Adults Lose Skills to AI. Children Never Build Them. (Psychology Today, 3/22)

[Emrys]

50. In my line of work (copy-editing for publishers), AI's been in use for some years.

After it started to be brought in, not all the publishers I worked for and books I worked on used it. One, more traditional (and great, also lefty) publisher I work with has as yet nothing to do with it beyond maybe traditional spellchecking (and they seem to be surviving, if not thriving).

In the versions I've seen, AI in copy-editing has taken two forms: pre-processing of files in an attempt to do some of the tedious donkey work, and checking the files after they've been worked on, to pick up on issues that may have been missed by a human copy-editor.

I'm currently working for a project management firm (they take on preparatory work for publishers, turning authors' typescripts into the final typeset versions). A year or so ago, they went over to using a custom-designed online publishing system rather than using Microsoft Word, which is the industry standard. Its pre-processing's always been a bit hit or miss. It can certainly help do away with some aspects of RSI and mindbending tedium. But it can also screw up, sometimes spectacularly (and occasionally hilariously). As you'd expect, it can be very very literal-minded, and that doesn't always fit with work on something as frequently nuanced as language, and especially a language as cranky as English.

One quite mechanical task pre-processing can be of some help with is cross-checking references. A non-fiction author may write a book with numerous citations of publications in text, associated with a references section or bibliography. The scope for errors (and general author sloppiness) is obvious, and dealing with and resolving them can form the bulk of our work, so any assistance is usually welcome.

I'd say the online system I'm working on with my current project is maybe 85% functional, maybe a little more, which may sound pretty good, but the 15% or so error rate is more of a bane than you might think.

For instance, one problem I've encountered is with in-text citations using "et al." Et al. is short for et alia, which is Latin for "and others". It can be used with the main author's name as an alternative to listing all the author names for a publication (and there can be very many in research works).

The system I'm using parses anything in text that "looks like" it may be a citation: what it assumes to be a name plus a year of publication (usually after the name, in brackets). That can occasionally screw up in itself (say if someone's just mentioning a year in passing), generating nonsense author queries that we have to weed out before we risk annoying the authors with them.

This same system's currently having a mental block with "et al." If it finds an author surname in text followed by a year in brackets and associates that with a references entry that has multiple authors, it'll raise a query complaining bitterly if it can't find "et al." in the accompanying phrase in text. Occasionally, it's correct, the author just made a mistake, and it's easily remedied. But the way it's currently programmed, it doesn't detect the strings "et al.," or "et al.'s", so these queries are just nonsense and we need to delete them or the author may think we're halfwits.

So the pre-processing may well be doing away with some donkey work, but it's creating other donkey work instead.

In terms of checking files after I've worked on them, my client very much wants us to run a "grammar/spelling checker" after finishing our main run-through, and this can lead to quite a lot of fun and games. These checkers - more or less primitive examples of AI - have been around in various word processors for many years, so you'd think they'd be quite mature by now. Alas.

The checker gives us the option of checking in either US English or UK English. The book I'm working on needs to be in UK English, but with -ize endings, not -ise ones (in words like recognize/recognise). Whoever did the programming didn't allow for this, and assumed anyone working in UK English would just need to use -ise endings, whereas -ize endings in UK English is a common standard in publishing nowadays (it's what Oxford University Press specifies, for instance).

So after working though the chapter and running the checker, I have to go through and reverse every time it's changed an -ize ending into an -ise one. More tedious donkey work, and often a lot of it.

It also makes some other bloopers. It prefers the "Oxford comma" in serial lists (Tom, Dick, and Harry), whereas the client publisher (and I) much prefer to include such commas only if they help clarify the sense of a phrase. That's also much more a UK standard usage.

It's also got a nasty habit, just to keep us on our toes when checking in UK English, of changing any instances it finds of "US" or "United States" to "UK" or "United Kingdom". How that came about beats me.

So I find myself arguing with the checker as I go along, on this as well as a number of other of its foibles: "Look, buddy, I've been doing this work for nigh on forty years, man and boy. You're just a cobbled-together jumped-up pocket calculator with delusions of adequacy trained on god knows what source material and programmed by people who don't really understand many basic principles of English, let alone copy-editing, so butt out."

This system is considered near state of the art, and I read not long ago that a major publisher had licensed it for a considerable sum for use by its in-house editing team.

The problems I've described could be quite trivial to reprogram, but the problems are economics and business politics. I've reported the problems I've found to my line manager, but the response is often, "Yeah, we've told the developers about that, but it doesn't look like it's going to get fixed any time soon" - the implication being "if ever".

No doubt some serious resources were expended to develop this system to its current state, and I guess bean counters have said it's good enough for jazz, regarding our feedback as nitpicky gripes.

Which may well be what they sound like to any of you who've reached this far in what's a much, much longer screed than I intended when I started typing. If I sound cranky on DU sometimes, maybe you now understand why.

In an attempt to at least do the OP the respect of relating to it more obviously: when I started out as a copy-editor, I was working with paper typescripts, pens, vats of Tipp-Ex, reams of Post-Its, and far too much coffee and tobacco.

I know how to do all these processes manually and mentally, and that often helps when the software screws up. In fact, without that grounding, it might be difficult to detect and identify some of the software bloopers I've mentioned, along with others, let alone overcome them.

I doubt many publishing training courses nowadays put students through the sort of apprenticeship I was lucky enough to have way back - funnily enough, with that same lefty publisher I mentioned up top, and they and I are both still going strong.