Re: [PATCH] t9129: fix UTF-8 locale detection

[Yann Droneaud <yann@droneaud.fr>]

Le mardi 18 mai 2010 à 19:08 +0200, Yann Droneaud a écrit :
> Le mardi 18 mai 2010 à 18:05 +0200, Michael J Gruber a écrit :
> > Yann Droneaud venit, vidit, dixit 18.05.2010 16:41:
> > > Since I don't have en_US.utf8, some tests failed:
> 
> > > 
> > > On my system locale -a reports:
> > > 
> > >    en_US
> > >    en_US.ISO-8859-1
> > >    en_US.UTF-8
> > > 
> > 
> > locale -a|grep en_US
> > en_US
> > en_US.iso88591
> > en_US.iso885915
> > en_US.utf8
> > 
> > This is on Fedora 13, which is not exactly exotic. What is your system?
> > 
> 

I've checked carefully multiple system and configuration, and found why
we have some little locale problem here.

Since glibc 2.3, a file can hold all locales in file "locale-archive"
instead of having a tons of directory. To store all the locales in this
file, it uses an index based on a "normalized" codeset, e.g. it converts
codeset to lowercase, removes dash and minus. 
So when one ask for the locale list, locale first go through the
"locale-archive" content and report normalized codeset (utf8)  instead
of canonical codeset (UTF-8), then it proceed with the legacy locales
directories, using for them the canonical codeset.

Until recently, Mandriva Linux doesn't make use of "locale-archive", so
UTF-8 locales were reported. Version in development uses
"locale-archive" + legacy locale directories, hence the mix I've
reported. Other Linux distributions like Fedora and Ubuntu uses only
"locale-archive" and so, have only "normalized" codeset.
POSIX doesn't specify the output of locale -a, so it's not really a bug
to show "normalized" codeset name.

But all others "POSIX" system I've found report "canonical" codeset,
e.g. UTF-8 (all but latest cygwin). 

Here's the bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=11629

BTW, I will shortly provided a fix for the testcase, which will handle
all cases.

Regards.

-- 
Yann Droneaud