From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18928 invoked by alias); 17 Jun 2014 17:09:02 -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 18437 invoked by uid 48); 17 Jun 2014 17:08:17 -0000 From: "bugdal at aerifal dot cx" To: libc-locales@sourceware.org Subject: [Bug localedata/14641] Deprecate name_fmt Date: Tue, 17 Jun 2014 17:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00174.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=14641 --- Comment #17 from Rich Felker --- There are two different arguments for deprecation of name_fmt that can be made based on comments in this pr: 1. Imposing a structure of first name, middle name, last name, etc. on names is itself a cultural convention that's far from universal. Providing a culture-specific way to format these poorly-thought-out name components into a combined string does not solve the problem of making a program compatible with diverse cultural conventions since such storage is already wrongly imposing particular conventions. 2. Locales should deal with the cultural conventions of the user's cultural environment, not the conventions associated with a particular piece of data. Of these, #1 only applies directly to name_fmt. If similar arguments apply to other items, that may be a good argument for their deprecation, but that would be a separate discussion. Argument #2 on the other hand applies to a much broader class of items, but I think it's also less clear-cut that it's correct. With the existence of uselocale/locale_t and de-facto conventions for locale names, one could argue that it's reasonable to use the locale system for dealing with data records where each record has associated with it a cultural context in which it's to be interpreted. I think this is probably a bad design (for example, many systems omit installation of all locales except the user's, which would affect what data they can process, and having a full locale installation is a lot more costly than just having external data on country-code-specific telephone number formatting, etc.) but I can see where some people would prefer it. -- You are receiving this mail because: You are on the CC list for the bug.