Bug 496076 - Broken locales when only LANG is defined in plasma-localerc
Summary: Broken locales when only LANG is defined in plasma-localerc
Status: RESOLVED DOWNSTREAM
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_regionandlang (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-11 06:32 UTC by Aidan Harris
Modified: 2024-11-14 16:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aidan Harris 2024-11-11 06:32:15 UTC
When only LANG is defined in plasma-localerc, locales get set like this:

$ locale
LANG=en_GB.UTF-8
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

This breaks locales and results in cryptic error messages like:

iconv: illegal input sequence at position 32
Error converting string from ANSI_X3.4-1968 to UTF-8

I don't know why my plasma-localerc was set like this, maybe a hangover from a previous version of KDE or something that wasn't migrated right but changing the region to American English and back again fixed it and resulted in the following changes to my configs:

$ sudo snapper -cconfig diff 6624..6626 | less -rf
--- /home/ahrs/.config/.snapshots/6624/snapshot/plasma-localerc 2020-03-31 23:57:53.539048957 +0000
+++ /home/ahrs/.config/.snapshots/6626/snapshot/plasma-localerc 2024-11-11 06:20:25.784709014 +0000
@@ -1,2 +1,12 @@
 [Formats]
-LANG=en_GB.UTF-8
+LC_ADDRESS=en_GB.UTF-8
+LC_MEASUREMENT=en_GB.UTF-8
+LC_MONETARY=en_GB.UTF-8
+LC_NAME=en_GB.UTF-8
+LC_NUMERIC=en_GB.UTF-8
+LC_PAPER=en_GB.UTF-8
+LC_TELEPHONE=en_GB.UTF-8
+LC_TIME=en_GB.UTF-8
+
+[Translations]
+LANGUAGE=en_GB

Is this something that can be migrated automatically somehow? Presumably there are other users in this situation too.
Comment 1 Nate Graham 2024-11-13 18:28:49 UTC
I don't recall us ever supporting such a configuration in the past, and we don't right now. This seems like a user or distro misconfiguration. I don't think there's anything for us to do here, sorry.
Comment 2 Aidan Harris 2024-11-13 18:40:09 UTC
(In reply to Nate Graham from comment #1)
> I don't recall us ever supporting such a configuration in the past, and we
> don't right now. This seems like a user or distro misconfiguration. I don't
> think there's anything for us to do here, sorry.

It worked fine in the past, only recently did KDE start defaulting to the C locale in this situation. I wish I knew how it ended up in this situation, it's definitely KDE because if I ssh into the machine or login to another tty the locales are set correctly. It's only the result of the plasma-localerc file that was causing this.

Sorry, for the noise. Thought it was worth reporting this anyway.
Comment 3 Nate Graham 2024-11-13 19:07:51 UTC
Hmm, any thoughts, Han?
Comment 4 Aidan Harris 2024-11-13 19:53:44 UTC
For what it's worth, I can't seem to replicate this anymore. It may have been the fault of a recent upgrade.
Comment 5 hanyoung 2024-11-14 16:26:26 UTC
If I ran `LANG=en_GB.UTF-8 LC_ALL=C locale` in terminal, I get the same output as yours. So I think maybe in plasma-localerc, the previous setting was just $LANG, $LC_* were unset.

The LC_ALL maybe coming from the distro setting. It worked okay because previously distro doesn't set LC_ALL? And once it did, the locale broken (LC_* inherit LANG if LC_ALL is not set).

Nonetheless, with the current "if LANG is set, also set all LC_*" approach, situations like these can be avoided.