I am working on a PR that would support merging multiple translation files when translating an application. So if a library author provided a set of translation files it would be possible to combine them with the application translations.

This would then need to be integrated into the Angular CLI.

Further, we should look into how best to make this seamless. For instance agreeing on a file naming convention (or perhaps a property in package.json) that told the CLI where to look for such files.

I also have a PR in the works for doing $localize based i18n message extraction from distributable files. We need to ensure that we can avoid extracting messages that came from libraries and were bundled into the main.js for example.

Can we use merging multiple translation files in angular 10?
I am currently using loadTranslations to solve the problem of multiple translation files.

By the way, is the dynamic switching of languages not supported by ivy？

We intend to use $localize within our libraries. One of the limitations we've run into at the moment is that there is no polyfills.ts for a library to add the import '@angular/localize/init';, so there is no global declaration of $localize, and building the library fails with:

Cannot find name '$localize'

We can work around this problem by redeclaring the global in the library and I've made a request here to have that in DT instead, to be able to add the following to the library's tsconfig:

    "types": [
        "@angular/localize"
    ],

But what is the intended way to inform typescript about the presence this global when there is no polyfills.ts?

@sorohan you only need to include this import in any one of your TS files so the compiler to pick up the typing of global $localize function

@petebacondarwin wouldn't that be better if that import was just the typing, and not also effectful (it is actually adding $localize to the global)? Or is that just an implementation detail we should ignore?

So it is true that this could leave the global function in your final application bundle. I believe that it adds about 850 bytes once it is minified.

If you are doing compile-time translation, then the $localize global is indeed not needed.

In Angular CLI builds we actually strip out this JS by configuring webpack. I believe the approach used is to intercept the import and return an empty string instead of the original file. See https://github.com/angular/angular-cli/blob/c8915f42055b7fcefbafbcd64b06bbc6aecf778a/packages/angular_devkit/build_angular/src/utils/webpack-browser-config.ts#L148-L157

Thanks for the info, it's very helpful.

Is using $localize directly actually public API? Should @angular/localize be added to the public_api.md, or should we hold off using it for now?

It is still not strictly public... I think the aim will be for it to be so by 10.1.0.
We still need to get the new message extractor integrated into the CLI before we can honestly support $localize in application code.
I will have a think about if there is a way we could include only the typings for libraries. It is not a use-case I have thought through properly yet.

Thanks for bringing it up.

I think you might be able to do:

import type {} from '@angular/localize/init';

Actually, having just played with this a bit, it seems that ng-packagr will not pull in the imported $localize global in to the library bundle. It leaves the application project to deal with this import. So right now, if you are using CLI to build your application, then this will be stripped out of any libraries that import it.

Be aware that adding $localize tagged strings to libraries is not quite supported yet: there is no way (in CLI today) to extract those messages into translation files.