技能介绍

要解决的问题

在基于 i18next 的项目中，翻译调用往往散落在组件、模板和工具模块里。新增文案或调整 key 时，靠人工更新各语言 JSON 很容易漏掉调用点，或者留下源码里已经不存在的过期条目。当代码路径变多后，也无法快速判断某个翻译键是否仍在使用。

核心能力与关键步骤

这个技能围绕 i18next-parser 把维护动作收敛成一条可重复的流程：

扫描代码库：按指定范围（例如 app/**/*.{js,hbs}、lib/**/*.{js,hbs}）查找 t(...)、i18next.t(...)、useTranslation 等翻译调用
提取翻译键：从源码中收集 key、默认文案、命名空间和上下文，避免凭记忆整理
更新本地化目录：将结果合并或更新到已有 locale 资源文件，让目录跟随代码而不是反过来

适用边界与注意点

它只处理 翻译键提取和 locale 目录维护，不是通用 i18n 平台，也不会自动产出高质量译文。动态拼接 key、模板语法边界和长期未使用的 key 仍需人工确认；上游项目自 2025 年 9 月起停止维护，长期使用要关注替代工具。

English version:

The problem it solves

In i18next projects, translation calls are often spread across components, templates, and utility modules. When new copy is added or keys change, manually updating every language JSON can miss call sites or leave stale entries that no longer exist in source code. Once the codebase grows, it also becomes hard to tell whether a given key is still used.

Core capabilities and key steps

This skill uses i18next-parser to turn maintenance into a repeatable flow:

Scan the codebase: search selected paths such as app/**/*.{js,hbs} or lib/**/*.{js,hbs} for t(...), i18next.t(...), and useTranslation
Extract translation keys: collect keys, default messages, namespaces, and context from source files instead of working from memory
Update locale catalogs: merge or refresh the existing locale resources so the catalog follows the code rather than the other way around

Scope and caveats

It only covers translation key extraction and locale catalog maintenance, not a full i18n platform and not high-quality translation generation. Dynamically built keys, template-specific syntax, and long-unused keys still need human review. The upstream project stopped being maintained in September 2025, so long-term teams should track a replacement.