Desktop Entry Specification

[Carlos Perelló Marín]

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

The problem is that you think that putting there the translation domain
means use .mo on runtime, It's not a must and I don't think it should
be.

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

It's a way to give choices to people.

You say the .mo solution is slow, could be (Takao says it's not) but
there are options to optimice it using cached values and other
solutions. That's 100% implementation detail. We are not talking about
an implementation detail, we are talking about a spec. The spec locks
you into a way to handle translations with .desktop files, we are asking
for a way that gives more flexibility to the implementation, that's all.


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

I don't see what's wrong use by default .mo files (if exists) and as
fallback the .desktop file content. You are not losing anything but
adding a way to update translations after release...


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


But you need to write it one by one and update that list manually.

Dude, I cannot understand why is so difficult for you to accept and
addition that does not hurts previous/current implementations and that
will give more flexibility to language packs. Upstream projects like
GNOME or KDE don't need to care at all about language packs as they
don't need them directly. But distributions will win a lot with that
small change. In fact, the maintainers will not need to care about that
change, they only need to accept patchs from distributions like SUN or
Ubuntu as they will fix it and having your .desktop files without the
'TranslationDomain' key will not affect you at all.

We are not talking about incompatible changes or evil changes to make
our life easier. The only arguments you gave me against the spec change
is:

 - It makes the spec depend on gettext: IT's not true, the key is added
as Optional.
 - The .mo usage on runtime is slow: It's an implementation detail and
one of the possible solutions to use that field so that field does not
implies that you should implement the spec using .mo files on runtime.
 
Am I missing anything? because I cannot understand the big problem that
you see there... I'm not proposing that we remove current system, but to
extend it to give more flexibility, that's all... It will not break
anything and upstream changes are minimum and 100% optional.

Cheers.

> 
> Cheers,
> Mark.
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
-- 
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/d842f57e/attachment.pgp