Friday, August 15, 2008


Tautology, according to the Visual Thesaurus, is (among other things), "verboseness resulting from excessive repetitions."

For too many technical writers - especially, in my experience, those drafting ERP software manuals, a verbose, leaden and tautological style seems to be the only one they are able to use. Hence such pearls as

"The Server Date information is displayed for informational purposes."

In our translations we can, in such instances, improve on the original. For example, "La Data server è visualizzata a scopo informativo" provides the same information in Italian and is more concise.

Besides omitting redundant words, the translation can be shortened by rearranging the sentence structure:

"You can create a link in the Documents frame to link to a file or a Web page,"

May be translated more concisely and without loss of information as "Nel frame Documenti si può creare un collegamento a un file o a una pagina Web" .


  1. In Japan at least, the manual is usually written in a rush after the product is done, and it's done by the most junior engineer, who didn't have a lot of time in his engineering degree to study expository writing.

    I do try to improve on the original when I can (with the client's blessing). Especially with Japanese , failure to do so would create incredibly redundant English.

  2. I'm not sure that improvements like these are always the purview of the translator; I can see going with "the Server Date is displayed for informational purposes," or even something more succinct, for instance, but I'm worried that "Server Date information" might refer to a _set_ of information rather than just the server date alone. You have to check on those things before you just start hacking away at things, imposing prescriptive stylistic considerations on what might be intentional salience mistaken for redundancy.

    And then, what about the passive construction (is displayed)? English-language writers and editors usually strongly favor using active voice instead? If you start hacking away, where do you draw the line?

    Just a few ideas of things writers have to keep in mind.

  3. Of course such changes are not always for us to make. In this case, however, I had the necessary information to make such decision (for one, I had also translated previously the software this manual is describing).

  4. I guess it down to a difference of perspective. Programmer usually think in terms of what a software does, while users (and thus translators) to what the software achieves.

    To make an example from my area, where the programmer sees "a collectible offensive object" we see a plain "weapon".

    The first is an element in a hierarchy of software classes, the latter stabs the enemy. I guess players have no doubt about which one they prefer to use ;)

    Personally, I file this under "adapting to the targert audience" and amend almost by default.


Thank you for your comment!

Unfortunately, comment spam has grown to the point that all comments need to be moderated. All legitimate comments will be published as soon as possible.