Difference between revisions of "Translation Proposal"

From Sugar Labs
Jump to: navigation, search
Line 67: Line 67:
Let's divide the languages into three groups:
Let's divide the languages into three groups:
    - English (the base language)
* English (the base language)
Line 77: Line 77:
    - Mediums of instruction (languages used at deployments as a common language where more than one language is spoken)
* 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)
* Local language (languages used by students at home)

Revision as of 03:38, 21 February 2016

SugarLabs needs a Localization delegate. The purpose of this proposal is to document the current Internationalization/Localization process and to define the role of the Localization delegate in that process. Some proposals for expansion/modification of the process are included.

Chris Leonard is arguably the incumbent Localization delegate:

Note: this title needs comment. The 'governance' page suggests that this position should be a delegate and not a co-ordinator since SLOBs cannot name a co-ordinator. I chose localization because I believe I18n (creating the framework and base) is the responsibility of sugar-devel and localization is a community responsibility.

"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)." cjl

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 current process is based on Pootle [[1]] server as the means of distributing localizations [[2]]

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

Let's divide the languages into three groups:

  • English (the base language)

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

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

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

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

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.

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

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 become the base for a guide to be included in the release (e.g. as an xol file). [[

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

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.

Other comments:

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

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

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

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

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: Emoji] - Caryl

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

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 better."' Sora

Another hole in the i18n infrastructure is with our Javascript activities. Maybe worth a GSOC project to shore it up. - Walter

For javascript L10n, start with these links:

<a href=http://www.localeplanet.com/></a>

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