Page MenuHomePhabricator

Cleanup and document code dealing with incomplete follow
Open, Needs TriagePublic


The original Technical-Debt ticket T240858: Clean up implementation for "follow" cases was based on wrong assumptions, patches reverted and the ticket closed as invalid. However, the tech-debt in the Cite codebase is still there and asks for cleanup. In detail:

  • Originally, the follow="…" feature was entirely untested. This is mostly fixed by now. Still some edge-cases are not covered.
  • The rendering order intentionally starts with the "incomplete" follow="…" (in the order in which they appear in the source), followed by all other references. This might need more test coverage and an update of the uasort() function in Cite.
  • Currently, the Cite code creates broken HTML where a <p> appears in the middle of an <ol>. This is not allowed. RemexHtml kicks in and changes this order as best as it can. This creates a fragile dependency that's not obvious at all. Solution: Change Cite so the <p> are output before the <ol>. Update: It appears the "incomplete" entries are meant to be part of the list, and indented as the other list entries, just not numbered.
  • Another issue is that this <p> is not in the code, but in a message. The message contains nothing that needs localization. The only reason to make it a message is so that a wiki can change it – or empty it. If it turns out this is not needed, we can delete the message and create the <p> in code.

Real-world example of such an "incomplete" follow="…":

Event Timeline

Change 572957 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/Cite@master] Fix broken HTML created by ReferencesFormatter

Semantically the incomplete ref is part of the list, it just shouldn't get the backlink and marker. I don't think the <p> wrapper is important (in fact, it might be better without: cf. T49544). I think in general the short summary for these refs is that they 1) should be at the top of the list, and 2) should not have a backlink and marker. Everything else is implementation detail and practical considerations.

Semantically speaking ...

Rather than calling the follow=... components as incomplete is not accurate, they are simply continuing a previous part [of a <li> in an ordered list.] Subsequent parts of a footnote are as incomplete as the first part.

And I have seen some continuing footnoes that are quite complex, they can be proceeding for numbers of pages, containing tables, etc.

This comment was removed by beleg_tal.

Change 572957 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/extensions/Cite@master] Fix broken HTML created by ReferencesFormatter


According to*&regex=1&namespaces=8&title=Cite+references.* there are currently no local overrides for the cite_references_no_link message.