Comment # 2 on bug 1095425 from Lothar Paltins

But the current behavior is the big change. Until now, KDE and QT respected the
setting of the env variables LANG or LC_CTYPE. This has changed since one of
the last OpenSuse Tumbleweed updates. Now a hard coded character encoding is
assumed and the users environment setting is ignored. I've also filed a bug
against QT, because I thought, that this is a QT issue before I found out, that
it's caused by ICU. And the QT maintainer said, that on his system, ICU still
uses the environment setting and not a harcoded value.

Here's an excerpt from the readme.html file in the icu-61.1 package:

Hardcode the default charset to UTF-8: On platforms where the default charset
is always UTF-8, like MacOS X and some Linux distributions, we recommend
hardcoding ICU's default charset to UTF-8. This means that some implementation
code becomes simpler and faster, and statically linked ICU libraries become
smaller. (See the U_CHARSET_IS_UTF8 API documentation for more details.)

The hardcoding is only a recommendation. The question is, does Suse really want
to give up the freedom of choice of character encodings? I would expect such an
attitude from Microsoft and Apple, but not from a Linux distribution. 

I have compiled the Suse icu-61.1-1.1 package with U_CHARSET_IS_UTF8=0 without
problems and with all regression tests passing.