Re: Need help fixing failing locale tests

From: John Marino <freebsd.contact_at_marino.st>
Date: Sun, 15 Nov 2015 15:47:06 +0100
On 11/15/2015 3:39 PM, Andrey Chernov wrote:
> As I already say, I don't want to insist on any particular point of view
> in such area as human behavior. I just say that it is POLA violation
> (even while it is upgrade) and we can let users decide by themselves,
> what it best for them (without me at least).

I am starting to think "POLA" as an acronym is subject to abuse.  By
this definition, *any* change would "astonish" a user (picturing the
most incompetent user impossible too).

POLA is meant for unreasonable and unexplained changes.  I don't think
tidying up locales for the first time in a decade is unreasonable or
unexplained.

Let's not dilute "POLA".  It's pretty good but you can apply it to anything.

>>> I tell about is not different text document encoding, but program
>>> failure due to inability to set his 8859-1 locale.
>>
>> Please provide an example of such a program (in ports).
> 
> See gettext-0.19.6/gettext-tools/configure, part started with
> # Test for the usual locale name.
> I don't have time to dig more such code now, but I remember I saw more
> for sure.
> 
>>> In any case it is related to the user behavior an various views on it.
>>> They can be different and I see no point to insist on my particular view
>>> at all. But... Programs configure soft-fails shows real danger here.
>>
>> and the impact of this is ... ?
> 
> Various. It depends on for what reason program sense locale.

If the ports framework is not overriding locale to "C" during the build
then that's probably something that should be introduced.  Ports should
not be producing different results based on the configuration of the
building machine at the time.

Right?  It's also good practice because C/POSIX never results in illegal
sequence errors while locales such as UTF-8 easily can.

John
Received on Sun Nov 15 2015 - 13:47:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:01 UTC