Help talk:Citation Style 1/Archive 75

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

Archive 70

←

Archive 73

Archive 74

Archive 75

Archive 76

Archive 77

→

Archive 80

A discussion at {{cite q}} got me wondering why cs1|2 doesn't emit error messages when {{cite book}} has a |work= (or alias) parameter. A |work= parameter in {{cite book}} is visibly rendered but whatever it contains is not made part of the citation's metadata:

{{cite book |title=Title |work=Work}}

Title. {{cite book}}: |work= ignored (help)

'"`UNIQ--templatestyles-00000005-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+75" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;work=</code> ignored ([[Help:CS1 errors#periodical_ignored|help]])</span>

Error messages are emitted when |encyclopedia= is used in other than {{cite encyclopedia}} or {{citation}}. Similarly, error messages are emitted when |chapter= (or alias) is used in a 'periodical' template ({{cite web}}, {{cite news}}, {{cite journal}}, {{cite magazine}}, {{cite pressrelease}}, {{cite podcast}}, {{cite newsgroup}}, {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite ssrn}}). So why shouldn't a |work= (or alias) parameter cause {{cite book}} to emit an error message? These searches time out but serve to show that |work= aliases are (improperly) used with {{cite book}}:

• |journal= ~5400
• |magazine= ~140
• |newspaper= ~190
• |periodical= ~100
• |website= ~2800
• |work= ~11,200

—Trappist the monk (talk) 21:38, 30 January 2021 (UTC)

This has nothing to do |work= but with the flawed module design which assigns the same label ("title") to parameters for different types of variables, depending on the downstream application. The entire module should emit an error. Another option is to double-down on the error and have "page" mean "chapter", again depending on the downstream template. Somewhat similar fun in the discussion about |postscript=, above. 98.0.246.242 (talk) 23:46, 30 January 2021 (UTC)

The citation template parameters correctly reflect the terminology used in the real world to describe citations. E.g., for journals, "title" means the article title, whereas for books it means the book title. The COinS metadata also has a degree of contextual ambiguity, e.g. rft.atitle is the "article title", which is used for book chapters, encyclopedia articles and journal articles. The citation templates seem to me to manage the disambiguation about as well as could be expected. Peter coxhead (talk) 07:37, 31 January 2021 (UTC)

This seems backwards to me. Do not introduce ambiguity in the module in the first place by having something mean 2 different things depending on arbitrarily defined context. The semantic meaning of "title" in some templates is "location within a source". That would be a journal article, a track in a musical work, an episode in a TV series, or a chapter in a book etc. In other templates the semantic meaning of title is "the source". A million convoluted discussions can result from this, and they do. After all the source and whatever it is labelled programmatically ("work" pretty much fits the bill since it covers any type of source) is the single most important parameter. And by all means give the metadata its proper place: they are secondary relative to the data, and should take their cue accordingly. Instead we have even more fog developing here. 98.0.246.242 (talk) 15:34, 31 January 2021 (UTC)

As I say any time the IP shows up for his rant (with which I more or less agree), I'd remove |title= entirely given that we should want a consistent system, and that parameter is the least consistent of the batch. --Izno (talk) 07:49, 31 January 2021 (UTC)

Well, hardly a rant, in the sense that it doesn't ruin my day either way. I just point out the underlying issue. Bad design will inevitably lead to incongruous situations, and treating the symptoms will not make the disease go away. 98.0.246.242 (talk) 15:19, 31 January 2021 (UTC)

The reason I call it a rant is that it assumes there was active design in what the parameters were called when taken as a group over all the templates of interest as the templates were created. There was not. They all sprang up individually (also why we have two styles and not one). That the general opinion that the module is defective at its core appears almost without fail is a second reason I call it one. We all know there is something technically wrong; our problem is that the alternative (deprecating and/or removing title being the solution I know) would be a social wrong by this point. So it doesn't help to remind us of that. If you particularly would like to start an RFC on the point, which would surely be needed, have at it. Or suggest a better solution. --Izno (talk) 17:31, 31 January 2021 (UTC)

Believe me, there were objections to this from the very beginning (pre-Lua). So after all these years of avoidable disputes and frequent reminders that made no difference whatsoever, this has settled into the "always-done-this-way" category, a false premise. Uncool. In the meantime, ignoring a wrong approach is entrenching it further, so there we are. 98.0.246.242 (talk) 22:33, 31 January 2021 (UTC)

