[6.1/7.0/trunk] Translation exported is not complete

[Pedro Manuel Baeza]

This has been detected from bug lp:933496, where a missing translation has triggered an investigation about that.

In purchase module, you have this menu definition:

       <menuitem icon="terp-purchase" id="base.menu_purchase_root" name="Purchases" sequence="3"
           groups="group_purchase_manager,group_purchase_user"
           web_icon="images/purchases.png"
           web_icon_hover="images/purchases-hover.png"/>

Exporting pot file, I get:

#. module: purchase
#: model:ir.actions.act_window,name:purchase.action_purchase_line_product_tree
#: model:ir.actions.act_window,name:purchase.open_board_purchase
#: model:ir.ui.menu,name:purchase.menu_board_purchase
#: model:ir.ui.menu,name:purchase.menu_purchase_config
#: view:res.partner:0
msgid "Purchases"
msgstr ""

But it must be another one comment that is missing:

#: model:ir.ui.menu,name:base.menu_purchase_root

Maybe the problem is because XML ID module is 'base' instead 'purchase', but if I export 'base' module, this comment isn't exported also.

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

It's not a bug, it's because the "Purchases" menu is shared by multiple module without any common ancestor except `base`, so it is located in `base`. As a result the proper location for this translation is in base.pot, and that's where it is, for example see:
   http://bazaar.launchpad.net/~openerp/openobject-server/7.0/view/5263/openerp/addons/base/i18n/base.pot#L1436

It is not an ideal situation because it requires you to have Purchase installed if you want to perform a manual export of base.pot that properly includes it, but it works. We always perform the export of the official translation templates on a system where all official modules are installed.

It can sometimes cause a translation to be missing in the UI depending on the order in which you installed the extra languages and modules. In that case you can fix it by updating base again.

We've tried a few different things to avoid this situation but nothing works well without having annoying consequences on other features. The simplest way to avoid it might be to never share a menuitem between several modules, using an alternative menu layout.

I would close this bug as Invalid for now, but it's not actually in the openerp-server project anyway, so it's up to you.

[Pedro Manuel Baeza (pedro.baeza)]

BTW, I'm getting same result:

http://img27.imageshack.us/img27/5065/tem5.png

That is untranslated terms, in 6.1, 7.0 or trunk, so there's must be another problem, and not only with 'Purchases' menu. Let me explore again and tell you back.

I have added openobject-server project (I selected wrongly ocb-server previously) and stay in New state until then.

Regards.

[Pedro Manuel Baeza (pedro.baeza)]

OK, I have got the path for getting terms translated:

- Create DB.
- Install purchase module.
- Run server with --update=all.

Checking previous untranslated terms, all have XML IDs referenced on foreign modules (base or another).

Is it possible to handle at module install/upgrade their foreign references translations?

Regards.

[Pedro Manuel Baeza (pedro.baeza)]

This current behaviour doesn't favor app-centric approach. I'm thinking in two solutions:

1) Handle on translation export strings that are overwritten in the selected module, but reference another one.
2) Load on install/upgrade of the module translation files affected by foreign references.

What do you think?

Or it's possible to modify, as you have said, current layout to avoid these references? BTW, this will only make up the problem, because other custom modules will suffer the same problem.

Regards.

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

Pedro,

The problem with 1) is that the location of the translation is logically the location of the record on which those translations exist. And in this case our problem is we would like two unrelated modules to both declare the same menu without getting duplicate menus if you install both, hence this rather strange trick of declaring it in the namespace of the only common ancestor module between them: "base".
Individually each of these features behave properly:
- translations MUST belong to the module on which their record are declared
- modules CAN declare a record that was initially defined in a parent module, in order to update it
- declaring a record from a parent module that does not exist in the parent module is rather a valid use case too (for migrations, backwards-compatibility, etc.)

There's mainly one place where we can detect something unusual for 1): when loading the translation for base.pot, the translation for record "base.menu_purchase_root" is initially skipped because that record does not exist yet (that's why you need to update the base module or force reload the translation to fix the UI). Due to the way ir.translation works we cannot create the entry yet because there is no valid res_id that will work. We could imagine a system to create it temporarily and add a logic somewhere during record creation to re-establish the link as soon as the corresponding record is created. However this seem quite far-fetched and definitely breaks KISS.
Detecting anything at export time seems even more complicated because the record is present and everything looks fine.

For 2) the cost of re-loading the complete translation files of parent modules as soon as some translation refers to a foreign reference seems very expensive for such a small case. It also carries a risk of requiring a full reload of most translations every time you install or update any module.

Really, both solutions (and other alternatives we have already considered) seem quite overkill for a situation that occurs for less than 5 terms in the 20k terms in OpenERP. And the addition of new cases is unlikely because this use case is *very* unusual. Only a few official Apps will need to share a menu that has never been declared in a parent module.

Finding an alternative layout that does not require this weird situation seems much simpler to me compared to the above.

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

PS: Please clarify title and description if you want this bug report to be an improvement request. Thanks!

[Pedro Manuel Baeza (pedro.baeza)]

Continued in the bug #1303918 with the data provided here.

Regards.