Last modified: 2007-12-28 10:54:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T11334, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9334 - wiki text markup in attributes doesn't show in inline queries
wiki text markup in attributes doesn't show in inline queries
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Markus Krötzsch
http://ontoworld.org/wiki/SMW_unit_te...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-19 04:49 UTC by S Page
Modified: 2007-12-28 10:54 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description S Page 2007-03-19 04:49:29 UTC
[[String test:=regular, ''italic'', '''bold''']]
appears with expected formatting in body, expecting formatting in the factbox,
but in an inline query you just see the raw text.

http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ talks about "How do I
render wikitext in my extension?" and suggests calling the parser explicitly. 
Hope this helps :-)

Several users have mentioned other cases where results in inline queries is not
formatted as expected, e.g. bug 7955 and 8047.  They may be related.
Comment 1 Markus Krötzsch 2007-03-24 17:29:54 UTC
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 ...
Comment 2 S Page 2007-08-27 20:43:59 UTC
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.
Comment 3 Markus Krötzsch 2007-09-25 07:45:23 UTC
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.
Comment 4 Markus Krötzsch 2007-12-28 10:54:10 UTC
The #ask parser function is now available and solves this problem.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links