From Empty Abstracts and Messy Formats to Retranslation: How I Plan the Next Phase of My WordPress AI Translation Project

Recently, I migrated some AI translation quality articles from the “WP Blog Multilingualization Practice” series to a new “WordPress AI Translation Engineering in Practice” series.

After splitting the series, I also started to rethink a longer-term question:

Now that SlyTranslate + GLM 5.2 can translate an entire technical article, what work in the next phase is truly worth investing time in?

Initially, I just noticed that some historical articles had empty excerpts. But upon further inspection, I found this was not an isolated minor issue; it was interconnected with historical article formats, SEO meta descriptions, English article retranslation, other language expansion, and automated script management.

Ultimately, I organized a set of work plans for the next phase:

• Inventory the editors and code formats of historical Chinese articles;
• Identify the Classic Editor, SyntaxHighlighter Evolved, and Code Block Pro;
• Use GLM-4.7 to batch-generate Chinese excerpts;
• Write the excerpts into WordPress’s post_excerpt;
• Improve article lists and Yoast SEO meta descriptions;
• Overwrite and retranslate historical English articles;
• Evaluate whether to add other languages;
• Continue optimizing the SlyTranslate full-text translation workflow;
• Use Codex and GitHub to manage related scripts;
• Compare the quality, speed, and API costs of different models.

This article mainly records how I gradually arrived at this plan starting from a seemingly simple “empty excerpt” issue.

1. The Initial Problem: Many Historical Articles Lack Excerpts

My WordPress blog contains a large number of early Chinese articles whose excerpt fields have always been empty.

On the article list page, when post_excerpt has no content, WordPress automatically extracts a snippet from the beginning of the body text to serve as the excerpt.

On the surface, this default behavior prevents the article list from having no description at all, but two problems occur in actual use.

The first problem is that the beginning of the article body usually contains the post views component.

Therefore, the article list simultaneously displays:

• The Post Views output separately by the theme or plugin;
• The Post Views automatically extracted by WordPress from the beginning of the body text.

As a result, a single article entry might show post views information twice.

The second problem is the Yoast SEO meta description.

Although the current meta description does not include post views, because the excerpt is empty, Yoast SEO actually uses a portion of the body text. For example:

<meta name="description" content="最近我开始重新重视博客的英文流量。 我的博客目前是基于： WordPress Polylang AutoPoly - AI Translation For Polylang AutoPoly 免费版中的 Chrome Built-in AI 来实现中文文章自动翻译成英文。" />

<meta name="description" content="最近我开始重新重视博客的英文流量。 我的博客目前是基于： WordPress Polylang AutoPoly - AI Translation For Polylang AutoPoly 免费版中的 Chrome Built-in AI 来实现中文文章自动翻译成英文。" />

This content is not entirely wrong, but it is just a mechanical extraction from the beginning of the body. It does not necessarily accurately summarize the problem the article solves, the methods used, and the final results.

Therefore, the initial goal was clear:

Backfill formal excerpts for historical Chinese articles.

2. Why We Cannot Just Fix the Chinese Article List Problem

If the goal were merely to eliminate the duplicate Post Views in the article list, we could temporarily hide one occurrence via the theme template or CSS.

However, this approach only addresses the symptom and does not solve the problem of the excerpt field itself being empty.

By formally backfilling post_excerpt, we can simultaneously improve:

• Chinese article archive pages;
• Category and tag pages;
• On-site search results;
• RSS feeds;
• Yoast SEO meta descriptions;
• Social media sharing excerpts;
• Subsequent English and other language translations.

This is especially true since I plan to subsequently overwrite and retranslate historical English articles.

If the Chinese articles themselves lack excerpts, the English article excerpts will still be empty during retranslation. The English article list and English meta descriptions will continue to experience the same issues.

Therefore, the Chinese excerpt is not a field that serves only the Chinese site; it should serve as the foundational data for subsequent multilingual content production.

3. Why Consider Using GLM-4.7 Instead of Continuing with GLM 5.2

Currently, SlyTranslate primarily uses GLM 5.2 for translating entire technical articles.

After multiple rounds of customization, GLM 5.2 can already handle:

• Gutenberg blocks;
• HTML tags;
• Shortcodes;
• Code Block Pro;
• Plaintext areas;
• Inline code;
• Long article placeholders;
• Unified translation of titles, excerpts, and body text.

However, generating excerpts is different from translating full articles.

The excerpt task usually only requires outputting a short piece of Chinese text and does not involve:

• Gutenberg structure restoration;
• Validating hundreds of placeholders;
• Code block restoration;
• Long article structural consistency;
• A large amount of English technical phrasing.

Its core requirements are:

• Accurately summarizing the article;
• Not adding information absent from the original text;
• Natural language;
• Consistent length;
• Controllable batch execution costs.

Therefore, I see no need to default to GLM 5.2, which has higher costs and capabilities, for excerpt generation.

I currently still have a GLM-4.7 model resource package, which can be prioritized for these relatively simple, short-output tasks.

The preliminary plan is:

model: glm-4.7
thinking: disabled

model: glm-4.7
thinking: disabled

This utilizes the existing resource package while reserving GLM 5.2 for the more complex task of translating entire technical articles.

Of course, this is just the current plan, not a permanent decision.

Subsequent steps still require comparing actual samples regarding:

• Excerpt accuracy;
• Chinese naturalness;
• Input and output tokens;
• API latency;
• Batch processing stability;
• Failure retry rate.

If GLM-4.7’s quality proves insufficient, I will then consider using GLM 5.2 or other models, rather than assuming in advance that a single model is suitable for all tasks.

4. Upon Further Analysis, I Found Historical Articles Do Not Follow a Single Format

While planning the excerpt script, a further thought occurred to me:

How should the script extract the natural language that actually needs summarizing from historical articles?

My historical Chinese articles span a long period, and the editors and code highlighting methods are not unified. Currently, there are at least four main situations.

1. Classic Editor, No Code Highlighting Plugin

The earliest batch of articles used the Classic Editor, and the code might just be plain:

<pre>...</pre>

<pre>...</pre>

Or:

<code>...</code>

<code>...</code>

Some articles might also just rely on spaces, line breaks, and manual HTML formatting.

2. Classic Editor, Using SyntaxHighlighter Evolved

Some later articles still used the Classic Editor, but code blocks were handled by SyntaxHighlighter Evolved.

The article body might contain something like:

[php]
code content
[/php]

[php]
code content
[/php]

Or shortcodes with parameters:

[php firstline="10" highlight="12,15"]
代码内容
[/php]

[php firstline="10" highlight="12,15"]
代码内容
[/php]

3. Gutenberg, Using SyntaxHighlighter Evolved

Later on, I started using the Gutenberg editor, but code highlighting still relied on SyntaxHighlighter Evolved.

These articles might simultaneously contain:

• Gutenberg block comments;
• Shortcode blocks;
• Classic or Freeform blocks;
• SyntaxHighlighter shortcodes;
• Plain HTML.

4. Gutenberg, Using Code Block Pro

Currently, new articles primarily use Gutenberg and Code Block Pro.

These code blocks contain not only the code itself but may also include:

• wp:kevinbatdorf/code-block-pro comments;
• JSON attributes;
• textarea;
• pre.shiki;
• code;
• span.line;
• Theme, line number, and language settings.

This means that whether generating excerpts or retranslating historical articles, we cannot assume all article structures are the same.

5. Why I Ultimately Decided Not to Convert All Historical Articles to Gutenberg + Code Block Pro First

After discovering the four historical formats, I briefly considered:

Should I convert all historical Chinese articles uniformly to Gutenberg + Code Block Pro before retranslating English articles and adding other languages?

From a long-term consistency perspective, this idea seemed reasonable.

