Re: Xlocale for NetBSD

[Konrad Schroder <perseant%hhhh.org@localhost>]

Looking further into the ISO2022 problem, it seems it is a shortcoming
of this implementation of localedef, not a problem with the CLDR tools
as I had supposed.  So it is reasonable to expect working ISO2022
locales from the system I'm proposing, if the relevant parts of the
Citrus code were connected correctly to localedef.

As a side note, this version of localedef needs better error reporting,
but that's easy enough to add.

Take care,
                        Konrad Schroder
                        perseant%hhhh.org@localhost

On 04/25/2017 08:08 PM, SODA Noriyuki wrote:
>>>>>> On Tue, 25 Apr 2017 17:45:14 -0700,
> 	Konrad Schroder <perseant%hhhh.org@localhost> said:
> 
>> The benefits of adopting xlocale would be:
>>
>>   * Per-thread locale settings
>>   * Working LC_COLLATE settings
>>   * Use localedef(1) instead of mklocale(1), which allows...
>>   * Take locale definitions directly from CLDR
> 
> These are all great.
> 
>> but, at least at the moment, has these drawbacks:
>>
>>   * No ISO2022 codemap
> 
> hmm.
> 
>> * No compatibility support; e.g. existing test binaries crash
> 
> This means it has an ABI compatiblity problem, doesn't it?
> 
>> Thoughts?
> 
> How about merging both current citrus staff and the xlocale staff?
> i.e.
>  * merge the LC_COLLATE staff to the citrus framework.
>  * merge the localedef(1) staff to the citrus framework.
>  * add the per-thread APIs.
> 
>> The current diffs are available at
>>
>>    http://www.hhhh.org/perseant/xlocale-20170425.diff
> 
> Thanks.
> I'll look at this.
>