Desktop Entry Specification

[Takao Fujiwara - Tokyo S/W Center]

Carlos Perelló Marín wrote:
> El mar, 07-06-2005 a las 10:30 +0100, Mark McLoughlin escribió:
> 
>>On Fri, 2005-06-03 at 20:36 +0200, Carlos Perelló Marín wrote:
>>
>>>Hi
>>>
>>>On Mon, 2005-05-23 at 07:32 +0100, Mark McLoughlin wrote:
>>>[...]
>>>
>>>
>>>>	My suggestion to Takao was that they change the way intltool-merge
>>>>works from a tool which merges translations into the .desktop files at
>>>>build time to a tool which merges individual translations from the
>>>>message catalog into the .desktop file at package install time.
>>>>
>>>>	i.e. your gnome-frobnicator-de package would
>>>>contain /usr/share/locale/de/LC_MESSAGES/gnome-frobnicator.mo and a %
>>>>post install scriptlet like:
>>>>
>>>>  $> intltool-merge --desktop-style --key Name --key Comment \
>>>>                    --textdomain gnome-frobnicator --lang de \
>>>>                    /usr/share/applications/gnome-frobnicator.desktop
>>>>
>>>>	and a %postun scriptlet like:
>>>>
>>>>  $> intltool-merge --desktop-style --key Name --key Comment \
>>>>                    --lang de --demerge \
>>>>                    /usr/share/applications/gnome-frobnicator.desktop
>>>>
>>>>Cheers,
>>>>Mark.
>>>
>>>that solution still needs that we add the translation domain value
>>>inside the .desktop file because a language pack will have a set of .mo
>>>files, and we still need the mapping between the .desktop file to the
>>>translation catalog.
>>
>>	Right, my example just had a bug. You'd also pass the translation
>>domain to intltool-merge via the command line.
> 
> 
> But if you do it at install time, you need to store it in any place.
> 
> We are talking about language packs, a language pack is not built from
> the source that has the .desktop file so we cannot take it from the
> build Makefile.
> 
> 
>>>Could we add that entry to the spec so both kind of implementations can
>>>be done? (the one that use the .mo files on runtime and the one that
>>>updates the .desktop files on installation time?)
>>
>>	I think it does make some sense to do this, but there are two problems:
>>
>>  1) It causes apps which display the menu to have to open every 
>>     application's message catalog. I'd like to have some idea what 
>>     kind of a performance hit that involves.
> 
> 
> I know you don't like the .mo idea, but the spec modification does not
> implies you will do it, you only get the translation domain information,
> then, you choose to use it at installation time or at build time.

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.

#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.

> 
> 
>>  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.

> 
> 
>>	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.

Thanks,
fujiwara


> 
> 
> Cheers.
> 
> 
>>Cheers,
>>Mark.
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>xdg mailing list
>>xdg at lists.freedesktop.org
>>http://lists.freedesktop.org/mailman/listinfo/xdg
>