优先选 googlecn，因其为大陆网络优化的镜像入口，可避免超时或403错误；需重启vs code生效，且不支持全部语言对，失败时可临时切换百度引擎。
翻译插件选 GoogleCN 还是 Google？
国内直连 google API 大概率超时或返回 403，google-cn 是专为大陆网络优化的镜像入口，但注意它不等于“百度翻译”或“彩云小译”——只是请求路由不同，底层仍是 Google 翻译引擎。如果你在设置里看到 translatorHelper.api 为 google 却始终无响应，别折腾代理，直接改成 google-cn。
常见错误现象：Failed to fetch translation 或控制台报 net::ERR_CONNECTION_TIMED_OUT；使用场景：批量处理 Docs 文档段落时，连续失败超过 3 次基本可判定是路由问题。
- 改完配置后必须重启 VS Code，仅重载窗口无效
-
google-cn不支持所有语言对，比如en → ja可能 fallback 到默认接口，此时需手动检查响应头中的X-Forwarded-For是否指向国内 IP - 若仍失败，临时换用
baidu引擎（需申请 AK/SK 并填入translatorHelper.baiduAppId和translatorHelper.baiduSecretKey）
翻译结果插入位置为什么总错乱？
Translator Helper 默认把译文插在原文**正下方**，但实际效果取决于光标位置、选区范围和文档格式。它不会自动加空行或缩进，也不会识别 Markdown 的代码块/引用块边界。
容易踩的坑：在 Markdown 表格中翻译某一行，译文会直接贴在下一行开头，破坏表格结构；在 JSON 或 YAML 中翻译键值对，译文可能插入到字符串引号外侧。
- 操作前先确认选区是否精确——用
Shift+→逐字符扩展比鼠标拖动更可靠 - 遇到结构敏感内容（如 frontmatter、YAML mapping），建议先复制原文到新文件，翻译完成后再粘贴回原位置
- 插件不解析语法树，所以对 JSX 注释、TypeScript JSDoc 的多行
/** */块，译文会挤成单行，需人工换行
中文文档校对时怎么避免覆盖原始英文？
真实协作流程不是“机器翻完就提交”，而是“译文紧贴原文 + 手动删改 + 保留可追溯性”。VS Code 本身不提供双语对照视图，得靠约定格式撑住流程。
推荐做法：用 HTML 注释包裹译文，例如 <!-- zh: xxx -->，既不影响渲染，又方便 grep 检索；或在原文后加 // [zh] xxx，适配 JS/TS 文件。
- 不要依赖插件的“替换原文”功能——一旦误操作，Git diff 里看不到源文本，PR 审核方无法判断修改是否合理
- Translator Helper 的
insertAfterSelection模式是安全底线，永远别开replaceSelection - 多人协作时，提前约定译文标记格式，否则后续脚本清洗（如提取全部
[zh]内容生成 glossary）会失败
为什么设置里 targetLanguage 改成 zh-CN 没用？
这个参数只影响翻译方向，不控制 UI 显示语言。很多人混淆了「翻译目标语言」和「VS Code 界面语言」——前者由 translatorHelper.targetLanguage 控制，后者由 locale 设置决定，二者完全独立。
典型症状：插件输出的译文是日文，但你明明设了 zh-CN；或者界面菜单是中文，但翻译结果却是繁体字。这说明插件读取的是另一个配置项，或 API 返回了未指定 region 的简体中文变体。
- 检查
settings.json中是否有重复定义，比如同时存在translatorHelper.targetLanguage和旧版translation.targetLang - Google 翻译 API 对
zh-CN和zh处理逻辑不同：zh可能返回港澳台常用词，zh-CN更倾向大陆术语，但不绝对 - 如果发现译文混用简繁体，不是插件 bug，是上游 API 未严格按 locale 返回——需在 PR 描述里注明术语统一规则，而非指望插件解决
真正难的不是点几下按钮，而是每次插入译文后，得立刻判断这句要不要加术语表索引、是否触发上下文重译、有没有漏掉隐藏的英文字符串（比如 error code 字面量）。这些没法靠插件自动完成。
