By Serena Beck, Membership Manager

As an author of many internal style guides, I can appreciate the amount of effort and time required to create a style guide and ensure it’s followed. I have a good eye for detail and enjoy making the documentation I write consistent. I’ve been a technical writer for 11 years, but this is the first year I’ve written manuals for translation. I had many questions about how to write for translation and what styles I should use. One of my colleagues recommended that I read John R. Kohl’s The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market.

I read and flagged many pages in Kohl’s Style Guide and I often reference these flags when I have questions or need assistance. Kohl created an amazing style guide and has the background required for writing a book of this magnitude. He has worked as a technical writer, editor, and linguistic engineer. His most important rule is to use common sense. He says “Don’t make any change that will sound unnatural to native speakers of English” (page 4). He adds “There is almost always a natural-sounding alternative if you are creative enough (and if you have enough time) to find it!” (page 5).

Kohl does an excellent job explaining the syntactic cues, punctuation, and capitalization you should consider when writing documentation for translation. Each rule is prioritized as high, medium, or low priority for human translation, machine translation, and non-native speakers. He explains a guideline and provides detailed correct and incorrect sentences to demonstrate that guideline. Flowcharts are used to help you make tough style decisions. My favourite is the “Flowchart for Clarifying Prepositional Phrase Modification” (page 79). This flowchart helps you determine if a prepositional phrase is in the correct location in a sentence.

One of the rules that really opened my eyes was that sometimes you need to use more words for clarity. For example, “There are two types of files: locked and unlocked” (page 167). Kohl states that “the French translation for locked and unlocked are slightly different depending on whether the noun they modify is masculine or feminine” (page 167). Therefore, when using machine-translation software, you would not want to use the above sentence. Instead, repeat the noun ‘files’ as shown in this sentence: “There are two types of files: locked files and unlocked files” (page 167).

As with all writing, it is important to be consistent, especially when two different styles are acceptable. For example, if a sentence is repeated in a manual and the series comma is used in the first instance but none of the other instances of the same sentence, this is considered a “fuzzy match” for the translation memory software (page 164). It takes extra time and money for a translator to interpret two sentences that are the same except for punctuation.

Another way to save money is to have fewer words to translate. Kohl suggests that one way of doing this is to eliminate software messages and omit dialog box and window names from manuals. I think that this is also a great way to save a writer time and create minimalist documentation – documenting more difficult software tasks instead of every single message, screen, and task that can be performed by a type of software.

Since reading Kohl’s guidelines, I have modified our internal style guides. I make style choices that are dependent on the type of translation – machine or human – and how to write for a global audience. His tips also help guide my punctuation and preposition choices. His book is a great addition to any writer’s style guide bookshelf.