Re: Need help fixing failing locale tests

On 11/15/2015 2:36 PM, Andrey Chernov wrote:
> On 15.11.2015 16:14, John Marino wrote:
>>> It is user confusion and his responsibility. It not leads to wrong
>>> program build f.e. Moreover, you can't protect users who set 8859-1 that
>>> way, they do not convert to 8859-15 as you assume but start to complain
>>> everywhere that FreeBSD is not working instead.
>>
>> Invalid.  "locale -a" shows what locales are available.
>> The confusion is not with one user.  It's with one user that produces
>> document in one encoding and a second user that choses the wrong one
>> (usually -1).  -15 was designed to replace -1.
> 
> No end-user use 'locale -a' to check locales. 

To quote you, that means it "user confusion and responsibility".
Fine.  He can "ls -d /usr/share/locales".  Otherwise, how does said user
set locales for the FIRST time.

We are talking about people that install FreeBSD 11 as a release.  If
it's an upgrade, it's documented in UPDATING (it will be) and anybody on
-CURRENT is taking responsibility for knowing what they are doing.  *IF*
this is an obstacle, it's either trivial or that user shouldn't be using
-CURRENT to begin with.


> An end-user keep some
> 8859-1 version is set many years ago, and "FreeBSD not working" problem
> 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).


> 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 ... ?


> 
>> OpenBSD removed ISO8859* completely.
> 
> OpenBSD was never good in locales in any case for all that years and
> contributes nothing in that area (f.e. Citrus was made by NetBSD). Now
> they try to simplify their life of supporting them, but since for us now
> all locales are autogenerated from CLDR I see no room for simplification
> in that way. Our "cleaned" locales (against to POLA) can be restored by
> autogeneration with minimal efforts, and they even took very little disk
> space.

It's not a technical issue.  -1 (and some -15) weren't removed for
technical issues, but to keep order.

>> Also invalid.  Locales are not standardized with regard to encoding, so
>> maintaining a museum of locales is specific to FreeBSD.  Linux calls
>> them differently.
> 
> Most of our (old) locales have the same names as linux ones.

Actually, none of the ISO* encodings.  Linux will accept "ISO8859-1"
because it's hyphen-insensitive, it it calls it "ISO-8859-1"

Maybe obsolete ones like cp866, GB2312 ... but there are more different
than the same.

John