After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755648 - System locale not set on single-user system, unable to set manually
System locale not set on single-user system, unable to set manually
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Region & Language
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-25 21:09 UTC by Seán de Búrca
Modified: 2016-01-18 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
region: Ensure that system and user formats are consistent (8.08 KB, patch)
2015-10-01 16:46 UTC, Rui Matos
committed Details | Review

Description Seán de Búrca 2015-09-25 21:09:11 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.
Comment 1 Rui Matos 2015-09-29 11:13:53 UTC
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?
Comment 2 Seán de Búrca 2015-09-29 13:28:04 UTC
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.
Comment 3 Rui Matos 2015-09-29 13:32:59 UTC
(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' ?
Comment 4 Seán de Búrca 2015-09-29 18:55:19 UTC
$ localectl 
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us
Comment 5 Rui Matos 2015-09-30 13:02:55 UTC
(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?
Comment 6 Seán de Búrca 2015-09-30 18:18:34 UTC
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.
Comment 7 Rui Matos 2015-10-01 16:42:35 UTC
Does that mean that now you can always change the system locale?
Comment 8 Rui Matos 2015-10-01 16:46:09 UTC
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.
Comment 9 Seán de Búrca 2015-10-01 21:42:24 UTC
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.
Comment 10 Rui Matos 2016-01-18 13:56:57 UTC
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