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.ben...@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" <cjlhomeaddr...@gmail.com> wrote: >> >> 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 >> _______________________________________________ >> SLOBs mailing list >> sl...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/slobs _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel