企业官网建设流程全解析

1. 项目概述与核心思路

1.1 本地化UI元素到底是什么

先说个场景。我早年做的一个工具类App，一开始只上架国内市场，界面全是中文，一切正常。后来想试试海外市场，就面临着把整个界面翻译成英文的活儿。当时年轻，想着“翻译还不简单，把中文文案替换成英文字符串不就行了”。结果真做起来才发现，本地化UI元素这件事，远不是“翻译”两个字能概括的。

项目标题里的“Localize UI Elements”，翻译过来就是“本地化用户界面元素”。它指的是一整套让界面能够适配不同语言、地区、文化习惯的工程手段。UI元素并不只是你屏幕上看到的那些按钮文字、提示语、菜单项，它还包含日期格式、数字格式、货币符号、排序规则、文本方向、图标含义、甚至快捷键配置。任何一个环节没有做好，用户在使用时就会觉得“这产品不像是为我们这里做的”。

这也就是标题编号本身值得注意的地方。0.03.02.04.08这种缩进层级，通常出现在企业内部国际化规范文档里，它把一个庞大的“全球化（Globalization）”工程拆成了多个层级：母项是本地化工程，子项是内容本地化，再往下拆到用户界面元素这一层。这种拆法本身就说明了一件事：本地化UI元素是一个有边界、有结构、有先后顺序的工作，而不是能靠一把梭“翻译完事”的杂活。

我们这篇文章就聚焦在这一层级上：界面上那些可以被用户直接看到、感知到的元素，如何做本地化。

1.2 为什么单独把“UI元素”拎出来讲

很多人会问：我做国际化的时候，把文案抽出来放到strings文件里，然后翻译，不就是在做UI本地化了吗？对，但只做对了一半。

UI元素和其他内容（比如文章正文、商品详情）最大的区别在于：UI元素的空间是有限的、位置是固定的、交互是强绑定的。按钮就那么大，弹出框就那么大，你翻译出来的英文可能是中文长度的两倍，直接撑破布局；德语的一个复合词可能长到让tab栏溢出屏幕；阿拉伯语是从右往左排版的，你所有靠左对齐的图标和文本结构都要映射翻转。

这些都是“用户界面元素”特有的问题。文章正文长了可以滚动，详情页长了可以分页，但导航栏标题、表单label、错误提示、按钮文字、Toast文案，它们没有“变长”的余地。UI元素本地化的核心矛盾，就是在多语言环境下，如何让这些固定空间里的元素依然准确、完整、美观地呈现。

此外，UI元素还承担着“引导操作”的功能。一个“确认删除”的按钮，在日语里如果用了过于礼貌的措辞，用户可能不敢点；在德语里如果用了过于直接的命令式，又显得生硬。界面文案的语用效果，直接影响用户对产品的信任感和操作意愿，这还不是翻译公司能帮你解决的，它需要产品和技术一起配合。

1.3 这篇博文适合谁看

如果你手头有以下任何一种情况，这篇文章应该能帮到你：

• 你正在做一个准备出海的App或网站，需要支持中英双语起步；
• 你的产品已经接到了海外用户反馈，收到的差评里出现了乱码、日期看不懂、文字被截断这类问题；
• 你是独立开发者，想提前把架构设计好，不想以后为了多语言重构代码；
• 你是产品经理或测试，需要对本地化质量做验收，但不知道从哪些维度把关。

这篇文章会从方案选型讲起，一步步拆解字符串资源怎么组织、参数和复数怎么处理、RTL布局怎么适配、测试要测什么，最后再分享一些我踩过的坑。整体走实操路线，按着做基本不会跑偏。

2. 整体设计：本地化工程的结构化拆解

2.1 国际化（i18n）和本地化（l10n）必须先分清

不想清楚这件事，后面的工作都会乱。国际化和本地化是两个不同层次的工作，但很多人把它们混成一谈，导致架构设计时漏掉了重要环节。

