Software Translation Headaches?

Subject: Software Translation Headaches?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, "Shenton, David (DTRN)" <david -dot- shenton -at- smithsdetection -dot- com>
Date: Mon, 10 Apr 2006 11:27:07 -0400

David Shenton wondered: <<I'm dealing with a large amount of translation on software screens and one issue that gives me a headache is trying to squeeze translated text into a specific size on a button field.>>

Coincidentally, I've written at some length on this specific problem. Have a look at my article to see whether it helps point you in the right direction:

It's not precisely what you're looking for, but many of the same principles apply, mutatis mutandis. Another key solution is to talk to your translators (or colleagues in the destination country) to find out whether the computer industry has developed standard terms for these functions. Clearly, they must have faced the same problem you have, and odds are good that they (with their superior knowledge of the target language) have come up with solutions you could adopt.

<<One solution would be the use of graphics so with that in mind I'm trying to create a more graphical button list.>>

This _can_ work, but the biggest problem with buttons and icons is that they are unintuitive to just about everyone until they have been memorized (e.g., by long experience using the same image in other software). Moreover, people tend to memorize icon and button locations more than they memorize the images themselves; you can see this quite dramatically if you use the Customize function to rearrange a colleague's toolbar icons in Word while they're off at lunch. Not that I've ever done this, you understand. <g>

As noted in my article, icons should never be randomly placed in the toolbar (i.e., the way that keyboard shortcuts were randomly assigned to F-keys in WordPerfect back when dinosaurs ruled the Earth). They should be arranged into logical groups based on functionality.

If you adopt the graphical approach, the way to make this humane is to use tooltips ("what's this?" help) directly in the interface, thereby eliminating the need to search the entire help file to find the name of a particular image and providing an instant explanation of what each image represents. Of course, then you'll need to ensure that the tooltip interface is defined so that it's sufficiently large to hold the full text.

You'll also need to ensure that you use identical text in the tooltip and the documentation; that lets users research a function using the name that appears in the tooltip rather than having to figure out what possible synonyms you used in the documentation.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
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!.
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Software Translation Headaches: From: Shenton, David (DTRN)

Previous by Author: Move from Ventura to FrameMaker wise?
Next by Author: Online feedback methods?
Previous by Thread: Software Translation Headaches
Next by Thread: RE: Software Translation Headaches

What this post helpful? Share it with friends and colleagues:

Sponsored Ads