#Which one is good- ngx-translate vs angular i18n
7 messages · Page 1 of 1 (latest)
No idea about ngx-translate, but angular i18n is compile-time translation.
We use it at work, it works alright, but the concept of compile-time translation is somewhat meh in my book.
They mean that you need to build your clients as many times as you have locales. And you need to do that every time you release something
Ergonomically I believe I'd prefer runtime translations like i18next does them. Though performance wise, compile-time translations are better, though I do not know by how much
Main question: what is needed? Compile-time translation or runtime? If you need compile-time, use Angular i18n. If runtime - there are plenty libs for it (ngx-translate, transloco, you name it)
Transloco ftw 😉
Angular i18n would be good, but manually copying the source language file for each locale and the lack of a built-in way to add or remove translations from existing files results in a very poor experience
TBH the way it works for us is that we had an existing translation system and UI for our translators already and we just wrote a service that uploads the translation files to that system and adds the keys that don't exist yet to the system.
And when you need to localize during build-time we generate a translation file via those keys in the service and download it to the client, all via cli.
So yeah, it only really works for us because we added it into our own tech-stack for translations.
With https://previsto.com we use Angular’s i18n - for website, webapp, libraries and hybrid mobile apps. Translations are maintained using poedit which is an awesome free tool that supports xlf.
Tooling was hard to get right for some parts, but when it is set up the experience is awesome. Having the ability to use Angulars native i18n to maintain the source message file is crucial IMO.
One of the biggest hurdles was the extra build for every translation as we went along. It did not fit into PWA’s or mobile Capacitor apps. We ended up with a solution where we compile our xlf’s to json and load those runtime (angular i18n supports that).
So in short we use Angular i18n with runtime translations for webapp and mobile app. For website we still use compile time translations.