Getting the Source Text Right with John Kohl’s Global English Style Guide

Editor’s Note: This article is an interview with John Kohl, the author of The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market. John has been working at SAS Institute as a technical writer, technical editor, and linguistic engineer since 1992. His book is available from SAS Press(external link) and from many online booksellers. John will be presenting on this topic at the October 2008 membership meeting of the Technical Editing SIG, and we wanted to whet your appetite with this interview for attending our meeting!

Source text

What central problem does your book, The Global English Style Guide, address?
The need to communicate clearly to a global audience—an audience that includes non-native speakers of English, translators, and perhaps also machine-translation software, as well as native speakers. The Global English guidelines are based on empirical research, and the book provides much more detailed explanations of these guidelines than can be found in any other single source.

What was your motivation for writing your book?
I’ve studied foreign languages (German, French, Russian, and Spanish) and have taught English to non-native speakers. As a result, I have a lot of empathy and understanding for people who are reading in what, for them, is a foreign or second language. I understand how much of a difference the style and vocabulary in a document can make to a non-native speaker’s ability to comprehend the material.

I’m also very sensitive to the types of ambiguities that leave translators scratching their heads. Translation is more efficient and more accurate when the English source texts are written clearly and simply.

What made you decide to publish these guidelines?
I really did not want to put the time and effort into writing this book, so for 15 years I waited, thinking that surely someone else would write it (or a book like it). In the meantime, I was speaking about Global English at various conferences and offering workshops at SAS and for a few other companies. I could see that there was a lot of interest in the topic and a need for an example-driven book that covered the topic thoroughly.

When I finally decided that I should write the book, I was pleasantly surprised that SAS Press was interested in publishing it. It’s the first book they have published that does not pertain specifically to SAS software or to software-related topics. The opportunity to work with them instead of with an outside publisher made the prospect of writing and publishing the book less daunting. I don’t know if I’d have written it if I had had to seek an outside publisher.

What features of the book especially pleased you?
I’m happy that I was able to cover the topic as thoroughly as I did. Some authors on the topic of writing for international audiences have done little more than admonish authors to “write clearly.” That advice is not very helpful! Writers and editors need specific guidelines that help them recognize ambiguities and other unnecessary impediments to the translation process. And they need enough of an explanation and enough examples that they can actually understand and apply those guidelines. I’ve done my best to meet those requirements in this book.

What is your most significant finding?
I think my most substantial contribution has been my research on syntactic cues—the little function words (usually “closed class” words such as pronouns, prepositions, auxiliary verbs, and so on) that many writers and editors have been taught to eliminate, but which are often essential for eliminating ambiguities and for improving readability. I’ve done a very thorough job of identifying and explaining the contexts in which these syntactic cues add clarity and improve translatability.

Doesn’t the use of syntactic cues increase the word count, leading to increased translation costs?
Not necessarily. In my book, I emphasize that authors and editors should think about content reduction at the same time that they are applying the Global English guidelines. In my own writing and editing, I find that I eliminate at least as many words as I insert, even when I am focusing only on sentences and paragraphs and not looking for entire topics that could be eliminated. So in the end, there is an overall decrease in localizable content.

Even if that were not the case, clarity and disambiguation are essential for producing quality translation. If you sacrifice clarity by eliminating syntactic cues, you might increase localization costs by forcing translators to seek clarification on unclear phrases and terminology. In addition, your risk of having incorrectly translated information in your deliverables increases, with potentially disastrous and expensive consequences.

What role does language technology play in this process?
As I was writing the book, acrocheck™ software was an invaluable research tool for collecting and analyzing examples of linguistic patterns. We are also using acrocheck at SAS to help our writers and editors follow our terminology guidelines and style guidelines, including many of the Global English guidelines. I’m an absolute believer that this type of technology should be used more widely. No writer or editor can keep extensive style guidelines and preferred terminology lists in mind while working on a document. Software such as acrocheck is far more efficient for this. Our writers and editors follow our guidelines much more consistently than they could if they had to look up rules or terminology lists online or on paper.

What kind of metrics have you used to quantify the benefits of using language technology or of following the Global English guidelines?
We have not found a need to try to measure the benefits of using acrocheck or of following the Global English guidelines. For anyone who uses this type of language technology and who reads the guidelines and examples in my book, the benefits are intuitively obvious. Everyone in our Documentation Division recognizes the importance of our guidelines, and our writers and editors are happy to have a tool that helps them follow those guidelines.

