Cordova/Ionic Phonegap 应用程序中的全球化/国际化

Question

我必须在 phonegap 应用中实现全球化。问题是我应该在编译应用程序之前进行翻译，还是在运行时进行翻译。

---

我可以去两个方向：

1. 第一个是使用像gulp-i18n-localize 这样的插件将源代码翻译成我想要的每种语言，然后 将每个翻译的源代码编译到不同的文件夹中 （en、sp、it 等）。然后在应用程序中调用我需要的文件夹 取决于我从navigator.language 得到的信息。
2. 第二个是创建一个服务，我每次加载组件或控制器时都会调用它，它会翻译 在呈现目标语言之前，将每个单词/短语转换为目标语言。 比如：global.trans('Save')。它也将获得 语言来自navigator.language。

---

• 这是一款应用，因此不会有大段落，只有标题、按钮、标签或消息/警报中使用的单词或小句子。
• 由于调用 api 时发送的语言参数，数据将从服务器以所需语言发出。
• 应用肯定会在未来进行一些修改，因此应该集中主要源代码，以便我们每次进行更新时都不必在不同语言的多个源中执行相同的更改。

---

是否有人已经实施了这些解决方案之一并且遇到了任何问题？或者是否考虑过其中一个可能存在的问题或认为哪个应该是最佳解决方案？您还可以考虑其他选择吗？

我看到的唯一问题是，在第一种情况下，apk 的大小会增长，因为每种语言都会有一个“站点”，每次我想添加一种语言时我都必须修改 gulpfile.js（除了词典）。在第二种情况下，它将为应用程序增加一些负载，因为它将翻译给定的每个单词/短语（翻译意思是调用服务，服务在字典（json）中搜索单词/短语/语言并返回值，尽管每个页面/屏幕没有太多要翻译的内容）。

Answer 1

我们最近经历了一个非常相似的思考过程，我们采取的步骤和最终得出的解决方案可能对您有所帮助。

TL;DR

这样做：https://www.positronx.io/angular-internationalization-i18n-with-ngx-translate-tutorial/

上下文

我们使用的是 ionic/angular/capacitor 而不是直接的 cordova，但我相信情况非常相似。

在我的场景中，我们有一个网站-SPA 和一个 Android 移动应用程序，其中包含大量共享代码，因此我们自然希望选择一种适用于两者的单一方法。

我们首先尝试了什么

我最初的思考过程与您相似，这导致我最初使用 Angular 目前支持的“构建时间”本地化方法 (https://angular.io/guide/i18n)。 这对 SPA 来说是可行的，尽管只有在添加 https://github.com/martinroob/ngx-i18nsupport 以允许随着应用程序的发展重新合并 XLIFF 文件时它才变得可行。

一个小缺点是需要设置一个兼容 XLIFF 的工具，以使实际进行翻译的效率最低。 （我们使用了https://omegat.org/）。

但是，一旦我们将相同的解决方案应用于移动应用程序，严重的缺陷就变得很明显：

1. 每个语言环境都需要一个单独的构建命令（在 angular.json/package.json 中具有相关的脚手架）。鉴于我们已经为不同的环境和场景提供了不同的构建脚本变体，随着我们添加更多的语言环境，这将导致变体的“组合爆炸”。
2. 为每个语言环境生成一个单独的 APK，这是一个完整的 PITA，很快就几乎不可能在 Google Play 上部署（请参阅here 规定的计划，以强制“App Bundles”）。
3. Capacitor 在构建时不能很好地与 Angular i18n 配合使用，如在 on this Ionic forum post 中详细描述的那样。基本上，您的构建脚本必须为每个构建破解电容器.config.json。

我们最终做了什么

鉴于以上所有情况，我们回到绘图板并尝试了不同的方法，基本上使用@ngx-translate，如in this tutorial所述。
尽管我们最初对带宽/性能有一些担忧，但观察它在实践中的工作方式，将这些放在一边：

• 每种语言的翻译都在一个单独的 JSON 文件中，该文件加载一次 - 如果应用程序要求该语言。纯文本可以很好地在线压缩。单个文件（在 SPA 场景中）的请求开销约为 400 字节。
• 我们的 SPA 由 S3 存储桶提供服务，并且使用 CDN（在我们的示例中为 CloudFront），该存储桶由边缘节点提供服务，希望非常靠近客户端设备。在 APK 场景中，语言文件已经在设备上。
• 在这两种情况下切换语言的速度都非常快，即使在新语言文件的初始加载时也几乎是瞬时的。

抛开性能不谈，还有其他好处：

• 该库利用 Angular 的 Pipe 脚手架使翻译 .html 文件中的标签的语法非常简洁
• JSON 翻译文件可使用文本编辑器进行编辑，语法非常明显，即使是非程序员也可以编辑 - 与 XLIFF 文件不同
• 只有一个 BUILD VARIANT 和一个 APK - 万岁：这个版本包含所有语言
• 编译的 APK 实际上比以前的方法要小一些，可能是因为工具更轻
• 无需在您的应用每次更改其标签时重新生成和重新合并主 XLIFF 文件。

版本信息：

"@angular/core": "^9.1.12",
"@ionic/angular": "^5.3.2"
"@ngx-translate/core": "^13.0.0",
"@ngx-translate/http-loader": "^6.0.0",

Answer 2

如果应用程序设计为也可以离线工作，那么在您的案例 1 中进行翻译肯定会更好。

1. 它将节省数据传输和加载时间，但成本仅为几 Kb；
2. 该应用可以在离线时以正确的语言传达相关信息；
3. 它将通过更快、更流畅地呈现国际化（因此，每个人都可以理解）用户界面来改善用户体验。