From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91426 invoked by alias); 4 Nov 2018 13:26:15 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 91352 invoked by uid 48); 4 Nov 2018 13:26:11 -0000 From: "carmenbianca at fedoraproject dot org" To: libc-locales@sourceware.org Subject: [Bug localedata/23857] New: Esperanto has no country Date: Sun, 04 Nov 2018 13:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carmenbianca at fedoraproject dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2018-q4/txt/msg00101.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23857 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. F= or 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=3Deo python3`, you get `locale.getlocale() =3D=3D ('eo_XX', 'ISO8853-3')`. - In a lot of packages, you'll see something like `*_*` to match all locale= s. Esperanto has to be separately mentioned such that the expression becomes= `eo *_*`. See . 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 proble= m, however, is that Esperanto is the exception. It's a special case that a lo= t 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 spec= ial case. Make it the same as all the other locales, and the problems will sor= t 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 et= c. 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 wi= ll 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 th= ink 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. --=20 You are receiving this mail because: You are on the CC list for the bug.