The Guide to Translation and Localization: Formatting Print and Online Documents

By Lingo Systems,
Portland, OR, U.S.A.

info [at] lingosys . com
www.lingosys.com

Get the List of 4,500+ Translation Agencies Now!
No Recurring Membership Fees!

Chapter 9: Formatting Print and Online Documents

Desktop publishing is an important part of many localization projects. It is not enough to simply translate the words and let them fall where they may. Care must be taken to present your manuals and help systems with the same sense of style and polish that they have in their source language. Fortunately the latest technology makes this task much easier. In this chapter, we will review both printed and online documentation, the changing nature of fonts, the wiles of text expansion, resizing screen captures, and portable documents. We end with a look at the tools that have revolutionized "tech pubs" creation: single-source and content management.

Roger Thompson Art Director/ DTP Supervisor Bats: Left Throws: Left Roger had another great season in 2006 as he helped carry Lingo Systems into contention in the Global Translation League. He hit 36 home runs and topped 30 stolen bases for the 7th consecutive year, and racked up 104 RBI. It was Lefty's 7th straight season with a .300 plus batting average, which is remarkable when you consider the physical demands of his position.

Experience Counts

Localization vendors handle desktop publishing in one of three ways. Some use their own employees, others outsource to contractors (either off-shore or on-shore), and the rest subcontract with the translation agencies who perform the linguistic work.

The differences can be significant, so do your homework. A skilled formatter knows many ways to ensure that your materials look as good in the new language as they did in the original. Also, with expertise comes efficiency. While the neophyte is searching for some way to squeeze text elegantly, the old pro simply reaches into a bag of trusted tricks. You shouldn't have to pay for someone else's on-the-job training.

Whether your vendor's DTP resources are located off-shore or on-shore can also affect your project. When timelines are critical or project complexity requires close coordination with other disciplines such as localization engineering or QA testing, there are often significant advantages to keeping these tasks in-house.

The best way to ensure that you receive well formatted deliverables is to ask for references and check them out. Inquire as to how many years of experience the formatters have with the desktop publishing program you use. If the job requires a new program or a new version of a traditional program, make sure the vendor knows how to use it and that they have the appropriate target language version. Since the formatting for some languages can only be done on a native operating system, your vendor will need to have invested in a variety of systems and licensed publishing tools. Even experienced formatters can get lost when working with other languages if they are only used to their own native tongue. On the other hand, experienced localization vendors will already have dealt with most system, application, and file compatibility issues. If you are invited to visit the vendor's site, ask for a tour and a demonstration of capabilities.

Selecting the Right Font

Software fonts have been around for more than twenty years. The earliest versions were sufficient to display text in dot patterns on monitors and dot matrix printers. Most did not have an extended character set to display accented characters, which is a fundamental requirement for localized documents. Even today some of the new specialty fonts do not feature even the simplest accented vowels. If you use one of these fonts, it will probably have to be replaced in order to display other languages.

Multilingual fonts were first included with the Windows operating system in the mid-90s. If the target languages were European, Slavic, Baltic, Cyrillic, or Turkic, the available fonts in the Windows character map application would probably suffice. Double-byte languages were another matter. Hebrew, Arabic, Hindi, and most Asian languages required font substitution even when Windows multilingual fonts were used. The twenty-first century has seen a breakthrough in software fonts with the inclusion of Unicode in the Windows XP and Macintosh OS X operating systems. Because Unicode fonts use more bytes per character, most alphabets around the world can be represented. Even if an operating system supports Unicode fonts, however, there are still some DTP applications that do not accommodate them. Eventually, all software fonts will be Unicode and applications that do not display them will be defunct.

Fonts can also be an issue when making PDF (portable document format) files. In the early 90s, some font manufacturers took pains to prevent their fonts from being embedded out of the fear that hackers would be able to extract them from the PDFs. This concern never materialized because the effort did not equal the prize. But if a document uses one of these older fonts and you wish to make it portable, consider changing to a different font.

Text Expansion

