This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085]
- From: Chris Leonard <cjlhomeaddress at gmail dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Mike Frysinger <vapier at gentoo dot org>, libc-alpha <libc-alpha at sourceware dot org>, Pander Musubi <pander at users dot sourceforge dot net>
- Date: Fri, 22 Apr 2016 15:12:28 -0400
- 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>
Isn't ease of use ever a consideration here?
Are all decisions, even those not code-driven, but user-driven always
decided on a "maximum parsimony" basis?
Can you describe the method a novice user of Linux would employ to mix
and match separate LC_* environment variables?
cjl
On Fri, Apr 22, 2016 at 12:10 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Mike Frysinger:
>
>> +% English language locale for the Netherlands.
>> +% 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.
>
> Why is this necessary? Isn't this use case the reason for having
> separate LC_* environment variables, so that you can mix-and-match
> locales like this? In other words, glibc doesn't need to provide a
> pre-cooked locale.