<div class="gmail_quote">On Wed, Mar 24, 2010 at 2:56 AM, Clytie Siddall <span dir="ltr"><<a href="mailto:clytie@riverland.net.au" target="_blank">clytie@riverland.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
1. Has anyone translated any part of these manuals into Vietnamese?<br>
<br>
2. If not, can we get this text on Pootle (e.g. using po4a [1] which converts many doc formats into PO files)?<br></blockquote><div><br>So, Clytie, this is a more expansive answer to your question about localizing the manuals into Vietnamese and the tools available to do so.<br>
<br>For long form texts (like manuals and web-sites) it isn't quite as simple as just scraping the translatable strings with a tool like po4a and posting the PO file on Pootle. The eco-system of tools is simply not as complete or mature as it is for code internationalization (i18n) and localization (L10n) and perhaps even more importantly, the familiarity and experience with support of po4a doesn't exist within the OLPC community at present.<br>
<br>For code, there is a fairly mature eco-system of tools that make a coordinated / distributed publication process simpler for localizers and developers alike. Tools like gettext assist in the first phase of i18n (preparing PO files) and there are also methods for connecting Pootle up to software repositories (like git) that can help keep the repo and the PO files concurrent and synchronized. After L10n is completed, there are further mechanisms for committing the completed PO file back to the repository where additional i18n steps occur in the build-creation phase of release publication (e.g. generation of MO files and language packs). <br>
<br>Even so, it takes a fair amount of manual intervention behind the scenes to make all of this work. By-and-large, Sayamindu carries most of that burden by himself, which is why I've chosen to work on various administrivia aspects of the Sugar Labs / OLPC localization effort, so that he can focus on the absolutely critical stuff that he is uniquely qualified to do. We are fortunate that for the most part our developers are committed to doing their part with respect to i18n, particularly the core Sugar developers and a good handful of Activity developers, but there is still room for improvement in terms of a number of individually contributed Actvities and getting them set up for inclusion in Pootle. This is mostly an ongoing education challenge and not a technical issue.<br>
<br>A far as long-form HTML-based text there is something of a gap in the maturity of the tools, particularly with respect to the interfaces between the i18n and L10n (and then back to i18n) process, and while it is true that po4a is an attempt to address this, it is simply not at the same "plug-n-play" level as a toolset as what is currently available for code L10n. No insult meant to the developers of po4a (I applaud and appreciate their work), but they themselves refer to these issues in the rather extensive manpage below. Reading it gives you some flavor for the complexities involved.<br>
<br><a href="http://po4a.alioth.debian.org/man/man7/po4a.7.php" target="_blank">http://po4a.alioth.debian.org/man/man7/po4a.7.php</a><br><br>It may seem a little unfair, but by the "eat your own cooking " standard, if you look at the repo for po4a, they only have their own documentation localized into a small handful of European languages, which must say something about the tool itself or at least the overall context in which it currently exists. Their L10n process still involves many manual steps that play themselves out on their e-mail lists, and this is not a truly scalable solution.<br>
<br>Importantly, a significant aspect of the maturity gap has to do with user training as much as the tools themselves. As a rule, FOSS software developers have accepted the importance of localization and are easily induced to do their part on i18n, but authors (both web-page developers and part-time documentation writers) have not yet been as well-indoctrinated by the localization community and so there is often a disconnect between the format of the document as produced by the authors as well as the tools they use to publish it (e.g. their site-hosting or wiki for instance) and the processes involved in i18n-L10n. Mostly this means that there is much more manual intervention needed because the automation of these tools for a highly distributed environment like Sugar Labs / OLPC has not reached the same level of sophistication on the back-end, in order to provide the simplest interface for developers and localizers on the front-end.<br>
<br>The "right" way to address the localization of long-form text is a challenge that has been kicked around in a number of OLPC forums, the library list (for HTML-based content), the wiki gang (for wiki L10n) as well as the Support Gang list (for the localization of manuals and other documentation). To date, no clear consensus around tools or methods has appeared. Solutions remain a mix of one-off and intensively manual processes. There have been various attempts to work towards using PO-file based methods (like the an early attempt with the OLPC web-site itself), but they have not gained real momentum or sustainability.<br>
<br>The FLOSS manuals setup for localization has been explored, but I don't
think it could be called truly successful (while different languages have
been set up, the number of those completed and published is not great). Whether that is due to the tools or the challenge of coordinating the human resources involved is not ewntirely clear to me. Obviously, there are real advantages to be gained by providing a single interface (Pootle) to localizers, but all of the necessary pieces have not yet been assembled to enable that for long-form text L10n work yet.<br>
<br>I wish there was a happy answer to your question. I do think that some individual elements of the solution are available (like po4a), but it will take some considerable effort by a fair number of people to establish and then maintain a long-form text publication process that works as smoothly as the current code L10n set-up. Given that neither Sugar Labs or OLPC has genuinely taken ownership of the textual content creation and curation process, I'm not sure that the committed resources to accomplish an overall solution will be forthcoming and so this remains a challenge that is not adequately addressed.<br>
<br>Those are just my thoughts, which are not intended as criticisms but as an acknowledgement of the status quo. There are some content-creation projects related to health education on the XO laptop that I would love to take on, but I've put them on the back-burner because I don't think they would be sustainable (in a useful, localized form) with the level of resources I could commit by myself.<br>
<br>cjl<br></div></div>