Help talk:Citation Style 1/Archive 76

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

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.

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)

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,^[1] and another uncommon term.^[2]

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,^[1] and another uncommon term.^[2]

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

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

This would help track cases like this [1]

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)

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)

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

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)

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)

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)

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)

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

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)

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)

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 Category:CS1 maint: ref=harv to an error category 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 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 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-0000006F-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%2FArchive+76" 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-00000073-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%2FArchive+76" class="Z3988"></span>

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

'"`UNIQ--templatestyles-00000077-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%2FArchive+76" 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-0000007B-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%2FArchive+76" 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-0000007F-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%2FArchive+76" class="Z3988"></span>

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

'"`UNIQ--templatestyles-00000083-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%2FArchive+76" 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 Category:CS1 maint: ref=harv while the sandbox emits and error message and categorizes the article into 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)

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)

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)

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.[2] —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)

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:

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

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)

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)

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)

We have a some supposedly 'temporary' prop cats Category:CS1 location test, Category:CS1: long volume value, Category:CS1: Julian–Gregorian uncertainty, and 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 Category:CS1 foreign language sources

cs1-prop-foreign-lang-source-2 – Category:CS1 foreign language sources (ISO 639-2)

cs1-prop-jul-greg-uncertainty – Category:CS1: Julian–Gregorian uncertainty

cs1-prop-location-test – Category:CS1 location test

cs1-prop-long-vol – Category:CS1: long volume value

cs1-prop-script – subcategories of Category:CS1 uses foreign language script

cs1-prop-tracked-param – subcategories of Category:CS1 tracked parameters

cs1-prop-year-range-abbreviated – 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)

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)

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. [3]

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)

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)

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)

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)

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

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

The PMID upper bound check needs to be revised.^[1]

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)

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)

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)

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)

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 Category:CS1 maint: developer-discouraged parameter or something similar
3. Create a hidden maintenance message, e.g. "developer-discouraged parameter |accessdate= (help)" or "developer-discouraged parameter |accessdate= used (|access-date= suggested) (help)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Maint version:

{{cite book/new |title=Title |url=//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)

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)

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 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 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 Category:CS1 properties: unhyphenated multiword parameter or 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 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 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: Category:CS1 nonstandard parameters: accessdate, 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 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 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)

 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)

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 Category:Album chart usages or just about anything else in 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)

Oppose the creation of any tracking cats without a good reason why something needs to be tracked (e.g., why would you create a tracking category for these parameters, and not for others?). Tracking for the sake of tracking is adding clutter and overhead to way too many articles, and making the hidden categories even less usable than they are now (they used to be a handy place to track some maintenance categories, now they are the dumping ground for anything that ticjles the fancy of some template editor, without much thought to how it eventually improves the articles). Templates are a tool, not a goal in themselves, and the generation of tracking categories in articles should be intended to improve the articles, not to check something related to a template for the sake of the template editors. Fram (talk) 15:39, 11 May 2021 (UTC)

So does this mean that you support the proposal as written? Any such tracking category created based on this proposal on how to name parameter tracking categories would have a good reason for its creation, discussed on this page. We currently track the use |authors=, for example, because the values contained within it do not populate metadata. I have added bolding to the actual proposal above. Please respond to what the proposal actually says, not what you think it might say or mean. – Jonesey95 (talk) 01:49, 12 May 2021 (UTC)

