Le 28-févr.-05, à 13:47, Claudio Valderrama C. a écrit :

> Do I need to read between lines that you have an abstraction layer to
> handle
> French correctly?
>
> If so, do you recommend any app developer to reinvent the wheel to
> handle
> Cyrillic (Russian, Belarusian, Bulgarian, Czech, Lusatian/Sorbian what
> is
> it, German people?, Polish, Slovak, Serbian, Ukrainian), Romance aka
> Latin
> derivatives (Spanish, Portuguese, Catalan, French, Italian, Rumanian),
> West
> Germanic variations (German, Dutch, English, Frisian), Sinese
> variations
> (Burmese, Chinese, Thai, Tibetan), Altaic variations (Japanese, Korean,
> Mongolian, Tungusic, Turki) and the like in a single shot? And we are
> leaving Malayo-Polynesian (Malay, Indonesian, Balinese, Oceanic that
> in turn
> comprises AFAIK Fijan, Hawaiian, Maori, Tahitian and Helen can tell me
> if
> our Easter Island's language, Rapa Nui is Maori variation) and still
> alive
> South American languages (like Chilean-Argentinian Mapundungun) out of
> the
> equation.
> :-)
>
> Do you suggest that applications handle variable MBCS, Olivier?

Claudio, I think we're not talking the same thing here.
I'm not asking any application developer to re-invent anything.
Application developers will *never* ever be concerned by how the engine
processes and stores strings.
In my view, you will still define a column as ISO8859_1 or GB18030 if
you like or need to.
All of my talk relates to how will the engine process that internally
and store it.
If I the engine takes your 'whatever character set' string and I store
it let's say in utf-8, you won't mind and be concerned as long as I
return you that string in ISO8859_1 the next time you query me.

Collations and so are a complex thing.
Implementing them based on a rigid unique internal charset (the unicode
unique charset) is a bit easier.
Having a unique internal charset also has advantages when it comes the
time to try to transliterate from one charset to another.

--
Olivier Mascia