没有不值得去解决的问题,也没有不值得去学习的技术!

多语言项目应该先做哪些语言?我的 66 个语言版本商业优先级排序

作者:

在

A Tour of Go 多语言翻译项目

图3:访问过去的 Go Tour 简体中文站 tour.go-zh.org 时,当前已经无法正常建立连接。

(1) 从「A Tour of Go 中文版」这个搜索词开始:我决定做一个持续维护的 Go Tour 中文版

本地运行的 A Tour of Go「Methods continued」课程页面,左侧为课程说明,右侧为 Go 代码编辑器及运行结果。

(2) A Tour of Go 中文版项目设计冻结:从 101 页到 103 页,从 Gin 转向 Cobra CLI

A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

(3) A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

go-tour-i18n 项目完成首个简体中文课程页面 welcome/1 的整页翻译、结构校验和本地预览。

(4) A Tour of Go 多语言翻译项目实录:完成首个 zh-CN 页面翻译闭环

图 1:DeepSeek 官方更新日志显示,本次只更新 DeepSeek-V4-Flash,DeepSeek-V4-Pro API 与 APP、Web 模型均未更新

(5) A Tour of Go 中文翻译项目进展:完成前 8 页、修复 present 语法,并暂缓 DeepSeek 对比

图 1:generics/1 简体中文页面本地预览

(6) 一个页面重试五次:使用 GLM-5.2 翻译 A Tour of Go 时遇到的 Token 与 Present 结构问题

图 1:methods/16 简体中文页面浏览器预览

(7) A Tour of Go 中文翻译实录:如何只翻译教学代码注释,而不破坏 Go 代码

图 2:A Tour of Go methods/20「练习:错误」中文候选页面最终渲染效果

(8) A Tour of Go 多语言翻译:当正确的中文语序被受保护标记顺序校验误判

图 3:methods/24 中文页面,静态代码、Bounds 行内代码和链接内的 image.Rectangle 均正确渲染

(9) A Tour of Go 中文翻译完成 7 个代表页校准:最后 3 页又发现了哪些真实问题

图 2:首批 10 个普通页面经过试跑与流程校准后全部进入 ready

(10) A Tour of Go 多语言翻译项目:首批 10 个普通页面试跑,从 2 个 blocked 到全部 ready

图 2:flowcontrol/6 最终中文页面,return 与 v 为适应自然中文语序发生整体换位

(11) A Tour of Go 中文翻译第二批实跑:从 Inline Code 顺序误判到历史响应重新验证

图 1:flowcontrol/6 首次原始输入实验直接通过统一自动校验

(12) A Tour of Go 多语言翻译项目:从 swap 问题重新审视 Token 保护,原始输入与最小保护的一次真实实验

图 7:moretypes/1 最终中文页面预览。左侧课程正文、静态代码块、行内代码和教学注释均正常渲染,右侧官方 Go 示例继续保持原样。

(13) A Tour of Go 多语言翻译实战:第三批 10 页全部 Ready,继续校准 Protected Token 的结构角色

图 4:上游源码确认共有 103 个课程页面,zh-CN 最终达到 ready=103、pending=0、blocked=0

(14) A Tour of Go 多语言翻译项目:zh-CN 103 个课程页面全部 ready,课程正文翻译阶段完成

图 4:GitHub 与 ChatGPT 已成功连接

(15) ChatGPT 连接 GitHub 实测:让 AI 直接读取 go-tour-i18n 仓库参与译文审核

图 3:中文 Go 术语校准完成后,将确定的译法写入 zh-CN glossary

(16) 为什么 channel 最终选择“通道”:A Tour of Go 中文术语统一的一次实践

图 1:技术含义基本正确,但“返回一个返回……”已经明显影响阅读,因此仍被列入 C 类修订

(17) 103 页逐页审核后,只返修 16 页:A Tour of Go 中文正文发布前质量审计

图 2:中文课程页面以及已经完成本地化的编辑器控制区

(18) A Tour of Go 多语言翻译项目:公共 UI 本地化完成,从课程译文走向完整中文界面

图 2:完整 zh-CN 正式投影成功生成,103 个课程页面被重新组装为 7 个 .article

(19) 从 103/103 ready 到完整站点验收:A Tour of Go 中文版补齐正式投影与课程元数据本地化

图 3:从 production bundle 独立启动的 A Tour of Go 简体中文页面,课程正文、公共 UI 和官方 Go 示例均已进入最终发布形态。

