Last modified: 2008-08-11 17:34:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7810, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5810 - Transcluded references can appear in wrong references section
Transcluded references can appear in wrong references section
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-05-03 14:03 UTC by Steve Bennett
Modified: 2008-08-11 17:34 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Steve Bennett 2006-05-03 14:03:00 UTC
Example case:

Here, I have transcluded about 10 articles into one. Some of the sub articles
use the new referencing system. Unfortunately here, the Rome article only
actually defines 1 reference, but ends up with 58,
because all the references defined in earlier articles transcluded into the
parent article are shown again.

Is there a workaround? The simplest solution would appear to be making <refs>
only be shown the first time a <references> section is used. In subsequent
<references> sections they should not be shown.
Comment 1 Brion Vibber 2006-05-03 22:06:39 UTC
I don't think that would work the way extensions are currently handled.
All <references> tags would be handled after all <refs>, and they don't 
have any positional information.
Comment 2 Steve Bennett 2006-05-09 13:02:34 UTC
Would it be possible to have a <clearrefs> tag, which purges the current cache?
In other words so that:

some<ref>foo</ref> text
<references />
<clearrefs />
intermediate text

more<ref>bar</ref> text
<references />

would produce:
some[1] text
1. foo
intermediate text

more[1] text
1. bar

Currently, the following is produced:
some[1] text
1. foo
2. bar
intermediate text

more[1] text
1. foo
2. bar

If transclusion is used, then the "2. bar" does not appear in the first
references section.
Without transclusion:
With transclusion:
Comment 3 Brion Vibber 2006-05-09 20:40:32 UTC
No, it would not.
Comment 4 Philippe Verdy 2006-05-30 13:38:50 UTC
We have <ref name="x"> to create multiple referencesto the same note.

But why not having <ref type="x"> for creating several independant lists in articles? Then to generate the 
list of references of the same type we would have <references type="x" /> and this would select only the 
references of that type (the absence of the type attribute in references tag would list all untyped refs 

We could optionally use <references type="*" /> to generate all references, merged into a single list, and 
<references type="x,y" /> to select only the enumerated types, or <references type="x,y,-z" /> to exclude 
refs with type z (the selection of refs to generate is made by the union of positive type selectors, minus 
the union of negative selectors.)

The text in a <ref>element may also embed other text in a <ref>, allowing notes to refer to each other. (But 
first, the parser should be corrected so that it collects all footnotes in the article, including those that 
are wiki-encoded after the <references /> wikitag.

There would still be only one numbering, whatever the type specified in <ref type="...">...</ref> elements.
Comment 5 v111p 2006-06-02 09:26:18 UTC
I suggest instead of "type", "group" is used, and every group is printed with a <references 
group="name_of_the_group"/>. <references/> (no group specified) prints the rest of the references. 
What Philippe suggests is too complicated. Why would you want to print 2, 3 or all reference groups 
into one list??
Comment 6 Brion Vibber 2006-06-02 18:34:48 UTC
The parser in 1.7 now processes tags in order, making it 
possible in theory to do a clear at each <references/>.

I note that your sample page no longer uses any 
transclusions, making it impossible to test the current 
Comment 7 Steve Bennett 2006-06-02 19:44:38 UTC
yeah, someone pointed out rightly that I was transcluding all the categories as
well and killed it. do the test cases in my comment #2 help?
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-06-12 16:29:31 UTC
Bug 6271 would allow one implementation of this.
Comment 9 Jelte (WebBoy) 2008-08-11 17:34:57 UTC
(In reply to comment #6)
> The parser in 1.7 now processes tags in order, making it 
> possible in theory to do a clear at each <references/>.

Done in r32290 by sanbeg.

Note You need to log in before you can comment on or make changes to this bug.