Prep doc for translation collection

[Doug Osborn <doug -at- CITR -dot- UQ -dot- OZ -dot- AU>]

This is the (partially organised) collection of information that i received
from my query on "preparing documentation for translation". Thanks to all
who replied and were willing to swap information. Some of this information
is sourced from the techwr-l archives.

The file is 936 lines long.

Cheers,
Doug

---------------------------------------------------------------------------
Doug Osborn                          | CiTR, Level 6, Gehrmann labs,
Technical writer                     | The University of Queensland,
InterNet: d -dot- osborn -at- citr -dot- uq -dot- oz -dot- au     | St Lucia, Qld, Australia 4072.
Phone : +61 7 365 4321               | Fax: +61 7 367 0441
---------------------------------------------------------------------------

*--- [beginning of included file]

Topics:

  0. Conclusion
  1. Resources
  2. Restricted grammars
  3. Recommendations
  4. Considerations
  5. Basic, "good" technical writing is the solution

0. Conclusion

Do not use any writing devices other than standard "good technical writing
practices". Use more graphics than normal. Contract a native speaker of the
target language to rewrite the manual. Ensure that the document will not be
altered after translating. Restricted grammars have limited usefulness.

1. Resources

1.1 Texts

[from Susan Fowler <sfowler -at- ejv -dot- com>]

As a starting point, see in Proc. of STC Conference 1993:

Russell & Thomson, "Planning for Translation: What We've Learned the Hard
Way"

Bennett, W.S., "Machine Translation and Technical Communication"

Burns, A.L., K. Roesner, "Localization Management of a Horizontal Software
 Project."

Technical Communication journal from STC has a translation column and
occasional full length articles.

Also contact Multilingual Computing, publ. Seth Thomas Schneider,
209/263-8178 or 71224 -dot- 1003 -at- compuserve -dot- com -dot-  They will send you a sample
issue. Contains ads for all types of programs and interesting articles.


[from Debby Andrews <dandrews -at- brahms -dot- udel -dot- edu>]

Recent messages regarding international issues led me to this
plug for a project I'm working on.

Debby Andrews, University of Delaware, is compiling an
anthology for the STC, _International Dimensions of Technical
Communication_, to be published later this year. This anthology
focuses on cultural, linguistic, and technological issues facing
the international technical communicator. A tentative list of
authors and their contributions follows:


Deborah C. Andrews, General Editor, "Introduction"

Rae Gorin Cook (Gorin Communications) "Defining and Resolving
Cultural-Linguistic Barriers to International Personnel in US
Business and Technology"

Linda Driskill (Jones School of Management, Rice University)
"Collaborating Across International Borders: Managing Change,
Changing our Perspectives"

Anne Eisenberg (Polytechnic University, New York), "English and
the International Language of Science"

Keith Elliott (SAP AG, Walldorf, Germany) "A Layered Approach to
Translating Online Documentation"

Charlene Johnson Forslund (Battelle, Seattle) "Audience Analysis
in Creating Pictorial Messages for Nonreaders"

Debbe Krape (University of Delaware) "International
Collaboration: A Case Study"

WandaJane Phillips (International Development Research Centre,
Ottawa, Canada) "The IDRC Strategy for Translating Computer
Documentation"

Ingrid Ratsep (West Chester PA), "The Heifer Project in Estonia:
A Model of International Communication in Agriculture"

Lil Rodman (University of British Columbia) "New Paradigms for a
New Nation: Some Observations on Business and Technical
Communication in Latvia"

Jan M Ulijn (Eindhoven University of Technology, the Netherlands)
"Cultural Rewriting: Experimental Evidence from French and Dutch
Technical Documents"

[from Nancy Hoft <itech -at- mv -dot- mv -dot- com>]

Managing Cultural Differences, 3rd Edition, Philip R. Harris and Robert
T. Moran, Gulf Publishing Company, 1991.

Digital Guide to Developing International User Information, Scott Jones,
et al., Digital Press (may not be Prentiss Hall), 1992.

Global Software, Dave Taylor, Springer-Verlag, 1992.

Designing User Interfaces for International Use, Jakob Nielsen (Ed.),
Elsevier, 1990.

International Business Communication, David A. Victor, Harper Collins
Publishers, 1992.

Also, check out all the offerings by Intercultural Press, the Society for
Intercultural Education Training and Research (SIETAR), the American
Society for Training and Development (ASTD), and have your student sign
up with the STC's International PIC (contact STC for more information).