When English is translated into other languages, it often takes more space to say the same thing. The reason may be that the new language uses more articles, as in French or Italian, or because the words are simply longer, as in Dutch or German. On the other hand, the new language might use a few ideograms to express an entire phrase causing the opposite effect. While text contraction is rarely a problem when localizing documents, text expansion can raise some tricky issues. The standard rule of thumb in the localization industry is that European languages expand, on average, by about 30% (without hyphenation). This can pose several challenges. A table that fits on one page in English may spill over to the top of the next page in Greek. Similarly, section headings in large type might ran to two lines. Indented text could leave large blocks of white space to the left.

Dianne Ellis DTP Specialist Chocolate, cioccolate, chocolat, yuch, Schokolade, chocolade, czekolada: I believe chocolate in any language or format can solve any problem on earth. Chocolate is made up of about 300 chemicals, such as caffeine, theobromine, and phenyethylamine, and is thought to have mood-altering effects. I just know that if I put "eat chocolate" at the top of my to-do list every day, I'll get at least one thing done.

At the beginning of the localization project, your provider should ask questions to determine how you want to handle text expansion. Do you want to shrink the font to ensure that pagination, TOC entries, and index references match the English source document? If so, should the line spacing (or kerning) shrink proportionally? Or would you prefer to keep the same font sizes and allow the text to flow, increasing the page count? Can formatters "borrow" space from the margins? Can the indentations be shrank to reduce white space to the left? Can headings be made smaller? If so, should it affect all similar headings or only those that present a problem? When long words expand to accomplish full justification, the spacing between the letters can stretch in ways that are uncomfortable to read. Can justification be turned off? Do you prefer to avoid hyphenation? In some languages this results in sudden line breaks. By addressing these layout concerns at the beginning of the project, your localized documents will have much higher quality when they are delivered.

The table on the next page presents an interesting look at one study on text expansion. While the information is informative, the percentage can change significantly depending on how you decide to handle compound words and hyphenation.

Online Documentation

Online documentation avoids some of the pitfalls of text expansion and page matching that are associated with printed materials, but it introduces engineering issues. For example, if your document is displayed on a computer screen in HTML, WinHelp, or some other online format, expansion will not be a problem since the text will extend downward and the user simply scrolls down the page to read the "expanded" text. What can be an issue is whether or not the content displays correctly on the operating systems and typical viewing applications (browsers) available in your target market. By performing functional testing on native operating systems, your localization provider will be able to ensure that the applications perform and display as advertised. Be sure to discuss your specific engineering testing requirements with your localization vendor so that you are both clear on testing expectations.

Resizing Graphics and Forms

Online forms and other page elements that contain text such as graphics and buttons may also need to be resized after translation. Similarly, online forms may require special engineering to support the user's ability to enter special characters, international style phone numbers, and foreign addresses (along with any other special requirements of your international users).

Screen Captures

Almost all software documentation uses screen captures, which are no more than pictures or graphics of the software as displayed on screen. This has become a technical documentation convention for tying together the references in the document to the items the user sees on screen.

Just as translated text expands in the body of the document, translated dialog boxes in GUI applications must expand as well. One of the most common examples is an error message box. A screen capture of an error message that was originally 432 pixels wide (6 inches on a 72 dpi Mac system), might need to be expanded to 504 pixels (7 inches) to fit the translated text. In the documentation, the 7 inch screen capture must be resized to fit in the same space as the original 6 inch screen capture. This often leads to distorted or fuzzy images. To solve this problem, the screen capture can be left at 7 inches (possibly throwing off the formatting), resized to something that causes less distortion, or used at 6 inches, accepting the distortions. If your document uses screen captures, be prepared to talk with your localization vendor about how you would like these matters resolved.

It is also important that the screen captures of your localized software be taken on a localized operating system. If a question is asked in French, the "yes" and "no" buttons should be French as well. For more information on localizing screen captures, see Chapter 6, Engineering and Computer-aided Tools.

Portable Document Format [PDF]

