chineselocalization 不完全汉化是因 st4 界面语言分三层，该插件仅完整实现主菜单与命令面板翻译，右键菜单、状态栏等依赖未提供的本地化字符串且无法动态重载，配置"locale": "zh_cn"和手动替换语言包均无效，当前最务实做法是接受高频区域已汉化、低频区域靠记忆或精准干预对应插件。
Sublime Text 4 装完 ChineseLocalization 后，菜单、设置项基本变中文，但状态栏、右键菜单、部分弹窗仍英文——这不是插件失效，是 ST 的语言加载机制只覆盖了主 UI 层，没触达所有上下文；手动替换语言包不仅无效，还可能破坏插件热更新能力。
为什么 ChineseLocalization 不翻译右键菜单和状态栏？
ST4 的界面语言分三层：主菜单（menu）、命令面板（command_palette）、上下文菜单（context）与状态提示（status_bar）。ChineseLocalization 当前只完整实现了前两层的翻译，后两者依赖插件作者显式声明并提供对应 key 的本地化字符串。你看到的“右键里还有英文”“保存时提示 still saving”等现象，属于已知限制，不是配置错误。
无序列表呈现关键事实：
-
ChineseLocalization的源码中，Context.sublime-menu和Status Bar.sublime-settings对应的中文映射缺失或未启用 - ST4 不允许插件动态重载
context类资源，必须重启才能生效，而多数用户重启后仍见英文，误以为失败 - 插件作者在 GitHub issue 中明确说明：状态栏文案（如
building...、indexing...）由核心引擎生成，第三方无法拦截翻译
Preferences.sublime-settings 里加 "locale": "zh_CN" 真的能补全翻译吗？
不能。这行配置只告诉 ST 加载哪套主 UI 语言资源，它不触发额外翻译逻辑，也不扩展 ChineseLocalization 的覆盖范围。加了它，菜单从英文变中文；不加，菜单保持英文——仅此而已。它对右键菜单、状态栏、构建输出、LSP 提示等区域完全无影响。
常见误操作包括：
- 把
"locale": "zh_CN"写进左侧默认设置（只读），保存无效 - 写进右侧用户设置但 JSON 多了逗号，导致整个配置解析失败，ST 回退用默认 en
- 改完没彻底退出进程（Windows 托盘还在、macOS Activity Monitor 没杀干净），新 locale 根本没加载
手动替换 en 文件夹真能解决“汉化不完全”？
不能，且风险极高。ST4 已弃用传统语言包目录结构，所有界面文本由插件打包进 .sublime-package 归档，硬替换 Packages/Default 或 Installed Packages/ChineseLocalization.sublime-package 内部文件，会导致：
- 每次插件自动更新时被覆盖，修改瞬间丢失
- JSON 格式错一个字符，整个插件加载失败，连带其他依赖它的插件（如
SideBarEnhancements）异常 - ST 启动时校验包签名失败，直接禁用该插件并报错
Package Control: Error loading package ChineseLocalization
2026 年起，ChineseLocalization 已强制启用 SHA256 包签名验证，手工解压 → 修改 → 重打包 → 签名的流程，普通用户几乎不可行。
那“不完全汉化”还能怎么应对？
接受现状 + 小范围精准干预是当前最务实的做法。真正需要中文的高频区域（比如菜单、命令面板）已覆盖；低频区域（如右键里的 Reindent、状态栏的 UTF-8）靠肌肉记忆适应更快。若非要干预，仅建议：
- 对极少数固定文案（如右键菜单中的
Copy Path），可用Context.sublime-menu覆盖：在Packages/User/Context.sublime-menu里添加自定义条目，用中文 label 替换原命令 - 状态栏显示内容由插件控制（如
GitGutter、SublimeLinter），去对应插件文档查status_bar_text配置项，手动设中文提示 - 别碰
Default包里的任何东西——它被 ST 核心强绑定，改了轻则乱码，重则启动崩溃
最后提醒一句：所谓“深度汉化”，在 ST4 当前架构下本质是个伪需求。插件生态决定上限，不是用户配置能突破的。盯着右键菜单那几个英文单词反复折腾，远不如花两分钟熟悉快捷键来得高效。
