TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
CB Casper wondered: <<Our documents are translated into multiple
languages and we are making a major change in going from FM+SGML to
XML. One area that is highly affected is graphics. We are being asked
to include no text in any graphic, but to include bubble numbers with
lead arrows anywhere we want to include text. We then include a list to
provide text for each callout.>>
It's obviously clearer to label the parts of a graphic directly rather
than using numbers and a lookup table because direct labeling removes
an entire step from the process of using the table: with a number, the
user must look away from the graphic, find the desired number in the
table, and determine the meaning rather than simply reading the meaning
directly from the illustration. But given the complexities and costs of
localization, this sounds like a reasonable compromise.
You could probably make this easier with some careful graphic design.
For example, arrange the numbers of the callouts, to the extent that
it's possible, running from top to bottom of the image, then provide
the lookup table beside the graphic, next to the numbers, in the same
order. That minimizes the cognitive cost of this extra step because the
callout is close to the correct position in the lookup table.
Could you do this by creating a two-cell table, with the left cell
containing the graphic and the right cell containing the text? If so,
this will work well; I've done something similar in quick-start manuals
that were well received by their users.
<<The reason for this change is to provide for easy translation without
affecting the graphic itself. The localizers only have to work with
text, not with the graphic itself, which can be expensive.>>
Of course, this assumes that the graphic is itself language-free. If
the graphics contain English words, you'll need to provide a localized
(e.g., French) version of the graphic too. In that case, the solution
proposed above provides little benefit. In that case, you need a
slightly different variation on this theme: find out what graphics
software your localizers use, and figure out how to exchange the
labeled graphics with them as painlessly as possible. If you keep the
text in a separate editable layer above the graphic (as in Photoshop),
it's easy to update that text.
I'm surprised that nobody (in my limited awareness <g>) has done
anything much to facilitate localization of graphics: For example, why
not write a simple utility that records the position of each text box,
extracts the relevant text into a text file (so it can be used with a
translation memory system), then reimports the translated text into the
graphic file? Given the number of hooks into the Photoshop API, it
doesn't seem like this would be rocket science, and it would provide
many efficiency benefits when it comes to localizing graphics.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
