Internationally oriented users who are physically located in the Netherlands
use software mainly in the English language. Therefore they have their systems
usually configured to US English International. However, due to the geographic
location, it can be desirable for certain data to be represented according to
the local Dutch notation while the rest remains in English.
Therefore this locale called en_NL has been created. It is based on en_US and
has some parts from nl_NL. Please see comments starting with "%% use" how each
section has been composed. Note that this specific configuration is difficult
to obtain by using locale nl_NL and setting LANGUAGES to en.
The latest version is available at:
Please include this locale in next release.
Requesting WONTFIX as for bug #12624.
I agree a flooding as discussed in bug #12624 should be prevented. However a English locale for Denmark and Nigeria do exist. Why not allow one for the Netherlands? Many software developers and GNU/Linux users in the Netherlands work in English and should be able to do that with proper notation of local data.
Unfortunately that is not possible by a simple mix of the groups of settings from en_US and nl_NL. Secondly, it is beyond the ability of most users of the described group to create their own RPM/DEB to add locale for en_NL. Thirdly, this motivation would only potentially allow for more package requests for English locales in the form of en_?? but of course only if they are well maintained. Setting up restrictions would ensure quality and prevent flooding.
Currently many Dutch users choose the Irish locale (see e.g. Ubuntu forums) to get as close as possible to what they need but they are still lacking support in times, dates, telephone numbers, addresses and more. This gap is closed by the proposed locale en_NL. This demonstrates majority of users is not able to add this locale themselves, hence this request and extended motivation.
i don't think this falls into the same bucket as bug 12624. that's a request for an esoteric locale that realistically speaking, no one is using today. on the other hand, en_NL has an active set of users.
patch moved to the mailing list:
btw, there's no need for nl_NL@euro anymore. since nl_NL itself is on the euro, we keep the @euro variant around only for legacy reasons. since en_NL is a new locale, we can just omit en_NL@euro entirely.
This is a usefull addition for me. I do have to change my locale on each terminal to a mix of en_US and nl_NL. So I have currently a script for that. Please add this locale. Then I can use that.
The latest version at https://github.com/PanderMusubi/locale-en-nl has small improvements due to discussion via email. Also documentation and validation has been extended to provide more details for rationale and insight in exact format.
(In reply to Pander from comment #7)
OK, but we don't use github. all patches/discussions are on the mailing list.
Ah, OK, I didn't know that. All questions and remarks got processed in the latest version on GitHub. I leave it to the sponsor of this bug to repost a patch on the mailing list and refer to GitHub for answers and improvements.
This Thursday, at the 2016 fall conference of NLUUG, there will be a talk on this locale. The locale will be discussed in all its details amongst an audience of expert users to validate this locale and get consensus and support. Minor changes will be made (some are already planned for the version on GitHub). A new patch will be send to glibc via this issue early next week.
See also http://bit.ly/2gd1ZBu
In August I will send the final version. Came across a few minor bugs in other locales which I will report first.
There is no consensus, and in fact there is opposition to the addition of en_* locales for all countries that deal with English. Stated reasons include: size of install, increased number of locales to pick from, complexity on the user side for selecting those locales (Chris Leonard's "maximum parsimony" theory ;-)). Instead the generally accepted idea is that you should mix-and-match the LC_* variables as needed, with the knowledge that this is not the most flexible way to solve this problem. Individual distributions are free to include whatever en_* locales they wish to build to suit their users. Likewise, users can do the same thing.
Therefore until there is consensus formed around this issue I'm marking this bug as RESOLVED/WONTFIX.
(In reply to Carlos O'Donell from comment #12)
> There is no consensus, and in fact there is opposition to the addition of
> en_* locales for all countries that deal with English. Stated reasons
> include: size of install, increased number of locales to pick from,
> complexity on the user side for selecting those locales (Chris Leonard's
> "maximum parsimony" theory ;-)). Instead the generally accepted idea is that
> you should mix-and-match the LC_* variables as needed, with the knowledge
> that this is not the most flexible way to solve this problem. Individual
> distributions are free to include whatever en_* locales they wish to build
> to suit their users. Likewise, users can do the same thing.
> Therefore until there is consensus formed around this issue I'm marking this
> bug as RESOLVED/WONTFIX.
I failed to mention that Mike Frysinger's suggestion of a new way to mix-and-match language/territory is probably the right place to start for a solution to this problem that doesn't include new locales.
Unfortunately, mixing on LC level doesn't do the trick. I gave a presentation at NLUUG in 2016 in a room full of experienced sysadmin professionals addressing all issues why not to include this. The locale was received with great enthusiasm as it solves a series of problems that cannot be fixed in another way. If you can find the time I could talk you through my presentation personally.