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.
>When the client is a non-language professional, it is our DUTY to inform
>and educate, and to explain that although it may be a "living" language,
>we will not reduce it to total jargon and slang, etc.
>One wonders if all technical writers are language professionals today?
A statement that assumes FAR too much!
Who, I ask, is talking about jargon? The topic of discussion was double-
spacing after a period, not writing rap songs!
Mr. McCann clearly does not face the cross-lingual conflicts that are
daily fare for me in my line of work. He may deal predominantly with
native English speakers for whom the placing of a preposition at the
end of a sentence is no big deal; I WISH that were my worst problem!
Let me give a real-life example: I was writing technical specifications
for a project to be presented to a major telecommunications company.
The person in charge of the project was adamant in insisting that I
write the term "charge details" throughout the specs -- but to treat
it as a singular noun! The request sounded so bizarre to me, so totally
unacceptable, that I tried as best I could to persuade the person to
change the wording to reflect the correct grammar and syntax. No way;
the original document, not written in English, had related to "charge
details" as a singular object, and I was to follow suit, even though
the English would jar the reader into wondering what sort of illiterate
had written the document.
I couldn't live with the incorrect wording, though. Rather than to have
a showdown, because I was still salaried at that time, I turned to the
department manager, explained the problem, and asked him to speak to
the author of the specs to try to reach some sort of agreement. The
department manager certainly had the seniority and the authority to
override the author's wishes; however, even he did not succeed where I
failed. He ultimately reached the conclusion that I had: if the author
was that insistent and would not send the document out otherwise, we
had to leave the incorrect wording as is.
Of course, the customer remarked at the pidgin English sound of the
passages that related to "charge details", but the contract for the
project was signed, the company made a handsome profit, and the only
person who lost sleep was I, and only for that period of time, because
after that incident, I left for a job that paid me almost double the
It's not right to assume that a technical writer is some sort of
prima donna who can crack a whip with every customer, certainly not
in the freelance world. I have never had a customer who forced me to
write jargon; the customers know that I had a publication record as an
author long before I worked in technical writing and, consequently, my
command of written English surpasses theirs by far. However, sometimes
constraints in a job may force a writer into compromises. I recall one
job in which I had to write a one-page insert for a product release. One
particular part of the insert would have been better presented in a
bulleted list, but space constraints made that impossible. I had to
write a sentence that was longer than I liked in the interest of keeping
on one page only. Ultimately, if the customer will not pay for the King's
English, the writer has to comply or go without income.
As far as the "educational" aspect of technical writing, not every
customer can be educated and it can waste time getting the job done
when the customer rejects everything the technical writer aspires to
teach. I remember one particular customer who invented the word
"bleeded" and no matter what I told him, he insisted that I use the word.
It's true that I kept changing it to "bled", but he actually read over
the documentation, and he ultimately won out every time. I didn't stay
in that job any longer than I had to, but while I was there, I was
expected to do as I was told, not to pose as the Education Minister.
If Mr. McCann saw some of the excuses for English that I often see, I
think he'd be at a loss to know how ANYONE could cope with such
startling errors. Have you ever gone to a restaurant to order "meat
faggots", "white acid cherub salad", "curse", "tabular", or "remorse
with additions"? One of the better glitches that I heard was when a
restaurateur insisted upon featuring "ox eggs" on his menu. When a
translator pointed out that the American term was "prairie oysters",
the restaurateur grew pale. "I can't have that on my menu. My
restaurant is kosher; they'll take my license away!" Then there was
the time I went to the Ass Restaurant; now THAT was memorable! What
I'm getting at is that in a non-English society, the battle is often
far more arduous: there is the problem of getting information in a
source language and bringing it into acceptable terminology in a
target language. Even if the engineer speaks in English, if he/she
thinks in another language, what comes out may be unintelligible.
If the technical writer isn't extremely well tuned to all the possible
pitfalls, he/she can easily make extremely embarrassing errors that may
go undetected; remember, the engineer may not realize that the
misinterpretations are just that.
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-