每一个前端开发者的 i18n 噩梦做过国际化的同学心里大概都有本血泪账。i18n 本质上不是技术难题它既没有高并发压力也没有复杂的算法。它的难在于**“琐碎”和“反人性”**。设想一下你平时的开发链路发现文案在 UI 稿里看到一段“确认删除”。打断思维停下手里的业务逻辑去想这个 key 叫common.delete_confirm还是action.delete_item人肉搬运打开zh-CN.json跳到文件末尾加上键值对再打开en.json加上空的 key或者去翻词典翻译一下。代码替换回到业务代码把中文删掉写上t(common.delete_confirm)。循环往复一个页面如果有 50 处文案你就得重复这套动作 50 次。这不叫编程这叫“代码搬运工”。更可怕的是随着项目变大你会发现en.json漏了 key或者zh-CN.json里有一堆没人用的“僵尸文案”整个国际化体系开始坍塌。这就是我开发 I18n Workflow Helper 的原因把国际化从“额外负担”拉回开发流程本身。重新定义是 Workflow不是 Framework市面上有很多 i18n 库i18next, vue-i18n, react-intl它们解决的是运行时如何显示语言。但 I18n Workflow Helper 解决的是开发时如何维护这些语言。它不改变你的代码逻辑它只是你 VS Code 里的一个“超级助手”。核心功能深度解析一、文案提取不再人肉搬运当你选中文中一段硬编码的中文时按下快捷键或通过 Command Palette自动替换代码里的span确认/span瞬间变成span{t(common.confirm)}/span。跨文件同步它会智能识别你的locales目录同时在zh-CN.json写入中文在en.json或其它语言自动补齐这个 key并预留空值或默认值。底层逻辑保持思维连贯性。你不需要离开当前的业务文件所有的 JSON 维护工作都在后台静默完成。二、工作区扫描给项目做一次国际化体检很多项目在上线前最怕的就是漏掉哪里的中文没改。 执行i18n: Scan Workspace后插件会像 Linter 一样扫描整个工程硬编码检测找出代码里所有遗漏的、未经过t()函数处理的文本。缺失校验代码里写了t(user.name)但 JSON 文件里根本没定义直接标红。冗余清理找出那些 JSON 里存在、但代码里早已删掉的“僵尸 Key”。结构对齐对比zh-CN和en如果 A 有 B 没有立即指出。三、导入 Diff 预览给盲目覆盖装上刹车这是很多团队的痛翻译老师给了一份巨大的 JSON你敢直接覆盖吗预览模式插件会生成一个类似 Git Diff 的预览界面。清晰标注哪些是新增的词条哪些是修改了现有翻译局部应用你可以选择只接受一部分变更。这让“导入翻译”从一次冒险变成了一次受控的代码变更。为什么我刻意不做自动翻译很多人问我既然都做 VS Code 插件了为什么不顺便接个 Google 翻译 API我的回答是为了项目的严谨性。语境问题AI 或机器翻译很难理解业务语境比如“Cancel”在某些场景下应该叫“取消”某些场景叫“作废”。流程解耦我希望这个工具是流程驱动的。翻译应该是专业人员或开发者确认后的结果。纯粹性我不想让这个工具变成一个“翻译工具”它应该是一个“工程化工具”。真实场景演进从零到一的治理如果你的项目目前一团糟可以试试这套“三步走”方案第一步全局扫描。用Scan Workspace找出所有的硬编码文案生成一份“欠账清单”。第二步一键提取。利用插件的提取功能快速把老代码重构成 i18n 模式。第三步常态化维护。在日常开发中通过 Explorer 视图随时查看语言文件的 key 数量和完整度。开发者寄语做更纯粹的开源这个项目目前对React、Vue、TS/JS提供了深度支持。我并没有把它做成一个闭源的商业产品而是放在了 GitHub 上。开源边界插件目前在处理复杂 AST 嵌套比如模版字符串里套函数时仍在不断优化。多工作区Multi-root Workspace的支持正在重构中。这些不完美的点正是开源的魅力所在——欢迎大家来提 PR 或者 Issue。国际化从来不只是“接一个库”而是要把一套容易失控的协作流程变得可持续。如果你也厌倦了在 JSON 和业务代码之间反复横跳厌倦了在上线前人肉搜索[\u4e00-\u9fa5]中文正则那么 I18n Workflow Helper 或许就是你需要的那个“最后一块拼图”。项目地址GitHub - OpenLucasKaka/i18n-workflow-helper立即体验VS Code 插件市场搜索I18n Workflow Helper。
告别人肉 i18n：我做了一个 VS Code 插件，把国际化拉回“人类”的工作流
每一个前端开发者的 i18n 噩梦做过国际化的同学心里大概都有本血泪账。i18n 本质上不是技术难题它既没有高并发压力也没有复杂的算法。它的难在于**“琐碎”和“反人性”**。设想一下你平时的开发链路发现文案在 UI 稿里看到一段“确认删除”。打断思维停下手里的业务逻辑去想这个 key 叫common.delete_confirm还是action.delete_item人肉搬运打开zh-CN.json跳到文件末尾加上键值对再打开en.json加上空的 key或者去翻词典翻译一下。代码替换回到业务代码把中文删掉写上t(common.delete_confirm)。循环往复一个页面如果有 50 处文案你就得重复这套动作 50 次。这不叫编程这叫“代码搬运工”。更可怕的是随着项目变大你会发现en.json漏了 key或者zh-CN.json里有一堆没人用的“僵尸文案”整个国际化体系开始坍塌。这就是我开发 I18n Workflow Helper 的原因把国际化从“额外负担”拉回开发流程本身。重新定义是 Workflow不是 Framework市面上有很多 i18n 库i18next, vue-i18n, react-intl它们解决的是运行时如何显示语言。但 I18n Workflow Helper 解决的是开发时如何维护这些语言。它不改变你的代码逻辑它只是你 VS Code 里的一个“超级助手”。核心功能深度解析一、文案提取不再人肉搬运当你选中文中一段硬编码的中文时按下快捷键或通过 Command Palette自动替换代码里的span确认/span瞬间变成span{t(common.confirm)}/span。跨文件同步它会智能识别你的locales目录同时在zh-CN.json写入中文在en.json或其它语言自动补齐这个 key并预留空值或默认值。底层逻辑保持思维连贯性。你不需要离开当前的业务文件所有的 JSON 维护工作都在后台静默完成。二、工作区扫描给项目做一次国际化体检很多项目在上线前最怕的就是漏掉哪里的中文没改。 执行i18n: Scan Workspace后插件会像 Linter 一样扫描整个工程硬编码检测找出代码里所有遗漏的、未经过t()函数处理的文本。缺失校验代码里写了t(user.name)但 JSON 文件里根本没定义直接标红。冗余清理找出那些 JSON 里存在、但代码里早已删掉的“僵尸 Key”。结构对齐对比zh-CN和en如果 A 有 B 没有立即指出。三、导入 Diff 预览给盲目覆盖装上刹车这是很多团队的痛翻译老师给了一份巨大的 JSON你敢直接覆盖吗预览模式插件会生成一个类似 Git Diff 的预览界面。清晰标注哪些是新增的词条哪些是修改了现有翻译局部应用你可以选择只接受一部分变更。这让“导入翻译”从一次冒险变成了一次受控的代码变更。为什么我刻意不做自动翻译很多人问我既然都做 VS Code 插件了为什么不顺便接个 Google 翻译 API我的回答是为了项目的严谨性。语境问题AI 或机器翻译很难理解业务语境比如“Cancel”在某些场景下应该叫“取消”某些场景叫“作废”。流程解耦我希望这个工具是流程驱动的。翻译应该是专业人员或开发者确认后的结果。纯粹性我不想让这个工具变成一个“翻译工具”它应该是一个“工程化工具”。真实场景演进从零到一的治理如果你的项目目前一团糟可以试试这套“三步走”方案第一步全局扫描。用Scan Workspace找出所有的硬编码文案生成一份“欠账清单”。第二步一键提取。利用插件的提取功能快速把老代码重构成 i18n 模式。第三步常态化维护。在日常开发中通过 Explorer 视图随时查看语言文件的 key 数量和完整度。开发者寄语做更纯粹的开源这个项目目前对React、Vue、TS/JS提供了深度支持。我并没有把它做成一个闭源的商业产品而是放在了 GitHub 上。开源边界插件目前在处理复杂 AST 嵌套比如模版字符串里套函数时仍在不断优化。多工作区Multi-root Workspace的支持正在重构中。这些不完美的点正是开源的魅力所在——欢迎大家来提 PR 或者 Issue。国际化从来不只是“接一个库”而是要把一套容易失控的协作流程变得可持续。如果你也厌倦了在 JSON 和业务代码之间反复横跳厌倦了在上线前人肉搜索[\u4e00-\u9fa5]中文正则那么 I18n Workflow Helper 或许就是你需要的那个“最后一块拼图”。项目地址GitHub - OpenLucasKaka/i18n-workflow-helper立即体验VS Code 插件市场搜索I18n Workflow Helper。
