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.
Paul wondered: <<Our docs in English will not be finalized until about
4 weeks before they must be given to the customer in another language
(mid-August). A translation will take about 4 weeks.>>
I'm assuming you mean that this is the translator's estimate given a
careful estimate of the amount of work you have described to them? The
less accurate your estimate, the more room you need to leave for
slippage (time overruns). It's worth noting that the exact match
between the two time periods sends up a red flag for me: there's no
room in that estimate for slippage, which is inevitable in many
projects. That means you need to find a way to free up time at the end
to correct any problems.
For future projects, it's well worth your while to figure out a way to
get the developers to freeze the interface and the features far in
advance of the deadline. These parts are easier to design well, test,
and freeze early in the design process so developers can subsequently
focus on the actual plumbing that makes the product work. If you can
achieve this, it's conceivable that you can come close to final
documentation well in advance of completion of the programming.
<<It has been suggested that I should turn over to the translator now
those chapters that we expect will have no or almost no changes, since
it would be impossible to have the entire translation done and the docs
printed and bound etc in the 4 week window starting in mid-July.>>
This makes good sense. First, it allows the translators to begin
developing a terminology list (for the sake of standardization) and
researching any problematic words or phrases. It will also give them an
idea of whether you understand the concept of consistency and, if not,
provide advice on how you can achieve it. Second, if there really are
only minor changes, this means that some parts of the translation will
be complete before you've even sent them the final parts. If there are
subsequent changes (e.g., the name of the "Output" menu is finally
changed to "Print" <g>), these are easy to make globally.
Both are a good thing. Note that you should also send the translator
chapters that are still very early in the writing and revision cycle,
provided they're clearly labeled "don't translate this yet". This also
gives them a head start on researching terms and building a translation
glossary.
<<Is it common practice to break up a translation like this?>>
So far as I know. I've only worked on smaller projects with looser
deadlines, but if I were asked to do something huge, that's exactly how
I'd want to work on it.
<<The thought of it fills me with dread, what with the implications of
getting doc changes back to the translator after they have "finished"
chapters that we thought would not change, and the idea of trying to
unite chapters that were translated at different times etc.>>
The first challenge you need to face is how to communicate changes to
the translators. If you're using Word or WordPerfect, it's easy: use
revision tracking so they can quickly see what you've done. In other
software, you'll need to develop workarounds such as tagging changed
text using colors, symbols, or whatever. The goal is to make it easy to
find changes, and difficult to miss changes. That both reduces the
translator's time commitment (i.e., your cost) and reduces the risk of
errors slipping through.
Second, hire an editor before you send anything for review and before
you send anything for translation. Errors caught before review are
things the reviewer won't have to correct; errors caught before
translation are things the translator won't have to correct.
I don't have strong data on this, but in my own work, editing before
translation (particularly when the goal is to make the text more
concise and efficient and to standardize wording for consistency) can
nearly repay the cost of the editing in saved translation costs.
(Reduce the number of words and you reduce the cost!) That would be
less true for highly automated machine-assisted translation with a good
existing translation memory, but even if it doesn't save money, it will
reduce the frequency of errors.
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
