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.
Just joined the list on the recommendation of a friend, because I
translate a lot of technical stuff and thus feel like a tech
writer--except that I'm not working with engineers but with tech writers
in another language.
So imagine my delight when I stumbled upon Geoff Hart's suggestions re:
writing for translators almost immediately upon subscribing! I think a lot
of what he says makes sense; otoh, some of it seems a bit patronizing:
> > - Start with a well-edited English version: remember,
> > garbage in, garbage out. If the text says Figure 1, and it
> > should say Figure 11, don't expect the translator to catch
> > this.
Yes please. And then, when the translator calls you pointing this stuff
out, don't say "go away and stop bugging me with minor details." All
translators complain about tech writers' lack of interest in nuances,
ambiguities, complexities. Our technical source texts often make little or
no sense; are misleading; are uneconomical and awkward; and when we call
the client to talk to the writer, we typically get complete indifference.
The attitude seems to be: "I wrote that weeks ago and am completely
absorbed in this new project and can't be bothered thinking about such
ancient history, go figure it out on your own."
I'm sure tech writers are always working under enormous deadline
pressures. But so are translators. And our impression often is that tech
writers are given, say, several weeks to write something that we are
expected to translate in two days. Your bosses, or whoever sends your work
out to be translated, seem to think that translation is much easier
and much faster than original writing. (Either that or they just forget to
budget adequate time for translation at the end of a project.)
> > - Implement some process for alerting the translator to
> > last-minute changes in the English version. We all know how
> > annoying it is when engineers forget to keep us up to date,
> > so we can empathize with the translator, right?
Nice of you to think of us! This is indeed important.
> > - Implement some form of controlled vocabulary: either
> > create a list of standard terminology, and stick to it, or
> > edit ruthlessly to eliminate synonyms. One word = one
> > meaning, and no synonyms for single concepts.
> > - Avoid qualifying phrases, particularly adjectives: how
> > "very" is "very" to someone who speaks another language
> > with different attitudes towards adjectives?
Here I'm starting to worry. What, we can't figure out nuances across
language boundaries? You've got to pare your language down to the most
boring level possible so that we don't screw it up?
When this would be most useful for us is when we're working in an area
that we don't understand very well--which is unfortunately quite often,
especially in languages of lesser diffusion (I work between Finnish and
English and can't afford to specialize). But even then we get expert help,
check earlier samples of similar writing (and in fact whenever you can
send a translator such samples, do it--it really helps)--and have our work
checked.
> > - Use punctuation correctly, but don't rely on fine
> > distinctions in punctuation to communicate specific
> > meanings. Information can be complex, but the manner in
> > which you express it should never be.
Well, the main thing here is whether your "fine-distinction" punctuation
system is public or private. If it's one that everybody who knows the
language can be expected to know, carry as much meaning as you want with
as fine a distinction as you want. Just don't make stuff up and expect us
to read your minds.
> > - Ruthlessly eliminate culturally specific phrases (e.g.,
> > most similes or metaphors, idiom, sports or military
> > analogies, religious references, literary allusions). These
> > can be offensive, misleading, or simply incomprehensible.
Oh, please, NO! This sort of phrase can often be the only spark of life in
a technical text! And your suggestion seems to imply that we're too stupid
to figure out what those phrases mean, or too incompetent as translators
to figure out an equivalent in the target language. Give us a collective
break here.
> > - Create a list of changes that must occur as a result of
> > localisation issues. For example, if the Middle East
> > version writes text from right to left, warn the translator
> > that "text wraps at the right margin" and its kin are no
> > longer valid. This is particularly important if it's a
> > blind translation, in which the translator doesn't have
> > your product to work with during the translation. Actually,
> > why tolerate blind translations in the first place?
The warning is a good idea. I don't know about those blind translations,
though. I mean, I'd love to get a free computer or piece of software or
car stereo every time I translated documentation on them; but what about
diesel engines? Architecture specs? Paper mills? UPS doesn't usually like
to ship whole factories to translators so they will be freed of the
necessity of translating without the product in hand. I think what may be
happening here is that Geoff typically works with hand-sized widgets; but
of course lots of technical writing deals with rather larger products.
> > - Understand enough about your new audience and perhaps its
> > language that you can watch for some of these "gotchas".
> > You don't have to be bilingual, but it helps. (In French,
> > there are plenty of words known as "faux amis" that exist
> > identically in English and French, yet have different
> > meanings in each language. Knowing this, you can avoid some
> > of these terms or warn the translator.
Gee, thanks. We are, after all, idiots.
Well, let me back off that a little: sometimes technical documentation is
translated by people who have no business doing the work. They have a
little school knowledge of the target language, maybe spent three weeks
there once on holiday or for a language course, and so the boss asks them
to translate things into that language for public release. For this sort
of translator, yes, you do have to spell everything out. But you should
never USE this sort of translator. If you go through a translation agency,
you can expect to work only with professionals who don't need this kind of
hand-holding, and certainly would not appreciate being thought of as the
kind of dolts who do.
> > Interestingly enough, most of these suggestions apply
> > equally well to writing good English. Quel concept!
Except for the ones about paring your language down to the barest bones of
clarity. That may be an ideal for writing good *technical* English, but
let's not generalize that too far!
