280篇博客，20套翻译文件，0个全职翻译——这个临时邮箱服务的国际化路子，像极了产品经理做MVP时的狼狈与精明。
20种语言，400多个可索引页面，流量来源从2个国家变成40多个。数字背后是一套被验证过无数次的土办法：用AI打底，人工抽检，SEO优先，体验凑合。
从20页到400页：URL即战略
网站结构很简单。用户访问 /pt-br/blog 看到葡萄牙语，/ja/contact 是日语，根目录默认英语。Astro（一个静态站点生成器）用动态路由参数 [lang] 处理，一套模板吐出20种输出。
每个语言版本有独立的URL、独立的meta标签、独立的hreflang标签指向其他所有版本。Google把每一页都当成独立页面索引。加语言前，网站约20个可索引页面；加完后，400+。
英语关键词"temp mail"竞争激烈到残酷。但西班牙语"correo temporal"、葡萄牙语"gerador de email temporario"呢？搜索量数千，竞争者寥寥。作者「我针对英语优化的关键词有巨大竞争。但西班牙语、葡萄牙语的对应词竞争小得多。」
这种"语言套利"是中小站点的经典打法。大公司在英语市场血拼时，小团队用机器翻译+轻量人工，吃掉长尾语言的搜索流量。
AI翻译+人工抽检：不完美但够用的妥协
UI字符串存在JSON文件里，en.json、pt-br.json、ja.json，同键不同值。这部分简单。麻烦的是博客内容——14篇文章×20种语言=280个markdown文件。
英语原文作者自己写，其他19种语言用AI生成初稿。葡萄牙语、西班牙语、德语、法语、日语这5个流量大的语种，找了母语者审校。剩下的，作者「抽查了一下，但基本就是AI输出加轻度编辑。」
理想吗？不。但「有一个准确度90%的日语版《什么是临时邮箱？》，总比完全没有强，尤其对SEO来说。」
这里有个反直觉的决策：不做100%人工翻译，而是把资源集中在高流量语种，其余交给AI。成本与覆盖面的权衡，产品经理看了会点头。
RTL和CJK：国际化里的隐形坑
阿拉伯语（从右到左）把布局搞崩了。CSS逻辑属性（logical properties）解决了一部分，但邮件阅读器和侧边栏还得单独写RTL覆盖样式。
中日韩（CJK）字符的单词长度分布完全不同。英语60字符的标题，日语可能只有20字符。作者被迫加了按语言生成meta标题的逻辑。
德语单词出了名的长，按钮直接溢出。最后给交互元素设了min-width，文字该换行换行。
这些细节没有标准答案，只有上线后逐个踩坑。国际化文档里不会告诉你，日语标题在搜索结果页会被截断成什么样。
原生内容 vs 翻译：搜索意图的差异
作者做了个对比实验：给巴西用户写的原生指南，比翻译版英语指南表现更好。因为搜索意图和例子不同——巴西用户搜"gerador de email temporario"时，想要的是本地化的使用场景，不是逐字翻译的通用教程。
这解释了为什么纯机器翻译策略有天花板。AI能处理语言转换，但处理不了文化语境。高价值市场值得投入原生内容，其余市场用翻译占位即可。
流量数据验证了这套逻辑。国际化前90%流量来自美英，现在覆盖40+国家。构建时间变长了——但作者没说完，截图在这里中断。
一个人维护20种语言的网站，本质是拿机器的可扩展性换人的不可替代性。翻译团队？不需要。完美体验？不追求。SEO流量和全球覆盖，才是唯一KPI。
最后一个细节：作者提到构建时间变长后，文章戛然而止。没有总结，没有展望。这种"话没说完"的收尾，像极了产品经理凌晨三点部署完国际化版本，盯着构建日志，发现又报错时的真实状态——系统还在跑，问题还在冒，但流量确实涨了。
如果你要做一个多语言产品，会先攻克哪5个语种，还是直接上20个？
热门跟贴