Re: [Bug localedata/14641] Deprecate name_fmt

[Keld Simonsen <keld@keldix.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