Template talk:Cite web/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 3 Archive 4 Archive 5 Archive 6

Create new param for permalink for specific version on same site as the original doc?

I don't think the text generated when using archiveurl, "Archived from [{{{url}}} the original] on [[{{{archivedate}}}]]", is appropriate for cases where the "archive" is just a permalink to a specific version at the same site as the original. How about adding a param just for this case? I'd be happy to code up a proposed change. --Jeremyb (talk) 16:08, 6 August 2008 (UTC)

That's exactly what the url parameter is for - a permanent link to the reference. The archiveurl is really intended for "off premises" archives - somebody else's copy of a page, presumably at a reputable archive like WebCite or Internet Archive. RossPatterson (talk) 18:42, 6 August 2008 (UTC)
So the living document shouldn't be linked at all? The use case I have in mind is an article ref to a MediaWiki wiki page on a non-WMF wiki. --Jeremyb (talk) 05:52, 7 August 2008 (UTC)
Not to be argumentative, but how is a wiki page different from a web page when used as a reference? Both are subject to change at somebody's whim, and with an accessdate= it should be clear what version of the page was intended as the reference. RossPatterson (talk) 16:46, 9 August 2008 (UTC)
WP:SPS Gary King (talk) 21:38, 9 August 2008 (UTC)
Most websites fail the self-published sources rule just as easily as wikis and blogs. Yet we have this template for citing web pages and we allow use of them as refernces when they are deemed to be reliable. I'll grant that blogs as a whole tend to be original research or opinion, but I think the jury is still out about wikis as a whole. RossPatterson (talk) 02:38, 11 August 2008 (UTC)
At the very least, in many cases we know the author of content on a webpage, especially personal websites; on wikis, the information can be written by literally anyone. Anyways, I was pointing to that page primarily because this discussion definitely belongs there and not here. I'm sure you can imagine the lengthy, lengthy, lengthy debates that a simple question like the one you posed can lead to. Gary King (talk) 02:46, 11 August 2008 (UTC)
Archiveurl should be used only when the original URL goes dead. Since the Internet Archive may have different versions of the original web page, it is useful to know the original URL. --—— Gadget850 (Ed) talk - 16:22, 10 August 2008 (UTC)


Add standard "location" parameter

{{Editprotected}} Please add the |location= parameter from {{Cite book}}, {{Cite journal}}, etc., as reference citations are not truly complete without this when it can be established. The code can simply be copy-pasted from one of those other templates in this series, as can the parameter's documentation (the parameter should be included in the default "common" options). I brought this up over a year ago; why hasn't it been fixed? — SMcCandlish [talk] [cont] ‹(-¿-)› 08:12, 4 September 2008 (UTC)

NB: I have just made the same changes (among other cleanup) at {{Cite comic}} and its documentation. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:17, 4 September 2008 (UTC)
Done I've added it, pretty much as a copy from {{Cite book}}. As in {{Cite book}}, the location will show up only if the publisher parameter is included. --Elkman (Elkspeak) 21:10, 9 September 2008 (UTC)

Broken

Resolved
 – Reported bug has been fixed.

Just of note, this edit broke the template somehow. –Juliancolton Tropical Cyclone 14:30, 4 September 2008 (UTC)

