Help talk:Citation Style 1/Archive 36

Question mark at the end of ref
There seems to be an issue at United States presidential election, 2020 with question marks showing up right after a ref. See this. Callmemirela  &#127809; talk 17:30, 10 August 2017 (UTC)
 * Not a cs1|2 problem. There is a stray invisible character after the last Mark Cuban reference: a delete character U+007F (you can 'not' see it between these arrows: →← in the wiki source for this comment).  Delete that stray character at United States presidential election, 2020 and no question mark.
 * —Trappist the monk (talk) 18:09, 10 August 2017 (UTC)
 * Thank you!  Callmemirela   &#127809; talk 21:17, 10 August 2017 (UTC)

Handling sites that have become malicious
The site www.heritage-history.com in July was promoting fake tech support. That problem seems to have gone away, but now the https version of the site has an invalid security certificate. Whether heritage-history has been taken over by bad guys forever, or they are somehow able to resolve their problem, this point up a need to be able to cite an archive of a site without having the citation contain a link to the original site, so as to minimize the risk that readers will click the link and arrive at a malicious site.

See Military history of Italy for an example of an offending link. Jc3s5h (talk) 13:36, 4 August 2017 (UTC)
 * usurped or unfit
 * —Trappist the monk (talk) 13:58, 4 August 2017 (UTC)


 * The parameters values usurped or unfit are not described on the help page. I don't use undocumented parameter values. Jc3s5h (talk) 14:07, 4 August 2017 (UTC)


 * I see partial documentation at Template:Cite web/doc, but it does not make clear if the value of the url parameter should be the link to the malicious site, or should just be  Jc3s5h (talk) 14:13, 4 August 2017 (UTC)
 * If a parameter is documented at any of the cs1|2 template pages, it is documented. You are free to improve the cs1|2 documentation so please do.  The documentation does say "setting usurped or unfit suppresses display of the original URL (but url is still required).'  You will discover that omitting url or leaving url blank will get the  requires  .  Again, you are free to make the documentation better.  Please do so.
 * —Trappist the monk (talk) 15:05, 4 August 2017 (UTC)


 * I don't want to test this on a live article. What if the malicious site has already been added to the spam blacklist before the attempt to add the  parameter. Wouldn't it be impossible to perform the edit with the offending URL still present? Jc3s5h (talk) 15:47, 5 August 2017 (UTC)
 * If blacklist will prevent page-save, there is no problem, right? And even if blacklist does not prevent the page-save, undo is your friend.  For those cases where blacklist prevents page-save, url can be set to an innocuous site, perhaps https://www.example.com with unfit, and archive-url & archive-date as appropriate for the archive copy and then original url blacklisted added at the end of the cite.
 * —Trappist the monk (talk) 10:34, 6 August 2017 (UTC)

Proposed revision to "Usage" text
The current "Usage" subdocument currently reads, "Copy a blank version to use. All parameter names must be in lowercase. Use the "|" (pipe) character between each parameter. Delete unused parameters to avoid clutter in the edit window. Some samples may include the current date. If the date is not current, then purge the page."

I would like to change this to, "You may copy a blank version to use. All parameters are optional except the  parameter.  Parameter names must be in lowercase or will not be recognized. A "|" (pipe) character must be placed between each parameter. You should delete unused parameters to avoid clutter in the edit window. Some samples may include the current date. If the date is not current, then purge the page."

Thoughts? Objections? KDS4444 (talk) 03:25, 13 August 2017 (UTC)
 * "All parameters are optional except the  parameter" is not true. For example, url is required if access-date is used, and last2 is required if last1 last1 is required if last2 is used. Look at the "Prerequisites" section of the cite journal documentation for more requirements, and also read the explanation of title parameter requirements at . – Jonesey95 (talk) 15:55, 13 August 2017 (UTC)
 * That would be last is required if last is used, right?
 * Perhaps that text in (and so Help:CS1 errors) needs revisiting.  Certainly title is a requirement except in  where book-title can be used.  Otherwise, chapter, article, contribution, entry, and section cannot stand alone as titles.  It was once true that they could but that has.
 * —Trappist the monk (talk) 17:08, 13 August 2017 (UTC)
 * —Trappist the monk (talk) 17:08, 13 August 2017 (UTC)

Using names of months
i have two connected problems on Cite news on cywiki: 1. When I copy this most recent version to our older module on cywiki, it causes an error which I'm unable to correct and 2. The date format on cywiki is always dd name of month yyyy (eg 19 Gorffennaf 2017), but as you can see on cy:Alfred Russel Wallace we can only use yyy-mm-dd (eg 2017-07-19). Any help would be warmly received! Llywelyn2000 (talk) 04:40, 22 July 2017 (UTC)
 * What is "an error which I'm unable to correct"?
 * Does the date format problem only happen with cy:Template:Cite news, or does it affect cy:Template:Cite web as well? Is it only the access-date parameter, or date as well? What happens if you use English-language dates like 19 July 2017 - does the problem disappear? -- Red rose64 &#x1f339; (talk) 08:30, 22 July 2017 (UTC)

I'm also perplexed. You said this most recent version by which I would expect the 28 May 2017 version of the module suite. But, at cy.wiki, the date there looks to be 26 May 2016.

The access-date validation at cy.wiki does not work because the MediaWiki time parser does not understand non-English month names. Try this in your sandbox at cy.wiki:

then try this:

you should get:

Because this problem exists in all non-English wikis, all versions of the module suite since 30 July 2016 have a fix for the problem.

What is your intent? Do you want to just fix your version of your older fork of the module suite? Do you want to the cy.wiki module suite to track the en.wiki modules?

I can see that someone has copied en:Module:Citation/CS1/Date validation/sandbox to cy:Modiwl:Citation/CS1/Date validation/sandbox, changed the month names to Welsh and then reverted. I would not recommend ever taking the en.wiki sandbox versions of the module suite; they are never guaranteed to be working. You should, instead, take the current live version into your sandboxen and make sure that whatever changes are required to suit your particular language are made first there before upgrading the live versions.

—Trappist the monk (talk) 11:59, 22 July 2017 (UTC)


 * Many thanks to both of you. I've reproduced the problem here. I managed to translate the months, so we're partly there! - I've also added your bits; the Welsh one doesn't work. Intent - to enable any form of input to produce our usual format (27 Mai 2017). Thanks again! Llywelyn2000 (talk) 05:53, 24 July 2017 (UTC)
 * The dates rendered in the citation at test 1 are (for me): 2017-07-19 and Adalwyd 2017-07-19. I see no 19/07/2017 in that page except where you write that the dd/mm/yyyy style is not used on cy.wiki.  Test 1 apparently shows that the module suite is working correctly; can't fix it if it ain't broke.
 * The reason for the failure of test 2 is described above and confirmed by the results of test 3.
 * Intent - to enable any form of input to produce our usual format (27 Mai 2017). Do you mean that you want the module suite to automatically reformat dates in mdy and ymd formats to dmy format?
 * —Trappist the monk (talk) 10:17, 24 July 2017 (UTC)
 * Intent - to enable any form of input to produce our usual format (27 Mai 2017). Do you mean that you want the module suite to automatically reformat dates in mdy and ymd formats to dmy format?
 * —Trappist the monk (talk) 10:17, 24 July 2017 (UTC)


 * I'm not making myself clear! Sorry, i'll try again:
 * Test 1 - should produce '19 Gorffennaf 2017'; as you say, the module should reformat to our accepted format
 * Test 2 - should not have that error at the end (Check date values in: |access-date= (help))
 * Test 3 - should allow the input to be in Welsh (5 Ebrill 2007); at the monment it creates an error 'Gwall: Amser annilys'.
 * Thanks! Llywelyn2000 (talk) 16:10, 28 July 2017 (UTC)
 * At test 1 you write this: If we input the date as 2017-07-19... what we get is 19/07/2017. I don't see that. Here is a copy paste of the rendered citation I see:
 * "Gwerthu llythyrau’r Cymro oedd yng nghysgod Charles Darwin". Golwg 360. 2017-07-19. Adalwyd 2017-07-19.
 * 19/07/2017 is not part of that rendering. I don't know how you can be seeing a dd/mm/yyyy date format; that is not something that the modules produce.
 * Test 3 does not test the cs1|2 modules; it tests the MediaWiki  parser function.  It is not possible for us to fix that here.  See T21412.
 * Test 2 fails because of the problem illustrated in test 3. I have explained that newer versions of the cs1|2 module suite have overcome that problem.  My recommendation to you is to do these things:
 * import the current version of the live modules (all of them) from en.wiki into their appropriate sandboxen at cy.wiki
 * modify the sandboxen as appropriate to suit the Welsh language (most will not require modifications I think)
 * test to make sure that the sandbox suite works
 * overwrite the current live version with the sandbox version
 * Automatic date reformatting is not something that the cs1|2 modules have ever done. At en.wiki df allows us to do date reformatting on a citation-by-citation basis.  And that works at cy.wiki, but not correctly (it renders English month names).  I believe that I know a solution to that which would enable automatic date reformatting and, as a side benefit, enable automatic translation of English month names into the local language month names.  I'm interested in exploring that but am not interested in retrofitting it into older versions of the module suite.  Cy.wiki would be a good test-bed but it must be upgraded first.
 * —Trappist the monk (talk) 10:41, 29 July 2017 (UTC)
 * The rendered reference for test 1 is wholly italicized. It should not be.  This is because user agents (browsers) apply default italic styling to the  tag that wraps the citation.  Wherever it is that cy.wiki handles site-wide styling, you can add this:
 * Automatic date reformatting is not something that the cs1|2 modules have ever done. At en.wiki df allows us to do date reformatting on a citation-by-citation basis.  And that works at cy.wiki, but not correctly (it renders English month names).  I believe that I know a solution to that which would enable automatic date reformatting and, as a side benefit, enable automatic translation of English month names into the local language month names.  I'm interested in exploring that but am not interested in retrofitting it into older versions of the module suite.  Cy.wiki would be a good test-bed but it must be upgraded first.
 * —Trappist the monk (talk) 10:41, 29 July 2017 (UTC)
 * The rendered reference for test 1 is wholly italicized. It should not be.  This is because user agents (browsers) apply default italic styling to the  tag that wraps the citation.  Wherever it is that cy.wiki handles site-wide styling, you can add this:
 * The rendered reference for test 1 is wholly italicized. It should not be.  This is because user agents (browsers) apply default italic styling to the  tag that wraps the citation.  Wherever it is that cy.wiki handles site-wide styling, you can add this:

