newlocale: Linux incompatibility

[Corinna Vinschen]

On Mar 25 13:03, Brian Inglis via Cygwin wrote:
> On 2023-03-25 05:49, Corinna Vinschen via Cygwin wrote:
> > On Mar 24 16:49, Brian Inglis via Cygwin wrote:
> > I never heard about an environment variable called LANGUAGE.  This is
> > about LANG/LC_ALL/LC_whatever, so POSIX syntax is required...
> 
> Used by gettext:
> 
> https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

Ok, I'm not using that because I didn't even know that.  But I'm not
sure why you even mention it, it has nothing to do with Cygwin's
locale implementation which is based on the POSIX definitions.
Exception here is where the data comes from since we don't maintain
locale definition files and thus we don't follow
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
to the letter.

> > > 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
> >    LC_CTYPE=lang_TERRITORY.codeset@modifier
> 
> You are using codeset to mean encoding, whereas in Unicode and W3 it usually
> means coded character set/charset; it can also mean charmap; see iconv(1):

I'm using the POSIX definition here.  Codeset is codeset, as in
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Quote:

  If the locale value has the form:

  language[_territory][.codeset]

  it refers to an implementation-provided locale, where settings of
  language, territory, and codeset are implementation-defined.

So I'm using the name "codesets" to follow POSIX documentation for
setting the matching locale environment variables, exactly to avoid
confusion.


Corinna