Bityi (translating code editor): Difference between revisions
(contact me please) |
|||
(25 intermediate revisions by 4 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. |
|||
[[Category:Software ideas]] |
|||
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. |
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.