I was asked to re-post this message to sugar-devel by Walter Bender. I have intentionally cross-posted to the Localization lsit as well. Please check both list's archives for responses.<br><br>cjl<br><br><div class="gmail_quote">
---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Chris Leonard</b> <span dir="ltr"><<a href="mailto:cjlhomeaddress@gmail.com">cjlhomeaddress@gmail.com</a>></span><br>Date: Wed, Mar 2, 2011 at 12:32 AM<br>
Subject: Translation Team report<br>To: Chris Ball <<a href="mailto:cjb@laptop.org">cjb@laptop.org</a>>, Walter Bender <<a href="mailto:walter@sugarlabs.org">walter@sugarlabs.org</a>>, Aleksey Lim <<a href="mailto:alsroot@member.fsf.org">alsroot@member.fsf.org</a>>, <a href="mailto:mchua@laptop.org">mchua@laptop.org</a>, Adam Holt <<a href="mailto:holt@laptop.org">holt@laptop.org</a>>, Bernie Innocenti <<a href="mailto:bernie@sugarlabs.org">bernie@sugarlabs.org</a>>, Sebastian Silva <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>>, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>
<br><br>Dear SLOBs,<br><br>I saw a comment is the SLOBs 2010-12-23 minutes that you wanted reports from the various Sugar Labs teams, please consider this to be a report from the Translation Team (at least from my personal perspective). Some of these comments may be seen as critical of organizations (or elements thereof), but I hope it is understood that my intent is to point out areas where improvement is needed and that my criticism is matched by my own efforts to contribute constructively. Feel free to circulate or post this as you see fit. I'd be happy to try to answer any questions that come up <<a href="mailto:cjlhomeaddress@gmail.com" target="_blank">cjlhomeaddress@gmail.com</a>>.<br>
<br>Sayamindu's transition to graduate student left a gap in the Translation Team's coverage of critical back-end issues (Pootle maintenance, adding new projects and connecting Pootle to git). Recently Rafael Ortiz (dirakx) has stepped up and begun taking up some of the slack (performing a Pootle upgrade, addressing a series of backlogged tickets related to adding L10n for new activities). This has been very helpful, but additional sysadmin-type support of the Pootle server would help to share that burden and provide essential redundancy in the arcane Pootle arts. I would encourage the SLOBs to be on the look-out to recruit additional talent to/from the Sugar Labs Systems team to the cause of localization to address a number of issues that remain unresolved.<br>
<br>There seems to have been a breakdown in the branching / versioning process (as reflected in Pootle). We have Glucose / Fructose pairs for Sugar 0.82 and 0.84 as archival projects, but there has been no versioning since, with only the un-numbered Glucose / Fructose projects (reflecting no freeze of versions 0.88, 0.90 or branching for the newly released 0.92). This may be a significant issue as development continues with certain of these versions (e.g. 0.88 for dextrose), but no frozen set of localization strings exists to correspond to these frozen releases.<br>
<br>In addition, this breakdown is also reflected in what I see as a disturbing lack of communication to the Localization list about string freezes and release dates. I take some personal responsibility for not having stayed on top of release schedules and not performing this communication myself as I have in the past, but it is very important that L10n be top-of-mind for the Release team and that communication to the Localization list about string freezes be a responsibility that developers take quite seriously.<br>
<br>It would be very helpful if the Sugar Labs Activity Team strongly encouraged developers to perform internationalization of their submissions to ASLO. I see this as another area where there is too much daylight between the development and localization processes and Sugar Labs (particularly key influential developers / maintainers) could do a better job of advocating for i18n / L10n by developing and communicating a clearer set of expectations of activity authors to assure the widest possible audience for their work. If large portions of this project exist only in English, I fear it will have failed it's mission. Admittedly, there exists some confusion about the correct procedures for POT generation and continuing synchronization (even among fairly experienced developers and not excluding myself), when this clarifies, improving our documentation would be desirable.<br>
<br>As for the Localization community itself, it continues to grow with new localizers joining weekly to a total of approximately 1800 registered Pootle users as of the current date working on over 100 languages and dialects. As one might expect, European languages are fairly well covered and current, while the non-European languages are much less adequately staffed and in particular there is often not an active language administrator (to perform QA reviews and commits to git) for these other languages. There are a number of languages that were set up by specific request that subsequently have seen little or no L10n activity. (Akan, Maltese, Sanskrit, Crioulo, Quechua, Aymara and a fair number of OLPC Oceania languages).<br>
<br>One notable issue is the poor coverage of some languages that are important to OLPC deployments as noted in my message on the thread about 11.2.0 language support:<br><br><a href="http://lists.laptop.org/pipermail/devel/2011-February/031092.html" target="_blank">http://lists.laptop.org/pipermail/devel/2011-February/031092.html</a><br>
<br>It is critical that OLPC lay the groundwork for these deployments by recruiting L10n volunteers from these languages that do not have a large user-base footprint on the Internet (at present). I see this as an organizational responsibility that OLPC has neglected. It is unfortunate that although they have an entire team based in Rwanda, the Kinyarawanda L10n effort has only recently gained an OLPC recruited localizer. OLPC is uniquely positioned to recruit localizers for their deployment languages and it is my opinion that their efforts have fallen short of the mark.<br>
<br>While by no means unique to the Sugar Labs / OLPC / eToys L10n project, there remains a significant challenge with handling longer-form (content) localization work. I see this as an issue that is potentially stunting the growth of content development and in particular the sharing of content developed by one deployment with others. Unfortunately, I have no particular solution to offer, FLOSSManuals represents one model, but I do not think it has truly had success in supporting L10n. A Pootle-based solution would be ideal. <br>
<br>On a related note, I believe that OLPC is missing a critical opportunity by not dedicating some resources to the i18n of the Help activity which is essentially a snapshot of the FLOSSManuals XO book wrapped as a Sugar Activity. This issue was noted as a genuine problem by Beth Santos in her efforts in Sao Tome when we spoke at a recent fund-raiser for STEP UP OLPC. Having onboard XO help that exists only in English is a "fail".<br>
<br>Much of the above clearly falls in the category of opinion, but I stand by it.<br><br>cjl<br><div style="padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;">
</div>
</div><br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>