Last modified: 2012-09-16 09:15:04 UTC
When viewing templates the parsing order is: - nowiki - onlyinclude, noinclude, includeonly When including templates in pages the parsing order is: - onlyinclude, noinclude, includeonly - nowiki This is inconsistent and I think it should be changed.
Parsing nowiki later than noinclude is very counterintuitive and makes writing code examples with noinclude/onlyinclude on template documentation subpages rather complicated.
This has been FIXED with the introduction of the new preprocessor. All tags are now parsed in the same pass, so the outermost tag is now always the most significant.
(In reply to comment #2) > This has been FIXED with the introduction of the new preprocessor. All tags are > now parsed in the same pass, so the outermost tag is now always the most > significant. On Wikipedia (1.16alpha-wmf (r59214)) this has only been fixed for noinclude and includeonly. onlyinclude is still passed in the wrong order: When viewing templates the parsing order is: - nowiki - onlyinclude When including templates in pages the parsing order is: - onlyinclude - nowiki I don't have a MediaWiki installation now to test this for SVN HEAD. Test case: Template code: 1<nowiki>2<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>4</nowiki>5 Expected result on template page and page calling template: 12<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>45 Result on template page is OK. Result on page calling template: 3nowiki -> onlyinclude (with nowiki -> onlyinclude in bold)
(In reply to comment #3) > Test case: > Template code: > 1<nowiki>2<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>4</nowiki>5 > > Expected result on template page and page calling template: > 12<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>45 > > Result on template page is OK. > > Result on page calling template: > 3nowiki -> onlyinclude (with nowiki -> onlyinclude in bold) > Frankly, I think onlyinclude is a quite strange feature, working a bit different from the other tags. As I understand it, Foo<onlyinclude>Bar</onlyinclude>Baz is supposed to work similar to <noinclude>Foo</noinclude>Bar<noinclude>Baz</noinclude> So your test case would translate to <noinclude>1<nowiki>2</noinclude>3'''nowiki -> onlyinclude'''<noinclude>4</nowiki>5</noinclude> which renders as 3nowiki -> onlyinclude when included, so the result you mention actually seems to be the expected output.
(In reply to comment #4) > Frankly, I think onlyinclude is a quite strange feature, working a bit > different from the other tags. As I understand it, > > Foo<onlyinclude>Bar</onlyinclude>Baz > > is supposed to work similar to > > <noinclude>Foo</noinclude>Bar<noinclude>Baz</noinclude> > > So your test case would translate to > > <noinclude>1<nowiki>2</noinclude>3'''nowiki -> > onlyinclude'''<noinclude>4</nowiki>5</noinclude> > > which renders as > > 3nowiki -> onlyinclude > > when included, so the result you mention actually seems to be the expected > output. > I think this argument is wrong for two reasons. First, the onlyinclude tag is inside a nowiki tag; stuff in nowiki tags should not be parsed ever, the parser should leave it alone completely. Second, the 'translation' you give is flawed, as it misnests noinclude and nowiki tags. The parser has to make sense out of that tag soup, which kind of defeats your point.
(In reply to comment #5) > I think this argument is wrong for two reasons. First, the onlyinclude tag is > inside a nowiki tag; stuff in nowiki tags should not be parsed ever, the parser > should leave it alone completely. Second, the 'translation' you give is flawed, > as it misnests noinclude and nowiki tags. The parser has to make sense out of > that tag soup, which kind of defeats your point. > It wasn't really meant as an argument, rather as a descrtiption of the status quo. If I had to choose, I would rather drop the feature completely, than change the functionality of it once more, just to make preprocessing even more complicated
The terminology in the bug summary is incorrect for the 1.12 parser. I went to a lot of trouble to simulate the 1.11 handling of onlyinclude as closely as possible in the 1.12 parser, to maintain backwards compatibility. If you call that behaviour a bug then so be it. But the problem is not "parse order" since onlyinclude is processed at the same time as nowiki. It could be described as precedence. See the awkward handling of onlyinclude here: http://www.mediawiki.org/wiki/Preprocessor_ABNF
(In reply to comment #7) > The terminology in the bug summary is incorrect for the 1.12 parser. I went to > a lot of trouble to simulate the 1.11 handling of onlyinclude as closely as > possible in the 1.12 parser, to maintain backwards compatibility. If you call > that behaviour a bug then so be it. But the problem is not "parse order" since > onlyinclude is processed at the same time as nowiki. It could be described as > precedence. See the awkward handling of onlyinclude here: > > http://www.mediawiki.org/wiki/Preprocessor_ABNF > Slightly less technical translation of this comment and the details at the link: onlyinclude has a higher precedence than everything else, which explains the behavior in inclusion mode. However, in non-inclusion mode, the parser doesn't look for or recognize onlyinclude tags; they're not recognized as anything special and are treated as literal text. (For completeness, an explanation of what precedence means: the parser will prefer to interpret things with a high precedence over things with a low precedence. The classic example is that 3+4*5 equals 23 because * has a higher precedence than + .)
*** Bug 24546 has been marked as a duplicate of this bug. ***
This an ongoing problem (1.19+): http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#VPT_not_showing_up_at_VPALL The parse order is inconsistent and unintuitive.
Same for html comments. onlyinclude tags on inclusion are handled before the html comments, which makes the onlyinclude acts like includeonly.
