Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Jul 2014 16:43:29 -0400
From: Rich Felker <>
Subject: Re: Locale bikeshed time

On Fri, Jul 25, 2014 at 10:15:51PM +0200, wrote:
> Replying to myself.
> On Fri, Jul 25, 2014 at 11:06:49AM +0200, 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?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.