Once unified, subsequent translations would only need to support one format, making editing and maintenance much neater.

However, after further evaluation, I concluded that a full format migration should not be a prerequisite for translation work.

1. The Risk of Historical Article Format Migration is Too High

Classic Editor articles might contain:

• Non-standard HTML;
• Manually crafted tables;
• Old shortcodes;
• Incomplete but browser-compatible tags;
• Special escape characters;
• Manually inserted images and links;
• Custom styles;
• Early WordPress auto-generated paragraph structures.

After batch converting to Gutenberg, the following might occur:

• Changes in paragraph order;
• Changes in blank lines;
• HTML being re-escaped;
• Shortcodes being incorrectly wrapped;
• Broken tables;
• Changes in code indentation;
• Gutenberg reporting blocks as invalid.

2. Code Block Pro Itself Has a Complex Structure

Batch converting plain <pre> and SyntaxHighlighter shortcodes to Code Block Pro is not just a tag replacement.

The script also needs to determine:

• Code language;
• HTML entities;
• Line numbers;
• Highlighted lines;
• Escaping methods;
• The current block structure of Code Block Pro.

If any judgment is wrong, it could corrupt the code content.

3. Format Migration and Translation are Two Different Issues

If format migration is completed simultaneously with retranslation, and an anomaly occurs in the English article, it is difficult to determine whether the problem stems from:

• Model translation;
• Placeholder protection;
• Code block conversion;
• Gutenberg structure generation;
• Plugin compatibility.

Therefore, the safer current strategy is:

New articles will continue to uniformly use Gutenberg + Code Block Pro; historical Chinese articles will retain their original formats; excerpt and translation tools will be compatible with historical formats.

Old articles will only be manually migrated one by one when they need re-editing or major updates.

6. Therefore, a Format Inventory Must Precede Excerpt Generation

Since we are not doing a full format conversion, the next step is not to directly call GLM-4.7, but to first understand the actual state of the historical articles.

I plan to first develop a read-only article format inventory tool to count:

• Total number of published Chinese articles;
• Number of articles with empty excerpts;
• Number of articles with non-empty excerpts;
• Number of articles using the Classic Editor with no highlighting plugin;
• Number of articles using Classic Editor + SyntaxHighlighter Evolved;
• Number of articles using Gutenberg + SyntaxHighlighter Evolved;
• Number of articles using Gutenberg + Code Block Pro;
• Mixed articles containing multiple structures simultaneously;
• Articles that cannot be reliably identified.

The classification should not only cover the four ideal scenarios but also retain:

mixed
unknown

mixed
unknown

Because real historical data is likely not perfectly neat.

For example, a Gutenberg article might simultaneously contain:

• Code Block Pro;
• Plain <pre>;
• Freeform blocks left over from Classic Editor migration;
• SyntaxHighlighter shortcodes.

If the script forcibly categorizes this into a single classification just to complete the statistics, subsequent excerpt extraction and translation testing could be based on flawed judgments.

7. Why Extract Representative Articles Instead of Running Across the Whole Site Directly

Another goal of the format inventory is to select representative samples for subsequent excerpt generation and translation testing.

A small number of articles need to be extracted for each major format to verify:

• Whether code is mistakenly treated as natural language;
• Whether shortcodes end up in the excerpt;
• Whether HTML is completely cleaned up;
• Whether article titles and section headings are preserved;
• Whether ultra-long articles need to be truncated;
• Whether the article’s conclusion can be recognized by the model;
• Whether GLM-4.7 adds conclusions not present in the original text.

Test samples should not be limited to the newest, most structurally standardized articles.

It is more reasonable to cover:

• Short articles;
• Long articles;
• Articles with little code;
• Articles with a lot of code;
• Articles containing tables;
• Articles containing many image captions;
• Articles containing shortcodes;
• The four editor and code formats.

Only test results obtained this way can reflect the entire historical article repository, rather than a few ideal samples.

8. How the Excerpt Generation Script Should Process the Body Text

