Page MenuHomePhabricator

References from template transclusions should be part of the internalList
Open, Needs TriagePublic


Currently references coming from template transclusions are not very well represented when using the VE. This is the root for several problems when dealing with them in the UI.

See for example
T215867: Visual editor reference auto name may collide with existing ref names when the existing reference comes from a template tranclusion
T52474: In VisualEditor, references in templates cannot be reused and are numbered separately from references in the text.

To fix some of these issues, especially with correctly numbering the references, avoid naming collisions and make transcluded references more visible to user they should probably be part of the of the document.


  • References should be numbered in the VE preview according to their numbering in the article text
  • The referencelist preview in VE can generate a list with all references, their content and numbering like in the article text
  • When named references from transclusions are part of the article, newly created references and their re-uses won't lead to naming conflicts with existing names
  • References from transclusions should not be selectable in the re-use dialog

Acceptance criteria:

  • All references from transclusions are part of the internalList of the current document
  • It should be possible to distinguish references coming from template transclusions from other references
  • Ideally it should be possible to identify which reference was transcluded from which template

This is not about re-using of references coming from template transclusions. That's a pretty big, complicated and in parts unclear task.

Maybe related:
T214241: data-mw info is clobbered by template annotations

Event Timeline

I experimented with this a couple of years ago, and noted some problems to solve:

I don't recommend re-using that code, but maybe it saves you a few hours of investigation :)

While it may be possible to make this work in some simple cases, it should be noted that with the current architecture of VE and Parsoid this is going to be quite difficult to do reliably.

References in templates are not part of the data model, and for a good reason. When we modify templates, all we change are template parameters. We then update a rendering in VE but this is only for the view, not the model. A template could generate a reference just by changing a boolean parameter (e.g. | generate_reference = 1). View updates are done via an API call and are asynchronous and detached from the model, this means if a template starts generating a reference after an edit to the template, there's no sensible way to put that information into the model. Similar problems arise if the reference stops getting generated, or if the template gets deleted.

Without a significant re-architecture of how VE and Parsoid handle templates and template updates, any feature that reads references from templates would need to come with some big caveats, e.g. if you delete the template where the reference was originally defined, the re-use of the reference will break (whereas with "normal" references, VE seamlessly transfers the reference definition to the remaining reference).

Just as clarification: Although it might be confusing with the tasks linked here. This is not about re-using references from templates. Re-using references that are the result of a transculsion is quite big, unclear and complicated to implement. For several reasons. And it even might not make sense in many cases.

This task is mostly to enable a correct numbering of the references, avoid conflicts while auto-naming and to make the contents and origin of the references more clear to the users.

This task is mostly to enable a correct numbering of the references, avoid conflicts while auto-naming and to make the contents and origin of the references more clear to the users.

Thanks for the clarification. While that removes the specific problems I mentioned with regards to reference re-use, the general problem of this data being provided async and being part of the view means that you will still have problems when templates are changed in any way (updated/added/removed), but those problems may just be limited to display errors, rather than wikitext corruption.

To be clear I think there is probably value in improving the reference lists in this way, even if it is only accurate until template changes are made, as that will cover 90%+ of use cases, I'm just pointing out that there are inevitably going to be limitations with the current architecture.

Depending on the outcome of T356860: Experiment: move reference footnote content out of VE internalList and into reference nodes, we may want to tweak this task to say "References from template transclusions should be tracked by visual editor", if internalList will be deprecated.

We just ran into this problem while trying to create a teaching demo. It would be greatly appreciated to have it fixed. I'm just thankful it didn't happen while we were in front of a roomfull of educators, trying to demonstrate the Visual Editor! ~~~~