Announcing the development of OLPC OS 12.1.0

[Chris Leonard]

On Thu, Mar 15, 2012 at 11:26 AM, Daniel Drake <dsd at laptop.org> wrote:
> Hi,
>
> We have now formalised the plan and schedule for our first major OS
> release of the year, 12.1.0, so it is time to announce it:
>
> http://wiki.laptop.org/go/12.1.0
> http://wiki.laptop.org/go/12.1.0/Release_plan
>
> (we had actually already started development a few months ago, but did
> not have all the details in place around the release process and
> schedule until now)
>
> As described in the release plan, we are currently in open development
> until May 7th - all features and invasive changes need to land in
> relatively-stable state before that date. We will then follow with a
> 4-week bug-fixes-only period, followed by a 4-week
> regression-fixes-only period, followed by the release on July 2nd.
>
> I will act as the release manager, and Peter Robinson will continue
> making and publishing the development builds throughout the
> development phase.
>
> Our latest development build, version 4, is somewhat broken (e.g. no
> networking, fails to boot on XO-1) but we will release a new build in
> the next few days that will make things a lot more usable. We do not
> have ARM builds, but we expect them to arrive shortly - the F17-on-ARM
> efforts are progressing rapidly, we're just a few packages away.
>
> Your continued feedback is appreciated: we are looking to draw in
> testing, bug reports and development efforts from the community,
> starting now :)
>
> Thanks!
> Daniel

I would like to collaborate with a package-savvy developer to try to
do a better job of identifying upstream L10n strings (and processes)
that we may want to know about, based on the packages.txt file

I have previously taken a pass through the packages.txt files on
earlier OLPC releases seeking to identify the upstream strings that we
would want localized for a "fully localized" release (not just the
Sugar UI, but including the underlying Gnome and Fedora software).  I
have identified strings on the Gnome Damned Lies erver, the Fedora
Transifex instance and the Translation Project site (as well as
Scratch's Pootle instance).

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

This effort has had some tangible results.  We have raised awareness
of Sugar / OLPC needs with upstream projects through steps like the
creation of an OLPC "release set" on the Gnome Damned Lies translation
tracking system.

http://lists.laptop.org/pipermail/devel/2011-July/032562.html

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

I have no direct evidence that this has specifically resulted in any
upstream language team prioritizing OLPC required L10n over other
packages, but I have communicated requests for such a prioritization
on the gnome-18n list and had a number of conversations with Gnome
upstream team members that are supportive of the Sugar / OLPC mission
and in some cases, they have registered on our Pootle server and
contributed to Sugar L10n, so overall, this has been a win.

This has also provided a better ability to track the status of
upstream L10n efforts for bits we need and our upstream L10n tracking
project on Pootle has served as a "tracking ticket" that provide a
"trail of breadcrumbs" for our L10n teams to follow to the upstream
when they have completed their work on our locally hosted projects.  I
do not believe this is a "zero-sum game", where a string they do
upstream is a string they do not do for Sugar.  Localizers work on the
projects they choose and many tend to have a certain loyalty to the
project that first got them engaged. but some localizers have a
stronger language-focused affinity and spread their effort around to a
variety of FOSS efforts.  By weaving connections between Sugar / OLPC
and various FOSS L10n efforts (particularly upstreams) , we are
establishing ourselves as a significant player in the FOSS L10n
community and gaining karma points for good citizenship.

Localizers and localized strings are a somewhat fungible asset.  It is
possible to leverage upstream work by creating pocompendium files and
placing them in the Terminology project on Poolte  where they offer
one-click suggestions while localizers are going through the PO files.
 I harvest upstream PO files and typically sort out those msgids
present in our hosted projects first.  I have done this for a number
of projects jsut getting off the ground and believe it has produced
faster completion and higher consistency in L10n.

Is there anyone that is willing to collaborate with me on going over a
spreadsheet (that I will start) and trying to identify additional
pockets of upstream strings for L10n so that I can improve
the"Upstream L10n tracking" project on Poolte?

cjl
Sugar Labs Translation Team Coordinator