[Sugar-devel] [Localization] Translations

[Chris Leonard]

Comments included in-line below

On Sat, Feb 20, 2016 at 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.

For quite some time (starting in 2008, as I recall) under the "title"
of Translation Team Coordinator I worked in that role (unpaid) and I
can certainly help in fleshing out details.  From 2008 - 2013 I was
able to dedicate adequate time to both technical aspects of i18n
(Pootle infrastructure and i18n advocacy/assistance to developers) as
well as L10n (localization mailing list, maintain L10n wiki pages,
support to new language communities, recruiting new localizers, etc.).
The good news (for me) is that in 2013 an extended period of
unemployment ended, the bad news is that I found myself unable to
continue to provide sufficient support to the community for several
reasons (technical issues with Pootle version migration as well as
development migration to github beyond my scope to manage alone) and a
slump in L10n activity by the community (perhaps in part because of
insufficient efforts to organize and rally the troops).

My employment situation has stabilized somewhat and I would like to
continue to contribute to the i18n/L10n effort, but as many have
experienced throughout the financial crisis, my new employment
circumstances are only providing a fraction of the income I had made
in the past, so my "free time" is subject to the demands of pursuing
supplemental income.  I have done some work in support of Sugar Labs
since (e.g. Awajún glibc locale drafting), for which I might be
compensated for my time and effort from the TripAdvisor grant based on
a template agreement worked out with the SFC and the prior approval of
the Sugar Labs Oversight Board.  That is essentially piece-work, a
pre-agreed amount for a pre-agreed deliverable (a committed glibc
locale), I have not yet actually drawn any TripAdvsor funds for this
purpose, but I may make such requests in future (assuming necessary
pre-approvals are granted).


> 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.

Note: English is the original language of many activities, but there
are also many written first in Spanish, working with developers to
make Spanish-originating activities capable of being translated to
other languages (via an English bridge)  is an issue requiring
attention.

L10n leadership tasks:

Monitoring new activity development and advocating for i18n of code
(gettext formatting).

Setting up new languages for availability in Pootle.

Reaching upstream to create glibc locales for new languages.
Necessary for them to be selectable languages in Linux-based systems.

Requesting github permissions for the pootle git-hub user (to enable
pull of new templates, push of completed translations).

Monitoring Pootle for currency of templates, update of templates on
existing languages, commit of new translations.  Tasks technically the
responsibility of individual language team leaders, but in practice
needing an overseer on behalf of all 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)

English is not always the base language of our South Amreican activity
developers, as mentioned, this requires some careful thought and
action to make these Spanish-originating activities more widely
available in other languages.

Fortunately, the Pootle system can take the ongoing Spanish
translation of an English-originating activity and show it to
indigenous language translators (e.g. for Spanish to
Aymara/Quechua/Guarani/Awajún L10n where localizers are primarily
bilingual, but not English-speaking).  Similarly, French translations
(if present in Pootle) can facilitate L10n into the indigenous
languages of Francophone Africa.  This helps us create bridges to
indigenous languages by localization into a "language-of-instruction",
e.g. Spanish, French) early in the development cycle.

> 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.

Actually, POT template files (Pootle English master files) need to be
generated early in the development cycle, well before release and must
be updated regularly as strings change in source. Those updated
templates need to be synched on Pootle and made available as soon as
possible.

Typically there is a "string-freeze" declared for several weeks prior
to release allowing localizers time to do their work in a stable
background.  The release itself includes all localizations made up to
the release date (as PO files).

> 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.

Agreed that a core set of languages should be completed prior to
release, not entirely sure about declaring "supported languages", we
should release what we have to encourage further work.

> 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.

You would think so, and we can talk about Khmer (Cambodian) at some
other time, but the reality is that you run into odd things more often
than you would think, sometimes for the reasons you mention below
(language-of-instruction), sometimes it is more complex than that.

> 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.

Oh, it were only that easy...  In reality, the technical means for
"bootstrapping" localization at the local level do not exist.  That is
a large and complex topic that I would behappy to discuss further, at6
length.  One issue ismaking it possible to touch and change PO files
on local machines (I do have some thoughts), another is capturing that
local work back at the central Pootle server for the benefit of
others.

What you describe is an ideal situation that is not currently possible
(local bootstrapping), in reality we need the L10n to happen on our
centralized Pootle server to get them back out.

> 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.
>
> Tony
>
>
> _______________________________________________
> Localization mailing list
> Localization at lists.laptop.org
> http://lists.laptop.org/listinfo/localization