After customizing SlyTranslate to translate complete articles with Zhipu GLM-5.2, long-form content could be translated in a single request while preserving Gutenberg block structure, HTML, code blocks, URLs, commands, and other protected content.
However, further testing with real WordPress posts revealed an important limitation:
A successful body translation only means that the English content has been generated. It does not mean that the English post is fully ready for publication in WordPress.
Beyond the post body, an English translation also needs to handle the following correctly:
- the relationship between the Chinese and English posts in Polylang;
- language mappings for categories and tags;
- the PublishPress Series association;
- the Series part number;
- the featured image;
- draft and publication status;
- object cache and page cache behavior in a multi-domain environment;
- the language switcher on the Chinese and English pages.
The focus of this round of troubleshooting was no longer GLM-5.2 translation quality, but the WordPress data migration and publication lifecycle that follow the creation of an English translation.
1. Current Site Environment
The test environment was as follows:
- WordPress;
- Chinese site:
https://www.shuijingwanwq.com; - English site:
https://en.shuijingwanwq.com; - admin domain:
https://admin.shuijingwanwq.com; - multilingual plugin: Polylang;
- translation plugin: SlyTranslate;
- translation model: Zhipu GLM-5.2;
- series plugin: PublishPress Series;
- page cache: W3 Total Cache Page Cache;
- object cache: W3 Total Cache Object Cache, stored in Redis;
- Chinese-site CDN: EdgeOne;
- English-site CDN: Cloudflare;
- custom translation compatibility logic: an MU plugin.
The earlier SlyTranslate customization primarily addressed the following requirements:
- send the complete Gutenberg post to GLM-5.2 as a single request;
- protect code blocks, HTML, URLs, commands, paths, and Gutenberg block structure;
- avoid splitting long posts into separately translated fragments;
- preserve the order of blocks in the post body;
- strictly validate protected tokens in the model response.
At that stage, newly generated English translations were published immediately by default.
This round of troubleshooting led to a further change in the workflow:
A newly generated English translation is first saved as a draft. It is published manually only after its categories, tags, Series association, featured image, and other data have been verified.
2. The Body Was Translated Correctly, but the English Post Data Was Incomplete
In the early tests, the English body was generated correctly, but some translated posts had the following problems:
- the English post was not assigned all of the correct English categories;
- English tags were missing;
- the PublishPress Series association was missing;
- the post was incorrectly shown as the first item in the Series;
- the featured image was empty;
- the Chinese page did not display the English language-switcher option;
- the database had been updated, but the English front end could still read stale objects.
These problems did not share a single cause.
They involved a combination of factors, including:
- data that the translation workflow did not yet handle;
- missing English terms in Polylang;
- incorrect timing for publishing the English post;
- PublishPress Series automatic-numbering hooks not firing as expected;
- stale values being read from the multi-domain object cache;
- stale HTML stored in W3TC Page Cache or the CDN.
It would therefore be inaccurate to attribute every issue to GLM, SlyTranslate, or Redis.
3. Why New English Translations Should Not Be Published Immediately
The original translation request passed the following post status:
{
"input": {
"model_slug": "glm-5.2",
"overwrite": false,
"post_id": 19419,
"post_status": "publish",
"source_language": "zh",
"target_language": "en",
"translate_title": true
}
}
Under the old workflow, the English post was published immediately after translation.
However, PublishPress Series assigns a Series part number when a post moves from draft to published, using hooks such as draft_to_publish and related hooks.
If the English post is published before its Series relationship is migrated, the events may occur in the following order:
创建英文文章并直接发布
↓
PublishPress Series 检查文章所属系列
↓
此时英文 Series 关系尚未完成
↓
无法为文章生成 Series part
↓
翻译流程稍后才关联英文 Series
As a result, the post may belong to a Series but still be missing:
_series_part_<Series term ID>
Without a part number, the PublishPress Series front-end list may treat the post as unnumbered and incorrectly place it first.
The first change in this round was therefore the post-status strategy:
新英文译文：保存为 draft
已有英文译文：保留当前状态
This allows the English post to receive its categories, tags, and Series association before it is published manually.
4. Categories, Tags, and Series Require Relationship Mapping, Not Direct Copying
In a Polylang environment, a Chinese category and its English counterpart are two different terms.
For example:
中文分类：智谱 AI
英文分类：Zhipu AI
They have different term IDs, but Polylang links them as translations of each other.
The English post must not use the Chinese post’s term IDs directly, and the workflow should not create an English term on the fly based only on the Chinese name.
The correct migration process is:
- read the categories, tags, and Series assigned to the Chinese post;
- use Polylang to find the English term mapped to each Chinese term;
- automatically assign the English post to those previously created and translated English categories, tags, and Series terms;
- if a Chinese term has no English counterpart, do not guess or create a new term automatically.
More precisely, the process is:
Migrate the Chinese post’s taxonomy relationships to the corresponding English taxonomy terms rather than copying the Chinese terms themselves.
5. Missing English Categories Should Not Trigger Automatic Duplicate Creation
When testing post 19429, the Chinese post had two categories:
- SlyTranslate;
- Zhipu AI.
After English draft 19522 was generated:
Zhipu AIwas mapped and assigned successfully;SlyTranslatedid not appear on the English post.
Further inspection confirmed that no corresponding SlyTranslate category had yet been created for the English language.
The system had not failed to assign an existing English category; Polylang simply had no English term available for migration.
This behavior matches the current safety policy:
存在明确的英文 Term
→ 自动关联到英文文章
不存在英文 Term
→ 不创建、不猜测、不使用中文 Term
This avoids the following problems:
- duplicate categories with the same name;
- inconsistent slugs;
- duplicates caused by differences in capitalization;
- Chinese categories being assigned incorrectly to English posts;
- uncontrolled or incorrect Polylang category translation mappings.
Before translating the post again, the SlyTranslate category needs to be created in English and linked through Polylang.
6. A Missing Series Part Number Is Normal While the Post Is a Draft
After correcting the post-status workflow, Chinese post 19419 successfully generated English translation 19519.
The inspection produced the following results:
中文文章 ID：19419
英文文章 ID：19519
英文文章状态：draft
The English draft contained the following data:
- the Polylang relationship between the Chinese and English posts was correct;
- the English categories were migrated correctly;
- all nine English tags were migrated successfully;
- the English Series association was correct;
- the Series part number was empty.
An empty Series part number at this stage was not an error.
PublishPress Series is expected to generate the part number automatically when the post is published.
The correct lifecycle is:
生成英文草稿
↓
迁移并关联英文分类
↓
迁移并关联英文标签
↓
迁移并关联英文 Series
↓
人工检查英文文章
↓
手动发布
↓
PublishPress Series 自动生成 part
After post 19519 was published, the Series part value in the database was generated automatically:
22
The highest existing part number in this English Series was 21; the new post therefore received part number 22, which correctly followed the append-in-sequence rule.
7. GLM Compressed Consecutive Zeros in a Protected Token
While translating Chinese post 19419, the API returned the following error:
{
"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
}
The diagnostic output showed that the expected token was:
SWQSTRUCT000018END
GLM returned:
SWQSTRUCT00018END
The model had removed one of the consecutive leading zeros.
The original Gutenberg content represented by this token was:
<!-- /wp:heading -->
The relevant fragment returned by GLM was:
SWQSTRUCT000017END
<h2 class="wp-block-heading">1. The Initial Cooperation Invitation</h2>
SWQSTRUCT00018END
SWQSTRUCT000019END
The Gutenberg structure had not been removed. Instead, the model had altered the numeric format of the protected token.
The existing strict validation prevented this malformed response from being written to WordPress. Without that safeguard, the restoration process might fail to find the correct token and could ultimately lose a block-closing comment.
8. Applying a Limited and Safe Repair to Malformed Tokens
I did not bypass validation or simply loosen the token regular expression.
Instead, I added the following rule:
A malformed token may be normalized only when it maps uniquely to exactly one expected token.
All of the following conditions must be met:
- the token type is identical;
- the numeric values match after leading zeros are removed;
- the malformed token matches only one missing expected token;
- no duplicate token exists;
- there are no multiple candidates;
- the repaired token order is correct;
- the complete strict validation passes again after repair.
For example:
SWQSTRUCT00018END
can be restored unambiguously to:
SWQSTRUCT000018END
If there is any ambiguity, duplication, or ordering error, the translation still stops.
The test result was:
PASS: zero contraction is repaired
PASS: correct token remains unchanged
PASS: ambiguous candidates fail
PASS: duplicate token fails
PASS: wrong fixed order fails
After the repair, post 19419 successfully generated English draft 19519.
9. The Featured Image Was Not Migrated to the English Post
During further testing with post 19429, the English body, categories, tags, and Series were correct, but the English draft had no featured image.
A read-only inspection showed:
中文文章 ID：19429
中文特色图片 attachment ID：19437
图片 URL：https://media.shuijingwanwq.com/2026/07/7-18.png
附件语言：zh
英文附件翻译：不存在
英文文章 ID：19522
英文特色图片：空
This confirmed that the featured-image relationship had not been synchronized when the English post was created.
WordPress stores the featured-image relationship in _thumbnail_id, which references an attachment. Migrating the body, taxonomies, or Series relationship does not populate this value automatically.
10. Featured-Image Migration Rules
The new featured-image logic follows these rules:
- do not overwrite an existing featured image on the English target post;
- leave the English post empty when the Chinese source post has no featured image;
- prefer the English attachment when Polylang provides an explicit English counterpart for the Chinese featured image;
- allow the English post to reuse the Chinese attachment when no English attachment exists;
- use
set_post_thumbnail()to establish the relationship rather than running raw SQL.
Post 19429 had no corresponding English attachment, so English post 19522 reused:
Attachment ID：19437
The test result was:
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
After this repair, I selected another new post for verification. Its English draft displayed the featured image correctly.
11. Why I Did Not Copy All Post Meta
Although featured images depend on post meta, copying all metadata from the Chinese post to the English post would be unsafe.
Post meta may contain:
- SEO plugin settings;
- internal editor state;
- page-builder data;
- cached results;
- temporary plugin fields;
- relationships tied to the Chinese post ID;
- Chinese domains and URLs;
- language-specific runtime data.
Unconditionally copying all post meta could transfer incorrect IDs, stale URLs, or plugin state from the Chinese post into the English post.
I therefore retained a whitelist-based approach:
明确迁移文章关系
明确迁移分类关系
明确迁移标签关系
明确迁移 Series 关系
明确迁移特色图片
Series part 由 PublishPress 在发布时生成
其他 Post Meta 不默认迁移
This approach requires item-by-item verification, but it carries less risk and is easier to roll back.
12. End-to-End Test with a New Post
After completing the repairs, I selected another Chinese post that included all of the following:
- categories;
- tags;
- a Series assignment;
- a featured image.
The test procedure was:
- run a full-article translation with SlyTranslate + GLM-5.2;
- generate an English draft automatically;
- inspect the English draft in the WordPress admin;
- confirm that the English categories, tags, and Series were assigned correctly;
- confirm that the featured image was present;
- confirm that the draft had no Series part number;
- do not open the English preview URL;
- publish the post manually;
- open the public English URL for the first time;
- check the front-end metadata and Series ordering.
Inspection of the English draft showed:
- the English body was correct;
- categories were assigned correctly;
- tags were assigned correctly;
- the Series association was correct;
- the featured image was displayed correctly;
- the Series part number was empty, as expected for a draft.
After publication:
- the public English page loaded correctly;
- the featured image was displayed correctly;
- the categories were correct;
- the tags were correct;
- the Series association was correct;
- PublishPress Series generated the part number automatically;
- the Series number matched in the admin and on the English front end;
- the new post was not incorrectly placed first in the Series.
13. English Draft Previews and Multi-Host Object Cache
Testing post 19519 also revealed the following behavior:
数据库 Series part：22
admin Host 读取结果：22
en Host 读取结果：空
As a result, the English front end temporarily placed the post first in the Series.
Before the post was published, the following URL had been opened:
https://en.shuijingwanwq.com/?p=19519&preview=true
The page returned a 404 at that time.
Although no valid public post page was generated, the en host may still have read and cached:
- the draft post status;
- an empty Series part number;
- an incomplete post object and post meta.
The post was then published through admin.shuijingwanwq.com.
Because W3TC Object Cache keys are host-dependent, clearing object cache entries on the admin host does not necessarily remove stale objects stored for the English host.
After precisely clearing the object cache on the en host for post 19519:
post status：publish
Series part：22
After regenerating the English W3TC Page Cache, the post no longer appeared first in the Series.
In later tests with new posts, the problem did not recur as long as the English draft preview URL was not opened.
For now, the safer temporary workflow is:
After generating the English draft, inspect its data in the WordPress admin without opening the English front-end preview URL, then publish it directly once everything has been verified.
The long-term multi-host object-cache compatibility issue will be handled separately as a caching problem rather than adding more logic to the translation plugin.
14. The Language Switcher on the Chinese Post May Still Be Stale
In the final new-post test, the English post was correct, but the corresponding Chinese page did not immediately show the English option in its language switcher.
I did not continue investigating this issue in the current round.
The missing switcher entry may involve:
- Polylang runtime relationships;
- the Chinese-host object cache;
- W3TC Page Cache;
- the EdgeOne CDN;
- stale HTML previously generated for the Chinese page.
The English post itself could already be generated and published correctly, so expanding the scope of this round was unnecessary.
Figure 6: The English post has been published correctly, but the corresponding Chinese post does not yet show the English language-switcher option
This issue will be handled as a separate follow-up task.
15. The Final English-Translation Workflow
After these changes, the English-post generation workflow is now:
中文文章
↓
SlyTranslate + GLM-5.2 整篇翻译
↓
生成英文草稿
↓
建立 Polylang 中英文文章关系
↓
迁移并关联已有的英文分类
↓
迁移并关联已有的英文标签
↓
迁移并关联对应的英文 Series
↓
迁移特色图片
↓
人工后台检查
↓
手动发布
↓
PublishPress Series 自动生成部分编号
↓
访问正式英文文章
The following must be prepared in advance:
- each Chinese category has a corresponding English category;
- each Chinese tag has a corresponding English tag;
- each Chinese Series has a corresponding English Series;
- these terms are linked as translations in Polylang.
The translation workflow does not automatically create missing English categories, tags, or Series terms.
16. Issues Resolved in This Round
This round completed the following changes:
- new English translations are saved as drafts instead of being published automatically;
- the Polylang relationship between Chinese and English posts is created correctly;
- Chinese category relationships are migrated to the corresponding English categories;
- Chinese tag relationships are migrated to the corresponding English tags;
- Chinese Series relationships are migrated to the corresponding English Series;
- PublishPress Series generates the part number automatically when the draft is published;
- the GLM issue that compressed leading zeros in protected tokens is repaired safely;
- featured images are migrated automatically;
- manually assigned English featured images are not overwritten;
- missing English terms do not trigger automatic creation of duplicate taxonomies;
- the body, categories, tags, Series, and featured image of newly generated English posts have all passed real-world testing.
17. Remaining Issues
The following issues still require further investigation:
- the English option may not appear promptly in the language switcher on the corresponding Chinese post;
- opening an English draft preview may populate a host-specific object cache with stale data;
admin,wwwandenneed a precise cross-host object-cache invalidation mechanism;- categories, tags, and Series terms without English counterparts must be created manually in advance;
- Chinese pages may still retain stale Series ordering or language-relationship data.
These issues should not be piled into the SlyTranslate translation workflow. They should be handled separately by Polylang data management and multi-domain cache compatibility logic.
18. Interim Conclusion
This troubleshooting process shows that WordPress translation automation cannot focus on the post body alone.
A publishable English translation must handle at least the following:
正文结构
+ Polylang 文章关系
+ 分类关系迁移
+ 标签关系迁移
+ Series 关系迁移
+ Series part 发布生命周期
+ 特色图片
+ 草稿与发布状态
+ Object Cache
+ Page Cache
+ CDN
The translation workflow should be responsible for:
- creating the English post;
- writing the English body;
- establishing the relationship between the Chinese and English posts;
- migrating Chinese taxonomy relationships to existing corresponding English terms;
- migrating the featured image;
- saving the new English post as a draft.
PublishPress Series remains responsible for automatic numbering when the post is formally published.
Multi-domain object-cache, W3TC Page Cache, and CDN invalidation should be handled by a separate cache-compatibility mechanism.
At this stage, SlyTranslate + GLM-5.2 has advanced from merely translating a complete WordPress post body to generating a complete English draft with the correct categories, tags, Series, and featured image.
The remaining Chinese language-switcher and cross-host caching issues will be addressed separately.
需要长期技术维护或远程问题排查？
我是拥有 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
发表回复