Easydict Issue 翻译工作流固定版本升级实录issues-translate-action v2.8.3 的 Markdown URL 误判修复【免费下载链接】Easydict一个简洁优雅的词典翻译 macOS App。开箱即用支持离线 OCR 识别支持有道词典 苹果系统词典 苹果系统翻译OpenAIGeminiDeepLGoogleBing腾讯百度阿里小牛彩云和火山翻译。A concise and elegant Dictionary and Translator macOS App for looking up words and translating text.项目地址: https://gitcode.com/gh_mirrors/ea/Easydict导读Easydict 仓库通过 GitHub Actions 中的issues-translate-action自动将中文 Issue、评论与 PR review comment 翻译为英文同时将英文内容回译为简体中文。本文以 2026-09-04-issue-translator-v2.8.3.md 这份升级记录为骨架完整还原 v2.8.3 的升级动机语言识别阶段忽略 Markdown 图片/链接中的 HTTP(S) URL避免中文正文被误判为英文而跳过翻译、固定 tag 的依赖治理策略以及 YAML 解析、diff 检查、引用范围审计的完整验证流程。读完本文你将掌握 Easydict 的 Issue 翻译自动化现状、其只固定引用已发布 patch tag、不依赖分支的依赖升级规范以及一套可复制的 GitHub Actions 依赖升级核验方法。背景Easydict 的 Issue 翻译自动化Easydict 是一个开源的多语种词典与翻译 macOS App仓库中通过 GitHub Actions 维护了多条自动化流水线。其中与社区协作最相关的是 Issue 翻译流水线配置文件位于 .github/workflows/issue-translator.yml。该工作流调用上游第三方 Actiontisfeng/issues-translate-action实现了 Issue 讨论区的自动双语化。当前仓库中该工作流的实际内容如下注意当前已演进至 v2.9.2但整体骨架与 v2.8.3 时代一致name: issue-translator on: issue_comment: types: [ created ] issues: types: [ opened ] pull_request_review_comment: types: [ created ] jobs: translate: runs-on: ubuntu-latest steps: - uses: tisfeng/issues-translate-actionv2.9.2 with: IS_MODIFY_TITLE: false PRIMARY_LANGUAGE: zh-CN SECONDARY_LANGUAGE: en CUSTOM_BOT_NOTE: Bot automatically translated this content.触发事件与翻译范围工作流通过三个事件触发覆盖了社区讨论的全部入口事件类型过滤触发时机issue_commentcreated新建 Issue 评论issuesopened新建 Issuepull_request_review_commentcreated新建 PR review 行内评论从 2026-09-17-issue-translator-v2.9.2.md 与 2026-09-04-issue-translator-v2.8.2.md 等历史记录可以确认Easydict 在历次升级中始终坚持只更新uses:引用的 Action 版本号不改动事件、表达式、权限与with输入配置的约束确保翻译行为语义稳定。四个关键输入项工作流中配置了四个 Action 输入含义如下IS_MODIFY_TITLE: false不直接改写 Issue 标题原文。按 2026-09-05-issue-translator-v2.9.0.md 的记录标题与正文会分别选择目标语言原始标题不会被直接修改翻译以评论形式呈现。PRIMARY_LANGUAGE: zh-CN非首选语言内容的目标语言。即日文、韩文及无法识别的文本一律翻译为简体中文。SECONDARY_LANGUAGE: en首选语言内容的目标语言。即中文内容翻译为英文。CUSTOM_BOT_NOTE翻译评论中附加的 Bot 提示文案使用与任意翻译方向一致的中性表述。v2.8.3 核心变更语言识别前的 Markdown URL 过滤本次升级关联文档是一次纯版本钉扎version pinning更新将.github/workflows/issue-translator.yml中固定的 Action 引用从v2.8.2更新为v2.8.3事件、inputs 与node24运行时保持不变。修复的问题场景v2.8.3 的核心修复点在语言识别language detection环节。在升级前Action 对评论内容执行语言识别时会把 Markdown 图片与链接中的 HTTP(S) URL 一并纳入判断。这带来一个典型的误判场景一条中文正文的评论中如果夹带了英文/URL 形式的 Markdown 链接例如[查看截图](https://example.com/xxx.png)或直接粘贴的图片地址URL 中大量的 ASCII 字符会显著拉高英文特征的权重导致整条评论被误判为英文内容从而被跳过翻译——但该评论的实际正文是中文本应被翻译为英文。修复策略识别与翻译分离v2.8.3 的处理方式体现了识别用轻量文本、翻译用完整原文的分离原则语言识别前忽略stripMarkdown 图片与链接中的 HTTP(S) URL仅基于剩余正文做语言判断从而让中文评论稳定地落入需要翻译的分支实际翻译时仍使用完整原文含 Markdown 标记保证翻译结果保留原有链接与排版结构不因识别阶段的过滤而丢失内容。这意味着该修复对用户侧是透明的评论中的链接与图片依然原样出现在翻译结果里变化的只是这条评论要不要翻译的判定结果。设计意图固定 patch tag拒绝分支依赖Easydict 对第三方 Action 的依赖治理策略十分明确从本记录的设计意图一节可以提炼出三条原则只固定引用已验证的 Action tag。上游每次发布后先在本地核验 tag 指向的提交与 Release 状态确认无误后才更新引用绝不直接依赖main等可变分支。明确 patch tag 为不可变部署边界。如 2026-09-04-issue-translator-v2.8.2.md 中所记tag 是工作流依赖的不可变部署边界必须先确认 tag 已推送才更新 Easydict 引用。小步升级、一次一个 patch 版本。从 v2.8.1 → v2.8.2 → v2.8.3 → v2.9.0 → v2.9.1 → v2.9.2每次只前进一个已发布版本避免跨版本跳升引入不可控的破坏性变更。这套策略的收益是任何时刻仓库中运行的工作流行为都是可审计、可回溯的出现问题时可以精确地定位到某个 tag 对应的行为变化而非受上游分支漂移影响。升级操作与验证流程可复制的清单v2.8.3 升级记录中给出了完整的验证步骤这套流程在后续 v2.9.0、v2.9.1、v2.9.2 的升级中被反复复用可提炼为通用清单第 1 步核验上游 tag 指向在更新引用之前先确认上游v2.8.3tag 已推送且指向预期提交。本次记录中更新前v2.8.3^{}peeled tag即解引用后的最终提交解析到fc86486959aad3c51b4903044534e6cdc09468a3。后续 v2.9.2 升级还进一步要求 Release 为非 draft、非 prerelease 状态防止引用到未正式发布的版本。第 2 步核对运行时契约兼容性确认上游action.yml的以下内容与当前引用版本兼容inputs定义IS_MODIFY_TITLE、PRIMARY_LANGUAGE、SECONDARY_LANGUAGE、CUSTOM_BOT_NOTE等参数名与默认值没有变更runs.using: node24运行时版本未变化dist/index.js入口打包产物结构与入口一致。v2.8.3 记录明确上游action.yml的 inputs、runs.using: node24与dist/index.js入口均与v2.8.2兼容这是决定能否只改一行引用的关键前提。第 3 步执行本地静态验证升级记录中使用的本地验证手段包括YAML 解析对.github/workflows/issue-translator.yml执行 YAML 语法解析如 RubyYAML.safe_load确保修改后的工作流文件语法合法git diff --check检查 diff 中是否存在空白字符错误trailing whitespace 等引用范围审计确认运行时 workflow 中的 Action 引用唯一且恰好为v2.8.3不存在其他残留版本引用。注意v2.9.0 的验证记录中特别说明未运行actionlint本机未安装该工具原因是本次仅变更 Action 引用与with输入未改事件、表达式或权限。可见验证工具的选用与变更范围相匹配。第 4 步控制变更范围允许修改的路径被严格限定在工作流文件与文档记录.github/workflows/issue-translator.ymldocs/exec-plans/下的计划归档docs/histories/2026-09/下的 history 记录禁止改动其他工作流、产品代码、Xcode 工程或用户内容也禁止在升级过程中触发真实 workflow 运行。第 5 步记录并等待真实环境验证升级完成后不执行推送或仅按约定推送翻译行为的最终验证交给下一次自然发生的中文 Issue、评论或 PR review comment——由 GitHub 托管的 Runner 在真实网络环境中验证。这是因为本地验证无法替代 GitHub Runner 的真实网络连通性与运行环境这一点在 v2.8.2 记录中针对 Google 网页翻译 batch RPC 的连通性亦有说明。升级脉络回顾从 v2.8.2 到 v2.9.2将本记录放入 Easydict 的升级时间线中可以更清楚地看到它的位置日期版本变更要点记录文件2026-09-04v2.8.2上游将失效的tomsun28/google-translate-api替换为固定版本google-translate-api-x10.7.3强制使用 Google 网页翻译 batch RPC并补充测试、重新生成distbundle2026-09-04-issue-translator-v2.8.2.md2026-09-04v2.8.3语言识别前忽略 Markdown 图片/链接中的 HTTP(S) URL避免中文评论被误判为英文本文关联文档2026-09-05v2.9.0配置中文优先双向翻译中文→英文、英文→简体中文日/韩文归入简体中文Bot 提示改为中性文案2026-09-05-issue-translator-v2.9.0.md2026-09-09v2.9.1核验上游 Release 为 stable 后仅更新uses:引用2026-09-09-issue-translator-v2.9.1.md2026-09-17v2.9.2固定引用已发布 tag不改触发条件与翻译配置当前仓库状态2026-09-17-issue-translator-v2.9.2.md可以看出Easydict 对 Issue 翻译工作流的维护遵循小步、固定、可审计的长期节奏上游每个 patch 版本发布后都经过 tag 核验、契约比对、静态检查三道关卡再以一行引用的最小 diff 落入仓库并留下对应的计划与 history 记录计划归档见 docs/exec-plans/completed/2026-09/ 目录。边界与注意事项适用前提上述升级流程适用于上游 Action 版本向后兼容的场景inputs 与运行时契约不变。若上游发生破坏性变更如输入项改名、Node 运行时升级、翻译后端更换则需要在第 2 步的契约核对中识别出来并同步调整with配置。本地验证的局限YAML 解析与 diff 检查只能保证配置静态正确无法验证真实翻译行为v2.8.2 记录明确指出本地网络无法代替 GitHub 托管 Runner 的真实 Google 连通性验证。因此真实环境验证依赖下一次自然触发的工作流运行。配置的当前形态截至本仓库当前状态工作流已演进至v2.9.2IS_MODIFY_TITLE: false、PRIMARY_LANGUAGE: zh-CN、SECONDARY_LANGUAGE: en、CUSTOM_BOT_NOTE的配置形态保持不变v2.8.3 修复的语言识别逻辑随后续版本继续生效。结语Easydict 的 Issue 翻译流水线是一个小依赖、大治理的典型样本一个看似只有一行的uses:引用背后是 tag 核验、契约比对、静态检查、范围审计与文档归档的完整闭环。v2.8.3 的升级更是演示了一个值得借鉴的工程细节——语言识别阶段应使用剥离 URL 等噪声后的轻量文本而翻译阶段应保留完整原文这一识别与翻译分离的思路对任何基于文本分类的自动化管线都有普遍参考价值。若你在自己的仓库中维护第三方 GitHub Actions本文的固定 tag 策略与验证清单可以直接复用。【免费下载链接】Easydict一个简洁优雅的词典翻译 macOS App。开箱即用支持离线 OCR 识别支持有道词典 苹果系统词典 苹果系统翻译OpenAIGeminiDeepLGoogleBing腾讯百度阿里小牛彩云和火山翻译。A concise and elegant Dictionary and Translator macOS App for looking up words and translating text.项目地址: https://gitcode.com/gh_mirrors/ea/Easydict创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Easydict Issue 翻译工作流固定版本升级实录：issues-translate-action v2.8.3 的 Markdown URL 误判修复
Easydict Issue 翻译工作流固定版本升级实录issues-translate-action v2.8.3 的 Markdown URL 误判修复【免费下载链接】Easydict一个简洁优雅的词典翻译 macOS App。开箱即用支持离线 OCR 识别支持有道词典 苹果系统词典 苹果系统翻译OpenAIGeminiDeepLGoogleBing腾讯百度阿里小牛彩云和火山翻译。A concise and elegant Dictionary and Translator macOS App for looking up words and translating text.项目地址: https://gitcode.com/gh_mirrors/ea/Easydict导读Easydict 仓库通过 GitHub Actions 中的issues-translate-action自动将中文 Issue、评论与 PR review comment 翻译为英文同时将英文内容回译为简体中文。本文以 2026-09-04-issue-translator-v2.8.3.md 这份升级记录为骨架完整还原 v2.8.3 的升级动机语言识别阶段忽略 Markdown 图片/链接中的 HTTP(S) URL避免中文正文被误判为英文而跳过翻译、固定 tag 的依赖治理策略以及 YAML 解析、diff 检查、引用范围审计的完整验证流程。读完本文你将掌握 Easydict 的 Issue 翻译自动化现状、其只固定引用已发布 patch tag、不依赖分支的依赖升级规范以及一套可复制的 GitHub Actions 依赖升级核验方法。背景Easydict 的 Issue 翻译自动化Easydict 是一个开源的多语种词典与翻译 macOS App仓库中通过 GitHub Actions 维护了多条自动化流水线。其中与社区协作最相关的是 Issue 翻译流水线配置文件位于 .github/workflows/issue-translator.yml。该工作流调用上游第三方 Actiontisfeng/issues-translate-action实现了 Issue 讨论区的自动双语化。当前仓库中该工作流的实际内容如下注意当前已演进至 v2.9.2但整体骨架与 v2.8.3 时代一致name: issue-translator on: issue_comment: types: [ created ] issues: types: [ opened ] pull_request_review_comment: types: [ created ] jobs: translate: runs-on: ubuntu-latest steps: - uses: tisfeng/issues-translate-actionv2.9.2 with: IS_MODIFY_TITLE: false PRIMARY_LANGUAGE: zh-CN SECONDARY_LANGUAGE: en CUSTOM_BOT_NOTE: Bot automatically translated this content.触发事件与翻译范围工作流通过三个事件触发覆盖了社区讨论的全部入口事件类型过滤触发时机issue_commentcreated新建 Issue 评论issuesopened新建 Issuepull_request_review_commentcreated新建 PR review 行内评论从 2026-09-17-issue-translator-v2.9.2.md 与 2026-09-04-issue-translator-v2.8.2.md 等历史记录可以确认Easydict 在历次升级中始终坚持只更新uses:引用的 Action 版本号不改动事件、表达式、权限与with输入配置的约束确保翻译行为语义稳定。四个关键输入项工作流中配置了四个 Action 输入含义如下IS_MODIFY_TITLE: false不直接改写 Issue 标题原文。按 2026-09-05-issue-translator-v2.9.0.md 的记录标题与正文会分别选择目标语言原始标题不会被直接修改翻译以评论形式呈现。PRIMARY_LANGUAGE: zh-CN非首选语言内容的目标语言。即日文、韩文及无法识别的文本一律翻译为简体中文。SECONDARY_LANGUAGE: en首选语言内容的目标语言。即中文内容翻译为英文。CUSTOM_BOT_NOTE翻译评论中附加的 Bot 提示文案使用与任意翻译方向一致的中性表述。v2.8.3 核心变更语言识别前的 Markdown URL 过滤本次升级关联文档是一次纯版本钉扎version pinning更新将.github/workflows/issue-translator.yml中固定的 Action 引用从v2.8.2更新为v2.8.3事件、inputs 与node24运行时保持不变。修复的问题场景v2.8.3 的核心修复点在语言识别language detection环节。在升级前Action 对评论内容执行语言识别时会把 Markdown 图片与链接中的 HTTP(S) URL 一并纳入判断。这带来一个典型的误判场景一条中文正文的评论中如果夹带了英文/URL 形式的 Markdown 链接例如[查看截图](https://example.com/xxx.png)或直接粘贴的图片地址URL 中大量的 ASCII 字符会显著拉高英文特征的权重导致整条评论被误判为英文内容从而被跳过翻译——但该评论的实际正文是中文本应被翻译为英文。修复策略识别与翻译分离v2.8.3 的处理方式体现了识别用轻量文本、翻译用完整原文的分离原则语言识别前忽略stripMarkdown 图片与链接中的 HTTP(S) URL仅基于剩余正文做语言判断从而让中文评论稳定地落入需要翻译的分支实际翻译时仍使用完整原文含 Markdown 标记保证翻译结果保留原有链接与排版结构不因识别阶段的过滤而丢失内容。这意味着该修复对用户侧是透明的评论中的链接与图片依然原样出现在翻译结果里变化的只是这条评论要不要翻译的判定结果。设计意图固定 patch tag拒绝分支依赖Easydict 对第三方 Action 的依赖治理策略十分明确从本记录的设计意图一节可以提炼出三条原则只固定引用已验证的 Action tag。上游每次发布后先在本地核验 tag 指向的提交与 Release 状态确认无误后才更新引用绝不直接依赖main等可变分支。明确 patch tag 为不可变部署边界。如 2026-09-04-issue-translator-v2.8.2.md 中所记tag 是工作流依赖的不可变部署边界必须先确认 tag 已推送才更新 Easydict 引用。小步升级、一次一个 patch 版本。从 v2.8.1 → v2.8.2 → v2.8.3 → v2.9.0 → v2.9.1 → v2.9.2每次只前进一个已发布版本避免跨版本跳升引入不可控的破坏性变更。这套策略的收益是任何时刻仓库中运行的工作流行为都是可审计、可回溯的出现问题时可以精确地定位到某个 tag 对应的行为变化而非受上游分支漂移影响。升级操作与验证流程可复制的清单v2.8.3 升级记录中给出了完整的验证步骤这套流程在后续 v2.9.0、v2.9.1、v2.9.2 的升级中被反复复用可提炼为通用清单第 1 步核验上游 tag 指向在更新引用之前先确认上游v2.8.3tag 已推送且指向预期提交。本次记录中更新前v2.8.3^{}peeled tag即解引用后的最终提交解析到fc86486959aad3c51b4903044534e6cdc09468a3。后续 v2.9.2 升级还进一步要求 Release 为非 draft、非 prerelease 状态防止引用到未正式发布的版本。第 2 步核对运行时契约兼容性确认上游action.yml的以下内容与当前引用版本兼容inputs定义IS_MODIFY_TITLE、PRIMARY_LANGUAGE、SECONDARY_LANGUAGE、CUSTOM_BOT_NOTE等参数名与默认值没有变更runs.using: node24运行时版本未变化dist/index.js入口打包产物结构与入口一致。v2.8.3 记录明确上游action.yml的 inputs、runs.using: node24与dist/index.js入口均与v2.8.2兼容这是决定能否只改一行引用的关键前提。第 3 步执行本地静态验证升级记录中使用的本地验证手段包括YAML 解析对.github/workflows/issue-translator.yml执行 YAML 语法解析如 RubyYAML.safe_load确保修改后的工作流文件语法合法git diff --check检查 diff 中是否存在空白字符错误trailing whitespace 等引用范围审计确认运行时 workflow 中的 Action 引用唯一且恰好为v2.8.3不存在其他残留版本引用。注意v2.9.0 的验证记录中特别说明未运行actionlint本机未安装该工具原因是本次仅变更 Action 引用与with输入未改事件、表达式或权限。可见验证工具的选用与变更范围相匹配。第 4 步控制变更范围允许修改的路径被严格限定在工作流文件与文档记录.github/workflows/issue-translator.ymldocs/exec-plans/下的计划归档docs/histories/2026-09/下的 history 记录禁止改动其他工作流、产品代码、Xcode 工程或用户内容也禁止在升级过程中触发真实 workflow 运行。第 5 步记录并等待真实环境验证升级完成后不执行推送或仅按约定推送翻译行为的最终验证交给下一次自然发生的中文 Issue、评论或 PR review comment——由 GitHub 托管的 Runner 在真实网络环境中验证。这是因为本地验证无法替代 GitHub Runner 的真实网络连通性与运行环境这一点在 v2.8.2 记录中针对 Google 网页翻译 batch RPC 的连通性亦有说明。升级脉络回顾从 v2.8.2 到 v2.9.2将本记录放入 Easydict 的升级时间线中可以更清楚地看到它的位置日期版本变更要点记录文件2026-09-04v2.8.2上游将失效的tomsun28/google-translate-api替换为固定版本google-translate-api-x10.7.3强制使用 Google 网页翻译 batch RPC并补充测试、重新生成distbundle2026-09-04-issue-translator-v2.8.2.md2026-09-04v2.8.3语言识别前忽略 Markdown 图片/链接中的 HTTP(S) URL避免中文评论被误判为英文本文关联文档2026-09-05v2.9.0配置中文优先双向翻译中文→英文、英文→简体中文日/韩文归入简体中文Bot 提示改为中性文案2026-09-05-issue-translator-v2.9.0.md2026-09-09v2.9.1核验上游 Release 为 stable 后仅更新uses:引用2026-09-09-issue-translator-v2.9.1.md2026-09-17v2.9.2固定引用已发布 tag不改触发条件与翻译配置当前仓库状态2026-09-17-issue-translator-v2.9.2.md可以看出Easydict 对 Issue 翻译工作流的维护遵循小步、固定、可审计的长期节奏上游每个 patch 版本发布后都经过 tag 核验、契约比对、静态检查三道关卡再以一行引用的最小 diff 落入仓库并留下对应的计划与 history 记录计划归档见 docs/exec-plans/completed/2026-09/ 目录。边界与注意事项适用前提上述升级流程适用于上游 Action 版本向后兼容的场景inputs 与运行时契约不变。若上游发生破坏性变更如输入项改名、Node 运行时升级、翻译后端更换则需要在第 2 步的契约核对中识别出来并同步调整with配置。本地验证的局限YAML 解析与 diff 检查只能保证配置静态正确无法验证真实翻译行为v2.8.2 记录明确指出本地网络无法代替 GitHub 托管 Runner 的真实 Google 连通性验证。因此真实环境验证依赖下一次自然触发的工作流运行。配置的当前形态截至本仓库当前状态工作流已演进至v2.9.2IS_MODIFY_TITLE: false、PRIMARY_LANGUAGE: zh-CN、SECONDARY_LANGUAGE: en、CUSTOM_BOT_NOTE的配置形态保持不变v2.8.3 修复的语言识别逻辑随后续版本继续生效。结语Easydict 的 Issue 翻译流水线是一个小依赖、大治理的典型样本一个看似只有一行的uses:引用背后是 tag 核验、契约比对、静态检查、范围审计与文档归档的完整闭环。v2.8.3 的升级更是演示了一个值得借鉴的工程细节——语言识别阶段应使用剥离 URL 等噪声后的轻量文本而翻译阶段应保留完整原文这一识别与翻译分离的思路对任何基于文本分类的自动化管线都有普遍参考价值。若你在自己的仓库中维护第三方 GitHub Actions本文的固定 tag 策略与验证清单可以直接复用。【免费下载链接】Easydict一个简洁优雅的词典翻译 macOS App。开箱即用支持离线 OCR 识别支持有道词典 苹果系统词典 苹果系统翻译OpenAIGeminiDeepLGoogleBing腾讯百度阿里小牛彩云和火山翻译。A concise and elegant Dictionary and Translator macOS App for looking up words and translating text.项目地址: https://gitcode.com/gh_mirrors/ea/Easydict创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考