[sugar] Multilingual programming

Andrew Clunis orospakr at linux.ca
Mon Mar 12 23:46:54 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Bicking wrote:
> Since there's been some talk of programming environments and whatnot, I
> thought I'd throw out some ideas about the whole English focus of most
> programming.
> 
> Anyway, I've thought a lot about how it might be possible to use other
> languages in Python code, and I can't come up with anything even
> slightly useful.  With sufficient cleverness, it might be possible to
> support other languages in isolated code, but it's so isolated that it
> requires cutting off the rest of the environment.  You can't reasonable
> translate things like dict.items, or the standard library, or the code
> that's going to be written by English speakers; and English will be the
> only common language among developers indefinitely, since there's no
> other common language to replace it, just local languages.
> 
> Still, we could create miniature environments where largely non-English
> code could be written.  It would involve lots of wrappers and custom
> libraries or wrappers and some hiding of libraries in tracebacks and
> elsewhere.  Keywords would still be left.  But the result is so
> constructed and isolated, I'm not sure if it's any better than just
> using a different language.
> 
> Something that can be localized reasonably easily is the documentation
> itself.  That could even include docstrings -- a small hack to help()
> and/or pydoc could look up translated docstrings, probably just leaving
> the original docstrings in place.  This could be useful.
> 
> Another option that came up in conversation (though I've forgotten the
> guy's name) is to use a language more suited to translation (like Logo,
> or eToys scripting) but really focus on using that as a bridge to
> English programming.  That could be done simply by offering translations
> as much as possible.  E.g., if they type in:
> 
>   para cuadrado :longitud
>     repetir 4 [ad :longitud iz 90]
>   fin
> 
> And they get alongside (and they could use at any time if they want):
> 
>   to cuadrado :longitud
>     repeat 4 [forward :longitud left 90]
>   end
> 
> This is only somewhat helpful, since the language used in Logo and eToys
> doesn't actually line up with Python.  But maybe that should be a goal;
> at least with Logo it *could* line up.  There's no repeat in Python, but
> "to" is "def", for *could* be added ("for" seems to mean lots of
> different things), it could have significant indentation, and some other
> renaming.
> 
> Anyway, just throwing out some ideas.
> 

This has been a pretty serious concern for Develop activity.  It seems
like we are basically resigned to forcing people to at least learn the
pseudo-english mnemonic keywords.  However, I have been thinking that it
might be possible to make a gettext-like translation database of the
docstrings in commonly used APIs.

That, and a properly translatable OLPC Programmers' Manual would go a
long way to improving matters without doing anything too drastic.

As I mention in the last section http://wiki.laptop.org/go/Develop ,
though, a translation matrix of language keywords (at least for Python)
probably creates more problems than it solves...

- --
Regards,
Andrew Clunis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9h6tALkUMXSNow8RAiYOAKCHUNwGdm2bIh3mucL1fBMj4jBsAQCfTmBx
tNmyM8OgStdCyWDbtfcE36E=
=zbZf
-----END PGP SIGNATURE-----


More information about the Sugar mailing list