/* Reset italic styling set by user agent */ cite, dfn {   font-style: inherit; }
 * (may require some consensus). Alternately, we can edit cy:Module:Citation/CS1/Configuration to locally override the default.  A site-wide solution would be preferred I suspect.  I don't know where cy.wiki keeps its site-wide css; if you cannot find it, I suspect that there are editors at WP:VPT who can help.
 * —Trappist the monk (talk) 11:19, 29 July 2017 (UTC)

- Many thanks for your work on this! I have a lot of work to do! I'll get back to you in a millennium or two! Llywelyn2000 (talk) 08:38, 14 August 2017 (UTC)

Ongoing &#x3C;references &#x2F;&#x3E; discussion at WP:VPPR
The village pump discussion about modifying &#x3C;references &#x2F;&#x3E; into columns is still ongoing. I invite you to comment there. --George Ho (talk) 09:58, 14 August 2017 (UTC)

Using OAdoi
According to https://peerj.com/preprints/3119v1/, nearly 50 % of the papers people look for (usually more recent publications) are available in some form of open access, even without counting academic social networks. Perhaps we should point all DOI links to https://oadoi.org/ instead of https://doi.org ? It's clearly a better service if people get to an URL where they can actually access the resource, and oadoi.org (used by hundreds of libraries already) redirects to doi.org if it doesn't know a better destination URL than the publisher-provided one. Alternatively, we could keep a double link, but I think we already provide too many overlapping links. --Nemo 05:31, 13 August 2017 (UTC)
 * Previous discussion.
 * —Trappist the monk (talk) 09:10, 13 August 2017 (UTC)
 * Thanks. The situation evolved in the latest few months though, to the point oaDOI is becoming the de facto main DOI resolver for many institutions (being also included in Web of Knowledge: ). If we wanted to be standard-compliant we would (only) display the "doi:" pseudo-protocol, instead we prefer to provide links which are useful (as CrossRef rightly recommends for its own dx.doi.org/doi.org).
 * Automatically linking the best PDF available is better than requiring users to edit articles and hardcode URLs or identifiers. --Nemo 22:41, 14 August 2017 (UTC)


 * Hi ! I would be surprised to see this happen, for the same reasons as the one pointed out in the previous discussion. Resolving errors are still possible (and in fact, likely, as the service relies on screen scraping). In terms of policy, even running OAbot as a bot was controversial, because a mass addition of CiteseerX links would violate WP:ELNEVER (see the discussion here). Switching the DOI resolver to oadoi.org would do that at a much larger scale and is therefore likely to face the same backlash. As I wrote earlier, I think this policy is out of touch with the current practices, but it seems quite hard to change it.
 * But there are even practical reasons why switching the DOI resolver would be a problem. Consider the following citation:
 * If we decide that the DOI is resolved by oadoi.org like this, then the two links will likely point to the arXiv: that is redundant. What if the reader actually wants to access the publisher's website instead? (Sometimes the documents are slightly different, for instance.) So we would need to have two links, one for doi.org and one for oadoi.org, but I agree that would be quite heavy (and useless in many cases, if not most).
 * − Pintoch (talk) 07:24, 15 August 2017 (UTC)
 * Note that we could still have something like oadoi that would provide that functionality. But first we need to get that autolinking feature implemented, so when we have free, we get the doi link on the title. Headbomb {t · c · p · b} 15:38, 15 August 2017 (UTC)
 * Note that we could still have something like oadoi that would provide that functionality. But first we need to get that autolinking feature implemented, so when we have free, we get the doi link on the title. Headbomb {t · c · p · b} 15:38, 15 August 2017 (UTC)

Edit request to setup or track CS1/Arguments module documentation
Please create Module:Citation/CS1/Arguments/doc with Improve documentation (or better) for maintenance category tracking. I've already created Module talk:Citation/CS1/Arguments/doc and redirected here. The documentation page to be created will appear at Module:Citation/CS1/Arguments and will categorize into Category:Templates with missing or incorrect documentation.

It is not semi-protected per se, but anonymous contributors can't create new pages to module namespace. 2001:2003:54FA:D2:0:0:0:1 (talk) 20:14, 16 August 2017 (UTC)


 * Amending the request: Please do the same for Module:CS1/doc. I've redirected Module talk:CS1/doc here. (The faith of Module:Citation/doc and Module talk:Citation/doc are a bit unclear to me.) 2001:2003:54FA:D2:0:0:0:1 (talk) 20:31, 16 August 2017 (UTC)
 * Why, regarding Module:Citation/CS1/Arguments? The submodule is unused. --Izno (talk) 21:05, 16 August 2017 (UTC)
 * And, in fact, is documented at Module:Citation/CS1/Whitelist. --Izno (talk) 21:06, 16 August 2017 (UTC)
 * Would do better then? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:51, 16 August 2017 (UTC)
 * I don't know these modules very well. I noticed it has a lot of Lua code, doesn't have documentation and hasn't been marked as deprecated or unused. If it's really unused, should it be nominated for MfD? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:51, 16 August 2017 (UTC)
 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. (Seeking wider consensus first.) 2001:2003:54FA:D2:0:0:0:1 (talk) 21:56, 16 August 2017 (UTC)

Citing podcast episodes by number
I am trying to cite a particular episode of a podcast using cite podcast but I am having trouble getting the episode number to come out: comes out as The obvious solution from the documentation is to use 50 but that isn't showing up in the output: where am I going wrong? TIA HAND —Phil | Talk 13:47, 18 August 2017 (UTC)
 * At Help:Citation Style 1 there is a table that shows that does not support volume, issue, or page(s).  The discussion that created that table is here.  There was no discussion of.


 * Were it me, I would write the title of your podcast as it actually appears on the podcast's website:
 * —Trappist the monk (talk) 14:39, 18 August 2017 (UTC)
 * I agree with Trappist. As far as I can tell, podcasts are numbered by episode only in their titles. When I look at a podcast's metadata in my feed, there is no "episode" attribute or field. – Jonesey95 (talk) 14:48, 18 August 2017 (UTC)
 * —Trappist the monk (talk) 14:39, 18 August 2017 (UTC)
 * I agree with Trappist. As far as I can tell, podcasts are numbered by episode only in their titles. When I look at a podcast's metadata in my feed, there is no "episode" attribute or field. – Jonesey95 (talk) 14:48, 18 August 2017 (UTC)

