Re: l10n process, en_US version, Help files

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

and sometimes not because you may also translate the product without
being an experienced user, or simply because you use Writer but not
Calc, etc...
> > - 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. :)

Not sure, as Khaled said, it may be because the load of work on
translation is enough to not take care of other things.
> > * 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.
> > - 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.

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

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

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.

Cheers
Sophie