Written by NANCY A. LOCKE and reprinted with permission from INTERCOM, the magazine of the Society for Technical Communication. Arlington, VA U.S.A.

In the past twenty years, two developments have had an important impact on the creation and design of communication: the appearance of personal computers on every desktop, equipped with “user-friendly” authoring and design software, and the globalization of world markets. The first development means that document design is no longer left to graphic artists. Technical communicators now may be asked to “package” as well as draft copy, designing documents from scratch or working with graphic style guidelines or a prescribed design template. The second development means that, increasingly, documents authored in one language (usually English) serve as the source for countless localized versions destined for distribution in markets around the world. The concomitant development and marketing of computer assisted translation (CAT), translation memory (TM), and content management systems promote the notion that any and all documents may serve equally well as source documents.

Despite the hype, technical communicators know that authoring software does not a writer make. Graphic designers know that sophisticated design software cannot compensate for a lack of basic design know-how. And, despite remarkable advances in technology, computers still cannot produce the elusive FAQMT (fully automatic, quality machine translation). Localization still requires a committed, coordinated, and skilled team of human beings-software engineers, translators, desktop publishers, and project managers-to produce localized documentation that remains true to the content and graphic intent of the source. Even though effective localization relies on the quality of the source, documentation groups and localization teams rarely collaborate in its creation. It is not unusual for the two groups to have no contact at all: More often than not, localization is undertaken after the source document is finalized-sometimes months or even years later. This estrangement further complicates the already complex process of localization, resulting in high costs and target documents of dubious quality.

At the risk of plunking another hat on the already overburdened heads of technical communicators, I can vouch that localization-proofing the graphic design of your work will add value to the end product. And if that isn’t inducement enough, localization-proofing will prevent the quality of your work from being compromised in the localization process. For the past seven years, I have made a living as a desktop publisher specializing in localized communication. This experience has given me insight into the design approaches that accommodate localization well and the design pitfalls to avoid. Following is a list of design and formatting suggestions that will go a long way toward ensuring cost-effective, quality localization. The list is by no means exhaustive, nor is every suggestion feasible in all document development/ authoring situations. For the sake of brevity, I use the term “technical communicators” to mean both writers and designers.

Font Choice

Most technical communicators know the advantages of Postscript, as opposed to TrueType, fonts. In general, for the simple reason that PostScript is a more recent technology, PostScript fonts have standardized, extended ASCII character sets-that is, special characters, accented characters and accents, non-English punctuation, ligatures, and symbols. This is not true of all TrueType fonts, some of which have very limited character sets. Also, PostScript fonts are more compatible with PostScript printers, which produce a higher quality print output than non-PostScript printers.

Surprisingly, custom TrueType fonts still seem to enjoy popularity. Custom fonts serve two distinct purposes: to “brand” a communication, or to provide a shorthand for firmware references.

In the first instance, branding, a custom font is not problematic unless the branded text will be translated. A custom font used solely to emphasize a trademarked brand name that will not be translated-let’s use “WowTech, Unlimited” as a fictional example-rarely poses a problem, but there may be a problem if a marketing tag accompanies the brand name-”WowTech, Unlimited: We rock!”-and the tag will be translated. For example, to localize for francophone markets, the translator might choose “WowTech, Unlimited: “a boume!” If the custom font does not contain a “”,” or the myriad other characters necessary to localize a document for the expanded European Union, the money spent on branding and developing a custom font will be for naught, and/or the graphic signature (the unique look of a communication that identifies it as belonging solely to your client) will suffer.

The second purpose of custom fonts- to provide a shorthand for firmware references-poses an even larger problem. In a document filled with references to firmware features, it is tempting to create a font that simulates firmware, much like a symbol character set. For example, a skilled engineer can create a font that mimics the buttons on a phone: flash, hold, redial, speaker, memory, etc. However, these custom fonts are rarely “extended” to simulate localized firmware. That is, while the actual product may have localized buttons, the font often does not contain localized characters. As a result, the desktop publisher may be required to create images to approximate each character and insert each image in place of the simple one-stroke custom character, a long and costly process. Also, many fonts (both custom and off-the-shelf) that simulate a dot-matrix-y LCD look do not contain accented letters, diacritics, or localized punctuation.