Fixed. That edit left a hanging [[; I removed it. grendel|khan 14:34, 4 September 2008 (UTC)
Looks good, thanks. –Juliancolton Tropical Cyclone 14:48, 4 September 2008 (UTC)

Quotation marks for titles

It is not Wikipedia method to quote titles using quotation marks, see for example this rendition of the cite web template: Paul Graham (2003). "Hackers and Painters". Retrieved on 2006-08-22. This should have been Paul Graham (2003). Hackers and Painters. Retrieved on 2006-08-22. I think the " should be changed to ''. However, I would greatly prefer that the quotes just be taken out, because the "title" that is being quoted is just a heading for a web page and not an actual title of a work, like the name of a book for example. They look really silly. Fortunately they don't appear when <ref>[http://www.foo.com/ Title] Retrieved on 2006-08-02</ref> is used. 199.125.109.129 (talk) 02:45, 5 September 2008 (UTC)

Strongly agree and disagree: 199 makes a good general point that the behavior is inconsistent, but the standard style (including in MLA and other style guides updated for the post-Internet world) is that works - e.g., an entire "web site" which can be defined in different ways, is italicized like a book or movie or album title, while a sub-item, like an article in a newspaper or magazine or journal, or a short story in a book-form collection (collection title italicized), or a song on an album, is put into quotation marks. So, they should not be removed, they should be normalized to be quotation marks, and italics applied to the work= field, not the title= field. Yes, some people will confuse the fields and misuse them, but life will go on, and there are many gnomes like me who will tool around and fix them. Basically, just do what {{Cite book}} and {{Cite journal}} do (except that {{Cite book}} uses |title= to mean what the other templates call |work=), since they are based on the MLA standards, and the rest of the {{Cite}}-family template have just been kind of doing whatever the heck they feel like, with wildly inconsistent results that contribute sharply to the general public perception of Wikipedia as amateurish and unreliable. — SMcCandlish [talk] [cont] ‹(-¿-)› 11:02, 6 September 2008 (UTC)
Post-script: When you do <ref>[http://www.foo.com/ Title] Retrieved on 2006-08-02</ref>, you are screwing your fellow editors, because no article with half-citations like that is ever going to make WP:FA (and often not even WP:GA), and someone, probably a whole bunch of someones, is going to have to visit every nothing-but-a-URL malformed source in the article and fill it out, either with {{Cite web}} or manually with all of the details that would have been sourced by {{Cite web}} (or more properly, {{Cite book}} and {{Cite journal}} which include the |location= parameter, a necessary piece of information for a full reference citation, thus my editprotected tag above). — SMcCandlish [talk] [cont] ‹(-¿-)› 11:06, 6 September 2008 (UTC)

Attempted killing of Wayback functionality

Some editors are trying to kill off this template

DG and a few other exclusionists/deletionists have basically taken over WP:EL for months now (they just wear out anyone who tries to discuss things with them). We could really use some Wikipedians with more common-sense over there..... frustrated (talk) 21:35, 6 September 2008 (UTC)

When it comes to external links, I agree with the "exclusionists/deletionists". I don't believe such links add significant value to most of the articles they're in, and I wouldn't miss them if they vanished. But I see your point - the basis of the argument is an assertion that archive sites, includng the Internet Archive, are copyright violators and as such shouldn't be linked to from Wikipedia. If that were deemed correct, we wouldn't be allowed to use them in citations either (e.g., {{cite web |archiveurl=...}}), which I think would be a great loss. RossPatterson (talk) 00:41, 7 September 2008 (UTC)
Unless and until someone successfully sues Archive.org or has them prosecuted for copyright infringement, this is not a Wikipedia issue. Archive.org's been around for over a decade now with no significant legal trouble. It is not WP's role to second-guess the legal system. We should also see WP:BROKE, and further remember that "that which is not forbidden is permitted", as the saying goes. That said, I agree with Ross and presumably with DB (whoever that is) that archive.org links in the External links section are kind of pointless. If it's not in the refs section and actually being used as a source for a fact in the article, then ditch it. And if it is, see if another source can be found. Linking to archives is basically a last resort to save a crucial source. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:27, 7 September 2008 (UTC)
In the first 14 entries (all I checked) at Special:WhatLinksHere/Template:Wayback, the template is found in the external links of these 5 articles: Common Desktop Environment, Encyclopædia Britannica, Economy of Germany, London Heathrow Airport, John Wilkes Booth.
The point is exactly that the External links can often be incorporated into the article's References at a later time. Unless they've been deleted.
DG = DreamGuy = has multiple rfcs and an arbcom, all about civility, but he treads the line enough to not get blocked - see his usual-rude reply to Jmabel at the 1st thread I linked above. (I'm trying to not make this about him, though he is the underlying problem behind this symptom of immediatism) (and yes, I'm a sock account who you wont see again. I'm trying to keep my real account away from his nastiness... but I do watchlist everything) frustrated (talk) 00:09, 8 September 2008 (UTC)
How is DreamGuy's previous RFCs appropriate for this discussion? It's starting to sound like forum shopping here... --Bobblehead (rants) 00:15, 8 September 2008 (UTC)
I've replied on this somewhere else. This discussion needs to be centralized. --—— Gadget850 (Ed) talk - 12:41, 11 September 2008 (UTC)

curly= parameter

This template has an undocumented |curly= parameter which, if set to anything at all, causes the double-quotes around the title to be displayed as typographic (aka curly) quotes (e.g., "title" vs. “title”, which may not look any different depending on your browser fonts). WP:MOS#Punctuation says "The exclusive use of straight quotes and apostrophes is recommended" and has for about a year, so I think that means the |curly= parameter should be ignored by the template. RossPatterson (talk) 03:30, 11 September 2008 (UTC)

It should just be removed. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:07, 14 September 2008 (UTC)
I just noticed that the |quote= parameter always uses typographic quotes, and should be changed to always use double-quotes per the same rule. RossPatterson (talk) 03:35, 11 September 2008 (UTC)

{{Editprotected}} Two quote formatting fixes needed as described immediately above, per WP:MOS. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:07, 14 September 2008 (UTC)

Done. --- RockMFR 16:12, 18 September 2008 (UTC)

Date linking deprecated

Resolved
 – Discussion centralized at Wikipedia talk:Citation templates#De-linking dates

Since date linking is now deprecated, shouldn't this template not have the date linked as well? Dismas|(talk) 23:16, 11 September 2008 (UTC)

Yeah, but since this and the other cite template use ISO 8601 I'd imagine the cleanup afterwards to be massive. ALTON .ıl 03:37, 14 September 2008 (UTC)
Irrelevant; 99.9% of all WP readers already see a bare ISO date in these fields because one of these templates chose that format and the rest unwisely followed suit, even though a moment's reflection tells us that the only WP users not seeing ISO dates here are the minuscule number of non-editor readers who have real user accounts and have turned on date formatting, and the diminishing number of editors who have done likewise. This shouldn't probably be discussed here anyway, but rather at Wikipedia talk:Citation templates#De-linking dates, where the discussion has been centralized. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:14, 14 September 2008 (UTC)

Machine translation field

{{editprotected}} I propose adding a "machine translation" field to the cite web template for non-English websites. SharkD (talk) 18:50, 18 September 2008 (UTC)

I have removed the editprotected template because this is a proposal, not a real edit that you want to make this instance. Gary King (talk) 18:55, 18 September 2008 (UTC)
OK, I'll see if I can come up with something. SharkD (talk) 18:59, 18 September 2008 (UTC)
What purpose would this parameter serve? What would you expect to supply as values for it? RossPatterson (talk) 23:07, 18 September 2008 (UTC)
I came up with two experimental versions, here. I'm not sure which of the two is better. SharkD (talk) 23:58, 18 September 2008 (UTC)
I don't know if a machine translation is a good idea as a reference because machines don't always translate correctly, and so if someone translates something to English and reads it and uses what they read to write new content, then the new content they write may be incorrect. So I oppose this idea for now. Gary King (talk) 01:17, 19 September 2008 (UTC)
Ah, so the intent is to provide a URL that links to a machine-generated translation of the reference, and possibly a translated title as well. I'm afraid I have to agree with Gary King - while I understand the idea, I think relying on automatic translation for reference purposes is counter to some of the Wikipedia citation guidelines. In particular, I think it violates "Cite the place where you found the material". If you read "Muere Tucapel Jiménez" en Espanol, just cite it as is with |language=Spanish. If you actually read it through Google's Spanish-to-English translator, cite it as such, but expect that it may raise somebody's hackles, because it may not be as reliable as an Edith Grossman translation. RossPatterson (talk) 01:50, 19 September 2008 (UTC)
Also oppose, and in fact machines never translate an entire page correctly. They're lucky to even get a sentence right. If a particular researcher wants to look at one of our sources, and do not speak the language in which it is written, it should be up to them to ask a live human to help them, or use one translation site or another one, or whatever. We needn't shoe-horn people into into going with a particular machine translation, as this may look like a WikiMedia endorsement of the translation service provider. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:09, 19 September 2008 (UTC)

addition of |ref =

Has there been consideration given to adding a | ref = to the template as exists in {{cite book}}? I know that it is my old habit, however, I keep trying to add it. <shrug> -- billinghurst (talk) 06:24, 22 September 2008 (UTC)

I agree, that would be useful in certain cases, even if not as often as with {{cite book}}. If no one objects by the 29th or so (i.e. a week from your first post), I say put up an {{editprotected}} request. You can refer to this diff to tell the admin exactly what you want done. Anomie 12:19, 25 September 2008 (UTC)
ref= sounds good to me. Gary King (talk) 14:25, 25 September 2008 (UTC)

Please reorder

{{editprotected}} Please place the quoted text first. Alexius08 is welcome to talk about his contributions. 11:11, 25 September 2008 (UTC)

This change would have a significant effect on reference lists, and should be discussed in detail for all the {{cite whatever}} templates before any change is made. It most certainly should not be made for just {{cite web}}, as that would make it inconsistent with the others. RossPatterson (talk) 12:00, 25 September 2008 (UTC)
Agree with RossPatterson, and I can see absolutely no valid reason to make such a change. The quote should be last, not first, in the citation. The point of the reference is the who/what/where of the reference, not a quote from it which should only rarely be necessary anyway. -- AnmaFinotera (talk · contribs) 14:13, 25 September 2008 (UTC)
Yes, it should be last for sure. They're sometimes huge, and so if placed somewhere near the beginning then they have the possibility of pushing some other vital information back to the end. Gary King (talk) 14:25, 25 September 2008 (UTC)

Shouldn't the dates be not linked per the MOS? - Peregrine Fisher (talk) (contribs) 00:04, 29 September 2008 (UTC)

See #Date linking deprecated. --Silver Edge (talk) 05:29, 29 September 2008 (UTC)

Format of date and accessdate etc.

Hello. Because of several tools for copiing references to other wikipedias, dates shoudt only be added in the ISO-format yyyy-mm-yy, yyyy-mm or yyyy (e.g. accessdate=2008-08-24 ). Otherwise, they make trouble by missing translation. Therefore I think, that the use of other formats and accessmonthday, accessdaymonth, accessyear etc. shoudt not be explained longer in the help of this template. Cäsium137 (T.) 19:20, 25 August 2008 (UTC)

If Casium137's advice is followed, then this template should not be used at all if any date within the template is in a non-Gregorian calendar. --Gerry Ashton (talk) 19:26, 25 August 2008 (UTC)
The accessdate should always be in the standard Gregorian calendar. I can't think of a reason why it would ever be appropriate to use another calendar for this, on the English Wikipedia.--Srleffler (talk) 03:14, 8 September 2008 (UTC)

There shoudt be a second template for use with non-Gregorian dates. Cäsium137 (T.) 00:29, 26 August 2008 (UTC)

Agree with Cäsium137, Gerry Ashton if we were not to use a template for anything involving Julian calander and therefore had manual-only references, it would be even harder for other languages to decipher, I'd have no problem undertanding a date in a Russian article that states 1321-05-23. But here is a link from Russian Asthma article: "Бронхиальная астма как нейрогенное воспалительное пароксизмальное заболевание. — Патогенетические нейрогенные механизмы и лечение. Проверено 16 июня 2007", now I can guess the year and day, but need direct knowledge of Russion to translate the month of "июня", where as if internally that article had the date as 2007-xx-16 we would instantly know which month xx was. Likewise unless the above ref is in some form of template, I can only guess at which bit is author or journal name and article title vs research group. Template have their uses although some learning curve for new editors (but poorly formated refereance of just a name and year are often worse than useless) - but the parameter list does help encourage editors to be as complete as possible with citation details, but that is another tangential discussion :-) David Ruben Talk 00:50, 26 August 2008 (UTC)

accessdate formatting

Can the templates be fixed so that they allow the form "Retrieved on January 1, 2008" as an alternative to "Retrieved on 2008-01-01"? If I indicate the article date as June 1, 2007, for consistency, I prefer to use the same date style for the accessdate: "Retrieved on January 1, 2008" as opposed to "Retrieved on 2008-01-01". Also, I would prefer it if wikilinking the accessdates was optional (requiring the use of brackets). Thanks. --Phenylalanine (talk) 06:07, 26 August 2008 (UTC)

Two notes of relevance here:
  1. However it is formatted, it should be formatted identically in all {{Cite}}-family templates.
  2. WP:MOSNUM (finally; this has been building up for several years now) has deprecated the wikilinking of dates for autoformatting purposes, so this all other {{Cite}}-family templates need to stop doing that. There may be other repercussions as well, the most obvious being that some of them use separate day=, month= and year= fields, and put them in a particular order which will no longer agree with WP:MOSNUM. There's no huge hurry in changing this, as the current wording is still under discussion and being fine-tuned, but expect to change it eventually. PS: Sorry for prior confusion with regard to {{Fix}}; at the time I was having simultaneous template-related discussions about two different families of templates, and took a phone call, with the end result that I confused myself pretty severely for a moment. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:55, 27 August 2008 (UTC)
This template still does not have the same formating as cite news. i am not sure with one is right. Oldag07 (talk) 20:26, 25 December 2008 (UTC)

Dates are linked....

Resolved
 – Duplicate topic.

....in the "Retrieved on ____ ____ ____" part of the template...per WP:MOSNUM, they should not be.... Cheers, the_ed17 03:54, 4 September 2008 (UTC)

If you read the sections above you will see that work on this is underway. Rjwilmsi 06:18, 4 September 2008 (UTC)

{{editprotected}}

Why were these edits made without discussion first? Work is underway to fix this; a major sweeping change like this needs some discussion first. Please undo them. Thanks! Gary King (talk) 15:33, 4 September 2008 (UTC)

I disagree that this is an uncontroversial change. "Work is underway to fix this"? I'm not sure exactly what this statement refers to, but I'm not aware of any technical solution that has any consensus. --Gerry Ashton (talk) 15:44, 4 September 2008 (UTC)
Right now, the dates appear as 2008-01-01; when they were linked, they appeared according to user preference. We were working on showing the dates based on a format specified when using this template. Gary King (talk) 15:51, 4 September 2008 (UTC)
Ah, I just saw Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Dates_in_citation_templates_and_creation_tools, which doesn't have many people involved in it? Anyways, we can leave it like this for now; hopefully there will be no repercussions. Gary King (talk) 15:55, 4 September 2008 (UTC)
After gathering my thoughts about this, I am unstriking the editprotected because if this template is going to unlink accessdates, then the other citation templates should do the same, to be consistent. Cite news, for instance, is often used together with cite web, and both look nearly identical; now we've got one that shows unlinked accessdates in YYYY-MM-DD and the other showing the accessdate in the user's preferred date format. While talking to another administrator about this, I said, and would like to re-iterate here, that I would prefer a discussion, even one that only lasts for 24 hours, and then the edits made; so at least this doesn't come as a surprise to many people and so people can get their thoughts in. Gary King (talk) 15:59, 4 September 2008 (UTC)
Thanks for your understanding. The MOS explicitly states than these dates shouldn't be linked, so, I think we should follow that. Cheers, —Anonymous DissidentTalk 23:42, 4 September 2008 (UTC)
I realize that (believe me, I've been in the thick of it and support unlinking dates – I'm a content contributor myself), but we've even worked with some of the most vocal supporters of the change (including User:Tony1) on converting this template so that the dates appear as something besides YYYY-MM-DD. Gary King (talk) 00:01, 5 September 2008 (UTC)
The issue hasn't been resolved since the accessdates still appear to be linked. --Phenylalanine (talk) 11:42, 11 September 2008 (UTC)

Template still indicates to link dates

Is it possible to get the DATE component of the template instructions modified. It still indicates that DATE can/should be wikilink'd. It would seem evident from discussions that dates should not be sso, and it is a might confusing when the instructions don't, and contrarily advocate do. Thanks. -- billinghurst (talk) 00:58, 14 October 2008 (UTC)

Period separation

Is there any reason that this template uses seperation by periods (.) when Template:Citation uses commas (,)? It would seem to make sense to make them both use one or the other, wouldn't it? — Byeitical (talk · contribs) 01:01, 27 August 2008 (UTC)

Very much so. I would strongly suggest doing what {{Cite journal}} and {{Cite book}} are doing, since as far as I can tell they are the only {{Cite}}-family templates that are actually based upon a (non-Wikipedia) standard citation format; {{Cite web}}, {{Cite news}}, {{Cite comic}},{{Cite video}}, etc., have a lot of inconsistencies. Not sure what to day about {{Citation}}; I have not reviewed it in enough detail yet. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:58, 27 August 2008 (UTC)
It's very hard to change at this point, because lots of existing articles make assumptions about whether the template ends in a period, and whether additional clauses after the cite template should add a comma after the template. — Carl (CBM · talk) 17:14, 27 August 2008 (UTC)
Thanks for the insight. — Byeitical (talk · contribs) 18:11, 27 August 2008 (UTC) —Preceding unsigned comment added by Byeitical (talkcontribs)
Nah, that's what bots are for! "A bunch of articles will need to be changed" is not a good rationale for not having a template do what it should be doing. — SMcCandlish [talk] [cont] ‹(-¿-)› 08:05, 4 September 2008 (UTC)
More citation styles used outside of Wikipedia have punctuation similar to {{Cite XXX}}, rather than {{Citation}}. Also, bots would have fewer pages to edit if we changed {{Citation}} and we would have fewer hand-written references to double-check. --Karnesky (talk) 17:04, 26 October 2008 (UTC)

Am I using authorlink parameter incorrectly?

Please see the first citation on this page and tell me if I am using the authorlink parameter correctly. If I add it to that citation it makes the first name a link and the last name gets put on the end of the link. Take a look please. Padillah (talk) 19:42, 30 September 2008 (UTC)

Yes, you are doing it wrong. The authorlink is the name of the Wikipedia article on the author, not an external link. Since ther eis not article for Nicholas Carlson, don't use the authorlink. --—— Gadget850 (Ed) talk - 20:27, 30 September 2008 (UTC)
Not sure I'd buy that. We don't avoid red links for cosmetic reasons. The test should be whether or not there ought to be an article Nicholas Carlson. If he's notable enough to create one, then a red link is a good thing that will encourage someone to start that article and keep track of the fact that it hasn't yet been done. Use the authorlink if you believe the article should exist, then create it, at least as a stub. This could, in principle, be semi-automated with bot checks against major author indices (oclc, scholar, pubmed, etc) for multiple publications or publications with multiple editions.LeadSongDog (talk) 15:58, 22 October 2008 (UTC)

Accessdaymonth broken ?

Can anyone find what I did wrong here, or is accessdaymonth broken? [1] The Day Month isn't showing in the result, only the year shows. SandyGeorgia (Talk) 18:21, 13 October 2008 (UTC)

You're using {{cite encyclopedia}}, which doesn't have accessdaymonth. Gary King (talk) 18:29, 13 October 2008 (UTC)
Well, crap :-) As I was cleaning up their refs, I didn't even notice that. Thanks, Gary! (Now someone needs to fix cite encyclopedia: it still beats me why these templates can't stay in sync.) SandyGeorgia (Talk) 20:15, 13 October 2008 (UTC)
You think that's bad ... Cite news just declared UDI. Mr Stephen (talk) 22:42, 13 October 2008 (UTC)
Should someone delink the dates in this template? -Peregrine Fisher (talk) (contribs) 00:02, 14 October 2008 (UTC)

accessdate link

Is there a decision on this that I missed? Or does it still need to be unlinked? GrszX 03:35, 16 October 2008 (UTC)

See WT:Citation templates#De-linking dates. --Silver Edge (talk) 03:52, 16 October 2008 (UTC)

Parallel activity

Editors here may be interested in Wikipedia talk:Manual of Style#Merging the zillions citation templates out there and Wikipedia talk:Manual of Style#Comments (templates merger) on a new Citation template that would putatively replace all the Cite family.LeadSongDog (talk) 15:59, 22 October 2008 (UTC)

equals in url truncates link

How do you stop a link like http://www.hrt.hr/index.php?id=48&tx_ttnews[tt_news]=18603&tx_ttnews[backPid]=38&cHash=6d8138b114 being truncated at the second "="?Dejvid (talk) 23:16, 26 October 2008 (UTC)

You realize that it has nothing to do with the "=" at all, and properly urlencode your brackets: http://www.hrt.hr/index.php?id=48&tx_ttnews%5Btt_news%5D=18603&tx_ttnews%5BbackPid%5D=38&cHash=6d8138b114. Anomie 23:42, 26 October 2008 (UTC)
Thanks, now I see what the problems is.Dejvid (talk) 00:06, 27 October 2008 (UTC)

date

[1]

[2]

  1. ^ "Jackie Makes Good". Time. August 26, 1946. Retrieved 2008-10-12. {{cite web}}: Italic or bold markup not allowed in: |publisher= (help)
  2. ^ "Jackie Makes Good". Time. April 11, 2007. Retrieved 2008-10-12. {{cite web}}: Italic or bold markup not allowed in: |publisher= (help)

Why is the date linked for some dates? - Peregrine Fisher (talk) (contribs) 17:13, 31 October 2008 (UTC)

Dates aren't automatically linked before January 1, 1970 because of Unix time. Gary King (talk) 17:47, 31 October 2008 (UTC)
I don't know, but it looks like bugzilla:11686, which is fixed in version r42663; the current version is 1.43.0-wmf.4 (2111e6d). Mr Stephen (talk) 17:59, 31 October 2008 (UTC)
Yep, that patch will fix this problem once it is released. Gary King (talk) 18:02, 31 October 2008 (UTC)

Please delink accessdate

Cite news accessdates have been delinked. now, for consistency, Cite web accessdates should also be delinked. Thanks.

Example: "Functional and Structural Comparison of Man's Digestive Tract with that of a Dog and Sheep". Retrieved January 19, 2008. --Phenylalanine (talk) 22:20, 1 November 2008 (UTC)

… but please replace the auto-linking with the template {{Date}} to avoid the ugly display of ISO dates. Michael Bednarek (talk) 12:28, 1 November 2008 (UTC)
Note that {{date}} will cause inappropriate output on articles not using DMY date ordering. Anomie 17:08, 1 November 2008 (UTC)
@Phenylalanine: Your example uses a date format which does not conform with the template's requirements (it requires ISO date, you gave MMMM DD, YYYY) What exactly is your example trying to point out?.
@Anomie: Displaying "2 November 2008" is always better than "2008-11-02", even if the rest of the article uses "November 2, 2008". Michael Bednarek (talk) 06:32, 2 November 2008 (UTC)
So says you. I happen to prefer YMD format dates outside of running prose and possibly infoboxes, the other formats are needlessly verbose. There is absolutely no reason for an article to have MDY format and the references to have DMY format, and the reference templates should not dictate the article format. Anomie 14:38, 2 November 2008 (UTC)
I appreciate your preference of YMD over MDY; I don't care either way. My point is that ISO display is not desirable. But that's what we get if the auto-linking of "accessdate" in these templates is simply removed. Any format is better than ISO. It just so happens that {{Date}} shows DMY. Michael Bednarek (talk) 02:12, 3 November 2008 (UTC)

Here is how the two templates compare. Notice how the accessdate parameter output is different: With "Cite web", the accessdate is auto-linked; not with "Cite news". For consistency, auto-linking of "Cite web" accessdates should be removed as per "Cite news":

Cite web:

{{cite web
  | last = Hansen
  | first = James E.
  | coauthors = R. Ruedy, M. Sato, and K. Lo
  | title = GISS Surface Temperature Analysis Global Temperature Trends: 2005 Summation
  | publisher = Goddard Institute for Space Studies|NASA Goddard Institute for Space Studies
  | date = 15 December 2005
  | url = http://data.giss.nasa.gov/gistemp/2005/
  | accessdate = 28 September 2006 }}

Hansen, James E. (15 December 2005). "GISS Surface Temperature Analysis Global Temperature Trends: 2005 Summation". Goddard Institute for Space Studies. Retrieved 28 September 2006. {{cite web}}: Text "NASA Goddard Institute for Space Studies" ignored (help)

Cite news:

{{cite news 
  | last = Andersen
  | first = David
  | coauthors = Witter, Lameen
  | title = Former Marine, Go Daddy CEO Talks About His Rise to Success
  | publisher = Marine Corps News
  | date = 17 February 2006
  | url = http://www.military.com/Careers/Content1?file=careersArticlesGoDaddy.htm&area=Reference
  | accessdate = 2 Juin 2006 }}

Andersen, David (17 February 2006). "Former Marine, Go Daddy CEO Talks About His Rise to Success". Marine Corps News. Retrieved 2 Juin 2006. {{cite news}}: Check date values in: |accessdate= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)

--Phenylalanine (talk) 13:53, 2 November 2008 (UTC)

Are you suggesting the input requirements to the parameter "accessdate" be completely removed and it should accept any old text string? Michael Bednarek (talk) 02:12, 3 November 2008 (UTC)
In the short term it's appropriate to delink the accessdate, in the longer term we need a proper solution like the datestyle parameter discussed above to allow editors to choose the date format of the references that matches the subject of the article. We shouldn't just accept any string for the accessdate as this will reduce consistency going forward. Rjwilmsi 08:02, 3 November 2008 (UTC)

date expression

{{editprotect}}

is there anything being done yet to return some consistency to the citation templates?

deprecated/discouraged; linked/unlinked or whatever....i'd just like to see them standardised. (this has been posted to both talk pages) --emerson7 16:32, 6 November 2008 (UTC)

Cite news jumped the gun and delinked without maintaining or fixing the format. *sigh* I'd say that one needs to be reverted until its properly done. -- AnmaFinotera (talk · contribs) 16:36, 6 November 2008 (UTC)

It's worth noting that for new citations, the accessdaymonth/accessmonthday solution works for both templates. I think that what's needed is some enterprising bot creator to make a bot or script that changes accessdate to accessdaymonth or accessmonthday and accessyear, as appropriate, in templates put in before autolinking of dates was deprecated. (It should also change the format in the "date" field from ISO 8601 to whatever's appropriate for the article.) —Josiah Rowe (talkcontribs) 18:33, 6 November 2008 (UTC)

I'm declining the edit request, since it's not clear what needs to be changed, and there doesn't appear to be a clear consensus. Once there's a consensus, please resubmit the request, thanks. --Elonka 04:11, 7 November 2008 (UTC)
Delinked per consensus at WT:Citation templates#De-linking dates. Conscious (talk) 10:25, 9 November 2008 (UTC)
Please undo this! Yes, there is consensus to delink the dates, but unless the templates without something to fix the existing dates, a ton of references now look horrible! That's why the edit request was denied. -- AnmaFinotera (talk · contribs) 16:01, 9 November 2008 (UTC)
I have added a hack to convert ISO date and accessdate to day-month-year format. Conscious (talk) 19:02, 9 November 2008 (UTC)

Arbitrary date format change

{{editprotected}} Please undo User:Conscious's recent edit. It arbitrarily forces the date to DMY format, irrespective of the format of dates used in the rest of the article or in the other references. If Wikipedia wants to force DMY format on all articles, that should be widely discussed and not done by one admin acting on their own. Anomie 20:00, 9 November 2008 (UTC)

I just want to note that only ISO dates are converted to DMY, MDY dates are left unchanged. If this is undesirable, the edit indeed needs to be reverted. Conscious (talk) 20:22, 9 November 2008 (UTC)
I agree, this needs to be undone. Arbitrarily forcing ISO to DMY is not desirable at all except on articles that area already using international date format. For the other thousands of articles, this is not appropriate and results in a mix of American and International dates. A hack isn't want is needed, but a real solution that deals with the delinking in a way that the dates are automatically reformatted to match the articles other date formats. -- AnmaFinotera (talk · contribs) 21:02, 9 November 2008 (UTC)

Agreed, revert the change. ForcinDMY for articles across all of Wikipedia definitely is not desired by everyone here. DiverseMentality 21:23, 9 November 2008 (UTC)

Undone. --- RockMFR 23:38, 9 November 2008 (UTC)

Now the dates display as (for example) 2008-11-09 instead of November 11, 2008. DiverseMentality 23:41, 9 November 2008 (UTC)
Yes, because for now I'm guessing there is no known why for the template to know which date format to use. So editors will have to continue manually updating refs (or use Lightmouse's script to do them faster). :( -- AnmaFinotera (talk · contribs) 01:03, 10 November 2008 (UTC)
So we actually have to start writing out the dates from now on? DiverseMentality 01:09, 10 November 2008 (UTC)
So it would seem, though no one can seem to agree there either. Half the templates still do it, half don't, and I don't think there really is a central discussion anywhere. :( -- AnmaFinotera (talk · contribs) 01:11, 10 November 2008 (UTC)
Yeah. The whole MOS:DATE change was shoved through, and then a bunch of people went off and removed date linking from these templates with minimal discussion and without any sort of real plan of action to deal with the repercussions.
IMO, the best solution would be extension to add a "DEFAULTDATEFORMAT" magic word that can be used like DEFAULTSORT or DISPLAYTITLE, and then <date> tags that will reformat the contained date into the specified format. Bonus if it handles date ranges, and bonus if it supports the user date preferences (and even more bonus if it allows <date short="yes"> and user preference between "normal"/"YYYY-MM-DD"/"MM-DD-YYYY"/"DD-MM-YYYY"). Unfortunately, T6582 seems to be going off in a different direction, trying to guess non-logged-in user date format preferences based on browser headers and making what looks like a link (e.g. [[2008-11-09]]) mean "autoformatted plain text" instead. Anomie 03:00, 10 November 2008 (UTC)
I think I'm just going to stop using the templates. There is no coordinated effort to maintaining these and consensus is all over the place. They are nice when they work, but this is ridiculous. --—— Gadget850 (Ed) talk - 04:20, 10 November 2008 (UTC)
Indeed; this is madness. The whole point of these templates from the content provider's position is "use and forget". I am seeing editors taking the accessdate outside the templates, and/or swapping over to accessdaymonth/accessyear. While this is do-able over a smallish number of articles it isn't realistic over the whole encyclopedia, and shouldn't be necessary. The poor reader is left with ISO-style dates which (AIUI) no country in the world uses. I thought Conscious brought a breath of fresh air to the templates. Mr Stephen (talk) 12:32, 10 November 2008 (UTC)
A solution to this problem has been worked out on the Norwegian wikipedia. We uses ISO dates for date parameters in no:Mal:Kilde www (the norwegian name for this template) and convert them to the default norwegian official language standard d. mmmmm yyyy by using the template no:Mal:ISOtilNorskdato (not yet converted to english/american unofficially standard here at en-wiki). So if you give the accessdate = 2008-10-11, it will be shown as 11. november 2008 for every reader if it's not wikilinked (a parameter). This will only works for dates in the range 1970-01-02/2038-01-19 (since it uses the #time-function). Nsaa (talk) 14:40, 10 November 2008 (UTC)
(ED) Personally, I think all that delinking needs to just be reverted until a real solution is found that fixes all of the templates via a bot before its turned off, but I suspect no one will agree to do that :( Nsaa, these templates were doing that based on user preferences. The issue is there are technically two English standards so using all mdy would mess up all articles using the international format (particularly European focused articles), while using all dmy messes up the many American and non-European articles.-- AnmaFinotera (talk · contribs) 14:42, 10 November 2008 (UTC)
In this template (and all other templates using date parameters) it should be possible to add a new parameter dateformate = and set it to dmy (default) or mdy, the datformate could then be used in the english version of no:Mal:ISOtilNorskdato to decide what date format should be returned. The biggest problem using this way is that a lot of dates isn't covered (every date before 1970-01-02 and after 2038-01-19). The template will only convert recognized ISO dates, others will be returned as they were written. I can try to work out an example using this template here: template:Cite web3. Personally I think it's really bad not using a standardized way of giving dates (like ISO 8601) in technically things like a parameter. Nsaa (talk) 15:30, 10 November 2008 (UTC)
I've now created {{DATEtoMOS}}. Using it with the following parameters on the date 2006-05-04 {{DATEtoMOS|2006-05-04|mdy}} gives May 4, 2006 or {{DATEtoMOS|2006-05-04|dmy}} gives 4 May 2006 Nsaa (talk) 16:18, 10 November 2008 (UTC)

Look at the two working examples at Template:Cite_web3 on how to use a new parameter dateformat in this (and all other dateparameter templates) to decide wath format to use (english or american). The only thing I've done to the current version of Template:Cite_web is this [2]. Nsaa (talk) 17:52, 10 November 2008 (UTC)

Note that the 1970-2038 bug is fixed, we just have to wait until Wikipedia is scapped to r42663 or above (it's at r42593 at the time of this comment). A major drawback to your suggestion is that would mean that all the millions of transclusions of the various templates would have to be edited to specify that parameter. Anomie 18:01, 10 November 2008 (UTC)
Coool! (didn't know about r42663, where's it located? found it at bugzilla:16108 and Mediawiki r42663). We could just default to dmy in {{DATEtoMOS}} (now it defaults to the input paramter), so it's not necessary to give the parameter in all the already created pages. Nsaa (talk) 18:18, 10 November 2008 (UTC)
Be aware that using the term ISO 8601 is pretty safe for cite web, but a bad idea for other citation templates. This is because web pages have all been written in the 20th or 21st century, and almost always use the Gregorian calendar. When citing books and journals there is a substandial risk that they might have publication dates given in the Julian calendar. A few are works are cited in Wikipedia that were published before 1583, and ISO 8601 may only be used for years between 1583 and 9999, and only for dates given in the Gregorian calendar. (The year range can be expanded by mutual agreement by partners exchanging information, but the Gregorian requirement may not be waived.) So some of the ideas being worked on here won't work for cite book or cite journal.
Also, using the term ISO 8601 in the documentation of this page would reinforce the idea that dates in the YYYY-MM-DD are indeed intended to conform to ISO 8601, and thus using that format with a Julian date, anywhere in the encyclopedia, is a factual error. --Gerry Ashton (talk) 18:49, 10 November 2008 (UTC)
In other words, call it "YMD format" instead of "ISO". Anomie 22:54, 10 November 2008 (UTC)
Look at the examples at Template:Cite web3 (and Template:DATEtoMOS, maybe it should be moved to Template:DatetoMOS?) now, I've incorporated handling of all the tree major input dates, added ymd instead of iso, and chosen dmy (maybe mdy should be choosen) as Default where the dateformat is not given. Nsaa (talk) 23:16, 10 November 2008 (UTC)
Wow, looks very good to me. I thought we'd never find something that worked! Of course, we won't get away from the fact that articles will need to be updated to set the new dateformat field, but that's easy enough to do by script and apply by category etc. Also, this change would leave existing articles operational and unlinked with the most sensible default. Rjwilmsi 00:30, 11 November 2008 (UTC)
But shouldn't the resulting date output not be linked by default? Michael Bednarek (talk) 02:48, 11 November 2008 (UTC)


I've updated Template:DATEtoMOS so it is not linked by default and changed paramter 2 and 3, since linking is used rarely. So

  • {{DATEtoMOS|2007-01-24}} gives 24 January 2007
  • {{DATEtoMOS|2007-01-24|mdy}} gives January 24, 2007
  • {{DATEtoMOS|2007-01-24|mdy|y}} gives January 24, 2007

The change done in Template:Cite web3 could probably now be applied to Template:Cite web, but before this is done by an administrator maybe a note should be postet on WP:VPT and let more people be aware of the change (maybe there is issues regarding performance when applying the {{DATEtoMOS}} to the heavily used {{Cite web}} or other stuff that is not yet seen by the relatively few people engaged in this discussion. Nsaa (talk) 09:50, 11 November 2008 (UTC)

Certainly, and to Wikipedia_talk:Citation templates too, as this change should logically be applied to all citation templates using dates to maintain consistency. Rjwilmsi 12:10, 11 November 2008 (UTC)
Added Wikipedia_talk:Citation_templates#Adding_dateformat and Wikipedia:Village_pump_(technical)#Adding_dateformat. Nsaa (talk) 13:45, 11 November 2008 (UTC)

Use of DATEtoMOS must be strictly limited to Cite web, or in other citation templates, the accessdate parameter. The template does not properly handle dates outside the asinine UNIX time range of 1970 to 2038. --Gerry Ashton (talk) 17:27, 11 November 2008 (UTC)

Is there really need for such a bold comment that is going to be out of date as soon as revision r42663 is scapped? Anomie 18:11, 11 November 2008 (UTC)
The template is broken, and its severe limitations must be carefully taken into account until it is fixed. Who knows when the new version will be installed? Who knows over what date range the new version will work? Once the new version is installed, the template should be tested to establish what date range it can handle. Nothing in the template documentation limits its use to citation templates; anything that could be described with a calendar date is fair game. --Gerry Ashton (talk) 19:03, 11 November 2008 (UTC)
To answer your second question, the new {{#time:}} code can handle dates from 0000-01-01 to 9999-12-31. The underlying PHP code can handle an even larger range, but it can't seem to parse dates with years with more than 4 digits and the MediaWiki date handling seems to choke on negative years. Anomie 23:54, 11 November 2008 (UTC)

I'm very impressed by this template. I have made some changes and doubled its efficiency, but the underlying principle is incredibly elegant. I can see no reason why, with a suitable default value for |1=, this code cannot replace {{date}}, which is desperately in need of an overhaul. The parameters as they stand are entirely backwards-compatible with those at {{date}}, except that this new code does not support dates without years (the current year is assumed). I can correct this without any loss of efficiency when the software is updated past r42663 and the check against pre-1970 dates is no longer required. You needn't be concerned, Gerry Ashton: this will happen within a few days, a week at the very longest, long before we are able to deploy this elegant template. And the new function will correctly handle any date between 0AD and 32767AD exclusive. It will not, of course, differentiate between the Julian and Gregorian calendars, but it can hardly be faulted for that. Once these tweaks have been made, I think we should update {{date}} with this new code and then we will finally have found a partial solution to the great date debate... we remove the requirement for links, retain the ability to enter dates in any input format, and create a unified, sensible output format. If/when a more complete solution to the date-autoformatting debacle is found that requires special syntax (like <date>...</date> tags) these can be added directly to the template, allowing us to instantly update every date on en.wiki to use the new formatting. The corrolary of this, of course, is that this new template should be used everywhere where dates should be volatile, and not elsewhere. However I think we can all agree that, once the issues with the date range are resolved, this will be an invaluable tool in improving our handling of dates on en.wiki. Great work everyone! Happymelon 23:49, 11 November 2008 (UTC)

I have found a characteristic of the DATEtoMOS template which should be documented. It accepts non-existent dates and treats them from an arithmetic point of view. See User:Gerry Ashton/sb-DATEtoMOS for examples. --Gerry Ashton (talk) 00:15, 12 November 2008 (UTC)
This behaviour is similar to how many other high-level languages deal with dates. I would consider this a feature rather than a bug (it allows simple date arithmetic). I agree, it should be documented. Michael Bednarek (talk) 02:31, 12 November 2008 (UTC)
I've tried to incorporate this into the documentation. Problem 1: My intention on the first hand was only to allow for #time:Y-m-d #time:F j, Y #time:j F Y formats, i.e. you will need to give the date in one of the three syntax's 2008-01-02, 2 January 2008 and January 2, 2008 (We shouldn't let people use other formats). But the code seems to interpret a lot of other variants also. For example it shouldn't have accepted {{DATEtoMOS|Dec 24th, 2007}} → 24 December 2007 [3] or {{DATEtoMOS|29 February 2007}} → 1 March 2007 [4] since 29 February 2007 isn't eq to 1 March 2007. Maybe it's possible to adjust the template so it handles these cases in a proper way (I supposed the condition {{#time:j F Y|{{{1}}} }}={{{1}}} shouldn't return a true value in these circumstances). Problem 2 and range: As long as the template just returns the value given it should be OK to use this template (since it doesn't affect dates outside the range). And if this fix is released in a weeks time we should maybe just wait if this is considered a big drawback (I don't think so in this particular template)? Nsaa (talk) 12:41, 12 November 2008 (UTC)
Let's wait for the mediawiki SVN fix so, once agreement is reached, we are in a position to roll out the change to all cite templates to maintain the most consistency.
Re other date formats: we'll never be able to stop users entering any old date format into the citation, templates can only be expected to support what they're designed for. I've already got a script to fix common errors, as do others. Such fixes could also be included in AWB general fixes. Rjwilmsi 13:58, 12 November 2008 (UTC)

(outdent) The update seems to have been applied. The examples at DATEtoMOS look good to me. Mr Stephen (talk) 00:42, 15 November 2008 (UTC)

Display of date - do we have to change manually?

Display of dates as yyyy-mm-dd looks absolutely ghastly. Dates look much better displayed as dd-mm-yyyy which is how the were displaying before the template was fiddled with. Have we got to go round manually changing every instance of the {{citation needed|date={{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}}} template to show the date in a visually acceptable form? Mjroots (talk) 07:58, 14 November 2008 (UTC)

Yes, "yyyy-mm-dd looks absolutely ghastly". No, we don't have to fix them by hand. We are waiting for an update to the software that runs Wikipedia. After that, all of the "cite X" templates will be changed to improve date display. See the discussion immediately above. Mr Stephen (talk) 08:08, 14 November 2008 (UTC)
Great, so I can continue entering new references in the usual way and the software will catch up later. Mjroots (talk) 08:10, 14 November 2008 (UTC)
  • Just to clarify this issue, should I enter dates in yyyy-mm-dd (eg. 2008-11-14) format without any markup and this will be fixed soon with the update? Or should I use the wikilink to format the date (eg. [[2008-11-14]])? Bill (talk|contribs) 11:06, 14 November 2008 (UTC)
Enter dates in unlinked YYYY-MM-DD. Within a couple of weeks the template should be updated to change the default display format to 'D Month YYYY' (this will be automatic). Also the template will allow the user to choose 'Month D, YYYY' display format for American-themed articles by adding another field to the citation (dates entered as YYYY-MM-DD will then be reformatted automatically). Rjwilmsi 12:07, 14 November 2008 (UTC)
Note that after the suggested change, dates entered in any format, but with no specification of the output format, will be reformatted to DD mmmm YYYY. Therefore, every single citation in every article that uses the mmmm DD, YYYY format will have to have the appropriate parameter added.
Question: has the documentation on how to use {{Cite web}} after the change been written yet. If so, where is it? --Gerry Ashton (talk) 14:27, 14 November 2008 (UTC)
Why is it being donw with dmy as the default instead of mdy?? I don't see anything discussion or consensus above that proclaims dmy to be the most used format nor the preferred default. If anything, I would think mdy would be the default with a parameter to change to dmy. In either case, I certainly hope someone is making a bot that will fix every last article that has the wrong format on it, since it seems the new template will be overriding those that have already been manually changed to the appropriate full date format. -- AnmaFinotera (talk · contribs) 15:10, 14 November 2008 (UTC)
There is no way for a bot to detect which date format is appropriate for an article. --Gerry Ashton (talk) 15:23, 14 November 2008 (UTC)
I would think one could at least make a reasonable guess based on the date format being used outside of references? Also, I think this planned change should not automatically reformat dates already in either mdy or dmy format as its pretty clear they have already been fixed, so reformatting them differently would just be poitnless.-- AnmaFinotera (talk · contribs) 15:30, 14 November 2008 (UTC)

What's the big deal - can we not just copy how {{cite news}} and {{cite journal}} are doing it? See the citation in the Anarchy_Alive! article - cite web is the only one showing yyyy-mm-dd. the skomorokh 16:36, 14 November 2008 (UTC)

Because it is also forcing a specific date format, with no option to switch. -- AnmaFinotera (talk · contribs) 16:44, 14 November 2008 (UTC)
At least in the case of cite news, one can specify either accessdaymonth or accessmonthday, in combination with accessyear, to put the date elements in whatever order you want (or so says the documentation, if you look very close). --Gerry Ashton (talk) 17:35, 14 November 2008 (UTC)
Why not just deprecate the use of YYYY-MM-DD as an input for accessdate. The easiest solution is to ask the user to enter accessdate=16 November 2008 or accessdate=November 16, 2008 whichever is appropriate. As the skomorokh said, the other cite templates work. Although they default to one standard, someone will have to edit the articles to flag them the other way. Why the complication of configuring a template to adjust the look when the date can be entered in the correct format anyway? ++ MortimerCat (talk) 09:48, 16 November 2008 (UTC)
Because it's not necessary to do so. If you "ask the user to enter XXX", maybe 99% of users will do so. The remaining 1% will either enter YYY regardless, in which case someone has to take time to fix it, or they won't enter anything at all. In both cases, productivity is lost, and we don't have any of that to spare. Instead, we can ask users to "enter whatever the hell you like and let the template sort it out", which I guarrantee 100% of users will be able to acomplish :D. In the limited set of cases where the output is genuinely important, we have a way to customise the output as necessary. In this situation, we really can have our cake and eat it. Happymelon 22:24, 16 November 2008 (UTC)
You think you can make something idiot proof, but idiots can be ingenious. ++ MortimerCat (talk) 23:25, 16 November 2008 (UTC)
To a reasonable degree of accuracy :D. I know what you mean though, but given that those people are going to be left hanging whatever happens, I think the point still stands. Happymelon 00:35, 17 November 2008 (UTC)

Well, here we are a month further down the line, and the software still hasn't been fixed! Mjroots (talk) 10:33, 14 December 2008 (UTC)

template problems

{ {cite web |last=Murphy |first=Robert P. |url=http://mises.org/story/1001 |title=Econometrics: A Strange Process |accessdate=2008-11-14 |authorlink=http://mises.org/articles.aspx?AuthorId=380} }

Murphy, Robert P. "Econometrics: A Strange Process". Retrieved 2008-11-14. {{cite web}}: Check |authorlink= value (help); External link in |authorlink= (help)

This doesn't seem to display properly... what am I doing wrong? —Memotype::T 22:36, 14 November 2008 (UTC)

If you are talking about the date, see the above discussion. JodyB talk 22:39, 14 November 2008 (UTC)
No, sorry, the problem was that I was using a url for the 'authorlink' attribute. Thanks though. —Memotype::T 22:42, 14 November 2008 (UTC)
Authorlink is only for wikipedia articles about the author, not for external links. Please see the documentation. Huntster (t@c) 01:13, 15 November 2008 (UTC)

Explanation needed for the technically disinclined

I gather from all the discussion above that a technical solution is underway to stop the templates from displaying dates in the ugly "2008-11-15" format. Am I right in understanding that the proposed solution will use "15 November 2008" as a default unless a new parameter is added, allowing for "November 15, 2008"? When will this be applied, and can it please be included in the template documentation? I don't understand all the technical gubbins and don't really want to — I just want to be able to use the templates, and for articles which already use the templates to display dates appropriately. Will the proposed technical solution allow this, and if so, when? —Josiah Rowe (talkcontribs) 11:02, 15 November 2008 (UTC)

The answer to all of your queries is yes. The change should be possible in the next couple of weeks, at which point the documentation will be updated too. Rjwilmsi 11:46, 15 November 2008 (UTC)
Isn't it possible now? Mr Stephen (talk) 12:04, 15 November 2008 (UTC)
Josiah Rowe wants "articles which already use the templates to display dates appropriately." Existing citations, with no revision, would display today's date as 15 November 2008. This is appropriate for some articles, not for others. Many articles will need to be fixed. --Gerry Ashton (talk) 15:27, 15 November 2008 (UTC)
Soonest started, soonest finished. Mr Stephen (talk) 15:36, 15 November 2008 (UTC)

Date autoformatting, redux

The necessary changes to the MediaWiki software and parallel improvements to the date formatting template copied from the Norwegian wikipedia have now been implemented, and the new code is located at Template:Date. This template forms a universal date formatting template that can be used to format all dates in the Gregorian calendar, also accepting dates from other calendars. The alteration demonstrated at {{cite web3}} can now be implemented successfully. This has the following implications:

  • All dates in citation templates that are unformatted will be converted to render in the Gregorian Calendar, using the default style of "day monthname year". Where it is appropriate to do so, an edit to add the parameter |dateformat=mdy to a citation template will change the format of all the dates in that template to render in the other style.
  • All dates in citation templates which are formatted (contain wikilinks for date autoformatting or to year in XXX pages, or any other value which is not a valid date (such as date ranges) will not change, and will continue to render in the user's style preferences. However, these dates are being progressively unlinked, so will eventually come under the 'magic' of the template.
  • All dates which are formatted (wikilinks etc) and use the Julian Calendar (or some other non-Gregorian calendar) will not change. However, these dates should be 'wrapped' in the {{julian date}} template and unformatted, to more clearly distinguish them as not being in the Gregorian calendar
  • All dates which are unformatted and use the Julian Calendar will be rendered as a Gregorian date with the default display of "day monthname year". Dates will render correctly for all years AD, render dates like "2 January 32BC" unformatted, and incorrectly render dates like "2 January -32" as 2 January 2032. This last syntax is an unacceptable date syntax anyway. All dates using the Julian calendar anywhere should wrap the date in the |julian calendar= template for consistency anyway.

These changes can be applied immediately and we can proceed straight away with the task of updating those dates that need to be tweaked as a result of this change. Comments and suggestions would be very helpful, as would input from editors who use Julian dates in the mainspace to update the documentation of {{julian date}} with some useful examples. Happymelon 16:55, 21 November 2008 (UTC)

Great, but should we be using {{cite web3}} or can we still use {{cite web}}and the change will be reflected there. Should we change {{cite web}} to {{cite web3}}with the dateformat set? JodyB talk 17:09, 21 November 2008 (UTC)
We should be using {{cite web}} as it is the true citation template. If consensus agrees, the code at cite web 3 should be copied here. -- AnmaFinotera (talk · contribs) 17:12, 21 November 2008 (UTC)
Indeed, the changes should be applied to {{cite web}}, as the other is just a sandbox. In fact, the pages that use {{cite web3}} (except examples) should be converted to use the main cite web template once the updated code is applied there. Happymelon 17:37, 21 November 2008 (UTC)
My complaint: I wish we could have a solution that didn't involve adding a parameter to every instance of the template in order to specify the date format; ideally, we should just have to add something like {{DATEFORMAT|mdy}} to each page that wants to use a non-default date format and all properly marked dates (e.g. <date>...</date>) in the article would follow automatically. But alas, just like with the MOS:DATE changes that began this, people are in too much of a hurry to do something that they won't wait to get a consensus on just how such a system should work and then write the code to do it right.
My suggestion: Forget the "Gregorian Calendar"/"Julian Calendar" crap. What exactly about displaying the date as "14 October 1582", "October 14, 1582", or "1582-10-14" means "Gregorian" as opposed to "Julian" that it can't be reformatted? If there is ambiguity, it needs to be stated explicitly rather than just left for people to wonder "Why is this date MDY when the rest are DMY?" Anomie 18:41, 21 November 2008 (UTC)
It's more that the underlying parser functions try to be clever with dates: if you specify February 29 in a year that's not a Gregorian leap year, it's converted to March 1. There are valid dates which simply don't exist in the Gregorian calendar, and the template will choke on them! The simplest way to 'protect' Julian dates from such assaults is just to blank them all out: if we wrap them all in one template, then we can (if we want to) modify that template at some point to do something clever with them if we want to. It's all about laying the groundwork to make later changes easier. Same actually goes for this as a whole: I couldn't agree more that the system you propose is infinitely preferable, and maybe at some point we'll get round to writing that. At that point, having all dates on en.wiki wrapped in one template, unformatted, and ready to be rejigged by javascript or whatever, is going to be a blessing from on high, and make the implementation of that system trivial. But as said somewhere above, there's a lot of work to get to that position, so we might as well start ASAP. This template is, although not a complete solution, certainly a step in the right direction. Happymelon 19:00, 21 November 2008 (UTC)
I had forgotten about Feb 29 in 3 of 4 century years; I suspect that would be a common occurrence, since any other date works. Instead of such confusing text above a simple, specific warning should suffice: "Note that the modern leap year rule is applied, so 29 February in most century years in the older Julian calendar will be incorrectly converted to 1 March; see Gregorian Calendar#Timeline for changeover dates in various countries. To avoid this, use {{[whatever]}} for those dates."
As for the rest, I threw some notes into User:Anomie/Date notes if anyone is interested. If everything else gets done, at least I wouldn't have to look too far to find someone who can write code. Anomie 01:35, 22 November 2008 (UTC)

Please rename Julian Date template

Please rename {{Julian date}} because the meaning conflicts with Julian Date. I suggest the name "Julian cal". --Gerry Ashton (talk) 19:14, 21 November 2008 (UTC)

Done, good point. Now at {{Julian calendar}}. Happymelon 12:21, 22 November 2008 (UTC)

Please rewrite!

I cannot understand the first post in the "Date autoformatting, redux" heading. There are two kinds of formatting potentially going on:

  1. Formatting by the date autoformatting mechanism
  2. Formatting by this template

I cannot decipher which is which in that post. --Gerry Ashton (talk) 19:11, 21 November 2008 (UTC)

I have tweaked my explanation to consistently use the term "format" for markup applied to the inputted date by the editor (eg wikilinks, the precise order of the components, and any other details) and "render" for the markup applied by the template to the inputted value (ie how the components of the date are ordered, and whether they are linked). The essential point is that any input that the template doesn't recognise as a valid date string passes straight through the template as if it wasn't there. Only dates that the template think are valid get any sort of processing. This template does not use MediaWiki's date autoformatting mechanism in any way; if the input is a wikilinked date (or the |3=y parameter is set to cause the template to render a linked date) then the final output from the template is then reformatted according to a user's date formatting preferences. But that is entirely separate to the work of this template. Does that make sense? Happymelon 19:12, 22 November 2008 (UTC)

What next?

Is there a central discussion somewhere about making these changes live on {{cite web}}? What needs to be done to make it work. JodyB talk 12:42, 22 November 2008 (UTC)

change interwiki

{{editprotected}} Please change [[de:Vorlage:Cite web]] to [[de:Vorlage:Internetquelle]] (See discussion here - in german language of course...)--Speck-Made (talk) 21:57, 3 December 2008 (UTC)

It can be edited by anyone here. Request disabled. Cheers. --MZMcBride (talk) 01:59, 4 December 2008 (UTC)

When is the date display going to be fixed?

I brought this up at WP:AN ages ago and was referred to a discussion elsewhere where I was told that the bug was known about and would be fixed soon.

Questions is, when is the bug going to be fixed so that when you enter accessdate=2008-12-05 it displays as Retrieved on 5 December, 2008 in the reference? Mjroots (talk) 14:39, 5 December 2008 (UTC)

Consistency with other Citation templates

Hi all,

Recent work has resulted in Cite journal, Cite book, and Citation using the same 'engine' template to produce their output, Template:Citation/core. This means that the three templates all produce a consistent output, and future edits will maintain this consistency, as only the 'engine' template needs editing. The consensus, as I read it, is that the output of all "Cite xxx" templates should be formatted in a consistent fashion, unless there is a strong reason to the contrary. I've put together a draft of Cite web that will also use this centralised "core" template, and wanted to detail the minor changes that this will produce affecting the template. If there is any opposition to these changes, I would appreciate it if the compelling reasons behind it could be laid out under the appropriate heading below. I've kept the template's output as unchanged as possible without invoking technically complex hacks. Please note that aesthetic concerns are insubstantial; there should be a solid editorial reason for opposing any changes. Also be aware that changes to source code of multiple pages are easily performed by bot if necessary.

Some test cases have appeared at Template:Cite web/testcases for your inspection, and if there are any errors or inconsistencies I have overlooked, please mention these below too. Thanks,

Martin (Smith609 – Talk) 20:24, 7 December 2008 (UTC)

Looking at your testcases page, I'm probably misunderstanding, but will your version get rid of the "Retrieved on..." part? Also, maybe it requires to much of a hack, but the "You must specify title= when using..." part looks funny with the two opening curly brackets included in the hyperlink. - Peregrine Fisher (talk) (contribs) 20:45, 7 December 2008 (UTC)
That's funny, the Retrieved on... was working a moment ago... I'll see what I've done. The latter issue I also thought I'd fixed; that's neater now. Martin (Smith609 – Talk) 20:57, 7 December 2008 (UTC) Fixed Martin (Smith609 – Talk) 21:01, 7 December 2008 (UTC)
The "Omitting the title in error" test case is displayed quite differently as well, and I expect that also means that is isn't being categorized as a citation-error either. The rest of the points you've identified seem trivial and acceptable to me. RossPatterson (talk) 23:42, 7 December 2008 (UTC)
 Fixed I hadn't thought of that; it does now categorise citation errors. Martin (Smith609 – Talk) 04:35, 8 December 2008 (UTC)
Hmm, on second thought, this isn't a proper comparison. You're not using the real {{Citation/core}} for these test cases, but instead a modified version at {{Citation/core/web}}. Changes to {{Citation/core}} impact other citation templates, and yours haven't been proposed at Template talk:Citation yet. Also, if the changes I was asked to make to {{Citation}} and {{Citation/core}} in support of archive copies are installed, the changes you've made for the |Archive= parameter will need reconsideration (and simplification, I think). RossPatterson (talk) 00:04, 8 December 2008 (UTC)
The copying of citation/core/web to citation/core will have no impact on the other templates which use citation/core. (But see our crossed wires at Template:Citation.) The way I've installed the archiveURL parameter is deliberate, as I think it will make integration with {Cite news} easier when the time comes. Martin (Smith609 – Talk) 04:35, 8 December 2008 (UTC)

I see you missed a few differences:

  • accessdates are forced to DMY format, regardless of the date format used in the article. This change was recently rejected, see Template talk:Cite web#Arbitrary date format change above. I'm hopeful that the current RFC at MOS:DATE will give us some way to not have to add a "date format" parameter to every use of every date-handling template, including this one...
    • I'm not sure that accessdates are forced to DMY format. Can you provide examples? Martin (Smith609 – Talk)
      • Current: "Example". Retrieved 2008-12-08.
        Proposed: "Example". Retrieved 2008-12-08.
        Current: "Example". Retrieved December 8, 2008.
        Proposed: "Example". Retrieved December 8, 2008.
        Anomie 05:15, 8 December 2008 (UTC)
  • "Pages" is moved after the publisher and publication date. IMO, it's better to have the page number next to the url/title, format, language, and such, as it goes with the source itself rather than the publisher.
    • Created section for discussion below. Martin (Smith609 – Talk) 04:30, 8 December 2008 (UTC)

Anomie 00:17, 8 December 2008 (UTC)

Linking of quotation marks enclosing title

Current template ({{cite web}})
[url "title"]. {{cite web}}: Check |url= value (help)
Sandbox template ({{cite web/citation}})
[url "title"]. {{cite web}}: Check |url= value (help)
Citation ({{citation}})
"title", [url url] {{citation}}: Check |url= value (help); Missing or empty |title= (help)
Synopsis
Quotes now included in the link
Solution
This is consistent with citation and looks neater (the external link symbol appears after the speech marks, avoiding fragmentation). I don't see it as a problem.
Discussion
If you have any strong reasons to maintain inconsistency across templates, please list them here.
  • Your synopsis is wrong. It's not "Brackets removed", it's "Quotes now included in the link". Anomie 00:17, 8 December 2008 (UTC)
    • Sorry, my mistake. I've corrected it. Martin (Smith609 – Talk) 04:08, 8 December 2008 (UTC)

Order of 'format' and 'language' notes, and doi and archive data

Current template ({{cite web}})
[ArchiveURL "title"] (in French). doi:doi. Archived from [url the original] (format) on archivedate. {{cite web}}: Check |archiveurl= value (help); Check |doi= value (help); Check |url= value (help); Check date values in: |archivedate= (help)
Sandbox template ({{cite web/citation}})
[ArchiveURL "title"] (in French). doi:doi. Archived from [url the original] (format) on archivedate. {{cite web}}: Check |archiveurl= value (help); Check |doi= value (help); Check |url= value (help); Check date values in: |archivedate= (help); Cite has empty unknown parameter: |1= (help)
Citation ({{citation}})
[ArchiveURL title] (in French), doi:doi, archived from [url the original] (format) on archivedate {{citation}}: Check |archiveurl= value (help); Check |doi= value (help); Check |url= value (help); Check date values in: |archivedate= (help)
Synopsis
Order switched
Solution
Discussion at Template talk:Cite journal some time ago agreed that the new order of language and format was preferable. DOI and archive data are unlikely to co-occur, as DOIs are permanent links to original documents.
Discussion
If you have any strong reasons to maintain inconsistency across templates, or problems with DOI/archive order, please list them here.

Location of 'pages' parameter

Current template ({{cite web}})
[url "title"]. publisher. pp. PAGES. {{cite web}}: Check |url= value (help)
Sandbox template ({{cite web/citation}})
[url "title"]. publisher. pp. PAGES. {{cite web}}: Check |url= value (help)
Citation ({{citation}})
[url title], publisher, pp. PAGES {{citation}}: Check |url= value (help)
Synopsis
Pages parameter relocated (please improve examples above to highlight problem)
Issues
Proposed location of pages parameter is consistent with other templates.
Solution
Either make all citation templates locate the pages number before the publisher, or make a special case for cite web (introducing inconsistency)
Discussion
Presumably there are good reasons for the order used by other citation templates which could apply to cite web. I don't think that treating cite web differently is a good idea; modifying other templates will require consensus at their talk pages. If a strong case can be made for changing these pages, it should be made below, then advertised on the talk pages of other templates using citation/core. Martin (Smith609 – Talk) 04:30, 8 December 2008 (UTC)
  • Examples fixed as requested. IMO, it makes more sense to say "source page 42 by publisher" than "source by publisher page 42", but the truth is I don't care so much. BTW, why doesn't your proposed version add the "pp" if you're going for such consistency? Anomie 05:15, 8 December 2008 (UTC)
    Thanks for providing the examples. I always thought that pp stands for "printed pages", so it doesn't really apply to web sources. I also wanted to minimise the changes I made to the output to minimise uproar! Martin (Smith609 – Talk) 05:18, 8 December 2008 (UTC)
    I always thought "pp." just stood for "pages", where "p." stood for "page". I could easily be wrong on that though. Anomie 05:35, 8 December 2008 (UTC)
I think you're right; Acronym and initialism#Representing plurals and possessives and Template:Cite book/doc seem to agree, too. Michael Bednarek (talk) 07:12, 8 December 2008 (UTC)

Publication date parentheses

Current template ({{cite web}})
[url "title"]. Date. {{cite web}}: Check |url= value (help); Check date values in: |date= (help)
Sandbox template ({{cite web/citation}})
[url "title"]. Date. {{cite web}}: Check |url= value (help); Check date values in: |date= (help)
Citation ({{citation}})
[url title], Date {{citation}}: Check |url= value (help); Check date values in: |date= (help); Text "publisher" ignored (help)
Synopsis
Brackets removed
Solution
This is consistent with other templates; I don't see it as a problem
Discussion
If you have any strong reasons to maintain inconsistency across templates, please list them here.
  • So now if there is an author specified the publication date is displayed in parentheses, but if there is no author specified it is displayed not in parentheses? How inconsistent, the old way makes more sense. Anomie 00:17, 8 December 2008 (UTC)
    • Interesting point. This inconsistency is because when citing journals and books, it's conventional to quote Author (year), so this isn't really up for negotiation. Without an author the (year) Title layout looks funny. So do we want web sources to be formatted differently from paper sources? Or should they only have the year in brackets when there is an author who wrote it in that year? Now I think about it, are there any instances when the year is meaningful without an author? Can you give some examples?
    • Martin (Smith609 – Talk) 04:16, 8 December 2008 (UTC)
    • Hang on a moment, the new template doesn't change anything here.
    • Old template: author (2000). [http:// "title"]. {{cite web}}: |author= has generic name (help); Check |url= value (help)
    • New template: author (2000). [http:// "title"]. {{cite web}}: |author= has generic name (help); Check |url= value (help)
    • Old template: [http:// "title"]. 2000. {{cite web}}: Check |url= value (help)
    • New template: [http:// "title"]. 2000. {{cite web}}: Check |url= value (help)
    • Martin (Smith609 – Talk) 04:20, 8 December 2008 (UTC)
      • Sure it does:
        Old template: "[http:// title]" (2000).
        New template: [http:// "title"]. 2000.
        I agree it looks odd to have "(year) title" with no author. The inconsistency is in "author (year)" versus "publisher. year." in your new version. Anomie 05:15, 8 December 2008 (UTC)
        • Oh, I see. I guess there is a case for the retention of parentheses. I'll code that in when I next have the time to test it, and when I am in a frame of mind where I notice inconsistencies without someone highlighting them in red for me... Martin (Smith609 – Talk) 05:22, 8 December 2008 (UTC)
          • I hope I didn't offend you with the red highlight (should I have used blue? ;) Anomie 05:35, 8 December 2008 (UTC)
            • Oh, no offence taken! I was more worried about offending you with my ignorance! Martin (Smith609 – Talk) 13:31, 8 December 2008 (UTC)

accessdate format

Code
{{cite web |title=title|url=url|publisher =| accessdate = 2008-01-01|dateformat=none (/ymd[default]/dmy/mdy}}
Current template ({{cite web}})
[url "title"]. Retrieved 2008-01-01. {{cite web}}: Check |url= value (help)
Sandbox template ({{cite web/citation}})
[url "title"]. Retrieved 2008-01-01. {{cite web}}: Check |url= value (help); Unknown parameter |dateformat= ignored (help)
Synopsis
Date format defaults to dd-mm-yyyy dd-mmm-yyyy - e.g. 1 January 2008
Solutions
  1. Creation of 'dateformat' parameter where alternative format is required.
  2. No autoformatting
Discussion
A 'dateformat' parameter has the advantage that references will be internally consistent by default (and consistent with the format used in cite book and cite journal). It also makes it easier to see at a glance that date formatting is consistent. It can be set to 'none' to remove date formatting. However there may be a problem with backwards-compatability. A bot could go round adding the appropriate dateformat parameter if necessary. Martin (Smith609 – Talk) 14:31, 12 December 2008 (UTC)
  • I hope the current RFC results in a consensus for a replacement date formatting that allows a magic word to set the format used per article (whether it also supports user preferences or not doesn't matter). That would be vastly superior to requiring all uses of all date-handling templates to include an additional parameter. Anomie 17:33, 12 December 2008 (UTC)
You may need to reach for that red highlighter again, but I think this is the only outstanding issue. I'd like to proceed with this edit over the weekend, while I have time to ensure that it goes smoothly. I'd advocate leaving autoformatting for now, so as to be consistent with all other citation templates, and allowing tweaking when the RFC discussion blows over - it'll be easy to implement anything that they decide. I'd also be happy to code in an exception so that the template doesn't modify the date format. Let me know which you'd prefer, and unless you have any other outstanding objections, and I'll propose an edit!
Thanks, Martin (Smith609 – Talk) 04:37, 13 December 2008 (UTC)
Smith609, it isn't clear to me what change you intend to make. No example in this section shows autoformatting; what's that about. Also, the statement "Date format defaults to dd-mm-yyyy" better not be true; If I wrote last Tuesday's date as 9-12-2008, most Americans would think I meant 12 September 2008. --Gerry Ashton (talk) 14:38, 13 December 2008 (UTC)
Sorry, this thread resulted from a discussion above where Anomie noted that the new template code automatically produces a dd-mmm-yyyy format (e.g. 9 September 2008). This formatting is consistent with that produced automatically by other citation templates. Martin (Smith609 – Talk) 16:32, 13 December 2008 (UTC)


Edit request

{{editprotected}} I have developed a solution whereby the date formatting is no different from the current template. This leaves no outstanding objection to the implementation of the new template.

Therefore please copy Cite web/citation to Template:Cite web. Thanks, Martin (Smith609 – Talk) 16:56, 13 December 2008 (UTC)

Done--Aervanath lives in the Orphanage 21:22, 24 December 2008 (UTC)

'with current date'

Although I may not be familiar with wiki template syntax, may I respectfully suggest to those who can edit this template that it is no longer the 9th of December 2008? Cynical (talk) 20:16, 11 December 2008 (UTC)

Everything looks fine on my side...doubt this is a template issue. Try purging your cache (F5 on many browsers) and see if that refreshes things. Huntster (t@c) 20:23, 11 December 2008 (UTC)
This is a documentation issue, not a template issue. The documentation is available for all to edit. Huntster is correct though, the current date is displayed with magic words. If you see the wrong date, it's almost certainly a cache issue. Pagrashtak 20:45, 11 December 2008 (UTC)

accessdate/Retrieved on

The use of "Retrieved on" has puzzled me for a long time. It has a suggestion that a snapshot of the referenced page was taken on the date specified and that the link will take you to some wayback machine type archived view of the page. Upon viewing the template, I see that the parameter is "accessdate". Why not use that: "Accessed on" or "Information gathered on" but NOT "Retrieved on" which is just plain misleading. -- SGBailey (talk) 06:52, 21 December 2008 (UTC)

That's kind of true. It would be a big change, though. - Peregrine Fisher (talk) (contribs) 08:21, 21 December 2008 (UTC)
I assume he means just changing the template itself to say "accessed on April 1 2008" rather than "retrieved on April 1 2008", which would actually be a very minimal change. I don't really have a strong view on whether or not it's a good idea. Happymelon 15:54, 21 December 2008 (UTC)
Since it hasn't been mentioned—this would need to be changed in all cite templates that use the accessdate parameter. You'll need to post notices on a few template talk pages. As more templates start using {{Citation/core}} I suspect this will become easier. Pagrashtak 07:14, 22 December 2008 (UTC)
I believe that we are using the APA style and that uses Retrieved. For a variety of styles, you can have a look at Wikisource cite. The place for the citation preference discussion is Wikipedia:Citing sources. -- billinghurst (talk) 08:26, 22 December 2008 (UTC)
That's interesting. The APA "Retrieved on" makes sense in an actual paper, which just lists a URL that you can't click. It's stranger here, where we hide the URL under a clickable title. - Peregrine Fisher (talk) (contribs) 22:15, 24 December 2008 (UTC)

URL hyperlink not displaying

Hi. Suddenly, at least in my browser (Safari), {{cite web}} hyperlinks no longer seem to display. For example in my browser, I do not see the hyperlink:

produced by:

  • {{cite web | url = http://www1.astrazeneca-us.com/pi/casodex.pdf/ | format = PDF | title = Casodex product insert | author = | authorlink = | coauthors = | date = 2006-03-01 | format = | work = | publisher = www1.astrazeneca-us.com | pages = | language = | archiveurl = | archivedate = | quote = | accessdate = 2008-12-27}}

This used to work, but several days ago it stopped working. Has anyone else noticed this behavior? Cheers. Boghog2 (talk) 21:47, 27 December 2008 (UTC)

Also in FF3. Will investigate... Any ideas when this started? Happymelon 21:50, 27 December 2008 (UTC)
Fixed, but this highlights a whole new set of problems. The template code wants to accomodate every man and his dog when it comes to alternative parameter names. It's just not feasible to do so when there are so many of them. Pick one syntax, hunt down and eliminate the rest, and then remove them from the template code. Otherwise we have to use a mass of #if: statements to choose between them, becuase we can't use parameter defaults as you've just realised. Happymelon 10:49, 28 December 2008 (UTC)
Done Much better. Thanks for your quick response. I apologize if I have opened a can of worms. Boghog2 (talk) 22:04, 27 December 2008 (UTC)

Hungarian interwiki

Could you please add hu:Sablon:Cite web to the article. Thanks Karmela (talk) 00:16, 29 December 2008 (UTC)

 Done, but remember you can add interwiki links to almost any template which uses {{documentation}}. The /doc subpages are almost never protected. Huntster (t@c) 00:42, 29 December 2008 (UTC)

accessdaymonth, accessmonthday, accessyear broken?

The parameters accessdaymonth, accessmonthday, and accessyear seem to no longer work.

This code:

  • {{cite web | title = Test page | url = http://www.testpage.co.org/ | date = 12 March 2008 | accessdaymonth = 28 December | accessyear = 2008 }}

should produce this:

  • "Test page". 12 March 2008. Retrieved on 28 December 2008.

but is currently producing this:

  • "Test page". 12 March 2008.
  • "Test page". 12 March 2008. {{cite web}}: Unknown parameter |accessdaymonth= ignored (help); Unknown parameter |accessyear= ignored (|access-date= suggested) (help)

Was there any discussion before the removal of these parameters, or was this an oversight? When can this be fixed? — Bellhalla (talk) 03:32, 29 December 2008 (UTC)

{{editprotected}}

Please revert the template to the 9 November 2008 version. The changes made on 24 December 2008 have broken the alternative accessdate parameters above, leaving many instances of this template without a valid retrieval date. — Bellhalla (talk) 14:07, 29 December 2008 (UTC)

Not done:, but I have  Fixed the template instead. Happymelon 14:06, 30 December 2008 (UTC)
Thanks for getting the retrieval dates back, but why the change in format? Now the the template generates a series of items separated by commas, rather than full stops as was previously the case and is the case with {{cite book}} and {{cite news}}Bellhalla (talk) 16:05, 30 December 2008 (UTC)
That change was per the discussion above, not something I've had any involvement with. Happymelon 16:20, 30 December 2008 (UTC)
Actually, no. The change from periods to commas was because you removed the part setting Sep completely instead of changing "|Sep = {{{separator|{{{seperator|.}}}}}}" to "|Sep = .". Anomie 18:24, 30 December 2008 (UTC)

Consolidating parameters

As I said above, this template currently incorporates a large number of alternative parameter names for the same value. This is, not to put too fine a point on it, untenable. We need to settle on one allowed name for each parameter and stop supporting the others. Note that I'm not talking about things such as |author= vs |first= and |last=, but things like |first= vs |given=; two parameters that do exactly the same thing but are just synonyms. There is no reason to support things like these. The list of duplicated parameters are below: a lot of them have been very recently introduced and IMO should be just as quickly removed before they gain any popularity:

  • |Surname1 = {{{last|{{{surname|{{{last1|{{{surname1|{{{author1|{{{author|{{{authors|{{{author|}}}}}}}}}}}}}}}}}}}}}}}}
  • |Surname2 = {{{last2|{{{surname2|{{{author2|{{{coauthor|{{{coauthors|}}}}}}}}}}}}}}}
  • |Surname3 = {{{last3|{{{surname3|{{{author3|}}}}}}}}}
  • |Surname4 = {{{last4|{{{surname4|{{{author4|}}}}}}}}}
  • |Surname5 = {{{last5|{{{surname5|{{{author5|}}}}}}}}}
  • |Surname6 = {{{last6|{{{surname6|{{{author6|}}}}}}}}}
  • |Surname7 = {{{last7|{{{surname7|{{{author7|}}}}}}}}}
  • |Surname8 = {{{last8|{{{surname8|{{{author8|}}}}}}}}}
  • |Surname9 = {{{last9|{{{surname9|{{{author9|}}}}}}}}}
  • |Given1 = {{{first1|{{{given1|{{{first|{{{given|}}}}}}}}}}}}
  • |Given2 = {{{first2|{{{given2|}}}}}}
  • |Given3 = {{{first3|{{{given3|}}}}}}
  • |Given4 = {{{first4|{{{given4|}}}}}}
  • |Given5 = {{{first5|{{{given5|}}}}}}
  • |Given6 = {{{first6|{{{given6|}}}}}}
  • |Given7 = {{{first7|{{{given7|}}}}}}
  • |Given8 = {{{first8|{{{given8|}}}}}}
  • |Given9 = {{{first9|{{{given9|}}}}}}
  • |Authorlink1 = {{{author-link|{{{author1-link|{{{authorlink|{{{authorlink1|}}}}}}}}}}}}
  • |Authorlink2 = {{{author2-link|{{{authorlink2|}}}}}}
  • |Authorlink3 = {{{author3-link|{{{authorlink3|}}}}}}
  • |Authorlink4 = {{{author4-link|{{{authorlink4|}}}}}}
  • |Authorlink5 = {{{author5-link|{{{authorlink5|}}}}}}
  • |Authorlink6 = {{{author6-link|{{{authorlink6|}}}}}}
  • |Authorlink7 = {{{author7-link|{{{authorlink7|}}}}}}
  • |Authorlink8 = {{{author8-link|{{{authorlink8|}}}}}}
  • |Authorlink9 = {{{author9-link|{{{authorlink9|}}}}}}
  • {{{date|}}}{{{publication-date|einval}}}
  • {{{journal|{{{periodical|{{{newspaper|{{{magazine|}}}}}}}}}}}}
  • {{{pages|{{{page|{{{at|}}}}}}}}}
  • {{{title|{{{contribution|}}}}}}
  • |Place = {{{place|{{{location|}}}}}}
  • |PublicationPlace = {{{publication-place|{{{place|{{{location|}}}}}}}}}
  • |language = {{{language|{{{in|}}}}}}
  • |AccessDate={{#if:{{{access-date|}}}|{{{accessdate|}}}|{{{accessdate|}}} }}
  • |Sep = {{{separator|{{{seperator|.}}}}}}

As you can see there are a lot of them, most of which have been unilaterally imported from Citation/core without considering whether they are useful to cite web. Most of them, I believe, are not. Which ones should be retained and which ones removed? Happymelon 11:30, 29 December 2008 (UTC)

Well {{{journal|{{{periodical|{{{newspaper|{{{magazine|}}}}}}}}}}}} can come out LS&B for a start. Are the nonstandard accessdate, Place, and PublicationPlace used anywhere, or are they cruft? Mr Stephen (talk)
accessdate is, I think, what comes out as "retrieved on XYZ", so that's useful. Unless they want us to find out where the site's servers are based, I can't think of any possible use for the other two. Happymelon 12:36, 29 December 2008 (UTC)
I see they are internal variables, rather than supported parameters, so skip my comment about accessdate etc. Mr Stephen (talk) 14:40, 29 December 2008 (UTC)
I've removed essentially all the parameters that were not present before the conversion to the meta-template; which pretty much resolves the problems. Happymelon 14:12, 30 December 2008 (UTC)
You also removed coauthors, doilabel, and editor that were present before the conversion. Also, FWIW, you left in author[2-9], authorlink[2-9], dateformat, day, first[2-9], and last[2-9]. Anomie 18:32, 30 December 2008 (UTC)
You've not outlined what damage these extra parameters cause. The benefit is that giving editors a range of parameters makes the template easier to use, and most of these 'surplus' parameters are common to other citation templates. Removing parameters without thorough testing does seem a bit premature, especially as many are already present in articles. Martin (Smith609 – Talk) 20:10, 3 January 2009 (UTC)

Coauthors?

I don't know what changes were made recently, but the coauthors tag seems to have been broken in the process?! -- Avi (talk) 16:39, 30 December 2008 (UTC)

Happy-melon removed it in this series of edits, probably because he didn't realize it wasn't one of the many "extra" parameters added in the recent edits to this template. Anomie 18:27, 30 December 2008 (UTC)

Restored to 12/27

I've restored the template to the 12/27 version, that should fix the issues, and then any pruning should be done very carefully in the future. -- Avi (talk) 18:48, 30 December 2008 (UTC)

Date parameter

There used to be brackets around the date in cite web Google cached from 21 Dec. They have now gone. Why? I see no consensus for this change. Can it be changed back please, Rambo's Revenge (talk) 20:15, 30 December 2008 (UTC)

Consensus was obtained here, with the argument being that cite web's output should be consistent with Wikipedia's other citation templates. Martin (Smith609 – Talk) 20:19, 3 January 2009 (UTC)

Reversion

{{editprotected}} Please revert this template to the stable 9 November version. Then you guys can play around with the template sandbox and testcases page before implementing the changes. This is a highly transcluded template that shouldn't be ping-pong-ing back and forth, as it is disruptive to many articles. This reversion has once again broken the alternate accessdate parameters accessdaymonth, accessmonthday, and accessyear. — Bellhalla (talk) 20:22, 30 December 2008 (UTC)

Looking at all the recent mess, I support this proposal. Rambo's Revenge (talk) 20:40, 30 December 2008 (UTC)

 Done -- Avi (talk) 20:43, 30 December 2008 (UTC)

Are the accessdate parameters the only things that are broken in the 27th Dec version? Please list any other errors here so I can fix them in one go. Martin 18:41, 3 January 2009 (UTC)
That's all I'm aware of but there may be other issues. May I please repeat the suggestion above of using the sandbox and testcases pages? Thanks in advance. — Bellhalla (talk) 19:23, 3 January 2009 (UTC)
I agree that the sandbox and testcases should be rigorously checked before any edit is enacted. Unfortunately the accessdate parameters slipped through my original testing of the stable 24th Dec version. I've now corrected this and would be grateful if any further editors would be willing to find further problems with the new template. Here are the testcases and here is the sandbox template. Thanks, Martin 19:43, 3 January 2009 (UTC)
The sandbox still contains all the problems highlighted in the #Consolidating parameters and #URL hyperlink not displaying sections above. ‑ 19:46, 3 January 2009 (UTC)
The URL problem is now resolved in the sandbox, and I've reinstated a few of your tweaks along the way. I'm reluctant to prune too many of the standard parameters, as these often end up being useful in rare cases. Can you convince me that they cause any harm worth worrying about? Martin (Smith609 – Talk) 20:15, 3 January 2009 (UTC)
As explained above, using parameter defaults is not acceptable in this situation. So all constructs like {{{last2|{{{surname2|{{{author2|{{{coauthor|{{{coauthors|}}}}}}}}}}}}}}} need to be replaced by a construct like {{#if:{{{last2|}}}|{{{last2}}}|{{#if:{{{surname2|}}}|{{{surname2}}}|{{#if:{{{author2|}}}|{{{author2}}}|{{#if:{{{coauthor|}}}|{{{coauthor}}}|{{{coauthors|}}} }}}}}}}}, an incredibly inefficient and messy parser construct that will introduce a huge increase in ParserFunction counts for absolutely no benefit whatsoever. Why do we need five alternative syntaxes for saying the same thing? Find the original parameter names that were used to define these values (ie what the templates 'in the wild' are actually using), and remove the unused and unnecessary alternatives. Happymelon 10:39, 8 January 2009 (UTC)
Why is accessdate still broken after so many weeks? If there's no consensus for changing the formatting, simply revert back the formatting that worked before instead of breaking it. Madcoverboy (talk) 15:49, 7 January 2009 (UTC)

{{editprotected}}

I've removed redundant parameters (= those not documented in the documentation) from the current sandbox to address HappyMelon's concerns. The constructs Happymelon suggested are used where necessary; in some cases they aren't (because they are effectively employed in the citation/core template instead). I've put a couple of Template:Cite web/testcases testcases up with blank parameters and they work fine. As no other bugs have been spotted, I suggest that we go live with the current sandbox by copying it to Template:Cite web. Thanks, Martin (Smith609 – Talk) 23:31, 10 January 2009 (UTC)
Looking at test cases, the last parameter doesn't appear functional. Disabling the edit request for now while this is sorted out. Pagrashtak 19:16, 14 January 2009 (UTC)
Numerous parameters (Surname1, Surname2, Authorlink1, Year, Place, DOI, At, Sep) still use parameter default constructions. More work needed. Happymelon 19:43, 14 January 2009 (UTC)
Good point. I see that the proposed version would add support for last1 in the Surname1 parameter, for example—why do we need to introduce this if the current version doesn't use it? More questions: Why does the sandbox reference {{Citation/core/sandbox}} instead of {{Citation/core}}? Would it be possible to give us a list of what parameters would be added/removed with this change? For example, last1, last2, last3, etc. are being added, while editor is being removed. Pagrashtak 20:13, 14 January 2009 (UTC)
Happymelon, the proposed version uses parameter default constructions in a perfectly adequate and functional way. Please give an example of how this could cause a problem. Pagra, I'm probably being blind, but I couldn't see where the |last= parameter didn't work. Could you give an example? The sandbox links to the sandbox citation core because it's a sandbox version of the template. Parameters are detailed below. Martin (Smith609 – Talk) 23:51, 19 January 2009 (UTC)
  • Editor: There is currently no editor parameter documented, which makes sense because I have never seen a web page which cites an editor. Therefore by HappyMelon's logic I didn't add a parameter which was unused.
  • Last1/last2/etc. : The 'last' parameter only works for web pages with a single author. It seems logical to extend it.

{{editprotected}}

The queries above seem to have been addressed, all Cite web/testcases are working, and I cannot produce an example where the new template will cause incorrect output. I'd be grateful if an admin would replace Template:Cite web with the current sandbox. When copying the code, please remove '/sandbox' from the first line of the template. Thanks, Martin (Smith609 – Talk) 14:59, 23 January 2009 (UTC)
Is there a reason you didn't remove it now? Pagrashtak 15:33, 23 January 2009 (UTC)
Edit request disabled, the test cases are not working as you say. Smith, I appreciate the work you do with these templates, but you need to slow down—you tend to rush and let things fall through the cracks. Pagrashtak 15:38, 23 January 2009 (UTC)
Pagra, it would be very helpful indeed if you were to let me know which test cases aren't working, and what the problem is. I've looked again and still can't see the problems you're alluding to. Could you please be specific? Martin (Smith609 – Talk) 23:39, 23 January 2009 (UTC)
Actually, I didn't mention the specific problem because I wanted you to take a look at all the test cases instead of focusing on the parameter I had in mind. It appears this wasn't enough to draw attention to it, so I'll be more specific below. Pagrashtak 22:37, 25 January 2009 (UTC)

Indeed. In fact, there has been no attempt to address my concern:

  |Surname1 = {{{last|{{{last1|{{{author|}}}}}}}}}
  |Surname2 = {{{last2|{{{coauthors|}}}}}}

That's a parameter default.

  |Authorlink1 = {{{authorlink|{{{authorlink1|}}}}}}

So is that.

  |Year={{{year|{{    <!-- attempt to derive year from date, if possible -->
             #if: {{{date|}}}
             |{{
                #iferror:{{#time:Y|{{{date|}}} }}
                |{{#iferror:{{#time:Y|{{{publication-date|einval}}} }}||{{#time:Y|{{{publication-date|}}} }}}}
                |{{#time:Y|{{{date|}}} }}
              }}
             |{{{publication-date|}}} <!-- last resort -->
           }}
        }}}

This is a particularly nasty one: all that carefully-constructed parser coding will be totally ignored if someone calls the template like {{cite web|url=http://www.example.org|date=January 23 2008|year=|month=|day=|...}}. How many times do I have to say it? You Can Not Do That. Pick one parameter to pass in each situation (either by only accepting one parameter in the first place, or by fiddling through them with parserfunctions) and pass only that parameter. Why do you continue to insist on using numerous different synonyms for the same thing? Happymelon 16:18, 23 January 2009 (UTC)

Hi, the example you cited seems to work to me:
  • {{cite web/sandbox|url=http://www.example.org|date=January 23 2008|year=|month=|day=||title=title...}}
  • "title..." January 23 2008. {{cite web}}: Check date values in: |date= (help); Cite has empty unknown parameter: |1= (help)
  • {{cite web/sandbox|url=http://www.example.org|date=|year=2008|month=January|day=23|title=title...}}
  • "title..." 23 January 2008.
It's much more useful if you can give examples of where the parameter defaults don't work, rather than just stating that they don't. You may want to look at Template:Cite journal, Template:Cite book and Template:Citation, which all employ parameter defaults without a problem. Martin (Smith609 – Talk) 23:39, 23 January 2009 (UTC)
You're right, thanks to the way the /core template handles the date input. This will still fail though:
{{cite web|url=foo|title=title...|year=|month=|day=|publication-date=January 24 2009}}
"title..." January 24 2009. {{cite web}}: Check date values in: |publication-date= (help)
Now consider the plausible situation of someone wanting to split a list of coauthors from the |coauthors= parameter to a list of |last#= parameters:
{{cite web|last=Smith|first=John|url=http://www.foo.com|title=title...|coauthors=Jane Smith, Fred Bloggs, George Bush}}
{{cite web|last=|url=http://www.foo.com|title=title... |last1=Smith|first1=John|last2=Smith|first2=Jane|first3=Fred|last3=Bloggs|first4=George|last4=Bush}}
Smith, John. "title..." {{cite web}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
Smith, John; Smith, Jane; Bloggs, Fred; Bush, George. "title..."
Bang, there goes Mr Smith. In fact, what happened to the rest of the authors? Something's not right there. Happymelon 00:23, 24 January 2009 (UTC)
Okay, thanks for the examples. I'll get onto it. Martin (Smith609 – Talk) 01:12, 24 January 2009 (UTC)
I've removed all of the parameter defaults mentioned by HappyMelon, with the exception of misspellings (separator/seperator; doi/DOI), because it's highly unlikely that these will both be present with different values in the same citation. (Someone with a sharper eye than me might want to make sure I've not missed any.) Are there any other things that need to be addressed before we go live? Martin (Smith609 – Talk) 01:24, 25 January 2009 (UTC)
Still not ready—you appear to making DOI a required parameter when it should stay optional and you are removing support for the first parameter. Pagrashtak 22:37, 25 January 2009 (UTC)
 Fixed but not tested. Anything else? Martin (Smith609 – Talk) 03:46, 26 January 2009 (UTC)
That looks much better from my perspective. Thankyou for your patience, Martin. Happymelon 08:42, 26 January 2009 (UTC)
Good. Thank you for checking my code so vigilantly! The test cases are all looking happy, and I don't think there are any outstanding concerns. Would anyone object to me requesting an edit? Martin (Smith609 – Talk) 14:35, 28 January 2009 (UTC)
No need.  Done. Let's see how this version goes down :D Happymelon 22:42, 28 January 2009 (UTC)
You broke support for accessmonthday/accessdaymonth/accessyear. Pagrashtak 15:04, 29 January 2009 (UTC)
What is the background behind these parameters? They seem rather redundant to me. Happymelon 16:20, 29 January 2009 (UTC)
When it was more-or-less mandatory to specify accessdate in YYYY-MM-DD format and the accessdate was automatically linked, the accessmonthday (or accessdaymonth) and accessyear provided a way to provide a spelled-out date of access. During the time these parameters were available, they were added to some unknown number of articles; to remove them now will break citations that were made in good faith. --Gerry Ashton (talk) 17:53, 29 January 2009 (UTC)
Seems like this category Happy-Melon just added will tell us in the near future which articles use the deprecated accessmonthday/accessdaymonth/accessyear fields. After that it's just a matter of going through the articles in that category and moving the values of those fields into the accessdate field. Depending on how many there ends up being, I wouldn't think it would take that long to do, even if we were to do it manually. It only took me half a minute or so to replace the field on 2008-2009 Canadian parliamentary dispute.[5] --Bobblehead (rants) 20:58, 29 January 2009 (UTC)
This could be done with a bot. Is it reasonable to conclude that a page which uses |accessmonthday= and |accessyear= should display dates in the "mdy" format, and equivalently for |accessdaymonth=? If so, the bot could combine the accessdate parameters into |accessdate=, combine the |day=, |month= |year= parameters into |date=, and set the appropriate |dateformat= to display them both correctly. If there's over a threshold number of cites using this format on the page, perhaps it should set the dateformat on all citation templates. Happymelon 08:47, 30 January 2009 (UTC)
That seems reasonable. Can a bot be programmed to count the different date formats and go with the majority? --Gerry Ashton (talk) 20:54, 30 January 2009 (UTC)

Date format

I've noticed that the "date" section does not automatically turn 2009-01-03 into January 3, 2009. The "accessdate" does do this, but not the basic "date" (for publication date). I'd fix this if I knew how, but I think it needs to be done to be consistent with the other dating styles that are present.  BIGNOLE  (Contact me) 13:34, 3 January 2009 (UTC)

Neither date nor accessdate currently changes the format of the date entered: "Example". 2008-01-01. Retrieved 2008-02-02. For a short time recently, attempted cleanup by Happy-Melon had broken things to force DMY ordering, but that has been reverted now.
At the moment, we have no acceptable way to do so, as forcing either DMY or MDY format for all uses would conflict with the date format used in the prose of many articles, link-based date formatting has been rejected by the community, any non-link-based replacement is still trying to gain consensus (see WT:MOSNUM), and forcing every use of the template to supply a "dateformat" parameter would be decidedly sub-optimal. Anomie 16:05, 3 January 2009 (UTC)
Wasn't me guv! I was just trying to fix someone else's broken code, although I admit I did make things worse... Happymelon 16:43, 3 January 2009 (UTC)
Putting it all in "long-hand" format is excessive waste of coding space for the article when we can automatically make it change to that style in the template. Otherwise, we now have hundreds (probably thousands) of articles that have never been adjusted since the date linking issue first came up and was removed. Thus, all those article's references that use the template read, "YYYY-MM-DD"...which is kind of hard to read on the fly, and looks grotesque on the screen.  BIGNOLE  (Contact me) 17:45, 8 January 2009 (UTC)

Unilateral removal of YYYY-mm-dd

This went unnoticed (at by myself) until I was challenged on why I was using YYYY-mm-dd dates in cite templates. From hunting, I notice that this undiscussed edit[6] from 2008-11 removed all of the previous examples and explicit advice to use YYYY-mm-dd. The editor in question appears to have made no previous contributions to this template or its documentation before, nor further edits immediately after this point. As far as I can tell, it appears to have been done unilaterally.

Could this please be reverted so that we don't end up with a complete mess of non-machine-parsable dates in the references section. {{cite/doc}} is still very explicit about the use of YYYY-mm-dd dates in connection with cite templates. —Sladen (talk) 18:09, 14 January 2009 (UTC)

Agreed, this should be reverted since the template itself still looks for and wants the ISO format. And from all discussions I've read so far, even when the code does go back to fixing the format, it will still prefer ISO. -- AnmaFinotera (talk · contribs) 18:50, 14 January 2009 (UTC)
{{editprotected}}. Okay lets get it fixed then (nb. to admin: this is for /doc). —Sladen (talk) 19:13, 14 January 2009 (UTC)
Disabling editprotected, as Template:Cite web/doc is not a protected page. Pagrashtak 20:27, 14 January 2009 (UTC)
 DoneI tried[7] to merge the obvious changes; however in the mean-time, the examples had also been meddled with, changing them from highly-diffable multi-line format, to massive single-line blocks (which aren't much good as examples anyway!). Please review and add back another further that I missed in the revert cleanup. —Sladen (talk) 03:38, 15 January 2009 (UTC)
I think you've gone a little too far back. There are now references to "Using non-linked retrieved date" examples, which are from the old version of the template when linking was the default. Pagrashtak 17:39, 16 January 2009 (UTC)

Related side question... was the date linking and formatting turfed?

The docs ref that the date should self-generate a link and I could have sworn that the "yyyy-mm-dd" numbers would convert to "Month dd, yyyy" depending on where in the article the template was placed.

- J Greb (talk) 16:41, 17 January 2009 (UTC)

No point linking to vanished pages

When a web site disappears, and a reference is changed to refer to an archived copy elsewhere, there's no point in having the generated code contain a link to the now vanished original web site. For example, at present, input like this:

{{cite web
|title=Example
|url=http://example.org/example.html
|archiveurl=http://web.archive.example/yyyymmddhhmmss/http://example.org/example.html
|archivedate=YYYY-MM-DD
}}

generates output that looks rather like this:

"Example". Archived from the original on YYYY-MM-DD.

That link to "the original" is pointless if the original URL is inaccessible (due to a web site being reorganised, content being deleted, or a company going out of business). I'd like an option to leave the original URL unlinked, for use when the original URL is known to be inaccessible. I suggest an extra input parameter like urlinaccessible=YYYY-MM-DD, to cause the output to look more like this:

"Example". Archived from http://example.org/example.html on YYYY-MM-DD. The original is inaccessible as of YYYY-MM-DD.

AlanBarrett (talk) 19:29, 15 January 2009 (UTC)

What if the original URL comes live again? Or if the archive goes dead? How would this affect the Link Checker tool? --—— Gadget850 (Ed) talk - 20:27, 15 January 2009 (UTC)
If the original URL is rendered in plain text, not as a link, then any link checker tool will ignore it. If the archive goes dead, then somebody will have to find another archive and edit the reference. If the original URL becomes live again, then probably nobody will notice, but I'd suggest that this proposed new feature be used only where the original URL is expected to remain dead. In the case that triggered my suggestion, it seems clear that the original URL won't come back (the domain name has been abandoned by the original publisher and is now an advertising site), and the Internet Archive seems likely to be stable. —AlanBarrett (talk) 20:57, 15 January 2009 (UTC)
This would cause the citation to be much longer and would likely lead to wrapping problems. Pagrashtak 22:39, 15 January 2009 (UTC)
I'd suggest this is a case of not needing to mess with something that already works fine. Huntster (t@c) 23:39, 15 January 2009 (UTC)
I don't think there should ever be a need to render a url in plaintext except where the article actually discusses such a thing in an encyclopedic context. If a link doesn't work, we should remove it. I'm not sure how the template currently functions with respect to the |archiveurl= parameter being specified but not |url=; if it's an acceptable output then it should be the approved practice; if not then the template should be adjusted to allow it. If it is abundantly clear that the link is not ever coming back, then the url should be removed altogether. In more dubious cases, it can just be comented out using HTML comment tags, and thus is still present in the wikitext for users to test and restore if necessary. Happymelon 00:05, 16 January 2009 (UTC)
The template doesn't allow |archiveurl= to be used without |url=. Changing the template to allow that seems like a reasonable solution to this problem. Then the original |url= could be commented out in the wikitext, both to retain it as a kind of documentation, and to instruct the template not to render it. —AlanBarrett (talk) 07:08, 16 January 2009 (UTC)
If we allow that, editors won't just comment it out, they'll remove it completely. Pagrashtak 17:09, 16 January 2009 (UTC)
Given that the link doesn't work, that's not really a serious problem. If a user added a broken link to an article, it would be reverted, no? We're only keeping the link against the faint possibility that it might one day fix itself. Removing it entirely is a perfectly acceptable action. Happymelon 17:55, 17 January 2009 (UTC)
No, that is a problem. We need to know the original source used. Not all broken links would be cause for immediate reversal. Pagrashtak 16:54, 20 January 2009 (UTC)
Why not just use the archiveURL in the |url= field, and not specify a URL? Martin (Smith609 – Talk) 23:03, 19 January 2009 (UTC)
Because you lose semantic clarity that way: it is no longer possible for a bot (or a human for that matter) to know with certainty that the url is going to link to the original page. |url= is for direct link, and |archiveurl= is for archive links. If it's not possible to use one without hte other, we need to fix the template, not change our behaviour to accomodate it. Happymelon 23:17, 19 January 2009 (UTC)

(outdent)I think the current functionality works just fine. Having the original URL (which has been pointed out above could possibly go live again) is important to show the source of the citation and serves as a historical record of where the information came from. Unless the original domain is hijacked by, say, someone spreading viruses or a porn site, I see no harm in retaining the links. — Bellhalla (talk) 16:41, 23 January 2009 (UTC)

I agree with Bellhalla. Mr Stephen (talk) 19:08, 23 January 2009 (UTC)

Work and publisher

I'm confused as to what to use. For example, would this be correct usage of both the work and publisher fields:

{{cite web
|url=http://www.autoblog.com/2008/03/04/geneva-2008-bugatti-veyron-fbg-by-hermes-scepter-and-empire-no/
|title=Geneva 2008: Bugatti Veyron Fbg by Hermes, scepter and empire not included
|last=Ramsey
|first=Jonathon
|date=2008-03-04
|work=autoblog.com
|publisher=Autoblog
|accessdate=2009-01-1 7}</nowiki>} What about something like this: <nowiki>{{cite web
|url=http://www.bugatti.com/en/veyron-16.4/technology/handling.html
|title=Driving the Ideal Line
|accessdate=2007-10-02
|accessmonthday=
|accessdaymonth=
|accessyear=
|author=
|last=
|first=
|authorlink=
|coauthors=
|date=
|year=
|month=
|format=
|work=bugatti.com
|publisher=Bugatti SAS
|pages=
|language=
|doi=
|archiveurl=
|archivedate=
|quote= }}

— Mr. Grim Reaper at 01:53, 24 January 2009 (UTC)

I would think giving the name of the website, when it is obvious, isn't really necessary. It might be more helpful if you were citing a play titled "Henry VIII" on a site named "The Complete Works of Shakespere" but the web address gave no hint of this (say it was http://www.a9263.invalid). --Gerry Ashton (talk) 02:28, 24 January 2009 (UTC)

(EC) No. In the first example, work isn't needed, nor in the second. Work should be used primarily for newspaper and other periodical/publication websites where the name should be italicized, such as here, for a reference using an online magazine called Animefringe. (Online magazines shouldn't use cite journal.):

{{cite web
|url=http://www.animefringe.com/magazine/2003/06/reviews/11/
|title=Tokyo Mew Mew Vol.2
|first=Patrick
|last=King
|work=Animefringe
|year=2003
|month=June
|accessdate=2008-04-18 }}

Publisher on the other hand, is used for general website/company names, such as

{{cite web
|url=http://www.hersheyicecream.com/
|title=Hershey's Ice Cream
|publisher=Hershey Creamery Company
|accessdate=2009-01-07 }}

The url generally shouldn't be in there at all except, of course, in the URL field. Usually you use one or the other, though sometimes you may use both if the company that publishes a periodical is different from the work itself. For example, here are two that use both:

{{cite web
|url=http://www.referenceforbusiness.com/businesses/G-L/Hershey-Foods-Corporation.html
|title=Hershey Foods Corporation
|publisher=[[Advameg]]
|work=Reference for Business
|accessdate=2009-01-07 }}

which gives you:

"Hershey Foods Corporation". Reference for Business. Advameg. Retrieved 2009-01-07.

{{cite web
|url=http://www.msmary.edu/alumni/whats-new/featured-alumni/Holder_Family.html
|title=A Sweet Legacy: For generations, the Holder family has been part of the ice cream business and part of the Mount
|first=Lisa
|last=Gregory
|publisher=Mount St. Mary's University
|work=Mount Magazine
|month=Fall
|year=2008
|accessdate=2008-12-30 }}

generates:

Gregory, Lisa (Fall 2008). "A Sweet Legacy: For generations, the Holder family has been part of the ice cream business and part of the Mount". Mount Magazine. Mount St. Mary's University. Retrieved 2008-12-30.

Hope that helps some? -- AnmaFinotera (talk · contribs) 02:34, 24 ary 2009 (UTC)

Yes indeed. Thank you very much. — Mr. Grim Reaper at 03:00, 26 January 2009 (UTC)
Is there a better name for those fields? I've been putting a newspaper company's name into the publisher field (with apostrophes for the italics) for a long time. - Peregrine Fisher (talk) (contribs) 03:28, 26 January 2009 (UTC)

Check it out. - Peregrine Fisher (talk) (contribs) 01:26, 25 January 2009 (UTC)

accessmonthday SNAFU ...

... I've lost track, is it broken again, broken still, or obsolete? {{cite web |title=My favorite things part II |work=Encyclopedia of things |url=http://www.example.org/ |accessmonthday=July 6 |accessyear=2005 }}

"My favorite things part II". Encyclopedia of things. Retrieved July 6, 2005.

Mr Stephen (talk) 23:05, 28 January 2009 (UTC)

Obsolete IMO, although I'd wait to hear other opinions. Happymelon 08:35, 29 January 2009 (UTC)
I just fixed Scout Moor Wind Farm a "featured article" with this problem. 71.250.136.115 (talk) 13:26, 29 January 2009 (UTC)

{{editprotected}} Please revert the template to this version that recognizes the accessdaymonth and accessmonthday . Some of us have article under review at WP:FAC that use these parameters. This same sort of disruption occurred almost exactly a month ago.

Why do these parameters keep disappearing? Is there some particularly compelling reason for these parameters to not be included in the template? — Bellhalla (talk) 20:40, 30 January 2009 (UTC)

Should be a relatively easy fix, just move the contents of accessdaymonth/accessmonth day and access year into accessdate. You don't need to have the date in ISO format and there isn't any auto-date formatting on cite web anymore. --Bobblehead (rants) 20:56, 30 January 2009 (UTC)
Also, in answer to your question, there isn't exactly a compelling reason to keep the parameters. The main reason why they were created is because back in the days when date autoformating was encouraged, the accessdate field autolinked. Some people didn't like that so they added the accessdaymonth/accessmonthday and access year parameters so the autoformatting could be avoided. Now that the autolinking has been removed from autodate (on cite web), there isn't a reason to keep the additional parameters. --Bobblehead (rants) 21:11, 30 January 2009 (UTC)
It would also be "a relatively easy fix" to retain the alternate parameters. If consensus is that they are to be deprecated (i.e. no longer recommended) they can be removed from the documentation page (where they still are listed, by the way), bit no articles would need to be "fixed". If, however, they are made obsolete, as is currently the case (was there consensus for making them obsolete?), it requires much more effort to "fix" them than would be spent in coding them to continue working. — Bellhalla (talk) 21:20, 30 January 2009 (UTC)
On the contrary, it would be an extremely complicated and messy fix, since unlike the |date= aliases, there is no alternative but to mash the various accessdate parameters together before it hits the {{citation/core}} template that normally does all this. There are about 1,350 pages that use these parameters, out of probably over 350,000 total (it was 319,000 last September). I will work on a bot script to make these transitions. Happymelon 21:38, 30 January 2009 (UTC)
(edit conflict)Fixed them on the article you're concerned with, so that shouldn't be a problem anymore. Granted, I don't believe that's your point...;) --Bobblehead (rants) 21:41, 30 January 2009 (UTC)
Thank you for the edits, Bobblehead.
Thanks for the explanation, HappyMelon. While you are working on the bot script, can you also design it so that it will perform the same search-and-replace on the following templates that call {{cite web}}:
Thanks in advance. — Bellhalla (talk) 22:20, 30 January 2009 (UTC)
Coding.... Happymelon 22:39, 30 January 2009 (UTC)
BRFA filed Wikipedia:Bots/Requests for approval/MelonBot 12. Happymelon 23:02, 30 January 2009 (UTC)
Thanks Bellhalla for mentioning {cite DANFS}...I was wondering why the dates were off in USS Nevada (BB-36) the other day... :) And thank you Happy-melon for coding and doing all of this! —Ed 17 (Talk / Contribs) 01:20, 3 February 2009 (UTC)

The bot run is almost complete, a number of articles the bot couldn't decipher for whatever reason have been left unchanged. Any help going through the last few pages to update the templates, would be most appreciated. Happymelon 00:05, 5 February 2009 (UTC)

Are you going to rerun the bot form time to time? Looks like Wikipedia is still indexing new instances of using accessmonthday/accessdaymonth/accessyear. --Bobblehead (rants) 00:17, 6 February 2009 (UTC)

It would seem the bot missed some pages. I've just had to fix List of colleges and universities in Vermont. Toohool (talk) 08:31, 11 February 2009 (UTC)

Editprotected

{{editprotected}} Accessyear= no longer works. ~EDDY (talk/contribs/editor review)~ 19:51, 31 January 2009 (UTC)

Please elaborate. It works fine in the following instance:
"Example". {{cite web}}: Unknown parameter |accessday= ignored (help); Unknown parameter |accessmonth= ignored (|access-date= suggested) (help); Unknown parameter |accessyear= ignored (|access-date= suggested) (help)
It is not displayed when the "accessdate" parameter is used, because accessdate should be specified in ISO format (see documentation), and if accessyear was displayed too, it would display twice.
"Example". Retrieved 2009-12-012009. {{cite web}}: Check date values in: |accessdate= (help)
Martin (Smith609 – Talk) 20:01, 31 January 2009 (UTC)

Italics

After the recent changes to the template, now when italics are applied within the title parameter, they don't show up; I noticed this on the article Dengeki Gakuen RPG: Cross of Venus under refs 1, 5, 6, 7, 8, and 9. Furthermore when Template:' is applied within the template now, as with refs 7 and 9 in the same article, it renders it as <span style="padding-left:0.1em;">'</span> Can someone please change it back to the way it was (or are we just not going to allow italics in the title parameter anymore?).-- 04:29, 3 February 2009 (UTC)

Took me a bit to see what you want to do here. Looks like you want to italicize parts of the web page title that should normally be italicized; in this case the name of the game. Looks like template does not parse wikicode or HTML which is why you are seeing the single quotes and the span tag. {{citation/core}} is getting way over my head, but I do see another problem. --—— Gadget850 (Ed) talk - 10:05, 3 February 2009 (UTC)
See reply in next section Martin (Smith609 – Talk) 19:36, 3 February 2009 (UTC)

Mangled error message

{{cite web}} should generate an error if the URL or title is missing.

The URL detection does work:

{{cite web}}

But the title detection message is mangled:

{{cite web|url=http://en.wikipedia.org}}

--—— Gadget850 (Ed) talk - 12:27, 3 February 2009 (UTC)

The same bug is causing this as the italics above; there has been no corresponding change to [Citation/core] or [cite web] that I'm aware of, and both examples were working fine when the change was first implemented. Could this be software-related? Martin (Smith609 – Talk) 19:40, 3 February 2009 (UTC)
 Fixed, recent update to {{link}}. Happymelon 23:44, 3 February 2009 (UTC)
I'm still seeing this problem here. Gary King (talk) 23:40, 5 February 2009 (UTC)
That would be because those cites don't have a title parameter. The error message is supposed to show. The problem here is that it was mangled. --—— Gadget850 (Ed) talk - 23:53, 5 February 2009 (UTC)
Was there a discussion about making the error less obvious so less likely to be found? For instance, if an article has no <references />, then it's very obvious now. But for citation templates, it gives a very subtle warning if one is missing a parameter? Gary King (talk) 00:06, 6 February 2009 (UTC)
I was considering that very question and the best solution. See below. --—— Gadget850 (Ed) talk - 00:25, 6 February 2009 (UTC)

Last updated...

This is more of a general question relating to citing web-based sources. When a page does not have a date it was written, such as a page that is periodically updated (like this one), does the date given as "Last updated <date>" function as as the "date" field when citing with this template? It seems like it should be to me, but I'm doubting myself. Thanks. JohnnyPolo24 (talk) 17:11, 5 February 2009 (UTC)

Yep, in a case like that, last updated would be its date :) -- AnmaFinotera (talk · contribs) 17:31, 5 February 2009 (UTC)
Thanks. That's what I thought, but I just wanted to make sure. JohnnyPolo24 (talk) 18:07, 5 February 2009 (UTC)

YYYY-MM-DD

Did somebody screw with the template or is it just an error? All of a sudden all of the references in articles are being formatted as "DD-MM-YYYY". It's doing this even in articles that just yesterday (cause I check every day) had them listed as "YYYY-MM-DD". I tried fixing this in on article by using the "dateformat=mdy" option, but it still showed up wrong. Is this something wrong on Wikipedia's side? TJ Spyke 02:34, 11 February 2009 (UTC)

See discussion here: [8] --Bobblehead (rants) 02:37, 11 February 2009 (UTC)

Centralised archival

{{editprotected}} A recent update to Template:Citation/core has made an improvement possible in the way that archive details are handled; please replace Template:Cite web with the current sandbox. (Fully tested) Martin (Smith609 – Talk) 00:40, 8 February 2009 (UTC)

Not done for now: It would be polite to at least explain what the change is doing; I can only just work through the changes, others may be completely in the dark. Is this intended to change the visual appearance or functionality? An example wouldn't hurt. Also, the requested code calls the citation/core sandbox (this has happened before); although AFAIK the two templates are currently the same, please double-check that the functionality is correct on the live citation/core code. Happymelon 00:53, 8 February 2009 (UTC)
Sorry, the improvements are: better error handling (e.g. mark when archivedate specified but archiveurl blank); correction of punctuation and capitalisation; and centralising functionality to minimise future template drift. No change in appearance will be observed (except if 'Archived on' comes after a comma, in which case it will no longer be incorrectly capitalised). Examples are available at Template:Citation/testcases/archive (they will affect cite web in the same way as they do Citation). Hope that clarifies things; I've reenabled the editrequest. Martin (Smith609 – Talk) 01:19, 8 February 2009 (UTC)
Done Thanks; the testcases are invaluable. Happymelon 10:56, 8 February 2009 (UTC)
Messes up on archiveurl=, see e.g. ref 37 here. Fixed by changing the ref to {{citation}}, so the problem is with the template, not the editor's mark-up. Please check archiveurl= in all other "cite XXXX" templates. --Philcha (talk) 13:43, 13 February 2009 (UTC)
Lerman, Michael (March 29, 2007). "2007 Philadelphia Film Festival". IndieWire. {{cite web}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Missing or empty |url= (help)
Lerman, Michael (March 29, 2007). "2007 Philadelphia Film Festival". IndieWire. {{cite web}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); Missing or empty |url= (help)
Seems this was broken before the change, so reversion won't help, unfortunately. The deeper I dig into the code the less sane it becomes; a fix might take some thought... Happymelon 20:58, 13 February 2009 (UTC)
The examples here are either missing or misusing the {{{url}}} parameter, which is required. Put the original url there and the archived url in {{{archiveurl}}} and it should be fine, like so:
Pagrashtak 22:09, 13 February 2009 (UTC)
There's litte point in linking to the original when it's vanished, returning either a 404 or a redirect to e.g. a home page. --Philcha (talk) 22:21, 13 February 2009 (UTC)
That's a point of disagreement. Pagrashtak 14:09, 16 February 2009 (UTC)
I agree that the original links should be retained, even when the page is no longer available. This will make it clear to the viewer where the content originated.Brian Powell (talk) 05:47, 17 February 2009 (UTC)

Pipe in URL

Is there a way around linking to a URL that contains a pipe? For example: http://www.allmusic.com/cg/amg.dll?p=amg&searchlink=SIGUR%7CROS&sql=11:gifoxqwkldae~T5 doesn't work as the template assumes the pipe is the delimiter and treats the URL simply as http://www.allmusic.com/cg/amg.dll?p=amg&searchlink=SIGUR. --JD554 (talk) 10:00, 17 February 2009 (UTC)

You can urlencode it, that is replace the pipe with %7C. Viz:
{{cite web|url=http://www.allmusic.com/cg/amg.dll?p=amg&searchlink=SIGUR%7CROS&sql=11:gifoxqwkldae~T5|title=allmusic}}
"allmusic".
Mr Stephen (talk) 11:04, 17 February 2009 (UTC)
Nice one. Thanks, --JD554 (talk) 11:13, 17 February 2009 (UTC)

Citation problem

On the article I'm working on, I can't get a citation to display properly in the References section. It's citation #6; the link isn't working. Can anyone help? Vantine84 (talk) 05:19, 18 February 2009 (UTC)

Done. You forgot to include "http://" in the url. Sometimes you just need another pair of eyes; glad to help. --Gerry Ashton (talk) 05:42, 18 February 2009 (UTC)

What about a subtitle field?

Might help with some sites, like this for example: http://www.hdot.org/trial/defense/evans/430ciiD I'm having a heck of a time properly citing this website.

It is hosted at Emory University. It is part of the Holocaust Denial on Trial work. But it is also a transcript of the Irving v Lipstadt trial records, which were in a court in England. And on top of that, The trial documents were transcribed into XML by Addison-Wesley (click on 'about these documents'), which based that transcription on 'HTML and print editions by the Beck Center Staff'. And apparently comes from David Irving, Hitler and Holocaust Denial, Richard J. Evans,London Davenport Lyons Solicitors, London, 1999. —Preceding unsigned comment added by Decora (talkcontribs) 18:51, 18 February 2009 (UTC)

Not really seeing what a subtitle field would do there or why it would be needed. Most of the extra stuff you noted does not need to be included in the citation. From my basic understanding, this is an electronic version of a printed book? If so, use {{cite book}} and just include the URL to the online version. :) -- AnmaFinotera (talk · contribs) 18:58, 18 February 2009 (UTC)
For the example Decora gave, if I wanted to reference something in the defense documents, I would use title = Irving v. Lipstadt:Defense Documents and work = Holocaust Denial on Trial. --Gerry Ashton (talk) 19:11, 18 February 2009 (UTC)

"Written at"?

Currently, if you use a "location" parameter in the cite web template, the location will be prefaced with the words "written at". How can we get rid of the "written at" in the template? I'm not convinced that most people would want or expect that phrase to show up in the citation. Besides, in some cases the location refers to a place of publication, not a place of writing. --Metropolitan90 (talk) 02:52, 26 February 2009 (UTC)

  • On the other hand, it's sometimes useful to have a "written at" attribute: wire service articles, for example, often contain a location (distinct from the publishing news outlet's location). Is there any way to distinguish the two, and do we want to include the ability to store that information in the citation? TheFeds 19:54, 15 March 2009 (UTC)

Possible bug with cite journal?

I'm not sure why but it seems that the text "Archived from the original on .." isn't displayed when using the archiveurl parameter with {{cite magazine}} (cite journal). I added a magazine article reference to the Dondurma article using the {{cite magazine}} template but it didn't display the archived url so I had to switch to {{cite web}}, but then apparently cite web doesn't accept the issue= parameter so both templates weren't ideal for me. Oh well, just thought I'd bitch and whine. -- OlEnglish (Talk) 22:24, 16 March 2009 (UTC)

It's not a bug – cite journal simply does not support archiving. See the documentation at Template:Cite_magazine#Parameters. Regards, Skomorokh 22:32, 16 March 2009 (UTC)
And, in this case, the original is still online and free to all. Mr Stephen (talk) 22:39, 16 March 2009 (UTC)
Right. I switched back to cite magazine. Still it's too bad cite journal doesn't support the archiveurl= parameter, as there are many online journals and magazines. Plus it would probably help WebCiteBot if it's approved. -- OlEnglish (Talk) 19:16, 17 March 2009 (UTC)
You know {{cite magazine}} redirects to {{cite journal}}, right? Yeah, I'm sure WebCiteBot will improve things. I'll ask at Template talk:Cite journal why the parameter is not supported anyway. Skomorokh 20:57, 17 March 2009 (UTC)
Yup I'm aware. Thanks. -- OlEnglish (Talk) 23:25, 17 March 2009 (UTC)

Title

I added "The word 'title' should not be capitalized to avoid 'broken citation' error." and was reverted by User:RossPatterson. His rational was that the template documentation writes 'title' with a small letter.

I included this warning because it is one of the mistakes I see on a daily basis when correcting broken citations. Lots of editors don't copy an empty template from here, but write it themselves. And sometimes they write 'Title'. That's why I think that my warning was necessary here.

Let's hear the opinions of other editors on this. Debresser (talk) 13:23, 23 February 2009 (UTC)

I don't see much harm in including a note that the parameter names are case-specific. I know its a frequent problem with some other templates that do use uppercase...so when you use lower case, it borks. -- AnmaFinotera (talk · contribs) 13:55, 23 February 2009 (UTC)
My rationale was that all of the parameters are lower-case-only, not just |title=. Getting any of them wrong produces a bad citation. Getting |title= or |url= wrong also produces an error. I actually think the error is better, as it tells you what is wrong, but MediaWiki templates can't detect typo'ed parameter names, so we can't report errors on those. RossPatterson (talk) 19:38, 23 February 2009 (UTC)
I perfectly agree with your rationale. I was just trying to address a relatively common mistake. Anyway, is not a must for me. I doubt it would help significantly. :) Debresser (talk) 20:35, 23 February 2009 (UTC)

Because of another unfortunate edit like this (see here), involving all parameters in 7 cases, I decided to put a general notice in the doc page to avoid capitalisation of all parameters. Debresser (talk) 12:32, 2 March 2009 (UTC)

I have expanded the logic of AWB's general fixes to correct this for {{cite web}} on en-wiki (rev 4131, now in SVN release, will be generally available in next AWB release). I have 1500 hits from the October database dump that I'll now run through. Do any other 'cite' templates have the same restriction that the AWB fix should also apply to? Thanks Rjwilmsi 20:16, 2 April 2009 (UTC)
All of them I think (see User:Citation bot), but certainly {{cite book}}, {{cite news}} (by documentation) and {{cite journal}}, {{cite press release}}, {{cite hansard}} (by inspection). I don't think I'ver ever used any of the others. While an edit is open, can we convert: id=PMID -> pmid=; id=ISBN -> isbn=; id= OCLC -> oclc=; id=DOI -> doi=; (there may be others, I don't know). Mr Stephen (talk) 21:25, 2 April 2009 (UTC)
rev 4132 AWB now covers cite ... web|book|news|journal|paper|press release|hansard|encyclopedia and citation. For the DOI/PMID business, I have no knowledge of this stuff, so please file an AWB feature request with more details, examples of correct edits, maybe even the relevant code from the DOI bot (better to convert tested code than rewrite from new). Thanks Rjwilmsi 22:33, 2 April 2009 (UTC)

Another mistake which is made approximately ten times more often than the one mentioned directly above is that editors don't provide a title parameter. I've changed the documentation page to stress this point clearly. Debresser (talk) 00:58, 2 April 2009 (UTC)

I did make a feature request for Reflinks which should help in clearing up this error, but it's not been implemented yet. Rjwilmsi 20:13, 2 April 2009 (UTC)

doi parameter

Ok, I don't claim to understand the need for a doi, or how it works, but is it possible to use a piped link for it? I've just seen it added to Abbots Bromley, and it appears as a meaningless jumble of characters. If possible, I suggest it be change to something like [{{{doi}}} permanent digital identifier] or something similar, yielding (in this example) permanent digital identifier. Can this be done? —  Tivedshambo  (t/c) 17:44, 25 March 2009 (UTC)

References with a DOI will generally not be cited with this template. Martin (Smith609 – Talk) 19:01, 2 April 2009 (UTC)
Can I remove it from the article then? —  Tivedshambo  (t/c) 19:08, 2 April 2009 (UTC)
It's cited using Template:Citation and should remain. See WP:DOI for more info. Martin (Smith609 – Talk) 23:44, 2 April 2009 (UTC)
My mistake - I didn't cotton on to it not being cite web. I'll raise the discussion on template talk:Citation. —  Tivedshambo  (t/c) 08:53, 3 April 2009 (UTC)

{ {accessyear}}??!!

I dont know if it's just me or if every single "citeweb" reference has { {accessyear}} at the end!!?? Every article? Dt128 (talk) 08:06, 7 April 2009 (UTC)

That was my error; it's fixed now. —Anonymous DissidentTalk 08:38, 7 April 2009 (UTC)
For example, Duffy discography is still showing { {accessyear}}! Dt128 (talk) 09:39, 7 April 2009 (UTC)
Purge your cache. —Anonymous DissidentTalk 09:57, 7 April 2009 (UTC)
Thanks! Dt128 (talk) 10:21, 7 April 2009 (UTC)

Double periods

Cite web adds a period to the publisher, editor, and first fields, and there may be other fields. If these fields already end in a period (for instance, if the publisher ends in "Inc.", "Co.", or "Corp.", or a name field ends in an initial or in "Jr.") the result is a double period. I'm told there's no way to tell Cite Web not to add the extra period if it already exists, because Cite Web is a template, not a program. But this strikes me as not taking the problem seriously enough; double periods in Cite Web are among the most frequent proofreading problems in Wikipedia, and although removing the period after "Inc." works, it's much too big a problem to solve one article at a time. If we can't change the template, can we get a bot to remove the extra period, or at least put a warning in the document? Art LaPella (talk) 05:11, 6 February 2009 (UTC)

A warning in the documentation would be a good idea. I see no reason, really, to add end punctuation to anything in the template save for material in the title, which I treat as a quote. I don't use punctuation for names (Abrams, J J), companies (Camelot, Inc), etc. Huntster (t@c) 05:37, 6 February 2009 (UTC)
OK, I'll change the documentation, although few people will read it. Of course the issue is how Camelot, Inc(.) is written throughout Wikipedia, not just by one editor. Art LaPella (talk) 06:08, 6 February 2009 (UTC)
Oh, most definitely it is an issue throughout the site, but the /doc change is a good first step. Huntster (t@c) 07:17, 6 February 2009 (UTC)
The StringFunctions extension has a {{#sub:}} function that would return the last character in a string, and that could be tested by {{#if:}}. However, Special:Version shows that the extension is not installed. —AlanBarrett (talk) 08:14, 6 February 2009 (UTC)
The best solution would be to change Cite Web's default separator to a comma: you can see how this change affects an individual citation by specifying |sep=,. Currently the cite and citation templates aren't consistent in using a period or comma: perhaps changing them all to use commas by default would be a good idea? Martin (Smith609 – Talk) 12:50, 6 February 2009 (UTC)
Of course the Inc. Co. Ltd. etc are erroneous input anyway. Should the template output mark it as an error?LeadSongDog come howl 03:22, 10 April 2009 (UTC)
But Pubs., Pr., etc. are not. They are even mandated by some citation styles. — SMcCandlish [talk] [cont] ‹(-¿-)› 04:18, 10 April 2009 (UTC)

Error message improvement

The template generates an error if the URL or title are missing:

I propose that these be wrapped with class="error" to make them stand out. For example:

--—— Gadget850 (Ed) talk - 00:29, 6 February 2009 (UTC)

Sure, I'd like anything to make it stand out. Something as obvious as that is more likely to be fixed sooner rather than later. Currently, it's very hard to spot errors in a list of 100 or more references, which is quite often, especially in articles at places like FAC. Gary King (talk) 00:55, 6 February 2009 (UTC)

I would like to propose these specific changes:

<span class="error">Error: no {{para|title}} specified when using {{tl|cite web}}</span>

Error: no |title= specified when using {{cite web}}

<span class="error">Error: no {{para|url}} specified when using {{tl|cite web}}</span>

Error: no |url= specified when using {{cite web}}

This makes the problem more obvious and makes the verbiage consistent. --—— Gadget850 (Ed) talk - 03:07, 13 February 2009 (UTC)

Sure. I'm be willing to use anything besides how it looks now, short of using the blink element. Gary King (talk) 03:28, 13 February 2009 (UTC)

As one of those who regularly fix broken citation errors I completely agree that it is sometimes very hard to find the footnote with the citation error. They should really be red (like reference errors).

I also agree that it would be better if both |url= and |title= errors had the same text: or You must specify ... when using {{Cite web}} , or No ... specified. I personally like the first better.

I see consensus here. When will this be implemented? Debresser (talk) 00:53, 2 April 2009 (UTC)

 Done Martin (Smith609 – Talk) 18:59, 2 April 2009 (UTC)

This is great. It is now so much easier to spot the reference with the problem! Debresser (talk) 08:22, 3 April 2009 (UTC)

Please notice that when the title is missing, the last two brackets are not in red. Example: http://doviddebresser.angelfire.com/. {{cite web}}: Missing or empty |title= (help) Could someone fix this, please. Debresser (talk) 00:34, 10 April 2009 (UTC)

The problem is that the error message is linked, and includes a link to Cite Web. The solutions are to remove the error message from the title field [which would either involve quite substantial changes to the template, or moving the error message to a later point in the citation]; to prevent the title from being linked [undesirable]; to remove the link to Cite Web [undesirable]; or to leave it as it is [ugly]. Which would people prefer? Martin (Smith609 – Talk) 14:53, 10 April 2009 (UTC)
But the error message for a missing url doesn't show this same problem. Just the error message for a missing title. So why should this be any more difficult? Debresser (talk) 15:53, 10 April 2009 (UTC)
Because the title isn't linked to anything, because there is no URL to link it to. Martin (Smith609 – Talk) 17:55, 10 April 2009 (UTC)
I understand now. As one who works with this error category a lot, I'd prefer to remove the link after the error message. If a reason is needed, it would be that often the problem is not that a title is not provided, but e.g. that the word "title=" is missing from the template or that it is capitalised "Title=", so the first thing I do is check the whole template in the edit page to see where the error is, and I never ever get to press the link provided by the error message in the article page. Debresser (talk) 18:22, 11 April 2009 (UTC)

The template page

Why is there a broken url message on top of the template page? Debresser (talk) 08:24, 3 April 2009 (UTC)

That's the template itself. It displays that message when no URL parameter is provided. Perhaps there's a case for putting it in <noinclude> tags. —  Tivedshambo  (t/c) 08:51, 3 April 2009 (UTC)
It's because the update that switched this template to using {{Citation/core}} accidentally removed the <includeonly> and </includeonly> that should enclose the template itself. That probably means that all the templates switched over to {{Citation/core}} in recent months have the same problem. RossPatterson (talk) 11:47, 3 April 2009 (UTC)
 Fixed Happymelon 11:59, 3 April 2009 (UTC)

Thanks, Happymelon for fixing this. My "question" was actually meant to get this fixed. And this fix was a lot more important than you think. Let me explain.

Before the fix, the first thing you would see on the page is: provide a url, or the template errors. Nothing is mentioned about the necessity to provide a title also, until much later, in the technical parts of the documentation. In my opinion this contributed significantly to the large number of uses of the Cite web template without a title parameter (around 10 a day, about 50% of all citation errors in Category:Articles with broken citations. You have now fixed the template, and I hope the occurence of this error will go down. Debresser (talk) 09:21, 8 April 2009 (UTC)

There is a very noticable reduction in the number of problem encountered in the Category:Articles with broken citations. Thanks again! Debresser (talk) 18:25, 11 April 2009 (UTC)

accessdates

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)

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 accessdate? (And shouldn't the documentation be updated?)--Kotniski (talk) 11:51, 2 April 2009 (UTC)
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)
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)
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). Happymelon 13:50, 19 April 2009 (UTC)

Use template:languageicon?

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)

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

dateformat parameter

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)

location parameter is hosed

{{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)

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

{{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)
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)
 Done What a mess :D Happymelon 09:44, 21 April 2009 (UTC)

Mentioning cross-namespace redirect in /doc

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)

It should be deleted. Cross-space redirects are not allowed, and it certainly shouldn't be encouraged or mentioned here. -- AnmaFinotera (talk · contribs) 02:24, 18 May 2009 (UTC)
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)
My opinion is to keep the status quo. In general I am in favor of simplicity. Debresser (talk) 14:39, 18 May 2009 (UTC)

Change in default separator and minor bug

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)

{{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). -- AnmaFinotera (talk · contribs) 01:33, 24 May 2009 (UTC)

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)

  • Are semicolons really that important? --droll [chat] 03:33, 24 May 2009 (UTC)
    • 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)
  • 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)
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)
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)

Support for parameter "accessyear"

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 DissidentTalk 12:40, 13 March 2009 (UTC)

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 January2001 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 DissidentTalk 12:46, 13 March 2009 (UTC)
See the section #accessdates below. -- John Broughton (♫♫) 14:18, 27 May 2009 (UTC)

Display of original and archived links

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)

Good change. An admin needs to make it tho.--2008Olympianchitchat 22:49, 27 May 2009 (UTC)
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)
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)

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)

Authorlink display

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

For example

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

or even

in comparison to

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

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)

"released date" or "article date" for date filed

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)

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)
??? That statement wasn't clear due to way you used "published."Jinnai 04:54, 6 June 2009 (UTC)
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)

Field order

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)

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)

archiveurl

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)

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)
Thanks, I had not noticed that section. --Joshua Issac (talk) 20:28, 22 June 2009 (UTC)

Category:Cite web templates using unusual accessdate parameters

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)

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). Happymelon 12:14, 9 May 2009 (UTC)
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)
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)

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)

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)

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)

Then we don't need to make any changes, as the current {{NAMESPACE}} {{PAGENAME}} = {{FULLPAGENAME}}. ---— Gadget850 (Ed) talk 12:07, 10 May 2009 (UTC)
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)
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? Happymelon 08:31, 15 May 2009 (UTC)
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)
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)
 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. Happymelon 10:54, 15 May 2009 (UTC)
Thanks. This is called: making the live of gnomes a little easier. :) Debresser (talk) 10:56, 15 May 2009 (UTC)
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)

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. Happymelon 11:03, 17 July 2009 (UTC)

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 Happymelon, 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)
They will simply not function; it would be like setting |snorkel=. (also)Happymelon 08:51, 21 July 2009 (UTC)

Page and pages parameters are broken

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)

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)
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)
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)
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 DissidentTalk 13:42, 10 May 2009 (UTC)
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)
Other templates to p. or pp., not page or pages. -- AnmaFinotera (talk · contribs) 14:59, 10 May 2009 (UTC)
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)
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 -- AnmaFinotera (talk · contribs) 15:09, 10 May 2009 (UTC)
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)
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)
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. -- AnmaFinotera (talk · contribs) 16:03, 10 May 2009 (UTC)

Good points all. I agree with Smith609 and AnmaFinotera, 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.&nbsp;}}{{{page}}}
         |{{#if: {{{pages|}}}|{{#if:{{{nopp|}}}||pp.&nbsp;}}{{{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)
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)
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)
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)

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)

Date format

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 (talkcontribs) 19:46, 23 June 2009 (UTC)

I have boldly replaced the date format to use {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (e.g. 13 May 2024). 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)
I support you here. Debresser (talk) 16:54, 30 June 2009 (UTC)
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)

Parameter sequence

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)

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)
Indeed, a sandbox-test confirms your answer. Thx. Must have been a different mistake by me. -DePiep (talk) 12:02, 29 June 2009 (UTC)

