https://bugs.kde.org/show_bug.cgi?id=438421
Alvin Wong <al...@alvinhc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
Ever confirmed|0 |1
--- Comment #1 from Alvin Wong <al...@alvinhc.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
