Mark Wai wrote:

At 07:43 PM 3/23/99 +0100, Joachim wrote:

...

However, there are serious problems.

First of all, it isn't much use to translate the standard classes. If Collection were translated to Ansammlung, then I won't be able to use any code that uses Collection objects, and you won't be able to use my code that says Ansammlung.

I disagreed. Not if your entire Smalltalk base classes are written in a *single* language.

What use is it to allow writing German code if the base classes are still in English? How do you reuse my (German) classes in your (Chinese) systems?

These are the questions that must be addressed.

I don't see why you would want to create a class (say OrderedCollection) in English, then create a >>add: method in Dutch, create another method >>addLast: in Chinese and create another method

...

...

removeFirst: in Russian.

Nor do I. I'm talking about mixed languages at the system level, not mixed languages within a class (which is easy to avoid).

...

This could be overcome by giving each class several names, one for each language. But such a list would never be complete, and you'll get into real trouble once several people start translating stuff independently of each other.

I don't know how I could best answer (I have too much to say for this one) you this but I don't see this as problem at all.

Now you're being unfair. I have no chance to answer here.

...

Third, there are characters that are different but look the same. This is particularly true for stuff in cyrillic scripts, such as Russian. A cyrillic a looks exactly as its latin equivalent, yet it has a different code. I just imagine Russians writing English code and accidentally dropping a cyrillic A in an otherwise latin identifier - the compiler will complain and nobody will be able to *see* the problem.

No problem. This could be resolved if the VM, compiler and various system classes support 2 bytes character encoding.

This does *not* resolve the problem. In fact Unicode (which *is* a 2-byte encoding if I'm not totally mistaken) creates the problem in the first place. It's like having the same A glyph both for code 65 and for 165; you'll never know whether the A you're looking at is the same as the code-165 A somewhere else.

...

In all, I think it's best to draw a distinction between source code (which has always been English, and should remain so) and display text (which should be translateable, so Unicode is an excellent idea *there*).

I respect your opinion but I think the total opposite. English has been, and will be the dominant force in programming level for any forseeable future, I have no problem with that. I just think that non-English programmers deserve a chance to express their programming ideas natively in a beautiful environment like Smalltalk.

I agree that they should be able to have that chance. But life isn't fair.

Pre-mature conclusion and always follow the given can only lead to missed opportunities to make this a better world.

I don't think my conclusions are premature. I have seen several tries at this one. Apple Computer translated the keywords of a scripting language, as did Microsoft. Both failed miserably; the experiment was cancelled almost instantly once it hit the street (i.e. within a year's notice). The problems were the same in both cases: 1) The effort required to translate any new code to all the languages in the world proved too great. (How far has your Chinese translation come? Are you prepared to keep translating for the rest of your life? Do you have a chance to keep up with the speed at which new software is appearing? Do you see all the volunteers required to translate Squeak into all the other languages? Translation requires an organized effort, to ensure at least a little consistency; it's drudgery to keep the terminology consistent; do you see the capable project leaders for each language? I don't. I have been a technical translator for three years, leading and doing several translation projects of various sizes. Believe me, there is nothing more boring (and thus error-prone) than translating heaps of technical stuff, be it source code or manuals. And in a community of volunteers, Boring = Will Not Be Done.) 2) Interoperability problems. Code written in the German dialect didn't run in the US, and vice versa. I foresee the same problem for Squeak.

Regards, Joachim