Help talk:Citation Style 1/Archive 76

This is an archive of past discussions. 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.

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

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

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

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

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

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.

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:math/0207028
3. |class= is unset

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

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.

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:

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

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:

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

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)

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

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

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

dgaf

)  14:04, 13 April 2021 (UTC)

Fixed. The ultimate arbiter here is

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

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

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

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

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

map-bms – {{#language:map-bms|en}} → Basa Banyumasan but map is

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.

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

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

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

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

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

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

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)

{{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 ssrn}}) but matching suggestions (as patterns or individual rules); discussion
• Add parameter name to err_extra_text_pages message
• Add err_asintld_missing_asin, err_doibroken_missing_doi, err_embargo_missing_pmc error messages for missing |asin= / |doi= / |pmc= parameters; discussion
• Refactor style and ref functions
• Emit maintenance message when the value of |ref= equals the default value; discussion
• Emit maintenance message when |postscript= is longer than one character; discussion
• i18n support for year/date mismatch; discussion
• separate {{cite AV media}} / {{cite AV media notes}} |others= maintenance cat from other template's |others= maintenance cat; discussion
• revert "helpful" dash conversion; discussion
• revise |display-<names>= error messaging; [[Help talk:Citation Style 1/Archive 75#Bug in cfg.special case translation [list name]|discussion]]
• add position to Vancouver errors; discussion
• support edtf uncertain date format; discussion

Module:Citation/CS1/Configuration

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

Module:Citation/CS1/Whitelist

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

Module:Citation/CS1/Date validation

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

Module:Citation/CS1/Identifiers

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

Module:Citation/CS1/COinS

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

Module:Citation/CS1/Suggestions

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

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

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

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

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

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

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

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

... Additional wikitext clutter can be removed is sufficient to be a necessary and beneficial change. One of the discussion points since forever is that citations clutter wikitext. This change removes one point of clutter. I have not been reverted where I have removed |ref=default_value. My speculation is that the people using |ref=default_value (either hardcoded or with {{

sfnref

}}) either wrote the articles prior to |ref=harv or did not know about |ref=harv or do not know that neither |ref=default_value nor |ref=harv are necessary any more. I see all three as far more likely than editors deliberately adding these just to meet one or another of MP's speculations as stated in that discussion.

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

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

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

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

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

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

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

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

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

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

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

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

Re the default for |ref=. This was set to |ref=harv, as in the author-date short reference scheme. The module programmatically offers a target for select short-reference anchors such as those generated by {{

harv}} (by mapping the author and date parameters accordingly). That would make something like |ref=harv or similar redundant. Or that is what I think this means, anyway. 98.0.246.242 (talk

) 01:45, 4 April 2021 (UTC)

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

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

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

Follow-up to module updates

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

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

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

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

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

We might change that to:

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

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

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

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

|series-no= restored.

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

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

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

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.

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.

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.

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)