A Beginner’s Guide to High-quality Software Localization · A Beginner’s Guide to High-quality...
-
Upload
truongtuong -
Category
Documents
-
view
276 -
download
0
Transcript of A Beginner’s Guide to High-quality Software Localization · A Beginner’s Guide to High-quality...
A Beginner’s Guide to High-quality Software Localization
© 2012 Net-Translators Ltd. All rights reserved.
A White Paper
By Shy Avni & David Sommer
May 2012
CONTENTS
Introduction ............................................ 1 Why Software Localization Often Fails ... 2 Internationalization ................................ 2 Get Ready ............................................... 3
Determine Your Launch Strategy ........ 3 Schedule Your Resources .................... 4 Prepare Your Product ......................... 4 Plan to Manage Change ...................... 6 Build Infrastructure............................. 6
Translation & Testing .............................. 8 User interface ..................................... 9 Documentation ................................. 11 Online Help (OLH) ............................. 12
Deployment & Debrief .......................... 12 Working With a Localization Partner .... 13
Multilingual Testing Facilities ........... 13 In Summary........................................... 13
INTRODUCTION
It is common knowledge that software localization is the process of adapting a
software application – its language and other locale-specific aspects – for use in
foreign-language markets. The steps that go into localization, however, are less well
known. Translating user interface (UI) strings is central to the localization workflow,
but it’s only one part of a complex process in which taking shortcuts often ends in
mistakes, product failure, brand erosion, and, sometimes, user harm.
This paper offers a high-level overview of the main steps required for localizing
software. Its goal is twofold: to provide software companies in many industries
with a basic understanding of the localization process, and to help them be better
prepared to work with a localization provider, also known as a language services
provider (LSP). By following these steps in collaboration with an LSP, you can easily
produce localized versions of your software that reflect the same high quality and
user appeal your development team worked hard to achieve in the source-
language product.
NOTE: It’s important to note that this is only a general overview of a complex
process; there are many issues specific to each company, software, industry, etc.,
that may impact your company’s localization workflow. In addition, for the sake of
simplicity and understanding, many steps are presented here in a somewhat linear
order. In practice, it is common for these steps to be cyclic or iterative in nature.
A Beginner’s Guide to High-quality Software Localization | Page 2
WHY SOFTWARE LOCALIZATION OFTEN FAILS
Despite the ubiquity of online resources aimed at helping software professionals
learn about localization, failed international product releases are not uncommon.
Many companies skip steps in the preparation phases or begin translating without a
thorough, up-to-date localization plan. Some allocate inadequate budget or time for
localization then find they have to take shortcuts to stay on budget/schedule, such
as reducing testing or using inexpensive machine translations. And many underestimate
the ROI of localization expertise, instead hiring inexperienced or translation-only
vendors or using staff with little or no experience in localization project management.
Any of these decisions can doom a localization project to delays and cost overruns as
issues surface during localization, compromising product quality or reliability in ways
that go undetected until the products are in the hands of customers.
Avoiding these common mistakes can not only increase the quality of your localized
products but can actually reduce the time and cost required for all your localization
efforts. For many companies, the easiest and most cost-effective way to ensure
success is to partner with an experienced LSP specializing in software localization.
INTERNATIONALIZATION
Before localizing any software product, it is paramount that it be ready for translation. If
this is the first time you have localized this or any product, internationalization, or
i18n, is crucial. I18n is the process of generalizing a product during design or
development so it can be easily adapted for various languages and locales without
engineering changes or redesign. It makes localization easier, faster, and helps you
achieve the highest quality product.
There are many online resources available to help you learn more about i18n best
practices and internationalize your software. Many websites offer i18n checklists to
assist you in verifying your software’s readiness. I18n consultants and many LSPs can
help you review your product thoroughly prior to localization, or, ideally, in the
architecture stage of development to lay a solid foundation for efficient localization
later. The more you invest in the i18n process, the more efficient and cost-effective
your translating and testing efforts will be. Decisions made, changes implemented, and
problems resolved once during the i18n phase will avoid the need to address these
issues during localization of each software component in every language.
This ‘early prevention’ theme is so important, it bears repeating. With multiple
components and many target languages, you don’t need a math degree to see that
investing time to correct a design issue or mistake early – at the i18n stage or during
the source review phase – avoids the need to detect and correct the many mistakes
it propagates later. Choose your favorite saying about prevention: 1/10/100, “an
ounce of prevention is worth a pound of cure,” and so on. They are all true in
software localization.
A Beginner’s Guide to High-quality Software Localization | Page 3
GET READY
Before undertaking any localization project, there is much to be done. Preparatory
steps, such as the ones below, will help you ready your product for efficient localization
and help you collaborate with your LSP more effectively. They include tasks such as:
Planning the launch strategy of your localized products
Determining and scheduling the internal and external resources
Readying your software product
Creating terminology assets (glossary and termbase)
Building other localization infrastructures as needed
Training key team members
Deciding on a program for change management
Developing or updating test plans and test cases.
Determine Your Launch Strategy
Localization can formally begin only when the source version of your software is
frozen. But your code-freeze strategy will be influenced by several factors, one of
which is how and when you intend to launch the localized products. Will they be
released at the same time as the source-language version? Months later? All at once
or in tiers? And so on. So even before you begin working with your LSP, think through
your launch plan and timeline – from code freeze to deployment – and schedule
localization tasks accordingly. Regardless of the launch strategy you choose, having a
clear grasp of the impact that localization will have on your development timeline will
ensure that adequate time is allotted for thorough localization.
Remember: not leaving adequate time is one of the most common mistakes some
software companies make when planning for localization.
FOR EXAMPLE
For a simship strategy (simultaneous shipping), plan to start translating and testing drafts early. When the final software is ready, only a small effort should be needed for release. This approach may cost more but reduces time-to-market, enabling you to achieve faster ROI and capture market share earlier.
Releasing localized products in tiers (strategically selected groups of languages) with or after the English version is launched, calls for a different localization timeline.
A Beginner’s Guide to High-quality Software Localization | Page 4
Schedule Your Resources
Developing any software product requires careful resource scheduling; localizing
software is no different. Planning ahead for the localization stage gives both your LSP
and your internal localization project manager enough lead time to allocate the best
resources for your project.
Assigning and involving internal resources, such as in-country reviewers, testing
personnel, developers, etc., early in the localization planning stages commits their
availability and helps them feel more invested in project success. One important
internal resource that may require longer lead time for many companies to find and
schedule is in-country reviewers. In-country-review (ICR) is a crucial localization step
intended to be a final check of translations for accuracy, terminology, language
quality, and compliance with country standards. They are an invaluable resource for
final reviews and approvals at various stages of the project. You will want to designate
one primary internal contact for each target language to act as an in-country reviewer.
It is not always possible or practical for some companies to find or allocate in-country
resources. If this is the case for your company, your LSP can help you address this by
either locating and assigning a power user in the target country or preparing
translators to complete the final verification cycle.
Prepare Your Product
Your developers worked for months or years to perfect a software product in one
language, usually English, and most software elements – user interface (UI), online
help (OLH), documentation, etc. – will be impacted by localization. Whether the
product has been properly internationalized or not, a thorough review of the UI
design and text used in each software component helps to find and correct issues
with design or language use before translation. This avoids propagating mistakes into
every language, reducing errors, preventing time delays, and lowering cost.
How does problematic language end up in final source text? Often, the English source
text was not written with localization in mind, it was written by developers for whom
English is not a native language, or it was not fully reviewed for compliance with
corporate standards. Without detection, any of these issues could impact all of the
translations.
Design-related issues
Pre-translation source review can often detect and relate to the design of product
components (namely the UI), such as:
text within the graphics, charts, and tables that has not been properly externalized,
thus cannot be easily extracted for translation
graphics containing text that leave insufficient or no room for text expansion for
localized text (typically 20-30% for European languages). This is most noticeable in
FOR EXAMPLE
When a source text containing three errors and four instances of US-centric English is translated into 10 languages, the translated texts can include 30 syntactical or linguistic errors, and 40 potential cultural references that may not be relevant or understandable in the target languages.
A Beginner’s Guide to High-quality Software Localization | Page 5
UI elements such as menus, buttons, and anywhere the space allotted for text is
limited or dictated in some way by visual elements.
Format and content issues
Software components should also be reviewed to identify and address potential
issues with both content and content format. Different country standards can make
some issues easy to detect and trivial to correct, others are more subtle to catch.
Examples of such issues include:
characters, numerals, special characters, and diacritical marks
script direction: left-to-right, right-to-left, top-to-bottom
date and time formats
numeric and currency formats
weights and measures
telephone numbers and addresses
names and titles
social-security, national identification, and passport numbers
capitalization and punctuation1
ambiguous text or technical mistakes
locale-specific issues such as cultural appropriateness or political sensitivity.
These are just a few of the types of issues that should be examined and edited as
needed during pre-translation source review. There are many, many other types of
content and content format issues that may vary by the industry, company style,
target locale, intended audience, etc.
Before we leave the subject of preparation, it’s worthwhile to make a comment
about finding issues early in documentation. In most software apps, documentation
has the highest word volume. Consequently, careful scrutiny of the documentation
text is imperative because the cumulative effect of source text issues can pose so
many potential challenges during translation and testing. During internationalization,
it is highly recommended that you choose tools for content management (CMS),
authoring, and desktop publishing (DTP) that support localization into your target
languages. Many of these tools include features that can help you prepare source
documents for localization, reducing the cost and time-to-market.
Pseudo translation
Highly recommended before translation begins, pseudo translation is an enormously
effective way to save cost and time during both translation and testing of each
software component. It comprises a series of tests that emulate translation into the
1 Shneiderman, 1998
A Beginner’s Guide to High-quality Software Localization | Page 6
target languages using the same characters as actual translations and a logical text-
expansion algorithm based on language expansion estimates. Here again, problems
detected and addressed during this phase eliminate the need to detect, report, and
resolve the same problem in each target language.
Getting help
There are many options for guiding you in preparing files for localization, such as:
Online resources on how to “write for localization”
Time- and cost-saving tools to help you review source materials for problems
Features in CMS and authoring tools for reviewing and preparing source text
LSPs who can assist you with:
- assessing the level of effort and changes required before localization
- reviewing and preparing the source files for you
- collaborating with your developers to choose localization-friendly terminology
or UI text.
Best practices
Because correcting errors in the source is so important for every product and every
localization project, it is recommended that you establish a disciplined approach to
preparing and reviewing any source material before localization. Following best
practices for source review and, as appropriate, enlisting the services of your LSP
before translation, will help you dramatically improve the cost and time efficiencies
of the localization steps to come.
Plan to Manage Change
One of the goals of internationalization is to design software in a way that minimizes
the need for changes during localization. But whether your software has been
properly internationalized or not, you must have a clear plan for how to handle the
design-related issues that will inevitably arise during localization. The plan should
include a clear assignment of responsibility for who performs the changes (you or
your LSP) and should indicate how issues will be handled. For example, some
alternatives for design changes needed due to text expansion could include
shortening the words, using smaller fonts, enlarging the menus, etc.
Build Infrastructure
Training
One key to successful, efficient localization is to ensure that key localization team
members are trained on the product’s use and purpose. Training enables localization
team members ― yours and your LSP’s ― to better understand what the product
does, how and why the user will use it, and the environment or context in which it
will be used. Many software companies underestimate the importance of training,
but this crucial step can have a marked impact on translation quality.
A Beginner’s Guide to High-quality Software Localization | Page 7
Typically, training should be provided to translators, reviewers, linguistic testers, the
project manager, and any other significant stakeholders on the LSP and client side. It
can take many forms, depending on the product and training media or materials
available, including activities such as watching demos, running tutorials or reading
user manuals, as well as installing and interacting with the application itself. Your LSP
can consult with you to determine the best training approach and appropriate materials.
Style guide
Just as corporate style guides establish a standard look-and-feel and consistency
between software applications, localization style guides do the same for the localized
software in each target language. Creating and using a style guide as part of the
localization process helps to create a common vision, meet business and usability
requirements for consistency across languages, and address specific language
requirements. The style guide should be used by all translators, reviewers, testers,
and ICRs. If your company does not have a style guide, your LSP can help you create
one based on your requirements, corporate vision, and style.
Terminology assets
There are many requirements for good terminology management during localization,
but preparing a glossary and terminology database (termbase) is the most basic and
critical to project success. A central, approved reference of accurate, key words and
phrases in each target language is not just a recommendation, it is vital to establishing a
proper localization infrastructure.
Glossary creation and translation into the termbase are typically handled by your LSP.
Client reviews and approval at intermediate stages are recommended, final client
approval of the termbase is mandatory.
Build and approve a glossary - First, a monolingual glossary is created in the
source language, typically using automated tools to extract the suspect terms from
the content of your software components (UI, documentation, and OLH). A
content manager or terminologist should review the terms and decide which to
include. Adding definitions for each term helps the translation team understand
them better. Including metadata for each term, such as status, product, creation
date, modification date, etc., enables filtering according to a set of parameters.
Since glossary preparation is typically handled by your LSP, it’s important that
someone in your company review and approve the final glossary to ensure both
accuracy and consistency with standard company and industry usage. When
available, your ICR resources are the best resource for this.
Create and approve the termbase – After approval, the glossary is translated into
target languages and organized into a multilingual termbase. The termbase ensures
that accurate, approved, consistent terminology is used throughout all translations.
DETAILS THAT MIGHT BE STANDARDIZED IN A LOCALIZATION STYLE GUIDE
voice (active, passive formal, informal)
document titles fonts, font size footnote reference numbers placement and styling of figure and table captions
naming conventions, measurements
abbreviations acronyms addresses capitalization phone and fax number formats punctuation time, dates, currency trademarks etc.
A Beginner’s Guide to High-quality Software Localization | Page 8
Again, it is imperative that someone from your company, ICR team, or distributor
base review and sign off on the termbase. It contains the text that your users will
read and experience when they interact with your product. And different
companies, even in the same industry, have different preferences for terminology
use, so it’s crucial that the translations in the termbase be both accurate and
consistent with your company’s specific usage.
The importance of building and approving an accurate glossary and termbase cannot
be overstated. Every terminology change made after these assets are approved must
receive a full impact analysis and may result in additional cost and time to update the
glossary and termbase, and replace translations in all relevant places.
In most projects, some updates to these assets are inevitable. So it is also important
to establish a terminology maintenance strategy that identifies how and by whom
these assets will be updated as the translations and testing progress.
Test plan & test cases
Thorough localization testing is the last step in a localization workflow, but a
comprehensive test plan should be created before testing begins. It gives testers a
very clear understanding of testing goals and details the test cases that will address
the typical product use and known localization issues. Taking the time to develop a
comprehensive test plan early, before testing begins, allows test cases to be created
or modified as needed before testing is scheduled to begin.
Test plans should cover all three main test areas (linguistic, cosmetic, and functional)
as well as all components, functions, and use scenarios of the application. This
includes everywhere text appears, text input, error messages, etc.
TRANSLATION & TESTING
With planning complete, source text readied, and infrastructure in place, the actual
translation can begin. Translation and testing are typically handled by an LSP, but the
basic steps are explained here to give you a better understanding of the process.
Before we discuss translation, it is important to point out that there is a direct
correlation between translator qualifications and translation quality. Clearly,
translators need to be professionals with solid language skills in both the source and
target language. But the highest-quality translations are consistently produced by
translators who are native-speakers of the target language and who live in the
country where this language is spoken. Their translations are the most up-to-date and
relevant to the target locale; and remember, that’s the target locale of your
customer. When translating technical materials ― regardless of the topic or industry
― both translation quality and project efficiency are also dramatically improved when
A TEST PLAN MIGHT INCLUDE:
Installation and set-up on target platforms to ensure the product interacts as expected from the install program and is compatible with target environments.
Entering locale-specific text to validate that the application can handle input in each language.
Testing all combinations of supported OSs, browsers, etc.
A Beginner’s Guide to High-quality Software Localization | Page 9
translators have relevant industry background or experience in the product’s subject
matter. The most efficient, cost-effective, and high-quality results are achieved when
translators have all of these qualifications.
User interface
Translation
Software generally includes at least the UI, documentation, and OLH components.
The UI is typically translated and tested first, so that documentation and OLH files in
each language can refer to the final, localized UI content.
Translation memory creation
During UI translation, an important language asset called a translation memory (TM)
is created. The TM is a repository of pairs of text segments (original and translated)
that are created using computer-aided translation (CAT) tools during translation into
a specific language. The TM is also updated as needed during review and testing.
Much more than a convenience, the TM helps translators work more efficiently and
increases translation consistency for commonly used phrases and terminology,
thereby reducing localization costs and time-to-market.
Throughout the translation of each software component, translations may be
changed or updated, requiring updates to the TM. In this way, the TM serves as the
authority for accurate, updated translations and simplifies the coordination between
various project team members who use it. Keeping the TM up-to-date is important
both for consistency in the current project and will help to save time and money in
future projects that leverage this TM.
Resizing UI elements
You might remember that one important task during project and file preparation was
to think through change management, that is, how, when, and by whom changes will
be handled. One design-change activity often undertaken during UI translation is
resizing UI elements, such as buttons or other graphic assets, due to text expansion in
the target language. Resizing UI can also be handled during testing.
Testing
Once UI translation is complete, running automated tests on the translations can help
to verify consistency with the termbase, with industry terminology, and within the
translation itself. Spell checkers and other customizable tests can be used to validate
the translation. Once these issues are addressed, formal UI testing can begin.
UI testing and debugging are essential steps of software localization during which
issues of many kinds are identified and corrected. UI testing primarily targets
linguistic issues, that is problems with the accuracy or context of the translations,
typos, grammatical errors, issues of cultural-appropriateness, regional settings, etc.
A Beginner’s Guide to High-quality Software Localization | Page 10
Typically during this process, any cosmetic problems (visual issues created by translated
or localized content such as text truncation, line breaking, proper encoding for screen
display, accent character spacing, fonts, etc.) and functional bugs (issues related to
improper functionality of the localized product, such as compatibility with localized
code pages, text input acceptance, menu functionality, string manipulation, etc.)
should also be reported and resolved.
Best practices for testing include having a process and the resources in place to handle
each bug category. Using a good issue tracking and reporting methodology will serve
to fully document the problems and solutions and enable full traceability. It should:
categorize issues by classification, e.g. linguistic, cosmetic or functional, error type
such as typos, grammatical issues, i18n bug, etc., and track information related to
issue management such as severity, responsibility, status (open, closed), etc.
enable screenshots to be attached with descriptions
include steps to reproduce the problem
enable statistics to be compiled to help identify common problem areas and
opportunities for process improvement.
Once all tracked bugs issues are addressed, automatic regression tests can be used to
confirm that known bugs were fixed without creating others. As a final check, if your
company has ICR resources, it is recommended that they review the localized UI
before moving on to translate other components.
The importance of localization testing
One of the biggest challenges with software localization is translating in the proper
context, that is, with the intended application function, audience, and user environment
in mind. The original UI translation is typically performed on a text-string basis in
resource files, not in the context of the graphical UI itself. Even when visual tools such
as Passolo are used, translators still need to see the flow of the application scenarios
to truly understand context and choose the correct translation.
Consequently, out of context errors are common and constitute one of the largest
classes of bugs encountered during testing. It is only when a localized application is
used, from beginning to end, that many context issues and related mistakes are
revealed. This is one reason thorough testing of localized projects is so important.
Many software companies don’t fully understand the reasons for investing in more
testing. From their perspective, they’ve already invested in debugging and testing the
source-language product. But thorough testing of the localized software is the only
way to ensure that you find and resolve problems before your customers do –
whether the issues were created during localization or were present in the source
design or content.
FOR EXAMPLE
Consider the word “record.” What is its meaning? Is it a verb or noun? Is the context related to, for example, setting a record of achievement, recording music, or perhaps a reference to a particular record (entry or file) in a database?
A Beginner’s Guide to High-quality Software Localization | Page 11
While translations can easily be carried out in the target countries, testing is more
complicated and can potentially be quite challenging for a translation-only vendor.
Often, it requires special configurations or environments such as a clean room or
specific platforms, browser configurations, or IT requirements. Testers themselves
require a different set of skills and tools than translators, such as a good eye for detail,
proficiency with bug tracking systems, and experience reading and executing test plans.
It is important to work with LSPs who offer dedicated testing staff. Ideally, they
should work in or have access to a dedicated product testing environment or facility
equipped to emulate the salient details of the product’s use environment, such as, IT
configuration, user, environmental etc.
Documentation
The steps for localizing documentation are similar to those of the UI. Preparation
steps, detailed earlier, ensure that the best tools are used and that documentation
source materials are truly ready for localization. Remember, documentation usually
has the highest word counts of any software component, so taking the time to
remove errors in the source dramatically reduces the time required to find and fix
them later in each language.
A few documentation-specific steps are required before translation begins:
It is important to ensure that the translated UI is referenced correctly in the
documentation. The most effective way to do this is to include translated UI
segments in the termbase or TM accompanied by metadata containing correct
reference information. Changes in the UI that occur after the documentation
translation commences must also be checked and updated in the documentation.
Screenshots needed in the documentation (or OLH files) must be captured in each
language, ideally by a native speaker of the target language or by someone very
familiar with the application. Automatic scripts and commercially available tools
can assist with this task, but they are often cumbersome and difficult to run.
Translate, proof, and edit
With the termbase complete, style guide ready, TM updated, and screenshots
captured, translation of the documentation can begin. It proceeds in a similar manner
to the UI. When complete and reviewed, the translation must be proofread and edited
for accuracy, adherence to language rules, and with the end-user experience in mind.
DTP, DTP QA, and verification
Creating documentation files in different languages inevitably requires some
adjustment to the layout of each version. DTP, typically performed by your LSP, formats
localized documentation as needed for print and/or online use. After DTP, each set of
documentation should be verified to ensure it is complete and that both text and
graphical elements match the source. When the DTP professional is not native
A Beginner’s Guide to High-quality Software Localization | Page 12
speaker of the target language, the final review should be carried out by someone
who is to ensure both language and contextual elements have not been compromised.
This verification step is not another proofreading exercise, it checks only for those
elements that affect the graphical layout. To ensure perfect alignment between the
application and documentation, the documentation can also be validated by using it
to operate the localized software. Here again, as a final check, it is recommended that
you have your ICR resources, when available, review the localized documentation.
Back translation
If 100% accuracy is paramount in your industry, such as it is for medical device
manufacturers, documentation can also be checked through back translation. This
process involves translating the localized documentation back into the source language
(typically English) then comparing it with the original. This is a time consuming,
expensive process, but it can yield exceptionally accurate results.
Online Help (OLH)
Compilation
OLH compilation is largely an automated process; nonetheless, creating localized help
files should be handled by someone experienced with this task. Preparing and testing
OLH templates for known issues such as text expansion, extended character size, etc.,
will reduce unexpected localization issues (and delays) during final compilation. In
addition, not all OLH tools support all languages. If the languages you need are not
supported by your tools or LSP, you need to plan for how these unsupported languages
will be handled before starting to localize.
Testing
Like the UI, localized OLH files need to be thoroughly tested, including linguistic,
cosmetic, and functional elements. It’s highly recommended that testing be performed
by native speakers of the target languages who are more adept at noticing the subtle
discrepancies and details that a non-native speaker might miss. And finally, it is
recommended that your ICR resources perform a final review of the OLH translations.
DEPLOYMENT & DEBRIEF
With localization of the UI, documentation, and OLH files complete, you are ready for
deployment. Localization is a process in which constant improvement enables you
and your LSP to succeed together and helps you complete projects in a more timely
and cost-effective way. So before you consider this project complete, it is highly
recommended that you add one last step to promote ongoing success and
efficiencies in future localization efforts. All the project stakeholders and reviewers
(both internally and from your LSP) should hold a debriefing or postmortem meeting
to discuss both what worked well and where there is room for improvement.
A Beginner’s Guide to High-quality Software Localization | Page 13
WORKING WITH A LOCALIZATION PARTNER
It should be clear by now that localization is a specialized field, requiring expertise
and diverse resources. This is why most software companies work with an LSP
experienced in software localization, freeing them to stay focused on what they do
best: developing and selling software products. LSPs are uniquely qualified to provide
many of the services described in this paper:
helping you plan and schedule the localization project, deadlines, and deployment
helping you prepare each product component (UI, documentation, OLH, etc.)
coordinating translation through a network of professional, in-country translators
and other localization professionals
interfacing efficiently with your software development teams
providing complete DTP and related testing and validation services
providing professional testers and dedicated multilingual testing environments.
Multilingual Testing Facilities
In addition to normal localization testing services, a few LSPs offer dedicated
multilingual testing facilities that bring the resources, tools, testing environment, and
support together under one roof. By fostering open collaboration, knowledge sharing,
and problem solving between testers working in different languages, such facilities
can produce faster, more accurate, and more consistent testing results.
IN SUMMARY
Software localization is a complex process, but armed with a basic understanding of
the localization process, you and your company will be better prepared to work more
efficiently with your LSP. Not all LSPs offer software localization or approach
localization in the same way, so be sure to look for one who specializes in localization,
― not just translation ― and offers the unique combination of services, guidance, and
resources your company needs. Working together and following the basic steps
presented here, you can easily produce localized versions of your software that
reflect the same high quality and user appeal your company has invested years to
achieve in the source-language product.
About the Authors
Shy Avni is the Vice President of North American Operations and David Sommer is the
Director of Strategic Operations at Net-Translators Ltd. Net-Translators is a language
services provider offering high-quality translation, localization, and multilingual
testing services in over 60 languages. For information visit www.net-translators.com.
© 2012 Net-Translators Ltd. All rights reserved.