Bug 22473 - Suggestion: Introduce en_EU locale
Summary: Suggestion: Introduce en_EU locale
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-22 06:03 UTC by Rafal Luzynski
Modified: 2017-11-29 07:43 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafal Luzynski 2017-11-22 06:03:31 UTC
Following the previous discussion on the alpha mailing list [1] I suggest to introduce en_EU locale. It should be useful for the people who live in non-English speaking European countries but want to use the English user interface having their local settings for other things like metric system, paper size, etc. So far workaround solutions have been used like en_SE, en_DK, en_NL, also used in other countries. The en_EU locale would mean a generic European locale without favoring one or few countries. ISO currently marks EU country code as exceptionally reserved for European Union [2] which is kinda good but my initial idea was that EU may mean both European Union and whole Europe (including also non-EU countries). The yesexpr and noexpr entries should include the Y/N answers for as many languages as possible.

The idea is not to drop en_DK immediately although these locales can use "copy en_EU" if it makes sense.

[1] https://sourceware.org/ml/libc-alpha/2017-08/msg00308.html
[2] https://www.iso.org/obp/ui/
Comment 1 Andreas Schwab 2017-11-22 18:53:45 UTC
Which of the several European local settings are "generic"?  If you only want English messages you can already use LC_MESSAGES.
Comment 2 Egmont Koblinger 2017-11-22 19:18:46 UTC
Some aspects sound quite problematic to me.

What should be the decimal separator, the first day of the week, the currency etc. (let alone a few less important ones e.g. phone prefix, postal format)?

To second Andreas's point, what are the desired use cases to which setting separate LC_whatever variables isn't sufficient currently? Would an en_EU then be definitely sufficient for all these kinds of requests? Wouldn't something else, e.g. improving the way users could generate their own locales (tools, docs) a better solution?

If en_EU is added then shouldn't there be a fr_EU, de_EU etc., for ... for which languages exactly?
Comment 3 Rafal Luzynski 2017-11-28 23:14:48 UTC
(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.
Comment 4 keld@keldix.com 2017-11-29 07:43:05 UTC
I think we should follow the i18n locale very closely, and only deviate in the monetary
items.

I note that ISO in their English documents uses "," for   decimal separator and "." for thousands separator.
So will almost all of the EU do after brexit.

Best regards
Keld