Language selection always falls back to English

Bug #1276072 reported by Alexis Scheuer on 2014-02-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LightDM GTK+ Greeter
Fix Released
Sean Davis
lightdm (Ubuntu)
Gunnar Hjalmarsson
lightdm-gtk-greeter (Ubuntu)
Gunnar Hjalmarsson

Bug Description

I upgraded two amd64 computers from 13.04 to 13.10, and discovered on both that the language is set to English (whereas I selected French language at the beginning of the upgrade).
Moreover, each time I set it back to French, dragging both French (France and Canada) and some English (UK & US) on top of the default English in the language selection list, default English comes back on top at next login.

I even tried to modify my .pam_environment (in console mode) and the /etc/environment to set fr_FR as the default, no way: gnome-language-selector seems to force default English as default at each connection!

Hopefully, I do understand English, but this is turning me mad.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: language-selector-gnome 0.116
ProcVersionSignature: Ubuntu 3.11.0-15.25-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Tue Feb 4 10:48:33 2014
InstallationDate: Installed on 2013-07-29 (190 days ago)
InstallationMedia: Xubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423.1)
MarkForUpload: True
PackageArchitecture: all
SourcePackage: language-selector
UpgradeStatus: Upgraded to saucy on 2014-02-03 (0 days ago)

Alexis Scheuer (alexis-scheuer) wrote :
Gunnar Hjalmarsson (gunnarhj) wrote :

Dragging some French option to the top in Language Support should be sufficient. Please make sure that it stays on top before closing Language Support. (You may need a couple of attempts.)

There is normally no reason to edit ~/.pam_environment manually, and /etc/environment should not be used at all for setting language/locales. However, since you did edit ~/.pam_environment, it might explain why it doesn't work as expected. Can you please post the contents of your ~/.pam_environment file.

Changed in language-selector (Ubuntu):
status: New → Incomplete
Alexis Scheuer (alexis-scheuer) wrote :

Well, after a few complementary tests, I found out that this is a lightdm bug!

In fact, on one computer (using Xubuntu), the session's options, as session's type (Unity, Gnome, xfce, openbox, ...) and language (!), are not kept from one session to the next, as it used to be, and need to set manually at each connection. On the other computer (using Lubuntu), only the type option seems to be kept, not the language which has to be set manually...

I did not find any bug report about lightdm. Can this bug be changed, or should I create a new one?

Gunnar Hjalmarsson (gunnarhj) wrote :

What makes you think that lightdm has anything to do with it? Actually, lightdm is not involved at all when you set the language from Language Support. L-S calls accountsservice, which both saves the language as an accountsservice property and updates ~/.pam_environment. This should work the same way in Ubuntu, Xubuntu and Lubuntu.

If you have studied the ~/.dmrc file, I can tell you that lightdm does not use those settings since accountsservice is installed.

This bug report can be changed to whichever package is affected, so don't file a new report.

But before you change that, let's try to figure out what the real problem is. It would be valuable if you could provide a detailed step-by-step description with the steps you take and your observations.

Alexis Scheuer (alexis-scheuer) wrote :

Well, the point is that my ~/.pam_environment is modified (even if it is write-protected, funny) when I connect through the session manager (which is lightdm), and precisely at that moment (I did monitor this on tty1), but not when I connect on console mode (on tty1, for example).
And even now that I found the way to correct the language setting (by selecting it in the language selector of the session manager), I have to do it at each connection (it is set back to English) - in fact, I found that the session's type is correctly kept on both my computers, only the language is a problem. Otherwise (if it let English), the two first lines of my ~/.pam_environment are modified (to LANGUAGE=en \\ LANG=en_US.UTF-8). I add an archive with my current versions of /etc/environment and ~/.pam_environment.

And, at last, even now that I corrected the language setting, I found out that some translation are missing (update manager, synaptic, Gimp, evince, emacs, calculator, ...). I think I did not have this problem when I connected before (but I may be mistaken). The language setting does not seems correct, in fact: gnome-language-selector still shows English on top, and French at the bottom (and thus grey)... I however have some (about a half) of the main menu items in French...

As a conclusion, it only partially works with my turnaround.

Gunnar Hjalmarsson (gunnarhj) wrote :

~/.pam_environment write protected?? That breaks everything. You should:

1. Ensure that you have read/write access to ~/.pam_environment, so the system can do its job with respect to the language settings.
2. Remove all those language/locale entries in /etc/environment - only the PATH line should be kept.

Can you please do so, and let us know if that fixes it.

