Codex 桌面端汉化：从菜单到主界面的实现思路

Codex 已经内置了多语言资源，但让菜单显示中文，不代表主界面也完成了汉化。主界面通常由 Web 技术渲染，语言状态还可能受到应用配置、浏览器运行环境和动态功能开关的共同影响。因此，桌面端汉化需要先弄清楚语言资源在哪里、应用如何选择语言，再按操作系统采用适合的实现方式。

本文介绍 Codex macOS 和 Windows 桌面端的汉化思路，以及如何在保留应用可用性的前提下验证修改结果。实现时可以参考这个跨平台 Skill：codex-localization。不想折腾可以使用我汉化好的。

为什么菜单中文了，主界面仍然是英文？

桌面应用的不同区域可能由不同部分负责：

原生菜单由 macOS 或 Windows 桌面应用框架创建。
主界面由内嵌的 Web 页面或 renderer 渲染。
语言资源可能包含在应用安装包中，也可能由应用运行时加载。
语言设置可能同时来自启动参数、用户配置和应用内部的动态配置。

所以，只设置系统语言或切换菜单语言，未必会改变主界面。反过来，网页主界面显示中文，也不一定代表原生菜单已经切换。

汉化前应分别确认这些部分的语言来源，并用实际界面验证，而不能只看某一项设置是否写入成功。

先检查官方资源和当前版本

开始修改之前，先检查目标 Codex 版本：

确认安装包来源、版本和架构。
检查包内是否包含简体中文资源。
定位主界面的入口资源和语言选择逻辑。
确认应用如何校验包完整性与代码签名。
在隔离环境中测试修改和启动结果。

应用更新后，内部资源路径和配置逻辑可能变化。旧版本验证通过，不代表新版本也能沿用相同修改。应把每个版本视为需要重新检查的目标，并在验证完成前保留英文启动能力。

macOS：在隔离副本中修改并验证

macOS 方案的关键，是只对经过验证的应用副本进行修改，并保持应用包的完整性数据一致。

典型流程包括：

验证官方安装包，并复制应用到专用暂存目录。
根据精确的应用包哈希确认目标版本。
在已确认的主界面资源中启用官方 i18n 配置，并选择 zh-CN。
更新 ASAR 资源及相关完整性摘要。
对暂存副本重新签名，并检查嵌套签名。
通过启动、主界面和后续启动检查后，再进入安装或替换流程。

暂存目录的名称只能作为额外检查，不能证明副本真的安全隔离。实现还应解析真实路径，确认目标位于专用暂存目录，避免路径穿越或符号链接指向已安装的应用。替换前要检查目标应用状态，并保留原应用，以便失败时恢复。

本机重新签名会改变原有签名身份，可能影响钥匙串共享、安全存储、通知或依赖签名身份的功能。因此，签名验证和启动验证都要纳入测试，也不能把重新签名后的应用描述为与官方签名版本完全等同。

Windows：先使用系统语言配置，再验证运行时状态

Windows 版应优先使用 Codex 安装包自带的中文资源，并通过用户配置和启动参数选择 zh-CN。如果主界面还需要运行时启用 i18n，再根据目标版本使用受限的本地化配置流程。

在使用 Chromium DevTools Protocol（CDP）时，需要认识到它提供了对页面的控制能力。绑定 127.0.0.1 和使用随机端口可以减少意外暴露，但不能阻止同一用户下的其他本机进程连接调试端口。应优先考虑应用内桥接或受支持的 pipe/IPC 方式；如果目标版本必须使用 TCP CDP，应限制监听时间、校验进程和页面目标，并把这种同用户进程风险记录清楚。

navigator.language 也不能想当然地直接赋值。该属性可能是只读的，或在目标 renderer 中以不同方式暴露。应针对每个支持的版本验证覆盖方法是否确实作用于 Codex 使用的执行环境，并检查刷新后的结果。

更重要的是，navigator.language 显示为中文本身并不能证明汉化成功。验收还应确认官方 i18n 状态已启用，并检查主界面、设置页和原生菜单等实际区域。若运行时检查失败，应让 Codex 正常启动，并报告中文配置未完成，而不是阻止应用使用。

两个平台不能共用同一套修改方式

macOS 和 Windows 的应用包结构、签名和运行机制并不相同：

平台	主要关注点	实现边界
macOS	ASAR 资源、Electron 完整性摘要、应用签名	在隔离副本中修改、校验和重新签名
Windows	官方 `.pak` 资源、用户配置、启动参数、renderer 运行时状态	优先配置用户语言；MSIX 不应被直接修改或重新签名

例如，macOS 的 Info.plist 完整性处理和应用重新签名，不能直接套用到 Windows。Windows 用户配置路径和 MSIX 包边界，也不是 macOS 的安装流程。实施时应先确认平台，再选择对应方案。

安装、更新和回滚同样重要

汉化不只是一次性的资源修改。Codex 更新可能覆盖本地化内容，应用修复也可能重新安装原始文件。因此，安装器或更新器需要在每次版本变化后重新检查资源和语言状态。

建议把"应用是否安装成功"和"汉化是否完成"作为两个独立结果：

应用文件损坏或启动失败时，按安装流程处理并在必要时回滚。
只有汉化检查失败时，保留可启动的 Codex，并提示用户可以继续使用英文版或稍后重试。
替换应用前保留可恢复的原版本。
对更新后的版本重新进行资源、签名、运行和界面检查。

这样可以避免语言配置问题被误报为"Codex 未安装"，也能减少失败时对用户现有应用的影响。

一套实用的验收清单

每次支持新的 Codex 版本时，至少检查：

安装包来源、版本、架构和官方中文资源。
平台对应的完整性与签名要求。
实际主界面是否使用简体中文。
原生菜单和设置界面是否符合预期。
应用关闭后再次启动，中文状态是否仍然存在。
更新失败或汉化失败时，原应用是否仍可使用或恢复。
日志中没有记录账号凭据、令牌、Cookie 或聊天内容。

结语

Codex 桌面端汉化不是简单替换几段文本。稳定的实现需要理解官方语言资源、主界面的 i18n 开关、操作系统的应用包规则，以及安装和更新过程中的失败处理。

按版本验证、按平台选择实现方式，并以实际界面结果作为验收依据，才能让菜单与主界面都可靠地显示中文，同时尽可能保留应用的正常启动和恢复能力。