Re: setlocale behavior with 'missing' locales

[Rich Felker <dalias@libc.org>]

On Sun, Nov 12, 2017 at 04:19:51PM -0600, A. Wilcox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 07/11/17 23:27, Rich Felker wrote:
> > One notable issue is that, right now, we rely on being able to set 
> > LC_MESSAGES to an arbitrary name even if there's no libc locale 
> > definition for it; this is because gettext() relies on the name of
> > the current LC_MESSAGES locale to find (application-specific)
> > translation files that might exist even without a libc translation.
> > I'm not sure how we would best keep this working under changes
> > similar to the above.
> 
> I can think of two ways to handle it, but neither of them are all that
> great:
> 
> 1) Provide simple translations for the most common 90% of languages.
> Some people are getting unfairly screwed here, but they are probably
> getting screwed by every other app/library as well.  It should be very
> simple to find a list of month names and abbreviations online for
> pretty much any language (even using Wikipedia's month article
> translations or Microsoft's Open Software Translations project).

This is an interesting idea I once considered, but it has too many
problems. It's a large volume of data that would be duplicated in
every static-linked application, and at least some of it would become
outdated or would be subject to user disagreement about what it should
be -- things like time formatting, radix separator (if we make it
variable at all), etc. Also the category in question is LC_MESSAGES,
which has nothing to do with dates but rather strerror messages and
such. Having default translations for these for all languages linked
into libc really does not make sense.

> 2) Use an access(3) call for /usr/share/locale/$LC_MESSAGES.  This
> means there is virtually no work for musl beyond adding the call, and
> it will only succeed if the locale is available (which is exactly what
> the standard demands).  The two problems I see with this is:

access() is generally always wrong (uses wrong permissions when real &
effective ids differ), but that's a minor detail. However I don't see
how this tells you anything useful. All it tells you is whether at
least some application installed in the given prefix (here /usr) has
translation files for the particular locale name. It doesn't tell you
whether the running application does (false positives), nor does it
tell you whether applications with different prefixes might (false
negatives).

>   1) if /usr/share is NFS shared this could lock.
>      But it would do so anyway if setlocale(3) succeeded.
> 
>   2) it requires use of stdio which most people on this list hate.

I don't see what relation it has to stdio.

Rich