Re: Locale bikeshed time

[u-igbb@aetey.se]

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