The documentation process is more efficient because writers fix many of the errors in their documents before turning those documents over to editors. Editors can focus more on content reduction and on other issues that decrease costs and that add greater value to our documentation.

Your book includes 49 major style guidelines, plus dozens of other guidelines for punctuation, capitalization, and terminology. If you had to narrow those down to only ONE, what would be the most important guideline you’d like to see companies use in their authoring?
The in-house translators at SAS once told me that “Limit the length of sentences” was the most important guideline. That guideline is certainly important, but not all long sentences are difficult to translate. So, personally, my favorite guideline is “Make each sentence syntactically and semantically complete.” The book contains several more-specific guidelines about how to do that, but here is one example:

Not Global English:
Space is tracked and reused according to the REUSE value when the file was created, not when you add and delete records.
Global English:
Space is tracked and reused according to the REUSE value that was in effect when the file was created, not according to the REUSE value that is in effect when you add and delete records.

In order to translate the first version of the sentence, a translator has to read between the lines and has to have a very good understanding of the context and subject matter. The translator essentially has to rewrite the sentence as I did in the revised version, supplying the missing content, in order to translate it. Translators should not have to compensate for authors who don’t express their ideas completely!

Thanks, John!

More Than Grammar: Expectations of Technical Editing New Hires

Shelley Thomas

As an academic who teaches technical editing to undergraduates, I wanted to know what employers’ expectations are for their new hires. In September, I asked the discussion list: “What would you expect from a new hire who has completed a technical editing course (beyond being well-versed in grammar, mechanics, and punctuation)?”

I received 18 responses to my question, and the range of issues raised by the listserv participants surprised me. While some of the responses stressed knowledge of the basics (strong knowledge of grammar, punctuation, and style guides), other responses were less focused on editing mechanics, concentrating instead on adept interpersonal skills and familiarity with various technologies. The technical editor’s responsibilities extend beyond grammar checking; the editor must be able to ensure consistency, logical structure, completeness, usability, and effective communication among all parties.

Grammar and Mechanics

While any company should be able to safely assume that a new technical editor would have a solid command of grammar, punctuation, usage, and mechanics, this is not always the case. Several respondents emphasized that this basic knowledge, which I assumed applicants would possess, was lacking. One respondent, Candy Jenkins, said, “I don’t believe enough emphasis is stressed on grammar and mechanics in institutions of higher learning, so having a good foundation in that is important.” Many companies use editing tests to ensure that their applicants have this most basic editing knowledge.

Style Guide

New editors must be familiar with standard proofreading marks and be experienced with using more than one style guide, especially the more widely used guides such as APA, Chicago, and AP. Because editors are divided regarding the use of soft copy and hard copy edits (see “Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy,” Corrigo, July 2007), editors continue to use proofreading symbols and authors rely on a standardization of these symbols to understand the edits. With the knowledge of various style guides comes an ability to create and maintain an in-house style guide (or a document-specific style sheet) to promote consistency. Furthermore, new editors must acquaint themselves with whatever style guide the company uses. Virginia Janzig remarked, “The editor needs to find out what style guide is used and then use it even if the editor doesn’t agree with some of the guidelines.” This knowledge allows the editor to edit with confidence by referencing a standard to support edits and make only necessary changes.

Interpersonal Skills

Editors must be able to adeptly defend their edits across many levels of an organization’s hierarchy. Their edits must be based on sound reasoning (or a notation in a style guide) and readability (as defined by the user or audience). To do this successfully, a new editor must make intelligent edits, write helpful and respectful queries, and persuasively communicate the changes to the author(s). These skills allow the editor to assist the author and to advocate for the user without projecting an “I-just-got-my-degree-and-know-it-all” attitude. When a new editor explains her edits to an author, she must do so with tact. And, according to Jennifer Coury, “[Editors] should always be able to gracefully explain [their] edits (either by e-mail or on in person).” Not only should effective editors be able to write clear queries within the document, they should also be able to discuss the emendations with the author through e-mail, in person, or on the phone.

Teamwork

While many technical writers and editors wish they could work alone, it just isn’t so. “Gone are the days when the editor sits alone in a corner, rarely to be approached except in times of grammar crises,” wrote Catherine Rudiger. New editors, especially, must integrate themselves into whatever project, big or small, they need to accomplish. This element requires, as Stephanie Weiss explains, “teamwork, flexibility, follow-through, and project management skills.” All too often, junior employees defer to their more senior colleagues. A successful technical editor, regardless of rank, must communicate clearly to writers of all skill levels and not be intimidated by a person’s degree or seniority. Good communication allows consistent editing of documents across organizational lines and document versions.

