Talk:Bityi/GSoC

Any comments here would be greatly appreciated. Here's one from the mailing list:

SJ: overambitious

"All students can ask for feedback on this list; otherwise you will get feedback by email / through the SoC interface.

Feedback on this list is good if one is amenable, since it lets everyone see the sorts of issues that make for a better application. In this case, your proposal is an interesting one; though as this has been tried unsuccessfully in the past, it seems quite ambitious. One typical path to an unsuccessful summer internship is planning a project that one intends to do alone that is quite ambitious, without an obvious subset that could be used as an interim milestone and shared early on for public adoption. What kind of collaboration would you expect / need with other projects? Are there other people interested in the project who have been working with you to date? Does this interface directly with Develop?"

I have attempted to respond to the feasibility aspect on the page, with a calendar and some discussion of my first-draft attempt to attack this same problem. Also, clarified that this is a part of Develop - the "bityi" name is not a thing in itself, just a made-up word for this functionality. As to collaboration, I would expect the code to do this in Pippy would be quite simple, a later step (not encompassed in this proposal) would be pootle integration, but I can complete this proposal without collaboration. Homunq 09:33, 27 March 2008 (EDT)

Bobbypowers: cool

This looks really cool! You mentioned a central server that users could upload dictionaries too, maybe administered in a wiki-like way? As an American with unfortunately poor spanish skills, I would really like to be able to translate local identifiers from Spanish/Mandarin/whatever back to english in a tooltip or something on mouseover. As you mention, understanding identifiers adds important context for understanding what the code is doing. I agree, this is pretty much what the OLPC is all about! Good luck!

Bobbypowers 13:41, 27 March 2008 (EDT)

Server: that is a planned feature but I'm not promising it in the GSoC timeframe. Back to English: I guess I need to clarify, your editor has a language setting (defaulting to your OS language) and you see everything in that language as long as it exists - so you would never see Spanish if an English translation exists. If it didn't, you could easily right-click to add a translation, and hopefully even get a suggestion from Google Language Tools or your local dictionary. (btw, I understand that on the screen it's just called "Chinese", not "Mandarin"). Homunq 15:13, 27 March 2008 (EDT)

Will the translation features you create for Bityi be available in a library form for use in other programs? I could see Turtle Art, Etoys and my OpenSim project benefiting a lot from something like this!

Bobbypowers 21:04, 28 March 2008 (EDT)

I am not sure if they will be in a library included in Sugar, though I would argue for that option. Also, note that Turtle Art and Etoys (and, as I understand it, OpenSim), as graphical environments where user-defined functions are of secondary importance, already benefit substantially from more traditional l10n practices. However, there is no question that I would design my code to be portable. It would be necessary in logviewer, in pippy, and I would hope that it would get use in IDEs outside of the XO. Homunq 22:33, 28 March 2008 (EDT)

PL/1 is more workable (User:AlbertCahalan)

Since PL/1 does not reserve keywords, there is no problem with a collision between a variable name and a translated keyword. According to wikipedia's PL/1 article:

PL/I compiler also accepts variable names like key words (like IF, ELSE and THEN) and it uses the same symbol ('=') for checking equality of variables and for assignment. Something like this is accepted:

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF

This code is interpreted as: If variable 'if' has the same value of variable 'then' then assign to variable 'then' the value of variable 'else', otherwise assign to variable 'else' the value of variable 'if'.

Collisions in (Spanish?) are dealt with exactly the same way as collisions in English. This is not an issue. Homunq 08:33, 8 April 2008 (EDT)

the ghetto, realness, and mystery problems (User:AlbertCahalan)

At a very fundamental level, this idea is isolating. It is beneficial to be part of a larger community. This applies for getting help, looking at examples on the web, chatting with other programmers, sharing one's work, etc.

This is why good support for cut/paste (into/from English), switching back to English with a single-keystroke shortcut, and easy-to-use functionality for other apps are all key. This is intended to make all of the things you mentioned easier, not harder. From one big initial entry barrier, it breaks up the problem into two easy steps - learning programming in your own language, then learning the translation.

Think of it this way: which is harder, learning to program, or learning a new programming language? I know that I've learned more than one programming language the night before the job interview; and just relearning the keywords in English would be even easier than that. Yet I am still learning how to be a better programmer. And one of the lessons is, when you have a big problem, divide and conquer. Homunq 01:03, 8 April 2008 (EDT)

This idea is also sort of demeaning, suggesting that the kids are incapable of handling "real" tools. Programming isn't like carpentry, where "real" tools (which kids crave) can remove a limb or worse. Here, "real" tools are safe for kids.

There is nothing fake or crippled about this. This is as full-featured as python. Homunq 01:03, 8 April 2008 (EDT)

Translation adds an extra layer. The user gets stuck with hidden magic. What he sees is NOT reality. It is essential for a beginning programmer to learn that there is no magic; stuff works in a way that is dependable, reliable, and not insanely constructed. The computer does what it is told to do. There is no mystery or magic. There are no little critters (elves, leprechauns, gnomes, etc.) inside the computer making arbitrary decisions to confuse the programmer.

This is a legitimate concern. For instance, in the current design, if module A imports module B which imports module C, there are situations where module A could try to use a translated name from module C which was not declared as public in module B and thus is not available. Two solutions would be static analysis, or mandating that all public elements of C are available through B.

I am sensitive to this issue. Many of the design decisions (such as the refusal to change "is not" to "no es") are motivated by the desire for transparent simplicity. I believe that it is imperative that the results of this be intuitive and that it cause ZERO bugs in code it touches. I believe that this goal is possible. Homunq 01:03, 8 April 2008 (EDT)

better idea (User:AlbertCahalan)

Use a status bar (like the bottom of a typical web browser) to provide info. Do this for English too.

If the curser is on a "for" keyword, then you explain how a "for" loop works. You don't give some lame one-word translation. You give a sentence or two at minimum, and a bit of formal syntax.

I was going to do this with tooltips instead of a status bar, but yes, this is part of what I plan. I like your idea that it works for keywords too, not just with docstrings of identifiers. However, this is not a replacement for one-word translations. For one thing, without a translated view, the motivation and interface for adding new translations will be lacking. For another, this is fundamentally slower reading than keeping them inline. Homunq 08:33, 8 April 2008 (EDT)

Don't worry about the formal syntax being unreadable to beginners. First of all it is a critical thing to learn about. Second of all it is easy to learn by example. Third of all, this will be the only thing useful when the less-formal explanation is not available in the required translation.

Hey! Of course! Nobody is saying any different. This tool should be usable even by professional programmers. (Now I feel patronized!) Homunq 08:33, 8 April 2008 (EDT)

apertium

autotranslation tool?