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.