Kubuntu reaching out to KDE l10n

[Arne Goetje]

Albert Astals Cid wrote:
> Still there's the problem to resolve on why you should be trying to 
> "steal/prevent" people to become KDE translators by making them use Rosetta 
> instead of translating directly KDE upstream.

We don't "steal/prevent" people from becoming upstream KDE translators.
Quite on the contrary, we do encourage our translation teams to submit
their translations and fixes back to upstream for any project, including
KDE.
However, for most languages we don't have many KDE users/translators in
our translation teams, if any at all. Therefor our translation teams
lack communication with upstream KDE.
Maybe it would be a good idea to have at least one person per language,
who is involved in the upstream KDE translation to become a member of
the respective translation team in Launchpad/Rosetta and guide the team
on how to keep upstream and downstream in sync, if desired, and help if
necessary.

Now, I'm trying to clarify on why we need Launchpad/Rosetta in the first
place (I get asked this question many times):

Ubuntu/Kubuntu as a distribution releases stable releases every 6
months. Those stable releases are supported for 18 months (5 years for
LTS releases). During the support period only grave bugs are fixed as
SRU (stable release update). However, we do ship language-pack updates
periodically, so that buggy translations can be fixed and languages
which are not fully translated can be completed over time. That means
that the software packages, which contain the translation templates,
don't change in the archive, but missing translations get added and
buggy ones fixed. Therefor we stick with older versions and improve
translations for them, while upstream goes on to develop their next
release and might even have dropped support for older releases already.
For example, Kubuntu Hardy 8.04 is a LTS release, means it will be
supported until 2013. This release still has KDE 3.5, which is not
supported upstream any more. But we still improve translations, because
users use it.
In some cases, we need to patch the original software, which might
change msgids or even introduce new ones. So, we differ from upstream.
In order to get those strings translated, our translators use Rosetta
and we ship those translations in our language-packs.

Now I'll try to explain why we have so much trouble with KDE
translations in Rosetta.

When using gettext, we have a translation template (the .pot file) and
corresponding translation files (the .po files) for each language.
Usually, upstream projects generate the .pot template during build time,
while they may ship a collection of already (sometimes partially)
translated .po files in their tarball.
Now, when we upload new software into our archive, we package the source
package and upload it to our build daemons. The build daemons build the
binary packages and push them into the archive. During this process, the
 generated .pot file and the .po files get stripped out of the binary
package and submitted to Rosetta, where they get included into the database.
Within Rosetta, the .pot templates are associated with the source
package they came with.

With KDE, things are bit different, since you ship translations already
as a separate package and the .pot files got stripped from the source
packages. However, we cannot import them into Rosetta like this, since
we need the .pot files and associate them to their respective source
package. Means, our package maintainers currently need to do some extra
work in order to generate the .pot files again in the correct source
packages. Since templates tend to move, being merged or renamed between
KDE releases, we somehow need to track that. And currently we have no
means to automatically track those movements, which results into
inconsistencies between the Rosetta database and the source packages.

In short, here is what we'd like to have:
 1. be able to sync translations directly with KDE, maybe through direct
database to database communication if possible. This can be
unidirectional at first (KDE -> Rosetta), but later we would like to
have an easy way to commit changes or new translation back to KDE. So, I
don't know how you organize the translation process in KDE, but maybe
Rosetta changes could be submitted into a separate queue and then being
reviewed by the respective KDE translation team.
This item does need some technical solution as well as an agreed
procedure with both sides involved. So, I'd like to call for discussion
on how we could implement this. (Rosetta engineers are subscribed to
this mail as well.)

 2. closer communication between translation teams in KDE and Launchpad.
For example, when there are discrepancies between translations done
upstream and in Launchpad, those conflicts should be resolved through
communication and discussion. (i.e. why the translation in Launchpad has
been done this way and not the other way and which one is better).

 3. have an automatic way to track template movements between KDE
releases. Currently this is a manual process, we need to identify the
templates first and then manually change them in Launchpad/Rosetta. For
example: when we upgrade from KDE 4.2.95 to 4.3.0, once the new packages
hit the archive, their corresponding templates should be updated (i.e.
template "foo" has been moved from source package "bar" to "baz")
automatically (maybe with manual approval). So, we would need some
script to do this, and I think we are on a good way already to get this
done, thanks to Harald.

Anything else I missed? :)

Cheers
Arne
(Ubuntu Translation Coordinators team member)