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: 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. http://www.doctohelp.com
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: http://lavacon.org/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
