Date: Fri, 06 Apr 2007 08:52:53 -0700 From: "Kevin Oberman" <oberman@es.net> To: Jean-Yves Lefort <jylefort@FreeBSD.org> Cc: gnome@freebsd.org, Michael Nottebrock <lofi@freebsd.org>, kde-freebsd@freebsd.kde.org, xors@mne.ru Subject: Re: [kde-freebsd] system:/media/cd0 and volume_label not latin symbols Message-ID: <20070406155253.197D945055@ptavv.es.net> In-Reply-To: Your message of "Fri, 06 Apr 2007 13:37:17 %2B0200." <20070406133717.fbc1f9f9.jylefort@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1175874773_76952P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1175874773_76952P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGFmzVkn3rs5h7N1ERAvVpAKCKsFUTNMFQUeXmYG7ks4SQEZHPxACgudAY QdFFiG+K4nIQfGLA6+BG4+A= =8pFi -----END PGP SIGNATURE----- --==_Exmh_1175874773_76952P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070406155253.197D945055>