(20) A Tour of Go 多语言翻译项目:103 页全部完成后,我终于生成了可独立部署的 zh-CN Production Bundle

图 1:A Tour of Go 简体中文版正式生产页面,远程运行已经成功输出“Hello, 世界”。

(21) A Tour of Go 多语言翻译项目:zh-CN 正式上线,从生产发布到 go.dev Playground 的完整部署记录

图 1:新生产域名 go-dev.shuijingwanwq.com 已正常访问,Go 示例远程运行成功

(22) A Tour of Go 多语言翻译项目:从 go-tour 到 go-dev,完成 EdgeOne、Nginx 与 HTTPS 生产域名迁移

图 1:A Tour of Go 多语言翻译项目正式生产首页

(23) A Tour of Go 多语言翻译项目正式上线:从项目首页、公共 Footer 到生产发布元数据的完整收尾

图 3:GA4 g/collect 请求返回 HTTP 204,并携带当前课程页面地址,确认 Google Analytics 已产生真实事件上报

(24) A Tour of Go 多语言翻译项目:接入 Google Analytics 与百度统计,从 systemd 注入到 EdgeOne 与真实上报验证

图 1:生产环境 robots.txt 与 sitemap.xml 已正确对外提供,Sitemap 共包含 104 个规范 URL。

(25) A Tour of Go 中文站上线后:补齐 robots.txt、Sitemap,并完成五大搜索引擎提交

图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。

(26) A Tour of Go 多语言翻译项目:修复手机端首页顶栏标题换行,并完成真机验证

图 3:生产自动部署脚本第一次真实运行时,systemd 已经显示 active,但首次 localhost 探测仍然得到 HTTP 000;随后连续 3 次同时满足 active + HTTP 200 后,脚本才判定部署成功,并继续完成公网 HTTP 200 验收。这次真实运行验证了连续应用层健康检查的必要性。

(27) A Tour of Go 多语言翻译项目:从一次 203/EXEC 故障到生产自动部署脚本落地

图 1:阿里云生产环境访问 go.dev Playground 时出现 TLS 握手超时

(28) A Tour of Go 多语言翻译项目:为 Playground 搭建独立的 ZgoCloud 执行代理

图 3:清除 /tour/script.js 缓存后,Run 已直接请求 ZgoCloud /compile 并返回 HTTP 200

(29) A Tour of Go 多语言翻译项目:将生产 Run / Format 切换到 ZgoCloud 执行节点

【图 1:微信中运行 Go 示例时出现 Error communicating with remote server.】

(30) A Tour of Go 中文版手机端运行与格式化偶发失败排查:从间歇性报错到补强 Nginx 可观测性

【图 4:向 golang-dev 公开邮件列表发送 Playground 使用告知邮件并投递成功】

(31) A Tour of Go 多语言项目:为 Playground 代理增加唯一 User-Agent,并主动告知 Go 官方

【图 3:百度剩余 9 个核心 URL 提交成功,remain 归零】

(32) A Tour of Go 搜索引擎收录实测:从 Google 自然索引到百度主动提交与 Bing IndexNow

【图 1:当前正式中文 methods/24 页面,右侧示例代码运行成功】

(33) A Tour of Go 中文翻译完成后,我为什么重新评估 minimal-protect 翻译模式

【图 3:5 个页面 Request SHA256 完全一致,但 Response SHA256 全部不同】

(34) A Tour of Go 翻译实验:更多原始上下文为什么没有更好?从 157 个保护标记到 30 次重复盲评

图 3:3 个代表页 × 4 个评审模型,共 12 次匿名评审的完整排名与第一名票数。

(35) A Tour of Go 翻译质量再评估:minimal-protect 未达预期后,我开始比较 ChatGPT、Codex 与 GLM-5.2

图 2:GitHub 中的 chatgpt-zh-CN-008 重译批次。一个 Batch 同时保存 inputs、raw-responses、candidates、validation 和 retry 记录,GitHub 成为 ChatGPT 与本地翻译流水线之间的数据交接层。

(36) 没有 OpenAI API,我如何用 ChatGPT + GitHub 完成 A Tour of Go 103 页全量重译

图 1:103 个正式课程页面完成最终语义质量审核,结果为 A=103、B/C/D=0,同时不存在缺失、重复或额外页面。A/B/C/D 是本轮项目内部语义质量分级,并不是自动结构 validator 的结果。

