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

Hi Kendy,
Le 26/01/2015 15:43, Jan Holesovsky a écrit :
> Hi Sophie, Mihovil,
>
> 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.
>
> 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 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 will show you a modified string, even if it doesn't affect your
translation you will have to validate the string again to have it on a
translated state. Also we don't all work on Pootle, several of us are
working off line and Pootle is only a repository for our files.

That's why we were thinking of a en_US version as a real language and
different from the sources and also about scripting changes when
possible (like the substitution of ~ by _)
> 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.

yes, that's much better, even if we have to be cautious about the workflow.

> 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.

Translators are for most of them non technical people and will not see a
commit, but only the result on Pootle, sometimes months later. In the
same way the developer who is doing tons of changes for en_US is invited
to discuss them with the l10n team :)
> 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?

Yes, I think it was too late and when the l10n team is at work, it's the
rush i.e RC time for developers, so not the best period to discuss hot
topics ;) That's why I've waited to open this discussion.
Also, even if I've discussed as much as possible about l10n on issues
concerning UI changes, it's a lot of work to follow each commit that
could have an effect. Sharing the effort between developers/UX/l10n
teams should be possible. As we follow Gnome HIG, adding it as
pre-requisite for UI changes/adds may prevent to have to rewrite dialogs
for example.
> Also - should we have a 'Localization' recurring topic in the ESC?  Who
> would be the right representative there, please?

Maybe not as a recurring topic, but something that should be in mind of
UX team and developers when they commit or check for commits that have a
huge impact on l10n.

Cheers
Sophie

-- 
Sophie Gautier sophie.gautier@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation

-- 
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