Native “.desktop” file support in gettext

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]
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 --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.

6 Replies to “Native “.desktop” file support in gettext”

  1. Thanks for the great work. Keep in mind that things like the “Keywords” entry is unlikely to be translated in a 1-to-1 fashion. The English and the translation might include synonyms, which might be less or more in certain languages. I think the syntax should simply be checked (to ensure that there is no missing “;” at the end, for example).

    1. It is not supported (yet?). In a typical translation workflow, I suppose all translations are maintained in PO format, and thus no need to merge translations back from a desktop file.

      What’s your use-case?

      1. If one already has localized .desktop files it will need a tool to convert them to .po. It will only probably to use it once.

Leave a Reply

Your email address will not be published. Required fields are marked *