Well, that last comment reminded me of something:

I've read code written in english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did something that it didn't (and, of course, it was more difficult to realize why the code didn't behave like it was saying :P).
So... as writing everything in english can be a solution, it can be a big problem too :(

On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

Once upon a time I wondered if it wouldn't be possible to translate
the whole sources in any language (via a Dictionary).
In any other language, we ��(think of a child) must learn to "talk' to
computer in computer own language...
So an apprentice has to learn a new language anyway
Be it an english computer language is thus not that important.
However, one of the nice properties of Smalltalk is enabling "talking"
to the machine in a language close to our natural language, and that
lowers the barriers.
So the question of natural language naturally arises.

The translation could be performed statically (transforming a whole image)...
Or tools could as well perform the translation dynamically (using AST)...

In the former case, we must maintain dictionaries if we want to
continue sharing code with rest of the world.
In the later case, if user adds a method #foo that already has a
translation #bar, the effect might be surprising... (where the hell is
my method foo ?).
The problem is rather unlikely in English-Chinese conversions though ;)

Untill there is such universal translations available, I agree with Juan:
in long term, it's better/easier to use a single language wrt
uniformity/homogeneity.
I personnally started with franglishe, but tend to use English more and more...
...well, what I perceive as good English might hurt some ears ;).

Nicolas

2010/7/28 Alexandre Bergel <alexandre@bergel.eu>:

>> I'd even suggest the system to reject names and selectors not in ASCII.
>
> I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePr��f��r��e if he/she wishes. Every beginner do this...
>
> Cheers,
> Alexandre
>
>
>>
>> Cheers,
>> Juan Vuletich
>>
>> Alexandre Bergel wrote:
>>> I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important.
>>> Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 28 Jul 2010, at 21:33, empty wrote:
>>>
>>>
>>>> In 1.1 and 1.2, without setting a language environment for Chinese, I am able
>>>> to use Chinese by setting fonts. It seems to work except for accepting a
>>>> class named in Chinese will end in a ClassBuilder error of 'Class names must
>>>> be capitalized'. Well is it a feature(requires language environment being
>>>> set correctly) or bug?
>>>>
>>>> The code located being:
>>>>
>>>> validateClassName: aString
>>>> �� �� "Validate the new class name"
>>>>
>>>> �� �� aString isSymbol
>>>> �� �� �� �� �� �� ifFalse: [ ^ false ].
>>>> �� �� aString first canBeGlobalVarInitial ifFalse:[
>>>> �� �� �� �� �� �� self error: 'Class names must be capitalized'.
>>>> �� �� �� �� �� �� ^false].
>>>> �� �� environ at: aString ifPresent:[:old|
>>>> �� �� �� �� �� �� (old isKindOf: Behavior) ifFalse:[
>>>> �� �� �� �� �� �� �� �� �� �� self notify: aString asText allBold, �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� ��' already exists!\Proceed will store over it.' withCRs]].
>>>> �� �� ^ true
>>>>
>>>> and following the code the problemic method is #canBeGlobalVarInitial: which
>>>> is found in two classes:
>>>> in EncodedCharSet class side:
>>>> canBeGlobalVarInitial: char
>>>>
>>>> �� �� | leadingChar |
>>>> �� �� leadingChar := char leadingChar.
>>>>
>>>> �� �� leadingChar = 0 ifTrue: [^ self isUppercase: char].
>>>> �� �� ^ self isLetter: char.
>>>>
>>>> and in LanguageEnvironment
>>>>
>>>> canBeGlobalVarInitial: char
>>>>
>>>> �� �� ^ Unicode canBeGlobalVarInitial: char.
>>>>
>>>> I didn't set a Chinese environment and the exception is occured in in
>>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought
>>>> to be lowercased.
>>>>
>>>>
>>>>
>>>>
>>>> -----
>>>> ��������� ��������� ���������
>>>> --
>>>> View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p2305496.html
>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project@lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> ��------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00
>>>
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel ��http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project