OpenEuphoria

1. international language support

• Posted by John McAdam <johnmcadam at clix.pt> Aug 15, 2001
• 457 views

I think that one thing that would help to popularize
euphoria would be international language support.
When I talk to people here about Euphoria - which
is pretty often - they are interested, but are put off
by the english. So would I be if I had to program in
german, say, or chinese or something. So I thought
that it might be a 'simple thing' to write a preprocessor
that would substitute the keywords, builtin commands,
and common library routines from one language to
another. A simple list something like:

{{"end","fim"},
{"include","incluir"},
{"to","ate"},
{"by","por"},
{"exit","sair"},
{"type","tipo"},
{"constant","constante"},
{"for","para"},
{"while","enquanto"}} etc.

This would allow a portuguese programmer to write
code in his native language. The preprocessor would
look for these words and substitute them for the english
equivalent then run the program.
The list could be an include file, that could be replaced
by any other language that you would care to. French
Russian, Arabic, Swahili, Malay. etc.
OK. The problem is the word 'simple'. Simple for some
but I'm not up to it. Does anybody else think this is a
good idea and does anybody want to tackle It? I've got
the translation/substitution list for Portuguese (one of the
top ten spoken languages in the world) if anybody would
like to try.
Or maybe its already been done and I just didn't find it,
in which case, inform me please.
JOHN

3. Re: international language support

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 15, 2001
• 442 views

5. Re: international language support

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 15, 2001
• 472 views

Hi Rolf,

>it really true that international language support
>is important for a programming language (PL) ?
>I never found a major PL written in an other
>language than English. 
>Could anyone give me examples of PLs (not IDE's)
>to be used in other
>languages than English?

Yes,  C  for personal computers ES system 
with Alpha-DOS supports Russian identificators,
but, for compatibiliti, has only latinic reserved
key words.

Now, imagine you write your program in Russian,
simply, yes ?

Now, imagine Russian schoolboy/girl writes
his/her program in English, hard, no ?

Regards,
Igor Kachan
kinz at peterlink.ru

7. Re: international language support

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 15, 2001
• 439 views

Hi John again:

> OK. The problem is the word 'simple'. Simple for some
> but I'm not up to it. Does anybody else think this is a
> good idea and does anybody want to tackle It? I've got
> the translation/substitution list for Portuguese (one of the
> top ten spoken languages in the world) if anybody would
> like to try.
> Or maybe its already been done and I just didn't find it,
> in which case, inform me please.
> JOHN

I have standard Eu editor ed.ex, which works in Russian
syntax. Only editor, not Eu, naturally.

See please, really this is a very simple thing.
Just compare your ed.ex and my red.ex
with DOS command fc to extract differencies.

You can get this package just now at

http://www.private.peterlink.ru/kinz/red_eu.zip

Regards,
Igor Kachan
kinz at peterlink.ru

9. Re: international language support

• Posted by rolf.schroeder at desy.de Aug 15, 2001
• 447 views

Hi all English understanding folks on this list!

If one likes English or not: one advantage of writing a PL (programming
language) only in English is the exchangeability worldwide, i.e., on
this mailing list! For beginners it seems to be an advantage (Igor
mentioned russian pupils), but the key words of a PL should never be
transcripted to other languages. I'm sure, (I know it from my children
from preschool times) children will easily keep the few English items
like 'for while do next if then else ...', much faster the adults.

Let me state it plain: I's nonsense (at least today) to transcribe a PL
into an other language, times of Babylon are gone at least for PLs!

Have a nice day, Rolf

11. Re: international language support

• Posted by brian_keene at yahoo.com Aug 16, 2001
• 460 views

Igor:
Since you've asked for opinions from the peanut gallery (the rest of
the group).  Here's mine.

Using a straight word substitution between languages won't work for the
following reasons:

1. You may be able to translate the keywords, but all error messages
   are still going to be in English.  So the user must still know
   English to develop the program.
2. Syntax translation is just the beginning.  Grammatical & linguistic
   translations must be done as well which can't be done with a simple
   table approach.
3. Many languages (chinese, korean, japanese, russian, etc.) need more
   than the 7 bit ASCII character set.  My understanding is that EU as
   well as most PL's (prog. Langs.) aren't designed to handle the 8 bit
   UNICODE standard as part of their language keywords.  Although a
   preprocessor if correctly written could handle this.  But this makes
   the preprocessor much more complex.
4. Then there's what was mentioned before about words in 1 language
   after being translated conflicting with other parts of the prog.

This subject was wrestled with many years ago in Bell Laboratories
by people I worked with (who were MUCH MUCH MUCH smarter then me) who
finally gave up this idea and decided to leave their C compilers in
English. Since even at that time (~1980) they felt that English was
becoming the universal language in computer programming.