Suggestion - Add one sentence to the Cite web template documentation
I recently asked this question in the (very helpful) Teahouse: In a website citation, if the web page title is in ALL CAPS, should we keep it that way? The answer: No, change it to title case.

I had searched for the answer prior to asking it in the Teahouse, including reading the template documentation for cite web. The cite web template documentation, under 3. Parameters > 3.4 Description > 3.4.2 Title, explains: "title: Title of source page on website. Displays in quotes."

My suggestion is to add this sentence:


 * Also see: Help:Citation Style 1

I defer to your collective wisdom if this is a worthwhile addition. It would have helped me, and I did find the answer via the Teahouse.

Thanks! - Mark D Worthen PsyD  (talk)  06:39, 20 August 2017 (UTC)


 * That's a good suggestion, but doesn't 3. Parameters > 3.4 Description > 3.4.2 Title already have a hatnote just above the line you quoted, directing readers to the passage you're suggesting? – Margin1522 (talk) 02:40, 23 August 2017 (UTC)

template:cite encyclopedia
The parameter  isn't displaying properly in cite encyclopedia. I've had to switch to cite web when citing limited access sources. The template talk page redirects here for some reason. Pariah24 (talk) 22:44, 26 August 2017 (UTC)
 * Most of the talk pages for the templates like, , , etc. redirect here, because they share a lot of code, and problems in one almost always mean problems in some or all of the others. So to avoid pointless duplicated change requests, we have centralised them here. -- Red rose64 &#x1f339; (talk) 08:51, 27 August 2017 (UTC)
 * url-access doesn't work with, , , or because there is no chapter-url-access (and aliases).   and the others, except , internally promote title and url to chapter and chapter-url so that the title may be rendered in quotes.  Because there is no chapter-url-access, url-access cannot be similarly promoted.


 * I have hacked the module sandbox to add chapter-url-access so that url-access is also promoted.
 * chapter-url-access has the same rules as url-access.
 * chapter-url-access has the same rules as url-access.
 * chapter-url-access has the same rules as url-access.


 * The new chapter-url-access allows works with :
 * —Trappist the monk (talk) 10:28, 27 August 2017 (UTC)
 * —Trappist the monk (talk) 10:28, 27 August 2017 (UTC)
 * —Trappist the monk (talk) 10:28, 27 August 2017 (UTC)

Change for Help:Citation Style 1
I suggest changing "Note that access-date is the date that the URL was checked to not just be working..." to "Note that access-date is the date that the URL given in url (or archive-url, if real URL is dead) was checked to not just be working...". This is because several months ago, I asked someone whether access date can refer to the archive-url or no, and the answer was (as I remember) no – but this is weird because case when there is no access date parameter at all and someone updates article or its references by adding access dates and checking URLs to fix dead ones is possible (so added accessdate can apply for accessing archived version of original URL, which [archived one] can be considered completely valid and generally same [relative to the original one], especially if from web.archive.org). Proof that there are such cases is that access date is chronologically after archive date (i.e. date URL became dead) in many cases already; even tracking cat for such cases might be introduced but it wouldn't be for URLs accessed after they became dead (because we cannot know this) but only to know for cases where access dates is after archive date. --Obsuser (talk) 15:40, 25 August 2017 (UTC)
 * Access date clearly conveys now and should continue to clearly convey that it is associated with the main URL of the citation, not any other URL. Links can and archived before they become dead. --Izno (talk) 15:53, 25 August 2017 (UTC)
 * what exactly do you mean by the main URL? Citations to chapters, encyclopedia contributions, etc. often only contain chapter-url, since the URL to the work as a whole is not useful to readers; indeed quite often there isn't a URL for the whole work: authors of chapters/contributions regularly upload their part when the work as a whole isn't online. Peter coxhead (talk) 17:40, 25 August 2017 (UTC)
 * The url specified in url, as the documentation currently states. --Izno (talk) 19:52, 25 August 2017 (UTC)
 * I think the documentation at Help:Citation Style 1 is incorrect or out-of-date: it doesn't reflect the way that that the citation templates now behave. accessdate without url is ignored:
 * whereas adding chapter-url correctly produces:
 * Peter coxhead (talk) 20:42, 25 August 2017 (UTC)
 * Why do you want to say that it must refer only to the url? That is the point of this discussion: proposal to clarify that it can refer to the archive-url, chapter-url etc. also (and it is not true that it clearly conveys now only to url, there are already many cases – as I said – where access date refers to archive url [it is after URL became dead], or chapter url). If I'm wrong, than it would be useful to track cases where accessdate refers to other URL (if possible).
 * I agree. --Obsuser (talk) 12:25, 28 August 2017 (UTC)
 * Why do you want to say that it must refer only to the url? That is the point of this discussion: proposal to clarify that it can refer to the archive-url, chapter-url etc. also (and it is not true that it clearly conveys now only to url, there are already many cases – as I said – where access date refers to archive url [it is after URL became dead], or chapter url). If I'm wrong, than it would be useful to track cases where accessdate refers to other URL (if possible).
 * I agree. --Obsuser (talk) 12:25, 28 August 2017 (UTC)

Date formats for ranges
Why does " " give ""?

Date should remain same.

