Opened 7 years ago

Closed 4 years ago

#4327 closed enhancement (fixed)

Language CP module displays combo text in 2nd preferred language

Reported by: garycmartin Owned by: erikos
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: 0.98.x
Severity: Unspecified Keywords:
Cc: dsd, manuq Distribution/OS: OLPC
Bug Status: Unconfirmed

Description

Using the Language CP module to add a 2nd language choice, with English (USA) still as the primary language choice, will cause the Language CP module to display its combo menus in the second language after a restart, rather than the expected primary language. See attached screen shot.

Attachments (2)

Language_CP_module_translations.png (96.7 KB) - added by garycmartin 7 years ago.
0001-CP-language-section-display-language-country-each-in.patch (2.8 KB) - added by manuq 7 years ago.
Patch

Download all attachments as: .zip

Change History (17)

Changed 7 years ago by garycmartin

comment:1 Changed 7 years ago by manuq

  • Keywords olpc-test-pending added
  • Resolution set to fixed
  • Status changed from new to closed

Pushed 52076ffd .

comment:2 Changed 7 years ago by greenfeld

  • Keywords olpc-test-pending removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

This still does not work in OLPC 13.1.0 os30/sugar-0.98.3-1 in the case where the first language is English (US or AU).

I suspect that a translation match is always searched for even if the first language does not require one.

comment:3 Changed 7 years ago by erikos

  • Cc manuq added

comment:4 Changed 7 years ago by manuq

I see what's the issue now.

Could be reproduced in 12.1.0 too, so is not a regression added in the gtk3 port.

Ideally, each language should be displayed in their actual language, like in the Wikipedia site sidebar, and this has been a feature request for a long time.

comment:5 Changed 7 years ago by erikos

  • Keywords 13.1.0 removed
  • Milestone changed from Unspecified by Release Team to 1.0
  • Type changed from defect to enhancement

Thanks for checking for a regression. 1.0 work then.

comment:6 Changed 7 years ago by manuq

The CP module gets the translation of each language and territory using python gettext.dgettext with the domains 'iso_639' and 'iso_3166' respectively (a reference here).

This is an abbreviation of what is happening, having set English (USA) as primary language and Spanish (Argentina) as secondary:

[olpc@xo-1e-88-ab ~]$ cat ~/.i18n
LANG="en_US.utf8"
LANGUAGE="en_US.utf8:es_AR.utf8"
[olpc@xo-1e-88-ab ~]$ echo $LANG
es_ES.utf8
[olpc@xo-1e-88-ab ~]$ echo $LANGUAGE 
en_US.utf8:es_AR.utf8
[olpc@xo-1e-88-ab ~]$ python
Python 2.7.3 (default, Aug 26 2012, 05:16:24) 
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gettext
>>> print gettext.dgettext('iso_639', "French")
Francés

comment:7 Changed 7 years ago by manuq

Changing the order of the languages in $LANGUAGE doesn't affect the result, Spanish translation is returned anyways. Removing Spanish language makes English translation appear:

[olpc@xo-1e-88-ab ~]$ export LANGUAGE=es_AR.utf8:en_US.utf8
[olpc@xo-1e-88-ab ~]$ python -c "import gettext; print gettext.dgettext('iso_639', 'French')"
Francés
[olpc@xo-1e-88-ab ~]$ export LANGUAGE=en_US.utf8:es_AR.utf8
[olpc@xo-1e-88-ab ~]$ python -c "import gettext; print gettext.dgettext('iso_639', 'French')"
Francés
[olpc@xo-1e-88-ab ~]$ export LANGUAGE=en_US.utf8
[olpc@xo-1e-88-ab ~]$ python -c "import gettext; print gettext.dgettext('iso_639', 'French')"
French

comment:8 Changed 7 years ago by manuq

Using the class-based API, each language name can be obtained in its own language:

>>> tra = gettext.translation('iso_639', languages=['fr'])
>>> print tra.gettext("French")
français

And, the issue with English might be because of this:

>>> tra = gettext.translation('iso_639', languages=['en'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/gettext.py", line 471, in translation
    raise IOError(ENOENT, 'No translation file found for domain', domain)
IOError: [Errno 2] No translation file found for domain: 'iso_639'

In fact the bug only happens with English as primary language. Setting French as primary language displays the list inside the combo in French, regardless of what language is set as secondary.

comment:9 follow-up: Changed 7 years ago by manuq

The patch goes for the imho better approach, do like Wikipedia sidebar and many other language selectors do, "each language should be displayed in their actual language".

While testing please take into account that not all languages and countries are translated. I can see "Spanish" not translated to Spanish, for example. Some successful examples are:

English (New Zealand)
fancais (Belgique)
Deutsch (Belgien)

comment:10 follow-up: Changed 7 years ago by erikos

There is a long standing bug about the "how to find my own language" issue: #51 It has a similar patch, and issues back then were performance wise. Manuel, can you have a look at the old ticket and check the findings there?

comment:11 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by erikos

Replying to manuq:

The patch goes for the imho better approach, do like Wikipedia sidebar and many other language selectors do, "each language should be displayed in their actual language".

While testing please take into account that not all languages and countries are translated. I can see "Spanish" not translated to Spanish, for example. Some successful examples are:

I am very surprised that 'Spanish' is not translated to 'Español'. I think that is a blocker. I would first like to know why is that the case.

Also, while testing, I came across an issue with scrolling in the combo box filed as #4447.

comment:12 in reply to: ↑ 11 Changed 7 years ago by manuq

Replying to erikos:

Replying to manuq:

The patch goes for the imho better approach, do like Wikipedia sidebar and many other language selectors do, "each language should be displayed in their actual language".

While testing please take into account that not all languages and countries are translated. I can see "Spanish" not translated to Spanish, for example. Some successful examples are:

I am very surprised that 'Spanish' is not translated to 'Español'. I think that is a blocker. I would first like to know why is that the case.

True, I think the same. I have added my findings in a separate ticket: #4449

Also, while testing, I came across an issue with scrolling in the combo box filed as #4447.

Great, that one was being forgotten.

comment:13 in reply to: ↑ 10 Changed 7 years ago by manuq

Replying to erikos:

There is a long standing bug about the "how to find my own language" issue: #51 It has a similar patch, and issues back then were performance wise. Manuel, can you have a look at the old ticket and check the findings there?

Thanks a bunch for adding historical context.

Yes I agree with the performance concerns. We have:

  1. a long delay before opening the Language section, which gives the feeling the user click didn't work, specially noticeable in XO-1.
  1. a delay adding a row with the + button.

Number 1. is because we parse the output of 'locale -av' command to get the set of (language, country, code) and the interface is stalled. We should do that async.

Number 2. is because we translate the set of (language, country, code) each time a row is added. We should cache those translations. My patch makes this even slower.

So, I will try to do the async and cache.

comment:14 Changed 6 years ago by dnarvaez

  • Milestone changed from 1.0 to Unspecified

comment:15 Changed 4 years ago by quozl

  • Resolution set to fixed
  • Status changed from reopened to closed

Works fine now with 0.107.0.

Also tested on XO-1, it takes only three seconds to display the language control panel, and there is a busy cursor as well.

Note: See TracTickets for help on using tickets.