Adventures in Translation (Part 2): 
Preparing Your Documents

by Margie Yundt

You've kicked off a project to write a documentation suite for your company's latest software innovation, and they need this documentation, and the software translated into French, German, and Japanese. After weighing all the options, you've chosen a translation company to handle the translations, including the localization of the software, and obtained quotes for the project (see April's article: Finding a Vendor). What now?

Breathe. You can handle this. Read on...

Creating Documents for Translation

To begin with, keep the following in mind when you are creating documents for translation:

• Be clear and concise. Don't leave the translator wondering what you mean -- leave no room for misinterpretation. Every word they need to translate directly affects the bottom line, so be frugal (but not at the expense of clarity -- that counts too!). Write out acronyms the first time you use them to avoid confusion. You want to make sure you and the translator(s) are referring to the same thing.
• Avoid slang and western-biased images. Slang is difficult to translate and understand in a foreign context. Be aware of your international audience -- are they going to get your reference to the Energizer Bunny^®? Probably not, unless you are referring to "The Bunny" as dinner!
• Keep text out of your graphics. Whenever possible, avoid including text within a graphic. It will cost you more money, and/or more time, for translators to go into these graphics and translate the text they contain. Consider using alphanumeric labels in graphics and include descriptions for these labels in a separate table below each graphic.
• Allow for text expansion. Make sure the template you are using gracefully handles longer character strings -- for example, in French user is utilisateur; that's quite a difference in character length! Admittedly, with today's 'automagic' templates, string length is usually more of a concern in the software interface then in desktop publishing. Still, you should consider this factor when creating table formats or side headings. Ensure you leave enough white space to avoid truncated or hyphenated character strings, and remind developers to consider spacing when setting up the real estate for the software interface.
• Ensure your template is international-friendly. More than just accounting for varying sizes in character strings, you need to ensure your templates are going to play nicely with other languages, which may include accented characters, special symbols, and/or certain stylistic conventions.
  
  This means stick with the standard serif and sans serif fonts, such as Times and Arial, as these fonts are widely available, legible in a wide spectrum of languages, and, in most cases, have a built-in extended character set for special characters and symbols. If your company uses a specialized or non-standard font, consider finding a conventional alternative. If you don't use a standard font, be prepared to do some early testing of sample translations and/or incur additional costs if the translator (and reviewers) must buy one or more fonts specifically for your project.
  
  Also, consider the flexibility for switching page sizes from the North American convention of 8.5x11 to the European convention of A4 (8.27x11.69). If possible, set up your template to switch between these two formats without affecting pagination. FrameMaker^® does this well.
  
  And, if possible, set up automation in the template to grab the content (for example, running headers) from the body pages. In other words, avoid "hard-coding" English text in macros, because anything you hard code will need to be manually updated by either you or a translator within whatever software you are using. Will the translator know enough about the software to do this? Maybe, maybe not.

Sending the Documents to the Translator(s)

Okay, so you've completed your documents, and you have all the string files required from Engineering to translate the interface. Now what?

Next, you need to send these files (with clear instructions) to the translation company. In addition to the source files, your package should include the following:

• A style guide or format description document. Provide a document that clearly identifies any automation in the template(s) that you provide, the document structure, what to translate or not translate, and the expected format for the deliverable. The more information you provide up front, the less chance there will be of any misunderstandings about what you get/don't get back.
• A copy of the software being localized and any special installation instructions. You should also provide test files and any configuration files that are required to run the software. Translators who can run the software, can also test the translation and put strings for translation in context with the program being documented.
• PDF versions of the documents being translated. Translators like to compare the source documents they are translating with the finished English versions so they can make sure the formats match and the translated content appears as expected.
• A cover letter describing the contents of the translation package (or e-mail). Include contact information for questions -- e-mail is a great (and cheap) way to communicate, especially across time zones!

If your project involves translations into multiple languages, ensure you provide a complete package for each translator. Or, if you e-mail the information, let the translation company distribute the information to individual contractors. In this case, consider installation for the project as a self-extracting zip file for everyone to download (using a password you provide) via a secure FTP or Web site.

Want to know more? Have questions? Come out to our STC chapter meeting, "Translation 101", on Tuesday, May 4th and quiz our panel of know-it-alls, um, I mean, experts. See you there!