什么是软件本地化？

软件本地化包括以下步骤：

• 准备要翻译的代码
• 导出软件字符串
• 微调解析和分段策略
• 制定一个关键术语列表（术语表）
• 创建软件翻译项目
• 分配翻译人员
• 分配给审阅者
• 查询管理
• 自动化 QA 检查
• 重新导入已翻译的字符串
• 在暂存环境或屏幕截图中进行 QA 检查
• 测试

在本文中，我们将探讨这些不同的组件及其在整个本地化过程中的影响。

准备翻译代码

虽然一些软件 在编码时考虑了翻译，但通常翻译是在软件已经成熟时弹出的要求。 为了准备代码进行翻译，需要仔细查看变量、日期以及可翻译内容与代码的整体架构。 日期、货币和其他因素会根据区域的不同而改变格式。 如果它们是硬编码的，则需要将它们重新编码为动态实体，以实现跨文化的灵活性。 根据代码的编写方式，将代码与可翻译文本隔离可能非常容易或困难。 这将影响导出字符串的下一步，但它可能是软件本地化中最容易被忽视和低估的方面。 代码与文本简单性的每一次涟漪都会导致无数的波澜，这将影响整个本地化过程。 这可能会导致难以保持代码的完整性或使其对翻译人员友好。 当然，您可以通过解析和分段策略来克服其中一些挑战，但如果您能在不受代码干扰的情况下导出更干净的可翻译内容，您的软件本地化过程将会更好（更可持续和可扩展）。

导出软件字符串

导出字符串应该是一个简单的过程。 但事实并非如此。 某些格式是首选，而其他格式则应避免使用。 首选格式示例： XML、YAML、JSON。 它们结构化、可预测、易于解析，并且在代码中相对容易查找模式，从而减少了翻译成不同语言时出现的问题。 需要避免的格式示例： TXT、CSV、混合代码。 例如，CSV 导出可能会成为一场噩梦。 分隔字符如分号是必要的语言工具。 要在算法上区分用作代码中断的分号和用作译员工具的分号几乎是不可能的。 这会产生数百个误报，需要在质量保证过程中检查这些误报，并在重新导入代码等过程中处理这些问题。 例如，对于混合代码，我们指的是包含 JSON 的 XML，这增加了解析和分段过程的复杂性。 编码也是一个关键痛点：

• HTML 编码
• URL 编码
• Unicode 编码
• Base64 编码
• 十六进制编码
• ASCII 编码

这些编码框架中的每一个都会在 本地化过程中产生影响，包括字符不兼容，具体取决于包含的语言。

微调解析和分段策略

如果您遵循了上面列出的最佳实践，那么您的解析和分段策略将成为流程优化器。 如果您还没有，解析和分段将成为流程推动因素。 作为流程优化者，精细调整的分段策略将确保内容以对翻译人员和审阅人员友好的方式被您的 翻译管理系统 吸收。 在这里，您可以确保变量受到保护，任何剩余的代码都受到保护，并且文本以对翻译过程有意义的方式被分割。如果您还没有做功课，这就是事情可能变得疯狂的步骤。 要么是因为创建足够的解析来保护代码和变量是不可能的，要么是因为编写足够的正则表达式以使软件内容更易于翻译需要极大的努力。 无论哪种方式，这都是关键的一步。 如果您随着时间的推移更改解析和分段策略，您将在翻译记忆库利用方面遇到损失，这将导致额外的成本和流程复杂性。 在它炸到你的脸上之前，这似乎没什么大不了的。 例如，假设您的整个软件有 100,000 个单词，并且您正在翻译成 10 种语言，而且您的每个单词的平均成本为 0.15 美元。 假设您已经翻译了您的软件，但现在对解析策略进行迭代，这将导致利用率损失10%（这可能是解析中小改动的预期结果），这意味着一开始就损失了$15,000，更不用说所需的额外时间和其他影响。

开发一个关键术语列表（词汇表）

任何人都可以开发一个词汇表。 很少有人能发展出一个伟大的。 有些人采用统计方法，从内容数据库中挖掘出最常出现的关键词。 虽然这加快了进程并根据频率捕捉了重要的术语，但一些关键术语并不一定经常使用。有些人采用定性方法，让翻译人员浏览大量内容并手动识别相关术语。 其他人使用AI寻找语言模式，并识别实体和术语，这些术语不一定仅仅基于频率，而是基于它们的整体语义相关性。无论采用何种方法，在术语表方面，少即是多。 虽然您希望确保捕获了基本术语，但如果将太多术语标记为术语表术语，则几乎不可能确保对正确应用的治理。 过多的误报和警报使翻译人员和审校人员难以管理术语建议和运行自动 QA 检查器。 词汇表的另一个提示是，标记不应翻译的术语与需要特定类型翻译的术语一样重要。

创建软件翻译项目

此步骤在很大程度上取决于您使用的翻译管理系统的框架。 一些系统将允许您在同一环境和项目中管理整个项目生命周期，而其他平台则需要不同的方法，可能是基于字符串或文件的。 虽然这看起来可能只是一个形式，但建立实际的翻译项目有关键检查点，例如：

• 确保完整地摄取文件
• 确保语言对在区域设置级别是正确的
• 确保日期正确无误
• 确保工作流步骤是必要的
• 分配给翻译人员

在此步骤中，我们假设您已经有一个经过审核的翻译团队，可以根据语言对进行分配。 与以下翻译人员合作是关键：

与翻译者相同，但更加强调批判性的辨别。 您需要足够挑剔的审阅者，他们能够理解风格和错误之间的区别。 在流程的这个阶段，如果审校人员更改过多，则会损害整个翻译流程的完整性。 这就是 Bureau Works 专有质量管理框架派上用场的地方。

查询管理

软件翻译的一个关键部分是能够解决在翻译过程中出现的问题。 例如，按钮“X”代表什么，或者这个变量指向什么？重要的是要有一个流程，允许您提出有关源语言的问题，并为项目中的所有翻译人员提供答案，无论他们的语言对如何，以最大限度地减少重复回答同一问题。 同样重要的是要有一种方法为查询分配不同的状态，例如新建、已分配、已解决等，以便您的项目管理团队能够确保及时回答查询。

自动质量保证检查

对于任何软件本地化过程至关重要，自动化 QA 检查确保某些关键项目被标记，例如：

• 尾随空格
• 字符限制
• 标点符号不一致
• 术语表不遵从
• 拼写
• 标签不一致（源代码和翻译代码不匹配）
• 重新导入翻译后的字符串

如果你已经活着走到这一步，那你一定做对了什么！:) 它可以不那么痛苦，但你在这里。 现在，可以将字符串重新导入回存储库并重新构建软件。 如果您错过了前面概述的任何最佳实践或管理不善，则由于代码中断、标签不匹配或其他可能影响代码成功重新采用的问题，您可能会在此步骤中遇到困难。

自动化质量保证流程还可以与自动身份验证等工具集成，以提高安全性并确保本地化工作中的数据准确性。

来源： LinkedIn

QA 检查在暂存环境或屏幕截图中

如果此步骤与测试合并，可以忽略此步骤，但为翻译人员提供暂存环境或主屏幕截图的访问权限会很有帮助，以确保字符串正确显示，并且没有阻止测试开始的明显问题。

测试

这是一个超越明显的错误检测和修复的阶段。 通过测试，可以在上下文中重新审视已翻译的字符串。 一些在翻译过程中看起来完美的翻译，从用户体验的角度来看可能不是最好的。 与致力于改善用户体验而不仅仅是被动寻找漏洞的测试人员合作非常重要。

结论

软件本地化是一个广泛、昂贵且复杂的过程。 但不仅如此。 它是迭代和连续的，这意味着您将经历无数次相同的过程，以便在软件不断发展时更新您的软件。 这是对一个过程的高级和肤浅的概述，该过程可能会变得无限更加微妙和复杂。 但关键的收获是，从一开始就投资于一个框架和最佳实践是值得的。 一旦船启航，修复它将变得越来越具有挑战性和昂贵。