多语言移动应用开发和更新的专业提示

多语言移动应用程序开发的成功将取决于代码的优雅程度。 如果它写得草率或不遵循最佳实践，您将花费大量时间解析和解决不一致之处。

输入垃圾，输出垃圾是编码的基本原则，而在尝试将应用程序翻译成多种语言时，这一点尤为明显。不幸的是，很少有开发人员在创建应用程序时考虑到全球化。 相反，他们希望在一个市场取得成功，以后再担心其他市场。 虽然这不是一个不可克服的错误，但它确实意味着您在多市场部署时将面临一些额外的挑战。

多语言移动应用开发提示

如果您在新市场发现了一个机会，您可能急于在其他人利用它之前推出本地化版本。 但是，质量对用户来说永远比速度更重要。 通过花一些额外的时间来制定本地化策略，您可以确保您的应用程序名列前茅。 以下是一些提示，帮助实现这一目标：

审核您的代码

代码的优雅等于 应用本地化 的优雅。 然而，鉴于如今开发团队的规模，系统中有许多人参与，各自有不同的工作方式，这并不罕见。 这些不同的开发协议可能会导致不一致和更大的问题。 要避免此路径，请检查您的代码

• 一致的变量处理
• 标准化标记
• 留下标签的注释和协议
• 易于字符串解释
• 总体编写标准

仔细审查现有代码将使您有时间在本地化过程之前对其进行清理。 这是您可以在内部完成的事情，或者您可以与将此作为标准做法的语言服务提供商合作。

允许本地化专家使用应用程序

为本地化专家提供应用程序的访问权限对于为他们提供翻译上下文是必要的。 这种策略培养了基于使用的术语管理，而不是统计或译员管理。 考虑一下对简单事物的解释，例如在像 Uber 这样的交通平台上“家”这个词的含义。 “Home” 可以指最终用户的住所，也可以指应用程序的主屏幕。 在这种情况下，本地化专家可以根据术语的使用情况来映射术语，而不是简单的统计相关性。 这种关注确保了这两个词的最终翻译在给定的上下文中是有意义的。

了解您的代码存储和传输

无论您是将代码存储在 Github 还是其他存储库中，您都需要一个连接器，以实现从翻译人员到网站的无缝过渡。 这包括允许与本地化内容相关的潜在问题。 想想法国和它对撇号的不同用法。 当您以法语到英语运行机器翻译时，或者反之亦然，这些撇号会破坏代码。 您需要预测这些问题并在连接级别解决它们。 否则，您将一遍又一遍地修复相同的问题。

提供清晰的反馈渠道

反馈渠道适用于内部和外部用户。 您希望您的测试者和用户能够分享信息，并且您需要在他们看到内容之前进行检查。 您以两种形式查看反馈：

1. 用户： 考虑用户界面和体验（UI/UX）。 您如何吸引用户，让他们了解应用程序可以根据反馈进行更改？调查、公众反馈论坛、自动崩溃报告？所有这些选项都将使您能够在特定市场中调整并改进您的应用程序。 反馈还包括根据特定国家的要求建立收集数据的权限。
2. 质量保证： QA 的频率越高，需要管理的输出就越多。 在获取所需信息与尽量减少内容周期的复杂性之间，这是一个微妙的平衡行为。 您还必须考虑在给定平台上进行测试的可访问性。 Android 通常是开放的并允许测试人员部署您可以在任何地方快速模拟的 APK 文件。iOS 更难模拟和测试。 您需要根据这些独立的平台创建不同的测试协议。

为文本构建缓冲区

文本适合一种语言并不能保证适合另一种语言。 看看像英文中的 “church” 这个词这样简单的东西。 在西班牙语中，它被翻译成七个字母的单词“iglesia”。 这意味着它不会适合你为英文版本设置的标准 6 个字母的文本框，并且可能会破坏你的代码。 因此，明智的做法是向文本框添加 30% 的缓冲区，以便为这些差异腾出空间。 有些语言，如德语，因占用的空间比您预期的要多而臭名昭著。

工具帮助引导您进行本地化之旅

命令行界面 (CLI) 将是您工具库中最好的工具。 它简化了文件的查看和管理，让您更容易看到所有内容在流程中的位置。 理想情况下，您将可以访问一个平台，该平台使用比标准术语为基础的电子表格更多的内容来跟踪常用的白话。 它将提供动态工作流管理，如果您更改了英语中的单个术语，则会触发所有其他语言的更改。

您还可以访问这些更改，并根据具体情况批准或拒绝它们，并附有评论。并非所有本地化管理平台都如此强大，但这正是您在多语言移动应用程序开发中所需要的。 它提供了一个端到端的解决方案，允许您在工作中进行构建并消除冗余任务。

借助正确的平台推动您的本地化工作，您将能够在将翻译成本降至最低的同时，将业务扩展到数百个市场。