Last modified: 2014-11-17 10:35:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 529 - Templates inside of tables appear incorrectly
Templates inside of tables appear incorrectly
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
1.3.x
All All
: High major with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Template...
: parser
: 540 (view as bug list)
Depends on:
Blocks: 12974
  Show dependency treegraph
 
Reported: 2004-09-19 14:29 UTC by Erdal Ronahi
Modified: 2014-11-17 10:35 UTC (History)
11 users (show)

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


Attachments

Description Erdal Ronahi 2004-09-19 14:29:22 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.
Comment 1 JeLuF 2004-09-19 17:48:13 UTC
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.
Comment 2 JeLuF 2004-09-20 05:36:54 UTC
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
Comment 3 JeLuF 2004-09-20 16:38:56 UTC
*** Bug 540 has been marked as a duplicate of this bug. ***
Comment 4 Leah 2004-09-20 17:18:13 UTC
(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.
Comment 5 Timwi 2004-09-20 17:19:37 UTC
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.
Comment 6 Brion Vibber 2004-09-20 17:37:34 UTC
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.
Comment 7 Leah 2004-09-20 17:44:11 UTC
(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 ''...'').
Comment 8 JeLuF 2004-09-20 17:45:40 UTC
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.
Comment 9 Leah 2004-09-20 17:53:56 UTC
(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?
Comment 10 Leah 2004-09-20 18:10:01 UTC
Incidentally, are there good reasons why {| and |} may only appear at the
beginning of lines?
Comment 11 Wil Mahan 2004-09-20 22:14:21 UTC
(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.
Comment 12 Wil Mahan 2004-09-22 17:25:32 UTC
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.
Comment 13 Wil Mahan 2004-09-25 05:20:53 UTC
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 '*'
Comment 14 Brion Vibber 2004-12-11 23:22:37 UTC
1.4 release imminent, marking as fixed.
Comment 15 Christian Neubauer 2008-02-14 15:31:33 UTC
This fix causes bug 12974.
Comment 16 Mormegil 2008-11-12 21:15:44 UTC
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.
Comment 17 Siebrand Mazeland 2009-04-25 11:11:23 UTC
Reopening. Blocks bug 12974.
Comment 18 Mike.lifeguard 2009-05-29 00:47:18 UTC
removed deprecated keyword fixed-in-cvs
Comment 19 Felix Pahl 2010-04-16 06:11:57 UTC
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.
Comment 20 Felix Pahl 2010-04-16 06:17:37 UTC
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.
Comment 21 Happy-melon 2011-01-15 14:25:20 UTC
(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.
Comment 22 Felix Pahl 2011-01-15 14:50:37 UTC
(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.
Comment 23 Happy-melon 2011-01-15 16:20:46 UTC
(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.
Comment 24 Felix Pahl 2011-01-15 16:36:55 UTC
(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 :-)
Comment 25 Happy-melon 2011-01-17 10:37:42 UTC
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.
Comment 26 Krinkle 2011-01-26 01:29:47 UTC
Reverted in r81012.

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


Navigation
Links