国际化（Internationalization，缩写i18n）是在代码和架构层面做的准备工作。它的核心目标是：让产品具备支持多语言、多地区的能力。在代码层面，这意味着你不能把任何用户可见的字符串硬编码在代码里；日期、数字、货币的格式不能写死；布局要能适应不同的文本长度和排版方向。一句话总结：国际化是“把产品和特定语言解耦”。

本地化（Localization，缩写l10n）则是在国际化完成的基础上，为某一个特定的语言和地区提供适配内容。翻译文案只是本地化的一部分，它还包括调整日期格式、适配本地合规要求、选择符合当地审美的图标、甚至调整配色方案。

从这个项目标题来看，“Localize UI Elements”属于本地化层级的任务，但它的前提是国际化已经做完了。你不可能在一个所有文案都硬编码在代码里的项目里，直接跳到“本地化UI元素”这一步。所以在实际落地的过程中，第一步永远是回头检查：你的代码架构是否已经支持外部化的字符串、参数化格式、动态布局。

2.2 典型的资源文件组织方式

在实际项目中，界面元素的本地化通常依赖平台提供的资源文件机制。以移动端和Web为例：

iOS这边，最常见的做法是使用.strings文件，每个语言一个文件，比如Localizable.strings（英文）、Localizable.strings（中文）；在Swift开发中，也可以用.xcstrings统一管理，Xcode 15之后对多语言的支持更完善了，可以在一个可视化的编辑器里管理key和多种语言的译文。

Android则是把字符串放在res/values/strings.xml里，默认语言放在values目录，其他语言放在对应的values-目录下，比如中文是values-zh、日文是values-ja。系统会根据设备的语言设置自动选择对应的资源目录。

Web前端的选择更多样。轻量级的可以用i18next搭配react-i18next或vue-i18n，把文案放在JSON文件里；需要工程化管理的，也可以用FormatJS这类基于ICU MessageFormat的方案，它天然支持复杂的复数规则和日期格式化。

无论用哪种方案，有一条原则是通用的：绝对不要在代码里直接写“你好”或者“Hello”这样的字面量，而是要用一个key来引用。比如home.greeting，然后在资源文件里映射到对应语言的文案。这样做的好处是，key是稳定的，即使某一种语言的文案改了，也不需要动代码；而且key本身可以作为一种语义化的注释，帮助翻译人员理解上下文。

2.3 我把方案选型的思路理一下

如果你还在技术选型阶段，我给一个比较务实的建议：小团队优先用平台原生方案，别一上来就上重型框架。

什么算重型框架？就是那种需要搭建翻译管理平台、自动化流水线、多语言包构建系统的大型方案。对于只有两三种语言的产品来说，这些基础设施带来的维护成本可能比翻译本身还高。原生方案（iOS的strings + Android的strings.xml + Web的i18next）已经能覆盖90%的需求，而且上手快、出问题好排查。

当然，如果你的产品已经有十几个语言版本，翻译团队多人协作，文案量上万条，那就值得引入专业的翻译管理平台（比如Crowdin、Lokalise这类工具），把翻译流程从“改代码提交”变成“翻译平台协作”，产品人员和翻译人员在同一个平台上工作，代码层面只负责拉取最新的语言包。

我在实际项目里见过的最常见踩坑，不是选错了框架，而是选框架之前没想清楚“翻译由谁来维护”。如果你的翻译工作流是“开发自己翻译”，那用什么框架都行，简单就好；如果是“有专职翻译但不会写代码”，那你必须选一个能提供可视化编辑界面的方案，否则翻译人员天天改JSON文件，迟早会出格式错乱的问题。

2.4 界面元素本地化的完整要素拆解

在动手之前，先建一张表，把UI元素本地化的所有要素过一遍。这张表我每次做新项目都会贴到墙上，当作验收清单用。

