第三篇：产品本地化 — 不是翻译，是重建一半产品

July 2, 2026

进入信号：第一站选了新加坡。但你的 UI 是全中文的、支付只支持微信和支付宝、帮助中心只有中文——老外根本用不了。

本篇解决的问题：i18n/l10n 不只是把所有字符串翻译成英文——是多语言架构、支付本地化（Stripe + 东南亚本地钱包）、UX 文化适配（不只是翻译文案——是理解老外点按钮的习惯和中国人完全不同）。还有日期、时区、数字格式这些「你以为不用管的细节」。

一、i18n ≠ l10n——先搞清楚两个概念

i18n（Internationalization）：让你的代码「准备好说多种语言」。核心是把所有硬编码字符串抽成可翻译的 key。

l10n（Localization）：针对某个特定市场定制产品。包括翻译、支付方式、UX 习惯、营销语调、甚至定价策略。

很多中国团队以为「i18n 做完了 = 英文版做完了」。但 i18n 只是基础设施——l10n 才是真正让新加坡客户觉得「这个产品是为我们做的」的东西。

二、i18n 实战：3 天把全中文代码变成多语言

你之前所有的文案都硬编码在 React 组件里：

// 之前：中文写死在代码里
<Button>创建新白板</Button>
<Placeholder>输入团队名称…</Placeholder>
<Toast>白板已保存</Toast>

第一步：把所有文案抽成 i18n key。

// 之后：用 t() 函数引用翻译 key
<Button>{t('whiteboard.create')}</Button>
<Placeholder>{t('team.name.placeholder')}</Placeholder>
<Toast>{t('whiteboard.saved')}</Toast>

第二步：建翻译文件。

// zh.json（你原来的所有中文文案）
{
  "whiteboard.create": "创建新白板",
  "team.name.placeholder": "输入团队名称…",
  "whiteboard.saved": "白板已保存"
}

// en.json（AI 辅助翻译 + 你人工校审）
{
  "whiteboard.create": "New Whiteboard",
  "team.name.placeholder": "Enter team name…",
  "whiteboard.saved": "Whiteboard saved"
}

你用的工具：next-intl（Next.js 最流行的 i18n 解决方案）。3 天完成全部迁移——570 个 i18n key，英文翻译 AI 辅助一个人校对完成。

三、不止文案：四个「你以为不用管」的细节

需要适配的	中文	英文	坑在哪
日期格式	2026年7月2日	Jul 2, 2026	不同市场的日期顺序不同——美国是 Month/Day/Year，欧洲是 Day/Month/Year。如果你的系统把 07/02/2026 当 7 月 2 日但德国客户认 2 月 7 日——合同的截止日期就全乱了。
数字格式	1,000,000	1,000,000	中文和英文都用千分位逗号——但德语用点（1.000.000），法语用空格（1 000 000）。
时区	UTC+8	UTC+8（新加坡）到 UTC-8（旧金山）	所有时间存储用 UTC，显示时转换客户端时区。不要把 UTC+8 当成「默认时区」写死在逻辑里。
RTL 语言	从左到右	从左到右（英语），从右到左（阿拉伯语/希伯来语）	支持 RTL 几乎等于重写整个 CSS。先不做 RTL 市场——等你有 10 个以上阿拉伯客户再说。

动手本地化前，先补一课：你真的听懂海外用户了吗？

翻译、支付、UX 改版这些都是在讲"怎么改"。但在动手之前，还有一件更前置的事常常被技术团队整个跳过——先确保你听懂的是海外用户的"真实声音"，而不是你们自己脑补的需求。 埋头把 UI 翻成英文，结果没验证过"这个功能是不是老外要的"，是最常见的浪费。

英国产品与市场专家 Dolly（做过戴森英国空净、OPPO 海外音频、极米海外洞察）给了出海团队四步法，可以直接迁移到 SaaS 上：

1. 先问：你的真实用户在哪个平台"吵架"？

对白板这种协作 SaaS，海外用户真的会日常在 Reddit、YouTube、Google 上搜、问、吐槽。原则是跟着"普通用户天天逛"的社区走：

尽量避开这几类：Amazon（虚假评价多）、Facebook（键盘侠居多）、国内小红书（反映的不是海外市场）；
用对关键词艺术，比如在 Google 搜 "best whiteboard for teams under $10/month"，能看到真实用户从各种角度比较产品——这些角度就是功能定义期最好的素材；
锁定地区市场（比如欧美）后，可再补 Trustpilot、德国评测机构 Stiftung Warentest 等第三方平台；Reddit 声音真实，但要小心被带回"技术犄角旮旯"，挑着听。

2. 定量会"看起来可靠"，定性和真正给方向

很多团队偏爱发问卷拿数据，因为"数据不可辩驳"。但在需求/功能定义阶段，样本再大也可能只是"看似可靠"，真正给你方向的是定性研究——一对一的深访、在小范围里观察真实用户怎么用。别一上来就用问卷数字拍板加哪个功能。

3. 收集到的信息，拿四把尺子量一遍

