Date: Fri, 25 Jul 2014 18:32:39 -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 ?) Yes, I agree that's a bad idea. > Somewhat cleaner might be: ("zxx" and "ZZ" below are literals) > > no localization C > language[+territory] ll[l][_TT] > purely territorial zxx_TT ("no language" code) While clean and well-defined, I wonder whether zxx_TT is counter-intuitive to most users... > and possibly > no territory-specific stuff included ll[l]_ZZ ("no territory" code) > > The last item would e.g. allow treating ll[l] alone as "including > the most frequently used territorial features for this language" > (like "sv" == "sv_SE"), > but I think this approach would be bad and confusing - such a definition > is not certain nor stable. > > I think that a language code alone should mean "no territory-specific > stuff included" and nothing else. I think that's reasonable. > Then "ll" would be a synonym for "ll_ZZ" and hence "ll_ZZ" will not have > to exist at all. That's definitely nice. > Then the usage would be like > > LANG=de_DE (... "€") > > LANG=sv_SE (decimal comma, "kr") > LANG=sv LC_MONETARY=zxx_SE (decimal point from "C", iso4217 "SEK") Changing the numeric radix point is explicitly not supported. :) LC_NUMERIC is just always C because, well, numbers are numbers, not something to vary by culture, and changing the radix point just breaks parsing and storing data for interchange. LC_MONETARY on the other hand could in principle provide a different monetary radix point, but it's not terribly useful until we get a full-featured strfmon anyway. 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.