Twine: should passage names be included in the dictionary?

[H Labrande]

The title says it all.

Pros: - we can decide to leave them all alone or change all their names easily that way - if your game glues two twine html files into one (to provide a language selection menu for the player for instance), you can do that without being afraid the passages intertwine (ha) by mistake ; you'll just have two independent trees with disjoint passagenames

Cons: - requires looking in the html tags and searching for tiddler="passage" everywhere - requires detecting <<display "passage">> - requires detecting the shorthand <<passage>> (too hard??)

Might have to think more about that...

[H Labrande]

Actually, is the second pro a void concern? Our script works on HTML generated by Twine, hence on one game generated once, to make another HTML with the other game. So the passage names don't even have to be different, because it's two different files ; and they probably won't be glued together because each embeds TiddlyWiki and other parts that are supposed to be defined only once. The menu selection would have to be a simple HTML file that directs you to the correct Twine file. (But then if you do that, you can't really have dynamic language selection: the player chooses a language and can't change mid-way to another language. Which might be a concern or a nice feature to have for some. But this is not really fixable given the concept of the script, so it's a limitation I guess. And who knows maybe you can get around it by dropping a cookie in the browser that'll get recovered and parsed by the other file.)

So, void?

[H Labrande]

Detecting all passage names and replacing them sounds like a bigger headache than it's worth, because of the multiple cases and basically having to write a tiddlywiki interpreter.

If the user really wants to translate her passage names, she can get a dump of the passage names by uncommenting the "print(listOfPassages)" line (currently line 198) and use a search+replace feature on a text editor.