把本地化放在产品完成之后，等于默认前面的决定对任何市场都成立。现实里经常不是这样。文本区域按一种语言的长度留好，换一种语言就溢出，或者被截断到看不懂。日期、货币、地址和计量单位被写死在程序里，而不是放在可以替换的规则中。数据模型只假设一个地区、一种单位、一套行政区划。产品流程默认用户从一个市场的渠道进来，用那个市场的方式完成支付、注册或服务。服务本身也只有一种响应时间和一种人工介入方式。

这些都不是翻译团队在最后一段时间可以补上的。翻译可以换掉句子，换不掉一个只认识一种市场的结构。等到句子已经无法放进界面，或者流程在另一个市场根本走不通，再谈“把内容交出去翻译”，讨论的已经不是语言质量，而是产品是否还来得及改。

Leaving localization until the product is done assumes that earlier decisions are neutral across markets. They often are not. A text area sized for one language overflows or gets cut off in another. Dates, currency, addresses and units are written into the program instead of living in rules that can be replaced. The data model assumes one region, one unit system and one way of dividing a territory. The flow assumes users arrive through one market’s channel and finish payment, sign-up or service in that market’s way. The service itself has only one response time and one way for a person to step in.

A translation team cannot repair that in the final stretch. Translation can replace sentences. It cannot replace a structure that only knows one market. When the sentence no longer fits the interface, or the flow cannot be completed elsewhere, “send it for translation” is no longer a question of language quality. It is a question of whether the product can still be changed in time.

如果国际化只意味着“最后能够被翻译”，它就会被排到内容冻结之后。对需要跨市场运行的产品，它应该更早进入架构、数据、内容、设计、发布、测试和上线后的运营。这些词不必堆在一起才显得完整。意思很具体：信息怎么被存储，界面怎么留出变化的空间，版本怎么发布，上线之后谁来验证，都要问一句，这个决定是不是只对一个市场成立。

这不是要求第一天就支持所有市场。那通常不现实，也会让产品失去焦点。它要求的是，当第二个市场出现时，团队改的是配置、内容和必要的规则，而不是拆掉当初被当成“唯一现实”的那些假设。能被调整、能被验证，比一开始就声称覆盖全球更接近真正的产品能力。

If internationalization only means “it can be translated at the end,” it will be scheduled after the content freeze. For a product that has to run across markets, it belongs earlier: in architecture, data, content, design, release, testing and in operations after launch. The point is concrete. How information is stored, how the interface leaves room to change, how a version is released, and who checks it after launch, all need the question of whether the decision is true for only one market.

That is not a demand to support every market on day one. That is usually unrealistic, and it blurs the product. The demand is that when a second market appears, the team changes configuration, content and the rules that must change, rather than tearing out assumptions that were treated as the only reality. Being able to adjust and to verify is closer to a real product capability than an early claim of global coverage.

用户最后看到的常常是语言。语言后面还有别的层。文化会改变人对礼貌、风险和信任的预期。规则会改变什么能做、什么必须告知。数据是否存在、是否可更新，会改变功能是否成立。市场习惯会改变人如何完成同一个任务。运营条件决定问题出现以后，有没有人、有没有流程、有没有时间把它处理完。用户的预期，往往是这些条件一起形成的。

不同产品要处理的维度并不一样。一个内容产品、一个交易产品和一个需要长期运行的软件，不该套同一张本地化清单。清单可以提醒人不要只看见翻译，但不能代替对这个产品的判断。机械地把文化、规则、数据、习惯和运营逐项打勾，看起来完整，也可能让团队错过真正会让产品停住的那一项。

What users see last is often language. Other layers sit behind it. Culture changes what people expect of courtesy, risk and trust. Rules change what may be done and what must be disclosed. Whether data exists and can be updated changes whether a function is real. Market habits change how people complete the same task. Operating conditions decide whether, after a problem appears, anyone, any process and any time remain to deal with it. User expectations are usually formed by these conditions together.

Products do not all need the same dimensions. A content product, a transaction product and software that has to keep running should not share one localization checklist. A list can remind a team not to see only translation. It cannot replace judgment about this product. Ticking culture, rules, data, habit and operations one by one can look complete while the team misses the single condition that would actually stop the product.

差异如果在产品定义时被看见，它常常还是一个设计选择。这个字段要不要做成可配置，这条流程要不要允许分叉，这组内容要不要和代码分开。到了市场上线之前才发现，同样的问题可能变成架构修改、整轮重新测试、版本推迟，或者上线以后用运营去补一个产品没有留下的口子。

运营上的补救有时不可避免。它不应该成为默认的跨市场方法。每次用人工把一个结构性问题接住，团队都在支付一次本可以更早付掉的成本，而且下一次换市场时，这笔成本还会再出现。

一个常见情形是：问题被排进翻译计划，直到界面已经锁死，发布窗口只剩几天。那时团队不是在选择更好的设计，而是在选择哪一种损失更小。

真正成熟的国际化，不是让产品最后“能够被翻译”，而是在产品设计之初就为不同市场留下可以运行、可以调整、可以验证的空间。

When a difference is seen while the product is still being defined, it is often still a design choice. Should this field be configurable? Should this flow be allowed to branch? Should this content live apart from the code? Found just before a market launch, the same issue can become an architectural change, a full retest, a delayed release, or an operational patch over a gap the product never left open.

An operational workaround is sometimes unavoidable. It should not be the default cross-market method. Each time people manually catch a structural problem, the team pays a cost that could have been paid earlier, and the same cost returns with the next market.

A common situation is that the problem is placed on the translation schedule until the interface is already locked and only a few days of the release window remain. The team is no longer choosing a better design. It is choosing which loss is smaller.

Mature internationalization does not mean the product can be translated at the end. It means the product was given, from the start, room to run, to be adjusted and to be checked in more than one market.