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.
> -----Original Message-----
> From: bounce-techwr-l-58477 -at- lists -dot- raycomm -dot- com
> [mailto:bounce-techwr-l-58477 -at- lists -dot- raycomm -dot- com]On Behalf Of Balchunas,
> Sent: Monday, January 08, 2001 8:34 AM
> To: TECHWR-L
> Subject: Translation of Op. Manuals
> I am a technical writer for a large medical device manufacturer and could
> use a little advice regarding how to effectively manage the translation of
> operator manuals.
> We currently translate our package inserts, but we will shortly begin
> translating operator manuals in order to meet requirements issued
> by the EU.
> Who is typically responsible for translation of software?
You're going to need to assign at least one person to act as translation
coordinator. This person puts all of the files together, sends them out to
the translation agency, resolves issues as they arise, and receives the
finished products back to do something with it.
Seeing how the bulk of the translation comes from documentation, the
recommendation is to assign a tech writer (even a junior tech writer) to
this task. They don't need to have extensive product knowledge; they just
need to be well organized and adept at working with others to resolve
It is highly recommended that the translation coordinator be sent to
training on translation tools (such as TRADOS, if that's what tool you
decide on), because there is much that this person can do without even
knowing the target languages. Yes, this investment is an expense for the
first release, but will save you BIG TIME in subsequent releases.
You are going to need buy-off from development in terms of them assigning
you at least one engineer part-time for the task. Why? Because the messages
are buried in the code files (e.g., resource files) and only engineering
knows where they truly are. Moreover, once the resource files come back from
translation, this person has to compile them into the system and get it
working. In some cases such as oriental languages, you're going to need
operating systems in those languages to verify proper operation.
Having a tech writer as the lead contact person to the translation agency is
helpful and recommended. However, there is no getting around engineering
> How is the review of translated text handled?
You need to get a promise from your sales representatives or application
engineers in those countries. There is no getting around native speakers
with the subject matter expertise to review the translation. Getting their
buy-off for devoting some time to the review shouldn't be a problem; after
all they were probably the ones "beachin' n moanin'" for the translation in
the first place.
However, the translation coordinator is going to have to lay down some
ground rules, such as "the reviewers are only to change things that are
outright wrong." If it is worded differently than what they would say but is
still correct (e.g., a preferential changes), they should refrain
themselves. It takes them time and costs you to get such changes to the
agency and incorporated back in.
> How much faith should you put
> in the translation agency to effectively translate your software and text?
If you give them realistic schedules, you can expect an average translation.
But don't expect it to be stellar until you have somehow gotten the time
commitment from an in-country reviewer.
The translation agencies (and their translation memory software) are good at
learning. You are going to take a significant hit in the first release just
getting the terminology correct. However, once it is in memory and you have
worked out the kinks, subsequent releases will be pieces of cake.
> One agency we've spoken with will send translated text to the
> representatives of our company in the respective countries for review and
> then incorporate changes.
Do it. However, I cannot emphasize enough having the in-country reviewers
buy-off to the time commitment in advance. Most representatives in those
countries are sales people or application engineers, both of whom have
priorities set for making sales and helping existing customers. They are not
technical writers and won't be prepared for this workload (once a release)
if sprung on them.
> I'd appreciate any input or resources from people with experience handling
In other advice, you need to get your source text as clean as possible
BEFORE you send it off. This includes directory structure organization. If
you have major changes planned for the documentation, do this first. It will
be harder to do later even in the source language.
You also need to think about graphics; who is going to edit the images with
the new (translated) terms. This is another (time consuming) job for the
translation coordinator and may require dual-boot systems to get some
screen-shots. You need to get your translation memory system (e.g., TRADOS)
in place beforehand.
I just got back from a 14 month stint in Austria. They sent the source
English text off to be translated into 6 languages before I had a chance to
review it, which resulted in shitty translations. Garbage in, garbage out.
They also didn't have it organized in terms of a directory structure, book
structure, help structure, and file location. (Documentation files were
buried in the source code directories.) They were using MS Visual SourceSafe
and a feature known as file sharing. It wasn't so bad if you were in their
network and always fetched the latest and greatest. The problem was that
when you checked out the projects onto your hard-disk (to burn a CD-ROM to
send to translation), you ended up with copies of the same files. BAD NEWS
I spent a lot of time fixing things that should have been organized from the
beginning. I reduced the file count from well over 3000 files to just over
1200. Most of them were image files that were shared and re-used. THIS WAS A
MAJOR PROBLEM when it came to translation. It is one thing when I have to
tweak images in a language that I don't even speak, but it entirely another
to tweak the same image over and over because it was shared and I didn't
know it. I implemented more effective use of the WinHelp project files and
flatter directories structures.
Development needs to be involved from the beginning, because they might have
to structure their code differently to more effectively allow translation.
As was already mentioned, they're the ones who will have to re-compile and
test the software once it is back in house.
Other advice I can impart. Do all in your power to push back foreign
language releases (at least for the first one). You will have enough to do
just getting English software running and documented without compounding
everyone's workload with translation issues in the same release.
>From my experience, translating the manuals and online help wasn't the
problem. In fact, subsequent releases went extra smoothly due to the
translation memory system and better organization; we made (some of) the
language releases at the same time we make English.
The SNAFUs were:
- Tweaking the images from online help and the manuals for the given
languages. (We hired a part-time Mother-of-two to just do screen shots and
image tweaking... Mostly because our translation coordinator was lazy.)
- Doing something with the returned documentation files, such as building
and printing FrameMaker books and/or compiling online help.
- Building the software.
- Testing the software.
- Having the software and documentation reviewed.
Your first release is going to be a real "beach" with lots of itchy hot sand
getting in everything and rubbing you raw. Just keep in mind that subsequent
releases will be cheaper and will go much smoother. It is the subsequent
releases where translation memory and all of your translation headaches pay
off. PLAN FOR AT LEAST TWO RELEASES.
Voyant Technologies, Inc.
Tel. +1 303.223.5164
Fax. +1 303.223.5275
glenn -dot- maxey -at- voyanttech -dot- com
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
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.