翻译质量与 SEO
这是核查该说法的页面。它涵盖 Docsbook 实际衡量翻译的哪些方面、如何修正翻译、搜索引擎和 AI 助手如何处理翻译后的文档,以及——最后——机器翻译在技术文体中仍会出错的地方,并附有来源。
Docsbook 衡量什么,以及它不衡量什么#
Docsbook 不发布翻译质量分数。 您的页面不会有 BLEU、COMET、TER 或人工评分数据,本说明文档也不会虚构这些数据。产品实际衡量的是覆盖率和时效性:某个页面是否存在于某种语言版本中,以及该页面是否基于当前线上版本的源内容制作。
这比“我们的翻译很好”这一说法更为有限,但也是可以核查的说法。
覆盖范围和新鲜度#
每个已存储的翻译都会保留其所依据的源文件的 git blob SHA。覆盖范围通过读取 HEAD 中的仓库树并按路径进行比较来计算:
| 状态 | 含义 | 读者为此付出的代价 |
|---|---|---|
current |
根据 HEAD 中文件的 SHA 翻译 | 没有 |
behind |
根据页面的旧版本翻译 | 页面会告诉他们一些文档已不再说明的内容 |
missing |
在仓库中从未翻译成此语言 | 他们会回退到原始语言 |
manual |
手写或上传的内容——新鲜度由作者决定 | 没有;永远不会被计为落后 |
orphaned |
已翻译页面的源文件在 HEAD 中已不存在 | 这是一个对应于已删除内容的页面 |
覆盖范围为 (current + manual) / total。当 behind 和 missing 均为零时,某种语言处于同步状态。当无法读取仓库时,覆盖范围为 null——绝不会是一个确定的零值——因此,受到速率限制的 GitHub 读取永远不会将健康的语言标记为红色。
查看方式#
- 在面板中。 每种语言都有自己的页面:一个按差距的类型划分的条形图及其覆盖率百分比、你的文档当前所在的提交、一个显示是谁启动了正在运行的翻译流程的实时进度条、按每次运行的结束方式着色的最近十几次运行记录,以及——当某次运行提前停止时——用文字说明的原因。在此下方,是按最新优先排列的提交,每个提交都会显示其页面在该语言中的状态结论,因此“定价页面的重写于周二上线了”是可以直接核实的事项,而不是需要你自行推断的文件名。
- 通过 MCP。
get_translation_status会为每种语言准确返回以下内容:current/behind/missing/manual/orphaned、百分比、in_sync、当前是否有运行正在进行及其进度,以及上次运行的结果——包括启动它的代理运行。该工具自身的描述会提示调用方在run_translation_pass之前读取它,因为对于已经与源内容持平的语言再次进行翻译既要花钱,也不会带来任何变化。 - 通过 Webhook。
translation.needed会在启用语言中的页面即将开始翻译时触发,translation.completed会在翻译持久化完成时触发,而translation.outdated会在某个翻译落后于其源内容时触发。translation.completed仅在页面确实已被持久化时触发,因此负责重新索引 CMS 的监听器永远不会收到不存在的翻译通知。
唯一一个用于比较而非衡量的数字#
Translations 仪表板上的节省金额,是以人工翻译者按每 1,000 个字符 5.00 美元的费率翻译相同字符时收取的费用,减去 AI 翻译实际向您收取的费用。关于这一数字,有两点需要注意:
- 它是按字符而非按单词计价的,这是经过刻意设计的。单词数取决于目标语言的特性——中文和日文没有以空格分隔的单词,因此按单词计算的指标对于恰恰应该衡量的语言会显示为接近零。
- 它是一个反事实数字,而不是发票金额。这两笔金额都没有实际支付。该费率是 Docsbook 中的固定常数,并不是您收到的报价。请将该数字理解为数量级。
我可以更正翻译吗?更正会保留吗?#
您可以更正翻译,而且更正内容不会被后续处理覆盖——这一点在数据库写入本身中得到了强制保证。但之后读者是否会看到您更正后的文本,则是另一个问题,诚实的答案如下。
如何进行更正。 在“翻译”面板中编辑翻译,或通过 upload_translation 发送翻译。上传的内容会以草稿状态到达;list_pending_translations 会显示草稿,approve_translation 会发布其中一项。编辑翻译内容会将该行标记为手动上传。
为什么更正会在后续处理中保留。 自动处理会通过数据库 upsert 写入,而其冲突子句只会覆盖来源为 docsbook_ai 的行。标记为手动上传的行会被该写入跳过,覆盖率会将其计为 manual——这是一种永远不会“落后”的状态,因为人工编写页面的新鲜度取决于编写者本人,而不是哈希比较。以这种方式替换实时 AI 翻译时,还会向调用方返回 replaced_ai_translation: true,因此代理可以提醒人工操作员:它刚刚替换了读者已经看到的内容。
存在疑问。 Docsbook 的文档曾表示,一旦您上传更正内容,“Docsbook 从那时起就会提供您的版本”。 可以验证的是:更正后的行会被存储,不会被后续自动处理覆盖(upsert 的冲突子句只会覆盖来源为
docsbook_ai的行),并且在覆盖率中会被计为manual,而不是过时。 无法验证的是:读者确实会看到该内容。根据当前代码,有三点指向相反的结论。面向读者的页面会从热缓存中读取翻译;缓存未命中时,则从筛选为origin = 'docsbook_ai'的存储行中读取。相同的筛选条件还会决定某个语言环境是否属于此页面的hreflang集群,以及其 URL 是否会进入站点地图。而缓存失效路径明确指出,手动行和外部行“永远不会写入 SSR Redis 页面键”,因此首次读取时也没有缓存副本可供查找。手动上传或手工编辑的行与这些条件都不匹配。我们尚未发布任何关于读者实际看到更正页面的测量结果,而按当前机制也无法推断会看到这种结果——因此,应将手动上传视为一种保护页面免遭重新翻译并驱动外部流程的方式,而不是改变读者所见内容的方式。如果您今天发现某个具体句子有误,可靠的解决方法是修改源页面,然后让处理流程重新翻译它。
这正是我们的证据规则要求我们标记、而不是悄悄删除的那类声明。
搜索引擎如何处理翻译后的文档#
每种语言使用独立 URL,以及每页一个 hreflang 集群#
每种语言都有自己的 URL 路径——绝不是子域名,也绝不是查询参数。此外,每个文档页面都会输出一个 hreflang 集合,其中包含作为 <link rel="alternate"> 的替代项,以及指向原始语言 URL 的 x-default 和 en。
使其生效的规则是互惠性,并且它是按页面而非按网站强制执行的:
| 规则 | 原因 | 检查位置 |
|---|---|---|
| 只有当此页面确实已翻译成某种语言时,该语言区域才会出现在此页面的集群中 | 未翻译的 /fr/… URL 会渲染原始内容,并将原始页面声明为其规范页面。将其列为替代项会发布一个与自身规范页面相矛盾的集群成员,而整个集群——包括那些确实已翻译的语言区域——都会被丢弃 |
任意已翻译页面的 <head> |
| 未翻译语言区域的 URL 将规范指向原始语言页面 | 它是与原始页面相互竞争的近重复页面,而不是一个独立页面 | 任何法语尚未覆盖的页面对应的 /fr/… URL |
/en/… 将规范页面指向无前缀 URL |
英语在两者上提供的字节内容完全相同;这对 URL 会合并为一个可建立索引的页面,而不是两个相互重复且各自指向自身的规范页面 | 任何 /en/… URL |
noindex 页面会从集群中完全移除,而不仅仅是不出现在其他页面中 |
搜索引擎会抓取每个替代项以验证互惠性——这正是将 noindex 页面从索引中移除以停止消耗的抓取预算 |
前置元数据中包含 noindex: true 的页面 |
站点地图完全不会输出 hreflang 替代项 |
站点地图级别和页面级别的 hreflang 会合并为一个集群,并且必须保持一致。站点地图无法经济地检查每个页面的翻译状态,因此它输出的任何内容都会列出每个已启用的语言区域——从而重新引入那个会使集群失效的确切成员 |
sitemap.xml |
Docsbook 使用与 URL 路由相同的函数生成规范页面和替代项,因此它发布的地址一定是返回 200 而不是执行重定向的地址——指向重定向的规范 URL 会被 Google 处理为丢弃该页面。
同一规则下还有一个机制。Google 明确表示,它“使用页面的可见内容来确定页面语言”,并且“我们不会使用任何代码级语言信息,例如 lang 属性或 URL”——因此,一个完全翻译的页面如果仍然提供英文 <title>,就会将其最强的页面内信号发送为错误的语言。Docsbook 会从已经存储的翻译 HTML 中恢复标题,读取该页面自身已翻译的 <h1>,无需额外的模型调用。在这种情况下,元描述会有意保留原文:为其臆造翻译不是元数据构建过程可以执行的操作,而正确的标题配合原语言描述,也胜过两者都错误。
为什么这些规则各自都是正确的#
| 规则 | 为什么它适用于使用它的机器 | 来源 |
|---|---|---|
为每种语言发布独立的 URL,并使用 hreflang 标注这一组 URL |
Google 的指示是:“使用 hreflang 告知 Google 内容的不同变体” | Google 搜索中心:本地化版本 |
| 确保每个集群都相互返回链接,并且绝不要列出此页面未翻译成的语言区域 | “每个语言版本都必须列出自身以及所有其他语言版本。”Google 将这一失败列为常见 hreflang 错误中的第一项,归在缺少返回链接之下:“如果页面 X 链接到页面 Y,页面 Y 必须链接回页面 X。如果所有使用 hreflang 注释的页面都不是这种情况,则这些注释可能会被忽略或无法正确解读” |
Google 搜索中心:本地化版本 |
| 将未翻译的语言区域 URL 规范化到原始页面 | Google 的原文表述很明确:“只有当页面的主要内容保持未翻译时,页面的本地化版本才会被视为重复内容。”根据定义,提供英文正文的 /fr/ URL 就属于这种情况 |
Google 搜索中心:本地化版本 |
| 让已翻译的页面使用自身的规范 URL,绝不要将其规范化到原始页面 | Google 的规范化指南要求“确保以相同语言指定规范页面”,并指出携带 hreflang 的 rel="canonical" 注释“不会用于规范化” |
Google 搜索中心:规范化 |
| 翻译正文,而不仅仅是导航和页脚 | “Google 使用页面的可见内容来确定其语言。”以及“我们不使用任何代码层面的语言信息,例如 lang 属性或 URL。”正文未翻译的语言区域 URL,无论其声明了什么,都不是该语言的页面 | Google 搜索中心:管理多区域网站 |
| 将语言区域放在路径段中 | 子目录是 Google 记录的三种 URL 结构之一,另外两种是 ccTLD 和子域名。其列出的缺点是人为因素:“用户可能无法仅从 URL 识别地理定位” | Google 搜索中心:管理多区域网站 |
| 使用不带扩展的两字母语言代码 | 对于 hreflang,Google 要求使用 ISO 639-1 语言代码和 ISO 3166-1 Alpha 2 区域代码,并拒绝其他任何形式:“不在这些标准中列出的其他代码(例如 es-419)不受支持”。BCP 47 对形式的要求也一致——其自身指南指出,子标签“仅应在能够提供有用的区分信息时使用”,W3C 将其重述为:“黄金法则是让语言标签尽可能简短” |
Google · RFC 5646 (BCP 47) · W3C |
| 绝不要自动将读者重定向到某种语言 | “避免将用户从网站的一个语言版本自动重定向到另一个语言版本”——“这些重定向可能会阻止用户(以及搜索引擎)查看所有版本” | Google 搜索中心:管理多区域网站 |
请注意倒数第二行对有效标签的含义:es-419 是完全合法的 BCP 47 标签——W3C 将其作为示例进行讲解——而 Google 明确不接受它用于 hreflang。有效的语言标签与有效的 hreflang 值并不是同一个集合。
机器翻译是否违反 Google 的规则?#
不违反——而且答案比通常争论中的任何一方所说的都更具体,因此值得准确理解。
翻译后的页面不是重复内容。Google 用一句话明确了界限:“只有当页面的主要内容仍未翻译时,页面的本地化版本才会被视为重复内容。”完全翻译的页面是一个独立页面。提供原始正文的本地化 URL 才是重复页面——这也是 Docsbook 会将这种情况规范到原始页面,而不是将其作为备用版本发布的原因。至于重复内容这一问题,Google 长期以来的立场是:“除非重复内容的意图似乎是欺骗用户并操纵搜索引擎结果,否则网站上的重复内容不会成为对该网站采取措施的理由”(揭开重复内容处罚的真相,2008 年)。
过去“机器翻译属于垃圾内容”的规则已经不复存在。Google 的垃圾内容政策中完全没有关于机器翻译的条目——页面中没有出现“machine translation”和“automatically translated”这两个字符串。现有的是规模化内容滥用,其定义是“创建大量对用户几乎没有或完全没有价值的非原创内容,无论其创建方式如何”。翻译一词仅在该政策关于抓取的一个示例中出现:“抓取信息流、搜索结果或其他内容来生成大量页面(包括通过同义词替换、翻译或其他混淆技术等自动转换方式),而这些页面几乎没有为用户提供价值”。Google 的更新日志记录了 2025 年 6 月 11 日的清理工作:“从我们的多语言文档中移除了关于使用 robots.txt 屏蔽所有自动翻译页面的章节”,“以配合我们在 2024 年 3 月对垃圾内容政策所做的更新”(Search Central 文档更新)。
当前的立场取决于质量,而不是取决于方法。当被直接问及自动翻译是否会损害排名时,Gary Illyes 回答说,“如果自动翻译的质量很低,也许会”,并建议网站“确保由精通这些语言的母语人士审阅(并酌情修正)翻译内容”。在同一场会议中,John Mueller 指出,没有“可以添加到页面中、用于声明翻译由机器生成的特殊标记”;评判标准是“页面是否翻译得很好”;“良好的本地化远不只是翻译单词和句子”;而且低质量输出属于“可以直接在这些页面上添加 noindex robots 元标签”的情况(Google SEO 办公时间,2024 年 6 月)。
对文档团队而言,实际可以这样理解:
- 受到惩罚的是没有价值的数量,而不是工具本身。翻译读者确实需要的一百个文档页面,并不属于规模化内容滥用;生成没人要求的本地化页面才是。
- Google 明确指出的变量是审阅。Docsbook 为你提供了相应的功能界面——按语言显示覆盖范围的页面、包含
approve_translation的list_pending_translations,以及可在发布前将每个页面通过你自己的处理流程的external模式——但不会强迫你使用它们。auto模式会边处理边发布。请做出明智的选择。 - 最具成本效益的审阅方式不是审阅每个页面,而是审阅那些直接影响收益的页面:快速入门、任何与定价相关的内容、该语言在分析数据中访问量最高的页面,以及任何会因错误翻译指令而导致读者无法完成设置的内容。如果某种语言的内容读起来很糟,而你又不打算修正,那么
noindex就是一种获得认可的解决方案。
AI 助手如何使用它们#
没有什么特别之处,而这正是关键所在。生成式引擎检索的是与爬虫读取的相同静态 HTML。启用一种语言后,系统会为助手创建该语言的页面,以便在用户使用该语言提问时进行检索和引用——而仅包含原始语言的语料库无法做到这一点。Docsbook 还会根据语言代码为站内全文搜索建立翻译文本的索引,因此使用德语搜索的读者匹配到的是德语页面,而不是英文源页面。有关页面本身新增的内容,请参阅 GEO。
局限性——机器翻译在技术文档中仍然会出错的地方#
请像认真对待页面其余部分一样认真对待本节内容。
-
术语一致性没有得到管理,这是整个领域经过测量的薄弱环节。 Docsbook 没有术语表、术语库,也没有可供你提供的禁止翻译列表。一致性来自三个较弱的来源:请求以温度 0 运行,未经编辑的部分会从缓存中原样提供,因此不会发生漂移;导航标签以及标题/描述则作为集合进行翻译。使用相同术语的两个不同页面是独立翻译的,因此可能会出现不一致。
这有多大影响已经得到测量。Moslem 等人(《将领域术语整合到机器翻译中:利用大型语言模型》,WMT 2023,arXiv:2310.14451)报告称,在 DE-EN、EN-CS 和 ZH-EN 的盲测集上,“纳入盲测数据集译文的术语数量,从通用模型的平均 36.67% 增加到流程结束时的平均 72.88%”——“在三个语言对中,术语的成功使用率几乎翻了一番”。请准确理解这一指标:它统计的是所需术语是否被使用,而 72.88% 是一个专门为此构建的四步流程的最终结果,并不是单靠更强的模型得出的。
WMT25 术语共享任务则从同一问题的另一面给出了具体数字。其 Track 1 数据由 SAP 从其在线帮助门户生成(EN→DE/RU/ES,每个语言对有 500 个测试实例,来自 13 个团队的 20 个系统),并且“强大的系统能够实现超过 97% 的极高术语准确率”——但前提是系统在推理时获得正确的术语表,而这正是 Docsbook 所没有的输入。该任务还使用随机词典和不提供词典的方式运行相同系统:其顶级系统使用正确术语表时得分为99.1,使用随机术语表时为 49.2,不使用术语表时为 44.4。对于较长文本,报告指出“系统经常表现不佳”,并且“文档赛道仍然是一项更具挑战性的任务”。这应当理解为:术语保真度是通过工程手段实现的,而不是自然而然继承的;Docsbook 尚未通过工程手段实现这一点。
总体框架也是如此。WMT24 通用翻译任务(Kocmi 等人)在 11 个语言对上收集了来自“8 个不同的大型语言模型(LLM)和 4 家在线翻译服务商”的译文,其标题为《LLM 时代已经到来,但机器翻译尚未解决》。其领域包括新闻、文学、语音和社交媒体,而不是技术文档——因此,引用它只能说明“尚未解决”,涉及领域文本的任何内容则应引用上面提到的两项研究。其测试套件确实报告了术语方面的弱点,但范围很窄:这句话讨论的是一个方向和一个系统,即“对于英语-俄语,Yandex 在专名和术语方面较弱”,并不是关于 LLM 翻译整体的结论。
-
普通文本中的裸标识符仅受到一条指令的保护。 围栏代码块和反引号中的代码会从请求中移除,并逐字节恢复——这是机械式的。以普通文本书写且没有反引号的参数名称会传递给模型,并且只有因为提示词如此要求,才会保持源语言不变。将标识符标记为代码,是你能为自己的翻译所做的价值最高的事情。我们查找了关于 LLM 翻译具体有多频繁地破坏代码标识符的已发表测量结果,但没有找到;最接近的已发表证据就是上面引用的术语研究。应将这一风险的规模视为尚未测量,而不是视为很小。
-
图像
alt文本不会被翻译。它是一个 HTML 属性,而保护href和id的规则也会保护alt。 -
Docsbook 没有发布过自身的测量结果。没有准确率数据,没有错误率,也没有按语言划分的排名。如果你需要针对自己的语料库获得这些数据,诚实的做法是请一位流利使用目标语言的读者审阅你自己页面中的样本——而覆盖率会告诉你哪些页面值得抽样。
-
模型可能会在你不知情的情况下发生变化。默认翻译模型是一个配置常量,模型选择器允许你更改它。上个月翻译的页面使用的是当时选定的模型;模型改进后,不会有任何机制重新翻译页面。
-
不会对地区变体进行建模。巴西和葡萄牙共用一个
pt,简体和繁体共用一个zh。对于这种区别会影响产品销量的产品而言,这是真实的局限,而不是可以忽略不计的误差。
相关#
- AI 翻译 — 流程本身:分块、保护和失败处理
- 翻译设置 — 启用语言、模型、模式和区域 URL
- SEO — 每个页面上的规范链接、站点地图和结构化数据
- GEO — 让助手能够引用页面的要素
- Docsbook 如何证明其声明 — 本页面遵循的规则