Krita 4.4.5 and 5.0 nightlies cannot load translation when running from a path with unicode characters under Windows. This is a regression. Krita 4.4.3 did not have this bug. Reproduce: 1) Windows 10 21H1 tested 2) Download krita-x64-4.4.5.zip 3) Extract it to a directory with some unicode characters in its name, for example "测试" 4) Start Krita In this case Krita can only load English, although other languages were listed. Resource names like template categories are unaffected. Curiously some "OK" and "Cancel" buttons are unaffected (in Switch Application Language dialogue, for example). This is an issue relayed from the local community.
This is going to be a tricky one to fix, if we even want to attempt to fix it. My suspicion on the core issue is that ki18n uses `QFile::encodeName` to encode the locale directory [1], then passes it to `bindtextdomain` [2] of gettext. `QFile::encodeName` encodes the file path in "local 8-bit", which on Windows means the local ANSI codepage (e.g. CP936 aka almost-GBK on Simplified Chinese systems), whereas the path encoding expected by GNU gettext is unspecified -- it might be UTF-8, but it also depends heavily on which function it uses to open files. It is made more complicated that we ship a copy of gettext built by a third party. I'm not going to trace this one through. We might want to report this to ki18n (or perhaps change the product on this issue?) but personally I would just suggest nobody attempt to install Krita onto a path with non-ASCII names, because nobody can guarantee that everything else in Krita can work fully as expected. [1]: https://invent.kde.org/frameworks/ki18n/-/blob/v5.64.0/src/kcatalog.cpp#L96 [2]: https://invent.kde.org/frameworks/ki18n/-/blob/v5.64.0/src/kcatalog.cpp#L212
Actually, it seems that we do build gettext from source for Windows. The pre-built binaries are only for build-time execution. There seems to be a patch that makes gettext work with UTF-8 paths [1]. However, due to ki18n using `QFile::encodeName` instead of `QString::toUtf8`, there is an encoding mismatch. The correct fix should be for us to patch ki18n to use `QString::toUtf8` there to match our build of gettext. CC amyspark [1]: https://invent.kde.org/graphics/krita/-/blob/2fb33351f7f0ec193b1f22b0b46fd0aaa2bcb4b8/3rdparty/ext_gettext/0003-Fix-win-unicode-paths.patch
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/910
Git commit 11db240d822ef3dc728e924f0b0d3ada147c582a by L. E. Segovia. Committed on 15/06/2021 at 16:40. Pushed by lsegovia into branch 'master'. ki18n: fix loading our translations from Windows This commit introduces a patch to k18n, suggested by Alvin Wong, to make ki18n behave properly with our patched copy of gettext. The latter contains a patch of vcpkg to make it behave with UTF-8 paths on Windows, but this wasn't reflected on ki18n's initialization code. The patch works by inserting an additional define in libintl.h that flags the presence of vcpkg's UTF-8 patch. While at it, we update the libgnuintl.win32.h template file to match the underlying gettext version. CCMAIL: kimageshop@kde.org A +40 -0 3rdparty/ext_frameworks/0001-ki18n-fix-loading-catalogs-with-patched-gettext.patch M +11 -1 3rdparty/ext_frameworks/CMakeLists.txt M +4 -4 3rdparty/ext_gettext/0001-Fix-macro-definitions.patch M +6 -6 3rdparty/ext_gettext/0002-Fix-uwp-build.patch M +22 -6 3rdparty/ext_gettext/0003-Fix-win-unicode-paths.patch M +313 -270 3rdparty/ext_gettext/0004-vcpkg-CMake-toolchain.patch https://invent.kde.org/graphics/krita/commit/11db240d822ef3dc728e924f0b0d3ada147c582a
Thank you, guys! :D