In the talks I had, most people defined internationalization as product translation and localisation. A few thought it belonged to Customer Support; the majority was divided between Marketing and Development. All complained that regardless of how hard they tried to accommodate the “international market”, there was always some new problem preventing revenue from flowing in.

I do not see this situation improving as long as companies believe they can address “international markets” with an “internationalization function” that focuses on “internationalizing the product”. Whether it belongs to Marketing or Development is irrelevant: the concept does not make sense.

Consider a successful US software company. Surely all business functions contribute an essential part, else why would they exist? There is no reason to believe the same functions are not essential in the German market. Yet, when a company moves its business there, very few employees are aware that something is going on. At best, the rest of the company does not contribute at all; more often though, it hampers the undertaking without even knowing.

Going after a new country requires a considerable company effort. You need every business function and the right timing to win the game. Overlook and you will ruin valuable accomplishments, convincing the achievers that their efforts are in vain.

Unfortunately, this is unknown to a great majority. Most projects falter not for one, but for dozens of reasons, all originating in a lack of international awareness. Shipping clerk or general manager, every uninformed person can increase the cost and lead-time.

To highlight this, I have laid out some comments and anecdotes as a company tour. I am sure you will spot familiar situations.

Marketing

No surprise, marketing very promptly embraces the international scene. The thrill of a new market, the “worldwide” added on the business card, not to mention the frequent-flyer miles. Too bad that the travel more often serves a product announcement spree than a research mission.

Hyped up by US success, taking the new territory for granted, many marketers solely concentrate on distribution channels. Never mind the gaping holes between the English language / US functionality product and what the locals expect you to deliver.

To make things worse, “country” must be too modest a term for respectable marketing vocabulary. Why settle for less than the “European”, “Asian” or “Latin American” markets, or better yet, the “Global Marketplace”. Who cares these are not “markets” at all, not in the sense that they can be addressed with a single flavor of products and services.

Without research and clear focus, the “Strong European Presence” in the glossy brochure means: “We skim the continent for customers, sell whatever they will buy and [have somebody else] figure out later how to deliver”. Few customers in many countries, huge delays or products never delivered, more versions and languages than anyone can keep track of - this kind of marketing is simply devastating.

Marketing Communications

As regards glossy brochures, I once saw a communications department decide that every paragraph had to start with a large capital in a different color. Since these changed with translation, every language required a reprint of all the color layers. With their low print quantities, most field offices were handing out $35 brochures.

Development

No doubt international awareness has increased among engineers in recent years. Operating systems commonly handle base requirements for different locales, and most developers have heard about not embedding strings in source code.

However, raised awareness is giving development a false sense of “mission accomplished”. Product managers go to great pains to comply with clichés like “keep all strings separate” or “Unicode takes care of Asia” without further analysis. They spent the money, congratulate the team and close the case. Additional requests following such “favors” are considered inappropriate.

In reality, beside common sense, there is no single rule that can be universally applied. Solutions should correspond to goals, not take up some internationalization fad. Development still has to learn that translation is not a text replacement exercise; that quality requires context. There is a desperate need for better release management and quality control of translated and localised versions. Most development tools are appalling at addressing these issues.

The product’s architecture has an impact, but not including internationalization in the development cycle is by far the biggest trouble generator. The mythical “Simultaneous Worldwide Availability”, a marketing stunt of questionable value, continuous to coax internationalization projects into starting too early. Product instability generates 95% of cost and time overruns. It is worth considering how frozen “frozen code” is supposed to be.

Documentation

The little attention paid to technical writing is baffling. In one case, an application with a large volume of on-line help, writers restructured help from screen level to field level and did a “little editing” while they were at it. Nothing but felicitations from US customers. Too bad there was no record of the changes and no way to recover them automatically. The 15 other language versions faced estimated re-translation costs of $3.5 million. (No, we didn’t spend that much; we ended up “being creative”).

On-line help and documentation easily represent 70% of an application’s translation cost, a pure matter of volume. Writers should have size objectives and acknowledge that quality and quantity are different concepts. If you distribute a product in 15 languages, every word carries an average $4.50 translation tag. It is therefore worth investigating the end-user value of your words. Consider the following anecdote: A distributor in Tokyo told me he had produced Japanese manuals for our newest release. My company had paid an arm and a leg for the initial translation, so I wondered how he could afford the update. Just a reprint of the old version he confessed, only the covers and page headers had been updated. No problem though, the manuals weren’t very useful and customers never read them anyway!

Somebody commented: “Don’t worry, soon those manuals will be gone. We already have CD-ROM and in no time it will all be on the Net”. Not worried? This belief that the problem goes away with the hardcopies announces nothing but trouble. The issue is the content and volume of information, regardless of how it is distributed.

Sales Support

Rave reviews for a sales support team who had developed demo scripts linked to an impressive sample database. Demonstrators could use live data to highlight the benefits of the software to process manufacturers.

Europe heard about this excellent sales tool and lobbied hard to get it translated. Tough luck! The demo scenario described a doughnut factory. Without resources to develop an example Europeans could identify with, the project was abandoned. Every country used precious time from its consultants to kludge its own demo.

Sales

Sales people are among the designated victims of internationalization problems. They know it and rightfully skip no opportunity to voice their frustration. Sometimes though, the eagerness to be heard produces complaints bordering on the frivolous. This badly hurts credibility with corporate structures, who already have a hard time understanding justified claims.

I know a country manager who started a wildfire by stating that the translated brochures he had received were “absolute crap and unfit to be handed out to any prospect in his country”. The marketing communications group had recently been talked into swapping its original design for a more international one and found the news very distressing. The problem? The front page showed one of these commonplace pictures of a few clean-cut employees gawking ecstatically at a terminal. If you took a magnifying glass and peered through the glare on the computer screen, you could see it was in English. The event won the country a subzero attention level for any further requests.

Packaging, Distribution

Regardless of the product architecture, translating software unavoidably generates language versions. In the best case, you will have different versions of text. In the worst case, you will have different versions of code. In addition, localisation can generate different versions of certain components, which can be packaged and distributed in many different ways. From a single worldwide deliverable to individual country deliverables, every option has its pros and cons. Most important is that the matter has been given the necessary thought in advance. Too often the whole distribution strategy is dictated by whatever process has been kludged together at the last minute.

Delivery mechanisms are also subject to translation and localisation. Whether you put things in boxes or ship them electronically, testing what happens on the receiving end is always a good idea. Anyone who has communicated internationally via e-mail knows that strange things happen to message contents in cyberspace. Making the assumption that what works in the US will work elsewhere is a recipe for disaster.

Our European support center once got bombarded with calls after a new release had been delivered. Customers complained that English text was popping up all over the place. The translated versions had been thoroughly tested and the news left us perplexed. What had happened? In the US, a last minute change had been made to the install utilities. The new procedures had been validated and worked fine, for the US version. A bug was preventing language components from being loaded correctly. Nobody had cared to check.

Customer Education

Educators and technical writers share the same problem: too many words can put materials out of reach for smaller markets. It is also not rare for workshops to suffer from doughnut-and-baseball syndrome. Another common mistake are the diagrams, flow charts and slides with too little room for translation.

Education’s biggest problem however is the lack of separation between what they teach and how they teach it. Customers in every country have to learn pretty much the same thing: how to use the software. However, different cultures have different approaches to teaching, and the typical “this is what you’ve learned, this is what you will learn” does not necessarily export well.

In spite of the excellent work done by US education services, it is not rare to see countries redevelop their own materials. Why? “Too much; too repetitive; untranslatable; my customers would go nuts; easier to redo than to sort out”. Some countries will do a good job, others a lousy one. All could make better use of their resources.

Customer support

Doing business in multiple countries can lead to nasty surprises for support. Language and local functionality add two more dimensions. Defining clear support policies and strict procedures is mandatory to avoid utter confusion.

In the US, you deal with plain bugs. Go international and you are dealing with Swedish bugs and Italian bugs, global bugs and local bugs. If the product’s architecture is bad, everything you fix has to be re-translated. If it is worse, everything you fix has to be re-enabled for double-byte languages as well.

Sometimes you discover code you did not know existed and sometimes you wonder if you are talking about the same product. The combinations of version / platform / operating system / database / language / local function can be staggering. Nobody knows how many master copies there are and everybody claims to have the real one.

You deal with people who hardly speak English and others who are upset if you do not call back after saying “I’ll talk to you later”. Twenty-four hours a day, someone somewhere is digging up a bug for you.

The trend to make support services available over the World Wide Web adds tremendous visibility to these issues. Strong international awareness in this activity is a must. Identification mechanisms for language, function, release, version and fix levels are highly recommended. Expect the population of bald support managers to increase sharply in the near future.

General Management

The bread and butter of decision makers is to make decisions. Preferably informed ones. Very often though, information is either lacking, incomplete, or ignored when international deals are negotiated. It all happens as if the US products and services are transferable to any part of the world. There is a vague understanding that some modifications will be required, but nobody bothers to evaluate the extent of the work.

A multi-million dollar deal is something every business acclaims. This company was no exception when a large corporation accepted its offer to deliver manufacturing software to Latin American and Asian subsidiaries. Unfortunately, a commitment made during negotiations turned it into a very painful experience: “Products delivered will meet local requirements”.

In Brazil, one of the first countries implemented, they spent $ 850,000 in translation and localisation. Even before considering Asia, it was obvious that the internationalization bill alone would make the project a huge loss generator. The company had no other choice but to negotiate its way out. The customer stayed, but instead of generating revenue, additional products and services had to be given away for years.

More…

Shipping clerks confusing Austria and Australia, order administrators asking for information only Americans can provide, legal departments imposing US law on the world, controllers who have no clue whether a market is profitable or not, whole books could be filled with horror stories. You get the point: every uninformed player can and frequently does complicate international expansion.

Dedicated internationalization functions do not solve this problem. On the contrary, the message conveyed to the rest of the company is: “Somebody is taking care of it, it’s not your problem”.

If you are playing such a role, you are faced with a daunting task: produce quality deliverables for a variety of dissimilar markets, on time and within budget, while the rest of the company is [unknowingly] inventing every possible way to delay the process and increase the cost.

Your options depend on your status and level of resources: fight tough internal battles to change habits, spend considerable efforts undoing the work of your colleagues, or squeeze your vendors to absorb the time and cost inflation. The rarity of senior-level positions in this activity makes the latter option a very popular one. So much for quality! Whatever the path chosen, it is a lose-lose situation.

Getting out of this vicious circle requires a radical shift from the isolating concept of internationalization to the encompassing idea of international deployment. The first step is to acknowledge that the decision to pursue international markets affects every business function and requires a company-wide effort.

Is there a solid business case to expand into China? Does management at the highest level fully support the idea? Each expertise area now has to review its skills and procedures in light of this broader objective.

Of course that does not mean everybody should learn Chinese. There are plenty of external resources who can expertly assist with research, analysis, planning and execution. However, the responsibility and control must reside in the same organizations who until now were operating at the national level. Broadening the objective of each business function guarantees international awareness and gets rid of national factions opposing international ones.

There is no miracle recipe, but each organization should observe some simple rules:

• Describe a target market in terms of products or services required to achieve revenues.
• Compare your product or service with the one that will fit the market.
• Look at the requirements for each market and find out what they have in common.
• Identify what changes to the base product or service can significantly reduce the production costs for other markets.
• Consider global or local solutions, centralized or decentralized implementations, internal or external resources, vendors or affiliates as partners, up-front investments or deferred payments through royalties, etc....
• Make sure your cost estimates and schedules are included in the overall plans.
• Know whose work depends on yours.
• Communicate.

The bottom line? Internationalize the company, and the product will follow.

---

Yann Meersseman & Associates
23, Nickerson Road
Lexington, MA 02173, USA
Tel: +1 617 862 3642
Fax: +1 617 862 2265