How a local model keeps a 67-language site translated

Most websites are monolingual for an unglamorous reason: translation is priced like a luxury. Per-word APIs quietly price a personal site out of being multilingual at all, an agency retainer prices out most small products, and both hide the real cost, which arrives later. Every future edit multiplies across every locale, forever. So teams ship English, promise themselves “we’ll localise later”, and later never comes.

We took the opposite bet twice: a personal site in five languages and a production SaaS in sixty-seven. Neither pays a translation bill. Here is how that works.

Why do most sites stop at one language?

Do the arithmetic that translation vendors hope you will not. A per-word API price looks harmless until you multiply it by your word count, then by your locale count, then by every edit you will ever make. Sixty-seven locales do not cost 67 translations. They cost 67 translations of every change, for the life of the product.

That last multiplier is the killer, and it is the one nobody budgets for. Translating a site once is a project. Keeping 67 locales current as the content evolves is a permanent tax, and when teams stop paying it, locales rot silently: a new feature described in English, a stale price in German, a missing page in Japanese. Visitors notice before you do.

What does the pipeline actually do?

Two parts, both boring on purpose.

A language model runs on local hardware, through Ollama, on a machine that sits on a desk. It translates new and changed content into every locale. No request leaves the network, no meter runs.

A ledger tracks what changed. A small SQLite pipeline records which content is new or edited since it was last translated, per locale. When the model runs, it works through exactly that list and nothing else. Untouched content is never re-translated; changed content can never be forgotten.

Maintenance effort scales with the size of the edit, not the size of the catalogue.

That one property is the whole trick. Without the ledger, “keep 67 locales current” is a recurring project someone has to remember to fund. With it, staying current is a side effect of publishing. On Esoteric Numbers, the same pattern holds locales current as the calculators evolve, and because the pages are server-rendered, every locale is a first-class, indexable site, which is the entire acquisition story in 67 languages.

Is a local model good enough for translation?

We wrote before about when on-premise AI is the right call: it wins when the task is well defined rather than open-ended. Translation is the textbook case. Bounded input, bounded output, stable behaviour, easy to spot-check. It does not need a frontier model on someone else’s servers; it needs a capable open-weight model, run consistently, close to the content.

The models fit on hardware you can buy. In our lab, translation runs alongside heavier AI workloads on a Mac Mini through Ollama, on a private network, surviving machine failures mid-job. The pattern behind the two sites is the same one, hardened.

What does it cost?

The electricity the desk was already using. That sounds like a slogan, so consider what it changes structurally: when the marginal cost of a locale is zero, the question “is this language worth it?” disappears. Nobody asks whether the 67th locale earns its keep, because it costs nothing to keep. A small team gets the multilingual posture of a company a hundred times its size, and the budget conversation never happens.

What would this look like for your product?

Anywhere content changes over time and readers live in more than one language: product catalogues, documentation, help centres, listings, menus. The shape is always the same, a ledger of what changed and a model on your hardware working through it, and because it runs on your machines, the content never leaves your building.

That is the on-premise AI work we sell, and this is exactly the kind of question our Sovereign AI Pilot answers for your own workflow: two to three weeks, one real workflow, a clear answer. If you have a translation tax you have stopped paying, or never dared to start, bring it to us in your own words.

Frequently asked questions

How do you keep 67 locales up to date without an agency?

With a ledger. Every content change is recorded, and a language model running on local hardware re-translates only what changed, in every locale. Maintenance effort scales with the size of the edit, not with the size of the catalogue, so no locale quietly rots.

Is a local model good enough for production translation?

Translation is a well-defined task, exactly the kind local models are strong at. It is not open-ended frontier reasoning; it is a bounded transformation with clear inputs and outputs, which makes its behaviour stable and its quality easy to spot-check. Two of our production sites run on this pattern today, one with 5 languages and one with 67.

What does it cost to run?

The electricity the machine already uses. There is no per-word bill, no per-token meter, and no vendor contract, which is what makes 67 locales economically sane for a small team in the first place.

Can the same pattern work for my product?

If you have content that changes over time and readers in more than one language, yes: product catalogues, help centres, documentation, listings. The pipeline runs on your hardware, so nothing leaves your building. That is the on-premise AI service we offer.