问题描述
Some years ago 我使用 @ngx-translate 处理我的 Angular 应用程序中的字符串替换。
现在我需要对我的应用程序进行国际化，尽管 @ngx-translate 似乎仍然是更好的选择，但我愿意*给 Angular i18n 内置功能。
我已阅读 Angular i18n documentation 并且拥有应用程序的翻译版本似乎非常简单（尽管使用的是 XML 而不是 JSON！）。
如文档所述：
由于 i18n 的部署复杂性和最小化重建时间的需要，开发服务器一次只支持本地化一个语言环境
此外，我必须为每种语言构建不同的应用程序，这导致应用程序重复：
ng build --configuration=production,fr
ng build --configuration=production,es
ng build --configuration=production,it
ng build --configuration=production,de
我说得对吗？我们不应该只有一个应用程序和与在运行时加载的语言一样多的“message.xlf”文件（或类似的东西）吗？
*我在某处读到 ngx-translate 的维护者认为，一旦 Angular “赶上”，他的解决方案就会被弃用。事实上，他被 Angular 团队聘用从事 I18n 模块的工作；他指出，内置解决方案要复杂得多，而且没有错误。所以，虽然ngx-translate还在被广泛使用，但也许我们迟早应该考虑转移到内置模块。
解决方法
你说得对，是的...
使用 Angular 的 i18n 机制需要您为每个区域设置单独构建。
作为补充，我想补充一点，Netanel Basal（以及其他一些开发人员）已经（更现代？）替代了 ngx-translate（称为 transloco）——它可以在这里找到：{{ 3}}