New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
amineparis opened this Issue Apr 3, 2017 · 65 comments

Comments

Projects
None yet
@amineparis

amineparis commented Apr 3, 2017

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

@SamVerschueren

This comment has been minimized.

Collaborator

SamVerschueren commented Apr 3, 2017

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.

@amineparis

This comment has been minimized.

amineparis commented Apr 3, 2017

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

@jlberrocal

This comment has been minimized.

Contributor

jlberrocal commented Apr 3, 2017

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

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Apr 3, 2017

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)
@amineparis

This comment has been minimized.

amineparis commented Apr 3, 2017

Perfect Answser TY !

@amineparis amineparis closed this Apr 3, 2017

@josersleal

This comment has been minimized.

josersleal commented May 15, 2017

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

This comment has been minimized.

Collaborator

ocombe commented May 15, 2017

@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

This comment has been minimized.

josersleal commented May 15, 2017

@jaska45

This comment has been minimized.

jaska45 commented Aug 1, 2017

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

This comment has been minimized.

aghilesh commented Aug 2, 2017

@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

This comment has been minimized.

Collaborator

ocombe commented Aug 9, 2017

@imraqes

This comment has been minimized.

imraqes commented Aug 16, 2017

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

This comment has been minimized.

Contributor

jlberrocal commented Aug 16, 2017

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

@neridonk

This comment has been minimized.

neridonk commented Aug 29, 2017

Does anyone know when this : 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.

will happen?

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Aug 29, 2017

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

@Derekjohnson277

This comment has been minimized.

Derekjohnson277 commented Sep 20, 2017

@ocombe My application is currently using this library to do the translations, would you recommend switching to the angular i18n to not run into future problems? Would it be worth the time to switch over?

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Sep 21, 2017

if you can (meaning if you don't need translations in the code), it's definitively worth it yes

@Derekjohnson277

This comment has been minimized.

Derekjohnson277 commented Sep 21, 2017

Good to know @ocombe , thanks!

@jasonever

This comment has been minimized.

jasonever commented Jan 19, 2018

@ocombe

I need your advice , i'm building a chat application (Web and Mobile app) .. So i'm confused about going ahead with using Angular i18n or Ng-Translator ? especially i saw your comment in github before that in March2018 Angular will release an edition that i18n has more features like dynamic load feature same like NG-Translator ..so i will be able to switch to another language without reloading the app (in realtime) is this correct or what ? i need your advice .. Thanks :)

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Jan 20, 2018

The way it's going, you'll never be able to dynamically change the language in Angular. It's clearly not a priority for Google and they don't think it's a problem if you have to reload the app completely to change the locale.

@denizengin

This comment has been minimized.

denizengin commented Jan 24, 2018

@ocombe How about being able to do translations in code, is that likely to arrive soon to Angular i18n?

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Jan 24, 2018

Yes that's coming soon, we are adding runtime i18n in v6.0 and then code translations right after that (or maybe at the same time)

@beachjf

This comment has been minimized.

beachjf commented Feb 4, 2018

The main problem with the fact that every language has their own app is it's really difficult to make the app share the same session. I'm actually facing this issue with angular 5 app combinnr with identify server

@ibagaric

This comment has been minimized.

ibagaric commented Feb 5, 2018

@ocombe I am in the moment where i need to decide, should I use Angular i18n or ngx-translate.
In the future, will Angular i18n have possibility to export translates to JSON or PO file.
Is there any easy way to read XLIFF or XMB format with some GUI so it can be easily given to translators.
What lib to use, what is your advice? Thanks in advance!

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Feb 5, 2018

In the future, will Angular i18n have possibility to export translates to JSON or PO file.

yes, I'm lobbying hard to get this, and we'll have it one way or another (either we support it ourselves, or we open the API and I'll make a lib for it)

Is there any easy way to read XLIFF or XMB format with some GUI so it can be easily given to translators.

there are a lot of websites for translators that you can use, some of them have a free tiers
some good ones include:

  • poeditor (claims to supports angular)
  • crowdin (free for open source)
  • oneskyapp (unlimited free tiers as long as you translate yourself)

What lib to use, what is your advice? Thanks in advance!

if you can use the official implementation, then use that, it's more performant, the limitation is that it's limited to what is offered whereas with ngx translate you can always extend it via plugins, or even fork it if necessary

@jaska45

This comment has been minimized.

jaska45 commented Feb 6, 2018

Please do not add any new formats! You already have three: XMB, XLIFF 1.2 and XLIFF 2.0. Most other platforms have only one :-)

