public inbox for libc-locales@sourceware.org
 help / color / mirror / Atom feed
From: "digitalfreak at lingonborough dot com" <sourceware-bugzilla@sourceware.org>
To: libc-locales@sourceware.org
Subject: [Bug localedata/22473] Suggestion: Introduce en_EU locale
Date: Tue, 28 Nov 2017 23:14:00 -0000	[thread overview]
Message-ID: <bug-22473-716-BhQRraAGvG@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-22473-716@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=22473

--- Comment #3 from Rafal Luzynski <digitalfreak at lingonborough dot com> ---
(In reply to Egmont Koblinger from comment #2)
> Some aspects sound quite problematic to me.
> 
> 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 Monday
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 these
fields already, also including the ISBN code prefix. It turns out that some
countries have multiple ISBN codes and multiple int_select prefixes. This has
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 setups
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 things
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 there
are any I guess that fr_FR (de_DE) would be a sufficient choice for them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2017-11-28 23:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  6:03 [Bug localedata/22473] New: " digitalfreak at lingonborough dot com
2017-11-22 15:39 ` [Bug localedata/22473] " piotrdrag at gmail dot com
2017-11-22 18:53 ` schwab@linux-m68k.org
2017-11-22 19:18 ` egmont at gmail dot com
2017-11-23 14:50 ` fweimer at redhat dot com
2017-11-24 19:20 ` jwilk at jwilk dot net
2017-11-28 23:14 ` digitalfreak at lingonborough dot com [this message]
2017-11-29  7:42   ` Keld Simonsen
2017-11-29  7:43 ` keld at keldix dot com
2018-12-20  8:18 ` pander at users dot sourceforge.net
2018-12-21 10:25 ` digitalfreak at lingonborough dot com
2018-12-21 10:51 ` pander at users dot sourceforge.net
2019-09-16  8:47 ` robert.pollak at posteo dot net
2021-11-08 23:40 ` sergio.callegari at gmail dot com

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=bug-22473-716-BhQRraAGvG@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=libc-locales@sourceware.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).