[Sugar-devel] Language section debugging, use ICU?
manuq at laptop.org
Tue Mar 26 15:17:54 EDT 2013
I have ongoing work on polishing the Language section of the Sugar
settings panel. I'm sharing my findings to open discussion, to start
bringing back discussions to the mailing list, and to encourage
testing of my patches.
First, an introduction of the issues, ordered by priority as I understand:
1. list of languages: how could I select my language if it is
displayed in another language?
2. list of languages: if there are two languages and English is the
first one, the list is displayed as the second one
3. many language names are not translated
4. the section takes a lot of time to start, we should display a
watch/busy cursor while it is loading
The issues are interconnected as you will find if you try to read the
many comments, which mix them all through the years :)
A brief of the current implementation:
A. we parse the output of 'locale -av' command and create a list of
(language name, territory name, locale code)
B. we call gettext with ISO-639 to translate the language name
C. we call gettext with ISO-3166 to translate the territory/country name
Number 2 gets obsolete if we solve no. 1. The problem in 2. is that
we should not use gettext to translate strings to English, as they are
already in English. It is iliustrated in this comment:
Number 3 is a flaw of the current implementation: the output of
'locale -av' does not match 100% the strings in the po files for the
given gettext domains. See comment by Chris Leonard on this:
Number 4 has a general patch that works for all sections, except for
Modem section. We actually have code that displays a busy cursor, but
it is shown only for an instant, because (fortunatly) the UI doesn't
block the program. The patch wraps the initialization of the section
in a GObject.idle_add call, to make it work. As said before, this
conflicts with the current implementation of the Modem section. So..
still work to be done on this one.
By the way, number 4. gets less relevant if we speed up the section.
That leads me to talk about my findings on issue number 1: I have
investigated alternatives to our current gettext implementation.
- using gettext domain ISO 639-3 instead of ISO 639 for translating
the language name
- using external libraries Babel and PyICU
Here is a table of my results:
And here is the result of profiling them:
So, it looks like the ICU project is very fast and provides good
output. And reading the project homepage it looks on shape too. Can
we consider a switch to it?
.. manuq ..
More information about the Sugar-devel