TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Translations... dogma or realism? From:Susan Harkus <Susan -dot- Harkus -at- xt3 -dot- com -dot- au> To:"TECHWR-L (E-mail)" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 3 Oct 2000 08:51:16 +1100
I read the comments by Max Wyss and Bernd Hutschenreuther in relation to the output from translation software. They are stock standard comments that come up regularly. However, it is disappointing to see people writing off a technology that has much to offer. More importantly, it is sad to see dogmatic statements that might deter others from leveraging from the technology.
The key to acceptable draft output from translation software is the quality of the input, as well as the functionality of the software. By quality of input I mean well-structured prose using terms/vocabulary consistently. As for idiomatic language, in most cases, the software's custom dictionary will address the issue.
Structured English and controlled English came along early in the translation software cycle, when the software engineers realised that their tools produced nonsense when applied to undisciplined writing. But structured English and the like impose constraints that most technical communicators reject outright. I do too.
However, technical writing has moved on since the birth of translation software and the industry's drive to produce READABLE documents that COMMUNICATE their messages clearly, has increased the quality of source for translation. Earlier in the year, I proved to myself and respected colleagues that the good writing guidelines that most tech communicators accept, combined with some techniques driven by translation software, result in documents that communicate their message clearly and comfortably to source language readers, as well as documents that produce an acceptable translation draft when submitted to translation software. There is no doubt that you need a human translator to do a post-translation edit but even with a post-translation edit, you can reduce the translation effort by half.
There was an excellent article on the Softissimo site earlier in the year (alas, now pulled) comparing the effort required for the human translation of the Lewinsky-Clinton report with the effort required using a combination of Reverso (their translation software) and a human translator. Their conclusion was that text that lacked some of the subtleties of expression of "natural" language did not cause discomfort for readers.
In posting this, I don't seek to change the minds of Max or Bernd or to spoil their collection of translation anecdotes, but I do urge anyone who faces localisation challenges to consider improving the quality of source text so that their company can take advantage of translation software when they produce the initial target language version.
Once a translation is in place, translation memory software is certainly the way to go and the language version needs to be moved to a translation memory.