User talk:Citation bot/Archive 4

This is essentially the same bug that was previously reported here but it still occurring. Boghog (talk) 19:48, 25 October 2014 (UTC)

 Not a bug. Or perhaps, only to the extent that you consider the "lastn" (etc.) parameters to be errors.

 There have been several discussions on stuffing "full author lists" into the [c]author[s] parameters (e.g.: Module_talk:Citation/CS1/Archive_9#Coauthors_2). That is certainly a dubious practice, and perhaps it is time to deprecate it. But this is not the place for that. ~ J. Johnson (JJ) (talk) 20:19, 25 October 2014 (UTC)

Absolutely a bug. It is redundant and unnecessary to add lastn parameters to these citations. Even if one wanted such parameters, the bot has done this incorrectly by not also adding the corresponding firstn parameters and removing the author parameter. Furthermore this "correct" behavior would be in clear violation of WP:CITEVAR. The use of a single author parameter to store full Vancouver formatted author lists is widely used and has long been accepted. The bot should not make changes to citations that were not asked for. What is dubious practice is firstn, lastn nonsense that clutters up Wikitext to generate meta data that no one uses or should use. Wikipedia is not a reliable source and this extends to citations. Boghog (talk) 21:05, 25 October 2014 (UTC)

There is no redundancy in separating a list of authors into individual authors, or splitting an author's last name (which is the basis for alphabetizing) from the rest. And if you think that the "lastn" and "firstn" parameters are "nonsense that clutters up Wikitext" you probably aren't happy using citation templates in the first place, so perhaps you should just use straight text, manually formatted. Except, of course, where use of templates has already been established. ~ J. Johnson (JJ) (talk) 22:13, 25 October 2014 (UTC)

Please look carefully at the diffs above. What citation bot has done is add lastn parameters and left the existing author parameter in place. As a consequence, author last names are now listed twice, once in the author parameter and again in lastn parameters. That is redundancy. You probably aren't happy using citation templates in the first place – nothing could be further from the truth. I quite often convert non-templated citations to {{cite journal}} templated citations (see this diff, there are thousands of similar examples in my edit history). Furthermore I maintain this template filling tool that generates {{cite journal}} formatted citations. Spliting author data between firstn, lastn parameters is an excessive level of data granularity that becomes unwieldy if there are a large number of authors. The Vancouver system provides a compact comma delimited list that unambiguously defines authors' first and last names. Boghog (talk) 05:40, 26 October 2014 (UTC)

Any use of any of the citation templates in the wikitext — i.e., within <ref>...</ref> tags — introduces clutter, so it is inconsistent for you object to "clutter" only in regard of author parameters. (As a side note: I find all bibliographic details clutter the text, which is why I put them into a separate section.) If your complaint is that, after adding "lastn" parameters, the bot failed to remove the corresponding "author" parameters, then I would concur that is a bug. But that is just what you are asking for: to retain the questionable "author" parameters. As to splitting the author names: that is not a bug, that is the intended result. ~ J. Johnson (JJ) (talk) 21:41, 26 October 2014 (UTC)

Good, we now both agree that there is a bug, but your solution is a clear violation of WP:CITEVAR. Storing full author lists in a single author parameter has not been deprecated and you have not explained why this use is questionable. Quite to the contrary, the use of "firstn, lastn" parameters becomes ridiculous if there are a large number of authors. Furthermore it is completely unnecessary if the author list follows the Vancouver system. The reason to use templates is so that the data can easily be parsed to provide a consistent rendering of the citations, wiki links, maintained by bots, etc. The Vancouver system author format can easily be parsed without the need for verbose firstn, lastn parameters. It just that the maintainers of Module:Citation/CS1 have resisted doing so. ({{vcite2 journal}} provides a possible way forward if functionality were added to this template to parse the author parameter to internally generate firstn, lastn parameters). I also occasionally use list defined references, but some editors object to these because it splits the text from the supporting sources. Regardless of whether these lists are a good idea or not, most articles don't use these. Finally, templates should be concise containing no more overhead than is necessary to do its job. I see the value of separate parameters for title, journal name, date, etc. but splitting author data into firstn, lastn parameters is an excessive and unnecessary degree of data granularity. So I disagree that I am being inconsistent. Boghog (talk) 03:35, 27 October 2014 (UTC)

Neither is deprecated. The right behaviour is to standardize on the predominant type, or failing that, leave the existing form. The bot is doing neither, but that is not the egregious part. The bot is populating the same author in both ways, creating the appearance of two authors of the same name! LeadSongDog come howl! 03:48, 27 October 2014 (UTC)

This is ridiculous, the bot needs to be halted until this issue is fixed. The bot shouldn't add lastn, firstn, author, authors and similar unless none of the above is specified already, that's it, I don't get why it's even a matter of discussion. Ihaveacatonmydesk (talk) 17:16, 27 October 2014 (UTC)

No, we don't agree. Or rather: I will agree there is a bug if you agree that it is in retention of misused "author" parameters. But obviously you don't. If you want to argue about apppropriate "data granularity" or "clutter", fine, but those aren't bugs, so this is the wrong place. ~ J. Johnson (JJ) (talk) 19:25, 27 October 2014 (UTC)

But yes, we do agree :-). We just need to replace |author= with |vauthors= and convince the maintainers of Module:Citation/CS1 to parse the later to internally create firstn, lastn parameters. Agreed? A brilliant idea that should make everyone happy. With this solution, we can reduce the clutter while still generating clean metadata and fully supporting |authorlinkn=, |display-authors=, etc. We can also introduce error checking to make sure the content of |vauthors= is compliant with the Vancouver system. Boghog (talk) 20:43, 27 October 2014 (UTC)

