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

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:

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.

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.

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.

The Lingo.dev GitHub 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:

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:

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/engin... free-text feedback like the German copy sounds too stiff goes in the same way and returns the same kind of structured suggestion.

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`.