i18n-LE

i18n-LE：看起来完成了的语言区域

只需按一下按键，即可根据源语言区域审查翻译目录
i18next、next-intl、VS Code 语言包和 Flutter ARB——检查键和令牌，绝不显示翻译字符串

觉得有用？ 点赞或评分能帮助其他开发者找到它 — ★ GitHub · ★ Open VSX · ★ Marketplace

它的功能

西班牙语版本上周发布了，从那以后，指标页面对每位用户都显示着 {{periodo}}。目录里的键一个不缺，也能通过解析。占位符经过机器翻译后，名称也被翻译了；代码编译毫无问题，页面却显示了字面文本。

打开目录，运行 i18n-LE: Audit Catalogues，它所属的目录集便会根据源语言区域进行审查：缺少键或多出键的语言区域、翻译中被删掉或改名的占位符、其他库约定中的结构、空值、重复定义的键，以及在一个语言区域中是对象、在另一个语言区域中却是字符串的路径。报告会在编辑器旁打开。也可以在资源管理器中对任意文件夹运行。支持 VS Code 以及 Cursor 和 VSCodium 等基于 VS Code 的编辑器（可从 Open VSX 安装）。

• 发布前 — 这个语言区域可以发布了吗，还是只是看起来可以？
• 机器翻译后 — 通过令牌名称捕获从 {{timeframe}} 变成 {{periodo}} 的情况
• 审查译者的拉取请求时 — 无需阅读译文，即可查看结构发生变化的键

报告中绝不会包含翻译字符串。 报告只列出键、占位符令牌、计数和结构；通过证明某个字符串与源字符串逐字节相同来识别未翻译的字符串，而不会显示该字符串。它不会改写任何内容。

安装

首先判断你使用的是哪个库

{name} 在 next-intl 中是占位符，在 i18next 中则是字面文本；{{ name }} 在 i18next 中是变量，在 ICU 中则是包住单词的字面花括号。光看字节无法判断这一点，因此读取目录前会先识别库，占位符语法、复数模型以及哪些键属于元数据，都由识别结果决定。

共有五种判断依据，任意两种一致即可识别：清单依赖项（package.json、pubspec.yaml）、配置文件、目录布局、目录自身的语法，以及源代码中的调用位置。ARB 文件中，@@locale 与 @key 元数据并列时，仅凭这一点就足以判断。如果没有任何依据一致，或有两个库同时匹配，工具会拒绝判断并列出发现的内容，而不是擅自选择一个。设置 i18n-le.library 可跳过识别。

VS Code 扩展的 package.nls.json 位于根目录，而其翻译则位于其他位置；这两部分会作为一个整体读取。读取源文件仅用于判断所用的库，绝不会据此生成问题报告。

检查内容

一个目录就是基准，绝不会合并所有目录——合并会让一位译者的拼写错误变成其他所有人的缺失键。基准是唯一的英文目录，或 i18n-le.source 指定的目录。复数类别会折叠到其基础键，因此波兰语中的合法 _few 不会被视为多余键；本工具有意不检查复数类别是否完整。

在 AI Agent 中使用

同一引擎也可作为 MCP 服务运行，因此 Agent 可以直接调用它，而不必拿到 25 份目录后自行逐一比对。

check_catalogues(library, files, source?, keysAreSource?, maxResults?)

工具接收目录内容和库名称 — 它无法查看项目，因此无法识别库，也不会猜测。它会以数据形式返回与编辑器中显示的相同报告，默认最多包含 500 条发现，并通过 meta.truncated 标记是否截断。它不会读取文件，也不会发起网络请求。该工具以 i18n-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/i18n-le 的名称发布在 MCP 注册表 中。它的响应与 Rust CLI 服务完全一致：两者使用同一套语料运行，差异测试会向两者输入数千组生成的目录集（包括损坏的目录，此时两者都会报告解析器自身的错误信息和位置），并比较每一条响应。

