From: "carmenbianca at fedoraproject dot org" <sourceware-bugzilla@sourceware.org>
To: libc-locales@sourceware.org
Subject: [Bug localedata/23857] New: Esperanto has no country
Date: Sun, 04 Nov 2018 13:26:00 -0000 [thread overview]
Message-ID: <bug-23857-716@http.sourceware.org/bugzilla/> (raw)
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.
next reply other threads:[~2018-11-04 13:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-04 13:26 carmenbianca at fedoraproject dot org [this message]
2018-11-05 13:44 ` [Bug localedata/23857] " fweimer at redhat dot com
2018-11-05 15:33 ` carmenbianca at fedoraproject dot org
2018-11-05 17:20 ` Roumen Petrov
2018-11-05 16:01 ` ldv at sourceware dot org
2018-11-05 16:11 ` fweimer at redhat dot com
2018-11-07 23:48 ` digitalfreak at lingonborough dot com
2018-11-08 7:49 ` carmenbianca at fedoraproject dot org
2018-11-17 0:11 ` digitalfreak at lingonborough dot com
2018-11-20 12:02 ` carmenbianca at fedoraproject dot org
2018-11-20 12:17 ` fweimer at redhat dot com
2018-12-20 9:38 ` pander at users dot sourceforge.net
2024-01-06 21:07 ` maiku.fabian at gmail dot com
2024-01-09 11:20 ` maiku.fabian 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-23857-716@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).