User talk:Citation bot

From Wikipedia, the free encyclopedia
Jump to: navigation, search


Note that the bot's maintainer can go weeks without logging in to Wikipedia and can no longer devote extensive time to bot maintenance. If a major bug arises and goes unnoticed, it may go unnoticed; as such, important matters may warrant an e-mail. Breaking changes to templates maintained by the bot will be more readily addressed if advance notice can be given.

Please click here to report an error.

This bot is only periodically maintained and new feature requests are no longer being considered. The code is open source and interested parties are invited to assist with the operation and extension of the bot.

Bot should add more than four editors and add displayeditors=29 if there are exactly 4 editors[edit]

Bot should add more than four editors and add displayeditors=29 if there are exactly 4 editors

Status
new bug / feature request (two related features in one request)
Reported by
Jonesey95 (talk) 23:49, 21 September 2013 (UTC)
Type of bug
Improvement
Actual / expected output
Bot limits editors to four first names and four last names.
Bot should retrieve all editors and add "displayeditors=29" parameter if there are exactly four editors.
Replication instructions
Run the citation expander on a citation that has four editors listed but more than four editors in the original work.
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer
Remove four-editor limit from bot code and add "displayeditors=29" to citations with exactly four authors.

Discussion

The bot should add "displayeditors=29" if there are exactly four editors to avoid the Lua error described for exactly 9 authors above. – Jonesey95 (talk) 23:49, 21 September 2013 (UTC)

Journal Capitalization[edit]

Capitalization

Status
feature request
Reported by
Saimondo (talk) 16:21, 3 August 2014 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
Bot writes for example "Molecular and cellular biology" instead of "Molecular and Cellular Biology" by autofilling with PMID 9858585
Link
https://en.wikipedia.org/w/index.php?title=Template%3ACite_pmid%2F9858585&diff=619550325&oldid=604044373
Replication instructions
autocomplete with PMID 9858585
We can't proceed until
Agreement on the best solution
Requested action from maintainer

Discussion

Extended content

Data on NCBI seems to be ok: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC83919/ where the Journal is written as "Mol Cell Biol." on the webpage and as "MOLECULAR AND CELLULAR BIOLOGY" in the full text pdf.

What to do in those cases? Include "Molecular and Cellular Biology" in: https://en.wikipedia.org/wiki/User:Citation_bot/capitalisation_exclusions in sush cases?

The same with

-"The Journal of biological chemistry" e.g. PMID 9858585

-"The Journal of cell biology" e.g. PMID 9763423

an other cases seen in https://en.wikipedia.org/wiki/Special:RecentChangesLinked/Category:Cite_doi_templates ? Thanks--Saimondo (talk) 16:21, 3 August 2014 (UTC)

Actually PubMed lists the journal as "Molecular and cellular biology" in the webpage meta data. A very minor case of GIGO. AManWithNoPlan (talk) 02:31, 4 August 2014 (UTC)
Perhaps its worth quoting the University of Chicago Manual of Style (14th ed.) on this matter:
"In regular title capitalization, also known as headline style, the first and last words and all nouns, pronouns, adjectives, verbs, adverbs, and subordinating conjunctions (if, because, as, that, etc.) are capitalized. Articles (a, an, the), coordinating conjunctions (and, but, or, for, nor), and prepositions, regardless of length are lowercased unless they are the first or last word of the title or subtitle. The to in infinitives is also lowercased."
On the other hand, it is common in library cataloging following MARC format to capitalize only the initial word, proper nouns, and, if the title begins with an article, that article and the following noun.
Wikipedia citations should follow citation style, rather than library cataloging style. In this case, the appropriate form would be "Molecular and Cellular Biology". The Wikipedia Manual of Style provides much the same advice on the capitalization of titles. SteveMcCluskey (talk) 18:40, 4 August 2014 (UTC)
I am not very familiar with PHP (the language that Citation Bot is coded in), but it would appear that there is a mb_convert_case function:
 $str = mb_convert_case($str, MB_CASE_TITLE, "UTF-8");
