Region & Languages: allow more granularity over regional settings
What is the issue?
Currently, the Regional Formats
, apart from the language choice (apparently being LANGUAGE
and LANG
), is just one setting, controlling multiples locales variables at the same time, from which you cannot deviate using. As far I can tell, this setting changes only LC_NUMERIC
, LC_TIME
, LC_MONETARY
, LC_PAPER
, and LC_MEASUREMENT
to one of the installed locales. This leads to uncomfortable problems for people whose personal/professional situations are not as straightforward as using one locale to set all these variables.
As far as I can tell, this also create a discrepancy in languages between applications using LC_TIME
instead of the one using LANG
, such as GNOME Calendar
.
A case could also be made for, say, LC_ADDRESS
and LC_TELEPHONE
, but, as far as I understand, it has been something gnome-session
implemented which did not make its way up to gnome-control-center
. Please, correct me if I am wrong.
Anyway, the current state of the regional settings is too simplistic, and as been a growing pain for more and more users over time.
What are the use-cases?
This change would prove beneficial for any user expecting these settings to not be correlated. Having choices over these do not seem like much, but it applies to any user who find themselves in a situation where these settings do not make sense together, and/or have to work with different formats.
These use-cases range from students studying abroad or workers who cross borders for work, to international organizations present in different countries, or even people working remotely from another country than the company is.
Difficulties and technical considerations
These use-cases boil down to the same need, being able to choose different formats/conventions, independently of what each locale has set in stone, for what could be seen as edge-cases, but are the daily reality of many. There are as many potentially required configurations as there are personal situations.
For what it's worth, this is one thing Windows and macOS do better than Linux, where you can select the currency, date and time format, etc. independently.
To be completely honest, I am not too sure about how this issue should preferably be tackled, since, while the problem is pretty straightforward at a glance, the underlying implementation problem is way less obvious.
-
I guess that some other refinements or other solutions could be used, but setting specific locale variables to other locales values could be a starting point.
-
Another potential solution would be to define a custom locale from scratch, depending on the selected settings ; while this seems "cleaner", IMHO, it requires root access and much more work, in order for each variable to be defined, and the custom locale to be generated, instead of using standard locales.
More complex solutions could be devised, but I do not think it would be wise.
For reference, this is what can be found about this in the gettext section on the GNU website:
LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, and so on, are the environment variables meant to override LANG and affecting a single locale category only. For example, assume you are a Swedish user in Spain, and you want your programs to handle numbers and dates according to Spanish conventions, and only the messages should be in Swedish. Then you could create a locale named ‘sv_ES’ or ‘sv_ES.UTF-8’ by use of the localedef program. But it is simpler, and achieves the same effect, to set the LANG variable to es_ES.UTF-8 and the LC_MESSAGES variable to sv_SE.UTF-8; these two locales come already preinstalled with the operating system.
Personally, this has been something that has been bugging me for many years, and new issues regarding this keeps pilling up, and not only on this issue tracker. I felt interesting to open another to try to be more exhaustive, and expose the current situation a bit better, in order to highlight why this is an actual issue, not a marginal one, especially in this day and age of remote work from/to different countries, with different conventions. Especially if this ends up being addressed, it would be better to ensure most use-cases are covered, to avoid having to rework it later.
Current workarounds
Currently, the only workarounds are to either edit the specific LC_*
values manually, or to create a custom locale, which are both less than user-friendly, and uniquely possible for (somewhat) advanced users. Both approaches lack an easy way to easily change the settings if/when necessary.
Steps to reproduce:
- Open GNOME Settings
- Click on
Region & Language
- Click on
Formats
- Click on a one of the locales provided
- Observe the fact that all settings change according to one locale
GNOME vs Windows 10 vs macOS comparison
For comparison's sake, here are a couple of screenshots.
Current state of Formats
with a few different locales, just for example:
As can be seen, the Windows/macOS GUIs are similar to what is done when defining a custom locale, but through the GUI instead of having to create the necessary files by hand (and generate the custom locale).
Interestingly, with the random settings shown in the previous screenshots, macOS locale
displays the following:
% locale
LANG=""
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=