Collation implementation

[Martin v. Loewis]

> You see unlike the other I18N libs that are floating around this is
> the only one that has a complete back end locale support without
> depending an iota on the system facilities and has support for more
> locales/countries/languages than most of the commercial OS'es with
> the exception of maybe win2k.

You see this is not true. The glibc locale implementation has all the
same properties.

> Which commercial *NIX for example supports more than a couple of
> dozen locales?

Solaris 8?

> Which of those in turn support complex text and layout like Arabic?
> Which of them support bi-directtional text?

How is this relevant to libstdc++?

> I18N is much more complex than people think and IBM did a very
> admirable thing in releasing ICU.

I don't question that statement; it may be a perfect solution in
another universe. For the universe I live in, it seems to have a
number of problems.

> Please do read a bit about I18N and take a look at ICU before
> anything else.

I've read a bit about I18N years ago, and I looked at ICU just
yesterday. Am I now qualified to respond?

> And if ppl still want to ignore it then may I ask what other option
> do we really have that does all that?

To me, the reasonable options are:
- use the glibc's __newlocale stuff
- use Matt Austern's system integration library

Shipping a locale database with libstdc++ is not very attractive, IMO.

Regards,
Martin