Same happens with " " which gives "" even if date should be 1 July – 1 August 2008 i.e. first part of range should not vanish. --Obsuser (talk) 13:06, 24 August 2017 (UTC)
 * does not support date ranges. Never has.
 * I see that you've made and unmade several changes to Module:Citation/CS1/Date validation/sandbox. Why?  To what purpose?
 * —Trappist the monk (talk) 13:16, 24 August 2017 (UTC)
 * Can it then be disabled for that function, so that if range is present df parameter is ignored?
 * Regarding changes in that module, complete diff is this. Purpose was first to enable three-digit years, and after that when I saw about metadata using captured year I generally gave up on this to be sure because I guess that metadata is ISO so year must be four-digit. At the end of my changes, three-digit years have been enabled for "month day, year" and "day month year" formats – because there is no reason to restrict date to four-digit years (this does not affect accessdate params), maybe not even to restrict two- or one-digit years, as something might be published e.g. June 854 or even June 54 etc. Also, in "month day – month day, year" and "day month year - day month year" there were minor inconsistencies: in first case, three-digit year was allowed in if match but not in real match for extraction; in second case, vice-versa.
 * Regarding changes in that module, complete diff is this. Purpose was first to enable three-digit years, and after that when I saw about metadata using captured year I generally gave up on this to be sure because I guess that metadata is ISO so year must be four-digit. At the end of my changes, three-digit years have been enabled for "month day, year" and "day month year" formats – because there is no reason to restrict date to four-digit years (this does not affect accessdate params), maybe not even to restrict two- or one-digit years, as something might be published e.g. June 854 or even June 54 etc. Also, in "month day – month day, year" and "day month year - day month year" there were minor inconsistencies: in first case, three-digit year was allowed in if match but not in real match for extraction; in second case, vice-versa.
 * Regarding changes in that module, complete diff is this. Purpose was first to enable three-digit years, and after that when I saw about metadata using captured year I generally gave up on this to be sure because I guess that metadata is ISO so year must be four-digit. At the end of my changes, three-digit years have been enabled for "month day, year" and "day month year" formats – because there is no reason to restrict date to four-digit years (this does not affect accessdate params), maybe not even to restrict two- or one-digit years, as something might be published e.g. June 854 or even June 54 etc. Also, in "month day – month day, year" and "day month year - day month year" there were minor inconsistencies: in first case, three-digit year was allowed in if match but not in real match for extraction; in second case, vice-versa.


 * --Obsuser (talk) 15:29, 25 August 2017 (UTC)


 * Is it possible that you are confusing CS1 with a bibliographic system? CS1 exists only to verify claims in articles (and elsewhere) by pointing to sources. The bibliographic history of a source is only pertinent when it affects reliability and verification. Sources should be cited by the date most relevant to the reader who wants to retrieve them. Whether a work was produced in 854 by some publisher means nothing in this context. A reliable (preferably easily retrievable) edition of the work published in 2014 by a certain publisher is what should be cited, and there is always orig-year if specific older information is deemed relevant. 300 years from now the 2014 edition would probably no longer be accessible; if the source is still used, a contemporary edition/reprint should be used instead. Access dates are a totally different issue and should always be more or less current . 72.43.99.138 (talk) 13:58, 26 August 2017 (UTC)
 * I made the interpolations above, for clarity. 72.43.99.138 (talk) 14:15, 26 August 2017 (UTC)
 * I do not support the change to allow three-digit years. Almost all three-digit years that I have found are typo errors, things like  or  . In each case, "2014" is meant. – Jonesey95 (talk) 22:53, 27 August 2017 (UTC)
 * I'm not necessarily opposed to three-digit years. They have their place.  I suspect that the need for day and even possibly month precision in a first millennium date is rare.  We could limit three-digit years to year-only dates which will allow cs1|2 to handle almost all references and bibliographies.
 * —Trappist the monk (talk) 10:33, 28 August 2017 (UTC)
 * It is not rare to cite a source published when the Julian calendar was in effect at the time and place of publication. But ISO 8601 does not allow Julian calendar dates. Converting the publication date from Julian to Gregorian would go against long-standing citation traditions outside Wikipedia, and would be hopelessly confusing. Thus citation templates should not emit metadata that asserts publication dates conform to ISO 8601. If that were to be done, an editor encountering an article that cites articles with Julian publication dates would be justified converting all the citations in the article to some other citation format, such as Chicago Manual of Style, to avoid publishing false information. Jc3s5h (talk) 23:07, 27 August 2017 (UTC)
 * What? Where in this discussion has anyone suggested date conversions between the Julian and Gregorian calendars?  Just to be clear, df does not do calendar conversion.  All it does is format conversion (hence its name).
 * —Trappist the monk (talk) 10:33, 28 August 2017 (UTC)
 * indicated his or her belief that the Cite Q template (and hence, the Citation template) emits ISO dates as metadata. Everyone who mentions "dates" and "ISO" in Wikipedia (with no qualification of which of the many ISO standards is meant) is advocating that all dates be stated in the Gregorian calendar, whether they realize that's what they're advocating or not. I am warning Obsuser about the probably unintended implications of his or her post. Jc3s5h (talk) 12:04, 28 August 2017 (UTC)
 * Again: What? No one here has mentioned except you just now.  The first instance of the letter 'q' (or 'Q') occurs with your mention of .  The reformatting applied by df applies to the rendered visual format of the original date but not to the metadata.  It is not possible to have ymd with 23 June 1254:
 * Dates in the COinS metadata are in a format that looks like that standard's format because that standard's mechanism for date ranges (yyyy-mm-dd/yyyy-mm-dd) is terse and to the point. For dates outside of the Gregorian calendar, only the year is made part of the metadata so that we avoid any need for calendar conversion.  YMD dates in cs1|2 look like that standard's format and are Gregorian like that standard but otherwise do not conform to that standard.
 * In the comments that I wrote in the function  in Module:Citation/CS1/Date validation I did suggest that these dates conform to that standard.  Perhaps I should revise those to say that the COinS date format resembles the standard's format.
 * —Trappist the monk (talk) 14:00, 28 August 2017 (UTC)
 * Sorry, I shouldn't have mentioned Cite Q in this context. I looked on the main page for metadata information. It does mention that metadata exists, but does not say what standard the metadata follows. I'm unable to understand from your comments above what standard is being followed. Could you please provide a link to the standard? Jc3s5h (talk) 18:44, 28 August 2017 (UTC)
 * See this discussion.
 * —Trappist the monk (talk) 19:17, 28 August 2017 (UTC)
 * Can reformatting then be disabled for that function, so that if range is present df parameter is ignored?
 * No, CS1 is a sort of bibliographic system. Yes, newer version is desirable but not neccessary (854 one can still be used), and I thing orig-year is also date i.e. part of verification system.
 * I agree to limit three-digit years to year-only dates (maybe to allow also month-and-year-only dates).
 * No need for warning each other; when I said I guess that metadata is ISO so year must be four-digit I meant that if 874 is captured possible ISO date would be "874-06-01" and I guess it is incorrect because it must be "yyyy-mm-dd"; so that's why I gave up on three-digit years wherever there was something like "for metadata" next to year (maybe I'm wrong about this, Trappist the monk knows better what is this metadata actually and would allowing three-digit years there corrupt it). --Obsuser (talk) 12:19, 28 August 2017 (UTC)
 * Yet one would think that most citable sources produced during the Julian (or any other) calendar period would have contemporary editions in the current calendar. Works that survive centuries usually do. And I don't think CS1 is anything other than what is explicitly stated: a more-or-less standardized, custom collection of guidelines for providing a measure of reliability to an anonymously produced encyclopedia. 72.43.99.138 (talk) 12:27, 28 August 2017 (UTC)
 * The custom that has emerged in Wikipedia is to cite the date of a paper publication, even if what the editor actually viewed was a verbatim image of it on microfilm, or a verbatim digital image from a source like Google Books. On the other hand, if the editor viewed a newer edition, which was re-typeset and re-paginated, then the date of the newer edition would be cited. There are many publications from the time when the Julian calendar was used that are readily available as digital images. Whether a newer edition would be more reliable than an older edition depends on the nature of the claim being supported. Jc3s5h (talk) 13:02, 28 August 2017 (UTC)
 * If there is a custom of citing the print publication without crediting of the actual media consulted, such custom should be retired. It contradicts WP:SAYWHEREYOUGOTIT and may prevent readers who want to verify the sources from accessing the claimed source. There are several parameters that can be used (type, via etc.) or templates ( being an obvious candidate). Apart from that, it seems that dating the source needs additional clarity. There appears to be some confusion regarding work date and publication date, and their respective usage in the date field. 72.43.99.130 (talk) 19:05, 28 August 2017 (UTC)
 * Yet one would think that most citable sources produced during the Julian (or any other) calendar period would have contemporary editions in the current calendar. Works that survive centuries usually do. And I don't think CS1 is anything other than what is explicitly stated: a more-or-less standardized, custom collection of guidelines for providing a measure of reliability to an anonymously produced encyclopedia. 72.43.99.138 (talk) 12:27, 28 August 2017 (UTC)
 * The custom that has emerged in Wikipedia is to cite the date of a paper publication, even if what the editor actually viewed was a verbatim image of it on microfilm, or a verbatim digital image from a source like Google Books. On the other hand, if the editor viewed a newer edition, which was re-typeset and re-paginated, then the date of the newer edition would be cited. There are many publications from the time when the Julian calendar was used that are readily available as digital images. Whether a newer edition would be more reliable than an older edition depends on the nature of the claim being supported. Jc3s5h (talk) 13:02, 28 August 2017 (UTC)
 * If there is a custom of citing the print publication without crediting of the actual media consulted, such custom should be retired. It contradicts WP:SAYWHEREYOUGOTIT and may prevent readers who want to verify the sources from accessing the claimed source. There are several parameters that can be used (type, via etc.) or templates ( being an obvious candidate). Apart from that, it seems that dating the source needs additional clarity. There appears to be some confusion regarding work date and publication date, and their respective usage in the date field. 72.43.99.130 (talk) 19:05, 28 August 2017 (UTC)

WP:SAYWHEREYOUGOTIT states

"So long as you are confident that you read a true and accurate copy, it does not matter whether you read the book using an online service like Google Books; using preview options at a bookseller's website like Amazon; on an e-reader (except to the extent that this affects page numbering); through your library; via online paid databases of scanned publications, such as JSTOR; using reading machines; or any other method."

So the custom of citing the date of the print publication rather than the date of the publication that faithfully reproduces the images of the print publication is in absolute conformity to WP:SAYWHERYOUGOTIT. Jc3s5h (talk) 19:11, 28 August 2017 (UTC)
 * If I'm consulting a scanned copy of a source, say a book scanned into Google Books, I probably won't know when the scanned copy was created to credit a different date of "publication". Since it is a faithful reproduction of the original, I cite it as the original print book that was scanned, and add the Google Books like with Google Books. The "say where you got it" is satisfied by the URL and via attribution. Even if I'm consulting a document that was scanned and uploaded onto Wikimedia Commons (like commons:File:AASHTO USRN 1985-06-26.pdf) where I do know when the document was scanned, that date doesn't change the publication details of the source I'm consulting. Instead, I'd argue that giving a 2014 date for a 1985 document would confuse matters in the citation.  Imzadi 1979  →   21:32, 28 August 2017 (UTC)


 * There are two different aspects here. The first is attribution: a copy of a source should be declared as such. What is cited is the copy, not the original (this applies to later print editions of books as well). If this is how the editor cites the source, then that is how the citation can be verified by a reader. There are parameters in CS1 that make such declarations plain, as discussed above. The second aspect is the fact that work date and publication date have different meanings and serve different purposes. Work date in the present context serves to identify a source whereas publication date, in addition to discovery of the source, offers a means to retrieve it. However either can be used in the date field, and this may lead readers to believe that an editor consulted a source from say, 1492. This is improbable, and perhaps not what the average Wikipedia reader (who likely has very little knowledge of the technicalities of citation systems) would expect as proof of an article claim. 65.88.88.214 (talk) 23:00, 28 August 2017 (UTC)

code tweaks
I have tweaked Module:Citation/CS1/Date validation/sandbox so that date-holding parameters that hold date ranges are skipped.

I have also restored the date checking to 4-digit years for dates with month or with month and day. Simple year, year ranges, and circa year dates continue to support 3- and 4-digit years.

—Trappist the monk (talk) 10:45, 29 August 2017 (UTC)

Access-level parameters
I'm wondering if a non-breaking space should be placed before the access-level icon. It seems odd for the icon to be separated from its link, especially if the icon winds up on a line of its own.

Additionally, is there any reason that  and   are not acceptable values for the   and   parameters (and perhaps ,  ,  , and  , though I'm not particularly familiar with them)? Of course  isn't accepted since it's assumed that content that has a DOI or that is on JSTOR requires a subscription unless otherwise indicated, but what about, for example, the occaisional paper that is accessible for free on JSTOR provided one registers for a free account?

Any thoughts? 142.160.131.202 (talk) 20:55, 30 August 2017 (UTC)


 * There should be a non-breaking space yes. has been working on this, but I don't know what came out of it.
 * Those should be supported per the RFC we held, but they haven't been rolled out yet. The main reason to not support them was that doi/jstor are usually closed access, and thus "flagging what is normal" was seen as undesirable. The RFC did conclude that they should at least be allowed, and then editors can chose to flag this or not.
 * free/free/free/free etc all work already
 * Headbomb {t · c · p · b} 21:08, 30 August 2017 (UTC)
 * I presume that you are referring to this template:
 * If you look at the code produced from that you will see this bit:
 * In the midst of that you will find this:
 * which is a narrow no-break space. As you have discovered, it does not work.  I suspect that it doesn't work because the access signal is an image and not a letter or number.
 * —Trappist the monk (talk) 21:56, 30 August 2017 (UTC)
 * That's precisely the citation I had in mind. Do you know if there is any way of getting it to work with the image? (Despite the fact I was citing The Computer Journal, I'm afraid that my background is definitely not in computer science.) 142.160.131.202 (talk) 22:22, 30 August 2017 (UTC)
 * I can see how "flagging what is normal" might be considered undesirable, but the case I'm discussing isn't "flagging what is normal". JSTOR, for instance, requires a subscription for most content (that I've seen, at least), so I'm just hoping to be able to tag those less common cases where  or   are appropriate. And nothing I was referring to should affect the   value. 142.160.131.202 (talk) 22:22, 30 August 2017 (UTC)
 * Non-breaking spaces - and the  declaration - are intended for use when there are two pieces of text which should not be divided. Access icons are images, and images are not text. Some browsers may prevent wrapping when text is "joined" to an image in this manner, but this behaviour is not documented and must not be relied upon. -- Red rose64 &#x1f339; (talk) 08:31, 31 August 2017 (UTC)
 * That's precisely the citation I had in mind. Do you know if there is any way of getting it to work with the image? (Despite the fact I was citing The Computer Journal, I'm afraid that my background is definitely not in computer science.) 142.160.131.202 (talk) 22:22, 30 August 2017 (UTC)
 * I can see how "flagging what is normal" might be considered undesirable, but the case I'm discussing isn't "flagging what is normal". JSTOR, for instance, requires a subscription for most content (that I've seen, at least), so I'm just hoping to be able to tag those less common cases where  or   are appropriate. And nothing I was referring to should affect the   value. 142.160.131.202 (talk) 22:22, 30 August 2017 (UTC)
 * Non-breaking spaces - and the  declaration - are intended for use when there are two pieces of text which should not be divided. Access icons are images, and images are not text. Some browsers may prevent wrapping when text is "joined" to an image in this manner, but this behaviour is not documented and must not be relied upon. -- Red rose64 &#x1f339; (talk) 08:31, 31 August 2017 (UTC)


 * Well, although "registration" means "a free registration is required to access the source" I'm not sure it gives the right impression for the JSTOR links you refer to, since, since you both need to make an account you can only read three articles within a 14 day period  you can't download the article like you'd be able to do with the truly free ones / if you paid for it, just see one page at a time. It's a lot more jumping through hoops than something where you make an account and you access it for free. To me "registration" means you have normal unlimited access, you just need to make an account once. Umimmak (talk) 15:33, 31 August 2017 (UTC)

Should the template remove redundant periods?
E.g. "Torvalds, Linus (May 9, 1996). "Re: Linux Logo prototype.". Archived".. I believe the MOS allows the latter removed, not the former), is there an exception for refs? I had no luck with postscript=none (strangly did nothing?!) and mode is for other. Any alternative? Best would be if the template did it in agreement with the MOS(?). comp.arch (talk) 11:24, 1 September 2017 (UTC)
 * Please provide a sample template. I believe that some periods are already ignored. – Jonesey95 (talk) 13:12, 1 September 2017 (UTC)
 * It's this one, I think.
 * There is a function in Module:Citation/CS1 called  that is supposed to remove duplicate punctuation when that punctuation matches the template's separator character (in this case a dot).  But,   apparently doesn't have a case for  .  So I added one:
 * There is a function in Module:Citation/CS1 called  that is supposed to remove duplicate punctuation when that punctuation matches the template's separator character (in this case a dot).  But,   apparently doesn't have a case for  .  So I added one:


 * But, that doesn't look quite right to me. Compare the above to a simple example without the separator character inside the quotes (this is the norm):
 * So, perhaps when title has a trailing separator character, we should remove the title's trailing character rather than remove the template's separator character.
 * —Trappist the monk (talk) 13:42, 1 September 2017 (UTC)
 * —Trappist the monk (talk) 13:42, 1 September 2017 (UTC)

Date error not flagged
There appears to be no flagging of a date error when cite web is called from Kilde www

As an example renders as

This should give a date error for the dots in the date and another for the dash. Keith D (talk) 17:15, 8 September 2017 (UTC)
 * If one is to believe the 'Pages transcluded onto the current version of this page' list at the bottom of this page, the cs1|2 module suite is not used by that template. This is confirmed by looking at your example this way:
 * and comparing that to this rendering which does use :
 * If one looks into the source for, there are two mentions of cite web one of which is in a comment but the other is not. That code is sufficiently complex that, without I take time that I haven't got right now, I cannot explain.  I would have suggested that a conversation with Editor Jimp (who authored the cite web section of that code would be in order but that editor has not edited since March).
 * There are relatively few instances of this template so perhaps the right thing to do is to upgrade those instance to use the correct cs1|2 template (the example here might want to be ).
 * —Trappist the monk (talk) 18:27, 8 September 2017 (UTC)
 * It appears that cite web is involved only when the template is substed. That template, and other foreign-language citation-translation templates, should be set up to auto-substitute, like Internetquelle, but the date substitution is broken. I have posted on the template's talk page to see if anyone is willing to fix the date substitution bugs. – Jonesey95 (talk) 18:31, 8 September 2017 (UTC)
 * Thanks, could not work out the code. Keith D (talk) 23:56, 8 September 2017 (UTC)
 * —Trappist the monk (talk) 18:27, 8 September 2017 (UTC)
 * It appears that cite web is involved only when the template is substed. That template, and other foreign-language citation-translation templates, should be set up to auto-substitute, like Internetquelle, but the date substitution is broken. I have posted on the template's talk page to see if anyone is willing to fix the date substitution bugs. – Jonesey95 (talk) 18:31, 8 September 2017 (UTC)
 * Thanks, could not work out the code. Keith D (talk) 23:56, 8 September 2017 (UTC)

Language parameter
Hello! There's an apparent oversight with the "language" parameter. There are many journals, proceeding, collective works, etc. that have content in various languages, and the language cited should refer to a specific entry. Currently, when one uses or  with the "chapter" parameter, the "language" parameter appears next to the journal or book title, respectively, whereas it should appear next to the article title or chapter title, because that is where it is relevant. Constantine  ✍  14:20, 8 September 2017 (UTC)
 * language is not attached to any particular title-holding parameter; readers are, I guess, expected to infer that it applies to the most specific title. For example, if type or series is included in a  template:
 * There are a bazillion cs1|2 parameters. Figuring out how to render each parameter in its optimal position according to which of the other bazillion parameters are selected for the particular citation is an onerous task; one that will likely never be accomplished.
 * —Trappist the monk (talk) 14:46, 8 September 2017 (UTC)
 * Granted that there are many parameters, but presumably the order of appearance is related to the order in which the parameter is defined. So why not define it right after title and/or chapter? Alternatively, or in addition, why introduce a "chapter-languange" parameter, analogous to "chapter-url"? Constantine  ✍  18:02, 8 September 2017 (UTC)
 * Order of appearance and order of definition are wholly unrelated. Parameters are rendered in an order that somewhat resembles the order established by external style guides like Chicago, ALA, etc.
 * —Trappist the monk (talk) 09:45, 9 September 2017 (UTC)
 * Order of appearance and order of definition are wholly unrelated. Parameters are rendered in an order that somewhat resembles the order established by external style guides like Chicago, ALA, etc.
 * —Trappist the monk (talk) 09:45, 9 September 2017 (UTC)

Generalize Template:Cite report
Propose merging and  to, and adding a type parameter that sets the descriptive wording, e.g. to "report", "technical report", "press release", "whitepaper", "standard", "specification", "form", etc. This would provide for easier and more precise citation of a wide range of governmental and NGO output, without polluting the metadata output of title, work, or wherever people are trying to randomly insert such things. Also, these descriptive terms should not be capitalized per MOS:CAPS; they're being overcapitalized in the [at least] three redundant templates, with output of "(Technical report)", "(Press release)", and "(Report)", respectively. And the title needs to be either in italics or quotation marks; I would suggest italics (at least as a default), since this is for stand-alone items, though perhaps there could be a switching parameter; some citation styles may demand quotation marks for works under a certain length. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:04, 10 September 2017 (UTC)
 * I disagree with merging press releases in; those are short-form works that shouldn't be in italics, while reports are typically longer-form works that would have italicized titles. (Personally, I gave up on using cite report and just use cite book with Report.) As for the descriptive terms, those should remain capitalized. It's quite common for those to be capitalized in the citation styles.  Imzadi 1979  →   23:47, 10 September 2017 (UTC)

Article on multiple pages, continues under a different title
Hi, guys! I would like to cite the material on page 10 of an article that appears on page 1 as "Girl Kisses Boy", but is continued on page 10 as "Boy Cries After Being Kissed". Normally I would use the first title and note "pp. 1, 10" to indicate that the article covers multiple pages. Should I be using the second title and just "p. 10"? Thanks! -Location (talk) 02:16, 8 September 2017 (UTC)
 * Or treat the 2nd as a subtitle ? —Th e DJ (talk • contribs) 07:43, 8 September 2017 (UTC)
 * Do you mean Girl Kisses Boy; Boy Cries After Being Kissed with 10? -Location (talk) 15:04, 8 September 2017 (UTC)
 * title should be the title of the work as it appears in the contents/title page. That is the way most works are indexed and that is the way they can be found. You can use "&sect; Boy Cries After Being Kissed". p. 10. 72.43.99.138 (talk) 13:58, 10 September 2017 (UTC)
 * If we're talking about a newspaper article, they typically use a shorter or different title for the continuation. At the bottom of the section on page 1, it would say "See 'Boy Cries After Being Kissed', p. 10" or similar and then at the top of the section on page 10, it would say "'Boy Cries After Being Kissed' from p. 10" or similar. Personally, I cite it under the main title on page one and cite the two pages together. Unless the article is especially long, the information being cited should be easily located whether it is on either page.  Imzadi 1979  →  16:52, 10 September 2017 (UTC)
 * Thanks for the replies. On multiple occasions I have had cited material reverted because someone didn't pay attention to the fact that the cited material within the linked newspaper article was continued on a second page. I guess that not really my fault, but I was hoping to cite in a way to prevent that from happening. Thanks again! -Location (talk) 02:45, 11 September 2017 (UTC)

Possible sandbox bug with cite interview
I stumbled across this Lua error on Template:Cite interview/testcases:



I don't know how long it has been there or what the error means. Here's a direct call to cite interview/new, showing that the problem is in cite interview, not in cite compare:



And here is the citation with only title:



Any ideas? – Jonesey95 (talk) 18:33, 11 September 2017 (UTC)

This occurs in cite web as well: --Izno (talk) 20:01, 11 September 2017 (UTC)

TfD notification about Template:Cite Q
There is a discussion here which may be of interest to editors of this page. Nikkimaria (talk) 00:10, 16 September 2017 (UTC)
 * Just to note that this is about Template:Cite Q. Thanks. Mike Peel (talk) 01:03, 16 September 2017 (UTC)

Legislation template
Hi, I originally posted this at the Help Desk but realised here is probably a better venue. I was taking a look at Railways in Melbourne with the intent of cleaning up its citations, and given that there's a fair few CS1 templates I thought that might as well be the eventual style. However, this article cites quite a few pieces of Victorian legislation, and I wasn't sure about the best way to provide a CS1 citation for these sources. There's a template, Cite Legislation AU, but I'm not sure if it's appropriate. Happy to do it manually too but I'll need some guidance on the correct style. Triptothecottage (talk) 21:31, 20 September 2017 (UTC)
 * I agree that is not a good fit because it is a source-specific template that is locked to the Austlii website.  cs1|2 are not really good at legislative citations because they are general purpose tools that are pretty good at rendering citations for the most commonly cited stuff: books, magazines, newspapers, journals.  It can be done, though.  Rewriting this one:
 * compared to:
 * Note that these two citations, while purporting to cite the same thing, do not. The former cites the version of the legislation dated 1 July 2010 while the latter cites the presumably current version dated 12 April 2017.  I suspect that  will always do that so important bits of a source might get legislated away in future making the source useless for Wikipedia's purposes.
 * compared to:
 * Note that these two citations, while purporting to cite the same thing, do not. The former cites the version of the legislation dated 1 July 2010 while the latter cites the presumably current version dated 12 April 2017.  I suspect that  will always do that so important bits of a source might get legislated away in future making the source useless for Wikipedia's purposes.
 * Note that these two citations, while purporting to cite the same thing, do not. The former cites the version of the legislation dated 1 July 2010 while the latter cites the presumably current version dated 12 April 2017.  I suspect that  will always do that so important bits of a source might get legislated away in future making the source useless for Wikipedia's purposes.
 * Note that these two citations, while purporting to cite the same thing, do not. The former cites the version of the legislation dated 1 July 2010 while the latter cites the presumably current version dated 12 April 2017.  I suspect that  will always do that so important bits of a source might get legislated away in future making the source useless for Wikipedia's purposes.


 * Similar to the above, ref 33, ref 34, ref 36, ref 38, ref 39, and  ref 41 can all use  as I did above. Ref 35 is referencing a Wikipedia article which it should not do so you might want to find a better source.
 * —Trappist the monk (talk) 22:35, 20 September 2017 (UTC)
 * Thanks for all that. I think that's a good point about the dynamic nature of the Austlii citation. (I hadn't even noticed the internal link in 35!) I'll get around to using CW for all of them. Triptothecottage (talk) 03:17, 21 September 2017 (UTC)

Truthful publication dates
In Help_talk:Citation_Style_1/Archive_10 indicates that metadata is emitted for publication dates, and the metadata is meant to be in the COinS format, and a series of references leads to this date format description. That document in turn refers to ISO 8601, which only allows the use of the Gregorian calendar and Proleptic Gregorian calendar. I voiced the concern in the original discussion that any date before Thurday 1 March 1923 should not be emitted as metadata, because that is the date that the last country (Greece) switched from the Julian to the Gregorian calendar.

Citation Style 1 adopts the date formats from Manual of Style/Dates and numbers. That manual clearly allows Julian calendar dates: "A date can be given in any appropriate calendar, as long as it is (at the minimum) given in the Julian calendar or the Gregorian calendar or both, as described below." Quite a few articles about events between 1582 and 1923 contain footnotes stating which calendar is used in the article; automatically putting (without date conversion) dates into the metadata is likely to contradict these footnotes.

All the documentation that any reasonably diligent editor will read indicates Julian calendar publication dates between 1583 and 1923 may be, and in some case should be, in the Julian calendar. The templates at present silently change the meaning of what the editor has written.

