Most Powerful Open Source ERP

How To Test Translations

How To showing how to test translations in ERP5.
  • Last Update:2016-07-01
  • Version:001
  • Language:en

Table of Contents

Glossary Tests

This chapter introduces translation tests which are based on the use of the Glossary. The aim of those tests is to check that all terms from the glossary are translated and that they are also well translated.

Glossary Testing Tools

This paragraph introduces the tools which are needed to perform the Glossary tests. Glossary tests are based on reports which can be generated by the glossary:

  • the "English glossary terms" report;
  • the "Local glossary terms" report.

English glossary terms report is helpful for all the glossary tests. It can be displayed or printed here:

https://www.myerp5.com/glossary/glossary_module.

You will need a user and login, as defined in the document How to Translate [RD]. When you are on this page, type "en" in the language field to filter the list and display only the English terms of the glossary.

Local glossary terms report is helpful to test the local translation of the glossary. It can be displayed or printed here:

https://www.myerp5.com/glossary/glossary_module.

When you are on this page, type the abbreviation of your local language in the language field to filter the list and display only the local language terms of the glossary. For instance, if you want to see only French terms, type "fr" in the language field.

The Glossary Tests

The glossary tests are designed to check the quality and the completeness of the glossary. This paragraph introduces the 3 tests that will be helpful to test the glossary:

  • English Term Unicity test;
  • English Term Completeness test;
  • Local Term Translation test.

Term Unicity: make sure there are no duplicate English terms

This first test will help detecting duplicate glossary entries (ie. same reference, same business field, different Title). This test is partly automated:

  • A script generates a report, gathering the Glossary entries that verify this statement: "A given combination of a Reference, a Business Field, and a Language returns several Titles in the Glossary".
  • A Tester (human) analyses this report.

This test is considered as passed whenever there are no duplicate entries.

TestTerm Unicity
TypeEnglish Glossary
ToolsEnglish Glossary Report (see above for information)
PurposeDetect duplicate entries in the same business field (ie. same reference, different title)
ActorsWhoever
Steps
  1. Open the English Glossary report, as described in above
  2. Run the Action "Find duplicated terms
  3. Report duplicate terms through the reporting procedure (Chapter 4). No duplicates means that the test is passed.
Follow-up actions
  1. Some duplicate terms can usually be merged into one
  2. Duplicate terms which can not be merged are usually the sign that the business field category is badly designed or that the choice of property was wrong in an application.
Term Unicity Test

Term Completeness: make sure all English terms are well chosen and precisely described

This second tests helps choosing precise terms in each business field. This test is performed by people who are skilled in the business field.

TestTerm Completeness
TypeEnglish Glossary
ToolsEnglish Glossary Report (see above for information)
PurposeMake sure all terms are well chosen and precisely defined
ActorsWhoever skilled in the Business Field and in English
Steps
  1. Open the English Glossary report, as described in above
  2. Filter the entries by Business Field and by English language
  3. Check the English terms one by one and look for terms which title is too ambiguous or too abstract, for terms which description is empty or not precise enough.
  4. If you find some terms which need improvement, report them through the reporting procedure (Chapter 4). Empty report means that the test is passed.
Follow-up actions
  1. Description must be improved if it is not precise enough.
  2. Term must be changed if it is too abstract or too ambiguous and if nothing justifies such a choice.
  3. Description must be improved to justify or explain the choice of the term (if the term is abstract).
Term Completeness Test

Term Translation: make sure all local terms are well translated

The third Glossary test helps translating all terms in a local language. It is the first test which requires to compare English original entries with translated entries. This test must be performed by a person in the business field and in the local language. Passing this test proves that both English and local (ex. French) Glossaries are good enough.

TestLocal Term Translation
TypeLocal Glossary
ToolsEnglish and Local (ex. French) Glossary Reports (see above for information)
PurposeCheck that the translated terms are well translated
ActorsWhoever skilled in the Business Field and in the local language
Steps
  1. Open the English and French Glossary Reports, as described in above
  2. Filter the entries by Business Field and by English language
  3. Check the English terms one by one and make sure that there is a well translated equivalent in the local language.
  4. If you find some terms which need improvement, report them through the reporting procedure (Chapter 4).
  5. Empty report means that the test is passed.
Follow-up actions
  1. Term must be changed if it is too abstract or too ambiguous and if nothing justifies such a choice.
  2. Description must be improved to justify or explain the choice of the term (if the term is abstract).
Local Term Translation Test

Application Tests

This chapter introduces tests which are related to the ERP5 application itself. Application tests in a given business field must be performed after passing Glossary tests in the same business field. A translation of an ERP5 application is considered as “good” once all application tests for all involved business fields are passed.

Application Testing Tools

