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

["carmenbianca at fedoraproject dot org" <sourceware-bugzilla at sourceware dot org>]

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.