何时是启动本地化工作的最佳时机？

“我们将在产品适合市场后进行本地化。”这一句话让软件公司平均损失了 23-42% 的开发工作，并导致全球发布延迟 6-18 个月。隐藏成本不是翻译，而是您今天在每一行代码中构建的技术债务。

残酷的数学：立即构建与稍后改造

• 5-7x – 改造本地化与内置本地化的成本倍增
• 23-42% – 本地化延迟导致技术债务浪费了开发时间
• 6-18个月 – 推出后本地化时进入全球市场的平均延迟

根据麦肯锡和本地化行业标准协会的研究，组织将 23% 到 42% 的开发工作浪费在处理技术债务上。当本地化被视为事后才考虑时，这种债务就会呈指数级增长。

这实际上意味着：如果您的团队花费 3 个月的时间构建一个包含硬编码字符串、布局假设和不区分区域设置的格式的功能，那么当您决定走向全球时，您将花费 15-21 个月的时间来解决它。这不包括翻译时间——这只是使代码库可本地化的工程工作。

决定你命运的技术债务比率

技术债务比率衡量的是修复代码库的成本与从头开始构建代码库的成本。行业数据显示，TDR 高于 5% 表明需要采取紧急行动。对于延迟国际化的公司来说，本地化特定的TDR往往超过40%。

真实例子： 一家拥有 50,000 行代码和硬编码英文字符串的 SaaS 初创公司估计需要 2 周的时间来“添加翻译”。实际工作花费了开发人员 6 个月的时间来外部化字符串、修复损坏的布局、实现区域设置感知格式并解决边缘情况。成本：工程时间约为 180,000 美元。如果他们从第一天起就进行国际化建设，增量成本将约为 25,000 美元。

开始的最佳时刻：在写第一行之前

这项研究是明确的。从一开始就整合本地化的公司行动更快，花费更少，并占领全球市场，而竞争对手仍在重构他们的代码库。

国际化 (i18n)：您的基础

国际化是指将您的软件设计为适应多种语言和地区，而无需进行工程更改。这不是您添加的功能，而是您从架构零天开始采用的思维方式。

i18n 核心原则（从第一天起就构建这些原则）：

• 外部化所有面向用户的文本： 切勿在源代码中对字符串进行硬编码。使用将内容与逻辑分开的资源文件（JSON、YAML、XLIFF）。
• 统一码无处不在： 支持双字节字符、从右到左脚本（阿拉伯语、希伯来语）和复杂脚本（泰语、梵文）。
• 区域设置感知格式： 日期、时间、数字、货币和单位必须根据用户区域设置动态调整。
• 灵活的用户界面布局： 与英语相比，德语文本扩展了 30%。日本合同。您的 UI 必须在不中断的情况下处理文本扩展/收缩。
• 避免连接字符串： “You have ” + count + ” messages” 在具有不同语法规则的语言中中断。请改用参数化字符串。
• 双向设计： 您的布局应该支持从左到右和从右到左的文本呈现，而无需重新设计。

// BAD - Hardcoded, 在其他语言中会出现问题
const greeting = "Hello, " + userName + "!";
const message = "You have " + count + " new messages";

// GOOD - Externalized, parameterized, localizable
const greeting = i18n.t('greeting', { name: userName });
const message = i18n.t('message_count', { count: count });

四个时机触发因素：当本地化变得紧迫时

虽然理想的答案是“从一开始”，但在某些特定时刻，本地化会从“可有可无”转变为“存在的必要性”。

触发因素 1：意外的国际流量

您检查 Google Analytics，发现 15-30% 的流量来自您未定位的市场。这些用户正在找到您，但您在这些市场的转化率比您的本土市场低 60-80%。

行动： 这是需求存在的验证。如果您等待本地化，这些市场的竞争对手将构建本地化替代方案并抓住您发现的机会。

触发因素 2：实现产品与市场契合

您已经在最初的市场中找到了产品与市场的契合点。保留率高，流失率低，并且用户拥护您的产品。现在是扩张的时刻，而不是六个月后。

行动： 立即启动持续本地化基础设施。像 Notion 这样的公司等到注意到日本和韩国的庞大用户社区后，就迅速进行了本地化。如今，Notion 70% 的用户都在美国境外。

触发因素 3：筹款或收入里程碑

您已经筹集了一大笔资金或达到了需要加速增长的收入里程碑。投资者期待国际扩张。延迟本地化会延迟这种增长。

行动： 在将销售和营销扩展到新市场之前，分配 15-20% 的工程资源用于构建国际化基础设施。

触发点4：竞争压力

