Page MenuHomePhabricator

Transcluded references can appear in wrong references section
Closed, ResolvedPublic


Author: bugs

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.

Version: unspecified
Severity: minor



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:12 PM
bzimport added a project: Cite.
bzimport set Reference to bz5810.
bzimport added a subscriber: Unknown Object (MLST).

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.

bugs wrote:

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:

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.

v111p wrote:

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??

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

bugs wrote:

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?

ayg wrote:

Bug 6271 would allow one implementation of this.

webboy wrote:

(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.