Problem / 问题描述
English
The current UI contains many hardcoded Chinese strings across the frontend. This makes the project difficult to use for non-Chinese users and also makes future localization harder to maintain.
At the moment, even if users can understand the documentation, the actual interface is still heavily Chinese-only. This creates a barrier for international adoption.
Main problems:
- Many visible UI texts are hardcoded directly in components/pages
- It is difficult to switch the interface to English or other languages
- Future translation work would require repeatedly editing source components
- Community contributors cannot easily add new locales
I would like to request a basic i18n foundation for the frontend so the project can support multiple interface languages more cleanly.
中文
当前前端界面中存在大量硬编码的中文文本，这使得非中文用户很难使用本项目，也会让后续的本地化维护变得更加困难。
目前即使用户能够看懂文档，实际界面仍然高度依赖中文，这会对国际用户的使用和推广造成明显门槛。
主要问题：
- 许多界面可见文本直接硬编码在组件或页面中
- 很难将界面切换为英文或其他语言
- 后续翻译时需要反复修改源组件，维护成本较高
- 社区贡献者无法方便地新增语言包
我希望项目能够先加入一个基础的前端 i18n 结构，以便更规范地支持多语言界面。
Proposed Solution / 建议方案
English
I suggest introducing a minimal frontend i18n layer first, with a small and safe scope.
Suggested first phase:
- Keep Chinese (
zh-CN) as the default language
- Add English (
en) as the second locale
- Extract hardcoded UI strings into locale files
- Only translate interface text, not AI-generated content
- Avoid changing business logic unless necessary
- Start with the most user-facing pages/components first
Possible implementation idea:
- Introduce a lightweight i18n solution for the frontend
- Create locale files such as
zh-CN.json and en.json
- Replace direct UI strings with translation keys
- Keep the current Chinese wording as the source of truth initially
Benefits:
- Easier for international users to adopt the project
- Easier for contributors to add more languages later
- Cleaner code structure for UI text management
- Lower maintenance cost for future localization
If this direction is acceptable, I am willing to prepare a PR for the first step.
中文
我建议先引入一个最小化、低风险的前端 i18n 方案，先从小范围开始。
建议的第一阶段：
- 保持中文（
zh-CN）为默认语言
- 新增英文（
en）语言包
- 将硬编码的界面文本提取到语言文件中
- 仅处理界面文本，不处理 AI 生成内容
- 除非确有必要，否则不改动业务逻辑
- 优先从用户最常接触的页面/组件开始
可能的实现思路：
- 在前端引入一个轻量级 i18n 方案
- 创建如
zh-CN.json 和 en.json 的语言文件
- 用翻译 key 替换直接写死的界面文本
- 初期以当前中文文案作为基准文本
这样做的好处：
- 更方便国际用户使用项目
- 后续社区贡献者更容易添加其他语言
- 界面文本管理更清晰，代码结构更规范
- 降低未来本地化维护成本
如果这个方向可以接受，我愿意先提交第一阶段的 PR。
Component / 功能模块
Settings / 设置
Alternatives / 替代方案
English
Possible alternatives I have considered:
- Keep the current Chinese-only UI and rely only on translated documentation
- Translate only a few key pages manually without introducing a full i18n structure
- Maintain a separate fork with English UI changes
However, these alternatives all have clear drawbacks:
- Documentation-only translation does not solve the Chinese-only interface problem
- Manual text replacement without i18n will become harder to maintain over time
- A separate fork increases long-term maintenance cost and makes upstream synchronization harder
Because of this, I think adding a small i18n foundation in the main project is the cleaner long-term solution.
中文
我考虑过以下替代方案：
- 保持当前纯中文界面，仅提供翻译后的文档
- 不引入完整 i18n 结构，只手动翻译少量关键页面
- 维护一个带英文界面的独立分支或 fork
但这些方案都有明显缺点：
- 仅翻译文档并不能解决界面仍然是中文的问题
- 不使用 i18n、只做手动文本替换，后续维护会越来越困难
- 独立 fork 会增加长期维护成本，也会让后续同步上游变得更麻烦
因此，我认为在主项目中加入一个小规模、基础的 i18n 结构，会是更干净、更可持续的方案。
Additional Context / 补充说明
English
Additional context:
- I am interested in helping make the project easier for non-Chinese users.
- I noticed that the repository already includes
README_EN.md, so multilingual support seems consistent with the project direction.
- My request is focused on interface text only, not on translating AI-generated content.
- To reduce review risk, I suggest starting with a small first step and limiting the initial PR to frontend UI text extraction and locale files.
If this proposal is acceptable, I am willing to prepare a small PR for the first phase.
中文
补充说明：
- 我希望帮助这个项目更方便地被非中文用户使用。
- 我注意到仓库已经提供了
README_EN.md，所以增加多语言界面支持与项目方向看起来是一致的。
- 我的建议只针对界面文本，不涉及 AI 生成内容的翻译。
- 为了降低评审风险，我建议先从一个较小的第一步开始，初始 PR 只处理前端界面文本提取和语言文件。
如果这个提议可以接受，我愿意先准备第一阶段的小型 PR。
Problem / 问题描述
English
The current UI contains many hardcoded Chinese strings across the frontend. This makes the project difficult to use for non-Chinese users and also makes future localization harder to maintain.
At the moment, even if users can understand the documentation, the actual interface is still heavily Chinese-only. This creates a barrier for international adoption.
Main problems:
I would like to request a basic i18n foundation for the frontend so the project can support multiple interface languages more cleanly.
中文
当前前端界面中存在大量硬编码的中文文本，这使得非中文用户很难使用本项目，也会让后续的本地化维护变得更加困难。
目前即使用户能够看懂文档，实际界面仍然高度依赖中文，这会对国际用户的使用和推广造成明显门槛。
主要问题：
我希望项目能够先加入一个基础的前端 i18n 结构，以便更规范地支持多语言界面。
Proposed Solution / 建议方案
English
I suggest introducing a minimal frontend i18n layer first, with a small and safe scope.
Suggested first phase:
zh-CN) as the default languageen) as the second localePossible implementation idea:
zh-CN.jsonanden.jsonBenefits:
If this direction is acceptable, I am willing to prepare a PR for the first step.
中文
我建议先引入一个最小化、低风险的前端 i18n 方案，先从小范围开始。
建议的第一阶段：
zh-CN）为默认语言en）语言包可能的实现思路：
zh-CN.json和en.json的语言文件这样做的好处：
如果这个方向可以接受，我愿意先提交第一阶段的 PR。
Component / 功能模块
Settings / 设置
Alternatives / 替代方案
English
Possible alternatives I have considered:
However, these alternatives all have clear drawbacks:
Because of this, I think adding a small i18n foundation in the main project is the cleaner long-term solution.
中文
我考虑过以下替代方案：
但这些方案都有明显缺点：
因此，我认为在主项目中加入一个小规模、基础的 i18n 结构，会是更干净、更可持续的方案。
Additional Context / 补充说明
English
Additional context:
README_EN.md, so multilingual support seems consistent with the project direction.If this proposal is acceptable, I am willing to prepare a small PR for the first phase.
中文
补充说明：
README_EN.md，所以增加多语言界面支持与项目方向看起来是一致的。如果这个提议可以接受，我愿意先准备第一阶段的小型 PR。