竞争对手已在主要市场推出了本地化版本，并且正在获得关注。他们的本地化产品正在转化您本可以捕获的用户。

行动： 这是最昂贵的触发器。您现在正在时间压力下进行改造，与从一开始就构建 i18n 相比，这会增加 8-10 倍的成本。

敏捷本地化框架：冲刺，而不是瀑布

传统的方法——构建一切，然后翻译一切——已经死了。现代软件开发使用敏捷冲刺。您的本地化工作流程必须符合这一节奏，否则就会成为扼杀全球速度的瓶颈。

持续本地化：它的实际含义

持续本地化将翻译工作流程集成到敏捷开发周期中，因此本地化版本与源语言版本同时发布。翻译不是发布后的混乱，而是每个冲刺中内置的并行过程。

它在实践中是如何运作的：

1. Sprint 计划（第 0 周）： 本地化要求是预先确定的。产品经理和本地化团队就哪些内容需要翻译以及优先考虑哪些市场进行协调。
2. 发展（第 1-2 周）： 开发人员使用外部化字符串构建功能。当新内容提交到代码库时，它会自动提取并发送到翻译管理系统 (TMS)。
3. 翻译（并行过程）： 当开发人员继续编码时，翻译人员则处理新的字符串。上下文通过屏幕截图、UI 描述和开发人员评论提供。
4. QA 整合（第 2 周）： 翻译后的字符串将合并回代码库。语言 QA 与功能 QA 一起进行。测试人员检查 UI 中断、文本溢出和上下文准确性。
5. 部署（第 2 周结束）： 所有语言版本同时部署。英语、德语、日语和西班牙语版本同时发布，而不是按顺序发布。

本地化冲刺计划：缺失的部分

大多数开发团队直到最后一刻才计划冲刺而不考虑本地化。这会造成混乱。以下是高绩效团队如何将本地化整合到冲刺计划中：

1. 将本地化定义为“完成的定义”的一部分

一项功能只有在所有目标语言中进行测试后才算完成。这迫使团队在冲刺估算中考虑本地化时间。

2. 创建本地化用户故事

将本地化视为用户故事：“作为德国用户，我需要翻译所有 UI 元素，以便我可以用我的母语使用该产品。”分配故事点并跟踪速度。

3. 让本地化团队参与冲刺计划会议

本地化经理参与冲刺计划，以确定翻译量、标记复杂的字符串并按时间表进行调整。这可以防止出现意外。

4. 自动化内容提取和交付

使用 CI/CD 集成自动从 Git 提交中提取新字符串并将其路由给翻译人员。通过电子邮件或电子表格进行的手动交接是扼杀敏捷速度的瓶颈。

5. 将翻译缓冲区构建到冲刺中

并非每个冲刺都需要大量翻译。一些冲刺专注于后端工作，只需进行最少的 UI 更改。使用这些冲刺来弥补翻译债务或完善现有翻译。

团队结构：谁真正进行本地化？

本地化不是一个人的工作。它需要开发人员、产品经理、技术作家、翻译人员和 QA 测试人员之间的跨职能协作。这是理想的团队结构：

本地化团队规模问题

您实际上需要多少人？这取决于您的发展速度和市场野心：

• 早期阶段（PMF 之前）： 0-1 本地化专家。开发人员处理 i18n 架构。使用带有内置翻译网络的 TMS 平台进行翻译工作。
• PMF 后（2-5 种语言）： 1 名本地化经理 + 外部翻译供应商。经理协调工作流程、管理 TMS 并确保质量。
• 规模阶段（5-15 种语言）： 1-2 名本地化经理 + 顶级市场的专门语言学家 + 长尾语言的外部供应商。考虑聘请国内审稿人。
• 企业（超过 15 种语言）： 完整的本地化团队由区域经理、内部语言学家、质量检查专家和本地化工程师组成。

技术作家的角色：本地化写作

技术作家是高效本地化的无名英雄。用源语言清晰书写的内容翻译速度更快、更准确且成本更低。

本地化友好的写作指南：

• 使用简单、直接的语言： 避免习语、文化参考和复杂的句子结构。 “点击按钮”比“点击按钮启动进程”翻译得更好。
• 与术语保持一致： 通篇使用相同的术语来表示相同的概念。不要交替使用“删除”、“删除”和“垃圾”。选择一个。
• 保持句子简短： 每句话一个想法。含有多个从句的长复合句是翻译的噩梦。
• 避免幽默和双关语： 双关语、笑话和巧妙的双关语很少能被翻译。它们迫使译者在直译（失去笑话）或创造性改编（引入风险）之间做出选择。
• 供译者参考的文档上下文： 添加注释，解释字符串出现的位置、作用以及任何限制（字符限制、语气要求）。
• 创建和维护术语表： 定义一次关键术语。确保翻译人员对产品特定术语使用一致的翻译。

