Help talk:Citation Style 1/Archive 71

Possible scheme to mark parameter values for review

 * As a sidenote from the thread above, I like J. Johnson's idea of a "badauthor" parameter alias in the linked thread. In fact, I was thinking about something similar myself some while ago:

The prefix would have to be worded more neutrally like debug-*, check-*, recheck-*, TEMP-*,  ("minus"),   ("uncertain"),   ("question mark") or similar, and the prefix should be applicable to all template parameters in general, like Radcliffe, 0367-9950 or 29 February 1866.

If an editor runs into a parameter value that appears to be incorrect and that should be double-checked, but cannot be verified immediately, the editor would just add the prefix to mark it for future review. Once this or another editor has checked a parameter flagged this way, s/he would correct the value if necessary and/or simply remove the prefix again.

The template could populate a special maintenance category for this, but otherwise these aliases would be treated exactly as their canonical forms, including error checking. This way, this feature could be coded as a general exception to the normal parameter evaluation and therefore without overhead and it could be documented in a single place like our ((accept-this-as-it-is)) syntax, without having to list it as an alias everywhere.

An alternative to this are HTML comments, but they are not machine-readable and wouldn't cause the citation to show up in a maintenance category.

The system could be extended to bot edits as well in two ways:

Bots running into entries they find fishy but cannot resolve reliably (that is, with 100% accuracy) could instead mark the parameter with the prefix and leave it to humans to actually check and possibly correct it, instead of applying guesswork themselves. This would extend the model of a bot/tool assisting a specific user synchronously to assisting all possible editors, and asynchronously, without causing harm in case of problems.

Also, bots and similar tools could be asked to flag all entries where they changed values with, and prefix all parameters where they added information with   (or at least those where potentially inaccurate info was added - this should never happen in the first place, but we all know that in reality it happens quite often at least with some bots/tools). Parameters prefixed with  would be ignored by the citation template, except for, perhaps, populating a maintenance category, and, possibly, show up in preview already (but framed somehow). Editors working on the article and improving citations would simply have to remove the prefixes after reviewing them.

Thereby, it would be much easier for humans to identify bot edits for review (also long after the fact when it might no longer be listed among the recent edits in the edit history) and to double-check some additions before they go live. It would take some time for this new process to trickle through, but since it's technically optional the transition would be smooth and the situation would gradually improve with each new bot/tool adopting it.

IMO, this could solve many problems with Citation Bot and similar overambitious tools by allowing them to make suggestions instead of actually carrying out the edits and often messing up citations. Even if the concept would not be adopted community-wide, it could still be used by those who decide to use it.

For readers, the  idea would have no visible impact at all, whereas   prefixed information would only become visible with some delay. But for anyone looking at the source code (or preview), the scheme would be completely transparent.

I see this as kind of an informal but formalized and thus machine-readable light-weight communication and process model which can be voluntarily adopted by anyone to ease the normal communication and ad-hoc citation improvement process among human editors and bots (instead of leaving HTML comments, having to discuss temporary details on talk pages, or fighting against each other).

--Matthiaspaul (talk) 14:39, 3 September 2020 (UTC)

Further extending the notation of using  (or   or  ) prefixes, it would also be possible to mark parameter values, which have been verified by humans already, with a   (or even a  ) prefix. At the same time this could be used as a flag to tell bots to leave a particular parameter alone, like Gray. This would hardly be necessary for all given parameters in a template, but could be convenient to have if a known correct value will likely (or has already) trigger(ed) false alarms (like a name including what appears to be a typo but isn't). In contrast to a HTML comment, it would be shorter and machine-readable. As a template-wide "global" feature applicable to all parameters this could be coded with minimal overhead.

If the  prefix would be used for to-be-checked parameter values,   could be conveniently used for bot-added values, or vice versa.

--Matthiaspaul (talk) 20:49, 3 September 2020 (UTC)
 * Following up on this idea, we had a discussion about empty parameters in a (somewhat related) thread about unknown parameters, and it turned out that some users see empty parameters as clutter that should be removed (some don't) whereas others use empty parameters as reminders and hints to point themselves and other editors to some important but still missing information in a citation.
 * I belong to the second group but can also understand the former when a citation contains a lot of empty parameters which have not been placed there deliberately but simply by stuffing some empty default template into an article which was never filled out.
 * I think, my above proposal for template-wide supported parameter prefixes like,   and   could be utilized to solve this dilemma as well:
 * Following the proposal, prefixing a parameter with  would indicate "this parameter value needs to be reviewed" to other editors, so, if, by the same principle, an editor would prefix an empty parameter with   this would mean "Hey, I'm deliberately adding this empty parameter here because this missing information should be part of this citation, therefore please review and possibly add the info if you can". Example: -author. Once an editor adds the missing info, he would remove the parameter prefix again. Example: John Doe.
 * Further spinning this example for illustration purposes, another editor might come around who finds this name suspicious and consequently would set it to John Doe, thereby telling other editors "Hey, this name looks fishy to me and might be a placeholder rather than the correct name, but I can't prove it right now. Please review if you can". Later, another editor would stop by and scrutinize the citation, and if s/he finds that the value is correct as it is, s/he would either remove the prefix again or, if it is likely that the value will stir up questions again, indicate that the value has been verified to be correct John Doe, thereby telling other editors "Yeah, this doesn't look right, but I verified it and this particular author is actually named John Doe. Everything is fine". Something along this line...
 * Now, if this review scheme would be communicated and gradually adopted by more and more editors, we could allow editors and bots to remove all empty parameters which have not been prefixed, because it would be easy for the editor who deliberately added a few empty parameters to prefix them with  in order to avoid their removal.
 * Thereby we could address both scenarios at the same time without causing damage, improve the interaction between editors and bots, making their collaboration more efficient and less stressful, and effectively increase the quality of citations with less communication overhead.
 * --Matthiaspaul (talk) 10:11, 11 September 2020 (UTC)

error category names standardization
I think that all cs1|2 error categories should have consistent naming as we have done for maintenance cats. We have standardized on CS1 errors: &lt;descriptor> as a naming convention. This is a list of existing non-standard error categories, their page counts, and proposed replacements: additions: I don't think that it matters how many articles are listed in a category; if this change is accepted, old cats will depopulate as articles wend their way through the job queue until empty and new cats will populate in the same manner.

Any reasons we shouldn't do this? Better cat descriptors?

—Trappist the monk (talk) 13:33, 12 September 2020 (UTC) 00:49, 14 September 2020 (UTC) (addition) 14:16, 14 September 2020 (UTC) (better name)


 * A minor point re unsupported parameters. This may imply a parameter supported elsewhere in the system, such as the template-specific parameters you discussed above. Unknown parameters may be better described as "unrecognized" (by the system), and would be obviously unsupported. 64.18.9.247 (talk) 20:43, 12 September 2020 (UTC)
 * It is good that you bring this up, I was about to ask the very similar question if these two category naming schemes would serve a purpose or should be harmonized. I was also about to propose to change the non-hyphenated parameter names archiveurl and accessdate to their hyphenated variants in the category names. Therefore, full support.
 * In your list of proposed new names above, one category uses "citation" another "cite", I would prefer both of them using "citation".
 * There are two more category names that might need touches:
 * → Not sure why this includes "original", wouldn't this be better something like or even just ?
 * --Matthiaspaul (talk) 07:50, 13 September 2020 (UTC)
 * suggests that the category is only for those articles that have cs1|2 templates using unfit.  also holds articles that have cs1|2 templates that use usurped.  cs1|2 does not distinguish one from the other as humans do.
 * and suggest that there is a valid parameter/keyword pair unknown; there is not.  The   part of that category name is to suggest that bots using, bot: unknown, are responsible for adding articles to the category.  The primary (only?) bot using this is InternetArchiveBot.
 * and are the only error messages that use 'cite'.  In, 'web cite' is intended as a stand-in for 'cite web' and 'cite podcast', both of which populate this category.   refers to the rendered citation, not to the cs1|2 template – which may not be empty (this from Jinn):
 * —Trappist the monk (talk) 11:16, 13 September 2020 (UTC)
 * Regarding "unfit", I see your point, but then the message refers not to one of the parameters (lowercase ), but to the abbreviation URL (Uniform Resource Locator), hence should be uppercased:
 * Regarding, perhaps it is just me, but to me the current category name is somewhat cryptic. What does "original" mean here specifically? If this is related to the parameter, url-status should be hyphenated. If this is not related to the parameter but to URLs, the abbreviation should be uppercased. (On a different note: Why did we name the value "bot: unknown" rather than just "unknown"?)
 * Regarding "cite" vs. "citation", not sure if using 'web cite' as stand-in for 'cite web' and 'cite podcast' really works (at least the intended association doesn't work for me). Perhaps →
 * --Matthiaspaul (talk) 18:44, 13 September 2020 (UTC)
 * I've added to the list.
 * Yeah, it is a bit cryptic but that is why we have documentation at the category. If the documentation isn't sufficient to decrypt the meaning, then tweak the documentation. When rendered, the url that is replaced by an archive url is the original url:
 * One place to start for the history of  starts at dead-url= keyword.
 * Just about any cs1|2 template can be considered 'web related' if it has a url. This cat is for those templates that require a url.  Perhaps drop the 'web' and say .  This cat also applies to.
 * —Trappist the monk (talk) 00:49, 14 September 2020 (UTC)
 * is straight to the point. Perfect.
 * Thanks for the pointer to the history of bot: unknown. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this  in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed   prefix (like in bot-unknown) or would try to embed this into the more general parameter review scheme proposal (similar to unknown). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with  ), that proposal would have to be adjusted/extended somewhat. Something to think about...
 * --Matthiaspaul (talk) 13:01, 14 September 2020 (UTC)
 * Yeah, it is a bit cryptic but that is why we have documentation at the category. If the documentation isn't sufficient to decrypt the meaning, then tweak the documentation. When rendered, the url that is replaced by an archive url is the original url:
 * One place to start for the history of  starts at dead-url= keyword.
 * Just about any cs1|2 template can be considered 'web related' if it has a url. This cat is for those templates that require a url.  Perhaps drop the 'web' and say .  This cat also applies to.
 * —Trappist the monk (talk) 00:49, 14 September 2020 (UTC)
 * is straight to the point. Perfect.
 * Thanks for the pointer to the history of bot: unknown. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this  in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed   prefix (like in bot-unknown) or would try to embed this into the more general parameter review scheme proposal (similar to unknown). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with  ), that proposal would have to be adjusted/extended somewhat. Something to think about...
 * --Matthiaspaul (talk) 13:01, 14 September 2020 (UTC)
 * Thanks for the pointer to the history of bot: unknown. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this  in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed   prefix (like in bot-unknown) or would try to embed this into the more general parameter review scheme proposal (similar to unknown). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with  ), that proposal would have to be adjusted/extended somewhat. Something to think about...
 * --Matthiaspaul (talk) 13:01, 14 September 2020 (UTC)

Question, isn't "Category:CS1 errors: bare URL" the same error as "Category:CS1 errors: missing title"? Those don't seem to be independent. AFAICT, the first is missing titles when there's a URL, the second is missing titles regardless of if there is a URL. &#32; Headbomb {t · c · p · b} 16:02, 13 September 2020 (UTC)
 * Also "web cite" should be "cite web" or "web citation". &#32; Headbomb {t · c · p · b} 16:03, 13 September 2020 (UTC)
 * collects articles that have cs1|2 templates that have a url-holding parameter without its matching title-holding parameter: chapter-url without chapter:
 * – collects articles that have cs1|2 template that do not have any of title, trans-title, and script-title (no main-title parameter):
 * Should not be 'cite web' because that category also applies to.
 * —Trappist the monk (talk) 18:09, 13 September 2020 (UTC)
 * Should not be 'cite web' because that category also applies to.
 * —Trappist the monk (talk) 18:09, 13 September 2020 (UTC)
 * —Trappist the monk (talk) 18:09, 13 September 2020 (UTC)

Should removed parameters be in the list of suggestions?
Recently, Matthias has added support in the suggestions list to parameters that have been removed, listing a few related discussions but none which directly cite a decision to support parameters that are removed. Is this something we want to do? I am not generally in support of it -- we've removed the parameters from support, so why are we continuing to support them? --Izno (talk) 18:22, 16 September 2020 (UTC)
 * Removed parameters are not supported, AFAICT. We are helping editors fix their errors instead of simply showing an error message. . Or perhaps I misunderstand what is at issue. – Jonesey95 (talk) 19:42, 16 September 2020 (UTC)
 * The suggestions module indeed provides suggestions. By "support" I mean "we have modules that will provide that suggestion when we have chosen deliberately to remove the attributes in question". (I'm sure also that we pay some non-zero price for the suggestions list.) Prior to Matthias's changes, I'd classify the set in this way: misspellings and translations. These additions are not really in keeping with what was in there prior, and I'd like an affirmative agreement that "yes, we want to continue to provide some moderate level of support for these". The point of deprecation and removal is to say "no, we don't want to continue to support these". --Izno (talk) 21:23, 16 September 2020 (UTC)
 * We did this before as well, but perhaps only occasionally (e.g. trans_title).
 * The reason I added the removed parameters to the suggestion list is that despite our efforts to clean them up at least in mainspace, they occasionally show up (again) and I think it is desirable to make the transition as smooth as possible and give editors a hint on the new parameter if there is a replacement (the CS documentation lists recently deprecated parameters, but not older ones, so editors might be clueless running into them - like I was for a moment running into laysummary recently). In some sense, these can be considered "misspellings", but I would also classify them as "former parameters". I think it is important to document their type in the comments (this might be helpful when the current list might need to be turned into a more complex table with various flags in the future). In the case of old parameters, it might even make sense to record the date of deprecation, so this can be reevaluated a couple of years later.
 * I was living under the impression that this part of the code is only executed when the main code has detected an unsupported parameter already, issuing an error message. So, it doesn't affect the performance of well-maintained citations. Also, for cleanness of code it is important to get rid of any traces of former parameters from the main modules, but in the suggestion module, it doesn't harm to keep mentioning them (in fact, I think, it is improving the list if they are mentioned).
 * --Matthiaspaul (talk) 10:07, 17 September 2020 (UTC)

transcript
transcript, transcript-format, transcripturl, and transcript-url are unique to and  I have moved them to the   table in the whitelist sandbox.

—Trappist the monk (talk) 19:02, 11 September 2020 (UTC)


 * Should these be available for cite speech, cite serial, cite podcast, cite interview? --Izno (talk) 19:42, 11 September 2020 (UTC)
 * That could be done. There has been some interest for supporting these parameters in  but that apparently fizzled for who-knows-why.
 * —Trappist the monk (talk) 21:52, 11 September 2020 (UTC)
 * cite serial documentation says it supports transcript-url.
 * Following up on the stupid questions, I wonder why we have so many templates like this. cite av media should cover most of them (and perhaps a new cite online av media to cover cite podcast requirement for a URL, if that really is necessary). (Also also, I know that it will apparently take an act of God to get people to agree that a serial and an episode are actually the same thing.) --Izno (talk) 05:59, 19 September 2020 (UTC)

O wicked wall, through whom I see no bliss!
Pyramus in Shakespeare's A Midsummer Night's Dream Act 5, Scene 1

Yesterday I thought to create a common function to handle accept-as-written markup. There are several places in Module:Citation/CS1/sandbox that detect and strip that markup so starting at the top of the module and working down, I replaced each independent detect-and-strip with a call to the new function, testing as I went. Worked great until I got to  and bam! ran straight into a wall at full speed.

Lua has a built-in, unalterable limit of 60 upvalues. Roughly speaking, an upvalue is anything in a module that has the same scope as the function in question and is directly used by the function. In ~/sandbox, there are some 61 functions that may be used by  (not all of them are directly used). Additionally there are 24 functions held in various other modules (most of them used by ) that count against the upvalue limit.

We have been close to this limit for some time. Since the last update, ~/sandbox has gotten two new functions,  and , and one new table   and dropped the function. At the time that I hit the wall, we were sitting right at an upvalue count of 60.

So, what to do? For the nonce, I have taken the cheap and easy way out. The 24 functions held in various other modules were declared as local names to make life a bit easier so, for example, Module:Citation/CS1/Utilities/sandbox has a very commonly used function. To make that easier to type, the cross-module name  was mapped to a local name. I have changed all of the remapped names to their cross-module names. Doing that reduced the upvalue count by 20 (I believe – not tested). There were 24 functions from four modules so should be 20.

is an enormous beast. It can be reorganized and split into multiple sections which is something that I have wanted to do for a long long time. But it isn't an easy task so I have been putting it off and putting it off ... 'O wicked wall...'

—Trappist the monk (talk) 15:18, 13 September 2020 (UTC)
 * I appreciate your dedication to these modules, Trappist, and I have confidence that these stony limits will not thwart you. With love's light wings did I o'er-perch these walls, for stony limits cannot hold love out. – Jonesey95 (talk) 15:34, 13 September 2020 (UTC)
 * Best wishes of recovery from hitting that wall. ;-)
 * Regarding ((syntax)) detection, it happens that I planned for today to add ((accept-this-as-it-is)) detection code at the beginning of the identifier evaluation code, unconditionally stripping of the parentheses whenever they exist (that is, regardless of identifier parameter) and recording a flag on which the code further down would act in the cases of the identifiers which can make use of it already, like the ISBN and DOI examples. The idea for this was to not introduce the detection and stripping code for each identifier individually in order to avoid unnecessary code repetition.
 * Of course, this could be further generalized by running the ((syntax)) detection and stripping code over all parameters, keep record of the results alongside the parameters for later evaluation in the code dealing with the individual parameters supporting this feature. For all other parameters, the corresponding flag would just be ignored. This works on the assumption that a usage of ((syntax)) in the outside world can be basically ruled out in any context even remotely related to citation-related information, and that it is very unlikely that the ((syntax)) would be applied by a user in a parameter not supporting the feature, but if a user would apply it anyway, the parentheses would silently be stripped off and the template would behave as if they would not have been provided in the first place. This would reduce the number of instances where the detection code would have to be invoked to one (or at most very few places) making it unnecessary to even implement it as a subroutine (except for that it looks nicer).
 * --Matthiaspaul (talk) 20:15, 13 September 2020 (UTC)
 * Regarding accept-as-written markup, I am still under the firm belief that should not be expanded, and I have not seen an active consensus that it should even be in use today (even, TBH, for organizational authors in Vancouver--instead we should support that use case directly as I have mentioned elsewhere). We are not tracking it today (though we should tomorrow for where we do provide it), and I would guess it is hiding some articles best unhidden. --Izno (talk) 06:16, 19 September 2020 (UTC)

