feat: 添加国际化(i18n)模块，支持中文简体和英文

[60999]

• 创建 i18n 核心模块 (i18n/index.js)

  • 支持多语言注册和切换
  • 支持浏览器语言自动检测
  • 支持参数插值和嵌套翻译键
  • 支持 localStorage 持久化语言设置
  • 支持 DOM 自动更新 (data-i18n 属性)

• 创建中文简体语言包 (i18n/locales/zh-CN.js)

  • 完整翻译所有界面文本

• 创建英文语言包 (i18n/locales/en-US.js)

  • 完整翻译所有界面文本

• 更新 app.js

  • 集成 i18n 模块
  • 添加语言切换 API
  • 添加语言选择器事件监听

• 更新 index.html

  • 添加 data-i18n 属性到所有文本元素
  • 添加语言选择器下拉框

• 更新 style.css

  • 添加语言选择器样式

[frankzhang-netizen]

请问你这个项目有没有测试成功过？

[ruvnet]

Heads-up: PR #309 (natiixnt) also adds i18n to ui/app.js — that one targets EN/PL with 60+ translation keys, this one targets EN + 简体中文. Both add a data-i18n attribute system and a language selector.

To avoid two incompatible i18n implementations landing, could we coordinate? Two options:

1. Add zh-CN as a third locale to the feat(ui): i18n (EN/PL), screenshot, settings panel, reduced motion, uptime clock #309 i18n module (cleanest — one system, three languages).
2. Keep this PR's i18n module as the canonical one and ask feat(ui): i18n (EN/PL), screenshot, settings panel, reduced motion, uptime clock #309 to layer EN/PL translations into it instead.

Either works architecturally. Whichever shape the maintainer prefers, the other PR would need to align. Could you take a look at #309's ui/i18n/index.js and comment there on whether your translation set could drop into that structure?