Top 3 reasons to do a language edit

There are several good reasons to do a language edit and most have to do with the overall quality and usability of your documentation. That’s the lesson I learned while editing our upcoming Release Notes for language.

The language edit is the unloved stepchild of the tech writing process: It is frequently last in line and gets less attention than the actual writing and the content review. Yet it really impacts the quality of the documentation, precisely because it occurs so close to publication. Here are three benefits of a language edit.

Correct, clear and consistent language

The most obvious benefit is to ensure that the language in the document is correct, clear and consistent. This is why you do it in the first place. And it is especially important if the documentation is written by several authors. Even if you have a really good and detailed style guide, you’re bound to get different ways to interpret it – to put it benevolently… 🙂

Ensuring clear language requires a language editor who is well-versed in the subject – but not so steeped in it as subject-matter experts (SMEs) who may review content who often have too much of an insider’s view and won’t spot potential misunderstandings. (Many SMEs are also uncomfortable with reviewing language, either because they lack the skills or because it distracts them from the review they should be doing.)

Ensuring consistent language requires an editor who reads across the complete document – instead of distributed authors and reviewers who work on a chapter each. Most chapters I encountered had their distinct style, but the differences between chapters couldn’t have been greater if they had been in entirely different documents. This seems to be a stylistic issue at first, but it spills over into the other two reasons for a language edit, so follow me on to the next item which is…

Consistent structure

Our standard operating procedure for writing Release Notes contains a standard structure which each entry should follow. Essentially, it looks like this:

• Summary of enhanced or new feature
• User benefit of feature
• Prerequisites of feature
• How to use feature
• Results and next steps of feature

Depending on the scope of an enhancement, some of these structural elements per entry are optional. A new menu option may be self-explanatory enough, so we don’t need to point out the user benefit, and there are no special prerequisites. The whole entry may be but two sentences long.

However, it is a matter of judgment how many details and customer guidance we want to provide. For a team of distributed authors, this is almost impossible to agree upon before hand. A language editor can help to ensure consistent structure. This may require consulting with the author about missing structural elements, but if they’re quick to respond, it is well worth the effort.

Raising documentation standards and value

While you are talking with authors about missing elements, this is a good chance to offer feedback about recurring issues. I’ve noticed that some authors have their “favorite” mistakes. One has missed a guideline in the style guide and keeps repeating the same small mistake. Another may have a larger misunderstanding, whether it’s about topic types, the use of personas, etc.

The language editor not merely improves a document, but in the process also performs a thorough audit of current documentation practices. So she or he can help to ensure adherence to documentation standards and raise the value of the documentation you publish. A language edit is often the last chance to ensure your final document feels and works as it should and lives up to your corporate and documentation standards. Omit it at your own peril.

For more about editing, see my earlier post “Editing for tech writers“.

– Do you do language edits? What benefits do you get from them? Which shortcomings made you wish you had done one? Please leave a comment.

Advertisement