Language packs and desktop entries

[Carlos Perelló Marín]

El mar, 07-06-2005 a las 12:02 +0100, Mark McLoughlin escribió:
> Hey,

Hi

> 	To summarise the discussion we had at GUADEC around this issue, we
> talked about two solutions.
> 
>   1) Put the translation domain for the app in the .desktop file and
>      have .desktop file parsers pull the translations from the 
>      approriate message catalog.
> 
>      This is nice from the point of view that it would solve the 
>      language packs issue very cleanly and that (at least in GNOME) the 
>      translations are already in the message catalog.
> 
>      First problem is the performace hit with having to read every app's
>      message catalog. We're already seeing problems because of the 
>      amount of disk seeking involved with loading every .desktop file. 
>      Add message catalogs into the equation and you now have to locate 
>      each message catalog (by stat()ing for each locale alias) and 
>      load it.
> 
>      AFAICT, the GNU message catalog format is designed as an mmap()able
>      hash, so loading the message catalog doesn't neccessarily involve
>      loading the entire file from disk, but some implementations (e.g. 
>      python) do load the entire file.
> 
>      Another problem is that this would add a dependancy on GNU gettext 
>      to the desktop entry spec. I'm not sure how big a problem that is, 
>      but it does need to be carefully considered.
> 
>      Finally, the migration path isn't straightforward. If apps 
>      immediately move to using TranslationDomain and stop using 
>      localestrings in the .desktop files, then those .desktop files 
>      won't work with older implementations. You'd probably end up with 
>      an indefinite period where apps still include the translations in 
>      the .desktop file as well as the message catalog.
> 
> 
>   2) The install-time merging of translations into the .desktop file.
> 
>      What I like about this is that the solution basically just 
>      involves some straightforward build/install infrastructure work 
>      and no other changes.
> 
>      The main problem I see here is that we'd be making it impossible 
>      (or at least much more difficult) for the package management system
>      to keep track of the .desktop file contents. Essentially, if you 
>      were doing language packs with RPM you'd have to do the following
>      in the base package:
> 
> %verify(not md5 mtime size) %{_datadir}/applications/*.desktop
> 
>      which certainly isn't ideal.
> 
>      
> 	Essentially, I think the latter solution involves pushes all the
> complexity on language pack implementors - language packs would require
> some work to get right, in terms of getting the infrastructure to
> handle .desktop files in this way and, also, in terms of ongoing
> maintenance work.
> 
> 	However, the former solution involves a runtime performance hit,
> changes to the specification and compatibility issues.

As I said in my previous mails, I see a third option:

3) Add the translation domain info to the .desktop files and let the
implementator decide if they want to stay as we handle translations
today or use 1) or 2). That's the point behind a spec, it does not
drives the way the implementation is done.

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