region subtag of language are not being set accordantly

Thanks for reporting this issue. Could you please clarify:

* I don't quite understand the title of this bug report. 'zh_TW.utf8'
  sounds correct to me.

* Do you think it may be the same issue as is discussed at
  https://lists.ubuntu.com/archives/ubuntu-desktop/2010-December/002722.html,
  i.e. there is no 'zh_TW.utf8' locale on the remote machine, why its
  locale settings gets changed to 'C' or 'POSIX'?

* Please let us know the output of the 'locale' command on the remote
  machine.

The problem is language-selector and ubiquity set the subtag of locale in different way, like if you choose en_US druring your installation, then LANG and LANGUAGE will be set as en_US.UTF-8, but after you made any changes with language-selector, like change the language, the subtag will be set as xx_XX.utf8, and this is obviously a problem.
In my case, my remote machine is using en_US.UTF-8, but after I made a change with my local machine, the locale will be set as zh_CN.utf8, then, all Chinese characters on remote machine can't be displayed correctly from within the screen sessions. In addition, I think most distros are still using the tag scheme like xx_XX.UTF-8, instead of xx_XX.utf8.
So I'm very curious about why shall we use xx_XX.utf8? In addition, we have a lot of place to set locale variants, it make user feel frustrated, especially from GDM, too complicated. Why don't we just put all those languages relevant variant into /etc/environment or /etc/default/locale for system-wide settings, and into ~/.profile for users setting? then GDM/KDM/XDM/ just read it from them, it will more easy and straightforwad not only for end users, but also for developers.

On 2011-01-24 07:41, ZhengPeng Hou wrote:
> ... if you choose en_US druring your installation, then LANG and
> LANGUAGE will be set as en_US.UTF-8, but after you made any changes
> with language-selector, like change the language, the subtag will be
> set as xx_XX.utf8, and this is obviously a problem. In my case, my
> remote machine is using en_US.UTF-8, but after I made a change with
> my local machine, the locale will be set as zh_CN.utf8, then, all
> Chinese characters on remote machine can't be displayed correctly
> ...

Aha, now I understand better. That issue has been reported previously in
bug 666565, so I marked this document a duplicate of bug 666565.

> In addition, we have a lot of place to set locale variants, it make
> user feel frustrated, especially from GDM, too complicated. Why
> don't we just put all those languages relevant variant into
> /etc/environment or /etc/default/locale for system-wide settings,
> and into ~/.profile for users setting? then GDM/KDM/XDM/ just read
> it from them, it will more easy and straightforwad not only for end
> users, but also for developers.

As a part of the solution to bug 553162, the use of the files
/var/cache/gdm/$USER/dmrc and ~/.dmrc were recently extended with a
couple of new fields for storing locales settings. While I agree that
it may presently appear unnecessarily complicated, it's the result of a
carefully considered compromise, so it won't likely be altered
short-term.

I really don't understand how does LCMess come from, and whats the purpose of Langlist stand for in dmrc.

LANG
LANGUAGE
LC_CTYPE
LC_NUMERIC
LC_TIME
LC_COLLATE
LC_MONETARY
LC_MESSAGES
LC_PAPER
LC_NAME
LC_ADDRESS
LC_TELEPHONE
LC_MEASUREMENT
LC_IDENTIFICATION
Are those above not enough to handle the situation we're facing now?
To solve the issues related to language selection, why don't we improve language-selector itself, instead of come out such a workaround. Please to the attachment which is a screenshot of the locale setting under KDE4, if we can improve language-selector to this one, and store all settings under ~/.profile, would it be much more easier for users/developers.

screenshot of locales setting under KDE4

I have make this bug no longer a duplicate of Bug #666565. I think before 666565 is fixed ultimately, this problem can only be worked around in language-selector, since a work around won't be a lot of work but fixing the whole picture of locale may need some efforts.

locales on Ubuntu are really annoying today, different applications do different settings. IMHO language-selector has already achieved what the original design aimed at (thanks everyone who have worked on it). We need something evolutionary to be landed if we want make things more simple, not more complicated.

@ZhengPeng Hou
"LCMess" and "Langlist" are fields in dmrc for storing language settings on disk, while the list you posted contains environment variables.

