i18n-manager（国际化管理器）Skill 是什么？能自动提取硬编码文案吗？

国际化管理器（i18n-manager）：一条命令揪出全部硬编码文案，自动生成翻译文件

它是谁：国际化管理器Skill（英文名 i18n-manager，技能ID 12850），一个专注「硬编码字符串提取」的 AI 技能。
核心能力：扫描项目源码中的用户面向字符串（React/Next.js 的 JSX 文本、模板字面量、Python f-string），生成 en.json 翻译文件，并自动把 Welcome to our app 转换成 welcome_to_our_app 这类翻译键。
最强差异化：每一条提取结果都带文件名与行号，改代码时不用再全项目搜索。
支持框架：React / Next.js、Vue.js、Python、HTML 模板四类场景。
上手成本：一条命令即可跑通，前提是本地有 Python 环境；具体安装入口与细节以官方说明为准。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息

项目	内容
中文名	国际化管理器Skill
英文名	i18n-manager
技能ID	12850
一句话定位	从代码中提取硬编码字符串以进行国际化，并生成翻译文件

它到底解决什么问题？

做过国际化（i18n）的开发者都知道，最痛苦的不是接语言包，而是第一步：把散落在几百个文件里的中文/英文文案一条条找出来。这个过程通常有三种结局——

人工 Ctrl+F 逐个文件翻，几百上千条文案要花好几天；
一边翻一边改代码，改到一半发现漏了某个 jsx 里的文本节点，又要重来；
交给翻译平台，结果因为键名全靠手写，出现 key1、key2、key_2 这种无法维护的命名。

国际化管理器Skill 就是把这一步彻底脚本化：你告诉它源码在哪、翻译文件输出到哪，它把字符串捞出来、建好键、写成 JSON、并告诉你每条文案在哪个文件的第几行。

一键安装的思路与步骤

「一键安装 AI 技能」的核心思路是：技能本身是一份带有脚本与说明的目录（从下方命令路径可以看出，它被放置在 .agent/skills/ 下的技能目录中），安装即"把技能挂进你的 AI 助手/项目环境"，之后用自然语言或命令即可调用。

安装前提（3 条）

你所使用的 AI 编程助手/Agent 平台支持技能（Skill）机制，并能访问项目目录；
本地具备 Python 运行环境（该技能以 .py 脚本形式执行扫描）；
对目标源码目录有读取权限，对输出目录有写入权限。

安装步骤（4 步）

找到并安装：在技能市场/技能列表中搜索「国际化管理器」或「i18n-manager」，也可按技能ID 12850 检索，点击安装。具体入口地址与安装命令以官方说明为准。
确认落地位置：安装完成后，确认项目内存在 .agent/skills/i18n-manager/ 目录，其中包含 scripts/string_extractor.py（提取脚本）与 data/i18n_patterns.json（检测模式配置）。
验证是否生效：直接执行官方给出的用法命令，看是否有扫描输出：
```
python .agent/skills/i18n-manager/scripts/string_extractor.py --path "src/" --output "locales/"
```
若命令被识别并开始扫描、或在 locales/ 目录下生成了 en.json，说明技能已生效。
小范围试跑：正式改造前，建议先把 --path 指向一个子目录（例如某个页面组件所在目录），确认提取结果的质量与键名风格符合团队规范，再对全量源码执行。

提示：由于技能以脚本形式运行在本地项目内，安装后建议检查一次脚本与配置文件的完整性；如安装方式、权限要求与平台相关，请以官方说明为准。

2. 该技能的主要功能和特点

能做什么

扫描硬编码字符串：自动识别源文件中的用户面向文本，覆盖 JSX 文本内容、模板字面量（模板字符串）、Python f-string 这三类最常见的"藏在代码里"的文案。
生成 en.json 翻译文件：扫描结果直接落地为结构化的英文翻译文件，可直接交给翻译同学或翻译平台继续处理。
自动创建翻译键：把原文转换成下划线风格的键名，例如 "Welcome to our app" → welcome_to_our_app，省掉"键名怎么起"的争论。
报告文件与行号：每条提取到的字符串都会标注来源文件与行号，方便开发按图索骥地替换代码。
可配置的检测模式：通过 data/i18n_patterns.json 存放检测模式与常见翻译结构，便于按项目习惯调整识别策略。
多框架覆盖：React / Next.js（JSX 文本）、Vue.js（模板文本）、Python（用户面向字符串）、HTML 模板。

和普通工具比强在哪

比"人肉搜索"快且全：一次扫描整个目录树，不依赖记忆和关键词猜测。
比通用搜索更懂上下文：它识别的是"用户面向字符串"这一语义，而不是简单地匹配所有字符串字面量，减少噪音。
产出即资产：不只是列一份清单，而是直接给出可直接使用的翻译文件骨架。
定位可回溯：文件 + 行号的双重定位，是把"提取结果"变成"可施工改造清单"的关键，这一点很多脚本式方案会忽略。
可被 AI 助手调用：作为技能，它可以由 AI 助手在你的自然语言指令下调用，不需要你记住所有参数细节。

