Re: [libreoffice-l10n] Re: l10n process, en_US version, Help files

Hi Robinson,
Le 12/12/2013 00:35, Robinson Tryon a écrit :
> On Wed, Dec 11, 2013 at 11:19 AM, Sophie <gautier.sophie@gmail.com> wrote:
> > Hi all,
> >
> > 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.
>
> Hiya Sophie,
> 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
> repos?

First, thanks for taking part of this :) and yes, given that en_US is
the source for all localization you have to fix it in the source. May be
Andras could give you more info here, it's one level to high for me ;)
> 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 :-)

thanks a lot for your offer.
> > *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
> > proof reading.
> > - 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?

Having the overall number of real words to translate (over the xml
changes or .ui port) would be great. I'm not sure I understand what you
have in mind with a web visualization tool :)
> > *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
>
> So basically
> - better communication
> - more lead-time before strings land in pootle

yes, currently we are in the dark concerning numbers, updates,
integration, time for fixes.
> > *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.

Yes, this is my idea, but I need input from Christian or Andras to write
the page
> > *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?

I don't think you can do anything here, it's more on the developer side
before merging patches.
> > - 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?

Imho there is no formal workflow, or none I'm aware of. Filing a bug but
I don't know who will fix it, I think that most of the time Andras takes
action here.
> > - 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:
> http://12v.org/urs/EuroUrS6InstrumentClusterDiagram.jpg
>
> Perhaps something like that would help the devs keep the naming consistent?

I don't know, this is why I need input from developers :) There are may
be guidelines for example the orders of the [Help] [OK] [Cancel]
buttons, but even here I'm not sure of the consistency, but I don't know
about a nomenclature of strings. I don't want to add processes or
constraints to developers, but more give them some references where they
can find quickly the good terms to use.

Cheers
Sophie


-- 
To unsubscribe e-mail to: l10n+unsubscribe@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/l10n/
All messages sent to this list will be publicly archived and cannot be deleted