没有不值得去解决的问题,也没有不值得去学习的技术!

SlyTranslate + GLM-5.2 翻译 WordPress 长文章后,分类、标签、Series 与特色图片同步问题排查

图5:英文文章发布后,前台特色图片、分类、标签和 Series 顺序均正常

作者:

WordPress AI 翻译工程实战

WordPress 经典编辑器代码块无损迁移:批量转换 SyntaxHighlighter 短代码为 Gutenberg 区块

(1) WordPress 经典编辑器代码块无损迁移:批量转换 SyntaxHighlighter 短代码为 Gutenberg 区块

点击翻译按钮后,遇到一个弹窗“神秘”闪退问题及解决方法

(2) 点击翻译按钮后,遇到一个弹窗“神秘”闪退问题及解决方法

图5:DeepL API 注册页面,国家或地区列表中没有中国大陆

(3) 中国大陆 WordPress 博客想提升英文翻译质量,为什么这么麻烦?一次 Polylang + AutoPoly + DeepL API 排查复盘

图5:DeepSeek 的评分结果截图

(4) Chrome Built-in AI、Yandex Translate、ChatGPT Plus 翻译质量对比:我为什么决定重点英文文章改用 ChatGPT Plus

[截图 2:浏览器 Network 中直接请求 translate.yandex.net]

(5) 从 AutoPoly 到 Yandex 网页版:一次 WordPress 英文自动翻译质量验证

【图1:AutoPoly Free 与 Pro 功能对比截图】

(6) AutoPoly Pro + OpenAI API 能否自动化 WordPress 英文翻译?一次从技术到支付的可行性分析

【图2:点击“立即试用”后,ChatGPT 输入框中出现“代理模式”】

(7) ChatGPT Agent 能否替代 ChatGPT Plus 完成 WordPress 英文重译?

【图 7,SlyTranslate 显示翻译完成并创建文章 19426】

(8) SlyTranslate + 智谱 GLM-5.2 长文翻译排障:从 600 秒超时到完整生成英文 WordPress 文章

【图 5,54 个代码块精确匹配、差异数量为 0】

(9) WordPress SlyTranslate + GLM-5.2 长文单次翻译实战:排查 invalid_translation_runaway_output 假失败

【图 2,SlyTranslate 的 Additional Instructions 保持为空】

(10) SlyTranslate + GLM-5.2 翻译质量继续优化:从关闭随机采样、内置提示词到深度思考与模型 A/B 测试

【图6,终端中的完整测试结果】

(11) 在 GLM 5.2 之后测试 DeepSeek:一次面向 WordPress 长文翻译的模型对比与取舍

【图 4,“英文博客翻译质量优化”项目中已经整理完成的会话列表】

(12) 为英文博客翻译质量优化建立独立 ChatGPT 项目:整理历史会话并统一后续评测标准

【图3:Gemini 3.5 Flash 首次成功调用结果】

(13) 暂缓 OpenAI 后,我在本地测试了 Gemini:与 GLM 5.2 的 WordPress 技术文章翻译对比

图3:清理英文 Host 下的对象与术语关系缓存后,英文文章重新显示 SEO Tools、Yoast SEO 和 Blog SEO Log

(14) 为 SlyTranslate 的 GLM 5.2 整篇翻译补上 Plaintext 智能处理,并修复 Code Block Pro 区块失效

图5:英文文章发布后,前台特色图片、分类、标签和 Series 顺序均正常

(15) SlyTranslate + GLM-5.2 翻译 WordPress 长文章后,分类、标签、Series 与特色图片同步问题排查

图1:Codex 输出 Token 校验诊断结果

(16) SlyTranslate 全文翻译报错排查:完善 GLM 5.2 的段落与占位符约束

图1:创建 wordpress-ai-translation-pipeline 私有 GitHub 仓库

(17) 将 WordPress AI 翻译优化项目提交到 GitHub:一次阶段性的收尾

图1:文章列表中因摘要为空而重复出现两个 Post Views

(18) 从空摘要、历史格式混杂到重新翻译:我如何规划 WordPress AI 翻译工程的下一阶段

图4:最终批处理输出 42/42 完成、待处理 0、异常状态 0。

(19) 从只读审计到 42/42 完成:用 GLM 与 SlyTranslate 安全补全 WordPress 历史文章摘要

图3:GitHub 已正确识别仓库的 MIT License。

(20) 将 WordPress AI 翻译优化仓库从私有切换为公共:从敏感信息审计到最小改动发布

