[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Jul 2014 22:08:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: locale fallback option
On Sat, Jul 26, 2014 at 11:46:31PM +0200, Wermut wrote:
> Hi
>
> I just read, that you committed the basic locale code and about the
> musl firsts and thought of one thing that I would really like to see
> in a modern implementation.
>
> 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
> the language "ts" which is also spoken in "AB", but he does not know
> any english.
>
> Status quo: Because the translation "xyz_AB" is not really complete,
> the user A gives up, is frustrated and sets his locale to "ts_AB".
>
> What really should be possible: User A sets the locale "xyz_AB" and
> sets "ts_AB" as a fallback for definitions and strings not available
> in "xyz_AB". Only if a string is not defined in either "xyz_AB" or
> "ts_AB", the hardcoded english string is shown to him.
>
> This would require, that the locale definition would accept something
> like LANG=xyz_AB:ts_AB
What you're asking for is roughly possible with GNU gettext and the
LANGUAGE environment variable. See:
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
This does not facilitate partial translations with fallback to a
different language, but does facilitate the situation where only some
apps have the user's preferred language and others only have a more
widely-used language.
I think we should support the exact same thing in musl's internal
gettext. Whether we should support fallbacks in the LC_* variables for
the locale too is an open question, but I don't think there's any
reason at all to consider "partial translations" with fallback to a
different language for locales. The number of messages is just so
small (and not going to significantly increase) that it really doesn't
make sense to have partial translations. Fallbacks kind of make sense,
but you can always choose a language that libc actually has for the
_locale_, then put the list of application languages in the LANGUAGE
variable, so I'm not clear on how fallbacks would let you do anything
you couldn't otherwise do or make it significantly easier. Does this
make sense?
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.
