开发工具CLIAI 应用【免费下载链接】zcfZero-Config Code Flow for Claude code Codex项目地址https://gitcode.com/gh_mirrors/zc/zcf点击查看免费下载本文基于 ZCFZero-Config Code Flow开源仓库中《i18n 静态键值对重构计划》这一规划文档展开完整还原了项目将动态拼接的i18n.t()调用改造为静态键值对访问的全过程包括重构范围、四种核心实现模式、执行与验证流程。读完本文你将掌握一套可复用的 i18n 键可发现性重构方法论能够解决诸如 VSCode i18n-ally 等翻译插件因模板字符串拼接而无法索引翻译键的典型问题并理解 ZCF 现有静态化实现的源码依据。一、为什么需要静态键值对重构ZCF 是一个同时面向 Claude Code 与 Codex 的零配置工作流工具其 CLI 界面通过 i18next 提供中英文双语支持相关官方说明见 docs/zh-CN/advanced/i18n.md。在早期的实现中部分翻译调用采用了模板字符串动态拼接的方式i18n.t(namespace:key.${variable})这种写法在运行时可以正常工作却带来了一个隐蔽的工具链问题i18n-ally 等 IDE 翻译插件通过静态扫描源码中的i18n.t()调用参数来识别翻译键而模板字符串中的${variable}是运行时变量扫描器无法静态求值因此这些动态拼接的键在插件中会丢失导致翻译键补全、缺失键提示、悬空键检测等能力全部失效。重构计划见 .zcf/plan/history/i18n静态键值对重构.md的核心目标就是将动态拼接改为静态对象访问// 旧方式i18n-ally 无法识别 i18n.t(language:configLangHint.${l}) // 新方式静态对象键全部可被扫描 const STATIC_KEYS { value1: i18n.t(namespace:key.value1), value2: i18n.t(namespace:key.value2) } as const // 使用 STATIC_KEYS[variable]该方案在保留原有变量 → 翻译查找语义的同时把所有翻译键以字面量形式固化在源码中使静态分析工具能够逐一识别。二、重构范围四类动态拼接的使用点根据规划文档的重构范围分析项目中共有 13 处动态拼接调用分布在 4 个文件、4 个命名空间中。以最终落地后的源码为准实际改造后的对应关系如下1. 语言配置提示language 命名空间2 处规划指向src/commands/update.ts:44、src/commands/init.ts:254拼接模式i18n.t(\language:configLangHint.${l})变量范围l ∈ [zh-CN, en]对应的翻译键在 src/i18n/locales/zh-CN/language.json 中定义{ configLangHint.zh-CN: 便于中文用户自定义, configLangHint.en: token 消耗更低 }英文版src/i18n/locales/en/language.json则对应easier for Chinese users to customize与lower token consumption。2. 工作流选项workflow 命名空间2 处规划指向src/utils/workflow-installer.ts:28,83拼接模式i18n.t(\workflow:workflowOption.${workflow.id})变量范围workflow.id ∈ [bmadWorkflow, commonTools, featPlanUx, gitWorkflow, sixStepsWorkflow]3. 输出风格配置configuration 命名空间6 处规划指向src/utils/output-style.ts:151,173,175,182,184拼接模式i18n.t(\configuration:outputStyles.${style.id}.name)i18n.t(\configuration:outputStyles.${style.id}.description)变量范围style.id ∈ [default, engineer-professional, nekomata-engineer, laowang-engineer, explanatory, learning]4. MCP 服务配置mcp 命名空间3 处规划指向src/config/mcp-services.ts:77,78,85拼接模式i18n.t(\mcp:services.${config.id}.name)i18n.t(\mcp:services.${config.id}.description)i18n.t(\mcp:services.${config.id}.apiKeyPrompt)从以上范围可以看到动态拼接集中出现在由配置文件或用户选择驱动的动态列表场景中这正是重构的重点地带。三、四种核心实现模式详解规划文档给出了两种静态化实现模式键值映射对象与对象数组。结合仓库当前源码src/i18n/index.ts 为 i18next 实例与命名空间的统一出口下面逐一说明落地后的真实形态。模式一as const键值映射对象语言配置提示适用于变量值集合固定且可穷举的小型映射。规划中给出的LANG_HINT_KEYS在源码 src/utils/prompts.ts 的selectTemplateLanguage函数中落地// 创建静态语言提示键保证 i18n-ally 兼容性 const LANG_HINT_KEYS { zh-CN: i18n.t(language:configLangHint.zh-CN), en: i18n.t(language:configLangHint.en), } as const // 使用由 addNumbersToChoices 包装为带编号选项 name: ${LANG_LABELS[l]} - ${LANG_HINT_KEYS[l]},两个关键设计点as const断言将对象字面量固定为 readonly 结构TypeScript 会对LANG_HINT_KEYS[l]的索引访问进行精确的字面量类型校验杜绝拼写错误引入运行时 undefined。模块内局部常量静态对象在函数内部创建保持作用域最小化不影响其他模块。模式二as const键值映射对象 兜底工作流选项工作流场景变量更多且工作流配置可能随时间扩展因此落地方案在模式一基础上增加了兜底回退。源码见 src/utils/workflow-installer.ts 的installWorkflowWithDependencies函数const WORKFLOW_OPTION_KEYS { commonTools: i18n.t(workflow:workflowOption.commonTools), sixStepsWorkflow: i18n.t(workflow:workflowOption.sixStepsWorkflow), featPlanUx: i18n.t(workflow:workflowOption.featPlanUx), gitWorkflow: i18n.t(workflow:workflowOption.gitWorkflow), bmadWorkflow: i18n.t(workflow:workflowOption.bmadWorkflow), } as const const workflowName WORKFLOW_OPTION_KEYS[config.id as keyof typeof WORKFLOW_OPTION_KEYS] || config.id此处|| config.id的兜底非常关键当新增工作流尚未补充翻译键时界面会优雅降级展示原始 id而不会抛错或渲染为缺键字符串体现了重构对可扩展性与鲁棒性的兼顾。模式三对象数组 find查找输出风格配置当需要同时访问同一 id 下的多个字段name、description时用对象数组按 id 聚合更清晰。源码 src/utils/output-style.ts 的configureOutputStyle中落地const outputStyleList [ { id: default, name: i18n.t(configuration:outputStyles.default.name), description: i18n.t(configuration:outputStyles.default.description), }, { id: engineer-professional, name: i18n.t(configuration:outputStyles.engineer-professional.name), description: i18n.t(configuration:outputStyles.engineer-professional.description), }, // ... nekomata-engineer / laowang-engineer / ojousama-engineer / // leibus-engineer / rem-engineer / explanatory / learning ] // 使用 const styleInfo outputStyleList.find(s s.id styleId) name: ${styleInfo?.name || styleId} - ${ansis.gray(styleInfo?.description || )}值得注意的是规划文档中的变量范围仅列出 6 种风格而当前源码中的outputStyleList已扩展到 9 种新增ojousama-engineer、leibus-engineer、rem-engineer与 templates/common/output-styles 下的模板目录一一对应。这恰好印证了规划中静态对象集中管理易于扩展的预期——新增风格只需追加数组项i18n-ally 依然可以完整识别所有翻译键。模式四对象数组 条件字段MCP 服务配置MCP 服务场景还引入了条件字段的复杂度只有需要 API Key 的服务才有apiKeyPrompt字段。规划方案在 src/config/mcp-services.ts 的getMcpServices中实现const mcpServiceList [ { id: context7, name: i18n.t(mcp:services.context7.name), description: i18n.t(mcp:services.context7.description) }, // ... open-websearch / spec-workflow / mcp-deepwiki / Playwright / serena { id: exa, name: i18n.t(mcp:services.exa.name), description: i18n.t(mcp:services.exa.description), apiKeyPrompt: i18n.t(mcp:services.exa.apiKeyPrompt), }, ] return MCP_SERVICE_CONFIGS.map((config) { const serviceInfo mcpServiceList.find(s s.id config.id) const service: McpService { id: config.id, name: serviceInfo?.name || config.id, description: serviceInfo?.description || , requiresApiKey: config.requiresApiKey, config: config.config, } // 仅对需要 API Key 的服务附加 apiKeyPrompt if (config.requiresApiKey serviceInfo?.apiKeyPrompt) { if (serviceInfo.apiKeyPrompt ! mcp.services.${config.id}.apiKeyPrompt) { service.apiKeyPrompt serviceInfo.apiKeyPrompt } } if (config.apiKeyEnvVar) { service.apiKeyEnvVar config.apiKeyEnvVar } return service })这里有一个重要的架构分层纯业务配置与翻译文本解耦。MCP_SERVICE_CONFIGSsrc/config/mcp-services.ts只包含id、requiresApiKey、apiKeyEnvVar、config如stdio/http类型的 npx 启动命令与环境变量不含任何 i18n 文本翻译文本完全由静态mcpServiceList提供再通过find按 id 合并进最终服务对象。这种分层让翻译缺失与配置错误两类问题互不干扰同时serviceInfo.apiKeyPrompt ! \mcp.services.${config.id}.apiKeyPrompt 的守卫判断还能识别键缺失导致 i18next 返回原始键名的异常情况。四、i18n 核心机制命名空间与初始化前提静态键值对重构依赖的i18n.t(namespace:key)语法由 ZCF 的 i18n 核心 src/i18n/index.ts 支撑理解其配置有助于排查重构后的异常17 个命名空间common、api、ccr、cli、cometix、configuration、errors、installation、language、mcp、menu、multi-config、tools、uninstall、updater、workflow、codex对应 src/i18n/locales 下zh-CN/与en/两个语言目录中各.json文件。分隔符配置keySeparator: false禁用键内分隔符扁平键结构nsSeparator: :以冒号区分命名空间与键因此language:configLangHint.zh-CN即表示 language 命名空间下的扁平键。多路径资源加载initI18n通过loadPath依次探测开发环境src/i18n/locales、npm 包node_modules/zcf/dist/i18n/locales、生产构建./dist/i18n/locales等路径并以zh-CN/common.json是否存在作为路径有效性判据。使用前提ensureI18nInitialized()会在所有工具函数入口强制校验 i18n 已初始化即initI18n()已由 CLI 命令调用若未初始化会抛出明确错误。这解释了为什么所有重构后的静态对象都放置在调用ensureI18nInitialized()之后的函数体内——静态化并不改变 i18n 实例的生命周期约束。五、执行流程与验证策略规划文档将执行过程划分为三个阶段并明确了可量化的成功标准阶段 1数据收集分析所有动态拼接使用模式模板字符串中的变量位置与形态收集所有可能的变量值如语言代码、工作流 id、风格 id、MCP 服务 id 的完整枚举设计静态对象结构键值映射 vs 对象数组的选型。阶段 2代码重构按语言配置提示 → 工作流选项 → 输出风格配置 → MCP 服务配置的顺序依次改造每个模块独立提交便于回归定位。阶段 3验证测试运行相关功能测试CLI 交互、工作流安装、输出风格选择、MCP 服务枚举在 IDE 中验证 i18n-ally 的键识别效果补全、悬空键、缺失键检测以中英文两种语言实跑 CLI 确认翻译正常渲染。成功标准规划文档原文所有动态拼接改为静态对象访问i18n-ally 能识别所有翻译键功能测试全部通过TypeScript 类型检查通过代码结构保持整洁。仓库中的测试体系为第三阶段提供了自动化保障。例如 tests/i18n/i18n-integrity.test.ts 会断言每个必需命名空间common、api、configuration、language、mcp、workflow等在zh-CN与en两个语言目录下都存在且 JSON 合法各语言间翻译键集合保持一致防止重构过程中键被遗漏或删改。六、预期效果与可复用经验规划文档列出了五项预期效果均可从当前仓库源码得到印证i18n-ally 兼容性所有i18n.t()调用参数均为字符串字面量可被静态扫描完整索引类型安全性as const与keyof typeof让索引访问受编译期类型约束重构后不会因键名拼写错误在运行时返回 undefined性能优化翻译值在对象创建时预计算一次后续按变量查找是 O(1) 的对象属性访问避免了每次拼接后重新执行 i18n 解析代码整洁性消除了模板字符串嵌套变量带来的可读性问题维护便利性新增语言选项、工作流、输出风格或 MCP 服务时只需在静态对象中追加一个条目即可同时获得翻译键的可发现性与类型检查。这套重构方法论具有通用参考价值凡是用变量驱动的翻译键都应改为以字面量枚举驱动的静态映射。落地的三种变形键值映射、映射兜底、对象数组条件字段恰好覆盖了从固定小集合到动态可扩展集合再到多字段条件字段集合的复杂度阶梯开发者可按自身场景对号入座。相关源码与文档索引重构规划.zcf/plan/history/i18n静态键值对重构.mdi18n 核心实现src/i18n/index.ts语言提示静态化src/utils/prompts.ts工作流选项静态化src/utils/workflow-installer.ts输出风格静态化src/utils/output-style.tsMCP 服务静态化src/config/mcp-services.ts翻译资源src/i18n/locales/zh-CN/language.json、src/i18n/locales/en/language.json完整性测试tests/i18n/i18n-integrity.test.ts语言体系官方文档docs/zh-CN/advanced/i18n.md赞分享开发工具CLIAI 应用【免费下载链接】zcfZero-Config Code Flow for Claude code Codex项目地址https://gitcode.com/gh_mirrors/zc/zcf点击查看免费下载相关推荐zcf 项目 i18n 清理实战从 146 个冗余翻译键到零告警的完整流程zcf 项目 i18n 清理实战从 146 个冗余翻译键到零告警的完整流程 导读 本文基于 zcfZero Config Code Flow for Cl开发工具CLIAI 应用VUX 国际化i18n完整指南vux-loader 静态多语言编译与 vuex-i18n 动态切换VUX 国际化i18n完整指南vux loader 静态多语言编译与 vuex i18n 动态切换 导读 VUX 是基于 Vue 与 WeUI 的移动端UI组件前端彻底告别手动翻译auto-i18n-translation-plugins让你的网站一键国际化 彻底告别手动翻译auto i18n translation plugins让你的网站一键国际化 还在为网站国际化而头痛吗auto i18n trans前端构建工具国际化上一篇Bilibili-Evolved构建工具迁移从Webpack到Vite实战下一篇Readest终极灾备方案确保电子书阅读服务永不中断创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 5:27:00 · 阅读 1.2k ZCF i18n 静态键值对重构实践：让 i18n-ally 完整识别动态翻译键
开发工具CLIAI 应用【免费下载链接】zcfZero-Config Code Flow for Claude code Codex项目地址https://gitcode.com/gh_mirrors/zc/zcf点击查看免费下载本文基于 ZCFZero-Config Code Flow开源仓库中《i18n 静态键值对重构计划》这一规划文档展开完整还原了项目将动态拼接的i18n.t()调用改造为静态键值对访问的全过程包括重构范围、四种核心实现模式、执行与验证流程。读完本文你将掌握一套可复用的 i18n 键可发现性重构方法论能够解决诸如 VSCode i18n-ally 等翻译插件因模板字符串拼接而无法索引翻译键的典型问题并理解 ZCF 现有静态化实现的源码依据。一、为什么需要静态键值对重构ZCF 是一个同时面向 Claude Code 与 Codex 的零配置工作流工具其 CLI 界面通过 i18next 提供中英文双语支持相关官方说明见 docs/zh-CN/advanced/i18n.md。在早期的实现中部分翻译调用采用了模板字符串动态拼接的方式i18n.t(namespace:key.${variable})这种写法在运行时可以正常工作却带来了一个隐蔽的工具链问题i18n-ally 等 IDE 翻译插件通过静态扫描源码中的i18n.t()调用参数来识别翻译键而模板字符串中的${variable}是运行时变量扫描器无法静态求值因此这些动态拼接的键在插件中会丢失导致翻译键补全、缺失键提示、悬空键检测等能力全部失效。重构计划见 .zcf/plan/history/i18n静态键值对重构.md的核心目标就是将动态拼接改为静态对象访问// 旧方式i18n-ally 无法识别 i18n.t(language:configLangHint.${l}) // 新方式静态对象键全部可被扫描 const STATIC_KEYS { value1: i18n.t(namespace:key.value1), value2: i18n.t(namespace:key.value2) } as const // 使用 STATIC_KEYS[variable]该方案在保留原有变量 → 翻译查找语义的同时把所有翻译键以字面量形式固化在源码中使静态分析工具能够逐一识别。二、重构范围四类动态拼接的使用点根据规划文档的重构范围分析项目中共有 13 处动态拼接调用分布在 4 个文件、4 个命名空间中。以最终落地后的源码为准实际改造后的对应关系如下1. 语言配置提示language 命名空间2 处规划指向src/commands/update.ts:44、src/commands/init.ts:254拼接模式i18n.t(\language:configLangHint.${l})变量范围l ∈ [zh-CN, en]对应的翻译键在 src/i18n/locales/zh-CN/language.json 中定义{ configLangHint.zh-CN: 便于中文用户自定义, configLangHint.en: token 消耗更低 }英文版src/i18n/locales/en/language.json则对应easier for Chinese users to customize与lower token consumption。2. 工作流选项workflow 命名空间2 处规划指向src/utils/workflow-installer.ts:28,83拼接模式i18n.t(\workflow:workflowOption.${workflow.id})变量范围workflow.id ∈ [bmadWorkflow, commonTools, featPlanUx, gitWorkflow, sixStepsWorkflow]3. 输出风格配置configuration 命名空间6 处规划指向src/utils/output-style.ts:151,173,175,182,184拼接模式i18n.t(\configuration:outputStyles.${style.id}.name)i18n.t(\configuration:outputStyles.${style.id}.description)变量范围style.id ∈ [default, engineer-professional, nekomata-engineer, laowang-engineer, explanatory, learning]4. MCP 服务配置mcp 命名空间3 处规划指向src/config/mcp-services.ts:77,78,85拼接模式i18n.t(\mcp:services.${config.id}.name)i18n.t(\mcp:services.${config.id}.description)i18n.t(\mcp:services.${config.id}.apiKeyPrompt)从以上范围可以看到动态拼接集中出现在由配置文件或用户选择驱动的动态列表场景中这正是重构的重点地带。三、四种核心实现模式详解规划文档给出了两种静态化实现模式键值映射对象与对象数组。结合仓库当前源码src/i18n/index.ts 为 i18next 实例与命名空间的统一出口下面逐一说明落地后的真实形态。模式一as const键值映射对象语言配置提示适用于变量值集合固定且可穷举的小型映射。规划中给出的LANG_HINT_KEYS在源码 src/utils/prompts.ts 的selectTemplateLanguage函数中落地// 创建静态语言提示键保证 i18n-ally 兼容性 const LANG_HINT_KEYS { zh-CN: i18n.t(language:configLangHint.zh-CN), en: i18n.t(language:configLangHint.en), } as const // 使用由 addNumbersToChoices 包装为带编号选项 name: ${LANG_LABELS[l]} - ${LANG_HINT_KEYS[l]},两个关键设计点as const断言将对象字面量固定为 readonly 结构TypeScript 会对LANG_HINT_KEYS[l]的索引访问进行精确的字面量类型校验杜绝拼写错误引入运行时 undefined。模块内局部常量静态对象在函数内部创建保持作用域最小化不影响其他模块。模式二as const键值映射对象 兜底工作流选项工作流场景变量更多且工作流配置可能随时间扩展因此落地方案在模式一基础上增加了兜底回退。源码见 src/utils/workflow-installer.ts 的installWorkflowWithDependencies函数const WORKFLOW_OPTION_KEYS { commonTools: i18n.t(workflow:workflowOption.commonTools), sixStepsWorkflow: i18n.t(workflow:workflowOption.sixStepsWorkflow), featPlanUx: i18n.t(workflow:workflowOption.featPlanUx), gitWorkflow: i18n.t(workflow:workflowOption.gitWorkflow), bmadWorkflow: i18n.t(workflow:workflowOption.bmadWorkflow), } as const const workflowName WORKFLOW_OPTION_KEYS[config.id as keyof typeof WORKFLOW_OPTION_KEYS] || config.id此处|| config.id的兜底非常关键当新增工作流尚未补充翻译键时界面会优雅降级展示原始 id而不会抛错或渲染为缺键字符串体现了重构对可扩展性与鲁棒性的兼顾。模式三对象数组 find查找输出风格配置当需要同时访问同一 id 下的多个字段name、description时用对象数组按 id 聚合更清晰。源码 src/utils/output-style.ts 的configureOutputStyle中落地const outputStyleList [ { id: default, name: i18n.t(configuration:outputStyles.default.name), description: i18n.t(configuration:outputStyles.default.description), }, { id: engineer-professional, name: i18n.t(configuration:outputStyles.engineer-professional.name), description: i18n.t(configuration:outputStyles.engineer-professional.description), }, // ... nekomata-engineer / laowang-engineer / ojousama-engineer / // leibus-engineer / rem-engineer / explanatory / learning ] // 使用 const styleInfo outputStyleList.find(s s.id styleId) name: ${styleInfo?.name || styleId} - ${ansis.gray(styleInfo?.description || )}值得注意的是规划文档中的变量范围仅列出 6 种风格而当前源码中的outputStyleList已扩展到 9 种新增ojousama-engineer、leibus-engineer、rem-engineer与 templates/common/output-styles 下的模板目录一一对应。这恰好印证了规划中静态对象集中管理易于扩展的预期——新增风格只需追加数组项i18n-ally 依然可以完整识别所有翻译键。模式四对象数组 条件字段MCP 服务配置MCP 服务场景还引入了条件字段的复杂度只有需要 API Key 的服务才有apiKeyPrompt字段。规划方案在 src/config/mcp-services.ts 的getMcpServices中实现const mcpServiceList [ { id: context7, name: i18n.t(mcp:services.context7.name), description: i18n.t(mcp:services.context7.description) }, // ... open-websearch / spec-workflow / mcp-deepwiki / Playwright / serena { id: exa, name: i18n.t(mcp:services.exa.name), description: i18n.t(mcp:services.exa.description), apiKeyPrompt: i18n.t(mcp:services.exa.apiKeyPrompt), }, ] return MCP_SERVICE_CONFIGS.map((config) { const serviceInfo mcpServiceList.find(s s.id config.id) const service: McpService { id: config.id, name: serviceInfo?.name || config.id, description: serviceInfo?.description || , requiresApiKey: config.requiresApiKey, config: config.config, } // 仅对需要 API Key 的服务附加 apiKeyPrompt if (config.requiresApiKey serviceInfo?.apiKeyPrompt) { if (serviceInfo.apiKeyPrompt ! mcp.services.${config.id}.apiKeyPrompt) { service.apiKeyPrompt serviceInfo.apiKeyPrompt } } if (config.apiKeyEnvVar) { service.apiKeyEnvVar config.apiKeyEnvVar } return service })这里有一个重要的架构分层纯业务配置与翻译文本解耦。MCP_SERVICE_CONFIGSsrc/config/mcp-services.ts只包含id、requiresApiKey、apiKeyEnvVar、config如stdio/http类型的 npx 启动命令与环境变量不含任何 i18n 文本翻译文本完全由静态mcpServiceList提供再通过find按 id 合并进最终服务对象。这种分层让翻译缺失与配置错误两类问题互不干扰同时serviceInfo.apiKeyPrompt ! \mcp.services.${config.id}.apiKeyPrompt 的守卫判断还能识别键缺失导致 i18next 返回原始键名的异常情况。四、i18n 核心机制命名空间与初始化前提静态键值对重构依赖的i18n.t(namespace:key)语法由 ZCF 的 i18n 核心 src/i18n/index.ts 支撑理解其配置有助于排查重构后的异常17 个命名空间common、api、ccr、cli、cometix、configuration、errors、installation、language、mcp、menu、multi-config、tools、uninstall、updater、workflow、codex对应 src/i18n/locales 下zh-CN/与en/两个语言目录中各.json文件。分隔符配置keySeparator: false禁用键内分隔符扁平键结构nsSeparator: :以冒号区分命名空间与键因此language:configLangHint.zh-CN即表示 language 命名空间下的扁平键。多路径资源加载initI18n通过loadPath依次探测开发环境src/i18n/locales、npm 包node_modules/zcf/dist/i18n/locales、生产构建./dist/i18n/locales等路径并以zh-CN/common.json是否存在作为路径有效性判据。使用前提ensureI18nInitialized()会在所有工具函数入口强制校验 i18n 已初始化即initI18n()已由 CLI 命令调用若未初始化会抛出明确错误。这解释了为什么所有重构后的静态对象都放置在调用ensureI18nInitialized()之后的函数体内——静态化并不改变 i18n 实例的生命周期约束。五、执行流程与验证策略规划文档将执行过程划分为三个阶段并明确了可量化的成功标准阶段 1数据收集分析所有动态拼接使用模式模板字符串中的变量位置与形态收集所有可能的变量值如语言代码、工作流 id、风格 id、MCP 服务 id 的完整枚举设计静态对象结构键值映射 vs 对象数组的选型。阶段 2代码重构按语言配置提示 → 工作流选项 → 输出风格配置 → MCP 服务配置的顺序依次改造每个模块独立提交便于回归定位。阶段 3验证测试运行相关功能测试CLI 交互、工作流安装、输出风格选择、MCP 服务枚举在 IDE 中验证 i18n-ally 的键识别效果补全、悬空键、缺失键检测以中英文两种语言实跑 CLI 确认翻译正常渲染。成功标准规划文档原文所有动态拼接改为静态对象访问i18n-ally 能识别所有翻译键功能测试全部通过TypeScript 类型检查通过代码结构保持整洁。仓库中的测试体系为第三阶段提供了自动化保障。例如 tests/i18n/i18n-integrity.test.ts 会断言每个必需命名空间common、api、configuration、language、mcp、workflow等在zh-CN与en两个语言目录下都存在且 JSON 合法各语言间翻译键集合保持一致防止重构过程中键被遗漏或删改。六、预期效果与可复用经验规划文档列出了五项预期效果均可从当前仓库源码得到印证i18n-ally 兼容性所有i18n.t()调用参数均为字符串字面量可被静态扫描完整索引类型安全性as const与keyof typeof让索引访问受编译期类型约束重构后不会因键名拼写错误在运行时返回 undefined性能优化翻译值在对象创建时预计算一次后续按变量查找是 O(1) 的对象属性访问避免了每次拼接后重新执行 i18n 解析代码整洁性消除了模板字符串嵌套变量带来的可读性问题维护便利性新增语言选项、工作流、输出风格或 MCP 服务时只需在静态对象中追加一个条目即可同时获得翻译键的可发现性与类型检查。这套重构方法论具有通用参考价值凡是用变量驱动的翻译键都应改为以字面量枚举驱动的静态映射。落地的三种变形键值映射、映射兜底、对象数组条件字段恰好覆盖了从固定小集合到动态可扩展集合再到多字段条件字段集合的复杂度阶梯开发者可按自身场景对号入座。相关源码与文档索引重构规划.zcf/plan/history/i18n静态键值对重构.mdi18n 核心实现src/i18n/index.ts语言提示静态化src/utils/prompts.ts工作流选项静态化src/utils/workflow-installer.ts输出风格静态化src/utils/output-style.tsMCP 服务静态化src/config/mcp-services.ts翻译资源src/i18n/locales/zh-CN/language.json、src/i18n/locales/en/language.json完整性测试tests/i18n/i18n-integrity.test.ts语言体系官方文档docs/zh-CN/advanced/i18n.md赞分享开发工具CLIAI 应用【免费下载链接】zcfZero-Config Code Flow for Claude code Codex项目地址https://gitcode.com/gh_mirrors/zc/zcf点击查看免费下载相关推荐zcf 项目 i18n 清理实战从 146 个冗余翻译键到零告警的完整流程zcf 项目 i18n 清理实战从 146 个冗余翻译键到零告警的完整流程 导读 本文基于 zcfZero Config Code Flow for Cl开发工具CLIAI 应用VUX 国际化i18n完整指南vux-loader 静态多语言编译与 vuex-i18n 动态切换VUX 国际化i18n完整指南vux loader 静态多语言编译与 vuex i18n 动态切换 导读 VUX 是基于 Vue 与 WeUI 的移动端UI组件前端彻底告别手动翻译auto-i18n-translation-plugins让你的网站一键国际化 彻底告别手动翻译auto i18n translation plugins让你的网站一键国际化 还在为网站国际化而头痛吗auto i18n trans前端构建工具国际化上一篇Bilibili-Evolved构建工具迁移从Webpack到Vite实战下一篇Readest终极灾备方案确保电子书阅读服务永不中断创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考