使用 AI 自动翻译 Drupal 页面

多语言积压（backlog）有一种特别的“味道”。你周一用英文发布，承诺德语“这周搞定”，到了周五却盯着 47 个已更新页面，根本没法清楚回答：“所以……真实进度到底是什么？”

我见过团队试图用更多流程来解决：表格、翻译工单、每周同步会。一直都能凑合，直到有人在 200 个页面里改了主视觉段落（hero paragraph）。然后你又回到靠猜的状态。

最终对我们有效的方法，是把翻译当作一个生产系统来做：用 TMGMT 进行跟踪与治理，用一个小型自定义模块通过 cron 自动触发任务，再配合一个在后台运行的 AI 翻译器，它可以通过分块（chunking）处理超长字段。

这篇文章从管理者视角出发：产出、风险，以及你应该问团队哪些问题，避免最后变成一个“悄无声息的烂摊子”。

先说清楚：在 Drupal 语境里，“自动翻译”到底是什么意思

如果你想象的是一个魔法按钮，能瞬间把整个网站变成五种语言，那就忘了吧。可靠的版本更慢，也更无聊：

• 检测到新增或更新的内容。
• 创建并跟踪翻译任务（job）。
• 工作按计划在后台运行。
• 结果进入审核步骤（或者如果你愿意承担风险，也可以自动接受）。
• 当译文满足你的规则时发布。

正是这种“任务（job）”的概念，让 TMGMT 成为很好的骨架。它本来就是为把翻译当作一项有状态、有追踪、有来源、并可通过翻译器插件执行的工作来管理而设计的。

所以你买的不是“AI 翻译”。你买的是一个可度量的工作流。

为什么 cron 和队列不是“实现细节”

管理者通常听到“cron”会觉得“定时任务嘛，没问题”。但 Drupal 的自动 cron 是按计划触发的，在低流量情况下可能会延后；在默认设置下，它还可能把额外负载加到用户请求上。

翻译任务很重。它涉及外部 API 调用、重试，有时还有很长的文本。所以可靠的模式是：先把工作放进队列，再让 cron 以可控的切片方式处理它。

用管理者能听懂的话说就是：

• 编辑不需要等翻译完成。
• 不会因为有人发布了一篇长页面，你的网站就出现延迟尖峰。
• 你可以通过分配更多或更少的后台时间来调节吞吐量。
• 故障会被隔离到更小的工作单元，而不是拖垮整次运行。

如果你的团队没有提前规划这些，你得到的不是自动化，而是一种新的故障模式。

AI 部分：你能得到什么，以及得不到什么

对于 AI 翻译器，我们采用与 TMGMT 兼容的方式，让翻译仍然通过任务与工作流来管理，而不是靠一次性脚本。

从项目角度看，选择哪家提供商比很多人想象的更重要。它会在未来给你更多选择：

• 当成本变化时，你可以切换模型。
• 如果政策要求，你可以用不同方式处理（路由）敏感内容。
• 你可以按语言调整 prompt 风格，减少语气漂移。
• 你可以把翻译设置当作配置管理，而不是硬编码逻辑。

但别在内部过度宣传。AI 翻译很快，也可能好得出乎意料，但它仍然需要治理。审核工作流存在是有原因的。

最大的运营风险：很长的 Body 字段

这部分通常要等 PM 们经历第一次事故之后才会真正重视。

大型 Body 字段（文档、政策页、包含大量嵌入式标记的页面）是“朴素”的 AI 翻译最容易翻车的地方。有时是明显报错；更常见的是悄悄出问题：只输出一部分、格式前后不一致，或者生成了损坏的 HTML，一路混过去，直到有人在生产站点上发现。

我们的解决方案不是“更好的提示词”。而是工程化手段：

• 在后台翻译，而不是在用户请求链路里翻译。
• 把很大的 Body 值拆成多个分块（chunk），保持在可行的大小范围内。
• 按原始顺序重新组装。
• 在分块级别重试，这样单个失败不会卡住整页。

分块确实带来一个权衡：术语可能在不同分块之间漂移。可以通过轻量术语表或按语言制定的风格规则来缓解。

自定义模块做什么（以及为什么你需要它）

TMGMT 是工作流引擎，但仍然需要有东西来决定 何时 创建翻译任务（job）。这就是自定义模块要做的事：

• 检测内容变更。
• 决定该内容类型需要哪些语言。
• 自动创建或更新翻译任务。
• 将工作推入队列，让 cron 稍后处理。

这能带来可预测的运营节奏，也让翻译成为发布卫生（publishing hygiene）的一部分，而不是一条独立的项目流水线。

在更大的项目里，你会需要明确规则：哪些内容类型自动翻译、哪些必须走审核、小改动与大改写分别如何处理。没有规则，自动化就会变成“惊喜行为”。

该衡量什么（才能判断它是否在工作）

如果你不定义成功，团队会替你定义，而且你可能不喜欢他们的定义。下面这些指标才真正对应业务结果：

• 翻译延迟：从内容发布/更新到译文可供审核的中位时间。
• 积压规模：处于“needs translation”或“needs review”的条目数量。
• 返工率：AI 输出后，译文被人工再次编辑的频率。
• 失败率：重试次数、卡住的任务，或需要人工介入的格式问题。

用任务跟踪作为报表与汇总的载体，而不是再发明一个平行的仪表盘。

治理：项目成功或“悄悄社死”的分水岭

让人最快对自动翻译失去信任的方式，是发布了法律风险高或伤害品牌的内容。自动化会放大“爆炸半径”。

你需要的是政策层面的决策，而不只是装几个模块：

• 哪些内容类型可以自动发布 AI 翻译？
• 哪些必须走审核？
• 谁来负责术语表：产品名称、法律措辞、受监管的表述？
• 如果模型更新导致语气变化，你的回滚方案是什么？

混合模式通常是更理性的折中：AI 负责量，人负责风险。

一个不会把编辑团队“炸翻”的上线计划

如果你一次性把这一切都推上去，编辑会觉得地面都在移动。其实有更好的路径。

先从一个结构清晰、风险较低的内容类型开始：新闻、活动页、FAQ。把流水线跑稳。然后再扩展到更“脏”的内容：长文页面、文档、格式很重的营销页。

另外，尽早决定 cron 怎么跑。可靠性和吞吐量会以一种团队常常低估的方式影响交付日期。这不是一个技术脚注。

在我点头之前，我会问的一个问题

当系统正常运转时，翻译会变成背景噪音。这就是目标。

但这里有个不太舒服的问题：你是在优化速度，还是优化信心？ 因为答案决定了你是否自动发布、审核要多严格、先推哪些语言，以及你愿意在术语控制上投入多少。

如果你告诉我你在运营什么类型的网站（偏营销、偏文档，或混合）以及范围内有多少语言，我可以建议一种与风险画像匹配的上线方式，而不是假装一个工作流适用于所有人。

想找市场上最好的 Drupal 开发公司？你刚刚找到了。

我们是最大的 Drupal 专注型数字化代理机构，致力于交付快速、安全、可扩展的平台——毫不妥协。从新建与改版到迁移与长期支持，我们的 Drupal 专家以精品级关注交付企业级成果。

今天就预约一次通话，让我们把你的 Drupal 路线图变成高性能的现实。