Translation?

[Geoff Hart]

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.ca
(try geoffhart at mac.com if you don't get a reply)
www.geoff-hart.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -