Further Improving SlyTranslate + GLM-5.2 Translation Quality: From Disabling Random Sampling and Built-in Prompts to Deep Thinking and Model A/B Testing

Previously, I integrated SlyTranslate with Zhipu GLM-5.2 and, through a custom MU Plugin, modified the WordPress technical article body to be sent to the large language model for translation in a single pass.

For relevant earlier records, please refer to:

• https://www.shuijingwanwq.com/2026/07/14/19429/
• https://www.shuijingwanwq.com/2026/07/15/19450/

After implementing the one-pass full-text translation, the overall translation quality is already significantly better than the earlier chunked translation approach. However, compared to direct re-translation using ChatGPT Plus, some issues still occasionally appear in the English titles, summaries, and body text, such as:

• Titles retaining Chinese word order and stacking multiple nouns consecutively;
• Summary information being too dense with overly long sentences;
• Regular links occasionally being incorrectly summarized as redirects;
• Expressions like WordPress English site showing slight traces of Chinglish;
• Some paragraphs being grammatically correct but not reading like natural English technical blog posts.

Therefore, I continued testing in the following three directions:

1. Optimizing model request parameters;
2. Built-in translation prompts into the code;
3. Testing deep thinking and other models.

1. First, clarify the current actual translation workflow

During the early troubleshooting process, SlyTranslate used to split the body text into numerous requests, resulting in records of nearly 89 model calls in the old logs.

However, the current implementation has changed.

The current custom MU Plugin is:

wp-content/mu-plugins/swq-glm52-translation-tuning.php

wp-content/mu-plugins/swq-glm52-translation-tuning.php

It intercepts SlyTranslate’s translation REST requests and processes the article using a custom workflow:

• The title is translated as a short field;
• The summary is translated as a short field;
• The body text, after code protection, is sent to GLM-5.2 in a single pass;
• After all fields are successfully translated, they are written into the English article together;
• Only a single model request is allowed during the body translation phase; retries and chunked fallbacks are blocked.

Therefore, a complete translation currently typically generates only a few API requests, rather than dozens.

This also means that when subsequently evaluating prompt length, translation time, and API costs, the 89 requests from the old workflow can no longer be used as a baseline.

2. Disabling random sampling

The Zhipu API supports controlling whether to use random sampling via do_sample.

For technical article translation, what I need more is:

• Terminology stability;
• Reproducible expressions;
• Using the same English term for the same concept whenever possible;
• Avoiding different requests randomly selecting different synonyms.

Therefore, before the request is formally encoded into JSON, I added:

$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;

$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;

After disabling sampling, the translation results become more stable, but this primarily improves consistency and reproducibility; it does not automatically eliminate Chinese word order and machine translation tone.

3. Discovering that Additional Instructions only affect the body text

Initially, I filled out a fairly complete set of Additional Instructions in the SlyTranslate backend, which included:

• Preserving Gutenberg block structure;
• Protecting HTML, URLs, commands, paths, and filenames;
• Protecting SWQBLOCK and SWQINLINE placeholders;
• Avoiding Chinese word order;
• Using natural English technical writing style;
• Not adding facts and conclusions that do not exist in the source text.

After re-translating, the body text improved, but the title hardly changed.

At first, I suspected that the title might be going through SlyTranslate’s original plugin’s independent translation workflow. After further checking the current MU Plugin, I found the real problem lies here:

$prompt = self::build_field_prompt( '', $field );

$prompt = self::build_field_prompt( '', $field );

Although build_field_prompt() supports receiving Additional Instructions, an empty string is passed during the call.

Meanwhile, the body text is called via:

self::translate_full_content(
	$source,
	$target_language,
	$resolved_source_language,
	$additional_prompt,
	$post_id,
	$article_title,
	$article_excerpt
);

self::translate_full_content(
	$source,
	$target_language,
	$resolved_source_language,
	$additional_prompt,
	$post_id,
	$article_title,
	$article_excerpt
);

That is to say:

Additional Instructions were passed to the body text, but not to the title and summary.

After the fix, the short field call was adjusted to:

$translated = self::translate_field_value(
	$source,
	$target_language,
	$resolved_source_language,
	$field,
	$id,
	$post_id,
	$additional_prompt
);

$translated = self::translate_field_value(
	$source,
	$target_language,
	$resolved_source_language,
	$field,
	$id,
	$post_id,
	$additional_prompt
);

The function parameters were simultaneously added:

private static function translate_field_value(
	string $source,
	string $to,
	string $from,
	string $field,
	string $unit_id,
	int $post_id,
	string $additional_prompt
)

private static function translate_field_value(
	string $source,
	string $to,
	string $from,
	string $field,
	string $unit_id,
	int $post_id,
	string $additional_prompt
)

And the prompt construction was changed to:

$prompt = self::build_field_prompt(
	$additional_prompt,
	$field
);

$prompt = self::build_field_prompt(
	$additional_prompt,
	$field
);

After the fix, the title changed from the original:

WordPress Polylang English Subdomain Migration Links Still Pointing to Chinese Site...

WordPress Polylang English Subdomain Migration Links Still Pointing to Chinese Site...

