Including images can be a headache for the technical writer. Thanks to the challenges of translation, your headache can morph into a long-term migrane when the images include text.
The “industry standard” solution is to avoid text in images. At first, this sounds like a wonderful idea. “Don’t write, just draw.” It could almost be a song. And it works well for some products (think Ikea furniture assembly instructions).
If words are inescapable, you can often get away with replacing these with numbers. Customers are used to this: it’s a well-established practise to make them match part numbers to a table of names.
The problem is that some image types are meaningless when the text is removed. Think of graphs without labelled axes, or, even worse, flowcharts with just numbers in all the boxes.
My previous post (11 images issues for tech doc systems) explored some of the challenges inherent in handling images in technical documentation.
Unless you’re writing very image-intense documentation, you’re probably using a system that does not include all the image information.
For example, for a DITA system, the image itself is not part of a DITA file (it’s just a reference). The image’s source file is not formally related to the DITA file at all. This means that the text in the image can be two steps away from the DITA file.
For text without images that need translation, a modern translation workflow can look something like this:
Create the content
Extract the text fragments
Translate the text fragments
Merge the translated text fragments into the content
Publish the translation
If possible, use automatic formatting during publication. The style sheet should be designed so that it has flexibility to accommodate different text lengths.
For simplicity, I’ve left out the quality control loops. For example, depending on the method/tool that you use, you may need to check that the fragments are put back in the right places. Native speakers should also check the translated publication. They can see errors that you didn’t even know could arise. For example, Chinese has rules about the minimum number of characters on a line.
It takes time and effort to set up a translation system, train translators to use it, get quality control in place, and get it to run smoothly. And that’s without the complexity introduced by images with text that needs to be translated ….
If there are images that need translation, in addition to the above, a person or tool has to:
Identify the images with text
Extract the text from the images
Translate the text fragments
Merge the translated text into the translated images, and then save in the required image format
Link to the translated images in the translated publication
For simplicity, I’ve left out quality control loops again, even though they are important. And someone has to combine and coordinate this workflow with the text translation workflow.
If your system is intelligent and well-designed, the image translation workflow only has to be repeated when there are revisions to the images. If your system is unsophisticated or badly designed, you may have to manually check whether the images have been translated each time there is a new translation. In addition, you may have to update the links to previously translated images every time there is a new translation.
If you use a software system that allows you to include the image text with the writing, you can avoid the problem of a separate translation process for images.
The DITA 1.3 specification includes “SVG integrations.” I haven’t tested whether this means that you can include the content of an SVG with a text layer. If it does, this can solve the translation headache (that is, once your vendor has implemented the SVG integration support, and if you get your translation package to extract the SVG text). Note however that if your image needs to be a photo with text overlay, SVG can’t help you.
MadCap Flare allows an image map with hyperlinks. You could potentially use this to include translatable text, although I haven’t tried it. The downside is that with MadCap Flare you have vendor lock-in. And the more you use of image maps for translatable text, the more locked-in you get …
English is more compact than most other languages. On average, Russian words are a bit longer than English ones, while German words can be sustaintially longer. But that’s on average, and you might not be lucky.
For example, you might have labelled a part of an image “Governor/AVR” (12 characters) and left a bit of extra space for the translation. In my industry, “AVR” is a very well-known English abbreviation for automatic voltage regulator, and it would be inappropriate not to use the abbreviation. The problem is that the impressive German “Drehzahlregler/Spannungsregler” (no abbreviation available, and 30 characters) is unlikely to fit.
Image translation can’t always be avoided. It may require manual processes, and/or complex automatic processes. If you’ve got a lot of images to translate, it may be worthwhile investing in tools and processes to make this more efficient.
What’s your experience with images and translation in technical documentation? Write a comment ….
Jeanine Shepstone writes user information for generator control systems. There are plenty of images to contend with.
Get new posts delivered straight to your inbox.