Jump to content

Help talk:Citation Style 1/Archive 67

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 60←Archive 65Archive 66Archive 67Archive 68Archive 69Archive 70

Beachcat

Wrong venue. ―Mandruss ☎ 19:40, 7 June 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Beachcat is a brand name, see http://www.beachcatboats.net/ — Preceding unsigned comment added by Dddavis1954 (talk • contribs) 19:33, 7 June 2020 (UTC)

Your comment is not relevant to this page, which is for discussions about improvements to the page Help:Citation Style 1. If you want to propose a change to the article Beachcat, please do it at Talk:Beachcat. ―Mandruss ☎ 19:40, 7 June 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

number of pages

Hello,

the guide says that "pages=" is not for the total number of pages. But then, it there a field for this purpose?

Thank you. Rama (talk) 07:54, 26 April 2020 (UTC)

Afaik: no. --Francis Schonken (talk) 08:07, 26 April 2020 (UTC)
No and there shouldn't be, because citations are not supposed to describe the manifestation and we wouldn't. Similarly, you're not going to write that the volume is 21 cm, or other things you'd find in a library record. Nemo 08:14, 26 April 2020 (UTC)
(edit-conflict) While this is true in general, the page count is still sometimes a useful information for a reader, for example to estimate the size of a download (not everyone has a flatrate or highspeed connection), the paper copying costs when one wants to order a copy of the work from a library, or the postal costs for shipping of a sample (in that case, weight and physical size would be better metrics, but page count can still help to get at least a rough figure). I have (though rarely) seen the total page count given as part of the target page information in normal citations.
Also, citation templates are used for various purposes: One of them is as references to support statements in articles. Another very common usage is in "Works" sections, where the page count might be genuinely interesting to readers.
The page count is (perhaps not always the best metric but) something a reader might find useful when judging if it is worth the hassle to get a copy of a cited work to study in further details. Is a topic just mentioned somewhere, or is the source a substantial work on the topic?
So, yes, the page count is not essential information in references, but nevertheless it is sometimes convenient to know. Therefore, a |page-count= parameter is supported by citation templates in some other Wikipedias, and has often been suggested to be added to our templates as well in the past (clearly indicating that there is a demand for it among users regardless if it is essential informatin or not). It would help to format this information in a consistent way and show it in suitable places, instead of every editor having to invent his/her own style for it. I would therefore support the addition of such a parameter.
In lack of such a parameter, the page count can be appended to the template like " (n pages)" (still in the <ref></ref> section).
--Matthiaspaul (talk) 12:54, 26 April 2020 (UTC)
You would write that an specific edition is 21 cm, and that is what ISBN are pointing to, and we do have ISBNs. More importantly, page numbers are specific to a particular edition, and that is what we cite in articles. Rama (talk) 11:14, 26 April 2020 (UTC)

Imho:

Groote, Inga Mai (2003). Pietro Torri, un musicista veronese alla corte di Baviera. Sette note (in Italian). Vol. I. Broz, Barbara (Appendix: "I musicisti veneti in Europa ai tempi del Torri"). Verona: Della Scala. ISBN 8885099734. OCLC 681975493. 118 pages.{{cite book}}: CS1 maint: postscript (link)

... would be possible (this uses the |postscript= parameter for the number of pages info). --Francis Schonken (talk) 11:24, 26 April 2020 (UTC)

I presume that by |others=Broz, Barbara (Appendix: "I musicisti veneti in Europa ai tempi del Torri") you mean that you are citing the appendix authored by Broz in Groote's work. For that, we have |contributor= and |contribution= so:
{{cite book |title=Pietro Torri, un musicista veronese alla corte di Baviera |last=Groote |first=Inga Mai |year=2003 |publisher=Della Scala |location=Verona |isbn=8885099734 |lang=it |contributor=Broz, Barbara |contribution=Appendix: "I musicisti veneti in Europa ai tempi del Torri" |series=Sette note |volume=I |oclc=681975493 |postscript=. 118 pages.}}
Broz, Barbara (2003). "Appendix: "I musicisti veneti in Europa ai tempi del Torri"". Pietro Torri, un musicista veronese alla corte di Baviera. By Groote, Inga Mai. Sette note (in Italian). Vol. I. Verona: Della Scala. ISBN 8885099734. OCLC 681975493. 118 pages.{{cite book}}: CS1 maint: postscript (link)
If that is the case, |postscript=. 118 pages.= implies that the appendix is 118 pages. Is it?
—Trappist the monk (talk) 12:02, 26 April 2020 (UTC)
No, you just made a complete mess of it. The book is by Groote with an appendix by Broz: the entire book (main part by Groote, including appendix by Broz) is 118 pages. --Francis Schonken (talk) 12:27, 26 April 2020 (UTC)
I agree with Rama that "page numbers are specific to a particular edition, and that is what we cite in articles", if Rama means that the page, or pages, that contain information supporting what is in the Wikipedia article. But in the Citation Style 1 used by the citation templates, similarly to external style guides like Chicago Manual of Style or APA Publication Manual, does not give the total number of pages in a book that is cited. Sometimes, if citing a journal article, the page or page range of the entire article is given, especially when using short citations. In that case, each endnote would give the page(s) that support the specific spot where information supporting the claim just before the endnote. The bibliography entry would give the page(s) of the whole article. For example

The Holoscene era began approximately 11 700 calendar years before AD 2000.[1]

References

  1. ^ Walker et al. 2009, p. 1.

Works cited

  • Walker, Mike; Jonsen, Sigfus; Rasmussen, Sune Olander; Popp, Trevor; Steffensen, Jørgen-Peder; Gibbard, Phil; Hoek, Wim; Lowe, John; Andrews, John; Björck, Svante; Cwynar, Les C.; Hughen, Konrad; Kershaw, Peter; Kromer, Bernd; Litt, Thomas; Lowe, David J.; Nakagawa, Takeshi; Newnham, Rewi; Schwander, Jacob (2009). "Formal definition and dating of the GSSP (Global Stratotype Section and Point) for the base of the Holocene using the Greenland NGRIP ice core, and selected auxiliary records". Journal of Quaternary Science. 24 (1): 3–17. doi:10.1002/jqs.1227.
Jc3s5h (talk) 12:05, 26 April 2020 (UTC)

...which would look quite silly for books:

Groote, Inga Mai (2003). Pietro Torri, un musicista veronese alla corte di Baviera. Sette note (in Italian). Vol. I. Broz, Barbara (Appendix: "I musicisti veneti in Europa ai tempi del Torri"). Verona: Della Scala. pp. 1–118. ISBN 8885099734. OCLC 681975493.

Not the way "total number of pages" is made clear: looks like an excerpt of a larger publication. --Francis Schonken (talk) 12:27, 26 April 2020 (UTC)

& I disagree that total number of pages, that is, for an entire book (as opposed to an excerpt like an article in a journal), is more than very exceptionally useful as information in references: if and when it is (e.g. two editions of the same pre-ISBN book in the same year, only different in number of pages), the |postscript= parameter can be used to indicate the number of pages. --Francis Schonken (talk) 12:57, 26 April 2020 (UTC)

The number of pages in a book is not something that should be supported. Headbomb {t · c · p · b} 15:00, 26 April 2020 (UTC)

We might reconsider renaming |pages= to try and reduce this problem. It is very common perhaps 15% to 20% of all book citations misuse |pages=. It's an understandable mistake. -- GreenC 15:33, 26 April 2020 (UTC)

Don't see how this would remedy anything about the problem without making something else worse. --Francis Schonken (talk) 16:47, 26 April 2020 (UTC)
I would consider one exception, and that would be in articles about books. There, it would make sense to include a bibliographic entry that includes the number of pages or the file size. If the biblio entry is formatted via a cs1/2 template, I would use |nopp=y and the number of pages/kbytes with the appropriate suffix. 98.0.246.242 (talk) 15:59, 26 April 2020 (UTC)
Writing an article about a book is a different task than citing a book in any other article. A good practice in an article about a book is to use Template:Infobox book. That template has a |pages= parameter. Jc3s5h (talk) 16:23, 26 April 2020 (UTC)
For books, that would look like this:

Groote, Inga Mai (2003). Pietro Torri, un musicista veronese alla corte di Baviera. Sette note (in Italian). Vol. I. Broz, Barbara (Appendix: "I musicisti veneti in Europa ai tempi del Torri"). Verona: Della Scala. 118 pages. ISBN 8885099734. OCLC 681975493. {{cite book}}: Unknown parameter |nopp= ignored (|no-pp= suggested) (help)

Wouldn't do that, seems like a less suitable workaround. For kbytes this amounts to nonsense. E.g. Johann Sebastian Bach: His Life, Art, and Work:
(with a few exceptions these are all full copies of the same book). --Francis Schonken (talk) 16:47, 26 April 2020 (UTC)
I believe the file size could be used in bibliographic entries when the work has been officially published in digital media, along with |format=, and perhaps |via= if the digital provider is not the official publisher. 98.0.246.242 (talk) 17:07, 26 April 2020 (UTC)
No, imho, file size would not be the type of characteristic of a book to adopt in any cite template. Generally, books don't have an "official" file size, and publishers would often publish the same book in different resolutions (leading to different file sizes) and/or different formats (PDF, specific screen reader formats, etc – also leading to different file sizes) – even the outlet where one accesses a digital publication (e.g. Google books vs. other vendors) may lead to file size differences. This is not generally a characteristic that identifies a "book", not even a characteristic that would allow to distinguish official editions from bootlegs. --Francis Schonken (talk) 06:40, 27 April 2020 (UTC)
Just to prove that the total number of pages is sometimes actually used in citations in academia, here are two examples where an author of the University of Illinois used this in the citations he gave in his papers:
The syntax he used is ", ? p[p]." appended at the end of the citation, similar to what I propose: " (? page[s])" for |total-page[s]=? in #Question_about_page_parameter_in_Template:Cite_journal.
--Matthiaspaul (talk) 13:52, 7 May 2020 (UTC)
This book uses "XI+393 pages":
  • Dokter, Folkert; Steinhauer, Jürgen (1975) [1970]. Digitale Elektronik in der Meßtechnik und Datenverarbeitung: Anwendung der digitalen Grundschaltungen und Gerätetechnik. Philips Fachbücher (in German). Vol. 2 (4 ed.). Hamburg, Germany: Deutsche Philips GmbH. ISBN 3-87145-273-4.
--Matthiaspaul (talk) 19:08, 8 May 2020 (UTC)

Inconsistent citation, Articles with inconsistent citation formats, and a historical function of Citation Bot

Category:Articles with inconsistent citation formats explains its purpose via {{Inconsistent_citations}} which I include, in part, here:

I had been cleaning up this maintenance category based on the explanation above.

Observations of what I encountered
Issues
  • User:Citation Bot no longer applies a CS style fix or adds the postscript
  • the inconsistency in reference style within articles is much more common and covers many more variations
  • these common inconsistencies exceed and outlast whatever original intent the category and template were intended to communicate
Questions
  • How then should we improve the category/tag?
  • Is this the the right place for the conversation to take place?
Recommendation
  • Convert {{Inconsistent_citations}} into a maintenance tag OR
  • mark it and the category as historical
  • make it clear to editors that maintenance categories should not be applied directly to articles

—¿philoserf? (talk) 16:48, 8 May 2020 (UTC)

I never liked that template, but possibly because the CS1 templates are nowadays much more consistant than back when this was added by bots. One thing that will greatly help is having mode markers which will allow for scripts to be made that highlights if something is in CS1, CS2, or something else entirely. Which would make it easier to see if things are actually inconsistent or not. Headbomb {t · c · p · b} 16:56, 8 May 2020 (UTC)
Just pondering aloud for a moment... if all of the main templates have been converted to use the module, and if CS1 now has |ref=harv by default like CS2, then is the only remaining difference between the two the punctuation, couldn't that last item be harmonized at some point? If so, we'd have just a CS without need for the number, and there would be no need to worry if an article mixed the template families because they'd be one family. Again, just pondering aloud. Imzadi 1979 → 21:06, 8 May 2020 (UTC)
Please step carefully away from the third rail. At least start a new thread. – Jonesey95 (talk) 23:19, 8 May 2020 (UTC)

No response to the recommendation yet. Reiterated below without the surrounding text.

Recommendation
  • Convert {{Inconsistent_citations}} into a maintenance tag OR
  • mark it and the category as historical

—¿philoserf? (talk) 01:46, 12 May 2020 (UTC)

I say convert it to {{cleanup}} with a reason of "Citation styles are a mix of Citation Style 1 and Citation Style 2" in the 200 or so articles in which is appears, then nominate the template and the category for deletion. – Jonesey95 (talk) 14:09, 12 May 2020 (UTC)

Proposal: page-range

Proposing the addition of a new argument |page-range= to replace |pages=.

Currently two problems relate to |pages=:

  • The name "pages" is ambiguous. Users frequently interpret this to mean total number of pages in a book. This has knock-on effects with bots linking to electronic copies of the book at the wrong/last page. This is a real and widespread problem.
  • There is no mechanism to indicate a page range and a page, which is useful in journals, anthologies of magazines, and sometimes books.

Thus it is be possible to use both |page= and |page-range= in a citation. For example:

|page=42 with |page-range=40-50 would produce: 40-50 [42] or something similar.

