@krzysztof-platis we implemented this suggestion, it seemed to work in Spartacus 4.x locally and in CCV2, with the new 5.2 Version, it does not seem to work anymore.. (neither locally nor CCV2, as long as no occ url is defined in the environment file)
our config initializer:
export class CustomI18nConfigInitializer extends I18nConfigInitializer {
readonly scopes = ['i18n.backend.loadPath']; // declare config key that you will resolve
readonly configFactory = () => this.resolveConfig().toPromise();
constructor(
protected configInit: ConfigInitializerService,
private occEndpoints: OccEndpointsService,
private baseSiteService: BaseSiteService
) {
super(configInit);
}
protected resolveConfig(): Observable<I18nConfig> {
return this.baseSiteService.getActive().pipe(
take(1),
map(() => {
// eslint-disable-next-line no-console
console.log('i18n config initializer, load path: ' + this.occEndpoints.buildUrl('i18n'));
return {
i18n: {
backend: {
loadPath: this.occEndpoints.buildUrl('i18n'),
},
},
} as Config;
})
);
}
}
our app module:
providers: [
{
provide: CONFIG_INITIALIZER,
useExisting: CustomI18nConfigInitializer,
multi: true,
},
],
our i18n config factory:
export function i18nConfigFactory(): I18nConfig {
const prefix = environment.occ.prefix ?? '';
const baseUrl = environment.occ.baseUrl ?? '';
const url = `${baseUrl}${prefix}<site-id>/i18n/{{lng}}/{{ns}}`;
// eslint-disable-next-line no-console
console.log('i18n config factory, base url: ' + baseUrl);
return {
i18n: {
backend: {
// value get's replaced in the CustomI18nConfigInitializer with the proper OCC url since we need the base site id in the url
loadPath: url,
},
chunks: {
...translationChunksConfig,
cart: [...cartBaseTranslationChunksConfig.cart],
checkout: [...checkoutTranslationChunksConfig.checkout, 'checkoutGuest', 'checkoutShipping'],
order: [...orderTranslationChunksConfig.order],
storeFinder: [...storeFinderTranslationChunksConfig.storeFinder],
userAccount: [...userAccountTranslationChunksConfig.userAccount],
userProfile: [...userProfileTranslationChunksConfig.userProfile],
},
fallbackLang: 'de',
},
};
}
Is the idea to have both an i18nConfig
AND an i18nConfigInitializer
or should I use just one of them?
I tried to not use a config factory and entirely use the dynamic config intializer, but then it seems that spartacus thinks, the translations will be provided within the app and not be lazy loaded.
If I just use the i18nConfig
with a placeholder loadPath
value, I get a 404. For me, it therefore seems, that the logic from the dynamic config initializer is run too late after the translations where already loaded.
any idea?