Software Localization: The Art of Turning Japanese

If you live in Japan and use Japanese software, you've undoubtedly noticed that almost all the major programs were developed by overseas companies. But have you ever stopped to think about how foreign software becomes Japanese? Japan is a major market for localized foreign software, thanks to the internationalization efforts of foreign software developers and the anonymous work of software localizers.

by Tina Lieu

Software localization is the process of transforming programs (and their accompanying printed documentation) from one language version to another. The process has been around in Japan since the 1980s, but the term "localization" has been used only since the early 1990s when this work began to be recognized as an industry related to, but different from and more involved than, translation.

Today, localization is an essential and integral part of the software industry. More and more developers are deriving significant portions of their total revenue from international sales. For example, sales of international versions of software (that is, sales outside the US) account for about 50% of sales at Claris, while at Microsoft that percentage rises to over 60%.

However, globalization (the process of creating business opportunities and markets in foreign countries) does not come cheaply, especially for software. A 1995 study (Globalisation: Creating New Markets with Translation Technology) by London-based IT consulting firm Ovum Ltd. estimates that globalization costs software developers (called "publishers" in the localization industry) about 2% to 5% of company revenues. But for a top-selling product, the rewards are well worth the cost.

The importance of being Japanese
In the '80s, most software localization into Japanese was done in a piecemeal fashion. A software publisher would typically ask its local Japanese distributor to localize its products, sometimes with the incentive of royalties, and the distributor would use a mix of internal resources and outsourcing to translation or software engineering firms to perform the work.

Within the past five years, however, several dedicated localization companies have appeared in Japan, having grown from either translation or software development roots. This crop of professional localization service companies (called "vendors" in the industry) has experienced good growth, and they are now used by the major US software publishers. Yet a significant amount of localization continues to be done internally by trading companies, distributors, translation houses, and software engineering firms.

Large US- or Europe-based multi-language localization vendors (MLVs) have at last acknowledged the importance of a local Japanese presence. Several MLVs have moved into Japan this year (1997), either by acquiring a local localization firm or by setting up a branch office. Three examples are the merger of Shin-Yokohama-based Pacifitech with Bowne Global Solutions in March, the opening of a Tokyo production office by Dublin-based International Translation & Publishing in April, and the scheduled (before year-end) merger of Japanese Language Services (Osaka, Cambridge, MA, and San Jose, CA) with Lionbridge.

The importance of the Japanese software market is undeniable. Major software publishers, such as Microsoft, Netscape, and Claris, all rank Japan as possibly the largest and most important national market outside the US. In fact, Microsoft reportedly earns more revenue from its localized Japanese products than any other language except English. (Microsoft even sold more copies of its Visual C++ in Japan than in the US.) The Japanese subsidiary of Claris, meanwhile, has seen its sales grow twenty-fold since it was established five years ago.

Figures for the percentage of localized software used in Japan are hard to come by, but a good estimate of the percentage can be gained by looking at Japan's software imports and exports. According to a survey by the Japan Electronics Industry Development Association (JEIDA), in 1995 Japan imported a staggering \392.6 billion in software, of which 92% came from North and South America. Japan's software exports for the same year amounted to only about 1% of its imports (\3.9 billion). These statistics clearly show the competitive weakness of native Japanese software versus localized foreign-language (mainly English) versions.

To outsource, or not to outsource?
The "proper" way to localize a product is a matter of contention. The mix of in-house localization (that done by the publisher) and outsourced work (to localization vendors) varies depending on both the nature of the product and the working philosophies of the publisher.

Some publishers feel that only they can really understand their product, or that doing the work in-house is more efficient than outsourcing. Others prefer not to carry the burden of maintaining extra staff and making the investment required for localization work, preferring to outsource the task.

The job of localizing a product is usually divided into three areas, each with its own characteristics and demands. There is translation of documentation (printed manuals and online help), translation and adaptation of the user interface (UI; for example, the menus and dialog boxes), and software engineering (which for Japanese, and other Asian languages, often includes double-byte enablement of a single-byte application so that it can accept input/output of kanji). Then, finally, there is the required testing (debugging) of the software to make sure that the various parts work together and function properly in all the to-be-supported environments.