(37) 103 页翻完还不能发布:A Tour of Go ChatGPT 译文的语义审核与 Canonical Promotion

图 3:7 个 article endpoint 的 production origin 与 EdgeOne 公网响应全部 exact match,同时新的 ChatGPT 译文标记存在,旧版译文标记已经消失。

(38) 103/103 与 7/7 Exact Match:A Tour of Go ChatGPT 新译文的最终线上验收

【图 2:upstream source preview】

(39) A Tour of Go 多语言翻译项目首次实现 upstream 同步机制:从一次性翻译到长期维护

图 2:A/B/C/D 质量评级规则,展示正式质量 rubric 与 Promotion gate。

(40) A Tour of Go 多语言翻译项目引入 Translation Quality Review:从自动验证到 AI 翻译质量控制

图 4:翻译后 Playground Example,展示中文注释与保持不变的 Go 代码结构。

(41) A Tour of Go 多语言翻译项目实现 Playground Example 本地化:从代码注释翻译到完整学习体验

图 5:公网页面验证广告脚本输出

(42) A Tour of Go 多语言翻译项目接入广告系统:从 AdSense 专用配置到通用 HTML 注入架构

图 3:百度统计单页应用设置

(43) go-dev 单页网站接入统计与 Google AdSense Auto Ads 验证记录

图 1:GitHub 仓库中的多语言翻译项目结构

(44) A Tour of Go 多语言翻译项目:选择日语作为第二语言并启动翻译验证

图 5:模型身份描述不一致

(45) A Tour of Go 多语言翻译项目中的 AI 协作异常排查:一次长期工程会话失效分析

【图 1:ChatGPT GitHub 写入流程调整说明截图】

(46) go-tour-i18n 翻译流程调整:从 ChatGPT GitHub 写入到本地 artifact 导入

图 4 展示了本次异常状态。

(47) go-tour-i18n 翻译自动化流程复盘:已验证的 ChatGPT 翻译能力在新任务中的稳定性问题

【图 6:全部评审结束以后才读取 secret key,完成最终揭盲】

(48) A Tour of Go 翻译质量再评估:Codex High 已接近 ChatGPT High,我决定调整默认翻译引擎

图 4:ja-JP 生产课程页实际运行 Go 示例

(49) A Tour of Go 日语版正式上线:第二门语言 ja-JP 完成生产发布

图 1:ja-JP 上线以后,先提交“新增语言标准化流程”

(50) A Tour of Go 多语言扩展复盘:为第三门语言建立标准化流程

图 1:课程正文结束以后,页面左侧仍然存在大块视觉空白,但 AdSense 并没有在这里插入展示广告。

(51) A Tour of Go 明明有大片空白,为什么 AdSense 就是不显示展示广告?

图 2:golang/website 当前的 _content/tour/。课程内容、静态资源和模板都在这个上游目录中持续维护。

(52) 为了 AdSense,要不要放弃 SPA?A Tour of Go 页面架构的一次取舍

图 4:最终的手动课程广告真实展示在课程内容区域内,而不是 footer 之后。

(53) 保留 SPA 以后,广告应该放在哪里?从 AdSense 预览到方案 B

图 1:Google Search Console 中,多个不同的 A Tour of Go 课程 URL 被判断为“重复网页,用户未选定规范网页”。

(54) SPA 的 SEO 老问题:为什么最后还是给 103 个 A Tour of Go 课程页生成了 Prerender HTML

图 2:方案 B 生产环境中,源码已经正常,但课程主体高度异常缩短,footer 提前进入第一屏。

(55) 从源码空白到 AdSense 高度污染:A Tour of Go 方案 B 的生产收尾

图 1:A Tour of Go 德语版 de-DE 已正式运行在生产环境

(56) A Tour of Go de-DE 上线复盘:第三门语言用了约 16 小时,下一门如何压到 8 小时?

图 1:fr-FR 首次 production 验收完成后,我没有立即开始 ko-KR,而是先连续完成新增语言与首次生产流程的优化

(57) 法语版上线后,我没有马上开始韩语:A Tour of Go 新增语言流程的一轮完善与简化

图 1:根据 ko-KR 期间 76 次 Git 提交估算实际工作时间

(58) 原本预计 6 小时,最后用了约 16~18 小时:A Tour of Go 韩语版上线复盘

