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:Re: Translations... dogma or realism? From:Max Wyss <prodok -at- prodok -dot- ch> To:Susan Harkus <Susan -dot- Harkus -at- xt3 -dot- com -dot- au> Date:Tue, 3 Oct 2000 02:36:20 +0200
Susan,
believe me, it is not a per se writing off a technology. The results
of so called "general purpose" translation systems ARE SIMPLY NOT YET
SATISFACTORY. Period. There are developments going on, which are
worthwile following, and which certainly will eventually lead to some
results (Xerox Grenoble comes to my mind).
However, I think it could be proven that there is no way current
computer technology will be able to create reliable translations
ever. The reason for this is that there are too many context
dependencies which can not really be fed into the software ... or,
when you are done with feeding those dependencies, you already have
translated your documents.
It is kind of interesting to always hear "the important thing is that
we understand the meaning". Such a comment must come from monoglots.
Because the context dependencies are not easy to bring over, the
"approximate meaning" is the hardest part to transmit. In other
words, it is easier to do a wrong word-by-word translation than to
create an approximate meaning. Keep in mind that is even difficult
for an audience who actually knows what the meaning should be. For an
audience who does not know what it should be, forget it.
Structured English and all those similar efforts do absolutely have
their reason to be. However, don't they mainly affect vocabularies?
If so, they are not really a help for "general purpose" translation
systems, because at vocabulary level, their only limitation is the
size of the database. These efforts do have some other advantages, as
they make it possible for people with very limited English knowledge
(but the knowledge of what it is supposed to read) to understand the
texts. Another thing I wonder about all those efforts is if they
don't just take over the whole writing process in a way that form (in
this case a limited vocabulary) takes control over the contents. If
contents is simple, it works, but what about complex contents? Your
2000 or so words of structured English or so may not be sufficient.
Now, in an environment of an absolute requirement to be exact, "not
causing discomfort to readers" is not good enough. Of course, the
translation process is a Garbage-in-Garbage-out process. With an
experienced translator (particularly supported with a TM system), the
q value (you can define it as "quality in target language divided by
quality in source language") can be better than 1. I am still looking
out for a "general purpose" translation system which gets above 0.5.
Another thing. It might be interesting noticing that the two names
mentioned in the message are from German speaking areas. This is
understandable because German has a different grammar from most other
commonly used languages. German phrases can be longer, more complex
and consist of several parts. This makes it even more difficult to
analyze the meaning of the text (or to synthesize it properly). This
makes German also quite a bit context sensitive (there are languages
which are even worse in that respect, such as Japanese, and it is no
surprise that Japanese computer companies wasted enormous sums of
money in translation software, without a real success).
I mentioned earlier in this message current computer technology. This
has been done on purpose. With current computers (von Neumann
machines) and their model of operation, it is not possible to catch
the contents and associations of language. In order to do that, the
model of operation of the computer needs to be closer to the way the
human brain works. If we get there, chances exist that we get to some
kind of decent machine translation systems.
For technical stuff, such as maintenance manuals or so, this may be a
little bit earlier because the context and the associations can be
limited.
Another (longish) Zweiräppler.
Max Wyss
PRODOK Engineering
Low Paper workflows, Smart documents, PDF forms
CH-8906 Bonstetten, Switzerland
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.