Desktop Entry Specification

[Mark McLoughlin]

On Tue, 2005-06-07 at 11:44 +0200, 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:

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

	If it was an RPM based language pack, it would look like:

%post
intltool-merge --desktop-style --key Name --key Comment \
               --textdomain gnome-frobnicator --lang de \
               /usr/share/applications/gnome-frobnicator.desktop

	What would happen would be that intltool-merge (at package install
time) would pull the translation for Name/Comment from:
 
  /usr/share/locale/de/LC_MESSAGES/gnome-frobnicator.mo

	and merge those translations into the .desktop file using the Name[de]
and Comment[de] keys.

	Unless I'm missing something - intltool-merge would have all the
information it needs on that command line to do the merging.

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

	I've zero idea about any current language pack infrastructure, so I
don't really understand what you're saying but it sounds like an
implementation detail which could be sorted out by some minor
infrastructure work.

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

	You mean runtime vs. install-time, right?

	Well, as I say above, I don't think you should need it at install-time,
so its the runtime issue I'm considering.

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

	If an app installs the Name/Comment translations in a GNU message
catalog, it is only optional for a .desktop file reader to have support
for the GNU message catalog format (e.g. via the gettext library) if you
consider it optional for the .desktop file reader to have support for
translations.

	(i.e. its not optional)

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

	Ah, sorry.

Cheers,
Mark.