You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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
Current behavior
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.
Code hint:
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).
Please tell us about your environment:
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 text was updated successfully, but these errors were encountered:
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'm submitting a ... (check one with "x")
Current behavior
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.
Code hint:
It seems this short-circuit will make any further requests to loaders to be ignored.
core/lib/src/translate.service.ts
Line 250 in d121f77
Desired behavior
Using multiple loaders at different levels and having them executed if such translations haven't been loaded yet or modify documentation:
Please tell us about your environment:
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 text was updated successfully, but these errors were encountered: