Date: prev next · Thread: first prev next last

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

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.


Sophie Gautier
Co-founder - Release coordinator
The Document Foundation

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.