标签： Polylang
-
本文继续记录 WordPress + Polylang 英文站从 /en/ 迁移到 en.shuijingwanwq.com 之后的 CDN 与缓存配置过程。前一篇文章已经解决了源站侧的 Polylang 多域名配置、W3 Total Cache Page Cache 兼容、Redis Object Cache 旧配置缓存等问题。本文重点处理 en.shuijingwanwq.com 接入 Cloudflare、启用 HTML 页面缓存、验证首页与文章页 MISS 到 HIT、确认登录用户 Cookie、REST API、登录页和后台入口不会被缓存，并最终通过 Nginx 将非 www 域名下的后台入口统一 301 到 www.shuijingwanwq.com。
-
本文记录一次将 WordPress + Polylang 英文站从路径模式 /en/ 迁移到独立子域名 en.shuijingwanwq.com 的完整排查过程。迁移过程中并不是简单修改 Polylang URL 设置就结束了，而是连续遇到了 Polylang 保存失败、扩展插件 Fatal Error、W3 Total Cache 将英文子域名误判为 foreign domain 并 301 回主域名、Redis Object Cache 缓存旧语言配置等问题。最终通过修复 Polylang 扩展插件、添加 W3TC 兼容 mu-plugin、清理 Redis 对象缓存，并验证 html lang、canonical、hreflang 和 W3TC 页面缓存文件，完成了英文子域名的源站侧迁移。
-
本文记录了一次在 OneinStack 已有 Nginx 虚拟主机中追加 en.shuijingwanwq.com 子域名，并重新签发包含多个域名的 SSL 证书的实操过程。由于主站已经有稳定访问量，且 Nginx 配置中包含多项自定义规则，作者没有采用“删除虚拟主机后重新添加”的方式，而是选择在现有 vhost 中追加 server_name、调整跳转规则、检查 Nginx 配置、添加 DNS 解析，并通过 acme.sh 重新签发和安装证书。文章也说明了这一步是后续将 WordPress 英文站从 /en/ 迁移到 en.shuijingwanwq.com 的服务器与证书准备工作。
-
这篇文章基于前一篇将 WordPress `/wp-content/uploads/` 媒体库资源迁移到 `media.shuijingwanwq.com + Cloudflare` 的实践，继续分析 EdgeOne 流量成本控制问题。通过 EdgeOne 指标发现，虽然 uploads 图片和附件已经从 EdgeOne 拆出，但 `www.shuijingwanwq.com/en/` 英文路径仍占今日 EdgeOne 流量约三分之一。文章进一步评估了页面缓存、Bot 流量、`/en/` 路径占比、Nginx 现有 301 规则冲突风险，以及将英文站迁移到 `en.shuijingwanwq.com + Cloudflare` 的收益与代价。最终结论是：英文站拆分到子域名有助于显著降低 EdgeOne 流量，但不能仓促执行，需要先确认 Polylang、多语言链接、canonical、hreflang、sitemap、Cloudflare 接入和 301 跳转规则，确保旧 `/en/*` 路径能够一次跳转到最终英文子域名地址。
-
这篇文章记录了一次用 ChatGPT Agent 自动化 WordPress 英文重译流程的真实测试。原本希望 Agent 能替代当前的 ChatGPT Plus 手动重译流程，帮助处理中文文章内容并生成英文标题、摘要和正文。但实际测试发现，Agent 处理长篇 Gutenberg 代码编辑器内容时耗时很长，最终任务耗时约 25 分钟，而且输出结果明显不完整，只覆盖了文章前半部分。相比普通 ChatGPT Plus，Agent 在摘要完整性、正文覆盖范围和 code-block-pro 结构细节上都不够稳定。因此，当前结论是：ChatGPT Agent 暂时不适合作为长篇 WordPress 技术文章的英文翻译主流程，更适合未来尝试用于后台复制、粘贴、保存草稿等网页操作环节。
-
在验证 AutoPoly 免费版与 Yandex 网页版的翻译质量后，我继续评估 AutoPoly Pro + OpenAI API 是否能替代目前的 ChatGPT Plus 手动重译流程。结果发现，真正的问题已经不只是翻译质量，而是包括 Gutenberg 区块保护、OpenAI 请求位置、阿里云服务器访问能力、API 账单支付方式等一整套落地问题。本文记录这次分析过程，以及我为什么暂时没有直接切换到 AutoPoly Pro + OpenAI API 主流程。
-
这篇文章记录了我对 AutoPoly 免费版、Yandex Translate 网页版以及 ChatGPT Plus 整篇翻译流程的一次对比验证。通过浏览器抓包可以确认，AutoPoly 免费版使用 Yandex 时，并不是将整篇 WordPress 文章一次性提交翻译，而是按段落、区块或文本片段分批请求 Yandex。这样虽然有利于保留 Gutenberg 结构、代码块和配置内容，但正文翻译容易缺少上下文，机器翻译感明显。相比之下，Yandex 网页版 Quick translation 的普通正文连贯性略好，但会把代码块和配置块也翻译掉，并且存在长文本限制。最终结论是：AutoPoly 更适合作为 Polylang 结构复制和低价值历史文章初稿工具，高价值英文技术博客仍应继续使用 ChatGPT Plus 整篇重译，后续更值得研究的是如何自动化现有 ChatGPT 翻译流程。
-
本文基于一次 WordPress 多语言博客英文翻译质量对比，实测分析了 Chrome Built-in AI、Yandex Translate 与 ChatGPT Plus 在技术博客英文化中的表现差异。结果显示，自动翻译适合低成本覆盖普通长尾文章，而涉及海外流量、英文 SEO、Carbon Ads 审核、联盟营销和技术咨询转化的重点文章，更适合使用 ChatGPT Plus 进行完整英文重译。
-
针对 WordPress 博客英文翻译质量不佳的问题，文章复盘了从 Polylang 配合 AutoPoly 免费版及 Chrome Built-in AI 向更高质量方案迁移的排查过程。通过在阿里云服务器上测试 DeepL、Google 及 OpenAI 等接口，发现 DeepL 因账号注册地区限制不适合大陆用户，其余则存在网络超时。文章最终放弃更换多语言插件或强行接入 DeepL，决定保留 Polylang 架构，采用普通文章自动翻译、重点文章人工精修的分层策略，以在成本、风险与质量间取得平衡。