Discussion: future of the library

ocombe commented 6 years ago

Hello everyone, I'd like to discuss about the future of this library and get your opinion on my plans.

(Long) history

You can skip that part if you don't care about how this library came to life

When I started this library 3 years ago, I wanted to learn Angular and I thought that working on an open source project would be the best way to do that. It had worked for me on AngularJS with my library ocLazyLoad that was a huge success (2600 stars) and whose core principles were finally integrated into the framework in v1.6.7.

At the time I was looking for a way to translate my Angular apps and found out that there was nothing in Angular to do that (i18n wasn't even existing in the framework). I asked my good friend Pascal Precht if he was interested in porting angular-translate from AngularJS to Angular but he wasn't and told me that I should do it.

My library quickly became popular for various reasons (no real alternative, I had a good reputation from my work on ocLazyLoad, my appearances in Angular Air and my talks at conferences). And I guess that the code was good enough and easy to start with. It was also a time where the framework was still in beta, and there were no real guidelines for publishing libraries for Angular, it was so hard to do it that not a lot of people were trying and I didn't have any real competition on i18n for a long time.

Some time later, the library ecosystem started to settle and Angular was stable, they decided to drop the name Angular 2/4/... in favor of just "Angular". I decided to rename this library ngx-translate and to use npm scopes in order to deliver a modular experience. I rewrote the whole library and made it possible to replace some parts (loader, parser, compiler, ...). It was still a side project for me, but I was using it at work because we had finally started using Angular in production and needed to translate the app in multiple locales.

The official i18n implementation was super complicated (and still is), it didn't support json, code translation, changing the locale without reloading the app, and you needed multiple app bundles (one per locale). My library was so popular that I wanted to work on it full time because I could see that it was a necessity for the Angular community. It solved a lot of use cases, and was simple enough to be usable in a few minutes.

I decided to quit my job and see if I could make a living out my open source work. I knew that it was possible because ag-grid had done it and they were very successful. It was in December 2016, I had 2 months left at work before I was free, and I went to the conference NG-BE where Igor Minar from the core team was present. I wanted to ask him some advices on how to turn this into a profitable OSS project, but before I could tell him about my plans, he told me: "Ah Olivier, I wanted to talk to you, you've got to stop working on your library [ngx-translate], Companies come to us and want to do i18n, but they only talk about your library, we want them to use our solution [Angular i18n] because it's more efficient".

I was a bit speechless, I was there about to tell him that I had quit my job and wanted to work full time on my lib, and he was asking me to stop working on it. So I did what anyone with a bit of common sense would have done, I told him that Angular i18n sucked, that it failed to deliver the promise of easy-to-use-yet-powerful that they wanted Angular to be. I probably didn't use those words, but he agreed with me that it still needed some work, but they didn't have enough resources to work on it (Victor Savkin and Jeff Cross had just left the team to create Nrwl). I jumped on the occasion and told him that I would love to work with them to improve Angular i18n. He told me that he would consider it, and we left it at that.

A few weeks later, and recontacted me, and told me that they were ok to hire me as a contractor to work on i18n. It was like Christmas for me (actually it was around Christmas, so that might explain it) because working for Google is a once in a lifetime opportunity and a dream job. But working on open source, from home, for Angular, it was even better and I didn't even thought that it was possible for me to do that.

I joined the team in February 2017 (almost a year ago), and started working on i18n. There was a lot of work to do, but I was confident that I could make a difference. It was clear to me at the time that it would take a few months to make i18n easier to use for everyone, with the features that people wanted, and that I could deprecate my library after that.

It turns out that working on a framework like Angular is super complicated. The codebase is huge, not highly documented, with a lot of different packages. The development process is complicated (it doesn't even work on Windows yet), and whenever you make a change you have to be extra careful not to break anyone. We even write tests, like a lot of tests! It was a big shift for me, because I had always worked on projects that needed to ship fast, and tests were clearly not the priority, you fixed bugs instead. But working on a library like Angular is totally different. Millions of people depend on your code, when you make a mistake you can break applications that loose thousands or hundred of thousands of dollars because of you. The responsibility is overwhelming and that's why it is much more complicated to release new features. I also wasn't the one deciding the priorities for the framework. Any change that you want to make has to work with Google applications, and it's not like you can duplicate functionalities to make it work for everyone (who said forms and http?).

Anyway it was complicated to change the way i18n worked in Angular. I learned a lot and I feel like we're going in the right direction now. I understand the choices that they made for Angular i18n, it's the most efficient and stable way to translate applications. It works very well for huge companies like Google, but it just isn't what most developers need/want.

During this year, I haven't really worked on ngx-translate. The issues are pilling up, I've only merged a few PRs and some of them have been waiting there for a long time without any activity because of me. There are some long term issues that I haven't taken the time to fix (code splitting / lazy loading, testing, ICU expressions, bugs with ionic...).

But before we get to that, let's quickly compare my library with the native implementation.

Angular

In Angular, you translate your templates using an extraction tool that generates xmb or xliff files, which are well defined formats that have been battle-tested. Those files are translated using professional tools, by real translators. At the end you merge the translations at build time and get a translated bundle.

Advantages:

The translation process is well defined, it is easy to detect missing translations and you can integrate that in your plans before deploying your app (extract, send to translators, merge)
It scales well, you never look directly at the files since you use a software for that, you can translate in x languages, you just need to extract once and create the translation files for each locale (which your professional tool should do for you)
it's super efficient because the app is pre-translated when it bootstraps, there's no extra work to apply your translations and it works well with pre-rendering because of that
since you merge the translations at build time, it means that it can support directives, components and other html elements, you can move them around in the different languages, or even remove them if needed
you don't need to worry about lazy loading, your bundles are translated at build time, and that includes your lazy loaded modules

Issues:

it takes a lot of work to setup, you need to extract, send to translators, and then you can merge
you create one app bundle / locale, which means that you cannot change the locale at runtime, you need to reload a different bundle for that. And to do that you need to handle server side routing to deliver the correct locale bundle. Google doesn't feel like it's an issue because you're not supposed to change your locale frequently. And in fact most of your users will change it maybe only once, or not at all. But it still complicates the workflow a lot.
no code translations, only template are translated since that's all you can do at build time for now
harder to use in development because you need to stop your dev server, extract translations, merge them. And the setup is different between JIT and AOT...
you cannot translate libraries, and that's a real problem for components libraries (like material, ng bootstrap, ...)

ngx-translate

With ngx-translate you load the module and configure it, you then load the json files containing your translations. You need to manually define keys for your translations and to write them in your json files that you will probably translate yourself, or transform into other formats that you'll send to your translators. But it's ok because json is easy to manipulate and generate.

Advantages:

you can choose how you want to handle your translations (bundled, http-loaded, pre-cached using service workers or localstorage, etc...)
you can change the locale at any time
it works in your templates AND in your code
json (that's all I need to say)
the community can work on plugins, custom loaders, tooling, etc... everything is hackable and you should be able to make it work the way you prefer

Issues:

it uses bindings (via a pipe or a directive) which means that it works at runtime and you can experience some kind of FOC effect (flash of content) when the translations are loaded and applied. Also it takes some memory and some processor time when change detection is triggered
if you want to split translations, it doesn't work well, the setup is complicated and there are bugs in the library
json is not an official translation format, and most professional translation tool don't handle that, but you can use different loaders to support other formats (like po) so that's not a super huge issue
it's hard to test
if it breaks, then your app will have no text!
it doesn't support angular elements (components, directives, pipes) because there's no "compile" at runtime for AOT applications

Changes in Angular

Like I said, I've been working on Angular i18n for almost a year now. I've actually worked on a lot of other things as well, and the changes in i18n were clearly not the priority for the framework. A lot of internal changes were also necessary before we could do the changes that we wanted.

I've greatly improved the documentation (i18n guide), I've created demo projects with and without the cli to help people get started. I've worked on bugs, and made a few changes, but we've not released anything major for translations.

Finally for v6 the big changes are coming, translating will be done at runtime. Having access to the internals of the framework means that it will be way more efficient than what ngx-translate does. You shouldn't experience the FOC effect, and it won't take any resource during change detection. You'll be able to do code translations, at last! There will only be one bundle per application for all of the locales (or multiple, if you prefer). And libraries should be translatable.

What will not change:

you'll still have to extract translations using the extraction tool and merge them at build time, which means that's it's not very easy to use in development
there's no json format yet (we've been discussing internally about opening the API so that developers can write their own serializers if they want)
it'll still be more complicated to setup and to use than ngx-translate
you can translate at runtime in your code, but the templates will be translated at bootstrap, which means that you cannot change the locale without reloading the app
new features will still take a long time to be implemented, because we don't have the freedom that a library like ngx-translate has

So what about ngx-translate future?

This has been a long post, and we're finally getting to the part where we talk about the future of ngx-translate. The way I see it there are 2 solutions:

1/ we continue like it has been for the past year, only merging a few PRs, not working on new features and not improving the workflow. I keep working on making Angular i18n better and hopefully people will stop using this library because the native solution will be better. Or maybe a real alternative will emerge (like https://github.com/robisim74/angular-l10n).

2/ I change the way I work and decide to spend more time on the library (at least 1 day/week) to improve it: fixing lazy loading, code splitting, adding functions to help with testing, support ICU expressions, create well documented and maintained examples, finally tackle ionic and other mobile issues, ... I focus on making sure that the library stays a viable alternative to Angular i18n by providing solutions to the "problems" that Angular i18n will not fix. I write better tooling, maybe even an editor for the translations. I rewrite the documentation, on a real website with shiny examples.

To do all of that, I would need to make this library profitable somehow. I was thinking about changing the license to require companies to pay for the library (while keeping it free for open source and personal projects) in exchange for priority support (for bugs fixing, and for working on the features that they want the most). Obviously the current version would remain free and MIT-licensed, since there's no legal way to retroactively change a license, and it would be stupid to do that anyway. But new versions would be using this new license.

This library is downloaded ~350 000 times / month on npm now, if you compare that to the ~2 400 000 downloads of @angular/core, it means that my library is used in 1 out of 7 Angular projects! That's crazy, and it gives me confidence that this is viable.

What do you guys think? Would your companies be willing to pay for a better ngx-translate? Do you see any other alternative?

ZCatherine commented 5 years ago

I want to know if I18N still does not support translation of component library.

tatsujb commented 5 years ago

@ngehlert I'm in exactly the same state you are except for me ngx-translate is really not cutting it.

And I'm stuck being cussed out by my boss because "i18n being in the state you claim for Angular in 2018 (Q4) is impossible!!!"

@ocombe

I agree, Google has its own solution internally (closure) and that's why it's not very important for them... We have limited resources and clearly this is not the top priority.

I can't make heads or tails of such a decision.

ngehlert commented 5 years ago

@tatsujb just curios, what feature is missing for you in ngx-translate.

I would not count on the dealine for the Angular translation feature... I has been postponed a LOT of times already...

tatsujb commented 5 years ago

@ngehlert I know :( ... I'm just trying to get some multiple-choice/dynamic translations in. I also noticed I can't get certain places translated in this library (such as input placeholders).

not that the angular method doesn't have it's fair share of problems and their idea that having to start from scratch on what you were doing on your webapp when changing language (reload the whole page) is acceptable in 2018-19, is ludicrous.

so far I'm a bit frustrated by how little automation there is as compared to the angular way but am pleased with the use of JSON, which you can organize really really precisely (by page + by view + by component) also I was up and running really REALLY fast. but yeah I'm still only 5% of the way on all my translatable fields after a day it feels sooooooo slow to go get them one by one.

luckily I only have to search my project by the i18n tag so that saves alot of time.

ngehlert commented 5 years ago

@tatsujb well multiple-choice/dynamic translations is not a problem in ngx-translate. afaik there are even plugins e.g. for the angular router so you can swap language based on the url. And i know for sure you can translate input placeholders :)

eh and you don't have to extract them by hand. there is automation for it. have a look here: https://github.com/biesbjerg/ngx-translate-extract

just have another look. pretty sure ngx-translate will feature all your needs... I'm just still struggling because it is not sure whether this lib is being supported in the future and I highly prefer native ways - but in this case the native way is just not good enough

tatsujb commented 5 years ago

@ngehlert you're right I was doing something dumb :

<input
       [placeholder]="{{ 'confirmedDate' | translate }}"
>

when obviously I was supposed to be doing :

<input
       [placeholder]="'confirmedDate' | translate"
>

ngehlert commented 5 years ago

I don't have a project to test it on right now, but I'm pretty sure you have an error in your syntax. try use the placeholder without the brackets [ and ].

so instead of [placeholder]="{{ 'confirmedDate' | translate }}"

do placeholder="{{ 'confirmedDate' | translate }}"

or even this one should be possible [placeholder]="'confirmedDate' | translate"

you just mixed up different versions of the syntax together.

anilgr commented 5 years ago

Can anyone tell how did you translate using native way?, you need angular CLI for that right?. Ionic 3 project is not even angular project.

ngehlert commented 5 years ago

@anilgr you find everything here https://angular.io/guide/i18n

no you don't need angular cli for that

ionic 3 is an angular project as it uses angular :) it may not use the angular cli but it is still an angular project. i'm using the native translation in ionic 3 by myself

Gokul-Pulsebeat commented 5 years ago

@ocombe Does Angular i18n and/or ngx-translate support AngularJS (version 1.x)? Can these services be downgraded in used in AngualrJS?

Ghostbird commented 5 years ago

For me one of the great things about ngx-translate is the ability to load multiple translations with fallbacks, on the fly.

I use this approach:

global translations (these are always loaded first, mainly used for the list of languages.)
language translations (e.g. English)
country translations (e.g. override pants with trousers and color with colour in UK)

I think it is fine if only critical bugs are fixed. This library is stable and has all the functionality I need.

broweratcognitecdotcom commented 5 years ago

ngx-translate is better than what comes with angular. We can't switch at this point. It's waaaay too late. otherwise we have zero issues with your library. it is great.

VVKot commented 5 years ago

@ocombe Now that angular v8 with Ivy opt-in is out is there a new estimate on translation plans?

ocombe commented 5 years ago

Once ivy is the default in google apps we will start working on the translation service for external users. So anywhere between soon and v9 :)

leolcao commented 5 years ago

@ocombe, what is your plan about upgrading ngx-translate to support Angular 8.x?

ocombe commented 5 years ago

it's supposed to work with v8 already

dsebastien commented 5 years ago

Hello @ocombe,

I'm curious about the current state of things. What would you recommend for a brand new project? ngx-translate or angular i18n?

I find it hard to clearly see where I should be going..

ocombe commented 5 years ago

For people waiting for runtime i18n with ivy: bad news, I had to leave the Angular team (budget cuts) and this means that i18n will get less attention. Pete B. Darwin will work on it part time, but he also has a lot of other priority things on his list (like ngcc). The current plan is to have translations working with ivy for v9 but only as a build step (like it is right now). This means that it's still going to be 1 build / locale for now, and there won't be code translations (only template translations).

Looks like ngx-translate still is the best choice for now 😕 I'll see what I can do on my free time to improve the lib. I might rewrite it from scratch for ivy because there's a lot of flaws in the current design that would require a complete rewrite to fix, and I think that we can use runtime translations from ivy to do a good part of the work (meaning better perf). We would loose the ability to change the language without reloading the app (or at least the templates), which I don't think it's too big of a deal (and for those who absolutely need this, then the current ngx-translate would still work).

kolkov commented 5 years ago

WTF, Google have no money?!!

ocombe commented 5 years ago

They are recruiting internally for the team, it's just the budget for external contractors like me that was over budget

alessiostalla commented 5 years ago

@ocombe last time I tried the current ngx-translate does not work with the Ivy preview and AOT. And Ivy will become the default in the future, so that's going to be a problem. I can help with development. However, we need the ability to switch the language, and doing so without reloading the whole app and without complicating the build is a big pro (though not absolutely necessary). I guess my ideal would be to have two strategies, the fast one requiring a reload, and the slower but more flexible one doing everything at runtime with no reloads.

ocombe commented 5 years ago

If it doesn't work with ivy&aot then it's a bug that I should fix. I don't really see why that would be the case since ivy is supposed to be 99% compatible with view engine. @alessiostalla could you open an issue with a repro project that I could use to see what's the issue? Thanks!

ngehlert commented 5 years ago

@ocombe that are some really sad news :( code translations not even in V9?... that was supposed to be in couple of major versions ago - and somehow always postponed. I know it's not your fault^^ still just sad to hear after all, that (at least in my eyes) such an important feature seems to be completely ignored by the angular team.

Maybe it's time to go back to ngx-translate 👍

vivainio commented 5 years ago

Since this thread is what is being used for "general discussion", I made a blog post on a possible alternative approach: https://dev.to/vivainio/trivial-typesafe-translations-in-angular-3aod

ocombe commented 5 years ago

@ngehlert I'm going to work on some new tools / services for ivy, hopefully for v9. Hold on for a few weeks while I figure things out, but I shall bring some good news to the community soon :)

bjornharvold commented 5 years ago

Great library! Have used it successfully for years. #gratitude. Fix the small issues and feature enhancements, bump the major version and charge $9.99 for it. Assume worst case scenario 10% of your 350K downloads upgrade (which they will), you just netted $350K. Charge for major versions going forward with a cheaper upgrade path for existing customers.

Thank you @ocombe

ewok-janitor commented 5 years ago

Indeed. I can no longer wait for google to come up with a runtime i18n solution. I would pay more than $10, especially if there was an automated migration path.

julianpoemp commented 5 years ago

Option 1. There are people that use your library in free open source projects. @ocombe why don't you use opencollective to collect donations?

alessiostalla commented 5 years ago

@ocombe I couldn't reproduce it. Maybe it depended on some Angular.next version that has been superseded.

ocombe commented 5 years ago

So now that I left Google, I have some time to work on all the things that I wanted to do for so long. I'll be working part time on https://www.locl.app/. It will be the next gen library for i18n with a bunch of tools to go with that. Since that represents a lot of work, some parts will be free (the lib most likely) and some will be a subscription or something like that. In any case it'll be free for open source projects.

I will also see if I have the time to work on ngx-translate to fix all the current issues and add some new features, and offer paid support (which could be part of the subscription to locl)

bjornharvold commented 5 years ago

Also check out what Netanel is doing with Transloco: https://github.com/ngneat/transloco / https://netbasal.com/introducing-transloco-angular-internationalization-done-right-54710337630c

ArielGueta commented 5 years ago

@ocombe thanks for your work!

@bjornharvold we migrate to Transloco. It's really awesome library.

julianpoemp commented 5 years ago

@ocombe thanks for your work!

@bjornharvold we migrate to Transloco. It's really awesome library.

I migrated to transloco, too. It's very good and easy to migrate. Works with my translation files and the migration process took me only 15 minutes 😄 👍

vmasek commented 4 years ago

I've got together a blog post about translations and i18n in Angular, it touches the topic from the perspective of the architecture. You could say that it is translations as a code, the best thing is that they are fully typed and lazy-loaded.

Feel free to have a look, migration from ngx-translate is pretty easy.

https://medium.com/angular-in-depth/angular-typed-translations-29353f0a60bc

ahnpnl commented 4 years ago

hi, I saw release v12 has a few new features. Does it mean that the 2nd solution was chosen @ocombe ?

ocombe commented 4 years ago

Not really, I've just taken the time to merge all of the existing PRs :) But I'm focusing my efforts on my new project Locl that will be free for open source and paid for commercial projects

pengrongbo commented 4 years ago

@ocombe Do you still maintain this library for angular 9? I mean to fix some of the existing issues and release a new version for Angular 9 and after.

ocombe commented 4 years ago

Yes, I haven't had time to look into it, if you could make a PR that would be awesome!

SimonNodel-AI commented 4 years ago

Well, I am very disheartened by progress with localization support in Angular. First of all I'd like to say huge thank you to @ocombe for the work you've been doing and for being passionate about this topic and all the effort you've put it into making it happen. I've been following your progress and Angular team progress on localization and ngx-translate was my choice (pre Angular 9 release). Fortunately or unfortunately, we could hold off on the decision for while however, now I need to make a decision for our localization strategy. I was really hoping, that with you on Angular team, the built-in solution would do all the things we need. Sadly its not so. I no longer have trust that Angular 10 will be any better.

Given that your effort is now focused on locl I don't think ngx-translate is a viable choice for us. As it stands, I would have to choose between transloco and locl. I'd love to support your work but, there is no clarity to pricing model and I am not sure when that will become available. I really hope you can publish those details soon otherwise I'd only have 1 choice.

ocombe commented 4 years ago

Yeah, I just hired someone to help me on the project, hopefully you should see some progress on that part soon!

sebgos commented 4 years ago

@ocombe any news on Locl and ngx-translate future?

ngehlert commented 4 years ago

Well, I am very disheartened by progress with localization support in Angular. First of all I'd like to say huge thank you to @ocombe for the work you've been doing and for being passionate about this topic and all the effort you've put it into making it happen. I've been following your progress and Angular team progress on localization and ngx-translate was my choice (pre Angular 9 release). Fortunately or unfortunately, we could hold off on the decision for while however, now I need to make a decision for our localization strategy. I was really hoping, that with you on Angular team, the built-in solution would do all the things we need. Sadly its not so. I no longer have trust that Angular 10 will be any better.

Given that your effort is now focused on locl I don't think ngx-translate is a viable choice for us. As it stands, I would have to choose between transloco and locl. I'd love to support your work but, there is no clarity to pricing model and I am not sure when that will become available. I really hope you can publish those details soon otherwise I'd only have 1 choice.

@SimonNodel-AI what feature is missing for you in Angular 9? With the new $localize service I managed to get translations completely running (also in TypeScript) in Angular 9, without any external library.

SergeyBarskiy commented 4 years ago

Hey, @ocombe . if you have a few minutes, could we talk about your project? Our company is weighing in the support for ngx-translate, but my boss needs a bit more information. My email address is in my profile... Thank you!

ajayojha commented 4 years ago

Hi @ocombe, First of all, I would like to thank you for your efforts on the @ngx-translate/core package.

I have created an extensible library @rxweb/ngx-translate-extension of @ngx-translate/core. This provides more than 50+ spectacular features.

The objective of creating this library for helping the existing users who using @ngx-translate/core package but not getting a quick solution if they stuck somewhere or the limitations of the features which they are expecting as an intuitive solution in the base library. As you are the expert so I would request you please review the features provided by @rxweb/ngx-translate-extension as well as the sample application and share your precious inputs which make this library even better for ngx-translate community users.

As I said this is an extensible library of ngx-translate not a migration from ngx-translate to ngx-translate-extension. The base remains the same. Please refer extensible guide for taking a glimpse of the extension. In simple words, we can say ngx-translate is active by using 'ngx-translate-extension' package for new features and bug fixes.

High-level Features

Component/ HTML section-wise resolve the translation content.
One Configuration through the application. Not required to use 'forChild'.
Resolve translation content through @translate decorator.[NEW]
The more intuitive way to bind the FormControl error messages.
Pure pipe for translation.
Many More...

Here is the snap of extending the features.

I will wait for your exemplary response.

Rush commented 3 years ago

@ajayojha does your library support zoneless operation?

mbeckenbach commented 3 years ago

Please just go on with this one. After a looong time i tried to use the official i18n again. And it still sucks the same as in the beginning. Yeah the builds are faster now and i can use it in typescript. But it is still way to painful to use.

ngehlert commented 3 years ago

@mbeckenbach out of curiosity what is missing for you from the official i18n package?

mbeckenbach commented 3 years ago

@ngehlert Besides the possibility to switch language at runtime, tooling is simply bad.

There is nothing like xliffmerge built in. Because never people need to sync such files…

Then when you bring it together with xliffmerge and universal you maintain the list of languages in how many places? Many

mbeckenbach commented 3 years ago

@ngehlert Another think missing in official one is a possibility to have strongly typed keys. @@foo.bar is a magic string. With NGX translate and some effort i can have it strongly typed and refactoring safe.

TaylorAckley commented 3 years ago

Sorry to be that guy - Seems like the status is of ngx-translate is still up in the air based on that thread, but it's been quite a while since there was a substantial commit to core. Is ngx-translate in hibernation in favor of locl?

ngx-translate / core