Native language versions

[Ian]

Has anyone tried translating the command set of Perl into other
languages (French, Japanese, Arabic etc.), so that native speakers do
not need to learn any English in order to program, then writing a
suitable compiler?

 

[Josef Moellers]

Has anyone tried translating the command set of Perl into other
languages (French, Japanese, Arabic etc.), so that native speakers do
not need to learn any English in order to program, then writing a
suitable compiler?

... and loose the possibility to use CPAN modules?

 

[Guest]

: Has anyone tried translating the command set of Perl into other
: languages (French, Japanese, Arabic etc.), so that native speakers do
: not need to learn any English in order to program, then writing a
: suitable compiler?

Many years ago I as in Japan for the first time and had access to a
computer. At that time, computers still came with built-in ROM with
BASIC, which I could try after starting the machine. I was astonished
and disappointed to see that print statements still were named print,
and not insatsu (in whichever writing system that would be rendered
doesn't really matter). Naively, I asked myself why the advanced
technology of Japan had not brought forth a computer that would natively
"work in Japanese".

Years and many languages later I understood that such an endeavour is
of little meaning. Any given language consists of more than words, there
is also grammar. While you could replace "print" by "insatsu", you
would also have to transform

print $calar;

into

$calar wo insatsu;

("wo" being grammatical glue).

suddenly you go from PO to OP (predicate-object to object-predicate).
Your complete stack mechanism gets upset, ending up with a language
like Forth or PostScript. Japanese is a bit like RPN for calculators.

Saying

insatsu $calar;

would be completely ungrammatical, hence incomprehensible, in Japanese.

Things get worse if you talk about conditionals.

if ($a eq $b) {do something}

would become

($a,$b to ha onaji).dattara {katsudou}

since the condition in Japanese is expressed as a verb form, not as
a particle.

Worse with Arab which modifies the vowel structure of a consonantal skeleton
in order to arrive at new meanings.

No, this approach is completely impractical and not even of any academic
interest. You cannot learn French while, for the sake of making things
easy, maintain that you replace the French words by English. On y va -
let's go? How will you transform that?

The German-, French-, ... ized versions of MS Excel macro language and
friends show how utterly useless the approach is. You gain ease of talking
while loosing your complete audience. What a trade-off.

Oliver.

 

[Anno Siegel]

Has anyone tried translating the command set of Perl into other
languages (French, Japanese, Arabic etc.), so that native speakers do
not need to learn any English in order to program, then writing a
suitable compiler?

The meaning of computer language keywords and their meaning
in a natural language have little to do with one another.
Knowing what "print" means in English desn't help you any
when it comes to its usage in a Perl context. So, even if
your approach were feasible, the benefit would be small.
The hard part to learn about computer language components
is their interaction, not their individual meaning.

Anno

 

[Tad McClellan]

Has anyone tried translating the command set of Perl into other
languages (French, Japanese, Arabic etc.)

How do you say "grep" in French or Japanese?

 

[Guest]

: > Has anyone tried translating the command set of Perl into other
: > languages (French, Japanese, Arabic etc.)


: How do you say "grep" in French or Japanese?


grep in French could be ierg (imprimer expression rationelle globale), while
in Japanese I'd expect shdi (seikihyougen wo dokodemo insatsu suru), but more
idiomatical would be gureppu, of course.

scnr,

Oliver.

 

[Ted Zlatanov]

Has anyone tried translating the command set of Perl into other
languages (French, Japanese, Arabic etc.), so that native speakers do
not need to learn any English in order to program, then writing a
suitable compiler?

I don't think the former would engender the latter. In particular,
you'd need to translate and correct all the documentation
appropriately for that language, and all your programs would require
that special version of Perl. I don't think the effort is worth the
loss of compatibility, considering the incremental effort of learning
a few keywords is negligible compared to learning Perl as a language.

Ted

 

[Peter J. Holzer]

: Has anyone tried translating the command set of Perl into other
: languages (French, Japanese, Arabic etc.), so that native speakers do
: not need to learn any English in order to program, then writing a
: suitable compiler?

In perl you don't need a separate compiler for that: You can write a
filter module. See Lingua::Romana:erligata for a filter module which
implements Latin syntax (including declensions and
position-independence) for Perl.

Many years ago I as in Japan for the first time and had access to a
computer. At that time, computers still came with built-in ROM with
BASIC, which I could try after starting the machine. I was astonished
and disappointed to see that print statements still were named print,
and not insatsu (in whichever writing system that would be rendered
doesn't really matter). Naively, I asked myself why the advanced
technology of Japan had not brought forth a computer that would natively
"work in Japanese".

Years and many languages later I understood that such an endeavour is
of little meaning. Any given language consists of more than words, there
is also grammar. While you could replace "print" by "insatsu", you
would also have to transform

[examples where Japanese grammar differs from English grammar]

Worse with Arab which modifies the vowel structure of a consonantal skeleton
in order to arrive at new meanings.

No, this approach is completely impractical and not even of any academic
interest.

I don't think this would be impractical at all. I don't know Japanese or
Arabic, but I don't think parsing a computer language based on Japanese
or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
is quite hard - "only perl can parse Perl" as the saying goes). At least
your examples don't look hard to me.

The German-, French-, ... ized versions of MS Excel macro language and
friends show how utterly useless the approach is. You gain ease of talking
while loosing your complete audience. What a trade-off.

There are probably a lot more people who program Excel than any other
programming language. There are of course other factors which make Excel
attractive to non-programmers (not least that it doesn't *look* like a
programming language), but I wonder whether translating the function
names doesn't contribute to its popularity. There is a surprising number
of people who don't understand basic English (even though they learned
it in school).

