Template:Werdnabot

Archives

March 2006 – June 2006 June 2006 – December 2006 December 2006 – August 2007 September 2007 – July 2008 August 2008 – Current

I'd not be surprised if thousands of articles still use this particular parameter for the definition of the year of a source's access. I therefore think it is imperative that support is re-introduced for this field in the template, or some way of script-assisted conversion is considered. —Anonymous Dissident^Talk 12:40, 13 March 2009 (UTC)[reply]

Sorry, I just realised I didn't phrase my comment properly. Forget what I said above. What I meant to say is that date formats of the form accessdate=14 January|accessyear=2001 do not work, whereas they once did. I for one once used this reference format liberally, and I learned it from someone else. So it seems likely that, regardless of whether it is correct or incorrect, this form may have once been used to some probably considerable extent in the past. Can support for this be re-introduced at all? —Anonymous Dissident^Talk 12:46, 13 March 2009 (UTC)[reply]

See the section #Access dates below. -- John Broughton (♫♫) 14:18, 27 May 2009 (UTC)[reply]

Are accessdaymonth and accessmonthday supposed to work, as the documentation says? Because they don't seem to.--Kotniski (talk) 11:43, 2 April 2009 (UTC)[reply]

In fact, if the ordinary accessdate parameter is not linked anyway (and it seems not to be), then why do we need any alternative parameters for the access date? (And shouldn't the documentation be updated?)--Kotniski (talk) 11:51, 2 April 2009 (UTC)[reply]

I changed the accessdate code to use the same code as {{cite news}}. The parameters are working again. But I don't know the answer to your second question. -- JHunterJ (talk) 12:10, 2 April 2009 (UTC)[reply]

Well, I made a couple of changes to the documentation based on how the template seems to work (i.e. it doesn't link dates, so there's no need for a special syntax for making unlinked dates). Hope it make ssense now.--Kotniski (talk) 10:38, 7 April 2009 (UTC)[reply]

Are these parameters for when you don't know what the date is, but you're pretty sure what the year is when you use a website as a source? -- Jeandré, 2009-04-19t12:34z

The parameters are holdovers from when the date was automatically linked, and are now deprecated. They should not be used, and there's an ongoing effort to remove them entirely. The accessdate should be entered using |accessdate= in the appropriate date format for the article (dmy or mdy, depending). Happy‑melon 13:50, 19 April 2009 (UTC)[reply]

Would it be possible for the "language" attribute to use the Template:Languageicon template? --76.167.241.45 (talk) 22:59, 19 April 2009 (UTC)[reply]

Pretty sure you "can" use it, but no real reason to use it. -- Collectonian (talk · contribs) 23:32, 19 April 2009 (UTC)[reply]

I see that there is a "dateformat" parameter available, but I don't see any documentation (or even mention) of it in Template:Cite web/doc. Since people are adding it to citations in articles, can we get this documented? (Besides showing the patterns and what they produce, it should be clear for potential users what patterns work, and what don't or aren't tested.) Thank you. ~ Jeff Q (talk) 23:38, 19 April 2009 (UTC)[reply]

{{Editprotected}} Someone monkeyed with this to insert weird and usually counterfactual wording, such that the location parameter renders as "written at LOCATION", kind of randomly in the middle of the citation. First off, this does not correspond to any citation style in the world. Secondly, the location (which is part of most widely recognized citation styles) is the location of the publisher not of where the author was allegedly sitting at the time of writing. It should be rendered "LOCATION: PUBLISHER". If the publisher field is not yet present, the display of location and the colon following it should be suppressed with "display:none;" CSS, or with a wikicode #if. The current code is so screwy that people are actually deleting this information from citations! (example). It needs to be fixed immediately. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:51, 21 April 2009 (UTC)[reply]

Strongly support this be changed back to "Location: Publisher" to follow virtually any normal citation format. I'd change it myself, but I can't make heads or tails of this metatemplate junk. — Huntster (t • @ • c) 01:01, 21 April 2009 (UTC)[reply]

Yes, Template:Citation/core seems to be expecting a PublicationPlace parameter but this template does not pass this. I cannot see any obvious recent changes which may have affected this issue, so I assume it has been like this since January. Could you possibly be more specific about the change that needs to be made? I'm not so familiar with this code. Deactivating the request until we sort out what exactly needs to be done. — Martin (MSGJ · talk) 06:22, 21 April 2009 (UTC)[reply]

{{Editprotected}}

Ah, right. {{Cite web}}'s |Place = {{{location|}}} needs to be |PublicationPlace = {{{location|}}}. I didn't realize it was {{Citation/core}} that was doing the weirdness. It has, indeed, a Place parameter, but this is clearly a highly specialized location parameter for exact site of authorship that is not pertinent to {{Cite web}} (I'm having a hard time imagining what it is used for and where). {{Citation/core}} is probably smart enough on its own to handle the formatting problem of a location being specified without a publisher, and if it isn't, that should be fixed over there, not here. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:38, 21 April 2009 (UTC)[reply]

I've put your proposed change on the sandbox. Can you test it and confirm that it is behaving as intended? — Martin (MSGJ · talk) 07:52, 21 April 2009 (UTC)[reply]

 Done What a mess :D Happy‑melon 09:44, 21 April 2009 (UTC)[reply]

If deprecated date parameters are used, the page is placed into Category:Cite web templates using unusual accessdate parameters. The sorting in that category is rather odd, as the code is:

[[Category:Cite web templates using unusual accessdate parameters|{{NAMESPACE}} {{PAGENAME}}]]

I propose to change this to the more standard:

[[Category:Cite web templates using unusual accessdate parameters|{{PAGENAME}}]]

---— Gadget850 (Ed) ^talk 11:20, 9 May 2009 (UTC)[reply]

Now that all the non-article pages have been removed, yes. Before, it was useful for filtering and prioritising work (ironically, the non-articles were done first, which wasn't really the idea, but never mind). Happy‑melon 12:14, 9 May 2009 (UTC)[reply]

That is just the way my twisted mind works. :) Apart form the fact that 1. there's less of them, and since you have to start somewhere, why not start where you can easily make a difference? 2. templates and files are usually used on other pages, so fixing them effects both the template or files as well as the page(s) they are transcluded upon. Debresser (talk) 18:44, 9 May 2009 (UTC)[reply]

I am in favor of the proposed change, as I am the one who raise this point on both your talkpages. But, as I have pointed out to Gadget850 before, there is much to be said for sorting non-articles together in one place. In other categories we've chosen for "!". Could this be done also? Debresser (talk) 18:44, 9 May 2009 (UTC)[reply]

That could be done by changing the referenced markup to:

{{namespace detect showall
| 1 = [[Category:Cite web templates using unusual accessdate parameters|{{PAGENAME}}]]
| 2 = [[Category:Cite web templates using unusual accessdate parameters|!]]
| main  = 1
| template = 2
| category = 2
| help = 2
| file = 2
}}

---— Gadget850 (Ed) ^talk 20:32, 9 May 2009 (UTC)[reply]

Looks good. Debresser (talk) 22:03, 9 May 2009 (UTC) I see a three-party consensus here. And I doubt if there's anybody else looking at this category. :) Debresser (talk) 00:46, 10 May 2009 (UTC)[reply]

If you'll allow me to speak my mind. I was frankly a little surprised when I first saw this solution (with 1={{PAGENAME}} and 2="!"). I thought the obvious solution would be to use {{FULLPAGENAME}}. I agree that that doesn't set aside template and others completely, but it does group them together. And it is much shorter and more elegant. And has the additional feat of sorting templates, help pages, categories and files separately, much like you tried to do once with "!", "#", "@" and"$". I din't say this before, because I very much appreciate your efforts and I am dependend on you since I am not an admin and can't edit templates myself. But it is what I would have done without even a second thought at the first moment this subject arose. Debresser (talk) 11:33, 10 May 2009 (UTC)[reply]

Then we don't need to make any changes, as the current {{NAMESPACE}} {{PAGENAME}} = {{FULLPAGENAME}}. ---— Gadget850 (Ed) ^talk 12:07, 10 May 2009 (UTC)[reply]

That's precisely what's bothering me here. Why didn't it sort the pages alphabetically only by namespace (there were "u" for userpages and "t" for "templates, but all articles were together in one big row)? It should work the same way as other error categories we work with, where articles get sorted alphabetically also. I think the reason is that {{NAMESPACE}} {{PAGENAME}} is not {{FULLPAGENAME}}. {{FULLPAGENAME}} is {{NAMESPACE}}:{{PAGENAME}}. Debresser (talk) 15:53, 10 May 2009 (UTC)[reply]

Which means all articles get sorted under ":". What exactly are we trying to do here? Why won't that be achived by using a FULLPAGENAME sort? Happy‑melon 08:31, 15 May 2009 (UTC)[reply]

That was a theoretical excursion. I'd still like to request the factual (not theoretical) change to the "!" sorting as described above. Debresser (talk) 18:50, 14 May 2009 (UTC)[reply]

We were just exanging opinions with Gadget850. Of course {{FULLNAMEPAGE}} will be the best solution of that sort, hypothetically. What I'd like to request though is to implement the first suggestion, sorting all non-articles under "!". If that's too much trouble, then {{FULLNAMEPAGE}} is definitely a good solution which is preferable to {{PAGENAME}}. Debresser (talk) 10:45, 15 May 2009 (UTC)[reply]

 Done with FULLPAGENAME, as that's easy. I'm not sure the extra work needed to sort non-articles by ! is justified by the results, given that this is supposed to be a transient category anyway. Happy‑melon 10:54, 15 May 2009 (UTC)[reply]

Thanks. This is called: making the live of gnomes a little easier. :) Debresser (talk) 10:56, 15 May 2009 (UTC)[reply]

Do I understand correctly that as soon as they're fixed you'll discontinue support for them from the template? Debresser (talk) 10:56, 15 May 2009 (UTC)[reply]

Thanks to Debresser's heroic effort, Category:Cite web templates using unusual accessdate parameters is now essentially empty. I intend to remove these parameters from the template code entirely now: that will mean simplifying the |AccessDate= code to this:

  |AccessDate={{#if:{{{accessdate|}}}
                |{{#if: {{{accessyear|}}}
                   |{{{accessdate}}} {{{accessyear}}}
                   |{{{accessdate}}}
                 }}
                |{{{accessday|}}} {{{accessmonth|}}} {{{accessyear|}}}
   }}

Any thoughts? The next stage should be to clear out usage of the |accessday=, |accessmonth= and |accessyear= parameters, IMO. Happy‑melon 11:03, 17 July 2009 (UTC)[reply]

I agree with the proposed change. What will happen if somebody uses |accessdaymonth= or |accessmonthday=, after that change?

I also agree with the next step proposed by Happy‑melon, to start eliminating all other minor date parameters, leaving only |accessdate=. And I will be willing to lend a hand. Debresser (talk) 08:25, 21 July 2009 (UTC)[reply]

They will simply not function; it would be like setting |snorkel=. (also)Happy‑melon 08:51, 21 July 2009 (UTC)[reply]

The page is just displayed as a number by itself, making no sense. It needs to say Page {{{page}}} or Pages {{{pages}}}. Although I did a lot of work on these new templates, unfortunately I'm not an admin so can't make the change myself anymore... {{editprotected}} ··gracefool☺ 10:50, 10 May 2009 (UTC)[reply]

I don't understand what you mean. And no changes have been made to {{Cite web}} that could have any repercussions except for that technical category of the previous section, and that changewas made correctly. If there were anything wrong, we'd have manyfold posts by now. Could you give an example, please? Debresser (talk) 11:09, 10 May 2009 (UTC)[reply]

For example, the last reference at List of OECD countries by suicide rate reads

"The Social Report 2008 - Health" (PDF). New Zealand Ministry of Social Development. 26. Retrieved on 2009-05-10.

"26" comes from page=26. It should say something like "Page 26", or if the pages parameter was used instead, Pages 26-28 etc. Or perhaps just p. 26 and pp. 26-28 like {{cite book}}.

··gracefool☺ 11:44, 10 May 2009 (UTC)[reply]

Also it should be reordered so pages are displayed after title rather than almost at the end. Thus:

"The Social Report 2008 - Health" (PDF), page 26. New Zealand Ministry of Social Development. Retrieved on 2009-05-10.

This reordering needs to be done to the other citation templates as well. ··gracefool☺ 13:34, 10 May 2009 (UTC)[reply]

Is this an informed comment you're making? Are you quite sure that the current citation method is actually wrong? It's quite possible that it's simply a particular style of referencing format. A template talk: page may not be the best place to get informed opinions on that. —Anonymous Dissident^Talk 13:42, 10 May 2009 (UTC)[reply]

The number definetely needs something to make it clear, otherwise it is a rather 'misterious' number hanging in the middle of the text. A working example currently at User:Nabla/Test1, using User:Nabla/Test as the template (diff from the original).

Not sure about the position, though it looks better as in Gracefool's second example.

Nabla (talk) 13:49, 10 May 2009 (UTC)[reply]

Other templates to p. or pp., not page or pages. -- Collectonian (talk · contribs) 14:59, 10 May 2009 (UTC)[reply]

I'm not convinced that 'cite web' is the most appropriate template for paginated sources; as I understand it is intended for web pages, and PDF files would be better handled with citation/cite journal/cite paper/cite book/ etc. (Cite book, for instance, displays pp. by default). In most cases, it would probably be more appropriate to cite the source, and use the {{rp}} template in-line. Martin (Smith609 – Talk) 15:05, 10 May 2009 (UTC)[reply]

For the most part, I tend to agree with this. If you do use pages with cite web, just manually add the p./pp. Its only recently that the other templates did this automatically anyway. :-P -- Collectonian (talk · contribs) 15:09, 10 May 2009 (UTC)[reply]

Nevertheless, I think ··gracefool is right. There is this option to indicate pages. And it is relevant, since many online sources use pages. So the template should show it in the same nice way as {{Cite book}}. Since they've made it work for {{Cite book}} they can just copy it here and {{Cite web}} will use it also. Debresser (talk) 15:39, 10 May 2009 (UTC)[reply]

Unless you (or someone else) are able to task a bot to go around and fix all transclusions to avoid double page indicators ("p. p. 35"), then this is a moot point. As for the placement of "page", you'd be better off getting "Cite book" or "Citation" to implement first, since it typically leads the way with changes. Note, however, that MLA, APA, and CMS citation formats all place the page number at the very end of the citation, so I'm not sure what precedent Gracefool is drawing from, other than some kind of aesthetic. I would not support either proposal, as it seems unnecessary. — Huntster (t • @ • c) 15:54, 10 May 2009 (UTC)[reply]

As a side note, there is a bot that does/did that for the other templates, so presumably it could also fix any cite web instances broken if the pages parameter were updated. -- Collectonian (talk · contribs) 16:03, 10 May 2009 (UTC)[reply]

Good points all. I agree with Smith609 and Collectonian, cite web should not have pages. I can't think of any time where it should - on the web, a page is a url. If it's a PDF or whatever, another template should be used. Can anyone think of an exception? Yes a bot could fix this, I doubt it has been used much at all.

Great point Huntster, standard citation formats have the page number at the end, so I withdraw that idea. Same with "page" instead of "p". Heh it's all a matter of remembering why I made it that way in the first place :p ··gracefool☺

I recommend replacing the current code with:

 |At = {{#if: {{{page|}}}
         |{{#if:{{{nopp|}}}||p. }}{{{page}}}
         |{{#if: {{{pages|}}}|{{#if:{{{nopp|}}}||pp. }}{{{pages}}}}}}}
       }}

I don't think that casual editors should have to worry about such things. It also saves a lot of bot work. Where in the citation the page data is cited is a function of {{Citation|core}} it seems to me. --droll [chat] 19:23, 14 May 2009 (UTC)[reply]

Well its not quite that easy is it. It would still be necessary to clean up places where editors added p. or pp. in the article text. Can't be that many occurrences. It should be easy to clean up. It would be best to use a dump generated just before the code change. --droll [chat] 19:33, 14 May 2009 (UTC)[reply]

If Templatetiger is correct there are 22 pages that use the page field and 210 pages that use the pages field. Some hang an external link on it so the nopp field would be useful. --droll [chat] 20:36, 14 May 2009 (UTC)[reply]

If my code or something similar is agreed upon I volunteer to do the clean up. It would be good to add a maintenance category associated with the two fields to catch changes since the dump that Templatetiger uses. Something like:

{{#if:{{{page|}}}{{{pages|}}}|[[Category:Cite web templates using page fields|{{PAGENAME}}]]}}

--droll [chat] 00:33, 15 May 2009 (UTC)[reply]

Someone above asked for an example where page numbers are useful with {{cite web}}, and I have one. I wanted to point out a typo in some web sources. These are long hand or OCR transcriptions of an old book and have the book's page numbers embedded. For other citations of this reference I use {{cite book}}, but here wanted to emphasize this was a problem with the web transcripton.

From Mont Clare, Pennsylvania: "[Note: A version of Bean's History, copied on several websites, names it Quineyville, but this is a transcription error.<ref>"BEAN'S HISTORY OF MONTGOMERY COUNTY, PENNSYLVANIA, CHAPTER LXXII. UPPER PROVIDENCE TOWNSHIP". pp. pp. 1057-8. Retrieved 2009-07-07.</ref>]".

It would also possibly be useful where there was something like a javascript pagination or gallery mechanism where the URL always takes you to page 1 and there citation is further back.

However some other editor has since removed that pp. in spite of the template not yet providing it. Is the change discussed above imminent and this is pre-clean up, or do I need to put the pp. back in? --J Clear (talk) 18:00, 10 July 2009 (UTC)[reply]

See this discussion I had with another user. He changed cite web from a redirect (to this template) to a disambiguation page (diff) which I reverted. Per the discussion, he wants a mention of the redirect (perhaps using {{for}} or {{otheruses}}) on this template's /doc page. I feel this would be unnecessary and make the template documentation awkward. What is your opinion? ~EdGl ★ 02:08, 18 May 2009 (UTC)[reply]

It should be deleted. Cross-space redirects are not allowed, and it certainly shouldn't be encouraged or mentioned here. -- Collectonian (talk · contribs) 02:24, 18 May 2009 (UTC)[reply]

Wikipedia:Cross-namespace redirects does not say they are not allowed; there are arguments for both sides. See #Arguments for keeping CNRs for good reasons to keep cite web. The redirect was nominated for deletion, but was kept because consensus to delete was not reached. ~EdGl ★ 02:54, 18 May 2009 (UTC)[reply]

My opinion is to keep the status quo. In general I am in favor of simplicity. Debresser (talk) 14:39, 18 May 2009 (UTC)[reply]

I notice that the default separator has been changed from a period to a comma. Was that intentional?

Also there seems to be a bug in the new code. Notice that:

 {{cite web
   | url = http://en.wikipedia.org/wiki/Template_talk:Cite_web
   | title = Template talk:Cite_web
   | separator = 
   | publisher = Wikipedia
   | accessdate = 2009-05-23 }}

yields:

"Template talk:Cite_web". Wikipedia. Retrieved 2009-05-23. {{cite web}}: Cite has empty unknown parameter: |separator= (help)

The code was probably meant to be something like:

  |Sep = {{#if:{{{separator|{{{seperator|}}}}}}|{{#ifeq:{{{separator|{{{seperator}}}}}}|;|&#059;|{{{separator|{{{seperator}}}}}}}}|.}}

A switch expression might even be cleaner if there was a consensus about which separators were to be allowed.

I know this is trivial but I think it is good to get it right. --droll [chat] 23:35, 23 May 2009 (UTC)[reply]

{{editprotected}} Request edit changing the default separator be reversed. No discussion or consensus here, and edit summary claims to look at Talk:Citation, with no direct link (nor relevance to this template). -- Collectonian (talk · contribs) 01:33, 24 May 2009 (UTC)[reply]

Request above code be used to restore default separator as also solves the problem of using a semicolon.--droll [chat] 01:53, 24 May 2009 (UTC)[reply]

• Are semicolons really that important? --droll [chat] 03:33, 24 May 2009 (UTC)[reply]
  • I suppose if someone preferred to use a comma separator, a semicolon is necessary if the citation fields contain internal commas. That said, I've never seen anyone override the cite template separator in practice, though I'd guess that usage does exist somewhere. The important thing was to restore the peiod (full stop) as the default. —TKD [talk][c] 06:32, 24 May 2009 (UTC)[reply]
• Fixed using your code (with some spacing for readability). I will be applying this to the other cite templates, which were also affected. —TKD [talk][c] 05:04, 24 May 2009 (UTC)[reply]

Apologies about changing the default, I hadn't intended to do so. But - how, now, is one to suppress the separator, if one wishes to do so? (I think that specifying a non-breaking space will result in double spacing in the template, as other spaces are already hard coded.) Your 'fix' has changed the behaviour of the template; if there is some editor out there who has, for some reason, needed to suppress the separator in some articles, then those will now be broken. Martin (Smith609 – Talk) 14:13, 24 May 2009 (UTC)[reply]

You're right. I've attempted the fix that case now: Unless {{{separator}}} or {{{seperator}}} is a semicolon, it'll fall back to the old {{{separator|{{{seperator|.}}} }}} coding. —TKD [talk][c] 15:28, 24 May 2009 (UTC)[reply]

Currently, a template like this:

{{cite web|title=The 19th TASS |url=http://www.fac-assoc.org/19%20TASS/19thTASS.htm|archiveurl=http://www.webcitation.org/5gwhyRHS6|archivedate=2009-05-21|deadurl=no|accessdate=2009-05-19}}

displays like this:

"19th TASS". Archived from the original on 2009-05-21. Retrieved on 2009-05-19.

where the first link is to the archive, the second to the original.

I suggest this instead:

"19th TASS". Retrieved on 2009-05-19. Archived on 2009-05-21.

The revised format has a number of advantages:

• It's shorter.
• It puts the retrieval date of the original link next to that link.
• It puts the original retrieval date and archive date in chronological order.
• It makes it easier for the reader to follow the link to the original page, which is a better place to go. (Better for the reader, plus the original page owner will be less unhappy with any archive link if his/her page gets a more prominent position.)

On the flip side, I acknowledge that the current format works equally well whether the parameter deadurl has a value of "no" or "yes", while the proposed format is not the best if the value is "yes". So, at the cost of yet more complexity, I suggest that what the reader sees should depend on whether the original url is recorded as dead or not; if deadurl=yes, then the current display is better. -- John Broughton (♫♫) 14:49, 27 May 2009 (UTC)[reply]

Good change. An admin needs to make it tho.--2008Olympian^chitchat 22:49, 27 May 2009 (UTC)[reply]

I strongly object. I believe that the first link should be to the page that contains the information that serves to verify the information in the article. Maybe I'm missing something but it appears that if this change is make then hurried users are likely to click the link to an updated page or dead link and become confused. The fourth point seems to claim that there is some value to the page owner if the change is made. I believe Wikipedia should put the good the the reader first. We are under no obligation to the owners of web pages we link to except that they should not be misrepresented. Most links to archived pages are the result of link rot. If rot results in a dead link what value is there in placing the dead link first.

By the way, should the accessdate be the date the bad link was last accessed or the date the archived version was last accessed. The first case seems to provide little in the way of useful information to the reader. --droll [chat] 00:29, 28 May 2009 (UTC)[reply]

Accessdate should always be the date the original website was accessed, because that shows exactly when the cited material was pulled, and may determine which copy of an archived page should be used. Accessdate should not be changed unless 1) the source has changed and text in the article is being changed to match, or 2) it can absolutely be confirmed that the current version of the source matches the originally viewed source. — Huntster (t • @ • c) 06:41, 28 May 2009 (UTC)[reply]

To address each of Droll's points:

• the first link should be to the page that contains the information that serves to verify the information in the article. The best source of verification is the original page, if available. That's because (a) the pageowner may have posted a correction or updated the page; or (b) the pageowner may have updated the links on the page that provide supporting facts. Moreover, if the page no longer provides support for the citation, that can be an indication that the pageowner has changed his/her mind about the matter. Let's keep in mind that the core issue isn't whether the original posting editor was right or wrong (something that the archived page can resolve); the issue is whether what is in the article is correct. And for that, we want to send the reader to the latest version of the page.
• hurried users are likely to click the link to an updated page or dead link and become confused. If they click the link to an updated page and it doesn't support the claim, we want them to realize that's a problem - and we'd want them to do that whether or not the original page ever supported the claim. As for finding a dead link and becoming confused, they would always have the alternative of clicking on the "Archived" link. (It's reasonable to assume that Web users are quite familiar with dead links, and understand what "Archived" means.)
• We are under no obligation to the owners of web pages we link to except that they should not be misrepresented. Owners of web site pages provide supporting information for Wikipedia; if we can help them without hindering readers, we should.
• Most links to archived pages are the result of link rot. Here I owe an apology for not having prefaced my suggestion with some background: we have a new bot, User:WebCiteBOT, whose purpose is to try to archive every external link that can be archived (some web owners block this). So while it's certainly true that most archived links today are due to link rot, that (hopefully) won't be the case in the future as this bot goes to work. (It was looking at this bot's work that lead me to this template; originally I thought that the bot was formatting the citation I was examining.)

Finally, I note that we should encourage editors to change the deadurl parameter from =no to =yes when a link is bad. Better yet, we should get a bot to do link checking and change this parameter as needed (see the discussion at WP:VPPR#Dead external links). Droll and I have no disagreement as to what do do when a link is bad - we absolutely don't want to provide that link when we have an archived version that works. -- John Broughton (♫♫) 16:39, 28 May 2009 (UTC)[reply]

Note that the template displays incorrectly when an authorlink is used.

For example

• Last, First (Date). "Title". Retrieved Date. {{cite web}}: Check date values in: |accessdate= and |date= (help)

or even

• Last, First (Date). "Title". Retrieved Date. {{cite web}}: Check date values in: |accessdate= and |date= (help)

in comparison to

• Clark, Martyn (27 August 2005). "Interview with Skream". Retrieved 30 June 2007. {{cite web}}: Check |authorlink= value (help); External link in |authorlink= (help)

where "[|" and "]" are added around the author's name. Hyacinth (talk) 22:31, 28 May 2009 (UTC)[reply]

Authorlink is intended to link internally to the author's wikipedia entry. It isn't intended for a URL. For example:

Shakespeare, William (1 January 2008). "Random website". Retrieved 2 February 2009.

— Huntster (t • @ • c) 23:24, 28 May 2009 (UTC)[reply]

this article has left me in a quandary as to what to cite. The problem is the release date is before the article date. EDIT: another site - this one is off by an even larger margin and this one is not even in the same year.陣内_Jinnai 01:46, 6 June 2009 (UTC)[reply]

If you are talking about what date should be included in the |date= field, then it is always the article date...when the article itself is published. For the purposes of the citation, it doesn't matter when the media (audio, video, etc) was actually published...though it is useful that the article clearly gives that date. — Huntster (t • @ • c) 03:11, 6 June 2009 (UTC)[reply]

??? That statement wasn't clear due to way you used "published."陣内_Jinnai 04:54, 6 June 2009 (UTC)[reply]

What I mean is you should use the date that the article, review, whatever, was published...originally written. Not the date the media was released. For example, in the case of the first link you provided, you would use |date=February 6, 2008, the date the article was published, instead of February 5, the date the media was released. Is that clearer? — Huntster (t • @ • c) 11:17, 7 June 2009 (UTC)[reply]

Given the importance of reliable sourcing, it makes no sense to me to have the URL displayed before the publisher. Can we change that? Disembrangler (talk) 12:23, 10 June 2009 (UTC)[reply]

What do you mean? The URL is part of the title field, which is definitely appropriate in its current location. — Huntster (t • @ • c) 03:26, 11 June 2009 (UTC)[reply]

I used the "archiveurl" parameter in a citation to link to the archive in case the original becomes unavailable, but I want the main link to still point to the original which is currently available (using the archive as a back-up only). How do I do that? --Joshua Issac (talk) 19:08, 22 June 2009 (UTC)[reply]

Use url= to include the original URL and it will link displayed as "original". See #Display of original and archived links above]]. ---— Gadget850 (Ed) ^talk 19:17, 22 June 2009 (UTC)[reply]

Thanks, I had not noticed that section. --Joshua Issac (talk) 20:28, 22 June 2009 (UTC)[reply]

I have added support for the translation parameter. Will add docs later. Revert if any problems are encountered. See also here. Crum375 (talk) 13:43, 23 June 2009 (UTC)[reply]

Is there a particular that this template continues to use ISO 8601-format dates it in its examples even though Wikipedia no longer autoformats dates, or has it just been forgotten? —Preceding unsigned comment added by Black Falcon (talk • contribs) 19:46, 23 June 2009 (UTC)[reply]

I have boldly replaced the date format to use {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (e.g. 12 February 2025). This affects just the examples in the documentation and can be modified (added later: within articles) as desired by individual editors. –BLACK FALCON ^(TALK) 16:25, 30 June 2009 (UTC)[reply]

I support you here. Debresser (talk) 16:54, 30 June 2009 (UTC)[reply]

That fixes the examples. I'm guessing by the state of thousands of articles that ISO has become the defacto standard. We do have a way to format the date without linking, but no will to implement this. ---— Gadget850 (Ed) ^talk 19:35, 30 June 2009 (UTC)[reply]

Do I understand that the sequence of parameters is determined by the editor (e.g. if I type accessdate=2009-01-01 first when editing, it will be rendered in first position)? Maybe that should be written in the doc, then. -DePiep (talk) 08:48, 29 June 2009 (UTC)[reply]

No, off the top of my head I cannot think of any template that allows user-defined placement. This template uses a fixed placement of output that depends on what parameters are used. In your example, accessdate will be output close to the end. For example:

• Last, First (2009). "Title". Work.com. Retrieved 2009-01-01.

— Huntster (t • @ • c) 11:04, 29 June 2009 (UTC)[reply]

Indeed, a sandbox-test confirms your answer. Thx. Must have been a different mistake by me. -DePiep (talk) 12:02, 29 June 2009 (UTC)[reply]

Am I crazy or did the date of production-related parameters (date, year etc.) get moved from parentheses after the author to the end of the line? Why? Circeus (talk) 16:35, 29 June 2009 (UTC)[reply]

Not as far as I can tell. See my example in the section above...the publication year still comes in parentheses after the author. You may have run into some kind of special situation...can you show an example of the problem? — Huntster (t • @ • c) 04:03, 30 June 2009 (UTC)[reply]

See notes #1,2,10,11 at Yves Bérubé. Notes the same problem shows up in notes #8 and 9, which use {{cite journal}}. Circeus (talk) 06:17, 30 June 2009 (UTC)[reply]

Ah, I see, I thought you meant the dates were showing up at the end even when author was present. IIRC, it was considered inappropriate (and I agree) to place the date at the front of the citation when there was no author given, so things could be sorted better (i.e., sort either by author or title). This is already an issue with metadata collection, and could eventually be useful in articles if/when citation handling is improved. I don't remember if the date used to stay at the front in all cases, but I don't believe it's been that way for a while. AKA, this is a normal occurrence. — Huntster (t • @ • c) 11:03, 30 June 2009 (UTC)[reply]

Okay, thanks. Personally I would have moved the date to after the title, but I'll bow to the statu quo. Circeus (talk) 16:45, 30 June 2009 (UTC)[reply]

{{editprotected}} Compare Bob (2009). "FOOBAR". BARFOO. ({{cite journal}}) with Bob (2009). "FOOBAR". BARFOO. ({{cite web}}). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 17:07, 29 June 2009 (UTC)[reply]

I think I agree, but have no idea how to fix it. I've asked User:Crum375 if he/she can help. — Martin (MSGJ · talk) 08:32, 30 June 2009 (UTC)[reply]

This is a {{Citation/core}} issue, and after looking at it, I don't see a readily apparent fix, considering it appears to be designed to accommodate both quote marks and italics. Far too complicated. Personally, I don't see this as an issue...it doesn't change the meaning of anything, but don't care either way. — Huntster (t • @ • c) 11:10, 30 June 2009 (UTC)[reply]

I concur with Huntster. I too see no easy way around this, without adding complexity to the core engine (which services many other citation types). How important do you feel it is? Crum375 (talk) 12:58, 30 June 2009 (UTC)[reply]

Couldn't resist a challenge, so I fixed it. Since this is a common engine, it may affect other citation types, so this may need to be reverted if other users run into issues. Let me know what you think. Crum375 (talk) 14:03, 30 June 2009 (UTC)[reply]

Looks good here. I can't see where it would break a citation style, if anything, it would've fixed the other styles, as they too would need to have the quotes outside the link. Thanks. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 15:09, 30 June 2009 (UTC)[reply]

Hopefully you are right, and it won't break anything or ruffle any feathers. Worst case, we can always revert to the old style. Crum375 (talk) 17:37, 30 June 2009 (UTC)[reply]

Well done, Crum, thanks for that. — Huntster (t • @ • c) 09:44, 1 July 2009 (UTC)[reply]

It seems like titles with closing brackets "]" at the end of the title are placed after the url link on the title page. Many of the music references in School Rumble use closing brackets for their title the final bracket is placed after the link despite being part of the title.陣内_Jinnai 18:46, 4 July 2009 (UTC)[reply]

I believe this is a known issue in most of the citation templates. You'll have to wrap that part of the title in <nowiki></nowiki> tags to get around it. -- Collectonian (talk · contribs) 18:52, 4 July 2009 (UTC)[reply]

There has been talk on the village pump and Template talk:Citation to rearrange the order of the urls due to WebCite collapsing largely because of overload from Wikipedia. Rearranging the order, original first then archived url, was suggested to help minimize the overload since often a website doesn't change much in content (except front pages of news sites and the like) over time. Since a major amount of articles use this template, I thought it appropriate to bring up here.陣内_Jinnai 02:10, 14 July 2009 (UTC)[reply]

I'd like to get PDF citations to display the way that external links using {{PDFlink}} do. Specifically, they show the acrobat icon and have PDF wikilinked, regardless of whether or not the actual URL ends with the extension ".pdf". Observe:

• {{PDFlink|http://www.google.com}} => Template:PDFlink

There seems to be some autodetection happening with vanilla links that adds the icon (something having to do with CSS, about which I'm fairly ignorant):

• [http://www.google.com/foo.pdf] => [1]

And this autodetection naturally falls through into the links created by {{cite web}}:

• {{cite web|url=http://www.google.com/foo.pdf|title=Look at the icon}} => "Look at the icon" (PDF).

I keep seeing URLs that point to PDFs, but are going through a database (or other system) so that the URL doesn't have the PDF file name in it. And in these cases, the icon isn't generated.

• {{cite web|title=State Route 143 Resolutions|publisher=[[Utah Department of Transportation]]|url=http://www.udot.utah.gov/main/uconowner.gf?n=200609181649181|format=PDF}}

=> "State Route 143 Resolutions" (PDF). Utah Department of Transportation.

Could we get cite web to detect "|format=pdf", and then specify the PDF icon rather than the default icon? Perhaps this could be via a similar mechanism as {{PDFlink}}, i.e., using <span class="PDFlink">. DeFaultRyan 19:47, 17 July 2009 (UTC)[reply]

Minor thing I've noticed with some references I've used, the "page=" parameter is only showing the number, not "p. #". To illustrate:

• {{cite web |publisher=[[IGN]] |author=Shea, Cam |url=http://xbox360.ign.com/articles/954/954036p2.html |title=Street Fighter IV AU Review | page=2 |date=2009-02-12 |accessdate=2009-08-09}}

• Shea, Cam (2009-02-12). "Street Fighter IV AU Review". IGN. p. 2. Retrieved 2009-08-09.

Happens with "pages=" as well. Sorry if this is an already known about issue.--Kung Fu Man (talk) 14:47, 9 August 2009 (UTC)[reply]

Resolved

— KieferSkunk (talk) — 18:37, 10 August 2009 (UTC)[reply]

The "Work" parameter seems to automatically italicize the entry, but not all applicable entries should be italicized, such as websites. This seems like a problem to me. Drewcifer (talk) 06:50, 11 August 2009 (UTC)[reply]

Since there is no manual of style to indicate what output this template is to produce, how do you know websites should not be italicized? --Jc3s5h (talk) 10:52, 11 August 2009 (UTC)[reply]

This is correct. Use work when the publisher should be italicized (like citing the NY Times website or the like), otherwise use the publisher field which is not italicized. -- Collectonian (talk · contribs) 12:42, 11 August 2009 (UTC)[reply]

Disagree. The work is always the published medium, the publisher is the company doing the publishing. Work is italicised, publisher is not. — Huntster (t • @ • c) 04:20, 12 August 2009 (UTC)[reply]

Publisher and work are two different things, at least in the case of many websites. Allmusic, for example, is published by Macrovision. And you're right, there is no MOS about this template specifically, but there is an MOS about websites and that they shouldn't be italicized. Where it's at eludes me at the moment, but if you need proof I can try and dig it up. So, that said, any template that is meant to facilitate websites should have the ability to facilitate the website in the appropriate style, ie, not italicized. Drewcifer (talk) 05:05, 12 August 2009 (UTC)[reply]

Oh, I don't disagree with regard to that, just pointing out to Collectonian that the two fields cannot and must not be used interchangeably. Since Cite web shouldn't be used to cite news stories that were printed in physical form (for example), I see no problem with removing the italics altogether from this template, speaking in broad terms. — Huntster (t • @ • c) 05:09, 12 August 2009 (UTC)[reply]

I feel that the work parameter should be made devoid of the auto-italicising. Instead we can make the publisher as auto-bracketed like the way it is done for Cite news templates. Just a thought. --Legolas ^(talk2me) 05:44, 12 August 2009 (UTC)[reply]

The template does italicize the work entry automatically, but if you italicize the entry like this: work=Allmusic, it would appear in normal font in the reference section. For example reference #10 in the article "Live to Tell". Frcm1988 (talk) 06:12, 12 August 2009 (UTC)[reply]

Websites are not a "published medium" but generally a publisher of content. Makes sense to me. And not saying use them interchangeably, there are some web sources where you can and should use both. -- Collectonian (talk · contribs) 11:15, 12 August 2009 (UTC)[reply]

Websites are most certainly published media..."published" does not necessarily mean the same thing as "printed". The website is never a publisher of content, merely the work that contains the content...there will always be an individual, company, or other entity behind that website. Two totally different things. If you can include both sets of data, then do so, but "work" is the only thing that really needed. — Huntster (t • @ • c) 22:50, 12 August 2009 (UTC)[reply]

The concept of what a website is, and a publisher is, is not made clear in the documentation (perhaps because there is no agreement on the meaning). In my mind, a website is a work; the medium is the World Wide Web. The publisher is a corporation, partnership, or individual. Unless you think Tron or The Matrix are non-fiction, publishers cannot exist in electronic form. --Jc3s5h (talk) 13:27, 12 August 2009 (UTC)[reply]

My only worry with re-doing the template is that it would fail to be backwards compatible. ie, all of the instances where the "work" parameter should be italicized. I can't necessarily think of any examples, but I'm sure they exist. So instead, what if we just added an extra parameter: "website". It's more straightforwardly language-wise (calling the website the "work" always was a bit of a stretch, IMO), it would be un-italicized, and it wouldn't mess up all of the millions of times the template's already been used. Drewcifer (talk) 17:01, 12 August 2009 (UTC)[reply]

Unnamed editor who posted at 17:01, 12 August 2009 UT, what is a website? --Jc3s5h (talk) 17:14, 12 August 2009 (UTC)[reply]

Sorry, that was me. One too many tildes, though I've fixed it now. I'm not sure what you mean by your question. Go to website to find out more I guess. Or is this question leading somewhere? I'm very confused. Drewcifer (talk) 00:08, 13 August 2009 (UTC)[reply]

The website article indicates, and I agree, that a website is a collection of digital content that is addressed with a single domain name or IP address. It could be a work if it is under the creative control of a single entity. On the other hand, if the only thing the different components share is the address, then it does not qualify as a work. For example, home.comcast.com wouldn't qualify as a work because the component pages are independently created by the many subscribers to that ISP. On the other hand, Wikipedia (English version) is a single work. If there is to be a website parameter, there should be clear instructions about when to use it. In some cases, it would be redundant to give both a work parameter and a website parameter. Also, since a cite web citation will usually include a link, the website is indicated by the address, so isn't usually necessary. --Jc3s5h (talk) 00:36, 13 August 2009 (UTC)[reply]

I think we're somewhat in agreement here. Adding a website parameter is not meant to replace the work parameter. And alternatively, they could of course be mis-used, like any parameter in any template. So of course clear instructions would be necessary to avoid misuse and redundancy. That said, the clear difference between what one would call a "work" and what one would call a "website" means we need to add or adjust something in the template. Drewcifer (talk) 00:55, 13 August 2009 (UTC)[reply]

I'm using {{cite web}} with |ref= in some of my edits; it works in the same way as that at {{cite book}}. Should it be documented in {{cite web}} as per {{cite book}}, or is it deprecated and should I desist?

Further to that, the following parameters are recognised by the template source of {{cite web}}, but are not documented, and I can't find anything above to suggest that they're deprecated (as with |accessyear= etc.):

|at=
|authorlink1= to |authorlink9=
|dateformat=
|first1= to |first9=
|last1= to |last9=
|postscript=
|publication-date=
|separator=

nb |first1=, |last1=, |authorlink1= are all ignored if |first=, |last=, |authorlink= respectively are present; however |first2=, |last2=, |authorlink2= etc. are always valid. --Redrose64 (talk) 14:34, 16 August 2009 (UTC)[reply]