Page MenuHomePhabricator

Nesting templates lead to excess whitespace
Open, LowPublic

Description

Parser test showing the problem and the expected output

Some wikitext constructions depend on whether we are at the start of a line, or not. This is tracked using a flag called lineStart. However, the parser preprocessor loses track of this flag when a nested template is used.

See http://test.wikipedia.org/wiki/Line-start_flag_lost_when_nesting_templates – it uses {{Top-level template}}, which is only a call to {{Subtemplate}}. The parser thinks the list contained in {{Subtemplate}} is not at the line start (even though it is, in fact), so that (according to bug 529 behavior) it prepends a newline, which appears as a redundant paragraph on output.

If {{subtemplate}} is called directly, the paragraph disappears, and the output is correct.

See the attached parser test.


Version: unspecified
Severity: normal
URL: http://test.wikipedia.org/wiki/Line-start_flag_lost_when_nesting_templates

Attached:

Details

Reference
bz16700

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz16700.
bzimport added a subscriber: Unknown Object (MLST).
Mormegil created this task.Dec 18 2008, 6:19 PM

Created attachment 5595
Patch solving the bug

My guess of the problem cause and an offered fix (I am not completely self-confident in parser/preprocessor code, though).

Attached:

+need-review

(In reply to comment #3)

Please confirm:
http://translatewiki.net/w/i.php?title=Sandbox&oldid=2901073

Actually, not at all, it just seems somebody broke the parser big time. Currently, numbered lists inside tables are just broken completely. See http://translatewiki.net/w/i.php?title=Sandbox&oldid=2901174

(And it did not help in the general case, either, it just seems like that at first sight. Check http://test.wikipedia.org/wiki/Line-start_flag_lost_when_nesting_templates for a numbered example, where the problem would still be obvious.

Yep. That is fixed in r86064.

Translatewiki just updated. Everything looks fine. For a some weird reason the parser test is still broken, evn though the output is fine. http://translatewiki.net/wiki/Sandbox

(In reply to comment #6)

Translatewiki just updated. Everything looks fine. For a some weird reason the
parser test is still broken, evn though the output is fine.

It does not look fine at all (see http://translatewiki.net/wiki/Sandbox#Without_tables_because_of_the_currently_broken_parser). It just got worse in a more strange way, see http://translatewiki.net/wiki/Sandbox#Even_more_broken

Ok, sorry for the false alarm.
Could you have a look again now?

(In reply to comment #8)

Could you have a look again now?

Yep, it looks better now (if it didn’t break something else ;-) ).

I'll close it & will keep an eye on possible side effects.

dasch wrote:

For side effects check bug 30384

kaldari reopened this task as Open.May 1 2017, 12:25 AM
kaldari added a subscriber: kaldari.

It looks like this bug is active again since rSVN86072 was reverted by rSVN96887. Anomie offered some suggestions for fixing it at T14974#3224585.

FYI, it looks like all the infoboxes on English Wikipedia work around this bug by using actual table HTML tags rather than Wikitext table markup.

This bug is quite annoying for Lua wrapper templates, because they inevitably use nesting. I will be very pleased if this gets fixed.

Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptMar 11 2019, 5:13 PM