Bug 496076

Summary:	Broken locales when only LANG is defined in plasma-localerc
Product:	[Applications] systemsettings	Reporter:	Aidan Harris <me>
Component:	kcm_regionandlang	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED DOWNSTREAM
Severity:	normal	CC:	hanyoung, nate
Priority:	NOR
Version First Reported In:	master
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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.