Wrong $LANG environment var set by lightdm

Bug #1507854 reported by adam
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Light Display Manager
New
Undecided
Unassigned

Bug Description

[[BUG]]
Lightdm always set wrong $LANG environment variant.

For Simplified Chinese, it set $LANG to zh_CN.utf8.
However the correct one should be zh_CN.UTF-8, and some GUI program especially like gVim will output tons of error if $LANG is set to zh_CN.utf8.

I used to set LANG in my .xprofile file, but I didn't know the reason why it doesn't override LANG setting now.

[[REPRODUCER]]

1. Log in using zh_CN language (P.R.C)
2. open terminal emulator
3. run gvim in terminal emulator and see the output.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

What operating system are you using?

Changed in lightdm:
status: New → Incomplete
Revision history for this message
adam (anonymous-temp-mail) wrote :

Archlinux, with lightdm 1:1.16.3.

Changed in lightdm:
status: Incomplete → New
Revision history for this message
Piotr Jurkiewicz (piotrjurkiewicz) wrote :

1. LightDM uses `locale -a` command to get the list of available locales in function update_languages() (liblightdm-gobject\language.c line 52).
2. `locale -a` returns the simplified locale name (zh_CN.utf8) instead of the full locale name (zh_CN.UTF-8).
3. `locale -a` returns the simplified locale name because it reads it from the locale archive in function write_archive_locales() (http://repo.or.cz/glibc.git/blob/HEAD:/locale/programs/locale.c#l634).
4. The simplified name is used in locale archive because it is being 'normalized' when adding a locale to the archive. Function add_locale_to_archive() (http://repo.or.cz/glibc.git/blob/HEAD:/locale/programs/locarchive.c#l1130) calls function _nl_normalize_codeset() (http://repo.or.cz/glibc.git/blob/HEAD:/intl/l10nflist.c#l299) which normalizes the codeset name. Codeset names are normalized by that function to all-lowercase with all non-alphanumeric characters stripped i.e. "UTF-8" turns into "utf8".

See this: http://unix.stackexchange.com/questions/186963/what-is-the-proper-encoding-name-to-use-in-locale-for-utf-8

Notice that the answer author apparently did not understand the mail he is citing (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607138#79).

I believe that it should be fixed in glibc. I think that function add_locale_to_archive() should store the locale with unnormalized codeset and then add an alias for its name with normalized codeset.

Until the fix will be accepted to glibc (if ever), it can be fixed in LightDM as well: by simply replacing '.utf8' with '.UTF-8' in locale names obtained from `locale -a` command before adding them to languages list (liblightdm-gobject\language.c line 80).

Revision history for this message
Piotr Jurkiewicz (piotrjurkiewicz) wrote :

This patch adds code which replaces '.utf8' with '.UTF-8' in locale names obtained from `locale -a` command before adding them to languages list.

It also replaces calls to g_strrstr(code, ".utf8") with calls to is_utf8(code) and moves that function a little bit upwards in order to make it available in update_languages(). Thanks to that the code will work even when glibc will change the output format of `locale -a` from .utf8 to .UTF-8.

Revision history for this message
adam (anonymous-temp-mail) wrote :

Thank you a lot, Piotr,

But before apply the patch, I'd like to use xprofile and just add "export LANG=zh_CN.UTF-8" as a workaround.

The problem is, this method works fine in one box, but fails in another one.

These two boxes are using same lightdm, butthe one using Xfce4 fails to set $LANG and still the wrong .utf8.
The one using Cinnamon works fine as expected.

IIRC, lightdm will source $HOME/.xprofile before launching the DE/WM, so even for Xfce4 it should set LANG to correct one.

Is there something wrong in lihgtdm or Xfce4?

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.