[etoys-dev] Updated: (SQ-554) Etoys does not work with Chinese input

[K. K. Subramaniam]

On Friday 01 Oct 2010 6:45:48 pm Bert Freudenberg wrote:
> No, I don't think that's a good idea. There is already #charCode and
> #asUnicode and #asInteger. Overriding #value is bad.
That's true.
 
> Senders should be fixed to use the correct one. Besides, ASCII is only a 7
> bit code anyway so should raise an error if > 127, in the strictest sense.
> I'd just leave it like it is for now. So any sender of #asciiValue should
> be removed and replaced with the appropriate method call.
‌There are about 163 senders just in Etoys image and some of them are quite 
valid (i.e. they do apply for lang=0,value<128 case. 
HandMorph>>generateKeyboardEvent is not one of them, so ‌I ‌go ahead fix these 
places.

> This needs to be fixed it in Squeak, too. When we port Etoys to the
> squeak.org version, we could pick it up from there.
Yes. the issue is common but the fix is non-trivial. Latin1 languages can have 
either UTF32InputInterpreter or UTF8InputInterpreter depending on the codeset 
being used. LocalePlugin has to be extended to return codeset (nil, UTF-8, 
...) and modifier on Unix.

For solving the current issue, I will patch the immediate asciiValue misuse 
and create a changeset for UTF8Environment that should cover most of the 
multilingual issues for non-Latin languages. For en, ‌I will add a m17n 
preference that will switch between classic codesets and UTF-8 codeset.

Subbu