Re: Language packs and desktop entries

[Takao Fujiwara - Tokyo S/W Center]

(B
(BAlexander Larsson wrote:
(B> On Wed, 2005-06-08 at 15:33 +0900, Takao Fujiwara - Tokyo S/W Center
(B> wrote:
(B> 
(B>>Excellent summary. Thanks for the valuable discussions.
(B>>
(B>>Mark McLoughlin wrote:
(B>>
(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>>
(B>>Yes, this is right. But .mo is a binary and .destop is a text file. So for 
(B>>the milestone, If we change almost .desktop files to .mo files, I think the
(B>>performance will be faster rather than the current implementations. One 
(B>>solution is to use one .mo file for the .desktop file.
(B> 
(B> 
(B> I think you are misunderstanding what the performance problem is. The
(B> problem is the need to open multiple files (both desktop and mo), and
(B> for .mo file its even worse, as it requires multiple stats to locate the
(B> right translation. Each stat of a file means a seek, and two seeks for
(B> an open. Each seek is on average half a rotational delay on the HD,
(B> which is a very long time in cpu clock cycles. Actually reading the file
(B> once we've seeked to it is not a problem, relatively.
(B> 
(B> In fact, the stating and opening of many files in for instance the icon
(B> theme spec has caused massive performance issues for implementations,
(B> and we do *not* want that to happen again.
(B
(BOK, you mean even if we use one .mo file only, the multiple stats effect the 
(Bperformance?
(BMy understanding is to read one by one .icon file.
(B
(BIf possible, could you provide the measurable way?
(BI have a sample implementation and I don't find the big delay on Ultra 10. so 
(BIf I could show the exact time, it would be a really help for one
(Breference. I think the concern needs to be investigated.
(B
(BThanks,
(Bfujiwara
(B
(B> 
(B> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
(B>  Alexander Larsson                                            Red Hat, Inc 
(B>                    [EMAIL PROTECTED]    [EMAIL PROTECTED] 
(B> He's a superhumanly strong Jewish dwarf with no name. She's a provocative 
(B> mutant mermaid with her own daytime radio talk show. They fight crime! 
(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