i18n question.

Simo Sorce simo.sorce at xsec.it
Mon Mar 8 14:35:53 GMT 2004

On Mon, 2004-03-08 at 15:11, Benjamin Riefenstahl wrote:
> Hi Simo,
> Simo Sorce <simo.sorce at xsec.it> writes:
> > NO, that would mean you have 2 "internal charests" to deal with ...
> > Actually we make a rule that all constants are _only_ ASCII and you
> > can guarantee all charset you use are 100% ASCII compatible.
> On a slightly different level you are actually dealing with an
> unlimited number of encodings at the moment, and they are all in 8-bit
> and distinguished at runtime.  Two reliable ones (ASCII and UTF-16)
> with different static signatures (distinguished at compile time) and
> separate sets of functions/methods seems an improvement to me.

Ideally it may be, but before making such claims we should analyse the
details to see if that's really an improvement or not.

What's the problem in beeing charset agnostic (with some rules of
course) ?
I would really like to know where really is the problem we are trying to
fix with this proposal :-)

> > (you have 2 internal charsets then, that's a nightmare),
> :-( You folks have too many nightmares for my taste.

Truth is: the code is vast.
Changing the internals of such code is a _big_ operation, you can't do
that in a few days of hacking ... and all people dealing with the code
have to switch to a totally different way to deal with the code they do.
So there is a huge possibility for bugs to be introduced at the
conversion time, and lot of bugs to be introduced immediately after.
To me, that's a nightmare :-)

> Some people would think this would *enhance* the quality of the code
> immediately and could be an incentive to improve it even more.  But I
> realize that opinions can reasonably vary on that point, so this
> depends much on who is going to write and maintain the code.

I do not see where or why this should *enhance* the code, can you
explain this point?


Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Garofalo, 39 - 20133 - Milano
mobile: +39 329 328 7702
tel. +39 02 2953 4143 - fax: +39 02 700 442 399

More information about the samba-technical mailing list