很多人看到“本地化”就觉得复杂，其实从最简单的输出入手能够把核心问题一条条拆解出来：文本如何抽取、如何替换占位、复数规则怎么处理、还有文本方向和格式化等。这些是所有项目都会遇到的问题，先把 Hello World 问题做到位，后面遇到复杂场景才能有章可循。
示例（坏例子）：
console.log("Hello World");这段代码对单语言足够，但不利于翻译。改成从资源文件读取才是正确方向。
常见做法是按语言建立文件，例如：
一个简单的 en.json：
{
"greeting": "Hello World"
}中文文件：
{
"greeting": "你好，世界"
}真实应用常常要插入变量，比如用户名。约定占位符格式（如 ICU MessageFormat）可以统一处理：
{
"welcome": "Hello, {name}!"
}ICU 的一个优势是支持复数和条件表达式：
{
"apples": "{count, plural, =0 {No apples} one {# apple} other {# apples}}"
}不同语言的复数规则差异巨大：英语通常 one/other，但俄语或阿拉伯语有更多类别。推荐使用支持 ICU 的库（例如 ICU MessageFormat、i18next with i18next-icu、FormatJS）。
不要通过翻译文本手动拼接日期/数字，应该使用标准 API（Intl 在现代 JS 中）或平台自带的 locale-aware 格式化器：
new Intl.DateTimeFormat('fr-FR').format(new Date())注意：时区与本地化是独立维度，决定显示时应区分用户时区与内容时区。
// 初始化
import i18next from 'i18next';
i18next.init({
lng: 'en',
resources: {
en: { translation: { greeting: "Hello World" } },
'zh-CN': { translation: { greeting: "你好，世界" } }
}
});
// 使用
console.log(i18next.t('greeting'));
<string name="greeting">Hello World</string>
<string name="greeting">你好，世界</string>
// en.lproj/Localizable.strings
"greeting" = "Hello World";
// zh-Hans.lproj/Localizable.strings
"greeting" = "你好，世界";
务必统一使用 UTF-8。某些老系统或数据库字段可能使用其它编码，迁移时需要特别注意字符丢失与乱码问题。还有一点：不同语言对字体的支持差异很大，尤其是 CJK 与阿拉伯、印地语等，上线前要验证界面字体是否可显示全部字符。
| 检查项 | 目的 |
| 资源完整性 | 所有键在目标语言存在且未误删 |
| 占位匹配 | 参数化字符串占位与代码中使用一致 |
| 伪本地化通过 | 发现长文本或方向问题 |
| 人工校对完成 | 翻译质量与品牌语气一致 |
现阶段常见且高性价比的做法是先用机器翻译（MT）生成初稿，然后由本地译员做人工后编辑（PE）。优势与要点：
| 任务 | 典型人力/天 | 说明 |
| 字符串抽取与资源组织 | 1-3 | 取决于项目规模，自动化工具能加速 |
| 机器翻译 + 人工后编辑（每千字） | 1-2 | 视语言对与领域专业度而定 |
| 伪本地化与测试 | 1 | 检查溢出与布局问题 |
| 上线前 QA | 1-3 | 包含译审与一轮修复 |
好了，按上面的步骤从 Hello World 起步，慢慢把流程打磨成常规作业。实践中你会发现某些环节可以自动化，某些环节必须人工把关，这两者结合起来，既能保证效率也能保证品牌和用户体验——然后就像修一辆老车那样，一边调整一边开着上路，改得更顺手了自然就好了。
了解更多相关内容
先把问题拆开：能用的关键是什么？ 要想知...
阅读更多 →
费曼式解读：把问题说清楚 把“批量刊登怎...
阅读更多 →