User:Cjl/11.3.0 notes1

Freezes

In a FOSS project a freeze of any sort (feature, string, code) has both a technical element and a social element. I'll largely focus on the social aspect.

A feature freeze is imposed on the release sponsor (e.g. OLPC) by the release manager out of respect for the developers of non-core elements so that they have the opportunity to adjust to the new technical underpinnings of the release. The sponsor may have to accept that desired features may not be achievable for the planned release. The release manager has the technical means to enforce the feature freeze by controlling the patches accepted to the branch.

A string freeze is imposed on developers out of respect for the L10n community to give them time to complete their work on a target that is not continuing to move. As Honey activities are not controlled by a single person, the technical means of achieving a freeze does not really exist. However as a social compact, it should be feasible to identify the maintainers of the activities planned for inclusion in the build and ask them to respect a period of stasis to allow the localizers to work on a stationary target. The technical means of enforcing the freeze are not truly required if the social compact is respected.

Action #1 -

Release manager to identify maintainers of key Honey activities and discuss an informal "string freeze" process with them.

The reality is that, in general, Honey activity UIs are not rapidly moving targets anyway, so this should not be impractical.

Other actions OLPC could take to enhance L10n of 11.3.0

Recruit localizers from deployment regions

OLPC has not always consistently leveraged it's contacts with in-country teams and ex-pat participants to advance L10n. This is particularly important as the regions OLPC targets are not generally well-represented in the FOSS L10n community (e.g Rwanda, Haiti, Oceania, Cambodia, etc.). Fortunately the Rwanda team has recently stepped up to the plate on Kinyarwanda and an effort that actively recruited Armenian L10n help has made rapid progress. Perhaps the slow progress in some native languages is understandable when the language of instruction is English. but even so, OLPC should aspire to advance L10n by leveraging their working relationships with native speakers.

Haitian Kreyol, Khmer, Mongolian, Amharic, numerous Oceania languages are examples of where there are a well publicized OLPC presence, but rather poor localization coverage.

Action #2 -

We need to give localizers a method for experiencing Suagr without having an XO laptop. A solid SOAS release is an essential pice of addressing thsi issue. I have been recruiting a rare Khmer localizer that would love to help (and we badly need Khmer localizers), but doesn't currently have a good way of obtaining the necessary context to perform meaningful L10n work. Should I continue to wait of SOAS5 or should I recommend TOAST (which I know very little about)?

What resources and tools does are needed to support L10n efforts for 11.3.0?

Action #3 -

Obviously, we need more localizers for the "under-represented" languages that are of the most interest to OLPC deployments in under-developed countries. As these localizers are not easily found in other FOSS projects, a focus on L10n needs to be made an element of OLPC "pre-sales" planning. L10n recruitment needs to come from the top-down via engagement fo OLPC-A and OLPC-F management in leveraging their contacts as a bottom-up approach of expecting localizers of these under-represented languages to come to us will not guarantee adequate coverage. This should be discussed with OLPC management.

Measurement / Tracking of key L10n metrics

Action #4 -

L10n coverage of key languages is a critical metric with regards to the potential for "success" of an OLPC release and therefore needs to be proactively tracked by the release manager. If it is worth doing, it is worth measuring.

We can easily monitor status of Sugar strings via Poolte (see http://wiki.laptop.org/go/File:11.2.0_L10n_status.ods for 11.2.0 langs), but with the inclusion of the GNOME boot on the image, there are many additional upstream L10n strings (in those same under-represented languages) that will not simply appear on their own (unlike many European languages), engagement with the upstream is critical.

GNOME has been kind enough to provide me with access to managing an "OLPC release set" on their Damned Lies L10n server. (see http://l10n.gnome.org/releases/olpc/) in addition tracking ticket PO files have been created on Pootle (for non-GNOME packages) to both track completion and to "leave a trail of breadcrumbs" pointing localizers at upstream strings that need work (see http://translate.sugarlabs.org/projects/upstream_l10n/).

Even this is an incomplete listing of the L10n strings that need to be done. See http://wiki.laptop.org/go/File:11.2.0_packages.ods for a listing of packages and annotations on their L10n processes, it si still a work in process/

Action #5 -

The identification of L10n processes associated with all packages included in OLPC releases needs to be completed collaboratively with the release manager or other developer and the Translation Team. In some cases, there may be no UI strings, and this needs to be noted. Tracking tickets in Pootle should be created where possible to enable "discoverability" of upstream strings that need work.

On of the key pieces of L10n status tha needs to be tracked is the "commit status" of L10n of each PO by each language. We have no simple method for determining whether a completed L10n has been committed or whether changes (e.g. QA and improvements) may have occured to a PO after completion and commit. This is a serious deficiency in our available metrics. I had asked Sugar Labs about creating a "Commit" list (corresponding to OLPC's Commit" list), but this has not moved forward for lack of resources or prioritization and in any event would only act to identify commits, not changes post-commit.

Sayamindu had hacked a previous version of Pootle to give these committed flags on the PO files, but those changes were lost in a subsequent Pootle upgrade. Could OLPC incentivize Sayamindu (cash is very sincere) to resurrect this tracking and upstream it to the Pootle developement team so we could once again have access to this sort of reporting. Perhaps you can think of other ways (besides individual commit log review) to quickly obtain some idea as to whether a given PO in a given language has been committed and whether there have been any changes in the PO since that time that have not yet been committed?

Action #6 -

Investigate methods for rapidly determining status of PO commits and whether another commit is needed.