One possibility would have been to use any one of a number of languages for high-level GUI scripting, eg. HyperCard or AmigaVision. However, these are all defined for a very specific user interface: monitor and speaker for output, mouse and keyboard for input, nothing else. Syntax is strictly defined and immutable, the only extension mechanism is invoking external programs. Most traditional command line scripting languages (the UNIX sh family, MS-DOS batch files, etc) also fit into this paradigm, they just restrict their interfaces even further to just keyboard and console.
The way to break free from all externally imposed limitations is to roll your own with a low-level programming language like Java, Perl or C. The fastest and most common way is to integrate the script logic directly into the user interface, but with more complex scripts -- the translator's entire suite is thousands of lines long -- this rapidly becomes a nightmare to debug and maintain, as the script logic is intertwined with the interface logic.
So I wrote a quick abstraction layer in Java that allowed my program to parse menus written in a rapidly evolving custom language dubbed "YakScript", an obscure pun on the Japanese word for translating machine, tsuuyakki. This worked well for a while, but as the language's complexity increased, the separation between logic and interface became less and less clear. After considering the situation, I abstracted the language's commands themselves into their own classes and reworked the interpreter core to handle them dynamically... and only then did I realize that I had just created a general-purpose interface construction language!