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