In retrospect, this was very egotistical of them.  But I suspect it was
more of an excuse for them to get out of having to solve a problem they
couldn't se a solution for.

Just my 2 cents (my opinion)

Regards
Brian Keene

--- Igor Kachan <kinz at peterlink.ru> wrote:
> 
> Hi Rolf,
> 
> >Hi all English understanding folks on this list!
> 
> Why only "English understanding folks" for programming ?
> 
> <snip>
> >I'm sure, (I know it from my children
> >from preschool times) children will easily keep
> >the few English items like
> >'for while do next if then else ...',
> >much faster the adults.
> >Let me state it plain:
> >I's nonsense (at least today)
> >to transcribe a PL into an other language,
> >times of Babylon are gone at least for PLs!
> 
> Do you remember Babel's intention ?
> We have what we have now.
> We just live under times of Babylon now.
> 
> I understand your points very well, but I know excellent
> expert in the area of other science (non computer area)
> who is absolutely *dull* in foreign languages, but wants
> use computer and programming in his job very much.
> He is real END USER. EUPHORIA is his language.
> 
> There are about 360 persons in this list, why some
> of them don't write to us ? Think please.
> 
> Then, switching among different native languages
> for programming language doesn't require any
> translations or transcribeings (is it correct?),
> you just change one table to another.
> The inner *order* of key words in these tables is
> important, not sense of these words.
> Try red.ex for idea.
> 
> I think John is correct, and I like this idea
> of preprocessor, editor is ready.
> 
> Regards,
> Igor Kachan
> kinz at peterlink.ru
> 
> 
> 
> 
>

13. Re: international language support

• Posted by Irv Mullins <irvm at ellijay.com> Aug 16, 2001
• 461 views

On Thursday 16 August 2001 06:29, Igor Kachan wrote:

> I understand your points very well, but I know excellent
> expert in the area of other science (non computer area)
> who is absolutely *dull* in foreign languages, but wants
> use computer and programming in his job very much.
> He is real END USER. EUPHORIA is his language.

On the other hand, some people use APL, 
a language which not one single person in the whole 
world learned as a child.  There's also one written 
in Vulcan, if I'm not mistaken. 
Anyway, you may want to follow this thread on Slashdot:
http://www.slashdot.org/askslashdot/00/08/08/195240.shtml

Regards,
Irv

15. Re: international language support

• Posted by Irv Mullins <irvm at ellijay.com> Aug 16, 2001
• 447 views

On Thursday 16 August 2001 08:46, freeplay at mailandnews.com wrote:

> This is an easy one to do and has been done in many applications (a
> compiler is really just an application yes?).  UNIX has had NLS (Natural
> Language Support) for ages now.  The idea for program dialogue (prompts,
> error messages, report names, column titles etc.) is that you write message
> catalogues with all this information.  You write one for each language you
> want to support.  When the program runs it detects which language to run in
> (UNIX uses the LANG environment variable for this) and then consults the
> appropriate message catalogue.
>
> The programmer has more work to do (on top of writing the message
> catalogue) because they have to consult the message catalogue (through an
> API I guess) to get message text as opposed to hard coding it into printf
> statements and the like.  Issues such as message lengths differing from
> language to language have to be addressed.  It can get quite complex to say
> the least.

What about languages that read from right to left? 
Or from top to bottom? 
Doesn't that make parsing  er.. more interesting?

,sdrageR
i
r
v

17. Re: international language support

• Posted by Irv Mullins <irvm at ellijay.com> Aug 16, 2001
• 464 views

On Thursday 16 August 2001 11:14, freeplay at mailandnews.com wrote:

> Parsing isn't the issue with NLS.  NLS is a way to help you code an
> application once (single source) and have it run in as many different
> languages you have the time to translate a message catalogue into.  Not
> sure if it handles reading text right to left.  I guess you just put the
> message text in the catalog right to left.  The other biggie is character
> sets.

Parsing would be an issue if keywords were translatable.
If you look at any number of Linux programs which can run in multiple 
languages, you'll see that the source code still uses "English-ish" 
keywords. Lots of if ()  printf(), etc.

I think Logo has been translated into French. and Applescripts worked 
when written in French.

> I've never coded anything with NLS so I'm no expert.  I'd guess, however,
> that the format of a message catalogue has an "english" feel to it though

Pretty much  the same thing could be done in Euphoria with simple include 
files:
msg.en
msg1 = "File not found"
msg2 = "Cannot read file"

msg.es
msg1 = "Fichero no encontrado"
msg2 = "No puede leer el fichero"

(Apologies for the poor spanish)
Just include the desired msg.xx file for your language.
The advantage would be that anyone, not just a programmer, who can 
read one of the existing msg. files could easily translate that into a new 
msg. file in her native language, and your program would be usable.

