Sublime Text没有真正可用的划词翻译插件，必须用trans命令行工具+Build System实现选中即译；因其底层不支持系统级划词事件，插件依赖的on_selection_modified事件触发不可靠，且同步HTTP请求导致卡顿、乱码、429限流等问题必然发生。
Sublime Text 没有真正可用的划词翻译插件，装了也基本等于白装——卡顿、乱码、空响应、误翻代码，全是必然结果。别折腾插件，直接用 trans + Build System，5 分钟配好，稳定不卡。
为什么所有划词翻译插件都必然失效
不是你配置错了，是 Sublime 的底层机制和翻译服务端限制共同决定了它们无法可靠运行：
-
on_selection_modified事件根本不是“划词触发器”，它只在手动鼠标拖选或按方向键选中时才可能触发，Ctrl+Shift+Right快速选词、切 Tab 后立刻划词、甚至只点一下光标，它都不响 - 插件用
urllib.request发同步 HTTP 请求，ST4 的 Python 3.3 运行时没异步支持，一调 API 编辑器就假死几秒 - 注释识别靠正则硬切，
//后整行都发出去，连/* */外的变量名都可能被吞进去 - 遇到 emoji、全角标点、BOM 或混合编码，直接抛
UnicodeDecodeError - 连续请求很快触发 Google/Bing 返回
429 Too Many Requests，后续全白屏或空字符串
怎么配一个真能用的 Build System 翻译方案
核心思路：把选中文本交给外部命令，不卡主线程、不乱码、不被限流。关键配置项必须写对：
-
shell_cmd中必须用${selected_text}（Sublime 内置变量），且必须先选中文字再按Ctrl+B -
-brief去掉音标/词性等冗余输出，避免粘贴回编辑器时带干扰字符 -
-e google显式指定引擎，防 fallback 到已失效接口导致空响应 -
selector设为comment，让Ctrl+B只在注释区域生效，杜绝误翻代码 - Windows 用户必须用 WSL（如 Ubuntu 22.04+）跑
trans，原生cmd或powershell对 UTF-8 换行处理不可靠，中文必丢字
配置文件 Translate.sublime-build 内容如下：
{"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+'把选区粗分为语言块列表 - 结合
view.sel()[0].begin()光标位置，反向找最近一块作为目标词 - 若选区首字符是 ASCII 字母、末字符是中文（如
"init初始化"），大概率是跨语言误选，应自动收缩至首个连续汉字段 - 禁用
view.expand_to_scope('string')，它会在字符串内吞掉引号和转义符，导致翻译结果带多余符号
Build System 翻译后怎么把结果粘贴回来
默认 Build System 不支持“自动回填”，得靠外部工具链衔接。最轻量的做法是：
- 把
shell_cmd改成管道形式："trans -brief -e google -s auto -t zh : '${selected_text}' | xclip -selection clipboard -i"（Linux）或pbcopy（macOS） - Windows WSL 下需额外启用 X11 转发或改用
wsl.exe -e clip.exe写入 Windows 剪贴板 - 回填动作由快捷键完成：翻译完按
Ctrl+V即可，比任何“自动替换”更可控、更少出错
真正难的不是配命令，而是意识到：Sublime 的设计哲学是“做小而快的文本处理器”，不是“集成翻译 IDE”。越想让它干不属于它的活，越容易掉进阻塞、乱码、限流的坑里。