Thus I call for the citation templates to not emit metadata for publication dates before 1 March 1923 of the Gregorian calendar, or at the very least, only give the year. Jc3s5h (talk) 20:11, 28 August 2017 (UTC) Fixed first link 07:12 29 August 2017 (UT)
 * I think that the real link that Editor Jc3s5h meant to provide is this one: Help_talk:Citation_Style_1/Archive_10.
 * —Trappist the monk (talk) 09:52, 29 August 2017 (UTC)

I have begun an RFC about accurate dates in citation metadata: Wikipedia talk:Citing sources. Jc3s5h (talk) 15:03, 26 September 2017 (UTC)

Spacing
Is it just me, or is the spacing in citations suddenly broken? It seems to be adding multiple spaces after the title. Although now that I look around, it seems to be doing it in templated external links as well. --tronvillain (talk) 22:47, 28 September 2017 (UTC)
 * It's not extra spacing, it's spacing that was always there for the external link icon to be dropped into - but at the moment, there is a problem with the external link icons, see Village pump (technical). -- Red rose64 &#x1f339; (talk) 23:24, 28 September 2017 (UTC)
 * Aha. Thanks. --tronvillain (talk) 13:17, 29 September 2017 (UTC)

Cite book: Treat |work as synonym of |title in absence of the latter
It's good that we can do something like to handle cases where a stand-alone work exists as a book but has also been published in a journal and we're citing that version of it.

However, it's annoying that I can't fix a mal-citation of the form: by simply changing "journal" to "book" and "title" to "chapter".

The work parameter should be aliased by default to the main work title, in every template in this family, even if we permit it to do other things if title is also specified in some cases. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  01:15, 3 October 2017 (UTC)

