From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100450 invoked by alias); 28 Nov 2017 23:14:54 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 100263 invoked by uid 48); 28 Nov 2017 23:14:50 -0000 From: "digitalfreak at lingonborough dot com" To: libc-locales@sourceware.org Subject: [Bug localedata/22473] Suggestion: Introduce en_EU locale Date: Tue, 28 Nov 2017 23:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: digitalfreak at lingonborough dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2017-q4/txt/msg00236.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22473 --- Comment #3 from Rafal Luzynski = --- (In reply to Egmont Koblinger from comment #2) > Some aspects sound quite problematic to me. >=20 > What should be the decimal separator, This is English so a comma "," most probably. > the first day of the week, I'd like to review some European locales but at the moment I lean into Mond= ay as some ISO standard says. > the currency etc. Euro seems to be the most widely used currency in Europe. > (let alone a few less important ones e.g. phone prefix, postal > format)? They should be left empty, probably. We had lots of trouble with some of th= ese fields already, also including the ISBN code prefix. It turns out that some countries have multiple ISBN codes and multiple int_select prefixes. This h= as led us to questions whether any application actually uses these data. > To second Andreas's point, what are the desired use cases to which setting > separate LC_whatever variables isn't sufficient currently? My guess is that users are not aware of the possibility to select separate = LC_ variables or maybe the GUI support is insufficient. > Would an en_EU > then be definitely sufficient for all these kinds of requests? For some maybe yes, for some this would be just the best they can achieve. Occasionally there are requests to add en_XX locale because there are people around Europe who want to use English even if this is neither their native language nor the language of their countries. Examples: Bug 14085 https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/208548 http://rhea-ayase.eu/articles/2017-08/Upgrade-to-Fedora26 > Wouldn't > something else, e.g. improving the way users could generate their own > locales (tools, docs) a better solution? Maybe improving GUI setups. But I'm not sure if this is possible The GUI se= tups tend to be simplified nowadays. I suspect their answer would be "no, we want the users to choose just a language and a country, not a series of geeky th= ings like a paper format, date/time format, postal code format etc." > If en_EU is added then shouldn't there be a fr_EU, de_EU etc., for ... for > which languages exactly? If only there are people who choose French (German) language for their computers because this is their favorite foreign language and they are not related with any French (German) speaking country... To be more precise: it should be a reasonably large group of people, we should not add a locale for just one or few persons. Honestly, I'm not aware of such people. But if the= re are any I guess that fr_FR (de_DE) would be a sufficient choice for them. --=20 You are receiving this mail because: You are on the CC list for the bug.