Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

asin & isbn

|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 ‹The template Category link is being considered for merging.› 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 ‹The template Category link is being considered for merging.› 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-00000047-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" 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:

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:

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)

"Log into Facebook"

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)

generic title

Added internet archive wayback machine ~560 hits

These were added by REFLINKS c. 2012.

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

And added webcite query result ~300 hits

And these were (are) added by reFill and reFill 2.

—Trappist the monk (talk) 19:09, 18 March 2021 (UTC)

And another wikiwix's cache ~200 hits

—Trappist the monk (talk) 19:22, 25 March 2021 (UTC)

Should cite comic be part of CS1?

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)

Autolinking

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

The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present. The existence of the paramaters |doi-free= or |hdl-free= should cause the doi or hdl to have priority and be used instead of the pmc for the title link. --Whywhenwhohow (talk) 23:59, 8 March 2021 (UTC)

What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)

For the articles you edit? Add the url you want to link as the |url= parameter. That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don't have to try to understand or remember it. —David Eppstein (talk) 06:14, 26 March 2021 (UTC)

Obtuse template style

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

Because outside of Wikipedia, scholarly and academic journals commonly use that style so cs1|2 reflects that. {{cite journal}} has used this style since it's very early days. There has been some discussion, on and off, about changing that.

—Trappist the monk (talk) 18:43, 12 March 2021 (UTC)

The last planning discussion and the last unplanned discussion. I'm pretty close to starting an RFC, just need to get some stuff written down. --Izno (talk) 19:45, 12 March 2021 (UTC)

I don't know for cite journal but {{cite book}}, if you put anything besides a plain number in |volume=, it isn't bolded, ex. [1], so there's that. I mean, it shouldn't be much of a problem changing the journal template so it displays "vol. x"; but again it's really a minor issue of citation style and so long the source is uniquely identifiable we shouldn't be worrying too much about that. RandomCanadian (talk / contribs) 20:10, 12 March 2021 (UTC)

That happens because you wrote |volume=vol. 1 which value causes Module:Citation/CS1 to render no-bold-volume because the value is five-characters in length. You should not be doing what you did. It is the responsibility of the templates to format the values supplied in parameters when the citation is rendered. If this discussion or some other discussion leads us to change how {{cite book}} renders |volume= so that it renders as 'vol. <volume value>', your citation will then render as 'vol. vol. 1.' and someone will have to fix it. Please don't include extraneous text in cs1|2 parameter values.

—Trappist the monk (talk) 20:31, 12 March 2021 (UTC)

That was very much an intentional work-around because I'm personally not happy with that formatting - I have seen it used for journals but not for books. RandomCanadian (talk / contribs) 20:39, 12 March 2021 (UTC)

With all respect, is it not simpler to not use CS1 templates? Then you format the citation the way you see fit. The rationale behind emphasizing the volume was to make people aware that this is a multi-part source, the search for which does not end with locating the title, one should dig deeper to find the appropriate part. Bold weight is used as emphasis to distinguish from the emphasis given to the title, which is in italic type. And obviously the template rendering of the volume parameter is confusing and contradictory, and the instructions are inadequate. I would use a freehand citation rather than trying to figure out the nonsensical. 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)

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

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

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

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

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

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

"I don't see a reason for that"

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)

ISO dates

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

Umm, that isn't an ISO 8601 date format. cs1|2 adheres as closely as it can to MOS:DATES; when MOS:DATES allows YYYY Month dd date format, cs1|2 will follow.

—Trappist the monk (talk) 02:10, 17 March 2021 (UTC)

Related discussion: Wikipedia_talk:Manual_of_Style/Dates_and_numbers#ISO_8601

--Matthiaspaul (talk) 17:00, 11 April 2021 (UTC)

Help:Citation Style 1/test problems

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)

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

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.

References

And a {{cite book}} template and two {{harvc}} templates in §Bibliography:

• Black, ed. (2021). All about Colors.
  • Blue. "Why Blue is the best color". In Black (2021).
  • Greene. "Green is better than Blue because it has Yellow". In Black (2021).

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

Thanks for this pointer to {{harvc}}. This is extremely useful when citing encyclopedias, and I didn't know about this until now. {{sfnm}} is another that I came across only recently. Is there a list somewhere of the family of sfn/harv templates? -- Michael Bednarek (talk) 03:55, 21 March 2021 (UTC)

Template:Sfn § Author–date citation templates is the only list that I know of.

—Trappist the monk (talk) 11:28, 21 March 2021 (UTC)

Reference and Bibliography?

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

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

See WP:REFNAME. – Jonesey95 (talk) 15:17, 23 March 2021 (UTC)

Report style

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

{{cite report}} is the way it is because that was the way it was created all those many many years ago. For the discussion that occurred around the time that I migrated {{cite report}} from {{citation/core}} to Module:Citation/CS1, see Help talk:Citation Style 1/Archive 6 § Cite report.

—Trappist the monk (talk) 13:27, 23 March 2021 (UTC)

We talk about cite report on occasion. Please take a look at the archives. Izno (talk) 14:28, 23 March 2021 (UTC)

Finding errors in Vancouver names

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

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

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

DOIs greater than 10.49999

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)

Automating URL access tags

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

Adding on a bit, the datasets would essentially be URL lists, similar to the whitelists and blacklists we use, that would assign those base URLs as, say: subscription, registration, free, sites that are two or more of those, and possibly another category for sites known to be free in certain locations. - Floydian ^τ _¢ 02:21, 31 March 2021 (UTC)

I assume you have in mind external code that is called by the module when these parameters are set, so that the relevant processing is offloaded. An editor override should be an option. In general, because humans should should have control over all processes, and in particular because access status may restate faster than database updates. 64.61.73.84 (talk) 03:15, 31 March 2021 (UTC)

Yes, the way this would work is that if someone used {{citation|url=nonfreesite.com}}, it'd use the database entry for nonfreesite.com to display the padlock, but if someone used {{citation|url=nonfreesite.com|url-access=free}}, it'd override. {{u|Sdkb}} ^talk 03:27, 31 March 2021 (UTC)

"URL lists, similar to the whitelists and blacklists" We already have a database for this: Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 8 April 2021 (UTC)

I appreciate the intention but we should think twice about adding hard-coded lists like this - it will be significant work to maintain. I am concerned by the rising complexity of this module and the sustainability of its maintenance. Would you consider adding support for this in a bot instead? We already do quite a lot of tagging with User:OAbot, this sort of tagging would easily be in scope for it. Also I suspect not that many domains can be considered as mostly paywalled, with the generalization of hybrid open access among scholarly publishers, so it's not clear to me it would be that useful in practice. Perhaps you have specific domains in mind? − Pintoch (talk) 09:30, 31 March 2021 (UTC)

Pintoch, I don't have a strong opinion about whether we should do automation via a bot or something else, just that if we want the tags to appear widely outside of GAs/FAs, there should be some sort of automation. Maintaining a database of URLs with their statuses is a lot less work than maintaining references individually, since each website is likely used hundreds or thousands of times. I don't have specific domains in mind, although I think big newspapers might be a good place to start. {{u|Sdkb}} ^talk 10:00, 31 March 2021 (UTC)

@Sdkb: then I would warmly invite you to carry out this project via WP:OABOT. If you want to curate the list of paywalled sources I am sure we can find someone to add the relevant Python code there to make it work. It should be a lot easier to get this through BRFA than to implement this in the citation modules. − Pintoch (talk) 14:41, 31 March 2021 (UTC)

