Enoda

The problem

Translating classical texts closely means constantly stopping to look up a word, work out its parsing, or trace a construction back to a grammar reference. Not everyone has a classical dictionary or grammar to hand, and switching between the text and a separate reference breaks a kind of concentration that’s better spent on the text itself.

Why I built it

While studying for exams, I kept losing time hunting for a dictionary or a textbook every time I hit an unfamiliar word. Enoda started as a way to close that gap for myself: cut the time spent on lookup, without handing over the translation itself.

Why no AI?

This is the decision the whole app is built around, so it is worth being direct about it. Enoda doesn’t translate, and there is no model anywhere in it. Everything it tells you comes out of a rule-based parser working from morphology and syntax.

• Agency stays with the reader. A tool that hands you finished English removes the only part of translating that teaches you anything. Enoda gives you what the form is, and leaves what it means here to you.
• A rule gives the same answer twice, and can show its working. If Enoda calls something a genitive absolute, there is a rule behind that you can check. A model that is right most of the time is worse than useless when you are learning, because you can’t tell which time you are in.
• Ambiguity is information. Where a form genuinely has several possible parsings, Enoda shows all of them rather than picking the most likely one and hiding the rest. Deciding between them is the reading.

The cost of that decision is real, and it shows up in what I had to drop. See what I’ve learned below.

How it works

It works like the inline grammar checkers built into most word processors, but for classical languages instead of typos. Highlight a word or passage anywhere in a document or browser, and a pop-up appears right there, showing parsings and dictionary senses for the word, along with any constructions, literary devices, or idioms Enoda picks up nearby.

What it covers

macOS only for now. Windows and mobile builds come after the parsing is solid on one platform.

What the output looks like

Highlighting a word returns its headword, its full parsing, the senses that fit that form, and any construction or device Enoda recognises around it. Two examples of the shape of that output:

Set out here as text; in the app this appears as a pop-up over whatever you are reading.

What I’ve learned

I originally wanted a rules-based system that could also produce a full trot, not just word-level parsing. A trot is an old classroom aid: a literal, word-by-word or clause-by-clause rendering set alongside the original, meant to get a student through the syntax quickly rather than to read well on its own. That’s different from a translation, which reworks the Latin or Greek into natural English and makes real judgment calls about tone, word order, and idiom. Building a trot mechanically, without those judgment calls, turned out to be close to impossible without leaning on AI or some form of machine learning. Since keeping agency with the translator mattered more than that feature, I dropped it rather than compromise.

Current status

Building out the Greek detection system, extending the existing rule-based Latin parser to cover classical and Homeric Greek.

Known limitations

• No translation output, and no trot. That is deliberate, and it is not coming back.
• Ambiguous forms return every parsing that fits, not a single best guess. On a heavily syncretic form that list can be long.
• Greek coverage is behind Latin: the Latin parser has been in use far longer.
• macOS only. No Windows, iOS or Android build yet.
• Constructions are detected from a fixed rule set, so an unusual or corrupt construction can go unrecognised rather than be flagged as odd.