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

Russ,

Although I have been involved in very little translation work, I believe you got snookered.

Several years ago, I attended a small forum on using XML in technical writing. It was about the time that Microsoft Word switched to an XML-based file format. One of the speakers was an owner of a small translations company. He was all gaga about the fact that a Word file could be saved as XML. He stated that his translations house would prefer content in XML, because it removed all the formatting leaving only the content to manage. We have not used him to translate XML documents, so I cannot state if there are any savings from the DTP costs. If one has a well-running XML roundtripping workflow, I would think one could hand off the XML files to the translations house and get translated XML in return...no DTP required; you do the DTP yourself when you bring the XML into FrameMaker.

Two years ago, we asked one of our employees from Columbia to translate a 250 page, structured FrameMaker user manual into Spanish. The employee had never used FrameMaker, structured nor unstructured. I gave her about 10 minutes training. She a very, very good job. I can't remember if I had to fix anything, but if I did, it was very little. Our EDD inserts a few test snippets automatically, such as Warning, Caution, etc, in addition to autonumbering text, such as Figure and Table. She gave me the Spanish for these snippets. I then added formatting rules to the EDD that were triggered by a book attribute for the language. After importing the updated EDD, all these snippets updated correctly.

So, my little experience is that a well-designed EDD should virtually eliminate the DTP that a translations house needs to do; the only thing I can think of is fixing pagination. Moreover, an XML workflow should eliminate the DTP cost entirely.

One could always ask the translations house to do ONLY the translations, and let you do the DTP yourself.

Van