Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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)

Yes, this would be appropriate. Institutional repositories hosted by academic institutions are by far the most stable and reliable link targets we have in our citations.

On the other hand it's not appropriate to give priority to the DOI over the PMC ID, because PubMed Central is more likely to present relevant updates, such as retraction notices of medical articles, which often go missing on the publishers' websites. Legacy publishers generally lag several years behind PubMed, see for instance Elsevier. Nemo 18:38, 25 April 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)

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)

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)

I agree with Trappist the monk. There is no shared definition of paywalled. The other day I sent a link to theguardian.com to someone and they replied that it was "paywalled": in reality the content was "just" covered almost entirely by a giant banner asking for money, not dissimilar from what the Wikimedia Foundation regularly places on Wikipedia.

Also, websites constantly switch from one business model to the other. Bloomberg.com or nytimes.com have metered paywalls which are kept intentionally easy to bypass; reuters.com is about to introduce a new paywall but it's certain how long it will last; etc. It might be more suitable to do this with a MediaWiki extension like mw:Extension:SecureLinkFixer, which could add CSS classes to a predefined list of domains. The CSS styles and the list of domains could then be overridden locally. Nemo 15:34, 25 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; [[Help talk:Citation Style 1/Archive 75#Bug in cfg.special case translation [list name]|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/Archive 75 § 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)

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 its |authornlink= and |authorlinkn= variants), 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)

RFC reclosed

The RFC has been reclosed in favor of continuing to support the six remaining unhyphenated parameters. Please adjust your scripts and bots accordingly. Presumably, we will need to make some adjustments to the sandbox code. I have already modified Module:Citation/CS1/Whitelist/sandbox and Module:Citation/CS1/Suggestions/sandbox. – Jonesey95 (talk) 15:37, 15 April 2021 (UTC)

I think we should keep ‹The template Category link is being considered for merging.› Category:CS1 maint: discouraged parameter as a tracking category. It will help us to understand the scale of the usage of these parameters, and searches with petscan when there are tracking categories available work better than insource searches. I don't know if it is possible to keep the category marking the parameters as "true" in the whitelist, however. – Jonesey95 (talk) 23:36, 15 April 2021 (UTC)

I'm inclined to agree. I don't read anything in close 2.0 that imposes limits on the collection of information. But then, I'm not a wiki-lawyer so I could be wrong... Most of that close, it seems to me, is merely an attempt to justify the use of head-counting as the mechanism by which the outcome was determined. Rather a poor precedent, methinks. It would have been better to take the hard decision: declare the obvious impasse and require a completely new RFC. Yeah, this whole exercise just confirms my low opinion of RFCs. Ok, I'm done with my rant.

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

It would be inappropriate to keep the category, since the basis for creating it - the RfC closure - has been found not to reflect consensus. Nikkimaria (talk) 01:47, 16 April 2021 (UTC)

Fair enough. Let's rename the category to ‹The template Category link is being considered for merging.› Category:CS1 properties: unhyphenated multiword parameter or something else neutral. It is useful to track the usage of these parameters so that when the inevitable next RFC happens, we have some data to describe how many of these types of parameters exist in the wild. – Jonesey95 (talk) 03:45, 16 April 2021 (UTC)

A theoretical future RfC doesn't seem a good reason to add a category to millions of pages and clutter up reference popups. What data specifically are you wanting to collect, other than simply how many of them there are, and why is the less invasive solution (searching) insufficient for that purpose? Nikkimaria (talk) 12:34, 16 April 2021 (UTC)

The unhyphenated count cat (whatever we call it - I'm fine with a neutral rename) could actually make/keep the case for keeping non-hyphenated params. The point is, everyone interested can easily see, and track, if they choose, the size of the cat, instead of performing a large array of searches to varying degrees of success.   ~ Tom.Reding (talk ⋅dgaf)  12:50, 16 April 2021 (UTC)

Such a category would not add messaging to the output. Izno (talk) 13:07, 16 April 2021 (UTC)

Izno, the current category does - what would be changed to make that not happen? Nikkimaria (talk) 21:25, 16 April 2021 (UTC)

Something along the lines of how |language= is handled today. See language_parameter in the core module which calls add_prop_cat from the utilities module. Izno (talk) 21:33, 16 April 2021 (UTC)

Can we please pick a new name and get the code in place? I think it would be politically foolish to stick with the new word "discouraged", given the two RFC closures. Either of the neutral ‹The template Category link is being considered for merging.› Category:CS1 properties: unhyphenated multiword parameter or ‹The template Category link is being considered for merging.› Category:CS1 maint: unhyphenated multiword parameter should do the trick without advocating a particular future state. That should reduce the drama, including a CFD that is full of absurd arguments. I am not good enough at Lua to implement this tracking, else I would try it myself. – Jonesey95 (talk) 17:54, 19 April 2021 (UTC)

+Vote for ‹The template Category link is being considered for merging.› Category:CS1 properties: unhyphenated multiword parameter, as it is slightly more neutral than its "maint:" equivalent.   ~ Tom.Reding (talk ⋅dgaf)  18:11, 19 April 2021 (UTC)

Implemented. Because a properties categorizer, must be tested in mainspace because there is no visible message and this page is not categorized. Here is one that can be copied to someplace in mainspace for testing:

{{cite web/new |title=Title |url=//example.com |accessdate=2021-04-19}} → "Title". Retrieved 2021-04-19.

I chose ‹The template Category link is being considered for merging.› Category:CS1 nonhyphenated multiword parameters as the category name; 'non' instead on 'un' because I like it better (no more concrete reason than that) and plural because that is consistent with other properties categories.

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

Thank you, Trappist. This is a petty concern, but for some reason that I can't put my finger on, "nonhyphenated" looks wrong to me as a grammar and usage nerd. I prefer "unhyphenated", and will not die on this hill, but I did bring a few sources. I didn't find any definitive sources to support my position, and when you look, you find a bunch of spammy junk, but in my searching, I found this good explanation and this thoughtful piece, both of which lean towards "un" as the default prefix when you are trying to negate an adjective that may not have a standard prefix in common usage. The best support for "unhyphenated" comes from this Google ngram, which shows that "unhyphenated" is roughly 100 times more common in English usage.

I will change the word in the sandbox to save you from implementing my petty nerdiness, but I am open to contrary evidence. – Jonesey95 (talk) 20:41, 19 April 2021 (UTC)

... we should hyphenate un-hyphenated. ;) Izno (talk) 20:43, 19 April 2021 (UTC)

[citation needed!] Sarcasm registered and recorded. I have implemented the minor change from "non" to "un" in the sandboxen and tested it in a mainspace article. The new "un" category shows in red at the bottom of the page, as it should, and no maintenance/error message is displayed. I think it is working as intended. Thanks again, Trappist (and no thanks to Izno!). Should we deploy these changes to quell the torch-and-pitchfork crowd? I know we just did an update, but it probably makes sense to do another one because of this change that affects more than a million pages. – Jonesey95 (talk) 20:56, 19 April 2021 (UTC)

Perhaps a better term is 'nonstandard'. This, it seems to me, is more generic and could be applied to any parameter name for whatever reason. Further, I wonder if the nonstandard-parameter category should be split according to parameter name. Doing that would provide better granularity: ‹The template Category link is being considered for merging.› Category:CS1 nonstandard parameters: accessdate, ‹The template Category link is being considered for merging.› Category:CS1 nonstandard parameters: origyear, etc. I don't see much reason to separate enumerated forms from their base-name form so |authorlink= and its enumerated forms would all be categorized in ‹The template Category link is being considered for merging.› Category:CS1 nonstandard parameters: authorlink.

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

I like the idea of separating the category per parameter name. Regarding "nonstandard", my gut feeling tells me this would have to be written with a hyphen, but I understand there are differences between BE and AE... But if it could be applied to any parameter we probably shouldn't include a term like "standard" or "non-standard" at all.

--Matthiaspaul (talk) 21:30, 20 April 2021 (UTC)

Nonstandard is encountered in common usage, as you note. However a term like "accessdate" is not. It is a fabricated compound peculiar to script writing, because spaces are not used in parameter names. A cautionary note: following recent developments, there is a possibility that people would see the use of the term "non[-]standard" as possible evidence of bias. Because paranoia is catching. I am sure that Trappist means "standard" (or "normal") in the statisticsl sense, but this will be a lost distinction. 74.64.129.102 (talk) 21:48, 20 April 2021 (UTC)

I'm looking for a term that isn't burdened with all of the baggage of the bipolar rfc and cfd. I'm looking for a term that has the meaning of uncanonical (yep, that's a word) in the sense that these parameters do not follow the canonical form. Alas, most synonyms of nonstandard are too negative. Atypical seems less negative but somehow, for me, isn't sufficiently 'general'. If we're going to have these categories, it would be best to have a base name that is neutral; a name that neither demotes nor promotes. We might abandon the descriptor part of the category name entirely and use something like ‹The template Category link is being considered for merging.› Category:CS1 uses parameter: origyear which describes what the category holds: articles with cs1|2 citations that use |origyear=.

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

(edit conflict) I am bad at wiki-politics, but even I can see that using any form of the word "nonstandard" is a bad idea, given the ire that a handful of editors have toward any efforts to simplify and standardize these templates. We need a neutral category name. Tracking categories that track parameter usage are often called something like "Pages using Foo template with Bar parameter". That's neutral. "CS1 unhyphenated multiword parameters" is neutral. "CS1 parameter: accessdate" is neutral. Any category name containing the word "nonstandard", in any form, is not neutral. The ire-filled handful will ask us to point to a widely advertised RFC setting a standard for parameter naming, we won't be able to do it, and there will be another fight. – Jonesey95 (talk) 23:06, 20 April 2021 (UTC)

I've tweaked the categorizer so that Module:Citation/CS1/Whitelist/sandbox uses the text string 'tracked'; in Module:Citation/CS1/Whitelist/sandbox, the prop_cats{} key is ['tracked_param'] and the category name is 'CS1 uses parameter: $1'; in Module:Citation/CS1/sandbox, mention of hyphenation is replaced with tracked and tracked_param.

—Trappist the monk (talk) 23:44, 20 April 2021 (UTC)

Probably too late to be of any help now, but is the word you've been looking for to supplant "discouraged", "nonstandard" or "unhyphenated" perhaps the one that's used in the cite templates' documentation: "alias"? — JohnFromPinckney (talk) 16:55, 21 April 2021 (UTC)

Thanks. Earlier in this process alias did occur to me but for some reason or another, now forgotten, I rejected it. As it is now, the categorizer is, I think, agnostic. That's a good thing because any parameter might be monitored (tracked) for any reason regardless of whether or not it is or has an alias.

—Trappist the monk (talk) 19:33, 21 April 2021 (UTC)

"Alias" and "synonym" are what occurred to me, but I'm unclear on the intent of this category. Is it meant to be used for all parameters with aliases, and if so, is the usage of each different alias needed? If I understand Module:Citation/CS1/Configuration correctly, some like "chapter" have many aliases. Are multiple categories needed to track each one? isaacl (talk) 20:57, 21 April 2021 (UTC)

For the nonce, the module sandbox is set to categorize those articles with cs1|2 templates that use one or more of some of the parameters that are semantically indistinguishable from their canonical counterparts. To humans, |chapter=, |contribution=, |entry=, |article=, |section= are semantically distinguishable from each other whereas |orig-year= is decidedly not semantically distinguishable from |origyear=. I can imagine tracking, for example, |encyclopaedia= or |encyclopedia= which are semantically indistinguishable except that one or the other is misspelled. We might track |class= now that |arxiv-class= has been introduced; we might track |no-tracking= or |template-doc-demo= – do we really need both? No doubt, there are other parameters that we might want to track.

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

In that case, "synonym" sounds good to me. I'm not clear, though: are the uses of both (or more, if any are introduced in future) synonyms being tracked separately? isaacl (talk) 23:00, 21 April 2021 (UTC)

You will notice that I wrote For the nonce. Using 'synonym', or any other qualifier, in category names tends to limit how the categorizer might be used. I don't want to do that; I want it to be a general purpose tool that will allow us, as editors at en.wiki, and also editors at other-language wikis, to track any particular parameter for any or no reason and not be constrained to 'synonyms'.

—Trappist the monk (talk) 23:36, 21 April 2021 (UTC)

Sure, "CS1 uses parameter: $1" is a good generic template for a category. I didn't realize you weren't still looking for a term to replace non-canonical. isaacl (talk) 23:48, 21 April 2021 (UTC)

I think that I have settled on a name but since I did, no one but you and Editor JohnFromPinckney has commented so I don't know that what I think is a good choice actually is a good choice...

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

The current adjective-less name pattern is a good one. It is neutral and allows us to track any parameter we want to track in the future, without needing to attach a descriptor to it. – Jonesey95 (talk) 00:58, 22 April 2021 (UTC)

Re: the absense of comments on the generic name – usually, people tend to speak up more when they dissent? 98.0.246.242 (talk) 01:10, 22 April 2021 (UTC)

Not including an adjective into the name is what I suggested as well, therefore I'm fine with it. :-) --Matthiaspaul (talk) 20:03, 22 April 2021 (UTC)

Summarizing this discussion, for the record: neutrally named categories "CS1 uses parameter: $1", where $1 is the parameter name, are added to pages when parameter $1 is used in the article. This code is present in the sandbox modules, and the special status "tracked" can be used in the Whitelist module to assign a tracking category for a given parameter. Tracking can be applied for any parameter of interest, for any reason. – Jonesey95 (talk) 16:00, 10 May 2021 (UTC)

Discussion at Wikipedia:Categories for discussion/Log/2021 April 16 § Category:CS1 maint: discouraged parameter

 You are invited to join the discussion at Wikipedia:Categories for discussion/Log/2021 April 16 § Category:CS1 maint: discouraged parameter. * Pppery * _{it has begun...} 19:41, 16 April 2021 (UTC)Template:Z48

Post-CFD-closure discussion about tracking parameters using categories

The above discussion has been closed with a result that the category should be deleted (which we had already agreed to above with a strong consensus). There is a deletion review in progress, and it looks like the closure will stand. I asked in the deletion review about this clause in the closure: From here, I would suggest starting a discussion as to whether a tracking category for the parameter(s) in question should be created, and if so, what the name of it should be. The closer (Jc37), has responded in the deletion review to say essentially that they are satisfied with the words in the closure (closer, please correct me if I am misreading).

It appears that as a formality, we need to have another discussion about tracking categories for any additional parameters that we wish to track with CS1 modules (we have uncontroversially tracked the use of |authors= since 2016, and until a few months ago, we did the same with |editors=). On the assumption that I have all of this right (I have pinged the closer above to ensure that they have a chance to correct any misinterpretations here), I am starting a new discussion.

I propose that, as is done in hundreds of templates already, we implement a neutral mechanism in these modules, using categories, to track parameters of interest, and that "CS1 uses parameter: $1", where $1 is the parameter name, be the name of all such new categories. Please respond below with support, opposition, counter-proposals, and comments. – Jonesey95 (talk) 23:52, 10 May 2021 (UTC)

I have left a comment on the DRV which includes concern about that line. Izno (talk) 01:14, 11 May 2021 (UTC)

What is the specific benefit of such an implementation? Nikkimaria (talk) 02:08, 11 May 2021 (UTC)

They're tracking categories. They give us information about how a given parameter is used. That information helps us to have informed discussions, and to track parameter usage over time. They are like thousands of other tracking categories, e.g. those in ‹The template Category link is being considered for merging.› Category:Album chart usages or just about anything else in ‹The template Category link is being considered for merging.› Category:Tracking categories. – Jonesey95 (talk) 04:17, 11 May 2021 (UTC)

Why would we be interested in tracking these parameters in particular? What specific information about use are we hoping to gain? Nikkimaria (talk) 12:46, 11 May 2021 (UTC)

This discussion is not about particular parameters, unless I have phrased something incorrectly above. It is about what the name of each tracking parameter category, or categories, would be. We already came to a consensus above, and proposed code is in the sandboxes, but the CFD closure said that a new discussion needed to happen before more parameter tracking categories could be created. All I'm looking for is editors' simple restatement of the above consensus, assuming that they have not changed their positions. Pinging all participants in the above discussion: @Isaacl, Izno, JohnFromPinckney, Matthiaspaul, Nikkimaria, Tom.Reding, and Trappist the monk: (my apologies if my text-scraping failed to find someone). – Jonesey95 (talk) 14:12, 11 May 2021 (UTC)

Support existence & creation of neutrally named tracking cats.   ~ Tom.Reding (talk ⋅dgaf)  14:17, 11 May 2021 (UTC)

Support per Tom Reding. However I oppose linking this activity with the disputed CfD, and not because I initiated a DRV on it. But because it submits module maintenance to a rather inflexible precedent that affects everyday housecleaning tasks. Category creation was always submitted here for discussion anyway. I restate that there is no obligation to do so either, but it is a good thing. 66.65.114.61 (talk) 14:59, 11 May 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)

There having been no answer to my question, and because there are no cs1|2 templates in the wild that are using them, I have removed support for |isbn13= and |ISBN13= from the sandbox.

It occurs to me to wonder if we should support |isbn10=. Citation bot and perhaps others, convert 10-digit ISBNs to the thirteen-digit form. Sometimes editors object to that; there are occasional complaints registered at the bot's talk page. Perhaps |isbn10= might act as an inhibit flag to Citation bot so that it doesn't automatically convert to isbn13?

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

Whether or not this is implemented, this is an efficient use of existing resources. Even the prospective doc would be pretty straight forward imo. 66.65.114.61 (talk) 15:37, 20 April 2021 (UTC)

I'm still seeing usage of isbn13 in the wild. Insource searches don't always show complete results, so if we proceed with this change, we should expect some pages to pop into our error categories. Also, can you please update the "proposed module update" list at the bottom of this page with the two most recent sandbox changes? Thanks. – Jonesey95 (talk) 16:25, 20 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 ([2]) 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)

Ok, accept-this-as-written markup inhibits the generic name error check:

{{cite book/new |title=Title |last=User |first=Super}} → User, Super. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=((User)) |first=Super}} → User, Super. Title.

{{cite book/new |title=Title |last=User |first=((Super))}} → User, Super. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=((User)) |first=((Super))}} → User, Super. Title.

{{cite book/new |title=Title |author=((Super User))}} → Super User. Title.

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

Perfect, thanks. --Matthiaspaul (talk) 06:35, 21 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 my) 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)

Regarding the metadata aspect (and related to what David Eppstein mentioned above regarding multiple uses of the volume parameter): I think some books can have a volume number, a volume name, or both. The two are conceptually two separate metadata items. The logic based on the volume parameter being a pure numeric value or string less than 5 characters is essentially trying to support both forms of metadata in one parameter. Perhaps the two can be separated, say by adding a volume-name parameter, and a bolded, bare number used only if volume-name is not present. (I know as someone not deeply engrained in the myriad of uses of the citation templates, there are likely many issues I've overlooked.) isaacl (talk) 17:23, 17 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)

Well, if it is discouraged, it should be written in the documentation and ideally the alternative approach that should be used to meet the requirement of the use case should be given. Otherwise, an example how to use it seems useful. Either way is fine with me, but not something vague in between. Dominic Mayers (talk) 21:42, 15 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)

Fixed in the sandbox: Reinstated "true" value for previously "discouraged" parameters per the RFC reclose.

Cite episode comparison

