Re: Collating bug with period?

[Danilo Segan <dsegan at gmx dot net>]

Hi Keld,

Today at 11:25, Keld JÃrn Simonsen wrote:

> What do yoy mean by "not scaling"? Glibc has a mechanism "reorder-after"
> that can build on an existing LC_COLLATE spec and then just reorder a
> few characters, like the PERIOD character. This functionality is also
> included in ISO 14651 and TR 14652.

I mean that you have to create a separate locale and do a "localedef".
In some circumstances this even involves setting of some environment
variables (if you're not privileged enough to write to /usr/lib/locale
or wherever). 

As I said, it only means changing a few weights, but you can't avoid
re-creating the entire locale for this simple change.  Imagine having
for each single locale another one named <locale>@filenamesort which
only does 'copy "<locale>"' everywhere, and adds a few reorder-after
rules (or any other).

That's how I got to "not scaling".  Provided this is really a feature, 
and not bloat (I'm not sure that it is a feature), we'd have an
orthogonal setting for this, instead of having to redefine all the
other locale stuff at the same time, and we could have both dictionary
and filename sorting at the same time (imagine having
LC_FILENAME_COLLATE; again, I'm not saying that this is what we need,
rather that GNU libc doesn't scale to provide asked-for functionality;
this is not a bad thing, GNU libc localedata doesn't scale either to
provide translations for all the country and language names either,
but we don't expect it to, so it's not a problem).

The core of my mail is the question: do we really need this kind of
scalability?

Cheers,
Danilo