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

[Edward Welbourne]

On 17 Apr 2023, at 18:16, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> But anything that goes through QIODeivce::read or write (QProcess,
>> QFile, Q{Udp,Tcp,Local}Socket) will suffer if there's no agreement on
>> what that encoding is.

And that's a cross-platform problem for anyone who has to consume data
produced by a (presumably non-Qt) source that's using legacy codecs.
At present our answer is to use Qt-with-ICU or some separate codec-converter.

>> [snip] What has changed is that the Windows API has matured to the
>> point that this is now a viable choice (previously, it was
>> experimental and known to cause issues). But it's still an
>> application choice; we can't enforce it.

But we *can* document how to do it as part of our "how to package your
application" instructions, thereby encouraging users of Qt to do so.

>> But I think we should:
>> a) do it for our own applications, since we do know our own code
>> b) advise users somehow that they should opt-in to this
>> c) decide if we want to change from opt-in to opt-out in the medium
>>    term (7.0 for example)
>> d) decide if we want to enforce it in the long-term
>>
>> Option (d) depends on (c). Option (c) informs whether we need a Qt
>> CMake API or whether we can simply say upstream CMake should handle
>> it.

Lars Knoll (18 April 2023 09:46) replied
> I think this should be the goal, but I’d vote for a slightly faster
> schedule.
>
> (a) and (b) are things we should be able to do right now.

Sounds sensible to me.

	Eddy.