mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: locale fallback option
Date: Sat, 26 Jul 2014 22:08:03 -0400	[thread overview]
Message-ID: <20140727020803.GS4038@brightrain.aerifal.cx> (raw)
In-Reply-To: <CALONj1dGcrcTJ=rU34FLcnR4qz6Rkqzhhv=Fm7okTienCygVOA@mail.gmail.com>

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


  parent reply	other threads:[~2014-07-27  2:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-26 21:46 Wermut
2014-07-26 21:51 ` writeonce
2014-07-27  2:08 ` Rich Felker [this message]
2014-07-27  5:26   ` Wermut
2014-07-27  8:12     ` Rich Felker
2014-07-27  8:08 ` u-igbb
2014-07-27  8:18   ` Rich Felker
2014-07-27  8:45     ` u-igbb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140727020803.GS4038@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).