Improved to:

WordPress Polylang English Subdomain Migration: Links Still Pointing to Chinese Site...

WordPress Polylang English Subdomain Migration: Links Still Pointing to Chinese Site...

Although it is not yet the ideal English title, it proves that Additional Instructions are now affecting the title translation.

4. Building stable prompts into the MU Plugin

Continuing to use backend Additional Instructions presents several issues:

• Requires copy-pasting before every translation;
• The input box only retains a limited length of content;
• Titles, summaries, and body text require different rules;
• When translating to other target languages in the future, English writing requirements cannot be forcibly applied;
• Prompts scattered in the backend are not conducive to long-term maintenance.

Therefore, I built the stable translation rules directly into the MU Plugin, keeping the backend Additional Instructions as an optional temporary supplement.

The new implementation adds the following methods:

build_field_prompt()
build_content_prompt()
build_target_language_field_rules()
build_target_language_content_rules()

build_field_prompt()
build_content_prompt()
build_target_language_field_rules()
build_target_language_content_rules()

The title, summary, and body text use different rules respectively.

English title rules

Key requirements for the model:

• Avoid Chinese word order;
• Avoid consecutively stacking multiple nouns;
• Avoid unnatural -ing title fragments;
• Clarify the relationships between time, cause, problem, and result;
• Do not rewrite a “complete fix” as a generic “user guide”;
• Do not add exaggerated conclusions that do not exist in the source text.

English summary rules

Key requirements for the model:

• Use 2 to 4 clear sentences;
• Summarize the problem, main cause, and final solution;
• Avoid cramming all information into a single overly long sentence;
• Do not use vague, bureaucratic expressions;
• Do not conflate regular links, redirects, caches, and database records.

English body text rules

The body text continues to retain the existing one-pass translation mechanism, emphasizing:

• Preserving the author’s first-person perspective;
• Preserving the troubleshooting sequence and practical record style;
• Using clear subjects and direct verbs;
• Maintaining consistent technical terminology;
• Avoiding word-for-word translation and Chinese sentence structures;
• Not adding, deleting, merging, or adjusting Gutenberg blocks.

Other target languages

The code does not forcibly apply English rules to all languages.

The target language is normalized first. For example:

en
en-US
en_US

en
en-US
en_US

These will all be recognized as English.

Languages without dedicated rules for now will use general technical translation rules as a fallback, and dedicated rules for languages like Japanese can be added later.

After building in the prompts, the backend Additional Instructions can be left empty. The current complete MU Plugin now uniformly includes model parameters, field prompts, body text prompts, placeholder protection, and validation logic.

5. Actual translation results after built-in prompts

Re-translating the same Chinese article took approximately:

1.36 minutes

1.36 minutes

The new English title is:

Fixing Links That Still Point to the Chinese Site After a WordPress Polylang English Subdomain Migration: A Complete Guide for Category Dropdowns, Breadcrumbs, and Block Templates

Fixing Links That Still Point to the Chinese Site After a WordPress Polylang English Subdomain Migration: A Complete Guide for Category Dropdowns, Breadcrumbs, and Block Templates

Compared to the original title, it has significantly improved:

• The main structure of the title is clearer;
• “Links still pointing to the Chinese site” has become the main problem;
• It no longer stacks nouns completely according to the Chinese title order.

However, a few minor issues remain:

• WordPress Polylang English Subdomain Migration still feels slightly crowded;
• The source text meant “complete fix,” but the model wrote A Complete Guide, causing a slight shift in meaning.

The summary and body text also reached a publish-ready level, but there are still some minor traces of machine translation, such as:

the WordPress English site

the WordPress English site

A more natural expression might be:

the English version of the WordPress site

the English version of the WordPress site

Also:

After selecting the Browser category, the browser...

After selecting the Browser category, the browser...

The category name Browser and the common noun browser appear in the same sentence; while grammatically correct, the reading experience is less than ideal.

This indicates that prompt optimization has brought actual improvements, but the returns from continuously adding fragmented rules are likely diminishing.

6. Testing GLM-5.2 deep thinking

Next, I tried enabling deep thinking for GLM-5.2:

$body['thinking'] = [ 'type' => 'enabled' ];
$body['reasoning_effort'] = 'high';
$body['do_sample'] = false;

$body['thinking'] = [ 'type' => 'enabled' ];
$body['reasoning_effort'] = 'high';
$body['do_sample'] = false;

When testing directly in WordPress, the summary translation returned:

{
	"code": "swq_field_translation_failed",
	"message": "Field translation failed: field=excerpt, unit_id=excerpt, reason=invalid_translation_assistant_reply. Diagnostic: /tmp/swq-glm52-field-error-summary.json",
	"data": null
}

{
	"code": "swq_field_translation_failed",
	"message": "Field translation failed: field=excerpt, unit_id=excerpt, reason=invalid_translation_assistant_reply. Diagnostic: /tmp/swq-glm52-field-error-summary.json",
	"data": null
}

The HTTP response was:

500

500

This indicates that the current SlyTranslate or Provider’s response adaptation layer cannot directly and correctly handle the data structure returned by Thinking mode.

However, continuing to modify the adaptation layer might require:

• Adding raw response logging;
• Compatibility with reasoning_content;
• Adjusting the Provider’s response mapping;
• Repeatedly triggering errors in the production environment.

To avoid continuously modifying production code, I switched to calling the Zhipu official API directly on my local machine for an independent A/B test.

7. Testing deep thinking locally

The test used the exact same:

• Chinese title;
• Chinese summary;
• Gutenberg body text sample;
• Prompts;
• GLM-5.2;
• do_sample=false.

The only variable is:

thinking=disabled

thinking=disabled

Versus:

thinking=enabled
reasoning_effort=high

thinking=enabled
reasoning_effort=high

The test results are as follows:

The total time for deep thinking was about 3.95 times that of thinking disabled, and token usage was about 2.59 times.

In terms of quality:

• Title: The thinking-disabled version was more direct;
• Summary: The deep thinking version improved slightly;
• Body text: Each had pros and cons, with no stable improvement.

Although deep thinking improved some sentences, it also introduced new issues, such as:

• The main structure of the title became longer;
• Chinese primary domain was less natural than Chinese main domain;
• but instead loaded: expression was stiff;
• Changing the numbering 1. to I.;
• inspection, fixing, and verification was not natural enough.

The final conclusion is:

Deep thinking runs normally, but the improvement to current technical blog translation is unstable, and it is not worth bearing nearly 4 times the time cost, additional token costs, and adaptation layer maintenance costs.

8. Comparing GLM-4.7-FlashX

To determine whether the remaining issues are approaching the model capability limit of GLM-5.2, I also tested GLM-4.7-FlashX directly locally.

Both models used:

thinking=disabled
do_sample=false
Same prompts
Same input

thinking=disabled
do_sample=false
Same prompts
Same input

Test results:

GLM-4.7-FlashX reduced the total time by about one-third, but token usage only decreased by about 1.6%.

In terms of quality, GLM-4.7-FlashX’s issues were more apparent.

For example, the title rendered the singular English subdomain as:

English Subdomains

English Subdomains

And generalized “still pointing to the Chinese site” into:

Broken Links

Broken Links

The summary also contained:

fixed links
verifying the source site

fixed links
verifying the source site

These expressions did not accurately reflect the technical meanings of “permalinks” and “verifying on the source site.”

The body text mixed past and present tenses:

After migrating...
are accessible
I discovered
does not access
returns

After migrating...
are accessible
I discovered
does not access
returns

In contrast, GLM-5.2 is better at maintaining consistency in technical facts, tense, and context.

Therefore, although GLM-4.7-FlashX is faster, it is not suitable as the current production translation model.

9. Current final configuration

After this round of testing, the current production environment is temporarily fixed to:

$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;

$body['thinking'] = [ 'type' => 'disabled' ];
$body['do_sample'] = false;

The model continues to use:

glm-5.2

glm-5.2

While retaining:

• Built-in dedicated prompts for title, summary, and body text;
• Selecting prompt strategies based on the target language;
• Backend Additional Instructions as an optional supplement;
• One-pass body text translation;
• Gutenberg and HTML structure validation;
• SWQBLOCK and SWQINLINE placeholder protection;
• Allowing only a single body text model request;
• 600-second timeout;
• 32768 maximum output tokens;
• Not writing incomplete articles if translation fails.

10. Next steps

After testing prompts, parameters, deep thinking, and Zhipu models, GLM-5.2 can serve as the stable baseline for the current solution.

Continuing to add more fragmented prompts for GLM-5.2 is unlikely to yield significant improvements, and might instead result in:

• Rules interfering with each other;
• Some sentences improving while others regress;
• Prompts becoming increasingly difficult to maintain;
• The model becoming more conservative to comply with the rules.

If we want to further improve translation quality later, a more valuable direction is to use the same local A/B testing approach to compare other models.

I plan to apply for a DeepSeek API Key and use the exact same:

• Chinese title;
• Chinese summary;
• Gutenberg body text sample;
• Built-in prompts;
• Thinking disabled;
• Random sampling disabled;

For a fair comparison.

Only if another model significantly outperforms GLM-5.2 in technical accuracy, English naturalness, structure preservation, and long-text stability will it be necessary to continue modifying the model compatibility logic in the production environment.

Summary

The most important takeaway from this round of optimization is not finding a parameter that suddenly boosts translation quality, but rather gradually clarifying the functional boundaries of each layer:

• do_sample=false mainly improves stability;
• Prompts can improve title and body text organization, but cannot completely break through the model’s capability ceiling;
• Titles, summaries, and body text require different prompt strategies;
• Stable prompts are better built into the code rather than manually pasted each time;
• The translation benefits of deep thinking are unstable;
• A faster model is not necessarily more accurate;
• Model capabilities and WordPress adaptation issues should be tested separately;
• Calling the official API directly locally is more suitable for model experimentation than repeatedly modifying code in the production environment.

Currently, GLM-5.2 with deep thinking disabled, random sampling disabled, and combined with built-in multi-field prompts, is the relatively stable, balanced, and practically usable configuration in this SlyTranslate automated translation solution.