图1:仓库显示所有历史批次已经完成,并允许创建下一批。

(21) 每天批量处理 20 篇 WordPress 历史文章:代码块迁移、摘要补全与英文覆盖翻译完整 SOP

图 2:复杂 Classic 一次转换成多个 Gutenberg 区块

(22) 每天批量处理 20 篇 Mixed WordPress 历史文章:Classic 转 Gutenberg、SyntaxHighlighter 迁移、摘要补全与英文覆盖翻译完整 SOP

GLM-5.2 整篇翻译再次出现 Protected Token 校验失败:从尾部 Token 丢失到 Plaintext 结构重排的完整排查记录

(23) GLM-5.2 整篇翻译再次出现 Protected Token 校验失败:从尾部 Token 丢失到 Plaintext 结构重排的完整排查记录

图 1:历史文章 4652 在 GLM-5.2 整篇翻译时返回 HTTP 400 安全检测错误

(24) GLM-5.2 整篇翻译持续返回 HTTP 400:从安全检测拦截到 Plaintext 载荷缩减的完整排查与修复

图 1:历史文章批处理返回 HTTP 400,并提示内容安全检查未通过。

(25) GLM-5.2 整篇翻译返回 400:一次内容安全误拦截的逐步定位与恢复记录

图 5:文章最终已经 completed,但原来的 excerpt_generation_failed、HTTP 400 和人工完成记录同时保留。

(26) WordPress 历史文章自动化遇到 GLM 1301:从 HTTP 400 到 ChatGPT 人工兜底完成

图 1:index 814 的 INLINE Token 换序及中英文 Gutenberg 对照

(27) WordPress AI 翻译排错实战:一次合法的行内代码换序,为什么会阻断尾部结构自动修复?

图 1:完整文章首次整篇翻译失败,SlyTranslate 返回受保护标记校验错误

(28) WordPress 超长 Gutenberg 文章整篇 AI 翻译踩坑:从 1000+ 受保护标记到完整翻译成功

【图1:历史文章迁移最终状态,67 个固定批次、1281 篇文章全部完成】

(29) WordPress 历史文章迁移终于收尾:全量审计 1438 篇中文文章,并停用 SyntaxHighlighter Evolved

在完成 SlyTranslate 与智谱 GLM-5.2 的整篇文章翻译定制后,长文章正文已经可以一次性翻译,Gutenberg 区块结构、HTML、代码块、URL 和命令等内容也能够得到保护。

不过,继续测试真实 WordPress 文章后,我发现:

正文翻译成功,只代表英文内容已经生成,并不代表英文文章已经具备完整的 WordPress 发布条件。

除正文外,一篇英文译文还需要正确处理:

  • Polylang 中英文文章关系;
  • 分类与标签的语言对应关系;
  • PublishPress Series 系列关系;
  • Series 部分编号;
  • 特色图片;
  • 草稿与发布状态;
  • 多域名环境下的对象缓存和页面缓存;
  • 中英文页面语言切换器。

本轮排查的重点,不再是 GLM-5.2 的翻译质量,而是英文译文生成后的 WordPress 数据迁移与发布生命周期。


一、当前网站环境

本次测试环境如下:

  • WordPress;
  • 中文站:https://www.shuijingwanwq.com
  • 英文站:https://en.shuijingwanwq.com
  • 后台域名:https://admin.shuijingwanwq.com
  • 多语言插件:Polylang;
  • 翻译插件:SlyTranslate;
  • 翻译模型:智谱 GLM-5.2;
  • 系列插件:PublishPress Series;
  • 页面缓存:W3 Total Cache Page Cache;
  • 对象缓存:W3 Total Cache Object Cache,通过 Redis 保存;
  • 中文站 CDN:EdgeOne;
  • 英文站 CDN:Cloudflare;
  • 自定义翻译兼容逻辑:MU Plugin。

此前对 SlyTranslate 进行的定制,主要解决了以下问题:

  1. 将整篇 Gutenberg 内容作为一个完整请求发送给 GLM-5.2;
  2. 保护代码块、HTML、URL、命令、路径和 Gutenberg 区块结构;
  3. 避免长文章被拆成多个片段分别翻译;
  4. 保留文章正文的区块顺序;
  5. 对模型返回结果中的保护 Token 进行严格校验。

当时的新英文译文默认会直接发布。

而本轮排查后,才进一步将流程调整为:

新生成的英文译文先保存为草稿,待分类、标签、Series、特色图片等数据确认后,再由人工发布。


