[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Xlocale for NetBSD
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.
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
>> * No compatibility support; e.g. existing test binaries crash
> This means it has an ABI compatiblity problem, doesn't it?
> How about merging both current citrus staff and the xlocale staff?
> * 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
> I'll look at this.
Main Index |
Thread Index |