[libreoffice-design] Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

Hi Rimas, all

Le 27 janv. 2015 19:32, "Rimas Kudelis" <rq@akl.lt> a écrit :
> Hi Jan,
>
>
> 2015.01.26 16:43, Jan Holesovsky rašė:
> > Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:
> >
> > > Cosmetic changes (~ to _ or "Status" to "Status:" or ... to … or those
> > > different quote styles I don't even have on my keyboard) and anything
> > > similliar - NOT OK if you don't script it for all languages
> > > Cosmetic changes ("Big brown fox" -> "Big Brown Fox") - NOT OK at all,
> > > change just for en_us, don't change my strings and don't even notify me
> > > you did it in en_us
> > I see 2 problems here:
> >
> > 1) There is no tool that would detect these trivial changes, and would
> >    act accordingly.
> >
> >
> > Regarding 1) - I thought that Pootle is detecting the trivial changes
> > some way, and offering the original translation.  Is it not?  What can
> > be done to improve that, so that for translators it is just a matter of
> > checking; not a matter of translating?  [Or even what you suggest - that
> > it would just update the source strings without touching the
> > translations?]
>
> Pootle does offer the original translation, but the localizer still has
> to approve it.
>
> Furthermore, Pootle does not apply any automatic changes. If you had
> e.g. "Some ~string", and you change it to "Some _string", Pootle will
> show the original translation as a hint, but the user will still have to
> port this trivial change to the translation manually.
>
> Needless to say, sometimes these minor differences avoid being noticed
> by the localizers, which results in errors in the locale (I've seen
> incorrect access key identifiers in the menus at least once).
>
> However, while you are correct that there is no tool to detect these
> changes, I don't think there has to be. The person who implements the
> change knows better than anyone whether or not it can be automated,
> perhaps they even automated it themselves. For example, I seriously
> doubt that somebody went over all L10n files and changed triple dots to
> ellipses manually, this was most likely a scripted change. Same, or very
> similar, script would have probably worked with all other locales, but I
> guess that person simply didn't think about it.
>
> Similarly, changes in used quote characters most likely could have been
> isolated and transplanted to locales.
>
> Adding colons to certain strings only would probably have been slightly
> more difficult, but still scriptable.
>
> And none of that requires any "tool to detect trivial changes"... ;)

That's the point of this discussion, thanks Rimas to make it :-)
L10n team can always react, and earlier now, but making the scripting part
of the commit or part of the 'one making the change' is more natural in the
workflow.  In other words, our product is not en_US only.
> > 2) The texts for translations are updated in big 'code' drops, without
> >    possibility for translators to affect the process in any way - for
> >    them it is too late.
> >
> >
> > Regarding 2) - I'm glad that you say that the strings will be now
> > getting to Pootle immediately after the code / string changes in master.
> > I think it is important that the translators will be able to deal with
> > the changes immediately, not several months later, so that they can
> > cooperate, and not only react.
> >
> > In general, I don't think that setting extremely strict rules works,
> > unless you have means how to enforce them - like via a commit hook or so
> > (and it is extremely unpopular way to do things).
> >
> > It is always much better to communicate - if you see a developer who
> > commits a change that causes you grief, please _do_ tell _him/her_
> > immediately, and - if possible - in a friendly way.  I'm sure he/she
> > will do much better the next time.
> >
> > Unfortunately I did not see any signs of notice that this or that change
> > was problematic for localization on the development mailing list - were
> > there such warnings there?  Like "commit XY caused AB - please don't do
> > such things, unless we agree how to do that effectively / without pain"?
> > Or was it impossible so far because the strings in Pootle were not
> > synced with master?
>
> I fully agree with you here, and yes, so far communicating these issues
> was really difficult because these massive changes appeared in front of
> the localizers' eyes way too late in the process.

What we should take care though is to not over complicate the work of l10n
team by relying on this fact. So as I already said, it should be a shared
work and vigilance by the concerned teams.
Cheers
Sophie

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