Advance preparation

Perhaps the single most important thing to understand about translation is that it's not simply the substitution of one word for another. It is a complex process involving linguistic and cultural systems. It is easier to accommodate all of the elements involved in translation when they are taken into consideration as the document is being written in English.

When you have control over the source material, there are several things that can be done in advance to help the translation process.

Avoid the use of buzz words and idioms. They simply do not translate. This particularly applies to user manuals. Wordplay in one language rarely translates into another.

Language should be kept simple and to the point. The translator must be able to understand the manual in order to produce an understandable translation. Short, transparent sentences work best in both English and the target language.

Terminology should be consistent. It is important that your writers use terminology consistently. Otherwise, two slightly different terms in English for the same thing will generate two different terms in translation.

Some common "time bombs"
There are some other items which must be considered in the case of long-term and/or large-scale translation projects.

• Acronyms (should they be translated or not?)
• Software screens (how are they handled, regardless of whether they are translated?)
• Terminology (development of foreign-language terms)
• In-flight revisions (changes made while the translation is underway)

We refer to these issues as "time bombs." They often don't get the attention they deserve in the early stages of translation, and they tend to blow up later, causing major problems.

If your documentation is part of a complex series of documents, then a comprehensive strategy needs to be developed from the outset on whether and how to deal with these time bombs. Failure to do so may land you in the position of having half of your documentation presented one way and the other half another way. At best, it will be inconsistent, at worst, unusable.

As with most things, a little advance planning goes a long way. If a manual covers or includes software that will be translated, the software should be translated first. The translation agency and the client can then work together to create a terminology list specific to the product. If your company already has a foreign presence, there probably are pre-existing terms. For the sake of consistency, it is important to coordinate the use of these terms. Excellent communication between the agency and the client is vital at this point.

Make sure that you indeed have the final version before passing it on to the translator or agency. If the English is rewritten during the translation process, confusion and errors in translation are almost unavoidable and will be costly to fix.

Other concerns
With respect to publishing, you should be aware that the size of the text will vary. Spanish, French and other European languages can take up to 50% more space, while Japanese will take much less space than English. If you plan to use a uniform format for all versions of the manual, or produce one multilingual volume with graphics, you must leave space for expansion. The text must be arranged to avoid unwanted white space. Flexibility is the key word.

Also, if you are choosing a desktop publishing package, remember that it might have to support the accented characters of European languages, or alphabets and character sets, such as Russian, Hebrew and Chinese. Consult with your translation specialist before locking yourself into a format that will not accommodate the translated version.

Software localization
Software translation is accompanied by a special set of issues. Chief among these is the problem of field restrictions. As many languages require more space than English, restrictions applied in the source material can lead to abbreviations that make the software all but indecipherable in the foreign language version.

Furthermore, the English is often abbreviated. The resulting message might seem perfectly understandable to the software designer, but there is always the chance of misinterpretation by the translator, who does not have the complete context at his or her disposal.

Let's look at the following sample:
...
5543 1 8 Operator
5544 1 6 Status
5545 1 2 F3
5546 1 4 Exit
5547 1 7 Run Job
5548 1 2 F8
5549 1 9 Return To
5550 1 8 Main Run
5551 1 3 F12
5552 1 6 Select
5553 1 7 Machine
...

Many translators receive files like this with no explanatory information. Do 'Operator' and 'Status' go together? Are 'Run Job' and 'Exit' commands, or do they go together? Are any of the numbers significant? [In fact, those in the third column indicate the number of characters for that field and must be changed with the translation.]

Every software message should be completely explicated, and if necessary rewritten in plain English, before it is sent off for translation. If this is not possible, the necessity of good technical contact between the translator and the client during the translation process becomes even more important.