Why ngx-translate exists if we already have built-in Angular2+ i18n ?

[chaouiy]

why should someone choose this package instead of the official i18n module ?

[SamVerschueren]

Because you don't always want to reload your entire application when someone switches the language. Angular i18n forces you to build the application per language.

[chaouiy]

As mentioned in the official documentation we have the choice between JIT/AOT compilation

[jlberrocal]

Because they aim to different purposes, for example try to change your application language with a click with the native library of angular

[ocombe]

Hello,

this is a good question, and as I am working on i18n in the Angular core team I am probably the best to answer this.

The idea behind this lib 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 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 can not change the translations)

[chaouiy]

Perfect Answser TY !

[josersleal]

So why dont you at angular call the guys from ngx and integrate ngx instead of reinventing the wheel?
Ins't that the point of open source?

[ocombe]

@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.

[josersleal]

Hi Sorry I missed that part :) Keep up the good work.. Thank you: José R. S. Leal

…

On 15 May 2017 at 14:24, Olivier Combe ***@***.***> wrote: @josersleal <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#495 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC_xuFmBomH56LAVc_V9HpBThjWzEBR4ks5r6DX7gaJpZM4MxgA4> .

[jaska45]

Olivier has done a great job. The native Angular I18N has many advantages over all 3rd party I18N libraries.

• Minimal impact to templates. You don't have to refactor all elements to use translator pipe but simply mark them with i18n attributes.
• The original string in in the template an not in resource file such as .json
• Extract tool will extract strings from templates and hopefully soon from .ts too.
• Extract tool extracts source code location and optional description and meaning. Developers can easily add comments that are essential in many cases.

Of course this approach has some limitations:

• Cannot reuse the same string on multiple places. That would be a nice new features
• Source code cannot easily use the string defined in the template. Of course code can find the DOM element and get the string from there. Would be a nice to have an easy way to refer a template string from .ts.

[aghilesh]

@ocombe : Is there any plan to add runtime language switching feature on i18n+AOT ? Right now application is planned to use ngx-translate over i18n because of the run-time switching constraint.

[ocombe]

Yes it's planned for the 5.x branch probably, not 5.0 though, we have too much on our plate for that Le mer. 2 août 2017 à 21:59, aghilesh <notifications@github.com> a écrit :

…

@ocombe <https://github.com/ocombe> : Is there any plan to add runtime language switching feature on i18n+AOT ? Right now application is planned to use ngx-translate over i18n because of the run-time switching constraint. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#495 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQMopxEs3C1QIGT2K4ezy93rJ_ss0s1ks5sUNU4gaJpZM4MxgA4> .

[imraqes]

How dificult is it to move from ngx-translate to angular i18n, I have already implemented ngx-translate so if I have to change is it too much work around ?

[jlberrocal]

is a totally different structure, however i don't see a possible reason for change ngx-translate for native i18n