On Fri, Jul 15, 2011 at 11:39 AM, Chris Leonard <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
