Comment 13 for bug 590108

On 2011-10-06 00:14, Colin Watson wrote:
> Despite the general subject, I'm going to restrict this bug to the case
> of those languages where the choice of location may get you a different
> localisation (due to different dialect, writing system, etc.): of the
> languages we support for installation, that's Portuguese and Chinese.
> There is also a problem of what should happen if (say) you select
> English but then say you live in Switzerland, or select Chinese but say
> you live in France; that is a much harder problem and I would appreciate
> not having the scope of this bug widened to include that.

Not sure I understand how the latter would be much harder. Isn't it basically the same thing, i.e. picking one locale for LC_MESSAGES etc. and another locale for LANG?

> To fix this, we need to change both localechooser and ubiquity. The
> approach I'll take is modelled on that of language-selector; in cases
> where they mismatch, LANG should primarily reflect the location (so that
> numeric, monetary, etc. locale categories are correct) while LANGUAGE,
> LC_MESSAGES, LC_CTYPE, and LC_COLLATE should primarily reflect the
> language.

Yes, that's how language-selector does it in Oneiric.

I for one am playing with the idea to propose that we do it the other way around for the P cycle, i.e. let LANGUAGE and LANG reflect the language and, when needed, assign to LC_TIME, LC_NUMERIC, LC_CURRENCY etc. some other locale than what's put into LANG. I can see three reasons for doing this switch:

* It's how GNOME does it in g-c-c, and considering that we are moving towards replacing the language-selector UI with "Region and Language" in g-c-c, it would eliminate one of the current differences in approach between Ubuntu and GNOME.

* There seems to be quite a few desktop apps/tools, or parts of apps, that ignore both LANGUAGE and LC_MESSAGES for the display language, and let LANG solely determine the display language. (My LANG usually contains a Swedish locale, while my display language is English, and I often see Swedish translations in dialogs and menus.)

* Some distributions may prefer the simplistic approach to equal l10n with simply picking a locale name and assigning it to LANG. If we would switch to let LANG represent the language, the LANG variable would roughly be used for the same purpose all over, which would reduce the risk for confusion with respect to locale/language settings.

If it would be decided to do this switch, I hope that it won't be too hard to make similar changes to localechooser and ubiquity.