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.
Dick Margulis wonders: <<I'm writing a user manual for a patient
monitor with a sorta kinda Windows-like GUI. That is, there is a menu
bar with drop-down menus. Some of the menu selections open dialogs.
In other words, the visual metaphors are friendly and familiar, even
if there aren't actual windows you can close. In the initial draft I
included screen shots of the menus and dialogs in the course of
writing task-based procedures. The client, in reviewing the draft, is
concerned that the cost of translation into something like ten target
languages will be greatly increased because of the need to generate
substitute screen shots and has suggested, as an alternative, that we
mock up the menus and dialogs using text tables (the deliverable is
in Word). The result would be logically equivalent to screen shots of
the actual menus, but it would not be graphically identical.>>
Remind the client that not all shortcuts work out as well as you'd
hope, particularly in complex situations like multi-language
translations. The screenshots are a good bet simply because then you
know for sure that you've got the right words (the ones that actually
appear in the interface). If the translation agency is also
translating the menus, you might as well just use the screenshots
produced from their translations.
On the other hand, if you're able to coordinate with the translators,
it's easier to use text tables because these can be automatically
translated (whereas graphics must be translated manually, increasing
the risk of error): just make sure the translators understand how
these tables relate to the interface so that they will use the same
terms in both places.
<<...the menus and dialogs as translated by the translation agency
might not be identical to the menus and dialogs as translated ahead
of time by the company for their on-screen display>>
Might be a Very Bad Idea (we probably need an acronym, VBI, for this
purpose <g>). If you're hiring professionals to translate the
documentation, why allow amateurs to translate the interface?
Speaking as a frustrated French translator here in Quebec, I can rant
for quite some time about the low quality of translations hereabouts
by people who consider themselves qualified to translate... and who
really should have their word processors confiscated.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
