[OLPC library] [Localization] Translating the manuals?

[Chris Leonard]

On Wed, Mar 24, 2010 at 2:56 AM, Clytie Siddall <clytie at riverland.net.au>wrote:

>
> 1. Has anyone translated any part of these manuals into Vietnamese?
>
> 2. If not, can we get this text on Pootle (e.g. using po4a [1] which
> converts many doc formats into PO files)?
>

So, Clytie, this is a more expansive answer to your question about
localizing the manuals into Vietnamese and the tools available to do so.

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.

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).

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.

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.

http://po4a.alioth.debian.org/man/man7/po4a.7.php

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.

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.

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.

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.

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.

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.

cjl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/library/attachments/20100325/c1a5f658/attachment.htm