newlocale: Linux incompatibility
Sat Mar 25 11:49:06 GMT 2023
On Mar 24 16:49, Brian Inglis via Cygwin wrote:
> On 2023-03-24 06:18, Corinna Vinschen via Cygwin wrote:
> > > First, it's a bug in the Emacs testsuite. The test simply assumes that
> > > there's no en_DE locale on any system, but that's just not true.
> > > Windows support the RFC 5646 locale "en-DE", which is called "English
> > > (Germany)" in the "Region" settings.
> > >
> > > You can also check with `locale -av | less' and search for en_DE.
> > >
> > > For the reminder of this mail, I assume you're talking about Cygwin 3.5.
> > > I won't fix this for 3.4 anymore, given how much locale handling has
> > > changed for 3.5.
> > >
> > > The second bug is that Cygwin blindly trusts the Windows function
> > > ResolveLocaleName(). That function blatantly converts even vaguely
> > > similar locales into something it supports. E.g., it converts "en-XY"
> > > to "en-US". I. .e., even if you use "en_XY.utf8" as locale, the above
> > > testcase will wrongly succeed. So I have to rethink how I resolve POSIX
> > > locales to Windows locales.
> Does Windows even consider https://www.rfc-editor.org/rfc/rfc4647 "Matching
> of Language Tags", part of https://www.rfc-editor.org/info/bcp47 "Language
> Tags", and if POSIX only matches exactly, will LANGUAGE be able to be used
> for fallback?
I never heard about an environment variable called LANGUAGE. This is
about LANG/LC_ALL/LC_whatever, so POSIX syntax is required...
> I currently define LANGUAGE=en_CA:en_GB:en in case en-CA is unsupported by
> [I use my own en-CA locale not the glibc default created by https://rap.dk/.]
> Will "-" be supported like "_" as a separator in values?
In Cygwin? No. The POSIX syntax is required, it's converted into
a matching Windows RFC 5646 locale internally.
> > > And the third bug is that Cygwin fails to set errno if it doesn't
> > > support a locale, but that's a minor inconvenience in comparison.
> > >
> > > Thanks for the report, I totally missed the above problem with
> > > ResolveLocaleName.
> > I pushed a couple of patches which hopefully clean up the code. It's
> > really frustrating how these Windows locale functions work. Or, rather,
> > not work. I mean, come on...
> > - ResolveLocaleName() resolves "ff-BF" to "ff-Latn-SN", not to
> > "ff-Adlm-BF" or "ff-Latn-BF", even though both exist.
> > - There's a locale called "sd-Arab-PK" and a locale "sd-Deva-IN". If
> > you ask for the script used in "sd-IN", the result is "Arab", not
> > "Deva".
> > I had to create a replacement function for ResolveLocaleName which
> > doesn't return totally screwy and unexpected results, and special case
> > two more locales in /proc/locales output so the output makes sense.
> Aha - a nice new 3.5.0 feature - as well as /proc/codesets - is that
> charsets e.g. ISO-10646, etc. rather than encodings e.g. UTF-8, etc.!
It's a list of what you can use as codeset in $LANG and friends as in
More information about the Cygwin