There are multiple methode to translate an (Angular) app, the big main methodes are :
and
As far I understood i18n is easier for SEO because of the clean url browsing with
e.g
app.com/de
app.com/en
on the other hand with ngx-translate it is easier to switch between languages.
I know that the creator of ngx-translate was hired by Angular for their i18n. Can anybody say me what the main differences are (pro/cons)?
I believe that this issue answers your question: https://github.com/ngx-translate/core/issues/495
This question is old at this point, but I think the answer is in need of an update.
ngx-translate has been largely abandoned. The author of ngx-translate, ocombe, is hard at work at Google to improve the built in Angular method. He transitioned ngx-translate to maintenance only. As of this date (May 2021), he has not done any maintenance on ngx-translate for 11 months including no update for Angular 11.
ngx-translate no longer appears viable for projects newly internationalizing Angular.
ngx-translate is still widely used, and hasn't become obsolete; it just became stable in most of the existing features. And regarding updates, there have been maintenance releases (for Angular version compatibility) since this answer was posted –
Ardeliaardelis I believe that this issue answers your question: https://github.com/ngx-translate/core/issues/495
According to @ocombe, The idea behind ngx-translate library has always been to provide support for i18n until Angular catches up, after that this lib will probably be deprecated. For now, there are still a few differences between Angular i18n and this library:
Angular only works with one language at a time, you have to completely reload the application to change the lang. The JIT support only means that it works with JIT, but you still have to provide the translations at bootstrap because it will replace the text in your templates during the compilation whereas this lib uses bindings, which means that you can change the translations at any time. The downside is that bindings take memory, so the Angular way is more performant. But if you use OnPush for your components you will probably never notice the difference
Angular only supports using i18n in your templates for now, I'm working on the feature that will allow you to use it in your code, but it's still a work in progress. This lib works both in code and templates
Angular supports either XLIFF or XMB (both are XML formats), whereas this lib supports JSON by default but you can write your own loader to support any format that you want (there's a loader for PO files for example)
Angular supports ICU expressions (plurals and select), but ngx-translate library doesn't
Angular supports html placeholders including angular code, whereas this library only supports regular html (because it's executed at runtime, and not during compilation, and there is no $compile in Angular like there was in AngularJS)
The API of ngx-translate library is more complete because it is executed at runtime it can offer more things (observables, events, ...) which Angular doesn't have (but doesn't really need given that you can not change the translations)
I'll point out the differences, but whether they are pros and cons totally depends on the type and scale of your project and developer team.
| ngx-translate | i18n |
|---|---|
| Relies on bindings in order to translate at runtime. | The translation is done after build, creating a different application for each language. Each of the translated apps will be in a directory (for example /pt/ and /en/), this requires a redirectioning app. |
Sacrifices performance because all translated bindings will be checked in every change detection cycle, even if translation doesn't happen. This can be worked around by using the OnPush change detection strategy. |
Prioritizes performance. Since the translation happens in build, the translated strings will be hard-coded into the target templates. |
| Does not require reloading for translation. | Requires reloading for translation, on the premise that translation requests are rare. |
| Increases bundle size due to the additional bindings and the translation library. | Internationalization doesn't affect the bundle size. |
| All translation strings have to be shipped to the user, even if they aren't needed. However, lazy-loaded modules can have their own translation files. | Translations are done in build, so the client browser only gets what is necessary for the requested translation. |
| Translation files are very portable, readable and easy to create during development. They can be created gradually as the application grows, and also easily refactored. | Managing translation files is so complex that a translation pipeline has to be defined (watch 6:35-10:15, read). The main problem is that the translation files have to be done from scratch every time that the app is changed. In this process, previous translations can only be reused by slowly copy-pasting the previously translated strings. |
| Translating contents dynamically is trivial, being the most common approach to translation with this library. | Translating contents dynamically is complex. |
Dynamically translated contents (which are extremely frequent with ngx-translate) are hard to track for SE's. |
The clean URL browsing and static translations strongly benefit SEO. |
These were my main references:
I feel like there are so many big trade-offs here that it's really hard to choose...
Please feel free to improve this comparison!
There is a quite complete comparison between Transloco, Angular-I18n and Ngx-translate in Transloco docs:
© 2022 - 2024 — McMap. All rights reserved.
angularjstag from your question. – Inesinescapable