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.
Subject:Re: planning for help translation From:Tom Brophy <tom -at- TCRAFT -dot- COM> Date:Wed, 7 Jul 1999 15:36:56 +0100
Hi Grayson,
> In my experience, it is absolutely essential to have the same
> translators and project managers do the localization of the software
> and the translation on online and printed documentation. This way
> you are sure to have consistent translation. Also, the translators
> are able to translate the UI more accurately when they have the
> manuals and online help for reference.
I don't think I'd go quite as far as to say "absolutely essential". While it
may nark off people on this list, the reality is that the software is the most
critical component in most localization projects. I have worked in
localization for ~10 years, and I have only ever seen one project where
localized help/doc was a standalone deliverable. Most publishers take one of
the following lines:
1) the doc/help must match the software
2) the doc/help or portions thereof are left in the source language (usually
English).
If we assume we are localizing the doc/help, then both components are heavily
dependent on the software. Unfortunately, the common requirement to simship
often precludes waiting for the software to finish before starting the
doc/help, which in turn means different translators working on software and
doc/help. Translation inconsistencies can be minimized by producing a
comprehensive and agreed glossary before any translation starts, or reusing
existing translations via Computer Assisted Translation (CAT) tools such as
Trados, Transit and others.
To recap:
1) If the software isn't finished yet, get an appropriately scheduled visual
freeze into the development schedule - this will save you an inordinate amount
of grief, money and hair.
2) Create a glossary from the software in conjunction with your vendor. Have
it reviewed and finalised; be very careful about making changes to it once
translation has started. (Note that changes are not impossible - they're just
expensive in terms of time and money.)
3) Create language-specific style guides. Dig out any language-specific
reference material you've got e.g. previous translations
4) Get your help out of whatever HAT it was authored in (if any) and quantify
it
5) Create a build kit for the localization vendor and test it on a clean,
non-networked machine.
6) Review any errors in the source language help and correct them before
translation starts if at all possible and ship the build kit to your vendor
7) Discuss and agree your deliverables, schedules and budgets with your
vendor. Determine what your hot criteria are from cost, quality, schedule and
tell your vendor (in case of cock-ups) - all three is not an acceptable answer
:-)
8) Agree a sampling schedule with your vendor and get the supplied files
reviewed in a tmely manner. (Note that your high-school French/German/whatever
is unlikely to qualify you to override a professional translator's text!)
9) Get your files back, QA them and ship them