Multi-language Capabilities for DITA Does Not Come for Free

DITA Translation

One of the main ROI arguments made for moving to DITA is the significant localization cost reductions that can be had: basically the more languages you output to, the better the ROI.

It is worth noting though that multi-language capabilities does not come for free, as there are some one-time costs associated with going down this path that ought to be taken into account that rarely gets mentioned. Some of these costs are not inconsiderable and will be a nasty shock for those who haven’t budgeted for it. Here are the ones I am familiar with:

  • the cost of buying multi-language fonts so that the output is rendered correctly (Unicode fonts tend to give you the best bang for the buck here)
  • cost of the XSL work necessary to process new language outputs (if done externally); this may not be such a big deal for many Western languages, but worth taking into account when dealing with Asian languages and especially when working with right-to-left languages like Hebrew and Arabic
  • QA costs associated with checking the new language types internally, as well as the tools necessary to process them (Heartsome licenses anyone?)
  • possible upgrade costs associated with outputting new language types (determine first whether or not your output engine is capable of producing content in the target language)
  • is the localization firm you are using ready for DITA? This is much less of a consideration now that even a couple of years ago, as the standard set of tools most localization firms use now includes DITA capabilities, but that wasn’t always the case. Check to see whether or not your localization firm can handle DITA content; the last thing you want is to discover that the loc firm is behind the times and hasn’t updated its translation toolbench software, and wants you to foot the bill. Even when a localization firm does have the capabilities to handle DITA, you may also find some additional engineering charges tacked onto your invoice if they handle your Translation Memory for you, and they need to make some internal engineering changes to make this happen.

Keep in mind that these are one-time costs, and that the ROI argument is a good one. But it always helps to know what you are getting into before taking the plunge into multi-language output under DITA.

About

"DITAWriter" is Keith Schengili-Roberts. I work for AMD as a Senior Manager for Technical Documentation, and have recently helped usher in a new company-wide DITA-based CCMS. And I like to write about DITA and the technical writing community. To get ahold of me you can email me at: keith@ditawriter.com.

View all posts by