Part of the new Angular rendering engine, Ivy, includes a new approach to localizing applications — specifically extracting and translating text. This article explains the benefits and some of the implementation of this new approach.
新的Angular渲染引擎Ivy的一部分包括一种本地化应用程序的新方法-特别是提取和翻译文本。 本文介绍了此新方法的好处和一些实现。
Prior to Ivy, the only way to add localizable messages to an Angular application was to mark them in component templates using the i18n attribute:
在Ivy之前，向Angular应用程序添加可本地化消息的唯一方法是使用i18n属性在组件模板中标记它们：
<div i18n>Hello, World!</div>The Angular compiler would replace this text when compiling the template with different text if a set of translations was provided in the compiler configuration. The i18n tags are very powerful — they can be used in attributes as well as content; they can include complex nested ICU (International Components for Unicode) expressions; they can have metadata attached to them. See our i18n guide for more information.
如果在编译器配置中提供了一组翻译，则当用不同的文本编译模板时，Angular编译器将替换此文本。 i18n标签非常强大-它们既可以用于属性也可以用于内容； 它们可以包含复杂的嵌套ICU(Unicode国际组件)表达式 ； 他们可以附加元数据。 有关更多信息，请参见我们的《 i18n指南 》。
But there were some shortcomings to this approach.
但是这种方法有一些缺点。
The most significant concern was that translation had to happen during template compilation, which occurs right at the start of the build pipeline. The result of this is that that full build, compilation-bundling-minification-etc, had to happen for each locale that you wanted to support in your application.
最重要的问题是转换必须在模板编译期间进行，而模板编译恰好在构建管道的开始进行。 这样的结果是，必须为要在应用程序中支持的每个语言环境进行完整构建，编译-捆绑-最小化等。
(build times will vary based on project size) (构建时间将因项目规模而异)If a single build took 3 minutes, then the total build time to support 9 locales would be 3 mins x 9 locales = 27 mins.
如果单个构建花费3分钟，则支持9个语言环境的总构建时间将为3分钟x 9个语言环境= 27分钟。
Moreover, it was not possible to mark text in application code for translation, only text in component templates. This resulted in awkward workarounds where artificial components were created purely to hold text that would be translated.
此外，不可能在应用程序代码中标记文本以进行翻译，而只能在组件模板中标记文本。 这导致笨拙的变通方法，在该变通方法中，仅创建人造组件来容纳要翻译的文本。
Finally, it was not possible to load translations at runtime, which meant it was not possible for applications to be provided to an end-user who might want to provide translations of their own, without having to build the application themselves.
最后，不可能在运行时加载翻译，这意味着不可能将应用程序提供给可能希望提供自己翻译的最终用户，而无需自己构建应用程序。
The new localization approach is based around the concept of tagging strings in code with a template literal tag handler called $localize. The idea is that strings that need to be translated are “marked” using this tag:
新的本地化方法基于使用名为$localize的模板文字标签处理程序在代码中标记字符串的概念。 这个想法是使用此标记“标记”需要翻译的字符串：
const message = $localize `Hello, World!`;This $localize identifier can be a real function that can do the translation at runtime, in the browser. But, significantly, it is also a global identifier that survives minification. This means it can act simply as a marker in the code that a static post-processing tool can use to replace the original text with translated text before the code is deployed. For example, the following code:
这个$localize标识符可以是一个真正的函数，可以在运行时在浏览器中进行翻译。 但是，重要的是，它还是一个可以幸免的全局标识符。 这意味着它可以简单地充当代码中的标记，静态的后处理工具可以在部署代码之前使用静态后处理工具用翻译后的文本替换原始文本。 例如，以下代码：
warning = $localize `${this.process} is not right`;could be replace with:
可以替换为：
warning = "" + this.process + ", ce n'est pas bon.";The result is that all references to $localize are removed, and there is zero runtime cost to rendering the translated text.
结果是将删除所有对$localize引用，并且呈现翻译后的文本的运行时成本为零 。
The Angular template compiler, for Ivy, has been redesigned to generate $localize tagged strings rather than doing the translation itself. For example the following template:
用于Ivy的Angular模板编译器已经过重新设计，以生成$localize标记的字符串，而不是自己进行翻译。 例如以下模板：
<h1 i18n>Hello, World!</h1>would be compiled to something like:
将被编译为类似以下内容：
ɵɵelementStart(0, "h1"); // <h1>ɵɵi18n(1, $localize`Hello, World!`); // Hello, World!ɵɵelementEnd(); // </h1>This means that after the Angular compiler has completed its work all the template text marked with i18n attributes have been converted to $localize tagged strings which can be processed just like any other tagged string.
这意味着在Angular编译器完成其工作之后，所有标记有i18n属性的模板文本都将转换为$localize标记字符串，可以像处理其他任何标记字符串一样对其进行处理。
Notice also that the $localize tagged strings can occur in any code (user code or generated from templates in both applications or libraries) and are not affected by minification, so while the post-processing tool might receive code that looks like this
还要注意， $localize标记的字符串可以出现在任何代码中(用户代码或从应用程序或库中的模板生成)，并且不受缩小的影响，因此，尽管后处理工具可能会收到如下所示的代码
...var El,kl=n("Hfs6"),Sl=n.n(kl);El=$localize`Hello, World!`;let Cl=(()=>{class e{constructor(e)...it is still able to identify and translate the tagged message. The result is that we can reorder the build pipeline to do translation at the very end of the process, resulting in a considerable build time improvement.
它仍然能够识别和翻译带标签的消息。 结果是，我们可以在流程的最后对构建管道进行重新排序以进行翻译，从而显着缩短了构建时间。
(build times will vary based on project size) (构建时间将因项目规模而异)Here you can see that the build time is still 3 minutes, but since the translation is done as a post-processing step, we only incur that build cost once. Also the post-processing of the translations is very fast since the tool only has to parse the code for $localize tagged strings. In this case around 5 seconds.
在这里，您可以看到构建时间仍然是3分钟，但是由于翻译是作为后处理步骤完成的，因此我们只需支付一次构建费用。 而且翻译的后处理非常快，因为该工具仅需解析$localize标记字符串的代码即可。 在这种情况下，大约5秒钟。
The result is that the total build time for 9 locales is now 3 minutes + ( 9 x 5 seconds) = 3 minutes 45 seconds. Compared to 27 minutes for the pre-Ivy translated builds.
结果是，现在9个语言环境的总构建时间为3分钟+(9 x 5秒)= 3分45秒。 相比之下，常春藤翻译版本需要27分钟。
Similar improvements have been seen in real life by teams already using this approach:
已经在使用这种方法的团队在现实生活中看到了类似的改进：
The post-processing of translations is already built into the Angular CLI and if you have configured your projects according to our i18n guide you should already be benefitting from these faster build times.
翻译的后处理已内置在Angular CLI中，如果您已经按照我们的i18n指南配置了项目，则应该已经受益于这些更快的构建时间。
Currently the use of $localize in application code is not yet publicly supported or documented. We will be working on making this fully supported in the coming months. It requires new message extraction tooling — the current (pre-Ivy) message extractor does not find $localize text in application code. This is being integrated into the CLI now and should be released as part of 10.1.0.
当前，尚未公开支持或记录在应用程序代码中使用$localize 。 在接下来的几个月中，我们将努力使它得到完全支持。 它需要新的消息提取工具-当前(常春藤)消息提取器在应用程序代码中找不到$localize文本。 现在已将其集成到CLI中，应作为10.1.0的一部分发布。
We are also looking into how we can better support translations in 3rd party libraries using this new approach. Since this would affect the Angular Package Format (APF) we expect to run a Request for Comment (RFC) before implementing that.
我们还在研究如何使用这种新方法更好地支持第三方库中的翻译。 由于这会影响Angular封装格式(APF)，因此我们希望在实施该请求之前先运行一个注释请求(RFC)。
In the meantime, enjoy the improved build times and keep an eye out for full support of application level localization of text.
同时，享受改进的构建时间，并密切注意对文本的应用程序级别本地化的全面支持。
翻译自: https://blog.angular.io/angular-localization-with-ivy-4d8becefb6aa
相关资源：四史答题软件安装包exe