[Pkg-xfce-devel] Bug#734391: Bug#734391: lightdm: language selection of lightdm seems to be totally fucked up

[Klaus Maria Pfeiffer]

hi!

On 2014-01-06 22:09, Yves-Alexis Perez wrote:

>> I know, that for that topic there are already some open bugs, but either they
>> are quiet old, only handling one part of this problem or workaround is not
>> complete.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679386

opened for version 1.2.2-1 on 28 Jun 2012. it describes more or less the 
situation when LANG is set, as I do in my testcase #3. provided 
workaround is to re-set LANGUAGE. last statement on 22 Oct 2012. 1 and a 
1/2 year old, just tagged fixed-upstream since 25 Apr 2013.

>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694588

opened for version 1.2.2-1 on 28 Nov 2012. dupe of 679386. already 
merged by you.

>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733261

opened for version 1.8.5-2 on 27 Dec 2013. seems to be lightdm always 
takes language from .dmrc file, even language selector is disabled. in 
any case, when .dmrc gets removed, lightdm showed the behaviour 
expected. not retested by me. this was the story till message #25. 
afterwards its just describing the bug when LANG is set, see above, my 
testcase #3.

> So you open another one, so everyone is *really* confused?

no, I just try to clarify the whole story about language settings and 
lightdm. to give the big picture. therefore I provided just 4 testcases.

> Also, I find
> the tone pretty offensive,

take this: s/fucked up/useless/g

> which doesn't exactly incitates me to anwer
> the report at all.

you have already.

>> initially, lightdm is suggesting me a total wrong locale czech (would have
>> awaited english due to LANGUAGE set), as you can see in
>> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_0_virgin_czech.png
> Yes, incidentally it's the first one of the available list.

that's bad in my opinion, because root has just choosen a language 
during installation for good reason, which is definitly written by the 
installer into /etc/default/locale as LANGUAGE. and as you correctly 
stated below, this is just a priority list, as also explained here 
<http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable>

so, my expectation is, that when LANG is unset (as it should be), 
lightdm should choose the locale based on LANGUAGE priority and not on 
the alphabetical (?) order of languages.

>> lets login. languages are mixed up, as you can see in
>> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_1_first_login.png
>> ;===
>> tux at dodahos:~$ export | grep -i lang
>> declare -x LANG="cs_CZ.utf8"
>> declare -x LANGUAGE="en_US:en"
>> tux at dodahos:~$ cat .dmrc
>> [Desktop]
>> Language=cs_CZ.utf8
>> Session=lightdm-xsession
>> ;===
> I don't see how they are mixed up.

please, have a detailed look on my screenshot (still linked above) where 
panel is english, applications menu is in czech, terminals menu is 
english, ... this is what I mean with mixed up.

> czech was selected in the menu, so
> LANG is set to czech.

no, czech was suggested because its the first language avail on the 
system, it was not really selected. yes, LANG is set correctly.

