From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110738 invoked by alias); 22 Feb 2016 08:10:07 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 110718 invoked by uid 89); 22 Feb 2016 08:10:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=14652, Hx-languages-length:1456, wg20, H*u:1.5.20 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rap.rap.dk Date: Mon, 22 Feb 2016 08:10:00 -0000 From: Keld Simonsen To: vapier at gentoo dot org Cc: libc-locales@sourceware.org Subject: Re: [Bug localedata/14641] LC_NAME: deprecate locale category Message-ID: <20160222080955.GA21754@rap.rap.dk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2016-q1/txt/msg00181.txt.bz2 On Sat, Feb 20, 2016 at 04:50:29AM +0000, vapier at gentoo dot org wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=14641 > > --- Comment #37 from Mike Frysinger --- > (In reply to keld@keldix.com from comment #36) > > i was looking at POSIX: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html > > ISO 30112 does not appear to be public, and i'm not about to waste $200 on > private standards. `man 5 locale` is about the only public reference i can > find. Well, the ISO C standard is not public either, and we do try to follow it. There at copies of working drafts of ISO 14652 and ISO 30112 available: http://www.open-std.org/JTC1/SC22/WG20/docs/n972-14652ft.pdf http://www.open-std.org/JTC1/SC35/WG5/docs/30112d10.pdf Both specs have explicit reference to glibc, and some specific cooperation with glibc. > i don't see this limited bit of info being useful beyond toy programs, and even > those are limited to specific locales. if people are serious about localizing, > they're better off with a real library. having these fields in glibc misleads > them into thinking they're more useful than they actually are. better to cut > them off sooner and drive them to fuller solutions. As I wrote, this information is what is commonly sought for eg. flights and hotels. What do you have in mind of improvements? Best regards Keld