[etoys-dev] Updated: (SQ-554) Etoys does not work with Chinese input
K. K. Subramaniam
kksubbu.ml at gmail.com
Fri Oct 1 10:56:23 EDT 2010
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.
> 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
> 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.
More information about the etoys-dev