Screenplay generation: emit $strings. keys for validation messages that resolve to resources

[woksin]

Validation messages that resolve to a resource string are currently dropped with SP0016, and cannot be recovered by reading a constant.

Why the constant route does not work

A localized application writes its messages as:

RuleFor(_ => _.Title).NotEmpty().WithMessage(_ => RequestMessages.TitleRequired);

where RequestMessages.TitleRequired is generated from a .resx by the MSBuild:Compile generator:

internal static string TitleRequired {
    get { return ResourceManager.GetString("TitleRequired", resourceCulture); }
}

That is a runtime, culture-dependent lookup. It has no constant value, so HasConstantValue / GetConstantValue return nothing and the message is correctly reported as computed. #2397 recovers the lambda-returning-a-literal and lambda-returning-a-const shapes, but those do not occur in a localized application.

Measured on a real production application: 510 WithMessage calls, all of this shape, accounting for 247 of its SP0016 diagnostics.

Suggested direction

The Screenplay language has a $strings. form for exactly this. Rather than resolving the message to text at generation time — which would bake one culture into a document meant to describe the application — emit the key:

message $strings.TitleRequired

The key is statically available: it is the GetString argument in the generated designer property, and equivalently the property name. Recovering it means recognizing that a symbol is a resx designer property and taking its name, rather than trying to evaluate it.

Points worth deciding:

• Whether to qualify the key with the resource class ($strings.RequestMessages.TitleRequired) or emit it bare, and what the language's $strings. form actually accepts.
• Whether to verify the key exists in the .resx at generation time, or trust the symbol.
• What to do when a message is composed rather than referenced directly (string.Format(...), interpolation) — those should stay SP0016.

Acceptance

A validation rule whose message references a resource designer property emits a $strings. message rather than being dropped; SP0016 on the reference application falls by roughly 247; the document still compiles under the Screenplay compiler; generation stays deterministic. Messages that are genuinely computed continue to be reported.

Related: #2397 (where this was discovered and why the constant route was insufficient).

[woksin]

Correction to my own estimate in this issue, from implementing it (PR #2413).

I predicted SP0016 would fall by ~247. It falls by 133 — 643 → 510.

The premise held: 509 of 510 WithMessage calls are the resource shape, none are composed, and all 510 are now readable. The estimate was wrong because it conflated messages that can be read with messages that have somewhere to go.

Recovering a message only removes an SP0016 if the message attaches to a rule the document actually states:

Rule the message attaches to	Count	Declarative counterpart
Must / MustAsync	~248	no
NotEqual, InclusiveBetween, IsInEnum	~37	no
NotEmpty, MaximumLength, GreaterThan(OrEqualTo), Matches, LessThanOrEqualTo, Equal, EmailAddress	~123	yes

For the ~285 whose rule lives in code, the rule is dropped and the message has nothing to attach to. Those still report SP0016 — but now naming $strings.InvoicingMessages.Foo instead of raw lambda text, so what was lost is inspectable.

133 recovered against ~123 countable by regex (which under-counts multi-line chains) means every message reachable by this change was recovered. Closing the remaining ~285 needs Must to gain a declarative counterpart — a language question for Cratis/Screenplay, not more message recovery.

One implementation note worth recording: the key is taken from the GetString literal, not the property name, because StronglyTypedResourceBuilder mangles non-identifier characters when generating the property. And the emitted form is qualified ($strings.<Class>.<Key>) because 6 keys genuinely collide across two resource classes in this application, carrying different text.