From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5645 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: locale fallback option Date: Sun, 27 Jul 2014 04:12:52 -0400 Message-ID: <20140727081252.GV4038@brightrain.aerifal.cx> References: <20140727020803.GS4038@brightrain.aerifal.cx> 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 1406448801 22519 80.91.229.3 (27 Jul 2014 08:13:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2014 08:13:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5650-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 27 10:13:15 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 1XBJZx-0002cr-JC for gllmg-musl@plane.gmane.org; Sun, 27 Jul 2014 10:13:13 +0200 Original-Received: (qmail 23708 invoked by uid 550); 27 Jul 2014 08:13:07 -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 23681 invoked from network); 27 Jul 2014 08:13:04 -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:5645 Archived-At: 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