Lingo.dev 开源本地化工程工具链实战指南MCP、CLI、CI/CD 与 React 编译器【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexicaLingo.dev 是一套开源本地化工程工具用于将 AI 翻译能力接入 Web 与移动端应用的开发与发布流程并与 Lingo.dev 本地化工程平台连接以获得一致、高质量的翻译结果。本文基于仓库 readme/he.md项目 README 的希伯来语译本与对应源码系统讲解 Lingo React MCP、Lingo CLI、Lingo GitHub Action、Lingo API 与 Lingo Compiler for React 五种工具的定位、命令与配置方式读完即可在自己的项目中落地push 即翻译的持续本地化流水线。快速入门五种工具如何选Lingo.dev 按翻译能力入口把工具分成五类官方 README 用一张速查表做了归纳工具作用快速上手方式Lingo React MCP为 React 应用提供 AI 驱动的 i18n 配置提示词Set up i18nLingo CLI本地化 JSON、YAML、markdown、CSV、PO 文件npx lingo.devlatest runLingo GitHub Action在 GitHub Actions 中实现持续本地化uses: lingodotdev/lingo.devmainLingo Compiler for React构建期本地化 React无需 i18n 包装层插件withLingo()其中 CLI 是其他工具的地基GitHub Action 本质上是在 CI 环境里调用lingo.dev ci命令见 action.ymlMCP 与编译器则在交互式开发与构建阶段使用。本地化引擎默认平台引擎与自带 LLM 两条路线所有工具都可以连接 Lingo.dev 平台 的本地化引擎——由平台托管、带状态的翻译 API。每个引擎会在每次请求中维护字典、品牌语气voice与按语言划分的指令官方文档引用其检索增强本地化Retrieval-Augmented Localization研究称该机制可减少 16.6%–44.6% 的术语错误。同时CLI 也支持自带 LLMBring Your Own LLM从而不必把内容发送到 Lingo.dev 平台。自带 LLM 的能力可以从 packages/cli/package.json 的依赖中直接印证CLI 内置了 OpenAIai-sdk/openai、Anthropicai-sdk/anthropic、Googleai-sdk/google、Mistralai-sdk/mistral、OpenRouteropenrouter/ai-sdk-provider与 Ollamaollama-ai-provider-v2等 provider本地化器localizer在源码 packages/cli/src/cli/localizer 中分化为lingodotdev平台引擎、explicit显式指定模型与pseudo伪本地化三条路径。Lingo.dev MCP给 AI 编码助手装上 i18n 知识在 React 应用中手工配置 i18n 极易出错——官方文档特别指出即使是基于 AI 的编码助手也可能虚构不存在的 API 并破坏路由。Lingo.dev MCP 通过 Model Context Protocol 给 AI 助手提供框架特定的 i18n 知识覆盖 Next.js、React Router 与 TanStack Start可直接在 Claude Code、Cursor、GitHub Copilot Agents 与 Codex 中使用。典型用法是在 AI 助手中直接下达Set up i18n之类的指令由助手基于 MCP 注入的知识完成初始化配置避免幻觉 API。从仓库结构看CLI 还提供了一条 MCP 初始化命令入口packages/cli/src/cli/cmd/init/cursor.ts说明 i18n 初始化流程是可脚本化、可重复执行的。Lingo CLI一条命令本地化六种文件格式Lingo CLI 是整套工具链的核心定位是一条命令本地化 JSON、YAML、markdown、CSV 与 PO 文件npx lingo.devlatest init npx lingo.devlatest runinit负责在项目中生成 i18n 配置文件run执行本地化流水线。关键设计是锁文件lockfile机制CLI 通过i18n.lock跟踪已翻译的内容只有新增或变更的内容才会进入翻译处理未变化的键不会被重复请求翻译从而控制成本并保证增量一致性。仓库根目录与 packages/cli 下都可以看到i18n.lock的真实产物。支持的格式与目录虽然速查表只列了五种格式但从源码 packages/cli/src/cli/loaders 的 loader 实现看实际支持的输入远不止这些除 JSON、YAML、markdown、CSV、PO 之外还包括 MDX/Markdoc、EJS、Twig、MJML、SRT/VTT 字幕、XML、Android 资源、Flutter ARB、Xcode strings/stringsdict/xcstrings、XLIFF、properties、PHP 数组、HTML、纯文本等。每个 loader 都配有独立的解析与写出逻辑并有对应.spec.ts测试覆盖例如 json.ts、yaml.ts、markdown.ts。run 命令的完整参数run命令在 packages/cli/src/cli/cmd/run/index.ts 中定义除了无参数直接运行外还支持以下实用参数参数作用--source-locale code覆盖i18n.json中配置的源语言--target-locale code只处理指定目标语言可重复传入多个--bucket type只处理指定桶类型如 json、yaml、android可重复传入--file pattern按路径子串过滤待处理文件可重复传入--key prefix按点分隔路径前缀过滤键如auth.login--force强制重译所有键绕过变更检测适合更换模型或翻译设置后重新生成--frozen只校验不修改源文件/目标文件/锁文件不同步即失败退出适合 CI/CD 前置校验--estimate仅估算待翻译内容的费用并退出会真实调用 Lingo.dev API 计价结果是估算而非报价--api-key key覆盖 settings 或环境变量中的 API Key--concurrency n并发翻译任务数默认 10上限 10--watch/--debounce ms监听源文件变更自动重译防抖默认 5000ms--pseudo伪本地化模式用重音字符与视觉标记替换字符串不调用任何外部 API用于 UI 国际化就绪性测试--sound翻译完成后播放成功/失败音效资产位于 packages/cli/assets--debug处理前暂停便于附加调试器注意两点约束--estimate不能与--watch或--frozen组合使用run的内部流程是setup → plan → (estimate|frozen) → execute → 汇总源码中plan阶段会先计算变更增量execute阶段再按增量执行翻译任务。Lingo.dev CI/CDpush 即翻译的持续本地化官方文档给出的核心主张是每次 push 都触发本地化缺失的字符串在代码进入生产环境之前就被补齐。支持 GitHub Actions、GitLab CI/CD 与 Bitbucket Pipelines 三种平台——这一点与源码 packages/cli/src/cli/cmd/ci/platforms 下的github.ts、gitlab.ts、bitbucket.ts一一对应。GitHub Action 的最小配置uses: lingodotdev/lingo.devmain with: api-key: ${{ secrets.LINGODOTDEV_API_KEY }}仓库根目录的 action.yml 定义了该 Action 的全部输入可进一步定制行为输入默认值说明versionlatestLingo.dev CLI 版本api-key空Lingo.dev 平台 API Key建议放入仓库 Secretpull-requestfalse是否以 PR 形式提交翻译改动commit-messagefeat: update translations via LingoDotDev提交信息pull-request-titlefeat: update translations via LingoDotDevPR 标题commit-author-name/commit-author-emailLingo.dev/supportlingo.dev提交作者信息working-directory.工作目录process-own-commitsfalse是否处理本 Action 自己产生的提交防止翻译提交再次触发翻译的循环parallelfalse是否并行执行Action 内部实际上把上述输入拼装为一次npx lingo.devversion ci调用因此 CI 的行为与本地ci命令完全一致。对应的 CI 流程实现分为 in-branch直接提交回当前分支与 pull-request创建 PR两种模式见 packages/cli/src/cli/cmd/ci/flows。Lingo.dev API直接从后端代码调用本地化引擎如果需要在业务后端内按需翻译可以直接调用 Lingo.dev API不必经过 CLI。API 提供两类调用方式同步与异步本地化按场景选择即时返回或后台处理异步场景通过webhook投递完成结果按 locale 的故障隔离单个语言失败不会拖垮其他语言的翻译流程WebSocket 实时进度客户端可实时接收翻译进度事件。CLI 底层对 Lingo.dev 平台的调用正是通过 packages/sdk 与 packages/cli/src/cli/sdk 中的 SDK 实现SDK 同样以子路径lingo.dev/sdk对外导出见 packages/cli/package.json 的 exports 字段后端集成可直接复用。Lingo Compiler for React早期 Alpha去掉 t() 与 JSON 的构建期本地化这是当前处于早期 Alpha的实验性方向在构建期完成 React 本地化不再需要 i18n 包装层。开发者直接用英文书写组件编译器在构建时自动识别可翻译字符串并生成翻译版本——没有翻译 key、没有 JSON 字典文件、也没有t()函数。支持 Next.jsApp Router与 Vite React接入方式是withLingo()插件。从仓库 packages/new-compiler 的实现结构看编译器通过 unplugin 体系同时提供 vite.ts、webpack.ts、next.ts 三种接入面核心转换逻辑集中在 transform 目录翻译服务与缓存则由 translation-server 与 translators 承担。仓库同时提供两个可运行的参考项目demo/new-compiler-next16Next.js 16 示例与 demo/new-compiler-vite-react-spaVite React SPA 示例Alpha 阶段的实践方式可参照这两个 demo 的 README 与配置。参与贡献仓库是一个pnpm turborepo monorepo工作区定义见 pnpm-workspace.yaml贡献流程如下Issues在仓库 Issues 中报告 bug 或提交功能请求Pull Requests每个 PR 都必须附带 changeset——运行pnpm new非发布相关改动用pnpm new:empty并确保测试通过后再提交本地开发安装依赖pnpm install运行测试pnpm test构建pnpm build根目录 CONTRIBUTING.md 与 CODE_OF_CONDUCT.md 提供了完整的行为准则与提交规范commitlint 配置见 commitlint.config.js。多语言文档与新增语言项目 README 被翻译为 30 种语言存放于 readme 目录中文版见 readme/zh-Hans.md本篇文章依据的希伯来语版见 readme/he.md。新增语言的方式在根目录 i18n.json 中以 BCP-47 格式添加语言代码提交 Pull Request。这一机制本身也是 Lingo.dev 的自我使用仓库用自己的 CLI 维护各语言 README 与i18n.lock是观察该工具链实际运行效果最直接的样例。仓库根部的横幅图 content/banner.png 即官方使用的项目封面。综上所述从交互式 MCP、命令行增量翻译到 CI 持续本地化、后端 API 与构建期编译器Lingo.dev 提供了覆盖写代码—提交—构建—上线全链条的本地化工程方案无论选择平台引擎还是自带 LLM其增量锁文件与变更检测机制都能保证翻译成本可控、质量可追踪。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lingo.dev 开源本地化工程工具链实战指南：MCP、CLI、CI/CD 与 React 编译器
Lingo.dev 开源本地化工程工具链实战指南MCP、CLI、CI/CD 与 React 编译器【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexicaLingo.dev 是一套开源本地化工程工具用于将 AI 翻译能力接入 Web 与移动端应用的开发与发布流程并与 Lingo.dev 本地化工程平台连接以获得一致、高质量的翻译结果。本文基于仓库 readme/he.md项目 README 的希伯来语译本与对应源码系统讲解 Lingo React MCP、Lingo CLI、Lingo GitHub Action、Lingo API 与 Lingo Compiler for React 五种工具的定位、命令与配置方式读完即可在自己的项目中落地push 即翻译的持续本地化流水线。快速入门五种工具如何选Lingo.dev 按翻译能力入口把工具分成五类官方 README 用一张速查表做了归纳工具作用快速上手方式Lingo React MCP为 React 应用提供 AI 驱动的 i18n 配置提示词Set up i18nLingo CLI本地化 JSON、YAML、markdown、CSV、PO 文件npx lingo.devlatest runLingo GitHub Action在 GitHub Actions 中实现持续本地化uses: lingodotdev/lingo.devmainLingo Compiler for React构建期本地化 React无需 i18n 包装层插件withLingo()其中 CLI 是其他工具的地基GitHub Action 本质上是在 CI 环境里调用lingo.dev ci命令见 action.ymlMCP 与编译器则在交互式开发与构建阶段使用。本地化引擎默认平台引擎与自带 LLM 两条路线所有工具都可以连接 Lingo.dev 平台 的本地化引擎——由平台托管、带状态的翻译 API。每个引擎会在每次请求中维护字典、品牌语气voice与按语言划分的指令官方文档引用其检索增强本地化Retrieval-Augmented Localization研究称该机制可减少 16.6%–44.6% 的术语错误。同时CLI 也支持自带 LLMBring Your Own LLM从而不必把内容发送到 Lingo.dev 平台。自带 LLM 的能力可以从 packages/cli/package.json 的依赖中直接印证CLI 内置了 OpenAIai-sdk/openai、Anthropicai-sdk/anthropic、Googleai-sdk/google、Mistralai-sdk/mistral、OpenRouteropenrouter/ai-sdk-provider与 Ollamaollama-ai-provider-v2等 provider本地化器localizer在源码 packages/cli/src/cli/localizer 中分化为lingodotdev平台引擎、explicit显式指定模型与pseudo伪本地化三条路径。Lingo.dev MCP给 AI 编码助手装上 i18n 知识在 React 应用中手工配置 i18n 极易出错——官方文档特别指出即使是基于 AI 的编码助手也可能虚构不存在的 API 并破坏路由。Lingo.dev MCP 通过 Model Context Protocol 给 AI 助手提供框架特定的 i18n 知识覆盖 Next.js、React Router 与 TanStack Start可直接在 Claude Code、Cursor、GitHub Copilot Agents 与 Codex 中使用。典型用法是在 AI 助手中直接下达Set up i18n之类的指令由助手基于 MCP 注入的知识完成初始化配置避免幻觉 API。从仓库结构看CLI 还提供了一条 MCP 初始化命令入口packages/cli/src/cli/cmd/init/cursor.ts说明 i18n 初始化流程是可脚本化、可重复执行的。Lingo CLI一条命令本地化六种文件格式Lingo CLI 是整套工具链的核心定位是一条命令本地化 JSON、YAML、markdown、CSV 与 PO 文件npx lingo.devlatest init npx lingo.devlatest runinit负责在项目中生成 i18n 配置文件run执行本地化流水线。关键设计是锁文件lockfile机制CLI 通过i18n.lock跟踪已翻译的内容只有新增或变更的内容才会进入翻译处理未变化的键不会被重复请求翻译从而控制成本并保证增量一致性。仓库根目录与 packages/cli 下都可以看到i18n.lock的真实产物。支持的格式与目录虽然速查表只列了五种格式但从源码 packages/cli/src/cli/loaders 的 loader 实现看实际支持的输入远不止这些除 JSON、YAML、markdown、CSV、PO 之外还包括 MDX/Markdoc、EJS、Twig、MJML、SRT/VTT 字幕、XML、Android 资源、Flutter ARB、Xcode strings/stringsdict/xcstrings、XLIFF、properties、PHP 数组、HTML、纯文本等。每个 loader 都配有独立的解析与写出逻辑并有对应.spec.ts测试覆盖例如 json.ts、yaml.ts、markdown.ts。run 命令的完整参数run命令在 packages/cli/src/cli/cmd/run/index.ts 中定义除了无参数直接运行外还支持以下实用参数参数作用--source-locale code覆盖i18n.json中配置的源语言--target-locale code只处理指定目标语言可重复传入多个--bucket type只处理指定桶类型如 json、yaml、android可重复传入--file pattern按路径子串过滤待处理文件可重复传入--key prefix按点分隔路径前缀过滤键如auth.login--force强制重译所有键绕过变更检测适合更换模型或翻译设置后重新生成--frozen只校验不修改源文件/目标文件/锁文件不同步即失败退出适合 CI/CD 前置校验--estimate仅估算待翻译内容的费用并退出会真实调用 Lingo.dev API 计价结果是估算而非报价--api-key key覆盖 settings 或环境变量中的 API Key--concurrency n并发翻译任务数默认 10上限 10--watch/--debounce ms监听源文件变更自动重译防抖默认 5000ms--pseudo伪本地化模式用重音字符与视觉标记替换字符串不调用任何外部 API用于 UI 国际化就绪性测试--sound翻译完成后播放成功/失败音效资产位于 packages/cli/assets--debug处理前暂停便于附加调试器注意两点约束--estimate不能与--watch或--frozen组合使用run的内部流程是setup → plan → (estimate|frozen) → execute → 汇总源码中plan阶段会先计算变更增量execute阶段再按增量执行翻译任务。Lingo.dev CI/CDpush 即翻译的持续本地化官方文档给出的核心主张是每次 push 都触发本地化缺失的字符串在代码进入生产环境之前就被补齐。支持 GitHub Actions、GitLab CI/CD 与 Bitbucket Pipelines 三种平台——这一点与源码 packages/cli/src/cli/cmd/ci/platforms 下的github.ts、gitlab.ts、bitbucket.ts一一对应。GitHub Action 的最小配置uses: lingodotdev/lingo.devmain with: api-key: ${{ secrets.LINGODOTDEV_API_KEY }}仓库根目录的 action.yml 定义了该 Action 的全部输入可进一步定制行为输入默认值说明versionlatestLingo.dev CLI 版本api-key空Lingo.dev 平台 API Key建议放入仓库 Secretpull-requestfalse是否以 PR 形式提交翻译改动commit-messagefeat: update translations via LingoDotDev提交信息pull-request-titlefeat: update translations via LingoDotDevPR 标题commit-author-name/commit-author-emailLingo.dev/supportlingo.dev提交作者信息working-directory.工作目录process-own-commitsfalse是否处理本 Action 自己产生的提交防止翻译提交再次触发翻译的循环parallelfalse是否并行执行Action 内部实际上把上述输入拼装为一次npx lingo.devversion ci调用因此 CI 的行为与本地ci命令完全一致。对应的 CI 流程实现分为 in-branch直接提交回当前分支与 pull-request创建 PR两种模式见 packages/cli/src/cli/cmd/ci/flows。Lingo.dev API直接从后端代码调用本地化引擎如果需要在业务后端内按需翻译可以直接调用 Lingo.dev API不必经过 CLI。API 提供两类调用方式同步与异步本地化按场景选择即时返回或后台处理异步场景通过webhook投递完成结果按 locale 的故障隔离单个语言失败不会拖垮其他语言的翻译流程WebSocket 实时进度客户端可实时接收翻译进度事件。CLI 底层对 Lingo.dev 平台的调用正是通过 packages/sdk 与 packages/cli/src/cli/sdk 中的 SDK 实现SDK 同样以子路径lingo.dev/sdk对外导出见 packages/cli/package.json 的 exports 字段后端集成可直接复用。Lingo Compiler for React早期 Alpha去掉 t() 与 JSON 的构建期本地化这是当前处于早期 Alpha的实验性方向在构建期完成 React 本地化不再需要 i18n 包装层。开发者直接用英文书写组件编译器在构建时自动识别可翻译字符串并生成翻译版本——没有翻译 key、没有 JSON 字典文件、也没有t()函数。支持 Next.jsApp Router与 Vite React接入方式是withLingo()插件。从仓库 packages/new-compiler 的实现结构看编译器通过 unplugin 体系同时提供 vite.ts、webpack.ts、next.ts 三种接入面核心转换逻辑集中在 transform 目录翻译服务与缓存则由 translation-server 与 translators 承担。仓库同时提供两个可运行的参考项目demo/new-compiler-next16Next.js 16 示例与 demo/new-compiler-vite-react-spaVite React SPA 示例Alpha 阶段的实践方式可参照这两个 demo 的 README 与配置。参与贡献仓库是一个pnpm turborepo monorepo工作区定义见 pnpm-workspace.yaml贡献流程如下Issues在仓库 Issues 中报告 bug 或提交功能请求Pull Requests每个 PR 都必须附带 changeset——运行pnpm new非发布相关改动用pnpm new:empty并确保测试通过后再提交本地开发安装依赖pnpm install运行测试pnpm test构建pnpm build根目录 CONTRIBUTING.md 与 CODE_OF_CONDUCT.md 提供了完整的行为准则与提交规范commitlint 配置见 commitlint.config.js。多语言文档与新增语言项目 README 被翻译为 30 种语言存放于 readme 目录中文版见 readme/zh-Hans.md本篇文章依据的希伯来语版见 readme/he.md。新增语言的方式在根目录 i18n.json 中以 BCP-47 格式添加语言代码提交 Pull Request。这一机制本身也是 Lingo.dev 的自我使用仓库用自己的 CLI 维护各语言 README 与i18n.lock是观察该工具链实际运行效果最直接的样例。仓库根部的横幅图 content/banner.png 即官方使用的项目封面。综上所述从交互式 MCP、命令行增量翻译到 CI 持续本地化、后端 API 与构建期编译器Lingo.dev 提供了覆盖写代码—提交—构建—上线全链条的本地化工程方案无论选择平台引擎还是自带 LLM其增量锁文件与变更检测机制都能保证翻译成本可控、质量可追踪。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考