Documentation consistency requires an editor to look beyond sentence-level edits to examine page design, template use, layout, and font. With this editing task, a new hire must refer to a style guide or documentation guidelines to maintain the organization’s “look and feel” for documents, whether delivered in e-versions or in hard copy.

Technology

New hires must be familiar with various technologies: Web, content management systems (CMSs), advanced features of word processing, XML/DITA, and FrameMaker, to name only a few. As Jim Purcell wrote, “Nothing irritates writers more than editors who know language but have no idea about technology.” A familiarity with technology allows a new hire to acclimate quickly to a new position without extensive (and expensive) training. With the job market growing ever tighter, new employees in technical writing and editing must demonstrate complex skill sets. This includes, as Christina Bottomley emphasized, “the ability to upload docs to a website, learn a CMS, follow a style guide, and update changes in multiple docs.” An interest in technology helps new hires investigate editing options and delivery methods. It also and keeps them on the cutting edge of software packages.

Translation

In the global economy, technical writers and editors must prepare for their documents to be translated into other languages. With this in mind, an editor must be able to “meet the challenges of creating documents that will be translated” and understand “strategies for keeping translation costs low,” according to Julie Kumasaka. This editing skill involves an eye for consistency in usage and terminology, avoidance of jargon and idioms, and clarity of expression. In addition, a new editor may have to justify these types of edits to an author persuasively and confidently. Furthermore, knowledge of another language aids in the task of translation and deepens an editor’s understanding of English usage.

Conclusion

As I have researched undergraduate technical editing courses across the country, I have found that many address the issues expressed in this discussion This discussion opened my eyes to the complex nature of technical editing and created an avenue for more effective instruction. The editor is ultimately responsible for ensuring the author’s message seamlessly reaches its audience. At times, educators become removed from the work world, and we (educators) need to update our skill set and corporate knowledge. From the detailed comments I received, educators cannot take anything for granted when it comes to preparing undergraduates for “the real world.”

 

Minutes from Our Business Meeting at the Conference

Virginia Janzig

The business meeting of the STC Technical Editing Special Interest Group (TE SIG) was called to order by Pat Moell on 3 June 2008, at 7:30 a.m., in the Philadelphia Marriott Downtown Hotel.
Pat recognized members of the board who were present. She also noted that the Distinguished Service Award was going to be presented to Diane Feldman at the 55th Annual STC Technical Communication Summit recognition banquet that evening.

Pat identified SIG accomplishments and areas of direction for the SIG:
• Bylaws, budget, and strategy
• Job listing aids
• Continue to hold annual elections (first election held October 2007)
• Provide 2 scholarships yearly
• Continue quarterly membership meetings
• Improve Web site

Pat asked each attendee to introduce themselves and identify what the TE SIG is doing that is worthwhile and identify things that might be offered to the membership.

SIG suggestions
• Continue quarterly meeting topics
• Consider repeating popular topics
• Discussion list is useful
• Opportunity to meet people
• Sense of community, validation of work and career
• Love of language (St. Bernadette’s Barking Dog)
• Change time of meeting once a year to accommodate other time zones
• Job bank, specific editing opportunities, possible link to LinkedIn?

Style guides and other resources
• Style manual in a wiki
• Consolidating style guides
• Need strong knowledgebase
• List of style manuals
• Open source style guide. Sun is driving this. SIG needs to be heavily involved.
• Automate process for updating style guides.
• Common ground for international style guide: international companies using one language with writers and editors from many languages and cultures.
• Terminology – AP, Chicago Manual of Style, IEEE, software, writing (content management)

Editing – types, different ways to do it, skills
• Types of editing: journalism, technical, peer (peer review), small groups, international groups, group editing, content versus context
• Differentiate writing and editing
• Writer-to-editor ratios – how to handle, what to edit
• Expanding editing skills to provide value, protect job
• Editors who do other things – how to juggle different jobs
• Collaborating with writers, subject matter experts, building relationships, lessons learned
• Editing engineers and other highly technical subject matter experts – approaches

Management stuff
• Getting STC into large companies (possible?)
• Getting STC out to more lone writers
• Metrics for management, ROI, prove the value of editing to management.

The meeting was adjourned at 8:35am.

 

Impressions of STC’s 55th Annual Conference

Pat Moell

