User talk:Trappist the monk: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 19:14, 28 December 2020

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22, 23, 24, 25, 26

This page has archives. Sections older than 7 days may be automatically archived by .

CS1

This user is responsible for those
CS1 error messages (help).

Comments are welcome. If your comments are about my work on a particular article, please make
them at the article's talk page so that everyone who has an interest in the article may participate.

To stop Monkbot, add a message to its talk page. Comments and questions about Monkbot are welcome here.

Fix

— Preceding unsigned comment added by 2409:4065:E8C:C5D7:6A4B:465D:15C1:E917 (talk) 16:20, 11 December 2020 (UTC)[reply]

How to fix it, I have tried to request an edit but the response is like the above?? — Preceding unsigned comment added by 2409:4065:12:47C1:1920:9B63:797F:8AC2 (talk) 19:31, 19 December 2020 (UTC)[reply]

Bot consolidating access-date→accessdate

Trappist the monk Don't know if you are the correct person to alert about this. But if not, please point me to the correct talk page. In recent weeks/months, I've noticed what looks to me like a bot, or persons using a bot, to correct "access-date" to "accessdate". I have no issue with that, seems like a good idea. However, it's really an exercise in futility. The drop-down cite template on the standard toolbar I use, all have a fill-in blank for "Access date". The data input from the user is irrelevant. What happens, once the "Insert" button is chosen, is that the template prints the hyphenated word "access-date" So unless that is changed in the template, whoever is bot changing to "accessdate", is really just spinning their wheels. Thoughts? Should this be posted elsewhere? — Maile (talk) 23:36, 19 December 2020 (UTC)[reply]

I don't know of any bot or other tool that is converting |access-date= (with the hyphen) to |accessdate= (without the hyphen). Monkbot/task 18 is converting |accessdate= (without the hyphen) to |access-date= (with the hyphen).

—Trappist the monk (talk) 00:11, 20 December 2020 (UTC)[reply]

Interesting. Well, next time I notice that on my watch list, I'll post here who and what it was. — Maile (talk) 00:26, 20 December 2020 (UTC)[reply]

Hi TTTM. What is the rationale/point of changing "accessdate" to "access-date"? What benefit does it have? It does lend itself to a lot of watchlist-cloggery! Hope you have a great Christmas too. Ho, ho, ho! Lugnuts ^{Fire Walk with Me} 10:06, 25 December 2020 (UTC)[reply]

Is this question not answered in the bot's documentation?

—Trappist the monk (talk) 12:15, 25 December 2020 (UTC)[reply]

Not that I can see - it mentions that the task is being done, but I can't see why it is being done. It even links to this discussion suggesting not to do it. Lugnuts ^{Fire Walk with Me} 13:17, 25 December 2020 (UTC)[reply]

The not to do it in that discussion means that WP:GENFIXES should not be doing what the bot is doing because |accessdate= to |access-date= fixes make it more difficult for an editor using awb with genfixes enabled to see the changes that they want to see, that they need to see.

From the bot's documentation: For parameter names that are multiword, cs1|2 is gradually shifting to prefer the hyphenated form. You can see this in process at Help:CS1 errors#Cite uses deprecated parameter |<param>= where there is a list of currently-deprecated all-run-together parameter names and a list of all-run-together parameter names for which support has been withdrawn. The normal way of deprecating and removing parameters has been adequate for those and others that are yet to be deprecated but will do nothing but incur the wrath of editors were it to be applied to |accessdate=, |archivedate=, |archiveurl=, |authorlink= (the 'big' four) because overnight, millions (literally) of articles will start showing Cite uses deprecated parameter |<param>= error messages (a lot of them). I, for one, am not interested in the sort of torches-and-pitchforks drama that would ensue. Monkbot task 18 answers the question asked in previous drama situations: why can't a bot fix these before turning on the error messages?

—Trappist the monk (talk) 14:22, 25 December 2020 (UTC)[reply]

Monkbot GIGO

This edit was a bit of GIGO, but it broke a cite template that had been working. If it could be avoided, that would be great. – Jonesey95 (talk) 00:29, 21 December 2020 (UTC)[reply]

This one was perhaps not GIGO; it broke a template that had a comment in it. – Jonesey95 (talk) 00:38, 21 December 2020 (UTC)[reply]

I've seen just a few of these (I regularly troll the missing pipe cat looking for them); too difficult to avoid for too little reward.

—Trappist the monk (talk) 00:50, 21 December 2020 (UTC)[reply]

This one didn't trigger the missing pipe category, unfortunately. – Jonesey95 (talk) 02:28, 21 December 2020 (UTC)[reply]

Thanks for the report.

