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:Re: What do you brief translation agencies? From:"George F. Hayhoe" <george -at- ghayhoe -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 4 Nov 1999 11:14:04 -0500
Jennifer O Neill asked, "in how much detail should you brief
a translation agency when giving them a contract?" My own
experience in working with contractors--and as a
contractor--is that the more detailed the specification, the
fewer problems arise on both sides and the less time gets
wasted asking and answering questions (and remember that
when your vendor is halfway around the world and has a
work-stopping question, an entire workday or more can be
wasted waiting for the response to an e-mailed question).
SOFTWARE: You should not only spec the software and the
version to be used, but when working with vendors outside
your own country, you should be aware that the version of
the product sold in that country may not be completely
compatible with the version sold in your own country. This
can cause problems as basic as the inability to open a
document. Always test in advance, ensure that all of your
personnel and all of the vendor's personnel are using
exactly the same versions that were tested, and agree up
front that neither you nor the vendor will upgrade during
the project.
PLATFORM/OPERATING SYSTEM: Although cross-platform issues
are gradually being solved, the current solutions are often
far from perfect. Most importantly, you may experience
problems with differences in character sets if you use the
Windows platform and your vendor uses MacOS or UNIX, or vice
versa. (Character set problems can also result from using
different language versions of a single platform or
operating system.)
FONTS: Identify the precise fonts--and foundries--you want
the vendor to use. The many versions of fonts out there vary
widely, and this fact will have significant consequences for
some documents, especially where page design requires
careful copyfitting.
TEMPLATES/STYLESHEETS/STYLE GUIDES: If you want the vendor's
documents to match your own, supply the templates or
stylesheets you use. Also provide your style guide, and any
other design and development guidance you provide for your
own staff. It's very difficult to recreate a design
precisely, and the short turnaround on many contract jobs
makes this task even more of a challenge. Amazingly, some
supposedly professional technical communicators,
translators, desktop publishers, etc. do not use global
styles and do all document formatting locally. This practice
will drive you--or your next vendor--crazy when revision
time rolls around.
MEASURING SYSTEM: Don't assume that everyone uses the same
system of measurement as you do. If you think in centimeters
and the vendor assumes inches (or picas and points),
significant differences will result. (This may seem obvious,
but there's an expensive pile of junk now littering the
Martian landscape that was caused by precisely this
misunderstanding, and both the vendor and the customer were
in the same country.)
PAGE SIZE: Even if the design is not crucial, you should
specify output page size. If you're in the U.S. and receive
pages formatted for A4 output, you will need to do extensive
reformatting. If your vendor is in the U.S. and you're most
anywhere else in the world and receive pages formatted for
Letter output, you may need to do likewise.
DELIVERY MEDIUM: With the popularity of e-mail attachments
and FTP as a means of exchanging files these days, this
isn't as big a problem as it used to be, but there is
probably nothing more frustrating than receiving a disk that
your computer can't read. Don't get caught up the creek
without a Bernoulli with a deadline looming!
There are certainly lots of other things that can cause
problems. Whenever you're part of a team larger than one
person, you will be amazed at how uncommon "common" sense
is. Once again, the virtues of methodology and standards
shine through precisely because they explicitly share
assumptions rather than merely assuming them.
