Transifex and Trac
Trac is available in a number of languages and the translations for the captions are performed in Transifex, which is a modern, open-source localization platform. It is a web system which automates the translation workflow for complex international projects. It is the alternative to the more laborious TracL10N process, involving svn, Babel, make, etc.
This page is targeted at translation team coordinators who need to synchronize the translation updates with the translation catalogs in the repository.
The key is to keep all sources in sync, if there is more than one:
- 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, a workflow which avoids those pitfalls and enables changes to flow in both directions is described. 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 a new translation for Trac usually involves 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.
A committer is 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
|English (United Kingdom)||en_GB||mrelbe||en_GB||mrelbe|
|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
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 #group2 there is only the usual maintenance to do
- for #group3 the translation team coordinators are invited to ask for commit privileges and integrate #group1
- for #group4 the translations will be "promoted" to #group3, ie integrated in the repository, as soon as a decent coverage is reached (say > 50%)
- for the languages in #group6 there's nothing to do as long as there's no content
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. The translator coordinator 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 duplicating work and making integration harder. Transifex provides all the facilities for communication between team members. There are 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. 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:
$ pip install transifex-client
or a 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 you want to work on:
- branches/1.2-stable will be maintained for the foreseeable future, so you may want to continue contributing there
- branches/1.4-stable is the latest stable release branch
- trunk is where the new interesting stuff happen (TracDev/Proposals/ConfigEnumTranslation?).
Now let's go through a complete example, starting from 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
The key is to not lose translations, in one direction or the other. Unlike Trac, Transifex does not support version control.
In the command line, 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
An 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.
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 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, 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 differences. 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 should be 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 instance. 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.
Publish your changes
You can commit the changes to the source with an appropriate log message, but, please!, before that:
- remember to check your catalog with
make check, here:
- remember to check your catalog by compiling it, here:
Once you are done, make sure you push back the changes to Transifex. See the other example below.
Pushing local modifications of the catalogs to Transifex
After committing changes to the message catalog, it is 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.
That can be done for several languages at once:
$ tx push -t -r trac.0_12-stable-messages-pot -l fa,gl,ko,pt,ro,vi Pushing translations for resource trac.0_12-stable-messages-pot: Pushing 'fa' translations (file: trac\locale\fa\LC_MESSAGES\messages.po) Pushing 'gl' translations (file: trac\locale\gl\LC_MESSAGES\messages.po) Pushing 'ko' translations (file: trac\locale\ko\LC_MESSAGES\messages.po) Pushing 'pt' translations (file: trac\locale\pt\LC_MESSAGES\messages.po) Pushing 'ro' translations (file: trac\locale\ro\LC_MESSAGES\messages.po) Pushing 'vi' translations (file: trac\locale\vi\LC_MESSAGES\messages.po) Done.
Notes about the Transifex "Releases"
In Transifex is not exactly clear if a release should be a line of development (branch) or a given released version. It supports both and lets you choose to organize the way you wish.
I opted to make the "releases" match our maintenance branches, and not individual releases; 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 (moreover, 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.
On the other hand, 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 when introducing a new major release, for example for Trac 1.2.
See also: TracL10N