Help talk:Citation Style 1/Archive 30

Archive 25

←

Archive 28

Archive 29

Archive 30

Archive 31

Archive 32

→

Archive 35

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: Lewis Mumford (1934). "Chapter II:" 4: The Primitive Engineer (sectioned). Technics and Civilization (Harbinger Books, 1963 HC ed.). Harcourt, Brace & World, Inc. (published 1963). p. 76. LCCN 63-19641. {{cite book}}: |chapter-format= requires |chapter-url= (help); Invalid |script-chapter=: missing prefix (help); More than one of |pages= and |page= specified (help)

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—or gave a clue as to which direction to move in the new edition to adjust the given page range. FrankB 21:59, 15 December 2016 (UTC)

As far as I know, cs1|2 and specifically {{cite book}}, 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#Controlling error message display.

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!) FrankB 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, Trappist the monk. // FrankB

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=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 |postscript=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? FrankB

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. // FrankB 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 {{cite book}} 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 </ref> tag as your edit 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.(Richards 2013, pp. 596–597)

References

• Richards, E. G. (2013). "Calendars". In Urban, S. E.; Seidelmann, P. K. (eds.). Explanatory Supplement to the Astronomical Almanac (3rd ed.). Mill Valley CA: University Science Books. pp. 585–624. ISBN 978-1-891389-85-6. {{cite book}}: Invalid |ref=harv (help)

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. |page=6, ¶ 2 works to render "p. 6, ¶ 2.", or if you don't want to use the pilcrow, |page=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 |page=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 </ref> 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 {{cite book}} 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 requirement that in-source locators must 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 |pages=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)

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 the full citation is in a note (i.e., between <ref>...</ref> 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 {{cite journal |last1=<!-- --> |first1=<!-- --> |last2=<!-- --> |first2=<!-- --> |last3=<!-- --> |first3=<!-- --> |year=1989 |title=none |journal=Journal of Electroanalytical Chemistry and Interfacial Electrochemistry |volume=263 |issue=1 |pages=187–188 |doi=10.1016/0022-0728(89)80141-X}})" in a reference (see Journal of Electroanalytical Chemistry). The output is

