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. 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. 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. > 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. > 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. -- http://ache.vniz.net/ _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
