The “.desktop” file format is simple, but it is a pain for translation tools such as gettext, which assumes that every output file (MO file, Java .properties file, etc) is generated for a single locale.
A translated .desktop file looks like:
[Desktop Entry] Type=Application Name=foo Name[fr]=(French translation of "foo") Name[de]=(German translation of "foo") ...
As you see, it mixes up the translations in multiple locales. This does not naturally fit in the current xgettext/msgfmt workflow. Traditionally, application developers have to use a wrapper script (aka intltool) to deal with this.
On the other hand, there has been a long-standing request to support the .desktop file format in gettext, to eliminate the extra dependency. So, I decided to give it a try. With the current patch set, you can extract translatable strings with xgettext as usual:
$ xgettext yourapp.desktop -o yourapp.pot
It doesn’t have much difference with intltool-extract, but xgettext properly interprets character escapes (\s, \n, \t, \r) and lists (foo;bar;baz;). This could prevent translation errors such as missing ‘;’ at the end of a list value.
Then, you can merge translations back to a .desktop file with msgfmt, one locale at a time:
$ msgfmt --desktop --template=yourapp.desktop.in --locale=fr -o fr.desktop fr.po $ msgfmt --desktop --template=fr.desktop --locale=de -o de.desktop de.po ... $ msgfmt --desktop --template=yo.desktop --locale=zh -o yourapp.desktop zh.po
It could be inefficient, as it requires writing entire file for each locale, while intltool-merge processes multiple locales at once. However, I don’t think it would be an issue, since .desktop files are usually small.
I’d like to land this in the next release, so GNOME3 applications can be localized without intltool (perhaps you might remember that gettext recently got support for GtkBuilder and GSettings schema). I’ve created a sample project using those features, based on GTK+ application tutorial.