图 2:英文 source 与当时发生 validation failure 的 ko-KR candidate 对比

(59) Validator 报错,到底该改译文还是改规则?一次 A Tour of Go 韩语翻译实战

图 2:法语 A Tour of Go 仓库目前已经归档,页面仍保留 553 Commits 和 61 Contributors 的历史

(60) 从法语 553 次提交到韩语两代离线:A Tour of Go 社区翻译为什么难以长期维护

【图 4:es-ES 首次 Production 收口后连续完成的流程优化 commit】

(61) 从 es-ES 首次上线复盘:我把 A Tour of Go 新增语言的 Production 流程又收敛了一轮

图 1:旧公网验收链路连续出现 curl 28 超时,最终导致 public-machine 阶段失败

(62) A Tour of Go Production 公网验收踩坑:从跨境 SOCKS 链路改为 zgocloud direct

图 1:两次 Production Machine Acceptance 都已经通过,但 Headless Chrome 分别在 / 和 /tour/ 判定页面没有完成渲染

(63) 页面明明能打开,为什么 Headless Chrome 仍然判定 Production 失败?

图 3:Bing 从 Google Search Console 中识别到新的 it-IT 站点,并同时发现已有的 1 个 sitemap

(64) GSC → Bing Webmaster Tools:多语言站点如何减少重复验证

图 3:英文站 3 小时内出现 565 个 Cloudflare 来源 URL

(65) IndexNow 实战:手工提交长期不显示,Cloudflare Crawler Hints 却很快出现在 Bing Webmaster Tools

【图 1:A Tour of Go 项目首页目前的语言版本列表】

(66) 从 nl-NL 到 tr-TR:A Tour of Go 连续上线三门语言后,我又优化了哪些流程

【图 4:Go local 页面中已经出现 French、German、Korean、Simplified Chinese】

(67) 从邮件无人回复到进入 Go 官方 Go local:我的 4 个 A Tour of Go 翻译站终于被收录

图8:最终只保留一把启用的新 API Key

(68) 腾讯云 EdgeOne API 自动化:从 CAM 子用户到最小权限 API Key 的完整配置

【图 7:Production Release Batch 最终汇总】

(69) 从同步 Go 官方上游到一个命令发布 10 个语言站:A Tour of Go Production 流程的再次收敛

【图 3:Cloudflare Smart Tiered Cache 已启用】

(70) Cloudflare 缓存 HIT 很快,MISS 却不稳定:回源阿里云杭州的一次真实优化

【图 3:简体中文站 Support 页面】

(71) 广告之外,社区项目如何长期活下去?我给 A Tour of Go 多语言项目加了 Support

图5:评论成功发布

(72) 从 Go Weekly 到 Reddit、DEV 和 Go Forum:第一次系统推广 A Tour of Go 多语言项目

【图 4:RTL 桌面课程布局修复后的效果】

(73) 第一次把 A Tour of Go 做成 RTL:阿拉伯语版本上线,以及我踩过的几个坑

多语言项目应该先做哪些语言?我的 66 个语言版本商业优先级排序

(74) 多语言项目应该先做哪些语言?我的 66 个语言版本商业优先级排序

做多语言项目时,有一个问题迟早会遇到:

到底应该先翻译哪些语言?

如果只是支持三五种语言,这个问题并不复杂。英语、中文、日语、德语、法语、西班牙语,挑几个主要市场即可。

但当一个项目准备支持几十种语言以后,问题就完全不同了。

我的 Go 多语言项目最初只是翻译 A Tour of Go。因为时间关系,当时并没有一开始就设计一个覆盖整个 Go 文档体系的庞大计划,而是先把 Tour 做完,再逐步扩展 Learn、Tutorial、Database、Modules、Security 等内容。

随着项目推进,我最终完成了 65 个 community locale,也开始思考另一个更长期的问题:

如果以后还有新的多语言项目,我是不是还要重新研究一次“应该支持哪些语言、先做哪一种语言”?

我的答案逐渐变成了:没有必要。

既然已经花了大量时间研究语言范围、地区变体、商业价值和实施成本,那么完全可以建立一份长期使用的语言池和默认顺序。后面的项目直接复用,需要跳过 source language 时跳过即可。

而这一次,我决定让这个基础顺序只回答一个问题:

从长期广告收入潜力来看,哪一种语言更值得优先完成?

从 65 个 locale 到 66 个跨项目目标

