【免费下载链接】co-op-translatorKeep Markdown, Jupyter notebooks, and image text translated as your repository changes.项目地址https://gitcode.com/gh_mirrors/co/co-op-translator点击查看免费下载Co-op Translator 是一款开源的文档自动翻译工具将它接入 GitHub Actions 后仓库中的 Markdown、Jupyter notebook 和图片文本一旦变更CI 就会自动重新翻译并直接创建一个翻译 PRPull Request无需任何人工操作。本文将带你用最简单的方式完成这套 CI 集成的完整配置新手照着做 10 分钟即可跑通。先看懂原理一张图理解文档自动翻译流程Co-op Translator 的翻译流程分为四步扫描变更 → 调用模型翻译 → 保护结构并改写链接 → 生成元数据并审查。源码哈希和语言级元数据能识别哪些文件已过期未变化的文件会被直接跳过避免重复消耗 Token。接入 GitHub Actions 后这个流程会完整地跑在 CI 里阶段在 CI 中做什么翻译检测变更的源文件只重新翻译过期内容审查用co-op-review做确定性检查结构、链接、新鲜度不调用模型开 PR翻译和审查都成功后才自动创建或更新 PR合并不会自动合并由人来审查措辞后手动合并最终你的 README 会像下面这样在仓库中维护一张多语言表格每行都是 CI 自动更新的准备工作先配好 2 项前置条件第 1 步为仓库添加翻译服务商 Secrets在目标仓库中打开Settings Secrets and variables Actions点击New repository secret添加你选用的模型服务商密钥文本翻译三选一即可按需添加服务商需要的 SecretsAzure OpenAIAZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_MODEL_NAME、AZURE_OPENAI_CHAT_DEPLOYMENT_NAME、AZURE_OPENAI_API_VERSIONOpenAIOPENAI_API_KEY、OPENAI_CHAT_MODEL_ID可选OPENAI_ORG_ID、OPENAI_BASE_URLAnthropicANTHROPIC_API_KEY、ANTHROPIC_MODEL可选ANTHROPIC_BASE_URL如果还要翻译图片里的文字额外需要 Azure AI Vision 的AZURE_AI_SERVICE_API_KEY和AZURE_AI_SERVICE_ENDPOINT。纯 Markdown 翻译则完全不需要 Vision 服务。详细配置说明见 docs/configuration.md 和 docs/azure-ai-setup.md。第 2 步开启工作流创建 PR 的权限打开Settings Actions General在 Workflow permissions 区域勾选Allow GitHub Actions to create and approve pull requests并保存最快上手5 步拿到你的第一个 README 翻译 PR官方提供了一份现成的工作流模板从根目录的README.md和单一目标语言开始最适合第一次尝试复制模板把 translate-readme.yml 复制到你仓库的.github/workflows/目录下并提交。模板通过根 action.yml 调用 Co-op Translator建议固定到一个已审查的 commit 以保证可复现。先预览进入Actions Translate README Run workflow选择语言如ko、ja、es保持勾选Preview only运行。预览不调用模型、不写文件、不建 PR只显示 Token 估算。补齐权限确认上一步的两个 Secrets 已添加、PR 创建权限已开启。正式运行取消勾选Preview only再运行。流程会依次执行预览 → 翻译 →co-op-review --readme-only审查 → 全部成功后创建或更新翻译 PR运行摘要里会直接附上 PR 链接。审查合并检查 PR 中的措辞和文件改动没问题再合并。PR 只包含translations/语言/README.md及其元数据文件源 README 保持不变。 组织策略如果限制了上述权限可以请管理员评估使用 GitHub App 方案详见官方文档 docs/github-actions.md 的 GitHub App Setup 章节。进阶配置让整仓 Markdown 自动翻译并开 PRREADME 跑通之后推荐切换为push 触发的标准工作流.github/workflows/co-op-translator.yml核心逻辑如下name: Co-op Translator on: push: branches: [main] jobs: co-op-translator: runs-on: ubuntu-latest env: TARGET_LANGUAGES: es fr de permissions: contents: write pull-requests: write steps: - uses: actions/checkoutv4 with: { fetch-depth: 0 } - uses: actions/setup-pythonv7 with: { python-version: 3.11 } - name: Install Co-op Translator run: | python -m pip install --upgrade pip pip install co-op-translator - name: Run Co-op Translator env: AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }} # ……其余密钥按所用服务商配置 run: translate -l $TARGET_LANGUAGES -md -y - name: Create Pull Request with translations uses: peter-evans/create-pull-requestv5 with: token: ${{ secrets.GITHUB_TOKEN }} branch: update-translations base: main add-paths: | translations/几个关键设计点paths:过滤大仓库建议在on.push下加paths:过滤器只在文档变更时触发节省 CI 分钟数失败即停翻译或审查任一步失败作业会在开 PR 之前中止不会产生半成品 PR笔记本与图片给翻译命令加-nbnotebook或-img图片文字需 Azure AI Vision并相应调整审查与add-paths参数CLI 参数-l指定语言、-md仅 Markdown、--readme-only只译 README完整参数见 docs/cli.md配置完成后每次 main 分支有文档变更Actions 都会跑完翻译与审查然后自动生成一个结构清晰的翻译 PR看看效果翻译结果长什么样下面是一个真实案例同一个 README 段落英文版与 Co-op Translator 自动生成的韩文版对照。链接、代码和 Markdown 结构都被完整保留翻译后的文档会原样保存在仓库的translations/语言/目录中可以像普通代码一样被审查、版本管理和持续更新实战避坑4 个让 CI 更稳的建议 控制单次翻译量GitHub 托管 Runner 有作业时长上限语言太多或仓库太大时可减少单次语言数、用-md/-nb/-img限定内容类型或换用 self-hosted runner。 审查措辞再合并工作流会整体重译变更过的源文件人工改过的译文可能被覆盖。合并前务必审查 diff如需在 Markdown 块级别保留人工编辑可使用 Python API 的 translation state provider见 docs/api.md。 把co-op-review用于 PR 校验它是确定性的审查命令不写文件、不调用模型适合在 PR 上验证生成结果- name: Review translated outputs run: co-op-review --changed-from origin/${{ github.base_ref }} --format github 组织级场景用 GitHub App如果组织要求 App 身份、或需要生成的 PR 自动触发下游 CI可按官方文档配置 GitHub App用 App Token 替代GITHUB_TOKEN创建 PR。更多排障思路如没有生成 PR、Token 估算异常可参考 docs/troubleshooting.md。常见问题 FAQQ1为什么运行了却没有新 PR翻译或审查任一步失败时不会创建 PR源文件没有实际变化时同样不会开新 PR。查看 Workflow Summary 和失败步骤的日志即可定位。Q2PR 会自动合并吗不会。无论哪种工作流合并都由人来执行确保机翻措辞经过人工把关。Q3第一次运行一定要配置 Azure 吗不一定。Azure OpenAI、OpenAI、Anthropic 三选一即可翻译文本只有翻译图片里的文字才需要 Azure AI Vision。Q4除了 GitHub Actions 还有哪些用法Co-op Translator 提供 CLI、Python API、MCP Server、容器等多种接入方式选择建议见 docs/workflows.md容器快速运行方式见 Dockerfile。小结与延伸资源到这里你的仓库已经具备了文档变更 → 自动翻译 → 自动审查 → 自动开 PR的完整闭环。核心要点回顾前置只需 2 项模型服务商 Secrets 允许 Actions 创建 PR 的权限先跑 README 模板再升级到整仓 push 工作流失败即停、永不自动合并安全性由工作流本身保证资源路径GitHub Actions 官方指南docs/github-actions.md仓库级根 Action 定义action.ymlREADME 翻译工作流模板docs/assets/workflows/translate-readme.yml配置与密钥说明docs/configuration.md确定性审查实现src/co_op_translator/review/把多语言文档交给 CI把审查留给团队——这就是 Co-op Translator 的协作翻译之道。✨赞分享【免费下载链接】co-op-translatorKeep Markdown, Jupyter notebooks, and image text translated as your repository changes.项目地址https://gitcode.com/gh_mirrors/co/co-op-translator点击查看免费下载相关推荐co-op-translator自动化的多语言文档翻译工具co op translator自动化的多语言文档翻译工具 项目介绍 在当今全球化的技术环境中语言障碍常常成为国际合作和知识共享的障碍。为了解决这一问题如何快速上手GenerambaiOS项目代码生成完整指南如何快速上手GenerambaiOS项目代码生成完整指南 Generamba是一款专为Xcode设计的强大代码生成工具能够显著提升iOS/macOS开发效率终极MP4视频修复指南如何用Untrunc快速拯救损坏的珍贵回忆终极MP4视频修复指南如何用Untrunc快速拯救损坏的珍贵回忆 你是否经历过这样的绝望时刻孩子第一次走路的视频、婚礼现场的珍贵录像、重要会议的记录文件突视频处理上一篇零代码扩展云应用AWS Amplify JS第三方API集成实战指南下一篇探索vscode-gitlens代码透镜GitCodeLensProvider工作原理解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/6 1:21:34 · 阅读 1.2k 用GitHub Actions让文档自动翻译并开PR：Co-op Translator CI集成完整指南
【免费下载链接】co-op-translatorKeep Markdown, Jupyter notebooks, and image text translated as your repository changes.项目地址https://gitcode.com/gh_mirrors/co/co-op-translator点击查看免费下载Co-op Translator 是一款开源的文档自动翻译工具将它接入 GitHub Actions 后仓库中的 Markdown、Jupyter notebook 和图片文本一旦变更CI 就会自动重新翻译并直接创建一个翻译 PRPull Request无需任何人工操作。本文将带你用最简单的方式完成这套 CI 集成的完整配置新手照着做 10 分钟即可跑通。先看懂原理一张图理解文档自动翻译流程Co-op Translator 的翻译流程分为四步扫描变更 → 调用模型翻译 → 保护结构并改写链接 → 生成元数据并审查。源码哈希和语言级元数据能识别哪些文件已过期未变化的文件会被直接跳过避免重复消耗 Token。接入 GitHub Actions 后这个流程会完整地跑在 CI 里阶段在 CI 中做什么翻译检测变更的源文件只重新翻译过期内容审查用co-op-review做确定性检查结构、链接、新鲜度不调用模型开 PR翻译和审查都成功后才自动创建或更新 PR合并不会自动合并由人来审查措辞后手动合并最终你的 README 会像下面这样在仓库中维护一张多语言表格每行都是 CI 自动更新的准备工作先配好 2 项前置条件第 1 步为仓库添加翻译服务商 Secrets在目标仓库中打开Settings Secrets and variables Actions点击New repository secret添加你选用的模型服务商密钥文本翻译三选一即可按需添加服务商需要的 SecretsAzure OpenAIAZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_MODEL_NAME、AZURE_OPENAI_CHAT_DEPLOYMENT_NAME、AZURE_OPENAI_API_VERSIONOpenAIOPENAI_API_KEY、OPENAI_CHAT_MODEL_ID可选OPENAI_ORG_ID、OPENAI_BASE_URLAnthropicANTHROPIC_API_KEY、ANTHROPIC_MODEL可选ANTHROPIC_BASE_URL如果还要翻译图片里的文字额外需要 Azure AI Vision 的AZURE_AI_SERVICE_API_KEY和AZURE_AI_SERVICE_ENDPOINT。纯 Markdown 翻译则完全不需要 Vision 服务。详细配置说明见 docs/configuration.md 和 docs/azure-ai-setup.md。第 2 步开启工作流创建 PR 的权限打开Settings Actions General在 Workflow permissions 区域勾选Allow GitHub Actions to create and approve pull requests并保存最快上手5 步拿到你的第一个 README 翻译 PR官方提供了一份现成的工作流模板从根目录的README.md和单一目标语言开始最适合第一次尝试复制模板把 translate-readme.yml 复制到你仓库的.github/workflows/目录下并提交。模板通过根 action.yml 调用 Co-op Translator建议固定到一个已审查的 commit 以保证可复现。先预览进入Actions Translate README Run workflow选择语言如ko、ja、es保持勾选Preview only运行。预览不调用模型、不写文件、不建 PR只显示 Token 估算。补齐权限确认上一步的两个 Secrets 已添加、PR 创建权限已开启。正式运行取消勾选Preview only再运行。流程会依次执行预览 → 翻译 →co-op-review --readme-only审查 → 全部成功后创建或更新翻译 PR运行摘要里会直接附上 PR 链接。审查合并检查 PR 中的措辞和文件改动没问题再合并。PR 只包含translations/语言/README.md及其元数据文件源 README 保持不变。 组织策略如果限制了上述权限可以请管理员评估使用 GitHub App 方案详见官方文档 docs/github-actions.md 的 GitHub App Setup 章节。进阶配置让整仓 Markdown 自动翻译并开 PRREADME 跑通之后推荐切换为push 触发的标准工作流.github/workflows/co-op-translator.yml核心逻辑如下name: Co-op Translator on: push: branches: [main] jobs: co-op-translator: runs-on: ubuntu-latest env: TARGET_LANGUAGES: es fr de permissions: contents: write pull-requests: write steps: - uses: actions/checkoutv4 with: { fetch-depth: 0 } - uses: actions/setup-pythonv7 with: { python-version: 3.11 } - name: Install Co-op Translator run: | python -m pip install --upgrade pip pip install co-op-translator - name: Run Co-op Translator env: AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }} # ……其余密钥按所用服务商配置 run: translate -l $TARGET_LANGUAGES -md -y - name: Create Pull Request with translations uses: peter-evans/create-pull-requestv5 with: token: ${{ secrets.GITHUB_TOKEN }} branch: update-translations base: main add-paths: | translations/几个关键设计点paths:过滤大仓库建议在on.push下加paths:过滤器只在文档变更时触发节省 CI 分钟数失败即停翻译或审查任一步失败作业会在开 PR 之前中止不会产生半成品 PR笔记本与图片给翻译命令加-nbnotebook或-img图片文字需 Azure AI Vision并相应调整审查与add-paths参数CLI 参数-l指定语言、-md仅 Markdown、--readme-only只译 README完整参数见 docs/cli.md配置完成后每次 main 分支有文档变更Actions 都会跑完翻译与审查然后自动生成一个结构清晰的翻译 PR看看效果翻译结果长什么样下面是一个真实案例同一个 README 段落英文版与 Co-op Translator 自动生成的韩文版对照。链接、代码和 Markdown 结构都被完整保留翻译后的文档会原样保存在仓库的translations/语言/目录中可以像普通代码一样被审查、版本管理和持续更新实战避坑4 个让 CI 更稳的建议 控制单次翻译量GitHub 托管 Runner 有作业时长上限语言太多或仓库太大时可减少单次语言数、用-md/-nb/-img限定内容类型或换用 self-hosted runner。 审查措辞再合并工作流会整体重译变更过的源文件人工改过的译文可能被覆盖。合并前务必审查 diff如需在 Markdown 块级别保留人工编辑可使用 Python API 的 translation state provider见 docs/api.md。 把co-op-review用于 PR 校验它是确定性的审查命令不写文件、不调用模型适合在 PR 上验证生成结果- name: Review translated outputs run: co-op-review --changed-from origin/${{ github.base_ref }} --format github 组织级场景用 GitHub App如果组织要求 App 身份、或需要生成的 PR 自动触发下游 CI可按官方文档配置 GitHub App用 App Token 替代GITHUB_TOKEN创建 PR。更多排障思路如没有生成 PR、Token 估算异常可参考 docs/troubleshooting.md。常见问题 FAQQ1为什么运行了却没有新 PR翻译或审查任一步失败时不会创建 PR源文件没有实际变化时同样不会开新 PR。查看 Workflow Summary 和失败步骤的日志即可定位。Q2PR 会自动合并吗不会。无论哪种工作流合并都由人来执行确保机翻措辞经过人工把关。Q3第一次运行一定要配置 Azure 吗不一定。Azure OpenAI、OpenAI、Anthropic 三选一即可翻译文本只有翻译图片里的文字才需要 Azure AI Vision。Q4除了 GitHub Actions 还有哪些用法Co-op Translator 提供 CLI、Python API、MCP Server、容器等多种接入方式选择建议见 docs/workflows.md容器快速运行方式见 Dockerfile。小结与延伸资源到这里你的仓库已经具备了文档变更 → 自动翻译 → 自动审查 → 自动开 PR的完整闭环。核心要点回顾前置只需 2 项模型服务商 Secrets 允许 Actions 创建 PR 的权限先跑 README 模板再升级到整仓 push 工作流失败即停、永不自动合并安全性由工作流本身保证资源路径GitHub Actions 官方指南docs/github-actions.md仓库级根 Action 定义action.ymlREADME 翻译工作流模板docs/assets/workflows/translate-readme.yml配置与密钥说明docs/configuration.md确定性审查实现src/co_op_translator/review/把多语言文档交给 CI把审查留给团队——这就是 Co-op Translator 的协作翻译之道。✨赞分享【免费下载链接】co-op-translatorKeep Markdown, Jupyter notebooks, and image text translated as your repository changes.项目地址https://gitcode.com/gh_mirrors/co/co-op-translator点击查看免费下载相关推荐co-op-translator自动化的多语言文档翻译工具co op translator自动化的多语言文档翻译工具 项目介绍 在当今全球化的技术环境中语言障碍常常成为国际合作和知识共享的障碍。为了解决这一问题如何快速上手GenerambaiOS项目代码生成完整指南如何快速上手GenerambaiOS项目代码生成完整指南 Generamba是一款专为Xcode设计的强大代码生成工具能够显著提升iOS/macOS开发效率终极MP4视频修复指南如何用Untrunc快速拯救损坏的珍贵回忆终极MP4视频修复指南如何用Untrunc快速拯救损坏的珍贵回忆 你是否经历过这样的绝望时刻孩子第一次走路的视频、婚礼现场的珍贵录像、重要会议的记录文件突视频处理上一篇零代码扩展云应用AWS Amplify JS第三方API集成实战指南下一篇探索vscode-gitlens代码透镜GitCodeLensProvider工作原理解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考