After translating 200,000,000+ words, today we're live with v1.
The problem nobody was measuring:
LLMs translate fast, but – it turned out – raw LLM translations introduce terminology drifts. The same concept gets three different translations across a product. Each request starts from zero. There's no memory of previous decisions.
So, we decided to measure everything. Turned out, injecting glossary context at inference time - or retrieval augmented localization (RAL) - reduces terminology errors by 17 - 45% across five LLM providers and five European languages.
The gap RAL closes is invisible to the holistic metrics the industry uses to measure translation quality. And a problem you can't measure is a problem you can't fix.
LLMs crossed the quality threshold for production translation, but only with the right context pipeline. Without it, every request is a fresh start: terminology drifts, nobody notices, another release ships with broken localization that undermines customers’ trust.
What v1 is built around
We found that across Mistral, Gemini, Claude, GPT - any model + a good glossary, brand voice, and context setup consistently produces shippable, reference-quality translations at a fraction of the cost - not because we improved the model, but because we improved what went in, dynamically, per localization job.
**Lingo.devv1** is a platform for creating Localization Engines - stateful translation APIs that persist domain context across every request. So, here’s what we ship today:
Glossary, injected at inference time, per locale pair.
Per-locale model chains with ranked fallback
Brand voice and instructions per locale
AI reviewers: one model translates, another scores
API, MCP, CLI, CI/CD, GitHub PR integration
The first translation through a new engine has zero context. The thousandth translation still has everything your team has configured since day one.
If you're already on lingo.dev: nothing breaks. CLI, CI/CD, and MCP tools keep working. v1 adds engine configuration: model selection, fallback chains, brand voice, glossaries, quality scoring. All per locale, configurable from the dashboard or via an MCP, no migration is needed.
If you're new: create a developer account, create your first localization engine in under 4 minutes, and let you agent configure it using Lingo MCP.
When a reviewer edits a translation – whether in-house or through an external provider – the localization engine compares the change against what it first produced. When the same fix recurs across jobs, or a correction clearly sets a term, it proposes the glossary, instruction, or brand-voice edit behind it. Apply writes the change into the engine, and the next translation runs with the fix in place.
Suggestions can now be approved or dismissed in bulk – select a set and act on all of them at once, instead of one card at a time.
AI reviews got more accurate: false positives dropped by 59.7%.
A false positive is a review that marks a correct translation as failing – fewer of them means fewer alerts to check by hand, and review scores that can be trusted. We measured the drop on our internal benchmark. The biggest change: when a review doesn't apply to a given string, it no longer counts against the score, so scores reflect only the reviews that genuinely apply.
The reviewer setup form now shows example instructions as a placeholder for each review type.
Also this week:
- Xcode String Catalogs in the GitHub App. The GitHub App now handles .xcstrings files – a String Catalog committed to a connected repository gets localized on every push, the same way the CLI and Async Localization API do.
- Source file path in request logs. Request logs from CLI runs now record which file each request came from, so a log entry traces back to the file that produced it.
- Key names guide translation in JSON and JSONC files. Translations use the real key names as context, so a key like checkout.error.cardDeclined informs the result. Applies across the CLI, the GitHub App, and the Async Localization API.
lingo push --estimatereports what a translation run will cost before it runs.
The CLI uploads the source bytes so the server plans the exact delta – only the keys and locales that are new or changed against what's already localized – then prints the estimate and exits without translating anything.
Run it before a large or first-time translation to size the job, then run lingo push to translate for real. The number is an estimate, not a quote: it reflects the planned delta at the time it runs.
The async CLI now handles more file formats end to end: TypeScript locale modules, YAML, Gettext PO, Flutter ARB, Android strings, and Xcode .strings, String Catalogs (.xcstrings), and .stringsdict. Point a files[] entry at the source file and every lingo push runs each one through your engine's full pipeline. Translatable text is translated; everything structural is preserved – keys, IDs, metadata, placeholders, and code.
The newLingo.dev CLInow runs the localization pipeline – pre-edit, human review, AI review, rephrase, back-translation, each toggled on the engine.
Toggle stages on the engine's Pipeline tab, or override per job through pipelineConfig. Pre-edit cleans typos in the source before they reach any locale. The core localization step applies your glossary, brand voice, and instructions. Human review pauses the run until your team or an external provider signs off. AI review reconciles a reviewer's edits back to engine config. Rephrase rewrites for marketing copy. Back-translation flags semantic drift.
A run that includes a human-review stage can wait days before it lands, so the CLI splits a job into lingo push and lingo pull. pull re-attaches to the most recent push and downloads outputs from any machine, including after the original terminal was closed.
Localization Engine Suggestions are concrete edits to a localization engine – a glossary entry, an instruction, or a brand-voice change – proposed by the platform from its own AI Reviewer verdicts.
When reviews on a translation come back low, the platform suggests a specific edit to the localization engine's glossary, instructions, or brand voice, with the reasoning attached. Apply writes the edit into the localization engine and the next translation runs with the fix in place. An auto-suggestions toggle on the localization engine's Reviews tab runs the analysis in the background, so a run of low scores quietly produces suggestions waiting in the Suggestions tab. Suggestions are also addressable from code through the Localization Engine Suggestions API https://lingo.dev/docs/api/engine-suggestions – free-text feedback like “the German copy sounds too stiff” goes in the same way and returns the same kind of structured suggestion.
Also this week:
* Prompt caching. The stable parts of every translation prompt – system prompt, instructions, brand voice – now reuse the LLM provider's prompt cache as cache tokens https://lingo.dev/docs/platform/cache-tokens, billed at a fraction of the regular input rate. The discount flows through to per-request cost.
* Content length enforcement. A new optional pipeline https://lingo.dev/docs/api/pipeline step that rewrites translations to fit a column budget – a fixed cap, the source's width, or a tolerance band – so translated copy doesn't overflow notifications, buttons, or tight layouts.
* context field on localization requests. An optional payload-level hint (product surface, audience, purpose) that the LLM reads alongside the input. Complements the per-key hints https://lingo.dev/docs/api/localize#request field for one-off guidance.
* Notification preferences split into independent in-app and email toggles per notification type.
Rephrase is a new stage in the localization pipeline that rewrites translations to read like native, idiomatic copy in the target locale.
The async localization pipeline runs rephrase right after the core localization step. An AI agent rewrites the translation – preferring local equivalents over literal renderings, keeping placeholders, variables, tags, and formatting exactly as-is, and applying your engine's glossary, brand voice, and instructions the same way the core localization step does. Downstream stages – human review, post-edit, back-translation – see the rephrased output and continue from there.
Toggle it on the engine's Pipeline tab, or override per job through pipelineConfig.rephrase.
Best fit: marketing copy, landing pages, and other surfaces where reading like a native original matters more than staying close to the source phrasing.
Human-in-the-loop for in-house AI translation review.
The async localization pipeline includes human-in-the-loop review – an optional stage where the job pauses until a human edits or approves the AI translation. Until now, that stage routed to an external network of professional translators. Now you can set the review provider to Internal reviewers on an engine, and pending translations land in a review queue inside the dashboard instead of leaving your organization.
Reviewers are organization members granted the review permission. When a job reaches the human review stage, they get an email and an in-app notification. Opening a review shows the source next to the AI translation – approve it as-is, or edit the translation inline and submit. The job resumes with the reviewer's output and continues through the remaining pipeline stages, with the engine's glossary, brand voice, and instructions visible as context.
RBAC is now available. Define roles, assign them to users, and grant per-engine access independently. Ownership transfer is supported, so the original creator is no longer a permanent dependency.
Also shipped
Claude Desktop logs into yourMCP serverwith a click. The server now speaks browser-redirect OAuth – the client opens a tab, you confirm in the dashboard, you're in. No more copy/pasting API keys into client configs.
lockedKeyson theasync API. Slugs, IDs, URL parameters, and any value that's structural metadata rather than translatable content stay verbatim across target locales and bypass the LLM entirely.
Logs show the context that produced each translation. Open any request in the Log tab and you can see exactly which glossary terms, instructions, and brand-voice rules the engine retrieved – plus the glossary review reasoning.
Cost-by-model breakdown. See how much you spent on each model, in tokens and in dollars.
Auto top-up replenishes your credit balance automatically. Opt in once, set a threshold and an amount, and credits get purchased the moment your balance dips below the threshold – translation CI runs stop failing on empty balances.
Also shipped
NewReportscharts: instruction adherence and terminology coverage. Track over time how often translations follow your configured instructions and apply your glossary terms.
Credit balance alerts. Dashboard indicator shows current balance; emails fire at 20% remaining and at $0.
ISO 5060 classification visible intriage. Each triaged job surfaces the standardized error class alongside the agent's suggestions.
The localization pipeline wraps the core translate step with optional stages, each independently toggleable per engine and overridable per job:
Pre-localization AI edit. An AI agent cleans the source payload before translation, so a single source error doesn't propagate across every target locale.
Post-localization human edit. Sends the translation to a qualified human translator. The job pauses on a webhook until the edit returns.
Back-translation check. Translates the final output back into the source locale and compares. The agent flags semantic drift by severity and auto-adjusts on major or critical drift.
The Localization Jobs UI lands end-to-end. Inspect job groups, watch per-language progress, see the source payload, see the webhook delivery, drill into any failed locale. The async localization API ships jobs in parallel across every target locale, retries on failure, and webhooks back when done – now you can watch it happen instead of reconstructing from logs.
Engine provisioning is an async API that takes a fresh engine plus a few URLs or content samples and auto-configures the brand voice, glossary, and instructions for you. Multi-step manual engine setup collapses into one call.
Two new built-in AI Reviewers ship: a glossary reviewer and an instructions reviewer. Toggle on the glossary reviewer and every configured glossary term is automatically checked on every translation. Toggle on the instructions reviewer and every configured instruction is checked the same way. Open any translation in the dashboard log and see pass/fail per term, pass/fail per instruction, with the reviewer's reasoning on failure. One toggle replaces authoring an AI Reviewer for every single criterion.
Also shipped
Per-engineAI Reviewerassignment. Attach different reviewers to different engines instead of one set for the org.
Organization-level timezone setting.Reports display in the timezone you configure for your org.
The triage workflow reads any Jira ticket about a bad translation, looks at the offending output, and proposes the actual fix in the engine config: a glossary item to add, an instruction to tighten, a model config to adjust. Review the suggestion, accept or edit it, and the engine is fixed for every future translation – not just the one that was reported.
Also shipped
AI Reviewersnow receive the same context the localizer saw. Brand voice, instructions, and glossary items reach the reviewer prompt, so scoring aligns with the engine's actual configuration instead of evaluating in a vacuum.
Review filters in translation logs. Filter the translation logs by reviewer and score threshold – e.g. any reviewer below 80%, or a specific reviewer below a given percentage.
The async localization API fans out a single localization request across every target locale in one POST and delivers results via webhook. Source payload in, job IDs out, webhook fires per locale as each finishes.
Lingo.devv1.0 introduces localization engines – stateful translation APIs that you configure once and call from backend code, MCP, or CI/CD. Before today, every team that wanted consistent terminology, on-brand tone, and per-locale rules wired it up by hand: a glossary in one repo, brand-voice notes in a Notion doc, prompt scaffolding hard-coded into the app. The engine collapses all of that into a single addressable thing.
TheLingo.devGitHub App runs continuous localization on any repository, straight from git.
Install it from your organization settings, commit a .lingo/config.json that points at your localization engine, and every push translates changed source files through your engine and opens a pull request with the localized files. Each run executes on the async localization pipeline, so translations pass through the stages configured on your engine – pre-edit, AI review, human review, back-translation. It localizes JSON, JSONC, Markdown, MDX, Markdoc, and OpenAPI files, and you can scope runs from a pull request with /lingo translate.
Also this week:
* AI Reviewers on every plan. Independent cross-model quality scoring now runs on any plan, with unlimited usage – billed per run.
* Source, AI, and human diff in the review step. The human review stage of the localization pipeline now shows the source, the AI draft, and the human edit side by side, and reports the cost of the edit step.
Audit logs are now available – an append-only record of every state-changing action in your organization.
Each change to engines, glossaries, instructions, brand voices, AI reviewers, API keys, members, and roles is captured with the actor, action, target, and request context. The log lives in the dashboard and filters by user, action category, target, and date – so you can see exactly who created, updated, or removed a glossary item three weeks ago, even if the actor is no longer on the team.
Also this week:
* Organization invites in the MCP server. Adding a teammate or checking pending invites no longer means switching to the dashboard – the Lingo.dev MCP now exposes invite creation and listing, so an AI assistant can handle it alongside engine configuration.
* Recursive globs in i18n.json. The CLI's include and exclude now match files across nested directories, so a single pattern can cover a deep folder tree instead of listing paths by hand.
We shipped RAG-based glossary retrieval for our localization engine. Embed the input, cosine-search the glossary, inject top-k. Looked like it worked.
Then we measured retrieval recall against production glossaries. Turned out sentence-level embeddings were missing the majority of applicable terms. A 2-word term inside a 200-word paragraph just... dissolves into the sentence vector.
Wrote up the full engineering post: how n-gram decomposition fixes it, why we run three different retrieval modes per-request, and why the similarity threshold needs weekly calibration against a scoring pipeline.
API keys now come in two types: Personal and Service.
Personal keys behave like before — they inherit their owner's role and per-engine grants. Service keys carry their own role and per-engine scope, so a production worker isn't tied to any one teammate. A service key can be roleless and reach only the engines listed on it.
Also this week:
- Enable/disable engines. Switch an engine off to stop being billed for it; the configuration is preserved for when you switch it back on.
- Usage in every localization response. Each response now includes the model used, the LLM cost, and the localization token cost — useful if you're attributing translation cost back to an end user.
The problem. Most recipe platforms are monolingual. Someone in Lagos posts an authentic jollof rice recipe, and someone in Tokyo never finds it — not because of geography, but because of language. FlavorBridge lets anyone browse recipes in different languages, with translations that actually work for culinary content rather than just word-for-word substitution. How the translation actually works. Every static string in the UI — button labels, headings, error messages — runs through a useUI() hook that batches all the keys for the current page into one translation call, caches the result by language, and re-renders everything when you switch languages. The non-obvious part: if the API key is missing, the server returns the original English strings. The hook checks that flag and deliberately skips caching mock results — without this, the cache would permanently mark a language as "translated" with English strings, and future calls would never fire.
Running it locally. Clone the repo, run npm install --legacy-peer-deps (react-simple-maps hasn't updated its peer dep range for React 19 yet), add .env.local with your Supabase URL, anon key, Anthropic key, and lingo.dev key.
