Too easy to make duplicate translations

Bug #73947 reported by Eivind Ødegård
2
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Undecided
Unassigned

Bug Description

Currently, translators are told that the translation focus is on Dapper. Still, many people translate for Edgy (or other incarnations), thus leading to packages being translated twice- once for Edgy, once for Dapper.

To avoid duplicate work, translations for Dapper packages should be merged frequently (preferably daily) with the Edgy packages, and perhaps vice versa, so we avoid having to translate the same package twice. This should of course only happen for untranslated strings which are unchanged from one distro to the next.

I know that keeping track of what the translators are doing is in part a job for each translation team, but automated merging would ease the pain. It would also benefit all distros, e.g. translations for Dapper would immediately be useful for Edgy too. Perhaps such auto-merged translations could be marked with "need review" in order to avoid errors?

This probably has been discussed ad nauseam on the mailing lists, but I will file it as a bug, as that's just what it is. And please forgive me if this is a duplicate bug report. It only goes to show the duplicity of this bug (bad pun, but intended nonetheless).

Edit: The Rosetta FAQ, https://help.launchpad.net/RosettaFAQ , seems to have addressed this malbehaviour. That's what I think at least. To quote the FAQ (point 5 under "Translation process"):

What happens with the translations done on the Ubuntu templates for a product? Do they get shared with my template for my development branch?

      All translations introduced into the Rosetta system get included in a huge "translation memory". If someone translates an application for its Ubuntu breezy series, these translations will appear as suggestions when someone else translates another series of that product. A planned feature for Rosetta is "Translation Sharing", which would allow a translation to apply to all series of a product when it's updated in just one, which will make it a lot easier to do.

---------------------

So that probably means this is a planned feature. Until this feature is in place and tested, I suggest keeping this bug open.

description: updated
description: updated
description: updated
Revision history for this message
Данило Шеган (danilo) wrote :

This is basically implementing https://blueprints.launchpad.net/products/rosetta/+spec/multicast-translations

Also note that we've already got what you're asking for in one direction (from Dapper to Edgy migration, but we don't have clear policy on how often will we run it).

Changed in rosetta:
status: Unconfirmed → Confirmed
Revision history for this message
Eivind Ødegård (eivind) wrote :

Regarding comment 1 - multicast translations:

Very good. This is what I was asking for, thanks for putting me in the right direction. Both the related bugs on the multicast translation page are of the utmost importance. Upstream must have priority, and translations must go across all distributions. Of course, you know how important it is to get this working.

Regarding comment 2 - Dapper to Edgy migrations:

It's good that Dapper to Edgy migration does take place. Could this information be given on several userspace webpages, eg. the list of translatable packages for each language?
I also uphold my initial suggestion of frequent translation merging, e.g. daily. As Rosetta is a system with high newbie appeal, it also needs to be newbie proof. We don't want people translating the same strings across different distributions, and we should prevent them from doing so, even though they should use their senses and don't do such things.

Thanks for commenting!

Revision history for this message
Данило Шеган (danilo) wrote :
Changed in rosetta:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.