<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>                       concept of transparent non-English-based editing of<br>                       real python code. See notes, below, for further discussion.<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>   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>   #1 homunq     Jameson Quinn         <a href="http://www.casarizoma.org/id_dsa.pub">www.casarizoma.org/id_dsa.pub</a>     <a href="mailto:jquinn@cs.oberlin.edu">

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>       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>       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>       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>   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>   [ ] 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>   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>   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>   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>       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>   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">

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">http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display

</a><br><a href="http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display/design">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">

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>(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>(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>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>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>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>