To you and me and other members of the Open Source community who are
used to sharing our programs with other people all over the world, the
mere thought of a localized programming language is a nightmare
(debugging a program with Portuguese comments in it is hard enough, at
least you understand the code), but there are people who don't speak
English and who want to write programs only for themselves and their
colleagues and friends. (and BTW, if you do it right, you can make such
programs translatable - unlike human languages, the semantics of a
programming language is known)

hp

 

[Peter J. Holzer]

... and loose the possibility to use CPAN modules?

If you do it via a source filter (like Lingua::Romana:erligata) you
don't lose the CPAN modules. What you may lose is some of the usefulness
of the documentation that comes with those modules since the examples
may not work if you change for example the way functions are called or
assignments are done. So you need somebody to translate the docs. But if
you aim at programmers who don't speak English, you need to translate
the docs anyway.

hp

 

[Guest]

: > : Has anyone tried translating the command set of Perl into other
: > : languages (French, Japanese, Arabic etc.), so that native speakers do
: > : not need to learn any English in order to program, then writing a
: > : suitable compiler?

: In perl you don't need a separate compiler for that: You can write a
: filter module. See Lingua::Romana:erligata for a filter module which
: implements Latin syntax (including declensions and
: position-independence) for Perl.

Which is a nice thing to have, but have we ever heard that the Vatican
uses this module extensively?

: > No, this approach is completely impractical and not even of any academic
: > interest.

: I don't think this would be impractical at all. I don't know Japanese or
: Arabic, but I don't think parsing a computer language based on Japanese
: or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
: is quite hard - "only perl can parse Perl" as the saying goes). At least
: your examples don't look hard to me.

No, that's right. You _can_ do it, but is it practical? Is it still Perl?
I wonder how to maintain a claim that two languages are equal (perhaps
better: equivalent) if both their grammars and lexica differ substantially?

: There are probably a lot more people who program Excel than any other
: programming language. There are of course other factors which make Excel
: attractive to non-programmers (not least that it doesn't *look* like a
: programming language), but I wonder whether translating the function
: names doesn't contribute to its popularity. There is a surprising number
: of people who don't understand basic English (even though they learned
: it in school).

While I stay with you that this feature may have contributed to the popularity
of Excel, I've seen a number of cases where a file with scripts written in the
German version wouldn't execute on the English version Excel. This was quite
a few years ago, though, maybe things have changed.

Oliver.

 

[Tad McClellan]

