From Unanswered Emails to the Official Go Local: My Four A Tour of Go Translation Sites Are Finally Listed

On September 11, 2026, I opened the official Go A Tour of Go again:

https://go.dev/tour/welcome/2

In the language list of Go local, you can now see:

• French — Français
• German — Deutsch
• Korean — 한국어
• Simplified Chinese — 简体中文

These 4 links ultimately all point to the multilingual translation project for A Tour of Go that I have been maintaining long-term.

Looking at the result, this matter seems very simple: apply to the official Go project to add a few translation sites to the language list.

But the actual process was much more complicated than I initially expected.

At first, I tried reaching out via email; after receiving no reply, I decided to switch to a GitHub Issue. Later, I went through a series of issues including ad requirements, link boundaries between the Tour and other site content, the issue feedback entry, and production environment modifications.

Ultimately, from the first attempt to contact them to the 4 languages officially appearing on go.dev, this matter finally came full circle.

This project actually started with Go local

I actually knew very early on that A Tour of Go had a Go local page:

https://go.dev/tour/welcome/2

You could even say that my initial decision to start this project was directly related to this page.

At the time, I noticed that the original Simplified Chinese translation in Go local was no longer accessible.

It was precisely because I saw this gap that I began to consider:

Could I maintain a long-term accessible Simplified Chinese version that continuously tracks upstream updates myself?

Later, this gradually expanded from a Chinese translation project into a multilingual translation project:

https://github.com/shuijingwan/go-tour-i18n

So, applying to enter Go local wasn’t something I just thought of recently.

From the very beginning of the project, this was actually a very natural long-term goal.

Initially, I chose to send an email

Originally, I didn’t create a GitHub Issue directly; instead, I first sent an email to golang-nuts.

The first email was sent on August 22, 2026, primarily applying to add the Simplified Chinese version.

After a week without a reply, I followed up again on August 29.

By then, the German version was also completed, so the second email included the German site as well, and I asked:

If third-party language listings are more suitable for submission via code changes or other methods, I hoped they would let me know the recommended process.

But the email still went unanswered.

At this point, I started to feel that continuing to wait was pointless.

Go itself is an open-source project that heavily relies on GitHub Issues and Gerrit. Since this was a clear website modification request, submitting an Issue directly might actually be the more appropriate approach.

Shifting from email to GitHub Issue

So, I finally created:

golang/go#81336

https://github.com/golang/go/issues/81336

This time, I didn’t just apply for Chinese.

At the time, there were 4 languages that met the conditions for stable maintenance:

• Simplified Chinese
• French
• German
• Korean

My thinking was actually quite simple:

These translations all come from the same repository and the same maintenance process, and they will continuously track the upstream A Tour of Go.

If the official project was willing to accept them, rather than applying separately each time a language was completed, it would be better to submit the currently mature versions together.

After the Issue was created, things finally started to progress.

But the first real issue wasn’t translation quality.

It was ads.

The first surprise: The official Go project doesn’t accept Tours with ads

These sites of mine have been live websites from the very beginning.

Since they require servers, domains, CDNs, and maintenance time, I also integrated Google AdSense, hoping to slightly offset some of the long-term maintenance costs.

Initially, I thought that as long as the ads didn’t block the tutorial content, it shouldn’t be a big problem.

At the time, the course pages primarily had:

• Auto Ads;
• one manual ad slot on the course page;
• some automatic ad formats.

When the maintainer first gave feedback, she mentioned the ad pop-up in the lower left corner of the page.

So, I first turned off ad formats like pop-ups and anchors that were more disruptive to the learning experience.

I originally thought this would be enough.

Later, the maintainer further clarified that she was referring to the display ads on the page, and explicitly stated:

As far as I’m aware, the other Go local tours linked from https://go.dev/tour/welcome/2 do not have any display ads. We won’t be able to link to these translations unless they are free of ads.

In other words, this was no longer a matter of:

“No intrusive ads.”

But rather:

If they are to enter Go local, the Tour itself must be ad-free.

At this point, I actually struggled with it for a long time.

Is it worth giving up Tour ads for an official entry point?

This isn’t a purely technical issue; it’s a business trade-off.

I prioritized translating /tour first because I believe A Tour of Go is very high-quality content.

Users who are actually studying the Tour often click through many course pages consecutively.

From an advertising perspective, these pages are actually valuable.

If a language joins Go local, it means the entire /tour/... for that language must remain ad-free.

If 10 or 20 languages meet the conditions and apply for official links in the future, it means more and more Tour pages will give up direct ad monetization.

