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 710246 - Use GNOME-wide, not system-wide, locale settings when only one GNOME user
Use GNOME-wide, not system-wide, locale settings when only one GNOME user
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: Region & Language
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-16 08:33 UTC by Marko Myllynen
Modified: 2021-06-09 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marko Myllynen 2013-10-16 08:33:20 UTC
If there is only one local GNOME user with administrative privileges then when changing Region & Language->Language the change is immediately applied system-wide in /etc/locale.conf instead of being a contained GNOME-wide configuration change.

There are several issues with this approach:

1) While "root" is not a valid GNOME user it is a perfectly valid console user so the GNOME user is changing locale also for the superuser

2) The current approach does not seem to take into account network users in any way (I tested this by enabling SSSD in PAM configuration)

3) The current approach affects to non-GNOME processes as well. For example when changing language from default (English) to Russian under GNOME, rebooting to non-graphical mode (old school runlevel 3) I see the following because processes are affected by /etc/locale.conf:

# grep ru_RU /proc/*/environ | wc -l
30

This also means that with ru_RU a) all the messages from standard utilities on console are now completely unreadable even for Russian speakers since the system font is still unchanged, b) some programs are now logging in Russian (like pulseaudio), and c) if root wanted to restore the previous locale then it would also affect GNOME.

To address all these issues I propose to add "EnvironmentFile=/var/lib/gdm/.i18n" in the gdm.service file and then never touch system configuration files under /etc. Using ~/.i18n is inline what e.g. shell scripts on Fedora expect and this nicely removes the need to come up with additional logic / workarounds for cases like 2).

Moved here from downstream bug at https://bugzilla.redhat.com/show_bug.cgi?id=1014327.

Thanks.
Comment 1 Kamil Páral 2016-01-05 13:55:50 UTC
I'd like to chime in for this - please don't merge system and session locale configuration on a single user system, make them separate (switchable using the Login Screen button, as on a multi-user system). I understand you want to make things simple, but locales are never simple, and you're making some use cases very difficult with the current approach. I believe it's mostly caused by the fact that most developers are native English speakers or run their system in English locale. But in reality, this is the state of things:

* some languages have just a partial translation, especially for system cli tools
* some languages have very poor translation, making important messages hardly recognizable, especially for system cli tools
* some languages contain characters which are not rendered correctly in text mode out of the box
* some languages require input methods which don't work in text mode out of the box, or they behave differently than their X counterparts (especially console keyboard layout vs X keyboard layout matching is a very deep rabbit hole that never works properly for many languages)

For this reason, many non-english users tend to keep system locale to en_US, so that if something breaks, they are able to work with text mode properly, debug problems, search for error messages on the internet, etc. But they also switch their user session to their national language, because usually the desktop translations are far better, they are rendered correctly and the input methods works correctly. Unfortunately, this is not possible with current Region & Language dialog - you can't set separate system and session locale if you're the only user. But that's exactly what many many people want to do (including me).

There are also some corner cases which you forgot to take into account when implementing this - if you have multiple users and your system locale different from your session locale, and then delete the other users, Region & Language dialog will show your current session locale, but will not allow you to modify system locale (which is different). Users in this situation will be confused, because GNOME will claim their locale is X (when they know their system locale is Y), and there will be no way to adjust the system locale. Ditto for input methods. Rather than trying to fix this in code somehow, wouldn't it be easier to simply show user and system settings always separately? Clear and simple, no confusion, no use cases lost.
Comment 2 André Klapper 2021-06-09 16:07:21 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.