Hi Sophie,
OK for me to work on master translation.
To conclude, what l10n team would like to see is:
- a review process of the strings before they are committed and make
sure they respect the en_US standards (capitals, grammar, punctuation,
typography). Maybe adding the Gnome HIG book to our pages [like 2] if
not already.
That will require a revisor with en_US skills.
- if there is a way to script changes, script them otherwise wait until
there is a script available to commit them- any time there are heavy changes that pop up in someone's mind (like
changing ... for …) discuss it with the l10n team before committing
those changes.
Right.
The issue is raised (IMHO) because a great deal of developers are not
english native speakers, as well as their focus is no C++ language
rather than English.
The thing is: if we can catch the modification upfront, it will make it
easy for all of us.
If I may also suggest, I'll ask all developers and within ESC recurrent
revision, to check/review/flag for any major issues with respect to
l10n. This can be implemented as
One: create a meta-bug about l10n en_US string revision.
Two: then on each commit that involves some form of l10n activity, the
developer should open a new bug with his commit number/reference and
link to the l10n meta-bug. The subject line should be "L10n revision
requested".
Three: the same developer, if implementing or modifying a feature,
should also open a similar bug with subject "[LOCALHELP] feature XYZ
changed/created; help page missing" and link to bug 80430.
Note that we don't ask to the developers to fix english mistakes nor
write help pages, tasks that we can offload from them provided we get
noticed.
Fixing English mistakes/linguistics and writting help pages is a task
the community can do continuously.
Kind regards