Preparing Projects for Localized Desktop Publishing

By John Watkins,
President and COO,
ENLASO Corporation

marketing [at] translate . com
www.translate.com

Introduction

If you search the Web for guidelines for preparing projects for localization, you will find that most of the results focus on issues related to language content. For technical documentation and marketing materials, preparation and guidelines for the document publishing portion of your multilingual projects are equally important.

Some customers new to translation and localization often assume that translated documents simply open up in the same format as the source files, requiring little or no manual adjustments. This is not always the case. Ways to handle text expansion, special language-specific fonts and manipulations of the final output are just a few of the decisions the customer must make. Some planning, including the development of styles and formatting guidelines, can greatly streamline the publishing process of localized files.

ENLASO has assembled an impressive list of guidelines to help you meet multilingual publishing challenges. This white paper includes a thorough checklist, with some examples, that covers the decisions you should make and the information you should provide before starting a publishing oriented localization project. These guidelines are aimed at projects with paper or PDF output as a final deliverable; software or Web site localization require somewhat different guidelines.

General Questions to Keep in Mind

• Is the project a new translation (from scratch) or an update to a legacy project? If it is an update, is it minor or major? Do you have the legacy source and target language files for any updates?

• What are the source and target language(s)? Specify the country or locale as well (e.g., fr-CA for Canada vs. fr-FR for France).

• Are style guides available for the source documents? What about for style guides for the localized documents? If not, can they be created? Do you need your localization vendor to prepare these for you?

• What turn-around time do you require for the localization effort, including the layout of localized files?

• Does the project include a customer review step of the translated content and/or formatting before final delivery? If so, has the internal review staff been identified? Have internal review turnaround times been established?

• Are changes to content or format expected during the project? This will influence the probability of change orders and the likelihood of project cost increases. Expected changes often have an impact on cost and delivery time.

• Do you have an existing Translation memory (TM) from previous projects?

• Are there localizable graphics (graphics that contain text that needs to be localized)? If so, can you provide the source graphic files for editing?

• Are there screenshots from software that appear in the document? Is the software localized (requiring the placement of localized screenshots in the target language documents)? Can you provide the screenshots or should the vendor capture the screens for you from the software?

• Are there specific fonts for the vendor to use, or should the vendor select appropriate fonts for the target languages?

• Will a single sourced document provide multiple outputs? (e.g., FrameMaker outputting PDF, HTML and Help via WebWorks or RoboHelp?).

When Sending Files to the Vendor

• Clean folder structures: Provide an organized and clean folder structure with all source files needed to build the documentation (including any artwork). If possible, only include files that are used in the documentation for localization. It is always preferable if the files are “collected for output” including fonts, when they are in Quark or InDesign.

• Final source files: Provide source files as close to “final” as possible. Most accurate estimates are done on final files. If non-final files are provided, a vendor must re-analyze files prior to project start.

• Final output of source: Provide final deliverable output of the source language (typically a final PDF). This is referred to as the 'Go by', and is used to assure consistent and high quality output for the localized documents. If final deliverable output specifications cannot be provided by the client, the vendor will create them and request the client's approval prior to their use.

• Platform/Applications/Versions of source documents: Provide information on all platforms (e.g., PC, Mac, UNIX, Linux) and applications (e.g., FrameMaker, InDesign, QuarkXPress, Illustrator, PageMaker, WebWorks, Word, Excel, PowerPoint), and versions (E.g. FrameMaker 7.0 or 8.0, InDesign CS2) used in creating the source documents.

Publishing Phase

• Pages: During documentation layout of the localized content, the vendor needs to know if the page flow has to match the source documents (e.g., whether page breaks must match, whether documents must end on an even or odd number of pages, and the maximum allowable page count.

• Text expansion: As a general rule, expect content to expand 20-30% for European languages. Asian languages tend to come closer to English in page length, but they typically require larger font sizes. Consider the preferred format overrides the vendor should use (e.g., kerning adjustments before adjustment of line spacing before adjustments to smaller font sizes).

• Fonts: Some languages require different fonts to render the characters correctly. If you have strict preferences for appropriate fonts, provide this information to your vendor early in the localization process. Note: if you have established a custom designed “corporate font,” there may not be equivalent style fonts for eastern European and Asian languages.

• Units/address/phone/currency: During the localization process, measurement units may be left in English units or need to be converted for the appropriate market. It is best if you provide the converted units, if they are necessary, to ensure compliance with your products. In a similar vein, you may need to provide alternative contact information (address and telephone numbers) and currency rates to be used in the localized documentation.

• Graphics: Preparing graphics for localization can save money during the localization process. Ensure that the graphics have “text layers” so that the text can be easily accessed and modified by your localization vendor. If these text layers are “flattened”, the vendor must budget for re-creation of text layers.

• Screenshots: Software documentation often contains screenshots from the software for reference. If the software is localized as well, then localized screenshots should be placed in the localized documentation.

o If they will remain in English, how should the localization vendor handle User Interface references within the body text that directly refer to a screen shot?

o If screenshots are localized, will the localization vendor recreate screenshots after the User Interface is localized or will you provide them?

• Part/artwork numbers for the localized documents: Make sure to provide project specific language codes, part numbers, and artwork numbers that replace related numbers from the source files.

• Style Guides: These publishing phase guidelines are often combined into style guides for each target market. Style guides provide a living document of these requirements, helping to ensure consistent quality over multiple projects for each target market. Working with a localization vendor experienced in the development of target market style guides improves your localization efficiency. Deliverables

• File naming and folder specifications: You may have specific requirements for the delivery of localized documentation files (including file naming conventions, directory folders naming and structure. Communicate to the localization vendor about your specific needs.

• Change in application for deliverables: Clients may need to transfer their source content from an old application to publishing software more suited for your target language(s) (e.g., PageMaker to FrameMaker conversion) to better accommodate features like tables and cross references. Conversion to another application may also be necessary if the source application does not support your target language(s). For example: FrameMaker 8 doesn’t support Arabic or other bi-directional languages. In this case, InDesign would be a better choice.

o If document conversion is necessary, re-creation of the source template in the deliverable application is required prior to localization. Make sure to approve the final source template prior to starting translation.

• Translation memory: Using a translation memory can improve quality (by supporting consistency in the translation) while helping to reduce costs through the leveraging of previously translated text. Do you have specific translation memory format requirements? There are a number of tools available, though the largest market share belongs to Trados and the TMX translation memory format.

• PDF specifications: Documentation is often output to PDF format. Should PDF be Web or print ready or do you need both? If PDF must be print ready, make sure to provide resolution requirements, dpi and final page size specifications. If PDF is for print, should a registration mark be added? Are bookmarks required or other special features? When either party (customer or vendor) “guesses” what the best output specification would be, there is the risk of additional billable time required for recreating correct PDF output.

Summary

Finding the answers to these questions eliminate many of the surprises that can occur in multilingual documentation production. Internal fact-finding to provide full specifications to your localization vendor is well worth the effort, saving time and money during the localization process. The tips in this white paper can help you avoid unwanted project delays or costly change orders.

For more information or to request a quote, please contact us by phone at 303 516 0857 or by e-mail at marketing [at] translate . com.

Corporate Blog of Elite - Professional Translation Services serving ASEAN & East Asia