Angular 5 internationalization

Yes. ngx-translate is good till now, and I hope it will be in future as well.

I am using ngx-translate in my current Angular 5 project with 5+ languages.

It is working fine for me so far. I did not have to make any custom changes, it worked like plug and play thing.

I used this plugin https://github.com/ngx-translate/core

After spending time looking into this, I thought I'd post the main differences I found between ngx-translate and Angular-i18n:

• 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). Personally, Json files are quite straight forward to read through rather than these other formats, but that’s not a huge drawback.
• Angular supports ICU expressions (plurals and select), but this 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 this 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 cannot change the translations) The creator of ngx-translate has said this:

Ocombe (developer of ngx): @josersleal that's exactly what they did, the angular team hired me to improve i18n for everyone But there is no way to integrate my lib directly into the core, after working for 3 months for the core team I can tell you that Angular i18n is much more complex and elaborate than my lib. It handles a lot of more complex stuff, and it does it without all the bugs and shortcomings that my lib has. I understand that it's frustrating that the core doesn't evolve as fast as what a library can do, but there are reasons for that, and the first one is that you cannot implement something and change it whenever you see that you forgot to include a use case. Everything has to be thoroughly planned and thought. Still, you will have most of the things that this lib can do in the core in the future, but it might take a year before we get there unfortunately. The good news is that it's going to be much better than my naive implementation.

This is a good article to discuss the main differences between ngx-translate and Angular’s i18n: https://github.com/ngx-translate/core/issues/495

The changes for i18n are due in version 6 of angular. Today, we are currently on version 5:

• It won't be for 5.0, it should be before 6.0 (so before march 2018). Unfortunately I don't have a more precise date

• The developer of ngx-translate (and now a main contributor to angular-i18n) has posted this 12 days ago: https://github.com/angular/angular/issues/20193

• Here’s the design document for i18n (the Prior Art section is interesting): https://docs.google.com/document/d/1LH7lJ1GjRgpGUjzNb6Eg4xrPooRdi80QOTYYh8z_JyY/edit#

Some thoughts…

• Angular-i18n is more performant as you compile your application in the language you require (rather than translations happening at runtime). Can also be a drawback as you may need to have multiple builds of your application in different languages.
• If we were using SEO, angular-i18n would be the way forward, due to url browsing. For my case, I don’t need this at all.
• If we required plural switching etc. Again, I don’t need this – I just need a fairly straight forward runtime language switch in templates and code.
• Angular-i18n wont be released until March 2018 at least. For me I cant wait until then as I need to build my app now.
• ngx-translate won’t have as comprehensive a set of capabilities as angular-i18n BUT again, I only need simple runtime translations, so think its fine for what we need.
• ngx-translate is open source and come the day it’s no longer being developed, if there's a serious issue I guess I could fix myself (hopefully by the time that comes, any issues that may arise will be ironed out).

I am also going to have a look at the Angular-l10n library as it looks very good:

• Angular-l10n - https://github.com/robisim74/angular-l10n