Wikitext	{{cite episode|accessdate=15 April 2021|airdate=15 April 2021|archivedate=2014-10-06|archiveurl=https://web.archive.org/web/20141006071642/http://www.example.com|author2=Jane Doe|author2link=Jane Doe|author=John Smith|authorlink=John Smith|origyear=2020|series=Series|title=Title|url=http://www.example.com}}
Live	John Smith; Jane Doe (15 April 2021) [2020]. "Title". Series. Archived from the original on 2014-10-06. Retrieved 15 April 2021.
Sandbox	John Smith; Jane Doe (15 April 2021) [2020]. "Title". Series. Archived from the original on 2014-10-06. Retrieved 15 April 2021.

The above example uses all of the parameters that were "discouraged" in the first RFC. The sandbox version shows that there is no maintenance message and no error message. – Jonesey95 (talk) 15:31, 15 April 2021 (UTC)

Thank you. Fram (talk) 16:30, 15 April 2021 (UTC)

New category: Category:CS1 errors: missing class for newstyle arxiv preprints

This would help track cases like this [3]

Conditions

1. {{cite arXiv}} only
2. |eprint/arxiv=####.#### or |eprint/arxiv=####.####, where # is a digit. This covers the 'new' identifiers like arXiv:1607.04503 and not 'old' ones like arXiv:math/0207028
3. |class= is unset

Headbomb {t · c · p · b} 22:51, 15 April 2021 (UTC)

I'm confused. The {{cite arxiv}} documentation says that |class= is optional. An error category (and therefore an attendant error message) would indicate that |class= is required

Here is the citation that matches your example |arxiv=1607.04503 from Gabriele Vezzosi both with and without |class=:

Hennion, Benjamin; Porta, Mauro; Vezzosi, Gabriele. "Formal gluing along non-linear flags". arXiv:1607.04503 [math.AG].

Hennion, Benjamin; Porta, Mauro; Vezzosi, Gabriele. "Formal gluing along non-linear flags". arXiv:1607.04503.

In both cases the module creates the same url:

https://arxiv.org/abs/1607.04503

Why do we need to throw an error for {{cite arxiv}} templates that don't include |class=?

—Trappist the monk (talk) 23:48, 15 April 2021 (UTC)

Because in general pure arxiv citations should be cited with the class (https://arxiv.org/help/faq/references). It's how it's cited across virtually all sciences, since that gives an idea in which moderated section of the arxiv something is from (e.g. the awful physics.gen-ph, or the saner hep-ex). Class is optional in that if you have an old identify, you don't need class, because class is implicit (the foobar/####### in old style.) Headbomb {t · c · p · b} 23:56, 15 April 2021 (UTC)

You claim "It's how it's cited across virtually all sciences" is so completely counter to my experience that I think it is just wrong. I have seen many academic publications that cite arXiv preprints and I have never to my knowledge seen them cite them with their class. Regardless of what that page on arXiv states, what evidence beyond it do you have to support the idea that this is somehow normal or standard or anything more than an idiosyncratic Wikipedia-only convention? As counter-evidence I offer http://cccg.ca/proceedings/2019/proceedings.pdf (listed because it has a whole proceedings in a single pdf, with multiple citation styles in evidence) which has 28 citations to arXiv none of them listing the class. I am not arguing that class should be forbidden, but it should certainly not be an error to omit it. —David Eppstein (talk) 00:09, 16 April 2021 (UTC)

It's an error than can be trivially fixed with Citation bot as soon as it's detected. If an error is too much, then make it a maintenance message. Headbomb {t · c · p · b} 02:14, 16 April 2021 (UTC)

Some history.

—Trappist the monk (talk) 00:34, 16 April 2021 (UTC)

I think, a maintenance message cannot harm for this, but an error message appears to be too much.

Speaking about |class= I take the opportunity to propose that we add an |arxiv-class= alias for consistency. We have |pmc-embargo-date=, |doi-broken-date=, |asin-tld= and a whole assortment of |bibcode-access=/|doi-access=/|hdl-access=/|jstor-access=/|ol-access=/|osti-access=/|s2cid-access=, so |class= appears to be a bit odd a name for a parameter directly related to |arxiv= only.

Given that |class= appears not to be used very widely (in the low thousands?), perhaps we could even abandon |class= in favour of |arxiv-class=, but I could also live with keeping it for now.

--Matthiaspaul (talk) 21:54, 16 April 2021 (UTC)

Support renaming the parameter per above, and the associated search-and-replace (without error displays) after proper discussion. In general, I believe it is better to minimize the use of parameter aliases. Devise a parameter label that is concise and easily understandable, document it properly, and that should be enough. Aliases, although they may be temporarily useful for compatibility, introduce complexities for both programmers and users, and they seem to assume a life of their own. 98.0.246.242 (talk) 02:39, 17 April 2021 (UTC)

Protected edit request on 16 April 2021

Please revert this edit, since it was based on the incorrect and now overturned closure of this RfC. The new close finds that "non-hyphenated parameters should not be deprecated in citation templates"; therefore the edit as it stands is in clear violation of this consensus. RandomCanadian (talk / contribs) 13:36, 16 April 2021 (UTC)

Accessdates and the like were not deprecated in that edit, so this edit request is based on a flawed premise. Headbomb {t · c · p · b} 13:47, 16 April 2021 (UTC)

Except it still marks these parameters as "discouraged", which is not what the close of the RfC says, does it? "This means that existing hyphenated (e.g. access-date) and non-hyphenated (e.g. accessdate) parameters should both continue to be supported by the templates." - if I can read the template correctly, that should mean they should be set to "true", not "pre-deprecation purgatory" (since there is explicitly no consensus to deprecated the parameters, now or at some future point). RandomCanadian (talk / contribs) 14:03, 16 April 2021 (UTC)

That edit has already been reversed in the module sandboxes, and the category description has been changed to explain that it is only a tracking category. Conversations continue above about how best to track the remaining unhyphenated parameters. – Jonesey95 (talk) 14:38, 16 April 2021 (UTC)

Oppose. Discouraged ≠ deprecated, and discouragement need not lead to deprecation. The RFC outcome (Option C) doesn't restrict "developer discouragement", so there is no need to reverse the edit. The module will continue to support both parameters. The module comment, re: "pre-deprecation purgatory", may be too aggressively suggesting deprecation, and can be changed or removed.   ~ Tom.Reding (talk ⋅dgaf)  16:27, 17 April 2021 (UTC)

The finding that these parameters are in any way "discouraged" was reversed, and the associated changes made should thus also be reversed. Nikkimaria (talk) 18:15, 17 April 2021 (UTC)

The concept of "discouragement" wasn't 'reversed' in close#2; it wasn't even mentioned. As such, the RFC has no bearing on whether or not to track these parameters in any way.   ~ Tom.Reding (talk ⋅dgaf)  21:36, 17 April 2021 (UTC)

Close#1 invented the concept of "discouraged", and was reversed, meaning that the concept no longer has any basis. The other changes associated with the reversed closure should similarly be reversed. Nikkimaria (talk) 21:50, 17 April 2021 (UTC)

Close#1 invented the concept of "discouraged" Not true. The first close invented the term developer discouraged. Elsewhere on this page, I wrote that developer discouraged is a new term to me. On my talk page, the closer confirmed the term is a made-up term created for the purpose of the close. The notion of discouraged cs1|2 parameters has been around for quite a while. Before it was deprecated and finally removed, use of |editors= was discouraged and at one time had its own tracking category ‹The template Category link is being considered for merging.› Category:CS1 maint: uses editors parameter (July 2016 – August 2020). |authors= is discouraged; see, for example, the documentation at {{cite book}} and ‹The template Category link is being considered for merging.› Category:CS1 maint: uses authors parameter (since July 2016).

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

the closer confirmed the term is a made-up term created for the purpose of the close - ie. the close invented the concept as used in the context under discussion - the changes resulting from that close. The current close does not support the notion that these parameters are discouraged as you define it, nor that they require a maintenance category. Nikkimaria (talk) 23:17, 17 April 2021 (UTC)

You wrote: Close#1 invented the concept of "discouraged". That is a false statement because, as I explained, cs1|2 has had the concept of "discouraged" parameters since 2016. The closer's term, developer discouraged, as noted on my talk page where the closer wrote: No, I literally just made it up, was made up for the purposes of that close. Close #2 is mute with regard to categories; is mute with regard to the term discouraged; is mute with regard to the term developer.

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

We should probably delete the main page and many other things, while we're at it, since the close made no mention of it.   ~ Tom.Reding (talk ⋅dgaf)  16:16, 18 April 2021 (UTC)

If you want to delete the main page, or make parameters discouraged, feel free to start a new RfC. In the meantime though, since the initial close was undone, the associated changes should also be undone. Nikkimaria (talk) 00:53, 19 April 2021 (UTC)

The request was for the module to be reversed; while it is nice that this has been done in the sandbox already, it doesn't answer the original request. If sandbox changes get automatically transported to the main module, then please tell us when. If not, then please inform us when this change will be reverted. Fram (talk) 17:22, 16 April 2021 (UTC)

Looking at Module:Citation/CS1, updates only happen every few months, and the most recent update was just a few days ago. It will probably be a while, given the need to avoid re-rendering millions of pages too frequently. Vahurzpu (talk) 02:51, 17 April 2021 (UTC)

Seeing as the initial RfC result was implemented within a week, it seems reasonable that the new result would also be implemented promptly, rather than waiting a few months. Nikkimaria (talk) 14:48, 17 April 2021 (UTC)

Indeed, I think that would be reasonable. I just don't think that we know what the exact next step is, especially with an unnecessary CFD started by thread OP. --Izno (talk) 14:54, 17 April 2021 (UTC)

RandomCanadian (the OP) didn't start the CfD. Fram (talk) 08:21, 19 April 2021 (UTC)

@RandomCanadian: Can this be closed? It's being discussed elsewhere (here and here). It's been more than ten days already while this edit request has been pending.. –MJL ‐Talk‐^☖ 03:05, 28 April 2021 (UTC)

Note that Wikipedia:Categories for discussion/Log/2021 April 16#Category:CS1 maint: discouraged parameter has now been closed as delete. * Pppery * _{it has begun...} 18:10, 9 May 2021 (UTC)

Now that the CfD has closed as "delete", can this edit request please be executed, and can the necesarry changes be made to depopulate the category? Fram (talk) 07:06, 10 May 2021 (UTC)

It would probably be better to wait for Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter to close before taking any action. 13:23, 10 May 2021 (UTC)

CS1 module suite update (date TBD) April 2021

I suggest that we do an out-of-cycle update to the cs1|2 module suite on a date TBD sometime between now and the end of April 2021, primarily in order to implement the reclosure of the unhyphenated parameter RFC. Here are the changes to date since the last major update on 10 April:

Module:Citation/CS1

• detect generic author, editor, etc names; discussion
• Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
• add "CS1 uses parameter: $1" properties tracking categories; discussion
• emit error when |first= is wikilinked; discussion

Module:Citation/CS1/Configuration

• detect generic author, editor, etc names
• Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
• add "CS1 uses parameter: $1" properties tracking categories
• remove support for unused |isbn13= and |ISBN13=; discussion
• remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
• add support for nrf-gg, nrf-je language codes; discussion

Module:Citation/CS1/Whitelist

• Remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
• Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
• add "CS1 uses parameter: $1" properties tracking categories
• remove support for unused |isbn13= and |ISBN13=

Module:Citation/CS1/Date validation

• No changes

Module:Citation/CS1/Identifiers

• No changes

Module:Citation/CS1/COinS

• No changes

Module:Citation/CS1/Suggestions

• Uncomment suggestions for parameters moving from deprecated to unsupported

Links to relevant discussions, along with implementation date suggestions, are welcome in the above list; they should all still be on this page. I will come back and add the discussion links if I have time later. – Jonesey95 (talk) 21:39, 19 April 2021 (UTC)

arxiv-class

Really don't see the point of having |arxiv-class=, class doesn't cover anything else, and is only supported by {{cite arxiv}}. There's no confusion possible, and I object its creation. Headbomb {t · c · p · b} 23:32, 19 April 2021 (UTC)

Yes, you know all this only if you follow this page. There's a chance that the module may be targeted to a wider audience. On that outside chance, the module should present editors a consistent approach, and its documentation should expand on consistency as one of the design principles applied. Additionally, the documentation could include info about the particular template, such as the one you referred to above. Again on the outside chance that editors may not encounter Arxiv or arxiv citations on a daily basis. I know, it's a drag. But you are not the one doing it, it is somebody else's burden. 173.52.226.51 (talk) 00:39, 20 April 2021 (UTC)

Actually, I'm the one doing most arxiv-related cleanup. Again, there is no confusion with anything, class doesn't pertain to anything but cite arxiv because class is only used with cite arxiv. If you don't use cite arxiv, you will not see class anywhere. |arxiv-class= is busy work that serves no purpose but to cause confusion by renaming a uniformly-used parameter into a mismash of new and old for no reason. Headbomb {t · c · p · b} 00:50, 20 April 2021 (UTC)

What was meant as "burden" was the updating/maintenance of the module. Otherwise, and sincerely, I believe that any work you do to clean up this area is commendable. 98.0.246.242 (talk) 03:28, 20 April 2021 (UTC)

"class" is a pretty vague parameter. I'm not personally sold on moving deck chairs around though so... Izno (talk) 01:15, 20 April 2021 (UTC)

These discussions about parameter labels are very refreshing. Questions spring to mind: how is an editor to know that only {{cite arxiv}} uses a "class" parameter? Secondly, is there an implicit assumption that there will forever be only one "class"-labeled parameter in all of CS1/2? I understand that people with intimate knowledge of Arxiv will find the new term unnecessary and convoluted. I am not in favor of aliases, but I would recommend |arxiv-class= as an alias of |class= for this template. CS1/2 covers a diverse field of cited sources. It is not unusual to find in any article a number of different CS1/2 citation templates. At some point, it may be easier for the average editor to have to deal with a single standardized nomenclature (the one native to CS1/2) rather than wade through unfamiliar "industry" practice. Assuming that such nomenclature is simply and concisely explained. 98.0.246.242 (talk) 03:19, 20 April 2021 (UTC)

How is an editor to know that only {{cite arxiv}} uses a "class" |class= only appears in {{cite arxiv}} documentation, and is undermentioned anywhere else. Headbomb {t · c · p · b} 12:03, 20 April 2021 (UTC)

I have my doubts that even seasoned template editors would know this. It may require an extraordinary level of attention to the particulars of template/parameter documentation. 98.0.246.242 (talk) 23:57, 21 April 2021 (UTC)

CS1/CS2 parameters should follow a consistent naming scheme within the CS1/CS2 universe so that they are easy to memorize (and ideally can be constructed from memorizing the scheme without having to remember a particular parameter specifically or to look up it up the documentation). They should also be self-explanatory so that if a user runs into a parameter s/he can guess the meaning without having to look up the documentation. While there are still areas for improvement, I think we have improved quite a bit regarding this in recent years.

|class= by itself is quite meaningless and ambiguous. There are other possible "classes" that are used in conjunction with references. We don't currently use them but we might have other |...-class= parameters in the future, so I think it is time to prepare for this. We don't need to hurry, |class= can stay for the while being, but the |arxiv-class= parameter should exist as well for a smooth transition.

Parameters and attributes named "class" are also used for other purposes (for example in HTML), making it difficult to reliably search for the CS1 parameter |class=. Searching for |arxiv-class=, however, would not give false positives.

As the |arxiv= parameter is supported by other CS1 templates than {{cite arxiv}} as well, is there a specific reason why we do not support the |class= parameter in other templates as well?

--Matthiaspaul (talk) 19:48, 22 April 2021 (UTC)

Simply put, no. This is citations, not CSS. We do not need to preemptively disambiguate something that doesn't need disambiguation. As for not supporting it in other citations, it's because it's not relevant to other citations. This is something that's only relevant to {{cite arxiv}}. There is zero point in forking the parameter and breaking tools for, we have consistant usage, let's keep it that way. Headbomb {t · c · p · b} 19:52, 22 April 2021 (UTC)

Reverted the arxiv-class thing in the sandbox. This does not have consensus. Headbomb {t · c · p · b} 05:01, 28 April 2021 (UTC)

Headbomb, I think your removal was incomplete. The sandbox renders with red Lua errors. Scroll up and down this page to see them. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)

He removed the whole line and probably should not have since that is not undoing what the original edit did. ;) Fixed. Izno (talk) 05:19, 28 April 2021 (UTC)

Yes, thanks for fixing. LUA is awful. Headbomb {t · c · p · b} 05:55, 28 April 2021 (UTC)

I don't find your arguments that we shouldn't have |arxiv-class= very convincing.

{{cite arxiv}} is a CS1/CS2 citation template and within that family of citation templates all parameters should follow the same naming scheme in order to make it easier for editors to remember or even derive parameter names and their relations. This holds true also for parameters which are for some reason private to a specific template only, because otherwise we could have a |class= parameter in another template with a completely different meaning. |class= being a modifier for one of the identifiers (|arxiv=) its name should be |arxiv-class= following the example of all other such parameters we have (|doi=/|doi-broken-date=, |pmc=/|pmc-embargo-date=, |asin=/|asin-tld=) and a whole bunch of |bibcode-access=, |doi-access=, |hdl-access=, |jstor-access=, |ol-access=, |osti-access=, |s2cid-access=. They all start with the identifier name they belong to and end on the argument type to be entered (a date, a top-level-domain, an access state), so following this scheme a class type belonging to |arxiv= should be specified in a parameter named |arxiv-class=. This would be consistent. |class= by itself is not following this scheme and therefore is inconsistently named. It is also a meaningless parameter name by itself, so people running into it cannot derive its purpose from its name, and for people who are potentially using it, it is more difficult to remember because it is an exception to the mind model of how other parameter names were chosen.

Unfortunately, you didn't answer my question why we don't support the parameter in all CS1/CS2 parameter supporting |arxiv=. You just stated it would not be relevant in other templates, but did not answer why. In the original thread you even asked for |class= to become kind-of a mandantory parameter for {{cite arxiv}}; from this I derive that it is important to you. So, why is it important in {{cite arxiv}} and not in, say, {{cite book}} which supports |arxiv= as well? I'm asking because right now it is handled as an exception, and it would simplify the code if we won't have to treat it like an exception.

Regarding HTML/CSS, the existence of the "style" attribute was brought forward against naming a parameter |style=, which is (one reason for) why we settled on |name-list-style= eventually. Similar situation for "class".

Regarding scripts, adding a parameter is not breaking anything. And it would be trivial to change the scripts to support both parameters |arxiv-class= and |class=, anyway (if we don't fade out |class= at a later stage). If, as you stated, you are mostly alone working in this area, updating the scripts should be even easier. Of course, in an ideal world a good parameter name would have been chosen right from the start, so that there would be no desire to change it, but if we want to reach the goal of having a logical and consistent interface for all CS1/CS2 templates eventually, we shouldn't wait harmonizing parameter names until we actually run into a name conflict, because the longer we wait the more we will have to clean up afterwards. Therefore, even if we do not disable support for |class= soon (in order to keep backward compatibility until everyone has switched), we should start to educate people to use |arxiv-class= instead as soon as possible.

--Matthiaspaul (talk) 07:18, 28 April 2021 (UTC)

Except that class doesn't modify in anyway arxiv. What you'll find in {{cite arxiv}} is most typically {{cite arxiv|...|eprint=1234.54321|class=hep-ex}}. Headbomb {t · c · p · b} 09:27, 28 April 2021 (UTC)

I'm inclined to agree with Editor Matthiaspaul because I too don't find Editor Headbomb's reason persuasive. Editor Headbomb appears to be the only editor who is opposed; Editor Izno appears to be indifferent; IP editor (98.0.246.242, 173.52.226.51) appears to support; Editor Matthiaspaul supports; and I support because I am persuaded by the argument that parameter names should be correctly descriptive (we should think about |ref= – in another discussion). So, I think that Editor Headbomb's edit should be reverted.

—Trappist the monk (talk) 13:10, 28 April 2021 (UTC)

The argument for renaming the parameter arxiv-class in cite arxiv is as nonsensical as renaming isbn to book-isbn in cite book. It's a parameter unique to cite arxiv, there is no need for disambiguation, especially at the expense of creating unnecessary complexity that will cause maintenance headache and tool breakage. Headbomb {t · c · p · b} 15:49, 28 April 2021 (UTC)

I think right now I lean toward "let's not move the deck chairs around with only 3 in support and 1 opposed" at this time. Adding a parameter later is easy; removing one later is not. Generally I'd be appreciative for opinions from editors who aren't you four. I see persuasive arguments for changing the name but not sufficiently persuasive if all it is doing is moving deck chairs (or with the stated purpose of moving deck chairs).

That all said, I continue to prefer to wait until the CFD for the category responsible for this update be settled first, so perhaps others may comment and settle the matter. Izno (talk) 14:21, 28 April 2021 (UTC)

I would say that any discussion in these parts involving 4 editors is packed to the rafters... 98.0.246.242 (talk) 01:12, 4 May 2021 (UTC)

As much as it pains me to say it, Izno was right to say that we should wait for the CFD closure. Blargh. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)

Anyone want to update the list and support this update?

A number of changes have been made to the sandboxes since I posted the above list. Is there support for this out-of-cycle update? If so, please speak up here, and someone needs to update the above list of changes. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)

So long as arxiv-class is kept out, what's in there shouldn't be controversial / reflects RFCs. Headbomb {t · c · p · b} 09:25, 28 April 2021 (UTC)

Tracked parameter code (partially?) removed

The "discouraged parameter category" this CFD has been closed, and Pppery set the hyphenated parameters back to "true" in Whitelist/sandbox (no judgment on this action, just stating facts to keep the timeline straight). I don't think that change to just one of the modules will completely undo the parameter tracking system that we have set up. It is unclear to me whether the sandboxes are in a deployable state as of this time stamp. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)

I believe it's deployable in the sense that nothing would break were they to be deployed, but there's some now-dead code in the Configuration and main modules that someone could clean up if they felt inclined to. * Pppery * _{it has begun...} 00:45, 10 May 2021 (UTC)

I would recommend waiting. I have commented at the closer's talk page (well one of them) and at CfD regarding the closure, which imo is ripe for review. So let's see where this will go, if anywhere. Relax and enjoy! 98.0.246.242 (talk) 01:44, 10 May 2021 (UTC)

Note that this IP has now taken the CfD to deletion review at Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter. * Pppery * _{it has begun...} 13:23, 10 May 2021 (UTC)

wikilinks in |first=

At a discussion elsewhere, it was noted that cs1|2 doesn't alarm when |first= has a wikilink. |first= can't be used without |last= so when it is appropriate to link a name to that name's article, |author-link= is the appropriate parameter. To reinforce this, the documentation for |first= explicitly tells editors: 'Do not wikilink—use author-link instead.'

When I ran it, this search, which looks only for |first= (none of the aliases nor any of the other names – editor, interviewer, etc), found fewer that 100 instances. But, it times out, so who knows what's really out there.

• {{cite book/new |last=Blue |first=[[Black|B]] |title=Title}} → Blue, B. Title. {{cite book}}: Check |first= value (help)
• {{cite book/new |last=Blue |first=[[Black]] |title=Title}} → Blue, Black. Title. {{cite book}}: Check |first= value (help)
• {{cite book/new |last=Blue |first=Black |title=Title}} → Blue, Black. Title.

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

Going through last week's xCite dump for {{cite book}} yields 348 matches on 295 distinct pages (listed here, though I'm probably going to clean up some). I imagine books probably make up most of the author linking, so while it's out there, there's not vastly more than the search turns up. Vahurzpu (talk) 16:33, 20 April 2021 (UTC)

Reviewing changes to this module?

Looks like this module was changed to add a tracking category for certain parameters. Were those changes reviewed, and concenus reached before making them? I can't seem to find a discussion about it. -- Mikeblas (talk) 14:32, 21 April 2021 (UTC)

If you're talking about the discouraged parameter category, just do a find for the word "discouraged" on this page. That will lead you to the RFC, the RFC closure, the RFC unclosure, the RFC reclosure, and all sorts of other drama. The short version is that the category will be going away when the module is next updated. That discussion is also on this page. – Jonesey95 (talk) 14:42, 21 April 2021 (UTC)

Issues with `nrf-je` language code

Hey! I was editing Amélia Perchard, an article about a Jèrriais writer. One of the sources is in Jèrriais but while it is listed in the template docs as supported by MediaWiki, the hyphenated je is cut, and it results in an error as nrf isn't a language. (The same thing happens with Guernésiais, which is nrf-gg.) Is it possible this could be fixed (by not cutting the hyphenated section in these cases or something like that)? Thanks in advance! Remagoxer (talk) 18:15, 21 April 2021 (UTC)

Language support at MediaWiki is a mess in that it has quite a few nonstandard language tags that are meaningless to anyone outside of the MediaWiki universe:

