Specialized Writing and Localization

Freelance writers who write technical documents intended for localization need to pay focus on much more than verb contract and active voice. These writers should also give attention to rules that make it possible for translators to fit the original document in intent and in structure and minimize the price of these translations in the process. When I actually researched articles and textbooks 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

When you are serious about writing for localization, Fenster get this book, A global British Style Guide: Writing Obvious, Translatable Documentation for a Global Market. Until you get the book, here are some guidelines to get started on:

Make use of shorter sentences. Avoid nested clauses or phrases.
Recycle or repeat all the language as possible: phrases, conditions, notes and warnings.
Avoid using words which may have more than one meaning.
Use subjective as nouns and verbs as verbs.
Use 'that' in all those places you were taught to not use the word 'that. ' Removing 'that' as we were taught in Freshman English only makes translations harder and more subjective.
Avoid idioms. Prefer usages that are in an ordinary dictionary.
Give clear instructions to the translation agency. Make sure everyone is about the same page.
Maintain it simple with reduced sentences

This is always a good writing approach. I have found that when I am wanting to write a concept and it the concept just are unable to be framed, I probably need to break in the thought into two or more sentences. It is like trying to put 10-pounds of stuff into a 5-pound bag.

Remember that sentence structures, even thought structures, are not the same globally. If you want as direct a translation as you possibly can, do not use a sentence framework that is predominate only in English. It can get mangled fairly easily.

Steady 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 words but if you act like you start almost all of your software tasks with the same phrase, "On the control bar, select... " or "At the main window, choose... " 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 much "fuzzy fits. "

This is correct for any words, phrases, paragraphs, such as notes, cautions, and warnings, or any regularly repeated and reused item. Repetition also puts the emphasis where it belongs: on the content.

Idioms for the Idiomatic

A few idioms and idiomatic terms are extremely ingrained in our culture that we get become unaware that they are idioms. My best recommendation is to become aware. Some examples of words and phrases follow:

the base line
in most cases
bear in mind
Also, using a term that has more than one meaning in English:

'since' when you really mean 'because. '
'figure out' when you imply 'determine. '
Rules for the Translation Agency

Regulations breed consistency and they also set up practical expectations for your converted materials. In most situations, you would not want an interpretive translation of technical material. That means that you want your copy translated to match the shape 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 freshly minted DITA XML documents. They had done fine with the trial replicates and all languages but most of the completed data files needed to be sent back for them to fix.

1st, they said they could handle DITA XML when they really didn't know very well what it entailed. Using their translation tool, it will have been simple. Strip out there the phrase, check the context, translate it, put it back in, no problem. Right? Oh, and validate the reconstructed record against a DITA File Type Definition (DTD). DITA has an element, menucascade, lets you enter a food selection item > menu item > menus item structure.

For example, select File > Print. A number of the files came back with, "Select Printing on the File menu. " Not so bad. However, many of these were 3-level cascades and they read like spaghetti by the time they were converted. But worst of all, it broke the code.

Another example of interpretive translation took place in the The german language 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 do not work for all of us style-wise. We checked other German translations from other agencies and located that the norm was, 'fenster Bilanzaufstellung. '

These are just some of the examples of contracts you must make before you go too significantly with translations. Here are some suggested actions:

Seek the services of really good proofreaders to examine your translated documents from the original English.
Keep a record of any and all disparities between your expectations and the translated documents. Use this checklist 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.