二、正文翻译正常,但英文文章数据并不完整

早期测试中,英文正文能够正常生成,但部分译文存在以下问题:

  • 英文文章没有关联完整的英文分类;
  • 英文标签缺失;
  • PublishPress Series 没有关联;
  • Series 顺序错误地显示为第 1 篇;
  • 特色图片为空;
  • 中文页面没有显示英文语言切换器;
  • 数据库已经更新,但英文前台仍可能读取旧对象。

这些问题并不是由同一个原因造成的。

其中既包括:

  • 翻译流程没有处理的数据;
  • Polylang 英文 Term 尚未建立;
  • 英文文章发布时机不正确;
  • PublishPress Series 自动编号 Hook 没有按预期触发;
  • 多域名 Object Cache 读取旧值;
  • W3TC Page Cache 或 CDN 保存了旧 HTML。

因此,不能简单地把所有异常都归因于 GLM、SlyTranslate 或 Redis。


三、为什么不能让新英文译文直接发布

最初的翻译请求中,传入的状态为:

JSON
{
  "input": {
    "model_slug": "glm-5.2",
    "overwrite": false,
    "post_id": 19419,
    "post_status": "publish",
    "source_language": "zh",
    "target_language": "en",
    "translate_title": true
  }
}

旧流程会在翻译完成后直接发布英文文章。

但 PublishPress Series 会在文章从草稿切换为发布状态时,通过 draft_to_publish 等 Hook 自动分配 Series 部分编号。

如果英文文章先发布,之后才迁移 Series 关系,事件顺序就可能变成:

Plaintext
创建英文文章并直接发布

PublishPress Series 检查文章所属系列

此时英文 Series 关系尚未完成

无法为文章生成 Series part

翻译流程稍后才关联英文 Series

最终,文章虽然已经属于某个 Series,但可能缺少:

Plaintext
_series_part_<Series term ID>

缺少部分编号后,PublishPress Series 前台列表可能将该文章作为未编号文章处理,并错误地排在第一项。

因此,本轮首先调整了文章状态策略:

Plaintext
新英文译文:保存为 draft
已有英文译文:保留当前状态

这样,英文文章会先完整建立分类、标签和 Series 关系,再由人工发布。

图1:新的英文译文生成后,文章状态为 Draft
图1:新的英文译文生成后,文章状态为 Draft

四、分类、标签和 Series 不是简单复制,而是迁移对应关系

在 Polylang 环境下,中文分类和英文分类是两个不同的 Term。

例如:

Plaintext
中文分类:智谱 AI
英文分类:Zhipu AI

它们拥有不同的 Term ID,但在 Polylang 中建立了语言翻译关系。

因此,英文文章不能直接使用中文文章的 Term ID,也不应该仅根据中文名称临时创建一个英文 Term。

正确的迁移过程是:

  1. 读取中文文章关联的分类、标签和 Series;
  2. 通过 Polylang 查询每个中文 Term 对应的 English Term;
  3. 将英文文章自动关联到这些已经提前翻译和创建好的英文分类、标签和 Series;
  4. 如果某个中文 Term 尚未建立英文对应项,则不自动猜测或创建新 Term。

这更准确地说是:

将中文文章的 Taxonomy 关系迁移到对应的英文 Taxonomy,而不是复制中文 Term 本身。


五、缺少英文分类时,不应自动创建重复分类

在文章 19429 的测试中,中文文章包含两个分类:

  • SlyTranslate;
  • 智谱 AI。

生成英文草稿 19522 后:

  • Zhipu AI 成功迁移并关联;
  • SlyTranslate 没有出现在英文文章中。

检查后确认,当时 English 语言下尚未建立对应的 SlyTranslate 分类。

因此,这不是系统漏掉了一个已经存在的英文分类,而是 Polylang 中没有可供迁移的 English Term。

这符合当前的安全策略:

Plaintext
存在明确的英文 Term
→ 自动关联到英文文章

不存在英文 Term
→ 不创建、不猜测、不使用中文 Term

这样可以避免出现以下问题:

  • 同名分类被重复创建;
  • Slug 不一致;
  • 大小写不同导致重复;
  • 中文分类被错误分配给英文文章;
  • Polylang 分类翻译关系失控。

后续需要在 English 语言下提前创建并关联 SlyTranslate 分类,再进行文章翻译。


六、草稿阶段没有 Series 部分编号属于正常现象

修复状态流程后,中文文章 19419 成功生成英文译文 19519

检查结果如下:

