标签： WordPress 翻译
-
在使用 SlyTranslate 调用 GLM 5.2 进行 WordPress 整篇文章翻译时，模型重复生成了相邻段落，导致同一个 SWQINLINE 占位符出现两次，并触发 swq_full_article_token_validation_failed。排查确认严格 Token 校验器工作正常，问题并非响应截断或插件逻辑错误。通过完善全文翻译提示词，进一步约束段落唯一性、占位符格式、六位编号及前导零保留后，文章 19445 重新翻译成功。现阶段继续采用“提示词降低错误概率、占位符保护结构、严格校验阻止错误结果”的方案。
-
在暂缓 OpenAI API 测试后，我改为在本地调用 Google Gemini，并使用与 GLM 5.2 相同的标题、摘要和正文样本进行 A/B 对比。测试发现，Gemini 3.5 Flash 的英文表达略显自然，但存在响应波动、技术语义扩展以及正文标题残留中文等问题；Gemini 3.1 Pro Preview 则因免费层级额度为 0，无法完成测试。综合翻译准确性、Gutenberg 结构完整性、接口稳定性、服务器网络和维护成本后，现阶段继续使用 GLM 5.2 作为 SlyTranslate 的生产翻译模型。
-
在完成 SlyTranslate 与智谱 GLM 5.2 的整篇翻译定制后，我进一步申请并接入 DeepSeek API，通过本地脚本对 glm-5.2 与 deepseek-v4-pro 进行了相同内容、相同提示词下的标题、摘要和正文翻译测试。结果显示，DeepSeek V4 Pro 的响应速度明显更快，但在信息完整性、技术表达和 Gutenberg 段落衔接方面，并未表现出稳定优于 GLM 5.2 的质量优势。考虑到现有 GLM 5.2 定制插件已经包含代码区块占位、HTML 与 Gutenberg 结构保护、整篇翻译和内容还原等完整处理流程，当前没有必要再为 DeepSeek 重复投入开发。后续若继续追求更高翻译质量，将优先在本地测试 OpenAI，确认其是否具备足够明显的优势，再决定是否解决阿里云杭州服务器访问 OpenAI API 的网络问题。
-
这篇文章记录了我对 AutoPoly 免费版、Yandex Translate 网页版以及 ChatGPT Plus 整篇翻译流程的一次对比验证。通过浏览器抓包可以确认，AutoPoly 免费版使用 Yandex 时，并不是将整篇 WordPress 文章一次性提交翻译，而是按段落、区块或文本片段分批请求 Yandex。这样虽然有利于保留 Gutenberg 结构、代码块和配置内容，但正文翻译容易缺少上下文，机器翻译感明显。相比之下，Yandex 网页版 Quick translation 的普通正文连贯性略好，但会把代码块和配置块也翻译掉，并且存在长文本限制。最终结论是：AutoPoly 更适合作为 Polylang 结构复制和低价值历史文章初稿工具，高价值英文技术博客仍应继续使用 ChatGPT Plus 整篇重译，后续更值得研究的是如何自动化现有 ChatGPT 翻译流程。