3. 如何使用该技能？

方式一：命令行直接调用（推荐，最稳定）

第 1 步：准备目录结构。 确保你的源码目录（示例中为 src/）与输出目录（示例中为 locales/）路径清晰，输出目录不存在时可先创建。

第 2 步：执行提取命令。

python .agent/skills/i18n-manager/scripts/string_extractor.py --path "src/" --output "locales/"

参数含义（依据官方用法说明）：

--path：要扫描的源码路径，可以是一个目录；
--output：翻译文件的输出目录。

第 3 步：查看输出。 执行后你会得到两类结果：

文件产物：输出目录下的 en.json，形如：
```
{
  "welcome_to_our_app": "Welcome to our app"
}
```
控制台报告：每条提取字符串对应的文件路径与行号，可直接作为改造清单。

第 4 步：人工校对。 重点检查三类内容：① 键名是否语义清晰、是否有重复（不同原文可能生成相同键名）；② 是否误抓了非用户面向的字符串；③ 是否漏抓了动态拼接的文案。

第 5 步：按报告逐处替换源码。 依据行号定位到具体位置，把硬编码文案替换为引用翻译键的写法（具体替换写法取决于你项目所用的 i18n 库，请遵循项目既有约定）。

第 6 步：把 en.json 交给翻译流程。 作为其他语种的基础文件，复制成 zh.json、ja.json 等继续填充。(文件命名与结构建议沿用本技能生成的 en.json 结构，保持一致性。)

方式二：通过 AI 助手自然语言调用

如果你的 AI 编程助手已加载该技能，可以直接下指令，例如：

「用国际化管理器扫描一下 src/ 里所有硬编码的界面文案，把结果输出到 locales/，然后告诉我哪些文件里还有没处理的。」

助手会根据技能说明调用脚本，并把扫描报告整理成易读的清单。

输入示例与输出说明对照

环节	示例
输入	`--path "src/" --output "locales/"`
命中示例	JSX 中的 `Welcome to our app`、Python f-string 中的 `Hello, {name}` 类文案
键名生成	`Welcome to our app` → `welcome_to_our_app`
定位信息	指明该字符串所在的源文件与行号
最终产物	`locales/en.json`

4. 同类型竞品对比分析

国际化提取并不是全新赛道，市面上有一批成熟的工程化方案。下表以本技能为参照，对比几个常见替代思路（各竞品具体功能与用法请以官方说明为准）：

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
国际化管理器Skill（i18n-manager）	AI 技能形态的「文案提取器」	扫描 JSX 文本/模板字面量/Python f-string，生成 `en.json`，自动建键，报告文件与行号	需 Python 环境与技能平台，一条命令即可	项目首次国际化、存量代码摸底、多框架混合项目	优势：开箱即用、产物直接可用、带行号定位、可由 AI 助手调用；不足：仅提供提取与生成，源码替换仍需人工按报告处理
生态型提取工具（如 i18next 生态的 parser 类工具）	与 i18n 框架深度绑定的提取器	从源码提取文案并生成/更新语言文件，通常与框架配置联动	需安装依赖并编写配置文件	已确定使用特定 i18n 框架的中大型项目	优势：与框架集成度高、可持续更新；不足：配置成本较高、跨框架能力弱、对 Python 等非前端代码覆盖有限
编译插件类方案（Babel/构建流程插件）	在构建链路中做文案提取与校验	通过编译器插件在打包过程中抽取消息、生成语言包	需要改动构建配置，理解插件机制	前端工程化程度高、CI 流程完善的团队	优势：与构建流程融合、可持续校验；不足：接入门槛高、出问题排查成本大、对非前端项目不适用
人工检索 + 电子表格整理	完全手工的传统做法	全文搜索、逐条复制、手工编号	零门槛，但耗时最长	文案量极少的小项目、临时应急	优势：无需任何工具；不足：极易遗漏、键名混乱、无行号记录、无法复用

怎么选？

只想快速摸清家底、并且项目语言栈比较杂（React + Vue + Python 混用）→ 优先用国际化管理器Skill；
已经深度使用某个 i18n 框架，且希望提取流程固化进 CI → 生态型工具或编译插件更合适；
两者也可以组合：先用本技能做一次性"存量清理"，再用框架配套工具做"增量维护"。

5. 该技能的典型应用场景与实际体验情况

场景一：React / Next.js 项目首次出海