Almost all online translation services claim to support XLIFF. The reality is that XLIFF is very complex format and Angular's extract tool can create pretty complex XLIFF. Especially if you have plurals, genders, links or inline formatting elements. In addition Angular XLIFF files contain many proprietary properties such as meaning and location. What I have noticed is that a generic XLIFF parser/scanner cannot properly handle Angular's resource files. This is why it is better that the localization tool uses a dedicated Angular parser that can property handle the resource files.

But this is perfectly fine. The main task of a localization tools is to scan the source files and in that process extract all information that is needed. I am glad that Angular resources contain all the information needed to fully extract strings and enable continuous localization where translation and development can work independently to each other.

@milanc

This comment has been minimized.

milanc commented Apr 9, 2018

That sounds good, I hope that will come soon.
Thank you.

@ndr508

This comment has been minimized.

ndr508 commented Apr 22, 2018

I am working on a project where we have to set up the infrastructure to support internalization on front end. There is no immediate current need to support multiple languages at this time. However, when needed we would like to have the current design support this. The idea is to implement the internalization for English language currently. I am looking at both Angular i18n and ngx-translate features. As it seems from the above discussion threads, even though Angular i18n is lacking some features currently compared to ngx-translate, those would be eventually be added to Angular i18n, correct?

Can you please suggest whether it is good to with ngx-translate or Angular i18n?

Thank you!

@SoftwareDevFromLA

This comment has been minimized.

SoftwareDevFromLA commented May 8, 2018

@ocombe - My question is in regards to: add runtime language switching feature on i18n - I noticed that you mentioned it's planned for the 5.x branch, but looking through the i18n doc I dont see anything that references it. Can you please tell me if its implemented and also point me to some sample working code?

@ocombe

This comment has been minimized.

Collaborator

ocombe commented May 8, 2018

It's been postponed twice already. It's scheduled for v7 now, we needed the new renderer (ivy) to make it possible.

@RezaRahmati

This comment has been minimized.

RezaRahmati commented Jun 12, 2018

@ocombe - great work, is this feature 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. scheduled for v7 or it's available on v6, also if there is a simple example how it will be?

@shabinpshams

This comment has been minimized.

shabinpshams commented Jul 19, 2018

@ocombe - I am working on an application which has both web and mobile. Developing application using Angular 5 with i18n. I also wanted to use the same code base to Ionic application and i couldn't find any support on ionic framework for i18n.
Please help me to solve this issue.

@lizzymendivil

This comment has been minimized.

lizzymendivil commented Sep 19, 2018

Hi there!
19 September, 2018
what is the status for i18n Angular please?
I need to internationalize my app, need to decide between ngx-translate and i18n built-in tool

@ocombe
(using angular 6)

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Sep 20, 2018

If you need it now go for ngx translate. Ivy won't be stable until next year probably.

@lizzymendivil

This comment has been minimized.

lizzymendivil commented Sep 20, 2018

Thanks @ocombe so ngx translate won't be deprecated soon, right?

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Sep 20, 2018

no

@Diemauerdk

This comment has been minimized.

Diemauerdk commented Sep 25, 2018

Hi @ocombe

Using Angular 6 i18n - do you know if it is possible to get the translation text using typescript? for example using an id?

