Guide to Localization 2009.pdf

April/May 2009

LOCALIZATION

® Localization: The Global

Pyramid Capstone

® Local Websites

for Global Brands

® The Emerging Role

of Machine Translation

® Building Quality into

GETTING STARTED : Guide

G E T T I N G S T A R T E D

the Localization Process

Guide : G E T T I N G S T A R T E D

GETTING STARTED

People often ask what localization is. The short

explanation would be something along the lines

of taking any product or service created in one

locale and making it relevant to the local culture in another . Longer explanations run

the length of entire articles, which is what you can expect in this Localization Getting

Started Guide.

Localization is typically part of a larger process, as Richard Sikes explains, and to

match his hefty globalization overview he has a paragraph-long localization deﬁ nition

of his own embedded in the article. Ben Sargent adds marketing savvy to the global

goal with a plethora of tips and examples on localizing global brands in websites. Alex

Yanishevsky gives a summation of machine translation’s emerging role in localization,

and Eva Müller ﬁ nishes things off with a discussion on quality and pragmatics — that

is, pragmatically, it makes sense to localize, especially if you’re doing so with enough

pizzazz to catch the eye of the local market.

Editor-in-Chief, Publisher Donna Parrish

Managing Editor Laurel Wagers

Assistant Editor Katie Botkin

Translation Department Editor Jim Healey

News Kendra Gray

Illustrator Doug Jones

Production Sandy Compton

Editorial Board

Jeff Allen, Julieta Coirini,

Bill Hall, Aki Ito, Nancy A. Locke,

Ultan Ó Broin, Angelika Zerfaß

Advertising Director Jennifer Del Carlo

Advertising Kevin Watson, Bonnie Merrell

Webmaster Aric Spence

Technical Analyst Curtis Booker

Data Administrator Cecilia Spence

Assistant Shannon Abromeit

Subscriptions Terri Jadick

Special Projects Bernie Nova

Advertising advertising@multilingual.com

www.multilingual.com/advertising

208-263-8178

Subscriptions, customer service, back issues

subscriptions@multilingual.com

www.multilingual.com/subscribe

Submissions editor@multilingual.com

Editorial guidelines are available at

www.multilingual.com/editorialWriter

Reprints reprints@multilingual.com

This guide is published as a supplement to

MultiLingual , the magazine about language

technology, localization, web globalization and

international software development. It may be

downloaded at www.multilingual.com/gsg

The Editors

Localization: The Global Pyramid Capstone

page 3

Richard Sikes

Richard Sikes has been immersed in localization since 1989.

He is a freelance localization management trainer and consultant.

Local Websites for Global Brands

page 8

Ben Sargent

Ben Sargent is a senior analyst and content globalization strategist with

Boston-area research and consulting ﬁ rm Common Sense Advisory, Inc.

The Emerging Role of Machine Translation

page 12

Alex Yanishevsky

Alex Yanishevsky is senior solutions architect at PROMT Americas.

Building Quality into the Localization Process

page 14

Eva Müller

Eva Müller is a senior information developer and

operational planner at Rockwell Automation.

The No. 1

independent technology for the linguistic supply chain.

www.across.net

Across Systems, Inc.

Phone +1 877 922 7677

americas@across.net

Across Systems GmbH

Phone +49 7248 925 425

international@across.net

page 2

The Guide From MultiLingual

LOCALIZATION

Getting Started:

Localization

GETTING S T A R T E D

STARTED : Guide

Localization: The Global

Pyramid Capstone

R ICHARD S IKES

recruiter to interview for a job with a

major Canadian manufacturer of air-

plane components. It seems that the hiring

manager had spotted the keyword global-

ization in my online résumé, and because

the company was embarking on a global-

ization initiative, he thought I might be

an ideal candidate for the position. I went

to the interview. In short order, we deter-

mined that in their corporate universe, glo-

balization meant imprinting the stamp of

how things were done in the mother ship

organization on all associated organiza-

tions around the world. I quickly explained

that in my international software develop-

ment and marketing universe, globaliza-

tion meant reaching out to understand

what users in cultures other than my own

desired and then to evangelize incorpo-

rating those attributes in those markets.

Needless to say, it was a short interview!

The attitude displayed by the hiring com-

pany may be useful in some situations, but

to me, it embodied much of what has given

globalization a bad name. It also pointed to

another issue that I have observed closer

to home: even in our relatively knowledge-

