Re: writing for non-native speakers of English

[John Kohl <sasjqk -at- UNX -dot- SAS -dot- COM>]

In article <01INFVMDNNNQBHA82I -at- ADONIS -dot- OSTI -dot- GOV>, Michele_Berkes -at- ccmail -dot- osti -dot- gov
writes:
|> Fellow techwhirlers,
|>
|> I am looking for information about writing for non-native speakers of
|> English. ...
|>
|>
|> I have come across other issues, though, on which I have not found any
|> guidance. My instincts on many of these issues vary from those of my
|> supervisor. (Her style is very tight, but I worry that it may be too
|> dense, perhaps not enough bite-sized phrases. Mine, on the other hand,
|> tends to run on, which I'm acutely aware of.)

I'm not sure what you mean by a "tight" style, but if you mean a style
in which the writer/editor eliminates all of the little "function words"
that help readers (including native speakers as well as non-native
speakers) quickly recognize grammatical relationships between parts of
sentences, then that is definitely the wrong way to go.  I have done a
lot of research in the reading process (and I have an M.A. in Teaching
English as a Second Language), and readers (both native and non-native)
rely heavily on these "syntactic cues" to facilitate reading.

See the following for more information:

Kohl, John R. "Improving Translatability and Readability with
Syntactic Cues" in _Proceedings of the 39th International Technical
Communication Conference_.  Washington, DC: Society for Technical
Communication, 1992.

|> Is there *a* way to write that would be easier to understand for all?

No, there is not "a" way.  There are many sources of potential ambiguity
in English.  I've compiled a detailed discussion of most of them, along
with hundreds and hundreds of examples, but unfortunately I have not
found time to put them into a publishable form. (Maybe some day--if my
employer will allow me to use examples from our docs!)

In any case, I have found that you cannot simply give writers a set of
guidelines for using syntactic cues or for detecting and resolving
potential ambiguities and expect them to be able to implement those
guidelines.  Quite a bit of training, following by individual feedback,
is required.  I'm not convinced that companies (including my own
employer) are willing to invest in thorough, EFFECTIVE training for
writing for international audiences.  (I've done some "syntactic cues"
training, for my employer and at STC conferences, but that is really
just the tip of the iceberg.)

So about the best you can do, in the absence of such training, is follow
the more general guidelines for clear writing that are found in tech
writing textbooks.  There is very little good information available re:
sentence-level guidelines for writing for international audiences.
(However, there is a lot of bad information out there--overgeneralities
and misconceptions that have been propagated until they have
unfortunately reached the status of "conventional wisdom.")

|> (The more I think about it, the more I doubt that *a way* is
|> possible.) For example, it seems possible that a native German speaker
|> would be comfortable with long strings of nouns, whereas a French
|> speaker might prefer strings of prepositional phrases. And I have no
|> idea what the structures and syntax would be for Japanese or Korean.
|> Here's an example from a piece I'm working on today (for our
|> newsletter):
|>
|>   Option 1: worked in the United States as a research fellow at the
|>   Chemistry Department of Stanford University, California
|>
|>   Option 2: worked in the United States as a research fellow in
|>   Stanford University's Chemistry Department in California.
|>
|> I'm not sure that example fully captures the distinction I'm trying to
|> make, but it's the one that got me started on this message ;-)
|>

Option 1 sounds more natural to me, but in other contexts, using an
apostrophe to indicate possession would certainly be natural and
acceptable (as I said in another post).

|> Another example:
|>
|>   Option 1: in charge of developing, managing, and producing databases
|>
|>   Option 2: in charge of the development, management, and production
|>   of databases
|>
|> I like the first option here, but in light of the comments of John
|> Humpert regarding the potential for misunderstanding gerunds, perhaps
|> the second would be clearer?

Non-native speakers of English who are not fluent ARE often confused by
"-ing words" because these words can fill so many different grammatical
roles in English.  However, I don't think you should avoid using them
unless a) there is a genuine potential for ambiguity, or b) there is an
easy alternative that sounds natural to native speakers.