: > Has anyone tried translating the command set of Perl into other
: > languages (French, Japanese, Arabic etc.)


: How do you say "grep" in French or Japanese?


grep in French could be ierg (imprimer expression rationelle globale), while
in Japanese I'd expect shdi (seikihyougen wo dokodemo insatsu suru), but more
idiomatical would be gureppu, of course.

scnr,

That was fun.

I suppose we'd need some character other than "m" for m// then too?

 

[Guest]

: I suppose we'd need some character other than "m" for m// then too?

Most certainly. I suggest //i for m// (i as in itchi, to be matching).
Note that the object predicate order is typical of Japanese. In contrast,
the //i modifier of Perl (an attribute, that is), should be rendered
in Japanese as m// (for m as in mushi, to ignore).

Oliver.

 

[Ted Zlatanov]

Most certainly. I suggest //i for m// (i as in itchi, to be matching).
Note that the object predicate order is typical of Japanese. In contrast,
the //i modifier of Perl (an attribute, that is), should be rendered
in Japanese as m// (for m as in mushi, to ignore).

Why stop there? Just write the operators in Unicode

Ted

 

[Peter J. Holzer]

: > : Has anyone tried translating the command set of Perl into other
: > : languages (French, Japanese, Arabic etc.), so that native speakers do
: > : not need to learn any English in order to program, then writing a
: > : suitable compiler?

: In perl you don't need a separate compiler for that: You can write a
: filter module. See Lingua::Romana:erligata for a filter module which
: implements Latin syntax (including declensions and
: position-independence) for Perl.

Which is a nice thing to have, but have we ever heard that the Vatican
uses this module extensively?

No, I don't think so. It's an interesting case study, but of little
practical value. Latin is a dead language - nobody speaks it as their
first language, and the set of people who do speak it, are interested in
programming and don't speak even a little bit English is probably very
small. Conway probably chose Latin because its syntax is so different
from most current programming languages. If you can implement a
programming language based on Latin, you can probably implement one
based on any living language, too.

: > No, this approach is completely impractical and not even of any academic
: > interest.

: I don't think this would be impractical at all. I don't know Japanese or
: Arabic, but I don't think parsing a computer language based on Japanese
: or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
: is quite hard - "only perl can parse Perl" as the saying goes). At least
: your examples don't look hard to me.

No, that's right. You _can_ do it, but is it practical?

I think I misunderstood you when you wrote "impractical". I thought you
meant that it is extremely difficult to do. But it seems you only meant
that the result would be of little practical use.

So about the practical use:

For a general purpose programming language: Probably not. "Real
programmers" value the ability to share their programs all over the
world too much. Maybe China will have supplanted the USA as the leading
superpower in 50 years and we will all learn Chinese and create new
programming languages based on Chinese grammar (which AFAIK is
positional, too) and writing. But not now.

For embedded languages in applications or as shell/command languages:
I think so. More and more people use computers which don't have an IT
background. They want their computer to talk to them in their native
tongue and they want to talk *to* their computer in their native tongue.
English-based programming languages are an additional hurdle which keeps
these people from programming - the other hurdle are GUIs. I started
using computers around 1983. At that time, most of the documentation was
English, the normal user interface was a command line interface which
consisted of vaguely English words ("ls" isn't English, but it is easy
to memorize as shorthand for "list") and the command line language
(whether that was Basic on home computers, command.com's language on DOS
or shell) also served as a script language. Programming was natural.
Now people have GUIs, but programming languages are textual (yes, you
can "record macros", but is that programming?). That's a major gap to
cross. Their applications are all in their native language, but
programming languages are based on English: That's another major gap. I
think it is necessary to close both gaps so that ordinary users get back
where they were 20 years ago: Where they can "teach" the computer to
things, so that they don't have to do them themselves.

Is it still Perl?

No. Definitely not. It is a different language which can be translated
into perl and can use Perl modules.

: There are probably a lot more people who program Excel than any other
: programming language. There are of course other factors which make Excel
: attractive to non-programmers (not least that it doesn't *look* like a
: programming language), but I wonder whether translating the function
: names doesn't contribute to its popularity. There is a surprising number
: of people who don't understand basic English (even though they learned
: it in school).

