Desktop Entry Specification

[Mark McLoughlin]

On Tue, 2005-06-07 at 12:42 +0200, Carlos Perelló Marín wrote:

> So you want that we look one by one all modules, get the translation
> domain, add it to a list that will be used later with the language packs
> and that will be obsolete if upstream changes the translation domain
> (it's not usual but it happens).
> 
> I know that intltool-merge will work as you say, but you need the
> --textdomain argument, it will not appear magically.

	Absolutely. I do understand this requires more work for language pack
implementors.

> My proposal is just that on build time we add that field from the
> package's environment variables into the .desktop file so we can get the
> translation when we want and from the package we want. After this
> change, if the translation domain changes, the .desktop file will get
> the change for free.

	Right, but I think it only makes sense to add the translation domain to
the .desktop files if we're talking about changing how .desktop file
readers should get the translated values of keys.

	I don't think it makes sense for .desktop file readers to have to look
for translations using the current localestring format *and* using
gettext().

	i.e. the two-stage lookup of translations would only be interesting in
the context of allowing .desktop file readers to handle legacy .desktop
files. If we add the translation domain, the message catalog should
become the canonical place to obtain the translations.

> > > > > 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.
> 
> Again, can you explain me where do you get that information from on
> install-time?

	The translation domain for a given .desktop file would be hardcoded in
the post-install scriptlet of that language pack.

Cheers,
Mark.