Repository navigation
Resolve a $strings. reference against a real dictionary, at runtime - #130
Merged
Merged
Conversation
The frontend rendered a $strings.<key> reference literally - nothing served
the dictionary a .strings file actually holds, so a screen author had a
localization mechanism that compiled and validated but never showed
anything but the token itself in a running application.
StageStrings discovers every .strings file under the mounted model root
via Cratis.Screenplay.Strings' existing IStringsFiles/StringsFile.Parse,
merging every file that declares a given locale into one flat dictionary.
Two new endpoints - /stage/locales and /stage/strings/{locale} - serve
that alongside /stage/scene and /stage/routes rather than folding it into
either: a locale switch is a question about what a running Stage offers,
not something the scene itself needs to carry.
The frontend's useStrings hook fetches both, defaulting to the first
locale reported, and resolveStringsInElement (Cratis/Scene#47) resolves
every reference in a screen's element tree before it reaches the
registry - the same seam SceneContent already had for handing an element
to SceneElementView. A locale switcher only appears once more than one
locale exists; one locale is not a choice worth a control for.
Authored .strings files for every $strings. reference the Billing sample
already declared, next to whichever .play file names each key - the
established <base>.<locale>.strings convention, not a new format. This is
what made the reference resolve to a real value in verification rather
than to an empty dictionary that happened to compile.
Verified end to end against a real running Stage container built from
these changes: /stage/locales and /stage/strings/en both serve real data,
and InvoiceList's title renders as "Invoices" - the value from the .strings
file - rather than the literal $strings.invoice.listTitle token it showed
before this.
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The frontend rendered a
$strings.<key>reference literally - nothing served the dictionary a.stringsfile actually holds. Resolution has to happen at runtime (not compile time) so a locale switch or an edited translation takes effect without recompiling the model.What changed
StageStringsdiscovers every.stringsfile under the mounted model root viaCratis.Screenplay.Strings' existingIStringsFiles/StringsFile.Parse, merging every file declaring a given locale into one flat dictionary./stage/localesand/stage/strings/{locale}, served alongside/stage/sceneand/stage/routesrather than folded into either - a locale switch is a question about what a running Stage offers, not something the scene itself carries.useStringsfetches both, defaulting to the first reported locale.resolveStringsInElement(Give a $strings. reference somewhere to resolve against, at runtime Scene#47) resolves every reference in a screen's element tree before it reaches the registry - the same seamSceneContentalready had for handing an element toSceneElementView..stringsfiles for every$strings.reference the Billing sample already declared, next to whichever.playfile names each key - the established<base>.<locale>.stringsconvention.Verification
npx tsc -b,npx vite build,npx vitest run: 10/10 passing (2 new specs).dotnet test(Debug) on Host: 130/130. On Contracts: 399/399.dotnet build -c Release: clean./stage/localesreturns["en"],/stage/strings/enreturns the full merged dictionary, and InvoiceList's title renders as "Invoices" rather than the literal$strings.invoice.listTitletoken.