Bug 14085

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:
  https://sourceware.org/ml/libc-alpha/2016-04/msg00551.html

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.

https://sourceware.org/bugzilla/show_bug.cgi?id=12624#c3 :
QUOTE
Accepting any such special-interest locale would open a flood.  There is no reason to have such a locale in glibc.  The localedef utility is standardized for a reason: locales can be compiled by anyone.

Just create a RPM or whatever which upon installation installs the files and compiles the locale with localedef.
UNQUOTE

Adding "en_non-en" locales is not flooding.
Let's see what flooding is.

Somehow some people seem to forget that the EU (as we know it now) is a reality since 1993. There are 24 official languages of the European Union. And 19 EU member states. There is an internal single market in the EU where by law all member states have agreed to act as one. Also, EU policies further the free movement of **people**, goods, services and capital within this internal market. Yes also people.
Has/Is anyone In The Netherlands working for a company that has Linux desktop computers in their network and employs English speaking permies or English speaking freelancers using those Linux computers?
And where more often than not one of the job requirements for native Dutch speakers is : good (or better) written and spoken English. Because of the mix of nationalities within the company. We are the USE (United States of Europe) after all.
Has/Is anyone working for one of the many Japanese companies in The Netherlands, where speaking and writing English is mandatory?

Has/Is anyone working for a company where Windows sysadmins keep Linux desktops and laptops off their network and out the door because of locale issues?
Although staff would prefer to use Linux on the dersktop.

Some of the companies in The Netherlands that I worked as a freelance contractor that had and still have many English speaking freelancers/permies : ING Bank, ABN AMRO Bank, RABO Bank, MUFG Bank (nee Bank of Tokyo Mitsubishi UFJ), Canon Europe BV, Kyocera Mita Europe, Cygnific BV (Air France-KLM's worldwide support), XS4ALL BV (best ISP ever). They all refuse Linux desktops for this locale issue.

ING Bank encountered major issues after they decided to build their new call center software on Linux (server and desktop). As you guess the issues were about locales on the desktop. Yes, they had to roll their own locales. I'm still grateful that I did not work on that mope and grope project. That was in late 2008.

You expect us to keep rinsing and repeating the ING effort almost 11 years later? Almost 26 years after the beginning of the EU ?
Thanks for adding the Euro-sign though. It shaved 2 seconds off the work to create a new locale. Hail Windows and Hail MacOS for putting in a genuinine effort to conquer the desktop. Doh! Oops!