My gut reaction to this proposal is that it will be just one more thing over which editors will squabble. What to do when the base url can be free and can be subscription? Who is to be tasked with designing and maintaining this database? If the goal of this proposal is to help get these parameters used a lot more widely, how does automatic application of the access icon further that goal? Module:Citation/CS1 cannot rewrite article wikitext so editors looking at wikitext will never see |url-access= except when it has been added to the citation template by a human or by a bot.

—Trappist the monk (talk) 10:59, 31 March 2021 (UTC)

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

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)

module suite update 10–11 April 2021

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

Module:Citation/CS1

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

Module:Citation/CS1/Configuration

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

Module:Citation/CS1/Whitelist

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

Module:Citation/CS1/Date validation

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

Module:Citation/CS1/Identifiers

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

Module:Citation/CS1/COinS

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

Module:Citation/CS1/Suggestions

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

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

• Regarding err_doibroken_missing_doi, the linked discussion does not mention doi.
• What specifically is meant by "Refactor style and ref functions"?
• It would be best to hold off on further deprecations based on hyphenation until the closure of the Village Pump RfC
• As per the linked discussion for "Emit maintenance message when the value of |ref= equals the default value", the value of the proposed change is unclear.

Nikkimaria (talk) 19:19, 3 April 2021 (UTC)

Style/ref functions was not user-facing. This is why the word 'refactor' was used.

I do not see a reason to stop removing deprecated, and to stop deprecating, dash versions of parameters where the dash versions have essentially already been removed (whether so because they were deprecated and removed or because there were so few in the wild that no-one was using them). I make no comment on the RFC and its associated parameters; the RFC essentially did not discuss the parameters identified above, however it closes.

"ref equals default value": It identifies citations which do not need |ref= which means additional wikitext clutter can be removed. That seems sufficient to me, and I said as such originally. What do you find unclear? Izno (talk) 21:44, 3 April 2021 (UTC)

Why this is a necessary or beneficial change. The linked discussion provides some reasons why an editor may have chosen to include such values. Additionally the RfC, while not focused specifically on these parameters, raises questions as to the wider practice of deprecating unhyphenated aliases following on an RfC that did not intend or require same. Nikkimaria (talk) 00:37, 4 April 2021 (UTC)

... Additional wikitext clutter can be removed is sufficient to be a necessary and beneficial change. One of the discussion points since forever is that citations clutter wikitext. This change removes one point of clutter. I have not been reverted where I have removed |ref=default_value. My speculation is that the people using |ref=default_value (either hardcoded or with {{sfnref}}) either wrote the articles prior to |ref=harv or did not know about |ref=harv or do not know that neither |ref=default_value nor |ref=harv are necessary any more. I see all three as far more likely than editors deliberately adding these just to meet one or another of MP's speculations as stated in that discussion.

Here are some more reasons to remove it even though I think the prior was sufficient:

1. As mentioned therein, the harv keyword is also deprecated as it is the default behavior for all templates, so this change also makes the templates more consistent i.e. you only need |ref= if you need to set something to a non-default (mostly when you have no authors or editors). This makes teaching new and old users easier.
2. Having unnecessary |ref=default_value serves to confuse new editors who may think it is always or even sometimes necessary, when it is strictly not.

Now, do you sincerely believe that one of the qualities in MP's speculations was actually of interest and moreover that it is sufficient to override the clutter and unteaching new users and consistency points? I do not believe any of his points are of sufficient interest or are clearly lacking in evidence. Be specific in your answer to what you think is more important, rather than pointing to unspecific comments on his part. Izno (talk) 02:12, 4 April 2021 (UTC)

|doi-broken-date= without |doi= has been an error since the 3 September 2019 update. That update used doibroken_missing_doi which was changed to err_doibroken_missing_doi at the 10 October 2020 update. Here is a simple example template that shows that |doi-broken-date= without |doi= error detection is already functional (before the next update):

{{cite book |title=Title |doi-broken-date=April 2021}} → Title. {{cite book}}: |doi-broken-date= requires |doi= (help)

|asin-tld= without |asin=, |pmc-embargo-date= without |pmc=, and |class= without |arxiv= error detection was added to the sandbox at this edit, rewritten and the |class= error detection removed at these edits. This functionality has since been split between Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox to resolve the extraneous error messaging noted at Help talk:Citation Style 1 § asin & isbn. Because |asin-tld= without |asin= and |pmc-embargo-date= without |pmc= error detection is grouped together with |doi-broken-date= without |doi= error detection, I included err_doibroken_missing_doi in the above list.

—Trappist the monk (talk) 22:22, 3 April 2021 (UTC)

The RFC discussion is about the last six unhyphenated parameters that have not yet been deprecated. The deprecated parameters listed above were deprecated by consensus on this talk page before the new RFC started. There is no point in delaying their formal deprecation in the module code, since they no longer exist in a significant quantity in the wild; any stray deprecated parameters that may have been added after the affected namespaces were checked and cleaned can quickly be tidied up. There will not be a massive bot run or piles of red error messages. – Jonesey95 (talk) 00:55, 4 April 2021 (UTC)

The question asked there is about non-hyphenated parameters, period. Nikkimaria (talk) 01:11, 4 April 2021 (UTC)

Yes, that was the question. It hasn't been the discussion, in any shape or form. The discussion is almost exclusively whether a bot prior to formal deprecation is appropriate and whether it is appropriate for that bot to make other cosmetic changes and whether it's appropriate to do it with parameters used a million times or more. It has certainly not discussed the parameters deprecated by a discussion here. Izno (talk) 01:48, 4 April 2021 (UTC)

However, because that was the question, the closing could be anticipated to address that question. Thus the need to wait for an outcome there, rather than relying solely on local consensus here. Nikkimaria (talk) 01:56, 4 April 2021 (UTC)

No, closings summarize the discussion, even if it tends away from the question. I anticipate that the question in the heading of that discussion will feature not at all in the closer's summary. Izno (talk) 02:21, 4 April 2021 (UTC)

Re the default for |ref=. This was set to |ref=harv, as in the author-date short reference scheme. The module programmatically offers a target for select short-reference anchors such as those generated by {{harv}} (by mapping the author and date parameters accordingly). That would make something like |ref=harv or similar redundant. Or that is what I think this means, anyway. 98.0.246.242 (talk) 01:45, 4 April 2021 (UTC)

No, this discussion is about cases where a template like {{cite book |last=Last |first=First |year=2020}} also has |ref=CITEREFLast2020. That value is the same value as the templates auto-generate today automatically.

|ref=harv was separately deprecated already when the templates were set to do so, sometime within the past year. Izno (talk) 02:17, 4 April 2021 (UTC)

An observation. It may be time to ditch the "Style" part from the module's name. This module collection and the applications (templates) based on it has evolved beyond style elements. There are error-checking routines for data, calls to external code, and compliance to standards that have nothing to do with presentation. It is becoming a full-blown citation format rather than just facilitating the stylistic formatting of citations. I make no representations about whether this is a bad or good thing. 98.0.246.242 (talk) 02:02, 4 April 2021 (UTC)

Follow-up to module updates

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

This edit to the sandbox on 4 April (after the list above was written) apparently fixes this edit.

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

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

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

We might change that to:

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

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

