And not just translation
The goal of localisation is to adapt a software to the language and culture
of a new market, and this requires a great deal more than mere translation.
Below, we have listed the tasks involved within a full-scale localisation
Since one of our guiding principles is flexibility, we can of course take
a modular approach and handle any combination of these services or the
entire project. In this way, we can adapt to your individual needs and
work in collaboration with your internal team.
All aspects of localisation must be carried out for each new product.
For subsequent versions or builds, however, it is not always essential
to carry out each task.
Receiving and installing the product
The localisation services supplier must, of course, first install the
software. This requires the right operating system, which may be different
from that normally used by the translator. The installation should be
carried out by a power-user, who will already take notes with a view to
the localisation of installation procedures at this point.
Glossary creation and maintenance
The project (product) glossary is required to ensure consistency throughout
all screens and documentation. Building a glossary will make it possible
to first check the consistency of the source text: localisation services
are also quality assurance services for the original product. Glossary
creation starts with an analysis of all source texts and screens, but
a glossary is never frozen before the final delivery. In fact, maintenance
procedures play an important part in the overall quality of any localisation
User interface glossary
The first task is to list all strings in menus, dialog boxes, commands
and error messages. This results in an extremely comprehensive list of
all terms related to the product. A term is by no means words alone: the
glossary should also contain all character strings that appear more than
once in the entire product and its relevant documentation. Whether such
strings must then become glossary items or be included in translation
memories must be determined from case to case. External terminology resources
are often required for optimum adaptation to the standards of a given
computing environment. The MSWindows standard terminology, for instance,
is available for developers as bilingual equivalence tables for a specific
product. However, all the tables are US English based and the English-French
table for a given product is not necessarily based on the same structure
as that of the English-German table! Building the corresponding French-German
dictionary is therefore no easy task.
General project glossary
In addition to computing terms, product specific terminology as used
in manuals, CBT, on-line help or even packaging documentation mainly consists
of technical jargon. This means that the localisation supplier must have
a sound knowledge of the technical field, and an excellent network of
specialised translators. It is important to note that a translation company,
even specialised in a single field, is first and foremost a translation
company, and it is the client who is the field specialist. Building the
general project glossary must therefore be approached and carried out
as a joint project. Usually, this type of collaboration is of surprising
benefit to the client company, which gains a completely new insight into
its own corporate terminology.
Translating all strings should normally be carried out by translating
resource files, but there are still developers who think hardcoding the
text is easier, or that the project is to upgrade older software where
screen text is written within the code. This of course requires a very
careful translator. Translators should be informed about the maximum number
of characters in each string of the original screen, since adapting to
this will drastically reduce resizing costs. Ideally, developers should
take localisation needs into account and allow for some increase in the
length of string. But this is an ideal scenario. Following the resizing
of screens, a control of the localised version must be carried out, i.e.
all screens must be checked visually! Language and layout errors must
then be corrected. Checking the localised version also means checking
the software, and if required sending bug reports and implementing the
subsequent code modifications.
User manual localisation
Here again, translation is not all it takes. The writer's approach is
sometimes highly culture-related, and must be modified in line with a
completely different cultural environment. The old Netscape user manual,
starting with "Hi Mom, I got a new job..." would sound ridiculous in French.
Indexes require more than translation. Think of the German compound words
resulting in several words once translated. Where do you want the index
tag? For which index entry level? Re-indexing is often a must. Screen
captures must of course correspond to the localised version, and are part
of the manual localisation tasks, and include resizing, formatting, etc.
Screen captures may include art work. Usability testing is also part of
the process: does the localised version of the user manual provide accurate
help for the user? After final content QA at all levels, the user manual
must still be formatted for the desired media, i.e. on paper or CD.
Online Help localisation
The content of online help is quite similar to that of a user manual,
but its presentation, handling and navigation are different. In a cleverly
established documentation architecture, where the writing is consistent
in terms of vocabulary and style, sentences or segments are often identical
in both the online help and the user manual. Using translation memory
tools thus leads to greater consistency, faster delivery, and cost savings.
Here again, however, translation quality is not everything, and within
the localisation process it is essential to format the content, to compile
the online help, to tag and test keywords and cross references, to ensure
context sensitivity, and to test functionality before creating final localised
online help and online manuals. And equally, the text is not everything.
Help contains art work, screen captures, hotspots and other bitmaps that
require capturing, creating, editing and compiling.
CBT localisation Requirements
They are quite similar to those for help, even if content and media might
be different. Again, non-linguistic tasks are as important as translation
Is equivalent to a small software localisation project, with the incorporation
Packaging texts, labels, brochures, registration cards and various marketing
texts. Here, the preferred media is often paper and the layout must be
created accordingly. Here, translation quality criteria are not the same
as those for technical texts, manuals or help. In this case, the objective
is not optimum usability, but maximum appeal.
Other related translations
White papers, retailer information, media documentation and other texts
might be part of the overall project, and require pure translation "only".