You are not logged in.

#1 2019-03-23 08:36:00

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

locales rabbithole

Oh dear, while trying to polish the setlocale script so that it might work with other DMs than lightdm, I got deeper and deeper into issues with language handling, Display Managers...

Anyway, I just want to get this all down here, for future reference if nothing else.

Yesterday afternoon, after realizing that there seems to be a shift away from setting users' locales in ~/.dmrc to using accountsservice, I spent the afternoon trying to find how to do that through the Official Channels (dbus) rather than just editing /var/lib/AccountsService/users/<user> There is no documentation on accountsservice's dbus interface, but finally via this and this found commands which work:

user_path=($(dbus-send --print-reply=literal --system --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.FindUserByName string:"$USER"))
dbus-send --system --dest=org.freedesktop.Accounts "${user_path[0]}" org.freedesktop.Accounts.User.SetLanguage string:"$LANG"

Felt quite pleased with myself at that point, but today found this scathing putdown of accountsservice and totally failed to Google up any mention of a language selection GUI (or any other) utility in MATE, on Debian anyway.

damo wrote:

...a bunch of warnings which went away after installing accountsservice...

( https://forums.bunsenlabs.org/viewtopic … 930#p75930 )
Damo, what kind of warnings were you getting? Any other thoughts about accountsservice?

Language selection with LightDM is an old, old bug that we shipped a fix for from BL Hydrogen here, based on this Debian bug report post

So the new setlocale script will work on BL, because /etc/X11/Xsession.d/21bunsen-lightdm-locale looks at .dmrc and sets the right LANG and LANGUAGE variables from that. (Some Debian/Launchpad posters have recommended checking /var/lib/AccountsService/users/<user> as an alternative to .dmrc.) But that Xsession file only springs into action if LightDM is running, because other DMs were supposed to do the Right Thing anyway, but now without more testing I'm not quite so sure.

I tested on a Buster system with the default MATE desktop. This also uses LightDM+slick-greeter but I couldn't find any UI for setting the user language. I tried running my setlocales script - this writes to .dmrc and also calls accountsservice and appears to be working, but while LANG is set correctly, LANGUAGE is still at whatever is in /etc/default/locale (install-time setting I guess). MATE lacks our BL fix, so LANGUAGE is not being changed either by LightDM or accountsservice.

With a wrong LANGUAGE the user interface language is not set up properly. (An unset LANGUAGE would be OK in fact, but if it's set it should match LANG.)

Also have an LXQT Buster install on a laptop - LXQT provide a language chooser, so I didn't try setlocale.sh, but again LXQT's utility sets LANG but leaves LANGUAGE at the system default, so it doesn't work properly either.

All of this can be worked round by setting LANG and LANGUAGE in the user's ~/.xsessionrc, but that would override the variables if they had happened to be set correctly via some other interface, breaking it. It would be better if the script worked alongside any other language-setting utilities, rather than usurping them.

Another option would be to remove the LightDM test from BL's etc/X11/Xsession.d/21bunsen-lightdm-locale so that it sets LANG and LANGUAGE from /var/lib/AccountsService/users/<user> and ~/.dmrc regardless of what Display Manager the user has installed. (That would still allow users to override variables in ~/.xsessionrc if they wanted.) That fix ought to work on BL, but as I said it would be nice if setlocale.sh were useful for other simple DEs too.

Getting a bit lost here - does anyone have any comments on any of this?
Any of our distro-hoppers - how do other DEs handle language choosing?

Last edited by johnraff (2019-03-24 04:59:42)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#2 2019-03-23 10:34:38

damo
....moderator....
Registered: 2015-08-20
Posts: 5,059

Re: locales rabbithole

Getting a bit lost here - does anyone have any comments on any of this?

Not as lost as I would be if I tried to delve into it!


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#3 2019-03-27 08:15:55

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

Snippets, part 1

Setting the Locale through Environment Variables

In particular, LANGUAGE is not needed. LANG is enough for most cases, and sets all the LC_* subvariables, including LC_MESSAGES. If LANGUAGE is set, though, I'm pretty sure it overrides LC_MESSAGES. (LANGUAGE has the use that it can specify fallback languages in case the user's preferred translation is not available.)

Before the user specifies locale variable(s), the system will provide some, maybe from /etc/default/locale. The Display Manager (LightDM for BunsenLabs) will also attempt to set a locale. (In LightDM's case, this fails miserably.)

Whether LANGUAGE is defined in /etc/default/locale or not seems to depend on some decisions made by the Debian Installer. It may also be overwritten by update-locale, a utility whose main purpose seems to be to edit /e/d/l.
Here's my current /e/d/l:

john@helium:~$ cat /etc/default/locale 
#  File generated by update-locale
#LANG="en_GB.UTF-8"
LANGUAGE="en_GB:en"

I haven't yet found out when update-locale is called, and by whom, but maybe it's the post-install script of some package?

Anyway, the main message is that LANGUAGE might, or might not, be set, and any locale utilites should be able to deal with both cases.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#4 2019-03-27 09:47:11

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 1,817
Website

Re: locales rabbithole

Just observing stuff,

on my Debian stretch only $LANG seems to be set (same on Manjaro openbox),

on my Raspian $LANG and $LANGUAGE and $LC_ALL are set. $LANG is always 'en_US.UTF-8' and $LANG != $LANGUAGE, but $LANGUAGE = $LC_ALL on Raspbian.

@johnraff, What tests or what kind of tests are needed?

Last edited by brontosaurusrex (2019-03-27 11:48:20)

Offline

#5 2019-03-28 04:38:25

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

^Thanks Bronto, that's useful data.
If you have a moment, maybe you could post the result of these?

cat /etc/default/locale
cat ~/.dmrc
cat /var/lib/AccountsService/users/"$USER" # This might not exist
locale

And, what DM are you using (LightDM or...)?

In fact, I think I'll make a little questionnaire, and invite especially the Distro-Hoppers... smile


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#6 2019-03-28 08:59:23

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 1,817
Website

Re: locales rabbithole

Using LightDM with Debian, link to 3 machines in your pm.

Offline

#7 2019-03-28 10:00:02

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

Another Debian bug on locales with LightDM (there are several):
https://bugs.debian.org/cgi-bin/bugrepo … bug=735251


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#8 2019-03-28 16:37:29

hhh
Meep!
Registered: 2015-09-17
Posts: 8,347
Website

Re: locales rabbithole

Boy rabbithole doesn't begin to describe this, does it? tongue

My first time messing with this as I only speak one language, American. monkey

Since I'm such a novice, I'm starting at the beginning, so apologies if this is all obvious. Maybe it will trigger something pr you'll catch something you missed, though.

The Debian Manual...

https://www.debian.org/doc/manuals/debi … the_locale

Note that this reference is based on gdm3. We can't offer gdm3 because it requires gnome-session, which requires gnome-shell, which requires gnome-settings-daemon, etc...

But what about 8.4.5, creating an entry in /etc/pam.d/lightdm pointing to a locale-x file in /etc/default? I assume where the man says 'auth' it's the same as 'session' in my file. I'm rebooting now...

-edit- Nothing, no change. I'm going to stop testing before I convert my system to Greek and can't tell what anything is anymore, but I'll keep an eye on this. Sorry I can't be of help, John.

-edit- Well, duh. Setting LANG via /etc/pam.d/lightdm/locale-x didn't work because ~/.dmrc changed it back. Trying again...

Offline

#9 2019-03-28 17:28:49

hhh
Meep!
Registered: 2015-09-17
Posts: 8,347
Website

Re: locales rabbithole

For what it's worth, once I disabled ~/.dmrc, that method is working for setting the language to en_GB.utf8 in my session while leaving the system's default as en_US.utf8...

rachel@TyrellCorp:~$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
rachel@TyrellCorp:~$ 

I'm guessing, though, that what you're trying to do is to have multiple languages available for a session and have a way to choose one. That's not possible from any lightdm greeter, though, is what you're saying.

Offline

#10 2019-03-28 18:12:06

hhh
Meep!
Registered: 2015-09-17
Posts: 8,347
Website

Re: locales rabbithole

@John, scathing critique or not, it seems that the tools provided are the ones we should use, meaning set the user language in AccountsService and lose ~/.dmrc...

https://help.gnome.org/admin/system-adm … er.html.en

https://wiki.archlinux.org/index.php/di … er_session

Offline

#11 2019-03-29 03:36:37

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

@hhh thanks for all the feedback.

re: accountsservice, have you tried setting a language there?
(As I said in the OP, it can be done via dbus as well as editing the file directly.)
I think my experience with LightDM was that accountsservice was ignored.
I'd love to handle the user language choice "properly" but I guess the key point is:

Arch Wiki wrote:

For display managers that use AccountsService...

Finding which DMs support which ways of setting LANG would be an interesting project...

LightDM just ignores everything, except the language choice it gets from lightdm-gtk-greeter, plus some arcane entrails of its own - hence the BL workaround. (MX Linux have also implemented a similar fix, but other Debian setups like lxde and MATE have not.)

The more I look at this mess, the more I think any users not using BL+LightDM should just put their locale envvars in ~/.xsessionrc.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#12 2019-03-29 04:56:44

hhh
Meep!
Registered: 2015-09-17
Posts: 8,347
Website

Re: locales rabbithole

johnraff wrote:

@hhh thanks for all the feedback.

re: accountsservice, have you tried setting a language there?
...
I think my experience with LightDM was that accountsservice was ignored.

After more time down the hole, confirmed. I didn't realize accountsservice was an Yves thing...

https://bugs.debian.org/cgi-bin/bugrepo … bug=733261

As you can see, his first question is what's in .dmrc. He then marks another bug WONTFIX, though with reason...

https://bugs.debian.org/cgi-bin/bugrepo … bug=734391

The more I look at this mess, the more I think any users not using BL+LightDM should just put their locale envvars in ~/.xsessionrc.

Agreed. I'm leaving my Language= in .dmrc where it was when I started looking into this, even though that method is somehow deprecated. tongue BTW, is that file generated by lightdm, do we provide it, what's the story?

Offline

#13 2019-03-29 09:29:45

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

hhh wrote:

BTW, is that file generated by lightdm, do we provide it, what's the story?

~/.dmrc is generated by LightDM if it doesn't exist. I had a feeling other DMs might use it too, but no longer so sure.

/etc/X11/Xsession.d/21bunsen-lightdm-locale is provided by us, based on (a little tweaked) one of those Debian bug report posts.

LightDM's behaviour might have changed a little bit since some of those threads. Some of that locales mess is coming courtesy of xfce anyway. The findings of Vladimir K in the above post seem to match mine

3. $LANG and $LANGUAGE are completely untouched by lightdm.
4. ~/.dmrc is always written with correct settings on login

I haven't looked at $GDM_LANG at all though.

If LightDM is used with the gtk greeter and the language selector enabled, then .dmrc is written with the chosen LANG at login (but the non-standard utf8 ending instead of UTF-8). However LANG is not set in the user environment. (EDIT: actually, LANG is sometimes set, but not usually in a useful way.) LANGUAGE is ignored. The BL fix above sets LANG and LANGUAGE (only if it's not unset) according to what's in .dmrc.

With slick-greeter, nothing is done at all.

For BunsenLabs - if running LightDM, whatever greeter - it's OK to set a Language in .dmrc because our Xsession fix will handle it. That's what the proposed setlocale.sh script does at the moment. However, users wanting to set their LOCALE by hand, not via the login GUI, are better off putting it in ~/.xsessionrc IMO.

If a BunsenLabs user switched to another DM I've no idea what will happen.

Last edited by johnraff (2019-03-30 05:17:00)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#14 2019-03-29 13:18:59

hhh
Meep!
Registered: 2015-09-17
Posts: 8,347
Website

Re: locales rabbithole

More time in the hole and I have the following. Some terminology clarification...

lightdm is the DM we use, lightdm-gtk-greeter is the greeter we currently use, slick greeter is the greeter we might use in lithium. Both greeters are for lightdm, there are other greeters as well (kde, razorqt, etc...)

re: ~/.dmrc, the behavior is the same for both of these greeters, it's lightdm itself that always writes a ~/.dmrc file if...

1) That file is not already present.

2) You have changed your session. If you just log back in no file is generated even if the .dmrc file is missing. If it is missing, your Language, if not set somewhere else by you, will fall back to the system default and running "locale" will show all fields blank (LANG= , LANGUAGE= ,etc...). If you change to any other session, even from Default Xsession to Openbox and even if Openbox is your only session option, lightdm will write a .dmrc file with the following (for example)...

[Desktop]
Language=en_US.utf8
Session=openbox

Changing your language there will make it the session language on next login, assuming you haven't set language somewhere that takes precedence, like ~/.xsessionrc.

If you add a locale in .xsessionrc (for example, on line 3 add 'LANG=de_DE.UTF-8') then, in this example, 'Language=en_EN.utf8' in .dmrc will be ignored and German will be the session language on next login.

If a user uses startx or another DM (other than gdm3, which uses AccountsService properly, and probably sddm, but I haven't tested that), they should use .xsessionrc to set the session language.

I hope that helps. big_smile

Offline

#15 2019-03-30 05:32:01

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

^That sums it up quite nicely.
Except:

Changing your language there (.dmrc) will make it the session language on next login...

That works on BunsenLabs because of our Xsession fix, but I'm not too sure how reliably LightDM by itself will set LANG. (MX have a fix too.)

---
I've just switched to sddm in my Lithium test VM. Have found nothing related to setting locales so far.

---
One of those Debian bug threads had an idea of putting the chosen language at the head of the list that LANGUAGE supports, instead of just overwriting it. ie (pseudo-code):

LANG=en_GB.UTF-8
if LANGUAGE is unset
then Leave it alone
if LANGUAGE=ja_JP:de_DE:en
then LANGUAGE=en_GB:ja_JP:de_DE:en

Not hard to do, and in real world cases might be preferable.
Alternatively, only prepend to LANGUAGE if it's already a colon-separated list, otherwise just overwrite it?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

#16 2019-03-30 08:23:11

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,740
Website

Re: locales rabbithole

This seems to work, in sh too, it doesn't need bash:

mk_language(){ 
    [ -z $LANGUAGE ] && return 0
    NEWLANGUAGE=$1
    case $LANGUAGE in
    *:*)
    {
        local IFS=:
        for i in $LANGUAGE
        do
            [ "$i" = "$1" ] || NEWLANGUAGE="${NEWLANGUAGE}:${i}"
        done
    }
    ;;
    esac
    LANGUAGE=$NEWLANGUAGE
    echo "LANGUAGE is now $LANGUAGE"
}

# test it

$ LANGUAGE=ja_JP:de_DE:en_US:en
$ mk_language en_GB
LANGUAGE is now en_GB:ja_JP:de_DE:en_US:en
$ mk_language en_US
LANGUAGE is now en_US:en_GB:ja_JP:de_DE:en
$ LANGUAGE=en_GB
$ mk_language en_US
LANGUAGE is now en_US
$ LANGUAGE=
mk_language en_US
$ echo "$LANGUAGE"

$ 

John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Online

Board footer

Powered by FluxBB