http://bugzilla.suse.com/show_bug.cgi?id=1095425 http://bugzilla.suse.com/show_bug.cgi?id=1095425#c2 --- Comment #2 from Lothar Paltins <lopa@mailbox.org> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.