One disadvantage might be extra work for the programmer, having 
to keep track of all the msg id's, and always using them instead of just 
typing the text in directly.  A pre-processor might be able to 
solve this, by scanning the finished code, extracting and creating a list of 
all the unique strings, saving that list to a msg. file, and then replacing 
those strings in the source with the msg1 .... msg2... etc. pointers.

Of course, this doesn't help much with the other problems, such as 
the translated string being much longer than the original, 
English => German, for instance. 

Regards,
Irv

19. Re: international language support

• Posted by Gerardo <gebrandariz at YAHOO.COM> Aug 16, 2001
• 451 views

Hi, everybody.

I've been following this thread with some interest. Many interesting
thoughts, nothing really new, basically the old conflict: should x be
translated or should I learn another language? Happens with books, movies
and clothes labels, not just with PLs.

I don't think there's just one clear solution. I believe most people will
feel comfortable with a dual system, as in keeping English-based syntax
along with translated docs (as long as they are well translated -you should
see some Spanish help files, and I do mean MS).

Now, there's a point that this far I haven't seen anybody make, and I feel
it's quite important. English as an almost requisite for programming is
pushing considerably towards the popularisation of an international
language. Never mind it's English, it might have been French, Spanish,
Russian or ..you name it. Never mind it comes along with programming.

The main fact is that we're all talking a common language, sharing ideas and
experience across every line you care to mention, just because we share a
language. This not only makes us comfortable and serves our needs, it's an
enormous intellectual and practical multiplier.

There's ample historical precedent. The huge scientific process that helped
lead Europe through the Middle Ages and the Renaissance would not have been
possible had not every person with intellectual pretensions been profficient
in the use of a common language, namely Latin.

We live in a small, troubled world. As Buckminster Fuller said, a spaceship
that came without the manual. We -the whole human species- are now in the
process, whether we are conscious of the fact or not, of writing that
manual. I'd say that a good grasp of a common language is step number zero
towards that end. English? So be it. Does an English-inspired PL help along
the way? My finger points upwards.

Not that the preprocessor idea is wrong in any way. There are many good
translations around, along with the bad and the ugly. Of books, movies, TV
series, documents of all kinds. If it helps someone to do a better job,
good. But if it gives someone the idea that it's not worth the trouble to
learn another language, seeing that the (translated) world is intent on
beating a path to your particular neck of the woods, then it's doing you and
everyone else a sad disservice.

By the way, here's an unintentional example of the complexity of the whole
thing:

----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, August 16, 2001 1:13 PM
Subject: Re: international language support


> Pretty much  the same thing could be done in Euphoria with simple include
> files:
> msg.en
> msg1 = "File not found"
> msg2 = "Cannot read file"
>
> msg.es
> msg1 = "Fichero no encontrado"
> msg2 = "No puede leer el fichero"
>
> (Apologies for the poor spanish)
>
> Regards,
> Irv

No apologies needed. Your Spanish is quite adequate, and your translation
would indeed have made the grade in any important commercial app. However,
therein lies a wolf in sheep's disguise. Your Spanish is truly Spanish, I
mean as in from Spain. Not every Spanish (language) speaker says 'fichero.'
That's actually a Gallicism, a literal translation from the French
'fichier'. Both fichier and fichero actually mean 'file cabinet', and so
would have been more appropriate as equivalences for the English 'archive'.

But that's water under the bridge. Half the Spanish-speaking world says
'fichero', the other half says 'archivo'. Each half understands the other,
the way Americans and Britons understand about lift and elevator, but it's
not their native way, not the way they speak or think. It can be almost like
another language. Literally. I'm from urban Argentina. I once underwent the
daunting experience of not understand two words out of three in what a
Mexican teenager was saying. Tired of speaking to the walls (as we say
here), he sighed and ...switched to English. Great buddies ever since.

Gerardo


>

21. Re: international language support

• Posted by Igor Kachan <kinz at peterlink.ru> Aug 27, 2001
• 450 views

Hi John,

> > The problem I was worried about - clashing keywords with
> > other people's variable names - doesn't really exist. If the
> > Foreign LAnguage PRogrammer (FLAPR) includes a file
> > that uses variable names that conflict with his version of the
> > keywords it won't be a problem because the preprocessor
> > doesn't translate the included file, just the current document.

I got your efl_edit.zip on the RDS site and attached
with your mail. Thank you very much !

It works for me well both with novo.ex in English
and novo.efl in Portuguese.

  

This is Euphoria Programming Language, no ?

(-: (-: (-:

10 days and such the job done !

Now just testing, debugging and improvements.

Thanks again!

Regards,
Igor Kachan
kinz at peterlink.ru