2015.01.29 16:24, Christian Lohmaier rašė: > Hi Caolán, *, > > On Thu, Jan 29, 2015 at 3:10 PM, Caolán McNamara <caol...@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+unsubscr...@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
