标签： Gutenberg
-
在 WordPress 历史文章迁移过程中，将原有流程图内容转换为 MerPress Mermaid 区块后，前台出现 Syntax error in text，并显示 Mermaid 11.9.0。最初将错误的 流程图 TD 修改为 flowchart TD 后问题仍未解决，最终发现关键在于节点文本写法。将 A[节点文本] 统一调整为 A[“节点文本”] 后，包含 test()、main()、go test() 以及中英文混合内容的流程图恢复正常渲染。本文记录完整排查过程，并总结适用于 WordPress 历史内容迁移的 Mermaid 节点编写与验收规则。
-
本文整理了一套每天批量处理 20 篇 WordPress 历史文章的完整流程，包括 SyntaxHighlighter 向 Code Block Pro 迁移、代码语言核对、生产只读验证、中文摘要生成、英文覆盖翻译、有限重试和失败恢复。本次实操还修复了 Plaintext 行数校验过严，以及 Ctrl + S 被误判为 Markdown 列表的问题，最终完成整个批次，并形成可长期复用的操作规范。
-
本文记录了将 WordPress 历史文章中的 Gutenberg SyntaxHighlighter 代码块统一转换为 Code Block Pro，并复用既有中文摘要生成与英文覆盖翻译流程的完整实践。通过生产环境只读扫描、固定批次、人工转换、结构验收和状态恢复，第一批 20 篇文章最终全部完成中文摘要写入与英文覆盖翻译。过程中也暴露出批次执行中的网络超时、状态恢复边界和过度设计问题，并据此确定了后续历史文章的标准化处理方案：不同旧格式只负责识别与转换，转换完成后统一进入现有 Gutenberg + Code Block Pro 执行流程，不再重复建设摘要和翻译管线。
-
本文记录了使用 GLM 4.7、GLM 5.2 与 SlyTranslate，安全补全 42 组 WordPress 中英文历史文章摘要的完整过程。流程通过固定候选清单、写入前备份、内容哈希、Polylang 双向校验、状态持久化、断点恢复与自动重试，应对 GLM 超时、REST 连接中断及 SlyTranslate HTTP 500 等真实故障，最终实现 42/42 完成、待处理 0、异常状态 0。
-
在使用 AI 批量补全 WordPress 历史文章摘要之前，我先建立了一套只读格式审计管线，用于受控导出文章、识别 Classic Editor、Gutenberg、SyntaxHighlighter 和 Code Block Pro 等历史格式，并进行风险分类与候选筛选。项目已完成 3 条、20 条和 100 条生产样本验证，143 个自动化测试全部通过，并以中英文文档形式公开到 GitHub。当前阶段不调用 AI，也不写回 WordPress，重点是先明确格式边界、数据安全和失败保护，为后续长期运行的摘要补全流程建立可靠基础。
-
在持续优化 WordPress 中文技术文章英文翻译流程后，我将相关定制代码、测试脚本、问题分析和生产验证记录整理到 GitHub 私有仓库 wordpress-ai-translation-pipeline。本文记录了仓库创建、本地目录改名、远程绑定、main 分支与标签推送、路径修正、敏感信息审计以及 .gitignore 完善过程。GitHub 的引入让翻译优化工作从临时排查转向可追踪、可回退、可长期维护的工程流程，也标志着本阶段翻译质量优化工作告一段落。
-
在使用 SlyTranslate 调用 GLM 5.2 进行 WordPress 整篇文章翻译时，模型重复生成了相邻段落，导致同一个 SWQINLINE 占位符出现两次，并触发 swq_full_article_token_validation_failed。排查确认严格 Token 校验器工作正常，问题并非响应截断或插件逻辑错误。通过完善全文翻译提示词，进一步约束段落唯一性、占位符格式、六位编号及前导零保留后，文章 19445 重新翻译成功。现阶段继续采用“提示词降低错误概率、占位符保护结构、严格校验阻止错误结果”的方案。
-
在完成 SlyTranslate 与智谱 GLM-5.2 的 WordPress 长文章整篇翻译定制后，英文正文虽然能够正常生成，但实际发布流程仍出现分类、标签、PublishPress Series、Series 部分编号和特色图片未正确迁移等问题。本文根据真实测试过程，记录如何将新英文译文由自动发布调整为草稿，利用 Polylang 将中文 Taxonomy 关系迁移到已建立的英文分类、标签和 Series，并让 PublishPress Series 在人工发布时自动生成顺序编号。同时还修复了 GLM 压缩保护 Token 前导零以及英文特色图片缺失的问题。最终，新英文草稿已经能够保留 Gutenberg 结构，并自动关联正确的分类、标签、Series 和特色图片。中文语言切换器及多域名 Object Cache 失效问题则留待后续单独处理。
-
在暂缓 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 的网络问题。