This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085]
- From: Marko Myllynen <myllynen at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 25 Apr 2016 16:13:09 +0300
- Subject: Re: [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085]
- Authentication-results: sourceware.org; auth=none
- References: <1461298610-19221-1-git-send-email-vapier at gentoo dot org> <87a8klk4jp dot fsf at mid dot deneb dot enyo dot de> <D44674DF-E470-43C5-B667-22EBDE618CCC at users dot sourceforge dot net>
- Reply-to: Marko Myllynen <myllynen at redhat dot com>
On 2016-04-22 23: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.
The situation you describe is in no way specific to the Netherlands and
in fact there have been similar requests for other en_* variants in the
> 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.
Again, the Netherlands is not any kind of exception here. If we start
adding en_* variants, will English be the only exception or are we
willing to add, say, fr_* variants as well? If not, why?
Accepting en_* variants but rejecting others could be seen as a certain
kind of statement by the project, I'm not sure would that be wanted.
> 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.
At least earlier en_DK has been considered a mistake which should not be
repeated (see e.g. the BZ link above.)
In general I think the right answer is not to add arbitrary locale
variants to glibc but to make it easier for users to customize their own
environment as their see fit (see e.g.