ubuntu-translations-coordinators team mailing list archive

[Albert Astals Cid <aacid@xxxxxxx>]

A Dimarts 07 Juliol 2009 06:37:47, Arne Goetje va escriure:
> 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.

Good to know

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

Errr, no, let's do it the reverse, let's at least one person per language in 
Launchpad/Rosetta join the upstream KDE translation so he learns by himself. 
That makes much more sense to me.

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

That's great on theory but has been a total failure since Rosetta exists, as a 
simple example i lost 2 days (not full time, just my free allocated time to 
work on KDE translation coordination) trying to fix a Spanish KDE translation 
bug when actually it was just simply someone having overwrote correct KDE 
translation in Rosetta with an incorrect string.

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

Remember thinking that you are smarter than upstream is not a good idea, but 
in the case you feel like patching software behind maintainers back the good 
idea would be just using a separate .po file and making sure it's loaded.

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

We have a file called process_orphans.txt in our svn with the moves/deletes we 
do, get it and use it, actually i think it's what Harald is using already.

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

We could just mail the coordinator of each languagem the changes, the problem 
again is that he can get flooded by "not worthy" Rosetta translations and just 
kill her free time to work on KDE.

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

And how is upstream going to notice there's a discrepancy?

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

I already mentioned process_orphans, this should be enough.

Albert

>
> Anything else I missed? :)
>
> Cheers
> Arne
> (Ubuntu Translation Coordinators team member)