很多项目第一次做国际化时，只盯着第一行“文本类”，结果到了测试阶段才发现日期格式还是中文习惯、阿拉伯语用户看到的界面布局完全颠倒、截图素材里的中文没处理。这张表的价值在于，它可以让你在规划阶段就把所有类别纳入范围，而不是上线后被打补丁。

3. 核心细节解析与实操要点

3.1 字符串资源：key的命名规范与组织——一个贯穿全文的示例

key命名这件事，表面上看起来只是风格问题，但在大型项目中，key的混乱程度直接决定你后续维护时想不想摔键盘。

我见过几种典型的坏味道。第一种是把key直接命名为英文文案，比如"hello_world" : "你好，世界"，翻译成英文时value也是“Hello world”。这种方式在只有两种语言时问题还不大，但一旦加入第三种语言，你发现key本身变成了英文文案，就无法做到“key与语言无关”；将来要改英文措辞时，key也得跟着变，所有引用它的代码都要动。第二种是key没有层级和分组，翻译文件几千行铺开，搜索一个key要靠肉眼扫，新增一条要担心是不是跟已有的重复。

比较推荐的做法是，把key当作代码变量来管理，遵循“模块名.页面名.元素名”的分层结构。还是用前面那个工具App来举例，假设我们要给设置页面里的“清除缓存”按钮加文案，key可以命名为settings.data_management.clear_cache。这样翻译文件里按字母序排列后，同一个页面的文案自然聚在一起，查找和维护都方便。给翻译人员看的时候，上下文也更清晰，他们能从key的命名推断出这条文案出现在哪个位置、是什么用途。

字符串资源组织上还有一个要注意的点：不要把整句文案拼在一个key里。举个例子，“你有3条新消息”这句话，不要写成一个key为notification.message、value为“你有{count}条新消息”的字符串，而是要把“条新消息”这种可复用的片段拆出来单独一个key，再把数量部分作为参数传入。这样不同语言的语序差异才能被正确处理。中文说“你有3条新消息”，日语说“新しいメッセージが3件あります”，主语和数量的位置完全不一样，参数化的方式能最大程度保留翻译的灵活性。

3.2 占位符与格式化：为什么“{count}”比“%@”好用

在iOS的.strings文件里，字符串格式常见的是"notification.message" = "You have %@ new messages.";。这个%@是Object-C时代遗留的格式符，对应一个对象参数。在Swift里，String(format:)依然支持这套。

但Web和跨平台生态里，现在更主流的是ICU MessageFormat，其中最典型的语法就是{count}这种花括号占位符。比如：

"notification_message": "You have {count} new messages."

然后通过格式化函数传入{count: 3}，运行时就会替换成实际的数字。

为什么我强烈建议用{count}而不是%d、%@这种C风格占位符？有三个原因：

第一，可读性强。翻译人员看到一个{count}，能直观理解这里会填入一个数字；但看到%@、%1$d这种符号，非程序员完全不知道是什么，极容易在翻译时误删或误改。

第二，支持命名参数。{count}和{name}是语义化的名字，而不是位置序号。这在翻译成某些语序完全不同的语言时特别重要——英文的“You have {count} new messages”到了阿拉伯语里，可能是“لديك {count} رسائل جديدة”，参数的灵活移动不会出错，但只要用的C风格的位置参数，翻译人员一旦调整位置，就可能导致格式化崩溃。

第三，能配合复数规则一起用。这一点我们下一篇详细讲，但核心原因是{count}这种命名占位符天然适合交给ICU的复数选择器去处理。

3.3 复数规则：不只是“单数/复数”那么简单

这是本地化UI元素里最容易被低估的一个环节。中文没有复数变化，所以很多中国开发者在写代码时根本不会考虑“数量不同时，文案是否需要变化”的问题。但只要你出海，复数规则就一定会撞到你。

英语里的复数规则还比较简单：1个是单数，0和大于1是复数。但俄语有四种复数形式、波兰语有五种、阿拉伯语有六种。举个例子，阿拉伯语里数字1、2、3到10、11以上、0，每一种对应的名词形式都不一样。

