Help talk:Citation Style 1/Archive 78

This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 75

Archive 76

Archive 77

→

when |archive-url= is broken

In normal display mode (what readers see), broken archive urls are ignored except that the module emits an error message. When editors view the same article in preview mode, and when the archive url is an archive.org url, the module uses a modified form of the archive url. The purpose of that is to enable editors to see archive.org's calendar view so that they might choose the url of an appropriate snapshot to replace the malformed archive url in the template. When |archive-url= holds a malformed archive url, the live module truncates the timestamp from 14 to 6 digits and appends a splat (*). That used to work. So, I have tweaked the code so that the new preview-mode archive url uses the first six (YYYYMM) or four (YYYY) digits of the timestamp, zero-fills to 14 digits, and then appends the splat. To see this in action, you must edit this section (or page) and preview.

Cite web comparison
Wikitext	`{{cite web\|access-date=November 3, 2008\|archive-date=2017-06-14\|archive-url=https://web.archive.org/web/20170614/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html\|publisher=Intellivision Productions\|title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers\|url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html}}`
Live	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved November 3, 2008. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)
Sandbox	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved November 3, 2008. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)

In the above examples, the live version links to a "We're sorry — something's gone wrong" page while the sandbox links to the calendar view.

—Trappist the monk (talk) 19:38, 5 August 2021 (UTC)

Thanks for making this feature work again. (For those interested in the background of this feature, see: Help_talk:Citation_Style_1/Archive_13#web.archive.org/save/...)

However, the "*"-wildcard still seems to work fine with 0-, 4- and 8-digit timecodes, so the zero-filling does not appear to be necessary in all cases:

BTW, if you truncate the archive URL to |archive-url=https://web.archive.org/web/20170614 or shorter, the new implementation throws a Lua error in "Module:Citation/CS1/sandbox at line 2379: attempt to index local 'timestamp' (a nil value)."

The utility of the feature could be further improved if we would allow it to accept |archive-url=http://web.archive.org/web/ as an entry shortcut forcing it to take the URL from the |url= parameter and optionally the timestamp from the |archive-date= parameter to automatically form archive URLs like https://web.archive.org/web/*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html or https://web.archive.org/web/20170614*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html for the error message, so that editors could utilize our preview to select or create a snapshot from/at archive.org with a minimum amount of keystrokes.

--Matthiaspaul (talk) 02:55, 6 August 2021 (UTC)

Fixed the script error:

Cite web comparison
Wikitext	`{{cite web\|access-date=November 3, 2008\|archive-date=2017-06-14\|archive-url=https://web.archive.org/web/20170614\|publisher=Intellivision Productions\|title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers\|url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html}}`
Live	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved November 3, 2008. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)
Sandbox	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved November 3, 2008. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)

—Trappist the monk (talk) 11:39, 6 August 2021 (UTC)

Cite magazine – why upper case Vol.?

Why does {{Cite magazine}} emit volume in upper case: {{cite magazine|title=Some title|magazine=Some Magazine|volume=17}} -> "Some title". Some Magazine. Vol. 17. ? -- Michael Bednarek (talk) 09:23, 7 August 2021 (UTC)

Because it follows a period. Headbomb {t · c · p · b} 10:39, 7 August 2021 (UTC)

OK. Sorry if I'm a pest, but why then is page in lower case? — "Some title". Some Magazine. Vol. 17. p. 18. -- Michael Bednarek (talk) 13:36, 7 August 2021 (UTC)

I don't think you're a pest, but the odds against getting a coherent answer to that are astronomical. Headbomb is right, of course, as you are in your question. 12.182.249.131 (talk) 14:16, 7 August 2021 (UTC)

Why do I hear Tevye in my head when he says, while singing "Tradition":

"You may ask, how did this tradition start?

I'll tell you – I don't know. But it's a tradition..."

—Trappist the monk (talk) 16:10, 7 August 2021 (UTC)

display-authors bug

If you specify just one author and then invoke display-authors=1, you get an error. You need to specify an author2 to make it go away (even though author2 isn't displayed!). Urhixidur (talk) 15:19, 4 August 2021 (UTC)

You will get the same error when you have two authors and set |display-authors=2:

{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=2}}

First Author; Second Author. Title. {{cite book}}: |author= has generic name (help); Invalid |display-authors=2 (help)

It is supposed to work that way. When there are only two authors, setting |display-authors=2 becomes meaningless. When there are more than two authors and you only want to display one of their names, then |display-authors=1 will suppress display of the second author name and add et al. to the rendering:

{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=1}}

First Author; et al. Title. {{cite book}}: |author= has generic name (help)

When the template has only one of the two authors, set |display-authors=etal to indicate that the work has more authors whose names are not shown:

{{cite book |title=Title |author=First Author |display-authors=etal}}

First Author; et al. Title. {{cite book}}: |author= has generic name (help)

—Trappist the monk (talk) 15:28, 4 August 2021 (UTC)

The (help) link provides the three paths to fixing this error. Izno (talk) 16:14, 4 August 2021 (UTC)

As an aside - the Harv warning has changed to be bold from a brown-ish colour in the last couple of days - any idea what has changed? Keith D (talk) 13:00, 6 August 2021 (UTC)

There are two warnings for SFN. One set is emitted by the SFN module. Those are in red. The other set are from whichever of the three-ish scripts that detect bad SFNs. Those are the brown-ish color. While they may have changed in shade or something, the latter has always been that color. Izno (talk) 13:36, 6 August 2021 (UTC)

My script has not changed and shows the warning messages for the above citations like this:

<span class=warning style="font-size:100%">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>

Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.

But isn't class=warning going away? If it is, I should change the warning markup to:

<span style="color:#ac6600">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>

Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.

—Trappist the monk (talk) 14:12, 6 August 2021 (UTC)

You might consider emitting a class still so people can customize the color, but sure. Izno (talk) 14:55, 6 August 2021 (UTC)

I am using User:Ucucha/HarvErrors.js Keith D (talk) 19:15, 6 August 2021 (UTC)

No changes to that script since this edit in March 2021. Yesterday was WP:ITSTHURSDAY, there is some small discussion about skins at WP:VPT about monobook skin stuff; related?

—Trappist the monk (talk) 19:45, 6 August 2021 (UTC)

It could be but not clear from that what the changes would be. Looking at phab:T285991 seems to imply some changes needed in preferences, but cannot locate checkbox "Enable responsive MonoBook design". I have tried unticking "Enable responsive mode" but that makes no difference. Keith D (talk) 20:18, 6 August 2021 (UTC)

@Keith D: "Enable responsive MonoBook design" is no longer there. It was at Preferences → Appearance, between "Shared CSS/JavaScript for all wikis (more information):" and "Reading preferences". I think it was removed when "Enable responsive mode" was added a little higher up. --Redrose64 🌹 (talk) 22:41, 6 August 2021 (UTC)

Yes, these preferences were flipped; this was in either last week's tech news or the week before's. Izno (talk) 17:41, 8 August 2021 (UTC)

Markup in titles

Peeking at Category:CS1 errors: markup, I see it doesn't include fields like "title". I'm in the process of cleaning up lots of HTML entities (which shouldn't be in these fields either), and I've seen lots of instances of double single quotes (''...'') in the title field. On Wikipedia, this will make italics, but apparently italics are not allowed in COinS fields? Is this something that should be systematically fixed? -- Beland (talk) 07:48, 9 August 2021 (UTC)

If the title of an article includes a binomial name or the name of a genus then by convention this is placed in italics (using double single quotes). - Aa77zz (talk) 08:55, 9 August 2021 (UTC)

Absolutely, and anything else would be utterly wrong and strongly resisted by those who edit organism articles. Peter coxhead (talk) 09:32, 9 August 2021 (UTC)

Is this about Wikipedia article titles or the title field of a citation? If it is the latter, then it crashes into one of the CS1 non-sensical flaws, the fact that |title= may be the source (as in {{cite book}}), or a location within the source (as in {{cite journal}}). This is pertinent, because the title value is auto-formatted differently. In the case of title=source it would be in italics. Including italics markup, would cause the affected text to display in straight type. Because of the fundamental error of mis-defined and mis-applied parameters, more convoluted acrobatics have to be employed. Good luck! 65.88.88.57 (talk) 11:48, 9 August 2021 (UTC)

Italic wikimarkup is permitted where it is appropriate to use it. Bold markup is also allowed though I wonder if bold makes much sense in the context of a citation's title. This search (times out) finds some use of bold markup in |title=. We might create a maintenance category to track bold markup in |title=, |chapter= and aliases. Such categorization must be mindful of '''s (possessive form of italicized text).

—Trappist the monk (talk) 11:13, 9 August 2021 (UTC)

I thought kerning was handled in |title=. 65.88.88.57 (talk) 11:48, 9 August 2021 (UTC)

In titles that will be rendered in quotations ({{cite web}}, {{cite journal}}, etc), cs1|2 adds kerning when the title text has leading or trailing quote marks

{{cite periodical |title='leading' quote and trailing "quote" |periodical=Periodical}}

"'leading' quote and trailing "quote"". Periodical.

—Trappist the monk (talk) 12:01, 9 August 2021 (UTC)

Ok, this is the most basic case. Is there a problem with inserting a hair-space in code to account for others?

Also, I would include typographic emphasis in |title= if that is how the source is formatted, only as a help for the reader. There may be a minority of readers for whom anything but exact representation may cause confusion. However this additional emphasis should not be a requirement, just as (generally) adherence to case is not a requirement. There is already the semantic emphasis built in to the presentation of the work argument, and the occasional emphasis on |volume= (depending on day of the week, or something). This should be enough to attract readers' attention to the most important information in the citation. But there may be another minority of readers for whom any added emphasis may confuse. 65.88.88.57 (talk) 12:16, 9 August 2021 (UTC)

Triple quotation mark in such a case will cause an error anyway as it will bold the rest of the sentence, not close the italic. Izno (talk) 13:16, 9 August 2021 (UTC)

Umm, nope:

{{cite periodical |title=''Possessive italics'''s in title |periodical=Periodical}} and some trailing text

"Possessive italics's in title". Periodical. and some trailing text

—Trappist the monk (talk) 13:56, 9 August 2021 (UTC)

`{{cite web}}` template: please make the `title` parameter optional

For web sources, specifying titles often is not necessary but makes code longer and wastes editor’s time. There is no reason to make it required. Let editors decide whether the title is needed. VSL0 (talk) 03:58, 10 August 2021 (UTC)

Well it raises the question, necessary for what? What do you believe is the purpose of a citation? -- GreenC 04:06, 10 August 2021 (UTC)

@VSL0: Could you please provide some specific examples of citations where you believe specifying titles is not necessary? Thanks! GoingBatty (talk) 04:18, 10 August 2021 (UTC)

@GoingBatty: @GreenC: The {{cite web}} template is often used just for referencing (providing the source of information), not necessary for a citation. VSL0 (talk) 04:45, 10 August 2021 (UTC)

"Just for referencing" "not necessary for a citation" is a contradiction. A reference is a citation and vice versa. Headbomb {t · c · p · b} 09:22, 10 August 2021 (UTC)

@GoingBatty: @GreenC: @Headbomb: The purpose of using {{cite web}} may be just providing the link to the source with specifying its date or access-date in a standard way. In case of accessible web sources there may be no need for knowing their titles in advance (especially if they don’t represent books, articles, publications), and this is enough for making the title parameter optional. Could anyone modify the template? VSL0 (talk) 07:44, 11 August 2021 (UTC)

I know the topic is considered closed, but if you allow, I believe an observation must be made. The purpose of {{cite web}} stated above is incorrect. Like all citation templates, its purpose is to formalize a citation according to a citation system, in this case CS1/2. Citations don't exist to provide links although they should, if they can. Linking is an ancillary to discovery and wikitext verification. As far as |title="Webpage Title" is concerned, it is rather helpful to the lay reader, the same way an in-source location such as "chapter" or "page" would be in print. The related comments below are also pertinent. 65.88.88.46 (talk) 15:51, 11 August 2021 (UTC)

My opinion is that very occasionally be some merit in omitting a title – for example, not every web page has a useful title. But those are rare cases, and I wouldn't support removing title as a required parameter, for the reasons outlined at Wikipedia:Bare URLs#What is wrong with bare URLs? In the vast majority of cases editors should be adding titles to their cites. Also, as a final point, it doesn't actually break anything if you omit the title - you'll still generate a cite, and if it's really "wasting your time" to add a title, then don't do it. Per the page I linked above, "If you only have time and inclination to copy the reference URL you found, we thank you for your contribution!" But such a cite should display a red error message, simply because it's very useful for you or anyone else who comes to the page after you, to know that a title ideally should be added. — Amakuru (talk) 08:27, 11 August 2021 (UTC)

There are several reasons why this is not a good idea:

omitting the title makes the link as susceptible to linkrot as using a bare url rather than the template.
titles are an indicator to the reader as to what the linked web page is about.
if a web page is so poorly designed as to not have a title then I'd be questioning it's suitability as a reliable source. Nthep (talk) 08:30, 11 August 2021 (UTC)

@Amakuru: @Nthep: I rather agree, and the topic may be considered closed. VSL0 (talk) 11:52, 11 August 2021 (UTC)

IMO now theoretical since the discussion is closed anyway, the purpose of a citation on Wikipedia is to facilitate finding and verifying a source. The citation is a means to an end. If a title exists, it would be so significant to finding the source it would be required. If no title exists, I don't know. Would need to see examples. Often in those cases the title is descriptive eg. "Facebook post by A_User on a Topic". -- GreenC 16:46, 11 August 2021 (UTC)

Incorrect spacing

Hello, there appears to be some spacing problem in the |issue= field of {{cite news}} it appears to add a space after the comma for some reason.

{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=14,479 |date=3 September 1884 |location=Column F |page=3}}

"The new Exchange railway station at Bradford". The Leeds Mercury. No. 14, 479. Column F. 3 September 1884. p. 3.

Keith D (talk) 19:41, 16 July 2021 (UTC)

Help:Citation Style 1 § Accept-this-as-written markup

{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=((14,479)) |date=3 September 1884 |location=Column F |page=3}}

"The new Exchange railway station at Bradford". The Leeds Mercury. No. 14,479. Column F. 3 September 1884. p. 3.

—Trappist the monk (talk) 20:01, 16 July 2021 (UTC)

Thanks - I have not come across this before. Keith D (talk) 21:21, 16 July 2021 (UTC)

@Keith D Is this really worth applying to all the instances of cite news in which it occurs when the vast majority of users who add citations using cite news will be oblivious of the issue and will not be using some obscure markup when they add the citation? If effort cannot/has not been put into preventing the template behaving in this way in the first place - a never ending battle in applying a manual fix appears to be fruitless. This is bordering on Wikipedia:Cosmetic edit territory. Nthep (talk) 21:52, 17 July 2021 (UTC)

I am just trying to fix the problem, I cannot see it as cosmetic as it is changing the displayed text to remove a space inserted by the templates. Keith D (talk) 21:59, 17 July 2021 (UTC)

This is a "workaround" that is really a "make-work". When was it decided that an issue number including a comma needs a space after that comma? It certainly hasn't always behaved that way. Now my watchlist is flooding with edits like this that simply should not be necessary. --Redrose64 🌹 (talk) 22:15, 17 July 2021 (UTC)

@Redrose64 I don't think this was a deliberate introduction but reading the section Trappist linked to is some bug in CS1 templates that sometimes (always?) shows itself. If it really is a major issue then it should be fixed but @Keith D, I'm sorry the way to resolve the issue is to fix the template's behaviour, not by applying some little known manual workaround that simply masks the issue and does not fix it. Nthep (talk) 22:25, 17 July 2021 (UTC)

This is definitely not cosmetic. The in-source location (the page #) must be given exactly. The behavior you see in this case is because the module regards comma as a separator and formats the number as a sequence of pages, adding a space after the comma (as is proper in such cases). If you dislike the workaround offered, remove the comma from the page number. 64.18.9.201 (talk) 23:29, 17 July 2021 (UTC)

Keith D and myself are not talking about page numbers, we're talking about issue numbers. A physical newspaper or magazine with a particular cover date may have an issue number, or it may not; but if it has one, there won't be more than one for any given date. A daily newspaper will use approximately 313 issue numbers in one year; a monthly magazine will use twelve issue numbers in a year. --Redrose64 🌹 (talk) 08:11, 18 July 2021 (UTC)

I know of no cases where |issue=, |number= or |volume= might need to contain a list. In my experience, they're always single values, and should be treated as such. |pages= is a different matter, and we do provide it as a parameter distinct from |page= to recognise the fact that a list may often be required. --Redrose64 🌹 (talk) 09:11, 18 July 2021 (UTC)

What about multi-part articles, split between different issues etc of a work (I would normally split these out into separate references, but some people wouldn't.Nigel Ish (talk) 10:18, 18 July 2021 (UTC)

Two issues - two references. --Redrose64 🌹 (talk) 20:26, 18 July 2021 (UTC)

(edit-conflict) There isn't much the template can do about it. These parameters support comma-separated item lists, so if the comma is meant as thousands separator rather than list separator, the ((accept-as-is-syntax)) must be used to indicate this. See also:

IMO, the easiest solution is to simply not use thousands separators. They often cause confusion anyway, because the exact rules and characters used very much depend on the locale you live in (i.e. some countries start grouping at 999, others at 9999, some countries group by 3 digits others by 4 digits, some countries use commas, others use dots, apostrophes or a number of other characters). If anything, thousands separators should be generated by the template itself (using thin-spaces). Another solution would be to use wrapper templates for those rare cases, where the number exceeds 999.

--Matthiaspaul (talk) 23:43, 17 July 2021 (UTC)

Thinking about it there is one way how to possibly improve the situation slightly (at least in some cases): At present, the templates interpret both, commas and semicolons as list separators. If semicolons are used, they will be translated into commas on the fly for display and metadata purposes. It is important that we support both list separators because different users are used to different separators, however, if we assume that editors will not normally switch between these separators within a single list, we could define one additional rule: If a given list contains at least one semicolon, the comma will no longer work as a list separator but as a thousands separator. Therefore |issue=14,479,800 would be interpreted as three items "14, 479, 800" and |issue=((14,479)),800 as two items "14,479, 800", but |issue=14,479;800 would be interpreted as "14,479, 800" instead of "14, 479, 800". The scheme would only work for arguments containing lists, that is, a single item like "14,479" would still require the accept-as-is syntax |issue=((14,479)) to keep it from being interpreted as two list items "14, 479". So, effectively, this would still require the usage of a special syntax, but at least some cases might be more intuitive to write than before. Also, it is important to understand that if a scheme like this would be implemented it would work for all parameters taking argument lists for reasons of consistency.

--Matthiaspaul (talk) 08:52, 18 July 2021 (UTC) (updated 11:39, 7 August 2021 (UTC))

Help_talk:Citation_Style_1/Archive_57#pages=_parameter_when_there_are_more_than_1,000_pages_in_a_work seems to suggest that separate logic can be applied to each parameter. Apart from the multi-part article case mentioned about by Nigel Ish, I'm struggling to see any case for space after comma in the issue parameter. And even in the multi-part case I think that is misuse of the template e.g. in listing a bibliography entry rather than as a citation. Nthep (talk) 11:44, 18 July 2021 (UTC)

Citation templates are used for more then references only, so bibliography entries (i.e. in "Works" or "Further reading" sections) are perfectly within the scope of them. Personally, I have also used lists of volumes, numbers and issues in references as well.

Likewise, except for the few cases mentioned here, I never saw issues or numbers higher than 999 in real life as an editor, so they are comparibly rare as well. I guess, it either way depends on what kind of articles and sources one is working on.

It would be possible to treat lists in the various parameters differently, but it would complicate the code (and thereby make it more difficult to maintain) and we frequently receive requests to make citation templates behave more logical and consistent, so not treating list arguments the same everywhere appears to be counter-productive.

Above, I proposed three ways how to possibly make it easier to enter publications with issue numbers higher than 999: The first is to not use thousands separators in the first place - this is syntactical sugar that is basically not needed to convey the message, and they are ambiguous and inconsistent in themselves. Another solution would be to create dedicated wrapper templates for those few newspaper using higher numbers. The third one would be to no longer allow for mixed separator lists using both comma and semicolons, but to disallow commas as list separators as soon as a semicolon is used in the same list. These solutions might improve the sitation without compromising the existing general scheme.

--Matthiaspaul (talk) 12:13, 18 July 2021 (UTC)

Disagree. Citations are not biblio entries, and citation templates should not be used as bibliography templates. It is better to stop thinking that a rigidly defined set of forms can encompass even the majority of citation cases. Templates are just that, formatted applications of the most general/generic instances. These templates handle most general functions fairly well, but they have a way to go to reach the above-average mark, and the documentation is below par. This is what should be the prime objective, imo (but not under the current environment when even the provenance of tracking categories is questioned). The templates do handle a few special cases tolerably. But multipart sources are a tight-corner case that can be adequately cited with a combination of cs1 templates and {{harvs}} plus custom anchors. As stated, it is not correct to cite multiple issues, volumes, URLs, etc. in a single citation. These are discrete items and should be cited in a discrete fashion, please do not convolute them into a single bibliographic record as a pseudo-citation. After developers are given a free hand to develop as they see fit, and after the essentials are correctly applied, then perhaps exotic items such as multipart citations can be considered. 12.166.107.91 (talk) 13:05, 18 July 2021 (UTC)

Railway Magazine reached issue 1000 with cover date August 1984. Yes, I've got it - I also have a continuous run of issues 521 through to the current issue, which is no. 1,444 [sic]. If you like, I can analyse which have commas and which don't. --Redrose64 🌹 (talk) 21:17, 18 July 2021 (UTC)

I wonder if we could add some code to detect all-numerical values (optionally in ranges or lists) of more than 4 (not 3 per MOS) digits, and if they exist, to automatically add thousands-separators in form of thin-spaces to them. Numerical values combined with letters or other symbols would be left alone, because then adding thousands-separators to the numerical part might cause confusion.

Thin-space (" ") thousands-separators are one of the styles recommended by MOS:DIGITS (and ISO and {{val}}: 12 345) and they would have the advantage that they cannot be confused with decimal or list separators, no matter of locale. We would probably have to do something about line-wrapping, but otherwise I can't see any problems arising from them. Either way, if it would still be desirabe to leave the numbers alone, the automatic addition of thin-space thousands-separators could be suppressed using our ((syntax)).

For our purposes, this could help to eliminate the need or urge of some editors to provide thousands-separators in large numerical values in the first place, and thereby reduce the risk of confusion. (IMHO, providing thousands-separators of any kind is a bad practise on parameter input level - the generation of thousands-separators should be left to presentation layer only, therefore done automatically inside the template, if at all.) If there really are large all-numerical page (or volume or issue) numbers which must use a comma as thousands-separator in order to faithfully reproduce a source also using commas as thousands-separator for some reason, they could still be given using a comma, but then the user would have to use our ((syntax)) to avoid misinterpretation as list separator - just as before.

Nevertheless, this scheme would cover the majority of standard cases and leave our ((syntax)) for the special cases.

--Matthiaspaul (talk) 09:39, 29 July 2021 (UTC)

I'd be happy with no thin space or no separator in issue numbers or page numbers for that matter. Regarding line-breaks is there a thin non-breaking space? volume and issue that Nthep (talk) 14:18, 29 July 2021 (UTC)

So are we anywhere near a consensus to either:

do nothing and continue to rely on the clumsy (( )) syntax, or
do nothing and not worry about spaces after commas in the issue parameter, or
remove the issue parameter from the list of those parameters where commas are used as list separators, or
remove all thousands-separators from the issue parameter, or
replace any thousand-separators with a thin (non-breaking) space?

Nthep (talk) 19:38, 11 August 2021 (UTC)

the simplest, easiest to apply, perfectly legitimate, and correctly-weighted option is to remove thousands separator and explicitly advise editors about it. All other options have flaws. I assign this option the most significant weight because of virtual certainty that citations with issue-no>999 will be encountered several decimal points to the right of the dot. Probably at less than .001. 72.229.23.69 (talk) 21:35, 11 August 2021 (UTC)

Not when you're dealing with old newspapers that have been going since the early 19th century. Then it easy to be dealing with five figure issue numbers. I don't have a problem with omitting thousands separators but we need to be clear on the look. Nthep (talk) 11:02, 12 August 2021 (UTC)

Issue number is not necessary in newspapers. They are indexed (and commonly referred to) by issue date, not issue number. 100.2.235.66 (talk) 11:42, 12 August 2021 (UTC)

so are many periodicals but nobody is suggesting just to use issue date and not number as well if it is available. Nthep (talk) 13:34, 12 August 2021 (UTC)

Was only referring to newspaper indexing. The reasoning for choosing option 4 was given above. 64.18.9.201 (talk) 14:08, 12 August 2021 (UTC)

I would go with 3 as first choice, otherwise 1. Certainly there should be no space in the issue and those above 999 need a seperator. Keith D (talk) 23:39, 11 August 2021 (UTC)

Why do they need a separator? 38.88.211.114 (talk) 00:36, 12 August 2021 (UTC)

Current version of page no longer contains cited facts. url-status=?

It seems to me that there |url-status= needs another option, for a webpage which is live and has not been usurped, but where the current version no longer contains the cited info.

I have been archiving the refs on the article Paul Gogarty (an Irish politician), and the page http://www.paulgogarty.com/about/ was cited in 2009 as a ref for the assertion that he joined the Green Party in 1989 as a student. That current live age doesn't say that, because Gogarty left the Green party 10 years ago, and has been an independent since 2011. So his biog page now focuses more on his status as an independent.

However, the relevant facts are in an archived version of the page, from 2009: https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/

I was unsure what value to give for |url-status=. None of the options was a good fit:

|url-status=live makes the current version the primary link, which is not helpful
|url-status=usurped would be untrue, because the domain has not been usurped
|url-status=unfit initially seemed like the best option, but it does not link the original URL, which seems unhelpful
|url-status=dead isn't strictly true, because the original page is still live ... but this option does link the original URL

So in this edit[1] I used |url-status=dead as the least-worst option.

However, it would be better to have some option which more accurately describes the situation. Maybe |url-status=rewritten or |url-status=revised?

It seems to me that this situation is not uncommon, so there should be an option which supports it. --BrownHairedGirl (talk) • (contribs) 06:03, 17 June 2021 (UTC)

This is indeed a common situation, e.g. in websites of scientific organisations. A |url-status=revised (or |url-status=updated or |url-status=changed) as short for changed and no longer containing the cited information and linking to an archived version would be more informative than shoe-horning |url-status=dead. — Jts1882 | talk 07:53, 17 June 2021 (UTC)

I support the idea, but we should try and find a keyword which cannot be misunderstood. "changed", "updated", "revised" or even "rewritten" could mean all kinds of changes to the page, including those which are still supporting the statement and for which we would not want to swap the |url= and |archive-url= links. Perhaps |url-status=outdated would transport that message? --Matthiaspaul (talk) 12:08, 17 June 2021 (UTC)

Thinking about alternative keywords properly describing the situation, |url-status=outdated, |url-status=substituted, |url-status=replaced, and |url-status=archived came to my mind so far. Perhaps archived would be the most universal one as it does not make a statement in regard to the potentially changed contents of the live site and its validity, just that an archived snapshot exists (and therefore can be linked to if the editor wants to). Codewise, this would be treated as an alias to dead for now.

--Matthiaspaul (talk) 19:15, 6 July 2021 (UTC)

BrownHairedGirl's example could thus look like:

Gogarty joined the Green Party in 1989 as a student.<ref>{{cite web |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=archived |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}</ref>

"Profile of Paul Gogarty TD". Paul Gogarty's website. Archived from the original on 2015-12-29. Retrieved 2009-06-19. {{cite web}}: Invalid |url-status=archived (help)

--Matthiaspaul (talk) 15:09, 7 July 2021 (UTC)

I'm not convinced that |url-status=archived is all that meaningful. Looking at the wikitext of your example template, a generic editor might think, "of course its archived, it has |archive-url= ..." If this new keyword (presuming that we can find one), is to convey the meaning that the original url no longer supports our article's text, then that keyword should be sufficiently descriptive to convey that meaning. |url-status=archived doesn't do it for me.

As an aside, I am going to delete my |url-status=blacklisted changes because they won't work; your change will be swept away by that revert.

—Trappist the monk (talk) 17:26, 7 July 2021 (UTC)

Well, I thought that perhaps not conveying that meaning would be a good thing here, but I see the point. What about |url-status=diverging/diverged, |url-status=deviating/deviated, |url-status=differing/differed/different or |url-status=drifted?

--Matthiaspaul (talk) 17:49, 7 July 2021 (UTC)

If this really is a good idea, and I remain skeptical, |url-status=archive-verified. It's not going to be intuitive regardless, and we're probably not going to be able to find a single word to do what you want. Izno (talk) 18:15, 7 July 2021 (UTC)

I guess, |url-status=invalid would be too close to |url-status=unfit and imply either gross or corrupt contents or an error, but |url-status=invalidated would convey the message that there once actually was valid contents (as verifiable by the archived snapshot - somewhat in line with Izno's archive-verified above), that there was a change in contents, and that the current one isn't good any more, but still not dead, or unfit, or usurped... Perhaps BrownHairedGirl, Jts1882, or Amakuru have ideas for even better keywords?

--Matthiaspaul (talk) 18:51, 7 July 2021 (UTC)

Unfortunately, I have no better suggestion. I struggled to find something pithy for content changed and no longer containing the cited information and |url-status=revised/updated/changed) were the best one word options I could think of. Izno's |url-status=archive-verified conveys the right message that the content was verifiable and can still be checked in the archive. — Jts1882 | talk 09:01, 8 July 2021 (UTC)

We should try hard to find a suitable one-word keyword. I mean, live, dead, unfit and usurped also do not convey all implied meanings associated with them, but they come close enough to be memorizable.

Unfortunately, archive-verified is too long IMO, and, while true, it is also a bit too much on the policy side - I mean, we do not necessarily need to explicitly state in the keyword that the contents is verified (verifiable from the archive), because that's what WP:RS need to be in the first place. What's more important to convey is that the live contents has changed and deviates from the former contents which supported the statement.

|url-status=revised/updated/changed would be nice short keywords to reflect the change in general, but they miss a notion of the original information not being supported any more. |url-status=substituted/replaced/reworked do convey that message better, but are perhaps a bit too close to |url-status=usurped already, after all, substitution or replacement could also indicate a site holding completely new information rather than a page that is still rooted in the original one, but has changed enough (just) to no longer support the statement. IMO, |url-status=diverged or |url-status=deviated transports that message quite well. |url-status=invalidated could do it as well (and even has a notion of former validation/verifiability), but is closer to |url-status=unfit already. None of them implies the existence of an archived snapshot, but the existing keywords don't do that as well, so this is not necessarily a bad thing. If we would want to put the emphasis on the availabilty of an archive rather than the reasons for why it might be necessary to refer to it, |url-status=archived could be a suitable purely descriptive option as well. Finally, here is another one which (only indirectly) implies change and a need to recover the original information, but also has aspects of information being archived and verified: |url-status=retrievable.

--Matthiaspaul (talk) 13:22, 8 July 2021 (UTC)

Replacing "--" by "–"...

Hi, this is a followup to a recent but meanwhile archived discussion at Help talk:Citation_Style_1/Archive_75#Issue_with_{{{issue}}}, which was about converting double-hyphens and triple-hyphens in page ranges to en dashes and em dashes.

I originally implemented that on 2020-11-17 based on some suggestion that double-hyphens could occur in BibTeX entries and thereby could end up here as well occasionally. Unfortunately, I introduced a bug into the code trashing stripmarkers ("never do any last-minute changes after having already tested the code..." ;-) and because I could not locate the original discussion any more, it was removed rather than fixed. Well, I still haven't found the original discussion, so it probably wasn't here, but I just ran into a site (by renowned Nelson H. F. Beebe) excessively using double-hyphens in (hundreds of) BibTeX citations, so I thought I would drop a link here just for reference:

http://ftp.math.utah.edu/pub/tex/bib/bstj1930.html

Since we are doing all kinds of plausibility checks and also some on-the-fly conversions (including with pages and page ranges), I still think we should cover this case. After all, a double-hyphen in a page range can never be part of the page designation itself and the only reasonable interpretation is as an endash in a page range. The alternative to just silently converting them to improve our display and make our metadata output more consistent would be to throw a maintenance message, but this would require more code. --Matthiaspaul (talk) 12:46, 17 June 2021 (UTC)

Searches:

-- 25 (times out)

--- none

—Trappist the monk (talk) 12:59, 17 June 2021 (UTC)

Not sure why you escaped the dashes, but I can get to 36 with timeout.

I do not see a need for this change. There are sufficiently few and clearly not many being introduced that the interested user can just work from a search. Izno (talk) 13:51, 17 June 2021 (UTC)

In fact, I can refine this to

Still don't think we need it. Izno (talk) 14:23, 17 June 2021 (UTC)

I, on the contrary, don't see how it could cause any harm. It would improve consistency in how citations are displayed and metadata is generated. Using two consecutive hyphens for an endash was a common notation in pre-Unicode times and many people are still accustomed to it. While we support Unicode and therefore do not technically need this any more, in general it is still a good idea to maintain compatibility with ASCII conventions for as long as they don't step in the way of more modern conventions. En dashes are still difficult to type in many keyboard layouts and visually almost impossible to distingish from a hyphen in many fonts. So, while they are technically the correct thing to use, they are not convenient to use. Why not let the templates do the translation for the editors' convenience? After all, we already translate a variety of other special character "transliterations" on the fly, so this would not be anything new. Alternatively we could have someone looking for these strings every once in a while and fix them in citations, but this is a never-ending endeavour, and we would continue to generate strange looking citations and metadata until fixed.

Alternatively, we could detect the pattern and issue an error message in order to force editors to use en dashes. However, this would require more code than to just translate this on the fly, so if code complexity would be the issue, an on-the-fly translation would be the preferable solution. --Matthiaspaul (talk) 14:41, 19 July 2021 (UTC)

MOS:DASH asks us to avoid double and triple dashes. MOS is generally about the visible output, not necessarily about parameter input on source code level, but what we can draw from this is that we should not have "--" or "---" showing up in rendered citations and metadata (well, unless the metadata standard would require en/em dashes to be transliterated this way, which COinS, however, does not). So, we should either accept them on source code level and convert them on the fly for proper output as "–" or "—", or, since they can never be a valid part of a single page designation, we should check for this condition (similar to our various extra text checks) and emit an error message. I still prefer the former alternative because it is easier to implement and in some cases might even become useful when people want to enter an en dash in an environment not supporting direct entry of the glyph, but I would also support the latter alternative.

--Matthiaspaul (talk) 10:42, 13 August 2021 (UTC)

Location within large tree-structured documents with no page numbers

I often need to cite material from a tree-structured document with no page numbers. Typically there is a sidebar for navigation. If section foo.bar.baz has a stable URL then I can use |section-url=, but often there is none. Ideally I would like to mark it up with something like

{{cite document
 |     title =  Manual with nested sections and no page numbers
 | section-1 =  foo
 | section-2 =  bar
 | section-3 =  baz
 }}

However, nothing like |section-n= is implemented. |section=foo: bar: baz and |section=foo - bar - baz look clunky. What is the best way to mark up such citations? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 11 August 2021 (UTC)

This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time. Along with your |section1=, |section2=, |section3= your next request will be for |section-url1=, |section-url2=, |section-url3=, etc. And, how would that render? cs1|2 citations are complex enough, I don't think that we should be making them more complex by attempting to cite multiple sources with a single template. As an aside, this is why I want to do away with |lay-url= and its companions.

Still, perhaps something like what you want is already available and linking is possible but ugly, very ugly:

{{cite manual |title=Manual with nested sections and no page numbers |at=§foo, §bar, §[//example.com baz]}}

Manual with nested sections and no page numbers. §foo, §bar, §baz.

And don't use {{cite document}} to cite a manual. {{cite document}} is a redirect to {{cite journal}}. Why? Don't know; it really ought not to redirect there... {{cite manual}} as I used here is a redirect to {{cite book}}.

—Trappist the monk (talk) 17:14, 11 August 2021 (UTC)

I don't know why you wrote This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time., since the first three sentences clearly are describing a single source that is at a third level branch of the navigation sidebar. That is, on the navigation bar of the web page, you have something like

Extraneous content entries
Content entry for section foo
- Extraneous content entries
- Content entry for subsection bar of section foo
  - Extraneous content entries
  - Content entry for subsubsection baz of subsection bar of foo

where the intended citation is for only for subsubsection baz of subsection bar of foo, not for the enclosing foo or bar. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:28, 12 August 2021 (UTC)

I know what you wrote, but to me, your example template skeleton seems to contradict your initial statement; mostly because you did not describe how such an assemblage of parameters is to be rendered. That is why I wrote what I wrote. If you are citing section 'baz', then the title of section baz should be all that you need.

Even were we to create enumerated |section<n>= parameters, you still have some sort of clunky rendering if you want all of those hierarchical names in the rendered citation:

"Content entry for section foo > Content entry for subsection bar of section foo > Content entry for subsubsection baz of subsection bar of foo". Manual Title.

Isn't |section=Content entry for subsubsection baz of subsection bar of foo sufficient?

—Trappist the monk (talk) 12:04, 12 August 2021 (UTC)

I didn't mention rendering because I'm more concerned with semantics than layout. If someone implements |level-n-section= then I could live with whatever rendering they chose. I'd probably prefer "level-1 > level-2 > level-3", but that's a nit.

The name of the lowest level branch is definitely not all I need, since it doesn't tell the reader how to navigate to that. |section=Content entry for subsubsection baz of subsection bar of foo is sufficient. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:10, 13 August 2021 (UTC)

Identificativo SBN

Is there a way to put an Identificativo SBN (Italian identifier) in Cite book and similar templates?--Carnby (talk) 08:10, 12 August 2021 (UTC)

@Carnby: The cheap and nasty workaround is to use others=SBN 123456. Otherwise you have to request an addition to the template: I have no idea how you would do that. --John Maynard Friedman (talk) 09:53, 12 August 2021 (UTC)

@John Maynard Friedman: |others= is for 'other' contributors; not for miscellaneous identifiers.

Carnby: use |id=Identificativo SBN: <identifier number>

—Trappist the monk (talk) 11:39, 12 August 2021 (UTC)

We have a dedicated template for this, so ideally you would use |id={{ICCU|number}}. (It is not named {{SBN}} because of the name conflict with the ISBN predecessor.)

--Matthiaspaul (talk) 10:57, 13 August 2021 (UTC)

Thank you very much, I didn't find that! Is it possible to add it as a normal identifier i.e. |iccu=? Thanks in advance.--Carnby (talk) 05:42, 14 August 2021 (UTC)

How to extlink the components of a multi-component publication

This citation:

{{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = 386–392, 521–525, 1397–1412 | title = A rank-invariant method of linear and polynomial regression analysis. [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf I], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf II], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf III] | volume = 53 | year = 1950}}
Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis. I, II, III", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412 {{citation}}: External link in |title= (help)

is throwing a CS1 error "External link in |title= (help)". But obviously it wouldn't work to use |title-link= (the only suggestion at the help link) because the three components of this multi-component work need to be linked separately. Can anyone suggest a way to make this citation work without errors and without splitting it into three separate citations? All I would really want is to disable the CS1 error message, because except for that message the citation template appears to format the citation adequately. —David Eppstein (talk) 17:14, 13 July 2021 (UTC)

You can link the page numbers:

{{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf 386–392], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf 521–525], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf 1397–1412] | title = A rank-invariant method of linear and polynomial regression analysis | volume = 53 | year = 1950}}
Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412

—Trappist the monk (talk) 17:48, 13 July 2021 (UTC)

This might be a good solution in the current implementation as we strip off the link before generating the metadata for |pages= and friends. It might be a good idea to consider to do the same for |volume=, |number= and |issue= as well in order to better support various kinds of multi-partite publications (currently we don't, so adding the links to those parameters would, while still looking nice, mess up the metadata).

In this specific case the perfect solution would be to add support for a dedicated |part= parameter. Even COinS has a special attribute for this (rft.part, which we do not use at present), indicating that this is really something we are lacking support for in our current implementation. As far I see it, parts are typically displayed following the title, but before volumes.

--Matthiaspaul (talk) 18:38, 13 July 2021 (UTC)

Thanks for the suggestions. I think support for parts would be a good idea, but I think for now I'll follow trappist's suggestion of putting the links on the pages. —David Eppstein (talk) 21:01, 13 July 2021 (UTC)

The simplest solution may be implementing |page-linkn=, this assumes the editor should match the link number to the page sequence in |pages=. 66.108.237.246 (talk) 13:33, 14 July 2021 (UTC)

There is no need for separate |page-linkn= parameters. |pages= and friends already support page ranges, page lists as well as external links without messing up the metadata. (|volume=, |number= and |issue= don't support external links at present, though.) Hence, there is no need for a separate |page-linkn= parameter to provide links. Associating the nth-link with a particular list item would considerably complicate the code. --Matthiaspaul (talk) 20:41, 14 July 2021 (UTC)

There is a need for link parameters only when the module is designed logically. An entity and a link to the entity are not the same thing and should be represented separately, not with the same parameter. This is flexible and understandable by editors. On a lower level, data types should correspond to unique parameters. You shouldn't have the same field accepting images and free-form text for example, or URLs and plain text as another example. But as stated, this presumes a logical module design. So this is probably off-topic. 65.88.88.126 (talk) 20:57, 14 July 2021 (UTC)

During the great hyphen war many [enough] users didn't care about logical design vs. ease of use. -- GreenC 16:15, 15 July 2021 (UTC)

Another assessment would be that entrenched ways are largely immune to logic, especially when work is required to arrive at a rational state. Also, zealotry to do something is just as bad as inertia, as the tracking-category-deletion phase of the hyphen wars shows. 65.88.88.57 (talk) 17:45, 15 July 2021 (UTC)

--Matthiaspaul (talk) 13:42, 21 July 2021 (UTC)

Another related discussion: Help_talk:Citation_Style_1#Multiple_URLs_(split_file)

--Matthiaspaul (talk) 03:49, 17 August 2021 (UTC)

bad DOI check

The following throws an error, but it's resolving correctly

O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.

Headbomb {t · c · p · b} 09:27, 17 August 2021 (UTC)

Given that we support both U+0027 and U+02BC, it seems we should support U+2019 as well (although I hate it).

--Matthiaspaul (talk) 10:38, 17 August 2021 (UTC)

Don't edit other editors' posts. I have restored the U+2019 character.

—Trappist the monk (talk) 11:51, 17 August 2021 (UTC)

Sorry, that was completely unintentional - AGF, it should have been obvious that this was just a mistake. I used the preview to experiment with different characters inserted into the citation, got distracted with something else, and simply overlooked the changed character when I wrote my comment later on...

--Matthiaspaul (talk) 12:51, 17 August 2021 (UTC)

Fixed in the sandbox.

Cite journal comparison
Wikitext	`{{cite journal\|date=2016\|doi=10.1922/CDH_3707O’Mullane31\|issue=33\|journal=Community Dental Health\|pages=69–99\|title=Fluoride and Oral Health\|vauthors=O'Mullane DM}}`
Live	O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.
Sandbox	O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.

—Trappist the monk (talk) 11:51, 17 August 2021 (UTC)

There are probably other string functions we should be using mw.ustring for instead. You might consider having a general look. Izno (talk) 16:38, 17 August 2021 (UTC)

Date quarters

Some publications give a date as year and quarter, but, e.g., |date=3Q 1984, yields an error message:

"foo" (Document). 3Q 1984. {{cite document}}: Check date values in: |date= (help); Cite document requires |publisher= (help)

Is there a legitimate way to enter a quarter in |date=? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 16 August 2021 (UTC)

{{cite journal |title=foo |journal=Journal |date=Third Quarter 1984}}

"foo". Journal. Third Quarter 1984.

—Trappist the monk (talk) 15:29, 16 August 2021 (UTC)

But be prepared for a strange result when the author name is provided

Doe, John (Third Quarter 1984). "The unbearable brightness of fooing". Journal of Forensic Fooology.

which is far from ideal. Would Chatul be better advised to use issue= rather than (or even as well as) date= ?

{{cite journal |title= The unbearable brightness of fooing |journal=Journal of Forensic Fooology |date=1984 |issue=Third Quarter 1984 |first=John |last=Doe}}

which yields

Doe, John (1984). "The unbearable brightness of fooing". Journal of Forensic Fooology (Third Quarter 1984).

which I suspect is what Chatul might prefer (and be more convenient to use with {{harv}} or {{sfn}}. --John Maynard Friedman (talk) 16:48, 16 August 2021 (UTC)

No. The date parameter was specifically changed in the past year or so to accept quarterly dates. Your opinion on the appearance is, uh, noted elsewhere. Izno (talk) 18:34, 16 August 2021 (UTC)

@Izno: It is not just my opinion. I don't have access to Cite them right, but this document from Library Services at London Metropolitan University says that it is based on Pears, R; Shields, G (2013). Cite them right: the essential referencing guide (9th ed.). Basingstoke: Palgrave Macmillan.:

Some journals use the month or season of publication, or just a number instead of the volume and issue numbers. Enter these details after the journal title in your reference list.

(my emphasis).^[1] I have never, ever, seen a citation that looks like Izno (Spring-Summer 1821); every case I have found is simply Izno (1821). Maybe you have access and there is a case in point? I am very happy to be put right if I am mistaken. --John Maynard Friedman (talk) 15:07, 18 August 2021 (UTC)

cs1|2 is not beholden to Cite them right: the essential referencing guide or to Chicago Manual of Style or to any other style guide. In cs1|2 'style', when an author list is present, the publication date (|date= or |year=) is rendered after the author list. It has been thus since forever. Editors at en.wiki commonly provide seasonal dates:

Spring: ~8600 hits (search times out)

Summer: ~7400 hits (search times out)

Winter: ~5000 hits (search times out)

Fall: ~6300 hits (search times out)

Autumn: ~3700 (search times out)

and they even provide seasonal ranges:

Spring–Summer: ~700 hits

Summer–Fall: ~150 hits

Summer–Autumn: ~60 hits

Fall–Winter: ~280 hits

Autumn–Winter: ~100 hits

Winter–Spring: ~230 hits

there are other combinations that I leave to the reader.

—Trappist the monk (talk) 15:45, 18 August 2021 (UTC)

And anyway, sfn/harv will still be put in as the year. Izno (talk) 18:38, 16 August 2021 (UTC)

Where is |date=ordinal quarter year documented? Shouldn't it be included in the table of examples? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:56, 17 August 2021 (UTC)

They are documented at Help:Citation_Style_1#Dates. I have added them to the error help as well. --Matthiaspaul (talk) 17:42, 17 August 2021 (UTC)

I've added examples at Wikipedia:Manual of Style/Dates and numbers#Formats; do they look okay? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:30, 18 August 2021 (UTC)

I'm not convinced that the new examples belong in those two tables. MOS:DATES and those two tables were written to govern dates in article prose. cs1|2 has adopted MOS:DATES as the standard that governs date formats in the templates but cs1|2 does not have any authority to write the rules for article prose. Quarterly dates in article prose are not obliged to adhere to cs1|2 format rules. I think that the examples should be removed until there is a consensus at MOS:DATES to require a particular quarterly date format in article prose.

—Trappist the monk (talk) 12:59, 18 August 2021 (UTC)

References

^ Library Services (February 2016). "Harvard Referencing Guide" (PDF). London Metropolitan University. Retrieved 18 August 2021. (Section: Journal articles – print and electronic)

Push PMID limit up

Donders, T.; Panagiotopoulos, K.; Koutsodendris, A.; Bertini, A.; Mercuri, A. M.; Masi, A.; Combourieu-Nebout, N.; Joannin, S.; Kouli, K.; Kousis, I.; Peyron, O.; Torri, P.; Florenzano, A.; Francke, A.; Wagner, B.; Sadori, L. (2021). "1.36 million years of Mediterranean forest refugium dynamics in response to glacial–interglacial cycle strength". Proceedings of the National Academy of Sciences of the United States of America. 118 (34): e2026111118. doi:10.1073/pnas.2026111118. PMID 34400496.

This should not throw an error. Headbomb {t · c · p · b} 03:52, 18 August 2021 (UTC)

Seems fixed now... thanks to whoever did it. Headbomb {t · c · p · b} 15:55, 18 August 2021 (UTC)

Multiple URLs (split file)

We have this ref at United Airlines Flight 175

Federal Bureau of Investigation (February 4, 2008). "Hijackers' Timeline" (PDF). NEFA Foundation. Archived from the original (PDF) on October 12, 2008. Retrieved October 6, 2008.

It's cited to a page on "NEFA Foundation", which isn't exactly reliable, but the report is the FBI's. The same report can be found on their website, but split into two portions (part-01-of-02, part-02-of-02) (perhaps for file size reasons). FBI site: [2][3]. How can we use the URLs from fbi.gov directly, but only using one cite tag? ProcrastinatingReader (talk) 13:54, 15 August 2021 (UTC)

cs1|2 templates are designed to cite one source at a time. In United Airlines Flight 175, pages 218, 261, and 288 are the only pages cited in that report so the FBI part 2 source is all that is needed:

{{cite web |url=https://vault.fbi.gov/9-11%20Commission%20Report/9-11-chronology-part-02-of-02/ |title=Hijackers' Timeline (Redacted) (part 2 of 2) |website=Federal Bureau of Investigation |date=November 14, 2003 |access-date= |ref={{sfnref|''Federal Bureau of Investigation''|2003}}}}

"Hijackers' Timeline (Redacted) (part 2 of 2)". Federal Bureau of Investigation. November 14, 2003.

You could include a link to part 1 of 2 under §Further reading if it is important.

—Trappist the monk (talk) 14:55, 15 August 2021 (UTC)

If I run into this situation, I typically append such extra links as raw URLs in square brackets (without title) to the end of the citation, that is, between the template's closing }} brackets and Mediawiki's closing </ref> tag: [4][5]

Most often, such extra links are only meant to help prevent future link rot, so I want them to be rendered as short and unobtrusive as possible and deliberately don't add titles so that they don't consume much extra space in the reference. Since they are outside of the template's special handling for archived links, I typically choose archived links for them if available.

If the source is available only in form of individual PDFs on a per-page basis, the links are probably better worked into the |pages= parameter instead.

When the source is splitted over several multi-page-files (as in your example) and the reference is citing multiple pages distributed over several files, splitting the reference into multiple citations (as indirectly suggested by Trappist above) is certainly an option, but in most cases I find references to the same source (but page numbers) in multiple citations are adding too much redundancy and I therefore try to combine them into a single reference including such appended raw links.

Not ideal, but there isn't much the templates could do to improve this situation because there is only one title. The only thing that could be improved by having multiple numbered |urln= parameters would be that the extra links could be displayed immediately following the title instead of at the end of the main citation, like:

Hijackers' Timeline (Redacted)I II

But still, display of dates and handling of archive links would only work for the main link, and metadata creation would be more complicated. Not sure if this would be worth it.

--Matthiaspaul (talk) 21:43, 15 August 2021 (UTC)

Abusing the |type= parameter (which does not become part of the COinS metadata) could be used to produce a more reasonable rendering of multiple links - without solving the underlying problems with handling multiple dates and archive links, of course. However, while the current live version of the template does not produce any error message, the sandboxed version will throw an "External link in |type=" error (per Help_talk:Citation_Style_1/Archive_77#url_in_name_parameters). For illustration purposes only:

Federal Bureau of Investigation (2008-02-04). "Hijackers' Timeline" (PDF) (I II). NEFA Foundation. Archived from the original (PDF) on 2008-10-12. Retrieved 2008-10-06. {{cite web}}: External link in |type= (help)

So, if we would want to add some limited support for multiple links, it could be implemented similar to |type=. Perhaps this could be combined with the rendering of what an already proposed |part= parameter would produce (if we would allow external links there).

--Matthiaspaul (talk) 03:48, 17 August 2021 (UTC)

Support for slash in some date ranges?

Inspired by the discussion at Help_talk:Citation_Style_1#Undesirable_behaviour_of_issue=_in_cite_magazine_when_the_issue_is_a_month_or_months, I wonder if we should add support for two more date range formats allowed by our MOS, but not supported by CS1/CS2 at present:

Ranges with consecutive month names or years separated by "/" instead of "–". At present, they have to be "converted" into en-dash ranges:

"November/December 2020" → "November–December 2020"
"2020/2021" → "2020–2021"

For as long as only (non-digit) month names and/or 4-digit years are involved they appear to be free from any possible ambiguities.

The reason why it might be good to support them in citations is that, in the context of publications, if date ranges are used at all, they most often involve consecutive (weeks,) months or years, and if they are printed on a publications' cover, most often slashes are used rather than en-dashes, so a slash would look more "natural" in a citation when citing from, i.e., a bimonthly publication. It may also make entry of those ranges easier.

--Matthiaspaul (talk) 17:32, 17 August 2021 (UTC)

Your first step would be to change MOS:DATERANGE. – Jonesey95 (talk) 20:34, 17 August 2021 (UTC)

For the purposes of determining if adding support for this would be found useful, please assume MOS support to be a given.

Actually, the slash is one of the explictly allowed formats already for year ranges with consecutive years, so no changes to the MOS would be required:

"The slash notation (2005/2006) may be used to signify a fiscal year or other special period, if that convention is used in reliable sources"

"fiscal year or other special period in reliable sources" is exactly where we would use this in citations, that is, when the source uses this format as well (else we have little need to use it).

And somewhat further down:

"An overnight period may be expressed using a slash between two contiguous dates: the night raids of 30/31 May 1942 or raids of 31 May / 1 June 1942."

By extension and because it is not mentioned as disallowed, this would apply to consecutive months as well.

I have never seen consecutive days being used in publication dates, but consecutive months separated by a slash are quite common in bimonthly publications and special issues. I have very rarely seen endashes being used there, hence this proposal.

--Matthiaspaul (talk) 21:51, 17 August 2021 (UTC)

a given No, that's a waste of our time to entertain the idea. Please get support there first. Izno (talk) 21:53, 17 August 2021 (UTC)

Reliable sources, for the purposes of citations, are either our MOS directly or other style/citation guides, not reliable sources for a specific domain as with TNYT or a specific journal source.

Regarding slash between contiguous dates, that has a key word: "overnight". The examples are clearly not relevant. Izno (talk) 21:56, 17 August 2021 (UTC)

I recommend that the OP dig through the MOS talk page archives to find the origin of the support for the slash notation, which clearly means "one part of one period, connected to a contiguous part of a subsequent period", like July 2005 through June 2006 for a fiscal year, or 9 pm on 30 May through 5 am on 31 May for a "night of". The slash notation is clearly not applicable to a range covering two full time periods, like November–December, which is what the date of a periodical intends. To say it another way, you could have "the nights of 29/30 May and 30/31 May" as acceptable usage, but not "the magazine issues for October/November 2005 and November/December 2005". – Jonesey95 (talk) 00:51, 18 August 2021 (UTC)

Jonesey, thanks for taking up this discussion constructively. You are bringing up an interesting aspect.

I can't see these implied differences being made in the relevant MOS text, but from my personal experience I agree that the slash notation has multiple implied meanings whereas the en-dash notation almost always means a complete period.

However, if these differences are real, it would be even less desirable to blindly convert "2020/2021" or "November/December 2020" found in a source into "2020–2021" or "November–December 2020" in a citation (as we currently have to do because CS1/CS2 does not support the slash notation). Depending on circumstances it could change the meaning considerably and thereby invalidate the citation. If we do not know exactly what it means in a particular context, it is best to just use what is used in the source, similar to keeping a "Christmas 2020" date designation "as is" in a citation instead of trying to convert this into a specific date - because even in the Western world it could refer to the 2020-12-23, 2020-12-24, 2020-12-25 or 2020-12-26 or various combinations thereof (and in most cases the actual publication date would be several days earlier, anyway).

--Matthiaspaul (talk) 02:29, 18 August 2021 (UTC)

I, too, often find the date and issue CS1 rules too restrictive. If we remember that the whole purpose of bibliographical references is to provide the most complete and unambiguous link to the source, then if the source says "July/August 2021 issue", that is exacly how you would find it on the shelf in your library. In this case, July/August means "July and August" issue, so it is not a MOS:DATERANGE thing (July to August issue does not sound right, right?). Example here (title:&, text: /, and). In the past, a slash was used instead of today's comma, meaning "and" or "or". What gives us right to say Vanity Fair, Vogue, Elle, The Architectural Review, Dwell, Smithsonian Magazine, Men's Health, BA, The Atlantic (…) are all wrong and should be corrected to use an en-dash instead of their forward slashes? Ponor (talk) 02:56, 18 August 2021 (UTC)

Citations are not bibliographic references. Also, any contiguous dates/date elements taken together constitute a time interval (range) irrespective of their separator. "July and August" is a range. The norm in CS1 has been to follow Wikipedia's MOS when possible, including the presentation of date ranges, although there are significant exceptions. But the date field in any citation system does not have to be presented verbatim. As long as the correct data is input in some form the work will be found by date, Date indices do not index text strings, but date data formatted according to masks/templates that may include ranges and the like. You would be just as likely to find a "July/August" item as a "July–August" item. The significant info, which indices understand, is "July" (in proximity, {AND/OR}) to "August". The separator used in the literal expression is a matter of presentation. 24.103.251.114 (talk) 12:16, 18 August 2021 (UTC)

The bigger question is why do people expect that the templated CS1 solutions will apply to every case they can think of, and generally solve all problems. Where does this expectation come from? It is not as if these templates are obligatory. Development-wise such minor issues of presentation like the object of this thread are very much secondary. There are far more substantial development issues that may be tackled. Although, if I was a developer here I wouldn't lift a finger to cross a t. In this environment developers are expected to justify use of tracking elements. Any serious programmer would laugh you out of the room :) 24.103.251.114 (talk) 12:30, 18 August 2021 (UTC)

I don't know what citations and bibliographical references are to you, we're discussing the latter. Those who (actually) write Wikipedia articles will find sources that have "July/August 2021" as their publication date, and will (not knowing the ""correct"" way) try to use them verbatim:

"Laughter". Journal of Serious Programmers. July/August 2021. {{cite journal}}: Check date values in: |date= (help).

See what happens here, see all the redness? It says it's wrong, even though it's not. This is a citation template (producing a bibl. reference) being smarter than the editor in a pretty common use case. That's not nice, just as it's not nice to be laughed at by a bunch of serious programmers... but I see that as their problem, not mine. Ponor (talk) 13:22, 18 August 2021 (UTC)

CS1 is its own style regarding dates which comes out of WP:MOSDATE. I do not see anyone laughing at you. We have instead pointed you to the correct location if you should want to change that style. Izno (talk) 14:40, 18 August 2021 (UTC)

The documentation, with all its problems, nevertheless clearly lays out what is right and wrong in the context of the non-obligatory CS1 templates. If you wish to use these templates, follow the guidelines. A bibliographical reference is information about a certain work. It usually includes a wealth of detail (depending on the bibliographic database) about the provenance, publishing history, editions etc. of the work. A citation in Wikipedia is information about quickly and easily locating a source in order to verify claims in wikitext. It is a different kind of animal. Those people who write articles in Wikipedia without reading the pertinent documentation will see all kinds of red messages. As for this minor issue, first clear it at MOS:DATERANGE. Don't "interpret" what is being stated regarding slashes and ranges, get an explicit answer. Then we can further discuss it here. I will add to Izno's comment: nobody is laughing at you, and the comment was referring to something else. It's not about you. 65.88.88.126 (talk) 15:45, 18 August 2021 (UTC)

So according to you, 24.103.251.114 or 65.88.88.126 or ???, nothing should ever be discussed on this page because CS1 templates are non-obligatory. Use them as they are or leave? What a bureaucratic argument, I'd never expect that from an Wikipedian. I think you're confusing bibliographical references with Bibliographic records (note wikilinks). Also, a Citation is only a little (inline) pointer to the full reference, even Wikipedia can teach us that. My argument is that WP:MOS should not apply to bibliographic data, because those data are used to locate sources. You wouldn't correct this title "Everything You Need to Know About the July/August Issue of ‘Men’s Fitness,’ Starring M…." would you? So why enforce July–August when that's not what you'd find in your library? Minor or not, it's an issue. Discussing it is non-obligatory. But whoever wants to discuss it, and has time to discuss it, and doesn't feel it's waste of her time to discuss it, should discuss it with arguments other than "waste of our time", "go change WP:MOS first"... That's not how Consensus is built. I'm sorry, but no one has answered any of Matthiaspaul's or my concerns yet. Ponor (talk) 02:31, 20 August 2021 (UTC)

I believe you misunderstand everything stated in the previous post, and that's fine. What is not fine is that you presume to know the motivation and thinking of others and then proceed on that presumption to make judgements and accusations out of thin air. That, coupled with putting your words on somebody else's mouth. A point-by-point rebuttal could be made, but what for? 64.18.10.208 (talk) 04:11, 20 August 2021 (UTC)

non-English translator templates and substing

I have hacked an experiment to make {{literatur/sandbox}} invoke a lua module. That is discussed at Template talk:Literatur § lua module experiment.

Because that template is supposed to be subst'd when used, for the experimental module to work with the live Module:Citation/CS1, it will be necessary to change {{citation}} as I did to {{citation/new}} with this edit. Without that change, the subst returns the content of the citation template:

{{#invoke:citation/CS1/sandbox|citation
|CitationClass=citation
}}

and that is a pretty much pointless {{citation}}: Empty citation (help).

If the {{literatur/sandbox}} experiment is successful, then it makes some sense to do the same thing for other translation templates:

{{Cita news}} – requires the subst fix for {{cite news}} and {{cite book}}

{{Cita libro}} – requires the subst fix for {{cite book}}

{{Cite web/German}} – these require the subst fix for {{cite web}}

{{Cite web/Finnish}}

{{Cite web/Swedish}}

{{Cite web/Portuguese}}

{{Cite web/Danish}}

{{Cite web/French}}

{{Cite web/Polish}}

no doubt there are other translation templates (some of this list I found in Category:Infobox importer templates – why there?) You might think that there is a subcategory in Category:Citation Style 1 templates for translation templates ... There isn't.

So, I propose to modify {{citation}}, {{cite book}}, {{cite news}}, and {{cite web}} so that translation templates can be subst'd.

Opinions? Objections?

—Trappist the monk (talk) 20:03, 19 August 2021 (UTC)

Please test the change on one or another of the larger articles in existence (we really should have a list of go-tos) to establish that parser/expansion times are not problematically increased. Izno (talk) 14:57, 20 August 2021 (UTC)

Alas, that will be a problem. I don't know where one might find a large article with only {{citation}} templates so I created a test page (not saved) that had 1000 of this (grabbed from Module:Citation/CS1/testcases):

{{citation| url=http://books.google.ca/books?id=WrkzPcxBnLMC |title=Takhta untuk Rakyat: Celah-celah Kehidupan Sultan Hamengku Buwono IX |trans-title=Serving the People: The Life Story of Sultan Hamengku Buwono IX |language=Indonesian |isbn=978-979-22-6767-9 |editor1-first=Mohamad |editor1-last=Roem |editor1-link=Mohamad Roem |editor2-first=Mochtar |editor2-last=Lubis |editor2-link=Mochtar Lubis |editor3-first=Kustiniyati |editor3-last=Mochtar |editor4-first=Maimoen |editor4-last=S. |last=Nasution |first=A. H. |author-link=Abdul Haris Nasution |publisher=Gramedia Pustaka Utama |location=Jakarta |year=2011 |origyear=1982 |edition=Revised}}

Previewing that page rendered 930 templates before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:

CPU time usage: 8.633 seconds

Real time usage: 8.611 seconds

Lua time usage: 6.165/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 6926.279 1 -total

98.66% 6833.462 1000 Template:Citation

Then I changed the 1000 {{citation}} templates to {{citation/new}}. Previewing the page again, only 604 template rendered before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:

CPU time usage: 13.342 seconds

Real time usage: 13.380 seconds

Lua time usage: 10.026/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 11348.237 1 -total

98.16% 11139.520 1000 Template:Citation/new

I tried an experiment where I used {{ifsubst}} to choose between the subst'd form of the #invoke and the un-subst'd form

CPU time usage: 12.853 seconds

Real time usage: 12.828 seconds

Lua time usage: 9.639/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 11316.758 1 -total

98.57% 11154.984 1000 Template:Citation/new

94.54% 10698.378 1000 Template:Ifsubst

I have removed the experiment so timing for {{citation/new}} is:

CPU time usage: 9.469 seconds

Real time usage: 9.441 seconds

Lua time usage: 6.951/10.000 seconds

and Transclusion expansion time report (%,ms,calls,template)

100.00% 7732.135 1 -total

98.69% 7630.937 1000 Template:Citation/new

So, I guess that we can say that for now, any module-based translation templates must not be subst'd.

I wonder if it's possible to have a {{citation/subst}} template that the translation template could call. The inside of that template would have the substable version of the Module:Citation/CS1 #invoke so when subst'd, would return a normal {{citation}} template except with the {{citation/subst}} name. If subst'd we might include a maint cat so that {{citation/subst}} might be manually tweaked back to {{citation}}. Perhaps a tweak to Module:Unsubst to add an expicit template-name override parameter to that would be in order... I'll ponder these ideas. For now, the subst experiment at {{citation/new}} has been reverted.

—Trappist the monk (talk) 17:14, 20 August 2021 (UTC)

Created {{citation/subst}} which can be called by the translator module. Without modification to Module:Unsubst, the resulting substitution of a {{Literatur/sandbox}} template is a {{citation/subst}} template. I have tweaked Module:Unsubst/sandbox so that {{citation/subst}} can supply an alternate name (in the current case, |$template-name=citation). When substing a {{Literatur/sandbox}} template using the Unsubst sandbox, the resulting substitution is a {{citation}} template. This, I think, solves the problem because {{citation/subst}} is only called by translation templates that need substing and then once subst'd, the template is a normal cs1|2 template.

Discussion about the change to Module:Unsubst is at Module talk:Unsubst § template invocation name override.

—Trappist the monk (talk) 18:30, 20 August 2021 (UTC)

I created a subcat for citation translation templates under Category:Citation Style 1 translation templates

--Matthiaspaul (talk) 10:02, 21 August 2021 (UTC)

Permanent errors

Note: I originally posted this[6] at Template talk:Citation, but moved it here 'cos I think this is a more appropraite location.

Category:CS1 errors: unsupported parameter includes 22 pages in the Wikipedia namespace: 14 AFD pages, and 8 pages from the Signpost.

These pages should not be edited, so they are perma-clutter in this cleanup category.

Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but the inclusion of these pages prevents that. --BrownHairedGirl (talk) • (contribs) 01:47, 21 August 2021 (UTC)

I think minor formatting corrections that do not change the actual discussion text are allowed on closed AfDs. —David Eppstein (talk) 02:21, 21 August 2021 (UTC)

Thanks, @David Eppstein. I corrected two of them, but after a re-think, I reckoned it might cause grief, so I gave up. I will re-start.

Do you think the same applies to the Signpost pages? --BrownHairedGirl (talk) • (contribs) 02:26, 21 August 2021 (UTC)

Typos are routinely fixed on Signpost pages; cleaning up unsupported parameters should be uncontroversial. isaacl (talk) 02:49, 21 August 2021 (UTC)

Unless changing the citation parameters would undermine the illustration of a problem or the flow of arguments in threads about CS1/CS2 citation template issues themselves, cleaning up such errors "under the hood" can only help to restore the former display of a citation and thereby preserve its original meaning or intention, so it is helpful maintenance not controversial.

When I (have to) edit such pages I leave a HTML comment near the change indicating what was changed and why.

If the problem can't be fixed by adjusting the template parameters (for example because this would change the meaning of arguments), an alternative to actually fixing the problem is to disable the template's categorization by adding a |no-tracking=yes parameter to the offending citation. But this requires editing as well, of course.

--Matthiaspaul (talk) 07:35, 21 August 2021 (UTC)

The simple fix is |no-tracking=yes. It leaves the citation template as it was, shows the error messages, but keeps the page out of error categories.

—Trappist the monk (talk) 12:00, 21 August 2021 (UTC)

Many thanks, Trappist the monk.

|no-tracking=yes is the least intrusive solution, so I will do that. --BrownHairedGirl (talk) • (contribs) 18:02, 21 August 2021 (UTC)

All those pages have now been cleared from the category. --BrownHairedGirl (talk) • (contribs) 18:38, 21 August 2021 (UTC)

I routinely correct the kinds of pages in question and have had only one editor be annoyed (after which I explained that it was fine for various reasons, and he assented). Izno (talk) 15:43, 21 August 2021 (UTC)

Reftag error messages

Hello, http://reftag.appspot.com/ has been generating this error message for most of this week. Reftag shortens a googlebook url and usually provides the complete cite book reference, including ISBN. Reftag is mentioned in See also at the end of this article Template:Cite book. It is also the topic of this article here.

Error: Server Error The server encountered an error and could not complete your request.

Please try again in 30 seconds.

Nothing improves in 30 seconds or 3 days. Has the link for this helpful tool in Cite Book format been changed?

Thanks. --Prairieplant (talk) 04:07, 21 August 2021 (UTC)

Unfortunately, we can't help you with that one here. This is not a CS1/CS2 citation template issue, but related to an external tool out of our control. You will have to ask the maintainer of the tool for help, who fortunately happens to have a Wikipedia account at User talk:Apoc2400. --Matthiaspaul (talk) 07:48, 21 August 2021 (UTC)

Thank you for the link to Apoc2400. I have left a message at the talk page, and it turns out I am the second person to mention these error messages when trying to use the citation tool. --Prairieplant (talk) 04:40, 23 August 2021 (UTC)

Template:Cite_serial#In-source_locations

Template:Cite_serial#In-source_locations says that |season= is a supported parameter.

But at Amy's Choice (Doctor Who)#Continuity (permalink to current version), two refs using |season= are throwing a error:

Russell T Davies (writer), Euros Lyn (director) (25 December 2009 – 1 January 2010). The End of Time. Doctor Who. BBC. BBC One. {{cite serial}}: Unknown parameter |season= ignored (|date= suggested) (help)
Robert Holmes (writer), Peter Moffatt (director) (16 February – 2 March 1985). The Two Doctors. Doctor Who. BBC. BBC One. {{cite serial}}: Unknown parameter |season= ignored (|date= suggested) (help)

How can this be fixed? --BrownHairedGirl (talk) • (contribs) 02:59, 22 August 2021 (UTC)

Try using |series= instead? In any case, this is the correct term for post-revival Doctor Who, see WP:WHO/MOS#Terminology. --Redrose64 🌹 (talk) 07:31, 22 August 2021 (UTC)

@Redrose64: see the examples above. |series= is already in use.

I have no interest in the topic. This is just drive-by maintenance.

I just want to get the citations to display the contents of each param to the citation, and thereby remove the page from Category:CS1 errors: unsupported parameter. The documentation says the current setup should work, but it doesn't

--BrownHairedGirl (talk) • (contribs) 10:38, 22 August 2021 (UTC)

Support for |season= was withdrawn from {{cite serial}} with this edit which updated the wikitext version of the template to use {{citation/core}}.

I have updated the {{cite serial}} doc.

—Trappist the monk (talk) 11:08, 22 August 2021 (UTC)

@Trappist the monk: thanks. --BrownHairedGirl (talk) • (contribs) 23:11, 23 August 2021 (UTC)

Undesirable behaviour of issue= in cite magazine when the issue is a month or months

No doubt this is in the archives but I can't find it. Take for example this citation:

Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. November/December 2005. Retrieved 1 January 2019.

The issue is "November/December 2005", it is nonsense to show it as "no. November/December 2005". The same problem would occur with "issue=Spring 2021" etc. Surely in the case where issues are numbered, the correct argument to use is "number="? How does it make sense to add a "no." prefix to "issue"? --John Maynard Friedman (talk) 09:46, 12 August 2021 (UTC)

Aren't those better handled as dates? (Doing so would require changing November/December to November–December)Nigel Ish (talk) 10:56, 12 August 2021 (UTC)

Agreed. In such cases, issues are dated, not numbered. 100.2.235.66 (talk) 11:46, 12 August 2021 (UTC)

No, that gives a very ugly result:

Paul Lunde (November–December 2005). "The Beginning of Hijri calendar". Saudi Aramco World Magazine. Retrieved 1 January 2019.

which I admit is used and works fine for {{cite news}}. In this example, the 'issue=' setting puts the information in the logical place (after the title) in the citation: the only problem is that addition of the inappropriate 'no.' Why is that intrusion ever needed?

Using (a test) number= gives

Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. 567. Retrieved 1 January 2019.

where the element is positioned logically and the insertion of 'No.' is entirely appropriate. --John Maynard Friedman (talk) 13:24, 12 August 2021 (UTC)

Here is the pdf of the Saudi Aramco World magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:

{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}

Lunde, Paul (November–December 2005). "Patterns of Moon, Patterns of Sun" (PDF). Saudi Aramco World. Vol. 56, no. 6. Retrieved 2021-08-12.

—Trappist the monk (talk) 14:04, 12 August 2021 (UTC)

Touché! I shall go and stand in the corner for the rest of the class for not having checked a citation after I cleaned it up.

BTW, why did you use "issue=6" and not "number=6"? Are they in fact synonymous, two names for the same bit of programming? If so, then that would explain everything and it will be obvious that my proposal (that issue= should not insert No. ) must get spiked. --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

|issue= and |number= are aliases.

—Trappist the monk (talk) 18:11, 13 August 2021 (UTC)

@John Maynard Friedman: Further to what Trappist wrote, the documentation explicitly shows that |number= is an alias for |issue=. So they must be expected to behave identically. --Redrose64 🌹 (talk) 22:56, 13 August 2021 (UTC)

@Redrose64: Add failure to RTFM to my sins. Detention as well for my pains.

(But they should be different, they have different meanings, so it was not just a lazy assumption. [xref Matthias P remark below]. In my sample citation, the issue is November/December, the number is 6. The date of publication is most likely to have been October. Most "in your local newsagent" magazines come out best part of a month before their declared issue date .) --John Maynard Friedman (talk) 23:23, 13 August 2021 (UTC)

(edit-conflict) |issue=6 is not wrong at present, but |number=6 would be better in this case to improve forward compatibility. At present, both parameters are treated as aliases and produce identical output. But different periodicals use different nomenclatures. It is therefore a good idea to use |issue= when the publication uses "Issues" as well, and |number= when they use "Numbers", so that the template can adapt and generate the appropriate prefix "Iss." or "No.". If the publication itself does not prescribe a certain nomenclature, it is best to use issues for volume-relative numbering schemes (as well as non-numeric issue names/titles) and number for absolute numbering schemes (because that's what most periodicals use - but not all).

Also, when we will finally add support for periodicals featuring both, a number and an issue (requested multiple times and planned for a long while), we will have to better distinguish between them to generate the proper output.

As discussed above, a date belongs into the |date= parameter, but there are cases where issues have actual names or titles. This still looks reasonably good in conjunction with |issue= ("Special issue") but not with |number=.

--Matthiaspaul (talk) 18:23, 13 August 2021 (UTC)

I suggest you put aside notions of "ugly". Most citation systems use terse, functional statements. Aesthetics rarely if at all enter the discussion. That doesn't mean that formatting cannot be improved, but such improvement must primarily enhance understanding and utility. 64.18.9.209 (talk) 14:32, 12 August 2021 (UTC)

I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

That part of the style is consistent with the academic citation styles on which it is based.Nigel Ish (talk) 18:03, 13 August 2021 (UTC)

Well, the entire Wikipedia citation ecosystem, including CS1/2 has many, many faults in design, implementation, and documentation, not all which stem from misconceptions of what a citation system geared to non-expert users (readers) should be. But this case is fairly straightforward and easily addressable. The issue number and/or date are useful in locating the source, and if known should be made available, in a way that is obvious and clear. If the issue series is dated rather than numbered, use that information anywhere it makes sense. There is nothing wrong, ugly or amateurish in entering the issue date in the date field. This is correct. The formatting of the date itself is a different issue and does not affect the needed data. 69.193.187.30 (talk) 21:19, 13 August 2021 (UTC)

There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues [7]. —David Eppstein (talk) 21:36, 13 August 2021 (UTC)

OK, some magical process will turn static forms that apply certain generic positional & formatting rules - the so-called CS1/CS2 citation statements - into dymamic AI appliances that will perfectly account for every single special case under the sun, no matter how rare. Even though the current existing non-magical documentation at least hints otherwise, and even though 1. templates are not the only way to present CS1/CS2 citations and 2. CS1/2 citations are not the only way to reference. 68.173.76.118 (talk) 22:27, 13 August 2021 (UTC)

The templates can already accommodate some "non-date dates" - i.e. seasons, Easter and Christmas according to Help:Citation_Style_1#Dates - whether the templates are modified to accommodate others will depend on how often they are used.Nigel Ish (talk) 11:03, 16 August 2021 (UTC)

I think for this to be useful, we should support more or less complete sets. An editor of Christian topics would certainly wonder why s/he can enter "Christmas 2020", but not "Pentecost 2020", which both are used in clerical publications.

Let's try to come up with some list of named dates to be supported:

Michaelmas, Martinmas, Advent, Christmas, Candlemas, Hilary, Epiphany, Lent, Easter, Pentecost, Trinity
Midspring, Midsummer, Midautumn, Midwinter
Carnival
Holiday
First Semester, Second Semester
Winter Semester, Summer Semester
First Quadrimester, Second Quadrimester, Third Quadrimester

--Matthiaspaul (talk) 03:08, 18 August 2021 (UTC) (updated 13:25, 18 August 2021 (UTC), 17:54, 27 August 2021 (UTC))

In some cases, suffixed with the word 'term', as in Michaelmas term, Easter term, Epiphany term, Hilary term, Lent term, Summer term and Trinity term. --John Maynard Friedman (talk) 20:51, 18 August 2021 (UTC)

For this to be useful, may I suggest to stop proposing additional unnecessary complexity. Especially when there are other issues with the existing modules. Wikipedia is not a science publication or a clerical publication, or whatever your area of expertise or interest may be. There is more than enough badly presented complexity already. How many citations dated "Pentecost (year)" justify the additional coding and documentation (and for non-Christians, additional explanation)? There is |issue= and |date=, and also |quote= where you can quote the date period verbatim. One or more of those 3 should be sufficient for a small minority of cases. 184.75.82.14 (talk) 21:35, 18 August 2021 (UTC)

I agree completely. These notations invariably indicate the issue of the periodical, not its date. But it seems that there is no consensus here for that view, despite it being the style used everywhere else. --John Maynard Friedman (talk) 22:20, 18 August 2021 (UTC)

It would certainly be easier if this would always be the case. Unfortunately, the real world is often more complicated than this. Please read up the old discussions which led to general support for seasons, quarters and named dates in our citation templates. As you write, sometimes these names can be seen as part of the issue (and then should also be reported as named issue in |issue=), but sometimes publications carry an |issue= in addition to a named date (and often no "normal" date at all). In these latter cases, these named dates need to be actually handled as a date in |date=, also for proper metadata generation. If not, it will become more difficult to locate these sources and obtain a copy of these publications in libraries, as they are often not found when stored under a different search key. There are even a number of dedicated COinS keys reserved for seasons (rft.ssn), quarters (rft.quarter) and named dates (rft.chron), clearly indicating that such dates are actually used in the publishing industry and that they need to be supported in the library business.

As editors of this encyclopedia, we have a duty to reproduce reference parameters as we find them (per our core policies on verifiability WP:V, neutral point of view WP:NPOV, and no original search WP:NOR), so we cannot simply "translate" a "Christmas issue" into a "December 24 issue" or a "Second Quarter issue" into an "April–June issue" just because we don't like these special dates - it would invalidate the reference making it difficult to find the publications. Also, we may be making invalid assumptions, as in some locales Christmas is in January, and quarters may start in different months depending on context.

As developers and maintainers of our citation templates we should make sure that editors are able to create citations faithfully reflecting what they find in the sources (perhaps after some minor normalization) without having to trick the templates or fall back to non-templated citations.

Editors like David Eppstein, Imzadi, Andy Dingley or Carcharoth have repeatedly asked to add support for them, not because they particularly "like" them, but simply because they run into them occasionally in their editing work. Many other editors don't have the stamina to come here asking but either give up on citation templates or invent unsupported workarounds which will lead to more inconsistency, more difficult maintainability, and lower accuracy and reliability.

Commentors in this forum should seek for ways how to make life easier for readers and editors, not unnecessarily worry about (often enough incorrectly) anticipated implementation difficulties most of them cannot fathom anyway or trying to set priorities - they can leave that to the few volunteering programmers.

What we do need your input for is when you see areas not fully or adequately covered by our templates yet and what kind of difficulties you run into or questions you might have when entering non-mainstream citations. Sharing these experiences with us will help to improve the templates and hence the quality of this encyclopedia (and quite a number of other projects taking indirectly advantage of our citations as well). Lamenting over the assumed complexity of a potential implementation does not - in the current somewhat schizophrenic situation, where people are criticizing our citation templates for non-performance in certain areas and at the same time are actively hindering the developers to implement the necessary improvements, it will only slow down the process and thereby progress as a whole. Citations are diverse and therefore complex by their underlying nature, we can't change this, but what we can help do is making it easier and more reliable to enter them anyway.

The good news in this case is that, thanks to Trappist's great work, the infrastructure to support such special dates already exists in our templates since a couple of years (including the code for proper metadata generation), so adding more named dates does not actually add more complexity to the templates - it is, with minor exceptions, just adding more entries to an already existing table of named dates.

--Matthiaspaul (talk) 11:34, 19 August 2021 (UTC)

You make several assumptions and statements above that are not based on fact. First, there are several large and small issues with the module design and with the implementation of that design. Secondly, the documentation (at all levels: for readers, editors, and developers) is hardly adequate. These existing issues should imo be addressed first.

The policies of Wikipedia you mention apply mainly (and in some cases exclusively) to wikitext in article space. They also apply to things like having different citations that verify claims of all viewpoints present in the article, the citations mostly involving third-party sources with some past history of reliability. They do not apply to how citations themselves are structured. Instead, understandable citations are required to apply some of these policies. And that is it. Everything else: modules, templates, COins, formatting rules, etc. is irrelevant. Readers, who are Wikipedia's consumers, and the targeted recipients of its policies, do not need any of these add-ons to verify whatever nonsense one writes in article space. So, may I suggest that we make sure readers know why citations should exist. Make sure that they are presented in an understandable manner. Make sure that readers know what they consist of and why. And show them how they can verify the claims made in wikitext. Once you have a good idea about how to do all that, you can use it as the input for a citation system. You can even automate parts of that citation system, as one example, by using forms (templates). Any form standardizes a process, and thereby limits it, in order to be efficient, avoid the law of diminishing returns, for positive benefit/cost ratio etc. No form will ever account for all cases, but it can account for the basic, and most common cases. The basic cases are not a mystery. They are the minimal information needed to easily and quickly find the source that verifies the wikitext, because that is the point, and not how to embroider a citation.

When readers try to discover a source, they have several options: libraries, museums, bookstores etc., other repositories of sources, and of course electronic searches online. The institutions/trade entities may or may not keep their own catalogs, but they as well as the online search engines, closely follow the way marketing, trade, and bibliographic databases are indexed. Traditionally (and presently) these indices may use the author name, the source name, and a subset of the publication info: the publishing source, the publishing date, the published version, the publishing location, etc. And also one or more marketing, classification or content-location identifiers. Every time a reader asks a person or a piece of software to find them a source, someone or something will eventually or immediately consult one or more of those (relatively few) classification databases, whether they realize it or not. As pointed out in another post, in these classification databases date indices do not order text data, but date data. The calendars used are reduced to certain date formats that include numbers and a small number of keywords (days of week, month-names etc). Personally I have not ever encountered a periodical classification database that includes keywords such as "Christmas" in their date indices. I have seen such keywords in the very rare "Issue name" field, but mostly in special fields such as "Notes", "Other", "Misc."

So yes, even with their existing problems, CS1 templates can account for a "Christmas (year)" issue, by using one or more parameter as suggested in the previous post above. The source will be found. Resources can be used where needed in order to make a citation system that responds to readers first. Then we'll see about rare cases and if it is worth doing anything about them. 65.88.88.76 (talk) 21:09, 19 August 2021 (UTC)

It is certainly important both to the editor and the reader that the reference matches as far as is reasonable how the date is presented by the publication - we shouldn't expect people who are trawling through piles of magazines (or possibly having to buy back issues) to have to infer dates which differ between the actual paper copy and the citation. The key question is how often these non-standard dates are used - ones like seasons, quarters and to a lesser extent Christmas and Easter are used sufficiently frequently (I've seen most of these in real life, often without a corresponding 'normal' date) for them to be already implemented (after much discussion) - how frequently are the suggested extra examples (and other possible examples such as say Passover or Eid) actually used?Nigel Ish (talk) 21:47, 19 August 2021 (UTC)

Yeah, but back then our citation templates were really lacking support for them at a fundamental level. So this was a bigger issue. The infrastructure to support them first had to be implemented. Now, the effort isn't much more than adding a few more entries to a table.

The point here is that most editors running into these things in real life won't come here asking us to add support for them, and even if the occasional editor finds the way into our forum, it is very inefficient to add them one after another over a period of a decade or so. If someone can run into examples using "Christmas" or "Easter" it is quite obvious by extension, that there will also be publications using some of the other important Christian liturgical dates, maybe a little less common but this doesn't really matter as it doesn't add complexity, and, in fact, someone found examples for "Trinity", etc. a couple of years later. That's why I think we should do this a little bit more systematically, and add them in sets, rather than individually. We'd stop annoying those editors running into them but not reporting them here until someone finally comes around, and it will free our minds to work on other, probably more important things.

Regarding frequency of occurrence, fortunately they are rare. But they are also cheap to add. Until I was pointed to them in discussions I never saw those liturgical dates in publications, but I don't normally edit religious articles so the likelihood was low that I would run into them. Evidence has been given that they are actually used. Regarding the other entries, I personally ran into Midsummer, Carnival (as Karneval), and the various semester variants. Doing some dedicated research I also saw midwinter, midautumn and midspring, but I wouldn't have run into them if I wouldn't have searched for them. The quadrimester entries are derived from EDTF, a standard set up by the Library of Congress and many bibliographical institutions from all over the world (meanwhile also adopted by ISO). Obviously they saw a need to support them, and they are experts in the fields. Personally, I never saw them as "quadrimeters", only as "trimesters" (but apparently that's the same).

--Matthiaspaul (talk) 00:10, 20 August 2021 (UTC)

@Nigel Ish. These days, it is probable that the number of readers going through stacks of periodicals or buying back issues in order to verify a wikitext claim is smaller than the number of times an issue dated or labeled "Christmas (year)" appears in Wikipedia citations. It is much more likely they will ask someone or some thing for help. It was explained above what is likely to happen then. As was also pointed out before, there are ways to present rare dating info right now, even with rigid elements like templates. Sure, these ways may be stretching the use of the templates, but that is because the rare dating stretches the notion of "date". The entire point is that when there are other, more substantial issues regarding CS1, this and other minor (because rare) items can wait further judgement in time. In the meantime, one of the available fixes can be used. 64.18.10.203 (talk) 04:41, 20 August 2021 (UTC)

I have a list of 2.4 million journal and magazines like:

journal-of-black-psychology_2014-08_40_4
journal-of-primary-prevention_1982_spring_2_3
journal-of-occupational-and-environmental-medicine_1959-07_1_7

Note the "spring". The four seasons are most common. There are many "supplement, "index", "special issue". Also "first quarter". Many date ranges such as "jan-apr" (or "january-april"). And "winter-spring". Combos like "fourth quarter supplement" and "january-october cumulative". About 80 "christmas". About 20 "midsummer". Nothing with "semester" or "quadrimester". -- GreenC 05:17, 20 August 2021 (UTC)

"With Smith, John" in work lists

Many pages for academics have a "Works" or "Books" section that lists out their authored books, etc. (example). For these, I often like to use the CS1 citation templates, just without the surrounding ref tags and without the author parameters, as the author can be presumed to be the subject of the page. However, this gets tricky when there are multiple authors, as listing out only the other authors would be confusing and give the impression that the subject wasn't actually involved. For these instances, I could just write out With {{citation|last=Smith|first=John|title=..., but I feel like that wouldn't be good for the metadata. Is there a way to do this better within the citation template itself? If not, could we create it? {{u|Sdkb}} ^talk 05:17, 27 August 2021 (UTC)

You're looking for the parameter |author-mask= and its cousins |author-maskn=, I believe. — JohnFromPinckney (talk / edits) 06:16, 27 August 2021 (UTC)

Thanks! I just tried it here; hopefully I did it right. {{u|Sdkb}} ^talk 06:34, 27 August 2021 (UTC)

You're welcome. You got close, but you've surely already seen that Headbomb and Redrose have tweaked the cites for you. HE, — JohnFromPinckney (talk / edits) 08:52, 27 August 2021 (UTC)

The proper solution has been found already but I'd like to add an additional remark against just leaving out (some or all of) the names (or in other cases omitting the title), as this would create incorrect metadata for the citation. Since our citations are machine-readable and are harvested by external parties, this would cause such incomplete citations to be distributed elsewhere (which can cause confusion and various synchronization or merging problems further down the chain, which eventually not only affects those third-parties but also ourselves when our editors use such external data in other articles).

So, the proper solution is, as correctly stated above, to provide all the data to make a citation self-complete, and then use special parameters (|author/editor/translator/...-maskn= for the names) to suppress certain values from the local output of the citation. (A similar case exists for titles, and we already have some means to mute titles but we are still lacking a proper method to specify a title for metadata but mask it in the local output - I hope we can address this when we add support for descriptive titles, which should show up locally without text decoration, but should not normally be made part of the metadata, or at least not without being specially marked).

--Matthiaspaul (talk) 18:35, 27 August 2021 (UTC)

Thanks; that's helpful to know! {{u|Sdkb}} ^talk 20:45, 27 August 2021 (UTC)

Same book source, different pages?

Good day,

Currently working on a major edit of MCW Metrobus, some of which involves adding book sources to previously unsourced content. But when using Template:Cite book, what general guidance is there for providing multiple sources from the same book? As in, one source uses the book on one set of pages, while another source uses the book on a different set of pages? Is there, perhaps, a way these sources can be 'combined' so there is no repetition, or is repetition the only way?

Cheers, Hullian111 (talk) 17:58, 27 August 2021 (UTC)

Hi Hullian, there are several ways how to accomplish this.

The easiest and most common method is to just combine the multiple pages into a list of cited pages in the |pages= parameter, and optionally merge the corresponding quotes from the source into the |quote= parameter (which has a separate |quote-pages= parameter, if the quotes are from a subset of those pages given in the |pages= parameter only). Once you have defined this citation through something like <ref name="YourRefName">{{cite book |YourCitationParameters=...}}</ref>, you can then invoke this citation by <ref name="YourRefName"/> whereever it is needed to support an article statement.

If you need to specify individual pages (or quotes) at the various places where you invoke your citation, you can append {{rp}} like this: <ref name="YourRefName"/>{{rp|YourPageNo}}. Some people like to combine this into a wrapper template {{r|YourRefName|p=YourPageNo}} - this gives exactly the same output but is shorter and easier to read.

All these methods are basically just variants of one main scheme how to produce citations. The advantage of all of them is that they require only one "References" section and that you can define the core citation either in the article body (so called "inline references") or, if you want to avoid the clutter a long citation definition might create in the middle of the wikitext for the article prose, it can be defined down in the "References" section (this is called "list defined references").

All the linking down to the citations and the backlinks from there up to the invocation is carried out automatically by Mediawiki without any necessary manual intervention.

There are a number of other citation methods as well, among them so called short references ({{sfn}}). Similar to {{rp}} they allow to specify short references with page numbers, but the linking works considerable different (the links are created by the templates, not by the underlying Mediawiki software which, depending on author names, dates and titles used in the core citation, can sometimes cause ambiguous or dangling pointers requiring manual fixup). Also, they require two special sections in the article, one for the short references (often named "References" or "Notes"), and another for the core citations (often named "Bibliography"). While it keeps the links in the prose extremely short even for citations with page number, this comes at the expense of an extra layer of indirection (the "References" section), which can add significant clutter to an article. Also, there are no backlinks from the core citations in the "Bibliography" section to the short references, which makes it more difficult to find and visit all invocations of a citation resolving to a single publication.

I think I would start with the first method because it is by far the most commonly used method, it covers the majority of scenarios well, and is the easiest to master. If you then need to specify individual pages this can be easily added using {{rp}} in a second step.

--Matthiaspaul (talk) 19:29, 27 August 2021 (UTC)

I think it is inaccurate to say that short references require two separate reference sections. A solution to this problem, using only a single references section, is: use a footnote containing the full reference for the first occurrence of the book among the references, and then use short citations created by {{sfn}} or {{sfnp}} for subsequent citations to different pages in the same book. Also, I would advise against using {{rp}}; it is an abomination that mixes up footnote markers with citation metadata and requires readers to remember one piece of a citation while they look up the other. I would prefer for all instances of it to be replaced by less-bad referencing styles. —David Eppstein (talk) 19:41, 27 August 2021 (UTC)

@Matthiaspaul:That’s a lot of wordage - I think I kind of understand what Matthias is going for in the first para. By the first method, I assume you mean typing out individual pages broken up by a comma? I’ve discovered you can type practically whatever you want in the page number section, so is that valid for a citation? Or do I have to break it down into individual cites?

@David Eppstein: Yeah, I have to agree on that. Breaking down cites like that seems overly complicated, and page numbers don’t exactly help when I’m linking to Google Books pages for the URL sections. The print copy I have of Wharmby’s Metrobus book probably won’t line up with the eBook version, so that’s bound to confuse readers. Especially since Google Books doesn’t provide page numbers.

Sorry if I’ve misunderstood anything, its late in the evening, and I’ll try and closely read what Matthias has proposed tomorrow. Hullian111 (talk) 22:12, 27 August 2021 (UTC)

Please do not put things in the |page= or |pages= parameter that are not page numbers. You can instead use |contribution=, |chapter=, or |at= (but |at= and |pages= cannot both be used in the same citation). For {{sfn}} there is also |loc=. —David Eppstein (talk) 22:17, 27 August 2021 (UTC)

That's something I happily agree with David. |pages= supports comma-separated lists of pages, page ranges and linked pages in any combination, but please don't put other information into the parameter. |page= is for singular pages, and |at= is for other location information (sheets, columns, paragraphs, etc.) for which the prefix p. or pp. would be misleading. These prefixes also do not belong into the parameter, they are generated by the template itself.

--Matthiaspaul (talk) 22:28, 27 August 2021 (UTC)

(edit-conflict) That's interesting, David, because I come to just the opposite conclusions. ;-) In your suggested use of {{sfn}} with the core citation defined at the first occurence, the citation ends up in the same section as the short references, and, as it also serves as the core citation for the following short references, it either cannot contain page information for the first invocation (putting the first invocation at disadvantage), or it would have to carry a combined list of pages for all invocations (and thereby would create misleading metadata for the first invocation), or it would carry the page information for the first invocation only (and then show wrong page information for all the other invocations linking to it). Certainly a way to avoid the symmetrical two-section setup, but hardy ideal. Also, in order to keep the space occupied by the often very long lists of short references smaller, this section is often formatted as multi-column list with a small column width, but this does not work well when long citations are part of this section as well - to the effect that the list of references cannot be broken into multiple narrow columns and thus occupies a lot of display space creating huge areas of white space.

I also don't understand your comment on {{rp}}. All it does is append some terse superscript page information to the superscripted links.^[1]^: 5 It does not deal with metadata at all and therefore cannot cause it to be mixed up.

Regarding your comment that it "requires readers to remember one piece of a citation while they look up the other", this is exactly the situation I find myself in when having to sift through articles containing short references created with {{sfn}} (because of the missing backlinks from the core citations to the short references or the invocations). One of the advantages of {{rp}} or {{r}} is just that they do not have this problem and automatically provide the backlinks necessary to jump between all pages cited from a single publication. To me, this is a serious shortcoming of the former.

To the OP it is important to know that the different systems obviously have different pros and cons (otherwise we wouldn't need them all ;-), and that WP:CITEVAR applies.

--Matthiaspaul (talk) 22:19, 27 August 2021 (UTC)

@Matthiaspaul: @David Eppstein: Morning all - now I’m able to look at this with a fresh head, with the recent arguments for and against in mind, I’m slowly coming round to think that {{rp}} might be my best bet for my intents and purposes. I will admit, I am still a bit of a novice at this whole Wikipedia thing despite massively picking up on editing this year, so thanks for additional clarification what shouldn’t go in the Template:Cite book page numbers area. Think I may have phrased it wrong by typing ‘anything’...

As I understand it, using {{rp}}, would this ^[2]^: 129 and ^[2]^: 178 be suitable solutions for my page number problem? Or would the other ones be an optimal way to go? Hullian111 (talk) 08:38, 28 August 2021 (UTC)

Yes, except that I would^[3]^: 131 use it like this:^[3]^: 185 See the added |pages=131, 185 parameter, merging the pages info from all short references like {{rp}}. This gives complete metadata, including page info, in the full citation. It may look a bit odd in the source code of this thread, because the definition of the full citation is located where we are actually only citing page 131, but it creates the correct output anyway, and the definition^[4]^: 201 could be added^[4]^: 205 into^[4]^: 231 the References section further down. I'm creating one here to illustrate this with a third citation:

References

^ Dummy citation
^ ^a ^b Paul Williams (15 September 2016). Manchester Buses. Amberley Publishing Limited. ISBN 978-1-4456-5315-0. Retrieved 27 August 2021.
^ ^a ^b Paul Williams (1 March 2018). Manchester Buses, Revised (2nd ed.). Amberley Publishing Limited. pp. 131, 185.
^ ^a ^b ^c Harold Smith (15 January 2020). The Return of the Manchester Bus. Manchester Publishing Company. pp. 201, 205, 231.

--Matthiaspaul (talk) 09:03, 28 August 2021 (UTC)

(edit-conflict) The alternative using {{sfn}} would^[1] look^[2] like^[3] this:^[4]

References

^ Williams 2019, p. 131.
^ Williams 2019, p. 185.
^ Williams 2019, p. 190.
^ Williams 2021, p. 102.

Bibliography

Williams, Paul (15 January 2019). Manchester Buses (corrected ed.). Amberley Publishing Limited. pp. 131, 185, 190.
Williams, Paul (1 August 2021). The New Manchester Buses (fully revised 3rd ed.). Amberley Publishing Limited. p. 102.

See, the actual links are a bit shorter because they don't show the page info embedded, but at the expense of an extra section, so you have to click twice to see the actual citation info. And once you reached the core citation, there are no links back to the individual short refs. Also, the linking itself relies on anchor names created by the citation templates (derived from the author surnames and year, and this can easily led to ambiguous anchor names and invalid HTML (when there are two publications by the same author in a year or two authors of the same name) or dangling pointers (if someone does not recognize that the citation in the bibliography section is referenced from the short references further up and changes or deletes it). There are sometimes also discrepancies between the anchor name created by the citation template and the assumed anchor name used in the short references (not in this example, of course). These errors can be fixed, but they are difficult to detect and therefore it often takes months or years until someone finally finds and fixes them (there are some tools to assist in this process). All in all this style requires careful testing and maintenance. This cannot happen with the style I am recommending further up because it does not rely on these self-created link names but only on those created and used by the underlying Mediawiki software (which reliably displays error messages when there are errors).

--Matthiaspaul (talk) 10:30, 28 August 2021 (UTC)

@Matthiaspaul: Thanks, think that's it! Testing it in Sandbox, I think that method you've suggested works well and should satisfy the issue for the four and potentially more page cites I need to insert into the article. Might take me a while to fully break it down, but I think that's my query solved. I'm going to be working on this MCW Metrobus page for a while over on Docs and Sandbox before I publish it, so if you happen to stop by, let me know if I'm doing it right. Still learning as I go along, after all.

Cheers, Hullian111 (talk) 11:40, 28 August 2021 (UTC)

@Hullian111: Have a look at Swindon railway station#History, references 1 through 7 inclusive. Is this what you are wanting? --Redrose64 🌹 (talk) 09:46, 28 August 2021 (UTC)

This is in fact an example of the unsymmetrical {{sfn}} style David was recommending. However, in addition to the general issues with {{sfn}} described by me above, it creates misleading (and incomplete) metadata (only valid for the first citation) and "nicely" illustrates the excessive white space caused because short and long references are mixed in the same section so that columns must be wide enough for the long references. I think, in this example, it's still tolerable, but there are examples with much longer lists of short references, where it really impacts the visual appearance of an article. On the other hand, when the in-article-location information becomes much longer than a short page or page range, the {{rp}} style can become distracting as well. So, what's best in a particular article depends on the circumstances.

--Matthiaspaul (talk) 10:46, 28 August 2021 (UTC)

To the OP: take a look at WP:LDR and also templates {{harv}} and {{sfn}}. The short citations can be displayed with {{reflist}} and the full citations with something like the {{refbegin}}/{{refend}} combination. 68.173.76.118 (talk) 23:12, 28 August 2021 (UTC)

error messaging

This is a sidetrack off of Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header. Over the past few days I have been reworking how error messaging is handled in the various modules (primarily Module:Citation/CS1 and Module:Citation/CS1/Identifiers which emit the most errors). In the previous conversation, I suggested that it would be a good thing to move all error messages to the end of the citation. As it is right now, some error messages are made part of the template's rendering which, to me, looks bad.

The live module has a table called z.message_tail which holds all of the error messages that are rendered following the citation. To load that table, it is necessary for the code to call set_message() in Module:Citation/CS1/Utilities. That function returns the error message as a plain message or as a message wrapped in ... tags appropriately classed for hidden or visible error messages. The function that called set_message() then has to use the returned message as an appendage on a parameter's data or as a replacement for it; or, the function must insert the returned message into the z.message_tail table. Moving all error messages to the end of the citation means that set_message() can insert the message in z.message_tail as part of its normal operation and so the code is simpler and more consistent.

I have done that. The change primarily impacts Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox but also impacts Module:Citation/CS1/Utilities/sandbox. I have renamed z.message_tail to z.error_msgs_t so that the name reflects its content.

As part of this I have spent a bit of time refining the assembly of the various parts of the finished citation (the citation itself, the anchor ID and the css classes in the <cite> tag, the metadata, the error messages, the maintenance messages, and the categories (roughly the 100ish lines of code beginning at about line 3844 of Module:Citation/CS1/sandbox). This includes the error and maintenance summaries and the error message prefixes discussed in the previous conversation, sorting of error and maintenance messages. Empty citations will no longer produce metadata because why bother:

{{cite book}}

{{cite book}}: Empty citation (help)

'"`UNIQ--templatestyles-000000B2-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

{{cite book/new}}

{{cite book}}: Empty citation (help)

'"`UNIQ--templatestyles-000000B5-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

—Trappist the monk (talk) 22:02, 28 July 2021 (UTC)

I wonder if some kind of "error framing" could be done (at least in preview) to make it easier for editors to spot the errors. Mockup:

{{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=Vol. 34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}

Smith, John (9999). "Title of Things". Journal of Stuff. Vol. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}: |volume= has extra text (help); Check date values in: |date= (help)

I assume it would complicate the code too much but still wanted to mention it to spread the idea.

--Matthiaspaul (talk) 00:59, 29 July 2021 (UTC)

In your example above

**

the two message spans could be combined into one:

**

to reduce the size of the resulting HTML. However, I understand that this might not always be possible if they are interwoven with hidden messages, so I'm mentioning this just in case you see an easy way to do it anyway.

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Yeah, they could be combined but it is much easier in the code to have them as separate spans because we can't always and forever know that the first error message after the {{Cite book}} prefix will be a visible error message. However, that does highlight a flaw in the prefix design; if all error messages emitted by a citation are hidden, then the prefix should also be hidden. As it is, it is always visible. I'll think about that ...

—Trappist the monk (talk) 15:10, 1 August 2021 (UTC)

Citations emitting only hidden error messages will also hide the error message prefix:

{{cite journal/new |title=Title}}

"Title". {{cite journal}}: Cite journal requires |journal= (help)

'"`UNIQ--templatestyles-000000BC-QINU`"'<cite class="citation journal cs1">"Title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+78" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>

—Trappist the monk (talk) 16:29, 1 August 2021 (UTC)

Do not emit duplicate IDs in any case. Our objective is to comply with HTML and that does not. Thanks. I'll revert the lot of the sandbox if that remains in the code. The supposed gain is not worth that. Izno (talk) 14:12, 3 August 2021 (UTC)

Presumably this is related to discussion that occurred at Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header regarding links from the preview warning messages to citations elsewhere in the previewed article. Where were you and your objections when we first discussed this? You were around and even edited this page during the period of that conversation. Instead of swooping in with drama and threats after the fact, it would have been better for you to participate in the discussion as it was on-going.

The point is taken and I have removed the spans and go-to links.

—Trappist the monk (talk) 15:37, 3 August 2021 (UTC)

Busy trying not to care about Matthias' outlandish requests? :) Izno (talk) 15:51, 3 August 2021 (UTC)

Not funny, and not outlandish at all. It's all about user-friendliness and usability.

The anchors/spans are added only if there is a problem in a citation. So articles without problematic citations will never have them. Also, above I proposed to add them only in preview in order to not invalidate HTML in normal article view. Even web designers who otherwise care about good HTML often deliberately ignore trivialities like this, in particular if it is known to not cause any harm.

Further, all articles with citations lacking disambiguation contain identical anchors and thereby contain invalid HTML - and not only in preview or with actual citation errors, but in normal article view for as long until the disambiguation gets fixed. And in this case, a doubled anchor actually causes "harm" as it makes subsequent citations "unreachable". When we discussed this when making |ref=harv the default, we decided to ignore this because the benefit far outweights the problem. Nobody complained about it.

We should do the same here as well, in particular as in this case the doubled anchors do not create any practical problem for browsers at all and do only exist in preview and when citations have errors, anyway. So, ignoring the "no double anchors" doctrine would be a valid engineering decision. If we do not, we should immediately switch off harv-style anchors as well.

--Matthiaspaul (talk) 17:28, 3 August 2021 (UTC)

HTML structure of a citation

However, there is a related, more general issue. This is unrelated to preview messages and the restructuring of error messages, but since we are talking about the structure of the HTML for a citation, I'm bringing this up anyway.

The general structure of a citation (in the sandbox, that is, including the preview message) is as follows:

<span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span>

Citation with appended messages

Some browers and tools allow to highlight the scope of elements and navigate from element to element or otherwise take advantage of knowing the scope of data elements (screenreaders and browsing assistance tools, web development tools, web harvesters). Right now, they see a citation as an empty preview error span, the actual citation with optional messages appended, followed by the COinS info.

This is somewhat suboptimal. The preview error span should span over the whole citation including messages and COinS data.

In addition to this, the COinS span should ideally span over the citation and messages as well in order to declare the context of the COinS data. This would result in the following nested structure:

<span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span>

Citation with appended messages

The only adverse effect of this rearrangement I can see right now is that the browser will now display the COinS data as tooltip, which might be confusing. So, if the contents of the COinS span really must be empty, it might be possible to do it the other way around and embed it into the cite element. The preview error span could still wrap around both:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></cite></span>

Citation with appended messages

In both of these two cases, the proper extraction of COinS data by existing tools would have to be tested, because in the examples I could find on the web they always suggest that this is an empty element (or only containing a space) immediately following the citation. At least wrapping the preview span around both of them will work regardlessly:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></span>

Citation with appended messages

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Umm, the general structure of a sandbox citation is not quite what you say it is. See for example this:

{{cite book/new |title=Title |access-date=2021-08-01}}

Title. {{cite book}}: |access-date= requires |url= (help)

<templatestyles src="Module:Citation/CS1/sandbox/styles.css"></templatestyles><span id="cite-book-error"></span><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3ABlue" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>[[Category:CS1 errors: access-date without URL]]

so what we have is:

<templatestyles></templatestyles>><cite>The Citation</cite>><messaging><categories>

I created empty error-anchor and maint-anchor spans because that is how {{anchor}} implements anchors. It is easy enough to wrap the entire rendering from <cite> to the end of the last category in the error-anchor and maint-anchor spans. If we did that, we could add an undefined class so that editors can style the anchored citations; don't know how beneficial that would be ...

I am unwilling to change how the metadata span is handled without someone having conducted extensive research to prove that your suggestion does not break external tools. Apparently metadata works now so ain't-broke-don't-fix applies.

—Trappist the monk (talk) 14:55, 1 August 2021 (UTC)

Error-anchor and maint-anchors now wrapp entire citation from <cite> to the end of the last category:

{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}

Title. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |authors= ignored (help)

'"`UNIQ--templatestyles-000000C8-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+78" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;authors=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

—Trappist the monk (talk) 16:19, 1 August 2021 (UTC)

Looks good, thanks.

I agree, moving the COinS info will require more research in regard to what works with existing tools, and what might not. That's why I was bringing this up.

Unfortunately, the standard itself is not very clear about it, so implementations might vary in regard to what they expect. As far as I understand it, there should be no inherent dependency of the COinS span from <cite>, therefore from the viewpoint of data extraction, it should not matter, if one gets embedded into the other.

Regarding the contents of the COinS span, they suggest to use a space in environments where an empty span would be removed in some HTML optimization processes. From this we can at least derive that the span does not need to be empty.

They also talk about the possibility to place some default text in there, leaving it open to interpretation if COinS-aware browser plug-ins are meant to replace this text with some link/icon to a pop-up etc., or if they are meant to insert such links/icon after the text. If we find a browser plug-in which would replace the text, we obviously cannot place the citation there, otherwise this would be the most-"natural" place for it. It would be interesting to learn from the community which tools they use and how they behave on the following two test citations:

Manually crafted citation with <cite> inside COinS span:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].

Manually crafted citation with COinS span inside <cite>:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].

--Matthiaspaul (talk) 11:18, 3 August 2021 (UTC)

Given that the COINS span outputs its content as a title, putting cite inside the span is a non-starter. Everything internal will have a hover over title completely meaningless to users and defeating the other over hovers we have (links predominantly). Izno (talk) 14:10, 3 August 2021 (UTC)

Proposition: "narrator" alias

For audiobooks, mainly. Whenever the various situations are sorted out and proper development restarts. This alias may be useful. 66.108.237.246 (talk) 13:39, 1 September 2021 (UTC)

Audiobook probably use {{cite media}} with |others=Narrated by Simon Vance. The free-form |others= allows for multiple narrators; or, "Full-cast" such as BBC radio adaptations of a book that are too many to list, or some staring roles. --GreenC 14:58, 1 September 2021 (UTC)

There are also other situations for a narrator role apart from audiobooks, such as TV programs, films, and also things like scripts (of plays etc). I don't know if it as common as the translator role that has its own alias, but I wouldn't be surprized. 65.88.88.46 (talk) 15:15, 1 September 2021 (UTC)

There are many roles (not a complete list): Author, Composer, Contributor, Cover artist, Cover designer, Designer, Director, Editor, Forward, Illustrator, Introduction, Narrator, Photographer, Preface, Translator. -- GreenC 15:25, 1 September 2021 (UTC)

|others= works fine for these roles. Almost none of them help with WP:V, which is the main purpose of these templates. – Jonesey95 (talk) 16:09, 1 September 2021 (UTC)

There is a rare case when the narrator info can contribute to verification. In many works (and unfortunately so, imo) the narration is acted rather than read straight. It is conceivable that the narrator's inflection may change the meaning for some listeners. Wikitext may claim a "fact" that depends on such meaning. There should be some indication that the wikitext claim is due to the narrator (as de facto editor) and not necessarily due to the author. But this may be better suited to a more complete citation system. 65.88.88.46 (talk) 17:09, 1 September 2021 (UTC)

Adding an observation made in this discussion about the illustrator role. Audiobook titles can be found by using the "narrator" info, even when the author is not used. The major trade databases (wholesale & retail) index the "narrator" field, and the narrator is prominently displayed in browse lists along with the author. 65.88.88.76 (talk) 21:00, 2 September 2021 (UTC)

`{{hyphen}}` converted to dash

Help:Citation Style 1#pagehyphen says For a hyphenated page, use |page=12{{hyphen}}34. This will not only properly display a hyphen... However, I don't believe this is true, as "{{cite book|title=Title|pages=1{{hyphen}}2}}" renders as "Title. pp. 1–2." with a dash. --Ahecht (TALK
PAGE) 02:27, 2 September 2021 (UTC)

|page= and |pages= are not the same thing. Compare your example:

{{cite book|title=Title|pages=1{{hyphen}}2}}

Title. pp. 1–2.

and the same citation according to the documentation:

{{cite book|title=Title|page=1{{hyphen}}2}}

Title. p. 1-2.

—Trappist the monk (talk) 02:40, 2 September 2021 (UTC)

@Trappist the monk Got it. I added to the "pages" section to clarify. While I have your attention, the "Accept-this-as-written markup" section says Markup can be applied to the entry as a whole or to individual list entries, but that doesn't seem to work for numbers with commas:

{{cite book|title=Title|pages=1, ((1,234))}}

Title. pp. 1, 1,234.

I understand that the logic for handling this case would be more complex than what the module currently does, and would require pre-processing the string before splitting it. If this behavior is intended, should the documentation clarify? --Ahecht (TALK
PAGE) 15:56, 2 September 2021 (UTC)

I saw your tweak to the documentation but the module is smart enough to handle the hyphenated case you demonstrated:

{{cite book |title=Title |pages=1-2–3-4}} – a range of hyphenated page numbers without the need for {{hyphen}} and {{endash}}

Title. pp. 1-2–3-4. – works properly

But if you prefer to use the templates:

{{cite book |title=Title |pages=1{{hyphen}}2{{endash}}3{{hyphen}}4}}

Title. pp. 1-2–3-4. – still works properly

We should reserve recommendation of the accept-this-as-written markup for those cases where it is truly needed so I am going to revert you.

—Trappist the monk (talk) 16:08, 2 September 2021 (UTC)

@Trappist the monk: I suppose a better example would be {{cite book|title=Title|pages=((1{{hyphen}}2)), ((3{{hyphen}}4))}} where those are intended to by hyphenated page numbers. Any objection to me adding that to the help page? --Ahecht (TALK
PAGE) 19:29, 2 September 2021 (UTC)

No objection. You might want to note the difference between your example and this:

{{cite book|title=Title|pages=((1{{hyphen}}2, 3{{hyphen}}4))}}

Title. pp. 1-2, 3-4.

because of what happens when a space character is omitted:

{{cite book|title=Title|pages=((1{{hyphen}}2,3{{hyphen}}4))}}

Title. pp. 1-2,3-4.

—Trappist the monk (talk) 19:41, 2 September 2021 (UTC)

[1] Library Services (February 2016). "Harvard Referencing Guide" (PDF). London Metropolitan University. Retrieved 18 August 2021. (Section: Journal articles – print and electronic)

[2] Dummy citation

[Williams2016-3] Paul Williams (15 September 2016). Manchester Buses. Amberley Publishing Limited. ISBN 978-1-4456-5315-0. Retrieved 27 August 2021.

[Williams2018-4] Paul Williams (1 March 2018). Manchester Buses, Revised (2nd ed.). Amberley Publishing Limited. pp. 131, 185.

[Smith2020-5] Harold Smith (15 January 2020). The Return of the Manchester Bus. Manchester Publishing Company. pp. 201, 205, 231.

[FOOTNOTEWilliams2019131-6] Williams 2019, p. 131.

[FOOTNOTEWilliams2019185-7] Williams 2019, p. 185.

[FOOTNOTEWilliams2019190-8] Williams 2019, p. 190.

[FOOTNOTEWilliams2021102-9] Williams 2021, p. 102.

[1]

[1]

[2]

[3]

[4]

[1]

[2]

[3]

[4]

when |archive-url= is broken

Cite magazine – why upper case Vol.?

display-authors bug

Markup in titles

{{cite web}} template: please make the title parameter optional

Incorrect spacing

Current version of page no longer contains cited facts. url-status=?

Replacing "--" by "–"...

Location within large tree-structured documents with no page numbers

Identificativo SBN

How to extlink the components of a multi-component publication

bad DOI check

Date quarters

Push PMID limit up

Multiple URLs (split file)

Support for slash in some date ranges?

non-English translator templates and substing

Permanent errors

Reftag error messages

Template:Cite_serial#In-source_locations

Undesirable behaviour of issue= in cite magazine when the issue is a month or months

"With Smith, John" in work lists

Same book source, different pages?

error messaging

HTML structure of a citation

Proposition: "narrator" alias

{{hyphen}} converted to dash

`{{cite web}}` template: please make the `title` parameter optional

`{{hyphen}}` converted to dash