[from Kay Wicker <kayw -at- spedi -dot- mn -dot- org>]

"Software Internationalization and Localization, an Introduction" by
Emmanuel Uren et al (c) 1993 Van Nostrand Reinhold, New York.

The book's audience is software developers, with about 10 pages of the
300 oriented about documentation translation issues. However, if you're
into QA'ing or designing parts of the user interface such as dialogue
boxes and menus, the software developer info would be relevant to you.
One of my programmer coworkers says it "recommended" reading for any
software internationalization effort.

"The GUI Guide, International Terminology for the Windows Interface"
by Microsoft Press (c) 1993.  European Edition.

The book's audience is software developers.
80% of the book is a table of how English names in a user interface
correspond to various European languages. It has a disk that I haven't
loaded.

[from E. Winters <ewinters -at- netcom -dot- com>]

DAVID VICTOR* : 'LESCANT'
L/LANGUAGE
E/ENVIRONMENT & TECHNOLOGY
S/SOCIAL ORGANIZATION
C/CONTEXT
A/AUTHORITY CONCEPTION
N/NON-VERBAL BEHAVIOR
T/TIME

[from Heli Roosild <HeliR -at- MSMAILHQ -dot- NETIMAGE -dot- COM>]

Swenson, Lynne V. "How to Make [American] English Documents Easy to
Translate"; Proceedings of the 34th International Technical Communication
Conference, 1987; Washington DC: STC: WE-193 to WE-195.

[from kathy farrell <kfarrell -at- MSTR -dot- HGC -dot- EDU>]

One guide used in the aerospace industry is "AECMA Simplified English," AECMA
document #PSC-85-16598.  The subtitle is "Guide for the Preparation of
Aircraft Maintenance Documentation in the International Aerospace
Maintenance Language."  AECMA is the Association Europeenne des
Constructeurs de Materiel Aerospatial.  My copy of the guide says they're
based in Paris.

[from Elaine Winters <ewinters -at- NETCOM -dot- COM>]

I can recommend a few things I've found useful:

Trompennars, Fons: Riding the Waves of Culture: Brealey Publishing

Rhinesmith, Stephen H.: A Manager's Guide to Globalization:
Business One Irwin

Hall, Edward T -- everything Dr. Hall has written has proved enlightening.

and there are many more, of course.

Alas, much of the stuff that's been written is on a very
superficial - -'develop a checklist' level, and that's
unfortunate.  This is an issue which must be addressed at
the deepest level of thought.

I've always thought it belongs in the dialogue on 'quality'
and 'customer service' that surfaces everytime a country
that pays better attention than we do to such matters - -
clobbers us economically.  It really should be an ongoing
discussion, and 'Deming' style - - we need to keep getting
better at it.

We don't.  We blunder around like 'ugly'
know-it-alls offending everyone in our path.

I have published several articles on this subject in
Technical Communication -- most recently: 2Q'94.

1.2 Consultants/training

[from ...]

**************************************************************************

                        STC NNE SEMINAR APRIL 23
**************************************************************************

         Getting Started in Worldwise Technical Communication


     Nancy Hoft of International Technical Communication Services
     and Marcia Sweezey of Digital Equipment Corporation will be
     conducting a seminar on the internationalization and
     localization of user information. Internationalization is the
     process of creating products that can be used in multiple
     localities or that can be easily adapted (localized) for such
     use. The seminar includes a basic overview and introduction to
     internationalization and localization and some fun exercises.

     Who Should Attend:
          * Technical Writers, Graphic Artists, Technical Editors,
          * Supervisors, Instructional Designers
          * People who want some new solutions to
            internationalization/localization;
          * User Interface Designers
          * Writers who write on-line material

     The seminar includes sessions on the following:
     Working with Translators
     Designing pages for Internationalization
     Designing graphics for Internationalization
     Writing for Internationalization
     Managing projects from the perspective of internationalization
     and localization.

[detail deleted]

   ABOUT THE SEMINAR LEADERS

    Nancy Hoft consults with companies on how to internationalize
     and localize their technical communication products.  She
     teaches workshops on international technical communication.
     She is a Novell Certified NetWare Engineer (CNE). Nancy serves
     on two STC committees and manages the International SIG of the
     NNE Chapter. She is also the co-manager of the STC worldwide
     International Professional Interest Committee.  She is
     currently writing a book on international technical
     communication.

     Marcia Sweezey initiated the first comprehensive
     internationalization program for the members of the worldwide
     information and localization communities of Digital Equipment
     Corporation. She co-authored the book Developing International
     User Information as well as Digital's internal standards for
     development of international products. Marcia provides
     consulting services to managers and contributors from around
     the globe and is a contributor on a worldwide service
     globalization program team.

