|
Message-ID: <20140726204329.GR4038@brightrain.aerifal.cx> Date: Sat, 26 Jul 2014 16:43:29 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Locale bikeshed time On Fri, Jul 25, 2014 at 10:15:51PM +0200, u-igbb@...ey.se wrote: > Replying to myself. > > On Fri, Jul 25, 2014 at 11:06:49AM +0200, u-igbb@...ey.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
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.