The next time you power up a PC, imagine viewing a file menu in French, a dialog box in Czech, or a date in Chinese. Not what you’d call "user-friendly," but, nonetheless, examples of what many foreign users face daily with English-language software applications.

One way to offer foreign users the same level of convenience, comprehension, and satisfaction that native English speakers enjoy is "software localization"—a facility that makes software communicate with users in their native language.

Although they accept localization as a desirable and laudable objective, developers of scientific and engineering application software have been slow to offer localized products. Much of the reason stems from a belief that localization means facing intractable language problems. Supporting applications in one language is generally enough of a problem, they believe, without having to add as many as 30 other versions.

In fact, some developers avoid the issue altogether and voice a popular argument that their foreign users are mainly scientists and engineers, who are already English literates. Other reasons vendors express for not localizing their products relate to cost, loss of quality control, and extended time to market.

Despite these arguments, communicating with a PC is, by definition, personal, a tête à tête involving a user and a powerful tool. Anything less than 100% communication implies proportionately less efficient use of the tool’s functions.

It’s true that a well-designed graphical user interface (GUI) can minimize the requirement for textual communication and works fine for day-to-day operation, once a user is familiar with a product. But when running a tutorial or when operation takes an unexpected turn, the user needs to understand text messages or to head for a help menu.

No doubt many global users accept English software applications. But, in most cases, it’s because they have no alternative, and locally developed alternatives, when available, offer limited capability and support. Even English-speaking foreign scientists and engineers, given the choice, prefer communicating in their native languages. Additionally, where applications communicate with technicians and unskilled operators, English-language software may be unusable.

If you want to localize software products, the obstacles are formidable but not insurmountable. Much depends on the level of localization you are targeting. At a basic level, simply translating screen text is straightforward. Adding processing of user inputs for one localized language is more complex, and expanding that facility across multiple languages significantly increases the challenge.

Ideally, you need to lay foundations for localization at the outset of development. For example, you need to partition screen text from operational code for your application. Also, you need to consider which markets to target for localization. Japan comes high on the list of priorities, and that means your application must support a double-byte character set; US and most European-language software uses single-byte characters.

Fortunately, companies such as Microsoft and Apple have pioneered this territory in their advances on domestic and home users. As a result, MS-Windows and Macintosh developers find many of the architectural features and facilities for localization built into the development tools.

In addition, there are plenty of subcontract companies specializing in software localization. Generally, these companies offer wider localization services, including translating support documentation, developing glossaries, and distributing software. These localizers accept MS-DOS, MS-Windows, Macintosh, and Unix applications.

RR Donnelley Information Services is a major company in the information-translation business. Software localization accounts for around 40% of the company’s revenue, and 80% of that work involves translating MS-Windows applications. The company operates from 10 offices around Europe and one in Beijing. The company localizes products into 15 European languages—principally French, German, Italian, and Spanish—and into Chinese, Japanese, and Korean.

David Roach, vice president and director of business development at Donnelley, explains that the company’s service extends beyond straightforward translation to include creating, managing, and distributing information. Reducing customers’ time to reach global markets is a primary focus of the company’s service.

As an example, Roach cites work for companies such as IBM and Microsoft, where it once took up to nine additional months to release foreign-language software. Now, it takes three to four weeks maximum. Roach says these time-to-market reductions for localized products are broadly in line with speedier hardware developments: Five years ago, it took two to three years to develop a PC; now, it takes three to six months.

To attain this level of service, Roach describes Donnelley’s hub-and-spoke strategy, which centralizes nonlanguage activities, such as preprocessing, setting up glossaries, and handling stylistic issues, and places these services on line in Donnelley’s national offices.

Roach stresses the importance of localizing products within the target country and of using staff with both development and end-user expertise. Without this arrangement, you can hope neither to incorporate cultural and straightforward translation issues nor to maintain the quality of a localized product. Roach believes that, because of the speed of changes in the information-technology sector, localizers should not spend more than six months away from their target countries. More than that will make them unattuned to the nuances of culture, colloquialisms, and jargon to maintain quality in localization.

Localization can be routine

Microsoft has more than a decade of experience in localizing its products and routinely offers software in as many as 30 languages. Although the company maintains a high level of in-house localization expertise, globally dispersed subcontractors perform most localization.

John Hopper, desktop-unit product manager at Microsoft, believes that localization involves more than just word translation. He says, in general, you also have to consider language structure and cultural issues. There are additional problems with languages that don’t use a Roman alphabet and that require right-to-left page layout.

