[Bug localedata/14641] New: Add a strftime()-like function for formatting human names

[Bug localedata/14641] New: Add a strftime()-like function for formatting human names

[bugzilla at tecnocode dot co.uk]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

             Bug #: 14641
           Summary: Add a strftime()-like function for formatting human
                    names
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: localedata
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugzilla@tecnocode.co.uk
                CC: libc-locales@sources.redhat.com
    Classification: Unclassified


It’s useful that glibc’s locale data collects together different locales’ ways
of formatting names as name_fmt (lh.2xlibre.net/values/name_fmt/). However,
this is difficult to use, and requires programs to implement their own parser
for the field descriptors. This causes duplication of code and means all the
programs have to be kept up-to-date with any changes to the set of allowed
field descriptors.

Would it be possible to add a function similar to strftime() which will parse a
*name* format string and substitute values for its field descriptors?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #1 from keld at keldix dot com <keld at keldix dot com> 2012-09-28 12:05:59 UTC ---
On Fri, Sep 28, 2012 at 11:33:42AM +0000, bugzilla at tecnocode dot co.uk
wrote:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
>              Bug #: 14641
>            Summary: Add a strftime()-like function for formatting human
>                     names
>            Product: glibc
>            Version: unspecified
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: localedata
>         AssignedTo: unassigned@sourceware.org
>         ReportedBy: bugzilla@tecnocode.co.uk
>                 CC: libc-locales@sources.redhat.com
>     Classification: Unclassified
> 
> 
> It???s useful that glibc???s locale data collects together different locales??? ways
> of formatting names as name_fmt (lh.2xlibre.net/values/name_fmt/). However,
> this is difficult to use, and requires programs to implement their own parser
> for the field descriptors. This causes duplication of code and means all the
> programs have to be kept up-to-date with any changes to the set of allowed
> field descriptors.
> 
> Would it be possible to add a function similar to strftime() which will parse a
> *name* format string and substitute values for its field descriptors?

yes, this is possible. I think it would be better to have one standardized way
than several
homegrown. Coul we find out what are the different current APIs vailable in
different
implementations?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2012-09-28 12:21:06 UTC ---
I think this feature is fundamentally misguided. There is no universal way to
represent a "broken down" human name; the whole "first name last name" or
"family name" concept is rooted in particular cultures and does not even apply
to others. I don't think glibc has any business perpetuating the concept that
it's reasonable for applications to store names like this.

Properly written applications should simply be storing a single "name" field as
one string, possibly tagged with a subrange of the string to be used as a
primary sort key. Other useful tagging would be rules specific to the named
persons' culture for how to transform their name into a salutation, etc. But
this is specific to the culture of the person being named, not the locale.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[simon.mcvittie at collabora dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

Simon McVittie <simon.mcvittie at collabora dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.mcvittie at collabora dot co
                   |                            |.uk

--- Comment #3 from Simon McVittie <simon.mcvittie at collabora dot co.uk> ---
(In reply to Rich Felker from comment #2)
> There is no universal way
> to represent a "broken down" human name; the whole "first name last name" or
> "family name" concept is rooted in particular cultures and does not even
> apply to others.

I agree that whenever more information is available, it's much better to use
it, but applications don't always have that luxury.

The current motivation for this feature request is Folks, a library to
aggregate contact/address-book information from various sources, much of it
modelled on vCard syntax. If we know the formatted name (vCard's "FN") we do
use it in preference to the structured name (vCard's "N", which might look like
"N:Bach;Johann;Sebastian;Herr;"), but if all we know is the structured name, we
need to display it somehow, and the user's locale seems a more reasonable guess
than "they're probably American".

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
On Wed, Nov 06, 2013 at 12:52:02PM +0000, simon.mcvittie at collabora dot co.uk
wrote:
> The current motivation for this feature request is Folks, a library to
> aggregate contact/address-book information from various sources, much of it
> modelled on vCard syntax. If we know the formatted name (vCard's "FN") we do
> use it in preference to the structured name (vCard's "N", which might look like
> "N:Bach;Johann;Sebastian;Herr;"), but if all we know is the structured name, we
> need to display it somehow, and the user's locale seems a more reasonable guess
> than "they're probably American".

I can't see the justification for having a library's behavior depend
on the user's locale, especially when the library's purpose is this
kind of information processing. Name formatting logic really belongs
in your library, with the options either as a setting (possibly with
an ability to request a reasonable default based on the locale) or
based on heuristics using the rest of the contact's info (like
country).

BTW I think this is getting mildly off-topic for the bug tracker, but
the reason I posted it here is that I think it's a justification for
which this functionality does not belong in libc -- the idea that
using the user's locale rather than a locale associated with the
individual name is the wrong thing to be doing, and that in library
code working with this kind of data, it's the third-party library's
job to do this hard work of getting it right.

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[simon.mcvittie at collabora dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora dot co.uk> ---
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?

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
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.

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

Re: [Bug localedata/14641] Add a strftime()-like function for formatting human names

[Ondřej Bílka]

On Wed, Nov 06, 2013 at 04:08:37PM +0000, simon.mcvittie at collabora dot co.uk wrote:
> --- Comment #5 from Simon McVittie <simon.mcvittie at collabora dot co.uk> ---
> 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?
>
Providing good support for formatting names is out of scope of libc. You
would want to get name declension, detect swapped first name (by looking
to name database), recognizing sex based on first name, which should be
handled by separate library.

I did not do a google querry but somebody probably already wrote library
that does this.

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #7 from Ondrej Bilka <neleai at seznam dot cz> ---
On Wed, Nov 06, 2013 at 04:08:37PM +0000, simon.mcvittie at collabora dot co.uk
wrote:
> --- Comment #5 from Simon McVittie <simon.mcvittie at collabora dot co.uk> ---
> 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?
>
Providing good support for formatting names is out of scope of libc. You
would want to get name declension, detect swapped first name (by looking
to name database), recognizing sex based on first name, which should be
handled by separate library.

I did not do a google querry but somebody probably already wrote library
that does this.

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #8 from keld at keldix dot com <keld at keldix dot com> ---
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 <bugdal at aerifal dot cx> ---
> 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

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #9 from Rich Felker <bugdal at aerifal dot cx> ---
On Wed, Nov 06, 2013 at 11:57:48PM +0000, keld at keldix dot com wrote:
> 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. 

This is not the way locales are supposed to be used. You don't just
keep switching them around at runtime. In your specific example of
formatting a letter, it's wrong, because you want the address
formatted according to the cultural conventions of the place in which
it's being sent, but the name written the way the recipient's name is
supposed to be written.

> 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. 

But that has nothing to do with how the name should be formatted, only
with how the address should be formatted. Also, depending on your
locale, the matter of formatting an address can depend on the
conventions of the recipient's country or the sender's. In any case
this logic is all way outside the scope of libc locale.

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> ---
On Thu, Nov 07, 2013 at 12:29:55PM +0000, keld at keldix dot com wrote:
> If there are different users then it is only natural to switch to each user's
> locale, eg when printing a name, or printing an address.

No. Locale names (and whether they even exist) are
implementation-defined. A correct application cannot use locales by
name, but can only use the user's configured locale or the C/POSIX
locale. Applications which assume the existence of particular locale
names are not portable, and even if you only cared about them working
on GNU/Linux systems, many such desktop systems only have one locale
installed (the user's own locale).

Even if you could assume the names and existence of locales, their
definitions may vary slightly between systems, which means the
interpretation of your data would not be portable. The key here is
that name "formatting" is not just presentation, it's actually
interpretation.

> I believe this is in scope of libc, meaning that this is to make an application
> culturally adaptable. It is just a more advanced use than the normal i18n,
> because we want to accomodate different users' cultural conventions.

No, the cultural conventions in question are not cultural conventions
of any users of the system. The data you're working with has been
encoded (I would go so far as to say "corrupted") in a way that's
dependent on the cultural conventions of the person whom it names (or
sometimes not even that, but the cultural conventions imposed on that
person by virtue of where they're living and their legal status
there). The problem is decoding it to the person's actual name.

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #12 from keld at keldix dot com <keld at keldix dot com> ---
On Thu, Nov 07, 2013 at 03:00:40PM +0000, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #11 from Rich Felker <bugdal at aerifal dot cx> ---
> On Thu, Nov 07, 2013 at 12:29:55PM +0000, keld at keldix dot com wrote:
> > If there are different users then it is only natural to switch to each user's
> > locale, eg when printing a name, or printing an address.
> 
> No. Locale names (and whether they even exist) are
> implementation-defined. A correct application cannot use locales by
> name, but can only use the user's configured locale or the C/POSIX
> locale. Applications which assume the existence of particular locale
> names are not portable, and even if you only cared about them working
> on GNU/Linux systems, many such desktop systems only have one locale
> installed (the user's own locale).

If you have an application that depends on more locales, then you need to have
those
locales installed. That is the case with everything, you do need to have
the appropiate software installed to solve your job.

Anyway there are standards for locale names, that libc should honour,
such as ISO 15897. Given that we are talking libc, it is reasonable
to assume that the locales of libc can be present, and that naming of locales
of libc can be used.


> Even if you could assume the names and existence of locales, their
> definitions may vary slightly between systems, which means the
> interpretation of your data would not be portable. The key here is
> that name "formatting" is not just presentation, it's actually
> interpretation.

As long as the locales conform to standards, the results generated
should be culturally acceptable, even if the locale data differ slightly.

> > I believe this is in scope of libc, meaning that this is to make an application
> > culturally adaptable. It is just a more advanced use than the normal i18n,
> > because we want to accomodate different users' cultural conventions.
> 
> No, the cultural conventions in question are not cultural conventions
> of any users of the system. The data you're working with has been
> encoded (I would go so far as to say "corrupted") in a way that's
> dependent on the cultural conventions of the person whom it names (or
> sometimes not even that, but the cultural conventions imposed on that
> person by virtue of where they're living and their legal status
> there). The problem is decoding it to the person's actual name.

Your interpretation is not in line with POSIX or ISO i18n model
(TR 11017) nor ISO C. And it is not in line with IPU recommendations. 

best regards
keld

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

[Bug localedata/14641] Add a strftime()-like function for formatting human names

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fweimer at redhat dot com
         Resolution|---                         |WONTFIX
              Flags|                            |security-

--- Comment #13 from Florian Weimer <fweimer at redhat dot com> ---
Closing per previous discussion.

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

[Bug localedata/14641] Deprecate name_fmt

[bugzilla at tecnocode dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

Philip Withnall <bugzilla at tecnocode dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---
            Summary|Add a strftime()-like       |Deprecate name_fmt
                   |function for formatting     |
                   |human names                 |

--- Comment #14 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
(In reply to Florian Weimer from comment #13)
> Closing per previous discussion.

As per comments #5 and #6, I think the proper solution is to deprecate
name_fmt, since it seems to be fundamentally incorrect to have it in libc, and
keeping it un-deprecated just encourages people to use it incorrectly or
unsuccessfully.

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

[Bug localedata/14641] Deprecate name_fmt

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #15 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Philip Withnall from comment #14)
> (In reply to Florian Weimer from comment #13)
> > Closing per previous discussion.
> 
> As per comments #5 and #6, I think the proper solution is to deprecate
> name_fmt, since it seems to be fundamentally incorrect to have it in libc,
> and keeping it un-deprecated just encourages people to use it incorrectly or
> unsuccessfully.

Fair enough.  That would extend to LC_NAME, LC_ADDRESS, LC_TELEPHONE, I
suppose.  What about LC_MEASUREMENT and LC_IDENTIFICATION?

Related identifiers include _NL_NAME_*, _NL_ADDRESS_*, _NL_TELEPHONE_*, plus
the _NL_NUM_* identifiers.  Anything else?

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #16 from keld at keldix dot com <keld at keldix dot com> ---
On Tue, Jun 17, 2014 at 07:48:21AM +0000, fweimer at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #15 from Florian Weimer <fweimer at redhat dot com> ---
> (In reply to Philip Withnall from comment #14)
> > (In reply to Florian Weimer from comment #13)
> > > Closing per previous discussion.
> > 
> > As per comments #5 and #6, I think the proper solution is to deprecate
> > name_fmt, since it seems to be fundamentally incorrect to have it in libc,
> > and keeping it un-deprecated just encourages people to use it incorrectly or
> > unsuccessfully.
> 
> Fair enough.  That would extend to LC_NAME, LC_ADDRESS, LC_TELEPHONE, I
> suppose.  What about LC_MEASUREMENT and LC_IDENTIFICATION?
> 
> Related identifiers include _NL_NAME_*, _NL_ADDRESS_*, _NL_TELEPHONE_*, plus
> the _NL_NUM_* identifiers.  Anything else?

Hmm, what is the reason for this? Name layout and the other issues are
cultural conventions that should be adaptable in software.

Best regards
Keld

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

[Bug localedata/14641] Deprecate name_fmt

[bugdal at aerifal dot cx]

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.

[Bug localedata/14641] Deprecate name_fmt

[bugzilla at tecnocode dot co.uk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 7170 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #18 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
(In reply to Florian Weimer from comment #15)
> (In reply to Philip Withnall from comment #14)
> > (In reply to Florian Weimer from comment #13)
> > > Closing per previous discussion.
> > 
> > As per comments #5 and #6, I think the proper solution is to deprecate
> > name_fmt, since it seems to be fundamentally incorrect to have it in libc,
> > and keeping it un-deprecated just encourages people to use it incorrectly or
> > unsuccessfully.
> 
> Fair enough.  That would extend to LC_NAME, LC_ADDRESS, LC_TELEPHONE, I
> suppose.  What about LC_MEASUREMENT and LC_IDENTIFICATION?

LC_MEASUREMENT and LC_IDENTIFICATION are in active use, and seem reasonably
well-defined and useful (for example, knowing which temperature units to use in
the current locale). LC_TELEPHONE also seems useful, giving international call
codes in and out of the current country.

I guess I’d say the cutoff is whether the formatting depends on the origin of
the data. For phone numbers it doesn’t (calling codes are internationally
defined), but for names and addresses.

> Related identifiers include _NL_NAME_*, _NL_ADDRESS_*, _NL_TELEPHONE_*, plus
> the _NL_NUM_* identifiers.  Anything else?

I can’t find anything else.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-23951-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jun 20 02:33:12 2014
Return-Path: <glibc-bugs-return-23951-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 6298 invoked by alias); 20 Jun 2014 02:33:10 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 6066 invoked by uid 55); 20 Jun 2014 02:33:03 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/6803] scalb(), scalbln(), scalbn() do not set errno on overflow/underflow
Date: Fri, 20 Jun 2014 02:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-6803-131-4jf55gohJV@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-6803-131@http.sourceware.org/bugzilla/>
References: <bug-6803-131@http.sourceware.org/bugzilla/>
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-06/txt/msg01327.txt.bz2
Content-length: 3699

https://sourceware.org/bugzilla/show_bug.cgi?idh03

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  3ef6b85059cdd52096625d98c4ce9259854cb8bb (commit)
       via  d8c2869d4450d54935c3410ad3093d51b5d85f79 (commit)
      from  c8daec5c7cd19378112391d2394e6d6344e156dc (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h>f6b85059cdd52096625d98c4ce9259854cb8bb

commit 3ef6b85059cdd52096625d98c4ce9259854cb8bb
Author: Stefan Liebler <stli@linux.vnet.ibm.com>
Date:   Fri Jun 20 07:48:20 2014 +0530

    [BZ #6803] Set errno for scalbln, scalbn

    Errno is not set and the testcases will fail.

    Now the scalbln-aliases are removed in i386/m68
    and the wrappers are used when calling the scalbln-functions.

    On ia64 only scalblnf has its own implementation.
    For scalbln and scalblnl the ieee754/dbl-64 and ieee754/ldbl-96 are used,
thus
    the wrappers are needed, too.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;hØc2869d4450d54935c3410ad3093d51b5d85f79

commit d8c2869d4450d54935c3410ad3093d51b5d85f79
Author: Stefan Liebler <stli@linux.vnet.ibm.com>
Date:   Fri Jun 20 07:44:42 2014 +0530

    Generate en_GB.UTF-8 during testing

    This patch generates en_GB.UTF-8, which is used in
    tst-strcoll-overflow.  This solves the issue of failing xtests on
    s390/s390x.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                      |   37 +++++++
 NEWS                                           |   24 ++--
 localedata/Makefile                            |    2 +-
 math/Makefile                                  |    2 +-
 math/libm-test.inc                             |  128 ++++++++++++------------
 math/w_scalbln.c                               |   40 ++++++++
 math/w_scalblnf.c                              |   36 +++++++
 math/w_scalblnl.c                              |   36 +++++++
 sysdeps/i386/fpu/s_scalbn.S                    |    1 -
 sysdeps/i386/fpu/s_scalbnf.S                   |    1 -
 sysdeps/i386/fpu/s_scalbnl.S                   |    1 -
 sysdeps/ia64/fpu/w_scalblnf.c                  |   20 ++++
 sysdeps/ieee754/dbl-64/s_scalbln.c             |    2 -
 sysdeps/ieee754/dbl-64/wordsize-64/s_scalbln.c |    2 -
 sysdeps/ieee754/flt-32/s_scalblnf.c            |    1 -
 sysdeps/ieee754/ldbl-128/s_scalblnl.c          |    1 -
 sysdeps/ieee754/ldbl-128ibm/s_scalblnl.c       |    1 -
 sysdeps/ieee754/ldbl-128ibm/w_scalblnl.c       |   23 ++++
 sysdeps/ieee754/ldbl-64-128/s_scalblnl.c       |    5 -
 sysdeps/ieee754/ldbl-64-128/w_scalblnl.c       |   27 +++++
 sysdeps/ieee754/ldbl-96/s_scalblnl.c           |    1 -
 sysdeps/m68k/m680x0/fpu/s_scalbn.c             |    1 -
 sysdeps/sparc/sparc64/soft-fp/s_scalblnl.c     |    2 -
 23 files changed, 297 insertions(+), 97 deletions(-)
 create mode 100644 math/w_scalbln.c
 create mode 100644 math/w_scalblnf.c
 create mode 100644 math/w_scalblnl.c
 create mode 100644 sysdeps/ia64/fpu/w_scalblnf.c
 create mode 100644 sysdeps/ieee754/ldbl-128ibm/w_scalblnl.c
 create mode 100644 sysdeps/ieee754/ldbl-64-128/w_scalblnl.c

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #19 from keld at keldix dot com <keld at keldix dot com> ---
On Tue, Jun 17, 2014 at 05:08:15PM +0000, bugdal at aerifal dot cx wrote:
> 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.

Well, the LC_MAME category was designed on research on very many countries and
cultures. 
Do you have examples where this does not work?

We also have some areas which do not always work culturally, for example 
dates, where we do not cover the islamic calender. Era calenders
are not covered either.

> 2. Locales should deal with the cultural conventions of the user's cultural
> environment, not the conventions associated with a particular piece of data.

Well, then we should have a look on who is actually the user.
In the case of names you could regard the receiver of a letter as the final
user.

The LC_NAME (and LC_ADDTESS) category addresses a real need for providing
culturally acceptable software. Really many cultures use the Family name,
first name convention, which is offending to me for my name. The world is
rather
split in two halves on the order of given name and family name.

The same with the other categories. They can be used to format culturally
correct data for really many cultures. But they are not fully complete
to cover all of the circumstances in the world. I would say that LC_TIME
is worse off than LC_NAME in the percentage of cases in the world it covers.


> 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.

The locale data does occupy quite some space. But in these days
disk space is pretty cheap, except for the telephones. If we only install the
locale data itself, and not all the message catalogues, then the extra cost is
reasonable.
glibc is not installed normally on android anyway. 

I don't know how many apps are using the LC_NAME category, but I estimate it is
not
many. I could see it handy in an address book, or telephone directory. And also
in a word
processing environment, for writing letters. I think what we have in LC_NAME is
the
best information in the market, and thus it gives glibc and edge. 
For the users that use the data it is really good that it is supported. 

Best regards
Keld

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

[Bug localedata/14641] Deprecate name_fmt

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #20 from Rich Felker <bugdal at aerifal dot cx> ---
On Fri, Jun 20, 2014 at 05:48:35AM +0000, keld at keldix dot com wrote:
> The LC_NAME (and LC_ADDTESS) category addresses a real need for providing
> culturally acceptable software. Really many cultures use the Family name,
> first name convention, which is offending to me for my name. The world is
> rather
> split in two halves on the order of given name and family name.

That's the naive and mistaken view that resulted in the creation of
LC_NAME/name_fmt to begin with. In reality there are a lot more
conventions than just these two, but the prevalence of information
systems that require names to be stored as a first/given name and a
last/family name seems to have made their existence much less visible.
Here are some other cultural conventions:

- Only one name. Attempting to force these into a given/family pattern
  is offensive and results in things like being assigned a "first
  name" of "FNU" and having your given name treated as a family name.

- Multiple names, but all given. Attempting to force these into a
  given/family pattern is almost always offensive because it will
  result in things like "Mr./Ms. Second-name", presenting a name
  backwards as "Second-name First-name", etc.

- Multiple family names. I don't even know how this is typically
  handled.

Wikipedia has some detailed coverage of the issues:

http://en.wikipedia.org/wiki/Family_name
http://en.wikipedia.org/wiki/Mononymous_person

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #21 from keld at keldix dot com <keld at keldix dot com> ---
On Fri, Jun 20, 2014 at 06:16:42AM +0000, bugdal at aerifal dot cx wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #20 from Rich Felker <bugdal at aerifal dot cx> ---
> On Fri, Jun 20, 2014 at 05:48:35AM +0000, keld at keldix dot com wrote:
> > The LC_NAME (and LC_ADDTESS) category addresses a real need for providing
> > culturally acceptable software. Really many cultures use the Family name,
> > first name convention, which is offending to me for my name. The world is
> > rather
> > split in two halves on the order of given name and family name.
> 
> That's the naive and mistaken view that resulted in the creation of
> LC_NAME/name_fmt to begin with. In reality there are a lot more
> conventions than just these two, but the prevalence of information
> systems that require names to be stored as a first/given name and a
> last/family name seems to have made their existence much less visible.
> Here are some other cultural conventions:
> 
> - Only one name. Attempting to force these into a given/family pattern
>   is offensive and results in things like being assigned a "first
>   name" of "FNU" and having your given name treated as a family name.
> 
> - Multiple names, but all given. Attempting to force these into a
>   given/family pattern is almost always offensive because it will
>   result in things like "Mr./Ms. Second-name", presenting a name
>   backwards as "Second-name First-name", etc.
> 
> - Multiple family names. I don't even know how this is typically
>   handled.
> 
> Wikipedia has some detailed coverage of the issues:
> 
> http://en.wikipedia.org/wiki/Family_name
> http://en.wikipedia.org/wiki/Mononymous_person

I think all of these examples can be covered with the existing LC_NAME spec.
And they were all known at the time of specification.

Best regards
keld

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

[Bug localedata/14641] Deprecate name_fmt

[bugzilla at tecnocode dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #22 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
(In reply to keld@keldix.com from comment #21)
> I think all of these examples can be covered with the existing LC_NAME spec.
> And they were all known at the time of specification.

Have you got a link to that and the associated discussion? The best I can find
is
   
https://sourceware.org/git/?p=glibc.git;a=commit;f=locale/langinfo.h;h=4b10dd6c1959577f57850ca427a94fe22b9f3299
which is not very informative.

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #23 from keld at keldix dot com <keld at keldix dot com> ---
On Fri, Jun 20, 2014 at 01:01:22PM +0000, bugzilla at tecnocode dot co.uk
wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #22 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
> (In reply to keld@keldix.com from comment #21)
> > I think all of these examples can be covered with the existing LC_NAME spec.
> > And they were all known at the time of specification.
> 
> Have you got a link to that and the associated discussion? The best I can find
> is
>    
> https://sourceware.org/git/?p=glibc.git;a=commit;f=locale/langinfo.h;h=4b10dd6c1959577f57850ca427a94fe22b9f3299
> which is not very informative.

This was discussion in ISO Sc22/WG20. The main input paper was:
http://www.cicc.or.jp/english/hyoujyunka/databook/databook.pdf
Some was discussed orally in WG20 meetings, I do not think there are 
a specific recording of that discussion.

Best regards
Keld

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

[Bug localedata/14641] Deprecate name_fmt

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #24 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to keld@keldix.com from comment #21)
> I think all of these examples can be covered with the existing LC_NAME spec.
> And they were all known at the time of specification.

I think the discrimination of married vs unmarried women in name formatting is
now considered obsolete and perhaps even slightly offensive.

In any case, proper name formatting is not something related very strongly to
culture anymore, but to individual persons and the relationships among them. 
Locales are more or less country-based, so they are a poor way to select name
formatting rules.

Even telephone number formatting isn't as straightforward as it may seem.  In
Germany, there are three major ways of formatting phone numbers, and it seems
that de_DE.UTF-8 uses neither of them (it's difficult to tell because the
formatting codes are undocumented).

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #25 from keld at keldix dot com <keld at keldix dot com> ---
On Mon, Jun 23, 2014 at 07:44:34AM +0000, fweimer at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #24 from Florian Weimer <fweimer at redhat dot com> ---
> (In reply to keld@keldix.com from comment #21)
> > I think all of these examples can be covered with the existing LC_NAME spec.
> > And they were all known at the time of specification.
> 
> I think the discrimination of married vs unmarried women in name formatting is
> now considered obsolete and perhaps even slightly offensive.

Then you can make them the same (Ms).

> In any case, proper name formatting is not something related very strongly to
> culture anymore, but to individual persons and the relationships among them. 
> Locales are more or less country-based, so they are a poor way to select name
> formatting rules.

The locales are culturally oriented. I cannot speak for every culture, but 
proper name formatting still seems relevant in many cultures.
What we have is not perfect, but it can be used to provide more culturally 
acceptable results. But I think there is room for improvement, 
I invite such suggestions for improvement. Do you have any suggestions?

> Even telephone number formatting isn't as straightforward as it may seem.  In
> Germany, there are three major ways of formatting phone numbers, and it seems
> that de_DE.UTF-8 uses neither of them (it's difficult to tell because the
> formatting codes are undocumented).

The idea was at least to get rid of the USA way, which is not culturally
acceptable
in many countries. Then a number of ways would be kind of OK - in my country
there are also some common examples, and then there is an official
recommendation.

Best regards
keld

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

[Bug localedata/14641] Deprecate name_fmt

[myllynen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

Marko Myllynen <myllynen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |myllynen at redhat dot com

--- Comment #26 from Marko Myllynen <myllynen at redhat dot com> ---
(In reply to Florian Weimer from comment #24)
> 
> Even telephone number formatting isn't as straightforward as it may seem. 
> In Germany, there are three major ways of formatting phone numbers, and it
> seems that de_DE.UTF-8 uses neither of them (it's difficult to tell because
> the formatting codes are undocumented).

For documentation of the codes please see for example
http://www.open-std.org/JTC1/sc22/WG20/docs/n972-14652ft.pdf or
http://man7.org/linux/man-pages/man5/locale.5.html.

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #27 from keld at keldix dot com <keld at keldix dot com> ---
On Mon, Jun 23, 2014 at 01:02:24PM +0000, keld at keldix dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> 
> --- Comment #25 from keld at keldix dot com <keld at keldix dot com> ---
> On Mon, Jun 23, 2014 at 07:44:34AM +0000, fweimer at redhat dot com wrote:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=14641
> > 
> > --- Comment #24 from Florian Weimer <fweimer at redhat dot com> ---
> > (In reply to keld@keldix.com from comment #21)
> > > I think all of these examples can be covered with the existing LC_NAME spec.
> > > And they were all known at the time of specification.
> > 
> > I think the discrimination of married vs unmarried women in name formatting is
> > now considered obsolete and perhaps even slightly offensive.
> 
> Then you can make them the same (Ms).

One could actually introduce a new keyword for women unmarried+married.
This is a convention found in many cultures.

Best regards
keld

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

[Bug localedata/14641] Deprecate name_fmt

[bugdal at aerifal dot cx]

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.

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

[Bug localedata/14641] Deprecate name_fmt

[keld at keldix dot com]

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.

[Bug localedata/14641] Deprecate name_fmt

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14641

--- Comment #30 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to keld@keldix.com from comment #29)
> 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.

It's impossible to have apolitical locales.  We don't have one for Palestine as
far as I can see, and our data clearly takes sides in the disputes about
Macedonia and Taiwan (which is probably unavoidable one way or the other).

The lack of a way to encode royal and noble ranks in names could be considered
a political statement as well.

We should move this to libc-alpha if there is anything more to discuss, but it
seems unlikely we will reach agreement, so there is probably no point.

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