The excerpt script should not send the complete raw HTML directly to the model.

A more reasonable processing flow is:

Read Chinese article
→ Determine article format
→ Delete or isolate code content
→ Delete Gutenberg block comments
→ Delete irrelevant shortcodes
→ Clean up HTML
→ Preserve titles, section headings, and natural language
→ Call GLM-4.7
→ Validate excerpt
→ Write to post_excerpt

Read Chinese article
→ Determine article format
→ Delete or isolate code content
→ Delete Gutenberg block comments
→ Delete irrelevant shortcodes
→ Clean up HTML
→ Preserve titles, section headings, and natural language
→ Call GLM-4.7
→ Validate excerpt
→ Write to post_excerpt

Unlike full translation, excerpt generation does not require replacing code with a large number of placeholders and then restoring them after the model outputs.

Since excerpts should not contain code in the first place, directly deleting the code is usually simpler.

However, this “deletion” must be based on accurate identification.

For example, we cannot delete an entire paragraph of body text just because <code> appears in it, nor can we mistake a plain technical explanation for a shortcode just because square brackets appear.

Therefore, format identification and natural language extraction should serve as reusable foundational modules, rather than a collection of ad-hoc regular expressions.

9. Excerpt Writing Should Only Maintain post_excerpt

After generating the excerpt, I plan to write the content into WordPress’s native:

post_excerpt

post_excerpt

Instead of simultaneously maintaining a separate Yoast SEO custom meta description.

The reasons for this are:

• The WordPress article list can directly use the excerpt;
• Yoast SEO can continue to generate meta descriptions via excerpt variables;
• During English translation, the excerpt can be translated directly;
• Avoiding creating two separate sets of content for the excerpt and SEO meta description;
• When modifying excerpts later, only one field needs to be maintained.

When formally writing, we also should not directly use SQL to update the database.

It is more appropriate to call it via the WordPress environment:

wp_update_post()

wp_update_post()

This way, WordPress, Yoast SEO, object caching, and related save hooks can all correctly receive the article update.

10. Why We Cannot Process All Historical Articles at Once

Even if GLM-4.7’s excerpt quality looks good, we should not batch write to all historical articles on the first try.

A more reasonable execution order is:

Phase 1: Read-Only Statistics

Do not call the API, do not modify the database; only count article formats and excerpt statuses.

Phase 2: Small-Scale Dry-Run

Select 10–20 representative articles, call GLM-4.7, but only output candidate excerpts and logs, without writing to WordPress.

Phase 3: Manual Review

Focus on checking:

• Whether the excerpt is accurate;
• Whether the article’s conclusion is missing;
• Whether it contains code;
• Whether marketing phrasing appears;
• Whether it is too long;
• Whether it is just a mechanical rewrite of the title;
• Whether articles of different formats perform consistently.

Phase 4: Small Batch Formal Write

First write about 20 articles, and check:

• WordPress backend excerpt field;
• Chinese article list;
• Category and tag pages;
• Yoast SEO meta description;
• W3 Total Cache;
• EdgeOne cache;
• RSS and page source code.

Phase 5: Batch Processing

After verifying there are no issues, process a certain number of articles per batch, retaining checkpoint recovery, failure retries, and run logs.

Although this approach is slower than executing all articles at once, it significantly reduces the risk of batch-polluting historical content.

11. Why I Decided to Create a Separate GitHub Public Repository

Backfilling excerpts is not just an add-on feature for SlyTranslate.

It is essentially an independent WordPress historical content processing tool:

Read article
→ Determine format
→ Extract natural language
→ Call AI
→ Validate excerpt
→ Write to post_excerpt

Read article
→ Determine format
→ Extract natural language
→ Call AI
→ Validate excerpt
→ Write to post_excerpt

Therefore, I plan to create a separate public repository:

wordpress-ai-excerpt-backfill

wordpress-ai-excerpt-backfill

