为什么要统一
- 好管理
- 由产品提供, 移植性高
- 多语言的翻译专业结构一般是按照词条收费的,统一能减少冗余、减少冗余就能省钱
1. 目标
- 通过 表格管理 多语言词条，确保 iOS、Android、React Native 端统一使用 相同的 key。
- 翻译由产品提供，客户端通过 脚本同步表格，生成各端适配的多语言文件。
- 格式化替换符的统一，以 iOS 格式 为标准，通过脚本转换为各端格式。
2. 表格管理
- 词条 key：三端共用，确保一致性。
- 翻译内容：表格提供各语言版本（如
zh_CN、en_US）。 - 替换符：统一采用 iOS 语法
%1$@，后续通过脚本转换。
示例：
| Key | 中文 (zh_CN) | 英文 (en_US) |
|---|---|---|
| breakfast_notice | 早上吃了%1@杯牛奶 | I ate %1@ cups of milk this morning |
3. 各端替换符标准
| 平台 | 替换符示例 | 说明 |
|---|---|---|
| iOS | %1$@ %2$@ | 采用 %n$@ |
| Android | %1$s %2$s | 采用 %n$s |
| React Native | 依赖具体实现（推荐匹配 Android 规则） |
4. 脚本转换逻辑
在执行脚本时，根据目标平台自动转换替换符：
- iOS：保持
%n$@ - Android：将
%n$@→%n$s - React Native：与 Android 规则匹配
示例转换：
| Key | iOS (strings) | Android (strings.xml) |
|---|---|---|
| breakfast_notice | 早上吃了%1$@个鸡蛋和%2$@杯牛奶 | 早上吃了%1$s个鸡蛋和%2$s杯牛奶 |
5. 自动化流程
-
产品填写表格，翻译多语言内容。
-
开发/脚本定期同步 表格内容，转换替换符并生成各端所需的 strings 文件：
- iOS (
.strings) - Android (
strings.xml) - React Native（JSON 或其他格式）
- iOS (
-
客户端读取多语言资源，确保翻译可用。
6. 维护方式
- 表格由产品管理，支持批量修改 & 版本控制。
- 脚本自动生成，避免人工干预，减少维护成本。
- 定期回顾格式规范，确保三端一致。
7. 开发流程
总结
不管多少种语言 都可以按照这个逻辑去做词条管理, 好处显而易见, 对于组件化的词条拆分也是有好处的
