UI 硬编码中文，无法切换语言

状态: 🟢 已修复

日期: 2026-07-07 严重程度: 🟠 P2（国际化阻塞，所有非中文用户无法使用） 影响范围: frontend/src/menus/*.ts（全部菜单文件）+ src/core/i18n/（新建） 发现方式: GitHub issue 修复方案: i18n/ 新建 locale.ts + t.ts + locales/*.ts，五种语言，三千多处 t() 替换

---

问题描述

联邦的界面从一开始就是中文的。"地面可见度"、"模型库"、"场景设置"——这些字符串直接写在代码里，嵌在 slideRow 和 buildXxxLevel 的调用中。

它们不是数据，它们是代码的一部分。

用户在 GitHub 上提了一个 issue："Can this support English?"

问题不在翻译。问题在于——字符串不在一个地方。它们散在三十多个菜单文件里，每改一个地方都要改代码。

根因分析

没有 i18n 层。没有翻译表。没有语言切换机制。

"先让东西能跑"是合理的优先顺序。但当有人想用它时，"能跑"和"能用"之间的距离，是三千多个硬编码字符串。

为什么没有暴露

联邦从一开始就用中文开发，中文也是目标用户的主要语言。所以"不支持其他语言"在很长一段时间里不是 bug——是假设。

这个假设直到有人从非中文环境打开联邦才暴露。

修复方案

src/core/i18n/ 新建三个文件：locale.ts、t.ts、locales/*.ts。

t 函数接收一个 key（如 "menu.ground.visible"），在当前语言的翻译表里查找对应文本。找不到就返回 key 本身——翻译缺失时，至少能告诉用户这个 UI 元素叫什么。

五种语言：zh-CN、en、ja、ko、zh-TW。

手动替换三千多处硬编码字符串为 t() 调用。

语言切换时 refreshRoot() 重新渲染菜单——所有 label 都是 t(key)，语言变了，翻译就变了。

教训

1. 假设是技术债的一种 — "先支持中文"是合理的，但这个假设需要在代码里留一个扩展点
2. 翻译缺失时，key 本身是最坏的回退 — 但比没有任何文本好