Desktop Entry Specification

Takao Fujiwara - Tokyo S/W Center Takao.Fujiwara at Sun.COM
Wed Jun 8 08:16:39 EEST 2005



Carlos Perelló Marín wrote:
> El mar, 07-06-2005 a las 19:03 +0900, Takao Fujiwara - Tokyo S/W Center
> escribió:
> 
> [...]
> 
> 
>>I have the actual implimentation to use .mo files and I didn't notice the any performance delays on gnome-panel.
>>I got some information to treat this.
> 
> 
> Nice to know it.
> 
> 
>>#1. Specify the domain name in .desktop
>>#2. Change .mo file name or .desktop files to have the same names.
>>#3. Use only one .mo file for .desktop files.
>>
>>My implementation is #3. It's not so complicated against the current codes.
> 
> 
> 
> I think we should go for #1.

Thanks for the analysis.

> 
> The changes done upstream are trivial, nowadays GNOME and KDE are using
> already .po files to translate .desktop files. In fact GNOME installs
> already the translations as .mo files.
> 
> #2 is too intrusive.

Yes, You're right. However I heard a rumor about this. Now a person try sorting the .mo file names because the current .mo filenames are not made the 
format and some modules are hoo.mo, some are hoo-$version.mo and others are not same as the application names.
So I mean if there is the sorting issue which is NOT related with Desktop Entry, I think this option makes sense.

But if not, it's intrusive.


> 
> #3 requieres that you extract the strings from the .desktop file
> directly and create your own .po file. This solution is not intrusive at
> all, but it means that any distribution doing language packs (like SUN
> and Ubuntu, not sure if there are any others out there) will need to do
> it without reusing anything.

Also right. we have the similar situlation both are derived from the language packs but we need to think other situations.

One possibility is to use a environ parameters for the .mo, i.e. the default is specified one .mo USE_MO=hoo but it can be added as 
USE_MO=hoo,/usr/share/locale/*/LC_MESSAGES/3rd_app

But if it is trivial to have the domain names in .desktop, we should go for #1.

Thanks,
fujiwara

> 
> 
>>>
>>>> 2) It introduces a dependancy on GNU gettext to the desktop entry 
>>>>    spec.
>>>
>>>
>>>Well, it's not a hard dependency, it's optional so you can ignore it if
>>>you want in your implementation.
>>
>>I think to provide some translation options is important then the distributers can select prefered options.
> 
> 
> Indeed.
> 
> 
>>>
>>>>	We had several discussions about this and other related things at
>>>>GUADEC. I'll try and summarise all that in another mail.
>>>
>>>
>>>Yeah, please.
>>
>>I awaited you come back from GUADEC.
>>
>>
>>
>>>
>>>>>Attached, you have the proposed change to the spec.
>>>>>
>>>>>The diff has also a fix for the Icon type, the description of that field
>>>>>says that it should be a 'localestring' instead of just a 'string'.
>>>>
>>>>	I think Icon is intentionally a localestring - you might imagine an
>>>>icon having some text or a cultural reference. I don't think it would be
>>>>a good idea to have an icon like that and I haven't seen a localized
>>>>Icon key in practice but ...
>>>
>>>
>>>I think you misunderstood me. The spec defines Icon as a localestring
>>>but it shows it as a string so either the description or the type should
>>>be fixed.
>>
>>We need to translate all multilingual files; .desktop, .icon, .server, .kbd and etc as the product shipment so we would like to separate all 
>>multilungal types.
> 
> 
> Same here in Ubuntu, you are not alone (finally :-P)
> 
> Cheers.
> 
>>Thanks,
>>fujiwara
>>
>>
>>
>>>
>>>Cheers.
>>>
>>>
>>>
>>>>Cheers,
>>>>Mark.
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>xdg mailing list
>>>>xdg at lists.freedesktop.org
>>>>http://lists.freedesktop.org/mailman/listinfo/xdg
>>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>xdg mailing list
>>xdg at lists.freedesktop.org
>>http://lists.freedesktop.org/mailman/listinfo/xdg
> 





More information about the xdg mailing list