To avoid these difficulties, choose a simple font and keep font effects (bold, italics, underlining, color, shading) to a minimum. The most common font attributes, very effective in English, may distort non-English characters. Italics and underlining, for instance, may distort Asian characters. Too much bold can convey an unintended stridency in some cultural contexts. An “all caps” or “small caps” attribute simply won’t work for a language system that does not use uppercase and lowercase.

Rule of thumb: Exploit language to its fullest and rely on its strength to deliver the message, not on the ambiguous and potentially counterproductive effects of font attributes.

Style Sheets

Despite the sophistication of style sheet utilities, I often receive graphically complex documents that exploit only one style, “Normal,” overridden repeatedly on a case-by-case basis. Documents in which styles have been based on the “Normal” style, a favored approach for Microsoft Word users, pose the same problem.

In Word documents, “Normal” is user defined, and therefore changes depending on where the document is opened. Worse yet, there is no way to tell whether the original writer’s “Normal” has been overridden by the translators or, ultimately, by the desktop publisher. In working with a document replete with “Normal” or “Normal”-based styles, the primary desktop publishing task becomes decrypting and then replicating the author’s graphic intent. Logical and consistent application of style sheets, like the logical and consistent application of text style guides and terminologies, goes a long way toward ensuring quality localized communication.

Globe-Worthy Syntax

Coherent and effective text relies on clear syntax. Similarly, coherent and effective design relies on clear “graphic syntax”-the orderly arrangement of graphic elements. Using style sheets ensures the consistency of a source document’s graphic syntax. Certain desktop publishing habits can further ensure that graphic syntax remains intact through the localization process. Most of these habits aim to counter the chief result of localization: content expansion.

Effective graphic design is the effective management of space. Text translated from English frequently occupies more space-that is, it expands. Rates vary from 10 percent and up. Greek can easily expand by 30 percent. Notable (but not the only) exceptions are Japanese and Hebrew.

Text expansion has an enormous impact on document design. After translation, one-line headings run to two lines or longer and split across “soft” page breaks. Paragraphs travel, pushing important headings down the page. Text boxes tailored for English crop callouts. Narrow page columns designed to accommodate important sideheads, kickouts, or pulled quotes in English, and tables and charts that strictly circumscribe content, cannot contain the longer translated text. In short, expansion disrupts the careful management of space-margins, tabs, text alignment, graphic boxes, and lines. Hence, localized documents need to be reformatted to restore the layout.

If you consider that a document might need to be reformatted not for just one language but for six or twelve or even thirty languages, the enormity of the task and its cost implications become clear. Consider, too, that each language, unique in its capacity to expand, requires a different “fix.” There is no global approach that meets the needs of all languages. The following suggestions will help you contend with the problems of expansion. With experience, you may discover new ways to make sure that your carefully constructed content stays put.

Don’t eyeball layout. Relying solely on your eyes when making design decisions is a tempting approach for the visually gifted, but it compromises the quality of localized documentation. Software provides the tools to ensure that the design remains intact: tabs, indents, paragraph leading, spacing and justification, etc. Explore your software’s utilities and exploit them to the fullest.

Use the space bar sparingly. The space bar should be used solely for inserting spaces between words and sentences. (Note: One space following final punctuation, not two, is the typographical norm.) Spaces inserted to achieve the effects of indents, hanging indents, and justification will “travel” in translation and will wind up not at all where they were intended to be.