And it resolves the ambiguity of "pages" which means a range of pages. -- GreenC 13:43, 4 May 2020 (UTC)

  • Support. Per above. 50.74.165.202 (talk) 14:23, 4 May 2020 (UTC)
  • Support. I support the idea in general, but not the suggested parameter name. Per the meanwhile established underlying scheme how we name new parameters, the parameter should end on "pages" rather than start with it. We are just discussing a very similar extension at #Question_about_page_parameter_in_Template:Cite_journal, where I proposed |span-page[s]= for this, and we also discussed possible output format notations. Alternatives could be |chapter-page[s]= for books or |article-page[s]= for journals and magazines, but they imply semantics which I tried to keep out of the parameter name in the more general |span-page[s]= suggestion. --Matthiaspaul (talk) 14:37, 4 May 2020 (UTC)
  • Oppose, that's what |pages= are for. No citation style says to put the total number of pages in a book. I'd might be ok with something like |specific page(s)=, but really that's why you write something like "See page 34 in {{cite journal|...}}" or similar. Headbomb {t · c · p · b} 14:38, 4 May 2020 (UTC)
    Which would be one out of many ways to specify it. The underlying idea of the various suggestions for more specific page-related parameters is to define a proper (machine-readable) place where to put some specific type of page information (and, by the "self-explanatory" name of the parameter, explictly declare that the given page value is of a particular type). This will help to reduce (and eventually eliminate) the misuse of the old |page[s]= parameters for things they were not designed for, and also allow us to provide the information in a consistent, centrally controlled format rather than letting every user invent his own style. So, if we would find a better notation in the future or want to introduce responsive templates or user-definable template output, we could easily switch to new output formats instead of having to maintain citations on an individual basis, only being able to guess which type of page information was meant by an original editor.
    GreenC proposes to add a parameter for ranges, and treat the existing |page[s]= parameter as a parameter for individual pages. However, like you, I think to remain compatible with the existing usage of |page[s]=, we would have to treat it as an alias for page ranges rather than individual pages, and instead introduce new parameter(s) for specific pages (which I called |cite-page[s]= in my proposal, but |specific-page[s]= would be another option). For orthogonality, I also proposed to introduce |span-page[s]=, so that users could deliberately declare a specific type of page info, rather then having to rely on the old ambiguous |page[s]= parameter for this.
    However, the underlying idea of both proposals is the same, and I take it from your vote that, despite the Oppose, you do not actually oppose the underlying idea of more specific page parameters in general, right?
    --Matthiaspaul (talk) 15:19, 4 May 2020 (UTC)
    The documentation is [also] the name of the parameter. Templates should be non-editor-hostile, be clear what they mean, not introduce ambiguities that create real and widespread technical problems. Evidently "rtfm" isn't working for |pages=. -- GreenC 15:34, 4 May 2020 (UTC)
    I agree with Headbomb that the total number of pages is irrelevant information to begin with. --bender235 (talk) 23:21, 7 May 2020 (UTC)
  • The citation templates currently have a deficiency in that they cannot express both the full citation of a journal article (or separately-authored chapter in an edited book) and the part of the article that supports a statement. However, allowing parameters for singular and plural pages to co-exist does not achieve that either, because sometimes the part that supports the statement will not be a single page. (Sentences, and paragraphs, can span pages.) Kanguole 14:42, 4 May 2020 (UTC)
    I think, we will have to give up the idea of strictly singular and plural pages for a broader concept. Thinking about it, what we actually mean is individual pages used to support (one or more) statements in an article (typically singular, but not always), and a (possibly fragmented) span of pages defining the whole article / chapter (typically plural, but not always). What holds true is that the page span will always be equal to or a superset of the set of individual pages.
    So, while we would normally get something like (using both suggested notations)
    40-50 [42]
    42 (40-50)
    things like the following would also be possible:
    40-50 [42-44]
    42-44 (40-50)
    Even something like:
    42-43, 45-50 [43, 45-47, 49]
    43, 45-47, 49 (42-43, 45-50)
    If both were equal, as in the following example
    42-44, 50 [42-44, 50]
    42-44, 50 (42-44, 50)
    the template could switch to a simpler output format:
    42-44, 50
    42-44, 50
    Another example of equal sets:
    43 [43]
    43 (43)
    and the corresponding simplified output:
    43
    43
    Likewise, when only one type of pages was given.
    --Matthiaspaul (talk) 15:49, 4 May 2020 (UTC)
    Having experimented with both proposed notations in a number of real-world examples in the sandbox, I think, I like the [square-bracket] notation more than the (round-bracket) notation:
    It is easier to distinguish from number issues in journals/magazines, and it loosely resembles other uses of square brackets where we list the important information first followed by related additional information of the same type in square brackets (e.g. |orig-year=, |trans-*=). Round brackets are already used for diverse purposes (dates, issue numbers, types, languages, comments) as part of the normal citation syntax. Also, using square brackets for the extra page info would avoid clashes with the occasional existing use of round brackets for other purposes (alternative page numbers, extra commentary regarding particular pages, etc.) seen in some citations.
    However, I remain open for other suggestions, in particular some which might already be in use somewhere.
    --Matthiaspaul (talk) 19:21, 5 May 2020 (UTC)
    |page-range=, strictly read, is problematic. Editors may legitimately cite multiple pages that are not contiguous; |page-range=, strictly read, precludes that legitimate use.
    I think that I support some solution that eliminates the ambiguity of |pages=. I do not support |page-range= as that solution. Of course your question to me is: what is a better parameter name? Alas, I don't know. |pages-set= because 6, 23 and 40–50 represent sets of pages?
    And, minding the omg!-the-sky-is-falling! reaction to the deprecation and replacement of |dead-url=, any decision resulting from this discussion will likely bring out the torches-and-pitchforks crew who will blame me.
    —Trappist the monk (talk) 14:59, 4 May 2020 (UTC)
    One can have multiple page ranges with the alias |page-ranges=. Or whatever "ranges" is called. -- GreenC 15:40, 4 May 2020 (UTC)
    Following the same logic as with |author-*=, |editor-*=, |chapter-*=, |archive-*=, |script-*=, |trans-*=, |orig-*=, I think a parameter refining/altering the existing parameter |page[s]= should be named |range-page[s]= rather than |page-range[s]=.
    As you pointed out, given that the parameter may also be used for articles/chapters distributed over multiple locations in a work, it would also need to accept multiple page ranges. However, the template's output "p."/"pp." depends on the count of pages, not the count of ranges, which would be another reason for the paramter to end on |-page[s]= rather than |-range[s]= (unless the template could reliably auto-detect singular/plural of pages).
    Looking for synonyms ("range", "span", "set", "extent"), and in particular some for which fragments would not sound strange, my order of preference would be "span", "extent", "range", "set". Somehow, |range-page[s]= looks odd to me, whereas |span-page[s]= does not, but YMMV. Also, I think, "set" is a bit too vague in general and could be easily misunderstood. Are there other suitable synonyms? "chapter" would be quite suitable for books, but would sound strange for journals/newspapers/magazines, vice versa for "article". That's why I was looking for a more abstract term, which could be used in all citation templates without looking out of place. Suggestions?
    --Matthiaspaul (talk) 10:01, 6 May 2020 (UTC)
    Re |url-status= so long as the template supports both the old and new at the same time, without emitting red warnings, bots have time to convert to the new, then turn on the warning messages - after a couple months for example. It was the sudden red lights that really upset everyone. I have no problem writing a bot for this, I have custom CS1|2 libraries. -- GreenC 20:43, 4 May 2020 (UTC)
    Trappist the monk, I didn't understand your point about contiguous pages. Where an article in an edited volume or journal covers pages 10–40, that's the page range (page range=10–40). Or the article might be split up (page range=10–20, 30–40). Within that article, the text we're adding is supported by something on page 11 (page=11) or on pages 11–12 (pages=11–12). SarahSV (talk) 21:38, 6 May 2020 (UTC)
    The proposal is to create a new parameter to replace |pages=. The suggested replacement is |page-range=. I understand 'range' in this context to mean a contiguous series of page numbers from m to n where m is the lower bound and n is the upper bound; all page numbers between m and n are included in the 'range'. I do not understand 'range' to mean a discontinuous collection of individual page numbers and/or page-number ranges. |page-range= is singular, not plural. Perhaps I'm being pedantic, but if we are to create a new parameter to replace |pages=, the name we choose for that parameter should describe what it is that the parameter will hold. So I suggested |pages-set= because that name allows for a simple page-number range, a comma-separated list of page ranges, a comma-separated list of individual page numbers, or combinations of these. Perhaps too esoteric. So perhaps, because we are citing multiple pages of a source to support text in an en.wiki article, |multi-pages=?
    —Trappist the monk (talk) 23:26, 6 May 2020 (UTC)
    I realize that everyone is reading the various suggestions a little bit different. ;-) So, I think, it is only good to be as specific as possible so we get a clearer picture and can better align our mind models.
    Regarding "set" and "multi". Isn't this a bit too vague? I mean, what the parameter is supposed to be used for is not to give an arbitrary set of pages (like the set of pages supporting one or more statements in an article), but a number of pages defining a complete set of chapter/article pages. IMHO, "range" is a much better term for this (but IMHO still not the best possible), and if we'd use |range-pages= rather than |page-range= we could also avoid the singular/plural issue.
    (But GreenC's proposal does not cover a number of corner cases yet, so it would still need to be further refined. I will come back to this later.)
    --Matthiaspaul (talk) 01:46, 7 May 2020 (UTC)
    The purpose of a citation is to identify the source that supports the content of an en.wiki article. WP:V § Responsibility for providing citations says: Cite the source clearly and precisely (specifying page, section, or such divisions as may be appropriate). We have tools, citoid etc, that scrape publisher websites and then populate |pages= with the page range that the publisher provides (I notice this most for journal cites). Very often, these sorts of citations are in-line and the editor does not override the tool to comply with the precision clause in WP:V to provide a precise page location for the one sentence or the one paragraph that supports the en.wiki article. The reader then has no recourse but to search through all however-many-pages are listed in |pages=m–n. For bibliographic listings, this automatic publisher scraping method is fine as long as there is a short-cite pointing to the long-cite. In both forms (in-line and bibliographic) |page= and |pages= are sufficient to accomplish the task of identifying the in-source location for the reader. Because of the WP:V precision requirement, cs1|2 renders the value in |page= when both it and |pages= are present in a template.
    I am usually indifferent to what external style guides say but in this case I agree with what appears to be the CMoS rules. Paraphrasing:
    • For in-line citations (their notes form) provide the specific page number or numbers in the source that support the en.wiki article.
    • For bibliographic listings, provide the occupied page-number range for book chapters and journal articles; omit page-number range for magazines and newspapers
    The problem identified by Editor GreenC is that editors mistakenly use |pages= to list the total number of pages in the source; that could be the whole book or whole chapter or whole article (I've also seen it used to hold the page number of the last page in the source article or the last page of interest).
    I see no reason to provide specific in-source pagination for source content that supports en.wiki content and in the same citation provide the pagination limits for the whole source. Simple and clean is best.
    But, I'm getting ahead of myself. The thing that needs doing first is to define the cs1|2 style. Does cs1|2 follow CMoS? Does it follow some other style guide? Does it strike out on its own and do something completely different? Once a style decision is made, then, if necessary, we can consider how to implement that decision.
    —Trappist the monk (talk) 13:07, 8 May 2020 (UTC)
I assume you are being humorous. This is after all Citation Style 1, where a large part of what we do here is to discuss presentation. Also, most elements of the native style are encoded. Placement, emphasis, punctuation etc. There is little leeway for editors to improvise, and that is not necessarily a bad thing since this is not a creative endeavor. However (and perhaps confusingly to some) this discussion is not just about style, but also structure. We are asked to justify certain citation elements, not just the way they are presented. In citations form should follow function. Whatever increases clarity, conciseness and speed in discovery should come first, and following that I'm sure proper presentation will be arrived at. Personally I preferred the old arrangement where strictly technical stuff was at the module talk page, overall presentation and design of cs1 in this page, and applications of the style in the template pages and elsewhere, since not all applications of cs1 in a Wikipedia article have to be templated. But that's just me. 98.0.246.242 (talk) 20:58, 9 May 2020 (UTC)
  • Trappist the monk, I wouldn't support removing pages=. There's no connection between that and page-range=, and it's singular (one range, several pages). As for contiguity, it's mostly in newspapers that the range will be split up (page-range=3, 16–20). SarahSV (talk) 22:32, 7 May 2020 (UTC)
    Proposing the addition of a new argument |page-range= to replace |pages=. (emphasis mine) That is the proposal, so yes, there is a connection. m–n is a single range citation. 3, 16–20 is not a range; it is a comma-separated list containing an individual page and a range of five contiguous pages; it is a multi-page citation.
    —Trappist the monk (talk) 13:26, 8 May 2020 (UTC)
  • Oppose as unnecessary. Just change the documentation to standardize on a format like "20–30 [28]". – Jonesey95 (talk) 15:03, 4 May 2020 (UTC)
    That is a fair suggestion. To add teeth to it though, there could be a parameter whose use would encode that format. 50.74.165.202 (talk) 15:10, 4 May 2020 (UTC)
  • Oppose as complexity with no discernable added benefit; also, an output like "pp. 20–30 [28]" is counter-intuitive: the guidance at WP:REFPAGE suffices to handle cases where both a page range and a page number are needed for a reference. --Francis Schonken (talk) 10:27, 6 May 2020 (UTC)
    WP:REFPAGE does not address page ranges at all.
    I accept it as your opinion that something like "pp. 20–30 [28]" is counter-intuitive to you. In contrast to this, I find it rather intuitive, in the sense that a reader, who has no prior knowledge of any documentation about it, will likely find out what it means by himself - if not immediately, then at least after having seen a couple of examples in other citations. He won't be able to misinterpret it for something else, and he would still be able to make good use of the citation (to the extent that was possible before the introduction of this extension) by simply ignoring it. Being backward-compatible and self-explanatory are signs of a good notation.
    I also accept that you do not see a need for more specific parameters, and that you do not have a use for it - and won't be forced to use it. However, other users have a use for it, and have been asking and complaining and suggesting about it often enough in the past. Since Wikipedia is an encyclopedia aimed at everyone, not just you personally, this warrants a discussion how to elegantly solve the underlying problem of |page[s]= being a parameter ambiguous enough to be used for several purposes depending on the article and citation in question as well as on the style guide an editor might be used to.
    Some users use it to list individual pages supporting statements in an article, whereas other users use it to specify the page range occupied by an article. Yet some users switch between these uses depending on the type of work they are citing or the count of pages in the list. This often enough leads to ambiguous information and usability issues:
    For example, an editor might specify the page range of a long treatise within an even larger work although the topic is only mentioned on a single page (or several of them - it doesn't really matter for this example in general). Seeing this reference, a reader might expect something fundamental supporting the statement and happily place a copy order in a library getting 100 pages in return. After carefully studying them, he will find the topic being mentioned on a single page (perhaps even a single sentence), so ordering this particular page (if any at all) would have been all that was needed: An enormous amount of resources, money and time wasted. Even worst, another reader might overlook that single occurence in the huge pile of pages and erroneously remove the citation from the article as not supporting the statement.
    In another citation, a reader will only find a single page being mentioned, although the topic is covered at large in the surrounding pages. Perhaps, the reader would not be able to understand the single page citation out of context. So, the reader might want to order the whole chapter, but since the editor did not provide any information about the page range, the reader has no chance to find out about it other than by trial-and-error (perhaps several times), or ordering the work as a whole (which might not be feasible, because it is too large or expensive).
    In yet another citation, the editor specified only the starting page of a page range rather than the actual page range (an awkward but common notation), assuming the reader would be able to find out the last page by knowing the start page of the next chapter. However, this may create page overlap, and is not always applicable at all (no access to the table of contents or index, or, as in case of newspapers or magazines, fragments of an article being scattered over the whole publication). Also, the reader might confuse the start page with an individually cited page, order it, and get nothing useful in return at all. And if he does not recognize the reason for this, he again might be tempted to remove the citation from the article.
    These are only some of many examples of common scenarios readers are facing, but from them alone it should be clear that the existing practise leaves a lot to be desired and that, with some minor (and fully backward-compatible) tweaks as suggested, it is possible to improve the usability of the system considerably. This will not only be for the convenience of our readers, but also ease the usage of citation templates for editors and in the end it will improve the quality of our citations.
    --Matthiaspaul (talk) 12:56, 6 May 2020 (UTC)
    Re. "WP:REFPAGE does not address page ranges at all" – I should have mentioned "WP:REFPAGE in addition to cs1/cs2 documentation". Sorry for assuming that as understood: it is explicit now.
    Further: would it be possible to condense your contribution a bit? I have read prior discussion before formulating my "oppose", which thus was well-informed, and does not need a re-run of prior argumentation as reply. Is there anything new in your reply? Please, strike the rest, so that we can come down to business: as is, I'd refer you to guidance like WP:BECONCISE and WP:TEXTWALL. Tx. --Francis Schonken (talk) 14:03, 6 May 2020 (UTC)
  • Support. We need page= and pages= to give the page(s) we need to point to. We also need page range= to give the page range of the journal article or article in an edited volume. SarahSV (talk) 21:28, 6 May 2020 (UTC)
  • Support i second Sarah, this would solve a lot of problems! --Gyanda (talk) 14:30, 15 May 2020 (UTC)
  • As far as I know our templates are currently hardwired to assume either singular or plural of pages (and emit either "p." or "pp.") depending on if |page= or |pages= is used, right? There is no auto-detection for this, or is it? --Matthiaspaul (talk) 01:46, 7 May 2020 (UTC)
  • I think that page-range= (or page-span= which i would mildly prefer) shoiuld not replace pages= but should be in addition to either page= or pages= which should continue to specify a single or multiple pages where the actual fact being cited is supported. DES (talk)DESiegel Contribs 13:59, 11 May 2020 (UTC)
The problem is that |pages= is ambiguous and a large percentage of editors are misusing it. You might say not our problem RTFM, but the template is designed to be self-documenting, editors are not required to be experts of the documentation page, the names of the arguments are the documentation. The word "pages" is misleading editors to think it means one thing and not another. It is creating a significant problem that can't be easily fixed by bot. The longer this goes on, the bigger the problem becomes. It's now impacting other bots and processes as well. -- GreenC 13:48, 15 May 2020 (UTC)
Indeed, but not only that, copy-pasting and re-using and 'learning via wikicode' type of people will utterly ignore the documentation. They will see |page*= and just put whatever pages they want to put, regardless of which of |page=, |pages=, |page-range=, |page(s)-directly-supporting-the-information-i'm-citing= is used. Solution, KISS, and have |pages=16–32 [18] to say page 18 in an article spanning pages 16 to 32. Or use {{rp}}, {{sfn}} etc... Breaking the existing designs will cause more problems than it solves. Headbomb {t · c · p · b} 19:15, 15 May 2020 (UTC)
Fortunately the proposal does not break anything. The fault is the template, not users. Get rid of "pages" and the problem will drop by 90% or more. Very few people will mistake "page" or "page-range" for the total number of pages in a book. We know this because we rarely if ever see "page" being misused this way. -- GreenC 19:58, 15 May 2020 (UTC)
The total number of pages in a book is irrelevant and does not contribute anything towards WP:V. |page= and |pages= are routinely confused with and misused for each other. That would only grow worse with other parameters named page-something. Headbomb {t · c · p · b} 20:01, 15 May 2020 (UTC)
I'd rather fix the template then millions of user's understanding of what "pages" means. The confusion you mention would be lessened with more precise terminology by replacing the problematic "pages". -- GreenC 21:10, 15 May 2020 (UTC)
It would not clarify anything, because |pages= would remain valid, most people would not even known |page-range= exists, and no one (bibtex, scientific journals) calls this bibliographic information page range. Which means pretty much everyone would keep using pages for this. Headbomb {t · c · p · b} 21:23, 15 May 2020 (UTC)
  • Headbomb, So far as I can see, a proposal to add a parameter |page-range= or |page span= does not break anything. I don't think anyone is arguing that providing the number of pages in a book is useful bibliographic data (well in a very few cases it allows distinguishing editions of older works not otherwise having different bibliographic data, but that is quite rare). But some do argue that listing the range or set of p0ages that make up ma journal article or chapter is of value, and is common in some academic citation styles. (Indeed CMoS says to mdo so in bibliographies. But replacing or deprecating the |pages= parameter would break many existing citations, and making pages an alias of page would lose a significant (and traditionally provided) bit of data, plural or singular number of pages actually being cited. Moreover, the parameters for the various CiteX templates are supposed to be as consistent as possible and in {{cite book}} and {{Cite News}} and others |pages= always means the specific list of pages where the supporting info is to be found. We should not lose that consistency, nor be forced outside the template proper. Adding a |page-range= (or similar, whatever we call it) would handle that case while leaving behavior unchanged for existing cases. Now if the tempalte orm the module it calls could be enhanced to detect that the content of |page= indicated multiple pages, and emit "pp.", instead of "p.", then i could support making "pages" an alias of "page", and adding page-range to that. That would also allow bot conversion with no mloss of functionality or data. DES (talk)DESiegel Contribs 20:33, 15 May 2020 (UTC)
It becomes redundant to |pages= which is already the parameter to put page ranges in and creates even more confusion. Headbomb {t · c · p · b} 20:35, 15 May 2020 (UTC)
According the the documentation on {{cite journal}} and {{cite book}} when citing a specific chapter, pages is not the parameter to put page ranges in, nor should it be, because that means |pages= would be used for very different purposes in {{cite news}} and other CiteX templates than in {{cite journal}}, which is highly undesirable. According to the template documentation, |pages= is now the parameter in which to put the exact pages where the cited info is to be found, when there is more than one such page. By "page range" other in this discussion mean "the total set of pages making up the article, even if the cited info is found on only one or a few of these". I think that pages should not be used for a page-range in that sense. Thus there is no redundancy, and those given to copying existing template uses will perhaps have better models to work from. DES (talk)DESiegel Contribs 20:49, 15 May 2020 (UTC)
If it says that, the documentation is wrong then, because |pages= for journals is to indicated the pages of the article being cited. It would also mean that millions of |pages= would need to be converted to |page-range=, and then cause huge confused about which of |page=, |pages= or |page-range= to use, and they would all be badly used. Again, the solution is to use |pages=18–32 [26]=. #32;Headbomb {t · c · p · b} 20:52, 15 May 2020 (UTC)

Et al

I don't know where to bring this up, so I'll do it here. When editing, above the text window there's a sort of menu bar that one can use to put text in bold or italics, to add one's signature, and so on, and then finally the word "Cite". If one clicks on that, then a bar appears just below that menu bar, with the word "Templates". If one puts the cursor on that, one gets a menu of "cite web", "cite news", "cite book", and "cite journal". I often use this. When I click on "cite journal", I get a pop-up box in which I can put the author, title, et cetera. But if there are a lot of authors, then I want to use "display-authors=etal". It would be very nice if there were an option in that pop-up box to tell it to include "display-authors=etal"! Can someone add that, or tell me where I should go to make this request? Eric Kvaalen (talk) 09:11, 15 May 2020 (UTC)

You should probably take this request to WP:RefToolbar.
—Trappist the monk (talk) 10:28, 15 May 2020 (UTC)
@Eric Kvaalen: Until then, you can add additional parms manually to most existing fields in the citation tool. For example, if the OCLC field is not being used, just put |display-authors=etal in it and it will be added to the resulting cite (after an empty |oclc=). Even if a field is being used, you can usually add |display-authors=etal after the field contents. —[AlanM1 (talk)]— 09:00, 16 May 2020 (UTC)


Thanks to both of you. The idea of writing "display-authors=etal" in one of the fields doesn't really help much -- I don't want to have to type it at all. Anyway, I have now made the request at Wikipedia talk:RefToolbar. Eric Kvaalen (talk) 12:33, 16 May 2020 (UTC)
@Eric Kvaalen: Yeah – I didn't know if that was the issue. I use WinCompose to create letters with diacritics and realized it can just as easily be used to create commonly used wiki sequences like {{Citation needed|date=April 2020|reason=}}. I've also used Auto-It in the past (and should probably again), which is more flexible in what it can do. Perhaps that can help you. —[AlanM1 (talk)]— 21:06, 16 May 2020 (UTC)

Problem with Template:Web kaynağı

There seems to be an issue with {{Web kaynağı}}, and the template documentation suggests discussing here. The example in the documentation works nicely.

{{Web kaynağı | url = http://yenisafak.com.tr/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |başlık= Açılımdan nemalanmadık! |erişimtarihi = 30 Aralık 2009 |yayımcı = [[Yeni Şafak]] |tarih= 24 Ekim 2009 | arşivurl = https://web.archive.org/web/20101015165324/http://yenisafak.com.tr:80/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |arşivtarihi= 15 Ekim 2010}} → 

{{Web kaynağı | url = http://yenisafak.com.tr/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |başlık= Açılımdan nemalanmadık! |erişimtarihi = 30 Aralık 2009 |yayımcı = [[Yeni Şafak]] |tarih= 24 Ekim 2009 | arşivurl = https://web.archive.org/web/20101015165324/http://yenisafak.com.tr:80/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |arşivtarihi= 15 Ekim 2010}}

However, if you leave out |archive-url=, you get the following error...

{{Web kaynağı | url = http://yenisafak.com.tr/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |başlık= Açılımdan nemalanmadık! |erişimtarihi = 30 Aralık 2009 |yayımcı = [[Yeni Şafak]] |tarih= 24 Ekim 2009}} → 

{{Web kaynağı | url = http://yenisafak.com.tr/Cumartesi/Default.aspx?t=24.10.2009&i=218687 |başlık= Açılımdan nemalanmadık! |erişimtarihi = 30 Aralık 2009 |yayımcı = [[Yeni Şafak]] |tarih= 24 Ekim 2009}}

You can see this in every reference in Draft:Hakan Hançer. Could someone please tweak the template so it doesn't try to put the URL in the archive-url and generate the error? Thanks! GoingBatty (talk) 03:05, 17 May 2020 (UTC)

I think I have fixed it by telling the wrapper template to simply pass |archive-url= to the module instead of trying to do the module's work for it. – Jonesey95 (talk) 05:05, 17 May 2020 (UTC)

Hi,

There's a small glitch in the citation template code handling identifiers. Links from manifestations of ISMN numbers should go through the identifier redirect, but the citation templates still link to International Standard Music Number directly:

Reincken, J. A. (2008). "Preface, Critical commentary, Facsimiles". In Beckmann, Klaus (ed.). Complete Organ Works (2 ed.). Schott Music. ISMN 9790001137416.

Since the configuration at Module:Citation/CS1/Configuration appears to be fine, this is probably a glitch in the code deciding where to link to (Help_talk:Citation_Style_1/Archive_64#choosing_identifier_redirects) and could be down to prefix being set to '' for the ISMN identifier (not so for any of the other identifiers). --Matthiaspaul (talk) 22:39, 2 May 2020 (UTC)

fixed in sandbox:

Cite book comparison
Wikitext {{cite book|author-first=J. A.|author-last=Reincken|author-link=Johann Adam Reincken|chapter=Preface, Critical commentary, Facsimiles|date=2008|edition=2|editor-first=Klaus|editor-last=Beckmann|ismn=9790001137416|publisher=[[Schott Music]]|title=Complete Organ Works}}
Live Reincken, J. A. (2008). "Preface, Critical commentary, Facsimiles". In Beckmann, Klaus (ed.). Complete Organ Works (2 ed.). Schott Music. ISMN 9790001137416.
Sandbox Reincken, J. A. (2008). "Preface, Critical commentary, Facsimiles". In Beckmann, Klaus (ed.). Complete Organ Works (2 ed.). Schott Music. ISMN 9790001137416.

—Trappist the monk (talk) 22:53, 2 May 2020 (UTC)

That's bug fixing in real-time, isn't it? ;-) Thanks.
--Matthiaspaul (talk) 23:33, 2 May 2020 (UTC)
& reverted the sandbox --Francis Schonken (talk) 03:48, 3 May 2020 (UTC)
Restored the sandbox. Identifiers need to have a consistent treatment between CS1 templates, individual templates, and each other. There is zero reasons for ISMN to stand out from the rest. Headbomb {t · c · p · b} 13:57, 3 May 2020 (UTC)
Of course, the whole lot should be reverted. --Francis Schonken (talk) 14:28, 3 May 2020 (UTC)
Also "International Standard Music Number" is what shows on mouseovers. Headbomb {t · c · p · b} 13:58, 3 May 2020 (UTC)
Well, err, no. Incorrect. Maybe refresh or purge? --Francis Schonken (talk) 14:30, 3 May 2020 (UTC)
[1]. On Firefox. And when logged out, this. Headbomb {t · c · p · b} 14:41, 3 May 2020 (UTC)
Err. no. The image doesn't convince me, as I get something different on mouseover, also using Firefox BTW. --Francis Schonken (talk) 14:55, 3 May 2020 (UTC)
I can only conclude the whole thing never had consensus.
@Trappist the monk:
  • Please use edit summaries when editing modules such as Module:Citation/CS1/Identifiers/sandbox – it's very difficult to find the exact edits where you introduced this non-consensus change if you don't explain the edits in the edit summaries.
  • Afaics these are the related non-consensual edits in the Configuration sandbox, and these plus these in the identifiers sandbox.
  • I'll undo these non-consensus edits as much as I can: Trappist, could you please, after that, check the code that I didn't cause inadvertent issues?
  • Trappist, also, for such changes with far-reaching consequences the WP:CONSENSUS base needs to be broader. If you don't have the sixth sense for appreciating whether a consensus of sufficient level has developed in proportion to the breadth of the proposed change, I propose you leave the determination of whether such consensus has developed to someone else before proceeding with updates.
Thanks. --Francis Schonken (talk) 05:55, 4 May 2020 (UTC)
Please don't. I corrected an oversight on my part; you reverted and started this discussion. The reversions should have stopped there. Editor Headbomb reverted you. You reverted Editor Headbomb and me to remove all of the redirect-link code. I am going to restore the sandboxen to the corrected state before your reversion. If discussion here determines that cs1|2 should not link identifier labels to their associated articles through redirects, that is more easily handled than by brute-force reversion and does not effect the other-language wikis that use these modules.
—Trappist the monk (talk) 13:03, 4 May 2020 (UTC)
@Trappist the monk: I realize I am a tad late to this party but I am also confused. How do you claim these identifier label links "should go through the identifier redirect"? Is there some value to linking the identifier label via the redirect? If not, I am opposed to making such a change (although I agree with Headbomb in that such identifier label links should be handled the same across all means of generating such not just CS templates). The way I see it is ISMN (P1208) has a Wikidata item of this property (P1629) claim referring to International Standard Music Number (Q1666938) which in turn has an enwiki sitelink title referring to International Standard Music Number so that should be the link the identifier link label uses here not some arbitrary redirect. —Uzume (talk) 17:13, 4 May 2020 (UTC)
The idea behind these identifier redirects is to be able to distinguish "normal" links to a target article discussing an identifier (including those from normal redirects) from links to that article from manifestations of that type of identifier in other articles. So, while both ISMN and ISMN (identifier) link to International Standard Music Number, they serve two completely different purposes. The former is a redirect from an abbreviation used in "normal" article linking, the second one is a redirect only used in links from manifestations of ISMN IDs in articles, typically invoked through templates like {{ISMN}}, citation templates or the like. The parenthetical disambiguator "(identifier)" is reserved for this specific usage.
The main reasons to deliberately route such occurences through identifier redirects is that there are typically many invocations (up to hundreds of thousands, possibly millions, as in the case of identifiers like ISBN). They completely pollute "What links here" to a point that it is no longer usable. Routing them through this redirect, people doing normal article work who are only interested in normal links to the target article, can easily mute them in "What links here" and concentrate on those links they are actually interested it, instead of having to sift through an endless list of links they do not care about at all. Likewise, other people may want to carry out reverse lookup of only those articles which contain manifestations of a particular identifier (while doing research or wanting to maintain articles including a particular identifier). Due to the identifier redirect they can narrow the scope to only these incoming links as well. And people, who don't care about a specific class of incoming links, can continue to recursively traverse through all incoming links like before and they won't miss a single article, as the network of incoming links remains intact and only the grouping of incoming links changes. Best of both worlds. Also, in some cases, going through the redirect helps to keep the link from being displayed in (then undesired) boldface.
--Matthiaspaul (talk) 18:25, 4 May 2020 (UTC)
@Matthiaspaul: I appreciate the explanation. That does seem to provide some value. I personally believe the links on the identifier labels to be overlinking but I know there is consensus against removing those. This seems like a compromise. I see this sort of thing is also being pushed Module:Authority control. Perhaps someone will also work on others like Module:Taxonbar/conf, etc. —Uzume (talk) 18:35, 4 May 2020 (UTC)
Among other places, this was discussed at Help talk:Citation Style 1/Archive 64#choosing identifier redirects and it is highly desirable to remain consistent in the naming conventions, hence this switch to use the identifier redirect rather than linking directly (or going through other redirects for abbreviations) or such.
--Matthiaspaul (talk) 18:25, 4 May 2020 (UTC)
@Matthiaspaul: That seems like a good link to keep and I agree. —Uzume (talk) 20:12, 4 May 2020 (UTC)
As the normal redirect ISMN to International Standard Music Number remains unaffected, this does not change anything in regard to the model of relations at Wikidata. In fact, in a possible future extension of the Wikidata model, this could even improve machine-readability and lay the foundation to new functionality (semantic web).
--Matthiaspaul (talk) 18:25, 4 May 2020 (UTC)
@Matthiaspaul: Could you perhaps expound on what you foresee as a possible Wikidata functional change in this area. Thank you, —Uzume (talk) 20:12, 4 May 2020 (UTC)

I'm thinking about preparing an RfC:

  1. Does the system of linking identifiers through redirects have broad support?
  2. Does the standard MO that values assigned to such identifiers follow Wikidata have broad support?
  3. If redirects are used, is there broad consensus about a naming scheme for such redirects?
  4. If #1 and #3 have broad consensus, does that include less common identifiers, with, let's say, less than 20 or 50 implementations?

--Francis Schonken (talk) 06:22, 13 May 2020 (UTC)

--Francis Schonken (talk) 06:35, 20 May 2020 (UTC)

Number sign in pages crashes harvtxt

In this old version of Crossing number (graph theory), the Schaefer 2014 reference has parameter pages=#DS21. This causes {{harvtxt|Schaefer|2014}} to produce a big red error message "Lua error in Module:Footnotes/anchor_id_list at line 700: attempt to index local 'template_name' (a nil value)" in place of the actual reference. Regardless of whether that is the right way to indicate the article number (not page number) of this reference, I don't think that error message is a particularly helpful way of behaving. Probably this used to work and has somehow been broken recently. —David Eppstein (talk) 00:54, 22 May 2020 (UTC)

An issue for Module talk:Footnotes. There's been a few recent updates for that module. Headbomb {t · c · p · b} 00:57, 22 May 2020 (UTC)
Maybe, but the crash and error message is in the {{harvtxt}} Lua template, not in the footnote code. The footnote itself renders as expected. —David Eppstein (talk) 01:01, 22 May 2020 (UTC)
I don't see the big error message. I saw it before, but it no longer does it. A case of WP:ITSTHURSDAY? Headbomb {t · c · p · b} 01:08, 22 May 2020 (UTC)
Gone for me now too. Weird. —David Eppstein (talk) 01:19, 22 May 2020 (UTC)
Possibly fixed with this? Headbomb {t · c · p · b} 01:28, 22 May 2020 (UTC)

Needs exception for unusual-format dates

I have a reference in a draft I am working on whose publication date is "Fourth Quarter 1988". There appears to be no way of formatting this date without producing an error. I might reasonably guess that this means the same as "October–December 1988", but that's just a guess and citation metadata should not be based on guesswork; additionally, anyone trying to use this to look up the reference would have to work backwards from the guess to determine that it is the 4Q88 issue that should be accessed, so reformatting the date in this way would not serve one of the main purposes for which dates are included in references. What would be best, I think, would be some escape to tell the citation templates that a date format it cannot parse is nevertheless ok to include in a reference. The standard "accept-this-as-written markup", as documented on the help page, is to surround things in double parens, like |date=((Fourth Quarter 1988)), but that doesn't work. Why doesn't it work? —David Eppstein (talk) 01:04, 16 May 2020 (UTC)

I think the usual advice in these odd situations is to use |date=1988 and |issue=Fourth Quarter 1988. Will that work in this case? – Jonesey95 (talk) 05:13, 16 May 2020 (UTC)
No. It has proper separate volume and issue numbers, like most journal articles, so the issue number cannot be faked to give information that is not actually the issue number. (It's now live: it's the Abel reference in Frederick V. Waugh. What I did to make it format without errors is just give the year and omit the more detailed date, but that's not satisfactory.) —David Eppstein (talk) 16:24, 16 May 2020 (UTC)
Were we to support accept-this-as-written markup for |date= such dates would not contribute to the citation's metadata because Module:Citation/CS1/Date validation cannot construct an ISO 8601 format date from what amounts to an undefined date format. Similarly, such dates would not be available for construction of the anchor ID. Dates wrapped in accept-this-as-written markup would be treated as errors except that the error message would be suppressed.
The better solution would be for us to decide on an acceptable quarterly-date format that can be validated and so can contribute to the metadata and can be used to form an anchor ID.
—Trappist the monk (talk) 13:05, 16 May 2020 (UTC)
If we need both a free-format date and a metadata-sortable date, we could require that the year parameter have a valid year number or range when the date parameter is free-form. —David Eppstein (talk) 16:31, 16 May 2020 (UTC)
It would be better to define an acceptable quarterly-date format (this discussion is not the first time that we have discussed quarterly dates). Defining a standardized format allows us to handle quarterly date in the same way that we handle all other dates.
—Trappist the monk (talk) 17:30, 16 May 2020 (UTC)
Let me ask this: what is currently output for |date=Spring 2018? Seasons have the same issue as quarters because they also have varying definitions. Imzadi 1979 → 18:44, 16 May 2020 (UTC)
For this:
{{cite journal |author=Author |title=Title |journal=Journal |date=Spring 2018}}
Author (Spring 2018). "Title". Journal. {{cite journal}}: |author= has generic name (help)
COinS date is:
&rft.ssn=spring&rft.date=2018
anchor ID is:
CITEREFAuthor2018
cs1|2 does not interpret seasonal dates; the hemispherical distinction is left to the reader; it presumes that a seasonal date in |date= is the seasonal date of the magazine / journal / ... issue. This is as it should be. Similarly, cs1|2 would not interpret quarterly dates. For the above example, substituting |date=Fourth Quarter 2018 for |date=Spring 2018, cs1|2 would produce the same anchor ID but would have different metadata:
&rft.quarter=4&rft.date=2018
—Trappist the monk (talk) 19:17, 16 May 2020 (UTC)
Maybe I am missing something, but why is "October-December" a guess for "4th quarter"? Isn't it exactly that? How is the issue numbered? Unlike other fields, what populates |date= need not be verbatim as there are several acceptable ways to format a given date. Inserting the month range is fine. However |issue= should be given exactly as is, or as close to it as possible. 172.254.241.58 (talk) 13:39, 16 May 2020 (UTC)
Because quarters aren't well-defined. Academic quarters, Fiscal quarters, etc... all of which rarely line up. Headbomb {t · c · p · b} 14:27, 16 May 2020 (UTC)
I worked for a company whose fiscal year was offset by a month, starting on February 1 each year. Thus to them, "4th Quarter" is November–January. Some local governments near me use a fiscal year that starts on July 1, making their fourth quarter April–June, and others start on October 1, making their fourth quarter July–September. I've run into journals the reset their volume and issue numbering in the middle of the year, presumably following an underlying academic calendar year. Imzadi 1979 → 18:45, 16 May 2020 (UTC)
How the publisher chooses to interpret quarters does not matter. What matters is the date that the publisher assigns to the source. cs1|2 merely confirms that it understands the date format as it is written so that the date can be translated into the formats required for the anchor ID and the metadata.
—Trappist the monk (talk) 19:17, 16 May 2020 (UTC)
So based on the above, it looks like we already have the kernel of a metadata format based on how seasons are handled. Both seasons and quarters can be variable in how they translate into an actual range of corresponding calendar dates, and yet the metadata doesn't care if Spring is early in the calendar year (Northern Hemisphere) or later (Southern Hemisphere) or if the 4th quarter starts in November or July. Imzadi 1979 → 22:49, 16 May 2020 (UTC)
If I understand correctly, what has been referred to loosely as metadata is actually OpenURL, and version 1.0 of the specification for OpenURL can be found here. This specification provides for "the quarter of publication", which can take on the values 1, 2, 3 or 4.
If this value were implemented, a number of possible ways to define parameters to use it are possible. One could try to parse phrases such as "1st quarter 2020" into a date of 2020 and a quarter of 1. Or one could specify |year= or |date= = 2020 and |quarter= =1 (this would be a new parameter). The presence of the quarter parameter would create a requirement that if date is specified, it be a year; specifying a month or day-of-month in the date would be an error when quarter is present. Jc3s5h (talk) 23:37, 16 May 2020 (UTC)
While it is true that COinS metadata are based on OpenURL, there are also other metadata implementations. More to the point, while I agree with what is stated in the comments above, it seems to me that any application would lack the precision the OP requested. Moreover, as was pointed out "quarter" may mean a lot of different things. That would make any such date ambiguous. The related practice of using seasons as dates is normally to be avoided (MOS:SEASON), and for the same reason. 98.0.246.242 (talk) 02:15, 17 May 2020 (UTC)
Except that MOS:SEASON specifically allows seasonal dating in citations. Converting dating from how issues are published should be avoided as it makes it harder for others to find copies of sources. Imzadi 1979 → 03:03, 17 May 2020 (UTC)
any application would lack the precision the OP requested. What? Editor David Eppstein wants is to be able to write |date=Fourth Quarter 1988 because that is the date shown in the footer of the cited source so is exactly precise. There is no ambiguity and en.wiki's MOS has no control over how source publishers date their publications.
—Trappist the monk (talk) 11:33, 17 May 2020 (UTC)
Wasn't it pointed out above that "Fourth Quarter [anything]" is ambiguous? It could mean different ranges of months. Even if David Eppstein could enter it in |date=, readers might draw their own conclusions as to what that means. But I remarked on this an aside, not material to verification. What was mentioned above was that seasonal dating should normally be avoided, not always. If the publication can be found when searching by date "Fourth Quarter 1988" then a citation with such |date= is good enough. 98.0.246.242 (talk) 15:24, 17 May 2020 (UTC)
COinS is a layer on top of OpenURL. COinS, from the documentation that I have been able to scrape from various places (see Module talk:Citation/CS1/COinS § References), uses a subset of OpenURL to which it adds certain constraints (for example, the quarter key/value pair is restricted to journal objects in COinS but may be used for all other objects in OpenURL).
Because we already parse months, seasons, and proper names into dates usable by COinS, it wouldn't be that difficult to parse 1st quarter 2020 into &rft.quarter=1&rft.date=2020. We went to great effort to eliminate date parts from cs1|2 (|day=, |month=) so we should not return to that method with |quarter=1.
—Trappist the monk (talk) 11:33, 17 May 2020 (UTC)

The remark about ambiguity here isn't that First Quarter 2020 or Summer 2019 are problematic when used in citations, but rather that these cannot be converted to months because of their ambiguity. If you get the Summer 2020 issue of Australia Monthly, it will be summer in the northern hemisphere. But if you search for the "Summer 2020" issue of Australian Monthly, there is no ambiguity about which issue that is. Headbomb {t · c · p · b} 16:09, 17 May 2020 (UTC)

Concerning [2], it's probably also a good idea to support Quarter 1/2/3/4, and Q1/2/3/4. Headbomb {t · c · p · b} 17:47, 17 May 2020 (UTC)

Those forms require a comma? don't require a comma?
|date=Quarter 1, 1988 or |date=Quarter 1 1988?
|date=Q1, 1988 of |date=Q1 1988?
Numeric ordinal forms? cs1|2 doesn't support ordinals for days because MOS:BADDATE and MOS:ORDINAL prohibits that so probably should not support ordinal quarters for consistency
|date=3rd Quarter 2005
—Trappist the monk (talk) 18:06, 17 May 2020 (UTC)
I agree on your point re:ordinals. As for the comma, the only similar case that springs to mind is something like "May, 2020" vs "May 2020" (substitute, for the example's sake, "Month 5" for "May"). Both are correct, but I would lean towards the comma-less rendition as a personal preference. Others may prefer the comma as a separator between two distinct numbers. 98.0.246.251 (talk) 23:24, 17 May 2020 (UTC)
Comma-less, no different than "Winter 2002", vs "Winter, 2000". Headbomb {t · c · p · b} 23:54, 17 May 2020 (UTC)
I agree re the comma. Re how to write the quarter itself: I'm not entirely convinced that BADDATE's prohibition on ordinals is about this case (it is clearly aimed at days of the month; I don't think the editors who agreed on that rule even thought about quarters). But if we do think it applies, then "Quarter 4" for date formats that would use spelled-out months, and "Q4" or "4Q" (I don't care which) for formats that would use numeric months, seem like an acceptable substitute. —David Eppstein (talk) 00:12, 18 May 2020 (UTC)
I like "4Q1988"; "4Q 1988"; "Q4, 1988"; "4th Quarter 1988". I suppose "Quarter 4, 1988" is reasonable, though I can't remember seeing it. If the metadata needs a specific date, I'd suggest another parm to provide that in addition if it is known, i.e., |date=Summer 1988 |date-exact=1988-12-20. —[AlanM1 (talk)]— 04:39, 18 May 2020 (UTC)
Regarding which groupings should be supported at a minimum this list might be useful: Wikipedia talk:Manual of Style/Dates and numbers#Adding "holiday" and other similar terms to WP:SEASON? (although there are more groupings in the real world, as has been pointed out correctly by some above already).
--Matthiaspaul (talk) 21:09, 22 May 2020 (UTC)

Journal with nonstandard date format

In Round Top (Alpine County, California) I cite "Supplement to a Flora...", which was published in a journal with a nonstandard date format. In this case, the date is "Spring and Fall 1983". The citation template is showing an error. I am citing this source as follows:

<ref name="Smith 1983">{{Cite journal|title=Supplement to a Flora of the Tahoe Basin and Surrounding Areas|last=Smith|first=Gladys L.|url=https://digitalcollections.usfca.edu/digital/api/collection/p15129coll11/id/796/download|journal=The Wasmann Journal of Biology|volume=41|number=1 & 2|date=Spring and Fall 1983|format=pdf|page=25|access-date=May 23, 2020}}</ref>

Which renders as this: [1]

References

  1. ^ Smith, Gladys L. (Spring and Fall 1983). "Supplement to a Flora of the Tahoe Basin and Surrounding Areas" (pdf). The Wasmann Journal of Biology. 41 (1 & 2): 25. Retrieved May 23, 2020. {{cite journal}}: Check date values in: |date= (help)

What's the right format to use here? CJK09 (talk) 08:04, 23 May 2020 (UTC)

cs1|2 and MOS:DATES do not have a recognized format for what amounts to two dates. cs1|2 does not support 'Spring and Fall 1983' for the same reason it doesn't support 'April and October 1983' or support '5 and 23 'June 1983'. For such rare date forms there are a couple of options:
  • because |number=1 & 2 'Spring and Fall' is not absolutely required so |date=1983
  • you could fudge it a bit: |date=Spring–Fall 1983
  • you could lump 'Spring and Fall' into |number= somehow
  • You can hand-write the citation
cs1|2 is a general purpose citation style that is adequate to most needs but will never be able to answer all needs.
—Trappist the monk (talk) 12:03, 23 May 2020 (UTC)
Was this actually one issue or two? If two, it's two refs, not one. If one, the other things you can do are cite the later date only or go by the actual publication date rather than what's on the front page. --Izno (talk) 13:03, 23 May 2020 (UTC)
I would just use |date=1983 and be done with it. The volume and numbers and the year are sufficient to identify and locate the source. – Jonesey95 (talk) 21:50, 23 May 2020 (UTC)

Why language in between series title and volume number?

Maybe there's an explanation that escapes me at the moment, but why does {{cite book}} place the language indicator (i.e., "in German") in between the series title and the volume number? Here's an example from Balasagun:

  • Klein, W. (2000). Das nestorianische Christentum an den Handelswegen durch Kyrgyzstan bis zum 14 Jh. Silk Road Studies (in German). Vol. III. Brepolis. ISBN 2-503-51035-3.

In my opinion it should be:

  • Klein, W. (2000). Das nestorianische Christentum an den Handelswegen durch Kyrgyzstan bis zum 14 Jh. (in German) Silk Road Studies. III. Brepolis. ISBN 2-503-51035-3.

It would make particular sense here because the series, Silk Road Studies, actually has volumes in English, French, and German, so labeling it as if the language is specific to the series instead of the volume would be misleading. I'm sure there are other series like this, too. --bender235 (talk) 03:49, 6 May 2020 (UTC)

Agreed. The language indication should follow the most-specific title (book title, journal article title, etc.) that's being cited instead of a less-specific title (book series, journal title, etc.) because there are enough mixed-language examples out there. Imzadi 1979 → 05:10, 6 May 2020 (UTC)
This same placement of the language should probably apply to the other cite templates as well. Here's {{cite journal}} listing a Spanish-language article in a multi-language journal: "Título". Journal with Articles in Multiple Languages (in Spanish). – Jonesey95 (talk) 05:19, 6 May 2020 (UTC)
Lest we venture too far off, I think the output of |type= also belongs after the more-specific title for the same reasons, in that they describe the source. So in a {{cite news}} listing for an editorial: "Our Opinion on Stuff". Newspaper (Editorial). The annotation has the effect to describe the newspaper as an editorial, when it's the article that is the editorial. Imzadi 1979 → 12:28, 6 May 2020 (UTC)
Agreed. --bender235 (talk) 19:05, 6 May 2020 (UTC)
I don't necessarily disagree that the language annotation might be better positioned in citation renderings, but I don't think that it belongs directly after the most-specific title. Were we to do that, wouldn't we also, for the sake of consistency, have to place the in-source location annotation (|page(s)=, |at=) directly after the most-specific title? After all, specific in-source locations are supposed to be within the content that is defined by the most-specific title.
—Trappist the monk (talk) 12:03, 6 May 2020 (UTC)
I don't think so. We're talking about annotations that describe the source, not how to locate it. Imzadi 1979 → 12:28, 6 May 2020 (UTC)
Placing the language after the most specific item has some merits but would also have a number of disadvantages:
  • Depending on if |chapter= is used, the language would be displayed after the chapter or after the title, that is, it would seem to "move around".
  • Placing it after the title might create some corner cases in regard to where to put the delimiter depending on if or if not the title ends on ".".
  • In case of the optional |trans-chapter= and/or |trans-title= parameters being used, should the language be placed after the translation or before it?
This raises the question if this information actually belongs into the core of the citation at all. Wouldn't it be better to append it to the citation (which would create the question if it should be placed before or after |quote= and, possibly, |total-page[s]=)? Either way, being placed at the end of the citation, perhaps we could switch to use square-brackets and get rid of the "in". Examples:
  • Last, First (2000). "Chapter". Title. Work (Type). Series. III. Publisher. p. 5. ISBN 2-503-51035-3. [German]
  • Last, First (2000). "Chapter". Title. Work (Type). Series. III. Publisher. p. 5. ISBN 2-503-51035-3. "Quote" [German]
  • Last, First (2000). "Chapter". Title. Work (Type). Series. III. Publisher. p. 5. ISBN 2-503-51035-3. [German] (564 pages)
  • Last, First (2000). "Chapter". Title. Work (Type). Series. III. Publisher. p. 5. ISBN 2-503-51035-3. "Quote" [German] (564 pages)
--Matthiaspaul (talk) 21:53, 7 May 2020 (UTC)
I don't think it's an issue if some elements dynamically "move around" as appropriate. Map citations already do this with the type annotation:
  • Last, First (2000). Individual Map (Map). Scale. Series. Location: Publisher. § A1.
  • Last, First (2000). "Map in an Atlas" (Map). Atlas. Scale. Series. Location: Publisher. p. 1. § A1.
But when it comes to the language, we're back to the issue above that we're indicating that the series (if given, doesn't always apply) or the scale (!), which should always be given for non-dynamic maps, get the language annotation:
  • Surnom, Prénom (2000). Une carte (Map). Scale. Series (in French). Location: Publisher. § A1.
  • Surnom, Prénom (2000). "Une carte dans un atlas multilingue" (Map). Multilingual Atlas. Scale. Series (in French). Location: Publisher. p. 1. § A1.
Shuffling the language annotation to the end is not helpful because that just makes it an afterthought. I find the language annotation to be helpful when I don't recognize the language of the title. I think it would be better if we had it moved up, even merging adjacent parentheses, such as:
  • Surnom, Prénom (2000). Une carte (Map, in French). Scale. Series. Location: Publisher. § A1.
  • Surnom, Prénom (2000). "Une carte dans un atlas multilingue" (Map, in French). Multilingual Atlas. Scale. Series. Location: Publisher. p. 1. § A1.
I'm neutral if the "in" is retained or not. Imzadi 1979 → 23:41, 7 May 2020 (UTC)
This thread touches on one of my style pain points in CS1, which is what happens when you have lots of parentheses (and we have a long-time feature request that would add to it). Right now the module doesn't do the best job in how it assembles citations. --Izno (talk) 01:35, 8 May 2020 (UTC)
Agreed; adjacent parentheses should be merged together. Imzadi 1979 → 01:46, 8 May 2020 (UTC)
I don't think this would be a good idea, as it may lump unrelated information together into one syntactically separated chunk. --Matthiaspaul (talk) 03:43, 30 May 2020 (UTC)
Not really. I laid out some test cases of how I'd like to see it at the feature requests page. --Izno (talk) 23:07, 30 May 2020 (UTC)
So, according to your overview list, |format=, |type= and |language= would be the items which would be merged into a single (pair of brackets) occasionally? Is this a complete list? While this looks nice in some cases, I'm not sure it makes sense in the generic case with all possible values users might put into |format= and |type=? After all, these parameters take free-flow strings, not tokens...
You also bring up cases where |date= would be merged into this set as well. That, I think, would be a really bad idea. While |format=, |type= and |language= can be seen as optional "convenience annotation", the |date= is a core property of a citation, which must be easily parsable at first sight (by location and syntactical elements), if this would sometimes be merged with other unrelated information, it would no longer stand out.
How to avoid possible corner-cases like "(Date) (...)"? By putting some additional syntax element in between "(Date), (...)" or "(Date). (...)" or by moving the "(...)" part to the end of the citation.
--Matthiaspaul (talk) 09:10, 31 May 2020 (UTC)
Users misusing parameters as-documented is their problem, not mine. :) As for a complete list, I haven't looked into the module but I am fairly certain it's the set now (+- variants for e.g. ChapterFormat).

How to avoid possible corner-cases like "(Date) (...)" Your solutions to which are ugly.

I think you overblow the question of 'other unrelated information'. Rare is the case where you don't have the required other fields to keep the parentheticals separate, and the parameters aside from Date are all rarer than not given how English Wikipedia works. Date will still jump out if you've somehow managed to provide no author and no editor and a language/type/format, not least because that information is typically numerical in some sense and not least because it will always come first in the parenthetical statement.

Let me comment directly on "convenience annotation": If these are convenience annotations only, then why do we support them? --Izno (talk) 13:46, 31 May 2020 (UTC)

Regarding "(Date), (...)" or "(Date). (...)", I agree. I don't think this looks nice, but "(Date, ...)" looks even worse for some of the possible combinations. "(31 May 2020, Excel table)", "(31 May 2020, in Russian)", huh? (Also, things like "(PDF, Review)" don't look very sensible.) Under the circumstances, I think even "(Date) (...)" looks better. In some citation styles, dates are not put in brackets at all. This would solve this problem, but probably would create corner-cases elsewhere...
Regarding "convenience annotation". Because despite what some people wrongfully state in this forum, citation templates are used for all kinds of purposes where sources need to be mentioned or listed in a standardized format. References in an article is one of these purposes (and the most important one), but it is only one of them. Citation templates are also used in lists of "Further reading" and "Works" sections, some people even use them to format external links, and there are proably a few other uses as well. And that's all nice.
Also, even in their core discipline of providing references to articles, it is often helpful for readers to know more about a source than only the basic information to locate the source:
  • Language is useful so they know if they would be able to read the source.
  • Format may be useful to determine if they have the equipment to view the source (some people can't open specific file formats, some people can't play videos (for operating system, connection or policy reasons) or are blind, read Wikipedia with a screenreader and just can't see videos).
  • Type might be useful to know if the source is actually about what the title sounds like it is about, for example, is this "the real thing" or only a "review" or "abstract" of it?
  • Total page information (as discussed in various other threads) is useful to evaluate if the source is just a page, a few pages or a fundamental work.
Except for rare cases all this is non-essential to locate the source, but it is helpful for readers to decide if it is worth to locate the source for further studying. And since WP:NOTPAPER and we want to make it as convenient for readers to work with Wikipedia, enriching citations with this kind of information is a "good thing"(tm).
We just need to find the most suitable form to present this information in a citation. :-)
--Matthiaspaul (talk) 17:02, 31 May 2020 (UTC)
I just ran into a compilation of early works on switching theory and logic design which uses a citation style similar to our's - including language annotation. Interestingly, they append the "(In Language)" string at the end of citations. They might have had a reason for this (see above), so perhaps we should follow them...
https://pdfs.semanticscholar.org/acaf/34c7e4888a1d6022549a8ca1d5346ab91e05.pdf
--Matthiaspaul (talk) 03:43, 30 May 2020 (UTC)

Cite interview broken with visual editing

It seems that using Cite interview doesn't work with visual editing: the output of the citation shows up as text rather than the usual structured list of fields, so it's not really possible to add an archiveurl for instance. At Peter_Bocage, I ended up deleting the citation, adding it again as a Cite web, filling in the changes I wanted (worked fine), saving, and then opening source editing to rename the updated template back to Cite interview. This is unnecessarily complicated and seems kind of silly just to get the archiveurl in there... Can it be fixed to get it to work in visual editing like Cite web does? Thanks! —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 20:34, 31 May 2020 (UTC)

I don't use ve. If I understand what you are describing, the problem is not with cs1|2 but with ve's ability to create / edit a {{cite interview}} template. Apparently you did not save the version where the output of the citation shows up as text rather than the usual structured list of fields so I can't see from the article history what you describe. If the problem is as I suggested, ve's inability to create / edit {{cite interview}}, this help page may not be the best place to ask. There is a problem report link at WP:VE that may be a better place to report this issue.
—Trappist the monk (talk) 21:39, 31 May 2020 (UTC)
Ah, thanks! No, I didn't save it because I couldn't (or couldn't tell how to?) make the change I wanted to that way, so there was nothing to save. I'd posted here because I was under the impression that support for templates in visual editing is added by defining "template data" for the template (so it would be fixed by changing that, rather than the software). Although my understanding is very fuzzy, and maybe that's not the case for this! I'll copy this over there, then. Here it is: https://phabricator.wikimedia.org/T254113 —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 22:11, 31 May 2020 (UTC)
I added screenshots of "broken" and "working" to that page, also, which explain the problem more clearly than my description... —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 22:34, 31 May 2020 (UTC)
I don't use VE, but I went to my sandbox, switched to VE, went to Insert - Template, and typed "cite interview". I got a pop-up dialog box asking me for Last name, First name, Interviewer, and Source title. My window doesn't look like your screen shots at all, but inserting the template worked fine. To add an archive-url parameter, I clicked on the citation text, clicked Edit, clicked Add more information, and scrolled down until I found Archive URL. It works fine, as far as I can tell. – Jonesey95 (talk) 22:57, 31 May 2020 (UTC)
(Also posted this at the issue report) Oh, interesting. Adding and editing an existing one in my sandbox worked as expected. But when I put <ref> tags around it, it stopped being able to be edited correctly. I've put examples up at https://en.wikipedia.org/w/index.php?title=User:Goldenshimmer/sandbox&oldid=960065161 — Jonesey95, would you be willing to see if the two citation templates in that revision labeled "Not editable" show up normally for you in visual editing? Thanks! —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 23:36, 31 May 2020 (UTC)
A-ha! They are editable with a workaround: Click the reference, click edit in the small pop-up, it opens a broken large modal pop-up, click the displayed reference text in the large modal, it shows another pop-up with an edit button, click that edit button, then the normal edit modal pop-up appears. —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 23:51, 31 May 2020 (UTC)
Works for me too. I click the [1], click Edit, click the text of the citation, click Edit again, and I get the Cite interview interface that I described above. This looks like it is working as designed. I don't see anything that I would describe as "broken", but I don't know how VE is supposed to work, having never used it. – Jonesey95 (talk) 23:55, 31 May 2020 (UTC)
Thanks! I don't think it's intentional to have to edit the reference and the citation as separate steps when it's using a template citation, since Cite web doesn't require those two steps. Rather, clicking the ref and then editing it opens the template editing directly. It's also not obvious (to me anyway!) that clicking the citation in the first popup will allow opening the the second; I thought the first was all I could get until some trial-and-erroring. If all citations worked that way, I'd not call it broken, just confusing — but since Cite web can be edited without an intermediate step, this looks like a glitch. —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 00:46, 1 June 2020 (UTC)

Possible improved treatment of title parameters and language attributes

The current system of |title=, |script-title=, |trans-title= and |language= (and the similar parameter set |chapter=, |script-chapter=, |trans-chapter=) does not handle some cases in the best-possible way. The following suggestions would stay compatible with existing use but add support for some previously unsupported cases, also improve meta-data/screenreader support and assist editors in identifying foreign language citations lacking some important title or language information. Thereby, they would help to improve the quality of foreign language citations.

  • The present error message:
At present, |trans-title= without |title= and |script-title= throws an error message:
"|trans-title= requires |title="
At the minimum the message should instead read:
"|trans-title= requires |title= or |script-title"
(Likewise for |trans-chapter= without |chapter= and |script-chapter=.)
  • The case of a work or chapter title of a foreign language citation provided in the language of the local Wikipedia (English):
Example code:
{{cite journal |trans-title=Graphical aids to minimization in switching circuits |language=cs |author-first=Antonín |author-last=Svoboda |journal=Stroje na zpracování informací |publisher=Czechoslovak Academy of Sciences, Research Institute of Mathematical Machines |date=1958}}
Instead of throwing an error, it would be better to actually support these cases, as it is quite common with foreign language citations that only the translated title is known (and used in references), but the actual foreign language title is not. One "solution" is to add a dummy title like |title=(unknown) to get rid of the error message, which, however, is not desirable. Putting the translated title in |title= is also common, but sub-optimal as well, because without |language= the user has no way of knowing that the source is not in English at all - this can cause quite some confusion when actually trying to obtain the source.
Instead, we should actively encourage editors to put known translated titles (in the local Wikipedia language) of works in foreign languages into |trans-title= (rather than |title=) even if the original language title is not known. Therefore, instead of throwing an error message if |trans-title= is provided without |title= or |script-title=, the template should just display the translated title. Since displaying the translated title in [square bracket] looks ugly if neither |title= or |script-title= is present as well, it should, in this case, be displayed without any format decoration like a so called "descriptive title". That is, it would be displayed without the usual [square brackets], but also without italics or quotes (as a normal |title= would be rendered).
Supporting this combination of parameters would allow users to use the existing parameters in a more intuitive way and to more accurately describe foreign language citations with translated titles.
So, the example above would not throw an error message any more, and also not render with italics as a normal book title like
Svoboda, Antonín (1958). Graphical aids to minimization in switching circuits. Stroje na zpracování informací (in Czech). Czechoslovak Academy of Sciences, Research Institute of Mathematical Machines.
or with quotes like a normal journal title
Svoboda, Antonín (1958). "Graphical aids to minimization in switching circuits". Stroje na zpracování informací (in Czech). Czechoslovak Academy of Sciences, Research Institute of Mathematical Machines.
but without such format decoration as a descriptive title like:
Svoboda, Antonín (1958). Graphical aids to minimization in switching circuits. Stroje na zpracování informací (in Czech). Czechoslovak Academy of Sciences, Research Institute of Mathematical Machines.
Additionally, while the absence of a |trans-title= does not indicate that the citation is English, the presence of this parameter indicates a foreign language citation. Hence, if |trans-title= is present without |title= or |script-title=, the citation should display a hint in article preview like
"Foreign language citation missing original |title= or |script-title="
and put the article into some maintenance category so that users can search and retrofit the original foreign language title.
(Likewise for |trans-chapter= without |chapter= and |script-chapter=.)
  • The case of a work or chapter title provided in a language different from that of the local Wikipedia (English):
A solution to reliably attribute a language to a title would be to move a |title= in a known language to |script-title= (even without knowing anything else about the work). This would also assist translation tools and help screen readers to switch their pronunciation to the corresponding language.
While this already works for the limited number of languages supported by |script-title=, the template at present only supports prefix codes for languages with non-Latin alphabets, unfortunately. I can't see a compelling reason which would forbid us to broaden the concept to any other languages as well and therefore propose to let |script-title= support all language codes already supported by the |language= parameter. However, in order to retain the original functionality of the |script-title= parameter, the template would have to display |script-title= differently depending on if the provided prefix code is from the short or the full list of codes:
If the prefix is in the short list for non-Latin scripts, the script title should be displayed like before, that is, no special formatting is applied (as for "decorative titles") and the script title is framed with:
<bdi lang="??">script_title</bdi>
If, instead, the prefix code is only in the full list of language codes, the script title would be language-framed as well in the HTML, but we would have to distinguish two further sub-cases:
If |title= is not present at the same time, |script-title= can be treated just as a syntax-enhanced substitute for |title=, and consequently it should be displayed with the format decoration usually applied to |title= rather than |script-title= (that is, italics/quotes) plus language attributes. Depending on what would give the better HTML (TBD) we could still use the <bdi> element and just add (example here for italics) <i> like
<i><bdi lang="??">script_title</bdi></i>
or, if we would have to avoid the usage of <bdi> for Latin-derived scripts, we could use what {{lang}} uses already:
<i title="?????? language text" lang="??">script_title</i>
If, however, |title= is present in addition to |script-title=, we would still have to distinguish between the two parameters in the output, that is, |title= and |script-title= would be treated just like before for as long as the language code provided with |script-title= is in the short list. If it is in the full list, |script-title= would still not get italics/quotes, and if it is safe to use <bdi> for Latin scripts (TBD, see above) it would be HTML framed like
<bdi lang="??">script_title</bdi>
else we'd have to come up with something like
<span lang="??">script_title</span>
Additionally, for |script-title= using any language prefixes but that of the local Wikipedia ("en:"), the template could assume that the work is not in the local language (English).
If, in this situation, a |language= parameter is missing, the template could issue a hint in article preview:
"Foreign language citation missing |language="
and put it into a maintenance category.
Likewise, in the same situation, if |trans-title= is not present, the template could display a hint in preview:
"Foreign language citation missing |trans-title="
and put the citation into another maintenance category.
(As not providing |language= or |trans-title= are not actual errors, the template should not generate error messages for them.)
(The examples above were for the case of book title in italics, journal titles in quotes should be treated in an analogous fashion, of course.)
(Likewise for |script-chapter=, |chapter= and |trans-chapter=.)
  • Applying language attributes to title and chapter:
While the above two suggestions are extensions into areas not previously supported by the citation templates at all, the following suggestion is an improvement for existing scenarios by deriving language information for |title= and |chapter= as well.
At present the HTML language framing only happens for |script-title=, whereas |title= and |trans-title= do not support any language prefixes. (In the case of |title= this is probably down to potential conflicts with normal title strings, and in the case of |trans-title= we assume that the translation is in the locale language (English) and therefore no language framing is required in the English Wikipedia.) The suggestion is to apply language attributation also to |title= and |chapter= where it can be derived with reasonable likelihood from other parameters.
While the absence of the |trans-title= does not necessarily indicate that a citation is in the local language (English), the presence of |trans-title= can be used as an indicator that |title=, if also present, is not in the local language. Likewise for |trans-chapter= and |chapter=.
There are, however, two potential sources of language information, |script-chapter= or |language= for |chapter=, and |script-title= or (in absence of |chapter=) also |language= for |title=. (If |chapter= is present |language= applies only to |chapter=, in multilingual works not necessarily to |title=.) |language= defines the actual language the work or chapter is written in, whereas the |script-*= parameters specify the language the title of the work or chapter is given in the citation. As discussed above, this is often the same, but not always. If they are equal, it is quite reliable to assume that this can be extended to |title= or |chapter=, so that we could provide a HTML language attribute for them as well. If they are not the same, I am not sure, if we should give one of them preference over the other. I guess, in most cases in the English and other Latin-script based Wikipedias, the language provided through the corresponding |script-*= parameter would more likely match (in particular, if it is not in the short list for non-Latin scripts, that is, we don't have to put any possibly deviating legacy use into account), but I'm not sure if this holds also true for foreign Wikipedias in non-Latin scripts which also use our citation templates. Perhaps it would be better to play it safe and not apply language attributes to |title= or |chapter= in these cases.

--Matthiaspaul (talk) 09:24, 1 June 2020 (UTC)

Error message tweaked:
{{cite book/new |trans-title=Trans Title}}
[Trans Title]. {{cite book}}: |trans-title= requires |title= or |script-title= (help)
{{cite book/new |trans-chapter=Trans Chapter |title=Title}}
[Trans Chapter]. Title. {{cite book}}: |trans-chapter= requires |chapter= or |script-chapter= (help)
—Trappist the monk (talk) 12:05, 1 June 2020 (UTC)

Trans-title for encyclopedia instead of just entry title

Can we get a trans-title parameter for the encyclopedia cited in addition to the one already in template:Cite encyclopedia for the encyclopedia entry title? It would be very helpful with citing entries in non-English language encyclopedias. Kges1901 (talk) 11:32, 6 May 2020 (UTC)

Real-life examples are always useful. Do you have one or more?
—Trappist the monk (talk) 11:34, 6 May 2020 (UTC)
One case is citing a Russian encyclopedia, whose non-Latin alphabet title would not be understandable to English readers, so I'd like to include a translation. The template Template:Cite encyclopedia only includes a trans-title parameter for the title of the entry, not one for the title of the encyclopedia. For example, {{Cite encyclopedia|title=Павлоградский Гусарский Полк|encyclopedia=Отечественная война 1812. Энциклопедия [Patriotic War of 1812: Encyclopedia]|publisher=ROSSPEN|location=Moscow|last=Podmazo|first=Alexander|date=2004|pages=539–540|language=Russian|trans_title=|trans-title=Pavlograd Hussar Regiment|ref=harv|isbn=9785824303247}} So I've been manually including a translated title in the encyclopedia field, but perhaps there is a better solution? Kges1901 (talk) 13:35, 6 May 2020 (UTC)
One solution:
{{Cite encyclopedia |script-entry=ru:Павлоградский Гусарский Полк |script-title=ru:Отечественная война 1812. Энциклопедия |trans-title=Patriotic War of 1812: Encyclopedia |publisher=ROSSPEN |location=Moscow |last=Podmazo |first=Alexander |date=2004 |pages=539–540 |language=ru |trans-entry=Pavlograd Hussar Regiment |isbn=9785824303247}}
Podmazo, Alexander (2004). Павлоградский Гусарский Полк [Pavlograd Hussar Regiment]. Отечественная война 1812. Энциклопедия [Patriotic War of 1812: Encyclopedia] (in Russian). Moscow: ROSSPEN. pp. 539–540. ISBN 9785824303247.
—Trappist the monk (talk) 14:27, 6 May 2020 (UTC)
That looks good, thanks. Kges1901 (talk) 23:46, 6 May 2020 (UTC)
We should probably also give |trans-work= some function in that template. Glades12 (talk) 18:24, 1 June 2020 (UTC)

Printer parameter?

I was wondering if a new parameter, Printer, has ever been considered for books. By Printer I mean, the company that printed the book on behalf of the author or publisher. I think people sometimes confuse or equate Printer with Publisher. OvertAnalyzer (talk) 23:42, 26 April 2020 (UTC)

How will a |printer= parameter help readers locate sources to verify content in articles? Remember that the purpose of citations, quoting from that linked page, is to identify the source, assist readers in finding it, and (in the case of inline citations) indicate the place in the source where the information is to be found. – Jonesey95 (talk) 04:47, 27 April 2020 (UTC)
The printer may also vary for the same edition. Nemo 05:24, 27 April 2020 (UTC)
You are right that the Printer parameter might not help the reader all that much, but some books, particularly self-published books, do not mention a publisher, only the printer. In such cases I believe some writers may have placed the printer's name in the Publisher parameter. By having a separate Printer parameter, it might help prevent this. Since most self-published works are not allowed, it might also help identify when someone has used a self-published work. I don't have any specific examples of this being a problem. It's just something that came up in a discussion I had about self-published works. Thanks for your thoughts on the matter. OvertAnalyzer (talk) 17:58, 27 April 2020 (UTC)
But likewise the contents, layout and pagination may also vary depending on the printer, in particular in historic books. I have seen examples of books, which had a completely different layout, and still were referred to as same edition by the author. So, while not important in mainstream cases, it is still sometimes important to know to identify a particular source. In other cases, it may just be interesting bibliographic information (citation templates serve more purposes then only being used in article references).
Such a parameter has been asked for multiple times already in the past. I support the addition of |printer= and |printing= parameters. This would help to improve consistency in the output. Otherwise people typically try to squeeze this into the |publisher= and |edition= parameters, with varying success. It's better to allow us to centrally control how this information is rendered, if given, instead of letting each editor invent his/her own style for it. --Matthiaspaul (talk) 22:13, 27 April 2020 (UTC)
I would support adding the Printer parameter. Is this the correct forum for such a discussion? If helping the reader ID the reference source is a key criteria used to determine whether or not a parameter is included, it seems there are a number of parameters that should be removed, but I think more transparency is better than less. OvertAnalyzer (talk) 01:24, 28 April 2020 (UTC)
Self-published books are problematic regarding notability, reliability or accessibility, and should only indicate |publisher=Self-published. I would flag any citation that has something else there or that does not explicitly state it is a self-published work. The parameter |via= can be used to specify the self-publishing company/platform or the distributor, who may or may not also be the printer. In any case I find it hard to believe that someone can be aided in finding a purported source by knowing who the printer is. 98.0.246.242 (talk) 02:36, 1 May 2020 (UTC)
Then you haven't dealt with historical publications, where knowing the printer is sometimes essential to identify/get a particular variant of a work. Layout and pagination could vary considerably between printers, even for works which were referred to as the same edition by the author or publisher. --Matthiaspaul (talk) 23:56, 1 May 2020 (UTC)
What are "historical publications"? Most citation systems I know of conform to bibliographic definitions of edition, where changes in font size would qualify as different editions in large part due to pagination changes. 98.0.246.242 (talk) 00:52, 2 May 2020 (UTC)
Works of the 17th and 18th century. --Matthiaspaul (talk) 01:35, 2 May 2020 (UTC)
I would support a printer= parameter too for the reasons you outlined above for older books. SarahSV (talk) 02:18, 2 May 2020 (UTC)
It seems to me that this is unnecessary. I am not certain there was a distinction between printer and publisher before the 19th century. Secondly, a work notable enough to be cited (even for historical reasons) would have current editions. Or special editions such as facsimiles which would still be considered current editions. Collectibles, one-offs, historical pieces, etc. are much harder to verify. One should not normally cite such originals, but a reliable and easily verifiable modern rendition. There are exceptions, but imo do not justify their own parameter. 98.0.246.242 (talk) 16:16, 2 May 2020 (UTC)
Well, that starts from a number of misapprehensions:
  • Pre-19th-century books often distinguish printer and publisher;
  • A work notable enough to be cited does not always have current (printed) editions or (printed) facsimiles. It may have digital facsimiles, sometimes multiple facsimiles, derived from original prints in different libraries and/or facsimiles available from different publishers (... websites). In which case only the original publisher and/or printer matters.
  • Collectibles, one-offs, historical pieces, etc. are nowadays often made available (solely) via digital facsimiles, available via multiple outlets, which makes they're available for verification, and they're cited. E.g. List of compositions by Johann Sebastian Bach printed during his lifetime lists all known prints of Bach's music in the first half of the 18th century (some of which survived in a single copy), using cite templates. Of course these primary sources are cited, with a link to digital facsimiles where available, often on multiple websites.
Nonetheless, I'd be wary to introduce a |printer= parameter. IMHO it would create more confusion than it would solve, e.g. I don't think this cite template would gain anything by including printer info:

Bach, Johann Sebastian (1751–1752). Die Kunst der Fuge (in German). RISM 991013428 (first edition, 1751) and RISM 991013429 (second edition, with preface by Marpurg, 1752) – facsimiles: mu 6406.2030 H. & Fr. Rungs Musik-Arkiv No 226A, U 315 at Royal Library, Denmark (1751 edition, DK-Kk mu 6406.2030 H. & Fr. Rungs Musik-Arkiv No 226A, U 315 at Bach Digital website); Mus. O. 17364 at Berlin State Library (1752 edition, D-B Mus. O. 17364 Rara at Bach Digital website); BWV 1080 at Baldwin Wallace University (1752 edition, US-BER Kenney 1814, Vault: M 24.B2 at Bach Digital website). {{cite book}}: External link in |postscript= (help); Invalid |ref=harv (help); templatestyles stripmarker in |postscript= at position 3 (help)CS1 maint: postscript (link)

More important than these old prints, I think the |printer= parameter will do little or nothing to address self-publishing related issues. It will confuse those who don't know self-published sources are only exceptionally, i.e. when WP:ABOUTSELF conditions are met, acceptable for WP:V purposes, and those who are aware about these policy requirements and want to circumvent it will not use the parameter (or whatever other quirk to avoid detection). So more a layer of additional complexity than a real practical advantage. --Francis Schonken (talk) 17:09, 2 May 2020 (UTC)
Per WP:Verifiability#Self-published sources, they are acceptable on other subjects too when written by experts on those subjects. Glades12 (talk) 18:40, 1 June 2020 (UTC)
You realize that you are not citing original editions, but as mentioned above, later facsimiles of originals. Whether they are digital or not it does not matter. If it is an online archive like RISM, you are now citing the archived copy, not the original work. The archive is where people will turn to find the work, or a purported facsimile of the work, and assuming the archive is reliable, where they will verify the wiki claims, or not. I still don't believe there were standalone publishers before 1900 1800. Distribution/marketing functions in the book industry, like in most endeavors did not separate from production until after the industrial revolution and the appearance of regular transport networks. 98.0.246.242 (talk) 19:02, 2 May 2020 (UTC)

Re. "Distribution/marketing functions in the book industry, like in most endeavors did not separate from production until after the industrial revolution and the appearance of regular transport networks." – incorrect. But it was different. 18th-century (or earlier) "publishers" were what today would rather be called de facto "printers", while "editors" or even "authors" who said they sold the printed work from their home, and/or from the homes of relatives and friends in other cities, would be the "publishers" of today. Also bookshops could be marked as publishers (with or without printing the actual work). Much of that would be "self-publishing" by 21st-century standards. The proposed |printer= would be of no use for the whole period. FYI, RISM does not publish copies, digital or otherwise, of manuscripts or early prints: it is solely a repository of metadata (descriptions) about such documents. --Francis Schonken (talk) 06:39, 4 May 2020 (UTC)

Issues with "cite conference" template

Hi, I ran into a number of issues with the {{cite conference}} template I would like to see addressed:

  • {{cite conference}} does not support |chapter= but should (perhaps in the form of |book-chapter=). Currently, it just silently ignores |chapter= which is no good at all as no information should be silently ignored by any template. Example:
{{cite conference |book-title=Information Processing, Proceedings of the 2nd IFIP Congress 1962, Munich, Germany, August 27 - September 1, 1962 |chapter=Chapter 14. Switching Theory |title=Application of a Finite Set Covering Theorem to the Simplification of Boolean Function Expressions |author-last=Wells |author-first=Mark B. |date=1962 |publisher=North-Holland |volume=2 |pages=731–735}}
Wells, Mark B. (1962). "Application of a Finite Set Covering Theorem to the Simplification of Boolean Function Expressions". Information Processing, Proceedings of the 2nd IFIP Congress 1962, Munich, Germany, August 27 - September 1, 1962. Vol. 2. North-Holland. pp. 731–735.
  • In another case I know the translated title of an article but not the original one. That's why I did not provide |title=, only |trans-title=. I think this is a case that should be supported by the templates in general (but since this is a generic issue, I will bring this up elsewhere), however, the error message provided by the template
{{cite conference |trans-title=Translation |author=Author |book-title=Book |volume=VI |publisher=Publisher |date=1958 |pages=35–53}}
Author (1958). [Translation]. Book. Vol. VI. Publisher. pp. 35–53. {{cite conference}}: |author= has generic name (help); |trans-title= requires |title= or |script-title= (help)
is misleading
"|trans-chapter= requires |chapter= "
(which is fine for {{cite book}} but not for {{cite conference}}). Instead it should read:
"|trans-title requires |title="
here.

--Matthiaspaul (talk) 17:41, 31 May 2020 (UTC)

{{cite conference}} has been problematic for a long time as I have noted in previous discussions. For your particular case, according to https://dblp.org/db/conf/ifip/ifip1962, the paper that you are citing (Wells 1962) is one of 5 papers in chapter 14 (possibly six if the symposium – a paper? – is included). It seems unnecessary to name the chapter when you are citing a specific paper in that chapter:
{{cite conference |book-title=Information Processing, Proceedings of the 2nd IFIP Congress 1962, Munich, Germany, August 27 - September 1, 1962 |title=Application of a Finite Set Covering Theorem to the Simplification of Boolean Function Expressions |last=Wells |first=Mark B. |date=1962 |publisher=North-Holland |volume=2 |pages=731–735}}
Wells, Mark B. (1962). "Application of a Finite Set Covering Theorem to the Simplification of Boolean Function Expressions". Information Processing, Proceedings of the 2nd IFIP Congress 1962, Munich, Germany, August 27 - September 1, 1962. Vol. 2. North-Holland. pp. 731–735.
Wells lists this paper in the bibliography of his Elements of Combinatorial Computing (item 253) without mention of the chapter.
—Trappist the monk (talk) 23:00, 31 May 2020 (UTC)
Error message tweaked:
{{cite conference/new |trans-title=Translation |author=Author |book-title=Book |volume=VI |publisher=Publisher |date=1958 |pages=35–53}}
Author (1958). [Translation]. Book. Vol. VI. Publisher. pp. 35–53. {{cite conference}}: |author= has generic name (help); |trans-title= requires |title= or |script-title= (help)
—Trappist the monk (talk) 14:33, 2 June 2020 (UTC)

{{cite journal}} In-Source Locations Documentation Incorrect for Page Number Display

Page numbers are always displayed with colons, never with p & pp. This always happens whether nopp is present or absent. nopp seems to be irrelevant for {{cite journal}}. The documentation says otherwise. —65.78.11.84 (talk) 22:06, 3 June 2020 (UTC)

{{cite journal}} is working as it should. {{cite journal}} separates |page(s)= from |issue= with <colon><space> and does not render p. or pp. page prefixes so |no-pp= is meaningless.
If you are not citing an academic or scholarly journal article, perhaps {{cite magazine}} is a better choice; it does render p. or pp. and does obey |no-pp=:
{{cite magazine |title=Title |magazine=Magazine |volume=1 |issue=2 |page=3 |no-pp=yes}}
"Title". Magazine. Vol. 1, no. 2. 3.
—Trappist the monk (talk) 22:22, 3 June 2020 (UTC)
I have updated the documentation to reflect the above discussion. Please see Template:Cite journal#In-source locations, where I have attempted to suppress all mention of "p." and "pp." and |nopp= from that section of the {{cite journal documentation}}. I am sure that further improvement is possible. – Jonesey95 (talk) 23:00, 3 June 2020 (UTC)

Where should a preposition in a name be listed in the citation?

I would like to cite this source (a review of Love and Information) in a section on reception. The review was written by John Del Signore. Should the "Del" be placed in the "first" parameter or the "last" one? AndrewOne (talk) 21:24, 3 June 2020 (UTC)

No doubt – no doubt – there are those who will disagree with me, but I think that |last=Del Signore is correct. Others will say that |first=John Del is correct. I choose the former because, assuming 'Del' is a preposition to the surname, it belongs before and there for with the surname; not after the given name. Of course, if 'Del' is a second given name then the second form is correct. Hard to know. If 'Signore' is Italian, John certainly is not so it is entirely possible that |first=John Del are English or American given names for an English or American writer from an Italian family.
So, none of that really answering the question, you might avoid the issue with: |author=John Del Signore. You also might ask the author. If you do and get a reply, note the author preference in the article with a hidden comment so that some editor here doesn't change the name to their preferred form sometime in future – of course, editors do ignore hidden comments...
—Trappist the monk (talk) 21:54, 3 June 2020 (UTC)
I would definitely put the particle "Del" with the last name because in all the instances I know of, the particle modifies the main part of the last name. In this case, according to Ancestry.com Del Signore means "of or belonging to the lord", not "of or belonging to John".
That said, if the article contains a bibliography in alphabetical order (whether it's called "References", "Works cited", or some thing else) the question of whether to put the citaion in the Ds or Esses is an open question. Chicago Manual of Style 17th ed. calls for following the preferences of the person, if known (they use mostly the same rules for bibiographies). Page 949 gives a list which I reproduce in part, which illustrates the possible variations:
Bauvoir, Simone de [plainly does not fit with citation templates]
Ben-Gurion, David
La Fontaine, Jean de
Leonardo da Vinci [I'm not sure if the concept of a family name existed during Leonardo's time.]
Medici, Lorenzo de'
Van Rensselaer, Stephen
In short, I don't think citation templates are up to the task of following some of the popular "systems" of alphabetization that are out there. Jc3s5h (talk) 22:13, 3 June 2020 (UTC)
The rule I am aware of is that prepositions like "de" belong to the surname, but are ignored during sorting, so (boldface by me):
de Beauvoir, Simone
Ben-Gurion, David
de La Fontaine, Jean
de' Medici, Lorenzo
Van Rensselaer, Stephen
Del Signore, John
da Vinci, Leonardo
--Matthiaspaul (talk) 23:38, 3 June 2020 (UTC)

Differing page numbers in different versions

What should you do when the page number differs between different versions of the same document? An example is the manual for Metroid: Samus Returns, in which page 4 is page 11–12 in the PDF file. (Not currently planning to cite it, but noticed this issue at Talk:Metroid: Samus Returns#Checkpoints.) Glades12 (talk) 13:22, 3 June 2020 (UTC)

Cite the version you read. If you read both versions, and they both support the statement equally well, cite the version that is more accessible to readers. If you feel it's important to point out both versions to readers, cite one and list the other in a "Further reading" section, with an explanation at the end of the "Further reading" entry of why it is included. Jc3s5h (talk) 14:45, 3 June 2020 (UTC)
I didn't mean "version" as in "different/updated content", I meant it as in "different way of accessing the same content". There are virtually no differences (even graphical) between the PDF manual and the manual accessible with a 3DS and copy of the game (I've read both), so your answer is not satisfactory here. You wouldn't get the latest edition of a book from a library, cite it somewhere, and then make a separate "Further reading" entry for the exact same edition of the book available on the Internet but with a different system of page numbering. You cite them simultaneously, because they are the same source. Glades12 (talk) 15:23, 3 June 2020 (UTC)
Sorry for being unclear about this. Glades12 (talk) 15:38, 3 June 2020 (UTC)
They are not the same source, because these are different media/formats that are accessible, and therefore verifiable differently. Even though "source" is narrowly defined as any content that verifies a claim, everything else in a citation is a direct or indirect aid in locating said content. For discovery and verification purposes, you are describing two distinct versions. As offered above, cite the one you read. If you have read both, cite the more accessible one. If you want to include both, you need two citations. 50.74.165.202 (talk) 19:41, 3 June 2020 (UTC)
Is the scan of a book on Google Books a different source from the print one too? Then we have a lot of citation splitting to do... Glades12 (talk) 05:45, 4 June 2020 (UTC)
No, in this case only the print version is relevant, Google is just a "provider", not a publisher. But an online reissue by the publisher would be something that would have to be distinguished from the original. From how I understood your example, you had two variants of a document which probably had the same origin, but were formatted and published independently, hence the page numbers in the printed version and missing page numbers in the electronic version.
--Matthiaspaul (talk) 09:35, 4 June 2020 (UTC)
In this case, I would put the emphasize on the page numbers in the printed version. The PDF document you linked to does not provide any page numbers at all (only the page numbers assigned by the PDF viewer, which is yet another set of page numbers and may differ from those in the document depending on various circumstances - they are almost never relevant for reference purposes). If the electronic document would have page numbers as well, and it would be for some reason important to mention them in addition to those in the printed document, I would not add the second source to "Further reading" but just append a comment to the citation (that is, between the closing }} and the </ref>).
--Matthiaspaul (talk) 16:18, 3 June 2020 (UTC)
I would use |at= or |chapter= instead of trying to figure out page numbering. – Jonesey95 (talk) 17:10, 3 June 2020 (UTC)

Multiple authors — any limit on how many authors to mention?

Greetings!

Brevity is the soul of wit, is there any limitation on how many authors should one mention when referring to a source? I'm dealing with an article that mentions a dozen of authors (as typical to natural sciences): Lucy J. E. Cramp, Richard P. Evershed, Mika Lavento, Petri Halinen, Kristiina Mannermaa, Markku Oinonen, Johannes Kettunen, Markus Perola, Päivi Onkamo, and Volker Heyd.

Should I omit some of the authors, how should I cite the source in question? Thank you very much in advance! :-)

Cheers! Jayaguru-Shishya (talk) 17:42, 4 June 2020 (UTC)

You may include as many as you wish or which you think are necessary to find the source in question. There is |display-authors= if you choose to omit some or wish to have all in the wikitext but display some number fewer. --Izno (talk) 17:47, 4 June 2020 (UTC)
Granted, I would recommend against listing everyone involved in the production of a blockbuster film or AAA video game. Glades12 (talk) 05:43, 5 June 2020 (UTC)

Harmonizing CS1/CS2 into CS, and other cleanups for consistency?

Now, that CS1 also issues harv-style anchors by default, the differences between CS1 and CS2 citation styles are marginal (unless I miss something).

Since maintaining two systems where one would be sufficient complicates documentation and guidelines, error messages, parameter names etc. throughout Wikipedia, I think it is time to merge them to a point where it is no longer necessary to refer to them as two styles. The current system is difficult to grasp for newcomers. For them, it would be easier to have one system, and if they need special support for something that is not the default, to have a parameter for this.

Please don't get me wrong, I don't want to remove any functionality, I just want to remove artificially / historically created complexities / unnecessary hurdles in producing an easier to understand and document citation system for the majority of users.

  • At present, we have a |mode= parameter which can be set to CS1 or CS2 style. Apparently, this only changes the usage of commas and dots between citation elements, if or if not a terminator will be placed after a citation, and if some messages are displayed in upper- or lowercase. If so, why don't we introduce dedicated parameters with self-explanatory names to control these behaviours and then deprecate (and much later remove support for) |mode=? (Optionally, add corresponding parameters to the "Use xyz date" templates (like for auto-date formatting), so that citations can be brought into a consistent style easily.)
  • Although long deprecated, we still support the |year= parameter, which is apparently only needed in the rare cases, where references need an additional disambiguator like "a", "b". If so, why don't we introduce a specific self-expanatory parameter for this like |disambiguator= and later remove support for |year=? Right now, the documentation is quite long-winded to explain why the parameter is deprecated, but under which specific conditions it can still be used. Instead, with |disambiguator= the documentation could simply explain how to use it when needed in a positive way.
  • With |year= gone and |orig-year= actually being a parameter to specify dates rather than only years, we could finally rename it into |orig-date= for consistency.
  • Of course, before removing support for the old parameter names in perhaps a year, we would need to support both for a transitional phase and to run a bot to update all citations to use the new parameters. Since no functionality will go, this would be a straight-forward "mechanical translation" which does not require user interaction.

The first three points are independent of each other, but since we would have to run a bot, it would be good to let it address all three points in one go. Comments? Remarks? --Matthiaspaul (talk) 10:48, 4 June 2020 (UTC)

Mostly indifferent to this, but I would like |year= to at least be kept as an alias for |date=. Who said it's deprecated? I personally find it useful. I do support making |orig-date= work somehow, however. Glades12 (talk) 13:27, 4 June 2020 (UTC)
But the year can be specified using the more flexible |date= parameter as well, e.g. |date=2020.
|year= was deprecated when we faded out the |month= and |day= parameters years ago. The only reason we kept it was its secondary use to specify an optional disambiguator for anchors like |year=2020b, which, from a user's perspective trying to understand how to use our citation templates, would be better served by a dedicated parameter like |disambiguator=b (prototypical name).
--Matthiaspaul (talk) 15:21, 4 June 2020 (UTC)
No. |year= is not, and never has been, deprecated. In cs1|2, to deprecate a parameter, the parameter's assigned value is changed from true to false in the Module:Citation/CS1/Whitelist tables where the parameter name is listed (basic_arguments and limited_basic_arguments in this case). It is true that |date= is the preferred parameter because that parameter name is more flexible.
—Trappist the monk (talk) 15:54, 4 June 2020 (UTC)
|year= is not and should not be deprecated. It's very handy when you want only the years, and not the full dates of publication. Headbomb {t · c · p · b} 16:33, 4 June 2020 (UTC)
Can you elaborate on this, please? |date= has the same length as |year=, so what is so handy about |year=?
--Matthiaspaul (talk) 18:13, 4 June 2020 (UTC)
Year holds the year. Date holds the date. Headbomb {t · c · p · b} 19:46, 4 June 2020 (UTC)
Bummer. My question was genuine, not rhetorically. I really tried to understand you, because even if our preferences obviously differ, it is important to understand each other in order to think up and implement the best possible solution - ideally one which works for everyone...
In my book, date is a superset of year.
Either way, if the |year= is only for years, why do we use it to specify citeref disambiguators, which have nothing at all to do with years (or dates)? They clearly belong into a different parameter...
Do you believe that any user will have problems to grasp that if they only have a year, they can still stuff it into |date=?
And if |year= is for years, why don't we reintroduce the |month= and |day= parameters?
To me, |year= is a left-over from the distant past, when |month= and |day= were removed, and it is inconsistent with how we can specify dates today due to the improved "smartness" of the citation template making sense of dates given in a multitude of possible formats. It makes the documentation more complicated than necessary, it is a (small) special case in the code, it makes spiders and bots reading the source code (slightly) more complicated than necessary. Anyway, we could even keep it as an alias for |date=, what I am "complaining" about is its usage for disambiguators. There really must be a better solution to this.
--Matthiaspaul (talk) 20:18, 4 June 2020 (UTC)
I haven't looked this up in the sources, but apparently |date= undocumentedly supports the disambiguator thing as well |date=2020b - it shouldn't, but even less a reason to keep |year=.
--Matthiaspaul (talk) 21:36, 4 June 2020 (UTC)
|date= and |year= support anchor ID disambiguation in a way that editors see as similar to the anchor link disambiguation used by the {{harv}} and {{sfn}} templates. Before we converted to Lua, |year= was the only parameter that could accept an anchor ID disambiguator. I think that that was because appending the disambiguator to |date=, at the time, caused #time parser errors. Conversion to Lua muted the restriction. We elected at the time to make the anchor disambiguator a suffix character for dmy, mdy, my, and y (and the various ranges and season) formats and to not insert the anchor ID disambiguator into the middle of ymd dates (2020a-05-29) so |year= was retained to support anchor ID disambiguation when the citation uses the ymd publication date format. No doubt, we could revisit that decision.
—Trappist the monk (talk) 22:16, 4 June 2020 (UTC)
Our documentation states:
Date: Full date of publication edition being referenced, in the same format as other dates in citations in the same article. Must not be wikilinked.
or: year: Year of publication edition being referenced. Discouraged in favor of date, except in the rare case that all of the following conditions are met:
  • the publication-date format in the template is YYYY-MM-DD
  • the citation requires a CITEREF disambiguator
  • the template uses |ref=harv or |mode=cs2 or the template is {{citation}}
So, the wording is "discouraged". The bottom line is the same...
--Matthiaspaul (talk) 18:13, 4 June 2020 (UTC)
Nay, not the same. When we deprecate a parameter, that is the final step before support for it is withdrawn. To get to the deprecated state, we have to have taken the decision to withdraw support for that parameter. We have taken no decisions to withdraw support for any of the discouraged parameter (we also discourage |authors= and |editors= neither of which is deprecated – as an aside, I would like to see these two deprecated and removed because they do not contribute to the citation's metadata).
—Trappist the monk (talk) 18:32, 4 June 2020 (UTC)
Something I would support as well. Same for |vauthors=, as it encourages editors to be lazy. --Matthiaspaul (talk) 19:30, 4 June 2020 (UTC)
"marginal": Oh, you sweet summer child. --Izno (talk) 17:16, 4 June 2020 (UTC)
Are there other differences than those documented?
--Matthiaspaul (talk) 18:13, 4 June 2020 (UTC)
Only social preference. :) I count this one among the list of "will we ever use one date format?" and "which form of English should Wikipedia use?". --Izno (talk) 18:20, 4 June 2020 (UTC)
Okay, then I'm relieved for being called only an out-of-the-box thinker rather than a lunatic.
Personal preferences or social differences should never keep us from striving for the best-possible solution for the majority of users. Above, I wrote about a time span of one year, but this isn't actually important, it could be five or ten years - enough for really everyone to adjust. However, in order to eventually achieve a more consistent system we will have to start somewhen - the earlier the better. That's why I brought up the topic.
Regarding date formats, in the very long run I actually see one unified date format: "yyyy-mm-dd", because of its many convincing advantages in an international context, and also because it is a good middle ground between the other two formats. But something I would like to see even more than a single date format is user-customizability (a setting in user preferences or a user script to be included and working similar to {{Use xyz dates}}). Would work only for logged-in users, but nevertheless...
--Matthiaspaul (talk) 19:30, 4 June 2020 (UTC)
The main reasons I prefer CS2 to CS1 are (1) lots. of. incredibly. annoying. periods. breaking. up. the. flow. of. the. citation. and. making. it. difficult. to. continue. the. citation. within. a. sentence. without. weird. period-comma. combinations., and (2) less a technical thing because you can actually get either style from either set of templates, but a philosophy that every citation can be formatted with a single template in a single style rather than having to break out separate templates with separate styles for each different type of publication one might encounter. I'm sure other editors have similar reasons why they prefer CS1 to CS2, beyond merely force of habit. But the punctuation thing, minor as it may appear, is actually a big obstacle to unifying the templates in either direction because in many cases the way they're embedded into their surrounding context depends on that. Anyway, if I were pushing to unify citation formatting, CS1 versus CS2 is not where I'd start; instead, I'd push to get rid of Vancouver style. As for date format choice, I think the real solution is to make it a reader preference instead of an article-author preference, so Wikipedia readers could get all dates reformatted into their own preferred style. —David Eppstein (talk) 19:36, 4 June 2020 (UTC)
Personally, I'd harmonize the two styles by using commas (as in CS2) and terminating the citation with a period unless |postscript= is used. That would also mean following the capitalization from CS2. Then we could have a discussion about the appropriateness of Vancouver style in the merged CS. Imzadi 1979 → 21:03, 4 June 2020 (UTC)
I think I could probably handle periods in most of a citation; what I don't think I could handle is not terminating an Author/Editor/Interviewer/Person List with a period, given its use of semicolons in a fully-used template (for |first= and |last=). --Izno (talk) 01:24, 5 June 2020 (UTC)
Punctuation in formatted citations is not there to make them look good. Neither should such citations be read as prose, as they are more or less like shorthand. Punctuation is a field delimiter, bookmarks that let the reader know where a certain citation element begins and ends. And punctuation, like capitalization, is an element of style. Imo, a citation style that uses two different modes of punctuation could be legitimately described as two styles, not one. 64.9.245.154 (talk) 12:22, 5 June 2020 (UTC)
Be aware that both separator types can cause ambiguity. Full stops: "Book. p. 1, sec. Section." ("p" and "sec" look like separate data items). Commas: "News Article, Everything Local, National, and Beyond, Small Town, United States: Informer, Inc." Glades12 (talk) 05:09, 6 June 2020 (UTC)

Unknown parameter "acccess-date"

Not sure what is wrong (from Arkansas State University): 

{{cite web |url=https://www.nacubo.org/-/media/Nacubo/Documents/EndowmentFiles/2019-Endowment-Market-Values--Final-Feb-10.ashx?la=en&hash=9E941CF13A17783282F46626C72FE7AFB63F9D82 |title=U.S. and Canadian Institutions Listed by Fiscal Year (FY) 2019 Endowment Market Value and Change* in Endowment Market Value from FY18 to FY19 (Revised) |publisher=[[National Association of College and University Business Officers]] and [[TIAA]] |date=2020 |acccessdate=May 6, 2020}}

-- GreenC 13:28, 19 May 2020 (UTC)

Too many 'c'
—Trappist the monk (talk) 13:34, 19 May 2020 (UTC)
Ahh. The Invisible Gorilla. Couldn't see it but now plainly obvious. -- GreenC 14:15, 19 May 2020 (UTC)
If you use access-date instead of accessdate then spellcheck is more helpful catching these kinds of minor typographical errors. The benefits of unambiguous and correctly spelled names for template parameters should be increasingly clear to template programmers. -- 109.77.203.218 (talk) 01:40, 7 June 2020 (UTC)

Use of Pages in Cite Journal

In the thread at Wikipedia:Teahouse#Question on Formatting (Note this willl no doubt be archived shortly, changign the location) Tenryuu argued that When you are referencing a source, you have to mention all the pages it is found in the journal. If you want to specify which page it is from, you can use a template like {{Rp}} or {{Sfn}} to do so and that this was true even when a particular journal was only being sited a single time in a given Wikipedia article. I believe this is incorrect, and I read the documentation for {{cite journal}} to say so, specifically the part reading page: The number of a single page in the source that supports the content. and that a single citation should not require the use of {{Rp}} or {{Sfn}}. I say that the basic cite should, without any helper templates, point the reader to a specific place in the source where the fact being cited is supported, and that this is if anything more essential in Cite Journal than, in say, {{cite news}}, because a journal article is often long and reading the entire article to verify a single fact is often impractical. Am I correct about the current usage of Cite Journal, or not? Pinging others involved in the Teahouse thread. @Gyanda, Usedtobecool, GoingBatty, and AlanM1: DES (talk)DESiegel Contribs 13:47, 11 May 2020 (UTC)

(Link update: Wikipedia:Teahouse/Questions/Archive 1060#Question on Formatting)
--Matthiaspaul (talk) 16:13, 18 May 2020 (UTC)
There is no have to mention all the pages (emphasis mine). WP:V § Responsibility for providing citations says: Cite the source clearly and precisely (specifying page, section, or such divisions as may be appropriate). It is a disservice to our readers to make them search for one paragraph, for one sentence, for one tiny morsel in a multi-thousand-word source. That is just cruelty. When using {{rp}} or {{sfn}} or {{harv}} then, the full-cite in §Bibliography probably should list the page-range covered by the source (journal articles, book chapters) but for in-line citations, just the page(s) that lead the reader to identify the location in the source.
—Trappist the monk (talk) 14:06, 11 May 2020 (UTC)
In other words, there's really no problem then. I was talking about going by mentioning where one can find the work in the References section, similar to APA citation. —Tenryuu 🐲 ( 💬 • 📝 ) 14:31, 11 May 2020 (UTC)
Do remember that CS1 is not APA. It is mcloser to COoS, but it is its own style. In an article that does not use harvard or short foot notes (whioch is most articles here) the "Notes" or "References" sectio0n is the total list of actual citations. Each citation muist, in some way, include the specifiic in-source location of the supporting facts. That is not optional. The page range for the article is optional, and soime have argued that it is not even desirable. But whatever means are used, the specific location, normally a page or a small number of pages, must be given. DES (talk)DESiegel Contribs 15:07, 11 May 2020 (UTC)
Opinion is divided on this point. The documentation is also contradictory, with the description of |pages= saying it is for the specific pages supporting the statement and the examples showing it used for the whole journal article. The latter interpretation is clearly correct when {{cite journal}} occurs in a list of sources; the difficulty arises when it is used in a <ref> tag. Here both sets of pages are important, one for locating the support for the statement within the article, and the other for locating the article, but |pages= has room for only one. As I noted, opinion is divided here. My personal practice (when not avoiding the issue by using short references) is to use |pages= for the whole article and add the specific pages after the {{cite journal}}. (There is some discussion further up the page on having two separate parameters to deal with this issue.) Kanguole 14:34, 11 May 2020 (UTC)
I find this very interesting and may also use it. Thanks for the input! Kind regards, --Gyanda (talk) 11:17, 15 May 2020 (UTC)
@DESiegel: If I'm sourcing a single sentence, I would specify the |page= that sentence is on, knowing they could read other pages if they wish. If I think the reader needs to review multiple pages to support the Wikipedia article, I would use |pages=. GoingBatty (talk) 15:05, 11 May 2020 (UTC)
Yes that would be my practice as well, GoingBatty and that is how I read the template documentation, But it seems that some people want to use pages for the entire range of pages occupied by a journal article, which would require {{RP}} or some other mechanism to specify the exact paqge. In any case, I say that the exact page must be specified in some way. WP:BURDEN seems to me to say that also. DES (talk)DESiegel Contribs 15:10, 11 May 2020 (UTC)
Not necessarily. In {{cite journal}} and other templates, the article cited is considered an in-source location. In source locations have traditionally (and correctly) been specified in their entirety, as an indivisible item. However, this was when such items were much shorter than the average journal article of today, where context may be needed. If an editor does not want to use a short ref and a bibliographic entry, one of the better proposals imo from the related discussion on page ranges above, is to add the page context as an editor interpolation, in brackets. Another option would be to allow |pages=and |at= to coexist in a reference. 98.0.246.242 (talk) 17:18, 11 May 2020 (UTC)
I have to tell you, editor with IP ending in 246.242, that journal articles of 50 to 100 pages or more have been common in some journals going back decades before the founding of Wikipedia, indeed back before 1900. The standard here has always been that a citation must identify the location of the content being cited as precisely as is reasonably possible, to allow readers to verify that the cited source supports the statement. a page range of 20, let alone 50 or more, pages is not helpful for that purpose. Citations to paginated articles should cite a specific page, or a short range if the supporting information is on more than one page, whatever mechanism is used to format the citation. Citing the entire article is better than nothing, but not sufficient. DES (talk)DESiegel Contribs 20:58, 11 May 2020 (UTC)
My thoughts are aligned with DES. Of what practical benefit to the reader is providing the full page range of an article when only a specific single page is necessary to verify the content for which we are providing the cite (which is the point of citations)? The reader can easily find the article in the journal's table of contents if they want to read the whole thing or see the title page, and I imagine some pubs make it even easier with headers/footers. However, this is a far less likely use case than finding the specific relevant page. I wouldn't object to another parm to contain the full page range, but in its absence, the specific page is more important. (I'm also unsure whether there can be a non-confusing way to render both values.) —[AlanM1 (talk)]— 23:26, 11 May 2020 (UTC)
Well, no-one disputes that. There are several ways to present the needed information now, with the current system. Also now, and properly, what goes in |title= is the in-source location (the article). When it comes to the relevant pages, it would be inexact to substitute the context subset for the entire range. It is not representative of what you are citing, with the discrepancy becoming fairly obvious when one looks at the source's table of contents, which likely gives an indication of the actual range, and where also likely, readers may turn to first. In similar fashion when one is citing a book chapter, where a page range should be given. Again there are options to add the context pages in that chapter with the current system. I wonder how often 50 or 100 page-articles were cited in general reference lay works like Wikipedia. Scientific papers up for peer review perhaps or similar? I don't think it is fair to compare the reference system in such works, with Wikipedia's own, which has a different purpose and target. 98.0.246.242 (talk) 23:42, 11 May 2020 (UTC)
It seems that you dispute it, editor with IP ending in 246.242. Specifically "it" is I wouldn't object to another parm to contain the full page range, but in its absence, the specific page is more important. When you write When it comes to the relevant pages, it would be inexact to substitute the context subset for the entire range. you seem to be disagreeing, and I disagree with you. More specifically I think that the actual page or pages where the info being cited may be found (which I think is what you mean by the "context subset") are far more important to show in a ref, and that failure to do so is what is inexact. As to past practice, Wikipedia has cited peer-reviewed academic journal articles since early in i8ts history, at least, Previous encyclopedias and other tertiary sources such as textbooks did not usually cite such sources, but they had named authors with reputations for each article, and that presumably made their selections from source literature more reliable, with no need (or much less need) for readers to verify sources. Even so, books and book chapters were cited by encyclopedia articles, so some of the same issues will have arisen. But Wikipedia's citation practices are more closely based on those of academic publications than those of older encyclopedias and similar publications. DES (talk)DESiegel Contribs 00:06, 12 May 2020 (UTC)

User:AlanM1 asked "Of what practical benefit to the reader is providing the full page range of an article when only a specific single page is necessary to verify the content for which we are providing the cite (which is the point of citations)?". In the days before the internet, if a reader's library didn't have a certain journal, it the reader's library would request a copy from a library that did have it. If the reader were able to specify the exact pages to be copied (for the whole article), the request would be more likely to be filled correctly. (The person filling the request might be a part-time student employee, who might or might not have partied the previous night.) It still conceivable that some Wikipedia reader requests may be filled in this fashion.

Of course it is also desirable to specify the exact pages which support the claim in the Wipedia article. Jc3s5h (talk) 01:41, 12 May 2020 (UTC)

I would think a request for just page 135 would be more likely to be filled than a request for pages 120–160. Not to mention cost if you have to pay for the copies. —[AlanM1 (talk)]— 03:33, 12 May 2020 (UTC)
One has to represent what one cites. In this discussion what is cited is an in-source location (the article). This location must be given accurately, by including the page range. There is no disagreement on the need for a 3rd-level location in order to provide context. This can be done now, as pointed out. If a parameter to specify this is introduced, it should not, imo preclude the page range. There is the parameter |at= that can be used for this with a tweaking of the code. And definitely Wikipedia's citation styles should not be based on academic practice. They are different beasts with different needs and audiences. 64.9.249.161 (talk) 14:07, 12 May 2020 (UTC)
@IP161: When citing a magazine article that appears on pages 4–8, we don't necessarily cite |pages=4–8 if we're citing a sentence on page 6. Same with a newspaper article that appears on pages 4, 6, 9, and 12. Why is a journal cite different? —[AlanM1 (talk)]— 01:07, 14 May 2020 (UTC)
Because that's the way that journal articles are traditionally cited. definitely Wikipedia's citation styles should not be based on academic practice. They are different beasts with different needs and audiences – I agree that they don't have to be exactly the same, but given that this is an encyclopedia, and given that many scientific and technical articles make heavy use of academic sources, our style should not depart too far.
Note that this is the same as citing chapters or sections in books; traditionally the page range of the "entity", here the chapter or section, is given. Peter coxhead (talk) 09:02, 14 May 2020 (UTC)
It is not possible to fit your readership to your citation style. You have to fit your citation style to your readership. Why is this simple notion so hard to understand? This being a layman's general purpose project, what kind of reader does that imply? Academics? Experts? They have a multitude of established, reliable sources to turn to. Do you think Wikipedia is their go-to source? Both the citation structure and it's presentation should be designed for the audience you actually have. Otherwise it is a hobby for dilettantes. 172.254.241.58 (talk) 13:10, 14 May 2020 (UTC)

The CMoS says at https://www.chicagomanualofstyle.org/tools_citationguide/citation-guide-1.html

Chapter or other part of an edited book

In a note, cite specific pages. In the bibliography, include the page range for the chapter or part.

Journal article

In a note, cite specific page numbers. In the bibliography, include the page range for the whole article. For articles consulted online, include a URL or the name of the database. Many journal articles list a DOI (Digital Object Identifier). A DOI forms a permanent URL that begins https://doi.org/. This URL is preferable to the URL that appears in your browser’s address bar.

Now CS1 is not the CMoS, but it is probably based more on Chicago than on any other single style guide. Therefore the CMoS guidance is relevant, although not definitive. An ordinary <ref>...</ref> tag functions as both a note and a bibliography entry, but mostly as a note. And use in simple <ref>...</ref> tags is probably the primary use case for any of the CiteX templates, including {{Cite Journal}}. Harvard style refs or the use of {{sfn}} are far less common, to the best of my understanding. Therefore the template should be adapted to the note form fist, ideally with a way to handle the other forms also. But when used in a note context, the exact page or, pages where the info being cited appears should be listed, and not the page range for the entire article, if there is not a convenient way to list both (such as the proposed |page range= or |page-span=). The comment of 241.58 above has a good point about the probable audience as well. DES (talk)DESiegel Contribs 15:44, 14 May 2020 (UTC)

A citation in a <ref>...</ref> tag does indeed combine the functions of a note and a bibliography entry. That is exactly why both page ranges are needed in the case of a journal article or chapter in a edited book. The audience for citations is people who want to examine the original source. If that is an academic journal or edited book, it will be convenient for the citation to follow academic conventions. Kanguole 16:08, 14 May 2020 (UTC)
Note also that https://libguides.nps.edu/citation/chicago-nb#journal says:
Journal Article: Always include page numbers in notes when available.
I don't see that "academic conventions" include any case where the actual exact pages cited are not provided in one form or another. Specific page(s) are excluded only in bibliography entries intended to be read together with specific notes that give specific pages. If one or the other must be omitted, it should be the page range. DES (talk)DESiegel Contribs 16:39, 14 May 2020 (UTC)
The point, which follows from combining a note and a bib entry, is that neither page range should be omitted. At least two methods of achieving that with the current templates have been suggested. Kanguole 16:48, 14 May 2020 (UTC)
@Kanguole: I would suggest, if this is necessary, a new parm be created for the full-article range (maybe |article-pages=) so the meaning of the existing page(s) parms remains consistent (as the specific page(s)) across books, newspapers, etc.. Where should this new parm be shown in the rendered cite? E.g., |article-pages=247–256 in:
—[AlanM1 (talk)]— 08:47, 16 May 2020 (UTC)
It would require two new parameters, say |article-pages= and |cited-pages= (each with singular variants), because |pages= is currently being used for both purposes. There have been a few suggestions for rendering, e.g. adding the cited page(s) at the end, or putting it after the article pages in square brackets, but it's probably better to get the meaning sorted out before thinking about rendering. Kanguole 09:05, 16 May 2020 (UTC)

This came up again at Wikipedia:Teahouse#In cite journal template, how to use page number as identifier, along with a question as to whether a page number should be used for the |id= parameter for a pre-internet journal. I want to urge that the be some motion on this. I think it is a mistake to have a different use for the |page= and |pages= parameter on cite journal than on other citation templates. I think it is an even bigger mistake for people to urge the use of the template in a way contrary to its documentation. Either agree to change the documentation, or agree to use the template as documented. I think the {{rp}} solution is clumsy and likely to be missed. A usage such as |pages=240-280 [257] works now, and is better IMO than RP, but a new parameter, or even two new parameters would be better yet. But if we are to use |pages=240-280 [257] let us have consensus that it is the form to use for this case, and modify the documentation to describe it and suggest its use. DES (talk)DESiegel Contribs 22:04, 6 June 2020 (UTC)

Note that the |pages=240-280 [257] form would only be appropriate in a citation of a journal article or separately-authored book chapter that was within <ref> tags. For a citation of a book inside <ref> tags, one would specify only the pages supporting the statement. For a journal article or separately-authored book chapter in a list of works, one would specify the pages of the entire article only. (And for a book in a list of works, no pages would be specified.) So the usage would still vary depending on the kind of citation and its context. Kanguole 09:50, 7 June 2020 (UTC)

Change to doc for agency=

Wire services cannot sell content to themselves, so it's inaccurate to use |agency= for content they publish on their own websites, such as apnews.com. When they do that, they are not acting as wire services. Propose change from:

agency: The news agency (wire service) that provided the content (if different from the work and publisher); examples: Associated Press, Reuters, Agence France-Presse. May be wikilinked if relevant.

to:

agency: The news agency (wire service) that provided the content; examples: Associated Press, Reuters, Agence France-Presse. Do not use for sources published on the agency's own website; e.g. apnews.com or reuters.com; instead, use work or publisher. May be wikilinked if relevant.

―Mandruss ☎ 17:48, 7 June 2020 (UTC)

Perhaps that says the same thing, I don't know. But it says it clearer, and there is a clear need for clarification since many editors are not using the parameter that way. ―Mandruss ☎ 18:08, 7 June 2020 (UTC)

Go for it. The change is reasonable. --Izno (talk) 20:29, 7 June 2020 (UTC)
Went for it. ―Mandruss ☎ 20:58, 7 June 2020 (UTC)

mask style

Use of a two-em dash (—) is preferred for omission over two em dashes (——). 🖖 ChristTrekker 🗣 21:27, 2 June 2020 (UTC)

Citation Style 1 mask options are well defined, and explained at Template:Cite_book#Display options, where editors are provided with the option of specifying the number of em dashes that are used for the masking. (And that "two-em dash" above is just an em dash, according to https://r12a.github.io/app-conversion/, and doesn't take up two ems on my screen.)
One dash: John Doe. Title. {{cite book}}: Unknown parameter |authormask= ignored (|author-mask= suggested) (help)
Two dashes: John Doe. Title. {{cite book}}: Unknown parameter |authormask= ignored (|author-mask= suggested) (help)
Does that help? – Jonesey95 (talk) 21:39, 2 June 2020 (UTC)
Real Unicode two-em dash, for your copy-pasting pleasure (U+2E3A): ⸺ … and a real three-em dash, for good measure (U+2E3B): ⸻ Out with fake kerned-together dashes, in with Unicode! (The one posted above is indeed an em dash, not a two-em dash.) —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 04:10, 3 June 2020 (UTC)
I used a real two-em dash, but MediaWiki "helpfully" converted it, I guess. 🖖 ChristTrekker 🗣 21:11, 11 June 2020 (UTC)

Chapter-id or Chapter-doi parameter?

For some Springer publications and probably ACM & IEEE proceedings, the chapter or article has a DOI. For Springer the publication may also have a DOI. Would a general chapter-id or a specific chapter-doi be warranted. chapter-id could be used for arXiv values or NCBI NBK numbers for a chapter.

Waldhausen F. (1985) Algebraic K-theory of spaces. In: Ranicki A., Levitt N., Quinn F. (eds) Algebraic and Geometric Topology. Lecture Notes in Mathematics, vol 1126. Springer, Berlin, Heidelberg DOI https://doi.org/10.1007/BFb0074449 Print ISBN 978-3-540-15235-4 Online ISBN 978-3-540-39413-6

The URL https://link.springer.com/book/10.1007/BFb0074435 resolves to the book and the DOI portion resolves too. RDBrown (talk) 03:05, 12 June 2020 (UTC)

Are you intending to re-create the debacle of several years ago when url= was changed from attaching to book chapters to attaching to their titles and for years and years after I kept finding citations where the link was in the wrong place? If you have both a doi for the chapter and another doi for the book, why do you think readers want to be presented with both of them and having to distinguish between them? Is there an example where the landing page for the doi for the chapter fails to provide a link to the overall book? —David Eppstein (talk) 04:42, 12 June 2020 (UTC)
To be honest, when I had both available, a chapter and a book DOI, I always provided the book DOI (and sometimes left the chapter DOI in a comment). I guess, good arguments can be found for both. Either way, this example shows that we should better distinguish between them in the future, in particular now that some users want to add auto-linking...
In the case of the Springer DOIs it seems to be possible to tell them apart programmatically, but is this a general scheme or just their way of doing it? If not, we actually might need self-explanatory |chapter-doi= and |book-doi= parameters, so that editors can specify which type of DOI they provide.
--Matthiaspaul (talk) 11:35, 13 June 2020 (UTC)
Breaking existing citations would be bad. I have been adding chapter DOIs as the DOI parameter, which ends up next to the ISBN. Should the DOI be documented as referring to the chapter, rather than the publication, where there is one? Otherwise forgetting chapter-doi and using chapter-id would avoid ambiguity. RDBrown (talk) 07:20, 12 June 2020 (UTC)
There is a related discussion here: Help_talk:Citation_Style_1#Auto-linking_for_book_chapters
--Matthiaspaul (talk) 11:35, 13 June 2020 (UTC)

Help for title linking

I initiated {{Citation Style documentation/Linking title}}, for use, for instance, in:

--Francis Schonken (talk) 16:49, 8 June 2020 (UTC)

That looks like instruction creep to me. I don't think it is really necessary. Glades12 (talk) 17:44, 8 June 2020 (UTC)
I thought links in |title= would be disallowed because they can spoil metadata, and that |title-link= is to be used instead. Otherwise, what is the purpose of |title-link=?
The documentation should not propose any linking inside of |title= at all.
--Matthiaspaul (talk) 11:02, 9 June 2020 (UTC)
Wikilinks in |title= are actually allowed according to the documentation pages, which makes |title-link= redundant. However, external links and templates seem to be disallowed. (These rules are absolutely ridiculous.) Glades12 (talk) 11:25, 9 June 2020 (UTC)
Wikilinks in |title= do not spoil metadata; they do spoil the rendering when |url= has a value:
{{cite book |title=[[Title]]}}
Title. → title metadata: &rft.btitle=Title
{{cite book |title=[[Title]] |url=//example.com}}
[[Title]]. {{cite book}}: URL–wikilink conflict (help) → title metadata: &rft.btitle=Title
—Trappist the monk (talk) 12:48, 9 June 2020 (UTC)
Thanks for the explanation. I vaguely remember seeing some code stripping off link syntax elements from titles in the sources the last time I looked, I just didn't knew how effective it was and if it has been there all the time. However, if internal links can be safely given in |title=, what is the purpose of |title-link= then? After all, internal and external links are mutually exclusive, anyway.
--Matthiaspaul (talk) 13:57, 9 June 2020 (UTC)
Apparently introduced at this version of Module:Citation, perhaps as a generic form of |episodelink=. |titlelink= is not supported by {{citation/core}}.
—Trappist the monk (talk) 14:44, 9 June 2020 (UTC)

The current format is correct imo.|title= provides the literal value. |title-link= or |url= provide links to or about the title. A wikilink is also a specially formatted url. Additionally, the parameter is consistent with similar: |author-link=, |editor-link=. For clarity, it is best to separate the literal value from links to it. Apart from the fact that it is good programming practice (different data types). 65.88.88.69 (talk) 18:23, 9 June 2020 (UTC)

Yes and no. The reason to keep different types of information separate is because this gives us the freedom to change the output format according to new requirements in the future. If, however, it is possible to reliably pry apart related types of information later on, it is not absolutely necessary to keep them separate. There are other design goals to consider as well, including the user interface, as well as the documentation and implementation. For example, since we can separate |date= into |year=, |month= and |day= it was no longer necessary to maintain separate parameters for them, thereby making it easier for users to enter dates. Similar, if we can reliably remove links from titles, we won't actually need |title-link= any more. According to some tests, the currently implemented link stripping code works with all kinds of links, including links in subtitles, piped links, links to #hash targets, even multiple links in a single title. The fact that users can use the normal wikilink syntax is also a plus. |title-link= is apparently restricted to the same characters as links in |title=, so no advantage for |title-link= here. Since bots had to cope with embedded links in titles all the time, this isn't a reason to keep |title-link=, either. However, |title-link= can be used to link to titles combined from |title= and |script-title= (similar to |author-link= for |author-last= and |author-first=). Therefore, I have meanwhile come to the conclusion that we should not fade out |title-link= (likewise for |author-link=, |editor-link=, |translator-link=, |contributor-link= and |interviewer-link=). But what about |publisher-link= and |series-link=? Will we have |script-publisher= and |script-series= in the future? (At least I had a use for |script-publisher= more than once.)
--Matthiaspaul (talk) 05:50, 15 June 2020 (UTC)
I don't think the date example is apt. Year, month and day are elements of date. Subsuming them is non-controversial. However, links to title are a separate issue altogether. They are not an element of title but a symbolic link to it. And different types of links may have different formats which may necessitate different link parameters. As noted the wikilink class consists of links that are in reality urls reformatted so that can be internally parsed by the software. I believe it is better to have 1. different parameters for linking and 2. separate parameters for separate classes of links. This for both semantic and programmatic reasons. The naming is I believe correct. All wikilink-class link parameters have "-link" as part of the name. Most non-wiki link parameters consist of the link name/identifier (url, doi, isbn etc.). 98.0.246.251 (talk) 17:27, 15 June 2020 (UTC)

"chapter"-linking added

Have now expanded with guidance for linking "chapter"; Re. "instruction creep" – incorrect: this proposal allows more options than current guidance (and would indeed replace part of the current "instruction creep" that has given some trouble lately). --Francis Schonken (talk) 15:13, 9 June 2020 (UTC)

How so? Glades12 (talk) 18:05, 9 June 2020 (UTC)
How do you mean? How so did I expand with guidance for linking chapter? (answer: so!) Or: how so this allows more options than current guidance? Or: how so current "instruction creep"? Or: how so replacing that instruction creep? Or: how so that instruction creep has given trouble lately? --Francis Schonken (talk) 05:38, 10 June 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_67&oldid=1153317544"