Collation implementation

[Shiv Shankar Ramakrishnan]

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

Maybe yes. But I last remember when I looked at some wchar_t and locale
related functions some were missing. (Very few though). Maybe I was
looking at the wrong place/thing. Where can I read more about the locale
system implementation of glibc wrt to the data file formats and what the
user can add etc? i.e. the locale back end stuff.

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

Solaris 8 is relatively new so how do you add all this to the old
Solaris 7 and 2.x installations? Moreover it is biased towards scripts
like Chinese/Korean/Japanese/Thai/Arabic with not much thought about
any of the scores of Indic scripts. But to their credit I'll say that
supporting Indic scripts is not easy or high priority for anyone. Only
win2k seems to do a decent job of trying to support Indic scripts.

|> 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++?

Not strictly. Only in the sense of a complete I18N framework/solution.
The user would use libsdtc++ for internal data manipulation but finally
he/she would need to display it. So it helps if that support is also
available in the some library externally and all the more better if
libstdc++ also used the same. And many system libraries don't have this
support. So does it really help that the user has to then on top use
another library? But this is my opinion only.

|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.

I think maybe we need to look at the universe that would benefit the
most number of users. I don't know what that would be though.

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

Whoops! That wasn't meant as an affront to you or anyone. I apologise
for any misunderstandings :) For all I know I don't consider myself also
very qualified with I18N.

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

Yes of course these could be used. Can someone enumerate the strengths
of these approaches? I mean I really can't claim to know a lot about
these. What are the areas in which they are better?

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

But it would be nice if the user could download them seperately and
and in some magical way plug it in with libstdc++ to take advantage of
it? The libstdc++ could then by default ship with either the system
stuff or with very few minimal locale data. But I don't want to close
out a way of taking advantage of it on systems with lesser I18N support.
Thanks,
Shiv