From: Florian Weimer <fw@deneb.enyo.de>
To: Chris Leonard <cjlhomeaddress@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>,
libc-alpha <libc-alpha@sourceware.org>,
Pander Musubi <pander@users.sourceforge.net>
Subject: Re: [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085]
Date: Sat, 23 Apr 2016 12:05:00 -0000 [thread overview]
Message-ID: <87vb38jzss.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <CAHdAatZf+6OQrRjBSmOUHw34-TYH0zvNAqA9G3K-1DQE_XmMnw@mail.gmail.com> (Chris Leonard's message of "Fri, 22 Apr 2016 15:12:28 -0400")
* Chris Leonard:
> Isn't ease of use ever a consideration here?
Sure.
> 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?
Some desktop environments already have a per-category locale selector.
I doubt we can ever do without this because for this mixed locale
environments, there won't always be a clear preference, and we can't
tell users that they have to live with it because that's what their
local standards body has decided.
If desktop environments refuse to add the user interface for this, or
can't arrange for the installation or generation of the required
locales, this isn't really our fault. If we aggressively increase the
number of locales, it is likely that only a subset of them make it to
the user due to installation size concerns.
next prev parent reply other threads:[~2016-04-23 12:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 4:17 Mike Frysinger
2016-04-22 15:19 ` Chris Leonard
2016-04-22 16:10 ` Florian Weimer
2016-04-22 19:07 ` mix/match lang/territory (was: [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085]) Mike Frysinger
2016-04-23 12:01 ` mix/match lang/territory Florian Weimer
2016-04-22 19:13 ` [PATCH] localedata: en_NL: new English in the Netherlands locale [BZ #14085] Chris Leonard
2016-04-23 12:05 ` Florian Weimer [this message]
2016-04-23 13:18 ` Chris Leonard
2016-04-23 14:57 ` Pander
2016-04-23 15:03 ` Florian Weimer
2016-04-23 19:51 ` Pander
2016-04-22 20:28 ` Pander
2016-04-22 21:23 ` Mike Frysinger
2016-04-23 12:01 ` Florian Weimer
2016-04-23 14:47 ` Pander
[not found] ` <0C28F4FA-7780-4DFD-90E8-054AFE1D7346@users.sourceforge.net>
2016-04-23 12:14 ` Florian Weimer
2016-04-23 14:41 ` Pander
2016-04-25 13:13 ` Marko Myllynen
2016-04-23 11:15 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vb38jzss.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=cjlhomeaddress@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=pander@users.sourceforge.net \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).