Meeting the Challenges of Software Localization

American software publishers who ignore the Japanese market do so at their own peril. In all likelihood, their competitors are in Japan already, and using the profits they make there to compete more effectively at home.

Software localization, though -- especially for the demanding Japanese market -- is not an easy task. If your company is considering localizing its products for Japan, heed the advice of the experts quoted in this article.

by Coleman Yeaw

Companies looking to access Japan's software market face the intimidating hurdle of localizing their products effectively. Localization presents a wide array of challenges, from the strategic, company-wide level all the way down to the individual level. While American companies are increasing their understanding of the technical and cultural issues involved in localization, they still often underestimate the effort that is required to manage a localization project. This is dangerous, because project management is often the largest factor in determining whether a localization effort will be successful.

The need to properly localize for Japan has become an accepted fact of business -- the Japanese customer insists on it. Non-localized products will sell in Japan only if they are unique or have no major language component (such as a screen saver, for example).

Joelle Feldman, localization manager at Banyan Systems, observes that, "While we only localize portions of our documentation for European markets, the Japanese demand that the entire set be translated." This need is echoed by Gail Wertheimer of Cheyenne Software. "We can get by selling English products longer in other markets than we can in Japan." Both Cheyenne and Banyan have offices in Japan that take active roles in the localization process.

A company-wide commitment

Before localization is even attempted, it is important to secure the entire company's commitment to the effort. It is not unusual for a mature software company to have over 50% of its revenue generated in international markets; even small software companies often derive a large percentage of their revenue internationally.

Japan is the second-largest market, after the US, for many software firms. Wendy Walter, localization manager at System Software Associates (SSA), declares that "60% of our revenue is international, so there is no question as to whether we localize or not." SSA has invested heavily in localization, creating a department of over 50 people dedicated to it.

JD Edwards, a maker of financial software based in Denver, Colorado, has made a similar commitment. According to Susan Daly, the company's localization manager, "If you really want to have the product be seamless on the Japanese user's end, it takes everyone's effort on the developer's end working together to make it happen."

By devoting significant budget to staff and tools for localization, JD Edwards has significantly increased its flexibility and speed for creating international materials. They have implemented a department-wide translation memory tool, and hooked it in with the company-wide system for creating documentation. "Out of a central database of translated material, I can create user guides, in-house documentation, and online material for presentation on multiple platforms," says Daly.

Jim Downton, manager of information management and translations, technical education, and documentation for Motorola's Cellular Infrastructure Group, identifies internal commitment as the first issue he faces in a localization project. "The management [staff] for the product both in the US and in Japan first need to be educated about what we are doing. Once they become involved in helping with terminology and validating translations, they start to understand better what it is we do, and then things can run smoothly." Downton's group translates around 50,000 pages per year, divided among several languages, and manages a network of over 20 localization vendors.

Keep development involved

The most important department in the organization that must be involved closely with the localization process is development. "Software is alive almost until it reaches manufacturing," cautions Banyan's Feldman. If development makes changes at the last minute, that can have a major impact on the localization effort.

From a localization standpoint, it is always easier to work on products and documentation that will not change. But localization groups rarely have this luxury. As Mary Lou Kirkpatrick of INSO Corporation explains, "Even with a product which is on the shelf, all of a sudden there's a software change -- they have to fix bugs -- and that throws off the localization effort." Good communication with the development group to know when such issues might arise is critical.

Ideally, products should be developed from the start with localization in mind -- globalization, in other words. Programmers and designers should create internationalized products, ready to be localized for particular markets. Says SSA's Walter, "Our localization people work very closely with development. The developers are responsible for making sure that the software works internationally. They know if I raise a problem, it's serious --and fixing it gets top priority." Having this level of commitment to international markets in the organization makes the localization process go much more smoothly and can avert problems before they seriously impact deadlines or shipping dates.

People make the difference

Another vital problem-reduction strategy for the beginning of a project is choosing the right people to do the work. A major choice that companies will face is whether to hire people and do the localization themselves, or to outsource to vendors. There is no clear consensus as to which is the better approach, and both can be successful.

In choosing their approach, companies need to consider the volume of their work and the turnaround requirements. "Our biggest challenge," says Cheyenne's Wertheimer, "is finding good resources -- not just vendors, but internally as well. The vendor is critical to the success of the project." Choosing the right people is especially important if a company plans to hire its own localization staff. "A translator is a specialist, like a programmer, tech writer, or marketing person," says JD Edwards' Daly.

