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 dev.laptop.org 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: http://wiki.laptop.org/go/Develop Regarding code i18n, I filed a bug on the OLPC track several months ago concerning docstring translation: http://dev.laptop.org/ticket/1075 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