While I stay with you that this feature may have contributed to the popularity
of Excel, I've seen a number of cases where a file with scripts written in the
German version wouldn't execute on the English version Excel. This was quite
a few years ago, though, maybe things have changed.

I think that's still the case (but I don't know: I don't use Excel) and
it is sometimes a problem. However the majority of Excel users doesn't
care as they don't share their spreadsheets with people who speak
different languages.

hp

 

[Guest]

: So about the practical use:

: For a general purpose programming language: Probably not. "Real
: programmers" value the ability to share their programs all over the
: world too much. Maybe China will have supplanted the USA as the leading
: superpower in 50 years and we will all learn Chinese and create new
: programming languages based on Chinese grammar (which AFAIK is
: positional, too) and writing. But not now.

For sure this will happen. Even though this is not Perl, but TeX, I know
of one case in Mongolia where a Mongolian computer scientist implemented
a package with Mongolian commands, instead of the English commands (TeX
is macro-based, and it is not a big problem to compile a huge list of
aliases to the existing macros).

: > Is it still Perl?

: No. Definitely not. It is a different language which can be translated
: into perl and can use Perl modules.

Well, I am not at all against writing modules which can replace (or enrich)
"native" Perl commands, statements and structures with English names by
any other given language. A bit further into the still dawning age of Unicode,
and everything can be expressed with non-ASCII characters. Not that Perl
is the restricting factor, but the constraints are usually in the users'
platforms.

I still have my doubts that it will help to lead people back to the joy
of programming even a simple script. You cited the age of CLIs and built-
in Basic, command shells etc. This age will not really return to the average
computer user any more. Computers tend to become more and more taken for
granted, omnipresent and powerful, to a degree that they start vanishing
from public perception, just like electry which is delivered from wall
outlets, not power plants, etc. Who still realizes that a digital camera,
a mobile phone, the cash register at the local market or the ignition control
system of your car happen to be powerful computers with specialized purposes
and interfaces?

That leads me back to Perl. The true hurdle lies not in the choice of
English of French or Japanese words for things like "print" or "while".
These can be replaced easily. Judging by an overwhelming number of postings,
we see fundamental conceptual errors as the source of various posters'
problems. Take anything like

$line_1="first line";
$line_2="second line";
$line_3=...

combined with the question "How can I construct a variable name from a
variable?"

where everybody can see that the answer would be an array. Or someone
puts $element=@elements and wonders why @elements=('a','b','c')
always becomes "3" in $element, instead of "abc".

This newsgroup is full of initial postings based on conceptual errors, and
astonishingly enough, these conceptual errors can occur even in the code
of contributors who otherwise seem to be quite fluent in fairly idiomatic
Perl. I do not think that the ratio of conceptual misunderstandings will
really decrease with localized programming code wordings.

This is why I question the practicality of just translating the keywords
of a language like Perl. First of all, the documentation needs a good,
thorough and complete translation, then you still can translate keywords,
but when you come to concepts, structures and symbols, there is not much
to translate. You have to learn them. Is the average native English (be she
British, American or Asian-Pacific (Australia and Hong Kong come to my mind))
programmer statistically less error-prone and more successful as a programmer
just because she seemingly doesn't have to learn the keywords?

The module providing English names to Perl's built-in variables ($_, $/,
$., etc.) can be complemented by a module providing German, Japanese, Chinese
and other names. This is helpful indeed, but users still have to read and
understand from documentation and general computer science knowledge how
to manipulate these symbols, and how to manipulate their data by them.
It doesn't really help if a German user has difficulties applying a $/
if the concept of an $INPUT_RECORD_SEPARATOR is not well understood, notably
if the first occurrence in perlvar.pod says "# enable localized slurp mode".
It doesn't even use concepts like EOL, record separators etc. Just imagine
a young Chinese, Japanese or even German computer science student trying
to understand what "slurp" means in the context of reading from a file handle,
while the first reference in the Oxford English dictionary is:
eat or drink (something) with a loud sloppy sucking noise:
she slurped her coffee | [ intrans. ] he slurped noisily
from a wine cup.

