The translation of some properties such as title is

• sometimes not required
• sometimes implemented by ui message
• sometimes implemented by content message

There is no way to clearly distinguish those cases in current ERP5. A proposed solution is to define a notion of translation policy for types and documents.

Translation Policies

There could be 3 translation policies:

• No Translation: in this case, titles, descriptions, etc. will not be translated
• UI Translation: in this case, titles and descriptions would be translated using
  • the ui message catalog without adding new messages
• Content Translation: in this case, titles and descriptions would be translated using
  • the content message catalog with automatic addition of new messages

The choice of a policy could be defined at the level of the portal type and overriden at the level of the document.

Examples of applications:

• Account: we need Content Translation
• Module: we need UI Translation
• Accounting Transaction Line: we need UI translation
• Accounting Transaction: we nee No Translation

Default Message Catalog

A variation to this approach is to define a default message catalog at the level of the portal type and at the level of the document. Automatic message addition then becomes a property of message catalogs which defines their behaviour.

Current Strategy

After an intensive discussion, we have decided to take this approach:

• Define a new attribute translatable in a property.

• ERP5Type automatically generates some accessors and another property (e.g. getTranslatedTitle, title_translation_domain).

• Extend ERP5TypeInformation by adding a new tab Translation to define how to translate each translatable property.

• The translation accessors use getPropertyTranslationDomain to obtain a translation domain name.
• If an object defines a translation domain, getPropertyTranslationDomain returns it.
• If a portal type defines a translation domain, getPropertyTranslationDomain returns it.
• Otherwise, getPropertyTranslationDomain returns None, and no translation is performed.

So translation domains are usually defined in portal types, but you can override the behavior easily in objects by setPropertyTranslationDomain.

Note: this mechanism can be extended for more than translation, i.e. how to access data.