[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190313005239.GD23599@brightrain.aerifal.cx>
Date: Tue, 12 Mar 2019 20:52:39 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Slight improvement to __get_locale?
On Mon, Mar 11, 2019 at 01:45:31PM -0500, A. Wilcox wrote:
> Hi muslers,
>
> We have a proposal to make locales work a tiny bit better on musl.
> Currently, there is no locale map file (which, there generally will
> never be one, until the rest of the locale system is overhauled and made
> more..public), and musl will simply let you setlocale(3) to anything.
>
> Our proposal is that __get_locale could determine if any of the
> following paths exist:
>
> /usr/share/locale/$foo
> /usr/share/locale/${foo/.//}
I don't really like the hard-coded paths, and I think they have false
negatives that would be unfortunate. For example if your base system
in /usr doesn't have any NLS, but locally-installed apps in /usr/local
do, you'd want to see their translations. Even adding
/usr/local/share/locale wouldn't really help, since the package might
have its translation files somewhere else (like
/opt/pkgname/share/locale or something).
> If one exists, the function succeeds. Otherwise, it fails. The builtin
> locales would not be affected, so C.UTF-8 and POSIX would always be
> available and working.
I forget if the framework for __get_locale to be able to fail without
breaking UTF-8 is in place yet. I know I started on the work, but
didn't make the final changes that would activate it. This needs to be
checked before we introduce that. Note that the existing (prior to
your email) proposal to introduce it would just drop visibility of any
locale names where musl doesn't itself have a locale file. So in some
sense, even with drawbacks your proposal is "better" in some ways,
just less consistent.
> I seem to recall that a similar discussion was had here many years ago,
> but I could not find it in my archives (and Openwall still has no search
> functionality). I would be willing to write the implementation, and we
> would be testing it in a wide variety of environments across different
> CPU architectures and software packages.
>
> The only drawback we have determined would be that this may not be
> compatible with slashpackage. There may be others, but they were not
> immediately evident. If the musl community does not want this, we are
> okay with that as well.
I don't want to reject it outright, but I think we really need a "big
picture" plan for how we intend locale to work with musl. It might
make sense to have some sort of meetup (either physical or virtual) of
parties interested in the outcome with a goal of identifying what
everybody's requirements are for this functionality to be useful and
how to achieve them in ways that don't unnecessarily step on toes or
break things.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
