public inbox for libc-locales@sourceware.org
 help / color / mirror / Atom feed
From: "carmenbianca at fedoraproject dot org" <sourceware-bugzilla@sourceware.org>
To: libc-locales@sourceware.org
Subject: [Bug localedata/23857] Esperanto has no country
Date: Mon, 05 Nov 2018 15:33:00 -0000	[thread overview]
Message-ID: <bug-23857-716-UjwdrIo6wq@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-23857-716@http.sourceware.org/bugzilla/>

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.

  parent reply	other threads:[~2018-11-05 15:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 13:26 [Bug localedata/23857] New: " carmenbianca at fedoraproject dot org
2018-11-05 13:44 ` [Bug localedata/23857] " fweimer at redhat dot com
2018-11-05 15:33 ` carmenbianca at fedoraproject dot org [this message]
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-UjwdrIo6wq@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).