Lingo.dev v1

嘿，Product Hunt 的朋友们 👋 感谢大家的关注。非常激动能来到这里！ 本地化工程领域同时发生了两件事 团队正在从传统的机器翻译和翻译供应商转向大语言模型（LLM）。这是看得见的变化。看不见的变化是：缺乏领域上下文的 LLM 并不能进行本地化，它们只是生成看起来像翻译过的文本。 LLM 让翻译变得快速，但也让它变得无状态。 原始的 LLM 没有记忆，无法记住之前的决策。同一个术语在产品中可能出现三种不同的翻译。这种问题会悄无声息地累积。 这就是术语漂移。它也是翻译和本地化之间的差距。 翻译是对文本进行转换。本地化则是在每个语言环境、每次发布中，确保内容的一致性和术语正确性，并融入领域知识。这个差距是一个工程问题。此前，没有人为此构建过基础设施。 直到 lingo.dev v1 的出现。 从处理 2 亿多个单词中学到的经验： 这一切始于 2023 年的一次黑客松，当时赢得了"最佳开发者工具"奖。2024 年，我们与精选的早期用户、设计合作伙伴、客户以及 Discord 社区一起，构建了开源的本地化工具。 到 2025 年，我们已经处理了超过 2 亿个单词，Mistral、Solana、SoSafe 和 Cal.com 等团队都通过我们的基础设施进行本地化。 在此期间，我们发现每个团队都遇到了同样的问题。LLM 翻译很快，但术语在不同版本间出现漂移。模型没有记忆，无法记住之前的决策。每次请求都是从零开始。 缺失的环节从来不是更好的模型，而是模型周围的上下文管道。 支撑这项研究的成果： 最近，我们发表了一项研究：检索增强本地化（RAL），即在推理时将术语表注入到 LLM 的上下文中，这使五个 LLM 提供商和五种欧洲语言的术语错误率降低了 16.6% 到 44.6%。这项已发表的研究包含了超过 42,000 个质量判断。 最重要的发现是：Mistral 模型加上一个 72 个术语的术语表，其质量接近 Google Gemini 的原始质量，但每个 token 的成本却低得多。 事实证明，本地化质量取决于配置，而非模型投入。 阅读研究 → https://lingo.dev/research/retri... v1.0 版本带来了什么： 团队可以在 Lingo.dev 上创建有状态的本地化引擎，一次性配置，然后从任何地方调用： - 术语表：将源语言术语映射到每个语言环境的目标翻译，并在每次请求的推理时注入 - 按语言环境的模型链：跨提供商的排序备用方案；在不触及任何术语表条目的情况下，在不同版本间切换模型 - 品牌语调与指令：为每个语言环境定义语气，为特定模式（如引号、省略、拼写习惯）设置规则 - AI 审查员：一个模型进行翻译，另一个模型按维度打分；实现大规模的跨模型质量评估 - API、CLI、CI/CD、MCP：同步 API、带 Webhook 通知的异步任务、npx lingo.dev@latest run 命令、以及每次推送时自动创建带翻译内容的 PR 的 GitHub 集成 这个方案不适用于： 没有一致性要求的一次性翻译。 偏好人工主导审核流程的团队，可能会觉得传统平台更适合。 立即尝试： 在 https://lingo.dev/ 上，不到 3 分钟即可创建第一个本地化引擎。 在结束之前，我们很想听听这个社区的看法： 1. 如果你曾将产品本地化为 3 种以上语言，最先出问题的是什么——速度、质量还是一致性？（我们有一个假设，但很想听听你的实际经验。） 2. 如果你是一名开发者，曾尝试将 LLM 翻译集成到 CI/CD 管道中，你不得不绕开哪些问题，并希望这些问题能被直接解决？ 自 2023 年以来，我们一直公开进行开发，最初只与少数用户合作，然后与 GitHub 社区合作，现在则面向所有人。 非常乐意深入探讨 RAL 研究、引擎架构、术语注入机制，或者任何你感兴趣的话题。 欢迎留言或直接联系我们！