FAQ on migration to Transifex.com
General questions about the migration
The core Fedora translation projects were migrated to Transifex.com on Friday, February 18, 2011. Projects on Fedora Hosted will be given a chance to opt-out, and those who don't opt-out will be migrated over the next two weeks.
Why now and not wait for the next version?
We are lacking resources to manage our current infrastructure, and the L10n group decided that the Fedora 15 translations are in danger. All related Fedora groups (L10n, Infrastructure, Packaging, Docs and Board) have concluded that there is little risk in the move.
Where do I get the "tx" command-line utility?
Where can I get more help on using the Transifex client?
Additional help for the Transifex client is available at http://help.transifex.com/user-guide/client/client-0.4.html.
Do I need to create a new account?
At this point, yes, you need to create a new account on Transifex.com, in order to join teams and work with other translators. There is no stable and well-tested OpenID support in Fedora Infrastructure, nor in Transifex.
Can i help in making the migration faster?
Yes. You can bootstrap the migration of a developer's project. When you create the project, assign maintainership to glezos and raven too, in order to hand over the maintainership to the proper developer when he creates an account on Transifex.
How do I migrate my team?
Here's the list of translation teams on Transifex.
Existing maintainers who don't see their team there should create an account, login, and Request a team creation from that page.
If you are an active translator but your maintainer is not active any more, please follow the standard procedure to change the team maintainer. Contact your own team, create a vote, and send an email to trans-list with information on changing the team maintainership. We basically need to see that the whole team approves you as the maintainer, before approving you.
If in doubt, ask in #fedora-l10n by pinging one of the Fedora L10n maintainers listed, or by sending them a message through Transifex or email.
My project has already been migrated, now what?
You'll need to become the project maintainer on Transifex, to be able to push source language strings, create new resources etc.
First, create an account on Transifex. On your Project Details page, you'll see that we've assigned a couple of temporary maintainers. Send a message to one of them to add you as the project maintainer.
My project has not been migrated yet, what do I do?
Create an account on Transifex and proceed to read the question below "How do I use "tx set" properly?".
How do I assign my project to the Fedora teams?
Most Fedora projects will want to use Fedora's translation teams. To do this, do the following: Navigate to Transifex → MyProject → Access Control → Outsource → "Fedora Project".
- NOTE**: At the moment, you'll need to first push your translations and then apply this. This should be fixed on the week of 8-Mar-11.
How do I use "tx set" properly?
It depends on how your project is set up. In all cases, the set up is a simple process, and there's full documentation on the transifex-client package and the tx utility.
All these instructions assume that you have already visited the translation portal and set up your project there. If you haven't done so yet,create your localization project on Transifex. Note your project's slug on the site, which is usually its name rendered in all lowercase. If you can't remember that setting, visit the project page and select Edit to look at the settings.
The rest of the instructions will use the following conventions:
- $PROJECT_SLUG - the slug for your project. If you can't remember it, visit the project page and select Edit to see the setting; it also appears in the URL for the project.
- $RESOURCE_SLUG - the slug for a resource. If you can't remember it, visit the project page, select the resource, and then select Edit to see the setting; it also appears in the URL for the resource.
- $SOURCE_LANG - the source language for your project. Usually this is "en".
- $PO_DIRECTORY - the directory in your project's source tree where your pot file and po files are maintained, usually it's the po subdirectory under your projects top level directory (e.g. $topdir/po)
- $POTFILE - the POT file for a single-POT project, e.g. $PO_DIRECTORY/<project_name>.pot (usually po/<project_name>.pot)
My project has a po/ folder, a single POT and multiple PO files
In your checked-out project repository (e.g. a SVN checkout or git clone), run:
This command creates a ~/.transifexrc file for your user account, and a .tx/config file in your project working tree. You may commit the latter in your repo, so it's used across developers and be version-controlled.
To declare your POT file and the source language (probably "en"), run this command:
tx set --execute --auto-local -r $PROJECT_SLUG.$RESOURCE_SLUG -s $SOURCE_LANG -f $POTFILE "$PO_DIRECTORY/<lang>.po"
To pull the latest translation (PO files) from Transifex for all languages, run:
tx pull -a
My project uses multiple POTs
Each POT file will become a separate resource. If they are two, just run two set commands. With the next push, both of them will be pushed.
If they are too many, you can create a small script to replace the 'set' commands similar to this:
for POTFILE in `ls pot`; do FILE=$(basename "$POTFILE" .pot) tx set --auto-local -r fedora-docs-relnotes.$FILE --source-language=en \ --source-file pot/$FILE.pot "<lang>/$FILE.po" --execute done
Can you show me a full example?
Do I have to add the .tx/config file to my project?
No. You can add the tx set commands needed to your build scripts and execute them each time you make a release if you prefer. Committing the .tx/config file to your repository simply speeds up the process.
Some of my languages (po files) could not be pushed (401 error etc)
To push your languages and ignore the broken ones, use `tx push -s -t --skip`.
- NOTE**: Also, you should *first* push your translations and *then* outsource your teams to Fedora. If you have already outsourced them, temporarily change this (Tx Project Page → Access Control → Limited Access), push, and re-enable it. This should be fixed on the week of 8-Mar-11.
Non standard language name
This could happen if the language do not have a standard name. There are 260+ languages supported -- use one of them.
po files without translations (empty)
The tx client may report it successfully pushed the po file but the po file does not appear in the resource on the TX server. This may be because the po file did not contain any translations (e.g. all msgstr's are empty, this can happen when you first create a po file using msginit)
Some po files are "Skipped" by the tx client
The tx client compares the timestamp of the po file on the server with the last modified timestamp of the po file in your source tree. If the timestamp of the TX server's copy is newer than the timestamp of the file in your file system then the tx client will skip pushing the file on the believe the TX server already has a newer version. You may need to reset the timestamps on your po files to the current time (e.g. touch $PO_DIRECTORY/*.po). If there is time skew between the TX server and your machine you may need to wait a few minutes until your recently modified timestamps appear to be newer than the TX server's notion of the timestamp so that the tx client will push it. If your machine's clock is significantly different than the TX server's clock you may need to reset your clock (hint: use ntp)
But my resource does contain some empty po files, you said tx client won't push those
The TX server will create a po file for each translation team assigned to the project when the resource is created. Those po files will initially be empty. It appears to be an odd inconsistency that the TX server will not accept empty po files from the tx client, but happily creates empty po files in anticipation of a translation team.
Some languages (po files) appear in my resource which were never pushed
After creating a resource you may discover while looking at the resource's contents on the TX server there are languages (po files) listed which you never pushed. Where did they come from? If your project already has translation teams assigned to it then the TX server will automatically add a language (po file) to your resource for each translation team. Initially those po files will not have any translations in them (0% translated).
Why have my PO file comments been removed?
There are three types of comments in PO files:
- Developer-produced comments -- they are located before msgid and have a special prefix. This IS supported by Tx.
- Translator-produced comments -- same as above. This is PLANNED to be supported in Tx.
- Comments in PO file which are not attached to translatable entities. This is outside of Tx's scope.
Because Transifex now uses the POT file itself to generate all PO files, all comments inside your PO file are not kept. In fact, the PO file itself is not kept at all -- translations are stored in the database itself, allowing more flexibility and features. Hence, comments which were in the PO file are not retained.
Since traditionally copyright assignment was kept as comments on the top of PO files, starting from Transifex 1.0, one needs to track copyright history in a different way.
You should either keep copyright notices in a separate "README.translations" file or inside the POT file (again, POT file comments are retained). In the future, we plan to support copyright assignment in Transifex natively, however general comments won't be kept.
(related ticket: #675)