Comments included in-line below On Sat, Feb 20, 2016 at 3:35 AM, Tony Anderson <tony_ander...@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 > localizat...@lists.laptop.org > http://lists.laptop.org/listinfo/localization _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel