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

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