Enable editors to control footnote ordering and to insert wikitex between footnotes. Also declutter article prose.
Closed, DeclinedPublic


Modified cite.php to implement these extensions

This bug replaces Bug 12498, which I have marked WONTFIX.

The implemented extensions are intended to be entirely backwards compatible with existing wikitext, and to enhance functionality as follows:

  • Allow <Ref>...</Ref> declarations outside of the article prose, thus reducing editorial clutter inside the prose. Support for a decl=whatever parameter is added for this. Refs can be invisibly declared in a block using <ref decl=whatever>...</ref>, with all the clutter represented by "..." being removed from the article prose. Only minimal clutter (e.g., <Ref name=whatever />) would need to be placed inline in the article prose.
  • Allow editorial control over the order in which Refs are expanded when the <References /> tag is encountered. Editors would exercise this control by placing the block of invisibly declared footnotes, grouped and ordered as desired, early in the wikitext — ahead of the first occurrence of a Ref tag in the visible article prose. Cite.php will have stacked the Refs in the footnote declaration block in the order they were encountered, and they will be expanded in that order.
  • Allow anonymous subheaders to appear in the list of expanded references. Support for a head parameter is added for this. Subheaders can be invisibly declared in the invisible block of declared Refs as <Ref head>...</Ref>, and will appear in the expanded references list at the point where they were declared.

Allowing footnotes to be grouped, with each group introduced by editor-controllable headers, provides functionality similar to that provided by Bug 6271.

This extension provides functionality addressing Bug 5997.

Version: unspecified
Severity: enhancement

Attached: Cite.php

bzimport added a project: Cite.Via ConduitNov 21 2014, 10:05 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz12796.
Wtmitchell created this task.Via LegacyJan 26 2008, 5:59 AM
Wtmitchell added a comment.Via ConduitJan 26 2008, 6:00 AM

Test case & demonstration wikitext.

Attached: Test_case_wikitext.txt

Wtmitchell added a comment.Via ConduitJan 28 2008, 3:47 AM

This extension provides functionality addressing Bug 12765.

MauryMarkowitz added a comment.Via ConduitMay 10 2008, 11:58 AM
  1. I assume that the "decl=" syntax is a tag that renders the ref invisible? If so, can't we think of a better keyword? How about visible=no?
  1. I really, really believe that the references/cites should be placed as close to their physical location in the article as possible. The best-case scenario would be that they would be placed directly in the ==References== section itself.

I don't think that (2) really requires the ref header functionality.

Wtmitchell added a comment.Via ConduitMay 10 2008, 10:44 PM

Responding to Comment #3 from Maury Markowitz

  1. Changes from decl= to something else are possible. The difficulty is in defining the requirement more than in implementing the functionality. Personally, I would favor a new parser hook, e.g. "Footnotes, as in "&lt;Footnotes> ... &lt;/Footnotes>" with all footnotes invisibly declared in the " ... ".
  1. What the "ref header functionality" (the cite.php mediawiki Citation extension) does is to provide a mechanism for hooking footnotes referenced in the text with clickable superscripted identifiers to the expanded text in a list of identifier-marked notes which appears elsewhere (usually near the foot of the article). The parser is a one-pass parser, and stacks the footnotes in the order they are first encountered. It's easy to control the ordering of footnotes by declaring them invisibly very early in the wikitext. It wouldn't be very difficult to initially collect and stack footnote references (e.g. &lt ref name=whatever/>) and reorder the footnotes in the order of their declaration (e.g., &lt ref name=whatever> ... &lt;/ref>, which would allow the footnote declaration block to be placed at the foot of the article. As I said, the difficulty is in defining the requirement more than in implementing the functionality.
MauryMarkowitz added a comment.Via ConduitMay 11 2008, 2:24 AM

Bill, thanks for the note. I'm glad to hear you think the technical side is the easy part. :-) I actually have a little experience in this field, and I took one look at the source and realized a better programmer than me was going to have to step up for this one. I hope you are volunteering!

The good news is that I think I do know the spec. Not because of any personal superpowers, but because there was a really great thread in the tech mailing list a while back. A lot of ideas were tossed up and a couple stuck, and at the end it really seemed like we'd come to a consensus on what we were all looking for. I'd be happy to track this down and summarize if that would be useful.

BTW, on (2), wasn't there another upgrade (bug) that addressed this? IE, can't you put the body of the ref after the stubs now? If this is true, it should work OK even with the ref bodies at the bottom. Or am I misunderstanding the issue?

Wtmitchell added a comment.Via ConduitMay 12 2008, 5:08 AM

Hi Maury,

I'm short on time at the moment, so let me just say that I'd appreciate your requirements summary, and also say the following....

That bit about putting the footnote definitions at the end of the wikitext being easy was an offhand remark. On later reflection, I realized that it may not be so simple, depending on what "it" is (requirements definition needed).

As I understand it, the the mediawiki parser (I've never looked at the code) is a one-pass parser, and by the time the <references/> tag is encountered and triggers the expansion of the footnotes list, the superscripted numbered footnotes have already been sent to the user's browser. It'd be easy to reorder the reflist footnote expansion from order-of-first-encounter to order-of-declaration, but the numbering is by that time set in stone in order-of-first-encounter. I can conceive of a change in requirements which might make this not such a big deal (I won't take the time to explain that just now), but I cannot conceive of the change I have in mind for that being acceptable to the wikipedia community -- much less to the wider wikimedia community. I'd be happy to discuss this if there is a chance that it's not a timewaster, but not just now.

I am really disappointed that this bugzilla bug has sat unreviewed for five months or so. I did the implementation work with the the perception that the work was in response to a multiply-expressed desire to (1) declutter the wikitext and (2a) allow editors the flexibility to control the ordering of footnotes and (2b) allow editors to group footnotes (e.g., pure notes, grouped separately from an alphabetized list of footnoted author-date cites, perhaps grouped separately from other footnoted cites not done with author-date). I get a "nobody cares" vibe from this. Perhaps I've neglected to take some action of which I'm not aware which would trigger review of this.

bzimport added a comment.Via ConduitOct 8 2008, 12:05 PM

klas wrote:

Hi, I believe that the decluttering feature is greate, and really welcome that. I noticed that Bill is disappointed about the lack of support for this idea, but there is probably a whole bunch of Wikipedia editors out there who feel like me, but simply haven't found their way to this page to give their support. Please, go ahead and implement this feature as soon as possible. Lack of support doens't mean it is a bad idea. If I can help in any other way than actually writing the code, please let me know.

Wtmitchell added a comment.Via ConduitOct 9 2008, 3:59 AM

The extension to cite.php which added support for the optional ''group'' parameter to the ''Ref'' tag invalidated the code I implemented here. My implementation here could be reconciled with the current code, but I've had an idea for an alternative approach which I like better. Right now, it's just an idea for an approach, not even a well thought-out statement of requirements&mdash;but once the requirements are thought out I believe the implementation would be straightforward and would impact the existing Cite extension code only minimally. If anyone is interested in discussing this, email me or (preferebly) put a note on my talk page -- Talk:Wtmitchell -- at Wikipedia.

MauryMarkowitz added a comment.Via ConduitOct 9 2008, 11:38 AM

I'm a bit confused, where is the "group" described? It sounds a lot like something that came out of the e-mail thread I was mentioning.

As Klas notes, I think the lack of support here is really an issue of no-one being able to find it. Just drop a note in any of the mailing lists and watch what happens...


bzimport added a comment.Via ConduitNov 28 2008, 9:30 AM

simon wrote:

I voted on this because I think the functionality is badly needed, i.e. to unclutter Wiki-text and it would also be good to be able to decide on reference ordering. I think the proposed syntax looks a bit strange, though; agree with the first comment from Maury Markowitz. I suggest something like this:

Apples are often red<ref name="bob"/>, but they can also be green<ref name="alice"/>. Some people claim to have seen blue apples<ref name="cybil">Cybil, C. (2004). Blue apples!</ref>


<refdef name="alice">Alice, A. (1997). Green apples!</refdef>
<refdef name="bob">Bob, B. (2003). Red apples!</refdef>

The "cybil" example is there to demonstrate how this would handle existing code. When the "references" section is parsed, it goes through all "refdef" tags. At the closing tag, it will display all refs that have been defined earlier in the text, but do not have a "refdef". Actually, since mostly "refdef"-tags are going to be inside "reference", the syntax could be simplified:

alice = Alice, A. (1997). Green apples! |
bob = Bob, B. (2003). Red apples!

But the we lose some flexibility, like the things that "ref head" could enable...

Wtmitchell added a comment.Via ConduitMay 24 2009, 7:27 AM

This bug is superseded and replaced by Bug# 18890. I am resolving it as WONTFIX.

Add Comment