Subject: Translation?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, obair81 -at- comcast -dot- net
Date: Thu, 01 Jun 2006 09:37:49 -0400

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


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!.
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.


Previous by Author: Re: Coping with sub-par contractors (was: Frustrated)
Next by Author: New question about demos - transition effects?
Previous by Thread: RE: translation
Next by Thread: Re: Translation?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads