User talk:Trappist the monk: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 16:55, 31 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]

There are thousands upon thousands of articles that use cs1|2 templates where the templates hold superfluous empty parameters. It is not possible for the bot to know why editors leave empty parameters. It is not possible for editors to know why other editors leave empty parameters unless the 'leaving' editors also include some sort of note explaining why they have left this or that parameter empty. My experience is that empty parameters left by editors tend to remain empty. Any interested editor can add parameters with values at any time to improve upon existing templates so leaving empty parameters as teasers for other editors is not necessary. Unless editors bestir themselves to improve a cs1|2 template, the template will not be improved regardless of any 'tantalizing' parameter left empty by a previous editor.

If removal of empty parameters were truly a bad idea, the community would have long since risen to object. That the community have not objected after 600k+ edits suggests that removal of empty parameters is not a bad idea.

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

Alternatively, people may respect the good work you do on templates and just accept the things they don't like being imposed on them out of respect. Martin of Sheffield (talk) 23:00, 28 December 2020 (UTC)[reply]

I'm one of those. I wholeheartly support the main task but consider three of the sub-tasks counter-productive, the removal of what-looks-like a template parameter in HTML comments (which trashes some comments), the removal of the valid |url-status= parameter with values different from live if no |archive-url= is given at the same time, and the unconditional removal of empty (known) parameters. I do support their removal if caused by the introduction of empty template prototypes but not if they were individually and deliberately added by editors to indicate an important missing parameter to other editors (and themselves).

I raised my concerns and proposed a more reasonable conditional removal process (based on a threshold value for the number of allowed empty parameters in a citation template), and also proposed a general alternative:

I didn't raise my concerns in the BRFA for Monkbot 18 because I didn't want to be accused for causing the general approval process to stuck (again), but I don't like the completely unnecessary collateral damage it creates.

Counting "not being reverted often" as indicator for support for the changes is, I think, a two-bladed sword. It could also be that the good changes (the main task) overrule the questionable ones, or that people value the otherwise good work and, peaceful as they are, don't want to escalate a conflict. After all, reverting someone's good-faith edits should only be done when absolutely necessary.

TTM: My experience is that empty parameters left by editors tend to remain empty.

My experience is a different one. It often takes a long time (months, sometimes years) for the empty parameter to be filled (or removed as unfillable) by editors, but eventually it gets addressed. Also, I find this to be a decades-long established "ad-hoc communication model" between editors working on articles and/or improving citations.

--Matthiaspaul (talk) 18:24, 30 December 2020 (UTC)[reply]

And I have seen multiple cases where it was obvious that the editor just copied the boilerplate from the template doc, filled in what they understood and left others to clean up the mess. Fortunately we now have a bot for that. --John Maynard Friedman (talk) 20:12, 30 December 2020 (UTC)[reply]

The big issue with bots like this though is the noise they generate. When your watchlist suddenly grows to dozens of entries per day it does become an issue. You either examine each one (in case they are obscuring a real edit) which takes an inordinate amount of time, ignore them, or give up and simply delete the watchlist until the bot has finished its run. That's why I asked for an estimate of the duration, apparently it will last for 5-8 months. Martin of Sheffield (talk) 23:27, 30 December 2020 (UTC)[reply]

Yeah, I have seen those cases as well (that's what I meant by template prototype above) and it's good that we have a bot to clean this up, but in the current implementation the bot fixes 100% of them, but at the same time also removes "legitimate" other uses which makes it more difficult to improve citations for editors. My observation is that in most of the first type of cases, many parameters (often dozens) are empty, whereas in most of the second type of cases, only a few parameters are empty. If the bot would not remove empty parameters if there are less than, say, four or five of them in a template, it would still catch the majority of cases of the first type, while leaving alone the majority of cases of the second type. There might be other criteria, but they would be more complicated to implemented. Thereby we could still get rid of the bulk of bad uses without hindering the good ones - like most good-faith human editors would do applying common sense and good editorial judgement. It would not be perfect, but better than the current "sledge-hammer" approach.

--Matthiaspaul (talk) 10:18, 31 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]

Thanks. I did not know that there was such a thing as the Fisher–Yates shuffle. I'll implement you fix.

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

Disagree with task 18: cosmetic, convert language names to codes

For List of 2016 albums, Monkbot performed Task 18 (cosmetic), which included User:Monkbot/task 18: cosmetic cs1 template cleanup#convert language names to codes. I disagreed with that decision and reverted all the language codes back to clear English, with the following edit summary as my reasoning: Reverted some edits by Wiki-bot as preference. Prefer language mention for translated articles to be spelled out in clear language rather than by country code, as clearer to the casual user.

Per Template:Cite book#Title: "language: The language (or a comma-separated list of the languages) in which the source is written, as either the ISO 639 language code (preferred) or the full language name." Although language code is preferred, the template allows for full language name, and it is my preference as a non-programmer to use clear English when possible. Without evidence of a debated upon and decided upon decision, I see this as preference, and will impose my preference on some articles. However, if there has been a debate, I would love to see the link, so that I can not be obstructionist. Mburrell (talk) 22:29, 28 December 2020 (UTC)[reply]

I have added List of 2016 albums to the bot's skip list.

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

Thank you. Can all the other <List of 20xx albums> be added to the bot's skip list? I have already gone through each of the lists from List of 2005 albums to List of 2021 albums and adjusted the archivedate to archive-date, archiveurl to archive-url, and accessdate to access-date, and just don't want to deal with the language translation.

I did appreciate the empty parameter clean-up you did, more because it revealed where I had forgotten to add a date or an author than that it was empty. Thank you for taking the time to do this excellent work. I know people generally speak up when upset or to challenge you, and I want to take the time to say thank you for doing this mostly thankless task. Mburrell (talk) 23:16, 28 December 2020 (UTC)[reply]

Added.

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

Salafi jihadism

I am sorry, I reverted your edits on Salafi jihadism, can you please do them again but without reverting my edits. Thanks Kiro Bassem (talk) 05:55, 29 December 2020 (UTC)[reply]

Greek places, language code changes

Here's a fun one for you. Monkbot's edit to Mesopotamo, Thessaloniki caused a duplicate reference error because it (unnecessarily, IMO) changed a clear full-text language name to a language code, causing a conflict with a previously identical reference in {{Infobox Greece place}}. That template is transcluded by 3,000 articles. I think that the template and its transclusions may need to be processed by the bot in a batch, or the reader-comprehensible language names may be better left alone. Or a third, even better way, which you are often good at coming up with. – Jonesey95 (talk) 05:54, 30 December 2020 (UTC)[reply]

This search suggests that there are 25ish articles that have the template and are also in Category:Pages with duplicate reference names. I've added those to the currently running batch.

—Trappist the monk (talk) 13:56, 30 December 2020 (UTC)[reply]

Thanks. It seems like this will continue to happen with templates and their transclusions. It might be worth reconsidering the quasi-random nature of Monkbot's page selection process. It might be better to operate from a list of templates that contain named references, along with pages that transclude those templates. There are probably not that many to process. (I know that is just a sample, but it's only 300, not 30,000.) I do not envy you all of the noise you are experiencing; you are a stouter soul than I. Let me know if there is any way I can help. – Jonesey95 (talk) 16:46, 30 December 2020 (UTC)[reply]

Here is a search that includes all cs1|2 templates; looks for |accessdate= in named templates; and omits ~/doc, ~/sandbox, and ~/testcases pages. It finds about 150 templates. Alas, I don't know how to automate the assembly of a list of articles that transclude those templates except to fetch that list of templates and with some regex slight of hand create a 'what-links-here' link and then copy/paste the result to a master list of articles. Ugh.

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

Stop Monkbot

Hi. Per this comment, please can you stop your bot. Thank you. Lugnuts ^{Fire Walk with Me} 14:42, 30 December 2020 (UTC)[reply]

Nomination of Noor Siddiqui for deletion

A discussion is taking place as to whether the article Noor Siddiqui is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Noor Siddiqui until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.

FalconK (talk) 02:32, 31 December 2020 (UTC)[reply]

Syncing leading to loss of translations

Please do refer to Module:Citation/CS1/Configuration. You have made a syncing recently from Sandbox that has led to loss of translations in the module. So, while syncing your changes, please confirm that the translations are not getting lost. Adithyak1997 (talk) 16:55, 31 December 2020 (UTC)[reply]

@@ Line 247: / Line 247: @@
 Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.
 <!-- Template:Afd notice --></div> [[User:Falcon Kirtaran|FalconK]] ([[User talk:Falcon Kirtaran|talk]]) 02:32, 31 December 2020 (UTC)
+== Syncing leading to loss of translations ==
+Please do refer to [[:ml:ഘടകം:Citation/CS1/Configuration|Module:Citation/CS1/Configuration]]. You have made a syncing recently from Sandbox that has led to loss of translations in the module. So, while syncing your changes, please confirm that the translations are not getting lost. [[User:Adithyak1997|Adithyak1997]] ([[User talk:Adithyak1997|talk]]) 16:55, 31 December 2020 (UTC)