|Version 10 (modified by 10 years ago) ( diff ),|
Transifex and Trac
Transifex is a modern, open-source localization platform. It’s a web system which automates the translation workflow for complex international projects.
Transifex and Trac
- Synchronization with Transifex
- Notes about the Transifex "Releases"
Transifex is indeed a nice tool and can be seen as much more attractive for potential translation contributors than having to go through the somewhat complex procedure described in the TracL10N page, involving svn, Babel, make, etc.
Things are not so simple, or rather, we should take an extra step to make it really as simple as it looks.
The problem is that we might have two sources of changes, and it will make no good to anyone if the two sources are not in sync:
- a Transifex translator might work on an out-of-date catalog, redoing the work the translator coordinator committed directly in the catalog file in the repository
- worse, pulling updates from Transifex and blindly committing them could lead to regressions
- conversely, a translator coordinator could easily miss the changes done by another translator on Transifex
- here as well there's a risk for him to overwrite changes made by Transifex contributors if he pushes changes carelessly
In the following, we'll try to present a workflow which avoids those pitfalls and enable changes to flow in both directions.
See also the related discussion in Trac-dev, Trac translations and Transifex.
Once you're familiar with Transifex (and they have some very good documentation on their site), you can apply for membership to one translation team for a language, or create a new team if your language of choice isn't yet represented there (be aware that undertaking a new translation for Trac represents a lot of work).
Translation team coordinator
It's much better if the translation team coordinator on Transifex is also the committer responsible for that language in the Trac project itself.
As a committer, he's ultimately in charge of the synchronization work, pulling changes made by members of the translation team on Transifex and pushing back changes made directly to the repository.
Here's an overview of the different teams and status.
|1) The languages for which we have a committer and a team coordinator|
|Japanese||ja||jomae||ja||jun66j5 (same ;-) )|
|Spanish (Argentina)||es_AR||rmorales||es_AR||cramm (same)|
|2) The languages for which we have a committer but no team coordinator|
|English (United Kingdom)||en_GB||mrelbe||en_GB|
|3) The languages present in the repository and no committers but have a team coordinator|
|4) The languages not yet present in the repository but have content and team coordinator|
|5) The languages present in the repository, but no committers and no team coordinator|
|6) The languages for which there's no content, neither in the repository, nor in Transifex|
- for the languages in #group1, the translation maintainers are primarily in charge for doing the synchronization
- for the languages in #group5, I'm currently going through a check before pushing back to Transifex
- for the languages in #group6, there's nothing to do
Translation team member
Updating translations on Transifex is only one part of the story, since you need to get your changes integrated into the source code. For that, you need to inform the translator coordinator for your language (see tickets for translation coordination). She will pull the changes from Transifex using the procedure described below, verify them, and commit them. If the translator coordinator doesn't react in due time or is not active anymore, a member of the Trac team will likely notice the activity on the ticket and he could do the same but without the language verification step, obviously.
It's even a better idea to contact and discuss with the translator coordinator before updating the catalogs on Transifex, as some might not be up to date, and you will risk to duplicate work and make integration harder. Transifex provides all the facilities for smooth communications between team members. There's also the tickets, or plain e-mail on trac-dev@… or directly to the translators.
Synchronization with Transifex
As discussed above, this is normally the responsibility of the translation team coordinator who has the commit permissions on the catalog files in the Trac subversion repository.
Typically you'd do this for approving and committing changes if you're a translation coordinator, but even if you're not a committer you could do this if you want to prepare a patch for submitting those changes for review on a ticket.
You first need to install the Transifex client.
Well, it's usually nothing more than:
(or one variation of the above).
If you're on Windows, you'll also need a hack…
Of course, you also need to have a checkout of the source, of the branch where you want to work. branches//0.12-stable will be maintained for the foreseeable future, so you may want to continue contributing there, but branches//1.0-stable is now the official stable release branch, so don't neglect it. trunk is where the new interesting stuff happen (TracDev/Proposals/ConfigEnumTranslation?).
Now let's go through a complete example. I made one update to the resource corresponding to the messages catalog on 0.12 for the French translation (more specifically, on that page: Transifex:resource/0_12-stable-messages-pot/l/fr/).
Checking the status
As I tried to emphasize in the previous sections, what is really important is to not lose translations, in one direction or the other. Well, at least on the Trac side we have version control, which doesn't seem to be the case on the Transifex side…
Back to the command line, for checking the status. First thing to do is to verify that everything is correctly configured:
cboos@linux:~/trac/0.12-stable$ tx status No authentication data found. trac -> 0_12-stable-messages-js-pot (1 of 2) Translation Files: - en: trac/locale/messages-js.pot (source) - ca: trac/locale/ca/LC_MESSAGES/messages-js.po - de: trac/locale/de/LC_MESSAGES/messages-js.po - en_GB: trac/locale/en_GB/LC_MESSAGES/messages-js.po - en_US: trac/locale/en_US/LC_MESSAGES/messages-js.po - eo: trac/locale/eo/LC_MESSAGES/messages-js.po ...
If you get the
No authentication data found. line, you first need to authenticate yourself:
cboos@linux:~/trac/0.12-stable$ mkdir tmp cboos@linux:~/trac/0.12-stable$ cd tmp/ cboos@linux:~/trac/0.12-stable/tmp$ tx init Creating .tx folder... Transifex instance [https://www.transifex.com]: Creating skeleton... Creating config file... No entry found for host https://www.transifex.com. Creating... Please enter your transifex username: cboos Password: Updating /home/cboos/.transifexrc file... Done. cboos@linux:~/trac/0.12-stable/tmp$ cd .. cboos@linux:~/trac/0.12-stable$ rm -fr tmp
Alternatively, you can directly edit your
~/.transifexrc file, and add:
[https://www.transifex.com] hostname = https://www.transifex.com password = <your actual password> token = username = <your account name>
token can be left empty, but must be present.
Then try again:
cboos@linux:~/trac/0.12-stable$ tx status | grep fr - fr: trac/locale/fr/LC_MESSAGES/messages-js.po - fr: trac/locale/fr/LC_MESSAGES/messages.po
A very important preparation task that must be done before pulling is to make sure the .po file was updated. Even if you think it must be because there are no local changes, it's a good idea to
make update-.. (
fr in this example). Perhaps the Babel version you're using at the moment is different from the one which was used before the last version was committed, or a manual change was done at the last minute, etc.
Doing a catalog update ensures that we have a "normalized" content to compare with the version of the catalog pulled from Transifex, after the latter has been "normalized" as well by another Babel update, as the automatic formatting done by Transifex is completely different.
Make sure to "freeze" that updated Trac version, by making a commit in a local branch (if you use git or hg) or even a "maintenance" commit in Subversion.
Pulling the French catalogs from Transifex
Now, before pulling changes from Transifex, make sure you have no local modifications to the catalogs you're about to update. Otherwise, those local modifications will be lost (well, on Windows at least; seems that on Linux it manages to make better checks with the timestamps between the local file and the file on the server).
Once you made sure you have no pending local modifications, you may now pull:
cboos@linux:~/trac/0.12-stable$ tx pull -l fr Pulling new translations for resource trac.0_12-stable-messages-js-pot (source: trac/locale/messages-js.pot) -> fr: trac/locale/fr/LC_MESSAGES/messages-js.po Pulling new translations for resource trac.0_12-stable-messages-pot (source: trac/locale/messages.pot) -> fr: trac/locale/fr/LC_MESSAGES/messages.po Done.
If you see 'Skipping…' messages, the Transifex client thought it should better avoid updating your local copy. If you're sure you know better, you can pass the
-f flag so that it updates it nevertheless.
Examining the changes
If at this point you want to check the difference … good luck! Transifex introduces a bunch of unrelated formatting changes in the translations, folding multiple lines into one, etc.
You can get rid of these spurious changes by doing an update with Babel, which can be seen as a kind of "normalization" step:
cboos@linux:~/trac/0.12-stable$ make update-fr python setup.py update_catalog -l fr update_catalog_js -l fr running update_catalog updating catalog 'trac/locale/fr/LC_MESSAGES/messages.po' based on 'trac/locale/messages.pot' running update_catalog_js updating catalog 'trac/locale/fr/LC_MESSAGES/messages-js.po' based on 'trac/locale/messages-js.pot'
Now the changes are hopefully much more significant:
diff --git a/trac/locale/fr/LC_MESSAGES/messages.po b/trac/locale/fr/LC_MESSAGES/messages.po index 00f3c3c..a33bf50 100644
a b 1 1 # French translations for Trac. 2 # Copyright (C) 20 07-2008Edgewall Software 2 # Copyright (C) 20 Edgewall Software 3 3 # This file is distributed under the same license as the Trac project. 4 4 # 5 6 7 5 8 # Emmanuel Blot <email@example.com>, 2007. 6 # Christian Boos <firstname.lastname@example.org>, 2008. 7 9 # Michel Briand <email@example.com>, 2008. 8 # Stéphane Raimbault <firstname.lastname@example.org>, 2009 10 # Stéphane Raimbault <email@example.com>, 2009 9 11 msgid "" 10 12 msgstr "" 11 "Project-Id-Version: Trac 0.12\n" 12 "Report-Msgid-Bugs-To: firstname.lastname@example.org\n" 13 "Project-Id-Version: \n" 14 "Report-Msgid-Bugs-To: \n" 13 15 "POT-Creation-Date: 2012-01-29 14:04+0100\n" 14 "PO-Revision-Date: 201 1-01-25 20:28+0100\n" 16 "PO-Revision-Date: 20100\n" 15 17 "Last-Translator: Christian Boos <email@example.com>\n" 16 "Language-Team: fr_FR<firstname.lastname@example.org>\n" 18 "Language-Team: <email@example.com>\n" 17 19 "Plural-Forms: nplurals=2; plural=(n > 1)\n" 18 20 "MIME-Version: 1.0\n" 19 21 "Content-Type: text/plain; charset=utf-8\n" … … msgstr "à %(owner)s" 2654 2655 #: trac/ticket/default_workflow.py:251 trac/ticket/default_workflow.py:271 2655 2656 #, python-format 2656 2657 msgid "The owner will be changed from %(current_owner)s" 2657 msgstr "Le propriétaire changera de%(current_owner)s" 2658 msgstr "Le propriétaire %(current_owner)s" 2658 2659 2659 2660 #: trac/ticket/default_workflow.py:259 2660 2661 #, python-format
It's a good idea to get rid of the changes in the first hunk. With git, it's easy:
cboos@linux:~/trac/0.12-stable> git checkout -p diff --git a/trac/locale/fr/LC_MESSAGES/messages.po b/trac/locale/fr/LC_MESSAGES/messages.po index 00f3c3c..a33bf50 100644 --- a/trac/locale/fr/LC_MESSAGES/messages.po +++ b/trac/locale/fr/LC_MESSAGES/messages.po @@ -1,19 +1,21 @@ # French translations for Trac. -# Copyright (C) 2007-2008 Edgewall Software +# Copyright (C) 2012 Edgewall Software # This file is distributed under the same license as the Trac project. # +# Translators: +# Christian Boos <firstname.lastname@example.org>, 2008,2012. +# Christian Boos <email@example.com>, 2008. # Emmanuel Blot <firstname.lastname@example.org>, 2007. -# Christian Boos <email@example.com>, 2008. # Michel Briand <firstname.lastname@example.org>, 2008. -# Stéphane Raimbault <email@example.com>, 2009 +# Stéphane Raimbault <firstname.lastname@example.org>, 2009. msgid "" msgstr "" -"Project-Id-Version: Trac 0.12\n" -"Report-Msgid-Bugs-To: email@example.com\n" +"Project-Id-Version: Trac\n" +"Report-Msgid-Bugs-To: http://trac.edgewall.org/\n" "POT-Creation-Date: 2012-01-29 14:04+0100\n" -"PO-Revision-Date: 2011-01-25 20:28+0100\n" +"PO-Revision-Date: 2012-10-27 13:13+0000\n" "Last-Translator: Christian Boos <firstname.lastname@example.org>\n" -"Language-Team: fr_FR <email@example.com>\n" +"Language-Team: French <firstname.lastname@example.org>\n" "Plural-Forms: nplurals=2; plural=(n > 1)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" Discard this hunk from worktree [y,n,q,a,d,/,j,J,g,s,e,?]? y @@ -2654,7 +2655,7 @@ msgstr "à %(owner)s" #: trac/ticket/default_workflow.py:251 trac/ticket/default_workflow.py:271 #, python-format msgid "The owner will be changed from %(current_owner)s" -msgstr "Le propriétaire changera de %(current_owner)s" +msgstr "Le propriétaire ne sera plus %(current_owner)s" #: trac/ticket/default_workflow.py:259 #, python-format Discard this hunk from worktree [y,n,q,a,d,/,K,j,J,g,e,?]? q
Note that you can also do
make diff for a more up-to-the-point output (
make diff vc=git if you're working in a git checkout).
Do something with those changes…
… do whatever you wish, for example commit the changes to the source with an appropriate log message, but, please!, before that:
- remember to check your catalog with
- remember to check your catalog by compiling it (here,
Once you're done, make sure you push back the changes to Transifex. See the other example below.
Pushing local modifications of the French catalogs to Transifex
After committing changes to the message catalog, it's a good idea to push those changes to Transifex so that other contributors can see these changes.
Even if you just pulled changes from Transifex (coming from the other example above), you most certainly did local adaptations like the removal of the spurious metadata changes, or small fixes, then you should also push those changes back to Transifex the same way, as Transifex won't pick up the changes made to the translated catalogs from the repository (it will do that for the catalog templates though, so the latter are always up-to-date).
But if you didn't do a pull just before, doing a push might overwrite changes contributed to Transifex, so you should be careful. The safest thing to do is to simply do a pull first, normalize the changes by running
make update-.., compare, and only then, if there are no changes but spurious ones in the metadata in the comments in the header, revert those spurious changes and do the push of your committed state. If the changes were significant, you're simply back to the #pull-example situation described before.
cboos@linux:~/trac/0.12-stable$ tx push -t -l fr Pushing translations for resource trac.0_12-stable-messages-js-pot: Pushing 'fr' translations (file: trac/locale/fr/LC_MESSAGES/messages-js.po) Pushing translations for resource trac.0_12-stable-messages-pot: Pushing 'fr' translations (file: trac/locale/fr/LC_MESSAGES/messages.po) Done.
For some languages, push can fail like this:
$ tx push -t -l gl Pushing translations for resource trac.0_12-stable-messages-js-pot: Warning: No mapping found for language code 'gl'. KeyError: 'gl'
This is because there's no
message-js.po catalog for the 'gl' translation, only a
The workaround is to push explicitly this one, by using the
$ tx push -t -r trac.0_12-stable-messages-pot -l gl Pushing translations for resource trac.0_12-stable-messages-pot: Pushing 'gl' translations (file: trac\locale\gl\LC_MESSAGES\messages.po) Done.
Notes about the Transifex "Releases"
Transifex is not exactly clear if a release should be a line of development (branch) or a given released version. It supports both and let you choose to organize you the way wish.
I opted to make the "releases" match our maintenance branches, and not individual releases (well, we still have a few of these, as apparently you can't delete a release).
The downside is that string freeze periods and release dates will need to be adjusted constantly on the same release. The alternative, creating a new "release" for each actual version we release bears as much overhead (more even, are there's no copy operation) and doesn't bring any benefit besides keeping a record of the versions we made, record that we obviously maintain here anyway in the roadmap.
OTOH, the big benefit is that all the links from t.e.o to Tx won't need to be updated after each minor release. The only updates needed will be at the occasion of introducing a new major release (i.e. for 1.2).