How can a structured frame be used for translating books to foreign languages?

@Ian Proudfood

A well organized XML based project will definitely save translation costs. There are many advantages to the XML approach to translation management including: Almost zero DTP rework costs - make the EDD/Template do all of the work! Translation is application version independent - no need to wait for the Translation Memory/CMS system vendor to support the latest version of FrameMaker.

»... a well organized XML based project will definitively save translation costs.« – I have read sentences like this from a lot of consultants. And I have consulted/supported a lot of customers after those consultants left the stage. I always hear more or less the same from all of those clients. No question, I hear a lot of arguments for working with XML in tech doc, most of the arguments you mention included. Most of the tech writers are happy with the new structured FrameMaker and enjoy writing. And, cross your heart: Finally there's no alternative to XML in the long term if you take your tech writer job seriously. No question – working with pure XML in a professional information architecture in a structured, guiding editing environment like FrameMaker is cool, fun, faster and produces more open, more accessible, more reusable, more reliable, more consistent, in a nutshell: more valuable data.

But what I have never ever heard, and I'm talking about several hundred companies, is: We save more money on translation now. You might imagine that this is surprising me since many years. This is why I always ask: Did you save any costs in your translation projects? Surprisingly the answer is always: No. Actually some – no, wait: many – tell me, that their translation agency even charges more now, because they have a lot of new costs:

• Costs, to customize their translation memory system to the clients custom xml,
• costs to follow badly or not documented changes in the client's xml structure (DTD/Schema changes) in the TMS,
• costs because of more engineering work like 
  • valididating xml in advance,
  • fixing invalid xml exports,
  • fixing invalid translations due to – sometimes massively – increased amount of tag errors because of tagging differences of "old" (legacy mif) and "new" (xml) tags,
  • dealing with just too big XML files that need to be carefully split, so that the TMS has a chance to read it, or alternatively:
  • "glue" the ten-thousand xml "snippets" to more handy chunks,
  • project managers and translators that need to do additional checks, validations, verifyings - and often not knowing what to do with those cryptic error messages, meaning additional support costs

Of course, many if no all of these and many other problems I did not mention here can be solved. And many are not exactly system immanent problems but communication problems (like introducing or renaming elements/attributes but not documenting this and not communicating this to the translation service provider) or would apply to any system change (e.g. also when switching from Word to Frame). However, I do not know of any single translation company on this planet (and I know virtually thousands of them from countries all over the world) that reduced the price per word for just a single pence, just because the client switched over from Word/Quark/FrameMaker/InDesign/Whatever to XML.

Just ask your translation service provider: Will you charge me less per word if I send you XML instead of MIF? I would really be surprised to hear a "yes". And frankly, if you have ever compared a professional FrameMaker document with the same document in xml format in a professional system like Trados: There is actually no difference that would justify any price difference. The text is the same, the amount of words identical, the number of tags is identical, it even looks identical in the translation system (I can post screenshots if you like). From the translation perspective there is no single reason why a translator should charge a single pence less.

So, it's a modern myth, that switching to xml reduces translation costs. That might be true, if you come from a really medieval documentation szenario with MS Word or the like, with manual formatting without any styles and so on (I see tech docs every day where even the TOC is typed in manually!!!) and swith from there to a modern structured xml authoring in combination with other supporting tools like authoring memory / authoring assistance, controlled language, translation memory and terminology managent and control, snippet based content management and so on. That will increase the consistency and quality of your data, which will reduce translation costs in the long term. But the truth is: This has nothing to do with XML per se, but with professional writing and professional management.

So, what's left in the money saving story? No more DTP in the target languages? I always hear, that with XML and FrameMaker you do not have to "format" the translated document. The truth is: If you have a professionally formatted (unstructured) document, you don't have to take care of it, too. Modern tools like Trados keep 100% of the formatting 100% correct in the translated document. If the underlying template is intelligent enough to take account of text amount changes due to longer translations, and if you don't have too many local formatting overrides, the DTP is actually zero and can be reduced to a few mintes/hours for "flying" of the document to check out for unexpeted problems wich can occure in both structured and unstructured documents.

Just to give some numbers on this: We are processing every day technical documentations for a quite big company. A typical documentation from them is about 250 pages in unstructured FrameMaker 9 (source language is English). Until now they were resistent to all my XML pushing. The Documentation is based on a straight, simple template (with our help "reduced to the max") and there are no formatting overrides (a script automatically checks this). The post translation Quality Assurance effort is - depending on the target language - usually something between 1 to 4 hours – that's a few seconds per page for the languages where already a lot of past Quality Assurance Steps went back into the Translation Memories and up to a minute per page for more "problematic" languages).

So, again: XML will not save you a single pence on translations. But it might help you to produce more open, more accessible, more reusable, more reliable, more consistent, in a nutshell: more valuable data. But if you already have properly set up (ustructured) FrameMaker Documents and already work with a professional translation memory system, you will be quite disappointed to learn, that the impressive money saving promises you recently saw on that great PowerPoint slides melt down to a few bucks over a couple of years.

Kind regards,

Stefan Gentz

Stefan – Thanks for your insight.

Our translators are excellent linguists but not all of them are technically-minded. It is not very long ago that some were dictating translations to be typed up from tape. Most of them are now comfortable in Word, but would hesitate to leave the safe environment, especially when it has in many cases been customised by means of simple macros to facilitate the job.

As in many walks of life, we can recognise an ideal target but accept that anything we might achieve is inevitably a compromise.