Technical Writing for Translation
A big part of technical translation is technical writing. Or that is to say, good technical translation requires good technical writing. The added challenge for the technical translator, however, is that documents are often written with different stylistic conventions in different languages. Simply recreating the style and formatting of the source document in the translation will generally make for a less effective translation.
Translating technical documents isn't like translating literature. There are no cultural cues to preserve, no great literary techniques to convert. What needs to be preserved is the technical content of the document.
For example, say you've been given the task of translating a bicycle-assembly manual. The user of your translated manual had better be able to follow your instructions, and come up with exactly the same bicycle as a person reading a manual written in the original language. That is the technical translator's primary task.
The technical translator's secondary task is to make the translation as precise and easy to follow as possible. If a user of the original manual can put the bicycle together in 10 minutes, the user of the translation should not have to pore over the manual, scratching his head for an hour to figure the thing out. This means using plain, precise language, appropriate vocabulary, and conventional text and document formatting for the target language.
I should note that this is not the only school of thought on the subject – there are those who think that technical translations should be literal. This is especially true when a translated document will not be used primarily for its technical content, but rather as a legal document (e.g. patents and translations used as evidence in legal disputes). There are also situations in which, for whatever reason, the buyer of the translation prefers a more literal rendering (for instance, if the client wants to verify the content and is not capable of understanding idiomatic writing in the target language).
But I am not writing about these situations here. Here, I am simply assuming that the translation will be used for its technical content, and that producing a precise, readable, and correct target-language document is the first priority.
In this article, I will be writing specifically about Japanese-to-English translation, although a lot of what I have to say should be equally applicable to any language combination.
It practically goes without saying that using technical terms correctly and consistently is of paramount importance for technical translation. At best, failure to use the correct terminology will destroy the credibility of the translation, and by extension, the translator. At worst, it will render the translation useless and possibly leave the translator – or, more likely, his client – open to product-liability lawsuits.
Using the correct terminology requires an understanding of the technical field of the document, for which bilingual dictionaries are but a poor substitute. Even if the word you look up is listed in the dictionary, and one of the translations given is correct, how do you know which definition is correct, if any, unless you know the field?
In a broader sense, the only way to write convincingly in a given technical field is to have read (and preferably written) extensively in that field. The pretenders are quite easy for the expert to pick out.
There are of course many ways to acquire expert knowledge in a given field. Some of the more common ways are a college degree in that field and/or professional experience. But to me, it doesn't really matter where the translator comes by this knowledge, just that he has it. In fact, being a former or current practitioner in the field in question can be a bit of a liability, because the temptation to "improve" on a document becomes quite large in some cases. This can have negative consequences, especially when the translator has not truly understood the source text (see below for more on this).
Another essential skill for producing a good translation is the ability to deeply understand the source text. Of course knowledge of the technical field is important for being able to understand the source text, as is having read extensively in that field in the source language. Another essential ingredient is, of course, good understanding of the source language in general. I have seen translations badly botched by people with impeccable technical qualifications, but who lacked the ability to correctly interpret the source document.
Another mistake technical translators in particular often make is thinking that every word in the original has got to show up in the translation. Here is another reason why knowledge of the field is essential: you need to be able to understand the content of the source document, so you can figure out what the technical terms are, and what can safely be reworded for better understanding.
The most important thing here is to get a style guide, and stick to it. The Chicago Manual of Style is an old standby for American writers, and can be a good choice for its level of detail and general acceptance. Also for American writers, American Heritage Dictionary is probably a good guide to spellings, capitalization, and the like.
But these general references often do not say enough about technical writing, and so should be supplemented with a field-specific guide. As my field is computers, I use Microsoft Manual of Style as a general guide for technical writing. As poor as I find some of Microsoft's product manuals, Microsoft Manual of Style generally has very good guidelines for computer-related technical writing.
Finally, ask your client if they have a style guide. In my experience, nine times out of ten they won't, but if they do you will probably regret not having used it. If something in the client's style guide seems odd or directly contradicts a more generally accepted guide, you might do well to talk it over with your client. When dealing with Japanese clients in particular, such discrepancies often stem from simple ignorance.
When writing in English, you should lay out your document in a manner that is generally accepted in the English-speaking world. Rather than formatting headings with bold, font size, and the like, Japanese writers will often use several different sizes and shapes of bullets, brackets, and the like to denote headings. This stems from the relative lateness of the appearance of word-processing software for Japanese, but the net result is that simply imitating Japanese formatting conventions can leave for a very hard-to-read document.
Another area where Japanese and English practice is generally different is in section numbering. The typical numbering pattern in English documents is something like this:
1. A Major Heading
1.1 A Minor Heading
1.1.1 A Sub Heading
In Japanese documents, however, sections are often signalled using a new numbering sequence, and various levels of indentation. This again stems from the relatively long time it took for word-processing software to catch on in Japan. The same text might be formatted something like this in a Japanese document:
1. A Major Heading
(1) A Minor Heading
① A Sub Heading
Simply copying this formatting into the English translation will make for a much less readable document.
Text formatting is another area where Japanese and English documents often diverge. For instance, in software documentation, Japanese documents usually put UI elements in [brackets] or "quotes," while in English the practice is generally to put them in bold.
Japanese documents often leave inline computer code in an ordinary font (ASCII text generally stands out fine from the Japanese characters on its own), while the usual practice in English documents is to use some computer-like font, such as Courier New.
Here is another case where following the advice of a good style guide for the target language is vital. You won't do your clients or readers any favors by blindly copying the text formatting of the source language.
So what's my point? Glad you asked. My point is simply that a well done translation should also be a good piece of technical writing. Sometimes our source documents are themselves not the best technical writing around, but we do what we can.
What is important is to not get caught up with the trees so much that you miss the forest. Don't just blindly follow the document conventions of the source document: format your translation like readers of the target language expect it to be formatted. Don't just chunk in technical terms because you found them in a dictionary: know what the source is saying and what you are writing.
Writing about rocket science doesn't have to be rocket science. Know your field, get some good guides and stick to them, and format your document appropriately for the target audience. The rest will follow.