Help talk:Citation Style 1

Active discussions
Citation templates
... in conception
... and in reality

asin & isbnEdit

|asin= accepts 10-digit numbers that can be 10-digit ISBNs or 10-digit numbers that begin with 630 or 631 which are not (currently) ISBNs but are ASINs. We have Category:CS1 maint: ASIN uses ISBN where we keep track of |asin= with a numerical value that is probably an ISBN – the number checks as a numerically valid ISBN.

I have tweaked Module:Citation/CS1/Identifiers/sandbox so that it emits error (red) messages when |asin= has an assigned numerical value that does not begin with 630 or 631. Additionally, I have tweaked the ISBN-10 validation code so that it emits an error message when |isbn= has an assigned value beginning with 630 or 631 (probably an ASIN):

Cite book comparison
Wikitext {{cite book |title=Title |asin=412346789X}}
Live Title. ASIN 412346789X Check |asin= value (help).
Sandbox Title. ASIN 412346789X Check |asin= value (help).
Cite book comparison
Wikitext {{cite book |title=Title |asin=6305277001}}
Live Title. ASIN 6305277001.
Sandbox Title. ASIN 6305277001.
Cite book comparison
Wikitext {{cite book |title=Title |asin=6317484546}}
Live Title. ASIN 6317484546.
Sandbox Title. ASIN 6317484546.
Cite book comparison
Wikitext {{cite book |title=Title |isbn=412346789X}}
Live Title. ISBN 412346789X.
Sandbox Title. ISBN 412346789X.
Cite book comparison
Wikitext {{cite book |title=Title |isbn=6305277001}}
Live Title. ISBN 6305277001 Check |isbn= value: invalid group id (help).
Sandbox Title. ISBN 6305277001 Check |isbn= value: invalid group id (help).
Cite book comparison
Wikitext {{cite book |title=Title |isbn=6317484546}}
Live Title. ISBN 6317484546 Check |isbn= value: invalid group id (help).
Sandbox Title. ISBN 6317484546 Check |isbn= value: invalid group id (help).

If this is accepted, Category:CS1 maint: ASIN uses ISBN will go away; these asin errors will categorize in Category:CS1 errors: ASIN‎. The error message for |isbn=63[0|1]....... reuses an existing error message supplement currently only used for ISBN-13 / ISMN group id errors.

Trappist the monk (talk) 20:42, 24 January 2021 (UTC)