Choosing the wrong people for the project can be catastrophic. Misguided executives may think that anyone with a working knowledge of the language is good enough, when in fact the localization staff should be every bit as qualified as the original technical writers and programmers. Motorola's Downton offers this advice regarding vendors: "Look at the core staff of the company to see if they have enough permanent staff to handle the project. And if it's going to be revised, I would want to make sure they have the archiving procedures in place to do that."

Downton has some strong opinions about localization. "I don't like Asian languages and European ones to be done in the same place. The more people you have at the vendor site who understand the target language -- even assistants or people not directly involved -- the less likelihood that something small but important will slip through the cracks."

It is important to realize that translation, even of technical material like software documentation, is primarily a language-based activity. "If the translators don't have the technical knowledge," says Daly, "we can teach them that. But the language skills that make a good translator are much tougher to teach."

Banyan gives its vendors access to all its own tools for compilation and testing, although much of the validation is still handled by Banyan itself. By keeping the vendors in touch with all developments and changes in the tools and software, Banyan avoids lots of headaches, Feldman notes. "Our product is very complicated and technical, so our vendors have it up and running on their sites. In addition, because we have a long relationship with them, we can trust them to understand our software. They are more partners than outside organizations."

The more this type of trust builds, the easier it is to get past particular problems that might arise in the course of a project. As in any relationship, there is a learning curve, but once trust has been established, problems become much more manageable.

Open communication

Maintaining adequate lines of communication between the publisher and the localizers for dealing with the questions that will inevitably come up is critical. Any good localization group, whether inside the company or at an outside vendor, will ask questions as they work through the material. "Vendors should absolutely ask as many questions up front as possible, so that once things get started they can run," says Cheyenne's Wertheimer. Translators will read software documentation more carefully than 99% of the end users who look at it, and they are likely to find mistakes or vague explanations that often slip through the internal writing process.

Ideally, the questions that translators ask should be reflected in later documentation, resulting in improvement of the original English as well. One tactic is to educate the translators ahead of time, sending them through formal training on the product. Notes Banyan's Feldman, "We invest quite heavily in our vendor in terms of training and keeping them up to date on our technology. We view that as a long-term investment."

To successfully complete a localization project -- as in any task involving more than one person -- communication is the key. Depending on the scale of the project, either daily or weekly liaison may be necessary. On large-scale projects, it helps to have an established reporting system. INSO, for example, logs all contacts with vendors into a Lotus Notes database, so that information to and from the vendor is disseminated to everyone in the organization who needs to know. They also require weekly project updates from their vendors.

The partnership between vendor and publisher should be a two way street. While the vendor is provided with greater access to information from the publisher, the publisher should also be able to find out just where a project stands at any time. Keeping that information readily available requires a great deal of talent and organization -- key things to look for in localization resources.

Localizing for Japan

Often, the Japanese office will want to take a more active role in localization than Europeans do. At Cheyenne, "the Japanese insisted on owning the localization process. Eventually, we set up a system where two people get their budget from the Japan office [but] they still work here in New York." And at Banyan, "dealing with Japan poses special localization challenges. Our office there very actively participates in the localization process." The reason, in part, is that the Japanese have very demanding standards for quality, and the market does not tolerate mistakes.

Companies that have only localized for European markets will face new technical issues when localizing for Japan. "Any time you move into double-byte languages," cautions JD Edwards' Daly, "you have to address a whole new set of issues. We have had to be very careful, even with our internal tools, to keep the capabilities from forking and ending up with two different tools."

It also takes longer to implement the translation memory tools for Japanese because they are not as well supported by the marketplace, and there are some unique hardware considerations. These issues are becoming better understood as more software companies move away from the model of letting a distributor or partner handle all localization for Japan. American companies are realizing Japan's importance, taking more responsibility and making the investment to localize themselves.

Localization projects are under pressure from several directions. The pressure to reduce the time difference between American and Japanese releases, known as the "delta," pushes squarely against the increasing complexity of products and the increasing volume of the documentation. Localization is caught in the middle. The only way to deal with these conflicting business realities is by managing the flow of projects and information better.

Tools for project management are starting to proliferate, and some of these tools may have features that will make them especially well suited for localization projects. In the end, though, localization remains a task that depends largely on the talent and creativity of the people who do it.

Coleman Yeaw is Sr. Vice President of Japanese Language Services (http://www.japanese.com), a translation and localization firm located in Cambridge, Massachusetts. A veteran of numerous localization projects, Mr. Yeaw lived in Japan from 1987 to 1991 and speaks Japanese fluently. He can be reached via e-mail at coleman@japanese.com.