Patristic Translation Pipeline — Following Imperfectly

Over the last few weeks I’ve been building a pipeline for working with patristic texts. The original reason for building it was much more ambitious than modernising old English: I want to produce a machine-assisted English translation of St Jerome’s Commentary on Ezekiel, starting from the Latin text.

There is one fairly significant problem with this plan.

I don’t know Latin.

That means I cannot simply give a Latin text to an LLM, read the English output, think “that sounds good” and publish it. A fluent English translation can still be completely wrong. In some ways that makes a convincing translation more dangerous than an obviously bad one.

So the pipeline has gradually become less about asking AI to translate something and more about creating a system where different models can propose interpretations, evidence can be checked, disagreements can be surfaced, and a human can make the final decision.

The basic principle I have been working with is:

Models may propose; evidence must verify.

Instead of trusting one model, the text can be passed through several stages. Different models produce independent translations or interpretations. Other stages look at the Latin structure, morphology, terminology, possible ambiguities, and places where the translations disagree. Difficult passages can be flagged for additional research rather than quietly smoothed over.

The final text is then reviewed by a human.

That human is currently me, which brings us back to the slight inconvenience that I still do not know Latin.

Because of that, I wanted a way to test the architecture on something where I could judge the result myself.

Testing the Same Idea on Old English Translations

The obvious candidate was the enormous collection of English translations of the Church Fathers that are already in the public domain.

Many of these translations are excellent, but they were produced in the nineteenth century and the English can sometimes be harder to read than it needs to be.

St John Chrysostom’s Homilies on the Gospel of Matthew seemed like a particularly good test.

Rather than translating from another language, the pipeline could take an existing English translation and modernise it while attempting to preserve Chrysostom’s meaning, argument and tone.

The task is much safer because I can read both versions myself.

If a model turns:

“this nothing injures the truth of what they have said”

into something clearer such as:

“this does nothing to undermine the truth of what they have said”

I can judge whether the modernisation has actually improved the sentence.

More importantly, I can compare the choices made by different models.

One model may preserve the original sentence quite closely. Another may restructure it significantly. Occasionally one notices something the others miss. Sometimes all of them make the sentence worse and the best decision is simply to leave the original alone.

That has probably been the most useful part of the experiment so far. The value is not that an AI model gives me the answer. It is that several models can give me possible answers, disagreements become visible, and I have something concrete to evaluate.

That feels much closer to the workflow I eventually want for the Latin project.

Human in the Loop

I’ve become increasingly convinced that the human-review part is not something to remove from this process.

It is the point of the process.

The goal is not to build a machine that can ingest thousands of pages of patristic writing and automatically produce a supposedly authoritative modern edition.

It is to make careful human review more practical.

A useful pipeline can identify sentences worth looking at more closely. It can show where two models interpreted something differently. It can preserve the original source beside the proposed modernisation. It can record why a particular change was suggested and allow the reviewer to reject it.

Sometimes the correct action really is:

Ignore everything the models suggested.

And that is fine. The machine is there to assist the reading of the text, not replace it.

Then the Pipeline Found Something I Wasn’t Looking For

While reviewing Homily 1, I noticed something strange. The text went from section 3 directly to section 5. My first assumption was naturally that I had broken something.

That would not exactly have been surprising. I have parsers, chunking logic, preprocessing, model outputs and various other opportunities for a perfectly innocent paragraph to disappear into the machinery.

So I checked the source PDF. It also went from section 3 to section 5. At that point I found the scanned edition from which the public-domain transcription had ultimately been produced and checked that instead. And there it was.

Section 4.

The scanned book contained the missing section, but the searchable public-domain transcription I had been using had omitted it entirely. That was an unexpectedly satisfying discovery.

I started this project thinking mostly about translation quality: how to prevent models from confidently inventing meanings, how to surface difficult passages, how to preserve provenance, and how to make human review manageable.

I had not really considered that the process might also expose problems in the source texts themselves. But once a text is being processed systematically, structural anomalies become much easier to notice. A missing numbered section suddenly looks suspicious. A broken paragraph can be compared against the scan. A strange sentence might turn out not to be a difficult translation at all but a transcription error.

The original source still matters. Perhaps more than ever.

Modernisation as Textual Work

This has also changed slightly how I think about the modernisation project itself. At first it felt like a useful side experiment before returning to the much harder Latin translation. Now I think it may be worthwhile in its own right.

There is an enormous amount of patristic material available freely online, but “available” and “pleasant to read” are not necessarily the same thing.

The nineteenth-century translations often contain excellent scholarship underneath English that can now feel unnecessarily difficult. At the same time, aggressively rewriting them would risk flattening the authors or quietly changing what they actually said.

A careful modernisation sits somewhere between those two extremes. Keep the argument. Keep the theological terminology where it matters. Keep the author’s character. Remove unnecessary linguistic friction. And when there is uncertainty, preserve the original and flag the problem rather than pretending there isn’t one.

I’m still experimenting with exactly where that line should be.

Some sentences need only a changed word or two. Others benefit from being restructured completely. Occasionally the slightly strange older phrasing is part of what gives the passage its force and should probably remain.

That judgement cannot really be reduced to “make this modern English”.

What Comes Next

There are a lot of Chrysostom homilies.

A lot.

So this may turn into a rather larger test than originally intended. But the early results have made me much more confident in the general architecture. The pipeline does not need to be infallible. In fact, designing it around the assumption that models will make mistakes seems considerably healthier.

What matters is whether those mistakes can be detected, whether uncertainty becomes visible, whether evidence remains accessible, and whether the human reviewer retains control of the final text.

And apparently, every now and then, the machinery might even help find a missing section of a 1,600-year-old homily hiding inside a nineteenth-century scan.

I’ll take that as a win.

Looking into the Project

I have now open sourced the project on GitHub. You can find it on my profile under the name interpres.

I’ll likely keep tweaking the architecture and improving things as I continue using it.

The choice of models came after a few days of experimentation. I mostly tested them against difficult Latin phrases, compared the outputs, and looked at where each model seemed particularly useful or unreliable.

The pipeline is designed to run almost entirely locally, with a single optional call to OpenRouter.

My current setup is:

RTX 4070 12 GB GPU
32 GB of RAM
AMD Ryzen 7 3700X CPU

I would treat these as the hardware the project has been tested on rather than strict minimum requirements. Other configurations may work perfectly well, particularly with different models or quantisations.

Latin translation is still fairly slow on my machine because Qwen 3.8 does not fit entirely within the GPU’s VRAM and therefore has to split the workload between the GPU and system memory/CPU.

At the moment, processing a single chunk can take roughly 10–30 minutes depending on the length and complexity of the passage.

Because of that, the pipeline is very much designed around batch processing: start a run overnight or while away from the computer, then come back later and work through the results in the reviewer UI.

The project includes the pipeline, reviewer interface, and import/export support, so the generated data can also be inspected independently rather than being tied permanently to a particular run or machine.