So what I was really considering at the time was:

Is sacrificing the Tour’s direct ad revenue in exchange for the official Go entry point worth it?

Later, I still decided to accept this condition.

The reason wasn’t that ads are unimportant, but because I felt the official Go entry point itself might bring another kind of long-term value.

The value of the official Go entry point is more than just a backlink

I have never viewed these translation sites as competing with go.dev.

go.dev primarily provides English content, while the sites I maintain target users of different languages.

The two are inherently complementary.

If we’re talking about competition, it’s more about competing with other third-party translations or tutorial sites within the same language, rather than competing with the official English Go site.

So what I was really considering was another matter:

If users are already going to the official Go page first, could we make the official page directly serve as the entry point for these community translations?

Once included in Go local, the access path becomes:

go.dev → 对应语言的翻译站

This means users don’t need to first use a search engine to figure out which third-party translation site is more trustworthy; they can directly enter from the language entry points listed by the official Go site.

This kind of value cannot simply be measured by how much ad revenue /tour loses.

It could at least include:

• Direct traffic brought by the official entry point;
• The trust endorsement provided by the official Go page;
• High-quality backlinks;
• Potential subsequent brand awareness and return visits;
• Potential long-term impact on search engine crawling and indexing.

So I ultimately decided:

For languages applying for Go local, the Tour will be ad-free;

Other languages that haven’t entered Go local will maintain normal commercial capabilities.

The project later formally distinguished these two modes as:

• go-local
• standard

Currently, go-local consists of:

• zh-CN
• fr-FR
• de-DE
• ko-KR

While the other languages remain standard.

This way, the entire project’s languages won’t be permanently bound to the same set of commercial restrictions just because of the official requirements for 4 languages.

It wasn’t just about turning off ads; links within the Tour also needed adjustment

After the ad issue was confirmed, a more specific requirement emerged.

Many original pages in A Tour of Go contain root-relative links like these:

• /doc/...
• /blog/...
• /pkg/...
• /cmd/...
• /ref/...
• /talks/...

On go.dev, these links would originally lead to official Go content.

But on my independent translation domain, they would be parsed by the browser as paths under the current site.

This is actually directly related to my subsequent project planning.

I don’t intend to only translate /tour.

These 4 languages are still planned for further expansion:

• /doc
• /blog
• and other Go-related content

And I do not plan to give up ad displays for these non-Tour contents.

So initially, I actually hoped to form an in-site path like this in the future:

/tour → 本站 /doc /blog

This way, after finishing the Tour, users could continue reading more Go content on the same language site.

But during the communication, the maintainer explicitly requested:

Content accessed directly by clicking from the Tour also cannot land on ad-bearing pages on this site.

This meant that if I actually launched the site’s /doc and /blog in the future, those root-relative links in the existing Tour would lead directly to ad-bearing content, no longer meeting Go local’s requirements.

Therefore, I changed links in the Tour that originally belonged to official Go content, such as /doc, /blog, /pkg, /cmd, /ref, and /talks, back to their corresponding:

https://go.dev/…

This doesn’t mean I will give up on the subsequent /doc and /blog for these 4 languages.

On the contrary, I still plan to continue translating and expanding this content, and /doc and /blog will still retain ad displays.

What really changed is the entry point relationship.

I no longer let these links in /tour go directly to the site’s future commercialized content; instead, I plan to place the entry points for /doc and /blog on the site’s homepage.

The resulting path is more like:

Go 官方 → /tour → 本站首页 → /doc /blog

Rather than:

Go 官方 → /tour → 直接进入带广告的 /doc /blog

For me, this boundary is acceptable.

Although it sacrifices the Tour’s ability to directly drive traffic to other content, it doesn’t give up the commercialization space for the rest of the language site.

Another detail: When users find issues, where should they report them?

After the ad and link issues were mostly resolved, Go maintainer Dmitri Shuralyov noticed another very practical issue:

If issues arise with these community translations, where should the “submit feedback” in the top right corner point to?

Initially, my translation site still used the upstream configuration:

https://go.dev/doc/contribute#check_tracker

But this was actually unreasonable.

Because issues users encounter on my translation site are likely to be:

• Translation errors;
• Locale-specific issues;
• UI issues;
• Deployment issues;
• My project’s own implementation issues.

Sending these issues directly to the official Go project would instead increase the burden on upstream maintainers.

So I accepted the suggestion and changed the unified feedback entry point to:

https://github.com/shuijingwan/go-tour-i18n/issues

From then on, the process was clear:

Users first report issues to my translation project.

If I confirm the issue originates from the Go upstream, I will organize it and submit it upstream myself.

This is actually an open-source maintenance approach I highly approve of.

Since I want the official Go project to link to these sites long-term, I should naturally assume the corresponding first-tier maintenance responsibility.

A minor caching incident with the French site

After deploying the feedback entry point, I updated and verified the Chinese, French, German, and Korean sites respectively.

But during testing, the maintainer found:

Simplified Chinese, German, and Korean all correctly redirected to the new GitHub Issues, while clicking the French one seemed to just open the current page in a new tab.

I re-checked production:

• deployment PASS;
• machine acceptance PASS;
• browser acceptance PASS;
• visual HUMAN gate PASS.

I then tested the French site using both a normal browser and an incognito window.

Both correctly opened:

https://github.com/shuijingwan/go-tour-i18n/issues

So I replied to her:

It might be that the browser still has old JavaScript cached; she could try a hard refresh.

The maintainer later confirmed:

Thanks! It’s working for me now. Will merge the change to add these to the website.

At this point, I basically knew this endeavor had succeeded.

Only code merging and official website deployment remained.

CL 829864: 4 translations officially enter the Go website source code

The corresponding changes subsequently entered Go Gerrit:

https://go-review.googlesource.com/c/website/+/829864

The submission title was very direct:

_content/tour: add translations

It was ultimately merged into golang/website.

Corresponding commit:

db076098077c07d3cef1b85a2cf56ff52777f587

Issue #81336 was subsequently marked as completed and closed by GopherBot.

This change added a total of 4 links:

• French
• German
• Korean
• Simplified Chinese

From this moment on, the application itself was officially successful.

But I was still waiting for the final step:

The actual deployment to the go.dev production site.

September 11, 2026: Officially online

On September 11, 2026, I opened again:

https://go.dev/tour/welcome/2

This time, all 4 languages were present in the public production environment.

This image is more meaningful to me than a merged commit.

Because it represents not just that the code has entered the repository, but that:

Regular Go users can now actually click through to these translation sites from go.dev.

At this point, from the initial unanswered email to finally entering the official Go local, this matter has finally come full circle.

Looking back, the biggest cost this time wasn’t development time

If we only look at the technical modifications, this wasn’t particularly difficult.

What really made me hesitate repeatedly was actually:

Was it worth giving up /tour ads for the official link?

There is no answer yet.

It has just gone live, so it’s impossible to draw a conclusion from a day or two of data.

But at least one thing has changed:

Previously, these sites could only rely on:

• Search engines;
• GitHub;
• My blog;
• Direct visits;
• Other natural backlinks.

Now there is an additional, very special entry point:

go.dev itself.

And I have acquired 4 experimental samples at once.

I can use:

• zh-CN
• fr-FR
• de-DE
• ko-KR

as the go-local group;

and use:

• ja-JP
• es-ES
• it-IT
• nl-NL
• pt-BR
• and other future languages

as the standard group.

Then I can actually observe:

• How much traffic go.dev referrals can bring;
• Whether it increases the return visit rate;
• Whether it improves search engine crawling and indexing;
• Whether it brings better brand awareness;
• Whether the official backlinks generate SEO value;
• Whether these benefits can offset the ad revenue lost by the Tour itself.

This will be more valuable than any theoretical analysis.

I plan to treat September 11, 2026 as Day 0

Next, I plan to observe separately:

• 7 days;
• 30 days;
• 90 days.

I will pay particular attention to the differences between the 4 Go local languages and the other standard languages.

If I find in the future that:

Official links can indeed consistently bring stable traffic, and noticeably improve search performance, return visits, and brand awareness,

Then for languages not yet covered by Go local that also have high commercial potential, I might continue to adopt:

Ad-free Tour ↔ Official Go entry point

This model.

Conversely, if after a few months I find:

Official referrals are scarce, SEO shows no obvious changes, and brand benefits are unclear, then I will also know:

There is no need to continue sacrificing Tour ads for more languages in exchange for official links in the future.

There is no need to jump to conclusions yet.

Let the data speak for itself first.

Next up: Syncing with upstream again

After this official launch, I am ready to immediately do one more thing:

Re-sync with the A Tour of Go upstream.

The reason is very simple.

These 4 sites have now become community translations that will be directly linked to from the official Go page.

Since I have gained this entry point, I also want users entering these sites to see the latest A Tour of Go content as much as possible.