Some of the challenge is translating the jargon that US marketers create from bits of other words, which make sense only in English. One example is Microsoft’s use of "wizard," which, when translated literally into other languages, may convey a meaning different from what Microsoft wants to imply.

Another basic problem is providing sufficient character fields for localized versions. For example, Microsoft’s German translation of "undo" becomes "Rückgängig," and "preferences" be-comes "Bildschirmeinstellungen," both too long to fit in the fields required for the US version. Also, localization extends to packaging where color plays an important part. In some countries, purple has strong deathly connotations—clearly unsuitable for a "new-version" banner.

Hopper explains that word order poses further problems because software constructs expressions by pulling words from areas of code. A word order in English commonly doesn’t track into a local language. For example, the word order in the string "Place disk 1 into drive A," which typically uses 4 bits of text, is incorrect in other languages.

Similar errors arise when using a fill-in algorithm with time and date information. In some countries, Monday, not Sunday, is the first day of week, and date format expects a year to be read first. In addition, some languages use a colon, a period, or a space as a character separator. Overcoming these problems requires small changes to the structure of the software as well as to the translation of text.

Hopper says an overall objective for those software developers anticipating localization should be to confine information for translation in a dynamic- link library (DLL). Then, when the software composes a string, it calls on the DLL, which returns the text. In an ideal situation, that arrangement means that localization needs access only to the DLL, minimizing the chance of interference with the software’s fundamental operation. Hopper says one alternative is for localizers to edit tokens, or resource libraries. But that alternative means that they have to retest the product for basic functionality.

With a wealth of localizing experience, Microsoft developers anticipate many difficulties when designing a base product in English. Despite this experience, Microsoft often develops localized versions in parallel with the base product to highlight problems early. Following this strategy, the company routinely launches seven localized versions of products such as MS-Windows simultaneously with the US base version.

One problem Microsoft has identified is a need to maintain consistency in translation across a variety of products and revisions. For MS-Windows developers, Microsoft publishes a GUI guide (Ref 1) that offers localization guidelines for the main components of Windows and includes a glossary in 14 languages.

Japanese is high priority

National Instruments offers a Japanese-localized version of its Macintosh LabView instrumentation-software system. The company has limited localization of LabView to translation of the dialog box and menu bars. This work involved introducing double-byte characters and localizing displayed text in kanji characters on LabView.

According to Paul Austin, software engineer with National Instruments, you need to decide at the outset of a design which level of software localization you want to reach. At a basic level, translation of dialog boxes and menu bars on a user interface is straightforward using readily available stand-alone tools.

A second level is to process localized data to provide data entry, to save program or configuration settings, or to operate a search facility. At this level, you need to employ system functions for Windows and the Macintosh. For example, system functions for sorting strings can depend on your locale. Using these functions makes much of the localizing effort transparent.

At the final level, Austin says, there’s a difference in complexity between writing an application to be localized in just one language and one you expect to localize in several versions. Austin’s general advice is to be not too ambitious in constructing long sentences. There are simply too many variations in sentence construction in different languages to expect to rebuild accurate lengthy text strings.

Racal-Redac Systems also offers a Japanese-localized product. The company has recently applied Japanese localization to the pc-board, multichip-module, and postprocessor tools in the company’s Expert workstation electronic-design-automation suite. Duncan Hooper, senior development manager for CAD/CAM tools, says the company limited localization to warning and error messages and to input and output of design text. He says that, although system users can handle an English GUI, they must be able to read warning and error messages that signify unusual events. In addition, shop-floor operators have to be able to read manufacturing documents that the tools generate.

To generate documents in the Expert system, you have to type Japanese text, and the system must be able to plot out that information. Building in the facility to plot out Japanese characters proved to be a significant task. The characters require a vector font that can be stroke-drawn with a photographic or pen-plotting device, rather than simply referenced to a standard bit-map font, as with normal text output.

Hooper says a "locale" facility in Unix utility X11.R5 was instrumental in enabling Racal to produce a localized version. This facility aids the assembly of message catalogs of translatable text and handles multibyte characters for Japanese. The company assembled the message catalogs in its UK plant and carried out the translation at its Japanese office.

1. "The GUI Guide—International Terminology for the Windows Interface," Microsoft Corp, 1993.

2. "How to Write Localizable Macintosh Software," Addison-Wesley.

3. Lunde, Ken, "Understanding Japanese Information Processing," O’Reilly & Associates.