Lingo.dev

Key features

• CLI with five documented commands The command line covers internationalization, running translations, guided initialization, authentication, and CI, with a pull command that opens translation pull requests for review.[1][2]

• Compiler with framework plugins Compiler rules and bundler integrations detect the visitor's language and ship only that language, keeping localized builds small and readable for search engines.[1]

• CI agent with pull-request review The continuous localization agent watches for new or changed content, translates it, and opens pull requests through a documented GitHub Action, with GitLab and generic CI support for other pipelines.[1]

• Thirty-eight documented file formats JSON variants, YAML, Gettext PO, XLIFF, Flutter ARB, CSV, Markdown, and mobile formats are documented, so most stacks keep their existing locale files.[1]

• Four translation modes Standard translate, context-aware smart, glossary-pinned precise, and local-first offline modes let teams pick the tradeoff between fidelity and data locality per run.[1]

• Translation memory and style controls A shared memory, style guide, glossary, and per-locale tone settings keep repeated and brand-sensitive copy consistent across languages.[1]

• API server with MCP endpoint The engine exposes a documented API and a Model Context Protocol server, so AI agents and external systems can drive translation programmatically instead of shelling out to the CLI.[1]

• Self-hosted engine with own model keys Teams can run the engine on their own infrastructure with their own API keys and unlimited machine translation, keeping unreleased copy inside their boundary; a managed cloud remains available for teams that prefer not to operate it.[1][2]

Who will love it

• Product teams shipping multilingual releases weekly or faster Translations arrive through the same pull-request flow as code, so localization never becomes a release blocker owned by a separate team.[1][2]

• Developer-led teams standardizing many locales One configuration, one glossary, and one pipeline cover 38 formats and four modes, which beats maintaining per-platform translation scripts.[1][2]

• Teams with data-locality motives for self-hosting The engine runs on team infrastructure with the team's own model keys, keeping unreleased copy inside their boundary, and the offline mode keeps source files local during translation.[1][2]

Who should avoid it

• Non-technical teams needing visual translation Setup, configuration files, model keys, and CI wiring all assume engineers; there is no documented no-code editor, so visual-first teams will stall.[1][2]

• Fixed-budget buyers needing exact quotes Public pricing is token-based with plan thresholds, so total cost depends on content volume and target languages that only the buyer can project.[1]

• Teams wanting field-proven quality reports With no inspectable original user reports, anyone who needs peer evidence of quality or support before adopting should wait for the corpus to mature.[1]

Compatibility and requirements