Technical writers can help a localization project significantly by following a set of guidelines in the pre-production phase of localization – that is, when the source files are generated at the “home location.”
Here are my suggestions as to what to include and not to include in these guidelines.
1) Writing Guidelines
a) Exclude all culturally-specific idioms, conventions and expressions since they are hard or impossible translate to another language.
For example, “here are the facts straight from the horse’s mouth” is an American expression that cannot be translated easily to most other languages. Thus it should not be used in a pre-production technical source document.
b) Include the open written forms of all abbreviations and acronyms the first time they are used. And the rule here is: the less, the better.
When one must use them, immediate disclosure is a must to prevent any misunderstandings.
Example: The North Atlantic Treaty Organization has NATO for acronym in English but OTAN (Organización del Tratado del Atlántico Norte) in Spanish.
c) Include a Glossary which should define all the technical terms and concepts used in the source document.
If it is not made very clear that “resistor” refers to the electronic circuit component, it may become “a protester who resists government oppression” when translated.
(Don’t forget the Murphy’s Law: whatever can happen, will happen.)
d) Include a Unit and Measurement Conversion Chart.
(Public domain image courtesy of Wikipedia)
In the absence of such a chart, a “1 million dollar home” can be mistranslated as a “1 million rupee home” which is 47 times less than what it should sound like within the Indian context.
e) Include a list of terms and concepts that should NOT be translated and used as-is since they may sound awkward in the local language when translated.
For example, a “transistor,” “frequency modulation” or “arbitrage” are concepts that should perhaps be left alone just as they are used in the source document.
The project management should develop that Don’t-Translate list in consultation with the technical writing team for a faster and better localization process.
2) Image Guidelines
There are also important image and font considerations that you need to take into account as a technical writer for a problem-free and affordable localization process.
(SIDE BAR: Let’s immediately open a small sidebar here and stress the importance of graphics knowledge and skills in technical writing since formatting the information takes as much time of a typical technical writer as expressing it in a straight forward manner.)
RULE #1: Do not embed your image text inside your image.
One thing you should not do is to save any text that needs localization together with your original image files.
If for example you are using Adobe Illustrator to generate your vector and EPS (Encapsulated Post Script) images, do not use the Text tool to add your captions or callouts directly onto the image itself. If you do that, the same image will need to be manipulated for a second time at the local end in order to translate the text part.
RULE #2: Do not rasterize your text, and do not convert it into a Bezier outline.
It will be especially troublesome if the text is either rasterized (as in Photoshop) or transformed into outlines and Bezier curves (as in Illustrator) since that creates non-editable text. Your text then turns into a true image, a picture. After that, it can only be changed through time-consuming image alteration methods.
Instead, first import the image into your the page composition program and then add the text inside the page composition program itself.
Whether you are using MS Word, FrameMaker, QuarkExpress, or InDesign, you can always add a text box to any imported image. Add all your captions or legends that way.
Localizing the editable content of such a text box is much easier and less costly than manipulating the image source file itself.
Localize to globalize; but do it the smart way as described above.