This name is not tied to GLM-4.7, nor is it tied to a specific WordPress plugin.

In the future, it can support:

• GLM;
• DeepSeek;
• OpenAI;
• Other compatible APIs;
• Different excerpt rules;
• Other WordPress sites.

The article format inventory tool will also be placed in the same repository, rather than creating another one.

Because the inventory and excerpt generation share:

• WordPress loading;
• Article queries;
• Editor detection;
• Code block identification;
• Natural language extraction;
• Test samples;
• Report output.

If they were split into two repositories, it would lead to duplicate code and duplicate maintenance later on.

12. Codex’s Role in This Plan

This type of work is well-suited for having Codex assist with the engineering implementation.

Codex can be responsible for:

• Initializing the repository;
• Creating the project structure;
• Writing the CLI;
• Implementing format identification;
• Writing tests;
• Generating JSON and CSV reports;
• Integrating the GLM API;
• Implementing dry-runs;
• Implementing checkpoint recovery;
• Logging tokens and latency;
• Managing Git commits;
• Deploying upon explicit authorization.

However, Codex should not decide on its own:

• What constitutes a qualified excerpt;
• What content should be deleted;
• Whether existing excerpts can be overwritten;
• When a full batch write can occur;
• Which model can directly enter production.

These quality standards still need to be determined through actual article sampling.

Therefore, I plan to divide the responsibilities into two parts:

Codex is responsible for engineering implementation, while I am responsible for content standards, sample review, and production decisions.

13. Why Overwriting and Retranslating Historical English Articles Comes After Chinese Excerpts

I already have a large number of historical English articles, but these English articles come from different translation stages, such as:

• Yandex;
• Chrome Built-in AI;
• AutoPoly;
• ChatGPT Plus;
• SlyTranslate;
• Different prompts and models.

The translation quality and structural consistency are not uniform.

Therefore, I plan to subsequently overwrite and retranslate historical English articles.

But this work should come after backfilling the Chinese excerpts.

The reason is that during retranslation, three fields of the Chinese article can be processed uniformly:

title
excerpt
content

title
excerpt
content

This way, the English articles can simultaneously receive:

• A retranslated title;
• An English excerpt semantically consistent with the Chinese excerpt;
• A retranslated body text.

The English excerpt does not need to be summarized separately based on the English body text, nor does it need to remain empty.

This reduces model calls and keeps the Chinese and English excerpts corresponding.

14. Adding Other Languages Should Come Later Than Retranslating Historical English Articles

Technically, Polylang can continue to add other languages.

However, adding a language is not just about calling a translation API one more time; it also brings:

• New language taxonomies;
• New article counts;
• New tag translations;
• New series translations;
• Sitemap growth;
• Cache growth;
• Search engine submissions;
• Language switching;
• New domains or URL structures;
• API costs;
• Content maintenance costs.

Therefore, before the historical English articles have been reorganized, it is not appropriate to immediately expand to more languages.

A more reasonable order of assessment is:

1. First backfill Chinese excerpts;
2. Verify the English overwrite translation process;
3. Evaluate English traffic and maintenance costs;
4. Then choose whether to add other languages;
5. Only select languages with clear readership and search value.

Adding a language should not be done just because “it is technically possible,” but should be based on long-term maintenance capacity and actual benefits.

15. SlyTranslate Optimization Will Not Stop

Although current full-text translation has made significant progress, SlyTranslate’s production workflow may still encounter new edge cases.

Problems that have already occurred include:

• Long article timeouts;
• invalid_translation_runaway_output false failures;
• Placeholder omissions;
• Placeholder duplications;
• Placeholder collisions with body text examples;
• Natural language paragraph duplications;
• Code Block Pro block failures;
• Plaintext area misjudgments;
• Category, tag, and Series sync anomalies;
• Featured image out of sync;
• Cache prematurely generating error pages.

These issues show that model quality is only one part of the translation process.

A truly long-term viable translation system also needs:

