Here’s one problem that arises from the way Inform does things:
[code]Enigma is a room.
A cipher is a kind of thing. A cipher can be one-time, Caesar, or public-key (this is its cryptotype property). Understand the cryptotype property as describing a cipher.
Before printing the name of a cipher: say "[cryptotype] ".
One one-time cipher and one Caesar cipher are in Enigma.[/code]
(This took an embarrassingly long time to get compiled and working, BTW.)
Output:
PrefaceByArticle (or whatever is doing it) looks ahead at “one-time cipher,” sees that it starts with an “o,” and guesses wrongly that the indirect article should be “an.” Unlike with the unicorn and the hourglass, you can’t just set the indirect article of ciphers directly (well, in this case, every cipher should have “a,” but that won’t generalize). I guess in a case where you do know exactly which element is going to come after the indirect article you could do something like this:
[code]Enigma is a room.
A cipher is a kind of thing. A cipher can be one-time, Caesar, open-woffle, or public-key (this is its cryptotype property). Understand the cryptotype property as describing a cipher.
Before printing the name of a cipher: say "[cryptotype] ".
One one-time cipher, one open-woffle cipher, and one Caesar cipher are in Enigma.
The indefinite article of a cipher is usually “a[if the item described is open-woffle]n[end if]”.
A room has a cryptotype.[/code]
…you have to give a room a cryptotype to avoid this bug. (Also open-woffle isn’t a real thing, I got tired of looking up types of ciphers.)
But if it’s not entirely predictable which property is going to get printed first when you print the name of something, this won’t work. The code I’m working on allows for some more sophisticated and customizable ways of figuring out which article to use but as I said it doesn’t play nicely with the places where Inform uses indirect articles.
So I’d really like to figure out what Inform is doing by default, but that code does seem unusually opaque.
…OK, winkling through it there does ultimately seem to be a call to LanguageContraction in Language.i6t, which checks whether the letter in question is aeiouAEIOU. If I could figure out a way to have that call an I7 phrase instead I might be able to avoid a lot of the machinery I’ve been trying to use.