Help talk:Citation Style 1/Archive 75

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

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

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

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

generic title

Added internet archive wayback machine ~560 hits

These were added by

—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

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.

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

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.

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

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:

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

• No ASIN, valid TLD:

OK.

• Valid ASIN, invalid TLD:

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

• Valid ASIN, valid TLD:

OK.

• Invalid ASIN, invalid TLD:

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

• Invalid ASIN, valid TLD:

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

• Valid ASIN, no TLD:

OK.

• Invalid ASIN, no TLD:

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

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

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.

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.
  hdl:11336/85874. {{cite journal}}: Invalid |doi-access=fre (help
  )

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

1. |work=The New York Times
2. |work=
   All Movie Guide, |via=The New York Times
3. |work=
   All Movie Guide
4. |work=
   All Movie Guide
5. |work=
   All Movie Guide, |publisher=The New York Times
6. |work=
   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.

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

--Matthiaspaul (talk) 18:51, 30 March 2021 (UTC)

If some form of the RFC below is to run, deferring action on these cases until afterwards might create less friction. It might happen, for example, that the RFC removes the issue that these forms were created to work around, in which case no-one will miss them. Kanguole 15:35, 14 March 2021 (UTC)

Doesn't matter. cs1|2 is responsible for the annotation used when rendering |volume= and |issue=. These tests catch inappropriate volume and issue annotations in the parameters' assigned values. Inappropriate extra annotations will always be inappropriate regardless of the outcome of an rfc (if there is an rfc).

—Trappist the monk (talk) 15:44, 14 March 2021 (UTC)

I am hopeful that these messages will be hidden maintenance messages when they are initially deployed. Given the current discussion about hyphens at VPP, it would behoove us to avoid being tone-deaf to editors' concerns about error messages and changes to the CS1 templates based on limited discussions. – Jonesey95 (talk) 04:36, 15 March 2021 (UTC)

Draft RFC

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

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

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 (

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)