Last modified: 2014-08-11 01:16:08 UTC
More specifically, it can't count references. See the screenshots, specifically the citation at the end of the "early days" section.
Created attachment 12700 [details] How it should look
Created attachment 12701 [details] How it actually looks
Created attachment 12705 [details] How it actually looks
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.
Ah, I see the new screenshot. You wanted to write "Early years"?
Indeed. In my defence it's 10pm on a Sunday :/
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.
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.
IIRC the VE renders (and numbers) references natively without using our rendering at all. Which would make this a VE bug. Trying to confirm.
Moved to VE, as the numbering seems to be re-done in VE.
(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.
This also prohibits references utilised in templates from being used elsewhere on the page via the template inspector. Blah :/.
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.
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
Change 71528 had a related patch set uploaded by GWicke: WIP Bug 50474: Remove children of references node https://gerrit.wikimedia.org/r/71528
Change 71528 merged by jenkins-bot: Bug 50474: Remove children of references node https://gerrit.wikimedia.org/r/71528
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.
*** Bug 52083 has been marked as a duplicate of this bug. ***
Resolving Bug 28980 could relieve at least part of this problem by lifting the need to use <ref> because of localization issues.
*** Bug 52478 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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.
(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. :-)
*** Bug 53486 has been marked as a duplicate of this bug. ***
(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.
*** Bug 53777 has been marked as a duplicate of this bug. ***
*** Bug 51058 has been marked as a duplicate of this bug. ***
*** Bug 63210 has been marked as a duplicate of this bug. ***
*** Bug 52742 has been marked as a duplicate of this bug. ***
*** Bug 69373 has been marked as a duplicate of this bug. ***
