Language packs and desktop entries

[Mark McLoughlin]

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

Cheers,
Mark.