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

Bert Freudenberg bert at freudenbergs.de
Fri Oct 1 11:12:57 EDT 2010

On 01.10.2010, at 16:56, K. K. Subramaniam wrote:

> 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


- Bert -

More information about the etoys-dev mailing list