>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.
That would be great, but it can't happen in this case. Maybe 95% done in advance of July 1, but they can't freeze the GUI before their promised "gold" date.
<<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.
Yes, it does seem like this might be a good thing. I do have some chapters that are unlikely to change.
I guess I could use mif2go to convert chapters one at a time so I could send the translator selected chapters. I would rather keep the Word content (coming from Frame) in one large Word file, since I know the Master pages "feature" in Word works as well as I play the tuba.
Now, if I could just find the many hours it will take to get mif2go conversion working right...
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
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 http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com
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
http://www.techwr-l.com/techwhirl/ for more resources and info.
Translation?: From: Geoff Hart
Search our Technical Writing Archives & Magazine