如何在 iOS 应用程序中正确嵌入 Qt 5.15 本地化

Question

Qt 5.15 引入（至少我相信它是 5.15 的新功能）.ts 文件，以允许在应用程序中正确处理多语言环境文本。我正在从 5.X 更新 iOS Qt 应用程序，其中 X 对 .ts 文件一无所知。启动时，我收到一条警告，表明存在特定于应用程序的翻译集（这是真的），但 Qt 自己的文本没有翻译（如警告文本和对话框提示）。文档说，这些翻译位于 qtttranslations 文件夹中的 Qt5 源目录（目前通常是 /tqtc-qt5）中。这样说这个文档https://doc.qt.io/qt-5/ios-platform-notes.html#application-assets。示例仅显示应用程序特有的文本翻译，而不是 Qt 的“内置”文本。太快了，我将列出我的假设，以便可以更正或确认它们。

1. Qt 一直都有自己的嵌入文本，但 5.15 引入了一种方法来确保您的多语言环境就绪应用程序具有所有可用的正确翻译的“内置”文本。

2. 只有 app-writer 知道他们正在使用哪些模块，因此 app-writer 有责任指定将哪些翻译集添加到 app 的资源中以处理不同的语言环境。 （根据本文档 - https://doc.qt.io/qt-5/qmake-variable-reference.html#translations）

3. 根据上述两个文档，例如，如果我使用基本的 Qt 功能和 QML，并且我有一个应用程序具有一级语言支持，例如英语、德语和法语，我的应用程序似乎.pro 文件应包含类似

   TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_en.ts 
   TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_de.ts 
   TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_fr.ts 
   TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_en.ts 
   TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_de.ts 
   TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_fr.ts
   
   CONFIG += lrelease embed_translations
   

我已经跟踪调试器中的 Qt 源代码，直到它抱怨缺少翻译。它正在寻找 qt*_*.qm，其中第一个通配符是您的模块（“base”、“declarative”等），第二个是您的双字母语言代码。那么，我应该明确地将 .qm 文件作为资源添加到我的 iOS 包中，还是 TRANSLATIONS += foo_ln.ts 隐含地执行此嵌入以响应 CONFIG += lrelease embed_translations。有一件事是肯定的：现在，我对较旧的 .pro 文件的天真移植对 TRANSLATIONS 属性没有任何作用，并且 Qt 对我的包中丢失的 .qm 文件感到不安。这是一个警告，而不是严重的失败，所以我假设在紧要关头，它会提供美国英文文本，这似乎是翻译的基线，并且默认嵌入源（而不是包）中。我在上面第 3 点中对 .pro 文件的示例添加似乎足够了，还是还有更多工作要做？还是有更少的事情要做？有没有我在文档中遗漏的 .pro 指令，上面写着“使用 Qt 固有字符串的国际翻译做正确的事情”？除了列出的 .ts 文件之外，还有一个“qt_*.ts”文件集。无论我是否需要，对于那些不关心拖着一些额外字符串的懒惰人来说，这就是一切吗？最后，还有EXTRA_TRANSLATIONS，类似于TRANSLATIONS，只是它在构建过程中不经过lupdate。现在我很不清楚lupdate 相对于lrelease 的功能，但是否一个用于“库存”Qt 字符串，另一个用于特定于应用程序的翻译（因为它们可能是“更新的”由于开发过程中的变化）？语义现在对我来说没有意义，我也没有责任以“正确”的方式处理这些事情。

Answer 1

我想回答我自己的问题，因为事实证明上面的许多假设都是错误的，我需要更深入地研究源代码和调试器才能弄清楚，但现在我有了智慧。我正在阅读的文档是关于如何将原始翻译文件“（.ts 文件）”包含到使用 qmake 构建的应用程序中。与Qt 一样，使用qmake 或Qt Creator 构建可以自动解决您的大部分问题，而您只需提供执行应用程序所需的少量规范。然而，我正在开发的应用程序非常庞大、陈旧且过于复杂，因此我花了很多时间寻找最不起眼的 Qt 和 CMake 功能来拼凑这个科学怪人的应用程序怪物。我试图解决的问题只是向Qt 提供它自己的用于多语言环境应用程序的文本本地化文件。特定于应用程序的那些很好，但 Qt 对我摇摆不定并抱怨它找不到自己的。因此，事实证明 .ts 文件不适用于此类任务 - 它们只是从翻译公司以可消耗形式获取数据的管道的一部分。在Qt 自己的配置和构建过程中（是的，我们从源代码构建Qt），它处理将原始.ts 文件编译成.qm 文件，适合框架的翻译器对象使用。这些都只是坐在qtbase/translations 准备集成到应用程序安装。问题是我们（很久以前开发这个应用程序的团队，我现在正在复兴）没有处理iOS 案例。这是一个特殊情况，需要一些选择。您可以将翻译文件放入应用程序包中的特定路径，您可以自制一些奇异的 URL 解析，从而根据需要向翻译器提供 .qm 文件的内容，或者您​​可以将它们全部编译成 .qrc 文件并将它们放置在您的资源树中。最后是我们对特定于应用程序的翻译所做的，所以我为Qt 模仿了它，为我们使用的模块和我们的一级本地化目标语言中的语言环境过滤了全部.qm 文件集。这涉及到一个复杂的 python 脚本和几行额外的 Cmake，包括一个非常难以捉摸的 (QINIT_RESOURCES)，它控制了一切，直到我意识到这个平台需要它。我只是把这个总结一下，所以如果其他人很困惑找到这个问题，那么有一些通用的 cmets 可以解决问题。