A Tour of Go Chinese Translation: First 8 Pages Done, Present Syntax Fixed, and DeepSeek Comparison Deferred

On August 2, 2026, I officially started advancing the Simplified Chinese translation of the go-tour-i18n project and completed the full translation loop for the first page, welcome/1.

In the previous article, “A Tour of Go Multilingual Translation Project Record: Completing the First zh-CN Page Translation Loop“, I documented the page projection, glossary, Protected Token, development-stage retry mechanism, and the generation process of the first Chinese candidate.

After continuing development on the second day, the project has now completed 8 Simplified Chinese lesson pages:

• welcome/1
• welcome/2
• welcome/3
• welcome/4
• welcome/5
• basics/1
• basics/2
• basics/3

The Welcome chapter is fully complete, and the first three pages of the Basics chapter are also done.

However, the most important takeaway from this progress is not just adding a few translated pages, but rather further confirming the runtime semantics of the officially published pages, improving the Chinese prompts, and fixing an inline code protection issue hidden in the legacy present syntax.

1. The project currently adopts 103 officially published pages

The official source code of A Tour of Go contains 7 .article files.

Counted according to the standalone local runtime mode, there are originally 101 regular lesson pages. However, in the Welcome chapter, there are also two pages controlled by the #appengine: condition:

• Go offline
• The Go Playground

These two pages are expanded into independent pages in the official online runtime environment.

Since the goal of this project is to build a publicly released Chinese version, rather than just replicating the standalone local runtime results, the final adoption consists of 103 officially published pages:

• 101 regular pages;
• 2 conditional pages;
• While retaining 2 conditional source records for auditing.

The project did not directly modify the official original _content files, but instead generated the official pages at the release projection layer.

This approach keeps the upstream source code unchanged and clearly distinguishes between:

• Official original source code;
• Standalone local pages;
• Official release page projection;
• Chinese candidates;
• Final published content.

2. The Welcome chapter is fully complete

The Welcome chapter in the official release projection contains 5 pages:

1. Hello, 世界
2. Other language versions
3. Offline use (optional)
4. Go Playground
5. Congratulations

Among them, the first page went through multiple development attempts.

These attempts were not just repeatedly modifying the Chinese text, but gradually calibrating:

• Page projection;
• Conditional content handling;
• Protected Token;
• Glossary;
• System Prompt;
• Candidate validator;
• Development mode retry behavior.

All model requests, raw responses, and validation results are saved according to the source SHA and attempt number, without being overwritten by subsequent results.

3. Official release pages switch to remote execution semantics

welcome/1 contains a sentence explaining where the program is compiled and run after the user clicks the “Run” button.

The official source code provides two semantics for different environments:

• Standalone local Tour: runs on the user’s computer;
• Official online Tour: runs on a remote server.

The local Tour registers /socket and invokes the server’s local Go toolchain to execute the code. This approach is suitable for developers running it on their own computers, but it cannot be directly exposed to a production environment.

The production site for this project will not directly expose the local /socket, so the official release projection ultimately adopts:

Compile and run this program on a remote server.

At the same time, the original standalone Tour behavior in the repository remains unchanged.

That is to say:

• The original local Tour still uses the your computer branch;
• The Chinese official release projection uses the a remote server branch;
• The 6 translation attempts previously saved under the old source are retained;
• No fake model invocation records will be created just to switch the release projection.

This step further clarifies that lesson translation cannot be handled in isolation from the final release environment.

4. Starting to translate official Go technical pages

After completing the Welcome chapter, I started translating the Basics chapter.

Currently, the first three pages are complete.

1. Packages

The Chinese title is set to:

包

This page introduces:

• Go programs consist of packages;
• Programs start running from the main package;
• How to use fmt and math/rand;
• The relationship between package names and import paths.

The Chinese generated by GLM-5.2 is overall natural and accurate, and can basically be used directly.

This page consolidated three basic terms:

• package → 包
• import path → 导入路径
• package name → 包名

2. Imports

The Chinese title is set to:

导入

The sentence initially generated by the model was:

This code places the import paths in a parenthesized “grouped” import statement.

The technical meaning is mostly correct, but “places the import paths in” is slightly mechanical and does not fully convey the meaning of multiple imports being organized together.

It was finally adjusted to:

This code organizes multiple imports in a parenthesized “grouped” import statement.

Another original translation was:

But using a grouped import statement is better style.

Finally adjusted to:

However, using a grouped import statement is better code style.

This page adds the term:

• import statement → 导入语句

3. Exported names

The Chinese title was finally set to:

导出名

The model’s original title was “导出的名称”, which is not incorrect in meaning, but in the Go technical context, “导出名” is more concise and more consistent with the common expression used by Chinese developers.

