Bug: scoped translation extraction issues (NX context)
kekel87 opened this issue · 0 comments
Is there an existing issue for this?
- I have searched the existing issues
Is this a regression?
No
Current behavior
We've encountered several issues with scoped translations, I'll list them here and indicate how we've worked around them, or if the issue already exists:
-
provideTranslocoScope
is not considered during extraction// Does not work provideTranslocoScope({ scope: 'scope-name', loader: SUPPORTED_LANGUAGES.reduce( (acc, lang) => ({ ...acc, [lang]: () => import(`../../assets/i18n/[scope-name]/${lang}.json`) }), {} ), }),
// Use token instead { provide: TRANSLOCO_SCOPE, multi: true, useValue: { scope: 'scope-name', loader: SUPPORTED_LANGUAGES.reduce( (acc, lang) => ({ ...acc, [lang]: () => import(`../../assets/i18n/[scope-name]/${lang}.json`) }), {} ), }, },
-
scope
in the structural directive is not considered during extraction// Does not work <ng-container *transloco="let t; scope: 'scope-name'"> <p>{{ t('title') }}</p> </ng-container>
// Use read instead <ng-container *transloco="let t; read: 'scope-name'"> <p>{{ t('title') }}</p> </ng-container>
-
should be checked on directive
<span transloco="alert" translocoRead="scope-name"></span> <span transloco="alert" translocoScope="scope-name"></span>
-
Scope extraction results in empty translation files
Since we generate scoped translations inlibs/[lib-name]/src/assets/i18n/[scope-name]
,transloco-keys-manager
generates an empty (unscoped) file inlibs/[lib-name]/src/assets/i18n/
.
We are just ignoring them for now. -
The typing of the marker function does not support scopes
This issue already exists, and we have applied this workaround.
Expected behavior
-
provideTranslocoScope
should work like the token -
scope
in the structural directive should be put translation in according file -
There should be a way of indicating that there are only scopes and thus preventing unscoped keys and also not generating this files.
-
Update exposed
marker
typing
Please provide a link to a minimal reproduction of the bug
I don't know if you can make an NX repo with Stackblitz
Transloco Config
Here's the configuration of one of our libs:
libs/[lib-name]/transloco.config.js
module.exports = {
rootTranslationsPath: 'assets/i18n/',
langs: ['en', 'fr'],
scopePathMap: {
'scope-name': 'libs/[lib-name]/src/assets/i18n/[scope-name]',
},
keysManager: {
input: [''],
sort: true,
unflat: true,
removeExtraKeys: true,
emitErrorOnExtraKeys: true,
},
};
And here's how we provide translations to be lazy-loaded with the lib:
libs/[lib-name]/src/lib/[lib-name]/[lib-name].routes.ts
export default [
{
path: '',
component: ...,
providers: [
{
provide: TRANSLOCO_SCOPE,
multi: true,
useValue: {
scope: 'scope-name',
loader: SUPPORTED_LANGUAGES.reduce(
(acc, lang) => ({ ...acc, [lang]: () => import(`../../assets/i18n/[scope-name]/${lang}.json`) }),
{}
),
},
},
],
] satisfies Routes;
Debug Logs
No response
Please provide the environment you discovered this bug in
Transloco: 6.0.4
Transloco Keys Manager: 3.8.0
Angular: 17.1.1
Node: 20
Package Manager: npm
OS: ubuntu/mac os
Additional context
Hi,
We are using transloco-keys-manager
in an NX repository, with multiple libraries.
As recommended by NX, most of our codebase resides in the libs, with applications serving only as containers.
With this in mind, we have implemented translations per library (+ a global translation lib), and each library supports its own translation and provides a means for it to be lazy-loadable.
We want to scope each library translation to avoid any translation conflicts in the applications (each lib has a different scope).
I can open a separate issue if that's simpler.
I also want to reference US related to NX, as I believe there's a real topic to document here.
I could try to work on it as soon as I finish the PR on ESM and Angular 17. 😉
I would like to make a pull request for this bug
Yes 🚀