# Transloco: the Angular internationalization library built on signals

> A TypeScript monorepo under the @jsverse scope, with runtime language switching, lazy loading, a keys-manager that extracts translation keys from your source, and an alpha train aimed at version 9.

**jsverse/transloco** — 🚀 😍 The internationalization (i18n) library for Angular

- Repository: https://github.com/jsverse/transloco
- Website: https://jsverse.gitbook.io/transloco/
- Stars: 2,281 · Forks: 227
- Language: TypeScript
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/jsverse-transloco

## The package scope changed, so dependency names changed

The first thing the README says is an important callout marked IMPORTANT, and it is about dependency names rather than features. The Transloco packages are now published under the `@jsverse` scope, and existing dependencies need updating to get the latest features.

That is a mechanical migration rather than a design change, but it is the kind of thing that breaks a build in a way that costs an afternoon to trace. If you are upgrading from an older Transloco, every import specifier and every `package.json` entry moves from the previous scope to `@jsverse`. The README also carries a `pkg.pr.new` badge, which is the continuous-release service that publishes a package straight from a pull request so you can test a change before it lands in a tagged release.

The project itself is TypeScript, MIT licensed, at 2,281 stars and 227 forks with 153 open issues, and the last push was 2026-09-28. The tree confirms it is a monorepo managed with pnpm and Nx: `pnpm-workspace.yaml`, `nx.json`, `libs/` for the packages, `apps/` for the applications, `tools/`, `scripts/`, plus a `.verdaccio/` directory for a local package registry. There is a `BREAKING_CHANGES.md` at the root and a `CLAUDE.md`, and `CHANGELOG.md` is generated through `changelog.config.js` with commit messages linted by `commitlint.config.js` and hooks in `.husky/`.

That commit discipline is worth noting. A library that publishes alpha versions weekly and renames its scope mid-flight needs a reliable way to generate release notes, and the tooling shows it has one.

## Runtime language switching and multiple languages at once

The README describes Transloco as the internationalization library for Angular and puts a signal-based API at the top of its feature list. The rest of the list is where the design becomes clear.

The capability that distinguishes it from the older approach is the pair of runtime language switching and handling multiple languages simultaneously. A language picker that reloads the whole page is easy to implement and unpleasant to use; a signal-based API means the language is reactive state, so switching it updates bound templates without a reload. Handling multiple languages at the same time goes further, which matters for content that is genuinely bilingual, such as a page showing an original text next to its translation.

Supporting that are lazy loading, so translation files are fetched when a language is first needed rather than bundled up front, and flexible fallbacks for missing translations. The fallback behavior is the part teams usually care about most and the part libraries usually treat as an afterthought; a missing key returning the language's own key rather than an empty string makes a partially translated app debuggable instead of blank.

The list also names fully supports standalone components, clean and DRY templates, comprehensive testing support, server-side rendering compatibility, and localization support, meaning locale-aware formatting of numbers, dates and currencies on top of message translation. It closes with a variety of rich plugins, highly customizable and hackable, and schematics.

That last cluster is the honest summary of the project's character. The features are only half of it; the plugin system and the schematics are what you use on day two, when the sample configuration no longer fits your application.

## keys-manager does the part that usually goes wrong

The release notes for the recent 9.0.0 alphas spend more words on the keys-manager than on the core library, which is a good sign about where the project's effort is going.

The problem keys-manager solves is the one that makes i18n projects rot. Developers write the literal key string in a template, the key gets renamed or deleted, and nothing fails until a translator notices a blank label in production. Extracting keys from source at build time turns that into a compile-time or lint-time failure.

The alphas show this component being actively reworked. 9.0.0-alpha.2 published the marker as an ESM-only subpath export and included the LICENSE in all published packages. alpha.3 removed the webpack plugin, added support for `@boundary` and `@error` error-boundary blocks, added a TranslocoTitleStrategy to translate and reactively update router titles, and honored the sort option for pot output, which is the intermediate format used for handing strings to translators. alpha.4 dropped `@ngneat` import compatibility, fixed loading config when `--config` points to a file, and replaced a tsquery-based extraction with a single-pass TypeScript extraction under a performance heading.