这里首先需要解释一个容易混淆的数字。

当前 Go 项目已经完成的固定范围是 65 个 community locale。

Go 官方 Tour 使用 generic en 作为 English authority,但这个 en 是 source language,并不属于上述 65 个 community locale。

这对于 Go Tour 没有问题,因为原文就是英语。

但一个可以跨项目复用的语言池不能假定 source 永远是英语。

以后完全可能出现:

Plaintext
source = zh-CN
source = ja-JP
source = de-DE

如果语言池里没有美国英语,那么中文项目反而没有一个最重要的英语商业市场目标。

因此,我在跨项目语言池中额外加入:

Plaintext
en-US

最终得到:

66 个跨项目目标 locale。

以后每个项目只需要执行一个简单规则:

canonical source 已经覆盖哪个 locale,就跳过哪个 locale,其余语言保持原有商业顺序。

因此英语项目可以跳过 en-US,中文项目可以跳过 zh-CN,但不需要重新制作另一份语言排行榜。

我排序的不是“语言的重要性”

这份排名很容易产生一种误解:

排在前面的语言是不是“更重要”,排在后面的语言是不是“不重要”?

不是。

这份表不评价语言、文化、国家、民族或者使用者的重要程度。

它只是在估算一个商业问题:

如果同一个技术内容项目获得合理的本地流量,各语言版本未来能够产生多少广告收入?

换句话说,我真正估算的是:

Plaintext
预期广告收入
≈ 潜在可获得流量
× 单位流量的商业价值

没有真实运行数据以前,这两个值都不能直接知道,只能通过代理指标估计。

潜在流量会受到语言使用人口、互联网人口、国家规模、开发者人口以及技术内容使用习惯影响。

单位流量商业价值则和所在经济体的购买力、广告主数量、广告投入、数字广告成熟度等因素高度相关。

所以人口很多,不一定排名最高。

人口很少,也不一定排名很低。

一个典型例子:印度和北欧

印度拥有极其庞大的互联网人口和开发者群体。

GitHub 的 2025 Octoverse 数据显示,印度已经拥有约 2190 万 GitHub developers,成为全球第二大开发者社区;Brazil 约 689 万,Indonesia 约 437 万。The GitHub Blog

这意味着印度、巴西、印尼不可能因为广告单价较低,就简单地被放到排行榜末尾。

但另一边,挪威、丹麦、瑞典、瑞士这些国家人口很少,却拥有很高的人均收入、成熟的数字经济和高价值广告市场。

所以:

低单价 × 巨大人口

和:

高单价 × 较小人口

最终可能得到相近的商业价值。

这也是为什么单纯按照“语言人口排行榜”来决定多语言项目顺序并不合理。

美国为什么应该排第一

加入 en-US 后,美国英语基本没有什么悬念地排在第一位。

IAB 与 PwC 的数据显示,美国互联网广告收入在 2025 年达到 2946 亿美元,同比增长 13.9%。IAB

这个市场同时具备:

广告规模巨大、购买力高、广告生态成熟、开发者人口庞大、英语技术内容消费成熟等多个优势。

因此,对一个面向开发者的技术内容网站而言,美国英语应当成为默认商业第一优先级之一。

中国为什么仍然非常靠前

如果只考虑 Google AdSense,那么中国大陆可能会被严重降权。

但我现在刻意不这样排序。

原因是这份表希望成为跨项目、跨广告平台的长期商业顺序,而不是“Google AdSense 支持度排行榜”。

中国 2024 年 GDP 约为 18.74 万亿美元,仍然是全球第二大经济体。德国、日本、印度、英国、法国、加拿大、巴西等主要目标市场也都处在全球大型经济体之列。世界银行数据目录

如果未来中文项目使用中国大陆本地广告平台或者其他商业模式,那么 zh-CN 的商业价值显然不能因为 Google 的限制而被人为降到后面。

同样的原则也适用于俄罗斯语、波斯语等市场。

因此,这一次我不把“当前能不能使用某一家广告平台”作为基础排序因素。

欧洲为什么有大量语言排在前半部分

欧洲有很多人口并不大的语言市场,例如荷兰语、瑞典语、挪威语、丹麦语、芬兰语、捷克语。

但这些市场不能简单按照人口排序。

IAB Europe 的 2025 AdEx Benchmark 显示,欧洲数字广告市场已经达到 1310 亿欧元,同比增长 10.5%;西欧成熟市场依然保持稳定增长。IAB Europe