[from Charlene Strickland <Charlene_Strickland -at- cpqm -dot- saic -dot- com>]

I can offer two sources of information on Simplified English:
Sharon Stewart, President, SDS Productions
78 E. Bonita Drive, Simi Valley, CA 93065   805-520-3855  or 818-715-4005
weekdays

She does consulting (1-on-1 training), in-house workshops, & seminars. She
bases training on the AECMA Simplified English Document (Association of
Europeene des Constructeurs de Material Aerospatial).

James Hoard, Research & Technology
Boeing Computer Services
PO Box 24346, M/S 7L-43, Seattle WA 98124   206-865-3263  email:
jhoard -at- boeing -dot- com

Jim has information about Boeing's application of Simplified English,
including glossary and grammar & style restrictions. They've created a
Simplified English Checker (also based on AECMA, obviously!) that analyses
& suggests rewrites. I've seen a demo, and it is a great tool (although not
commercially available). I can mail you copies of two papers he's written
describing Boeing's development in this area.

[from "Rollings, Gill" <WGILLR -at- WOK-MSMAIL-GW -dot- ISL -dot- COM>]

British Aerospace (the company that builds planes and things, not the one
that flies them) uses "Simplified English", and runs courses geared to
technical uses.  I have a letter from their Customer/Vendor Liaison Group
(Tech. Pubs.), and although it's dated October 92, I expect the group still
exists even if the front man has moved on.  You may not want to come over
to attend a course (there might be similar ones he can tell you about in other
parts of the world), but you can buy the materials without doing that, I
think.

Contact Mr J Henry
Customer/Vendor Liaison Group (Technical Publications)
No. 5 DO
British Aerospace Airbus Ltd
PO Box 77
BRISTOL   BS99 7AR
UK

Tel. +44 272 693831 (switchboard)
Fax +44 272 364130

1.3 The US STC PIC

[from Larry Kunz <ldkunz -at- vnet -dot- ibm -dot- com>]

STC has a PIC (Professional Interest Committee) for International
Technical Communication.  I'm sure you'll find lots of valuable
information, and make lots of good contacts, there.

