翻译恢复

Glossia 会在发布前验证翻译内容。恢复保留了该要求：重试必须仍然保留源结构及必需的占位符，且每个生成的文件均通过其配置的验证命令。

Markdown 翻译

Glossia 从不重新渲染翻译后的 Markdown 文档。它仅解析源内容以提取正文：段落、标题、列表项、表格单元格、组件和 HTML 的面向用户属性（title, details, alt, label, description, summary, placeholder, aria-label, caption），以及 HTML <summary> 的文本。每个翻译都被写回原文所占用的确切字节，因此代码、链接目标、组件、GitHub 警报、显式标题锚点（如 {#install}）、列表标记和空行都会保持逐字节相同。

每个段落或标题都将作为完整句子进行翻译。内联格式化为编号标签：<gN>...</gN> 包裹链接或强调的单词，<gN/> 用于必须保持不变的内容（如内联代码或组件）。模型可以将标签移至符合目标语言词序的位置，但必须保持每个标签恰好一次。每个请求还会携带周围的源文档，以及来自同一文件的最新翻译供参考。

如果一个单元丢失或虚构了标签，它将会带因由单独重试，最多三次。经过验证的单元会被保留。拼接后，Glossia 解析结果并比较其结构与源。如果一个翻译元素会变成标题、列表或强调，其正文会被转义，不需要进一步的模型调用。

目录翻译

Gettext 目录在翻译之前会被解析为字符串。请求携带最多八个字符串，以 8,000 字节的批处理为目标。单个更大的字符串保持不变。模型返回一个包含相同数量字符串且顺序相同的数组。Glossia 检查插值变量并拒绝空的翻译。

标题在代码中使用目标区域的多重格规则构建。源消息标识符、注释和目录结构来自解析后的源。如果一个批次返回了格式错误的容，Glossia 会重试一次，然后将其拆分为更小的批次。成功的相邻批次无需再次翻译。

提供者限流

Glossia 协调使用相同凭证和模型的翻译请求。限流响应会延长它们的共享冷却时间，并增加新请求之间的间隔。若一分钟无调用，成功流量会逐渐缩短间隔。已在运行的请求允许完成。

提供者重试提示是最小延迟。重复的失败也会增加退避时间，即 30 秒基础延迟加上抖动；较长的提供者提示具有优先权，上限为五分钟。Together 的 x-ratelimit-reset 头部与 retry-after 一同被识别。

在八次未成功的请求尝试后，存储库运行将停止创建新文件。延迟的延续继承翻译分支并恢复未完成的工作。之前的尝试在会话历史中保持可见，通过该延续链接。延迟从一分钟增加到五分钟，最多六次自动延续。更新的活跃会话享有优先权，撤销的会话永远不会恢复。仅验证失败不会调度提供者恢复。

引擎发布后的恢复

版本：Enterprise。 本节介绍的 Kubernetes 发布检查和引擎发布后的恢复需要隔离的翻译运行器。本页其他部分介绍的 Markdown、目录和提供者恢复以及持久化进度，在 Community 中仍然可用。

会话有两个独立版本：正在翻译的存储库提交和正在执行该提交的翻译引擎镜像。在 Kubernetes 中，每个作业固定了调度它的 Web 副本的确切镜像摘要。作业能够承受 Web 发布的影响，且从未在翻译中途切换代码。因此，在发布前刚刚调度的作业即使在 Web 应用程序更新后也可以在旧引擎上完成。会话详情显示引擎摘要；没有此来源记录的旧会话显示“未记录。”

每隔五分钟，Glossia 检查其部署是否已完全发布。只有来自该健康版本的作业才能调度引擎恢复。如果项目的最新会话在该发布完成之前被排队，在较旧的已记录引擎摘要上运行，并在随后六小时内失败，Glossia 可以在当前版本上创建延续。使用时间也覆盖了等待容量并在发布后才启动的作业。不同的镜像摘要本身不会触发无关部署后普通失败的重试。已完成文件和开放的翻译拉取请求会延续；只有未完成的工作才会再次翻译。排队的发布延续在发布进行中时等待，最多等待 15 分钟。Kubernetes API 或权限失败会以明确的错误停止启动，而不是被误认为是持续进行的发布。

恢复是有机的：会话必须以记录的项验证失败结束，其最新尝试中的每个失败项必须报告 Markdown 结构、保留内容或 Markdown 单元失败。中断或部分取消的尝试不符合条件。提供者错误、用完的凭据、被拒绝的凭证、发布失败、源读取错误、外部验证命令失败和未知原因不会由部署重试。成功、活跃、已取消、被替代和无版本会话也被保留。即使用户取消了它，更新的会话也总是胜出。

会话在另一种引擎版本上最多获得一次延续，谱系中最多有三个发布延续。如果新引擎仍然失败，则不会在该同一镜像上再次重试，即使是在回滚之后。谱系保留了其之前尝试过的引擎摘要，启动器在创建排队作业之前会再次检查它们。现有的提供者恢复限制在发布延续中得以保留。可变镜像标签和未配置发布身份的部署不会启用自动引擎恢复。

持久化进度

已完成文件及其锁文件以批次形式发布到翻译分支：每 25 个文件或每 15 分钟进行一次提交，运行结束时进行最后一次提交。每次推送都会运行仓库的拉取请求检查，因此批量处理防止了大型运行针对每个文件启动单独的检查运行。一个项目仅有一个翻译拉取请求：默认分支上的新提交延续当前开放的请求，并且仅翻译自变更以来的内容。一旦该拉取请求被合并或关闭，下一次运行将启动一个新的。未完成的文件内部，本地验证的片段和恢复批次也会保存到数据库中长达七天。这些检查点可以在工作进程停止后存活。它们的范围限于账户、项目、文档输入、有效凭据和模型、上下文，以及片段或修复尝试。

恢复的运行仅当输入仍然匹配时才能重用片段。它总是再次验证最终组装的文档。被拒绝的模型响应并非检查点。文档级别的验证失败会启动单独的修复尝试，因为验证器可能无法识别单一的负责片段。

已过期的检查点和非活跃的提供者配速记录将通过排程的会话恢复作业移除。这些是操作记录；用户不需要将它们添加到他们的仓库或在L10N.md中配置它们。