因此,一个只有几百万或一千多万人口的高购买力市场,完全可能比一个拥有数千万人口但商业价值较低的市场更值得提前完成。

“民族”不是一个适合直接排名的字段

在最初整理数据时,我考虑过人口、大洲、国家、民族、经济体量、广告市场等因素。

后来我决定不单独使用“民族”这个字段,而改成:

主要国家 / 地区与语言社群

因为语言和民族经常不是一一对应。

英语、西班牙语、阿拉伯语、法语、俄语、斯瓦希里语都跨越多个国家和大量不同族群。

对于商业分析来说,真正有意义的是:

使用这门语言的人主要分布在哪里,他们所处的经济和广告市场是什么样的。

66 个语言版本的广告收入潜力顺序

下面这张表就是我最终采用的第一版商业顺序。

“潜在受众”只是数量级提示,不等同于严格的母语人口统计;“广告潜力”同样是当前没有真实 PV、RPM 和 fill rate 数据情况下的综合预期。

排名Locale中文语言名称主要国家 / 地区区域潜在受众量级经济 / 广告市场特征广告潜力
1en-US英语(美国)美国北美3 亿级全球最大数字广告市场之一,购买力极高S+
2zh-CN简体中文(中国大陆)中国大陆东亚10 亿级超大型经济体、互联网市场巨大S
3en-GB英语(英国)英国欧洲7000 万级高购买力、高成熟度广告市场S
4ja-JP日语日本东亚1 亿级大型发达经济体,广告市场成熟S
5de-DE德语(德国)德国欧洲8000 万级欧洲最大经济体,高商业价值S
6en-CA英语(加拿大)加拿大北美4000 万级高购买力、高广告价值S
7fr-FR法语(法国)法国欧洲6000 万级大型成熟经济体S
8en-AU英语(澳大利亚)澳大利亚大洋洲3000 万级人口较少但单用户商业价值很高S
9ko-KR韩语韩国东亚5000 万级高度数字化、技术市场成熟S
10es-419西班牙语(拉丁美洲)墨西哥、阿根廷、哥伦比亚、智利等拉丁美洲数亿多国共享语言,整体流量潜力巨大S
11pt-BR葡萄牙语(巴西)巴西南美洲2 亿级大人口、大型经济体、开发者增长快S
12ar阿拉伯语中东、北非中东 / 非洲数亿横跨大量国家,并包含高收入海湾市场A+
13it-IT意大利语意大利欧洲6000 万级大型成熟欧洲市场A+
14es-ES西班牙语(西班牙)西班牙欧洲5000 万级欧洲成熟广告市场A+
15nl-NL荷兰语荷兰欧洲2000 万级人口不大但购买力和广告价值很高A+
16ru-RU俄语俄罗斯及俄语地区欧洲 / 亚洲1 亿级大型语言市场,可采用其他广告渠道A+
17zh-TW繁体中文(台湾)台湾东亚2000 万级高收入、高互联网普及率A+
18de-CH德语(瑞士)瑞士欧洲千万级以下极高购买力和广告价值A
19sv-SE瑞典语瑞典欧洲1000 万级高收入成熟数字市场A
20en-IN英语(印度)印度南亚超大型全球最大的开发者增长市场之一A
21id-ID印度尼西亚语印度尼西亚东南亚2 亿级超大人口、互联网和开发者高速增长A
22fr-CA法语(加拿大)加拿大魁北克等地区北美千万级高购买力区域市场A
23de-AT德语(奥地利)奥地利欧洲1000 万级成熟高收入欧洲经济体A
24nb-NO书面挪威语(Bokmål)挪威欧洲500 万级极高人均收入、广告价值高A
25zh-HK繁体中文(香港)香港东亚700 万级高收入国际商业市场A
26da-DK丹麦语丹麦欧洲600 万级高购买力成熟市场A
27en-SG英语(新加坡)新加坡东南亚600 万级小人口、高收入、高商业价值A
28pl-PL波兰语波兰欧洲4000 万级中大型欧洲经济体A
29he希伯来语以色列中东1000 万级高收入、科技产业集中A
30cs-CZ捷克语捷克欧洲1000 万级成熟中欧市场A
31tr-TR土耳其语土耳其欧洲 / 亚洲9000 万级大人口、中大型经济体B+
32th-TH泰语泰国东南亚7000 万级大型东南亚消费市场B+
33pt-PT葡萄牙语(葡萄牙)葡萄牙欧洲1000 万级欧洲成熟市场B+
34fi-FI芬兰语芬兰欧洲600 万级小人口、高购买力B+
35zh-SG简体中文(新加坡)新加坡东南亚数百万高收入区域中文市场B+
36hi-IN印地语印度南亚数亿巨大语言人口,但单位广告价值较低B+
37vi-VN越南语越南东南亚1 亿级快速增长互联网经济B+
38ms-MY马来语马来西亚东南亚数千万中等人口、较成熟数字经济B
39en-ZA英语(南非)南非非洲数千万市场非洲较成熟的广告经济体之一B
40ca-ES加泰罗尼亚语西班牙加泰罗尼亚地区欧洲千万级位于较高收入欧洲区域B
41fil-PH菲律宾语菲律宾东南亚1 亿级大人口、数字市场增长快B
42hu-HU匈牙利语匈牙利欧洲1000 万级中等欧洲广告市场B
43el-GR希腊语希腊欧洲1000 万级成熟但规模较小的欧洲市场B
44ro-RO罗马尼亚语罗马尼亚欧洲2000 万级成长中的欧洲数字市场B
45bn-BD孟加拉语孟加拉国南亚1 亿级以上超大人口、单位商业价值较低B−
46ta-IN泰米尔语印度南部南亚数千万大语言社群、广告价值偏低B−
47te-IN泰卢固语印度南部南亚数千万大语言社群、广告价值偏低B−
48uk-UA乌克兰语乌克兰欧洲数千万中等语言市场,长期恢复潜力存在B−
49fa-IR波斯语伊朗及周边地区中东9000 万级大型语言市场,需其他广告渠道B−
50bg-BG保加利亚语保加利亚欧洲600 万级小型欧洲市场C+
51ml-IN马拉雅拉姆语印度喀拉拉邦南亚数千万人口可观、广告价值较低C+
52mr-IN马拉地语印度马哈拉施特拉邦南亚数千万大型语言社群C+
53kn-IN卡纳达语印度卡纳塔克邦南亚数千万区域技术产业较强C+
54gu-IN古吉拉特语印度古吉拉特邦南亚数千万较大区域经济体C+
55pa-IN旁遮普语(果鲁穆奇文,印度)印度旁遮普地区南亚数千万较大语言社群C+
56ur-PK乌尔都语巴基斯坦南亚亿级潜在市场大人口、广告价值较低C+
57kk-KZ哈萨克语哈萨克斯坦中亚2000 万级市场中等规模、高于部分低收入市场C
58hr-HR克罗地亚语克罗地亚欧洲400 万级小型欧洲市场C
59sk-SK斯洛伐克语斯洛伐克欧洲500 万级小型欧洲市场C
60sl-SI斯洛文尼亚语斯洛文尼亚欧洲200 万级小人口但收入水平较高C
61lt-LT立陶宛语立陶宛欧洲300 万级小型欧盟市场C
62et-EE爱沙尼亚语爱沙尼亚欧洲100 万级数字化程度高但人口极小C
63lv-LV拉脱维亚语拉脱维亚欧洲200 万级小型欧盟市场C
64sr-RS塞尔维亚语(西里尔文)塞尔维亚欧洲700 万级小型欧洲市场C
65sw-TZ斯瓦希里语(坦桑尼亚)坦桑尼亚、东非非洲亿级跨国语言社群人口巨大但广告商业价值目前较低D
66am-ET阿姆哈拉语埃塞俄比亚非洲数千万大人口、当前广告市场价值较低D

