[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems
thiago.macieira at intel.com
Sun Nov 3 17:22:12 CET 2019
On Saturday, 2 November 2019 22:35:00 PST André Pönitz wrote:
> Compiled opt-in per-application at least shifts the blame from Qt to the
> application vendor, compiled opt-in per-process environment leaves the blame
> still with the application vendor, but actually provides the possibility to
> do the right thing when it is known that the child actually _needs_ it.
When the parent process written in Qt knows that the child needs it, they must
already be using QProcessEnvironment.
So when the user needed to do it, it's a bug in the Qt application. There are
1) when the child process needs en_US or C, because it was printing messages
in another language, or far more commonly, it was using thousands and decimal
separators other than those of English
2) when the child process needs a non-UTF-8 because it was confused by UTF-8
multibyteness or was using that to print “fancy quotes”
The case (1) is not a problem if we override the environment to en_US.UTF-8 or
C.UTF-8. Your scenario is restricted to case (2).
Do note that forcing the environment today, in Qt 5, has implications for the
Qt application itself. It's just wrong to do so and I think the number of
people doing that is fairly small. With this proposal, in Qt 6, the Qt
application would run correctly. But that means that the overriding you're
asking for is unlikely to exist *today*.
So if we're talking about the future, why is using an environment variable to
suppress the Qt's override not sufficient?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development