Re: locale fallback option

[Rich Felker <dalias@libc.org>]

On Sun, Jul 27, 2014 at 10:08:56AM +0200, u-igbb@aetey.se wrote:
> On Sat, Jul 26, 2014 at 11:46:31PM +0200, Wermut wrote:
> > Problem: User A speaks a language "xyz" and lives in country "AB". So
> > he will set the relevant locale environment vars to "xyz_AB". The
> > problem is, that the language "xyz" is only spoken by a minority of
> > people and the translation of the software in his language is often
> > not complete or non existend. The result is, that user A will have to
> > read the most strings in plain english, because this is the standard
> > fallback. Because our user A is a member of a minority, he knows also
>  ...
> > This would require, that the locale definition would accept something
> > like LANG=xyz_AB:ts_AB
> 
> I guess a similar effect could be achieved by
> 
> LANG=ts_AB LC_MESSAGES=xyz_AB    (or LC_MESSAGES=xyz_ZZ)
> 
> if fallback to LANG happens per-item in contrast to per-category.

It doesn't. The LC_ALL->LC_*->LANG->system_default fallback system is
simply per category and based on whether the variables are set (and
nonempty), not whether they resolve to a working locale. This is
probably less than ideal. I suppose I could define "system_default" as
doing a fallback with the remaining vars after omitting the ones that
don't work, but this would still be per-category. Per-item is rather
complex and requires having locale objects that are "hybrids" and
having a way to name and identify them (since setlocale has to be able
to return a name for the current setting back to the caller).

> Frankly, I think this is about a redesign of the locale system and
> hardly belongs to musl goals.

Yes. The system is largely broken -- it does too little to actually be
useful for serious adaptation to linguistic and cultural conventions
and to support multilingual text data, and it does far too much in the
sense of breaking use of the standard library functions for
information interchange purposes. For a long time I've wanted to
design and write a very light but powerful library for handling these
things correctly (completely independent of the libc locale system),
but it will probably be a very long time before I get around to doing
a project like that, if ever...

Rich