Avoid soft returns or forced line breaks at all costs. Like spaces, soft returns travel. Also, some CAT software tools have trouble managing soft returns. Hard returns should be used only at the ends of paragraphs, not to create space or force text into a desired position. Space before and after paragraphs can be defined as part of the paragraph style. Use “top of page” and “page break before” utilities. Use forced page breaks only when you really want text to appear at the top of the page. Remember: The top of your page may not be the top of the localized page.

To keep paragraphs from breaking across a page, opt instead for ample widow protection. Headings should never break across a page or be divorced from the text that follows. With expansion, one line headings can easily go to two and three lines. If possible, set the widow control at ninety-nine lines to ensure the integrity of your text. In Microsoft Word, use the keep lines together setting by choosing Paragraph from the View menu, clicking on the Line and Page Breaks tab, and checking the appropriate box.

Ensure that your graphic intent is clear. In anticipation of expansion, even if your headings never exceed one line, explicitly set leading (the space between lines in the same paragraph) and, if desired, hanging indents. Keep leading loose to accommodate accents, but not so loose that an expanded heading overwhelms the text that follows.

Do not use icons and graphics as substitutes for text. While it may be true that a picture is worth a thousand words, many of these words are not acceptable in polite conversation. First, many icons and graphics simply do not “translate” well. Second, translating text loaded with icons is time-consuming and therefore costly. While word count is the most common approach to estimating the cost of a translation project, any savings realized by the use of icons (which lowers word count) will be lost due to lower speeds of work at the translation stage. At the formatting stage, icons will have to be repositioned to accommodate the syntax of the translation(s), a process that also increases cost. Such an approach compromises even the most generous localization budget.

Very few icons are understandable in all cultural contexts. Some, like the hand palm up, may be offensive or disturbing to some users. Once you have carefully chosen icons, a glossary may promote understanding. That said, well-chosen graphics and icons certainly add interest to the page and can communicate complex information. Most documents would be very dull without them. Be sure, however, to anchor these elements so that they follow the flow as intended.

Graphics frequently contain text that may need to be localized. But some common practices for increasing the ” portability” of graphics have unintended consequences that affect localization. For instance, Adobe Photoshop allows you to “merge” the layers of a graphic, which compresses all the information into one layer. Creating outlines (in Adobe Illustrator) or converting text to a bitmap (in CorelDraw) transforms text objects into graphic objects, which eliminates font incompatibilities. These practices enable your clients to open, view, and print the document even if they do not have the font that you used to create your graphic. Unfortunately, these practices can hamper localization. For one thing, they complicate text extraction for the purposes of translation. At the desktop publishing stage, removing or masking the English text in a merged graphic can be a delicate, time-consuming process, particularly if the text is surrounded by color. Because the text in a merged file is no longer a discrete element, there is no way to determine what the original font was. The desktop publisher must try to replicate it as closely as possible by choosing a comparable font-rarely an easy task. Preserving “source” graphics with discrete layers and fonts intact saves both time and money.

Ideally, text in graphics should be avoided. Extracting text from graphics is time-consuming and labor-intensive. Worse, text embedded in graphics may be overlooked. The most cost-effective approach is to create callouts in the desktop publishing program that are then accessible to CAT tools.

One final word on graphics: Instead of copying them into your documents, use links. Copied graphics can be difficult to identify, and tend to make documents “heavy” and hard to manipulate.

Generally, the space allotted to all page layout elements-margins, headers and footers, columns, sidebars, etc.-should be more ample than that required by the English text. If you try to “shoehorn” content onto the page to minimize printing costs, increased localization costs will generally outweigh any savings to your client.


Localization presents a wide range of challenges to communicators. This article examines only a few. It is my hope, however, that an increased awareness of the challenges, a dialogue between the creators of source and the producers of localized documentation, and a closer general collaboration between the professionals in both disciplines will widen the range of approaches and solutions.

Nancy A. Locke is a multilingual desktop publishing specialist with over seven years’ experience with localization and translation providers in the United States and Canada.