[sugar] Develop activity (Oops...)
Ian Bicking
ianb
Mon Aug 6 12:47:54 EDT 2007
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
More information about the Sugar-devel
mailing list