I'm not inclined to make the attempt. This is the only breakage of this kind of that I know about. It's better, I think, that the bot visibly broke the malformed template so that it could be properly repaired.

—Trappist the monk (talk) 00:47, 21 December 2020 (UTC)[reply]

Here's a third one. It is not clear to me from the harv documentation whether Citation|ref=harvard_manuscript is valid or invalid, but the other two ref=blah_blah links in that page are working. Couldn't your code just remove "ref=harv" only when followed by a pipe or a brace? And I do not view the template with a comment in it as malformed; comments are valid anywhere, as far as I know. – Jonesey95 (talk) 02:07, 21 December 2020 (UTC)[reply]

Here's a fourth one. This one too appears to be avoidable by looking for a trailing pipe or brace after "harv". There are no doubt more of these out there, waiting for the bot to break them. I look askance at "the only breakage of this kind...". – Jonesey95 (talk) 02:12, 21 December 2020 (UTC)[reply]

I agree, the first one seems fairly easily avoided. --Izno (talk) 05:17, 21 December 2020 (UTC)[reply]

Did it again after Jonesey95 reported the problem above :( Plastikspork _―Œ^(talk) 20:21, 22 December 2020 (UTC)[reply]

I have added Harold A. Lafount to the bot's skip list.

—Trappist the monk (talk) 14:53, 23 December 2020 (UTC)[reply]

Broken citation template

Monkbot broke a citation template here (line 310). It seems to have tried to eliminate "| ref = harv" and left the "2" alone on the line. I restored it, but perhaps that line needs to be gone completely? My brain goes funky when confronted by Harvard references. (Ping me when replying — I’m editing really intermittently these days.) — Gorthian (talk) 07:46, 22 December 2020 (UTC)[reply]

Thanks. That's been fixed.

—Trappist the monk (talk) 12:31, 22 December 2020 (UTC)[reply]

Have you fixed it in the bot's code? I just used some primitive insource searching to pre-emptively find and modify a couple dozen articles using "ref=harvxxx" so that the bot would not break them, but I know that I have missed some. I think our count of known article breakage is now up to six or seven (I know there have been hundreds of thousands of edits), and I am sure there are more broken and not-yet-broken instances out there. Is it really that hard to ensure that there is a pipe or brace following "harv" before removing it? Given that |ref=harv is not a broken state, is it worth breaking articles to remove it? – Jonesey95 (talk) 14:55, 22 December 2020 (UTC)[reply]

See this diff.

—Trappist the monk (talk) 14:52, 23 December 2020 (UTC)[reply]

Sorry, I missed this edit. Well done! – Jonesey95 (talk) 00:28, 28 December 2020 (UTC)[reply]

Another Batch of Bot Breaks

Monkbot continues to cause "duplicate reference definition" problems in articles that it edits. Here is a list of articles that I had to repair today. Each one had at least two duplicate reference definition errors due to nearly invisible changes Monkbot made to templates involved in these articles.

I'd like to understand why Monkbot can't be improved to check for errors before saving changes it makes. Without that features, nobody has any idea how much regression it is causing. -- Mikeblas (talk) 22:37, 22 December 2020 (UTC)[reply]

Here are some more:

I think it's increasingly clear that this bot shouldn't be performing edits until it is fixed. -- Mikeblas (talk) 14:13, 23 December 2020 (UTC)[reply]

Perhaps if the bot edits a template, it needs to edit any article that transcludes that template as well, so that any shared references are in sync. I just had to clean up after the bot at Signal (software), where the same thing happened. – Jonesey95 (talk) 15:50, 23 December 2020 (UTC)[reply]

There is a longer discussion at the bot noticeboard, but it would probably help for task 18 to be run on Category:Pages with duplicate reference names at least once a day, or at least on new additions to the category. Many of the articles in that category are fixable simply by hyphenating parameter names. – Jonesey95 (talk) 00:26, 28 December 2020 (UTC)[reply]

Mexicans

I was exploring the Mexicans wikipedia page and I found it was edited with racist rants against Mexicans CasualCommoner (talk) 07:33, 24 December 2020 (UTC)[reply]

@CasualCommoner: can you be more specific? If your referring to the article Mexicans, it has 153kB+ of content, which is a lot to search through for a vague complaint of "racist rant". A quote and a specific section would be helpful. - wolf 07:53, 24 December 2020 (UTC) (talk page stalker)[reply]

Been fixed by another editor.

—Trappist the monk (talk) 12:20, 24 December 2020 (UTC)[reply]

Question

Years ago, I was able to move the "preview" button away from the "publish" button to prevent accidental page-saves. Is there any way to move the "Log out" link to a different location? Thanks - wolf 07:37, 24 December 2020 (UTC)[reply]

Search the archives at WP:VPT. I recall seeing that log out link issue addressed there.

—Trappist the monk (talk) 12:21, 24 December 2020 (UTC)[reply]

@Thewolfchild: Should be doable. What skin are you using and where do you want it to go? --Izno (talk) 15:58, 24 December 2020 (UTC)[reply]

Hey guys, thanks for the replies. I'm editing on my phone using "Desktop view", and when trying to click on either "Contributions" or "Search' in the top right corner, I often click on "Log out" instead. (not a dire issue, just a pain in the ass) I was hoping to move the "Log out" link to another location. I did a search for "log out" via WP:VP, (where others have the same issue, aito) and I found these three posts;

Move Log out link in Monobook from 2011,
Accidentally logging out when trying to use search bar etc. on mobile from 2016 and
Proposal: “are you sure” page when clicking on “log out” before logging out from 2020.

The first and second discussions offer scripts to hide and/or negate the "Log out" link, or move it to another location. The third is a proposal to have an "Are you sure?" message box pop-up when you click "Log out", (which actually sounds preferable). This is a proposal that Ttm contributed to, it was archived before being actioned or closed. Do either of you know of any reason not to use this script? Otherwise I think I might give it a try.
To answer Izno's question, I just use the default "Vector" skin. I have just the one css page with script to for my "Preview" button.
Sorry about the length here, but maybe others will find this useful. I'll wait awhile to see if there are any replies before trying that script. Thanks again for all your assistance. Cheers - wolf 21:23, 24 December 2020 (UTC)[reply]

@Thewolfchild: Reviewing the 'are you sure' script from a soundness/safety perspective, it looks reasonable for someone looking for a way to deal with this problem. (You may of course have an interest in not using a script in someone else's user space.)

The discussion in archive 143 leaves off the other solution w.r.t. moving the link, which could be added to one of the sidebars or I think even the top navigation bar, or a more modern CSS solution, which could reposition it in the set of links in its normal area (i.e. moving it furthest left rather than furthest right, for example). --Izno (talk) 00:11, 25 December 2020 (UTC)[reply]

@Izno: I'm not sure I follow when you say "...using a script in someone else's user space." The instructions would have me create a common.js page in my own userspace, and add the script there. Am I misreading something? Also, has the solution in #143 been tested? Do you know where the link would go? And are there options on location? Thanks again - wolf 00:36, 25 December 2020 (UTC)[reply]

@Thewolfchild: You can copy-paste the script instead of those instructions, which has a benefit and detractor: the former is that you control what the script does which means you can rest assured that it will never be used maliciously. The latter is that it may be updated at some point in the future and you would miss the update. (Both are not necessarily likely, but the consequences of a minor script like this being updated are not weighed evenly against the consequences of a malicious script, which could result in the compromise of your account.)

I have not tested any of the solutions in 143 and do not know what will occur, though I can guess at what will happen if one of the links is moved. How about you tell me where you want the link to go (perhaps one of the places I mentioned earlier, perhaps somewhere else) and then we can talk about that solution?

There is another alternative, and that's to use a less finicky skin in general. Vector is (perhaps obviously) not designed today for a mobile skin, whereas Monobook, Minerva, and Timeless all have responsive representations. (Turning Monobook's responsive on is a step or two from memory; the other two are out of the box.) (And, Vector will have a responsive form sooner or later.) --Izno (talk) 01:01, 25 December 2020 (UTC)[reply]

I appreciate the feedback you provided, and based on it I think I'll give the pop-up script a try, in my userspace. Thank you also to Ttm for the info, and for hosting this little info session. Cheers & Happy Holidays to you both. - wolf 02:15, 25 December 2020 (UTC)[reply]

Happy Holidays!

Merry Christmas and a Prosperous 2021!

Hello Trappist the monk, may you be surrounded by peace, success and happiness on this seasonal occasion. Spread the WikiLove by wishing another user a Merry Christmas and a Happy New Year, whether it be someone you have had disagreements with in the past, a good friend, or just some random person. Sending you heartfelt and warm greetings for Christmas and New Year 2021.
Happy editing,
LorriBrown (talk) 05:46, 25 December 2020 (UTC)[reply]

Spread the love by adding {{subst:Seasonal Greetings}} to other user talk pages.

Merry Christmas

File:Christmas tree in field.jpg	Merry Christmas Trappist the monk
	Hi Trappist the monk, I wish you and your family a very Merry Christmas and a very happy and prosperous New Year, Thanks for all your contributions to Wikipedia this past year, like this tree, you are a light shining in the darkness. – SD0001 (talk) 15:07, 25 December 2020 (UTC)[reply]

Hyphens

Why is Monkbot adding hyphens in templates, such as accessdate > access-date? ATS (talk) 19:56, 25 December 2020 (UTC)[reply]

For parameter names that are multiword, as |accessdate= is, cs1|2 is gradually shifting to prefer the hyphenated form. Nonhyphenated parameter names that have been recently deprecated or are now no-longer supported are listed at Help:CS1 errors#Cite uses deprecated parameter |<param>=. Preemptively converting existing uses of the nonhyphenated parameter names prevents the flood of Cite uses deprecated parameter |accessdate= and similar error messages that would otherwise occur when those parameters are deprecated before support for them is withdrawn.

—Trappist the monk (talk) 00:12, 26 December 2020 (UTC)[reply]

Thanks for the response. I would note, however, that neither |accessdate= nor |authorlink=, the two I've seen 'corrected' thus far, is on the list. This seems an anticipatory move that could be years ahead of its time, if indeed ever. That said, I will not revert the bot further. ATS (talk) 03:15, 26 December 2020 (UTC)[reply]

|accessdate= and |authorlink= are not in the lists because they have not yet been deprecated. The bot is [preemptively] converting existing uses of the nonhyphenated parameter names so that when those parameter names are eventually deprecated, article space isn't flooded with the deprecated parameter error message.

—Trappist the monk (talk) 12:14, 26 December 2020 (UTC)[reply]

Have you any idea how much longer Monkbot is going to be doing this task? Nearly every entry I see in my watchlist is this Monkbot and frankly I've given up and cleared the watchlist. Martin of Sheffield (talk) 16:56, 27 December 2020 (UTC)[reply]

Predict the future? I can't do that. Based on the (somewhat unreliable) results of the cirrus searches listed in the bot's documentation page, when the bot started running there were something in excess of 2.8 million and maybe as many as 4 million articles that task 18 might edit. In the month or thereabouts that task 18 has been running, it has made 575,000+ edits.

—Trappist the monk (talk) 17:45, 27 December 2020 (UTC)[reply]

Is this really a good idea? It's concealing a multitude of sins

Well, I wonder how good an idea this is. It serves beautifully and powerfully to make it hard to detect empty parameters, always a *useful* sign of sloppy editing. Take this Monkbot edit which, it claims presumably truthfully: "(Task 18 (cosmetic): eval 89 templates: del empty params (266×); hyphenate params (26×); del |url-status= (14×);)". That is TWO HUNDRED AND SIXTY SIX pieces of sloppiness being swept under the carpet in one swift stroke. In that case a little search of the history reveals that some days earlier, "an editor" made this edit which added many of those incomplete citations. Nobody picked it up at the time; I wasn't watching the article, as it happens.

I think the bot should not be deleting empty parameters, for at least two reasons:

1) often, as just exemplified, empty parameters indicate incomplete citations, including vital details like publisher, URL (!), and page numbers. Just deleting them leaves a much more difficult task of detection, as (for instance) a simple search for "<param>= |" returns nothing.

