Date: prev next · Thread: first prev next last


2015.01.29 16:24, Christian Lohmaier rašė:
Hi Caolán, *,

On Thu, Jan 29, 2015 at 3:10 PM, Caolán McNamara <caolanm@redhat.com> wrote:
On Wed, 2015-01-28 at 10:20 +0100, Stephan Bergmann wrote:
On 01/19/2015 11:03 AM, Sophie wrote:
e.g. in the past changing the "Letter" size translation in Spanish to
"Oficio" instead of the literal translation was a pain. And right now I
want to fix a gadzillion Indic translations short-cuts to ascii chars
and not characters that only available via IM. What I want to do is to
commit to the translations git repo and forget about it. Does that
work ?
Nope, as on the next export from pootle those changes will be overridden again.

The changes need to be done in pootle. (not necessarily via web-UI,
that would be tedious, but the change needs to be reflected in pootle
to "stick").

Well if we can't import stuff from git into Pootle, then it's quite a
broken process we have in place...

Until now, I believed that our l10n data can travel both ways, which
would mean that the state of affairs in Pootle can be exported into git,
altered, and imported back into Pootle without loosing anything.

In particular, since we're working on .po files, I see it like this:
1. reference strings are changed in en-US templates
2. the state of affairs is exported from Pootle into git
3. the translations are checked out and the changes made in step 1 are
reflected in msgid and, if necessary, in msgstr strings in the checked
out translation files, unless a particular l10n team opts out of this
automation.
4. changed files (more likely, a subset of them) are verified to be
correct and are committed back into git
5. these changed files are imported back from git into Pootle. When that
is done, the project is reopened for further translation and additional
validation of the result.

But as some languages use offline translation, even doing the change
in pootle might be undone when teams just upload their local copy
again without bothering to check for updates that were done in pootle.

That's why communicating such changes well in advance is necessary – so
that those who work offline can plan for that. In general, it is
possible that they will overwrite something, but in that case, it's just
that particular team losing the benefit of automation, not all of them.
Furthermore, the scripts we would use in each case don't have to be a
secret – a team that works offline will quite likely have enough
resources and knowledge to run them locally.

Rimas



-- 
To unsubscribe e-mail to: projects+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/projects/
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.