The Perils and Pitfalls of Localizing DITA Content

DITA has more than earned its spurs as a method of reducing global publishing costs, but that doesn’t mean that the localization process is completely free of challenges.

As we learned in Part 1 of this article, DITA content is designed to be built from small and independent “topic chunks” that linguists are usually able to translate without the need for much additional context. Because of this, a linguist can be supplied with a PDF of the final published output that will provide any missing context. But what happens when you need to review one translated chapter from a large manual containing 20 or more? While it would previously have been easy to identify the chapter requiring review, each chapter might now be made from 35 files out of a total of more than 650 in the whole manual. This can be where a typical language service provider (LSP) comes up short.

A solution to every problem

Based on our unique understanding of how DITA works, we have developed a solution for this. The key to DITA content is the DITAMAP – a file that serves as the blueprint for a publication and lists the eventual order of the DITA files. We have created a tool which reads the DITAMAP file and organizes the DITA files into the correct order.

How it works

The screens below show how we can accommodate a client who asks for the review of only one chapter (in this case, it’s the Sample Programming and Processing chapter, which contains 32 files) of a document containing 162 files. The screen to the left shows the full list of translated files in alphabetical order, while the DITAMAP visualization through FrameMaker to the right shows us the order but also splits the chapter into several sections and sub-sections that mimic the eventual publication structure. We’ve highlighted how three of the DITA information chunks fall into the eventual structure:

The other common issue linguists can have with DITA is understanding how a file is eventually represented once published. In flowing text this is not typically a problem, but the DITA framework does allow the use of some sophisticated elements that can appear confusing to linguists. Examples of this are complex table and list layouts or elements that are part of the DITA user interface domain (a special set of DITA elements designed to document user interface tasks, concepts, and reference information.) An element contains one or more user interface control () elements, and when there is more than one element, the formatter shows connecting characters between the menu items to represent the menu cascade. 

In the following example:

produces the following output:

Start > Programs > Accessories > Paint

Once a document starts to use multiple elements and references, the chain of elements can become harder to understand. For that reason, we’ve created a plugin that uses the xslt transformation file supplied by a client in order to generate an XML preview of the DITA text directly in Trados Studio. You can see how this preview looks in the red box in the screenshot below. This way, even more complex layouts (such as the ones shown below) can be easily visualized by the linguist, making translation a much simpler task.

If your business is planning to move its authoring to a DITA environment, get in touch with our team for more information about how we can take the pain out of your localization process.