[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALONj1cv1z_PiGKDDbaG4eVZOdAYa_fhw6YaGxGyasDc=T+kKA@mail.gmail.com>
Date: Sun, 27 Jul 2014 07:26:27 +0200
From: Wermut <wermut@...il.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: locale fallback option
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.
If at least gettext is made properly and would allow a really proper
LANGUAGE functionality, then probably I would be happy.
I will test next week if glibc is still handling it like described.
Regards
Kevin
On Sun, Jul 27, 2014 at 4:08 AM, Rich Felker <dalias@...c.org> wrote:
> 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.