that can transform a string into title case (i.e., capitalize the first and last words of the title and all nouns, pronouns, adjectives, verbs, adverbs, and subordinating conjunctions). This function would probably work well for most journal names. Boghog (talk) 19:15, 4 August 2014 (UTC)
This should be easy to implement, but I anticipate that some time down the line it will upset someone. Before I implement it, could we establish consensus and file a bot approval request if necessary? Thanks. Martin (Smith609 – Talk) 08:49, 25 August 2014 (UTC)
How about your implement it for adding journal titles, but don't implement it for changing existing entries. Eventually, the list of titles that violate the rules will be built up, and then you can make it is a fix for existing journal titles. AManWithNoPlan (talk) 01:48, 4 September 2014 (UTC)

You are of course right, it´s no error it´s the catalog style NCBI is using. I don´t have the complete overview what capitalization format is obtained by the doi or issn vs pmid queries. But if you use the cite-> templates-> cite journal option here in the edit window and use autofill with the doi:10.1128/MCB.00698-14 you get "Molecular and Cellular Biology" if you use the same publications PMID 25022755 with autofill you get "Molecular and cellular biology". If capitalization means also harmonization I think few wikipedians would be against it.

Furthermore, as far as I understand https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Titles_of_works the capitalization format like above should be ok (I have the impression that most journals use capitalization for their own names on their homepages/pdfs). Should we ask on the Manual of style talk page to see if there´s a consensus for capitalization? In case someone is interested, here is a recent reply of an email I (re-)sent to NCBI some time ago:

"...Standard cataloging requires that the first word in the full journal title begins with an upper case letter and remaining words (except for proper nouns) begin with lower case. Journal title abbreviations begin with all upper-case letters. I checked the XML data for several journals and found that each of the title listed in this manner. You can see several examples at the bottom of this document:

Fact Sheet: Construction of the National Library of Medicine Title Abbreviations http://www.nlm.nih.gov/pubs/factsheets/constructitle.html Sincerely, Ellen M. L. ...

-Original Message-

Dear NCBI Team, in the xml data of a specific article https://www.ncbi.nlm.nih.gov/pubmed/9858585?dopt=Abstract&report=xml&format=text the journal name is written "Molecular and cellular biology" and the abbreviation is "Mol Cell Biol.". I think the correct journal name should be "Molecular and Cellular Biology" as written on the journal homepage http://mcb.asm.org/content/19/1/612.long ." Saimondo (talk) 17:29, 10 September 2014 (UTC)

https://en.wikipedia.org/wiki/User:Citation_bot/capitalisation_exclusions seems to be being ignored by the latest bot also. AManWithNoPlan (talk) 16:12, 27 September 2015 (UTC)
So, the conclusion is
  1. covert journal names to title case when adding them
  2. Add back in exclusions list support https://en.wikipedia.org/wiki/User:Citation_bot/capitalisation_exclusions

AManWithNoPlan (talk) 20:43, 2 January 2016 (UTC)

Bot does not handle aliases[edit]

Status
new bug
Reported by
It Is Me Here t / c 11:31, 3 September 2014 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
If an instance of {{cite journal}} has no |issue=φ, the Bot adds it, even if the {{cite journal}} already has |number=φ, throwing up a red error in read mode.
It should do nothing (bypass {{cite journal}}s with |number=φ).
Link
http://en.wikipedia.org/w/index.php?title=Template:Cite_doi/10.2307.2F1477803&diff=623994852&oldid=623994152
We can't proceed until
Agreement on the best solution
Requested action from maintainer

Discussion


The bot also adds "pages=" when there is already a "p=" or "pp=" or "page=" card. AManWithNoPlan (talk) 21:00, 26 December 2015 (UTC)

...or "at=". Lithopsian (talk) 16:36, 29 December 2015 (UTC)
https://en.wikipedia.org/w/index.php?title=Calutron&type=revision&diff=688482098&oldid=688481880 Hawkeye7 (talk) 07:02, 1 November 2015 (UTC)
Another example of pages= being added when page= already exists: https://en.wikipedia.org/w/index.php?title=Inflow_%28meteorology%29&diff=next&oldid=698774275
Issue and number too: https://en.wikipedia.org/w/index.php?title=Ferruccio_Busoni&diff=prev&oldid=724431335 AManWithNoPlan (talk) 20:04, 16 July 2016 (UTC)

