本文反过来试图强调手机APP开发国际化部分的主要问题，该部分一方面对最终用户影响最大，另一方面对日常编码影响很大——界面翻译。尽管在本文中我们将分析如何在手机APP开发中实现国际化，但提供的大多数问题和可能的解决方案都可以手机APP于不同的开发环境。
开发多语言手机APP时面临的首要难题之一是为键选择最合适的命名约定，这将代表要翻译的文本。
有一种诱惑是要么保持键短，从而在需要参考翻译信息时减少打字量，要么保持它们长而深的嵌套，从而具有明确定义的结构。然而，做空通常不是一个好主意。尽管人们不必记住某些翻译的长路径，但它通常会导致看起来笨拙的长键名，这必须支持所需的区分。考虑以下稍微夸张的示例：
en-GB: dashboard_main_table_headers_first_name: First name
很容易被分割成
en-GB: dashboard: main_table_headers: first_name: First name
另一方面，过于嵌套的键可能会变得曲折且难以记忆，实际上许多级别可以很容易地省略而不会引入歧义，例如
en-GB: dashboard show: view: main_section: table: headers: first_name: First name
通过去除一些不必要的关卡并将其中的一些关卡合二为一，我们可以很容易地实现合理的解决方案。
en-GB: dashboard: show: table_headers: first_name: First name
关于密钥创建要问的第二个问题是密钥中实际包含的内容。答案可能是：“只要是直观的、明确的，并且可以让您高效地查找和编写翻译”。这种结构的示例可能如下所示：
例如
en-GB: customer: products: show: label_price: Price
最后一级的命名应该是一致的，每次我们必须这样做的时候不要过多地考虑如何命名特定的键。显然，我们可能需要在翻译中添加一些公共分支，以存储在命名空间等之间共享的键。仍然具有良好定义的命名约定肯定会提高依赖于翻译的繁重手机APP的效率。
在小型手机APP中，没有必要准备比每种语言一个更多的语言环境文件。尽管如此，随着手机APP的增长，翻译文件变得难以维护和管理——因此，经过深思熟虑的语言环境文件树可能是避免这种问题之王的一种方法。作为额外的奖励，为同一手机APP的特定模块分发翻译包会更容易。
翻译文件结构的一些示例
Module name based ..yml ..yml #Shared
例如
invoicing admin.en-GB.yml admin.da-DK.yml admin.en-GB.yml admin.da-DK.yml
Namespace / Role name based ..yml ..yml #Shared
或者
admin invoicing.en-GB.yml invoicing.da-DK.yml invoicing.en-GB.yml invoicing.da-DK.yml
l ..yml ..yml #Shared
等等……您甚至可以将语言包放在不同的目录中。在大多数情况下，对于大多数情况来说，一层嵌套感觉就足够了。这取决于您选择哪种方法，并且最适合给定的手机APP。
持续的开发、升级、重构等通常会导致翻译文件中出现孤立的翻译分支，除非非常注意保持一切潮流。无论如何，有时我们想检查我们的翻译文件是否有点太大。第一个想法是扫描源代码中的键并将其与语言环境文件中的任何内容进行比较——之后，只需删除代码中未提及的所有键。这实际上有两个缺点。
第一个是如果使用键继承或者某些键不是从主手机APP代码而是从某些库等调用的。这显然会导致删除正在使用的键。第二种情况产生相同的效果，并且是由调用键时使用字符串插值引起的。
为了解决这个问题，我们可能会尝试启用密钥记录并让手机APP运行（最好在生产环境中）。启用此机制并运行完整的测试套件也会有很大帮助（取决于测试覆盖率）。这种通过扫描源代码增强的方法应该为我们提供几乎（如果不是全部）在手机APP中使用的完整密钥，我们可以将其与庞大的翻译文件进行比较。
用于记录翻译键的简单代码
module I18n module Registry protected def lookup(locale, key, scope = \[], options = {}) @log ||= Logger.new(File.join(Rails.root, 'log', 'i18n_registry.log')) @log.info key super end endendI18n::Backend::Simple.send :include, I18n::Registry
就像查找未使用的翻译一样，我们可以通过某种注册表来增加源代码扫描。这次我们可以将我们的解决方案基于 Rails I18n 提供的 exception_handler 钩子
I18n.exception_handler = lambda do |exception, locale, key, options| @log ||= Logger.new(File.join(Rails.root, 'log', 'missing_translations.log')) case exception when I18n::MissingTranslationData @log.info key options\[:rescue_format] == :html ? exception.html_message : exception.message end else raise exception endend
在开发过程中向翻译文件添加翻译是最没有生产力的任务之一。在使用两种或多种语言的手机APP中尤其如此。但是，使用 exception_handler 的强大功能，我们可以自动化这个密钥创建过程。
当第一次调用缺少的翻译键时，这可能会在每种语言的翻译文件中生成该键，根据键名自动创建翻译等。我们甚至可以调用一些服务，它会自动将通用翻译大致翻译成不同的语言. 实际上提供了一个 gem 允许这样做，所以不要在此处粘贴代码，而是查看它的 github 存储库。
除非团队有一些专门的翻译，否则将翻译委托给一些外部资源是很常见的，比如客户、客户的员工、外包翻译等。在所有情况下，都必须开发某种翻译过程的方法。
直接编辑文件 可能会有些尴尬且不易处理，尤其是对于不熟悉翻译文件语法的翻译人员。小的缩进变化或一些特殊的符号移除甚至会导致手机APP无法启动。这是最便宜的开始方式。
开发 专门的翻译界面 可能很诱人，但需要深思熟虑。如果外部服务不能提供例如所需的访问控制，则可能值得在内部开发一些东西。在这种情况下 ，可以使用37signals 的 Tolk 作为基础。浏览 github 以获取其他共享解决方案，以免从头开始重新发明轮子。
在大多数情况下，基于SaaS的解决方案 似乎是最好的解决方案——旨在与翻译团队合作，可以大大减少问题的数量、花费的时间并促进本地化手机APP的过程。对于翻译 rails 手机APP，目前有两个主要参与者：rails-only LocaleApp 和更通用 的 WebTranslateIt。请查看它们的功能并确定最适合您的功能。
手机APP国际化的许多方面在本文中甚至都没有涉及——它涵盖了在手机APP开发期间处理翻译的方面——然而，这是所有未来 i18n 相关任务的基础。因此，选择最适合您的方法，让您的手机APP使用另一种语言。
接入ChatGPT系统多少钱？
APP如何接入ChatGPT系
小程序开发费用，开发小程序需要
怎么选择一家靠谱的小程序制作公
app制作流程-策略|评估规划
开发一个app多少钱？
