From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1394 invoked by alias); 6 Nov 2013 23:57:46 -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 1341 invoked by uid 89); 6 Nov 2013 23:57:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: rap.rap.dk Date: Wed, 06 Nov 2013 23:57:00 -0000 From: Keld Simonsen To: bugdal at aerifal dot cx Cc: libc-locales@sourceware.org Subject: Re: [Bug localedata/14641] Add a strftime()-like function for formatting human names Message-ID: <20131106235735.GA8030@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/msg00059.txt.bz2 On Wed, Nov 06, 2013 at 04:30:28PM +0000, bugdal at aerifal dot cx wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=14641 > > --- Comment #6 from Rich Felker --- > On Wed, Nov 06, 2013 at 04:08:37PM +0000, simon.mcvittie at collabora dot co.uk > wrote: > > OK, so is your position that _NL_NAME_NAME_FMT should never be used, and if we > > need similar functionality, we should invent our own? > > My opinion on this is not authoritative for glibc, but yes, my > position is that this locale property should be considered deprecated > and that new features using it should not be added. My reasoning is > that treating name formatting as a property of the user's locale is > fundamentally wrong. The way you format a person's name is a function > of _their_ cultural conventions, not your cultural conventions. Since > libc's locale system does not and cannot know the conventions > associated with the name being formatted, it cannot help you get the > correct results. > > In some sense, _NL_NAME_NAME_FMT is less of an offense because it > might help programs know the right formatting (or a right default to > try) for new names introduced by the user. If a program takes the > format string and does its own formatting, it can also accept other > non-default formats. But if a program requests that the libc do the > formatting based on the current locale, there is no way to handle > non-default formats. In this sense, I would object less to a function > like strftime for names that took the name format string as an > explicit argument, rather than using the current locale's format > string. This is certainly an option that could be proposed and > discussed. Well, the intention with this specification is to be able to format an address according to the local conventions for the specific language and territory. In most cases the information is also usable as a user's set of locale preferences, but you are right that an address is mostly useful in the format of the local conventions for that address. The intended use is then to switch to the locale of the address in question, for eg formatting of an address for a postal letter. To find the correct locale for a given address is not straightforward. You would often have a country associated with the address and then you could find a locale related to that country. The information does relate to a i18n problem and does a much better job than the often seen US formatting of addresses. I do not think it should be depreciated. best regards keld