Access dates sometimes superfluous
"Access dates are not required for links to published research papers, published books, or news articles with publication dates."

With regard to the last of those, bear in mind that news articles are often revised some time after publication, and the date of revision (along with the reason/s for doing so) will be noted in the text. Additionally, my own experience suggests that even though the content of an article may not be revised, revisiting an article some years after publication can result in the discovery of a very different headline from the one noted in the citation, filled out earlier in the article's existence. Harfarhs (talk) 22:30, 18 September 2020 (UTC)
 * I agree. It's not even remotely uncommon for news articles to be updated, and thus potentially no longer support content in a Wikipedia article. I think we should remove that last part. Glades12 (talk) 05:00, 19 September 2020 (UTC)
 * As stated earlier, such articles in the kinds of sources we trust will almost always provide a revision date. News articles with publication dates indeed do not need access dates. --Izno (talk) 05:03, 19 September 2020 (UTC)
 * That makes no sense, unless you're using  for the date of the last update, which I do not. Glades12 (talk) 05:10, 19 September 2020 (UTC)
 * Why aren't you? :) Just because you aren't, doesn't mean you shouldn't. You don't know what may have changed between the original publication date and the amended date (you should, but you might not), so you should cite the date of the copy you referenced, not an earlier or later date. (Best yet, ensure you always provide an archive URL!) --Izno (talk) 06:11, 19 September 2020 (UTC)
 * Yes, the date that belongs into the date parameter is that of the latest date (of revision) that is known.
 * However, I, too, have seen quite many online magazine and news articles with sometimes vastly differing headlines and no indication of any revision or revision dates. So, the only specified date may be the original publication or a revision date - without knowing the publication history of an article, a normal reader will never know. Quite shockingly, in recent years I have even seen many online articles which carry no date information at all. So, access-date is quite important.
 * --Matthiaspaul (talk) 07:32, 19 September 2020 (UTC)
 * This sentence is one of those "guidelineish" pseudo-advices (I complained about here) that crept into our template documentation, but doesn't belong there (it is not a guideline, and shouldn't be one). I take issue with some editors trying to push their personal preferences this way. access-date is never required, but optional. (In my opinion it is always desirable to have per WP:V, whereas some editors see it as clutter.) Basically, it is up to the editorial judgement of the editor adding a citation if s/he thinks it is useful in a citation or not. Therefore, let's delete that misleading sentence completely. It has no place in a template's documentation.
 * --Matthiaspaul (talk) 07:32, 19 September 2020 (UTC)

Place but no publication place
What should you do when the appropriate value for  (i.e. the place where a source was written (or otherwise created)) is known, but not  ? An example is the video Hirokazu Tanaka on Nintendo Game Music, Reggae and Tetris (used at Hirokazu Tanaka), which was recorded in Tokyo, but could have been published at just about any place with a Red Bull office. Glades12 (talk) 05:33, 19 September 2020 (UTC)
 * Just put it in place like everyone else? The distinction, for all intents and purposes, is nil at this point. (That aside, citing the location matters less and less entirely these days for anything of relevant sort from what I have observed.) (Also, Ttm, weren't we going to look at place/pub-place?) --Izno (talk) 06:15, 19 September 2020 (UTC)
 * I figured that was the best option. Glades12 (talk) 07:16, 19 September 2020 (UTC)
 * A distinction is made when both publication-place and location/place are used at the same time. Then location/place becomes a parameter only for the written-at-place.
 * The names place and location are unfortunate because of their ambiguity. Therefore we should introduce a new dedicated parameter for the written-at-place, like written-place. However, given that place/location can also be used to specify the publication place for as long as publication-place is not present, and some editors have a very bad habit of changing publication-place to place, existing entries of place/location cannot be automatically converted into written-place (nor publication-place), but will, once the new parameter has been introduced, have to be reviewed individually.
 * This is another place (no pun intended) where too unspecific parameter names are biting us badly.
 * --Matthiaspaul (talk) 08:14, 19 September 2020 (UTC)
 * publication place was intended to be that new separate parameter when it was first introduced. (See also XKCD standards strip.) I do not see a benefit, as was discussed sometime in the past year that instituted Category:CS1 location test, to retaining the two separate meanings, where there are ~500 instances of such. Pick one location and be done with it. --Izno (talk) 15:27, 19 September 2020 (UTC)
 * See also XKCD standards strip. This one?
 * —Trappist the monk (talk) 15:37, 19 September 2020 (UTC)
 * Indeed. --Izno (talk) 17:05, 19 September 2020 (UTC)

Borked?
HI all

Is the template currently broken?

I have used it for a time code in a film, but it seems to be just priting the parameters onto the article text for the viewing public:

Waterworld

(Last paragraph)


 * Reynolds still received full credit as director.Kevin Reynolds (1995). Waterworld (Film). Universal City Studios, Inc. Event occurs at 02:15:11. Directed by Kevin Reynolds

There are quotation marks around the last iteration of "Kevin Reynolds", but these are not selected when copy/pasting I am going to have to remove access date, as it is asking me for a url for the access date ... of course it came from my brain, as i know what date it is today lol


 * Reynolds still received full credit as director.Kevin Reynolds (1995). Waterworld (Film). Universal City Studios, Inc. Event occurs at 02:15:11. Directed by Kevin Reynolds |access-date= requires |url= (help)

and now going to hide the whole mess ...

Chaosdruid (talk) 17:47, 19 September 2020 (UTC)
 * Not wrapped in  tags?
 * — Preceding unsigned comment added by Trappist the monk (talk • contribs) 17:52, 19 September 2020 (UTC)
 * Yep, that was probably the biggest problem. Jonesey95 shows how to do it (and simultaneously fixes the citation, making this discussion pointless) in this edit. Glades12 (talk) 06:36, 20 September 2020 (UTC)

First/last or given/surname canonical form?
Our recent discussion Help_talk:Citation_Style_1 made me think (again) about the best choice for the canonical parameter names of the various name-related parameters. We currently support the variant pairs first/last and given/surname for all our name parameter sets author, editor, contributor, translator and interviewer.

While the first pair (our default) does not create problems for (most) Western names, it actually is ambiguous. Even our citation templates render the names in the order "last, first", something we accept without much thinking because we are so used to it. However, for names not following the Western name order, it is not obvious which part of the name belongs into which parameter, as what is displayed first and last may depend on context.

An alternative concept that works across almost all (Western and Eastern) cultures is to distinguish not the first and the last name, but the given and the family name (which we, somewhat oddly, call surname in our parameter interface, although that would better pair with forename, but anyway).

Since proper semantics are more important for input data than "proper" display order (which can be changed through other means if necessary), I think, we should switch to use given/surname as our canonical defaults. first/last would be supported as before, just not be the defaults any more.

The only difference would be that given/surname would be listed first in the list of alias names, and first/last a bit later.

The advantage of this minimal change would be that the risk of mixing up the given and family name of names in Eastern name order would be significantly reduced (if not eliminated, except for when they aren't known in the first place) in all new citations entered. Some bots (and probably also VE) would automatically start to use given/surname rather than first/last when adding new names to a template.

--Matthiaspaul (talk) 01:52, 20 September 2020 (UTC)
 * The disadvantage is that first/last (the order in which the parts of the name are presented) is meaningful for patronymic-without-surname systems like the Indian or Icelandic ones, whereas given/surname forces names in those systems into boxes into which they do not fit. —David Eppstein (talk) 05:42, 20 September 2020 (UTC)
 * Thanks for bringing in this interesting aspect.
 * According to our article on Icelandic names, they seem to be composed of given name plus surname, with given name and first name referring to the same part of the name. So, it seems as if the entry of Icelandic names would not be negatively affected if we would switch to given/surname (whereas the pair given/family would not fit well).
 * The article on Indian names, however, mentions many variants and leaves me unconclusive. I have invited the visitors of that article's talk page to share their views on this.
 * --Matthiaspaul (talk) 07:33, 20 September 2020 (UTC)
 * You are incorrect. Most Icelandic people do not have a surname. What they have is a patronymic. The differences are (1) that they are not generally called by that name by itself even in formal writing (so in a Wikipedia article about a person using this system we should refer to them by given name rather than by their patronymic, even though we generally refer to people with surnames by their surname), and (2) it is not a family name, passed down from generation to generation, but rather it is just one of the parents' given names (traditionally the father's), suffixed by "son" or "dottir" (same as English "son" or "daughter"). So e.g. Leif Erikson does not mean that Leif was from a family called "Erikson", as it might mean for an American name of similar form; it means that Leif's father had the given name Erik (and full name Erik Thorvaldsson etc). That's a historic example but they still use the same system. So it may seem to you that it is ok to call it a surname, but it really is not a surname and you are imposing your culture on their own in an inappropriate way. It sounds like you need to read https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ . —David Eppstein (talk) 07:50, 20 September 2020 (UTC)
 * Regarding Icelanding surnames, that's why I wrote given/surname (not given/family name). Our article on Icelandic names uses the term "surname" as well, as do referencing guides such as, so, while what you write is correct, the term "surname" can't be wrong either (unless someone would take surname as synonym for family name, which would not be correct for Icelandic names).
 * --Matthiaspaul (talk) 09:18, 20 September 2020 (UTC)

Horse profile citations
There has been an internal reorganisation of the horse profiles database at Racing Post (formerly at bloodstock.racingpost.com), so a number of citations (probably a couple of thousand, almost all using cite web) will have to change to match. Fortunately the mapping from the old to the new URLs is straightforward. As I see it, there are three possible approaches:
 * 1) Simply convert all the old URLs to the new URLs, leaving everything else unchanged
 * 2) Create a new template (I've set up a proof-of-concept Racing Post horse) which would be passed the horse id (a 6-digit number) and use it to construct the URL, and would be attached to the id parameter, in the same way as templates such as ProQuest
 * 3) Create a new specific-source citation template such as cite Racing Post horse profile, which would build the entire citation given the horse id and the title (similar to cite Mountain Project and many others)