I support application of these two bug fixes ASAP (especially since it looks like I caused one of them). – Jonesey95 (talk) 14:09, 10 April 2021 (UTC)

I'm still thinking about the |issue= issue.

|series-no= restored.

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

Chuj is unsupported in |language

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

cs1|2 only supports languages that are known to MediaWiki which does not know about every ISO 639 language code. The list of supported languages is at Template:Citation Style documentation/language/doc.

—Trappist the monk (talk) 22:35, 3 April 2021 (UTC)

I am aware of this - would this have to be a deeper MW change? However, I've also heard that manual overrides are possible? Sorry if I'm a bit confused, I'm not exactly sure what this change would fall under. Remagoxer (talk) 23:42, 3 April 2021 (UTC)

cs1|2 has the facility to override an existing language name if that language name is known to MediaWiki. For example, for code bn, MediaWiki returns Bangla which is the endonym. What cs1|2 wants is the exonym, Bengali, so cs1|2 overrides MediaWiki to render the language name correctly.

MediaWiki do some times change the language name data but I have never been successful in getting them to change anything for me. Perhaps you will have better luck.

—Trappist the monk (talk) 00:29, 4 April 2021 (UTC)

lua error with invalid access parameter

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

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

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

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

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

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

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

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

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

What I really want to know, what I really want to know, is how did I miss |airdate=? After all of this, that parameter was completely overlooked. Argh!

I don't know what to think about developer discouraged. Outside of the RFC, is there such a thing? Google returned only 152 results for the quoted string ... one of them the RFC. Deprecation (at least as I understand it within the scope of cs1|2) is 'developer discouraged'; that is, deprecation is the point where we formally begin to discourage the use of something. For example, we 'discourage' the use of |authors= because we are none of us clever enough to write code that can reliably parse apart a free-form list of human names so that those names may be included in the citation's metadata. But, because there are 22k-ish articles in ‹The template Category link is being considered for merging.› Category:CS1 maint: extra text: authors list‎, we aren't ready to deprecate it quite yet.

Removing the nonhyphenated parameters from the documentation is simple and straight forward. I'm not so sure about the maintenance category or message. A category with a million or more articles seems so large that it would be off-putting to anyone interested in fixing those articles. Adding maintenance messaging won't normally be a problem but for large articles that are nearing the post‐expand include size limit, it might push them over the edge and incur anger before these parameters are officially deprecated.

We might propose a 'bot-only' version of GENFIXES so that |accessdate= etc could be fixed by AWB bots doing other stuff without imposing the burden on normal everyday AWB users who also want to run AWB with GENFIXES on. I won't hold my breath for this because it is rather special purpose.

—Trappist the monk (talk) 20:05, 6 April 2021 (UTC)

What? Trappist isn't perfect? Trappist missed |airdate=? For those of us who make mistakes more than once a month, this was, frankly, a relief. Welcome to the club, friend. (I did only list |airdate= once in the 27,000-word RFC discussion, and that discussion was painful to visit, so I can see why it was missed.)

I don't know what to think about the apparently made-up adjectival phrase "developer-discouraged" (I have inserted a hyphen here and above, but I am not pedantic enough to try to correct the RFC closer) either, when we have had the perfectly good concept of deprecation for a long time. I do think that there is enough guidance in the RFC for us to use it as the closer intended, though.

I think that a hidden category of a million-plus articles is fine (see ‹The template Category link is being considered for merging.› Category:Living people, for example), especially since our intent is to make it smaller. We can use that category to find stray template uses of the parameters that have escaped our notice. We can use it to run petscan searches and insource searches that allow us to find articles where a bot or an AWB editor could hyphenate the parameters while making a visible change (e.g. accessdate and ref=harv, currently 10,000 articles). We can track its size over time to gauge the feasibility of actually deprecating and removing support for the parameters at some point.

I can live without a hidden message. The RFC and its closure may seem like a barrier at first, but I think that they allow us some room to move forward. Wikipedia a group project run by humans; things don't always go the best way, but they progress toward sanity over time. – Jonesey95 (talk) 20:48, 6 April 2021 (UTC)

I have asked the closer for some clarification on one unclear sentence. Also, I am not worried about hidden messages making the pages exceed the template expand size. I would be happy to monitor the intersection of that category and the new maintenance category and fix the expansion problem by fixing the parameters. – Jonesey95 (talk) 21:24, 6 April 2021 (UTC)

The simplest way to do the category is to treat the category as a properties cat: ‹The template Category link is being considered for merging.› Category:CS1 has developer-discouraged parameter or some-such. We can mark the six parameters in Module:Citation/CS1/Whitelist with some sort of secret code (discouraged comes to mind) and then modify validate() to detect that secret code in the same way that it detects false for deprecated parameters. validate() then calls utilities.add_prop_cat() to add the category. Empty deprecated parameters cause a error; empty discouraged parameters would do the same.

It would seem that now is the time to act (before the pending update) if we are going to act at all.

—Trappist the monk (talk) 21:47, 6 April 2021 (UTC)

I agree, and the detection approach and timing appear sound, if you have time to code it. It would be nice to hear from other page watchers, but the RFC and this note from the closer provide some guidance that we can lean on for consensus. I think in-text messages should be green and hidden by default (or nonexistent; I'm not attached to them). As for the cat name, how about ‹The template Category link is being considered for merging.› Category:CS1: developer-discouraged parameter, which appears to match the pattern of recently created "properties" categories. I'll be happy to write a description and some guidance for the category page. – Jonesey95 (talk) 22:28, 6 April 2021 (UTC)

Maint messages are hidden by default (they exist in articles visible or no). I guess that ultimately, maint cats are better because they are visible so editors who see them may be more inclined to fix. Since the closer appear to prefer maint messages... Category name would then be ‹The template Category link is being considered for merging.› Category:CS1 maint: developer-discouraged parameter.

—Trappist the monk (talk) 22:46, 6 April 2021 (UTC)

Maint version:

{{cite book/new |title=Title |url=//example.com |accessdate=2021-04-06}} → Title. Retrieved 2021-04-06.

{{cite book/new |title=Title |url=//example.com |accessdate=}} → Title.

{{cite book/new |title=Title |url=//example.com |accessdate=2021-04-XX}} → Title. Retrieved 2021-04-XX. {{cite book}}: Check date values in: |accessdate= (help)

{{cite episode/new |series=Series |airdate=2021-04-06}} → Series. 2021-04-06.

{{cite book/new |title=Title |url=//example.com |archiveurl=//archive.org |archive-date=2021-04-06}} → Title. Archived from the original on 2021-04-06.

{{cite book/new |title=Title |url=//example.com |archive-url=//archive.org |archivedate=2021-04-06}} → Title. Archived from the original on 2021-04-06.

{{cite book/new |title=Title |author=Blue |authorlink=Blue}} → Blue. Title.

{{cite book/new |title=Title |author=Blue |authorlink1=Blue}} → Blue. Title.

{{cite book/new |title=Title |author=Blue |author1link=Blue}} → Blue. Title.

{{cite book/new |title=Title |date=2021 |origyear=1700}} → Title. 2021 [1700].

—Trappist the monk (talk) 00:40, 7 April 2021 (UTC)

I do not think that "Cite has empty unknown parameter: accessdate" is accurate wording for a supported parameter (see the second example above). – Jonesey95 (talk) 04:10, 7 April 2021 (UTC)

Ok, changed.

—Trappist the monk (talk) 12:51, 7 April 2021 (UTC)

"Developer-discouraged" really sounds odd. Let's just call this new state "discouraged" in the category name and message.

--Matthiaspaul (talk) 09:33, 7 April 2021 (UTC)

Ok, changed.

—Trappist the monk (talk) 12:51, 7 April 2021 (UTC)

The hidden message could be further improved by suggesting a replacement parameter if there is a replacement defined in the list of suggestions (like we do for most no longer supported parameters). This would apply to these new "discouraged" parameters as well as to so called deprecated parameters.

--Matthiaspaul (talk) 11:41, 7 April 2021 (UTC)

That would convert the messaging from a maintenance message to an error message. I don't think that we should create a special one-off maint message for this or any other maint condition.

—Trappist the monk (talk) 12:51, 7 April 2021 (UTC)

Comments were welcomed by the OP, so: this tempest in a teapot ended quite fittingly, with a whimper (for now). In such cases, the obvious mediocrity is often enhanced by the introduction of new terms in order to fit the contortions of the decision. I don't blame the closer for splitting the baby down the middle. This RFC was frivolous, but so what. Hundreds are. On the other hand, this module collection is overcategorized. The answer to everything sometimes seems to be, let's have another category (of whatever type, but the error-emmting ones are obviously the ones raising people's hackles). So precious human resources will now be taken away from optimizing the modules and rationalizing their design, and made to ensure that the displeasure of developers (tut tut tut) over a non-issue is properly represented. The only entertainment regarding the RFC and this discussion is Jonesey's joke about "progress". 72.43.189.156 (talk) 22:58, 6 April 2021 (UTC)

Re: AWB pushback: I think the ~2.8m |accessdate= pages then where the deal-breaker, moreso than the now only ~30k pages (down from ~330k 5 months ago!) with |authorlink= unhyphenated aliases up to 5. Not just that, but the number of |accessdate= on a per-page basis was very prohibitive. There are many fewer |authorlink= per page, especially now after Monkbot & others standardizing, that it's much less burdensome to add back into WP:GENFIXES.

One way to slowly get around the |accessdate= GENFIXES burden would be to hyphenate 1 citation template at first, instead of all of them at once. Then, every few weeks, months, or however long it takes to get that template's |accessdate= count down to negligibility, add another citation template to hyphenate accessdate, and repeat until all templates are included. Perhaps this can be started after the |authorlink= count is in the ~1k range.   ~ Tom.Reding (talk ⋅dgaf)  03:02, 7 April 2021 (UTC)

I added a few parameter renaming lines to the AWB genfixes, but I was reverted by an editor who does not appear to agree with the RFC. I have no interest in edit warring, and I don't use AWB, but other editors may want to engage there. – Jonesey95 (talk) 03:51, 7 April 2021 (UTC)

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

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

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

I don't agree with point 1 above. The close said: Monkbot 18 should not be run solely to replace the discouraged non-hyphenated parameters. [...] With so many objections to execution of the "hyphenate cs1|2 parameter names" section of Monkbot 18, it's hard to say there is consensus to enact it except if it was bundled with non-cosmetic changes... (The ellipsis removes some stuff that does not make any sense or is not relevant here.) To me, this reads as "If a bot is making cosmetic changes to the parameter names and no other changes to the page, that is not allowed. If a bot (or human editor) is making a substantive change to the page, it is OK to update the parameter names." Both quoted sentences state or imply that parameter replacement along with substantive changes are allowable bot edits. – Jonesey95 (talk) 06:10, 7 April 2021 (UTC)

Yep. I read it the same way. So, updating discouraged parameters to fully supported ones while doing other non-cosmetic edits is still okay for humans and bots. --Matthiaspaul (talk) 09:54, 7 April 2021 (UTC)

I agree.

@MJL: see ambiguous interpretations of your close above regarding use of the word "manually". I do not think this RFC has the 'power' to restrict AWB/JWB/etc. users from performing hyphenations, as long as they also make substantive edits (WP:AWBRULES #4). AWB/JWB/etc. are known as "semi-automatic" tools, so I would suggest changing "manually" to "manually or semi-automatically".   ~ Tom.Reding (talk ⋅dgaf)  11:41, 7 April 2021 (UTC)

@Tom.Reding: Yeah, manually or semi-automatically was always the intention. That's fixed now. –MJL ‐Talk‐^☖ 18:05, 7 April 2021 (UTC)

Broken histories

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

|deadurl= and |dead-url= were deprecated at the 3 September 2019‎ module-suite update. Support for these parameters was withdrawn at the 11 January 2020‎ module-suite update. Those actions have nothing to do with the recently closed RFC.

—Trappist the monk (talk) 22:06, 11 April 2021 (UTC)

Help with a citation

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)

how about something completely different?

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

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

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

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

{{#invoke:cs1 documentation support|template_data_validate|cite web}}

Template:cite web uses standard parameter set; TemplateData has errors:

• |authors= is not a valid parameter

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

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

The worst of the pain with TemplateData is that no-one ever got around to making it so we could document enumerated parameters sanely. It's overwhelming to work through the list when you have to slog through 30 parameters all for the same idea (times 15 templates). Izno (talk) 23:18, 8 April 2021 (UTC)

There is a phabricator bug for this. T54582 --Salix alba (talk): 14:15, 11 April 2021 (UTC)

Anyway, cool tool. Might be interesting to build some more-general tool for template and/or non-i18n module checks between TemplateData and what is implemented. Izno (talk) 23:19, 8 April 2021 (UTC)

I think about a variant of this sometimes when I'm editing a template that does unsupported-parameter checking. Why keep a human-maintained list of valid parameters when a module can read the actual template wikitext for comparison against the parent frame?

—Trappist the monk (talk) 11:09, 9 April 2021 (UTC)

Is anybody actively maintaining TemplateData as a project? Anything that improves the interaction with the module is a good thing, as long as the cross-development is not derailed by TemplateData having its own roadmap. There is the advantage of somewhat-structured documentation, but surely the native documentation could also be formatted programmatically. To me, this would be a worthier project than fussing over whether editors will have to deal with hyphenated parameters. 24.103.101.218 (talk) 12:35, 9 April 2021 (UTC)

Added to all cs1|2 templates that have TemplateData ({{cite AV media notes}}, {{cite map}}, {{cite serial}}, {{cite speech}}, {{cite techreport}} do not). I'll leave it to those who care about TemplateData to fix the errors.

—Trappist the monk (talk) 13:43, 9 April 2021 (UTC)

Thank you for this rigor, Trappist. This sort of module-based doc maintenance is one of the first things I did with {{Authority control}}, and it has saved much time, effort, and sanity.

When trying to remove |editorlink= params, I couldn't tell by the doc & contradictory TemplateData (and minor self-inconsistency in the doc) which is the canonical param & which is the alias (I guess I could ignore the TD, but I'd rather hear it from the source). Module:Citation/CS1/Whitelist subtly suggests (by virtue of appearing first in the table) that |editor-link#= is the canonical version & |editor#-link= is its alias. Similarly with |editor-first#= as cannon & |editor#-first= as its alias, and so-on with all numbered parameters. If so, does this also apply to all #=<1|null> params like |author-link1=, |author1-link=, |author-link=, (i.e. cannon, alias, alias, respectively) or is there a different scheme for these?   ~ Tom.Reding (talk ⋅dgaf)  14:44, 9 April 2021 (UTC)

I don't believe that there is any officially preferred form of parameter name when the choice is between non-enumerated and enumerated (|author-link= and |author-link1= or |author-link= and |author1-link=). I don't believe that there is any officially preferred form of parameter name when the choice is between the enumerated forms (|author-link1= and |author1-link=. In all cases they are fully equivalent.

So, I guess it comes down to preference. For me, that preference is: |author-link= → |author-link1= → |author1-link=. It would be best if all of these types of parameters followed the same pattern parameter-to-parameter and template-to-template.

—Trappist the monk (talk) 16:32, 9 April 2021 (UTC)

I have found a minor coding error, but I don't know the right place in the code to fix it. The alias message renders as:

*<code style="color: inherit; background: inherit; border: none; padding: inherit">|ISBN13=</code> not valid alias of: |isbn=</code>

Note the extra </code> tag or missing <code> tag. – Jonesey95 (talk) 13:42, 11 April 2021 (UTC)

Fixed that.

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

|ISBN13= & |isbn13= were both flagged as errors in Template:Cite book/TemplateData, but both show as 'true' on the whitelist. Template:Cite book/doc currently says that |ISBN13= & |isbn13= are both aliases to |isbn=, which is not reflected in the TD. Should ISBN13/isbn13 be reinstated in the TD, or removed from the corresponding doc-template?   ~ Tom.Reding (talk ⋅dgaf)  13:05, 11 April 2021 (UTC)

Yes, they are aliases. ISBN13 and ISBN parameters are synonyms in Module:Citation/CS1/Configuration. Izno (talk) 13:24, 11 April 2021 (UTC)

According to this cirrus search, |isbn13= and |ISBN13= are rarely used. cs1|2 templates accept only one |isbn= parameter so do we really need |isbn13= and |ISBN13=? I think we don't so these should be quietly replaced with |isbn= and the other two deprecated.

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

|isbn13= and |ISBN13= issue is fixed.

—Trappist the monk (talk) 17:20, 11 April 2021 (UTC)

|orig-date= appears in Template:Cite arXiv/doc but is flagged as 'not valid parameter' in Template:Cite arXiv/doc#TemplateData.   ~ Tom.Reding (talk ⋅dgaf)  14:04, 13 April 2021 (UTC)

Fixed. The ultimate arbiter here is Module:Citation/CS1/Whitelist. {{cite arxiv}} is a preprint template so it is constrained to use only those parameters listed in limited_basic_arguments{}, limited_numbered_arguments{}, and preprint_arguments.arxiv{}.

—Trappist the monk (talk) 14:25, 13 April 2021 (UTC)

|orig-date= is still showing for Template:Cite bioRxiv/doc#Date & Template:Cite ssrn#Date, and I'm unsure how to correct them. A null edit didn't work, but |orig-date= is now correctly hidden in Template:Cite arXiv#Date.   ~ Tom.Reding (talk ⋅dgaf)  14:47, 13 April 2021 (UTC)

name-list-format= still in article space

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

That's interesting. Before I disabled the parameter back then (Help_talk:Citation_Style_1/Archive_74#Removal_of_no_longer_used_name-list-format=_in_sandbox) I checked ([4]) that the parameter was no longer in use in mainspace (otherwise I wouldn't have disabled it). So, either I must have made a mistake running that check or Cirrus search wasn't accurate. Fortunately, the number of hits is low enough to be fixed manually.

--Matthiaspaul (talk) 09:43, 11 April 2021 (UTC)

Cirrus search, like category links in a way, does not guarantee an update to its index if no edit has been made to a page recently. This long tail is pretty routine when working in this area. The only way to get all of them guaranteed is to pull a database snapshot and search there. Izno (talk) 13:26, 11 April 2021 (UTC)

(Sometimes it's caused by reversions to versions older than when you searched too.) Izno (talk) 13:27, 11 April 2021 (UTC)

No worries; the search doesn't always return 100% of what is out there, and as Izno says, reverts and weird lags can cause searches to miss things. I also found a half-dozen uses in template space, but I think I have fixed all of them. – Jonesey95 (talk) 13:34, 11 April 2021 (UTC)

junk author names

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

|last=link|first=Get|last2=Facebook|last3=Twitter|last4=Pinterest|last5=Email|last6=Apps|first6=Other

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

At present there aren't that many:

Email: ~130

Facebook: ~140

Google: ~260 (timed out)

Instagram: ~20

LinkedIn: ~50

Pinterest: ~90

Tumblr: ~30

Twitter: ~400

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

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

Alas indeed. We could also try to detect VE-inflicted, lazy-editor nonsense like this. – Jonesey95 (talk) 14:53, 11 April 2021 (UTC)

Those should probably be a Phab report regardless. Izno (talk) 15:59, 11 April 2021 (UTC)

Go for it. I am immensely tired of submitting VE bugs to phab and having them sit unaddressed for years. – Jonesey95 (talk) 16:10, 11 April 2021 (UTC)

I have modified Module:Citation/CS1/sandbox and ~/Configuration/sandbox so that the module detects the bogus author/contributor/editor/interviewer/translator names listed above:

{{cite book/new |title=Title |last=Facebook}}

Facebook. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Someone |first=Tumblr}}

Someone, Tumblr. Title. {{cite book}}: |first= has generic name (help)

{{cite book/new |title=Title |last=Someone |translator=Google}}

Someone. Title. Translated by Google. {{cite book}}: |translator= has generic name (help)

The test only tests 'first' names when the 'last' name doesn't have a bogus name. This because no need to have a list of essentially duplicate error messages:

{{cite book/new |title=Title |last=Facebook |first=Twitter}}

Facebook, Twitter. Title. {{cite book}}: |last= has generic name (help)

The test stops looking for bogus names once one has been found:

{{cite book/new |title=Title |last=link|first=Get|last2=Facebook|last3=Twitter|last4=Pinterest|last5=Email|last6=Apps|first6=Other}}

link, Get; Facebook; Twitter; Pinterest; Email; Apps, Other. Title. {{cite book}}: |last2= has generic name (help)

As part of this tweak, I modified the code that detects generic titles so that we don't have to maintain two functions to do basically identical tests. To show that I haven't broken anything:

{{cite book/new |title=Are you a robot? |last=Someone |first=}}

Someone. Are you a robot?. {{cite book}}: Cite uses generic title (help)

—Trappist the monk (talk) 15:56, 12 April 2021 (UTC)

Have you seen how many subjects the author named "Super User" is an expert in? When I patrolled these, some years ago now, a handful were genuine, in the sense that the author name "Super User" was visible on the cited page, but most of them are just copied from the metadata of websites that haven't been set up properly. -- John of Reading (talk) 16:24, 12 April 2021 (UTC)

Added:

{{cite journal/new |last1=User |first1=Super |title=Penicillium species A |website=www.aspergilluspenicillium.org |url=https://www.aspergilluspenicillium.org/9-penicillium/53-aspergillus-species-a |language=en-gb}}

User, Super. "Penicillium species A". www.aspergilluspenicillium.org. {{cite journal}}: |last1= has generic name (help)

—Trappist the monk (talk) 16:53, 12 April 2021 (UTC)

That's fine except for that we should allow to override the check. We already support the ((accept-this-as-written)) markup for this set of parameters. The error message should not show up if it is used (for example in the case "Super User" would be the proper (avatar) name for the author as mentioned by John). --Matthiaspaul (talk) 19:45, 13 April 2021 (UTC)

Using volume= with cite book

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

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

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

Remove the word "volume": Handbook. Vol. IV: Terns to Woodpeckers. Izno (talk) 16:01, 11 April 2021 (UTC)

The real solution here is that books should display 'Vol.' in front of their volumes. Headbomb {t · c · p · b} 16:54, 11 April 2021 (UTC)

Hence my working on the RFC which you have noticed. ;) Izno (talk) 17:54, 11 April 2021 (UTC)

Does it make sense that in the above example "Volume" is flagged as "extra text", but "Terns to Woodpeckers" is not? I agree with Aa77zz: whatever was changed should be changed back. Srnec (talk) 19:30, 11 April 2021 (UTC)

It's possibly somewhat problematic that, for books, we use the |volume= parameter for two different things (to distinguish the parts of a multi-volume single work, and to label books in a book series by their number in the series). —David Eppstein (talk) 18:29, 11 April 2021 (UTC)

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

Remove the word volume. That's the fix. That's all you need to do. Izno (talk) 22:13, 11 April 2021 (UTC)

No. Because then it is in bold. And that's not right. Why should anybody have to 'fix' what isn't broken to make it wrong? Srnec (talk) 23:49, 11 April 2021 (UTC)

It is an error to put the parameter name in the parameter value: |volume=Volume IV, |pages=pp. 3–5, |editor=Edward Eddington (ed.), etc. This is because this extra text is generally the wrong kind of information: it's not the metadata for the publication itself, but rather an attempt to control how that metadata is framed in its presentation to the user. If you're using these templates, you need to give up that control, let the template handle how to tell the reader that the volume is "IV" or "IV: Terns to Woodpeckers", and not try to put a description of what kind of metadata it is into the metadata itself. I happen to think that the template should always write out "vol. X" rather than just displaying it as "X", and not use boldface for volume numbers, but that's a separate discussion from the correct way to tell the template what your metadata is. —David Eppstein (talk) 00:05, 12 April 2021 (UTC)

I happen to think this was a bad change made without discussion. Since we cannot revert it, the only choice we have is to abandon use of the template. Hawkeye7 (discuss) 00:43, 12 April 2021 (UTC)

The change was discussed in #Obtuse template style and announced for incorporation in #module suite update 10–11 April 2021 (and subsequently incorporated). If what you wanted was to know why it happened, you need to ask for that first.

Anyway, I think any pain points will be resolved by the RFC I am preparing at #Draft RFC. That aside, DE is fundamentally correct. That aspect of CS1/2 is no different than any other citation style. Izno (talk) 00:48, 12 April 2021 (UTC)

This change is not listed in #module suite update 10–11 April 2021. Hawkeye7 (discuss) 05:58, 12 April 2021 (UTC)

@Hawkeye7: allowed plural forms of extra text patterns for volumes, issues and numbers; discussion. I'm sorry it was not more clear but I also did not write the note in question. --Izno (talk) 14:17, 12 April 2021 (UTC)

then it is in bold What? I provided a copy of the volume rewritten above without the word volume. Do you see bold there? I do not. (I understand that when the template bolds things is not obvious for people who do not keep close track, but this is not one such instance. The majority of CS1/2 will bold templates with: only numerals, Roman, Arabic or otherwise; and sufficiently short text, usually less than 5 characters. This case is neither.) Izno (talk) 00:51, 12 April 2021 (UTC)

It's not just in bold:

• Keegan, John (1969). "Broad Front or Narrow Front?". In Hart, Basil Liddell (ed.). History of the Second World War. Vol. 8. London: Purnell. pp. 3196–3197. OCLC 2466051.

What is the reader supposed to make of the eight sitting out there on its own like a country dunny? Why is is separated from the page number?

The Commonwealth Style Guide (p. 204) says that references must be in the form vol. 8, no. 1, pp. 376-377 Hawkeye7 (discuss) 01:11, 12 April 2021 (UTC)

So, a totally different citation to the one above. Got it. As just stated, yes, numbers are bolded.

External citation/styles guides are not CS1/2. If you want to format an article according to Commonwealth, that is your prerogative, but these are not the templates for that and never have been. Ever.

Again, you will have an opportunity on the point to change what the rendering appears as. Please go review the draft RFC linked in the section above and leave a comment in that section if you think that RFC reads okay to you. --Izno (talk) 01:48, 12 April 2021 (UTC)

That is not correct. Note the comment above from Trappist the monk in the "Obtuse template style" section: Because outside of Wikipedia, scholarly and academic journals commonly use that style.

I don't care about the RfC; I want the error messages removed. Hawkeye7 (discuss) 05:52, 12 April 2021 (UTC)

Hawkeye7, then remove the extra text "Vol.", "Volume" etc. from the parameter, and the error message will disappear.

One of the ideas for using citation templates is to decouple information from presentation, a fundamental design principle, and to centrally maintain the presentation for consistency and also to allow for future changes in presentation style without having to rework all citations individually. Editors working on an article should not (need to) bother about the presentation of citations at all, all they need to do is provide the proper information.

The reason why our citation templates for books display volumes in bold and without any extra text like "Vol." is because the community decided that book citations should look this way long ago. So, this is not a shortcoming of the template, but deliberately coded this way. Nevertheless, not everyone agrees with this and therefore some people abuse the |volume= parameter trying to override the presentation. However, this is not a good idea because it will defeat the idea of allowing the presentation to be changed centrally in the future (perhaps even depending on the output device, different languages, or in a user-selectable format) and cause invalid metadata to be generated.

The proper way for you to deal with the situation is to ignore your presentation preferences for the moment and provide the data in the proper format for the template (that is, without any "Vol." etc.). Optionally, you can voice your opinion here that displaying bold volume numbers for books might not look nice or could even be ambiguous for people not familiar with this convention, or you might even propose a different presentation. If enough people ask for a presentation including a "Vol." prefix, we can change it centrally, but only if |volume= continues to contain just the volume, not some extra text decoration (otherwise the resulting presentation would become "Vol. Vol. X"). See the point?

I hope this helps to better understand why something like "Vol." does not belong into the |volume= parameter. --Matthiaspaul (talk) 11:39, 12 April 2021 (UTC)

It is true that [external] citation/styles guides are not CS1/2. That does not mean that, long ago, the editors who individually created these templates did not model the individual template styles on existing external style guides or external common practice. The editors who created {{cite journal}} likely chose to have the template render the 'V (I): P' form because that style is commonly used by scholarly and academic journals.

cs1|2 is a style unto itself and is not beholden to any external style guide.

Error messaging can be turned off; see Help:CS1 errors § Controlling error message display

—Trappist the monk (talk) 12:02, 12 April 2021 (UTC)

So turn them off. We shouldn't need an RFC every time something needs to be reverted because there's obviously no consensus for it. See the mandatory website/work clusterfuck. These should be, at best, maintenance messages. Headbomb {t · c · p · b} 12:25, 12 April 2021 (UTC)

Agreed. Hawkeye7 (discuss) 12:27, 12 April 2021 (UTC)

I personally agreed with making it a maint message at rollout when it was instituted but I let it drop by the wayside for other reasons, and people still would have screeched on individual articles instead. It is now trivial to make things maintenance items from being errors in the module (sandboxes) (and vice versa); why did no-one else before rollout change it? (Before you try to excuse your collective selves, no, Lua is not black magic.) --Izno (talk) 14:17, 12 April 2021 (UTC)

I have written programs in Lua! I know exactly what code needs to be changed. But I can't edit the module; only admins can and I'm a second-class citizen. And the change you're talking about was not advertised in advance. Nor is there a test case for it. Hawkeye7 (discuss) 20:49, 12 April 2021 (UTC)

Documentation says we can't edit the sandbox, but apparently we can. Hawkeye7 (discuss) 21:28, 12 April 2021 (UTC)

Yes, the sandbox is always available for edit. (I guess you interpreted the locks at the beginning in the documentation as referring to the whole line? That was not the intent certainly, just the first column of live modules.) Izno (talk) 22:22, 12 April 2021 (UTC)

For the records, the change was discussed here: Help_talk:Citation_Style_1#Obtuse_template_style

--Matthiaspaul (talk) 19:19, 13 April 2021 (UTC)

This is about {{cite book}}. When have bold volume numbers ever been normal for books? I am now told that "the community decided that book citations should look this way long ago", but I always thought it was just a silly oversight in template design. I am also told that I "need to give up that control" and "let the template handle how to tell the reader [what] the volume is". But the template does not do that well, so what I'm really being told is to give up using the template. The template is what needs fixing. If it formatted book citations sensibly, then "fixing" the error would not be so bad. But why would anyone "fix" the error just to produce a weird-looking citation? Srnec (talk) 12:35, 12 April 2021 (UTC)

When have bold volume numbers ever been normal for books?

|volume= was added to {{cite book}} on 15 March 2008 with this edit and bolded a week-or-so later at this edit. These changes were apparently made as the result of a series of discussions:

• Volume parameter
• Volume number
• implement volume
• Volume_parameter,_again

So yes, "the community decided that book citations should look this way long ago" as a deliberate decision, not just a silly oversight in template design.

—Trappist the monk (talk) 13:18, 12 April 2021 (UTC)

Note the comment above from Trappist the monk in the "Obtuse template style" section: Observing that there is another style that does X does not mean anything about CS1/2's style Y. Again.

I don't care about the RfC Then you are clearly not here to collaborate and care only for having your preference enforced. Do better. Take the minute I asked you to, look over the RFC, tell me whether you think it is formed well, and we can move on with an actual positive request for change. --Izno (talk) 14:17, 12 April 2021 (UTC)

You're not reviewing my articles, and I'm not reviewing your RfC. If you're looking for collaboration, I have plenty of article writing you can work on. Hawkeye7 (discuss) 20:49, 12 April 2021 (UTC)

Oh very well then. There's a fundamental conflict between Matthiaspaul's notion that the module deals with metadata and Trappist's that it enforces a house style. The latter is the way it works; we have no ability to pass style information from the template down to the module; it is hard coded in the module. Now, various disciplines are accustomed to having differing styles to suit their different needs. The RfC attempts to create a "general display" which enforces a common presentation. This is most likely to suit no one, and the Srnec will likely agree with my conclusion that if successful, it will put more pressure on us to abandon the use of the template. Hawkeye7 (discuss) 21:28, 12 April 2021 (UTC)

I don't see how those two concepts are in conflict whatsoever. It both deals in the metadata and enforces the house style on that metadata. Arbitrary users trying to work around that house style are why there are now red warnings that you are here fussing about. :)

The RFC does come from the presumption that CS1 is one style (+- CS2), not whichever domain's or other stylebook's, because that is how it has always operated; because that is easier to teach, learn, and recognize; and because we don't want to code 300 styles into one module. If you want it to be flexi-style in all things, that's a different RFC. It might even be its own module. I definitely know a different stylebook's citation style is a different module, though I've been considering what functions could be made common so that every style could have date checking and etc.

If you have an article that you think I can help with in some way (I can not offer much), please let me know. :) Izno (talk) 22:16, 12 April 2021 (UTC)

Variety of citation styles should be encouraged. To noone in particular: By all means work on a CS3 module - there is space for additional citation styles that are simpler, or more consistent, or better designed, because they would be starting with a clean slate. As was observed above, the present modules deal with much more than presentation. The recent thread above about "junk authors" is an example. It deals with error checking the data, not the format. This may be an advanced citation function, but it is certainly not a style-related one. Other than that, editors have a right to expect that updates will be compatible as much as possible, with no mainspace-visible disruption. Developers have a right to do with code internals what they see fit. Including relabeling parameters for consistency (other things being equal) without being constantly scrutinized. This is after all an optional tool. 98.0.246.242 (talk) 00:23, 13 April 2021 (UTC)

The sandbox should now display the error as hidden: Title. Vol. Volume. {{cite book}}: |volume= has extra text (help) Be forewarned, this error being hidden by the module will likely not continue into the indefinite future. Izno (talk) 14:39, 12 April 2021 (UTC)

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

When can we expect to see this change in production? Hawkeye7 (discuss) 20:49, 12 April 2021 (UTC)

Could be this week, could be three months. (I only say 3 months because that's the general update frequency.) I've seen 3 people want it to be hidden and another 1 in the implementing discussion who tended toward making it hidden to start, so that seems like some inertia to deploy sooner than later. --Izno (talk) 22:20, 12 April 2021 (UTC)

The basic problem is that {{cite book}} has never formatted volume numbers in a normal way. It treats them the way {{cite journal}} does and that just doesn't make any sense. Can't we just fix it so that it generates the appropriate text the way |edition= does? Srnec (talk) 00:14, 13 April 2021 (UTC)

I have deployed this change as well as a fix for the below thread started by PresN. Further discussion regarding the below change may continue in that thread. Izno (talk) 01:30, 14 April 2021 (UTC)

Sorry to interject, but does this mean there's no practical benefit to resolving these new errors at this at this time? (I only have 7, but I'd rather not mess with citations if unnecessary.) Estheim (talk) 17:36, 13 April 2021 (UTC)

If Izno's patch will be accepted (which I would support as well), the message will change from an error message to a maintenance message. That is, it will be visible only to those interested in it. However, the fact remains that extra text like "Vol.", "Volume" or similar does not belong into the |volume= parameter and will have to be removed either way. The "Terns to Woodpeckers" in the original example is not "extra text" by this definition, but the subtitle of this particular volume. So, something like "IV: Terns to Woodpeckers" is fine in the |volume= parameter, but "Vol. IV: Terns to Woodpeckers" is not. --Matthiaspaul (talk) 19:19, 13 April 2021 (UTC)

There's no practical benefit to resolving these new errors at this time. The module can handle the matadata. Presentation has yet to be agreed upon. Hawkeye7 (discuss) 20:20, 13 April 2021 (UTC)

(edit conflict - replying to your original comment before you changed it) To a limited extent it could at least in theory, but it does not in the current implementation. Citation templates are not only read by the template code itself, but also by a large assortment of bots and other clients, so trying to "fix it on the fly" would only solve part of the problem. For proper machine-readability across the board and for reliable reusability of the data, the parameters should only contain valid information also on source code level.

Ideally, proper input checking would have been implemented right from the start, so that no invalid data could ever have been saved without causing an error message alerting the contributing editor to correct it, but this wasn't possible before the switch to Lua (and still today is only possible to a limited extent for performance reasons and because of the "free text" nature of most of the citation data). With technology advancing and templates further maturing this will be gradually more and more enforced by our citation templates while fixing old citations containing invalid data.

Again, if people do not like the current presentation of citations, the proper process is to come here and discuss possible improvements, not to try to work around perceived or real issues by inserting invalid data. It will backfire eventually.

And also again, the current presentation style of volumes for books is the result of such community discussions in the past, not some random artifact. However, consensus can change, but it will only change if people make proposals for a better presentation and can agree on one of them eventually (the most difficult part...). Although I'm used to this symbolic notation for scientific periodicals, I, too, think that bold but otherwise bare volume numbers look a bit strange in book citations and not everyone will understand them. So, I can very well understand why people are tempted to add "Vol." to the |volume= parameter (and I probably occasionally did this myself somewhen in the past), but it is still bad practise and should be corrected.

--Matthiaspaul (talk) 22:17, 13 April 2021 (UTC)

For me, the bare bold volume number for a book is as wrong as any invalid data, so there is no option of correcting anything. No matter what you do, it's wrong. Srnec (talk) 00:29, 14 April 2021 (UTC)

I see your point, but your (or mine) personal preference is not relevant here; the template presents volumes the way the community decided upon long ago. And only one parameter input produces this style. Also, only this style produces correct metadata and is easily machine-readable by other clients. And only this style can be centrally switched (without much overhead, that is) if the community's preference would change to a different style in the future. So, there is clearly only one "right" way of doing it. --Matthiaspaul (talk) 00:48, 14 April 2021 (UTC)

I don't think there was a community decision at all. Rather, an editor tacked it on since it was requested and there was no thought about the form it would take. I say this based on my reading of the links provided by Trappist above. Perhaps there was a discussion about form elsewhere. Anyway, editors who actually use the template found a kludge. Srnec (talk) 01:19, 14 April 2021 (UTC)

I completely agree. This has been wrong since I started using the template many years ago. Like many others, I just started adding "Volume 1: blah blah blah" in an effort to work around the bare bolded number that resulted otherwise. I doubt this was really a "community decision"; if it was, it must have been a very small, select community! MeegsC (talk) 07:34, 15 April 2021 (UTC)

What I'd really like to see is instead of the module accepting a |CitationClass=journal parameter, it taking in a format eg. |format=%first, %last (%date) %title, %series, %volume. %location: %publisher. This would facilitate changes like those suggested by Izno. Hawkeye7 (discuss) 21:20, 13 April 2021 (UTC)

This is essentially what the module does under the hood already, except more complicated because it's actually complicated. :) In other words, the change is easy, it just requires consensus (hence the planned RFC). Because we've been doing a great job at getting consensus lately. Izno (talk) 23:54, 13 April 2021 (UTC)

Should we use the template {{cite encyclopedia}} for dictionaries with short definitions too?

I ask the question because, given that the title (the entry in the dictionary) is required, when an article must cite different entries in a dictionary, the same dictionary will be cited as many times as there are entries. I don't like the logic. It makes perfect sense with a typical encyclopedia with long articles with a different author for each entry, but not so much in the case of a dictionary with short anonymous definitions. If we do use the encyclopedia template, how the abbreviated references should differentiate the different citations of the same dictionary. I did not met that situation, but I like to use an approach that is robust and thus would work in those cases. Dominic Mayers (talk) 13:03, 13 April 2021 (UTC)

I would employ {{harvs}} or better, {{harvc}} (or a combination) with custom anchors.I believe there was a recent discussion about similar, you should check this page/arhives.50.74.165.202 (talk) 14:29, 13 April 2021 (UTC)

Of course, I should have done that. I found this, but it's not convincing that there is not a better solution. I will continue the search in the archives. Dominic Mayers (talk) 14:39, 13 April 2021 (UTC)

I think 50.74.165.202 was referring to the section #References listed by editor of the book, but Bibliography lists by author of the chapter above where {{harvc}} is discussed. -- Michael Bednarek (talk) 14:45, 13 April 2021 (UTC)

It's not obvious how it applies. I might have overlooked it, but I don't see how the abbreviated reference for a given title can be created and how it will be linked to the corresponding {{cite encyclopedia}} entry. The situation is that we have two or more {{cite encyclopedia}} entries that differ only by the title. So, the author last, the editor last or whatever except the title is useless. I suspect that I can create an artificial anchor in each {{cite encyclopedia}} entry, but I was hoping for something more convenient. Dominic Mayers (talk) 15:01, 13 April 2021 (UTC)

On second thought, what about |loc=? Like: "article text that uses a very uncommon term, and another uncommon term.

References

Sources

• Fowler, H. W. (1926). Modern English Usage.

HTH. -- Michael Bednarek (talk) 15:33, 13 April 2021 (UTC)

Sure, but the question was "should we use the {{cite encyclopedia}} template...?" You have indirectly answered "No", because you used {{cite book}}. Dominic Mayers (talk) 15:44, 13 April 2021 (UTC)

I believe it was used only as example. The proper template would be the one for edited collections ({{cite encyclopedia}}). Michael Bednarek's posts explain better what I was referring to. Either method or both can be used, depending on how you want to present the reference (single entry or a compound entry of a main listing with sublistings). Also, I do not think there are "artificial" anchors. You can create your own, as it befits the occasion. 50.74.165.202 (talk) 15:53, 13 April 2021 (UTC)

But in {{cite encyclopedia}}, the title is mandatory, so you cannot use it as {{cite book}} was used by Bednarek. This is the main point in my question. (And yes, "artificial" might not be the appropriate term. I meant an anchor that you have to create yourself instead of reusing info that is already available such as the author.) Dominic Mayers (talk) 16:00, 13 April 2021 (UTC)

"article text that uses a very uncommon term, and another uncommon term.

{{cite dictionary |title=Wordsmith's Big Dictionary of Small Words |date=2021 |ref={{sfnref|''Wordsmith''|2021}}}} → Wordsmith's Big Dictionary of Small Words. 2021.

References

—Trappist the monk (talk) 16:15, 13 April 2021 (UTC)

Oh well, I thought about putting the name of the encyclopedia in the title, but I didn't consider the possibility that the parameter encyclopedia was optional, so I discarded this as a solution. To my defense, not a single example in the documentation of Template:Cite_encyclopedia illustrates that we can put the name of the encyclopedia in the title. They all use the parameter encyclopedia. Dominic Mayers (talk) 17:04, 13 April 2021 (UTC)

The reason the documentation does not provide examples of that use is because that use is discouraged, basically. Or because no-one has written it that way. (I would be more inclined to believe the former than the latter. The module does some gross stuff because of how |title= can be used in {{cite encyclopedia}}.) Izno (talk) 23:59, 13 April 2021 (UTC)

Best way to cite the Vth volume of something?

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)

Discouraged

Please revert the 6 "discouraged" parameters back to "true" in the Whitelist. The RfC close that this change was based on has been reverted. Fram (talk) 07:33, 15 April 2021 (UTC)

Although the new-fangled classification was the result of the superseded close, it is not by itself in opposition to the successor. The people who take time to create these optional tools have to be afforded some freedom to indicate preference on purely technical grounds. In this case, centering on consistency and uniformity. I would suggest that a new/first-time editor too would be better served by the distinction. 66.65.114.61 (talk) 14:47, 15 April 2021 (UTC)