From: enh <firstname.lastname@example.org>
To: Rich Felker <email@example.com>
Subject: Re: [musl] A journey of weird file sorting and desktop systems
Date: Fri, 28 Jan 2022 10:33:53 -0800 [thread overview]
Message-ID: <CAJgzZorMYDML8NT4p7sX5DMMrT5+2=OZ+6soTCt2+=inHC8AOQ@mail.gmail.com> (raw)
On Fri, Jan 28, 2022 at 10:01 AM Rich Felker <firstname.lastname@example.org> wrote:
> On Fri, Jan 28, 2022 at 08:58:30AM -0800, enh wrote:
> > (Android's libc maintainer here...)
> > i'd argue this isn't a musl bug. on Android we make a clear distinction between:
> > 1. libc's responsibilities which, to paraphrase rich, are basically
> > "be unsurprising because your audience is OS/app developers who don't
> > speak all the languages their users use anyway". that is: "code point
> > order".
> That's not what I said. I speculated that part of the difficulty with
> getting people to care is that a large number of users personally
> prefer LC_COLLATE=C. Not that we should punt because of that.
> > 2. icu's responsibilities which cover all the user-facing (as opposed
> > to developer-facing) stuff. i18n is *hard* and the C/POSIX APIs are,
> > to be blunt, not fit for *that* purpose. there's a reason why all of
> > Android/macOS/Windows (and all the browsers) ship copies of icu.
> ICU is really, *really* bad. I don't want to be encouraging people to
> use it because basic functionality is missing from libc.
human languages are really really messy. a lot of the complexity is inherent.
as for the non-inherent, https://github.com/unicode-org/icu4x seems
like a good start.
> > the bug here is that a desktop file manager is assuming "i just want
> > telephone book order --- how hard can it be?". the answer turns out to
> > be "hard". especially when you get into fun stuff like users who *do*
> > speak multiple languages and have strong expectations for how they
> > sort. or places where there are multiple sort orders in common use.
> Absolutely. That's why I don't want to treat the problem half-assedly,
but that's my point --- it's not the *implementation* that's the
issue, it's that the C/POSIX *interfaces* are insufficient. the bar on
how good a job you _can_ do within those constraints is horribly low.
> but make sure we design or choose a format for the collation tables
> that's simultaneously (1) efficient, (2) sufficiently expressive to
> give the behaviors users may want, and (3) easy enough to understand
> that users can customize it if needed. The POSIX localedef format (an
> option group musl intentionally does not support) does not have any of
> those properties except maybe #2. The standard Unicode format may
> translate directly into something that can meet all 3; I'm not sure.
next prev parent reply other threads:[~2022-01-28 18:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 13:41 ellie
2022-01-28 14:10 ` Rich Felker
2022-01-28 14:57 ` ellie
2022-01-28 16:58 ` enh
2022-01-28 18:01 ` Rich Felker
2022-01-28 18:33 ` enh [this message]
2022-01-28 19:22 ` Rich Felker
2022-01-28 19:47 ` Markus Wichmann
2022-01-28 18:01 ` Ariadne Conill
2022-01-28 17:54 ` Ariadne Conill
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 NNTP newsgroup(s).