In VisualEditor, references in templates cannot be reused and are numbered separately from references in the text.
OpenPublic

Description

For example, look at this old version of w:en:Popocatépetl. It has 21 references, 3 of them in the infobox only. When you open it in VE, those first 3 cannot be accessed from the re-use menu. In addition, all 21 appear in the references list, but each reference x in the text corresponds to entry x + 3 in the references list.

See Also:
T52505
T53289
T54398
T55777
T54262

bzimport added a project: VisualEditor-DataModel.Via ConduitNov 22 2014, 1:54 AM
bzimport set Reference to bz50474.
Ironholds created this task.Via LegacyJun 30 2013, 7:31 PM
Ironholds added a comment.Via ConduitJun 30 2013, 7:32 PM

How it should look

Attached:

Ironholds added a comment.Via ConduitJun 30 2013, 7:32 PM

How it actually looks

attachment Screen Shot 2013-06-30 at 12.24.02 PM.png ignored as obsolete

Ironholds added a comment.Via ConduitJun 30 2013, 7:52 PM

How it actually looks

Attached:

Rillke added a comment.Via ConduitJun 30 2013, 7:59 PM

Yes, there are references with the same name, split into multiple entries but I don't understand how the screenshots you attached should demonstrate that.

Rillke added a comment.Via ConduitJun 30 2013, 8:01 PM

Ah, I see the new screenshot. You wanted to write "Early years"?

Ironholds added a comment.Via ConduitJun 30 2013, 9:02 PM

Indeed. In my defence it's 10pm on a Sunday :/

ssastry added a comment.Via ConduitJun 30 2013, 11:08 PM

Looks like the ref-counter has been reset after the 2nd ref-tag was processed and also, 13 references are duplicated (the first 2 are not duplicated).

The bug cannot be duplicated locally. So, I suspect something is off when refs are being reused from Varnish caches.

ssastry added a comment.Via ConduitJul 1 2013, 4:10 PM

It seems that this bug doesn't cause any wikitext corruption, but only affects display in VE. Still something we should fix on the Parsoid end, but not as troublesome as I initially thought this was.

GWicke added a comment.Via ConduitJul 1 2013, 4:35 PM

IIRC the VE renders (and numbers) references natively without using our rendering at all. Which would make this a VE bug. Trying to confirm.

GWicke added a comment.Via ConduitJul 1 2013, 4:37 PM

Moved to VE, as the numbering seems to be re-done in VE.

Catrope added a comment.Via ConduitJul 1 2013, 5:27 PM

