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:To localize... or not? (Was: Dropping the you?) From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Janice Gelb <janice -dot- gelb -at- sun -dot- com> Date:Sat, 24 Jun 2006 09:24:59 -0400
Janice Gelb noted: <<... our style guide doesn't allow first-person
plural and we also suggest that writers don't "recommend" and that they
just tell the reader what to do.>>
FYI for those who don't know her: Janice is co-author of "Read me
first!", which she co-developed while working at Sun. It's a highly
credible alternative to Microsoft's guide (I believe it won an STC
award too), even if you primarily write in a Microsoft environment.
Being an editor, I don't agree with everything in it (the world will
almost certainly end when all editors agree <g>), but I like it much
better than Microsoft's advice.
As Janice notes, the word "recommend" is generally redundant if you're
writing in the imperative voice. If you tell someone to do something,
it's clear that this instruction is your recommendation, so there's no
need to emphasize the point. Delete the word, shorten the writing, get
to the point. There are cases when it's necessary to add the word back
in for emphasis, but those cases must be the exception: like seasoning
food, adding too much of any one spice dulls the palate and conceals
the other (often more important) flavors.
<<On the greater question, while I agree that cultural sensibilities
should be taken into account, and our style guide has plenty of
recommendations on the subject, I don't think that sensitivity should
extend to making the English more convoluted than necessary for
Europeans.>>
As several of the examples in this thread have shown, it's easy to
write clearly in a way that all audiences will understand. One way to
look at this requires us to take a step back and think about writing in
a slightly different way than we might have been doing. Think about
writing as having two components: the words that convey the meaning,
and the words that flavor that meaning (i.e., account for a cultural
context). Simplistically, this could be described as "what you say and
how you say it". In that context:
<<Correcting writing that is difficult to understand for non-native
speakers is one thing, as that benefits all readers.>>
That's the "what you say" part. One of the cool things about trying to
boil down writing to make it as concise as possible (but no more
concise!*) is that the exercise helps you focus in on which words are
really important.
<<Changing writing that might not use an approach comfortable for
absolutely every reader is to me another issue entirely. I don't think
that possible Asian discomfort with the use of "you" as too informal
should necessarily outweigh a desire to make technical writing more
approachable for non-Asian readers unless that is the primary
audience.>>
This comes down to whether it's possible to localize or not. As I noted
previously, many Asian readers will simply accomodate our different
English rhetorical style without any fuss or bother. They might prefer
a different style, but if the information is important and meaningful,
they'll cope. It works the other way too. I, for example, don't expect
China to adapt Mandarin to follow English syntax so that learning
Chinese syntax would be easier for me. (Unfortunately, it's also why my
aging brain makes earning so much slower, but that's life.) I do expect
my Chinese colleagues to write clearly.
Many companies take the perspective that it's simply not practically or
economically feasible to make the effort to customize their writing for
different audiences. Yet if you take a step back and consider the
difference between "what you say and how you say it", this perspective
becomes a bit more difficult to support. The hard part about technical
editing, and the most time-consuming part in my experience, is the
technical part: getting the facts right, and ensuring that the "what
you say" is correct and clear. This is why we have intensive peer
reviews.
The easier part is the mechanics of copyediting, the "how you say it"
part. (Yes, I'm oversimplifying... I'm trying to make a point, not to
state a law of the universe of words.) This suggests that the burden of
localization may be easier than we sometimes think: get the "what you
say" right in the first version (the technical edit), then hire a local
editor to polish the "how you say it" part. A good editor (they do
exist) can be taught how to distinguish between the "what" and the
"how", and work much faster by touching only the how.
How might this work? If you think a bit about writing to prepare for
localization, there are a range of strategies, up to and including the
use of AECMA simplified English
(http://www.simplifiedenglish-aecma.org/). But even in the simplest of
these strategies, imposing a measure of consistency on how you write
makes the job easier. Sometimes the changes become purely mechanical
and easy to automate with a Word macro; for a trivial example, phrases
such as "you should [imperative verb]" can be automatically replaced
with "[imperative verb]" by the local editor if the local style is to
use imperative voice.
Real-world examples become more complex, of course, but the philosophy
doesn't. Something to ponder!
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
