On Fri, 06 Apr 2007 08:52:53 -0700
"Kevin Oberman" <oberman@es.net> wrote:
> > Date: Fri, 6 Apr 2007 13:37:17 +0200
> > From: Jean-Yves Lefort <jylefort@FreeBSD.org>
> > Sender: owner-freebsd-gnome@freebsd.org
> >
> > --Signature=_Fri__6_Apr_2007_13_37_17_+0200_OapU1fZfsGyEc4EJ
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Disposition: inline
> > Content-Transfer-Encoding: 7bit
> >
> > On Wed, 4 Apr 2007 12:58:29 +0200
> > Michael Nottebrock <lofi@freebsd.org> wrote:
> >
> > > On Wednesday, 4. April 2007, Jean-Yves Lefort wrote:
> > >
> > > > > So I see several solutions:
> > > > > 1. By default submit to HAL user's locale encoded mount point name.
> > > >
> > > > This is not possible. All hal data must be encoded in UTF-8.
> > > >
> > > > > 2. Modify mount point naming scheme to something which is not
> > > > > dependant on locale encoding, for example, to device name.
> > > >
> > > > I'd rather not make this the default behaviour. The volume label is
> > > > much more informative than the device name and should cause no
> > > > problems for most users.
> > > >
> > > > > 3. Change user's locale to UTF8.
> > > >
> > > > This is the recommended solution. UTF-8 is now universally supported
> > > > and I see no reason to stick to a legacy encoding.
> > >
> > > Universally supported except in FreeBSD. :( I'm not aware of any substantial
> > > work on UTF-8 since it was imported, which would mean that there's still no
> > > collation support.
> > >
> > > If even some Linux distributions despite their vastly superior UTF-8 support
> > > apparently do it, I think solution 2 should at least be offered via OPTIONS
> > > right in the port - installing an alternative ruleset wouldn't be too
> > > difficult to implement.
> >
> > What would be difficult (or impossible) would be to provide a
> > satisfactory explanation of the option using the small number of
> > characters available.
> >
> > You're right that the FreeBSD libc lacks Unicode collation support,
> > but it seems that no gain is made by sticking to a legacy locale:
> >
> > $ touch A B a b
> > $ export LANG=en_US.UTF-8; ls
> > A B a b
> > $ export LANG=en_US.ISO8859-1; ls
> > A B a b
> >
> > As you can see, the files are incorrectly sorted with both locales. On
> > a Linux box, the sort order is correct (a A b B) in both cases.
> >
> > If someone can convince me that there are good reasons to use a legacy
> > locale, I might add the option despite the fact that its description
> > would be cryptic.
> >
> Jean-Yves,
>
> I guess the term "correct" is unclear as for en_US languages. The order
> should be either "A a B b" or "A B a b". The answer you see is the one
> most commonly used on computers, (A B a b). It is also the one
> used by the default LANG=C.
>
> What you call the correct order is not normal collation sequencing in
> the US and that is the country that these languages are supposed to
> support.
http://www.bartleby.com/61/s1.html
--
Jean-Yves Lefort
jylefort@FreeBSD.org
http://lefort.be.eu.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFGFoqqyzD7UaO4AGoRAn6TAJ47Jg82Z7PGN6ghfQTaaz9KtzzgqACfa/U+
T2eGbrtasC0BzTk6tZF6ffA=
=InNL
-----END PGP SIGNATURE-----