Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we made Typerighter, the Guardian’s style guide checker

theguardian.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: How we made Typerighter, the Guardian’s style guide checker

#11

Post by smt88 »

teach wrote: post #2

This is wonderful. I love to see technology enhancing experts' ability to do what they already do, but faster/more accurately. Also, I'm a big fan of regex. I think -- probably thanks to jwz's famous quote -- a lot of younger programmers avoid them but they're fantastic for MATCHING. Using them in a Google sheet is a killer MVP to prove out something like this.

I'm good at reading/writing regex and use them a lot, but I always worry about their maintainability. They're a common source of hard-to-pinpoint bugs.

I suppose I still use them because I don't know of a better way to do things.

Re: How we made Typerighter, the Guardian’s style guide checker

#12

Post by seanwilson »

Is there a link to a list of the style rules their checker tests for?

I've always felt automated checks + fixes for grammar and style are miles behind where they should be by now. Checking over and over e.g. long emails for problems before you send them is super time consuming, and that's not even considering help with tone and the overall message.

Re: How we made Typerighter, the Guardian’s style guide checker

#14

Post by dmje »

triceratops wrote: post #8
ggm wrote: post #7

Earlier quoted context omitted.

name me a tier-1 paper without typos. the point about the graun, is how entertaining they could be.

Honestly I don't see that many typos in other papers; grammatical issues, sure. But it would appear that not knowing what the squiggly red underlined words are is a requirement of being a Graun writer or editor.

Probably worth taking into account their line in that article about how good they are at fast-turnaround journalism. Typos are always going to happen in that environment I’d guess.

Re: How we made Typerighter, the Guardian’s style guide checker

#15

Post by js_herbert »

smt88 wrote: post #11
teach wrote: post #2

This is wonderful. I love to see technology enhancing experts' ability to do what they already do, but faster/more accurately. Also, I'm a big fan of regex. I think -- probably thanks to jwz's famous quote -- a lot of younger programmers avoid them but they're fantastic for MATCHING. Using them in a Google sheet is a killer MVP to prove out something like this.

I'm good at reading/writing regex and use them a lot, but I always worry about their maintainability. They're a common source of hard-to-pinpoint bugs. I suppose I still use them because I don't know of a better way to do things.

We were amazed at how far we were able to get with them – if solving a problem with a regular expression produces two problems, we should now have 13,000 problems. The fact that they worked so well is due to the work of the subeditor who compiled (and still maintains!) the rule corpus – as well as the sheer volume, there are quite a few carefully ordered rules. Because style guide matches are reasonably sparsely found in content, and usually reasonably specific as to what matches (even if it's difficult to produce a correction) it turned out to be a surprisingly tractable problem to produce something useful with regular expressions alone – but we'd never have discovered that was the case unless someone had spent literally years doing it!

General maintainability is a priority, and we'd like to improve our rule management tooling to make the process of rule maintance generally accessible to editorial staff. We're also working on making noisy rules match more specifically, which usually involves migrating the initial regex into Languagetool for e.g. pattern-matching on part-of-speech.

Re: How we made Typerighter, the Guardian’s style guide checker

#16

Post by iainmerrick »

dmje wrote: post #14
triceratops wrote: post #8

Earlier quoted context omitted.

Honestly I don't see that many typos in other papers; grammatical issues, sure. But it would appear that not knowing what the squiggly red underlined words are is a requirement of being a Graun writer or editor.

Probably worth taking into account their line in that article about how good they are at fast-turnaround journalism. Typos are always going to happen in that environment I’d guess.

1. Why, with good tools available?

2. Can't they at least fix typos quickly?

3. I still regularly see trivial grammar errors (repeated words, etc) in opinion pieces on the Guardian, not just breaking news and liveblogs. I guess some of those opinions pieces might be treated as "fast-turnaround journalism", AKA "hot takes". The rate of simple typos there makes me wonder about more important things like factual accuracy.

Edit to add: reading the article more closely, it sounds like they've only started using this new system quite recently, so hopefully it will help them improve. I stand by my opinion that in recent years the rate of typos and grammar errors has been higher on the Guardian than most other comparable news sites.

Re: How we made Typerighter, the Guardian’s style guide checker

#17

Post by kimburgess »

Relying on purely on regex misses so much context available from a document. I've been working on some tooling [1] in this space recently and a core epiphany was noting you can model written language as an AST and then reason about it in this form rather than opaque blocks of text (or flat, sequential text fragments as with Typerighter). An even better realisation was that others had already noted this too and built a mature ecosystem based on this concept [2].

[1]: https://github.com/place-labs/orthograph-err

[2]: https://textlint.github.io/

Re: How we made Typerighter, the Guardian’s style guide checker

#18

Post by danpalmer »

kimburgess wrote: post #17

Relying on purely on regex misses so much context available from a document. I've been working on some tooling [1] in this space recently and a core epiphany was noting you can model written language as an AST and then reason about it in this form rather than opaque blocks of text (or flat, sequential text fragments as with Typerighter). An even better realisation was that others had already noted this too and built…

I had this same thought, but I wonder if it really matters for this use-case. The rules are actually quite simple much of the time – they're spelling and stylistic corrections.

I suspect the biggest problem with using regexes is over-suggestion, trying to correct American English spellings in a quote for example, but I suspect this is a pretty good balance of features, usability, and correctness.

One issue that comes with more complex systems like you mention is that the bugs become more complex. I'd imagine it's fairly easy for a journalist using this tool to know why an incorrect suggestion has been made, and that makes it easy for them to disregard it. While the error rate may improve with more complex analysis, those errors that do still happen are likely to be less understandable.

Re: How we made Typerighter, the Guardian’s style guide checker

#20

Post by js_herbert »

kimburgess wrote: post #17

Relying on purely on regex misses so much context available from a document. I've been working on some tooling [1] in this space recently and a core epiphany was noting you can model written language as an AST and then reason about it in this form rather than opaque blocks of text (or flat, sequential text fragments as with Typerighter). An even better realisation was that others had already noted this too and built…

This is definitely true – in this sense, our initial corpus of regexes are the booster stage for this project, in that they enabled us to produce something useful for journalists in a reasonable timeframe. Typerighter's built as a platform for matching text, so we're not tied to regex – at the moment, we're migrating many rules to LanguageTool, which is a part of our pool of matchers and has a more sophisticated set of NLP tools. (And a great project – thanks LT maintainers!)

Thanks sharing these projects, other suggestions are very welcome – we'd be interested in adding new matchers based on different tech if they were a good fit for the use case.

Post reply on HN