fix(transloco): 🐛 Allow translateSignal API to access any scope

[maleetz]

Use the autoPrefixKeys=false configuration to find the best provider scope based on the requested key(s), which will then wait for any inline loaders to resolve before trying to translate.

This also includes a small refactor to move the autoPrefixKeys configuration logic into a private function.

✅ Closes: #875

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/jsverse/transloco/blob/master/CONTRIBUTING.md#commit
• [x] 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?

• [x] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Issue Number: #875

Using an app.config.ts with multiple TRANSLOCO_SCOPE providers with inline loaders, you can select translations from either scope using the pipe or directive but only have access to the first scope with the translateSignal API.

What is the new behavior?

To avoid introducing a breaking change but still fix this issue, we can utilize the new autoPrefixKeys configuration property from https://github.com/jsverse/transloco/pull/868.

If the user has configured their transloco service to not automatically prefix the translation keys with the requested scopes then their translation keys will contain the full path of the translation, including the requested scope. We can utilize that full path to find the correct transloco scope in the providers array to support any inline loaders for that scope.

This PR does not address requesting translations from multiple scopes with inline loaders, if someone needs to do that they should create separate signals.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

[pkg-pr-new[bot]]

Open in StackBlitz

@jsverse/transloco

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

@jsverse/transloco-locale

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

@jsverse/transloco-messageformat

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

@jsverse/transloco-optimize

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

@jsverse/transloco-persist-lang

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

@jsverse/transloco-persist-translations

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

@jsverse/transloco-preload-langs

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

@jsverse/transloco-schematics

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

@jsverse/transloco-scoped-libs

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

@jsverse/transloco-utils

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

@jsverse/transloco-validator

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

commit: cf59c01

[maleetz]

I also created a branch to showcase an alternative which consolidates the scope loading logic from the directive / pipe so that we can reuse it in selectTranslate for this use case: https://github.com/maleetz/transloco/commit/213423c15d0a789177deae87df3081ed7b7c62b1#diff-c07e4a02be032d92cac1cfbef925cccb4f35c3a4a1697a76a9993f7790ca296c.

Things I like about the consolidation:

• Less duplicated code
• More clarity that signals / directive / pipe should operate the same when not auto prefixing keys
• Removes the confusing lang => path (lang + scope) => back to lang conversion. Instead I just keep a reference to the correct lang in the observable
• Supports the case of selecting from multiple scopes with one selectTranslate call, but I can't imagine this is a likely use case.

Things I don't like:

• Riskier change
• Waits for more inline loaders that necessary most of the time