From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5590 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Fri, 25 Jul 2014 11:06:49 +0200 Message-ID: <20140725090649.GN16795@example.net> References: <20140722201008.GC16795@example.net> <20140722203540.GA11570@brightrain.aerifal.cx> <20140723095031.GE16795@example.net> <20140723163907.GC11570@brightrain.aerifal.cx> <20140723192503.GG16795@example.net> <20140723210120.GD11570@brightrain.aerifal.cx> <20140724153526.GH16795@example.net> <20140724160150.GA4038@brightrain.aerifal.cx> <20140724201548.GM16795@example.net> <20140724220228.GB4038@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406279239 27740 80.91.229.3 (25 Jul 2014 09:07:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 09:07:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5595-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 25 11:07:12 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XAbT6-0001ca-2t for gllmg-musl@plane.gmane.org; Fri, 25 Jul 2014 11:07:12 +0200 Original-Received: (qmail 24471 invoked by uid 550); 25 Jul 2014 09:07:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24459 invoked from network); 25 Jul 2014 09:07:09 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe08.swip.net; client-ip=92.222.38.67; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140724220228.GB4038@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5590 Archived-At: On Thu, Jul 24, 2014 at 06:02:28PM -0400, Rich Felker wrote: > first you would need an idea of what some "non-language" category > values might be. I can think of some for LC_COLLATE, though I'm not > sure how valuable many of them are: > > - UCA default tables > - UTF-16 code unit order > - Case-insensitive Unicode codepoint order I can hardly give any opinion on their importance. > For the other categories, examples seem much harder to find. > LC_MESSAGES is inherently a language-based category, but perhaps you > could have a locale that eliminates verbose natural-language messages > and replaces them with C/POSIX identifiers (e.g. printing ENOENT > instead of "No such file or directory") conveying the meaning. (Or we > could be somewhat radical and replace all the internal strerror > messages like this and require LC_MESSAGES=en to get them back.) I'm I like this - for clarity, conciseness and for making it as neutral as possible (ENOENT stems of course from English but no worse than the keywords of C itself). > LC_MONETARY, most if not all of the data really corresponds to a > political unit context, not a language, so in principle it might make > sense to have locales just for LC_MONETARY that aren't associated with > a language, but I can't see that being a convenient or reasonable > design in practice... Indeed, LC_MONETARY has basically nothing to do with language. If I might choose I would not let LANG imply LC_MONETARY (iow would skip LC_MONETARY in language-based locale definitions). 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]] And if we find something that does not feel reasonable to connect to either a language or a territory, we can do special cases @ [or ZZ@ ("no territory") or zxx@ ("no language") but the shorter and simpler is to prefer] The expected mode of usage would be like LANG=de LC_MONETARY=EU or LANG=sv LC_MONETARY=SE or LANG=eo@iso8601 LC_MONETARY=US@iso4217 which would in every case access two locale data files of different classes, clearly visible in the naming. Iso date format actually would be a good candidate for a standalone "@iso8601", but it can as well live inside the C locale. Then the last example above might look like LANG=eo LC_TIME=@iso8601 LC_MONETARY=US@iso4217 at the expense of a third file to be accessed or rather LANG=eo LC_TIME=C LC_MONETARY=US@iso4217 What do you think about such a naming convention and usage mode? Rune