Hi,

The problem actually comes from a limitation of Launchpad's translation system. We had never hit it before because there was only one fully-synchronized translatable series of OpenERP. The problem is that PO templates entries are not only shared between series, but their comments are shared as well, regardless of the destination series. 

The obvious advantage of sharing the POT entries between series is that translators can actually translate the terms only once in any series, and they will automatically be translated in other series where the same terms appear. That is absolutely vital. However the POT comments are carried over with the translation, and therefore are being exported in all series, even those where the POT comments were different for that same msgid entry.

As the most recent series (trunk or latest stable) are most likely to see their POT files updated, they will ultimately override all PO comments, and in the case where the term is used in different places, this could make it disappear in some places for older series. We can keep fixing PO comments left and right as in the current merge proposal, but this will not really fix the issue, only move it or delay it.

We discussed this with LP developers and changing this in Launchpad is not trivial, and goes deep in the db structure of the translations system. The POT comments being really meant as mere comments, their system cannot really be blamed for mixing them a little bit - they're just supposed to help translators - it's only a problem because OpenERP treats them as more than just comments.

So the quickest way to fix this correctly is to fix our framework globally, possibly in all affected series.
I can think of two options at this point:

1.  Override PO comments with POT comments.
When loading PO files, we could first pre-load the corresponding POT file, and use the comments from the POT file instead of those from the PO files. As LP does not touch the POT files, the right PO comments (from the right series) will still be in the POT template. Downside: this represents a no-negligible amount of code, parsing time and risk, especially as it will be needed in stable series too.

2. Treat the translation type a hint, not an exclusive condition.
In ir.translation._get_source(), the ``types`` parameter is currently treated as an exclusive filter: if no translation is found within the given types, no result is returned at all. We could change this to make ``types`` a non-exclusive hint of the type(s) that are preferred when looking for translations. If a translation of the right type(s) is found it it will be returned with higher priority, but if none is found, candidates with another type will still be returned.
This seems to carry little risk as the translation type is really just a hint... we have no reason to believe that a translation with the wrong type is not going to be correct. In fact we have no way of giving a different translation for the same term at the moment, so they cannot be different even if we wanted.

I tend to prefer solution 2 as much simpler and less risky, so I whipped up a quick patch (attached) that should apply cleanly on any 6.0/6.1/trunk branch. Could any of the affected users double-check it works in their case and does not seem to have any bad side-effect?

Thanks!