i18n question.

[TAKAHASHI Motonobu]

abartlet wrote:
>> My point is that even if Samba can  support all Japanese scripts with
>> UTF-8, we cannot migrate to UTF-8 soon because of lots of legacy
>> application and systems that can recognize only legacy charsets.
>
>OK, so it is the unix application problem (aka 'I have to fix all my NFS
>clients too').

// ... and have to fix all systems which communicate with the unix
// application.

>I have *no problem* with Samba supporting other character sets, that fit
>in tridge's rules, and it looks like jra has the special cases required
>in hand.

OK, this means same as 

|(1) Samba should fully support several unix charsets (such as CP932
|  and EUC-JP) for the present.


>I still strongly advocate the use of UTF8 as the single character for
>future systems.  

I agree, but also have to say "it's difficult".

>However this all got lost in the noise about 'unicode is not enough',
>'we should use USC4 for our internal interfaces', 'have a different
>FS character set'....

For Samba, I agreed 'unicode' and 'UCS-4' matter.

- We can say 'unicode is not enough' to support ALL Japanese
  characters (at least 60000 or more), but to support ALL Japanese
  characters used on Windows, Unicode can support them.

- We can use UCS-4 for internal charset, but is not good, I think.

- Currently if we need different FS charset, we can make a new VFS
  modules like as CAP.so and HEX.so. 
  We will create FS charset instead of VFS modules.

  I think currently to solve the issue, creating new VFS modules is
  acceptable.

-----
TAKAHASHI, Motonobu (monyo)                    monyo at home.monyo.com
                                               http://www.monyo.com/