Tips for translators of the GRAMPS program.
- 1 Tips for translators
- 2 Hard to Translate Phrases
- 3 Advanced issues
- 4 Translating man pages
Tips for translators
Translating GRAMPS into a new language means translating English strings used in the GRAMPS interface. To put it shortly, this amounts to
- obtaining the gramps.pot file with the strings to be translated,
- translating the strings in the template, and
- getting the translated file uploaded into gramps SVN repository.
Another avenue of translation is translating the documentation. This is a different and lengthy process and it is decribed in our Translating the manual page. Here we will concentrate on the interface translation only.
gramps.potfrom GRAMPS SVN repository, see the introduction to SVN.
- Look for
gramps.potin the directory
gramps2/poor if you looking for the trunk version look for
gramps.potin the directory
gramps.potto the file named
lang.po, according to the language you are translating into (
ru.pofor Russian, etc.)
- Use GTtranslator (GNOME), KBabel (KDE), Emacs po-mode, pootling (GNU/Linux, windows), poedit (GNU/Linux, OSX, windows), or any similar tool designed for translating
.pofiles. If you do not like any of these tools, you can use any text editor to translate messages.
- Even though GRAMPS uses UNICODE (UTF-8) for its character set, you may use your native character set for your translation. Just make sure you specify the character set you are using in the
Content-Typeline in the
.pofile. GRAMPS will handle the conversion to UNICODE.
- In the directory
gramps30/porun the command:
makeIf there are errors in your po file, this will fail and give you an error message. You should correct these errors. If you have trouble understanding the error, try to run the next test, which might give a more verbose output.
- In the directory
gramps30/porun the command:
./check_po lang.powhere lang is your language code. This will give you errors in your translation, information on badly translated phrases, ... the output could resemble something like this..
- File: nl.po
Template total: 3816
PO total: 3671
%s mismatches: 0
%d mismatches: 2
%() name mismatches:9
%() missing s/d: 0
Runaway context: 0
XML special chars: 0
Last character: 15
Shortcut in msgstr: 16
PO Coverage: 99.67%
Template Coverage: 95.89%
%d mismatches --------------
You can see that there are 3816 strings to be translated and the coverage is around 96 %. There are still 12 untranslated strings and some 120 fuzzies. The last one can be ok, but should be checked. Additional information shows e.g. that in 15 strings there is a mismatch with the 'last character':
last character not identical ---------
msg nr: 98, lineno: 602
msgid "Could not make database directory: "
msgstr "Kon geen gegevensbestandsmap aanmaken"
This is very valuable information, because you can easily see what the problem is, even if you do not understand the language! Clearly the last characters must be ": "
- In the directory
gramps30/porun the command:
msgfmt --statistics lang.powhere lang is your language code. This should not throw an error.
- Basically this gives the same info in a condensed format: 3533 translated messages, 125 fuzzy translations, 12 untranslated messages.
- Currently, formatting is performed during build time, so you should not have to worry about it. The translated
.pofile is the product of your work. Check it into SVN if you obtained the permission to do so, or email it to Don Allingham or Alex Roitman otherwise.
Updating your translation
If you have submitted a translation, changes are that after some weeks/months, new strings are added to GRAMPS, implying you need to update your translation file.
Assuming you have obtained originally the GRAMPS source tree as explained in Brief introduction to SVN. Now:
- Update your gramps tree from SVN. This can be done by executing the command
svn upfrom the root GRAMPS svn directory. This will download an updated
- Use your outdated translation to translate the strings that did not change:
msgmerge lang.po template.po -o newlang.poor
msgmerge --no-wrap lang.po template.po -o newlang.powhere
langis your language code. The
--no-wrapoption will prevent changes due to automatic word wrapping, use it if your previous po file was constructed like that. The
--no-wrapoptions allows for more readable SVN diffs.
- Translate all untranslated messages in
newlang.po. When you are sure everything is right, rename
lang.poand check it into SVN as you did with the original file.
- If command
msgmergeis not available on your system, you have to install the
}gettextpackage. For windows users.
There is also the make target that does the following:
- Create new
gramps.pottemplate from the source code files
- Updates each
pofile in the source tree
It may be an overkill for you, but if you feel like using it, you can run:
po directory. This assumes that you have already succesfully configured the source.
Testing your update
You can test your update easily with the above mentioned check_po file. If you downloaded this file, just do:
python check_po newlang.po
. If everything is ok, the output will be something like this:
- File: newlang.po
- Template total: 3075
- PO total: 3075
- Fuzzy: 0
- Untranslated: 0
- %s mismatches: 0
- %d mismatches: 0
- %() name mismatches:0
- %() missing s/d: 0
- Runaway context: 0
- XML special chars: 0
- Last character: 0
- Shortcut in msgstr: 0
- PO Coverage: 100.00%
- Template Coverage: 100.00%
Installing your translation
You want to use the new translation immediately, and systemwide? You can by installing just the contents of the po directory, but you will need to build the source first, so:
./autogen.sh make cd po make --prefix=/usr/share install #as root !
This should install your translations to
/usr/share/locale/xx/LC_MESSAGES/gramps.mo, with xx your language. You could off course copy your files manually to that dir with the gramps.mo name.
Make sure you only install from within the po directory, or you will install the development version of GRAMPS, which is not supported and for testing only!
Hard to Translate Phrases
Some things are just hard to translate. Below are a few of the more difficult items, along with some suggestions on how to handle them.
The Church of Jesus Christ of Latter Day Saints (a.k.a. Mormons) maintains a lot of genealogy data. In the United States, they are probably the non-government organization with the most detailed records available. Genealogical research is important to the Mormon church. They are responsible for defining the GEDCOM format.
The LDS Church has some specific terminology that can present difficulty in translating. There are two approaches to handling the information.
- If the LDS Church has a presence in your country, contact the LDS Temple in your area and ask them what the correct terminology is in your native language
- If the LDS Church does not have a presence in your country, it would probably be safe to simply not translate the phrases.
These terms include:
- LDS Ordinance names:
- Sealed to Parents
- Sealed to Spouse
- LDS Baptism
- LDS Status names for Ordinances:
- BIC (Born In the Covenant)
- DNS (Do Not Submit)
- DNS/CAN (Do Not Submit/Previous sealing cancelled)
Format line parameters
Format line parameters such as %s and %d should not be translated. The order of these parameters should not be changed. Examples:
Long widowhood: %s was a widow %d years.
Translation (using Backward English as an example :-):
Gnol doohwodiw: %s saw a wodiw %d sraey.
Named format line parameters such as %(something)s and %(something)d also should not be translated. Feel free to change the order of named parameters to correctly phrase the message in your language. Also, use hints provided by the names. Examples:
Baptized before birth: %(male_name)s born %(byear)d, baptized %(bapyear)d.
Translation into Backward English:
Dezitpab erofeb htrib: %(byear)d nrob %(male_name)s, dezitpab %(bapyear)d.
In the above example, the verb "born" should be in masculine form (if verbs in your language have gender, that is), since the person born is apparently a male.
In some cases, two different concepts can be expressed by the same word in English and yet require different translations. For example, the title of the book and the nobility title of the person are expressed by the same Title word. However, in other languages different words are needed to describe the book title and the person's title.
To mitigate such problems, a context can be added to the translation string. A context-enabled string has a vertical line separating the context from the string:
The correct translation should not include either the context or the separator. The context is to give the translator idea of what the string means. However, both the context and the separator must not be in the translated string, so in backward english the above is translated into
Translating relationships is not done within the
.po files, except for occasional
mother strings here and there in the interfaces and reports. Complete translation of all relationships for the language/culture is done inside a relationship calculator plugin.
In short, the need for a plugin comes from the impossibility to translate "first cousin twice removed" in languages such as, e.g., German or Russian. See the Relationship Calculator page for details on why and how to create such a plugin.
Handling date translation is not entirely done within the
.po files. Complete handling of date translation for each language/culture is done inside a dedicated date handler module.
The need for a separate module comes from the requirements to handle culture-specific parsing and displaying of dates. For example, the month and day order is different between most European countries and the US. Also, each language has its own set of acceptable modifier and qualifiers for the date: things like "from X to Y" or "between X and Y" may have different word order. Same with "around", "calculated", "estimated". Add to this calendar names, and you have a compelling need for a dedicated module. See the Date Handler page for details on why and how to create such a module.
Translating man pages
You can also translated the man pages into your own language.
For the development (trunk) version you can find the required starting files under the directory (/trunk)/data/man. You will find the files
First off all you must make a directory for your language under data/man.
where xx is your languagecode (fr for French, sv for Swedish, etc.) You should use SVN. See the introduction to SVN. Then do
svn add xx svn commit -m "xx dir for man pages" xx
This will add the xx dir under svn revision control and upload the new dir.
Next step is to copy the Makefile.am and gramps.1.in from data/man to your new directory. Translate all relevant strings in the man/xx/gramps.1.in file. Change the file Makefile.am:
- add the line mandir = @[email protected]/xx
- change the line && CONFIG_FILES=data/man/xx/[email protected] $(SHELL)
Next step: change the file data/man/Makefile:
- add xx to the line SUBDIRS = fr nl sv
The final step is to alter the file Configure.in :
- add data/man/xx/Makefile to the line AC_CONFIG_FILES([
Because you added new files, SVN requires that you set the correct propset for those files. Two things are to be done.
svn propset svn:mime-type text/plain xx/gramps.1.in xx/Makefile.am svn propset svn:eol-type native xx/gramps.1.in xx/Makefile.am
You could also in the config file of subversion ( HOMEDIR/.subversion/config) enable the auto-prop feature (enable-auto-props = yes) and uncomment the relevant lines in the [auto-props] section. All changes must be committed and do not forget to change the ChangeLog file.
You should see no errors when you run the