Last modified: 2014-11-17 10:35:53 UTC
This problem newly appeared today. If templates containing tables appear inside of tables, they are incorrectly rendered. Nothing has been changed on this and similar pages where the problem occurs.
The code on that page was: {| |{{template}} |- |{{onemore}} |} with template and onemore being templates containing tables. Which is equivalent with: {| |{| |code from template |} |- |{| |code from onemore |} |} which produces the same broken output. "Correct" input would be {| | {{template}} |- | {{onemore}} |} since subtables have to start at the beginning of a new line. It was a bug that this worked before ... I'll check how many pages are affected.
It's a language construct that is not widely used. 2 on ku:, 21 on de:, all of them fixed. On en:, I've seen 3 or 4. The workaround is easy, just add a newline. The patch to make this work would be big and ugly. => WONTFIX
*** Bug 540 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > It's a language construct that is not widely used. 2 on ku:, 21 on de:, all of > them fixed. On en:, I've seen 3 or 4. The workaround is easy, just add a > newline. The patch to make this work would be big and ugly. => WONTFIX This is not language-specific. It affects any table which includes a template containing a table.
By "language construct" he was referring to the wiki language, not spoken languages. And please read all of the above. It does not affect any table which includes a template containing a table. You just have to put the template token on a new line. That's all.
The fix being ugly isn't a good reason to mark a bug as WONTFIX. Yes, there's a workaround, but it oughtn't to be necessary.
(In reply to comment #5) > By "language construct" he was referring to the wiki language, not spoken languages. > > And please read all of the above. It does not affect any table which includes a > template containing a table. You just have to put the template token on a new > line. That's all. Oughtn't it be simple for the parser to add a newline before {| occurring at the beginning of a template? The parser already correctly handles apostrophes at the ends of templates; i.e., '{{italic}}text''' renders as '<i>...</i>text, not <b>...text</b> (assuming Template:Italic contains ''...'').
The fix being ugly is not the main reason to close it, but as performance is an issue, we should not add unneeded complexity to the code. - It's not documented that this will work. Every example of table syntax shows that subtables have to start on a new line. Templates are just inserted wiki text. - There is a workaround. Just add a single newline. Like you would have to do if you wouldn't use templates but plain wiki table markup.
(In reply to comment #8) > The fix being ugly is not the main reason to close it, but as performance > is an issue, we should not add unneeded complexity to the code. > > - It's not documented that this will work. Every example of table syntax > shows that subtables have to start on a new line. Templates are just > inserted wiki text. > > - There is a workaround. Just add a single newline. Like you would have > to do if you wouldn't use templates but plain wiki table markup. One might argue that the entire wiki table syntax is "unneeded complexity", especially because it is buggy. See [[en:Template_messages]]. How is the user to know which of these templates must appear on a newline, without looking at their contents?
Incidentally, are there good reasons why {| and |} may only appear at the beginning of lines?
(In reply to comment #7) > the ends of templates; i.e., '{{italic}}text''' renders as '<i>...</i>text, not > <b>...text</b> (assuming Template:Italic contains ''...''). Actually, it does render as <b>italic<i>text</i></b><i></i> now that my patch to bug 60 has been applied. That's the reason this bug arose.
Supposing that we want to fix this, what are the realistic options? 1. The simplest solution would be to insert a newline before every template. I guess this would lead to unwanted spaces in some situations. It would break something like * {{template_list_item}} 2. As Leah suggested, it would be possible to check for {| at the beginning of a template. My concern is that this is not general enough; I think we would also need to check for *, :, #, and maybe even section headings at the beginning of templates, as well as anything else that depends on starting at the beginning of the line. 3. It should be possible to insert a special delimiter at the beginning of each template that gets removed before the final output, a la Kate's fix to bug 266. This is more complex.
Should be fixed in HEAD. A newline is now prepended to a template if 1) one isn't already present 2) the template begins with '{|', ':', ';', '#', or '*'
1.4 release imminent, marking as fixed.
This fix causes bug 12974.
Yep, this change breaks stuff. Remember that this code applies not only to templates, but also to parser functions. The fact that a parser function output begins with a semicolon definitely does not mean that a <dl> was intended. See bug 12974 and http://test.wikipedia.org/wiki/Newline_through_parser_functions I tend to agree with JeLuF’s comment #8 here – if some syntax feature works only at the beginning of a line, it is the responsibility of the person who wrote the syntax feature to ensure that it is really at the beginning of a line. If you are writing a template, add a newline on its top, declare its proper usage in the documentation, or whatever. Anyway: while I believe this feature/fix/… should be removed again, but I believe a compromise is possible: To add the newline only for the table syntax (not for ':', ';', '#', or '*'). Table syntax is rare in other uses than tables (while colons and semicolons are perfectly normal in plain text), and tables seem to be the primary use case for this bug/fix.
Reopening. Blocks bug 12974.
removed deprecated keyword fixed-in-cvs
A comment that might speak for changing or at least prominently documenting this: I just wrote a MediaWiki template expander in Java -- when I was done implementing all the features I needed, I tested it on a real-life example that uses lots of nested templates (http://fr.wiktionary.org/wiki/Annexe:Conjugaison_française:abaisser) and compared the result with the raw expanded output (http://fr.wiktionary.org/w/index.php?title=Annexe:Conjugaison_française:abaisser&action=raw&templates=expand). Everything was exactly right, including all whitespace, except that I seemed to be missing a newline at the very beginning, and I couldn't figure out where that was supposed to be coming from. The time it cost me to dig into the source code and bug reports to get to the bottom of this one discrepancy was quite a significant fraction of the total time I spent writing the expander. I still haven't found anything outside source code and bug reports that documents this behaviour.
BTW, the problem is slightly compounded by the fact that the special template expansion pages (http://meta.wikimedia.org/wiki/Special:ExpandTemplates, http://fr.wiktionary.org/wiki/Spécial:ExpansionDesModèles) *don't* produce this newline.
(In reply to comment #20) > BTW, the problem is slightly compounded by the fact that the special template > expansion pages (http://meta.wikimedia.org/wiki/Special:ExpandTemplates, > http://fr.wiktionary.org/wiki/Spécial:ExpansionDesModèles) *don't* produce this > newline. I don't believe this is the case, on 1.16-wmf4 at least.
(In reply to comment #21) > (In reply to comment #20) > > BTW, the problem is slightly compounded by the fact that the special template > > expansion pages (http://meta.wikimedia.org/wiki/Special:ExpandTemplates, > > http://fr.wiktionary.org/wiki/Spécial:ExpansionDesModèles) *don't* produce this > > newline. > > I don't believe this is the case, on 1.16-wmf4 at least. I disagree -- this can be reproduced as follows: Go to http://fr.wiktionary.org/w/index.php?title=Annexe:Conjugaison_française:abaisser&action=edit and copy the content of that page (a template call). Go to http://fr.wiktionary.org/wiki/Spécial:ExpansionDesModèles, paste the page content into the text area and click "OK". You get the expansion of the template, without a newline at the top. Now go to http://fr.wiktionary.org/w/index.php?title=Annexe:Conjugaison_française:abaisser&action=raw&templates=expand. You get the same expansion, but with a newline at the top. The HTML source on that site has the meta tag <meta name="generator" content="MediaWiki 1.16wmf4" />, so it seems to be using the version you mentioned.
(In reply to comment #22) > Now go to > http://fr.wiktionary.org/w/index.php?title=Annexe:Conjugaison_française:abaisser&action=raw&templates=expand. > You get the same expansion, but with a newline at the top. Leading whitespace is probably trimmed from the ExpandTemplates output, but the newline is added. Try expanding Foo{{fr-conj-1|abaiss| |'=oui |pron=a.bɛ |pc=s }}bar You'll see that in the output the table start has been moved onto a new line.
(In reply to comment #23) > (In reply to comment #22) > Leading whitespace is probably trimmed from the ExpandTemplates output, but the > newline is added. Try expanding > > Foo{{fr-conj-1|abaiss| > |'=oui > |pron=a.bɛ > |pc=s > }}bar > > You'll see that in the output the table start has been moved onto a new line. I see. In that case, that seems like a bug in ExpandTemplates -- it's supposed to let you see how templates are expanded; it has no business trimming leading whitespace :-)
Resolved in r80430. The first line of a wikitable cell is now treated as a linestart context, so structures like {| | Foo | * Bar | {| | Look I'm nested! |} |} Will all work, and regardless of whether they were added via a template or directly.
Reverted in r81012.