|work= should stand for a greater work, which is anything in italics in this template. That it is not is a failing of the module. I long for the day where I could generically say {{cite book |work=Work |chapter=Chapter}} as easily as I can {{cite website |work=Website |webpage<!-- why doesn't that parameter exist -->title=Webpage}} as easily as I can {{cite news |work=Work |article<!-- another one that probably doesn't work in cite web and should though I haven't checked -->title=Article}}. And have all the synonyms for a work be actual synonyms: journal, encyc, report, conference, book(-title...), website.... --Izno (talk) 07:49, 31 January 2021 (UTC)

Then {{Citation}} would have to have different parameters from the "cite family", because a fully aliased and hence generic |work= would not identify the type of the source, which is needed to map the components into COinS and the other metadata systems used by reference managers as well as format them in the displayed citation. Peter coxhead (talk) 11:32, 31 January 2021 (UTC)

Citation would need to use anything but work, but this is essentially already true. That it happens to alias to some parameters rather than others (or none) is another failure. And, we were talking about CS1 in this conversation anyway, not CS2. --Izno (talk) 17:31, 31 January 2021 (UTC)

Consider the display produced in these two examples:

1. {{cite web |title=''Papaver cambricum'' L. |work=The International Plant Names Index |url=https://www.ipni.org/n/673433-1}} → "Papaver cambricum L." The International Plant Names Index.
2. {{cite web |title=''Meconopsis'' Vig. |work=The International Plant Names Index |url=https://www.ipni.org/n/30149252-2}} → "Meconopsis Vig". The International Plant Names Index.

The "." in both "L." and "Vig." is a key part of the standard abbreviation of the botanists' names. But in the second example it disappears, so I have to remember to put either "Vig.." or "Vig." in the wikitext. Is this fixable? Peter coxhead (talk) 11:42, 31 January 2021 (UTC)

{{cite web |title=((''Meconopsis'' Vig.)) |work=The International Plant Names Index |url=https://www.ipni.org/n/30149252-2}} → "Meconopsis Vig." The International Plant Names Index.

—Trappist the monk (talk) 11:57, 31 January 2021 (UTC)

I'm doubtful that this is any more sustainable than e.g. my use of .. My experience is that unless I also remember to include an HTML comment to explain, a copy editor is likely to "correct" the citation without noticing the disappearance of the stop. Anyway, it's another alternative, so thanks.

So how can the problem be fixed with {{IPNI}}? Double parentheses don't work here.

{{IPNI |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.

{{IPNI |id=30149252-2 |taxon=Meconopsis |authority=((Vig.))}} → "Meconopsis ((Vig.))". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.

Peter coxhead (talk) 09:52, 1 February 2021 (UTC)

The double parenthesis only works on the whole title, so you need to do this:

{{IPNI |id=30149252-2 |taxon=((Meconopsis |authority=Vig.))}} → "Meconopsis Vig." International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.

Would make the code confusing for editors without explanation. Perhaps the template should be edited to always bracket the title. —  Jts1882 | talk  10:38, 1 February 2021 (UTC)

@Jts1882: done in the sandbox. Now

{{IPNI/sandbox |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.

{{IPNI/sandbox |mode=cs2 |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig.", International Plant Names Index (IPNI), Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens

BUT the use of ((..)) prevents the italicization of the taxon name, as it does in Trappist's example above, so isn't the solution. Substituting "." for the terminal "." may be the answer. Now fixed by Trappist. Peter coxhead (talk) 20:12, 1 February 2021 (UTC)

The use-as-written markup support was added to the module in response to this discussion.

—Trappist the monk (talk) 12:48, 1 February 2021 (UTC)

As there is an |authorlink= parameter in the citebook template for the |first= and |last= name parameters, I was wondering if we could incorporate an |authorlink2= parameter for the |last2= and |first2= parameters, as sometimes a work is authored by two or more noted authors who have articles here at Wikipedia. Would it be possible to add an |authorlink2=, and even an |authorlink3=, parameter to the citebook template? -- Gwillhickers (talk) 19:24, 1 February 2021 (UTC)

It's already there, though the hyphenated forms |author2-link= or |author-link2= are preferred. Kanguole 19:36, 1 February 2021 (UTC)

{{cite book |title=Title |last=Brown |first=AB |last2=Red |first2=CD |author-link1=Brown |author-link2=Red}}

Brown, AB; Red, CD. Title.

ad nauseum

—Trappist the monk (talk) 19:40, 1 February 2021 (UTC)

I tried using |authorlink2= before but it resulted in an "unrecognized parameter" error. I must have messed up the syntax or something. In any case, both the hyphenated and un-hyphenated types are working fine now.  Many thanks! -- Gwillhickers (talk) 23:39, 1 February 2021 (UTC)

Sorry if this is the wrong place to post this. In source reviewing Edvard August Vainio I discovered that PDFS with trans-title parameters (for Journals, at least) end up splitting up the PDF icon from the "PDF" abbreviation. E.g.:

• Hertel, Hannes; Gärtner, Georg; Lőkös, László (2017). "Forscher an Österreichs Flechtenflora" [Investigators of Austria's lichen flora] (PDF). Stapfia (in German). 104 (2): 1–211.

Is this something that can be fixed in the template's code...? Aza24 (talk) 07:57, 2 February 2021 (UTC)

Previous discussion at Help talk:Citation Style 1/Archive 69 § trans-title= splits PDF format indication

—Trappist the monk (talk) 11:27, 2 February 2021 (UTC)

Hello, the check for numerics in the |last= parameter does not appear to work in this case. Would have expected it to appear in Category:CS1 maint: numeric names: authors list

{{Cite web|last=2005-02-02T11:48:01|title=Must Have It has had it|url=https://www.retail-week.com/must-have-it-has-had-it/40302.article}}

2005-02-02T11:48:01. "Must Have It has had it".{{cite web}}: CS1 maint: numeric names: authors list (link)

Keith D (talk) 16:38, 2 February 2021 (UTC)

Help talk:Citation Style 1/Archive 64 § Check author names are not numeric for Cite web Alphanumeric 'names' are not detected because it is possible that such names might be legitimate.

—Trappist the monk (talk) 17:16, 2 February 2021 (UTC)

I have a citation to an article that showed up in an alumni magazine. The magazine itself was the Spring 2013 edition, and the article was posted to the website on June 27, 2013. However setting |publication-date=Spring 2013 gives me a Check date values error.

• Griset, Rich (June 27, 2013). "Figures of speech: Yuri Lowenthal '93 finds his voice". William & Mary Alumni magazine (published Spring 2013). Archived from the original on August 22, 2016. Retrieved July 20, 2016 – via WM.edu. {{cite web}}: Check date values in: |publication-date= (help)

Any suggestions? AngusW🐶🐶F (bark • sniff) 00:05, 4 February 2021 (UTC)

WP:SAYWHEREYOUREADIT: If you read the website, cite that; if you read the magazine, cite that. A single cs1|2 template may cite the magazine or may cite the website but not both at the same time. If you want to cite both: two templates. Of course, it is common to fudge that and cite the magazine with a courtesy link to the website.

—Trappist the monk (talk) 00:59, 4 February 2021 (UTC)

If identical versions of a work are published on paper and online, it's common to write the citation as if citing the paper version, even though it was read online; the URL would be included. But date and publication-date are aliases of each other, so only one should be in the citation. If they are indeed identical, the "Spring 2013" date would probably be best, because it would allow those who prefer to read online, and those who prefer to read paper, to find and confirm they have the correct publication. Jc3s5h (talk) 01:35, 4 February 2021 (UTC)

Your reference throws an error because |publication-date= is not supported programmatically the way |date= is. So a perfectly correct variable in one parameter is wrong when applied to another parameter of the same class. Why, you ask? I guess the answer is, why not? Expectations that things should make sense may be misplaced. Anyway, there's a fair chance |publucation-date= will soon be deprecated, so I wouldn't expect a fix. 66.65.114.61 (talk) 21:59, 4 February 2021 (UTC)

S2CID value currently is 230000000, but recent reference numbers are higher. Citation Style to be updated. Example: Reference ID 231590107 [1] https://www.semanticscholar.org/paper/Resilience-of-trees-and-the-vulnerability-of-to-in-Saintilan-Bowen/97f77008d54ab237b93fd71d72c30f5582d71872 Cited here: Bush encroachment Sekundemal (talk) 05:05, 25 January 2021 (UTC)

Thanks for reporting. Updated the limit to 235000000 in the sandbox.

--Matthiaspaul (talk) 07:23, 25 January 2021 (UTC)

An RFC that probably should have been held on this page has been posted at VPP. It asks: "Should non-hyphenated parameters be fully removed from the CS1|2 family of templates?" Please make your views known there, if you have them. – Jonesey95 (talk) 04:07, 11 February 2021 (UTC)

Just to drop a note that there should be a way to do i18n of the invisible_chars table in the Configuration module, since the names are used in error messages. Changing the names directly (e.g. from 'zero width joiner' to 'ゼロ幅接合子' in the case of jawiki) does not work well since the English name is referenced in the has_invisible_chars function. I had to fix the jawiki module by making the same name changes in that function. ネイ (talk) 14:34, 12 February 2021 (UTC)

I've hacked the module so that the invisible character finder uses the zwj or del character itself as the tested value in has_invisible_chars(). It isn't pretty but will do until I can figure out a better way to do it.

—Trappist the monk (talk) 19:44, 12 February 2021 (UTC)

Thank you! Looks good to me. ネイ (talk) 05:59, 13 February 2021 (UTC)

There is only one mention of the general-purpose {{citation}} template in this help page. It is widely used, convenient since it works for any source, and not controversial or deprecated, as far as I know. Is there any objection to adding it to the "Templates" list? Aymatth2 (talk) 12:48, 13 February 2021 (UTC)

No templates in headers.

I presume that you are referring to the table at Help:Citation Style 1 § Templates. That table is for cs1 templates. {{citation}} is a cs2 template and has its own page: Help:Citation Style 2. Until there is movement to fully merge Help:Citation Style 1 and Help:Citation Style 2 into a single help page, I don't think that the distinction should be blurred.

—Trappist the monk (talk) 12:59, 13 February 2021 (UTC)

The templates are not cs1 or cs2, but just differ in their default modes. They can all render cs1 or cs2.

{{Citation}} renders cs1 format if |mode=cs1 is specified.

{{Cite book}} renders cs2 format if |mode=cs2 is specified.

If we add {{citation}} to the "Templates" list we can include a note on |mode=cs1. I would support merging the two help pages, but that seems like a separate discussion. Aymatth2 (talk) 15:35, 13 February 2021 (UTC)

As at the Village Pump survey this was said to be the venue for feedback... For what it is or isn't worth, and just for the record, I was sufficiently incandescent about the recent removal of the freetext editors field to abandon using citation templates altogether. I have actually found this quite freeing; no more looking up the documentation repetitively and trying to squeeze whatever oddity I've got in front of me now into the increasingly tight straitjacket of the templates. No more trying to work out why what it says for CS1 doesn't work in CS2. No more magically appearing little red error notices. No more bot edits to check. Simples, as the meerkat says. Espresso Addict (talk) 00:22, 16 February 2021 (UTC)

@Espresso Addict: Yes, and you'll have something like John,S.; John, W. (eds) John Smith "Title of something Journal of Something" https://10.1111/10321.32156 volum. 34 issu. ("3") pages=32304-223, and not notice the dozen errors you have in it.

Everything you can put in CS1 works in CS2. And, unless you're doing something really weird, you don't have to learn anything much save for the basic |last#= |first#= |year= |editor#-last |editor#-first= |chapter= |title= |journal/magazine/...= |publisher= |location= |volume= |issue= |pages |doi= |isbn=, leaving out those you don't need.

Or even simpler just use <ref>{{doi|10.1155/....}}</ref> and let Citation bot fill in the stuff for you. Headbomb {t · c · p · b} 03:00, 16 February 2021 (UTC)

Well, you might generate a dozen errors per reference, but I don't.

If you choose to accept what the various citation tools create, great. I find they make such code soup of anything other than the simplest reference that it's nearly always easier to redo by hand. Even worse, absurd pages like one I saw the other day but can't now locate, where literally an entire column was filled with the authors for a single reference, which discourage readers from checking out the sources by making reference lists bloated. Espresso Addict (talk) 03:35, 16 February 2021 (UTC)

|display-authors=1 is there for those cases. Headbomb {t · c · p · b} 04:06, 16 February 2021 (UTC)

I use {{citation}} for all source definitions and stick them in a single-column alphabetic list in a "==Sources==" section after the {{reflist}}, then use {{sfn}} to cite pages in the sources. This declutters the article text and gives precise citations without duplication. For Google Books, reftag formats the citation. For other sources, I just cut and paste whatever identifying information I can find, stick in labels like |first= ... |last= ... |title= ... |url= ... etc., then glance at the result to make sure there are no error messages. I have provided all the information I can and {{citation}} has rendered it in the format that has evolved over the years through consensus among many editors. I can't imagine why I would try to do that by hand. Aymatth2 (talk) 14:07, 16 February 2021 (UTC)

No more magically appearing little red error notices. No more bot edits to check. And no more automatically-generated targets for {{sfn}}? David Brooks (talk) 23:55, 16 February 2021 (UTC)

I've just discovered a flaw in {{cite news}}. It does not allow one to fully cite a section of a newspaper that has separately numbered pages, such as a "Sport" or "Financial" section. Correctly citing an article on e.g. page 3 of the Sport section will mislead the reader to look on page 3 of the main section. It isn't possible to add "section=Sport", it just gives an ugly red error message. Roger (Dodger67) (talk) 18:38, 12 February 2021 (UTC)

Use |department=. --Izno (talk) 18:57, 12 February 2021 (UTC)

Thanks Izno - the mention of "section=department" is rather deeply buried in the template documentation. As "Section" is a fairly common term for such parts of newspapers, perhaps some adjustment could be done to make it a bit more obvious? Roger (Dodger67) (talk) 21:42, 14 February 2021 (UTC)

I doubt anyone will stop you modifying the documentation as you please. --Izno (talk) 21:45, 14 February 2021 (UTC)

Could we have the citation templates give one of those red warning messages when someone adds an archive-url that is identical to what's already in url, like here by Asdasdasdff? --bender235 (talk) 17:56, 19 February 2021 (UTC)

Like this?

and for |chapter-url= aliases

—Trappist the monk (talk) 19:00, 19 February 2021 (UTC)

That's what I meant, yes. But maybe it could be a bit more explicit on what's the problem. Simply "check value" might be misinterpreted as "there's a typo in the URL." --bender235 (talk) 21:12, 19 February 2021 (UTC)

What is best practice when using 'cite web' and:

1. The url is still live but no longer supports the text in the article.
2. An archived version of the webpage does support the text.

'url-status=live' is correct but puts the current, non-supporting URL first, before the archive url.

'url-status=dead' puts the text-supporting, archived url first, but the original url is not actually dead.

Thanks. Nurg (talk) 23:43, 19 February 2021 (UTC)

If it is the case the URL was usurped e.g. by spam, |url-status=usurped; if the living link is no longer useful, |url-status=unfit.

If it is the case the citation no longer supports the page content because the information in the citation was retracted, you should probably find a new citation. --Izno (talk) 01:08, 20 February 2021 (UTC)

Speaking of ASIN TLDs, we currently support com, co.jp, co.uk, com.au, com.br and com.mx as TLD special cases. According to:

• https://kdp.amazon.com/en_US/help/topic/G200652190
• https://github.com/self-unit/Project_3
• Amazon_(company)#Website
• de:Amazon#Internationale_Präsenz_und_weitere_Standorte

there are a few more combinations. Therefore I have added them to the |asin-tld= values supported by us. Unknown combinations now throw an error message:

Cite book comparison

Wikitext	{{cite book|asin-tld=xy|asin=6305277001|title=Title}}
Live	Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)
Sandbox	Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)

This will also show citations where |asin= and |asin-tld= have been mixed up. --Matthiaspaul (talk) 20:48, 25 January 2021 (UTC)

Also added error messages for |asin-tld= without |asin=, |class= without |arxiv=, and |pmc-embargo-date= without |pmc=.

Cite book comparison

Wikitext	{{cite book|asin-tld=uk|title=Title}}
Live	Title. {{cite book}}: |asin-tld= requires |asin= (help)
Sandbox	Title. {{cite book}}: |asin-tld= requires |asin= (help)

--Matthiaspaul (talk) 01:02, 27 January 2021 (UTC)

Rewritten. And, I removed the |class= test and error message because |class= is only supported by {{cite arxiv}} which in itself requires |arxiv= so a |class= requires |arxiv= is just redundant.

—Trappist the monk (talk) 23:19, 27 January 2021 (UTC)

This makes sense. :-) Thanks.

--Matthiaspaul (talk) 13:30, 21 February 2021 (UTC)

The following four CS1 categories indicate they have sub-categories, but when trying to open them, they only show "nothing found":

• Category:CS1 errors: dates‎
• Category:CS1 errors: external links‎
• Category:CS1 French-language sources (fr)‎
• Category:CS1 Yiddish-language sources (yi)‎

A similar problem was already reported some while ago at:

• Help_talk:Citation_Style_1/Archive_44#CS1_error_categories_show_as_having_subcategories,_but_I_don't_see_them
• Wikipedia:Village_pump_(technical)/Archive_166#Tracking_categories_show_as_having_subcategories,_but_I_don't_see_them
• Wikipedia:Village_pump_(technical)/Archive_166#CSD_backlog?
• T195397

--Matthiaspaul (talk) 01:07, 26 January 2021 (UTC)

I just had a look again and tried to open the above mentioned subcategories at Category:CS1 errors and Category:CS1 foreign language sources‎. It's still showing blue rather than white "arrows" there, indicating non-existent sub-categories. So, it is persistent rather than some temporary glitch. No idea how to fix this...

--Matthiaspaul (talk) 10:33, 21 February 2021 (UTC)

Null editing the parent & child doesn't fix this either.   ~ Tom.Reding (talk ⋅dgaf)  13:34, 21 February 2021 (UTC)

We have "chapter-url" but we need a parameter to fill in the archiveurl for that chapter (which is different from "url", which is for the whole book). I propose to add "chapter-archive-url" and "chapter-archive-date". -- love.wh 15:55, 18 February 2021 (UTC)

Previous discussions:

Help talk:Citation Style 1 § Archive url/date for chapters

Help talk:Citation Style 1/Archive 74 § Why no archive-chapterurl?

—Trappist the monk (talk) 16:08, 18 February 2021 (UTC)

• Having proposed this previously, I still agree. --bender235 (talk) 17:53, 19 February 2021 (UTC)

Same here (for a parameter name |archive-chapter-url= rather than |chapter-archive-url=, that is). --Matthiaspaul (talk) 13:56, 21 February 2021 (UTC)

Per a previous discussion, stable documented use, and a tangential discussion elsewhere on wiki, I've added a maintenance category for |postscript=s longer than 1 character.

Cite book comparison

Wikitext	{{cite book|author=A|postscript=none|title=T}}
Live	A. T
Sandbox	A. T

Cite book comparison

Wikitext	{{cite book|author=A|postscript=,|title=T}}
Live	A. T,
Sandbox	A. T,

Cite book comparison

Wikitext	{{cite book|author=A|postscript=.|title=T}}
Live	A. T.{{cite book}}: CS1 maint: postscript (link)
Sandbox	A. T.{{cite book}}: CS1 maint: postscript (link)

Cite book comparison

Wikitext	{{cite book|author=A|postscript=. A|title=T}}
Live	A. T. A{{cite book}}: CS1 maint: postscript (link)
Sandbox	A. T. A{{cite book}}: CS1 maint: postscript (link)

Citation comparison

Wikitext	{{citation|author=A|postscript=none|title=T}}
Live	A, T{{citation}}: CS1 maint: postscript (link)
Sandbox	A, T{{citation}}: CS1 maint: postscript (link)

Citation comparison

Wikitext	{{citation|author=A|postscript=,|title=T}}
Live	A, T,
Sandbox	A, T,

Citation comparison

Wikitext	{{citation|author=A|postscript=.|title=T}}
Live	A, T.
Sandbox	A, T.

Citation comparison

Wikitext	{{citation|author=A|postscript=. A|title=T}}
Live	A, T. A{{citation}}: CS1 maint: postscript (link)
Sandbox	A, T. A{{citation}}: CS1 maint: postscript (link)

Points of interest:

1. Whether this should be more than 1 byte (ASCII character) or more than 1 code point (Unicode character)?
2. Whether 1 should be configurable for other wikis with possibly different punctuation expectations? (Alleviates question 1 answer.)
3. Whether instead of quantity it assesses a specific pattern for goodness and emits the category otherwise (e.g. whether we should just look for 1 [.,;:] or similar)?
4. Whether the user-specified postscript matches the mode's postscript (for more cleaning like ref similar to the above).

--Izno (talk) 09:37, 30 January 2021 (UTC)

While |postscript= seems to have been intended to define the lead-out character originally, I have seen it being used to specify various longer "post scriptums" as well. I remember that some people even started edit-warring over it when I tried to reduce this to a dot or comma in the past. So, obviously, some people have a need to specify more than a single character there.

Therefore, I have, at several times in the past years, thought that it might be better to officially broaden the intended use-cases for this parameter also in the documentation - this would also better reflect the name of the parameter for post scriptums, rather than only for lead-out characters.

So, if we would enforce this to hold only a specific character (or none) in the future, we should have a good answer for why we actually do this. Is it just riding a principle even if it is against some people's needs, or is enforcing this actually necessary or beneficial for something? Is their actual harm done if people use it to specify more than a single character? What alternatives could we introduce for users needing to specify more than a single character there? Either way, is |postscript= the best parameter name for it?

--Matthiaspaul (talk) 17:43, 30 January 2021 (UTC)

The situations you describe (and several others) arise from the fact that |postscript= in the cs1/2 templates does not mean a postscript. Programmatically it is not even the lead-out character. It is the separator of the last displayed field, and very much a part of the "script", to use another wrong term for displayed output. The parameter-naming fog then causes all the unnecessary confusion and disputes. Give the parameter a proper, self-explanatory label and many of these situations may disappear. 98.0.246.242 (talk) 23:33, 30 January 2021 (UTC)

I do not personally care about the parameter name. If you (all) would like to introduce an alias and/or deprecate the current name, go for it. In the middle of another giant deprecation? Not sure about that. :) --Izno (talk) 07:59, 31 January 2021 (UTC)

As I said in the earlier discussion, |comment=, which is what |postscript= is being abused for, has never had sufficient support for implementation at this talk page. If users want it, they should get an RFC together and show there is a consensus for implementation.

That people have edit warred over it, I can only shake my head. You should point them to the documentation the next time. Since you framed it ambiguously, be aware that we generally support editors placing a comment after the citation-proper in references, so I should hope you were reducing it to a character by simply moving the end curly-brackets.

(None of my actual questions have been answered. ;) --Izno (talk) 07:59, 31 January 2021 (UTC)

A bit confused. Are you advocating for |comment= here? Not a good idea, I don't think. Supposing |postscript= is renamed into something more precise (|final-punctuation=? |end-mark=? there's many ugly choices) then I think the Unicode presentation would be best as it should be more flexible. I would think the answers to the rest follow from this choice. 98.0.246.242 (talk) 15:44, 31 January 2021 (UTC)

Are you advocating for |comment= here? ... I would think the answers to the rest follow from this choice. No. And flexibility may not be necessary. --Izno (talk) 17:25, 31 January 2021 (UTC)

Sure, I pointed to the documentation and engaged into a discussion, but to no avail. The editor was (and is) putting various identifiers, extra links and additional annotation into |postscript=. I moved the identifiers to the |id= parameter, the remainder out of the citation template (but inside the <ref> tags). One of his arguments for putting identifiers into |postscript= was that |id= was only for publisher-supplied identifiers, not for identifiers associated with the work by independent parties or at a later point in time. Of course, we do not make that distinction at present. (This might give us at least a hint how to further improve the templates, but that would be unrelated to |postscript= and hence off-topic here.)

--Matthiaspaul (talk) 12:25, 21 February 2021 (UTC)

only for publisher-supplied identifiers is certainly not how it is documented. Users who make stuff up drive me crazy. :^) --Izno (talk) 17:27, 21 February 2021 (UTC)

1. code points because this module is used in wikis that have multi-byte punctuation characters

2. |postscript= should be just 1 character

3. nah, presentation['ps_cs1'] and presentation['ps_cs2'] are sufficient

4. monkbot task 18 is currently removing |postscript=. for cs1 templates and |postscript=none for cs2 templates; having a maint cat or error message for these conditions seems a good idea.

Although I don't have much to suggest, the terminal punctuation article names 'end mark' and 'stop' as commonly used terms. We might also use |terminator= or |terminal-char=. 'Postscript' does suggest free-form text like an appendix ...

—Trappist the monk (talk) 00:00, 1 February 2021 (UTC)

Noted.

I am not sure you understood my third question. It would be something like

if not mw.ustring.match(s, '[%.:;,]') then -- a different configurable? list than in (2)

or

if mw.ustring.match(s, '%P') then -- %P is the complement of the Unicode punctuation group

for the condition as allowing only specific punctuation characters rather than the current

if #s > 1 then

. I don't know why someone would want to put something there that wasn't punctuation, so that is why I ask. --Izno (talk) 01:16, 1 February 2021 (UTC)

|end-mark= and |terminal(-char|-mark)= seem like good options, but I note the comma is not included in the group per our article. (I'll be back.) --Izno (talk) 01:20, 1 February 2021 (UTC)

I used |list-leadout= in {{Catalog lookup link}} also allowing for prepositions like "and", "or", "as well as" or " & ", but this can be emulated using |postscript=none, so it is not really necessary to support them as valid parameter input.

Searching for a better parameter name, I was thinking about |end-mark= as well, but, as you said, it is an established term and the common definition does not include the comma, so it might be misleading.

As a variation on your |terminal-mark=, |termination-mark= comes to my mind. "Termination mark" is an established term (alongside "continuation mark") in some programming languages and command-line interfaces, where it is used as input to end a command line prematurely before the physical end of the line (or to extend some logical line input beyond the physical line), whereas here we would use it for output. Still, it appears to be conceptually related and descriptive enough to avoid misinterpretation in the context of citation templates.

Ending the parameter name on |-mark= (or |-character=) seems desirable because this could be (re-)used to define special marks for other purposes as well would this become necessary in the future, whereas something like |-separator= might be already too narrow a definition.

--Matthiaspaul (talk) 12:25, 21 February 2021 (UTC)

I guess I gotta wonder: why shouldn't |postscript= (or its 'better' name if one can be found) be constrained to accept only the keyword none? If editors want to add a 'postscript' (of any sort), they can do so after the template's closing }}. Use |postscript=none to suppress cs1 terminal punctuation. When used with cs2, |postscript=none is ignored except that the template emits a maintenance message as described above. I've been noticing recently that there are quite a few instances of {{citation}} that are 'terminated' with a dot outside the closing }} which suggests that editors would rather do that than type the extra 12 characters required for |postscript=..

—Trappist the monk (talk) 14:32, 21 February 2021 (UTC)

Another possibility is that they are unaware of the parameter. Kanguole 14:36, 21 February 2021 (UTC)

Seems like a reasonable question. I know we recommend placing stuff outside the citation template but I also know that VisualEditor's reference tooling does not support 'mixed style' references (which is one reason one might choose to support |comment= also, on that note). I agree with Kanguole about users not knowing about it may be a reason. --Izno (talk) 17:28, 21 February 2021 (UTC)

When citing some journals using the automated formatting, we get this annoying error because it automatically loads the date as YYYY-MM, which isn't supported by cite journal. For instance.^[1] This happens with many Nature journals. I think the easiest solution is to simply allow this, as I believe the data is unambiguous.

FemkeMilene (talk) 15:21, 21 February 2021 (UTC)

This has been discussed and rejected many times, including at Wikipedia talk:Citing sources/Archive 49#No known day? Jc3s5h (talk) 15:31, 21 February 2021 (UTC)

Thanks for your quick reply, I now see why this leads to confusion. So the solution should be in the importing of the information, that the cite button automatically changes 2020-02 to February 2020, or just drops the month altogether. That sounds like Phabricator-difficulty? FemkeMilene (talk) 15:43, 21 February 2021 (UTC)

In general, I agree that the process of importing the information should reformat the date, if possible. One problem is that the publications may provide so many date formats that it isn't possible to automatically interpret them. Another problem is that there are so many add-ons that try to help editors add citations, that I have no idea what system you are writing about. When I edit an article, I don't see anything that will help me create a citation, other than merely insert <ref> and </ref> markup. Jc3s5h (talk) 15:51, 21 February 2021 (UTC)

(edit conflict)

What automated formatting? Here are two citations created by WP:RefToolbar; this one created from the source's URL:

{{cite journal |last1=Morlighem |first1=Mathieu |last2=Rignot |first2=Eric |last3=Binder |first3=Tobias |last4=Blankenship |first4=Donald |last5=Drews |first5=Reinhard |last6=Eagles |first6=Graeme |last7=Eisen |first7=Olaf |last8=Ferraccioli |first8=Fausto |last9=Forsberg |first9=René |last10=Fretwell |first10=Peter |last11=Goel |first11=Vikram |last12=Greenbaum |first12=Jamin S. |last13=Gudmundsson |first13=Hilmar |last14=Guo |first14=Jingxue |last15=Helm |first15=Veit |last16=Hofstede |first16=Coen |last17=Howat |first17=Ian |last18=Humbert |first18=Angelika |last19=Jokat |first19=Wilfried |last20=Karlsson |first20=Nanna B. |last21=Lee |first21=Won Sang |last22=Matsuoka |first22=Kenichi |last23=Millan |first23=Romain |last24=Mouginot |first24=Jeremie |last25=Paden |first25=John |last26=Pattyn |first26=Frank |last27=Roberts |first27=Jason |last28=Rosier |first28=Sebastian |last29=Ruppel |first29=Antonia |last30=Seroussi |first30=Helene |last31=Smith |first31=Emma C. |last32=Steinhage |first32=Daniel |last33=Sun |first33=Bo |last34=Broeke |first34=Michiel R. van den |last35=Ommen |first35=Tas D. van |last36=Wessem |first36=Melchior van |last37=Young |first37=Duncan A. |title=Deep glacial troughs and stabilizing ridges unveiled beneath the margins of the Antarctic ice sheet |journal=Nature Geoscience |date=February 2020 |volume=13 |issue=2 |pages=132–137 |doi=10.1038/s41561-019-0510-8 |url=https://www.nature.com/articles/s41561-019-0510-8 |language=en |issn=1752-0908}}

this one created from the source's doi:

{{cite journal |last1=Morlighem |first1=Mathieu |last2=Rignot |first2=Eric |last3=Binder |first3=Tobias |last4=Blankenship |first4=Donald |last5=Drews |first5=Reinhard |last6=Eagles |first6=Graeme |last7=Eisen |first7=Olaf |last8=Ferraccioli |first8=Fausto |last9=Forsberg |first9=René |last10=Fretwell |first10=Peter |last11=Goel |first11=Vikram |last12=Greenbaum |first12=Jamin S. |last13=Gudmundsson |first13=Hilmar |last14=Guo |first14=Jingxue |last15=Helm |first15=Veit |last16=Hofstede |first16=Coen |last17=Howat |first17=Ian |last18=Humbert |first18=Angelika |last19=Jokat |first19=Wilfried |last20=Karlsson |first20=Nanna B. |last21=Lee |first21=Won Sang |last22=Matsuoka |first22=Kenichi |last23=Millan |first23=Romain |last24=Mouginot |first24=Jeremie |last25=Paden |first25=John |last26=Pattyn |first26=Frank |last27=Roberts |first27=Jason |last28=Rosier |first28=Sebastian |last29=Ruppel |first29=Antonia |last30=Seroussi |first30=Helene |last31=Smith |first31=Emma C. |last32=Steinhage |first32=Daniel |last33=Sun |first33=Bo |last34=Broeke |first34=Michiel R. van den |last35=Ommen |first35=Tas D. van |last36=Wessem |first36=Melchior van |last37=Young |first37=Duncan A. |title=Deep glacial troughs and stabilizing ridges unveiled beneath the margins of the Antarctic ice sheet |journal=Nature Geoscience |date=February 2020 |volume=13 |issue=2 |pages=132–137 |doi=10.1038/s41561-019-0510-8}}

These two examples are slightly different but in both cases, the tool created |date=February 2020 so you must be using some other automated formatting tool. Perhaps you should raise this issue with the tool's maintainers.

The YYYY-MM date format is not supported by MOS:DATES. If you can get YYYY-MM added to MOS:DATES (first spend some time in the talk page archives), then cs1|2 will support that date format.

—Trappist the monk (talk) 15:52, 21 February 2021 (UTC)

I found it after toggling all of my preferences on/off. It's the 2017 wikitext mode's cite button (this also explains why some of my installed scripts aren't working!), which came from the VE. I'll leave a note there. Not going down the route of changing the MOS, just want this error to go away. FemkeMilene (talk) 16:57, 21 February 2021 (UTC)

Nice work. Fixing the tool is the correct route. A tool inserting ambiguous dates like "2004-05" is a bug that needs to be fixed. – Jonesey95 (talk) 17:31, 21 February 2021 (UTC)

I could swear that Citoid had been fixed for this. A search just for the word 'month' in Phabricator in the Citoid project gets nothing though except a quickly closed ticket on Nature's translator being badly wrong. :/ --Izno (talk) 17:38, 21 February 2021 (UTC)

Above, Izno made the following request:

Jc3s5h Please point to the guidance in question which bans it for publication dates. Thanks! My understanding is that you are in fact the incorrect editor here. --Izno (talk) 21:07, 23 February 2021 (UTC)

In the document which defines Citation Style 1, Help:Citation Style 1, we find the section Help:Citation Style 1#Date compliance with Wikipedia's Manual of Style, which states that Citation Style 1 adopts Wikipedia:Manual of Style/Dates and numbers § Dates, months, and years.

The "Acceptable Date Formats" table has a row for the yyyy-mm-dd format. In the "General use" column it states "No equivalent for general use", but lists 2001-09-02 in the "Only where brevity is helpful (refs,^[b] tables, infoboxes, etc.) column. Footnote b is not applicable because the "Manual of Style/Dates and numbers" is not just covering articles that use citation templates, it also covers articles that use other citation styles, and those other citation styles may have date formats that differ from what's in the "Manual of Style/Dates and numbers"

Later the "Dates, months, and years" section states

• Publication dates in an article's citations should all use the same format, which may be:
  • the format used in the article body text,
  • an abbreviated format from the "Acceptable date formats" table, provided the day and month elements are in the same order as in dates in the article body, or
  • the format expected in the citation style being used (however, all-numeric date formats other than yyyy-mm-dd must still be avoided).

I have struck out the last bullet because Citation Style 1 has adopted the Manual of Style for its dates, so that bullet does not apply. Jc3s5h (talk) 21:33, 23 February 2021 (UTC)

It seems clear to me that the guidance you are quoting explicitly and clearly states that these style dates are acceptable for references, and that you are striking things out because you don't like them rather than because they are actually inapplicable. —David Eppstein (talk) 21:37, 23 February 2021 (UTC)

Wow, you are so far off it's not funny. You're quite simply wrong about those lines and the interpretations for CS1/2. --Izno (talk) 21:38, 23 February 2021 (UTC)

(edit-conflict) I thought the times of alternative facts were over now...

As already replied in Help_talk:Citation_Style_1#ISO_date_display the list of applicable date formats explicitly lists yyyy-mm-dd as an allowed date format (for all kinds of dates past 1583, including publication dates) in references, tables, infoboxes, etc. Bullet points 2 and 3 apply both, and they both allow the format in citations.

--Matthiaspaul (talk) 21:57, 23 February 2021 (UTC)

(Edit conflict.) I believe the references in the "Manual of Style/Dates and numbers" refer to instances where a citation style is being followed in an article which requires a date format different from what is allowed in the rest of the articles. For example, this university library description of one of the styles used by the Council of Science Editors gives the date of a journal article as "2010 Jun". The editors of a Wikipedia article could decide to follow that style and use that format, although it would not be allowed were it not for the statements in "Manual of Style/Dates and numbers" like footnote b and the passage I struck. Jc3s5h (talk) 22:02, 23 February 2021 (UTC)

Thanks for providing your train-of-thought. I hope this doesn't ruin your day, but this remains a misinterpretation. The editors of an article cannot decide to follow a foreign style guide allowing "2010 Jun" as a valid date format, except for, perhaps, as a rare exception through a local consensus for (unknown) good reasons per WP:IAR. A "2010 Jun" format is simply not allowed by our MOS, whereas "yyyy-mm-dd" is (at least in refs, tables, infoboxes and certain other places, not in the prose).

--Matthiaspaul (talk) 22:43, 23 February 2021 (UTC)

It appears that Matthiaspaul has not read, or has forgotten, WP:CITEVAR. That guideline section allows any citation style, other than parenthetical referencing. On of the bullet points in that guideline section is

To be avoided

• adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;

So clearly, the advice contained in "Help:Citation Style 1" does not apply to articles that do not use citation templates. This is reinforced at Wikipedia:Citing sources#Citation templates and tools which states Citation templates can be used to format citations in a consistent way. The use of citation templates is neither encouraged nor discouraged: an article should not be switched between templated and non-templated citations without good reason and consensus". Jc3s5h (talk) 22:59, 23 February 2021 (UTC)

Help:Citation Style 1 may not apply to non-citation-style-1 citations, but MOS:DATEUNIFY does, and is clear about which date formats are acceptable and which are not. —David Eppstein (talk) 23:37, 23 February 2021 (UTC)

(edit conflict) So what? We are talking about acceptable date formats in citations in general, and "yyyy-mm-dd" specifically. This has nothing to do with providing citations with or without citation templates. While Help:Citation Style 1 applies to CS1 citation templates only (and is only a help page rather than a guideline, BTW), WP:CITEVAR, WP:CITESTYLE and MOS:DATE are guidelines applying to citations with or without citation templates.

Citations not using citation templates must still be compliant with our MOS. What they mean by "any" above is "any of the forms allowed by MOS". And "yyyy-mm-dd" happens to be one of the allowed forms in citations, whereas "2010 Jun" is not.

But since you do not seem to believe me, try to add "2010 Jun" style-dates to (non-templated) citations (to avoid the template's error message) in one article, and "yyyy-mm-dd" dates to citations in another article, and see what happens.

Tomorrow will be a better day.

--Matthiaspaul (talk) 23:45, 23 February 2021 (UTC)

Jc3s5h: the guidance "all-numeric date formats other than yyyy-mm-dd must still be avoided" clearly implies that one all-numeric date format, namely YYYY-MM-DD, is allowable. – Jonesey95 (talk) 00:16, 24 February 2021 (UTC)

"All-numeric date formats other than yyyy-mm-dd must still be avoided" appears in "Manual of Style/Dates and numbers", which in turn, applies to articles using any citation style allowed by WP:CITE. So if there are citation styles out there calling for 2021 Feb, or 2021-02-23, that's allowed. If there's a citation style out there calling for 2/23/21, that's forbidden because it's so atrocious that we decided to toss WP:CITEVAR aside and condemn that atrocity. But Citation Style 1, unlike other citation formats, has adopted the date formats in WP:MOSNUM, including the part about publication dates matching dates in article text, so what's OK if following Council of Style Editors style is not OK when following Citation Style 1. Jc3s5h (talk) 00:32, 24 February 2021 (UTC)

When 4 people tell you you're wrong, best think about moving on. Even besides that, these templates have been around time in module form. Consider that this format is not an error in |date=. --Izno (talk) 00:48, 24 February 2021 (UTC)

This would be nice to have. Lfstevens (talk) 22:45, 6 February 2021 (UTC)

Previous discussion: Help talk:Citation Style 1 § Why no archive-chapterurl?

—Trappist the monk (talk) 22:58, 6 February 2021 (UTC)

And here: Help_talk:Citation_Style_1#propose:_add_"chapter-archive-url"

--Matthiaspaul (talk) 15:20, 25 February 2021 (UTC)

Why does Template:Cite journal explain the page parameter as "The number of a single page in the source that supports the content" (and pages as "A range of pages in the source that supports the content")? The examples on the template page indicate that the parameter is used to give the page range of the entire journal article, not merely that of the part that supports the content. — Pajz (talk) 04:18, 24 February 2021 (UTC)

The way I have seen these used is that if the cite xxx template is invoked immediately after the passage that is being supported, the page(s) that support the passage is specified.

If the article frequently sites different page ranges in sources at different points in the article, the source is put in a bibliography and a template such as {{sfn}} is placed after the passage that is being supported, with the page(s) put in the sfn template. The bibliography entry does not have any page(s) parameter if it is a book, but if it is a journal, the pages parameter has the full page range of the journal article. Jc3s5h (talk) 14:16, 24 February 2021 (UTC)

There is no strict right or wrong here. Both, providing the page range or providing the individual pages is correct and useful depending on circumstances. In order to distinguish the two cases and even allow to specify and display both values in a coherent and consistent way, we will most probably have some dedicated parameter for it in the future, but for as long as this is not implemented (I might do it, but don't have the time for it at present) you can adopt a notation we came up with in previous discussions allowing to specify the article page range followed by the individual pages in square brackets, like in "pp. 5–12 [6, 8]" (meaning that the cited article goes from page 5 to 12, and the relevant pages in there supporting the statements are the pages 6 and 8) or "pp. 5–12, 14–15 [6–7, 12]" (meaning that the article goes from page 5 to 12 and 14 to 15, and the relevant pages in there are 6, 7 and 12). For some more background see Help_talk:Citation_Style_1/Archive_74#Citing_section_of_journal_article? and the list of older threads listed there.

If it is important to source each statement in our article individually by a specific page, the {{sfn}} approach is also a solution. It has its own set of pros and cons, so it depends on the article and source what might be preferable in a situation.

If everything goes well, a Mediawiki Cite extension should be rolled out later this year which will also provide for more granular sourcing options through improved <ref> tags, see meta:WMDE_Technical_Wishes/Book_referencing. --Matthiaspaul (talk) 17:53, 24 February 2021 (UTC)

Thanks, well, that has been my understanding—my question was really meant quite literally: Why does Template:Cite journal say otherwise? As both of you seem to confirm, in a journal article, page(s) is primarily used to indicate the range of the journal article, and thus the description "A range of pages in the source that supports the content" strikes me as somewhat misleading. — Pajz (talk) 20:21, 24 February 2021 (UTC)

I see. The reason is probably lack of time as well. The documentation is not always up to date. Better now? --Matthiaspaul (talk) 21:14, 24 February 2021 (UTC)

Thank you, Matthiaspaul. — Pajz (talk) 09:42, 26 February 2021 (UTC)

Module:Citation/CS1 line 3982: table.insert (error_list, '<code class="cs1-code">&#124;year= / &#124;date= mismatch</code>');

This error message should be moved to error_conditions table in the Configuration module. ネイ (talk) 06:02, 13 February 2021 (UTC)

Done, but not the way you wanted. Date errors are collected into a sequence table and then presented using error_conditions.bad_date. The mismatch error message is assembled using the format string in messages['mismatch'].

See Module talk:Citation/CS1/testcases/dates at test_year_date_mismatch. The apparent errors there are due to a refinement of the message formatting.

—Trappist the monk (talk) 16:19, 13 February 2021 (UTC)

Thank you. It looks weird that an error message is in messages instead of error_conditions, but I am good as long as I can do i18n. ネイ (talk) 11:26, 28 February 2021 (UTC)

Hello, unsure if this is the best place to bring this up as it is probably browser related than the templates but may be something could be done in the templates to avoid the problem further down the line.

The problem is with the all numeric ISO sytle date formats being displayed in dd-mm-yyyy format when there is scripting in the templates.

For example Firefox rendering of

{{Cite journal|last=العنانی|first=هیام حمدی|date=2019-02-01|title=أحمد محمود نجیب رائد أدب الأطفال|volume=18|issue=18|pages=199–205|journal=test}}

العنانی, هیام حمدی (2019-02-01). "أحمد محمود نجیب رائد أدب الأطفال". test. 18 (18): 199–205.

shows the date as 01-02-2019. Keith D (talk) 00:40, 22 February 2021 (UTC)

The first thing to do would be to set the script-title instead:

• العنانی, هیام حمدی (2019-02-01). أحمد محمود نجیب رائد أدب الأطفال. test. 18 (18): 199–205.

Which doesn't help all that much. :^) --Izno (talk) 00:56, 22 February 2021 (UTC)

In the first example, it looks like the title is rendered first, with a quotation mark at the end of it, followed by a space, a full stop, the date in RTL format, the first name, a space, the last name, and a quotation mark. Something like:

Title" .(DD-MM-YYYY) First ,Last". rest of citation properly rendered.

It looks like the right-to-left formatting could be rendering improperly for some reason. I copied the code above to a text editor to check for hidden characters, and I did not find any. – Jonesey95 (talk) 03:55, 22 February 2021 (UTC)

It is rendering reasonably correctly given requirements for the bidirectional algorithm. See the nice summary talk by the WMF staffer responsible for such things in MediaWiki). --Izno (talk) 04:12, 22 February 2021 (UTC)

May be we should be putting a restriction on using IOS dates when this situation arises so we do not get them in the dd-mm-yyyy format. Keith D (talk) 13:42, 22 February 2021 (UTC)

As the ISO 8601 format is particularly important in an international context, I don't think it would be a solution at all trying to avoid it in foreign language citations. Instead, we should try to improve the template so that the citation gets displayed correctly also with foreign language browser settings. For someone who does not speak any Arabic languages, what would be the correct display of an 2021-02-23 ISO date on a browser with Arabic language settings? 2021-02-23, 23-02-2021 or 32-20-1202? --Matthiaspaul (talk) 19:59, 23 February 2021 (UTC)

Keith D does not say whether this template is being used in the English Wikipedia, but since the parameter names are in English, I'll presume that it is. I observe the problem is resolved if the author's name is given in Roman characters:

Cite journal comparison

Wikitext	{{cite journal|date=2019-02-01|first=John|issue=18|journal=test|last=Smith|pages=199–205|title=أحمد محمود نجیب رائد أدب الأطفال|volume=18}}
Live	Smith, John (2019-02-01). "أحمد محمود نجیب رائد أدب الأطفال". test. 18 (18): 199–205.

Considering that the English Wikipedia gives the titles about all people in Roman characters, even if the person's native language uses a different alphabet, this seems appropriate. Jc3s5h (talk) 20:00, 23 February 2021 (UTC)

In additon, Citation Style 1 adopts the date rules in WP:DATE. That says that YYYY-MM-DD format should only be used where space is limited; that would not include the article text. The publication date may be in the same format as article text dates, or abbreviations of those, preserving the month and day order. For example, if dates in an article were written like February 23, 2021, then your publication date could be February 1, 2019, or Feb 1, 2019.

Likewise, if dates in the article were written like 23 February 2021, then your publication date could be 1 February 2019 or 1 Feb 2019. But 2019-01-02 is not correct for a publication date. Jc3s5h (talk) 20:13, 23 February 2021 (UTC)

Not in the article prose, but it is correct in citations (and very commonly used there). --Matthiaspaul (talk) 20:27, 23 February 2021 (UTC)

Matthiaspaul is wrong. In Citation Style 1 YYYY-MM-DD format may be used for access dates and archive dates, but not for publication dates. Jc3s5h (talk) 20:38, 23 February 2021 (UTC)

@Jc3s5h: Please point to the guidance in question which bans it for publication dates. Thanks! My understanding is that you are in fact the incorrect editor here. --Izno (talk) 21:07, 23 February 2021 (UTC)

It is too cumbersome to answer in an existing thread because of talk page indentation customs, so I will answer in a new thread. Jc3s5h (talk) 21:12, 23 February 2021 (UTC)

Here. --Matthiaspaul (talk) 14:02, 24 February 2021 (UTC)

(edit-conflict) Certainly not, the date format used in citations is independent of the date format used in the prose. The ISO date format is used all over the place in citations (actually, for citations using the ISO date the most common variation is to consistently use it for all dates: (publication) date, access dates and archive dates). WP:DATE specifically knows:

"Acceptable date formats:"

"Only where brevity is helpful (refs, tables, infoboxes, etc.)"

"2001-09-02" "Use yyyy-mm-dd format only with Gregorian dates from 1583 onward"

And WP:CITESTYLE adds:

"Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD, because of the ambiguity concerning which number is the month and which the day. For example, 2002-06-11 may be used, but not 11/06/2002." (boldface by me)

But let's focus on what this thread is about:

From your example above I take it that the correct display of a date like 2019-02-01 on a browser with Arabic language settings would still be 2019-02-01, not 01-02-2019, not 10-20-9102? Is that your assumption, or do you know for sure? I do not speak these languages therefore I do not really know and can only assume what might be correct for them, so this is a genuine question.

--Matthiaspaul (talk) 21:15, 23 February 2021 (UTC)

I found this used in Abdul-Tawab Yossef in the English Wikipedia. May be we need to have some sort of tracking for this situation and do some clean-up on the articles that it appears in. Keith D (talk) 20:52, 23 February 2021 (UTC)

This discussion appears to have gone sideways. This thread should not be about date formats. This looks like a rendering bug, some sort of unclosed or misplaced RTL formatting code, when |first= is in Arabic (or another RTL language; see the final Hebrew example, which renders slightly differently but still incorrectly). Here are some test cases:

Cite journal comparison (Last and First in Arabic)

Wikitext	{{cite journal|date=2019-02-01|first=هیام حمدی|issue=18|journal=test|last=العنانی|pages=199–205|title=Title|volume=18}}
Live	العنانی, هیام حمدی (2019-02-01). "Title". test. 18 (18): 199–205.
Sandbox	العنانی, هیام حمدی (2019-02-01). "Title". test. 18 (18): 199–205.

Cite journal comparison (Last in Arabic)

Wikitext	{{cite journal|date=2019-02-01|first=First|issue=18|journal=test|last=العنانی|pages=199–205|title=Title|volume=18}}
Live	العنانی, First (2019-02-01). "Title". test. 18 (18): 199–205.
Sandbox	العنانی, First (2019-02-01). "Title". test. 18 (18): 199–205.

Cite journal comparison (First in Arabic)

Wikitext	{{cite journal|date=2019-02-01|first=حمدی|issue=18|journal=test|last=Last|pages=199–205|title=Title|volume=18}}
Live	Last, حمدی (2019-02-01). "Title". test. 18 (18): 199–205.
Sandbox	Last, حمدی (2019-02-01). "Title". test. 18 (18): 199–205.

Cite journal comparison (First in Hebrew)

Wikitext	{{cite journal|date=2019-02-01|first=א|issue=18|journal=test|last=Last|pages=199–205|title=Title|volume=18}}
Live	Last, א (2019-02-01). "Title". test. 18 (18): 199–205.
Sandbox	Last, א (2019-02-01). "Title". test. 18 (18): 199–205.

Additional troubleshooting is welcome. – Jonesey95 (talk) 00:08, 24 February 2021 (UTC)

Arabic numerals are weakly directional. As I understand it, their 'directionality' is controlled by the directionality of adjacent (preceding) text. So, without markup to control directionality, a YMD date that follows strongly directional Arabic-script text will assume the directionality of that text. Groups of digits (year is a group, month is a group, and day is a group) maintain their internal organization (most significant digit is always the leftmost digit). Here, in plain text the last name from your examples follows the YMD date so to English readers the rendering of the date is correct:

• 2019-02-01 العنانی

As I wrote this next example, I placed the last name at the left margin, added a space character at the right end of the Arabic-script text and then pasted the date to the right of that space character. Because the Arabic-script text is strongly directional and the date is weakly directional, the browser repositions the date to the right and applies rtl rules to the digit groups:

• العنانی 2019-02-01

This example was created in the same way as the previous example except that I wrapped the date in <bdi>...</bdi> tags (bidirectional isolation) before pasting. The markup overrides the directionality that had been applied to the previous example:

• العنانی 2019-02-01

We could apply <bdi>...</bdi> tags to |date= when the cs1|2 template has an author and when the first character of |date= is a digit. MDY dates, because English is strongly ltr are not troubled by the directionality of the Arabic script but DMY dates are:

• العنانی February 1, 2019
• العنانی 1 February 2019

—Trappist the monk (talk) 00:59, 24 February 2021 (UTC)

Thank you, Trappist, for the great explanation. Much appreciated.

--Matthiaspaul (talk) 10:40, 24 February 2021 (UTC)

And I agree that we should <bdi>...</bdi>-frame all dates, which could be affected by this. --Matthiaspaul (talk) 10:04, 28 February 2021 (UTC)

{{cite journal|title=Title|journal=Journal|issue=1{{en dash}}12 {{interp|ed. interpolation}}}}

"Title". Journal (1–12 [ed. interpolation]).

What happened? Used to work. 64.18.9.208 (talk) 15:37, 22 February 2021 (UTC)

Those are buggered-up stripmarkers; they should look something like this:

?'"`UNIQ--nowiki-000000B3-QINU`"'?ed. interpolation?'"`UNIQ--nowiki-000000B4-QINU`"'? question marks here replace the delete character that begins/ends a stripmarker

Someone added these two lines to hyphen_to_dash()

	str = str:gsub ('[^%-]%-%-%-[^%-]', '—'); -- replace triple-hyphen with emdash
	str = str:gsub ('[^%-]%-%-[^%-]', '–'); -- replace double-hyphen (as found in BibTeX entries) with endash

In this case, it's the second of those that deletes the Q and the n and replaces the -- with an endash. Because the stripmarkers are now corrupted, MediaWiki doesn't replace them with the nowiki'd content.

—Trappist the monk (talk) 20:15, 22 February 2021 (UTC)

Matthias did, somewhere in here. I do not recall seeing a discussion on the point and believe the change should be reverted in the next update. --Izno (talk) 21:13, 22 February 2021 (UTC)

Thanks for reporting this, IP. This obviously isn't working as intended. It can be fixed so that it correctly translates double/triple hyphens into en/em dashes while leaving double-hyphens in stripmarkers untouched. --Matthiaspaul (talk) 19:17, 23 February 2021 (UTC)

Let's have a discussion about having those first, seeing as we haven't had that. I'm of the basic preference we should not, as the behavior is sufficiently niche and I doubt documented. There's no reason to support that in a set of generalist templates. --Izno (talk) 19:21, 23 February 2021 (UTC)

I recall that I acted on some complaint about inconsistent metadata, but I can't find this again now as well. Could have been somewhere else.

Either way, I think, anything we can do that helps to generate more consistent output is a good thing. As double- and triple-hyphens don't have a meaning different from their traditional uses emulating en and em dashes with ASCII characters in this context (well, except for this obscure strip-marker thing above), automatically translating them to their Unicode equivalents does not harm (if implemented correctly, that is), and it would even be helpful to those who have problems to enter en or em dashes directly. We are doing all kinds of other translations like this as well, so this is just completing the set, not introducing something really new. Adding it to some maintenance cat and/or throwing an error message regarding unsupported input formats would be another option, but would be less convenient to users (and require more code).

--Matthiaspaul (talk) 10:37, 28 February 2021 (UTC)

I'm not sure I understand exactly how this offered explanation applies here. The stripmarkers are exposed because it seems the module code is caught in a racing condition, with a mis-applied edit. A bit of testing would have probably made this obvious. Moreover there was no prior discussion of the specific changes that I am aware of. So now I suppose we have to wait for the next update. Another example of sinning in haste and repenting at leisure. 98.0.246.242 (talk) 01:48, 1 March 2021 (UTC)

I came across this citation at Jack Johnson (boxer), which has a missing URL tag despite having an SSRN: ^[1]. Any idea what's happening here? {{u|Sdkb}} ^talk 19:03, 24 February 2021 (UTC)

Don't use cite web unless you put a URL in. That's how that template has always worked. An identifier is not a URL.

"The Johnson–Jeffries Fight and Censorship of Black Supremacy". SSRN 1563863.

--Izno (talk) 19:06, 24 February 2021 (UTC)

Okay, thanks! {{u|Sdkb}} ^talk 19:26, 24 February 2021 (UTC)

For this one, use {{cite SSRN}} Headbomb {t · c · p · b} 21:45, 24 February 2021 (UTC)

I think for that one it's better to use {{cite journal}}, with the journal publication metadata from the ssrn landing page, and the ssrn id. That way readers can know that it has been reliably published and is not just a preprint. —David Eppstein (talk) 21:51, 24 February 2021 (UTC)

If they're referencing the published version, yes, for sure. Headbomb {t · c · p · b} 00:45, 25 February 2021 (UTC)

The published version is the reliable version. If the version they are citing is different from the published version in any important way, then it also is problematic with respect to reliability. —David Eppstein (talk) 02:06, 25 February 2021 (UTC)

This is a fundamental design question relating to Wikipedia infrastructure. It has probably been discussed but I do not know where (hints appreciated). It does not seem to have been implemented. If Wikipedia were designed like any sane relational database, every source (book, website) would have its own record (i.e. a unique page) with fields (author name, publisher, date etc) already populated and verified. For any given source this would be done once, ever. And then any article in the whole encyclopedia could reference the source with a simple {{ cite book |id=x}} or {{ cite website |id=X }} (adding page number or URL path for precision). Unique IDs exist already: ISBN for books, registered domains for websites. Instead, authors are having to laboriously re-enter this data for every article, with the obvious risk of corruptions and disparities. This situation seems almost unbelievably inefficient. What am I missing? Rollo (talk) 22:32, 3 March 2021 (UTC)

@Rollo: You may be looking for {{cite q}}. Wikipedia tried cite doi and didn't like it, but maybe cite q will go better. --Izno (talk) 22:46, 3 March 2021 (UTC)

@Izno: Amazing! Yes, that is exactly what I am looking for, thanks for the tip. And indeed, let's hope adoption goes better. Hard to see how it would not, given what a huge timesaver it must be to do things this way. Rollo (talk) 11:29, 4 March 2021 (UTC)

Further to what Editor Izno stated, ISBNs, while they are supposed to be unique, are not. Citoid (used by RefToolbar and by the abomination that is Visual Editor) draws information from WorldCat to fill citations in a manner somewhat akin to what you describe. WorldCat is full of these non-unique ISBNs. There is a move afoot to do something like you suggest. See WikiCite (but don't hold your breath for that to happen any time soon ...)

—Trappist the monk (talk) 23:00, 3 March 2021 (UTC)

I believe the problem with bad ISBNs of any kind was more due to governance issues with the various ISBN authorities. Some of them were pretty lax and the International body had been aloof. It seems things are run much better now, but of course that doesn't help with these "historical" ISBNs. 98.0.246.242 (talk) 04:31, 4 March 2021 (UTC)

The modern "unique" ISBNs are in fact less in line with Wikipedia's purposes (the main purpose in this context being WP:V). A 21st-century book can be published concurrently in several formats (paperback, eBook, ...), by different publishers (e.g. one publisher in the UK, and another publisher in the US), and there may be reprints, etc. In a modern approach, all these editions have different ISBNs. Now, for Wikipedia's purposes, i.e. WP:V, it really doesn't matter whether the reference to the source is to the 'linen bound' or 'paperback' version. But one version (e.g. a pre-ISBN original print) may be available for free at archive.org, large sections of another print of the same book (e.g. one published in 10-digit ISBN era) may be available at Google books, while its most recent print, by yet another publisher, and with a "modern" ISBN, is only available as dead wood copy. WP:V aims at assisting Wikipedia editors checking ("verifying") article content to reliable sources: in the case of the example above, giving only the "modern" 13-digit ISBN is counterproductive to a swift verification of article content. Similar for paperback vs. ebook (etc): one may (partially) accessible online, while another isn't. Giving only one modern ISBN can, in this case, also be counterproductive to WP:V expectations. For clarity, a reliable source which is only available off-line is of course OK for WP:V, but why give the impression a book is only available off-line when it is accessible on-line? Besides, what I'm trying to say here also applies when only paper copies exist: a Wikipedia editor may own a 'paperback' version, while the reference in an article gives the ISBN for a 'hardcover' version of the same book: ideally we would have a unique identification of a book with a certain content, independent of the distribution format – when the reference uses page numbers the identification would ideally be for books with the same content and the same pagination. None of that is the same as a unique identification via a modern ISBN number (except if there's only one single edition of the book, but that is becoming rare nowadays as modern books are often concurrently published in paper and eBook versions, and older books are easily republished in eBook format, with a new ISBN). --Francis Schonken (talk) 07:41, 4 March 2021 (UTC)

To verify content needs a link to the source that was actually used - we cannot use an old edition to verify what is said in a later edition and vice-versa - contents may vary with time and location of publication and even with consecutive publication of different print and electronic editions, things like page numbering will differ. Automatic systems for filling in references are limited by the fact that often the databases which these are based on, like Worldcat are error-strewn, thus there are often dozens of entries for the same edition of the same book, or worldcat entries that give incorrect author/editor information - (for example people who have been dead for 20 years listed as author/editor for editions of annuals like Jane's All the World's Aircraft). And then of course you still get high quality books by reputable publishers issued with the wrong ISBN number.Nigel Ish (talk) 08:56, 4 March 2021 (UTC)

Re. "To verify content needs a link to the source that was actually used" – no, it doesn't. Off-line sources are perfectly acceptable (see WP:V). The source needs identification (not necessarily a "link"), and ISBNs are far from the ideal tool for unique identification of book content (that is, in Wikipedia's WP:V context, which is the context of importance here). --Francis Schonken (talk) 09:26, 4 March 2021 (UTC)

Link is perhaps the wrong word, but WP:SAYWHEREYOUGOTIT still applies - you can't necessarily say that two different editions of the same work say the same thing - information may have been superceded in later editions or been removed for spacing reasons, and page numbering may differ between different format versions issued at the same - it's no good pointing to page 32 of a book unless you also say which edition of the book to point to - if you point to ta different edition to that used to cite the information, then there is every chance that verification attempts will fail.Nigel Ish (talk) 13:54, 4 March 2021 (UTC)

WP:SAYWHEREYOUGOTIT does not speak about quality of references, only about a minimum. It does not prevent a reformatting or expansion of references in view of a better compliance to WP:V. Neither does it necessitate usage of an ISBN. Not even for books. Not even for books that have an ISBN. I don't even see what WP:SAYWHEREYOUGOTIT has to do with this.

Example: page 1 of ISBN 0199248842 is exactly identical to page 1 of ISBN 039304825X, and so on for hundreds more pages of these two publications of the same book. And the book still has a few other ISBN numbers (all with identical pagination). In which case none of these ISBN numbers is a unique identification number for the content of this book that can be used for references in Wikipedia (well, it frequently is). So, only giving one of these ISBNs (without even naming title, author, publication date, publisher), is not very generous (as in: not all too helpful) WP:V-wise for those who want to verify Wikipedia's content, although, of course, any of these ISBNs, with a page number, could be a "SAYWHEREYOUGOTIT" for the Wikipedia editor who based mainspace content on it. But for the OP's question: no, only an ISBN number without other particulars of the publication (or, in an opposite direction: not mentioning the ISBN of a reference work that has an ISBN), may get you past WP:SAYWHEREYOUGOTIT, but is indeed "not enough" WP:V-wise. --Francis Schonken (talk) 14:31, 4 March 2021 (UTC)

I feel a bit of redundancy, giving the ISBN but also the title, author, publisher, etc. makes some forms of vandalism more obvious and future-proofs the citation in case the ISBN data providers go away. Jc3s5h (talk) 15:25, 4 March 2021 (UTC)

"[[H]]". PMC 12345. {{cite journal}}: Cite journal requires |journal= (help); URL–wikilink conflict (help). Same with free doi, etc. AManWithNoPlan (talk) 02:13, 24 February 2021 (UTC)

That doesn't look like a bug. You can't have a wiklink in |title= and also a URL. PMC provides a URL. – Jonesey95 (talk) 04:19, 24 February 2021 (UTC)

If you really want to override the pmc link, the way to do that is to use |title-link=:

{{cite journal|title=H|title-link=H|pmc=12345}}

produces

"H". PMC 12345. {{cite journal}}: Cite journal requires |journal= (help)

(This only lets you link the whole title. But in general, if you wikilink a title, you should wikilink the whole title, to an article about the source being linked; do not link title words to articles about those words.)

—David Eppstein (talk) 06:06, 24 February 2021 (UTC)

I would consider this as a bug (introduced with the original implementation of auto-linking in early 2020). The correct behaviour would be to detect this special case and mute the identifier-derived URL. I already mentioned this at Help_talk:Citation_Style_1/Archive_71#Manual_override_of_auto-linking when I implemented auto-link-overriding, but have not come around to fix it yet.

One workaround is to use |title-link= to provide the link, as David suggests above. Another way is to set |title-link=none. The latter method even allows to link individual words in the title (although this is not recommended).

{{cite journal|title=A[[B]]C|title-link=none|pmc=12345|journal=Journal}}

"ABC". Journal. PMC 12345.

It might be worth noting that the COinS metadata remains clean and still contains the title as rft.atitle=ABC only (that is, without the embedded link):

'"`UNIQ--templatestyles-000000D8-QINU`"'<cite class="citation journal cs1">"A[[B]]C". ''Journal''. [[PMC (identifier)|PMC]]&nbsp;<span class="id-lock-free" title="Freely accessible">[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12345 12345]</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=ABC&rft_id=https%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fpmc%2Farticles%2FPMC12345%23id-name%3DPMC&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+75" class="Z3988"></span>

--Matthiaspaul (talk) 13:43, 24 February 2021 (UTC) (updated 22:07, 5 March 2021 (UTC))

Some recent edits at Triple H (see ref [253]) show that bad input can give the error shown:

{{cite web|url=https://example.com|title=Example|date=February 6, 2019|osti-access=February 19, 2021}}

Lua error in Module:Citation/CS1/Utilities at line 127: Called with an undefined error condition: invalid_param_val.

Does something in the module need tweaking? Johnuniq (talk) 06:58, 5 March 2021 (UTC)

Backtrace as provided there:

    [C]: in function "error"
    Module:Citation/CS1/Utilities:127: in function "set_message"
    Module:Citation/CS1/Identifiers:1416: in function "extract_id_access_levels"
    Module:Citation/CS1/Identifiers:1516: in function "identifier_lists_get"
    Module:Citation/CS1:3022: in function "citation0"
    Module:Citation/CS1:4123: in function "chunk"
    mw.lua:518: ?
    [C]: ?

--Izno (talk) 07:14, 5 March 2021 (UTC)

Fixed in sandbox:

{{cite web/new|url=https://example.com|title=Example|date=February 6, 2019|osti-access=February 19, 2021}}

"Example". February 6, 2019. {{cite web}}: |osti-access= requires |osti= (help); Invalid |osti-access=February 19, 2021 (help)

—Trappist the monk (talk) 12:16, 5 March 2021 (UTC)

The CS1 templates that support |url= and |url-status= should also support the following from {{dead link}}:

fix-attempted

Set this to "yes" if you have tried unsuccessfully to find an archived copy, or a copy with a different URL. This will put the page in Category:Articles with permanently dead external links. Note that a link that is not in the Internet Archive (Wayback machine) can very often be found, e.g. by a search for the full title, in quotes, on the original Web site or the Internet at large, if the Wayback machine fails.

We lose functionality by recording the link death in the citation template instead of with that stand-alone template (which we generally should not be using except for citations anyway; if a link in "External links" has gone dead, it should just be removed since the entire section is optional and is not part of the encyclopedia content per se, i.e. there is no WP priority to fix dead links in that section, but a high priority to do so in citations that have broken).  — SMcCandlish ☏ ¢ 😼  11:54, 5 March 2021 (UTC)

See this. The doi parameter is, by the nature of things, effectively an URL, so it shouldn't be causing an error. Unless this is intentional? RandomCanadian (talk / contribs) 04:24, 6 March 2021 (UTC)

The problem has nothing to do with the doi. If you removed the doi from the citation you would get the same error message. The problem is that {{cite web}} is only for web pages (with urls) and you are trying to use it for something that you are not linking as a web page (with a url). I think {{cite encyclopedia}} is probably the right choice for this citation, or you could use {{cite Grove}}. —David Eppstein (talk) 05:01, 6 March 2021 (UTC)

Had no clue that existed. Still counter-intuitive because a doi is usually also a valid url; i.e. in this case if you just append "https://" in front of "10.1093/gmo/9781561592630.article.13655" then you have a perfectly valid url... The template should recognize that and not throw an error. Cheers, RandomCanadian (talk / contribs) 05:17, 6 March 2021 (UTC)

It is not a url. It tells you the identity of the document you are looking for, not the address on the internet that you should get it from. You have to go through the doi system (the https://doi.org server) to convert it into a url, and the result of the conversion could theoretically be different depending on when you did it or where you were coming from when you did it. In any case, even when you are linking to journal articles or books or newspaper articles by their urls, it is better to use the {{cite journal}} or {{cite book}} or {{cite news}} templates so that the citation has the other appropriate metadata, rather than just using {{cite web}} for everything. As the cite web documentation says, it is "for web sources that are not characterized by another CS1 template". —David Eppstein (talk) 05:39, 6 March 2021 (UTC)

Correct. If I may be excessively pedantic, the doi.org servers do not "convert" the doi into a url, they resolve it, using their authoritative database (the directory of all doi numbers). Sorry about the geekfest. 69.193.220.107 (talk) 18:52, 6 March 2021 (UTC)

Shall we deprecate some more nonhyphenated parameters? Specifically:

|booktitle= – None from CS1

|chapterurl= – 9, None from CS1

|episodelink= – 0

|mailinglist= – None from CS1

|mapurl= – All bing URLs

|nopp= – None from CS1

|publicationdate= – None from CS1

|publicationplace= – 0

|serieslink= – 0

|transcripturl= – 0

We might also include |origyear= but is still used in quite a few articles (search).

—Trappist the monk (talk) 14:02, 3 February 2021 (UTC)

• Support standardization, especially given their mostly extremely low usages. |origyear='s 10k usage vs. |orig-year='s ~60k usage might find some resistance, so I support deferral there, if necessary.   ~ Tom.Reding (talk ⋅dgaf)  14:24, 3 February 2021 (UTC)
• Support standardization. Also, many of the above numbers are greatly inflated by other templates and urls that have the searched for phrase. AManWithNoPlan (talk) 15:17, 3 February 2021 (UTC)
• Support the continued move away from unhyphenated multi-word parameters, including |origyear=. With any other template, it would have been the work of a few days to standardize on one style of parameter name and convert all of the transclusions. The only reason that the process for CS1 templates is different is that there are millions of transclusions instead of hundreds. – Jonesey95 (talk) 17:23, 3 February 2021 (UTC)

Note - none of the above are from cite/citation template parameters. AManWithNoPlan (talk) 22:19, 3 February 2021 (UTC)

Thanks for that. I've marked all but |origyear= as deprecated. We might add that param to Wikipedia:AutoWikiBrowser/Rename template parameters as a way to push the numbers down.

—Trappist the monk (talk) 23:09, 3 February 2021 (UTC)

@Trappist the monk: Should we add |original-year= as an alias for |orig-year=? –MJL ‐Talk‐^☖ 18:21, 7 February 2021 (UTC)

Could. I'm more-or-less indifferent. If we do add a 'long-form' name, oughtn't it to be |original-date=? After all, |orig-date= is the 'new' canonical form...

—Trappist the monk (talk) 19:15, 7 February 2021 (UTC)

As of this time stamp, I have removed the above parameters from all of the transcludable templates that I could find with searches (about 150 templates). I haven't bothered with /sandbox, /doc, or /testcases pages yet. I also took care of |origyear= and |authorlink=, since concerns have been raised about the latter at the hyphenation RFC linked below. – Jonesey95 (talk) 01:12, 20 February 2021 (UTC)

It looks like |archiveurl= and |archivedate= and |airdate= are also cleared from transcluded templates. As far as I can tell, the only unhyphenated parameter left in use in template space, excepting a few inevitable stragglers, is accessdate, used in up to 1,100 templates (there are no doubt some false positives in those search results). – Jonesey95 (talk) 03:46, 22 February 2021 (UTC)

|authorlink= is also used in three non-archived places, all apparently used to construct a base CS1 citation to a specific source. David Brooks (talk) 04:52, 22 February 2021 (UTC)

Links to those three places would be helpful. Here's what I get when I search. (Edited to add: I just found your helpful link at VPP. Thanks!) – Jonesey95 (talk) 05:33, 22 February 2021 (UTC)

FWIW, nearly all of the direct uses of |accessdate= have now been removed from transcluded templates that use CS1 templates. If you click on the link above, you will get a lot of hits for non-CS1 templates that use the unhyphenated parameter, and a few DYK pages that do not get transcluded in article space. If the VPP RFC closes in favor of deprecation (option A or B; there is still time to make a statement there if you wish), we should find that very few of the errors are generated by the use of |accessdate= in transcluded templates. Possibly none, but I don't entirely trust WP's search engine to give me complete results. – Jonesey95 (talk) 06:28, 7 March 2021 (UTC)

This is just a note to say that the VPP discussion/RFC about deprecation of unhyphenated multi-word parameters is ongoing, and it is unclear how it will end up. It does appear to me that if the parameters are deprecated, there is consensus to not display deprecation error messages to normal readers and editors until a bot has removed all or most of the deprecated parameters. Also, if we are going to deprecate the above parameters by moving the sandbox modules to the live modules sometime soon, including or not including |origyear=, we may want to do it without displaying error messages, as a good-faith acknowledgement of many editors' frustration with these changes. I will note that nearly all templates that use Module:Check for unknown parameters use hidden categories and show error messages only in Preview mode, which seems to comport with a general consensus that these errors are only for the cognoscenti and do not need to be displayed to readers. – Jonesey95 (talk) 18:51, 4 March 2021 (UTC)

It's high time we have a template that can support both specific and generic preprint services, and scales accordingly.

{{cite preprint |last# |first#= |year#= ... |title=... |repository= ... |arxiv=... |citeseerx=... |ssrn=...}}

Which could then be used for things like

• {{cite preprint |last1=Ambale-Venkatesh |first1=Bharath |last2=Quinaglia |first2=Thiago |last3=Shabani |first3=Mahsima |last4=Sesso |first4=Jaclyn |last5=Kapoor |first5=Karan |last6=Matheson |first6=Matthew B. |last7=Wu |first7=Colin O. |last8=Cox |first8=Christopher |last9=Lima |first9=Joao A C. |year=2021 |title=Prediction of Mortality in hospitalized COVID-19 patients in a statewide health network |repository=[[medRxiv]] |doi=10.1101/2021.02.17.21251758 |pmid=33619510 |pmc=7899480 |s2cid=231959570}}

and give

• Ambale-Venkatesh, Bharath; Quinaglia, Thiago; Shabani, Mahsima; Sesso, Jaclyn; Kapoor, Karan; Matheson, Matthew B.; Wu, Colin O.; Cox, Christopher; Lima, Joao A C. (2021). "Prediction of Mortality in hospitalized COVID-19 patients in a statewide health network" (Document). doi:10.1101/2021.02.17.21251758. {{cite document}}: Cite document requires |publisher= (help); Unknown parameter |pmc= ignored (help); Unknown parameter |pmid= ignored (help); Unknown parameter |s2cid= ignored (help); Unknown parameter |work= ignored (help)

Headbomb {t · c · p · b} 18:07, 23 February 2021 (UTC)

@Headbomb: Except we shouldn't be citing preprints - if the article is published in a journal afterwards, cite the reviewed version instead... RandomCanadian (talk / contribs) 20:45, 7 March 2021 (UTC)

We shouldn't normally be cited preprints normally when there's a published version, but we can still cite preprints in general, in limited circumstances. Headbomb {t · c · p · b} 22:40, 7 March 2021 (UTC)

Here I'm editing Carl Marzani#Published by Marzani & Munsell. The entry of concern displays as

• King, Jr, Martin Luther; Nelson, Truman (1962). Foreword. Negroes with Guns. By Williams, Robert F. New York: Marzani & Munsell. OCLC 340047.

Only on Wikipedia does the citation give top billing to the author of the Foreword. That's not good, please fix it, so that the entry appears like this:

• Williams, Robert F. (1962). Negroes with Guns. with Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.

Even better, since the "Foreword" is actually two separate essays by King & one by Nelson, it would be best to have contribution1, contribution2 and contribution3 as parameters.

Nota bene: I put the above into Wikipedia:Village pump (proposals) and a friendly user responded: "Please raise this at Help talk:Citation Style 1 which is where citation template issues are discussed." So here we are. Larry Koenigsberg (talk) 21:46, 1 March 2021 (UTC)

If you're citing the foreword, then you are citing King & Nelson, whose foreword appeared in a work by Williams. So the template is correct in its presentation order. This isn't a general book reference you find in a list of works cited, it's a specific targeted reference to the foreword itself. If you are not citing the foreword, then you don't to have that information in the template. Headbomb {t · c · p · b} 21:56, 1 March 2021 (UTC)

If the part you're citing (the part you name in the "contribution" field) is the foreword, then it should be front and center. If you are citing some other part of the book, then you should cite that other part of the book; the contribution field is there to say what you're citing, not to list other stuff that you're not citing. —David Eppstein (talk) 21:58, 1 March 2021 (UTC)

If you just want to add a mention of the foreword, use |others=, such as:

• Williams, Robert F. (1962). Negroes with Guns. Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.

Otherwise, as noted, if you're citing the foreword itself, you'd use |contribution=Foreward etc. Imzadi 1979 → 23:26, 1 March 2021 (UTC)

Some older related threads:

• Help_talk:Citation_Style_1/Archive_74#Illustrator=
• Help_talk:Citation_Style_1/Archive_73#Others
• Help_talk:Citation_Style_1/Archive_9#Proposal_for_more_detailed_parameters_than_the_catch-all_others=_parameter

--Matthiaspaul (talk) 10:50, 7 March 2021 (UTC)

@Trappist the monk: About the cfg.special_case_translation [list_name], this may have no effect on enwiki, but it has affected the results of non-English wikis, shows like "|display-作者=10 (帮助)" error messages, this is not a real parameter name.

p.s. I am updating the CS1 to zhwiki (it is an old versions from five years ago), and I have trouble due to format changes and deprecated parameters like dead-url. Looking forward to a better internationalization. --YFdyh000 (talk) 12:34, 7 March 2021 (UTC)

That happens because error_conditions.err_disp_name[message] hasn't been translated.

—Trappist the monk (talk) 12:45, 7 March 2021 (UTC)

I think this is wrong, the err_disp_name message should not get special translation for parameter $1, this creates a combination of content that should not be translated.--YFdyh000 (talk) 10:58, 8 March 2021 (UTC)

If I have correctly decoded what it is that you are really complaining about, it is that current error message mechanism doesn't adequately handle locally named aliases of the en.wiki parameter names. If that is what you are really saying, then I have some sympathy for that position. I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox so that the module no-longer assembles the parameter name but instead uses the parameter name given in the template.

{{cite book/new |title=Title |author=Author |display-authors=3}}

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

—Trappist the monk (talk) 13:58, 8 March 2021 (UTC)

Smith, J. (2006). Journal of Nothing. 1 (2): 3–4. doi:10.1039/B909133E#.{{cite journal}}: CS1 maint: untitled periodical (link)

Should throw an error. Headbomb {t · c · p · b} 04:19, 8 March 2021 (UTC)

Why? Is there something in the DOI specification that forbids the # character in a DOI suffix? I am unable to find it. It looks to me as if DOI suffixes can even contain emojis, perversely enough, though I could be wrong: The DOI name is case-insensitive and can incorporate any printable characters from the legal graphic characters of Unicode. – Jonesey95 (talk) 06:04, 8 March 2021 (UTC)

There's a bunch of things about DOIs that are technically legal, but aren't used. You could, in theory, have 10.14asdfa14234/something, but in practice, it's 10.####/something or 10.#####/something. You can search for DOIs ending in #, none resolve to anything. Headbomb {t · c · p · b} 08:36, 8 March 2021 (UTC)

The module can enforce the correct identifier format. It is beyond scope to ascertain that the target exists, or that it is the correct one. 24.103.251.114 (talk) 13:01, 8 March 2021 (UTC)

The module already enforces known bad DOIs, like Smith, J. (2006). Journal of Nothing. 1 (2): 3–4. doi:10.155555/foobar. {{cite journal}}: Check |doi= value (help)CS1 maint: untitled periodical (link) even if they fit what is technically allowed. Headbomb {t · c · p · b} 17:14, 8 March 2021 (UTC)

This may be jumping the gun. For all one knows, this may come to pass in the future, since it is allowed. I see no downside from removing the particular checking function, and any other that devotes processing time to something that is technically allowed but not presently used. Apart from wasting cycles, it seems like an unnecessary limitation that produces no tangibles. There's another minus: while I have no way to forecast whether "foobar" will ever be used in a doi, if it does the module will have to be modified yet again, to amend the doi-checking function. 98.0.246.242 (talk) 05:12, 9 March 2021 (UTC)

Then you lack both imagination and experience doing cleanup on Wikipedia, because DOI checking yields tons of errors and fixes. Headbomb {t · c · p · b} 05:15, 9 March 2021 (UTC)

We are discussing something that is not an error and therefore does not need a fix. Especially not one that comes with overhead. 98.0.246.242 (talk) 05:25, 9 March 2021 (UTC)

FYI to the OP, searching the web for "doi regular expression match" (without the quotes) will yield some interesting attempts at trying to solve the problem of how to find a valid DOI. I don't think any of the people in the threads I read were able to solve the problem fully, because the spec is so permissive. – Jonesey95 (talk) 05:49, 9 March 2021 (UTC)

Hello,

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)

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)

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. 98.0.246.242 (talk) 04:18, 17 March 2021 (UTC)

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)

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 (talk ⋅ contribs) 04:10, 24 February 2021 (UTC)

83 hits is not exactly a lot but I would add it anyway:

Other related threads:

• Help_talk:Citation_Style_1/Archive_73#Addition_to_generic_title
• Help_talk:Citation_Style_1/Archive_70#Wayback_Machine
• Help_talk:Citation_Style_1#generic_title

--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 book}}: Cite uses generic title (help)
Sandbox	Log into Facebook. {{cite book}}: 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 (talk ⋅ contribs) 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 book}}: Cite uses generic title (help)
Sandbox	Redirecting... {{cite book}}: Cite uses generic title (help)

--Matthiaspaul (talk) 14:55, 20 March 2021 (UTC)

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)

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)

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)

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. 2021-03-XX. {{cite book}}: Check date values in: |date= (help)

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

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! —Collin^{t 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:

• doi:10.51134/sod.2013.039
• doi:10.51593/20190038
• doi:10.51291/2377-7478.1099
• doi:10.51291/2377-7478.1201
• doi:10.51405/0639-014-002-006
• doi:10.51442/ijags.0009
• doi:10.5951/mathteaceduc.2.1.0042

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! —Collin^{t 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)

|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|asin=412346789X|title=Title}}
Live	Title. ASIN 412346789X. {{cite book}}: Check |asin= value (help)
Sandbox	Title. ASIN 412346789X. {{cite book}}: Check |asin= value (help)

Cite book comparison

Wikitext	{{cite book|asin=6305277001|title=Title}}
Live	Title. ASIN 6305277001.
Sandbox	Title. ASIN 6305277001.

Cite book comparison

Wikitext	{{cite book|asin=6317484546|title=Title}}
Live	Title. ASIN 6317484546.
Sandbox	Title. ASIN 6317484546.

Cite book comparison

Wikitext	{{cite book|isbn=412346789X|title=Title}}
Live	Title. ISBN 412346789X.
Sandbox	Title. ISBN 412346789X.

Cite book comparison

Wikitext	{{cite book|isbn=6305277001|title=Title}}
Live	Title. ISBN 6305277001. {{cite book}}: Check |isbn= value: invalid group id (help)
Sandbox	Title. ISBN 6305277001. {{cite book}}: Check |isbn= value: invalid group id (help)

Cite book comparison

Wikitext	{{cite book|isbn=6317484546|title=Title}}
Live	Title. ISBN 6317484546. {{cite book}}: Check |isbn= value: invalid group id (help)
Sandbox	Title. ISBN 6317484546. {{cite book}}: 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. 98.0.246.242 (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-00000120-QINU`"'<cite class="citation book cs1">''Title''. [[ASIN (identifier)|ASIN]]&nbsp;[https://www.amazon.com/dp/6305277001 6305277001].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=https%3A%2F%2Fwww.amazon.com%2Fdp%2F6305277001%23id-name%3DASIN&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+75" 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 info-uri.info (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|asin-tld=xy|title=Title}}
Live	Title. {{cite book}}: |asin-tld= requires |asin= (help)
Sandbox	Title. {{cite book}}: |asin-tld= requires |asin= (help)

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

• No ASIN, valid TLD:

Cite book comparison

Wikitext	{{cite book|asin-tld=de|title=Title}}
Live	Title. {{cite book}}: |asin-tld= requires |asin= (help)
Sandbox	Title. {{cite book}}: |asin-tld= requires |asin= (help)

OK.

• Valid ASIN, invalid TLD:

Cite book comparison

Wikitext	{{cite book|asin-tld=xy|asin=6305277001|title=Title}}
Live	Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)
Sandbox	Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)

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

• Valid ASIN, valid TLD:

Cite book comparison

Wikitext	{{cite book|asin-tld=de|asin=6305277001|title=Title}}
Live	Title. ASIN 6305277001.
Sandbox	Title. ASIN 6305277001.

OK.

• Invalid ASIN, invalid TLD:

Cite book comparison

Wikitext	{{cite book|asin-tld=xy|asin=xyz5277001|title=Title}}
Live	Title. ASIN xyz5277001. {{cite book}}: Check |asin-tld= value (help); Check |asin= value (help)
Sandbox	Title. ASIN xyz5277001. {{cite book}}: Check |asin-tld= value (help); Check |asin= value (help)

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

• Invalid ASIN, valid TLD:

Cite book comparison

Wikitext	{{cite book|asin-tld=de|asin=xyz5277001|title=Title}}
Live	Title. ASIN xyz5277001. {{cite book}}: Check |asin= value (help)
Sandbox	Title. ASIN xyz5277001. {{cite book}}: Check |asin= value (help)

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

• Valid ASIN, no TLD:

Cite book comparison

Wikitext	{{cite book|asin=6305277001|title=Title}}
Live	Title. ASIN 6305277001.
Sandbox	Title. ASIN 6305277001.

OK.

• Invalid ASIN, no TLD:

Cite book comparison

Wikitext	{{cite book|asin=xyz5277001|title=Title}}
Live	Title. ASIN xyz5277001. {{cite book}}: Check |asin= value (help)
Sandbox	Title. ASIN xyz5277001. {{cite book}}: Check |asin= value (help)

OK.

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. {{cite book}}: |doi-broken-date= requires |doi= (help)

{{cite book/new |title=Title |pmc-embargo-date=2 April 2021}} → Title. {{cite book}}: |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)

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)

|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. {{cite journal}}: 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)

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]

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)

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

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=https://movies.nytimes.com/movie/11238/The-Court-Martial-of-Jackie-Robinson/overview |title=The Court Martial of Jackie Robinson (1990) |work=[[The New York Times]] |access-date=December 9, 2019 |archive-url=https://web.archive.org/web/20140103141030/http://www.nytimes.com/movies/movie/11238/The-Court-Martial-of-Jackie-Robinson/overview |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. 24.103.251.114 (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. 24.103.251.114 (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}}. 98.0.246.242 (talk) 19:17, 7 April 2021 (UTC)

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. [4], 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. 98.0.246.242 (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. 64.61.73.84 (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. 98.0.246.242 (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\|\}] – ~870

|volume=[Vv][Ii]* *[\|\}] – ~1450

|issue=[Ii][^Ii\|\}] – ~500

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:

volume

vol (with or without terminal dot)

v. (requires terminal dot because 'v' can be an allowed Roman numeral)

|issue= value begins with:

issue

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

number

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|journal=Journal|number=I.3|title=Title|volume=Vol:3}}
Live	"Title". Journal. Vol:3 (I.3). {{cite journal}}: |volume= has extra text (help)
Sandbox	"Title". Journal. Vol:3 (I.3). {{cite journal}}: |volume= 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|journal=Journal|number=3, 5|title=Title|volume=I–II}}
Live	"Title". Journal. I–II (3, 5).
Sandbox	"Title". Journal. I–II (3, 5).

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|number=nos. 3, 5|title=Title|volume=vols. I–II}}
Live	"Title". Journal. vols. I–II (nos. 3, 5). {{cite journal}}: |number= has extra text (help); |volume= has extra text (help)
Sandbox	"Title". Journal. vols. I–II (nos. 3, 5). {{cite journal}}: |number= has extra text (help); |volume= has extra text (help)

Cite magazine comparison

Wikitext	{{cite magazine|journal=Journal|number=3, 5|title=Title|volume=I–II}}
Live	"Title". Journal. Vol. I–II, no. 3, 5.
Sandbox	"Title". Journal. Vol. I–II, no. 3, 5.

Cite magazine comparison

Wikitext	{{cite magazine|journal=Journal|number=nos. 3, 5|title=Title|volume=vols. I–II}}
Live	"Title". Journal. Vol. vols. I–II, no. nos. 3, 5. {{cite magazine}}: |number= has extra text (help); |volume= has extra text (help)
Sandbox	"Title". Journal. Vol. vols. I–II, no. nos. 3, 5. {{cite magazine}}: |number= has extra text (help); |volume= 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)

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

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)

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 ([5]) 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)

After the recent change to |volume error messaging, I get an error on a few lists where I'm citing the "V"th volume of a set of books (specifically: |volume=V: Carnivores, Pangolins, Equids and Rhinoceroses). The "V: " trips the "don't put 'volume' in the 'volume' parameter check, and so would "V ". Does anyone have a recommendation for how to indicate that it's volume "V" without getting the warning? I can't think of one, so I just changed it to the slightly wrong "5", but thought I'd ask. --PresN 23:59, 13 April 2021 (UTC)

Book. Vol. V: Carnivores, Pangolines, Equids and Rhinos. for context. I would agree that this should not be an error and that one of the regexes should change. Perhaps that can be rolled out with the other change I made above. Izno (talk) 00:03, 14 April 2021 (UTC)

The pattern in the configuration is '^v[%.:= ]', -- Roman numeral without separator (space char is sep char here). @Trappist the monk: Why did you add that deliberately? Or did you implement what you wanted to implement incorrectly?... (Issue has a similar issue: '^i[%.:= ]', -- Roman numeral without separator (space char is sep char here).) Izno (talk) 00:12, 14 April 2021 (UTC)

My thinking was that 'V' or 'I' followed by a space character introduces the volume or issue 'value'. MediaWiki strips trailing whitespace before handing named parameters and their values to the template and so to the module. Therefore, whitespace following 'V' or 'I' is indicative of 'V 25'.

I was going to suggest the accept-this-as-written-markup |volume=((V: Carnivores, Pangolins, Equids and Rhinoceroses)) but that doesn't work (badly):

{{cite book/new |volume=((V: Carnivores, Pangolines, Equids and Rhinos)) |title=Book}}

Book. Vol. V: Carnivores, Pangolines, Equids and Rhinos.

But, this does:

{{cite book/new |volume=((V: Carnivores Pangolines Equids and Rhinos)) |title=Book}}

Book. Vol. V: Carnivores Pangolines Equids and Rhinos.

Something about the comma. I have to think about this...

—Trappist the monk (talk) 00:27, 14 April 2021 (UTC)

This should not be an accept as written case. It should be supported. I'll simply remove the pattern if that is the alternative. Izno (talk) 01:00, 14 April 2021 (UTC)

I'm not convinced that simply removing the pattern is a good idea. If you can show that editors never write 'V.', 'V:', 'V=', or 'V ' in the same way that they write 'Volume:' etc then perhaps the pattern can go away.

—Trappist the monk (talk) 01:20, 14 April 2021 (UTC)

No, I think the burden of proof is on showing that accept as written is necessary. We already know Roman numeral V is a case we must account for. If you cannot produce a pattern that supports it, then the pattern should be removed. Period and end of story. Izno (talk) 01:26, 14 April 2021 (UTC)

Now deployed, since there was no opposition above to setting the error to hidden, I did not want to touch the live module twice, and because you apparently went ahead and made a change as below to the live module for a separate error. Izno (talk) 01:31, 14 April 2021 (UTC)

Fixed. utilities.has_accept_as_written() returns two values; a text string stripped of the accept-this-as-written markup and a boolian. hyphen_to_dash() then dutifully returned both but utilities.substitute() doesn't like booleans so it choked.

The distinction between the comma version and the non-comma version is the path that the code follows in hyphen_to_dash() (there were no commas so the mw.text.split() doesn't).

Because this flaw produces lua script errors I have updated the live module with this fix.

—Trappist the monk (talk) 01:20, 14 April 2021 (UTC)

Anything that replaces user input should be documented in detail. Currently there is no indication in the help page that |vol= input that does not conform to the constraint pattern is replaced. I think recent discussions would have been quickly settled if such parameter constraints were better communicated. If it is deemed appropriate to document the relevant code for developers (a good thing), it should be more so for users. 71.167.45.141 (talk) 12:02, 14 April 2021 (UTC)

Certainly, the documentation can always be improved (please consider creating an account and help out as well - it's not that we don't want to improve the documentation, it's just a matter of time).

If a user runs into this problem, the error/maintenance message will contain a link to Help:CS1_errors#extra_text_volume, where the problem and the desired fix is explained. Also, the ((accept-this-as-is)) syntax to mute the message in case of wrongly detected valid input is explained in various places including here: Help:Citation_Style_1#Accept-this-as-written_markup.

--Matthiaspaul (talk) 14:37, 14 April 2021 (UTC)

I would document what I code and I do not code here. But this is irrelevant. It is good that there are maintenance messages, but I was referring to preventive maintenance. It is obvious (and understandable) that people are annoyed when a dumb thing berates them, especially when they have no way of knowing in advance. At least with proper doc, you can always ask them to rtfm. 50.74.165.202 (talk) 15:21, 14 April 2021 (UTC)