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 : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
