LOCALIZATION PROJECT
TUTORIAL
Copyright © 1998-2008 72arts.com™ All Rights reserved.
The author reserves the right to revise the contents without obligation to notify any person of such
revisions or changes.
All Rights reserved. The documentation presented here does contain proprietary information protected by
copyright. No part of this publication may be reproduced, transcribed, stored in a retrieval system,
translated into any foreign language or computer language, or transmitted in any form whatsoever without
the prior written consent of the author.
72arts.com™ is a Trademark of Dr. Uwe Schwenk.
Dr. Uwe Schwenk
Wood Dale, Illinois 60191
United States
Internet E-Mail:
[email protected] Website: www.72arts.com
CONTENTS
Localization Project Tutorial 3
Project Planning .......................................................................................................................................................4
Analysis ................................................................................................................................................................4
Localization Requirements ...............................................................................................................................4
Technical Requirements....................................................................................................................................5
Workflow Design ...............................................................................................................................................6
Resource Allocation...........................................................................................................................................6
Selection of External Resources ......................................................................................................................6
Internal Infrastructure .......................................................................................................................................7
Financial Stability ...............................................................................................................................................7
Scheduling ...........................................................................................................................................................8
Localization Kit ........................................................................................................................................................9
Project Information Sheet ................................................................................................................................9
Glossary ............................................................................................................................................................ 10
Questions & Answers..................................................................................................................................... 10
Tools ................................................................................................................................................................. 10
Translation ............................................................................................................................................................. 11
Software ............................................................................................................................................................ 11
Online Help ..................................................................................................................................................... 11
Quality Assurance ................................................................................................................................................. 11
ii Contents
Software Review .............................................................................................................................................. 12
Online Help and Documentation Review .................................................................................................. 12
Bug Report ....................................................................................................................................................... 12
Project Conclusion ............................................................................................................................................... 13
Chapter 1
LOCALIZATION PROJECT TUTORIAL
According to the Localization Industry Standards Association (LISA), the localization process can be
defined as "taking a product and making it linguistically and culturally appropriate to the target locale
(country/region and language) where it will be used and sold."
Localizing a software product is a complex undertaking, involving a wide variety of activities including, but
not limited to, translation and review of the linguistic content. A software localization project is actually
the result of the combined effort of several teams: linguists (translators, reviewers, language coordinators),
software engineers, desktop publishing specialists, technical writers, web site and graphics designers, and
project managers.
The following is a complete sample localization project. This sample is meant to provide a complete
overview on what is required for effective localization. It is not product specific because it is meant as a
starting point for executing a localization project in a capacity as project manager.
IN THIS CHAPTER
Project Planning ....................................................................................................... 4
Localization Kit ........................................................................................................ 9
Translation............................................................................................................... 11
Quality Assurance .................................................................................................. 11
Project Conclusion ................................................................................................. 13
Localization Project Tutorial 3
Chapter 1 Localization Project Tutorial
PROJECT PLANNING
The different elements of Project Planning are described in the following sections.
ANALYSIS
The first step of a localization project is the analysis of the project requirements. The following are
examples of basic project requirements:
What types of content should be localized (e.g., software, online help, printed manuals, web pages,
graphics, etc.)?
What are the target locales (country/region and language)?
What activities does the project involve (e.g., software building and testing, online help compilation
and testing, etc.)?
What tools should be used?
Is a glossary available?
Is any previous translation available? If so, what percentage of the translation is usable in the current
project?
On a more detailed level, the analysis should also
examine more specific project requirements,
typically applying to software localization.
LOCALIZATION REQUIREMENTS
These requirements might address issues such as the following:
Does the software product require domain expertise?
If so, is product training planned for translators and other localization specialists?
Is any support provided for translators by in-country subject matter specialists?
Are there any specific style requirements besides those outlined in the style guide?
4 Localization Project Tutorial
Chapter 1 Localization Project Tutorial
It is worth noticing that style requirements can
vary, depending on the target audience. For
instance, the localization of a software manual
may need to accurately reflect the source text,
whereas you may need to adapt the source
content of a marketing brochure to meet the
standards of the target market.
TECHNICAL REQUIREMENTS
What are the platforms on which the software product is supported?
Should date, time, and calendar formats be localized?
Should decimal and thousands separators be localized?
Should currency format(s) be localized? What about units of measurements?
Are there keyboard accelerators that must be localized?
Should address and phone number formats be localized?
Should URLs be localized?
Should graphics be localized?
Are there any special screen layout requirements (e.g., vertical text, bi-directional text)?
Note: In a real-world scenario, this analysis is usually associated with an estimate of project costs and
budgeting. Budgeting is not covered in this tutorial.
Localization Project Tutorial 5
Chapter 1 Localization Project Tutorial
WORKFLOW DESIGN
For the localization process to work effectively, it is important to design in advance the most critical steps
of the project workflow. This involves planning when, how, and by whom the following steps will be
performed:
Localization Kit: creation and maintenance.
Terminology database: setup, translation, approval and updates.
Engineering: conversion and preparation of software files, testing of software build, validation of
localized files (checking for appropriate file format, providing technical support to linguists).
Translation and Language Quality Check: determining whether to outsource or rely on internal
resources.
Desktop Publishing: de-, recompilation and testing of Online Help, preparation of printed
documentation files for translation, final page layout, etc.
Questions & Answers: designating the point of contact for questions coming from translators and
language coordinators.
RESOURCE ALLOCATION
For each phase of the localization process, it is essential to determine what resources will be required:
Internal resources (the internal project team may consist of software engineers, technical writers,
language specialists, desktop publishing experts)
In-country resources (e.g., reviewers, technical support specialists)
External resources (e.g., freelance translators, subject matter specialists, or other external consultants).
SELECTION OF EXTERNAL RESOURCES
Due to the large volume of most software localization projects, a significant proportion of the translation
work (and sometimes also of the Language Quality Check) is often outsourced to a localization vendor or
to a group of freelance translators. Outsourcing may be risky if not enough care is taken in ensuring an
accurate handover of project information to the localization partner. This aspect will be discussed in more
detail in the Localization Kit section.
6 Localization Project Tutorial
Chapter 1 Localization Project Tutorial
The following criteria might apply for the selection of a localization vendor:
Language combinations.
Technical and domain expertise (ideally, the partner should have experience localizing similar
products) .
Internal organization e.g. How many translators, reviewers and language leads does the company
employ?
What percentage of the translation is outsourced?
Does the company employ any software engineer or DTP specialist? What are the internal
communication protocols?
What is the typical project workflow?
What are the criteria for selecting translators?
The partner should use only translators that are
native speakers of the target language, are trained
in translation, and have up-to-date language skills.
Never select a vendor who uses proprietary
technology! Make sure to clarify the ownership of
the translation memory (if used).
INTERNAL INFRASTRUCTURE
What internet/intranet capabilities does the company have?
What are the anti-virus mechanisms in place? What back-up and recovery mechanisms are in place?
FINANCIAL STABILITY
What is the company’s annual revenue?
Is the company financially sound?
Track record and references from past clients.
Localization Project Tutorial 7
Chapter 1 Localization Project Tutorial
Once the most suitable candidates have been selected, it is helpful to get a glimpse into how they would
handle a typical localization project. One of the best ways to evaluate a prospective localization partner is
to supply a Testing Kit which, depending on the project's nature, may involve Project Analysis,
Translation, and Language Quality Check.
In essence, the Testing Kit should act as a sample, small-scale localization project. This evaluation method
is invaluable in providing an overview into the company's approach, expertise, thoroughness, and
proactiveness.
For example, during the analysis and the quality check process, does the vendor submit relevant
queries?
Do queries reveal a good level of insight into the project's requirements and into the localization
process in general?
Are queries efficiently organized in a Q&A management system or randomly sent via E-Mail or file
attachments?
Does the quality of their test translation meet the project standards?
Does the vendor come up with possible solutions to the issues raised?
How accurate is their Language Quality Check?
SCHEDULING
Once the workflow design and the resource allocation have been finalized, it is possible to lay down a draft
schedule, which will include:
A list of the main project tasks
The time slot allocated for each task
The resource(s) allocated for each task
It is important to determine in advance in what format the schedule will be published and distributed and
how frequently it should be updated. In the long run, it is better to maintain a consistent scheduling
format, from project planning through completion.
The schedule proposal should be submitted at the kick-off meeting and discussed with all the parties
involved, particularly with the localization vendor and other concerned external parties. Before finalizing
the schedule, it is essential that it be approved by every person participating in the process. The following
points need to be agreed upon:
8 Localization Project Tutorial
Chapter 1 Localization Project Tutorial
Time allocations for each task are realistic.
Information and resources needed to perform each task are available.
The schedule is in line with the project priorities and with the most critical steps of the designed
project workflow.
The internal project schedule is synchronized with the schedule of any external localization partners
involved.
Some “buffer” time is allocated for unforeseen issues, such as late delivery of files from localization
vendor or late report of major software bugs.
LOCALIZATION KIT
A localization kit is a comprehensive set of data that is needed to localize a product into a number of
specified languages. In a typical software localization project, the Localization Kit is likely to contain:
The localizable items: the software and any relevant documentation (online help, user manual,
marketing brochures, licence agreement, etc.).
A set of localization guidelines, including product glossary, formatting and stylistic guidelines, specific
instructions for translators (e.g., a list of non-translatable items, translation memory settings, and
instructions for using localization tools).
General project information and requirements, such as quality expectations, detailed schedule, product
technical specifications, project history, etc.
The main purpose of a Localization Kit is to supply the localization partner with all the information they
need to successfully localize the product. Software engineers, web developers, technical writers, or product
managers who participate in the development of the software product are valuable resources. If this
knowledge is not adequately collected and transferred to the localization partner, this could heavily impact
the final quality of the localized product, reduce project management efficiency, and disrupt the schedule,
therefore increasing costs. A well organized Localization Kit can minimize these risks upfront and lay the
basis for effective project communication protocols.
PROJECT INFORMATION SHEET
One of the first items to be included in a localization Kit is an introductory file, whose aim is to provide an
overview of the project, describe the contents of the kit itself, and incorporate essential localization
instructions.
Localization Project Tutorial 9
Chapter 1 Localization Project Tutorial
GLOSSARY
To guarantee an accurate translation of the product terminology and to ensure a consistent use of such
terminology throughout the various project components, it is crucial to provide translators with a glossary.
It should be provided at the kick-off stage of the project or, in any case, before translation starts.
The creation of the glossary should start as soon as the source software and documentation files become
available. First of all, a terminology list should be set up. This is an alphabetical list of all significant terms
found in the localizable files. The terms should be accompanied by the appropriate definitions and context
information. The terminology list will then be circulated and translated into the relevant languages.
The next necessary step is the glossary review. It is important that all the parties involved in the Language
Quality Check process review and agree on the glossary. Implementing important terminology changes in a
late stage of the project is not recommended, both because there is a risk of introducing terminological
inconsistency, and because this is certain to generate additional project costs, especially if the changes are
extensive.
QUESTIONS & ANSWERS
A good Localization Kit is about effective communication between the client and the localization partner.
To make sure that all the essential product information is effectively managed and conveyed to the right
people, it is a good idea to set up a form for the exchange of questions and answers. This form will mostly
contain the questions coming from translators, concerning terms or passages that are difficult to translate
because of their highly technical nature or lack of context information. At project start, it is important to
determine who will be the point of contact for each category of queries coming from translators, and how
the queries will be categorized, processed, and shared effectively.
TOOLS
A Localization Kit should also mention which localization tools will be required for the project, and, if
possible, provide tutorials or relevant instructions for the use of such tools.
Never select a vendor who uses proprietary
technology! Make sure to clarify the ownership of
the translation memory (if used).
10 Localization Project Tutorial
Chapter 1 Localization Project Tutorial
TRANSLATION
Ideally, the translation of the software files should precede the translation of the Online Help, the printed
user manuals, and of any other documentation related to the software. This is because Online Help
projects or user manuals contain many references to the software user interface, such as names of buttons,
menu options, or screen captures. If changes in the software terminology are introduced when the
documentation has already been localized, it will be very difficult to implement such changes consistently
throughout all the documentation without introducing terminology inconsistencies or generating additional
project costs.
SOFTWARE
The localization of software involves the translation of the Graphical User Interface (menus, dialog boxes,
toolbars, buttons, etc.) and of software strings, normally displayed in error messages, tool tips, etc.
ONLINE HELP
The translation of the Online Help should ideally start when most of the software files have been
translated. The following items should be provided to ensure an accurate translation of the Online Help:
All the project glossaries
The localized software files
An up-to-date version of the running software, possibly both in the source and in the target language.
Translators should check that all the software
options mentioned in the Online Help (buttons,
menu items, error messages, etc) match the
options displayed in the running software.
QUALITY ASSURANCE
In a software localization project, Language Quality Assurance is a complex process. An efficient
Language Quality Assurance process should be carefully designed in the early stages of the project. It
should encompass the preparatory work illustrated during Project Planning (on page 4), in the
Localization Kit (on page 9), during Translation (on page 11) and only at the very end, the language
quality checks on the localized materials, which are described in this section.
Localization Project Tutorial 11
Chapter 1 Localization Project Tutorial
SOFTWARE REVIEW
Once the software files have been translated, one or more experienced linguists will select a suitable
percentage of the localized content and perform a proofreading. It is usually a good idea to limit the
number of linguists in charge of such review, to minimize risks of linguistic and stylistic inconsistencies
being introduced. The purpose of the linguistic review is to check that the translation is in line with the
quality standards outlined in the Localization Kit. This will involve checking glossary compliance and
terminology consistency throughout the project, reporting any grammar mistakes or typos, and providing
feedback on any linguistic errors found. This first review is carried out directly on the files handed back by
the translators.
After the localized content has been incorporated into the software and a localized software build has been
created, it is normally a good idea to perform a second linguistic check, directly on the localized build. This
can serve various purposes:
Detect any errors which were not picked up in the first review
Ensure that all the errors reported during the first language review have been fixed and that all
corrections have been implemented by the localization vendor
Check that all software options are translated correctly, according to their context in the running
software. For instance, the same term can be translated differently, depending on whether it applies to
a menu item or to a dialog box title.
Look out for any truncated text: this happens when the localized text is much longer than the source
text, and the software menu or dialog box is not properly resized.
Test software functionality and make sure that the translation accurately reflects the software's
behavior.
ONLINE HELP AND DOCUMENTATION REVIEW
The aim of the Online Help review is not only to check general linguistic accuracy and compliance with
approved terminology, as described above in the Software review section, but also to ensure that the
Online Help refers correctly to the software user interface. For this reason, it is recommended to test the
Online Help against the running build. If possible, it would also be good to perform a final review of the
compiled Online Help. For linguistic quality on documentation, see the section Translation Quality
Control for Documentation.
BUG REPORT
A bug report database is generally a good method for flagging and keeping track of all the errors detected
during the localization review process.
12 Localization Project Tutorial
Chapter 1 Localization Project Tutorial
PROJECT CONCLUSION
Once the project is concluded, it is good practice to create a report on lessons learned for future reference,
which outlines the project’s history, reviews the procedures adopted, and analyzes the main issues. Ideally,
this report should be created following a wrap-up meeting of all the project team members. The meeting
would be essentially an opportunity for the project team to reflect on the issues encountered and to
brainstorm on the possible solutions. Obviously, good practices should also be pointed out, and ideas
could be proposed on how to further improve them.
The following are a few examples of topics for discussion in a typical “post-mortem” meeting:
How accurate was the initial project analysis?
Did the project scope turn out to be wider than initially planned?
Was there any impact on the schedule?
How effective was the communication between all project team members?
Were all problems reported and addressed in a timely manner?
Were all components delivered according to schedule?
Quite commonly, errors are still reported after the final quality check. At this point, the project is
concluded and it is no longer possible to implement changes. It is important, however, to keep track of
outstanding errors, so they can be addressed before the next product release. A Bug Report form or
database could be created, containing a description of each error and the proposed solution for future
projects.
Localization Project Tutorial 13
