WP 博客多语言化实操
(5) 博客菜单翻译实操
![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
在继续测试 SlyTranslate 的整篇文章翻译功能时，我再次遇到了一次全文翻译失败。
这次后台返回的错误是：
swq_full_article_token_validation_failed
从错误名称来看，问题仍然与全文翻译过程中使用的受保护占位符有关。
进一步检查后发现，这次并不是占位符丢失、格式被修改或固定顺序被打乱，而是 GLM 5.2 在生成译文时，把一个相邻段落整体重复输出了一遍，导致同一个 SWQINLINE 占位符出现了两次。
最终，我没有放宽现有校验规则，也没有直接删除重复占位符，而是完善了发送给模型的全文翻译提示词。
修改完成后，我重新翻译了文章 19445，已经可以正常完成。
一、为什么全文翻译需要使用占位符
我目前使用 SlyTranslate 调用 GLM 5.2，对 WordPress 技术文章进行整篇翻译。
为了避免大模型修改代码、命令、URL、HTML 结构和 Gutenberg 区块注释，定制插件会先把不应该翻译的内容替换为受保护占位符。
例如：
SWQSTRUCT000018END
SWQBLOCK000018END
SWQINLINE000018END
SWQHTML000018END
不同类型的占位符分别承担不同作用：
SWQSTRUCT：保护 Gutenberg 区块边界；SWQBLOCK：保护完整代码块或不可翻译元素；SWQINLINE：保护段落中的行内代码；SWQHTML：保护固定 HTML 元素。
大模型完成自然语言翻译后，插件再将这些占位符还原为原始内容。
这种方案能够明显降低代码块和 WordPress 结构被误翻译的风险，但前提是模型返回的占位符数量、格式和顺序必须正确。
二、这次出现的错误
本次翻译失败后，诊断文件显示：
expected_count: 629
actual_count: 630
expected_fixed_count: 584
actual_fixed_count: 584
fixed_order_valid: true
missing_tokens: []
unexpected_tokens: []
duplicated_tokens:
SWQINLINE000013END: 2
这组数据已经能够比较准确地说明问题。
预期应该返回 629 个占位符，模型实际返回了 630 个。
与此同时：
missing_tokens: []
unexpected_tokens: []
这说明没有占位符丢失，也没有出现无法识别的新占位符。
固定结构占位符的数量和顺序也完全一致：
expected_fixed_count: 584
actual_fixed_count: 584
fixed_order_valid: true
唯一异常是：
SWQINLINE000013END
在模型输出中出现了两次。
三、不是简单地多输出了一个 Token
进一步检查模型返回内容后，发现问题并不是单纯重复了一个占位符字符串。
实际输出类似下面这样：
SWQSTRUCT000105END
<p>The cached query results under the SWQINLINE000013END Host:</p>
SWQSTRUCT000106END
SWQSTRUCT000107END
<p>The cached query results under the SWQINLINE000013END Host:</p>
SWQSTRUCT000108END
模型把前一个段落的英文内容连同其中的 SWQINLINE000013END，一起复制到了后一个结构区间。
也就是说，这次错误的本质是：
模型重复生成了一个相邻段落，而不是只重复输出了一个占位符。
这一区别非常重要。
如果只是简单删除第二个 SWQINLINE000013END，虽然 Token 数量可能恢复正常，但重复的英文段落仍然存在。
更严重的是，后一个结构区间原本应该包含的正文，很可能已经被前一个段落的副本替换。
此时强行删除重复 Token，可能导致校验表面通过，但文章实际缺少了一段原文对应的译文。
因此，我没有采用自动删除重复占位符的处理方式。
四、为什么可以排除响应截断
本次请求只调用了一次 GLM 5.2，主要数据如下：
模型：glm-5.2
max_tokens：32768
请求耗时：约 86 秒
输出字符数：32828
模型返回内容已经完整到文章结尾，最终的结构占位符也正常存在。
同时：
missing_tokens: []
说明所有预期占位符都能在响应中找到。
如果 API 响应因为 max_tokens 不足而在中途被截断，通常会缺少文章尾部的大量结构 Token，而不是只多出一个内联 Token。
因此，本次问题基本可以排除：
max_tokens不足；- 网络中断；
- HTTP 请求失败；
- JSON 解析失败；
- 文章结尾被截断；
- 响应解包逻辑误删正文。
当前链路还没有记录 API 原始的 finish_reason，所以无法直接证明模型以正常的 stop 原因结束。
不过，从文章结尾完整、所有预期 Token 均存在的结果来看，本次错误并不符合响应截断的特征。
五、现有严格校验器工作正常
从这次结果来看，当前全文翻译校验器并没有出现误判。
它正确识别出了以下异常：
expected_count != actual_count
duplicated_tokens 不为空
随后阻止错误译文继续还原和写入文章。
如果没有这层校验，这篇带有重复段落、并且可能缺少原始内容的英文文章，很可能会直接保存到 WordPress。
因此，当前严格校验不能因为模型偶尔出现问题就被放宽。
尤其不应该采用以下处理方式：
- 允许重复 Token 直接通过；
- 自动删除第二个重复 Token；
- 只检查 Token 是否存在，不检查出现次数；
- 只校验固定结构 Token，忽略
SWQINLINE； - 为了降低失败率而取消全文完整性检查。
对于公开发布的翻译插件而言，翻译失败确实会影响用户体验，但静默生成结构看似完整、正文内容却存在错误的文章，风险更高。
六、此前还遇到过前导零丢失问题
在之前的测试中，还出现过另一种占位符异常。
模型曾把：
SWQSTRUCT000018END
输出为：
SWQSTRUCT00018END
也就是把固定六位数字编号缩短成了五位，删除了一个前导零。
插件目前已经加入无歧义的前导零恢复逻辑。
只有在能够明确判断原始 Token 的情况下，才会把五位编号恢复为六位编号，并重新执行完整严格校验。
如果修复结果存在歧义，或者修复后仍然无法通过完整校验，插件仍然会终止翻译，不会强行写入文章。
不过，代码层面的容错只能作为兜底。
更合理的方式仍然是从提示词中明确告诉模型：
- 占位符编号固定为六位数字；
- 所有前导零都必须保留；
- 不得修改 Token 类型和大小写；
- 不得在 Token 内插入空格、换行或标点；
- 每个 Token 必须且只能出现一次。
七、为什么先选择完善提示词
发现重复 Token 后，我一开始考虑过，是否可以让插件自动删除其中一个重复项。
但结合实际输出可以看到，模型重复的不是一个孤立 Token，而是整个相邻段落。
在这种情况下直接去重，可能让校验通过，却无法恢复后一个段落原本应该包含的内容。
另一种方案是识别受污染的结构区间，再对该区间进行局部重新翻译。
不过，这需要额外解决以下问题：
- 判断两个重复 Token 中哪一个属于正确段落；
- 判断后一个段落是否已经覆盖其他内容；
- 从源 payload 中提取对应结构区间；
- 单独调用模型重新翻译；
- 把局部结果替换回整篇译文；
- 再次执行完整 Token 校验；
- 防止局部修复引入新的结构问题。
目前只发现了一次相邻段落重复，而且现有校验已经成功阻止了错误结果写入。
因此，我先采用了改动更小、维护成本更低的方案：
完善全文翻译提示词，明确限制段落重复、Token 重复和前导零丢失。
现有严格校验、前导零无歧义修复、响应还原和 API 请求流程均保持不变。
八、当前使用的完整全文翻译提示词模板
本次修改的是：
SWQ_GLM52_Translation_Tuning::build_content_prompt()
生产插件会通过下面的代码，根据目标语言动态插入对应的写作规则：
$language_rules = self::build_target_language_content_rules( $target_language );
因此，下面展示的是当前使用的完整全文翻译提示词模板。
其中“原有目标语言写作规则”所在位置，会在实际请求时被动态生成的规则替换。
全文翻译模式：
输入内容是一篇技术文章的完整正文。请将它作为一个连贯、可直接发布的完整文档翻译成目标语言。
请根据文章内容判断其实际技术领域，不要预设每篇文章都与 WordPress、PHP、Nginx、服务器或任何其他固定技术有关。
[原有目标语言写作规则，由 build_target_language_content_rules() 动态插入]
上方提供的文章标题和摘要只用于理解上下文，不得将它们加入返回的正文。
不可翻译的代码、行内代码、固定 HTML 元素、Gutenberg 区块边界以及部分可翻译区域已替换为受保护占位符。
每个受保护占位符都必须逐字符原样复制，并且在输出中必须且只能出现一次。不得遗漏、重复、额外生成、复制、翻译、改名、拆开、包裹或重新编号任何占位符，也不得把一个段落中的占位符复制到另一个段落。占位符的类型、大小写和结尾必须保持不变；编号必须始终是固定 6 位数字，所有前导零都必须保留。
例如，SWQSTRUCT000018END、SWQBLOCK000018END、SWQINLINE000018END 和 SWQHTML000018END 必须完整保留。SWQSTRUCT000018END 不得写成 SWQSTRUCT00018END、SWQSTRUCT000018end、SWQSTRUCT 000018 END 或 SWQSTRUCT000 018END。不得在占位符内部插入空格、换行、标点、HTML 标签或 Markdown 格式。
SWQBLOCK 开头的占位符代表一个完整、独立且不可翻译的代码块或代码元素。把每个 SWQBLOCK 当作不可移动的文档锚点，保持它们原有的相对顺序和文档位置。不得为了让目标语言更流畅而反转、交换或重新组合两个 SWQBLOCK；只能改写固定 Token 前、后或之间的自然语言，同时保持 Token 顺序不变。例如原文结构是“属性中：SWQBLOCK000001END……提交：SWQBLOCK000002END”时，必须保持 000001 在 000002 之前。
SWQINLINE 开头的占位符代表自然语言中的行内代码。每个 SWQINLINE 只能在其原句或原段落内部因英文语序需要而调整位置，不得移动到其他段落、列表项、标题、表格单元格或章节，也不得把前一段的 SWQINLINE 复制到后一段。
SWQHTML 开头的占位符代表固定 HTML 元素，必须逐字符原样保留一次，且不得移动。
SWQSTRUCT 开头的占位符代表原始 Gutenberg 起始或结束区块注释，是不可移动的区块边界。必须保持完整 SWQSTRUCT 序列的数量、顺序和位置，不得交换相邻结构 Token、删除区块边界，或把一个结构区间中的内容移动到另一个结构区间。
匹配的 SWQPLAINSTART 与 SWQPLAINSTOP 之间的文本来自 Plaintext 或预格式化区块。默认翻译其中每个人类语言片段，包括作者编写的标签、注释、摘要、说明和描述，即使它们很短、单独占一行、看起来像终端输出，或与 URL、域名和标识符混合。保留机器值，但翻译其周围的人类语言说明。例如，将“中文站：”和“英文站：”译为“Chinese site:”和“English site:”，将“选择 Browser”译为“Select Browser”，并在保留域名的同时翻译“www.example.com：补丁正常输出”中的说明部分。只有当上下文明示某段原文措辞本身就是实际系统证据，修改它会造成事实错误时，才保留源语言；这项狭窄例外可用于确切界面标签、原始错误消息、原始日志或字面观测值。例如，周围正文说明“中文（中国）”是中文站实际显示的语言切换器标签时，应保留该文字。仅仅位于 Plaintext 区块、看起来像输出或只是短标签，都不足以保留源语言；无法确定自然语言片段用途时，应翻译。若 Plaintext 区域只包含 URL、域名、路径、命令、标识符、状态码或其他机器可读值，则仅将其用于理解上下文，内部文本必须原样复制且不得移动。始终保留 URL、域名、路径、命令、参数、机器标识符、状态码、箭头、标点、行序、行数、空行和缩进，不得添加 Markdown 围栏或引号。
匹配的 SWQALTSTART 与 SWQALTSTOP 之间是图片 alt 值，应自然、简洁地翻译，不得添加引号；外围图片标签会另行还原。
原始 Gutenberg 区块注释由 SWQSTRUCT 表示；其余输入仍包含 HTML 标签及属性、区块属性、URL、域名、短代码、模板变量和文档结构。所有这些内容以及命令、参数、配置键、路径、文件名、标识符、产品名和插件名都必须原样保留。
原文中的每个自然语言段落只能翻译一次。不得重复、遗漏、合并、拆分、替换或重新排列 Gutenberg 区块、HTML 元素、段落、标题、列表项、表格单元格或章节；保持其层级、相对顺序和文档位置。不得把前一个段落的译文复制到相邻段落。即使两个相邻段落内容相似，也必须分别翻译并保留各自结构；不得因前后文相似而跳过其中任何一个段落，也不得自行补充源内容中不存在的段落、标题、说明或总结。
在同一个标题、段落、列表项或表格单元格内部，可以根据自然英文表达需要调整句子结构、主语、修饰语和从句，但不得跨越原有结构边界移动内容。
只翻译自然语言文本。保持原意、事实、技术区别、操作步骤、时间顺序、风险判断、确定程度和结论；不得把链接误写成重定向、把缓存条目误写成数据库记录，或混淆原文中的其他技术区别。英文应自然、准确、克制且适合技术读者，不使用营销表达。
返回前，在内部检查是否存在重复或遗漏的段落、重复或遗漏的占位符、占位符格式变化以及固定结构 Token 的数量或顺序变化；发现问题时应先自行修正，但不得输出检查过程、Token 清单、校验报告或解释。
不得添加解释、引言、结语、评论、免责声明、营销语言、Markdown 代码围栏或源文不存在的内容。最终只返回完整的英文译文正文。
九、这份提示词重点解决了哪些问题
这份提示词虽然比较长，但不同规则分别用于解决不同的翻译风险。
1. 防止占位符重复和遗漏
提示词明确要求：
- 每个占位符必须且只能出现一次；
- 不得遗漏或额外生成占位符；
- 不得把一个段落中的占位符复制到另一个段落；
- 不得改变 Token 类型、大小写和结尾。
这部分直接针对本次 SWQINLINE000013END 被重复输出的问题。
2. 固定六位数字编号
提示词明确规定 Token 编号始终为固定六位数字，并保留全部前导零。
同时给出了错误格式示例：
SWQSTRUCT00018END
SWQSTRUCT000018end
SWQSTRUCT 000018 END
SWQSTRUCT000 018END
这部分针对之前发生过的 Token 前导零丢失问题。
3. 限制 SWQINLINE 的移动范围
行内代码在中英文语序转换时，可能需要在一句话内部调整位置。
因此，SWQINLINE 不能完全固定在原始字符位置，但它只能在原句或原段落内部移动，不能进入其他段落、标题、列表项或表格单元格。
4. 固定 Gutenberg 结构
SWQSTRUCT 代表 Gutenberg 起始或结束区块注释。
提示词要求保持它们的数量、顺序和位置，不得交换相邻结构 Token，也不得把一个结构区间中的内容移动到另一个区间。
5. 防止相邻段落被复制
提示词明确要求每个自然语言段落只能翻译一次。
即使两个相邻段落内容相似，也必须分别翻译并保留各自结构，不能因为上下文相似而复制前一段或跳过后一段。
6. 处理预格式化区域中的自然语言
SWQPLAINSTART 与 SWQPLAINSTOP 之间可能同时包含自然语言和机器值。
当前规则要求：
- 翻译标签、说明、注释和描述；
- 保留 URL、域名、路径、命令和标识符；
- 保持行序、空行和缩进；
- 只有在内容属于原始日志、错误消息或确切界面标签时，才保留原始语言。
7. 要求模型内部检查，但不返回检查报告
提示词要求模型在返回前检查：
- 是否重复或遗漏段落；
- 是否重复或遗漏 Token；
- Token 格式是否变化；
- 固定结构 Token 的数量和顺序是否正确。
但是，模型不能返回检查过程、Token 清单或说明。
最终响应仍然只能是英文正文，避免模型额外输出：
Translation completed successfully.
All placeholders were verified.
十、修改后的实际测试结果
提示词修改完成并同步到生产插件后，我重新对文章 19445 执行了一次全文翻译。
这次翻译已经正常完成，没有再次出现：
swq_full_article_token_validation_failed
也没有检测到：
SWQINLINE重复；- Token 前导零丢失；
- 固定 Token 顺序异常；
- 相邻段落重复导致的校验失败。
这说明本次提示词强化至少对当前测试文章起到了实际作用。
不过，一次重新翻译成功，并不能证明 GLM 5.2 以后绝不会再次生成重复段落。
大模型输出仍然存在一定随机性，因此现有严格校验和失败阻断逻辑仍然需要保留。
更准确的结论应该是：
新提示词降低了当前已知错误再次发生的概率，但不能替代代码级校验。
十一、为什么暂时不增加复杂的自动修复
理论上，插件还可以在检测到重复 SWQINLINE 后，尝试识别错误结构区间，再单独重新翻译对应段落。
但这会明显增加实现复杂度。
需要解决的问题包括：
- 判断两个重复 Token 中哪一个属于正确段落；
- 判断后一个段落是否已经覆盖其他原始内容；
- 从源 payload 中重新提取对应结构区间；
- 单独重新翻译该区间；
- 将局部结果替换回整篇译文；
- 再次执行完整 Token 校验；
- 防止局部重试造成新的结构问题。
目前只出现了一次相邻段落重复，并且通过提示词强化后重新翻译已经成功。
在这种情况下，暂时没有必要为了理论上的自动恢复能力，引入大量复杂代码和额外维护成本。
当前方案仍然是：
提示词降低错误概率
+
严格 Token 校验阻止错误结果
+
失败后重新执行一次全文翻译
如果以后仍然频繁出现相同问题，再考虑增加一次受控的整篇自动重试，会比直接删除重复 Token 更安全，也比局部结构修复简单。
十二、修改过程中暴露出的生产环境安全问题
这次提示词修改过程中，还出现了一个与翻译本身无关、但同样值得记录的问题。
最初给 Codex 的任务要求是修改插件提示词，并直接提供了生产文件路径：
/data/wwwroot/www.shuijingwanwq.com/wp-content/mu-plugins/swq-glm52-translation-tuning.php
Codex 将“请修改插件”理解为已经获得生产环境写入授权，直接修改了生产文件。
虽然本次修改内容正确，修改前也创建了备份，并且 PHP 语法检查通过，但这种默认直接操作生产环境的流程仍然存在风险。
后来我在项目根目录增加了：
AGENTS.md
其中明确规定：
只读分析
→ 本地副本修改
→ 等待明确部署授权
→ 创建生产备份
→ 上传指定文件
→ 完成生产验证
同时约定：
/data/wwwroot/下的所有路径均属于生产环境；- “修改代码”“修复插件”“完善功能”等普通表述不代表生产部署授权；
- 没有明确要求部署时，只能修改本地副本；
- 历史任务中的部署授权不能自动延续到后续任务；
- 如果是否允许写入生产环境存在歧义，默认不得写入。
这项调整不会直接改善翻译质量，但能够降低后续使用 Codex 维护插件时的生产风险。
十三、这次排查带来的结论
这次问题进一步说明，整篇文章翻译的稳定性不能只依赖模型本身。
一个可长期运行的技术文章翻译流程，至少需要三层保护。
第一层：明确的提示词约束
告诉模型哪些内容可以翻译，哪些内容必须逐字符保留，并明确禁止段落重复、遗漏和结构移动。
第二层：代码级占位符保护
在发送给模型前，把代码、HTML、Gutenberg 结构和机器值替换为受保护 Token。
第三层：返回结果严格校验
检查：
- Token 数量；
- Token 唯一性；
- Token 格式；
- 固定 Token 顺序；
- 缺失 Token；
- 额外 Token；
- 重复 Token；
- 无歧义格式修复后的完整性。
提示词可以降低错误概率，但不能替代校验器。
校验器可以发现结构异常，但也不能保证自然语言内容绝对正确。
最终目标不是让每次调用永远不会失败，而是在模型偶尔出错时，插件能够阻止错误结果进入正式文章，并让用户通过简单重试恢复正常流程。
十四、当前阶段的全文翻译流程
经过这次调整，目前全文翻译流程可以继续保持：
保护 Gutenberg、HTML 和代码内容
→ 一次性发送完整文章
→ GLM 5.2 翻译自然语言
→ 检查 Token 数量、格式、唯一性和顺序
→ 通过校验后还原原始内容
→ 写入 WordPress 英文文章
提示词已经针对真实出现过的两类问题进行了强化：
相邻段落和 SWQINLINE 重复
Token 六位编号丢失前导零
重新翻译文章 19445 已经成功。
现阶段可以继续观察后续文章的实际翻译结果，不急于加入自动删除、局部重译或复杂恢复机制。
对于这类依赖大模型的自动翻译插件而言，保持实现简单、校验严格、问题可诊断，可能比追求任何异常都自动修复更加可靠。
WordPress 网站维护、性能优化与博客运营咨询
本站已持续运营超过 10 年，累计发布 1000+ 篇原创技术文章，长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。
如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题，可以联系我做一次远程技术排查。
适合以下用户：
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点
服务内容：
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询
如需了解方案或交流相关问题，请直接联系我，并注明：WordPress 维护咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复