[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
usage
* 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
builtins
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,
Mike
[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
http://www.vrplumber.com
http://blog.vrplumber.com
More information about the Sugar-devel
mailing list