Lingo.dev v1

Localization engineering platform for consistent translation

API

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

Hey Product Hunt 👋 Thanks for hunting us. Excited to be here! Two things changed at once in localization engineering Teams are switching from legacy machine translation and translation vendors to LLMs. That part is visible. The invisible shift: LLMs without domain context don't localize, they just produce text that looks translated. LLMs made translation fast. They also made it stateless. Raw LLMs have no memory of previous decisions. The same term gets three different translations across the product. The results compound silently. This is terminology drift. And it's the gap between translation and localization. Translation converts text. Localization makes it consistent, domain-aware, and terminologically correct across every locale, every release. That gap is an engineering problem. And nobody had built the infrastructure for it. Until lingo.dev v1. What we learned from processing 200,000,000+ words: We started at a hackathon in 2023. Won "Best DevTools." Spent 2024 building open-source localization tooling with select early users, design partners, customers, and our Discord community. By 2025, we’d processed 200M+ words and teams at Mistral, Solana, SoSafe, and Cal.com were running localization through our infrastructure. During this time, we learnt that every team hit the same wall. LLMs translated fast. But terminology drifted across releases. The model had no memory of previous decisions. Each request started from zero. The missing piece was never better models. It was the context pipeline around the model. The research that shaped this: Recently, we published a study: retrieval augmented localization (RAL), injecting glossary terms into the LLM's context at inference time - reduced terminology errors 16.6–44.6% across five LLM providers and five European languages. 42,000+ quality judgments in our published research. The finding that mattered most: Mistral models with a 72-term glossary approached Google Gemini's raw quality at a fraction of the per-token cost. Turns out, Localization quality is a function of configuration, not model spend. Read the research → https://lingo.dev/research/retri... What v1.0 ships: Teams create stateful localization engines on Lingo.dev, configure it once, and call it from anywhere: - Glossaries: map source terms to target translations per locale pair, injected at inference time on every request - Per-locale model chains: ranked fallback across providers; swap models between releases without touching a single glossary term - Brand voice and instructions: define tone per locale, set rules for specific patterns (quotation marks, elision, spelling conventions) - AI reviewers: one model translates, another scores by dimension; cross-model quality measurement at scale - API, CLI, CI/CD, MCP: synchronous API, async jobs with webhook delivery, npx lingo.dev@latest run, GitHub integration that opens PRs with translations on every push. Where this doesn't work: One-off translations with no consistency requirements. Teams that prefer human-led review workflows may find legacy platforms a better fit. Try it today: Create your first localization engine in under 3 minutes at https://lingo.dev/ Before we go, there are a few things we're genuinely curious about from this community: 1. If you've localized a product into 3+ languages, what broke first - speed, quality, or consistency? (We have a hypothesis, but I'd love to know your experience.) 2. If you're a developer who's tried wiring LLM translation into a CI/CD pipeline, what did you have to hack around that you wish was just... handled? We've been building in public since 2023, first with select few users, then with our Github community, and now with you all. Happy to go deep on the RAL research, the engine architecture, glossary injection mechanics, whatever's interesting. Drop a comment or hit us directly!