This project should go beyond the state of the art in language tools. Just localizing all the software, and having a dictionary, is not enough - many of the users will be bilingual between an indigenous and a colonial language, and it will be impossible to localize to all possible indigenous languages before shipping. Thus, the laptops themselves should have localization support and language-learner support, ideally built into every application (!). Moreover, you do NOT want an impossible fragmentation of commands/error messages to make tech support impossible, so ideally as part of the same effort you make the "canonical" English version accessible for when tech support is needed. The same arguments apply to any source code and/or programming activities included, which is why you need a source-code editor with transparent native-language display.
 One idea
Pressing the "view source" key is already planned to bring up a dialog of "Do you want to edit or just browse". While this dialogue is not an ideal user experience (why not just let them start editing if they want to) it is true that initializing a new branch of version control is not desirable if they just want to browse. Anyway, since the dialogue is already there, it could have a third option of "edit application text" (strings) which let the user do localization work. This would bring up a table which would always have more than two columns, with obvious ways to "pick" the language represented by the third column from a list which is pre-sorted to have the country's main languages at the top. The table would ideally be prescrolled to the last dialogue (if any) or the command in the undo stack (if not), and would offer suggestions from a dictionary when appropriate.
Homunq 04:08, 28 July 2007 (EDT)