Translation Team/i18n Best Practices

General tips

Here are some general tips which will make your translators happy. For a much more comprehensive list of best practices, please read the Gnome i18n Guidelines.

When in doubt, use translator-comments

When you are using a string which may be confusing for the translators (contextual issues, or cultural issues), or if you want the string to be translated according to a particular convention, use translator-comments, which would show up alongside the message in the PO file translator get when they translate you software. Example (from Calculate activity)

        # TRANS: multiplication symbol (default: '*')
        self.mul_sym = _('mul_sym')

So as you can see from the above example, translator-comments are normal Python comments with the "TRANS" keyword. This shows up the PO file as

#. TRANS: multiplication symbol (default: '*')
#: mathlib.py:74
msgid "mul_sym"
msgstr ""

You can also use msgctxt, which is better integrated with Translation Memory (T.M.). The output is in this form:

#: string ID
msgctxt "button label"
msgid "Edit"
msgstr ""

Use plural forms

Do not assume that all languages have a concept of singular and plural like English. Some languages might have a single form, and some have more than two form. Use plural forms via ngettext() in these cases. Example (from sugar-update-control):

                header = gettext.ngettext("You can install %s update",
                                          "You can install %s updates", avail) \
                                          % avail

Show changes in strings

Use the "--previous" option with msgmerge when updating PO files. This option will output strings like this:

#, string header
#|msgid "This is the old string"
msgid "This is the new string"
msgstr "This is the old string translated"

so translators can see what has changed. Some translation editors will highlight the changes, which is particularly helpful with complex strings, very long strings or strings with code/formatting. This option definitely improves the accuracy of translation updates.

Use white-spaces and newlines only when you need to

The tool which converts the translated PO files into binary MO files, msgfmt, can be quite picky about newlines and lines with only whitespaces. For example, the following string in sugar has a blank line at the end which is often overlooked by translators, causing msgfmt to choke.

    print _('Usage: sugar-control-panel [ option ] key [ args ... ] \n\
    Control for the sugar environment. \n\
    Options: \n\
    -h           show this help message and exit \n\
    -l           list all the available options \n\
    -h key       show information about this key \n\
    -g key       get the current value of the key \n\
    -s key       set the current value for the key \n\
    -c key       clear the current value for the key \n\
    ')

Keep string formatting as simple as possible

In case of code like the following example, translators tend to translate the strings "error" and "file" into their own languages, causing msgfmt to choke.

                notify.props.msg = _('%(error)s when deleting %(file)s') % \
                    { 'error': err.strerror, 'file': logfile }

Avoid such strings if possible; use numbers or untranslatable strings (that are not English words) instead, e.g.

                notify.props.msg = _('%(ERR)s when deleting %(2)s') % \
                    { 'ERR': err.strerror, '2': logfile }

Pootle specific tips

These are some tips/guidelines which would keep Sayamindu (who currently maintains the Pootle installation) happy ;-).

Do not touch anything inside your po directory

If you change anything inside the po directory (including the POT file), and push it to Git, it will create a conflict which has to be updated in the Pootle side manually. Try avoid doing this, If you see any issues, please ping Sayamindu (sayamindu at sugarlabs dot org) (you can also catch him on IRC, in channels like #sugar on Freenode with the nick unmadindu). If the changeset that you have is large, send him a patch, and he will apply that from the Pootle side manually and commit.

Try to keep the po directory in the top level directory of your repository

The various homebrew helper scripts which keep Pootle running properly make the assume that the po directory will be in the toplevel of the source repository. Try to avoid putting the po directory under a directory like i18n or such, as this will need yet another special casing in the helper scripts, making stuff more difficult to maintain.

Add user pootle to the committer list for your activity

If you have set up your activity on git.suagrlabs.org, please add the user pootle to the committer list so that po files can be updated for your project. (You add new committers from the button "Manage colaborators" in the right-hand menu on the repository mainline page (where you will find a link to http://git.sugarlabs.org/[your activity]/mainline).

Request to have your project included in pootle

Make a request by filing a ticket on bugs.sugarlabs.org. You should set Type to 'task' and Component to 'localization'. Please include a link to the project page on git.sugarlabs.org (or whatever other repository you use).