What breaks when you ship to ten locales at once
What breaks when you ship to ten locales at once
当你同时发布十种语言版本时，会发生什么问题？
I localized a mobile app into ten languages. Most of what I’d read beforehand was about how to translate. Almost none of it was about what goes wrong after, which turned out to be the harder half. These are the mistakes I actually made.
我曾将一款移动应用本地化为十种语言。在此之前，我读到的大多数内容都是关于“如何翻译”的，几乎没有任何内容提到翻译之后会出什么问题，而这恰恰是更难处理的一半。以下是我亲身犯过的错误。
1. I translated the content and left the chrome in English
1. 我翻译了内容，却把界面框架留成了英文
This is the one I’d undo first. The quiz content — the part users came for — got translated properly. The surrounding interface did not, or did only partly. Settings, error states, the subscription screens, legal copy, empty states. The result is worse than an English-only app, because it sets an expectation and then breaks it. A user who has been reading comfortably in their own language hits a wall precisely when something has gone wrong or something is being asked of them. The experience doesn’t degrade gradually; it fractures at the exact moments that matter most. The lesson: a locale is either done or it isn’t. Partial coverage is not partial credit. If you can’t finish a language, ship it later.
这是我最想撤回的一项。测验内容（用户真正关心的部分）翻译得很到位，但周围的界面却没翻译，或者只翻译了一部分。比如设置、错误状态、订阅页面、法律条款、空状态页面等。结果是，这比纯英文应用更糟糕，因为它先建立了一种预期，随后又打破了它。当用户正沉浸在母语阅读中时，一旦遇到问题或需要进行操作，就会立刻撞上一堵“语言墙”。用户体验不是逐渐下降的，而是在最关键的时刻直接崩塌。教训是：一种语言要么彻底完成，要么就别做。部分覆盖并不等于部分得分。如果你无法完成某种语言的本地化，那就晚点再发布。
2. I shipped locales before I knew anyone wanted them
2. 在确认有人需要之前，我就发布了多语言版本
Adding a language feels like growth. It is cheap to start and expensive forever: every string you ever write afterwards is now ten strings, every feature ships at the speed of your slowest translator, every bug report might be a translation bug. I added languages because I could reach those speakers, not because I had evidence they were waiting. Some were right. Some were an ongoing tax I’m still paying. The lesson: treat each locale as a permanent operational commitment, not a one-time content cost. Ask what evidence would justify it, then go find that evidence first.
增加一种语言感觉像是增长。它启动成本很低，但维护成本却是永久的：之后你写的每一行代码现在都变成了十行，每个功能的发布速度取决于你最慢的译员，每一个错误报告都可能是翻译问题。我增加这些语言是因为我可以触达那些用户，而不是因为我有证据表明他们在等待。有些是对的，有些则成了我至今仍在支付的“持续税”。教训是：将每种语言版本视为一种长期的运营承诺，而不是一次性的内容成本。先问问自己有什么证据能证明其必要性，然后先去寻找这些证据。
3. I couldn’t review what I couldn’t read
3. 我无法审核我读不懂的内容
Obvious in hindsight. I shipped languages I don’t speak, with no process for knowing whether they were any good beyond “the translator seemed competent.” You cannot eyeball your way out of this. You need either a native reviewer who is separate from the translator, or a sampling process, or both — and you need it before launch, because the alternative is finding out from a one-star review written in a language you’ll have to machine-translate to read. The lesson: budget for review as a separate line from translation. They are different jobs and the same person should not do both.
事后看来这很明显。我发布了我不懂的语言版本，除了“译员看起来很专业”之外，没有任何流程来判断翻译质量。你无法靠“目测”来解决这个问题。你需要一位独立于译员之外的母语审核员，或者一套抽样检查流程，最好两者兼备——而且必须在发布前完成，否则你只能通过一条一星差评来发现问题，而那条评论你还得靠机器翻译才能读懂。教训是：将审核预算作为与翻译分开的独立项目。它们是不同的工作，不应由同一个人完成。
4. I let terminology drift
4. 我任由术语不统一
Several translators, one corpus, no glossary. The same domain term ended up rendered three different ways across the app. Each individual choice was defensible. Collectively it made the product feel like it had been assembled from parts, and worse, it made the material harder to learn from — the whole point of consistent terminology in educational content is that the learner builds one mental model, not three. The lesson: the glossary comes before the first word is translated. Retrofitting consistency across a large corpus is enormously more expensive than establishing it.
多名译员，一个语料库，却没有术语表。同一个领域术语在应用中出现了三种不同的译法。每一个单独的选择都有其道理，但合在一起，产品就像是用零散部件拼凑出来的。更糟糕的是，这增加了学习难度——教育内容中保持术语一致性的核心目的，是让学习者建立一个统一的思维模型，而不是三个。教训是：术语表必须在翻译第一个词之前就准备好。在庞大的语料库中后期修正一致性，其成本远高于最初就建立好规范。
5. I assumed text length was roughly constant
5. 我假设文本长度大致相同
German and Russian run substantially longer than English. Some languages run shorter. Either way, layouts built around English string lengths break — truncation, wrapping into two lines, buttons growing past their container, labels colliding. This is not caught by review, because reviewers read text, they don’t measure it. It is caught by pseudo-localization — rendering your UI with artificially lengthened strings before you have any real translations — which costs almost nothing and would have saved me a round of layout fixes.
德语和俄语的文本长度通常比英语长得多，有些语言则更短。无论哪种情况，基于英语长度设计的布局都会崩溃——文字被截断、自动换行、按钮超出容器、标签重叠。这在审核中很难发现，因为审核员只读文本，不测量长度。这可以通过“伪本地化”（pseudo-localization）来解决——在获得真实翻译之前，用人为拉长的字符串来渲染界面。这几乎不需要成本，却能帮我省去一轮布局修复工作。
6. I treated RTL as “a language”
6. 我把从右向左（RTL）排版仅仅当作“一种语言”
Arabic isn’t another locale in the list; it’s a different layout direction. Mirrored navigation, flipped icons that indicate direction, number and punctuation handling inside mixed text. Most frameworks handle the basics. The basics are not the problem — the problem is every place someone hardcoded a left margin, every directional icon that shouldn’t flip (a play button) sitting next to one that should (a back arrow), and every string that mixes scripts. The lesson: if RTL is in your plan, put it in early. Adding it after a year of LTR-only development means auditing every layout you’ve written.
阿拉伯语不仅仅是列表中的另一种语言，它是一种完全不同的布局方向。镜像导航、指示方向的图标翻转、混合文本中的数字和标点处理。大多数框架能处理基础功能，但基础不是问题所在——问题在于那些硬编码的左边距、那些不该翻转的图标（如播放按钮）与应该翻转的图标（如返回箭头）混在一起，以及混合脚本的字符串。教训是：如果你的计划中包含 RTL，请尽早加入。在仅支持从左向右（LTR）开发一年后再添加 RTL，意味着你必须审计你写过的每一个布局。
What I’d do differently
我会做出的改变
Pick two languages. Do them completely — content, interface, store listing, support. Build the glossary, the review process and the pseudo-localization step while the surface area is small enough to hold in your head. Then add the third. The instinct is to go wide early because the marginal translation cost looks low. The translation is not the cost. Everything downstream of it is.
先选两种语言，彻底做好——包括内容、界面、商店描述和支持服务。在工作量还小到足以掌控时，建立好术语表、审核流程和伪本地化步骤。然后再增加第三种。人们的直觉是尽早铺开，因为边际翻译成本看起来很低。但翻译本身不是成本，翻译之后的所有下游工作才是。