The model’s original body text included:

If a name starts with a capital letter, it is exported.

Finally adjusted to:

In Go, a name that starts with a capital letter is exported.

The final operation instruction was also changed from:

Then try again.

Adjusted to:

Then run it again.

This page adds the terms:

• exported name → 导出名
• unexported name → 未导出的名称

5. Discovering a backtick structure that looks like an error

While checking the Packages page, I noticed the following snippet in the official source code:

`package`rand`

`package`rand`

If understood as standard Markdown, this content appears to have obvious issues:

• `package` is inline code;
• rand is plain text;
• There is an extra backtick at the end.

However, after checking the HTML of the official online page, the actual rendered result is:

<code>package rand</code>.

<code>package rand</code>.

The structure here is completely correct:

• package rand is a complete code node;
• The space is inside the code node;
• The English period is located after </code>.

The reason is that A Tour of Go does not use standard Markdown, but rather the legacy present syntax.

In this syntax, a single backtick appearing inside a code span is converted to a space.

Therefore:

`package`rand`

`package`rand`

ultimately represents:

package rand

package rand

The source file itself has no errors, and the official page projection did not break this content.

6. The real issue occurs at the Protected Token layer

Although the official source code and the final page rendering are both correct, the project’s own protector did not fully understand this present syntax.

The regex used by the original protector was similar to:

`[^`\n]+`

`[^`\n]+`

When this regex encounters the first subsequent backtick, it assumes the inline code has ended.

Therefore:

`package`rand`

`package`rand`

is incorrectly split into:

`package`

`package`

and the unprotected:

rand`

rand`

The page fragment the model actually received was similar to:

... statement ⟪GTI18N_f769f12c_000006⟫rand`.

... statement ⟪GTI18N_f769f12c_000006⟫rand`.

Here, the Protected Token only corresponds to `package`, while the trailing `rand“ is still sent to the model as plain text.

This time, GLM-5.2 happened not to modify the remaining content, so after Token restoration, the candidate still retained the original valid present syntax.

However, this success was clearly coincidental.

In the future, the model could very well:

• Move rand;
• Delete the trailing backtick;
• Treat rand as plain English;
• Adjust the order of the Token and rand.

Therefore, even though the current candidate can pass the validator, this protection logic must still be fixed.

7. Fixing legacy present inline code protection

After the fix, the protector can recognize the entire present inline code as a complete unit.

Now:

`package`rand`

`package`rand`

is mapped as a whole to:

⟪GTI18N_f769f12c_000006⟫

⟪GTI18N_f769f12c_000006⟫

Its semantic content is:

package rand

package rand

During Token restoration, it is verbatim restored to the official original present source code:

`package`rand`

`package`rand`

Finally, it is still correctly rendered by present as:

<code>package rand</code>

<code>package rand</code>

This fix added corresponding regression tests, covering:

• Inline code for ordinary words;
• Code containing one internal space;
• Code containing multiple internal spaces;
• Punctuation boundaries after code;
• Complete mapping of Protected Tokens;
• Verbatim restoration after Token restoration;
• Structural comparison by the candidate validator;
• Ensuring no unprotected `rand“ remains on the Basics Packages page.

This issue demonstrates once again:

Structural consistency between the candidate and the source does not guarantee that the source protection process before entering the model was correct.

If the protector first incorrectly splits valid source code, the model response may remain consistent with the incorrect protection result and still pass subsequent validation.

Therefore, in addition to validating model output, tests consistent with the official present parsing behavior must be established for the protector itself.

8. Originally planned to test DeepSeek, but ultimately postponed

At the end of the previous project record, I originally planned to pause the continued translation of pages to test the new version of DeepSeek before deciding which model the A Tour of Go project should primarily use next. (永夜)

DeepSeek was considered at the time for two main reasons.

First, a significant amount of GLM-5.2’s paid Tokens had already been consumed. If we were to translate all 103 pages next, and even expand to other languages, it would be necessary to evaluate whether a model with more suitable quality, speed, and cost existed.

Second, DeepSeek had just released a new model update. I originally hoped to use the same complete lesson page to compare under completely identical conditions:

Complete lesson page
→ Same Protected Token
→ Same glossary
→ Same prompt requirements
→ Same present parsing and structural validation
→ Compare Chinese quality, first-pass rate, speed, and cost

Complete lesson page
→ Same Protected Token
→ Same glossary
→ Same prompt requirements
→ Same present parsing and structural validation
→ Compare Chinese quality, first-pass rate, speed, and cost

Previously, I had indeed conducted a comparison between deepseek-v4-pro and GLM-5.2.

However, that test occurred in a WordPress technical blog translation scenario, not an A Tour of Go lesson page translation scenario.

The goal at the time was to evaluate whether DeepSeek was worth integrating into the existing full-article WordPress blog translation workflow. The test script provided both models with the same Chinese content, prompts, and test fields for the title, summary, and body.

The test results showed:

• DeepSeek V4 Pro had faster response times;
• Titles were more concise, but some technical information was omitted;
• Summaries leaned more towards compressing and reorganizing content;
• The body text had minor paragraph transition and reference issues;
• GLM-5.2 retained the original information more completely;
• GLM-5.2’s tone for technical articles and paragraph independence were more stable.

Therefore, the precise conclusion drawn at that time was not “DeepSeek is inferior to GLM-5.2 in A Tour of Go translation”, but rather:

In a baseline A/B test oriented towards the full-article WordPress technical blog translation workflow, DeepSeek V4 Pro did not demonstrate a stable quality advantage sufficient to replace GLM-5.2.

That test also did not invest a large amount of time to replicate the full Gutenberg long-form protection and restoration logic into the local A/B script. For a more detailed testing process, you can refer to “Testing DeepSeek after GLM 5.2: A Model Comparison and Trade-off for WordPress Long-form Translation“. (永夜)

The reason I considered retesting this time was that I thought DeepSeek V4 Pro had released an updated version.

After further checking the official update log, I found that the model actually updated on July 31, 2026, was:

DeepSeek-V4-Flash-0731

DeepSeek-V4-Flash-0731

The official documentation explicitly states:

• This time, only the DeepSeek-V4-Flash API was upgraded;
• The DeepSeek-V4-Pro API was not updated;
• The APP and Web models were not updated either;
• The officially updated V4-Pro still needs to wait for a subsequent release. (DeepSeek API Docs)

The official documentation at the time also showed that the Responses API only supported deepseek-v4-flash, and support for deepseek-v4-pro was expected to be added in early August 2026. (DeepSeek API Docs)

What I really want to re-evaluate is the updated Pro version, not the Flash version whose main advantages are speed and cost.

If I continue to call deepseek-v4-pro now, I am actually still testing the previously evaluated model that has not yet completed a new round of updates.

Under these circumstances, even if I run through the A Tour of Go pages again, it would be difficult to draw a truly meaningful “new version comparison” conclusion, and it would only incur extra consumption of:

• Development time;
• API Tokens;
• Codex usage quota;
• Model adaptation and result analysis costs.

Therefore, the final decision is:

Temporarily postpone this round of DeepSeek comparison and continue using the already calibrated GLM-5.2 to advance the project.

“Postponing” here does not mean permanently excluding DeepSeek.

Once DeepSeek officially releases the new V4-Pro version, and it can be confirmed that the model version or actual capabilities have changed, I will then use go-tour-i18n‘s existing unified workflow for testing:

• Same pages;
• Same Protected Token;
• Same glossary;
• Same translation prompts;
• Same candidate validator;
• Same page rendering and structural validation.

Only results obtained this way will have true comparative value.

9. How is GLM-5.2 currently performing

Judging from the official technical pages completed so far, GLM-5.2’s overall performance is relatively stable.

As of basics/3, the following have not been found:

• Obvious mistranslations of Go technical concepts;
• Omission of key content;
• The model adding its own explanations;
• Broken .play paths;
• Changes to inline code content;
• Changes to preformatted code;
• Broken present page structures;
• Modified link targets.

The general situation for the three Basics pages is:

• basics/1: Can basically be used directly;
• basics/2: Needs minor Chinese polishing;
• basics/3: Needs minor Chinese polishing.

The content that currently needs adjustment is mainly concentrated on Chinese expression, rather than technical accuracy.

For example:

• Titles being too literal;
• Sentences retaining English word order;
• Mechanical expressions like “is better style”;
• “Try again” not accurately describing the actual operation;
• Go-specific terminology not being concise enough.

This shows that GLM-5.2 can already reliably complete the initial translation of full technical pages, but the first three simple pages alone cannot directly prove that all remaining complex pages can be batch-published entirely without human observation.

10. Will not continue advancing the remaining pages one by one

In the early stages of the project, a strict single-page workflow was adopted:

Complete lesson page
→ GLM-5.2 full-page translation
→ Save candidate
→ Automatic validation
→ Check Chinese quality
→ Update glossary or protection rules
→ ready

Complete lesson page
→ GLM-5.2 full-page translation
→ Save candidate
→ Automatic validation
→ Check Chinese quality
→ Update glossary or protection rules
→ ready

This approach is very suitable for the first few pages.

It has already helped the project discover and resolve:

• Production page projection issues;
• Semantic differences between local execution and remote execution;
• Fixed UI terminology issues;
• Distinction between regular body text and proper names;
• Legacy present inline code issues;
• Development-stage retry limit issues;
• Mechanical expression issues in Chinese prompts.

However, if the remaining ninety-plus pages are still translated, returned, reviewed, modified, and submitted one by one, the overall efficiency will be very low.

Moreover, continuously translating the short pages at the beginning of Basics cannot cover the entire structure and technical complexity of A Tour of Go.

Therefore, moving forward, instead of directly continuing with basics/4, the approach will change to a three-phase advancement.

11. The next phase will first select representative pages

In the first phase, about 5 to 7 representative pages will be selected from different chapters.

These pages should cover as much as possible:

• Longer technical explanations;
• Exercise pages;
• Special present structures;
• Methods and interfaces;
• Generics;
• Goroutines and channels;
• .image pages;
• Other rare directives.

This batch of pages will still use single-page translation and full review.

The goal is not to continue increasing the ready count, but to confirm as soon as possible:

• Whether the protector still misses other present syntax;
• Whether GLM-5.2 can accurately handle complex Go concepts;
• Whether the glossary is already stable enough;
• Whether the System Prompt still needs adjustment;
• Whether long pages will experience truncation, repetition, or context issues.

12. Trial run of 10 pages after representative pages are stable

After the representative pages are completed, 10 regular pending pages will be automatically translated at once.

These 10 pages serve as a pre-production batch before the full run.

The main observations are:

• Whether they all pass structural and candidate validation;
• Whether issues requiring protector modifications reappear;
• Whether technical concept mistranslations occur;
• Whether widespread glossary conflicts occur;
• Whether the System Prompt needs further adjustment;
• Whether most pages can be used directly or only need very light polishing.

This step will no longer pause and submit after translating each page, but will complete a batch and then analyze them uniformly.

13. Batch translation of remaining pages only at the end

If both the representative pages and the 10-page trial run remain stable, the program can be allowed to automatically process the remaining pages:

pending
→ Automatic translation
→ Automatic validation
├─ Pass → ready
└─ Fail → Limited retry
             └─ Still fails → blocked

pending
→ Automatic translation
→ Automatic validation
├─ Pass → ready
└─ Fail → Limited retry
             └─ Still fails → blocked

Pages entering blocked can be exported as full pages, re-translated by ChatGPT, and then enter the same automated validation.

It should be specifically noted that:

Batch automated translation does not mean automated publishing.

Even if candidates are generated for all remaining pages, the following still need to be completed:

• Present re-parsing;
• Page structure comparison;
• .play, .image, and link validation;
• HTML rendering validation;
• Page routing validation;
• Chapter-level sampling;
• Pre-publishing checks for the entire site.

Only pages that pass these checks are allowed to enter the final publishing workflow.

14. Current phase summary

As of now, the go-tour-i18n project has completed:

• Pinning the official upstream commit;
• The directory of 103 officially published pages;
• 2 conditional source page audit records;
• Full translation of the Welcome chapter;
• Translation of the first 3 pages of Basics;
• A total of 8 zh-CN pages entering ready;
• Retention of GLM-5.2 requests, responses, and validation records;
• Candidate and page state management;
• Gradual accumulation of the Chinese glossary;
• Correction of the official release remote execution semantics;
• Fix for legacy present inline code protection;
• Source SHA and upstream content tracking;
• Candidate validator;
• Distinction between development mode and production mode retries;
• Strategy for cross-chapter representative pages, a 10-page trial run, and full translation;
• Verifying that DeepSeek only updated V4-Flash this round, and postponing the model comparison because V4-Pro has not yet been updated.

When the project started, I originally thought the main question was:

Can AI translate the Go tutorial well?

Only after actually starting the implementation did I realize that model translation is just one component of the entire system.

A multilingual project that can be maintained long-term must also solve:

• How to keep page identities stable;
• How to synchronize upstream updates;
• How to generate the official release projection;
• How to correctly protect special syntax;
• How to audit model invocations;
• How to avoid false positives in automated validation;
• How to maintain terminology consistency;
• How to distinguish between local runtime and production runtime;
• How to recover failed pages;
• When it is worthwhile to re-evaluate the model;
• When it is appropriate to proceed with batch translation.

Although only 8 pages have been completed so far, the project’s translation, validation, and state management foundations have gradually stabilized.

The most important thing next is not to increase the number from 8 pages to dozens as quickly as possible, but to confirm whether the entire workflow truly has the conditions for safe batch execution through a small number of representative complex pages.