This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug localedata/14641] Deprecate name_fmt


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]