Home / Archives /

Lucy Norris, Director of Product Readiness and Localization at Eastman Software (formerly Wang Software), addressed the International SIG on Tuesday, November 11, at Augment Systems in Westford. Despite the Veterans' Day holiday (or because of it?), there was a healthy turnout.

Ms. Norris' key point, which those in the audience with localization experience heartily endorsed, was that localization must be viewed as a function of software development. Dealing with localization as a function of translation is a sure recipe for disaster-or at least, multiple headaches and guaranteed missed deadlines. Language requirements should be specified as part of the product requirements. Those who wait until the actual translation will find themselves with problems such as hard-coded strings that show up in English or an excellent translation into a language that reads from right to left forced into a design that does not allow the translation to flow in the proper direction on the screen.

At Eastman, explained Ms. Norris, the linguists (translators) sit with the developers, an overt (and practical) acknowledgment that localization is an engineering as well as a translation task. Ms. Norris prefers to use in-house linguists if at all possible, and Eastman, in fact, maintains three linguists in each of the seven languages (French, Italian, German, Spanish, Dutch, Swedish, and Japanese) in which it typically does each project. Ms. Norris has worked with translation companies and advised strongly of the need for advance planning and good communication. If you work with outside linguists, you must have a contact person in your company who understands both the engineering and language needs and who can explain and insist on linguistic requirements and international conventions with the engineering and development people.

In addition to creating product specifications in support of locale-specific conventions, savvy localization managers will ensure that developers have coding practices to enable localization and adaptation. Double-byte enabling, for example, must be part of the code base. Ms. Norris recommended the programmers' checklist found in Developing International Software for Windows 95 and Windows NT (Microsoft Press).

Not surprisingly, product documentation needs to be created with translation in mind. The tools used should match both documentation and translation requirements; Eastman, for example, uses Framemaker because it supports multiple languages.

Anything that is user-oriented should be translated. Examples are screens, online help, documentation, media labels, and installation instructions. Programmer documentation and "administrative" functions typically remain in English. Whether or not to translate packaging and collateral is more of a judgment call, one that is dependent on the class of product, the channel, and the expectations of the buyer. If packaging is to be translated, be aware that the approach is likely to differ from that taken with the other material translated. The translation may need to be more of a rewrite than a literal rendering, as what constitutes effective packaging text varies from culture to culture. Germans expect technical facts, not fluff, while Italians are more appreciative of a description of the features and less interested in all the details. Because packaging text is for retail use and is likely to need a "re-spin," it may be better to have it translated locally, suggested Ms. Norris.

A widely accepted myth, and a pet peeve of Ms. Norris, is that at least 30% white space needs to be left to allow for the expansion that occurs with translation. She pointed out that 30% is a lot of white space in your English text; it's better to plan on a re-layout of your translated documentation.

Of course, the decision as to what exactly to have translated is highly dependent on market and cultural expectations. One market may expect all documentation to be translated, while another may not really care as long as all screens have been translated. No matter what is being translated, or whether it is being done in-house or contracted out, there are some guidelines to follow to make the whole process easier:

1. A glossary of terms (especially of technical terms) needs to be created and followed; terminology should be the same across the software, the online help, the documentation, the product packaging, etc. Ms. Norris recommended using Microsoft's translations of terminology. In general, she feels that Microsoft's guidelines for localization are excellent.
2. A translation "cookbook" should be created that will allow multiple linguists to translate either simultaneously or serially.
3. Do a pilot translation project, especially for new software products, to ensure that the material can be translated and that "beyond the U.S." requirements are supported. An audience member pointed out that Finnish does not have prepositions and therefore text that depends on "to" or "from," for example, is meaningless. The writing style of the English should be "clean"; jargon and terminology that is U.S.-centric should be avoided. Reference chapters rather than specific pages within your documentation, since text expansion will cause the page numbers to change. Any graphics material should most definitely work internationally; you don't want to have to fiddle with bit maps!
4. Test the localized software using the source language test plans and scripts.

OK, now you're all set as far as an overview of the localization process itself goes. But, how do you determine when to start the process? First, establish your time-to-market requirements. User and culture requirements and expectations should be key in your determination of when the international versions need to ship. Plan to do the translation process with all the languages -- if you are doing multiple languages -- in parallel. Remember that translation and engineering go hand-in-hand and that the foreign language versions need to go through the same testing procedure as the English version. Keep in mind that once the English ships, the attention of the developers will have shifted to the next project, and it will be difficult to coax them into fixing any problems encountered with the international versions. At Eastman, all the language versions ship the same day as the English or about 30 days, on average, after the English.

For more information on the International SIG of the Boston Chapter STC, contact the SIG manager, Marie-Anne de Warren

Cindy Swain is a recruitment manager at Linguistic Systems Inc. (a translation company) in Cambridge.