Desktop Entry Specification

[Carlos Perelló Marín]

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.

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

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

Yeah, please.

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


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/db1b4d7b/attachment.pgp