The short explanation to the current solution: While we want that GDM stores the new settings on disk, if the user changes language from the greeter, the boot might fail if we let GDM save things under /home. That's why we expanded the use of /var/cache/gdm/$USER/dmrc.

For the long explanaion, please study the discussions at bug 553162 and https://bugzilla.gnome.org/show_bug.cgi?id=633295.

I see from the screenshot that KDE offers a gui for fine-tuning the non-language locale settings, and I agree that it would be good if language-selector could be further developed along those lines. It would be great if you could file a separate bug about that. (This bug tends to contain too many topics.)

On 2011-01-25 08:36, Aron Xu wrote:
> I have make this bug no longer a duplicate of Bug #666565. I think
> before 666565 is fixed ultimately, this problem can only be worked
> around in language-selector, since a work around won't be a lot of
> work but fixing the whole picture of locale may need some efforts.

Also GDM would be involved in such a workaround if it would be decided
to replace 'utf8' with 'UTF-8'.

> locales on Ubuntu are really annoying today, different applications
> do different settings.

When you say "today", which versions of language-selector and GDM are
you referring to? A few months ago, I would have agreed, but I have been
working with Ubuntu's way to handle language/locale settings for a while
now, and I believe that significant improvements have been and are about
to be committed. Please feel free to install the latest development
versions of GDM and language-selector and let us know what you think.
https://launchpad.net/~gunnarhj/+archive/language-menus

@Gunnar Hjalmarsson
From my point of view, GDM shouldn't offer that much options to users, like we have l-s after login which can let users set their language and relevant settings, but we also have gdm greeter to let users make their choice, isn't it redundant? And from usability's point of view, is it a bad design? So to solve the problem thoroughly, we might consider of disable the lang select from gdm greeter, improve l-s, centralize language settings, but not workaround by workaround.

We might need to open another bug report and assign all relevant people on that issue, so we can have a throughout discussion on the design of user experience.

@ZhengPeng Hou
I can't help feeling that your view is colored by the fact that GDM and language-selector did not play well together previously. People usually ask for more options, not fewer.

@Aron Xu
General design discussions are better hold at e.g.
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

I have to say, though, that now is not an optimal time for such discussions on locale handling, since significant changes have recently been and will very soon be launched.

@Gunnar Hjalmarsson
Its nothing about bias, its from end users perspective, to my experience(My job is to do level one support to those users who has never used linux, but they're trying), too much options scares users, they will get confused, and can't figure out what will work for them, as I mentioned above, to make it easier and more straightforward to EU might be better choice.
Just my $0.01

The fact, that I just spent quite some time to help synchronize GDM and language-selector with respect to the controls of languages/locales, makes me probably disinclined to listen to a suggestion to drop GDM's language picker. Yes, I for one am biased, no doubt about it. ;-)

Please be assured that I have no other goal but making it better for end users; working with bug 693337 is my latest effort in that direction. One important thing that remains, to complete the changes, is to revise the related documentation.

As regards the data storage, the user settings for LANGUAGE and LC_MESSAGES are now stored in /var/cache/gdm/$USER/dmrc and ~/.dmrc, while the user settings for LANG (and other LC_* variables, when applicable) are stored in ~/.profile. It's not _that_ complicated, is it? OTOH, I imagine that it's more important to Linux beginners that the GUI makes sense.

This bug was fixed in the package language-selector - 0.13

---------------
language-selector (0.13) natty; urgency=low

  [ Gunnar Hjalmarsson ]
  * LanguageSelector/gtk/GtkLanguageSelector.py:
    - Ensure that main or origin country is included when country
      specific options for a language are shown (LP: #710148).
    - Do not let an absent translation directory make the program crash
      (LP: #714093).
  * data/LanguageSelector.ui:
    - Shorter label to describe the second tab (LP: #709855).
  * LanguageSelector/macros.py:
    - Use locale names with '.UTF-8' instead of '.utf8' when setting
      LC_* or LANG environment variables (LP: #666565, #700619).
      Thanks to Lauri Tirkkonen for the patch!
 -- Evan Dandrea <email address hidden> Mon, 14 Feb 2011 16:13:04 +0000