Desktop Entry Specification

[Carlos Perelló Marín]

On Wed, 2005-05-25 at 19:02 +0900, Takao Fujiwara - Tokyo S/W Center
wrote:
> I'm sorry, the mail size is exceeded.
> Resending.
> 

[...]

> #### Option1. Change GNOME APIs.
> 
> GOOD
> ====
> 1. Don't mind 3rd party's integration into GNOME if the .desktop files are English.
> 
> 2. Easily maintain and have the testings for UI messages because we can concentrate .mo files and don't need to merge base files with our ones.
> 
> 3. Consist process between us and Community.
> 
> 
> WRONG
> =====
> 1. Community needs to accept the patches because we hardly maintain the patches internally.
> 
> 2. Community don't mind to separate l10n contents if they want English messages, they can configure the parameter LC_MESSAGE=C with the user level.
> 
> 3. For 1 of multilingual files; i.e. .xml file, we needs to convince each maintainer because we don't have the standard APIs for .xml translation.
> 
> 4. YaST2 problem still there. [1]
> 
> [1] YaST2 is the bundled software in SuSE and it doesn't use GNOME APIs so this solution cannot be applied.

Yast can use this solution if you implement a patch to the KDE
implementation of the spec.


I think that we should add the extra field (as optional) to the spec and
thus every one decides how will they handle translations.

You will need anyway a way to map between .desktop files and translation
domains (for 1.- and 3.-).

I was talking about this with other Ubuntu developers and the main
problem we have doing the update at install/removal time is that you are
changing a file that is installed by another package and that's not
good. In order to support language packs in Ubuntu and being compatible
with manual installations or the install of other packages outside
Ubuntu, we had to implement a second place to store the .mo files from
the language packs so we don't have conflicts. In this case it's exactly
the same problem, but instead of just patch glibc, we need to do a
bigger patch to GNOME and KDE to handle it so we prefer to use directly
the .mo files.

As both solutions, using .mo files at runtime or at installation time,
need the translation domain information, I think we could just add it to
the spec and let people choose whatever they prefer to do to use that
field. It does not affects the spec at all.

Does it make sense?


Cheers.

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