Loading the library's translations

The library ships translatable strings of its own — currently the MatPaginatorIntl labels. Transloco loads translations from your app’s assets, not from node_modules, so those strings have to be extracted into your assets and merged in by your loader before they resolve. Until you do that, they render as raw key paths.

You need this if you use MatPaginatorIntlTranslocoService, or if you see FLYZE_LIB_CORE_ANGULAR.… on screen.

Related: features/relative-translation-keys.

How it is wired

Piece	Role
src/lib/i18n/en.json, de.json in the package	the library’s keys, one file per language
the i18n block in projects/lib-core-angular/package.json	declares scope FLYZE_LIB_CORE_ANGULAR, path src/lib/i18n, strategy join
assets in ng-package.json	copies src/lib/i18n into the published package
your app’s transloco.config.js	tells transloco-scoped-libs where to write
your app’s TranslocoLoader	merges the extracted file into the translation for that language

With strategy: 'join' the extractor writes <lang>.vendor.json next to your own <lang>.json — it does not touch your file. The content is the library’s keys nested under the scope:

{
    "FLYZE_LIB_CORE_ANGULAR": {
        "I18N": { "MAT_PAGINATOR": { "FIRST_PAGE_LABEL": "First page", "…": "…" } }
    }
}

That nesting is why MatPaginatorIntlTranslocoService resolves the flat path FLYZE_LIB_CORE_ANGULAR.I18N.MAT_PAGINATOR.… with no transloco scope involved — and why you do not configure a scope for it. It also means step 3 below is not optional: a file nobody loads changes nothing.

1. Add the extraction config

Install @jsverse/transloco-scoped-libs as a dev dependency, then in the app root:

transloco.config.js

module.exports = {
    rootTranslationsPath: 'src/assets/i18n/',
    scopedLibs: ['./node_modules/@flyze/lib-core-angular']
};

rootTranslationsPath is where the *.vendor.json files are written. Which languages get extracted is not configurable here — the extractor globs every *.json in the library’s i18n folder, so you get one vendor file per language the library ships, regardless of what your app supports. (langs in transloco.config.js is read by transloco’s keys-manager, not by this tool.)

2. Run it as part of the build

npx transloco-scoped-libs

Wire it into prebuild / prestart rather than running it by hand:

{
    "scripts": {
        "prebuild": "transloco-scoped-libs",
        "prestart": "transloco-scoped-libs"
    }
}

Otherwise a library upgrade that adds keys leaves the app rendering raw key paths until someone remembers.

Two things to expect on a first run:

• It prints Error: … ENOENT … en.vendor.json. Benign — it reads the output file to merge into and that file does not exist yet. It writes it anyway.
• It appends each generated file to your .gitignore. The vendor files are build artifacts; do not commit them, and make sure the extraction runs in CI. Pass skipGitIgnoreUpdate: true if you would rather manage .gitignore yourself.

3. Merge the vendor file in your loader

The extracted file is a second file for the same language, so your TranslocoLoader has to fetch both and merge them:

@Injectable({ providedIn: 'root' })
export class TranslocoHttpLoader implements TranslocoLoader {
    constructor(private http: HttpClient) {}

    getTranslation(lang: string): Observable<Translation> {
        return forkJoin({
            app: this.http.get<Translation>(`/assets/i18n/${lang}.json`),
            vendor: this.http
                .get<Translation>(`/assets/i18n/${lang}.vendor.json`)
                .pipe(catchError(() => of({})))
        }).pipe(map(({ app, vendor }) => ({ ...app, ...vendor })));
    }
}

The catchError matters: a language your app supports but the library does not ship has no vendor file, and a 404 there must not break the whole translation load.

Symptoms and causes

You see	Cause
FLYZE_LIB_CORE_ANGULAR.I18N.MAT_PAGINATOR.…	the extraction never ran, or the loader does not merge <lang>.vendor.json (step 3)
the whole language fails to load	the loader fetches the vendor file without a catchError and the library ships no file for that language
labels correct after reload, stale after switch	expected — the paginator does not emit changes, see features/relative-translation-keys
keys missing after a library upgrade	re-run the extraction — wire it into prebuild