To join the PIC, contact:

  Ann Lyn Burns
  Rocky Mountain Translators
  5757 Central Ave., Ste. G
  Boulder, CO  80301
  phone 303/449-6954

  (Sorry -- I don't have an e-mail address for her.)

Note that you must be an STC member to join a PIC.  (If you're
not an STC member, what are you waiting for?! :-)

[from archives]

The Society for Technical Communication (STC) has an International
Professional Interest Committee (PIC)!  Its mission is:

        The International Technical Communication PIC
        serves STC members by exchanging information about
        globalization and localization projects, international
        standards, and development of product information for
        international audiences.

If you are interested in the International Technical Communication PIC
and in joining the STC, contact the following:

STC Headquarters
901 North Stuart Street, Suite 904
Arlington, VA 22203-1854 USA
703.522.4114
FAX: 703.522.2075

****  MAIN CONTACT ****
Nancy Hoft
Co-Manager, International Technical Communication PIC
INTL TECH COMM SVCS
563 Forest Road, Unit B
Wilton, NH 03086-9718 USA
Telephone/FAX: 603.654.6894
Internet: itech -at- mv -dot- mv -dot- com
CompuServe: 71614,1574

Pat McClelland
Co-Manager, International Technical Communication PIC
Digital Equipment France
2, rue Gaston Cremieux
B.P. 136
91004 EVRY CEDEX
FRANCE
Telephone: 33.1.69 87 57 78
Internet: patricia -dot- mcclelland -at- pao -dot- mts -dot- dec -dot- com

For those of you who are currently International Technical Communication
PIC members, Ann Lyn Burns, formerly of Rocky Mountain Translators, is
currently pursuing a new career path that has precluded her involvement
in PIC activities.

2. Restricted grammars

2.1 What are restricted grammars?

[from Fred Wersan <f -dot- wersan -at- bull -dot- com>]

We have something called Bull Global English. It is a variation on the
various forms of controlled English systems. The point is that if you write
your books with an eye toward the requirements of translation, the cost of
translation, both in terms of time ind $$ will be lower, fewers errors,
etc.
us forms of controlled English systems. The point is that if you write your
books with an eye toward the requirements of translation, the cost of
translation, both in terms of time and $$ will be lower, fewers errors,
etc.


The key points, which you can apply without too big a deal are:
one word, one meaning
short sentences
avoid complex sentence structures
avoid jargon
avoid culturally specific examples.

In other words, keep it simple. (This doesn't mean keep it simple minded,
which some folks sometimes think.)

[from Ray Bruman <rbruman -at- raynet -dot- com>]

You might want to research Basic English, a concept invented early
in the century by a British linguist named Osgood (?) at Cambridge (?).

He developed a carefully selected vocabulary (750 words) and a subset
of English grammar, that would be much easier to read and learn than
the full language as it was usually taught.

The idea was promoted enthusiatically up through World War II, and the
Caterpillar equipment corporation used a derivative called Caterpillar
English (!) to write the technical manuals for their earth-moving devices.

The concept was hotly debated, like Esperanto, simplified spelling, and
other language notions.  It seems to have faded into complete obscurity.
But I think there is a lot of merit in it and would like to learn more.
Our University of California library had quite a few books on it.

[from calistro -at- BNR -dot- CA]

Doug Osborn asks about restricted grammars, and
I would like to clarify some of the replies given
so far.  (I receive the messages from this list
in digest form, so I do not have any replies sent
after 19 September, and I apologize for repeating
any information in more recent replies.)

Basis English is the 850-word list with grammatical
rules developed by C.K. Ogden, along with I.A. Richards,
the rhetorician.  It was developed in the late 1920s,
and after the Second World War there was a great
deal of interest in the promotion of Basic English
as an international language; moreover, the project
reportedly received the support of Churchhill
and Roosevelt.  See Richards, I. A. Basic English and
Its Uses.  New York:  W.W. Norton Company Inc., 1943,
for some of the details of this story.  You will also find
the 850-word list in this book, if I remember correctly.
It seems that Basic did not "get off the ground", however,
and a recent English linguist laments that "we" may have
given up too quickly on Basic.  The real problem with
Basic, as a lexicon for technical communication, is that
it contains too much and too little: too much in the way
of general words, such as comb, stick, play (noun), insect,
happy, and too little in terms of technical vocabulary.
But then, it was meant to be a subset of Standard English
for purposes of social communication.  See Peterson, D.A.T.
~Developing a Simplified English Vocabulary?. Technical
Communication  2Q, 130-132, 1990.

In any case, Caterpillar developed its Caterpillar Fundamental
English in the late 1970s.  It contained 743 words and was
used for producing English documents that would not be
translated.  See Sanderlin, Stacey. ~Preparing Instruction
Manuals for Non-English Readers?.  Technical Communication.
2Q pp. 96-100, 1988, and also Kirkman, John. Good Style:
Writing for Science and Technology.  London, U.K.: E & FN Spon,
1992, for more details.  As many of you know, Caterpillar has
more recently developed Caterpillar Technical English, which
has software-controlled support in the form of ClearCheckTM, with
the view to establishing pure machine translation.  See
Gallup, Sharlene, ~Caterpillar Technical English and Automatic
Machine Translation? in Proceedings 40th Annual General Meeting
of the Society for Technical Communication, 421-424, 1993.

Simplified English, as least one form of it, is perhaps the
most restrictive of all the restrictive grammars in existence.
It was developed by the Association europeene des constructeurs
de materiel aerospatial (AECMA), along with the American Transport
Association (ATA), for use in aircraft maintenance and operations
de materiel aerospatial (AECMA), along with the American Transport
Association (ATA), for use in aircraft maintenance and operations
manuals.  See Gingras, Becky.  ~Simplified English in Maintenance
Manuals?.  Technical Communication 1Q, 24-28, 1987, for more
details.  AECMA contains about 2600 items (!), but that includes
all technical names and manufacturing processes for the aircraft
industry.  If you are looking for a more "generic" Simplified
English, see Peterson's article in Rubens, Philip.  Science and
Technical Writing: A Manual of Style.  New York: Henry Holt and
Company, 1992.

And this is just the tip of the iceburg.  I hope that I
have made it clear that there are many different "restrictive
grammars", which means that it is up to the person, or company,
who wishes to use some form of controlled English to make
some difficult choices about terminology and writing rules. I
would also suggest that you consult Kirkman's work for a
discussion of the subject of writing for international audiences.

2.2 Why *not* to use restricted grammars

[from E. Winters <ewinters -at- NETCOM -dot- COM>]

These techniques are useful when you KNOW from the start that the information
will never be translated and must be intelligable to all.

[from Chuck Murray <cmurray -at- 4gl -dot- enet -dot- dec -dot- com>]

In my brief experience using a "restricted
grammar" (actually a restricted vocabulary - at NCR Corporation in the
1970s), I didn't enjoy using it, and I concluded it did not advance - and
maybe it even impeded - its stated goals, which included easier and less
costly translation. I'll briefly address my two main points.

  1. Fun - It wasn't fun to use. Like most writers, I of course consider
