This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 15 | ← | Archive 18 | Archive 19 | Archive 20 | Archive 21 | Archive 22 | → | Archive 25 |
https://en.wikipedia.org/?title=List_of_exoplanets_discovered_in_2019&type=revision&diff=947872230&oldid=947858354 Back in the old days the bot would have ran on this page. We do a lot better checking now, since things can go really off the rails when the templates are not right.
AManWithNoPlan (
talk) 23:48, 28 March 2020 (UTC)
|journal=
to a {{
cite book}}, as this sequence of edits did? I would think |series=
, as in your final edit, would be more appropriate. I think adding journal to cite book is unlikely enough to be correct that it should count as a bug by itself, even though it can be patched up. —
David Eppstein (
talk) 06:31, 29 March 2020 (UTC)
Step 1 done: https://github.com/ms609/citation-bot/pull/2769 and now waiting on Step 2: https://github.com/ms609/citation-bot/pull/2770 AManWithNoPlan ( talk) 12:11, 29 March 2020 (UTC)
|publication-place=
to |location=
, despite the
cite template documentation still saying about location: "For news stories with a dateline, that is, the location where the story was written. In earlier versions of the template this was the publication place, and for compatibility, will be treated as the publication place if the publication-place parameter is absent; see that parameter for further information.".
I've read the documentation before making citations, so was annoyed about the bot changing the parameters the "wrong" way. So I reverted it and tried to file a bug report, but upon finding
User_talk:Citation_bot/Archive_15#Publication_place I learned that the bot was "correct". But that discussion was a year ago, and nothing happened since. Quick fix would be to stop bot from making these edits until documentation is changed. Having it inconsistent wastes time of uninvolved people (like me) who need to search through bug report archives just to learn what is going on.
Attomir (
talk) 15:40, 31 March 2020 (UTC)
|location=
is simply preferable to |publication-place=
. Both work just fine, they are aliases of each other.
Headbomb {
t ·
c ·
p ·
b} 16:31, 31 March 2020 (UTC)|page=1493
to |pages=1491–3
in a Science article (|doi=10.1126/science.1255720
) for which I explicitly referenced a page on which the referred claim is made.
I gather that some citation style guides say that referencing page numbers for journal articles (as opposed to books) is not needed, but I do not see an explicit prohibition in any enwiki guidelines. Is the bot doing this because it is a journal article or because it is short?
As an aside, I do not think getting the page range of the whole journal article is all that important nowadays, as no one reads them in print anymore... Attomir ( talk) 15:43, 31 March 2020 (UTC)
I'm reporting this because the user (
User:Sb008) prefers to just have a go at the person who activated the bot rather than addressing the underlying issue.
Timrollpickering (
Talk) 16:15, 30 March 2020 (UTC)
Two automatic systems, VisualEditor and Citation bot, are at odds over
The automatically generated WorldCat URL in the automatically generated Template:cite book seems to be this bone of contention.
For a details, see also User:Lent/sandbox/VisualEditor_vs._Citation_bot
This automation-driven WP:EDITWAR seems counter-productive. Or maybe we use it as entertainment: "Let's get ready to rumble!" :) Lent ( talk) 01:44, 29 March 2020 (UTC)
As I was working backwards from the last change, I started with Citation bot, but I have also opened a task on VisualEditor [ T248770] VisualEditor Automatic cite book generated from isbn vs. Citation bot
Would knowledgeable editors please go there to instead [
T232771] and add to the task more details clarifying the problem and suggested fixes?
Lent (
talk) 03:07, 29 March 2020 (UTC)
|title=
and |work=
to |chapter=
and |encyclopedia=
respectively. Fair enough. But then in 3 of these references it also adds |title=Ullmann's Encyclopedia of Industrial Chemistry, 40 Volume Set
, even as there already is |work=[[Ullmann's Encyclopedia of Industrial Chemistry]]
param there.|title=
s.
This may be problem with book's metadata, but is there a legitimate situation in which all three of "title", "chapter", and "work/encyclopedia/etc." are needed in one citation?
As an aside, what is the rationale of changing title/work to chapter/encyclopedia? When I was creating the citations for Ullmann's in the first place, I could see there were 2 conventions for existing articles, one was using "chapter" for chapter name and "title" for encyclopedia name, other used "title" and "work" respectively. Why is the former preferred? Attomir ( talk) 15:49, 31 March 2020 (UTC)
|pages=7-1 – 7-2
into |pages=7–1 – 7–2
. —
David Eppstein (
talk) 01:51, 4 April 2020 (UTC)what should happen = If there is already an en-dash in a page parameter, it should not convert hyphens into dashes in that parameter. And if there are two hyphens in a path parameter, they should not be converted into dashes. This should not have to be one of the many cases where we have to use special encrypted coding that only the bot maintainers can remember to keep the bot out. It should know not to do it without special coding.
https://github.com/ms609/citation-bot/pull/2798 This should fix it once implemented. If not, I will keep digging, since all dash changed should go through this function first. The use of HTML dashes was not anticipated, since that's not supposed to be done in general.
AManWithNoPlan (
talk) 11:53, 4 April 2020 (UTC)
Yesterday I realised Citation bot is possibly running another unapproved bot task, i.e. transforming wikilinks in the "title" parameter to content of the "title-link" parameter, see Help talk:Citation Style 1#Continuation of bot topic. Is there a reason why the bot operates these transformations? -- Francis Schonken ( talk) 06:39, 5 April 2020 (UTC)
|title=
do not corrupt the COinS metadata. Here are two examples; one has a wikilinked |title=
and the other uses |title-link=
. The metadata for both are exactly the same
'"`UNIQ--templatestyles-00000003-QINU`"'<cite class="citation book cs1">''[[Title|A Linked Title]]''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
'"`UNIQ--templatestyles-00000006-QINU`"'<cite class="citation book cs1">[[Title|''A Linked Title'']].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
'"`UNIQ--templatestyles-00000008-QINU`"'<cite class="citation book cs1">''A Linked Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
Thank you for the update on the handling of COINS data in CS1/CS2. It used to be much different. Once this is deployed, the bot will stop the splitting out. https://github.com/ms609/citation-bot/pull/2805 AManWithNoPlan ( talk) 12:19, 5 April 2020 (UTC)
Both the changes to Vincenty's formulae are bogus. Prepositions in French titles shouldn't be capitalized. The "issue=3" for Rainsford's paper is just wrong.
User:SandyGeorgia has a complaint, about this in medical articles. The idea being that URLs that duplicate DOIs should be left if free. AManWithNoPlan ( talk) 20:05, 23 March 2020 (UTC)
|doi-access=free
and the template should use that to automatically create links like it does for PMCs. And since this isn't currently possible, there might be a case to keep them for now.
Headbomb {
t ·
c ·
p ·
b} 21:20, 23 March 2020 (UTC)
Samples
From REM Sleep Behavior Disorder Single-Question Screen, for all the citations in the article, here is what our readers see:
In the second case, the impression that could be given to readers is that they can't read the full text of the second source. We cannot assume that our readers know that they can click on the DOI link in that one case to get to the free full text. We can't even assume they know what a DOI link is. We can't expect them, in a larger article, to click through to every DOI to see if, by chance, free full text is available. We WANT our readers to be able to access text as often as possible, and to be able to verify text, so by in effect "hiding" free full text from the uninitiated reader is a disservice.
Our readers may know that in ALL Wikipedia articles, a blue link in the title means they can read the article. The citation style I use is consistent with the Wikipedia-wide convention: that is, to provide a blue link in the title whenever free full text is available. We do this automatically when a PMC is available, but we have to do it manually when a PMC is not available, but free full text is otherwise available. I have been asking for a long time to stop changing the citation style in articles I edit; I hope not to have to install a deny bot template, because that would eliminate valuable bot edits. Please stop removing URLs to free full text when a PMC is not available, so citations will be consistent. SandyGeorgia ( Talk) 22:53, 23 March 2020 (UTC)
{{ fixed}} closed for now. AManWithNoPlan ( talk) 20:35, 6 April 2020 (UTC)
The problem outlined (and supposedly fixed) here is back or still happening. We're still seeing a double "(subscription or UK public library membership required)", as happened here.
Can bot drivers also stop the bloody bot changing book url field to a chapter url field, and stop changing cite web to cite book every time they see a citation from WorldCat, as happened at [11], [12] and [13]? I'm getting bored having to clear up when the bot passes through; the idea of a bot is to make life easier for editors, not add to their workload. - SchroCat ( talk) 07:14, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2807 - if the OCLC URL has the word "edition" in it and the citation is not "cite book", then the URL conversion will not be done. AManWithNoPlan ( talk) 12:03, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2808 - this should once deployed remove the library template in the case where the ref= parameter is set to a template. AManWithNoPlan ( talk) 12:34, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2809 And a little more generic regex. AManWithNoPlan ( talk) 12:49, 5 April 2020 (UTC)
That should do it. AManWithNoPlan ( talk) 13:06, 5 April 2020 (UTC)
{{ fixed}} AManWithNoPlan ( talk) 20:32, 6 April 2020 (UTC)
|ISBN=
to |isbn=
without making any other changes.
|ISBN=
to |isbn=
without making any other changes. If that is the only change that the bot or tool sees as an option, it should skip editing the article entirely, moving on to the next article. The bot/tool already has the option to not perform an edit to a selected article if it does not see anything in the article that needs changing; the bot/tool should not make cosmetic edits.|ISBN=
to |isbn=
while also adding or fixing useful information that changes the appearance of the article for readers, I will not complain. Cosmetic edits are no good, though. Does the bot have BRFA approval to perform these cosmetic edits? If not, it should stop performing them. –
Jonesey95 (
talk) 17:57, 10 April 2020 (UTC)
Izno is right here. It's fine when you're previewing the page and then manually saving it. But as an automatic-no-review edit, those (and many other edits) shouldn't be done when it's the only thing being done. Headbomb { t · c · p · b} 05:02, 11 April 2020 (UTC)
Not a single refrence is working please make it proper as it was Maizbhandariya ( talk) 02:33, 12 April 2020 (UTC)
<ref>{{arxiv|0910.5501}}</ref>
expands to
{{
cite journal}}
: Cite journal requires |journal=
(
help)when it should expand to
Headbomb { t · c · p · b} 23:00, 9 April 2020 (UTC)
What about creating a redirect WP:CITEBOTREQ (following the WP:*REQ standard) added to the top of WP:BOTREQ page along with the other WP:*REQ pages for automated requests? Understood this page is not primarily a "request" page, but given its active development and frequent feature requests it seems reasonable. -- Green C 15:17, 9 April 2020 (UTC)
In
this edit the bot changes books.google.ca
to books.google.com
, but in
this edit it does not do the same with books.google.co.in
.
Jonatan Svensson Glad (
talk) 21:49, 12 April 2020 (UTC)
|=https://books.google.com/?id=JJKgq1YCkeAC
(no named parameter, where |url=
already exists)
Not sure what. After someone restarts it, need to run https://tools.wmflabs.org/citations/gitpull.php to make sure up to date. AManWithNoPlan ( talk) 15:50, 13 April 2020 (UTC)
{{ fixed}} AManWithNoPlan ( talk) 16:44, 13 April 2020 (UTC)
|title=[[The Worst Journey in the World]] chapter 9
to |title=[[The Worst Journey in the World chapter 9]]
|title=[[The Worst Journey in the World|The Worst Journey in the World chapter 9]]
instead.
Jonatan Svensson Glad (
talk) 22:56, 13 April 2020 (UTC)
My suggestion is to also search for the viewport string & to exempt it when found from removal. Here is the difference between the record & the preview:
Peaceray ( talk) 15:21, 15 April 2020 (UTC)
Maybe the preview has gone away...and therein is the issue. Links to Google books, either directly, or indirectly through agents like WorldCat, do rot. There is an essay, WP:GBWP that discusses this issue among others.
I do consider it my responsibility as an editor & a former reference librarian to make it as easy as possible for users to get to sources. I do not expect most users to know that they may be able to get to a preview by clicking on an OCLC #. If I have educated them through a WorldCat preview that OCLC's WorldCat is a resource for them to use, then so be it. I would much rather send someone to WorldCat's unencumbered interface than to Google Books for philosophical reasons. OCLC, as a non-profit cooperative whose mission is to get bibliographic & holding information to users, aligns far better with Wikipedia's missions than Google. In the matter of how to wrap that or not, I recognize that we differ. I am just asking that my decisions as an editor be respected.
I am sensitive to the argument that Google Books preview content may vary by time & space. Do you have any resources that you would recommend to me for further reading about that?
Peaceray ( talk) 02:26, 18 April 2020 (UTC)
Moving here, as suggested by FULBERT, from their talk page. They and I both used the bot on 500 Queer Scientists [14] [15], and it tagged a lot of links to the site the article is about with the publish date from their metadata, which was 5 February 2020. The problem is that the text appears to have been written before that date: for instance, Anson W. Mackay, as originally created by Jesswade88, contains a link (acccess date 4 July 2019) to what appears to be the same page as the link I added [16].
The link on the old page is dead (I've been meaning to go through Wikipedia and update them); what seems to have happened is that the website has been substantially restructured/redesigned, so that the date of the page is not the same as the date the text was first published (which in most cases is not given/is unknown). What's the right thing to do in this circumstance? YorkshireLad ✿ (talk) 09:18, 12 April 2020 (UTC)
{{ notabug}} we can fix. Hopefully, running bots sooner or adding access-date or date sooner will help. AManWithNoPlan ( talk) 14:46, 18 April 2020 (UTC)
{{ notabug}} Please stop imposing the use of the hdl parameter: when it is wanted editors would likely have used it. Most editors won't know what it is, which makes it particularly user-unfriendly for future improvement of articles. -- Francis Schonken ( talk) 08:58, 4 April 2020 (UTC)
Thank you for working on the documenting of this. AManWithNoPlan ( talk) 20:27, 6 April 2020 (UTC)
{{tl|fixed}}
Question: what was fixed? -- Francis Schonken ( talk) 21:38, 6 April 2020 (UTC)
I will more properly tag it as {{ wontfix}} AManWithNoPlan ( talk) 00:25, 24 April 2020 (UTC)
|pridate=
is valid in some templates. This will add |urldate=
to the list of 'dead' parameters to not be changed.
AManWithNoPlan (
talk) 13:31, 23 April 2020 (UTC)
Can you remove also p. in page and pages?
Grimes2 (
talk) 22:34, 24 April 2020 (UTC)
Example for a hidden non-breaking space.
Headbomb {
t ·
c ·
p ·
b} 14:50, 24 April 2020 (UTC)
form, which should not be removed. --
Izno (
talk) 19:39, 24 April 2020 (UTC)
|date=0001-01-01
That's acually the date on the website <meta property="article:published_time" content="1/1/0001"/>! I will add some code to catch that sloppiness.
AManWithNoPlan (
talk) 21:00, 24 April 2020 (UTC)
{{
wontfix}}
|ref=harv
is now the default in citations, and having the explicit version no longer does anything.
Headbomb {
t ·
c ·
p ·
b} 17:26, 18 April 2020 (UTC)
Well, a related BOTREQ is at WP:BOTREQ#Cleanup of cite templates after "ref=harv" became default and/or update to HarvErrors.js – came here because I thought this would be something up Citation bot's alley? Anyhow, there's no formal BOTREQ yet, but the issue is discussed at Help_talk:Citation_Style_1/Archive 69#Cite book Harv warning. Is it possible to let your light shine there, possibly advising what would be desirable and what not, what the bot can handle, and what not, etc? Tx. -- Francis Schonken ( talk) 07:52, 19 April 2020 (UTC)
|postcript=none
when those do nothing. Like the ISBN/isbn capitalization, this shouldn't be the only edit being done on a page.
Headbomb {
t ·
c ·
p ·
b} 11:37, 19 April 2020 (UTC)
{{
EB1911}}
will honor whatever you give it.{{
cite EB1911}}
. {{cite EB1911}}
also uses Module:Template wrapper so every parameter it gets from {{EB1911}}
and every parameter that it has inside gets passed to {{
cite encyclopedia}}
. Here is a {{
harvnb}}
linking to {{EB1911}}
(prescript turned off for clarity):
{{harvnb|Chisholm|1911}}
→
Chisholm 1911 – links to the second EB1911 showing that the template honors what you give it{{EB1911|no-prescript=yes|title=Example Title|ref=none}}
{{EB1911|no-prescript=yes|title=Example Title}}
|ref=
values will still work, as long as template editors make correct modifications to templates. If something goes wrong, we are likely to see a spike in the article count at
Category:Harv and Sfn template errors (32,775 articles at this writing). So far, I have seen no such spike. Please post at that category page or on my talk page if you see any EB1911 template usages with broken links that you are unable to fix. –
Jonesey95 (
talk) 22:32, 19 April 2020 (UTC)
ref = {{{ref|}}}
entirely. Clever wrappers. Thanks for the verification.
David Brooks (
talk) 13:55, 20 April 2020 (UTC) ETA: Thanks for the patient explanation, Trappist.
David Brooks (
talk) 14:00, 20 April 2020 (UTC)I oppose removing "ref=harv". Having that parameter in place gives editors who are not technically inclined a marker that there is a parameter available that controls the production of an anchor. As you know, editors will sometimes move a citation from Works cited to Further reading and vice-versa, which involves switching between "ref=harv" and "ref=none". It doesn't matter to that group of editors which of those is the default, and it is helpful to them to be able to use either value for the parameter without somebody removing one or the other. Software works best when it's designed to accommodate the working practices of the users, not when it forces the working practices of the users to accommodate its idiosyncrasies. -- RexxS ( talk) 15:12, 21 April 2020 (UTC)
... it does nothing" Of course it does something. It allows folks like me to explain to other editors that there is a parameter which needs to be set to "harv" when they want to connect the citation to a sfn, and set to "none" when they use the full citation elsewhere. That allows them to move a source from reference to reading and vice-versa with minimal effort. It's cognitively easier to learn how to switch a parameter from one value to another than it is to learn when to omit it and what value it has when it must be included. If we had encouraged editors to add "ref=harv" and "ref=none" in the past, hardly anybody would have even noticed when the default changed. Leave the "ref-harv" parameter alone: it's not hurting anything, and it would allow any future change in default to happen transparently. Robust systems don't rely on defaults. -- RexxS ( talk) 01:01, 22 April 2020 (UTC)
|ref=harv
and go "Oh, there's a variety of shortened footnotes templates you can use to make a shortened foot note to this citation!". And robust systems rely on defaults all the time.
Headbomb {
t ·
c ·
p ·
b} 14:31, 22 April 2020 (UTC)
Oppose removing "ref=harv". We need that extra functionality when moving citations around from source sections to FR to Selected works. Without it, the scripts are malfunctioning, articles look ugly, and there's no clear way to fix them. SarahSV (talk) 22:18, 21 April 2020 (UTC)
|ref=harv
does. There is zero difference with a citation with |ref=harv
and one without. If your script is broken, update your script, or get a new one made at
WP:SCRIPTREQ.
Headbomb {
t ·
c ·
p ·
b} 22:42, 21 April 2020 (UTC)
No particular opinion on whether the bot should remove |ref=harv
or not, but as I stated on the CS1 talk page: As things currently stand this isn't a
WP:COSMETICBOT task - |ref=harv
currently throws a
maintenance category. Maybe it shouldn't, and maybe a bot removal isn't a good idea, but removing the parameters is not a cosmetic edit according to the definition in the policy.
Jo-Jo Eumerus (
talk) 08:30, 22 April 2020 (UTC)
|ref=harv
is there or not. It's something purely self-referential. If falls in the
broader definition of "edits of such little value that the community deems them to not be worth making in bulk".
Headbomb {
t ·
c ·
p ·
b} 14:26, 22 April 2020 (UTC)
|ref=harv
from citation templates, would be to remove the code from the CS1 module that generates a maintenance category and maintenance message when |ref=harv
is used. We don't generate a maintenance message when |type=
is present but empty, and that is code that does the same thing as |ref=harv
, i.e. nothing. This might be a good discussion to have at
Help Talk:CS1. As I proposed at the top of this thread, I propose closing this discussion as being premature, since there is not consensus to remove these |ref=
parameters yet. –
Jonesey95 (
talk) 21:56, 22 April 2020 (UTC)
|ref=harv
, IMO, but I don't think there is consensus to remove empty parameters. Consensus to remove clutter from CS1 citations should be sought at
Help Talk:CS1, not here. –
Jonesey95 (
talk) 22:45, 22 April 2020 (UTC)
RexxS, Headbomb has now started implementing this. Does the above count as consensus? SarahSV (talk) 20:41, 24 April 2020 (UTC)
|harv=
from these templates, which does absolutely nothing but remove a maintenance category from the template page and the articles these are transcluded onto, she is really going out of her way to have her "workflow" disrupted because no script is affected, no anchors are affected, and there is zero no rendering changes anywhere on any page associated with that removal.
Headbomb {
t ·
c ·
p ·
b} 22:54, 24 April 2020 (UTC)
You're really not going to understand anybody else's view if you ignore what they write. -- RexxS ( talk) 23:52, 24 April 2020 (UTC)@ Headbomb: I can see you've removed "ref=harv" from something like 50 templates using AWB today. Am I right that you're working on the assumption that citations hard-coded into templates will never be moved from a Works cited into a Further reading section, so would not inconvenience editors like Sarah? I trust you know that bot-like edits (around 50 pages in less than two minutes) to create a fait accompli is strongly frowned on when there is dispute over the appropriateness of the edits. I should caution you against doing similar removals in articles where is a chance of other editors objecting.
[emphasis added] --RexxS (talk) 21:23, 24 April 2020 (UTC)
|harv=
from template pages in a sea of 110K+ articles a fait accompli, you and I have a very different definition of what that is.
Headbomb {
t ·
c ·
p ·
b} 23:57, 24 April 2020 (UTC)
I've been away for a while, but... doesn't "removing ref=harv from 50 templates" imply that Trappist's addition of ref=harv as a default for CS1 is permanent? I know that change seemed to have no downside (other than more warnings in HarvErrors.js), but I don't recall a strong consensus. Since this is being discussed in many places I may have missed an RFC. Now we've made more changes that rely on the CS1 change, it would be difficult to roll back now. David Brooks ( talk) 23:14, 25 April 2020 (UTC)
{{ notabug}}
Your recent editing history at BWV Anh. shows that you are currently engaged in an edit war; that means that you are repeatedly changing content back to how you think it should be, when you have seen that other editors disagree. To resolve the content dispute, please do not revert or change the edits of others when you are reverted. Instead of reverting, please use the talk page to work toward making a version that represents consensus among editors. The best practice at this stage is to discuss, not edit-war. See the bold, revert, discuss cycle for how this is done. If discussions reach an impasse, you can then post a request for help at a relevant noticeboard or seek dispute resolution. In some cases, you may wish to request temporary page protection.
Being involved in an edit war can result in you being
blocked from editing—especially if you violate the
three-revert rule, which states that an editor must not perform more than three
reverts on a single page within a 24-hour period. Undoing another editor's work—whether in whole or in part, whether involving the same or different material each time—counts as a revert. Also keep in mind that while violating the three-revert rule often leads to a block, you can still be blocked for edit warring—even if you don't violate the three-revert rule—should your behavior indicate that you intend to continue reverting repeatedly.
--
Francis Schonken (
talk) 06:27, 25 April 2020 (UTC)
|jstor-access=free
, and if those aren't, then they shouldn't be taking the place of the URL in the first place, gives the impression a free article is available there.
Headbomb {
t ·
c ·
p ·
b} 15:12, 25 April 2020 (UTC)
I was just going to say that - good job Green. Also, one page articles are often free on accidentally. AManWithNoPlan ( talk) 16:39, 25 April 2020 (UTC)
|x-access=registration
is when you must log in to access the material, not for interstitial 'ads' or cookies. (|x-access=subscription
is when you must pay to access the material.) --
Izno (
talk) 21:03, 25 April 2020 (UTC)
|JSTOR=
paremeter. Likewise for DOI urls which are redundant with the DOI parameters. This is normal and not a bug.
Headbomb {
t ·
c ·
p ·
b} 17:02, 26 April 2020 (UTC)
Funky Unicode punctuation instead of normal characters are a real pain, often not present in the meta data. I am making assumptions since we have no electricity today. :-{
AManWithNoPlan (
talk) 14:11, 18 April 2020 (UTC)
<meta property="og:title" content="Red Velvet’s Irene, new face of world’s bestselling liquor brand Chamisul soju - Pulse by Maeil Business News Korea"/>
|doi-access=free
and |url-status=dead
. These are typically citations with random links to faculty websites, broken URLs to previous incarnations of the publisher and assorted zombies, or other dubious copies of the work: no need to keep them when they're broken and the version of record is already available gratis from the publisher. The parameters url, url-status, archive-url, archive-date and variants all need to be removed.
https://github.com/ms609/citation-bot/pull/2825
AManWithNoPlan (
talk) 22:20, 30 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2829
AManWithNoPlan (
talk) 22:24, 1 May 2020 (UTC)
Applies to the other identifier urls too.
Headbomb {
t ·
c ·
p ·
b} 15:57, 2 May 2020 (UTC)
The instructions under Stopping the bot from editing say "add a comment...such as". I think it would be helpful to clarify the "such as". Will any comment do? An empty comment? Or should it contain some key words? David Brooks ( talk) 15:08, 2 May 2020 (UTC)
The bot is changing Google Books links, which Google changes back again, so the change seems pointless at best. For example, the bot changes https://books.google.com/books?id=7zoaKIolT9oC to https://books.google.com/?id=7zoaKIolT9oC. SarahSV (talk) 05:58, 2 May 2020 (UTC)
/books?
to /?
We could also write
https://google.com/books?id=7zoaKIolT9oC, but again, why change it?
SarahSV
(talk) 06:35, 2 May 2020 (UTC)/books?
is more efficient/cleaner, but I'll also agree that removing /books?
only to have google re-add it is sort of pointless.
WP:FAITACCOMPLI here is a red herring.
Headbomb {
t ·
c ·
p ·
b} 07:50, 2 May 2020 (UTC)
Changes that are typically considered substantive affect something visible to readers and consumers of Wikipedia, such as the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs. By that it is not a cosmetic edit. However if it is a considered a cosmetic edit again according to WP:COSMETICBOT
Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change. So then still it is allowed if not done as the only change. Now if this is specific change is really useful is debatable yes. Redalert2fan ( talk) 09:51, 2 May 2020 (UTC)
Changes that are typically considered substantive affect something visible to readers and consumers of Wikipedia, such as the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs<--- See that part in bold? Not cosmetic. Headbomb { t · c · p · b} 14:18, 2 May 2020 (UTC)
Anyhow:
Is a bug
The reply "even more google book url simplification occurs" does not sound like the bug is addressed. Either the bot is liable to introducing CITEVAR variation and/or inconsistency where there was none, or the bug is sorted, ending that undesirable bot behaviour. I suppose enough info has been given above to describe the bug so it can be sorted, which would make posting a formal bug report redundant. -- Francis Schonken ( talk) 12:19, 2 May 2020 (UTC)
@ AManWithNoPlan: please fix the bug, tx. -- Francis Schonken ( talk) 02:34, 3 May 2020 (UTC)
One last note We are now adding (instead of removing) the /books. This is because google is moving away from books.google.com to just google.com and putting the books in the URL path instead of the hostname. AManWithNoPlan ( talk) 13:19, 4 May 2020 (UTC)
For reference:
[33].
Redalert2fan (
talk) 16:00, 3 May 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2838 AManWithNoPlan ( talk) 17:20, 3 May 2020 (UTC)
|number=OGC 06-103r4
to |number=OGC 06–103r4
, changing the hyphen-minus character to an en dash.number
fields.
One small feature request is to capitalize the c in cite templates when you see that it's lowercase on a page. It's just a small thing but it would be nice to add to help keep citations standard. ReFill does it right now but that tool has been buggy for me lately. To be clear when you make new citations you're capitalizing it just like you should. I'm just asking to check on the old citations to make sure they're capitalizing the c in cite. Here's a screenshot of what I'm talking about. https://user-images.githubusercontent.com/921217/81133032-64229400-8f1e-11ea-8a0d-3c85a21b2553.png
I also opened a ticket here and they asked for me to post here https://github.com/ms609/citation-bot/issues/2844
Cite chapter is just cite book under a different name. You can apply any cleanup done to cite book to cite chapter.
Headbomb {
t ·
c ·
p ·
b} 14:51, 6 May 2020 (UTC)
Since we don’t run the tools, then probably no.
https://tools.wmflabs.org runs it.
AManWithNoPlan (
talk) 16:38, 6 May 2020 (UTC)
Looking at
[38] "Numéro d'article 0007" is stated, but "Nombre de pages 13" is actually also given. Taking a look at the the actual pdf in question I can confirm it has 13 pages.
Redalert2fan (
talk) 16:06, 3 May 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2851
AManWithNoPlan (
talk) 11:35, 9 May 2020 (UTC)
See
this discussion in the archive from a few weeks ago. This was reported to have been fixed, but it is still happening (the diff linked above is from the most recent 24 hours). –
Jonesey95 (
talk) 15:08, 9 May 2020 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 15 | ← | Archive 18 | Archive 19 | Archive 20 | Archive 21 | Archive 22 | → | Archive 25 |
https://en.wikipedia.org/?title=List_of_exoplanets_discovered_in_2019&type=revision&diff=947872230&oldid=947858354 Back in the old days the bot would have ran on this page. We do a lot better checking now, since things can go really off the rails when the templates are not right.
AManWithNoPlan (
talk) 23:48, 28 March 2020 (UTC)
|journal=
to a {{
cite book}}, as this sequence of edits did? I would think |series=
, as in your final edit, would be more appropriate. I think adding journal to cite book is unlikely enough to be correct that it should count as a bug by itself, even though it can be patched up. —
David Eppstein (
talk) 06:31, 29 March 2020 (UTC)
Step 1 done: https://github.com/ms609/citation-bot/pull/2769 and now waiting on Step 2: https://github.com/ms609/citation-bot/pull/2770 AManWithNoPlan ( talk) 12:11, 29 March 2020 (UTC)
|publication-place=
to |location=
, despite the
cite template documentation still saying about location: "For news stories with a dateline, that is, the location where the story was written. In earlier versions of the template this was the publication place, and for compatibility, will be treated as the publication place if the publication-place parameter is absent; see that parameter for further information.".
I've read the documentation before making citations, so was annoyed about the bot changing the parameters the "wrong" way. So I reverted it and tried to file a bug report, but upon finding
User_talk:Citation_bot/Archive_15#Publication_place I learned that the bot was "correct". But that discussion was a year ago, and nothing happened since. Quick fix would be to stop bot from making these edits until documentation is changed. Having it inconsistent wastes time of uninvolved people (like me) who need to search through bug report archives just to learn what is going on.
Attomir (
talk) 15:40, 31 March 2020 (UTC)
|location=
is simply preferable to |publication-place=
. Both work just fine, they are aliases of each other.
Headbomb {
t ·
c ·
p ·
b} 16:31, 31 March 2020 (UTC)|page=1493
to |pages=1491–3
in a Science article (|doi=10.1126/science.1255720
) for which I explicitly referenced a page on which the referred claim is made.
I gather that some citation style guides say that referencing page numbers for journal articles (as opposed to books) is not needed, but I do not see an explicit prohibition in any enwiki guidelines. Is the bot doing this because it is a journal article or because it is short?
As an aside, I do not think getting the page range of the whole journal article is all that important nowadays, as no one reads them in print anymore... Attomir ( talk) 15:43, 31 March 2020 (UTC)
I'm reporting this because the user (
User:Sb008) prefers to just have a go at the person who activated the bot rather than addressing the underlying issue.
Timrollpickering (
Talk) 16:15, 30 March 2020 (UTC)
Two automatic systems, VisualEditor and Citation bot, are at odds over
The automatically generated WorldCat URL in the automatically generated Template:cite book seems to be this bone of contention.
For a details, see also User:Lent/sandbox/VisualEditor_vs._Citation_bot
This automation-driven WP:EDITWAR seems counter-productive. Or maybe we use it as entertainment: "Let's get ready to rumble!" :) Lent ( talk) 01:44, 29 March 2020 (UTC)
As I was working backwards from the last change, I started with Citation bot, but I have also opened a task on VisualEditor [ T248770] VisualEditor Automatic cite book generated from isbn vs. Citation bot
Would knowledgeable editors please go there to instead [
T232771] and add to the task more details clarifying the problem and suggested fixes?
Lent (
talk) 03:07, 29 March 2020 (UTC)
|title=
and |work=
to |chapter=
and |encyclopedia=
respectively. Fair enough. But then in 3 of these references it also adds |title=Ullmann's Encyclopedia of Industrial Chemistry, 40 Volume Set
, even as there already is |work=[[Ullmann's Encyclopedia of Industrial Chemistry]]
param there.|title=
s.
This may be problem with book's metadata, but is there a legitimate situation in which all three of "title", "chapter", and "work/encyclopedia/etc." are needed in one citation?
As an aside, what is the rationale of changing title/work to chapter/encyclopedia? When I was creating the citations for Ullmann's in the first place, I could see there were 2 conventions for existing articles, one was using "chapter" for chapter name and "title" for encyclopedia name, other used "title" and "work" respectively. Why is the former preferred? Attomir ( talk) 15:49, 31 March 2020 (UTC)
|pages=7-1 – 7-2
into |pages=7–1 – 7–2
. —
David Eppstein (
talk) 01:51, 4 April 2020 (UTC)what should happen = If there is already an en-dash in a page parameter, it should not convert hyphens into dashes in that parameter. And if there are two hyphens in a path parameter, they should not be converted into dashes. This should not have to be one of the many cases where we have to use special encrypted coding that only the bot maintainers can remember to keep the bot out. It should know not to do it without special coding.
https://github.com/ms609/citation-bot/pull/2798 This should fix it once implemented. If not, I will keep digging, since all dash changed should go through this function first. The use of HTML dashes was not anticipated, since that's not supposed to be done in general.
AManWithNoPlan (
talk) 11:53, 4 April 2020 (UTC)
Yesterday I realised Citation bot is possibly running another unapproved bot task, i.e. transforming wikilinks in the "title" parameter to content of the "title-link" parameter, see Help talk:Citation Style 1#Continuation of bot topic. Is there a reason why the bot operates these transformations? -- Francis Schonken ( talk) 06:39, 5 April 2020 (UTC)
|title=
do not corrupt the COinS metadata. Here are two examples; one has a wikilinked |title=
and the other uses |title-link=
. The metadata for both are exactly the same
'"`UNIQ--templatestyles-00000003-QINU`"'<cite class="citation book cs1">''[[Title|A Linked Title]]''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
'"`UNIQ--templatestyles-00000006-QINU`"'<cite class="citation book cs1">[[Title|''A Linked Title'']].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
'"`UNIQ--templatestyles-00000008-QINU`"'<cite class="citation book cs1">''A Linked Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=A+Linked+Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser+talk%3ACitation+bot%2FArchive+20" class="Z3988"></span>
Thank you for the update on the handling of COINS data in CS1/CS2. It used to be much different. Once this is deployed, the bot will stop the splitting out. https://github.com/ms609/citation-bot/pull/2805 AManWithNoPlan ( talk) 12:19, 5 April 2020 (UTC)
Both the changes to Vincenty's formulae are bogus. Prepositions in French titles shouldn't be capitalized. The "issue=3" for Rainsford's paper is just wrong.
User:SandyGeorgia has a complaint, about this in medical articles. The idea being that URLs that duplicate DOIs should be left if free. AManWithNoPlan ( talk) 20:05, 23 March 2020 (UTC)
|doi-access=free
and the template should use that to automatically create links like it does for PMCs. And since this isn't currently possible, there might be a case to keep them for now.
Headbomb {
t ·
c ·
p ·
b} 21:20, 23 March 2020 (UTC)
Samples
From REM Sleep Behavior Disorder Single-Question Screen, for all the citations in the article, here is what our readers see:
In the second case, the impression that could be given to readers is that they can't read the full text of the second source. We cannot assume that our readers know that they can click on the DOI link in that one case to get to the free full text. We can't even assume they know what a DOI link is. We can't expect them, in a larger article, to click through to every DOI to see if, by chance, free full text is available. We WANT our readers to be able to access text as often as possible, and to be able to verify text, so by in effect "hiding" free full text from the uninitiated reader is a disservice.
Our readers may know that in ALL Wikipedia articles, a blue link in the title means they can read the article. The citation style I use is consistent with the Wikipedia-wide convention: that is, to provide a blue link in the title whenever free full text is available. We do this automatically when a PMC is available, but we have to do it manually when a PMC is not available, but free full text is otherwise available. I have been asking for a long time to stop changing the citation style in articles I edit; I hope not to have to install a deny bot template, because that would eliminate valuable bot edits. Please stop removing URLs to free full text when a PMC is not available, so citations will be consistent. SandyGeorgia ( Talk) 22:53, 23 March 2020 (UTC)
{{ fixed}} closed for now. AManWithNoPlan ( talk) 20:35, 6 April 2020 (UTC)
The problem outlined (and supposedly fixed) here is back or still happening. We're still seeing a double "(subscription or UK public library membership required)", as happened here.
Can bot drivers also stop the bloody bot changing book url field to a chapter url field, and stop changing cite web to cite book every time they see a citation from WorldCat, as happened at [11], [12] and [13]? I'm getting bored having to clear up when the bot passes through; the idea of a bot is to make life easier for editors, not add to their workload. - SchroCat ( talk) 07:14, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2807 - if the OCLC URL has the word "edition" in it and the citation is not "cite book", then the URL conversion will not be done. AManWithNoPlan ( talk) 12:03, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2808 - this should once deployed remove the library template in the case where the ref= parameter is set to a template. AManWithNoPlan ( talk) 12:34, 5 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2809 And a little more generic regex. AManWithNoPlan ( talk) 12:49, 5 April 2020 (UTC)
That should do it. AManWithNoPlan ( talk) 13:06, 5 April 2020 (UTC)
{{ fixed}} AManWithNoPlan ( talk) 20:32, 6 April 2020 (UTC)
|ISBN=
to |isbn=
without making any other changes.
|ISBN=
to |isbn=
without making any other changes. If that is the only change that the bot or tool sees as an option, it should skip editing the article entirely, moving on to the next article. The bot/tool already has the option to not perform an edit to a selected article if it does not see anything in the article that needs changing; the bot/tool should not make cosmetic edits.|ISBN=
to |isbn=
while also adding or fixing useful information that changes the appearance of the article for readers, I will not complain. Cosmetic edits are no good, though. Does the bot have BRFA approval to perform these cosmetic edits? If not, it should stop performing them. –
Jonesey95 (
talk) 17:57, 10 April 2020 (UTC)
Izno is right here. It's fine when you're previewing the page and then manually saving it. But as an automatic-no-review edit, those (and many other edits) shouldn't be done when it's the only thing being done. Headbomb { t · c · p · b} 05:02, 11 April 2020 (UTC)
Not a single refrence is working please make it proper as it was Maizbhandariya ( talk) 02:33, 12 April 2020 (UTC)
<ref>{{arxiv|0910.5501}}</ref>
expands to
{{
cite journal}}
: Cite journal requires |journal=
(
help)when it should expand to
Headbomb { t · c · p · b} 23:00, 9 April 2020 (UTC)
What about creating a redirect WP:CITEBOTREQ (following the WP:*REQ standard) added to the top of WP:BOTREQ page along with the other WP:*REQ pages for automated requests? Understood this page is not primarily a "request" page, but given its active development and frequent feature requests it seems reasonable. -- Green C 15:17, 9 April 2020 (UTC)
In
this edit the bot changes books.google.ca
to books.google.com
, but in
this edit it does not do the same with books.google.co.in
.
Jonatan Svensson Glad (
talk) 21:49, 12 April 2020 (UTC)
|=https://books.google.com/?id=JJKgq1YCkeAC
(no named parameter, where |url=
already exists)
Not sure what. After someone restarts it, need to run https://tools.wmflabs.org/citations/gitpull.php to make sure up to date. AManWithNoPlan ( talk) 15:50, 13 April 2020 (UTC)
{{ fixed}} AManWithNoPlan ( talk) 16:44, 13 April 2020 (UTC)
|title=[[The Worst Journey in the World]] chapter 9
to |title=[[The Worst Journey in the World chapter 9]]
|title=[[The Worst Journey in the World|The Worst Journey in the World chapter 9]]
instead.
Jonatan Svensson Glad (
talk) 22:56, 13 April 2020 (UTC)
My suggestion is to also search for the viewport string & to exempt it when found from removal. Here is the difference between the record & the preview:
Peaceray ( talk) 15:21, 15 April 2020 (UTC)
Maybe the preview has gone away...and therein is the issue. Links to Google books, either directly, or indirectly through agents like WorldCat, do rot. There is an essay, WP:GBWP that discusses this issue among others.
I do consider it my responsibility as an editor & a former reference librarian to make it as easy as possible for users to get to sources. I do not expect most users to know that they may be able to get to a preview by clicking on an OCLC #. If I have educated them through a WorldCat preview that OCLC's WorldCat is a resource for them to use, then so be it. I would much rather send someone to WorldCat's unencumbered interface than to Google Books for philosophical reasons. OCLC, as a non-profit cooperative whose mission is to get bibliographic & holding information to users, aligns far better with Wikipedia's missions than Google. In the matter of how to wrap that or not, I recognize that we differ. I am just asking that my decisions as an editor be respected.
I am sensitive to the argument that Google Books preview content may vary by time & space. Do you have any resources that you would recommend to me for further reading about that?
Peaceray ( talk) 02:26, 18 April 2020 (UTC)
Moving here, as suggested by FULBERT, from their talk page. They and I both used the bot on 500 Queer Scientists [14] [15], and it tagged a lot of links to the site the article is about with the publish date from their metadata, which was 5 February 2020. The problem is that the text appears to have been written before that date: for instance, Anson W. Mackay, as originally created by Jesswade88, contains a link (acccess date 4 July 2019) to what appears to be the same page as the link I added [16].
The link on the old page is dead (I've been meaning to go through Wikipedia and update them); what seems to have happened is that the website has been substantially restructured/redesigned, so that the date of the page is not the same as the date the text was first published (which in most cases is not given/is unknown). What's the right thing to do in this circumstance? YorkshireLad ✿ (talk) 09:18, 12 April 2020 (UTC)
{{ notabug}} we can fix. Hopefully, running bots sooner or adding access-date or date sooner will help. AManWithNoPlan ( talk) 14:46, 18 April 2020 (UTC)
{{ notabug}} Please stop imposing the use of the hdl parameter: when it is wanted editors would likely have used it. Most editors won't know what it is, which makes it particularly user-unfriendly for future improvement of articles. -- Francis Schonken ( talk) 08:58, 4 April 2020 (UTC)
Thank you for working on the documenting of this. AManWithNoPlan ( talk) 20:27, 6 April 2020 (UTC)
{{tl|fixed}}
Question: what was fixed? -- Francis Schonken ( talk) 21:38, 6 April 2020 (UTC)
I will more properly tag it as {{ wontfix}} AManWithNoPlan ( talk) 00:25, 24 April 2020 (UTC)
|pridate=
is valid in some templates. This will add |urldate=
to the list of 'dead' parameters to not be changed.
AManWithNoPlan (
talk) 13:31, 23 April 2020 (UTC)
Can you remove also p. in page and pages?
Grimes2 (
talk) 22:34, 24 April 2020 (UTC)
Example for a hidden non-breaking space.
Headbomb {
t ·
c ·
p ·
b} 14:50, 24 April 2020 (UTC)
form, which should not be removed. --
Izno (
talk) 19:39, 24 April 2020 (UTC)
|date=0001-01-01
That's acually the date on the website <meta property="article:published_time" content="1/1/0001"/>! I will add some code to catch that sloppiness.
AManWithNoPlan (
talk) 21:00, 24 April 2020 (UTC)
{{
wontfix}}
|ref=harv
is now the default in citations, and having the explicit version no longer does anything.
Headbomb {
t ·
c ·
p ·
b} 17:26, 18 April 2020 (UTC)
Well, a related BOTREQ is at WP:BOTREQ#Cleanup of cite templates after "ref=harv" became default and/or update to HarvErrors.js – came here because I thought this would be something up Citation bot's alley? Anyhow, there's no formal BOTREQ yet, but the issue is discussed at Help_talk:Citation_Style_1/Archive 69#Cite book Harv warning. Is it possible to let your light shine there, possibly advising what would be desirable and what not, what the bot can handle, and what not, etc? Tx. -- Francis Schonken ( talk) 07:52, 19 April 2020 (UTC)
|postcript=none
when those do nothing. Like the ISBN/isbn capitalization, this shouldn't be the only edit being done on a page.
Headbomb {
t ·
c ·
p ·
b} 11:37, 19 April 2020 (UTC)
{{
EB1911}}
will honor whatever you give it.{{
cite EB1911}}
. {{cite EB1911}}
also uses Module:Template wrapper so every parameter it gets from {{EB1911}}
and every parameter that it has inside gets passed to {{
cite encyclopedia}}
. Here is a {{
harvnb}}
linking to {{EB1911}}
(prescript turned off for clarity):
{{harvnb|Chisholm|1911}}
→
Chisholm 1911 – links to the second EB1911 showing that the template honors what you give it{{EB1911|no-prescript=yes|title=Example Title|ref=none}}
{{EB1911|no-prescript=yes|title=Example Title}}
|ref=
values will still work, as long as template editors make correct modifications to templates. If something goes wrong, we are likely to see a spike in the article count at
Category:Harv and Sfn template errors (32,775 articles at this writing). So far, I have seen no such spike. Please post at that category page or on my talk page if you see any EB1911 template usages with broken links that you are unable to fix. –
Jonesey95 (
talk) 22:32, 19 April 2020 (UTC)
ref = {{{ref|}}}
entirely. Clever wrappers. Thanks for the verification.
David Brooks (
talk) 13:55, 20 April 2020 (UTC) ETA: Thanks for the patient explanation, Trappist.
David Brooks (
talk) 14:00, 20 April 2020 (UTC)I oppose removing "ref=harv". Having that parameter in place gives editors who are not technically inclined a marker that there is a parameter available that controls the production of an anchor. As you know, editors will sometimes move a citation from Works cited to Further reading and vice-versa, which involves switching between "ref=harv" and "ref=none". It doesn't matter to that group of editors which of those is the default, and it is helpful to them to be able to use either value for the parameter without somebody removing one or the other. Software works best when it's designed to accommodate the working practices of the users, not when it forces the working practices of the users to accommodate its idiosyncrasies. -- RexxS ( talk) 15:12, 21 April 2020 (UTC)
... it does nothing" Of course it does something. It allows folks like me to explain to other editors that there is a parameter which needs to be set to "harv" when they want to connect the citation to a sfn, and set to "none" when they use the full citation elsewhere. That allows them to move a source from reference to reading and vice-versa with minimal effort. It's cognitively easier to learn how to switch a parameter from one value to another than it is to learn when to omit it and what value it has when it must be included. If we had encouraged editors to add "ref=harv" and "ref=none" in the past, hardly anybody would have even noticed when the default changed. Leave the "ref-harv" parameter alone: it's not hurting anything, and it would allow any future change in default to happen transparently. Robust systems don't rely on defaults. -- RexxS ( talk) 01:01, 22 April 2020 (UTC)
|ref=harv
and go "Oh, there's a variety of shortened footnotes templates you can use to make a shortened foot note to this citation!". And robust systems rely on defaults all the time.
Headbomb {
t ·
c ·
p ·
b} 14:31, 22 April 2020 (UTC)
Oppose removing "ref=harv". We need that extra functionality when moving citations around from source sections to FR to Selected works. Without it, the scripts are malfunctioning, articles look ugly, and there's no clear way to fix them. SarahSV (talk) 22:18, 21 April 2020 (UTC)
|ref=harv
does. There is zero difference with a citation with |ref=harv
and one without. If your script is broken, update your script, or get a new one made at
WP:SCRIPTREQ.
Headbomb {
t ·
c ·
p ·
b} 22:42, 21 April 2020 (UTC)
No particular opinion on whether the bot should remove |ref=harv
or not, but as I stated on the CS1 talk page: As things currently stand this isn't a
WP:COSMETICBOT task - |ref=harv
currently throws a
maintenance category. Maybe it shouldn't, and maybe a bot removal isn't a good idea, but removing the parameters is not a cosmetic edit according to the definition in the policy.
Jo-Jo Eumerus (
talk) 08:30, 22 April 2020 (UTC)
|ref=harv
is there or not. It's something purely self-referential. If falls in the
broader definition of "edits of such little value that the community deems them to not be worth making in bulk".
Headbomb {
t ·
c ·
p ·
b} 14:26, 22 April 2020 (UTC)
|ref=harv
from citation templates, would be to remove the code from the CS1 module that generates a maintenance category and maintenance message when |ref=harv
is used. We don't generate a maintenance message when |type=
is present but empty, and that is code that does the same thing as |ref=harv
, i.e. nothing. This might be a good discussion to have at
Help Talk:CS1. As I proposed at the top of this thread, I propose closing this discussion as being premature, since there is not consensus to remove these |ref=
parameters yet. –
Jonesey95 (
talk) 21:56, 22 April 2020 (UTC)
|ref=harv
, IMO, but I don't think there is consensus to remove empty parameters. Consensus to remove clutter from CS1 citations should be sought at
Help Talk:CS1, not here. –
Jonesey95 (
talk) 22:45, 22 April 2020 (UTC)
RexxS, Headbomb has now started implementing this. Does the above count as consensus? SarahSV (talk) 20:41, 24 April 2020 (UTC)
|harv=
from these templates, which does absolutely nothing but remove a maintenance category from the template page and the articles these are transcluded onto, she is really going out of her way to have her "workflow" disrupted because no script is affected, no anchors are affected, and there is zero no rendering changes anywhere on any page associated with that removal.
Headbomb {
t ·
c ·
p ·
b} 22:54, 24 April 2020 (UTC)
You're really not going to understand anybody else's view if you ignore what they write. -- RexxS ( talk) 23:52, 24 April 2020 (UTC)@ Headbomb: I can see you've removed "ref=harv" from something like 50 templates using AWB today. Am I right that you're working on the assumption that citations hard-coded into templates will never be moved from a Works cited into a Further reading section, so would not inconvenience editors like Sarah? I trust you know that bot-like edits (around 50 pages in less than two minutes) to create a fait accompli is strongly frowned on when there is dispute over the appropriateness of the edits. I should caution you against doing similar removals in articles where is a chance of other editors objecting.
[emphasis added] --RexxS (talk) 21:23, 24 April 2020 (UTC)
|harv=
from template pages in a sea of 110K+ articles a fait accompli, you and I have a very different definition of what that is.
Headbomb {
t ·
c ·
p ·
b} 23:57, 24 April 2020 (UTC)
I've been away for a while, but... doesn't "removing ref=harv from 50 templates" imply that Trappist's addition of ref=harv as a default for CS1 is permanent? I know that change seemed to have no downside (other than more warnings in HarvErrors.js), but I don't recall a strong consensus. Since this is being discussed in many places I may have missed an RFC. Now we've made more changes that rely on the CS1 change, it would be difficult to roll back now. David Brooks ( talk) 23:14, 25 April 2020 (UTC)
{{ notabug}}
Your recent editing history at BWV Anh. shows that you are currently engaged in an edit war; that means that you are repeatedly changing content back to how you think it should be, when you have seen that other editors disagree. To resolve the content dispute, please do not revert or change the edits of others when you are reverted. Instead of reverting, please use the talk page to work toward making a version that represents consensus among editors. The best practice at this stage is to discuss, not edit-war. See the bold, revert, discuss cycle for how this is done. If discussions reach an impasse, you can then post a request for help at a relevant noticeboard or seek dispute resolution. In some cases, you may wish to request temporary page protection.
Being involved in an edit war can result in you being
blocked from editing—especially if you violate the
three-revert rule, which states that an editor must not perform more than three
reverts on a single page within a 24-hour period. Undoing another editor's work—whether in whole or in part, whether involving the same or different material each time—counts as a revert. Also keep in mind that while violating the three-revert rule often leads to a block, you can still be blocked for edit warring—even if you don't violate the three-revert rule—should your behavior indicate that you intend to continue reverting repeatedly.
--
Francis Schonken (
talk) 06:27, 25 April 2020 (UTC)
|jstor-access=free
, and if those aren't, then they shouldn't be taking the place of the URL in the first place, gives the impression a free article is available there.
Headbomb {
t ·
c ·
p ·
b} 15:12, 25 April 2020 (UTC)
I was just going to say that - good job Green. Also, one page articles are often free on accidentally. AManWithNoPlan ( talk) 16:39, 25 April 2020 (UTC)
|x-access=registration
is when you must log in to access the material, not for interstitial 'ads' or cookies. (|x-access=subscription
is when you must pay to access the material.) --
Izno (
talk) 21:03, 25 April 2020 (UTC)
|JSTOR=
paremeter. Likewise for DOI urls which are redundant with the DOI parameters. This is normal and not a bug.
Headbomb {
t ·
c ·
p ·
b} 17:02, 26 April 2020 (UTC)
Funky Unicode punctuation instead of normal characters are a real pain, often not present in the meta data. I am making assumptions since we have no electricity today. :-{
AManWithNoPlan (
talk) 14:11, 18 April 2020 (UTC)
<meta property="og:title" content="Red Velvet’s Irene, new face of world’s bestselling liquor brand Chamisul soju - Pulse by Maeil Business News Korea"/>
|doi-access=free
and |url-status=dead
. These are typically citations with random links to faculty websites, broken URLs to previous incarnations of the publisher and assorted zombies, or other dubious copies of the work: no need to keep them when they're broken and the version of record is already available gratis from the publisher. The parameters url, url-status, archive-url, archive-date and variants all need to be removed.
https://github.com/ms609/citation-bot/pull/2825
AManWithNoPlan (
talk) 22:20, 30 April 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2829
AManWithNoPlan (
talk) 22:24, 1 May 2020 (UTC)
Applies to the other identifier urls too.
Headbomb {
t ·
c ·
p ·
b} 15:57, 2 May 2020 (UTC)
The instructions under Stopping the bot from editing say "add a comment...such as". I think it would be helpful to clarify the "such as". Will any comment do? An empty comment? Or should it contain some key words? David Brooks ( talk) 15:08, 2 May 2020 (UTC)
The bot is changing Google Books links, which Google changes back again, so the change seems pointless at best. For example, the bot changes https://books.google.com/books?id=7zoaKIolT9oC to https://books.google.com/?id=7zoaKIolT9oC. SarahSV (talk) 05:58, 2 May 2020 (UTC)
/books?
to /?
We could also write
https://google.com/books?id=7zoaKIolT9oC, but again, why change it?
SarahSV
(talk) 06:35, 2 May 2020 (UTC)/books?
is more efficient/cleaner, but I'll also agree that removing /books?
only to have google re-add it is sort of pointless.
WP:FAITACCOMPLI here is a red herring.
Headbomb {
t ·
c ·
p ·
b} 07:50, 2 May 2020 (UTC)
Changes that are typically considered substantive affect something visible to readers and consumers of Wikipedia, such as the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs. By that it is not a cosmetic edit. However if it is a considered a cosmetic edit again according to WP:COSMETICBOT
Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change. So then still it is allowed if not done as the only change. Now if this is specific change is really useful is debatable yes. Redalert2fan ( talk) 09:51, 2 May 2020 (UTC)
Changes that are typically considered substantive affect something visible to readers and consumers of Wikipedia, such as the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs<--- See that part in bold? Not cosmetic. Headbomb { t · c · p · b} 14:18, 2 May 2020 (UTC)
Anyhow:
Is a bug
The reply "even more google book url simplification occurs" does not sound like the bug is addressed. Either the bot is liable to introducing CITEVAR variation and/or inconsistency where there was none, or the bug is sorted, ending that undesirable bot behaviour. I suppose enough info has been given above to describe the bug so it can be sorted, which would make posting a formal bug report redundant. -- Francis Schonken ( talk) 12:19, 2 May 2020 (UTC)
@ AManWithNoPlan: please fix the bug, tx. -- Francis Schonken ( talk) 02:34, 3 May 2020 (UTC)
One last note We are now adding (instead of removing) the /books. This is because google is moving away from books.google.com to just google.com and putting the books in the URL path instead of the hostname. AManWithNoPlan ( talk) 13:19, 4 May 2020 (UTC)
For reference:
[33].
Redalert2fan (
talk) 16:00, 3 May 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2838 AManWithNoPlan ( talk) 17:20, 3 May 2020 (UTC)
|number=OGC 06-103r4
to |number=OGC 06–103r4
, changing the hyphen-minus character to an en dash.number
fields.
One small feature request is to capitalize the c in cite templates when you see that it's lowercase on a page. It's just a small thing but it would be nice to add to help keep citations standard. ReFill does it right now but that tool has been buggy for me lately. To be clear when you make new citations you're capitalizing it just like you should. I'm just asking to check on the old citations to make sure they're capitalizing the c in cite. Here's a screenshot of what I'm talking about. https://user-images.githubusercontent.com/921217/81133032-64229400-8f1e-11ea-8a0d-3c85a21b2553.png
I also opened a ticket here and they asked for me to post here https://github.com/ms609/citation-bot/issues/2844
Cite chapter is just cite book under a different name. You can apply any cleanup done to cite book to cite chapter.
Headbomb {
t ·
c ·
p ·
b} 14:51, 6 May 2020 (UTC)
Since we don’t run the tools, then probably no.
https://tools.wmflabs.org runs it.
AManWithNoPlan (
talk) 16:38, 6 May 2020 (UTC)
Looking at
[38] "Numéro d'article 0007" is stated, but "Nombre de pages 13" is actually also given. Taking a look at the the actual pdf in question I can confirm it has 13 pages.
Redalert2fan (
talk) 16:06, 3 May 2020 (UTC)
https://github.com/ms609/citation-bot/pull/2851
AManWithNoPlan (
talk) 11:35, 9 May 2020 (UTC)
See
this discussion in the archive from a few weeks ago. This was reported to have been fixed, but it is still happening (the diff linked above is from the most recent 24 hours). –
Jonesey95 (
talk) 15:08, 9 May 2020 (UTC)