最近，我给 A Tour of Go 多语言项目增加了一个以前一直有些犹豫的功能：
Support the project。
简体中文站提供微信和支付宝；面向国际用户的语言站，则提供 USDC、USDT，以及 Binance、OKX 平台内转账等方式。
从技术实现来看，这并不是项目里最复杂的功能。
真正让我考虑很久的，是另一个问题：
一个免费、开源的社区项目，在页面里增加“支持项目”入口，到底合不合适？
这次最终决定加入 Support，也不是一个孤立的决定。
它其实和我前段时间重新研究 A Tour of Go 历史上的社区翻译项目密切相关。
一、这件事要从那些已经离线的社区翻译说起
9 月 3 日，我写过一篇文章：
《从法语 553 次提交到韩语两代离线：A Tour of Go 社区翻译为什么难以长期维护》。
那次重新调查历史项目以后，我印象最深的，不是曾经有多少种语言，而是：
很多社区翻译曾经投入了大量时间，最后还是停止维护甚至彻底离线。
法语项目就是一个很典型的例子。
仓库历史上能够看到：
553 Commits
61 Contributors进一步排除能够识别出的官方上游历史以后，我当时统计到的 fork-only 历史仍然有：
162 fork-only commits
14 个 fork-only Git author name
超过 11 年的活动跨度最后仓库还是 archived，Production 站点也已经离线。(永夜)
韩语更让我印象深刻。
第一代项目长期无人维护以后，又有人重新建立了第二代项目：
第一代离线
→ 新维护者重新翻译和迁移
→ 建立新的 Production
→ 再次进入官方语言列表几年以后，第二代韩语仍然再次 OFFLINE，官方也重新移除了链接。(永夜)
所以我后来越来越认同一个判断：
社区翻译真正困难的，往往不是第一次把一门语言翻译出来，而是五年、十年以后，它还有没有条件继续存在。
二、一个翻译项目的“维护”，远不只是继续翻译
如果只看最终结果，很容易把历史项目的离线理解成：
维护者后来没有继续翻译。
但实际问题远比这复杂。
历史上的 A Tour of Go 社区翻译曾经共同面对过：
上游不断变化
runtime 淘汰
App Engine 部署失效
production ownership
部署权限
技术债
Bus Factor
维护者时间变化
基础设施成本Go 官方过去甚至专门处理过 App Engine runtime 淘汰以后，社区 Tour 无法重新部署的问题。
翻译文本可能还好好地留在 GitHub。
真正先断掉的却可能是：
runtime
→ deployment
→ hosting
→ production site
→ official link一旦其中某个环节长期无人处理，对普通学习者来说，这门翻译实际上也就“消失”了。(永夜)
这也是为什么现在的 go-tour-i18n 花了大量精力在翻译之外：
Translation Workflow
Quality Check
Locale Surface Review
Production
CDN
自动验收
上游同步
正式文档
搜索引擎我希望留下的不只是：
今天这个站已经上线。
还应该尽量留下：
几年以后，它仍然有继续维护和接手的条件。
三、历史上的中文社区维护者，也曾对商业模式感到无奈
在上一篇文章里，我还记录过一个让我很有感触的细节。
我以前看到过中文社区维护者表达过类似的无奈：
这种项目很难谈什么商业模式。
当时我没有重新找到那句话的原始出处，所以没有把它作为可核实的直接引文，只保留了这个大致意思。(永夜)
现在继续做这个项目，我越来越能够理解这种感受。
社区翻译通常意味着：
免费访问
不开会员
不卖课程
不卖软件
没有订阅
也很难有稳定企业合同从学习者角度来看，这当然很好。
但对于长期维护来说，就会自然产生另一个问题：
项目依靠什么持续运行？
这个问题在项目刚上线的时候并不明显。
一年、五年、十年以后，差别就会越来越大。
四、社区项目免费，并不意味着运行它没有金钱成本
开源代码可以免费放在 GitHub。
翻译内容也可以免费提供给所有人。
但一个真正在线运行的多语言项目，仍然存在持续的金钱投入。
以我现在的 A Tour of Go 多语言项目为例，背后涉及：
服务器
海外网络节点
域名
公网带宽
CDN
DNS / 网络服务
监控和日志
Production 存储
AI 工具其中一些能力确实可以使用免费方案。
例如目前不少 community locale 使用 Cloudflare Free。
但：
部分基础设施免费 ≠ 整个项目没有运行成本服务器、域名、网络和各种维护工具叠加起来，仍然需要长期投入。
这些属于比较容易量化的金钱成本。
但实际上，还有另一部分往往更容易被忽略。
五、比账单更难量化的，是长期投入的时间和精力
随着语言越来越多，真正需要持续投入的已经不仅是金钱。
例如一次上游同步，可能涉及：
检查 upstream
→ 判断 TranslationUnit 变化
→ 翻译 / revision
→ validation
→ Quality Check
→ promotion
→ Locale Surface Review
→ preview
→ Production
→ browser acceptance遇到故障以后，还可能继续处理：
systemd
Nginx
CDN
DNS
TLS
Playground
浏览器兼容
搜索引擎这些都不会出现在任何云服务账单里。
但它们同样是真实成本。
甚至对于一个社区项目来说，这部分长期人力和精力投入，往往比服务器本身更加稀缺。
所以长期维护实际上至少包含两类不同成本：
一类是可以直接计算的：
服务器、域名、CDN、工具等金钱投入
另一类是很难直接计价的：
维护者持续投入的时间、注意力、知识和精力前者需要项目有条件继续运行。
后者则决定了有没有人愿意长期把这件事情放在自己的优先级里。
两者最终都会影响一个社区项目能不能坚持很多年。
六、最初我想到的可持续方式，还是广告
A Tour of Go 多语言站一直保持免费访问。
所以最自然的一种运营方式就是：
免费内容 + 广告用户不用注册，也不需要支付课程费用。
如果未来能够获得稳定的自然搜索访问，广告就可以帮助承担一部分：
服务器和网络
CDN 与域名
维护工具
长期 Production 运行也就是说，它的意义并不仅仅是产生一项收入数字。
更重要的是让：
用户使用项目产生的流量，能够反过来分担项目自身的一部分长期运行成本。
这样项目就不再完全依赖单一维护者持续投入金钱。
不过，我现在也不太愿意把增加多语言版本简单描述成：
更多语言
→ 更多页面
→ 更多广告收入因为那会把整个项目的目标说得太窄。
更准确的逻辑应该是：
更多语言
→ 更多开发者可以使用自己熟悉的语言学习
→ 更多地区的用户和搜索引擎能够发现这些内容
→ 社区项目的覆盖范围扩大
→ 同时增加长期可持续运营的可能首先还是让内容真正被人发现和使用。
收入是项目长期运行条件中的一部分，而不是唯一目标。
七、现在的 AdSense 数据仍然非常有限
从最近 7 天的数据来看，go-dev 多语言项目目前通过 AdSense 获得的收入还很少。
其中很多语言站仍然显示：
US$0.00不过，这里不能直接把它理解成：
这些语言没有流量价值，或者项目没有意义。
首先，很多 locale 本身才刚刚上线。
更重要的是，目前已经被 Go 官方加入翻译列表的 4 个站点，我已经撤销了广告展示。
因此现在的广告数据，本身就混合了两种不同状态：
一部分站点：
继续通过广告分担运营成本
另一部分站点：
为了进入官方语言入口，已经不再展示广告这也带来了一个非常现实的取舍。
八、官方链接和广告之间，我最终更看重“被发现和使用”
对于一个社区翻译项目来说，能够进入 Go 官方 A Tour of Go 的语言列表，非常有价值。
它解决的首先不是收入问题，而是：
发现问题。
一个新的语言站即使已经：
上线
有 sitemap
提交搜索引擎
完成 SEO也不意味着目标用户马上知道它存在。
而官方链接则完全不同。
访问官方 A Tour of Go 的开发者，可以直接看到：
这里还有自己的语言版本。
这正是社区翻译最希望发生的事情。
所以目前存在一个很明显的选择：
加入官方链接
→ 更容易被目标开发者发现和使用
→ 但需要撤掉广告
不加入官方链接
→ 可以继续保留广告
→ 但新站获得稳定曝光会困难很多如果只看短期收入，可能会倾向于后者。
但如果回到社区翻译本身的意义：
做出来，是希望有人真正使用。
那么官方入口的价值就不能只用广告展示量计算。
所以这 4 个语言站即使撤掉广告，我仍然认为加入官方链接是更有价值的选择。
九、这也意味着广告不能成为唯一的可持续方式
这个取舍也让我开始重新思考一个问题：
如果社区项目只有广告这一种收入来源，那么恰恰在最有价值的官方曝光渠道上，它可能完全无法使用。
这并不意味着应该放弃官方链接。
也不意味着应该想办法重新把广告塞回去。
更合理的方向是：
让项目的长期可持续性不要只依赖一种方式。
于是我才开始真正考虑：
Support。
十、我为什么一直对 Support 有一些心理负担？
开源世界里，自愿支持其实非常普遍。
GitHub Sponsors、OpenCollective，以及很多独立项目自己的赞助页面，都不是什么新鲜事。
但真正轮到自己的项目时，我还是会觉得有些别扭。
这种心理到底有多少和中文传统文化有关，我不太敢简单下结论。
如果直接归因成：
儒家文化轻商。
我觉得反而太武断了。
“义利”“士商”“商业活动在传统文化中的位置”本身就是一个很大的历史和社会话题，不适合在这篇技术项目文章里下简单结论。
但至少从我自己的感受来说：
在中文语境里，公开讨论收入、赞助、支持，往往会比单纯讨论技术多一层心理压力。
很容易担心：
会不会显得太功利？
会不会让人觉得是在伸手要钱？
一个开源项目谈这些合不合适？所以我以前更容易接受广告。
因为广告看起来是：
用户继续免费使用
广告主承担费用而 Support 则需要直接面对：
是否愿意支持这个项目？
后来我才慢慢觉得，这两件事情并不需要对立起来。
十一、允许用户自愿支持，不等于改变项目的开放属性
A Tour of Go 多语言站增加 Support 以后，并不会改变原来的使用方式。
不支持项目的人仍然可以：
免费访问
免费学习
免费使用 Playground
查看全部课程不会出现：
支持后才能解锁章节
支持后才能运行代码
支持后才能使用完整功能而且项目源码本身仍然公开。
如果有人不希望使用我部署的 Production 站点，或者不希望看到其中的广告，他仍然可以：
查看源代码
自己部署
继续传播Support 没有把开源内容变成付费内容。
它只是增加了一个新的选择：
如果这个项目对你有价值，而且你愿意参与它的长期维护，可以提供自愿支持。
十二、所以我最终把 Support 正式做进了项目
这个功能也不是一次完成的。
Git 历史里能够看到它逐渐完善的过程。
最初是：
feat: 添加多语言项目支持入口然后是：
feat: 完善多语言项目支持方式最后又增加：
feat: 增加英文 README 并优化项目支持展示从一个简单入口，逐渐变成一个需要考虑：
不同语言
不同地区
不同支付习惯
UI
移动端
复制交互
翻译
Production的正式功能。
十三、到底是“支持整个项目”，还是“支持某个语言版本”？
这个问题我后来也专门考虑过。
如果每一个语言页面都写一个 Support，很容易让人产生一种感觉：
为什么到处都在要求支持？
所以需要把层次说清楚。
从项目整体来看：
Support 面向的是整个 go-dev 多语言项目的持续维护。
GitHub README 使用的也是：
Support the project因为很多基础设施本身就是共享的：
代码仓库
Production tooling
shared assets
维护流程
CDN / 网络能力
AI 工具
长期工程维护但用户真正进入某一个语言站时，他看到的又是一个具体 locale。
所以站内页面会把 Support 表达成：
支持当前语言版本继续维护和发展。
例如简体中文站，就是：
支持简体中文版本韩国站则对应韩语版本。
这样做的意义不是把整个项目拆成几十个完全独立的“小项目”。
而是让用户清楚知道：
自己当前使用的是哪个社区语言版本，支持会帮助这个版本以及背后的共享项目继续维护。
因此可以把两层关系理解成：
GitHub / 项目层：
支持整个多语言项目
具体 locale 页面：
从当前语言版本的角度提供 Support 入口这样既不会让项目层级显得混乱，也能让每个语言站的用户看懂这个入口和自己有什么关系。
十四、中文站首先提供最自然的国内方式
简体中文站目前主要提供：
微信支付
支付宝
页面里的核心表达是：
帮助这个语言版本持续维护和发展。
这里强调的并不是一次性的“打赏”，而是让 Support 和项目本身的长期运行联系起来。
它对应的是这个语言版本背后的持续工作，例如：
翻译更新
上游同步
Production
基础设施
长期维护也就是说，Support 在页面里被放在了“项目持续维护”这个语境中，而不是单独作为一个收款入口存在。
十五、一个多语言社区项目，也不能只提供国内支付方式
项目既然面向国际用户，那么只放微信和支付宝显然不够。
所以国际版本里，我增加了：
USDC — Base
USDT — Tron (TRC20)以及可选的：
Binance
OKX平台内转账。
如果用户和项目维护者恰好使用同一个平台，UID 内部转账在一些场景下可以减少小额链上转账的不便。
当然，实际是否可用和费用如何，仍然应该以平台当时显示为准。
十六、Support 最后也进入了真正的多语言 Production 页面
后来我并没有把这些内容只停留在 GitHub README。
Support 也正式进入了各个语言站。
例如韩语站：
页面中的：
标题
说明
资产
网络
地址
最低金额
风险提示
平台内部转账都和其他 UI 一样完成本地化。
这意味着 Support 已经不只是：
README 里附带的一段收款信息而是一个正式的多语言 surface。
因此它同样需要经过：
Locale Surface Review
Production
browser acceptance这也是为什么我现在更愿意把它称为：
项目支持功能。
十七、谁可能会真正使用 Support？
教程网站和普通软件服务不太一样。
A Tour of Go 并不是一个用户每天都需要打开的工具。
很多人的使用路径可能只是：
搜索到教程
→ 学习一次
→ 解决问题
→ 以后偶尔复习
或者推荐给其他人所以我现在不再把 Support 想象成：
只有“长期高频用户”才会使用。
更合理的情况可能是：
某个人只使用过一次，但觉得这个翻译对自己确实有帮助，因此愿意表达一次支持。
也可能有人长期关注项目。
也可能绝大多数用户只是免费使用，然后离开。
这些都很正常。
Support 面向的不是某一种固定“付费用户画像”。
它只是给所有愿意回馈项目的人保留一个入口。
十八、广告和 Support 解决的是不同问题
广告适合：
大量普通访问
→ 每一次贡献很小
→ 聚合成一部分运营收入Support 更像是：
少量用户主动认可项目
→ 自愿提供一次或多次支持它们对应的是完全不同的行为。
而官方链接又是第三个维度：
让更多目标开发者真正发现和使用项目所以现在我的思路越来越不是：
选广告，还是选 Support？
而是：
官方入口
→ 提高发现和使用
广告
→ 在适合展示广告的站点分担部分运营成本
Support
→ 给愿意主动回馈项目的人一个入口几种方式可以同时存在，各自解决不同的问题。
十九、Support 本身不会创造用户
这一点也需要保持很现实的预期。
项目增加：
微信
支付宝
USDC
USDT
Binance
OKX并不会自动产生任何收入。
如果：
没人发现
没人使用
没人觉得有价值那么再完整的 Support 页面也没有意义。
所以 Support 不是一个流量增长策略。
真正重要的事情依然是：
翻译质量
语言覆盖
官方链接
搜索引擎发现
Production 稳定
长期维护Support 做的只是：
当真的有人愿意支持时，项目已经准备好了一个合适的入口。
二十、我仍然希望项目逐渐形成可持续的收入，但这应该建立在社区价值之后
完全不谈收入并不现实。
一个需要长期维护的项目，如果未来能够逐渐产生稳定收入，就意味着维护者可以投入更多时间，也意味着项目更有可能获得长期持续维护。
但顺序很重要。
我更希望是：
项目首先有价值
→ 更多语言真正被使用
→ 社区影响逐渐扩大
→ 形成一定的可持续收入
→ 继续投入维护也就是说，收入首先应该帮助项目：
承担运行成本
降低长期维护压力
增加继续投入的条件如果有一天项目规模真的足够大，能够让维护工作本身获得更稳定的回报，我认为那反而是一种健康的结果。
因为社区项目并不是只有“完全无偿”才算社区项目。
持续、稳定、有人愿意长期投入，同样重要。
二十一、除了金钱成本，还需要让维护者的时间投入变得可持续
前面区分了两类成本：
金钱投入 + 时间与精力投入收入最直接能够帮助的是第一类。
例如：
服务器
CDN
域名
网络
AI 工具但如果一个项目逐渐拥有稳定的运营能力，它也会间接影响第二类。
因为维护者不再需要面对：
项目越来越大
+ 所有成本自己承担
+ 所有维护时间仍然只能不断挤出来这种结构。
换句话说：
经济上的可持续，并不是为了替代社区价值，而是为了给长期维护创造更好的条件。
这也正好回到了历史上的那些项目。
二十二、这和法语、韩语曾经离线的问题重新连接起来了
历史上的法语项目有：
553 次提交
61 个 Contributors
多年维护历史最后仍然归档。
韩语甚至经历了：
第一代
→ 离线
第二代
→ 重建
→ 再次上线
→ 最后再次离线这些项目的离线当然不能简单归因于“没有收入”。
没有足够 evidence 支持这种直接因果关系。
更真实的情况很可能是多种因素共同作用：
Bus Factor
维护者变化
runtime 淘汰
部署权限
production ownership
上游变化
时间不足
技术债
基础设施成本但经济因素同样很难完全排除。
因为如果项目长期要求：
有人持续贡献时间
+ 有人持续承担金钱成本
+ 却没有任何反馈机制那么随着维护者自己的工作、家庭和生活发生变化，这个项目的优先级自然可能下降。
所以我现在更愿意把 Support 看成：
长期维护系统里的一个小补充。
它不会解决所有问题。
但它至少增加了一种让项目继续运行的可能。
二十三、真正重要的不是 Support 本身，而是减少对单一维护者的绝对依赖
如果一个社区项目想运行几个月：
维护者自己承担所有成本，通常并不难。
但如果目标是：
持续同步 Go 官方
不断增加语言
五年以后仍然在线
十年以后仍然有人维护就必须考虑更长周期的问题。
例如：
文档能不能留下？
Production 能不能接手？
代码能不能继续维护？
权限能不能转移？
运行成本有没有长期来源？我现在希望 go-tour-i18n 尽量做到：
流程可以继承
代码可以继承
Production 可以继承
文档可以继承
运行成本也不必永远完全依赖一个人Support 只是最后这一项的一种尝试。
二十四、社区项目的可持续方式，也不需要只有一种
目前我能够想到的可能包括：
广告
自愿 Support
未来可能的企业赞助
社区资源支持
技术合作并不是每一种都一定会出现。
也不需要为了“商业模式完整”而提前把它们全部做出来。
现阶段：
广告 + Support已经足以进行长期真实验证。
以后如果有新的真实需求，再继续增加。
我现在越来越不想追求：
找出唯一正确的收入模式。
更重要的是：
有没有一种组合，既不破坏免费和开放，又能提高项目长期存在的概率。
最后：Support 不是一个孤立的收款页面，而是长期维护体系的一部分
所以这次给 A Tour of Go 多语言项目增加 Support，我现在更愿意把它放回整个项目历史里理解。
它并不是突然多出来的一项“收入功能”。
而是在继续回答一个早就存在的问题：
社区翻译怎样才能更长时间地活下去？
历史已经证明：
第一次上线并不是终点。
一个项目真正长期存在，需要：
语言质量
上游同步
技术维护
Production ownership
部署能力
文档和知识传承
基础设施
时间投入
经济可持续性缺少其中任何一部分，几年以后都可能成为新的风险。
这也是为什么现在的 go-tour-i18n 不仅要解决：
怎样翻译？
怎样验证？
怎样上线？还要逐渐回答：
怎样让更多人真正发现和使用？
怎样让未来的维护者能够接得住？
怎样让项目拥有承担一部分自身长期成本的能力？广告是一种方式。
Support 是另一种方式。
官方链接则帮助社区翻译真正到达需要它的人。
它们并不需要互相排斥。
对于我来说，最希望保持的原则仍然很简单：
免费
开放
多语言
持续维护如果有一天，这个项目能够在持续帮助更多开发者的同时，也逐渐形成足够稳定的运营条件，让维护本身能够长期继续下去，那应该是一个很理想的结果。
毕竟从那些已经离线的社区翻译回头看：
把一个语言版本做出来已经不容易。
但更难的，可能一直都是：
十年以后，它仍然在线，也仍然有人愿意、有人能够继续维护。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。