i18n question.

[Jeremy Allison]

On Tue, Mar 09, 2004 at 11:11:06PM +0200, Alexander Bokovoy wrote:
> On Wed, Mar 10, 2004 at 04:03:34AM +0900, TAKAHASHI Motonobu wrote:
> > |However, provided the CP932 mappings were "corrected" (e.g. using libiconv-1.9.1 pluglin) then
> > |the utility would correctly convert ??? to U+FFE0. Then you have Unicode on the wire
> > |(UCS-2LE/UTF-16LE), Unicode internally (UTF-8), and Unicode on Disk (UTF-8). So at least in
> > |this case there would be no mapping problems. It's only when you want to use a legacy encoding
> > |on disk for filenames that the internal string handling results in problems (e.g. 2nd byte
> > |ASCII violates one of The Sanity Rules).
> > 
> > Yes, so if we want to use Samba 3.0 with Japanese, first we should fix
> > (modify?) the conversion table of iconv(). Unfortunately only glibc
> > 2.3.3 or later, or patched GNU libiconv are satisfied with Samba 3.0.
> > 
> > This means currently I have to say "Samba 3.0 cannot work correctly in
> > Japanese environment for business use".
> Note that it is not a fault of Samba but rather iconv(3) long standing
> problem which bites every other application which utilizes it as well.
> Of course, we might add specific CP932 table as charset module to bypass
> relation on system iconv support and you are welcome to introduce it to
> Samba CVS HEAD.

This is a very good point. If you can't get it fixed in glibc iconv
at least we can fix it for you in Samba.

We definately want you to be able to say "Samba 3.0 works correctly in a
Japanese environment for business use".

Cheers,

Jeremy.