Jason,

> Stefan,

>> What about an additional property like
>> TransliterateToLocalCharset : boolean
>> that defaults to TRUE?

> I really much prefer to avoid making IBO the responsible party where
> transliteration is concerned. Initially I wanted to stay out or the
> transliteration business entirely.

> Currently the only transliteration I do is when the CharSet property
> is set to UTF-8 so it may be more appropriate to have a property
> that controls whether or not UTF-8 translitaration happens so that
> it is clear I prefer to stay out of it.

So that's what I proposed above: Have a boolean property that
simply determines if IBO does transliteration or not.

> But, now that it appears this business of doing some default
> transliteration is going to be required, what else am I up against?

You'll have to do it right. No compromises, or your non-USA customers
will have problems using IBO.

> I presume there are other character sets that the FBClient/GDS32
> client support that also will require some transliteration. Would
> someone more experienced with character sets give me their opinion
> on what default transliteration I should be doing?

None. Transliteration is built into the FbClient already. You already
have the Client Character Set property that determines what FbClient
shall deliver.

The problem is data bound controls: These also have a Character Set
property and that must match with the one that is used for the Client
connection. It has always been the responsibility of the developer to
ensure that it's matching.

E.g. when I use Windows-1252 for my controls (ANSI_CHARSET), I also
must use WIN1252 (or at least ISO8859_1) for the client character
set. But I as the developer had always have to care about that, not
IBO.

The whole concept of "local character set" becomes completely useless
when you have multi-language applications. (E.g. when you want to
process Czech on a German or American PC.)

> Perhaps if we step back and look at this from a bigger picture we can nail
> this down in such a way that it can be clearly documented and controlled.

So I'd like to repeat my suggestion:

Introduce a Boolean property in TIB_Connection that controls if there
is a Transliteration to the local character set by IBO or not. You
might restrict this to Unicode (UTF8, UNICODE_FSS), because
transliterating other character sets is non-trivial (you would need to
have many and large translation tables). So the property name could be
TransliterateUnicodeToLocal
or something along that line.

It would stay in the responsibility of the developer to take care of
the match between Client Character Set and the Character Set of the
controls. Those who want to have a UTF8 connection for some reason and
know they mostly use local character set controls set the property to
TRUE, those who want to make true multi-language apps, set it to
FALSE.

An "AsUtf8String" property could also be beneficial. But for this to
work with all character sets, you would need those translation tables
again ...


Best Regards

Stefan