All of these options involve about the same amount of work, and all could be done by bot or by AWB. My own feeling is that option 1 would be to miss an opportunity to futurepoof these citations, so the only real choice is between options 2 and 3. Because the citations currently use cite web, option 2 leads to error messages complaining about the lack of a URL. This can be fixed by changing to another citation template such at cite journal. but is obviously undesirable as the Racing Post database is not a journal. Option 3 seems the best to me, but I'd appreciate input from citation specialists here. (And as a supplementary question: the current citations mostly include parameters date and access-date - I don't think these are either necessary or beneficial when citing this sort of database and I'm inclined to just discard them - any thoughts?) Colonies Chris (talk) 10:58, 20 September 2020 (UTC)
 * I would say option three. Use Module:template wrapper so that editors can add whatever  parameters they want to the basic template.   is one example of a wrapper template.
 * —Trappist the monk (talk) 11:53, 20 September 2020 (UTC)
 * Agreed on option 3, for consistency and flexibility. As far date is concerned, this is a bit tricky when it comes to databases. Citing a record (a particular horse profile) is pointing to an in-source location, the source being the database. One should date the database edition/version normally. However, individual records may be revised or updated more often than the database itself and this should be cited too. I would utilize citation. I would use (clumsily) date for the record revision date. I would use edition for the database revision/version (this may also be a date). Access dates are not needed in such rendition. This is not perfect but should work, assuming the database is indexed by record-subject+record-revision. 172.254.241.58 (talk) 13:12, 20 September 2020 (UTC)
 * I see your point, but there doesn't seem to be any sort of date or version id available, either for the database as a whole or for any specific record (see Port Etienne for a typical example). Colonies Chris (talk) 15:28, 20 September 2020 (UTC)
 * I followed the link you provided (I wonder if there's a profile for Citation (horse)) and the earlier comment should be amended, as this is not a free-standing database. It is a website that includes a breeding/past performance database that may be continuously updated. The source (racingpost.com) is fixed. The horse profile webpage is now the in-source location. In this case access-date is apt, as the proper entry for date would be n.d.. This would be awkward in the specific-source template you have in mind, you may want to leave date out altogether. The other option involves wading into the source code to figure out the revision date, which is convoluted. And cite web is now as good or better than citation as the base template imo. 64.18.9.222 (talk) 03:53, 21 September 2020 (UTC)
 * Leave a request at WP:URLREQ regardless. --Izno (talk) 13:26, 20 September 2020 (UTC)

Remove period after Magazine name
British motoring magazine What Car? makes for rather silly looking punctuation. How can I best avoid the period after the "magazine" field in template:cite magazine? It currently ends up looking like this: Reference

Thank you,  Mr.choppers &#124;   ✎  18:24, 20 September 2020 (UTC)


 * For easier cross-refs some similar threads:
 * Help_talk:Citation_Style_1/Archive_62
 * Module_talk:Citation/CS1/Feature_requests
 * --Matthiaspaul (talk) 20:25, 20 September 2020 (UTC)

name-given= and -surname parameter variants
Following up on the recent thread Help_talk:Citation_Style_1/Archive_69, I have gone through the list of supported name parameters.

In the parameter sets for author, contributor, editor, interviewer, subject and translator we generally support -first, -last, -given, -surname, -link and -mask variants and their enumerated forms. (Some combinations also exist in non-hyphenated variants for legacy support, see below.)

I noticed the following irregularities:


 * interviewerlink and interviewermask were unsupported and unused but were still listed as supported in the Whitelist.
 * author-/interviewer-/-given/-surname as well as their numbered variants were missing from the set.
 * display-subjects as an alias for display-authors was missing from the set.

I have therefore removed support for the first two parameters and added the missing variants, so that we now have a fully symmetrical list of name parameters, making it easier to document and use them without having to look up which exact variants are supported by which group. subject is special as it (apparently deliberately?) does not support any of the -first, -last, -given and -surname variants. In addition to this, author and editor also support several non-hyphenated forms for legacy support, but it is good to know that at least contributor, interviewer, subject and translator are free of them now.

For the records, these non-hyphenated aliases are used only a few times and could be cleaned up and deprecated as well:
 * : (~96 -> 0)
 * : (137 -> 0)

--Matthiaspaul (talk) 21:54, 10 September 2020 (UTC)
 * This editormask does not time out. 87. --Izno (talk) 19:48, 11 September 2020 (UTC)


 * @Izno, do you have a reliable Cirrus search pattern to determine the exact number of articles containing cite templates including a nocat parameter (a parameter name unfortunately also used by various other templates in huge numbers, whereas the usage number in citation templates is probably very small)? I came up with   but this could still be fooled. --Matthiaspaul (talk) 21:00, 11 September 2020 (UTC)
 * It's not 0, certainly; Alabama has . Upper bounds is probably in the realm of 1300. --Izno (talk) 01:08, 12 September 2020 (UTC)


 * Of the set of non-hyphenated -related parameters, only editorlink (and enumerated variants) has a large number of hits at all, so we can deprecate the others:
 * editorfirst: (~0/~0)
 * editorlast: (0/~0)
 * editorgiven: (0/0)
 * editorsurname: (0/0)
 * editorlink: (3499/~3556)
 * editormask: (0/(2))
 * displayeditors: (0/27)
 * So, we are almost there that, among the -related parameters, only the group of  -related parameters are using non-hyphenated parameter variants in really huge numbers any more (which, at least, is easy to remember) &mdash; too much to fix them up any time soon without bot assistance.
 * --Matthiaspaul (talk) 14:05, 16 September 2020 (UTC)
 * Actually, even in the group of -related parameters, only some of them are used:
 * authorfirst: (~1/~2)
 * authorlast: (~1/~2)
 * authorgiven: (~0/~0)
 * authorsurname: (~0/~0)
 * authorlink: (~66730/~91681)
 * authormask: (~1939/~2125)
 * displayauthors: (2774/3145)
 * --Matthiaspaul (talk) 11:23, 17 September 2020 (UTC)


 * I think that the usage numbers of the non-hyphenated editor[0-9]link[0-9], author[0-9]mask[0-9], and displayauthors parameter aliases are already low enough to set these parameters to "deprecated" while continuing to fully support them (despite the deprecation maintenance message) for another year or however long it takes to reduce their numbers, so that editors will gradually switch them to their hyphenated forms when they edit the corresponding articles.
 * Would this be acceptable for author[0-9]link[0-9] (non-hyphenated) as well, or would we first have to reduce the much higher usage numbers considerably?
 * --Matthiaspaul (talk) 14:48, 17 September 2020 (UTC)
 * editorfirst, editorlast, editorgiven, editorlast, editormask, displayeditors, authorfirst, authorlast, authorgiven, authorsurname are indeed ~0.
 * editorlink#* 3.4k + editor#+link 140 ~ 3.5k uses.
 * authorlink#* ~253k + author#+link ~1.2k ~ 255k uses.
 * authormask#* ~2.1k + author#+mask ~10 ~ 2.1k uses.
 * displayauthors 2.8k (same link).
 * I see no harm in deprecating/removing the practically-unused ones. You should consider working through the parameter names in the template space as well for templates which implement these templates as a passthrough.
 * I think you can sell me on deprecating the others besides authorlink. 255k is not a number I want to drop in the deprecated pile. --Izno (talk) 05:52, 19 September 2020 (UTC)
 * Okay. I share your view in regard to this and consequently have set the three aliases (including their enumerated variants) to deprecated but left authorlink for it still has way too many active uses. The other aliases, which are already at 0 hits, were already disabled.
 * --Matthiaspaul (talk) 16:07, 19 September 2020 (UTC)
 * --Matthiaspaul (talk) 16:07, 19 September 2020 (UTC)

Still broken: title=none + doi-access=free
I am still seeing errors from cite journal with none + free. I thought this was supposed to be fixed? An example (a book review headed by the name of the book it reviews without having its own separate title): This one, if cited by itself, would not be too ridiculous to make up a fake title like "Magical Mathematics" (the title of the book it reviews). But when it is part of a bulleted list of 15 reviews, all of the same book, all given the same fake title, it just looks ridiculous. And if instead of making up something fake but plausible you copy what appears at the top of each review and pretend it's a title, you get monstrosities like (from a different review of the same book) "Featured Review: Magical Mathematics: The Mathematical Ideas That Animate Great Magic Tricks. By Persi Diaconis and Ron Graham. Princeton University Press, Princeton, NJ, 2012. $29.95. xiv+244pp, hardcover. ISBN 978-0-691-15164-9." So I prefer to omit them, which per WP:CITEVAR should be a perfectly acceptable citation style that the templates support. Adding a little lock icon to the doi shouldn't change anything about that.

To put it more bluntly, the autolinking RFC did not address citations with no title, and did not have consensus for imposing a new requirement that all journal citations list a title. Therefore, it should not have been implemented in a way that implicitly imposed such a requirement. —David Eppstein (talk) 21:45, 20 September 2020 (UTC)
 * Another use for this that I'm seeing, in trying to clean up these errors in existing articles, is when a publication with a normal title is reprinted in another source and the citation refers to both copies. It is typical to omit the title for the second reference, but this is now broken when the second copy would autolink. An example, from Pioneer anomaly:
 * Also published in
 * —David Eppstein (talk) 22:29, 20 September 2020 (UTC)
 * Cite the copy that was read per SAYWHERE. If they are the same for the fact of interest, cite the one more likely to be accessible for the common user. (Or, fill in the details and then use e.g. authormask.) --Izno (talk) 02:22, 21 September 2020 (UTC)
 * Your opinion on how you would have chosen differently which of multiple versions to cite in this instance is noted but not particularly relevant to a problem that concerns other editors being unable to format citations in the way that they prefer. And especially irrelevant because whoever actually made that choice, in this instance, is nowhere in sight to be lectured to about how their preference is wrong. —David Eppstein (talk) 06:27, 21 September 2020 (UTC)
 * It's fixed in the sandbox. As always, the issue is that this template is treated like it will cause the financial markets to crash if it's updated more than thrice a year. &#32; Headbomb {t · c · p · b} 22:31, 20 September 2020 (UTC)
 * As I have specifically said before, establish that consensus should be otherwise. Thanks. --Izno (talk) 02:22, 21 September 2020 (UTC)
 * Where is the consensus that it should be this way to begin with. This update schedule is the result of one person's preference for that update schedule and the template being locked behind an admin and LUA barrier. &#32; Headbomb {t · c · p · b} 21:55, 21 September 2020 (UTC)
 * WP:REDLOCK and High-risk templates and WP:STATUSQUO. I see no reason to disrupt the release pace. If you believe it should be faster, you may establish a consensus for that position at your leisure. --Izno (talk) 23:38, 21 September 2020 (UTC)
 * How about fixing a thing that is broken. WP:PERF applies. WP:REDLOCK doesn't. The fix is tested. It works. It should be deployed. &#32; Headbomb {t · c · p · b} 03:07, 22 September 2020 (UTC)
 * As Headbomb wrote, the sandboxed version looks like this:
 * Also published in
 * David, isn't this fixing the reported issue?
 * Related threads:
 * Help_talk:Citation_Style_1/Archive_70
 * Help_talk:Citation_Style_1/Archive_70
 * Help_talk:Citation_Style_1
 * Assuming a normal schedule for rollout, the update would probably happen on the weekend of the 2020-10-10/11.
 * --Matthiaspaul (talk) 21:42, 21 September 2020 (UTC)
 * Is there a good reason for having left it in a broken state for four months and for continuing to leave it in a broken state for another month, all the while bots continue to break more citations because of this? —David Eppstein (talk) 22:06, 21 September 2020 (UTC)
 * None but the belief that Wikipedia servers will be unhappy if we fix things. &#32; Headbomb {t · c · p · b} 03:08, 22 September 2020 (UTC)
 * I don't mean to ask even more from those who tirelessly work on these templates, but any willing sysop is free to publish the fixes from the sandbox. WMF sysadmins have said it's fine to update the templates more frequently, preferably during business hours (EU/USA time). Nemo 13:56, 22 September 2020 (UTC)
 * I don't mean to ask even more from those who tirelessly work on these templates, but any willing sysop is free to publish the fixes from the sandbox. WMF sysadmins have said it's fine to update the templates more frequently, preferably during business hours (EU/USA time). Nemo 13:56, 22 September 2020 (UTC)

no-cat parameter cleanup
Hi, the CS1 templates support a debug feature to disable categorization. This is currently supported by five parameter aliases, which is overkill for such a rarely used feature:


 * template-doc-demo 0
 * no-cat 0 (2 uses in non-citation templates)
 * nocat >=2 Paleocene Alabama (>15k uses in non-citation templates)
 * no-tracking 0
 * notracking 0

In our cleanup effort, I think, we should, in a first step, deprecate the unused parameter names template-doc-demo, no-tracking and notracking, making no-cat the canonical name and nocat its alias, and - despite the name - put them in (only) a special hidden category to find out how many citation templates actually use this feature. I think, the number will be very low (perhaps a handful, at most a few dozens), but given the fact that the template uses the "generic" parameter name nocat and that Cirrus search for this times out, we cannot find out easily.

Once knowing the citation templates using this feature and evaluating the reasons for its use, we might, in a second step, switch the parameter name to something unique (and thus easily searchable) but still more sensibly named than template-doc-demo, perhaps cite-no-cat (so that it can still be found if someone searches for a "no-cat" parameter), but ideally even something that fits into our naming scheme better: Perhaps it can be merged into (cite-)mode or integrated into a new, more general debug parameter like debug-mode, also controlling namespaces. This would be something to discuss in the next round.

If we support the ((accept-this-as-it-is)) syntax for more parameters (per Help_talk:Citation_Style_1, Help_talk:Citation_Style_1), we might even be able to eliminate some of the reasons for the feature's (ab)use in mainspace, thus reducing this again to a pure debug parameter.

--Matthiaspaul (talk) 08:56, 13 September 2020 (UTC)
 * In the Paleocene article above, this citation currently uses no-tracking to avoid being put into an "invalid DOI" error category (the DOI is oddly formed with a pending dot, but valid):
 * As the doi parameter meanwhile supports our ((syntax)) to disable our validation check, this can be achieved without abusing no-tracking now:
 * DOI values framed this way will now be put into a special maintenance category so we can try and derive patterns to further improve our DOI validation code.
 * --Matthiaspaul (talk) 20:02, 19 September 2020 (UTC)
 * Related links:
 * * Help_talk:Citation_Style_1/Archive_61
 * * Help_talk:Citation_Style_1/Archive_62
 * --Matthiaspaul (talk) 20:29, 20 September 2020 (UTC)
 * * Help_talk:Citation_Style_1/Archive_62
 * --Matthiaspaul (talk) 20:29, 20 September 2020 (UTC)


 * All of those searches are confined to article space. These parameters are mostly used outside of article space, often to suppress error categorization when template errors occur in discussions and in template docs where showing the error messaging is undesirable.  Some sort of special case code will be required to categorize the use of these parameters.
 * —Trappist the monk (talk) 11:36, 13 September 2020 (UTC)
 * See also recent discussion. --Izno (talk) 12:33, 13 September 2020 (UTC)
 * In all spaces (I'm not going to try for nocat given all the overlap):
 * 77 template-doc-demo
 * 38 no-cat
 * 475 no-tracking
 * 17 notracking
 * I would probably support removal of no-cat/nocat regardless of counts or the above-linked discussion given the overlap with other templates making it hard to find instances, and probably also notracking given the few uses. Whether we should remove no-tracking would probably be dependent on the purpose of this parameter in mainspace. --Izno (talk) 14:36, 13 September 2020 (UTC)
 * Good point, the uses outside mainspace can't be ignored here. Given the numbers I think we should proceed by trying to find out why the parameter was used in mainspace. However, to find all occurences we might need to temporarily introduce a special "uses nocat" category.
 * --Matthiaspaul (talk) 20:02, 19 September 2020 (UTC)
 * The usage numbers of the aliases notracking and no-cat have been brought down to zero (switching them to no-tracking for now, the most sensibly named one of the remaining aliases. Support for these parameter variants was disabled, and no-tracking is now the canonical form.
 * In order to sort out the nocat nightmare, we need a temporary tracking category. I would appreciate if Trappist could take care of this, as the code for this is a bit tricky and he is already familiar with it. I think it is important to have this in the forthcoming template update, so that we don't lose too much time until the next round.
 * Regarding no-tracking, at least the name is unique, but otherwise it's far from perfect. The jury is still open to find a parameter name better fitting into our parameter naming scheme...
 * --Matthiaspaul (talk) 20:29, 22 September 2020 (UTC)
 * You want this maint cat for nocat only? So:
 * —Trappist the monk (talk) 23:27, 22 September 2020 (UTC)
 * Thanks, that was straight-forward. :-) Somehow, I had expected something more complicated...
 * --Matthiaspaul (talk) 22:11, 23 September 2020 (UTC)
 * Okay, template-doc-demo has been eliminated as well now.
 * The following two pages are protected and therefore need to be updated by an admin:
 * List_of_hoaxes_on_Wikipedia/Richard_Hopkins_(chess_player)
 * User:Jonesey95/AutoEd/unnamed.js
 * I found that some secondary templates still use the former template doc demo parameter. They have been updated to accept no-tracking as well now, but the following 80 occurences should be fixed up as well:.
 * NB. One citation-related template using nocat is Citation error.
 * --Matthiaspaul (talk) 22:11, 23 September 2020 (UTC)
 * Matthias, you need to go slower or get opinions about some of your changes first. I don't agree to deprecating/removing template-doc-demo as I believe that should be the sole-purpose of the parameter (and which no-tracking and variants do not communicate). See the discussion I linked above. Reverted all of those changes. --Izno (talk) 23:16, 23 September 2020 (UTC)
 * Huh? I think I was quite clear right from the start (11 days ago) that template-doc-demo and its aliases should be cleaned up and replaced by something with a more sensible name and possibly modified functionality. template-doc-demo is about the most nightmarish parameter name I can think of. Although no-tracking does not fit well into our parameter naming scheme either, it is a much more user-compatible parameter name. In the long run we should be able to come up with a better name, anyway.
 * So far, I have not found another use in article space. Once we have sorted and cleaned up the nocat stuff after the next update, we should ask us the following questions:
 * Do we actually need this in mainspace? Should we disallow the feature in mainspace?
 * What should be the default behaviour in other namespaces? Should the behaviour be changed to populate categories only when a special option is given?
 * If it would be always disabled in mainspace and enabled elsewhere, do we need a parameter to control it at all?
 * Should we change the temporary nocat category into a permanent maint category for the feature as a whole?
 * Find a better parameter name based on the resulting functionality and use case of the feature. If we don't keep a maint category the parameter name needs to be unique to serve as a search pattern.
 * --Matthiaspaul (talk) 01:11, 24 September 2020 (UTC)
 * My point is that these questions should be answered before we remove the parameter name that indicates it should not be used in mainspace. :^) Removing it was a cart before the horse thing. What's your answer to the questions, to get that started? --Izno (talk) 02:12, 24 September 2020 (UTC)
 * --Matthiaspaul (talk) 01:11, 24 September 2020 (UTC)
 * My point is that these questions should be answered before we remove the parameter name that indicates it should not be used in mainspace. :^) Removing it was a cart before the horse thing. What's your answer to the questions, to get that started? --Izno (talk) 02:12, 24 September 2020 (UTC)

Please use consistent ordering in examples
Half the examples for put   near the beginning and half at the end. I know order doesn't matter, but the inconsistency hurts comprehension. Thanks y'all! -- Skierpage (talk) 23:21, 7 September 2020 (UTC)
 * If you see where improvements can be made in the cs1|2 documentation, please improve it.
 * —Trappist the monk (talk) 00:25, 8 September 2020 (UTC)
 * While it may be difficult to come up with one order suiting all cases, I'm sure most editors have some kind of default order and reoccuring patterns they use at least when editing citations manually. I can see three major sorting criteria:
 * Semantically (descending order based on importance of entry in identifying a specific citation)
 * Convenient ("chronological" order of appearance when writing down and subsequently completing a citation, e.g. with url= before title= in cite web)
 * Alphabetically (ascending order, only useful in documentation)
 * FWIW, I typically try to use a semantical order similar to the following, but deviate from it when editing existing citations:
 * control parameters (ref, mode)
 * title-/chapter-related parameters (title, script-title, trans-title, title-link, chapter, script-chapter, trans-chapter, chapter-link)
 * author-/editor-related parameters (author list, editor list, contributor list, translator list, each entry ordered first, last, link, optionally name-list-format, *-mask, display-*)
 * publication-date-related parameters (publication-date, date, orig-date)
 * version-related parameters (edition, version)
 * venue-related parameters (magazine/journal/conference, series/work, volume, issue/number)
 * page-related parameters (page, pages, at, optionally nopp)
 * publisher-related parameters (publisher, via)
 * location-related parameters (publication-place, location)
 * identifier-related parameters (with issn and isbn first and id last in the list)
 * url-related parameters (url, url-access, chapter-url, chapter-url-access, access-date, url-status, archive-url, archive-date)
 * quote
 * postscript
 * --Matthiaspaul (talk) 10:42, 9 September 2020 (UTC)
 * A somewhat related thread:
 * Help_talk:Citation_Style_1 --Matthiaspaul (talk) 16:47, 24 September 2020 (UTC)

Invalid parameters ignored when empty
Hi, invalid template parameters throw an error message (and optionally a hint) when they contain a value, but are ignored when empty.

