Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 2013.12.11. 17:19, Sophie wrote:
*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.

Discissions in this mailing list usually helped to clarify the meaning.
Failing that, git log / git blame -- find out who the author was and ask
him or her. Translators are welcome to test new features, sometimes it
is obvious what a function does, despite the confusing UI text.

- 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)

If it's overlooked by 60+ active translation teams + beta testers, then
probably it is not that much important. We can live with it. :)

* 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.

- 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 expected.

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.

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
write a mail to the list, newcomers will not see it. You can write wiki
pages, some people will not read it. You can ask people individually,
some will ignore you. But I have an idea. What about prolonging the
string freeze date of help until the first bug fix release? That would
give developers/help authors/translators more time to concentrate on
documentation of new features. So we could say, with x.y.0 you get all
new features, and x.y.1 will come with updated help.

Best regards,
Andras


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.