[sugar] Develop activity (Oops...)

[Andrew L. Clunis]

----- "Ian Bicking" <ianb at colorstudy.com> wrote:
> 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.

Actually, I'm of the same mind there to a certain extent.  If "for", "if",
"while" and company are just considered part of the Python language
instead of the English language, the problem goes away.  One could even
consider identifiers merely symbols (which they are) for an abstract
concept.

However, while for this might be true for Real Programmers, I'm told
that for young children the English keywords and identifiers can prove
to be a significant barrier.

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

I agree.

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

Yikes.

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

Hm, that is a good point; perhaps if the focus for i18n was done on
eToys and Logo (which are the things that the younger kids will be
using anyway), then the idea that Develop activity would simply expose
Python without any language assistance does seem easier to swallow.
Especially if there was a good internationalized documentation system.

> 
> Anyway, some thoughts.

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


-- 
Regards,
Andrew Clunis