View source for Talk:Bityi (translating code editor)

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 usage and more 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.

I don't know what the status of the current "Develop" activity is, but the tooltips could go well with auto-completion.  See Visual Studio .NET 2005 for a very nice implemention of that - they call it intellisense or something - have a look on wikipedia (http://en.wikipedia.org/wiki/IntelliSense) if you don't have windows.

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)

:My suggestion would rigorously eliminate name collisions. Yes, it would mean that code written in Spanish and viewed in English would still have Spanish variable/function/object names, including a few which, due to collisions with English keywords (or even collisions with English v/f/o names that happened to be dynamically added to the translation mapping by the Spanish programmer), have the prefix es_. The Spanish names are pretty much unavoidable and there is a possible solution for code that gains widespread use in English (a retranslation tool which also adds things to the dynamic translation mapping). The prefixing is exactly the correct behaviour in this case. And besides, this stuff will be MORE of a problem if you do things with tooltips (think about it).

:As a teacher, I can say categorically that even 10s of keywords would be a barrier to many kids. Not all, by any means; but we should go for maximum accessibility.

:ps. Who are you? You should register, it would be good to have at least a screen name to respond to.

:pps. Thanks for the comments, and no need to make excuses for not volunteering to help. But honestly, if Python has any advantage, it's that it is is easy to pick up. Whether you like it is another issue, but I'm sure you could hack it. :) [[User:Homunq|Homunq]] 17:23, 28 July 2007 (EDT)

::OK - you pursuaded me to sign up - just getting an account... [[User:87.127.98.185|87.127.98.185]] 05:28, 29 July 2007 (EDT)

::Back again with a shiny new account.  I see your point about "even 10s of keywords would be a barrier to many kids", and since I only speak one language, I'll take your word on that.

::For the full translation, there are quite a few more things that need to be considered.  For example runtime errors that mention a refrence to the code (eg. Error on line 17, column 21) would need to be dynamicly adjusted.  Also, if the interpreter gives a code snippit around an error it would need adjustment.

::Also, if it's a programming language that allows code in strings to be evaluated, that could cause big problems, because that would require translation at program runtime rather than just on file open or save.  For example Javascripts "eval" function (http://www.w3schools.com/jsref/jsref_eval.asp).  In that case I can't see any clean way of allowing localized keywords to work without serious modification to the interpreter, and in many cases it would mean that the program actually runs differently.

::Even with using full translation, I think tooltips with descriptions and "intellisense like" features are useful, especially if you're new to programming in a particular area and want to know the class etc. names.

::I would consider it important for it to be very easy to toggle the translation on and off - particularly because if someone always works with translation on they won't be able to program on another platform that doesn't have translation.  [[User:Hello1024|Hello1024]] 05:43, 29 July 2007 (EDT)