Translations of .desktop files are not loaded

[David Planella]

Binary package hint: netbook-launcher

In the Karmic UNR nearly all shortcuts to applications in the right panel and all categories in the left tabs panel appear untranslated.

Those translations come from each application's .desktop files, which in Ubuntu are stripped from the original files and put into the application's .mo files shipped in the language packs. Those translations are then not read from the .desktop files themselves, but loaded at runtime from the .mo files.

Due to this, glib has been patched in Ubuntu for some time in order to implement this functionality (through which e.g. gnome-panel loads the .desktop file translations), and in fact the Jaunty version of UNR did correctly load the .desktop translations this way.

The attached screenshot shows the effect of this bug: untranslated application shortcuts and menus on the left with a Catalan locale. Note though, that pressing Alt+F1 to show the main menus in gnome-panel displays all translations correctly.

Note that the netbook-launcher translations have not yet been released in the language packs, but I believe this bug is not directly related to this, but rather to how the .desktop file translations are loaded.

[Neil J. Patel (njpatel)]

Weird, I see this, but am having a worse problem that only a very small subset of strings are translated (not even the gnome-menu!) Maybe the LANG variable isn't being set properly, because if launch the launcher form my desktop like:

$ LANG=ca_ES.utf8 netbook-launcher -w

It works fine (karmic desktop).

[David Planella (dpm)]

Just for the record, the locale settings on the netbook where the bug can be reproduced are:

$ locale
LANG=ca_ES.UTF-8
LANGUAGE=ca_ES.UTF-8
LC_CTYPE="ca_ES.UTF-8"
LC_NUMERIC="ca_ES.UTF-8"
LC_TIME="ca_ES.UTF-8"
LC_COLLATE="ca_ES.UTF-8"
LC_MONETARY="ca_ES.UTF-8"
LC_MESSAGES="ca_ES.UTF-8"
LC_PAPER="ca_ES.UTF-8"
LC_NAME="ca_ES.UTF-8"
LC_ADDRESS="ca_ES.UTF-8"
LC_TELEPHONE="ca_ES.UTF-8"
LC_MEASUREMENT="ca_ES.UTF-8"
LC_IDENTIFICATION="ca_ES.UTF-8"
LC_ALL=

Also, switching to classic mode in the same netbook and then executing

$ LANG=ca_ES.utf8 netbook-launcher -w

presents the same problem (untranslated .desktop files in netbook-launcher, but translated on the context menu which appears after pressing Alt+F1)

[Neil J. Patel (njpatel)]

David, does the Alt+F1 menu show all the correct translations, including those for applications? I'm only seeing translations in that menu for desktop files with translations in them (like openoffice). I'll try a clean install of tomorrows image and report back here on my findings.

Also, could you see what happens with a different language? I tried Catalan and Russian, and got the same issue with both (no translations in either the launcher or gnome-menu, and only some translations across the desktop). Thanks!

[David Planella (dpm)]

Hi Neil,

Yes, Alt+F1 shows the correct translations for both the menu categories and the application entries in the menu. The applications themselves are also translated. You can see this in the screenshot:

* The "Sound and Video" menu category appears:
  * untranslated in the left panel (netbook-launcher)
  * translated ("So i vídeo") in the Alt+F1 context menu (is gnome-panel loading this?)

* Inside the "Sound and Video" menu, taking Brasero as an example, its name (from /usr/share/applications/brasero.desktop) appears:
  * untranslated in the left panel (netbook-launcher)
  * translated ("So i vídeo > Enregistrador de discs Brasero") in the Alt+F1 context menu (is gnome-panel loading this?)

I have also been able to reproduce this with another language (German).

The fact that the translations of .desktop files containing static translations (i.e. textual translations inside the .desktop file) are loaded correctly, but not those contained in .mo files (e.g. the translations from gedit.desktop in Ubuntu are stripped and put in gedit.mo, to be loaded at runtime), seems to confirm the suggestion that netbook-launcher does not load gettext translations at runtime.

Some of the files containing static translations in the .desktop files are:

/usr/share/applications/tomboy.desktop
/usr/share/applications/f-spot.desktop
/usr/share/applications/ekiga.desktop
/usr/share/applications/openoffice.org-*.desktop
/usr/share/applications/scim-setup.desktop

These are the only ones which appear translated, but in fact they shouldn't contain translations (they should have been stripped by pkgbinarymangler, so probably separate, unrelated bugs should be opened for each one of them - see See https://wiki.ubuntu.com/Translations/TranslationLifecycle).

[Neil J. Patel (njpatel)]

I understand that the translations are stripped from the desktop files and put in separate packages. The thing is that we use the same desktop-file reading library as the gnome-panel menu does, libgmenu, and the same code works fine on Jaunty, so I'm a bit worried as to where the issue is creeping in. As I was unable to get my gnome-panel-menu to read the translations, I was wondering if it was a system-wide issue, but as you do have translated menus, there's obviously something wrong elsewhere.

I've been unable to test a clean image until today, but I'll do that now and report my findings.

[Neil J. Patel (njpatel)]

I've tried out a fresh image and am seeing exactly what you see david, so i'll try and figure out what's going on.

On a side-but-related-note, I can't find a netbook-launcher.mo anywhere in /usr/share/locale or /usr/share/locale-langpack. It looks like the translations strings for the launcher itself are missing. I've spoke to Loic about this and he's recommended asking you to see if you know what's going on (so consider this me asking :).

[Neil J. Patel (njpatel)]

Okay, so this isn't an issue in the launcher at all!

After inspecting all parts of the launcher, and wondering a lot about why it works if I compile the launcher from scratch, but not if I use the launcher in the archive, I've figured it out:

The missing netbook-launcher.mo in /usr/share/locale-langpack/$LANG/LC_MESSAGES means that when the launcher initially set's up it's translations using the bindlocaledomain methods etc, they fail without warning, but also screw up translations in the rest of the program, which effects gnome-menus.

On my netbook, with a clean install of UNR, I copied netbook-launcher.mo for the russian language from an isolated install in opt/ to /usr/share/locale-langpack/ru/LC_MESSAGES/netbook-launcher.mo and then restarted the launcher in LANG=ru_RU.utf8. Everything worked perfectly.

We need to figure out what is happening to the launchers .mo files...why aren't they being included in the langpacks?

[Данило Шеган (danilo)]

They are likely not included in language packs because they are not part of Ubuntu yet (one would have to manually add them in when packages are being built, and that's something you'd have to discuss with Arne to get it going).

They are currently blocked for import, but that's something that has probably been decided between Kyle and Arne.

[Данило Шеган (danilo)]

And a link with the import queue: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports

[Kyle Nitzsche (knitzsche)]

Данило Шеган (Danilo) and Neil are correct that import of translations of unr packages into karmic language packs is currently disabled. This is in place to allow Ubuntu Translators to *complete* translation work in the *upstream* projects (for example lp.net/unr/netbook-remix-launcher) before import to karmic. This phase of translation work is scheduled to be completed on Sep 4, 2009.

Translation in the upstream projects is preferable to minimize effort required to get downstream translation changes (those done in ubuntu LP project) into the upstream project(s) and to enable other downstream projects to have complete translations as early as possible.

Anyone interested in further details can see the blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-unr-karmic-translations.

[Neil J. Patel (njpatel)]

Okay, thanks Kyle/Danilo. Who knew that a missing .mo file can cause these effects! At least we know what the issue is now and it can be fixed once the translations are ready.