Offer from gnome-i18n team

[Chris Leonard]

On Fri, Jul 15, 2011 at 11:39 AM, Chris Leonard
<cjlhomeaddress at gmail.com> wrote:
> Dear OLPC devel,
>
> I have been trying to build links with upstream L10n communities that
> translate the L10n bits we need and I recently sent this message to
> gnome-i18n:
>
> http://mail.gnome.org/archives/gnome-i18n/2011-July/msg00041.html


The nature of GNOME's offer is much clearer to me now and it is
elegantly simple and useful.  It will have no impact on OLPC build
process, other than hopefully promoting higher rates of upstream L10n
coverage.

The essence of the offer is to name a release set upstream as 'OLPC",
see it on the list here:

http://l10n.gnome.org/releases/

Claude Paroz had granted me the priv to maintain this list through a
web-admin interface on that site, What I do is to go to a module and
tag a particular build of it as belonging to the OLPC release set
through a simple pulldown web-page.

******What are the implications of this for the OLPC release manager?

Essentially,

http://l10n.gnome.org/releases/olpc/

will give a quick dashboard snapshot of the level of L10n coverage of
upstream packages we inherit from GNOME.  Given that OLPC is shipping
dual-boot GNOME images, the level of L10n coverage *should* be a
status that is tracked.   The release manager should engage with the
L10n community at the earliest stages to provide ample time for
increasing L10n coverage (both locally and upstream).

I'm happy to see that this is included on Daniel's planning for future releases
http://wiki.laptop.org/go/User:DanielDrake/11.3.0_goals

This release coordination with the L10n community will necessary
include maintaining a current "release set" tagging upstream (e.g.
this will change when we eventually move to gtk3+ and PyGi).

******What are the implications of this for the L10n community?

Quite simply, this is a far superior (and always up-to-date version)
of the GNOME package tracking I attempted to do at:

http://translate.sugarlabs.org/projects/upstream_l10n/

By going upstream to
http://l10n.gnome.org/releases/olpc/

Localizers can quickly identify the strings of interest to OLPC and
focus on those.


I think one of the critical elements of OLPC's reality is that often
the languages of most interest to us are among those that have the
smallest on-line L10n communities and so special efforts are required
(Dari, Pashto, Kreyol, Kinyarwanda, etc.).  In particular, we need to
pay attention to the upstream bits we need, and can't expect our
localizers to find their way around the upstream without a clear trail
blazed.  It's a jungle up there.

Admittedly, many deployments are happy to have English as the language
of instruction, which takes some of the urgency out of L10n into local
langs; however, I philosophically believe that our aspirations should
be higher than that.  I strongly believe that OLPC staff should strive
to do a better job of leveraging their local contacts to drive L10n in
the local languages of it's deployment areas.  It should basically be
an element of "pre-sales" preparation and planning, and not an
afterthought.

cjl