From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5638 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: locale fallback option Date: Sat, 26 Jul 2014 22:08:03 -0400 Message-ID: <20140727020803.GS4038@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406426904 10565 80.91.229.3 (27 Jul 2014 02:08:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2014 02:08:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5643-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 27 04:08:17 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XBDsm-0006Du-Cz for gllmg-musl@plane.gmane.org; Sun, 27 Jul 2014 04:08:16 +0200 Original-Received: (qmail 11310 invoked by uid 550); 27 Jul 2014 02:08:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11302 invoked from network); 27 Jul 2014 02:08:15 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5638 Archived-At: 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