From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31941 invoked by alias); 17 Oct 2013 21:05:44 -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 31897 invoked by uid 89); 17 Oct 2013 21:05:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rap.rap.dk Date: Thu, 17 Oct 2013 21:05:00 -0000 From: Keld Simonsen To: carlos at redhat dot com Cc: libc-locales@sourceware.org Subject: Re: [Bug localedata/16052] Provide European ordering rules (EOR / EN 13710) for locales Message-ID: <20131017210541.GI32359@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: 2013-q4/txt/msg00018.txt.bz2 On Tue, Oct 15, 2013 at 03:23:48PM +0000, carlos at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=16052 > > Carlos O'Donell changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |carlos at redhat dot com > > --- Comment #2 from Carlos O'Donell --- > (In reply to joseph@codesourcery.com from comment #1) > > Note that the ISO 14651 data in glibc is extremely out of date; see bug > > 14095. I don't know whether that would affect this issue - whether it > > would be necessary to update the ISO 14651 data first, understanding > > exactly how it relates to (an old version of) ISO 14651 in the process. > > We certainly need someone willing to spend a substantial amount of time > > understanding collation issues and how we got to the current state. (To a > > lesser extent, there are such issues for character map / LC_CTYPE > > information - see bug 14094 - both need substantial work to produce > > appropriate automation for easier future updates of this data while > > demonstrating that previous unautomated local changes aren't being > > inappropriately lost in the process.) > > Agreed. I think this work should fall on the shoulders of the distribution > maintainers. At some point I will be doing some work here, but my first goal is > to fix the state of getaddrinfo against the various RFCs. It is on my list that the 14651 list should be made compatible with glibc (or the other way around). The editor of 14651 is aware of the problem. But some things need to be accomplished before the 14651 editor and I undertake this work. Best regards Keld