[kde-freebsd] system:/media/cd0 and volume_label not latin symbols

Jean-Yves Lefort jylefort at FreeBSD.org
Fri Apr 6 11:37:24 UTC 2007


On Wed, 4 Apr 2007 12:58:29 +0200
Michael Nottebrock <lofi at 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 Lefort

jylefort at FreeBSD.org
http://lefort.be.eu.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20070406/af4ffa6f/attachment.pgp


More information about the freebsd-gnome mailing list