Desktop Entry Specification

[Takao Fujiwara - Tokyo S/W Center]

Hi All,

I have been thinking the solution to update multilingual files dynamically but we have several problems.

On the other hand, I found another way to separate multilingual files.


Solution 4. Separate multilingual files and use configuration files to switch locales.

  - .desktop files (menu entries)

The idea is to use /etc/xdg/menus/applications.menu

<AppDir>/usr/share/applications/$LANG</AppDir>
Example implementation is we use /usr/share/applications/C for C locale and use g_get_language_names () to decide the current locale.


gnome-menus-xx-g11n-separation.diff: Patch for .desktop

  - .server files (bonobo components)

We can use /etc/bonobo-activation/bonobo-activation-config.xml and the way is as same as .desktop.

  - .schemas files (gconf key descriptions)

We can use /etc/gconf/2/path

  - .icon files (nautilus emblem names)

I have no ideas.


What do you think? It needs a small patch by module to handle $LANG but I expect it's easy implementations.
I created the sample patch and it works fine.

Thanks,
fujiwara

Takao Fujiwara - Tokyo S/W Center wrote:
> 
> 
> 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
>>
>>
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>