Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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

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.