Help talk:Citation Style 1/Archive 67

• 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

  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: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! --
  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 {{

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

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.

b

} 21:23, 15 May 2020 (UTC)

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

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;

b

} 20:52, 15 May 2020 (UTC)

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)

There seems to be an issue with {{

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

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:

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

• Oppose –
  ISMN (identifier) showing up on mouseover is, of course, much less helpful than International Standard Music Number showing up in that case. Further Help talk:Citation Style 1/Archive 64#choosing identifier redirects seems hardly a consensus on anything: people talking about options without coming to a conclusion (and even less a formal closure). I see a few people pushing their idiosyncratic, and generally unhelpful, preferences – not generally followed by others. --Francis Schonken (talk
  ) 03:43, 3 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.

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.

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.

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
  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 (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)

@

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

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)

• Follow-up:
  RISM (identifier) has been deleted after discussion at Wikipedia:Redirects for discussion/Log/2020 May 11#RISM (identifier)
  . Next steps could be:
  1. Take
     WP:RfD
     , which now seems likely it wouldn't survive;
  2. Initiate, as suggested above, the broader RfC on all of these, while none of them ever got broad support afaics.

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

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

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

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?

b

} 01:28, 22 May 2020 (UTC)

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.

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.

Concerning [2], it's probably also a good idea to support Quarter 1/2/3/4, and Q1/2/3/4.

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: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".

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)

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]

What's the right format to use here?

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)

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
  .

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)

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

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 {{

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 "

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|

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 —

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|

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|

Talk｜Contributions

00:46, 1 June 2020 (UTC)

{{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}}

(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).

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, --

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,

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 {{

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:

• Woods, G. T. (December 1976). "Chemically, the Same or Different?". The Mathematical Gazette. 60 (414): 252–253.
  ISSN 0025-5572
  .

—[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)

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)

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|

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)

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)

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

• Help:Citation Style 1#Titles and chapters
• Template:Citation Style documentation/title

--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)