Bityi (translating code editor): Difference between revisions
Jump to navigation
Jump to search
| (16 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Source-code editor with transparent native-language display== |
|||
Almost all programming is done in programming "languages" based on English. These are really codes, much less than languages, with a limited vocabulary. Still, it's a significant barrier for other-language programmers, especially young ones. A modern computer, even a cheap one, would have no trouble doing transparent, real-time translation into the user's natural language. For instance, on disk you'd have python "if ... else...", but on screen, you'd see (and write) "si... sino..." (spanish). |
Almost all programming is done in programming "languages" based on English. These are really codes, much less than languages, with a limited vocabulary. Still, it's a significant barrier for other-language programmers, especially young ones. A modern computer, even a cheap one, would have no trouble doing transparent, real-time translation into the user's natural language. For instance, on disk you'd have python "if ... else...", but on screen, you'd see (and write) "si... sino..." (spanish). |
||
Note that the problem is not quite THAT simple. It must deal not only with the keywords and the builtins of the language. It should have a facility for translating identifiers from modules also. |
|||
To make my proposal a little more specific: |
|||
== Current design thoughts... == |
|||
* Based on scintilla (BOB open-source editing component, already does coloring and folding). |
|||
* If the user unknowingly used an English keyord on-screen, it would be "escaped" with a prefix like "ES_" on disk. |
|||
* Similarly, if a program used a whateverlanguage keyword, it could be escaped on-screen. |
|||
* A right-click on any word shows the English version, obviously includes easy option to turn translation off globally. |
|||
* By default, only translates keywords for given programming language, but includes option to have cascading translation files for files and the libraries they use. These could be created on-the-fly using right-clicks with dictionary support. |
|||
are at [[Source-code editor with transparent native-language display/design]]. |
|||
a few implementation brainstorms... |
|||
* Only what's actually on screen need be duplicated in memory |
|||
* The cursor counts as a wordbreak for speed reasons. |
|||
== Older discussion == |
|||
Interested? Contact me.... I will be continuing to explore this idea, but I'm not going to jump in with both feet unless I have some backup.--[[User:Homunq|Homunq]] 16:20, 25 July 2007 (EDT) |
|||
has been moved to the [[Talk:Source-code editor with transparent native-language display|talk page]]. |
|||
==Name== |
|||
Some details of scite/scintilla: GTK based, as is takes under 2 megs decompressed and with lexers for many many languages. |
|||
The word "bityi" is drawn from John Wilkins's 1664 artificial language. It is the word for language number 42 (bi-: discourse; -t-:5th of 9 subgenuses ; -yi: 8th of 9 subspecies): in Douglas Adams's world of the babel fish, this would be the Final Answer Language. Obviously, such a linguistically triumphalistic name is meant ironically: Wilkins's language is best known as the butt of one of Borges's intricate jokes, and the "final answer" of 42 is no good to anyone without a question. I hope that this project will be successful, but it can only avoid the pitfalls of previous Grand Linguistic Plans if it focuses on being as useful and unobtrusive as possible and NOT on being a total solution for everything. |
|||
==But...== |
|||
I just read the OLPC interface guidelines, particularly the "view source" key. From one angle: that just emphasizes that this idea should be absolutely central to this project, I'm actually even more surprised than I already was that (as far as I can tell, sorry if I've missed you) no-one has thought of it. From another angle: if you want to be able to view the source OF the view source activity, a laudible goal, that would tend to indicate that for OLPC purposes this would be better based on IDLE. But my interest in this idea is not solely OLPC-based. So... again, contact me if you want to collaborate with me on this one. If my first collaborator wants to go with or other Python/TK based editor, great, I like to program Python; if they prefer scintilla in C++, great, I think it will have a wider impact. |
|||
===Possible criticism=== |
|||
Either way, I repeat: this idea is absolutely vital to OLPC fulfilling its goal (perhaps not the main goal, but clearly a goal) of creating as many programmers as possible.[[User:Homunq|Homunq]] 06:05, 28 July 2007 (EDT) |
|||
Several people with whom I have talked about this have voiced concern that this would mean that a programmer would be hamstrung by not learning "real" python (or other programming language), but the translated version. This is a valid criticism, but I have two responses. |
|||
# Most importantly, I intend this as a stepping stone, not as an end in itself. I expect users of this functionality to use it to help them to learn the English idioms, even if they continue to prefer to code in their languages. I also expect that as they get into programming, they will be more motivated to learn English for a thousand other reasons - more than they would have if learning (a few words of) English had been an initial hurdle. |
|||
== And then... == |
|||
Further browsing and exploration finally leads me to [[Develop#Human Language and Culture Concerns]] where this issue has been discussed. As you can see from what I say here, I think that there are simple solutions to the issues raised there. I'll go continue this discussion over there. |
|||
[[User:Homunq|Homunq]] 15:30, 28 July 2007 (EDT) |
|||
[[Category:Software ideas]] |
|||
# Secondly, I expect to make this a solid, useful, and ubiquitous enough functionality that, even though they will eventually have to learn to read English code and comments, they will never be forced to retrain their fingers to type 'if' in English unless they want to. |
|||
==Isolating== |
|||
This will serve to isolate the programmers. It locks them into a programming ghetto. They won't be able to write normal code with a normal editor. They won't be able to follow examples on the web. |
|||
==Status== |
|||
It's not as if anybody needs this. As proof, I offer English. The "for" loop common to numerous programming languages has nothing to do with the English word as far as I can see. Neither does the "static" keyword. We get by OK. We just memorize what the keywords do. We even deal with unpronouncable things like "^" and completely weird usage of basic punctuation. |
|||
A proof-of-concept based on IDLE is coming along decently at the [[git]] tree for idly-develop: //dev.laptop.org/git/projects/idly-develop . |
|||
[[User:AlbertCahalan|AlbertCahalan]] 00:06, 10 August 2007 (EDT) |
|||
*Translation works and tested |
|||
:I understand the point, and it is a possibility. |
|||
*Adding / removing multiple dictionaries (in the future, for multiple files) seems to work but is not well tested. |
|||
*File IO for dictionaries is implemented for single files, work is underway to update it to use one file per language after the first two (english and preferred) |
|||
:However, I'd argue that, in making the first step into programming easier, it is a good thing; further steps, of learning "keyword English", can and will come easily later. After all, which was harder to learn, the first computer language you knew, or the second? |
|||
*Using the actual IDLE (with syntax coloring) in another language works, for shell and files. Currently the only dictionaries are spanish keywords and builtins. |
|||
*Dictionary changes with an open file are unimplemented. |
|||
:Consider the following scenarios: A child who is literate in Arabic presses the "view source" key and sees an impenetrable mass of foreign symbols; or, they see some confusing words which seem to have their own strange logic. Which do you think is more likely to lead to that child, 10 years later, being fluent enough in English to search for code snippets on the web? It's not clear-cut, but I'd say the second. |
|||
*UI additions (tooltips and new menu items) are in process: |
|||
:*Preference dialog changes are working |
|||
:Or for you: say that SQL was in russian, with cyrillic letters and all. Sure, you could learn "выберите ... из ... где ...", and read it in all the examples on the web and in your programming books - but if an editor plugin came along that let you write "select ... from ... where ...", wouldn't you use it in your own coding? I sure would, and "ghetto" be damned. |
|||
:*one menu item which toggles the window from English to otherLang (this sometimes breaks the syntax coloring, currently.) |
|||
:*Tooltips only for keywords, using mousein/mouseout. Does not notice when you move your mouse between two contiguous keywords - to me, not a problem. |
|||
:Final point: it is entirely possible that, 10 years from now, this feature is as common as syntax coloring in any code editor program (and exists as a browser plugin, and is automagically done by "did you mean" in all major search engines, etc.) If the ghetto is the whole world, where's the ghetto? [[User:Homunq|Homunq]] 13:30, 10 August 2007 (EDT)) |
|||
[[Category:Language support]] |
|||
Latest revision as of 20:14, 5 March 2009
Source-code editor with transparent native-language display
Almost all programming is done in programming "languages" based on English. These are really codes, much less than languages, with a limited vocabulary. Still, it's a significant barrier for other-language programmers, especially young ones. A modern computer, even a cheap one, would have no trouble doing transparent, real-time translation into the user's natural language. For instance, on disk you'd have python "if ... else...", but on screen, you'd see (and write) "si... sino..." (spanish).
Note that the problem is not quite THAT simple. It must deal not only with the keywords and the builtins of the language. It should have a facility for translating identifiers from modules also.
Current design thoughts...
are at Source-code editor with transparent native-language display/design.
Older discussion
has been moved to the talk page.
Name
The word "bityi" is drawn from John Wilkins's 1664 artificial language. It is the word for language number 42 (bi-: discourse; -t-:5th of 9 subgenuses ; -yi: 8th of 9 subspecies): in Douglas Adams's world of the babel fish, this would be the Final Answer Language. Obviously, such a linguistically triumphalistic name is meant ironically: Wilkins's language is best known as the butt of one of Borges's intricate jokes, and the "final answer" of 42 is no good to anyone without a question. I hope that this project will be successful, but it can only avoid the pitfalls of previous Grand Linguistic Plans if it focuses on being as useful and unobtrusive as possible and NOT on being a total solution for everything.
Possible criticism
Several people with whom I have talked about this have voiced concern that this would mean that a programmer would be hamstrung by not learning "real" python (or other programming language), but the translated version. This is a valid criticism, but I have two responses.
- Most importantly, I intend this as a stepping stone, not as an end in itself. I expect users of this functionality to use it to help them to learn the English idioms, even if they continue to prefer to code in their languages. I also expect that as they get into programming, they will be more motivated to learn English for a thousand other reasons - more than they would have if learning (a few words of) English had been an initial hurdle.
- Secondly, I expect to make this a solid, useful, and ubiquitous enough functionality that, even though they will eventually have to learn to read English code and comments, they will never be forced to retrain their fingers to type 'if' in English unless they want to.
Status
A proof-of-concept based on IDLE is coming along decently at the git tree for idly-develop: //dev.laptop.org/git/projects/idly-develop .
- Translation works and tested
- Adding / removing multiple dictionaries (in the future, for multiple files) seems to work but is not well tested.
- File IO for dictionaries is implemented for single files, work is underway to update it to use one file per language after the first two (english and preferred)
- Using the actual IDLE (with syntax coloring) in another language works, for shell and files. Currently the only dictionaries are spanish keywords and builtins.
- Dictionary changes with an open file are unimplemented.
- UI additions (tooltips and new menu items) are in process:
- Preference dialog changes are working
- one menu item which toggles the window from English to otherLang (this sometimes breaks the syntax coloring, currently.)
- Tooltips only for keywords, using mousein/mouseout. Does not notice when you move your mouse between two contiguous keywords - to me, not a problem.