Of these three areas, the translation of documentation is almost always outsourced, even by companies who prefer to keep the rest of the localization process in-house. Localization of the UI and engineering work is where companies differ in their approach. Claris Japan and Netscape are of the "let's do it in-house" school, while Microsoft is more open to outsourcing.

Home is where the source code is.
US-based Claris Corporation's first Japanese software release was MacWrite in 1989, four years before the establishment of Claris Japan. Today, Claris makes software for both Mac and Windows platforms, and its applications are localized in as many as 16 languages.

Nearly all Claris software products are also developed for Japan's market. In fact, some Japanese-developed extras end up in all versions, and Claris Impact version 3.0 (a business diagramming application) was developed especially for the Japanese market and is not available in the US.

According to marketing manager Tomoharu Kito, "Claris products are not just localizations; all of them are 'culturized' from the developmental stage. Unless the software is designed to meet user needs and is easy-to-use, [the user] will not be able to take advantage of any great functions [the product has]." Regarding the actual localization process, Kito continues, "Depending on the product, historically we haven't done development just in-house, but have sometimes outsourced certain portions. But today, as a principle, we do the development in-house. At our US Claris Corporation headquarters, we've set up a development team composed mostly of Japanese staff to develop our Japanese versions. We have development teams for each language at the same location as the US headquarters development team. This is more efficient for communication between the [various] development teams."

Netscape Communications is still a relatively young company, established just three years ago. For Netscape, there was never a question about doing international versions right from Netscape Navigator version 1.0. Taisuke Shinkawa, manager of product marketing at Netscape Communications Japan, elaborates. "We knew we needed international versions [of our software] and started working on them from the very beginning." Netscape, too, incorporates components developed for one language into all its versions. According to Shinkawa, "Rather than add functions to one version, if one version needs it, we add it to all the versions. Otherwise, from a development point of view, it's too expensive."

Like Claris, Netscape sees localization not as a separate process, but as part of the overall development process. Shinkawa explains that, "We don't really think about making international versions as being 'localization.' When we do development, we develop components that can be easily taken out and brought back in. So a resource file might be sent out for translation, and then when we get it back, it's incorporated into the application [under development]. If we do outsource, it's just the translation."

Regarding where he sees the third-party localization industry going, Shinkawa says, "I don't think it'll completely disappear, but I don't think it will grow to be that big. Because, just think - company A will ask localizer B to do version 1.0, but starting with version 2.0, or soon after, A may ask B to do less, or A may decide to do the whole thing by itself. Company A will put in the needed structure from the beginning. [Outsourcing] doesn't make sense from a cost point of view. In order to make competitive software, you need to be big; and if a software company is that big, it will just do its own localization."

Localization is here to stay
Although the localizers we spoke with disagreed with Shinkawa's dim view of the future of outsourced localization, they did agree with his declaration that the engineering work should be done in-house. Even so, localizers see a great and increasing demand for their services.

Michael Shannon, sales manager, Asia, of International Translation & Publishing Japan (ITP Japan), hypothesizes that Shinkawa's definition of localization might be too narrow, focusing on the software rather than also encompassing the documentation and online help. "The main part of localization is the translation in all cases: the translation and adaptation of online help and documentation, and preserving consistency across all three." Regarding the decision to do localization in-house or outsource it, Shannon remarks, "It all depends on the size of the projects versus the number of internal resources available. As the software industry grows, most companies have no alternative but to outsource, especially as content-specific localization becomes more important."

Bob Myers, vice president, Asia, of Bowne Global Solutions, counters Netscape's Shinkawa's forecast that the localization industry will remain small by saying, "[That is] basically wrong for a couple of different reasons. You do need to divide the work into docs [documents], UI, and engineering. Each of these three components has different characteristics. As a company goes through its product cycle, engineering issues will come to be handled by the central engineering group - and this is the correct way. The trend to outsource docs in a turnkey way is now thoroughly well established. The market is, by definition, growing [in terms of] the number of languages and the amount of text. This is on a strong growth curve."

