[6.1/7.0/trunk] Menu translations doesn't work after module installation because they have ID referenced as "base.xxx"

As seen on bug #1294887, some menus doesn't appear translated because their definitions on XML have an ID with reference to the base module, so that translation export tool include them on base translation file, not on each module. In this serie of consequences, only loading base module loads these translations, but on the base loading, translations are not loaded because the elements don't exist. The only way to handle this is to install module (for example purchase), and then update base module again.

An easy solution to this is to rename these IDs to another ones, and it's very interesting that this lands on trunk before the v8 debuts, because this change is not easy to be done on an stable branch.

This is the complete list of menus with this problem that I have detected:

account:
· base.menu_action_currency_form

association:
· base.menu_association
· base.menu_event_config
· base.menu_report_association

base_action_rule:
· base.menu_base_action_rule_admin

base_calendar:
· base.menu_calendar_configuration

crm:
· base.menu_sales
· base.menu_import_crm
· base.menu_sale_config
· base.menu_base_partner
· base.menu_crm_config_lead
· base.menu_crm_config_opportunity
· base.menu_sale_config_sales
· base.next_id_64

crm_claim:
· base.menu_project_report
· base.menu_aftersale

crm_helpdesk:
· base.menu_project_report
· base.menu_base_partner
· base.menu_aftersale

event:
· base.menu_event_main
· base.menu_marketing_config_root
· base.menu_report_association

hr:
· base.menu_crm_case_job_req_main

hr_recruitment:
· base.menu_crm_case_job_req_main

idea:
· base.menu_tools
· base.menu_lunch_survey_root

marketing:
· base.marketing_menu

marketing_campaign:
· base.menu_report_marketing

membership:
· base.menu_association
· base.menu_marketing_config_association
· base.menu_report_association

mrp:
· base.menu_mrp_root
· base.menu_mrp_config

multicompany:
· base.menu_action_inventory_form

plugin_outlook:
· base.menu_base_config_plugins

plugin_thunderbird:
· base.menu_base_config_plugins

product:
· base.menu_sale_config_sales
· base.menu_product

product_margin:
· base.next_id_73

project:
· base.menu_main_pm
· base.menu_definitions
· base.menu_project_config_project
· base.menu_project_report
· base.menu_definitions
· base.menu_project_config

project_long_term:
· "base.menu_project_long_term

purchase:
· base.menu_purchase_root
· base.menu_procurement_management_supplier_name
· base.next_id_73

sale:
· base.menu_base_partner
· base.menu_product
· base.menu_invoiced
· base.next_id_64
· base.menu_base_partner
· base.menu_base_config
· base.menu_sale_config

subscription:
· base.menu_tools
· base.menu_lunch_survey_root

survey:
· base.menu_tools
· base.menu_lunch_reporting
· base.next_id_10

I know that there are some modules that redefine menus because you wanted in the past reduce the coupling between modules, but these are the only solutions I see:

1. Set again some dependencies. Not desirable.
2. Create glue modules with the shared menus that are installed as dependencies of the others. Not the best, but it works.
3. Put that menus definitions on base, and add an active field on menus that allows to hide some menus. On modules that need this menu, you would define the menu again with active flag set to True, and translations will be already correct.
4. A variation of the last one, as all these cases are shared root menus, is that on web client, if there is a root menu that doesn't have any children, you can hide it. Less elegant.
5. At last, develop a method, as commented on the other bug report, to handle translation with foreign modules IDs. The costliest (on development and processing time), but the best to avoid any problem.

Let me know if you want me to help you on the MP.

Regards.