Translating Technical Documentation Without Losing Quality

Technical translation is a wide-ranging field, and most professional translators have had to deal with a technical document at some point in their careers, be it a set of instructions to install a piece of equipment, a long manual for a new procedure or a “simple” PowerPoint presentation scrutinizing some obscure aspect of a company.

While other types of translations aim to inform or convince the readers, technical translation is most often used to direct them through an activity. As such, clearness and simplicity outweigh style considerations or the gradual presentation of a concept. As the author states in his introduction: “If you mess up in your translation what technical writers have carefully worked out for the original document, you won’t make them happy.”

Translating Technical Documentation Without Losing Quality by Marc Achtelig (indoition publishing, 2012) seeks to help translators of technical documents by presenting all the essential rules good technical writers follow that are specifically relevant to translators. Achtelig does not offer any advice regarding content creation, advice that you might find in a book aimed at technical writers, because translators are rarely involved in that step of the process.

Appropriately enough, the book presents content in a very methodical and logical manner. Each topic begins on a new page and is numbered hierarchically based on the section and chapter. Articles are conveniently hyperlinked to other related content in the book, which is a boon for readers of the electronic format. Readers of the hard copy version might find these hyperlinks to be pale and thus difficult to read. Each article usually begins with boxed text detailing the rule to be followed. This is followed by a series of examples clearly rated NO, YES and TOP (this last one being the best practice), with explanations and commentary when necessary.

The book is divided into two parts of approximately 100 pages each. The first part contains advice regarding technical writing in general, and sentences and words in particular. The tips covered in this section are very relevant to all professionals who deal with language and include: keep it simple; be concise; use the present tense; use the active voice; use and with care; use common words; avoid abbreviations and acronyms; avoid stacks of modifiers; and avoid gerunds that conceal a direct verb.

An example of the last infraction would be “Before being able to use the program, logging in is required,” which could be more clearly stated as “Before you can use the program, you must log in.” Gerunds that refer to potential actions are acceptable, however (“Dropping the server may damage it”).

The section concludes with two extensive “blacklists”: overblown words (overly complex words or phrases that can be replaced by simpler choices, such as go to instead of navigate to), and filler words (vague words that should be avoided, such as actually and perfectly).

The second part is a compilation of approximately 120 issues involving very specific words that are often improperly used interchangeably in technical documents. In each case, the article provides clear directives as to which terms should be selected, as well as a list of near synonyms to avoid. These articles are organized in two large categories: general terminology and computer terminology. Some of the words addressed in the first category are:





The computer terminology section, on the other hand, includes synonyms such as:



menu/submenu/drop-down menu/pull-down menu

Internet/internet/world wide web

It is evident that the author aimed to produce a practical tool with his text, and that great care was taken to organize and structure the contents of the book in order to facilitate its day-to-day use. The final result — especially the e-book version — achieves this goal with near perfection.

However, it is equally evident that the author worked from two unspoken assumptions that limit the number of translators who might benefit from this work. First, the book assumes that the source document has been carefully created by a professional in accordance with the fundamental principles of technical writing: clarity, concision, simplicity and active voice. In my experience, those types of documents represent a very small minority of source files sent to translators. More commonly, technical source files are created by subject-matter experts who have little to no experience writing for an audience outside their specialty. Their texts are filled with insider jargon and acronyms, vague word choices, confusing structures and so on. In short, they break all the rules that appear in the first half of this book. The addition of a chapter addressing this frequent problem and providing some solutions — or at least some advice on how to deal with this common situation — would have made this book a valuable resource for any translator working with technical documents.

The second assumption is that the translator is working into English. In particular, most of the issues that make up the second half of the book only apply in English. For instance, the subtle distinctions between can, could, may, might, does and will won’t generally be found outside Indo-European languages. Even languages that are very close to English, such as French, won’t have an issue with separating data from information and assistant from wizard, and only an anglophone will ever wonder if you can pluralize an acronym by adding an apostrophe and an s after it. Translators working in other language combinations can still make use of the first half, since the principles it contains apply generally to all languages. The author does demonstrate some awareness of the book’s anglocentricity by occasionally mentioning when rules are English-specific (such as strings of nouns and modifiers stacked together), but these notes appear inconsistently. To be fair, it would be impossible to create a truly universal book that could be equally useful across all languages. Given the care with which this work was written, however, it does seem strange that the author neglected to mention this fundamental assumption on the book jacket or introduction.

In the final analysis, this book will be most useful for translators and editors working into English from source documents created by a professional writing team. If only one of those categories applies to you, Translating Technical Documentation Without Losing Quality might still be of interest to you for some of your work. Otherwise, I would seek out more general guides to help you tackle your next technical document.