The partial translation is probably explained by a typo in ~/.pam_environment: There is no "fr-FR" language code, should be "fr_FR". ( Language Support/accountsservice would never have made such a typo. ;-) )

Alexis Scheuer (alexis-scheuer) wrote :

OK, you're right, the problems came from this typo. Everything is fine, now (I did modified manually the ~/.pam_environment because the language selection at the session opening did not correct it once - I don't know why it works now).

I just insist on the fact that a write-protected ~/.pam_environment does not break anything: it is modified whatsoever (I will try it again, but I am quite confident on it).

And I still have to select the correct language at connection, it is not kept from one session to the next.

Alexis Scheuer (alexis-scheuer) wrote :

I confirm both points (no problem with write-protected ~/.pam_environment, still have to select French).

Is there a way to set French as the default language (that is what I wanted when I changed the /etc/environment, but it did not work)?

Gunnar Hjalmarsson (gunnarhj) wrote :

It's probably the write protection that prevents the system from remembering the language. Why on earth do you want that?

* Make it editable.
* Use Language Support to change the language somehow, and instantly change it back.

That way accountsservice should save the language, and you don't need to actively select it before logging in. Let us know if that doesn't help.

Use the "Apply system-wide" button in Language Support to make your language the default language for the system. (That will save things in /etc/default/locale.)

Sorry, but:

- write protection of ~/.pam_environment was just for testing, I made it editable after but it did not change anything.

- the file /etc/default/locale is correct (I attach it), it does not prevent the default language from the session manager to be English...

Gunnar Hjalmarsson (gunnarhj) wrote :

Did you change the language back and forth using Language Support as I suggested?

Yes, several times, in two ways: change, log out, log in, change back, log out, log in, or change, change back, log out, log in, ...
Always the same behaviour: English is the default!

Gunnar Hjalmarsson (gunnarhj) wrote :

Can you please attach these files:



Yes, you've got the point: then language line is missing in /var/lib/AccountsService/users/scheuer.

Moreover, /var/log/lightdm/lightdm.log talks of a /var/log/lightdm/x-0-greeter.log, which says that directories /usr/share/lightdm/sessions and /usr/share/lightdm/remote-sessions (this is less important, I don't want to accept remote sessions) are missing.

I attach all that. Thanks, I now only need either the syntax to correct the file /var/lib/AccountsService/users/scheuer, or a way to get AccountsService to do it (should I add a /usr/share/lightdm directory?).

Gunnar Hjalmarsson (gunnarhj) wrote :

Now this is strange. I see in /var/log/lightdm/lightdm.log the entry "Greeter sets language fr_FR", and it's not followed by any error message. Still, as you say, Language is not set in /var/lib/AccountsService/users/scheuer.

Furthermore, since Language isn't set in /var/lib/AccountsService/users/scheuer, accountsservice should fall back to the language in /etc/default/locale. So French (France) should be pre-selected at login.

I wouldn't think that those warning messages in x-0-greeter.log are related. (I have one of those warnings myself.)

OTOH I'm kind of lost. I tested with my own relatively clean Xubuntu installation (it's Xubuntu you are using, right?), and it behaves as expected in this respect.

You could of course try to manually edit /var/lib/AccountsService/users/scheuer and add these lines:


affects: language-selector (Ubuntu) → accountsservice (Ubuntu)
Changed in accountsservice (Ubuntu):
status: Incomplete → New

Sniff! Sorry to tell you that: it does not work!

The point is that the file /var/lib/AccountsService/users/scheuer is rewritten (without the language settings) at each connection. Too bad!

And I don't understand either why the language setting does not fall back to the system language, defined in /etc/default/locale, but to the default one (English).

It may be an installation problem: if I remember well, I installed a Xubuntu 12.04, and upgraded to 12.10, 13.04 then 13.10 (but it worked quite well under 13.04 - I did not have this problem, at least).

Gunnar Hjalmarsson (gunnarhj) wrote :

Try to reinstall accountsservice:

sudo apt-get install --reinstall accountsservice

Gunnar Hjalmarsson (gunnarhj) wrote :

And maybe reinstall lightdm and lightdm-gtk-greeter too...

Gunnar Hjalmarsson (gunnarhj) wrote :

Another thought... Is your user ID 1000 or above?

About the message "Greeter sets language fr_FR" in/var/log/lightdm/lightdm.log , the next line is "Writing /home/scheuer/.dmrc" and indeed ~/.dmrc contains both language and session definitions.

I did the 3 reinstalls but did not have time to check.

About the ID, YES !!!! Hell, yes, my lab sets me a uid < 500, and I have the same on my laptop to simplify (I may perhaps do otherwise).

