I am not judging, although it might appear as I am. I already mentioned a couple of features that make me think Angular is a great choice for a web framework and I’m still decided to invest my time on it. However, I failed by not evaluating it more deeply, to be fair. Anyway, we all have our flaws, don’t we?
Internationalization & Localization are critical features for any web, desktop, and mobile application, especially if they aim to a global scale of usage. That’s why I was surprised about the approach the Angular team chooses to handle this. Obviously, this is not a simple topic to manage and I’m assuming they had all the best intentions to implement i18n this way, however, we must agree that it has its downside.
When you need to build one application per language it means, consequently, that every new language that you decide to support will increase the build time. We can discuss having builds running in parallel, but the fact is that when you have multiple languages, it’s still a bottleneck. To be clear, when I’m talking about having issues with building time, I’m not considering minutes. I’m talking about taking around 4h to build a frontend application with 25+ languages.
Didn’t get the picture? Imagine that you need to roll out a hotfix to production, at least 4h the delay to have it fixed is due to the building time. Plus unit & E2E tests running time. It’s a critical issue.
Despite the fact that the i18n has better performance when compared to runtime solution, such as ngx-translate, taking too long to have it ready to deploy it’s a high cost to afford. The half-full glass of water is that the refactor efforts to move from the build-in i18n to ngx-translate are not that big, and, I’d encourage.
I hope they get it fixed in a newer Angular version and I wish I could help them to achieve this milestone. Until it doesn’t happen, ngx-translate is the way to go here.