On 4/13/25 10:06 AM, Kaulkwappe wrote:
Hi!
I use Fedora 41 KDE and my first and default language is English (primary) and
my second language (secondary) is German. However, the Bash shell wrongfully
uses the secondary language:
bash --version
GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder jünger <http://gnu.org/licenses/gpl.html>
Dies ist freie Software. Sie darf verändert und verteilt werden.
Es wird keine Garantie gewährt, soweit das Gesetz es zulässt.
It seems that the Bash shell suffers from a locale bug which Nate from KDE has
described as follows:
I don't think so. It all comes down to which strings are marked for
translation in the source and appear in the pot file, which strings
are translated in your locale and appear in the right bash.mo file,
and what gettext(3) does with the LANGUAGE environment variable.
According to
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_02
only gettext(3) looks at LANGUAGE, and that behavior can't be modified by
any calls to setlocale(3). gettext(3) is responsible for overriding
the `active category', which is LC_MESSAGES, according to what it finds
in $LANGUAGE.
If there is no installed locale for en_US, or no LC_MESSAGES bash.mo file
in the right place, gettext(3) will ignore that locale in $LANGUAGE.
So whether or not bash does anything with LANGUAGE -- it does not -- and
whether or not gettext(3) does the right thing with LANGUAGE -- it probably
does -- you see the translated version and copyright strings in the locale
that gettext(3) thinks you should.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
