Desktop Entry Specification

[Asgeir Frimannsson]

Hi,

Rodney Dawes wrote:

>I'm not sure I understand your problem, but this looks like a question
>mainly for the intltool list. You want the translations for the desktop
>files to be looked up inside of a mo file, like say, gedit-foo.mo,
>rather than gedit.mo? I don't see any need to do things this way. What
>about the current method isn't ideal? I'd rather figure out what the
>exact problem is, rather than just going off and implementing a feature
>that you think might fix some behavior for you only.
>
>I've been on vacation all week, or I would have replied a bit sooner.
>
>I don't think as an end result, we should be splitting the .desktop
>files out into multiple files for translation purposes though, just so
>that you can split them up into separate packages.
>  
>
The main problem here is not in the translation process, but at runtime. 
It is becoming more common to split up packages and ship separate 
'language packs' - Only shipping the English version of the software, 
and then you get it localised by installing a language pack. For example 
you ship

myapp-1.0.rpm
and language packs:
myapp-l10n-ja-1.0.rpm
myapp-l10n-nb-1.0.rpm

So say you're running under Japanese (ja) locale, but do not have the 
Japanese language pack installed for myapp. You will still see the 
content of the Desktop entry in Japanese, as the localised resources for 
Desktop files for *all* locales are stored in the single .desktop file:

[Desktop Entry]
Encoding=UTF-8
Name= *English* MyApp Name
Name[ja]=*Japanese* MyApp Name
Comment= *English* MyApp Comment
Comment[ja]=*Japanese* MyApp Comment
Exec=/usr/bin/myapp

Preferably, it should be possible to separate out all localisable 
resources, which is fine for software messages (each language has one MO 
file) and documentation (separate docs for each language). This is not 
possible with Desktop entries and such.

There are two ways to implement support for this in the Desktop Entry 
Spec (as said before):
 1) By adding a variable such as TranslationDomain [1]:

[Desktop Entry]
Encoding=UTF-8
Name= *English* MyApp Name
Comment= *English* MyApp Comment
Exec=/usr/bin/myapp
TranslationDomain=myapp

Here, if the desktop entry does not find the localised message in the 
file, it will use gettext, to retrieve the message from the 'myapp' 
domain, if it exists. Or as Takao Fujiwara propose:

>1. If $USE_DESKTOP_ONLY == WITH_MO in /etc/X11/gdm/Xsessions but /usr/share/locale/$lang/LC_MESSAGES/*.mo is missed, UI is english.
>2. If found the translation in multilingual files, return the translation.
>3. If the translation is not found in multilingual files and $USE_DESKTOP_ONLY == WITH_MO, find the translation from a .mo file.
>4. If the translation is not found in both multilingual files and .mo, return the English message.
>  
>
 2) By having separate Desktop Entry files for translations:
 - as prompted in an earlier mail by Waldo Bastian...

How to implement this in intltool or other tools is off-topic for this 
list, what we should discuss however, is if such an approach is feasible 
for the Desktop Entry Specification.

cheers,
asgeir

[1] http://udu.wiki.ubuntu.com/LanguagePackRoadmap