[Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems
thiago.macieira at intel.com
Fri Nov 1 22:49:36 CET 2019
On Friday, 1 November 2019 12:29:19 PDT André Pönitz wrote:
> > > My personal preference is:
> > > a) C.UTF-8
> > > b) override it to force UTF-8 on the same locale
> > > c) yes
> > I agree with all three choices.
> a) and b) are fine with me, "c) yes" sounds like a potential problem.
> Most of the child process I usually call are not Qt based, rather some
> random unrelated tools, in some cases even quite old random unrelated
TBH, all the more reason for propagating the choice. Please remember that on
any modern Linux or macOS or FreeBSD, they are already running with a UTF-8
locale. The most common scenario of our setting something is when LC_ALL=C was
set in the environment, which will cause us to reset it to C.UTF-8.
> > > ones, would not make the same choices. If we do not propagate, we could
> > > end up with a child process (often helpers) that make different choices
> > > as to what command-line arguments or pipes or contents in files mean.
> If we propagate we'll expose the child processes to locales they might not
> expect, in circumstances where the user of the system possibly intentionally
> chose a non-UTF8-locale to make exactly those child processes happy.
True, but that was done at the expense of running Qt in a largely unsupported
and untested scenario. Setting the locale to C means we can't access any file
with an 8bit file name; setting to Latin1 would allow that, but produce
mojibake in GUI.
> Effectively, going for "c) yes" deprives the user of a certain level of
> freedom that is needed, "c) no" is less intrusive.
> "c) no" as default and a simple one-liner opt-in for applications that
> want to engage in "strict parenting" might be an option, too.
How about making the resetting opt-out, instead of opt-in?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development