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.
Re: When to use screen shots (was: screen dumps in books)
Subject:Re: When to use screen shots (was: screen dumps in books) From:Tom Brophy <tom -at- TCRAFT -dot- COM> Date:Fri, 22 Jan 1999 05:30:53 -0000
Hi,
[snip]
> Getting to the appropriate screen and populating it
> is time consuming, particularly when the translation people
> are not familiar with the software being documented.
This problem can be alleviated by providing a "roadmap" to the various screenshots that need to be taken. This doesn't have to be specifically for the localization folk, your internal QA department would probably also find such a roadmap quite useful.
> I've worked with translation companies that didn't provide the
> translators with computers capable of running the software
> being documented, so the translators were not able to
> generate screenshots at all.
This shouldn't be an issue with Mac/Wintel software, although it can be a prolem with client-server and Unix applications. Depends on what the translation company said it was going to do - if the doc needs screenshots, the company needs some means of taking the shots.
> The scheduling can be a serious problem. The goal is to
> release the translated version of the product very, very
> quickly. That means translating the books and the software at
> the same time.
This is generally not advisable. If you can guarantee that I have a perfectly internationalized application, and we have an agreed glossary up front, I can proceed with the two components in tandem. However, perfectly internationalized applications are rare beasts indeed. It is quite common that there will be dependencies between different strings within an application. These dependencies will ususally only become apparent when the translator checks their translation in context. Changing a term in the software can entail a *lot* of expensive rework on the doc/help afterwards.
> Waiting for the software to be translated in
> order to get the screenshots introduces undesirable links in
> the timeline.
Agreed. But, you usually need to balance schedule, cost and quality. Optimizing one of these will adversely affect the other two. You need to decide on the balance you want up front, and communicate that balance to your translation vendor.
> In some cases, it is actually quicker and easier for the
> translators to edit the screenshot graphic directly than to
> redo the shot from the software.
Typically, if you decide to manually edit screenshots, the following occurs:
a) someone generates an art text file (containing the localizable text from the graphic)
b) the text file is sent to the translator who returns the translated file
c) a graphics/DTP person edits the US graphic to insert the localized text.
Issues can arise with the font face and size to be used, the fact that the translator has translated the text without any context.
Cheers,
Tom
// Tom Brophy, Email: tom -at- tcraft -dot- com
// Translation Craft, 19A Main Street, Blackrock, Co. Dublin, Ireland
// Phone:+353 1 2836336; Mobile:+353 86 8295856; Fax:+353 1 2783572
