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.
| Test | Term Unicity |
| Type | English Glossary |
| Tools | English Glossary Report (see above for information) |
| Purpose | Detect duplicate entries in the same business field (ie. same reference, different title) |
| Actors | Whoever |
| Steps |
- Open the English Glossary report, as described in above
- Run the Action "Find duplicated terms
-
Report duplicate terms through the reporting procedure (Chapter 4).
No duplicates means that the test is passed.
|
| Follow-up actions |
- Some duplicate terms can usually be merged into one
-
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.
| Test | Term Completeness |
| Type | English Glossary |
| Tools | English Glossary Report (see above for information) |
| Purpose | Make sure all terms are well chosen and precisely defined |
| Actors | Whoever skilled in the Business Field and in English |
| Steps |
- Open the English Glossary report, as described in above
- Filter the entries by Business Field and by English language
-
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.
-
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 |
- Description must be improved if it is not precise enough.
-
Term must be changed if it is too abstract or too ambiguous and if
nothing justifies such a choice.
-
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.
| Test | Local Term Translation |
| Type | Local Glossary |
| Tools | English and Local (ex. French) Glossary Reports (see above for information) |
| Purpose | Check that the translated terms are well translated |
| Actors | Whoever skilled in the Business Field and in the local language |
| Steps |
- Open the English and French Glossary Reports, as described in above
- Filter the entries by Business Field and by English language
-
Check the English terms one by one and make sure that there is a
well translated equivalent in the local language.
-
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 |
-
Term must be changed if it is too abstract or too ambiguous
and if nothing justifies such a choice.
-
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.
| Test | Application Completeness |
| Type | Application |
| Tools | PO File (see above for information) |
| Purpose | Check that the UI PO is 100% translated |
| Actors | Whoever |
| Steps |
- Open the PO File provided by the server. Open the PO File with Kbabel or any text editor like Kate.
- Look for the untranslated terms.
- If you find some untranslated terms, report them through the reporting procedure (Chapter 4).
- The test is passed if there are no untranslated terms
|
| Follow-up actions |
- 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.
| Test | Application Internal |
| Type | Application |
| Tools | ERP5 Test Instance, ERP5 Test Cases (see above for information) |
| Purpose | Check that the translation is good, usable and complete in the context of the application. |
| Actors | Whoever, on a module per module basis |
| Steps |
- Open an ERP5 test instance and login as normal user.
- Go to ERP5 KM and access the Test Cases module.
- Select a given Test Case from the list (usually, the one you were requested to perform).
- Trigger the action "Generate a Test Report" from the "Action" menu. This generates a new Test Report.
- 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"
- Once all steps in the test report are finished, trigger the action menu to "Share" test results.
|
| Follow-up actions |
- 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.
| Test | Application External |
| Type | Application |
| Tools | Nexedi ERP5 (CRM) |
| Purpose | Check that a panel of external users accept the translation and do not complain about it. |
| Actors | Whoever Client/Usability/Management/Marketing oriented |
| Steps |
- Choose a panel of ERP5 active users (ex. 1 to 10) amongst the users speaking the language that has been translated.
- Upgrade all their ERP5 instances with the new translation, once it has been tested along all other tests described in this document.
- Notify them that they can start testing and that they can use the support procedure (whatever it is) to provide feedback.
- Whenever receiving a complaint, report the term(s) through the reporting procedure (Chapter 4).
|
| Follow-up actions |
- 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¶