Hi, this is Jameson. I'm pretty much available afternoons in Guatemala (GMT-6). I pretty much agree with what Andrew said about i18n of the programming language itself, but I have a slightly different point of view. I'm interested in doing something that would be as useful as possible for internationalization of programming itself, in both education and real-life, *across* languages and platforms. I actually agree that OLPC and Python is the coolest platform there is, and the right place to start this effort - but I hope that whatever we do will be generalizable beyond that niche. I want to get the UI right - just enough magic to do everything you want, but not so much that it gets annoying. That means either being very intimate with the editor's internal data structures, or being very bossy from outside them. Either way, but especially in the latter case, I see that when you mix dynamic changes of UI language (retranslation or detranslation on the fly), dynamic changes in the translation dictionary (at the module level, of course), and undo, things start to get complicated. I talked to some of the AbiWord developers on IRC about their data structures, and they are less-than-effusive about how robust their main text data structure is (their file structure is XML, but their data structure does not have "end tag" elements for many tags, so they have not been able to unit test that all their code respects clean heierarchical structure). This makes me continue to wonder if AbiWord is the right answer for the editor widget for the Develop activity. Andrew has been very clear with me that that is a done decision, because it will preserve a common UI and allow the new collaboration functions to be used in Develop. Still, if it were up to me, I'd like to consider both sides of that question. To do this right, we may want something more made-to-order - and maybe the collaboration is easier to add than it would be to hack AbiWord into the right shape. .... I'm going to describe my vision for i18n below, as best I can. This includes both user experience and some implementation, all mixed together, because without at least considering implementation it would be too easy to wish for the impossible. Go ahead and skip the rest of the message, if you want; this is just my way of getting my thoughts down on paper, and giving y'all a chance to read them before any phone call IF YOU WANT. In the below, "Spanish" is my shorthand for "some language besides English". On disk, you have .py files always in normal, (English-keywords) python. Sitting next to this file is a .p4n (or whatever) file which has a translation matrix for translating the identifiers of this file from English to any number of other languages. This p4n will only NOT exist for files written in English, with no translations. For files written in other languages but without translations provided, the p4n will consist of solely a preferred-language identifier (so that the interpreter knows what language they're written in). If an English translation is added to the p4n, that identifier is changed to English in the .py as well. Third languages cannot be added before English. Other programs with the same preferred language which load this module, automatically use the new English identifier based on the p4n translation, even if they were last saved with the Spanish identifier (before the p4n changed); to get this functionality, an preferred-English .py which loads a preferred-Spanish module without translations must use some new "import thisSpanishModule in Spanish" terminology. While editing, you see your preferred language for all code. No identifier translation is performed on string literals (including docstrings) or most comments. There is a simple, ReST-based markup to turn translation ON for blocks or single words within comments. Also, a separate feature will translate whole comments or docstrings at a time, not on a word-by-word basis. There are menu items for "comment this out as code", "make the English version of the selection into a string", and "make the Spanish version of the selection into a string", as well as easy keyboard and menu shortcuts for toggling the translation function on and off. Other than this, the text behaves largely as if it only existed in the Spanish version. Tooltips and context menus give easy, constant access to seeing or changing the English translation of each identifier. Only actual code changes go in the undo stack - not translation-related changes.... Cheers, Jameson <div>On 8/4/07, Andrew L. Clunis <<a href="mailto:andrew@orospakr.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> andrew@orospakr.ca</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Ack, I hit the "Send" button as the "Save Draft" button!  Sorry about that, guys. :( Here is the rest of what I meant to say: Greetings all, A group of us are interested in getting to work on Develop activity. Here's what, as I understand it, people are working on: - code internationalisation.  Jameson and myself have been discussing   various means of achieving this lofty goal, see below; - version control (so kids can modify others' activities without   worrying about maintaining different copies of code, and providing   them with a means of sharing and merging any changes, etc.); - visual editing.  Mike Fletcher has been looking into Logo and   Smalltalk-like visual editing for python development.  Guido   has been looking into class reloading which would permit people to   modify the code in a running program, a necessary feature for visual   development; The current Develop source tree sitting on <a href="http://dev.laptop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> dev.laptop.org</a> is now quite out of date and no longer runs.  I personally considered it a spike solution, a demonstration of what a simple version of Develop could look like.  I'm not even sure we'll reuse any code from that version. Here, although it is somewhat out of date, is the wiki page for Develop: <a href="http://wiki.laptop.org/go/Develop" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.laptop.org/go/Develop </a> Regarding code i18n, I filed a bug on the OLPC track several months ago concerning docstring translation: <a href="http://dev.laptop.org/ticket/1075" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://dev.laptop.org/ticket/1075</a> However, recently Jameson and I came to the conclusion that not only are docstring translations necessary, but so are identifier translations. Jameson and myself have been discussing several alternative methods: Method I: The programmer writes a python file in whatever language they want. They set this language in some sort of "base language" directive in the file, and then add translations for the identifiers to a matching '.pyt' (a gettext-like table, perhaps?) file. Method II: ... is the same as Method I, except that the base language is always English.  The code is presented to the user for editing in the language of their choice using these the human language equivalents from the .pyt file (and the .pyt files of any imported modules).  In order to preserve the reversible 1-1 nature of the translation step localized words which clash with English keywords or localized words from other libraries are given an alphanumeric prefix to distinguish them.  Although this approach is perhaps not quite as "utopian" as Method I, it has several pragmatic benefits: more translators will be available with English serving as a lowest common denominator (more people know Arabic and English and Portuguese and English than know both Arabic and Portuguese); with a common base language, exchange of code will also be easier in the international community. On top of that, there remains the question as to how and where to implement this logic.  Should it be a separate tool/library (possibly troublesome, because Python's dynamism means that the only thing that truly understands scope is the interpreter at runtime), or something inside the interpreter (harder to implement/maintain/get accepted into upstream)? This is such a drastic change, with potentially extensive consequences, that its development should involve the Python community.  It should clearly begin life as a PEP. I suggest that we have a live discusson on either IRC, a teleconference (I imagine that the folks at 1CC would be able to arrange a teleconference for us), or Skype (ew), and see where it takes us. There are a lot of really awesome ideas floating around, but I think we need to make this a coherent effort.  When are people available? The first step would be decide what Develop should be (at least for Gen1), and write our acceptance tests. Happy hacking! -- Regards, Andrew Clunis </blockquote></div>