Import queue entries may suffer from brain split.

[Henning Eggers]

Import queue entries are linked to either the ProductSeries or the SourcePackage that the import is for. Once approved they are also linked to a POTemplate which in turn is linked to a ProductSeries or a SourcePackage. There is nothing that keeps those two link in sync, so the entry may be pointing to a different series/package than the template.

Practical example where this matters: A contributor uploaded templates and translations which were approved and imported. Then they asked the Rosetta admins to remove those templates because of errors which they did by moving them to the special rosetta/deleted-templates. Problem is that there are still translation entries in the queue (albeit in state "Imported") that link to these templates. The contributor uploads new templates and translations but since the queue re-uses entries if the path matches, the old "brain-split" entries are re-used and the translation imports go to rosetta/deleted-templates. Ouch.

[Fabien Tassin (fta)]

I have to remove some obsolete templates from the chromium translations really soon (2 templates merged into 1 upstream). I also have to either disable or remove some other templates that are not used in Ubuntu and for which upstream is not accepting contributions (like the google chrome strings) so that i don't waste translator resources.

Please advise how to best do that in order to avoid this bug and bug 655077

(this is a blocker for chromium, as is bug 669831)

[Данило Шеган (danilo)]

Fabien, the best way to ensure you are not hit by this bug or bug 655077 is to not do any uploads (wait for the import queue to clear, if needed mark files related to templates you want to disable as 'Deleted' and wait a day or so for them to be removed) and then disable templates yourself. If you want some help, please file a question on https://answers.launchpad.net/rosetta and we'll make sure to help get it done.

[Данило Шеган (danilo)]

Btw, this bug is not something you have to worry about too much. Even if you don't get it right, it shouldn't affect your project in a negative way, and it's very easy to fix afterwards.

[Henning Eggers (henninge)]

I considered this bug for a quick fix during the bug jam but I don't think it is quick. I thought about these options:

1. Implement setters for TranslationImportQueueEntry.potemplate and .pofile that update .productseries etc. to be the same as for the template. The problem here is that in the described situation the productseries was changed on the template, so a setter on the queue entry would not have been involved.

2. Make TranslationImportQueueEntry.productseries etc. properties that return either the attribute from the entry itself if it is still unbound (i.e. not linked to a template) or the attribute from the template. The challenge here are database queries that involve these attributes and that would have to implement the same look-up order. That may have an impact on performance and will certainly not be quick to fix (including tests and such).

Also, the rosetta project is gone and with it the deleted-templates series and I don't know what happened to the templates that were linked to it.

[Robert Collins (lifeless)]

Dropping to low (because its 'very easy to fix afterwards')