Coding passive voice detection

Home/Coding, Grammar/Coding passive voice detection

Coding passive voice detection

Several years back, my colleague Ben and I developed a Chrome extension for editorial quality assurance. Ben provided the actual coding ability, and I was there to try and define the logic for the various rules we were trying to detect. We started with relatively simple checks, like preferred words, or preferred spelling or capitalisation, checks for heading and link length, and some basic metadata checks, but then we thought, ‘it’d be cool if this could detect passive voice’…

So, how did we do it?

There are easier ways of explaining passive voice, but not in a way that can be easily replicated in JavaScript… So we had to bite in to the grammatical structure.

Consider the passive voice below:

The story was written by Kermit.

The bold bit was the key to being able to detect it. This pattern looks like:

Auxiliary verb + Past participle

[An auxiliary verb is a verb used just to carry the tense; it’s not your traditional ‘action’ word. The past participle is… Well, here’s an example: Today I eat. Yesterday I ate. I have eaten. Eaten is the past participle.]

So to detect this form with JavaScript, we just needed lists of all possible auxiliary verbs, and all past participles…

Auxiliary verbs

  • was
  • were
  • has been
  • will be
  • should be
  • can be
  • can not be
  • can’t be
  • could be
  • couldn’t be
  • could not be
  • must be
  • must not be
  • mustn’t be
  • was not
  • wasn’t
  • were not
  • has not been
  • will not be
  • shouldn’t be

I’m probably forgetting a few, but that’s most of them, as far as we’re likely to need. As we weren’t using any fuzzy matching, the contraction forms (e.g. wasn’t) needed to be called out specifically.

For the past participles, we used the hundred most common verbs in English, plus a bunch of of ones common to government… Things like ‘implemented’ and ‘delivered’.

Ben incanted the sacred words while facing east and sacrificing a chicken to the gods of jQuery, and hurrah, we were away. It worked brilliantly. When passive voice was detected, it would be highlighted yellow in the page, with the font changed to fuchsia Comic Sans, making it so jarring that the author had to consider whether passive voice was appropriate for that particular situation.

And people who couldn’t grasp passive voice thought that it was voodoo.

By | 2017-05-19T08:20:54+00:00 March 16th, 2015|Coding, Grammar|6 Comments

About the Author:

Writer, editor, musician, plain English evangelist, content ninja for hire, and general web guy, Rory does lots of things, when he has time...

6 Comments

  1. Ben Boyle March 16, 2015 at 11.00pm - Reply

    Good times! We should publish those tests, I’ll look into that today 🙂

  2. Phillip Lincoln March 17, 2015 at 2.38am - Reply

    You two are a couple of web savants. The people thank you.

  3. Ben Boyle March 17, 2015 at 6.40am - Reply
  4. Sharon L March 17, 2015 at 8.40am - Reply

    Agree with Phil! How can we get the tool?

  5. Rory March 18, 2015 at 12.30am - Reply

    If you’re still with QG, you can get access from the online services team or editorial team at the place I used to work…

    🙂

    Try editorial@…

  6. […] 2012 we tackled editorial quality by testing for passive voice, non-preferred terms, number formats and more. Computers are great at consistently performing the […]

Comment on this post