[Sugar-devel] [SLOBS] [Localization] Translations

[Walter Bender]

Another hole in the i18n infrastructure is with our Javascript activities.
Maybe worth a GSOC project to shore it up.
On Feb 20, 2016 3:58 PM, "Chris Leonard" <cjlhomeaddress at gmail.com> wrote:

> 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
> _______________________________________________
> SLOBs mailing list
> SLOBs at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/slobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160220/0bb63b29/attachment-0001.html>