[sugar] Develop activity (Oops...)

Mike C. Fletcher mcfletch
Mon Aug 6 22:44:52 EDT 2007

Andrew L. Clunis wrote:
> 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:
My idea for internationalization is as follows:

    * assume a progression from graphical, to local language, to
      subset-of-English for those who want to become proficient programmers
          o provide tools that let the children put blocks together in a
            reasonably constrained environment
          o show the children what putting the blocks together does in
            their native language
          o let the children edit the source-code in their own language
            to start with
          o allow the children to flip back and forth between
            native-language keywords and English keywords
          o support the children in translating to/from English for code
            they want to publish
    * for each component in the programming language (e.g. for loops,
      while loops, variable assignment, etceteras)
          o provide a visual form which implies the operation and allows
            for drag-and-drop operation
          o provide a canonical translation (which is also reserved
            words/symbols/punctuation in the native language)
          o provide a localized description of the operation (preferably
            with some simple lessons on usage, maybe some demos with
            sample code for each one, hook these up in the UI so that
            the child can explore the idea behind the operation)
          o when used, show the (standard) Python code generated by the
    * for the special case of identifiers in the user's
      (non-ascii-compatible) language
          o store all identifiers as transcoded[1] ascii identifiers in
            the source code on initial writing (before translation)
          o display all identifiers as their non-transcoded versions in
            the UI
          o store the translation matrix in a separate file (to allow
            for multiple translations)
    * allow for a localization option that also translates keywords and
          o uses the canonical translation
          o allow the user to input any Unicode identifier as an
            identifier which is not in the canonical translation
          o typing in the localized version of "for" or "class" would
            insert "for" and "class" into the stored code
    * identifiers/keywords which have no translations are presented in
      ascii (i.e. all current Python code would show up in English,
      potentially with keywords in Arabic or Thai)
    * have a tool that allows for querying e.g. BabelFish to get
      translations from/to a given language for given identifiers
          o allow for exporting any pure-ascii translation (e.g.
            English) to the base file (updating the translation tables
            as we do so)
          o should provide both localization and internationalization
            support (i.e. the same tool would allow the country to load
            a common Python module and produce a translation for it)

Regarding source-code-control:

    * I'd like to have bzr integrated into the IDE with reasonably
      fine-grained automated commits (universal undo/redo) along with
      annotated commits (more like a regular "save" operation)

My preference would be that we get a few spike tests under way that show 
that a given internationalization approach will work *with the current 
Python*, also to test out AbiCollab as an editor, integration of an SCC 
system into an editor in an intuitive manner, parsing and presentation 
of Python code as visual programming operations (and visual editing to 
produce new Python code), and generally any parts of the project that 
are "research".  We can assume that this code will be thrown away and 
that we'll just use the ideas and results to write the actual IDE.

For discussions, we should probably set up a mailing list, IRC and phone 
conversations tend to be a bit ephemeral for designing things IMO.  
Still, I'm available most days for IRC or phone conversations with a bit 
of notice.

Enjoy yourselves,

[1] by transcoded, I mean using some stable, predictable mechanism that 
always converts the same e.g. Arabic word to the same sequence of ascii 
characters, a normalized token that always represents the same Arabic 
word, but has no necessary English representation.

  Mike C. Fletcher
  Designer, VR Plumber, Coder

More information about the Sugar-devel mailing list