RE: Translation of Op. Manuals (long)

["Glenn Maxey" <glenn -dot- maxey -at- voyanttech -dot- com>]

This isn't as much of a rebuttal as it is a clarification of terms and
agreement. Long and boring and only of interest if you're doing translation.

> Glenn wrote:
>
> >>I can certainly see Linda's point about not giving [translation
coordination]
> >>to a junior technical writer.
> >>There are many reasons why I suggested this, though.
>
> >>The person doing the coordination does not have to be a subject matter
> >>expert. They don't have to know the terminology. They don't have to be
> >>good, experienced writers. They don't have to know the languages that
> >>are being targeted.
>
> Linda wrote:
>
> That was my point exactly. At least in the case of medical devices, it is
> helpful, if not essential, that the coordinator have a good working
> knowledge of the product and terminology. You'd be surprised what
> will turn up with a quick, cursory edit, **provided the person knows the
subject
> matter inside and out**. I'd agree that they don't need to be experienced
> writers. Languages are very helpful though.

Linda talks about a "quick, cursory edit." If any editing is performed, then
certainly you're going to want an experienced technical writer doing the
job. (The translation coordinator is NOT the translator, but could be. If
they are one and the same, then subject matter expertise helps.) So, Linda
and I have no disagreement here.

Based on my experience, though, as soon as the technical writers have source
documentation in a state ready for publication (and hence translation),
there will be no more quick, cursory editing that is possible or permitted
without seriously undermining (or complicating) the translation process.

