Technical Writing And Localization

By Author: Eric Hughes
Total Articles: 37
Comment this article

Writers who write technical documents intended for localization need to pay attention to much more than verb agreement and active voice. These writers should also focus on rules that make it possible for translators to match the original document in intent and in structure and minimize the cost of these translations in the process. When I researched articles and books on writing for localization, I did find one interesting fact. Following the rules for localization generally made the document better in English as well.
Some basic guidelines
If you are serious about writing for localization, get this book, The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market. Until you get the book, here are some guidelines to get you started:
Use shorter sentences. Avoid nested clauses or phrases.
Reuse or repeat as much language as possible: phrases, terms, notes and warnings.
Avoid using words that have more than one meaning.
Use nouns as nouns and verbs as verbs.
Use 'that' in all those places you were taught not to use the word 'that.' Removing 'that' as we ...
... were taught in Freshman English only makes translations more difficult and more subjective.
Avoid idioms. Favor usages that are in an ordinary dictionary.
Give clear instructions to the translation agency. Make sure everyone is on the same page.
Keep it simple with shorter sentences
This is always a good writing technique. I have found that when I am trying to write a concept and it the concept just cannot be framed, I probably need to break up the thought into two or more sentences. It is like trying to put 10-pounds of stuff into a 5-pound bag.
Keep in mind that sentence structures, even thought structures, are not the same globally. If you want as direct a translation as possible, do not use a sentence structure that is predominate only in English. It can get mangled fairly easily.
Consistent verbiage
This is a great rule in that it helps the translation, helps the readability in any language, and it saves on translation costs. Obviously, you are using the same words for all of your UI controls or technical terms but if you start most of your interface tasks with the same phrase, "On the command bar, select... " or "At the main window, select... " You have just made the author's job easier, the translator's job easier, the user's reading experience easier, and you will not be paying for as many "fuzzy matches."
This is true for any words, phrases, paragraphs, such as notes, cautions, and warnings, or any consistently repeated and reused item. Repetition also puts the emphasis where it belongs: on the content.
Idioms for the Idiomatic
Some idioms and idiomatic phrases are so ingrained in our culture that we have become unaware that they are idioms. My best recommendation is to become aware. Some examples of words and phrases follow:
the bottom line
for the most part
bear in mind
Also, using a word that has more than one meaning in English:
'since' when you really mean 'because.'
'figure out' when you mean 'determine.'
Rules for the Translation Agency
Rules breed consistency and they also set up realistic expectations for your translated materials. In most cases, you would not want an interpretive translation of technical material. That means that you want your copy translated to match the form and function of your tasks, concepts and references. I didn't realize how important all this was until a translation agency, a previously reliable translation agency, totally botched the translation of our newly minted DITA XML files. They had done fine with the trial copies and in all languages but most of the completed files had to be sent back for them to fix.
First, they said they could handle DITA XML when they really didn't know what it entailed. Using their translation tool, it should have been simple. Strip out the phrase, check the context, translate it, put it back in, no problem. Right? Oh, and validate the reconstructed file against a DITA Document Type Definition (DTD). DITA has an element, menucascade, that allows you to enter a menu item > menu item > menu item structure.
For example, select File > Print . Some of the files came back with, "Select Print on the File menu." Not so bad. However, some of these were 3-level cascades and they read like spaghetti by the time they were translated. But worst of all, it broke the code.
Another example of interpretive translation occurred in the German translation. We noticed that some of the words were partially rendered in boldface font. We use boldface font for selectable UI controls and windows. The translation agency provided a translation of the Results window like this, 'Ergebnisfenster.' That did not work for us style-wise. We checked other German translations from other agencies and found that the norm was, 'fenster Ergebnis.'
These are just some of the examples of agreements you must make before you go too far with translations. Here are some suggested actions:
Hire really good proofreaders to review your translated documents against the original English.
Keep a record of any and all disparities between your expectations and the translated documents. Use this list on every new project with every new translation agency.
Create a Glossary of terms. This is an absolute necessity for most translation agencies.
Relax, have fun. This is easy.

essay papers online