(In reply to comment #9)

IIRC the VE renders (and numbers) references natively without using our
rendering at all. Which would make this a VE bug. Trying to confirm.

That's correct. VE does not see the first two references because they are in a template, and so it mistakenly believes the one in "Early years" is the first one.

We could mitigate this by using the numbering Parsoid gives us.

Ironholds added a comment.Via ConduitJul 1 2013, 5:28 PM

This also prohibits references utilised in templates from being used elsewhere on the page via the template inspector. Blah :/.

GWicke added a comment.Via ConduitJul 1 2013, 5:40 PM

Parsoid provides ref info also inside template-generated content, and our ref / references rendering code make use of that. I have proposed to share that code in bug 50505.

Using the Parsoid rendering on first load could be a workaround, but hacking dynamic updates into that sounds like more trouble than it's worth.

GWicke added a comment.Via ConduitJul 1 2013, 8:57 PM

I think so far we have seen several issues in this area:

  • References from templated content are not being picked up by VE, which causes
  • the numbering to be off
  • those references to be missing in references
  • edits to refs whose primary (first in DOM order) definition is templated just update the first non-templated ref alias in the page. Those changes are then not rendered in the PHP parser. Correct behavior would be to explain why that reference cannot be edited.
  • Some refs are duplicated in the references section
gerritbot added a comment.Via ConduitJul 1 2013, 9:18 PM

Change 71528 had a related patch set uploaded by GWicke:
WIP Bug 50474: Remove children of references node

https://gerrit.wikimedia.org/r/71528

gerritbot added a comment.Via ConduitJul 1 2013, 9:32 PM

Change 71528 merged by jenkins-bot:
Bug 50474: Remove children of references node

https://gerrit.wikimedia.org/r/71528

GWicke added a comment.Via ConduitJul 1 2013, 9:36 PM

The ref duplication issue (last bullet point) was actually a Parsoid bug which is fixed with the commit above. It only manifested itself in templated references sections which are not rendered by VE. The fix is deployed to production.

The other VE issues remain, but fortunately are less visible to users unless they modify references.

Jdforrester-WMF added a comment.Via ConduitJul 26 2013, 11:10 PM
  • Bug 52083 has been marked as a duplicate of this bug. ***
Amire80 added a comment.Via ConduitJul 27 2013, 1:09 PM

Resolving Bug 28980 could relieve at least part of this problem by lifting the need to use <ref> because of localization issues.

Jdforrester-WMF added a comment.Via ConduitAug 29 2013, 11:37 PM
  • Bug 52478 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitAug 29 2013, 11:44 PM

kwwilliams wrote:

Describing a widely used template as a "hack" and refusing to fix the bugs associated with VE in terms of editing it is not a valid solution. The template does work and the references work fine using the normal editor. There's no way to code the template to not include the #ref.

It is not within the scope of the VE project to refuse to fix problems because they are hard.

I strongly, strongly object to the implication in the addition to 52478 that implies that this bug in VE will never be fixed.

Jdforrester-WMF added a comment.Via ConduitAug 30 2013, 12:17 AM

(In reply to comment #21)

Describing a widely used template as a "hack" and refusing to fix the bugs
associated with VE in terms of editing it is not a valid solution.

Who said I was refusing to fix it?

The template does work and the references work fine using the normal editor.
There's no way to code the template to not include the #ref.

<ref>{{foo}}</ref> works just fine, because that's how it was designed to be used. If you want an easier way to edit, use VE. ;-)

It is not within the scope of the VE project to refuse to fix problems
because they are hard.

This is off-topic, but actually, it is very much part of Wikimedia's job to make decisions about whether it is worth spending large amounts of donor funds on marginal use cases rather than features that can't be done in other ways.

I strongly, strongly object to the implication in the addition to 52478 that
implies that this bug in VE will never be fixed.

There is no such implication; there is clearly the inference in your reading of it, however. We will fix this bug - the comment just explains the priority of this bug in relation to others.

bzimport added a comment.Via ConduitAug 30 2013, 12:31 AM

kwwilliams wrote:

There's no way to code a single template that generates both a reference and table markup without using {{#tag:ref}}.

If you didn't think "any reference created by a template shouldn't work, deliberately" would be read as a refusal to fix that particular aspect of this bug, I have no idea what you intended it to mean.

I also don't see that this bugzilla specifically addresses the ability for the names and contents of template generated references to be available to an editor that is using the "add reference" dialog.

GWicke added a comment.Via ConduitAug 30 2013, 12:35 AM

We might actually be able to use the same CSS technique I developed for auto-numbered external links in bug 53505 for citations. That would at least fix the numbering without extra effort, but won't help with <references> rendering and editing.

Jdforrester-WMF added a comment.Via ConduitAug 30 2013, 12:37 AM

(In reply to comment #23)

There's no way to code a single template that generates both a reference and
table markup without using {{#tag:ref}}.

True. This should have given you pause to consider /why/ it wasn't available until recently. :-)

If you didn't think "any reference created by a template shouldn't work,
deliberately" would be read as a refusal to fix that particular aspect of
this bug, I have no idea what you intended it to mean.

Translation: When we made MW's citation system, the intent right from the start was to never, ever let people create nested references, or references that need to be parsed multiple times, because it creates endless issues.

Unfortunately, when later the {{#tag:xxx}} system was created, the person implementing that didn't remember this issue and instead has indeed given rise to all manner of epic problems.

I also don't see that this bugzilla specifically addresses the ability for
the names and contents of template generated references to be available to an
editor that is using the "add reference" dialog.

That would be the "don't show up as references to insert" part of the title. :-)

Jdforrester-WMF added a comment.Via ConduitAug 30 2013, 12:41 AM
  • Bug 53486 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitAug 30 2013, 6:23 AM

kwwilliams wrote:

(In reply to comment #25)

(In reply to comment #23)
> There's no way to code a single template that generates both a reference and
> table markup without using {{#tag:ref}}.

True. This should have given you pause to consider /why/ it wasn't available
until recently. :-)

Laughing while you dismiss my comments adds a layer of rudeness to the discussion that is completely unnecessary.

Jdforrester-WMF added a comment.Via ConduitOct 28 2013, 11:43 PM
  • Bug 53777 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitNov 25 2013, 12:12 PM
  • Bug 51058 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitMay 30 2014, 2:27 AM
  • Bug 63210 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJun 9 2014, 4:40 PM
  • Bug 52742 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitAug 11 2014, 1:16 AM
  • Bug 69373 has been marked as a duplicate of this bug. ***
Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 1:22 AM
Ironholds removed a subscriber: Ironholds.Via WebDec 5 2014, 7:45 PM
marcoil added a subscriber: marcoil.Via WebDec 24 2014, 11:33 AM
Etonkovidova added a subscriber: Etonkovidova.Via WebDec 25 2014, 1:22 AM

Notes for testing the future fix:

  • The references placed in the Infobox template should be numbered correctly along with the other page references
  • There should be no discrepancy in displaying reference numbering in Read mode or VE mode
  • also, check reference for class="toccolours" - the warning msg should be displayed: "This reference is defined in a template or other generated block, and for now can only be edited in source mode."
Krinkle removed a subscriber: Krinkle.Via WebJan 9 2015, 2:57 AM
coldchrist added a subscriber: coldchrist.Via WebJan 14 2015, 2:51 AM

It doesn't seem to have been mentioned above that this bug can cause the loss of a citation, which might affect the severity or priority. If you have a ref inside a group note (e.g. inside a tag) and delete all other copies of the ref, including the base copy, VE is unable to transfer the base text to the copy of the ref in the tag, so the citation is lost.

GermanJoe added a subscriber: GermanJoe.

See en-Wiki feedback "Citation numbers messing up". This problem is repeatedly mentioned on en-Wiki, confuses editors and hinders editing of developed articles with complex reference structures. I would like to propose the whole issue with "references in templates" and "references generated by templates" as blocker. I am aware, that 5 other tasks are possible related to this problem (See also), maybe the whole topic area needs another fresh look for a solution. - the problem is known for almost 2 years now, and should get a higher priority and more frequent updates on its status.

Jdforrester-WMF added a comment.Via WebMay 6 2015, 8:49 PM

In the weekly triage meeting on 2015-05-06, we discussed this task. Though we acknowledge that this is moderately confusing for users, fixing this is a very large piece of work (which reflects why it has not been completed in the past two years either). I've marked this as blocked by a piece of work that we hope to finish out this quarter, which will hopefully help make this slightly less epic to fix.

Trizek-WMF added a subscriber: Trizek-WMF.Via WebJun 3 2015, 10:51 PM
Neil_P._Quinn_WMF changed the title from "VisualEditor: References created by templates numbered alone, not with the rest of the page, and don't show up as references to insert" to "References in templates are numbered separately from references in the text and cannot be reused in VisualEditor".Via WebJun 16 2015, 2:04 AM
Neil_P._Quinn_WMF edited the task description. (Show Details)
Neil_P._Quinn_WMF changed the title from "References in templates are numbered separately from references in the text and cannot be reused in VisualEditor" to "In VisualEditor, references in templates and image captions cannot be reused and are numbered separately from references in the text.".Via WebJun 16 2015, 8:47 PM
Neil_P._Quinn_WMF edited the task description. (Show Details)
Neil_P._Quinn_WMF changed the title from "In VisualEditor, references in templates and image captions cannot be reused and are numbered separately from references in the text." to "In VisualEditor, references in templates cannot be reused and are numbered separately from references in the text.".Via WebJun 16 2015, 9:01 PM
Neil_P._Quinn_WMF added a project: Epic.

Add Comment