软件本地化：让您的应用程序适应全球市场
软件本地化是指将应用程序适配不同语言和地区的过程。借助现代工具和最佳实践，全面了解从国际化到部署的完整软件本地化流程。
什么是软件本地化？
软件本地化（也写作软件本地化）是指将软件产品进行调整，以满足目标市场的语言、文化和技术要求的过程。它不仅限于简单的文本翻译，还包括用户界面调整、日期和数字格式设置以及文化定制。
计算机软件本地化涵盖桌面应用程序、Web 应用程序、移动应用程序和嵌入式系统。虽然每个平台都有其独特的挑战，但核心原则始终如一：将字符串外部化、支持多种语言环境，以及实现翻译工作流的自动化。
软件本地化流程通常始于开发阶段（国际化），并贯穿翻译、测试和部署的各个环节。Better i18n 等现代平台通过人工智能驱动的翻译和面向开发者的 SDK，有效简化了整个流程。
随着人工智能技术的进步，软件本地化已取得长足发展。现代本地化平台采用神经机器翻译作为初译，生成初稿，随后由专业语言专家对质量要求较高的字符串进行审核和润色。这种将人工智能的处理速度与人类专业知识相结合的混合方法，在保持用户期望的语言质量的同时，缩短了新语言版本的上市时间。 团队现在可以在数小时内交付常规 UI 字符串的翻译，并将人工审核资源集中用于营销文案、法律文本和涉及文化敏感性的内容。
软件本地化的范围
- 用户界面标签、按钮、菜单、错误信息和通知文本
- 日期、时间和数字格式已根据地区惯例进行调整
- 版面调整与从右到左（RTL）语言支持
- 根据文化背景进行本地化的图片、图标和多媒体内容
- 各目标市场的法律与合规要求
软件本地化类型
软件本地化因平台而异。每种平台都有其独特的文件格式、工具链和部署注意事项，这些因素共同决定了本地化工作流程。
Web 应用本地化
针对多语言环境适配单页应用（SPA）和服务端渲染框架。涉及浏览器语言环境检测、CDN 分发翻译包、基于动态路由的语言切换以及 SEO 友好的 hreflang 实现。
移动应用本地化
使用 .strings 和 .stringsdict 文件本地化 iOS 应用，使用 XML 字符串资源本地化 Android 应用，以及适配 React Native 和 Flutter 等跨平台框架。包括针对各目标市场的应用商店列表本地化。
桌面应用本地化
使用 .resx 资源文件适配 Windows 应用程序，使用 .lproj 包适配 macOS 应用，使用 gettext PO 文件适配 Linux 应用。涵盖安装程序本地化、帮助文档及系统级集成。
SaaS 平台本地化
支持云平台的多租户区域设置，包括面向用户的仪表盘、管理界面、事务性电子邮件、API 响应消息以及应用内通知。这需要在微服务之间协调本地化工作。
软件本地化流程
一套从头到尾系统化的软件产品本地化方案。
国际化（i18n）
通过将字符串外部化、支持 Unicode 以及将日期和货币等与区域设置相关的逻辑进行抽象化处理，来准备您的代码库。
翻译
通过专业译者、AI 驱动工具或由 TMS 管理的混合工作流，翻译所有面向用户的字符串。
文化适应
针对文本扩展调整布局，支持 RTL 语言，本地化图片和图标，并将内容适配至各地区的文化规范。
本地化测试
针对所有受支持的语言环境运行语言、功能和视觉方面的质量保证测试，以发现内容截断、编码问题以及文化差异。
为什么软件本地化如此重要
本地化软件能覆盖更广泛的受众，并在参与度、留存率和收入方面带来可衡量的业务成果。
- 无需重新开发产品即可拓展新市场
- 通过母语体验提升用户留存率
- 相较于仅提供英语的竞争产品获得竞争优势
- 开拓来自国际用户的新收入来源
- 满足地区合规性和无障碍访问要求
- 加强品牌在当地市场的认知度
软件本地化最佳实践
遵循这些行之有效的做法，可高效地对您的软件进行本地化，并确保质量。
提前规划本地化
从第一天起就以本地化为出发点设计架构。在成熟代码库中补充 i18n 的成本远高于从一开始就将其纳入构建。
将所有字符串外部化
切勿将面向用户的文本硬编码。请将所有字符串存储在外部资源文件（JSON、XLIFF）中，以便翻译人员无需接触代码即可进行工作。
使用 ICU 消息格式
使用 ICU MessageFormat 来处理复数、性别和复杂格式，而不是使用会在不同语言间导致错误的字符串拼接。
自动化工作流程
将您的 TMS 与 CI/CD 流水线集成，自动同步新字符串、触发翻译并部署更新，无需人工交接。
持续测试
在每次构建时运行自动化本地化测试，以便在内容进入生产环境之前，及时发现文本截断、翻译缺失和编码问题。
为译者提供背景信息
请在翻译键中添加截图、字符限制及用法说明，以便译员能产出准确且符合上下文的译文。
软件本地化工具与平台
借助合适的工具，本地化工作将不再是手动操作造成的瓶颈，而是能够高效、可重复的流程。大多数团队会结合这三类工具，构建一套完整的本地化解决方案。
翻译管理系统（TMS）
集中化平台，管理完整的翻译生命周期——组织字符串文件、协调译者分配、维护翻译记忆库，并跨语言追踪进度。TMS 是任何可扩展本地化工作流的核心支柱。
计算机辅助翻译（CAT）工具
桌面或云端工具可帮助专业译员通过翻译记忆库、术语表查询和术语管理来提高工作效率。计算机辅助翻译（CAT）工具会建议之前已获批准的译文，并确保大型项目中译文的一致性。
持续本地化平台
像 Better i18n 这样的开发者优先平台，能够直接与 CI/CD 管道和源代码控制系统集成。它们会自动检测新字符串、触发翻译并部署更新的语言文件，确保本地化工作与每次代码发布保持同步。
软件本地化的关键指标
跟踪这五项指标，以评估本地化工作的健康状况，并在瓶颈问题影响国际用户之前及时发现并解决。
翻译覆盖范围
每个语言区域的字符串翻译完成百分比。目标：正式发布的语言区域需达到 100%。
上市时间
从新增英文字符串到部署翻译所需的天数。持续本地化可将这一时间缩短至 24 小时以内。
语言质量
每个语言区域的 LQA（语言质量保证）评分，衡量准确性、流畅性和术语一致性。
伪本地化通过率
正确处理文本扩展、特殊字符和长字符串的 UI 元素所占的比例。
未翻译字符串数量
生产环境中缺失的翻译键数量。对于已发布的语言环境，该数值应为零。
关于软件本地化的常见问题
国际化与本地化有什么区别？
国际化（i18n）是对软件进行设计的过程，使其无需修改代码即可适配不同语言和地区——包括外部化字符串、支持 Unicode 以及抽象依赖区域的格式化逻辑。本地化（L10n）是针对特定区域实际调整软件的过程——翻译文本、调整布局，以及为文化相关性定制内容。i18n 由开发者一次性完成；L10n 则由译者和本地化工程师针对每个区域逐一完成。
我应该什么时候开始规划本地化工作？
尽早开始——最好是在架构和设计初期。在现有代码库中追加国际化功能，其成本远高于从一开始就将其纳入设计。即使上线时只支持一种语言，从一开始就将字符串外部化并使用合适的国际化库，也能让日后添加语言变得轻而易举。
如何处理在其他语言中会变长的文本？
文本膨胀是本地化过程中最常见的问题之一。德语文本通常比英语长30%至40%，而中文和日语则往往更为精炼。应使用自动调整大小的容器设计灵活的布局，避免在文本中使用固定宽度的元素，并在获得实际译文之前，利用模拟文本膨胀的伪本地化工具进行测试。
软件本地化使用哪些文件格式？
常见的格式包括 JSON（Web 和移动应用）、XLIFF（行业标准交换格式）、.strings 和 .stringsdict（iOS）、XML 资源（Android）、.resx（Microsoft .NET）、PO/POT 文件（gettext/开源）以及 ARB 文件（Flutter）。最佳选择取决于您的技术栈和工具。大多数翻译管理系统都支持所有主流格式。
我应该使用机器翻译还是人工翻译？
大多数团队采用混合模式。对于支持文章和内部文档等内容量大、风险较低的内容，机器翻译（MT）效果良好。而面向客户的用户界面字符串、营销文案和法律内容，则更适合采用人工翻译或机器翻译加人工后编辑（MTPE）的方式。如何取得恰当的平衡，取决于您的内容类型、质量要求和预算。
什么是持续本地化？
持续本地化是指将翻译直接集成到 CI/CD 管道中，从而自动检测新字符串和更新后的字符串，将其发送进行翻译，并随代码变更一同部署。与将翻译工作批量处理并纳入定期发布周期不同，持续本地化能确保每个语言环境始终与源语言保持同步。支持此工作流的平台会监控您的代码库中的字符串变更，自动触发翻译任务，并将完成的翻译合并回构建中——从而使团队能够在每次部署时发布本地化版本。
如何处理从右到左语言的本地化？
对于阿拉伯语、希伯来语和波斯语等语言的从右到左（RTL）本地化，仅将文本方向翻转是不够的。请使用 CSS 逻辑属性（例如使用 margin-inline-start 代替 margin-left），以便布局自动镜像。根据当前的语言环境，在 HTML 根元素上设置 dir 属性。请谨慎处理双向文本——即使在 RTL 内容中，数字、URL 和代码片段仍应保持从左到右的显示顺序。 在向真实用户发布前，请通过 RTL 模拟本地化进行全面测试，以发现布局问题、图标对齐错误及文本截断等问题。