Hi all,
[Please follow-up the discussion on projects@ list to keep the history
of the thread there and ease the discussion, thanks :-)]
I would like to open a discussion about the way developers team, UX team
and l10n team should interact and work together.
There has been a heavy discussion [see this thread 1] during this round
of translation. The l10n team was a bit frustrated that there were again
so many changes in the en_US version that does not concern the l10n
versions (like adding colon at the end or capitals in the middle of the
strings).
Each time, it seems part of this could be automated or a reflection
on how to avoid messing the l10n work should have been introduced before
those changes are committed. For example, if I decide to change FR
localization to have sentence capitalization in the menu entries, none
of the 100 other localizations won't and shouldn't be affected. It
should be the same for en_US version or if really impossible, try to
find a solution that lower the impact on all localizations.
None of the l10n teams is against changing or correcting the UI of the
en_US version and none is against the natural evolution of the suite.
What is not bearable is when you have 100 000 changes in en_US and only
a 1/3 concerns all the other languages and it is repeated over the
branches.
We are trying to change our workflow to work on master instead of
branches. That will allow us to review the strings earlier (to leverage
heavy unneeded changes if possible) and have more time to localize. But
that will work only if each taking part of the changes take care of the
others.
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.
- 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.
I know it may lower the enthusiasm of some contributors, but it will
regain the one of our l10n teams for sure :)
[1]
http://nabble.documentfoundation.org/libreoffice-l10n-Workflow-based-on-master-tt4131453.html#a4132459
[2] https://developer.gnome.org/hig-book/3.12/design-text-labels.html.en
Cheers
Sophie
--
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation
--
To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/projects/
All messages sent to this list will be publicly archived and cannot be deleted