> *You* set LANGUAGE (which lightdm doesn't touch).

yes and no. during installation of the system I choosed english as 
language, but LANGUAGE itself is set by installer in /etc/default/locale 
which is sourced by lightdm's init file.

but due to LANGUAGE is a priority list (mentioned and given link above), 
it should also reflect the choosen language in LANG respectively in 
LC_MESSAGE. this is also checked by /usr/sbin/update-locale.
;===
#  If LANGUAGE is set, its first value must be compatible with LC_MESSAGES
;===

let me give you an example.
;===
root at dodahos:~# export | grep -i lang
declare -x LANGUAGE="en_US:en"

root at dodahos:~# update-locale LANG=de_AT.UTF-8
*** update-locale: Warning: LANGUAGE ("en_US:en") is not compatible with 
LANG (de_AT.UTF-8). Disabling it.

root at dodahos:~# update-locale LANG=de_AT.UTF-8 LANGUAGE=de_AT:de:en_US:en

root at dodahos:~# cat /etc/default/locale
#  File generated by update-locale
LANG=de_AT.UTF-8
LANGUAGE=de_AT:de:en_US:en
;===

>> now I delete
>> username and give tux and language is still esperanto, would have awaited czech
>> now. see screenshot
>> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_2_wrong_language.png
> This one looks indeed weird.

even its not the case often used.

>> ok, lets select locale czech and login with tux. same as before. lets logout.
> What do you mean “same as before”? LANG correctly set to cs_CZ and
> LANGUAGE still set to en_US?

yes.

>> - LANGUAGE not set correct by lightdm
> I'm honestly not sure lightdm should touch LANGUAGE at all.

it should. because user has choosen LANG as its prio 1 language, so this 
should be reflected in LANGUAGE, as also update-locale does.

> Considering
> it's a priority list, replacing the content by one locale doesn't look
> like a good idea. Maybe adding the currently selected locale on top of
> the list?

good idea, very good idea!

> If it's not set, then it's useless to set it to the same
> content as LANG.

I think so.

>> - languages mixed up in xfce
> Likely because of the LANG/LANGUAGE mismatch.

of course.

>> there's a workaround mentioned in http://bugs.debian.org/cgi-
>> bin/bugreport.cgi?bug=679386#107, lets apply and test it as testcase #2.
> I should indeed revisit that bug, but it's most likely fixed with recent
> lightdm-gtk-greeter versions.

I've already installed lightdm* from experimental.

> Also the shell workarounds look pretty bad
> so I won't even comment.

to be honest, I like it, because its definitly doing that what lightdm 
is missing. ok, its just overwriting LANGUAGE and not setting choosen 
LANG as prio 1. it was declared as workaround.

>> ok, lets set system locale with dpkg-reconfigure locales to en_US.UTF-8.
>> root at dodahos:~# cat /etc/default/locale
>> #  File generated by update-locale
>> LANG=en_US.UTF-8
>> LANGUAGE="en_US:en"
>> ;===
>> tux at dodahos:~$ cat .xsessionrc
>> export LANG=cs_CZ.UTF-8
>> export LANGUAGE=cs_CZ:cs:en
> When did you add a .xsessionrc?

before login. or what do you mean with add? its sourced by 
/etc/X11/Xsession.d/40x11-common_xsessionrc. I have created it before I 
logged in.

> Because it'll set the variables for the
> session completely outside of lightdm/lightdm-gtk-greeter.

lets say afterwards.

>> now tux has .dmrc file, so, would await at next login lightdm is suggesting me
>> czech. nooo. its suggesting me english. wtf? seems to be lightdm is ignoring
>> users .dmrc file if LANG is set.
> Before or after entering the login?

after entering username and pressing tab to jump into password field.

>> - LANG overwritten even if set in .xsessionrc
> You're confused here,

no, lightdm confused me, to be honest. because ...

> .xsessionrc is sourced after the login.

... every export | grep -i lang I've done already in a terminal in xfce.

to clarify a little bit (just brainstroming, not really seen in the system):
lightdm is setting LANG to cs_CZ.utf8
mentioned patch is setting LANG to cs_CZ.UTF8
.xsessionrc is setting LANG to cs_CZ.UTF-8
but LANG after login in xfce terminal is cs_CZ.utf8

>> we will do now the language selection by .xsessionrc.
> Then you're completely outside of login process.

doesn't matter, but every user on the system can choose his own language 
depending of what he has declared in his .xsessionrc.

>> so it really seems to me, that language handling is totally fucked up in
>> lightdm.
> Now, this is rude.

what do you prefer: fouled up, screwed up, bitched up? ok, sorry, lets 
say its just useless.

> If you have constructive comments, you're welcome to
> do so.

thanks. see above.

> It's even quick to actually read the code you're bashing.

sorry, not yet. first, plz, give me the chance how eg kdm is handling 
that stuff, tomorrow.

> Considering there's like one piece of information here (the fact that
> the locale is not re-loaded the second time a user login is entered),

hopefully you now got some ideas how to handle LANG and LANGUAGE?

> I'm pretty much inclined to just ignore the rest.

I'm sorry.

>> gre3tings, Klaus
> Not really, actually.

gre3tings, Klaus