public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "keld at keldix dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/14641] Deprecate name_fmt
Date: Mon, 23 Jun 2014 22:13:00 -0000	[thread overview]
Message-ID: <bug-14641-131-MSEJHzBnyU@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 #29 from keld at keldix dot com <keld at keldix dot com> ---
On Mon, Jun 23, 2014 at 09:19:57PM +0000, bugdal at aerifal dot cx wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #28 from Rich Felker <bugdal at aerifal dot cx> ---
> > One could actually introduce a new keyword for women unmarried+married.
> > This is a convention found in many cultures.
> 
> This would be a very bad change from my perspective. The entire aim of the
> locale system should be avoiding offending users by presenting information in a
> way that's culturally inappropriate. While in many cultures there is such a
> historical distinction in titles, it's generally not necessary to use such
> titles at all, and there will be a segment of members of the given culture who
> are offended by it, consider it backwards, misogynist, etc. like Florian
> mentioned. The locale system should not be reinforcing or giving preference to
> conservative elements of the cultures it's modelling. It should be neutral and
> acceptable to as diverse a group of people within the culture as possible.
> 
> On a related issue, even storing people's gender or sex in your data is a bad
> idea unless it's absolutely essential. What do you do when the person's gender
> is ambiguous (particularly a problem in information systems where an employee,
> rather than the person being identified, enters their information into the
> system), or when the gender on their legal documents does not match the gender
> they identify as? Many systems nowadays seem to ask users to choose their title
> rather than asking them for gender, which seems like a thinly-veiled way of
> asking for gender, but even that has problems. For example you risk non-native
> speakers of the language not understanding what title means or what the choices
> are, then getting offended later when they're called by a gender-inappropriate
> title they (accidentally) selected.
> 
> Anyway perhaps this is all tangential, but my point is that the locale system
> should be deprecating all of these things rather than reinforcing them.

Well, my take is that we are not political with the locales. We just record
what cultural things that are in use. Then we leave it to implementers
and users to do what they want to do, in a way that is culturally acceptable.

I myself do not use titles normally in my work, for example in my ISO
work, but many of my collegues do. I then provide for their use, and
allow them to do what is natural to them. I also recognize that in a culture,
there may be several levels of politeness. An invitation to a formal
anniversary, or a legal letter may have other levels of politeness than a SMS:

In some way the locales are conservative, preserving the different cultures
of the world in the digital society. In some other way the locales are
liberating, allowing a culturally acceptable appearance of applications in
most of the cultures of the world. At least the locales should enable us to 
get rid of English oriented conventions, which are not acceptable in may
cultures of the world.

Best regards
Keld

-- 
You are receiving this mail because:
You are on the CC list for the bug.


  parent reply	other threads:[~2014-06-23 22:13 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
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 [this message]
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-MSEJHzBnyU@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: link
Be 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).