[Web UI] 社区贡献征询：i18n 多语言化 + 移动端界面简化 + 特性检测优化 || [Web UI] Community contribution consultation: i18n multi-language + mobile interface simplification + feature detection optimization

[Gong-Mi]

背景

目前 Web UI 在移动端浏览器（尤其是 Android）上的体验还有不少打磨空间。我在本地做了些调研，想先征询官方意见，确认方向对齐后再提 PR，避免大改动被拒。

---

1. i18n 多语言化

现状：Web UI 全是英文硬编码（toast、placeholder、aria-label、按钮文案等约 100+ 处），没有国际化基础设施。

方案：引入 react-i18next + i18next-browser-languagedetector，先支持 en / zh，按模块渐进替换硬编码文本，避免一次性改几十个文件。

问题：官方是否欢迎社区来做 i18n？如果有规划中的技术选型，我可以对齐。

---

2. 移动端界面简化（图标替代文字）

现状：小屏下文字按钮占空间（如 "New session"、"Refresh Sessions"）。

方案：在 <1024px 断点下，部分纯文字按钮改为 lucide-react 图标 + Tooltip，保留 aria-label 确保无障碍。桌面端完全不变。

问题：这种图标化是否符合官方 UI 规范？

---

3. 移动端特性检测（非 UA 嗅探）

现状：目前纯响应式，没有针对 touch / 高分屏 / 软键盘做精细化处理。

方案：只用标准特性检测 API，不做平台特判：

• window.visualViewport → 解决 Android 键盘弹起压扁布局
• @media (hover: none) / pointer: coarse → touch 设备优化
• window.devicePixelRatio → 高分屏图标清晰度（只做渲染优化，不做布局分支）

问题：官方是否接受这类 feature-detection 层面的优化？

---

总结

以上三项都围绕 Web UI 移动端体验，改动不小。希望先确认官方对优先级和技术方案的倾向，对齐后再开具体 Issue / 提 PR。

如果官方觉得某几项可以接受，我可以进一步细化方案并拆成小批量 PR 提交。

---

Background

Currently, there is still a lot of room for improvement in the experience of Web UI on mobile browsers (especially Android). I did some research locally and wanted to seek official opinions first and confirm that the direction is aligned before submitting a PR to avoid rejection of major changes.

---

1. i18n multi-language

Current situation: The Web UI is all hard-coded in English (about 100+ places such as toast, placeholder, aria-label, button copy, etc.) and has no international infrastructure.

Plan: Introduce react-i18next + i18next-browser-languagedetector, support en/zh first, and gradually replace hard-coded text by module to avoid changing dozens of files at one time.

Question: Does the official welcome the community to do i18n? If there is a planned technology selection, I can align it.

---

2. Simplified mobile interface (icons replace text)

Current situation: Text buttons under small screens take up space (such as "New session", "Refresh Sessions").

Scheme: Under the <1024px breakpoint, some plain text buttons are changed to lucide-react icon + Tooltip, and aria-label is retained to ensure accessibility. The desktop version is completely unchanged.

Question: Does this iconification comply with the official UI specification?

---

3. Mobile terminal feature detection (non-UA sniffing)

Current situation: Currently purely responsive, there is no refinement for touch/high-resolution screen/soft keyboard.

Plan: Only use standard feature detection API, without platform-specific judgment:

• window.visualViewport → Solve the problem of Android keyboard popping up and flattening layout
• @media (hover: none) / pointer: coarse → touch device optimization
• window.devicePixelRatio → High-resolution screen icon clarity (only rendering optimization, no layout branching)

Question: Does the official accept this type of feature-detection level optimization?

---

Summary

The above three items all focus on the Web UI mobile experience, and the changes are not small. I hope to confirm the official preference for priorities and technical solutions first, and then open a specific issue/raise a PR after aligning them.

If the official feels that certain items are acceptable, I can further refine the plan and split it into small batches for PR submission.