Re: planning for translation of help

[Tom Brophy <tom -at- TCRAFT -dot- COM>]

Hi Ellen,

> I know I will be translating into at least Brazilian, Spanish,
> traditional Chinese, and Japanese, with more to follow, I'm sure.
> Should I be contacting a translation firm immediately and working
> with them from the outset.
> If yes, what should I be looking for as I contact them. What are
> the other major components of planning for a translation project.

1. Decide what you're translating.
Is there accompanying software? Are you localizing the software? Is there
accompanying documentation? Are you localizing the documentation? What about
packaging? marketing bumph?
2. Decide when you need to ship.
Is the source language help still in development? Finished? Do all languages
need to ship together? At the same time as the source language product?
3. Quantify the amount of translation required.
Translators work on the basis of word counts. A translator can usually
translate ~2000 words of WinHelp/day. Edit/Proof passes progress at ~5/6000
words per day. If the number of days required exceeds your desired ship
date, re-assess either what you're translating or the required ship date.
4. Decide who's going to do it.
You have several options:
Inhouse translators - often result in the best quality, are usually cheaper
than other options, can be a pain to manage if you've got several languages
running concurrently, can be a bigger pain to find, can require a lot of
support
Incountry translators - can be difficult to find, difficult to assess and a
royal PITA to manage (time zones, language, culture, etc.)
Translation agency - you should be able to offload a lot of the day-to-day
project management required to them, quality can be variable, expertise can
be variable
Localization agency - as per translation agency, but they tend to be more
capable (technically)

Process:
1. Generate a glossary from the software (if any)
2. Get whoever is translating to translate the glossary
3. Get someone to review the glossary, get corrections implemented. Freeze
the glossary.
4. Get any other reference material required together, e.g.
language-specific style guides, references to third-party products,
booknames of accompanying documentation, etc.

If you envisage translating future versions of the help files, get the
translators to use a Translation Memory tool. There are several available.
If it's a one-off job, TM can be an unnecessary overhead unless there is a
lot of internal repetition in the files.

5. Make sure your source language help is in good shape. Corrections after
the event cost on a per language basis.
6. Get the help source files out of your HAT. HATs are a PITA for
localizers, and are an unneccessary complication.
7. Ship all of the source files to your translator, with a copy of the
compiled source language help.
8. State your delivery requirements (source files, graphics, compiled help,
TM, etc.) and QA standards to the vendor.
9. Look for a sample file /portion of a file which has been
translated/edited/proofed early in the process and have your glossary
reviewer check it out for adherence to the glossary, adherence to
styleguides, functional integrity of the file ("What hidden text?"), any
other instructions you supplied ... Note there is little point going back to
your vendor with the results of the sample check after they've completed all
the files!
10. QA it and ship it.
11. Repeat ad nauseam or ad infinitum - whichever comes first.

Cheers,
Tom

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=