If you play D&D in German, French, Portuguese, or anything else that gets called a “non-English market” in a planning doc, you already know this experience. Every tool in this hobby assumes your table speaks English. Character builders, VTT interfaces, AI note-takers: English in, English out, and if your session happens to be in another language, you get whatever falls out of the machine.

We shipped that exact failure. This post is about the bug, the one-evening fix, and the three design decisions inside the fix that turned out to be the actual hard part.

The bug: we detected your language, then threw it away

Here’s the embarrassing shape of it. Loracle’s transcription engine auto-detects the session’s language. That part worked from day one: a German session produced a clean German transcript, correctly labeled de, sitting right there in the pipeline.

Then the recap stage took that German transcript and handed it to a language model with an English prompt and zero instructions about output language. So the model did what models do with mixed signals: it wrote the recap in English. Or mostly English. Sometimes it flipped a coin mid-document and your wiki got a German article with an English summary, which is somehow worse than either.

The data knew what language your table speaks. The pipeline ignored it. That’s the whole bug, and I suspect it’s the same bug inside most tools that behave this way. Language support usually exists at the transcription layer because the vendor sells it there, and then dies one function call later because nobody wrote the sentence that carries it forward.

The fix took one evening. The decisions took longer.

The fix is a prompt directive, injected into every prose-generating pass in the pipeline: session recaps, entity extraction, wiki articles, the “Previously On” narration, narrative analysis. All five. It says, in essence: detect the dominant language of the source material and write ALL user-facing prose in that language. A German session gets a German recap. A Spanish one-shot gets a Spanish one.

No schema change, no feature flag, no settings toggle. Which sounds like a small ship, and in line count it was. But three decisions inside that directive are where the real product thinking lives, and each one is a place where the naive version quietly breaks.

Decision one: structure stays English, prose goes native

A recap document has load-bearing bones. Section headings like “The Story So Far” get parsed by the pipeline downstream; JSON keys and entity type fields get read by code. Translate those and the machine stops understanding its own output. A French table would get a beautiful French recap that fails to render, because the parser is looking for a heading that’s now “L’Histoire Jusqu’ici.”

So the directive splits the document into two layers: everything a human reads goes in the table’s language, everything a machine reads stays pinned to English. Titles, summaries, narration, descriptions: native. Headings, keys, enums: English, exactly as specified. The reader never sees the seam.

Decision two: never translate a name

This one is craft, and it’s the decision I’d defend hardest. If your table named the villain “Der Bleiche König,” that’s his name. He appears in the transcript as Der Bleiche König, the wiki article about him is written in German, and he is never, ever “The Pale King.”

Names at a table are canon in their exact spoken form. The entity graph that Loracle builds across sessions depends on recognizing the same name every time it appears; a translation pass that “helpfully” localizes names would fracture your cast into duplicates and betray the way your table actually talks. The rule in the prompt is absolute: entity names pass through untouched, whatever language surrounds them.

Decision three: detect per session, follow the table

We could have added a campaign language setting. A dropdown, a default, a support article explaining it. We skipped it, because the transcript already tells us the truth per session, and the truth beats a setting. Tables are messy: the Brazilian group that runs one session in English because a visiting friend joined, the bilingual table that drifts. Detection follows what actually happened at your table that night. A setting only remembers what someone clicked six months ago.

Why this stays rare

The honest answer for why most tools don’t do this: the market math looks bad until it doesn’t. English-speaking players dominate the spreadsheets, i18n sounds like a translation-agency invoice, and the tables it fails are quiet about it. They just churn.

But TTRPG is enormous in Germany, in France, in Brazil. Those tables are recording sessions, taking notes, forgetting what happened last month, exactly like yours. The pipeline version of this feature costs a directive and some discipline about which layer speaks which language. Once your recap engine reads the session instead of assuming it, following the table’s language stops being a feature and becomes the obvious default.

Your table’s memory should sound like your table. If your paladin committed arson in German, the record of it should read that way too.