Player-name dialogue slots

A player’s name is not a grammar instruction

A dialogue line can look correct with the writer's favorite test name and still fail when the player chooses something else. The sentence may assume a title, a pronoun, a particular name order or a grammatical form that the name field never supplied. This workbench checks an explicit template contract: which literal values does the line need, and have you actually provided them for each chosen fixture and locale?

Use it when a game or interactive story lets the player choose a name, or when a script must support several approved ways of referring to one character. The output is rendered dialogue and an unresolved-work list. It does not generate a personal identity, determine gender, infer pronouns, decline a name, translate a sentence or connect directly to a game engine. Those boundaries keep a successful substitution from becoming a false linguistic endorsement.

The task differs from a bilingual identity map. A map establishes which names refer to the same person across editions. This page checks the sentence that uses a supplied reference. A correct identity map can coexist with a missing possessive form or an unsupported template expression. Conversely, a sentence can substitute every token while still needing a writer's review for voice, relationship and context.

Author the sentence before trusting the slot

Each template has an ID, an exact locale label and a text string. IDs let you find a line after another revision. Locale labels are compared exactly. The text contains literal prose and tokens such as {{name}}, {{subject}}, {{possessive}} or {{call}}. The name token always uses the fixture's exact supplied name. Other tokens require forms explicitly supplied for that fixture and locale.

The parser accepts a small ASCII key syntax with letters, digits, hyphens and underscores after an initial letter. Surrounding whitespace inside a token is ignored. It does not accept property access, function calls, nested tokens or arbitrary expressions. A request such as {{name.toUpperCase()}} is an unsupported token, not a command to execute. Write a separate approved form if a line needs a specific display convention.

Literal text outside tokens remains authored text. The tool cannot determine that an article, verb ending or honorific in that text is appropriate. If the sentence assumes something not in the slot contract, substitution will not repair it. Consider authoring a neutral sentence, adding an explicit reference form or using a separately reviewed variant rather than expecting a name to carry hidden grammatical metadata.

Keep fixture names and supplied forms separate

A fixture has a stable ID, an exact name and an optional object of locale-specific forms. These are test cases you supply, not newly generated characters or real player observations. Use meaningful IDs such as courier or visitor. The same fixture can have an English subject form, a Japanese call form and another authored display without the software claiming that it translated one into another.

For example, the default courier fixture supplies They and their for two English keys and an authored Japanese call form. The values come from the fixture, not from the spelling Mira. The visitor fixture includes a name with angle brackets and an ampersand to test literal text handling. It deliberately lacks a Japanese call form, so that line remains unresolved until an author supplies an approved value.

The name key is reserved and cannot be overridden inside a form set. If a locale needs a different name-like reference, give it a distinct key and use that key explicitly in the template. This preserves the difference between a player's exact chosen name and an authored contextual form. It also makes the scope of a revision visible: changing one call key need not rename the underlying player fixture.

Run the default case completely

The two English templates welcome the named person and refer to a parcel using supplied subject and possessive forms. Both fixtures have the English forms those lines need. The Japanese template uses call. The courier has that explicit value; the visitor does not. Five of the six line/fixture combinations therefore render, and the sixth reports the missing call key.

Supply a Japanese call value for the visitor and rerun. That resolves its affected line without changing the English welcome or the courier's forms. Now change only the courier's English possessive. Only the English parcel line for that fixture should change. The workbench is useful because dependencies are explicit enough to inspect, not because it applies a broad text replacement across every line.

Try changing the locale label from en to en-US without supplying a matching form set. A line using only name can still render because name is fixture-level data. A line needing subject or possessive becomes unresolved. The tool does not borrow en forms or choose another locale automatically. Decide whether those labels should be separate in your project and author the corresponding data deliberately.

Original fictional scene: the notice that promoted a name

The mission board welcomed the new courier with a title the writer had never put in the player profile. It appeared before the chosen name in every greeting.

During a playthrough of the draft, the player named the character Not Your Captain. The board promptly addressed the courier as Captain Not Your Captain. The player laughed, but the next line was less amusing: a gatekeeper treated the title as a rank that allowed access to a restricted room.

The name had exposed two separate assumptions. One was a sentence pattern that attached a title to every display string. The other was a story rule that acted as if that title described an established office. Changing the chosen name would make the greeting look less strange without repairing either contract.

The writer removed the automatic title from the general greeting. In the scene where rank actually mattered, she used an explicit authored reference key and a separate narrative condition. A person who held no office could still have a name that happened to contain Captain, without the plot promoting them by string resemblance.

A second fixture revealed another gap. The English parcel line needed a supplied possessive, but the profile had only a name. Someone suggested guessing from the spelling. The writer instead recorded an explicit form for the fixture and authored a sentence variant that did not require the key when the game had not collected that choice.

For the Japanese version, the local writer chose a call form appropriate to the relationship in that scene. It was stored under its own locale key. The team did not present the English form as a translation authority or apply an honorific merely because a name looked familiar.

At the next playthrough, Not Your Captain could accept the ordinary delivery without being promoted. The missing-form fixture stayed visibly unresolved until the necessary line or value was authored. The player kept the joke in the name, while the story regained control over rank and reference. This is an original fictional scene, not a report about an actual game or a claim that this website implements access control in a game engine.

