March 2005: If You Try to Sell Me Something, Best Do it in My Language

Posted on March 25, 2005

By Bill Decker for The Denver Business Journal

When companies release software abroad, in what format should they do it? How should they modify their product?

Companies have choices. They can release the software in their own language, making no changes, or they can translate, localize or internationalize their software.

Which method should a firm employ, and when?

To answer this question, an examination of the options is necessary.

• Making no changes — According to some resellers and marketers of software, there are times when producers should leave the software in American English. Many countries have a population of executives who embrace American ideals and business practices. It’s often simpler to use American software.

Sometimes, English interfaces on desktops carry a certain prestige. In other cases, it can be more private than local software, as not everyone in foreign organizations can use English software.

This is the least expensive option. No product enhancement or changes are needed. With no added development costs, a firm can use its resources to build markets internationally rather than rebuild product.

On the negative side: the market potential is limited, and there’s often an arrogance associated with American business practices. Thus a solely American product marketed abroad reinforces the stereotypes many cultures have about Americans: monolingual, sales-oriented, and lacking cultural interest or understanding.

• Translation is a methodology often employed. Software does have a look and feel, but most of software is word-driven. It can be inexpensive to ignore most software interfaces and back-ends, and just manage the words. This option appeals to budget-conscious firms that need to release internationally but have limited resources.

Disadvantages: The firm is spending money but not curing the entire problem. For example, a Web site that welcomes you at its home screen may read: “Welcome Bill Decker” but reads as “Willkommen Bill Decker” in German. The phrase is longer and throws off everything on the page. It could ruin how the site looks and functions.

Also, the site might still look American, which some cultures despise.

• Internationalization of software works by building the source code to be adaptable to any market. This is often confused with localization, which prepares software for a specific market.

Lingoport internationalizes software at the source code level

“When you are building source code, let’s take out all the cultural, language and appearance faux pas at the beginning,” President Adam Asnes said. “Internationalizing source code enables a firm to have one consistent product that adapts to many countries. This gives localizers an easier job adjusting the product to their markets. ”

“Easier job” translates to less expensive for the client. It’s the classic “ounce of prevention equals a pound of cure” analogy. If the code is built right from the start, it’s easier for other software professionals to do their jobs.

Internationalizing costs money. There are initial costs, and a firm still would require translators and localizers.

In an unusual way, internationalization’s weakness is its strength. Since no firm can be an expert in all countries, internationalizing doesn’t compete with localizers or translators. It’s about the back end of the product, and translation/localization deals with the front end.

• Localization is market-specific for software. It changes software to an actual German, Swiss or Japanese product. For example, Eve Bodeux of Bodeux International in Denver localizes Web sites for French-speaking markets. “Language is important, but so is color, texture, euphemisms, usability and features,” she said.

In Chinese-speaking markets, yellow is pornography’s color. In the Arab world, green means good luck. Initials such as KFC or MGD (popular branding schemes in the United States) have sounded too military in Europe. And since French is the one of the top five languages spoken in the world, key cultural distinctions need to be made among France, Quebec or even Mali.

Language isn’t just a one-to-one match of words and phrases. We don’t want our software to read like a poorly written fortune cookie at a Chinese restaurant.

Localization has many advantages:

• It makes the user feel better about the product.
• The software firm is seen as a local company.
• Cultural cues, such as asking for a mother’s maiden name to retrieve passwords, are accounted for (as half the planet doesn’t know their mother’s maiden name). Sensitivities to color, the look and feel of the screen, initials, thought processes and other cultural cues for users are considered.

Disadvantages are time and money. A firm would need to have enough local versions of its product to be local in each market. This is also the case in English, where British English differs from Philippine English which differs from Singaporean English, and so on. Unfortunately, the most common shortcut is to put a foreign national on the task of localization.

“Hans, fix this,” is how Asnes describes that decision. Professionals who specialize in this type of work are needed. Just being from the country in question is not sufficient to localize software.

It’s worth doing it right, though. When new markets open up, which software will be adapted first?