While it is okay to leave (some) empty parameters in a citation in order to point editors to missing information, I think, unrecognized parameter names should always generate an error, regardless if they contain a value or not. --Matthiaspaul (talk) 09:24, 9 September 2020 (UTC)
 * Probably more trouble than is worth. It is clear that unknown parameters are ignored, and any editor would probably realize something is wrong when the input doesn't display. The coding routines to implement this may not be simple and would have to be amended any time there is any change in the "legal" parameters. 65.88.88.57 (talk) 12:51, 9 September 2020 (UTC)
 * Actually, very simple, and the code already uses Module:Citation/CS1/Whitelist as a reference; any parameter name not in the whitelists is an unknown parameter. At present there is an   statement that looks for a parameter value.  When the parameter value is an empty string, the code goes on to the next parameter in the template.  For unknown parameters without assigned values, we simply follow the currently non-existent   where we do a quick check to see if the parameter name is in the whitelist; ignore when it is, error message when it isn't.
 * No changes to the code required when the whitelist is updated. This same mechanism will also catch empty deprecated parameters.
 * —Trappist the monk (talk) 13:24, 9 September 2020 (UTC)
 * We could do this. Were we to do it, I think that we should limit the checking to the basics.  Is this a known and properly formed parameter?  No checking the suggestion list.  I don't know how to predict how many of these kind of parameters exist in the wild so we could be in for torches and pitchforks if we do this with message-display enabled.  Separate category and error message from  (which category needs renaming) so that we don't turn off error messaging for unknown-parameters-with-values.  Once the majority of the unknown-parameters-without-values errors are remedied, we can combine the two categories and unify the error messaging.
 * The inclusion of empty parameters is, I think, pointless and just makes cs1|2 templates harder to read, clutters the wikitext so that the article text is harder to read in edit mode, and, in my experience, these empty parameters rarely get filled by subsequent editors. Just as bad is the inclusion of meaningless parameters with values – the abomination that is ve adds live when it adds empty archive-url and archive-date.  I would be in favor of including url-status without archive-url  as one of those errors that populate  (another category that needs a name change).
 * —Trappist the monk (talk) 13:24, 9 September 2020 (UTC)
 * Regarding unknown parameters (with or without values), sounds good to me.
 * Regarding known parameters with empty values, however, I differentiate between two cases:
 * Cleaning up some of the alias parameters recently, I ran into cases like this one, where empty template prototypes were copied into an article but never filled out, amounting to 2 KB of needless clutter in the given example. This obviously needs to be cleaned up and I don't object even when bots do it.
 * On the other hand, I often leave (for myself and other future editors) a couple of empty parameters in a citation pointing to specific missing info that I expect to be included in a complete citation but was unable to provide at the time I carried out the edit. In many of these cases, I will fill out these parameters at a later stage after further researching a topic (but this may take up to months, sometimes even years). I get quite upset if someone (typically drive-by editors) comes around and deletes those empty parameters, because it makes it more difficult for me to further improve such citations. It's like throwing sand in the gear.
 * The difference between these two cases is that the first case is about a large number of empty parameters left in a citation more or less mindlessly, and in the second case a few empty parameters left in a citation deliberately (and most likely only temporarily until the citation is complete).
 * If I had to program a bot rule for this, incorporating a threshold might allow to detect and eliminate the majority of instances of the first type while leaving most of the second type intact:
 * "If there are more than about five empty parameters in a citation, it is likely that someone just copied a template prototype, if there are fewer, the parameters were likely deliberately left by editors as hints for further research."
 * (A possible way to solve this in a way satisfactory for both parties could be to adopt my parameter review proposal also for empty parameters.)
 * Regarding live, I must admit that I typically add this as well when I add url and access-date. While I normally try to provide archive-url and archive-date at the same time, sometimes this is not possible because  is down again or refuses to archive a site. In my opinion url-status semantically belongs to url primarily, only secondarily to archive-url. While removing live in absence of archive-url is debatable (in a citation I favour explicit settings rather than relying on default assumptions, because the former work as kind of documentation and the latter can change over time), I have recently seen a bot (IIRC it was GreenC Bot) removing dead in absence of archive-url as well - this is annoying and clearly a bot error, because, if a URL goes dead or gets usurped by something else, this is a condition that should be recorded in dead even if no archive-url is available (and in some cases there may not even be an alternative url available). If this would be put into an error category, I can already see some careless editor or bot coming around removing the citation completely (although the document once was available and verified per access-date). Therefore, we shouldn't remove url-status and don't issue errors on this.
 * --Matthiaspaul (talk) 18:03, 9 September 2020 (UTC)
 * Responding to the OP: I would strongly object to the display of any error message to regular editors where unsupported but empty parameters are present. They do no harm. The normal use of Module:Check for unknown parameters in infoboxes and other templates, for example, does not display an error message or a hidden category when unsupported parameters are blank, because they do no harm. I have heard the argument that they are somehow an attractive nuisance, that editors will be tempted to put values in them, but there is little to no evidence that this happens, and if it did happen, the editor would encounter null display of the parameter value, along with an error message and a hidden category. I recommend letting sleeping dogs lie.
 * All of that said, if someone wanted to program AWB to remove empty, unsupported parameters from CS1 templates as part of AWB's general fixes, I would not object. They should be removed only as part of a substantive edit. – Jonesey95 (talk) 15:46, 9 September 2020 (UTC)
 * While I personally don't see a problem displaying an error message because the problem should be easy to fix even by unexperienced editors when the error message contains the name of the unsupported parameter, we could start with a preview message or opt-in maintenance message and maintenance category first to see how many of them are around.
 * --Matthiaspaul (talk) 18:03, 9 September 2020 (UTC)
 * To be clear, I am taking issue with 's implication that there is a problem at all. Empty parameters in CS1 templates do not cause any problems. We can safely ignore them. – Jonesey95 (talk) 18:15, 9 September 2020 (UTC)
 * Thanks for the clarification, I really took your comment as a recommendation to take less drastic measures than to throw an actual error message in the face of normal users.
 * My request, however, was primarily about unknown parameters (regardless of them being empty or not). I don't think we should ignore them, that's bad interface design (and also bad programming practise). Detecting and removing junk can help to reduce potential sources of confusion and to clean up clutter in badly maintained articles. We already throw an error message if an unknown parameter contains a value, so it would only be consistent to also throw an error message if an unknown parameter does not contain a value.
 * I could follow your argument in a discussion about how strong we should act on them, that is, if we should throw a hammer in form of an error message (my original proposal), or just give a nice hint in article preview and possibly populate a maintenance message for gnomes to clean them up (my compromise).
 * But I honestly cannot understand why someone would oppose a cleanup effort for as long as he would not be forced to participate in it. This looks as opposing something for the sake of opposing. While it is always possible that someone does not recognize something as a problem, this is not a good reason to oppose actions to remove problems seen by others for as long as such effort does not negatively get into his way. Do you see a use case for leaving unsupported parameters in citations? Do they carry some value for you?
 * --Matthiaspaul (talk) 19:24, 9 September 2020 (UTC)
 * When the tiny community of editors at this page makes a change that affects millions of CS1 template transclusions, thousands of editors who normally do not care about, or barely tolerate, CS1 templates and their complexity will see that change. If that change appears to those editors to be pointless, those editors form a negative opinion of the community that maintains those widely used templates, and they are less likely to support proposed changes that actually improve the quality of Wikipedia. All of that means that we need to be judicious about implementing change. – Jonesey95 (talk) 21:51, 9 September 2020 (UTC)
 * Indeed. Not signaling empty (optional) parameters is the norm in the Wikipedia platform. Required parameters are already properly addressed in cs1/2. Informational messages about unknown parameters are harmless and as stated above by Trappist apparently easily implemented. 172.254.241.58 (talk) 12:15, 10 September 2020 (UTC)
 * I've hacked the sandbox to emit an error message when cs1|2 encounters an unknown parameter that doesn't have an assigned value. Right now it uses the same error messaging as an unknown parameter with an assigned value.  If we retain this change, perhaps a better category and message is appropriate.  Also finds empty deprecated parameters.  Empty known parameters do not cause an error message:
 * —Trappist the monk (talk) 14:25, 10 September 2020 (UTC)
 * Thank you, Trappist, for demonstrating a proposed change. I object strongly to displaying error messages for empty parameters. I expect that it would cause a storm of trouble among non-technical editors. – Jonesey95 (talk) 15:02, 10 September 2020 (UTC)
 * In my first two posts on this topic I suggested, perhaps not clearly enough, that because I don't know how to predict how many articles have cs1|2 templates holding empty-unknown-parameters that if we include this detection, any messaging it produces should be hidden until the associated category is emptied sufficiently that enabling display will not cause torches pitchforks drama.
 * You are right, empty parameters don't cause problems in the sense that nothing technical breaks. cs1|2 doesn't care.  MediaWiki doesn't die.  Both render perfectly readable articles.  But cs1|2 templates in wikitext do impede editors when they are reading and editing wikitext.  This is true even when cs1|2 templates use only the parameters and values that they need; retaining unused parameters (known or unknown) compounds effort required for reading and editing.  This change does not propose to fix the empty-parameter-clutter problem.
 * —Trappist the monk (talk) 15:47, 10 September 2020 (UTC)
 * While I don't think the error message would actually cause a stir up, I don't mind if we make it a maint message first. Looks good to me.
 * --Matthiaspaul (talk) 12:44, 11 September 2020 (UTC)
 * I do think old parameters that are blank should be set in a category of some sort though I tend to agree it probably should not be visible. --Izno (talk) 16:14, 10 September 2020 (UTC)
 * I cannot think of a single instance where the case of optional parameters not being used is signaled to end-users in any programming environment. Any more than telling the user of any form (aka template) that they did not fill in optional fields. The person using the form knows that. If certain fields are consistently not used would be of interest to the form designer only. And then only if the unpopular fields consume resources better utilised elsewhere. 64.18.9.231 (talk) 13:06, 11 September 2020 (UTC)
 * I have tweaked the test a bit and changed its error message. Instead of independent error messages for each unknown empty parameter, the module now collects a table of unknown empty parameters and then creates a single list in a single error message.  Empty deprecated parameters are, for the purposes of this test, treated as unknown because they will become unknown at the end of the deprecation period.  Empty positional parameters are not ignored (positional parameters with some sort of value cause the  error message).  The error message produced by this test is hidden from readers and from all editors who have not opted to see hidden error messages.
 * – editors is deprecated so is included in the unknown empties error message
 * – deprecated parameters that have an assigned value are not treated as unknown
 * – extraneous pipe creates empty positional parameter
 * – extraneous pipe followed by whitespace is empty but not detected; I'll fix that fixed
 * —Trappist the monk (talk) 12:07, 12 September 2020 (UTC) 12:54, 12 September 2020 (UTC)
 * Logic looks good, but I would change the presentation slightly. Unknown parameters are rejected because they are unknown, not because they are "empty'. Some people may wrongly presume an implication. In other news regarding precision, parameters are never "empty". Perhaps they have not been assigned a value. Their data field could be empty though. 65.88.88.69 (talk) 13:14, 12 September 2020 (UTC)
 * Meh, I don't see the point. Only editors are even as much as annoyed by them (as long as they remain empty). Glades12 (talk) 18:15, 24 September 2020 (UTC)
 * – editors is deprecated so is included in the unknown empties error message
 * – deprecated parameters that have an assigned value are not treated as unknown
 * – extraneous pipe creates empty positional parameter
 * – extraneous pipe followed by whitespace is empty but not detected; I'll fix that fixed
 * —Trappist the monk (talk) 12:07, 12 September 2020 (UTC) 12:54, 12 September 2020 (UTC)
 * Logic looks good, but I would change the presentation slightly. Unknown parameters are rejected because they are unknown, not because they are "empty'. Some people may wrongly presume an implication. In other news regarding precision, parameters are never "empty". Perhaps they have not been assigned a value. Their data field could be empty though. 65.88.88.69 (talk) 13:14, 12 September 2020 (UTC)
 * Meh, I don't see the point. Only editors are even as much as annoyed by them (as long as they remain empty). Glades12 (talk) 18:15, 24 September 2020 (UTC)
 * —Trappist the monk (talk) 12:07, 12 September 2020 (UTC) 12:54, 12 September 2020 (UTC)
 * Logic looks good, but I would change the presentation slightly. Unknown parameters are rejected because they are unknown, not because they are "empty'. Some people may wrongly presume an implication. In other news regarding precision, parameters are never "empty". Perhaps they have not been assigned a value. Their data field could be empty though. 65.88.88.69 (talk) 13:14, 12 September 2020 (UTC)
 * Meh, I don't see the point. Only editors are even as much as annoyed by them (as long as they remain empty). Glades12 (talk) 18:15, 24 September 2020 (UTC)

Potential conflict between "Cite web" documentation and ProveIt?
Take a look at Special:Diff/979504621 -- it looks like PROVEIT is automatically placing the  parameter after the author and name fields in cite web. But on the documentation for that template, the provided formats all put that field first. It doesn't really matter to me either way, but it seems a little silly for the parameters to have two different canonical orderings. Anyone capable of shedding some light on this? { $$\mathbb{JPG}$$ } 05:41, 21 September 2020 (UTC)
 * Perhaps the examples treat url as the semantically most important parameter in the specific template context, whereas Provelt orders according to most common index fields. I consider this more of a cosmetic difference. I am not sure that dictating a canonical order to editors adds value. The required parameters are signaled. The software formatting can handle the rest. 64.18.9.222 (talk) 11:05, 21 September 2020 (UTC)
 * Would be better if it left the order of parameters alone as it is a pain in differences. It should just change the parameter in-situ and not do any reordering. Keith D (talk) 11:59, 21 September 2020 (UTC)
 * There is no "canonical ordering". Ideally, tools should not change the order of parameters; as Keith D says, it makes diffs harder to inspect. – Jonesey95 (talk) 13:17, 21 September 2020 (UTC)
 * I also think that bots should normally leave the parameter order unchanged. Still, it might make sense to streamline our examples and template prototypes a bit to use a single order, ideally one that is semantically logical and thus can be memorized easily and that can be maintained over all CS1/CS2 citation templates.
 * A somewhat related thread: Help_talk:Citation_Style_1
 * --Matthiaspaul (talk) 16:46, 24 September 2020 (UTC)

Language indicator for article, not journal
In the past, a lot academic journals printed articles in different languages even in the same volume. The  indicator of cite journal should thus be article-specific, not journal-specific. By that I mean instead of it should be This suggestion is actually related to a similar one I made in May regarding the language indicator placement in cite book. --bender235 (talk) 15:48, 24 September 2020 (UTC)
 * Jacobi, C. G. (1834). "Ueber die Figur des Gleichgewichts". Annalen der Physik (in German). 109 (8–16): 229–233..
 * Jacobi, C. G. (1834). "Ueber die Figur des Gleichgewichts" (in German). Annalen der Physik. 109 (8–16): 229–233..
 * I agree, both for articles in a journal and books in a series, and also for separately-authored chapters in an edited book. Kanguole 16:06, 24 September 2020 (UTC)
 * FWIW, the topic was also touched here: Help talk:Citation Style 1/Archive 69 --Matthiaspaul (talk) 16:33, 24 September 2020 (UTC)
 * Oh, glad someone managed to dig that out quicker than I did.
 * To wit, please consider Module talk:Citation/CS1/Feature requests and see if any of the suggested outputs look like they should not. --Izno (talk) 16:40, 24 September 2020 (UTC)
 * That is too complex to be confident of correctness. I suggest solving this in two stages:
 * Put the parentheticals where they belong – putting (in Lang) after a series, journal or edited book is clearly wrong.
 * Combine adjacent parentheticals.
 * Kanguole 17:08, 24 September 2020 (UTC)
 * It's not like either is trivial... --Izno (talk) 17:48, 24 September 2020 (UTC)
 * All the more reason to stage them. Kanguole 18:14, 24 September 2020 (UTC)
 * (edit-conflict) There is a somewhat related topic not in regard to the position of the language indicator, but in regard to the language value that should be displayed:
 * Help_talk:Citation_Style_1/Archive_67
 * language normally indicates the language of the work, but not necessarily that of title because if the original language title is not known, title (rather than trans-title) may contain the translated (here typically: English) title. But what, if script-title is used as well and its language prefix indicates a different language from language? Assuming that noone would go through the hurdles of writing a title in a non-Latin script if the work would not be in this very language as well, shouldn't the prefix language be considered the more accurate info and override the language provided by the language parameter? And, wouldn't it be possible that, if both are present and different, language actually was meant to apply to the journal/book as a whole (based on its display position) rather than the article/chapter? Should we display two "(in language)" then?
 * --Matthiaspaul (talk) 17:52, 24 September 2020 (UTC)
 * The language prefix and the language of the work will usually be the same, but there might be situations where they differ, and it's simple enough to continue to ask people to supply both.
 * The concern of a citation is the language of the work being cited, in this case a journal article or separately-authored chapter in an edited book. The language of the whole journal or book is not particularly relevant. Kanguole 18:14, 24 September 2020 (UTC)

