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 connec
On 26.04.2017 02:45, Konrad Schroder wrote:
> Thoughts?
This is something that I always wanted to see but never had in plans due
to amount of work that has to been done. Please keep it going!
signature.asc
Description: OpenPGP digital signature
On Tue, Apr 25, 2017 at 05:45:14PM -0700, Konrad Schroder wrote:
> * Per-thread locale settings
This is *not* an advantage. Please read the archives for a longer
discussion. Per-thread locales are just insane and ridiculously
expensive for no good reason.
> * Working LC_COLLATE settings
This c
On 4/25/17 20:08, SODA Noriyuki wrote:
* No compatibility support; e.g. existing test binaries crash
This means it has an ABI compatiblity problem, doesn't it?
Worse than that---in the current diff, there is no compatibility layer
at all, the problem manifests as missing symbols. I've thought
> On Tue, 25 Apr 2017 17:45:14 -0700,
Konrad Schroder 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 CLD
I've made a fair start at porting FreeBSD's (port of Darwin's) xlocale
to NetBSD. This started out as a frustration at ${WORK}, but continued
at home after we gave up at ${WORK} and switched OSs instead to get
working LC_COLLATE support.
The benefits of adopting xlocale would be:
* Per-thre