Bot unnecessarily adding last2, last3, last4, ... parameters[edit]

... to citations that already contain a complete author list

Status
unresolved ongoing bug
Reported by
Boghog (talk) 19:48, 25 October 2014 (UTC)
Type of bug
Deleterious
Actual / expected output
When the full author list is stored in |author=, the bot adds |last2=, |last3=, |last4=, ... without the corresponding |first2=, |first3=, |first4=, ...
If |author= contains the full author list, then the bot should not add |last2=, |last3=, |last4=, ... parameters
Link
diff, diff, diff, diff, diff, diff, ...
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer
If |author= contains a complete author list, do not unnecessarily add |last2=, |last3=, |last4=, ...

Discussion

Extended content

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}}[edit]

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)

Handling multiple authors[edit]

Extended content

@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 Yes Yes No
|author-link= support Yes Yes No
|displayauthors= support Yes Yes No
Author error checking No Yes No
Compact No Yes Yes
@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)


Comments cause trouble[edit]

Status
new bug
Reported by
Jonesey95 (talk) 02:54, 9 November 2014 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
Bot changed |publisher= to |DUPLICATE_publisher= in the absence of a duplicate publisher parameter
Bot should not do that.
Link
https://en.wikipedia.org/w/index.php?title=Fathima_Beevi&diff=629715024&oldid=610463414
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion

As far as I can tell, there were no duplicated parameters when the bot did its edit. – Jonesey95 (talk) 02:54, 9 November 2014 (UTC)

How did you get this? The bot is not currently working.--Auric talk 13:49, 9 November 2014 (UTC)
The edit is date-stamped 15 October 2014. I just discovered it yesterday while going through Category:Pages with citations using unsupported parameters. – Jonesey95 (talk) 15:48, 9 November 2014 (UTC)
Here's another similar one, adding DUPLICATE to |archiveurl= and |archivedate=. – Jonesey95 (talk) 19:53, 10 November 2014 (UTC)
This looks like it related to comments in the references in all cases. This appears to be a common thread in bot bugs on this page. AManWithNoPlan (talk) 04:45, 1 February 2015 (UTC)

Adding bogus |year= https://en.wikipedia.org/w/index.php?title=Wealden_Line&diff=629805699&oldid=629545497

This doesn't expand: typical.{{ref doi|10.1111/j.1096-3642.1950.tb01699.x}} listed [http://www.iucnredlist.org/ List<!-- Bot -->]

DUPLICATE_ added: https://en.wikipedia.org/w/index.php?title=509th_Composite_Group&diff=636859536&oldid=636220208

DUPLICATE_ added: https://en.wikipedia.org/w/index.php?title=Shapley%E2%80%93Folkman_lemma&diff=655089982&oldid=651991293

This bug appears to still be present in the current version, as of this date stamp. Pinging Fhocutt (WMF). – Jonesey95 (talk) 03:46, 22 September 2015 (UTC)
Give it another try? I tested the dev version (now the actual version) on testwiki and it didn't add DUPLICATE: https://test.wikipedia.org/w/index.php?title=User%3AFhocutt_%28WMF%29%2FCitation_bot_test&type=revision&diff=243602&oldid=243601 . --Fhocutt (WMF) (talk) 23:04, 9 October 2015 (UTC)
It's still doing it here on en.WP. – Jonesey95 (talk) 23:15, 9 October 2015 (UTC)

issue vs. volume confusion for journals with no volumes[edit]

Status
feature request
Reported by
All the best: Rich Farmbrough01:38, 11 November 2014 (UTC).
Type of bug
Inconvenience
Actual / expected output
for the journal ZookKeys changes the issue number to a volume number.
Should understand that this number is an issue number with this particular journal
Link
https://en.wikipedia.org/w/index.php?title=Aegista_diversifamilia&diff=630393100&oldid=629974617 - see discussion here
Replication instructions
A similar ZooKeys doi template
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer
Build in specific knowledge of this journal's numbering scheme. Possibly a list of one, unless and until other similar items are found.

