ngx-translate/core: an Angular i18n library that supports one live version

The workspace builds two packages, not one

The root package.json is named my-workspace, marked private, and its build target is not the library itself. Two scripts name two separate packages:

"build-all": "ng build ngx-translate && ng build http-loader",
"test-ci": "ng test ngx-translate --watch=false --browsers=ChromeHeadless && ng test http-loader --watch=false --browsers=ChromeHeadless"

The shorter build and test scripts name only ngx-translate, so a plain ng build and a plain ng test never reach the loader. The consequence for a contributor is that a change to the core package can leave http-loader broken without any local test turning red, and build-all and test-ci are the only scripts here that touch both packages in one run. The sources live under projects/, so the package you came for is not at the repository root either. A watch script runs ng build --watch --configuration development and start runs ng serve, so the workspace doubles as a place to develop against the packages rather than only to publish them.

The workspace depends on Angular 22 while the docs stop at 21

Every Angular package in the dependency block sits at the same floor:

"@angular/common": "^22.0.1",
"@angular/core": "^22.0.1",
"rxjs": "7.8.2",
"zone.js": "~0.16.0"

@angular/build, @angular/cli, and @angular/compiler-cli match it at ^22.0.1, while zone.js is held at ~0.16.0, rxjs at exactly 7.8.2, and tslib at 2.8.1. The README tells a different story: its support section is headed Angular 16 - 21 and the new documentation is said to cover installation on Angular 16+. The consequence is that the version this workspace builds against is not inside the range the documentation claims, so the repository is a forward-looking development environment rather than a description of the supported matrix, and a compat/ directory in the tree suggests that gap is tracked somewhere other than in package.json.

Only the current version receives updates and fixes

The support policy is one sentence long: only the current version gets new updates and fixes. For a version that has reached EOL the README offers three paths. Upgrade to the current version, with migration guides for v17 to v18 and for v16 to v17 linked to help. Remain out of date, which the same paragraph describes as leaving you subject to security risks and bugs. Commercial security support for EOL versions, offered by the partner HeroDevs for anyone who cannot migrate but must stay secure. The consequence is that these are not three equal options: the middle one is a stated risk, and the third is a paid engagement with a vendor rather than work you can do yourself.

The README is a signpost, and plugin details live on the website

The README's own position is that it has been superseded. The new documentation at ngx-translate.org is described as divided into smaller, more readable sections than this big README, covering installation on Angular 16+, documenting the additional interfaces, and explaining how to develop custom plugins. What is left in the repository is a list of links, a getting started tutorial hosted by codeandweb, and one recommended tool, BabelEdit, described as a translation editor for ngx-translate files. The consequence for an integrator reading only this checkout is that they learn a plugin API exists without learning its shape, and that the changelog is a link to the releases page rather than a file in the tree.

develop is the default branch and it runs ahead of v18.0.0

The default branch is develop, not master, and the last commit on it is dated 2026-09-26. The published release line is v18.0.0, dated 2026-06-09, preceded by two candidates on a single earlier day: v18.0.0-rc.0 and v18.0.0-rc.1, both from 2026-05-07. The consequence is a gap between what you can read about and what you get. The @ngx-translate/core package a registry hands you is the June release, while a fresh clone of develop carries three further months of commits that are not in it, so until a tag is cut the two are different things. The tree does carry a docs/ directory, and yet the README sends readers to the website instead of to it, so which copy is the maintained one is not something this repository settles.

Conventional commits and a husky hook shape your first commit

Commit format is enforced by tooling rather than left to habit. commitlint.config.ts sits at the root with @commitlint/cli and @commitlint/config-conventional both pinned at 21.0.2, husky is at 9.1.7, and the prepare script installs the hook itself:

"lint": "ng lint",
"format": "prettier --write .",
"prepare": "husky install"

Around them sit .husky/, .prettierrc, .prettierignore, eslint.config.js, angular-eslint at ^22.0.0, and lint-staged. The consequence is that those hooks only exist if the prepare script ran, so a clone where install was skipped or where hooks are bypassed gives you a tree nobody has checked, and the first time format runs, prettier rewrites files across the repository.

Tests need a real Chrome, and two reporters are installed

The test stack is Karma with Jasmine: karma at 6.4.4, jasmine-core at 5.12.1, @types/jasmine at 6.0.0, and karma-chrome-launcher at 3.2.0, with coverage through istanbul-lib-instrument and karma-coverage. Two scripts cover the core package:

"test": "ng test ngx-translate --code-coverage",
"coverage": "ng test ngx-translate --code-coverage --watch=false --browsers=ChromeHeadless"

A Chrome binary therefore has to exist on the machine, and ChromeHeadless is the mode the CI script uses. One oddity in the manifest: karma-mocha-reporter is installed next to karma-jasmine and karma-jasmine-html-reporter, so reporters for two runners are present and nothing in the scripts says which one the suite reports through. A test-and-build-for-all.sh script at the root and a tsconfig.spec.json beside tsconfig.json point at a shell entry point and a dedicated spec configuration, so there is more than one way in.

Editorial conclusion

ngx-translate/core suits a team already on a supported Angular version that wants runtime language switching with per-language translation files. It does not suit a team pinned to an end-of-life release, because fixes go to the current version only and the remaining options are accepting documented security risk or buying commercial support. Before adopting it, read the installation section on ngx-translate.org rather than this README, check that your Angular version falls in the documented range, and decide who edits the translation files, since the recommended tool is a third-party editor.

Frequently asked questions

Official sources

1. License: MIT
2. ngx-translate/core on GitHub
3. Project website
4. README
5. Releases