Myers recommends looking at software development and localization in terms of product and technology life cycles, which he thinks will continue to drive demand for localization services for both documentation and engineering. "Each cycle has a connection to the amount of localization required. Sometimes it's said that double-byte enablement will die out; everyone will figure out how to do it. That's wrong because both companies and technologies go through cycles."

"From an international point of view, a product doesn't become 'stable' until around version 3," Myers continues. "Windows, for example, had no real internationalization support until version 3. The Mac was internationalized with WorldScript in 1989; that's five years after it was first released. In the first versions of Java, there was no international support; you couldn't externalize the strings [isolate text that would change from language to language into files separate from the source code]. It was as if you were going back to Unix in 1980, changing source code and strings. As long as these cycles keep going, localization will be in demand."

Outsourcing (lots and lots of) files
Spearheading the support to develop a sizable and independent community of professional localization firms working into Japanese is none other than Microsoft. David Brooks, senior director of international product strategy, worldwide product group, is in charge of working on Microsoft's localization strategy, and finding and recommending vendors to the company's regional groups. "Localization has clearly become a very high profile topic," he states. "I meet twice a year with the chairman [Bill Gates] to talk about our localization strategy."

Not surprisingly, Microsoft has had a lot of experience localizing software, and generates a lot of demand for localization. Bill Gates recently stated that Microsoft's global localization spending for fiscal year 1997 was over $200 million. Brooks estimates that "Japanese is a sizable chunk of that [total]; in fact, the largest chunk, because we ship a high percentage of products to Japan. [The high Japanese cost] is also due to the additional complexities of double-byte enablement and the high cost of living."

Microsoft's localization style has changed significantly since it started localizing products for Japan. In conjunction with its then-distributor ASCII, one of Microsoft's early localizations was Multiplan (a precursor to Excel), released in 1983. "Initially, it was 'throw it over the wall,'" recalls Brooks, "meaning we'd finish the product, ship it in the US, and then turn over the source code library to the [Microsoft] folks in Japan, wish them luck, and go on vacation." From there, Microsoft engineers and internal contractors in Japan did everything needed to ship the product: double-byte enablement, adding an IME (input method editor) for inputting Japanese, translating documents and interface, and so forth. In the early '90s, the delta (time lapsed between the shipping of the original version and its foreign-language version) between English and Japanese versions for Microsoft were, in some cases, a year or more.

But Microsoft has since changed those ways. This year in October, for the first time, it released the English and Japanese versions of a product (Internet Explorer 4.0) simultaneously.

The globalization push
The change started some years ago, but the bulk of changes - and the real push - began three years ago. To streamline and shorten the localization process of its products, Microsoft devised three strategies: globalization of the software, a "no compile" strategy, and an integration strategy for tying localization responsibility to development groups and integrating overseas resources into the process.

Globalizing the software means writing code to make a single "executable" (execution file) with support to handle any language or script. This requires, among other things, building double-byte enablement into the core of the product and getting input and specifications from local sales and marketing offices early in the development cycle. Microsoft also pushed its business groups to globalize tools and processes.

The "no compile" strategy consists essentially of adopting development practices and localization tools that enabled English strings (text that changes in localized versions) to be removed and replaced with localized strings without having to re-compile the source code.

The integration push changed two things. One was rearranging the distribution of responsibility for localization to fall on the developers in Redmond rather than on each individual regional office. As Brooks puts it, "To make developers sit up and take notice of global requirements, we said 'you can't [just] throw it over the wall anymore. This is now your job.' Each group was made to 'own' localization of its own product." In addition, Microsoft integrated its overseas localization resources into its respective product groups.

Many publishers now take a more localization-friendly (internationalized) approach to development. As a result, it is generally easier to outsource localization work to vendors.

Needless to say, the market for software localization services has also changed greatly in the past five years. Localization firms of today face new challenges, including finding good staff, educating software developers, and responding to new avenues of demand.

Localization is a big topic, and we're not finished with it yet. In the January issue of Computing Japan, Tina Lieu (tlieu@gol.com) will explore the current state of the fledgling Japanese market for dedicated localization firms, the trends, and the direction in which the industry is headed.

Back to the table of contents