现实世界的成功故事：时机正确的公司

理念：早期本地化，捕捉全球增长

Notion 注意到日本和韩国市场出人意料地受到关注，而这两个市场并非他们的目标市场。他们没有等待，而是在产品与市场契合后迅速进行本地化。他们已经使用 Contentful 进行内容管理，因此与 Smartling 集成只花了一周时间。

如今，Notion 支持 19 种语言和方言，大约 70% 的用户位于美国境外。早期的本地化投资从一开始就将它们定位为全球产品，而不是试图扩张的美国产品。

Airbnb：本地化作为竞争策略

Airbnb 接触中国时知道自己面临着激烈的本土竞争（途家、小猪）和严格的监管障碍。他们的本地化策略不仅仅是翻译：

• 更名为“爱彼迎”： 意思是“用爱互相欢迎”——在文化上产生共鸣，而不仅仅是语音上的相似。
• 集成微信和支付宝： 中国用户不使用信用卡进行在线支付。 Airbnb 根据当地行为调整了支付基础设施。
• 根据中国人的喜好重新设计了用户界面： 将术语从“主人”和“客人”调整为“家庭伙伴”和“短期租客”，以符合文化期望。
• 本地化列表描述： 中国游客真正追求的目标从“豪华设施”转向“舒适的住宿”和“地道的当地体验”。

结果：本地化一年后中国客户群增长了 700%。

Spotify：文化本地化，而不仅仅是翻译

Spotify 在印度的推出表明本地化包括产品改编，而不仅仅是语言翻译：

• 多语言支持： 将印地语、泰米尔语、旁遮普语和其他语言直接集成到应用程序中——不是作为单一的“印度”版本，而是作为独特的本地化体验。
• 本地化播放列表： 构建了特定于地区的音乐发现算法，了解当地艺术家、流派和聆听习惯。
• 定价调整： 推出与当地购买力相匹配的实惠计划，而不仅仅是将美元兑换成印度卢比。

Spotify 并没有等到拥有“足够多”的印度用户来证明本地化的合理性。他们首先进行本地化以获取这些用户。

成本明细：您实际花费的费用

让我们谈谈真实的数字。从一开始就正确进行本地化与事后进行改造相比，本地化的实际成本是多少？

底线： 对于具有 100,000 行代码和 10,000 个可翻译字符串的典型 SaaS 产品，从第一天开始构建 i18n 的增量工程时间成本约为 30,000-50,000 美元。推出后对同一产品进行改造需要花费 200,000-500,000 美元的工程、翻译、质量保证和延迟的收入机会。

常见的反对意见（以及为什么他们是错误的）

“我们甚至不知道我们的产品是否会在国内市场取得成功。”

这是最常见的反对意见，它基于一个错误的假设：国际化是昂贵的开销，只有走向全球化才有回报。

现实：从第一天开始使用 i18n 进行构建需要花费 10-15% 的额外开发时间。这大约是每两周的冲刺额外一天。即使您从不进行本地化，外部化字符串、使用区域设置感知格式以及设计灵活布局的规则实际上也可以提高代码质量。您可以避免硬编码的假设，构建更加模块化的架构，并创建可维护的代码。

真正的问题不是“我们会走向全球吗？”问题是“当我们重建整个产品时，我们能承担得起重建整个产品的费用吗？”

“本地化可以等到我们在这些市场拥有付费客户之后再进行。”

这就产生了先有鸡还是先有蛋的问题。当您的产品未本地化时，国际市场的客户不太可能进行转化。您在这些市场的转化率将比您的本土市场低 60-80%，这使您得出“需求不足”的结论。

但需求低迷是本地化不佳造成的，而不是实际的市场不感兴趣。当您正确进行本地化时，那些“低需求”市场的表现往往会超出您最初的假设。

CSA 研究发现，76% 的在线消费者更喜欢购买带有母语信息的产品。如果您的产品没有本地化，那么您就无法衡量真正的需求，而是衡量对纯英文产品的容忍度。

“我们只会使用谷歌翻译，稍后再清理它。”

机器翻译已经有了显着的进步，但它并不能替代适当的本地化策略。原因如下：