able and harmonious world of software

localization, substantial discrepancies exist

in what industry participants understand

about how globalization differs from inter-

nationalization, and how both of these two

differ from localization.

they responded with a list of 1,600 issues!

I found this to be somewhat overwhelm-

ing, so I tried to focus in on prioritization.

Due to some factors outside the scope of

this article, the prioritization effort took

some time, so the next actual event in the

localize the five manuals may have been

appropriate for some target locales, it

most certainly was not for Japan. In fact,

the result was a double whammy. Not only

was dissatisfaction created, but a sub-

stantial sum of money was wasted trans-

lating unwanted manuals. A s it turned out,

the missing manual was the one and only

issue of importance; the remaining 1,599

identified deficiencies could have been

lived with, for one release anyway, if only

the manual had been translated.

This anecdote illustrates my point that

globalization must, to some extent at

least, involve a degree of investigation

into what foreign markets require and,

conversely, that international product

development without globalization at its

foundation is a recipe for failure. For this

reason, globalization builds the bottom-

most and widest tier on the pyramid. But

globalization does not only consist of off-

shore market research. Rather, it should

be considered more closely synonymous

with overall corporate investment strat-

egy. By this, I mean investment strategy in

the widest sense of the concept — not only

investment in the financial sense, but the

investment of effort that employees make

in everything they do. In other words, glo-

balization should be considered a mindset

as much as a task set.

I once was asked to prepare a consult-

ing proposal to evaluate localization pro-

cesses for a well-known and successful

company in the telecom space. My pro-

posal was not accepted at the time, how-

ever, because the company decided to

purchase a content management system

for their English content prior to explor-

ing their localization practices. It never

occurred to management that handling

localized content and adapting to localiza-

tion workflows might be critical, and thus

globalization was not in the forefront of

the decision-makers’ minds as the com-

pany considered this investment.

Based on the notion that globalization is

a mindset, international market research is

only one piece in a much larger mosaic and

should not be carried out in isolation or

world of software

localization ,

substantial

discrepancies exist

inwhatindustry

participants

understand about

how globalization

differs from

internationalization .

saga turned out to be a visit from two rep-

resentatives from the Japanese office to

our headquarters.

After we had gotten acquainted, they

asked, “The document set for this product

consists of 24 manuals, correct?” “Yes,”

I replied. “And you have localized five of

the 24 books?” “Yes,” I again replied, “in

order to keep costs contained, our product

management group decided that we would

localize only those five.” “And the Refer-

ence Manual is not included in the five?”

they asked. “Correct!” I confirmed. “Why

not?” they asked. “The Reference Manual

is the only one that we want in Japanese!”

It was immediately apparent to me

that our product management team had

made a decision that was based on insuf-

ficient due diligence. While the decision to

Globalization

My definition of globalization stems

from an experience I had while serving

as director of globalization for a large

software company. When I took the job,

one of the first things I was told was that

Japan was a problem. Exactly why it was

a problem was not clear to the hiring

manager, since the company had recently

completed a localization of the flagship

product at great expense, and shouldn’t

the office be pleased?

So, as one of my first tasks in my new

job, I set about contacting the Japanese

office to find out what was wrong with

the product. After a relatively short delay,

April/May 2009 • www.multilingual.com/gsg

page 3

LOCALIZATION

G E T T I N G

S everal years ago, I was called by a

E ven in our . . .

Guide : G E T T I N G S T A R T E D

GETTING STARTED

“thrown over the wall” to another depart-

ment, as is sometimes done with program

code. Quite to the contrary, regional mar-

ket considerations should be treated as

an integral part of marketing plans cre-

ated by a centralized marketing organiza-

tion. Target locales should be grouped in

tiers based on quantitative analysis, and

a business case mentality must prevail,

especially in the case of emerging mar-

kets. This will promote product planning

with diverse markets in mind.

Creating a business case for product

investment requires additional layers

of support in the finance or accounting

departments. It has always amazed me to

learn how many companies do not track

their revenues with sufficient international

granularity to know whether the criteria

set out in business case justifications are

actually met. In my experience, it is sadly

typical that companies do not know how

much revenue can be attributed to local-

ized products. At best, they may know how

much revenue comes from products sold

in certain regions, but there is no distinc-

tion between English and localized prod-

ucts sold. This simply is not tracked, nor

is there any infrastructure for tracking

or mining such vital data. Most com-

