I translate a lot of technical documentation, mainly instruction or installation manuals. Translation of such texts requires some knowledge of the topic in question, skill, attention to detail, and most importantly common sense. Yet even the best translators can go from mildly upset to seething with fury when an instruction manual poses problems and difficulties due to its poor structure and editing.
I have decided to share my thoughts about what deficiencies of technical documentation grind my gears and how to avoid them to prepare a document that can be smoothly translated.
Let me start by defining very briefly what technical writing is. Technical writing is preparing a document used in technical fields to communicate specialised topics or to provide instructions about how to do something. Usually, technical documentation, like instruction manuals, is drafted by technical writers. Technical writers are trained and educated to write such texts according to the best practices as the goal is to make technical communication as understandable as possible.
However, I often receive instruction manuals that were not written by professional technical writers but by other staff members, e.g. engineers, managers, foremen, secretaries, mythical interns… it’s hard to say by whom for sure. What can be said, though, is that despite their generally good command of English (or Polish!), their texts are hard to process, incomprehensible, or stylistically bad because the authors were not trained to write such documents in the first place and most likely it was not really their task to do so.
Here’s a list of the features of technical documentation that make translation easier along with related major deficiencies that I find in technical texts.
CONSISTENT TERMINOLOGY
Consistent terminology is the key to clear technical communication. The names of parts, systems, equipment, devices should be the same throughout the whole text to avoid confusion. Sometimes, though, I think the writer wanted to avoid repetitions and used a synonym or similar term, in the belief that it is clear from the context what’s what. If it’s an occasional wrench instead of a spanner, no great harm is done.
However, it is not always easy to be sure “what’s what” as a reader. Many things are obvious for the writer, as they know the topic inside-out, but the readers don’t always have the specialist knowledge to such an extent – that’s why they need technical documentation in the first place. If we find a warning light, emergency light, signalling lamp, and light tower in one document, unless we have a good picture of the whole system with adequate descriptions, it may be difficult to judge from certain contexts whether it’s one and the same object or four different ones.
Translators, even more so than regular readers who are users-to-be, can rarely contact the technical department responsible for the documentation to get further clarification. Usually, the technical documentation is created for a specialised machine manufactured by an obscure company someplace in Europe, which may not even have a working webpage, and the buyer of the machine is the one who wants the text translated. Also, there may be other obstacles such as short deadlines, non-competition agreements, etc.
Why is this consistency so important for translators? Apart from obvious reasons like understandability, consistent terminology makes the operation of Computer Aided Translation software easier. CAT translation memories have better fuzzy matches or even 100% matches this way. For instance:
The current operation of the system is shown on the light tower.
The current operation of the system is shown on the signalling lamp.
are two different segments which are only fuzzy matches instead of 100% matches for a CAT. This prolongs the translation process. Also, consistent terminology allows better use of glossaries in the CAT. All this affects CAT quality assurance tools, and, as a result, the quality of the translated text.
DEFINED ABBREVIATIONS
Sometimes, the writer of the technical documentation uses their in-house lingo full of abbreviations, e.g. DWS CP (distilled water system circulation pump), and assumes they are easily understood just like industry-wide ones, e.g. PCB, SDS, OHS (respectively: printed circuit board, safety data sheet, and occupational health and safety).
Abbreviations as such are useful, but they need to be clearly defined either in the introduction or at their first occurrence. It is often the case that the term in question appears in its unabbreviated form, but there is no clear connection made. Sometimes the abbreviation appears several pages later on in a different context or it is defined in some sentence towards the end of the whole text.
CONSISTENT STYLE
This topic is related to consistent terminology. Consistent phrasing, sentence structure, or even paragraph structure not only read better but also assure the readers that they deal with the same concept or procedure. Again, it sometimes happens that the writer lets their literary creativity loose and makes certain changes in sentences which, in fact, should sound exactly the same. For instance:
Check the oil level before you turn the machine on.
See the oil gauge before you switch on the machine.
These two refer to exactly the same task but they are written differently – and they shouldn’t if they are in the same text. It may happen that the change was introduced in subsequent revisions but it wasn’t applied consistently throughout the whole text, resulting in inconsistency.
Again, it may be confusing – or annoying – for the reader if they need to make sure if it is really the same task or maybe something else. And for the translator, this again puts additional workload, destabilises fluent work in CAT software, and makes quality assurance difficult.
EDITABLE FIGURES
This topic is not always easy to solve. Many extensive instruction manuals include figures representing process flow diagrams with a lot of text in them, charts, or photographs with descriptions right on them. Whenever possible and feasible, it’s best when the text to be translated is already made editable, so it can be read by the CAT software. However, if not possible, it’s a good practice in the case of documents sent as editable files to transcribe the text from such figures into tables below them. This is advantageous for both the client and the translator: the translator doesn’t have to waste time on transcription and additional quotation, and the client knows the date of submission and the final price for the translation right from the start.
SPACE
Sometimes it is crucial that the technical documentation has the same number of pages in all translated languages or that the text fits in the current formatting of the document in question. However, it is difficult to meet this requirement if each page is loaded to the margins with texts in columns and additionally includes tables, charts, and other figures. Let’s remember that on average, a Polish translation is about 10-15% longer than its English original in terms of characters.
Therefore, if it is indeed crucial for the text to remain in the same pages in the translation, the original should have adequate space to accommodate longer versions, like Polish.
WHAT DO I DO?
Although I’m not a trained technical writer (yet?), I pay attention to consistency. Whenever possible and whenever I’m certain of the author’s intention, I use consistent style and consistent terminology in the translation. Sometimes this is unavoidable, as the terminology in the target language is stricter and there are no good synonyms. In the case of undefined abbreviations, I try to do my research online, search through the whole original text, reference materials, and then, if successful, I define them at their first occurrence.
I know that the primary goal of any technical documentation is clarity and understandability for the final recipient. That’s why I do my best to facilitate and fix technical communication even if it breaks down in the original. And if the documentation is a complete mess in some parts – I duly notify the client about any deficiencies.
***
I’ve briefly described the most basic problems that sometimes appear in technical documentation that make translation difficult. There are some minor problems as well and I’m also sure I’ll find some more in future translations, but for now this is enough.
Remember, not all instruction manuals and other types of technical documentation have these deficiencies. If they are written by a qualified technical writer who pays attention to terminology, style, and above all, consistency, the document is just pure pleasure to translate. And, above all, it’s of good quality in its translated version.
If you have any more questions concerning this topic, leave a comment below, or send me an e-mail if you want to have your technical documentation translated: pawel@translatorion.com
Paweł
PS. For other tips on preparing a translator-friendly text read my article on how to prepare a text for translation. If you want to learn about technical translation in general, don’t miss my post Know Your ABC’s in Technical Translation.