Naming of a launcher

- In most cases...
The interface -name of a launcher, in most cases, is defined in the (first) line, starting with:


of its corresponding .desktop file:

enter image description here

- Localized naming from the .desktop file
For localized naming, some applications (like Thunderbird) use extensive lists with launguage- specific names:

enter image description here

- But where is the localized name defined if it's not defined in the .desktop file?
In some cases however, the icon is named differently, but the name is nowhere in the .desktopfile:

enter image description here

Where is this name connected with the .desktop file?


A few years ago, I wrote the QLE Quicklist editor. That version used the International interface names. I am rewriting it now in Gtk+, but need to find a reliable way to display the localized launcher names.


No doubt, this question is related to this one, but not exactly a dupe; I'd like to know where the information is stored to fetch the localized name(s) myself.


As a proof, the content of gnome-screenshot.desktop, named Scermafdruk localized (translated: Screenshot). No trace of the string "Scermafdruk" in the file...


[Desktop Entry]
Comment=Save images of your screen or individual windows
Exec=gnome-screenshot --interactive

[Desktop Action Screen]
Name=Take a Screenshot of the Whole Screen

[Desktop Action Window]
Name=Take a Screenshot of the Current Window
Exec=gnome-screenshot -w

[Desktop Action Area]
Name=Take a Screenshot of a Selected Area
Exec=gnome-screenshot -a
  • They have to be. Have you checked both locations for .desktop files? One is the obvious /usr/share/applications and the other is your personal folder in ~/.local/share/applications/. If a file is present in both, then your user-specific entry is used I believe. – Potaito Apr 18 '16 at 12:10
  • That's rather puzzling, I'm also only aware of these two locations for the .desktop files. Maybe someone else knows more. Did you check if maybe the name of the .desktop file has been localized as well? (Would not be the smartest thing to do and I doubt it) – Potaito Apr 18 '16 at 12:16
  • Have you tried recursively grep everything in /usr ? – Sergiy Kolodyazhnyy Apr 18 '16 at 12:46
  • @Serg good one! How could I forget, running now, I will do the same in my home dir. Have to teach now, I will look for the outcome when I am ready :) – Jacob Vlijm Apr 18 '16 at 12:53
  • 3
    "Binary file /usr/share/locale-langpack/nl/LC_MESSAGES/gnome-screenshot.mo matches". – Jos Apr 18 '16 at 12:56

As you found out yourself while testing, the entry responsible for such behavior is:


From https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging:


Translations of desktop entries (.desktop files) are also stripped out and included in language packs.

Contrary to what other distros do (except currently OpenSUSE), the translations are not expected to be in the .desktop files themselves (static translations), but rather in the same .mo file of the application, from which they are then loaded at runtime. We do this in order to be able to translate them in Launchpad and to ship them in language packs, so that they can be edited and updated by Ubuntu translators.

The runtime loading is done by patches to patch glib and kdelibs, which recognises the the X-Ubuntu-Gettext-Domain additional key we add to all Ubuntu .desktop files and adds gettext support when loading them. Note that if the .desktop file already contains translations, these static translations will be preferred.

Adding the X-Ubuntu-Gettext-Domain= key is done during build time in the packaging either automatically with the package build system or (increasingly rarely) with patches.

In other words, that means that the patched version of glib and kdelib on Ubuntu use the X-Ubuntu-Gettext-Domain key to add gettext support at runtime if a translation is not available by other means in the desktop file, translation which is retrieved from the application's .mo file.

Notice also that this implies that the support for the X-Ubuntu-Gettext-Domain key is a Ubuntu-specific implementation, and that desktop files using the X-Ubuntu-Gettext-Domain are only portable across distributions that use the same patched version of glib / kdelib.

| improve this answer | |
  • Excellent and complete answer. One question on "we add to all Ubuntu .desktop files and adds gettext support when loading them" I guess you don't mean all Ubuntu applications include the string in their .desktopfile? (Thunderbird doesn't for example, and there are quite a few more) – Jacob Vlijm Apr 19 '16 at 15:09
  • @JacobVlijm That I don't know, I didn't write the page on the Wiki :) However it seems like most of them do have the entry, while only a few do not (run grep -r '^X-Ubuntu-Gettext-Domain' /usr/share/applications to see which desktop files which have it and grep -lR '^X-Ubuntu-Gettext-Domain' /usr/share/applications to see which desktop files don't have it). I'd guess that either the Wiki is imprecise or we're reading that wrongly or they just forgot to add it. – kos Apr 19 '16 at 15:17
  • @JacobVlijm Typo, I meant grep -LR '^X-Ubuntu-Gettext-Domain' /usr/share/applications to see which desktop files don't have it. – kos Apr 19 '16 at 15:26
  • I have 139 .desktop files in/usr/share/applications without the string. I think the link is a bit optimistic on the implementation :) – Jacob Vlijm Apr 19 '16 at 15:29
  • @JacobVlijm Perhaps I found the reason, see here, very fist paragraph: "Packages in main and restricted don't contain translations (*.mo) files themselves, they are stripped during the build on the Launchpad buildds and put into language-pack-* packages instead. This is done in an attempt to bundle the translations you're interested in and cut down the occupied space.": I suppose packages outside of main and restricted are not bound to include the key? – kos Apr 19 '16 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.