Yesterday, I subscribed to the list and sent this message. I still haven't gotten it, making me think that it got swallowed by moderation before my subscription took effect. I'm resending it now to see if it gets through. If you get two copies, I apologise.

<br><br><div><span class="gmail_quote">On 8/9/07, <b class="gmail_sendername">Jameson Chema Quinn</b> <<a href="mailto:jquinn@cs.oberlin.edu">jquinn@cs.oberlin.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<pre>1. Project name             : Idly Develop<br>2. Existing website, if any : none<br>3. One-line description     : A proof of concept for multilingual programming<br><br>4. Longer description       : An IDLE-based program editor demonstrating the 

<br><br>                       concept of transparent non-English-based editing of<br>                       real python code. See notes, below, for further discussion.<br>                            :<br>                            :

<br><br><br>5. URLs of similar projects : Well, there's IDLE, and from about 1995-98 Appletalk did something similar... but this is really a new concept. <br><br>6. Committer list <br>   Please list the maintainer (lead developer) as the first entry. Only list 

<br><br>   developers who need to be given accounts so that they can commit to your<br>   project's code repository, or push their own. There is no need to list<br>   non-committer developers.<br><br>      Username   Full name             SSH2 key URL                    E-mail

<br><br>      --------   ---------             ------------                    ------<br>   #1 homunq     Jameson Quinn         <a href="http://www.casarizoma.org/id_dsa.pub" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

www.casarizoma.org/id_dsa.pub</a>     <a href="mailto:jquinn@cs.oberlin.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

jquinn@cs.oberlin.edu</a><br><br>I know that at least a couple of others would be interested, I'd be happy to allow any who want to to sign up.<br><br><br>7. Preferred development model<br><br>   [X] Central tree. Every developer can push his changes directly to the 

<br><br>       project's git tree. This is the standard model that will be familiar to <br>       CVS and Subversion users, and that tends to work well for most projects.<br><br>   [ ] Maintainer-owned tree. Every developer creates his own git tree, or

<br><br>       multiple git trees. He periodically asks the maintainer to look at one<br>       or more of these trees, and merge changes into the maintainer-owned,<br>       "main" tree. This is the model used by the Linux kernel, and is 

<br><br>       well-suited to projects wishing to maintain a tighter control on code<br>       entering the main tree.<br><br>   If you choose the maintainer-owned tree model, but wish to set up some<br>   shared trees where all of your project's committers can commit directly, 

<br><br>   as might be the case with a "discussion" tree, or a tree for an individual <br>   feature, you may send us such a request by e-mail, and we will set up the <br>   tree for you.<br><br>8. Set up a project mailing list:

<br><br><br>   [ ] Yes, named after our project name<br>   [ ] Yes, named ______________________<br>   [X] No<br><br>   When your project is just getting off the ground, we suggest you eschew<br>   a separate mailing list and instead keep discussion about your project

<br><br>   on the main OLPC development list. This will give you more input and <br>   potentially attract more developers to your project; when the volume of <br>   messages related to your project reaches some critical mass, we can 

<br><br>   trivially create a separate mailing list for you.<br><br>   If you need multiple lists, let us know. We discourage having many <br>   mailing lists for smaller projects, as this tends to<br>   stunt the growth of your project community. You can always add more lists

<br><br>   later.<br><br>9. Commit notifications<br><br>   [ ] Notification of commits to the main tree should be e-mailed to the list<br>       we chose to create above<br>   [ ] A separate mailing list, <projectname>-git, should be created for commit

<br><br>       notifications<br>   [X] No commit notifications, please<br><br>10. Shell accounts<br><br>   As a general rule, we don't provide shell accounts to developers unless <br>   there's a demonstrated need. If you have one, please explain here, and

<br><br>   list the usernames of the committers above needing shell access.<br><br>11. Notes/comments:<br>A. For prior discussion of this concept, see (oldest to newest):<br><a href="http://wiki.laptop.org/go/Develop#Human_Language_and_Culture_Concerns" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://wiki.laptop.org/go/Develop#Human_Language_and_Culture_Concerns</a><br><a href="http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display<br></a><br><a href="http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display/design" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display/design</a><br><a href="http://lists.laptop.org/pipermail/sugar/2007-August/003012.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://lists.laptop.org/pipermail/sugar/2007-August/003012.html</a> and associated thread.<br><br><br>B. Note on terminology: For what follows,<br>(Spanish) is shorthand for "user's non-English native language". 

<br><br>(Arabic) is short for "another non-English language". <br>(*Spanish) and (*English) are interchangeable variables for two languages, one of which is English.<br><br>C. Basic concepts and design philosophy

<br>

Write in Spanish-based quasiPython, save in English-based Python.<br>   reason: this keeps code fully portable, yet lowers the barriers to entry, especially for younger children who are not comfortable with English.<br><br>

Built-in translations of python keywords for all OLPC target languages    reason: it's easy, there are so few. Easy, GUI-based and dictionary-supported tools for translation of identifiers    reason: if everyone can translate, it will go fast. Wiki-style philosophy.

Ditto for line-by-line translation of docstrings and comments    reason: line-by-line translation allows the possibility of twext, not too fine or too granular. Translate ONLY module "public interfaces", not internals.

<br><br>(ie, what would go in a .h file if python had them - the things that get used by another module that imports it)<br>   reason: this simplifies the task of translating. It is probably not especially productive to try to translate module internals. 

<br><br>Also, see next point.<br><br>The translation UI only lets you translate INTO your preferred language the interfaces of modules IMPORTED BY your modules<br>   reason: this is the most useful user case. Restricting things to this case MASSIVELY simplifies the programming task

<br><br>and reduces the possible errors created, as the model is already focused on the interface between two specific files, so<br>overtranslation is not a risk, and as it is also reasonable in this case to expect user input on what file the translation

is intended to apply to. D. Status: new module in idlelib with >300 LOC. Of these, ~100 do the simple, static translation, and work; the other ~200 are focused on managing multiple translation dictionaries for multiple open files, these currently run but are buggy/incomplete.

minor modifications to EditorWindow, IOBinding, and a couple other existing IDLE modules (not ColorDelegator yet).  These make a working editor and shell with a static translation of keywords from English to Spanish.

E. Plans: This is intended as a proof-of-concept.  I expect that about 60-80% of the code could be reused with an AbiWord editor gadget (rather than the tk text gadget IDLE uses) for the real Develop activity.

<br><br>I also expect that when it's done, making it generalizable to computer languages other than Python would be about 20% additional work.<br></pre>

</blockquote></div><br>