Re: locale fallback option

[Rich Felker <dalias@libc.org>]

On Sun, Jul 27, 2014 at 07:26:27AM +0200, Wermut wrote:
> Hi
> 
> I think your statements make sense :) BTW, by adding locale to musl
> you probably opened the pandora :)
> 
> You are right with the LC_* fallback. If you setup a new translation
> team, then probably these files are the first that get implemented.
> 
> The GNU LANGUAGE is indeed working for some use cases, but still
> has/had some limitations, when I tried it some time ago. The problem
> was, that LC_TIME etc. where not properly overwritten by gettext
> according to LANGUAGE. That means if I set "LC_ALL=xyz_AB" and added
> "LANGUAGE=xyz:ts", the dates with programs no translation in  to "xyz"
> had still the Dates etc. formatted according to it. In west european
> languages this is a no brainer, but it got ugly once you use different
> scripts to write both langs. Like mixing arabic and english.

I think I understand what you're saying, but I don't see any
alternative. The standard libc interfaces are required to honor the
LANG/LC_* variables, not other settings (i.e. LANGUAGE), and thus if
LC_TIME is xyz_AB, time/date strings are going to be in language xyz,
regardless of the language of message strings.

This is probably a bit disconcerting, but won't this kind of thing
happen anyway with mixed LANGUAGE fallback? For instance if app FOO
uses library BAR and BAZ, and only BAR has a translation in language
xyz, you'll see strings from BAR in language xyz mixed (possibly even
in the same text areas) with strings from FOO and BAZ in language ts.

Do you have any suggestions for how this situation could be improved?

> If at least gettext is made properly and would allow a really proper
> LANGUAGE functionality, then probably I would be happy.

I've got gettext working and ready to commit, but so far it's without
the LANGUAGE fallback system. I don't think it will be too hard to
add, and I think I could even make it fallback for individual strings
if desired at little or no extra cost. I'm going to commit the basic
working code first though then look into adding more features.

Rich