Replacing ignore-isbn-error= and doi-broken= by isbn/doi=((invalid-value)) syntax
Only a minor point, and even one that would require a few hours work to clean up existing citations, so no priority, but in the long-run attempt to improve the consistency of the parameter interface of the citation templates and, where reasonably possible, reduce the number of parameters by making some of the existing parameters "smarter", I think, the true parameter (and its alias true) would be a good candidate to be replaced by adding support for the double-parentheses-syntax to ((accept this value as it is)) in the isbn parameter.

For a long while, when I occasionally ran into "valid invalid" ISBNs, it always took me quite some time to look up the exact parameter name to disable the ISBN validation check because true was almost undocumented (meanwhile it can be found listed nearby the documentation for isbn, so is easy to find). Things would have been easier, if the template would have supported the ((syntax)) instead of using a separate parameter for this. While this syntax is a bit cumbersome in itself (it needs to be), once you learn about it and have realized that this is a generic escape method used in various places to let the template accept parameter values it otherwise would not for some (normally but not in this particular case valid) reason, it becomes only natural to also try it when running into invalid isbn values - only to find out that it is not supported there.

So, for consistency, it should be supported there as well, and the ignore-isbn-error parameter be deprecated after existing citations have been adjusted accordingly (possibly by a bot).

(There are other cases, where the ((syntax)) should be supported as well (but still isn't), e.g. we recently had a discussion about quarters in date, where it was recommended as a breakout as well, see Help talk:Citation Style 1/Archive 68. The idea there was ((to reluctantly accept the input)) to not frustrate and block the editor in his/her endeavour to improve the encyclopedia, but to put such escaped forms into a maintenance category for evaluation in order to detect missing template functionality and for possibly necessary post-processing.)

--Matthiaspaul (talk) 10:30, 10 August 2020 (UTC)

Followup: doi-broken/doi-broken-date/doi-inactive-date would be other candidates. While these and the ignore-isbn-error parameter are reasonably named as is, they don't follow some overarching naming scheme and therefore are difficult to remember (and, as a consequence, need to be looked up whenever needed). It would be much more consistent and easier to remember if doi would accept the ((syntax)) as well for such invalid DOIs.

--Matthiaspaul (talk) 10:39, 10 August 2020 (UTC)
 * Weak support. Sounds reasonable, though it should definitely be low on the priority list. Glades12 (talk) 18:06, 6 September 2020 (UTC)

, '%1');.
 * The template now supports both methods to indicate invalid ISBNs. The oddball parameter ignore-isbn-error has been set to "deprecated", and the remaining < 300 uses can be easily switched to use the ((accept-this-as-is)) syntax manually as soon as the template goes live, so that support for that parameter can be disabled in the subsequent update.
 * --Matthiaspaul (talk) 15:59, 19 September 2020 (UTC)
 * Same support now for to-be-ignored ISSN/EISSN errors:
 * → (valid ISSN)
 * → (invalid ISSN)
 * → (ignored invalid ISSN)
 * --Matthiaspaul (talk) 22:03, 22 September 2020 (UTC)
 * I have created  in Module:Citation/CS1/Utilities/sandbox and used it in Module:Citation/CS1/Identifiers/sandbox to replace v, count_accept = v:gsub ('^%(%((.*)%)%).
 * This new function also replaces similar code in Module:Citation/CS1/sandbox.
 * —Trappist the monk (talk) 13:12, 26 September 2020 (UTC)
 * I have created  in Module:Citation/CS1/Utilities/sandbox and used it in Module:Citation/CS1/Identifiers/sandbox to replace v, count_accept = v:gsub ('^%(%((.*)%)%).
 * This new function also replaces similar code in Module:Citation/CS1/sandbox.
 * —Trappist the monk (talk) 13:12, 26 September 2020 (UTC)
 * —Trappist the monk (talk) 13:12, 26 September 2020 (UTC)
 * This new function also replaces similar code in Module:Citation/CS1/sandbox.
 * —Trappist the monk (talk) 13:12, 26 September 2020 (UTC)
 * —Trappist the monk (talk) 13:12, 26 September 2020 (UTC)

Deprecating some unused parameter aliases
Further researching possible options for my proposal to streamline override options for ISBN and DOI error handling, I was going through the list of currently supported parameter aliases and I found that ignoreisbnerror is actually unused. Given that, according to this thread, we don't want to introduce new non-hyphenated parameter aliases any more and keep the existing non-hyphenated variants only for legacy support, I don't think it makes any sense to keep support for non-hyphenated parameter aliases if they are unused, in particular if they belong to such rarely used features. Therefore, I want to deprecate the ignoreisbnerror alias.

Likewise, I was curious about the usage statistics of the many aliases parameter names for a small feature such as the DOI error override and found doi-inactive-date to be used only as an empty parameter, apparently from copying empty templates into articles - meanwhile removed. Astonishingly, there were also a few live occurences of empty template parameters doi-inactive/doiinactive/doibroken, although these are not supported as actual parameters by the templates (perhaps they were in the past and have never been cleaned up - done now).

There were three occurences of doi-broken actually being used, which I switched to use doi-broken-date instead, so that we are free to fade out doi-broken as well.

Removing support for these aliases we'd end up with the two canonical parameter forms ignore-isbn-error and doi-broken-date only.

--Matthiaspaul (talk) 14:51, 6 September 2020 (UTC)
 * ignore-isbn-error and ignoreisbnerror are not new but were simultaneously introduced in April 2013 – that was before the RfC that established our preference for hyphenated parameter names.  Still, I, for one, do not object to deprecation and removal of little-used non-hyphenated parameter names.
 * I think that doi-broken should be deprecated and removed because that parameter requires a date so its name should declare that. In the sandbox I have made doi-broken-date the canonical parameter name.  Similarly, embargo should be deprecated and replaced with embargo-date.
 * —Trappist the monk (talk) 17:54, 6 September 2020 (UTC)
 * Thanks for looking up the link to that old RfC.
 * There were only 14 occurences of embargo in use, and in all of these cases the parameter value was empty - therefore I cleaned them up. I support the switch to embargo-date or even better pmc-embargo-date given that the parameter applies only to PMCs.
 * So, we deprecate ignoreisbnerror, doi-broken, embargo, and ... ? You didn't mention doi-inactive-date, which I think we can deprecate as well - it's not used. I don't see a reason why we would need to support doi-broken-date and doi-inactive-date in parallel, or are these two different use cases which might need to be distinguished in the future?
 * In either case, is it important to document the fail-date of a DOI in a citation at all? I'm asking, because, if it is not, we could streamline the parameter name even more by changing it to dead or even eliminate it completely by using our special syntax as in ((invalid-number)).
 * --Matthiaspaul (talk) 11:50, 7 September 2020 (UTC)
 * --Matthiaspaul (talk) 12:57, 10 September 2020 (UTC)
 * Further, following your reasoning with regard to doi-broken (3× uses that you changed to doi-broken-date so we are free to fade out doi-broken) I have removed chapter-doi and title-doi as unused and unsupported from ~/Configuration/sandbox, ~/Whitelist/sandbox, ~/Suggestions/sandbox. Did I miss any?  If / when there is support for these parameters, that is the time to introduce them; we should not speculatively add parameters.
 * —Trappist the monk (talk) 18:16, 6 September 2020 (UTC)
 * See also Help_talk:Citation_Style_1
 * --Matthiaspaul (talk) 16:32, 10 September 2020 (UTC)
 * See also Help_talk:Citation_Style_1
 * --Matthiaspaul (talk) 16:32, 10 September 2020 (UTC)

trans-quote?
Hi, I feel like I remember a parameter trans-quote for translated quotes from citations in foreign languages. Am I remembering incorrectly, or has this been removed? Thanks, Ezhao02 (talk) 13:31, 5 August 2020 (UTC)
 * Never existed. quote is a free-form parameter so you can include translations in it if you would like.  Better in my mind, if the quoted material is important to the article, put that material in the article, translate it there and cite both; don't clutter the references section with quotations.
 * —Trappist the monk (talk) 13:56, 5 August 2020 (UTC)
 * Thanks for the information and the advice. Something must have happened to my memory. Ezhao02 (talk) 14:01, 5 August 2020 (UTC)
 * You probably have seen one of the proposals to add this (and script-quote) in the past. While Trappist is right that quote is a free-form parameter so you can add your own formatting, it would be desirable to have a consistent style centrally maintained instead of every editor having to invent his own conventions for this. Therefore, such a parameter is desirable. --Matthiaspaul (talk) 12:03, 8 August 2020 (UTC)

In the absence of such a parameter, I prefer to format foreign-language quotations like this: "Lorem ipsum dolor sit amet. [This is a nonsensical example sentence.]" Glades12 (talk) 13:18, 4 September 2020 (UTC)
 * This is exactly how I do it as well.
 * --Matthiaspaul (talk) 15:07, 4 September 2020 (UTC)


 * As this request comes up often enough, I have added support for it:
 * The rendering is not exactly as we both have used it in the past, but it was easier to implement this way. This can be further tweaked in the future.
 * --Matthiaspaul (talk) 20:33, 27 September 2020 (UTC)
 * The rendering is not exactly as we both have used it in the past, but it was easier to implement this way. This can be further tweaked in the future.
 * --Matthiaspaul (talk) 20:33, 27 September 2020 (UTC)

Descriptive titles and tokenizing the "No title" case

 * Splitted out from the "Wayback Machine" thread above:

I would also [include the many variants of expressing "No title" and] add support for a special token like "no-title" to indicate this condition; so, none would mute the display of a title, whereas no-title would display the descriptive title "[No title]" instead. (Well, if none would not be an established case already, I would recommend off for this instead, so that none would be free to display the "[No title]" message.) While these conditions are more likely to occur in newspapers and journals, the tokens should work in all cite variants, not only some of them (as "none" does at present). This would also simplify the code and documentation.

This way, we would improve consistency across the project, keep editors from inventing their own ways to express this special condition, and enable us to centrally update the message if this would become necessary in the future (e.g. due to a MOS change).

Which brings up another related topic: While the "no title" condition should IMO be a tokenized special case, I think, we should also have a dedicated parameter to enter other so called descriptive titles. (Descriptive titles are titles provided by the editor of a citation which differ from the actual title (if one exists) given by the author of the work. They are used in cases where the actual title is unsuitable to be reproduced in a citation for some reason (like being completely misleading, too long, historical alias names, non-existent etc.).)

We could use something like desc-title, descriptive-title, description-title or just description to distinguish them from actual titles. APA recommends to put descriptive titles in square brackets, some other style guides recommend to just write them without any text decoration (including without quotes)). See also: It could be useful to treat them differently (or even to suppress them) in meta-data, so that descriptive titles don't end up polluting databases without any means to tell them apart from actual titles.
 * https://ucmrp.edmc.edu/idc/groups/webcontent/@edmc_library_bmc/documents/webcontent/edmc-03350678.pdf
 * https://blog.apastyle.org/apastyle/2012/05/missing-pieces.html

The handling of descriptive titles could be somewhat similar to how we treat trans-title already, which reminds me of another related topic that trans-title should also work without title (instead of throwing an error), so that editors don't have to stuff translated titles into title (if the original-language title is not known) causing readers to assume these were the actual titles of a work and thereby causing confusion when trying to locate the work. See Help_talk:Citation_Style_1/Archive_67

Both features, tokenizing the "no title" condition and adding some means to enter descriptive titles differently were requested by several editors in the past already.

--Matthiaspaul (talk) 16:37, 4 September 2020 (UTC)


 * An example for the usage of the keyword "off" to disable the display of the title and the tokenized descriptive title "No title" in conjunction with auto-linking can be found in Help_talk:Citation_Style_1.
 * --Matthiaspaul (talk) 19:37, 27 September 2020 (UTC)

Request for new maintenance category for abbreviated year ranges in the date= parameter
Hi. Non-abbreviated year ranges are our preferred format for year ranges and there is certainly no particular need to support abbreviated year ranges in citations (except for if we can) - they could certainly be written in non-abbreviated form as well. Year ranges are comparably rare in citations, even more so abbreviated ones, as in most cases the publication date specifies a specific point in time rather than a span. I have seen less than a handful of abbreviated year ranges in citations in all those years.

On the other hand, incomplete dates consisting of only the month and the year and no day are very common in citations (I see them every day), but in the case of the ymd date format, the form "yyyy-mm" is disallowed in order to avoid a possible confusion with "yyyy–yy". Since the EDTF form "yyyy-mm-XX" is not currently supported as well (would be useful at least on source code level, not for display), this leads to such dates being rewritten as "Month yyyy", which unnecessarily creates inconsistency when all the other dates in the citations are given in ymd format.

Hence, it is reasonable to swap this around and fade out and ultimately disallow abbreviated year ranges in the date parameter of citations at some point in the future (only there, not elsewhere where they are still allowed, including e.g. in title, chapter, or quote parameters), so that, at some further point in the future, we can officially allow "yyyy-mm" in citations already using the ymd format. (In order to keep the change as minimal as possible, this is meant to affect only citations, not dates in tables or in the article body.)

In order to get a grip on how many citations actually have dates formatted this way at all, I would appreciate a tracking/maintenance category for citations using any detectable form of abbreviated year range (but at least the "yyyy–yy" form). --Matthiaspaul (talk) 13:19, 9 August 2020 (UTC)
 * Can you please give a list of examples of what you consider abbreviated year ranges? It is unclear what you consider acceptable and unacceptable.
 * Our date format checking follows MOS:DATESNO and MOS:DATERANGE; is there an invalid format listed there that is not being detected? – Jonesey95 (talk) 15:01, 9 August 2020 (UTC)
 * Here's an example of an invalid range that is currently detected as an error: . – Jonesey95 (talk) 15:03, 9 August 2020 (UTC)
 * Here's an example of an invalid range that is currently detected as an error: . – Jonesey95 (talk) 15:03, 9 August 2020 (UTC)


 * I don't think so. The idea, however, is to deprecate abbreviated year ranges in citations in general, even where they are currently still allowed by MOS. (Before I hear people screaming: This change should only affect abbreviated year ranges in citations, not other uses anywhere else in an article, which should continue to be allowed under the restrictions already applying per MOS.)
 * My feeling is that this minimal change to the MOS would impact only very few citations in existence, therefore it should have no actual negative effect on those who prefer abbreviated year ranges. (However, at a later point in time, it would have major advantages for the many articles using citations in ymd format, because then they could write "yyyy-mm" instead of "Month yyyy" when the day is not known.)
 * But in order to know the actual numbers, we need a maintenance category for abbreviated year ranges.
 * Here are some examples of abbreviated year ranges:
 * 1881–86, 1881–886, 1881–6, 1881–82, 1881–882, 1881–2
 * Of those, 1881–886, 1881–6, 1881–882, 1881–2 are not allowed anywhere in Wikipedia (and are probably already ruled out by our template - haven't tried), whereas 1881–86 is allowed in certain contexts if good reasons apply for using them, and 1881-82 (consecutive years) is allowed in more places, while still not being the preferred form.
 * I guess, it makes sense to also sense for the same pattern with hyphen (-) rather than endash (–).
 * I have never seen other forms, but perhaps there are variants with additional pre- or postfix notation. If so, they should be put into this category as well for evaluation. At present (before the proposed MOS change) this should not be flagged as error, as it is just for tracking.
 * --Matthiaspaul (talk) 16:08, 9 August 2020 (UTC)
 * I feel like I'm doing your work for you. Does the above list help? Do you propose that CS1 mark the first case, "1881–86", as an error? All of the other cases appear to be processed correctly per MOS. – Jonesey95 (talk) 17:08, 9 August 2020 (UTC)
 * I think this is going in the wrong direction. The readers still would not know what the abbreviated date is meant to represent and not know that we disallow abbreviated years. We should be making it clear what we are using and disallow both yyyy-mm & yyyy-yy in citations. Keith D (talk) 19:01, 9 August 2020 (UTC)
 * Both of those formats are already flagged:
 * Again, what is the exact proposal here? If the proposal is to change MOS, that should happen at a MOS talk page. – Jonesey95 (talk) 19:20, 9 August 2020 (UTC)
 * Jonesey, it is extremely hot over here, and possibly also where you live, but still I think I have been quite clear about that. The request, at this stage, is to put citations which contain abbreviated year ranges in the date parameter into a dedicated maintenance category for further evaluation. The request is not to check the current implementation to be in sync and to be compliant with the MOS, nor is it to throw any additional error messages. The question I hope to be able to answer is the extent to which such abbreviated year ranges are used in citations at present (although I already assume them to be rarely used), and if there is anything special about the articles using such citations.
 * This is not a request to change the MOS, but this will likely happen (e.g. there) at a later stage pending the outcome of an evaluation of the citations accumulating in the requested maintenance category.
 * I deliberately remained somewhat vague in regard to the exact search pattern because there might be forms of abbreviated year range notations in the English language I am simply not aware of (as a non-native speaker), and the resulting pattern also depends on (the sequence of) pattern checks already carried out by the current implementation (e.g. your list above gives a good overview, but I found that yy <= 12 are special-cased - there might be more such peculiarities, leading zeros come to my mind).
 * At the risk of missing some special forms, something similar to yyyy[–|-]yy would probably catch most already (based on some tests with " " as a search pattern, which, however, times out, therefore does not give accurate figures). At this stage, this does not need to be 100% exact math, although someone reading my intentions for this request above and being familiar with the actual implementation would probably be able to nail it down with precision right from the start.
 * --Matthiaspaul (talk) 20:34, 9 August 2020 (UTC)
 * Forgot to mention year ranges in the publication-date and year parameters in addition to those in date.
 * --Matthiaspaul (talk) 16:31, 21 August 2020 (UTC)
 * See also: Help_talk:Citation_Style_1 --Matthiaspaul (talk) 17:40, 23 August 2020 (UTC)
 * Abbreviated year ranges in the date, year or publication-date parameter will now be indicated by an optional maint message and put into new category "Category:CS1 maint: abbreviated year range" for further evaluation:
 * --Matthiaspaul (talk) 23:43, 19 September 2020 (UTC)
 * This is not a request to change the MOS, but this will likely happen (e.g. there) at a later stage pending the outcome of an evaluation of the citations accumulating in the requested maintenance category.
 * I deliberately remained somewhat vague in regard to the exact search pattern because there might be forms of abbreviated year range notations in the English language I am simply not aware of (as a non-native speaker), and the resulting pattern also depends on (the sequence of) pattern checks already carried out by the current implementation (e.g. your list above gives a good overview, but I found that yy <= 12 are special-cased - there might be more such peculiarities, leading zeros come to my mind).
 * At the risk of missing some special forms, something similar to yyyy[–|-]yy would probably catch most already (based on some tests with " " as a search pattern, which, however, times out, therefore does not give accurate figures). At this stage, this does not need to be 100% exact math, although someone reading my intentions for this request above and being familiar with the actual implementation would probably be able to nail it down with precision right from the start.
 * --Matthiaspaul (talk) 20:34, 9 August 2020 (UTC)
 * Forgot to mention year ranges in the publication-date and year parameters in addition to those in date.
 * --Matthiaspaul (talk) 16:31, 21 August 2020 (UTC)
 * See also: Help_talk:Citation_Style_1 --Matthiaspaul (talk) 17:40, 23 August 2020 (UTC)
 * Abbreviated year ranges in the date, year or publication-date parameter will now be indicated by an optional maint message and put into new category "Category:CS1 maint: abbreviated year range" for further evaluation:
 * --Matthiaspaul (talk) 23:43, 19 September 2020 (UTC)
 * --Matthiaspaul (talk) 23:43, 19 September 2020 (UTC)

It looks like the code may need refinement. Case 4 is incorrectly marked with a maintenance message. Case 7 already fails the date check, so it does not need a maintenance message. – Jonesey95 (talk) 00:09, 20 September 2020 (UTC)
 * Not really. As I wrote, the purpose of this category is not to check any compliance with MOS, but to collect certain abbreviated year ranges used in a publication-related date parameter (that is, date, year, and publication-date). Your cases 1, 4 and 7 are actually those cases I am looking for, as detailed further above. The behaviour of the existing date validation code was deliberately not changed. --Matthiaspaul (talk) 00:28, 20 September 2020 (UTC)
 * If maintenance is not required, then maintenance categorization is not appropriate. Better to use a properties category.
 * —Trappist the monk (talk) 12:41, 20 September 2020 (UTC)
 * Because maintenance is not required, switched maint cat to properties cat. To accomplish this, moved   from Module:Citation/CS1/sandbox to Module:Citation/CS1/Utilities/sandbox.
 * —Trappist the monk (talk) 13:24, 26 September 2020 (UTC)
 * According to my evaluation of several dozens of these citations, most of them actually need maintenance. In most cases, people specified assumed year ranges if they didn't know the actual publication year, or specified the span of availability of a source (which is one of the purposes of orig-date). In rare cases, the publisher's data actually specified a year range, in those cases mostly for consecutive years.
 * However, as this kind of maintenance applies to all year ranges, not only the abbreviated ones, I agree, that for the present investigation detailed future above, a tracking category without maintenance message is good enough. In the future, however, we may add a maintenance category for all year ranges, though, so that the above mentioned misuses can be cleaned up - however, this requires actually researching the citations, therefore it is time-consuming work.
 * --Matthiaspaul (talk) 19:14, 27 September 2020 (UTC)

Guidance on title-linking: update after RfC
The RfC on title-linking was concluded yesterday. A related WP:AN discussion is still open. I'd like to prepare updates that will be necessary to Template:Citation Style documentation, including its id2 subtemplate, to make it conform to the outcome of the RfC. Thoughts? Or is it best to wait until the AN thread is closed? --Francis Schonken (talk) 13:25, 20 September 2020 (UTC)
 * It's not clear that the RfC affects any of the existing guidelines, on which the template documentation is based. What makes you think it does? Nemo 13:50, 20 September 2020 (UTC)
 * As the closer of the RfC, I don't think it requires any change to the templates either. That certainly did not seem to be the desire that I can find of any consensus or even substantial minority of people. But perhaps there are second or third order technical effects that I am not aware of. Best, Barkeep49 (talk) 15:18, 20 September 2020 (UTC)
 * Template:Citation Style documentation/id2 currently contains:"When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, ..."(my emphasis). The RfC close contains:"There is consensus against removing a parameter just because it is a duplicate."
 * Rationale given in the id2 documentation:
 * The appropriate identifier parameter ... is more stable
 * The appropriate identifier parameter ... may allow to specify the access status
 * The url parameter or title link can then be used for its prime purpose of providing a convenience link to a free-to-read copy of the source that would not otherwise be obviously accessible
 * (in a footnote:) This does not restrict linking to websites that are being used as sources to provide content in articles.
 * In the RfC close the perspective is broader: "... there is an agreement that sometimes removing duplicates can be appropriate. This decision should be made on an article by article basis, unless it is a copyright violation for which there is consensus to remove. Questions that can help guide a discussion include:
 * Does the functional impact, as currently experienced by readers, of the parameter exactly duplicate another parameter?
 * Does including a duplicate link help to establish intent of the person adding the citation by helping them to say where they got it or otherwise enhance verifiability in some way?
 * Is the parameter free or behind a paywall?
 * Is the link dead? If yes does it make sense to rename it to a different parameter in keeping with question 2?
 * What will best respect WP:CITEVAR?"
 * I think it best to improve the template documentation along the lines proposed in the RfC close. --Francis Schonken (talk) 16:01, 20 September 2020 (UTC)
 * , hmm. I see your point. I leave it to you and other editors of this page to decide on what actions, if any, are needed here as per our standard advice. Best, Barkeep49 (talk) 16:05, 20 September 2020 (UTC)
 * Regarding this particular "id2" part of the template documentation, I see three problematic statements in there. All of them were introduced by "Nemo bis" about a year ago who reverted  my attempts to correct  the misleading statements twice:
 * The term "equivalent" in "When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, which is more stable and may allow to specify the access status". Terms like "equivalent" or "redundant" are actually (and apparently deliberately) misinterpreted as "remotely similar" by some editors (and not as "exactly the same"). This is actively used by CitationBot to remove even unrelated url value (like ) when a doi (pointing to ) is present. (In the given recent example, CitationBot also removed the archive-url alongside the url, thereby causing even more damage.) As I pointed out in the RfC, the terms "equivalent", "redundant" and even "duplicate" are apparently not clear enough to transfer the message unmistakably, therefore the wording should be actually changed to "exactly the same" or "identical".
 * The statement that DOIs are more stable and may allow to specify the access status is factually misleading. We have url-access (and url-status and access-date) to specify the access status of url just like we have doi-access (and doi-broken-date) for doi etc. Also, while DOIs are designed to be long-living, they are not necessarily longer living than URLs. I have seen citations with broken URL and working DOI but also vice versa. So, the key against link rot is redundancy through archives and alternative links. As this is not actually relevant for template documentation purpose, we could either correct the statement or remove the sentence completely.
 * "The |url= parameter [...] can then be used for its prime purpose of providing a convenience link to a free-to-read copy of the source that would not otherwise be obviously accessible.": This highly misleading sentence (see also: Help_talk:Citation_Style_1) should be removed completely. The primary purpose of url is not to provide a free-to-read copy of the source, but to point to the cited document, regardless if it is free or not. This doesn't rule out free documents, which are always nice to have, of course, but the notion that url was only for free documents crept further elsewhere and was (ab)used by some editors as an argument to remove url parameters from citations as well.
 * Now, the RfC is very clear about that being free is not a requirement for url to exist, therefore this could be reduced to something like "The |url= parameter [...] can then be used for other purposes." or be removed completely.
 * In general, I can only repeat myself, that the template documentation is not a guideline and should not attempt to be one.
 * --Matthiaspaul (talk) 17:57, 20 September 2020 (UTC)
 * Basically +1 to all of that, but also "When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, which is more stable and may allow to specify the access status" should be removed altogether. The RFC concluded with consensus to link titles, which means a URL should be provided even if there is an identifier. Lev!vich 00:22, 21 September 2020 (UTC)
 * Identifiers can also link titles. Nemo 06:12, 21 September 2020 (UTC)


 * Regarding Barkeep49's mentioning of possible second or third order technical effects above, I actually see one such issue, which affects the template's implementation (and not only its documentation). I interpret the RfC's closure summary as a general reestablishment of the idea that editors should have full control over the title link and URL.
 * (IMO, a link provided via url can be considered unnecessary, if exactly the same link can also be established via auto-linking of one of the provided identifiers in a citation, but the condition really is "exactly the same" and not "similar" or "equivalent". (Only) under this specific condition removal of url would have zero effect on how a citation looks like and functions on user level, and therefore could be considered harmless, if not even beneficial (cleaner and easier to maintain citation code).)
 * However, for the editor to have full control over the linking, it is important that an option to override the auto-linking exists, a premise under which the auto-linking feature has been discussed from the beginnings several years ago in 2016 (until and beyond the auto-linking RfC in spring 2020). We discussed several options how to achieve this in a way nicely blending into our existing user interface and basically settled on overloading none/(title-)doi/pmc///none/(chapter-)doi/pmc// only to (again) switch to use none/doi/pmc// instead in Help_talk:Citation_Style_1/Archive_70. Despite Pintoch's negative opinion on this, other users (proponents as well as editors opposing auto-linking in general) including Trappist the monk, Headbomb, Nardog, David Eppstein, myself and others have repeatedly asked over the years that auto-linking, if implemented, should have such a control. I won't go as far as to request for the setting "none" to become the default, still I think, also in the light of the outcome of this new RfC, that this facility should be implemented ASAP (ideally before the next update) to finally settle the case (so that future enhancements of auto-linking, some of which have been requested already, can be based on a solid implementation). --Matthiaspaul (talk) 11:21, 22 September 2020 (UTC)
 * See also: Help_talk:Citation_Style_1
 * --Matthiaspaul (talk) 18:58, 27 September 2020 (UTC)

Format parameter
I propose moving format content so that it is positioned after title and not after text "Archived from the original". --5.43.72.55 (talk) 19:50, 27 September 2020 (UTC)

freeze changes to the module suite
For a while now I have intended to begin the live-module update process. Whenever I got myself ready to do that, someone changed something so I put it off.

It is time to freeze changes to the module suite sandboxen so that we can update the live modules. Finish what you are doing this weekend. No changes after Sunday except to fix something that is obviously broken. Next weekend we can announce an update for 10–11 October 2020.

—Trappist the monk (talk) 16:10, 26 September 2020 (UTC)
 * , have you seen this message? Do you have a timetable for finishing your proposed changes so that we can discuss updating the module? And are you planning to document, explain, or discuss the functional changes that you are making to the sandboxes with edits like these that are marked as copy edits? When we have updated the modules in the past, Trappist has provided a careful, detailed list of all of the changes, along with links to the discussions where those changes were proposed and discussed. – Jonesey95 (talk) 13:06, 29 September 2020 (UTC)
 * I wonder how you could miss that I am motivating, documenting and discussing most any changes I do (except for trivialities) all the time, probably more than anyone else in this forum.
 * From Trappist's comment above I take it that he wants to set up the list, but as I keep track of my changes, I could do that just as well (if I'll have time then).
 * In general, I try to always keep the code in a releasable state, except for the very short periods of time while I am actively working on or testing something. So, if Trappist wants to take a snapshot for release he can do so (and could have done so in the past as well) at almost any time. I certainly don't hinder any admin from carrying out the update, in particular not as there have been repeated complaints by other editors to release more frequently (e.g. Help_talk:Citation_Style_1).
 * I would also have no problems to update every one or two months, or at least when we have bug fixes for serious bugs or major new features to be rolled out. On the other hand, I also think that we should not update yet more frequently (except for in emergency cases), because if everything is in flow, it is more difficult to detect bugs. Also, even though the update itself is trivially easy to do, we need to be careful because of the high transclusion count and the relatively fragile nature of the Lua interpreter language and limited debug facilities.
 * However, in general, I think that in a collaborative project things need to be negotiated, not dictated. So, if Trappist would have mentioned that he has time to work on the update on the next two weekends and asked if we could arrange for the update to happen then because it would be convenient for him, I would have answered long ago offering my support. I think I am normally a nice person and quite approachable, but I expect this from others as well. So, if one decides to enforce something on fixed dates without negotiation with other developers he certainly can do so, but then I feel not obligated to answer or interact.
 * I don't think we need to block the sandbox for two weeks just to prepare an update, that's too much precious potential development time wasted. (Perhaps we should think about a separate release stage area in addition to the sandbox in the next round.) But, nevertheless, as I don't want to hinder Trappist's pace, I have not added new features after the weekend, only cleanups and minor tweaks, although I have several features pending for inclusion already (which I would have included otherwise).
 * If we ignore a schedule for a moment, from a perspective which changes might still make sense before the update, these are the things I would normally like to see being addressed before the update:
 * Fix of one remaining bug in the code related to (auto-)linking when the title has embedded links. This is an old bug also present in the live template (but not yet discussed) and it is partially addressed in the sandbox already, but not completely. I hope to find the time to look into this before the weekend, but either case, as there are workarounds this should not block an update.
 * I think it would be convenient for users if the template would optionally issue suggestions not only for unsupported parameters (as it does now), but also for parameters currently deprecated (in addition to the help link). Since deprecation only affects a few parameters temporarily, only few citations would be affected, therefore I think the performance hit would be acceptable. I assume that adding this would not be difficult, but I haven't studied that part of the code thoroughly, so I don't know for certain. With luck, someone else (or I) would look into this before the weekend, but if not, we should roll out without it.
 * If there is enough time, I could add some error messages for certain parameter error conditions not currently addressed, but this is non-blocking as well.
 * The current preparations for descriptive titles are incomplete and kept in an interim state for a potential update of the template. However, if there would be a couple of days more time, I would like to rework and finish it, but this can also happen after the next update.
 * We should certainly also check secondary templates for pass-through parameters to now disabled/deprecated parameters and update them accordingly.
 * I don't know if I will have time on the weekends of the 2020-10-10/11 and 2020-10-17/18, which is bad, because we will have to update various error/maint category names during the update. And in the days following the update we will have to fix up deprecated parameter names in articles, and also update the documentation. So, IMO, we could even release in the middle of the next week already.
 * --Matthiaspaul (talk) 20:18, 29 September 2020 (UTC)
 * I called for a freeze because the module sandboxen have been in a state of more-or-less continuous churn since about 19 September. The editors who usually comment here seem to me to have become remarkably quiet.  I wonder why that is.
 * We are not in a race. If something isn't part of this update, there will be another update.
 * —Trappist the monk (talk) 16:09, 30 September 2020 (UTC)
 * I, for one, have become "remarkably quiet" because of the overwhelming volume of changes and proposed changes, and the huge blocks of text that the proposers of these changes have added to this normally concise talk page. I have simply been unable to understand and track all of them. As I have indicated above, I worry that a significant amount of under-discussed change will result in a backlash from regular editors, as has happened in the past. I hope that I am wrong.
 * I look forward to seeing a complete, concise list of the functional differences between the live modules and the sandbox modules. – Jonesey95 (talk) 18:52, 30 September 2020 (UTC)
 * I concur. I would add that implementation of closed RFCs or of any outstanding consensus should perhaps take precedence over any changes other than stability/security related ones. Let's play nice. 98.0.246.242 (talk) 19:39, 30 September 2020 (UTC)
 * I am the same as Jonesey and the IP. I'm about || close from reverting everything to prior to the churn and having a proper discussion; much of what was added had certain decisions made that were poor in some fashion or another and some of what was added or changed did not obviously have consensus to me. --Izno (talk) 23:50, 30 September 2020 (UTC)
 * I agree, please revert. Rushing changes to the module just before an announced deployment to prevent them from being reviewed and discussed is very counter-productive and partial. − Pintoch (talk) 07:29, 1 October 2020 (UTC)
 * To move this groundless "witch-hunt" into a constructive direction again, Trappist, will you provide the list of changes or should I?
 * --Matthiaspaul (talk) 20:21, 1 October 2020 (UTC)
 * I, for one, have become "remarkably quiet" because of the overwhelming volume of changes and proposed changes, and the huge blocks of text that the proposers of these changes have added to this normally concise talk page. I have simply been unable to understand and track all of them. As I have indicated above, I worry that a significant amount of under-discussed change will result in a backlash from regular editors, as has happened in the past. I hope that I am wrong.
 * I look forward to seeing a complete, concise list of the functional differences between the live modules and the sandbox modules. – Jonesey95 (talk) 18:52, 30 September 2020 (UTC)
 * I concur. I would add that implementation of closed RFCs or of any outstanding consensus should perhaps take precedence over any changes other than stability/security related ones. Let's play nice. 98.0.246.242 (talk) 19:39, 30 September 2020 (UTC)
 * I am the same as Jonesey and the IP. I'm about || close from reverting everything to prior to the churn and having a proper discussion; much of what was added had certain decisions made that were poor in some fashion or another and some of what was added or changed did not obviously have consensus to me. --Izno (talk) 23:50, 30 September 2020 (UTC)
 * I agree, please revert. Rushing changes to the module just before an announced deployment to prevent them from being reviewed and discussed is very counter-productive and partial. − Pintoch (talk) 07:29, 1 October 2020 (UTC)
 * To move this groundless "witch-hunt" into a constructive direction again, Trappist, will you provide the list of changes or should I?
 * --Matthiaspaul (talk) 20:21, 1 October 2020 (UTC)
 * --Matthiaspaul (talk) 20:21, 1 October 2020 (UTC)

Manual override of auto-linking
As extensively discussed in the past months, a manual override facility has now been implemented for the auto-linking feature.

For this, title-link now supports a number of additional keywords:,  ,. They can be used to manually select one of the identifiers enabled for auto-linking (currently only PMCs and DOIs) or to completely disable auto-linking. Any values not matching one of these keywords will be interpreted as link target to a Wikipedia page (or one of its sister projects), as before. If such a link target would clash with one of the keywords, the ((accept-this-as-is)) syntax can be used to enforce the interpretation as a link target.

Auto-linking is also disabled if the display of the title has been disabled by off (currently also still none), whereas it remains enabled for descriptive titles (including the "No title" case, which can be specified by none in the future).

If the title-link parameter is left empty and no url is specified, the template will automatically select an identifier for auto-linking, whereby the current priorities will let PMCs take precedence over DOIs, assuming both to be valid and active. Invalid or embargoed PMCs as well as non-free, inactive or invalid DOIs will be ignored in this selection. To play it safe, the present implementation also ignores "invalid" DOIs accepted using the accept-this-as-is syntax - after all, auto-linking is a non-essential feature and the identifier link is always available through the normal identifier link as well.

At present, auto-linking is only enabled for cite journal, but it could be generalized to be supported by other cite templates as well (as was requested already).

The list of supported identifiers can be extended in the future (also already requested), but I recommend that only manual auto-linking will be used for a larger list of identifiers, unless the identifier will have a similar "prominence" as DOIs or PMCs. Otherwise, the priority-based auto-selection may appear "arbitrary" to readers.

Another possible future extension (also already requested) would be to allow auto-linking of chapters in addition to titles.

See also:
 * Village_pump_(proposals)/Archive_135
 * Help_talk:Citation_Style_1/Archive_59
 * Help_talk:Citation_Style_1
 * Help_talk:Citation_Style_1/Archive_68
 * Help_talk:Citation_Style_1/Archive_70
 * Help_talk:Citation_Style_1

Some examples:


 * (DOI+PMC not given, nothing selected)
 * (DOI+PMC not given, nothing selected)
 * (DOI+PMC not given, nothing selected)


 * (DOI given, DOI auto-selected)
 * (DOI given, DOI auto-selected)
 * (DOI given, DOI auto-selected)


 * (PMC given, PMC auto-selected)
 * (PMC given, PMC auto-selected)
 * (PMC given, PMC auto-selected)


 * (DOI+PMC given, PMC auto-selected)
 * (DOI+PMC given, PMC auto-selected)
 * (DOI+PMC given, PMC auto-selected)


 * (DOI+PMC given, PMC manually selected)
 * (DOI+PMC given, PMC manually selected)
 * (DOI+PMC given, PMC manually selected)


 * (DOI+PMC given, DOI manually selected)
 * (DOI+PMC given, DOI manually selected)
 * (DOI+PMC given, DOI manually selected)


 * (DOI+PMC given, auto-linking disabled)
 * (DOI+PMC given, auto-linking disabled)
 * (DOI+PMC given, auto-linking disabled)


 * (DOI+PMC given, PMC embargoed, DOI auto-selected)
 * (DOI+PMC given, PMC embargoed, DOI auto-selected)
 * (DOI+PMC given, PMC embargoed, DOI auto-selected)


 * (inactive DOI given, nothing auto-selected, correct maint message)
 * (inactive DOI given, nothing auto-selected, correct maint message)
 * (inactive DOI given, nothing auto-selected, correct maint message)


 * (invalid DOI given, nothing auto-selected, correct error message)
 * (invalid DOI given, nothing auto-selected, correct error message)
 * (invalid DOI given, nothing auto-selected, correct error message)


 * (invalid DOI given, but accepted, nothing auto-selected, correct maint message)
 * (invalid DOI given, but accepted, nothing auto-selected, correct maint message)
 * (invalid DOI given, but accepted, nothing auto-selected, correct maint message)


 * (DOI+PMC given, title target article "Title" selected)
 * (DOI+PMC given, title target article "Title" selected)
 * (DOI+PMC given, title target article "Title" selected)


 * (DOI+PMC given, title target article "doi" selected)
 * (DOI+PMC given, title target article "doi" selected)
 * (DOI+PMC given, title target article "doi" selected)


 * (DOI+PMC given, title disabled, no auto-linking, correct maint message)
 * (DOI+PMC given, title disabled, no auto-linking, correct maint message)
 * (DOI+PMC given, title disabled, no auto-linking, correct maint message)


 * (DOI+PMC given, descriptive "no title" specified, PMC auto-selected, correct maint message)
 * (DOI+PMC given, descriptive "no title" specified, PMC auto-selected, correct maint message)
 * (DOI+PMC given, descriptive "no title" specified, PMC auto-selected, correct maint message)


 * (DOI+PMC given, title label "off" selected, PMC auto-selected)
 * (DOI+PMC given, title label "off" selected, PMC auto-selected)
 * (DOI+PMC given, title label "off" selected, PMC auto-selected)


 * (DOI+PMC given, title label "off" selected, title target article "doi" selected)
 * (DOI+PMC given, title label "off" selected, title target article "doi" selected)
 * (DOI+PMC given, title label "off" selected, title target article "doi" selected)


 * (DOI+PMC not given, URL given, URL selected)
 * (DOI+PMC not given, URL given, URL selected)
 * (DOI+PMC not given, URL given, URL selected)


 * (DOI+PMC given, URL given, URL selected)
 * (DOI+PMC given, URL given, URL selected)
 * (DOI+PMC given, URL given, URL selected)


 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)


 * (DOI+PMC given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and title link given, URL selected, correct error message)


 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and title link given, URL selected, correct error message)


 * (DOI+PMC given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and title link given, URL selected, correct error message)


 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)


 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)


 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message)


 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)
 * (DOI+PMC given, URL and embedded title link given, URL selected, correct error message)


 * (DOI+PMC not given, embedded title link given, title selected)
 * (DOI+PMC not given, embedded title link given, title selected)
 * (DOI+PMC not given, embedded title link given, title selected)


 * (DOI+PMC not given, piped embedded title link "Wikipedia" with label "Title" given, title selected)
 * (DOI+PMC not given, piped embedded title link "Wikipedia" with label "Title" given, title selected)
 * (DOI+PMC not given, piped embedded title link "Wikipedia" with label "Title" given, title selected)

