My grain of salt there. I strongly believe we need to cross-talk, so I go
Le Thu, 12 Dec 2013 13:54:05 +0100, Sophie <firstname.lastname@example.org> a
Hi Andras, all,
Le 12/12/2013 11:18, Andras Timar a écrit :
On 2013.12.11. 17:19, Sophie wrote:
*About the en_US overall quality
- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)
Not sure, as Khaled said, it may be because the load of work on
translation is enough to not take care of other things.
We have three steps here:
- Seeing the typo / obvious inconsistency
- Marking the typo
- Fixing the typo
* See : With a en-US ui, you can catch some during normal work
Else, you are in a chase for them (QA, l10n, someone ? ).
* Next step is to mark them.
When you are in a chase, you can organize stuff to avoid duplicate work
and jot all references to, say, a wiki page or an etherpad, whatever fits
When you catch one on LO: what will make you go further ? Easiness. We
need a simple process to submit. The counterpart is that we may have many
false positives, so more filtering to do. Conclusion : either we provide a
simple way to report a miss in the text because it may provide useful
input, or we consider not having enough people to filter, and we limit
ourselves to chases.
* And... fixing !
Easy hacks or l10n sessions to fix that are both valid choices. We may
want to automate finding occurrences of text in the code. We began with
fdo#39439, but further steps are required.
* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended ;)
Probably it is prescribed by some rule, e.g. Gnome HIG, that every
dialog must have a Help button. So dialog creator application puts it
there, and the developer leaves it there thinking that someone may write
a help page for it later.
Well, may be, but unfortunately the help page is never created.
And who is this someone ?
BTW, I don't really know the workflow to provide some help content, but I
think the developer creating a help button should at list input some draft
so people have a start to improve (like we had some lengthy comments on
usage in code before).
We may have a script to parse the code and find help links without
targets, but to fight against obsolescence, we need people involved and
scanning the help, or like typos an easy way to report.
We are more in a typewriting & review process than a l10n one, so maybe we
need doc@ here.
If I admit your example is quite useless, Andras, we have many not-at-all
savvy users which actually needs the help, and the basic one, not the
expert one. That is the hard stuff. I don't want to dive into tutorials in
help, but a good explanantion and an example may help people figure how to
use something or to determine if this something is what they are searching
Remember that we have many facilities in LibreOffice, and we don't know
them all. So at one point you have to search for them. And here goes the
- more and more functions are undocumented or their help is obsolete. I
always think that an undocumented function is lost for the user and a
sad thing for a developer because his function will not be used as
As I wrote above, many functions/new dialogs are self-describing. I
hated to translate Gnome help 10 years ago, which was full of sentences
like this: "Click on Close button to close the dialog." So we need to
limit the scope here. It would be good, if you could give examples, what
needs further clarification in help.
They may be self describing for you, but not for most of our users. I've
collected some issues where the help needs to be amended or is missing,
but it would be better to have a general process and try to include more
people in it.
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do. Searching on BZ with this special tag would allow to involve more
people in the loop to test it and document it.
The problem is that you cannot enforce any rule to developers. You can
That I know :)
But I have an idea. What about prolonging the
string freeze date of help until the first bug fix release? That would
That's a good idea, but we still need help authors. I'm sure some people
will jump in, even earlier, if they only know where, hence the proposal
for a dedicated issue. As I said in another mail, I don't want to add
more processes, rules, etc. But there is some areas that impact more
than one team where it would be good to have some worflows.
We can have a start saying all contributore to libreoffice are nice :)
Then, we can ask for some information, like I said above, but I agree we
need authors there.
I don't say it will be easy, and I don't want to be like a
do-this-and-that. The above statements are just my view of what I think
could help to improve ourselves on those points.
Thanks for your attention
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy