Help talk:Citation Style 1/Archive 30

Page vs. Pages vs At parameters
In using cite book here, I find I'm getting an error for specifying a page and the pages in the book. More than one of |pages=, |at=, and |page= specified (help) Since I recall a long ago class in citation specifications which suggested including a page count and specific pages in citing a book, that memory indicates I certainly shouldn't be seeing an error. SPECIFICALLY:

The documentation certainly supports use of only one of the three, so what are we to use for total pages? Last I looked, being able to check page counts versus edition helped validate a specific page range of verified material&mdash;or gave a clue as to which direction to move in the new edition to adjust the given page range. Fra nkB 21:59, 15 December 2016 (UTC)
 * As far as I know, cs1|2 and specifically, has never supported 'number of pages' as a proper use of pages so, yes, you should be seeing the error message that you are seeing. You may not be seeing the error message about your use of chapter-format; that parameter requires that value is assigned to chapter-url.  The chapter-format error message is hidden as the result of (in my opinion) a misguided rfc which you can find in the archives.  To turn on all error messages, see Help:CS1 errors.


 * Additionally, I will note that you are misusing script-chapter. That parameter is intended to hold chapter titles that are written using a script other than Latin (Cyrillic, Korean, Greek, Hebrew, etc).
 * —Trappist the monk (talk) 22:46, 15 December 2016 (UTC)
 * OK, LOL. (One reason I stopped doing RFCs!) Fra nkB 04:41, 16 December 2016 (UTC)
 * Hmmmm, well seemed like a useful workaround since the template has no sub-title parameter. For me the important thing is the information is present and gotten across--the communication is clear, so worth the time to put up when data isn't crystallized knowledge. They are a pain. Thx though, . // Fra nkB
 * Please don't edit my comments by adding your comments to them. I've moved your comments out of my comments.
 * The most common practice for subtitles that I've seen is to include them in title with the title separated by a colon or a dash as appropriate:
 * Chapter II – 4: The Primitive Engineer
 * —Trappist the monk (talk) 11:15, 16 December 2016 (UTC)
 * A little clarification. In a full citation (such as produced by cite book) pages might be used for the total pages, or, where you cite only part of the book, the page range of that part or chapter. However, the specification of the specific location (page or section number, etc.) of the cited material is not part of the full citation. Where you use the full citation only once the conventional practice is to append the specifier to the citation. In this case we can add it following the cite template. I have made that change for you to illustrate (go ahead and revert it if you wish). (Note that "cite" also needs none.) Give me a yell if you have questions. ~ J. Johnson (JJ) (talk) 01:35, 16 December 2016 (UTC)
 * Thx to you too, JJ! I get your point, and think I understand the technique you suggest... but don't see the change... Ahem! No worries, I was raising the point because of my understanding from back in High School, or was it Jr. High? Fra nkB
 * No, it is not a valid use of cs1 or cs2 to use pages for the total page count, even when you are putting the full citation in one place and the page range of a specific citation elsewhere. The intended semantics of the pages parameter is only for pointing to ranges of pages where the cited information can be found. If you want to put the total page count into a citation, you need to do it outside the template and outside the cs1 style, because that is not part of cs1 (or cs2). —David Eppstein (talk) 02:21, 16 December 2016 (UTC)
 * Hmmmm, David, hate to break it to you man, but style and citations are a bit of an impossible mission. Nothing you can do will ever make them stylish. But thanks for the time to all. // Fra nkB 04:41, 16 December 2016 (UTC)
 * "Style" here is used to denote a ruleset for consistent formatting and presentation, it does not refer to subjective aesthetic. 64.134.243.44 (talk) 01:39, 17 December 2016 (UTC)
 * In a full citation (such as produced by cite book) pages might be used for the total pages. No.  The template documentation is clear about this: "do not use to indicate the total number of pages in the source."  That statement is backed up by the the style's documentation section on pages: "Note: CS1 citations do not record the total number of pages in a cited source; do not use this parameter for that purpose."
 * Because the in the example article does not have accompanying short citations, the in-source location is properly specified in page, pages, or at; it is not tacked onto the end between the closing   and the closing  tag as your  did.
 * —Trappist the monk (talk) 11:15, 16 December 2016 (UTC)
 * One piece of commentary is appropriate, I think: the value of pages is preceded by "pp." in the rendered output, not suffixed by it. That distinction is important. It would be read as "pages 495" which makes no grammatical sense. In a citation that does list the total pages, it would be rendered either "495 pp." or "495 pages.", which does make grammatical sense. So Trappist is correct: the CS1 style of citation does not list total number of pages, but only uses pages to indicate a range or listing of multiple pages being cited at once.  Imzadi 1979  →  13:06, 16 December 2016 (UTC)
 * Because the in the example article does not have accompanying short citations, the in-source location is properly specified in page, pages, or at; it is not tacked onto the end between the closing   and the closing  tag as your  did.
 * —Trappist the monk (talk) 11:15, 16 December 2016 (UTC)
 * One piece of commentary is appropriate, I think: the value of pages is preceded by "pp." in the rendered output, not suffixed by it. That distinction is important. It would be read as "pages 495" which makes no grammatical sense. In a citation that does list the total pages, it would be rendered either "495 pp." or "495 pages.", which does make grammatical sense. So Trappist is correct: the CS1 style of citation does not list total number of pages, but only uses pages to indicate a range or listing of multiple pages being cited at once.  Imzadi 1979  →  13:06, 16 December 2016 (UTC)


 * As far as I know, it is not customary when using citation style 1 to include the total number of pages, but sometimes the total number of pages can be derived from the citation. When the Wikipedia article has an alphabetical list of works cited, and either short footnotes or parenthetical references to that list, then the long citation will include the page range of an entire journal article, or an entire chapter in an edited book. The short footnotes or the parenthetical references will give the particular pages that support the claim in the article. Example: There are 12 months in a Gregorian calendar year.




 * As a general practice (i.e., not necessarily in Wikipedia) full citations for books sometimes include the total number of pages, which can be helpful in (e.g.) distinguishing different editions, or just letting the reader know how extensive the book is. In mentioning that pages sometimes is used for this purpose I was not suggesting that it should be.


 * I don't agree suffixing the "in-source location" (specification) to the template is improper. It is also necessary if one wants to specify a section or paragraph (using at) in addition to the page number, as the template does not tolerate both. ~ J. Johnson (JJ) (talk) 23:34, 16 December 2016 (UTC)
 * Use at for a paragraph with a page number isn't necessary. 6, ¶ 2 works to render "p. 6, ¶ 2.", or if you don't want to use the pilcrow, 6, para. 2 would give you "p. 6, para. 2.". The same works if you're citing a specific footnote on a published page via 3, n. 6 and the like.  Imzadi 1979  →   08:24, 18 December 2016 (UTC)


 * For starters, stuff like "¶ 2", "para. 2", "§2.1", etc., are not page numbers, so I say it is improper to include them in a parameter that is named "page" (or "pages"), which implies that the values are indeed about pages, which they are not. But if such items are suffixed to the citation template that kind of metadata pollution is avoided. (And perhaps avoiding COinS indigestion.)


 * But there is a deeper issue here. Trappist says "the in-source location is properly specified in page, pages, or at; it is not tacked onto the end between the closing  and the closing  tag ...". I say: why not?  Why can't it be? Where is the rule that everything in a note must be contained between braces?  Where short cites are used (by means of sfn or harv, or even without any templates) the "in-source location" is not even near the full citation, let alone in it. To use "pages" for the page range (such as for an article in a journal), AND for in-source location, gives us values like "200-220, 206", which is an inconsistent usage. ~ J. Johnson (JJ) (talk) 00:17, 21 December 2016 (UTC)
 * Perhaps a reread of what I wrote is in order. The sentence begins: Because the in the example article does not have accompanying short citations, ... at which point it continues with the remainder that is quoted above.  With the restriction that I specified, then, of course, the proper place for the in-source location is in page, pages, or at because the citation is not bibliographic in form and, using the template parameters in this way is consistent with the template and style documentation to which I referred earlier in that same post.  Certainly there is no  that in-source locators  use the available parameters, but, to not use the parameters, is inconsistent with the template documentation so why bother using the template at all?
 * I agree that 200-220, 206 is a misuse of the parameter. When used with a short cite, it is reasonable and acceptable to set pages to the range of page numbers that an article occupies.  When a cs1|2 template is not used with a short cite, then the in-source location parameter must specify which page or pages support the item being cited in the Wikipedia article.  It is not reader friendly to specify the whole page range of an article when the cited sentence lies on only one page; it is poor practice to make our readers search through a twenty-one page article for that one sentence on page 206.  Alas, there are tools like citoid that scrape bibliographic infomation into cs1|2 citations which our editors then accept as correct so our readers are forced to do the search for that one sentence.
 * —Trappist the monk (talk) 13:21, 21 December 2016 (UTC)
 * —Trappist the monk (talk) 13:21, 21 December 2016 (UTC)


 * Of course it is "not reader friendly" to not supply a specific in-source location, but that is not antithetical to supplying the page range. The point is to understand the value of both, and to supply both.


 * I take it as understood that where short cites are used (as with harv) the "in-source" location/specification does not go into the full citation. The matter is entirely of cases where (i.e., between  tags), and the editor wants to cite the specific location in the same note, where having a short cite (e.g., the "Smith et al.  2009") immediately following the full citation it refers to would be ludicrous. But note: this can come up even where short cites are used. One of the benefits of short cites is that the full citations can be taken out of the notes and collected elsewhere (and typically alphabetized for convenient consultation). But this is not required.  The full citations can be left in the notes, which is rather like putting them in the footnotes of a printed book. In such a case it would *not* be proper to include a specific page or location in the citation template, because then that specific location would be included in what subsequent short cites refer to. In such cases putting the specific page following the cite/citation template is not only reasonable, it is the only proper location for it.  Putting it into page is entirely unnecessary, and, as you just said, a misuse of the parameter.~ J. Johnson (JJ) (talk) 01:22, 24 December 2016 (UTC)