date parameter moved?

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)

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

Quotes should not be part of the link.

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

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)
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)
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)
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)
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)
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)
Well done, Crum, thanks for that. Huntster (t@c) 09:44, 1 July 2009 (UTC)

error in titles with closing bracket

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)

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. -- AnmaFinotera (talk · contribs) 18:52, 4 July 2009 (UTC)

Rearanging archive & original placement order

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)

Citing a PDF that doesn't end in the PDF extension

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:

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] => [9]

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)

Undocumented parameters

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)

As it is based on {{Citation/core}}, I would have thought that you could have used any of those parameters. I usually check for deprecation there, though I am also basically trying to get refs done as painlessly as possible.<g> -- billinghurst (talk) 01:26, 17 August 2009 (UTC)

Parameter "editor" needed

An editor parameter is needed, since any work of any kind in any medium can have an editor (and this editor may be a signficant part of the citation information). It should be formatted like, and have the same syntax as, the same field in Template:Cite book, after two recently-reported bugs in that code are fixed. Example:

Without the field:

<ref>{{Cite web
|title=What is Occam's Razor?
|first=Phil
|last=Gibbs
|year=1997
|work=Usenet Physics FAQ
|url=http://math.ucr.edu/home/baez/physics/General/occam.html
}}</ref>

[b 1]

