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.
Laurah Limbrick is working on her first project that involves translation:
<<Our current doc set is several thousand pages, with commensurate screen
shots. The plan for doc translation is that we (the documentation team) will
be provided with the translated GUI, and, using our current user docs as a
guide, will replace all screen shots in the English doc with the translated
shots by stepping through the foreign language GUI.>>
Your localisation vendor should already have done this for you as part of
their formal quality control process, but if you haven't worked with them
before, you should consider hiring a local person who's skilled in the
language to do a reality test. You may find out that the localizers did
excellent work, and that you can trust them fully in the future, or you may
find out that you need to insert a penalty clause (cost per error) in future
contracts and hire someone in your area to check everything locally. You
could have that local person check every single line of the translation, or
just do some random sampling to identify whether there's a general problem;
the latter is less expensive, but the former is more likely to spot errors
that arise only occasionally. Both jobs would be easier if your translation
vendor will provide a complete list of their equivalent terms (this may be
unavailable for technical or commercial reasons) that would let you look up
the correct translations and let you compare the screenshots yourself.
<<The language for this first go-round is Spanish, and 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.>>
That may be a reasonable assumption, but in French (another one of the
"romance" languages), text expands by an average of 25% or more. If Spanish
behaves similarly, you may discover that some fields or buttons have moved,
or that some text labels have been cut off, and in some cases, it may not be
obvious where things have moved or what's been cut off.
<<Future customers may not be using Roman alphabets, which may be an issue
in that "just count three items over on the menu bar, then count down two on
the drop-down menu" may not be an option, especially as it concerns data
entry and keyboard mapping.>>
My pet developers <g> program in Delphi, and use external "resource" files
to store the labels for all fields and buttons or whatevers; in effect,
anything in the interface that ends up with a text label is assigned an ID
number, and the text that's assigned to that number exists in a separate
file that's integrated with the software only when it's compiled. This makes
it easy for me to edit the labels, since I can simply print these files and
place them side by side. All I have to do is check that the text matches for
each numbered ID. If you can adopt this or a similar approach yourself, it
will greatly facilitate the task of checking the translations for accuracy,
consistency, and a match between languages. If the translations meet these
criteria, you must still confirm that the resulting screens are usable
(e.g., labels don't overlap or get cut off), but with modern visual design
tools, doing so and correcting any problems is a piece of cake.
<<How do you account for the lack of knowledge of the target language?>>
In my case, I know both languages (English and French) well enough that I
can do the quality control myself. If not, you need to hire someone with
excellent skills in the language of the translation and good skills in the
source language to do the work for you. There's no way around this. Although
the translation vendor should have done this step, everyone makes mistakes,
and the number of mistakes are directly proportional to the number of pages
(or screenshots) in the manual.
<<We don't have the luxury of using a side-by-side computer approach (one in
English, one in Spanish).>>
Which is why paper still works best for some things. Print out both sets of
manual pages, set them side by side on a table in a quiet room, and check
them line vs. line.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words;
on occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary."-- James D. Nicoll
*** 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.
