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

Introduction

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.

Completeness

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

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.

Usable

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

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.

Universal

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.

Recommendation

#

Add Complete Description To Glossary Terms

Write a complete description for each term that enters the glossary.

Rule

#

Document Content Is Written In British English

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.

Good Examples:

Organisation
Organisation

Bad Example:

OrganiZation
Société

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.

Good Examples:

Shipping Date
Customer

Bad Examples:

Start Date (on packing list)
Destination Section (on a sale order)
#

Use Localizer For Module Title Translation

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.

Crime

#

Never Forget The Original Translation Can Be Bad

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.

#

Never Translate Without Tools Or Advice

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.

#

Never Translate Glossary Without Looking At Application

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:

  • Order is used as a verb in Order workflow order_action transition.
  • Order is used as a noun for properties used for sorting, like int_index.
  • Order is used as a generic term for Purchase Order or Sale Order.

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.

#

Never Translate PO File Without Looking At The Application

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.