With the field:

<ref>{{Cite web
|title=What is Occam's Razor?
|first=Phil
|last=Gibbs
|year=1997
|work=Usenet Physics FAQ
|editor=Don Koks
|url=http://math.ucr.edu/home/baez/physics/General/occam.html
}}</ref>

[b 2]

  1. ^ Gibbs, Phil (1997). "What is Occam's Razor?". Usenet Physics FAQ.
  2. ^ Gibbs, Phil (1997). Don Koks, ed. "What is Occam's Razor?". Usenet Physics FAQ.

SMcCandlish [talk] [cont] ‹(-¿-)› 21:26, 17 August 2009 (UTC)

 Done to support 4 editors, using same input format as Template:Citation. Martin (Smith609 – Talk) 23:21, 17 August 2009 (UTC)

Please see #4, as I want to reuse it on other articles.

This is the reason I have always just used the URL and the accessdate. What in the world am I doing wrong?Vchimpanzee · talk · contributions · 18:34, 3 September 2009 (UTC)

You had a hard return in the middle of the title. -- AnmaFinotera (talk · contribs) 18:47, 3 September 2009 (UTC)
Thanks. I was also referring to the coauthor but then I remembered it was "coauthors" and when I tried to use a singular when it had a plural, or vice versa, it didn't work.
I copied and pasted the title, which doesn't work very well with PDFs.Vchimpanzee · talk · contributions · 19:24, 3 September 2009 (UTC)

