From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5581 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Thu, 24 Jul 2014 17:35:26 +0200 Message-ID: <20140724153526.GH16795@example.net> References: <20140722184932.GA4914@brightrain.aerifal.cx> <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> 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 1406216164 487 80.91.229.3 (24 Jul 2014 15:36:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2014 15:36:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5586-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 24 17:35:57 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 1XAL3f-0004aK-2B for gllmg-musl@plane.gmane.org; Thu, 24 Jul 2014 17:35:51 +0200 Original-Received: (qmail 9522 invoked by uid 550); 24 Jul 2014 15:35:49 -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 9514 invoked from network); 24 Jul 2014 15:35:49 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe01.swip.net; client-ip=171.25.193.20; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140723210120.GD11570@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5581 Archived-At: On Wed, Jul 23, 2014 at 05:01:20PM -0400, Rich Felker wrote: > > This feels appropriate - if the definitions indeed fall into distinctive > > classes like "full" / "single-category" and also if the naming reflects > > the distinction > > IMO language-based locales should be ll, lll, ll_TT, or lll_TT form > where ll or lll is lowercase ISO language code and TT is uppercase > territory code. Non-language-based locale files should avoid these > patterns. Just for certainty: I assume you mean "l" above being lower case and non-language-based definitions to begin/consist of uppercase letters? Totally avoiding two- and three-letter combinations would be hardly followed by less scrupulous parties :) but you certainly did not mean this. Btw do we have to also use lll (the three-letter codes) or would be the two-letter ones sufficient? I understand that this is not an implementation question but rather a discipline/policy one but in the long run it helps enormously to have a clean deployment idea from the beginning. An example of a spectacular failure to do so were the xkb keyboard maps. [ Two incompatible representations were in use, for many years (!) One was reasonable, structured by country i.e. reflecting different countries' actual standards. The other one was broken by design, using "language" as the main key without any actual definition of its semantics. This led to many of the available definitions being a hardly useful hacks (and of course to a lot of confusion for everyone as this thing was impossible to document). Remarkably even the maintainers of the maps at x.org/freedesktop.org at the time did not realize the origin of the problem. I happen to have been involved into clarifying the issue, now the structure of xkb/symbols is reasonable. ] This happens when one does not clearly document the target deployment model which the implementation exist for, iow is meant to implement. Other/unexpected ways to use a tool can be good too (or sometimes even better) but most of the deployers lack the time and knowledge for the analysis which the implementors by their role are to do - the analysis which you among other things are doing by the discussions here. The lack of the understanding easily leads to bad practices being perpetuated (like the mess of the Kerberos keytab traditions). I am afraid that not stating a clean usage model may harm musl deployments too (say by mixing two- and three-letter locale codes so that one can not sanely know which kind to use). Rune