I enjoyed meeting so many Technical Editing SIG members at the STC Conference in Philadelphia in early June. Thanks to all of you who volunteered to work at our table at the Welcome Reception, to facilitate the editing discussions at the SIG luncheon, and to present at our Technical Editing SIG Progression, “Editing Influences across Technical Communication.”

I was thrilled to see such great attendance at our annual breakfast meeting on Tuesday, June 3. Thank you for arising early enough to attend a 7:30 a.m. meeting. You all had great ideas for activities our SIG could be doing. We’ll be working on a strategic plan that will incorporate some of these ideas to work on over the next two years.

Leadership Day was informative and inspiring. Some characteristics of an exemplary leader are to model the way (do what you say you will do), inspire a shared vision, challenge the process, enable others to act and strengthen them, and encourage and respect others.

The quality of all the presentations I attended this year was very high. There were many good sessions for technical editors to learn more about their craft.

One general trend that I noticed was expressed succinctly by Andrea Ames: “Think more! Write less!” This trend toward minimalism was well represented by the session, “Editing Modular Documentation: Some Best Practices,” by Michelle Corbin and Yoel Strimling. If you follow their rules for chunking, labeling, and linking and follow their best practices, you will find that you have clear, simple topics that users can easily understand.

Another trend was expressed well by our keynote speaker, Howard Rheingold, the author of Smart Mobs; he spoke of the power of social networking through the use of our modern technologies to change history, our businesses, our government, and our lives.

If you are interested, the session materials are available as a link from the http://www.stc.org(external link) site.

I hope to see you next year in Atlanta.

Who Are We? What Should STC Be?

Mike Hughes

I am Mike Hughes, and I am running for Second VP for the Society for Technical Communication. In this article I tell you a little about me and my vision for our profession.

Who am I?

I am a Society Fellow currently on the editorial advisory board for Technical Communication and the Ken Rainey Excellence in Research award committee. I chaired the subcommittee on Research at the STC Academic-Industry Leaders Summit in 2007, and I was organizer and leader for the Sharing Corporate Knowledge Institute at the Summit Conference in 2007. I am also currently filling an interim director position on the board. In my day job, I am a user assistance architect for IBM. I have a master’s degree in Technical Communication and a PhD in Instructional Technology, and I am a Certified Performance Technologist through the International Society for Performance Improvement.

Who are we?

Technical communication is a diversified profession, one that supports multiple career paths and roles. Whether we call ourselves technical writers, information developers, instructional designers, content managers, or whatever, we improve the user technology experience by providing information that eases and enhances that experience.

When our profession was initially emerging, we stated our value in terms of the correctness and completeness of our documents and the clarity of the language in those documents. Then, as we matured, we started defining our value in terms of how we benefited our end users. And now we are taking our value proposition to yet a higher level: how we support the missions and objectives of the organizations that employ us. This means that our value can’t stop at the quality of the communications we produce; it must extend to the effectiveness of the actions they enable, and beyond that, to how the improved effectiveness of our users benefits our sponsors. The list is long, but these are just a few:

  • Increased customer adoption (because new products and services are easier to install and use)
  • Reduced support costs (because product owners can maintain their own products better)
  • Lower medical costs (due to better patient compliance with medicines and procedures)
  • Improved product quality and reduced production costs (because workers can comply with best practices that are easily understood)
  • Increased customer loyalty (because the web sites and other communication channels we create build communities of common value and interests)

 

What should STC be?

If those are some of the things we are about, what should the role of STC be?

  • Provide professional development programs in the core body of knowledge that defines us as a profession
  • Show leadership and provide education in the emerging tools and technologies that direct our future as a profession
  • Serve as our advocate within government and industry to articulate our contributions and needs as a profession

We have invested a lot of our society energy and resources over the last several years in improving the structure and governance of STC. I think we can quit reinventing ourselves now and put our new structure to work. We need to shift our focus outward again and ensure that as members we are getting full value for our dues. My main focus as an officer will be the following:

  • Maintain a balanced budget that funds the programs that add the most value for members
  • Ensure that our publications and conferences provide the content that helps members do their jobs
  • Create a collaboration where members, vendors, employers, and academic communities help technical communicators keep up with the ever-changing demands for tools and technology knowledge
  • Support a certification program through STC that helps our sponsors trust and understand our value and that creates sustainable careers for technical communicators.

Please visit my website at http://www.mindspring.com/~mikehughes/index.htm(external link) to get more information on my background or read some of my published papers. Go to my blog at http://user-assistance.blogspot.com(external link) and click the STC label to read more about my positions and thoughts on specific topics related to my candidacy.