Re: Translator abuse?

[Chris Leonard <cjlhomeaddress gmail com>]

On Mon, Jun 18, 2012 at 6:56 AM, David Woodhouse <dwmw2 infradead org> wrote:
> The OpenConnect VPN client exports a library, libopenconnect, which
> handles the fun part of communicating with the server to authenticate.
>
> This is used from the NetworkManager authentication dialog.
>
> However, The OpenConnect package lives outside GNOME git and its
> translations are handed in Transifex. Its translation coverage is fairly
> poor.
>
> This means that when you use NetworkManager-openconnect in a language
> which is fully supported by GNOME, you *still* get to see untranslated
> strings where they come from OpenConnect itself.
>
> I'm pondering "artificially" importing the translatable strings from
> OpenConnect into NetworkManager-openconnect, so that they get translated
> by the GNOME translation teams and the GNOME user experience for these
> languages is much better.
>
> However, this is technically a trick — I'd be importing strings from
> another package *outside* GNOME, which aren't used directly from the
> GNOME package, only to "harvest" the translations and put them back into
> the non-GNOME package.
>
> Would that be considered acceptable?

As a downstream that faces this sort of issue more frequently than
Gnome probably does given the Gnome position in the software stack, I
have tried to resolve similar issues in a variety of ways (as
Translation Team Coordinator of Sugar Labs / OLPC), with differing
levels of success.

In descending order of success from most successful to least successful.

1a) Obtain buy-in from my org (Sugar labs Oversight Board and our
parent fiscal sponsor SFC) that offering hosting on our Pootle
instance was a wise and acceptable use of our resources in a
particular case (AbiWord).  Engaging with the AbiWord community and
working over time to gain their trust and convince them of the
superiority of the hosted solution being offered over existing L10n
workflow (complete and mail PO files) and advantages of accessing a
larger pool of localizers.  Continuing engagement with high levels of
responsiveness to AbiWord localizers to maintain trust and smooth the
transition.

Results: Very successful, win-win-win achieved. (OLPC AbiWord users /
AbiWord devs / AbiWord localizers).  Results measurable by higher
levels of completion and expanded number of languages.

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

Compare stats for 2.8 (pre-Pootle) to 2.9 (post-Pootle)
http://www.abisource.com/contribute/translate/

1b) We have had this arrangement with eToys for a long time, so I am
not counting them, but their stuff lives in it's own SVN repo (that we
commit to via a special user:pootle given commit privs).  POT updates
are coordinated periodically.  Essentially we share the Pootle
instance and the localizers as an ICT educational community resource
of the greater Sugar Labs / OLPC / eToys community.

2) Engage with a friendly upstream (Gnome) from whom we inherit a LOT
of L10n bits, make polite requests about how to better coordinate, get
a very helpful response with the creation of a special "OLPC Release
Set" that allows us track our upstream L10n bits and makes it easy for
our localizers to identify those bits we use (thanks Claude).
Hopefully, also makes it easy for willing upstream localizers to
prioritize our L10n bits,  if so inclined, as OLPC distributes
dual-boot Sugar/Gnome builds providing a fully functional, but
somewhat simplified Gnome desktop to millions of kids as an
alternative to Sugar UI.

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

Results: Hard to measure specifically.  Success metrics would include
evidence that our localizers were working upstream, or that upstream
localizers choose to prioritize our bits.  My sense is that this is
overall an elegant solution for Sugar/OLPC and we do provide a "trail
of breadcrumbs" that our localizers can follow upstream easily, which
would benefit Gnome.  There are inherent benefits to collaborative /
cooperative information exchange and smoothing project to project
migration of contributions, but I really can't put hard numbers on how
well it has worked out.  It is clear that it is a no-lose situation
for all parties, so I'll declare it a win. :-)

3)  Provide simple "trail of breadcrumbs" for localisers to follow
from our L10n infrastructure to other upstream hosted L10n (Gnome,
Translate Project, Fedora Transifex, Scratch Pootle instance) for
packages we pull.  This is done by virtue of creating a dummy project
containing dummy PO files that serve the function of tracking tickets.

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

The PO is hand crafted (with a spreadsheet) to contain a developer's
comment with a link to the upstream L10n hosting for the package and
tracking is achieved by dummy "translation" of that package string
with "Completed on date X)".

Results:  Again hard to measure, but I am not that optimistic.
Frankly, a number of our localizers find this confusing and end up
providing a literal translation instead of following the directions in
the developer's comment.  The list of upstream packages changes
unpredictably over time and there is a significant manual maintenance
burden to keeping up-to-date on both the links pointed upstream and
their current completion status.  Overall, not one I would put in the
win column, but not a lose either.

4) Every once in a while, but only for certain languages and certain
packages, we will (with the consent of the upstream) host a local copy
of the PO file purely for the convenience of a local team that has
been specially formed (this happens periodically when a new country
buys a bunch of XO laptops) to do a localization sprint.  The goal is
to collect the strings for that package/language combination (these
are usually less-commonly found languages) and eventually upstream
them.

An example of this is GCompris (thanks Bruno), where we have some
South American indigenous language efforts going on.

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

Spanish is only present there because it is the bridging language
(many of these localizers speaking no English).

Results: Too soon to say.  No reason this can't work, but it is not a
general solution, just a stop-gap before upstreaming.  Our preference
would be to simply point the localizers upstream, but with these
specially formed teams, that is not always feasible and frequently the
glibc locales do not exist yet, so the upstream would have trouble
hosting them anyway.

That is the Sugar Labs experience in these situations, YMMV.

Regards,

cjl
Sugar Labs Translation Team Coordinator
http://translate.sugarlabs.org/