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

[Thiago Macieira]

On Monday, 4 November 2019 10:29:16 PST André Pönitz wrote:
> All but one do not let the UI user change the environment, i.e. the
> environment is passed through the Qt UI process (so far). The one is
> Qt Creator, but even there it is not possible to configure all child
> processes, and would not be tolerable to tell users "When you create a
> new run configuration remember to undo spurious environment changes done
> by Qt".

It's highly unlikely you're running Qt Creator in a non-UTF-8 environment in 
the first place. KDE has not supported such locales for 15 years.

If we were in 2004-2006 when this was recent and other Unix environments like 
Solaris and HP-UXi where non-UTF-8 could be still in use I could understand 
the skepticism.

> <rant>
> There _are_ setups that _are_ set in stone, that are not connected
> to anything and that don't give anything on updates, or do not even
> have the possibility to be "fixed" or changed in any way.

Why are you inserting Qt 6 into them, then?

>     int main()
>     {
>         if (strcmp((setlocale(LC_COLLATE, "")), "C") != 0)
>             abort();
>     }
> 
> Looks contrieved? [Check your hard disk before you answer.]

I'll do a full search on Clear Linux to see if there's any software that 
checks the return value of setlocale().

> Potentially harmful behaviour should always be opt-in, not opt-out
> (and never be non-configurable).

I don't disagree on the statement. I just disagree on whether it's harmful. 
*Not* calling qputenv could be harmful too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products