好在大多数国际化框架已经内置了这些规则的实现，比如ICU MessageFormat里的plural选择器。你的核心工作不是在代码里手动实现这些规则，而是把文案按“选择器”的方式组织起来，让框架去匹配当前语言的复数规则。

实操上，文案应该写成这样：

"message_count": "{count, plural, =0 {No new messages} =1 {You have one new message} other {You have # new messages}}"

这里other是兜底分支，不同语言下框架会自动选择对应的分支逻辑。你不需要为每一种语言写不同的格式模板，只需要提供“零、一、其他”这几个在多数语言里都有的分类，ICU框架会把other映射到该语言所需的更多子规则上。

这里有一个非常常见的坑：很多人会把“=0”“=1”写死在英文模板里，然后自以为所有语言都适用。实际上阿拉伯语里“一个”和“两个”用的都是不同且具体的变格，不是简单“=1”能覆盖的。更稳妥的策略是：先用ICU的plural语法来表达所有语言共有的“零、一、多、其他”等类别，具体分支的解析交给框架，翻译人员只需要在CAT工具里看到语境并给出对应的译文即可。

3.4 日期、数字、货币的格式化：你在界面上看到的所有“数字类”元素

文本之外，UI元素里最容易出错的就是各种格式化的数字。

先看日期。中英文环境下，日期格式有本质差异：中文习惯“年-月-日”，美国习惯“月/日/年”，欧洲很多国家用“日.月.年”或“日/月/年”。如果你在代码里写死YYYY-MM-DD，美国用户会困惑，欧洲用户会困惑。正确的做法是，永远不要自己拼日期字符串，而是用平台提供的DateFormatter或者国际化框架的日期格式化功能。在iOS里，要给DateFormatter设置locale属性，然后用.dateStyle和.timeStyle枚举；在Web里，用Intl.DateTimeFormat。

这里有一个很多开发者在测试时才会发现的坑：不要用DateFormatter默认的行为就完事了。不同地区的周起始日不同，有的周日是一周的第一天，有的周一。你写一个日历视图时，第一列是周日还是周一，取决于用户的地区，而不是你的主观偏好。

数字也一样。英文的千分位分隔符是逗号（1,000,000），德语里是句点（1.000.000），中文是逗号但标准不太一样。如果你在文案里用{count}直接拼接数字，用户看到的一定是未格式化的一长串。规范的方案是给数字格式化指定locale，让系统决定怎么加分隔符。

货币更是重灾区。人民币符号显示为“¥”，美元是“$”，欧元是“€”。但符号放前面还是放后面，不同语言也不同：英文通常写“$100”，中文写“100元”，法文写“100 €”。所以处理金额时，同样要把货币格式交给NumberFormatter或Intl.NumberFormat，而不是程序里写死“$+ 数字”。

3.5 RTL（从右到左）适配：阿拉伯语和希伯来语用户怎么看你的界面

这一块是UI元素本地化和内容本地化差异最大的地方。

阿拉伯语、希伯来语、波斯语这类从右向左书写的语言，用户的使用习惯跟我们是镜像的。拿home页举例子：中文用户从左往右扫视，导航栏左上角是返回按钮、右上角是菜单按钮；阿拉伯语用户则相反，返回按钮在右上角，菜单按钮在左上角，文字也从右往左排列。

在iOS上，系统级的semanticContentAttribute提供了.forceLeftToRight和.forceRightToLeft控制，UILayoutGuide也内置了RTL支持。只要你不手动指定leading和trailing时用绝对的left和right，大部分约束可以自动镜像。在Android上，官方推荐用android:layoutDirection="rtl"，配合start和end属性的约束来实现镜像。Web端则需要使用CSS的dir属性、逻辑属性（margin-inline-start、padding-inline-end这些）来适配。

