Comment 2 for bug 939371

Some thoughts...
I think this was never actually reported because we were not sure about Launchpad support for this.
Since then I have had a confirmation from LP developers that the translations UI does support it, and will simply consider the (msgid,msgctxt) pair as the translation key instead of simply the msgid.
This means translators will have to translate those 2 strings individually, which is in fact the goal. However that also means we should only use this very sparingly, for the few cases where 2 identical english terms need different translations, such as "Open" (the state) and "Open" (the action).

We should *not* use the msgctxt parameters to replace the OpenERP-specific "typing" of our translations, which are more of a hint telling the system where those translations are supposed to be used - but not that they should in fact be different.
In this area we have a bit of discrepancy between the ir.translation model and the GetText standard. We have separate entries in ir.translation for each of the applicable "types" (e.g. report/code/view), technically allowing different translations for each, whereas in GetText PO we will only be able to have a unique "msgid" entry for those, only allowing one translation (and that is the desired behavior, as in 99.99% of cases we will not want to have different translations).
We could probably drop this useless duplication from ir.translation, and for the 0.01% of the cases where we actually need the "report" version of the term translated differently from the "field label" version, we will be able to spawn a new "msgctxt" variant.