Plaintext
中文文章 ID:19419
英文文章 ID:19519
英文文章状态:draft

英文草稿中的数据包括:

  • Polylang 中英文文章关系正常;
  • 英文分类迁移正常;
  • 9 个英文标签全部迁移成功;
  • 英文 Series 关联正常;
  • Series part 为空。

这里的 Series part 为空并不是故障。

因为 PublishPress Series 的部分编号,应当在文章正式发布时自动生成。

正确的生命周期是:

Plaintext
生成英文草稿

迁移并关联英文分类

迁移并关联英文标签

迁移并关联英文 Series

人工检查英文文章

手动发布

PublishPress Series 自动生成 part
图2:英文草稿已经关联正确的 Series,但“当前部分”显示为无部分编号
图2:英文草稿已经关联正确的 Series,但“当前部分”显示为无部分编号

文章 19519 发布后,数据库中的 Series part 自动变为:

Plaintext
22

该英文 Series 原有最大编号为 21,因此新文章取得编号 22,符合顺序追加规则。

图3:英文文章手动发布后,PublishPress Series 自动生成部分编号
图3:英文文章手动发布后,PublishPress Series 自动生成部分编号

七、保护 Token 中连续零被 GLM 压缩

在翻译中文文章 19419 时,接口曾返回:

JSON
{
  "code": "swq_full_article_token_validation_failed",
  "message": "Protected token validation failed: expected=628, actual=627, fixed_order=no. Diagnostic: /tmp/swq-glm52-token-validation-summary.json",
  "data": null
}

诊断结果显示,预期 Token 是:

Plaintext
SWQSTRUCT000018END

GLM 返回的是:

Plaintext
SWQSTRUCT00018END

模型将连续的前导零压缩了一个。

这个 Token 对应的原始 Gutenberg 内容为:

HTML
<!-- /wp:heading -->

GLM 返回片段为:

Plaintext
SWQSTRUCT000017END
<h2 class="wp-block-heading">1. The Initial Cooperation Invitation</h2>
SWQSTRUCT00018END

SWQSTRUCT000019END

这并不是整个 Gutenberg 结构被删除,而是模型修改了保护 Token 的数字格式。

现有严格校验阻止了这次错误内容写入 WordPress。否则在恢复结构时,可能无法找到正确 Token,最终造成区块结束注释丢失。


八、对畸形 Token 进行有限且安全的修复

最终没有选择跳过校验,也没有简单放宽 Token 正则。

新增的处理方式是:

只有当畸形 Token 能唯一对应一个预期 Token 时,才允许进行规范化。

必须同时满足:

  • Token 类型相同;
  • 数字部分去掉前导零后的值相同;
  • 只能匹配一个缺失的预期 Token;
  • 不存在重复 Token;
  • 不存在多个候选项;
  • 修复后的顺序正确;
  • 修复后再次通过完整严格校验。

例如:

Plaintext
SWQSTRUCT00018END

可以唯一恢复为:

Plaintext
SWQSTRUCT000018END

但如果存在歧义、重复或顺序错误,翻译仍然终止。

测试结果如下:

Plaintext
PASS: zero contraction is repaired
PASS: correct token remains unchanged
PASS: ambiguous candidates fail
PASS: duplicate token fails
PASS: wrong fixed order fails

修复后,文章 19419 成功生成英文草稿 19519


九、特色图片没有随英文文章一起迁移

继续测试文章 19429 时,英文正文、分类、标签和 Series 已经正常,但英文草稿没有特色图片。

只读检查结果如下:

Plaintext
中文文章 ID:19429
中文特色图片 attachment ID:19437
图片 URL:https://media.shuijingwanwq.com/2026/07/7-18.png
附件语言:zh
英文附件翻译:不存在

英文文章 ID:19522
英文特色图片:空

这说明特色图片关系没有在英文文章创建阶段同步。

WordPress 的特色图片通过 _thumbnail_id 关联 Attachment。正文迁移、Taxonomy 迁移和 Series 迁移都不会自动补齐该关系。


十、特色图片迁移规则

新增特色图片处理逻辑后,采用以下规则:

  1. 英文目标文章已经有特色图片时,不覆盖;
  2. 中文源文章没有特色图片时,英文文章保持为空;
  3. 中文特色图片存在明确的英文 Polylang 附件时,优先使用英文附件;
  4. 不存在英文附件时,允许英文文章复用中文 Attachment;
  5. 使用 set_post_thumbnail() 建立关系,不直接执行原始 SQL。