• (Erratum in Journal of Electroanalytical Chemistry and Interfacial Electrochemistry. 263 (1): 187–188. 1989. doi:10.1016/0022-0728(89)80141-X.{{cite journal}}: CS1 maint: untitled periodical (link))

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 '"`UNIQ--templatestyles-00000014-QINU`"'<cite class="citation journal cs1">''Journal of Electroanalytical Chemistry and Interfacial Electrochemistry''. <b>263</b> (1): 187–188. 1989. [[doi (identifier)|doi]]:[https://doi.org/10.1016%2F0022-0728%2889%2980141-X 10.1016/0022-0728(89)80141-X].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Electroanalytical+Chemistry+and+Interfacial+Electrochemistry&rft.volume=263&rft.issue=1&rft.pages=187-188&rft.date=1989&rft_id=info%3Adoi%2F10.1016%2F0022-0728%2889%2980141-X&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+30" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: untitled periodical ([[:Category:CS1 maint: untitled periodical|link]])</span>)

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 <span> tag:

<span class="citation-comment" style="display:none; color:#33aa33"> CS1 maint: Untitled periodical ([[:Category:CS1 maint: Untitled periodical|link]])</span>

—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 <span class="citation-comment" style="display:none; color:#33aa33"> 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 margin-left:0.5em; to the style= attribute:

(Erratum in '"`UNIQ--templatestyles-00000018-QINU`"'<cite class="citation journal cs1">''Journal of Electroanalytical Chemistry and Interfacial Electrochemistry''. <b>263</b> (1): <span class="nowrap">187–</span>188. 1989. [[doi (identifier)|doi]]:[https://doi.org/10.1016%2F0022-0728%2889%2980141-X 10.1016/0022-0728(89)80141-X].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Electroanalytical+Chemistry+and+Interfacial+Electrochemistry&rft.volume=263&rft.issue=1&rft.pages=%3Cspan+class%3D%22nowrap%22%3E187-%3C%2Fspan%3E188&rft.date=1989&rft_id=info%3Adoi%2F10.1016%2F0022-0728%2889%2980141-X&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+30" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: untitled periodical ([[:Category:CS1 maint: untitled periodical|link]])</span>)

(Erratum in Journal of Electroanalytical Chemistry and Interfacial Electrochemistry. 263 (1): 187–188. 1989. doi:10.1016/0022-0728(89)80141-X.{{cite journal}}: CS1 maint: untitled periodical (link))

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)#References. 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)

@WhatamIdoing: following up with what the IP above me has said, look at Michigan State Trunkline Highway System#Works cited. In there you'll find that the "State Reward Trunk Line Highway Act" was published in 1915, but in the citation we have |orig-year=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)

@WhatamIdoing: 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: Michigan State Highway Department (1958). Official Highway Map (Map). [c. 1:918,720]. Lansing: Michigan State Highway Department. § A1. OCLC 12701120, 51856742. Retrieved October 17, 2019 – via Michigan History Center. (Includes all changes through July 1, 1958) 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:

Cite journal comparison

Wikitext	{{cite journal|arxiv=0910.5294|date=October 2010|doi=10.1016/j.physleta.2009.12.077|issue=10|journal=Physics Letters A/Physics-Bio PH.|title=DNA Breathing Dynamics in the Presence of a Terahertz Field|vauthors=Alexandrov BS, Gelev V, Bishop AR, Usheva A, Rasmunssen KØ|volume=374}}
Live	Alexandrov BS, Gelev V, Bishop AR, Usheva A, Rasmunssen KØ (October 2010). "DNA Breathing Dynamics in the Presence of a Terahertz Field". Physics Letters A/Physics-Bio PH. 374 (10). arXiv:0910.5294. doi:10.1016/j.physleta.2009.12.077.
Sandbox	Alexandrov BS, Gelev V, Bishop AR, Usheva A, Rasmunssen KØ (October 2010). "DNA Breathing Dynamics in the Presence of a Terahertz Field". Physics Letters A/Physics-Bio PH. 374 (10). arXiv:0910.5294. doi:10.1016/j.physleta.2009.12.077.

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:

• {{cite web |url=http://yahoo.com |archiveurl=http://liveweb.archive.org/http://yahoo.com |archivedate=June 3, 2016 |title=Yahoo! |work=Yahoo.com |author= |date=May 3, 2016 |accessdate=January 5, 2017}}

• "Yahoo!". Yahoo.com. May 3, 2016. Retrieved January 5, 2017. {{cite web}}: |archive-url= is malformed: liveweb (help)

This correctly renders with an error:

• {{cite web |url=http://yahoo.com |archiveurl=http://web.archive.org/http://yahoo.com |archivedate=June 3, 2016 |title=Yahoo! |work=Yahoo.com |author= |date=May 3, 2016 |accessdate=January 5, 2017}}

• "Yahoo!". Yahoo.com. May 3, 2016. Retrieved January 5, 2017. {{cite web}}: |archive-url= is malformed: timestamp (help)

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.

-- GreenC 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. -- GreenC 18:54, 5 January 2017 (UTC)

Ok:

Cite web comparison

Wikitext	{{cite web|accessdate=January 5, 2017|archivedate=June 3, 2016|archiveurl=http://liveweb.archive.org/http://yahoo.com|date=May 3, 2016|title=Yahoo!|url=http://yahoo.com|work=Yahoo.com}}
Live	"Yahoo!". Yahoo.com. May 3, 2016. Retrieved January 5, 2017. {{cite web}}: |archive-url= is malformed: liveweb (help)
Sandbox	"Yahoo!". Yahoo.com. May 3, 2016. Retrieved January 5, 2017. {{cite web}}: |archive-url= is malformed: liveweb (help)

—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. -- GreenC 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. -- GreenC 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 |author= Wu Ni, it won't work right for |ref=harv applications, and if |last=Wu |first=Ni (or even |surname=Wu |given=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)

|ref={{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:

1. create a new parameter, perhaps |surname-eastn=
2. 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=:

{{cite book/new |surname=Surname |given=Given |surname2=Surname |first2=Given |last3=Last |first3=First |title=Title}}

Surname, Given; Surname, Given; Last, First. Title.

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 |author-separatorn=none or |author-surname-firstn=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 |author-separatorn=none or |author-surname-firstn=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 {{cite journal}} 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.: |author=Wu Ni), as that is a misuse of "author", corrupts the metadata, and encourages stuff like |author=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 |author=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. • • • 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 {{citation/core}} for some cs1|2 templates and an old version of en.wikipedia's Module:Citation/CS1 for others. That then gives you some options:

1. copy en.wikipedia's Template:Cite AV media/old to v:Template:Cite AV media – probably simplest
2. create v:Template:Cite AV media based on v:Template:Cite web – may or may not work
3. 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-title=Heart has enough oxygen to survive hypothermia, CPR crucial |lay-url=http://www.eurekalert.org/pub_releases/2006-07/aps-hhe071206.php |lay-source=EurekAlert! |lay-date=18 July 2006

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)

Inconsistent behavior in para: format + para archiveurl

Take a look at what |format= is doing in {{cite web|url=http://www.isuskating.sportcentric.com/vsite/vfile/page/fileurl/0,11040,4844-188675-205897-133277-0-file,00.pdf |title=World Junior Figure Skating Championships: Ladies' results |work=International Skating Union |format=PDFlink |deadurl=yes |archiveurl=https://web.archive.org/web/20131224182426/http://www.isuskating.sportcentric.com/vsite/vfile/page/fileurl/0,11040,4844-188675-205897-133277-0-file,00.pdf |archivedate=2013-12-24 }}:

"World Junior Figure Skating Championships: Ladies' results" (PDF). International Skating Union. Archived from the original (PDFlink) on 2013-12-24. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

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 "World Junior Figure Skating Championships: Ladies' results" (PDF). International Skating Union. Archived from the original (PDF) on 2013-12-24. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help), which seems good to me. --Izno (talk) 02:50, 1 January 2017 (UTC)

|archive-format=:

{{cite web|url=http://www.isuskating.sportcentric.com/vsite/vfile/page/fileurl/0,11040,4844-188675-205897-133277-0-file,00.pdf |title=World Junior Figure Skating Championships: Ladies' results |work=International Skating Union |format=PDFlink |archive-format=PDFlink |deadurl=yes |archiveurl=https://web.archive.org/web/20131224182426/http://www.isuskating.sportcentric.com/vsite/vfile/page/fileurl/0,11040,4844-188675-205897-133277-0-file,00.pdf |archivedate=2013-12-24}}

"World Junior Figure Skating Championships: Ladies' results" (PDFlink). International Skating Union. Archived from the original (PDFlink) on 2013-12-24. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

—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:

• Cohen, Philip J. (1997). The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans [Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu] (in English and Croatian). Zagreb: Ceres. ISBN 978-953-6108-44-2.

 — 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.

Cite book comparison

Wikitext	{{cite book|first=Philip J.|isbn=978-953-6108-44-2|language=English, Croatian|last=Cohen|location=Zagreb|publisher=Ceres|sandbox=yes|title=Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu|trans-title=The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans|url=https://books.google.com/books?id=eSsyAAAAMAAJ|year=1997}}
Live	Cohen, Philip J. (1997). Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu [The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans] (in English and Croatian). Zagreb: Ceres. ISBN 978-953-6108-44-2. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox	Cohen, Philip J. (1997). Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu [The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans] (in English and Croatian). Zagreb: Ceres. ISBN 978-953-6108-44-2. {{cite book}}: Unknown parameter |sandbox= ignored (help)

--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 <p>...</p> 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 actual 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 <p> tags.[1] 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 "" error in zcash for this URL: https://z.cash/about.html. 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

{{cite web |url=https://twitter.com/AwqafM/status/560702214599999489 |title=zz |last= |first= |date=28 January 2015 |website=Twitter |publisher=وزارة الأوقاف - قطر |access-date= |quote=}}

"zz". Twitter. وزارة الأوقاف - قطر. 28 January 2015.

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:

"zz". Twitter. وزارة الأوقاف - قطر. January 28, 2015.

Even though wrapping the Arabic(?) text in a {{lang}} 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:

"zz". Twitter. وزارة الأوقاف - قطر (Qatari Ministry of Awqaf and Islamic Affairs). 28 January 2015.

— ^(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.

• وزارة الأوقاف - قطر [@AwqafM] (28 January 2015). الشيخ د.سعد بن عتيق العتيق خطيب يوم الجمعة 2015/1/30 بجامع الإمام محمد بن عبدالوهاب [Sheikh Dr. Saad bin Atiq old preacher on Friday, 30.01.2015 Mosque of Imam Muhammad bin Abdul Wahab] (Tweet) (in Arabic). Retrieved 27 January 2017 – via Twitter.

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 |language=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 this search, detecting |language=en-GB, |language=en-US etc. would be useful. --Redrose64 🌹 (talk) 14:25, 27 January 2017 (UTC)

|language=en does not display anything: {{cite web |title=Title |url=https://www.example.com |language=en|author=Author}} displays: Author. "Title". {{cite web}}: |author= has generic name (help); 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)

|language=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 |language=en at what seems to be a significantly higher rate than before. --Redrose64 🌹 (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#Make the link style consistent with cite xxx instead of magic links 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#Switch to using interwiki).

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#How_to_indicate_dead_implicit_links. -- GreenC 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)

 Not done 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 Redrose64's reversion is accepted. Peter coxhead (talk) 13:46, 4 February 2017 (UTC)

People's opinions differ, see Wikipedia talk:Citing sources/Archive 37#What do you do when there's no URL?. 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)

@Peter coxhead: 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.

@Arg342: 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. --Redrose64 🌹 (talk) 23:46, 4 February 2017 (UTC)

@Redrose64: but we're not talking about general searches. As Jc3s5h 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: "Search results for Yucca", The Plant List, retrieved 2017-02-05, where I know that /search?q=item added to the URL for the website is what is needed. But if I didn't know that, I could only provide something like: "Search page", The Plant List, Search for Yucca, retrieved 2017-02-05. 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? • • • 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 ({{webarchive}} 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. -- GreenC 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 {{{script-series}}} and {{{trans-series}}} parameters added to the {{Cite book}} template? Along the lines of {{{script-title}}} & {{{trans-title}}} and {{{script-chapter}}} & {{{trans-chapter}}}. 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)

Not done: please establish a consensus for this alteration before using the {{edit protected}} 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

Tracked in Phabricator
Task T157152

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 {{{script-series}}} and {{{trans-series}}} parameters added to the {{Cite book}} template? Along the lines of {{{script-title}}} & {{{trans-title}}} and {{{script-chapter}}} & {{{trans-chapter}}}. 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: |series=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

{{Identifier
 |link=Digital object identifier
 |display=doi
 |separator=:
 |id={{{1}}}
 |base-url-start=//dx.doi.org/
 |allow-free=yes
 |allow-limited=yes
 |allow-registration=yes
 |allow-subscription=yes
 |access-parameter={{{doi-access|}}}
}}

This way people can use {{doi |10.1234/123465 |doi-access=subscription}} to create doi:10.1234/123465 .

The code for {{PMC}} would become something like

{{Identifier
 |link=PubMed Central
 |display=PMC
 |separator= 
 |id={{{1}}}
 |base-url-start=//www.ncbi.nlm.nih.gov/pmc/articles/PMC
 |always-free=yes
}}

This way people can use {{PMC|2907408}} to create PMC 2907408 .

The code for {{bibcode}} would become something like

{{Identifier
 |link=Bibcode
 |display=Bibcode
 |separator=: 
 |id={{{1}}}
 |base-url-start=adsabs.harvard.edu/abs/
 |allow-free=yes
 |allow-limited=no
 |allow-registration=mo
 |allow-subscription=no
 |access-parameter={{{bibcode-access|}}}
}}

This way people can use {{bibcode|1974AJ.....79..819H}} to create Bibcode:1974AJ.....79..819H .

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? --AmaryllisGardener ^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 script_lang_codes which doesn't exist in sco:Module:Citation/CS1/Configuration.

—Trappist the monk (talk) 00:29, 14 February 2017 (UTC)

@Trappist the monk: Thank you! I'll get on updating the Config module right away. --AmaryllisGardener ^talk 00:42, 14 February 2017 (UTC)

Month-year access dates

Delaunay triangulation has a bunch of old |accessdate=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 (this edit 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

• |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.

Headbomb {talk / contribs / physics / books} 17:09, 16 February 2017 (UTC)

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? --Redrose64 🌹 (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?

Cite book comparison

Wikitext	{{cite book|title=url-access subscription|url-access=subscription|url=//example.com}}
Live	url-access subscription.
Sandbox	url-access subscription.

Cite book comparison

Wikitext	{{cite book|title=url-access registration|url-access=registration|url=//example.com}}
Live	url-access registration.
Sandbox	url-access registration.

Cite book comparison

Wikitext	{{cite book|title=url-access limited|url-access=limited|url=//example.com}}
Live	url-access limited.
Sandbox	url-access limited.

Cite journal comparison

Wikitext	{{cite journal|doi-access=free|doi=10.12345/12345|journal=Journal|title=doi-access free}}
Live	"doi-access free". Journal. doi:10.12345/12345.
Sandbox	"doi-access free". Journal. doi:10.12345/12345.

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.

/ / .

/ /

In lieu of the 50-50 split vote on

/ / . (main objection: yellow doesn't look yellow, hard for the color blind)

/ / . (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:

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?

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.

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)