角色：前端负责人。痛点：产品要上线英文版，代码里全是写在 JSX 里的中文文案，估算有上千条，排期只有两周。 使用方式：先对 src/ 全量执行一次扫描，把 en.json 交给翻译同学；开发则按输出的文件+行号清单并行改造组件。 体验情况：把"找文案"这个原本串行的前置环节变成了可并行的工作，行号定位显著减少了开发在文件里反复搜索的时间。注意：该技能聚焦 JSX 文本内容，对于写在属性里、或由变量拼接生成的提示文案，仍需人工补充。

场景二：Vue 后台管理系统的多语言改造

角色：全栈开发者。痛点：后台系统模板里混着大量提示语与表格列名，人工整理容易漏掉弹窗与表单校验文案。 使用方式：以模板目录为 --path 分批扫描，先出清单再改代码，避免一次性改动过大难以回归。 体验情况：分批扫描的策略更稳，每批改完即可验证。需要注意的是，键名是自动生成的，遇到结构相似的中文（例如多个"保存成功"）时要留意键名冲突，建议在生成后统一做一次键名规范化。

场景三：Python 脚本/服务的日志与提示文案整理

角色：后端开发者。痛点：面向用户的提示写在 f-string 里，与调试日志混在一起，不知道哪些该翻译。 使用方式：用技能扫描 Python 源码中的用户面向字符串，把"给用户看的"和"给开发看的"区分开。 体验情况：这是本技能相对纯前端提取工具的差异点——它支持 Python 的 f-string。但 f-string 中带插值变量的句子，提取后需要人工确认占位符处理方式，不能直接照搬。

场景四：老项目国际化可行性评估

角色：技术经理。痛点：要评估一个运行多年的 HTML 模板项目是否值得做国际化，需要先知道工作量。 使用方式：直接扫描全目录，用提取条数和分布情况估算改造工时。 体验情况：这是一个"轻量高回报"的用法——几秒钟就能拿到一份真实的工作量依据，比开会拍脑袋靠谱。

整体上手评价：上手难度低，一条命令即可跑通，真正的成本在于生成结果之后的校对与源码替换，这部分目前仍需要人工介入，把它理解为"高质量起点"而非"全自动改造"更准确。

6. 该技能能为用户带来的价值

把"人工翻代码"变成"脚本化批量产出"：原本需要按天计的文案盘点工作，压缩为一次命令执行 + 一轮校对；对于上千条文案的项目，节省的时间可以用"人日"来衡量。
降低国际化起步门槛：不需要先读完某个 i18n 框架的全部文档、也不需要先搭好复杂配置，先把文案捞出来，再决定技术方案，顺序更符合真实项目节奏。
统一键名规范：welcome_to_our_app 这类基于原文自动生成的键名，天然具备可读性，避免 key1、text2 式的技术债，长期维护成本更低。
可回溯的改造清单：文件 + 行号的定位能力，让"提取结果"直接变成可分配、可勾选的任务列表，团队协作与进度追踪都更容易。
跨语言栈复用：同一套技能可作用于 React / Next.js、Vue、Python、HTML 模板，混合技术栈团队不用为每种语言各找一套工具。
长期价值：新增页面或模块时，可周期性重跑扫描，形成"增量文案检查"的轻量流程，避免国际化能力随迭代逐渐退化。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装到哪里？ A：在支持技能机制的 AI 助手/技能市场中搜索「国际化管理器」或「i18n-manager」（也可按技能ID 12850 检索）安装，安装后技能会落在项目的 .agent/skills/i18n-manager/ 目录下。装完后运行一次官方给的提取命令，能生成 en.json 即视为生效。具体安装入口与平台差异请以官方说明为准。

Q2：使用它需要会写代码吗？需要什么前置条件？ A：需要使用一条命令，但不需要写代码。前置条件是本地有 Python 运行环境、能访问项目源码目录。如果你使用带技能能力的 AI 助手，也可以直接用自然语言描述需求，由助手代为调用。

Q3：它是收费的吗？ A：本技能自身的计费方式与授权信息以官方说明为准。技能本身以本地脚本形式运行，不产生额外的调用消耗；但若通过 AI 助手调用，可能涉及你所使用平台的额度规则，同样以对应平台说明为准。

Q4：它会不会自动帮我把源码里的文案替换掉？ A：根据技能说明，它提供的能力是「扫描 + 生成翻译文件 + 自动建键 + 报告文件与行号」，即完成提取与产出这一步；源码的具体替换仍需按报告逐处处理，替换写法取决于你项目使用的 i18n 方案。把它当作"高质量起点"而非"全自动改造"更合适。

Q5：它适合谁用？和框架自带的提取工具怎么选？ A：适合三类人：正在做首次国际化的前端/全栈开发者、需要评估存量代码改造工作量的技术负责人、以及语言栈混合（前端 + Python）的团队。如果你已经深度使用某个 i18n 框架并希望把提取固化进 CI，框架配套工具更合适；如果只是想快速摸清家底、一次性清理存量硬编码文案，本技能更快。两者也可以先用本技能做存量、再用框架工具做增量。