Problem with accessdate parameters

Accessmonthday

At the moment the code for the accessmontday parameter is

#if:{{{accessmonthday|}}}|{{{accessmonthday}}} {{{accessyear|}}}|

This results in a missing comma, in the case that there is an accessyear. Adding the comma in the code would result in a superfluous comma, in the case that there is no accessyear. The solution could be

#if:{{{accessmonthday|}}}|{{{accessmonthday}}}{{#if:{{{accessyear|}}}|, {{{accessyear}}}}}|

Debresser (talk) 22:07, 10 September 2009 (UTC)

Discussion of first problem

Use of |accessdaymonth= or |accessmonthday= will put the page into Category:Cite web templates using unusual accessdate parameters, so it's not a good idea to use them. I believe that |accessday=, |accessmonth= and |accessyear= are also deprecated, that's why none of the five are in the documentation... instead, |accessdate= should always be used, because when you find the web page that you're citing, you know what today's date is --Redrose64 (talk) 22:32, 10 September 2009 (UTC)
We know that. We are now discussing how to program the code that has to handle any parameter comming its way. Debresser (talk) 22:48, 10 September 2009 (UTC)
There have been several discussions along similar lines in the past, see #Category:Cite web templates using unusual accessdate parameters and quite a lot in Template talk:Cite web/Archive 5, in particular Template talk:Cite web/Archive 5#accessdates --Redrose64 (talk) 22:46, 10 September 2009 (UTC)
The simplification discussed in #Category:Cite web templates using unusual accessdate parameters met general agreement, but was not implemented, for unclear reasons. Please pay attention though, that only the problem described in the first subsection here would be solved by that simplification, but not the second, which remains in its place in the simplified code also. Debresser (talk) 22:51, 10 September 2009 (UTC)
BTW, I personally would like to simplify even more, and scrap accessday, accessmonth, and accessyear as well. Leaving only one accessdate. That for sure would solve both problems! Debresser (talk) 22:58, 10 September 2009 (UTC)
Yes, might I suggest then, that (a) a paragraph be added to the documentation along the lines of
The parameters accessday, accessdaymonth, accessmonth, accessmonthday and accessyear are deprecated and should not be used. accessdate should be used instead.
and (b) the template code be modified to place articles into Category:Cite web templates using unusual accessdate parameters should any of these five be detected --Redrose64 (talk) 23:03, 10 September 2009 (UTC)
At the moment the text is "accessdate: Full date when item was accessed, in the appropriate date format for the article. Should not be wikilinked." I would not change that at all. Perhaps indeed just add "The parameters accessday, accessdaymonth, accessmonth, accessmonthday and accessyear are deprecated and should not be used." Debresser (talk) 23:07, 10 September 2009 (UTC)
BTW, according to the logic in the documentation page, I would scrap the day parameter as well. It says there "either date: Full date of publication. ... or year: Year of publication, and month: Name of the month of publication. If you also have the day, use date instead." Which means you never should need day. Debresser (talk) 23:15, 10 September 2009 (UTC)

I finally finished the job I promised to do a while back, which as Debresser notes, I forgot to complete, and have removed |accessdaymonth= and |accessmonthday= entirely. I think this resolves the first issue? Happymelon 13:12, 13 September 2009 (UTC)

Yes, it does. The second problem remains, though, and virtually no input from other editors. Debresser (talk) 16:09, 14 September 2009 (UTC)

fo