I'm submitting a ... (check one with "x")
[x] bug report => check the FAQ and search github for a similar issue or PR before submitting
[ ] support request => check the FAQ and search github for a similar issue before submitting
[ ] feature request
Currrently if you want to use a custom loader in your library or lazy loaded module, you are importing it with forChild and you don't want to isolate it (i.e. because you want to change language uniformly in all layers of the application) you won't be able to effectively use a custom loader for both root and child parts.
The first one to load will have its translations in, but the second won't be able to execute its own loader since the translations for that language will be already there.
It seems this short-circuit will make any further requests to loaders to be ignored.
Using multiple loaders at different levels and having them executed if such translations haven't been loaded yet or modify documentation:
Otherwise, by default, it will share its data with other instances of the service (but you can still use a different loader/compiler/parser/handler even if you don't isolate the service).
Linux Ubuntu 17.10;
Angular v5.1.2
ngx-translate version: 9.0.2
Angular component library (shares same versions): bundled with rollup, tested they are sharing same @ngx-translate singletons
Browser: [all]
The workaround I found atm is to introduce a step in the component library build that will generate .ts files with the translations, and export those constants as a part of the library. After that I'm just extending the application translations with those ones in the translation loader. Not ideal though.
I'd be glad to help if this is a bug.
Im actually looking into the same functionality.
+1, also trying to add translations to a component library
Most helpful comment
Im actually looking into the same functionality.