With the advent of PDFs, documents became fully "portable" with their original layout and design maintained intact. Over time, PDFs have become specialized according to how they will be viewed. A high resolution PDF is necessary for high-quality offset printing, while a low-resolution electronic book is best for distribution over the Internet. A print quality PDF is usually huge in file size, often over 100 MB, while an online PDF can be as small as 1 MB or less. In both cases, the fonts must be embedded. Another version is a functional PDF, which contains bookmarks and links, and can even launch other applications. It is important to indicate which kind of PDF you want at the beginning of your project.

Single-source Content Management

The concept of single sourcing predates true content management. As the words suggest, it means writing one document and using that to produce more than one output. With the use of hidden text, variables, conditional text, and export filters, a desktop publisher is able to publish to multiple media, including hard copy documents, web pages, electronic books, help files, and more.

Single sourcing can be as simple as using the "Save As..." command from MS Word to create web pages. In this case the source is the Word file and the hard copy and web page are two different outputs from the same (single) source. Anyone with a copy of MS Word on their computer can accomplish this. If the web pages are subsequently imported into a help system, you now have a third use of the same material. When localized, only the Word file is translated. The original file then becomes a Translation Memory from which many other deliverables can be produced.

(George Sadek & Maxim Zhukov, Typographia polyglotta, New York: ATypI /Cooper Union, 1997. The study compared the Preamble from the Universal Declaration of Human Rights in a variety of languages, with English as the base 100%.)

Pete Landers DTP Specialist Pete first fell in love with other languages when he heard opera as a young man. Operatic arias like Vestila giubba, Mi chiamo Mimi, or Celeste Aidacon\weu, for him, images of far-off adventure. That is why, now, even though the text may be referring to a wrench or process management, the fact that it is in another language makes him think of travel. If you catch him singing "Per stringere, girare la vite in senso orario," as he is formatting text, don't tell him it only means "To tighten, turn the screw clockwise."

If your publishing requirements involve anything beyond limited Word documents, or if localization is in your future, the quick fix described above will not be sufficient. Thankfully, far more powerful and sophisticated single-source and content management solutions are currently available. These range from off-the-shelf single-source publishing programs to highly customizable, enterprise-level content management systems.

For single-source publishing Quadralay Corporation's suite of WebWorks products enables users to convert output from MS Word or FrameMaker into HTML, WinHelp, HTML Help, or even XML. The real tricks are in what can be done with the text as it passes through WebWorks. For example, a skilled user can map the styles in your source to any other style in a cascading style sheet. Or, you can create character maps to match special and extended characters to their corresponding HTML codes. As with any application, the more features it has, the more complicated it is to use. Fortunately, WebWorks comes with some templates that can be used for simple operations. Macromedia's RoboHelp product has similar output capabilities and has traditionally been popular with help authors.

A single-source solution that also includes authoring and content management tools may be appropriate if, in addition to multiple outputs, your publishing environment includes any of the following:

• Multiple content authors,

• A desire to publish in many languages,

• A high degree of similarity between content, and

• Difficulty in managing version control.

Not too long ago, content management systems were practically unobtainable for all but the largest corporations. Now, state of the art applications such as AuthorIT (which was used to create and publish this book), Documentum, and Interwoven (to name a few) use object-oriented, or relational database architecture, to combine multimedia publishing capability with authoring, version control, file sharing, and a host of other features. Perhaps the best news is that there are content management systems to fit virtually any budget, from highly customizable enterprise applications to entry-level systems with lots of functionality.

The need to provide clients with localized content is a major reason why so many companies are implementing content management systems. These tools provide a framework for creating and maintaining control of multi-language content... and thus minimizing cost. A more thorough discussion of single-source content management tools is presented in Chapter 15 by Paul Trotter, CEO of AuthorIT Software Corporation. This is followed by a description of the many benefits of integrating CMS tools into your localization workflow in Chapter 16.

[ Table of Contents ]

Read more articles - Free!

E-mail this article to your colleague!

Need more translation jobs? Click here!

Translation agencies are welcome to register here - Free!

Freelance translators are welcome to register here - Free!

Subscribe to TranslationDirectory.com newsletter - Free!

Take part in TranslationDirectory.com poll - your voice counts!

Free Newsletter

Menu