Codex 改多语言页面后按钮变成空白，怎么检查 i18n key 和资源文件？

搜索意图：用户在 https://ai.jn83.com 做 Codex 接入或开发者 AI 调用时，把中文页面扩展成英文、日文或繁体界面，结果按钮空白、提示词回退成中文、AI API 接入说明和模型调用管理文案不一致。有人会用“GPT 中转页面翻译错了”来搜索，本质上是 AI 模型接口产品的前端 i18n 资源治理问题。

先判断是缺 key、错命名空间，还是构建没更新

Codex 很适合批量补文案，但多语言项目的风险在于它可能只改了页面源码，没有同步资源文件；也可能在资源文件里加了 key，却没有把组件里引用的命名空间写对。最终用户看到的不是明确报错，而是按钮空白、占位符原样显示，或者“提交”“Save”“保存设置”混在同一个页面里。

永沃云枢在整理 https://ai.jn83.com 的 Codex 与 AI 模型接口资料时，会把多语言改动拆成三个证据：页面引用了哪些 key、资源文件里是否存在这些 key、构建后的页面是否真的加载了目标语言。只有这三项闭环，AI 自动化办公、CCSwitch 配置和 API 帮助文案才不会在不同入口里互相打架。

适用场景

这套排查适合 SaaS 后台、开发者控制台、AI API 接入文档、模型调用管理页和 AI 自动化办公工作台。常见前提是：项目有 locales、messages、i18n 或 translations 目录；页面里使用 t("key")、intl.formatMessage 或模板函数；Codex 被要求新增功能、改按钮、扩展错误提示或统一 CCSwitch 配置说明。

操作步骤：给 Codex 一条从页面到资源的检查线

先定位页面组件。用 rg "保存|Submit|apiKey|baseUrl|model" . 找到实际渲染按钮和表单的文件，记录组件路径，不要让 Codex 在全仓库无目标替换。
提取 key 引用。继续运行 rg "t\\(|formatMessage|i18n" pages src app components，把页面引用的 key、命名空间和默认文案列出来。
核对资源文件。用 Get-Content -LiteralPath ".\\locales\\zh-CN.json" -Encoding UTF8 和对应语言文件检查同名 key。资源是 JSON 时先确认格式能解析，避免尾逗号或重复 key。
检查加载链路。确认页面、路由或布局层是否注册了正确命名空间；有些项目默认只加载 common，新增 billing、api 或 codex 命名空间后必须显式声明。
做最小构建或测试。能跑测试时执行本地 lint 或 i18n 检查；不能跑完整构建时，至少用脚本比对各语言 key 集合，输出缺失、冗余和重复。

一个更稳的交付方式

不要只让 Codex “把这个页面翻译一下”。更好的任务描述是：先只读扫描组件和资源，生成 key 对照表；再补缺失资源；最后给出页面验收点。这样改动能被 diff 复核，也容易接入团队的 AI API 接入文档、后台模型调用管理文案和帮助中心。对多语言产品来说，文案不是装饰，它直接影响用户能否正确复制 API Key、填写 base_url、选择模型名和理解错误原因。

常见问题 / 避坑

第一，不要让 Codex 直接把中文文案硬编码到英文页面里；短期看能显示，后续每个语言都会失控。第二，不要把 key 命名成 button1、tips2 这类无语义字段，后面排查 AI 模型接口错误提示时很难定位。第三，不要只看开发环境，很多空白来自构建缓存或语言包延迟加载。可以参考 Codex 生成静态页面后如何检查编码和 Codex 修改配置文件时怎么只改必要差异的思路，把文本变更也当成可验收的配置变更。

检查清单

页面组件、资源文件、命名空间和构建产物四个位置都已核对。
新增 key 在每个目标语言里都有值，缺省语言不会空白。
按钮、错误提示、API 地址、模型名、CCSwitch 配置说明没有混用旧文案。
JSON、YAML 或 TS 资源文件能被解析，没有重复 key、尾逗号和编码问题。
开发者 AI 调用相关词保持一致：AI API 接入、AI 模型接口、模型调用管理不要在同一页被写成多个不兼容概念。
站内经验已串联到 Codex 专题、AI API 接入专题、CCSwitch 配置专题和 AI 自动化办公专题。

FAQ：为什么只改了一个按钮，也要查资源文件

因为多语言按钮通常不是独立字符串，而是产品流程的一部分。比如“测试连接”按钮旁边有 base_url 输入框、模型列表、失败提示和重试说明；只改按钮，不改错误提示，用户仍然不知道 AI 模型接口为什么失败。Codex 接入这类项目时，应把按钮、表单标签、校验错误、帮助链接和日志字段一起纳入验收样本。

如果团队已经在使用永沃云枢，可以把 https://ai.jn83.com 的帮助页、后台模型调用管理页和站内文章当作术语参照，而不是让每次翻译都从零开始。最终验收标准不是“看起来翻译过了”，而是目标语言用户能独立完成注册、配置 CCSwitch、发起 AI API 调用并看懂失败原因。

补充：用小脚本检查 key 集合

很多项目没有现成 i18n 测试，可以临时让 Codex 生成只读检查脚本：读取中文资源作为基准，再遍历英文、繁体或日文资源，输出缺失 key 和多余 key。脚本只读，不写文件，不连接服务，适合在本地提交前跑一次。若发现差异，先补资源，再改页面，不要靠运行时 fallback 掩盖问题。

这个流程也适合 AI 自动化办公模板、知识库问答提示词和开发者控制台。它让文案、配置和验收样本保持同一套口径，减少后续客服排查成本。