Desktop Entry Specification

[Carlos Perelló Marín]

El mar, 07-06-2005 a las 11:09 +0100, Mark McLoughlin escribió:
> 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.

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.

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.

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

a language pack has lots of .po files in its source and produces a bunch
of .mo files so you don't have access to the source package from where
the .po files comes.

A language pack is an implementation detail, true, and we are not
requesting a change to the spec that introduces any dependency or big
problem to non language packs deployments, we need an optional field
that will not break anything that is not using it.

I understand you don't like to use .mo files on runtime, but the spec
change is not depending on the implementation at all as that information
can be used for several implementations.

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

If you are not using language packs is useless change it from build time
to install time as you are not getting new translations...

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

I never said that we should remove translations from .desktop files. If
you use .mo files directly, you can get translation updates, if there
are not updates, you will get the current behaviour. If you don't want
to support .mo files on runtime, you will still have current behaviour.

What's the problem?

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

> Cheers,
> Mark.
> 
-- 
Carlos Perelló Marín
Ubuntu Hoary (PowerPC)  => http://www.ubuntulinux.org
Linux Registered User #121232
mailto:carlos at pemas.net || mailto:carlos at gnome.org
http://carlos.pemas.net
Valencia - Spain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050607/1020b3a1/attachment.pgp