Lingo.devreplexica开源本地化工程工具全景指南从 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本仓库 replexica是一套开源本地化工程工具集通过连接 Lingo.dev 本地化工程平台为开发团队提供一致、高质量的翻译能力。本文以仓库根目录的 README 总览文档 readme/bho.md 为核心骨架结合仓库源码与配置系统讲解 MCP、CLI、GitHub Action、API 与 React Compiler 五大组件的功能定位、快速上手命令与底层实现机制帮助你根据项目形态选择最合适的本地化接入方式。项目定位开源本地化工程工具Lingo.dev 的定位是开源本地化工程工具其核心思路是开发团队在代码仓库中使用开源工具与命令行翻译能力则由 Lingo.dev 本地化工程平台有状态翻译 API提供。文档原文将其描述为 Open-source localization engineering tools. Connect to Lingo.dev localization engineering platform for consistent, quality translations.开源本地化工程工具连接 Lingo.dev 本地化工程平台获得一致、优质的翻译readme/bho.md 中同样保留了这一定位描述。从仓库结构看这是一个 pnpm turborepo 的 monorepo见根目录 package.json 的turbo build/test/typecheck脚本与packageManager: pnpm11.10.0核心工作区包括packages/cliCLI 与 SDK、packages/compilerReact 编译器、packages/sdk后端 SDK、packages/spec配置与格式规范、packages/locales语言代码等印证了一套工具集的定位。快速上手工具矩阵一览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 实际提供了init与run两步命令见后文Lingo.dev CLI小节GitHub Action 底层调用的是 CLI 的ci命令见 action.yml 中的npx lingo.dev${{ inputs.version }} ci。README 也明确指出这些工具可以连接平台上的本地化引擎也可以自带 LLM。本地化引擎有状态的翻译 API所有工具背后都对接本地化引擎localization engines——你在 Lingo.dev 平台上创建的有状态翻译 API。README 强调每个引擎会在每次请求中持久化术语表glossary、品牌语气brand voice与按语言区分的指令per-locale instructions据此将术语错误减少 16.6%–44.6%该数据来自官方检索增强本地化研究报告README 中如实引用当然也可以选择在 CLI 中接入自己的 LLM。这一设计在 packages/sdk/src/index.ts 的 SDK 实现中有清晰印证engineParamsSchema定义了engineId引擎标识、apiUrl、batchSize、maxRetries、retryDelayMs等参数本地化请求支持reference参考译文与hints提示词等字段——这些正是术语表与品牌指令在 API 层的数据载体。Lingo.dev MCP让 AI 助手正确配置 React i18n在 React 应用中手工配置 i18n 极易出错即使是 AI 编码助手也常会幻想出不存在的 API、破坏路由。Lingo.dev MCP 的解法是为 AI 助手提供框架特定的结构化 i18n 知识覆盖 Next.js、React Router 和 TanStack Start兼容 Claude Code、Cursor、GitHub Copilot Agents 与 Codex。对开发者而言在 AI 工具中启用该 MCP 后只需给出提示词Set up i18n即可获得符合框架规范的 i18n 配置建议。仓库中 demo/new-cli 与 demo/new-compiler-next16、demo/new-compiler-vite-react-spa 等演示项目展示了不同框架下接入本地化的实际形态可作为理解 MCP 输出目标的参考。Lingo.dev CLI一条命令本地化多格式文件安装与两条核心命令CLI 通过 npm 分发包名lingo.dev提供lingo与lingo.dev两个 bin 入口见 packages/cli/package.json使用 Node.js 18。README 给出的两条命令是npx lingo.devlatest init npx lingo.devlatest runinit在项目中初始化本地化配置生成i18n.json、settings.jsonc等run执行本地化流水线读取配置、计算变更、调用翻译并写回目标语言文件。支持的文件格式README 明确列出 JSON、YAML、Markdown、CSV、PO 五类核心格式。从 packages/cli/src/loaders 的 loader 实现看实际支持远不止这些还包括 Android XML、Flutter ARB、iOS Xcode strings/xcstrings/stringsdict、XLIFF、SRT/VTT 字幕、PHP、properties、Markdoc、MDX、MJML、EJS、Twig、TXT、HTML、JSON5/JSONC 等且仓库 packages/cli/demo 下为每种格式都提供了en/es示例文件例如 packages/cli/demo/json/en/example.json、packages/cli/demo/yaml/en/example.yml 与 packages/cli/demo/po/en/example.po。README 中一条命令本地化多格式文件的描述是保守的说法实际覆盖面更广。Lockfile只翻译新增与变更内容README 特别强调了 lockfile 机制锁定文件跟踪已本地化的内容——仅处理新增或更改的内容。仓库中 packages/cli/i18n.lock 与根目录 i18n.lock 即为实例lockfile 的实现位于 packages/cli/src/utils/lockfile.ts配套 packages/cli/src/cli/cmd/lockfile.ts 命令与 packages/cli/src/cli/lockfile.spec.ts 测试。这一机制让增量翻译成为可能只有新增或内容发生变化的 key 才会被重新翻译既省成本又保证已审校译文不被覆盖。核心运行参数来自 run 命令源码packages/cli/src/cli/cmd/run/index.ts 是run命令的入口它定义了丰富的可选项可精确控制一次翻译的范围与行为--source-locale code覆盖i18n.json中的源语言用于本次运行--target-locale code只处理指定目标语言可重复传入多个--bucket type只处理指定 bucket 类型如json、yaml、android可重复--file pattern按路径子串过滤 bucket 文件例如messages.json或locale/--key prefix按点分路径前缀过滤 key例如auth.login匹配所有以auth.login开头的 key--force绕过变更检测强制重译所有 key适合换模型或改翻译设置后重生成--frozen只校验不修改源文件、目标文件、lockfile 不同步即失败退出适合 CI/CD 前置校验--api-key key覆盖 settings 或环境变量中的 API key--concurrency n并发翻译任务数默认 10最大 10--watch持续监听源文件变化并自动重译配合--debounce ms默认 5000ms 防抖--sound完成时播放成功/失败音效资产见 packages/cli/assets--pseudo伪本地化模式用带重音符号的字符与视觉标记翻译全部字符串不调用任何外部 API用于测试界面 i18n 就绪度--estimate打印待翻译内容的预估成本后退出不实际翻译不能与--watch/--frozen组合。run的执行流程为 setup → plan →可选 estimate→ frozen → execute → 输出摘要最后按结果设置退出码--watch模式下完成后进入文件监听循环。默认引擎或自带 LLMCLI 默认使用你在 Lingo.dev 平台创建的本地化引擎也可以接入自己的 LLM。README 列举了 OpenAI、Anthropic、Google、Mistral、OpenRouter、Ollama 六个供应商packages/cli/package.json 的依赖ai-sdk/openai、ai-sdk/anthropic、ai-sdk/google、ai-sdk/mistral、openrouter/ai-sdk-provider、ollama-ai-provider-v2与之完全对应。翻译器的实现位于 packages/cli/src/localizerlingodotdev.ts对接平台引擎、explicit.ts对接显式 LLM、pseudo.ts伪本地化。杂项命令除init、run外CLI 还提供ci供 CI/CD 平台调用、config get/set/unset配置读写、show files/locale/ignored-keys/locked-keys/preserved-keys查看状态、status、purge、cleanup、login/logout等命令见 packages/cli/src/cli/cmd帮助你在本地排查 lockfile、忽略键与锁定键的状态。Lingo.dev CI/CD在流水线中持续本地化持续本地化continuous localization解决的是代码改了、翻译没跟上的问题每次 push 都触发本地化缺失字符串在代码进入生产环境前被自动补齐。README 声明支持 GitHub Actions、GitLab CI/CD 与 Bitbucket Pipelines。GitHub Action 用法README 给出的最小 YAML 片段为uses: lingodotdev/lingo.devmain with: api-key: ${{ secrets.LINGODOTDEV_API_KEY }}仓库根目录的 action.yml 是这条 Action 的真实定义它把参数逐一带入底层 CLI 的ci命令runs: using: composite steps: - name: Run run: | npx lingo.dev${{ inputs.version }} ci \ --api-key ${{ inputs.api-key }} \ --pull-request ${{ inputs.pull-request }} \ --commit-message ${{ inputs.commit-message }} \ --pull-request-title ${{ inputs.pull-request-title }} \ --commit-author-name ${{ inputs.commit-author-name }} \ --commit-author-email ${{ inputs.commit-author-email }} \ --working-directory ${{ inputs.working-directory }} \ --process-own-commits ${{ inputs.process-own-commits }} \ --parallel ${{ inputs.parallel }} shell: bashAction 完整输入参数除api-key外Action 还暴露了以下可配置输入均有默认值versionLingo.dev CLI 版本默认latestpull-request是否以 PR 形式提交翻译变更默认falsefalse 时直接提交到当前分支commit-message提交信息默认feat: update translations via LingoDotDevpull-request-titlePR 标题默认同上commit-author-name/commit-author-email提交作者信息默认Lingo.dev/supportlingo.devworking-directory工作目录默认.process-own-commits是否处理该 Action 自己提交的内容默认false防止触发循环翻译parallel是否并行运行默认false。GitLab 与 Bitbucket 的接入同样由 CLI 的ci命令支撑——仓库中 packages/cli/src/cli/cmd/ci/platforms 下实现了github.ts、gitlab.ts、bitbucket.ts三个平台适配器对应 pull-request 与 in-branch 两种提交流程见 packages/cli/src/cli/cmd/ci/flows。Lingo.dev API / SDK从后端代码直接调用引擎当本地化需要由业务后端触发而非构建或 CI 流程时可以绕过 CLI 直接调用本地化引擎README 描述其支持同步与异步本地化、webhook 结果投递、按语言环境隔离失败、通过 WebSocket 实时查看进度。仓库中 packages/sdk 与 packages/cli/src/sdk/index.ts 提供了 TypeScript SDK 实现。以 packages/sdk/src/index.ts 为例SDK 暴露engineParamsSchema引擎级参数apiKey、apiUrl、engineId、batchSize默认 25、maxRetries默认 3 次指数退避重试、retryDelayMs默认 500ms 等localizationParamsSchema单次请求参数sourceLocale、targetLocale、可选的reference参考译文、hints提示、filePath、triggerType: cli | ci等CostEstimate类型/process/estimate接口返回的近似成本估算字符数 → token 数的启发式非正式报价。同步/异步模式、webhook 与 WebSocket 机制从 SDK 的类型与常量中可以推断其为引擎侧能力CLI 的ci流程packages/cli/src/cli/cmd/ci/index.ts正是通过这类接口在后端完成拉取变更 → 翻译 → 提交/开 PR的闭环。Lingo Compiler for React无 i18n 包装器的构建时本地化核心理念Lingo Compiler for React早期 Alpha是文档矩阵中技术形态最特别的一个构建时本地化彻底去掉 i18n 包装层。用纯英文编写组件编译器在构建时识别可翻译字符串并生成本地化变体——没有翻译 key、没有 JSON 文件、没有t()函数。当前支持 Next.jsApp Router与 Vite React。配置方式withLingo 插件README 矩阵给出的快速命令是withLingo()插件。旧编译器迁移文档 packages/compiler/README.md 给出了新旧两代编译器的配置对照新版lingo.dev/compiler用法如下Next.jsApp Routerimport type { NextConfig } from next; import { withLingo } from lingo.dev/compiler/next; const nextConfig: NextConfig {}; export default async function (): PromiseNextConfig { return await withLingo(nextConfig, { sourceLocale: en, targetLocales: [es, fr], models: lingo.dev, }); }Vite Reactimport { defineConfig, type UserConfig } from vite; import react from vitejs/plugin-react; import { withLingo } from lingo.dev/compiler/vite; const viteConfig: UserConfig { plugins: [react()], }; export default defineConfig(async () await withLingo(viteConfig, { sourceLocale: en, targetLocales: [es, fr], models: lingo.dev, }) );仓库中的实现与演示新一代编译器位于 packages/new-compiler其插件体系packages/new-compiler/src/plugin包含next.ts、vite.ts、webpack.ts、unplugin.ts以及 Next.js 各加载器next-config-loader、next-locale-server-loader等翻译服务则位于 packages/new-compiler/src/translation-server。仓库提供了两个可直接运行/构建的演示项目demo/new-compiler-next16Next.js 16 应用含 App Router 页面与计数器等组件如 demo/new-compiler-next16/components/Counter.tsxdemo/new-compiler-vite-react-spaVite React SPApublic/translations下已有de/en/es/fr四种语言的 JSON 翻译产物。两者可作为理解构建时生成本地化变体这一工作方式的最小实验对象。仓库自身的 dogfoodingi18n 配置与多语言文档Lingo.dev 的一个特色是项目自己用自己。根目录 i18n.json 就是一份真实配置locale.source为entargets列出 27 种目标语言含bhobuckets.mdx.include指向readme/[locale].md——这正是 readme 目录下 29 个语言版本 README 的生成来源。任何读者都可以参考这份配置理解i18n.json的字段语义locale.source源语言、locale.targets目标语言数组、buckets.名称.includeglob 匹配规则[locale]为语言占位符。README 还说明了为项目新增一种语言的步骤使用 BCP-47 格式将语言代码加入 i18n.json提交 Pull Request。参与开发与本地构建README 的贡献章节明确了开发与测试流程亦与根 package.json 脚本一致这是一个 pnpm turborepo 的 monorepo贡献者应通过 Issue 报告问题、通过 PR 提交改动且每个 PR 都需要 changeset发布变更用pnpm new非发布变更用pnpm new:empty。常用命令pnpm install # 安装依赖 pnpm test # 运行测试turbo 并行执行各包 vitest pnpm build # 构建全部包仓库根目录还提供 Dockerfile 与 action.yml前者可用于容器化运行环境后者即前文分析的 GitHub Action 定义开发细节可进一步参考 CLAUDE.md 与 packages/cli/WATCH_MODE.md。小结如何选择接入方式综合 README 文档与仓库源码可以根据团队工作流选择合适的工具组合AI 辅助配置阶段用 Lingo React MCP 在 Claude Code / Cursor / Copilot Agents / Codex 中快速、正确地完成 i18n 搭建日常增量翻译用 Lingo CLIinitrunlockfile 保证只翻译新增与变更内容--watch可本地实时翻译--estimate可先看成本持续本地化在 GitHub Actions / GitLab CI / Bitbucket Pipelines 中接入lingo.dev的ci流程push 即翻译产物可以是直接提交或自动创建的 PR后端集成用 SDK/API 在业务代码中直接调用引擎配合 webhook 与 WebSocket 获取结果与进度全新 React 项目尝试 Compiler for React早期 Alpha用withLingo()插件在构建期完成本地化彻底告别 key 与t()样板代码。【免费下载链接】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），仅供参考