Inconsistent Scope Resolution Between Template and Class

[YannickLauzier-eaton]

Hello everyone,

I haven’t found a clear answer yet, but please feel free to point me to existing discussions or issues if this has already been covered. 🙂

Context

We are working in an NX workspace and plan to build an application using a domain-driven architecture.

We are very optimistic about Transloco, as it allows:

• Loading translations from libraries via an inline loader
• Using the Transloco Keys Manager (TKM) for extraction and validation

Our intended workflow:

• Developers use extract to update translation files.
• CI uses find to validate key and it should fail if a key is not extracted, using emitErrorOnExtraKeys: true.

apps
 ├─ host
 │   └─ loads features from domain-host
 ├─ mfe-a
 │   └─ loads features from domain-a
 └─ mfe-b
     └─ loads features from domain-b

libs
 ├─ domain-host
 │   └─ feature-a
 │       └─ src
 │           ├─ assets/i18n
 │           │   ├─ en.json
 │           │   └─ fr.json
 │           └─ lib/feature-a
 ├─ domain-a
 │   ├─ feature-a
 │   │   └─ src
 │   │       ├─ assets/i18n
 │   │       │   ├─ en.json
 │   │       │   └─ fr.json
 │   │       └─ lib/feature-a
 │   ├─ feature-b
 │   │   └─ src
 │   │       ├─ assets/i18n
 │   │       │   ├─ en.json
 │   │       │   └─ fr.json
 │   │       └─ lib/feature-b
 │   └─ ...
 ├─ domain-b
 │   ├─ feature-a
 │   ├─ feature-b
 │   └─ ...

Global transloco.config.ts

const config: TranslocoGlobalConfig = {
  langs: ['en', 'fr'],
  keysManager: {
    defaultValue: 'Missing Translation: {{key}}',
    sort: true,
    unflat: true,
    emitErrorOnExtraKeys: true,
  },
  scopePathMap: {
    domainAFeatureA: '${sourceRoot}/assets/i18n',
    domainAFeatureB: '${sourceRoot}/assets/i18n',
    domainBFeatureA: '${sourceRoot}/assets/i18n',
    domainBFeatureB: '${sourceRoot}/assets/i18n',
  },
};

Configuration from the host

export const appConfig: ApplicationConfig = {
  providers: [
    // ...
    provideHttpClient(),
    provideTransloco({
      config: {
        availableLangs: ['en', 'fr'],
        defaultLang: 'en',
        reRenderOnLangChange: true,
        prodMode: !isDevMode(),
        flatten: {
          aot: !isDevMode(),
        },
      },
      loader: TranslocoHttpLoader,
    }),
	// ...
  ],
};

Expected Behavior

Each library declares its own scope.

For example, libs/domain-a/feature-a contains a FeatureA component that provides its scope:

@Component({
  selector: 'lib-feature-a',
  template: `
    {{ 'domainAFeatureA.keyFromTemplate' | transloco }}
  `,
  providers: [
    provideTranslocoScope({
      scope: 'domainAFeatureA',
      loader: {
        en: () => import('../../assets/i18n/en.json'),
        fr: () => import('../../assets/i18n/fr.json'),
      },
    }),
  ],
  imports: [TranslocoPipe],
})
export class FeatureA {
  keyFromClass = translateSignal('keyFromClass');
}

Observed Issues

• Template keys (domainAFeatureA.keyFromTemplate) are extracted and resolved correctly.
• Class-based keys (translateSignal) do not behave the same.

Key Manager (TKM) behavior

For keyFromClass to be extracted by TKM, I must explicitly specify the scope:

translateSignal('keyFromClass', undefined, 'domainAFeatureA');

However, this causes an unexpected side effect:

Transloco attempts to load translations from a domainAFeatureA folder inside the host application, rather than using the scope provided by provideTranslocoScope.

If I instead do:

translateSignal(
  'keyFromClass',
  undefined,
  inject(TRANSLOCO_SCOPE)
);

✅ Runtime behavior is correct.
❌ But when running extraction again, the key is removed from the JSON file because of:

transloco-keys-manager extract \
  --project domain-a-feature-a \
  --remove-extra-keys

Using the class based key as the template key.

If we are doing the following:

keyFromClass = translateSignal('domainAFeatureA.keyFromClass');

We have an error during the runtime and the translations are not resolved and the key manager does not extract the key.

Missing translation for 'domainAFeatureA.keyFromClass`.

Questions

• Is this expected behavior?
• Should class-based translations automatically inherit the scope provided via provideTranslocoScope, just like template-based keys?
• Is there a recommended way to use class-based translations in libraries without breaking TKM extraction.
• Is this a limitation / bug in Transloco or Transloco Keys Manager?

Thank you!