ndoiron at mapmeld.com
Sat Feb 20 21:05:50 EST 2016
Hi everyone... I'm in the Unicode Consortium so I'm happy to help work out
i18n tech issues in our Sugary ecosystem.
On the original point, I agree with Tony that it would be valuable to hire
an i18n/l10n point person. This funding has been around for a while without
any one person responsible for shipping it. You might want additional
support or conversation, from Open Technology Fund, Localization Lab, or
Adobe, for the position and workshops.
I'd like to see some people narrowing down where they know we need a
translation. If you can say *I know a teacher who wants this *or* we use
this activity in Language A and want it in Language B, *we should be able
to deliver that. There are interesting politics and discussions here, but
the funding is for translating and not for not-translating.
Technology side: it matters if you're translating Sugar, core Sugar
activities, additional activities, or Sugarizer. This is essential because
they're different programs at different levels of completeness, in use by
- Sugar and core activities have been ready from the beginning using
gettext and accepting translations on Pootle. I don't see that changing,
unless we want to use GitHub to reach younger developers.
- Additional activities: you would need to look on a case-by-case basis, to
see if text was hardcoded. Also you need special attention if language is
part of the activity, as in typing tutors, flipbooks, or crossword puzzles.
Tangential blog post:
- I did some research, and Sugarizer has three translation files, including
this master file: https://github.com/llaske/sugarizer/blob/master/locale.ini
Other web-based activities should use Polyglot.js from Airbnb; it's cool.
On Sat, Feb 20, 2016 at 2:57 PM, Caryl Bigenho <caryl at laptop.org> wrote:
> Hi Folks
> Here are some thoughts on Internationalization and Localization...
> 1) The most important consideration is what the local people really want…
> not what we think they want or think they should want. Maybe they are happy
> with English. On the other hand, maybe they would prefer their own local
> language (or dialect). Don't assume anything. Don't ask just one person.
> Ask enough people to get a genuine consensus.
> 2) Using students to provide localization is an excellent educational
> activity. However, it needs to be overseen by an "expert" (maybe their
> teacher) to insure it is both accurate and appropriate before submission to
> 3) The Spanish of Mexico is slightly different from the Spanish of Peru
> and/or the Spanish of Argentina (etc., etc,, etc). Using students for
> localization could be helpful here and, I'm sure for other languages.
> 4) Again, for Spanish… why not look to our largest Sugar deployment,
> Uruguay, for enlisting students to help? One of the SLOBs (José Miguel
> García) is Uruguayan as is super-star teacher Rosamel Ramirez.
> 5) Applying to GSOC for help in any aspect with this work seems like a "no
> brainer" but the deadline for applications for 2016 was yesterday! [image:
> Date: Sat, 20 Feb 2016 14:44:28 -0500
> Subject: Re: Translations
> From: sora at unleashkids.org
> To: holt at laptop.org
> CC: tony_anderson at usa.net; tim at timmoody.com; ndoiron at mapmeld.com;
> caryl at laptop.org; sverma at sfsu.edu; sugar-devel at lists.sugarlabs.org;
> localization at lists.laptop.org; walter at sugarlabs.org;
> slobs at lists.sugarlabs.org
> The success of the first translation will depend on how established /
> knowledgeable the local community is. Reviewing the first round of Haitian
> Creole translations, which I think were done by volunteers, you notice some
> obvious problems, like inconsistent terms. I've personally seen students
> and teachers become confused by these issues when using the computer. They
> keep using it anyway, but it definitely affects the user experience. Now,
> hopefully the attitude of "this is the wrong way to say it" will inspire
> the next round of volunteers to do a better translation - but that's a big
> assumption to make.
> I think it's important to remember that in many of these places, language
> ideology is something communities are working through. All the research
> supports literacy / learning in the mother-tongue language, but in many
> places the languages kids speak at home are seen as inferior to the ones
> they learn in school - not just because the one they learn in school is
> more widely-spoken, but because of myths that the language spoken at home
> is not "advanced" enough to study something like science / math / tech.
> So, basically, if the first translation is not adequate, there may not be
> a second translation. People may decide "This language is not adequate for
> using the computer" instead "Our translation is not adequate; let's make it
> On Sat, Feb 20, 2016 at 7:51 AM, Adam Holt <holt at laptop.org> wrote:
> Excellent food for thought Tony!
> +Sora, Tim, Nick, Caryl to see if they have ideas/suggestions below?
> On Feb 20, 2016 3:35 AM, "Tony Anderson" <tony_anderson at usa.net> wrote:
> As I understand the issue: SugarLabs has some funds available to support
> translation of Sugar. At the SLOBs meeting, it was proposed that
> SugarLabs recruit a 'translation manager', a possibly paid position. One
> question is the job description for this role.
> I would like to review the translation process:
> Translation has two separate parts: internationalization(I18n) and
> localization (L10n).
> The Sugar-Devel team is responsible for I18n (preparing the framework to
> support localization) and the community is responsible for L10n - providing
> translations (by default, from English) to other languages.
> The immediate focus is on using Pootle as the I18n framework with
> translators providing the localization.
> Let's divide the languages into three groups:
> - English (the base language)
> - Mediums of instruction (languages used at deployments as a common
> language where more than one language is spoken)
> - Local language (languages used by students at home)
> When a new Sugar release is made, the Pootle English master files should
> be a part of the release. Sugar development should ensure that Pootle files
> are available for all software in the release.
> Sugar may want to provide localization for one or more mediums of
> instruction (e.g. Spanish, French, Arabic). Since this would imply that
> files for these localizations are available at release, SugarLabs should
> decide which, if any, of these languages are to be supported.
> Deployments (or deployment sponsors) may need localization of Sugar for
> specific local languages (e.g. Kinyarwanda, Haitian Creole,
> Sotho, Xhosa). I believe these localizations are most likely to come from
> Sugar/XO deployments where the language is used. Some would
> seem to be a given - Cambodian.
> However, strange things happen. For example, Rwanda is one of the largest
> and most active deployments. However, there is no Kinyarwanda localization.
> The reason is probably that in Rwanda the OLPC laptops are part of a path
> to English. They are introduced at the fourth grade, the first year when
> the required medium of instruction is English. While Kinyarwanda is a
> subject in grades 4-6, the priority is using the XOs to facilitate learning
> in English, Mathematics, and Science.
> I believe that the Pootle files are distributed and installed with the
> released image. This should mean that XO users who know English and the
> native language could provide the localization. Once it is complete, the
> files can be installed on the XOs at the deployment and the localization
> would be available at the deployment. Ideally, localization would be done
> by the students as a learning activity. For example, in Rwanda,
> localization to Kinyarwanda would help students a lot in learning English.
> Sameer Verma has provided an excellent tutorial on how to do localization
> which could be included in the Sugar image.
> So, the translation manager would be responsible to identify deployments
> which use specific local languages and work with them to organize 'L10n'
> days for new releases. The translation manager should then interface with
> Pootle to submit the localization files for review and acceptance by Pootle.
> Sugar development could review Sugar (Python) activities to see if they
> support Pootle and attempt, eg. through GSOC, to get activities upgraded to
> implement Pootle and to include a base set of English Pootle files.
> Perhaps OLPC France could be tasked to provide French localization as part
> of the release process. For Spanish, perhaps Sebastian Silva (Peru) or Plan
> Ceibal could accept responsibility for Spanish.
> Meanwhile, being on the other side of the world, I have not made progress
> on getting a committee to help put their two cents in on this. Clearly,
> this scenario must be reviewed for Floss Manuals, Sugarizer, and other
> SugarLabs products which don't fit in this one. Also, how to provide
> localization of IIAB-2 content is, at least, a formidable question.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel