Enable sharing between products and Ubuntu

[Ursula Junque]

One more of the "bridging the gap" series: enabling message sharing between project and package series.

See the spec: https://dev.launchpad.net/Translations/Specs/UpstreamImportIntoUbuntu/FixingIsImported

[Henning Eggers (henninge)]

OK, after a first attempt, some thinking, and talking to people I came up with the following:

- Sharing translations within a DistributionSourcePackage (as POTemplateSharingSubset does now) is dangerous because it simply is the tuple (distribution,sourcepackagename) and the sourcepackagename may refer to different applications in different series of the distriubtion. Example: The game "chromium" became "chromium-bsu" when "chromium" was introduced for the browser. Accordingly, packaging links are always to SourcePackages (distroseries,sourcepackename) and may link to different products. The outcome might be that we'd be sharing translations between different products. Ouch.

Actually, this problem questions the whole concept of the DistributionSourcePackage and this might have to investigated separately.

- The original idea was to use the packing properties provided by the registry classes which may cover up the fact that packaging links used to not get copied when a new distroseries was created. Actually, most of them don't, only SourcePackage.packaging does AFAICT and SourcePackage.prodcutseries does not even use it. Most properties simply query the Packaging table which may be the result of sinzui's work and the fact that the packaging links are now being copied when a new distroseries is created. So we should simply query the Packaging table, too.

- A source package may be linked to only one productseries but each productseries within a product can be linked to a different source package within the same distroseries, in addition to the same or even a different source package in another distroseries. See the attached screenshot for a constructed example. The outcome is that the safest bet is to always follow packaging links from the product side to get the collection of sharing productseries and sourcepackages. As a side effect we also catch package renames between distroseries (but not template renames, obviously).

- Since the current interface of POTemplateSharingSubset takes a (distribution,sourcepackagename) tuple (i.e. a DistributionSourcePackage) but the Packaging table links to (distroseries,sourcepackagename) tuples (i.e. SourcePackages). So it needs to pick a distroseries to determine the correct product to share with. I will use distribution.translation_focus for this and fall back to distribution.currentseries. The fall back is more a formal thing because translation_focus is set for Ubuntu and that is the only distribution for which packaging is supported, anyway.

So, I have a plan. ;-)

[Henning Eggers (henninge)]

After a little more discussion with jtv, here are some more aspects of the situation:

- Basically we have two competing ways of defining a relationship between sourcepackages in different distroseries now.
  - purely by the name (what a DistributionSourcePackage is)
  - by their linkage to the same upstream product
Since for this feature I need the second relationship, I am willing to give up the first. Mixing both would produce a complicated, hard-to-predict model.

- That said, there are still source packages in Ubuntu that don't have upstream projects (yet) so those would have empty translations at the start of each new distroseries. The solution will be to have a fall-back to the old method of sharing by sourcepackagename but only if *none* of the involved sourcepackages has an upstream link.

- In practice, the harm done by the old method should be minimal. The reason is that in addition to the same sourcepackagename sharing sourcepackages also need identical template names to share *and* have overlapping English strings in order for sharing POTMsgSets to be created. We can expect that overlap to be small.