IMHO, a translation coordinator does not change the source text. The source
text is what it is and remains frozen. The writers may indeed make
improvements to (say, next release's) source text based upon problems that
the translators encountered and the translator coordinator's efforts to
resolve the problems. Changes to the source by experienced writers needs to
be controlled in how it is delivered to the translators.

The best control is once a release when the doc's are done. If you feed
these changes immediately to the translators, you significantly increase the
cost of the translation and may negatively impact the schedule. Multiply
this effort and cost by every language. Worse, the changes might not even
make it in to the target languages if they were too frequently made and not
controlled. I worked with some agencies that preferred constant updates and
some that refused anything new or updated until they were finished with what
we gave them.

Again from my experience, we said that translation happens at fixed points
in the release cycle. The translators got the state of the documentation at
that agreed upon point in time. Only agreed upon areas (much smaller in
scope) were allowed to change, because maybe the writers were still working
on it.

The translation coordinator had enough to do (1) making sure that the right
files were sent out to x different language translators; (2) verifying that
the translated versions were received back; (3) making sure that no "source
language" text remained in the translations; (4) verifying that everything
was translated; (5) getting the screenshots completed for all x languages;
(6) creating the manuals or help systems for all x languages. I'm just
talking documentation here. If translation of software is included, then
they're working their tails off coordinating the translation of the GUI once
the code is stable (at about the time the tech writers kick into high gear).

The translation coordinator does NOT have the time to make improvements to
the source once the translation process starts, nor would they want to make
such changes due to the multiplying factor. Translation agencies aren't
cheap even if using translation memory. They charge at least 20% of the
translation cost just to open a document and do fuzzy matching (e.g.,
automated sentence translation from what exists in the translation memory).

What I did not make clear in my postings is that my definition of a
translation coordinator limits the changes that they are permitted to make
to the source documentation. We limited it because they didn't have the time
and because even if they did have the time, it becomes a nightmare to manage
when the number of target languages is more than one.

And because we limited the scope of the job, we changed the parameters on
the skill set required to perform the job. A well-organized, highly
motivated, (college educated) entry-level employee such as a junior
technical writer or a translator could perform a bulk of the work...
assuming, of course, that an experience technical writer familiar with the
product were available to help answer questions.

Hence, Linda and I aren't in complete disagreement; we were just talking
about apples and oranges.


> <snip>
> >>Depending upon the department's budget, there could be
> >>lots of boring, tedious tasks that are done in-house, such as converting
> >>from FrameMaker to MIF, running the STagger to get RTF files for TRADOS,
> >>cleaning the RTF files, going backwards from RTF to FM, formatting and
> >>producing the FM manuals in those languages, managing the translation
> >>databases, and most tedious editing images with the translated text or
> >>creating screenshots in those languages. In some cases, they might even
> run
> >>the first fuzzy-match pass on the documents (assuming that the documents
> >>didn't change much and translation memory exists).
>
> Wow, do you do all that in-house? If so, I'd love to know what kind of
> dollars that saves. Our  translation house handles 95% of the items you
> mentioned--which I think is typical (?). That work would be incredibly
> tedious, and better suited to an experienced DTP person than a
> tech writer.

Our goal was to do that in house. Realities and goals sometimes don't match.

If you have been controlling the permitted changes from release to release,
the savings for doing certain tasks in-house can be significant and
increases with each target language. As was mentioned, translation agencies
charge at least 20% of the full translation price just to run a document
through TRADOS's fuzzy match.

In other words, if nothing changed in a chapter, you'll be billed 20% of the
cost to translated the whole chapter even though it may have only taken them
5-10 minutes to click on an icon and watch their computer churn away. If
only minor things changed here and there (sentences or paragraphs added),
you can use this technique to find out what is completely new. You can
extract copies of this from the text and only send that out to be translated
out of context. You'll then be billed 100% for the new stuff and 0% for what
hasn't changed.

Translators charge by the word. If the word count in the chapter is large
but the changes small, you do the math as to the cost savings for doing
certain pre-translation efforts in-house, multiplied by each language.

They also charge you to convert from, say, FrameMaker into MIF and then RTF
(and then back again). If you have more than one target language, you can at
least do the initial FM-MIF-RTF conversion so that you aren't billed
multiple times for essentially the same conversion.

Also, if you decide on a new layout or other major changes to the source
that are RESTRICTED from modifying anything at the sentence level, you could
use TRADOS in-house and auto-magically created translated products that
reflect the changes... assuming, of course, that you have the translation
memory. (Request it; it should always be one of the deliverables.)

Translation memory is a database that stores things on the sentence level.
If you change phrasing within a sentence, you essentially create a new
database item. During translation, there won't be a 100% match but it might
find the old translated sentence and suggest it. (This is a real big help
for translators.) If the changes were minor, the old sentence might still be
applicable.

At any rate, if the target language is European or one that you are familiar
with (even remotely, such as Spanish-French-Porteguese), you could use this
technique in-house to go from Winhelp (RTF/HLP) to Microsoft's HTML Help in
the other languages once you have done the conversion in English. The
hyperlink tags etc. will change at the sentence level, but TRADOS
translation memory would be smart enough to suggest the linguistic
equivalent; you would only have to manually insert the appropriate tags
where they might belong in the translated text. The caveat is that you have
to LIMIT improvements to the English source to only the bare minimum
required to convert from RTF to HTML.

Supporting lots of different languages can and does negatively impact the
changes you can make to the source. However, if you control the changes that
are made (e.g., refrain from going below the sentence level), you can gain
the freedom to make major documentation changes and roll these into other
languages in-house.

> <snip>
> >>However, a junior technical writer coming out of a technical
communication
> >>program has the tools skills that they need to be successful (if they
aren't
> >>messing with the software). The coordination process helps them become
more
> >>familiar with the entire documentation suite. It helps them become more
> >>proficient in the subject area so that they can later contribute as
writers.
>
> I'm not sure that coordinating unfamiliar documentation in a language they
can't read is
> really going to teach a junior tech writer anything, unless they already
> have solid product knowledge.

Whether or not it is a junior tech writer or a (college educated) entry
level DTP person, they will still learn something. They learn the
documentation suite. They become more familiar with the tools used by the
organization. They can gain product knowledge particularly if they are the
ones doing all of the screen shots. They have to compare elements of the
translation with the source somehow. If they have to do the screen shots
for, say, the tutorial in x different languages, they will become more
familiar with the product. Typically, they'll be reading and following the
English document while working in a translated version of the software for
the screen shots.


The reality from my translation experience has actually been more in line
with Linda's position (i.e., should involve experienced writers or
translators) instead of my position (i.e., could be given to a junior
employee).

=========================== boring story to support above statement

On the last project that I worked on, the most-tenured writer was burned out
on writing and wanted to move into marketing. A temporary transition into
translation coordination was arranged, because we needed someone, neither my
other co-worker nor I wanted that position, and the company was having a
hard time attracting employees due to their remote location and ineffective
HR group. Initially, it proved to be a wise decision, mostly because the
organization of the documentation (that he had been responsible for all
those years) was so complicated and inefficient, it couldn't be given to
someone else.

Over the years, he never found it important to take a step backwards to fix
design and organizational decisions that turned out to be wrong as the
documentation suite grew in order to go n steps forward in terms of being
able to bring new employees like me up to speed and ease translation
coordination efforts.

I plowed ahead with fixing the organizational problems (with a threat to
quit if they didn't let me do it). At any rate, his burn-out in writing
carried over into his activities as temporary translation coordinator. Come
the second release when he was "overworked", I took responsibility for
(English,) Spanish, German, and French while he continued to handle GUI
translation coordination and Japanese and Chinese. The scope of the Japanese
and Chinese efforts were reduced (and much of it farmed out to employees in
offices there). The ball got dropped for images in a Spanish training-type
manual that were still assigned to the burned-out temp trans coord. So, I
commandeered a college intern for about a week and supervised his efforts to
complete this task.

I had a part-time "Hausfrau" with minimal computer experience at my
disposal. We trained her in various applications (such as Explorer, PSP,
Paint, Notepad, Word). I got the organization of the source English where it
needed to be (such as reducing file count from 3000 to 1200) and had her
mirror those changes in the other languages. She created the screenshots and
edited text call-outs in images for Spanish, German, and French.

The moral of the story reflects both Linda's position and mine. Yes,
experienced writers (first my burned-out co-worker and then me) were heavily
involved with the translation coordination.

However, after I completed the organization in the source language, the
coordination with the translation agencies and the supervision of co-workers
went very smoothly; I still had time to document new features. However, this
was only possible because I had the "Hausfrau" and the intern to do the
grunt work. Supervising them was a significant distraction, but much-much
less of a distraction than having to do all of grunt work myself. When I
left, I handed off my tech writing and translation duties to two tech
writers fresh out of a tech writing school with full confidence that they
could handle it.

Glenn Maxey
Voyant Technologies, Inc.
Tel. +1 303.223.5164
Fax. +1 303.223.5275
glenn -dot- maxey -at- voyanttech -dot- com


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
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.