myself a creative genius, and the restricted vocabulary was stifling
[insert appropriate "emoticon" here...]. Kidding aside, it made the job
less enjoyable, and in several job interviews since then I've made it
a point to ask if the company requires a restricted vocabulary.

  2. Translatability - I heard second-hand that one of NCR's English-to-
Spanish translators said that the restricted vocabulary actually made
translation HARDER, because in many cases it was more difficult to
discern the writer's true meaning. In effect, two levels of "translation"
were now required: the first in the writer's mind, as he or she translated
the idea into phrasing from the restricted word list, and the second when
the translator rendered the English phrasing into Spanish or whatever.

My advice: Be skeptical of claims of benefits from restricted vocabularies,
and don't rely entirely on claims by those with a personal or professional
self-interest in promoting one or another such scheme. Finally, while
restricted vocabularies might be OK for certain types of technical writing
(e.g., tractor operation manuals), I doubt they're a good idea for writing
that involves sophisticated concepts and techniques (even when you're
writing for "unsophisticated" users of such systems or equipment).

2.3 When to use restricted grammars

[from Richard_G_Sobocinski%~WHC207"@CCMAIL.PNL.GOV]

I think the whole idea behind the simplified/restricted
English debate is to accomodate _machine translators_.  I
don't think that there is any doubt that a good _human_
translator is the better choice because of the current
limitations of machine translation.

3. Recommendations

[from Susan Fowler <sfowler -at- ejv -dot- com>]

Translating is NOT a simple matter of putting text in one end and pulling
it out the other. At a minimum, you will need to do post-editing. Best idea
is to pre-edit to standardize the sentence structure and vocabulary of the
source text.

[from Chuck Banks (chuck -at- asl -dot- dl -dot- nec -dot- com)]

        The action we take depends upon the type of customer who
receives our documents.

        For our direct customers in Commonwealth countries, we
internally translate our U.S. English base documents to
British English.  We have a team of British English writers in
our Pacific Basin divisions who do the translations.

        For our OEM customers, it depends upon the contract.  Some
do their own U.S.-to-British translations, some rely upon us
to do it.  Some Commonwealth customers accept American English
documents with no translation.

        Most differences between British and U.S. English
are in vocabulary, semantics, and spelling.  We try to keep
our documents free of idiomatic expressions.  Computer jargon is
treated the same.  British jargon is substitued for U.S. jargon.

[from Jack Shaw <jsh -at- SOFTWARE-AG -dot- DE>]

  1. Try to determine what the target languages will be,
     and talk with an expert/native about

     - active/passive voice,
     - addressed person (2nd/3rd, you/one), which was
       being beaten to a fare-thee-well here a while ago.

  2. Compile a terms/terminology list, with definitions.

[from Carol Odlum <carol -at- dreamer -dot- eyrie -dot- com>]

Be sure the English version is set in concrete before you start the
translation. Your costs will mount astronomically if revisions are
made after the translation has been started.

[from E. Winters <ewinters -at- netcom -dot- com>]

Experience has taught me to think more broadly; suggest
thinking about the totality of the task.  I've used
David Victor (among others) for guidance.

[from Christy Spencer <spencer -at- cs -dot- hh -dot- ab -dot- com>]

Before designing the projects, I surveyed representatives in foreign
countries to find out how their multilingual docs were presented (bound
together vs separat e) and 83% responded that they received separate docs.
So that's the type of do cs I designed...each language as a separte piece
to discard if not needed.  Wast e of money I know...but that was the
preference.

4. Considerations

4.1 General

[from archives]

That's one of the things I do. Localization  (the adaptation of software
to a local market in the global marketplace) is about the cultural
considerations of all aspects of communications.
Color is one of these issues. White is clean to Americans, but is the
color of death to Japanese (Americans have black hearses for a funeral;
Japanese dress in white for a funeral. An American wedding looks like a
funeral procession to a Japanese.)(But American wedding dresses have
penetrated Japan, so it is becoming accepted as a special instance.)

