Best Practices for Successful Documentation Localization

Which Points Should Be Considered in Documentation Localization?

Documentation localization can be a large, expensive endeavor. This article outlines simple, logical steps that involve the intelligent use of page geometry and common document elements that lead to substantial cost savings and shortened project delivery schedules.

The most common challenge with localized desktop publishing (DTP) is text expansion. Text often expands as much as 35 percent when translated into other languages. For instance, if source English paragraphs wrap on the page to a depth of six inches, the same text translated into German could wrap to a depth of eight inches.

Controlled Use of Tables and Containers

Some customers utilize tables for cosmetic purposes rather than emphasis of data. A classic example is a document format that boxes “important steps” within ruled table cells. A narrow left column serves to display side heads. This style encases generic content in tables, thus magnifying text expansion. This is particularly true where text is displayed as multi‐level nested lists within table cells.

Such tables act like miniature pages, reducing the useable page area. When you create content, ask yourself “does this need to be in a table?” Not only do table cells magnify text expansion after localization, table cells also increase file size which adds to extended upload and download times.

Another misuse of tables is boxed text, used for cautions and warnings. This type of text justifiably needs emphasizing; however, the text depth should be carefully limited in the source language. A warning box that is four inches deep easily expands more than an inch after localization, causing headaches with page breaks and subsequent text flow.

When you do use tables, avoid rotated or sideways text in table header cells. Rotated cell content does not wrap as regular body cells do, thus the height of the table header cell can grow dramatically with the translated, expanded text. Taller header rows bump portions of the table across multiple pages, and exponentially increase the final page count.

Thumb Tabs

Thumb tabs in the outer page margin with 90° rotated text cause similar problems as tables. Using thumb tabs is often necessary in certain types of documents such as catalogs. Before sending your content for translation, create language‐specific templates with a condensed typeface. Avoid UPPER CASE text, as not all languages support upper case usage. If your thumb tabs contain only product names that are not to be translated, you will not have any problems.

Text Layers in Illustrations

Illustrations, graphs, and images often contain descriptive or legend text within them. As such, they are labor intensive to localize. Typically, your staff or your localization vendor opens the source files in the native format (e.g., Illustrator or Photoshop), extracts text from text layers, and places the text into another format (e.g. MS Word). The localization vendor translates the text, and then someone manually copies and pastes keyed text back into the appropriate location within the source art. This leaves room for human error at several stages.

Whenever possible, confine such legend text outside of the artwork, for instance in a table below the illustration. This enables your legend text to be part of the overall document flow, which automatically transits into translation software tools—without manual extraction.

Redlines

Redlines, or updates to previously translated projects, sometimes incur additional cost due to the many manual steps involved. A combination of XML document structure and a content management system (CMS) allows for easy re‐use of content. This reduces translation costs and makes redlines more manageable. However, the initial setup costs for such a solution are often beyond the budget of many customers. Hence, the majority of redlines are manually marked up within a Word document or PDF.

Localization vendors must be able to read notations for changed content and update files accordingly. Many redline changes involve only formatting—for instance, boldface text or line break addition. The localization vendor must segregate marked pages for linguists (text content changes) and internal publishers (format only changes). If you are marking up redlines with annotations in PDF documents, use different colors or note objects to differentiate your text content changes from format changes.

Acrobat tools may be used to make comments display “by type,” giving the localization project manager a quick way to determine how many linguistic and formatting changes are involved. Note that redlines are not always the most efficient way to update your translated documents. If changes occur on every page, or every paragraph, it may be more effective and less error‐prone to rely on translation memory to identify changes.

Conclusion

These are just a few of the simple steps and tools you can use to manage documentation and localization projects to constrain costs. These steps, integrated with regular team communications with your localization partner, help reduce costs and ensure your projects’ success.

Argos’ Translation & Localization Solutions

For more information on how Argos can assist you with all of your translation and localization needs, please have a lot at our desktop publishing services or contact us.