实际操作中最大的坑不在于“原理不知道”，而在于测试不足。很多产品出海时只准备了中英双语，阿拉伯语这个方向的适配直到最后一刻才想起来，结果发现整个UI需要镜像翻转，图标方向、文本对齐、图片的视觉引导方向全都要调整，工作量等于一次小型的界面重构。

我的建议是：如果你的目标市场包含中东地区，或者你希望产品在架构上保持多方向适配的能力，从第一天设计UI时就用逻辑属性（leading/trailing、start/end）而不是物理属性（left/right）。这不算什么高级技巧，只是在写第一行布局代码时就多想一步而已。

3.6 图标与图片的本地化：比文字更隐蔽的UI元素

UI元素里还有一类经常被忽略：图片和图标里的“文字”。

一个典型的失误是：在App引导页里放了一张截图，截图里是中文界面。你做了多语言支持后，这张图片不会变，于是英文用户看到的引导页里出现了一张满是中文的截图，违和感瞬间拉满。

解决方案有三种层次。最简单粗暴的是在图片资源上做语言区分，比如onboarding_zh.png和onboarding_en.png，在资源加载时根据当前语言选择。更优雅的方案是，用矢量图和图标字体替代位图，文字部分用真正的文本元素叠加在图片上，这样文本可以随语言切换。

图标本身也有文化差异。举个我亲自踩过的例子：我们给一个任务管理App设计了一个“垃圾箱”图标表示删除操作。这个图标在大部分市场都没问题，但在某些地区，用户可能对它感到陌生甚至反感。另一个常见例子是“手电筒”图标，中文用户很熟悉“一个手电筒”代表打开手电功能，但某些地区的用户可能根本不认识这个形状。做本地化的专业流程里，针对目标市场做图标可用性测试，不是可选项，而是必选项。

4. 实操过程：从代码到交付的完整流程

4.1 实施前检查清单

在写任何代码之前，先把这几件事确认清楚：

• 代码中是否还有硬编码的字符串？全局搜索中文、英文等字母，确保没有任何用户可见文本直接写在代码里。
• 日期、数字、货币格式化是否全部走了框架方法？有没有自己拼接字符串的情况？
• 布局约束是否已经使用逻辑属性？在同一方向上有没有混用物理属性？
• 资源文件是否已经按目录或命名空间分好类？翻译工作流是否确定（工具、责任人、频次）？

这个清单看起来基础，但能帮你避免“做到一半推倒重来”的尴尬。我在给一些团队做代码评审时，经常看到他们声称“做了国际化”，但一搜代码，硬编码的字符串还是能从犄角旮旯里翻出来。最隐蔽的地方是拼接消息的代码，比如"订单号：" + order.id这样的代码，很容易漏网。

4.2 具体操作步骤演示

下面用一个简化版的“消息列表页”来做实操演示。这套流程在iOS、Android、Web上通用性都很强，区别只在于具体API。

第一步：提取文案，建立key清单。

先扫描所有用户可见文案，给它们配上语义化的key。我建议直接用表格维护，列包含：key、默认语言译文、后续语言译文、出现位置、备注。

第二步：在代码中用key替换文案。

iOS示例（Swift）：

navigationItem.title = NSLocalizedString("message_list.title", comment: "Messages list screen title") emptyLabel.text = NSLocalizedString("message_list.empty", comment: "Empty state message")

Android示例（Kotlin）：

supportActionBar?.title = getString(R.string.message_list_title) emptyLabel.text = getString(R.string.message_list_empty)

Web示例（React + i18next）：

const { t } = useTranslation(); return <h1>{t('message_list.title')}</h1>;

注意给每条key加上context注释（比如iOS的comment参数），这对翻译人员的帮助很大，因为他们无法直接看到界面。

第三步：创建语言资源文件。

英文的Localizable.strings：

"message_list.title" = "Messages"; "message_list.empty" = "No messages yet"; "message_list.accept" = "Accept"; "message_list.decline" = "Decline";