{
  "mcpServers": {
    "i18n-le": {
      "command": "npx",
      "args": ["-y", "i18n-le-mcp"]
    }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y i18n-le-mcp

CLI

同一项审计也可以在终端或 CI 步骤中运行：Rust CLI 位于 crate/，并与扩展共用一套语料 — crate/fixtures/ — 确保两者读取目录的方式完全一致。同一命令行也以 i18n-le 的名称发布在 npm 上，适用于装有 Node 但没有 Rust 的机器；CI 会在三种操作系统上逐字节验证其与 crate 的一致性。

通过 npm（i18n-le）或 crates.io（i18n-le）**安装。**两者都会安装同一个 i18n-le 命令。

npm install -g i18n-le   # or run it once: npx i18n-le
cargo install i18n-le

i18n-le locales/                       # the set in that directory; JSON on stdout when piped
i18n-le --system vscode-l10n l10n/     # name the library, skip identification
i18n-le --fail-on untranslated locales/
i18n-le mcp                            # the same audit over MCP on stdio

退出代码就是 API — 0 表示无问题，1 表示发现问题，2 表示问题本身格式错误（未识别到库、识别到两个库，或没有唯一来源）。完全没有找到目录时返回 0：没有需要检查的内容。

命令

默认情况下，没有命令绑定快捷键。可在编辑器的 键盘快捷方式 中为任意命令设置快捷键。

设置

语言

除英语外，支持 12 种语言：

德语 · 西班牙语 · 法语 · 印度尼西亚语 · 意大利语 · 日语 · 韩语 · 葡萄牙语（巴西）· 俄语 · 乌克兰语 · 越南语 · 简体中文

两部分内容均已覆盖：清单（命令标题、设置名称和描述），以及扩展运行时显示的所有内容（通知、状态栏和报告标题）。拒绝请求时给出的理由使用引擎的英文，与 CLI 中的相同。

隐私与安全

• 不访问网络。 扩展绝不会向任何地方发送数据。telemetryEnabled 设置只会将事件写入可供检查的本地输出通道（i18n-LE）。
• 报告、通知或 MCP 边界中绝不会出现翻译后的值。 键是有意设定的例外；如果布局将英文句子用作键，就会显示该英文。
• MCP 服务同样遵守这一原则。 它将内容作为参数接收并返回数据：不访问文件系统、不进行网络调用，也不收集遥测数据。如果翻译内容进入标准输出，check:mcp-bundle 会导致构建失败。
• 错误通知会隐去主目录和类似凭据的片段。
• 评分提示最多出现两次。 第 3 次成功使用时，扩展会询问一次你是否愿意为其评分；如果你选择 稍后 或关闭提示，则会在第 20 次使用时再询问一次。选择 不再询问 后将不再显示提示。自行将 notificationsLevel 设置为 important 或 silent，也会关闭该提示。计数保存在 VS Code 的扩展存储中，不会发送到任何地方；选择 评分 后，会在浏览器中打开你安装扩展的平台页面——VS Code Marketplace 或 Open VSX。

文档

性能

在 Apple M5 Pro、24 GB RAM、Node 24.3.0 上预热后运行 7 次，取中位数。输入由 scripts/benchmark.ts 生成，而非检入仓库，因此上面的大小正是实测值。运行 bun run benchmark 即可复现。

这些数据因机器而异，不会作为 CI 的断言——以基准测试作为构建门槛，只能反映运行器当时有多忙。

测试

18 个文件中共有 266 个测试用例，此外还有一个在真实 VS Code 扩展宿主中运行的集成测试套件，以及一个将构建好的 .vsix 安装到干净配置文件中的端到端测试。

数据由 scripts/coverage-readme.js 根据一次真实运行生成：coverage/coverage-summary.json 和 coverage/test-results.json；如果本节内容发生偏差，CI 会失败。运行 bun run test:coverage 可复现，测试用例数以 vitest 打印的为准。

LE 系列的更多工具

十六款单一用途工具，助力每个模型完成眼前的工作。每款工具都提供 Rust CLI 和 MCP 服务。访问一个页面即可了解全部：letools.dev

提取内容

• String-LE — 提取代码库中的所有字符串，方便人们阅读
• Numbers-LE — 提取代码库中所有硬编码数字，方便人们检查
• Units-LE — 提取所有带单位的量并进行标准化，并明确拒绝无法消除歧义的项目
• Dates-LE — 提取所有日期和时间戳，以及每个日期和时间戳解析出的确切时刻
• IDs-LE — 提取所有 UUID、ULID、NanoID、ObjectId 和 Snowflake，并解码其中的时间
• IPs-LE — 提取所有 IP 地址、CIDR 块和 MAC 地址，进行标准化并按范围分类
• URLs-LE — 提取代码库中的所有 URL，并标明其协议和确切位置
• Paths-LE — 提取代码库中的所有文件路径，并说明它们是否仍指向某个对象
• Colors-LE — 提取代码库中的所有颜色，并指出哪些颜色不在你的调色板中

检查内容

• Regex-LE — 查找代码库中的所有正则表达式，并报告哪些可能导致灾难性回溯
• Versions-LE — 查找一个依赖项在仓库各清单文件中的约束差异
• i18n-LE — 识别项目使用的 i18n 库，然后按照该库的规则审核其目录
• Scrape-LE — 在编写抓取器之前检查页面是否可抓取，并说明何时无法判断

守护安全

• Secrets-LE — 查找代码库中的硬编码凭据，并确保绝不将其打印到报告中
• EnvSync-LE — 比较目录树中的 dotenv 文件，并指出哪些文件缺少哪些键
• Unicode-LE — 查找会隐藏含义的 Unicode 字符——双向控制字符、不可见字符、同形异义字符、混合文字

每款工具都独立运行：没有共享 crate，也没有发布的核心库。两款工具得出相同结论时，只是因为同一个答案碰巧正确了两次。

联系 — nolindnaidoo.com · GitHub · LinkedIn

nolindnaidoo 的其他项目

Rust — pixelcoords 和 pixelactions 构成一个循环：pixelcoords 负责回答在哪里，pixelactions 则在该位置执行操作。它们各有自己的工具和风格，并不属于 LE 系列。

• pixelcoords — 冻结屏幕画面、标记区域，并获取像素级精确的坐标和裁剪图 pixelcoords.dev · crates.io · docs.rs
• pixelactions — 使用经人工验证的坐标执行交互，并确认操作已生效 pixelactions.dev · crates.io · docs.rs

许可证

MIT © nolindnaidoo