Some translatable files do not use gettext at runtime, but rather contain all translations in a single file, like .desktop and .directory files. We want to find a robust and generic way to update these translations through Rosetta and language packs.


Currently the language packs contain only translations for desktop applications that use gettext. However, there are many more translatable items in Kubuntu. Our goal is to extract all translatable contents from application packages, import them into Rosetta, and ship them into language packs so that they can be updated after a release and benefit from Rosetta updates.

Use cases

  • Sjoerd adds a Dutch translation to a menu entry of a Breezy application in Rosetta. Breezy users should get this new translation with the next language pack update.


This specification deals with the KDE part. The Gnome counterpart is specified in LangpacksDesktopfiles.


The KDE library that evaluates desktop/server/directory files should use gettext() to translate entries since the application's *.mo files already ship the translations.

In the past we proposed the extension of the FreeDesktop standard to support an additional field TranslationDomain, so that Gnome, KDE, and other implementations can find the matching .mo file at runtime to get additional translations from it. However, since this has been rejected upstream, we will use our own Ubuntu-specific field for this.

Most packages that are of interest to us use cdbs and or a copy of local to the package, thus modifying will already cover a very large percentage of packages.


description files

The tasks are to extract the strings from the .desktop files into .po files and add the translation domain (as value of the new field X-Ubuntu-Gettext-Domain) to the .desktop/.directory files. This will be done using a copy of the scripts at modified to add the translation domain. The scripts are and findfiles.

We will modify to create the foo_desktop.po files using and these will be in the source build to be picked up by rosetta the same as other .po files.

KDE library changes

KConfig will need an i18n call to find the translation and fall back to the .desktop file if the .po does not contain a translation. i18n is done by KLocale and we will need to be careful not to create recursion between KConfig and KLocale.

Outstanding issues

  • Ubuntu might change to use one large .po file for all the .desktop files, this would simplify the creation notably.
    • I don't think we should do this. It breaks context and if it's for performance problems, we could try to figure a way to generate such big .po file after exporting it from Rosetta. CarlosPerelloMarin

LangpacksDesktopfilesKDE (last edited 2008-08-06 16:16:29 by localhost)