On Tuesday 01 Feb 2011 3:40:10 pm Eric wrote:
> Thanks Subbu,
>> >This is because of input method conflict between supporting legacy codes
> > and modern UTF-8 input codes across multiple platforms.
> Don't very understand about the conflict you mentioned, could you give
> some example?
See the threads
http://lists.squeakland.org/pipermail/etoys-dev/2010-October/005933.htmlhttp://forum.world.st/New-Win32-VM-m17n-testers-needed-td63730.html
In a multilingual setting, the language of input codes can be different from
what is implied by the locale setting (system language). So one can encounter
Chinese input in a Latin-1 locale. The image has methods to switch locales
manually but not converters :-(. The logic for arriving at language+encoding
is different on different platforms. Part of this logic lies in VM and part of
it in the VM. VMs ports on Windows, Mac and Linux use different logic to deal
with multi-byte input methods, so the code in the image has to dance around
with VM host, locale setting and language codes to collect input.
If you are not likely to read files encoded in pre-Unicode Chinese codes and
you are just interested in getting Squeak to deal with Chinese input on Wintel
VM, just apply a patch to override all this logic for now. Hopefully, better
code will emerge as we get more feedback from Chinese users.
> >See SQ-554 and its discussion in etoys-dev for the background. You can
> > adapt the patch to make it work for your case (Squeak 4 on Windows?).
> Also for SQ-554, which defect report URL for this item? Do you mean the
> patch in etoys-dev?
Yes. In my patch, I tried to get UTF-8 encoding thru the VM into Squeak where
I could decode uniformly. It worked on Linux VM but not on Win32. I don't have
Win32 development machines around, so I couldn't take it further.
Subbu