文章 19429 没有对应的英文附件,因此英文文章 19522 复用了:

Plaintext
Attachment ID:19437

测试结果如下:

Plaintext
PASS: source image without English attachment is reused
PASS: English attachment translation is preferred
PASS: existing target image is not overwritten
PASS: source without image leaves target empty

完成该修复后,又重新选择一篇新文章进行验证,英文草稿已经能够正常显示特色图片。


十一、为什么不直接迁移全部 Post Meta

虽然特色图片依赖 Post Meta,但不能直接将中文文章的所有元数据批量迁移到英文文章。

Post Meta 中可能包含:

  • SEO 插件配置;
  • 编辑器内部状态;
  • 页面构建器数据;
  • 缓存结果;
  • 插件临时字段;
  • 与中文文章 ID 绑定的关系;
  • 中文域名和中文 URL;
  • 语言相关运行数据。

无条件迁移全部 Post Meta,可能将中文文章中的错误 ID、旧 URL 或插件状态带入英文文章。

因此,本次仍采用白名单方案:

Plaintext
明确迁移文章关系
明确迁移分类关系
明确迁移标签关系
明确迁移 Series 关系
明确迁移特色图片
Series part 由 PublishPress 在发布时生成
其他 Post Meta 不默认迁移

这种方式虽然需要逐项验证,但风险更低,也更容易回滚。


十二、完整的新文章测试流程

完成修复后,又选择了一篇同时包含以下数据的中文文章进行测试:

  • 分类;
  • 标签;
  • Series;
  • 特色图片。

测试流程为:

  1. 使用 SlyTranslate + GLM-5.2 执行整篇翻译;
  2. 自动生成英文草稿;
  3. 在后台检查英文草稿;
  4. 确认英文分类、标签和 Series 已正确关联;
  5. 确认特色图片已经存在;
  6. 确认草稿阶段没有 Series part;
  7. 不访问英文预览 URL;
  8. 直接手动发布;
  9. 首次访问正式英文 URL;
  10. 检查前台数据和 Series 顺序。

英文草稿检查结果:

  • 英文正文正常;
  • 分类关联正常;
  • 标签关联正常;
  • Series 关联正常;
  • 特色图片正常;
  • Series part 为空,符合草稿状态预期。
图4:修复后新生成的英文草稿,分类、标签、Series 与特色图片均正常
图4:修复后新生成的英文草稿,分类、标签、Series 与特色图片均正常

发布后的结果:

  • 英文正式页面可以正常访问;
  • 特色图片正常;
  • 分类正常;
  • 标签正常;
  • Series 正常;
  • PublishPress Series 自动生成 part;
  • 后台和英文前台的 Series 编号一致;
  • 新文章没有错误地排在 Series 第 1 篇。
图5:英文文章发布后,前台特色图片、分类、标签和 Series 顺序均正常
图5:英文文章发布后,前台特色图片、分类、标签和 Series 顺序均正常

十三、英文草稿预览与多 Host 对象缓存

在文章 19519 的测试中,还出现过以下现象:

Plaintext
数据库 Series part:22
admin Host 读取结果:22
en Host 读取结果:空

英文前台因此一度将文章错误地排在 Series 第一项。

该文章在正式发布前访问过:

Plaintext
https://en.shuijingwanwq.com/?p=19519&preview=true

当时页面返回 404。

虽然没有生成正常的公开文章页面,但 en Host 仍可能提前读取并缓存:

  • 草稿文章状态;
  • 空的 Series part;
  • 尚未完成的文章对象和 Post Meta。

随后文章通过 admin.shuijingwanwq.com 发布。

由于 W3TC Object Cache 的 Key 与 Host 有关,后台 Host 清理的对象缓存不一定覆盖英文 Host 已保存的旧对象。

精确清理 en Host 中文章 19519 的对象缓存后:

Plaintext
post status:publish
Series part:22

重新生成英文 W3TC Page Cache 后,文章不再排在 Series 第一项。

不过,在后续的新文章测试中,只要不访问英文草稿预览 URL,就没有再次出现该问题。

因此,目前更稳妥的临时流程是:

英文草稿生成后在后台检查数据,不访问英文前台预览地址,确认无误后直接发布。

多 Host Object Cache 的长期兼容问题,后续再作为独立缓存问题处理,不继续加入翻译插件。


十四、中文文章的语言切换器仍可能未及时更新

最后一次新文章测试中,英文文章已经正常,但对应中文文章页面暂时没有显示英文语言切换器。

