Need help fixing failing locale tests
mfl-commissioner at marino.st
Sun Nov 15 13:54:27 UTC 2015
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
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.
More information about the freebsd-testing