As a translation project manager, there’s never a dull moment. Over the course of a day, I communicate with linguists and clients across every time zone and assure the quality and delivery of documents from many different subject domains into many different languages. All sorts of unexpected problems arise requiring me to think outside of the box and find creative solutions.
One area of my job that creates unusual situations is desktop publishing (DTP). Multilingual desktop publishing is the process of reformatting a translated brochure or catalog to account for the different “look” of a new language. What could be so hard about formatting a translated document? It’s more complicated than you might think. There are many reasons why we can’t just use InDesign to put translated text in the space where the English text used to be. Sometimes the biggest challenge of multilingual DTP is reconciling the design preferences of the client with the limitations and idiosyncrasies of the written target language. In these cases, my responsibility as a project manager is to figure out (and diplomatically explain) a solution that works for the client while maintaining the readability of the translation for the client’s audience.
Complications occur when the client wants the translated document to have the same number of pages as the English source. This is not always possible, because of text expansion or contraction. Romance languages use up to 30% more characters than English; French and Italian “expand” during translation and require more space on the page. On the other hand, some Asian languages contract. A Chinese translation of a document that looks perfectly formatted in English can appear sparse, with too much white space.
We use a tool to create a pseudo-translation to anticipate what design changes may be needed to compensate for this. Pseudo-translation creates a “dummy” translation that mimics the qualities of the target language and predicts the size of the translated document. This is an effective way to demonstrate to a client the impact of text expansion or contraction for the document or application as a whole.
While working on the Spanish translation of a patient guidebook for the non-profit organization Living Beyond Breast Cancer, our desktop publishing team ran into different text expansion-related design issues. Although the client did not need the Spanish guidebook to have the same total number of pages as the English source, they did need to have certain information and images on target pages whose numbers corresponded to the source page numbers.
Spanish “expands” 25-30%. Had this had been a digital translation project, we might have accommodated expansion by selectively using a smaller font. However, for a print document, a small font size is too hard to read. Working together with the desktop publisher and client, we developed a style guide that addressed their specific needs and also provided multiple solutions for reflowing text. The style guide helped the desktop publishers working on other languages to effectively incorporate the client’s specific needs.
I’ve also learned that right-to-left languages like Arabic present their own unique set of challenges. For example, it’s a common misconception that only the Arabic text needs to be oriented from right-to-left. In fact, the entire layout needs to be flipped. If a series of images is supposed to be read in sequence, keep in mind that these must also be ordered from right-to-left. Also, the images themselves may also need to be localized; Arabic readers expect to see checklists presented with check-marks down the right hand side of the page.
Sometimes the text uses both Arabic and English. It takes an experienced desktop publisher to know how to incorporate the left-to-right reading English words with the right-to-left reading Arabic text. Here is an example of an English-language text translated and localized into Arabic which demonstrates all of these changes.
A client may want to use their corporate font so that localized documents are visually consistent with their other publications. However, the corporate font might not include the characters needed for the target language. In this case, a substitute font has to be used.
If a substitute font is used, we prefer to deliver multilingual desktop publishing projects as “outlined” files, in order to ensure the stability of the design. If a client opens a “native” file on a machine that does not have the proper font installed, the computer will either deliver gibberish (because of character mismatches) or substitute an available font. For languages with non-Latin writing systems, we always provide an outlined version, which freezes the text (like a .pdf) and prevents substitute fonts from hijacking the layout, especially if the file will be opened several times on its way to print (fonts can be tricky — read more here).
Line and page breaks
It is relatively easy to create correct line breaks with languages that use spaces between words in the same way that English does. But other languages have different rules about where line breaks can fall. I have encountered problems with text-wrapping and line breakage when formatting Korean texts for brochures and e-learning modules. Korean words are are composed of syllable blocks. Each syllable block contains 2-3 characters. This can cause problems because Korean words are improperly truncated when line breaks fall between the wrong syllable blocks. Similarly, in Chinese, a single word might be composed of one character, or of several characters. If line breaks separate a multi-character word, the meaning of the whole sentence can change. The most skilled user of InDesign cannot format a Chinese or Korean text if they can’t read that language. In addition, it is impossible to translate phrase-by-phrase between English and Korean, because the syntax is so different. Therefore, a request to have the exact same information on corresponding pages can’t always be accommodated.
Just when you think that you’ve seen it all in desktop publishing, a client will ask for something new. It’s my job to accommodate the request as best I can while clearly explaining why the structure of a particular target language might not allow it. Asking questions before starting a project, creating a style guide based on what worked during previous jobs, and speaking with the desktop publishing team about potential pitfalls are all ways to prepare for whatever unexpected situations may arise.