Discussion

http://search.crossref.org/?q=10.3897/zookeys.445.7778 The cross-ref data is wrong. So, it is not a bot bug, but the bot could easily fix it. AManWithNoPlan (talk) 19:15, 2 October 2015 (UTC)

The bot need to add special code for journals like this. And then internally store a list of of such journals. AManWithNoPlan (talk) 00:13, 3 January 2016 (UTC)

Edits citations inside of nowiki tags[edit]

Edits citations inside of nowiki tags

Status
new bug
Reported by
Izno (talk) 20:55, 29 April 2015 (UTC)
Type of bug
Inconvenience
Actual / expected output
The bot removed an accessdate from a citation without a URL (correctly) where the citation was used an example (and in this case happened to be wrapped in <nowiki>...</nowiki>.
I'm not sure, but I think my suggestion is that the bot should not touch citations inside <nowiki>...</nowiki>.
Link
//en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&curid=34112310&diff=659936244&oldid=659925010
We can't proceed until
Agreement on the best solution
Requested action from maintainer

Discussion


Duplicating jstor[edit]

Duplicate jstor parameter bug

Status
new bug
Reported by
Frietjes (talk) 14:11, 23 May 2015 (UTC)
Type of bug
Deleterious
Actual / expected output
Bot replaces a jstor url with a jstor parameter, but does not check to see if there is already a jstor parameter in the citation. hence, if there is already a blank jstor parameter, the jstor link is effectively deleted.
Bot should first remove the empty jstor parameter, and/or any completely duplicate jstor parameters (i.e., jstor parameters with the exact same value).
Link
http://en.wikipedia.org/w/index.php?title=Noye's_Fludde&type=revision&diff=663532320&oldid=637085644
Replication instructions
create a citation with both a jstor url and a jstor parameter in the citation template
We can't proceed until
Requested action from maintainer

Discussion


Special characters in data need escaped[edit]

Bot should escape square and pipes brackets in |title= and |authors=

Status
feature request
Reported by
Jonesey95 (talk) 03:42, 22 September 2015 (UTC)
Type of bug
Inconvenience
Actual / expected output
Link
https://en.wikipedia.org/w/index.php?title=Latamoxef&type=revision&diff=682190504&oldid=682190396
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion

This is a pretty obscure bug, but if someone wanted to fix it, they could run the title through a regex to look for "[[" and replace it with "[<!-- -->[" (as was done on that article). Kaldari (talk) 20:56, 22 September 2015 (UTC)

And pipes too: https://en.wikipedia.org/w/index.php?title=User%3AJonesey95%2Fsandbox2&diff=prev&oldid=694077824

The problem is that the source of the metadata, http://adsabs.harvard.edu/abs/1991bsc..book.....H, has a vbar within an author's name, I think erroneously as the author in question doesn't use a middle name or initial, and the bot doesn't recognize it and quote it to prevent it becoming a parameter delimiter. So I think there are really two issues here: (1) bad data elsewhere that we can't do much about, and (2) better bot handing of special characters in external data. —David Eppstein (talk) 21:39, 6 December 2015 (UTC)
I have added a diff in the bug description above. When vertical bars occur in URLs, replace each vertical bar with %7c. When vertical bars occur in parameter values that are not URLs, replace each vertical bar with &#124;. – Jonesey95 (talk) 23:46, 6 December 2015 (UTC)
Yes that's it. Sounds like a sensible solution. I've not seen one of these where the vertical bar is anything other than a mistake, but I suppose it is possible in some cases. Even for a mistake, it is perhaps best for the bot to keep the character, without breaking the formatting, and someone to take it out by hand if it is really obnoxious. Lithopsian (talk) 12:25, 7 December 2015 (UTC)
Sometimes for news site or web site sources, the pipe character or spaced dash may come up in |title= values, where it should really be treated as a field delimiter between title and publisher. I'm not sure if citationbot checks for that, but certainly there are some other tools that are getting it wrong. It would be good if citationbot caught and corrected those errors, rather than just converting the character to have a less-obvious error. LeadSongDog come howl! 17:06, 7 December 2015 (UTC)

Google books data is sometimes rubbish[edit]

Bot puts journal name into title

Status
new bug
Reported by
Jonesey95 (talk) 04:42, 23 September 2015 (UTC)
Type of bug
Inconvenience
Actual / expected output
Bot puts journal name into title=
Bot should put journal name into journal=
Link
https://en.wikipedia.org/w/index.php?title=Ataye_River&type=revision&diff=682349962&oldid=545633253
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion

Also: https://en.wikipedia.org/w/index.php?title=Homing_pigeon&diff=prev&oldid=682284024

the bot thinks it can interpret Google Books metadata, and fails badly for journal articles that are published within journal issues listed as books by Google Books. —David Eppstein (talk) 04:56, 23 September 2015 (UTC)
(EC) I think you have to propose a solution if you want this fixed - the bot took the "title" from the Google books link, which is generally appropriate. Example of solution: ask the bot to leave the title untouched IF the template type is "cite journal" AND the url contains "books.google" AND the citation is not retrievable through crossref/pmid/etc databases, but still fix the title if the template is "cite book"? (I admit this criterion is somewhat too complex.). Materialscientist (talk) 04:57, 23 September 2015 (UTC)
In my experience the metadata at Google books is too unreliable to ever use without human intervention. It's often a good starting point, but it regularly does things like replacing the actual publisher name with the name of a business entity that later bought the publisher, using publication years that are much later than the actual publisher, mangling author names, listing minor contributors (e.g. the author of a preface) as the author of a whole book, listing multiple book series for a book only one of which is correct, listing publisher names as authors and author names as publishers, filling in the "edition" field with descriptive text instead of the edition number, listing only one author or editor for a book that has more than one, etc. —David Eppstein (talk) 05:33, 23 September 2015 (UTC)
Yes. I think we should avoid any automated, or even semi-automated, any extractions from Google metadata. Even having a human pass on such extractions is too slack, as, at best, such data is in no way authoritative, and suitable only as hints for further research. ~ J. Johnson (JJ) (talk) 21:51, 23 September 2015 (UTC)
I think manual extractions are ok as long as they are doublechecked against either the preview or a hardcopy. And editors who don't have a preview or a hardcopy shouldn't be adding the citation at all. But the bot can't do any of that, it can only copy what Google already has wrong, and that's not good enough. —David Eppstein (talk) 03:04, 30 September 2015 (UTC)
In such cases we are not doublechecking the metadata; we're using it to find an authoritative instance from which to extract the data directly. At any rate, I think we are agreed that a bot should not be making any changes or additions based on the Google metadata. ~ J. Johnson (JJ) (talk) 22:01, 2 October 2015 (UTC)

Unknown is not a journal name[edit]

Unknown is not a journal name

Status
feature request
Reported by
(tJosve05a (c) 06:51, 24 September 2015 (UTC)
Type of bug
Inconvenience
Actual / expected output
Link
https://en.wikipedia.org/w/index.php?title=Digital_object_identifier&diff=prev&oldid=682510640
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion

In this case it looks like bad data at ADS rather than the bot's fault. —David Eppstein (talk) 06:56, 24 September 2015 (UTC)
Yes, but I think that the bot can have one line of code that refuses to add a journal name that is unknown. AManWithNoPlan (talk) 15:22, 1 October 2015 (UTC)

Dealing with half dead DOI[edit]

dx.doi.org resolves some DOI that cross ref does not

Status
new bug
Reported by
AManWithNoPlan (talk) 00:42, 18 November 2015 (UTC)
Type of bug
Improvement:
Actual / expected output
marks a DOI as invalid even if it works if there is no crossref entry
We can't proceed until
Agreement on the best solution
Requested action from maintainer
Only mark DOI invalid if dx.doi.org also fails

Discussion

I thought this was fixed and marked it as so. Currently, doi is flagged as invalid if crossref fails, which is reasonable, but need to also check is dx.doi.org also failed AManWithNoPlan (talk) 00:42, 18 November 2015 (UTC)

I encounter this bug quite often and find it annoying, because in my naive thinking it should be easy to make the bot check the dx.doi.org/xxx link for a "broken" doi. A fresh example: run doi bot on Africanized bee, it will mark doi:10.3265/Nefrologia.pre2010.May.10269 as inactive. Materialscientist (talk) 03:34, 5 February 2016 (UTC)

Bot created arXiv= parameter error[edit]

Bot created arXiv= parameter error

Status
new bug
Reported by
Jonesey95 (talk) 03:56, 7 December 2015 (UTC)
Type of bug
Inconvenience
Actual / expected output
Bot changed a valid |eprint= parameter into an invalid one by removing the class
Bot should leave valid parameters alone
Link
Search for 0508091 in this diff
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer
Modify code to match {{cite arxiv}}

Discussion

The bot removed the class portion of the arXiv parameter value in {{cite arxiv}}. It should not have done so. There are two kinds of arXiv parameters, explained in the documentation as follows:

  • arxiv or eprint (Mandatory): arXiv/Eprint identifier, without any "arXiv:" prefix. Prior to April 2007, the identifiers included a classification, an optional two-letter subdivision, and a 7-digit YYMMNNN year, month, and sequence number of submission in that category. E.g. gr-qc/0610068 or math.GT/0309136. After April 2007, the format was changed to a simple YYMM.NNNN. Starting in January 2015, the identifier was changed to be 5 digits: YYMM.NNNNN.
  • class: arXiv classification, e.g. hep-th. Optional. To be used only with new-style (2007 and later) eprint identifiers that do not include the classification.

The bot should not modify valid |arxiv= or |eprint= parameters. – Jonesey95 (talk) 03:56, 7 December 2015 (UTC)

Here's a minimal diff showing this problem. Lithopsian (talk) 00:02, 29 December 2015 (UTC)

Link at top of page leads to error[edit]

The link at the top of the results page is incorrect for articles containing spaces

Status
new bug
Reported by
Lithopsian (talk) 13:27, 26 December 2015 (UTC)
Type of bug
Cosmetic
Actual / expected output
After expanding citations for a page containing spaces in the title, the results page shows a link to the article at the top and bottom of the page. The link at the top does not lead to the article, but to an error page.
We can't proceed until
Agreement on the best solution
Requested action from maintainer

Discussion


Error converting url to arxiv parameter[edit]

Bot created invalid arxiv=

Status
new bug
Reported by
Hawkeye7 (talk) 21:48, 27 December 2015 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
A Bot inserted an arxiv= into a template on Metallurgical Laboratory creating a red "Check |arxiv= value" error message. Corrected by removing the ".pdf" from the end of the arxiv. see https://en.wikipedia.org/w/index.php?title=Metallurgical_Laboratory&type=revision&diff=697034978&oldid=697034297
We can't proceed until
A specific edit to the bot's code is requested below.
Requested action from maintainer

Discussion

Just need to strip the .pdf off of url when converting url to eprint. Super easy code change. AManWithNoPlan (talk) 19:19, 9 January 2016 (UTC)

JSTOR plant link mistaken for journal[edit]

JSTOR link

Status
new bug
Reported by
Josh Milburn (talk) 15:10, 7 February 2016 (UTC)
Type of bug
Deleterious
Actual / expected output
The bot is changing a JSTOR link to the JSTOR Global Plants project to an unrelated link to a JSTOR journal article. It falsely believes that the "JSTOR=" link on {{cite journal}} (admittedly, this is probably not the template which should have been used in the article) can be used in this case, when it cannot, as the citation is to a different part of the JSTOR website.
Link
https://en.wikipedia.org/w/index.php?title=Persoonia_terminalis&type=revision&diff=703656019&oldid=703655944
We can't proceed until
Agreement on the best solution
Requested action from maintainer
detect plant jstor urls and ignore

Discussion

That's annoying that JSTOR has chosen to add a new type of stable link (although it does start with plant) AManWithNoPlan (talk) 19:21, 7 February 2016 (UTC)

citing using pmid creates author1 instead of last1[edit]

citing using pmid creates author1 instead of last1

Status
not a bug
Reported by
Ihaveacatonmydesk (talk) 21:33, 30 May 2016 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
{{cite journal|pmid=12858711 |year=2003 |author1=Lovallo |first1=D |title=Delusions of success. How optimism undermines executives' decisions |journal=Harvard business review |volume=81 |issue=7 |pages=56–63, 117 |last2=Kahneman |first2=D }}
{{cite journal|pmid=12858711 |year=2003 |last1=Lovallo |first1=D |title=Delusions of success. How optimism undermines executives' decisions |journal=Harvard business review |volume=81 |issue=7 |pages=56–63, 117 |last2=Kahneman |first2=D }}
Replication instructions
use a pmid an click the button to autocomplete - also does the same thing when inputting a url into cite book, like {{cite book|url=https://books.google.com/?id=FI7l8O1tlkkC}}
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion

|author1= is an alias of |last1=. This would be a cosmetic fix (in the code) only. – Jonesey95 (talk) 22:55, 31 May 2016 (UTC)

Agreed, but since it's such a simple fix it would be a shame not to do it. Also I actively search for "author" when most of the refs are |lastn=/|firstn= to edit them for consistency, and that creates false positives. Ihaveacatonmydesk (talk) 08:28, 1 June 2016 (UTC)

When bibcodes ends with a dot, it leaves the dot out[edit]

When bibcodes ends with a dot, it leaves the dot out

Status
new bug
Reported by
Headbomb {talk / contribs / physics / books} 17:53, 19 June 2016 (UTC)
Type of bug
Inconvenience: Humans must occasionally make immediate edits to clean up after the bot
Actual / expected output
When bibcodes ends with a dot, it leaves the dot out (2010Natur.464...59)
The bot should retrieve the full 19-character bibcode (2010Natur.464...59.)
Link
[1] [search for the string "| bibcode = 2010Natur.464...59" in the diff]
We can't proceed until
Bot operator's feedback on what is feasible
Requested action from maintainer

Discussion


Removes access-date when chapter URLs specified[edit]

Removes access-date when chapter URLs specified

Status
new bug
Reported by
Dhtwiki (talk) 05:12, 20 June 2016 (UTC)
Type of bug
Improvement
Actual / expected output
Link
https://en.wikipedia.org/w/index.php?title=Earth&action=historysubmit&type=revision&diff=726104484&oldid=725978381
We can't proceed until
Agreement on the best solution
Requested action from maintainer
notice |chapter-url=

Discussion

The bug is that the bot does not seem to notice that |chapter-url= could have access date. The bot is looking for |url=. AManWithNoPlan (talk) 19:59, 16 July 2016 (UTC)

unnecessary addition of |DUPLICATE_page= parameter[edit]

unnecessary addition of |DUPLICATE_page= parameter

Status
new bug
Reported by
Trappist the monk (talk) 12:11, 26 June 2016 (UTC)
Type of bug
Inconvenience: Humans must clean up after the bot
Actual / expected output
|DUPLICATE_page= causes Module:Citation/CS1 to display a redundant error message
when a template has both |page= and |pages=, the bot should do nothing
Link
Dinophysis norvegica
We can't proceed until
Agreement on the best solution
Requested action from maintainer

Discussion

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.  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.  Unknown parameter |DUPLICATE_page= ignored (help); More than one of |pages= and |page= specified (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)
Re "arbitrarily...": The bot always tags the first duplicated parameter, which is the one that is not displayed in the citation. That preserves the rendered citation while adding the error message. There is no way that the bot could choose the "right" parameter to mark as a duplicate. – Jonesey95 (talk) 14:27, 30 June 2016 (UTC)
I disagree that this is necessarily a problem. These duplicate parameters can be hard to find in long articles, and the bot's conversion of one of the parameters to "DUPLICATE_parameter" makes the error stand out and helps editors who would otherwise not notice the errors find them and fix them. If there are any developers reading this page, I would like them to work on other bug fixes and feature requests before tackling this one. – Jonesey95 (talk) 14:43, 28 June 2016 (UTC)