Test case & demonstration wikitext.

Attached:

This extension provides functionality addressing Bug 12765.

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?

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

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 "<Footnotes> ... </Footnotes>" with all footnotes invisibly declared in the " ... ".

2. 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> ... </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.

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?

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.

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.

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.

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

Maury

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>

References

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

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:

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

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

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