This is a problem in various situations, not just for the case of markup (there
is a related issue with Type:Email). Currently, inline queries return plain HTML
code, which is probably not the right solution.

We could change the behaviour to make all formatters return wiki text, which is
finally sent to a parser. The downside would be that the parser does extra work
such as checking for the existence of articles that we already know to exist.
Another solution would be to make small parses for every returned data value.
Finally, we could endow the SMWDatavalue container with extra methods for
returing HTML versions of all outputs, and the SMWDatavalue object could handle
that issue. I will think about those possibilities ...

info wrote:

Links in wiki text also don't appear in inline queries. [[String test:=tastes like [[chicken]] ]] used to be forbidden (the rule was "no double closing brackets in strings"). Now that bug 9129 is fixed, the [[chicken]] part of the string displays as a link fine in text and the factbox; it's only in inline queries you see the brackets around chicken instead of a link.

Markus, maybe we could make users be explicit, and have two kinds of strings, type:UnparsedString and type:WikiMarkup (and two kinds of type:text and two kinds of type:enumeration... ugh). It seems more in the spirit of MediaWiki to just have all strings always parsed as wiki text (much like this wacky bug form treats text as wiki text) and make people use nowiki and such to turn it off.

If <ask> is made available as a parser function, all would be parsed anyway, and this bug would just go away. The main headache I have are the large amounts of wiki-links a query result might contain. All of those links would be parsed (again) by MediaWiki, creating many many useless queries to the DB. Right now none of the links in query results creates an extra DB lookup. Maybe we can fill the link cache of MW artificially with the data that we already have.

The #ask parser function is now available and solves this problem.