--Matthiaspaul (talk) 18:51, 27 September 2020 (UTC) (updated 14:45, 30 September 2020 (UTC))


 * These two examples still show incorrect behaviour related to embedded title links (but this old bug is present in the live version of the template as well and some corner cases of it are already fixed in the sandbox):


 * (DOI+PMC given, embedded title link given, PMC incorrectly selected, incorrect error message)
 * (DOI+PMC given, embedded title link "Wikipedia" with label "Title" given, PMC incorrectly selected, incorrect error message)
 * (DOI+PMC given, embedded title link given, PMC incorrectly selected, incorrect error message)
 * (DOI+PMC given, embedded title link "Wikipedia" with label "Title" given, PMC incorrectly selected, incorrect error message)
 * (DOI+PMC given, embedded title link "Wikipedia" with label "Title" given, PMC incorrectly selected, incorrect error message)
 * (DOI+PMC given, embedded title link "Wikipedia" with label "Title" given, PMC incorrectly selected, incorrect error message)


 * Since the bug is old and can be easily worked around by using title-link instead of embedding the link into title itself, this is not blocking a release.
 * --Matthiaspaul (talk) 14:45, 30 September 2020 (UTC)


 * Hi, I do not think there is consensus for this change (as extensively discussed before). Please revert your changes. Thank you! − Pintoch (talk) 07:08, 1 October 2020 (UTC)
 * Auto-linking has always (since 2016 up to after the RfC in 2020) been discussed under the assumption that there is or will be a way to manually override it if necessary, because there obviously are cases where it will link to the wrong target. This was mentioned by users who opposed auto-linking (like David Eppstein or myself), but also by vivid proponents of the feature (like Headbomb). Without some override facility people will either have to remove the PMCs and DOIs from such citations or stop using citation templates at all, both options which are directly diametral to the purpose of citation templates of making it as easy as possible to provide fully-fledged citations, and thus not desirable at all. The recent RfC on title linking also concluded that users should have full control over what is linked to a title and what not.
 * Since your original implementation did not address this, introduced several bugs (all but one finally addressed with this pending update) and unconditionally enforced auto-linking, we have, over the course of months, discussed possible ways how to integrate this into the system in a seamless way.
 * We basically had three models, one using a separate parameter like auto-link or auto-url (both originally suggested by Headbomb), and two overloading existing parameters, url (originally suggested by Trappist the monk, Nardog and me) and title-link (also suggested by me, but Trappist also noted sympathies for this). Headbomb's proposal would have added a new parameter and the names suggested so far did not fit into our naming scheme well, but he was generally open to other parameter names and implementations. When requests regarding auto-linking of chapters came up, I abandoned my title-link proposal in favour to Trappist's because it appeared slightly more flexible in the long run, but switched back to title-link to address your concerns that overloading url might cause problems with external scripts needing to be updated. In the post above I gave links to some of the past discussions regarding this.
 * So, there is a clear desire to have some means to control auto-linking when the automatic default doesn't work. Among those proposals offered over the course of months, I think, we have found the best solution, and, to be honest, I really can't see how this would interfere with your desire for auto-linking in general (actually, it helps to make auto-linking a feature which can be accepted by anyone), unless there is some dogmatics/politics involved why you deliberately don't want to give editors the control over citations they need - but I can't see how this would be in agreement with our core principles regarding verifiability and NPOV.
 * --Matthiaspaul (talk) 11:09, 1 October 2020 (UTC)
 * I have better things to do than repeating arguments over and over. If you genuinely intend to address my concerns with your move, you would have addressed them months ago already (such as giving an example of a citation where it is desirable to disable auto-linking). I just wanted to note my opposition to your changes and generally to your attitude (squeezing a big change like this just before an update to bypass discussion is not very considerate to your fellow editors). − Pintoch (talk) 16:10, 1 October 2020 (UTC)
 * This is really such a waste of time. So far, you did not provide any arguments except for that you don't like it, which is not a useful argument at all. Simply stating that a feature is not needed because you don't need (want?) it in the face of other users asking for it, is denialist behaviour not up to communication standards between intelligent people. (See, I personally do not consider auto-linking a desirable feature at all, but obviously there are other users who want it, so any arguments that it would not be desirable in general would be stupid. Instead, I try to destill the reasons for why some people want it and others don't, and seek a solution addressing the wishes and concerns of both parties. This approach of trying to learn from opposing arguments is what I expect from other editors as well. But it requires that people bring forward actual arguments not groundless opinions.)
 * You did not bother to fix the various bugs you introduced into the implementation over the course of months and you very prominently and rudely backed out of the constructive discussion which was seeking for solutions. Basically, if you have nothing constructive to contribute, it might be better to really spend your time on other things instead of attempting to hinder constructive editors in improving the project, in particular as the solution is giving you exactly what you wanted (automatic auto-linking by default).
 * I also ask you to stop your repeated bad faith accusations, they are completely groundless. In fact, I waited long enough for someone else to fix your bugs and address the concerns (because I also have better things to do) before I started to code the solution myself because I couldn't stand this complete lack of progress any more - it's harmful to the reputation of the project. Before that, because I very much value any constructive comments by my fellow editors (even if I don't agree with all of them), I very carefully discussed and weighted the various options we have, involving the community in utmost possible ways. And I did not squezze any big changes in before any update, actually, my code existed before Trappist's announcement (which he should have first negotiated with other developers, anyway) and I removed several features from the to-be-submitted code because they need more discussion.
 * --Matthiaspaul (talk) 19:16, 1 October 2020 (UTC)
 * There should be an overide mechanism. The simplest being doi/pmc/jstor/etc/none / doi/pmc/jstor/etc/none. If you want an example where a link is not desired, title-less journal citations would be the go-to example.
 * &#32; Headbomb {t · c · p · b} 16:26, 1 October 2020 (UTC)
 * Yep. Having internally considered and compared the url and title-link proposals code-wise, I have come the conclusion that the latter was even easier to implement. (I have a solution for the chapter link issue also for title-link but this will need more discussion, therefore it's not included at this time.)
 * Another example where override is needed are chapter DOIs which would be accidently linked to a title (instead of a chapter title) if there would be no way to override the behaviour.
 * Also, if the original editor providing a citation linked the title to a DOI, this should not be suddenly overruled by auto-linking to a link to PMCs just because some drive-by editor or bot added a PMC without at least given the editor the chance to reselect the DOI. It would invalidate the citation.
 * --Matthiaspaul (talk) 19:16, 1 October 2020 (UTC)
 * title-link is a terrible use for this because it is overwhelmingly used for links to Wikipedia and sister projects like Wikisource. This replaces URL, so it should use the URL parameters. Difficulty of implementation matters a whole lot less than ease of use (url is both much shorter to type than title-link, and guarantees there is no conflicting url/title-link like someone adding https://example.com to a citation with doi. &#32; Headbomb {t · c · p · b} 19:30, 1 October 2020 (UTC)
 * While I don't think title-link is "terrible", I see your point (that's why I proposed url for a long while as well ;-). Also, I specifically agree with that difficulty of implementation does not matter (we should always strive for the best-possible solution for users, no matter if it is difficult to code or not). Among the cons for url is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as title-link. Among the pros for title-link is that something like doi or none is semantically much more to the point than doi or none. An the argument of states being mutually excluded by the underlying parameter logic applies to both parameters as well, just that url is probably more commonly used than title-link. I was (and still are) open to both, but now slightly favour title-link. Functionality-wise, both solutions are equivalent. --Matthiaspaul (talk) 20:06, 1 October 2020 (UTC)
 * Among the cons for url is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as title-link.
 * Any tool or bot that gets confused by that would get confused by any invalid URL parameter like . There are tons of those in Category:Pages with URL errors. Most such tools or bots already correctly handle such errors either by failing, or by not touching url because they don't know what to do with it. Using the existing parameter url/chapter-url/contribution-url/foobar-url greatly reduced complexity for users, who then don't need to learn the arcane title-link/chapter-link/contribution-link and wrap their heads around why a   parameter is renamed  . &#32; Headbomb {t · c · p · b} 20:32, 1 October 2020 (UTC)
 * Any tool or bot that gets confused by that would get confused by any invalid URL parameter like . There are tons of those in Category:Pages with URL errors. Most such tools or bots already correctly handle such errors either by failing, or by not touching url because they don't know what to do with it. Using the existing parameter url/chapter-url/contribution-url/foobar-url greatly reduced complexity for users, who then don't need to learn the arcane title-link/chapter-link/contribution-link and wrap their heads around why a   parameter is renamed  . &#32; Headbomb {t · c · p · b} 20:32, 1 October 2020 (UTC)

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

Module:Citation/CS1:
 * deprecate editors parameter; discussion
 * fix duplicate error message; discussion
 * auto-link bug fix; discussion
 * unify handling of error and maint messaging; upgrade disp_names maintenance messaging to error, change unrecognized display name values from invalid_param_value to disp_name; discussion
 * tweak &lt;name>-link and &lt;name>-mask interaction; discussion
 * fix given-missing-surname error message; discussion
 * check for more than 0 semicolons; discussion
 * orig-date preferred over orig-year, change metaparameters; discussion
 * error messaging for 'Wayback Machine' and other generic titles; discussion
 * use common function to render comma-separated lists; discussion
 * convert to  calls to avoid upvalue limit; discussion
 * move  to Module:Citation/CS1/Utilities/sandbox; discussion
 * add keyword "off" to distinguish from "none" in title; discussion
 * add override and disable capability for auto-linking; discussion, discussion, discussion, discussion
 * add trans-quote, script-quote, page(s)-quote; discussion
 * detect and report empty invalid parameters; discussion
 * deprecate last-author-amp; discussion
 * detect and report malformed interwiki links; discussion

Module:Citation/CS1/Configuration
 * deprecate editors parameter
 * add subject-mask parameters; discussion
 * unify handling of error and maint messaging; discussion
 * upgrade disp_names maintenance messaging to error; discussion
 * error messaging for 'Wayback Machine' and other generic titles
 * revise df_template_patterns{} table; discussion
 * add orig-date; discussion
 * remove support for series-separator; discussion
 * remove support for ignoreisbnerror, doi-broken, doi-inactive-date and rename embargo to pmc-embargo-date; discussion
 * convert inactive doi categories to proper maint cats; discussion
 * add support for missing aliases author-given#, author#-given, author-surname#, author#-surname, interviewer-given#, interviewer#-given, interviewer-surname#, interviewer#-surname, display-subjects; discussion
 * remove support for unused aliases displayeditors, editormask and enumerated forms; discussion
 * support ((accept-this-as-written)) syntax for used DOIs not matching our validity check; discussion, discussion, discussion
 * remove support for unused aliases notracking and no-cat, made no-tracking the canonical form for now; discussion
 * support ((accept-this-as-written)) syntax for invalid ISSNs; discussion
 * add year range abbreviated properties cat; discussion
 * add keyword "off" to distinguish from "none" in title; discussion, discussion
 * add trans-quote, script-quote, page(s)-quote
 * add name-list-style as preferred alias of name-list-format; discussion
 * bump pmc limit; discussion
 * detect and report malformed interwiki links

Module:Citation/CS1/Whitelist
 * deprecate editors parameter
 * add subject-mask parameters; deprecate non-hyphenated subjectlink params; discussion
 * add orig-date
 * remove support for series-separator
 * remove support for ignoreisbnerror, doi-broken, doi-inactive-date and rename embargo to pmc-embargo-date
 * remove support for interviewerlink and interviewermask; add support for missing aliases author-given, author-surname, author-given#, author#-given, author-surname#, author#-surname, interviewer-given#, interviewer#-given, interviewer-surname#, interviewer#-surname, display-subjects; discussion
 * moved transcript, transcript-format, transcripturl,transcript-url, and inset to unique arguments table; discussion
 * moved mailinglist, mailing-list to unique arguments table; discussion
 * remove support for unused aliases displayeditors, editormask and enumerated forms; discussion
 * deprecate displayauthors as well as editorlink, authormask and enumerated forms; discussion
 * deprecate ignore-isbn-error; discussion discussion
 * remove support for unused aliases notracking and no-cat, made no-tracking the canonical form for now
 * add trans-quote, script-quote, page(s)-quote
 * add name-list-style as preferred alias of name-list-format
 * deprecate last-author-amp

Module:Citation/CS1/Date validation
 * fix dmy-dmy and mdy-mdy month spelling error detection; detect same-season-to-same-season errors in s-s y dates; discussion
 * use common function to render comma-separated lists
 * add year range abbreviated properties cat; discussion

Module:Citation/CS1/Identifiers
 * auto-link bug fix
 * unify handling of error and maint messaging
 * disable auto-linking from doi & pmc when embargoed, broken, or fail validation; convert inactive doi categories to proper maint cats; discussion
 * fix PMC link composition to go through redirect also if still under embargo; discussion
 * use utilities.has_accept_as_written for doi, eissn, isbn, issn, sbn; discussion discussion, discussion

Module:Citation/CS1/Utilities
 * unify handling of error and maint messaging
 * create has_accept_as_written; discussion
 * add_prop_cat moved here from Module:Citation/CS1/sandbox

Module:Citation/CS1/styles.css
 * Remove PNG icons as WMF dropped basic support for IE8

Module:Citation/CS1/Suggestions —Trappist the monk (talk) 10:18, 3 October 2020 (UTC) 10:42, 4 October 2020 (UTC) (+empty unknowns) 14:04, 4 October 2020 (UTC) (+last-author-amp) 15:07, 5 October 2020 (UTC) (+interwiki link check)
 * suggest orig-date instead of orig-year parameter; discussion
 * add hints for removed parameter names ignoreisbnerror, doi-broken, doi-inactive-date and embargo; discussion and discussion
 * add hints for removed parameter names interviewerlink and interviewermask; discussion
 * add hints for some likely misspellings of parameter names which do not have hyphenated forms (eprint, inset, network, newsgroup, newspaper, postscript, surname, transcript, vauthors, veditors)
 * add hints for parameters from citation templates in Italian and Spanish Wikipedia
 * add hints for removed parameter names authorfirst, authorlast, authorgiven authorsurname, displayeditors, editorfirst, editorlast, editorgiven, editorsurname, editormask and enumerated variants; discussion and discussion
 * add hint for old parameters laysummary and lay-summary.
 * add hints for two likely misguesses forename and family due to our support for given/surname instead of given/family and forename/surname
 * added hints for removed aliases notracking and no-cat; discussion
 * , can you please add your changes to this list when you have time? – Jonesey95 (talk) 13:46, 3 October 2020 (UTC)
 * I think the list includes Editor Matthiaspaul's changes.
 * —Trappist the monk (talk) 14:31, 3 October 2020 (UTC)
 * I did a Find in the list above for the modified processing of "Jnr" and additional suffixes, but I did not see them mentioned.
 * Maybe that change is too trivial for a bullet, but it makes me wonder what else has been missed. – Jonesey95 (talk) 05:13, 4 October 2020 (UTC)
 * Alas, none of us are perfect. You and other editors have made additions to past lists when I have failed to include those items.  This time I also missed the empty unknown parameter detection (now included).
 * —Trappist the monk (talk) 10:42, 4 October 2020 (UTC)
 * —Trappist the monk (talk) 10:42, 4 October 2020 (UTC)

Error messages for generic titles
* "error messaging for 'Wayback Machine' and other generic titles" .. this one will probably generate community discussion due to the volume of red messages. Possible outcomes include:


 * The new no-title will come up and people will begin using no-title in some automated fashion to squelch errors. Then we don't know what is a legit no-title versus one that was a generic title needing filling in.
 * As in the past when a large payload of new error messages are introduced, the community requests they be lifted until a bot can clean up legacy cases (bots can and have determined page titles)
 * The community is OK with generic title placeholders + tracking cat, and doesn't want error messages.
 * Some mix of these or others.

Once it becomes a general VP/community issue developers can loose control of what they think is best due to RfC outcomes. if we are lucky that won't happen but given the scale of red errors it's a real possibility. There are also the other stakeholders involved IABot, Citation bot, WaybackMedic, Refill and others. Personally of the opinion we should try and reduce cases before adding red errors, or at least announce the intention and give the community some time (6 months etc) to respond. -- Green  C  17:03, 3 October 2020 (UTC)
 * It's that whole visibility thing isn't it? If editors don't know that the errors are there they won't know that something needs fixing.  Why does  list so many articles?  Because maintenance messaging is hidden unless editors turn it on.  According to this search, there are about 20 of us who have it turned on.  So, essentially, no one knows that there is a problem ...
 * It's worse for error messaging because the 'show all error messages' css that used to be at (until  where it was commented out) provided a way for editors to see hidden error messages.  According to this search, there are 7 of us who can see all error messages. Again, no one knows that there are problems.  We should fix Help:CS1 errors so that editors who care can learn how to show hidden error messages.
 * So, yeah, we can hide the generic title error messages but only "we few, we happy few" will know that they exist. You were a participant in the Wayback Machine discussions.  You know the numbers we were seeing for the various proposed generic titles.  Given that there are  articles, the few thousand articles that we found by the various searches do not seem to me to be an intolerable quantity.  Of course, all it takes is one "shrill shrieking" editor who perceives that the sky is falling and we'll be back at WP:AN and "spitted upon pikes" ...
 * Quotes from Shakespeare's Henry V
 * —Trappist the monk (talk) 18:37, 3 October 2020 (UTC)
 * Restored show-all-errors css at.
 * —Trappist the monk (talk) 18:46, 3 October 2020 (UTC)
 * ... and I've been reverted.
 * —Trappist the monk (talk) 19:02, 3 October 2020 (UTC)
 * We have no hidden errors so I have reverted your change. (Which is also why "for l10n/i18n" is in the wikitext comment.) The change which removed the 'show everything at all times' is here, and is not necessary because the only hidden citation notations are maintenance messages, for which the CSS of interest is provided. The set of people who can see everything is still that CSS, which is probably closer to this search. 350 is still abysmal (and includes editors who are no longer editing/have hidden everything). --Izno (talk) 19:10, 3 October 2020 (UTC)
 * Actually, we do: is hidden and  will be hidden.
 * —Trappist the monk (talk) 19:17, 3 October 2020 (UTC)
 * Ah, I forgot that one is hidden. Okay then. --Izno (talk) 19:23, 3 October 2020 (UTC)
 * Actually, we do: is hidden and  will be hidden.
 * —Trappist the monk (talk) 19:17, 3 October 2020 (UTC)
 * Ah, I forgot that one is hidden. Okay then. --Izno (talk) 19:23, 3 October 2020 (UTC)

Some maintenance items to upgrade to errors (2)
original discussion

cs1|2 does not support 'dynamic' error category names. It could, because we create some maintenance category names dynamically, it just doesn't because there has been no need.

In this case there is no need for five separate error categories when one will be sufficient. So, I have tweaked the code so that these errors will all be listed in the single category:.

—Trappist the monk (talk) 18:33, 5 October 2020 (UTC)
 * I guess there's my opinion. :) --Izno (talk) 19:11, 5 October 2020 (UTC)

"Revised by" parameter for Cite Encyclopedia
Would it be possible to add a "Revised by" parameter for Template:Cite encyclopedia? I'm speaking specifically of using it for Grove articles, such as this one, where having the person who revised the article as the second author wouldn't make sense (because they didn't add the bulk of the article) and having them as the editor wouldn't either (because they aren't the editor of the encyclopedia as a whole, which is how it would display). Aza24 (talk) 18:34, 5 October 2020 (UTC)
 * The catch-all parameter others is useful for edge cases like this. – Jonesey95 (talk) 21:06, 5 October 2020 (UTC)
 * I agree with using . I don't think cases with sources that name their revisors are common enough to make an entirely new parameter worthwhile. Glades12 (talk) 18:40, 6 October 2020 (UTC)
 * Indeed, I wasn't even aware that "others" existed, thank you both for letting me know. Aza24 (talk) 18:44, 6 October 2020 (UTC)

Labels for the "page" parameter
I must have missed the discussion/rationale for replacing the parameter labels p and pp, with page and pages respectively, in templates. Can you please point me to the relevant section(s)? Thanks. I just noticed Citation Bot making the related edits. 98.0.246.242 (talk) 22:44, 5 October 2020 (UTC)
 * If you mean that Citation bot is replacing p with page and pp with pages then you should take that up at User:Citation bot. All four of those parameters are legitimate aliases; page and pages are the canonical forms.
 * —Trappist the monk (talk) 22:48, 5 October 2020 (UTC)
 * The documentation disagrees with you. There is no mention of aliases for the parameter, and p or pp are not there at all. So, when was this change discussed? 98.0.246.242 (talk) 23:32, 5 October 2020 (UTC)
 * Good catch. I have updated the documentation. – Jonesey95 (talk) 00:02, 6 October 2020 (UTC)
 * You know, the cs1|2 documentation has never been great. If you can see how it might be improved, please do so.
 * The of Module:Citation/CS1/Whitelist has entries for p and pp.  The edit that appears to make aliases of p and page and of pp and pages is .  Was that discussed?  Don't know.  You might troll through the archives of this page and the Module talk:Citation/CS1 archives to see if it was discussed.
 * —Trappist the monk (talk) 00:03, 6 October 2020 (UTC)
 * Well, I am not averse to the change, only of the fact that I could not find explanation for it. This may have widespread consequences as the bot is working through what I would presume to be many citations using the abbreviated form. For many editors this may seem an unnecessary/pedantic cosmetic edit. On the other hand, in today's digital age, abbreviations that were common in the print era may seem antiquated. There is also the general argument that abbreviations should be avoided as non-user friendly and cryptic. And thanks to Jonesey for restoring the documentation. The absence of the abbreviations from the doc (they were there previously) shows intent. 98.0.246.242 (talk) 00:41, 6 October 2020 (UTC)
 * It is not clear what change you are talking about. If you object to the change that the Citation bot tool made, you should bring it up at the bot's talk page. As for "restoring" the documentation, I don't think the aliases were ever in the documentation before, or when they might have been removed; you might check that page's history to be sure. – Jonesey95 (talk) 02:28, 6 October 2020 (UTC)
 * Reread the OP. As for the documentation, p and pp were always there as aliases or labels, pick any revision before September 2020. They disappeared a few days ago whereupon the bot went to work. Which is fine except for one thing: why didn't we know about it? 65.88.88.69 (talk) 18:31, 6 October 2020 (UTC)
 * Are you talking about Template:Citation_Style_documentation/pages or some other page? If another page, please link to it. – Jonesey95 (talk) 20:17, 6 October 2020 (UTC)
 * This is getting interesting. There is Citation Style documentation/doc. In this one, "p" and "pp" appeared 2012-02-17 2012-02-16. There are also specific template docs which I presume would be the documentation editors would be more prone to check, as it is transcluded in the template itself. An example is Cite book/doc. First appearance of "p" and "pp" is a day earlier on on the same day 2012-02-16. And then we have the documentation subtemplate you edited (Citation Style documentation/pages) which was more or less dormant/inactive until relatively recently, and where "p" and "pp" never existed. All purport to be based on csdoc ofcourse, but it seems there is a perfect storm of version-control confusion here. Under the circumstances I cannot blame the bot for the edits indicated in the OP, or the lack of discussion. This is caught in the cobwebs of CS1 documentation and apparently there is a huge, insincere spider at the center of it all. Nobody can get at it. 64.61.73.84 (talk) 00:38, 7 October 2020 (UTC)
 * I mentioned csdoc above. In it, "p" and "pp" appear earlier, on 2011-12-21. This, the day the template was created. 64.61.73.84 (talk) 00:59, 7 October 2020 (UTC)
 * This is getting interesting. There is Citation Style documentation/doc. In this one, "p" and "pp" appeared 2012-02-17 2012-02-16. There are also specific template docs which I presume would be the documentation editors would be more prone to check, as it is transcluded in the template itself. An example is Cite book/doc. First appearance of "p" and "pp" is a day earlier on on the same day 2012-02-16. And then we have the documentation subtemplate you edited (Citation Style documentation/pages) which was more or less dormant/inactive until relatively recently, and where "p" and "pp" never existed. All purport to be based on csdoc ofcourse, but it seems there is a perfect storm of version-control confusion here. Under the circumstances I cannot blame the bot for the edits indicated in the OP, or the lack of discussion. This is caught in the cobwebs of CS1 documentation and apparently there is a huge, insincere spider at the center of it all. Nobody can get at it. 64.61.73.84 (talk) 00:38, 7 October 2020 (UTC)
 * I mentioned csdoc above. In it, "p" and "pp" appear earlier, on 2011-12-21. This, the day the template was created. 64.61.73.84 (talk) 00:59, 7 October 2020 (UTC)