为什么精确名次其实没有那么重要

看到这样一张 66 行的表,很容易开始争论:

第 24 名和第 27 名到底谁应该更靠前?

我后来觉得这并不是一个值得投入太多时间的问题。

原因很现实:

如果一个成熟的 AI-assisted localization workflow 可以让我在两个月左右完成全部语言,那么一个语言提前两周还是推迟两周,对项目长期收入的影响其实很小。

真正重要的是避免两种极端错误。

第一种,是把商业价值非常高的市场长期放在最后。

第二种,是每增加一个项目就重新花几天研究一次语言排序。

只要解决这两个问题,这张表的价值就已经足够大了。

因此,我更看重 S、A、B、C 这些商业梯队,而不是相邻语言之间一两个名次的差异。

四门特殊战略语言

还有四门语言需要单独说明:

Plaintext
sw-TZ
kk-KZ
fa-IR
am-ET

它们在纯广告收入排序中并不一定很靠前。

但它们曾经具有另一个很特殊的价值:

生态入口。

例如,一个项目如果希望申请官方文档站、社区项目或者类似 go.dev 的语言链接,那么这些覆盖不足、竞争较小的语言有时反而会获得非常高的战略优先级。

所以我不会修改它们在基础商业表中的位置。

而是设置一个项目级规则:

