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
Using TranslateModule.forChild() in an Angular lib #883
Comments
We have the exact same problem. |
I think you should just import See the angular documentation on what to import:
Note: nothing mentioned of services
They also distinguish between Widget modules and Service modules. If I understand the usage section of the README of ngx-translate correctly, they also recommend importing
Note that it says use forChild if necessary, not as a general rule for shared modules. Maybe we should document this more explicitly in the README. |
@matheuscaldasrj - Could you find any approach to achieve this behaviour? I am facing similar issue where language change event on application translate service is not propagating to the library. |
Hi I have similar error. I'm using: "@ngx-translate/core": "11.0.0", App.module.ts: TranslateModule.forRoot({
loader: {
provide: TranslateLoader,
useFactory: TranslationProviders,
deps: [HttpClient],
},
}), My LazyLoaded module Imports SharedModule which imports and exports TranslateModule. I tried to import TranslateModule with forChild but didn't help. Any idea? |
Hi, i wrote this ugly solution invoking setTranslation with TranslateService and appending, all translations are come to be loaded and run everything fine: This is my finally solution Library code
App
|
I dont have problems with Translate module, I have in my app.module
And In my shared.module I have
I think that the problem can be that you didnt put the Translate Module in the exports zone of the Shared Module. |
Facing the same issue. I have even tried exporting TranslateModule as well. import { CoreModule } from './core/core.module'; import { AppRoutingModule } from './app-routing.module'; export function createTranslateLoader1( http: HttpClient){ @NgModule({
], export class AppModule { } import { AppRoutingModule } from './../app-routing.module'; export class NgAppUrlHandlingStrategy implements UrlHandlingStrategy { extract(url: UrlTree) { merge(url: UrlTree, whole: UrlTree) { export function createTranslateLoader2( http: HttpClient){ @NgModule({ ] export class CoreModule { } |
@juanjinario
into app.module.ts it started work fine. and in Shared module: |
I had a similar problem as described in the first message in this thread. I tried to create an Angular 7 library with After that, I use I hope my message will help somebody. |
Hi, faced this issue just yesterday with version 11.0.1 and Angular & CLI 8, what worked for me was: Like state in the documentation in my shared module i had:
and in my AppModule, wich also imports the shared module , i add to provide the TranslateStore
Not sure if this is supposed to be done this way but this did resolve the original error message "NullInjectorError: No provider for TranslateStore!". But now everything is translated except the lazy loaded modules. (every component loaded inside the had missing translations). What fixed this was setting the isolate: false when registering the translate module in my SharedModule. This issue ultimately seems to depend a lot with the way the angular project and module registration is set up. Hope this can help.. |
I had the same issue when lazy loading many translated angular 8 modules with ngx-translate/core v.11.0.1 . In the translation module I have :
In the container I have to add this line in the ngOnInit to make it work:
|
This worked for me, In tsconfig.ts of the main application add this to paths and restart your application:
|
Besides adding the standard |
I can confirm that just dropping all .forChild(), and having one .forRoot({...}) in app.module throughout my application + library did the trick. Seems strange though that you can't call .forChild() on what I see as child modules. Oh well. |
I've been tampering a bit with the library, and found out a solution,
providers: [{ provide: TranslateStore }] to the Shared Module seems to solve the injection issues with no .forRoot() call whatsoever |
Thank you so so much. I was having this issue and I've spent a considerable amount of time figuring out why suddenly the library doesn't translate anymore. This solved everything. |
For lazy-loaded modules with different translation loaders (loading
It's like I can't blend the two. I got pretty close though maybe you could have a look and play within |
@ahmadmu |
with lazy module somehow it's essayer it works fine FrontBaseClientModule it's kinda my shared module
export class FrontBaseClientModule {
constructor(
frontBaseClientTranslateLoader: FrontBaseClientTranslateLoader,
appTranslateService: AppTranslateService
) {
appTranslateService.onLangChange.pipe(take(1)).subscribe((event) => {
firstValueFrom(
frontBaseClientTranslateLoader.getTranslation(event.lang as any)
).then((res) => {
appTranslateService.setTranslation(event.lang, res, true);
});
});
}
} if any of you find this helpful please let me know :) |
So I came up with a salutation that might be useful for somebody. import { Injectable } from "@angular/core";
import { TranslateLoader } from "@ngx-translate/core";
import { Observable, zip } from "rxjs";
import { map } from 'rxjs/operators';
@Injectable()
export class MultiTranslationLoader {
protected readonly translationDefinitions: {usagePrefix: string, translationLoader: TranslateLoader}[] = [];
getTranslation(lang: string): Observable<Object> {
const loaders = this.translationDefinitions.map(definition => definition.translationLoader.getTranslation(lang));
return zip(...loaders).pipe(
map((translationsArray) => {
return translationsArray.reduce((prev, translation, index) => {
const translationDefinition = this.translationDefinitions[index];
const translationToAppend = translationDefinition.usagePrefix === undefined ? translation : {[translationDefinition.usagePrefix]: translation};
return {...prev, ...translationToAppend};
}, {} as any);
})
);
}
public registerTranslationLoader(usagePrefix: undefined | string, translationLoader: TranslateLoader) {
this.translationDefinitions.push({
usagePrefix,
translationLoader
});
}
} Usage// app.module.ts
@NgModule({
imports: [TranslateModule.forRoot({loader: {provide: TranslateLoader, useClass: MultiTranslationLoader})]
})
class AppModule {
constructor(@Inject(TranslateLoader) translateLoader: MultiTranslationLoader) {
translateLoader.registerTranslationLoader(undefined, new FakeTranslationLoader());
}
} // child.module.ts
@NgModule({
imports: [TranslateModule]
})
class ChildModule {
constructor(@Inject(TranslateLoader) translateLoader: MultiTranslationLoader) {
translateLoader.registerTranslationLoader('child1', new FakeTranslationLoader());
}
} // child.component.html
<h1>{{'child1.translationKey' | translate}}</h1> <!-- 'child1', because we provided it as usagePrefix in our child module. -->
<h1>{{'translationKey' | translate}}</h1> <!-- direct access to the translations object with all translations --> |
For anyone facing a similar issue, please notice the note in this section of the documentation. It explicitly says: |
Current behavior
I am trying to use ngx-translate inside an Angular 5 lib.
I have read from docs that "The forRoot static method is a convention that provides and configures services at the same time. Make sure you only call this method in the root module of your application, most of the time called AppModule"
So I thought that I should use Translate.forRoot() in my application and Translate.forChild() in my lib module
The problem is that when I use forRoot in my App and forChild in my lib I always get the following error:
I have tested and it works when I use forRoot in application and lib, but I have to use this.translate.use("myLanguage") because seems I have two instances of TranslateService and this doesn't seems to be the proper way.
Expected behavior
My lib should work using Translate.forChild({}) and my application using Translate.forRoot({})
How do you think that we should fix this?
Minimal reproduction of the problem with instructions
Application module
Lib module
Environment
The text was updated successfully, but these errors were encountered: