WP 博客多语言化实操
(5) 博客菜单翻译实操
![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近，我开始测试使用 SlyTranslate 配合智谱 GLM-5.2，自动为 WordPress 中文文章创建英文译文。
我的目标并不是简单翻译几段纯文本，而是希望自动完成一篇真实的 WordPress 技术长文，同时满足以下要求：
- 保留 Gutenberg 区块结构；
- 保留图片、链接和 HTML；
- 保留代码块原文；
- 自动创建英文文章；
- 自动建立 Polylang 中英文关联；
- 尽可能减少人工复制和重新排版。
测试文章的中文文章 ID 为 19372，正文中包含大量图片、列表和代码块，属于比较适合进行压力测试的一篇文章。
最开始，翻译请求连续出现 504 超时。经过多轮日志排查后，最终发现问题并不只是服务器执行时间不足，而是同时存在两个相互叠加的问题：
- SlyTranslate 发给 GLM-5.2 的
max_tokens只有256； - SlyTranslate 使用三倍字符长度作为长文本失控判断阈值，对中文翻译为英文容易产生误判。
在修复这两个问题后，文章最终在约 9 分钟内完成翻译，并成功生成结构完整的英文文章。
英文文章地址：
https://en.shuijingwanwq.com/2026/07/13/19426/
一、测试环境
本次使用的主要环境如下：
- WordPress；
- Polylang；
- SlyTranslate；
- Ultimate AI Connector for Compatible Endpoints；
- 智谱开放平台；
- GLM-5.2；
- W3 Total Cache；
- Code Block Pro；
- Nginx；
- PHP-FPM。
智谱兼容接口地址为：
https://open.bigmodel.cn/api/paas/v4
使用的模型为：
glm-5.2
为了避免思考过程消耗额外时间和 Tokens，模型配置中关闭了思考模式。
我为 SlyTranslate 设置的翻译规则主要包括：
- 最终只输出英文内容；
- 保留 Gutenberg 区块结构；
- 保留 HTML、URL、域名和插件名称；
- 代码块不翻译；
- 保持技术博客的客观语气；
- 不增加或删除技术事实。
二、最初的问题：翻译长时间运行后返回 504
第一次测试长文翻译时，SlyTranslate 会长时间显示正在翻译。
最开始，我先后调整了以下超时时间：
- PHP 执行时间；
- PHP-FPM
request_terminate_timeout； - Nginx
fastcgi_read_timeout； - Nginx
fastcgi_send_timeout。
最终，PHP-FPM 和 Nginx 的相关超时时间都增加到了 600 秒。
但是，即使等待整整 10 分钟，翻译请求仍然失败。
PHP-FPM 日志显示，请求在运行约 600 秒后被终止：
POST /index.php?_locale=user
Nginx 随后返回：
504 Gateway Timeout
这说明服务器并不是在某个瞬间崩溃，而是翻译任务在 600 秒内仍未完成。
三、智谱后台数据显示了异常请求模式
继续查看智谱开放平台的调用记录后，我发现一次翻译任务产生了大约：
- 105 次模型请求；
- 54,443 个输入 Tokens；
- 26,986 个输出 Tokens。
更加异常的是，很多请求的输出 Tokens 都恰好为：
256
如果只是正常分段翻译，不太可能连续出现大量完全相同的输出长度。
这意味着模型很可能不是自然结束，而是在达到输出上限后被强制截断。
四、增加 HTTP 调试后确认真正原因
为了确认 SlyTranslate 实际发送给智谱的请求参数，我临时创建了一个 MU Plugin，用于记录以下信息：
- 模型名称；
max_tokens；- 是否启用思考模式；
- HTTP 请求耗时；
finish_reason；- 输入和输出 Tokens。
日志显示，原始请求参数为：
model: glm-5.2
max_tokens: 256
thinking: null
chat_template_kwargs: {"enable_thinking":false}
模型返回结果则几乎全部是：
finish_reason: length
completion_tokens: 256
这已经可以明确说明：
GLM-5.2 每次输出达到 256 Tokens 后都会被截断。
由于译文结构不完整，SlyTranslate 的内容校验无法通过，于是会继续重试或重新拆分请求。
因此，任务并不是正常处理了 10 分钟，而是在不断执行大量被截断的无效翻译。
单纯继续增加 PHP 或 Nginx 超时时间，无法真正解决问题。
五、通过 MU Plugin 调整 GLM-5.2 请求参数
我没有直接修改 SlyTranslate 的主要翻译流程，而是保留它现有的：
- Gutenberg 区块解析；
- 内容分组；
- HTML 结构保护；
- 翻译结果校验；
- Polylang 文章关联。
只在最终请求发送到智谱之前，对 GLM-5.2 的请求参数进行最小调整。
创建文件：
wp-content/mu-plugins/swq-glm52-translation-tuning.php
内容如下：
<?php
/**
* Plugin Name: SWQ GLM-5.2 Translation Tuning
* Description: Adjusts Zhipu GLM-5.2 request parameters used by SlyTranslate.
*/
defined( 'ABSPATH' ) || exit;
add_filter(
'http_request_args',
static function ( array $args, string $url ): array {
$host = wp_parse_url( $url, PHP_URL_HOST );
$path = wp_parse_url( $url, PHP_URL_PATH );
if (
'open.bigmodel.cn' !== $host
|| false === strpos( (string) $path, '/chat/completions' )
) {
return $args;
}
$raw_body = $args['body'] ?? '';
$body = is_string( $raw_body )
? json_decode( $raw_body, true )
: $raw_body;
if (
! is_array( $body )
|| 'glm-5.2' !== ( $body['model'] ?? '' )
) {
return $args;
}
$body['thinking'] = array(
'type' => 'disabled',
);
if (
! isset( $body['max_tokens'] )
|| (int) $body['max_tokens'] < 1024
) {
$body['max_tokens'] = 1024;
}
$encoded = wp_json_encode(
$body,
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES
);
if ( is_string( $encoded ) ) {
$args['body'] = $encoded;
}
return $args;
},
PHP_INT_MAX - 10,
2
);
这段代码只针对以下请求生效：
- 域名为
open.bigmodel.cn； - 路径中包含
/chat/completions； - 模型名称为
glm-5.2。
它主要完成两个调整：
thinking.type = disabled
max_tokens 最低调整为 1024
这里的 1024 是最大允许输出，并不代表模型每次都会生成 1024 Tokens。
后续日志显示，大部分正常译文只使用了几十到两百多个输出 Tokens。
六、第一次修复后的结果：89 次请求全部正常结束
重新开始翻译后，日志中的请求参数已经变为：
max_tokens: 1024
thinking: {"type":"disabled"}
所有 89 个响应的完成原因均为：
finish_reason: stop
统计结果为：
stop: 89
length: 0
单次请求耗时大多在 2～6 秒之间，最大输出也只有约 265 Tokens。
这说明：
- 256 Tokens 截断问题已经解决；
- 模型能够正常结束输出；
- SlyTranslate 的分块翻译流程开始正常工作；
- 继续增加
max_tokens并不会让模型无意义地生成更长内容。
此时，浏览器中的翻译进度条也终于能够持续推进。
七、第二个问题：SlyTranslate 将正常英文摘要判断为失控生成
虽然请求不再被截断，但第一次完整翻译仍然失败。
SlyTranslate 返回错误：
The translated output is far longer than the source text,
indicating the model entered a runaway generation loop
or appended hallucinated content.
对应的内部错误代码为：
invalid_translation_runaway_output
继续查看 TranslationValidator.php 后发现，SlyTranslate 对较长文本使用了以下判断：
private const MAX_RUNAWAY_OUTPUT_RATIO = 3;
判断逻辑相当于：
译文字符数 > 原文字符数 × 3
一旦超过三倍，就认为模型可能进入失控生成。
这个限制对于同类拉丁文字语言可能比较宽松，但对于中文翻译为英文，字符数比例并不一定可靠。
八、为什么中文翻译为英文容易超过三倍字符数
本次触发错误的是文章摘要。
中文摘要长度为：
254 个字符
三倍阈值为：
762 个字符
GLM-5.2 返回的英文摘要长度约为：
856 个字符
实际比例约为：
856 ÷ 254 ≈ 3.37
从英文内容来看，这并不是模型重复生成，也没有增加大量不存在的内容。
只是因为中文单个字符的信息密度较高，而英文需要使用更多单词、空格和标点来表达相同含义。
因此，三倍字符限制对中文源文章容易产生误判。
九、将长文本增长阈值从 3 调整为 6
考虑到目前和后续文章的源语言都会是中文，而目标语言未来不一定只有英文，我最终将阈值调整为：
private const MAX_RUNAWAY_OUTPUT_RATIO = 6;
修改文件：
wp-content/plugins/slytranslate/inc/TranslationValidator.php
修改前：
private const MAX_RUNAWAY_OUTPUT_RATIO = 3;
修改后：
private const MAX_RUNAWAY_OUTPUT_RATIO = 6;
修改前先备份原文件：
cd /data/wwwroot/www.shuijingwanwq.com
file="wp-content/plugins/slytranslate/inc/TranslationValidator.php"
backup="${file}.bak-runaway-ratio-$(date +%F-%H%M%S)"
cp -a "$file" "$backup"
修改完成后检查 PHP 语法：
php -l wp-content/plugins/slytranslate/inc/TranslationValidator.php
验证结果：
No syntax errors detected
将阈值设为 6 后：
- 当前约 3.37 倍的正常英文摘要可以通过；
- 中文翻译为德语、法语等语言时也有更大余量；
- 插件原来记录的 10～30 倍异常生成仍然可以被拦截。
需要注意的是，这项调整直接修改了 SlyTranslate 插件文件。
以后更新插件时，这个值可能被覆盖，需要重新检查。
十、最终翻译成功
再次开始翻译后，任务终于完整执行成功。
本次翻译用时约：
9 分 6 秒
SlyTranslate 自动创建了英文文章：
文章 ID：19426
状态：publish
同时自动完成：
- 英文标题生成；
- 英文摘要生成；
- 正文翻译；
- 特色图片保留；
- Polylang 中英文文章关联；
- 英文固定链接生成。
十一、检查中英文文章的 Gutenberg 结构
翻译成功并不等于内容一定完整，因此我继续通过服务器脚本比较了中文文章和英文文章。
中文文章：
ID：19372
英文文章：
ID：19426
主要区块统计如下：
| 项目 | 中文文章 | 英文文章 |
|---|---|---|
| 段落 | 127 | 127 |
| 标题 | 28 | 28 |
| 图片 | 8 | 8 |
| 列表 | 15 | 15 |
| 列表项 | 72 | 72 |
| Code Block Pro | 54 | 54 |
| Gutenberg 开始注释 | 304 | 304 |
进一步提取 Gutenberg 区块签名后，结果为：
中文签名数：608
英文签名数：608
区块顺序完全一致：是
这说明英文文章没有出现：
- 区块丢失；
- 区块顺序错乱；
- 开始和结束注释不匹配；
- Gutenberg 结构被模型重写。
十二、检查 54 个 Code Block Pro 代码块
这篇文章包含 54 个 wp:kevinbatdorf/code-block-pro 区块。
逐个序列化并比较后，结果为：
中文代码块：54
英文代码块：54
完全一致的代码块：54
发生变化的代码块：0
也就是说，54 个代码块全部逐字保持原样。
这对于技术博客非常重要。
普通机器翻译或整篇文本翻译很容易修改：
- 命令；
- 域名；
- URL；
- PHP 代码；
- Bash 命令；
- JSON；
- HTML；
- 配置文件内容。
SlyTranslate 的区块级处理在结构安全性方面表现得比较稳定。
十三、检查英文正文是否残留中文
最后，我又统计了英文文章中的中文字符分布。
结果为：
标题中文字符：0
摘要中文字符：0
代码块之外中文字符：0
存在中文的非代码区块：0
剩余中文全部位于原样保留的 Code Block Pro 区块中。
因此，可以确认：
- 标题已完整翻译；
- 摘要已完整翻译；
- 普通段落已完整翻译；
- 标题和列表已完整翻译；
- 没有正文区块漏翻；
- 代码块遵循原有规则保持不变。
英文纯文本长度与中文纯文本长度比例约为：
1.75
这个比例也没有显示出整篇重复生成或内容异常膨胀。
十四、英文前台检查
英文文章前台地址为：
https://en.shuijingwanwq.com/2026/07/13/19426/
通过浏览器进行人工检查后，暂未发现以下问题：
- 页面无法打开；
- Gutenberg 区块报错；
- 图片丢失；
- 列表结构错乱；
- 代码块损坏；
- 目录异常；
- 页面出现大段重复内容。
十五、翻译质量的当前判断
从技术流程来看，这次测试已经成功：
- 长文可以完成翻译；
- Gutenberg 结构能够保留；
- 代码块不会被修改；
- Polylang 关联正常；
- 英文页面可以直接访问。
但从英文表达质量来看，目前 GLM-5.2 生成的文章仍然可能存在：
- 少量直译句式；
- 个别技术术语不够精确；
- 某些上下文逻辑词使用不够自然；
- 标题略长；
- 纯文本形式的代码块仍保留中文。
例如，中文语境中的“固定链接”有时可能被直接翻译成：
permalinks
但在具体上下文中，它实际可能更接近：
hardcoded links
这些问题暂时不会影响文章的基本理解，但距离完全不需要人工检查的高质量英文重译，仍有一定差距。
目前我不打算为每篇文章再投入 10～20 分钟进行英文审校。
如果仍然需要大量人工修改，那么自动翻译带来的效率优势就会明显下降，还不如继续使用 ChatGPT Plus 完成整篇重译。
因此，当前阶段先保留这套已经跑通的技术方案，后续再从以下方向继续优化：
- 调整翻译 Prompt；
- 优化技术术语规则；
- 尝试更适合技术文章的模型；
- 区分真正的代码与纯文本输出；
- 优化标题和摘要生成；
- 将长度校验改为更适合中文源文章的判断方式。
十六、关闭临时调试日志
问题定位完成后，我关闭了临时 HTTP 调试 MU Plugin。
执行：
cd /data/wwwroot/www.shuijingwanwq.com
mv \
wp-content/mu-plugins/swq-slytranslate-http-debug.php \
wp-content/mu-plugins/swq-slytranslate-http-debug.php.disabled
同时清空调试日志：
: > wp-content/slytranslate-http-debug.log
最终状态：
swq-slytranslate-http-debug.php.disabled
slytranslate-http-debug.log：0 字节
用于调整 GLM-5.2 参数的文件仍然保持启用：
wp-content/mu-plugins/swq-glm52-translation-tuning.php
因此以下设置仍会继续生效：
thinking.type = disabled
max_tokens 最低为 1024
十七、本次排障得到的几个结论
1. 长时间运行不一定是服务器性能不足
最开始看到 504 和 PHP-FPM 超时，很容易继续增加执行时间。
但真正的问题是每次输出都在 256 Tokens 时被截断。
如果不查看模型的实际请求和 finish_reason，仅调整服务器超时时间，很难解决根本问题。
2. 应同时检查请求数量和输出 Tokens
单次请求速度并不慢，但大量失败重试会迅速累积总耗时。
本次最有价值的线索是：
大量请求的 completion_tokens 都恰好等于 256
这比单独观察浏览器中的进度条更能说明问题。
3. 统一字符倍数不适合所有语言组合
中文字符的信息密度与英文不同。
简单使用：
译文字符数 > 原文字符数 × 3
容易将正常的中文到英文翻译误判为异常生成。
4. WordPress 技术文章不能只检查译文内容
对于包含大量区块和代码的文章，还需要检查：
- Gutenberg 区块数量；
- 区块顺序；
- 图片数量；
- 列表数量；
- 代码块数量；
- 代码块内容；
- 残留中文；
- 前台实际渲染结果。
5. 技术链路跑通与翻译质量达标是两个问题
这次已经解决的是：
SlyTranslate 能否稳定完成 GLM-5.2 长文翻译。
目前尚未完全解决的是：
英文质量能否在完全不进行人工审校的情况下，达到我原来使用 ChatGPT Plus 整篇重译的水平。
这两个问题需要分开评估。
结语
经过这次排查，SlyTranslate + 智谱 GLM-5.2 已经能够完成一篇包含 54 个代码块、8 张图片和数百个 Gutenberg 区块的 WordPress 技术长文翻译。
最终结果在结构完整性方面表现很好：
- 608 个 Gutenberg 区块签名顺序一致；
- 54 个 Code Block Pro 区块逐字一致；
- 普通正文没有残留中文；
- Polylang 中英文关联正常；
- 英文前台页面可以正常访问。
真正导致失败的两个关键问题分别是：
max_tokens = 256
以及：
MAX_RUNAWAY_OUTPUT_RATIO = 3
将 GLM-5.2 的最大输出提高到 1024，并将适用于中文源文章的长文本增长阈值调整为 6 后，整个翻译流程终于跑通。
目前这套方案已经具备继续测试和优化的基础，但是否能够完全取代 ChatGPT Plus 的人工整篇重译，还需要后续继续观察英文质量与自动化程度。
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
发表回复