| Summary: | Krita cannot load translation when running from a path with unicode characters under Windows | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Tyson Tan <tysontanx> |
| Component: | Translation | Assignee: | amyspark <amy> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alvin, amy |
| Priority: | NOR | ||
| Version First Reported In: | 4.4.5 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/11db240d822ef3dc728e924f0b0d3ada147c582a | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
|
Description
Tyson Tan
2021-06-10 14:54:36 UTC
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 |