我是怎么给 Claude Web 加上一个并不存在的语言的？
这篇文章记录的是一个很具体的问题。 如果你平时喜欢拆前端、盯运行时，或者对“明明官方没给这个入口，我能不能自己把它接出来”这种事情有天然兴趣，那你应该会理解这篇文章的出发点。 看到 Claude Web 没有中文，我最初的反应不是“等官方以后也许会加”，而是： 那我能不能自己把它做出来？ 我想给 Claude Web 加一个 简体中文 语言选项，而且不是简单把界面上某几个按钮替换成中文，而是尽量复用 Claude 自己的 i18n 加载链路，让页面像切官方语言一样，在运行时重新加载语言资源。 最后做到的效果是： 在 Claude Web 的语言菜单里注入一个 简体中文 页面保持官方支持的 locale，不去伪造后端 profile 运行时拦截 Claude 的 i18n 请求，返回自定义中文资源 最关键的是，找到 Claude Web 内部真正控制语言重载的 runtime 入口，在不刷新页面的情况下触发语言重新加载 这件事表面上看像“做个浏览器扩展”，但中间真正难的不是菜单注入，也不是静态资源服务，而是这个问题： Claude Web 页面运行时里，到底谁才是真正的语言切换入口？ 如果你只想看最后的答案，可以先剧透： window.__CLAUDE_I18N_STORE__.getState().setLocaleOverride(...) 但如果你真的准备在某个现代前端应用里做类似的事情，我建议你别只抄这行。真正值钱的是我是怎么走到这行代码的。 问题从一开始就不是“翻译文件放哪里” 一开始很容易把问题理解成： 我准备一份 zh-CN.json 让 Claude 去请求它 然后把菜单里多塞一个 “简体中文” 如果你也会本能地这么想，不奇怪，我一开始也是这么想的。 但很快就会撞到第一个硬约束：Claude 后端 profile 的 locale 不是任意字符串，而是一个受限枚举。 实际观察到的行为是： 选择官方语言时，Claude 会发一个 profile 更新请求 后端保存一个 locale 字段，比如 en-US 如果强行尝试 zh-CN，后端会直接拒绝 也就是说，这条路根本走不通：...