panies either “fly blind” based on

imperfect, unverified assumptions,

or they employ the “localize for

whoever screams the loudest”

method of decision-making.

This is partly an offshoot of

the practice of sales person-

nel being compensated by revenue rather

than profitability, and it may be consid-

ered an unnecessary burden during peri-

ods of robust business growth. However,

in leaner times such as we have as of this

writing, it is a shortsighted policy.

An additional attribute of the globaliza-

tion mindset is the conceptual treatment

of English product offerings as a subset of

a generic, locale-neutral product. This is a

tough mental leap for most North Ameri-

cans to make, although there is hope on

the horizon. The growing influence of the

Hispanic population, for example, has

caused numerous US-based businesses

to consider Spanish as a language with

an importance and personality of its own

approaching that of English. This, by defi-

nition, requires a whole new level of aware-

ness on the part of strategic planners.

In the software world, target markets

are generally farther afield, and compa-

nies are represented by offices located

abroad. These offices are valuable sources

of information, but all too often, the infor-

mation flow is in one direction only: from

headquarters to the field. This is counter-

productive. In a world where information

is power, the globalization-oriented com-

pany liaisons extensively with resources

all over the world, leveraging the informa-

tion gleaned from that contact.

The choice of representation in foreign

markets is also very much a part of global-

ization. There are many options; channel

strategy is a long-term decision with many

implications. One company that I know of

has blithely opened and closed offices in

Japan multiple times based on short-term

also be applied to such tasks as allowing

sufficient white space in source documen-

tation for text expansion or architecting a

website so that localized content can be

easily added.

When performed proactively, interna-

tionalization is conceptually very similar

to a real option. A real option is the right

or the ability, but not the obligation, to do

something at some point in the future. One

purchases this future advantage through

a current investment, and hence it has a

calculable dollar value. Think of an entre-

preneur who purchases a plot of land

alongside a country road where, some-

day, residential development will occur.

She builds a small service station and car

dealership. She doesn’t invest too much

money in the current facility because

she doesn’t know exactly when

the development will occur and, of

course, there is always some risk

that it might not. But what she does

do is to buy an option to purchase a parcel

of land next door at a predetermined price

at some future date. This guarantees that

she can expand the facility if she wishes,

but does not obligate her to purchase

the land if the development does not

materialize.

Within the context of product

development, proactive inter-

nationalization simply pro-

vides the option for a company

to cost-effectively localize at some

future time. Future localization is

cost-effective because product com-

ponents do not have to go through a dis-

ruptive and time-consuming retrofitting

process to support a decision to launch

sales in a new market. Turnaround time

from decision to delivery is therefore sub-

stantially shorter, and revenue gains occur

sooner.

Internationalization of software consists

of three basic task types, each supported

by numerous subtasks. The first of these is

the removal of cultural assumptions from

software design. The second is architec-

tural separation of the presentation layer

from the business logic layer. The third

is implementation of support for global

norms such as character sets or account-

ing procedures.

Removal of cultural assumptions is

somewhat easier said than done. Such

assumptions are not made by software

developers out of malice but, rather,

through understandable ignorance, albeit

also sometimes out of time pressure.

results, apparently unaware that each vac-

illation in policy further undermines their

credibility with local partners. While com-

panies presumably never enter markets

with the intention of failing, they frequently

do fail to proactively consider an exit strat-

egy in their up-front planning. Even this

pessimistic, risk-oriented activity belongs

to due diligence activities of globalization.

Internationalization

Internationalization, the act of making a

company’s products localizable, is some-

times called localization engineering. This

latter term is unsatisfactory for several

reasons, most prominently because it

implies that the task set is different than

core development and, by extension,

done by different people and, perhaps,

at a different time. But it is also not broad

enough. Internationalization need not only

refer exclusively to coding practices as

localization engineering implies; it might

page 4

The Guide From MultiLingual

LOCALIZATION

GETTING S T A R T E D

STARTED : Guide

Many North Americans are unfamiliar with

norms in other countries. For example,

developers trained at US institutions sim-

ply may not realize that decimal separation

is actually indicated by commas in much of

the world. Unfortunately, few university

computer science departments teach the

principles of internationalization, so one

can hardly fault the graduates of those

institutions. Another highly prevalent cat-

egory of cultural assumptions are those

surrounding generic linguistic issues. Lack

of understanding of text expansion is one

of these, as is how unresolvable gram-

