Workflow between dev, UX and l10n teams

projects
#41

So IMO there's the root of the problem. Lets say a developer does want
to make LibreOffice comply with the GNOME HIG and stick full colons at
the end of every label that is a label for another widget and is willing
to fix all the translations at the same time then he can't really do it.
So there really needs to be some way for developers to mass change
translations themselves, and ideally a trivial way.

I think we should not worry too much about the offline "upload and
overwrite" style case. There's no helping that :slight_smile:

C.

#42

2015.01.29 16:24, Christian Lohmaier rašė:

Hi Caolán, *,

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

#43

While I understand the concerns that underlie your idea, that process
is so heavy that we are just going to lose "drive-by" contributions
like e.g. the commits I did in August 2014 (which possibly no one
noticed and somebody else redid most of the work again
independently...).

http://cgit.freedesktop.org/libreoffice/translations/commit/?id=d9ae641365f094cc1898d7f614dc8a72a1c6b914
http://cgit.freedesktop.org/libreoffice/translations/commit/?id=34a7cd1e0959023b5fb0fa0e5873bcc67ae026e4
http://cgit.freedesktop.org/libreoffice/translations/commit/?id=1a15415c3fe875ee4193fbdbcbd0ebde3b13b48

Is there a possibility that git and pootle are more-or-less constantly
kept in sync? For example:

1) a git hook (script run automatically each time a push is done) that
   pushes the changes to pootle as soon as they are pushed to git
   (just like we mirror our git repo(s) to freedesktop).

2) the same from the pootle side, as soon as a translator makes a
   change, it is exported to git.

3) There is a theoretical race condition for conflicts (although the
   window could be kept to a few seconds...). In case of merge
   conflict, error out and mail a human for manual merge?

#44

Interestingly, doing a web search for "pootle git synchronisation"
leads me to http://weblate.org/en/features/ >:-)

#45

Hi,

Interestingly, doing a web search for "pootle git synchronisation"
leads me to http://weblate.org/en/features/ >:-)

Well, once we dont require to be self-hosted anymore,
https://translations.launchpad.net/ certainly would be an option too. However,
IMHO there are very good reasons to be self-hosted with translations.

Best,

Bjoern

#46

ourselves.

#47

Hi,

>> Interestingly, doing a web search for "pootle git synchronisation"
>> leads me to http://weblate.org/en/features/ >:-)

> Well, once we dont require to be self-hosted anymore,
> https://translations.launchpad.net/ certainly would be an option too.

However,

> IMHO there are very good reasons to be self-hosted with
> translations.

From glancing at the webpage, Weblate is a software that we can host
ourselves.

This is something the l10n team has already in his radar. But please,
before changing our tool and our workflow, let's discuss at Fosdem with
Dwayne from the Pootle team what we can achieve.
Cheers
Sophie

#48

Hi Lionel,

2015.01.30 10:53, Lionel Elie Mamane wrote:

2015.01.28 11:20, Stephan Bergmann wrote:

When talking about (developer-side) scripting, is it actually OK to
commit modifications to the translations in the translations git
sub-repo? My understanding was that such modifications would be
overwritten by the next "import commit" (as typically done by
Andras, AFAIU from some Pootle database).

The process as I see it would be somewhat like the following: when we
have a big enough string change, which can be scripted coming up, it
should be announced at least a few days in advance, that on day X time
Y, this change will land. (...)
On day X time Y, we close down the affected Pootle project, push its
localizations into git, then somebody who's in charge checks them out of
git and runs the script. When the script finishes its work, the
resulting files are committed back to git, imported back to Pootle and
the project is re-opened for translation. Once that is done, an
announcement should be sent to the L10n list with huge thanks for
everyone's patience and kudos to everybody involved in the process. And
we all live happily ever after. :slight_smile:

While I understand the concerns that underlie your idea, that process
is so heavy that we are just going to lose "drive-by" contributions
like e.g. the commits I did in August 2014 (which possibly no one
noticed and somebody else redid most of the work again
independently...).

http://cgit.freedesktop.org/libreoffice/translations/commit/?id=d9ae641365f094cc1898d7f614dc8a72a1c6b914
http://cgit.freedesktop.org/libreoffice/translations/commit/?id=34a7cd1e0959023b5fb0fa0e5873bcc67ae026e4
http://cgit.freedesktop.org/libreoffice/translations/commit/?id=1a15415c3fe875ee4193fbdbcbd0ebde3b13b48

I'm not sure exactly how such drive-by commits are relevant to this
case. I don't think anyone is taking care to watch for such commits at
the moment and import them into Pootle. I imagine that right now, only
locale that gets imported into Pootle periodically is the source locale
(en-US). Any changes to other locales, like this change of yours, are
doomed to be overwritten on next export from Pootle, unless you do them
in Pootle itself instead.

Is there a possibility that git and pootle are more-or-less constantly
kept in sync? For example:

1) a git hook (script run automatically each time a push is done) that
   pushes the changes to pootle as soon as they are pushed to git
   (just like we mirror our git repo(s) to freedesktop).

2) the same from the pootle side, as soon as a translator makes a
   change, it is exported to git.

3) There is a theoretical race condition for conflicts (although the
   window could be kept to a few seconds...). In case of merge
   conflict, error out and mail a human for manual merge?

Considering the size of our project and the amount of files, I'm afraid
that both these things would be impractical at the moment, here's why:
1) Exporting files from Pootle takes a lot of time currently. Exporting
only the relevant file on string submit would likely be faster, but
still not fast enough, I'm afraid.
2) Furthermore, even assuming that speed would be acceptable, making a
separate git commit for each string change would blow the size of
repository considerably and litter the commit log with thousands of
commit messages. Also, I suspect tree deviations might be unavoidable,
and merges might be required.
3) Regarding importing changes from git into Pootle – it's also slow, it
would likely be faster if import would be done for just the affected files.

Then again – how often do such drive-by commits happen? My guess is not
very often. So I don't think that is the scenario we should tailor for.
I can't open the git commit log page at the moment (perhaps the
repository is already too huge for cgit?), but if among the developers
there are only a handful exceptions like you, who want to also
contribute to their locale, perhaps the best option for them currently
is to do it using Pootle itself, or by contacting the localizer in
charge? I know that it seems much easier to just fix the problem, but as
you saw yourself, that doesn't quite work in our case.

On the other hand, the massive changes that we are discussing here are a
whole different beast: they are massive and they affect all locales,
because they change many strings in the source locale. And they are
often scriptable. And they drive localizers nuts, if not done properly. :slight_smile:

By the way, I just glanced over your commits, and it seems you mostly
removed spaces in some help SGML tags. Were these spaces breaking anything?
Also, the last commit you linked to mentions BugZilla. I feel obligated
to say that Bugzilla is called Bugzilla and not BugZilla (just like
Firefox is not called FireFox, and Microsoft is not called MicroSoft,
and we are not called Libre Office with a white-space in the middle).
That misnaming should probably be fixed in the source.

Regards,
Rimas

#49

There must be some American users of LibreOffice? Wouldn't en_US just be
like any other language, with the same challenge of finding translators?
Some would step up if they find the en_US translation to be less than
acceptable for them.

#50

I should add, if we go down that route, surely it's not a problem to
script a mass change in master to sync it with en_us, that also flags
all translations as unaffected by that change. Saving loads of
translation grief, but saving the space that Michael Stahl pointed out
would otherwise be taken up.

Cheers,
Wol

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.