Wikipedia talk:Citing sources

Retrieval dates: redundant for sources with official publication dates?

This subject keeps coming up. There is an extensive discussion in the archive. Please add new comments here, not in the archive. --EnOreg (talk) 14:20, 27 April 2009 (UTC)

References

</nowiki>

• Please don't make us go multiple places to edit a single reference; that will just cause people to abandon the notion. A better editing environment, one that had a separate edit box for refs right alongside the ref itself, seems like a better idea. I like the idea of tying refs with text, but only if we don't have to edit the ref in two locations. --Golbez (talk) 15:47, 6 July 2009 (UTC)

  How would your suggestion remove the clutter from page source? SharkD (talk) 15:52, 6 July 2009 (UTC)

I welcome this proposal cautiously, but agree with the concerns raised by Amalthea and Golbez. I think that if all the reference definitions were moved to the end of the article, this would make editing cumbersome as it would be necessary to keep moving there to add, alter or delete references, and would make section editing impractical. Placing reference definitions relating to a particular section at the end of that section sounds like a fair compromise. The split screen suggestion by Golbez is also great, if that can be implemented. — Cheers, JackLee ^–talk– 16:07, 6 July 2009 (UTC)

I really do not understand the point some people are making about section editing being made cumbersome: isn't it already the case that not all references in a section are always defined in that section? Shreevatsa (talk) 17:33, 6 July 2009 (UTC)

At present, most references inside sections of an article are typed directly in between "<ref>" tags. Alternatively, you can give a reference a name using "<ref name=>". Therefore, when you are editing a section and want to use the same reference, you just have to remember the name you gave the reference earlier. However, if a new system requires all reference definitions to be placed at the end of the article, then most of the time it will be necessary to edit the whole article so that new definitions can be inserted at the end. Editing a section will be more inconvenient because it will not be possible to insert the reference definition in that section – unless, of course, we put such definitions at the end of each section rather than at the end of the article. — Cheers, JackLee ^–talk– 17:55, 6 July 2009 (UTC)

Just to be clear, any technical change would allow but not require references to be moved. References placed directly would still work, but people would have the option of relocating them as a means of reducing clutter, if the community decides that is a good idea. Dragons flight (talk) 18:03, 6 July 2009 (UTC)

Yes, it should be backwards-compatible. SharkD (talk) 06:41, 7 July 2009 (UTC)

• For the record, any proposal that requires a separate editing box for references is a non-starter for me. Even if the community unanimously agreed to it, that's a much bigger change than I am personally willing to implement. However, I am willing to consider other options for relocating reference blocks, such as some way of defining them at the end of each section. Dragons flight (talk) 16:39, 6 July 2009 (UTC)

  Err, what you're proposing is already possible using the cite id system. Take a look at GRB 970508. --Cryptic C62 · Talk 18:05, 6 July 2009 (UTC)

  That's rather different, I'd say. The style used there is a compromise that can be useful in particular if many refs go to different pages of the same book. I personally find that style less useful, from a reader's point of view, cause I have to click the inline ref and the "Notes" item to get to the actual reference. Furthermore, if all you have are sources to online articles, without any page numbers, that system loses all advantages in my opinion, sunce you effectively duplicate all refs. Easier for the editor, while less useful for the reader, whereas the proposed system won't necessitate a visual change. Amalthea 23:00, 6 July 2009 (UTC)

• Hi Dragonsflight, I don't fully understand what your proposal is (in fact, I don't understand it at all, to be honest), but I'd like to add that anything that sections the refs off from the text (e.g. puts a box around them), or highlights them, or increases their length, makes copy editing for flow very difficult. In fact, it is impossible with some of the citation templates, which leaves us with some badly written articles and no clear way to improve them without removing a lot of the references. So I'd be opposed to anything that would make that situation worse. SlimVirgin ^{talk|contribs} 20:23, 6 July 2009 (UTC)

  I, in return, don't understand at all what you are saying. :)
  This proposal is about moving the body of references from the prose into into the "References" section. Only the named reference tag will be placed in the prose, e.g. "<ref name=nytimes/>". This will make copyediting the actual article text easier, and it will have no effect on the rendered page. Amalthea 23:00, 6 July 2009 (UTC)

• Is it possible to set up a page somewhere showing what this would look like? Even if it's not a working model, it would be good to see how it would appear, and in what way it's so very different from what some editors do already. Amalthea, the way you describe it, I can't see a huge difference between the proposal and editors who already use Harvard refs between ref tags in the text. SlimVirgin ^{talk|contribs} 18:09, 11 July 2009 (UTC)

• My thoughts: Keeping the references in the same place as the content is much preferable than having to go somewhere else to print them, as we used to. That's just asking for people to forget to do the reference, or just skip doing the reference at all out of laziness. Having an editing environment where we could collapse references or explode them out to a popup of some sort might help, but please don't return us to the days of {cite and {note. Even as an option, it will just screw things up. --Golbez (talk) 20:43, 6 July 2009 (UTC)

  As I mention above, I agree that there are circumstances when placing the body of references in a separate section is cumbersome. Would you agree though that for a new editor and from an editor who wants to edit existing references, having all references listed in one separate section instead of in the middle of the text will actually make things easier?
  I believe that if we still allow editors to place their new inline citations in the middle of the prose, without reservation, just as they do now, and rely on bots/AWB/gnomes to "clean" those articles up, it will very much be a net positive. Or do you see issues when editing existing references will be made (much) harder with the proposed system, Golbez? I'd certainly agree that if any change will make people use less citations, then it needs to be avoided, but I don't see why the proposed change would have that effect. Amalthea 23:00, 6 July 2009 (UTC)

  I found things much harder when references were split between prose and the end, I can't assume all new editors feel the same way but I know how I felt, both then and now. The problem with this proposal is that it gives three meanings to a single tag - it makes <ref> dependent on context and values, and I would think that would confuse new users more than anything. I find this proposal difficult for new users to understand (Heck, I have a problem with understanding it), and there are much better solutions than returning us to the old method of separating citation from prose. --Golbez (talk) 23:15, 6 July 2009 (UTC)

Finally, a way of moving ref definitions that is fully backwards-compatible and intuitive.

First let me say that I do not support fragmenting articles to the extent of implementing a <define>...</define> tag; that is just asking for confusion and poorly-constructed pages, the wiki equivalent of the evil 'jump' statement in some programming languages. Why are refs different? Because refs are what we'd describe as 'inline' elements: they come between, and sometimes within, the prose sentences. An infobox might be a huge block of ugly code, but it is distinct from the prose: whether or not people understand what the code does, they can easily recognise it as 'the code that makes the infobox appear', and skim past it to the text. Refs are not like that: because they break up the prose so horribly - often many lines of code for something that comes out as four characters on the screen - they are incredibly distracting, and make it almost impossible to copyedit or even read the prose. The reason we have so many problems with punctuation and references being in the wrong order (lorem, ipsum), or even duplicated (lorem,, ipsum) is because by the time you've skimmed through the huge ref body, you've completely forgotten what the preceeding text was like. Anything that makes ref tags less intrusive into the article prose itself is, IMO, a very good idea.

Editing references can be difficult, everyone knows that. Section editing is particularly irritating, both because references are not displayed in preview, and that the necessary ref may be defined in another section, outside the scope of the edit. These problems are nothing new, and ubiquitous in any article long enough for section editing to be worthwhile. The 'solution' is likely to involve fully separating the references from the content: that might be by having them in a separate edit box; the long-term goal is I believe a WYSIWYG editor. An intermediate solution could be as simple as a piece of javascript or MediaWiki code to pick up reference definitions from the rest of the article and make them available within the confines of a section edit. Do you think writing such code would be easier if the references remained scattered throughout the articles, or if they were collected in one DOM element at the end?

In short, I fully support this as what seems like by far the most elegant and effective way to improve the flexibility of the ref system. Happy‑melon 22:50, 6 July 2009 (UTC)

Thank you Happy-melon, that is an excellent description of the problems caused by the clutter. The only thing I would add is that the existing in-prose reference markup (especially with citation templates etc.) indeed turns away several newcomers, as we learnt from the usability study: please watch File:Wiki_feel_stupid_v2.ogv. Shreevatsa (talk) 23:47, 6 July 2009 (UTC)

From the video it looks like it doesn't compare <ref>s with {{ref}}s; it simply shows people's confusion with <ref>s. That in itself does not mean we should change back to the {ref format. --Golbez (talk) 23:50, 6 July 2009 (UTC)

The video shows that excessive markup is intimidating. No one is proposing changing back to the {ref format, only that anything that reduces clutter is good. One particular instance is that "Person is X,<ref name=nytimes/> Y,<ref name=post/> and Z.<ref name=la/>" is more readable for users than "Person is X,<ref>{{citation | date=...(4 lines of markup)}}, Y<ref>(another 4 lines)</ref>, and Z.". Of course, other ways to reduce clutter and make prose readable when editing are also most welcome. Shreevatsa (talk) 00:23, 7 July 2009 (UTC)

Reducing clutter would be great, I'd be all for that. I don't see how this accomplishes that; it moves the clutter out of the article text but it's still there, and this would make it less likely that it would be properly added and maintained, IMO. And if this change makes it easier for people to edit yet decreases the total value of references - as I think it would - I have to be opposed to it. There are other ways of making it easier to edit than this proposal (which really should be just a "what do you think", as the specific proposal here is pretty bad; again, we shouldn't have one tag do three different things depending on context. THAT would confuse new editors even more, I think. No other HTML tag works in that fashion, and few wiki tags do) --Golbez (talk) 00:50, 7 July 2009 (UTC)

Moving all references to the references section would organize them and make it a lot easier to a) read the article prose, and b) read the citations themselves, since the article prose would be rid of the citation clutter, and the citations themselves would appear on their own lines with the wiki markup' characters lined up in rows and columns. SharkD (talk) 06:39, 7 July 2009 (UTC)

It might organize them but in IMO it would make it less likely for people to add them in the first place. As for what you say above - "Yes, it should be backwards-compatible." - then there's no point. No clutter will be removed; Some people will still use the present system (since it's backwards compatible); and newbies will still be confronted with a wall of clutter. If you truly want to do this to get rid of clutter then you must go all the way with it and not support the old ref-in-text system. --Golbez (talk) 14:41, 7 July 2009 (UTC)

You're making a lot of assumptions. SharkD (talk) 08:31, 8 July 2009 (UTC)

I am? The only assumptions I see up there is when I say "some people"; that includes me, and I'm pretty sure I'm not making an assumption about my own preferences. --Golbez (talk) 14:37, 8 July 2009 (UTC)

It's not particularly hard to extract the refs from the wikitext, even when they are scattered around the article. If you really want to make that easier, eliminate the three different methods of quoting allowed for parameter values (name="foo", name='foo', and name=foo, all with different rules as to which characters are allowed in the value). Anomie⚔ 00:51, 7 July 2009 (UTC)

Good thing there's no description of what the script actually does. SharkD (talk) 08:30, 8 July 2009 (UTC)

The sad thing about statements like that is that they go out of date so quickly. Anomie⚔ 00:26, 9 July 2009 (UTC)

< It is already possible to separate references from the text, using the {{Note}} and {{Ref}} templates. (This was mentioned before by Golbez and others but I want to underline it to make sure newer editors understand the issues. This example is adopted from WP:Verification methods.)

Article

This is some information.1 This information comes from a book.2 This is more information that comes from a different book.3 This is a point that needs clarification.4 This is more information from the first book.2 References ^ This tells exactly where this information came from. ^ ^ Doe, John (1996), Book of Information, Great Books, ISBN 1234567890 ^ Doe, Jane (2020), More Information, Better Books, ISBN 1234567890 ^ This is a footnote that clarifies the point above.

