GNOME Bugzilla – Bug 755648
System locale not set on single-user system, unable to set manually
Last modified: 2016-01-18 13:57:01 UTC
My system's default locale is en_US.UTF-8. With only one non-root user created, I changed this user's locale to ga_IE.UTF-8 in the Region & Language panel. The login screen remains in English with US formats, but without creating a second user the panel does not give me the option to select a system-wide locale.
When there's only one user account on the system we actually change the system locale as well as the user's. The login screen won't be changed until you reboot though (or restart the GDM service), wasn't that the case for you?
This is not the case for me. Even after reboot, the login screen remains in English. Running `su -' followed by `locale' nets me en_US.UTF-8 as well.
(In reply to Seán de Búrca from comment #2) > This is not the case for me. Even after reboot, the login screen remains in > English. Running `su -' followed by `locale' nets me en_US.UTF-8 as well. What's the output of 'localectl' ?
$ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us
(In reply to Seán de Búrca from comment #4) > $ localectl > System Locale: LANG=en_US.UTF-8 This means that the system locale wasn't changed at all. To be clear: 1) Do you see a "Login Screen" button on the panel's top right? 2) Do you have localed messages in the journal when you change the language/region?
In reply to 1), I do not. However, in testing for 2), the system language was changed. To the best of my knowledge, neither my behavior nor the software version had changed. The only difference I'm aware of is that, previously, it was the first time setting a locale after the default set by the installer.
Does that mean that now you can always change the system locale?
Created attachment 312511 [details] [review] region: Ensure that system and user formats are consistent The formats (or 'region') setting might be unset meaning that it's the same as the language since that's what LC_TIME et al default to when unset. We already handle this for the user setting but for the system setting we're losing that semantic when getting it from localed since we don't allow priv->system_region to remain unset. This means that when users change the system language, the system formats will be explicitly set to the previous value of the system language instead of remaining unset and thus follow the new value for the system language. This isn't that bad on multi user systems where we display system settings separately from user settings, but on single user systems we change the system values to match the user values which, due to the above mentioned semantic difference regarding the region setting, means that when changing the language, the (unset) region will be displayed as the same as the language but the system region will be explicitly set to the previous language. Fix this by making the system region have the same semantic as the user's, i.e. allow it be remain unset until explicitly set by the user. -- I'm not entirely sure this fixes the issue reported here (I haven't even fully understood what's being reported tbh), but while doing some tests and looking at the code I noticed this bug.
Every time I change the locale now, the system locale is correctly set to the newly-selected locale. The issue only appeared the first time I changed my user language from the default en_US to ga_IE, wherein the system locale remained en_US despite only a single user being present on the system. I will attempt to reproduce this in the next few days to provide more detail.
This patch fixes a real bug so I'm pushing it anyway. If you can still reproduce this please re-open the bug. Attachment 312511 [details] pushed as 30470d7 - region: Ensure that system and user formats are consistent