How should auto-prefixing work in translateSignal?

[kbrilla]

I’d like to get feedback on the long-term API design around scoped translations in translateSignal / selectTranslate.

The main question is whether auto-prefixing should be the default behavior, something explicit and opt-in, or whether scoped behavior should live behind a separate API altogether.

I’m not asking about a specific implementation detail here, but about the expected developer-facing behavior:

• should translateSignal('title') try to infer/apply scope automatically?
• should that only happen when explicitly requested?
• or should scoped signal usage use a different API entirely?
  Looking for the least surprising and most maintainable behavior long-term, especially with scopes and inline loaders.

Linked issues: #875 #891 #903

[Rodrigo54]

My vote: auto-prefixing should be opt-in, not the default - and ideally scopes.autoPrefixKeys defaults to false in a future major.

While working on injectTransloco (#941), I ran into #875 and #903 independently, filed for unrelated reasons, and both trace back to the exact same root cause: auto-prefixing makes translateSignal silently pick one scope from DI at runtime, and that decision is invisible to anything that isn't the running app itself.

• Bug(transloco): Cannot easily access all TRANSLOCO_SCOPE (multi:true) providers with translateSignal API #875: with more than one TRANSLOCO_SCOPE provider active, there's no way to know which one should win. Any fix that still auto-prefixes (mine included, which uses the same "last scope wins" approach fix(transloco): take the last provided scope on selectTranslate #866 already applies) just picks a different wrong default - it doesn't actually solve it.
• Inconsistent Scope Resolution Between Template and Class #903: transloco-keys-manager does static extraction - it can't see a DI-inferred scope at all, so library authors are stuck choosing between working runtime resolution or working key extraction, never both together.

The directive and pipe already prove that not auto-prefixing works fine in practice at scale: they require the fully-qualified key, and as a direct result neither of the above problems exists for them - any number of active scopes are reachable, and the key is always statically visible in the source. service.translate()/selectTranslate() already behave the same way. translateSignal is the one outlier, which undermines the "signal is just a thin reactive wrapper around the service" mental model people reasonably expect - @austinw-fineart's comment on #855 makes the same point. @shaharkazaz's own read on #855 ("None should prefix right?") points the same direction.

For what it's worth, injectTransloco doesn't lock this decision in either way. It never implements the auto-prefix choice itself - it always defers to service.translate()/translateObject(), so it already works correctly under both directions this discussion could land on:

• Opt-in via the existing scopes.autoPrefixKeys flag (already tested against injectTransloco, including combined with t.read(prefix) as the ergonomic replacement for the auto-prefix it turns off).
• Removing auto-prefixing from translateSignal altogether, requiring fully-qualified keys everywhere - functionally identical from injectTransloco's side, since the decision was never made there to begin with.

So this can be decided independently of that PR without blocking it either way. My suggestion: default scopes.autoPrefixKeys to false in the next major, giving existing consumers an explicit migration path via the flag rather than a silent behavior change.