Weird linebreak at the end of citations
I recently used (Erratum in ) " in a reference (see Journal of Electroanalytical Chemistry). The output is
 * (Erratum in )

For some reason, that last bracket ) can appear on a second line, and is not kept in place by the linewrapping. This is due to the template putting a space between the final . of that citation and the bracket. This is both weird and wrong. Headbomb {talk / contribs / physics / books} 12:53, 29 December 2016 (UTC)
 * The terminal dot at the end of the doi is followed by the metadata, then by a necessary space, then the untitled periodical maintenance category message, and finally the closing bracket:
 * (Erratum in )
 * There is no space between the maintenance category message and the closing bracket. It would appear to me that nothing untoward is happening here.
 * —Trappist the monk (talk) 13:20, 29 December 2016 (UTC)


 * How is that space necessary? AFAICT, nothing depends on it. If it's only purpose is to put a space between something and a maintenance message nobody can see unless they opt in (e.g. probably like 10 people on earth), then that space should be part of the maintenance message, not displayed by default. Headbomb {talk / contribs / physics / books} 13:29, 29 December 2016 (UTC)
 * The space is part of the maintenance message (immediately following the opening tag:
 * —Trappist the monk (talk) 13:39, 29 December 2016 (UTC)
 * So why then does it display when the message isn't being displayed? Headbomb {talk / contribs / physics / books} 13:51, 29 December 2016 (UTC)
 * I also see a space between the period and the closing parenthesis when I turn off the maintenance messages. – Jonesey95 (talk) 14:02, 29 December 2016 (UTC)
 * I don't think that the module is necessarily at fault. The space is present in the maintenance category message because grammar requires it.  The   is supposed to tell the browser that the content is not to be displayed.  Instead, it appears to me that the browser assumes that there needs to be a space between whatever came before and whatever follows because the first character in the span is a space (or   html numeric entity).  If I remove the space, or replace it with something else, the browser does not insert a space between the terminal dot and the bracket.
 * We can remove the space and add  to the   attribute:
 * (Erratum in )
 * (Erratum in )
 * This appears to work.
 * —Trappist the monk (talk) 14:54, 29 December 2016 (UTC)
 * (Erratum in )
 * This appears to work.
 * —Trappist the monk (talk) 14:54, 29 December 2016 (UTC)

Parameter for an explanation?
There are a handful of errors in the date field at Materiality (auditing). This is because the date field should now only contain actual dates, and not date-related information, e.g., the date that these regulations went into effect. I've no inherent objection to this decision; OTOH, it's probably important to retain the key bibliographic detail that this book is the one that is "Effective for audits of financial statements for periods beginning on or after December 15, 2009". (For this kind of technical regulation, the date of effectiveness is more important and more useful for identifying the source than the date of publication.) But I don't see a parameter that's just for adding whatever text you want to the template. Did I overlook an option? What do you recommend? (Please ping me.) WhatamIdoing (talk) 19:34, 28 December 2016 (UTC)


 * I would say that CS1 templates are not used correctly here. Or the correct templates are not used. Also, the date issue is not clear to me, just from looking at the references. Are we citing the regulations, or the publications of the regulations? It should be the latter. Then the relevant date is the date of publication. You may note the "effective as-of" date outside the citation, or perhaps using the orig-year parameter. A less satisfactory (imo) situation would make use of date and publication date, but reverse their recommended usage. 65.88.88.62 (talk) 20:34, 28 December 2016 (UTC)
 * following up with what the IP above me has said, look at Michigan State Trunkline Highway System. In there you'll find that the "State Reward Trunk Line Highway Act" was published in 1915, but in the citation we have enacted May 13, 1913. That's the best way I know to clearly handle a disparity between and effective date and a publication date, and it may give you an idea on how to proceed.  Imzadi 1979  →   21:06, 28 December 2016 (UTC)
 * Thanks for these ideas. I think what I really want is a editorial-comment-on-this-source option.
 * The thing about regulations is that they're often re-printed, so any given copy may be published on any date, and there may be small differences between them (e.g., different page formatting). An editor may or may not be looking at the original.  So it might sometimes be useful to identify the date of publication for the copy you're looking at, but it's critical to identify the effective date, because that's how the regulation can actually be found in the real world.  It's similar to what you'd do with a much re-printed book:  Origin of Species was published in 1859, but the editor's looking at a transcript that was posted online in 1998.  The "originally 1859" is more important than the "my copy is from 1998" part.
 * And, in this case, the doc being cited is the original (the linked pdf contains only the relevant chapter), and the original contains no other date. So I can't switch the date parameters, because there's nothing to switch it with.  WhatamIdoing (talk) 20:07, 29 December 2016 (UTC)


 * I think what I really want is a editorial-comment-on-this-source option: There was talk of a note option for CS1, but I don't know what transpired. I tend to use link note for these cases. 65.88.88.127 (talk) 20:49, 29 December 2016 (UTC)
 * If the idea I mentioned above doesn't help, then another tactic I've used may: just run a note in parentheses after the citation, something that a few of the map citations generated by cite MDOT map do to note the "as of" date for the roadway conditions reflected by the map as stated in its legend, specifically:  Imzadi 1979   →   02:32, 30 December 2016 (UTC)

|vauthors= bug fix
In vauthors, when an author's initials have one or more multi-byte characters (uppercase Latin characters outside of the ASCII A–Z character set), Module:Citation/CS1 will treat the initials as a name and render only the first initial:

Fixed in the sandbox.

—Trappist the monk (talk) 19:25, 31 December 2016 (UTC)

liveweb.archive.org
liveweb.archive.org is a rarely used alias to the Wayback machine. It is usually used erroneously for example, notice there is no YYYYMMDD in the URL.

This should render with an error but does not:





This correctly renders with an error:





I'm working on a script to find and add snapshot dates in the wikitext (based on existing archivedate data), but a rendered error for liveweb would help. Thanks.

-- Green  C  15:34, 5 January 2017 (UTC)
 * Is a fix to cs1|2 necessary? This external link search would seem to indicate that there are relatively few instances of the liveweb.archive.org url; most appear to be in user and talk namespaces.
 * —Trappist the monk (talk) 15:45, 5 January 2017 (UTC)
 * Because I ran an AWB regex to convert them yesterday (sans talk pages). In over 530 article pages. Without the error message there is nothing to prevent (or discourage) editors from continuing to add them. liveweb.archive.org is a deprecated method that once worked without the need for a date in the URL (it actually still works but you can't lock-in which date it will end up at perhaps different from the intended archivedate). So editors who are accustomed to that format (without using a timestamp) will continue doing so without a warming message. -- Green  C  18:54, 5 January 2017 (UTC)

Ok:

—Trappist the monk (talk) 19:44, 5 January 2017 (UTC)


 * Thanks. Looks good to me. Though would it say "malformed: timestamp" since that's really the issue, the missing timestamp. liveweb.archive.org is an alias to web.archive.org so nothing inherently wrong with the hostname so long as it has a timestamp. --  Green  C  19:51, 5 January 2017 (UTC)
 * But you wrote: liveweb.archive.org is a deprecated method .... If it's deprecated, we should not support it.
 * —Trappist the monk (talk) 20:23, 5 January 2017 (UTC)
 * I did some research and liveweb is the name of a component of the Wayback Machine software stack. The Wayback archive shows activity only from 2011-2012. So I believe the liveweb hostname was a public-facing alias during that period, and is now a "hidden" alias (unadvertised) .. during that period it's possible they were advertising a method of linking that used the liveweb hostname but didn't include a timestamp (I'm guessing to explain why so many were added to Wikipedia that way). So the important difference is a timestamp be included - there may be other old hostnames lurking, others include wayback, www, www.web and web. --  Green  C  23:03, 5 January 2017 (UTC)

Chinese and Korean
I propose that we add an extra parameter that instructs Wikipedia to write the author's name as **family name** - **personal name**, for Korean and Chinese authors. This is how Chinese and Koreans write their names. This template guide advises uses to just put it all in **last**, but if I do this then the **harv** template cannot link to the reference properly. Ghrelinger (talk) 17:33, 10 December 2016 (UTC)
 * The documentation currently says "last: Surname of a single author", "first: Given or first names of author", and "author: this parameter is used to hold the complete name of a single author (first and last)". What words would you propose? Also see this China-related MOS section. Are you aware of any other guidelines that could help us in this situation? – Jonesey95 (talk) 17:49, 10 December 2016 (UTC)
 * One can also use the parameters surname and given. These are aliases for last and first, but are less confusing when working with East Asian names, in which the surname is customarily first, or a mixture of Eastern and Western names.  Kanguole 02:17, 11 December 2016 (UTC)
 * I think one part of the original comment bears some exploration is that if a Chinese name, like "Wu Ni" were cited using the recommended Wu Ni, it won't work right for harv applications, and if Wu Ni (or even Wu Ni) were used, we'd get an extraneous comma resulting in "Wu, Ni" in the rendered citation.  Imzadi 1979  →   03:02, 11 December 2016 (UTC)
 * It's true that the formatting in a citation is different from the way one normally writes an Eastern name, but that's even more true of Western names ("Smith, John"). Perhaps the current uniform format in a list of citations makes it easier for readers not familiar with all those languages to distinguish surnames ("Wu" and "Smith").  Kanguole 11:19, 11 December 2016 (UTC)
 * harvid works well for cases where you want to customize the ref=harv default. – Jonesey95 (talk) 15:06, 11 December 2016 (UTC)
 * We have had this discussion before. So, here is a possible solution:
 * create a new parameter, perhaps surname-eastn
 * tweak Module:Citation/CS1 to recognize that parameter as being different from all of the other last aliases so that it renders surname-eastn and its matching givenn (or other acceptable alias) without a comma separator
 * As a test, I hacked the module sandbox so that it does that with surname:
 * If this functionality is to be retained, an appropriately named parameter is required; unless we simply declare that, from this point forward, surname is defined to hold eastern family names.
 * —Trappist the monk (talk) 18:47, 11 December 2016 (UTC)
 * It would be rather weird to say that Chinese authors' family names are surnames but those of English authors aren't. Cleaner schemes would be none or y (and similarly for editors, etc), but as argued above I don't think it's necessarily a good idea.  Kanguole 19:05, 11 December 2016 (UTC)
 * I don't see where you or anyone else has argued against the notion of removing the comma from the author-name-rendering when the author's name is Asian. I disagree with your suggestion that none or y are 'cleaner' implementations.  Using surname-eastn is one parameter (which is required anyway) whereas surname plus a separator parameter is two so would bloat a cs1|2 template's author list by as much as a third – especially  templates which can often have numerous Asian authors.
 * —Trappist the monk (talk) 19:47, 11 December 2016 (UTC)
 * I don't see where you or anyone else has argued against the notion of removing the comma from the author-name-rendering when the author's name is Asian. I disagree with your suggestion that none or y are 'cleaner' implementations.  Using surname-eastn is one parameter (which is required anyway) whereas surname plus a separator parameter is two so would bloat a cs1|2 template's author list by as much as a third – especially  templates which can often have numerous Asian authors.
 * —Trappist the monk (talk) 19:47, 11 December 2016 (UTC)

Because there has been no further discussion, I have reverted the surname experiment.

—Trappist the monk (talk) 11:46, 25 December 2016 (UTC)


 * It seems we need to clarify that the standard and most common meaning of surname is "hereditary name common to all members of a family, as distinct from a forename or given name", for all languages. Nor is this a "Chinese and Korean", nor even "eastern" issue: Hungarian (e.g.) also puts the surname first. To make more special cases just makes everything messier, and more complicated.


 * We should not be recommending putting both surname and personal name into a single parameter (e.g.: Wu Ni), as that is a misuse of "author", corrupts the metadata, and encourages stuff like Doe, John, and further confusion having to explain why names are handled in different ways. Definitely calls for revising the documentation.


 * I believe the underlying issue is the objection to the inserted comma into an "Asian" name, like "Wu, Ni" (a point which has had some extensive discussion here). I will argue that the presence of the comma should be taken as reassurance that the surname has been properly handled, and provides a consistent view that the surname  by which indexing is usually done  is everything up to the first comma. ~ J. Johnson (JJ) (talk) 21:53, 26 December 2016 (UTC)


 * This is putting the cart before the horse. What matters most is what appears to the reader. In most Chinese or Korean names the comma is just wrong. If the name appears as "Lee, Kwan Yew" it just looks ignorant and unprofessional and ridiculous. -- Alarics (talk) 23:49, 26 December 2016 (UTC)


 * That is certainly the case in running text, but citations are a different matter. After all, an author name like John Smith is displayed differently in a citation than in running text.  Names of East Asian authors are often written without the comma in citations in specialist publications on Chinese or Japanese topics, where the target audience all know the convention, but in publications in global topics like the sciences, it is common to mark all authors' family names in citations in a uniform manner.  For example, Nature uses "Zhou, L. P." and "Clark, J. D.", while Science uses "L. P. Zhou" and "J. D. Clark".  This allows readers to identify the surnames (which are a key identifier of citations, and also used in short citations), without assuming knowledge of regional name conventions.  As a general-purpose work, Wikipedia should cater to such an audience, and the natural way to do that is to uniformly use the comma separator after the surname.  Kanguole 00:38, 27 December 2016 (UTC)
 * Another common convention is to write the surname in all-caps, like "LEE Kwan Yew", but that runs afoul of MOS:ALLCAPS. —David Eppstein (talk) 02:11, 27 December 2016 (UTC)
 * An exception is made for citations per LSA or Bluebook. Not for CS1 though. 64.134.96.155 (talk) 13:41, 27 December 2016 (UTC)


 * Alarics: you seem to be attributing to a general "reader sensibility" your own notion of what "just looks ignorant and unprofessional and ridiculous", which suggests a basic WP:JDLI. But, Kanguole has shown professional use of the comma, and I would like to think my own comments (above) show that inclusion of the comma is not "ridiculous". As to "ignorant", well, someone not familiar with standard bibliographic and indexing practice might, the first time they encounter it (perhaps in the seventh grade??), think that "Smith, Frank" is pretty ignorant. It's really a matter of convention. And as I said before, we could establish an understanding that the comma delimits the surname, similar to the use of small caps. The world has conflicting usage re surnames, but this use of the comma could be taken as how we resolve it. ~ J. Johnson (JJ) (talk) 21:10, 27 December 2016 (UTC)


 * We shall have to agree to differ. I shall continue to put "author=Lee Kwan Yew" so that the name appears correctly to the reader. -- Alarics (talk) 19:39, 28 December 2016 (UTC)
 * Please don't. Doing this makes linking to the reference with harv much more difficult. —David Eppstein (talk) 20:34, 28 December 2016 (UTC)
 * In that case it is harv -- whatever that may be -- that needs fixing. The tail is wagging the dog. What actually matters is how it appears to the reader. If the citation says "Lee, Kwan Yew" the ordinary reader will think we are bonkers. -- Alarics (talk) 20:58, 28 December 2016 (UTC)


 * Yes, please don't. It seems to me there is a "tail" here trying to wag the dog, but I would say the tail is your insistence in not having the inserted comma. In this case there is nothing needing "fixing" with harv; it does just what it is supposed to do. On the other hand, the problem doing it your way is there is no indication whether "Lee Kwan Yew" is in first-last or last-first order, and whether the surname (essential for searching and indexing) is "Lee" or "Yew". Besides, it is a misuse of author to mush together personal and surnames, which blurs the metadata, and condones what with other names is bad practice (like Frank Smith).


 * I understand the inserted comma annoys you, but that seems really trivial, and I don't understand why you should be so obstinate about this. Nor do I see why any "ordinary reader" should think we are "bonkers". And certainly not if we should adopt the understanding I suggested. ~ J. Johnson (JJ) (talk) 22:23, 28 December 2016 (UTC)
 * The "ordinary reader" probably doesn't have a clue what referencing is about in the first place, has anyone done a survey?. All reference formatting follows arbitrary conventions, so as long as the convention is easy to use, unambiguous and simple, we can use whatever works best for Wikipedia. We can create our own convention. If Lee, Kwan Yew is clear and unambiguous to the ordinary reader who has little knowledge of the other conventions, cool. It may look a little unconventional to those accustomed to other conventions, but it has the big advantage that it makes clear which is intended to be the family name to those of us who would otherwise wonder whether the editor who inserted the reference got it right or even thought about it. It doesn't stop them getting it wrong, but nothing is foolproof. Also it is easy to use and is currently supported. &bull; &bull; &bull; Peter (Southwood) (talk): 17:45, 6 January 2017 (UTC)

How can the cite AV Media template be used from Wikiversity
I would like to use the cite AV media template from Wikiversity. When I attempt this it appears in Red, indicating it is unknown. How can the cite AV Media template be used from Wikiversity? Thanks! --Lbeaumont (talk) 15:19, 8 January 2017 (UTC)
 * Wikiversity uses an old version of en.wikipedia's for some cs1|2 templates and an old version of en.wikipedia's Module:Citation/CS1 for others.  That then gives you some options:
 * copy en.wikipedia's Template:Cite AV media/old to v:Template:Cite AV media – probably simplest
 * create v:Template:Cite AV media based on v:Template:Cite web – may or may not work
 * upgrade all cs1|2 templates to use a copy of the current version of en.wikipedia's Module:Citation/CS1 – most difficult
 * For all of the above, documentation will need to be created from scratch.
 * —Trappist the monk (talk) 16:06, 8 January 2017 (UTC)

Lay summary in Cite journal
There are a number of articles with references that have "Check |laysummary= value" caused by editors adding a title with the url, for example Cardiopulmonary resuscitation (ref 84). Removing the title gets rid of the error message, but doing so removes what appears to be useful information. Is there a way to show the title without it creating this message? if not I like to propose the creation of a parameter "laytitle" or "lay-title" which could be used to prevent these Check value messages and still enable a title to be displayed EdwardUK (talk) 18:02, 6 January 2017 (UTC)
 * The error message is correct. lay-summary is a url-holding parameter that should have nothing but a url as an assigned value.  The parameter's name is confusing so I believe that it should be deprecated in favor of lay-url.  Title text applied to lay-url is the static text 'Lay summary'.  I can be persuaded that lay-title should be adopted such that when set, the assigned value modifies the static text and the link from lay-url is applied to the title-text from lay-title but not to the static text:
 * Lay summary: "Heart has enough oxygen to survive hypothermia, CPR crucial" – EurekAlert! (18 July 2006)
 * —Trappist the monk (talk) 12:31, 7 January 2017 (UTC)
 * That matches my thoughts exactly. I’m not quite sure how to test this (the template is far more complicated than any I worked on before), but as an addition to the template I can’t see why it would cause any problems when implemented, so I have added a proposal at the village pump here: Addition of “lay-title” to Cite journal
 * —EdwardUK (talk) 19:16, 10 January 2017 (UTC)
 * —EdwardUK (talk) 19:16, 10 January 2017 (UTC)

Inconsistent behavior in para: format + para archiveurl
Take a look at what format is doing in :

Would making the parenthetical statements which come after the URLs consistent be desirable? --Izno (talk) 02:47, 1 January 2017 (UTC)
 * Or perhaps, the archive URL shouldn't have the (automatic) format=PDF detection? What about how deadurl plays into this conundrum? --Izno (talk) 02:48, 1 January 2017 (UTC)
 * The same citation without a format produces, which seems good to me. --Izno (talk) 02:50, 1 January 2017 (UTC)
 * archive-format:
 * —Trappist the monk (talk) 03:57, 1 January 2017 (UTC)
 * Seems to me like archive-format should take the format value if the archive-format value is unset (or is set as detecting a PDF). --Izno (talk) 19:45, 12 January 2017 (UTC)
 * —Trappist the monk (talk) 03:57, 1 January 2017 (UTC)
 * Seems to me like archive-format should take the format value if the archive-format value is unset (or is set as detecting a PDF). --Izno (talk) 19:45, 12 January 2017 (UTC)

Section field for cite book
I had actually entered a "PART II" division under "section" before realizing...
 * chapter=, |contribution=, |entry=, |article=, |section=

All equivalent.

Can we have a field for sections? For example
 * Chapter 9 begins 135 https://books.google.ca/books?id=vJknBwAAQBAJ&pg=PA135
 * Chapter 10 begins 156 https://books.google.ca/books?id=vJknBwAAQBAJ&pg=PA156

yet https://books.google.ca/books?id=vJknBwAAQBAJ contents says:
 * PART II 77
 * PART III 207
 * PART IV 321

So clearly chapter 9 and 10 are both part of section II. Both are useful things to be able to cite, 'part' and 'chapter'. Ranze (talk) 22:24, 12 January 2017 (UTC)
 * The reason they're all equivalent is that they're used to cite separately authored parts of a book, like the chapter "Sportacus Saves the Day!" by Dagny Kristjansdottir, pp. 135–155. That (and the book info) is the vital information; the fact that it's chapter 9, or that it's in Part II: Filmic Translations, isn't normally considered worth putting in a citation.  Kanguole 12:12, 13 January 2017 (UTC)

Stop linking trans-title
This overlinking is unhelpful to anyone and looks awful, hard for a typical reader to distinguish from some kind of coding error: — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:03, 12 January 2017 (UTC)
 * Err, this is a "coding error": the template doc makes it clear that the foreign title goes in title and the English one in trans-title. So I'm not clear what point you're trying to make? --NSH002 (talk) 09:38, 12 January 2017 (UTC)
 * The specific of the above citation is an error on his part with respect to parameter use, but his concern (that the link is much too long because it includes the translated title) is not a coding error. He wants the title, and only the title, to be linked, rather than including the translated title. --Izno (talk) 12:38, 12 January 2017 (UTC)
 * Ah, a matter of taste, I suppose. I don't think it hurts, but YMMV. --NSH002 (talk) 13:51, 12 January 2017 (UTC)
 * I personally would also prefer to reduce the size of this link either internal or external, so I've made the change in the sandbox module. Below is the comparison (with corrected parameters). I am happy to be reverted if someone should disagree with this change.
 * --Izno (talk) 19:17, 12 January 2017 (UTC)
 * Meh. I guess I don't see this as a clear case of 'overlinking' in the sense that is defined in WP:OVERLINKING.  Actually, the arguments presented here seem to amount to nothing more than "I don't like links longer than a few words."  Not much of an argument in my opinion.
 * —Trappist the monk (talk) 00:32, 13 January 2017 (UTC)
 * It's not overlinking as such, but the large expanse of blue does make the title harder to read, so I prefer Izno's version with the linking restricted to the value of title. (But in this particular case I wouldn't have used url, since the ISBN link leads to the same place.)  Kanguole 00:58, 13 January 2017 (UTC)
 * I would say it's not WP:OLINK from a words-not-sense point of view because these are elinks and not internal links. However, the purpose of OLINK is indeed to reduce (or remove) some "sea of blue". I would venture that what is often 10+ words all linked (to the same location or otherwise), where TransTitle is used, in a row, meets that definition. Additionally, this makes this a bit more consistent when the name of the work (outside of cite web) is internally linked. In the case of cite web: I have a handful of citations in Call to Arms (video game) where, if I linked the works cited to those web pages with translated titles, I would experience a similar "ugh, lots of blue". But, perhaps there is a better question: how is a citation served/improved by having a translated title? --Izno (talk) 12:49, 13 January 2017 (UTC)
 * Please close your tags; not doing so buggers up the context highlighting (and isn't valid html).
 * Fine question, that. If the purpose of a citation is to assist the reader in locating the source, then the source's  title is necessary.  A translated title isn't really helpful unless the source is one of those that is constructed so that it reads in one language from one end, but when flipped over reads in another language and even then, editors should use the title of the 'sub-source' that they consulted.  But, I think that this particular sub-topic is perhaps best discussed (it may already have) at WP:CITE because it isn't specific to cs1|2.
 * —Trappist the monk (talk) 13:25, 13 January 2017 (UTC)
 * Huh. I thought it was valid HTML 5 but I see that I was wrong (though there is plenty of exception in the specification regarding closing &lt;p> tags. Your script/gadget should process paragraph elements without closing tags with that much exception. Indeed, and I might send it that direction. --Izno (talk) 14:12, 13 January 2017 (UTC)
 * Fine question, that. If the purpose of a citation is to assist the reader in locating the source, then the source's  title is necessary.  A translated title isn't really helpful unless the source is one of those that is constructed so that it reads in one language from one end, but when flipped over reads in another language and even then, editors should use the title of the 'sub-source' that they consulted.  But, I think that this particular sub-topic is perhaps best discussed (it may already have) at WP:CITE because it isn't specific to cs1|2.
 * —Trappist the monk (talk) 13:25, 13 January 2017 (UTC)
 * Huh. I thought it was valid HTML 5 but I see that I was wrong (though there is plenty of exception in the specification regarding closing &lt;p> tags. Your script/gadget should process paragraph elements without closing tags with that much exception. Indeed, and I might send it that direction. --Izno (talk) 14:12, 13 January 2017 (UTC)

z.cash single letter domain names CS1 error (copied from the Help Desk)
(Copied from the Help Desk.)

Hello, I am trying to fix a " Check  value (help) " error in zcash for this URL:. It seems like the validation code is incorrectly flagging single-letter domain names like this. How can I report this bug to the maintainer? – JonathanCross (talk) 13:44, 18 January 2017 (UTC)

I've verified that https://z.cash/ is a valid website, any ideas? Naraht (talk) 14:25, 19 January 2017 (UTC)

I took a look at the validation rules. Someone put a lot of energy into trying to to account for specific single letter domains, quirks of TLDs, etc. Much of this is no longer applicable given the vast expansion of Generic TLDs and will continue to cause issues as these domains are more widely used in the future. Can we remove some of the restrictions to make the validation less brittle? – JonathanCross (talk) 15:01, 19 January 2017 (UTC)

Date problem
Hello, there appears to be a problem with the date being split by text in the following example

Keith D (talk) 13:15, 25 January 2017 (UTC)
 * At the moment, there isn't a good solution to this particular case because there isn't a script-publisher parameter. As a work-around change the date format to mdy:
 * Even though wrapping the Arabic(?) text in a template appears to work, don't do that because that template will corrupt the metadata.
 * Even though wrapping the Arabic(?) text in a template appears to work, don't do that because that template will corrupt the metadata.


 * The problem arises because Arabic is a right-to-left script, and numbers can be either right-to-left or left-to-right. Because English is left-to-right, the browser's rendering can automatically render the date correctly when it directly follows the Arabic script.
 * —Trappist the monk (talk) 13:47, 25 January 2017 (UTC)
 * Another work-around I've seen used is to add an English translation to the publisher parameter. For example:
 * — (talk) 13:58, 25 January 2017 (UTC)
 * I was hoping for a template solution, rather than having to go round individual instances and apply a work-round to solve the problem. May be we need a tracking category to flag-up the situation and a BOT to apply a fix here, probably that supplied by RP88 rather than using month first dates if article is in day first format. Keith D (talk) 18:33, 25 January 2017 (UTC)
 * Using the cite tweet template, which is based on cite web, appears to help resolve things by crediting the user account and author name. Major citation guides use the text of a tweet as the title of the source, and supplying a translated title also helps English readers.
 *  Imzadi 1979  →   05:05, 26 January 2017 (UTC)
 *  Imzadi 1979  →   05:05, 26 January 2017 (UTC)
 *  Imzadi 1979  →   05:05, 26 January 2017 (UTC)

Misuse of language parameter
Please can we have something - either a little red error message, or a tracking category (or both) to flag up uses of en which is totally redundant, since this is the English Wikipedia, and sources are presumed to be in English unless otherwise indicated. Also, judging by the first few hits in [//en.wikipedia.org/w/index.php?title=Special:Search&fulltext=Search&search=insource%3A%2F%7Clanguage%3Den%2F&ns0=1 this search], detecting en-GB, en-US etc. would be useful. -- Red rose64 &#x1f339; (talk) 14:25, 27 January 2017 (UTC)
 * en does not display anything:  displays: ; does a category or red error actually feel necessary? I might be agreeable to a green maintenance message. I agree though, en-X should probably also not display anything. --Izno (talk) 14:53, 27 January 2017 (UTC)
 * en is explicitly allowed but hidden by default. This behavior was suggested by an excellent editor named Redrose64. It was requested by editors who copy citations from en.WP to WP in other languages; other valid reasons were provided as well. There was also a discussion about language parameter values of the form en-XX, which are also allowed (the suffix is ignored). – Jonesey95 (talk) 16:39, 27 January 2017 (UTC)
 * *giggle* --Izno (talk) 17:13, 27 January 2017 (UTC)
 * Oops, I had forgotten that. It's just that in the last couple of weeks I've seem people adding en at what seems to be a significantly higher rate than before. -- Red rose64 &#x1f339; (talk) 21:03, 27 January 2017 (UTC)

deadurl parameter
In the cite web template, are there any other valid values for the deadurl parameter, other than yes or no?

For a referenced page that has ever-changing content and where an article needs to refer only to an archived snapshot of that page, what value should be used for deadurl? The original URL still works, the domain still hosts the same site, but the referenced content is no longer on the page.

Additionally, is there a way to cope with the situation where archived content needs to be referenced, and the original URL was dead but is now occupied by a completely different and totally irrelevant site after the domain was purchased by a new owner (perhaps even cases where the site now hosts malware or other illegal content).

I didn't see anything in the documentation, but may have been looking in the wrong place. --79.74.156.254 (talk) 21:35, 28 January 2017 (UTC)
 * deadurl=unfit is what you're looking for.— CYBERPOWER  (Around ) 02:05, 29 January 2017 (UTC)
 * Is that suitable for both cases or just the one where the original URL needs to be suppressed/non-clickable? Are there any other valid parameter values for the deadurl parameter? --79.74.156.254 (talk) 03:03, 29 January 2017 (UTC)

Proposal to change how Template:ISBN links
Please see Template talk:ISBN for a proposal to change how Template:ISBN creates a link. It currently matches the behavior of "magic linking" (one long link); the proposal is to change the template to match our Cite templates, in which ISBN is linked to ISBN and the number links to Special:BookSources. Please respond at the Template Talk page. Thanks. – Jonesey95 (talk) 00:20, 25 January 2017 (UTC)
 * I personally see CS1's current linking of the identifier name to article space as a case of over-linking, however, I am sure others will disagree. I was just targeting a unified set of linking alternatives to magic links (at first I tried going the other way at Template talk:PMID).
 * We now have a full set of mostly uniform linking template alternatives to magic links: ISBN, IETF RFC and PMID (even though they differ from other MediaWiki projects like Wikiversity's v:Template:ISBN, v:Template:RFC and v:Template:PMID which has chosen to retain the magic links linking style). 50.53.1.33 (talk) 19:54, 30 January 2017 (UTC)

dead doi links
Discussion about dead doi links at Template_talk:Dead_link. -- Green  C  17:53, 1 February 2017 (UTC)
 * Answered there, but for the record, use doi-inactive-date per the templates' documentation. – Jonesey95 (talk) 18:10, 1 February 2017 (UTC)

Protected edit request on 2 February 2017
On the biography template, it lists Joyce Kozloff as Max Kozloff's ex-spouse, even though they are currently married. Please remove the parenthetical "Ex-Spouse" entry. 2604:2000:E84C:F900:5CFF:EDCE:6E8F:F87A (talk) 15:48, 2 February 2017 (UTC)
 * ❌ The 'biography' template, whatever that is, is not part of cs1.
 * —Trappist the monk (talk) 16:29, 2 February 2017 (UTC)
 * The editor appears to be referring to Joyce Kozloff and Max Kozloff, but both articles appear to show these two people as currently married to each other. Hmm. – Jonesey95 (talk) 17:30, 2 February 2017 (UTC)

Use of at parameter to specify web searches where there is no direct URL to source material.
I recently added a paragraph to the documentation article "pages" that was subsequently reverted here by User:Redrose64 regarding using the at parameter to recreate a web search where this is to only way to retrieve the source material. This usage of the "at" parameter resulted from a discussion at the helpdesk here suggested by User:Thincat. If archived, search for "Best way to cite a FRA Accident report." of February 3, 2017 in the helpdesk archives.

The gist of the situation is this: If the source material can only be seen as the result of a query at a web site, and the resulting page containing the source material does not have a unique URL, how should the citation be written?

It may be that my proposed paragraph did not explain or emphasize the unusual circumstances well enough.--Arg342 (talk) 13:06, 4 February 2017 (UTC)
 * This is an interesting question. Sometimes you can find or construct a URL for a search, even though the browser doesn't show one, but this may involve interpreting the source HTML for the page in question, which isn't something anyone can do. If I can't find such a URL, then I've generally used a made-up title like "Search for 'XXX'", giving the url for the website's search page. I personally agree that the at parameter would be another way to handle this. It needs to be discussed before 's reversion is accepted. Peter coxhead (talk) 13:46, 4 February 2017 (UTC)
 * People's opinions differ, see Wikipedia talk:Citing sources/Archive 37. Thincat (talk) 14:24, 4 February 2017 (UTC)
 * Arg342's addition doesn't make it clear that the search facility should be provided by the same entity that provides the data. In that case, it's essentially a data base lookup. It wouldn't be appropriate to cite a search performed with a general-purpose search engine such as Google or Bing. Jc3s5h (talk) 15:04, 4 February 2017 (UTC)
 * That's a good point and it may be the source of the difficulty. I agree we should not cite Google, etc. searches as "references". Thincat (talk) 15:09, 4 February 2017 (UTC)
 * WP:BRD says that it needs to be discussed before the changes of Arg342 are restored, not that it needs to be discussed before my reversion is accepted. Arg342 was WP:BOLD, I reverted, we're discussing - and until there is consensus here to put it back in, the status quo ante should stand.
 * It's about verifiability and no original research. People shouldn't be expected to perform their own web searches: can we be certain that one person's search results will be the same as another's? Recent evidence at WP:VPT indicates that it cannot. We don't cite books as "book in Oxfordshire County Libraries" and say to people "go find it yourself" - we give author, title and page at the very least. Yes, people may need to read a whole page of text in a book to find the one sentence that verifies the claim; and equally, when citing from the web, we might give a URL for one of the subpages of a website but nothing more specific - but at least the search is narrowed to a manageable level. -- Red rose64 &#x1f339; (talk) 23:46, 4 February 2017 (UTC)
 * but we're not talking about general searches. As says, it wouldn't be appropriate to cite a search performed with a general-purpose search engine. We're talking about reliable sources, particularly online databases, that don't readily provide a URL to locate specific bits of information, but only a URL for the search page. If you can see in the browser or work out what the search syntax is for the website, you can use something like:, where I know that   added to the URL for the website is what is needed. But if I didn't know that, I could only provide something like: . What we're discussing is how to handle this second case. Peter coxhead (talk) 07:48, 5 February 2017 (UTC)
 * This seems like a useful thing. Is it likely to be stable? &bull; &bull; &bull; Peter (Southwood) (talk): 17:35, 5 February 2017 (UTC)
 * Another suggestion - archive the results page at archive.org or archive.is and refer to that archived page within the reference. The archived page is static with a permanent, unique URL. -78.147.143.191 (talk) 19:45, 6 February 2017 (UTC)
 * Do both ( supports multiple archive sites). In my experience they both have problems with database searches retaining them long term. Even better add a third from Webcite. -- Green  C  20:33, 8 February 2017 (UTC)
 * I will support the OP proposal if there will be explicit, understandable guidelines in place. Searches at properly managed/curated/maintained databases would be ok, for example − I think most commercial/institutional databases would likely pass muster. Proper criteria about when this is allowed may alleviate Redrose64's misgivings regarding the consistency/stability of search results. I suppose it comes down to the management/integrity of the source, which is part of a source's overall reliability. 72.43.99.138 (talk) 17:22, 8 February 2017 (UTC)

Edit request: |script-series and |trans-series
Could we get and  parameters added to the Cite book template? Along the lines of &  and  &. I was surprised it didn't exist when I got an error thrown at Kabukidō Enkyō. Curly "JFC" Turkey 🍁 ¡gobble! 23:03, 5 February 2017 (UTC)
 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. Izno (talk) 23:41, 5 February 2017 (UTC)
 * Izno—sorry, but isn't that the purpose of bringing it up here? Curly "JFC" Turkey 🍁 ¡gobble! 02:26, 6 February 2017 (UTC)

PMC
Has anything changed recently with the way pmc is handled in cite journal? Whatamidoing (WMF) (talk) 20:24, 7 February 2017 (UTC)
 * No.
 * —Trappist the monk (talk) 20:26, 7 February 2017 (UTC)
 * Thanks. It seems that we have more of these errors than we used to, and I'm trying to figure out why.  A change in the template's tolerance for PMCnnnnn (rather than nnnnn) was one possible explanation.  A change to an API somewhere?  I don't know yet.  Whatamidoing (WMF) (talk) 16:22, 9 February 2017 (UTC)
 * Module:Citation/CS1 and its succeeding Module:Citation/CS1/Identifiers has never accepted anything for pmc except the numeric characters. Similarly, the modules do not accept any 'identifier prefix' (doi, isbn, pmid, etc).  There are no plans to change that.
 * —Trappist the monk (talk) 16:34, 9 February 2017 (UTC)
 * I don't think PMC error-checking has changed significantly since March 2014, but I could be wrong. I think it's a change to Citoid or some other aspect of Visual Editor (or upstream data, as Whatamidoing (WMF) suggests), hence the Phabricator bug that I submitted. – Jonesey95 (talk) 19:06, 9 February 2017 (UTC)

|script-series and |trans-series for cite book?
Could we get and  parameters added to the Cite book template? Along the lines of &  and  &. I was surprised it didn't exist when I got an error thrown at Kabukidō Enkyō. Curly "JFC" Turkey 🍁 ¡gobble! 23:03, 5 February 2017 (UTC)
 * Bump? Is there any reason not to include these? Curly "JFC" Turkey 🍁 ¡gobble! 01:14, 10 February 2017 (UTC)
 * For one citation? Probably not worth the effort.  Simply write: Eight Flowers of Ukiyo-e 浮世絵八華 or something similar if it's really important to have the script title of the series in the citation.  The script versions of the title and chapter parameters were created because non-Latin scripts should not be italicized and because there can be strange artifacts when the original language is written right to left (most often when digits are part of the title).  These two conditions turn out to be rather common (the former much more prevalent than the latter).  We do not, for instance, have script parameters for authors which quite often list both the author's name in transcription as well as native script.  If we were to add more script parameters, that, it would seem to me, would be where we would consider starting first.
 * —Trappist the monk (talk) 11:15, 10 February 2017 (UTC)

Template:Identifier
Let's revisit the idea of Template:Identifier meta template. I've done one example in the doc of that template, to show the general idea behind it.

Basically this would be a meta template (or a module) to handle all identifier links done in the style of CS1/2 (see list at User:Headbomb/Sandbox).

So the code for doi would become something like

This way people can use  to create.

The code for PMC would become something like

This way people can use   to create.

The code for bibcode would become something like

This way people can use   to create.

The template/module would include error checking, and could be invoked by both the individual identifier templates, and CS1/2 templates. Headbomb {talk / contribs / physics / books} 00:06, 11 February 2017 (UTC)
 * Does this discussion really belong here?
 * —Trappist the monk (talk) 01:19, 11 February 2017 (UTC)
 * Perhaps this discussion should be moved to Template talk:Identifier. After we get a rough draft template created, we can notify the talk pages of existing identifier templates about the new template to see if there is interest. – Jonesey95 (talk) 02:14, 11 February 2017 (UTC)


 * It might not really 'belong here', but ideally we probably want a high-level design discussion, and I don't know how the CS1/2 templates handle identifiers, nor do I know how LUA works. It might be a simple thing to copy-paste code from the template to the meta-identifier template/module, it might not. But certainly people here are the most knowledgeable about these issues, and long-term, a unified/coordinated approach is likely the best.
 * Plus, I don't know if this would be best handled as a module, or a template, so I'm reluctant to invest much effort in template coding without a clear picture of what we want here. Headbomb {talk / contribs / physics / books} 03:22, 11 February 2017 (UTC)

Give a citation bot link when mandatory parameters are missing, revisited
No one objected, and a notice was left on the citation bot page for a few months now. I say it's time we implement this. Headbomb {talk / contribs / physics / books} 04:00, 13 February 2017 (UTC)

Requesting new parameter
Over at c:Template:Cite web, they have a parameter editor-type. Recently I cited a website with no author, but a "compiler and annotator". I did it by setting author "John Doe (compiler and annotator)" but I couldn't do the cite using format "Doe, John" (first last) to match other citations on that page, so the new parameter would be helpful. Thanks to anyone who can add it! Vzeebjtf (talk) 06:20, 13 February 2017 (UTC)
 * We have others for this rare case. – Jonesey95 (talk) 06:50, 13 February 2017 (UTC)
 * Thank you! Vzeebjtf (talk) 10:07, 13 February 2017 (UTC)

Help on scowiki
On the Scots Wikipedia, I've been having trouble with CS1, especially the Utilities module. As can be seen at sco:Game Freak, it displays "Lua error in Module:Citation/CS1/Utilities at line 39: bad argument #1 to 'ipairs' (table expected, got nil)". What can I do to fix this? -- Amaryllis Gardener  talk 00:13, 14 February 2017 (UTC)
 * Looks like you don't have the appropriate version of the Configuration file. The error message appears to be referring to   which doesn't exist in sco:Module:Citation/CS1/Configuration.
 * —Trappist the monk (talk) 00:29, 14 February 2017 (UTC)
 * Thank you! I'll get on updating the Config module right away. -- Amaryllis Gardener  talk 00:42, 14 February 2017 (UTC)

Month-year access dates
Delaunay triangulation has a bunch of old April 2010 parameters in its external links section. "April 2010" to me looks like a perfectly valid, if unspecific, date format. But the article is now filled with big red errors saying that the accessdate values need to be checked. Is there a reason this style of date is disallowed in this context? Yes, maybe whoever accessed the links on those dates should have also included the day, but there's nothing to check now about the validity of the dates. They are what they are, and the error message are a waste of reader attention. —David Eppstein (talk) 18:50, 11 February 2017 (UTC)
 * Whole dates because ephemeral sources can change day-to-day and even hour-to-hour. When used in an external links section, the need for an access date is diminished because that source is supplementary information that is not necessarily used as a reference for the article.  The fix then is to remove the access-date parameters, or comment them out, or fix the date ( 7 April 2010), or validate that the links are correct and useful and replace the existing date with the date of validation – this last especially when these errors are detected in article-supporting citations.
 * —Trappist the monk (talk) 19:16, 11 February 2017 (UTC)
 * Full access dates have been a requirement for a long time. My personal preference among TTM's suggestions above is to validate the web page today and subsequently update the access date to today. There was a bot request at some point within the past half-year for something like IABot to work through this category of errors where some partial date was indicated, but the editors in that discussion didn't get to consensus on the topic. --Izno (talk) 00:49, 12 February 2017 (UTC)
 * Instead of leading to more precise dates, the actual effect of more-nitpicky error checking in this instance is that yet another editor has given up on using the citation templates and instead switched to manual formatting of the links. —David Eppstein (talk) 02:58, 12 February 2017 (UTC)
 * But access dates are not used for precision. They are used for (a) source-version identification, which allows (b) verification of the referenced information. Editors must directly and personally check sources. Don't they know the date they did so? If that is the case, by all means do not use CS1. Let's try to keep this system within the verification/reliability policy parameters. 65.88.88.126 (talk) 14:05, 15 February 2017 (UTC)
 * Presumably the editor who checked the sources in April 2010 knew then what exact date the sources were checked, but it is now 2017 and even that editor has probably forgotten. We can make an estimate by looking at the edit history but that would be using the access date parameter incorrectly, as it is supposed to be a record by the actual editor who checked the sources, not someone else's later guess. —David Eppstein (talk) 16:05, 15 February 2017 (UTC)
 * An error of +/- 1 day on the access date is much better than an error of up to +/- 30 days, and is what we have anyway because what you check on January 2 for you may have been checked on January 3 for someone else. The error should be thrown for that reason alone. Headbomb {talk / contribs / physics / books} 16:24, 15 February 2017 (UTC)

cite citeseerx
Could someone help create this?

Basically, it should be very similar to cite arXiv, except without the "fill this with a bot" code. That is, the supported parameters should be Headbomb {talk / contribs / physics / books} 17:09, 16 February 2017 (UTC)
 * authors and variants
 * date and variants
 * title
 * citeseerx
 * doi should throw an error, telling people to use citeseerx instead. If a valid doi that doesn't start with '10.1.1.' is used, the message should invite users to instead use cite journal.
 * All other identifiers and parameters should be unsupported.

Whatever happened to the access lock RFCs?
A discussion elsewhere prompted me to think about this topic.

Some time ago there was a lot of discussion about adding access signals to cs1|2 citations which discussion resulted in some RFCs. At the end of the RFC comment periods, nothing happened. And then a bot quietly archived the RFCs. So, there they sit, in the archive, unresolved.

So, what are we to do? Nothing? Get the RFCs' sponsor to resurrect them from the archives so that they can be properly closed? Revert the changes to Module:Citation/CS1 etc that support the RFCs? Something else that I haven't thought about?

—Trappist the monk (talk) 12:09, 9 February 2017 (UTC)
 * Did anybody post a closure request at WP:AN/RFC? -- Red rose64 &#x1f339; (talk) 12:21, 9 February 2017 (UTC)
 * One was and it was closed. The other apparently was not and so it remains unresolved.
 * —Trappist the monk (talk) 12:44, 9 February 2017 (UTC)
 * I have been observing the WP:AN/RFC backlog for some time and some (very brave) editors seem to work on it. As the second RFC is now on the top of the list, I expect it to be closed in the coming days (weeks?). − Pintoch (talk) 13:24, 9 February 2017 (UTC)

I have updated Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to use the lock images specified in the RFC close. Did I get it right?

Also, why do we need the images in two places? Shouldn't the images in Configuration be sufficient? Not my code so perhaps there is a reason that I'm not understanding.

—Trappist the monk (talk) 13:56, 9 February 2017 (UTC)


 * I closed the RFCs, but people objected to that. The main message from RFCs that we need to go back to the drawing board with respect to colors (no one is really happy with GBR, and no one is really happy with GYB, although GRB has one more !vote than GYR), that all options have to be available (but aren't mandated) for the URL/identifiers, and that autolinking the title based on the availability of a free official version has consensus. Headbomb {talk / contribs / physics / books} 13:59, 9 February 2017 (UTC)


 * About the images in two places, you are right: we should only list them in one place. If I am responsible for this mess, then I deserve a trout. It looks like the images in the Configuration file are used for identifiers, the images in the main module are used for title links. I'll try to change the title link code to use the configuration as well. − Pintoch (talk) 14:17, 9 February 2017 (UTC)
 * I have made changes to remove the duplicate lock code so that lock images are only defined in Configuration.
 * —Trappist the monk (talk) 12:18, 12 February 2017 (UTC)

I closed the design RfC and am taking a look at the behavioral RfC. Thanks. Eggishorn (talk) (contrib) 19:03, 9 February 2017 (UTC)


 * Since aspects B1 and B2 lack consensus after all this time, they should be closed as no consensus and the module reverted in the pre-RFC state. Since the already closed RFC's implementation depends on the aforementioned aspects, it should be treated as a theoretical. 100.33.37.109 (talk) 00:38, 10 February 2017 (UTC)

I agree B2 lacks consensus, but I think that B1 does have enough for a rough consensus. I closed it as overall having a problem because there is a significant body of opinion disputing the whole process. Please see the close for further details. Thanks. Eggishorn (talk) (contrib) 15:11, 10 February 2017 (UTC)


 * So, what's next? Do we remove the locks-rendering code and remove all the url-access and id-access? − Pintoch (talk) 21:33, 10 February 2017 (UTC)
 * I would suggest not going backwards but further changes to address the expressed concerns in a new RfC. I would guess that there will not be full agreement with whatever path is chosen, meaning that multiple options will likely be needed. Eggishorn (talk) (contrib) 22:36, 10 February 2017 (UTC)


 * No, we unrestrict their use on identifiers and urls, deprecate registration and subscription and go back to the drawing board with the visual design. Less visually aggressive scheme with sane color schemes can be presented in a follow up RFC. E.g.
 * Lock-green.svg / Lock-gray-alt-2.svg / Lock-red-alt.svg.
 * Lock-green.svg / Lock-gray-alt-2.svg / Lock-gray-full-alt.svg


 * In lieu of the 50-50 split vote on
 * Lock-green.svg / Lock-yellow-alt-2.svg / Lock-red-alt.svg. (main objection: yellow doesn't look yellow, hard for the color blind)
 * Lock-green.svg / Lock-blue-alt-2.svg / Lock-red-alt.svg. (main objection: blue makes no sense to blue an intermediate level)
 * Then after that (much simpler, 1 question only) RFC is over, we revisit the autolinking situation. Headbomb {talk / contribs / physics / books} 22:42, 10 February 2017 (UTC)


 * A fair assessment of the RfC process, and fair recommendations, by Eggishorn. The larger issue is that there is no definite consensus on the use of locks. Without such a consensus, arguing about the color scheme is putting the cart before the horse. Intimately related to implementation is the guidance given to editors by the help page. Such guidance cannot be finalized before a new RfC arrives at a clearer consensus. Until then, the proper thing to do is to rollback the code. 184.75.21.30 (talk) 23:32, 10 February 2017 (UTC)


 * There is consensus for such locks, although not it's not resounding at the moment. These locks already exist (e.g. templates such as closed access, open access, subscription required, etc.) and have been in the wild for years now, but because there's never been a centralized discussion, it's all very disparate, and the complexity of the case seem to have made many go "that will just complicate things, so oppose" or "too many options, unclear, so oppose". Deprecation, cleaning up weird instances of appending open access to citations with closed dois when a free url was provided, and streamlining with other templates will make things much easier to address in the future. We haven't covered everything, but the RFC does give us a direction for were we should be heading. We've at least nailed down the body, possibly the shackle, and we know the color scheme left no one truly happy. We also know restrictions on locks is a nope, as is mandating the flagging of non-free sources. So let's implement what we can from the mega RFC, and revisit the few issues we haven't nailed down yet one by one. Headbomb {talk / contribs / physics / books} 23:46, 10 February 2017 (UTC)

This is why, when these RFCs were first proposed, I suggested that they be simple and not run simultaneously. We have the design RFC that closed with some modicum of consensus. But, its closure is muddied somewhat because it is dependent upon the affirmative closure of the behavior RFC. That closure, if I read the closer correctly, calls into question the very existence of these access signals. Specifically, the closer writes:"There is,however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS.  Overall, there is not yet significant consensus on implementation of these citation template behaviors. (non-admin closure) Eggishorn (talk) (contrib) 02:42, 10 February 2017 (UTC)" It isn't clear to me how this should be interpreted: I, for one, want a resolution that is unambiguous. As I suspect happens in many RFCs, this behavior RFC raised at least one issue not directly asked in the request: should we really be using access signalling? One could argue that because the question of access signal acceptability was not directly asked, many respondents to the RFC did not state an opinion on that specific point so those who did are disproportionately represented in closer's summary.
 * 1) remove whatever implementation has already occurred because "there is not yet significant consensus on implementation"; because a "significant body of opinion has been expressed ... that the entire visual status indicator idea is not acceptable"; because the close is "a tentative indication of how the Citation Template processing would work [if implemented after another RFC]"
 * 2) do nothing; treat the behavior RFC as 'no consensus' so what has been implemented remains implemented (default).
 * 3) implement those aspects of the behavior RFC for which the closer found consensus and ignore the "not yet significant consensus on implementation" because access signals are already in use and those aspects that did find consensus are relatively minor changes.
 * 4) some other interpretation that I haven't thought of?

There haven't been that many changes since the last module update (none that are pressing) but before the next update, I would like this particular issue to have been put to bed.

—Trappist the monk (talk) 14:15, 18 February 2017 (UTC)
 * The existence and use of the existing parameters registration/subscription, and templates like subscription/registration/Password-protected/Subscription or membership required/Subscription_or_libraries, as well as free access/open access/closed access makes it pretty clear there is consensus to flag access levels. Headbomb {talk / contribs / physics / books} 14:27, 18 February 2017 (UTC)


 * Yes there is consensus for flagging access requirements. There is no consensus for flagging access requirements via the scheme of icons proposed in the RFC. So this can be put to bed, I think. Remove the unsanctioned (i.e. consensus-lacking) code, and submit a better RFC. Perhaps a series of cascading RFC's, so that each level is agreed upon before further drilling down to finer detail. 65.88.88.126 (talk) 14:17, 22 February 2017 (UTC)