Desktop Entry Specification
markmc at redhat.com
Wed May 25 10:08:52 EEST 2005
On Wed, 2005-05-25 at 16:33 +1000, Asgeir Frimannsson wrote:
> 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
> and language packs:
> 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,
So, when I discussed this with Takao before, I was very surprised that
the fact that you see some Japanese translations in the ja locale when
you don't have the language pack installed was considered a problem.
i.e. surely the idea of these language packs is to avoid installing
unwanted translations, rather than a mechanism to disable Japanese
messages in the ja locale?
If that's the case, the real bug we're trying to fix here is that when
you don't have the Japanese language pack installed, some extra disk
space (and memory/CPU when parsing) is used because the .desktop files
contain Japanese translations.
That puts the problem in some perspective ... for me, at least.
> 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 :
> 2) By having separate Desktop Entry files for translations:
> - as prompted in an earlier mail by Waldo Bastian...
3) Use a translation tool which can merge the translations into the
.desktop files (from the message catalog) at package installation
This doesn't require any extra support in the Desktop Entry spec
and is a pattern that could be followed for other file types
like .server files, GConf schemas etc.
More information about the xdg