这一问题没有继续在本轮处理。

因为中文语言切换器异常还可能涉及:

  • Polylang 运行时关系;
  • 中文 Host Object Cache;
  • W3TC Page Cache;
  • EdgeOne CDN;
  • 中文页面此前生成的旧 HTML。

当前英文文章本身已经可以正常生成和发布,因此没有必要继续扩大本轮修改范围。

图6:英文文章已经正常发布,但对应中文文章暂时没有显示英文语言切换器

这一问题将作为后续独立任务处理。


十五、最终形成的英文译文流程

经过本轮调整,目前的英文文章生成流程为:

Plaintext
中文文章

SlyTranslate + GLM-5.2 整篇翻译

生成英文草稿

建立 Polylang 中英文文章关系

迁移并关联已有的英文分类

迁移并关联已有的英文标签

迁移并关联对应的英文 Series

迁移特色图片

人工后台检查

手动发布

PublishPress Series 自动生成部分编号

访问正式英文文章

其中需要提前准备的是:

  • 中文分类已经存在对应的英文分类;
  • 中文标签已经存在对应的英文标签;
  • 中文 Series 已经存在对应的英文 Series;
  • 这些 Term 已经通过 Polylang 建立语言关联。

翻译流程不会自动创建缺少的英文分类、标签或 Series。


十六、本轮已经解决的问题

本轮已经完成以下调整:

  • 新英文译文由自动发布改为保存为草稿;
  • Polylang 中英文文章关系可以正常建立;
  • 中文分类关系能够迁移到对应的英文分类;
  • 中文标签关系能够迁移到对应的英文标签;
  • 中文 Series 关系能够迁移到对应的英文 Series;
  • 草稿发布后,PublishPress Series 可以自动生成部分编号;
  • GLM 压缩保护 Token 前导零的问题得到安全修复;
  • 特色图片能够自动迁移;
  • 已经人工设置的英文特色图片不会被覆盖;
  • 缺少英文 Term 时不会自动创建重复 Taxonomy;
  • 新英文文章的正文、分类、标签、Series 和特色图片均已通过实际测试。

十七、仍待处理的问题

当前仍有以下问题需要后续继续排查:

  • 对应中文文章的语言切换器可能没有及时出现;
  • 英文草稿预览可能提前写入旧的 Host 对象缓存;
  • adminwwwen 之间的跨 Host Object Cache 精确失效机制;
  • 没有英文对应项的分类、标签和 Series 需要提前人工建立;
  • 中文页面可能仍保留旧的 Series 顺序或语言关系缓存。

这些问题不再继续堆积到 SlyTranslate 翻译流程中,而应分别交给 Polylang 数据管理和多域名缓存兼容逻辑处理。


十八、阶段性结论

这次排查说明,WordPress 自动翻译不能只关注正文内容。

一篇可以正常发布的英文译文,至少需要处理:

Plaintext
正文结构
+ Polylang 文章关系
+ 分类关系迁移
+ 标签关系迁移
+ Series 关系迁移
+ Series part 发布生命周期
+ 特色图片
+ 草稿与发布状态
+ Object Cache
+ Page Cache
+ CDN

其中,翻译流程应负责:

  • 创建英文文章;
  • 写入英文正文;
  • 建立中英文文章关系;
  • 将中文 Taxonomy 关系迁移到已经存在的对应 English Term;
  • 迁移特色图片;
  • 将新英文文章保存为草稿。

PublishPress Series 继续负责正式发布时的自动编号。

多域名 Object Cache、W3TC Page Cache 与 CDN 缓存失效,则应由独立的缓存兼容机制处理。

目前,SlyTranslate + GLM-5.2 已经从“能够翻译整篇 WordPress 正文”,推进到“能够生成包含分类、标签、Series 和特色图片的完整英文草稿”。

剩余的中文语言切换器与跨 Host 缓存问题,将在后续继续处理。

为 SlyTranslate 的 GLM 5.2 整篇翻译补上 Plaintext 智能处理,并修复 Code Block Pro 区块失效 SlyTranslate 全文翻译报错排查:完善 GLM 5.2 的段落与占位符约束

需要长期技术维护或远程问题排查?

我是拥有 15+ 年经验的 PHP / Go 后端工程师,长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况,可以先从一次小问题排查开始合作:

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看:关于我 & 合作

微信:13980074657
邮箱:shuijingwanwq@gmail.com
Telegram:@shuijingwan
GitHub:https://github.com/shuijingwan