TW: mutt no longer showing special characters
Hi list, Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings... (*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
* Peter Suetterlin
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.15 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
mutt-2.2.3-1.1.x86_64 Tw20220422 I see the "special" chars here LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Patrick Shanahan wrote:
mutt-2.2.3-1.1.x86_64 Tw20220422
I see the "special" chars here
Thanks for checking! It's somewhat weird. On the 'bad' machine, already the XTerm/shell cannot display the umlaut if I type it, I only get the 'ü' instead of an ü. A konsole terminal *does* display the umlaut correctly, but when I start mutt in there, I only get the '??' Not sure what to make of that :(
Peter Suetterlin wrote:
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
Oh wait. I had tested this remotely on the TW20220419 machine, using ssh login in a console, as the machine is at work (and I'm at home). If I use vnc to actually use the display of that machine, characters are fine there. So it must be some bad setting on the local machine, not related to mutt but likely the font system.....
On 2022-04-24 12:58, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
Oh wait. I had tested this remotely on the TW20220419 machine, using ssh login in a console, as the machine is at work (and I'm at home). If I use vnc to actually use the display of that machine, characters are fine there. So it must be some bad setting on the local machine, not related to mutt but likely the font system.....
What is the local machine running? -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-04-24 12:58, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
Oh wait. I had tested this remotely on the TW20220419 machine, using ssh login in a console, as the machine is at work (and I'm at home). If I use vnc to actually use the display of that machine, characters are fine there. So it must be some bad setting on the local machine, not related to mutt but likely the font system.....
What is the local machine running?
TW20220421/mutt 2.2.3, (as the remote/working one is the TW20220419/mutt 2.1.5 machine) I've just dup'ed to TW20220422 to be same state as Patrick, still need to reboot...
Peter Suetterlin wrote:
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
Yuck. So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8 However, that one does not exist! speedy:~% ls /usr/lib/locale/en_DE* ls: cannot access '/usr/lib/locale/en_DE*': No such file or directory Trying to find where LANG is actually set I eventually found .config/plasma-localerc: speedy:~% cat .config/plasma-localerc [Formats] LANG=en_DE.UTF-8 [Translations] LANGUAGE= Which seems to be set in System Settings -> Region -> Formats There a a *ton* of LANG definitions that just plain don't exist in the system. Why can I select those after all? locale seems to also look for a general definition like en.UTF-8 or en.utf8 if the sub-format cannot be found. But those don't exist either :( Should this be regarded as a bug?
Hello,
In the Message;
Subject : Re: TW: mutt no longer showing special characters
Message-ID :
On 2022-04-24 15:01, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Hi list,
Since one of the latest updates of my TW computers(*) mutt (running in XTerm, but it's the same in konsole) no longer is showing special characters (like accented ones). Are others seeing that, too? Any hints what to look for? I didn't change any of my settings...
(*) one is running TW20220421/mutt 2.2.3, the other one TW20220419/mutt 2.1.5 With LANG=en_GB.UTF-8 I get, e.g., "Zurück", LANG=en_DE.UTF-8 displays it as two questionmarks, "Zur??ck"
Yuck.
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist!
That causes problems. Find existing ones here: ls /usr/lib/locale/*_DE* ls /usr/lib/locale/en_* -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-04-24 15:01, Peter Suetterlin wrote:
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist!
That causes problems.
Find existing ones here:
ls /usr/lib/locale/*_DE*
ls /usr/lib/locale/en_*
Yes, I know. The question is why can I select it in the System Configuration if it doesn' exist? It should *at least* be marked with a warning that this will only work with KDE applications...
On 24.04.2022 16:01, Peter Suetterlin wrote:
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist! speedy:~% ls /usr/lib/locale/en_DE* ls: cannot access '/usr/lib/locale/en_DE*': No such file or directory
Trying to find where LANG is actually set I eventually found .config/plasma-localerc: speedy:~% cat .config/plasma-localerc [Formats] LANG=en_DE.UTF-8
[Translations] LANGUAGE=
Which seems to be set in System Settings -> Region -> Formats There a a *ton* of LANG definitions that just plain don't exist in the system. Why can I select those after all?
locale seems to also look for a general definition like en.UTF-8 or en.utf8 if the sub-format cannot be found. But those don't exist either :(
Should this be regarded as a bug?
This is known for years. The KDE (and now Qt) locale management is plain incompatible with POSIX one. KDE allows setting of individual categories and arbitrary mix and match while POSIX only allows choosing between predefined combinations. There was an idea for KDE to generate POSIX locale on the fly. I do not think it was ever implemented. If KDE offers possibility to disable exporting of these fake locales, this is probably the only option.
On 24.04.2022 17:24, Andrei Borzenkov wrote:
On 24.04.2022 16:01, Peter Suetterlin wrote:
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist! speedy:~% ls /usr/lib/locale/en_DE* ls: cannot access '/usr/lib/locale/en_DE*': No such file or directory
Trying to find where LANG is actually set I eventually found .config/plasma-localerc: speedy:~% cat .config/plasma-localerc [Formats] LANG=en_DE.UTF-8
[Translations] LANGUAGE=
Which seems to be set in System Settings -> Region -> Formats There a a *ton* of LANG definitions that just plain don't exist in the system. Why can I select those after all?
Qt is using internal locale definitions that are based on Unicode Common Locale Data Repository, not POSIX/glibc locale database. These locales *do* exist in CLDR.
locale seems to also look for a general definition like en.UTF-8 or en.utf8 if the sub-format cannot be found. But those don't exist either :(
Should this be regarded as a bug?
This is known for years. The KDE (and now Qt) locale management is plain incompatible with POSIX one. KDE allows setting of individual categories and arbitrary mix and match while POSIX only allows choosing between predefined combinations.
There was an idea for KDE to generate POSIX locale on the fly. I do not think it was ever implemented.
If KDE offers possibility to disable exporting of these fake locales, this is probably the only option.
Or carefully selecting only those locale definitions that are known to exist in POSIX.
Andrei Borzenkov wrote:
On 24.04.2022 17:24, Andrei Borzenkov wrote:
On 24.04.2022 16:01, Peter Suetterlin wrote:
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist! speedy:~% ls /usr/lib/locale/en_DE* ls: cannot access '/usr/lib/locale/en_DE*': No such file or directory
Trying to find where LANG is actually set I eventually found .config/plasma-localerc: speedy:~% cat .config/plasma-localerc [Formats] LANG=en_DE.UTF-8
[Translations] LANGUAGE=
Which seems to be set in System Settings -> Region -> Formats There a a *ton* of LANG definitions that just plain don't exist in the system. Why can I select those after all?
Qt is using internal locale definitions that are based on Unicode Common Locale Data Repository, not POSIX/glibc locale database. These locales *do* exist in CLDR.
Hmm, then (IMO) it should trigger a dependency that adds those (to /usr/lib/locale) for compatibility with other programs. At least on distribution level, if KDE project isn't willing...
Or carefully selecting only those locale definitions that are known to exist in POSIX.
This. It's one thing if I use an editor to set LANG etc. myself in a config file, but a GUI should not allow to set values that are not available system-wide. IMHO of course again....
On Sun, 24 Apr 2022 18:12:31 +0100
Peter Suetterlin
Andrei Borzenkov wrote:
On 24.04.2022 17:24, Andrei Borzenkov wrote:
On 24.04.2022 16:01, Peter Suetterlin wrote:
So the problem is the locale setting: speedy:~% echo $LANG en_DE.UTF-8
However, that one does not exist! speedy:~% ls /usr/lib/locale/en_DE* ls: cannot access '/usr/lib/locale/en_DE*': No such file or directory
Trying to find where LANG is actually set I eventually found .config/plasma-localerc: speedy:~% cat .config/plasma-localerc [Formats] LANG=en_DE.UTF-8
[Translations] LANGUAGE=
Which seems to be set in System Settings -> Region -> Formats There a a *ton* of LANG definitions that just plain don't exist in the system. Why can I select those after all?
Qt is using internal locale definitions that are based on Unicode Common Locale Data Repository, not POSIX/glibc locale database. These locales *do* exist in CLDR.
Hmm, then (IMO) it should trigger a dependency that adds those (to /usr/lib/locale) for compatibility with other programs. At least on distribution level, if KDE project isn't willing...
Or carefully selecting only those locale definitions that are known to exist in POSIX.
This. It's one thing if I use an editor to set LANG etc. myself in a config file, but a GUI should not allow to set values that are not available system-wide. IMHO of course again....
So what's the bug number you've created? IMHO of course.
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
Masaru Nomiya -
Patrick Shanahan -
Peter Suetterlin