MR error checking
MR come in two formats, old (which I can't find documentation for, but the structure seems to be  [case-sensitive]) and new. The canonical identifier is a 0-padded 7-digit string (see, scroll to "New format for primary item identifier" section), but the zeros are optional, and are stripped for non-subscribers , and will therefore be common. The template should simply automatically zero-pad to 7 digits.

The old style should be put in a maintenance category so they can be updated. Anything else should be flagged as errors (e.g. mr01234, found in ). Headbomb {t · c · p · b} 18:12, 28 August 2017 (UTC)
 * Anyone? Headbomb {t · c · p · b} 02:03, 3 October 2017 (UTC)

JFM error checking
JFM seems to come in only one format. Headbomb {t · c · p · b} 23:33, 2 August 2017 (UTC)

Exception: But that's are not really JFM identifiers, those are ERAM identifiers, which happen to resolve to the same database. Not quite sure how to handle that one. Headbomb {t · c · p · b} 14:30, 4 August 2017 (UTC)
 * found in Hermite polynomials and Mehler kernel
 * found in Von Staudt–Clausen theorem
 * I've updated them to use id instead. Headbomb {t · c · p · b} 20:57, 4 August 2017 (UTC)
 * JFM could be abused to put a Zbl identifier. If the Zbl structure is found, it should throw an error and tell users to user zbl instead. Headbomb {t · c · p · b} 14:54, 4 August 2017 (UTC)
 * Unarchived as unresolved. Headbomb {t · c · p · b} 14:38, 26 August 2017 (UTC)
 * Anyone? Headbomb {t · c · p · b} 02:03, 3 October 2017 (UTC)

Zbl error checking
ZBL come in two formats, old [temporary?] format which consists of pure digits (, possibly 8 digits ) and new. Catching errors would mean having a way of catching mistakes such at t0303.10056, e.g.. Headbomb {t · c · p · b} 14:15, 4 August 2017 (UTC)


 * will resolve (e.g ), but the correct identifier has a \d{4}\.\d{5} structure (e.g ). Headbomb {t · c · p · b} 15:14, 4 August 2017 (UTC)

I'll also point out that I found quite a few that would resolve only once the  part was striped [e.g., which I've updated to the new style]. I think those are temporary Zbl identifiers. Compare (which doesn't resolve) to  (which resolves to ). Headbomb {t · c · p · b} 14:21, 4 August 2017 (UTC)


 * Zbl will often be abused to put a JfM identifier . If the JFM structure is found, it should throw an error and tell users to user jfm instead. Headbomb {t · c · p · b} 14:53, 4 August 2017 (UTC)


 * This page describes the coding for the  format, but I could not find anything for the other formats or temporary IDs. If the first four digits are a volume number, it makes sense that one could remove the zero padding with no loss of info. --Mark viking (talk) 20:44, 4 August 2017 (UTC)
 * If the  format isn't desired, that could be shown as an error too. There's only a handful of (around 41, last I checked). Headbomb {t · c · p · b} 21:02, 4 August 2017 (UTC)
 * I've updated them all, except  in Superpermutation. This is either the temporary assignment, or an oversight in the Zbl database, or it's just a legit but undocumented code. Headbomb {t · c · p · b} 21:37, 4 August 2017 (UTC)
 * I've confirmed those are temporary assignments. They should be put in a maintenance category so they can be updated to the canonical Zbl identifier once they get assigned. Headbomb {t · c · p · b} 14:43, 26 August 2017 (UTC)
 * Anyone? Headbomb {t · c · p · b} 02:03, 3 October 2017 (UTC)

Bug when title ends with single quote, revisited
Help talk:Citation Style 1/Archive 34

I thought this bug was addressed but perhaps it wasn't pushed live? I'm still getting the same error:

czar 05:57, 3 October 2017 (UTC)
 * It has been but, alas, there is a related problem for which I have not yet found a solution. And because real-life has been in the way these past months.
 * —Trappist the monk (talk) 11:19, 3 October 2017 (UTC)

Sections with cite web
OK, this has been gone over before. does not recognise either chapter or section. Here's, with a ref as follows: The person adding that ref has stuffed three distinct pieces of information into the title parameter. Clearly, I can move the page number to the page parameter; what I also want to do is move the heading "Ding-ding and away" (which is not part of the document title) into a separate parameter - but both chapter and section are unrecognised by. I also do not wish to pollute page - which incidentally should be 5–6 as it's not all on one page. So I rearranged it as: Please can we avoid enforcing these arbitrary restrictions which create inconveniences. There is a similar issue with most of the other refs in that article. -- Red rose64 &#x1f339; (talk) 09:15, 2 October 2017 (UTC)


 * The easiest solution (and one which works in some other cases where "cite X" templates impose restrictions) is to use :
 * There's always a trade-off between flexibility and error-checking; the "cite X" templates can be better at error-checking and enforcing consistency because they "know" the kind of citation being handled, whereas the "citation" template is more generic, but in a very few cases doesn't have enough information to work correctly. Peter coxhead (talk) 11:50, 2 October 2017 (UTC)
 * It is interesting to me that you choose to damn cs1|2, and in particular, for what would appear to be a fundamental citation failure in that article.  The article cites Guttmann's power-point slides from a talk given at the AusCERT Asia Pacific Information Security Conference held 18–23 May 2008 in Gold Coast, Australia.  Australia.  Surely a Wikipedia-notable slang term that refers to  train and station personnel would be documented in  sources, most notably the  press – especially when, in 1979, seven people died.
 * If Guttmann is the only source, use of a different cs1 template might be in order, perhaps this:
 * —Trappist the monk (talk) 11:58, 2 October 2017 (UTC)
 * If Guttmann is the only source, use of a different cs1 template might be in order, perhaps this:
 * —Trappist the monk (talk) 11:58, 2 October 2017 (UTC)
 * —Trappist the monk (talk) 11:58, 2 October 2017 (UTC)
 * —Trappist the monk (talk) 11:58, 2 October 2017 (UTC)
 * —Trappist the monk (talk) 11:58, 2 October 2017 (UTC)


 * I generally favor {citation} as handier and avoiding some of these pettifogging gotchas. But many, many editors use {cite web}, so it is pertinent to ask: why does {cite web} ignore chapter and section? (Are those too "book-like"??) It is quite common for web pages to have sections (which should be citeable), and not a few also have chapters. (E.g., here.) That kind of data facilitates verification, so why are they ignored? Alternately: why do they require extra treatment with obscure parameters? ~ J. Johnson (JJ) (talk) 22:38, 2 October 2017 (UTC)


 * I think citation and cite x are set up pretty much backward. The convention outside Wikipedia when citations are in endnotes is to separate the elements with commas. When parenthetical referencing is used, the usual convention is to use a period as a separator in the full bibliography items. If were using templates, and all citations are in endnotes, we done need ref = harv as the default. If we're using parenthetical referencing, we do want ref = harv as the default. So the default of ref = harv should be associated with cite x and not citation, but the reverse is how it's actually set up. Jc3s5h (talk) 23:14, 2 October 2017 (UTC)


 * This advice, The easiest solution (and one which works in some other cases where "cite X" templates impose restrictions) is to use doesn't appear to actually work reliably:
 * Generates the same red error with or without cs1.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  06:06, 3 October 2017 (UTC)
 * that's a different case. Now you're trying to have a 'three level' citation: contribution/chapter, title and newspaper. This only works when the top level is "encyclopedia", not when it's newspaper/work/website. (Try changing newspaper to encyclopedia.) The underlying reason is the way title is treated: e.g. it's the 'top level' for a book, but the 'second level' for a journal article. Peter coxhead (talk) 08:45, 3 October 2017 (UTC)
 * Yet we frequently need three-level citations. I guess I'll just go back to using at to get the desired result. I report this one because I was trying to fix a red template error I encountered in an article.  I forget where it was. I guess it will just remain there forever, unless these templates are adjusted to do what people need them to do instead of what some confused and palimpsestuous flowchart is forcing them to do.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:31, 3 October 2017 (UTC)
 * Debate club appears to be a regular part of the Legal Affairs magazine, in which case, perhaps department applies:
 * —Trappist the monk (talk) 11:58, 3 October 2017 (UTC)
 * I agree that lack of support for these parameters in and some other templates is annoying and is ; I, too, have to spend an inordinate amount of time fixing mal-citatations that try to shoe-horn non-title information into title. Since hardly anyone ever looks for and fixes these things, that means that there's an order of magnitude or two or three more such errors than people like me and RedRose64 take the time to repair. It behooves those insistent on metadata output that most of us just DGaF about or at most consider a very back-seat purpose of these templates, to set the templates up so that we can actually use them easily. For myself, I sometimes fix this with at (depends on what non-title info is being inserted into title), but there's not a consistent approach. Just letting people use section and chapter makes the most sense and enhances inter-template conversion/correction. (See also thread below about work in ).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  01:26, 3 October 2017 (UTC)
 * Yes, I've long wanted to be able to create 'three level' citations more freely using the templates, but the consensus here has been against it. You can, of course, always use plain text, which is necessary in other cases (e.g. date formats recommended by the source but not supported by the templates, like "2010 onwards"). Peter coxhead (talk) 08:45, 3 October 2017 (UTC)
 * Said something about this above .  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:32, 3 October 2017 (UTC)
 * —Trappist the monk (talk) 11:58, 3 October 2017 (UTC)
 * I agree that lack of support for these parameters in and some other templates is annoying and is ; I, too, have to spend an inordinate amount of time fixing mal-citatations that try to shoe-horn non-title information into title. Since hardly anyone ever looks for and fixes these things, that means that there's an order of magnitude or two or three more such errors than people like me and RedRose64 take the time to repair. It behooves those insistent on metadata output that most of us just DGaF about or at most consider a very back-seat purpose of these templates, to set the templates up so that we can actually use them easily. For myself, I sometimes fix this with at (depends on what non-title info is being inserted into title), but there's not a consistent approach. Just letting people use section and chapter makes the most sense and enhances inter-template conversion/correction. (See also thread below about work in ).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  01:26, 3 October 2017 (UTC)
 * Yes, I've long wanted to be able to create 'three level' citations more freely using the templates, but the consensus here has been against it. You can, of course, always use plain text, which is necessary in other cases (e.g. date formats recommended by the source but not supported by the templates, like "2010 onwards"). Peter coxhead (talk) 08:45, 3 October 2017 (UTC)
 * Said something about this above .  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:32, 3 October 2017 (UTC)

Self-published works?
What's best practice for publisher if a work is self-published? Do we have a standard form of words to use? In particular, this is for a historian whose first works were self-published, then later reprinted (as distinct, expanded works) by commercial publishers. Andy Dingley (talk) 15:05, 22 September 2017 (UTC) — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:46, 3 October 2017 (UTC)
 * . I hope this helps (if not, it would be nice to improve the documentation page).  — Paleo  Neonate  – 21:39, 22 September 2017 (UTC)
 * This isn't as a source, this is for a bio about an author and a list of their published works. Andy Dingley (talk) 21:44, 22 September 2017 (UTC)
 * Lewis Cozens? Reading that bibliography, the 'author' text at the end doesn't seem to mean anything – almost like an error has occurred; especially since it's not capitalized.  Maybe if location were included and 'Author' capitalized it would be better.  'Self-published', I think is better because it clearly states that the author  the publisher and doesn't leave the reader guessing.
 * —Trappist the monk (talk) 21:56, 22 September 2017 (UTC)
 * Agreed, either the word "author" needs to be capitalized in that context, or it should be replaced with "Self-published".  Imzadi 1979  →   03:02, 23 September 2017 (UTC)
 * I use "self-published" (or "Self-published", depending on the template output), for pretty much exactly the reason Trappist identifies. There are lots of things that various external citation styles do that we do not (except when some WP:CITEVAR nut is trying desperately to mimic an external style down to the character, which borders on a WP:NOTHERE pastime and generally leads to repeated WP:OWN-style disputes) . Most of those quirks are based on saving space to cut down printing cost, and are also conventions for a very narrow audience who all cite exactly the same way following the same rulebook. Neither of these apply here. We should use plain and unambiguous English, especially when doing so interfaces directly with one of the core content policies.  WP is actually special, and it's fine for us to do special things, within our own context. Using "author" in this position doesn't signal what it's intended to; it tells the reader that the person is the author, versus editor, illustrator, or whatever; not that they're self-publishing.

high risk
So there's this template at the top of several of the various cs1|2 template documentation pages. Except for, they look more or less like this from :

Recently Editor Mr. Guye changed the template at to look like this:

I reverted because the percentage-use is not really necessary to convey the fact that is widely used but also because the calculation used to arrive at that percentage is misleading so the result is mostly meaningless. Between then and now Editor Mr. Guye has reverted me with this edit summary: "This is what they do on many "High-risk" templates. It's not just something I decided to invent."

To set the record straight, I have not accused Editor Mr. Guye of inventing anything. I do not know who 'they' are so cannot speak to that part of the argument.

While it is possible, I suppose, to use in all namespaces, counting all pages in all namespaces misleads editors by artificially reducing the apparent usage in the few namespaces where it matters and foremost among them is article space.

Were Editor Mr. Guye to have chosen a more appropriate base for the calculation I might not have reverted (even though I still think that the statistic is not necessary). For example:

instead of

Rewriting the calculation to use  gives a better representation of  use where it matters most:

I've written all of this because WP:BRD

—Trappist the monk (talk) 18:05, 21 September 2017 (UTC)
 * Pretty sure there was a discussion last year about the template, where it was decided that two significant figures was quite sufficient; so 2600000 is no more precise than necessary. -- Red rose64 &#x1f339; (talk) 18:29, 21 September 2017 (UTC)


 * No comment on the base of the calculations as I just followed the format I saw before, but adding "which is X% of all pages" to certain high-risk templates is done on templates such as, , (for that one I updated the calculation, but did not originate its inclusion), ,  and more. &thinsp;&mdash; Mr. Guye (talk) (contribs)&thinsp; 18:48, 21 September 2017 (UTC)
 * But isn't that just the 'because other stuff exists' argument? Further, the cs1|2 templates that are truly 'high-risk' are protected so that the least of them require template editor user rights to edit. so really the  template doesn't have much value except as a rough indicator of the number of pages transcluding the template.
 * —Trappist the monk (talk) 21:56, 21 September 2017 (UTC)
 * I agree that the percentage is misleading and the precision excessive (and a recipe for churn). Kanguole 20:39, 21 September 2017 (UTC)
 * Yes, 2 significant figures seems fine, and a percentage of all articles doesn't seem useful (e.g. if it's a high use biography template the % of all articles isn't meaningful, it's the % of biographies, but we've no certain way to measure that, as the presence of the template itself may be the best measure). Rjwilmsi  07:19, 22 September 2017 (UTC)
 * Strongly concur with Trappist. We don't care that "X% of all pages" is relevant for some templates, which have general applicability (like ); it's not relevant here and people will abuse the bogus statistic in "citation-warring" arguments.   context should obviously use "X% of all articles" figure (however worded).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:51, 3 October 2017 (UTC)