Localization — 本质，内容针对语言和地区的适配

什么是 Localization (l10n) 与 i18n 有何不同？

Localization（简称 l10n——"l"和"n"之间的 10 个字母）——是将应用适配到特定语言和地区的过程。如果说 i18n 是架构基础，那么 l10n 就是内容填充。i18n 使翻译成为可能，l10n 则执行翻译。本地化包括：翻译所有界面文本、适配日期和数字格式、替换具有文化敏感内容的图像、修正法律文本（隐私政策、EULA）、为地区配置支付系统以及在目标设备上进行测试。

商业回报率——本地化直接影响转化率。根据 CSA Research（2023）的数据，76% 的用户偏爱在母语应用中购买，40% 的用户从不使用外语购买。零售应用本地化为日语可平均提高 150% 的转化率（Google, 2022）。本地化应用在区域 App Store 和 Google Play 中，得益于区域 ASO（目标语言的关键词），获得的自然安装量是原来的 2-3 倍。

i18n 与 l10n——同一过程的两个方面。i18n：将字符串提取到资源中、支持 RTL、数字格式化。由开发人员一次性完成。l10n：翻译字符串、适配内容、本地测试。由翻译人员和 QA 针对每个本地化多次进行。在 IT Sectr，我们为每个新语言的本地化预留 20-30% 的迭代时间——这包括翻译、审查、在设备上测试和修复错误。

iOS 本地化：Localizable.strings 和 Base Internationalization

Localizable.strings——iOS 中存储翻译的主要文件。每个本地化都有自己的 .lproj 文件夹：en.lproj/Localizable.strings、ru.lproj/Localizable.strings、de.lproj/Localizable.strings。格式："key" = "value";（带分号）。Apple 使用 Base Internationalization：Storyboard 和 XIB 只需创建一次（Base.lproj），界面字符串会为每种语言导出到 Localizable.strings。这消除了为每个本地化创建 XIB 副本的需要。

// en.lproj/Localizable.strings
// "settings.title" = "Settings";
// "profile.greeting" = "Hello, %@!";
// "items.count" = "%d item(s)";

// ru.lproj/Localizable.strings
// "settings.title" = "设置";
// "profile.greeting" = "您好，%@！";
// "items.count" = "%d 件";

// 按键加载字符串
navigationItem.title = NSLocalizedString(
    "settings.title",
    comment: "设置屏幕标题"
)

// 带参数的字符串
let name = "安娜"
greetingLabel.text = String.localizedStringWithFormat(
    NSLocalizedString("profile.greeting", comment: ""), name
)

// XLIFF 导入（Xcode → Editor → Import Localizations）
// 翻译人员工作后自动更新 .lproj 文件

Base Internationalization——Apple 的方法，界面（Storyboard、XIB）在 Base.lproj 中创建一次。添加语言时，Xcode 将字符串从 Base 导出到 XLIFF 文件。翻译人员翻译 XLIFF。导入后，Xcode 创建包含已翻译字符串的 .lproj。优点：无需为每种语言复制 XIB。限制：对于 RTL 语言（阿拉伯语、希伯来语），可能需要具有镜像布局的独立 XIB。

InfoPlist.strings 和元数据本地化

InfoPlist.strings——用于本地化应用名称（CFBundleDisplayName）、相机/麦克风权限（NSCameraUsageDescription）以及 Info.plist 中其他值的文件。在 .lproj 中创建：ru.lproj/InfoPlist.strings。格式：CFBundleDisplayName = "我的应用"; NSCameraUsageDescription = "应用需要访问相机以拍摄照片";。如果不本地化 InfoPlist.strings，系统对话框将显示为英文。

Android 本地化：values-ru、本地化资源

Android 资源通过目录名称中的限定符（qualifiers）来组织本地化。对于俄语——res/values-ru/，对于德语——res/values-de/，对于巴西葡萄牙语——res/values-pt-rBR/。Android 支持 160 多种本地化。系统根据设备语言自动选择资源（Locale.getDefault()）。如果精确的本地化不存在——则使用 values/（基本本地化，通常是 en）中的资源。

// res/values/strings.xml（基本——英语）
<string name="settings_title">Settings</string>
<string name="greeting">Hello, %s!</string>

// res/values-ru/strings.xml（俄语）
<string name="settings_title">设置</string>
<string name="greeting">你好，%s！</string>

// res/values-de/strings.xml（德语）
<string name="settings_title">Einstellungen</string>
<string name="greeting">Hallo, %s!</string>

// Kotlin——所有语言的统一代码
textView.text = getString(R.string.settings_title)

// 带参数的字符串
val greeting = getString(R.string.greeting, userName)

// 本地化图像
// res/drawable-ru/flag.png——俄语版本的旗帜
// res/drawable/flag.png——默认旗帜

// 布局本地化（针对 RTL 语言）
// res/layout-ar/activity_main.xml——阿拉伯语版本

不仅是字符串的本地化——Android 允许本地化图像（res/drawable-ru/）、颜色（res/values-ru/colors.xml）、尺寸（res/values-ru/dimens.xml）、动画、菜单甚至整个布局。对于单词长度不同的语言（德语比英语长 30-40%），使用具有增大按钮宽度的本地化 dimens.xml。对于具有不同颜色象征意义的地区（白色——在中国代表哀悼）——使用本地化的 colors.xml。

在设备上检查本地化

测试——通过设置 → 系统 → 语言将设备语言切换到目标语言。检查：所有字符串都已翻译、日期格式正确、数字使用正确的分隔符显示、图像符合地区要求、布局在长字符串下不会"损坏"。对于自动化，使用带有 LocaleTestRule（Android Testing Library）的 Espresso——它允许在不手动切换语言的情况下使用不同本地化运行测试。

文化适配：除了文本还需要翻译什么

文化特征——本地化不仅限于翻译字符串。颜色象征意义不同：红色——在中国代表幸运，在美国代表危险，在南非代表哀悼。白色——在欧洲代表纯洁，在中国代表哀悼。手势图标：竖大拇指——在美国代表积极，在中东代表侮辱。人物图像：在阿拉伯国家，穿泳装女性的图像是不可接受的。宗教符号：十字架、新月、大卫之星只能在适当的上下文中使用。

法律要求——每个国家都有自己的数字产品法律。GDPR（欧盟）——强制要求同意 cookie 和数据处理。CCPA（加利福尼亚）——删除数据的权利。个人数据法（俄罗斯，152-FZ）——将数据存储在俄罗斯联邦服务器上。LGPD（巴西）——类似于 GDPR。支付：在中国需要 Alipay/WeChat Pay，在印度需要 UPI，在巴西需要 Boleto 和 PIX。在启动本地化之前，为区域配置支付网关。

示例和内容——根据区域调整示例。对于德语本地化，使用公制系统（千克、千米），对于美国本地化，使用英制系统（磅、英里）。电话号码、邮政编码、地址——格式各不相同。货币示例：日本 ¥1000、美国 $9.99、俄罗斯 999 ₽。食物、服装、室内图像应符合区域标准。在 IT Sectr，我们建议聘请当地顾问来检查文化适配。

本地化流程：工具、翻译人员、CI/CD

本地化工具——专业平台可自动完成流程：Lokalise、Crowdin、POEditor、Smartling、Phrase。它们与代码仓库集成，自动导入新字符串，跟踪更改（增量更新——仅翻译已更改的字符串），提供翻译记忆库（TM——存储以前翻译过的短语）和术语表（Glossary）。专业翻译的平均成本：每词 0.08–0.15 美元（取决于语言）。

流程——(1) 开发人员将 i18n 键添加到代码中，推送到仓库。(2) CI/CD（GitHub Actions / GitLab CI）自动将新键发送到本地化平台。(3) 翻译人员收到通知，进行翻译并保存。(4) 翻译后的文件自动在仓库中创建 PR。(5) QA 在设备上检查本地化。(6) 发布。一个本地化的周期：2–5 个工作日（取决于数量）。对于 10 个本地化：在翻译人员并行工作的情况下需要 5–15 天。

机器翻译 + 人工审核——现代标准。神经网络翻译（DeepL、Google Translate、GPT-4）为流行的语言对提供 80-90% 的质量。人工翻译检查：术语、上下文（单词在不同屏幕上可能有不同含义）、文化适配。在 IT Sectr，我们采用混合方法：机器学习翻译 + 母语者审核。对于关键字符串（法律、支付）——仅限专业翻译人员。节省：在保持质量的同时节省高达 60% 的成本。