[Bug localedata/23857] New: Esperanto has no country

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] New: Esperanto has no country

albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

            Bug ID: 23857
           Summary: Esperanto has no country
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: localedata
          Assignee: unassigned at sourceware dot org
          Reporter: carmenbianca at fedoraproject dot org
                CC: libc-locales at sourceware dot org
  Target Milestone: ---

Since glibc 2.24, Esperanto has been available as the `eo.utf8` locale.  It was
added as more-or-less the only locale not to have an associated country.  For
translations, this works sufficiently well.  The problem, however, is that a
lot
of projects don't handle the no-country locale very well.

- In GNOME's gnome-control-center, the user is given a choice to pick a
language
  and a "format" (locale).  Esperanto is a language choice, but not a locale
  choice.  Instead, it defaults to "United States (English)".

- In Python's `locale`, unsetting all LC_* variables and running `LANG=eo
  python3`, you get `locale.getlocale() == ('eo_XX', 'ISO8853-3')`.

- In a lot of packages, you'll see something like `*_*` to match all locales.
  Esperanto has to be separately mentioned such that the expression becomes `eo
  *_*`.  See <https://bugzilla.redhat.com/show_bug.cgi?id=1643756>.

I still need to file bug reports for the first two examples, and there are more
examples that I haven't recorded in long-term memory.  The recurring problem,
however, is that Esperanto is the exception.  It's a special case that a lot of
projects don't account for, because what language could possibly not have a
country?

A simple, satisfactory solution would be to no longer make Esperanto a special
case.  Make it the same as all the other locales, and the problems will sort of
go away.  There are a couple of approaches to this:

1. Create "eo_NL" just like Interlingua---an auxiliary conlang similar to
   Esperanto--- has "ia_FR".  Separate locales might need to be created for
   different countries.

2. Create "eo_XX" or "eo_EO" as an exact copy of the current "eo" locale,
   excluding a lot of LC_ADDRESS information.

3. Create "eo_XX" or "eo_EO" with a fake "Esperantujo" country and currency.

4. Add a fake "Esperantujo" country and currency to the current "eo" locale,
   which might solve some problems, maybe?

5. Some combination of the above.

I have a slight preference for the first solution.  Users would be able to use
Esperanto while retaining their local currency, date formatting, etc etc etc.
It is also preferable in the sense that Interlangua already does this, thus
precedence has been set.

Alternative #6 is to keep the status quo and fix all the bugs in third party
projects that do not account for the special case of Esperanto.  This doesn't
scale very well, though.  If another no-country language comes along, it will
have to be added as exception to these other projects again.  It's also
cumulatively just a lot of work for a special case that not so many people use,
anyway.

I've briefly talked to Rafal about this issue on Fedora's trans list.  I think
we agree that it's not really a glibc bug, thus I felt hesitant reporting it
here, but a lot of tiny bugs in a lot of projects that use glibc.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

Florian Weimer <fweimer at redhat dot com> changed:

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

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I'm not really convinced this is a glibc bug.

Wouldn't it make sense to fix applications bugs instead?

There are other artificial languages which may face the same issue once we add
it to glibc.  Yiddish currently has a US locale, but isn't this a bit odd?

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

--- Comment #2 from Carmen Bianca Bakker <carmenbianca at fedoraproject dot org> ---
(In reply to Florian Weimer from comment #1)
> I'm not really convinced this is a glibc bug.
>
> Wouldn't it make sense to fix applications bugs instead?

I agree that it isn't, and I agree that it would make sense to fix application
bugs. The problem is that those application bugs happen because glibc presents
a special case, and one could undo all these application bugs simultaneously by
making sure that the special case isn't special anymore.

Even something so simple as my proposed solution 2 would get rid of a lot of
bugs in programs that expect all locales to look like lang_COUNTRY.

> There are other artificial languages which may face the same issue once we
> add it to glibc.  Yiddish currently has a US locale, but isn't this a bit
> odd?

If there's a sizeable population of Yiddish speakers in the US, then that
probably makes sense. It wouldn't make sense for Yiddish speakers outside of
the US, though.  Problem is: Do you want to create a glibc locale for every
possible country where Yiddish is spoken in some capacity? That would
ultimately be the best solution for users, but might cause an annoying
maintenance burden on glibc.

Ideally I'd like to see language and country completely separated from each
other instead of combined in locales, because that would ultimately make the
most sense, but that would be a super big redesign that I am not comfortable
with proposing.  I'm currently limiting my scope to making Esperanto (more)
usable on Fedora Workstation, and I think some of my above suggestions could
significantly improve the status of Esperanto with relatively little effort
(i.e., fixing all application bugs).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

--- Comment #3 from Dmitry V. Levin <ldv at sourceware dot org> ---
(In reply to Florian Weimer from comment #1)
> There are other artificial languages which may face the same issue once we
> add it to glibc.  Yiddish currently has a US locale, but isn't this a bit
> odd?

The comment is confusing.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Dmitry V. Levin from comment #3)
> (In reply to Florian Weimer from comment #1)
> > There are other artificial languages which may face the same issue once we
> > add it to glibc.  Yiddish currently has a US locale, but isn't this a bit
> > odd?
>
> The comment is confusing.

Sorry, the two sentences are really separate.  I did not want to imply that
Yiddish is an artificial language.  I think the majority of Yiddish speakers is
*not* located in the United States.  I suspect the locale was added under “US”
because there was no precedent for a locale without a country at the time.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

Rafal Luzynski <digitalfreak at lingonborough dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |digitalfreak@lingonborough.
                   |                            |com

--- Comment #5 from Rafal Luzynski <digitalfreak at lingonborough dot com> ---
Hello Carmen, thank you for filing this bug report.

(In reply to Carmen Bianca Bakker from comment #0)
> [...]
> I still need to file bug reports for the first two examples, and there are
> more
> examples that I haven't recorded in long-term memory.  [...]

I encourage you to file those bug reports.  Are they maybe caused by the
previous bug in glibc packaging in Fedora?

> [...]
> 1. Create "eo_NL" just like Interlingua---an auxiliary conlang similar to
>    Esperanto--- has "ia_FR".  Separate locales might need to be created for
>    different countries.

I was not aware of this case with Interlingua.  I would rather go for renaming
"ia_FR" to "ia" so that "eo" would not be alone anymore :-) but my knowledge
about Interlingua is too little to enforce it now.

> [...]
> Alternative #6 is to keep the status quo and fix all the bugs in third party
> projects that do not account for the special case of Esperanto.

This is my preferred choice and therefore I agree with Florian (comment 1) that
this is not a bug here.  Also, I think it's good if we approach other projects
and explain them how to fix the issue correctly.

(In reply to Carmen Bianca Bakker from comment #2)
> (In reply to Florian Weimer from comment #1)
> > There are other artificial languages which may face the same issue once we
> > add it to glibc.  Yiddish currently has a US locale, but isn't this a bit
> > odd?
>
> If there's a sizeable population of Yiddish speakers in the US, then that
> probably makes sense.

As far as I know yes, there is a large population of Yiddish speakers in the
US, they are about 160,000 people and I'm not sure but likely they are the
largest Yiddish population in the world.

> It wouldn't make sense for Yiddish speakers outside of
> the US, though.  Problem is: Do you want to create a glibc locale for every
> possible country where Yiddish is spoken in some capacity? [...]

Most of the time this makes sense if two (or more) populations speaking the
same language in two countries develop their languages to the extent that they
differ little and actually make two variants of a language.  Good examples are
US English vs. British English or Brazilian Portuguese vs. European Portuguese.

A secondary reason is when we want to provide other locale-dependent settings
for multiple countries speaking the same language.

So adding a locale makes sense if there is a population needing that.
Existence of a locale in CLDR and an official recognition of a language by the
local authorities are good argument for adding a locale variant.

> Ideally I'd like to see language and country completely separated from each
> other instead of combined in locales, because that would ultimately make the
> most sense,

Multiple environment variables (LC_MESSAGES, LC_MEASUREMENT, etc.) solve this
problem to some extent.  That means, you don't have every combination of
language/country but you can choose a separate locale for different purposes
and that should be usually sufficient.

> but that would be a super big redesign that I am not comfortable
> with proposing.

+1

> I'm currently limiting my scope to making Esperanto (more)
> usable on Fedora Workstation, and I think some of my above suggestions could
> significantly improve the status of Esperanto with relatively little effort
> (i.e., fixing all application bugs).

Thank you for your effort, please continue.

Again, I think this is not a bug but I don't mind if we discuss this here.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug localedata/23857] Esperanto has no country

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
https://sourceware.org/bugzilla/show_bug.cgi?id=23857

--- Comment #6 from Carmen Bianca Bakker <carmenbianca at fedoraproject dot org> ---
Hi Rafal,

(In reply to Rafal Luzynski from comment #5)
> I encourage you to file those bug reports.  Are they maybe caused by the
> previous bug in glibc packaging in Fedora?

https://gitlab.gnome.org/GNOME/gnome-control-center/issues/260 - Appears
glibc-related, because the languages and locales/formats map directly to glibc
options.  I wish I was more competent with C, and I'd try to fix it up myself.

https://bugs.python.org/issue35163 - Some weird obsolete configuration.

> I was not aware of this case with Interlingua.  I would rather go for
> renaming "ia_FR" to "ia" so that "eo" would not be alone anymore :-) but my
> knowledge about Interlingua is too little to enforce it now.

Is it okay to add the author of the original Interlingua bug report to this bug
report?  Perhaps they can add an original insight, and perhaps their motivation
for choosing "ia_FR" over "ia".

> > It wouldn't make sense for Yiddish speakers outside of
> > the US, though.  Problem is: Do you want to create a glibc locale for every
> > possible country where Yiddish is spoken in some capacity? [...]
>
> Most of the time this makes sense if two (or more) populations speaking the
> same language in two countries develop their languages to the extent that
> they differ little and actually make two variants of a language.  Good
> examples are US English vs. British English or Brazilian Portuguese vs.
> European Portuguese.
>
> A secondary reason is when we want to provide other locale-dependent
> settings for multiple countries speaking the same language.
>
> So adding a locale makes sense if there is a population needing that.
> Existence of a locale in CLDR and an official recognition of a language by
> the local authorities are good argument for adding a locale variant.

CLDR has "Unknown Region" listed under ZZ, which would work sufficiently well
for country-less languages.  i.e., proposed solution 2, or solution 3 with
"Unknown Region" as country (and "XXX" as currency).

https://unicode.org/cldr/charts/34/summary/root.html

It could also work for Yiddish, where "yi_US" is for the Yiddish population
inside the US, and "yi_ZZ" could be used by non-US Yiddish populations who are
spread across many other countries.  Though in the case of Yiddish
specifically, it might probably make sense to add an Israel entry, but that
will likely depend on a qualified volunteer doing the work.

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