Proposal: Automated Flow for Abstracting/Localising Speaker Names #92
Description
It is common for users to want to abstract away speaker names, either to reveal them as the player character learns the speaker's name, or to localise the name, or some other reason. But it's not the most pleasant thing to do while writing - of course it's far easier to write:
Gary: hello
than
{$GARY_SPEAKER_NAME}: hello
or similar. Attempting to do the latter is annoying, and likely more prone to errors. So I was thinking about how line IDs are added to the file for you, and thinking we could do something similar.
Imagine that there is some inspector button or something, similar to the "Add Line ID Tags" button. And it goes through all your yarn files in the current project or whatever scope, and finds all the speakers. It generates a potential variable name to replace each with, or maybe you can even provide a format string for generating the variable name from the speaker name. It then shows you a popup with every detected speaker name and the generated variable name for each, so you can manually edit any which you'd prefer had a different name, which actually represent the same person called a different thing over time, or where a stray colon has resulted in dialogue being mis-identified as a speaker. You then confirm when it looks right, and the utility does two things:
- Replaces every speaker name in your Yarn scripts with an interpolated variable of the corresponding speaker key.
- Creates (or updates) a loc table where the keys are mapped to speaker names, storing the original script values in the column for the base loc.
This is a destructive action, akin to - but definitely more dramatic than - the Add Line IDs functionality. But if it is done correctly, the result of running the script before and after using the utility would be the same. It would assist with localisation and good abstraction practices, and do away with work that people are currently doing manually.
I have been giving some thought to how we would solve the related problem of interpolated variable text needing to be localised, but I've not yet thought of a good enough flow. But I'd be curious for the sake of either use case: is there is a material difference in performance if we were to significantly increase the number of potential loc table lookups required to construct a single line of dialogue at runtime?