On Freitag, 16. Mai 2008, Robert Murphy wrote: > Dear Developers, > > I have successfully installed the Poem extension > (http://www.mediawiki.org/wiki/Extension_talk:Poem) on my wiki and it > has been running fine. However, I just discovered too faults with it, > that I now think may be due to Semantic MediaWiki. > > First, on the talk pages of custom namespaces, use of the <poem> tag > makes the error > UNIQ583c33685170dbcd-poem-00000000-QINU > (for an example, see > http://reformedword.org/index.php?title=Greek_talk:Genesis/13&oldid=423322) >. > > Second, it makes the factbox right after the </poem>, in the middle of > the page, and the values aren't on the page's main factbox, at the > bottom. (see http://reformedword.org/Greek:Psalm/119). > > While I know some PHP, I don't know the mediawiki framework well > enough to know why either of these might be. I posed this question on > the extension's page on mediawiki.org and got no reply. I wrote on > the talk page of Poem's creator > (http://en.wikipedia.org/wiki/User:Nikola_Smolenski) and he suggested > I contact Steve Sanberg (http://en.wikipedia.org/wiki/User:Sanbeg). > His reply was: > > The UNIQ.. problem seems to be unrelated to the poem extension. > Basically, the preprocessor hides XML-style tags with strings like > that to prevent them from being treated as wikitext, then unhides them > later on; something in the state of your parser must be getting messed > up. I looked at your wiki, and I get the same result with poem, cite > and nowiki. It's probably best to try disabling some extensions to see > which one is causing that. I'm not sure about semantic mediawiki; I'd > guess that it's using the wrong hook to detect when the page is ends, > so the recursive parse triggers the fact box. That sounds like a bug > in semantic mediawiki. -Steve Sanbeg (talk) 15:23, 15 May 2008 (UTC) > > I've disabled Cite to no avail. Now I can accept that the talk_page > problem might be mine alone, but the factboxes (pl.) in the middle of > the pages seems like a SMW error.
The whole thing is due to the way MediaWiki works, and one cannot really blame either SMW or Poem here. MediaWiki replaces certain parts of input text with that "UNIQ..." stuff. This happens *before* any extension gets to see the code -- i.e. extensions do not know what was there before (at least I do not know how, and in any case it this stuff usually cannot be understood as normal wiki text). Not only poem, but also <!--...-->, <math>, and <nowiki> are examples for that. See also bug 13011 <https://bugzilla.wikimedia.org/show_bug.cgi?id=13011> One way to improve the situation might be to have a parser function {{#poem:... instead of a parser hook <poem> (similar to our #ask that replaced <ask>). It is really the way in which MW processes <parserhooks> that creates problems here. Parser functions return not UNIQ... but normal wiki code, and that would be workable input for SMW. The other stuff (Factbox in page) happens for other reasons. The problem is that SMW uses MW hooks during parsing, i.e. functions that the parser triggers when parsing wiki articles. Unfortunately, MediaWiki uses more than one parser, and any hook in the parser code is used by all of those. Thus, whenever MediaWiki uses a second parser for some part of text, SMW will do the same as if this text was the only input. I know of no way of detecting whether SMW runs in a subparser or in the "real" parser. Normally, however, subparsers are triggered before or after the main page was parsed, and no semantic data is found then -- thus the Factbox is empty and remains hidden. You can try __NOFACTBOX__ to not display the Factbox, or you can check whether it suffices to avoid semantic annotations in certain environments. -- Markus -- Markus Krötzsch Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 [EMAIL PROTECTED] www http://korrekt.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
