User talk:Trappist the monk/Archive 16

Smallem help

Hey there!

The help you provided me with Smallem's source code is really appreciated. However I now get a strange error when I try to run it in the bash:

/mnt/nfs/labstore-secondary-tools-project/smallem/Smallem.sh: line 41987: unexpected EOF while looking for matching `"' /mnt/nfs/labstore-secondary-tools-project/smallem/Smallem.sh: line 41988: syntax error: unexpected end of file

Line 41987 is the last line and line 41988 doesn't actually exist but given that the parser wants to find an ending it tries to read one line below it (and fails to find it). At least that's what happening according to my understanding. I read that EOF errors are usually about missing parentheses so I simply searched for them. Surprisingly to me, I found out I had 704 ( and 703 ), so I guess that's the error? But I'm surprised as I don't remember adding any parentheses myself, they were all added by the module you helped create. Do you have any idea what might be happening? Or maybe it's not the parentheses themselves that are creating the problem but something else? Either way I think I need to somehow fix the missing parentheses problem too, now that I found out that it exists. But how do I find out where is the missing one among more than 40 thousand lines of code? - Klein Muçi (talk) 10:26, 4 November 2020 (UTC)

This is about sq:Moduli:Smallem? If you look at Template:Citation Style documentation/language/doc, you will see that there are lots of parentheses in the MediaWiki language names. Moduli:Smallem does not strip parentheses. Moduli:Smallem has not been changed since 16 September. It used to work, right? If it has worked before now, then something else is likely the problem.

The error message seems to suggest that a quote mark is missing: looking for matching `"'. You might try looking for that. What changes did you make? Did you leave out a quote mark or parenthesis as part of that recent change? Can you go back to a previous version? (You do have backups, right?)

—Trappist the monk (talk) 11:59, 4 November 2020 (UTC)

I'm very glad that you asked those questions. Please, bear with me while I answer them.

So, this is about the script that makes up the source code of Smallem (the robot). The source code is made of lines which I got by that module you mentioned + 18 more added lines. Now 3 of those extra lines make up the starting point and they're good on their own. Mostly commands on what to write as a summary when making edits, etc. Then there come around 40 thousand lines taken from that module which are the regexes for languages and then there come 15 more lines which are regexes to fix other small problems related to module CS1 (like removing ref=harv, etc). Now ever since we talked, the robot has run quite a few times but apparently all this time I had forgotten to add a / after the language regexes were finished so I could connect the code with the 15 extra lines. Therefore, all those lines were sort of ignored. Today I noticed that and I fixed it but by doing so, the robot stopped working altogether and I started getting those 2 messages in Git Bash. I thought maybe the problem is related to parentheses, even though the error message said something differently. And the fact that I found out an uneven number of brackets when using CTRL+F, made me doubt even more that something was related to them. Then I tried removing those 15 lines altogether and it worked fine so the problem is related to those lines (and they have no parentheses in them). So, maybe I can show you those 15 lines here and hopefully your eye can catch any error with regex in them? But still I'm a bit worried about the uneven number of parentheses. Any kind of regex I can use to search for those? Even though apparently that's not related to the problem I'm experiencing. - Klein Muçi (talk) 16:53, 4 November 2020 (UTC)

Since you have more left side parens than right side parens you might try to search for:

