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.
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.
Write a complete description for each term that enters the glossary.
All documents must be written in English (British Englsh). Other languages only
depending on demand.
All script names, portal_types names, form names, field names, workflow state
names, etc. should also be written in "British English" and will be translated
into other languageswith the Localizer tool.
The user interface has to be "business oriented" and localisation work of the
user interface has to be easy ERP5 technical vocabulary should be banished from the user interface.
Start Date (on packing list)
Destination Section (on a sale order)
Make sure you understand the difference between Module Portal Type and Document Portal Type
Modules portal type titles are part of the UI and shall be translated with erp5_ui. The
getTranslatedTitle method will use Localizer's erp5_ui catalog to
translate the title of the module document when displayed in the page templates.
Document portal type titles usually do not have to be
translated. Sometimes in a multilingual environment you may want to translate
document's title, in that case you should use erp5_content. Keep in mind that
this may add lots of messages in you Message catalog, and cause database size problems.
It is impossible to have a perfect translation, whenever the vocabulary used in
the native language is wrong. Of course, an inappropriate original term will
trigger off inappropriate translations.
If you think that a term is inappropriate in the native language of ERP5
(which is English), do not translate it. This term will be reported during the
Test Procedure and worked on by the Team.
Without context, it is impossible to translate ERP5, because a given word can
have many different meanings, or can be either a noun, an adjective or a verb.
If you do not look at the application during the translation procedure of the
Glossary, you might give wrong Titles and Descriptions to certain terms. The best
example is the Order word, that can be seen in those cases:
Conclusion: there should be 3 terms: Order Action, Sort Order, Order.
Look at the context, find where the term is used in the application and what for.
Once you have found this information, translate with the most precise word and
unambiguous word you can.
Translating a PO file without looking at the application is a translation crime
because it will generate bad terms, with wrong or inappropriate meanings. Same
thing as for the glossary, if the context is lacking, do not translate the term,
and ask for help of people who might know where the term is used. If you find a
term that looks like bogus or unused in the application, please report this term.
Almost nobody is able to know all the terms of an application and their
appropriate translation, because working on translation implies that at least
one of the two languages you are handling is not your native language. Working
without tools or advice will obviously lead to inappropriate translations.
To avoid this, you might need some help for your translation, for instance if
you do not know how to translate a term. You can use the links listed above
to look up translations in case you are in doubt on a specific translation.
This is a basic advice but not working alone is the key for achieving a good a
translation. Indeed, once the basic terms have been translated, you will find
out that ERP5 contains many specific terms related to those different fields:
Accounting, trade, customer relationship management.
In order to make sure that your translation is correct, or if you have any doubt
about a term and you do not find an answer in the Glossary, try to find an
answer using the options of this list, and remember that this is better not to
translate a term rather than translating at random:
Finally, if you have a real doubt about a word and can not find an answer in
those tools, ask the people around you to help/advise.