Wikitext

This is some information.{{ref|1|1}} This information comes from a book.{{ref|2a|2}} This is more information that comes from a different book.{{ref|3|3}} This is a point that needs clarification.{{ref|4|4}} This is more information from the first book.{{ref|2a|2}} == References == # {{note|1}}This tells exactly where this information came from. # {{note|2a}}{{note|2b}}[[John Doe|Doe, John]] (1996), ''Book of Information'', Great Books, ISBN 1234567890 # {{note|3}}[[Jane Doe|Doe, Jane]] (2020), ''More Information'', Better Books, ISBN 1234567890 # {{note|4}}This is a footnote that clarifies the point above.

What you propose is certainly an improvement over {{Note}} and {{Ref}}, because it automatically numbers the footnotes. As several people have noted, many editors would like to see clutter-free text like this example. However, as others have noted, this method was abandoned for several reasons that go beyond just the numbering issue, as discussed by Golbez, JackLee and others above. My own view is this:

1. I agree with HappyMelon and others above that Wikipedia needs a WYSIWIG editor that at least allows us to edit footnotes as easily as, say, Microsoft Word. The logical first step is that the editor window should show the linked, superscripted numbers that link to footnotes in a separate window or window section, where you can edit the contents of the footnote. All other proposals are, in my opinion, temporary and kludgy fixes that don't fully solve the problems and introduce new unforeseen problems.
2. Most editors don't seem to be aware of {{Note}} and {{Ref}}, despite the fact that these are used in a number of featured articles. Any new system, such as the one you propose, is probably destined to be just as rare and unknown, if not more so. Adding the code is fine, but "marketing" it to the vast majority of editors is another issue all together.

That's my two cents. ---- CharlesGillingham (talk) 18:40, 8 July 2009 (UTC)

• Thank you for expressing what I've been trying to say with #1. The problem is not the backend; the problem is in the editor. We've grown beyond a simple textarea form; while that of course can remain available, the only true solution to this is to have an advanced editor that allows us to separate the logic but not the entry. Many many more editors are aware of <ref>, both because it's more widely used and superior to {note}/{ref}; any change to <ref> to add two more types to it would confuse editors and doesn't solve the problem of clutter. --Golbez (talk) 19:42, 8 July 2009 (UTC)

  I've tried working with WYSIWYG HTML editors in the past and have found that they are more trouble than they are worth. While it is easy to get a simple page up and running in little time, they tend to insert junk and "invisible" formatting that shouldn't really be there.

  Also, thanks for mentioning the ref and note templates. However, it seems that they also require the refbegin and refend templates in order to achieve the smaller font. Could you provide an example of them being used along side the standard ref syntax, as well as the Cite XXX and Citation templates, so that we can see if there are any other stylization differences? SharkD (talk) 08:40, 10 July 2009 (UTC)

Hold on there, I'm not recommending these templates. The numbering really is kind of a pain. I'm just pointing out that "in the old days" there was a system very similar to what is being proposed and it was soundly rejected in favor of the current system, mostly because of the section editing issue. Just FYI. (I also fixed a bug in the example, just now.) ---- CharlesGillingham (talk) 03:17, 11 July 2009 (UTC)

On the "improved" (but not necessarily WYSIWYG) editor idea: check out the way wikEd handles the problem. It allows you to hide everything between <ref> and </ref>, changing it into a little button. It's a little buggy, but it is developing into a real solution to this problem.---- CharlesGillingham (talk) 03:17, 11 July 2009 (UTC)

Straw Poll on modifying <ref>

Based on the previous discussion, there would appear to be three possible courses of action at the software level for improving <ref> at the present time.

1. Alter <ref> and <references> as initially proposed so that the content of references may be defined within a <references> ... </references> block.
2. Alter <ref> so that the content of references may be defined in some other way at an arbitrary point in the page (such as at the end of the relevant section).
3. Do nothing now, and wait for a WYSIWYG editor or other solution to present itself / become widely adopted.

I would note that the first two of these aren't mutually exclusive, so one could support both and envision changes to allow for both. In order to move forward, I would like to know if a supermajority of Wikipedians support any of these options, hence the purpose of this straw poll, which I will try to advertise in the appropriate places.

Rgardless of any possible changes, the current <ref> syntax would continue to be fully supported, and changes would affect only how wikicode could be written with no change at all to the rendered page. Dragons flight (talk) 11:39, 11 July 2009 (UTC)

Option #1: Allow reference content to be defined inside <references>

Alter <ref> and <references> as initially proposed so that the content of references may be defined within a <references> ... </references> block. Each call to the reference, including the first one, would then be identified solely by the name parameter.

Example

Lorem ipsum dolor sit amet<ref name="foo" />, consectetur adipisicing elit, 
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.<ref name="bar" />

== References ==

<references>
<ref name="foo">abcde</ref>
<ref name="bar">xyz</ref>
</references>

Support #1

1. This is my personal favorite. Dragons flight (talk) 11:39, 11 July 2009 (UTC)
2. This would reduce clutter in source text by a large amount. For example, short phrases between two ref tags are very hard to visually locate in the edit box. A. di M. (talk) 13:18, 11 July 2009 (UTC)
3. This is also my personal favorite. I should say that having method #2 as a choice would be nice as well. --Izno (talk) 14:18, 11 July 2009 (UTC)
4. Makes far more sense, and is the standard method used in academic publication Modest Genius ^talk 16:39, 11 July 2009 (UTC)
5. Yes, it would be an improvement to shift ref definitions out of the prose. When adding refs, I avoid section edit anyway because preview then allows footnotes to be checked for expected appearance, cite errors etc. PL290 (talk) 17:52, 11 July 2009 (UTC)

   I concur that section editing with references works poorly.—C45207 | Talk 04:14, 14 July 2009 (UTC)

6. Assuming this is backward-compatible. -- Taku (talk) 19:41, 11 July 2009 (UTC)
7. Sounds good if it can be made to work without causing confusion about numbering. See for instance what I had to do to Taner Akcam - bundling loads of refs into one place in order to make the text editable. It would also make the "cite" templates more bearable - I can't stand the way they make it so hard to edit the text, in the common format where each item is on a new line. Rd232 ^talk 19:51, 11 July 2009 (UTC)

   By the way, I tend to remove line breaks in front of cite fields wherever I see it, and I haven't heard any squacking about it (yet). There's absolutely no reason to put line breaks in between fields of citation templates, and there is plenty of reason not to, as you've pointed out here. I think at least one of the template documentation pages actually says not to put the fields on new lines as well, and that could easily be standardized to all of them.
   — Ω (talk) 23:31, 11 July 2009 (UTC)

   Agree with the above.--Esprit15d • talk • contribs 11:31, 13 July 2009 (UTC)

8. Would quite elegantly solve the problem of orphaned references (currently bots do it). I also like the logical grouping of all the references together instead of mixing them in w/ article text. --Cybercobra (talk) 21:47, 11 July 2009 (UTC)
9. This would be a huge improvement towards improving usability for editors. This particular proposal was something that I was wishing for, a while ago.
10. As long as it's backward-compatible, and migration to the new system is easy. Sceptre ^(talk) 01:56, 12 July 2009 (UTC)
11. Per Sceptre. –Juliancolton | ^Talk 02:37, 12 July 2009 (UTC)
12. Page clutter -- a sea of templates -- is one of the most difficult barriers for new users to overcome, especially if those users aren't tech savvy. This would reduce that clutter considerably. Anything that makes the site easier to use is a Good Thing. – Luna Santin (talk) 03:34, 12 July 2009 (UTC)

    Assuming there will be constantly running bots to update this to create backwards compatibility.NW (Talk) 03:50, 12 July 2009 (UTC)

    Prefer option 4. NW (Talk) 16:10, 13 July 2009 (UTC)

13. Without question, this is my favourite. Much cleaner. Someone mentioned that this method may cause problems when moving text between articles, but I imagine it would be possible for a bot to automatically fix such orphaned refs...in fact, User:AnomieBOT is performing a very similar task right now (works really really well). — Huntster (t • @ • c) 09:32, 12 July 2009 (UTC)

    Yes, and anyway there are already problems when moving text between articles: depending on whether "ref defs" and "refs using defs" are present in the moved text or the remaining text, the move can result in cite errors in either or both places and it becomes necessary to play "hunt the ref def". The proposal will not worsen this and could improve it in cases where it's used well so that all the ref defs are found in one place. PL290 (talk) 10:03, 12 July 2009 (UTC)

