Page MenuHomePhabricator

Wikisource page is unexpectedly listed under "fostered"
Closed, DuplicatePublic

Description

In reviewing pages to try and resolve possible issues related to the parser upgrades,
I found the following on Wikisource :-

https://en.wikisource.org/w/index.php?title=Page:The_forerunners.djvu/77&oldid=6758196

which is transcluded here - https://en.wikisource.org/wiki/The_Forerunners_(Romain_Rolland)/XIV

I removed a spurious <nowiki /> tag from it, but this didn't clear the listing of the page on the Linter errors Special page here : https://en.wikisource.org/wiki/Special:LintErrors/fostered

I'm puzzled that this page should have led to a "fostered content" situation given that the very specific technique used, is what I was advised to use following a lengthy row at English Wikisource. I'm also suprised that it hasn't led to other pages utilising what is essentially the same tactic.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 13 2017, 6:57 PM
ShakespeareFan00 renamed this task from Linter to Unexpected "fostered content" error, for Wikisource page....Apr 13 2017, 6:58 PM
Aklapper renamed this task from Unexpected "fostered content" error, for Wikisource page... to Wikisource page is unexpectedly listed under "fostered".Apr 13 2017, 7:05 PM
Aklapper updated the task description. (Show Details)

I've been wondering (on IRC) if the {{ts|ptb1|fwb}} part on https://en.wikisource.org/w/index.php?title=Page:The_forerunners.djvu/77&action=edit makes it listed as fostered...

It may be that {{nop}} does it, which generates a blank <div></div>, which gets pushed to before the "implied" <table>.

The reasons for the {{nop}} are in effect what gets generated on transclusion is ....

|table item||table item<span class="pagenum">page number><div></div>
|-
|table item||table item

which forces a line break in the parser.

without the <div></div acting as a pusedo line break you get.

|table item||table item|-
|table item||table item

Which the parser compacts down to one line. treating the "|-" as a table item of "-" not a row marker as expected, which understanably mangles the table output on transclusion.

This is unrelated, but is a long-standing limitation in the parser/LST/Proofread page.

The lead {{nop}} bodge would not be needed if the parser and relevant extensions realised it was still inside a table (or by extension a non parent division), when it finished transcluding the previous page. ( Whilst this isn't a big issue for simple tables, I can see it being a possible gotchas for more complex layouts.)

Billinghurst added a subscriber: Billinghurst.EditedApr 13 2017, 11:45 PM

It would appear to be something quirky with Linter extension for that page.

If one moves the table header into the body it disappears. Then noinclude the table header in the body, and error listing recurs.

This is a broadly technique for tables through the WSes, and it is only this page that is spitting out an error. Propose that it is noted for Linter, and ignored for WS.

ShakespeareFan00 added a comment.EditedApr 14 2017, 4:37 PM

As I've now had the same error occur when <noinclude></noinclude> was used on content other than that at Wikisource it would seem Linter has a problem in parsing <noinclude></noinclude> content.

It may be that {{nop}} does it, which generates a blank <div></div>, which gets pushed to before the "implied" <table>.

This is indeed because of the {{nop}} transclusion.

The reasons for the {{nop}} are in effect what gets generated on transclusion is ....

|table item||table item<span class="pagenum">page number><div></div>
|-
|table item||table item

which forces a line break in the parser.
...
... <SNIP> ...

I don't fully understand the bug reported above. Will have to come back to this. But, I will note that a {{nop}} at the end of or after a table cell will not trigger fostering. It is the first {{nop}} immediately after a table is opened and before a table-row is opened that triggers this. So, it looks like you should be able to remove the {{nop}} at the beginning?

Nope, because that breaks the layout when the page is transcluded as I explained.

Okay .. I need to better understand the specifics of what is going on here with " ... a long-standing limitation in the parser/LST/Proofread page ... " This almost looks like that if T14974 also applied to "|-" syntax, you wouldn't need the workaround (of course, over there, some folks are complaining that they *don't* want that line break, so there are some conflicting requirements here). But, okay .. to be continued .. since I don't fully grasp all the nuances here.

There's been at least two rows about this at English Wikisource.

As I've now had the same error occur when <noinclude></noinclude> was used on content other than that at Wikisource it would seem Linter has a problem in parsing <noinclude></noinclude> content.

It is clearly not the case of such a simple issue.

@ssatry This is one page among the thousands that Wikisource has using that style of starting a continuing table with a {{nop}}, they are not showing up in the same means, so while the nop may be part of the issue, it is less likely that it is the sole issue. To me it is a miniscule matter, one false positive among so many matters.

<offtopic>The reason for the nop is that with wikitext |- that it needs to start it on a newline for mediawiki to know that it is a <tr> marker, and without the nop and a newline the system doesn't see it and just sees them as characters. </offtopic>

ssastry triaged this task as Normal priority.Apr 27 2017, 2:34 PM
ssastry moved this task from Backlog to Linter on the Parsoid board.Sep 18 2017, 5:12 PM
Restricted Application added a subscriber: jeblad. · View Herald TranscriptSep 18 2017, 5:12 PM