18.02.2021 23:04, Bjoern Voigt пишет:
To variables LANGUAGE, LANG and the LC_* variables are read from .config/plasma-localerc and non-empty variables are set as environment variables. In reality .config/plasma-localerc configured in system settings with English as first language and German as second language (as suggested in the bug reports)
[Translations] LANGUAGE=en_US:de
Which explains German language.
from .config/plasma-localerc results in LANGUAGE=de:en_US:en_US:de (in Konsole) and LANGUAGE=en_US:de (in gnome-terminal). So probably Konsole does extra processing of $LANGUAGE. But even gnome-terminal (in KDE desktop) behaves incorrectly.
Both terminals do only show German messages: myuser@myuser:~> rm does-not-exists rm: das Entfernen von 'does-not-exists' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
"strace" shows, that "rm does-not-exists" searches messages in this sequence (first: en_US, second: de - but en_US has no translation files):
Exactly. LANGUAGE is used by gettext i18n library. LANGUAGE lists message catalogs in order of preference, *each* message strings is looked up in *every* catalog, the first translation found is used with built-in (usually English) message strings being fall back if none of other translation for requested message is found. The problem is, English message "translations" almost never exist, because they are already part of program. In rare cases there may be some special catalogs for small part of messages (like spelling difference between American English and British English) but then you have situation when /some/ messages are displayed in English and most are displayed in next language set in LANGUAGE. gettext does not provide API to declare "my program has built in message strings in language en/de/es/...". May be it should. Also if catalog for language is incomplete (happens quite often) some message strings will be displayed in the first language, some - in the second one etc. That is more or less similar to language preference in web browsers - it defines the most preferred language, but also says - if page in this language does not exist, fetch it in the next one. Same logic here. The additional problem in case of KDE is also that KDE is using own locale management framework which simply cannot be mapped into glibc/POSIX one without losing functionality. glibc expects triples language_territory.charset while KDE allows setting each component (and more) completely independently. Which sometimes also leads to bizarre effects with non-KDE programs started in KDE environment.