2) sometimes, editors intentionally add empty parameters to mark items for further work; these are not always critical defects but may be desirable (e.g. non-mandatory URLs may be available for books or news items).

Perhaps this aspect of the bot's behaviour needs reconsideration. Chiswick Chap (talk) 17:50, 28 December 2020 (UTC)[reply]

Randomization

At Special:Diff/996774116 you asked for any advice on improving Module:Sandbox/trappist the monk/random sort. It looks like you made the mistake described in the second and third paragraphs of Fisher–Yates shuffle#Implementation errors. Since the error doesn't seem relevant to the discussion there, I brought it here instead.

Changing to r_idx = math.random (i, #source) should fix it to match the second code snippet at Fisher–Yates shuffle#The modern algorithm. Anomie ⚔ 19:14, 28 December 2020 (UTC)[reply]

@@ Line 182: / Line 182: @@
 Perhaps this aspect of the bot's behaviour needs reconsideration. [[User:Chiswick Chap|Chiswick Chap]] ([[User talk:Chiswick Chap|talk]]) 17:50, 28 December 2020 (UTC)
+== Randomization ==
+At [[Special:Diff/996774116]] you asked for any advice on improving [[Module:Sandbox/trappist the monk/random sort]]. It looks like you made the mistake described in the second and third paragraphs of [[Fisher–Yates shuffle#Implementation errors]]. Since the error doesn't seem relevant to the discussion there, I brought it here instead.
+Changing to <syntaxhighlight inline lang="lua">r_idx = math.random (i, #source)</syntaxhighlight> should fix it to match the second code snippet at [[Fisher–Yates shuffle#The modern algorithm]]. [[User:Anomie|Anomie]][[User talk:Anomie|⚔]] 19:14, 28 December 2020 (UTC)