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

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. :) Homunq 17:23, 28 July 2007 (EDT)