Unmaintained dependency ngx-translate-extract causes error on message extraction with Angular 13+

[hannaeko]

ngx-translate-extract is not maintained anymore. There is an ongoing discussion about forking the project in the issues.

In the meantime this will break our translation process if we upgrade to Angular 13 and so it will block the upgrade ( #349) until resolved. (Angular 12 is EOL next month so I initially wanted to upgrade asap.)

Instead of waiting for a fork, an other option would be to migrate to @angular/localize but this changes drastically the how translation is done.

• Instead of having the translation happening "live" in the browser, we build a bundle for each local. They will then be served under a separated base URL, e.g. zonemaster.net/en, zonemaster.net/se, etc.
• This design is (rightfully in my opinion) to make the final application "lighter" for the end-user as there is no need to load the translation library and everything.
• This also changes the format of the transation file from JSON to XML.
• Finally the language detection would be make at the web server level, using the accept-language header (see example from Angular documentation). That being said I think the example given in the documentation is over simplistic as it only use the first language in the header and the syntax can be much more complex. I did not found any robust method to do language detection without using a actual server being the reverse proxy (be it Apache or Nginx).

I am open to feedback and suggestion on what our next step would be.

[hannaeko]

@matsduf @mattias-p @pnax @tgreenx @mvw-afnic

[matsduf]

In the meantime this will break our translation process if we upgrade to Angular 13 and so it will block the upgrade ( #349) until resolved. (Angular 12 is EOL next month so I initially wanted to upgrade asap.)

Yes, that is important.

Instead of waiting for a fork, an other option would be to migrate to @angular/localize but this changes drastically the how translation is done.

Do you expect Angular/localize to be available and stable for at long time?

* Instead of having the translation happening "live" in the browser, we build a bundle for each local. They will then be served under a separated base URL, e.g. `zonemaster.net/en`, `zonemaster.net/se`, etc.

Having different base URLs (or language suffix) is not a problem as such, but it changes the API that we have set in API.md and when we have started to communicate that, to make it possible to URLs for Zonemaster with the domain to test, we do not want to change it again.

Else I do not fully understand what the difference will be if it happens "live" in the browser or via a change of URL.

Having the language in the URL makes it possible to send a URL with the language set, and that is a positive change.

* This design is (rightfully in my opinion) to make the final application "lighter" for the end-user as there is no need to load the translation library and everything.

Does that in practice make any difference?

* This also changes the format of the transation file from JSON to XML.

I guess there are pros and cons with both formats, but since we mostly use JSON that is probably a negative change.

* Finally the language detection would be make at the web server level, using the `accept-language` header (see [example from Angular documentation](https://angular.io/guide/i18n-common-deploy#configure-a-server)). That being said I think the example given in the documentation is over simplistic as it only use the first language in the header and the syntax can be much more complex. I did not found any robust method to do language detection without using a actual server being the reverse proxy (be it Apache or Nginx).

Do I understand it correctly that the feature that saves the language preference in the local store will not work anymore? But overriding the setting in the browser with another "suffix" will still work, won't it?

I am open to feedback and suggestion on what our next step would be.

Staying with non-supported ngx-translate-extract seems to be a bad option. Waiting for a fork that might or might not come is also a bad option. Do you see any reasonable alternative to angular/localize? Have you already done a POC of using that?

[hannaeko]

Do you expect Angular/localize to be available and stable for at long time?

Given that it is made and maintained by the Angular team as part of the project, I think so.

Having different base URLs (or language suffix) is not a problem as such, but it changes the API that we have set in API.md and when we have started to communicate that, to make it possible to URLs for Zonemaster with the domain to test, we do not want to change it again.

I was talking about that with @pnax , I and think we could have /run-test/<domain> redirect to /<language>/run-test/<domain> (and other urls as well, not only this one).

Else I do not fully understand what the difference will be if it happens "live" in the browser or via a change of URL.

For instance changing the language when looking at a test results will cause a full page reload and not translate the text in place.

Does that in practice make any difference?

Hard to say right now, it should at least make the JS bundle smaller.

Do I understand it correctly that the feature that saves the language preference in the local store will not work anymore?

I did not consider this aspect but yes. I guess there could be a workaround where we fetch the language set in the local storage with javascript and redirect the browser...

But overriding the setting in the browser with another "suffix" will still work, won't it?

You mean change the URL by hand?

Do you see any reasonable alternative to angular/localize?

I have not looked into it much, I will have a look.

Have you already done a POC of using that?

No, I was waiting for feedback first. From what I gather this might be a viable alternative but it comes with a few drawbacks. I will try to make a POC.

[hannaeko]

Have you already done a POC of using that?

A POC is available at #350

[matsduf]

Having different base URLs (or language suffix) is not a problem as such, but it changes the API that we have set in API.md and when we have started to communicate that, to make it possible to URLs for Zonemaster with the domain to test, we do not want to change it again.

I was talking about that with @pnax , I and think we could have /run-test/<domain> redirect to /<language>/run-test/<domain> (and other urls as well, not only this one).

And then "" would be the default language? I guess that could be OK.

For instance changing the language when looking at a test results will cause a full page reload and not translate the text in place.

As before. I guess that is OK.

But overriding the setting in the browser with another "suffix" will still work, won't it?

You mean change the URL by hand?

Or selecting from menu.

[matsduf]

Resolved by #349