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"... ;)
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.
Regards,
Rimas
--
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
- Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams (continued)
[libreoffice-l10n] Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams · Rimas Kudelis
[libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Wols Lists
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Jesper Hertel
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Jesper Hertel
[libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Wols Lists
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Rimas Kudelis
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Sveinn í Felli
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Jesper Hertel
[libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Stephan Bergmann
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.