For example, here is an excerpt from my "syntactic cues" materials.
(Sorry, I can't give you the whole thing because my employer holds the
copyright, and I don't have permission.)

[beginning of excerpt]

3. Look for present participles (verb forms that end
   in -ING) such as corresponding, describing, and
   using.

  a. If the -ING word follows a verb such as begin,
     start, or continue that can take an infinitive
     complement, then consider changing the -ING
     word to an infinitive.

     Rationale: In English, -ING words (present
     participles) can represent many different
     parts of speech and grammatical constructions.
     Therefore, they are inherently confusing to
     many non-native speakers of English. It is
     best to either add syntactic cues to them (to
     make them utterly unambiguous) or to eliminate
     them altogether when it is possible to do so.

      * XYZ continues processing program statements
        after it repairs the data set. --> XYZ
        continues to process program statements.. ..

  b. If the -ING word follows and modifies a noun,
     then always either expand it into a relative
     clause or find some other way of eliminating
     it.

     Rationale: In this environment, it is often
     possible that the -ING word is modifying a
     previous clause rather than the preceding
     noun. An MT system cannot reliably determine
     the correct interpretation. As noted above, it
     is best to avoid potentially ambiguous -ING
     words, and in this context it is usually very
     easy either to expand the -ING word into a
     relative clause or to find some other suitable
     modification.

      * Conclude the terminal description with
        comment lines to explain the capabilities
        [that are] being defined.

      * The relationships among data items are
        expressed by tables consisting (--> that
        consist) of columns and rows.

  c. If the -ING word follows a temporal
     conjunction such as when, while, before, or
     after, then make sure that the subject of the
     superordinate or main clause is also the
     implied subject of the -ING word.

     Rationale: This is a rule of English grammar,
     and an MT system cannot be expected to handle
     violations of English grammar correctly.
     Moreover, violating this rule lowers the
     quality of our documentation in the minds of
     language-sensitive readers.

      * When registering a control-window class, you
        must specify how many window words will be
        associated with that class. (correct,
        because the subject of the main clause,
        ``you,'' is also the implied subject of
        ``registering'')

      * When running ABC in noninteractive mode,
        more serious errors may cause the system to
        enter syntax-check mode. (incorrect, because
        ``errors'' is not the implied subject of
        ``running'') --> When you run ABC in
        noninteractive mode, .. ..

      * If an error occurs while creating or
        updating a file, the system can recover the
        file and repair some of the damage.
        (incorrect, because ``error'' is not the
        implied subject of ``creating'') --> If an
        error occurs while you are creating or
        updating a file, .. ..

  d. If the -ING word using occurs at the beginning
     of a sentence, then leave it alone.

     Rationale: In my experience, writers virtually
     always use ``using'' correctly in this
     context.

      * Using the Key Definitions, [you] define the
        key mappings that you want to use for your
        sessions. (the implied subject of the
        main clause, ``you,'' is also the implied
        subject of ``Using'')

  e. If the -ING word using introduces a
     participial phrase but is NOT at the beginning
     of a sentence, then either eliminate it or
     clarify it.

     Rationale: In my experience, writers virtually
     always use ``using'' incorrectly or
     ambiguously in this context. As with other
     -ING verbs in other contexts (see step 3c),
     the implied subject of ``using'' must be the
     same as the subject of the superordinate or
     main clause. Moreover, when ``using'' follows
     a noun, it is usually unclear (from an MT
     perspective) whether it modifies the noun or a
     preceding clause.

      * These same translations can also be defined
        using the Key Definitions dialog windows.
        (incorrect, because the subject of the main
        clause, ``translations,'' is not the implied
        subject of ``using'') --> You can define
        these same translations by using the Key
        Definitions dialog windows.

      * The svc_getcaller function returns the
        network address of the caller using an
        ``xprt'' handler. (It is unclear whether
        ``using'' modifies ``caller' or the
        preceding clause.) --> The svc_getcaller
        functions uses an ``xprt'' handler to return
        the network address of the caller. (emphasis
        is slightly different, but is probably
        acceptable)

      * You can also invoke the REG procedure using
        options. (Does the writer mean ``by using
        options''? Probably what he or she means is
        ``When you invoke the REG procedure, you can
        also specify options.'' This simply
        illustrates the confused thinking that this
        ``using'' construction often reflects!)

  f. If an -ING word is acting as an adjective
     (occurring before a noun), then consider
     whether it could be mistaken for a gerund
     (acting as a noun), or vice-versa. If so,
     revise the sentence or phrase.

      * Next, write and test the code for refreshing
        warehouse data. --> Next, write and test the
        code that refreshes the warehouse data.

      * Auditing Data (as a heading) [Does this
        describe data that were collected during an
        audit, or could it be a task-oriented
        heading for a section that describes how to
        audit data?]

  g. Don't worry about any -ING word that:

     i. is not derived by adding the suffix -ING to
        a verb -- e.g., during, spring, wing

    ii. is preceded by a preposition

        o For more information about referencing
          external files, see Chapter 3.

   iii. ends in -s

        o The correct settings for the latitudes
          and longitudes of major U.S. cities are
          listed in Appendix 1.

    iv. is preceded by any form of the verb ``to
        be'' (e.g., is, are, was, were, has been,
        have been)

        o If you are using batch mode, an error
          message appears in the SAS log.

     v. is the subject of a clause or sentence or is
        otherwise acting as a noun (gerund)

        o Specifying the ALTER password gives you
          ``read'' and ``write' access.

    vi. introduces a participial clause (except when
        the -ING word is using--See 3e).

        o The second argument has been set to NULL,
          indicating that the future amount is to
          be calculated.

     Rationale: In many of the above contexts, the
     -ING word is unambiguous because other
     syntactic cues are present. In the other
     contexts, there is no alternative to using the
     -ING word.


[end of excerpt]

As you can see, it gets kind of complicated!  (BTW, "MT" above means
"machine translation.")   But writers can learn the system if they have
enough practice and if they get one-on-one feedback in response to their
own writing samples later on.


|> Has anyone tried
|> simplified English? Was it useful?

Simplified English is feasible only if you are writing about simple
mechanisms or simple procedures.  E.g., Kodak uses it for camera-repair
instructions, and Caterpillar uses it for operating instructions for its
heavy equipment.  You certainly couldn't use it to document computer
software, though you could apply its principles to a certain extent,
such as standardizing terminology and avoiding unnecessarily complex
sentence structures.

Regards,

John Kohl
editor

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html