<html>
<body>
Some examples in Etoys of Multilingual programming. Besides the Japanese
version shown here, some students in Japan have done a better one that
also uses Japanese syntax (this turns out to help many young children, as
one might expect). The Spanish one is particularly good as it has had the
useful pressure of being used heavily in Spain.<br><br>
Cheers,<br><br>
Alan<br><br>
<img src="cid:7.0.1.0.2.20070313061654.0762e5a0@squeakland.org.0" width=717 height=538 alt="[]">
<br><br>
<br><br>
At 07:46 PM 3/12/2007, Andrew Clunis wrote:<br>
<blockquote type=cite class=cite cite="">-----BEGIN PGP SIGNED
MESSAGE-----<br>
Hash: SHA1<br><br>
Ian Bicking wrote:<br>
> Since there's been some talk of programming environments and
whatnot, I<br>
> thought I'd throw out some ideas about the whole English focus of
most<br>
> programming.<br>
> <br>
> Anyway, I've thought a lot about how it might be possible to use
other<br>
> languages in Python code, and I can't come up with anything
even<br>
> slightly useful. With sufficient cleverness, it might be
possible to<br>
> support other languages in isolated code, but it's so isolated that
it<br>
> requires cutting off the rest of the environment. You can't
reasonable<br>
> translate things like dict.items, or the standard library, or the
code<br>
> that's going to be written by English speakers; and English will be
the<br>
> only common language among developers indefinitely, since there's
no<br>
> other common language to replace it, just local languages.<br>
> <br>
> Still, we could create miniature environments where largely
non-English<br>
> code could be written. It would involve lots of wrappers and
custom<br>
> libraries or wrappers and some hiding of libraries in tracebacks
and<br>
> elsewhere. Keywords would still be left. But the result
is so<br>
> constructed and isolated, I'm not sure if it's any better than
just<br>
> using a different language.<br>
> <br>
> Something that can be localized reasonably easily is the
documentation<br>
> itself. That could even include docstrings -- a small hack to
help()<br>
> and/or pydoc could look up translated docstrings, probably just
leaving<br>
> the original docstrings in place. This could be useful.<br>
> <br>
> Another option that came up in conversation (though I've forgotten
the<br>
> guy's name) is to use a language more suited to translation (like
Logo,<br>
> or eToys scripting) but really focus on using that as a bridge
to<br>
> English programming. That could be done simply by offering
translations<br>
> as much as possible. E.g., if they type in:<br>
> <br>
> para cuadrado :longitud<br>
> repetir 4 [ad :longitud iz 90]<br>
> fin<br>
> <br>
> And they get alongside (and they could use at any time if they
want):<br>
> <br>
> to cuadrado :longitud<br>
> repeat 4 [forward :longitud left 90]<br>
> end<br>
> <br>
> This is only somewhat helpful, since the language used in Logo and
eToys<br>
> doesn't actually line up with Python. But maybe that should be
a goal;<br>
> at least with Logo it *could* line up. There's no repeat in
Python, but<br>
> "to" is "def", for *could* be added
("for" seems to mean lots of<br>
> different things), it could have significant indentation, and some
other<br>
> renaming.<br>
> <br>
> Anyway, just throwing out some ideas.<br>
> <br><br>
This has been a pretty serious concern for Develop activity. It
seems<br>
like we are basically resigned to forcing people to at least learn
the<br>
pseudo-english mnemonic keywords. However, I have been thinking
that it<br>
might be possible to make a gettext-like translation database of the<br>
docstrings in commonly used APIs.<br>
<br>
That, and a properly translatable OLPC Programmers' Manual would go
a<br>
long way to improving matters without doing anything too
drastic.<br><br>
As I mention in the last section
<a href="http://wiki.laptop.org/go/Develop" eudora="autourl">
http://wiki.laptop.org/go/Develop</a> ,<br>
though, a translation matrix of language keywords (at least for
Python)<br>
probably creates more problems than it solves...<br><br>
- --<br>
Regards,<br>
Andrew Clunis<br><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.3 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla -
<a href="http://enigmail.mozdev.org/" eudora="autourl">
http://enigmail.mozdev.org</a><br><br>
iD8DBQFF9h6tALkUMXSNow8RAiYOAKCHUNwGdm2bIh3mucL1fBMj4jBsAQCfTmBx<br>
tNmyM8OgStdCyWDbtfcE36E=<br>
=zbZf<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Sugar mailing list<br>
Sugar@laptop.org<br>
<a href="http://mailman.laptop.org/mailman/listinfo/sugar" eudora="autourl">
http://mailman.laptop.org/mailman/listinfo/sugar</a></blockquote></body>
</html>