• 上下文很重要： “银行”可能意味着金融机构或河边。未经训练，机器翻译无法理解上下文。
• 文化适应不是翻译： 本地化支付方式、调整配色方案以及调整 UI 流程都不是 MT 能够处理的事情。
• 品牌声音消失： 机器翻译产生的是功能性文本，而不是维护品牌个性的引人注目的文案。
• 法律和监管内容需要人工审核： 服务条款、隐私政策和合规文件必须在法律上准确无误。机器翻译错误会产生责任。

也就是说，机器翻译对于初始草稿、用户生成的内容翻译和低优先级内容很有价值。但它应该是包括人工审核的工作流程的一部分，而不是专业本地化的替代品。

您的本地化准备情况清单

使用此清单来确定您是否已准备好开始本地化（或者是否需要首先构建 i18n 基础设施）：

基础设施准备情况：

• 所有面向用户的字符串都在资源文件中外部化（不是硬编码）
• 代码支持 Unicode 并正确处理多字节字符
• 日期、时间、数字和货币格式使用区域设置感知库
• UI 布局处理文本扩展/收缩（使用德语和日语进行测试）
• 实现（或构建）从右到左的语言支持
• 避免字符串连接（使用参数化字符串代替）
• 翻译管理系统 (TMS) 已选定或正在评估中

团队准备情况：

• 开发人员了解 i18n 原则并接受最佳实践培训
• 指定本地化经理或负责人
• 为目标市场确定翻译供应商或内部语言学家
• 技术作家正在创建本地化友好的内容
• QA 流程包括测试本地化版本中的 UI 中断
• Sprint 规划包括本地化作为“完成定义”的一部分

战略准备：

• 根据流量数据、市场规模和竞争情况确定目标市场的优先顺序
• 预算分配给翻译、工具和潜在的招聘
• 定义成功指标（按市场划分的转化率、激活率、保留率）
• 研究目标市场的法律和合规要求
• 产品与市场的契合度至少在一个市场得到验证

时间悖论

开始本地化的最佳时机是当您编写第一行代码时。第二好的时间是现在——在你编写下一行代码之前。

每推迟构建 i18n 基础设施一天，技术债务就会又累积一天。每个硬编码的字符串都是您需要解开的另一个字符串。每个假定英文文本长度的布局都是您需要重新设计的另一种布局。

赢得全球市场的公司并不是那些拥有最好翻译预算的公司。他们从第一天起就将本地化融入到自己的 DNA 中，因此当东京、圣保罗或柏林有机会时，他们准备好用当地语言回答。

行动计划：本周做什么

如果您正在阅读本文并意识到自己一直在推迟本地化，请立即采取以下措施：

如果您还没有开始开发：

1. 从第一天起就成为 i18n 架构师： 选择具有内置 i18n 支持的框架（React Intl、i18next 等）。
2. 在第一次提交之前设置您的 TMS： Lokalise、Crowdin 或 Phrase 等平台直接与 GitHub 集成。
3. 立即外部化所有字符串： 每个 UI 字符串、错误消息和工具提示都位于资源文件中，而不是源代码中。
4. 记录您的本地化策略： 即使您只在一个市场推出，也要记录您将如何扩展到其他市场。

如果您处于发展中期：

1. 审核您的代码库： 识别所有硬编码字符串。优先考虑面向用户的功能中的外部化字符串。
2. 创建重构路线图： 在接下来的 3-6 个月内将 20% 的冲刺速度分配给 i18n 基础设施。
3. 从新功能开始： 所有新功能都必须符合 i18n 标准。这可以防止您在偿还现有债务的同时产生额外债务。
4. 使用伪本地化测试： 通过字符扩展生成假翻译，以便在真正翻译之前找到 UI 中断。

如果您已经启动：

1. 量化技术债务： 估计使您的代码库可本地化所需的工作量。诚实地对待成本。
2. 根据现有流量确定市场优先级： 查看 Google Analytics，了解尽管没有本地化但仍能获得自然流量的市场。
3. 在一个市场进行试点： 选择高潜力市场，进行全面本土化试点。这将揭示所有隐藏的挑战。
4. 向利益相关者传达现实的时间表： 改造本地化需要 6-18 个月，而不是 2 周。尽早设定期望。

结论：决定您的全球未来的决定

您现在了解了延迟本地化的真正成本。问题不在于是否进行本地化，而在于您是否会从一开始就构建它，还是要支付 5-7 倍的费用来稍后进行改造。

您在没有 i18n 基础设施的情况下发布的每个功能都是您需要重建的功能。你延迟进入的每一个市场都是竞争对手将占领的市场。

最聪明的创始人并不认为本地化是增长的负担。他们将其视为实现全球增长的基础。