The first thing the definition mentions is the noise of the action, not the
"whole cup of coffee in one scoop" concept.

Perl is not Java! And here, English-speaking computer scientists and Perl
programmers do have an unfair advantage over speakers of different tongues,
all the more in cultural backgrounds which allow the peaceful coexistence
of humour, wit and irony with absolutely serious business. Not all
cultures do appreciate this ambiguity which may be highly irritating in
Japan, Egypt, India or many other places.

To make a long story short: Language is more than lexicon and grammar.
Replacing the lexicon by close approximates of the lexicon is only partially
helpful. It is the documentation which needs a careful translation first.

Perhaps after porting Perl to so many platforms, we should start porting
the Perl documentation to more languages besides English. CPAN would gain
a huge advantage from such an effort, as would the global Perl community.

If a good framework is established, then any hint to e.g. perlreftut will
still point to the intended information, regardless of the language in which
the documentation is perused.

Sorry for the lack of conciseness.

Oliver.

 

[Peter J. Holzer]

: > Is it still Perl?

: No. Definitely not. It is a different language which can be translated
: into perl and can use Perl modules.

Well, I am not at all against writing modules which can replace (or enrich)
"native" Perl commands, statements and structures with English names by
any other given language. A bit further into the still dawning age of Unicode,
and everything can be expressed with non-ASCII characters. Not that Perl
is the restricting factor, but the constraints are usually in the users'
platforms.

I still have my doubts that it will help to lead people back to the joy
of programming even a simple script. You cited the age of CLIs and built-
in Basic, command shells etc. This age will not really return to the average
computer user any more.

And that's a good thing. I'm not pining for the "good old days". But I
think that current GUIs (which haven't changed all that much since XEROX
invented the mouse in the 1970s) aren't optimal either. I see all the
time people doing repetitive tasks, for which on Linux I would write a
five line shell script and be done with it. And I ask myself how the GUI
user could be enabled to write that script. Or let's formulate this in a
more general way: How can the user tell the computer: "I'm doing that
stuff every week. Do it for me!"? The "language" doesn't even have to be
written, it might be graphical, or a mixture. I agree that I'm getting
away quite a bit from the OP's notion of just translating perl keywords
.

Computers tend to become more and more taken for granted, omnipresent
and powerful, to a degree that they start vanishing from public
perception, just like electry which is delivered from wall outlets,
not power plants, etc. Who still realizes that a digital camera, a
mobile phone, the cash register at the local market or the ignition
control system of your car happen to be powerful computers with
specialized purposes and interfaces?

I'd like to have perl (or any other sane scripting language) installed
on my Nokia Communicator.

There's probably not much use for a user-accessible programming language
on a cash register. The cashier isn't supposed to reprogram the register -
the presence of such a language would probably be considered a security
risk. Neither do I see the need on a camera or a washing machine (but a
network-accessible command/status interface would be useful for both). A
modern mobile phone OTOH is almost a general purpose computer. There are
a few things for which it is unsuitable due to its small size, but apart
from that there isn't much difference to a desktop PC (and it's
certainly more powerful than the first computers I used were).

That leads me back to Perl. The true hurdle lies not in the choice of
English of French or Japanese words for things like "print" or "while".
These can be replaced easily. Judging by an overwhelming number of postings,
we see fundamental conceptual errors as the source of various posters'
problems.

Right. Actually, it goes deeper. Some people have problems with the
concept of a loop, or a variable. These people will probably never be
able to write a program of any complexity, but even those can compose a
linear list of "things to be done". Another reason why I see the value
of translating programming languages more in embedded languages than in
general purpose programming languages. A program without variables or
loops seems strange to us. But it may replace 20 mouse clicks and
filling in of 3 text fields with a single click, so it is useful for the
user.

This is why I question the practicality of just translating the keywords
of a language like Perl.

As I said, I wasn't talking about translating just the keywords. I
specifically mentioned Lingua::Romana:erligata because it changes both
the words and the grammar. And I tried to steer the topic away from
general purpose programming languages to specific applications, because
there I see value in localized programming languages.

