Private AI for translation and localization

A one-off translation of a single contract is a different problem from keeping a product's UI strings and marketing copy in sync across a dozen languages as the source text changes every week. This post is about the second case: a self-hosted model wired into a localization pipeline that runs continuously, rather than a document pasted into a tool once. If a one-off translation is what you need, our document translation post covers that scenario directly.

Why an ongoing pipeline is a different problem

A product's string files change constantly: a button label gets reworded, a new onboarding screen ships, a pricing page updates. Every one of those changes needs to reach every target language before release, and doing that by pasting strings into a cloud AI tool one batch at a time doesn't scale past two or three languages before someone on the team starts skipping it under deadline pressure. A pipeline that pulls new or changed strings automatically and translates them as part of the build process is the only way this stays current, and it's also the point where "paste text into a chat window" stops being a viable interface anyway, since the volume is too high and the process needs to be scriptable.

Why keeping this in-house matters for some content

Not every string file is sensitive. A public app's UI strings, once shipped, aren't a secret. But a lot of what runs through a localization pipeline is not yet public: marketing copy for a product that hasn't launched, an embargoed pricing change being localized ahead of a regional rollout, or UI strings for a feature still behind a flag that reveals the feature's existence if a translation vendor's staff sees it early. Sending that text to a cloud AI vendor, even one with a solid data-retention policy, means it exists on someone else's infrastructure before the company has announced it. A leak doesn't have to be malicious: a vendor's server logs, a cached prompt, a support ticket that includes a text sample, any of these can put pre-announcement content somewhere it shouldn't be.

Self-hosting removes that surface area for anything still under wraps, while leaving translation of already-public content as a lower-stakes decision either way.

What quality actually looks like

Here's the honest tradeoff: open translation models handle major language pairs, English to German, Spanish, French, Japanese, at a quality that's usable for UI strings and marketing copy with a native-speaker review pass, similar to what a competent freelance translator produces on a first draft. They're noticeably weaker on low-resource languages and on anything that depends on cultural adaptation rather than literal meaning, like a marketing tagline that needs to land as a pun in the target language, which still wants a human localization specialist. Don't expect a self-hosted model to replace that specialist; expect it to handle the routine string-by-string translation so the specialist's time goes to the copy that actually needs judgment.

UI strings are a good fit for automation because they're short, repetitive, and consistency across strings matters more than creative flair. Marketing copy needs more human oversight because tone and brand voice matter, and a model's default output tends to read a little flat until someone tunes the prompt with brand-specific examples.

Setup effort, honestly

Wiring a self-hosted model into a localization pipeline means pulling from whatever format the strings live in, a JSON locale file, a translation memory export, a CMS API, running the translation, and writing results back with enough context (screen name, character limits, surrounding strings) that the model doesn't translate a button label in isolation and produce something too long to fit. Budget a couple of weeks to get a clean pipeline running for a small team, plus ongoing time to build a glossary of product-specific terms the model should never translate literally, brand names, feature names, technical terms. Skipping the glossary step is the most common reason a first attempt produces inconsistent output.

A concrete workflow

A pattern that works well: hook the model into the CI pipeline so any new or changed string in the source locale file triggers a translation job for every target language, writing results to a review queue rather than merging directly. A localization lead or native-speaker reviewer approves or edits before the translated strings ship, so the model's output never reaches users unreviewed. For marketing copy specifically, keep the model's job scoped to a first draft and treat the human pass as the actual localization step rather than a formality.

Where the hardware fits

A translation-capable open model runs comfortably in a single Spark's 128GB of unified memory, with enough headroom to serve interactive review-tool requests and batch pipeline jobs without contention. At $0.79/hour in EU-Central, running this continuously costs less than most per-word cloud translation APIs once volume climbs past a few hundred thousand words a month, while keeping pre-announcement content off third-party servers entirely.