Most Powerful Open Source ERP

ERP5 Guideline Translation

Conventions on how to make quality translations.
  • Last Update:2017-04-11
  • Version:001
  • Language:en

Table of Contents


This document is to define what is considered as a good translation and to explain how to make a good translation. It introduces the different tools to be used and the process to follow for each tool to reach a good translation. It will also list translation crimes, which should be avoided. It does not explain how the translation must be tested.

Definition Of A Good Translation

This section describes the characteristics of a good translation.


This means that everything is translated and that there is no remaining untranslated word/sentence. Only the user interface PO File can be tested by a machine and proven to be complete, the Content PO file must be checked by humans, as described in the "How to test translations" document. You can read the How To Translate document to understand the translation procedure.


Unambiguous means that users must not have any doubt about the meaning of a term. If a term triggers a debate between people (within Nexedi for example), it means that it is ambiguous, and must be changed. There are many financial/accounting terms, all of them have an equivalent in a local language, or different equivalents, which means that you will sometimes have to choose between different translation solutions. If you have to choose between different solutions, please consider this rule: always use the word which is the most used in your language, even if it is not the less ambiguous. This is the only exception to the Unambiguous criterion described in this paragraph.


If a translation is usable for users, then it is good. What is the goal of a translation? It is to make the program usable by users speaking a given language. If they use it and do not complain about it, then the translation is good. For this to be true, the translation must be approved within Nexedi first after the translation has passed the translation tests successfully. The acceptance of users comes after this, and confirms or denies this statement.


Documented means that each word has a proper description in the Glossary. The description should give the meaning of this word, and if needed, an example of where it is used. This rule only applies to English terms, that will be the basis of future translations. It is of course better to document each language in the glossary but this is not compulsory.


There is one exception to the "usable rule" and to the "unambiguous rule exception": the case of universal terms in ERP5. Whenever using a term which is less common or less accepted allows to create a common (yet innovative) vocabulary with consistent semantic across different business fields, we should prefer innovation and consistency. This rule must be used with care though. Here are some details:

ERP5 tries to be very generic in all its aspects. This is a recognized innovation of ERP5, acknowledged by IEEE scientific publications. It uses the same technical terms, the same modules and the same conventions for very different business fields. The workflow state "stopped" is for example used both for accounting and trade. If the "usable rule" or the "unambiguous rule exception" lead to a situation in which the same translated term (ex. Closed) refers to different technical terms in ERP5 (ex. stopped and delivered workflow states) depending on the business field, then translation breaks the universality of the ERP5 design and may even lead to confusion in the company: what will happen whenever accountants and sales people discuss about "Closed" documents, which are documents in the last workflow state for one group and documents which still need to be worked for the other group. Not only such a translation breaks the universality of ERP5 design but even creates a fake sense of commonality for terms with very different underlying semantic.



Configure Test Method

Rule is a Predicate and if rule.test(simulation_movement) is True, the rule will be expanded inside the simulation movement.

Table of Contents

How it works

For root level applied rules (eg. Order Simulation Rule etc.), it can be blank because root level applied rule is decided by 'XXX_getRuleReference' type based method. (XXX it is inconsistent and may be unified in the future.)

After r32519 (2010-02-15), the hierarchy of simulation tree is modified.

  • old simulation tree
AR (Order Rule)
+-SM (order:Sale Order Line, delivery:Sale Packing List Line)
  +-AR (Invoicing Rule)
  • new simulation tree
AR (Order Simulation Rule)
+-SM (delivery:Sale Order Line)    <-- NEW
  +-AR (Deliverying Simulation Rule)          <-- NEW
    +-SM (delivery:Sale Packing List Line)
      +-AR (Invoicing Rule)

Please configure test method appropriately to support intended simulation hierarchy, i.e. test methods for old rules should support old simulation tree only, and test methods for new rules should support new simulation tree only.

Please also note that the implementation of new rules will be modified quite soon, and reconfiguration will be required according to coming modification.

Configure Trade Phase

To use BPM, you need to specify the trade phase. (to be written more)