14. A lovely plan. Also makes it easier to check/format all references in an article where people are using it. OrangeDog (talk • edits) 21:19, 12 July 2009 (UTC)
15. Most definitely. See my comment above for reasoning. Happy‑melon 22:16, 12 July 2009 (UTC)
16. This seems like a good idea (and per PL290's comments above, not a bad idea), but #2 would be fine too. Shreevatsa (talk) 22:54, 12 July 2009 (UTC)
17. This would be a significant improvement, particularly for new editors having to wade through refs and wikitext to find the text they want to change. Btw, whilst you're at it, is there any way of adding ==References=={{reflist}} automatically at the end of every article which has a ref tag? AndrewRT(Talk)(WMUK) 00:51, 13 July 2009 (UTC)

    Automatically appending a references section to articles where it is missing is already possible with appropriate changes to MediaWiki:Cite error refs without references. Dragons flight (talk) 09:07, 14 July 2009 (UTC)

18. I like this plan. The best of all worlds. I am very concerned about how this would be retrofitted to current articles.References are the literally the backbone of wikipedia, and yet, by their nature, they often get deleted, tampered with and otherwise compromised or destroyed because of technical issues or editor laziness. This could potentially exacerbate the problem exponentially without sufficient foresight and airtight bot execution.--Esprit15d • talk • contribs 11:31, 13 July 2009 (UTC)
19. Yes, as long as the current syntax remains available. (Not sure about the syntax, though—it's a bit too heavy IMHO.) —Ms2ger (talk) 11:47, 13 July 2009 (UTC)
20. Ruslik_Zero 19:29, 13 July 2009 (UTC)
21. Sure, this or option 2 would be great, as long as it is backwards compatible with existing usage. Plastikspork (talk) 20:40, 13 July 2009 (UTC) Although, it seems like this could be mostly achieved with the current {{ref}}/{{note}} system. Plastikspork (talk) 19:02, 16 July 2009 (UTC)
22. I support this option or something like #2. However, I can see an issue with adding/tweaking the reference while editing just a single section: only that section is visible, but the References section is not visible. Option #2 is slightly better, but still does not solve the problem of references used in multiple sections. Are references important enough to warrant their own edit box?—C45207 | Talk 04:13, 14 July 2009 (UTC)
23. Support. I have personally proposed this a long time ago[1]. This would be a huge step forward. The great thing is if this is done, and becomes the standard, it's easy to have a widget that lets you edit the contents of a {references /} block, even without full WYSIWYG. Stevage 07:25, 14 July 2009 (UTC)
24. Per discussion above. Amalthea 08:21, 14 July 2009 (UTC)
25. Yes, I support this syntax. It also urges editors to assign reference names, so that reuse of that reference on the page is facilitated. --Wikinaut (talk) 10:06, 14 July 2009 (UTC)
26. Yes, this is a really keen idea. It will make editing wikipedia articles 62% less intimidating. Kaldari (talk) 16:48, 14 July 2009 (UTC)
27. This prevents text clutter especially with very long refs. Strong support. —Ynhockey ^(Talk) 17:34, 14 July 2009 (UTC)
28. Yes, please. In articles that I've massively edited I have used the short-cite system just because I can't deal with the clutter of inline refs, but this would be much better. Looie496 (talk) 18:06, 14 July 2009 (UTC)
29. Support - I support both options listed. SharkD (talk) 19:17, 14 July 2009 (UTC)
30. Support This is the natural way to do it, at least for me. For those who prefer other ways, other ways remain available. Will greatly increase the readability of source text and facilitate editing . DGG (talk) 06:18, 15 July 2009 (UTC)
31. Support. Heavily cited articles can be almost uneditable as the citations overwhelm the text. I've often wished for the ability to have the information in a bibliography of some kind. This would address that.   Will Beback  talk  09:46, 15 July 2009 (UTC)
32. Support, this would be a good additional option to be used at the discretion of editors. Christopher Parham (talk) 11:08, 15 July 2009 (UTC)
33. Support gradual change. —Anonymous Dissident^Talk 16:15, 15 July 2009 (UTC)
34. Support. It's going to make it easier to edit Wikipedia. Tempshill (talk) 20:14, 15 July 2009 (UTC)
35. Support This will make it simple to add references, simple to scan the Edit page, and simple to edit the article. Gizza^{Discuss ©} 06:18, 16 July 2009 (UTC)
36. Support This is how it's done in LaTeX, and it's much more convenient both for editing the text and for editing the reference list. I hope this is implemented! Zvika (talk) 14:09, 16 July 2009 (UTC)
37. Support I've been always been wondering why this hasn't occurred to anyone else. Cite.php was broken because we didn't reinvent BibTeX yet. BibTeX did this right: If you put references in one place, they don't always break. So please make it more like BibTeX as long as you don't break existing stuff too badly. --wwwwolf (barks/growls) 17:47, 16 July 2009 (UTC)
38. Support I've begun my userpage plugging Bugzilla:5997, Bugzilla:2745, and Bugzilla:12796 for a while now. It's not difficult to bounce around and find references using the find (command). II | (t - c) 22:57, 16 July 2009 (UTC)
39. Support. The bigger the article, the greater the benefit. (Imagine a really, really huge article with lots of references. How is this in any way worse than what we have now?) For small articles this is not really beneficial but: 1) small articles aren't a problem, 2) there would be a choice between the two referencing styles anyway. GregorB (talk) 11:30, 19 July 2009 (UTC)
40. Support. This would make the content much easier to navigate for the new editors - a step in the right direction.--_{Piotr Konieczny aka Prokonsul Piotrus| talk} 17:10, 19 July 2009 (UTC)
41. Support if additional to, not replacement of, current system. For some articles the current system works just fine (usually shorter articles). Carlossuarez46 (talk) 23:13, 20 July 2009 (UTC)

Oppose #1

1. Strongest possible oppose As a content editor, I'd hate this. It'd mean that I'd need to be editing in two places simultaneously, which would be horrendous. Unless, of course, I've misunderstood the proposal - it's not really very comprehensible. --Dweller (talk) 12:37, 14 July 2009 (UTC)

   No, it doesn't mean that, since it's backward-compatible and you can continue using the existing system: when you insert a reference, you can insert it in-text, as you do now. Whenever any reference is used more than once (and this inevitably happens in any decently long Wikipedia article), you already have to edit "in two places simultaneously"; and this proposal doesn't make it any harder. Shreevatsa (talk) 14:26, 14 July 2009 (UTC)

   If I can continue using the existing system, what's the point of introducing a new one? I have no doubt that if you introduce this, MOS will be adapted to say it must be used and every FA I work on will have to comply. No thank you. I don't understand what you say about already having to work in more than one place. I've worked on some very long articles that refer many times to the same reference - I only have to insert it once, and it goes where I'm editing. Not in a completely different place at the foot. I get a sense that not enough quality content editors have been contributing here, probably because they're busy contributing quality content. I'll post at WT:FAC and see if some others disagree with me. --Dweller (talk) 17:53, 14 July 2009 (UTC)

   Sorry, Dweller, but your argument is very weak. The proposal is for more flexibility: you *can* define references in the footer - or in place. In a long article with multiple references to a single source, I think what will probably happen is people will start by defining them in place, then when that gets unwieldy, move the bigger ones to the footer. There's rarely a need to both modify the citation itself, and the reference to it at once: they're separate. And your claim about what the MoS will dictate is just spurious. Rejecting a proposal because you think the MoS will abuse it is extreme cynicism and bad faith. Stevage 05:56, 15 July 2009 (UTC)

   Dweller, you say about using the same reference many times: "I only have to insert it once, and it goes where I'm editing" - yet you complain about "editing in two places simultaneously", as if you don't need to edit in two places simultaneously right now, especially on very long articles you mention. That does not make any sense to me. GregorB (talk) 10:59, 19 July 2009 (UTC)

2. Weak Oppose One of the concepts in computer science is to put related code in close screen proximity. The more that one has to jump back and forth, the less efficient. Our current system has this problem when you have a named ref, and there's no easy way to find where it was defined. But instead of putting the ref closer, this solution pushes them all equally far away, which is probably not the ideal solution. This is in addition to the other drawbacks mentioned below, such as the fact that we can already do this without software changes, and the ease of orphaning refs, which was a bigger problem in the earlier days of wikipedia. Gigs (talk) 13:09, 14 July 2009 (UTC)

   "of the concepts in computer science is to put related code in close screen proximity" - well and truly trumped by factoring out detail. No computer scientist would propose inlining all function definitions. Certainly, it would be nice if there was a convenient way to get from a reference to the citation and back - but that's a usability issue, not a syntax one. Being able to remove the citations from the content is absolutely the right way to improve readability of wikitext. Stevage 06:10, 15 July 2009 (UTC)

3. Oppose. This will lead to references being defined and not used in the article (clutter) and/or references being used in the article without actually being defined. Any system that could lead to this potential mismash is not a good idea. Karanacs (talk) 18:27, 14 July 2009 (UTC)

   " This will lead to references being defined and not used in the article" - I doubt it, but it's actually not a bad thing. If there is a relevant source which for some reason is no longer associated with a particular sentence, we're better off retaining the citation. Currently, we would lose it altogether. Also, currently there is no way to smoothly integrate general references with specific ones. You do raise the issue that we haven't specified what will happen in this case yet.

   "and/or references being used in the article without actually being defined" - that's already possible. Nothing stops you writing<ref name="undefined" />. Has this become a big problem? Can you find a single example of this? In fact, the proposal makes this less likely, because there is less chance of someone deleting a reference which is relied on somewhere else. Stevage 06:10, 15 July 2009 (UTC)

   AnomieBOT fixed 1773 instances of the problem in June (some of those may have been reverted along with vandalism (e.g. if a vandal blanks a section, AnomieBOT fixes orphans resulting from that, and then someone reverts both edits)). Whether that qualifies as a "big" problem, I couldn't say. This proposal would help the "revised article and accidentally orphaned a ref" case, but exacerbate the "copy a fact from a different article" case; FWIW, the former is typically easier for AnomieBOT to fix than the latter. Anomie⚔ 18:31, 15 July 2009 (UTC)

4. Oppose. It's not clear from the proposal how it would work in an upward-compatible way. What if both the text and the references section define the same tag? What if there are duplicate tags in the reference section? How would templates like {{reflist|colwidth=30em}} work with the new system, or with a page that uses both the current and the proposed system? With the new system, can text refer to a preceding reference section? What if there are multiple reference sections? What can be nested inside a reference section other than refs? What happens if a reference is defined but not used? Just off the top of my head. Eubulides (talk) 23:03, 14 July 2009 (UTC)

   You're rejecting a proposal because its implementation details haven't been spec'ed out fully? Way to go. Ok, let's go through them:

   • What if both the text and the references section define the same tag?

   Good question. One of them presumably takes precedence. Let's say we have:

   "Text [ref name="foo"]www.foo.com[/ref] text text. [references] [ref name="foo"]www.foo.org[/ref] [/references]

   I would suggest that the in place reference's "name" field is ignored, and is treated as [ref]www.foo.com[/ref], since it clashes with another reference. This is most likely what the user intended.

   It doesn't sound right to ignore a name field. Wouldn't it be better to treat duplicate definitions the same, regardless of where they occur? But how would that work, exactly? Eubulides (talk) 02:11, 16 July 2009 (UTC)

   I think it's the best compromise. The local reference appears correctly. All other references use the definition defined in the [references] section. The only time it would be wrong is if one of the other references was supposed to use this local definition. Stevage 04:34, 16 July 2009 (UTC)

   • What if there are duplicate tags in the reference section?

   Ignore all after the first one.

   This seems to clash with the rule you proposed in the previous question's discussion. Eubulides (talk) 02:11, 16 July 2009 (UTC)

   • How would templates like {{reflist|colwidth=30em}} work with the new system, or with a page that uses both the current and the proposed system?

   I believe someone else has suggested a solution. I think I would prefer that references can be defined outside a [references /] block for this reason.

   Sorry, I missed that. Do you have a pointer to this other suggestion? Eubulides (talk) 02:11, 16 July 2009 (UTC)

   I was thinking of Amalthea's suggestion right up the top of this section - not really a solution, though, just a wish. Stevage 04:34, 16 July 2009 (UTC)

   • With the new system, can text refer to a preceding reference section?

   Sure, why not? The parser is not a recursive descent parser, so there's no particular cost in backtracking like that.

   Currently if you refer to a citation that isn't defined, there'll be a notice in the references section. But if you can refer to a preceding reference section, how will that still work with the new system? Eubulides (talk) 02:11, 16 July 2009 (UTC)

   Ask the developer. Stevage 04:34, 16 July 2009 (UTC)

   • What if there are multiple reference sections?

   What if? Currently they don't work very well. I imagine that wouldn't change.

   They don't work very well now, because there's no way to indicate which section a reference should go in. But with the proposed system, this would be easy to do, no? Eubulides (talk) 02:11, 16 July 2009 (UTC)

   • What can be nested inside a reference section other than refs?

   Nothing.

   Why not? And what happens if you go ahead and do it anyway? It would be useful, e.g., for Daylight saving time #References, which currently cannot be made 2-column because of the images. I'd like to put the images within the reference section. Eubulides (talk) 02:11, 16 July 2009 (UTC)

   Looks like the solution is a table, refs in one column, images in the other, no? Stevage 04:34, 16 July 2009 (UTC)

   • What happens if a reference is defined but not used?

   Good question (also raised by previous person). I suggest it is rendered, but obviously without any links to uses. Stevage 06:10, 15 July 2009 (UTC)

   That will lead to useless text in the article. It would be better to report a diagnostic, just as we do when a reference is used but not defined. Eubulides (talk) 02:11, 16 July 2009 (UTC)

5. Weak oppose. One of my pet peeves with the current implementation of named references (see remark under Option #3) is having to manually hunt for the definition when the ref is used in multiple places, especially in multiple sections. This proposal would increase the number of places one needs to look. ~ Ningauble (talk) 13:53, 15 July 2009 (UTC)

   Increase? Under this proposal, definitions would be in one place, whereas under the current implementation they might be anywhere in the article. GregorB (talk) 11:02, 19 July 2009 (UTC)

   On the contrary, the proposal is "backward compatible" so there would be a mix of inline definitions and definitions in the References section. ~ Ningauble (talk) 14:55, 19 July 2009 (UTC)

6. Strong oppose, obviously propsed by seomeone who doesn'tmreference or edit artciles or review them for GA or FA. I'd need two coputers just to co-ordinate what is foing on. Jezhotwells (talk) 14:05, 15 July 2009 (UTC)
7. Strong oppose. This is terrible: the referenced text and the actual reference will be split apart, leading to errors and refs pointing nowhere since they will be split into separate sections (and when refs are designed to increase reliability...). ChrisDHDR 18:51, 15 July 2009 (UTC)
8. Vehement Oppose Editors who add references do not want to have to add the ref tag on the statement and then make another edit to add the actual reference just for the sake of so-called clutter. It might move the cite templates out of the way, but it surely does not make editing any easier and only complicates things for new contributers. Reywas92^Talk 00:53, 16 July 2009 (UTC)

   The proposal does not require you to edit in two places; we could continue adding the reference just as we do now. A bot might later move it out of the way on request. Shreevatsa (talk) 05:14, 16 July 2009 (UTC)

   This just makes my oppose even stronger. Rather than millions of articles with a mostly uniform ref style, some will have citations after the statement, some at the bottom of the article, and some all over the place and you won't know where to edit. A bot will just complicate things further and ruin some of this uniformity. Reywas92^Talk 14:12, 16 July 2009 (UTC)

   Uniformity will still be there for the reader, and a bot can make near-uniformity happen. And how much confusion does this bring? Either it's in the ref section, or it's somewhere the text, and you need to use a combination of "find in page" and clicking the footnote-to-text links to find the ref: pretty similar to now. Except that newbies expect to find refs in the ref section, so if we can make that happen, it will make life easier for them. Rd232 ^talk 19:32, 16 July 2009 (UTC)

9. Strong oppose For an unusual reason. Every bit of complexity we add to the system makes it harder to use. Do you really think that brand new editors are going to be able to understand how this works on their first few edits? No. They're not going to even know what the hell <ref name="Frizoo43"> is for. They might think it has something to do with the font. They won't realize that it has anything to do with citations. So new editors won't leave us references; they won't be able to figure out how. The current system is ugly, sure, but it forces a new editor to see what is happening. Its sheer ugliness emphasizes its importance. Hopefully, it makes them realize that they are supposed to do something with those little tags. That's why I oppose this solution. I think the best solution is to add functionality to the editor that hides footnotes, as implemented in WikEd or the editor at in use at Appropedia:Sandbox. ----- CharlesGillingham (talk) 08:53, 16 July 2009 (UTC)

   newbies expect to find refs editable in the ref section, so if we can make that happen, it will make life easier for them. Rd232 ^talk 19:32, 16 July 2009 (UTC)

   It would certainly make life easier for vandals, if we break the link between the text and the source. This is a bad idea. Hiding T 08:39, 17 July 2009 (UTC)

   Can you explain that? I don't get that at all. WP:VANDALISM, in my experience, has very little to do with messing with references; and where it does, I still don't see that having the body of the ref in a different part of the article makes vandalism easier. Rd232 ^talk 08:51, 17 July 2009 (UTC)

   At any rate, the basic idea is that we want people to add content and references at the same time. There are tens of thousands of people who are doing this. We want to make it as easy as possible. Separating the content from the references makes it harder, not easier, to add some content and a reference. It makes it more likely that people will just add content, and forget about the reference. We need to keep the references where they are: next to the material they support. As I said above, the solution to unreadable wikitext is not to make it look like a computer program (e.g. <ref name="gobbledegook"/>) but to make it look something like Microsoft Word. This requires an enhanced editor, which makes it easy to see that there is a footnote inserted here, and that you're expected to use footnotes with citations when you edit. ---- CharlesGillingham (talk) 09:20, 17 July 2009 (UTC)

   My experience of vandalism obviously differs to yours, since I've encountered vandals who like to play with references and also vandals who like to add "referenced" material to Wikipedia. I can also recall when we had this system before and undoing vandalism was a lot harder because with references and text un-linked, reconstructing an article after a while can become incredibly hard if vandalism is buried in the page history. This proposal is going to make article editing harder, weirdly enough, because of the disconnect. I appreciate what people are trying to do, but this isn;t the right solution. The right solution would be some sort of way of allowing editing with references or without references, I'm not sure if such a thing is possible though? Hiding T 22:28, 17 July 2009 (UTC)

   In my experience, 9 times out of 10, broken references are due to bona fide (or almost bona fide) cuts - not outright vandalism - that remove the definition, and leave the rest dangling. This is very difficult to fix if not spotted immediately (i.e. if dozens of article revisions intervene). One more thing: brand new editors are "not going to even know what the hell <ref name="Frizoo43"> is for" - yet, somehow, they do now? GregorB (talk) 11:13, 19 July 2009 (UTC)

   No they don't. That's my point. This proposal claims it would be better if all the footnotes were of the form <ref name="GRZ">. I claim this syntax is too hard to understand at first glance. I argue that a "rich text" method ("click on this and edit the footnote") is what new users need. ----CharlesGillingham (talk) 09:33, 20 July 2009 (UTC)

10. Strong oppose The current system works and is easily understood - the actual formatting of the refs on first use is where the inexperienced slip up. The reference text is where it should be, and any problem with "clutter" is instantly resolved using WikiEd to colour the text. Jimfbleak - talk to me? 15:00, 16 July 2009 (UTC)

    I defy you to look at the wikitext of this version of Taner Akcam and tell me the current system works for loads of inline refs using cite templates. Rd232 ^talk 19:35, 16 July 2009 (UTC)

    I couldn't agree more, but that is a problem caused by citation templates. There's no need to use templates with the current ref system. SlimVirgin ^{talk|contribs} 22:37, 17 July 2009 (UTC)

    I disagree that citation templates are the cause of the problem and that hand-crafted citations would supply any improvement. For past discussion and horrible examples, see this and do a text search for "Example of the kind of problem templates cause" and for "hand-formated inline citations". Wtmitchell (talk) (earlier Boracay Bill) 02:36, 18 July 2009 (UTC)

11. Oppose, retrograde step. This is how we used to do it, and was incredibly unwieldy. Hiding T 08:36, 17 July 2009 (UTC)

    The problem with comparing it is that we didn't have a choice then, except by using parenthetical citations. There will still be the ability to use the current system, i.e., you get a choice. Without having double checked, I'm fairly certain the first major contributor gets their say in how citations are dealt with, so, I'm not sure this is really cause for concern in this way. The points that some others bring up... possibly concerning. --Izno (talk) 06:05, 18 July 2009 (UTC)

    Don't follow you at all, and in this instance we can't actually fall back on the first major contributor since many articles were created before we had any ability to footnote at all. You haven't addressed any of the flaws that this system demonstrably has, so I fail to see how you can dismiss my opposition. This system is unwieldy, counter-intuitive and didn't work. No-one has demonstrated why it will work this time around. Hiding T 09:44, 22 July 2009 (UTC)

Comments #1

This is simply a repeat of history. We used to do references like this with templates until <ref> was implemented. When we used {{ref}} templates, references would very often get separated when paragraphs were moved between articles and such. You would end up with orphaned references, missing references, etc. It was a mess. We need proper code folding of references in the text area, in my opinion. That, or split them out entirely into their own namespace. --MZMcBride (talk) 20:10, 11 July 2009 (UTC)

This did seem vaguely familiar from the misty past. Gigs (talk) 18:53, 13 July 2009 (UTC)

I'm not sure how no one has realized that this system is already possible. You just use ref tags in the body of the article and cite id tags at the bottom. See GRB 970508. There's really no need to screw up existing articles in order to achieve functionality that already exists. --Cryptic C62 · Talk 01:22, 14 July 2009 (UTC)

To quote myself from above: "That's rather different, I'd say. The style used there is a compromise that can be useful in particular if many refs go to different pages of the same book. I personally find that style less useful, from a reader's point of view, cause I have to click the inline ref and the "Notes" item to get to the actual reference. Furthermore, if all you have are sources to online articles, without any page numbers, that system loses all advantages in my opinion, since you effectively duplicate all refs. Easier for the editor, while less useful for the reader, whereas the proposed system won't necessitate a visual change." Amalthea 08:20, 14 July 2009 (UTC)

• I wonder if I am confused about what proposal #2 is about. My understanding (do correct me if I'm wrong) is that the reference definitions (e.g., something like "<ref>{{citation|...}}.</ref>") would be grouped at the end of each section to enable section editing to be carried out, but that the actual block of references or footnotes (created by </references> or {{reflist}}) would continue to be in the "Notes" section at the end of the article. If this is what proposal #2 is, then I prefer it to proposal #1. — Cheers, JackLee ^–talk– 05:30, 14 July 2009 (UTC)
• Comment It would be nice if the proposal could summarise what problem/s it's trying to address... --Dweller (talk) 12:41, 14 July 2009 (UTC)
  • Mainly clutter and intimidating markup, which affects even experienced users. See the conversation in the section immediately preceding the proposal, in particular Happy‑melon's comment and the usability study video. Shreevatsa (talk) 16:35, 14 July 2009 (UTC)
    • If this is intended to address issue of edit-pane clutter and intimidating markup caused by the practice of including the full specifications (author, year, title, editors, publisher, links, etc) of a cited reference work as an inline cite btw <ref></ref> tags, then it should be noted that we already have perfectly valid referencing system options that do exactly this, in a simple, intuitive and no-fuss manner—namely WP:CITESHORT or parenthetical referencing. In fact, option #1 in essence is only doing just what these accomplish—reducing the inline citation (either inside <ref></ref> tags or as inline parentheses) to a brief identifier string, while recording the fully expanded source reference one-time-only in a separate section dedicated to the purpose. The only difference is that in this option there'll be a clickable anchor connecting the citation and the source reference, however this can also be achieved for CITESHORT or PARENS where it is thought beneficial (but it's hardly necessary, and it doesn't work for 'small' articles or when you're already at the bottom of the page).

      Out of the 5 general classes of referencing systems described at WP:CITE, the issue this is trying to address is really a problem for only one of these, #2 [full] footnote system (possibly #5 embedded links also, but that's generally deprecated anyway). I'd agree that it is an issue for the 'full footnote' system (one of the reasons I avoid that system wherever I can, but it has several other serious deficiencies as well.) But it is not an issue for these others. Any proposal to alter the technical functioning of cites/refs must bear in mind that these other valid referencing systems exist, function perfectly fine the way they are, and need to continue to function as they do. If it could be implemented so that there is absolutely zero impact or change to the way CITESHORT and PARENS work currently, including the option of not requiring so-called "named references" (quite unneeded for CITESHORT), then well and good, I suppose. But I'm not seeing if this would be the case; would the tag <references/> on its own still just generate a numbered list compiling all the entries between <ref></ref> tags? Would all the ref tags have to be labeled ('named references') now? Presumably section editing & previewing with ref tags would still work (for previewing, it's a simple matter to add a temporary {reflist} when previewing to see how the section's refs will look)?

      If anything, the implication of this proposal and some general agreement that there are issues with the 'full footnote' system, is an argument to move away from the 'full footnote' system altogether, which I personally think is not a bad idea...--cjllw ʘ TALK 04:08, 15 July 2009 (UTC)

      • The mention of #3 shortened footnotes and #4 parenthetical referencing is mostly a red herring, since they are applicable mainly when sources used are books, when in fact sources used on most Wikipedia articles are websites, newspapers, and the like. And #1 ("general references") usually attracts a {{No footnotes}} template; inline citations are a good thing. So while I use #3 and #4 myself whenever possible, #2 (full footnotes) is really what is used on most articles, and convincing everyone to move away from it is infeasible. And yes, this proposal would not affect the way CITESHORT and PARENS work, would not require all refs to be named, and section editing and previewing would presumably still work as they do now (i.e., work when the ref is defined not elsewhere but inside the section, which is the case when you're adding the refs you want to preview). Shreevatsa (talk) 14:06, 15 July 2009 (UTC)
      • Bibliography-style referencing systems like citeshort & parenthetical referencing handle the full gamut of source types, not just books and journal articles. Websites, newspaper articles, audio-visual content, the works—there's nothing to stop these being entered in bibliography-style systems too. All you need is the name of the content's author (person/s or corporate identity primarily responsible, if genuinely unknown put anon.), a name assigned for the work, and publication date (or accessdate, or if unknown just use n.d.). Every source has at least these basic elements, and most will have many more identifying elements besides (I would be worried if we were using sources that did not have this accompanying identifying information). There is nothing that #2 full footnotes can do, that bibliography-style referencing systems like #3 citeshort & #4 parens cannot also do. However there are several other key things that bibliography-style referencing systems provide, that full footnotes cannot, which is why I for one avoid it wherever I may. But I'm under no illusions that it's going to be abandoned any time soon; I'm only commenting that these proposals seem to highlight some of its deficiencies, that are not shared by biblio-style referencing. And while the intention seems to be that the current implementation of citeshort and parens should not be affected in any way by the proposals, without any actual technical spec & review to go by (this is a concept proposal), it is still to be seen.--cjllw ʘ TALK 15:48, 15 July 2009 (UTC)

Option #2: Allow reference content to be defined anywhere

Alter <ref> so that the content of references may be defined (without being displayed) at any arbitrary point within the page. For example, references could be collected at the end of the first section in which they occur. Each call to the reference, including the first one, would then be identified by the name parameter.

Example

Lorem ipsum dolor sit amet<ref name="foo" />, consectetur adipisicing elit, 
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.<ref name="bar" />

<ref definition name="foo">abcde</ref>
<ref definition name="bar">xyz</ref>

== References ==

<references/>

Note: The exact syntax for implementing this is still subject to further discussion and possible changes.

Support #2

1. I don't think the cleaner wikitext is worth losing the ability to easily edit a section. My personal preference would be to separate them from the main textarea altogether, but failing that, this would be better. Mr.Z-man 15:22, 11 July 2009 (UTC)
2. More or less support - I think something along the lines of the "definition" flag is necessary in order to maintain backward-compatibility. It could also be incorporated into the tag name (i.e. refdef) or into the "name" parameter (i.e. ref namedef=""). SharkD (talk) 02:41, 12 July 2009 (UTC)
3. I agree, for the reasons given by Z-man. — Cheers, JackLee ^–talk– 08:36, 12 July 2009 (UTC)
4. Am I allowed to vote twice...? Can't make up my mind. –Juliancolton | ^Talk 16:16, 12 July 2009 (UTC)
   • I don't see why not. :-) — Cheers, JackLee ^–talk– 17:08, 12 July 2009 (UTC)
5. I believe I proposed something like this above, so I ought to vote here :) But #1 would be fine too. Shreevatsa (talk) 22:54, 12 July 2009 (UTC)
6. May be useful, and would certainly be better than nothing to declutter wiki text, but #1 would be better in my view. AndrewRT(Talk)(WMUK) 00:52, 13 July 2009 (UTC)

   Sure, this or option 1 would be great, as long as it is backwards compatible with existing usage. Plastikspork (talk) 20:40, 13 July 2009 (UTC) (moved to oppose) Plastikspork (talk) 18:57, 16 July 2009 (UTC)

Oppose #2

1. Strong oppose As a copyeditor, this would also be horrendous. I'd have to scan the entire text to find where someone had dumped the details of a ref I'm working on. --Dweller (talk) 12:39, 14 July 2009 (UTC)

Absolutely; but you already have to do exactly that! (When ref names are used.) So I can't understand why you don't like #1, which makes possible what currently isn't: to dump all the details in one place. Not everyone will have to use the feature, but where someone has done, your editing will be enhanced. PL290 (talk) 19:41, 15 July 2009 (UTC)

1. Oppose for the exact same reasons that Dweller just mentioned. I do a lot of gnoming and copyediting, and this would make those jobs so much more difficult. More harm would come from this than good. hmwithτ 16:07, 14 July 2009 (UTC)
2. Oppose for same reason as my oppose to option 1. Also, as Dweller says, this will make copyediting horrendous. Karanacs (talk) 18:27, 14 July 2009 (UTC)
3. Strong oppose This is a superset of #1 but brings no advantages over #1, its additional freedom merely undermining one of #1's two benefits by perpetuating the current distribution of refdefs throughought the prose so that they have to be hunted down during article-to-article moves involving ref names. PL290 (talk) 19:12, 14 July 2009 (UTC)
4. Per Dweller. The separation of the contents of the ref from the citation tags themselves would be confusing. Dabomb87 (talk) 20:48, 14 July 2009 (UTC)
5. Making the wikitext layout more like the published page may seem logical and easier to edit but I think it would lead to problems. Keeping the references in line with the associated facts means they are likely to stay with those facts. It makes it much easier to reuse the text.filceolaire (talk) 21:25, 14 July 2009 (UTC)
6. Strong oppose. Manually hunting for named ref definitions is enough of a nuisance already without making them invisible! ~ Ningauble (talk) 13:56, 15 July 2009 (UTC)
7. Strong oppose. What a remarkably dumb idea! References belong alonmgside associated statements. Then they can be checked by editirs and artcile reviewers. Putting them elsewhere has to be one of the most stupid ideas I have seen. Jezhotwells (talk) 14:02, 15 July 2009 (UTC)
8. Even stronger oppose. The ref link, the ref text, and where the ref shows up are all split up, leading only to confusion, errors and refs (links and texts) leading nowhere. A simply terrible idea. ChrisDHDR 18:56, 15 July 2009 (UTC)
9. This retains the few disadvantages of the general idea (allowing all references to be declared away from their point of display, not just duplicate refs), with none of the benefits. Happy‑melon 22:34, 15 July 2009 (UTC)
10. Vehement Oppose As an editor, I want my references where they reference something, not hidden elsewhere in the article. Reywas92^Talk 00:43, 16 July 2009 (UTC)
11. Oppose There is already the {{ref}}/{{note}} convention if someone wants to use that citation style. Plastikspork (talk) 18:57, 16 July 2009 (UTC)
12. Oppose. Not very different from how it is now, worse then proposal 1 above. --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 17:10, 19 July 2009 (UTC)
13. Strong oppose, confusing and makes referencing an even bigger headache. No benefit at all and only weakens consistency and referencing standards. -- Collectonian (talk · contribs) 19:00, 19 July 2009 (UTC)
14. Oppose if we can't know where to look for it, it's hard to find. Also, there is the wonderful occurence when someone adds a different definition of the same source name and you have to find which is being accepted by the parser. Argh. Carlossuarez46 (talk) 23:15, 20 July 2009 (UTC)

Comments #2

• My thoughts:
  • I see this proposal as at least no worse than proposal #1, and probably better. My understanding of proposal #2 is that reference definitions will be placed at the end of each section rather than in a block towards the end of the article. This will (1) clear the reference definitions out of the body text in each section, thus making the text easier to read; (2) still keep the references in fairly close proximity to the text to which they relate; and (3) enable section editing to be carried out which, for me, is what gives this proposal an edge over proposal #1. The reservation I have about proposal #1 is that one would always have to have the whole article open in order to jump between the body text and the reference definition block at the end of the article.
  • It is true that searching for reference definitions in proposal #2 will be slightly harder than in proposal #1, since in proposal #2 the definitions appear at the end of each section rather than all together at the end of the article. However, searching for the definitions in proposal #2 will be no more difficult than it is at present. In fact, it will probably be slightly easier because the definitions will be grouped together at the end of each section rather than embedded in the body text. Anyway, with the use of the "Find" command (CTRL-F) searching for references is not really a huge problem.
  • As regards ChrisDHDR's comment, one doesn't really need to worry about where the references eventually show up. I believe they will continue to be in a "Notes" section towards the end of the article. — Cheers, JackLee ^–talk– 19:53, 15 July 2009 (UTC)

• In addition to what Jacklee said above, I don't understand many of the oppose votes above, which imagine that references will get placed at arbitrary points in the article instead of as close as possible to their first use (or wherever they are defined now). Why would anyone be so deliberately perverse? Shreevatsa (talk) 05:24, 16 July 2009 (UTC)

  Where is a 'sensible' place to define a citation? Where the numbered link appears in the text is certainly defensible, although it has the problems espoused above of horribly breaking up the text. Where the references are actually displayed at the bottom of the article is certainly also defensible. Where else would it make sense to define references?? Nowhere. So why encourage such behaviour? The issue is not one of being "deliberately perverse", but rather of what makes 'sense' to one person not being intuitive to another. Maybe one editor's preference is to define each reference at the bottom of the section where it first appears: that seems defensible, certainly. Then the reference is used in another section, later in the article; fair enough. Then the original section is rewritten and the first use of the reference is removed, but the editor forgets to move the citation (fair enough, since it would be needless additional work to work out where to move it to). Now, without any perversity, we have a reference in one section drawing on a definition at a totally "arbitrary point in the article". Why expose ourselves to that problem? Happy‑melon 18:56, 19 July 2009 (UTC)

Option #3: Wait for something else / do nothing

This is the option for perserving the status quo, at least until something better comes along. For example, the widespread adoption of a WYSIWYG editor could remove the problem of reference clutter without any other modifications to the reference system. Alternatively, a more comprehensive system could create a separate interface (and edit box) for manipulating references. Such things may be possible, but they are longer-term solutions that could not be immediately implemented.

Support #3

1. There working on it now at http://usability.wikimedia.org/wiki/Main_Page. It's supposed to come out in January, I think. Neither of the two above ways really make it that easy, and they can also lead to orphaned refs. It they don't come up with something, then someone here needs to make the WYSWYG. - Peregrine Fisher (talk) (contribs) 21:49, 11 July 2009 (UTC)
2. Support. These proposals both exacerbate the tedium of manually hunting for the definitions of named references by increasing the number of places to check. This is already my No. 2 pet peeve with the current implementation of named references. If a mechanism for traversing an implicit link to the definition were available then the proposals would be more attractive and I would support option #1. My No. 1 pet peeve is that, when editing a section, references are not supported by WYPIWYG ("P" for Preview, never mind WYSIWYG). Aargh! ~ Ningauble (talk) 14:01, 15 July 2009 (UTC)
3. Don't waste the programmers' timeShii (tock) 05:00, 17 July 2009 (UTC)

   The programmer who's time would be spent on this has initiated this RFC, with willingness and intent to implement this change if it is found to be an improvement. It's really not for you to say what would be a waste of his time. Amalthea 13:55, 17 July 2009 (UTC)

Oppose #3

1. WYSIWYG is not coming along anytime soon. Nor is any other solution. Waiting for Godot is a stupid solution. Stevage 07:33, 14 July 2009 (UTC)

Incorrect. See these Wikipedia WYSIWYG (or WYSIWYM) editors: [2]. The best one is the UNESCO designed one. ---- CharlesGillingham (talk) 08:20, 16 July 2009 (UTC)

This rich text editor is apparently already in use on Appropedia. You can play with it, at Appropedia:Sandbox. ---- CharlesGillingham (talk) 08:37, 16 July 2009 (UTC)

Another one is WikEd ---- CharlesGillingham (talk) 09:02, 16 July 2009 (UTC)

1. Technology is always changing. Reasons for waiting would be (a) prohibitive implementation cost/complexity or (b) concern about loss of backward compatibility. Neither applies in this case as far as I can see from what's been said. So while we wait, let's also use the better solution being proposed. PL290 (talk) 19:11, 14 July 2009 (UTC)

Option #4: Wait for rich text interface

Apparently a rich text interface is being considered for ease of use. Many of these take extensions, meaning that when available then <ref>...</ref> tags could in principle be collapsed into a yellow highlighted word "ref", which users can click to edit. Long term that's probably quite a nice solution, especially as this kind of interface is (apparently) likely to be under consideration already. FT2 ^{(Talk | email)} 08:33, 12 July 2009 (UTC)

Support Option #4

1. NW (Talk) 16:10, 13 July 2009 (UTC)
2. CharlesGillingham (talk) 21:48, 15 July 2009 (UTC)

Comments #4

Can't something like this be done in javascript, right now? Gigs (talk) 18:54, 13 July 2009 (UTC)

If you add a tag {{reflist}} to the bottom of any section that is being edited, the references for the block will be visible in the preview. I suggest that this should be the default view for editing. Twocs (talk) 06:07, 15 July 2009 (UTC)

Note that WikEd has already implemented this, so it is certainly feasible in the near term. ---- CharlesGillingham (talk) 21:46, 15 July 2009 (UTC) There is also a (slightly buggy) wysiwyg editor in use on Appropedia. See Appropedia:Sandbox ---- CharlesGillingham (talk) 09:04, 16 July 2009 (UTC)

Comments on improving <Ref>

I'm jumping into this discussion late (and necessarily briefly as I will be leaving on vacation in a week or two). Let me identify myself right away as the person behind Bugzilla:18890 (to which, incidentally, I am not wedded, and for which a test wiki running that proposed enhancement is available at http://siteslot.com/testwiki2. I do urge anyone interested to click over to that test wiki and to take the added functionality for a test drive. Create an account ... or not. Clone the content of some Wikipedia pages there and try moving some or all of the <Ref>s on those pages into <Ref def ...>s, as illustrated on the main page there. I think that you will find that the functionality there is similar to what is being discussed here.). Wtmitchell (talk) (earlier Boracay Bill) 08:22, 14 July 2009 (UTC)

Centralized References

(copied from below) It has been proposed in several places (see, e.g, this essay) that wikipedia centralize its references, perhaps as part of the wiki commons. That is, every journal article, newspaper article, book, etc, would have a single entry in a centralized database. Wikipedia articles would then include in-line references to the database (which could be collected at the bottom of the page, if desired). Such a system seems much better than the current potpourri of referencing conventions currently in use, solving several problems at once. And, it has been implemented elsewhere. See Quantiki, which implements bibwiki, as an example.

Is there a consensus on the suitability and feasibility of this idea? Has it stalled? I looked at Wikipedia:WikiProject_Wikicite but it didn't seem to directly discuss this. Njerseyguy (talk) 22:01, 16 July 2009 (UTC)

• What a wonderful idea. Carlossuarez46 (talk) 23:17, 20 July 2009 (UTC)

Mediawiki, Wikipedia, and <Ref>

Most participants in this discussion are probably aware that <Ref> is not a Wikipedia thing, but there are probably some participants who are not aware of that. Just to clarify, Wikis are done using Mediawiki software which runs on a web server. That software is used by a lot of users other than Wikipedia. Extensions may be added to that software. One extension which is used by Wikipedia and by a lot of people.projects/organizations outside of Wikipedia is Mediawiki:Extension:Cite, which does <Ref>s.

What is being discussed here, I think, is a proposal to (1) modify the Cite extension at Mediawiki (2) in a way which would add additional functionality and in a way which would be transparently 100.00 percent backwards compatible with current functionality. We may or may not be contemplating here bypassing the Wikipedia:Bug reports and feature requests process. I hope that what is being discussed here is not a proposal to separate the Cite extension used by Wikipedia from the Cite extension distributed by Mediawiki. Wtmitchell (talk) (earlier Boracay Bill) 08:22, 14 July 2009 (UTC)

Yes, it would be a modification of the Cite extension for everyone, and yes it would be 100% backwards compatible. Dragons flight (talk) 09:13, 14 July 2009 (UTC)

Enhanced editor

An enhanced editor which would (optionally, I presume) allow multiple edit windows to be opened into different parts of an article undergoing editing (one window, say, into the article prose containing <Ref name=whatever />s and another window, say, into point in that article where a block with corresponding <Ref name=whatever>Ref body</Ref>s or <Ref def name=whatever>Ref body</Ref>s are placed) is an idea which I would urge be considered separately from the idea of improving <Ref>. Wtmitchell (talk) (earlier Boracay Bill) 08:22, 14 July 2009 (UTC)

The editor at Appropedia:Sandbox uses a pop up dialog box to edit references. (Push the "r" icon up at the top to open a reference.) WikEd opens or closes the footnote inside the text of the editor. So this functionality is certainly feasible in Wikipedia. ---- CharlesGillingham (talk) 09:06, 16 July 2009 (UTC)

Comma vs. period in references

I think all references across the project should use the same format. How about once and for all deciding whether commas or periods should be used to separate items within footnotes and reference lists? The citation templates could then be updated and maybe even merged in some cases which would make them easier to maintain and hopefully result in fewer bugs and inconsistencies. Tocant (talk) 12:39, 9 July 2009 (UTC)

I agree, but I believe this is one of those perennial proposals that never seems to gain consensus one way or another. Search the archives of this talk page to find the previous discussions on the matter. Personally, I think commas make more sense because when you have more than one reference in a footnote you can more easily tell where one reference ends and another begins. — Cheers, JackLee ^–talk– 12:57, 9 July 2009 (UTC)

I expect we'll do this right after the rest of the world decides whether they prefer MLA style, APA style, CMS style, or something else. Given that multiple legitimate formatting styles exist—and each has good reasons for being used in certain contexts—I think it's better to accept all of them (but constrain ourselves to existing styles) rather than inventing our own, consistent style (but having it incompatible with any of the normal styles used in other writing). Kirill ^[talk] [pf] 13:15, 9 July 2009 (UTC)

The current styles may have been an attempt to achieve consensus among editors since no one could agree on any one existing style. But then I wasn't around when those discussions took place, so I can't really say. :-) — Cheers, JackLee ^–talk– 13:20, 9 July 2009 (UTC)

I think it is better to use a consistent "Wikipedia style", preferably as a php extension so that the templates could be deleted. Tocant (talk) 13:22, 9 July 2009 (UTC)

I don't know what a php extension is, so I have no idea how that would work. But let me point out what the magnitude of creating a Wikipedia style would be.

Editors in the midst of writing an article will not and should not stop writing until a programmer adds support for some new kind of source. There is no chance that the programming of templates, php extensions, or anything else will cover all possible sources. Therefore, a Wikipedia citation style manual would have to be written, both to guide the programming, and to explain how to manually format sources that are not supported by the programming. The APA style manual has about 80 pages devoted to citations; I see no reason why a Wikipedia citation style manual would be any shorter. --Jc3s5h (talk) 13:40, 9 July 2009 (UTC)

It doesn't have to be any shorter and it doesn't have to be finished any time soon, it could take a year or two. Or a preexisting style could be chosen, does it really matter which one as long it is consistent? Tocant (talk) 15:09, 9 July 2009 (UTC)

Why do you think that consistency across the whole of Wikipedia is desirable? --PBS (talk) 19:54, 9 July 2009 (UTC)

Different styles on different pages doesn't look good. Also, the citation templates are buggy and overly complex since they need to support lots of different styles, with one clearly defined style it would be possible to have a cleaner code base. Tocant (talk) 20:28, 9 July 2009 (UTC)

