系列： WordPress AI 翻译工程实战
-
针对 Polylang 翻译插件在处理经典编辑器短代码时导致代码格式错乱的问题，文章提出将 SyntaxHighlighter 短代码批量转换为 Gutenberg 区块。通过编写 PHP 函数集成到 WordPress 批量操作，避免了正则表达式和自动转义引发的符号丢失，实现了三十多种编程语言的无损迁移。经测试，转换后的代码块在重新翻译后能保持格式完整。
-
本文介绍了在使用 Polylang 配合 AutoPoly 插件为 WordPress 博客添加多语言支持时，遇到的翻译弹窗闪退问题。排查发现文章标题中包含的 PHP 标记导致插件解析失败。通过将标题修改为普通文本，消除了特殊符号干扰，最终解决了弹窗自动关闭的故障，使翻译功能恢复正常。
-
针对 WordPress 博客英文翻译质量不佳的问题，文章复盘了从 Polylang 配合 AutoPoly 免费版及 Chrome Built-in AI 向更高质量方案迁移的排查过程。通过在阿里云服务器上测试 DeepL、Google 及 OpenAI 等接口，发现 DeepL 因账号注册地区限制不适合大陆用户，其余则存在网络超时。文章最终放弃更换多语言插件或强行接入 DeepL，决定保留 Polylang 架构，采用普通文章自动翻译、重点文章人工精修的分层策略，以在成本、风险与质量间取得平衡。
-
本文基于一次 WordPress 多语言博客英文翻译质量对比，实测分析了 Chrome Built-in AI、Yandex Translate 与 ChatGPT Plus 在技术博客英文化中的表现差异。结果显示，自动翻译适合低成本覆盖普通长尾文章，而涉及海外流量、英文 SEO、Carbon Ads 审核、联盟营销和技术咨询转化的重点文章，更适合使用 ChatGPT Plus 进行完整英文重译。
-
这篇文章记录了我对 AutoPoly 免费版、Yandex Translate 网页版以及 ChatGPT Plus 整篇翻译流程的一次对比验证。通过浏览器抓包可以确认，AutoPoly 免费版使用 Yandex 时，并不是将整篇 WordPress 文章一次性提交翻译，而是按段落、区块或文本片段分批请求 Yandex。这样虽然有利于保留 Gutenberg 结构、代码块和配置内容，但正文翻译容易缺少上下文，机器翻译感明显。相比之下，Yandex 网页版 Quick translation 的普通正文连贯性略好，但会把代码块和配置块也翻译掉，并且存在长文本限制。最终结论是：AutoPoly 更适合作为 Polylang 结构复制和低价值历史文章初稿工具，高价值英文技术博客仍应继续使用 ChatGPT Plus 整篇重译，后续更值得研究的是如何自动化现有 ChatGPT 翻译流程。
-
在验证 AutoPoly 免费版与 Yandex 网页版的翻译质量后，我继续评估 AutoPoly Pro + OpenAI API 是否能替代目前的 ChatGPT Plus 手动重译流程。结果发现，真正的问题已经不只是翻译质量，而是包括 Gutenberg 区块保护、OpenAI 请求位置、阿里云服务器访问能力、API 账单支付方式等一整套落地问题。本文记录这次分析过程，以及我为什么暂时没有直接切换到 AutoPoly Pro + OpenAI API 主流程。
-
这篇文章记录了一次用 ChatGPT Agent 自动化 WordPress 英文重译流程的真实测试。原本希望 Agent 能替代当前的 ChatGPT Plus 手动重译流程，帮助处理中文文章内容并生成英文标题、摘要和正文。但实际测试发现，Agent 处理长篇 Gutenberg 代码编辑器内容时耗时很长，最终任务耗时约 25 分钟，而且输出结果明显不完整，只覆盖了文章前半部分。相比普通 ChatGPT Plus，Agent 在摘要完整性、正文覆盖范围和 code-block-pro 结构细节上都不够稳定。因此，当前结论是：ChatGPT Agent 暂时不适合作为长篇 WordPress 技术文章的英文翻译主流程，更适合未来尝试用于后台复制、粘贴、保存草稿等网页操作环节。
-
本文记录了在 WordPress 中使用 SlyTranslate 接入智谱 GLM-5.2 翻译技术长文时，从连续 504 超时到最终成功生成英文文章的完整排障过程。经日志分析发现，主要问题分别是模型请求的 `max_tokens` 被限制为 256，导致大量译文以 `finish_reason=length` 被截断，以及 SlyTranslate 使用三倍字符长度判断失控生成，对中文翻译为英文产生误判。通过 MU Plugin 将 GLM-5.2 的最小输出上限调整为 1024、关闭思考模式，并将长文本增长阈值由 3 调整为 6 后，翻译任务在约 9 分钟内完成。最终生成的英文文章保留了全部 Gutenberg 区块顺序、图片、列表和 54 个 Code Block Pro 代码块，普通正文无中文残留，Polylang 关联及英文前台访问均正常。当前方案已经解决长文翻译的稳定性与结构完整性问题，但英文自然度和术语准确性仍有进一步优化空间。
-
本文记录在 WordPress、Polylang 与 SlyTranslate 环境中，使用智谱 GLM-5.2 对包含大量 Gutenberg 区块和 Code Block Pro 代码块的技术长文进行正文单次翻译的完整排查过程。最初后台返回 invalid_translation_runaway_output，但执行轨迹显示正文其实只调用模型一次，并已成功保存英文文章。真正原因是自定义翻译完成后，SlyTranslate 原始 REST 回调又继续执行。通过将接管入口从 rest_request_before_callbacks 调整为 rest_dispatch_request，最终避免重复翻译，同时验证了 54 个代码块逐字一致、Gutenberg 结构完整、正文无中文漏译，翻译质量也明显优于原生分块流程。
-
本文记录在 SlyTranslate + 智谱 GLM-5.2 一次性全文翻译方案基础上，继续优化 WordPress 技术文章英文质量的完整过程。通过关闭随机采样、修复标题与摘要未接收附加提示词的问题，并将标题、摘要、正文及目标语言规则内置到 MU Plugin，减少了后台重复配置。随后使用智谱官方 API 对深度思考与 GLM-4.7-FlashX 进行 A/B 测试，结果显示深度思考成本明显增加但质量提升不稳定，FlashX 虽然更快但准确性较低。最终确定以 GLM-5.2、关闭深度思考、关闭随机采样和内置多字段提示词作为当前稳定方案。