Re: Language packs and desktop entries

[Takao Fujiwara - Tokyo S/W Center]

Excellent summary. Thanks for the valuable discussions.
(B
(BMark McLoughlin wrote:
(B> Hey,
(B>       To summarise the discussion we had at GUADEC around this issue, we
(B> talked about two solutions.
(B> 
(B>   1) Put the translation domain for the app in the .desktop file and
(B>      have .desktop file parsers pull the translations from the 
(B>      approriate message catalog.
(B> 
(B>      This is nice from the point of view that it would solve the 
(B>      language packs issue very cleanly and that (at least in GNOME) the 
(B>      translations are already in the message catalog.
(B> 
(B>      First problem is the performace hit with having to read every app's
(B>      message catalog. We're already seeing problems because of the 
(B>      amount of disk seeking involved with loading every .desktop file. 
(B>      Add message catalogs into the equation and you now have to locate 
(B>      each message catalog (by stat()ing for each locale alias) and 
(B>      load it.
(B
(BYes, this is right. But .mo is a binary and .destop is a text file. So for the 
(Bmilestone, If we change almost .desktop files to .mo files, I think the
(Bperformance will be faster rather than the current implementations. One 
(Bsolution is to use one .mo file for the .desktop file.
(B
(B
(B> 
(B>      AFAICT, the GNU message catalog format is designed as an mmap()able
(B>      hash, so loading the message catalog doesn't neccessarily involve
(B>      loading the entire file from disk, but some implementations (e.g. 
(B>      python) do load the entire file.
(B> 
(B>      Another problem is that this would add a dependancy on GNU gettext 
(B>      to the desktop entry spec. I'm not sure how big a problem that is, 
(B>      but it does need to be carefully considered.
(B
(BGreat point. I thought two sample situataions.
(B
(B#1. Suppose gnome-panel, i.e. viewer component for .desktop, was written by 
(BJava and other applications have the .mo files.
(B
(B - Example solution: gnome-panel needs to read .mo files or have other 
(Bimplementations, e.g. convert .mo to .property.
(B
(B#2. Suppose an application was written by Java and it has .desktop.
(B
(B - Example solution: Need to provide .mo files to be read the translations by 
(Bgnome-panel
(B
(BWe still need to think other situations.
(B
(B
(B> 
(B>      Finally, the migration path isn't straightforward. If apps 
(B>      immediately move to using TranslationDomain and stop using 
(B>      localestrings in the .desktop files, then those .desktop files 
(B>      won't work with older implementations. You'd probably end up with 
(B>      an indefinite period where apps still include the translations in 
(B>      the .desktop file as well as the message catalog.
(B
(BYes, this implimentation should provide the two options. One is to use .mo 
(Bfiles and another is to use .desktop files for the compatibility and the
(Boptions should be able to be switched easily. Personally I think to keep the 
(Bcomptibility is not so difficult and I have the implimentation.
(B
(BIf we use .mo files, all related APIs need to be changed and need to be removed 
(Bthe translations from .desktop files.
(B
(B> 
(B> 
(B>   2) The install-time merging of translations into the .desktop file.
(B> 
(B>      What I like about this is that the solution basically just 
(B>      involves some straightforward build/install infrastructure work 
(B>      and no other changes.
(B> 
(B>      The main problem I see here is that we'd be making it impossible 
(B>      (or at least much more difficult) for the package management system
(B>      to keep track of the .desktop file contents. Essentially, if you 
(B>      were doing language packs with RPM you'd have to do the following
(B>      in the base package:
(B> 
(B> %verify(not md5 mtime size) %{_datadir}/applications/*.desktop
(B> 
(B>      which certainly isn't ideal.
(B
(BYes, it's one of the problems. The file size is different between machines.
(B - If one system installs ja locale and another machine installs de and fr 
(Blocales, the the file size will be different between machines.
(B
(BAs I wrote in the previous mail, this solution has some problems.
(B
(B1. Long Installation time.
(B - GNOME has about 80 languages for multilingual files. If we use this solution 
(Bit will takes 30 minutes and I have 10 minutes for Sun's supported 15
(Blanguages.
(B   Ideally, it should be 5 minutes.
(B
(B2. Installation time depends on the number of languages directly.
(B - It does not effect installtion times but also effects users' operations. If 
(Busers add packages eventually, they need to wait for the completion.
(B
(B3. Possible Installation bugs.
(B - This implimentation is to change the installer even if this does not change 
(Bany GNOME APIs. As you know, installer bugs are critical and user's
(Boperations are stopped by them. E.g. if installer add the translations in 
(B.desktop files, but the usage of filesystem becomes 100% and the installer
(Bwill be broken. It is hardly have a workaround in the user side.
(B
(B
(B
(B> 
(B>      
(B>       Essentially, I think the latter solution involves pushes all the
(B> complexity on language pack implementors - language packs would require
(B> some work to get right, in terms of getting the infrastructure to
(B> handle .desktop files in this way and, also, in terms of ongoing
(B> maintenance work.
(B
(BYes, you're right. sooner or later the implimentation is needed with intltool.
(B
(B> 
(B>       However, the former solution involves a runtime performance hit,
(B> changes to the specification and compatibility issues.
(B
(BWhat about providing both option? then, it depends on the distributers which 
(Boptions are used in their system.
(BPlease let me note, the former solution does NOT force to use .mo files but 
(Bprovide option to select .destop or .mo.
(B
(BI also that think to change APIs is different from adding domain names in 
(B.desktop. It would be a great thought of Ubuntu persons from both former and
(Blater option.
(B
(BThanks,
(Bfujiwara
(B
(B> 
(B> Cheers,
(B> Mark.
(B> 
(B> _______________________________________________
(B> xdg mailing list
(B> xdg@lists.freedesktop.org
(B> http://lists.freedesktop.org/mailman/listinfo/xdg
(B
(B
(B_______________________________________________
(Bxdg mailing list
(Bxdg@lists.freedesktop.org
(Bhttp://lists.freedesktop.org/mailman/listinfo/xdg