Why changing the name would hide the problem

A conventional test name could make Captain plus name look plausible. That would conceal the difference between a chosen display string and an office established by the story. Another player could expose the same error later. The useful revision changes the sentence contract and the narrative state that authorizes a title, rather than treating an inconvenient name as the cause of a broken rule.

The pronoun gap has the same structure. A name may suggest something to an individual writer, but that impression is not a supplied value. The tool reports a missing key. If your story has not asked for that information or does not need it, write another sentence. If it does need an authored form, obtain it through the project's actual character or player specification instead of a spelling-based shortcut.

Apply the counterfactual by testing a mononym, a name containing punctuation, a long form and a form that resembles a token. Read each line's meaning after substitution. A test case should challenge an assumption your script might make. It should not be used to rank real cultures or declare one kind of name inconvenient by nature.

Inserted values stay literal

The parser compiles the template once and then concatenates literal pieces with supplied values. It does not parse a player's name again as another template. If the exact name is {{subject}}, the welcome line displays those characters as the name. It does not replace the inserted text with a pronoun. The same rule applies to a supplied form that contains braces.

The website displays rendered strings as text, including markup-looking characters. That demonstrates the local preview's behavior; it is not a guarantee about the rendering or escaping policy of another engine you export to. Check that engine's integration separately. A downloadable string cannot certify that a destination will preserve the same literal interpretation.

The supported token syntax has no escape language for authoring literal double-brace delimiters inside a template. Unmatched or malformed delimiters are reported with their source position. Single braces in ordinary text are not tokens. If the story genuinely needs delimiter-like text, use a supplied literal form or redesign the authoring contract rather than relying on undocumented parser behavior.

Read an unresolved line as writing work

A missing form does not produce an invented value, a borrowed locale or an empty name pretending to be a completed line. The preview identifies the fixture, template and locale, then lists the missing keys. Syntax problems remain attached to the affected line. Other valid lines can still render, making it possible to separate a local authoring issue from a broken whole-file format.

Malformed JSON, duplicate IDs and unsupported record fields stop the scoped analysis. Correct the source data before trusting its references. The tool cannot know that an incorrectly assigned fixture ID was intended to represent another person. Stable IDs are useful only when their links match the author's actual decision.

A fully rendered line means its literal token contract is satisfied. It does not certify natural grammar, an appropriate relationship register, a coherent plot or a safe external integration. Read the dialogue beside the action that motivates it. In particular, check who is speaking, whom they are addressing and whether the chosen form is permitted in that context.

Scope the work instead of truncating it

The local contract accepts up to twelve fixtures and forty templates, with at most one hundred and twenty selected line/fixture combinations. Select fixture IDs or an exact locale label to narrow a larger dataset. A scope that exceeds the bound returns a clear conflict instead of silently dropping the last rows or choosing a representative sample.

Names, form values and source templates also have explicit size limits measured in UTF-16 units. A rendered line is limited to twelve thousand units, and the selected rendered scope to two hundred thousand. Repeated tokens can expand a short source into a much larger output, so the engine checks the resulting size before concatenating it. It reports an overlarge line without substituting a truncated sentence.

These bounds describe this local workbench, not what your final game can support. Break a large script into versioned scene batches and retain the scope labels. A successful test of twelve fixtures does not mean every possible player name has been tried. Include deliberately difficult cases and recheck them after changing template syntax or destination rendering.

Hand off the rendered lines and the missing work

The export contains selected fixture and line IDs, exact locale scope, rendered text, used keys and a separate unresolved list with missing keys or syntax/render-size diagnostics. It does not pretend that unresolved lines have been integrated. The private project export retains the original JSON and filters so the same authoring decision can be reopened later.

Keep source versions with the receiving project. If one approved form changes, find the lines using that key and review their meaning. A technically correct new value can still change intimacy, status or what a speaker appears to know. Use the forms-of-address or office-style tools when those story relationships need their own rules; do not ask a generic name slot to infer them.

The final creative test is a player choice that remains a name, a sentence that says what its author intended and a report honest about what was supplied. Literal substitution is a small mechanism. Its value comes from making assumptions visible before a chosen name is blamed for them.

Can the tool infer a pronoun from the chosen name?

No. Supply the exact forms the line needs, or author a sentence that does not need them. A familiar-looking name is not a declared pronoun, title or grammatical instruction. The same rule applies to each locale independently.

Why does en-US not use my en forms?

Locale labels match exactly and there is no implicit fallback. Decide which variants are equivalent in your project and supply their data deliberately. A name-only line can render without locale forms, while a line using a missing key stays unresolved.

Will braces in a player name execute another token?

Inserted values are concatenated as literal text and are not parsed again. A name that contains {{subject}} retains those characters. The website’s preview behavior does not certify the separate rendering contract of an exported game integration.

Does every resolved line have correct grammar?

Resolved means every supported slot had an explicit value. The authored prose, relationship register and plot context still need review. No morphology, translation or culture check is inferred from successful string substitution.