Re: Locale bikeshed time

[Rich Felker <dalias@libc.org>]

On Fri, Jul 25, 2014 at 10:15:51PM +0200, u-igbb@aetey.se wrote:
> Replying to myself.
> 
> On Fri, Jul 25, 2014 at 11:06:49AM +0200, u-igbb@aetey.se wrote:
> > Returning to the naming. As language-based locales are named
> > after languages, it would be nice to name other kinds of locale
> > data after their "natural association" too. Then politically-bound
> > data could be put into the corresponding "territorial" family:
> > 
> >  language                ll[l][_TT]
> >  territory               TT[_ll[l]]
> 
> A bad idea, forget it. This would be open to misinterpretation
> (which key is "more fundamental" for a certain kind of data,
> shall it go to ll_TT or TT_ll ?)

I wasn't quite sure where to inject this reply into the thread, but
one thing I just remembered is that glibc (and the XSI option for
POSIX) has [.charset] as part of the standard form for locale names,
and all of glibc's usable locales end in ".UTF-8". So a user on a
mixed system is likely to have their locale vars set to include
".UTF-8 "at the end, and therefore wouldn't get any localization when
running musl-linked programs with the locale names we've proposed.

The way I see it, we could either have the locale package provide
symlinks to all of the locales with ".UTF-8" on the end, or musl
itself could ignore anything starting with the first '.' in a locale
name. One downside of symlinks is that a locale could uselessly get
mapped twice if somebody happens to reference it by both names in
their locale vars. It also puts more of a configuration/complexity
burden on the installation. But it does keep policy out of libc and
saves a few bytes of code in libc.

Any opinions on the matter?

Rich