On 22 Apr 2016 22:27, Pander wrote:
> The rational behind this is the following. Most developers in the Netherlands use the English language while working with Linux et al. but need the local settings for date, hour, paper size, currency, etc. The mixing for this takes place within the LC sections. Compared to Germany or France, in the Netherlands even comments in code are usually/more in English.
> 
> Custom mixing is not that easy for the average+advanced user and impossible to get this particular setup. This local will be widely used once available. Users are, at the moment, stuck with either Dutch, US or Irish locale that don't offer what they need. In the Dutch industry, English is often the defacto language.

Florian's point is that for most categories, you can (mostly) get this today:
	export LANG=nl_NL.UTF8
	export LC_MESSAGES=en_US.UTF8
	export LC_NAME=en_US.UTF8

while it's true that locale settings are a bit obscure to many users, that
doesn't mean adding a locale so people can just `export LANG=en_NL` is the
right answer.  we have a documented system for controlling the locale (and
this aligns with POSIX), and we should be using it.

i would contend that for the average user, they'll be using a DE that has
a GUI where there is a settings panel for them to easily select how they
want the time/date/currency/etc... to be displayed.

> Adding this locale will not result in an explosion of additional locales, as no other languages than English are linga franca. There is also Danmark English one, I believe.  If you could measure the eventual usage, this locale will be very in much in demand and usage in the Netherlands.

with ~250 territories defined today, we're talking about ~250 for English
alone.  that is kind of an explosion considering we have ~330 locales now
in glibc, and only ~20 of them are for English.

note: i'm mostly playing devils advocate here.  as you can see in my other
posting, i don't think the current situation is great for either side.
-mike