ubuntu-docs updates for translation into Intrepid

[Jeroen Vermeulen]

Matthew East wrote:
> On Thu, Oct 9, 2008 at 11:19 AM, Jeroen Vermeulen <jtv at canonical.com> wrote:
>> It largely depends on how much of the overall translation work the pending
>> imports will cover.  The lower the ratio, the more sense it makes to
>> prioritize the templates.
> 
> Ok, I don't really understand this, because I would have thought that
> all new strings are worth having in the interface asap before po
> files, on the assumption that merging the outstanding pot files in the
> queue probably wouldn't take that long (how many imports does
> Launchpad get through per day?)

At the moment we're importing about 2k-5k files per day, although 
variability is huge.  Most of the remaining files are OpenOffice updates 
or newer uploads.

The problem with importing templates long before their uploaded 
translations is the risk of redundant translation work.  It might sound 
like the sort of problem you'd like to have, but actually we've found 
that it generates some very painful problem patterns:

1. Translators do lots of work, but their suggestions are not accepted 
because the messages they translated also turn out to be covered by the 
upstream imports.  So they find back nothing of their own work in the 
end result and feel rightfully frustrated.

2. Some of those translators then mistakenly identify not being a member 
of an Ubuntu translation team as the root problem, and sometimes file 
membership applications as Rosetta questions.

3. Translations are accepted and then override the upstream ones that 
are imported later, leading to complaints about unwarranted "forking" of 
the translations, bug reports, demands that we block this or remove 
that, and so on.  I've even had someone from a translation team ask me: 
"who reviews our translations and decides what goes into Ubuntu?"

4. People experiencing this find it hard to get to the places where 
their effort is going to be most useful, especially without good team 
coordination, and come up with ideas for fixing this in the UI.  They 
are often good ideas, often overlapping or conflicting ones, never 
perfect solutions.  And so far we never quite get around to choosing 
ones and implementing them.

A lot of the fallout ends up with us, the application developers, even 
when some of them are at least partly matters of Ubuntu community 
organisation.  We spend a lot of time on this, despite various policies 
and practices aimed at minimizing them, because until recently the 
Ubuntu division did not have anyone at all to coordinate the translation 
effort.  That's been partly addressed now, in the Intrepid cycle, but 
the new role is still gearing up.

We do make improvements on the engineering side to help address these 
problems: Ubuntu translations to language that have nobody to manage 
them no longer solicit suggestions.  We no longer need to take Launchpad 
offline to initialize translations for a new release.  A lot of outdated 
or misleading UI text about translation teams has been cleaned up and 
documentation has been rewritten.  Also, as of next month, upstream 
translations will start replacing ones that are translated only in 
Launchpad but not upstream.  (This would have rolled out last night, but 
we were busy dealing with Ubuntu imports operationally). 
Message-sharing will break down the walls between translations of 
different Ubuntu releases, eliminating much duplication of effort and 
taking a huge amount of pain out of translation openings, but it's a 
major effort that we complete one step at a time.

Given the amount of pain it can cause, I think moving templates ahead of 
translations as general practice is replacing one problem with another. 
  Our current plans are to open translations for new Ubuntu series much 
more aggressively, building on the organisational changes being made on 
the Ubuntu side; continue improving documentation thanks to the 
unrelenting efforts of Matthew Revell; and continue with these technical 
measures.

A more precisely outlined procedure might still help.  For instance, we 
might want to prioritize templates that have been Approved for a long 
time but which don't have any translations in the queue.  One limitation 
there would be that the auto-approval process is already loading our 
script server more heavily than we'd like.  Or we might want to show 
"careful, this translation has an import coming" warnings.  The 
limitations there would be UI design, page rendering cost, and 
engineering time.


Jeroen