← Back to team overview

desktop-packages team mailing list archive

[Bug 864618] Re: sets $LANG to a language name

 

Hi Rodrigo,

As you asked me on #ubuntu-desktop, I built g-c-c without the Ubuntu
specific patch 52_ubuntu_language_list_mods.patch, in order to check out
if the whole patch or part of it could be dropped in Oneiric.

I chose to respond through this long (hopefully not lengthy) bug
comment. With this I'd like to say that we ought to talk more to each
other on the locale/language topic; more about that in the end of this
comment.

This is how the patch was motivated in the changelog:

  * debian/patches/52_ubuntu_language_list_mods.patch:
    - Change the list of options, when setting language from User
      Accounts, to items representing available translations, and with
      that make it similar to the language list in language-selector.
    - Make items representing language @variants be displayed as such.

To me it looks like nothing significant has been changed upstream that
makes the patch less motivated than when it was uploaded.

With the build ex patch 52 installed, the language chooser UI consists
of two lists. For me, the first of them does not show all installed
translations, but it includes languages that I have not installed. It
also shows two "English" items without disclosing which country specific
translations they represent.

When I click "Other..." I see a list of all UTF-8 locales on my box,
most of which are irrelevant considering that the number of translations
are just a fraction of the number of locales. Also, in the case of
@variants no info is displayed that lets you know which of the items are
@variants. These are issues that g-c-c seems to have inherited from gdm,
but which were resolved in the Natty gdm package as regards Ubuntu.

With patch 52 included, there is one list only, and its items represent
the translations available on my computer, no more and no less. Each
item has a label that unambigously distinguishes it from the other
items, and you see if it represents a @variant.

So, I really can't see what good it would do to drop the patch in
Oneiric and expose the users to all those bugs.

In both language-selector and the Ubuntu variant of the User Accounts UI
the actual values that are dealt with in the language lists are language
values such as 'es_ES' or 'de', while upstream g-c-c deals with locale
names.

Our discussion started with https://code.launchpad.net/~gunnarhj/gnome-
control-center/non-utf8-confusion/+merge/78140, where I propose that the
call in gdm-languages.c for the language_name_get_codeset_details()
function is commented. That change would hopefully make Colin, with his
latin1 locale installed, happy, at least. :)

If you like you can blame the issue with installed non-utf8 locales on
patch 52, since language_name_get_codeset_details() does not change
anything if you pass a valid locale name to it. But that way of looking
at it isn't fair, since the code that messes with codesets shouldn't be
there in the first place, considering that we only deal with UTF-8
locales via the UI. In any case, dropping patch 52 the day before the
Oneiric release candidate, as a replacement for disabling that
irrelevant codeset code, can't reasonably be justified.

To make the intentions in https://lists.ubuntu.com/archives/ubuntu-
desktop/2011-October/003219.html come true, without sacrificing useful
functionality, I think we need to talk quite a lot during the P cycle.
IMO it would be a good idea to start with the conceptual side of
locale/language handling. Martin P. and Robert A. did just that this
morning; see comment #12 in this bug report.

Since most of what I have contributed to Ubuntu so far is related to
locale/language handling, I have some related thoughts in my head that
I'll put down on a wiki page. Hopefully we can start talking soon.
Looking forward to it.

/ Gunnar

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/864618

Title:
  sets $LANG to a language name

Status in “gnome-control-center” package in Ubuntu:
  In Progress
Status in “lightdm” package in Ubuntu:
  Fix Released
Status in “gnome-control-center” source package in Oneiric:
  In Progress
Status in “lightdm” source package in Oneiric:
  Fix Released

Bug description:
  As of the last oneiric upgrade I performed (I'm not certain, but I
  think this was from lightdm 0.9.7-0ubuntu2 to 1.0.0-0ubuntu3), my
  locale has been broken; it is now set to en_GB rather than to
  en_GB.UTF-8.  I've attached lightdm.log, of which the salient lines
  seem to be:

    [+8.46s] DEBUG: Launching process 2603: /usr/sbin/lightdm-session 'gnome-session --session=ubuntu-2d'
    [+8.46s] DEBUG: pam_setcred(0x930a6c8, PAM_ESTABLISH_CRED) -> 0 (Success)
    [+8.46s] DEBUG: PAM returns environment 'GNOME_KEYRING_CONTROL=/tmp/keyring-JAW17p GNOME_KEYRING_PID=2592 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8:en'
    [+8.46s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
    [+8.47s] DEBUG: Using locale en_GB for language en_GB

  Please fix this urgently; it's bad to have regressed to a legacy
  encoding.  We should be using UTF-8 for everything unless explicitly
  configured otherwise, and we definitely shouldn't be ignoring explicit
  configuration of UTF-8.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/864618/+subscriptions


References