\([^\)]*\(

This assumes that parens aren't nested.

Sure, show me the 15 lines.

—Trappist the monk (talk) 17:10, 4 November 2020 (UTC)

Thank you! Apparently this is the line with uneven parentheses:"\|\s*language\s*=\s*Èdè\ Sípáníìṣì\ \(orílẹ̀-èdè\ Látìn-Amẹ́ríkà\)\ \(\ Èdè\ Sípáníìshì\ \(Látìn-Amẹ́ríkà\)\b" "|language=es-419" \ Not sure what I should do with it.

These are the 15 lines:

• "\b\|?ref\s*=\s*Harv\b" "" \
• "\b\nocat\s*=\s*true" "no-tracking=true" \
• "\b\nocat\s*=\s*yes" "no-tracking=yes" \
• "\b\nocat\s*=\s*y" "no-tracking=y" \
• "\b\|dead-?url\s*=\s*true" "|url-status=dead" \
• "\b\|dead-?url\s*=\s*yes" "|url-status=dead" \
• "\b\|dead-?url\s*=\s*y" "|url-status=dead" \
• "\b\|dead-?url\s*=\s*no" "|url-status=live" \

---

• "\[\[Kategoria:CS1\]\]" "" \
• "\[\[Kategoria:Gabime\ CS1.*\]\]" "" \
• "\[\[Kategoria:Mirëmbajtja\ CS1.*\]\]" "" \
• "\[\[Kategoria:Vetitë\ CS1.*\]\]" "" \
• "\[\[Kategoria:Gjuhë\ CS1\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ burime.*\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ gabime.*\]\]" "" \
• "\[\[Kategoria:Faqe\ që\ përdorin.*\]\]" ""

I tried adding the lines above one by one and it kept working fine until "\[\[Kategoria:CS1\]\]" "" \. So I guess I have something wrong there with the square brackets.

PS: While we're at it, I assume you understand what all those regexes are supposed to fix. Tell me if you see any problem or have any better way to write them. - Klein Muçi (talk) 17:26, 4 November 2020 (UTC)

The unbalanced parentheses is legitimate because the source is unbalanced:

{{#language:es-419|yo}} → Èdè Sípáníìṣì (orílẹ̀-èdè Látìn-Amẹ́ríkà)

To get that fixed you probably have to talk to someone at MediaWik, probably through phabricator.

I don't see anything wrong with \[\[Kategoria:CS1\]\] as regex but you have to escape space characters in the language-name strings (inside quoted strings no-less) so perhaps whatever tool you are feeding with these regexes requires that square brackets be specially escaped; or it could be the colon that needs to be escaped. What happens if you remove the square brackets and the colon (as separate tests)?

—Trappist the monk (talk) 18:17, 4 November 2020 (UTC)

I tried removing both separately and it worked. I then tried adding them (in the "classical" way) and it still worked... :P I'm confused. I mean the only way I have to see if it works or not is to make a job submission to the Toolforge server of the script and see what happens. After some seconds I see the job status. If its not working, I check the error file and I see if any error has been recorded there. That's not happening anymore and the job stays on the Running status. It would be wise to do a full run and wait until it is over but that would require around 3 days to complete. Guess that's what my next step will be, to see if it ends well, without any errors, while doing its job and not entering any infinity loops. But anyway that's away from the scope of this conversation. I'm just surprised it started working suddenly by its own. Maybe I had copied some kind of invisible characters and by recopying that part, it got fixed.

Do you have any suggestions how my Phab Ticket should be (on general lines) about that language? I've never reported things like that before in Phabricator. - Klein Muçi (talk) 18:51, 4 November 2020 (UTC)

If you copied the name from a wikipedia category page, there is an invisible U+200E LEFT-TO-RIGHT MARK character immediately at the left end of the category name before the space character that precedes the parenthetical page count. You can see it here for Category:CS1 maint: DOI inactive.

For phabricator, keep it simple. Give the language magic word as I did above, give the rendering, and simply state that the returned result contains unbalanced parentheses. Don't bother with categorizing it; let those who frequent phabricator do that. Maybe someday it will be fixed. You could add me as a subscriber.

—Trappist the monk (talk) 19:45, 4 November 2020 (UTC)

Maybe that's what has happened. It still shows no sign of stopping as a job now and I've deliberately put some errors in a Z starting article to check if everything is all right at the end. I'll see after 3 days I guess. I hope it works fine because every time I think I've fixed everything and let it run by its own, when it does, I discover another bug. It has been months now. Do the closing (left?) square brackets need to be escaped in regexes? Were those lines generally good in terms of fixing CS1 errors?

Thank you for the suggestions! I'll create it now. :) - Klein Muçi (talk) 20:07, 4 November 2020 (UTC)

Tracked in Phabricator
Task T267265

I guess that I would have written the regexes above the <hr /> differently:

• "\|\s*ref\s*=\s*[Hh]arv\s*([\|\}])" "$1" \
• "(\|\s*)nocat(\s*=\s*(?:true|yes|y)\b)" "$1no-tracking$2" \

  "\b\nocat\s*=\s*yes" "no-tracking=yes" \

  "\b\nocat\s*=\s*y" "no-tracking=y" \

• "(\|\s*)dead-?url(\s*=\s*)(?:true|yes|y)\b" "$1url-status$2dead" \

  "\b\|dead-?url\s*=\s*yes" "|url-status=dead" \

  "\b\|dead-?url\s*=\s*y" "|url-status=dead" \

• "(\|\s*)dead-?url(\s*=\s*)no\b" "$1url-status$2live" \

For those below the <hr /> I would not have used .*; it is much too greedy; I have rewritten those that use .*:

• "\[\[Kategoria:Gabime\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Mirëmbajtja\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Vetitë\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ burime[^\]]*\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ gabime[^\]]*\]\]" "" \
• "\[\[Kategoria:Faqe\ që\ përdorin[^\]]*\]\]" ""

The closing square brackets are on the right, not the left, in left-to-right languages like English and Albanian. I would always escape them when they are not intended to be the close of a set.

—Trappist the monk (talk) 22:12, 4 November 2020 (UTC)

Yes, you're right about the brackets. I mean, I thought the same but you giving me the initial regex about them confused me, making me think you we're calling the closing one, the left one, hence the question mark. It was my mistake. Okay then. Thank you a lot! Those regex-es were as far as I could go on my own while checking on Stack Overflow forums for help. Do the last ones regarding categories cover every single category in Kategoria:CS1? [Edit: Aren't 2 main categories missing there already?] I'm waiting for Smallem to complete its test run these 3 days and then, if hopefully everything is all right, I'm making the adjustments and doing another test with your suggestions. Whenever you have some free time, try to explain to me what those regexes do part by part. Maybe I'm able to learn a bit more and be more versatile with them in the future. Unfortunately for me, I have it hard to understand most of them. But take your time for that. And again, thank you a lot for your hardworking volunteering even outside of your homewiki. - Klein Muçi (talk) 23:21, 4 November 2020 (UTC)

I only rewrote the category regexes that needed rewriting (only those with .*) the others should be ok.

Here at en.wiki, editors complain when a bot or automated tool changes spacing in templates so to avoid that, I try to retain the spacing. This is accomplished in the various regexes by capturing the whitespace around the pipe, and the assignment operator. This one is pretty straightforward:

"\|\s*ref\s*=\s*[Hh]arv\s*([\|\}])" "$1" \

Because parameters are introduced by a pipe, that is the first character to match, then zero or more spaces, ref, zero or more spaces, =, zero or more spaces, Harv or harv, zero or more spaces, and finally a capture of the pipe that introduces the next parameter or the first } that closes the template. All of that gets replaced by the captured character in $1 (| or }).

The rest are more-or-less the same as this:

"(\|\s*)nocat(\s*=\s*(?:true|yes|y)\b)" "$1no-tracking$2" \https://www.mediawiki.org/wiki/Manual:Pywikibot/replace.py

Capture the introductory pipe and zero or more spaces; nocat; capture zero or more spaces, =, zero or more spaces, and one of true, yes, or y; assert a word boundary here to prevent a match on stuff like yeah. Replace the target string with opening capture ($1), new parameter name no-tracking, and the properly spaced assignment operator and assigned value in $2.

https://regex101.com/ might be helpful.

—Trappist the monk (talk) 01:28, 5 November 2020 (UTC)

Thank you for the explanations! I really got to learn how to make use of captured characters because they make way for a smoother experience. I have 2 more naive questions:

• Can (should?) the 2 main categories that were left untouched be rewritten in a similar way with the other ones? Mostly for standardizing reasons.
• We've talked in the past about the spacing problem between parameters in templates. In SqWiki doesn't exist a general complain like what exists here. Can we change the regex so that the replaced expression is always with a standardized spacing between parameters? - Klein Muçi (talk) 13:19, 5 November 2020 (UTC)

If Kategoria:CS1 and Kategoria:Gjuhë are prefixes in some other category names then perhaps yes; otherwise no.

You can make the find and replace be whatever you'd like (within reason); you don't need my permission.

—Trappist the monk (talk) 13:58, 5 November 2020 (UTC)

Haha, of course but I'm technically limited by knowledge to do that. :P So practically I'm depending on you on making the needed change and then hopefully I can replicate it in the future. That's what I meant above with that question. :P - Klein Muçi (talk) 14:04, 5 November 2020 (UTC)

Ok, what is the style that you want?

—Trappist the monk (talk) 14:52, 5 November 2020 (UTC)

The ideal: If 0 spaces in find, then 0 spaces in replace. If 1 or more spaces in find, 1 space in replace. You also tell me how to remove the "0 condition" in the future if so needed and make it only "1 space" for whatever situation.

If the ideal can't be achieved: 0 or more spaces in find -> 1 space in replace. - Klein Muçi (talk) 15:06, 5 November 2020 (UTC)

One space where? Before the pipe? After the pipe? After the parameter name? After the equal? Some combination of these? Are you wanting to establish a standard form or adapt to whatever form an editor may have used?

—Trappist the monk (talk) 15:21, 5 November 2020 (UTC)

I was trying to not repeat the last conversation we had about standards regarding spacing. The most widely used standard in SqWiki when it comes to cite templates is the one without any kind of space whatsoever. And for a long time, I've been following that too because I strive for a minimalistic approach when it comes to citations and whatever makes the "code clumps" appear bigger and more chaotic, makes the new editor more scared. Then you said that 1 space before each element could help in readability and given that I've been working a lot to teach my community that references are not just some "strange code you blindly copy-paste" but normal templates like the other templates you use throughout the article, that logic moved me a bit. So I was between 0 and 1 spaces (everything more than that would be unnecessary and disruptive). Hence the ideal approach. If the ideal can't be achieved, now that I think it better, maybe it would be better if 0 or more -> 0 spaces. - Klein Muçi (talk) 15:34, 5 November 2020 (UTC)

Sigh. Maybe if I use pictures ... Which of these if any:

1. {{<templatename>|param-name=value|param-name=value|param-name=value}}
2. {{<templatename> |param-name=value |param-name=value |param-name=value}}
3. {{<templatename> |param-name = value |param-name = value |param-name = value}}
4. {{<templatename> | param-name = value | param-name = value | param-name = value}}
5. some variant of one of the above

—Trappist the monk (talk) 15:59, 5 November 2020 (UTC)

XD I have been talking all the time for versions 1 and 5. So, ideally, if it is version 1, leave 1, if version 5 or (5` - with more than 1 space), replace with version 5. If we can't regexify this logic, then just make a regex that replaces everything with version 1. Easy. At least it should have been. :P - Klein Muçi (talk) 16:06, 5 November 2020 (UTC)

Version 1 seems a poor choice to me because it is entirely possible to create templates that do not allow for line-breaks. Consider long author-name lists that use |lastn= and |firststn= where the names don't contain space or hyphen characters.

It may be possible to write a regex to determine which of v1 or v5 style to apply when all parameters in a template are consistently formatted. But, there is nothing to prevent editors from writing something like:

{{<templatename>|param-name=value|param-name=value | param-name = value | param-name = value}}

Choose one. Split the difference and choose v2? That allows for a sufficiency of line breaks and keeps parameter-name/value pairs tightly coupled.

If you must have v1 and v5, then simple regex is not the answer because, properly, a tool should look at all cs1|2 citations in an article and then decide which of v1 or v5 formatting to apply.

—Trappist the monk (talk) 16:33, 5 November 2020 (UTC)

I've said v5 and 5` but really I meant v4 and 4`. My bad. But okay then... If you follow that kind of logic, I'm keeping the initial version of respecting the original standard. - Klein Muçi (talk) 16:53, 5 November 2020 (UTC)

3 days passed and Smallem finished his run normally. I've now started another run with your suggestions, hoping everything will run smoothly. I had only 1 problem though: Can you help me understand what has gone wrong here? It's related to one of the last 15 lines we talked about above. Although it must be kept in mind that this was before implementing your suggestions. - Klein Muçi (talk) 18:39, 6 November 2020 (UTC)

Remember what I wrote about .* being greedy? This is a good example of that. Prove this to yourself at https://regex101.com/. From sq:Çështja e mbyllur, copy the text that begins:

[[:en:Viz_Media|Viz Media]] shpalli blerjen e serisë për Amerikën e Veriut në 1 qershor, 2004...

and ends with:

...Wayback machine capture from Egmont Univers, archived 2011</ref>.

Paste that into the test string window at regex101.com then paste:

\[\[Kategoria:Mirëmbajtja\ CS1.*\]\]

into the Regular expression bar. Three matches that are much longer than they should be. Now replace the regex with:

\[\[Kategoria:Mirëmbajtja\ CS1[^\]]*\]\]

Still three matches but they are quite different.

—Trappist the monk (talk) 20:53, 6 November 2020 (UTC)

Yes, you're right. I've reset that change and started the second run with your suggestions. I think it will be redone good now. I have one more question, even though this will mean to drag you a bit out of your safe waters. I know you in EnWiki have certain templates that tell bots to ignore certain things. Do you know what the mechanism behind that usually is in regard to the bot? In SqWiki there is only 1 template, used rarely, that interacts wrongly with Smallem. It has the parameter of language, same as cite templates (this one is an infobox) but doesn't understand ISO codes, so around 10 or 15 articles that transclude it have problems now. What do you think would be the best way to handle this situation and how can the said solution be achieved technically, if you can help in there. At least theoretically. - Klein Muçi (talk) 03:03, 7 November 2020 (UTC)

The only template that I know of that controls bot access to an article is {{bots}}. When a bot reads an article it is supposed to look for that Template. When an article contains an unqualified template, {{bots}}, or a qualified template, {{bots|deny=smallem}}, then the bot is supposed to skip the article. The template itself does nothing except add a category for message opt-out.

I cannot answer any more of your question without knowing more about what the sq.wiki bot control template is and more about the infobox.

—Trappist the monk (talk) 12:34, 7 November 2020 (UTC)

Yes, I understand but I meant how usually bots implement this in their code. The skipping mechanism.

This] is the template I mentioned. Is probably outdated so it is not a problem per se but a lot of templates can have a language parameter in their code so I think it will be a problem with Smallem in the future if they don't know to render "sq" -> "shqip" (Albanian) or other languages.

And finally, I saw this problematic edit today from the new run with your suggestions. Do you think I've copied them wrongly or have you made a small typo? - Klein Muçi (talk) 13:08, 7 November 2020 (UTC)

I don't know, but I would presume that pywikibot has some sort of mechanism that understands {{bots|deny=smallem}}; it must if pywikibot tasks are allowed to run here.

One way around the |language= in non-cs1|2 templates is to qualify each regex; something like this:

"(\{\{\s*[Cc]it[ae][^\}]+)\|\s*language\s*=\s*shqip\b" "$1|language=sq" \

It will be slower ...

I think that the way I wrote the |dead-url=no regex find and replace is correct.

—Trappist the monk (talk) 14:30, 7 November 2020 (UTC)

Yeah, I'll try to learn more on that. As for the languages problem, I've thought about that but unfortunately the problem would persist with the disambiguations then. For example, in Albanian we have "cite" and "cito" for some cite templates. Truth be told, "cito" is almost never used and it is a bad attempt of translation which can be easily deleted but it does look like a can of worms starting that process which theoretically would have to take into account every possible alias of every possible cite template. I've thought about somehow specifying the search only between <ref></ref> tags but then I thought about other ways that are possible to approach the citing process which not necessarily use those tags so that too wouldn't be failproof.

Maybe it's my mistake then. I'll let the bot finish its full run, return that change, check that line again and do one more. Here goes another 3-day-period. - Klein Muçi (talk) 15:22, 7 November 2020 (UTC)

I double checked the actual Smallem source code. I really see no difference between what you have written here and I've copied there. To be absolutely sure, I'm posting its last lines here taken directly from the script in use now:

• "(\|\s*)dead-?url(\s*=\s*)(?:true|yes|y)\b" "$1url-status$2dead" \
• "(\|\s*)dead-?url(\s*=\s*)no\b" "$1url-status$2live" \
• "(\|\s*)nocat(\s*=\s*(?:true|yes|y)\b)" "$1no-tracking$2" \
• "\|\s*ref\s*=\s*Harv\s*([\|\}])" "$1" \
• "\[\[Kategoria:CS1\]\]" "" \
• "\[\[Kategoria:Gabime\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Mirëmbajtja\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Vetitë\ CS1[^\]]*\]\]" "" \
• "\[\[Kategoria:Gjuhë\ CS1\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ burime[^\]]*\]\]" "" \
• "\[\[Kategoria:Faqe\ me\ gabime[^\]]*\]\]" "" \
• "\[\[Kategoria:Faqe\ që\ përdorin[^\]]*\]\]" ""

Am I missing something? :/ - Klein Muçi (talk) 15:41, 7 November 2020 (UTC)

That regex find-and-replace does the correct thing when tested using awb's regex tester. Have you seen the same problem with the |deadurl=yes rule?

Have you tried running smallem with just the |deadurl=no rule? Does smallem do anything with 'dead'? Does smallem do anything with |url-access=?

Is there any real reason for including the parameter renaming and category removal in the language-name task? If they are separate tasks, the renaming task would be accomplished much more quickly than three days...

—Trappist the monk (talk) 16:18, 7 November 2020 (UTC)

You mean redirects, not disambiguation, right?

So do this:

"(\{\{\s*[Cc]it[aeo][^\}]+)\|\s*language\s*=\s*shqip\b" "$1|language=sq" \

Or, write a rule to change 'cito' to 'cite':

"(\{\{\s*[Cc]it)o([^\|]*)" "$1e$2" \

If cito is a flawed pseudo translation, get rid of it. Make it a redirect with the canonical name cite

—Trappist the monk (talk) 16:18, 7 November 2020 (UTC)

So, one by one. :P So far I've only had these 2 occasions: 1 and 2. These are occasions that have come by chance while Smallem is completing its full run now, not made deliberately by me. I haven't done any tests myself because I just discovered it now, as I said. Shouldn't it be easy to just make it not forget the pipe? :P That's the only problem that's happening, no?

I've grouped together 3 things that may be considered different in 1 task right now. The 40k something language regexes, the parameter fixes and category removals. The way Smallem is set to operate now is by running once every month automatically with a cron job to make the needed changes. Separating tasks would just artificially increase complexity. Time in general is not really a problem because everything will be automatized. It is only a problem now that I'm doing manual tasks. I could separate them temporarily but a) I thought I finished working with them and everything was good already and b) I wanted to have a full script fully working and to be fully sure about that so all my tests were being done using the full, original script.

The problem is that that would require some work. Like agreeing first if we are to use Albanian redirects (yes, I meant redirects) or no, what should these translations be, change all the articles that are using different versions of those templates and then decide what to do with Smallem. And even then, I would have to ask you to help me change the whole module related to it so it would change the whole languages, not only Albanian. And of course that would require some more tests with the new mode. With other problems like those mentioned above, I don't feel ready to go that way yet. Possibly in the future I'll be here asking for help in that way, after I've evaluated a bit the situation with our cite templates and their redirects. I was hoping for an easier, more elegant solution that wouldn't require me to change the whole regex and make it even more verbose, but apparently, fate isn't with me so this will have to wait. - Klein Muçi (talk) 17:09, 7 November 2020 (UTC)

|dead-url=yes → url-statusdead

Two things are missing: the pipe and the assignment operator. From this we can surmise that the regex find/replace is crippled because, apparently, it doesn't support captures:

"(\|\s*)dead-?url(\s*=\s*)(?:true|yes|y)\b" "$1url-status$2dead" \

It is hard for me to believe that is the case. There must be some special secret mechanism that allows the replacement value to hold captures. You'll have to talk to someone who knows about your particular use of pywikibot because I know nothing about it. Or, go back to brute-force replacement:

• "\|\s*ref\s*=\s*[Hh]arv\b" "" \
• "\|\s*nocat\s*=\s*(?:true|yes|y)\b)" "|no-tracking=true" \
• "\|\s*dead-?url\s*=\s*(?:true|yes|y)\b)" "|url-status=dead" \
• "\|\s*dead-?url\s*=\s*no" "|url-status=live" \

—Trappist the monk (talk) 17:33, 7 November 2020 (UTC)

Oh, I see... It's the capture mechanism of regexes that doesn't work. I would but right now, I'm literally asking in a IRC chat especially for pywikibots about some information related to scheduling up cron jobs and I'm not getting any answer. :P It has been really difficult getting any kind of technical support related to this subject so even though you may be not the best choice to ask about it, you've helped almost more than everyone else I've talked for it. I'll go back to the brute force version as soon as this run ends. I'll write you again with the final results after a few days. Thank you! :) - Klein Muçi (talk) 17:57, 7 November 2020 (UTC)

Aaand, I'm back. Apparently I can't add these 2 lines in the script:

• "\|\s*nocat\s*=\s*(?:true|yes|y)\b)" "|no-tracking=true" \
• "\|\s*dead-?url\s*=\s*(?:true|yes|y)\b)" "|url-status=dead" \

because the bash shell malfunctions with the parentheses. It doesn't understand that regex at all and the whole script stops running. :( Any way we can rewrite that? - Klein Muçi (talk) 01:32, 9 November 2020 (UTC)

Because I knew what I wanted to write, that is what I saw. That is why real writers have editors.

• "\|\s*nocat\s*=\s*(?:true|yes|y)\b" "|no-tracking=true" \
• "\|\s*dead-?url\s*=\s*(?:true|yes|y)\b" "|url-status=dead" \

—Trappist the monk (talk) 01:36, 9 November 2020 (UTC)

I'm really confused. Maybe I'm too tired at this hour but I can't understand what you mean. Maybe my first text wasn't clear enough? :/ - Klein Muçi (talk) 01:44, 9 November 2020 (UTC)

You didn't give me the exact error message but mentioned parentheses. The two find and replace that you mentioned have an extra ) which I removed in my reply. When I originally wrote those regexes I knew what I wanted them to look like so that is what I saw. Humans are often blind that way. Sometimes we have to be told that what we wrote doesn't say what we thought it said; that is why real writers have editors who point out to them, as the bash did to you, that what we thought we wrote is not what we actually wrote.

—Trappist the monk (talk) 01:59, 9 November 2020 (UTC)

Yess! You're right. I was able to do a side by side comparison to see if you had actually changed anything or not (my eyes really couldn't see any change) and then I saw that all this time, those lines had 1 extra ). I tried it like that and it works. Thank you for the explanation also. I've started another run, hopefully after 2-3 days, I'll be able to thank you for the last time without seeing any error in the process. - Klein Muçi (talk) 02:07, 9 November 2020 (UTC)

Smallem just redid one of the old replaces about the status of links (DoA) and it worked fine this time, so I guess the regexes are good. Anyway it still needs some time to finish the full run. Meanwhile I was able to find the right part of the Pywikibot's documentation regarding the skipping of articles or parts of it. Unfortunately for me, it wasn't clear enough to make use of it. You're more tech-savvy than me and even though you don't deal with pywikibots, maybe you can understand the documentation a bit better and explain it back to me. I thought I'd try it once because as I've said, technical support regarding those subjects has been really difficult to obtain for me. Keep in mind that this is not in any way urgent and given that it is also a bit outside of your area of expertise, you can take all the time that you want before answering.

So, for skipping, there are 4 commands:

• -excepttitle:XYZ - Skip pages with titles that contain XYZ. If the -regex argument is given, XYZ will be regarded as a regular expression.
• -excepttext:XYZ - Skip pages which contain the text XYZ. If the -regex argument is given, XYZ will be regarded as a regular expression.
• -exceptinside:XYZ - Skip occurrences of the to-be-replaced text which lie within XYZ. If the -regex argument is given, XYZ will be regarded as a regular expression.
• -exceptinsidetag:XYZ - Skip occurrences of the to-be-replaced text which lie within an XYZ tag. Possible values of XYZ include: ... (it's a list of tags I'm not bringing here)

I believe the third is the one I need for the cases I described above (skipping whole pages it's not good for Smallem's function and it would be considered an extreme solution while the last command doesn't seem useful in any way at the moment for me) but I don't understand exactly how to utilize it. I mean with the first command you would just switch XYZ with the needed title but here, how do I tell the script what is the text that it needs to lookout for and not do the replaces there? Do I literally put the whole text? This wouldn't be helpful to me because the template gets different parameter values in different articles. Do I just put the header and footer of a text? This would be helpful but I tried it and putting 2 values there make the script not work. I'm confused as how to interpret that explanation.

Everything above is copied from this page:mw:Manual:Pywikibot/replace.py - Section: Parameters - Klein Muçi (talk) 13:36, 9 November 2020 (UTC)

I was able to find out how to use it with trial and error. Basically you tell the need-to-be-overlooked-text by creating a regex for it. Now, given that you're the regex guru, what would be the best regex to use to exclude this template? So basically to tell Smallem not to look inside the parameters and values of that. A very basic regex could be \{\{Infobox\ organizatë.*\}\}, no? But you scolded me for using regex-es like that for being too greedy so... What should I do instead in this case? - Klein Muçi (talk) 15:27, 9 November 2020 (UTC)

No. Your simple regex doesn't work because it will swallow everything up to the last }} in the page. Consider sq:FIFA. Copy all of the wikitext from that article into the test string box at https://regex101.com/. Copy your regex into the regular expression line. You will have to change the regex flags so click the flag icon at the right edge of the regular expression box and then uncheck 'global' and 'multi line' and check 'single line'. This, I think, approximates how smallem regexes work. You will see that your regex matches everything in the FIFA page so the result is that you skip the page.

So you ask: can't we make the regex less greedy? Yep, but that won't give reliable results. Change your regex to this:

\{\{Infobox\ organizatë.*?\}\}

that isn't what you want because |languages= is outside of the 'skip' content (the infobox at FIFA is written with an unsupported parameter |languages= so would not have been touched by smallem).

You are looking for a simple solution to a complex problem which is made more difficult because the find and replace apparently can't use captures. It may be that you will have to settle on using awb to add:

{{bots|deny=smallem}}

and then use -excepttext with a regex like this:

\{\{\s*bots\s*\|\s*deny\s*=\s*smallem\s*\}\}

—Trappist the monk (talk) 16:35, 9 November 2020 (UTC)

That would be going into the rabbit hole, getting the rabbit out of its home and digging even deeper. :P If you opened the page I gave you above, you may have seen that "multiline" was one of the commands you could activate to modify how regex-es work. Dotall being the other one. Just a side information because I was just made aware of it now myself. (Maybe your captures could work if I activated the right command? But I don't know what I would need to activate for that to work.) If you see the template's page, it has errors in it. And the example you found with FIFA gave me the idea that its values can be made to not be the same as those of cite templates (at the language parameter) so basically, meh... If no easy solution can be found, I'll leave it like that for the moment. But, just wondering, what if we could make a regex that only searches for the language parameter + the one that comes just before it (membership, if I'm not wrong)? And if those 2 parameters are together in a row, Smallem, does nothing. Wouldn't that be a good solution?

On another subject, you can use the command -search:XYZ to limit the pages Smallem has to work on. For example, searching for "language=" would be the same as typing that in the search box, getting all the pages containing those words and letting Smallem only work with those results instead of working with every possible article. Do you think I could utilize that command in any way to shorten a bit the duration of 1 run? What strings would I need to search for to get everything Smallem has to do (the language regexes, the error fixings and the category removals)? Would that somehow shorten the duration or would it be basically only insignificantly shorter if not the same? - Klein Muçi (talk) 17:44, 9 November 2020 (UTC)

-dotall and -multiline don't have anything to do with captures. But...

I don't know if this works but there is an example:

"{{msg:(.*?)}}" "{{\1}}"

That suggests that $1 is not the correct way to include captures in the replace. So maybe this might work:

"(\|\s*)dead-?url(\s*=\s*)(?:true|yes|y)\b" "\1url-status\2dead" \

For you, it isn't really necessary because you have working regexes that don't need captures.

a regex that only searches for the language parameter + the one that comes just before it. That will fail the first time some editor decides to reorder the parameters in the template instance. You cannot rely on any specific something leading or trailing the parameter of interest.

Because it is your stated goal to have |language= as part of every cs1|2 template, wouldn't it be better to avoid the -search and use -transcludes with the Moduli:Citation/CS1 as the argument? Any page not using the module and so any page not using a cs1|2 template would be excluded from smallem's work. I don't know how much that would shorten the work cycle; that will depend on the percentage of sq.wiki articles that use cs1|2.

—Trappist the monk (talk) 18:52, 9 November 2020 (UTC)

I thought about that but usually users tend to preserve the order in these cases. (They tend to copy-paste from existing articles.) So that would be better than nothing while not doing any harm if it malfunctions? :/

Hmm, good idea. I didn't know you can use transclusion with modules. I thought you can use it only with templates. I run a simulation with -transcludes:Moduli:Citation/CS1 (+ -ns:0 | - -start:!) and these were the end results:

16394 pages read
0 pages written
5 pages skipped
Execution time: 167 seconds
Read operation time: 0.0 seconds
Script terminated successfully.

The real deal would take longer than that and I guess there would also be throttles but 16k pages is WAY BETTER than 90k pages. Is that the correct number though? How many pages transclude that module at SqWiki? I remember you could find it in an easy way. If the numbers match up, this would be a drastic improvement. I'm just not sure it worked correctly because the pages were in a random order (not alphabetically), not sure why. I guess that command (the module transclusion) would basically include all three functions that Smallem currently deals with, no? And most likely even the ones on the future, since they're usually (if not always) connected to that module. - Klein Muçi (talk) 19:40, 9 November 2020 (UTC)

This link will get 5000 pages that transclude sq:Moduli:Citation/CS1. On that page, count the number of times you click the next 5,000 link. I counted three pages of 5000 articles (initial + 2 clicks) and one page of 1400 articles for a total of 16400 which more-or-less agrees with your reported results. Not very elegant but does the job.

It is entirely possible that the categories exist in articles that don't use cs1|2. But, you've run smallem enough already haven't you that there shouldn't be any of those category wikilinks in any articles unless they were added since the last smallem run, right?

—Trappist the monk (talk) 20:04, 9 November 2020 (UTC)

And there is this link that gives 16,669 transclusions.

—Trappist the monk (talk) 20:16, 9 November 2020 (UTC)

Can't really understand what causes the change of number or the loss of alphabetic order but given that the number was similar, I'm going with that method. Smallem will finish his current run in a day and after that I'll start another one to test the new method, how long it will take. Meanwhile, can you explain to me in general what multiline and dotall are supposed to do if activated? And speaking of explanations, I strongly believe captures work with just plain numbers. Look what is written in a given example on that page:

...What do we replace it with?

With the text parts before, between and after the boldings — these are put in parentheses to be able to refer to them with their group numbers, respectively. $ python pwb.py replace -page -regex -recursive -dotall -summary:Vastagtalanítás "(\{\|.*?)([^\|]*?)(.*?\|\})" "\1\2\3" - Klein Muçi (talk) 03:01, 10 November 2020 (UTC)

Because .* is greedy, most (all?) regex engines stop the pattern matching at a newline to prevent .* from matching everything in the text. When it is desirable to include newlines in the matching, set -dotall. To avoid the all-consuming nature of .*, I almost never use it unless I am searching a short, already limited string of text. I can't think of any regexes that I have written that have required the use of the ^ and $ anchor assertions that are controlled by a multiline flag. I have only ever used ^ and $ when regexing short, already limited strings. So, I have insufficient understanding of what -multiline does to attempt an explanation.

The numbers aren't just numbers but are escaped numbers. For regexes that I write, captures are included in the replace value with $1, $2, etc. pywikibot, apparently uses \1, \2, etc.

—Trappist the monk (talk) 14:33, 10 November 2020 (UTC)

And my bow! --Izno (talk) 04:18, 10 November 2020 (UTC)

Hahahaha, thank you, Elven Izno! Now if we could understand what causes the changes between searches, it would be a step closer to Mordor. - Klein Muçi (talk) 08:53, 10 November 2020 (UTC)

The run of Smallem was completed. All good with the regex-es. I started the shortened version. I believe things would be a bit faster if I changed this:

# Slow down the robot such that it never makes a second page edit within
# 'put_throttle' seconds.
put_throttle = 10

I'm not sure I should though. I mean, Smallem runs only once a month and I guess it wouldn't be a problem for the server but then again, I don't know. I wish I could know any way to have some data on that. - Klein Muçi (talk) 13:05, 10 November 2020 (UTC)

Is smallem in a race where total number of edits in a specific time period determines the winner? If you remove the throttling, and something goes horribly wrong, fewer articles will be damaged before some local editor notices and does whatever is necessary to halt smallem – smallem/pywikibot does have some sort of emergency shutdown, right?

—Trappist the monk (talk) 14:33, 10 November 2020 (UTC)

As always, thank you for the explanations! As for the speed, of course not. But given that (not counting the manual testes) it only works 12 times a year, it doesn't work with all the articles and even when it does work, regexes are usually very verbose and don't leave much place for errors, considering that 99% of them are semi-automatically generated using the Smallem module, speed looks like just one of the aspects I can study for improvements. One of course might ask "why" but why do we generally strive for improvement in any other aspect? :P But I totally understand what you mean. After all, the regexes we used before this run was complete malfunctioned and I had to revert 90% of them (even though there was only a small total of reverts to be done). But the general idea was to understand the needed limits of throttling. Maybe the 10 seconds are too much and around 2-5 would be enough? Maybe they are too low and they don't give enough time to react if problems arise? I have no prior experience with situations like these and that's why I wanted a way to gather some data or maybe just some insight from past experiences of certain users.

As for halting it... I guess if you block the account everything will stop? (I don't know what would happen with the script if the account got blocked midway while working. I hope for no infinite loops.) I mean, don't 99% of the bots have only this mechanism? I know only IABot that has something more elegant than that. - Klein Muçi (talk) 15:09, 10 November 2020 (UTC)

Does smallem/pywikibot wait until an article has been saved before fetching the next article? In a sense, that is self throttling so smallem can't then overrun what the servers are capable of handling. But, if smallem can send a new article, fetch, edit, and send another article before the first has completed saving, then smallem is not self throttling. What does the pywikibot documentation (if any) say about throttling?

All of my bots run under awb. A message on Monkbot's talk page will halt the bot (drive-by ip editors seem to do it regularly – there was one this morning even though I'm not currently running the bot). I know that pywikibot has been / is used at en.wiki. Many bots here have some sort of user-triggerable shutdown which avoids the need to get an admin to block the bot. I did a quick look at pywikibots at en.wiki; all of those I looked at require an admin to block the bot; regular users, apparently, can't halt a misbehaving pywikibot.

—Trappist the monk (talk) 16:19, 10 November 2020 (UTC)

I believe it does because it does have many setting regarding throttling:

Extended content

# ############# SETTINGS TO AVOID SERVER OVERLOAD ############## # Slow down the robot such that it never requests a second page within # 'minthrottle' seconds. This can be lengthened if the server is slow, # but never more than 'maxthrottle' seconds. However - if you are running # more than one bot in parallel the times are lengthened. # # 'maxlag' is used to control the rate of server access (see below). # Set minthrottle to non-zero to use a throttle on read access. minthrottle = 0 maxthrottle = 60 # Slow down the robot such that it never makes a second page edit within # 'put_throttle' seconds. put_throttle = 10 # Sometimes you want to know when a delay is inserted. If a delay is larger # than 'noisysleep' seconds, it is logged on the screen. noisysleep = 3.0 # Defer bot edits during periods of database server lag. For details, see # https://www.mediawiki.org/wiki/Maxlag_parameter # You can set this variable to a number of seconds, or to None (or 0) to # disable this behavior. Higher values are more aggressive in seeking # access to the wiki. # Non-Wikimedia wikis may or may not support this feature; for families # that do not use it, it is recommended to set minthrottle (above) to # at least 1 second. maxlag = 5 # Maximum of pages which can be retrieved at one time from wiki server. # -1 indicates limit by api restriction step = -1 # Maximum number of times to retry an API request before quitting. max_retries = 15 # Minimum time to wait before resubmitting a failed API request. retry_wait = 5 # Maximum time to wait before resubmitting a failed API request. retry_max = 120

I have experimented with none of them so I wouldn't dare talk with much faith in myself about their specific functions. Unfortunately, the documentations says little if anything about throttling. As far as I've seen, throttling is mentioned only briefly when talking about global options (that, as you can imagine, are used to locally override the configuration in user-config.py settings, part of which is the one I sent above) and even there it is only one command: -putthrottle:n Set the minimum time (in seconds) the bot will wait between saving pages. (I believe this would override the one with 10 seconds we talked about before.)

In relation to bots being blocked by normal users, I know what you mean with AWB. I was surprised to see its mechanism in action one day when I got a notification in AWB that the script was stopping because I had received a wiki-message. (Which was related to my AWB changes malfunctioning so I'm glad for that.) Maybe a similar mechanism exists for pywikibots, I'm imagining a setting where you program the bot to be continuously on the lookout for a specific page in wiki (or for a specific text in that page) which, when it gets edited (or the specific text added), it sends a termination command to the script. MajavahBot (which is one EnWiki also uses for archiving processes, if I'm not wrong) works with principles like that and it is an archiving pywikibot. But 75% of the documentation regarding pywikibots is written with people who are not beginners in mind so small details like these are not explained anywhere. I'm yet to know if you somehow can change the existing pywikibots (take a look at the full list if you haven't done already) by somehow adding to their functionalities (or modifying them) with Python writing or not. Not that I would know how to do that personally but... - Klein Muçi (talk) 16:53, 10 November 2020 (UTC)

I've identified a problem related to the language regexes. Apparently (obviously) Smallem can't "fix" cases when there is more than 1 value at the language parameter. Only the first value gets transformed. Talking about cases like these: |language=xxxx, yyyy, ... Any small change I can make to the language regexes so it starts considering even those cases? (I'm guessing, whatever needs to be done, needs to be done even to the module related to those langauges.) Just for a reminder, this is the actual format for the languages: "\|\s*language\s*=\s*English\b" "|language=en" \- Klein Muçi (talk) 00:01, 11 November 2020 (UTC)

No.

The regexes as they are written need to know the spelled-out name and the MediWiki code. To do two languages, the regex will need to know both languages and their codes and then, it will be necessary to flip the order so:

"\|\s*language\s*=\s*English,\s*Albanian\b" "|language=en, sq" \

and

"\|\s*language\s*=\s*Albanian,\s*English\b" "|language=sq, en" \

It will get much more more complex as you add languages ...

—Trappist the monk (talk) 00:20, 11 November 2020 (UTC)

LOL To think that I had cases with around 7 languages in a row or so... :P I'll try fixing that with AWB for the moment and in the future... Oh well... :P Everything else is going good though, although the random order of the articles still surprises me a lot. As a courtesy of ending the conversation properly, I'll write here when it ends. :) - Klein Muçi (talk) 00:26, 11 November 2020 (UTC)

Okay, unfortunately, I've come to a point I can no longer ignore the false positives Smallem gives on other templates. Almost every infobox template has some of them now. I'm surprised I never thought myself that the language parameter might be present even on other templates except for citation ones. Totally blind thinking by me. What can I do? Is 99% of Smallem's code, together with its module, doomed to fail? Or I can choose to make Smallem to ignore these pages completely? Are those pages supposed to be forever locked with an anti-Smallem template? Would that behavior (putting deny-bot templates not temporarily) be considered normal by EnWiki standards? Other than that, things are working fine and this was supposed to be the last manual trial so I'm a bit sad to find out I might have to give up everything.

On the other hand, regarding the random order of the articles, the only pattern I've noticed is that they tend to become related in the subjects they have. For example, first you have many articles related to cities in Finland, then many articles related to political figures on Turkey, then... Does that tell you anything? - Klein Muçi (talk) 09:36, 11 November 2020 (UTC)

The run ended. It took approximately 1 day instead of the usual 3 days so that's a big improvement. There were no problems except for the false positives with infobox templates. In regard to the articles' order, they also tended to be chronologically somehow. With articles edited in the last days coming in the end of the run. - Klein Muçi (talk) 11:43, 11 November 2020 (UTC)

I suggested before that infoboxen are modified by smallem because the language regexes aren't constrained to the cs1|2 templates. The regexes could be modified so that they are something like this:

"(\{\{\s*[Cc]it[aeio][^\}]*\|\s*language\s*=\s*)Albanian(\s*[\|\}])" "\1sq\2"

This would require changes to sq:Moduli:smallem. There is some benefit to modifying the regexes because I have noticed that the word boundary assertion \b causes the regex to fail when |language=Chinese (Taiwan) (or any other parenthetically disambiguated language name) because ) is not a 'word' character. That means that smallem has skipped any of this type of language name.

I don't understand your fixation with alpha ordering. The ordering of the article list returned by whatever mechanism pywikibot uses will be in whatever order it pleases pywikibot. I presume that the list is fetched by an api or search call into MediaWiki somehow. If you take Editor Izno's search link, as an example, the list of returned articles is not ordered. The alpha ordering of the list does not matter.

—Trappist the monk (talk) 12:39, 11 November 2020 (UTC)

Hahaha Yeah man, of course. I know what you mean about the order. I just wanted to know the rule behind it because obviously we can't say it's random AND the order helps me in manual tests to anticipate something. For example, to know when the run is nearing its end (that would be the letter Z in an alpha order) so I am on the lookout to check for it, if I want to know the time period it took to complete it. Or for running micro-tests on the regexes and the speed on which the said regexes are applied to real articles. For example, making some small changes in articles like "!!" or "0" (which are the first in an alpha order) and running Smallem to understand how it would react to them (and cutting it off after the said articles are edited). In the "new way" I can only put a job command and cross my hands in my chest for 24 hours until the test (or simulation) is fully complete. Only to find out that it didn't go as planned and I need to do another one and another one, and another one...

As for the modification of the regex, my initial hope was to find a way to exclude them but you cut that hope short. :P I agree to your thinking (even though it would bring problems with redirections I suspect but that's a step we will need to take some time so...). I haven't been able to study much the templates themselves involved with the module. Every time I want to do that, it turns out the time has come to do an update to the module itself and that plan gets postponed. But I have problems really understanding the full scope of it. I get the [Cc] part (which wouldn't be needed because pywikibots have the command -nocase) but why the [aeo] part? - Klein Muçi (talk) 13:07, 11 November 2020 (UTC)

PS: Feel free to make a subsection on the next answer if you want. This thread is getting rather long.

Must match one of 'C' or 'c'; must match literal string 'it'; must match one of 'a' or 'e' or 'o'. So the pattern will match:

Cita <anything>

cita <anything>

Citation

citation

Cite <anything>

cite <anything>

Cito <anything>

cito <anything>

As for redirects, it appears that there are relatively few among the five most common cs1|2 templates (book, journal, news, web, citation):

sq:cite journal → sq:Stampa:Cito revistë shk

sq:cite news → sq:Stampa:Cito lajm

sq:cito web → sq:Stampa:Cite web, sq:Stampa:Cito uebin, sq:Stampa:Përmendin web

sq:citim → sq:Stampa:Citation, sq:Stampa:Cite document

There may be others; I didn't expend much effort in my search. Because of citim, I added 'i' to the regex.

The oddball is Stampa:Përmendin web. It is used in only two articles so you might want to consider updating the two articles and then deleting that redirect.

—Trappist the monk (talk) 14:26, 11 November 2020 (UTC)

Oh! So you were taking into account the redirects. I see. Well, okay then. Përmendin has been taken care of. Meanwhile, I'll try to revert Smallem's wrongdoings. Can you deal with the changes related to the module? - Klein Muçi (talk) 15:13, 11 November 2020 (UTC)

Done I think. A sampling of the new regexes is at sq:Përdoruesi:Trappist the monk/Livadhi personal.

—Trappist the monk (talk) 16:25, 11 November 2020 (UTC)

And I just finished the reverts. Thank you! But as I asked before, shouldn't we get rid of the [Cc] part? Also, given that you're already a close helper in Smallem, is there a way I could send you the whole code for it? Maybe it helps with your regexes. I would send it on email, but you haven't given one so, any preferred free sharing website? - Klein Muçi (talk) 17:08, 11 November 2020 (UTC)

My memory regarding search results is that non-basic results are returned either by page creation or page ID (effectively the same in context) and/or by the most recent edit date and/or by the last purge date. I would guess pywikibot is generating results similarly. --Izno (talk) 17:47, 11 November 2020 (UTC)

Yes, that is similar to the results I've seen but MEH! Still too random as an order for me to utilize in the ways I described above. Thank you though! :)) - Klein Muçi (talk) 18:35, 11 November 2020 (UTC)

I would rather be more explicit than not so I try to write regexes that specifically indicate what it is that I'm looking to match. I don't always succeed.

—Trappist the monk (talk) 19:22, 11 November 2020 (UTC)

Roger that. I'll first try a version with one C and then go back to this if things start to look bad. One last question before I bring Smallem 2.0: Me is dum so can you please remind me of the procedures needed for extracting the needed languages' regexes from the module? Maybe you can spare me some detective work. - Klein Muçi (talk) 19:29, 11 November 2020 (UTC)

It's crude:

• on a sandbox page add this: {{#invoke:Smallem|lang_lister|list=y}}
• on a separate line add this: {{#invoke:Smallem|lang_lister|lang=}}
• click Show preview (ignore the )

Recall that we cannot render a regex for each supported language for all of the 320+ Wikipedias in a single operation so you have to give sq:Moduli:Smallem groups.

• copy part of the list of wikipedia prefixes into the |lang= parameter of the second invoke
• click Show preview. If you get just a link to #invoke:Smallem, then the list is too big for MediaWiki to render. Don't be so greedy
• copy the results to wherever you want them, repeat

—Trappist the monk (talk) 20:40, 11 November 2020 (UTC)

Done. 42288 lines. How correct have I been? I remember you had a way to check for that. - Klein Muçi (talk) 07:54, 12 November 2020 (UTC)

42288. Give sq:Moduli:smallem the entire list of codes and let it run. It will fail. At the bottom of the preview page, click 'Parser profiling data' From the drop-down box under Lua logs, click 'Expand': count = 42288 is the number of regexes created for the given number of input codes.

—Trappist the monk (talk) 12:12, 12 November 2020 (UTC)

But why did Smallem 1.0, with 15 extra lines, have 41983 lines in total and Smallem 2.0 has 42288 lines in total with 15 lines missing from it? Where did these ~300 new lines came from? Should we think that there were new changes to the languages implemented by MediaWiki? - Klein Muçi (talk) 12:32, 12 November 2020 (UTC)

The basic code at sq:Moduli:smallem has not changed, so it must be fetching more languages from MediaWiki. MediaWiki is not static; change should be expected.

—Trappist the monk (talk) 12:51, 12 November 2020 (UTC)

I didn't know it was THAT dynamic though. That means I must be on the lookout for changes more often in the future. I'll start the test in a couple of minutes with the new version and we'll see what happens after 1 day or 2. Thank you! :) - Klein Muçi (talk) 12:59, 12 November 2020 (UTC)

Typo: Can you change module Smallem so that there's a space before the final slash in the line? It ruins the bash syntax if it is without a space. I didn't want to do it myself in fear of ruining the Lua syntax. - Klein Muçi (talk) 13:36, 12 November 2020 (UTC)

Done.

—Trappist the monk (talk) 13:44, 12 November 2020 (UTC)

I was forced to stop it midrun. Look at this edit. Apparently it's changing every language parameter with an empty value to language=got. (That's not the only case of that.) I don't know where this is coming from. A malfunction from the module? - Klein Muçi (talk) 09:35, 13 November 2020 (UTC)

That edit suggests that somewhere among the 42288 regexes there is one that might look like this:

(\{\{\s*cit[aeio][^\}]*\|\s*language\s*=\s*)(\s*[\|\}])

or like this:

(\{\{\s*cit[aeio][^\}]*\|\s*language\s*=\s*) (\s*[\|\}])

If the insertion is always got then that might help you to narrow the search

I added a test-probe to sq:Moduli:Smallem that looked for language names that are empty-string or language names that are just space characters and then forced the module to process the whole wiki-code list. It did all 42288 regexes but none were trapped by the test. Then I forced the module to process all of the wiki-code list but to only emit regexes for language code got. There are apparently only 69 of them; none were malformed. I saved a local copy of those got regexes so if you want to run smallem as a test with only those, tell me where to put them.

—Trappist the monk (talk) 11:53, 13 November 2020 (UTC)

I searched for both of the expressions above but none is to be found on Smallem's code. Then I searched for "\1got\2". I got 69 results too. You can put them here, after the last line, but how exactly would I use them? I mean, I can run a test with only those regexes, of course, but what would I be trying to prove with this? As for the code being always got, I believe that's correct. I didn't let Smallem do a lot of changes, it did only 5 in total. From those 5, 1 was correct, it removed the ref=harv from one article, the other 4, were as follows:

• 1st edit
• 2nd edit
• 3rd edit
• 4th edit - Klein Muçi (talk) 12:41, 13 November 2020 (UTC)

I don't know. What we do know is that got is inserted in the article wiki text so perhaps by testing with only regexes that have "\1got\2" we can see if any of these cause the problem and if so, which one or ones. So run the got list of regexes against the four articles and see what happens.

—Trappist the monk (talk) 12:55, 13 November 2020 (UTC)

Yes, it does happen again. In those 4 articles and more. Don't tell me I need to do 69 tests straight now. :P - Klein Muçi (talk) 13:05, 13 November 2020 (UTC)

Split the list in half and text each half. Does the problem occur in only one half? Split that half and test. Keep splitting. If in both halves split one to see if you can isolate the regex or regexes that cause the problem.

—Trappist the monk (talk) 13:19, 13 November 2020 (UTC)

I was able to identify the culprit. "(\{\{\s*cit[aeio][^\}]*\|\s*language\s*=\s*)𐌲𐌿𐍄𐌹𐍃𐌺(\s*[\|\}])" "\1got\2" \ gets rendered like (\{\{\s*cit[aeio][^\}]*\|\s*language\s*=\s*)(\s*[\|\}]) as soon as I put it into cmd. I don't know why but now I'm a bit worried. Maybe that happens with most (every?) non-Latin letter and this only drew our attention because it was at the start of the list? - Klein Muçi (talk) 15:32, 13 November 2020 (UTC)

the culprit. so none of the other regexes in the 69 caused the problem? If that is true then non-Latin characters in general is not the problem but, it would appear, that there is a problem with letters in the Unicode Gothic block (U+10330–U+1034A). I don't know what cmd is so perhaps the problem is with that? or with how you put it into cmd?

I extracted all of the language names associated with the got wiki. Of those, only these language names use non-Latin characters:

sty: себертатар – Unicode block: Cyrillic

got: 𐌲𐌿𐍄𐌹𐍃𐌺 – Unicode block: Gothic

ban-bali: ᬩᬲᬩᬮᬶ – Unicode block: Balinese

I suspect that the MediaWiki got list is falling back to the English language list for all language codes except got because:

{{#language:sty|en}} → Siberian Tatar

{{#language:got|en}} → Gothic

{{#language:ban-bali|en}} → Balinese (Balinese script)

I'm pretty sure that I complained about sty at phabricator because себертатар is not an English language name for Siberian Tatar. If I remember correctly, my complaints were dismissed. ban-bali is relatively new.

—Trappist the monk (talk) 16:25, 13 November 2020 (UTC)

No, none of them because I kept halving the list and each time one half didn't work, before halving it further, I tried the other half to make sure that that was fine by itself. Each time they were good. I did the same until they were only 2 entries left and this malfunctioned while the other one didn't. CMD is where I SSH to Smallem in Toolforge. Put simply, it's just some program in Windows I use to connect to the hosting servers of Wikimedia, where most, if not all, of the bots are located, and give commands to Smallem. The problem is that what if other non-Latin language's names, non related to got also have this problem. I'll try running Smallem's complete code without the culprit and see what happens. - Klein Muçi (talk) 16:48, 13 November 2020 (UTC)

Apparently nothing happens. Things tend to run smoothly if that line is removed, which no matter how I paste it, the language's name disappears and obviously it brings that problem. What do you suggest I do with it? Remove it altogether? It's strange though that from more than 40 thousand lines, only this one can't be pasted there. - Klein Muçi (talk) 17:08, 13 November 2020 (UTC)

What does that mean: Apparently nothing happens? Nothing good happens? Nothing bad happens? Something happens but you aren't sure if it is good or bad?

Blame windows? When I start cmd.exe and paste just 𐌲𐌿𐍄𐌹𐍃𐌺 at the command prompt, I get three little boxes. If at that point I change the focus to something other than the cmd.exe window, windows closes the app. If, instead, I paste 𐌲𐌿𐍄𐌹𐍃𐌺, get the three little boxes, and then tap the space bar once, I get two more little boxes (5). Change focus and cmd gets closed. Try again: paste and tap the space bar twice. Now I have all of the little boxes and two extra spaces tacked on to the end of 𐌲𐌿𐍄𐌹𐍃𐌺. Change focus, and the window doesn't get closed. I went to got.wiki and grabbed some random text and pasted it into the command prompt. Same sort of thing; keep tapping the space bar until it all gets pasted.

I guess that I wouldn't worry too much about it. According to this search, 𐌲𐌿𐍄𐌹𐍃𐌺 appears on only two pages in the whole of sq.wiki (53 pages here).

What we can do is tweak sq:Moduli:smallem so that when it encounters 𐌲𐌿𐍄𐌹𐍃𐌺, it skips it. Further, we can make it skip any language name that is written using the Gothic Unicode block. Perhaps in some future version of windows, cmd.exe will have learned to accept text written with the Gothic alphabet though I wouldn't hold my breath for that.

—Trappist the monk (talk) 17:45, 13 November 2020 (UTC)

Haha, good question. I was thinking you'd get confused by it. See, the point is that given the enormous number of manual tests I've been running (the real ones, not the simulations) there are not many errors left to fix in SqWiki anymore. What would happen as soon as I started it (Smallem 2.0) was that it would start making changes since the first few seconds. That's because apparently there are many articles that have a language parameter but no value in it. And that thing would happen over and over again until I removed that line, after which, it just started running but bringing no results, a sign Smallem wasn't fixing empty parameters anymore. After some minutes, I stopped the run. But given that it wasn't completed fully, I can't say with certainty that it works good (most likely it does) or that it doesn't have any other problems similar to this that would show themselves in the future, if I'd let the test complete. I can be sure of those things only if the test is completed but I wanted to do that after having decided what to do with that line.

As for the cmd.exe part, that's strange. When I paste it, I get nothing. Literally nothing. The cursor doesn't move at all. What type of Windows are you using? 10? There are other languages which cmd can't read and they appear as squares with question marks on them or other symbols, appearing somehow corrupted, there are many of them, but they bring no problem. Smallem knows how to read them (or if it doesn't, it is able to skip them? - they have never brought any problem) Only this special case doesn't get pasted at all. I've only switched to using cmd.exe lately. Until some days ago, I used this for that purpose. It worked fine. I switched to cmd only because it seemed somehow faster, with minor improvements in the interface and because cmd is an "originally built in program". I wonder if problems like these would happen with Git Bash or not. Or any other kinds of shells/bashs. - Klein Muçi (talk) 18:09, 13 November 2020 (UTC)

I tried it again. When I try it at the cmd.exe without connecting to Toolforge, you can paste it but you get 12 boxes with question marks in it. After you are connected, you get nothing anymore. Maybe Toolforge server can't read that somehow? I don't know but it is strange because, as I said, there are a lot of languages that are rendered like that in Smallem's code (when you bring it in cmd.exe/Git bash) but they haven't brought any problems before. Now this one does bring problems even though it is rendered like those other languages, but only when not connected to Toolforge though (tried it twice). I don't know what deductions to bring from all these. :/ - Klein Muçi (talk) 18:47, 13 November 2020 (UTC)

I tweaked sq:Moduli:smallem so that it detects Gothic Unicode block language names and skips them. When skipped, a message is written at the top of the rendering. See sq:Përdoruesi:Trappist the monk/Livadhi personal.

If the git command thing that you are talking about is the unix-like one, I used to have that installed on this machine until windows decided to crash catastrophically during an update. There was no repair for that except to reinstall windows which means that all installed programs like git got blown away. And the windows updater is an originally built in program...

—Trappist the monk (talk) 19:17, 13 November 2020 (UTC)

Yes, from what I've seen, it is sometimes described as an emulator of Unix/Linux bash for Windows. That's what Mediawiki's manual suggested I use for these kind of stuff. When I learned that it was nearly identical to cmd, I thought lex parsimoniae and deleted it. I was wondering now if getting it back would help in this kind of situation or no. :/

So you're saying to just get rid of it? My perfectionist side isn't really happy with that decision but I understand that this is probably a hardblock so... If I have the nerves to try it with Git Bash and it works, I'll be back here. If not, I'll try running the complete test now without that line and be back here when it's over, hoping for no other bugs along the way. As always, thank you for the patience you show! :) - Klein Muçi (talk) 19:55, 13 November 2020 (UTC)

Yep, until and unless you can communicate Gothic Unicode blcok characters to smallem, leave it out and get on with work that can be done.

—Trappist the monk (talk) 20:18, 13 November 2020 (UTC)

Judging by Smallem's edits, it should be approaching the end of his run anytime soon now. Nothing has gone bad so far so I guess everything's good. I'll tell here anyway when it ends. While we wait, I was wondering about this option in the manual regarding replace pywikibots: -pairsfile - Lines from the given file name(s) will be read as if they were added to the command line at that point. I.e. a file containing lines "a" and "b", used as python pwb.py replace -page:X -pairsfile:file c d will replace 'a' with 'b' and 'c' with 'd'. However, using python pwb.py replace -page:X c -pairsfile:file d will also work, and will replace 'c' with 'a' and 'b' with 'd'. I can't understand the explanation. Maybe you understand a bit more? I was wondering if it could be in any way related to the problem of fixing parameters with multiple values.

Also, staying on the same subject, can you help me understand the function of these 2 options:

• -recursive - Recurse replacement until possible.
• -allowoverlap - When occurrences of the pattern overlap, replace all of them. Warning! Don't use this option if you don't know what you're doing, because it might easily lead to infinite loops then.

These are the final 2 options I haven't asked you about and they're directly related to the regex searches. But this is no real problem so, as I've said once above, take your time in answering it. :) - Klein Muçi (talk) 12:04, 15 November 2020 (UTC)

Gibberish written by someone who knows what they meant but didn't have an editor to help them write what they really meant. I cannot decode that gibberish.

I don't know what the exact meaning of recurse is here. In computer programming, a recursive function is a function that calls itself (and calls itself (and calls itself (and calls itself (and calls itself)))) to do its task. AWB uses the term recurse when it gets article lists from categories which I take to mean that it takes articles from category (and subcategory (and subcategory (and subcategory))). I expect that to recurse a pattern means that pywikibot searches text and replaces (searches text and replaces (searches text and replaces (searches text and replaces))) until there are no more replacements to be made. This will not help with the language-list problem because the pattern is always the same.

Anything that contains warnings about infinite loops seems to me to be a good thing to stay away from unless you know exactly what -allowoverlap does. But, given the quality of the documentation and apparent lack of support for it, stay away.

—Trappist the monk (talk) 12:34, 15 November 2020 (UTC)

Hahaha, yeah, exactly my thoughts on all of those things. Even for recurse, that was my first idea. About categories or redirects. In regex it looks a bit strange to consider as an idea. I can imagine it could help in a situation like this:

Find: Cat
Replace: C

Text:Catat
-after regex-
Text:Cat
-with recurse on-
Text:C

But that looks like a too uncommon feature to include. Anyway, yes. I agree on everything. :P - Klein Muçi (talk) 14:11, 15 November 2020 (UTC)

And the run is over. No problems whatsoever discovered. I can't believe you had the nerves to guide me through all this. Wild ride it has been. Thank you! :)) - Klein Muçi (talk) 20:41, 15 November 2020 (UTC)

Category:CS1 maint: DOI inactive as of August 2020

Hello, Trappist,

No, this isn't about CSI:Miami, I just came across this empty, dated category that would ordinary be deleted as uncontroversial maintenance but I have never come across a category like this one before. So I thought I'd check with you to see if it was still of use and might not be empty soon. Thanks for any clarification you can provide. Liz ^{Read! Talk!} 01:40, 17 November 2020 (UTC)

The category should never be populated again once it has been cleared. Citation bot probably cleared the category by updating the |doi-broken= parameter as it did with this article which is now in Category:CS1 maint: DOI inactive as of September 2020. When empty and when time has passed the category by, delete.

—Trappist the monk (talk) 11:48, 17 November 2020 (UTC)

Diberri (Boghog) filling tool

Hi, User talk:Trappist the monk

You and I were editing endometriosis Diff at the same time. Thank you. I hope you are OK with my edits.

General information: I used the Diberri (Boghog) Wikipedia template filling tool, to complete it. Diberri (Boghog) generates a Vancouver style citation with PubMed ID (PMID), PubMed Central ID (PMCID), URL, ISBN, DrugBank ID, HGNC ID, or PubChem ID. -- Memdmarti (talk) 15:27, 21 November 2020 (UTC)

Yep, we were. And, yep, I know about that tool though I don't use it. You might want to introduce the tool to Huhiop whose name I have recently seen associated with similarly mangled cs1|2 templates. Whatever tool they are using inserts invisible   characters and does not properly format the names for |vauthors=.

—Trappist the monk (talk) 15:36, 21 November 2020 (UTC)

Alright for me thanks, I will look into the tool when time allowsHuhiop (talk) 15:40, 21 November 2020 (UTC) Just tried the tool, trully awesome would be cool if it could add automatically those at begining and end, "<ref name=> and < / ref >, thanks Memdmarti

Thank you, Huhiop and User talk:Trappist the monk! Also consider using SandyGeorgia's [LastName][year][p][page#] format for "ref name=." For the MRI article that would be "Ref name=Wild2020p20200690." "deependomri" is also descriptive and good. --Memdmarti (talk) 16:21, 21 November 2020 (UTC)

Short help

Hey, Trappist!

They made the needed change with the missing parenthesis on Phabricator. Can you help me see the end result in module Smallem so I know where to add that missing parenthesis on Smallem's source code? - Klein Muçi (talk) 11:38, 23 November 2020 (UTC)

I think you should wait until the fix is actually propagated so that we know exactly what it is that MediaWiki returns. Still broken here:

{{#language:es-419|yo}} → Èdè Sípáníìṣì (orílẹ̀-èdè Látìn-Amẹ́ríkà)

To see what sq:Moduli:smallem returns, run the module on only code yo; look for es-419. Currently it's this:

"(\{\{\s*cit[aeio][^\}]*\|\s*language\s*=\s*)Èdè\ Sípáníìṣì\ \(orílẹ̀-èdè\ Látìn-Amẹ́ríkà\)\ \(\ Èdè\ Sípáníìshì\ \(Látìn-Amẹ́ríkà\)(\s*[\|\}])" "\1es-419\2" \

Doesn't a simple text search of the smallem code for Èdè\ Sípáníìṣì get you to the correct location?

—Trappist the monk (talk) 11:55, 23 November 2020 (UTC)

Yes, it does but the problem is I don't really know where to add it. The parenthesis. It seems all Greek to me what I'm reading. :P Well, not really Greek but... XD - Klein Muçi (talk) 12:09, 23 November 2020 (UTC)

Why would you not replace the whole regex? When the fix propagates, run sq:Moduli:smallem on code yo, extract the es-419 regex from the code yo output, locate the broken regex in the smallem code and replace it? Why would you not do that?

—Trappist the monk (talk) 12:18, 23 November 2020 (UTC)

Well, that's exactly what I asked for. What should I run on module Smallem. Apparently "yo". That answers the question. :P - Klein Muçi (talk) 13:01, 23 November 2020 (UTC)

ArbCom 2020 Elections voter message

Hello! Voting in the 2020 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 7 December 2020. All eligible users are allowed to vote. Users with alternate accounts may only vote once. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2020 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 02:26, 24 November 2020 (UTC)

Script-title

Hi Trappist. I, too, used to place script-title but then I happened to read that this is reserved for occasions when the original title has been romanized for the title field. That is, you cannot have script-title without also having title. Here's the example from template:citation:

... |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower ...

I do not find it necessary to romanize Japanese titles in most cases. Best,  Mr.choppers | ✎  03:22, 23 November 2020 (UTC)

reserved? you cannot have script-title without also having title? I don't know where you read that, but it is utter nonsense. |script-title= does not require |title= and never has. The various |script-<param>= parameters are always useful because, under the bonnet, they indicate to browsers and screen readers the language of the text they contain so that those user agents can render or speak the text correctly. Further, when Latin script would be italicized in |title= and any of the various |periodical= parameters, using the |script-<param>= parameters prevents the cs1|2 templates from italicizing CJK script.

Please tell me where you read this nonsense so that I can fix it.

—Trappist the monk (talk) 04:06, 23 November 2020 (UTC)

At Template:Citation#Title. "If script-title is defined, title holds a Romanization of title in script-title."  Mr.choppers | ✎  14:15, 23 November 2020 (UTC)

I think that you are reading more into that than exist. Still, I have tweaked the text a bit.

—Trappist the monk (talk) 14:58, 23 November 2020 (UTC)

Forgive my ignorance, but shouldn't |language= provide what browsers etc need to operate properly? Then |script-title= would only apply when one wanted to romanize a title. Anyhow, this is above my pay grade, just wanted to make sure that everyone who writes at Template:Citation are on the same page. Best,  Mr.choppers | ✎  02:45, 24 November 2020 (UTC)

@Mr.choppers: |language= defines the language of the work, not of the title. Even so, there are presumably titles which are romanized directly rather than being written in the particular script, so even then |language= would be insufficient. --Izno (talk) 17:43, 24 November 2020 (UTC)

@Izno: That is true.  Mr.choppers | ✎  18:44, 24 November 2020 (UTC)

Discussion at Help talk:Citation Style 1 § Meta proposal to globalize the CS1 templates

 You are invited to join the discussion at Help talk:Citation Style 1 § Meta proposal to globalize the CS1 templates. Jo-Jo Eumerus (talk) 08:36, 25 November 2020 (UTC)

Merge proposal which you may be interested in

Please see Tfd, where I proposed to merge Template:Lang-he-n into Template:Lang-he. Debresser (talk) 09:55, 25 November 2020 (UTC)

Notice of something the bot did

Nothing too concerning, but I noticed that one of the edits made by Monkbot (which is a godsend, thank you very much) here, from Convexity in economics, moved a pipe into a comment when the pipe was genuinely in use. I don't blame the bot, as it was weirdly formatted, but I figured I'd fill you in on this silly business. -BRAINULATOR9 (TALK) 02:02, 26 November 2020 (UTC)

It is a truism that bot code never survives first contact with Wikipedia editors. I'll look into it, thanks for the report.

—Trappist the monk (talk) 13:09, 26 November 2020 (UTC)

Monkbot

Hi @Trappist the monk: I see the Monkbot on the Gisela von Pöllnitz article, it is changing the language property on the refs from German to de. Why would it be changing to de, instead of German. Most folk don't know that the de, domain or localization symbol means German. What happens if becomes a more a obscure language like Hungarian for example. Instead of pointing to the actual language page, we have this? What is the point of it? scope_creep^Talk 18:31, 26 November 2020 (UTC)

The edit summary for this task 18 edit begins with a link to the bot's documentation page: User:Monkbot/task 18: cosmetic cs1 template cleanup. On that page is this section: User:Monkbot/task 18: cosmetic cs1 template cleanup § convert language names to codes which, I think, describes the rationale for those edits.

—Trappist the monk (talk) 18:40, 26 November 2020 (UTC)

Cosmetic changes

As bots actually allowed to make changes which are merely cosmetic? (ping resopnse, please) Beyond My Ken (talk) 18:59, 26 November 2020 (UTC)

It would appear so. Because of the discussion at Wikipedia:Village pump (proposals) § Cosmetic Bot Day (CBD), I got to thinking about a cosmetic bot that would cleanup cs1|2 templates. WP:COSMETICBOT says:

Consensus for a bot to make any particular cosmetic change must be formalized in an approved request for approval.

When the bot's code was sufficiently complete, I submitted the task as this WP:BRFA. The request was approved, so it would appear that with the appropriate approval, bots can be allowed to make changes that are merely cosmetic.

ping

—Trappist the monk (talk) 19:49, 26 November 2020 (UTC)

OK, thanks, I thought it might be something like that. Beyond My Ken (talk) 20:16, 26 November 2020 (UTC)

Calling Santa Clause for help

One last try: Take a look - Klein Muçi (talk) 09:27, 20 November 2020 (UTC)

Santa answered! Please, take a look at Meta regarding Yurik's tool. - Klein Muçi (talk) 12:06, 27 November 2020 (UTC)

Monkbot deleting 'author-link's?

In the last change in diff [1], Monkbot deleted what appears to have been a valid author-link= parameter from a cite book transclusion. Should it not do that, or was there something wrong with the parameter that I'm missing? Thanks, —2d37 (talk) 05:31, 27 November 2020 (UTC)

(For now, I've un-deleted the parameter. —2d37 (talk) 05:45, 27 November 2020 (UTC))

Here's the diff in which the editor fixed this apparent bot error. – Jonesey95 (talk) 05:54, 27 November 2020 (UTC)

Thanks for the report. I tweaked the bot's code and ran it against the current version of Linear algebra; Hefferon went untouched.

—Trappist the monk (talk) 12:25, 27 November 2020 (UTC)

Access date hyphenation

Hi there, I note that you added a hyphen to the access date in the citations on the page for Helen Petousis-Harris. Is there any value in doing this? I just use the template to enter this and it comes out without a hyphen, accessdate. I have no issue with what you have done; just wondering if is required, or more importantly, is anything lost by not doing it? Greg Realitylink (talk) 03:34, 28 November 2020 (UTC)

I don't know what it is that you mean by: I just use the template to enter this and it comes out without a hyphen, accessdate. |accessdate= is a parameter in a cs1|2 template. Do you mean something other than template? A tool perhaps? If so, what tool?

—Trappist the monk (talk) 12:26, 28 November 2020 (UTC)

Hyphenated parameters

2_parameter_names links to this RfC in stating that the unhyphenated names have been deprecated. However, that wasn't the question asked by the RfC - it specifically was not intended to eliminate any other form, just to ensure that the hyphenated form existed for each appropriate parameter. Was there another RfC where consensus was established to deprecate the unhyphenated form? Nikkimaria (talk) 21:58, 27 November 2020 (UTC)

Umm, §hyphenate cs1|2 parameter names does not say that unhyphenated names have been deprecated:

Because cs1|2 is an amalgam of several individually developed templates, it acquired a variety of parameter-name styles: |lowercase=, |Capitalized=, |camelCase=, |underscore_separated=, |space separated=, |hyphen-separated=, |allruntogether=. The |Capitalized=, |camelCase=, |underscore_separated=, and |space separated= parameter name styles have all been deprecated and support for these styles withdrawn in favor of the |lowercase= and |hyphen-separated= forms as a result of this RfC. For parameter names that are multiword, cs1|2 is gradually shifting to prefer the hyphenated form. The table lists the all-run-together form with the approximate number of articles that transclude cs1|2 templates using these parameters. Task 18 replaces the all-run-together forms of these parameters with the hyphenated forms.

The link to the RfC is there as historical background.

—Trappist the monk (talk) 23:17, 27 November 2020 (UTC)

Hi, regarding "For parameter names that are multiword, cs1|2 is gradually shifting to prefer the hyphenated form", where is this discussion taking place? How roughly how many editors are involved in making these decisions? Jason Quinn (talk) 00:41, 28 November 2020 (UTC)

Agree: where is/was this shift discussed? Your comments in the bot request include that "non-hyphenated cs1|2 parameter names are going away", and the discussion seems to make the assumption of deprecation. Nikkimaria (talk) 01:19, 28 November 2020 (UTC)

With few exceptions, discussion related to cs1|2 takes place at Help talk:Citation Style 1 – all of the cs1 template talk pages redirect there as do all of the Module:Citation/CS1-suite talk pages (except ~/COinS). Additional discussion related to cs2 takes place at Template talk:Citation but there has been recent discussion to also redirect that to WT:CS1. How many participants? I don't know. As many as were interested in participating in the discussions. Isn't that how it always is?

Quite a few non-hyphenated parameter names have already been deprecated. For lists of currently deprecated and recently unsupported nonhyphenated parameters, see Help:CS1 errors#Cite uses deprecated parameter |<param>=. At the next module suite update, these parameters will be deprecated:

|conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |seriesno=, |sectionurl=, |timecaption=, and |titlelink=

—Trappist the monk (talk) 02:07, 28 November 2020 (UTC)

I don't see any relevant discussions currently on that page; what specific discussions decided this? Nikkimaria (talk) 02:20, 28 November 2020 (UTC)

I don't have the time this morning to hunt those down. All discussions at WT:CS1 are archived. A good thing to look for is the module suite update announcements where I list all changes that will be made to the module suite with links to the discussions about those changes.

—Trappist the monk (talk) 12:59, 28 November 2020 (UTC)

From the last cs1|2 update (2020-10-10):

• deprecate |editors= parameter; discussion
• add |trans-quote=, |script-quote=, |page(s)-quote=; discussion
• remove support for |series-separator=; discussion
• remove support for |ignoreisbnerror=, |doi-broken=, |doi-inactive-date= and rename |embargo= to |pmc-embargo-date=; discussion
• add support for missing aliases |author-given#=, |author#-given=, |author-surname#=, |author#-surname=, |interviewer-given#=, |interviewer#-given=, |interviewer-surname#=, |interviewer#-surname=, |display-subjects=; discussion
• remove support for unused aliases |displayeditors=, |editormask= and enumerated forms; discussion
• remove support for unused aliases |notracking= and |no-cat=, made |no-tracking= the canonical form for now; discussion
• add |subject-mask= parameters; deprecate non-hyphenated subjectlink params; discussion
• remove support for |interviewerlink= and |interviewermask=; add support for missing aliases |author-given=, |author-surname=, |author-given#=, |author#-given=, |author-surname#=, |author#-surname=, |interviewer-given#=, |interviewer#-given=, |interviewer-surname#=, |interviewer#-surname=, |display-subjects=; discussion
• remove support for unused aliases |displayeditors=, |editormask= and enumerated forms; discussion
• deprecate |displayauthors= as well as |editorlink=, |authormask= and enumerated forms; discussion
• deprecate |ignore-isbn-error=; discussion discussion

The to-be-deprecated-at-next-module-update parameters were discussed here

—Trappist the monk (talk) 23:08, 28 November 2020 (UTC)

I've been looking through archives, and haven't been able to find either a discussion with consensus to generally deprecated unhyphenated parameters, or specifically to deprecate |accessdate=. Do you have links for either of those? Nikkimaria (talk) 02:24, 29 November 2020 (UTC)

Nope. You can clearly see the trend in the above mentioned deprecations. I don't think that I have ever said that |accessdate= has been deprecated.

—Trappist the monk (talk) 13:02, 29 November 2020 (UTC)

Then on what basis is your bot replacing it? Nikkimaria (talk) 13:57, 29 November 2020 (UTC)

Were we to deprecate |accessdate= today, some 2.8 million articles would bleed red error messages. And they would bleed a lot because of the ubiquity of that parameter name. All of that blood is more than sufficient to incite the community to rise, to fetch their pitchforks from the barn, and to light their torches. Avoiding that kind of drama seems to me to be a good thing.

—Trappist the monk (talk) 14:22, 29 November 2020 (UTC)

So to sum up: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people? Looks like replacing it without consensus is already annoying people. Please only have your bot replace parameters for which there is already consensus to deprecate. Nikkimaria (talk) 14:29, 29 November 2020 (UTC)

I think you pretty much nailed it here. There's no consensus to automatically replace "accessdate" with "access-date". Please stop. oknazevad (talk) 14:38, 29 November 2020 (UTC)

Help talk:Citation Style 1 § deprecation and removal of nonhyphenated multiword parameter names

—Trappist the monk (talk) 12:44, 30 November 2020 (UTC)

Thanks for the information, Trappist. That next set parameters are very rarely used and affect only a small number of pages. The one I noticed was the change of |accessdate=, which is ubiquitous, to |access-date=. Was there a reason |accessdate= was changed before the uncommon parameters? Maybe it would be best if a larger, more visible discussion had been made for |accessdate=? As the person in the discussion below states, there may be tools still using |accessdate= so it might not make sense to change these before the tools are changed. As for me personally, I actually find that the un-hyphenated version of |accessdate= is preferable because the hyphenated version linebreaks, and that linebreak introduces a significant parsing slowing (for humans) when scanning the source code as you have to scan both the right and left side of the textfield in the source editor. In other words, |accessdate= is more pragmatic than |access-date=. While I realize that argument might be made for any of the hyphenated parameters, I really think |accessdate= is different because of how common it is. Jason Quinn (talk) 05:13, 28 November 2020 (UTC)

|accessdate= is not being changed ahead of the more uncommonly used nonhyphenated parameter names; all nonhyphenated parameter names are being changed when they are encountered. It only appears that task 18 is 'focusing' on |accessdate= because it is more commonly used.

Yeah, perhaps, but you have to you have to scan both the right and left side of the textfield in the source editor when a line break occurs in a parameter's assigned value – any parameter value with a hyphen and any parameter value with a space. The parsing slowdown for either seems a wash to me.

—Trappist the monk (talk) 12:59, 28 November 2020 (UTC)

Count me as another editor who questions the need to add a hyphen to accessdate. It doesn't seem to serve any significant purpose and bloats the code, which seems to run counter to the main purpose of this bot to cleanup citations by removing unused parameters and reduce bloat. The RFC above made it pretty clear that both the hyphenated and unhyphenated versions are perfectly acceptable (other formats were depreciated). I would argue that it should be removed from the bot's changes as it's needlessly changing from one acceptable style to another, in violation of the spirit of WP:CITEVAR. oknazevad (talk) 11:42, 28 November 2020 (UTC)

I have run out of time. I will return to answer you later – probably between 1800 and 2400 UTC.

—Trappist the monk (talk) 12:59, 28 November 2020 (UTC)

The most hyphens added to an article yesterday was 1230 with this edit to Android (operating system). A 1k byte addition to an article that is 330k-ish bytes (that's probably overly large) is hardly bloat.

—Trappist the monk (talk) 23:08, 28 November 2020 (UTC)

I likewise will add that I prefer consistency, concise wording, and no line break here with my refs, therefore "accessdate". Please stop this bot task. ɱ (talk) 03:30, 29 November 2020 (UTC)

If consistency is the criterium, then you want task 18 to continue despite what you wrote as an edit summary when you reverted this task 18 edit. Before the task 18 edit there were:

• 121 |access-date=
• 187 |accessdate=
• 5 |archive-date=
• 3 |archivedate=
• 5 |archive-url=
• 3 |archiveurl=
• 1 |author-link=
• 4 |authorlink=
• 0 |series-link=
• 1 |serieslink=

after the task 18 edit there were:

• 307 |access-date=
• 8 |archive-date=
• 8 |archive-url=
• 5 |author-link=
• 1 |series-link=

One empty |accessdate= was deleted along with: |first= (2), |isbn= (2), |last= (2), |page=, |pages= (5), |website=, and |url=.

I have added Grand Central Terminal to the bot's skip list.

—Trappist the monk (talk) 13:02, 29 November 2020 (UTC)

A barnstar for you!

	The Original Barnstar
	Thank MonkBot for being so diligent. Firestar464 (talk) 07:19, 2 December 2020 (UTC)

Monkbot keeps archiving links and references that are still LIVE

Hello, in the articles NAACP and Florida State Road 538 Monkbot is archiving links and references despite the fact that the majority of the links are actually still live, there is possibly a misconfiguration or the bot has gone off its rocker :0) can you please look into this, I'd hate to have someone think that the Monkbot is vandalizing when its just trying to do its job. Thanks. YborCityJohn (talk) 15:12, 1 December 2020 (UTC)

@YborCityJohn: On the article NAACP it removed two |url-status=live because there was not an archive URL for either link. |url-status= is necessary only when there is an archive URL. I expect FSR 538's removals are for the same reason. --Izno (talk) 15:16, 1 December 2020 (UTC)

I think that you are mistaken. Monkbot task 18 does not archive anything. See the task 18 documentation for explainations of the things that task 18 does do.

—Trappist the monk (talk) 15:30, 1 December 2020 (UTC)

I see that in Florida State Road 538 the bot missed around 19 'accessdate' entries. Perhaps because bounded by spaces? Have moved 'accessdate = ' to 'accessdate='. I find the hyphenated versions far easier to read. Keep up the good work. I see the point regarding wordwrap, mentioned earlier, and I sometimes wonder if segmentation rules regarding non-breaking hyphens, etc, are around the wrong way, however we could write books on that. Neils51 (talk) 17:06, 2 December 2020 (UTC)

Thanks. At the moment the |accessdate= to |access-date= fix is disabled as a result of the §Hyphenated parameters discussion above. I hope to reenable that fix so those 19 in Florida State Road 538 (and about 45k other articles – so far) will get fixed ... eventually. The bot is white-space aware so any (or no) whitespace around a parameter name is not an issue.

—Trappist the monk (talk) 17:15, 2 December 2020 (UTC)

Trappist the monk, would it be possible to grab the HTML before/after a save and self-revert if there are a greater number of cite errors afterwards? Might cut down on some of these bug reports. Enterprisey (talk!) 09:14, 3 December 2020 (UTC)

What errors? If you look at the before and after linked from these diffs, you will see that task 18 did not introduce any errors:

• NAACP diff of first edit
• NAACP diff of second edit
• Florida State Road 538 diff

—Trappist the monk (talk) 12:57, 3 December 2020 (UTC)

Thank you!

Just thought I'd pop by to say how great Monkbot is, pretty impressive and much appreciated! LittleDwangs (talk) 23:02, 5 December 2020 (UTC)

Cite OED template

Hi Trappist: I wasn't sure if you were aware that your update to the {{cite OED}} template seems to have introduced an error. There's now a "Missing or empty |title=" message coming up on references that were fine a couple of weeks ago. It's showing in the template documentation as well. MeegsC (talk) 12:50, 6 December 2020 (UTC)

Never mind; I figured out what I needed to add. But the documentation may need some tweaking to help those of us who are suddenly faced with a rash of red error messages! ;) MeegsC (talk) 13:06, 6 December 2020 (UTC)

I suck at documentation so if you know how to make the documentation better, please do.

—Trappist the monk (talk) 13:34, 6 December 2020 (UTC)

Actually, when I really read the documentation instead of just skimming it, it's absolutely fine. I was just too lazy on my first pass! XD The "Term needed" message at the top of the template page before was a little more intuitive, but I think most of us will get there. MeegsC (talk) 13:55, 6 December 2020 (UTC)

Wanted to pop by and say thank you

Hi - I wanted to pop round and say thank you for your work with Monkbot. It's a breath of fresh air to see a bot dealing with issues surrounding citation markup - I've being going around and cleaning bits and pieces up, but obviously, your bot will be a bit quicker than me(!).

I don't know if this is in your remit, but seeing as it's in the same area as cleanup, I thought I'd drop it in. I know there might already be a bot working on this issue, but if there is, I haven't seen it - double spaces. They're easy enough to remove by users, true, and I have no knowledge of operating bots on Wikipedia, but, to a layman, it seems like the sort of thing Monkbot could check for, and remove, at the same time it cleans up citation parameters.

Another thing, wildly more complex, would be machine learning to tentatively tag articles as potentially requiring language tags - even flagging up potential words that would need tagging - but that's a pipe dream for another time, I think...

Anyway. Thank you for your diligent work in cleanup of our Wikipedia! Your work is so much appreciated :) --Ineffablebookkeeper (talk) 01:23, 7 December 2020 (UTC)

@Ineffablebookkeeper: See this recently archived discussion about double-spaces bot. In a nutshell, it's a bad idea. Headbomb {t · c · p · b} 01:50, 7 December 2020 (UTC)

Thank you. Spaces are, apparently, something that some editors will fight to the death to preserve so Monkbot task 18 seeks to maintain the spacing in cs1|2 templates as is.

—Trappist the monk (talk) 11:41, 7 December 2020 (UTC)

Task 18 and accessdate problem

It seems like Task 18 of Monkbot is failing to fix instances of |accessdate=, such as here. I have no idea what is going on. -BRAINULATOR9 (TALK) 01:43, 9 December 2020 (UTC)

|accessdate= fixes were disabled on 28 November as a result of Help talk:Citation Style 1 § deprecation and removal of nonhyphenated multiword parameter names. The fixes were reenabled on 8 December. Because Stranger in Moscow has |accessdate=, the bot will eventually revisit it.

—Trappist the monk (talk) 11:51, 9 December 2020 (UTC)

Alumni Ewha Woman's University

Lee Soodam from Kpop girlgroup SECRET NUMBER (traditional dance) .. Thank you WhouyuC (talk) 04:41, 10 December 2020 (UTC)

Thank you!

	The Working Wikipedian's Barnstar
	Thank you for you work! It is very much appreciated.LorriBrown (talk) 16:09, 13 December 2020 (UTC)

barak valley

Plz edit the trends section of barak valley, i.e lakhipur circle Hindu and Muslim population is wrong. — Preceding unsigned comment added by 2409:4065:E8C:C5D7:6A4B:465D:15C1:E917 (talk) 16:20, 11 December 2020 (UTC)

No. If you cannot edit the page yourself, make an edit request at Talk:Barak Valley.

—Trappist the monk (talk) 16:31, 11 December 2020 (UTC)

Barak valley

Sign - Saurav Mazumder Id - 2409:4065:E:250E:68D4:C791:AF35:BEFE. Trappist the monk plz correct the demography of lakhipur tehsil of cachar district in the trend section of Barak Valley. The existing number of Hindus and Muslims mentioning there is of lakhipur tehsil of Goalpara district and not of cachar as there are two lakhipur tehsils in Assam. Earlier I have requested in the Talk:Barak valley page but you didn't have responded it yet. Here's the link https://www.s/www.censusindia.co.in/amp/subdistrict/lakhipur-circle-cachar-assam-2100 — Preceding unsigned comment added by 2409:4065:E1E:D337:20AB:9998:549E:197 (talk) 13:44, 15 December 2020 (UTC)

No. I have never edited that page; my bot made a minor technical edit, but I have not and will not.

—Trappist the monk (talk) 13:55, 15 December 2020 (UTC)

stack bundles

Where’s stack bundles death in 2007 — Preceding unsigned comment added by 71.167.158.17 (talk) 13:47, 17 December 2020 (UTC)

Without an article, Stack Bundles won't be added to any list. First you, or someone else must create an article.

—Trappist the monk (talk) 13:56, 17 December 2020 (UTC)

Cambridge History templates fixes

You corrected my changes to {{New Cambridge History of Islam}}, thanks. I based my effort on Tom.Reding's fix to {{Cambridge Ancient History}}. Is that change itself OK? David Brooks (talk) 20:20, 17 December 2020 (UTC)

I looked at {{Cambridge Ancient History}} but decided not to 'fix' it. The correct way to 'fix' these templates and many others like them is to use Module:template wrapper so that we don't have to worry about 'fixes' like those that I did to {{New Cambridge History of Islam}}. By doing the correct 'fix', it isn't necessary provide explicit support for all of the (too many) aliases of various parameters because Module:template wrapper passes everything it gets to Module:Citation/CS1 through the selected cs1|2 template (unless instructed to ignore certain parameters).

—Trappist the monk (talk) 20:57, 17 December 2020 (UTC)

missing short description tag

Is there a way to find all the articles which need a short description so that it can be added? Thanks! Vikram Vincent 19:44, 18 December 2020 (UTC)

I know practically nothing about Short_descriptions except that they can somehow be drawn from Wikidata or provided by the {{short description}} template. I suppose that one way might be to search for articles without {{short description}}: 3.4+ million hits

—Trappist the monk (talk) 19:59, 18 December 2020 (UTC)

(talk page stalker) Vincentvikram: The most useful method is to install the "shortdescs-in-category" code described that is linked from here, then go to a category that interests you and use the "Show SDs" button to display local, Wikidata, and missing short descriptions. Make sure to read the rest of that page for guidance so that you add short descriptions that follow the normal practice here at the English Wikipedia. – Jonesey95 (talk) 22:04, 18 December 2020 (UTC)

Thank you Trappist the monk and Jonesey95 Vikram Vincent 05:20, 19 December 2020 (UTC)

Can I jump the queue?

I've been working on an article to get it up to GA standard. Before I put it up for peer review, I'd like to clear out any silly errors. So is there a way for an editor to request a monkbot run, as with citationbot? --John Maynard Friedman (talk) 16:52, 11 December 2020 (UTC)

Nothing formal. Tell me the article name and I'll add it at the top of the queue.

—Trappist the monk (talk) 16:58, 11 December 2020 (UTC)

Whoops, I thought I had left a watch on this page, so sorry for late reply. Article is Calendar (New Style) Act 1750. Thank you. --John Maynard Friedman (talk) 11:39, 19 December 2020 (UTC)

And just to add to the fun, I see that it has just happened anyway! Thank you for being a mind reader on top of everything else :-D --John Maynard Friedman (talk) 11:45, 19 December 2020 (UTC)

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)

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

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)

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

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)

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)

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)

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

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

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

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

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)

@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)

Been fixed by another editor.

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

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)

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)

@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)

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)

@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)

@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)

@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)

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)

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) Spread the love by adding {{subst:Seasonal Greetings}} to other user talk pages.

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)

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)

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)

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)

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

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

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)

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 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)

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)

Hyphens

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

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 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)

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)

|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)

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)

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)

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.

• 1884 Calgary municipal election
• 1889 Calgary municipal election
• 1898 Calgary municipal election
• 1919 Calgary municipal election
• 1918 Calgary municipal election
• 1897 Calgary municipal election
• 1890 Calgary municipal election
• 1891 Calgary municipal election

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)

Here are some more:

• Cyclone Akash
• Leap year starting on Friday
• Leap year starting on Monday
• Leap year starting on Saturday
• Leap year starting on Sunday
• Leap year starting on Thursday
• Leap year starting on Tuesday
• Leap year starting on Wednesday

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)

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)

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)