matical paradoxes can be created by string

concatenation.

There is a plethora of issues here,

but for simplicity’s sake, let it be said

that the goal of internationaliza-

tion is to create a locale-neutral

product. This is done by creat-

ing virtual “layers” of pro-

gram code that are discrete

from one another. These

layers have different functions.

The “presentation” layer is

that which the user sees and

interacts with. The “business

logic” layer is the area of code

that is the functional “guts” of

the program. In simple words,

that’s where the program does

whatever it does. There may

also be a “database” layer,

where data is stored and from

where it is retrieved. In most

programs, data is transferred

back and forth between these layers, so it

is not only the program code that defines

operations within these layers that is impor-

tant, but also the transport mechanisms

between the layers that require scrutiny for

internationalization support.

One problem occurs when these lay-

ers are not cleanly separated from one

another. Symptomatic of this kind of prob-

lem is when localization of the presenta-

tion layer causes malfunction within the

business logic layer. An example I once

encountered was the usage of the terms

high , medium and low from the presen-

tation layer, which contrasted with the

volume settings of a modem that were

reported to the business logic layer using

those same English words. One can easily

imagine what happened when the presen-

tation layer was translated: the compari-

son test failed every time, resulting in the

inability of the user to accurately deter-

mine or set the modem volume.

An example of problems resulting from

poorly internationalized transport mecha-

nisms is another issue I recently encoun-

tered. The product consisted of a Windows

client that drew its strings from a UNIX

back-end server and also used a similar

UNIX server to store data. The developers

failed to realize that there are character

encoding differences between the two

operating systems. The code that trans-

ferred data back and forth between these

two platforms therefore failed to properly

convert strings pulled from the UNIX server

to populate the user interface, resulting in

a nonsensical user interface (UI). It also

failed to properly store and return data

entered by the user. Since some of the data

but it cannot cover all cases. Functional

requirements need to be derived from the

globalization strategy, as previously des-

cribed, and then tested against during the

core code development process.

One such example from my past involved

128-bit data encryption algorithms that

were built into a product my employer

produced at the time. Among other mar-

kets, the product was intended for sale

in France. At that time, 128-bit encryp-

tion was illegal in France, so internation-

alization in this case included building

in the capability to suppress this feature

for French or English product builds ship-

ping to that region. While this example is

somewhat exotic, internationalization of

core products may come up in many other

more mundane contexts, such as currency

format support, date and time formatting,

business logic rules such as application of

value-added tax and a plethora of other

things that have nothing to do with local-

ization in the linguistic sense.

It is highly disruptive, time consuming and

therefore expensive to go back and retro-

fit program code to be internationalized

after a product is released. This gen-

erally involves branching the code.

One branch will contain devel-

opments of new features and

bug fixes to currently avail-

able versions, and may

not be internationalized.

The other branch contains

changes to enable internation-

alization support.

Then, at some point, the code must be

merged and regression tested. Many com-

panies follow this pattern, as pressure

to release quickly to home-turf markets

supersedes longer-range vision. But this

is really akin to offloading development

debt to the future. A far better and, in the

long run, less expensive and more flex-

ible practice is to accept a small amount

of ongoing overhead to internationalize

from day one in the development cycle.

This ensures two vital factors: flexibility

to localize quickly at any time, and gradual

lessening of the internationalization learn-

ing curve as developers incorporate best

practices into their daily work.

So far, we have discussed international-

ization primarily in the context of software

coding, but a quick detour to other areas of

product development is worthwhile. One

that comes to mind immediately is allowing

sufficient whitespace in documentation to

absorb language growth without causing

entered was the user’s password, logging

on to the application failed when the user

name or password contained characters

corrupted by the transport process.

Fortunately, many of these kinds of func-

tional problems can be easily exposed

by pseudo-localization. This technique

involves using software tools to simulate

translation of presentation layer pro-

gram code that is then sent for testing.

This brings up the subject of when, in the

development process, testing for interna-

tional support should be carried out and

how extensive it should be. Many compa-

nies push this into the functional area of

localization, but it does not belong there.

Even companies that do not localize may

wish to sell their products in non-English-

speaking locales. Therefore, the products

should fully support the functional require-

ments of those locales.

Pseudo-localization is one strategy to

proactively test for international support,

April/May 2009 • www.multilingual.com/gsg

page 5

LOCALIZATION

G E T T I N G

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: