Last modified: 2010-12-03 00:12:36 UTC
User Volker Wulf (in message "wikisyntax in text attribute") tried to disable parsing in string using <nowiki> tag and reported "funny characters when I ask". I reproduced for Type:String. I found the annotation [[String test::<nowiki>Don't parse this [[Test relation::Sandbox2]], what happens?]] * Displays the exact text in the page (good!). * Displays "UNIQ4771b2c964a25267-nowiki-0000001C-QINU" in inline queries. * Displays garbled wiki markup instead of the magnifying glass in the factbox (bad). It was hard to get MediaWiki to parse wiki markup in strings for SMW 1.0, now it's hard to turn it off! There's undoubtedly some tricky way to use markup or HTML to disable parsing but it won't be easy for naive users or automatically-generated semantic annotation to apply it. SMW could provide a different datatype for unparsed text, e.g. Type:Unparsed_string, or a special Property:DontParse that you put on certain properties. Neither is attractive.
The problem here is once more the order of text processing in MediaWiki. MediaWiki strips out <nowiki>-blocks and inserts placeholder strings UNIQ... instead. It would be possible to expand the UNIQ... placeholders (and the MediaWiki parser does that later on anyway, which is why the page displays properly), but I think we cannot find out how the UNIQ... part was generated (i.e. the orignial user input is lost). Various tags are handled in a similar fashion, including HTML comments and <math> blocks. It would also be hard to have a datatype for un-parsed strings, since MediaWiki parses (and escapes) strings before SMW even looks for annotations. The only option would be to hook into MediaWiki at some earlier stage, creating extra load and possibly breaking template compatibility. I do not know how to solve that problem. But a simple workaround would be to omit <nowiki> and to use other escapes for wiki markup instead (e.g. by using hex encoding for "["). I agree that Type:Text should probably do something to expand UNIQ... before storing the result (but then how would we get that expanded text back into a wiki page, without having special markup escaped?).
At leat we now catch this case properly and raise a generic error. No more mess in Factbox or elsewhere.
This is causing problems for some work that I'm doing (I'd like to be able to put tag extensions in property values). What's wrong with just expanding out the strip markers with $wgParser->unstripAll() in the assignment? Is Semantic MediaWiki supposed to store the original wikitext in the database, or the formatted HTML?
