Author: webboy
Description:
When viewing templates the parsing order is:
When including templates in pages the parsing order is:
This is inconsistent and I think it should be changed.
Version: 1.16.x
Severity: normal
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.
webboy wrote:
(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:
When including templates in pages the parsing order is:
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>5Expected result on template page and page calling template:
12<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>45Result 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:
(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:
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 + .)
richardg_uk wrote:
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.