[IAEP] Priority languages to translate Sugar

[Chris Leonard]

On Thu, Jul 14, 2016 at 10:50 PM, Caryl Bigenho <cbigenho at hotmail.com> wrote:
> Hi Folks…
>
> Although it may seem a nice idea to propose translations into many
> languages, at this time I feel translations should be restricted to those
> language groups that have the XO hardware to use Sugar, like those in Peru
> and Haiti. Trying to add some of the Native American languages, where the
> hardware is not available is a futile exercise.

I generally agree with prioritizing XO deployment languages.  In
addition to Peru/Haiti, we should not forget the OLPC Mexico  mother
tongues efforts as potentially being worthy of financial support.
They have done some excellent work on a volunteer basis already, a
trickle of funding might prompt more work.

At the same time, I think Sugar is hardware independent and we should
not discount the possibility of finding someone interested in using it
in some non-XO form (SoaS, Linux packages, etc.) in the context of a
language preservation effort in a first world (not
hardware-constrained) setting such as North American or Australian
First Nations languages.

> At the same time, we need an increased effort to work on the porting of the
> top Sugar Activities to Sugarizer. That is where we can reach children and
> young people everywhere because the needed hardware is already in their
> hands.
>
> A recent conversation I had with Samson Goddy in Nigeria went something like
> this:
>
> C: What computers will you be using with the students?
> S: Infinity
> C: How many will you have?
> S: Two
> C: But do most of them have smartphones?
> S: Yeah.
>
> He agrees with me that we should be supporting Sugarizer so we can take
> advantage of the hardware the students already have.
>
> So, along with these comments, I submit:  Simultaneous translation of Sugar
> Activities to their Sugarizer counter-parts is something that should be
> taken seriously.

Indeed it should and will be.  The trick to work out is the i18n/L10n
toolchain integration (Sugar uses GNU gettext toolchain into and out
of Pootle where Sugarizer needs a different toolchain  (being
JavaScript).  I'm in contact with a Pootle-using JavaScript-heavy
project (pretty cool stuff actually http://www.dhis2.org) and looking
to learn some lessons from their experimentation with various
JS-oriented tools.  Once we sort out how to get the JavaScript strings
in and out of the repo and Pootle in PO or other supported format we
can try to leverage all of the existing L10n work to minimize
"re-translation" of common strings.

> How many of you folks can do JavaScript, HTML5, and CSS? Those are the
> skills needed to do this. You can get these skills online if you want to
> help. Please contact me and Lionel Laske if you are willing to help with
> this.
>
> BTW… SOS (Sugar On A Stick) is not really a viable option.  I have tried it
> with teachers in a workshop and they found it too complicated to use and
> were afraid of infecting their computers with a virus. It was a great idea,
> 5 years ago. But, it is time to move on and Sugarizer is the direction of
> the future.
>
> Caryl


cjl