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: Pander <pander at users dot sourceforge dot net>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Mike Frysinger <vapier at gentoo dot org>,libc-alpha at sourceware dot org
- Date: Sat, 23 Apr 2016 16:41:35 +0200
- 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> <20160422212338 dot GG5369 at vapier dot lan> <0C28F4FA-7780-4DFD-90E8-054AFE1D7346 at users dot sourceforge dot net> <87r3dwjzec dot fsf at mid dot deneb dot enyo dot de>
On 23 April 2016 14:14:03 CEST, Florian Weimer <email@example.com> wrote:
>> I understand you are playing the devils advocate. Thanks for
>> that. Suppose that for all territories English is added, that will,
>> a maximum, double the number of locales, only once.
>> That is manageable. Computers nowadays can handle that amount with
>The current dominant criticism of glibc is related to installation
>size (search for Docker and Alpine Linux if you aren't aware). As
>always, the situation is more complex than some of the reports
>suggest, but adding a few dozen megabytes to the installation is
>probably not such a good idea.
>> At the moment, remixing LC sections is not supported by any of the
>> main GNU/Linux installers or by command line configuration tools or
>> configuration tools for GNOME, KDE, etc.
>Not quite true. It was supported in KDE; it had a separate selector
>for LC_MESSAGES at least. The KDE people removed it at one point
>because there was no need. If they have not added it back yet, I
>think this shows this feature is not actually needed, and neither are
>English locale variants.
>I don't want glibc to be the place where contested decisions by
>desktop environments are worked around. If the people actually
>working on end user interfaces determine that mixed locale settings
>are not needed, who are we to second-guess them? They have many more
>interactions with such users than we do.
>> As long as no progress is made in usability in installers and
>> configuration tools, I would see fit that en_NL is added. It can
>> always be removed if more elegant alternatives become available.
>If the locale has actual users, we can't remove it that easily.
That is exactly my point. Remixing on section level (with installer, config tools or scripts) will not offer the user what this specific en_NL locale offers. Hence, users that want it, will continue to use it and give this locale a raison d'etre.