Permission to geek, sir: This is electrifying my engineering brain in a massive way. I've been thinking on how one could handle localization for Ink in a more complete, language safe way. Are y'all doing anything like how shader variants work?
Permission to geek, sir: This is electrifying my engineering brain in a massive way. I've been thinking on how one could handle localization for Ink in a more complete, language safe way. Are y'all doing anything like how shader variants work?
I'm afraid I don't know how shaders work. But, I think it probably *could* be used for localisation as well; with the caveat that it'd be better if we could do in a way that somehow preserved more of the original context if you wanted to see it, so localisers could "test" translations as they go
I'm imagining a tree structure hidden under what looks like a simple spreadsheet interface. At any point, you might click a cell and say "give me the flow to this point" and it can spit out the text that led up to this moment. But when it's not needed, it's invisible.
relatedly - ten years ago we made inklewriter, a web-UI for writing basic branching stories. It had a few neat tricks, one of which was that if you clicked a node in the (list-format) index, it would flow the story to that point so you could see it in context, via a smallest-move from where you were
so although nodes were atomic units, it was impossible to see them out of some kind of context
Yeah, I remember playing with Inklewriter a bit. I'm a systems / networking programmer, so I don't touch many shaders myself, but I know the fundamentals: the system calculates the different permutations of the shader settings, and builds them separately.
I imagine you could do (or are doing) the same thing with a tree structure and an ink script: each possible text choice is a separate limb or twig, and the "address" of the node is just the full list of choices it took you to get there.
Great, now I'll be thinking about this the rest of the afternoon. Lol