Sorry, still no. The core issue is "data granularity" (as you call it), and particularly whether multiple authors ("author lists") should be allowed in a single parameter. (And possibly including whether authors' names should be split into first/last.) Whether the parameter involved is |author=, |authors=, |coauthor=, |coauthors=, |vauthors=, or any other parameter, is immaterial. ~ J. Johnson (JJ) (talk) 21:32, 27 October 2014 (UTC)

It appears that you have taken the position that is self evident that that authors names must be split into different parameters with out providing a shred of evidence that this is true. The only rational reason for maintaining such a position is that is essential for parsing and error checking the data, and as I have explained above, neither is true. The Vancouver system provides an unambiguous method for parsing author data. When the data is formatted in this style, explicit firstn, lastn parameters become superfluous. These parameters can be generated internally on-the-fly. Boghog (talk) 22:00, 27 October 2014 (UTC)

No, but the issue of whether to split or not is deep enough it should be split off from the specifics of this bot's behavior. ~ J. Johnson (JJ) (talk) 20:51, 30 October 2014 (UTC)

You still have not explained why splitting is essentiall, but I would agree this is not the place to have this discussion. Boghog (talk) 07:51, 31 October 2014 (UTC)

@Boghog: "Just parse it automatically" is a bad idea. See http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ for why. —David Eppstein (talk) 21:50, 27 October 2014 (UTC)

I totally agree. That is precisely the reason for proposing |vauthors= so that this type of parsing is only done when this specific parameter is specified. Boghog (talk) 22:06, 27 October 2014 (UTC)

Another essential part of the proposal is error checking. The string would only be parsed if it conforms to the Vancouver system. If it does not conform, an error is thrown. Boghog (talk) 22:37, 27 October 2014 (UTC)

It's not a matter of agreeing or not agreeing: the page is fine here https://en.wikipedia.org/w/index.php?title=Wishful_thinking&oldid=584965755#References, then the bot intervenes and the templates are throwing errors https://en.wikipedia.org/w/index.php?title=Wishful_thinking&oldid=584966975#References. So it is a bug. Ihaveacatonmydesk (talk) 20:32, 27 October 2014 (UTC)

edit: I took that as an example but the examples boghog linked are better suited. My example just proves that this bot has a history of messing with authors parameters and the devs just won't (or can't) fix its behavior. Ihaveacatonmydesk (talk) 20:36, 27 October 2014 (UTC)

Thanks Ihaveacatonmydesk. I didn't realize that some of the bot edits resulted in throwing errors. The problem is worse than I thought. This needs to be fixed immediately. Boghog (talk) 20:55, 27 October 2014 (UTC)

That was an old version of the bot, that particular issue might have been fixed. Still, I consider the issues it creates now as dire as those I linked. A bot should never need this amount of babysitting. Ihaveacatonmydesk (talk) 21:04, 27 October 2014 (UTC)

I would agree that this bot has been troublesome, which is why I tend to block it from pages I work on. I would also favor blocking it. ~ J. Johnson (JJ) (talk) 20:55, 30 October 2014 (UTC)

