|
Localization
and Linguistic Review Process
|
You can download the QA Matrix
here.
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.
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.
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.
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 readthrough 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
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
here.
If you would like to share your opinion regarding the content
of this page, please
contact
the Open Translation team.