First of all, the documentation needs a good,
thorough and complete translation, then you still can translate keywords,
but when you come to concepts, structures and symbols, there is not much
to translate. You have to learn them. Is the average native English (be she
British, American or Asian-Pacific (Australia and Hong Kong come to my mind))
programmer statistically less error-prone and more successful as a programmer
just because she seemingly doesn't have to learn the keywords?

That might be an interesting topic for a study. But I think it's the
wrong question. A "programmer" does program, so he has already learned
those keywords. The more interesting question is IMHO: Are there more
programmers among people who speak English than among people who don't?
And if that is the case, is it because the latter find it harder to
learn (English based) programming languages?

To make a long story short: Language is more than lexicon and grammar.
Replacing the lexicon by close approximates of the lexicon is only partially
helpful. It is the documentation which needs a careful translation first.

Perhaps after porting Perl to so many platforms, we should start porting
the Perl documentation to more languages besides English. CPAN would gain
a huge advantage from such an effort, as would the global Perl community.

Googling for "deutsche perl dokumentation" gives
http://www.perlmongers.de/?DeutschePerlDokumentation and
http://wiki.perl-community.de/bin/view/Perldoc/perl as the first hits,
which is a rather sad result, as both look like somebody started a
translation project and got bored with it very quickly.

I agree that for Perl translating documentation and books is a lot more
important than translating the language. A translated Perl wouldn't be
Perl anyway.

hp

 

[Michele Dondi]

And that's a good thing. I'm not pining for the "good old days". But I
think that current GUIs (which haven't changed all that much since XEROX
invented the mouse in the 1970s) aren't optimal either. I see all the
time people doing repetitive tasks, for which on Linux I would write a
five line shell script and be done with it. And I ask myself how the GUI
user could be enabled to write that script. Or let's formulate this in a

Really, this comes out so often... having started with a cli, albeit a
very poor one just like the old command.com was, I have a natural
inclination for clis. Of course the discovery of *NIX shells with the
arrival of Linux was such a shift of perspective in terms of power at
hand!!

So we can see all the time how people, coming especially from the Win*
world, have a hard time trying to do something with two or three
buttons of a mouse that we can do with selected buttons out of 100 or
so on a keyboard. In a fraction of the time that it takes them to
reach for the mouse and move the cursor to the correct point...

Nevertheless this is *not* the cli side of a cli vs. gui flame. Indeed
guis are attracting, handy, respectable and there are jobs they're
better suited to. All in all they're complementary.

==> The key point of this reflection is: shells are a means to manage
programs. So is a window manager. Then there are text based commands
to do system administration. Some are shell commands and others
external programs. Their graphical counterparts are typically embedded
in a file manager. Most of the time I prefer the cmd line tools, but
in selected cases a file manager is better suited for some particular
job. OTOH I bet most of you often find it easier to type 'someprogram
&' in some terminal rather than searching someprogram in a menu or set
of icons or some such! So... I'm generally a big supporter of the
concept of separation (the right tool for the right job, and all
interacting nicely to give the possibility of building something more
complex together), but what I really miss is a beast that is at the
same time a window manager, a file manager, and a (text-like) shell.


End of the free-thought-session,
Michele

 

[Michele Dondi]

network-accessible command/status interface would be useful for both). A
modern mobile phone OTOH is almost a general purpose computer. There are
a few things for which it is unsuitable due to its small size, but apart
from that there isn't much difference to a desktop PC (and it's
certainly more powerful than the first computers I used were).

Indeed mobiles are getting more and more complex and feature rich, and
now a Java VM is commonly found of them. But I'd rather prefer them to
be somewhat simpler and allow a programmable low-level system for the
daring, instead. Something in forth, say, or io
(<http://www.iolanguage.org>), maybe.


Michele

 

[Michele Dondi]

Right. Actually, it goes deeper. Some people have problems with the
concept of a loop, or a variable. These people will probably never be

<joke>
They may just program in a functional language which has no notion of
variable or loop, and just use recursion.
</joke>


Michele