Tweaking English in manuals and localisation?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Jennifer O'Neill reports <<We localise into up to 20 languages and one of my
tasks to check that manuals are suitable for localisation... the procedure
we're trying to put in place is to freeze the English once the manual has
been translated. In subsequent updates ideally only changes to the technical
content are made. These changes are marked in the manual so that everyone
can immediately see what's changed. In-country reviewers can then simply
check the translation of the marked text and not have to read the whole
manual>>

Sounds eminently sensible. I'm fortunate in only localizing into 2 languages
(English and French), but I use this approach profitably in my own context,
and it must be a lifesaver in yours.

<<This has meant that if the English was not written elegantly (for lack of
a better word) for the first translation, then the English remains inelegant
for subsequent updates unless it is causing a comprehension problem.>>

That's also a sensible approach. If your translators are any good, they
should be creating elegant translated text irrespective of how good or bad
the English original is. And if you use your translators for quality control
("we had a helluva time translating the manual; the English sucks"), this is
a great way to identify the texts that require the most urgent work at your
end.

<<Here's the problem. Tweaking and rewritting of the English in manuals with
each update... Aside from the cost consequences, the most serious problem
for me is that in-country reviewers often refuse to review these rewritten
docs as for them the info is the same, it's just written differently. As far
as they are concerned they're wasting their time doing a review.>>

I tend to agree with them. The problem that you're really facing is how to
distinguish between changes that affect the meaning or content, versus
changes that just make it easier for English readers to understand the
existing content. Your translators and reviewers shouldn't have to waste
their time on the latter; the former is the important stuff.

<<I recently was nearing the final stages of releasing a manual in 12
languages... The English was a bit clunky but comprehensible... I just
tidied up the English a bit and sent it for translation.>>

This is a case where you should carefully consider whether "comprehensible"
is acceptable. It's not always true that changing clunky into "elegant" by
good editing will pay for itself, but there are clear advantages to giving
translators the best source document you can produce: their work goes
faster, and the risk of errors decreases. I'd bet you could find a grad
student somewhere (someone looking for a thesis topic) willing to work with
you to quantify the merits of this approach, though that's not necessary if
you're willing to accept your own estimates of the costs and benefits.

<<There were some technical changes but the manual has been completely
rewritten by a tech writer. The English is better than in
the original doc but when I showed it the tech support guys (2 anglophones
and 1 francophone who works in English) to get their opinion,  they all
prefered the more clunky original doc as they said it got straight to the
point. The clunky English was no problem. So I just integrated the few
technical changes into the first version and releasd that.>>

That's a reasonable solution, but inefficient and perhaps suboptimal. The
inefficient part is obvious; the tech writer's time was wasted, not to
mention your own time comparing the two versions. The suboptimal part is
that your tech support guys have a far more intimate knowledge of the
product than the actual audience, and that can make them poorly suited to
judging the quality of the language. That's not to say that they didn't do a
good job, but you need to confirm that this is the case rather than just
assuming they're representative of your audience.

Case in point: One of our researchers just defended his thesis in roads
engineering, and came back to produce reports chock full of jargon from his
academic field. We had some pretty good discussions before we convinced him
that his target audience had changed and didn't know any of the buzzwords he
was using--appropriate though these were to the academic audience for his
thesis.

<<So where do you draw the line when you want to freeze the language in a
manual and just have technical changes done when updating? How tolerant
should one be of inelegant English? How do you persuade tech writers to
consentrate on what must change (eg, techncial content) and not fiddle with
what can change (eg, language) when updating a manual?>>

Not a question that we can answer, since these aren't questions with simple
answers that are universally applicable. You'll have to talk to your
translators to find out whether the English is suitable as it stands, what
styles of writing are causing them problems, and thus, what things you need
to target in updating your process. You also need to talk to your English
audience to confirm whether your tech. support reviewers are correct, or
whether your tech. writer did a better job and should be congratulated. That
feedback will also tell you what guidance to provide to the tech
writers--and the reviewers.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada

"Writing, in a way, is listening to the others' language and reading with
the others' eyes."--Trinh T. Minh-Ha, "Woman native other"

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.