public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug localedata/14641] Deprecate name_fmt Date: Tue, 17 Jun 2014 17:08:00 -0000 [thread overview] Message-ID: <bug-14641-131-QstudXSj7P@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-14641-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=14641 --- Comment #17 from Rich Felker <bugdal at aerifal dot cx> --- 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.
next prev parent reply other threads:[~2014-06-17 17:08 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-28 11:33 [Bug localedata/14641] New: Add a strftime()-like function for formatting human names bugzilla at tecnocode dot co.uk 2012-09-28 12:06 ` [Bug localedata/14641] " keld at keldix dot com 2012-09-28 12:21 ` bugdal at aerifal dot cx 2013-11-06 12:54 ` simon.mcvittie at collabora dot co.uk 2013-11-06 15:11 ` bugdal at aerifal dot cx 2013-11-06 16:10 ` simon.mcvittie at collabora dot co.uk 2013-11-06 20:33 ` Ondřej Bílka 2013-11-06 16:32 ` bugdal at aerifal dot cx 2013-11-06 20:35 ` neleai at seznam dot cz 2013-11-06 23:57 ` keld at keldix dot com 2013-11-07 2:26 ` bugdal at aerifal dot cx 2013-11-07 15:00 ` bugdal at aerifal dot cx 2013-11-07 19:02 ` keld at keldix dot com 2014-06-17 4:17 ` fweimer at redhat dot com 2014-06-17 7:32 ` [Bug localedata/14641] Deprecate name_fmt bugzilla at tecnocode dot co.uk 2014-06-17 7:48 ` fweimer at redhat dot com 2014-06-17 16:55 ` keld at keldix dot com 2014-06-17 17:08 ` bugdal at aerifal dot cx [this message] 2014-06-19 22:47 ` bugzilla at tecnocode dot co.uk 2014-06-20 5:48 ` keld at keldix dot com 2014-06-20 6:16 ` bugdal at aerifal dot cx 2014-06-20 11:04 ` keld at keldix dot com 2014-06-20 13:01 ` bugzilla at tecnocode dot co.uk 2014-06-21 18:36 ` keld at keldix dot com 2014-06-23 7:44 ` fweimer at redhat dot com 2014-06-23 13:02 ` keld at keldix dot com 2014-06-23 15:42 ` myllynen at redhat dot com 2014-06-23 21:07 ` keld at keldix dot com 2014-06-23 21:20 ` bugdal at aerifal dot cx 2014-06-23 22:13 ` keld at keldix dot com 2014-06-24 7:38 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-14641-131-QstudXSj7P@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).