I will continue to maintain:

https://github.com/shuijingwan/go-tour-i18n

And gradually add more languages.

However, for languages that already have other official community translations, I will not aim to replace them.

Whether new languages will continue to apply for Go local will also be judged based on the real data of these 4 languages over the next few months.

Less than a day after launch, go.dev is already driving noticeable traffic

After the official link went live, I originally thought I would need to observe for a period of time before seeing any obvious traffic changes.

But the actual effect appeared faster than I expected.

As of noon on September 11, 2026, Baidu Tongji had already shown very obvious changes.

On that day, the source PV from go.dev had reached 438, accounting for 64.41% of the referring websites’ PV, making it the primary referring website for the day.

Looking at the entry pages, this traffic clearly went to A Tour of Go:

• /tour: 251 PV, accounting for 36.86%
• /tour/welcome/1: 140 PV, accounting for 20.56%
• Other specific Tour pages have also appeared among the main entry pages

This set of data is very meaningful to me.

To enter Go local, I accepted a clear condition: The Tour pages for these 4 languages accepted by the official Go project cannot continue to display ads.

In other words, I did give up the possibility of these Tour pages directly generating ad revenue in the future, in exchange for the entry point provided by the official Go page.

Before it actually went live, I could only assume that being officially listed might bring traffic and brand endorsement, but I had no real data to prove how much traffic this entry point could actually bring.

Now, at least one of those questions has a very clear early answer:

Go local isn’t just a static link for brand endorsement; it does indeed bring very direct and quite noticeable traffic.

Of course, this is just data from less than a day after the official link went live.

A single day’s data cannot represent the next 30 days, let alone be used to judge long-term commercial value. Google Analytics’ real-time stats can already see visits at this point, but the standard “Traffic Acquisition” report for the day hasn’t finished processing yet, so here I am temporarily only using the data already generated by Baidu Tongji.

Next, I will continue to observe the data for 7 days, 30 days, or even longer to see how much of the traffic from go.dev can be retained, and whether these users will further visit the project homepage, GitHub, and future content like /doc and /blog.

So it’s still too early to say that the ad revenue given up for these 4 languages’ Tour pages has been “earned back.”

But at least one thing no longer needs to be guessed:

The official go.dev entry point has a very strong traffic-driving capability.

In conclusion

My intuitive takeaway from this experience is:

For many open-source projects, “official inclusion” really isn’t just about:

Whether you have translated the text.

It also includes:

• Whether the content is accessible long-term;
• Whether it is continuously maintained;
• Whether the page experience is appropriate;
• Whether the commercialization falls within the acceptable range of the official project;
• Who is responsible when issues arise;
• Where users should provide feedback;
• Whether the project has long-term maintenance capabilities.

Initially, I just wanted to apply for a link.

What I ultimately produced was a release strategy specifically tailored for Go local.

From a business perspective, I did pay a price:

The /tour for these 4 languages no longer directly displays ads, and the entry points in the Tour that originally might have continued to direct users to the site’s /doc and /blog also need to be isolated from future commercialized content.

But what I got in return is equally clear:

• An official Go entry point;
• High-quality backlinks from go.dev;
• Public visibility as a community translation;
• Lower user trust costs;
• A real experiment to observe the value of official traffic referrals long-term.

Before the official launch, the one thing I was most uncertain about was actually:

Could this go.dev entry point actually bring noticeable traffic?

Now, this question has a preliminary answer.

Less than a day after launch, go.dev has already become one of the primary referring websites for the day, and it accounts for a very high percentage.

This is still not enough to prove long-term commercial value, nor does it mean the losses from giving up Tour ads have been earned back.

But at least it can be confirmed that:

The official Go entry point is not just about “brand endorsement”; it does indeed possess a very strong direct traffic-driving capability.

So what I really need to observe next is no longer “is there traffic,” but rather:

• How long this traffic can last;
• Whether users will form return visits;
• Whether they will further visit the homepage, GitHub, and future /doc and /blog;
• Whether it will improve search engine crawling, indexing, and organic traffic;
• Whether it can ultimately generate enough long-term value to offset the opportunity cost of stopping ad displays on the Tour pages.

In other words, this experiment has moved on from:

Is the official entry point actually useful?

to the next stage:

How much is this entry point actually worth in the long term?

This answer still requires data from 7 days, 30 days, 90 days, or even longer to explain.

But at least starting from September 11, 2026, I no longer have to rely entirely on guessing.

The first batch of real data has already started to provide answers.

系列导航