Gunnar Hjalmarsson (gunnarhj) wrote :

As a test, can you please create a user without forcing the uid become < 1000, and see if things work as expected for that user? I have a feeling this may be it.

Changed in accountsservice (Ubuntu):
status: New → Incomplete

OK, uid is a part of the problem (as I do not use the lab's NIS, and as mount procedures make mappings, I will change my uid).

However, a part of the problem remains: why does the greeter falls back to the default language (English) instead of the system language (defined as French/France in /etc/default/locale)?

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2014-02-08 11:42, A. Scheuer wrote:
> However, a part of the problem remains: why does the greeter falls
> back to the default language (English) instead of the system
> language (defined as French/France in /etc/default/locale)?

It falls back to the system language for me. Given a user with a normal uid in Ubuntu, can you describe a reproducible case where it doesn't?

Well, normal/abnormal uid is not the point: before I enter my login, the greeter selects English as language (at login, as well as after any connection - the one with uid > 1000 or the other one).

Moreover, I now have the Language and FormatsLocale in /var/lib/AccountsService/users/scheuer, but the language is not set when I enter this account's login, while they are not in the other's account file, for which the language is set correctly.

A new line appeared in these files, indicating SystemAccount=true/false (true when uid < 1000, false otherwise).

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2014-02-08 16:40, A. Scheuer wrote:
> Well, normal/abnormal uid is not the point: before I enter my login,

Wait now.. You say before you *enter*. Don't you select the > 1000 user using the select box? (It should be there, unlike the < 1000 user.)

Well, I do prefer to hide users and show manual login (this is my work laptop, am I paranoiac?).

Whatsoever, it does not change a lot: before entering login (or selecting it, it should be the same), the language selected is English (it should be the system one, i.e. French, don't you think?).

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2014-02-08 18:52, A. Scheuer wrote:
> Well, I do prefer to hide users and show manual login (this is my
> work laptop, am I paranoiac?).

Paranoiac or not, at least you make it hard for yourself. ;-)

> Whatsoever, it does not change a lot: before entering login (or
> selecting it, it should be the same),

Should? Did you try the selecting way?

> the language selected is English (it should be the system one, i.e.
> French, don't you think?).

It should be the user language, if set, otherwise the system one. And that's what it probably would have been if you had applied the default feature to *select* the user you want to log in as. At least that's how it works for me and other *ubuntu + lightdm-gtk-greeter users.

Currently it's accountsservice that provides the language. However, for accountsservice to be able to do so, you must pass a username to it, and that's what you do when *selecting* a user on the login screen.

You know what? Considering that you prefer to hide the user list from the login screen, it might work better for you if you disable the language selector feature in lightdm-gtk-greeter. You do so by setting


in /etc/lightdm/lightdm-gtk-greeter-ubuntu.conf

Well, the point is not to make it hard for myself (it's not so hard), but for anybody else who would like to login (this is my lab's recommendation).

You say "It should be the user language", but it can't be, not before I select a user (or enter a login, and I mean the login only, not the password).

And definitely no, it won't help to disable the language selector: I won't be able to correct accountsservice's wrong selection of the language.

I will try a few connections with the users list and without the language selector, but I would be *very* surprised if it changes anything.

Worse and worse!

Of course, the user list helps because the user selected automatically is the only non system user, for which language setting is OK (explain me why) even though it is not written in its file in /var/lib/AccountsService/users/.

But two new bugs appear:
1- the background image set in /etc/lightdm/lightdm-gtk-greeter.conf is not used for this user (uid > 1000), while it is for the system user (if I choose Other and type its login); moreover, the image is removed if I select back the normal user;
2- I have my laptop on a deck, connected to an external screen, and thus have two images of different resolutions on the wider (external) screen; the resolutions are correct for the default image (the one of XUbuntu, used for the normal user) but not for the system user (lower size image is stretched to the other's height, but not width).

Fine, we now have 3 bugs (system language should definitely be the one set in /etc/default/locale, not English). The only positive point (I forgot to mention it earlier) is that if language is changed once (either manually or because the normal user has been selected), it remains to the selected value.

Oups, I don't even have to type a login for the change to occur, selecting Other makes it happen.

And having the language selector shown or not does not change anything...

Well, after investigation, I have to use my special id account: I need it for NFS and autofs to work at my lab.

I removed the new account, using users-admin, but its configuration file in /var/lib/AccountsService/users/ was not removed (I did it myself).

The two new bugs are to a real problem , but it would be interesting to understand why lightdm behave so. I also think the language selection to be a lightdm bug: the system language of /etc/default/locale is not taken into account (before any user is selected - the fact that the language is not changed for system users is after all normal); using the language selector allows to get the right language...

Gunnar Hjalmarsson (gunnarhj) wrote :

I agree that the system language as set in /etc/default/locale should be the fallback language, so I prepared two merge proposals that should fix it. It would be great if you could fix a 14.04 install and test the packages I uploaded to my PPA at

affects: accountsservice (Ubuntu) → lightdm-gtk-greeter (Ubuntu)
Changed in lightdm-gtk-greeter (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Low
status: Incomplete → In Progress
Changed in lightdm (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Low
status: New → In Progress
Sean Davis (bluesabre) wrote :

The first of the two merge proposals has been released in lightdm-gtk-greeter 1.8.2

Changed in lightdm-gtk-greeter:
status: New → Fix Released
importance: Undecided → Low
assignee: nobody → Sean Davis (smd-seandavis)
milestone: none → 1.8.2
status: Fix Released → In Progress
Sean Davis (bluesabre) on 2014-03-02
Changed in lightdm-gtk-greeter:
status: In Progress → Fix Released

Hi, thanks for the fix.

I just have a question: what do you mean by "fix a 14.04 install"? I do not have enough disk space to have two systems on my computer: if I want to try 14.04, I have to upgrade to it, and I am not used to do it before a few months after the announcement, nor happy to try (as they are usually a lot of remaining bugs and my computer is my working tool - I need it to work well).

I could perhaps try to get a 1 GB USB key, and try it on it in persistent mode. Do you think that would fit?

Gunnar Hjalmarsson (gunnarhj) wrote :

Well, I hoped it would be easier for you.. I think the changes fix it. So then you'll find out in a couple of months if the behavior has approved. If not, you may want to file another bug. ;)

Thanks for being persistent!

Changed in lightdm-gtk-greeter (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lightdm-gtk-greeter - 1.8.2-1ubuntu1

lightdm-gtk-greeter (1.8.2-1ubuntu1) trusty; urgency=medium

  * Merge with Debian unstable, remaining changes:
    - debian/rules:
      + add indicators to dh_auto_configure
    - debian/control:
      + add depends for indicator support
      + add depends for liblightdm-gobject-1-dev (ubuntu naming is different)
      + fix binary-control-field-duplicates-source lintian tag
    - debian/copyright:
      + fix wiki-copyright-format-uri lintian tag
      + fix obsolete-field-in-dep5-copyright lintian tags
      + add missing license information
    - debian/lightdm-gtk-greeter-ubuntu.conf,
    - debian/lightdm-gtk-greeter.install,
    - debian/lightdm-gtk-greeter.{post,pre}{inst,rm},
    - debian/60-lightdm-gtk-greeter.conf:
      + install and remove ubuntu conf files
  * New upstream release (LP: #1286949).
    - Fixes segfault on uninstalled session (LP: #1272910)
    - Prefer the system default language over English (LP: #1276072)
    - Remember last session and language per user (LP: #1282139)
  * debian/lightdm-gtk-greeter-ubuntu.conf:
    - Updated per new template, replaced deprecated "show-indicators" key
  * debian/patches/update-session-language.patch:
    - Removed as fix is included upstream in 1.8.2
 -- Sean Davis <email address hidden> Sun, 02 Mar 2014 19:43:01 -0500

Changed in lightdm-gtk-greeter (Ubuntu):
status: Fix Committed → Fix Released
Changed in lightdm (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lightdm - 1.9.9-0ubuntu1

lightdm (1.9.9-0ubuntu1) trusty; urgency=medium

  * New upstream release:
    - Handle signals being received in child processes instead of treating them
      like they are received in the daemon.
    - Set utmp ut_line to the display name (i.e. :0) to match what other
      programs expect (e.g. 'w').
    - Fix lightdm_greeter_ensure_shared_data_dir_sync returning the wrong value.
    - Fix shared data tests so you can run test suite without root again.
    - Be extra careful not to call any non thread safe function after a fork.
    - Fix some small memory leaks detected by valgrind.
    - Fix process shutdown code to stop generating confusing warnings
    - Fix more double removal of source IDs.
    - Test improvements.

  [ Gunnar Hjalmarsson ]
  * debian/patches/04_language_handling.patch:
    - Make lightdm_get_language() return a language with a short form language
      code (LP: #1276072).
 -- Robert Ancell <email address hidden> Tue, 11 Mar 2014 09:17:15 +1300

Changed in lightdm (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers