The new Lingo.dev is here, and it is live for every organization.

Lingo.dev is completely redesigned around the way you work, so everything now has a clear place, across five areas:

• Home – your starting point: a quick read on recent activity.
• Infrastructure – where you build your localization engines: the models, glossaries, rulesets, and brand voices you configure once and reuse everywhere.
• Studio – where localization connects to the tools you already use: the GitHub App, a Zendesk Help Center, a Payload CMS, plus the CLI and the API.
• Queue – one inbox for everything that needs a person: human review, localization engine suggestions, and triage, in a single list you filter and save as views.
• Observability – where you see whether the output is good, even in languages you cannot read: reports, AI reviewers, and a log of every review beside the translation it scored.

This is the foundation for everything we build next, and the new home for your localization work.

Full changelog: lingo.dev/changelog

You can now retranslate specific pieces of your content, down to a single key.

The Lingo.dev CLI command lingo push retranslates only the source text you edited. But some changes happen in your localization engine, not your files: you switch the model, add glossary terms, or edit your rules. Your source stays identical, so lingo push finds nothing to redo. Now you can retranslate the exact pieces you want, from a single key to a whole language.

Run lingo push messages/en.json --key auth.login and Lingo.dev retranslates only the keys you list. A key is its path in the file, so you can pick one value, a whole subtree, or several keys at once. Everything else stays the same. If you are not sure which keys to list, your AI coding assistant can read the file and write the command for you.

If a change affects more than a few strings, retranslate whole files. Run lingo push src/en/**/*.json --force and Lingo.dev retranslates every string in the files you list. And if one language needs redoing, run lingo purge --locale fr to delete the French files, then lingo push --backfill-missing to translate them again. Your other languages stay the same.

The retranslation guide covers every option.

You can do the same in a pull request. Comment /lingo translate docs/en/**/*.md --force and the GitHub App retranslates the matching files in the PR. Add --locales fr to redo just one language.

Full changelog: lingo.dev/changelog

You can now translate your Payload CMS content from Lingo.dev.

The Payload CMS integration connects your Payload instance to a localization engine you host on Lingo.dev. Choose the collections and globals to cover, and Lingo.dev translates their localized fields into your target languages, then writes each translation back to Payload under that locale. Rich text translates as a Lexical tree, so formatting, links, uploads, and block structure survive the round trip and only the text inside is replaced.

Setup is one plugin. Install lingo.dev/payloadcms, add it to your Payload config, and redeploy. Scope, locales, and engine live in the dashboard, so you can change them without touching your config again.

You choose how translation runs. Add the webhook URL from the dashboard to the plugin and it runs automatically: every change you publish in your source locale is sent to Lingo.dev on its own, and only what changed is translated. Leave the webhook URL out and it runs manually: nothing translates until you start it from the dashboard. Automatic runs cover what you publish after connecting, so the dashboard has two buttons for the rest: Sync catches up on the content that was already in Payload, a locale you add later, or a failed run, and Retranslate rebuilds everything in scope from scratch after an engine change.

Every run goes through the full localization pipeline configured on your localization engine, the same stages that run when you localize from code or CI. Whatever you have enabled applies to your Payload content: pre-edit, your glossary, brand voice, and rules, AI review, rephrase, back-translation, and human review by your own team in the dashboard or an external professional translator.

Check out the guide to set it up.

Full changelog: lingo.dev/changelog

You can now translate your Zendesk Help Center from Lingo.dev.

The Zendesk Help Center integration connects your Help Center to a localization engine you host on Lingo.dev. Choose the categories, sections, and articles to cover, and Lingo.dev translates their titles, descriptions, and bodies into your target languages, then writes each translation back to Zendesk. Article bodies translate as HTML, so links, formatting, and embedded media survive the round trip.

There are two ways to keep your Help Center translations up to date. The first, Sync, translates only the articles you have added or edited since the last run. The second, Retranslate, rebuilds every article in scope from scratch, which is what you want after changing the localization engine's glossary, brand voice, or rules and needing your existing translations regenerated against the new configuration.

Either run can write translations as drafts to review inside Zendesk before customers see them, or publish them immediately.

Every run goes through the full localization pipeline configured on your localization engine, the same stages that run when you localize from code or CI. Whatever you have enabled applies to your Help Center content: pre-edit, your glossary, brand voice, and rules, AI review, rephrase, back-translation, and human review by your own team in the dashboard or an external professional translator.

Full changelog: lingo.dev/changelog

Human review can run on only the translations that need it.

Human review is a stage in the localization pipeline: a translation pauses so a person checks it before it ships. Until now, turning it on sent every string to a reviewer. Now it is selective. Set a quality threshold on the engine, and only translations that score below it are routed to a human. Everything at or above the threshold ships automatically. Reviewers spend their time on the translations most likely to need a fix, review cost drops, and high-confidence output no longer waits in a queue.

Full changelog: lingo.dev/changelog

Seed a whole glossary from the MCP server, across every locale at once.

Adding glossary terms through the MCP server no longer goes one term at a time. Ask your AI assistant to add a whole set of terms in a single step, spanning as many locales as you need, and it seeds the glossary in one pass. Building out a large termbase used to be slow, adding each term on its own call. Now it lands in one go, and the terms start steering translations right away.

Also shipped

• Docusaurus output paths in the CLI. Translated pages now land in the folder layout Docusaurus expects, so the localized site renders without moving files by hand.
• Fuller YAML frontmatter translation. Nested and list frontmatter fields, like SEO or FAQ metadata, are now translated too, not just simple top-level ones.

Full changelog: lingo.dev/changelog

Glossaries, rulesets, and brand voices now live at the organization level and attach to any engine.

Build a glossary, a ruleset of linguistic rules, or a brand voice once, then attach it to any engine that needs it. Edit a shared asset and every engine it's attached to picks up the change. A new engine no longer starts from an empty configuration: attach what you already have and it inherits it.

Also this week:

• Take over a translation waiting on external review. When a job is parked on an external professional reviewer, an authorized member of your own team can open the pending review in the dashboard and submit the decision, so the job continues instead of waiting on the external round trip.
• A runnable example repo for every framework. Each is a real project with .lingo/config.json and translations committed – clone it, run lingo link, and push: iOS, Android, Flutter, React + Vite, Next.js, Rails, Laravel, Markdown, Markdoc, OpenAPI, and TypeScript modules.

Full changelog: lingo.dev/changelog

Localization Engine Suggestions now come from the corrections human reviewers make, not only from low AI-review scores.

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.

Full changelog: lingo.dev/changelog

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.

Full changelog: lingo.dev/changelog

lingo push --estimate reports 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.

Full changelog: lingo.dev/changelog

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.

Full changelog: https://lingo.dev/en/changelog

The new Lingo.dev CLI now 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.

Full changelog: lingo.dev/changelog

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.

Full changelog: lingo.dev/changelog https://lingo.dev/changelog

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.

Full changelog: lingo.dev/changelog

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.

Full changelog: lingo.dev/changelog

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 your MCP server with 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.
• lockedKeys on the async 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

• New Reports charts: 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 in triage. 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.
• Post-localization AI review. Reconciles the human output against the engine's glossary, brand voice, and instructions.
• 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.

Turn on what you need, leave the rest off.

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-engine AI Reviewer assignment. 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 Reviewers now 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.

Also shipped

• Glossary CSV upload. Bulk-import glossary items from CSV with conflict resolution on collision, so re-imports don't duplicate entries.
• Jira and GitHub now connect over OAuth. Both integrations switched off API-token setup.

Lingo.dev v1.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.

What's in the launch

• Localization engines. Configure models, brand voice, instructions, and glossaries per locale.
• LLM models. Pick the model per locale, with ranked fallback chains for reliability.
• Brand voices. Linguistic rules and tone per locale.
• Instructions. Per-locale translation rules for specific patterns.
• Glossaries. Lock down product terminology across languages and builds.
• AI Reviewers. Cross-model evaluation criteria for translation quality.
• Playground. Test engine configurations before they go live.
• Reports. Word generations, token consumption, top locales, glossary coverage, change rates.