The oops dialog needs to evaluate variables.
Test case Dakar: https://develop.twiki.org/do/oops/Sandbox/TestTopic2?template=oopssaveerr;param1=test+link+to+%TOPIC%+of+%WIKITOOLNAME%
Test case Cairo: http://twiki.org/cgi-bin/oops/Sandbox/SandBox02?template=oopssaveerr;param1=test+link+to+%TOPIC%+of+%WIKITOOLNAME%
This is a Cairo/Dakar incompatibility. For example, the latest BlackListPlugin generates an incomprehensible oops message because the variables are not evaluated:
Your IP address %REMOTE_ADDR% is black listed at the %WIKITOOLNAME% web site due to excessive access or suspicious activities. Please contact site administrator %WIKIWEBMASTER% if you got on the list by mistake.
evaluate variables, of course. But the order is such that it instantiates parameters after
expanding variables. Since your variables are in parameters, they don't get expanded. The reasoning behind this was that parameters to oops should always be nouns, and never sentences of error messages, due to the internationalisation problems this causes.
In the case of BlackListPlugin
it ought to define an oops template for the messages it wants to output, rather than hard-coding an English-only message.
To handle this correctly, you actually need a second call to variable expansion, so they are expanded both before and after parameter instantiation.
Thanks Crawford for fixing this.
Regarding hard-coding an English-only message, au contraire, the parameterized oops template is done for flexibility. The plugin uses only one oops template and fills it dynamically with one of two different messages based on plugins variables. That is, there is no need to ssh to the server to change the message.