| h3. Localization and Linguistic Review Process |
| h3. !trans-qa.jpg|align=left! |
| |
| You can download the QA Matrix [here|^Translation_QA_Template_Doc.zip]. |
| |
h3. \\ \\ \\
Localization and Linguistic Review Process\\
You can download the QA Matrix [tmpSpace:here|^Translation_QA_Template_Doc.zip].
|
| h4. What is Localization (L10N)? |
| |
The term "localization" was paradoxically used in connection with the term "globalization" at the end of the 1980s, though in fact it represents the opposite principles.
|
... Globalization is the process of designing or redesigning a product so that it can be localized (made local). The basic principle of localization is the adaptation of the wording and style of the source language to the culture and sensibilities of the target language. In a sense, "localization" has superseded the term "translation" and made it "politically correct".
That's why the first requirement for any translator in the localization industry is to be a native speaker with a sense of diplomacy.
In the software and marketing arena, the language used is critical to ensuring the success of a product. The language must be accessible to a wide variety of people from different environments, while at the same time respecting their culture and sensibilities in such a way that the target customers feel that the product was designed, developed and documented in their own country to meet their own specific needs.
If this is the case, the localization process has achieved its main goal. |
h4. Focusing on End Users |
| |
Customers of IT products can be divided into two or three main categories: developers, administrators and engineers, who are quite familiar with the English language since it has become a standard, and end users.
|
... End users are "all the rest": students, doctors, teachers, secretaries, linguists, translators... whose expectations regarding the language and documentation are much higher than those of a developer, who has the technical expertise to deal with the main issues of software or hardware and is not focused on the step-by-step instructions of an Online Help.
|
The end user also represents the majority of customers (numerically speaking). That's why the language should be correct, informative, technical but not too technical, easy to read and easy to carry out. Linguists, who have perfect knowledge of their native language as well as the source language, and good technical understanding, are the best candidates for performing the localization of a product for end users.
|
| |
| h4. The Review Work |
| |
The review work - the importance of which is often underestimated - has the purpose of giving the translation work, which is often performed by several translators, a uniform quality.
|
... The task is normally performed by one, or at most two, reviewers and should guarantee consistency of terminology and style, as well as further checking of the translation accuracy.
The ideal scenario would be to combine the language skills of a linguist with the technical expertise of a developer or engineer. While the linguist performs the translation, the engineer performs the review work to confirm the technical accuracy.
But even if this ideal scenario is not always practicable, the review work is the final, essential step in the localization process and should always be taken into consideration. |
h4. Linguistic QA |
| |
Glossaries and style guides are the "tools" of both reviewers and translators. Since it's very likely that there are more than two translators working on the same translations, glossaries and style guides are the "rules" laid down before the work begins, rules governing the work of all participants. The reviewers apply the tools as parameters in making their corrections.
There are several methods for performing the review, and several levels of feedback. Depending on the time and resources available, the work can be performed in one or two steps - but it's recommended to assign no more than 2 reviewers. Of course, the ideal solution would consist of a fast read-through to check the text's readability, followed by a much more thorough reading to check |
| |
* terminology,
* comprehension of the source language |
... * stylistic accuracy.
If, as in most cases, this is not possible, a single-step thorough reading will suffice, provided that all of the above-mentioned aspects are checked.
For work that has been translated for the first time, we recommend performing a comprehensive review of the text (100% check). In the case of updates or product patches, where little is added or modified, a spot check is a reasonable alternative to a comprehensive review.
Of course, several types of translation errors exist, and the most difficult task in localization feedback is the attempt to communicate how "good" or "bad" the overall translation is - in other words, measuring its quality in an objective way.
At Sun Microsystems, our linguists have endeavoured to apply the principles of engineering QA to linguistic QA. We identify "bugs" instead of "mistakes" and assign a priority instead of a severity.
For example:
* A P0 bug affects encoding (show stopper)
* A P1 bug affects usability (incorrect translation negatively impacting the user experience)
* A P2 bug affects readability or accuracy |
* A P3 bug affects style and causes minor readability issues
|
| h4. Feedback and Quality Trends: the QA Matrix |
| |
| h4. Feedback and Quality Trends: the QA Matrix |
When a product, for example a software program, is being localized into a language, it will very likely undergo several release processes during its life cycle. In this case, keeping track of the quality issues is critical to guarantee improvements and plan targeted corrective actions.
|
... At Sun Microsystems, the "bugs" found in the translation are listed in a (QA Matrix) template and compared to other parameters like word count and target customer: end user, developer or administrator. The parameters for end user customers are more strict. At the end, the macros in the template compute the feedback, which is a quality "level"
We have identified 35 quality levels:
* Level 1-9 \-> GO The quality is very good. No major risks exist for the product.
* Level 10-18 \-> GO\- The quality is acceptable, but must be improved in the next release.
* Level 19-32 \-> Full / Fail A comprehensive review (100%) must be performed; all corrections must be implemented.
* Level 33-35 \-> Retranslate. Show stopper. A new translation and a new review cycle are required.
In fact, the level constitutes a "measurement" of the linguistic quality. |
This level, compared to the feedback from the previous release feedback, allows the creation of trend charts and the optimal allocation of the budget (or efforts) to ensure more targeted improvements.
|
| You can download the QA Matrix
[tmpSpace:here|^Translation_QA_Template_Doc.zip]. |
h4. Feedback |
| |
| If you would like to share your opinion regarding the content |
| of this page, please
[contact
the Open Translation
team|http://developers.sun.com/contact/feedback.jsp?&category=sdn&mailsubject=Open%20Translation%20feedback]. |