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

[Chris Leonard]

For javascript L10n, start with these links:

http://www.localeplanet.com/

https://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/

cjl

On Sat, Feb 20, 2016 at 7:14 PM, Walter Bender <walter.bender at gmail.com> wrote:
> 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