On Tuesday 16 April 2002 12:26, Cees de Groot wrote:
> Making Squeak multi-lingual has been discussed before. There are
> two levels - making apps multi-lingual is relatively easy, look at
> EToys. However, making Squeak multi-lingual would probably mean
> wrapping every Smalltalk method selector with a localized
> representation.

That would be trivial to do with my "multisymbols" idea. Most other 
strings would also have to be handled somehow and that would be harder. 
The symbols and strings in the final 3.0 image take up almost 2MB and 
the image would become that much larger for each language added. 
Modules would be a good way around this problem, though the current 
scheme couldn't handle this.

> However, I don't think this is a precondition for educational use:
> EToys and the other authoring tools need to be in Dutch, but the
> "lower levels" can stay in English. The lower levels are for advanced
> usage, where users (kids, adults) have already grasped quite a bit
> about programming so the extra burden to switch to English is eased a
> bit. Learning English is a bit of a precondition for using computers
> anyway, there are worse ways to expose kids to English than teaching
> them the English names of Smalltalk method selectors (probably we're
> making this more of a problem than they'll ever have with it - at
> least in the Netherlands kids are exposed to the language all day so
> they're not likely to be alienated by it).

In Brazil only a subset of rich high school (and up) kids know enough 
English to be able to use Squeak. In the early 1980s not many people 
used computers without knowing English, but now most users speak only 
Portuguese.

> On a more philosophical level, it's a matter of balancing the extra
> burden of English-named method selectors against the advantages of
> the lingua franca that the current standard naming scheme (English
> names) is for code exchange. Localized names would seriously sit in
> the way of code sharing...

Multisymbols (just an object where a set of strings map to it via 
#intern: and which can reply one of the same set of strings, based on 
some global preference setting, via #asString or #storeOn:) allow code 
exchange between users with different native languages. Names for user 
defined symbols would be a problem, but they already are today.

-- Jecel