bat-smg – {{#language:bat-smg|en}} → Samogitian but bat is Baltic languages and smg is Simbali (which is not an authorized IETF language tag extlang

de-formal, es-formal, hu-formal, nl-informal – formal and informal are not IETF variants

map-bms – {{#language:map-bms|en}} → Basa Banyumasan but map is Austronesian languages and bms is Bilma Kanuri (which is not an authorized IETF language tag extlang

simple – simple what?

sr-ec – {{#language:sr-ec|en}} → Serbian (Cyrillic script) but to the outside world, sr-ec means Serbian as spoken in Ecuador

Most other language-country pairs supported by MediaWiki have a matching language code that cs1|2 can fallback on: de-formal → de, etc. For whatever reason, likely because ISO 639-3 associates both Guernésiais and Jèrriais with nrf (see the custodian's website), these pairs do not.

I have tweaked the module sandbox so that after the next module-suite update, nrf-gg and nrf-je will work:

{{cite book/new |title=Title |language=nrf-gg}} → Title (in Guernésiais).

{{cite book/new |title=Title |language=nrf-je}} → Title (in Jèrriais).

In the meantime, |language=Guernésiais and |language=Jèrriais render correctly.

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

Thanks for adding support for the codes for the next update, and while I prefer codes the language names will do fine. Remagoxer (talk) 21:53, 21 April 2021 (UTC)

ref = harv

Someone has emptied Category:CS1 maint: ref=harv and a Special:Search for |ref=harv seems to indicate there are indeed no other uses. Is there a good way to indicate to the user that the keyword is no longer necessary? (I let someone know on their talk page today.) Make it an error for some time (say a year or two) and then turn the error off and silently accept the value as literal 'harv'? Izno (talk) 03:20, 24 April 2021 (UTC)

Izno: Is the process you're (almost) suggesting this: begin with the status quo (not an error, just unnecessary/extraneous), then to make it an error (for a year or two), then make it not-an-error again (although nothing has changed in the support for the parameter)? I hope this question doesn't sound belligerent; I'm sincerely trying to understand the situation. — JohnFromPinckney (talk) 10:21, 24 April 2021 (UTC)

Yeah, it sounds gross, doesn't it? Just trying to get people to stop thinking of it as a keyword, and maybe at some future date, letting people put 'harv' in as text and have that be the id generated, if they care to (I don't know why they would want to). Ttm is right that people don't read the manual (well, my experience is a lot don't read the errors either). Izno (talk) 15:37, 24 April 2021 (UTC)

Thanks for your response. I get really...irritated... when people say nobody reads the documentation (on WP or IRL). I mean, I read the documentation, so the implication is that I'm nobody. Ugh. And if the claim were true, we could "save" a lot of time and space by deleting all our doc pages and never writing any more. Since that seems not to be the case, we must believe the documentation does some (marginal?) good.

In any case, I believe the documentation we have should be complete and correct. Therefore, I agree with part of what Trappist said: either all mention of |ref=harv should be expunged, or we should say, "This thing used to exist, but was deprecated in April 2021. Don't use it anymore". Talking about causing errors when people are following the current documentation is insane and disrespectful. And could cause people to stop reading documentation.

We still have

1. CS1 templates and {{Citation}} set |ref=harv as the default. here,
2. ...or a CITEREF auto anchor when |ref=harv is set here,
3. and Since April 2020, the parameter / keyword pair |ref=harv has no special meaning; |ref=harv may be removed from existing cs1 at csdoc, visible at Template:Cite book and similar.

All these and any other mentions should be fixed long before any error messages get shown. — JohnFromPinckney (talk) 11:20, 25 April 2021 (UTC)

The CS1 templates documentation is up to date. The problem there's half a dozen or more other documentation pages that have been written by a bunch of people, and are barely read. The issue is finding them all. I've never seen Wikipedia:Citation templates and reference anchors before for example, and I've been doing citation work for well over 10 years on Wikipedia. I've updated it, but if some other page still has |ref=harv on them, well it's pretty hard for us to know that, since those pages aren't part of the "official" CS1 documentation. Headbomb {t · c · p · b} 11:34, 25 April 2021 (UTC)

If you know how to improve the cs1|2 documentation (and when appropriate the documentation of other templates), please do so. Clear and concise documentation is difficult to write in a way that is accessible to the lay editor; it has been noted that I do not have that talent.

I find it hard to believe that editors regularly read template documentation but find it easy to believe that they might, might, read it when they get stuck for some reason. When they get stuck, editors will be looking for a solution, and not necessarily looking to see what changes are coming so the minor changes to the documentation that attend deprecation are likely to go unnoticed.

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

I don't know about disrespectful, but it seems clear no one will disagree that documentation should be fixed. :)

Inspired by the existence of {{para}} yesterday, here is a search that should find a whole bunch more uses. Izno (talk) 13:53, 25 April 2021 (UTC)

Perhaps a slightly more targeted search. I fixed about a dozen like this. – Jonesey95 (talk) 20:41, 25 April 2021 (UTC)

Because no one ever RTFM, the only way to educate editors is to make |ref=harv an obvious error. If we don't do this, this meaningless parameter/value pair will just be more accumulated detritus that will need to be removed by someone else. Before making this an error, all mention of |ref=harv must be removed from all cs1|2 documentation and from all {{sfn}} and {{harv}} documentation, and from anywhere else that it might be lurking. So, I favor converting ‹The template Category link is being considered for merging.› Category:CS1 maint: ref=harv to an error category ‹The template Category link is being considered for merging.› Category:CS1 errors: ref=harv with appropriate help text, etc.

This search finds about 60 Help, Template, and Wikipedia namespace pages that have |ref=harv which might be candidates for cleanup.

—Trappist the monk (talk) 11:55, 24 April 2021 (UTC)

But this is not an error. It is superfluous as it is the parameter's default value, but it does not affect the citation. And Monkbot patrols this so there is already some cleanup taking place. As long as the documentation is properly adjusted in all areas (including Monkbot's), I would let the bot do the work. Resulting complaints would then (hopefully) be addressed by clear & robust doc. 24.103.251.114 (talk) 12:34, 24 April 2021 (UTC)

And Monkbot patrols this Nope. Not since the RFC killed it.

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

News to me. I thought the RfC only mandated the bot stop replacing six unhyphenated parameter labels. Surely that function could be disabled in the bot's code? Instead of killing the bot. Imo it is a useful cleanup tool. I have not looked at the code to see if this is feasible. 24.103.251.114 (talk) 12:57, 24 April 2021 (UTC)

I asked if task 18 could come out of suspension after the Option-B-with-restrictions RFC close (Wikipedia:Bots/Noticeboard#Monkbot 18 (2)); the answer was: no. Asking after the Option C close which says, in part: "bot approval should be revoked" seems a pointless exercise. The hyphenation subtask is easily disabled but, the only non-cosmetic actions task 18 took was repair of articles listed in ‹The template Category link is being considered for merging.› Category:CS1 errors: empty unknown parameters. Some in the community are likely hypersensitive to Monkbot/task 18 doing anything which would lead to drama so I'm not interested in resurrecting it except if we ever have a cosmetic bot day (I'm not going to hold my breath for that ever occuring).

—Trappist the monk (talk) 13:26, 24 April 2021 (UTC)

Fair enough. But by the same logic, anything done here is likely to upset the snowflakes. If people are hypersensitive to Monkbot, the appearance of a new error category may produce similar reaction. 173.52.226.51 (talk) 15:02, 24 April 2021 (UTC)

I've changed my mind. |ref=harv is really a form of invalid parameter value so the category should be ‹The template Category link is being considered for merging.› Category:CS1 errors: invalid parameter value‎.

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

Fitting actions to my words, I have tweaked Module:Citation/CS1/sandbox and ~/Configuration/sandbox:

{{cite book/new |title=Title |author=Blue |date=2021 |ref=harv}} → Blue (2021). Title. {{cite book}}: Invalid |ref=harv (help)

'"`UNIQ--templatestyles-000000ED-QINU`"'<cite id="CITEREFBlue2021" class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>

{{cite book/new |title=Title |author=Blue |date=2021 |ref=none}} → Blue (2021). Title.

'"`UNIQ--templatestyles-000000F1-QINU`"'<cite class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

{{cite book/new |title=Title |author=Blue |date=2021 |ref=CITEREFSandbox}} → Blue (2021). Title.

'"`UNIQ--templatestyles-000000F5-QINU`"'<cite id="CITEREFSandbox" class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

{{cite book/new |title=Title |author=Blue |date=2021 |ref={{sfnref|Blue|2021}}}} → Blue (2021). Title.{{cite book}}: CS1 maint: ref duplicates default (link)

'"`UNIQ--templatestyles-000000F9-QINU`"'<cite id="CITEREFBlue2021" class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: CS1 maint: ref duplicates default ([[:Category:CS1 maint: ref duplicates default|link]])</span>

{{cite book/new |title=Title |author=Blue |date=2021 |ref=}} → Blue (2021). Title.

'"`UNIQ--templatestyles-000000FD-QINU`"'<cite id="CITEREFBlue2021" class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

{{cite book/new |title=Title |author=Blue |date=2021}} → Blue (2021). Title.

'"`UNIQ--templatestyles-00000101-QINU`"'<cite id="CITEREFBlue2021" class="citation book cs1">Blue (2021). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2021&rft.au=Blue&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Because those tweaks were made to code used to detect invalid parameter values for a variety of parameters, a couple of non-|ref= parameter tests:

{{cite book/new |title=Title |author=Blue |date=2021 |url=//example.com |url-access=nonsense}} → Blue (2021). Title. {{cite book}}: Invalid |url-access=nonsense (help)

{{cite book/new |title=Title |author=Blue |date=2021 |url=//example.com |url-access=subscription}} → Blue (2021). Title.

—Trappist the monk (talk) 16:45, 25 April 2021 (UTC)

Module:Citation/CS1/testcases/anchor for regression checks... Izno (talk) 17:33, 25 April 2021 (UTC)

I confess that I do not like that form of unit tests. To know what is actually being tested and what the test is looking for, one must read the test code. Pass results where 'Actual' is blank and 'Expected' is blank is entirely counterintuitive as are tests that should fail (testDatesExtraNd(), testDatesExtraNdPunct(), testTrailingAuthorDash()). Two tests fail for reasons that make no sense to me: testDatesUnexpectedLetter() and testDatesUnexpectedMaint(). When I hand assemble the cs1|2 templates that those two tests are looking at, I don't see anything wrong. Why are they failing? The missing trailing underscore disappears when CITEREF_A1_ is anchor-encoded; try this in the debug console: =mw.uri.anchorEncode('CITEREF_A1_'). In an anchor, an underscore represents a space character so I suspect that trailing spaces are trimmed.

—Trappist the monk (talk) 18:16, 25 April 2021 (UTC)

The reason these are preferable for HTML ID generation if no others is because the other module suite results are invisible and require review of the HTML instead.

More generally, you don't need to read the test code if you do not want in the general case. The point is to test for regressions. If all the tests pass, then what value is knowing that Citation X looks like Citation X_sandbox? None. But even beyond that, I also don't want to spend time looking at each particular test to see why it is different; I note that in at least one case for recent changes you specifically said "a whole bunch of tests fail but you can't see why". Which is fundamentally garbage for a test suite. I should know at a glance that a test has failed and then I can move on looking for why it is failing.

Secondly, it is not trivial in the other test module to test the sandbox implementation specifically matches a designed implementation. When I making changes in a sandbox, it does me little-to-no good to know that something is different than the live module; I should have the desired implementation that I am testing against which should be the target for implementation. That is very hard to do with that module suite today because it tests the entire template output which includes the TemplateStyles token; that token cannot be removed except in the function we use for our tests today. (Speaks to need for improvement of that suite.) I want to do what are effectively unit tests, not integration tests.

I don't like that blanks are displayed either, but that's functionally what a green test in software development means and probably why these templates do so as well. You don't need to know on the test case run page what that means because your tests are already built the way you should expect (were this a well-designed system of course with testing implemented from the beginning).

I will start a separate thread below this one to discuss the specific tests failing today. Izno (talk) 19:41, 25 April 2021 (UTC)

I have no problem with testing, but how is |ref=harv an "invalid" value? Isn't The {{harv}} anchor generated by default? 98.0.246.242 (talk) 02:24, 26 April 2021 (UTC

cs1|2 templates create default anchor IDs. The notion of 'harv' has meaning to the current cs1|2 module because maintaining an internal harv default value for the Ref meta-parameter was an expedient fix once the decision had been taken to always provide an anchor ID. In the sandboxed version, the need for an internal harv default value has been removed (there is no default value for Ref). |ref=harv is invalid because we want to train editors away from the habit of using it; the wasted effort to include it in cs1|2 template does nothing but clutter the wikitext.

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

I am trying to understand this, with the caveat that I almost never look at sandbox code unless I'm developing it. How are anchor IDs created? Doesn't such auto-creation imply a default value then? Also, is their target still a short ref? Does this have to do with a more "explicit" citeref anchor creation? These sound like important changes that are sort of just coming out. 50.74.165.202 (talk) 14:42, 26 April 2021 (UTC)

cs1|2 anchor IDs are the targets; they don't target anything.

In the live module, the code looks at the meta-parameter Ref. If none is the assigned value then no anchor ID. If harv or if Ref is blank, module assembles a CITEREF anchor ID from the contributors name-list or from the authors name-list or from the editors name-list (in that order; lists not mixed), and the year value from |year= or from |date= or |publication-date= (whichever is rendered). Any other values are used as the anchor ID without modification.

In the sandbox, the code looks at the meta-parameter Ref. harv is blanked and an error message emitted. If none is the assigned value then no anchor ID. If blank (may have been blanked when the error message was emitted), sandbox module assembles a CITEREF anchor ID in exactly the same way as the live module. Any other values are used as the anchor ID without modification.

There is no 'default' value for |ref= unless you believe blank to be a value.

Does this have to do with a more "explicit" citeref anchor creation? I don't know what this question means.

—Trappist the monk (talk) 15:53, 26 April 2021 (UTC)

Sorry. By explicit was meant that citeref might be declared to the user (as a |ref= replacement or other user action) instead of being "silently" generated. So actually the only difference between live & sandbox is the elimination of the keyword "harv". A null value for |ref= still generates a citeref anchor. In the live module a target for such anchors are corresponding short references, if someone decides to use them. 50.74.21.22 (talk) 19:07, 26 April 2021 (UTC)

The user (editor) declares to cs1|2 what the anchor ID will be, either implicitly by omitting |ref= or by leaving |ref= blank, or explicitly by setting |ref=<some value> which may include the keyword none. cs1|2 does not [declare] to the user.

In the live module a target for such anchors are corresponding short references. No. CITEREF anchors in cs1|2 template (long-form) are targets of {{sfn}} and {{harv}} templates (short-form). The linkage is one-way, from short-form to long-form. This is true in both the live module and in the sandbox module.

the only difference between live & sandbox is the elimination of the keyword "harv" Yes, in essentials. When |ref=harv, the live module emits a maintenance message and categorizes the article into ‹The template Category link is being considered for merging.› Category:CS1 maint: ref=harv‎ while the sandbox emits and error message and categorizes the article into ‹The template Category link is being considered for merging.› Category:CS1 errors: invalid parameter value‎

—Trappist the monk (talk) 19:29, 26 April 2021 (UTC)

You are correct that was muddy language on my part. I would rephrase it to say the anchor is generated by the long form, applied to the short form, and targets back the long form. I also mistakenly thought that you were considering removal of |ref= in favor of exposing the underlying citeref and then declaring that as a user-editable value. I mixed it up there. 98.0.246.242 (talk) 01:23, 27 April 2021 (UTC)

Update/shameless plug of WP:UPSD, a script to detect unreliable sources

It's been about 14 months since this script was created, and since its inception it became one of the most imported scripts (currently #54, with 286+ adopters).

Since last year, it's been significantly expanded to cover more bad sources, and is more useful than ever, so I figured it would be a good time to bring up the script up again. This way others who might not know about it can take a look and try it for themselves. I would highly recommend that anyone doing citation work, who writes/expands articles, or does bad-sourcing/BLP cleanup work installs the script.

The idea is that it takes something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14.

It will work on a variety of links, including those from {{cite web}}, {{cite journal}} and {{doi}}.

Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable. Headbomb {t · c · p · b} 13:20, 25 April 2021 (UTC)

Module:Citation/CS1/testcases/anchor and some questionable tests

as are tests that should fail (testDatesExtraNd(), testDatesExtraNdPunct(), testTrailingAuthorDash()). Two tests fail for reasons that make no sense to me: testDatesUnexpectedLetter() and testDatesUnexpectedMaint(). When I hand assemble the cs1|2 templates that those two tests are looking at, I don't see anything wrong. Why are they failing? The missing trailing underscore disappears when CITEREF_A1_ is anchor-encoded; try this in the debug console: =mw.uri.anchorEncode('CITEREF_A1_'). In an anchor, an underscore represents a space character so I suspect that trailing spaces are trimmed. —Trappist the monk (talk) 18:16, 25 April 2021 (UTC)

I have been meaning to bring up the specific failures in those test cases and just haven't gotten around to it.

1. testDatesExtraNd and testDatesExtraNdPunct: I have seen people work around the fact that we support n.d. in the date field indicating no date or undated. {{cite book|title=T |date=n.d. |first=F |last=_L_}} which displays as _L_, F (n.d.). T. and generates CITEREF_L_n.d.. Our standard SFNs then look like (_L_ n.d.) which people don't like the look of. I do not know if that should be how it works and I do not know how much effort it would be to change it if we want it to work another way.
2. testTrailingAuthorDash: Yes, I think it is trimming the underscore also, but I haven't been able to find where that is implemented to confirm. I do not know if we should care either. If not, it is a bad test and can be removed or changed (probably removed as a duplicate). I do not think there are many authors (perhaps on the web in a nickname?) with an underscore as their final character. As long as other systems (SFN) understand that underscore may end up trimmed, we are also probably fine.
3. testDatesUnexpectedLetter is my documentation (that should really be in the date validation module) that if you pass a letter in |date= where it is not strictly a year that you will get the letter back out in the displayed output, as so: {{cite book|title=T |date=1 January 2020a}} _A1_ (1 January 2020a). T.{{cite book}}: CS1 maint: numeric names: authors list (link). I would expect the letter to be trimmed with a full date on the output to the date display and kept for the context of the generated ID. But perhaps that is just me and the test should not be "unexpected".
4. testDatesUnexpectedMaint is a similar story but somewhat in reverse. When you have a template {{cite book|title=T |author=_A1_ |date=1 January 2020 |year=2020a}} you get this output _A1_ (1 January 2020). T.{{cite book}}: CS1 maint: date and year (link) CS1 maint: numeric names: authors list (link). Of course, the disambiguation is retained correctly in the CITEREF (you'll note you can't see it in this comment ;), but displaying the maintenance message when we have a template like this which disambiguates the ID without displaying the letter in the date output as in testDatesUnexpectedLetter doesn't make sense.

How we disambiguate IDs in general isn't great and is kind of a hack on. I know I've commented before that I don't think we should need |year= at all but am only half-interested today in discussing that. ;) Those two are probably just fallout of that. Izno (talk) 21:11, 25 April 2021 (UTC)

In general, any test that produces false positives (or negatives) with some consistency is a good candidate for the trash can, imo. For the particular cases above there may be other solutions. I would consider two date parameters in a citation an obvious error. The more specific date always wins. The additional appearance of a more generalized component such as the year, can only mystify or confuse the reader, and diminish the value of a citation. There should also be an optional facility to disambiguate full dates in the citation itself, again for the sake of reader clarity. Since the ease of publishing has made authoring more prolific, there may well be cases in the same article of citations with the same author and full date. Another corner case would involve the same author with more than one undated work cited in the same article. There are several inelegant solutions for these disambiguations, such as creating a conditional dab-specific parameter to tweak the display when |date= is present. 50.74.165.202 (talk) 15:09, 26 April 2021 (UTC)

Regarding using |year= to enter those letter disambiguators, I think we should devise some way so that dates and disambiguators have separate parameters eventually.

In order not to introduce a new parameter for the disambiguators I think overloading the |ref= parameter might work.

My first idea was to let |ref= interpret single-letter arguments as disambiguators for CITEREF anchors, and any other values as non-CITEREF anchors (unless they match one of the supported keywords like "none" or "harv"). Unfortunately, occasionally people are using single-letter arguments for non-CITEREF anchors as well (but this is rare), so we would have to first switch them to longer strings in affected articles.

Alternatively, we could change the logic so that arguments starting with a prefix like # will be interpreted as disambiguators for CITEREF-anchors with the # stripped off, so that something like |year=2021a or |date=2021a could instead be given as |date=2021 |ref=#a resulting in the same "CITEREFLast2021a" anchor (not "CITEREFLast2021#a" or "#a") whereas |date=2021 |ref=a would result in a non-CITEREF anchor "a" like before.

Thereby we would have the two values separated and wouldn't have to provide two date parameters when ISO dates should be used at the same time as disambiguators (and weird things like |date=2021-04-26 |year=2021a could be written more logical as |date=2021-04-26 |ref=#a). At a (much) later stage, support for disambiguators in the date parameters could be faded out (become undocumented or removed) and |year= would no longer be needed.

--Matthiaspaul (talk) 16:57, 26 April 2021 (UTC)

This scheme would even work with different methods to create anchors. |ref=#a could be seen as a shortcut version of |ref=harv#a. (If a hyphothetical future anchor generation scheme |ref=super would still need manual disambiguators at all, they could be given as |ref=super#a.)

--Matthiaspaul (talk) 17:14, 26 April 2021 (UTC)

If you need a disambiguating letter, you'll have to provide it somewhere. If it doesn't fit in |date=, you can currently either add |year= or use |ref={{sfnref|Last|YYYYa}}. I don't see the value in adding complexity for this rare edge case when two viable workarounds are already available, and both current workarounds allow an editor to search the wikitext for "YYYYa" to easily locate a matching (or broken) citation template. – Jonesey95 (talk) 21:20, 26 April 2021 (UTC)

|date=n.d. and |year=YYYYa are widely used and easily understood by editors and readers. Trying to find a different approach seems like an exercise in finding something to fix that doesn't need fixing. -- Michael Bednarek (talk) 01:03, 27 April 2021 (UTC)

Actually, I always considered these letter-disambiguators in dates one of the worst ad-hoc hacks in our citation templates - appending letters to what should actually be (only) dates does not make any sense at all to me. It should have been a separate parameter right from the start. So, what we would be doing is finally fixing a problem that never was solved properly. Implementing this as an alternative would add very little extra code, and if we could, at a later stage, even fade out the existing usage of disambiguators in date parameters, it would further improve the date format checking code and simplify the implementation as a whole.

--Matthiaspaul (talk) 12:24, 27 April 2021 (UTC)

Jonesey, I think these are the things I don't like in the current way of doing this:

• Using |year=YYYYa or |date=YYYYa is mixing two properties which do not belong to each other into one parameter. What do dates have to do with the fact that there is more than one publication from the same author and year cited in a single article? Nothing. It is also mixing layers with having to provide presentation layer stuff on parameter input level (like why we detect extra text like "No." in |number=). If we would want to change the presentation in the future, it will be difficult to pry this apart again. Also, the same citation cannot be used in a different article without having to edit a semantically unrelated date parameter rather than the semantically related ref parameter and this even although the date doesn't change at all. There's a risk to introduce typos and all third-party instances reading citations on source code level have to deal with this special case as well. So it unnecessarily adds maintenance overhead.
• Using |year=YYYYa in addition to |date=, you will get a maintenance warning. Also, you will have to repeat the year, that is, one property has to be given in two parameters - this goes against the principle of having to provide each property only once and let the template do the work of using it where necessary.
• Using |ref={{sfnref|Last|YYYYa}} you will have to even repeat multiple properties in more than one place, year and author name(s). And it exposes more details of the CITEREF anchor naming scheme than necessary to know for a user who just wants to disambiguate citations from the same author and year in an article, making it more difficult to change the scheme would this be needed at some point in the future.
• Since the date validation code has to accept these disambiguators as an exception to normal date formats it isn't as tight as it could be. "2021a" could be a date mixed with a disambiguator, or just a typo...

--Matthiaspaul (talk) 13:05, 27 April 2021 (UTC)

This is regarding the cases delineated by Izno in the testcases. If you are a reader, you see a full date and separately a year. Something is wrong here. Can this reference be trusted? Or you see a disambiguated year in a short, with no match at the targeted long form which uses a full date. Is this even the right target? As a reader and part of the 99% of Wikipedia users you are right to wonder. 98.0.246.242 (talk) 01:31, 27 April 2021 (UTC)

In the discussion I recall having but not being able to locate, I was sad that |year= remains a separate parameter from |date= in the module code, so it requires separate coding to ensure (as in the case above) that when |year= and |date= are both used that they emit a maintenance message. So in the test cases above I subsequently showed one of my sadnesses with the current code, entirely separate to that one, that occurs when you want to have the disambiguation but not see the letter in a full date. As I said, I don't know if I am appropriately sad for that. The only reason why we have |year= still is because we need to be able to disambiguate the YYYY-MM-DD case trivially. (Which off the cuff does not emit the maintenance message, possibly because we recognize ISO as valid.) Which is essentially the followon discussion that Matthias went straight to. :^) Izno (talk) 02:33, 27 April 2021 (UTC)

True, I confess I'm guilty of that. ;-) However, I planned to bring this up on the table for months - and never found the time for it... And now that you mentioned it I could no longer hold back.

--Matthiaspaul (talk) 12:24, 27 April 2021 (UTC)

I like the idea of |ref=single_letter where a trivial disambiguation is needed. I had been considering a |target-disambig= (naming TBD clearly) as an entirely separate entity to take care of it. I don't like that idea because it's another parameter that would have a similar responsibility to |ref= (gosh, |ref='s name is crap in retrospect). I would like to hunt down when the addition of "a" to the year or date was added to see what they considered originally and why another path was not taken. (Or perhaps it was like that before the Lua transition.)

I am strictly not in favor of anything needing to deal with "#" and would definitely see that as making things more complex both for implementation and user interface, not less. We would need to remove the # and add the letter rather than more constructively just adding the letter. Izno (talk) 02:27, 27 April 2021 (UTC)

Yeah, without the # it would be even easier - to remember and also to implement. However, then we would have to check and fix existing usage of single letters for non-CITEREF anchors in |ref= first. I ran some searches a couple of months ago - they are not that common, but they exist. IIRC, I could not find a single case of such anchor names starting with #, that's why I thought the # could be used to open kind-of a new namespace for these disambiguators.

--Matthiaspaul (talk) 12:24, 27 April 2021 (UTC)

Thinking about it, perhaps the logic could be switched so that |ref= takes either a CITEREF disambiguator (like |ref=a, but possibly even for disambiguators longer than a single letter), or, if started with a # prefix, a non-CITEREF anchor name (like |ref=#anchor-name), or a keyword (|ref=none/harv). Given that one has to use page-name#anchor-name to refer to a specific anchor on a page, having to use a # prefix when specifying these anchor names in |ref=#anchor-name seems to be quite intuitive to me. Of course, it would require that we first fix up existing usage of non-CITEREF anchors in |ref= by switching |ref=anchor-name to |ref=#anchor-name.

--Matthiaspaul (talk) 08:02, 28 April 2021 (UTC)

Ok, I've convinced myself #3 and #4 are bad tests. Heh. I think there is still value in thinking about whether it wouldn't just be better to make ISO disambiguation consistent in some way. Izno (talk) 03:03, 27 April 2021 (UTC)

series-number

The list of deprecated parameters says to use series-number=, but it doesn’t appear in the full parameter list. When I use it in {{cite book}}, there’s no error message but it doesn’t appear in the citation. I searched some of the talk archives, but gave up. What’s up with series number? — Preceding unsigned comment added by Mzajac (talk • contribs)

|series-number= and its aliases is not and has not been supported in {{cite book}}. --Izno (talk) 19:09, 28 April 2021 (UTC)

|season=, |series-no=, and |series-number= are all used only by {{cite episode}}; |series-link= is only used by {{cite episode}} and {{cite serial}}. I have moved these parameters out of the basic_arguments{} table and into the unique_arguments.episode{} and unique_arguments.serial{} tables.

—Trappist the monk (talk) 19:29, 28 April 2021 (UTC)

Also, |cartography= to unique_arguments.map{}

—Trappist the monk (talk) 19:41, 28 April 2021 (UTC)

And:

|book-title= to unique_arguments.conference{}

|conference=, |conference-format=, |conference-url=, |event= to unique_arguments.conference{} and unique_arguments.speech{}

|degree= to unique_arguments.thesis{}

|docket= to unique_arguments.report{} and unique_arguments.thesis{}

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

Thank you. Sometimes books in a series have an ordinal series number. In the example I recently encountered, the book’s title page has the series title and ordinal at the top above the author and book title: “Essays from the History of Ukrainian Culture ¶ Book 3.”

• Keywan, Ivan (1984). Ukrainian Fine Arts. Essays from the History of Ukrainian Culture (in Ukrainian and English). Edmonton, AB: Ukrainian Women’s Association of Canada. pp. 195–96. {{cite book}}: Unknown parameter |series-number= ignored (help)CS1 maint: unrecognized language (link)

In CMoS style (14.123: Series titles, numbers, and editors), the series number follows the series title, and may be preceded by vol. or no., and a book may have both. —Michael Z. 02:34, 29 April 2021 (UTC)

It may make more sense to use the issue/number parameter for this. —Michael Z. 02:41, 29 April 2021 (UTC)

Are you referring to series number or volume number? Asking because the example you presented is a volume number in a named series. In print, I have only encountered series numbers in periodicals, usually but not exclusively in academic or literary journals. Again usually after a periodical resumes publication after a hiatus or/and under new publisher or/and new editorial direction. In general, including books, you can use |series=. 69.203.117.115 (talk) 19:13, 29 April 2021 (UTC)

How did you determine that? CMoS implies that what it calls the “number” may take either vol. or no., but that the abbreviation is not normally required. An exception is when both appear, as in an example given:

• Wauchope, Robert. A Tentative Sequence of Pre-Classic Ceramics in Middle America. Middle American Research Records, vol. 1, no. 14. New Orleans: Tulane University, 1950.

I suppose I can use volume here, but that will not suffice somewhere else. Off the top of my head, I think of the latest English translation of the History of Ukraine-Rus’, which actually has a Volume 9, book 2, part 2.[4] —Michael Z. 21:15, 29 April 2021 (UTC)

Well, from the verso you quoted above, the series is named "Essays from the History of Ukrainian Culture", this concerns book (or volume or number) 3 in the series, and the volume is titled "Ukrainian Fine Arts" (I would not use the generic "Book 3" as a volume title. Obviously, volumes with specific titles are easier to locate). The template {{cite book}} is a fit, and provides the parameters you require: Ukrainian Fine Arts. Essays from the History of Ukrainian Culture. Vol. 3.

I don't know if by CMoS you mean the Chicago Manual of Style, but if you do, I would caution you that Citation Style 1 is a native Wikipedia format and does not necessarily follow external citation styles, especially in the details.

... [A]ctually has a Volume 9, book 2, part 2. What can be sourced are discrete, unambiguous items. An article in a print journal cannot be a source, because it cannot be obtained as a discrete item. To find it, you must first find the journal. So that is your source, and the article is a location in that source. Following this logic, which one of the "Volume 9, book 2, part 2" items can be referenced by itself? I would think it would be "Volume 9". Obviously the overall title must be also included for disambiguation. If there is a multi-part Volume, and the parts have been published as discrete items, all this info should be included. Since the templates are not going to provide exact fit for rarer cases (they are templates, not custom solutions), I would combine/concatenate the info. 98.0.246.242 (talk) 00:10, 30 April 2021 (UTC)

I’m not sure what you mean by “sourced.” Of course a journal article can be referred to through a doi, or just by its author, title, and date, for example, and in some cases has been sold separately by its publisher in either digital or print version. Regardless of that, v 9, b 2, p 2 is indeed a discrete print book, sold individually (or in a set), with ISBNs for its paper and cloth-bound versions. Anyway the fields for volume and issue/number are already there, so I don’t know why we would choose to deny editors having them just work for items that have a volume and issue number. —Michael Z. 02:04, 30 April 2021 (UTC)

"Sourced"=found as far as the reader is concerned. Notice that the journal example was referring to print media. Even in online media a doi is not sufficient as reference in a general-purpose encyclopedia. It is appropriate to provide some context, as there is already enough shorthand notation in a Wikipedia citation to mystify the average non-expert reader. I don't understand the last part, "issue" is normally used for periodicals. I don't remember ever seeing "issue" associated with books. 67.254.224.137 (talk) 12:23, 30 April 2021 (UTC)

Of course, I think we both agree a citation should present its fullest for to help readers. I wrote issue (number) as opposed to volume number or series number. Isn’t issue= an alias for number= in the framework? —Michael Z. 12:49, 30 April 2021 (UTC)

Conceptually (as in the documentation), yes. And as you can see it is an erroneous concept, since "number" is ambiguous. It could mean volume number, or (per the current discussion) series number. Programmatically, the argument (parameter) "number" is also made an alias of "issue". Conceptually (as in module design) this is also erroneous, and for the same reasons. 98.0.246.242 (talk) 14:41, 30 April 2021 (UTC)

What is erroneous? Volume and number are the larger and smaller series ordinals in sets of books and journals. They are often cited exactly the same way. So let’s enable the existing number= for {{cite book}}. —Michael Z. 15:08, 30 April 2021 (UTC)

Well, you asked if issue was an alias of number in this framework, which it is. Also in this framework, issue is not used for book citations. And the value for volume may be a literal title or a number. Since "number" may refer to different parameters, using it without context is a conceptual error. The correct approach would be to have "issue number" an alias of issue and "volume number" an alias of volume. Assuming aliases are really necessary here. 98.0.246.242 (talk) 15:35, 30 April 2021 (UTC)

You convinced me that the distinction between volume number, book number, issue number, series number is not clear cut. So since many books have two numbers, why not include one of the existing numbers in its template? I am not picky about what aliases it carries. —Michael Z. 17:25, 30 April 2021 (UTC)

PMID range check

The PMID upper bound check needs to be revised.

If the value is correct and larger than the currently configured limit of 33900000, please report this at Help talk:Citation Style 1, so that the limit can be updated.

--Whywhenwhohow (talk) 03:45, 29 April 2021 (UTC)

2200 papers a day. 34232000 should get us to October sync, 34428000 to January sync, 34624000 to next April 1 sync. Izno (talk) 03:59, 29 April 2021 (UTC)

Or, let's be generous, and make it 35000000. Headbomb {t · c · p · b} 06:17, 29 April 2021 (UTC)

The numbers were for reference and to try to time it out so that we aren't post-release twiddling our thumbs. :^) Izno (talk) 13:44, 29 April 2021 (UTC)

Was just about to post I had problems with PMID 33901420. Why do we need an upper limit in general? Does it really prevent many errors? If yes 39999999 is probably a good value. It checks the first digit and maximum number of digits and should be fine for a while. -- {{u|Gtoffoletto}}  ^talk 11:44, 29 April 2021 (UTC)

They do prevent errors, but minute increments that need fixing every 2-3 months are too little. 35000000 gives us well over a year of checks. 39999999 gives us 7 years. Headbomb {t · c · p · b} 11:58, 29 April 2021 (UTC)

I'd say either 39999999 or 35999999. The check we are making is on the number of digits and the first 1 or 2 digits (1 is probably enough). Everything else does not give an error. You probably don't catch more errors with smaller increments. Just more work. -- {{u|Gtoffoletto}}  ^talk 13:03, 29 April 2021 (UTC)

I have problems with PMID 33941312 (article from 2021, May 4), upper bound should be updated. — Lady3mlnm (talk) 05:59, 7 May 2021 (UTC)

The upper bound was a week ago. Whatever issue you are having on whatever article (you did not link), it is not due to this check. Izno (talk) 09:23, 7 May 2021 (UTC)

References

Should (must) template's |title= come from target <title>?

Is there any consensus, particularly for {{cite web}}, about where we should get the value for the CS1 |title parameter? I have had the impression, lo these many years, that we use the value found in the page's <title> element (as generally displayed in the tab or title bar), possibly minus the who-we-are stuff at the end. (When I was editing music articles a decade ago the common opinion seemed to be to use the exact, entire <title>, giving us stuff like |title=50 Cent Says Slim The Mobster Was Dropped From Aftermath Records {{!}} HipHopDX where |website=HipHopDX then led to somewhat repetitive citations.)

Lately (the last two years, anyway), it seems that editors tend to consistently when they use anything use the <title>, but usually lopping off the "| HipHopDX" or "| British Vogue" bits. The possible titles sometimes differ, as in this NYT story, where I would ignore the headline "F.B.I. Searches Giuliani's Home and Office, Seizing Phones and Computers" and use the "Rudy Giuliani's Apartment Searched in Federal Investigation" from <title>, trimming the " - The New York Times" at the end. Is that wrong?

I tried searching the archives here (as well as the cite web documentation and WP:CITE) but I don't know how to differentiate "<title>" from "title" in my search, and so get every instance of "title". Has this been discussed? What's best? — JohnFromPinckney (talk) 16:04, 29 April 2021 (UTC)

Title is what the page says, not what HTML elements say. For example, the HTML <title> of this page is Help:Citation Style 1 - Wikipedia. But if you go at Help:Citation Style 1, what it says on the page is Help:Citation Style. Another example is Joe Biden can't stop thinking about China and the future of American democracy (and not Joe Biden can't stop thinking about China and the future of American democracy - CNNPolitics. Headbomb {t · c · p · b} 16:25, 29 April 2021 (UTC)

For your New York Times example, I would use: "F.B.I. Searches Giuliani's Home and Office, Seizing Phones and Computers" because that is what readers will see first. For me, the text from <title> in the browser tab is only peripherally visible and, if I bother to look at it, is: '[favicon] Rudy Giuliani's Arartm' where the trailing 'm' fades away to nothing. The two titles don't match. It seems to me that <title> titles are convenient shorthand for web-editors and not meant to be the definitive article title.

Alas, I think that a lot of new instances of cs1|2 templates are created by automated/semiautomated tools (especially for {{cite web}}). Of late, I have noticed many many |title= values that look a lot like your 50 Cent example. That is just wrong. The website does not belong in |title=. Most of these seem to come from visual editor and tools like ReFill which means that they come from citoid. Scraping web pages for citation data is convenient but requires that the data are checked. It seems that this last step is all too often omitted. I cannot count the number of citoid-based cs1|2 templates that I have fixed.

—Trappist the monk (talk) 16:35, 29 April 2021 (UTC)

You are not required to use the content of the <title> element. Should you? If you must. By which I mean, if you don't know either the title of the webpage or the title of the website, the <title> can be a convenient location to find or verify that information. Izno (talk) 17:17, 29 April 2021 (UTC)

Ideally, both the metadata (HTML tag) and the data it describes (the content "title") should be the same.I believe the main reason they are not (apart for the extraneous stuff) is because different people are in charge of the content and the content's html representation. The tag being set, content editors change stuff without notifying html editors. Since most search facilities no longer distinguish between content and metadata by default, the page will be found either way. Compare with a print journal that shows an article title in the metadata (the TOC) that differs from the article title in the body. You will still find the article because the index field is the page number, but something is not exactly right. Back to the web, one could make the case that the HTML tag is what the "printer" (the HTML editor) "typesets" on the page, and that should be the correct title. Practically, I don't think it makes much difference. Use either. 69.94.56.76 (talk) 19:52, 29 April 2021 (UTC)

In some cases it does matter. For example, the World Spider Catalog, a major source for spider articles, has the same text in the title tag for all species, genera, family, etc. pages, making it useless as a citation title. Since we cite web pages for their content, not their HTML, it's the content title, often in the H1 tag, that matters when the two differ. Peter coxhead (talk) 20:02, 29 April 2021 (UTC)

You are right. This takes it in the direction of website organization, which probably is an issue left alone. People can have strong ideas about what constitutes a heading... So I agree that the content title is probably the suitable one. 69.94.56.76 (talk) 20:12, 29 April 2021 (UTC)

Well, clearly, the World Spider Catalog is a broken website, if only because the <title> element isn't uniquely informative, making it useless. (And it's useless not only for citations, but also because my four browser tabs open to different pages on that site show identical labels, and my browser history gives me no clue. Thanks for nothing.) But 69.94 is right; website organization is a different problem. For the WSC site, I would probably resort to the individual page content heading, if I noticed that the site was so messed up. — JohnFromPinckney (talk) 00:44, 30 April 2021 (UTC)

Sure, 69.94, it's probably true that web admin and content manager are different, and don't always communicate their changes well. In theory at least, the difference is supposed to be that "The document's title is often different from its first heading, since the first heading does not have to stand alone when taken out of context." That doesn't seem to be what's going on in my NY Times example, though. — JohnFromPinckney (talk) 00:44, 30 April 2021 (UTC)

|pmc-embargo-date= validation

PMC 7754939 is embargoed until 2023-01-01 but cs1|2 thinks that that date is invalid because it is more than one year into the future. Fixed that by extending |pmc-embargo-date= validation to this year + 2 years:

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|pmc-embargo-date=January 1, 2023|pmc=7754939|title=Title}}
Live	"Title". Journal. PMC 7754939.{{cite journal}}: CS1 maint: PMC embargo expired (link)
Sandbox	"Title". Journal. PMC 7754939.{{cite journal}}: CS1 maint: PMC embargo expired (link)

Changing the date to a 2024 date renders an error:

{{cite journal/new |title=Title |journal=Journal |pmc=7754939 |pmc-embargo-date=January 1, 2024}}

"Title". Journal. PMC 7754939.{{cite journal}}: CS1 maint: PMC embargo expired (link)

Changing the date to a 2021 date adds the article to ‹The template Category link is being considered for merging.› Category:CS1 maint: PMC embargo expired with maint message as before:

{{cite journal/new |title=Title |journal=Journal |pmc=7754939 |pmc-embargo-date=January 1, 2021}}

"Title". Journal. PMC 7754939.{{cite journal}}: CS1 maint: PMC embargo expired (link)

—Trappist the monk (talk) 14:48, 30 April 2021 (UTC)

property category names standardization

Not all that long ago we standardized the error and maintenance category names (see Help talk:Citation Style 1/Archive 71 § error category names standardization). We did not standardize the names of properties categories.

At the moment there are two forms of properties cat names: 'CS1 <descriptor>' and 'CS1: <descriptor>'. Which is the preferred form? Or, is a different form desirable, perhaps: 'CS1 prop: <descriptor>'?

For me, the least amount of work is to drop the colon because none of the subcategories (all associated with languages) use a colon in their names.

—Trappist the monk (talk) 18:40, 2 May 2021 (UTC)

It looks like dropping the colon is the easiest option for achieving localized consistency. My retentive side is a little bothered that all of the "CS1 errors:" and "CS1 maint:" cats have a prefix and a colon and the properties do not, but let's do the easy, consistent thing now and think for a while about whether "CS1 prop:" is the right thing to do for all properties cats. – Jonesey95 (talk) 19:06, 2 May 2021 (UTC)

highlighting cs1|2 citations that emit properties categories

We have a some supposedly 'temporary' prop cats ‹The template Category link is being considered for merging.› Category:CS1 location test, ‹The template Category link is being considered for merging.› Category:CS1: long volume value‎, ‹The template Category link is being considered for merging.› Category:CS1: Julian–Gregorian uncertainty‎, and ‹The template Category link is being considered for merging.› Category:CS1: abbreviated year range‎ that we created so that those who were interested could do something with the information that these categories represent. I don't know that anyone has actually done anything with this information. Part of the reason for that may be that it is not possible to look at a rendered article and see at a glance, which cs1|2 template is causing the module to add a particular prop cat.

I have hacked a simple test in the sandbox that adds a css class, css-prop, to the citation's <cite> tag when any of the properties cats are added. For example, this template will add Category:CS1: long volume value‎:

{{cite book/new |title=Title |date=May–Jun 2021 |volume = 1: Long volume}}

Title. Vol. 1: Long volume. May–Jun 2021.

If I add this css to my custom css page, the above citation renders with a pale yellow background:

.cs1-prop {background: #FFC;}

Without objection, I shall extend this so that only the prop cat(s) of interest are highlighted. For example, if the interest is in Category:CS1 location test, the editor's css might be:

.cs1-prop-location-test {background: #FFC;}

Opinions?

—Trappist the monk (talk) 18:40, 2 May 2021 (UTC)

I support the tagging of all non-language, non-script "tracking properties" cats with .cs1-prop so that people can make property messages visible. Is there a reason to turn the whole citation yellow instead of rendering a green message like the other cats do? I don't think additional class specificity is needed. – Jonesey95 (talk) 19:09, 2 May 2021 (UTC)

Because there are those who complain about such things. For example, you can search for 'CS1 maint: extra text: authors list' and get 26k results even when you don't have the maint-message css to show them. Those messages show up in the, apparently antiquated, WP:POPUPS, for example.

Adding a class to the <cite> tag is simple and unobtrusive. No doubt, clever editors can do other css tricks with the class as they see fit. I'm good with simple background highlighting. And the color doesn't have to be yellow ...

—Trappist the monk (talk) 19:25, 2 May 2021 (UTC)

I don't see a need for the general class if we should intend to add the specific class. Someone interested in all of them can just as easily add the 3 extra lines to their CSS to highlight them. Izno (talk) 19:40, 2 May 2021 (UTC)

I did not intend css-prop to remain; it was only the example that I created to test the concept and is now gone. These are all of the classes available to editors in the sandbox:

cs1-prop-foreign-lang-source – subcategories of ‹The template Category link is being considered for merging.› Category:CS1 foreign language sources

cs1-prop-foreign-lang-source-2 – ‹The template Category link is being considered for merging.› Category:CS1 foreign language sources (ISO 639-2)

cs1-prop-jul-greg-uncertainty – ‹The template Category link is being considered for merging.› Category:CS1: Julian–Gregorian uncertainty

cs1-prop-location-test – ‹The template Category link is being considered for merging.› Category:CS1 location test‎

cs1-prop-long-vol – ‹The template Category link is being considered for merging.› Category:CS1: long volume value

cs1-prop-script – subcategories of ‹The template Category link is being considered for merging.› Category:CS1 uses foreign language script‎

cs1-prop-tracked-param – subcategories of ‹The template Category link is being considered for merging.› Category:CS1 tracked parameters

cs1-prop-year-range-abbreviated – ‹The template Category link is being considered for merging.› Category:CS1: abbreviated year range‎

—Trappist the monk (talk) 21:52, 2 May 2021 (UTC)

All of that makes sense to me. I have set my background to "lightgreen", and it looks pretty nice. – Jonesey95 (talk) 01:21, 3 May 2021 (UTC)

i18n tweaks

As a result of discussion at my talk page, I have made some i18n changes that are mostly related to date validation. These changes are:

• elimination of the special case testing of 'May' when making sure that date ranges that include months use consistent style: 'Jun–July' not ok. It used to be that the module relied on month-name length but that doesn't work for some non-English languages.
• The module suite can, when properly configured, translate English month names to a local language's month names. It used to be that this functionality required editors at the local wiki to uncomment certain code in Module:Citation/CS1. I have changed that so that editors at the local wiki only need to set a configuration variable to true to enable the functionality. I have also added a maintenance category that is emitted when the module auto-translates a month name.

—Trappist the monk (talk) 15:48, 3 May 2021 (UTC)

css classes going away

From Tech News: 2021-18:

Future changes

• The CSS classes .error, .warning and .success do not work for mobile readers if they have not been specifically defined on your wiki. From June they will not work for desktop readers. This can affect gadgets and templates. The classes can be defined in MediaWiki:Common.css or template styles instead. [5]

Of these, cs1|2 uses only .error.

—Trappist the monk (talk) 16:10, 3 May 2021 (UTC)

I left a note at the VPT version that error is unlikely to change, but users are welcome to review the Phabricator task. Izno (talk) 16:24, 3 May 2021 (UTC)

The removal of those classes aside, I've been thinking I want to remove our reliance on it anyway. We have more specific classes today that only use the red color because we reset the font-size to 100% in TemplateStyles. I'm somewhat doubtful anyone has gadgets to find "error" in our context. Should be done in the sandbox now: T. {{cite book}}: Explicit use of et al. in: |author= (help)CS1 maint: ref duplicates default (link) Izno (talk) 17:32, 3 May 2021 (UTC)

That change causes all test cases that render error messages to fail in Module talk:Citation/CS1/testcases, Module talk:Citation/CS1/testcases/errors, Module talk:Citation/CS1/testcases/dates, and Module talk:Citation/CS1/testcases/identifiers. These test cases fail because the class= attribute in the citation's <cite> tag in the actual (sandbox) column renderings do not have the error class.

I was initially perplexed because immediately after the change to Module:Citation/CS1/sandbox/styles.css, the failed citations in the testcases pages did not display colored error messages. The reason for that was that Module:UnitTests replaces the actual (sandbox) templatestyles stripmarker with the stripmarker from the expected (live) rendering. The expected (live) stripmarker refers to Module:Citation/CS1/styles.css (the live css) which does not have coloring. The expected (live) rendering gets its error message coloring from the error class. Because the actual (sandbox) rendering does not have the error class, and the expected (live) rendering templatestyles css doesn't provide coloring, the actual (sandbox) error messages were not colored.

The manipulation of the templatestyles stripmarkers is done because stripmarkers are always unique so any comparison of rendering with stripmarkers will fail because the live and sandbox stripmarkers are not the same. To get around that, Module:UnitTests replaces the actual (sandbox) stripmarker with the stripmarker from the expected (live) rendering. I have tweaked Module:UnitTests so that the comparison of the expected (live) and actual (sandbox) renderings use the expected (live) rendering's stripmarker but, for the renderings used in the results table, each rendering uses its own stripmarker.

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

Something something integration tests instead of unit tests something something ;). Izno (talk) 23:03, 3 May 2021 (UTC)

Citation template for medRxiv preprints

I think it may be beneficial to have Template:Cite medRxiv, which could be modeled after Template:Cite bioRxiv. Currently, medRxiv preprints seem to be put into a Cite journal template, which often results in the article the template is used on being put in "Category:CS1 errors: missing periodical", or in a Cite web or Cite report template, which seem clumsy since a dedicated Cite medRxiv would make more sense. Velayinosu (talk) 02:22, 4 May 2021 (UTC)

Really we should have one {{cite preprint}} as a meta template that can handle them all. Headbomb {t · c · p · b} 02:58, 4 May 2021 (UTC)

It is an interesting idea, but why meta-template? Could a base template be a better idea instead, perhaps with a single switch-parameter such as the "work" being any of |[preprint|arxiv|biorxiv|medrxiv|ssrn]= etc. Of course such rendition may or may not necessitate a disambiguated |class= parameter which you don't favor. If there are diverse parameter sets among the various preprint services then imo a meta-template would be a better fit conceptually. But in such cases things tend to become complicated for editors. 184.75.108.82 (talk) 23:36, 4 May 2021 (UTC)

Solving "CS1 errors: missing periodical" for scientific protocols with doi but no journal

Hi all, this may be slightly related to the medRxiv topic above. Any advice on solving the "missing periodical" error for references to protocols.io protocols such as this in the CUT&RUN sequencing article which were presumably cited using cite journal as they have a doi, but don't have an associated journal? I see cite doi is deprecated in favour of cite journal; cite web doesn't seem quite right though. There's four such references in that article and the cleanup listing for the Computational Biology taskforce suggests 45 articles with the same CS1 error - any thoughts on how best to address this? Thanks! Amkilpatrick (talk) 15:29, 4 May 2021 (UTC)

It looks like this web site hosts pages that are not journal articles. I would use cite web, like this: Janssens, Derek; Henikoff, Steven. "CUT&RUN: Targeted in situ genome-wide profiling with high efficiency for low cell numbers v3 (protocols.io.zcpf2vn)". protocols.io. doi:10.17504/protocols.io.zcpf2vn.. – Jonesey95 (talk) 15:49, 4 May 2021 (UTC)

Great thanks, that would work - I'd missed the doi parameter in cite web. Cheers, Amkilpatrick (talk) 17:17, 4 May 2021 (UTC)

Do explanatory footnotes go before or after references?

Moved to Wikipedia talk:Manual of Style § Do explanatory footnotes go before or after references?

 – {{u|Sdkb}} ^talk 22:21, 6 May 2021 (UTC)

Conference chairman

There is no documented |chair= or |chairman= parameter for {{cite conference}}. Should the chairman be shown as an editor, or not shown at all? Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:50, 5 May 2021 (UTC)

They shouldn't be mentioned, no. Headbomb {t · c · p · b} 12:17, 5 May 2021 (UTC)

CC licensing parameter

I'm using a source whose copyright page says, "Please cite the work as follows: Energy Sector Management Assistance Program (ESMAP). 2020. The State of Access to Modern Energy Cooking Services. Washington, DC: World Bank. License: Creative Commons Attribution CC BY 3.0 IGO". I know we don't *have* to include the "CC BY 3.0 IGO" in the citation, but it would be nice to. Is there a way to include it? Clayoquot (talk | contribs) 18:53, 8 May 2021 (UTC)

cs1|2 does not support licensing annotation. If you believe that it is necessary then you can include the annotation after the the closing }} of the cs1|2 template.

—Trappist the monk (talk) 18:59, 8 May 2021 (UTC)

(edit conflict) Not in the templates. You can always append free-form text after any citation template within the footnote. There are similar requests to add licensing to the citation templates, and those requests are rejected because the license doesn't help a reader find the source to verify the cited information, which is the purpose of a citation. Imzadi 1979 → 19:00, 8 May 2021 (UTC)

Thanks for your quick responses :) Clayoquot (talk | contribs) 19:18, 8 May 2021 (UTC)

limited_basic_arguments

In Module:Citation/CS1/Whitelist the limited_basic_arguments{} table includes url and URL. The limited_basic_arguments{} is used only by the preprint template {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}} none of which need |url= because they are identifier specific templates. I have removed url and URL from the sandbox version of limited_basic_arguments{}.

—Trappist the monk (talk) 19:05, 8 May 2021 (UTC)

Why does df exist?

I'm not sure why |df= exists anymore, given that {{Use dmy dates}} and {{Use mdy dates}} both have date-formatting capabilities for CS1 templates and date formats are supposed to be consistent throughout a given article per MOS:DATEFORMAT. Should we remove it? -BRAINULATOR9 (TALK) 20:00, 8 May 2021 (UTC)

Some wikis don't have those templates, and even our wiki doesn't use them on all pages. Izno (talk) 20:02, 8 May 2021 (UTC)

There might be some reason for it that is explained by the foolishness at MOS:DATEUNIFY, but my brain is too tired to try to re-parse that nest of madness right now. – Jonesey95 (talk) 01:54, 9 May 2021 (UTC)

??? I thought that this short section was relatively straightforward compared to to the overall convoluted MOS:NUM guideline. The only omission of the section imo is the absence of guidance regarding dates in sections other than the body and citations, including in items such as infoboxes etc. 98.0.246.242 (talk) 22:28, 9 May 2021 (UTC)

ssrn

Editor Nemo bis made this edit which is more or less pointless because identifier access is by default paywalled unless explicitly set to free. The Editor did add a comment in the code: 'often free to read, but rate limited and may require subscription'. I do not know how true that statement is so invite Editor Nemo bis to discuss that change here.

—Trappist the monk (talk) 14:24, 9 May 2021 (UTC)

I've removed the default option, since it access varies. SSRN started hosting pay-to-read articles, despite it being clearly against their stated mission. Headbomb {t · c · p · b} 16:09, 9 May 2021 (UTC)

But in addition to that, you need to login in order to be able to actually be able to download the supposedly open things. If you're logged out, you're subject to restrictions à la metered paywall, where the second PDF you download in a day will require you to login or things like that.

Changing the default access level is not "pointless". It's useful for people to be able to navigate the identifiers and links we provide in citations, which is the entire point of having them in the first place. Having the grey icon next to one identifier and the green icon next to another makes it easier to reach the full text without having to open a dozen tabs for each citations and without having to study the purpose and access model of each target website.

Nemo 17:18, 9 May 2021 (UTC)

"You need to login in order to be able to actually be able to download the supposedly open things", again, not for most papers. Most papers are free, and don't require login. Some might require registration. Others might require you to pay. Headbomb {t · c · p · b} 18:04, 9 May 2021 (UTC)