常识性：结论符合你对这群人的基本认知吗？行业报告只能代表机构的宏观推断，不代表具体用户情绪；
逻辑性：答案之间逻辑自洽吗？把用户往回追问，每个问题至少追问五次，挖到行为背后的原因；
代表性：样本在地区、性别、使用习惯上有没有真覆盖你服务的人群；
时效性：需求是流动的，一年半以上的调研报告要打折来看。

4. 改完之后，去真实场景里找 beta tester 试

哪怕 UI 全改完，也得在海外目标用户手里转一圈：让 beta tester 在真实使用场景里测。他抱怨的每个"是不是我用错了"，对你都算产品漏洞——"即使是他使用不当，也是设计考虑不周的反馈"。 放下偏见认真记，别急着反驳"是他不会用"。

这样你补的不只是"翻译"，而是"这版英文产品真的长在老外需要的形状上"。

四、支付本地化：不是接一个 Stripe 就完了

你在国内只支持微信和支付宝。出海后，面临的支付选择完全不一样：

// 接 Stripe（覆盖全球信用卡 + 部分本地支付）
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

const session = await stripe.checkout.sessions.create({
  payment_method_types: ['card', 'paynow'], // 信用卡 + 新加坡 PayNow
  line_items: [{ price: 'price_xxx', quantity: 1 }],
  mode: 'subscription',
  success_url: `${baseUrl}/billing/success`,
  cancel_url: `${baseUrl}/billing`,
});

但 Stripe 不能覆盖所有东南亚支付场景：

市场	支付习惯	怎么接
新加坡	信用卡 + PayNow（类似微信扫码付）	Stripe 原生支持 PayNow ✅
马来西亚	信用卡 + FPX 网银	需要 Billplz / Stripe 的 FPX 集成
印尼	GoPay / OVO（电子钱包）	需要 Xendit / Midtrans
泰国	PromptPay（类似支付宝）	Stripe 支持 ✅
越南	银行转账 + Momo	需要本地聚合支付

你的策略：第一阶段只接 Stripe（覆盖信用卡 + PayNow）。新加坡 + 马来西亚 + 泰国的信用卡渗透率足够你起步了。后面市场大了再加本地钱包。

五、UX 文化适配：老外点按钮的习惯和中国人不一样

你让一个美国设计师朋友看了你的英文版。她给了 10 个反馈——最重要的三个：

1. 「颜色太花——看起来不像生产力工具。」

国内 SaaS 喜欢用大面积的主题色——蓝色的导航栏、橙色的 CTA 按钮、绿色的成功提示——因为国内用户觉得「有活力」=「产品在持续更新」。但西方用户（尤其是在 B2B 协作工具这个品类里）认为：大面积高饱和色 = 「不够克制」=「像消费 App 而不是工作工具」。

Linear 和 Notion 的设计哲学是：90% 的界面是中性色（白/灰/黑），只留 10% 给你强调最重要的一个操作。这种设计传递的信息是「别担心我会消失——我就在你需要的那个角落。」

你做了三个月改版：把导航栏从蓝色改成深灰、把成功颜色的饱和度从 80% 降到 30%、把所有「圆角 + 投影」改成「无投影 + 微圆角」。

2. 「帮助信息藏太深——每个功能旁边我需要一个 Tooltip。」

中国用户遇到不懂的功能——截图、发到你的客服群里、3 分钟有人回。西方用户遇到不懂的功能——去你的帮助中心自己搜；搜不到就换软件。

你给每个功能按钮旁边加了 ? 图标 + Tooltip：

<Button>
  Share
  <Tooltip content="Generate a shareable link. Anyone with the link can view this board.">
    <IconHelp size={14} />
  </Tooltip>
</Button>

加了 37 个 Tooltip 花了 2 天。但海外客户的求助工单数量下降了 42%。

3. 「Dashboard 卡片太多——我不知道该先看哪个。」

中国用户对信息密度的容忍度高——一天看 200 条微信消息的脑子，看 8 个 Dashboard 卡片没啥。西方用户一个屏幕最多 5-6 个信息块，多了会觉得「这个软件很复杂」。

你把 Dashboard 从 8 个卡片减到 5 个——只保留最近白板、团队活跃度、存储用量、最近邀请、快捷操作。

六、英文品牌语调（Tone of Voice）——不只是「不犯错」

你的第一次英文文案是这么写的：

"CollabMind is a powerful collaborative whiteboard platform that enables teams to work together seamlessly."

这是「对」的英文——没错别字、语法正确。但它没有任何性格。Linear 的官网文案是：「Linear is a better way to build software.」——只有 8 个单词，让一个工程师读完就想注册。

你的英文语调需要回答三个问题：

你是谁？ —— 「A simpler whiteboard for teams that hate complexity.」
你为谁做？ —— 不是「所有团队」，是「被 Miro 的复杂功能淹没的小团队」
你的性格是什么？ —— 简洁、直接、不装。像和一个同事在 Slack 里聊天，而不是像企业官网。

