Bug 507258

Summary: The languages offered are either invalid or don't match glibc
Product: [Applications] systemsettings Reporter: Andreas Schneider <asn>
Component: kcm_formatsAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: dennis.lissov, hanyoung, nate
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://sourceware.org/bugzilla/show_bug.cgi?id=33190
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Andreas Schneider 2025-07-20 07:01:22 UTC
This is a followup to https://bugs.kde.org/show_bug.cgi?id=403580 which doesn't seem to be fixed.

SUMMARY
I'm German but want my workstation to be English with ISO8601 dates. To achieve that I use:

export LANG="en_US.UTF-8"

export LC_ADDRESS="de_DE.UTF-8"
export LC_COLLATE="C.UTF-8"
export LC_CTYPE="de_DE.UTF-8"
export LC_IDENTIFICATION="C.UTF-8"
export LC_MEASUREMENT="de_DE.UTF-8"
export LC_MESSAGES="C.UTF-8"
export LC_MONETARY="de_DE.UTF-8"
export LC_NAME="en_DK.UTF-8"
export LC_NUMERIC="de_DE.UTF-8"
export LC_PAPER="de_DE.UTF-8"
export LC_TELEPHONE="de_DE.UTF-8"
export LC_TIME="en_DK.UTF-8"

The en_DK locale has d_fmt set to ISO8601 date (install glibc locale soruces).

grep d_fmt /usr/share/i18n/locales/en_DK 
d_fmt    "%Y-%m-%d"

However, if you set en_DK for LC_TIME in ~/.config/plasma-localerc you get a completely different time format in KDE/Plasma. If you scroll through the list in system settings look for an ISO8601 date, you find en_SE. If you set it the plasma the time/date is ISO8601, however the rest of your system stops working.

The locale doesn't really exist in the system:

lsd -l /usr/share/i18n/locales/en_SE
lsd: /usr/share/i18n/locales/en_SE: No such file or directory (os error 2).

With LC_TIME=en_SE set in plasma-localerc, a lot of application stop working. Here is an example:

Jul 19 19:22:42 magrathea solaar[4725]: Traceback (most recent call last):
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/bin/solaar", line 53, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     import solaar.gtk
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/solaar/gtk.py", line 34, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     from solaar import cli
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/solaar/cli/__init__.py", line 25, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     from logitech_receiver import base
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/logitech_receiver/base.py", line 34, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     from . import base_usb
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/logitech_receiver/base_usb.py", line 30, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     from solaar.i18n import _
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/solaar/i18n.py", line 62, in <module>
Jul 19 19:22:42 magrathea solaar[4725]:     set_locale_to_system_default()
Jul 19 19:22:42 magrathea solaar[4725]:     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib/python3.13/site-packages/solaar/i18n.py", line 49, in set_locale_to_system_default
Jul 19 19:22:42 magrathea solaar[4725]:     locale.setlocale(locale.LC_ALL, "")
Jul 19 19:22:42 magrathea solaar[4725]:     ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
Jul 19 19:22:42 magrathea solaar[4725]:   File "/usr/lib64/python3.13/locale.py", line 615, in setlocale
Jul 19 19:22:42 magrathea solaar[4725]:     return _setlocale(category, locale)
Jul 19 19:22:42 magrathea solaar[4725]: locale.Error: unsupported locale setting
Jul 19 19:22:42 magrathea systemd[4015]: app-solaar@autostart.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited


locale.setlocale(locale.LC_ALL, "") fails because there is no LC_TIME=en_SE locale!

Reprocuder:

LC_TIME=en_SE.UTF-8 python3                
Python 3.13.5 (main, Jun 11 2025, 22:06:31) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    locale.setlocale(locale.LC_ALL, "")
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting


LC_TIME=en_DK.UTF-8 python3
Python 3.13.5 (main, Jun 11 2025, 22:06:31) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=de_DE.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=C.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=de_DE.UTF-8;LC_TELEPHONE=de_DE.UTF-8;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C.UTF-8'


Where are those locales coming from?
Why doesn't the KDE en_DK match the en_DK in glibc?


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: openSUSE Tumbleweed
KDE Plasma Version: plasma6-desktop-6.4.2-1.1.x86_64
KDE Frameworks Version: libKF6ConfigCore6-6.16.0-1.1.x86_64
Qt Version: qt6-core-devel-6.9.1-2.1.x86_64
Comment 1 Andreas Schneider 2025-07-20 07:06:58 UTC
According to Mike, the list is coming from libicu, but plasma sets it as glibc locales. Those need to be separated.
Comment 2 Andreas Schneider 2025-07-20 07:10:34 UTC
kcm_formats writes the file `.config/plasma-localerc` with locales from libicu, however those are system variables which only work with glibc locales!

You need to configure the plasma languages and what you export as locales for glibc seperately!

`.config/plasma-localerc`

```
[Formats]
LANG=en_US.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_NAME=en_DK.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_TIME=en_SE.UTF-8
```
Comment 4 hanyoung 2025-07-20 07:45:56 UTC
Currently, we just return all the language Qt locale offers, which is coming from icu. Maybe we need to filter out the locale unsupported by glibc?

As for en_DK time format issue, there is little we can do. Because the definition is different between glib and icu for the same locale.
Comment 5 Andreas Schneider 2025-07-20 14:16:43 UTC
I would like to use en_SE in KDE to display ISO8601 dates correctly.

In order to achieve that, I think ~/.config/plasma-localerc needs a section for ICU formats a second for glibc formats! Only the glibc formats should be exported a environment variables then.

If a user selects a language, lets say for date/time, KDE should do:

  stat /usr/lib/locale/<LANG>/LC_TIME

if the file doesn't exist, set LC_TIME=C. This is the glibc default language. Other languages often require a glibc-lang package to be installed. 

Another solution is if the stat fails that you give the user a list of the directories in /usr/lib/locales and let him select one.

Just some ideas how to fix this. Let me know what you think.
Comment 6 hanyoung 2025-07-20 14:27:17 UTC
> Only the glibc formats should be exported a environment variables then.

Both glibc and Qt read locale from the same environment variables, it's not possible to only export locale for one system.
Comment 7 Andreas Schneider 2025-07-20 15:38:57 UTC
Then KDE needs to filter out all languages not in glibc.
Comment 8 hanyoung 2025-07-26 10:21:23 UTC
This MR should fix it: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5706
Comment 9 Andreas Schneider 2025-08-09 07:26:15 UTC
FYI: I was able to add en_SE to glibc: https://sourceware.org/git/?p=glibc.git;a=commit;h=a6eb8285d9bfb7ec0875b85ca356e833ff964d4f
Comment 10 Nate Graham 2025-09-24 20:40:42 UTC
That MR was merged; should this be marked as resolved now?
Comment 11 hanyoung 2025-09-25 13:41:14 UTC
(In reply to Nate Graham from comment #10)
> That MR was merged; should this be marked as resolved now?

Bugzilla no longer sync the information from invent.kde.org MRs?
Comment 12 Nate Graham 2025-09-25 13:52:45 UTC
There have been some hiccups recently, but in general it works.

Should this be marked as RESOLVED FIXED?
Comment 13 hanyoung 2025-09-25 14:23:56 UTC
(In reply to Nate Graham from comment #12)
> There have been some hiccups recently, but in general it works.
> 
> Should this be marked as RESOLVED FIXED?

Yes please, thx