I experimented with this a couple of years ago, and noted some problems to solve: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/463595

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! ~~~~