Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Native language versions

Reply
Thread Tools

Native language versions

 
 
Tad McClellan
Guest
Posts: n/a
 
      06-22-2006
<(E-Mail Removed)-berlin.de> <(E-Mail Removed)-berlin.de> wrote:
> Tad McClellan <(E-Mail Removed)> wrote:
>
>: > 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?


--
Tad McClellan SGML consulting
http://www.velocityreviews.com/forums/(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
 
 
 
Guest
Posts: n/a
 
      06-22-2006
Tad McClellan <(E-Mail Removed)> wrote:

: 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.

--
Dr. Oliver Corff e-mail: http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de
 
Reply With Quote
 
 
 
 
Ted Zlatanov
Guest
Posts: n/a
 
      06-23-2006
On 22 Jun 2006, (E-Mail Removed)-berlin.de wrote:

Tad McClellan <(E-Mail Removed)> wrote:
>
>> 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).


Why stop there? Just write the operators in Unicode

Ted
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      06-23-2006
(E-Mail Removed)-berlin.de wrote:
> Peter J. Holzer <(E-Mail Removed)> wrote:
> : > Ian <(E-Mail Removed)> wrote:
> : > : 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

--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | (E-Mail Removed) | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
 
Reply With Quote
 
Guest
Posts: n/a
 
      06-23-2006
Peter J. Holzer <(E-Mail Removed)> wrote:

: 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.


--
Dr. Oliver Corff e-mail: (E-Mail Removed)-berlin.de
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      06-24-2006
(E-Mail Removed)-berlin.de wrote:
> Peter J. Holzer <(E-Mail Removed)> wrote:
> : > 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

--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | (E-Mail Removed) | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      06-25-2006
On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
<(E-Mail Removed)> wrote:

>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
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      06-25-2006
On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
<(E-Mail Removed)> wrote:

>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
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      06-25-2006
On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
<(E-Mail Removed)> wrote:

>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
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
allow visitors to simply translate your site to their native language ! martin.benuska@gmail.com HTML 4 12-27-2006 04:03 AM
ASP.NET Return Server Native Language Dessip ASP .Net 3 06-16-2006 08:58 AM
A language-agnostic language Ed Java 24 03-27-2006 08:19 PM
On helping with Local Language versions... Britzilla Firefox 1 03-23-2005 06:01 PM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM



Advertisments