No, strangely, my oppose doesn't mean "support". No good reason for this category has been given. Please, after this discussion closes and the cat is finally deleted, don't create such a widely present cat without a VPPR discussion (feel free to remove any such cats, of which there are way too many (from many templates, I don't mean that this template is the main or only cause of this). Making hidden cats as a maintenance tool nearly useless, for the sake of a few people who like to "track" stuff (whether it is this, or tracking all pages where the Wikidata description is the bloody same as our description), is annoying; and template talk pages are not the right place to check whether something which will appear on, say, more than 100,000 pages, actually has consensus. So, reaffirm oppose. Fram (talk) 07:18, 12 May 2021 (UTC)

Oppose per Fram. The community's view on this matter should be crystal clear by now, and even the mere tracking of unhyphenated parameters means we're using category space to treat them as "different" from their hyphenated counterparts. If you really want to "track" such parameters, write an off-wiki script to do so.  — Amakuru (talk) 15:43, 11 May 2021 (UTC)

Oppose any action that would treat unhyphenated parameter names differently from hyphenated parameter names. My objection would be moot if the proposal were to create separate but equal and neutrally-named tracking categories for both hyphenated parameter names and unhyphenated parameter names, e.g. "hyphenated CS1 parameter name" and "unhyphenated CS1 parameter name". —David Eppstein (talk) 00:16, 12 May 2021 (UTC)

So does this mean that you support the proposal? The category names proposed do not mention specific parameter characteristics. I have added bolding to the actual proposal above. Please respond to what the proposal actually says, not what you think it might say or mean. – Jonesey95 (talk) 01:49, 12 May 2021 (UTC)

It's hard to tell. Are you proposing that, whenever an unhyphenated parameter name is declared to be a parameter of interest, we also declare the corresponding hyphenated name to be a parameter of interest? I see no such text in your proposal. Without such a condition, I still oppose. —David Eppstein (talk) 05:19, 12 May 2021 (UTC)

Please re-read the bold proposal text above. There is nothing about hyphenation there. – Jonesey95 (talk) 17:15, 12 May 2021 (UTC)

Correct. It is a blank check for the developers of the citation templates to declare any specific parameter to be "of interest" and to introduce a tracking parameter for it, introduced in a context where they previously tried to use this mechanism to deprecate unhyphenated tracking parameters out-of-process, and without safeguards to prevent them from doing it again (such as a requirement that when unhyphenated parameters are listed, the corresponding hyphenated ones must also be listed). As such, I still oppose. —David Eppstein (talk) 18:12, 12 May 2021 (UTC)

Oppose, since the rationale remains unclear. Nikkimaria (talk) 01:03, 12 May 2021 (UTC)

Of course I'm in favor of neutrally named error, maintenance, and properties categories.

Recently, I've been thinking about |authors= (a – gasp! – discouraged parameter) and its aliases |people= and |credits=. We need to find a solution to these parameters because whatever value is assigned to them never makes it into the citation's metadata. |people= and |credits= are used primarily for the {{cite episode}} and {{cite AV media}} templates (but can be used in any). It would be nice to track those two parameters so that we have some simple way of discovering how and where they are used so that we can devise some sort of solution to this problem.

I've also been thinking about |lay-date=, |lay-format=, |lay-source=, and |lay-url=. These are a crude attempt to shoehorn a second source into cs1|2 templates that are designed to cite a single source. The lay parameters provide incomplete bibliographic information about the lay source; none of that information is included in the citation's metadata. Better, I think, to do away with the lay parameters entirely and, if the lay source is really necessary to the articles where the lay parameters have been used, cite the lay source properly with the appropriate cs1|2 template. Tracking these parameters would be helpful in assessing the magnitude of the issue.

—Trappist the monk (talk) 13:54, 12 May 2021 (UTC)

We need to find a solution to these parameters because whatever value is assigned to them never makes it into the citation's metadata.

That's easy. Whoever is maintaining the metadata should add an "authors" field. You know, meta-data, ie derivative data that refers to source data. The dependency is one-way, and has nothing to do with these modules. Metadata should adjust to data, not the other way around. 65.204.10.232 (talk) 16:31, 12 May 2021 (UTC)

Although I'm unsure of the validity of my !vote here, I currently offer weak support for the idea of being able to track usages for analysis purposes. I take it this means that each and every parameter used with CS1|2 templates would (automatically) generate a categorisation, whether it was once or ever will be "of interest". Yes? That's a large addition, but Fram's arguments that tracking cats are already unusable haven't persuaded me to oppose; perhaps I lack experience in working with such things (although a decade ago I was involved with {{single chart}} support). It still seems like a useful idea to me. — JohnFromPinckney (talk) 19:18, 12 May 2021 (UTC)

I would certainly oppose using tracking categories for all citation template parameters. Currently, it can be useful to set one's preferences to make tracking categories visible, because often they give a quick indication of the presence of problems needing fixing (like citation needed tags) that could be harder to spot if one had to scan the whole article text to find them. Making most articles include dozens of useless tracking categories would be a quick way to break that functionality by hiding the meaningful tracking categories among a huge load of chaff. —David Eppstein (talk) 19:28, 12 May 2021 (UTC)

(edit conflict)

I would oppose having a category for every cs1|2 parameter (there are more than 200 individual parameters – too many, really) and I don't think that a category for every parameter is what Editor Jonesey95 has in mind. I can't think of a reason for that kind of chicken-in-every-pot kind of shotgun approach to categorization. Just because Editor Fram may not find error/maintenance/property categories useful does not mean that these categories are useless to everyone else. All of the categories linked from cs1|2 templates are hidden so readers never see them and editors who find them to be useless may hide them by unchecking the 'Show hidden categories' checkbox near the bottom of Special:Preferences → Appearance.

—Trappist the monk (talk) 19:39, 12 May 2021 (UTC)

Not what I said. Tracking categories make hidden cats less useful, as they bury the actual error and maintenance cats. I never claimed that error and maintenance cats aren´t useful. Fram (talk) 21:00, 12 May 2021 (UTC)

Exactly right. Where there is a genuine reason to avoid some particular parameter, because its use impacts on readers' ability to locate the source in question then having a discreet hidden category, which people like David can make visible at their discretion to help them spot and fix such things, is clearly useful. Adding "tracking" categories on top of that, for parameters that don't generate any problems at all on the formatted page, muddies the water and makes editors' life harder. And with absolutely no benefit identified to either article creators or readers in having those categories. Even for those whose specialism is citation templates, the only stated benefit of tracking seems to be so they can study and count them and then take no further action based on their findings. There really is no value to that exercise that justifies the burden it places on the project, I'm afraid.  — Amakuru (talk) 09:36, 13 May 2021 (UTC)

What burden does it place on the project? Software writers often employ tracking for a myriad purposes: for usability issues, for performance issues, for troubleshooting, for code effectiveness and a thousand other reasons. Such tracking can last hours, can be perpetually renewed until results are obvious, or it can be recurring at intervals. There is no facility in Wikipedia to test modules in real world simulations or do beta testing. Unfortunately this must happen on the live module. The bureaucratic requirements may slow development or produce more buggy code. That will be visible to readers, unlike the maintenance routines. 50.74.165.202 (talk) 14:08, 13 May 2021 (UTC)

(edit conflict)

If I understand what you wrote, you seem to be suggesting that the goal of the proposal is to have a category for every cs1|2 parameter. I don't think that is the correct interpretation of the proposal. Unless you know differently, there is no better way to know where and how an individual cs1|2 parameter is used than to track it with a hidden property category (if you do know of a better way, please tell us what that is). For the maintainers of the cs1|2 templates and infrastructures, quality data are important. Without quality data, good decisions cannot be made. Preventing cs1|2 maintainers from tracking parameter usage, as opposers here seem intent on doing, deprives the cs1|2 maintainers of the only method we have for gathering complete and accurate data. Incomplete and/or inaccurate data, of course, tends to produce less than optimal results. Remember, tracking every single one of the 200+ cs1|2 parameters is not the goal of this proposal. The goal here is to define a mechanism by which accurate and complete tracking of individual parameters may be accomplished as the need arises; no need to track that parameter, no category; it is just that simple.

—Trappist the monk (talk) 14:17, 13 May 2021 (UTC)

I would suggest to have this discussion, about a tracking cat on more than 1 million pages, not here, but on a larger forum, e.g. a village pump. Previous discussions have already shown that the consensus here is not representative of the consensus among the wider editing community: while the category is generated by this template, it appears on countless articles, and is clearly controversial. Deciding this here is not the best way to proceed. Fram (talk) 15:39, 11 May 2021 (UTC)

By all means initiate such a discussion about maintenance categories in general, at the largest possible forum with the largest number of participants. Once a policy, or at least specific guidelines for such categories are in place, I believe they will be readily complied with. Until then, per the current state of affairs, category creators/maintainers are under no obligation to follow the directive or whims of any drop-in editor on the subject. And it is not their fault, I think, that more editors who are knowledgeable on the subject or are open to it are not joining the discussions here. 65.204.10.231 (talk) 20:18, 11 May 2021 (UTC)

A request: before you submit a prospective policy/guideline about the creation, use, and deletion of maintenance categories at VP or anywhere appropriate, please bring here for a non-binding discussion. Not because your proposal must be "vetted" here in any way. In order to collect input from users of such categories so that the proposal is more rounded. 50.74.165.202 (talk) 14:04, 12 May 2021 (UTC)