如果某个项目存在明确的官方链接、生态合作、目录推荐等机会,这几门语言可以临时提前;如果不存在这类机会,就继续按照广告收入基础顺序实施。

这样“商业排序”和“生态战略”就不会互相污染。

ru-RU、fa-IR 等当前不适合某些国际广告平台的市场也是一样。

基础排名估算的是:

这个语言市场本身的商业潜力。

至于最终使用 Google、当地广告网络、直接赞助、affiliate,还是其他商业模式,是具体项目后面的 monetization implementation 问题。

技术项目还需要考虑开发者分布

我的项目主要是程序设计和技术文档,因此还有一个普通网站不一定需要重点考虑的因素:

开发者人口。

GitHub 2025 的数据已经非常明显地显示出开发者版图正在变化。

India 已达到约 2190 万 GitHub developers,Brazil 约 689 万,Indonesia 约 437 万;同时 Germany、UK、Korea、France、Canada、Japan 等成熟技术市场仍然拥有非常活跃的开发者社区。The GitHub Blog

所以对于编程文档而言:

人口很多但开发者渗透较低的市场,不能简单按全国人口计算。

反过来,小而高度数字化、拥有大量技术从业者的国家,也不应该因为人口少而被严重低估。

这也是为什么这份排序只能称作:

广告收入潜力排序

而不是一套绝对数学公式。

什么时候应该重新排序

我打算先把这份顺序冻结下来。

后续 Site v2、Site v3,以及新的多语言项目,都默认按照这套顺序实施。

真正值得重新排序的时间,不是看到另一篇“全球 CPM 排行榜”的时候,而是我自己开始拥有足够真实的数据以后。

例如:

Plaintext
Locale PV
× 实际 Page RPM
× fill rate
= 实际广告收入

到了那个阶段,就不再需要推测哪个市场更值钱。

真实收入本身就是答案。

在那之前,不断微调第 34 名和第 38 名,只会消耗时间,并不会真正提高项目收益。

最后的原则

经过这段时间的多语言实践,我现在更倾向于把语言选择拆成三个层次。

第一层是固定语言池。

我现在选择 66 个跨项目目标 locale,避免以后每做一个项目都重新研究全球语言。

第二层是商业基础顺序。

只根据长期广告收入潜力排序,不把某一个广告平台当前是否支持这门语言混进语言价值本身。

第三层是项目级 override。

官方链接、生态合作、地区政策、已有 source language 等特殊因素,可以改变某一个项目的实际实施顺序,但不修改底层商业排行榜。

这样,一个项目可以为了申请官方链接优先完成斯瓦希里语;另一个项目可以完全按广告收入顺序从美国英语开始。

两者都没有冲突。

对于我来说,这张表真正解决的问题也不是“世界上第 37 值钱的语言究竟是哪一种”。

它解决的是一个更实际的问题:

从今以后,当我再次开始一个多语言项目时,不需要重新问自己下一门语言应该做什么。

有一个足够合理、可以长期复用的顺序,然后持续完成它,就够了。

第一次把 A Tour of Go 做成 RTL:阿拉伯语版本上线,以及我踩过的几个坑

A Tour of Go 多语言翻译项目

本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验,到生产发布与后续维护的实际开发过程。

项目入口:
✅ Brazilian Portuguese — Português (Brasil)
✅ Dutch — Nederlands
✅ French — Français
✅ German — Deutsch
✅ Italian — Italiano
✅ Japanese — 日本語
✅ Korean — 한국어
✅ Simplified Chinese — 简体中文
✅ Spanish — Español
✅ Turkish — Türkçe
✅ 项目源码:GitHub:shuijingwan/go-tour-i18n

项目正在持续扩展更多语言版本,并长期维护翻译质量、生产发布与后续更新。项目属于非官方社区多语言翻译项目,与 Go 官方无隶属或授权关系。