Changelog

Max Prilutskiy·Updated3 days ago·5 min read

What's new in Lingo.dev - releases, improvements, and fixes.

May 2026#

  • API keys · Personal vs Service - API keys now come in two flavours. Personal keys inherit the creator's RBAC role and per-engine grants — same as before. Service keys are a new Enterprise-only construct decoupled from any one user, with their own role and/or per-engine scope. A service key can be roleless and reach only the engines listed on it, mirroring how a user without an org role still has access via engine_users rows. Anti-escalation guards apply on create and edit (role limited to engine:access, caller must hold every engine in scope). If the Enterprise plan ends, service keys deactivate with a typed 403 that names the entitlement, instead of a phantom "no engine scope" error.
  • MCP · OAuth login - The Lingo.dev MCP server now supports browser-redirect OAuth alongside token auth. Claude.ai, Claude Desktop, and other MCP clients can connect without copy/pasting API keys, and engines are configurable from inside the client.
  • Sync API · Usage metrics in response - The synchronous localize endpoint now returns the LLM model used, LLM cost, and localization token cost per request. Enables per-translation cost attribution down to the individual end user.
  • Async API · Locked keys - The async localization API now accepts lockedKeys. Locked values are preserved verbatim across target languages and bypass the LLM - for slugs, URL parameters, identifiers, and any key whose value is structural metadata rather than translatable content.
  • Platform UI · Retrieved context in Log tab - For every localization request, the engine retrieves the context used to produce that specific translation - glossary items, instructions, and brand voice. The Log tab now surfaces all of it per request, making it clear exactly which context shaped each translation.
  • Platform UI · Per-model billing breakdown - The billing page now splits cost and token usage by model across configured engines, instead of showing totals only. Makes it clear which models are driving spend.

April 2026#

  • Async API · Localization pipeline - Optional stages that wrap the core translate step in the async localization API, turning a single API call into a full translation workflow. Each stage is independently toggleable per engine and overridable per job. Full reference: Async Localization Pipeline.
    • Pre-localization AI edit - an AI agent cleans the source payload (typos, grammar, spelling) before translation, so a single source error doesn't propagate across every target locale.
    • Post-localization human review - the AI translation is sent to a qualified human translator who edits it for clarity, consistency, and accuracy. The job pauses on a webhook until the human output returns, with a configurable timeout (default 48h).
    • Post-localization AI review - after the human edit, an AI agent reconciles the human output against engine-level rules (glossary, brand voice, instructions). Catches cases where a translator's word choice conflicts with engine config. Requires human review enabled.
    • Back-translation check - the final translation is translated back into the source locale and compared against the original. An AI agent flags semantic drift by severity (minor, major, critical) and auto-adjusts the forward translation when major or critical drift is detected. Automates a classic human-QA technique.
  • Async API · AI engine provisioning - New Async Provisioning API that takes a fresh engine plus user-provided context (URLs, raw content) and auto-configures the brand voice, glossary, and instructions. An AI agent crawls the sources, extracts the configuration, and applies it to the engine - turning multi-step manual setup into a single API call.
  • Platform · AI reviewers - Major expansion of AI reviewers: per-engine configurability plus two built-in reviewers that replace hand-written quality checks for the most common cases.
    • Per-engine configurability - reviewers are now applied per engine instead of globally. The same organization-level library of reviewers can be enabled for the engines that need a given check and skipped for the ones that don't, so a strict legal-content reviewer doesn't run on marketing copy and a casual-tone reviewer doesn't run on a regulated engine. Built-in reviews toggle independently per engine on the Reviews tab.
    • Built-in Glossary items AI review - automatically checks whether each translation respected the engine's glossary rules: custom translations (e.g., "Deploy" → "Bereitstellen") and non-translatable terms (e.g., "OAuth") alike. Accounts for grammatical variations, so one glossary entry covers every inflected form. Returns a per-item breakdown with pass/fail and reasoning for each glossary entry, making the exact missed rule visible at a glance. Replaces hand-written custom reviewers for every glossary term.
    • Built-in Instructions AI review - evaluates each engine instruction independently against the translation. Three instructions produce three pass/fail verdicts, each with its own reasoning when failed. Supports N/A results when an instruction doesn't apply to the content (e.g., a formality rule on a translation that's just a product name); N/A is excluded from aggregate scores so quality metrics stay accurate. Replaces a custom reviewer per instruction.
  • Platform UI · New quality reports - Two new entries on the Reports page that turn the built-in AI reviews into time-series quality signals.
    • Terminology Coverage - tracks how consistently glossary terms are applied correctly over time. Daily line shows coverage percentage (correctly applied terms ÷ total relevant terms); bars show the absolute number of terms applied. A high terms-applied count combined with a falling coverage rate is an early warning that the glossary or engine config needs attention as volume scales. Filterable by engine and month.
    • Instruction Adherence - tracks how consistently the engine's instructions are followed over time. The percentage is calculated only across reviews where instructions were actually relevant - tooltips show followed / relevant so the rate and sample size are both visible. Useful for verifying that newly added instructions actually change behavior, and for catching regressions after a model swap or prompt change.

v1.0 - March 2026#

Lingo.dev v1.0 introduces localization engines - stateful translation APIs that teams configure once and call from backend code, CLI, or CI/CD.

  • Localization engines - configure models, brand voice, instructions, and glossaries per locale
  • LLM models - pick from the full OpenRouter catalog, with fallback chains for reliability
  • Brand voices - define linguistic rules and tone per locale
  • Instructions - set per-locale translation rules for specific patterns
  • Glossaries - lock down product terminology across languages and builds
  • AI Reviewers - custom 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