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
perse...@hhhh.org
On 04/25/2017 08:08 PM, SODA Noriyuki wrote:
>>>>>> On Tue, 25 Apr 2017 17:45:14 -0700,
> Konrad Schroder <perse...@hhhh.org> 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.
>
