Talk:Bityi (translating code editor): Difference between revisions
(New page: Scintilla is best starting codebase I know of as it has widest use. However, this is a new concept, so developing something from some other codebase or from scratch is not out of the quest...) |
(Name collisions) |
||
| Line 1: | Line 1: | ||
Scintilla is best starting codebase I know of as it has widest use. However, this is a new concept, so developing something from some other codebase or from scratch is not out of the question. I have had trouble in the past few days even getting on to the Scintilla mailing list or getting any live response, so this may well have to be a fork anyway. --[[User:Homunq|Homunq]] 17:07, 25 July 2007 (EDT) |
Scintilla is best starting codebase I know of as it has widest use. However, this is a new concept, so developing something from some other codebase or from scratch is not out of the question. I have had trouble in the past few days even getting on to the Scintilla mailing list or getting any live response, so this may well have to be a fork anyway. --[[User:Homunq|Homunq]] 17:07, 25 July 2007 (EDT) |
||
== Name collisions == |
|||
It looks likely that name collisions will become common in a system like this. Your suggestion of prefixing names will reduce the problem, but will then introduce other problems if the raw source wants to be viewed in english again. |
|||
My suggestion would be firstly to try implementing a simpler system where the code is edited in english, but if any key word is mouse-overed, a translation is shown in a tooltip. A short description of the syntax of each "command" could be shown in the local language in the tooltip, together with an example useage and mode details a hyperlink away. |
|||
Since most programming languages only have tens of keywords, I can't see that this is much of a barrier to entry, especially if tooltips are provided. The tooltips also ought to be provided for common objects and functions. The tooltips should be provided in english as well for the english olpc versions - it would probably encourage more developers if things like the sugar api's could be briefly explained in a tooltip rather than wading through pages of in depth documentation. |
|||
Using tooltips dramaticly simplifies the programming and corner-cases, together with confusion to the user when things don't quite work right with translation due to problems with certain local names conflicting with keywords, while only slightly increasing difficulty for the user in my opinion. |
|||
One difficulty, which may rear it's head with either method, is that some keyboards won't be able to type standard latin characters, or may be missing some of the characters required for a certain programming language (eg. not all keyboards have the three types of braces "([{" ). The only solution I can think of would be to have a symbol palette somewhere. |
|||
As far as support goes, I don't have much experience with python, so I don't think I can help since olpc seems written in python (if they could re-write the kernel in python I guess they would...), but on a more serious note, If you decide to implement the tooltip idea first, I think that could be done singlehanded. If later full translation is required then a lot of the tooltip translation code could be re-used. |
|||
[[User:87.127.98.185|87.127.98.185]] 15:34, 28 July 2007 (EDT) |
|||
Revision as of 19:34, 28 July 2007
Scintilla is best starting codebase I know of as it has widest use. However, this is a new concept, so developing something from some other codebase or from scratch is not out of the question. I have had trouble in the past few days even getting on to the Scintilla mailing list or getting any live response, so this may well have to be a fork anyway. --Homunq 17:07, 25 July 2007 (EDT)
Name collisions
It looks likely that name collisions will become common in a system like this. Your suggestion of prefixing names will reduce the problem, but will then introduce other problems if the raw source wants to be viewed in english again.
My suggestion would be firstly to try implementing a simpler system where the code is edited in english, but if any key word is mouse-overed, a translation is shown in a tooltip. A short description of the syntax of each "command" could be shown in the local language in the tooltip, together with an example useage and mode details a hyperlink away.
Since most programming languages only have tens of keywords, I can't see that this is much of a barrier to entry, especially if tooltips are provided. The tooltips also ought to be provided for common objects and functions. The tooltips should be provided in english as well for the english olpc versions - it would probably encourage more developers if things like the sugar api's could be briefly explained in a tooltip rather than wading through pages of in depth documentation.
Using tooltips dramaticly simplifies the programming and corner-cases, together with confusion to the user when things don't quite work right with translation due to problems with certain local names conflicting with keywords, while only slightly increasing difficulty for the user in my opinion.
One difficulty, which may rear it's head with either method, is that some keyboards won't be able to type standard latin characters, or may be missing some of the characters required for a certain programming language (eg. not all keyboards have the three types of braces "([{" ). The only solution I can think of would be to have a symbol palette somewhere.
As far as support goes, I don't have much experience with python, so I don't think I can help since olpc seems written in python (if they could re-write the kernel in python I guess they would...), but on a more serious note, If you decide to implement the tooltip idea first, I think that could be done singlehanded. If later full translation is required then a lot of the tooltip translation code could be re-used.
87.127.98.185 15:34, 28 July 2007 (EDT)