I believe that the bug described here is a duplicate of one described above. I have found that e-mailing the bot's maintainer is more effective than posting here at eliciting a response to requests perceived as urgent. In the meantime, the undo link is always available to you, and there are instructions for blocking the bot from specific articles displayed on the bot's user page. – Jonesey95 (talk) 00:01, 28 October 2014 (UTC)

It's not the bot that's been troublesome, so much as that needed behaviour of the bot keeps being shifted by changes to the template code. That said, the bot hasn't made an edit since 25 October, so there's no panic needed. LeadSongDog come howl! 21:14, 30 October 2014 (UTC)

Even if the addition of lastn was not a bug (and it clearly is), firstn should be added. (And it's still happening.) — Arthur Rubin (talk) 10:49, 26 November 2014 (UTC)

Hello! Anyone there??? Boghog (talk) 20:43, 12 December 2014 (UTC)

Workaround based on {{vcite2 journal}}

As a follow-up to the above discussion, a new {{vcite2 journal}} template with an optional |vauthors= parameter has been recently created. This close variant of {{cite journal}} supports assignment of multiple authors in Vancouver format (a comma separated list containing no semi colons or periods) to a single |vauthors= parameter that generates clean author metadata. In all other respects, {{vcite2 journal}} is identical to {{cite journal}}. Hence I would request that instead of adding last2, last3, last4, ... parameters to citations with Vancouver style author format that the bot instead replace {{cite journal | author}} with {{vcite2 journal | vauthors}}. Boghog (talk) 16:02, 6 January 2015 (UTC)

Since support for |vauthors= has now been added to all Citation Style 1 templates, it is no longer necessary to use {{vcite2 journal}}. Hence it should only be necessary to replace the |author= parameter name with |vauthors=. Boghog (talk) 08:01, 5 September 2015 (UTC)

@Boghog, Materialscientist, and Ryan Kaldari (WMF): I've been looking into the way the bot handles and expands multiple authors. The main issues seem to come from an odd choice to reassign several parameters (including authors and coauthor(s)) to author2, which I have temporarily fixed. There are also some hiccups when expanding "et al."--for some formattings of author lists, the list of names is not recognized as a list, so it thinks the list is a single author and fetches the rest of the author names because it looks like there are missing parameters.

My questions:

• Are there any changes which should be made for multiple authors?
• How should "et al."/"and others" be handled? Should they be left as-is? Should they be expanded when adding authors as new parameters? Should they be expanded from an existing author parameter? Is there any current consensus on this?
• If there are no cases where changes should be made for multiple authors, I propose a rule of "if a single author-related parameter is already present, it should not be changed and no more author parameters should be added, even if the rest of the citation is expanded". How does this sound? --Fhocutt (WMF) (talk)

If there is any author information already in the citation template, I think it's a minefield for us to try to modify it, especially now that Vancouver-style author lists are part of the mix. Even if we wrote code to cover all the dozens of contingencies, one of them would probably break before the month was out. I like your suggested rule. It seems like the best plan to me. I'm even reluctant for us to support adding author data in the case where no author parameters are currently present, but I guess there's a lot less chance to totally screw up the citation in that case. The worst we can do is add authors in the wrong style for the article, which hopefully humans will not mind fixing too much. Ryan Kaldari (WMF) (talk) 01:34, 15 September 2015 (UTC)

I think that copy/pasting author names can be enough of a pain, particularly for citation styles that do use individual first/last params, that it's a good idea to automatically insert some author details, even if it's not in precisely the right way. How about et al.? I suspect that runs into arguments about how much data/metadata to include in citations, but if having the rest of the authors included automatically is useful then it might make sense for the bot to handle that case. It's a complicated enough one, though (can have all authors et al., first + rest of authors et al., various coauthor params...) that it may be best to just not touch it. Thoughts? --Fhocutt (WMF) (talk) 02:51, 15 September 2015 (UTC)

First do no harm. I agree that it is best not to touch it. Boghog (talk) 03:45, 15 September 2015 (UTC)

I am hopeful that you are aware of |display-authors=etal in the CS1 style. If you find more authors in a particular citation, maybe you should just leave the existing authors alone and then add that, if display-authors isn't already set. I--of course--prefer more metadata to less, so, that's a separate solution. --Izno (talk) 03:48, 15 September 2015 (UTC)

(edit conflict) Using "et al." in an author parameter will put an article in Category:CS1 maint: Explicit use of et al., a maintenance category. The proper way to generate "et al." in a citation is to use the |display-authors= or |display-editors= parameter. See {{Cite_web#Display_options}} for more details.

As for your proposed rule, I would rather see the bot remove the content of a lone author parameter and then fill in all of the authors. Editors could then choose to display as many as they want by adding |display-authors=. If you go with the proposed rule, it would need to be accompanied by a way to force filling in additional author names. For example, with some versions of the Citation Bot, you could often remove the content of one or more parameters to persuade the bot to re-fill those parameters.

On a similar note, see at least one bug report section above about Citation Bot's limit of four editors. I can explain that to you at length in a separate thread if you like; the "Display options" section linked above has a short explanation. – Jonesey95 (talk) 03:51, 15 September 2015 (UTC)

I'd prefer this: fill in all authors if there are none (using the most "stable" format), don't touch authors if anything is already filled in. This way the bot will not generate new errors. Editors willing to refill authors could blank the author fields, and those who prefer other author formats might use Help:Citation_tools or ask to create additional gadgets like those. Materialscientist (talk) 04:04, 15 September 2015 (UTC)

@Materialscientist: How are those editors to be alerted to the fact that other authors exist? Perhaps a hidden comment appended to the existing author field? LeadSongDog come howl! 18:58, 15 September 2015 (UTC)

Just click the doi/pmid/etc. Materialscientist (talk) 22:27, 15 September 2015 (UTC)

@LeadSongDog: The "et al." in one or more of the author parameters, and the presence in the maintenance category, should indicate that there are more authors. --Fhocutt (WMF) (talk) 21:07, 15 September 2015 (UTC)

Well, "just click" does nothing in the edit window, and only comes into play once rendered. Worse, most editors will simply presume the existing citation is already correct. They need some cue to tell them to check "this" one, of all the citations in an article. Where the bot detects a discrepancy between the citation and the crossref/pubmed/etc database, it should drop a hint for humans, since it won't be making the revision itself. LeadSongDog come howl! 03:35, 16 September 2015 (UTC)

The proper place for et al. is not the author or editor name-holding parameters; use |display-authors=etal and or |display-editors=etal.

—Trappist the monk (talk) 21:16, 15 September 2015 (UTC)

I'm aware of this. However, per discussion above this tool is going to leave that for humans or less fragile/better maintained citation tools to fix. --Fhocutt (WMF) (talk) 21:43, 15 September 2015 (UTC)

Yes, good idea. I have cleaned up not a few instances of mushedtogetherauthors and find that there are enough subtleties that I think any parsing of authors should be the specific task of a dedicated, specialized bot. Similarly for the presence of explicit "et al.": that likely requires additional information beyond what is immediately present, which is probably more of stretch than Citation bot should attempt. ~ J. Johnson (JJ) (talk) 19:21, 16 September 2015 (UTC)

Comparison of author parameters
Feature	|lastn=, |firstn=	|vauthors=	|authors=
Clean author metadata
|author-link= support
|displayauthors= support
Author error checking
Compact

@J. Johnson: Please consider using the |vauthors= parameter (see table to the right) that is supported by CS1 style citation templates and easily parses Vancouver style comma delimited "mushedtogetherauthors". Why insist on an "absurdnumberofsuperfluousauthorparameters"? (see rationale) Boghog (talk) 20:05, 16 September 2015 (UTC)

Boghog: |vauthors= is specific for Vancouver style, which I – and most other editors outside of the medical topics – do not use. I would also dispute your implicit claim that vauthors= provides "clean author metadata", or that last/first does not allow "author error checking". I also deem the rationale for vauthors to be incorrect. However, all that is off-topic for this discussion. My point is that tackling any kind of "authors" problem is sufficiently challenging that it ought to be handled separately from other kinds of cleanup. ~ J. Johnson (JJ) (talk)

@J. Johnson: I would dispute your implicit claim that |vauthors= provides clean author metadata – that is not an implicit claim, that is an explicit claim (see explanation) that really does work. Please test |vauthors= with a metadata harvester like Zotero. Author first and last names are cleanly parsed and passed on to external citation manager applications. I would dispute .. last/first does not allow "author error checking" There is no standardization of the rendered output of the |firstn= parameter whereas |vauthors= insists on a standard format (first initial + an optional middle initial and in no cases, periods). I agree that a separate bot that respects WP:CITEVAR should handle author parameter cleanup. Boghog (talk) 21:21, 16 September 2015 (UTC)

Again, this is not the place to discuss the relative merits of vauthors=, etc. But I am pleased we agree on having a separate bot for handling authors. ~ J. Johnson (JJ) (talk) 21:31, 16 September 2015 (UTC)

Without |DUPLICATE_page= parameter:

Dahl, E; Naustvoll, LJ; Gustad, E (14 Aug 2012). "Monitoring of Dinophysis species and diarrhetic shellfish toxins in Flødevigen Bay, Norway: inter-annual variability over a 25-year time-series". Food Additives & Contaminants: Part A. 29 (10): 1605. doi:10.1080/19440049.2012.714908. PMID 22891979. {{cite journal}}: More than one of |pages= and |page= specified (help)

with |DUPLICATE_page= parameter:

Dahl, E; Naustvoll, LJ; Gustad, E (14 Aug 2012). "Monitoring of Dinophysis species and diarrhetic shellfish toxins in Flødevigen Bay, Norway: inter-annual variability over a 25-year time-series". Food Additives & Contaminants: Part A. 29 (10): 1605. doi:10.1080/19440049.2012.714908. PMID 22891979. {{cite journal}}: More than one of |pages= and |page= specified (help); Unknown parameter |DUPLICATE_page= ignored (help)

—Trappist the monk (talk) 12:11, 26 June 2016 (UTC)

Has the older messaging been turned off? A citation with a duplicate date that I corrected here doesn't display the old message that duplicate dates are present in a particular citation, in a version previous to the bot correction. However, the first, misused, date value is still overwritten by the second. The new marking of duplicate page/date/etc. with a specious parameter is actually more helpful, as it points out the specific citation involved (try searching a long article, without the requisite knowledge of regexes, to find such duplication otherwise). Dhtwiki (talk) 04:16, 28 June 2016 (UTC)

If you go to that older version and click edit and then click Show preview, you will get the more-than-one-value-for-the-"date"-parameter error message. Is that what you mean by the 'old message'?

MediaWiki gives only one of any parameter to any template so the templates themselves cannot know that there is a duplicate parameter. In the particular case of the cs1|2 templates, they can detect the use of aliases (|page= is more-or-less an alias of |pages=) because the parameter names are different. The bot is unnecessarily duplicating the cs1|2 redundant parameter detection and messaging when it adds the |DUPLICATE_page= parameter.

Because duplicate parameters (where the parameter names are the same) are caught by MediaWiki and categorized in Category:Pages using duplicate arguments in template calls, it seems to me that the bot should stop adding the |DUPLICATE_<whatever>= parameter to cs1|2 templates.

—Trappist the monk (talk) 10:55, 28 June 2016 (UTC)

Yes, it must be the message in Preview mode, and I missed it with the edit in question. However, that is a too-general warning. I recently painstakingly looked through one lengthy article with a similar, Preview-mode warning for a duplicate date in cite-news, without finding the duplication. The presence of a bot that makes changes to a particular citation, although error-generating, seems to me to be an improvement. Dhtwiki (talk) 11:45, 28 June 2016 (UTC)

I agree that error messages at the top of the preview are only vaguely helpful. There are tools listed at Category:Pages using duplicate arguments in template calls that might be helpful the next time you are confronted with that kind of error. But duplicate parameters of the same name are not the issue of this bug report. Having the bot flag parameters with identical names can be beneficial; not so beneficial when the templates are already flagging aliases.

—Trappist the monk (talk) 13:32, 28 June 2016 (UTC)

A quick look at the bot's contribs shows it wreaking havoc with "unknown parameter" errors. I have no idea what it's trying to accomplish, but I'm fairly certain this is not an improvement. ―Mandruss ☎ 04:42, 30 June 2016 (UTC)

I reverted one case and the bot returned 4 minutes later and did it again. Bot needs to be shut down now please. ―Mandruss ☎ 04:50, 30 June 2016 (UTC)

The bot is simply turning an invisible error into a visible error, moving the article from one error category, where the error is difficult to find and fix, to another, where the error is easier to find and fix. This is not "wreaking havoc". Also, I suspect that this "bot" is being activated by a human editor, not running automatically on its own, but I don't know if there is a way to know this. – Jonesey95 (talk) 05:00, 30 June 2016 (UTC)

Yeah, I was premature. I now understand the rationale, I retract my statements, and I have fixed the duplicate in that one case. But this discussion should have occurred before implementation, not after, as there is more than one way to skin a cat. I'm not at all convinced that a more-visible "unknown parameter" error is better than a less-visible, but at least descriptive, "duplicate parameter" error. I'm not aware of any other cases where errors are flagged by introducing invalid parameters into template transclusions. This is not the only option available to us. ―Mandruss ☎ 05:08, 30 June 2016 (UTC)

Citation bot has had this feature for many years, but this |DUPLICATE_foo= stuff was only output when someone ran Citation bot manually on an article. That's why I think that someone is manually running the bot, essentially as a script, against the duplicate parameter category, which has about 5,000 articles left in it (down from well over 100,000 when the category was created). As I said, I don't know if there is a way of verifying that or knowing who is doing it.

In any event, I am finding the "unsupported parameter" versions of the citations much easier to fix than the articles in the "duplicate parameter" category, because you can do a find for "dupl" in the article and jump immediately to the problem citation. This one was cute: reference 27 had an ISBN in a duplicated title parameter for at least six years, displaying the ISBN instead of the title. Citation bot helped us find and fix the problem. – Jonesey95 (talk) 05:33, 30 June 2016 (UTC)

I don't dispute that this is an adequate solution, maybe the best one, for an editor with 7 years and 70K edits, who understands the technical background (you). Maybe even so for one with 3 years and 25K edits who understands the technical background (me). Not necessarily for the other 80%+ of the editing population. For example, this bot could follow the example of Cyberbot II and post an explanation on the article's talk page, leaving the citation alone. The explanation could list both duplicate parameter values, making the cite almost as easy to locate with browser Find.
As currently written, the bot has to arbitrarily choose one of the values to invalidate, and it may be the wrong one. It was the wrong one in the case I corrected: the other |title= value was not a title but an editorial description of the page. So the bot's bold edit will be an improvement for about 50% of cases. In the other half, the bot will eliminate an error and replace it with incorrect information. Human attention is needed in each case, and this doesn't get it except for the relatively rare cases where an editor knows what this odd use of "unknown parameter" means, knows how to fix it, and cares to take the time to fix it. The talk page is more visible than little errors in the References section, and it provides space for clear explanation. ―Mandruss ☎ 06:03, 30 June 2016 (UTC)

Without |DUPLICATE_page= parameter:

Dahl, E; Naustvoll, LJ; Gustad, E (14 Aug 2012). "Monitoring of Dinophysis species and diarrhetic shellfish toxins in Flødevigen Bay, Norway: inter-annual variability over a 25-year time-series". Food Additives & Contaminants: Part A. 29 (10): 1605. doi:10.1080/19440049.2012.714908. PMID 22891979. {{cite journal}}: More than one of |pages= and |page= specified (help)

with |DUPLICATE_page= parameter:

Dahl, E; Naustvoll, LJ; Gustad, E (14 Aug 2012). "Monitoring of Dinophysis species and diarrhetic shellfish toxins in Flødevigen Bay, Norway: inter-annual variability over a 25-year time-series". Food Additives & Contaminants: Part A. 29 (10): 1605. doi:10.1080/19440049.2012.714908. PMID 22891979. {{cite journal}}: More than one of |pages= and |page= specified (help); Unknown parameter |DUPLICATE_page= ignored (help)

—Trappist the monk (talk) 12:11, 26 June 2016 (UTC)

Has the older messaging been turned off? A citation with a duplicate date that I corrected here doesn't display the old message that duplicate dates are present in a particular citation, in a version previous to the bot correction. However, the first, misused, date value is still overwritten by the second. The new marking of duplicate page/date/etc. with a specious parameter is actually more helpful, as it points out the specific citation involved (try searching a long article, without the requisite knowledge of regexes, to find such duplication otherwise). Dhtwiki (talk) 04:16, 28 June 2016 (UTC)

If you go to that older version and click edit and then click Show preview, you will get the more-than-one-value-for-the-"date"-parameter error message. Is that what you mean by the 'old message'?

MediaWiki gives only one of any parameter to any template so the templates themselves cannot know that there is a duplicate parameter. In the particular case of the cs1|2 templates, they can detect the use of aliases (|page= is more-or-less an alias of |pages=) because the parameter names are different. The bot is unnecessarily duplicating the cs1|2 redundant parameter detection and messaging when it adds the |DUPLICATE_page= parameter.

Because duplicate parameters (where the parameter names are the same) are caught by MediaWiki and categorized in Category:Pages using duplicate arguments in template calls, it seems to me that the bot should stop adding the |DUPLICATE_<whatever>= parameter to cs1|2 templates.

—Trappist the monk (talk) 10:55, 28 June 2016 (UTC)

Yes, it must be the message in Preview mode, and I missed it with the edit in question. However, that is a too-general warning. I recently painstakingly looked through one lengthy article with a similar, Preview-mode warning for a duplicate date in cite-news, without finding the duplication. The presence of a bot that makes changes to a particular citation, although error-generating, seems to me to be an improvement. Dhtwiki (talk) 11:45, 28 June 2016 (UTC)

I agree that error messages at the top of the preview are only vaguely helpful. There are tools listed at Category:Pages using duplicate arguments in template calls that might be helpful the next time you are confronted with that kind of error. But duplicate parameters of the same name are not the issue of this bug report. Having the bot flag parameters with identical names can be beneficial; not so beneficial when the templates are already flagging aliases.

—Trappist the monk (talk) 13:32, 28 June 2016 (UTC)

A quick look at the bot's contribs shows it wreaking havoc with "unknown parameter" errors. I have no idea what it's trying to accomplish, but I'm fairly certain this is not an improvement. ―Mandruss ☎ 04:42, 30 June 2016 (UTC)

I reverted one case and the bot returned 4 minutes later and did it again. Bot needs to be shut down now please. ―Mandruss ☎ 04:50, 30 June 2016 (UTC)

The bot is simply turning an invisible error into a visible error, moving the article from one error category, where the error is difficult to find and fix, to another, where the error is easier to find and fix. This is not "wreaking havoc". Also, I suspect that this "bot" is being activated by a human editor, not running automatically on its own, but I don't know if there is a way to know this. – Jonesey95 (talk) 05:00, 30 June 2016 (UTC)

Yeah, I was premature. I now understand the rationale, I retract my statements, and I have fixed the duplicate in that one case. But this discussion should have occurred before implementation, not after, as there is more than one way to skin a cat. I'm not at all convinced that a more-visible "unknown parameter" error is better than a less-visible, but at least descriptive, "duplicate parameter" error. I'm not aware of any other cases where errors are flagged by introducing invalid parameters into template transclusions. This is not the only option available to us. ―Mandruss ☎ 05:08, 30 June 2016 (UTC)

Citation bot has had this feature for many years, but this |DUPLICATE_foo= stuff was only output when someone ran Citation bot manually on an article. That's why I think that someone is manually running the bot, essentially as a script, against the duplicate parameter category, which has about 5,000 articles left in it (down from well over 100,000 when the category was created). As I said, I don't know if there is a way of verifying that or knowing who is doing it.

In any event, I am finding the "unsupported parameter" versions of the citations much easier to fix than the articles in the "duplicate parameter" category, because you can do a find for "dupl" in the article and jump immediately to the problem citation. This one was cute: reference 27 had an ISBN in a duplicated title parameter for at least six years, displaying the ISBN instead of the title. Citation bot helped us find and fix the problem. – Jonesey95 (talk) 05:33, 30 June 2016 (UTC)

I don't dispute that this is an adequate solution, maybe the best one, for an editor with 7 years and 70K edits, who understands the technical background (you). Maybe even so for one with 3 years and 25K edits who understands the technical background (me). Not necessarily for the other 80%+ of the editing population. For example, this bot could follow the example of Cyberbot II and post an explanation on the article's talk page, leaving the citation alone. The explanation could list both duplicate parameter values, making the cite almost as easy to locate with browser Find.
As currently written, the bot has to arbitrarily choose one of the values to invalidate, and it may be the wrong one. It was the wrong one in the case I corrected: the other |title= value was not a title but an editorial description of the page. So the bot's bold edit will be an improvement for about 50% of cases. In the other half, the bot will eliminate an error and replace it with incorrect information. Human attention is needed in each case, and this doesn't get it except for the relatively rare cases where an editor knows what this odd use of "unknown parameter" means, knows how to fix it, and cares to take the time to fix it. The talk page is more visible than little errors in the References section, and it provides space for clear explanation. ―Mandruss ☎ 06:03, 30 June 2016 (UTC)