Traditional machine translation treats every string the same. With LLMs, we can send context, glossary terms, and formatting rules alongside each string.
Machine translation has been usable for years. Google Translate, DeepL, and similar services produce output that's grammatically correct and generally understandable. So why did we build Polyglot around LLMs instead of traditional neural machine translation? The answer comes down to context.
Traditional MT systems translate strings in isolation. You send in "Save" and you get back a translation of the word "save." But "Save" on a button means something different than "Save" in a menu, which means something different than "save" in the sentence "We'll save your progress." Without context, the MT system has to guess — and it often guesses wrong, especially for languages where verb conjugation, formality level, or word order depends on usage context.
When Polyglot translates a string, it doesn't just send the raw text. It sends the file the string came from, the string's role (heading, button label, placeholder, error message), any meaning you've written for that key, and relevant glossary terms. This gives the LLM more to go on when it picks a translation.
For example, translating the string "Draft" in a blog editor is different from translating "Draft" in a banking app. When Polyglot knows the string comes from a file like PostEditor.tsx, the model can infer the likely meaning. When a key is truly ambiguous, you can spell out its meaning in polyglot.toml and that description travels with the string. Some MT APIs accept a context hint too, but an LLM can use richer, free-form context like this.
Every product has terminology that should be translated consistently. Maybe "workspace" should always be "espace de travail" in French, or "dashboard" should remain untranslated in all languages. Traditional MT services offer glossaries too, but they typically work as term-by-term mappings. Without them, you're left post-processing output — searching for known terms and replacing them, which can break grammar and sentence structure.
With LLMs, glossary terms become part of the instructions. Polyglot includes relevant glossary terms directly in the translation prompt, and the model incorporates them into its output while maintaining grammatical correctness. You define your glossary in a simple YAML file:
# polyglot-glossary.yaml
terms:
- term: "workspace"
translations:
fr: "espace de travail"
de: "Arbeitsbereich"
ja: "ワークスペース"
- term: "dashboard"
do_not_translate: true
- term: "deploy"
context: "Used as a verb for publishing changes"
translations:
fr: "déployer"
de: "bereitstellen"
When Polyglot encounters a string containing a glossary term, it includes the term definition and any existing translations in the prompt. The LLM then uses the correct terminology while constructing a natural-sounding translation around it.
Consistency is one of the hardest problems in translation. Users notice when the same concept is translated differently across your app — it feels broken, even when each individual translation is technically correct. Polyglot maintains a translation memory that tracks every string you've translated and reuses existing translations when the same string (with the same meaning) comes up again.
Translation memory also avoids waste. LLM calls have a cost, and re-translating strings you've already translated is pointless. When Polyglot finds an exact match in translation memory, it skips the model call entirely.
How much you reuse depends on your project — apps with many repeated UI patterns (buttons, form labels, error messages) reuse more than apps with mostly unique content.
A button label like "Cancel" is straightforward; a marketing headline or legal disclaimer needs nuance, tone, and cultural adaptation. Rather than route different strings to different models and hope the seams hold, Polyglot sends everything through a single LLM with full context — the component, the surrounding UI, glossary terms, and translation memory.
We benchmarked that choice in June 2026: across 4,900 translations — 100 UI strings into each of 49 languages — AI judges scored that pipeline's output 4.96/5 overall, with 100% of interpolation placeholders preserved exactly. Production has since changed models, so treat those as June's results. The methodology, dataset and June outputs are published and re-judgeable — you can re-score them with any model you like.
You don't translate strings one by one. polyglot translate sends every new string in one run and writes the results back to your locale files; strings it has already translated are skipped. That's handy for big migrations — translate the whole backlog in one pass, then review it.
# Translate everything new in one run
polyglot translate
In CI, the open Action sticks to detection — it flags new untranslated strings on every PR and leaves your branch alone. The translating happens through Polyglot Automation (early access for Team and Scale): generated translations go through human review by default, then Polyglot opens a catalog-only translation PR for your team to merge. It never writes to your default branch.
LLM-powered translation is a different approach from traditional MT, not just a tweak. Context, glossary terms, and translation memory work together to make translations more consistent and more natural. Generated translations still land in the dashboard for review before they're approved. And because it's driven from the CLI, it fits into the workflows developers already use.
We keep working on translation quality. If you're curious about how Polyglot handles a specific language pair or content type, install the CLI and try it on your own codebase. The guest tier gives you 50 free strings in one language — no account required.
Start in your terminal
Install the CLI, run a scan, and see exactly what you're missing. Free, no account required.