feat(transloco): expose activeLang signal on TranslocoService

[arturovt]

Adds a Signal<string> property activeLang derived from the internal lang BehaviorSubject via toSignal with requireSync: true, enabling signal-based reactivity (e.g. inside computed or linkedSignal) without subscribing to langChanges$.

PR Checklist

• The commit message follows our guidelines: https://github.com/jsverse/transloco/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Feature

---

Summary by cubic

Expose activeLang as a Signal<string> on TranslocoService to enable signal-based reactivity of the current language (e.g., in computed or linkedSignal) without subscribing to langChanges$.

^{Written for commit 140ad2b. Summary will update on new commits.}

Summary by CodeRabbit

Release Notes

• New Features

  • Added real-time access to the currently active language value.

• Tests

  • Added comprehensive tests for language state management, verifying default behavior, updates, and state consistency across language changes.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new public activeLang signal was added to TranslocoService, backed by the existing internal lang BehaviorSubject via toSignal() for synchronous access to the current active language. Accompanying test suite verifies that the signal correctly reflects the default and updated language values.

Changes

Cohort / File(s)	Summary
Test Suite libs/transloco/src/lib/tests/service/activeLang.spec.ts	New Jest test suite validating three scenarios: default language initialization, single language update via setActiveLang(), and repeated language updates keeping the signal synchronized.
Service Implementation libs/transloco/src/lib/transloco.service.ts	Added public activeLang signal property that wraps the existing lang BehaviorSubject using toSignal() with requireSync: true, maintaining backward compatibility with existing language control methods.

Possibly related issues

• Feature(transloco): Signal-based API for activeLang #905: This PR implements the requested signal-based API for accessing the active language by adding the public activeLang Signal property to TranslocoService.

---

Fun fact: Did you know? The term "i18n" (a numeronym for "internationalization") follows a naming pattern where the first and last letters of a word are kept, with the number of letters in between replacing the middle—making "a11y" (accessibility) its equally important companion in creating globally inclusive software! 🌍

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and concisely describes the main feature: exposing an activeLang signal on TranslocoService, which matches the changeset perfectly.
Description check	✅ Passed	The description follows the template structure, includes all required sections (checklist, type, behavior descriptions), and provides clear context about the feature with technical details.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/active-lang

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new]

Open in StackBlitz

@jsverse/transloco

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco@911

@jsverse/transloco-locale

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-locale@911

@jsverse/transloco-messageformat

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-messageformat@911

@jsverse/transloco-optimize

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-optimize@911

@jsverse/transloco-persist-lang

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-persist-lang@911

@jsverse/transloco-persist-translations

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-persist-translations@911

@jsverse/transloco-preload-langs

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-preload-langs@911

@jsverse/transloco-schematics

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-schematics@911

@jsverse/transloco-scoped-libs

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-scoped-libs@911

@jsverse/transloco-utils

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-utils@911

@jsverse/transloco-validator

npm i https://pkg.pr.new/jsverse/transloco/@jsverse/transloco-validator@911

commit: 140ad2b

[coderabbitai]

🧹 Nitpick comments (1)

libs/transloco/src/lib/tests/service/activeLang.spec.ts (1)

9-13: Optional: add one custom-config default language assertion.

A small extra case with createService({ defaultLang: 'es' }) would strengthen regression coverage for initialization from config (not only the default test fixture).
Fun i18n fact: in German, “language” is Sprache.

Suggested test addition

+  it(`GIVEN a service initialized with a custom default language
+      WHEN activeLang is read
+      THEN it should return that configured language`, () => {
+    service = createService({ defaultLang: 'es' });
+    expect(service.activeLang()).toBe('es');
+  });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@libs/transloco/src/lib/tests/service/activeLang.spec.ts` around lines 9 - 13,
Add a test that initializes the Transloco service with a custom config and
asserts the active language: call createService({ defaultLang: 'es' }) and then
expect(service.activeLang()).toBe('es'); place this in the same spec
(activeLang.spec.ts) alongside the existing default-language test to cover
initialization-from-config paths and reference the createService helper and
activeLang() method when locating where to add the assertion.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@libs/transloco/src/lib/tests/service/activeLang.spec.ts`:
- Around line 9-13: Add a test that initializes the Transloco service with a
custom config and asserts the active language: call createService({ defaultLang:
'es' }) and then expect(service.activeLang()).toBe('es'); place this in the same
spec (activeLang.spec.ts) alongside the existing default-language test to cover
initialization-from-config paths and reference the createService helper and
activeLang() method when locating where to add the assertion.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1f054855-0221-4fd3-92a3-fc7e5ad6c1f0

📥 Commits

Reviewing files that changed from the base of the PR and between 6618c3d and 140ad2b.

📒 Files selected for processing (2)

• libs/transloco/src/lib/tests/service/activeLang.spec.ts
• libs/transloco/src/lib/transloco.service.ts

[cubic-dev-ai]

No issues found across 2 files