[sugar] Develop activity (Oops...)

[Jameson "Chema" Quinn]

Hi, this is Jameson. I'm pretty much available afternoons in Guatemala
(GMT-6).

I pretty much agree with what Andrew said about i18n of the programming
language itself, but I have a slightly different point of view. I'm
interested in doing something that would be as useful as possible for
internationalization of programming itself, in both education and real-life,
*across* languages and platforms. I actually agree that OLPC and Python is
the coolest platform there is, and the right place to start this effort -
but I hope that whatever we do will be generalizable beyond that niche.

I want to get the UI right - just enough magic to do everything you want,
but not so much that it gets annoying. That means either being very intimate
with the editor's internal data structures, or being very bossy from outside
them. Either way, but especially in the latter case, I see that when you mix
dynamic changes of UI language (retranslation or detranslation on the fly),
dynamic changes in the translation dictionary (at the module level, of
course), and undo, things start to get complicated. I talked to some of the
AbiWord developers on IRC about their data structures, and they are
less-than-effusive about how robust their main text data structure is (their
file structure is XML, but their data structure does not have "end tag"
elements for many tags, so they have not been able to unit test that all
their code respects clean heierarchical structure).

This makes me continue to wonder if AbiWord is the right answer for the
editor widget for the Develop activity. Andrew has been very clear with me
that that is a done decision, because it will preserve a common UI and allow
the new collaboration functions to be used in Develop. Still, if it were up
to me, I'd like to consider both sides of that question. To do this right,
we may want something more made-to-order - and maybe the collaboration is
easier to add than it would be to hack AbiWord into the right shape.

....

I'm going to describe my vision for i18n below, as best I can. This includes
both user experience and some implementation, all mixed together, because
without at least considering implementation it would be too easy to wish for
the impossible. Go ahead and skip the rest of the message, if you want; this
is just my way of getting my thoughts down on paper, and giving y'all a
chance to read them before any phone call IF YOU WANT. In the below,
"Spanish" is my shorthand for "some language besides English".

On disk, you have .py files always in normal, (English-keywords) python.
Sitting next to this file is a .p4n (or whatever) file which has a
translation matrix for translating the identifiers of this file from English
to any number of other languages. This p4n will only NOT exist for files
written in English, with no translations. For files written in other
languages but without translations provided, the p4n will consist of solely
a preferred-language identifier (so that the interpreter knows what language
they're written in). If an English translation is added to the p4n, that
identifier is changed to English in the .py as well. Third languages cannot
be added before English. Other programs with the same preferred language
which load this module, automatically use the new English identifier based
on the p4n translation, even if they were last saved with the Spanish
identifier (before the p4n changed); to get this functionality, an
preferred-English .py which loads a preferred-Spanish module without
translations must use some new "import thisSpanishModule in Spanish"
terminology.

While editing, you see your preferred language for all code. No identifier
translation is performed on string literals (including docstrings) or most
comments. There is a simple, ReST-based markup to turn translation ON for
blocks or single words within comments. Also, a separate feature will
translate whole comments or docstrings at a time, not on a word-by-word
basis. There are menu items for "comment this out as code", "make the
English version of the selection into a string", and "make the Spanish
version of the selection into a string", as well as easy keyboard and menu
shortcuts for toggling the translation function on and off. Other than this,
the text behaves largely as if it only existed in the Spanish version.
Tooltips and context menus give easy, constant access to seeing or changing
the English translation of each identifier. Only actual code changes go in
the undo stack - not translation-related changes....

Cheers,
Jameson

On 8/4/07, Andrew L. Clunis <andrew at orospakr.ca> wrote:
>
> Ack, I hit the "Send" button as the "Save Draft" button!  Sorry
> about that, guys. :(
>
> Here is the rest of what I meant to say:
>
> Greetings all,
>
> A group of us are interested in getting to work on Develop activity.
>
> Here's what, as I understand it, people are working on:
>
> - code internationalisation.  Jameson and myself have been discussing
>   various means of achieving this lofty goal, see below;
> - version control (so kids can modify others' activities without
>   worrying about maintaining different copies of code, and providing
>   them with a means of sharing and merging any changes, etc.);
> - visual editing.  Mike Fletcher has been looking into Logo and
>   Smalltalk-like visual editing for python development.  Guido
>   has been looking into class reloading which would permit people to
>   modify the code in a running program, a necessary feature for visual
>   development;
>
> The current Develop source tree sitting on dev.laptop.org is now quite
> out of date and no longer runs.  I personally considered it a spike
> solution, a demonstration of what a simple version of Develop could look
> like.  I'm not even sure we'll reuse any code from that version.
>
> Here, although it is somewhat out of date, is the wiki page for Develop:
>
> http://wiki.laptop.org/go/Develop
>
> Regarding code i18n, I filed a bug on the OLPC track several months ago
> concerning docstring translation:
>
> http://dev.laptop.org/ticket/1075
>
> However, recently Jameson and I came to the conclusion that not only are
> docstring translations necessary, but so are identifier translations.
> Jameson and myself have been discussing several alternative methods:
>
> Method I:
> The programmer writes a python file in whatever language they want. They
> set this language in some sort of "base language" directive in the file,
> and then add translations for the identifiers to a matching '.pyt' (a
> gettext-like table, perhaps?) file.
>
> Method II:
> ... is the same as Method I, except that the base language is always
> English.  The code is presented to the user for editing in the language
> of their choice using these the human language equivalents from the .pyt
> file (and the .pyt files of any imported modules).  In order to preserve
> the reversible 1-1 nature of the translation step localized words which
> clash with English keywords or localized words from other libraries are
> given an alphanumeric prefix to distinguish them.  Although this
> approach is perhaps not quite as "utopian" as Method I, it has several
> pragmatic benefits: more translators will be available with English
> serving as a lowest common denominator (more people know Arabic and
> English and Portuguese and English than know both Arabic and
> Portuguese); with a common base language, exchange of code will also be
> easier in the international community.
>
> On top of that, there remains the question as to how and where to
> implement this logic.  Should it be a separate tool/library (possibly
> troublesome, because Python's dynamism means that the only thing that
> truly understands scope is the interpreter at runtime), or something
> inside the interpreter (harder to implement/maintain/get accepted into
> upstream)?
>
> This is such a drastic change, with potentially extensive consequences,
> that its development should involve the Python community.  It should
> clearly begin life as a PEP.
>
> I suggest that we have a live discusson on either IRC, a teleconference
> (I imagine that the folks at 1CC would be able to arrange a
> teleconference for us), or Skype (ew), and see where it takes us. There
> are a lot of really awesome ideas floating around, but I think we need
> to make this a coherent effort.  When are people available?
>
> The first step would be decide what Develop should be (at least for
> Gen1), and write our acceptance tests.
>
> Happy hacking!
>
> --
> Regards,
> Andrew Clunis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070804/0cbf26ac/attachment-0001.htm