Desktop Entry Specification

[Mark McLoughlin]

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.

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

  2) It introduces a dependancy on GNU gettext to the desktop entry 
     spec.

	We had several discussions about this and other related things at
GUADEC. I'll try and summarise all that in another mail.

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

Cheers,
Mark.