国际化

国际化是一个复杂的问题。Qwik 并没有直接解决国际化问题，而是提供了低级别的 API，以便让其他库来解决。

运行时翻译 vs 编译时翻译

从高层次来看，翻译问题可以通过两种方式解决：

• 运行时：在运行时加载翻译映射，并查找翻译结果。
• 编译时：在编译过程中将翻译嵌入到输出字符串中。

以上两种方法都有各自的权衡。

运行时方法的优点是：

• 简单。不需要额外的构建步骤。

运行时方法的缺点是：

• 每个字符串都会出现三次：
  1. 作为代码中的原始字符串。
  2. 作为翻译映射中的键。
  3. 作为翻译映射中的翻译值。
• 工具无法将翻译映射拆分，因此整个翻译映射必须在应用启动时被急切加载。这是一个问题，因为它会撤销 Qwik 在拆分和延迟加载代码库方面所做的努力。此外，由于翻译映射没有被拆分，浏览器将下载不必要的翻译内容。例如，对于在客户端上永远不会重新渲染的静态组件的翻译。
• 翻译查找会带来运行时开销。

编译时方法的优点是：

• Qwik 的代码延迟加载现在也扩展到了翻译字符串的延迟加载。（不会加载不必要的翻译文本）
• 没有运行时翻译映射，意味着字符串不会出现三次。

编译时方法的缺点是：

• 需要额外的构建步骤。
• 切换语言需要重新加载页面。

推荐方案

考虑到上述情况，Qwik 建议您使用最适合您约束条件的工具。为了帮助您做出决策，有三个不同的考虑因素：浏览器、服务器和开发。

浏览器

Qwik 的目标是提供最佳的用户体验。为了实现这一目标，它将代码的加载推迟到后面，以便初始启动性能不会受到过大的影响。由于运行时方法需要急切加载所有翻译内容，我们不推荐使用这种方法。我们认为编译时方法对于浏览器来说是最好的选择。

服务器

服务器没有延迟加载的约束。因此，服务器可以使用运行时或编译时方法。编译时方法在服务器上的缺点是，我们需要为每种语言单独部署。这会增加部署过程的复杂性，并对服务器数量提出更高的要求。因此，我们认为在服务器上使用运行时方法更可取。

开发

在开发过程中，较少的构建步骤将导致更快的反馈。因此，运行时翻译应该会带来更简单的开发工作流程。

我们的建议

我们建议在服务器上使用一个提供运行时方法的工具，并根据是否处于开发或生产环境，在客户端上使用运行时或编译时方法。这样可以提供最佳的用户体验和开发体验，并使用最少的服务器资源。

国际化库

$localize

$localize 是基于 Angular 的 $localize 系统的翻译系统。翻译可以以 xmb、xlf、xlif、xliff、xlf2、xlif2、xliff2 和 json 格式提取。

注意：$localize 系统是一个编译时翻译系统，并且完全从最终输出中删除。$localize 是 Angular 的一个子项目，包括其使用并不意味着 Angular 用于应用程序的渲染。

将 $localize 添加到 Qwik 的最简单方法是使用 pnpm qwik add localize 命令。这将安装所需的依赖项，并创建一个新的公共路由 /src/routes/[locale]，展示了 i18n $localize 的集成。

npm run qwik add localize

更多参考，请查看这个 示例仓库。

使用 deepl 为 $localize 自动翻译

对于自动翻译，您可以使用 deepl-localize 包。它将使用 deepl.com API 自动翻译您的字符串。

使用 deepl-localize 命令使用 npx 来翻译您的字符串：

npx deepl-localize translate -b src/locales/message-en.json -l de-DE fr-FR -a "YOUR-DEEPL-API-KEY"

或者，您可以在脚本部分使用 deepl-localize 命令来翻译您的字符串：

{
  "scripts":{
    "translate":"deepl-localize translate -b src/locales/message-en.json -l de-DE fr-FR -a 'your-deepl-api-key'"
  }
}

qwik-speak

qwik-speak 是一个用于在 Qwik 应用中翻译文本、日期和数字的库。

将 qwik-speak 添加到 Qwik 的最简单方法是按照官方的 指南 进行操作。