Interface translation

← Translations home

Introduction to PO file format

If you've never translated a PO file before, you will find its syntax very simple. The PO format is a really simple format, which probably at least partly explains its success and widespread use. The format is basically a hash list consisting of msgid and msgstr pairs, with the msgid being the original English string and key, and the msgstr being the translated value of it. Below is an example of a message.

#: gedit/dialogs/gedit-plugin-program-location-dialog.c:78
#: gedit/dialogs/program-location-dialog.glade2.h:2
msgid "Set program location..."
msgstr "Ställ in programplats..."

In addition to the msgid and msgstr parts, a message usually also has lines starting with #: that tell what source files and what lines the string used as msgid was extracted from. These lines have no syntactic value. They are only there as a help for translators and developers to know where a message came from.

A message in a PO file can be in one of essentially three different states. The message can be translated, fuzzy, or untranslated. A message counts as translated as soon as the msgstr part of it is non-empty. In a similar manner, an untranslated message is one where the msgstr is empty. The fuzzy state is special and essentially means that there is a translation in the msgstr part, but that this translation is most likely not entirely correct, and that it thus needs manual attention by a translator. A message can become fuzzy in one of two ways:

• The original string that the msgid represents was changed in the source code. A typo in the string may have been fixed or the string altered in some other way. The translator needs to check that the msgstr is still valid and make changes if necessary.
• A new string has been added to the source, and the string is similar (but not identical) to the msgid of an already existing, translated message. Then the msgstr of that message will be automatically reused for the new message, but the new message will also at the same time be marked fuzzy so that the translator knows there is some difference that he or she needs to adapt the translation to match.

There is always one special message in each valid PO file: the PO file header. It is encoded with the msgid for the empty string ("") as the key, and the actual header values are in the msgstr part. This unfortunately means that if you mark an empty string for translation, you will get the entire PO file header back as the ‘translation’. In almost all cases this is probably not what you want. Hence, do not mark empty strings for translation.

Get the PO file for your language

Download the .po file for your language from here.

If a .po file for your language does not yet exist, then you will have to get an empty template file to start a new translation. You may also need to use the updated template file (mentioned blow) to bring the .po file up to date with new strings introduced in the UI.

The most straightforward way to obtain the inkscape.pot template is to download it from here.

Alternatively, you can checkout the full BZR project repository and generate the project template. Information on how to get the source tree can be found here. Then, you have to follow some steps in order to generate the template:

1. ./autogen.sh
2. ./configure
3. Enter the ‘po’ directory: cd po
4. Generate the current PO template: intltool-update --pot

To make an absolutely up-to-date translation (in case the PO file in BZR is not up-to-date enough):

1. Update your local copy of Inkscape in the usual way: bzr pull
2. Merge your existing translations into the new POT file (inkscape.pot):
   msgmerge your_latest_PO_file inkscape.pot > new_PO_file

If you want to update ALL .po files in po/, cd there and run:

make update-po

Now that you have an empty PO template, you can start translating the messages.

You can track progress of all Inkscape translations here.

Tools for translators

You can edit PO files from any plain text editor, since they are simple text files. However, many useful tools have been developed to provide a simple experience translating PO files.

Recommended:

• Poedit
• Lokalize

You might also try:

• Emacs' po-mode (contained in the gettext distribution; the version in po-utils is old)
• gedit (installed on GNOME desktops, has a syntax highlight mode for PO file syntax)
• Virtaal — cross-platform PO editor that is clean, simple to use yet powerful
• Gtranslator

And last but not least, gettext utils, which are installed on every Linux distribution. You can see a complete reference too from installed info pages by running the command:

info gettext

A few important things to remember

• Some strings that can be ambiguous or having several meanings according to different contexts may have a context prefix : ‘Context|Amibiguous string’. In this case, simply translate ‘Ambiguous string’, the ‘Context|’ string is just a not to translate indication. (Some info on how to disambiguate a string can be found here.)
• After translating a fuzzy string (one that is marked with a ", fuzzy" comment), please remove its "fuzzy" tag — otherwise this translation will be discarded by the build process, meaning that this string will show up untranslated.
• Before publishing your work (after you have finished updating the PO file), please update the "PO-Revision-Date" and "Last-Translator" fields in the PO file header.

If you use a translation software, it may automatically deal with the last two points for you (see its preferences).

Review

This is the start of a list of places to get translation reviews done. So far:

• http://www.linux.it/tp/

Verification

Before submitting your file in the patch tracker, please make sure it is valid.

• Make sure the file is encoded in UTF-8.
• Make sure it is a valid po file and obtain some statistics about it: simply run msgfmt --statistics -cv translation_file.po from a command window.
• Make sure it is correctly formatted: run check-markup translation_file.po from a command window and verify it doesn't output any error message. The ‘check-markup’ Perl script can be found in the /po directory of Inkscape svn trunk.

Locale Testing

Before reporting that a locale doesn't work in Inkscape, you need to make sure that your system has that locale correctly set up. To do this, you need to generally find a way to run ‘locale-gen’ (under Debian/Ubuntu this is via dpkg-reconfigure locales). If you set both the LANG and LANGUAGE variables and check a regular tool, you should see the correct language for both the libc error (first line) and the tool error (second line):

LANG=es_MX LANGUAGE=es_MX ls -z
ls: opción inválida -- z
Pruebe `ls --help' para más información.

If it reports the regular C messages, your locale has not been correctly configured, and you'll need to find the right way to run ‘locale-gen’ for your distribution:

LANG=es_ES LANGUAGE=es_MX ls -z
ls: invalid option -- z
Try `ls --help' for more information.

Submit finished work

Upload your work via the Launchpad bug tracker. Report a new bug and attach your translated file to it. Don't forget to compress your file before uploading it.

Additionally, you may send a message to Inkscape's translators mailing list.

Programmers

Please make sure you use dgettext for any pluralized strings.

Windows installer translation

Strings for Windows installer are saved in *.nsh files. Each translation has its own file located in packaging\win32\ directory in Inkscape trunk. Get this file in similar way of getting *.po file.

Translating

1. Get the file according to your language. If there is not such a file, copy english.nsh file and rename it to yourlanguage.nsh.
2. Translate strings in the file.
3. Change header information in yourlanguage.nsh file (language name, local ID, windows code page and authors list) to proper values.

Testing the translation

This part is optional but recommended.

1. You need NSIS installer and run the make -f Makefile.mingw dist command after successful compilation of Inkscape. This command prepares binary of Inkscape for installer creation.
2. Add filename of your file to inkscape.nsi file, "STRING LOCALIZATION" section, "Language files" subsection.
3. Right click on the inkscape.nsi file and choose ‘Compile NSIS Script’. The installer compilation will start.
4. When the installer is finished, run it to test translations of strings in Installer and Uninstaller parts.
5. If the translation is tested successfully, submit it to the Launchpad bug tracker and mark as ‘Translation’. If you haven't tested your translation yet, submit it too but enter this information to the patch information. You will be contacted about its correctness.

Default template translation

• To translate the default template, modify the default.svg file and save it as default.xx.svg where ‘xx’ is the ISO code of your language. You will find the current template here.
• You need to modify your PO translation as well to use your localized default template. Look up for a msgid "default.svg" on the PO file and translate it accordingly to the file name of the localized template.
• To test it, save it to the proper location and restart Inkscape. Default document should be now based on your localized template (this is valid if your system is properly set to your locales).
• Upload default.xx.svg to the patch tracker.

To translate the default template, you can use Inkscape as well as any UTF-8 encoding capable text editor.