184
edits
Changes
Jump to navigation
Jump to search
Very rough draft of report to SLOBs (due for March meeting)
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.
<blockquote>
"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
</blockquote>
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 [[http://pootle.translatehouse.org/]] server as the means of distributing localizations [[http://translate.sugarlabs.org]]
<blockquote>
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
</blockquote>
Let's divide the languages into three groups:
- English (the base language)
<blockquote>
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
</blockquote>
- 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)
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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). [[
<blockquote>
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
</blockquote>
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:
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
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.
<blockquote>
"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
</blockquote>
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 [[http://pootle.translatehouse.org/]] server as the means of distributing localizations [[http://translate.sugarlabs.org]]
<blockquote>
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
</blockquote>
Let's divide the languages into three groups:
- English (the base language)
<blockquote>
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
</blockquote>
- 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)
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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.
<blockquote>
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
</blockquote>
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). [[
<blockquote>
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
</blockquote>
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:
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>
<blockquote>
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
</blockquote>