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.
John Garison is <<... heading the task force within the development group to
identify the issues we'll have to face. It's more the big picture items I'm
grappling with... What is the best order in which to approach things?>>
Start by identifying local contractors or agencies who will become your
partners in doing the translations plus localisations; this may take a
while. An ideal partner will have considerable experience in localisation
for the markets you're targeting, will have reasonable or even exepert
knowledge of your specific field, and will work easily with you (the human
aspects are important in translation). You can probably get good
recommendations here on techwr-l to help you start your search. The good
localisers can almost certainly walk you through more of the planning
process and in more depth than techwr-l can given the limited time we
'whirlers have to respond to your questions. I believe it was STC member
Nancy Hoft who recently produced a well-received textbook on localisation;
have a look at Amazon.com for details. Second, you'll have to start
considering localisation issues for your code, as you've noted below. One of
the biggies is that English is a surprisingly concise language compared to
many other languages, and you should plan to leave room for up to twice the
text length in text strings and so on.
<<What are the best techniques for extracting text strings from the program
logic?>>
This has been discussed every so often on techwr-l (including about 2 weeks
ago), so have a look at the archives. The approach I'm familiar with is
including all the text in a separate resource file that the programmers
merge into the main code during compilation. There may be more sophisticated
approaches to doing this, but I've found this works very well for me: I set
the English and French printouts side by side and compare the numbered text
strings to be sure they say the same thing. I've also worked from
hand-annotated screenshots, but that's likely to become unmanageable for
really large projects.
One thing that's key: if your developers can't be persuaded to freeze the
interface very early in the project, you're asking for trouble both in terms
of cost, delays, and errors; skilled technical translators can charge
upwards of $0.20/word (at the low end), and every word you change can have
ripple effects, so you can see how these problems can easily snowball.
Another thing is that you should invest heavily in editing to produce
concise, clear, effective prose to begin with; even the best translator will
choke on poorly edited, vague, misleading text, and if the text is
constantly changing you're in bad trouble.
<<What is reasonable to assume for the time it will take?>>
No idea. It depends on your specific field, whether your partner has a
translation memory system that works in that field, what services they
provide in addition to straight translation (e.g., testing the translation
with native speakers), and so on. Crude example: When I'm really flying and
working with a well-written document (often one that I've already edited in
French and thus already understand), I can translate the forestry documents
I work with nearly as fast as I can read and type (in rare cases reaching 80
wpm); that's including the homegrown translation memory I've developed, but
excluding a second pass through my work (self-editing) and our internal
review process. That's an atypically high rate, though; I don't usually
reach that level of productivity, and I'm much, much slower with unfamiliar
material or stuff that was written poorly in the first place.
<<Are there guidelines for translation costs - per word, I assume. Are they
different for documentation than for code?>>
As I noted, I've seen very cheap rates quoted for translation, particularly
for literary translation (where the budgets are nearly nonexistent), but
really good technical translators usually start at about $0.20/word. If your
particular product requires rare or highly technical expertise, expect to
pay considerably more. Most translators (including me) work at a fixed rate
per word for any field in which they're competent to do translations; rates
may vary upwards if considerable research is required to pick the right
terms or if they know you have nowhere else to go and have to pay whatever
they ask. <g> (One of our translators works for an hourly rate and actually
ends up saving us money because of her speed and quality.) Be careful to
specify what's included in this rate; sometimes (particularly for
freelancers), all you get is a translation; sometimes you get editing and
additional testing or validation for a higher price, and end up saving money
because you're getting much more than just the words.
<<What techniques can we adapt to test the results?>>
You're likely to have a local sales office at some point, or at least a
partner in distribution, and they may be a good source of advice on how to
do an audience analysis and usability survey with local users. I'd highly
recommend something like this, because even the best translators I've worked
with occasionally miss important nuances that the audience would pick up.
<<What's the best time to bring in a consultant - or should we just work
with whoever we pick as a translation vendor? When's the best time to think
about a vendor?>>
Find and start working with a partner right from the start: "plan twice, cut
once", as the saying goes. You may not actually pay them a weekly rate from
today until you actually start the translations, but you do need them to
help you with the initial planning. Once you've got a clear understanding of
what you must do and how, you can begin working independantly, without
paying them anything until you once again consult them or actually start
delivering materials for translation. You may instead decide that you need
someone constantly holding your hand throughout the process; the peace of
mind and early detection of problems may amply repay this investment if this
is the first time you're doing localisation. Moreover, problems you solve
early on are problems you can fix once and not have to solve repeatedly
throughout the rest of the process.
--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
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words;
on occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary."-- James D. Nicoll
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
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.
