Translations should support Gettext's translation context

[Numérigraphe]

Gettext and Launchpad support an interesting feature for translators: strings can be attached to a context to give translators an indication of the intent of the string.
Then this context is used to find translations too, which allows the same string to have several translations.
Note: This is NOT the same as the context dictionnary that the OpenERP framework uses.

There have been several requests for this feature and it was acknowledged by the core team, but I couldn't find a bug report so I'm filing one now.

Lionel Sausin.

[Numérigraphe (numerigraphe)]

Please mark "wishlist".

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Numérigraphe (numerigraphe)]

Le 27/02/2012 13:12, Olivier Dony (OpenERP) a écrit :
> 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).
I agree, all the more as sometimes it's enough to rephrase one of the
strings to make it clear.
Lionel.

[Yannick Vaucher @ Camptocamp (yvaucher-c2c)]

Any change about accepting msgctxt keyword?

This would allow using poedit and other msgmerge tools otherwise it gives duplicate errors when you need 2 different translations

[Olivier Dony (Odoo) (odo-openerp)]

Nothing planned for the moment.. I'm afraid this has a very low priority, and
would be non-trivial: we'd need to design a simple way for developers to
provide the msgctx hint in the source directly, since we don't want to
contextualize everything (it would make a lot of useless work for translators)

Wouldn't the usual workaround of having distinct msgids work for you? The cases
where you really need different translations for the same source term *and* you
can't change the source terms to be more context-dependent are very rare, in my
experience.

For example the status "Open" and the action "Open" can easily be disambiguated
by making one or both more specific, e.g. "In progress" and "Confirm Invoice", etc.

We'll also happily accept suggestions to rename confusing source terms into
more specific ones. We've done that before the 7.0 release [1] and will for 8.0
too.

[1]
http://openerp-community.2306076.n4.nabble.com/Openerp-community-Reviewing-English-strings-Re-OpenERP-7-0-Call-for-translators-tp4641397p4641543.html

On 02/04/2014 01:56 PM, Yannick Vaucher @ Camptocamp wrote:
> Any change about accepting msgctxt keyword?
>
> This would allow using poedit and other msgmerge tools otherwise it
> gives duplicate errors when you need 2 different translations
>