In order to perform the Application tests, some tools will be needed. This paragraph consists in a list of those tools. You will need two different tools that are a PO File and ERP5 Test Cases.

PO File gathers all the terms of the User Interface, and will be generated by the server whenever needed. This file is used in the Completion Test. In order to understand how to generate a PO File, refer to How to Translate [RD]

ERP5 Test Cases: Those test cases are reachable from the Test Case module of Nexedi ERP5. You will find a Test Case for each ERP5 Express module to be tested, under the name "QA for the translation of ERP5 xxx module".

The Application Tests

This paragraph introduces the 3 application tests which must be performed at the level of the application itself:

  • Application Completeness Test;
  • Application Internal Test;
  • Application External Test.

Application Completeness Test

The Application Completeness Test checks that all the terms of the PO File are translated. Once this test has been passed successfully, we are sure that all GUI messages are translated, and thanks to the previous Glossary Tests, that they are translated properly as long as the translator who translated the .po file followed the choices made in the glossary.

TestApplication Completeness
TypeApplication
ToolsPO File (see above for information)
PurposeCheck that the UI PO is 100% translated
ActorsWhoever
Steps
  1. Open the PO File provided by the server. Open the PO File with Kbabel or any text editor like Kate.
  2. Look for the untranslated terms.
  3. If you find some untranslated terms, report them through the reporting procedure (Chapter 4).
  4. The test is passed if there are no untranslated terms
Follow-up actions
  1. Untranslated terms must be translated
Application Completeness Test

Application Internal Test

The Application Internal Test helps developers of an application to check that the translation is usable, that there are no bad translations due to lack of context/bad context, and that everything is translated. This test must be performed before releasing the application to the client or to the public. This test is really important because it is the only way to make sure that all terms embedded in the content PO file are all translated, and all terms are properly translated in their context.

This test must be performed on a module per module basis. This test requires an ERP5 test instance which can be provided by on demand by requesting it at the contact section.

This test also requires access to Test Cases in ERP5 KM1.

TestApplication Internal
TypeApplication
ToolsERP5 Test Instance, ERP5 Test Cases (see above for information)
PurposeCheck that the translation is good, usable and complete in the context of the application.
ActorsWhoever, on a module per module basis
Steps
  1. Open an ERP5 test instance and login as normal user.
  2. Go to ERP5 KM and access the Test Cases module.
  3. Select a given Test Case from the list (usually, the one you were requested to perform).
  4. Trigger the action "Generate a Test Report" from the "Action" menu. This generates a new Test Report.
  5. The Test Report document includes a copy of all steps to perform. Follow those steps. If you find a wrong translation or something untranslated, write the term and the URL in the Test Report comments. Once the step is completed, trigger the menu action “Test Succeeded” or "Test Failed"
  6. Once all steps in the test report are finished, trigger the action menu to "Share" test results.
Follow-up actions
  1. Any failures to the Internal test require to update the PO files with improved translations.
Application Internal Test

External check

The Application Internal Test helps users or clients provided their views on the translation and increase its usability before it is released at large. This test must be performed only once all the previous tests are successful. Consider a period of 2 weeks at least to conduct such a test.

TestApplication External
TypeApplication
ToolsNexedi ERP5 (CRM)
PurposeCheck that a panel of external users accept the translation and do not complain about it.
ActorsWhoever Client/Usability/Management/Marketing oriented
Steps
  1. Choose a panel of ERP5 active users (ex. 1 to 10) amongst the users speaking the language that has been translated.
  2. Upgrade all their ERP5 instances with the new translation, once it has been tested along all other tests described in this document.
  3. Notify them that they can start testing and that they can use the support procedure (whatever it is) to provide feedback.
  4. Whenever receiving a complaint, report the term(s) through the reporting procedure (Chapter 4).
Follow-up actions
  1. Complaints must be digested and processed the same way as bug reports.
Application External Test

Reporting Translation Errors

This chapter explains how to report translation errors after testing translation with each of the 5 tests.

Current Reporting Procedure

Until a better solution is available, the current reporting procedure consists of using the erp5-dev mailing list to report translation errors.

Future Reporting Procedure

The current reporting procedure does not provide scalability and must be replaced by a more manageable one.

The future reporting procedure is based on the "Bug", "Test Case" and "Test Report" modules present in ERP5 KM, in erp5_forge and erp5_consulting. The preferred reporting procedure is the use of the "Test Case" and "Test Report" modules. By using those test modules, it is possible to track the evolution of the quality of the translation over time. It is also possible to distribute tests and track their progress over a team of translators and users. If you wish to participate to the beta-testing of both modules, please request an account via the contact section.

For minor errors in the translation procedure, it is acceptable to report them through the "Bug Module" as a "Translation Error". Such reports are useful, yet less useful than performing full Test Reports.

Related Articles