On Wed, Dec 11, 2013 at 11:19 AM, Sophie <firstname.lastname@example.org> wrote:
This mail is posted to the dev list and the l10n list, please follow up
on the l10n list.
I would like to open a discussion on the l10n workflow, the quality of
the en_US version and the Help files. All is linked and I would like to
discuss how we can improve the process here. I'm sure that having a
better understanding between the l10n process and the dev process should
help us to improve things :) So here is a proposal, it's a bit long,
sorry for that.
I've registered for the Pootle site, and I've started to poke around
on there. I'm not sure if there's anything I can do at that point in
the chain -- I guess I'll have to go up one level to the help and core
If there's anything specific I can do re: the en_US stuff, please let
me know. I've got a couple of airport layovers in my near future, so
I'll have a bit of time to spend :-)
*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
- depending also on the type of changes, we could use different tools to
optimize the work.
I'm not exactly sure how we import data into pootle, but perhaps we
could set up some kind of web visualization tool to show the current
diff (in # of strings, # of words, etc..) between what's in the
upstream repos and what's in pootle. Would that be helpful?
*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too
- better communication
- more lead-time before strings land in pootle
*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this
Perhaps documenting the process in some pages on the wiki would help
i10n better-understand how this works, and lead to some simple ways to
better communicate what's going on elsewhere back to the i10n teams.
*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.
I'm still getting my feet wet here, so I'm not quite as up to speed on
this process as you guys. It sounds like some of these issues are
rather nuanced, such that me being fluent in English isn't necessarily
going to help me track down problems much faster without some
additional context, right?
- 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)
What's our current workflow for solving those? Filing a bug, or?
- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used
Do we have a dialog with labels on all of the different parts,
indicating what nomenclature we're using to refer to each dialog or
component? Here's an example with a car dashboard:
Perhaps something like that would help the devs keep the naming consistent?
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