Removing the webpack plugin is the most consequential of those. It means keys-manager no longer assumes a specific bundler, which is the correct direction for a library in a framework that has been moving away from webpack by default.

The pot support deserves a second look too. Getting a string from a code change to a translation file to a translator and back is the workflow that determines whether a team actually maintains its translations, and supporting the standard gettext interchange format is how you let translators use the tools they already have.

## Documentation lives on GitBook, and that is where the depth is

The README is a feature list and a set of links, and it is honest about not being a manual. Documentation is on GitBook, with pages for the documentation proper, a sandbox and examples section, a schematics page, a blog posts collection, and an FAQ.

The sandbox link matters more than it sounds. A sandbox and examples page lets you see Transloco handling a language switch, a fallback and a lazy load in a running app rather than in a code snippet, which is the fastest way to decide whether the plugin you need exists.

The schematics page covers the setup path. Angular schematics generate the module wiring, the loader configuration and the initial translation files, which removes the most tedious part of adding i18n to a fresh application and, more importantly, makes the setup repeatable across a team. If you are evaluating a library, run the schematic on a scratch application before reading anything else, because the generated files tell you what the library thinks a good setup looks like.

The repository itself is where you look for the things docs tend to omit. `BREAKING_CHANGES.md` is the file to read first on any alpha version. `CHANGELOG.md` is generated, so per-release detail is in the GitHub releases rather than the repository. `CODE_OF_CONDUCT.md` and `CONTRIBUTING.md` are present, and the PRs-welcome badge in the README points at the contributing guide.

Given that the library is at 153 open issues and moving through alpha versions, the practical reading order is the FAQ, then the breaking changes for the version you plan to pin, then the sandbox.

## Conclusion

Transloco is a serious choice for Angular localization rather than a thin wrapper, and the parts that make it serious are unglamorous: a keys-manager that extracts keys from TypeScript at build time, schematics for setup, plugin boundaries, and a documented fallback mechanism for missing keys. Signals are the reason it can offer runtime language switching and simultaneous multiple languages without the loader-state plumbing that older Angular i18n approaches needed. Two things to weigh. Version 9 is still an alpha train, so the release notes carry breaking-change markers and you should read `BREAKING_CHANGES.md` before pinning a version rather than tracking master. And the packages moved to the `@jsverse` scope, which means every dependency line in your `package.json` needs updating. The documentation is on GitBook rather than in the repository, so budget for reading external docs before you estimate the work.

## FAQ

### What is Transloco?

Transloco is an internationalization library for Angular. You define translations in JSON files, load them per language, and bind them in templates through a signal-based API that supports switching the active language at runtime and holding several languages at once.

### What is ngx-translate/core?

That is the core package of ngx-translate, Transloco's predecessor in the Angular ecosystem. Transloco covers the same job with a signal-based API, lazy loading, a keys-manager for extracting keys from source, fallbacks, and plugins. If you are starting new work, the README's note about the @jsverse scope is the first thing to act on.

### Which translation library is best for Angular?

It depends on what you need. Transloco is a good fit when you want runtime language switching without a page reload, several languages available simultaneously, extraction of keys from TypeScript source, and a plugin system. ngx-translate remains widely used and simpler if you only need static per-language strings and do not want the extra tooling.

### How do I implement localization in Angular?

You write translations as JSON files, register a loader so they are fetched per language rather than bundled up front, and bind the keys in templates. Transloco's own answer adds a signal-based API so the active language is reactive state, fallbacks so a missing key resolves to a default language instead of blank, and a keys-manager that extracts keys from TypeScript at build time.

## Sources

- [jsverse/transloco on GitHub](https://github.com/jsverse/transloco)
- [License: MIT](https://github.com/jsverse/transloco/blob/master/LICENSE)
- [Project website](https://jsverse.gitbook.io/transloco/)
- [README](https://github.com/jsverse/transloco/blob/master/README.md)
- [Releases](https://github.com/jsverse/transloco/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jsverse-transloco