The New Age of Localization

Once, software developers viewed localization as mainly a technical challenge -- translating help files and adapting the source code to handle double-byte characters, for example. Today, though, savvy developers realize the importance of responding to the local market's culture-based needs and expectations.

by Andrew Wilson

Localization is more than just a buzzword in computer magazines and at software conferences; it is a marketing necessity for business and leisure applications and multimedia products. Even small developers eyeing a foreign market realize that finding a good localization house to adapt their product can spell the difference between a healthy profit and significant loss. Developers, re-publishers, and distributors are now looking at localized products as just that: products that look as though they are intended and developed especially for the local market.

Localization defined

"Localization is the process of modifying a computer software application, or program, in order to support operation by a user whose language and culture are different from those of the user for whom the application was initially developed." This was the definition of localization that I wrote in 1995. While it is still accurate, I now find the definition incomplete.

Today, I would amend my definition to take market potential into consideration: specifically, the fact that the title should actually sell and make money. A suitable addition to the above definition might be, "The goal of a localization is to produce a product that will be at least as successful in terms of sales in its new market as the original product was in the market for which it was initially intended."

Altruism, after all, seldom finds its way into the world of software development. There is usually no advantage for a developer in localizing a consumer CD-ROM title or business application for any market unless it can make money in that market. Developers, therefore, are starting to invest more attention and money in the localization of their products because they realize that products which are localized well simply sell better.

The bottom line is that if localizing software is worth doing at all, it is worth doing correctly. And this means producing a product that looks, behaves, responds, and satisfies or entertains just as well as a product that was designed for the target market from the very beginning. Consumers, and software, are becoming ever-more sophisticated, and the days when a poorly localized product can sell strictly based on novelty appeal, or because it has no significant competition, are long gone.

Progressive localization

The increasingly market-oriented approach to localization places new demands on localizers. Once, the main task facing the localizer of a product was to tackle the many and varied technical issues involved in creating converted assets. Today, though, there are various complex issues involving interface design, music, aesthetics, and basic cultural paradigms.

Creating a convincing sense of interactivity and design for the Japanese market presents a set of problems that cannot be solved by just a good knack for writing code. Designing interactive software for sale in a new market -- not simply converting its parts -- is the focus of progressive localization. More and more, issues of culture and design will determine a program's market profitability (or lack thereof).

Technically, this new approach to localization places even greater demands on engineers, and inevitably increases the ever-present bickering between the programmers and artists. Because producers of localization projects often make numerous requests for significant changes in the "look and feel" of a title, engineers and designers are having to meld their skills and work together more as a team as changes in visible assets, interactivity, and programming merge.

If the producer of a title demands that a certain screen have a different color for the Japanese market, for example, then the screen color must be changed. But this, in turn, might lead to color pallet problems. Which might lead to adjustments in the code. And this might well necessitate significant alterations of other things in other places.

Integration is essential

To achieve this kind of cooperation, of course, the localization team must have access to the source code, and be able to deal with integration as part of the project. This can be difficult to achieve, however, as many developers remain convinced that integrating converted assets from an outside source is easy. For such developers, localization is essentially nothing more than translating a bunch of screen text. This may work -- sometimes.

Increasingly, though, it is necessary for the localization house to insist on being involved in the integration aspect of the project as well. Often, it is absolutely essential to go in and change code in order to allow the conversions to be made correctly. No longer can software sell just by fitting the assets into the engine. Today, successful localization means making sure the assets are completely correct, suitably targeted, and properly adapted to the culture -- then fitting the engine around them. After all, the engine is just a vehicle on which the real meat and interest of the title rides.

But winning the integration part of the project and receiving the source code unleashes another monster: proprietary tools and utilities. These have been potential pitfalls in any localization project, but they become especially so in this new age of market- and culture-driven conversion, where code must be manipulated like never before. Proprietary tool construction often has an air of having been done by a backyard garage mechanic. Though they work fine in the hands of the developer who hacked them together, they can be almost impossible for the localization house to disassemble and rebuild. Further, documentation is often incomplete (or nonexistent). Given this difficulty, not a few engineers have pleaded with designers and graphics artists to please leave certain screens alone and let them go to the target market as they are.

The ideal future

Localization houses must educate developers on how to prepare titles for localization. They must ensure that they receive adequate documentation and clear directory archives, and that experts are on hand to answer questions posed by the localization engineers and programmers.

In the future, developers will regularly consult with localization teams in order to properly prepare the project for hand over. There may even be close involvement of localizers during the initial product development, since potential technical problems or sensitive cultural issues can be dealt with more effectively at the conceptualization stage.

If the developer could place a button anywhere on the screen, for example, and there is a clear preference as far as satisfying potential Japanese users is concerned, then let the localizer tell the developer where to put the button in the first place. This not only saves time and money, but also results in a better product. Perhaps a developer in North America even has an idea and storyboard that would make a better CD-ROM for a Japanese audience than an American one. Having developers in Canada and the US make Korean and Japanese CD-ROMs (and vice versa) is not inconceivable.

The localization process is becoming much more comprehensive and market driven, which is how it should be. This is, after all, how the original version was developed: with the goal of creating software that is interesting and suited to the intended audience (in other words, a product that will sell). If users in target countries are to feel that the software behaves and responds naturally and intuitively -- just as though it has been designed specifically for those users from the beginning -- then adequate time, money, and energy must be spent on localization.

Author Andrew Wilson (phone +1-604-736-8783, extension 117) works with FACT International/DNA Multimedia, a software localization, multimedia development, and media versioning enterprise.