• Input protection;
• Output validation;
• Exception logging;
• Safe fallbacks;
• Cache handling;
• Metadata synchronization;
• Git version control;
• Production deployment validation.

Therefore, the excerpt project and historical English article retranslation will not replace SlyTranslate optimization; rather, they will work together with it to form a more complete WordPress AI translation engineering process.

16. Why We Still Need to Continue Comparing Different Models

Currently, full technical article translation primarily uses GLM 5.2, and the excerpt plan will test GLM-4.7 first.

DeepSeek has completed preliminary testing, and the current results are not as good as GLM 5.2, so it is temporarily no longer a primary candidate.

Gemini has been tested locally, but the production server is located on Alibaba Cloud in Hangzhou, so network connectivity must be considered when calling foreign APIs.

OpenAI might also bring better English naturalness, but if the server cannot reliably request the API, a pure quality advantage is not enough to form a production solution.

Therefore, model comparison cannot just look at the English effect of a single article; it should uniformly compare:

• Technical accuracy;
• English naturalness;
• Structural integrity;
• Long article stability;
• Processing speed;
• API costs;
• Domestic server connectivity;
• Deployment complexity;
• Failure retry rate;
• Long-term maintenance costs.

The ultimate goal is not to find the theoretically strongest model, but to find:

A solution that can long-term and stably generate content approaching the quality of manual retranslation, at an acceptable cost and operational volume.

17. The Finalized Next-Phase Plan

Through the above analysis, I have ultimately organized the subsequent work into the following sequence.

Phase 1: Historical Article Format Inventory

• Develop a read-only CLI;
• Count the four main formats;
• Identify mixed and unknown;
• Count the number of empty excerpts;
• Extract representative test articles.

Phase 2: Chinese Excerpt Generation Testing

• Use GLM-4.7;
• Clean up code and irrelevant structures;
• Generate excerpts of 80–120 Chinese characters;
• Log tokens, latency, and raw model responses;
• Dry-run first, do not write to the database.

Phase 3: Formal Chinese Excerpt Backfill

• Write to post_excerpt in small batches;
• Verify the article list;
• Verify Yoast SEO meta descriptions;
• Verify caching;
• Process all historical Chinese articles in batches.

Phase 4: Overwrite and Retranslate Historical English Articles

• Preserve the original structure of the Chinese source articles;
• Translate title, excerpt, and body text simultaneously;
• Update existing English articles;
• Avoid duplicate creation;
• Check Polylang associations, categories, tags, Series, and featured images.

Phase 5: Evaluate Other Languages

• Evaluate whether to expand based on the English site results;
• Evaluate traffic, costs, and maintenance workload;
• Do not add languages just for the sake of language count.

Phase 6: Continuously Optimize the Translation Pipeline

• Continue refining placeholder protection;
• Add historical format test samples;
• Optimize exception handling;
• Compare model quality and costs;
• Use Codex and GitHub to manage code.

18. Phased Conclusion

This plan was not designed from the very beginning.

It started from a very small phenomenon:

Historical article excerpts were empty, causing the article list to repeatedly display Post Views, and the Yoast SEO meta description was just an extraction from the beginning of the body text.

Upon further analysis, the problem gradually expanded to:

• Chinese excerpt foundational data;
• English excerpts;
• Historical article formats;
• Code protection;
• Historical English article retranslation;
• Other languages;
• Model costs;
• Automated scripts;
• GitHub engineering management.

Ultimately, I chose not to directly batch-generate excerpts, nor to convert all historical articles to Gutenberg + Code Block Pro first.

The safer current route is:

Inventory first, then sample; backfill Chinese foundational data first, then overwrite English; ensure a single workflow is stable first, then consider expanding languages.

This also aligns with my current fundamental judgment regarding WordPress AI translation engineering:

The real difficulty is not getting the model to output a translation, but establishing a production workflow that can run long-term, is verifiable, recoverable, cost-controllable, and will not damage historical content.