Language packs and desktop entries

[Takao Fujiwara - Tokyo S/W Center]

Excellent summary. Thanks for the valuable discussions.

Mark McLoughlin wrote:
> 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.

Yes, this is right. But .mo is a binary and .destop is a text file. So for the milestone, If we change almost .desktop files to .mo files, I think the
performance will be faster rather than the current implementations. One solution is to use one .mo file for the .desktop file.


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

Great point. I thought two sample situataions.

#1. Suppose gnome-panel, i.e. viewer component for .desktop, was written by Java and other applications have the .mo files.

 - Example solution: gnome-panel needs to read .mo files or have other implementations, e.g. convert .mo to .property.

#2. Suppose an application was written by Java and it has .desktop.

 - Example solution: Need to provide .mo files to be read the translations by gnome-panel

We still need to think other situations.


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

Yes, this implimentation should provide the two options. One is to use .mo files and another is to use .desktop files for the compatibility and the
options should be able to be switched easily. Personally I think to keep the comptibility is not so difficult and I have the implimentation.

If we use .mo files, all related APIs need to be changed and need to be removed the translations from .desktop files.

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

Yes, it's one of the problems. The file size is different between machines.
 - If one system installs ja locale and another machine installs de and fr locales, the the file size will be different between machines.

As I wrote in the previous mail, this solution has some problems.

1. Long Installation time.
 - GNOME has about 80 languages for multilingual files. If we use this solution it will takes 30 minutes and I have 10 minutes for Sun's supported 15
languages.
   Ideally, it should be 5 minutes.

2. Installation time depends on the number of languages directly.
 - It does not effect installtion times but also effects users' operations. If users add packages eventually, they need to wait for the completion.

3. Possible Installation bugs.
 - This implimentation is to change the installer even if this does not change any GNOME APIs. As you know, installer bugs are critical and user's
operations are stopped by them. E.g. if installer add the translations in .desktop files, but the usage of filesystem becomes 100% and the installer
will be broken. It is hardly have a workaround in the user side.



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

Yes, you're right. sooner or later the implimentation is needed with intltool.

> 
> 	However, the former solution involves a runtime performance hit,
> changes to the specification and compatibility issues.

What about providing both option? then, it depends on the distributers which options are used in their system.
Please let me note, the former solution does NOT force to use .mo files but provide option to select .destop or .mo.

I also that think to change APIs is different from adding domain names in .desktop. It would be a great thought of Ubuntu persons from both former and
later option.

Thanks,
fujiwara

> 
> Cheers,
> Mark.
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg