- 1 Introduction to PO file format
- 2 Get the PO file for your language
- 3 Tools for translators
- 4 A few important things to remember
- 5 Review
- 6 Verification
- 7 Locale Testing
- 8 Submit finished work
- 9 Programmers
- 10 Windows installer translation
- 11 Default template translation
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:
- Enter the ‘po’ directory:
- Generate the current PO template:
To make an absolutely up-to-date translation (in case the PO file in BZR is not up-to-date enough):
- Update your local copy of Inkscape in the usual way:
- 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:
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.
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
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:
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).
This is the start of a list of places to get translation reviews done. So far:
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.pofrom a command window.
- Make sure it is correctly formatted: run
check-markup translation_file.pofrom 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.
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.
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.
- Get the file according to your language. If there is not such a file, copy english.nsh file and rename it to yourlanguage.nsh.
- Translate strings in the file.
- 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.
- You need NSIS installer and run the
make -f Makefile.mingw distcommand after successful compilation of Inkscape. This command prepares binary of Inkscape for installer creation.
- Add filename of your file to inkscape.nsi file, "STRING LOCALIZATION" section, "Language files" subsection.
- Right click on the inkscape.nsi file and choose ‘Compile NSIS Script’. The installer compilation will start.
- When the installer is finished, run it to test translations of strings in Installer and Uninstaller parts.
- 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.