Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't effectively use more than one Loader [forRoot+forChild] #763

Open
jvquarck opened this issue Jan 4, 2018 · 3 comments
Open

Can't effectively use more than one Loader [forRoot+forChild] #763

jvquarck opened this issue Jan 4, 2018 · 3 comments

Comments

@jvquarck
Copy link

jvquarck commented Jan 4, 2018

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

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.

this._translationRequests[lang] = this._translationRequests[lang] || this.getTranslation(lang);

Desired behavior

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]

@jvquarck
Copy link
Author

jvquarck commented Jan 4, 2018

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.

@EddyNll
Copy link
Contributor

EddyNll commented Jan 17, 2018

Im actually looking into the same functionality.

@Sjerd
Copy link

Sjerd commented Jan 25, 2018

+1, also trying to add translations to a component library

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants