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.
Steve Shepard reports: <<We have developed a version of our core software
for use in Europe. The project manager says we are not going to have the
localize, but I am sure he is in denial. It's going to have to happen if we
are serious about the European market.>>
Oddly enough, you're both right. If your product is essential and has no
real competitors, you don't have to localize any more than you have to
create a usable product in the first place: those who need it will simply
grit their teeth and cope. After all, pirated English versions of most
commercial software are easily available and heavily used in many economies
without translation (China was recently cited by--if I'm remembering
correctly--The Globe and Mail as a bad example of this practice, but they're
by no means unique). But if you're likely to have competitors, and want to
produce something highly usable that won't have customers constantly calling
your support line with annoying questions that could have been prevented by
a good translator/localizer ("when you use the verb 'table' in the
documentation, do you mean in the American or British sense?"), then you
need to localize the documentation. It's a messy business, but one that's
best planned for _now_ before you get going so that you have a firm position
to build on in future.
<<Of course, this means I have the task of researching what it's going to
take to localize our docs.>>
techwr-l and our archives are a great place to start; many of us deal with
such issues, and have discussed them at length here. Nancy Hoft's book
provides a good primer on the subject.
<<Any other suggestions, hints, tips, warnings, cautions, or pointers in the
right direction would be helpful.>>
Very few translators, even experts, can work anywhere near as fluently in
their second language as in their first; this means that you need someone
local (in the country where the documentation will be used) who's highly
competent in your version of English (U.S.) but truly expert in the local
language. Don't accept an American translator's word that they understand
the other culture well enough to do the job right without some compelling
proof; you can find such people, but the longer they've spent away from the
foreign country, the harder it is for them to keep current with usage
trends. One thing you'll definitely have to plan for is what to do about
onscreen text; labels in English can easily expand by up to 50% when
translated into languages such as French and German, and your programmers
must design a user interface that supports these longer labels. (Ditto for
the printed documentation templates.) Last but not least, edit your original
English source materials rigorously so that they're the best they can be,
and as concise as possible; cutting words without compromising clarity can
greatly reduce translation costs, both because there are fewer words to
translate and less likelihood of mistranslations. In fact, I've never run
the numbers, but since technical translation costs significantly more than
technical editing in my experience, I'd bet that paying a skilled editor
will actually more than repay your editing costs.
<<I am particularly interested in anything that would help me estimate the
cost of translation.>>
Translation is almost universally billed "per word", but practice varies
about whether this is per word of source material or translated material
(the former is more common in North America; the latter is common in some
parts of Europe, I'm told). Rates vary widely; literary translations (here
in Quebec) can easily begin lower than C$0.10 per word of source language
and run well over C$0.25 per word for technical translations, particularly
if few people are expert in the field (e.g., I can charge a really good rate
in forestry, because there are few skilled forestry translators). Make sure
the costing basis is clearly spelled out in advance. There may be additional
costs if special research is required, though an expert translator in your
field shouldn't generally have to do this research--they should generally
already know the terminology. To this cost, you should ideally also include
costs for editing (quality assurance of some sort) and testing the material
with local audiences; both services may be provided by larger or more
experienced contractors as part of their per-word price, but that's not
guaranteed, and if it's not part of the package, you need to provide this
work somehow.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"When ideas fail, words come in very handy."--Goethe
Sponsored by eHelp Corporation, makers of RoboHelp - the industry standard
in Help authoring. Download a trial version today or get special savings when
you buy the RoboHelp 2002 Holiday Edition. Visit 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.