There isn't a complete guide to color for every culture, every instance,
every situation. Just try to describe color just for the American market!
Red is erotic, is the stop sign, is danger, is attention. It depends
on the situation. Now do this for every culture! It's impossible.
For Chinese, red is lucky (which explains the crimson red in Chinese
restaurants).

The best thing to do with a manual is to map out the colors, explain the
intended significance,  and then check with the local distributors (who
MUST be natives, ie. not transplanted American managers) and get their
reactions.

[from Vincent Borghi <vb -at- ediscope -dot- fdn -dot- org>]

Concerning the material aspects, have in mind that many countries
use A4 or A5 paper format, and have 4-rings binders (US legal and letter
ans 3-rings binders are no-no's).

[from E. Winters <ewinters -at- netcom -dot- com>]

There are, of course, many categories of human behavior to
consider in this realm.  Here are a few things to think about --
for openers:

Similarities and Differences in your user group:
Cultural Context
        high or low
Linguistic
        Official language(s) & dialects, Style of Writing, Bi or
        Multi Lingual Population
Technological
        Telephone system, Computer availability, sophistication (1-10)
Educational
        Body of Knowledge, Teaching Style; traditional & modern, Literacy,
Political
        Trade, Legal, Traditions/Symbols
Economic
        Currency, Wealth?, Number Formats
Social
        Etiquette (business/non-formal), Family, Prejudices,
        attitudes toward age/leisure time
Religious
        Food, Colors, Icons, Forbidden behaviors

4.2 Working with translators

[from archives]

Consider having a native speaker write a new manual.  American companies
assume that everyone else thinks the way we do.  fThey don't.  We like an
organization that gets us into procedures quickly, puts reference toward
the back, postpones troubleshooting til much later.  But that is our bias.
We organize the way we live.  But that organization does not work so well
for Japanese or French audiences.

Think about the cultural snobbery involved in our assumption that if we
write a great manual for Americans, it will do for everyone else.
Note:  This is not a question of style.  It has to do with major
developmental questions: what goes where?  What topics get covered first?
OUR decisions seem weird and even perverse to people in other cultures.

So: hire a writer, not a translator!

[from archives]

I think there are major differences in the structure expected by different
cultures.  And once we change the overall organization, we are just about
forcing a complete rewrite, using the
American manual as a set of notes.  Good notes, but just notes.  For
instance, Japanese customers say they expect and like having all kinds of
cautions and warnings dealt with up front, so they can be assured that if
anything goes wrong, it's been dealth with; no American company would ever
do this.  And making the change is more than just grabbing Troubleshooting and
moving it to the front, because instead of being diagnostic, this text,
they say, should be narrative.

More and more, I think the budget reasons for "just translating" coincide
with unstated ethnocentric view that what's good for America is good for
the world.

[from jim grey (jwg -at- acd4 -dot- acd -dot- com)]

Once upon a long ago, I studied and practiced to earn a Certificate for
Technical Translation in German.  The two-year course taught me to
translate technical documents from German into English.  The number 1 thing
drummed into our heads was that we were *not* to alter the author's
message.  The number 2 thing was that our translations were supposed to read
naturally, and not be merely literal.  This makes sense, but its practice was
difficult.

German scientists and engineers write just as poorly as their
english-speaking counterparts.  It's institutional:  German technical
readers have an unspoken *expectation* that technical documents (as
separate from user documentation) are written in a complex, scholarly style.
Very often, a sentence I translated turned into nearly unintelligible
gobbledygook.  I ended up breaking many sentences into several sentences,
rearranging prepositional
phrases into possessives, changing passive to active.  These are the same
kinds of things I do, and I suspect you do as well, when you try to use an
engineer's usage notes in your documents.  I'm just trying to write clear,
direct English, which is what American technical readers presumably want.

Unfortunately, too much of this was considered "rewriting" and probably an
alteration of the author's message.  The course instructors maintained that
the American Translators Association (I think that's what it's called),
frowned deeply on this kind of thing.  The ATA is the translator's
equivalent
to the STC, except I get the impression that without ATA affiliation, a
translator is a nobody.

If this kind of constraint is found worldwide, I wonder how effective
"sanctioned" translations really are.  I'm just one guy against a viewpoint
widely agreed-upon within a group of people who do this stuff for a living,
and am open to being wrong or misunderstanding.

I imagine user documentation is generally a different beast, since much
of it is written for a non-technical audience.  The few software manuals
I looked at when I was in Germany ten years ago (admittedly, before I ever
heard of technical writing as a profession) weren't too hard to read.  But
still, I'd hate to use the product's manual translated into English under
the translation constraint I faced.  The writing would still seem stiff
and stuffy.

As an amusing side note, I just got a new coffee pot, a Krups, made in
Germany.  The instruction booklet has a section on "Descaling and
Potcleaning".
"Potcleaning" is typical German, while we'd say "Cleaning the Pot".
Fortunately, the ATA let us make this kind of substitution.  I bet these
instructions were translated into English by a native German speaker.

[from Jonathan Price <...>]

I know this is not quite answering your questions, but it's something I've
been working on with Japanese customers.  They tend to find even our best
Western manuals a pain in the you know what when directly translated,
particularly when the translator is living in the U.S., and out of touch
with current Japanese, or computer talk in Japan.

From anecdotal evidence, I have come to the conclusion that you ought to
ask a native speaker to do a complete rewrite (not translation) when going
from the U.S. to any Asian country, to the Germanic parts of Europe, and to
France.  Several Dutch studies show that the French expect a top-down
rational explanation of key concepts, then minor concepts, then, almost
incidentally, procedures, while the Germanic group (Holland, Denmark,
Scandinavia, Germany, Austria) expect no-nonsense how-to stuff right off,
and please postpone any conceptual stuff for later in the book.
Think about it as a native speaker of American: even if the manual started
off terrific in Korean, how useful is it going to be to an American who
hasn't finished high school, if we get a direct translation?  As writers,
we should support real writers around the world.  The translators can come
in going from German to Danish, say, or from one dialect of Chinese to
another.  But you need a real writer to make a new manual, to begin with.
(My biased opinion after talking to hundreds of intermediate Japanese
users, who have relied on direct translations of manuals from Apple and
IBM).

[from Christy Spencer <spencer -at- cs -dot- hh -dot- ab -dot- com>]

  1 - They're not "technical" experts for the given country.  For my wiring
guidelines and instructions, it was my job to find out what other countries'
standards were (i.e, how to specify AWG and NEC requirements) and this did
take some digging.

  2 - If anything changed after the document had been sent to the translator
and my company didn't have the compatible software (Ileaf for Japanese), I
had to resend the document with the new changes, wait for the translator to
make those changes, and resend me the document for printing (not good when
deadlines are tight).

  3 - Some translators did not follow the original format - breaking figures
and text in some weird places...and breaking up the document's appearance.
For my next translation, I did stipulate that format was important...and that
resizing of figures was allowed to keep pieces parts together (I'm currently
waiting on these translations...so I don't know about results yet ...).

  4 - It's a struggle to get your team members to realize the importance of
being correct the first time.  Changing product design (i.e, removing a jumper,
redoing a screen) late in the game will affect translations...and thus document
availability.

To make things easier, make sure you allow enough time in your development
for translations.  As soon as someone mentions translations, I immediately
add at least a month, maybe more (this depends on the size of the document
and the speed of the translating company) to my development estimates (and
I do mean estimates!).

[from Gwen Gall <ggall -at- CA -dot- ORACLE -dot- COM>]

Colour (and spelling <wink>) is apparently especially significant in
certain cultures, and is an issue in online documentation development, and
user interface design.

A case in point: I recently worked with a GUI developer from China, who was
quite stubborn (but dearly so--we're good friends), who had trouble
understanding that she shouldn't make her O.K. buttons bright red. She
said, "But red is good, and means good luck and money and things like that,
so they push the O.K. button to make good things happen..."

There are, of course, many other such stories. The point is: maybe we
shouldn't just be looking at translating words, but other things as well,
even as far as how thought processes differ culturally. We may need to
change the the structure and/or presentation order of ideas in a document
to accomodate cultural differences in cognitive processes.

5. Basic, "good" technical writing is the solution

[from Eric <ejray -at- okway -dot- okstate -dot- edu>]


     In my life as a translator I translated operator's manuals
     for a heavy equipment manufacturer from English into German.
     I can say that ease of translation is directly related to
     how well written a given sentence is. In other words, you
     couldn't pay me enough to take a crack at the sentence I
     just wrote. ;-). I don't remember ever having problems
     related to active vs. passive, except that the active voice
     was generally clearer to read (better written).

[from archives]

ejray -at- OKWAY -dot- OKSTATE -dot- EDU said:
>      I am a native speaker of English, and, while I
>      did a good job translating into German, I would never hire a
>      non-native speaker of the target language to translate into
>      the target language.

I think this is a wise rule.

[from Vincent Borghi <vb -at- ediscope -dot- fdn -dot- org>]

To prepare your document for translation, the basic idea is very
simple : ***** make it good ***** !

PS1: This involves for example:
- make your document short (throw away useless text...)
- make it structured
- use homogeneous, uniform, terminology
- consider the reader is intelligent : give fine details only when it
  is necessary (the "step by step" syndrome is boring for the reader;
  here in France, american documentations are sometimes considered as
  laughable, due to the incredible details that are given in instructions)
- of course, forget your cultural background : throw away all
  references to hamburgers, God, white house, feministic debate, and
  so on :-). Think like a stateless person.
- etc.

[from E. Winters <ewinters -at- NETCOM -dot- COM>]

This is a wonderful example of what can happen when
cultural considerations are not part of the original
planning.

Instructional Designing for a particular culture is
critical when you are preparing tutorials.

I frequently suggest that people recall the last time
they were someplace that was disorienting; even a first
roller-coaster experience is an example of what you
feel like when *cognitive dissonance* is a 'norm'.

And - - if you are using color, make sure you haven't chosen
something that has a particular meaning in the target country.

[from Richard_G_Sobocinski%~WHC207"@CCMAIL.PNL.GOV]

I agree with everything up to here.  "Step-by-step" may be
boring to the _reader_, but is very useful to the _user_.
Procedures that are written in step-by-step manner allow a
uniform approach to an operation that may be performed by
many different people.  It also allows you to do away with
some of those fine details and move them to another part of
your structured document where they are more useful (like the
troubleshooting section).

[from Jack Shaw <jsh -at- SOFTWARE-AG -dot- DE>]

[...]use your good, sound, experientially
ingrained judgement and dead reckoning to create the body
of info. that will eventually be translated. Do so, assuming
that the poor translator is a language expert, but a subject
know-nothing. Not that s/he is, but it's a valid assumption.
If the translator asks few subject-oriented questions during
the process, reach around and pat yourself demurely on the
back...

And, my personal slant is, write for kids. I mean, write as
though you were doing it for a short attention span and little
fascination for your topic. Lots of similes, and few abstract
concepts, if you can do it. Another view is, write as though
you were explaining something to that person you met in the
bar in Budapest/Acapulco/Rio/St. Petersburg/wherever that you
were trying to convey something to, and who understood at
best a smattering of your mother tongue. Simple (by definition)
sentences to the point of pain, with occasional complex ones
of few words with subordinating joiners ("Who was that person
THAT I saw you with...", and not "...person I saw you with..."),

Like you would want to be spoken to by a native of Budapest
or Adapulco or Rio or St. Petersburg... . And then there's
the old Rule of Three:

  1. Tell 'em what you're going to tell 'em.

  2. Tell 'em.

  3. Tell 'em what you've told 'em.

[from Christy Spencer <spencer -at- cs -dot- hh -dot- ab -dot- com>]

I have not played with restricted grammars but I have completed a couple of
docu ments that have been translated into other languages (Japanese, German,
French, Spanish and Italian).  These documents were shipped with the product
in all six languages so I was prepared while designing my docs.  I focused
on reducing word count and increasing graphics.

[from Heli Roosild <HeliR -at- MSMAILHQ -dot- NETIMAGE -dot- COM>]

An earlier employer of mine had a separate translation group  in the UK.
Many of the pointers they gave us for writing with translation in mind were
simply part of good writing in general--for example, do not use more than
one term to refer to the same thing, and avoid noun strings.  I
particularly remember that translators from English prefer structurally
explicit sentences rather than elliptical ones.  What I mean is, they
preferred
something like

     The boy who is wearing the blue coat that has a lace collar ...

to the (for me) simpler

     The boy wearing the blue coat with a lace collar.

[A primitive example, I know. (:-)]

English is wonderfully able to collapse grammatical structures and still
convey the correct meaning, at least to native speakers.  To the rest of
the world, however, the results are often ambiguous and a pain to translate.