中文的Localizable.strings（在zh-Hans.lproj目录下）：

"message_list.title" = "消息"; "message_list.empty" = "暂无消息"; "message_list.accept" = "接受"; "message_list.decline" = "拒绝";

Android的strings.xml同理，在values-en和values-zh目录下分别建文件。

第四步：处理格式化与复数。

把消息列表里可能出现的“你有3条新消息”改成参数化形式：

"message_list.new_count" = "{count, plural, =0 {You have no new messages} =1 {You have one new message} other {You have # new messages}}";

在代码里传参数：

let count = 3 let message = String.localizedStringWithFormat( NSLocalizedString("message_list.new_count", comment: ""), count )

Web / i18next：

t('message_list.new_count', { count: 3 })

第五步：做RTL方向和布局适配检查。

用iOS的semanticContentAttribute和UILayoutGuide检查约束，Android用android:supportsRtl="true"和start/end约束，Web用CSS逻辑属性。这一步不需要写新代码，但如果前面布局写死过left/right，这里就要逐个修改。

第六步：把文案交给翻译。

如果是自有翻译，直接维护资源文件即可；如果外包，记得把key清单、上下文注释、界面截图一并交付。翻译质量的高低，很大程度取决于你提供的信息是否足够充分。

4.3 一个真实的踩坑记录

之前做一个电商App的国际化时，我犯过一个印象深刻的错误。

当时要把结算页的“总计：¥1,234.56”做国际化，我以为只要把¥符号替换成对应货币符号就行，所以写了个这样的逻辑：根据货币代码，在前面加符号或后面加符号。结果上线后，德国用户反馈价格显示不对，仔细查才发现：德语环境下的欧元格式是“1.234,56 €”，千分位是句点、小数位是逗号、符号在数字后面。我自己拼的格式完全错位了。

后来改成用NumberFormatter，设置好locale和currencyCode，系统自动处理好了一切格式细节。这个坑给到我的教训是：格式类的内容永远不要自己拼接，永远把格式决定权交给系统或者框架，因为你自己无法穷尽所有地区的显示规范。

4.4 测试策略：本地化的验收标准

本地化测试我把它分成三个层次：

第一层是功能测试。切换语言后，所有页面能正常打开，没有崩溃、乱码、溢出；按钮可点击；表单可提交；日期选择器可以正常使用。

第二层是视觉测试。检查文本截断、按钮过宽、图标错位、长文本换行是否正常。这里的经验值是：英文文案通常比中文长30%到50%，德文可能长一倍，所以UI设计时要预留足够的空间。

第三层是文化测试。检查日期、数字、货币格式是否符当地习惯；检查是否存在冒犯性图标或含义不当的文案；检查RTL语言下布局是否镜像正确；检查文案的语气和称呼是否适应该地区文化（日语里的敬语差异、法语的“你/您”区分等）。

这个文化测试层面很多人觉得玄学，但实际影响很大。我记得有个做健身App的朋友，把“keep going”的激励语直接硬翻成中文“保持前进”，用户反馈感觉像机器人说话。后来他们重写了中文文案，改成“别停”，效果立刻不一样。界面文案不是翻译，是重写。

5. 常见问题与排查技巧

5.1 问题速查表

5.2 伪本地化：一个被低估的排查利器

伪本地化（Pseudo-localization）是很多大型国际化团队标配、但中小团队很少用的技术。它的原理很简单：在开发阶段，把源语言的所有字符串通过一种特殊规则“翻译”成一种看起来像外星语言的伪语言，然后运行App。

伪本地化的设计有几个目的。它会刻意把文本长度膨胀30%到50%，把每个字符替换成带重音符号的字符（比如a变成ä或å），这样一来，所有潜在的截断问题、硬编码字符串问题、字符编码问题，都会在开发阶段被暴露出来。你不需要等真实的多语言包交付，就能提前发现整体适配情况。

