Technical documentation processes for dealing with translations

[Robbie.N]

Im reviewing our current workflow as its very timeconsuming and would love to hear what other peoples processes are, or even suggestions for improvment. Our general process is as follows:

Currently we use framemaker to create the source manual and then send it away to a translation company, they translate it and send it back to us as mifs, which we convert back to framemaker and then reformat it to our standards. We use a lot of text insets which all need to be relinked to the appropriate language file and the cross references need to be reformatted (to use the correct language) and then relinked, its the relinking part of this process that takes a lot of time. In addition to all that you have to carry out the usual processes such as pagination, numbering, creating TOC etc etc. This process for one langauge can take anywhere between half a day to a full day per manual, depending on the size of the manual and experience level of the person doing it. Currently we are not using any xml and im wondering if this is the road we should be going down? I guess we are using unstructured framemaker, in that we have templates for various languages which we just import the paragraph and character formats, but thats about it.
The whole process is very repetitive and time consuming and im thinking there has to be a way of automating it in some way. I would love to hear peoples views and suggestions, Thanks!

[Bob_Niland]

re: …which we convert back to framemaker and then reformat it to our standards.

That dramatically complicates things.
When I had translation appear in the shop's (FM7) workflow, a print-ready PDF was all that was expected back.

What was sent used a process of:

- copy book/document to temporary ./doc-ID/

- re-save as MIF there

- script: gather all the imports to ./doc-ID/imports/

- script: re-write all the MIF import markup to use ./imports/
(the FM archive function may do this today)

- open MIFs in FM, re-save as .book and .fm, now with local paths
- zip it all up and make available to translators

The regional enterprise office was responsible for proofing.
Using MIF both allowed the in-house scripting, and eased matters if the translators were on a different FM version.

[Robbie.N]

Hi Bob, thanks for the feedback. I think the issue with doing it that way in the past has been that the standards slip somewhat with the LSP makes the calls on the final layout. But i may explore it as an option.

Im wonderiing if people are using xml or similar methodoligy to speed up the process too. It just feels like a very laborious process when we are living in a world with self driving cars & AI for example ! 

[Matt-Tech Comm Tools]

All that AI and self-driving tech relies on communication standards like XML. You'll want to be in that environment if you want to take advantage of machine translation and cost/time savings.

[frameexpert]

Converting to structured FrameMaker and having the XML localized may streamline things, but making structured templates and setting up a FrameMaker structured application is not a trivial process.

An alternative is to look at each step of your current process and see if the step can scripted; for example, relinking text insets to their localized versions, localizing autonumbering, etc. This could significantly decrease the amount of time required to prepare a localized book for output.

[FrameMaker-dk]

FrameMaker ships with XLIFF export. XLIFF is packs the entire document into a neat package, which can be processed through the translation tool. You get the XLIFF back and import it into your FM documents and presto! - the job is done. I have used XLIFF for VERY large documents - like 6-700 pages, and it has worked fine. Might be option for you to investigate.

[Matt-Tech Comm Tools]

Localization can be expensive,  so you should look at your localization budget and decide what you should invest in to drive down that cost.

After moving to an XML workflow, your localization cost will certainly be lower, so you will need to weigh the cost and effort of converting to a structured workflow against the cost and time savings after conversion. Look to localization vendors to help you evaluate your options.