Dom*_*omi 17 translation ngx-translate angular
翻译(Angular)应用程序有多种方法,主要的主要方法是:
和
到目前为止,据我所知,i18n对搜索引擎优化更容易,因为浏览网页很干净
例如
app.com/de
app.com/en
另一方面,使用ngx-translate,在语言之间切换更容易.
我知道ngx-translate的创建者是由Angular聘用的i18n. 任何人都可以说我的主要区别是什么(优点/缺点)？
小智 13
我相信这个问题可以回答你的问题:https://github.com/ngx-translate/core/issues/495
小智 11
这个问题在这一点上很旧，但我认为答案需要更新。
ngx-translate 在很大程度上已被放弃。ngx-translate 的作者 ocombe 正在 Google 努力改进内置的 Angular 方法。 他将 ngx-translate 转换为只用于维护。截至目前（2021 年 5 月），他已经 11 个月没有对 ngx-translate 进行任何维护，包括没有对 Angular 11 进行更新。
ngx-translate 对于新近国际化 Angular 的项目似乎不再可行。
我会指出这些差异，但它们是否有利弊完全取决于您的项目和开发团队的类型和规模。
| ngx-翻译 | 国际化 |
|---|---|
| 依赖绑定以便在运行时进行翻译。 | 翻译是在构建后完成的，为每种语言创建不同的应用程序。每个翻译的应用程序都将位于一个目录中（例如/pt/和/en/），这需要重定向应用程序。 |
牺牲性能，因为即使没有发生翻译，也会在每个更改检测周期中检查所有翻译的绑定。这可以通过使用变更检测策略来解决OnPush。 |
优先考虑性能。由于翻译发生在构建中，因此翻译后的字符串将被硬编码到目标模板中。 |
| 不需要重新加载翻译。 | 需要重新加载翻译，前提是翻译请求很少。 |
| 由于额外的绑定和翻译库，增加了包的大小。 | 国际化不会影响捆绑包的大小。 |
| 所有翻译字符串都必须发送给用户，即使不需要它们。但是，延迟加载的模块可以有自己的翻译文件。 | 翻译是在构建中完成的，因此客户端浏览器只能获取请求翻译所需的内容。 |
| 翻译文件非常便携、可读并且易于在开发过程中创建。它们可以随着应用程序的增长而逐渐创建，并且也可以轻松重构。 | 管理翻译文件非常复杂，因此必须定义翻译管道（观看6:35-10:15，阅读）。主要问题是每次应用程序更改时都必须从头开始翻译文件。在此过程中，只能通过慢慢复制粘贴先前翻译的字符串来重用先前的翻译。 |
| 动态翻译内容很简单，是使用该库进行翻译的最常见方法。 | 动态翻译内容很复杂。 |
动态翻译的内容（在 中非常常见ngx-translate）对于 SE 来说很难跟踪。 |
干净的 URL 浏览和静态翻译对 SEO 非常有利。 |
这些是我的主要参考资料：
我觉得这里有很多很大的权衡，真的很难选择......
请随时改进此比较！
根据@ocombe，ngx-translate库背后的想法一直是为i18n提供支持，直到Angular赶上来，此库可能会被弃用。目前，Angular i18n与该库之间仍然存在一些差异：
Angular一次只能使用一种语言，因此您必须完全重新加载应用程序才能更改lang。对JIT的支持仅意味着它可以与JIT一起使用，但是您仍必须在引导程序中提供翻译，因为它将在编译期间替换模板中的文本，而此lib使用绑定，这意味着您可以随时更改翻译。 。缺点是绑定占用内存，因此Angular方式更具性能。但是，如果您将其OnPush用于组件，则可能永远不会注意到差异
Angular目前仅支持在模板中使用i18n，我正在研究允许您在代码中使用它的功能，但这仍在进行中。该库在代码和模板中均有效
Angular支持XLIFF或XMB（均为XML格式），而该库默认情况下支持JSON，但您可以编写自己的加载器以支持所需的任何格式（例如，有一个PO文件加载器）
Angular支持ICU表达式（复数和选择），但是ngx-translate库不支持
Angular支持html占位符，包括角度代码，而该库仅支持常规html（因为它是在运行时执行的，而不是在编译过程中执行的，并且在Angular中没有像AngularJS中那样的$ compile）
ngx-translate库的API 更完整，因为它在运行时执行，它可以提供Angular所没有的更多东西（可观察到的事件...），但由于您无法更改翻译）
| 归档时间： |
|
| 查看次数： |
7661 次 |
| 最近记录： |