<p dir="ltr">Another hole in the i18n infrastructure is with our Javascript activities. Maybe worth a GSOC project to shore it up.</p>
<div class="gmail_quote">On Feb 20, 2016 3:58 PM, "Chris Leonard" <<a href="mailto:cjlhomeaddress@gmail.com">cjlhomeaddress@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Comments included in-line below<br>
<br>
On Sat, Feb 20, 2016 at 3:35 AM, Tony Anderson <<a href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a>> wrote:<br>
> As I understand the issue: SugarLabs has some funds available to support<br>
> translation of Sugar. At the SLOBs meeting, it was proposed that<br>
> SugarLabs recruit a 'translation manager', a possibly paid position. One<br>
> question is the job description for this role.<br>
<br>
For quite some time (starting in 2008, as I recall) under the "title"<br>
of Translation Team Coordinator I worked in that role (unpaid) and I<br>
can certainly help in fleshing out details.  From 2008 - 2013 I was<br>
able to dedicate adequate time to both technical aspects of i18n<br>
(Pootle infrastructure and i18n advocacy/assistance to developers) as<br>
well as L10n (localization mailing list, maintain L10n wiki pages,<br>
support to new language communities, recruiting new localizers, etc.).<br>
The good news (for me) is that in 2013 an extended period of<br>
unemployment ended, the bad news is that I found myself unable to<br>
continue to provide sufficient support to the community for several<br>
reasons (technical issues with Pootle version migration as well as<br>
development migration to github beyond my scope to manage alone) and a<br>
slump in L10n activity by the community (perhaps in part because of<br>
insufficient efforts to organize and rally the troops).<br>
<br>
My employment situation has stabilized somewhat and I would like to<br>
continue to contribute to the i18n/L10n effort, but as many have<br>
experienced throughout the financial crisis, my new employment<br>
circumstances are only providing a fraction of the income I had made<br>
in the past, so my "free time" is subject to the demands of pursuing<br>
supplemental income.  I have done some work in support of Sugar Labs<br>
since (e.g. Awajún glibc locale drafting), for which I might be<br>
compensated for my time and effort from the TripAdvisor grant based on<br>
a template agreement worked out with the SFC and the prior approval of<br>
the Sugar Labs Oversight Board.  That is essentially piece-work, a<br>
pre-agreed amount for a pre-agreed deliverable (a committed glibc<br>
locale), I have not yet actually drawn any TripAdvsor funds for this<br>
purpose, but I may make such requests in future (assuming necessary<br>
pre-approvals are granted).<br>
<br>
<br>
> I would like to review the translation process:<br>
><br>
> Translation has two separate parts: internationalization(I18n) and<br>
> localization (L10n).<br>
><br>
> The Sugar-Devel team is responsible for I18n (preparing the framework to<br>
> support localization) and the community is responsible for L10n - providing<br>
> translations (by default, from English) to other languages.<br>
<br>
Note: English is the original language of many activities, but there<br>
are also many written first in Spanish, working with developers to<br>
make Spanish-originating activities capable of being translated to<br>
other languages (via an English bridge)  is an issue requiring<br>
attention.<br>
<br>
L10n leadership tasks:<br>
<br>
Monitoring new activity development and advocating for i18n of code<br>
(gettext formatting).<br>
<br>
Setting up new languages for availability in Pootle.<br>
<br>
Reaching upstream to create glibc locales for new languages.<br>
Necessary for them to be selectable languages in Linux-based systems.<br>
<br>
Requesting github permissions for the pootle git-hub user (to enable<br>
pull of new templates, push of completed translations).<br>
<br>
Monitoring Pootle for currency of templates, update of templates on<br>
existing languages, commit of new translations.  Tasks technically the<br>
responsibility of individual language team leaders, but in practice<br>
needing an overseer on behalf of all languages.<br>
<br>
> The immediate focus is on using Pootle as the I18n framework with<br>
> translators providing the localization.<br>
><br>
> Let's divide the languages into three groups:<br>
><br>
>     - English (the base language)<br>
><br>
>     - Mediums of instruction (languages used at deployments as a common<br>
> language where more than one language is spoken)<br>
><br>
>     - Local language (languages used by students at home)<br>
<br>
English is not always the base language of our South Amreican activity<br>
developers, as mentioned, this requires some careful thought and<br>
action to make these Spanish-originating activities more widely<br>
available in other languages.<br>
<br>
Fortunately, the Pootle system can take the ongoing Spanish<br>
translation of an English-originating activity and show it to<br>
indigenous language translators (e.g. for Spanish to<br>
Aymara/Quechua/Guarani/Awajún L10n where localizers are primarily<br>
bilingual, but not English-speaking).  Similarly, French translations<br>
(if present in Pootle) can facilitate L10n into the indigenous<br>
languages of Francophone Africa.  This helps us create bridges to<br>
indigenous languages by localization into a "language-of-instruction",<br>
e.g. Spanish, French) early in the development cycle.<br>
<br>
> When a new Sugar release is made, the Pootle English master files should be<br>
> a part of the release. Sugar development should ensure that Pootle files are<br>
> available for all software in the release.<br>
<br>
Actually, POT template files (Pootle English master files) need to be<br>
generated early in the development cycle, well before release and must<br>
be updated regularly as strings change in source. Those updated<br>
templates need to be synched on Pootle and made available as soon as<br>
possible.<br>
<br>
Typically there is a "string-freeze" declared for several weeks prior<br>
to release allowing localizers time to do their work in a stable<br>
background.  The release itself includes all localizations made up to<br>
the release date (as PO files).<br>
<br>
> Sugar may want to provide localization for one or more mediums of<br>
> instruction (e.g. Spanish, French, Arabic). Since this would imply that<br>
> files for these localizations are available at release, SugarLabs should<br>
> decide which, if any, of these languages are to be supported.<br>
<br>
Agreed that a core set of languages should be completed prior to<br>
release, not entirely sure about declaring "supported languages", we<br>
should release what we have to encourage further work.<br>
<br>
> Deployments (or deployment sponsors) may need localization of Sugar for<br>
> specific local languages (e.g. Kinyarwanda, Haitian Creole,<br>
> Sotho, Xhosa). I believe these localizations are most likely to come from<br>
> Sugar/XO deployments where the language is used. Some would<br>
> seem to be a given - Cambodian.<br>
<br>
You would think so, and we can talk about Khmer (Cambodian) at some<br>
other time, but the reality is that you run into odd things more often<br>
than you would think, sometimes for the reasons you mention below<br>
(language-of-instruction), sometimes it is more complex than that.<br>
<br>
> However, strange things happen. For example, Rwanda is one of the largest<br>
> and most active deployments. However, there is no Kinyarwanda localization.<br>
> The reason is probably that in Rwanda the OLPC laptops are part of a path to<br>
> English. They are introduced at the fourth grade, the first year when the<br>
> required medium of instruction is English. While Kinyarwanda is a subject in<br>
> grades 4-6, the priority is using the XOs to facilitate learning in English,<br>
> Mathematics, and Science.<br>
><br>
> I believe that the Pootle files are distributed and installed with the<br>
> released image. This should mean that XO users who know English and the<br>
> native language could provide the localization. Once it is complete, the<br>
> files can be installed on the XOs at the deployment and the localization<br>
> would be available at the deployment. Ideally, localization would be done by<br>
> the students as a learning activity. For example, in Rwanda, localization to<br>
> Kinyarwanda would help students a lot in learning English. Sameer Verma has<br>
> provided an excellent tutorial on how to do localization which could be<br>
> included in the Sugar image.<br>
<br>
Oh, it were only that easy...  In reality, the technical means for<br>
"bootstrapping" localization at the local level do not exist.  That is<br>
a large and complex topic that I would behappy to discuss further, at6<br>
length.  One issue ismaking it possible to touch and change PO files<br>
on local machines (I do have some thoughts), another is capturing that<br>
local work back at the central Pootle server for the benefit of<br>
others.<br>
<br>
What you describe is an ideal situation that is not currently possible<br>
(local bootstrapping), in reality we need the L10n to happen on our<br>
centralized Pootle server to get them back out.<br>
<br>
> So, the translation manager would be responsible to identify deployments<br>
> which use specific local languages and work with them to organize 'L10n'<br>
> days for new releases. The translation manager should then interface with<br>
> Pootle to submit the localization files for review and acceptance by Pootle.<br>
><br>
> Sugar development could review Sugar (Python) activities to see if they<br>
> support Pootle and attempt, eg. through GSOC, to get activities upgraded to<br>
> implement Pootle and to include a base set of English Pootle files.<br>
><br>
> Perhaps OLPC France could be tasked to provide French localization as part<br>
> of the release process. For Spanish, perhaps Sebastian Silva (Peru) or Plan<br>
> Ceibal could accept responsibility for Spanish.<br>
><br>
> Meanwhile, being on the other side of the world, I have not made progress on<br>
> getting a committee to help put their two cents in on this. Clearly, this<br>
> scenario must be reviewed for Floss Manuals, Sugarizer, and other SugarLabs<br>
> products which don't fit in this one. Also, how to provide localization of<br>
> IIAB-2 content is, at least, a formidable question.<br>
><br>
> Tony<br>
><br>
><br>
> _______________________________________________<br>
> Localization mailing list<br>
> <a href="mailto:Localization@lists.laptop.org">Localization@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/localization" rel="noreferrer" target="_blank">http://lists.laptop.org/listinfo/localization</a><br>
_______________________________________________<br>
SLOBs mailing list<br>
<a href="mailto:SLOBs@lists.sugarlabs.org">SLOBs@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/slobs" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/slobs</a><br>
</blockquote></div>