TP Translation Project You code, we translate.

Translators and the TP

  1. About the Translation Project

  2. The Translation Project (the TP, for short) is meant as a service to both package maintainers and translators. The advantage for maintainers is that they need to announce a new POT file to just one address and can fetch the translated PO files from just one place, instead of having to deal with several translators separately. For translators the advantages are similar: they receive the POT file announcements and pre-merged PO files from a single place and send in their PO files via a single mechanism, instead of having to deal in different ways with several maintainers separately.

    At the TP, translators are grouped into language teams (rather than package teams) because, in general, translation issues are more specific to a human language than to a particular package. It is good for translators of the same language to get together, check each other's work, and discuss any problematic translation issues. This also increases the chances that all packages at the TP get translated in a similar manner, using the same conventions and a consistent vocabulary. Lone translators tend to find their own ways and words, making a package stand out as strange.

  3. Becoming part of a team

  4. First find the page that belongs to the language you want to translate into. On there is a list of all current language teams. On the relevant team page you will find the email addresses of the team leader and of the team's mailing list. You may wish to subscribe to the latter and write to the leader to become part of the team.

    If there is no team yet for your language and you want to start one, see for more information.

  5. Filling out the disclaimer

  6. Many of the packages listed at the TP require that your translations for them be provably free. The TP robot will reject any submission for such packages if you did not disclaim, in writing, your copyrights over the translations you produce. More details, plus a copy of the actual disclaimer, are given on .

    It takes in the order of one month, after you have sent off the disclaimer, for it to be fully processed. This is often the bottleneck of becoming a translator for some package, so you should address this matter as soon as possible. Once this formality is over, you are clear to do as many translations as you want without going through the formality again.

  7. Learning to use the robot

  8. While you are waiting for your disclaimer to be processed, you can already submit PO files to the robot, to practice. The robot may not accept the PO file, but it will probably discover some errors and tell you about them. People translating for the first time usually make various small mistakes and it may require a few tries before you get everything right, especially since the robot is very fussy about the contents of the header fields. Don't be discouraged, the robot is very patient. :-) Exactly how to deal with the robot is explained on .

  9. Learning to use the gettext tools

  10. To make your translations you will probably use a special editor program like KBabel or poEdit. But to test your work before submitting it you will need the msgfmt program; to look at existing MO files you will need the msgunfmt program; and to make and use a compendium you will need the msgcat and msgmerge programs. Normally these tools should already be present on your system. (If not, find the gettext package in your distribution and install it.) Have a look at the man pages for these programs, to get an idea for what they can do.

  11. Diving into actual translation work

  12. Look at the big colourful table on your team page in order to find a package to translate. Look at the rightmost column and find a cell that is not fully translated (not bright green), then see if it is package that is installed on your system and whether you sometimes use it. These packages are good candidates for first translation tasks. If the package is already assigned, you can ask that translator if it is okay for you to take over this assignment.

    When you have found a package you want to translate (or whose translation you want to update), send an email to <> with a CC: to your team leader and ask for assignment of the package. If the team leader stays silent we take this as agreement.

    To download the latest PO file for the package you want to translate, click the version number next to the righmost column. Then start your editor on this PO file (see for a list of programs) and translate all the messages, one after another.

    Once your PO file is fully translated, you may first want to submit it to your team list, to get feedback from your team members. When you have the necessary changes to accomodate for their suggestions and criticism, you can send the file to the TP robot -- possibly using the script.

  13. The initial comment lines

  14. Each PO file starts with four or more lines which look like comment lines but which are an integral part of the PO-file format. These initial lines are, in order: 1) the title line, 2) the copyright line, 3) the license declaration line, and 4) one or more author lines. When a PO file is still fully untranslated, these lines look like this:

       # Copyright (C) YEAR Free Software Foundation, Inc.
       # This file is distributed under the same license as the PACKAGE package.

    The words that are written in all uppercase need to be replaced by you. If you are translating to Spanish and the PO file is for xchat, the first line could be: "# Spanish translations for Xchat." In the second line you have to replace YEAR with the current year. In the third line you have to replace PACKAGE with the package name, in all lowercase. With that line you declare that your translations is as freely distributable as the package itself. You may use the line "# This file is put in the public domain." instead, which some packages seem to prefer. On the fourth line you fill in your full name and email address, followed by a comma plus the current year plus a period. If you are updating an existing PO file, there will already be an author line present and you add your line below it.

  15. The header fields

  16. After the initial comment lines comes the PO file header in the form of an empty msgid. Its corresponding msgstr contains several special fields, of which normally only the POT-Creation-Date will have already been filled in. The other fields must be filled in by you, but normally the editor that you use will do this for you.

       msgid ""
       msgstr ""
       "Project-Id-Version: PACKAGE VERSION\n"
       "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
       "POT-Creation-Date: 2007-12-31 22:44+0100\n"
       "Last-Translator: AUTHOR NAME <EMAIL@ADDRESS>\n"
       "Language-Team: LANGUAGE <>\n"
       "MIME-Version: 1.0\n"
       "Content-Type: text/plain; charset=CHARSET\n"
       "Content-Transfer-Encoding: ENCODING\n"
  17. The messages

  18. The rest of the PO file consist of a series of msgid / msgstr pairs, each preceded by one or more comment lines. A typical untranslated entry looks like:

       #: lib/error.c:88
       msgid "Unknown system error"
       msgstr ""

    The empty msgstr string has to be filled with the translation for the string shown after msgid. If you are translating to German, the entry -- once translated -- might look like:

       #: lib/error.c:88
       msgid "Unknown system error"
       msgstr "unbekannter Systemfehler"

    You produce a translation for each entry in the PO file, one after another, while respecting the overall file format and the quoting needed for special characters. Good observation may allow you to grasp what the format should be; the precise rules for PO files are given in the GNU gettext manual. To pinpoint formatting errors, use:

       msgfmt -cv yourfile.po
  19. Working as a team

  20. At the TP most teams have a mailing list. On that list the TP robot posts its messages about new POT files and uploaded PO files, but its main purpose is to be used as a discussion list, for translators to post their PO files (especially in the beginning, when doing their first translations) and ask for comments, corrections and possible improvements. If, however, your fellow team members don't do this, don't hesitate to look at their PO files and comment (privately or on the list) on the mistakes you find there.

    If your team seems to have died, try to revive it by writing to all members directly. If they do not answer, and also the team leader stays silent, and you do want to get on with translation work, then write to a TP coordinator, <>.