I agree with Tocant and JackLee that a consistent citation style would improve Wikipedia. To answer Philip's question, the argument for consistency has three main points, in my view: (1) It would make it easier for new editors to learn how to use citations, (2) it would simplify the development of automated tools to improve citations and (3) it would give Wikipedia a more professional appearance. I also agree with Tocant that there is no reason why there can't be a "Wikipedia style" that is every bit as well developed and specific as APA style or MLA style. And I certainly agree that the commas-vs-periods issue is never worth fighting over.

However, to implement a consistent style in Wikipedia requires WP:consensus, not just between the editors who happen to be watching this page, but all the editors of Wikipedia. So I don't agree that there is a technological solution that is substantially better than the templates, or a solution that involves changing any guideline or the manual of style. There is only one method that respects the opinions of all of Wikipedia's editors. We must unify the citation methods one article at at a time, gaining the consensus of local editors before making any changes.

Note that all the major citation templates have already been unified, thanks to the work of Martin Smith and others. The only substantial difference between the templates is commas and periods, at this point. With this in mind, we can certainly unify the articles that use the major citation templates. We simply replace {{citation}} with the more commonplace versions, such as, {{cite book}}, {{cite news}}, etc., which is a trivial change for most articles. I think the vast majority of local editors would not object to this change. The articles that don't use citation templates are another matter all together—they use a variety of idiosyncratic formats which can't be so easily unified. ---- CharlesGillingham (talk) 21:53, 9 July 2009 (UTC)

Well, I'm going to have to disagree with you slightly there. I believe {{Citation}} to be superior to the {{Cite xxx}} series of templates because I do not think it is a good idea to have separate citation templates for different types of material. Also, the {{Cite xxx}} series uses full stops instead of commas as separators, and as I have mentioned above I don't think this is a good idea either. (And perhaps this is an example of why it will be difficult to standardize on one single citation format.) — Cheers, JackLee ^–talk– 05:15, 10 July 2009 (UTC)

Many people, however, have an opposite view, believing that full stops are better than commas, and that having separate citation templates for the different types is a good thing. Different types of citations (books, journals, media, web, etc) may need to have different formats, because they are describing different things and often have different requirements. I use the Cite XXX templates myself because I prefer the parameter setup (and really can't stand the unnecessary and often extreme complexity of Citation), but if a single, unified, logical and simple system were developed that could account for all the various needs, I wouldn't be against its deployment and the phasing out of everything else. I too agree that a unified system for citations on Wiki would be good, but I do not believe there is any currently available system that is ready to become the standard.

As for the comma/full stop issue, I prefer full stops because it better sets sections of text apart from one another, since different sections may contain commas themselves (and rarely contain full stops). I don't understand your original argument for the commas, since all citations should theoretically be isolated on separate lines with leading bullets, so I'm not sure how one could be confused with another. Can you clarify or expound on this preference? — Huntster (t • @ • c) 05:49, 10 July 2009 (UTC)

Well, this is an example of why we haven't yet been able to settle on a single form of citation :-). I agree that citations in a "References" or "Further reading" section should be on separate lines with leading bullets, but I often string a series of citations together in a footnote, separated by semicolons. In those situations having the elements of the citation separated by full stops makes less sense. The alternative is to put each citation into its own footnote, but I find multiple footnote numbers^{[1][2][3][4][5]} unsightly and try to combine references into as few footnotes as I can. — Cheers, JackLee ^–talk– 06:36, 10 July 2009 (UTC)

I use the Cite XXX templates and try to fill in as much information as I can. The extra work is not a big deal. SharkD (talk) 08:32, 10 July 2009 (UTC)

Jacklee, to be honest, I don't think I've ever seeing multiple references strung together inside a single "ref" before, and I rather strongly disagree with that practice, because it makes it more difficult (not so much for experienced editors, but perhaps moreso for newbies) to reuse one of the citations elsewhere. Yes, the string of numbers isn't ideal, but there isn't anything wrong with it either...just a minor cosmetic thing. Better than repetitive instances of a single ref, because one was locked into a group and couldn't be reused. — Huntster (t • @ • c) 08:58, 10 July 2009 (UTC)

We are deviating from the original point so I won't say much more about this, but of course if a reference needs to be reused elsewhere then it has to be in a footnote of its own. But if some references are not referred to in other parts of an article, I personally see nothing wrong with putting them into one footnote (see, for example, footnote 48 of "Han Sai Por"). — Cheers, JackLee ^–talk– 15:48, 10 July 2009 (UTC)

My point was supposed to be that it doesn't matter very much. What does matter is that it is easy for new editors to create citations. To shorten the learning curve, we should simplify the system. If we want to simplify, we have to make it more consistent. To make it more consistent, we have to be willing to compromise about the little things. ---- CharlesGillingham (talk) 09:21, 10 July 2009 (UTC)

I agree. Of course, much depends on what one considers "little things" :-). And right now, it appears that a lot of editors do not consider "commas v. full stops" a little thing. — Cheers, JackLee ^–talk– 15:48, 10 July 2009 (UTC)

Although there's room to accomplish this by simplifying relevant templates, the most important thing is to stress to new editors that a simple embedded link is 90% as good as a full citation ready for FAC. Previous versions of this page made that rather clearer ("If you don't know how to format a citation, provide as much information as you can, and others will help to write it correctly." was in the lead), perhaps some language to that effect should be reintroduced. Christopher Parham (talk) 14:21, 13 July 2009 (UTC)

Actually, I thought the lead paragraph was pretty clear about this: "How to format. While you should attempt to format a citation as described in the How to format citations section of this guideline, it is even more important that material in Wikipedia is verifiable. Add your source even if you are unsure of how to properly format the citation—provide enough information to identify the source, and others will improve the formatting." — Cheers, JackLee ^–talk– 15:14, 13 July 2009 (UTC)

As a huge reference contributor (sometimes I go into articles and all I do is add references or clean up the existing references) i can say that (1) the vast majority of people don't give a flying flip about formatting references anyway. They stick a url in ref tags or put all pertinent information in ref tags and bolt. I don't think any system would keep people who find that reffing is too tedious from doing that. (2) Wikipedia is ultimately an academic endeavor. I would be highly wary of just coming up with a new consolidated reference system. The current one has been culled from already well-established reference norms in the greater journalistic community. We should put forth some effort to keep with larger academic protocol to maintain respect. (3) If we do simplify, which could be good, we should keep in mind that difference sources have really different needs. Citing a journal, a newspaper, an interview, a magazine article, a television show and a YouTube video has different requirements, and really should be treated accordingly. I'm not against change, and I personally loathe the current citation templates and NEVER use them, but just saying "one citation template to keep it easy" is oversimplifying the issue. I would recommend having a Wikipedia process like Twinkle where you have a series of drop down menus that narrow down which fields are relevant and then auto-formats it. That makes it simple without compromising academic integrity.--Esprit15d • talk • contribs 11:49, 13 July 2009 (UTC)

"One template to rule them all, ... and in the darkness bind them"? :-) I don't disagree that different types of material may have different citation requirements, but would just point out that there still ought to be some attempt to streamline them. No point having the year of publication in front of the title in one case and behind it in another. I'm sure that the editors who work tirelessly to improve the {{cite}} family of templates are well aware of this. — Cheers, JackLee ^–talk– 12:36, 13 July 2009 (UTC)

Except that, in some scholarly fields eg in hard sciences, the year of publication can be quite significant (the state of knowledge can date rather quickly, within a decade or less), and traditionally it's brought to the fore. In other fields eg literature & the classics, the name of the publication is more relevant than year of publication (& literary works & sources may be republished many, many times, more so than scientific papers). It's horses for courses; either author-date or author-title makes equal sense in the right contexts, as long as it's consistent within an article I don't see benefits to impose tight uniformity across articles that cover very different fields and have their own 'traditional' way of doing it, that (presumably) those writing articles in that field are familiar with. Agree with Espirit15d's points. And on a practical level, the chances of getting everyone to agree on a single, narrow & uniform style, are just about nil. The current tolerance of multiple internally-consistent styles works well enough, & helps to minimise conflicts.--cjllw ʘ TALK 03:14, 14 July 2009 (UTC)

I agree with cjllw about author-date or author-title making equal sense. I disagree with Esprit15d's notion that different kinds of sources have different citation formats (The example "Citing a journal, a newspaper, an interview, a magazine article, television show and a YouTube video" is invalid right off the bat. Journals, newspapers, magazine articles, television shows, and you tube videos all have the same citation format. No idea what "interview" is doing in there; "interview" is not a publication medium).

But these issues don't really have anything to do with comma/period consistency, so I'm not sure why they were mentioned. I keep seeing allusions to previous discussions about comma/period, and notions about everyone being against consistent representation. But I have yet to see any links to these discussions. Could someone provide a link please? -- Fullstop (talk) 19:56, 16 July 2009 (UTC)

Interviews are cited by reliable authors. They are not cited in Wikipedia because Wikipedia editors are unreliable and might have either misquoted the interview subject, or made the interview up out of whole cloth. --Jc3s5h (talk) 23:55, 16 July 2009 (UTC)

Apparent loss of data by WebCite

Editors who use WebCite to archive web pages may wish to note that there seem to be some continuing problems with the site, even though it appears to be up again. (It may be that it is not fully functional yet.) I have tried archiving a few web pages but it doesn't appear to be working properly. More worryingly, web pages that I archived before the site was taken down for server migration (see, for instance, "Choor Singh" and "Han Sai Por") are not accessible at the moment.

I sent an e-mail to Gunther Eysenbach, the initiator of the WebCite system, using the e-mail address stated at http://www.webcitation.org/faq but have not received any response. I also left a message on his Wikipedia user talk page, but another editor has pointed out that he hasn't been active on Wikipedia since February 2009. Anyway, until WebCite has ironed out these issues, editors should be cautious about using the service. I also sincerely hope that web pages that have previously been archived using WebCite will be accessible soon, and have not been "lost".

I'm not sure where the best place to discuss this issue is. Please feel free to leave messages on relevant talk pages directing editors to the discussion here. — Cheers, JackLee ^–talk– 09:49, 11 July 2009 (UTC)

In addition to the old archives not working, there are several other (less serious) problems with the site. I have been in direct contact with Mr. Eysenbach and it appears that he is not getting any straight answers from his programmer(s) at this point. In my experience, things move pretty slowly on their end so unfortunately don't expect any quick fix. :( I do find it hard to believe that the data is completely lost though. --ThaddeusB (talk) 15:05, 11 July 2009 (UTC)

I've also had problems with webcite lately. Mostly error messages so that I can't archive anything, but I've also been finding dead links where I previously did manage to archive something. I e-mailed them but got no response. SlimVirgin ^{talk|contribs} 20:07, 11 July 2009 (UTC)

As near as I can tell there is not a single archive that was created before the server transfer that is currently working. It appears that there is currently a bug causing the archive meta data to align properly with the archived data, and thus nothing comes up at all.--ThaddeusB (talk) 00:19, 12 July 2009 (UTC)

I have some suggestions to mitigate (what I hope) what will be a temporary loss of data. Most important, we should get the word out to the general community that webcited links are down, so that people don't go mass-deleting these "dead" URLs. Maybe we can institute a temporary policy of not deleting these links until the problem is resolved. I'm not sure how such a message would be most effectively transmitted. Perhaps in the Signpost and maybe a banner display? I think this is serious enough to warrant such an action, since many controversial items on BLPs are backed up with webcited pages. Also, should the Board and Jimbo be alerted, if they don't know already? --Blargh29 (talk) 21:57, 11 July 2009 (UTC)

The Signpost and the village pump are a good idea, though it'd be good to know for sure first that the apparently dead links aren't gone forever. SlimVirgin ^{talk|contribs} 23:06, 11 July 2009 (UTC)

Until we know whether they are gone forever, let's just keep them in the article, until we know for sure that they're gone. Apparently, the programmers are working on it.--Blargh29 (talk) 23:28, 11 July 2009 (UTC)

I'm just wondering what we could say in a notice on the village pump, i.e. what do we know for sure? I've just emailed the webcite people again to ask for more information. SlimVirgin ^{talk|contribs} 23:43, 11 July 2009 (UTC)

How about this: "Webcite a popular on-demand web archiving service is undergoing maintenance, causing many archived web pages to show error messages. Communication between the project's founder and ThaddeusB indicates that the maintenance is taking longer than expected and outages may continue. Please use extreme caution when deleting Webcite links, as they may not be true victims of link rot."?--Blargh29 (talk) 00:03, 12 July 2009 (UTC)

Here is what I know (and I've probably followed this more closely than anyone else due to being User:WebCiteBOT's programmer:

• WebCitation.org had regular intermittent problems for essentialy the entire month of June.
  • I was informed this was due to server load, partially caused by all the links my bot was submitting, and partially to general site growth
  • As such a new server was ordered.
• WebCite appeared to crash entirely on ~June 24.
  • Eysenbach acknowledges the downtime on his Twitter page - says a new server is on the way... Apparently the initial downtime wasn't directly related to the upgrade
• WebCite comes back for a few hours on June 26, but quickly goes back down
• Eysenbach acknowledges the servers are down for upgrades on June 29
• JMR.org (which formally ran off the same server as WebCite) comes back online
• Several days pass and no sign of WebCite; Eysenbach leaves town for major health conference
• On June 7th, I email to figure out what is going on.
  • Eysenback replies to it should have been back up by now & he isn't sure what is goign on
• WebCite returns on June 8th
  • I email with a very minor bug - cite IDs are being returned like "1.24734562784E+15" instead of "127345627841214"
  • I quickly realize there are much more serious problems (the archives not loading being the worst, obviously) & email a fuller list of problems
• The minor bug mentioned above is "fixed" incorrectly such that instead of returning the number it returns the short form (5iCDarRqh) instead of the number. I point this out.
• I send several emails directly to the head developer, but hear nothing.
  • The cite_id is changed back to the # form, but still displays wrong
• This morning, I get an email from Eysenbach saying he is still out of town and is struggling to manage the developer remotely. He says the problems are being caused by a new distribution of Linux and the developer is struggling to make it work
  • As near as I can tell, of the 5-6 bugs I reported only 1 trivial one has actually been fixed

In short, I think the data (& corresponding links) is still good, but I wouldn't expect the bugs to be fixed soon. Unfortunately, every time I have pointed out a non-trivial bug over the last several months it has taken a while before it was acted upon. --ThaddeusB (talk) 00:19, 12 July 2009 (UTC)

Wow, great info. Thanks. How would you summarize that for a message to the general population to let them know not to remove these links?--Blargh29 (talk) 00:36, 12 July 2009 (UTC)

Starting with what you wrote above, I'd say something like:

WebCite, a popular on-demand web archiving service referenced by Wikipedia over 20,000 times, went down for a server upgrade on June 24th. WebCite is currently "on-line" but a few things were broken in the upgrade and it is currently not working properly - for example, returning error messages or blank pages for most previous archives. ThaddeusB has been in contact with Gunther Eysenbach throughout the process and would like to assure the community that efforts are underway to fix the broken links. In the mean time, please do not remove, or otherwise attempt to fix, "broken links" to webcitation.org. See this discussion for more information.

A shorter version for where a long message is inappropriate might read:

WebCite, a popular web archiving service referenced by Wikipedia over 20,000 times, is currently returning error messages for most pages. Efforts are underway to resolve the problem. In the mean time, please do not remove "broken links" to webcitation.org. (more information)

--ThaddeusB (talk) 01:04, 12 July 2009 (UTC)

• I can agree with that. Do you want to note that at Wikipedia:Village pump (technical), and maybe Wikipedia:Village pump (policy)? For the Wikipedia:Wikipedia Signpost, maybe make a message at User talk:Ragesoss (editor) and Wikipedia:Wikipedia Signpost/Newsroom/Suggestions? What about the Wikipedia:Arbitration Committee, User talk:Jimbo Wales, or any other adminy-type group?--Blargh29 (talk) 03:54, 12 July 2009 (UTC)

Both VPs, Signpost, and the new Wikipedia:Content noticeboard would be my suggestions. WP:AN might not hurt either. --ThaddeusB (talk) 04:22, 12 July 2009 (UTC)

Posted. --Blargh29 (talk) 05:24, 12 July 2009 (UTC)

Thanks, ThaddeusB, for the useful updates and Blargh29 for helping to alert other editors to the current status of the matter. — Cheers, JackLee ^–talk– 06:03, 12 July 2009 (UTC)

Yes, thanks for taking the time and trouble to get that information and post it. SlimVirgin ^{talk|contribs} 20:54, 14 July 2009 (UTC)

New archives

So, I still can't access archived pages through WebCite, but it seems that I can make new archives of pages (e.g., [3]. Is archiving links now a good idea, or should we wait until this whole thing is figured out? Thanks. –Drilnoth (T • C • L) 02:30, 15 July 2009 (UTC)

New archives are working properly, but it wouldn't hurt to hold off for a few days just to be safe. I did notice some progress today - old URLS are no longer returning 404s but rather something like "/var/www/sites/www.webcitation.org/html/cache2a4455fab89777938f9945b5382d139ab2642eb2". This tells me that it is at least trying to find the caches now, but still isn't matching up quite right. New archives work when accessed via "webcitation.org/query?id=" or "webcitation.org/query?url=" or short form "webcitation.org/5iGK5zfVn" but fail if you use the raw url "webcitation.org/cache/2adec65f22dfe430ef9f5685b4d38c59d6a0ee83". So, it knows how to find the data using the query function but the raw URL is wrong. I am guessing this means the raw URL is being generated in properly which is why it can't find the old data. It is possible that when this is fixed newer raw URLs that were malformed won't work anymore, but I imagine a work around would be put in place to overcome this. --ThaddeusB (talk) 02:56, 15 July 2009 (UTC)

Okay; thanks! –Drilnoth (T • C • L) 03:01, 15 July 2009 (UTC)

Update

Most older archives are loading now. There still seem to be some problems with pictures not loading, but the text does. The formatting is all messed up because of the missing pictures, but the textual info is there. PDF archives don't load properly currently; and, multi-byte characters (primarily on Chinese/Japanese pages, but occasionally on other pages with extended characters used as separators) load as black question marks rather than the proper characters.

So, there are still some issues but at least all the data appears to be intact. --ThaddeusB (talk) 15:50, 18 July 2009 (UTC)

Just about all the kinks are ironed out now. I think it's completely safe to resume normal archiving activities and am restarting WebCiteBOT. Hopefully I don't overload their server again. :) --ThaddeusB (talk) 21:04, 20 July 2009 (UTC)

Implications of WebCite outage for usage of archiveurl's by Wikipedia citations

The WebCite outage, and the possibility that it was to some degree precipitated by calls to its database from Wikipedia readers, brings up one issue regarding Wikipedia's usage of the archive services. Currently, including the |archiveurl= ... parameters in a citation using the {{cite ...}} template causes the main hyperlink in a citation to call the archiving service. This usage implicitly assumes that the original URL is non-functioning, and it shifts all the server load from the original URLs to the archiving service.

I think that we should consider reducing the load on the archive servers by modifying Wikipedia's procedure so that the original URL is normally used for the main hyperlink. This is the procedure that WebCite itself suggested in its documentation. The main disadvantage of this procedure is that readers will more often find dead links on their first attempt. That could be mitigated by adding still another parameter to the template to indicate that the original URL is dead. On balance, the WebCite experience suggests to me that we should make this change. Easchiff (talk) 12:13, 12 July 2009 (UTC)

I think that's fair enough. This issue was discussed (inconclusively) at "Template talk:Citation", so I think you need to revive the issue there and invite editors active at, say, "Template talk:Cite book" to join the discussion. — Cheers, JackLee ^–talk– 14:41, 12 July 2009 (UTC)

I've taken the liberty of reproducing your comment at "Template talk:Citation#Order of original and archive URL in citation template". — Cheers, JackLee ^–talk– 17:31, 12 July 2009 (UTC)

It's a tough call. Most users will just click on the link presented. If it leads to a dead link, or worse, some error page that doesn't look like a dead link, most will never find the correct item. I think the real problem is that WebCite just isn't a big enough operation to be used as an archive for Wikipedia. --John Nagle (talk) 16:53, 18 July 2009 (UTC)

Enron scandal

Help! I need formatting assistance with citations & reflist supporting the article Enron scandal. If there is an editor who would enjoy tidying this up, he/she will get a barnstar from me, as this article has more citations than I have had hot dinners, and there are probably more to come. --Gavin Collins (talk|contribs) 09:38, 13 July 2009 (UTC)

You might want to contact one of the users listed at "Category:Wikipedian WikiFairies" or "Category:Wikipedian WikiGnomes" or leave a message at "Wikipedia talk:WikiFairy" or "Wikipedia talk:WikiGnome". — Cheers, JackLee ^–talk– 10:51, 13 July 2009 (UTC)

The assistance I need requires a good working knowledge of the referencing makup and a keen eye for detail. I don't think any member of those projects could help. From what I can see from their talk pages, they may as well merge to form Wikipedia:WikiCretins. --Gavin Collins (talk|contribs) 15:25, 13 July 2009 (UTC)

Ooooh, snippy. You could also try asking editors Awadewit, Mattisse or qp10qp. They've done FA or GA reviews of some articles I've worked on. — Cheers, JackLee ^–talk– 17:03, 13 July 2009 (UTC)

I've also just noticed that Esprit15d said in a posting above that he or she is "a huge reference contributor (sometimes I go into articles and all I do is add references or clean up the existing references)..." — Cheers, JackLee ^–talk– 20:43, 13 July 2009 (UTC)

Enable refTools and use its error check. ---— Gadget850 (Ed) ^talk 21:57, 13 July 2009 (UTC)

Gavin, tut tut. :) SlimVirgin ^{talk|contribs} 20:55, 14 July 2009 (UTC)

Anchor text generated by ref tags

While we are discussing how WP handles ref tags, I was wondering if anyone else would prefer a different method for generating the anchor text for a named reference tag. For example, if I create a reference <ref name="NotTheBestReference">, then the anchor used in the generated HTML markup is '#cite_note-NotTheBestReference-1', while for unnamed references you get a simple '#cite_note-0'. Also, the numbering for the references are indexed from 1, but the anchors are indexed from 0, which means that note-0 points to reference 1. This is probably very trivial, but for some reason I find it mildly irritating. Plastikspork (talk) 20:53, 13 July 2009 (UTC)

I found it quite irritating too when I first started using Checklinks on good article reviews. It still causes confusion. Jezhotwells (talk) 21:29, 13 July 2009 (UTC)

Then Help:Cite messages may be of interest, as it documents how the references are built. ---— Gadget850 (Ed) ^talk 21:51, 13 July 2009 (UTC)

Appending <references/> where missing

Someone above commented that it would be nice if <references/> was appended to the end of pages automatically in cases where it was missing. This could be done already by placing <references/> in MediaWiki:Cite error refs without references.

It would need some thoughtful formatting to look good, but it is certainly possible. Do people want to pursue that? Dragons flight (talk) 09:43, 14 July 2009 (UTC)

I think it's a good idea, though I would suggest that {{reflist}} be used instead since that template appears to be the norm now. Also, it would be better if the bot added {{reflist}} in a "Notes" section in the right place among other standard appendices according to WP:LAYOUT rather than simply at the bottom of the article, where it might end up underneath an "External links" section and thus not be in accordance with the guideline. — Cheers, JackLee ^–talk– 09:48, 14 July 2009 (UTC)

Putting it in the MediaWiki message would always place it at the end of the page. Category:Pages with missing references list is well monitored. ---— Gadget850 (Ed) ^talk 10:04, 14 July 2009 (UTC)

Oh, could this be done by bot instead, then? — Cheers, JackLee ^–talk– 10:08, 14 July 2009 (UTC)

(edit conflict) Even if the section is added automatically, you could still add that Category and have people reposition things correctly later. Dragons flight (talk) 10:09, 14 July 2009 (UTC)

Like a warning telling you that <references /> is missing? I did figure out how to link that message to Help:Cite errors yesterday, so that should help. This issue is no longer a major problem. We did a lot of work documenting the problems and creating messages and categories and it is well monitored. ---— Gadget850 (Ed) ^talk 10:21, 14 July 2009 (UTC)

According to the category page SmackBot already automatically fixes the type of errors that adding a <references/> to the article would fix. If that isn't actually correct, let me know adding a {{reflist}} in the correct spot is already part of the functionality of WebCiteBOT since it occasionally adds the first <ref> to an article. Thus I could easily reuse to code to do it to articles that are known to be missing the info. --ThaddeusB (talk) 03:11, 15 July 2009 (UTC)

Centralized references

It has been proposed in several places (see, e.g, this essay) that wikipedia centralize its references, perhaps as part of the wiki commons. That is, every journal article, newspaper article, book, etc, would have a single entry in a centralized database. Wikipedia articles would then include in-line references to the database (which could be collected at the bottom of the page, if desired). Such a system seems much better than the current potpourri of referencing conventions currently in use, solving several problems at once. And, it has been implemented elsewhere. See Quantiki, which implements bibwiki, as an example.

Is there a consensus on the suitability and feasibility of this idea? Has it stalled? I looked at Wikipedia:WikiProject_Wikicite but it didn't seem to directly discuss this. Njerseyguy (talk) 15:48, 15 July 2009 (UTC)

I recall that this has been raised and discussed before, but don't recall any consensus being reached on the matter. Try searching the archives of this talk page. — Cheers, JackLee ^–talk– 03:55, 21 July 2009 (UTC)

TfD about formatting lists of references

In re Wikipedia:Templates_for_deletion/Log/2009_July_10#Template:Ref_indent

Template:Ref indent, which formats references into non-bulleted hanging indent paragraphs (instead of the bulleted list recommended here), has been proposed for deletion. Must of the previous discussion was essentially WP:ILIKEIT and WP:IDONTLIKEIT. Since it has been relisted for further discussion, the policy- and MOS-based opinions of regular editors here might be particularly helpful in reaching a recommendation. WhatamIdoing (talk) 20:13, 17 July 2009 (UTC)

Templates and Aligning

When using citation templates, I always put them on a single line. Another editor recently went to a few articles I've worked on, including some GAs, and changed them to the vertical align method. As I abhor this method and I felt it was in violation of this guideline (which says to use the existing format and not change it purely for personal preferences) and the vertical format is the far more commonly used in the media related areas where we're interacting. So I reverted, noting so. However, he continues attempting to do this, and is edit warring across multiple related articles. The one time he bothered with an edit summary, he said he was doing it because it "looks better to me", which to me is not a valid reason to change this and its getting really annoying. Are there any guidelines regarding this that can be reviewed to (hopefully) help stop this? -- Collectonian (talk · contribs) 05:45, 19 July 2009 (UTC)

I have two thoughts. First, the relevant text in this guideline is the last line of introduction: "if an article already has some citations, an editor should adopt the method already in use or seek consensus before changing it", and in the section WP:CITE#Citation templates and tools: "Because templates can be contentious, editors should not change an article with a distinctive citation format to another without gaining consensus." My second thought is this: does it really matter? Is this worth fighting over? ----CharlesGillingham (talk) 09:23, 20 July 2009 (UTC)

Other editor finally stopped and apologized for "warring" over it. But good to know I was pointing to the relevant passages in my requests that he stop. (and in some ways, yes, it is, if you are the primary editor who is the one sourcing and fixing up articles...those horizontal formats are horrendous to work around) -- Collectonian (talk · contribs) 14:02, 20 July 2009 (UTC)

REFPUNC

We could use more eyes at WT:Footnotes#REFPUNC. The text of WP:REFPUNC expressly permitted the placement of footnotes before punctuation (a style used in many scientific journals), and a footnote in an example expressly prohibited it (for no discernable reason). WhatamIdoing (talk) 19:40, 22 July 2009 (UTC)