User story:
As reader I want to see sub-references with the same main content and the same additional details content as re-uses of one sub-reference.
Acceptance criteria:
- We want to merge sub-reference by comparing their Wikitext content similar to how it is done when two refs with the same name are "merged" if the content is identical
- Duplicates should be merged in the reference list, and get the same number (e.g. [1.1]) in their corresponding footnote markers.
- Since, we are aiming to roll this out without Parsoid, before we deploy we will need to discuss with Content Transform Team a solution to tweak tooling to ignore the visual diffs.
Mock
Notes
- Main ref content can be repeated for named refs, and this is used extensively by templates such as {{sfn}}. Unfortunately, this can create a fragile situation in manually-entered wikitext, for example when a ref tag is copy-pasted. The fragility is caused by any small change to the ref body causing an error to be displayed, and only one copy of the content being rendered. Named refs with and without details can take advantage of this deduplication.
<ref name="abc">def</ref> <ref name="abc">def</ref>
- The only type of reuse that can be offered for details is more like "duplication and deduplication" like this, which could be rendered as a single subref with two backlinks:
<ref details="abc" name="def">ghi</ref> <ref details="abc" name="def" />
- It would be wise to do some more UX discovery before implementation. If subrefs appear to be reused, there may also be an expectation to deduplicate them and treat as reuses in the visual editor. We can also gauge how important it is to users to have subref reuse.
- The mechanism to deduplicate subrefs will probably need to index details content by wikitext. It's unsafe to implement as a simple comparison loop, because this will slow down by N^2. Note that subrefs should only be compared within each top-level ref.
Out of scope
- VE is out of scope
- This is only for the legacy parser, for now.
- Top-level refs should not have this behavior, in fact we'll probably be adding an error if two named, top-level refs both include content.