[RFC] TUI 国际化 Walking Skeleton：欢迎页、状态/用量面板、对话框与 Slash 命令英/中文化

[meymchen]

背景与目标

Kimi Code 的 TUI 目前已具备英/中切换能力（/language），但大量用户可见文案仍是硬编码英文。本分支尝试为 TUI 搭建一个可扩展的国际化骨架（walking skeleton），先把高频界面统一抽入 apps/kimi-code/src/tui/i18n，并补齐 zh-CN 翻译，为后续全面 i18n 提供模式参考。

本次范围

1. 新增/扩展命名空间

   • cli：TUI 挂载前 CLI 提示（如 ~/.kimi-code/tui.toml 解析失败提示）
   • common：跨组件共享短句（Submit/Cancel/Back、↑↓ navigate 等键盘提示）
   • components：扩展 welcome、usage、status、footer、dialog 相关 key

2. 已迁移的 UI 区域

   • 欢迎/引导页（welcome.ts）
   • 共享对话框标签（choice-picker、model-selector、session-picker、undo-selector 等）
   • Slash 命令描述与 /help 面板
   • 状态面板（Status Panel）
   • 用量面板（Usage Panel）
   • 语言切换后自动刷新本地化的 slash 菜单

3. 配套改动

   • CLI 配置解析警告通过 i18n 路由
   • 新增/更新对应测试（welcome、status、usage、dialog、i18n 等）
   • 同步 0.17.1 changelog 与 changeset

希望讨论的问题

1. 命名空间划分是否合适？

   • 当前把通用短句放在 common.*，把组件相关放在 components.{welcome,usage,status}.*。是否有些 key 应该进一步按组件拆分，还是保持扁平？
   • cli 命名空间只放一条配置解析提示，未来是否应并入更上层的 app 或保留独立？

2. 键名稳定性

   • 目前新增 key 直接作为贡献者可见的“契约”。在更广泛的语言贡献者加入前，是否应先敲定一份 key 命名规范（如 camelCase、动作/名词分层）？

3. 插值与复数

   • 当前 footer 仍按 {count} 手动分 singular/plural（agentRunning / agentsRunning）。是否应引入 ICU/复数机制，还是保持简单字符串映射？

4. 翻译质量与术语

   • 已按中文语境校对，部分术语选择想听听维护者偏好，例如 thinking 当前译为“思考模式”（非进行态，更像功能开关），planMode 译为“计划模式”。
   • 是否应在 PR 中附一份关键术语对照表，方便后续其他语言译者参考？

5. 回归风险

   • 改动触及大量 TUI 渲染路径，虽然已补测试，但是否需要额外的人工冒烟测试清单（welcome、language switch、/help、status/usage panel）？

不在这个 PR 里做（避免范围膨胀）

• 非 TUI 文案（如 agent-core、server 日志）
• 公共 API 错误消息国际化
• 自动语言检测 / 系统 locale 跟随
• 翻译平台集成

相关提交

• fc281a70 fix(tui): refresh localized slash menu on language switch
• 464495db feat(cli): route TUI config-parse notice through i18n
• 1caf1a54 feat(tui): translate welcome/onboarding & shared dialog labels
• f5a5dbf8 feat(tui): translate usage/status panels & chrome labels
• 7bd87e2a feat(tui): translate slash-command descriptions & /help panel