Date: Thu, 24 Jul 2014 17:35:26 +0200 From: u-igbb@...ey.se To: musl@...ts.openwall.com Subject: Re: Locale bikeshed time 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
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.