Don't see why it would not be accepted. Seems non-controversial and intuitive. (talk) 21:09, 24 January 2021 (UTC)
Looks good to me as well.
Speaking of ASINs, we do not currently generate COinS data for ASINs and OLs because we would first need to communicate the ASIN TLD info and the OL A/M/W/X type to the COinS module. Some months back I was in the process of devising some way how to achieve this with minimal changes, but since the internal organization was changed considerable recently and you are more familiar with it I would appreciate if you could have a look at this for a probably more general solution.
--Matthiaspaul (talk) 22:19, 24 January 2021 (UTC)
Perhaps I have a solution. If asin() gets a pointer to ID_list_coins_t{} in Module:Citation/CS1/Identifiers/sandbox, asin() can overwrite the plain identifier with a properly assembled url. If we also change id_handlers['ASIN']['COinS'] to something other than nil in Module:Citation/CS1/Configuration/sandbox, Module:Citation/CS1/COinS/sandbox will use that value (the url) in an &rft_id= attribute:
{{cite book/new |title=Title |asin=6305277001}}
Title. ASIN 6305277001.
'"`UNIQ--templatestyles-0000002C-QINU`"'<cite class="citation book cs1">''Title''. [[ASIN (identifier)|ASIN]]&nbsp;[// 6305277001].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&" class="Z3988"></span>
I presume that this same scheme will also work for |OL=. Also, with a bit of a tweak overwrite an erroneous plain identifier value with nil (each identifier function in ~/Identifiers/sandbox), and a bit of a tweak to ~/COinS/sandbox so that it can detect nil identifier values, prevent erroneous identifiers from getting into the metadata.
Trappist the monk (talk) 17:54, 26 January 2021 (UTC)
Sorry for the long delay, Trappist, it is only now that I found the time to have a look at your proposed solution. It looks good to me, thanks.
Getting some means to suppress metadata generation for erroneous identifiers is desirable as well.
--Matthiaspaul (talk) 12:49, 28 February 2021 (UTC)
I have hacked Module:Citation/CS1/Identifiers/sandbox to suppress metadata generation for erroneous identifiers. Values from those identifiers that support accept-as-written markup (|doi=, |isbn=, |eissn=, and |issn=) are included in the metadata when so marked regardless of validity. |sbn= supports accept-as-written markup but is not (never has been) included in the metadata because we don't create a url for it, because rft.sbn is not a COinS-defined key, and because sbn is not registered at (for the info: URI scheme).
This change breaks almost all of the testcases at Module talk:Citation/CS1/testcases/identifiers. |sbn= is not broken because metadata are not created for that parameter. I discovered a long-standing bug in Module:Citation/CS1/Configuration/sandbox for |ismn=. The id_handlers['ISMN'].COinS assignment was 'nil', a string, when it should be nil, the datatype (represents the absence of a value). That was causing the module suite to add a malformed rft_id=<ismn value> k/v pair to the metadata for citations that use |ismn=. Fixing that breaks every ismn testcase.
Trappist the monk (talk) 21:01, 9 March 2021 (UTC)
I now see some bogus error messages I didn't recognize two months back, therefore I assume that this is a new issue possibly caused by the changes above:
  • No ASIN, invalid TLD:
Cite book comparison
Wikitext {{cite book |title=Title |asin-tld=xy}}
Live Title. |asin-tld= requires |asin= (help)
Sandbox Title. |asin-tld= requires |asin= (help)

misses the "Check |asin-tld= value" message.

  • No ASIN, valid TLD:
Cite book comparison
Wikitext {{cite book |title=Title |asin-tld=de}}
Live Title. |asin-tld= requires |asin= (help)
Sandbox Title. |asin-tld= requires |asin= (help)


  • Valid ASIN, invalid TLD:
Cite book comparison
Wikitext {{cite book |asin=6305277001 |title=Title |asin-tld=xy}}
Live Title. ASIN 6305277001 Check |asin-tld= value (help).
Sandbox Title. ASIN 6305277001 Check |asin-tld= value (help).

has extra "|asin-tld= requires |asin=" message.

  • Valid ASIN, valid TLD:
Cite book comparison
Wikitext {{cite book |asin=6305277001 |title=Title |asin-tld=de}}
Live Title. ASIN 6305277001.
Sandbox Title. ASIN 6305277001.


  • Invalid ASIN, invalid TLD:
Cite book comparison
Wikitext {{cite book |asin=xyz5277001 |title=Title |asin-tld=xy}}
Live Title. ASIN xyz5277001 Check |asin-tld= value (help).
Sandbox Title. ASIN xyz5277001 Check |asin-tld= value (help).

has "|asin-tld= requires |asin=" message instead of "check |asin= value".

  • Invalid ASIN, valid TLD:
Cite book comparison
Wikitext {{cite book |asin=xyz5277001 |title=Title |asin-tld=de}}
Live Title. ASIN xyz5277001 Check |asin= value (help).
Sandbox Title. ASIN xyz5277001 Check |asin= value (help).

has extra "|asin-tld= requires |asin=" message.

  • Valid ASIN, no TLD:
Cite book comparison
Wikitext {{cite book |title=Title |asin=6305277001}}
Live Title. ASIN 6305277001.
Sandbox Title. ASIN 6305277001.


  • Invalid ASIN, no TLD:
Cite book comparison
Wikitext {{cite book |title=Title |asin=xyz5277001}}
Live Title. ASIN xyz5277001 Check |asin= value (help).
Sandbox Title. ASIN xyz5277001 Check |asin= value (help).


I haven't had a chance to look into this so far.
--Matthiaspaul (talk) 00:01, 30 March 2021 (UTC)
I think that I have fixed these concerns by moving the asin-tld-requires-asin test into Module:Citation/CS1/Identifiers/sandbox. The test doesn't care what the assigned value is, only that when |asin-tld= has a value, |asin= must also have a value. Validation of |asin-tld= is handled by asin(). The tld validation test is done before the identifier validation test; asin() terminates with an error message at the first error.
This test code also works in the same way for |doi-broken-date= without |doi= and |pmc-embargo-date= without |pmc=
{{cite book/new |title=Title |doi-broken-date=April 2021}}Title. |doi-broken-date= requires |doi= (help)
{{cite book/new |title=Title |pmc-embargo-date=2 April 2021}}Title. |pmc-embargo-date= requires |pmc= (help)
Trappist the monk (talk) 22:57, 2 April 2021 (UTC)

I'm not sure I understand why Category:CS1 maint: ASIN uses ISBN should be gotten rid of. It's a very useful category, and an ISBN for an ASIN doesn't mean it's an invalid ASIN, just a redundant one that should be converted to an ISBN. Headbomb {t · c · p · b} 17:19, 1 February 2021 (UTC)

This belongs more into the already archived thread at Help_talk:Citation_Style_1/Archive_75#Added_asin-tld=_range_checking, but since I don't want to start a new thread for this minor bit, I'm hijacking this one just to note down that support for Polish ASINs ("pl"), which were introduced earlier this month, has now been added to the template's |asin-tld= parameter as well. --Matthiaspaul (talk) 15:23, 29 March 2021 (UTC)

"Log into Facebook"Edit

Should we add "Log into Facebook" (and "Log into Facebook - Facebook", "Log into Facebook | Facebook") to Category:CS1 errors: generic title? 83 results in article space. – Finnusertop (talkcontribs) 04:10, 24 February 2021 (UTC)

83 hits is not exactly a lot but I would add it anyway:
Other related threads:
--Matthiaspaul (talk) 13:59, 24 February 2021 (UTC) (updated 21:43, 5 March 2021 (UTC))
Added to sandbox:
Cite book comparison
Wikitext {{cite book |title=Log into Facebook}}
Live Log into Facebook. Cite uses generic title (help)
Sandbox Log into Facebook. Cite uses generic title (help)
--Matthiaspaul (talk) 21:43, 5 March 2021 (UTC)
@Matthiaspaul: one more that is related to Facebook: "Redirecting...". Searching for "Redirecting... facebook" returns 8 results, but this is not the proper way to search. – Finnusertop (talkcontribs) 20:04, 11 March 2021 (UTC)
This search finds ~80 results.
Trappist the monk (talk) 20:27, 11 March 2021 (UTC)
Added to sandbox:
Cite book comparison
Wikitext {{cite book |title=Redirecting...}}
Live Redirecting... Cite uses generic title (help)
Sandbox Redirecting... Cite uses generic title (help)
--Matthiaspaul (talk) 14:55, 20 March 2021 (UTC)

generic titleEdit

Added internet archive wayback machine ~560 hits

These were added by REFLINKS c. 2012.

Trappist the monk (talk) 13:08, 3 March 2021 (UTC)

And added webcite query result ~300 hits
And these were (are) added by reFill and reFill 2.
Trappist the monk (talk) 19:09, 18 March 2021 (UTC)
And another wikiwix's cache ~200 hits
Trappist the monk (talk) 19:22, 25 March 2021 (UTC)

Should cite comic be part of CS1?Edit

As titled - should {{Cite comic}} be incorporated into the CS1 module? (Previous discussion in 2013: Template talk:Cite comic#CS1)

Some observations on the template:

  • In Template talk:Cite comic#Language field (2011 and 2013), there were some complaints on the lack of |trans-title= which is currently already available in CS1.
  • Other than that, the template also lacks stuff like |url-access=, |archive-url=, |via=, etc.
  • |isbn= is not available and has to be manually entered in the format of |id=ISBN 0123456789.
  • No COinS is generated.

Note: The template has a unique display for the various author fields (|writer=, |artist=, etc.) and might not be straightforward to merge into CS1; hence bringing this up but not making it an official tfm nomination. ネイ (talk) 15:36, 3 March 2021 (UTC)

It seems like it wouldn't be that difficult to make it a wrapper of {{citation}} or {{cite book}}. Give it a try in the sandbox. – Jonesey95 (talk) 16:25, 3 March 2021 (UTC)
Depends on what is meant by cite comic. Is it a specific issue? Then probably the closest analog is {{cite magazine}}. Is it an anthology or collection? Then probably the closest is {{cite encyclopedia}} or one of the other redirects of that sort. The other issue of course is similar to the one that {{cite AV media}} and notes has in that it has many other fields for people who are not the author (and which subsequently do not necessarily fit into the CS1/2 mechanism all that well). Izno (talk) 03:37, 21 March 2021 (UTC)

Requested move 8 March 2021Edit

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Not moved (non-admin closure) (t · c) buidhe 02:23, 15 March 2021 (UTC)

– It's not really possible to cite a conference, only a specific presentation at one, the actual work. Trying to "cite a conference" would be like trying to "cite a corporation" or "cite a TV network". Not something WP would do. If one means to cite some written material that was included in a conference proceedings book, but which was not a presentation (e.g. some kind of post hoc introductory or analysis material), that would be better with {{cite paper}} or {{cite report}}). PS: I'm listing this here because Template talk:Cite conference redirects to this talk page.  — SMcCandlish ¢ 😼  02:22, 8 March 2021 (UTC)

  • You have requested a name change based on a misunderstanding. {{cite conference}} is to cite the proceedings, not a conference per se. The documentation has said as such for a long time. --Izno (talk) 02:34, 8 March 2021 (UTC)
  • Speedy oppose seemingly a misunderstanding. A parallel can be made: we don't cite a journal, we cite an article within it. The documentation is rather clear. Cheers, RandomCanadian (talk / contribs) 03:40, 8 March 2021 (UTC)
    There's no such thing as a "speedy oppose". All your response has done, really, is point out that the template-and-redirect relationship of {{cite journal}} and {{cite paper}} should probably be flipped.  — SMcCandlish ¢ 😼  08:42, 8 March 2021 (UTC)
    Seems like making a point just to make a point. cite paper has so few uses, I don't see why we'd want to change a long standing practice just out of some arcane reasoning that it's the "correct" way to refer to things. As for why it's "{{cite journal}}", that's because an 'article' ['paper' is a misnomer when the format is usually electronic...] could also refer to {{cite news}}. RandomCanadian (talk / contribs) 16:08, 8 March 2021 (UTC)
    Template redirects usually have few uses (unless they are convenient shortcuts like {{cn}}), precisely because they are redirects. We have bots and AWB scripts that auto-replace those redirects with the names of the actual templates (while making a more substantive edit of some kind, per WP:MEATBOT). So your sense that the redirect isn't used much is meaninless. It's weird to me that zero of the opposition responses here have been substantive in any way, much less actually addressed the rationale of the proposal. It's all WP:IDONTLIKEIT handwringing about change in general. This is not NeophobiaPedia last I looked.  — SMcCandlish ¢ 😼  02:19, 9 March 2021 (UTC)
    You want to change something that is most definitively not broken; like the template parameters annoyance of late. Your sole argument is what exactly? {{cite news}} does not cite a whole newspaper, only one article. {{cite journal}} does not cite a whole journal, only an article. {{cite conference}} does not cite a whole conference, only a part of it. The current title is meeting WP:CONSISTENCY with the existing style and is also more helpful by avoiding possible ambiguities in other areas (not all instances of citing a journal are what is termed a "paper" - occasionally this can be a review or something; and well "article" could refer both to a scholarly [journal] as well as to a popular press [news] publication)... As for "redirects usually have few uses": it also shows that the current style is well understood and well established and changing it on a technical whim likely isn't a productive spending of time. RandomCanadian (talk / contribs) 03:06, 9 March 2021 (UTC)
  • Comment @SMcCandlish:, although personally I'm fine with "Cite conference", I was going to create {{Cite proceedings}} for you and link it here since I get your point, and logically "Cite proceedings" is unambiguous where "Cite conference" might not be. As it turns out, someone created it ages ago. I'll probably start using that redirect myself, as I think it makes more sense. Mathglot (talk) 04:43, 8 March 2021 (UTC)
    Agree that "Cite proceedings" is probably the better format. In which case this should be procedurally closed and a new one with the better target opened. RandomCanadian (talk / contribs) 04:58, 8 March 2021 (UTC)
    It's a good redirect to have, but in this day and age we're often enough actually citing the presentation itself, since plenty of conferences are videoed in their entirety and available as online video. While one could also use {{cite video}} or {{cite web}} (or probably even {{cite speech}} for that matter), the ability to cite the same thing with any of several templates is nothing new, and not a problem, nor of any real relevance to the RM, which is about this particular template not being well-named. Anyway, whether we're citing the paper version of the presentation printed in the proceedings (or e-printed in the online copy of the proceedings), or we're citing an actual recording of the presentation, we're still citing the presentation, not the entire conference and not the entire proceedings volume, per se, so I stand by the rename proposal.  — SMcCandlish ¢ 😼  08:42, 8 March 2021 (UTC)
    I don't mind if "Cite proceedings" is created as a redirect to "Cite conference". But I oppose making "Cite proceedings" as the main name of the template because many journals are titled "Proceedings of ...". Examples include Proceedings of the IEEE, Proceedings of the National Academy of Sciences, and Proceedings of the Royal Society B: Biological Sciences. Jc3s5h (talk) 16:25, 8 March 2021 (UTC)
    Well, that's not the rename proposed here (it's to {{Cite presentation}}). And I'm not sure that "titles starting with ..." thing would matter anyway. Various movies and such are named "[The] Book of ...", yet this has no pro or con effect on whether we have a template named {{Cite book}}. If someone can't tell whether they are citing a journal versus a conference proceedings volume (or whether they're citing a film versus a book), they're not competent to create citations in the first place.  — SMcCandlish ¢ 😼  02:19, 9 March 2021 (UTC)
  • Oppose move on the basis that we already have too much churn in citation template parameter names and too many robots cluttering up our watchlists with too many edits changing working parameter names to other parameter names, and this will lead to many more of the same wasteful, useless, and distracting edits. —David Eppstein (talk) 17:00, 8 March 2021 (UTC)
    Not a valid rationale. This has nothing to do with (and will have no effect on) bots changing parameter names. You're making an argument like "I hate cats because a dog bit me once, so all small furry things must be bad."  — SMcCandlish ¢ 😼  02:09, 9 March 2021 (UTC)
    Are you being deliberately obtuse? Changing the canonical name of the template is likely to lead to requests by the bot-people to allow their bots to go through articles and make the same change to those articles, just as changing the canonical name of some parameters has led to the same sort of make-work changes by bots. —David Eppstein (talk) 02:48, 9 March 2021 (UTC)
  • Oppose: The current template title is stable and the proposer has had an option to withdraw at this point. Where one wishes to cite a live presentation, one has {{cite AV media}}. I might even suggest that one could use {{cite AV media notes}} if one wanted to cite the presentation itself (the "slides", as they usually go). But the point of the template is neither of those two items but instead to cite the proceedings and the articles/papers contained therein. There are many hills one might die on regarding CS1/2, but this ain't one of them. (I would entirely prefer if this template simply disappeared and any necessary parameters added to {{cite journal}} given what they are citing, but that is neither the proposal on the table nor proposed by the proposal mechanism used here.) --Izno (talk) 03:14, 9 March 2021 (UTC)
  • Oppose: As others have remarked/hinted, the source that the template cites is the entire published conference proceedings (the "conference"). A conference presentation that assumes a publishing life of its own can be cited with the template appropriate for that situation. If that is not the case, it should be cited as a location within the source. (talk) 05:39, 9 March 2021 (UTC)
  • Oppose per Izno. --NSH001 (talk) 02:07, 14 March 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Please autolink the title when |hdl= and |hdl-access= are provided similar to how it works with a supplied |doi=. Please add hdl as an option for |title-link= with |hdl= for cite journal. It would be useful if the combination of |hdl=, |hdl-access=, and |title-link= worked for cite report, techreport, or web too. Thank you. --Whywhenwhohow (talk) 04:30, 8 March 2021 (UTC)

The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present. The existence of the paramaters |doi-free= or |hdl-free= should cause the doi or hdl to have priority and be used instead of the pmc for the title link. --Whywhenwhohow (talk) 23:59, 8 March 2021 (UTC)
What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)
For the articles you edit? Add the url you want to link as the |url= parameter. That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don't have to try to understand or remember it. —David Eppstein (talk) 06:14, 26 March 2021 (UTC)

Obtuse template styleEdit

Why are volume, number, and page labels suppressed in {{cite journal}}? For example, volume=5 number=37 page=17 renders as an inscrutable 5 (37):17. Why not show vol: and p: ? There is also an inconsistency. For example, if {{cite news}} or {{cite web}} are used, page does display as "p." and pages as "pp."  JGHowes  talk 18:26, 12 March 2021 (UTC)

Because outside of Wikipedia, scholarly and academic journals commonly use that style so cs1|2 reflects that. {{cite journal}} has used this style since it's very early days. There has been some discussion, on and off, about changing that.
Trappist the monk (talk) 18:43, 12 March 2021 (UTC)
The last planning discussion and the last unplanned discussion. I'm pretty close to starting an RFC, just need to get some stuff written down. --Izno (talk) 19:45, 12 March 2021 (UTC)
I don't know for cite journal but {{cite book}}, if you put anything besides a plain number in |volume=, it isn't bolded, ex. [1], so there's that. I mean, it shouldn't be much of a problem changing the journal template so it displays "vol. x"; but again it's really a minor issue of citation style and so long the source is uniquely identifiable we shouldn't be worrying too much about that. RandomCanadian (talk / contribs) 20:10, 12 March 2021 (UTC)
That happens because you wrote |volume=vol. 1 which value causes Module:Citation/CS1 to render no-bold-volume because the value is five-characters in length. You should not be doing what you did. It is the responsibility of the templates to format the values supplied in parameters when the citation is rendered. If this discussion or some other discussion leads us to change how {{cite book}} renders |volume= so that it renders as 'vol. <volume value>', your citation will then render as 'vol. vol. 1.' and someone will have to fix it. Please don't include extraneous text in cs1|2 parameter values.
Trappist the monk (talk) 20:31, 12 March 2021 (UTC)
That was very much an intentional work-around because I'm personally not happy with that formatting - I have seen it used for journals but not for books. RandomCanadian (talk / contribs) 20:39, 12 March 2021 (UTC)
With all respect, is it not simpler to not use CS1 templates? Then you format the citation the way you see fit. The rationale behind emphasizing the volume was to make people aware that this is a multi-part source, the search for which does not end with locating the title, one should dig deeper to find the appropriate part. Bold weight is used as emphasis to distinguish from the emphasis given to the title, which is in italic type. And obviously the template rendering of the volume parameter is confusing and contradictory, and the instructions are inadequate. I would use a freehand citation rather than trying to figure out the nonsensical. (talk) 01:09, 13 March 2021 (UTC)
The only problem with doing a freehand citation is that, if you're trying to get the article promoted to GA or FA, you're likely to encounter objections to inconsistent citation formatting.  JGHowes  talk 01:30, 13 March 2021 (UTC)
Not using citation templates is a bad thing, IMO, in particular if it is only for stylistic reasons. If there is a demand to support something that our current templates do not allow for, the templates should be improved rather than not used.
--Matthiaspaul (talk) 13:14, 13 March 2021 (UTC)
Templates are forms. Would you ever use a form that requires you to enter your name in uppercase if it is more than 5 characters long and in lowercase otherwise? This is not just bad template design, it is lacking sense. The module should emit the error "do not use - illogical" (in red letters of course). Just in case people think that this just popped up, it hasn't. It has been pointed out for years. (talk) 15:23, 14 March 2021 (UTC)
Templates are also functions. If used, they add value (like more consistent formatting of citations in articles, central maintenance, error checking, machine readability and meta-data generation). These features directly or indirectly help to improve the quality of the content we provide, and also help a multitude of other projects).
Regarding the error message, as you can see below, we are just in the process to add it.
--Matthiaspaul (talk) 17:21, 14 March 2021 (UTC)
Functionally, these are editor-, not administrator/programmer helper-templates. The various quirks & the nonsense do not age well. (talk) 02:45, 15 March 2021 (UTC)
The above caused me to wonder how often |volume=vol. ... is used in {{cite book}}. This search says that there are 14.5k+ articles with malformed |volume= parameters (search times out). Of those, some 1400ish are roman numerals (also times out). For comparison, there are about 72kish articles that use {{cite book}} with |volume= values that do not begin with 'V' or 'v' (and yes, times out).
If we are going to look at |volume=, we should also look at |issue= even though {{cite book}} doesn't support |issue=: ~100 (timed out).
Switching to {{cite journal}}, same searches, just different template name gives inconclusive search results (all timed out) so making any judgement based on these is pretty much pointless:
|volume=[Vv][Ii]* *[\|\}]~1450
What I think can be said is that like |page= and |pages=, we should be trapping |volume= and |issue= when these have some form of extra text that looks something like the parameter's name.
Trappist the monk (talk) 23:03, 12 March 2021 (UTC)
And I have hacked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to implement this. A single function does both |volume= and |issue=. The tests are case insensitive and look for various volume and issue designators:
|volume= value begins with:
vol (with or without terminal dot)
v. (requires terminal dot because 'v' can be an allowed Roman numeral)
|issue= value begins with:
iss (with or without terminal dot)
i. (requires terminal dot because 'i' can be an allowed Roman numeral)
no (with or without terminal dot)
Are there other patterns that we should look for?
Trappist the monk (talk) 23:45, 13 March 2021 (UTC)
I added
nr (with or without terminal separator)
Rarely, I have also seen a colon (:) used instead of a dot (.), therefore I have added : and = as separators detected.
I think, we should move the patterns to /Configuration for easier localization.
Cite journal comparison
Wikitext {{cite journal |number=I.3 |title=Title |volume=Vol:3 |journal=Journal}}
Live "Title". Journal. Vol:3 (I.3). |volume= has extra text (help); |number= has extra text (help)
Sandbox "Title". Journal. Vol:3 (I.3). |volume= has extra text (help); |number= has extra text (help)
--Matthiaspaul (talk) 15:29, 14 March 2021 (UTC)
I tweaked the single-character patterns ('v', 'i', 'n') so that they catch <char><space>. Whitespace is trimmed from parameter values before delivery to the module so these tweaks catch |volume=V 123 etc.
Keeping the patterns local to the function until we settle on what the code will be doing is better for now. Yeah, should be moved before the next sync.
Trappist the monk (talk) 16:31, 14 March 2021 (UTC)
Added plural forms "volumes", "vols", "numbers", "nos", "issues" (plus variants). Rarely seen, but given that we support parameter ranges, they could occur.
Cite journal comparison
Wikitext {{cite journal |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
Live "Title". Journal. I–II (3, 5).
Sandbox "Title". Journal. I–II (3, 5).
Cite journal comparison
Wikitext {{cite journal |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
Live "Title". Journal. vols. I–II (nos. 3, 5). |volume= has extra text (help); |number= has extra text (help)
Sandbox "Title". Journal. vols. I–II (nos. 3, 5). |volume= has extra text (help); |number= has extra text (help)
Cite magazine comparison
Wikitext {{cite magazine |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
Live "Title". Journal. Vol. I–II no. 3, 5.
Sandbox "Title". Journal. Vol. I–II no. 3, 5.
Cite magazine comparison
Wikitext {{cite magazine |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
Live "Title". Journal. Vol. vols. I–II no. nos. 3, 5. |volume= has extra text (help); |number= has extra text (help)
Sandbox "Title". Journal. Vol. vols. I–II no. nos. 3, 5. |volume= has extra text (help); |number= has extra text (help)
--Matthiaspaul (talk) 18:51, 30 March 2021 (UTC)
If some form of the RFC below is to run, deferring action on these cases until afterwards might create less friction. It might happen, for example, that the RFC removes the issue that these forms were created to work around, in which case no-one will miss them. Kanguole 15:35, 14 March 2021 (UTC)
Doesn't matter. cs1|2 is responsible for the annotation used when rendering |volume= and |issue=. These tests catch inappropriate volume and issue annotations in the parameters' assigned values. Inappropriate extra annotations will always be inappropriate regardless of the outcome of an rfc (if there is an rfc).
Trappist the monk (talk) 15:44, 14 March 2021 (UTC)
I am hopeful that these messages will be hidden maintenance messages when they are initially deployed. Given the current discussion about hyphens at VPP, it would behoove us to avoid being tone-deaf to editors' concerns about error messages and changes to the CS1 templates based on limited discussions. – Jonesey95 (talk) 04:36, 15 March 2021 (UTC)

Draft RFCEdit

I have written up a a draft RFC over the past couple hours based on the previous planning done. Happy to see feedback on wording changes, bold tweaks, etc. --Izno (talk) 22:44, 12 March 2021 (UTC)
It is well thought-out and nicely depicted. But in this form, you will be able to hear the collective editor head-scratching across the internet. Not to say that I know how to make it simpler. I would subjectively slant the argument in favor of easily recognizable consistency, and damn the experts. Render a page "page/p", issue "issue/no" and volume "volume/vol". Then sit back and enjoy less fruitless discussion. (talk) 01:23, 13 March 2021 (UTC)
I appreciate the effort, but, I think, in this form it is too complicated for an RFC, and, giving readers almost complete freedom of choice, it will be difficult to derive a clear picture from the answers.
I think, what we actually seek is community input to get a better understanding on the community's general preferences, whereas, while adjusting the templates according to the outcome of the RFC, sorting out the corner cases and nitty-gritty details can be left to later local discussions. Hence, in order to keep things as simple as possible for them (so they get the general picture), we should not discuss in this RFC:
  1. Which parameters should be actually supported by which template
  2. Considerations in regard to publications which have both number and issue designations
  3. Minor style variations between singular and plural forms, lists and ranges
  4. If we should add commas between the values in "abbreviated" style or not
  5. If volumes should be presented in boldface in "scientific" or "symbolic" style or not, or leave it conditional on length and internal format
(For most of these questions we don't actually need wide community input, except for, perhaps, the last one. Where necessary, these topics can be addressed in subsequent local discussions.)
Thereby, the styles to choose from can be boiled down to four major variants, with #1 and #3 being the most important ones (where V is a placeholder for the volume, N a placeholder for the issue number, P a placeholder for the page info, and all other letters and symbols elements of the style itself):
  1. "Scientific": V (N): P. Example: 15 (11): 14–23.
  2. "Symbolic": V (N), pp. P. Example: 15 (11), pp. 14–23.
  3. "Abbreviated": Vol. V no. N. ... pp. P. Example: Vol. 15 no. 11. ... pp. 14–23.
  4. "Full": Volume V, number N. ... pages P. Example: Volume 15, number 11. ... pages 14–23.
The two main questions that need be answered:
  • Should all templates switch to use one of these styles for consistency or should the templates continue to use different styles depending on the publication type? If all should use the same style, which one of these four? When only a particular template should switch to a different style, the readers can mention this as well, but asking for the preferred style of each template individually would unnecessarily overcomplicate things.
  • Should there be a way to override the default style used by a template (like through a |periodical-style=scientific/symbolic/abbreviated/full parameter - parameter name and keywords are only working handles, the actual names could be discussed locally later on). This would allow editors to enforce consistency of style within an article even if the templates would continue to have different default styles, or to switch to a different presentation style where desirable (f.e. to have some means to use "scientific" style in a heavily scientific article even if the templates would use "abbreviated" style by default.)
--Matthiaspaul (talk) 13:14, 13 March 2021 (UTC)
I share the concern that the proposed four questions are likely to start a wide-ranging discussion from which it will be difficult to extract concrete actions. It might be more fruitful to present a short menu of choices, and ask for people's preferences. Moreover, I think previous discussions have identified three clear options:
  1. status quo
  2. 1 (2): 34–56 for journals, and vol. 1, no. 2, pp. 34–56 for everything else (though issue/number tends to be a journal thing)
  3. vol. 1, no. 2, pp. 34–56 for everything
Some people argued for fully spelling out "volume", "number" and "pages" – perhaps that could be a second question.
I don't think it would be a good idea to offer more formatting option parameters. Kanguole 14:31, 13 March 2021 (UTC)
Regarding an option to override the default format, I am generally a proponent of consistency but I also acknowledge that some people might have deviating needs in specific articles. The idea of such a parameter is to make it easier for them to vote for a standard default format in an RfC even if this is not their preferred format as they could still override the default where actually needed. Thereby the outcome of the RfC will have more chances to be accepted by the community as a whole. Achieve more consistency in general by default, and still keep everyone happy. Friendlier place, better project outcome. --Matthiaspaul (talk) 17:21, 14 March 2021 (UTC)

My comment on that RFC is that it's overwhelming and overloaded with information and options.

  1. The table should have only a single column with displaying all supported parameters (VIP for journals, VP for books, P for arxiv, I for podcasts, etc...).
  2. The RFC should be specifically about explicit (abbreviated Vol. 1 no. 2 p. 3) vs implicit (bolded and positional 1 (2): 3). Leave capitalization issues out, since that should just be made consistent with grammar rules (Vol. 1. No. 2. P. 3. with dotted separations or Vol. 1 no. 2 p. 3 / Vol. 1, no 2., p. 3 with no or comma separators, with Vol. being capitalized or not depending on it following a dot separator or not).

Headbomb {t · c · p · b} 15:26, 13 March 2021 (UTC)

Answering no-one in particular, but trying to cover the commentary:

  1. I am not in favor of custom switches. I will not propose it and I will attempt to make it clear in the RFC that that is not on the table. Adding customization in these templates deliberately works against any reason or rationale to have an RFC.
  2. I am interested in nitty-grittys. The community never gets to a consensus with some vague "Wikipedia should do this" which is +-'d by the community because the community always brings up the nitty-grittys separately in some unstructured way, rather than being invited to comment directly.
  3. I appreciate that there is a lot of leeway given in the questions. I do agree that some information (the bullets as listed by Matthias, perhaps besides the last bullet) is presented but is not part of the core question. I will attempt to make that clearer. (Ordering of the parameters in a specific citation is another one? I am not sure. Commas another -- I don't necessarily agree that volume - number needs a comma between, but it's a point of appearance that given we still can't get rid of CS2 [he displays his clear bias] is likely open to disagreement.)
  4. I deliberately have given the community leeway. If they want to go "boldface volume, with page indicator, as in cite book, for all templates, or all templates beside cite journal", that should be their choice. The community is going to get into such questions whether I want it or not just because of the sensitivity of citations.
  5. No, I do not think previous discussions have illustrated any particular preferred choices. I think we have some templates that look the way they do, and some previous discussions about how some templates should look, but none which have examined the set systematically. I do have faith in the community however, that the majority of the community will hew to the general look and feel of the templates today rather than propose crazy styles.
  6. I considered presenting the table in one column or similar. The problem is that not all templates will have all parameters filled and readers may be interested in how templates will look other. Cite journal is perhaps alone among the set that can be expected to be filled in for all 3 parameters on a regular basis, and even then I suspect it would not take long to find counterexamples.
  7. Overall density of information: I don't want to make people hunt for what it looks like today or what the templates do in the aggregate. I don't expect loud complaints if that information is missing, but I do expect complaints. Open to suggestions, specific reduction points (taking into account some 'don't talk about this stuff' to be added as indicated), or even someone else forking their own draft for comparison.

--Izno (talk) 03:27, 21 March 2021 (UTC)

OK, I've reworked the questions. I found I hated how I had asked the original questions because I could see them leading to a lot of unstructured answers. Are the new questions better for that? Izno (talk) 19:54, 11 April 2021 (UTC)

"I don't see a reason for that"Edit

Please be more specific than WP:IDONTLIKEIT, User:Izno. Thank you CapnZapp (talk) 18:44, 15 March 2021 (UTC)

"I don't like it" and "I don't see value in your addition in this context/on this page" are not equivalent. --Izno (talk) 20:34, 15 March 2021 (UTC)
No, Izno - you do not get to revert content without an explanation. I have started this talk section for you to explain what you mean by "I don't see a reason for that". And the fact you don't happen to see "value" in my addition is not sufficient. Am I supposed to read your mind? Or just try rewording over and over until I happen to find a version you deign to allow? CapnZapp (talk) 11:49, 16 March 2021 (UTC)
I think the users below have covered my reasons for reversion sufficiently. Izno (talk) 03:31, 21 March 2021 (UTC)
This discussion appears to refer to Help:Citation Style 1#Using_|format=; particularly this addition and the subsequent revert. For me, I'm not convinced that the addition is required because it is not clear to me how regular editors benefit from the added text.
Trappist the monk (talk) 12:19, 16 March 2021 (UTC)
If we assume that an editor will turn to a help page to quickly find concise, up-to-date, focused pointers, then the reverted note is dead weight. I am not discussing the merits of its content, just that, imo, it is out of place in a page that purports to be a practical guide. (talk) 04:18, 17 March 2021 (UTC)

ISO datesEdit

Can we add support for long ISO dates, e.g. 2021 March 16? — kwami (talk) 01:43, 17 March 2021 (UTC)

Umm, that isn't an ISO 8601 date format. cs1|2 adheres as closely as it can to MOS:DATES; when MOS:DATES allows YYYY Month dd date format, cs1|2 will follow.
Trappist the monk (talk) 02:10, 17 March 2021 (UTC)
Related discussion: Wikipedia_talk:Manual_of_Style/Dates_and_numbers#ISO_8601
--Matthiaspaul (talk) 17:00, 11 April 2021 (UTC)

Help:Citation Style 1/test problemsEdit


Something has caused this page to now have the red link category Category:CS1 errors: extra text: issue. I can't find a recent edit that would cause this category to appear. Can anyone help either fix this so the nonexistent category doesn't show up on error lists or create this category if it is now needed? Thank you. Liz Read! Talk! 05:06, 18 March 2021 (UTC)

Thanks. This is probably a temporary issue caused by the (still incomplete) preparations to add extra text warnings to |issue=, |number= and |volume= according to this thread: Help_talk:Citation_Style_1#Obtuse_template_style
--Matthiaspaul (talk) 11:09, 18 March 2021 (UTC)
Was even simplier: The example at Help:Citation Style 1/test problems contained |issue=Issue but was missing the |no-tracking=yes parameter causing the categorization now that we added the "issue" extra text warning to the template. --Matthiaspaul (talk) 18:36, 19 March 2021 (UTC)

References listed by editor of the book, but Bibliography lists by author of the chapterEdit

I'm citing a chapter with a specific author in a book that has another person as the editor, and I'm seeing that the Harvard citation cites the book by the editor's last name in the References section and by the chapter author's last name in the Bibliography. Is there a way to fix this, or has it not been a problem for anyone? Danaphile (talk) 23:48, 19 March 2021 (UTC)

When creating a CITEREF anchor, cs1|2 always uses the author name(s) if available; if not, it falls back on the editor name(s). If you only need to cite one author's work from an edited collection, rewrite the cs1|2 template to include the author and the author's contribution. If you need to cite the contributions of multiple authors from an edited collection, omit author names from the cs1|2 citation and for each author contribution add {{harvc}}. In the article text then, the {{sfn}} (or {{harv}}) template has the author name and links to the appropriate {{harvc}} template which, in turn, links to the cs1|2 template.
An example: here are a pair of {{sfn}} templates.[1][2]


  1. ^ Blue 2021, p. 13.
  2. ^ Greene 2021, p. 45.
And a {{cite book}} template and two {{harvc}} templates in §Bibliography:
  • Black, ed. (2021). All about Colors.
    • Blue. "Why Blue is the best color". In Black (2021).
    • Greene. "Green is better than Blue because it has Yellow". In Black (2021).
Trappist the monk (talk) 00:20, 20 March 2021 (UTC)
Thanks for this pointer to {{harvc}}. This is extremely useful when citing encyclopedias, and I didn't know about this until now. {{sfnm}} is another that I came across only recently. Is there a list somewhere of the family of sfn/harv templates? -- Michael Bednarek (talk) 03:55, 21 March 2021 (UTC)
Template:Sfn § Author–date citation templates is the only list that I know of.
Trappist the monk (talk) 11:28, 21 March 2021 (UTC)

Reference and Bibliography?Edit

Is there a simple way to add e.g. {{cite journal}} just once either as an inline <ref> or in the Bibliography section and invoke it by name in the other occurrence? It seems fragile to have to include it twice. Urhixidur (talk) 11:34, 23 March 2021 (UTC)

{{sfn}}/{{sfnp}} do that. You give the full citation, with the full page range of the article, in the bibliography and have short references with the specific pages at each use. Kanguole 11:41, 23 March 2021 (UTC)
See WP:REFNAME. – Jonesey95 (talk) 15:17, 23 March 2021 (UTC)

Report styleEdit

{{cite report}} should, like {{cite journal}} and others, quote the title instead of just spitting it out in Roman letters. Urhixidur (talk) 13:03, 23 March 2021 (UTC)

{{cite report}} is the way it is because that was the way it was created all those many many years ago. For the discussion that occurred around the time that I migrated {{cite report}} from {{citation/core}} to Module:Citation/CS1, see Help talk:Citation Style 1/Archive 6 § Cite report.
Trappist the monk (talk) 13:27, 23 March 2021 (UTC)
We talk about cite report on occasion. Please take a look at the archives. Izno (talk) 14:28, 23 March 2021 (UTC)

Finding errors in Vancouver namesEdit

Based on an offwiki discussion about how difficult it is to find errors in Vancouver names listings, I have modified the sandboxes such that they report an nth name containing the error. It is a first cut and I welcome 'better' changes. Particularly, I am not sure of the best way to deal with vauthors versus veditors and vauthors versus name list (and the combination) - it may not be particularly important though. The interested coder may wish to modify the particulars being reported by the module.

Adding "in name X" may also be better before the colon rather than after. I have no strong opinion on that point but I'm kind of liking it after rather than before.

Interested readers can review Module talk:Citation/CS1/testcases/errors at test_vancouver and test_vauthors. Izno (talk) 02:42, 27 March 2021 (UTC)

DOIs greater than 10.49999Edit

Hello! There now appear to be valid DOIs with prefixes of 10.50000 and above (cited, for instance, here) but these cause the templates to flag them for checking ("Check |doi= value (help).") Should the templates be amended not to flag the 10.50000–10.59999 range? Thanks! —Collint c 16:10, 28 March 2021 (UTC)

Already been fixed in the sandbox.
Trappist the monk (talk) 16:18, 28 March 2021 (UTC)
Since January. It should not take several months to roll out routine limit increases on identifiers. Headbomb {t · c · p · b} 16:25, 28 March 2021 (UTC)
They still produce a link and the error message can be suppressed with ((...)) around the DOI per Help:Citation Style 1#Accept-this-as-written markup. A search [2] currently finds seven working DOI doing that:
An edit to Module:Citation/CS1/Identifiers forces 4.8 million pages to be rendered so it shouldn't be updated too frequently either. PrimeHunter (talk) 18:55, 28 March 2021 (UTC)
We have a pretty big stack of changes ready to go in the sandbox. We should probably update the live modules, or at least post a list of the changes and discuss whether we want all of them to go live. Once every couple of months shouldn't put a heavy load on the servers. – Jonesey95 (talk) 02:27, 29 March 2021 (UTC)
Right now updates are quarterly, usually early in months 1/4/7/10. Headbomb is just annoyed because he hasn't tried to get/gotten consensus to make it more often. Izno (talk) 04:33, 29 March 2021 (UTC)
I am annoyed because this template is controlled by a small minority of people that can't be arsed to update the template when it needs to be updated. There is zero reason or consensus to have these updates happen once every 43 centuries. Show me the consensus for that. Headbomb {t · c · p · b} 19:03, 29 March 2021 (UTC)
If you had just started the RFC the last time we talked about this, you might have edits happening more often than quarterly. Izno (talk) 19:08, 29 March 2021 (UTC)
Thanks all, I appreciate the info and work! —Collint c 18:35, 29 March 2021 (UTC)
In my humble opinion it does not make sense to set upper limits on ids for validation. How often will that actually help editors? And how often will it raise false alarms because the bound is outdated? And how much trouble is it to maintain, when edits to the module trigger huge rendering backlogs? Keep it simple, spare everyone's time and just remove those limits. − Pintoch (talk) 09:23, 31 March 2021 (UTC)
I see good arguments pro and con those limits. One possible way to solve the problems would be to make the limits "self-serviceable", that is, to create a special limits configuration file, which would allow to override the internally defined limits (only) in the upward direction. This file should not be protected, so that it can be edited by anyone (except for, perhaps, IPs), so that virtually any editor running into a limit could (guided by the help section linked to in the error message) edit the file and increase the limit. Occasionally, a vandal might try to sabotage the limits by setting too high or too low values, but for as long as the limits cannot be set to lower values than those defined internally (if so, they would just be ignored by the module), and for as long as reading a possibly syntax-trashed limits file does not provoke any Lua errors, no actual harm could be done, except for that the limits would be effectively disabled temporarily. Whenever the module suite gets updated, the internal limits would be updated to reflect the limits defined in the limits file (plus some margin). The overhead to implement such a scheme should be small, but it would reduce necessary maintenance to a minimum and eliminate the need for those frequent "please update the limit" threads. Best of both worlds?
--Matthiaspaul (talk) 13:28, 31 March 2021 (UTC)
@Matthiaspaul: I do not think that changing the permissions needed to edit those limits would solve the problem that re-rendering all the pages that rely on it is costly. − Pintoch (talk) 14:38, 31 March 2021 (UTC)
That's true if it would happen very frequently (say, every couple of days). But we have been indicated by site admins in the past that occasional updates (say, once a week or every couple of weeks) are not actually a problem.
However, updating the whole module suite at that fast pace would make it more difficult to find and fix errors before changes go live and it would also be too much maintenance overhead, not only for the update itself but also for the gnomish actions that typically happen in preparation for an update and immediately afterwards. Documentation needs to be kept in sync as well. So, I think, it's good that we have longer semi-static times between the updates for things to settle - if, in the live system, everything would be in flow all the time, it would be more difficult to spot issues.
Personally, I think, the updates of the module suite should not happen more often than every two months, but I am also happy with the current three-month scheme. Maintaining some semi-fixed schedule helps to give structure to the project. However, bug fixes for frequently occuring non-trivial issues should be rolled out whenever they become available in order to not annoy a lot of readers longer than necessary. And limit updates could happen much more often as well, because we have meanwhile an infrastructure (with help pages updating automatically) making it very easy to implement them, and by just changing a number there is (almost) no risk to introduce new bugs. Most readers won't have recognized this because it mostly happened silently, but starting this year Trappist actually moved some bug fixes and limit updates to the live system shortly after they became available in the sandbox. So, some of the changes implemented after the last module suite update are in fact already live. I think, this is a good solution, but given the frequently necessary limit updates this could become tiresome over time.
Therefore, I think, something along the line of my proposal could be actually a solution.
--Matthiaspaul (talk) 16:59, 31 March 2021 (UTC)

Automating URL access tagsEdit

A few of us on WP:Discord have been chatting about the potential for automating the URL access parameter on this citation. Floydian suggested building a Lua dataset that has a bunch of URLs for frequently-used online sources, and then having {{Citation}} automatically assign the URL access tag associated with that website if a manual one is not provided. This wouldn't work for all sources, as some surely have multiple access levels or other confounding factors, but even if we can only use it for a subset of sources, it'd help get these parameters used a lot more widely and kept up to date better as paywalls are raised/lowered, and we could make the system more advanced over time. What do you all think? {{u|Sdkb}}talk 02:18, 31 March 2021 (UTC)

Adding on a bit, the datasets would essentially be URL lists, similar to the whitelists and blacklists we use, that would assign those base URLs as, say: subscription, registration, free, sites that are two or more of those, and possibly another category for sites known to be free in certain locations. - Floydian τ ¢ 02:21, 31 March 2021 (UTC)
I assume you have in mind external code that is called by the module when these parameters are set, so that the relevant processing is offloaded. An editor override should be an option. In general, because humans should should have control over all processes, and in particular because access status may restate faster than database updates. (talk) 03:15, 31 March 2021 (UTC)
Yes, the way this would work is that if someone used {{citation|}}, it'd use the database entry for to display the padlock, but if someone used {{citation||url-access=free}}, it'd override. {{u|Sdkb}}talk 03:27, 31 March 2021 (UTC)
"URL lists, similar to the whitelists and blacklists" We already have a database for this: Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 8 April 2021 (UTC)
I appreciate the intention but we should think twice about adding hard-coded lists like this - it will be significant work to maintain. I am concerned by the rising complexity of this module and the sustainability of its maintenance. Would you consider adding support for this in a bot instead? We already do quite a lot of tagging with User:OAbot, this sort of tagging would easily be in scope for it. Also I suspect not that many domains can be considered as mostly paywalled, with the generalization of hybrid open access among scholarly publishers, so it's not clear to me it would be that useful in practice. Perhaps you have specific domains in mind? − Pintoch (talk) 09:30, 31 March 2021 (UTC)
Pintoch, I don't have a strong opinion about whether we should do automation via a bot or something else, just that if we want the tags to appear widely outside of GAs/FAs, there should be some sort of automation. Maintaining a database of URLs with their statuses is a lot less work than maintaining references individually, since each website is likely used hundreds or thousands of times. I don't have specific domains in mind, although I think big newspapers might be a good place to start. {{u|Sdkb}}talk 10:00, 31 March 2021 (UTC)
@Sdkb: then I would warmly invite you to carry out this project via WP:OABOT. If you want to curate the list of paywalled sources I am sure we can find someone to add the relevant Python code there to make it work. It should be a lot easier to get this through BRFA than to implement this in the citation modules. − Pintoch (talk) 14:41, 31 March 2021 (UTC)
My gut reaction to this proposal is that it will be just one more thing over which editors will squabble. What to do when the base url can be free and can be subscription? Who is to be tasked with designing and maintaining this database? If the goal of this proposal is to help get these parameters used a lot more widely, how does automatic application of the access icon further that goal? Module:Citation/CS1 cannot rewrite article wikitext so editors looking at wikitext will never see |url-access= except when it has been added to the citation template by a human or by a bot.
Trappist the monk (talk) 10:59, 31 March 2021 (UTC)

edtf date formats as cs1|2 date parameter values (2)Edit

The original discussion is at Help talk:Citation Style 1/Archive 33#edtf date formats as cs1|2 date parameter values and at the same phabricator task: T132308. The EDTF standard is here.

In that phabricator task you can see that citoid will soon be returning month and year dates in the EDTF format: YYYY-MM-XX where the XX are literal characters that act as placeholders for unspecified days. Citoid is currently returning these dates in the YYYY-MM format which is incompatible with MOS:DATE.

Because of T132308, I have resurrected the 2017 code that I wrote for the EDTF format, tweaked a bit to accommodate intervening changes in Module:Citation/CS1/Date validation.

Citoid will give us cs1|2 templates with dates that look like this when the source gives month and year dates:

{{cite book/new |title=Title |date=2021-03-XX}}
Title. March 2021.

Trappist the monk (talk) 23:56, 31 March 2021 (UTC)

Thanks for tracking that task for us. – Jonesey95 (talk) 00:01, 1 April 2021 (UTC)
Citoid should really be brought inline with the MOS here. Headbomb {t · c · p · b} 01:10, 1 April 2021 (UTC)
100% support from my side. :thumbsup: --Matthiaspaul (talk) 10:14, 1 April 2021 (UTC)

module suite update 10–11 April 2021Edit

I propose to update cs1|2 module suite over the weekend 10–11 April 2021. Here are the changes:


  • Add support for emojis with zero-width joiners; discussion
  • Fix err_parameter_ignored and err_parameter_ignored_suggest message display for parameters not supported by some templates (like {{cite biorxiv}} / {{cite citeseerx}} / {{cite ssrn}}) but matching suggestions (as patterns or individual rules); discussion
  • Add parameter name to err_extra_text_pages message
  • Add err_asintld_missing_asin, err_doibroken_missing_doi, err_embargo_missing_pmc error messages for missing |asin= / |doi= / |pmc= parameters; discussion
  • Refactor style and ref functions
  • Emit maintenance message when the value of |ref= equals the default value; discussion
  • Emit maintenance message when |postscript= is longer than one character; discussion
  • i18n support for year/date mismatch; discussion
  • separate {{cite AV media}} / {{cite AV media notes}} |others= maintenance cat from other template's |others= maintenance cat; discussion
  • revert "helpful" dash conversion; discussion
  • revise |display-<names>= error messaging; discussion
  • add position to Vancouver errors; discussion
  • support edtf uncertain date format; discussion


  • Remove no longer used parameter |name-list-format=; discussion and discussion
  • Add parameter name to err_extra_text_pages message
  • Add err_bad_asin_tld message for unknown |asin-tld= values; discussion
  • add COinS support for |ol= and |asin=; discussion
  • Add err_asintld_missing_asin, err_doibroken_missing_doi, err_embargo_missing_pmc error messages for missing |asin= / |doi= / |pmc= parameters
  • Emit maintenance message when the value of |ref= equals the default value;
  • Emit maintenance message when |postscript= is longer than one character;
  • Add support for emojis with zero-width joiners;
  • i18n support for year/date mismatch;
  • separate {{cite AV media}} / {{cite AV media notes}} |others= maintenance cat from other template's |others= maintenance cat;
  • add another generic title; discussion
  • revise |display-<names>= error messaging;
  • |ismn= COinS bug fix; discussion
  • add position to Vancouver errors
  • allowed plural forms of extra text patterns for volumes, issues and numbers; discussion


  • remove no longer used parameter |name-list-format=; discussion and discussion
  • deprecate |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=; discussion
  • remove support for deprecated parameters |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |sectionurl=, |seriesno=, |timecaption=, |titlelink= (deprecated on 2021-01-09; all instances removed from categorized namespaces as of 2021-02-10)
  • added after this post, applied to live module 10 April: Mark |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= as "discouraged" parameters per RFC; discussion

Module:Citation/CS1/Date validation

  • i18n support for year/date mismatch;
  • support edtf uncertain date format;


  • bump doi five-digit-without-subcode limit to 59999; discussion
  • error for asin with isbn-10; error for isbn-10 begins with 630 or 631; discussion
  • add check for allowed |asin-tld= values; add allowed tlds; discussion
  • add COinS support for |ol= and |asin=;
  • switch to 'PATH' encoding for identifier ext links; discussion
  • fix access level error messaging; discussion
  • suppress COinS for erroneous identifiers; discussion


  • add COinS support for |ol= and |asin=;


  • add hint for removed parameter |name-list-format=;

Trappist the monk (talk) 17:28, 3 April 2021 (UTC)

  • Regarding err_doibroken_missing_doi, the linked discussion does not mention doi.
  • What specifically is meant by "Refactor style and ref functions"?
  • It would be best to hold off on further deprecations based on hyphenation until the closure of the Village Pump RfC
  • As per the linked discussion for "Emit maintenance message when the value of |ref= equals the default value", the value of the proposed change is unclear.
Nikkimaria (talk) 19:19, 3 April 2021 (UTC)
Style/ref functions was not user-facing. This is why the word 'refactor' was used.
I do not see a reason to stop removing deprecated, and to stop deprecating, dash versions of parameters where the dash versions have essentially already been removed (whether so because they were deprecated and removed or because there were so few in the wild that no-one was using them). I make no comment on the RFC and its associated parameters; the RFC essentially did not discuss the parameters identified above, however it closes.
"ref equals default value": It identifies citations which do not need |ref= which means additional wikitext clutter can be removed. That seems sufficient to me, and I said as such originally. What do you find unclear? Izno (talk) 21:44, 3 April 2021 (UTC)
Why this is a necessary or beneficial change. The linked discussion provides some reasons why an editor may have chosen to include such values. Additionally the RfC, while not focused specifically on these parameters, raises questions as to the wider practice of deprecating unhyphenated aliases following on an RfC that did not intend or require same. Nikkimaria (talk) 00:37, 4 April 2021 (UTC)
... Additional wikitext clutter can be removed is sufficient to be a necessary and beneficial change. One of the discussion points since forever is that citations clutter wikitext. This change removes one point of clutter. I have not been reverted where I have removed |ref=default_value. My speculation is that the people using |ref=default_value (either hardcoded or with {{sfnref}}) either wrote the articles prior to |ref=harv or did not know about |ref=harv or do not know that neither |ref=default_value nor |ref=harv are necessary any more. I see all three as far more likely than editors deliberately adding these just to meet one or another of MP's speculations as stated in that discussion.
Here are some more reasons to remove it even though I think the prior was sufficient:
  1. As mentioned therein, the harv keyword is also deprecated as it is the default behavior for all templates, so this change also makes the templates more consistent i.e. you only need |ref= if you need to set something to a non-default (mostly when you have no authors or editors). This makes teaching new and old users easier.
  2. Having unnecessary |ref=default_value serves to confuse new editors who may think it is always or even sometimes necessary, when it is strictly not.
Now, do you sincerely believe that one of the qualities in MP's speculations was actually of interest and moreover that it is sufficient to override the clutter and unteaching new users and consistency points? I do not believe any of his points are of sufficient interest or are clearly lacking in evidence. Be specific in your answer to what you think is more important, rather than pointing to unspecific comments on his part. Izno (talk) 02:12, 4 April 2021 (UTC)
|doi-broken-date= without |doi= has been an error since the 3 September 2019 update. That update used doibroken_missing_doi which was changed to err_doibroken_missing_doi at the 10 October 2020 update. Here is a simple example template that shows that |doi-broken-date= without |doi= error detection is already functional (before the next update):
{{cite book |title=Title |doi-broken-date=April 2021}}Title. |doi-broken-date= requires |doi= (help)
|asin-tld= without |asin=, |pmc-embargo-date= without |pmc=, and |class= without |arxiv= error detection was added to the sandbox at this edit, rewritten and the |class= error detection removed at these edits. This functionality has since been split between Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox to resolve the extraneous error messaging noted at Help talk:Citation Style 1 § asin & isbn. Because |asin-tld= without |asin= and |pmc-embargo-date= without |pmc= error detection is grouped together with |doi-broken-date= without |doi= error detection, I included err_doibroken_missing_doi in the above list.
Trappist the monk (talk) 22:22, 3 April 2021 (UTC)
The RFC discussion is about the last six unhyphenated parameters that have not yet been deprecated. The deprecated parameters listed above were deprecated by consensus on this talk page before the new RFC started. There is no point in delaying their formal deprecation in the module code, since they no longer exist in a significant quantity in the wild; any stray deprecated parameters that may have been added after the affected namespaces were checked and cleaned can quickly be tidied up. There will not be a massive bot run or piles of red error messages. – Jonesey95 (talk) 00:55, 4 April 2021 (UTC)
The question asked there is about non-hyphenated parameters, period. Nikkimaria (talk) 01:11, 4 April 2021 (UTC)
Yes, that was the question. It hasn't been the discussion, in any shape or form. The discussion is almost exclusively whether a bot prior to formal deprecation is appropriate and whether it is appropriate for that bot to make other cosmetic changes and whether it's appropriate to do it with parameters used a million times or more. It has certainly not discussed the parameters deprecated by a discussion here. Izno (talk) 01:48, 4 April 2021 (UTC)
However, because that was the question, the closing could be anticipated to address that question. Thus the need to wait for an outcome there, rather than relying solely on local consensus here. Nikkimaria (talk) 01:56, 4 April 2021 (UTC)
No, closings summarize the discussion, even if it tends away from the question. I anticipate that the question in the heading of that discussion will feature not at all in the closer's summary. Izno (talk) 02:21, 4 April 2021 (UTC)
Re the default for |ref=. This was set to |ref=harv, as in the author-date short reference scheme. The module programmatically offers a target for select short-reference anchors such as those generated by {{harv}} (by mapping the author and date parameters accordingly). That would make something like |ref=harv or similar redundant. Or that is what I think this means, anyway. (talk) 01:45, 4 April 2021 (UTC)
No, this discussion is about cases where a template like {{cite book |last=Last |first=First |year=2020}} also has |ref=CITEREFLast2020. That value is the same value as the templates auto-generate today automatically.
|ref=harv was separately deprecated already when the templates were set to do so, sometime within the past year. Izno (talk) 02:17, 4 April 2021 (UTC)
An observation. It may be time to ditch the "Style" part from the module's name. This module collection and the applications (templates) based on it has evolved beyond style elements. There are error-checking routines for data, calls to external code, and compliance to standards that have nothing to do with presentation. It is becoming a full-blown citation format rather than just facilitating the stylistic formatting of citations. I make no representations about whether this is a bad or good thing. (talk) 02:02, 4 April 2021 (UTC)

Follow-up to module updatesEdit

It appears that this update has deprecated the properly hyphenated |series-no=, but I do not see a discussion about that change. Is this a bug, or is the change not listed above, or something else? Pinging Trappist the monk. – Jonesey95 (talk) 13:39, 10 April 2021 (UTC)

This edit to the sandbox on 4 April (after the list above was written) apparently fixes this edit.
Trappist the monk (talk) 14:03, 10 April 2021 (UTC)

Another issue: |issue=November causes and extra text error. That happens because of this pattern:

'^nos?[%.:=]?' – begins with no or nos and may be followed by a dot, a colon, or an equal sign

We might change that to:

'^nos?%W' – begins with no or nos and must be followed by a character that is not a letter or a digit

Trappist the monk (talk) 14:03, 10 April 2021 (UTC)

I support application of these two bug fixes ASAP (especially since it looks like I caused one of them). – Jonesey95 (talk) 14:09, 10 April 2021 (UTC)
I'm still thinking about the |issue= issue.
|series-no= restored.
Trappist the monk (talk) 14:25, 10 April 2021 (UTC)

Chuj is unsupported in |languageEdit

I've seen several uses of Chuj in the |language param. Its 639-3 code is cac, so if someone could add support for it (or show me how to add it to the list) I'd be very happy. Thanks! Remagoxer (talk) 20:28, 3 April 2021 (UTC)

cs1|2 only supports languages that are known to MediaWiki which does not know about every ISO 639 language code. The list of supported languages is at Template:Citation Style documentation/language/doc.
Trappist the monk (talk) 22:35, 3 April 2021 (UTC)
I am aware of this - would this have to be a deeper MW change? However, I've also heard that manual overrides are possible? Sorry if I'm a bit confused, I'm not exactly sure what this change would fall under. Remagoxer (talk) 23:42, 3 April 2021 (UTC)
cs1|2 has the facility to override an existing language name if that language name is known to MediaWiki. For example, for code bn, MediaWiki returns Bangla which is the endonym. What cs1|2 wants is the exonym, Bengali, so cs1|2 overrides MediaWiki to render the language name correctly.
MediaWiki do some times change the language name data but I have never been successful in getting them to change anything for me. Perhaps you will have better luck.
Trappist the monk (talk) 00:29, 4 April 2021 (UTC)

lua error with invalid access parameterEdit

|doi-access=fre gives this beauty

  • Wild, Alexander L.; Cuezzo, Fabiana (2006). "Rediscovery of a fossil dolichoderine ant lineage (Hymenoptera: Formicidae: Dolichoderinae) and a description of a new genus from South America". Zootaxa. 1142: 57–68. doi:10.11646/zootaxa.1142.1.5. hdl:11336/85874. Invalid |doi-access=fre (help)

instead of an invalid |doi-access= error.

This should be fixed before the next update if possible. Headbomb {t · c · p · b} 22:15, 3 April 2021 (UTC)

Already fixed; its the 'fix access level error messaging' note in the update notification.
Trappist the monk (talk) 22:28, 3 April 2021 (UTC)

RFC on hyphenated citation template parameters closed – how to proceed?Edit

The RFC on unhyphenated parameters has been closed. As one might have expected from following the discussion, it's a compromise closure, but I believe that it gives us a sort of path forward.

The six unhyphenated multi-word parameters left (by my count) – |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= – are to be placed in a new (to us) state called "developer discouraged", which means this: As such, these parameters should not be advertised in documentation, hidden maintenance categories added (and etc.) while still remaining available for use by long time editors. The five or so grandfathered parameters should only ever turned off following a later discussion which receives wide attention and clear consensus. In the meantime, any editor should feel free to manually change unhyphenated parameters into their hyphenated forms while they're doing something else on a page.

This means that we can proceed with our work to convert unhyphenated parameters to hyphenated parameters, but (for now) only while making another substantive change to the page, like fixing another CS1 error.

With respect to the module code, I think this means that we should:

  1. Remove the unhyphenated versions of those parameters from our documentation.
  2. Create a hidden maintenance category called Category:CS1 maint: developer-discouraged parameter or something similar
  3. Create a hidden maintenance message, e.g. "developer-discouraged parameter |accessdate= (help)" or "developer-discouraged parameter |accessdate= used (|access-date= suggested) (help)"

We could also modify the AWB "general fixes" rules to replace the unhyphenated parameters so that they are fixed when an editor makes a substantive change to an article using AWB. Note that there was pushback when this change was made last year.

Is there more that we should do? Comments, corrections, additions, and suggestions are welcome. – Jonesey95 (talk) 17:49, 6 April 2021 (UTC)

What I really want to know, what I really want to know, is how did I miss |airdate=? After all of this, that parameter was completely overlooked. Argh!
I don't know what to think about developer discouraged. Outside of the RFC, is there such a thing? Google returned only 152 results for the quoted string ... one of them the RFC. Deprecation (at least as I understand it within the scope of cs1|2) is 'developer discouraged'; that is, deprecation is the point where we formally begin to discourage the use of something. For example, we 'discourage' the use of |authors= because we are none of us clever enough to write code that can reliably parse apart a free-form list of human names so that those names may be included in the citation's metadata. But, because there are 22k-ish articles in Category:CS1 maint: extra text: authors list‎, we aren't ready to deprecate it quite yet.
Removing the nonhyphenated parameters from the documentation is simple and straight forward. I'm not so sure about the maintenance category or message. A category with a million or more articles seems so large that it would be off-putting to anyone interested in fixing those articles. Adding maintenance messaging won't normally be a problem but for large articles that are nearing the post‐expand include size limit, it might push them over the edge and incur anger before these parameters are officially deprecated.
We might propose a 'bot-only' version of GENFIXES so that |accessdate= etc could be fixed by AWB bots doing other stuff without imposing the burden on normal everyday AWB users who also want to run AWB with GENFIXES on. I won't hold my breath for this because it is rather special purpose.
Trappist the monk (talk) 20:05, 6 April 2021 (UTC)
What? Trappist isn't perfect? Trappist missed |airdate=? For those of us who make mistakes more than once a month, this was, frankly, a relief. Welcome to the club, friend. (I did only list |airdate= once in the 27,000-word RFC discussion, and that discussion was painful to visit, so I can see why it was missed.)
I don't know what to think about the apparently made-up adjectival phrase "developer-discouraged" (I have inserted a hyphen here and above, but I am not pedantic enough to try to correct the RFC closer) either, when we have had the perfectly good concept of deprecation for a long time. I do think that there is enough guidance in the RFC for us to use it as the closer intended, though.
I think that a hidden category of a million-plus articles is fine (see Category:Living people, for example), especially since our intent is to make it smaller. We can use that category to find stray template uses of the parameters that have escaped our notice. We can use it to run petscan searches and insource searches that allow us to find articles where a bot or an AWB editor could hyphenate the parameters while making a visible change (e.g. accessdate and ref=harv, currently 10,000 articles). We can track its size over time to gauge the feasibility of actually deprecating and removing support for the parameters at some point.
I can live without a hidden message. The RFC and its closure may seem like a barrier at first, but I think that they allow us some room to move forward. Wikipedia a group project run by humans; things don't always go the best way, but they progress toward sanity over time. – Jonesey95 (talk) 20:48, 6 April 2021 (UTC)
I have asked the closer for some clarification on one unclear sentence. Also, I am not worried about hidden messages making the pages exceed the template expand size. I would be happy to monitor the intersection of that category and the new maintenance category and fix the expansion problem by fixing the parameters. – Jonesey95 (talk) 21:24, 6 April 2021 (UTC)
The simplest way to do the category is to treat the category as a properties cat: Category:CS1 has developer-discouraged parameter or some-such. We can mark the six parameters in Module:Citation/CS1/Whitelist with some sort of secret code (discouraged comes to mind) and then modify validate() to detect that secret code in the same way that it detects false for deprecated parameters. validate() then calls utilities.add_prop_cat() to add the category. Empty deprecated parameters cause a Cite has empty unknown parameter: |<param>= error; empty discouraged parameters would do the same.
It would seem that now is the time to act (before the pending update) if we are going to act at all.
Trappist the monk (talk) 21:47, 6 April 2021 (UTC)
I agree, and the detection approach and timing appear sound, if you have time to code it. It would be nice to hear from other page watchers, but the RFC and this note from the closer provide some guidance that we can lean on for consensus. I think in-text messages should be green and hidden by default (or nonexistent; I'm not attached to them). As for the cat name, how about Category:CS1: developer-discouraged parameter, which appears to match the pattern of recently created "properties" categories. I'll be happy to write a description and some guidance for the category page. – Jonesey95 (talk) 22:28, 6 April 2021 (UTC)
Maint messages are hidden by default (they exist in articles visible or no). I guess that ultimately, maint cats are better because they are visible so editors who see them may be more inclined to fix. Since the closer appear to prefer maint messages... Category name would then be Category:CS1 maint: developer-discouraged parameter.
Trappist the monk (talk) 22:46, 6 April 2021 (UTC)
Maint version:
{{cite book/new |title=Title |url=// |accessdate=2021-04-06}}Title. Retrieved 2021-04-06. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |url=// |accessdate=}}Title. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |url=// |accessdate=2021-04-XX}}Title. Retrieved 2021-04-XX. Check date values in: |accessdate= (help)CS1 maint: discouraged parameter (link)
{{cite episode/new |series=Series |airdate=2021-04-06}}Series. 2021-04-06. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |url=// |archiveurl=// |archive-date=2021-04-06}}Title. Archived from the original on 2021-04-06. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |url=// |archive-url=// |archivedate=2021-04-06}}Title. Archived from the original on 2021-04-06. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |author=Blue |authorlink=Blue}}Blue. Title. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |author=Blue |authorlink1=Blue}}Blue. Title. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |author=Blue |author1link=Blue}}Blue. Title. CS1 maint: discouraged parameter (link)
{{cite book/new |title=Title |date=2021 |origyear=1700}}Title. 2021 [1700]. CS1 maint: discouraged parameter (link)
Trappist the monk (talk) 00:40, 7 April 2021 (UTC)
I do not think that "Cite has empty unknown parameter: accessdate" is accurate wording for a supported parameter (see the second example above). – Jonesey95 (talk) 04:10, 7 April 2021 (UTC)
Ok, changed.
Trappist the monk (talk) 12:51, 7 April 2021 (UTC)
"Developer-discouraged" really sounds odd. Let's just call this new state "discouraged" in the category name and message.
--Matthiaspaul (talk) 09:33, 7 April 2021 (UTC)
Ok, changed.
Trappist the monk (talk) 12:51, 7 April 2021 (UTC)
The hidden message could be further improved by suggesting a replacement parameter if there is a replacement defined in the list of suggestions (like we do for most no longer supported parameters). This would apply to these new "discouraged" parameters as well as to so called deprecated parameters.
--Matthiaspaul (talk) 11:41, 7 April 2021 (UTC)
That would convert the messaging from a maintenance message to an error message. I don't think that we should create a special one-off maint message for this or any other maint condition.
Trappist the monk (talk) 12:51, 7 April 2021 (UTC)
Comments were welcomed by the OP, so: this tempest in a teapot ended quite fittingly, with a whimper (for now). In such cases, the obvious mediocrity is often enhanced by the introduction of new terms in order to fit the contortions of the decision. I don't blame the closer for splitting the baby down the middle. This RFC was frivolous, but so what. Hundreds are. On the other hand, this module collection is overcategorized. The answer to everything sometimes seems to be, let's have another category (of whatever type, but the error-emmting ones are obviously the ones raising people's hackles). So precious human resources will now be taken away from optimizing the modules and rationalizing their design, and made to ensure that the displeasure of developers (tut tut tut) over a non-issue is properly represented. The only entertainment regarding the RFC and this discussion is Jonesey's joke about "progress". (talk) 22:58, 6 April 2021 (UTC)
Re: AWB pushback: I think the ~2.8m |accessdate= pages then where the deal-breaker, moreso than the now only ~30k pages (down from ~330k 5 months ago!) with |authorlink= unhyphenated aliases up to 5. Not just that, but the number of |accessdate= on a per-page basis was very prohibitive. There are many fewer |authorlink= per page, especially now after Monkbot & others standardizing, that it's much less burdensome to add back into WP:GENFIXES.
One way to slowly get around the |accessdate= GENFIXES burden would be to hyphenate 1 citation template at first, instead of all of them at once. Then, every few weeks, months, or however long it takes to get that template's |accessdate= count down to negligibility, add another citation template to hyphenate accessdate, and repeat until all templates are included. Perhaps this can be started after the |authorlink= count is in the ~1k range.   ~ Tom.Reding (talkdgaf)  03:02, 7 April 2021 (UTC)
I added a few parameter renaming lines to the AWB genfixes, but I was reverted by an editor who does not appear to agree with the RFC. I have no interest in edit warring, and I don't use AWB, but other editors may want to engage there. – Jonesey95 (talk) 03:51, 7 April 2021 (UTC)

I'm struggling to understand why this is a compromise close.

  1. Whereas before we could make cosmetic hyphenation changes while doing other bot work, now it can only be done manually. AWB is semi-automated.
  2. Manually changing millions of citations equates to it won't happen.
  3. Changing the docs is a fig leaf. People are usually following examples or habit, sometimes the docs.

To me it looks like two big steps backwards (#1 and #2) and a very small step forward (#3). I'll be removing the hyphenation cosmetic feature from my bots. I would suggest before starting RfC #2, gather intelligence on how many hyphenated vs. non-hyphenated are added over a month period. Forget the legacy footprint, see what the community is doing right now to better determine what should be done going forward based on current consensus. It will also mitigate any loud minority who tend to dominate VP. -- GreenC 04:46, 7 April 2021 (UTC)

I don't agree with point 1 above. The close said: Monkbot 18 should not be run solely to replace the discouraged non-hyphenated parameters. [...] With so many objections to execution of the "hyphenate cs1|2 parameter names" section of Monkbot 18, it's hard to say there is consensus to enact it except if it was bundled with non-cosmetic changes... (The ellipsis removes some stuff that does not make any sense or is not relevant here.) To me, this reads as "If a bot is making cosmetic changes to the parameter names and no other changes to the page, that is not allowed. If a bot (or human editor) is making a substantive change to the page, it is OK to update the parameter names." Both quoted sentences state or imply that parameter replacement along with substantive changes are allowable bot edits. – Jonesey95 (talk) 06:10, 7 April 2021 (UTC)
Yep. I read it the same way. So, updating discouraged parameters to fully supported ones while doing other non-cosmetic edits is still okay for humans and bots. --Matthiaspaul (talk) 09:54, 7 April 2021 (UTC)
I agree.
@MJL: see ambiguous interpretations of your close above regarding use of the word "manually". I do not think this RFC has the 'power' to restrict AWB/JWB/etc. users from performing hyphenations, as long as they also make substantive edits (WP:AWBRULES #4). AWB/JWB/etc. are known as "semi-automatic" tools, so I would suggest changing "manually" to "manually or semi-automatically".   ~ Tom.Reding (talkdgaf)  11:41, 7 April 2021 (UTC)
@Tom.Reding: Yeah, manually or semi-automatically was always the intention. That's fixed now. –MJLTalk 18:05, 7 April 2021 (UTC)

Broken historiesEdit

I wasn't following this whole debate that closely, so perhaps this was covered, but I'm disappointed to see that whatever outcome there was has broken a ton of page histories, generating errors throughout the reference sections. See e.g. Special:Permalink/843704571#References. {{u|Sdkb}}talk 21:51, 11 April 2021 (UTC)

|deadurl= and |dead-url= were deprecated at the 3 September 2019‎ module-suite update. Support for these parameters was withdrawn at the 11 January 2020‎ module-suite update. Those actions have nothing to do with the recently closed RFC.
Trappist the monk (talk) 22:06, 11 April 2021 (UTC)

Help with a citationEdit

I'll be link saving URLs in about 10,000 citations to the New York Times Movies database, and while there also updating the metadata which I am uncertain how to proceed. Example:

{cite news |url= |title=The Court Martial of Jackie Robinson (1990) |work=[[The New York Times]] |access-date=December 9, 2019 |archive-url= |archive-date=January 3, 2014 |url-status=dead}}

The page is hosted at the NYT, but the content is copyright All Movie Guide as seen at the bottom of the page. The NYT licensed the content from a third party, and now that license has expired, the pages are dead links. The NYT did not create the content nor own it, rather hosted and branded it. The question is how to best cite it. Some ideas:

  1. |work=The New York Times
  2. |work=All Movie Guide, |via=The New York Times
  3. |work=The New York Times, |via=All Movie Guide
  4. |work=The New York Times, |publisher=All Movie Guide
  5. |work=All Movie Guide, |publisher=The New York Times
  6. |work=The New York Times, |agency=All Movie Guide

To further complicate there is also Baseline StudioSystems copyright notice at the page bottom, in addition to All Movie Guide. -- GreenC 05:24, 7 April 2021 (UTC)

I would not agonize over copyright issues. Copyright of the NYTMDb and its links to content belongs to NYT, and what is cited is a link. Assuming the original citations will be preserved, readers will access the wikitext-proving content via the archive. The content is by definition static: neither the movie info nor the credits seem liable to change. I would add |department=Movies and |via=archive-name. (talk) 12:30, 7 April 2021 (UTC)
In case it was not clear, I do not refer to editor-initiated archives. The above applies only to official/authorized archives of the NYT. Under the assumption that such archives have proper copyrights from parties concerned. (talk) 12:41, 7 April 2021 (UTC)

It's not just copyright notices, see for example [3] which is signed "Hal Erickson, Rovi" (Rovi = All Movie Guide). The NYT is not the underlying or original source, the Times licensed it for a while and no longer does. It will help our readers to know this content sources back to other entities, should archives become unavailable or are currently not available. -- GreenC 14:48, 7 April 2021 (UTC)

It is commendable that you want to provide a path to verification, but I believe this goes beyond what would be normally expected of a citation. It certainly exceeds the requirements of policy, and even the recommended practices. AFAIK they make no mention of a second-level source (source of a source). You are in untemplated territory. I would recommend a {{link note}}. (talk) 19:17, 7 April 2021 (UTC)

how about something completely different?Edit

Yesterday I tweaked a bunch of cs1|2 TemplateData structures. I don't use any tool that uses TemplateData; I think that TemplateData is a poor design choice that is attempting to be both documentation and control. It may do well at whatever control functions it is supposed to do but as far documentation, it is a failure (it can't support wiki-markup which completely misses the mark on a wiki).

Regardless, TemplateData's structured form does have some benefits in that it is 'structured' (which the 'official' documentation certainly is not). While doing the tweaking that I did yesterday, I noticed that almost all of the TemplateData identifies cs1|2 parameters that are no-longer supported or aren't supported in 'that' template. Because cs1|2 maintains a list of parameters that are supported in Module:Citation/CS1/Whitelist, it occurred to me that I could write a lua function to compare what the TemplateData think are supported parameters and what ~/Whitelist knows are supported parameters. So I did:

{{#invoke:cs1 documentation support|template_data_validate|{{ROOTPAGENAME}}}}

can be added to a cs1|2 template's doc page in §TemplateData. Or, it can be placed elsewhere, like this page:

{{#invoke:cs1 documentation support|template_data_validate|cite web}}
Template:Cite web/doc TemplateData has errors:
  • |credits= not valid alias of: |authors=
  • |editor2link= not valid alias of: |editor2-link=
  • |editor3link= not valid alias of: |editor3-link=
  • |editor4link= not valid alias of: |editor4-link=
  • |editor5link= not valid alias of: |editor5-link=
  • |editor6link= not valid alias of: |editor6-link=
  • |editor7link= not valid alias of: |editor7-link=
  • |editor8link= not valid alias of: |editor8-link=
  • |editor9link= not valid alias of: |editor9-link=
  • |editorlink2= not valid alias of: |editor2-link=
  • |editorlink3= not valid alias of: |editor3-link=
  • |editorlink4= not valid alias of: |editor4-link=
  • |editorlink5= not valid alias of: |editor5-link=
  • |editorlink6= not valid alias of: |editor6-link=
  • |editorlink7= not valid alias of: |editor7-link=
  • |editorlink8= not valid alias of: |editor8-link=
  • |editorlink9= not valid alias of: |editor9-link=
  • |editors= not valid alias of: |editor-last=
  • |last-author-amp= not valid parameter
  • |separator= not valid parameter

No doubt, it ain't perfect, but perhaps it will help to keep TemplateData synched with ~/Whitelist and maybe, just maybe, we will see fewer errors accumulating in the cs1|2 error categories. Suggestions for improvements solicited.

Trappist the monk (talk) 22:40, 8 April 2021 (UTC)

The worst of the pain with TemplateData is that no-one ever got around to making it so we could document enumerated parameters sanely. It's overwhelming to work through the list when you have to slog through 30 parameters all for the same idea (times 15 templates). Izno (talk) 23:18, 8 April 2021 (UTC)
There is a phabricator bug for this. T54582 --Salix alba (talk): 14:15, 11 April 2021 (UTC)
Anyway, cool tool. Might be interesting to build some more-general tool for template and/or non-i18n module checks between TemplateData and what is implemented. Izno (talk) 23:19, 8 April 2021 (UTC)
I think about a variant of this sometimes when I'm editing a template that does unsupported-parameter checking. Why keep a human-maintained list of valid parameters when a module can read the actual template wikitext for comparison against the parent frame?
Trappist the monk (talk) 11:09, 9 April 2021 (UTC)
Is anybody actively maintaining TemplateData as a project? Anything that improves the interaction with the module is a good thing, as long as the cross-development is not derailed by TemplateData having its own roadmap. There is the advantage of somewhat-structured documentation, but surely the native documentation could also be formatted programmatically. To me, this would be a worthier project than fussing over whether editors will have to deal with hyphenated parameters. (talk) 12:35, 9 April 2021 (UTC)
Added to all cs1|2 templates that have TemplateData ({{cite AV media notes}}, {{cite map}}, {{cite serial}}, {{cite speech}}, {{cite techreport}} do not). I'll leave it to those who care about TemplateData to fix the errors.
Trappist the monk (talk) 13:43, 9 April 2021 (UTC)
Thank you for this rigor, Trappist. This sort of module-based doc maintenance is one of the first things I did with {{Authority control}}, and it has saved much time, effort, and sanity.
When trying to remove |editorlink= params, I couldn't tell by the doc & contradictory TemplateData (and minor self-inconsistency in the doc) which is the canonical param & which is the alias (I guess I could ignore the TD, but I'd rather hear it from the source). Module:Citation/CS1/Whitelist subtly suggests (by virtue of appearing first in the table) that |editor-link#= is the canonical version & |editor#-link= is its alias. Similarly with |editor-first#= as cannon & |editor#-first= as its alias, and so-on with all numbered parameters. If so, does this also apply to all #=<1|null> params like |author-link1=, |author1-link=, |author-link=, (i.e. cannon, alias, alias, respectively) or is there a different scheme for these?   ~ Tom.Reding (talkdgaf)  14:44, 9 April 2021 (UTC)
I don't believe that there is any officially preferred form of parameter name when the choice is between non-enumerated and enumerated (|author-link= and |author-link1= or |author-link= and |author1-link=). I don't believe that there is any officially preferred form of parameter name when the choice is between the enumerated forms (|author-link1= and |author1-link=. In all cases they are fully equivalent.
So, I guess it comes down to preference. For me, that preference is: |author-link=|author-link1=|author1-link=. It would be best if all of these types of parameters followed the same pattern parameter-to-parameter and template-to-template.
Trappist the monk (talk) 16:32, 9 April 2021 (UTC)
I have found a minor coding error, but I don't know the right place in the code to fix it. The alias message renders as:
*<code style="color: inherit; background: inherit; border: none; padding: inherit">|ISBN13=</code> not valid alias of: |isbn=</code>
Note the extra </code> tag or missing <code> tag. – Jonesey95 (talk) 13:42, 11 April 2021 (UTC)
Fixed that.
Trappist the monk (talk) 14:02, 11 April 2021 (UTC)
|ISBN13= & |isbn13= were both flagged as errors in Template:Cite book/TemplateData, but both show as 'true' on the whitelist. Template:Cite book/doc currently says that |ISBN13= & |isbn13= are both aliases to |isbn=, which is not reflected in the TD. Should ISBN13/isbn13 be reinstated in the TD, or removed from the corresponding doc-template?   ~ Tom.Reding (talkdgaf)  13:05, 11 April 2021 (UTC)
Yes, they are aliases. ISBN13 and ISBN parameters are synonyms in Module:Citation/CS1/Configuration. Izno (talk) 13:24, 11 April 2021 (UTC)
According to this cirrus search, |isbn13= and |ISBN13= are rarely used. cs1|2 templates accept only one |isbn= parameter so do we really need |isbn13= and |ISBN13=? I think we don't so these should be quietly replaced with |isbn= and the other two deprecated.
Trappist the monk (talk) 14:02, 11 April 2021 (UTC)
|isbn13= and |ISBN13= issue is fixed.
Trappist the monk (talk) 17:20, 11 April 2021 (UTC)

name-list-format= still in article spaceEdit

Matthiaspaul and other editors who like to remove unsupported parameters: it looks like somewhere around 300+ uses of |name-list-format= in article space were either overlooked or added after January. – Jonesey95 (talk) 23:03, 10 April 2021 (UTC)

That's interesting. Before I disabled the parameter back then (Help_talk:Citation_Style_1/Archive_74#Removal_of_no_longer_used_name-list-format=_in_sandbox) I checked ([4]) that the parameter was no longer in use in mainspace (otherwise I wouldn't have disabled it). So, either I must have made a mistake running that check or Cirrus search wasn't accurate. Fortunately, the number of hits is low enough to be fixed manually.
--Matthiaspaul (talk) 09:43, 11 April 2021 (UTC)
Cirrus search, like category links in a way, does not guarantee an update to its index if no edit has been made to a page recently. This long tail is pretty routine when working in this area. The only way to get all of them guaranteed is to pull a database snapshot and search there. Izno (talk) 13:26, 11 April 2021 (UTC)
(Sometimes it's caused by reversions to versions older than when you searched too.) Izno (talk) 13:27, 11 April 2021 (UTC)
No worries; the search doesn't always return 100% of what is out there, and as Izno says, reverts and weird lags can cause searches to miss things. I also found a half-dozen uses in template space, but I think I have fixed all of them. – Jonesey95 (talk) 13:34, 11 April 2021 (UTC)

junk author namesEdit

Today I stumbled upon a cs1|2 template that had author name parameters like these from Belgrade Nikola Tesla Airport:


Sigh. Perhaps cs1|2 should alarm when name parameters include: Facebook, Twitter, Pinterest, Email, and, no doubt, others.

At present there aren't that many:

Email: ~130
Facebook: ~140
Google: ~260 (timed out)
Instagram: ~20
LinkedIn: ~50
Pinterest: ~90
Tumblr: ~30
Twitter authors: ~400

But, alas, if we do nothing, the number of these bogus-author templates will increase...

Trappist the monk (talk) 14:23, 11 April 2021 (UTC)

Alas indeed. We could also try to detect VE-inflicted, lazy-editor nonsense like this. – Jonesey95 (talk) 14:53, 11 April 2021 (UTC)
Those should probably be a Phab report regardless. Izno (talk) 15:59, 11 April 2021 (UTC)
Go for it. I am immensely tired of submitting VE bugs to phab and having them sit unaddressed for years. – Jonesey95 (talk) 16:10, 11 April 2021 (UTC)

Using volume= with cite bookEdit

Using the volume= parameter now throws and error when text is included. Many multivolume books have titles - for example:

  • Cramp, Stanley, ed. (1985). "Ceryle rudis Pied Kingfisher". Handbook of the Birds of Europe the Middle East and North Africa. The Birds of the Western Palearctic. Volume IV: Terns to Woodpeckers. Oxford: Oxford University Press. pp. 723–731. ISBN 978-0-19-857507-8. |volume= has extra text (help)

Now I could include the volume info in the title - but I think it would be better to revert to the previous behaviour - where no error was flagged. - Aa77zz (talk) 15:58, 11 April 2021 (UTC)

Remove the word "volume": Handbook. IV: Terns to Woodpeckers. Izno (talk) 16:01, 11 April 2021 (UTC)
The real solution here is that books should display 'Vol.' in front of their volumes. Headbomb {t · c · p · b} 16:54, 11 April 2021 (UTC)
Hence my working on the RFC which you have noticed. ;) Izno (talk) 17:54, 11 April 2021 (UTC)
Does it make sense that in the above example "Volume" is flagged as "extra text", but "Terns to Woodpeckers" is not? I agree with Aa77zz: whatever was changed should be changed back. Srnec (talk) 19:30, 11 April 2021 (UTC)
It's possibly somewhat problematic that, for books, we use the |volume= parameter for two different things (to distinguish the parts of a multi-volume single work, and to label books in a book series by their number in the series). —David Eppstein (talk) 18:29, 11 April 2021 (UTC)

When was this change made? Now I have to either move the |volume= parameters into the titles or (like Headbomb suggests) change the V in Volume to &#86; in all the book references Hawkeye7 (discuss) 21:43, 11 April 2021 (UTC)

Remove the word volume. That's the fix. That's all you need to do. Izno (talk) 22:13, 11 April 2021 (UTC)
No. Because then it is in bold. And that's not right. Why should anybody have to 'fix' what isn't broken to make it wrong? Srnec (talk) 23:49, 11 April 2021 (UTC)
It is an error to put the parameter name in the parameter value: |volume=Volume IV, |pages=pp. 3–5, |editor=Edward Eddington (ed.), etc. This is because this extra text is generally the wrong kind of information: it's not the metadata for the publication itself, but rather an attempt to control how that metadata is framed in its presentation to the user. If you're using these templates, you need to give up that control, let the template handle how to tell the reader that the volume is "IV" or "IV: Terns to Woodpeckers", and not try to put a description of what kind of metadata it is into the metadata itself. I happen to think that the template should always write out "vol. X" rather than just displaying it as "X", and not use boldface for volume numbers, but that's a separate discussion from the correct way to tell the template what your metadata is. —David Eppstein (talk) 00:05, 12 April 2021 (UTC)
I happen to think this was a bad change made without discussion. Since we cannot revert it, the only choice we have is to abandon use of the template. Hawkeye7 (discuss) 00:43, 12 April 2021 (UTC)
The change was discussed in #Obtuse template style and announced for incorporation in #module suite update 10–11 April 2021 (and subsequently incorporated). If what you wanted was to know why it happened, you need to ask for that first.
Anyway, I think any pain points will be resolved by the RFC I am preparing at #Draft RFC. That aside, DE is fundamentally correct. That aspect of CS1/2 is no different than any other citation style. Izno (talk) 00:48, 12 April 2021 (UTC)
This change is not listed in #module suite update 10–11 April 2021. Hawkeye7 (discuss) 05:58, 12 April 2021 (UTC)
@Hawkeye7: allowed plural forms of extra text patterns for volumes, issues and numbers; discussion. I'm sorry it was not more clear but I also did not write the note in question. --Izno (talk) 14:17, 12 April 2021 (UTC)
then it is in bold What? I provided a copy of the volume rewritten above without the word volume. Do you see bold there? I do not. (I understand that when the template bolds things is not obvious for people who do not keep close track, but this is not one such instance. The majority of CS1/2 will bold templates with: only numerals, Roman, Arabic or otherwise; and sufficiently short text, usually less than 5 characters. This case is neither.) Izno (talk) 00:51, 12 April 2021 (UTC)
It's not just in bold:
What is the reader supposed to make of the eight sitting out there on its own like a country dunny? Why is is separated from the page number?
The Commonwealth Style Guide (p. 204) says that references must be in the form vol. 8, no. 1, pp. 376-377 Hawkeye7 (discuss) 01:11, 12 April 2021 (UTC)
So, a totally different citation to the one above. Got it. As just stated, yes, numbers are bolded.
External citation/styles guides are not CS1/2. If you want to format an article according to Commonwealth, that is your prerogative, but these are not the templates for that and never have been. Ever.
Again, you will have an opportunity on the point to change what the rendering appears as. Please go review the draft RFC linked in the section above and leave a comment in that section if you think that RFC reads okay to you. --Izno (talk) 01:48, 12 April 2021 (UTC)
That is not correct. Note the comment above from Trappist the monk in the "Obtuse template style" section: Because outside of Wikipedia, scholarly and academic journals commonly use that style.
I don't care about the RfC; I want the error messages removed. Hawkeye7 (discuss) 05:52, 12 April 2021 (UTC)
Hawkeye7, then remove the extra text "Vol.", "Volume" etc. from the parameter, and the error message will disappear.
One of the ideas for using citation templates is to decouple information from presentation, a fundamental design principle, and to centrally maintain the presentation for consistency and also to allow for future changes in presentation style without having to rework all citations individually. Editors working on an article should not (need to) bother about the presentation of citations at all, all they need to do is provide the proper information.
The reason why our citation templates for books display volumes in bold and without any extra text like "Vol." is because the community decided that book citations should look this way long ago. So, this is not a shortcoming of the template, but deliberately coded this way. Nevertheless, not everyone agrees with this and therefore some people abuse the |volume= parameter trying to override the presentation. However, this is not a good idea because it will defeat the idea of allowing the presentation to be changed centrally in the future (perhaps even depending on the output device, different languages, or in a user-selectable format) and cause invalid metadata to be generated.
The proper way for you to deal with the situation is to ignore your presentation preferences for the moment and provide the data in the proper format for the template (that is, without any "Vol." etc.). Optionally, you can voice your opinion here that displaying bold volume numbers for books might not look nice or could even be ambiguous for people not familiar with this convention, or you might even propose a different presentation. If enough people ask for a presentation including a "Vol." prefix, we can change it centrally, but only if |volume= continues to contain just the volume, not some extra text decoration (otherwise the resulting presentation would become "Vol. Vol. X"). See the point?
I hope this helps to better understand why something like "Vol." does not belong into the |volume= parameter. --Matthiaspaul (talk) 11:39, 12 April 2021 (UTC)
It is true that [external] citation/styles guides are not CS1/2. That does not mean that, long ago, the editors who individually created these templates did not model the individual template styles on existing external style guides or external common practice. The editors who created {{cite journal}} likely chose to have the template render the 'V (I): P' form because that style is commonly used by scholarly and academic journals.
cs1|2 is a style unto itself and is not beholden to any external style guide.
Error messaging can be turned off; see Help:CS1 errors § Controlling error message display
Trappist the monk (talk) 12:02, 12 April 2021 (UTC)
So turn them off. We shouldn't need an RFC every time something needs to be reverted because there's obviously no consensus for it. See the mandatory website/work clusterfuck. These should be, at best, maintenance messages. Headbomb {t · c · p · b} 12:25, 12 April 2021 (UTC)
Agreed. Hawkeye7 (discuss) 12:27, 12 April 2021 (UTC)
I personally agreed with making it a maint message at rollout when it was instituted but I let it drop by the wayside for other reasons, and people still would have screeched on individual articles instead. It is now trivial to make things maintenance items from being errors in the module (sandboxes) (and vice versa); why did no-one else before rollout change it? (Before you try to excuse your collective selves, no, Lua is not black magic.) --Izno (talk) 14:17, 12 April 2021 (UTC)
This is about {{cite book}}. When have bold volume numbers ever been normal for books? I am now told that "the community decided that book citations should look this way long ago", but I always thought it was just a silly oversight in template design. I am also told that I "need to give up that control" and "let the template handle how to tell the reader [what] the volume is". But the template does not do that well, so what I'm really being told is to give up using the template. The template is what needs fixing. If it formatted book citations sensibly, then "fixing" the error would not be so bad. But why would anyone "fix" the error just to produce a weird-looking citation? Srnec (talk) 12:35, 12 April 2021 (UTC)
When have bold volume numbers ever been normal for books?
|volume= was added to {{cite book}} on 15 March 2008 with this edit and bolded a week-or-so later at this edit. These changes were apparently made as the result of a series of discussions:
So yes, "the community decided that book citations should look this way long ago" as a deliberate decision, not just a silly oversight in template design.
Trappist the monk (talk) 13:18, 12 April 2021 (UTC)
Note the comment above from Trappist the monk in the "Obtuse template style" section: Observing that there is another style that does X does not mean anything about CS1/2's style Y. Again.
I don't care about the RfC Then you are clearly not here to collaborate and care only for having your preference enforced. Do better. Take the minute I asked you to, look over the RFC, tell me whether you think it is formed well, and we can move on with an actual positive request for change. --Izno (talk) 14:17, 12 April 2021 (UTC)
The sandbox should now display the error as hidden: Title. Volume. |volume= has extra text (help) Be forewarned, this error being hidden by the module will likely not continue into the indefinite future. Izno (talk) 14:39, 12 April 2021 (UTC)
Return to "Citation Style 1" page.