Feature/auto detect language for init command

[AndersHsueh]

TLDR

功能：为 /init 命令添加语言自动检测

变更概述
此PR为Qwen Code的/init命令增加了语言自动检测功能，使命令能够根据系统语言环境自动选择合适的语言
模板，同时保留用户手动指定语言的优先级。

主要变更

1. 系统语言检测：实现detectSystemLanguage()函数，自动检测系统语言环境

   • 检查环境变量（LC_ALL, LC_MESSAGES, LANG, LANGUAGE, npm_config_language）
   • 支持多语言格式（如 zh, ja, ko, en 及区域格式如 zh-cn, zh-tw）
   • 提供回退机制，默认使用英文

2. 用户参数优先级：保留用户手动指定参数的优先级

   • 用户仍可使用/init jp等命令覆盖自动检测
   • 只有在未提供参数时才进行自动检测

3. 用户体验改进：更新UI消息以指示语言是自动检测还是手动指定的

技术详情

• 修改了initCommand.ts中的逻辑，优先使用用户参数，其次自动检测
• 创建语言模板映射，将检测到的语言代码映射到支持的模板
• 维持了向后兼容性

测试

• 项目成功构建，没有错误
• 代码符合TypeScript类型检查要求

用法

• 自动检测：/init
• 手动指定：/init en、/init cn、/init jp、/init kr

此功能增强了Qwen
Code的国际化能力，使/init命令更智能地适配用户的系统语言环境，同时保持了手动指定语言的灵活性。

Dive Deeper

Reviewer Test Plan

Testing Matrix

	🍏	🪟	🐧
npm run	❓	❓	❓
npx	❓	❓	❓
Docker	❓	❓	❓
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

[pomelo-nwu]

@AndersHsueh 非常感谢你的贡献！不过我暂时无法合并你的 PR，原因是对于语言的偏好应该是整个系统的设置，而且最好是通过memory文件让 LLM 来指导，而非工程上增加语言参数来设置（因为还有todo，subagent等等）。你可以试着将这个 prompt 放置在你的~/.qwen/QWEN.md文件中，应该能满足你的需求 /init 输出项目的中文代码分析

# 中文回复规则

## 核心规则

**所有输出必须使用简体中文，无例外。** 包括：对话回复、工具调用结果、生成的文件、文档、注释、错误信息。即使用户使用英文提问，也必须用中文回复。

## 工具调用输出

所有工具执行后的结果描述、成功/失败消息、摘要说明必须使用中文：

- 文件操作：`read_file`、`write_file`、`edit_file` 等
- 代码搜索：`codebase_search`、`grep` 等
- 终端命令：`run_terminal_cmd` 执行结果说明
- 其他工具：`todo_write`、`web_search` 等

**示例：**

- ✅ "已成功读取文件 config.json，包含 15 行配置"
- ❌ "Successfully read file config.json, contains 15 lines"

**注意：** 代码中的变量名和函数名可保持英文，但注释、文档和所有说明文字必须是中文。

• 相关的 issue 还有：对话、项目总结和subagent描述等的默认语言为英文且无法彻底修改 #850

[AndersHsueh]

@pomelo-nwu 你好, 我知道这个编辑 ~/.qwen/QWEN.md 的方式, 这样最符合逻辑, 也特别规整.
我的思路是这样的, 无论如何我们做的软件是给人用的. 很多的用户在希望“试用一下”的场景中. 得到的是一篇英文答复. 这无疑是令人沮丧的. 而据我自己测试. 如果第一句和Qwen说一段有指令含义的中文. 则它会自动用中文回答. 而如果第一句用了 /init 那么基本上这个回答就是英文的. 而且 /init 生成的内容也是英文的, 对很多国内的朋友有一定的阻碍.
Qwen Code是一个很好的工具, 我不断的向身边的朋友推荐. 而他们只肯用 Cursor , Trae 也不愿多看这里一眼. 我希望降低这个门槛. 让更多人先用上. 而不是艺术性的自我设限.

能否保留我的自动检测当前系统语言部分? 我不改变 /init 命令的参数行吗 ?

[pomelo-nwu]

@AndersHsueh 感谢你的热心推荐！非常赞赏你帮忙解决「上手门槛高」这个问题。不过给 /init中检测系统语言也不是一个好主意，因为正如 memory 的设计，都有 project memory 和 user memory 的区分，这个不能简单通过用户本地系统语言来检测。技术上，使用模版也不是一个优雅的方式。

我这边有两个思路提供：

• 第一，让我们为用户创建一个「用户文档」，当前的文档其实偏向「开发者文档」，我们可以把「如何设置系统的语言偏好」作为一个文档呈现在「用户文档」中。
• 第二，产品层面我们可以增加一个「On Boarding」功能，类似 Claude Code，当用户第一次启动 qwen 的时候，让用户自己决定偏好语言是什么，相应地动态更新 Memory 文件。这样也可以解决上手门槛高的问题

---

@AndersHsueh Thank you for your enthusiastic recommendation! I really appreciate your effort in helping to address the "high learning curve" issue. However, automatically detecting the system language in /init is not an ideal solution. As designed in the memory system, there is a clear distinction between project memory and user memory, and this cannot be simply determined by the user's local system language. Technically, using templates is also not an elegant approach.

I have two suggestions to propose:

• First, let's create a "User Documentation" for our users. The current documentation is more oriented toward "Developer Documentation." We can include "How to set system language preferences" as a section in the "User Documentation."

• Second, on the product side, we could introduce an "Onboarding" feature, similar to Claude Code. When users launch qwen for the first time, allow them to decide their preferred language and dynamically update the Memory file accordingly. This would also help lower the learning curve.

[AndersHsueh]

@pomelo-nwu
我个人非常看好您的第二种方案. 这个最直观. 不需要用户去了解规则(学习成本低)就能自然的达成.

我希望它能入手容易, 当用户深入了解后又能发挥更多复杂功能. windows的成功就是让我爸都能用电脑完成目标. 我非常崇尚这一点.
最后, 我多谈一个延伸的问题. 这个CLI在非专业年轻人口中称“小黑窗”, 不爱用. 这也是普及推广的一种阻碍. 我在构思一种让它集成使用到系统(日常工作)当中的方式(我还没想好) .

---

I personally very much favor your second approach. It's the most intuitive and can be naturally achieved without
requiring users to understand the rules (low learning cost).

I hope it's easy to get started with, and as users gain deeper understanding, they can unlock more complex features.
Windows' success is exemplified by enabling my father to accomplish computer tasks. I greatly admire this approach.

Finally, let me discuss an extended issue. This CLI is referred to as "the little black window" among
non-professional young people, and they are reluctant to use it. This is also an obstacle to popularization and
promotion. I'm contemplating a way to integrate it into the system (daily work) for more seamless usage (though I
haven't figured it out yet).