From the documentation(https://angular.io/guide/i18n) it seems only to be possible in a template.

Thanks

@Derekjohnson277

This comment has been minimized.

Derekjohnson277 commented Sep 25, 2018

@Diemauerdk if you need to get the translation in your component, just import the TranslateService and assign it in your constructor. Then you can use this.translateService.instant('[insert translation string]') to get the translated string.

@Diemauerdk

This comment has been minimized.

Diemauerdk commented Sep 25, 2018

Hi @Derekjohnson277

Thanks for the reply - cant' find that TranslationService. In what package/module does it come from?

@Derekjohnson277

This comment has been minimized.

Derekjohnson277 commented Sep 25, 2018

import { TranslateService } from '@ngx-translate/core';

@Diemauerdk

This comment has been minimized.

Diemauerdk commented Sep 25, 2018

@Derekjohnson277 but my question was how to do it using Angular 6 i18n (https://angular.io/guide/i18n) and not ngx-translate :)

@Derekjohnson277

This comment has been minimized.

Derekjohnson277 commented Sep 25, 2018

Ah haha my bad, from what I have read in the past Angular i18n doesn't support translations outside of the template, but maybe it has been upgraded to add that feature. The reason I still use ngx-translate is for in component translations.

@Diemauerdk

This comment has been minimized.

Diemauerdk commented Sep 25, 2018

@Derekjohnson277 , Thats fine :D

@lizzymendivil

This comment has been minimized.

lizzymendivil commented Sep 25, 2018

@Derekjohnson277 yeah, I think the same as you... ngx-translate looks better than Angular i18n
I really don't like the idea of deploy my app for every language and I prefer json format.

@Diemauerdk

This comment has been minimized.

Diemauerdk commented Sep 26, 2018

@lizzymendivil Yes at the moment it does look a lot better. But I am to build a large future proof solution so i cannot base it on something that's going to be deprecated.

@lizzymendivil

This comment has been minimized.

lizzymendivil commented Sep 28, 2018

@Diemauerdk ok, but angular i18n looks unstable because ng serve --aot --locale es is not working anymore, I got this error: Unknown option: '--locale' So, now it is working differently, things are changing.

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Sep 28, 2018

@CherryCoder91

This comment has been minimized.

CherryCoder91 commented Oct 18, 2018

I noticed Ivy is now at 92.47% completion with 11 items pending 3 of which are I18N: translate text literals, rearrange text nodes and ICU.

I am trying to understand the following:

  1. Will I18N be compatible with AOT in angular with Ivy?
  2. Will Ivy support real-time text translations when changing language on the fly (i.e. will ivy bake the translations for all languages into the compilation and bind the text literals?)
  3. Is there a documented / preferred strategy for serving the different compilations of the site based off user/account preference at the moment while there are different compilations per langauge?
  4. When are we likely to see the I18N work completed? Is this now a high priority given it is one of the few remaining major items for Ivy?

Any input on the above would be massively appreciated I am on a huge localisation epic at work with a lot of product managers hammering me!

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Oct 18, 2018

1/ Of course yes
2/ No, changing the language will require to reload the app, for now and the foreseeable future
3/ I don't understand the question
4/ Yes, and yes it's high priority, we've found a replacement for Victor who left the team last summer, and we now have someone working 100% on the compiler part of i18n. I work 100% on the runtime part, and misko is helping us both with the design.

@CherryCoder91

This comment has been minimized.

CherryCoder91 commented Oct 18, 2018

@ocombe Thanks for the super quick reply 👍

Sorry to be confusing for 3/ let me re-word:

My current understanding is that when we compile the app in a specific locale it finds and replaces the strings in the compiled templates during compile time (AOT). This results in a deploy-able version of the site per locale. This is great for optimisation of the size of the app bundle but adds challenges in deployment of the site. In our app we would like the user to store their preferred locale as a setting within the app and then have that locale served out while still accessing the same site domain. i.e app.mycompany.com could return the app in French / German / Spanish / etc based of the users preference. But given the app would have to load to first fetch that information I was wondering if the Angular community has a preferred / documented method for achieving this this as I don't have any previous experience in it? Does Angular have a mechanism for this or would we need to use some server side tech / force the user to use a different domain i.e. de.companyname.com, fr.companyname.com etc.

Sorry if I am asking about something with an obvious answer, just completely inexperienced in this area and want to make sure I am following best practices if we stick with the angular I18N.

@ocombe

This comment has been minimized.

Collaborator

ocombe commented Oct 19, 2018

For now this is how it works yes, it replaces the strings in the compiled templates.
With runtime i18n (in ivy) you'll load the translations at runtime, which means one bundle for all languages, and you can apply the language that you want when you load the app (but you'll have to reload the app to change the language, because once the templates have been compiled with one language, they are cached). This means that you could potentially apply some logic at runtime to load the language file that you want, as long as it runs before any template is compiled. For performance reasons it would be better to have the language files pre-loaded, otherwise you'll see a blank page until it's loaded.

I don't know what's the best method to load the files right now, but I'd say that you should probably do some server-side detection based on either browser language / cookies / user preferences in the database / sub-domain / specific url pattern, and then serve the correct file.
All of that can work server side with nginx rules (or equivalent, like node express, ..., depending on what you use).
You can find an example of an nginx file here: https://github.com/skeletons-projects/angular/blob/master/config/nginx.conf

@CherryCoder91

This comment has been minimized.

CherryCoder91 commented Oct 19, 2018

Thank you :)

The work you guys are doing for the community is awesome. we all appreciate it :)

@tatsujb

This comment has been minimized.

tatsujb commented Nov 5, 2018

The way it's going, you'll never be able to dynamically change the language in Angular. It's clearly not a priority for Google and they don't think it's a problem if you have to reload the app completely to change the locale.

they have a screw loose then... :/

@PowerKiKi PowerKiKi referenced this issue Nov 10, 2018

Open

[i18n] plans #16477

0 of 20 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment