[Bug localedata/22473] New: Suggestion: Introduce en_EU locale

[Bug localedata/22473] New: Suggestion: Introduce en_EU locale

[digitalfreak at lingonborough dot com]

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

            Bug ID: 22473
           Summary: Suggestion: Introduce en_EU locale
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: localedata
          Assignee: unassigned at sourceware dot org
          Reporter: digitalfreak at lingonborough dot com
                CC: libc-locales at sourceware dot org
  Target Milestone: ---

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/

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[piotrdrag at gmail dot com]

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

Piotr Drąg <piotrdrag at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotrdrag at gmail dot com

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Which of the several European local settings are "generic"?  If you only want
English messages you can already use LC_MESSAGES.

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[egmont at gmail dot com]

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

Egmont Koblinger <egmont at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail dot com

--- Comment #2 from Egmont Koblinger <egmont at gmail dot com> ---
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?

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[jwilk at jwilk dot net]

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

Jakub Wilk <jwilk at jwilk dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwilk at jwilk dot net

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[digitalfreak at lingonborough dot com]

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.

Re: [Bug localedata/22473] Suggestion: Introduce en_EU locale

[Keld Simonsen]

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[keld at keldix dot com]

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

--- Comment #4 from keld at keldix dot com <keld at keldix dot com> ---
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

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[pander at users dot sourceforge.net]

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

Pander <pander at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pander at users dot sourceforge.ne
                   |                            |t

--- Comment #5 from Pander <pander at users dot sourceforge.net> ---
As the maintainer of en_NL, I think an en_EU will not work as local formats
differ per country and only add confusion. I do support creation of en_DE,
en_SE and other English versions for EU countries, under the condition that as
much reuse of existing locales is being done as is practically possible. From
experience, I know that will only work for about 8 of the 12 locale categories.

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[digitalfreak at lingonborough dot com]

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

--- Comment #6 from Rafal Luzynski <digitalfreak at lingonborough dot com> ---
There is no en_NL locale in glibc.  I believe you are talking about a different
project, maybe about some non-upstream patches for glibc.  Of course, localedef
tool exists in order to allow the users build and use their own locales, even
without the root permissions.  So you may have and use whatever locale you
want.  However, I'm trying here to avoid inflation of locales.  The problem is
that each new locale, even if it source code is short and easy to implement,
makes about 2 MB binaries.  This multiplied by about 200 or 300 locales we
currently provide may make a problem.  Distros are already complaining about it
because the locale binaries take too much space both in installation media and
in the users' computers.

Of course, en_EU will not work for everyone.  Even if it works for 8 or 12
countries I'd be satisfied.

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[pander at users dot sourceforge.net]

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

--- Comment #7 from Pander <pander at users dot sourceforge.net> ---
I understand that the footprint needs to be as minimal as possible, and I'm
thinking how we could solve that the best. For example
https://www.sourceware.org/bugzilla/show_bug.cgi?id=24006 would enable more
minimization when needed.

Also https://www.sourceware.org/bugzilla/show_bug.cgi?id=14641 would free up
some space.

en_NL is indeed not in glibc, as is en_DE and en_SE. Only en_DK is, because it
was introduced early on. To reduce size and accommodate more practical use, I
would sooner propose removing li_NL, nds_NL, nds_DE and alike. See also
https://www.sourceware.org/bugzilla/show_bug.cgi?id=23857 for reasons.

There are more and more users in EU countries using their system in English
(and prefer to have correct support for their locale datetime, currency, etc.)
than there are users that want to use their system in their very very local
language such as:
- Upper Sorbian (hsb_DE)
- Lower Sorbian (dsb_DE)-
- Low German/Saxon/Nedersaksisch (nds_DE and nds_NL)
- Frisian (fy_DE and fy_NL)
- Limburgs (li_NL and li_BE)
which don't even have a spell checker or wide localization of applications.
These locales have practically no users, whereas most developers in EU
countries work in the English language but are in need of proper support of
datetime, currenct, etc.

Perhaps even join fr_BE and wa_BE, to free up even more space.

Locale en_EU is gonna give a lot of confusion, remarks and struggles over which
exact formats should be used, as they differ substantially among EU countries,
even/especially the larger countries.

In my opinion, better to trade the before mentioned locales for en_DE, en_SE,
en_NE, etc.

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[robert.pollak at posteo dot net]

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

Robert Pollak <robert.pollak at posteo dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert.pollak at posteo dot net

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

[Bug localedata/22473] Suggestion: Introduce en_EU locale

[sergio.callegari at gmail dot com]

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

Callegar <sergio.callegari at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergio.callegari at gmail dot com

--- Comment #8 from Callegar <sergio.callegari at gmail dot com> ---
I understand that there is a standard en_150 locale that works as English
(Europe) and that would do what is being asked. Would it make sense to have
this one in libc?

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