jeluf wrote:

The code on that page was:
{|

with template and onemore being templates containing tables.

Which is equivalent with:

{|

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.

jeluf wrote:

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

jeluf wrote:

*** Bug 540 has been marked as a duplicate of this bug. ***

qleah wrote:

(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.

timwi wrote:

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.

qleah wrote:

(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 ''...'').

jeluf wrote:

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.

qleah wrote:

(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?

qleah wrote:

Incidentally, are there good reasons why {| and |} may only appear at the
beginning of lines?

wmahan_04 wrote:

(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.

wmahan_04 wrote:

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}}
• 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.

wmahan_04 wrote:

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.

mike.lifeguard+bugs wrote:

removed deprecated keyword fixed-in-cvs

fpahl wrote:

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.

fpahl wrote:

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.

happy.melon.wiki wrote:

(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.

fpahl wrote:

(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.

happy.melon.wiki wrote:

(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|

}}bar

You'll see that in the output the table start has been moved onto a new line.

fpahl wrote:

(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 :-)

happy.melon.wiki wrote:

Resolved in r80430. The first line of a wikitable cell is now treated as a linestart context, so structures like

{|

Will all work, and regardless of whether they were added via a template or directly.

Reverted in r81012.

Change 803343 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/services/parsoid@master] WIP: Implement T2529 for Parsoid's standaone test mode

https://gerrit.wikimedia.org/r/803343

Change 803343 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/services/parsoid@master] Implement T2529 sol-nl hack in Parsoid's native template expansion path

https://gerrit.wikimedia.org/r/803343

Change 803343 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Implement T2529 sol-nl hack in Parsoid's native template expansion path

https://gerrit.wikimedia.org/r/803343

Change 979412 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/services/parsoid@master] WIP: Fix buggy T2529 handling

https://gerrit.wikimedia.org/r/979412

For folks chasing links, see also T14974 which registers some discontent with the state of the world post-T2529, but in the two decades since we've never "fixed" T14974 which seems to show that the compromise of T2529, although imperfect, has merit.