Re: Process for updating localized help

Subject: Re: Process for updating localized help
From: Paul Goble <pgcommunication -at- gmail -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Fri, 10 Sep 2010 17:22:30 -0500

C G asked:

>   - The translation will be done by some subsidiaries of the group we
>   belong to. It is unlikely that they will have RoboHelp, and I have no idea
>   how good their knowledge of HTML will be. How do I make sure they see and
>   don't mess up the proprietary RoboHelp conditional tags?

It's normal to insist that translators have standard industry tools
like RoboHelp. If they don't, expect translation costs over the
product lifecycle to be ridiculously high.

>   - What is your process for managing updates? How do your translators know
>   what has changed? How do you retrieve the files? Someone suggested using
>   version control - then everyone can easily see what has changed/retrieve
>   up-to-date files (but then my boss pointed out that everyone must learn how
>   to use version control properly).

It's normal to insist that translators use a translation memory
system, which allows them to avoid translating the same text twice
without imposing any new tools on you. If they don't, expect
translation costs over the product lifecycle to be ridiculously high.

>   - How do you manage the translation process for interface text? Do you
>   give the software to the translators, so that they can see the labels in
>   context?

It's normal to insist that interface text be stored outside of the
program code, in a plain-text file (often XML, but sometimes a .h or
other "include" file). This is a good practice from both a
translation and a software architecture point of view. This file can
be compiled-in (if you want a separate executable for each language)
or read at runtime (to allow on-the-fly language selection). It will
be very easy for the translators to translate the text in such a file.
If the programmers didn't design the software this way, then expect
both ridiculously high translation costs and infuriated programmers
(when they find out that the translators broke their code).

One implication of the above is that it's best to use professional
translators, even if there are people in your company who are native
speakers of the language. The in-house people do have an important
role: to QA the translations.

Another caveat: if you're doing 20 or so languages, the chances are
that some of them 1) use "interesting" character sets, 2) result in
text which takes up several times the space of the original, and 3)
are written right-to-left. Make sure all of your relevant software is
set up to deal with these issues.

Paul Goble

Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days.

LavaCon 2010 in San Diego Sept 29 - Oct 2 is now open for registration.
Use referral code TECHWR-L for $50 off conference tuition!
See program at:

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:

Process for updating localized help: From: C G

Previous by Author: Re: Only for list members working in India: Invitation to participate in STC India’s 2010 Salary Survey
Next by Author: RE: Do manuals have to be boring?
Previous by Thread: Process for updating localized help
Next by Thread: The verb "to search" and Windows 7

What this post helpful? Share it with friends and colleagues:

Sponsored Ads