[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Thiago Macieira]

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 
two scenarios:

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