On 15.04.25 11:26 PM, Marco Möller wrote:
On 4/15/25 18:24, Marco Möller wrote:
To unset LC_ALL use the following command:
$ sudo update-locale LC_ALL=
Dolphin now shows the wished display format for the columns showing
times.
There might be apps complaining about this value not being set,
though. Those apps could always be started by explicitly setting for
them a LC_ALL value in front of the app starting command, then.
Unfortunately, this cannot be the solution.
Too many apps used at the CLI complain about the missing LC_ALL
definition.
What I currently have set up:
$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_DE.UTF-8
LC_NAME=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_MEASUREMENT=en_DE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Even more confusing, even in Debian package "locales-all" there does not
exist "en_DE.UTF-8", just checked it for Trixie. But KDE System Settings
defined it, obviously. How can this be?
SOLVED:
A full day of life time lost to learn that KDE offers supposedly
available definitions in its selection lists under Region & Languages,
which in fact do not exist, like for instance the "en_DE" option does
not exist.
SOLUTION:
The user has to know that not all options can be used successfully,
although offered! Some of them are simply illusion.
Instead, the user demanding an international desktop environment has to
look up and only request options which originally appear in file:
/etc/locale.gen
At the bottom of this file there may, after many attempts to solve the
problem, appear some final lines:
# generated by KDE Plasma Region & Language KCM
en_DE.UTF-8 UTF-8
These lines are not to be understand as original. Actually, what is
listed here is a clear indicator for trouble! This, for example,
"en_DE.UTF-8" is exactly the option which shall be avoided to select in
KDE System Settings - Region & Languages.
Only having chosen valid options, LC_ALL can stay unset, then. Like this
LC_ALL will not overrule anything. If commands would not ask for
specific settings but for a global setting, like for the one possibly
defined in LC_ALL, then an automatic fallback mechanism will
alternatively read for them what is defined in LANG, if LC_ALL is not
defined. By this all CLI commands continue to work as expected.
Apps, which do interpret the specific settings individually, for
instance graphical apps like Dolphin running under KDE Plasma 6.3 in
Debian Trixie, can do so: they for instance can be displayed in one
language but using locale formatting from other languages.
Thus, a working setup is the following, for instance:
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
I am not sure if I should place a bug report to request KDE System
Settings - Region & Languages selection lists to not offer options prone
to provoke problems like the one I suffered and having burned so much
time of life. The internet is already full of similar reports, many
claiming that bug reports would have been placed already, but for years
not solved. The Year of the Linux Desktop will come, though!
I am really grateful to the developers of KDE, Debian, and many other
developers who make Linux possible! THANKS A LOT FOR IT!!
Still, concerning some parts of it, even after using it for some 25
years now, I only can shake my head in disbelief.
