From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5642 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Sun, 27 Jul 2014 09:51:20 +0200 Message-ID: <20140727075120.GB16795@example.net> References: <20140723163907.GC11570@brightrain.aerifal.cx> <20140723192503.GG16795@example.net> <20140723210120.GD11570@brightrain.aerifal.cx> <20140724153526.GH16795@example.net> <20140724160150.GA4038@brightrain.aerifal.cx> <20140724201548.GM16795@example.net> <20140724220228.GB4038@brightrain.aerifal.cx> <20140725090649.GN16795@example.net> <20140725201551.GQ16795@example.net> <20140726204329.GR4038@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 1406447516 9471 80.91.229.3 (27 Jul 2014 07:51:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2014 07:51:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5647-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 27 09:51:50 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 1XBJFF-00088g-St for gllmg-musl@plane.gmane.org; Sun, 27 Jul 2014 09:51:49 +0200 Original-Received: (qmail 9450 invoked by uid 550); 27 Jul 2014 07:51:43 -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 9436 invoked from network); 27 Jul 2014 07:51:40 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe05.swip.net; client-ip=178.63.154.93; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140726204329.GR4038@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5642 Archived-At: On Sat, Jul 26, 2014 at 04:43:29PM -0400, Rich Felker wrote: > I wasn't quite sure where to inject this reply into the thread, but > one thing I just remembered is that glibc (and the XSI option for > POSIX) has [.charset] as part of the standard form for locale names, > and all of glibc's usable locales end in ".UTF-8". So a user on a > mixed system is likely to have their locale vars set to include > ".UTF-8 "at the end, and therefore wouldn't get any localization when > running musl-linked programs with the locale names we've proposed. Ah yes this is regrettable. The transition from legacy charsets/encodings has already happened and even with glibc .UTF-8 is a de-facto default, thus "shouldn't" have to be indicated. > The way I see it, we could either have the locale package provide > symlinks to all of the locales with ".UTF-8" on the end, or musl > itself could ignore anything starting with the first '.' in a locale > name. One downside of symlinks is that a locale could uselessly get > mapped twice if somebody happens to reference it by both names in > their locale vars. It also puts more of a configuration/complexity > burden on the installation. But it does keep policy out of libc and > saves a few bytes of code in libc. As an integrator I certainly appreciate if I can skip making zillions of legacy links. There is also a matter of spelling utf-8 Utf-8 UTF-8 utf8 UTF8 Utf8 utf_8 (did I forget some? :) which different distros/users may choose differently. Debian Linux: $ locale -a C C.UTF-8 <===== en_US.utf8 <===== POSIX $ Given that the library implies utf-8, please ignore .anything explicitly - this part of the name is meaningless for musl by design. A packager can not fully imitate such behaviour even with a lot of links. The rare cases when the user really means a different charset but gets utf-8 are better handled by the user if/when encountered. Rune