有些框架已经内置了伪本地化支持。Android的Pseudolocales选项可以直接在开发者选项里启用；iOS在Xcode的Scheme设置里也可以配置。Web端可以自己写一个简单的i18n拦截函数，把所有返回的字符串做字符替换和长度扩展。

我第一次用伪本地化测试时，几乎是立刻就发现了3处硬编码中文和2处布局溢出问题，效果立竿见影。现在我建议每个做国际化的团队，在开发阶段就把伪本地化跑起来。

5.3 排查工具链推荐

除了伪本地化之外，还有几个工具在实际排查中帮了大忙：

• Transifex / Crowdin / Lokalise：这三家的“翻译记忆”和“术语表”功能很好用。同一个词汇在项目里从头到尾保持一致，靠人工很难，但平台可以自动提示术语一致性。
• Languagetool：用于检查译文语法问题的开源工具，虽然不能完全替代人工审校，但对粗心错误很有帮助。
• Screenshot testing（截图比对测试）：给每个语言版本跑一套自动化截图，然后做像素级对比。文本长度异常、布局溢出这类问题在截图对比中一目了然。

工具不在多，核心是让“人工检查”尽量被自动化替代。本地化测试如果全靠人工点、人工截图、人工比对，基本做不完。我的经验是，自动化截图对比至少能覆盖70%的视觉回归问题，剩下30%的文化适配问题，再靠人眼去检查。

5.4 上线后的人工巡检清单

产品上线后，本地化工作并没有结束。我建议在每次发版前，由懂当地语言的人做一轮人工巡检，重点检查：

• 新功能的所有页面文案是否完整翻译；
• 系统弹窗、推送通知、邮件模板中的文案是否与App内保持一致；
• 强制更新的文案和跳转逻辑在不同语言下是否顺畅；
• App Store或Google Play的商店截图、标题、描述是否也做了本地化。

这最后一条很多人忽略。用户最先看到的不是App内部，而是应用商店页面。商店页面的本地化质量直接影响下载转化率，而很多团队的商店本地化是滞后于App本地化的，导致用户下载后感觉“货不对板”。

6. 一些更远的话题和我的真实体会

界面元素的本地化做到一定程度后，你会意识到它本质上不是“翻译”问题，而是“产品心智”问题。

我记得做那个工具App时，中文版本的文案是我们自己写的，语气比较正式。后来做英文版，外包翻译社给了很地道的直译，但读起来特别商业。我们又找了一个英文母语的产品顾问，他把所有文案按“面向个人用户、工具属性、轻量级”的方向重写了一遍。改完之后用户留存和好评率都有明显提升。

所以我的建议是：如果你真的要认真做出海产品，不要把本地化当成“发翻译公司做完了事”的工序。最理想的做法是，在目标市场找一个懂产品、懂文化的母语者来“重写”文案，而不是“翻译”文案。重写的字数和结构未必跟源语言一致，但语用效果和用户感受是最贴合的。

从技术架构上说，这也意味着你的本地化体系要支持这种“重写”——文案长度可能完全不同，需要适配长文本；文案的重点信息位置可能不一样，需要支持不同的语序；按钮的文案措辞可能需要完全替换，而不仅仅是逐词翻译。一个设计良好的本地化架构，应该让这一切发生得自然而不需要返工。

界面元素的本地化，做得好是润物无声的，用户觉得这个产品“本来就是为我的语言和文化设计的”。做得不好，用户能感觉到“这东西是别人硬翻过来的”。差别在于你是否愿意把本地化当作产品体验的一部分来认真对待，而不是发布前的最后一道杂务。

如果这篇文章能帮你少踩几个坑、少走几步弯路，那我觉得写这些字就值了。最后还是那句话：项目编号再复杂，落到界面上就是那一句文案、一个按钮、一个日期格式，把它们一件件做对，产品的全球化之路就会走得更稳。