Re: Translating documentation/insertion of screen shots
so the assumption has been made that "everything in
the GUI will be in the exact same place", so that lack of knowledge of the
target language should (theoretically) not be a problem.
Well, that might be the case. Depending on the feature support, control labels COULD change. You won't know until it happens. Or, I should say, after it happens and your tech support starts getting trans-oceanic calls. (By the way, make sure to include support numbers that are accessible from outside of North America. 800 numbers don't work outside of North America. I'm not adding this to be flippant. It's a common oversight.)
When text on UIs is translated, controls can move from where they occur in the source UI. You might be able to pick commands from menus, but you might need to identify controls on dialog boxes. Depending on how well the original forms are designed, this task could be relatively easy or very difficult. If you document hot keys, these will change for the target languages (unless your company has standardized them).
I understand that it will be less costly than having our translation vendor
perform the task
It will be less costly, in that you won't have to pay the hourly rate for document localization. At the same time, translators won't be available to verify that any of the final captures are accurate. I think the assumption is that there won't be trade-offs. Keep in mind that, as expensive as localization is, the folks who do it typically have some experience. The trade-off might be reduced overt cost with an increase in the time required to get the job done because of lack of experience. Or the time you spend might result in the same cost, but you might have to push the release date. Also, keep in mind that the project management required localization can absorb your resources very quickly.
2. How do you account for the lack of knowledge of the target language? Was
this an issue?
Well, most of the document localization specialists also lack that knowledge. What they have that you don't are people who can verify the accuracy of the captures. You can lessen problems with accuracy by tightening your procedures for taking screen captures.
If your developers maintain the overall structure of the application, you can write explicit instructions on what to capture. This task will be greatly simplified if you limit captures to either full screens (not really useful) to active windows (much more useful). If you use area captures that contain text, each of these has to be reproduced in the target language, and that takes longer (since you have to use a mouse). What's more, controls and labels expand and move, so you might have a hard time determining exactly what to capture. So stick with capturing dialog boxes and windows. Better yet, reduce your dependence on screen captures entirely.
J.D. Edwards has found ways to get around some problems associated with localized captures. As I understand, they write scripts for taking screen captures and automate the process for target languages. Sounds pretty automagical to me. Anyway, if my friend Jay Mead is currently subscribed (and still at J.D. Edwards), maybe he can give you some details on how they manage this. He's also involved in the Rocky Mountain chapter of STC, so you might be able to hunt him down that way.
(If you DO contact him, tell him to drop me a line. :-)
3. We don't have the luxury of using a side-by-side computer approach (one
in English, one in Spanish). Presumably this will prove to be a usability
test of our English docs, since we'll have to step through the instructions.
Do you mean that you also have to do the software verification (that is, make sure that the translation accurately describes the tasks)? That's why localization companies have a verification step, and the translators are part of that process. You really don't have any hope of doing this part of the job unless you have competent reviewers for the target languages who can be available during the software verification.
If your doc group is going down this road, make sure to train all of them adequately to perform the tasks. Document localization is as different from writing as painting is from and printing reproductions. They might both render similar output, but the methods and materials used for accomplishing the task are not in the least similar.
Good luck. If you prepare your source text with target (that is, non-US) markets in mind, you'll reduce the rework you encounter for target languages. Document localization isn't rocket science, but it does require up-front planning.
Bill Burns, Senior Technical Consultant, Scriptorium Publishing
The WebWorks Publisher Cookbook now available
http://www.scriptorium.com/books/wwpcookbook.html
bburns -at- scriptorium -dot- com - 208-484-4459
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See
http://www.infomap.com or 800-463-6627 for more about our solutions.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
Follow-Ups:
References:
Translating documentation/insertion of screen shots: From: Laurah Limbrick
Previous by Author:
RE: Flexibility and Technical Writing
Next by Author:
RE: Translation Memory System
Previous by Thread:
Translating documentation/insertion of screen shots
Next by Thread:
800 numbers (was RE: Translating documentation/insertion of screen shots)
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads