Desktop Entry Specification

[Asgeir Frimannsson]

Hi,

Mark McLoughlin wrote:

>Hi,
>
>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
>>
>>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, 
>>    
>>
>
>	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.
>  
>
Reducing disk space or CPU usage is not the issue here. Inconsistent 
desktops (partially translated) is. In addittion, Supporting language 
packs means distributors (and language teams) can provide language packs 
*after* the software is released.

>>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]:
>>    
>>
>
>[snip]
>
>  
>
>> 2) By having separate Desktop Entry files for translations:
>> - as prompted in an earlier mail by Waldo Bastian...
>>    
>>
>
>[snip
>
>	and
>
>  3) Use a translation tool which can merge the translations into the
>     .desktop files (from the message catalog) at package installation
>     time:
>
>  http://lists.freedesktop.org/archives/xdg/2005-May/006920.html
>
>     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.
>
>  
>
Sorry, accidentaly didn't see this mail as I read through the thread. 
Yes, I totally agree, this approach with merging translations at 
install-time in some way would be the most ideal and feasible approach.

cheers,
asgeir