你改了整站文案——从「Collaborate seamlessly with your team using our powerful suite of tools」变成了「Draw. Write. Collaborate. No tutorial needed.」

七、英文版上线的 Checklist

✅ 570 个 i18n key，中英文翻译完成
✅ Stripe 集成（信用卡 + PayNow）
✅ 日期/数字/时区适配
✅ Dashboard 从 8 卡片减到 5
✅ 37 个 Tooltip 帮助文案
✅ 整站英文文案重写（人话，不是翻译腔）
✅ 英文帮助中心上线（10 篇核心文档）
✅ 英文 Terms of Service + Privacy Policy（Copy 了同品类 Notion 的模板然后改的——不要自己写）

八、Second State：把「国内优势」迁移成「全球信任」

上面讲的是「把产品本地化」。但还有一种出海，产品天生是全球的——它不用翻译 UI，它要迁移的是「国内的工程优势」和「全球的信任」。Second State 就是这条路。

Second State 做的是 WebAssembly 运行时（WasmEdge）——一种更轻、更快、更安全的「运行时/容器」基础设施，由华人科学家 Michael Yuan 创立。这类公司有一个共同点：它们的用户天然是全球的——开发者没有国界，所以它们不用纠结「先国内还是先海外」，第一天就活在 GitHub 上。

Second State 最关键的一个动作，是把核心项目开源，然后捐赠给 CNCF（云原生计算基金会）。这一步很反直觉——把自己的技术「白送」出去？但它的逻辑是：基础设施类软件，开源是唯一的获客方式。 开发者不会用一家闭源的运行时——他们要读代码、要参与、要在社区里遇到问题有人回答。WasmEdge 开源后，GitHub star 和贡献者涨起来，社区产生了大量「入站商机」——用他们自己的话说：所有客户和商业管道，都来自开源社区。 今天 WasmEdge 是 CNCF 的托管项目，客户里有 Fortune 500 公司。

这个案例给你的启发不是「你也去做开源」，而是一条更本质的东西：国内优势是可以迁移的，关键是把它翻译成全球信任的语言。 对开发者产品，那门语言是 GitHub 和开源协议；对协作工具，那门语言是你的英文内容、你的 SOC2、你的客户案例。「本土化迁移」的第一步不是翻译文案，是找到「你的优势，用什么方式让外国人相信」。

九、出海现实障碍清单：四条你迟早要踩的沟

这四条凑在一起，就是每个中国团队都要硬趟的「出海现实障碍」——它不是理论。你这一章做的本地化改版，本质上就是在为这四条沟做准备：

障碍	是什么	你在哪一篇处理它
数据合规	GDPR/CCPA/数据跨境，不满足就拿不到大客户订单	合规与法务篇
语言差异	不是翻译，是「表达方式」——日期格式、语气、礼貌习惯	本篇（i18n/l10n/语调）
渠道差异	国内靠群和地推，海外靠评价、内容、社区、代理	内容营销 / 竞品 / 社区 / 渠道篇
支付问题	微信/支付宝在海外不存在，信用卡、本地钱包是另一套世界	全球定价与支付篇

你会发现，这四条障碍正好对应着本系列后面的四篇——本地化只是第一关，后面每篇都在处理其中一条沟。清单看着吓人，但好消息是：每篇只处理一条，你不必同时面对全部四条。

什么时候进入下一阶段？

英文版上线了。Stripe 接好了。你给新加坡那个客户发了封邮件：「English version is live — here's your trial link.」

他回：「Awesome. I'll share it with my team. We have a brainstorming session tomorrow — perfect timing.」

进入下一阶段的信号：英文版上线了。但除了那个新加坡客户，互联网上没有任何人知道 CollabMind 的存在。你怎么让第一个陌生人发现你？

这是第四篇的内容——第一个海外客户。

本篇总结

做了什么	工具/方法	耗时
i18n 国际化	next-intl，570 个 key	3 天
支付	Stripe（卡 + PayNow）	1 天
UX 文化适配	降色 + 37 Tooltip + 减卡片	3 个月改版
英文品牌语调	人话文案，不装	2 天
英文帮助中心	10 篇核心文档	1 天

一、i18n ≠ l10n——先搞清楚两个概念​

二、i18n 实战：3 天把全中文代码变成多语言​

三、不止文案：四个「你以为不用管」的细节​

动手本地化前，先补一课：你真的听懂海外用户了吗？​

1. 先问：你的真实用户在哪个平台"吵架"？​

2. 定量会"看起来可靠"，定性和真正给方向​

3. 收集到的信息，拿四把尺子量一遍​

4. 改完之后，去真实场景里找 beta tester 试​

四、支付本地化：不是接一个 Stripe 就完了​

五、UX 文化适配：老外点按钮的习惯和中国人不一样​

六、英文品牌语调（Tone of Voice）——不只是「不犯错」​

七、英文版上线的 Checklist​

八、Second State：把「国内优势」迁移成「全球信任」​

九、出海现实障碍清单：四条你迟早要踩的沟​

什么时候进入下一阶段？​

本篇总结​