This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
This might not be a big problem yet, but perhaps something that should be on the radar. Forbes is now blocking users who have ad-blocking plugins enabled in their web browsers. The message shown to users is that they must whitelist Forbes' website in order to see the content; it's an all-or-nothing deal. If citations link to this site, or other sites that employ the same tactic, it becomes an accessibility issue much like a WP:PAYWALL. Using |subscription= or |registration= seems a bit misleading. Any ideas on how this could be handled? --Drm310 (talk) 15:57, 6 April 2016 (UTC)
I disagree. The end-result is that the source is not accessible under some circumstances. This has to be signaled, because it will affect verification for some readers. For now, I would use {{link note}}: (Website must be white-listed). 72.43.99.130 (talk) 17:17, 6 April 2016 (UTC)
No, use of adblocking software is a user choice. The ability to get to the site to verify a reference is therefore their own choice unlike a page where subscription is required. Nthep (talk) 17:43, 6 April 2016 (UTC)
In the past, users would choose to load pdf plugins if they wanted to see embedded pdfs. This may also be the case with some browsers today. This requirement is still being signaled by the pdf icon, and recommended in the template doc through the use of |format=. 72.43.99.130 (talk) 19:00, 6 April 2016 (UTC)
[1] also works. Please provide a legitimate case where this error cannot be worked around. Hypothetical "they must exist" doesn't usually work. --Izno (talk) 15:34, 8 April 2016 (UTC)
I see it in the TemplateData documentation for {{cite web}}. I have had my hands slapped for touching TemplateData – programming code that has been placed in template documentation, a terrible programming practice – so I no longer touch it. I do not consider TemplateData part of the template's documentation. – Jonesey95 (talk) 14:36, 8 April 2016 (UTC)
I believe the title of a speech should be in quotation marks, not italics. But {{Cite speech}} italicizes the title. I'm interested in getting that changed, but I was hoping for some discussion and consensus about it first. —Torchiesttalkedits23:08, 8 April 2016 (UTC)
I think that I am inclined to agree. Chicago and MLA seem to suggest that speech titles (they use the term 'lectures') should be quoted. APA seems to suggest that one doesn't cite a speech directly but, rather cites an 'authoritative source for the text.' That last I think applies to us because of the nature of WP:RS and WP:V; we should be citing a published transcript. If that is true, then {{cite speech}} should require both the title of the speech and the title of the enclosing work – like a chapter in a book. If the speech is published stand-alone as a pamphlet, then use {{cite book}}.
The way the template documentation is written suggests that it is permissible to cite something that an editor has heard at an |event= because it makes no mention of an enclosing work.
In the particular case I'm concerned with, it was a speech given at an event, with a video of the speech available on the site of the hosting entity. The event is notable and has its own article. —Torchiesttalkedits01:02, 9 April 2016 (UTC)
That video is the document that should be cited, when referencing the speech itself (as opposed to the event). I would use {{cite av media}}. Note the title displays in italics. Also note, you are no longer citing the speech, but (as Trappist suggested), a document of the speech. 72.43.99.146 (talk) 13:24, 9 April 2016 (UTC)
I would add that this discussion highlights some inconsistencies of cs1 templating. Are they citing 1. media in which source material is distributed (eg {{cite av media}}) or 2. source material type (eg {{cite speech}})? Or (confusingly) both or either? 72.43.99.146 (talk) 13:38, 9 April 2016 (UTC)
If we should cite videos or other documents as sources for a speech (and I probably agree with this), when should {{cite speech}} be used? It seems appropriate in a list of publications as in Albert Einstein, is this right? Perhaps the documentation for {{cite speech}} should give some guidance on when to use it, and when to use other templates that publish the speech. —Anomalocaris (talk) 06:27, 10 April 2016 (UTC)
Getting back to the original point, it seems we have agreement that speeches should be in quotation marks. Does anyone know where to request a change to the template? The talk page for it redirects to here. —Torchiesttalkedits16:59, 9 April 2016 (UTC)
Unfortunately it is hard to separate this original point from a bigger discussion of cs1. As far as I can tell, {{cite speech}} treats |title= as an alias of Module:Citation/CS1/Whitelist 'work' which to my knowledge is always italicized. In other templates, |title= does not refer to 'work', but to a part enclosed in the work, such as an article in a magazine. So things outside the template must change for your request to be applied. 65.88.88.69 (talk) 19:13, 9 April 2016 (UTC)
The Gender Equality Architecture Reform (GEAR) Campaign lobbied from 2007 for a new UN gender equality entity, with a website at http://www.gearcampaign.org. It achieved its goals in 2010 and dissolved, letting the domain name lapse. Now the domain name is being used by a blog about electric battery technology. The effect is that links in the Gender Equality Architecture Reform article point to the home page of the electric battery blog. Two suggestions have been made:
Add |archiveurl=. Problem: there may be no archive copy. And in this case the robots.txt on the electric battery blog is preventing access to archive copies (if they exist).
Add {{dead link}}. Problem: the link is not dead. Someone may come along, check the link, find it is not dead at all, and remove the {{dead link}}
The url should be preserved. The source page was there once, and quite possibly it is preserved in an archive somewhere which may become accessible in the future. Perhaps the citation template should have a parameter like |usurped-url=yes/no that would suppress the url link and add a message like (page no longer at original location). I am not sure if it should display the url, which is not useful to the general reader. Aymatth2 (talk) 14:58, 30 March 2016 (UTC)
If the original page is archived, the archived url could be added to the template, and the dependent parameter dead-url could be set to |dead-url=usurped, so that it points to the archive even when the non-applicable url is live. I suggest a search for the original page at the various online archives, maybe there is a capture somewhere. 72.43.99.130 (talk) 21:21, 30 March 2016 (UTC)
That works today when the original url is archived. But often it is not archived or, as in this example, even if it is archived the current robots.txt is blocking access to the archive. We need a solution for situations when a search in the archives for the original page fails. Aymatth2 (talk) 23:34, 30 March 2016 (UTC)
If you are certain that the original website publisher had forbidden archiving, there is little to be done.
You could ask the original publisher to somehow make available their own copy of the site (if any). I think this would be regarded as a primary source, since there would be no way to compare it with the live website as it was published.
Maybe a reliable (per Wikipedia) 3rd party has downloaded/screen-captured the website in question somewhere?
Reliable sources may be citing/mentioning the original website; you could use that info.
In all cases though, it would imo be against guideline to enter the resulting url in a citation of the now defunct organization. You are no longer citing that. You are citing information about the organization and its website. 72.43.99.146 (talk) 14:59, 31 March 2016 (UTC)
We have no way of telling whether the original website publisher forbade archiving, or whether the original page was archived at all. In this case the original publisher no longer exists and a search finds no online version of the original page. All we know is that, assuming good faith, a statement in the article was supported by a web page with that title at that url on that access date. The url now points to a completely different page. The question is how to represent that in the citation. Aymatth2 (talk) 15:58, 31 March 2016 (UTC)
robots.txt will not include a website unless the publisher expressly requests it. If the site was up for any length of time, and the publisher did not forbid it, it is likely some WebCrawler or other captured a snapshot. Again, I suggest you search these archives for possible captures during the time the site was up. The other option is not to include any reference to the website in the citation; it looks unverifiable. You can, as suggested, include refs from reliable sources about the website. 68.166.197.2 (talk) 22:02, 31 March 2016 (UTC)
Perhaps the example is confusing. Assume an article on goldfish breeding cites a web page found in 2009 at xyz.com. The XYZ Society was an authority on goldfish. The page was never archived and the XYZ Society was dissolved. Later, xyz.com was acquired by an unrelated organization. A statement in the article on goldfish breeding was supported by a web page about goldfish at xyz.com in 2009. The url now points to a completely different page. The question is how to represent that in the citation. Aymatth2 (talk) 23:53, 31 March 2016 (UTC)
Since the webpage no longer exists in any form, the specific citation is unverifiable, and it cannot support any statement. Whether the url now points elsewhere is irrelevant. I would recommend using a different source (and citation) to support said statement, if it is essential to the article. One example may be a reliable source that 1. mentions the no-longer existing webpage and 2. the specific content in that webpage that is pertinent to the statement. 72.43.99.146 (talk) 00:59, 1 April 2016 (UTC)
Links go dead all the time. If we cannot find an archive url we flag them as {{dead link}}. We do not remove the statement that relies on the dead link, and do not remove the citation, but just note that the link is no longer live. We keep a record of the source even though the source cannot now be retrieved. That policy will not change. This is a special case where the dead link has come back to life in a completely different form. Aymatth2 (talk) 01:15, 1 April 2016 (UTC)
@Aymatth2: I think you might be misunderstanding the "dead link" term here. If you were citing http://www.example.com/special_report.pdf published in 2009, and now the new website does not have a "special_report.pdf" file, then the link is dead. Without any archived copies of the old website accessible, it's as if the only copy of a book being cited were destroyed. In either case, it's not longer verifiable in any form. Imzadi 1979→02:23, 1 April 2016 (UTC)
@Imzadi1979: If there is no longer a file at http://www.example.com/special_report.pdf the www.example.com server may still handle a request for that url. It may give a "404 File not found" message, or a nicer "Ooops!" message. It may give a search screen or simply present the home page, as with http://www.gearcampaign.org/lost_file.php. The link is truly dead if the browser cannot find the domain or the server says the page does not exist. If the server comes back with a meaningful page, I would say the link has been "usurped", although I dislike the term because it implies something illegal. Aymatth2 (talk) 12:28, 1 April 2016 (UTC)
Does this excerpt from the {{cite web}} documentation help?
dead-url: When the URL is still live, but pre-emptively archived, then set |dead-url=no. This changes the display order with the title retaining the original link and the archive linked at the end. When the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable, setting |dead-url=unfit or |dead-url=usurped will not link to the original URL in the rendered citation; |url= is still required. Other accepted values are y, yes, or true. Alias: deadurl.
Not quite. |dead-url=usurped was intended for the similar case where the original |url= points to something inappropriate and there is an archive of the source that is available through |archive-url=. In this case, the original |url= points to something inappropriate but there is no archive of the source for |archive-url=.
I think that Editor Aymatth2 is looking for a way to prevent |url= from linking |title= like we do with |dead-url=usurped. This preserves the record of the source url, but the rendered title isn't linked. We might accomplish this with |dead-url=usurped no archive or |dead-url=unfit no archive.
Cite web comparison
Wikitext
{{cite web|dead-url=usurped no archive|format=PDF|title=GEAR Campaign Working Group|url=http://www.gearcampaign.org/uploads/cms/_images/4.2010%20GEAR%20Campaign%20Working%20Group.pdf}}
The above "usurped no archive" would work for me. The url is preserved, because maybe the page was in fact archived somewhere we never heard of, but the link is suppressed. I am pessimistic about Internet Archive doing anything about robots.txt. A change in name of the owner of a domain may just indicate a corporate name change or takeover. Internet Archive is probably correct to respect current robots.txt restrictions even if they were not there in the past. Aymatth2 (talk) 12:28, 1 April 2016 (UTC)
I wonder why an unverifiable url needs to be preserved. It adds nothing to the citation or to the statement it supposedly supports. If the only support for that statement was contained in the allegedly existing webpage, then this statement could now be challenged according to WP:V. The function of |dead-url= is to substitute the url when an archive exists. The function of {{dead-link}} is to signal editors that there is a problem url. If that url reputedly contained a source, and there is no other substitute for the url and/or the source, then the source does not exist.
Please find out how robots.txt works before assuming anything: see here. The Internet Archive has nothing to do with it, if the current legal owner requests it. Also the current exclusion does not mean that the page was never archived. There may well be snapshots of the page before the publisher added the exclusion. If there has been a change in publisher the old archived pages may still be public. 72.43.99.146 (talk) 15:21, 1 April 2016 (UTC)
There are many possible ways to find the new home of a URL that has become dead. A trick that might be unknown to an editor who comes across a dead url may be known to other editors. An editor who is a subject matter expert might know the new website of an organization, or be able to think of search terms that someone who is a good general-interest editor would not think of. So the dead url should remain as a clue to editors who may be able to find where it has moved to. Jc3s5h (talk) 16:09, 1 April 2016 (UTC)
Agreed. However, if the citation depended solely on that url, it is now violating Wikipedia guidelines and policy on verifiability. It should be removed, pending return to verifiability, and the previously supported text should be flagged with {{cn}}. 184.75.21.30 (talk) 20:59, 1 April 2016 (UTC)
Various government agencies and private companies maintain private internet archives which may become available in the future. We should assume good faith, keep the citation, retain the url and accessdate for potential future use, but suppress the usurped url in the citation display. Aymatth2 (talk) 21:31, 1 April 2016 (UTC)
There can be no assumption of good faith when it comes to verifiability. WP:V is a basic policy and it is one of the clearest such binding documents in Wikipedia. If a source is unsupported it just doesn't belong. I agree with flagging it with {{verify source}}. As is clear this is a temporary measure. If the source cannot be verified after a suitable length of time (which may be a short as hours for highly controversial subjects), any reference to it should be removed. 184.75.21.30 (talk) 23:20, 1 April 2016 (UTC)
A proposal that all citations to un-archived dead links should be removed after a specified period of time could be raised at the Village Pump. This discussion is about how to represent citations to un-archived dead links that have been usurped. Aymatth2 (talk) 23:41, 1 April 2016 (UTC)
Well this is not a proposal, but unambiguous existing, binding policy. Statements must be supported by citations of sources. Citations must be verifiable. If they are not, they cite nothing. The fact that the URL is usurped is a secondary technicality. What is not secondary is that whatever the allegedly supported statement claims, cannot be verified. It therefore does not belong in any encyclopedia. Flagging with {{verify source}} is an inducement to quickly (per WP:V) rectify this. Otherwise, it should be removed. As the policy makes clear, there is no way around this. 160.79.53.242 (talk) 00:53, 2 April 2016 (UTC)
Some say urls just clutter up a citation. Others say they should be provided as a courtesy if available. There is certainly no requirement to provide a url. This discussion belongs at the Village Pump, not here. Aymatth2 (talk) 02:33, 2 April 2016 (UTC)
This is not the question in this case. Here there is no proper url about the material cited. Some say that the url in question pointed elsewhere at some time in the past. You might as well be saying that you've seen a pig fly. Who can tell? 72.43.99.146 (talk) 15:02, 2 April 2016 (UTC)
WP:V is being misunderstood here. It does not require everything to be supported by citations. Nor does it say anything like "if a source is unsupported it just doesn't belong". WP:V requires references for "all quotations and any material challenged or likely to be challenged", which is amplified as
All material in Wikipedia mainspace, including everything in articles, lists and captions, must be verifiable. All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material. Any material that needs a source but does not have one may be removed. Please remove contentious material about living people that is unsourced or poorly sourced immediately.
If it's unchallenged, and is not a quotation, and is not a contentious claim concerning a living person, it implicitly satisfies WP:V. It might not satisfy other policies though (not just WP:BLP), but that's not the issue here. --Redrose64 (talk) 08:29, 2 April 2016 (UTC)
Interesting. Is the phrase All material in Wikipedia mainspace, including everything in articles, lists and captions, must be verifiable ambiguous? This is not a matter of choice. The material must be verifiable. Also, Any material that needs a source but does not have one may be removed. Any material that needs a source. This discussion is about a statement relying a source that does not exist (some say it existed in the past, but this cannot be verified). Where exactly is the misunderstanding? 72.43.99.146 (talk) 15:02, 2 April 2016 (UTC)
If a |dead-url=usurped no archive value is added (bad practice btw), then its superset |dead-url=no archive must be added. And then logically, |dead-url= must stop being dependent on |archive-url=. 65.88.88.200 (talk) 14:24, 4 April 2016 (UTC)
And concurrent with this value being added to the parameter, we will get documentation to show us how to verify that an allegedly usurped url is actually usurped, an allegation evident by the inclusion of said url in the citation. Obviously such verification path will be also be immediately evident in the template output, since this is what citations are there for. All right, then. 72.43.99.130 (talk) 17:25, 4 April 2016 (UTC)
Because I don't read any of the above as a definite 'yes, do this' or 'no, don't do this', and so that I can update the live modules, I have hidden the code that supports |dead-url=usurped no archive.
Archive them both someplace? Maybe make a miscellaneous archive into which to dump them? Perhaps Help talk:Citation Style 1/Centralized discussions/Miscellaneous archives? Or, maybe just move them to that folder or one similarly named so that the content doesn't have to be deleted and the original page redirected here.
And while we're talking about archives, can we do away with the enormous {{central}} template and just have a simple box in its place with a link to Help talk:Citation Style 1/Centralized discussions? That box is a big contributor to not landing at the anchor when you click into a section of this talk page.
I already pushed the date validation talk page archives to module talk:Citation/CS1/Archive 12, which is the 'parent' archive, so that's where I was going to put it. However, the two pages /Updates and /Error checking appear to be from the pre-auto-included /doc pages for modules, so I wasn't sure if the content was best "archived" or "incorporated elsewhere". The errors subpage can probably be archived (per Help:CS1 errors), but the Updates page? --Izno (talk) 17:27, 16 March 2016 (UTC)
I would remove the archives templates currently being hosted in the {{central}} invocation but keep the list of redirected pages. What do you think? --Izno (talk) 17:27, 16 March 2016 (UTC)
Nah. Because this page is primarily concerned with current topics, I don't see much reason to keep either of those lists here. We can have the bare-bones {{central}} template here like this:
{{central|text=the talk pages for all Citation Style 1 templates and modules redirect here.<br />A list of those talk pages and their historical archives can be found at [[Help talk:Citation Style 1/Centralized discussions]].}}
To help centralize discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found at Help talk:Citation Style 1/Centralized discussions.
@Redrose64: Hi. Please change "Português" to "Portuguese" that results from invoking Template:Cite act with parameter lang=pt. I don't know how the source code needs to be changed to achieve that result, sorry. Thanks for your time. fgnievinski (talk) 22:47, 10 April 2016 (UTC)
Following discussion at Help talk:CS1 errors/Archive 2#Quarterly date issues, I am raising the issue here of providing support for the use of quarterly date formats in citations. There are publications that use this date format, and I can't see any reason not to provide support for this. Some earlier discussions:
I've been told that an RfC is needed to make this sort of change. Is that really true? Is it not just common sense to add support for a date format that is used a fair amount, even if not widely used? Carcharoth (talk) 16:25, 12 April 2016 (UTC)
Please do not put words into my mouth that I did not speak. I said that it would be best if [WP:MOSNUM] had something more definitive than a single mention (which refers to seasons and not to quarterly dates, per se).
It would be best if WP:MOSNUM succinctly defined how quarterly dates are to be rendered because cs1|2 follow the rules set down there except in the clearly identified cases enumerated at CS1 compliance with Wikipedia's Manual of Style. Quarterly dates could be another such exception. But, support for that proposal did not appear.
The confusing thing here is that people seem to be deferring to MOS and things such as MOS:BADDATEFORMAT, when that explicitly states "Special rules apply to citations; see Wikipedia:Citing sources#Citation style". This rigid adherence to style guidelines with anything out of line throwing up an error is fine, as long as it is recognised that someone using a correct date format should not be told "we don't support that date format". They should be told "Oops, sorry, we will add support for that date format" (and maybe also - "sorry you were told that was an error, it wasn't really, we are just a bit over-zealous in keeping things in order"). The other thing is source integrity. It is important not to fiddle with what the source actually is (and what the publication uses for its dates) in the name of some consistent style. It is more important for people to be able to find the source if they need to, rather than get confused by changes introduced to comply with some style manual. Carcharoth (talk) 17:39, 12 April 2016 (UTC)
c1|2 have become their own styles. They are none of the published styles: Chicago, APA, MLA, <your TLA here>, from which they were created. The 20ish separate independent templates have over time merged into cs1|2. For the sake of consistency across all of the templates, a decision was taken to adopt MOS as the guide for date formatting. This is no different from the the WP:CITE guideline that dictates italic book titles, quoted chapter and article titles, etc.
The 'special rule' that applies to cs1|2 templated citations is that MOS defines how cs1|2 shall render dates. Because MOS is mute on quarterly dates, when I wrote the date validation code, I did not include support for that format. There is no one who champions the cs1|2 documentation so, for the most part, it sucks. But, at CS1 compliance with Wikipedia's Manual of Style it does say:
The proposal to add quarterly dates in spite of MOS has not gotten any real support; it was proposed but, apparently no one cared enough to comment.
I am not writing all of this as a dismissal of the idea. I am on record as supporting it and my opinion has not changed. However, the 'pressing need' has not been voiced so I've been off doing other stuff.
It doesn't matter what MOS 'permits'. Wikipedia citations must cite the date of an issue of a publication the same way that the publication does (e.g. Quarter 1 2016, not Jan-Mar 2016). This is to allow people looking up that publication to find it! What is needed is to stop the error messages when no actual error has been made. It just makes the (otherwise excellent) error-detection system look silly. Carcharoth (talk) 21:53, 12 April 2016 (UTC)
I favor the use of cs1|2 templates but I recognize that it is just a tool suitable for use in most but not all cases. If the tool does not do what it is that you want it to do, don't use it. Nothing compels its use.
Yep, that was the single mention of quarterly dates to which I referred in the other conversation. For the purposes of establishing what constitutes an acceptable quarterly date format for cs1|2, MOS is indeed mute. Consider the amount of detail applied to specifying how dates should look for numeric dates, for DMY, for MDY, for ranges. A lot of words and symbols are spent carefully defining those date formats. Quarterly dates get just that single mention and that mention suggests a format that looks a lot like three of the unacceptable date formats in the unacceptable date formats table. See these unacceptable examples at MOS:BADDATEFORMAT: the 9th of June, July of 2001, the first of May.
MOSDATE is intended to give formats for the kind of dates commonly encountered in running text, tables, and infoboxes. It isn't intended to give formats for dates in citations, but cs1|cs2 found that the formats found MOSDATE were mostly sufficient for citations as well, so borrowed those formats. Since quarters are often found in publications and less frequently found in other parts of encyclopedia articles, it would be appropriate for Help:Citation Style 1 and {{Citation}} to define a format for quarters. Jc3s5h (talk) 22:22, 12 April 2016 (UTC)
Can "Access date" be renamed to "Accessdate", or (at least) "access-date" be renamed to "accessdate"?
Can someone add further description on accessdate as I don’t know if it is OK to enter there date of the access to the archived version or only to date of the access to the URL as stated and bolded right now? Or to introduce new accessdate parameter for archive version URLs (for dead or not dead original URLs, doesn’t matter)? This is important as modules can be changed to display error if accessdate is after archivedate (in case it is not OK to enter the date of access to the archived version but only original URL). Note that several archive websites exist and that some can get broken down so other archive would be needed to archive such archive websites... --Obsuser (talk) 21:33, 15 April 2016 (UTC)
Why?
The URL, not the archive URL. And there's no reason to have an archive URL access date. Your suggestion that "can be changed to display error if accessdate is after archivedate" is precluded on some false notion that this is an error. I can think of no reason why it would be. --Izno (talk) 23:16, 15 April 2016 (UTC)
(edit conflict) Both |accessdate= and |access-date= do exactly the same thing, so editors are free to use whichever they prefer. Or did you mean you wanted the heading "Access date" on the Help page to be renamed?
The purpose of having an access date is to allow later editors to ascertain the version of the web page used as a source. Therefore it should normally remain as the date on which the contributing editor viewed the web page. One exception might be if an editor revises the article at a later date and re-checks the source page. Then it would make sense to update the access date because the page may have changed and the version on the later date would then be the one supporting the article text. If the only version available to a later editor is an archived page, then it does not make sense to update the access date. Does that answer your question? --RexxS (talk) 23:30, 15 April 2016 (UTC)
So it is OK to enter, let’s say, |accessdate=16 April 2016 when some page broke down on 11 April 2016 and was archived on 5 April 2016 (|archivedate=5 April 2016) i.e. it is not accessble via original URL on 16 April 2016 but only archive one?
@RexxS: I understand both |accessdate= and |access-date= do same thing but I guess former is much more used and more correct form. Please see the question above... --Obsuser (talk) 23:39, 15 April 2016 (UTC)
So do you want the header to be changed? We won't be changing the template itself, and the header doesn't need to be changed either, because that's not how English works.
There is no way to programmatically tell that a page can no longer be accessed even if it has an archive, and this change would not change that fact. So no, it's not okay, and yes, that's just fine. I don't see a need to change this functionality either. --Izno (talk) 00:10, 16 April 2016 (UTC)
No, not header (necessarily); only parameter name. I basically asked this: Can accessdate be for access to the archived version when original page URL is broken? --Obsuser (talk) 01:19, 16 April 2016 (UTC)
There's no need to know the date of access to the archived version. The access date tells the reader two things: (1) most importantly, for a site that changes, like an online database, the version that was consulted (2) the likelihood of the URL still being live. Access dates are not needed for archived versions, because (1) they will not change (2) the URL will be live as long as the entire archive is. Peter coxhead (talk) 06:14, 16 April 2016 (UTC)
In response to an earlier question, yes both |accessdate= and |access-date= do the same thing; and yes, the former is much more commonly used - but it is not because it is the "more correct form". The reason for |accessdate= being much more commonly used is simply because |access-date= was added comparatively recently, when it was decided to introduce hyphenated forms for many parameters. They are fully interchangeable, and you may use whichever you prefer. --Redrose64 (talk) 09:04, 16 April 2016 (UTC)
Revised documents?
How to handle revised documents?
<ref>{{cite web| title = LM117/LM317A/LM317-N 3-Terminal Adjustable Regulator| url = http://www.ti.com/lit/ds/symlink/lm117.pdf| date = 2004 May, Revised 2013 August| accessdate = 2013-10-02}}</ref>
{{cite web| title = LM117/LM317A/LM317-N 3-Terminal Adjustable Regulator| url = http://www.ti.com/lit/ds/symlink/lm117.pdf| date = August 2013 | orig-year= originally published May 2004| edition = Revised| accessdate = 2013-10-02}}
Nice proposal, to be sure :). One detail about the multiple names test: in the discussion, you give an example with multiple editors. Shouldn't the role be specified in plural? i.e. (eds.) instead of (ed.). 72.43.99.138 (talk) 13:07, 10 April 2016 (UTC)
No. Because |editor= is singular, the annotation that the module adds is also singular. If the cite uses multiple enumerated |editorn= parameters or |veditors= or |editors= then the module adds the plural annotation.
In this case, it will be likely read as the last name being the only editor, which would be factually and semantically incorrect. 72.43.99.138 (talk) 14:11, 10 April 2016 (UTC)
The singular/plural annotation of the editor name lists is not part of the multiple names test change. The annotation that I described is how the live module currently operates. The change does not modify that. Here is the same example you mentioned modified to use the live module:
{{cite book |title=Title |editor=one, two, three}}
one, two, three (ed.). Title.{{cite book}}: CS1 maint: multiple names: editors list (link)
I see. Then disregard my counterproposal. Is there no way to search for multiple separators in this field and thereby change the annotation to plural? 204.19.162.34 (talk) 15:26, 10 April 2016 (UTC)
There is, the same mechanism that adds the maintenance cat. But the purpose is to reduce or eliminate the semantically incorrect multiple-names-in-a-singular-parameter; not to mask it.
Done. I discovered and fixed a bug in fix archive_url_check(). Archive.org accepts urls in the form https://web.archive.org/YYYYMMDDhhmmss/... This form is remapped to https://web.archive.org/web/YYYYMMDDhhmmss/... which is what the code was looking for so the former caused a timestamp error.
Thanks for that. I've rewritten the function and think that I've fixed the other problem that I hadn't noticed: the flag don't work with the old-style urls. Here's reference 20 using the sandbox:
"La Constitution de 1987, Article 5" [Constitution of 1987, Article 5] (in French). 1987. Archived from the original on 12 September 2011. Retrieved 31 July 2015. Tous les Haïtiens sont unis par une Langue commune : le Créole.{{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
So I didn't get the archive.org url test quite right. There are a handful of variants that I hadn't considered. First there is an old url and a new url. These two are mostly compatible:
Archive.org's servers automatically map old form urls to new form urls so both of the above links will work.
The new form url also supports certain flags or modifiers that can be appended to the url's timestamp. These do not work with the old form urls. Adding the flags to the old form urls will result in a 404 error message:
Maybe we don't care about the exact content of the timestamp flag other than to make sure that it is three characters, two letters and an underscore. For example, this url works even though xx_ is not a valid flag:
It looks like many publishers use the PII as the second part of the DOI. See this helpful page for some explanation. I don't think that page helps in this case, but some additional digging may turn up something useful.
While using the {{PII}} template inside an |id= parameter will do the job, it is more cumbersome than using a dedicated parameter, and might create inconsistent formatting, if more than one id will have to be put into the |id= parameter. Do we put a colon or space (or both) between an id's name and value, or does that depend on the corresponding id? Do multiple ids have to be separated by comma, semicola or full stops, or does that depend on the type of the surrounding identifiers? Adding dedicated parameters for more such ids would help to streamline this (and easily change it, would this become necessary in the future) - and since they aren't all used at the same time it wouldn't add clutter to citations at all, just make life easier for all, authors, maintainers, and readers (even machines, when they try to read ids).
We don't support month ranges and this is unsatisfactory
So right now in the month field it can handle individual months (and seasons) only. That is, it can handle "January", "Jan", and "Summer" (and "Christmas") etc. but cannot handle "January-February" or "January-March" or "January-April" and so forth, and assorted publications do use those publication dates. So this is not satisfactory. It is not satisfactory to have to leave the month blank or put in a false month.
Hmm, coding for each possible month seperator (-, —, :, /, and with and without spaces, and then separate cases for each reasonably possible month combination (January-February, January-March, February-March, etc. etc. etc.) -- this would be require a large hand-written table...
Erm let's see...
Extended coding content
There's no reasons to change function "get_month_number" as it works fine... thinking about the problem I came up with a couple different ways to implement function "get_month_number" which I am NOT suggesting and which I doubt would actually work... these are just byproducts of thinking about ways to find month ranges...
alternate1functionget_month_number(month)legal_months='JanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecember'month_name_loc={1,6,16,21,26,29,33,40,37,56,63,71}month_name_length={7,8,5,5,3,4,4,6,9,7,8,7}start_match,match_length=string.find(legal_months,month)ifstart_match-- we found a month name in the inputfori1=1,12doforj=1,12doifstart_match==month_name_loc[i]-- starting with Januaryifmatch_length=month_name_length[j]-- check input string length against month name lengthreturniendendreturn0alternate2localfunctionget_month_number(month)legal_months='JanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecember'month_name_length={7,8,5,5,3,4,4,6,9,7,8,7}ok=strfind(legal_months,months)-- compare the list of months to the inputifok//-- found a possible good input, still need to make sure its not "uaryFeb" or "a" and so onfori=1to12ifok==a[i]-- if yes, our input matches the start of a legal month name, at leastifstrlen(month)==3returni-- 3 character input, match, its a shorty such as "Jan", we're goodelseifstrlen(month)==month_name_length[i]return(i)-- matching beginning and length of a legal month name, we're goodelse-- we did NOT find a legal month name in the input -- could be garbage, or "January-February"returnfalse
So now lets see.... what if you had... let's assume that month ranges are going to be divided by a dash, hyphen, long hyphen, slash, colon, or space, e.g. "January/April" or whatever (that's not going to cover instances with words or extra spaces, such as "January and February" or "January - February", but let's live with that for now)...
Let's see...
localfunctionis_valid_month_range-- only called if the month has been spit out as illegaltoken{}token[1]='-'token[2]='–'token[3]='—'token[4]='/'token[5]=':'token[6]=' 'fori=1to6dook=strfind(month,token[i])ifok-- we have found one of the tokensmonth_range_start_month=strsub(month,1,ok-1)-- get all of the string before the tokenmonth_range_end_month=strsub(month,ok+1);-- then all of the string after the tokenm1=get_month_number(month_range_start_month))ifm1elsereturnfalse-- if ok so far, do nothingm2=get_month_number(month_range_end_month))ifm2elsereturnfalse-- if still ok so far do nothingifm2>m1returntrueelsereturnfalse;-- still ok? we're goodendreturnfalse-- never found a token
Wouldn't this work? You find a token such as "/"... you send the (already existing) function "get_month_number" all of the original string before the token, and (if that's accepted) all of the original string after the token, and if that's accepted you must have a "legal month name" and "token" and "legal month name"... then check to make sure the range is not "December-December" or "December-March" (which is possible, but would require two years in the years field which I don't think we accept or probably need to)...
All right, that was fun, I haven't written code in decades, and I'll bet that there are many bugs, errors, and impossibilities there, but couldn't something sort of like that work? Herostratus (talk) 00:52, 11 April 2016 (UTC)
@Herostratus: the templates do support month ranges that comply with the MOS:
Author (January–February 2016). "Article". Journal. {{cite journal}}: |author= has generic name (help)
Author (Mar–Apr 2016). "Article". Magazine. {{cite magazine}}: |author= has generic name (help)
As most keyboards don't have proper dashes, and picking a dash off the menu is irksome for those of us who generally prepare text off-line, couldn't we have the software simply replace hyphens found in date ranges with the preferred en-dash? Rather than failing with a message to text that doesn't quite explain what the problem is. ~ J. Johnson (JJ) (talk) 19:47, 12 April 2016 (UTC)
I support this as well. It is not a good idea to depend on special character support not available or difficult to use (input or display) in some environments, so there should be a fall-back using only ASCII characters. The easiest solution I see is to allow a "-" to work as an alias and let the template convert it to the desired character for display. --Matthiaspaul (talk) 20:18, 18 April 2016 (UTC)
Can someone look into the CS1 maint checks. This template has recently been complaining about "CS1 maint: Multiple names: authors list" AngusWOOF (bark • sniff) 13:42, 19 April 2016 (UTC)
Cite tweet uses cite web to format citations, and in the case of an author name and twitter username, passes them through as {{cite web |author={{{author}}} [{{{user}}}] | ... }}, which has recently started throwing up the maintenance message. Here's an example:
Cite web comparison
Wikitext
{{cite web|author=Real Name [username]|title=Tweet contents|url=https://twitter.com}}
Live
Real Name [username]. "Tweet contents".{{cite web}}: CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
Sandbox
Real Name [username]. "Tweet contents".{{cite web}}: CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
The multiple author test is reacting to the semicolon that ends the html entities. Do you have an example of a {{cite web}} that won't accept plain brackets in |author=? Here is the example from your {{cite compare}} but intead of html entities it uses plain brackets. No error message:
{{ cite web | title=Tweet contents | url=https://twitter.com | author=Real Name [username]}}
In January this year, the template started having "Check |author-last1= value" errors. The help message said "make sure that there are no illegal characters in the paired parameters", and encoding the square brackets got rid of that error message (discussion). The error checking code seems to have changed since then, as the above example isn't producing the error message, so I guess we can go back to unencoded square brackets. - Evad37[talk]02:40, 20 April 2016 (UTC)
With regards to Help:CS1_errors#bad_paramlink: From playing around with different combinations, it looks like the "Check |param= value" now only comes up when there is a wikilink in param= AND param-link= is also specified. Eg.
{{cite book |title=title |author=[[Author]]: Author. title. {{cite book}}: |author= has generic name (help) → no error message
{{cite book |title=title |author=[[Author]] |author-link=Author }}: Author. title. {{cite book}}: |author= has generic name (help); Check |author= value (help) → error message
{{cite book |title=title |author=[http://example.com Author] }}: Author. title. {{cite book}}: |author= has generic name (help); External link in |author= (help) → no error message
{{cite book |title=title |author=[http://example.com Author] |author-link=Author }}: [http://example.com Author]. title. {{cite book}}: |author= has generic name (help); External link in |author= (help) → no error message
and the characters special characters < [ { } ] > don't actually need to be encoded: {{cite book |title=title |author=Author <{Author}> |author-link=Author }}: Author <{[Author]}>. title. {{cite book}}: |author= has generic name (help) → no error message
Yes and perhaps no. The test is really supposed to be catching inappropriate wikimarkup in the |<param>-link= parameters. For your examples:
no |author-link= so no error
correct
this is not something we test for but could. It is the same test as the External link in |<param>= which only looks at |title=, |chapter=, |work=, and |publisher=.
same
Because |author-link= is supposed to hold the title of an article, the illegal characters test applies to it not to |author= (this is why #3 and #4 do not show errors):
{{cite book |title=title |author-link=Author <{[Author]}> |author=Author }}: Author. title. {{cite book}}: |author= has generic name (help); Check |author-link= value (help) → error message
and this is the case that caused us to invent this error detector:
{{cite book |title=title |author=Author |author-link=[[Author]] }}: Author. title. {{cite book}}: |author= has generic name (help); Check |author-link= value (help) → error message
Trappist the monk you used as justification for turning on logging of this "error" on some obscure sentence in Help:Citation Style 1#Work and publisher " If the publisher is notable and has an article independent of the "work", the "publisher" parameter can include a wiki-link to that article, but should never externally link to the publisher's website."
So I suggest unless there is a clear consensus to the contrary (and I do not mean two or three comments here) that this "rule" is removed and not acted upon until such time as an RfC is run that shows that this is a prohibition that has a consensus. -- PBS (talk) 14:13, 19 March 2016 (UTC)
I think a change 4 years old can reasonably be construed as WP:SILENCE. The thread that Jc3s5h started had nothing to do with the December 16 change. --Izno (talk) 16:11, 19 March 2016 (UTC)
FWIW I agree with both SMcCandlish's addition and Trappist's software check. I think this is an error (or, sometimes, not so much an error as intentional spam) and should be flagged as an error. —David Eppstein (talk) 18:08, 19 March 2016 (UTC)
@Izno I disagree there are/were hundreds (thousands?) of such links in the citation templates. This obsucre "rule" was ignored until forced into the open by a software change. There is a underlying assumption of bad faith in this rule. In fact a link is more useful, (for readers and editors), for a less notable publisher than for a notable one. If an editor sees that the publisher is known to "someone familiar with, although not necessarily an expert in, the subject area will recognize" (to borrow a phrase from WP:AT) then a link to the publisher is not necessary. Ie if the publisher is notable, well known and reliable, (eg "Oxford University Press") then one leg of the three legged stool concerning "sources" in WP:V is met:
The word "source" in Wikipedia has three meanings:
The type of the work (some examples include a document, an article, or a book)
The creator of the work (for example, the writer)
The publisher of the work (for example, Oxford University Press)
All three can affect reliability.
In cases such as "Oxford University Press" then a link is not needed to help an citation meet the requirements of WP:V. However Including a convenience link to a less well known publisher's website allows readers and editor to asses more easily if a less than notable publisher is reliable. This is the reason I include links to the "about page" non-notable publisher—particularly if the source being cited is a website. It has nothing to do with spam and is not as David Eppstein suggests an error. -- PBS (talk) 11:46, 25 March 2016 (UTC)
Get consensus for your suggested change. Myself, David, SMC, Keith D all obviously agree with the test, Jonesey95 voiced no disagreement when Trappist indicated that this may be an issue, and Trappist either agrees or at least believes that it should be enforced in the software. So, if you would like it to change, WP:RFC is how you're going to get what you want, though with at least 4 people lined up to disagree with you, good luck. Responding to your comment in-full:
link is more useful, (for readers and editors), for a less notable publisher than for a notable one I do not dispute this. I dispute that it is necessary to link to the publisher, and in the same field as the publisher. My concern certainly would be in use of a less well-known publisher per what a reliable source is.
Transliteration parameter "quote=" needs a complementary trans-quote=
The "|quote=" parameter would really need a complementary "|trans-quote=" such that readers and editors don't need to translate everytime they need to understand the reference. This also aids in preserving a good translation instead of an impromptu one that easily looses the real meaning. Bytesock (talk) 00:37, 19 April 2016 (UTC)
Perhaps you mean 'translation'? Regardless, |quote= is a free-form parameter so its content is not restricted. That means you can include both the original and the translation in the same parameter. Keep it brief. If the quote is lengthy, consider putting it in an end note and referencing that.
While |quote= is a free-form parameter, which would accept translations as well, providing a dedicated |trans-quote= parameter would help enforcing a consistent format and allow us to adjust the format centrally would this become necessary in the future. At present, I would suggest to just put the translation in [square brackets] following the original quote, but who knows what might be preferable in a decade (perhaps we're using colors, or we would want to suppress one but not the other information depending on output device, speech output?), so I think it's generally best to keep logically separable info in separate parameters (this applies to a number of other parameters as well). --Matthiaspaul (talk) 23:24, 22 April 2016 (UTC)
Suggested further date checks
Having worked on fixing date errors for some time I have a few suggestions for improving the checking that takes place in the templates. Keith D (talk) 22:09, 21 April 2016 (UTC)
Acessdates
Accessdates are supposed to show the full date the item was accessed so the check should be tightened to allow only single full dates.
This seems too picky to me. Knowing the month when a web page was accessed is almost always adequate, if it is even necessary. – Jonesey95 (talk) 03:58, 22 April 2016 (UTC)
While such consistency checks can help locating typos, transmission errors or faked info, we must be very careful to not overdo them. There should always be a way to disable such checks to cope with the (probably not many) cases where a check would give false positives.
To give an example, I remember a case where I provided a reference based on a document I had downloaded from the net as part of a ZIP archive years earlier. I had a copy of the extracted document, and the download url was given in the document itself, but I was unable to narrow down the exact download date because I had long deleted the ZIP archive. Correlating other info I was at least able to specify the year I downloaded the file, so that's what I used for access-date. I found it particularly important to specify at least the year, since the file was no longer available online and wasn't archived at archive.org.
So, basically, a reasonable plausibility check would have to take the distance between the citation edit date and the online access-date into account as well (f.e. allow to omit the day if the access was not in the same month, and allow to omit the month if the access was in another year). Since the edit date isn't information stored in a citation, and because we cannot put the burden of rechecking the accessibility of all existing references whenever an article gets edited on all future article editors, ruling out abbreviated access-dates would be feasible only if there would be a way to override the check as well.
Otherwise, if year-only access-dates would no longer be allowed, we'd be forced to omit vital information or "invent" dates such as yyyy-01-01 or yyyy-12-31 in such cases - not a good idea IMO.
This is not sensible--why does it matter whether they are in the template in a particular order?--nor do I think the template can even detect which comes first. --Izno (talk) 01:22, 22 April 2016 (UTC)
Perhaps not the actual order in the wikicode, but consider the chronological order. How can you access a source on 12 June 2015 that wasn't published until 12 April 2016, some 10 months later? That would be quite sensible, IMHO. Imzadi 1979→01:45, 22 April 2016 (UTC)
Ah, see, I interpreted that wrongly. I would have a 1-7 day tolerance on the delta, but otherwise, I agree that would be a good test. (I think we have a similar test with a 1 day delta e.g. accessdate up to 1 date prior to publication date.) --Izno (talk) 02:29, 22 April 2016 (UTC)
I don't think this will work as proposed. Magazines, for example, are published with future dates, i.e. the "May 2016" print issue might be published (and posted on the web with that date) in February or March 2016. There may be some value in checking for dates that are too far apart. – Jonesey95 (talk) 03:58, 22 April 2016 (UTC)
Format consistency
Ignoring the all numeric ISO style dates, all of the other date fields in a cite should be in the same format. All using short or long months and all either day first or month first format.
Actually, also this caveat from Help:CS1#Dates: Access and archive dates in references should be in either the format used for publication dates, or YYYY-MM-DD. Which I expect is what is meant by "ignoring the all numeric ISO style dates"? --Izno (talk) 02:32, 22 April 2016 (UTC)
I think this proposal needs to be more specific. What about date=April 2016 | access-date = May 1, 2016 or date=2016 | access-date = May 1, 2016? That would fail the above test, but it is perfectly valid when the source is dated "April 2016" or "2016", with no day, or even month, provided. – Jonesey95 (talk) 03:58, 22 April 2016 (UTC)
Templates {EB1911} and {Cite EB1911} for parameter 1
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Recently there have been many pages using {{EB1911|pagename}} with parameter 1 intended as "title=pagename" or also {{cite EB1911}}. However, other changes to those templates keeping rejecting parameter 1 as error: Text "pagename" ignored. There has been just enough confusion so that it worked ok for a while, and people used {EB1911|page} many times to get "{cite encyclopedia|title=page|...}" but now is broken again. People seem to want to use {EB1911|page}, and so I think it should work again. Any plans? Wikid77 (talk) 21:49, 24 April 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Subscription required, but offers limited free views
In some website citations, I've found they offer a handful of "free views" before locking it down with subscription required. How should this be handled? Mark it as subscription=yes? AngusWOOF (bark • sniff) 20:21, 27 April 2016 (UTC)
There was some discussion on this a while back. I don't remember a consensus viewpoint emerging. My take on this is that the contributor should take the prudent step of indicating the source is not free. Because there is no certain method that can predict when the free-views promotion/allowance will end. Personally again, I may also add a {{link note}} indicating that there may be limited free views. This may depend on date of access. So that date should be indicated, either in the template, or explicitly in the note if the template does not require |access-date= (as is the case with doi links, for example). 72.43.99.146 (talk) 23:50, 27 April 2016 (UTC)
With all the noise about WP:CITEVAR and adhering to the established/consistent presentation style for citations, it would be prudent to caution editors wishing to consistently use CS1 that some of the specific-source templates may violate that wish. Or add some basic compliance criteria that specific-source templates must follow in order to be included to the category. 65.88.88.214 (talk) 19:48, 26 April 2016 (UTC)
The older definition of what it is that constitutes a cs1 template included both Module:Citation/CS1 and {{citation/core}}. I recently removed {{citation/core}} from the definition at H:CS1#Style but perhaps I was a bit hasty. Clearly, {{cite IETF}} and {{cite wikisource}} use {{citation/core}} so, by the old definition, these two at least, are cs1 compliant.
That being the case, we should probably restore {{citation/core}} to the definition.
Off-hand, do you know/have any idea whether templates built on {{citation/core}} would display differently than templates built on the Lua module? Since CS1 is an exercise on arriving at a uniform style. 72.43.99.146 (talk) 00:11, 27 April 2016 (UTC)
When the Lua version was developed the initial goal was to make it render its output for a particular template in the same way that the {{citation/core}} version rendered. For the most part, that has held true but changes were and have been made since the last {{citation/core}}-rendered template was integrated into Module:Citation/CS1. You can use {{cite compare}} to see how similar or different the renderings old v. new are.
For the specific-source templates, there is no such simple tool. But, since the 'style' for cs1 is periods for element separator, period for terminal punctuation, semicolon for author separator, static text in sentence case, and automatic CITEREF creation disabled, 'compliance with the 'style' can be determined by inspection. It may, though, be necessary to read the code because it is possible that these specific-source templates misuse {{citation/core}} parameters to achieve certain visual effects; this was true in some of the cs1 templates so you will sometimes see a different ordering of the citation elements when comparing the module rendering to that of {{citation/core}}.
The parent page states, "There are a number of templates that are CS1 compliant, because they use a CS1 template as a base," (H:CS1#Specific source) and then links the cat, but not all of these templates are based on a CS1 template. And as you stated above, basing a specific-source template on a general-use template may or may not make it compliant. 65.88.88.126 (talk) 14:50, 27 April 2016 (UTC)
{{cite IETF}} and {{cite Wikisource}} are cs1 if we restore the {{citation/core}} rule; {{cite QPN}} is cs1 even though it uses {{citation}} (cs2) because it sets |mode=cs1; {{yahoo maps}} is cs1 because it uses {{cite map}}, a cs1 template; {{BoM Aust stats/sandbox}} (and its parent) is cs1 because it uses {{cite web}}, a cs1 template. Don't really care about the subpages – there is code in a lot of template doc pages that will exclude these kinds of pages from the category; it's just a matter of hunting it down.
According to H:CS1, {{cite QPN}} is not compliant, because it is not based on a cs1 template (the only current requirement). The relevant section says nothing about display mode/delimiters. So either the help page has to be edited, or the specific-source category. 65.88.88.126 (talk) 19:07, 27 April 2016 (UTC)
{{yahoo maps}} has only been deprecated because the website was shut down almost a year ago. All articles using it as a source need to have it replaced with some other source going forward, which has been a slow process. Imzadi 1979→19:49, 27 April 2016 (UTC)
And you don't think that keeping it in this category is confusing regarding its status?
Would you say some minimal quality control may be needed before templates are put in CS1-related categories? The haphazard inclusion does not reflect nicely on CS1 as a whole. Which is no big deal, but there are enough micromanagers around to blow up this issue, like the interminable RFC discussion at Wikipedia talk:Citing sources regarding template coding – an issue that I wager is lost to 90% of editors, let alone Wikipedia readers, who will likely see no effect whichever way. And this RFC seems likely to spawn more RFCs, and even more esoteric ones. 72.43.99.146 (talk) 00:08, 28 April 2016 (UTC)
@72.43.99.146: it's still a CS1-based, specific-source template. Once the last 90 articles are switched over, it will be nominated for deletion. Until then, it still meets the two facets for that category, namely it uses CS1 and it's a template for a specific, albeit no-longer-existant, source. Imzadi 1979→06:04, 28 April 2016 (UTC)
