sublime text不能安装稳定可用的翻译插件，因其依赖不可靠的on_selection_modified事件且同步http请求导致卡顿；应改用trans命令行工具+build system实现选中即译。
Sublime Text 不能装稳定可用的翻译插件——所有标榜“一键划词翻译”“悬浮取词”的插件，2026 年已全部失效或不可靠。你点开 Package Control 搜索 Translate、Dictionary 或 Quick Translate，装上后大概率遇到：空白弹窗、按快捷键无响应、翻译结果全是问号、或者编辑器卡死几秒。这不是你操作错了，是底层机制决定它跑不起来。
为什么所有翻译插件都失效了
根本原因不是 Sublime 不行，而是插件写法和平台限制冲突：
-
on_selection_modified事件根本捕获不到 Ctrl+Shift+Right 这类快捷键选词动作，很多场景下压根不触发 - 插件运行在 Sublime 的 Python 3.3 主线程里，
urllib.request同步发请求 → 光标一悬停就卡住，用户感知就是“假死” - 注释识别靠正则硬匹配，
// init 初始化可能被当成整行代码发出去，甚至把if (x > 0)也裹进去 - 遇到 emoji、全角括号、BOM 头或混合编码，直接抛
UnicodeDecodeError - 连续请求很快触发 Google/Bing 返回
429 Too Many Requests，后续全空
怎么配一个真正能用的 Build System 翻译方案
绕过插件，用命令行工具 trans（translate-shell）+ Sublime 的 Build System，才是唯一快、稳、不卡、不乱码的路径。关键配置必须对：
-
shell_cmd中必须含${selected_text}—— 这是 Sublime 内置变量，没选中文字就按Ctrl+B，命令静默失败 - 加
-brief参数，否则返回带音标、词性、例句的长文本，粘贴回注释会污染格式 - 显式指定引擎：
-e google，防 fallback 到已失效的 Bing/DeepL 接口导致空响应 -
selector设为"comment"，让Ctrl+B只在//或/* */区域生效，避免误翻代码 - Windows 用户必须用 WSL（如 Ubuntu 22.04+）安装并运行
trans，原生cmd或powershell对 UTF-8 换行处理不可靠，中文必丢字
配置文件 Translate.sublime-build 内容如下（保存到 Packages/User/ 目录）：
{"shell_cmd":"trans -brief -e google -s auto -t zh : '${selected_text}'", "selector":"comment", "file_regex":"^.*$"}
中英文混合注释怎么精准取词
别信 view.word() —— 它对 "funcName初始化" 这种串返回整块，但你要的只是“初始化”。实际要手动分块再定位：
- 用正则
r'[a-zA-Z]+|[\u4e00-\u9fff]+|\d+'把选区粗分为语言块列表，比如["funcName", "初始化"] - 结合
view.sel()[0].begin()光标位置，反向找最近一块作为目标词 - 若选区首字符是 ASCII 字母、末字符是中文（如
"init初始化"），大概率是跨语言误选，应自动收缩至首个连续汉字段 - 禁用
view.expand_to_scope('string')—— 它会在字符串内吞掉引号和转义符，导致翻译结果带多余符号
Build System 翻译后怎么把结果粘贴回来
Sublime 的 Build System 默认不回填结果，得靠外部命令输出 + 手动粘贴。目前最可靠的做法是：
- 保持
shell_cmd输出为纯文本（靠-brief保证），复制终端输出内容，Ctrl+V粘贴回编辑器 - 不要指望插件自动替换选区 —— 自动替换需监听构建完成事件，而
trans是异步进程，Sublime 的exec类不保证回调时机，强行做容易错位或覆盖错误区域 - 如果真要自动化回填，必须用
sublime.set_timeout_async封装子进程调用，并手动读取 stdout，但复杂度陡增，且仍受 Windows 终端编码限制
真正省事的方式，是接受“选中→Ctrl+B→看终端→Ctrl+V”这个四步流程。它不炫技，但每一步都可控、可 debug、不卡顿、不丢字。
