几年前，我使用@ngx-translate在我的 Angular 应用程序中处理字符串替换。
现在我需要国际化我的应用程序，尽管@ngx-translate 似乎仍然是更好的选择，但我会给 Angular i18n 内置功能一个机会*。
我已经阅读了Angular i18n 文档，并且拥有应用程序的翻译版本似乎非常简单（尽管使用 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 还在被广泛使用，但也许我们迟早要考虑转移到内置模块。