[sugar] Develop activity (Oops...)

[Ian Bicking]

Andrew L. Clunis wrote:
> - code internationalisation.  Jameson and myself have been discussing
>   various means of achieving this lofty goal, see below;

This is a really ambitious goal.  I hope it doesn't keep us from having 
a good non-internationalized Develop activity.

I think it is also unclear yet whether this is feasible -- not just from 
a technical point of view, but whether it is feasible in terms of 
community structure, whether this translation can keep pace with 
upstream development, whether the abstractions will be too leaky.  Lots 
of people who don't speak English program, and from what I understand 
they don't internationalize their languages.  When they type "for" they 
don't have the English word "for" to remind them what it does, but they 
learn what it means independently from its meaning in any natural 
language.  That's what *all* programmers do; knowing English you just 
get a head start because you have a hint about what "for" might mean due 
to the natural language analogy.

But anyway, this is all to say that before committing fully to this 
translation effort I think you should create a fully working prototype 
that you can use to tell if it's really a workable goal.  And Develop 
shouldn't block on this goal.

A possible quick-and-dirty way to experiment with this is to hack 
Python's encoding.  An example of this is here: 
http://timhatch.com/projects/pybraces/

Basically you'd do:

   # -*- coding: lang_es -*-

And the 'lang_es' encoding would get first crack at rewriting the entire 
module.  Alternately you could use .py_es, and create a custom importer 
that did the same thing, which might be more reasonable.  Maybe an 
advantage of the custom importer is that you could wrap the entire 
module object, and possible wrap all the imported modules and objects 
(maybe with some kind of translating proxy).  Alternately you could just 
translate identifiers, and maybe use a translating version of getattr. 
But no matter what happens you are going to have leaking.

Another option for translation is PyLogo, which can run Python code, but 
has a clearer point for adding translation.  And probably a smaller 
scope of things that would have to be translated.  In that model, PyLogo 
would be a bridge to the more "full" language of Python, and part of 
crossing that bridge would involve learning some English (or at least 
the English keywords and attributes; the docstrings may still be 
translated).  For good and bad there would also be a clearer distinction 
between user and system code; user code would be in Logo, system code in 
Python, and by default users would see the Python code as effectively 
opaque.  So, for instance, tracebacks would leave out Python frames.  As 
a first-programming-language-ever experience, I think this can be helpful.

Anyway, some thoughts.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers