Jump to content

Template talk:SPI report

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

h4 h5 h6

[edit]

Hi. I'm wondering why the case pages use h4 h5 h6 headers, as part of the default structure given in this and related templates? (Wikipedia:Sockpuppet investigations/SPI/Blank report template header and Template:SPI archive notice). I can't see any transclusions into a larger page (my first guess for a rationale), even at large archived examples or ongoing cases.

It's not a major problem, but it is slightly odd that we're using ======<span style="font-size:150%">Comments by other users</span>====== everywhere. (I only ask, because I'm investigating where h5 and h6 headers are used at Enwiki, and these case pages are prolific in the search results!) Thanks. Quiddity (WMF) (talk) 22:16, 16 June 2015 (UTC)[reply]

My guess would be that they were originally transcluded somewhere and that it just hasn't been changed. @Timotheus Canens: do you know? Callanecc (talk • contribs • logs) 09:47, 17 June 2015 (UTC)[reply]
They used to be transcluded onto the main WP:SPI page itself. T. Canens (talk) 09:58, 17 June 2015 (UTC)[reply]
Thanks, both. :) I'll recommend, but leave up to you, as to whether to tweak (simplify simplify!). Quiddity (WMF) (talk) 00:13, 19 June 2015 (UTC)[reply]
See WT:SPI#Header levels on SPI report template. Callanecc (talk • contribs • logs) 02:00, 19 June 2015 (UTC)[reply]

Limit of 20

[edit]

It looks to me like when this template was created in 2010 it created a maximum of 20 named socks and 20 IP socks. Is there a reason why we should retain that cap? I believe that if you want to add more than 20, you can create the report with 20 and then add more to the list, but some editors don't realize that (see here). I didn't even know the limit was 20, although I realize it's not typical to have that many listed socks. Another option is to keep the limit but make it clear in the instructions that more can be added after report creation.--Bbb23 (talk) 00:08, 20 September 2015 (UTC)[reply]

I think we should double it, at least - and make it clear in the instructions that more can be added after report creation. NB: When they're added later, sometimes the tools don't work right.--Elvey(t•c) 18:33, 14 January 2016 (UTC)[reply]

Identify Limitations?

[edit]

{{editrequest}} not yet Should we edit the template to include a note of the limitation:

or should we put that in the SPI documentation? --Elvey(t•c) 16:13, 14 January 2016 (UTC)[reply]

[edit]

Template guru needed.

The top of this page says,

"You are about to add a second or subsequent request to the previous existing cases on: Sockpuppet investigations/Jytdog
Page for this report: Wikipedia:Sockpuppet investigations/Jytdog.
Please return to the main Sockpuppet investigations page (link above) and ..."

There is in fact no "link above". Can an admin fix that? It should link to (in this case) Wikipedia:Sockpuppet_investigations/Jytdog. I'm not sure which page to edit but they're protected (this best guess is anyway.) --Elvey(t•c) 18:48, 14 January 2016 (UTC)[reply]

Looks like s/Page for this report: ''{{FULLPAGENAME}}''/Page for this report: [[WP:{{PAGENAME}}]]/ here should do the trick. Can someone help troubleshoot? My edit didn't seem to help, but hasn't made things worse either. --Elvey(t•c) 19:31, 14 January 2016 (UTC)[reply]
To me it seems the error is the "(link above)". The user is meant to return to "the main Sockpuppet investigations page" to enter the correct name if they do not wish to create a second report on the user they're writing about (ie if they got the name wrong), and that page indeed is linked, just not above. Huon (talk) 21:34, 14 January 2016 (UTC)[reply]
I see that as only the case if the user entered the wrong name. If they got it right, then going back isn't appropriate; linking to the extant case is. --Elvey(t•c) 22:47, 1 February 2016 (UTC)[reply]
There is actually a link to Wikipedia:Sockpuppet investigations/Jytdog in the editintro, but it is a self-link and therefore renders bold and unlinked. I think you need external link markup for the link to work. SiBr4 (talk) 21:51, 14 January 2016 (UTC)[reply]
I cannot find such a link, even when clicking to find it, and/or watching my browser's status bar as I move my mouse. Also, of course I can't hardcode "Jytdog" in the page, since it needs to work in general for whatever was entered as the user name, not just for that user; surely {{PAGENAME}} needs to be part of the fix.--Elvey(t•c) 22:47, 1 February 2016 (UTC)[reply]
I meant that the editintro includes link markup ([[WP:{{PAGENAME}}]]) after "Page for this report:", which is what the "link above" refers to. In pages using it, however, it renders as bold text instead of a link, as it links to the page you're already on (putting [[Template talk:SPI report]] here does the same thing: Template talk:SPI report). Using an external link works around this (my link above was an example; the actual template would use something like [{{fullurl:{{FULLPAGENAME}}}} {{FULLPAGENAME}}]). SiBr4 (talk) 23:12, 1 February 2016 (UTC)[reply]
Ah, see what you mean - yes - It's there and yet not there. DoRD fixed the problem, using fullurl, in part, as noted below.--Elvey(t•c) 01:18, 2 February 2016 (UTC)[reply]
Plainlink the external link to make it look like an internal link. Mastah of hacks. --QEDK (T 📖 C) 10:23, 15 January 2016 (UTC)[reply]
QEDK: I tried this and couldn't get it to work due to the space in "Sockpuppet investigations"; I got links to [[1]]. Tried [https://en.wikipedia.org/w/index.php?title=Template:SPI_inputbox_instructions&diff=prev&oldid=702838097 this too; I guess the issue is that there are multiple levels of inclusion: Template:SPI_inputbox_instructions is included by Wikipedia:Sockpuppet investigations/SPI/Inputbox instructions for ordinary use... --Elvey(t•c) 22:47, 1 February 2016 (UTC)[reply]
@Elvey: I think that this is what you're asking for. ​—DoRD (talk)​ 23:48, 1 February 2016 (UTC)[reply]
Yes, that did it!--Elvey(t•c) 01:18, 2 February 2016 (UTC)[reply]

Accessibility

[edit]

At Wikipedia talk:Sockpuppet investigations #Accessibility, I've asked why this template uses an empty description list instead of a level 4 header for the heading "Suspected sockpuppets", breaking both WP:BADHEAD and html validation. Other comments there would be welcome. --RexxS (talk) 13:51, 3 June 2016 (UTC)[reply]

[edit]

Over at the /sandbox, I've added changes that support adding sock1 through sock6 and ip1 through ip6 to the editor interaction utility. If there are no objections, I'll implement it. ∰Bellezzasolo✡ Discuss 14:05, 18 January 2019 (UTC)[reply]

Template-protected edit request on 22 May 2019

[edit]

Couple of fixes required before it can work. Firstly, WMF Interaction Timeline only supports a maximum of two editors. So, fixed that. The current betacommand tool URL is a redirect, so fixed that as well. Pinging @Winged Blades of Godric: who made the changes. See here for changes. The change also introduced a line break and evidence two lines below the bullet, it's best to remove formatting customizations imo. qedk (t 桜 c) 13:31, 22 May 2019 (UTC)[reply]

 Done Facepalm Not sure 'bout why I thought to introduce multiple users to the Interaction tool. Did not check Betacommand's tool (I have never used it, yet) and that linebreak was a stray insertion:-( ∯WBGconverse 15:28, 22 May 2019 (UTC)[reply]

Lua

[edit]

It might be a good idea to create a lua module for this template. I'm not familiar with lua, but this will be useful. The current code is packed with sock# parameters, a lua module can fix this issue. Ahmadtalk 14:29, 16 January 2020 (UTC)[reply]

Template-protected edit request on 16 June 2020

[edit]

Please copy the changes I have made in the sandbox to the main template. The changes use the titleparts parser function to remove the html encoding from {{SUBPAGENAME}}, allowing the tools to work for names containing special characters. See sandbox vs live version. Danski454 (talk) 18:55, 16 June 2020 (UTC)[reply]

 Done Mdaniels5757 (talk) 21:48, 17 June 2020 (UTC)[reply]
[edit]

I have created a template to generate links to the Editor Interaction Analyser ({{EIA}}). I think it would be useful to use it here. I adapted the template in the sandbox (diff). The main differences:

  • It uses an interwiki link, instead of an external link.
  • It handles up to 40 positional parameters and ignores blanks. This way, instead of generating a link for the first 10 users and 10 IPs, we generate a link for all users and all IPs. Although if number of users plus number of IPs is larger than 20 it will still generate an invalid link.

Maybe the template needs some tweaking regarding substitution. So a review by a more experienced editor would be good. MarioGom (talk) 17:24, 17 April 2021 (UTC)[reply]

Changed back to an external link. An interwiki link can hit a limit size. MarioGom (talk) 07:02, 19 April 2021 (UTC)[reply]
Notified: Wikipedia talk:Sockpuppet investigations/SPI/Clerks. * Pppery * it has begun... 20:26, 7 May 2021 (UTC)[reply]
 Not done I feel strongly disinclined to implement this edit request because
  1. I had to fix two coding errors in the sandboxes (Special:Diff/1023743409, Special:Diff/1023742793)
  2. I'm still not convinced, even after doing that and some manual testing (since this template lacks testcases), that this is actually working in the same way as the old system and won't break anything.
  3. Most fundamentally, I'm seeing no clear need for any change. No one else has responded to this request in the month it has been active, and the proposer is not actively involved in administering SPI reports (and thus using the "tools" links whose coding is asked to be changed).
Overall, I see no clear benefit to doing this, and a non-trivial potential for harm, given that three mistakes have already been made (1: An interwiki link can hit a limit size, 2/3: the two edits I made to the sandboxes), and thus am declining to implement. * Pppery * it has begun... 03:11, 18 May 2021 (UTC)[reply]
While I'm not involved in administering SPI reports, I spend a good mount of time working with them. The annoyance of current EIA link limits is something that came up before when talking with some SPI clerks. Obviously it doesn't seem it's annoying enough for anyone to be interested in fixing it ;-) Anyway, if this is considered useful, I can introduce test cases, work through remaining technical issues, etc. MarioGom (talk) 15:28, 21 June 2021 (UTC)[reply]

Template-protected edit request on 23 January 2022

[edit]

There is a strange blank line before "tools". Patch provided in sandbox. Xiplus (talk) 07:22, 23 January 2022 (UTC)[reply]

 Done. P.I. Ellsworth - ed. put'r there 10:07, 23 January 2022 (UTC)[reply]
@Xiplus: Just wanted to say thanks for this. I went to clean up three whitespace errors we've been having at SPI, and got confused why I couldn't replicate this one... Then thought to check the template history and saw someone had fixed it a few days before! :D -- Tamzin[cetacean needed] (she/they) 19:21, 27 January 2022 (UTC)[reply]

Proposed change to sock list

[edit]
Twinkle
Tracked in github.com
Issue #1509
spihelper
Tracked in github.com
Issue #99
Tracked in github.com
Issue #111
spi-tools
Tracked in github.com
Issue #206

There's a number of problems with the current sock-list system. One is that, no matter how simple it may seem to add a new {{checkuser}} or {{checkip}}, people do manage to mess it up or put them in the wrong place. Another, more significant one is that the editor interaction links are only generated in the initial filing (and not at all, if using {{{socksraw}}}, as Twinkle does, making the link useless in the majority of our reports).

I propose a simplification that will fix these problems, fit in easily with the existing preloads, and be easily extendable to Twinkle:

  • Implement this change to {{SPI report}}. My new {{sock list}} takes an arbitrary number of parameters, without needing to specify whether they are accounts or IPs, and dynamically generates interaction links from them. I've created a module, Module:Forward parameters to template call, which will take any numbered parameters, sockn parameters, and ipn parameters, and turn them into numbered parameters in the {{sock list}} call. This allows full backward compatibility with any system using sock1, ip2, etc.
  • Change the {{{sock1}}}/etc. fields in Wikipedia:Sockpuppet investigations/SPI/Inputbox blank report for ordinary use and Wikipedia:Sockpuppet investigations/SPI/Inputbox blank report for ordinary use for IPs to 
    <!--If you want to request checkuser, simply change the line above this comment to checkuser=yes -->
<!--        sock 1 here      -->|1=
<!--        sock 2 here      -->|2=
<!-- add as many as you need -->|3=
    As noted, though, {{{sock1}}} and such will still work for backward compatibility.
  • Change L813-816 of twinklearv.js to 
        var text = '\n{{subst:SPI report|' +
        params.sockpuppets.map(function(sock, index) {
            return (index + 1) + '=' + sock;
        }).join('|') + '\n|evidence=' + params.evidence + ' \n';
    I'm not great at JS but I think that's right. (N.B.: Also incorporates whitespace change already at PR 1505.)
  • The {{{socksraw}}} parameter will be retained for anyone needing to override this. {{sock list}} will still be called, empty, after it, to provide the "Tools" link and allow for easy addition of other sox to the SPI subsequently. Although I'm not sure if anyone's been manually using {{{socksraw}}}, or if it's just Twinkle. Still, this would bridge any transition period between changing the template and changing Twinkle.

Thoughts? -- Tamzin[cetacean needed] (she/they) 04:44, 5 February 2022 (UTC)[reply]

A very useful feature IMO. In fact I think this could be used outside of just the suspected sockpuppets section, and possibly be useful elsewhere (such as in CU results) as this would save the number of duplicated calls to {{checkuser}} in the wikitext of the page. To allow this it would be worth to add parameters to disable the appended tools section + customise the bullet point level for the uses of {{checkuser}} and {{checkip}}, so that it can be used simply as a list for more experienced users.
The concerns I have is that unless this template is to be substituted, it is likely to break a number of already existing tools. I am sure that both spihelper and SPI tools would both need to be updated to support this as they read wikitext and not parsed content. The need for tools to be updated should not in itself be a reason to oppose, but this will be need to factored in before widespread implementation. As such, a non-dev version of spihelper and SPI tools that includes support for this template would be needed before it could be moved to widespread use to ensure the workflows of clerks, admins and CUs are not broken. Dreamy Jazz talk to me | my contributions 16:26, 5 February 2022 (UTC)[reply]
Because this template exists, I will see if I can't write some patches for spihelper and SPI tools to speed up that process raised in my concern. Dreamy Jazz talk to me | my contributions 16:35, 5 February 2022 (UTC)[reply]
@Dreamy Jazz: I can add a {{{tools_links}}} param to {{sock list}} and have it set to yes when being called from {{SPI report}}. As to indentation level, that should already work fine. HTML-wise the whole thing is one <ul>...</ul>, same as a series of asterisk-bullets. As to scripts, I've already checked that this change is not an issue for cuStaleness, of which I'm co-maintainer. See Special:PermaLink/1069742747 (in which I mercilessly vandalize Writ Keeper's sandbox). For SPIhelper, I'm not super familiar with its codebase, but it's possible the only change needed would be to L746: 
    const checkuserRegex = /{{\s*(?:check(?:user|ip)\s*\|\s*(?:1=)?\s*([^\|}]*?)\s*(?:\|master name\s*=\s*.*)?|sock\s?list\|\s*(?:(?:\d=)?([^\|}]+\|?))}}/gi
Not tested, and I'm bad at JS, so this is just proof of concept. With spi-tools, at spi_utils.py#L213 I think the following should work 
    def find_ips(self):date()
        one_value_templates = self.wikicode.filter_templates(
            matches=lambda n: n.name.matches(['checkip', 'checkIP']))
        multi_value_templates = self.wikicode.filter_templates(
            matches=lambda n: n.name.matches(['sock list', 'socklist']))
        for template in one_value_templates:
            ip_str = template.get('1').value
            try:
                yield SpiIpInfo(str(ip_str), str(date), self.page_title)
            except InvalidIpV4Error:
                pass
        for template in multi_value_templates:
            for param in template.params:
                if "=" not in param:  # Probably a better way to rule out named params
                    try:
                        yield SpiIpInfo(str(param), str(date), self.page_title)
                    except InvalidIpV4Error:
                        pass
Also not tested, but somewhat more confident in that code.
Pinging GeneralNotability and RoySmith to tell me all the things I've gotten wrong. -- Tamzin[cetacean needed] (she/they) 17:12, 5 February 2022 (UTC)[reply]
Your regex for spihelper doesn't work. First, the template {{sock list}} would need to be split up, and your code just seems to extract the sock list (plus when testing it it didn't work either). This will require at least two regexes, as regex does not support using the same capture group for multiple matches (as it stores one variable per match group). Dreamy Jazz talk to me | my contributions 17:25, 5 February 2022 (UTC)[reply]
I've made the necessary changes to {{sock list}}, Module:Sock list, Module:Forward parameters to template call, and Template:SPI report/sandbox. Now, {{sock list}} will by default not include the tools links, but {{SPI report}} will specify |tools_link=yes for the main sock list.
As to the regex, huh, I didn't know capturing groups worked that way. Learn something new every day. Do you want to handle the JS side here and I can handle the Python? (I desperately miss Python after writing all this Lua.) -- Tamzin[cetacean needed] (she/they) 18:11, 5 February 2022 (UTC)[reply]
Sure. I'm writing a patch right now, so no problem. Dreamy Jazz talk to me | my contributions 18:16, 5 February 2022 (UTC)[reply]
Patch created at https://github.com/GeneralNotability/spihelper/pull/99 Dreamy Jazz talk to me | my contributions 18:39, 5 February 2022 (UTC)[reply]
The pull request has been merged into the -dev version of SPI helper which is used by a good number of CUs and admins, so from the point of view of SPI helper this change should be okay to go ahead with. Dreamy Jazz talk to me | my contributions 21:02, 6 February 2022 (UTC)[reply]
I'm happy to have patches for spi-tools, but just a heads up, I'm going to be merciless about unit tests. -- RoySmith (talk) 18:21, 5 February 2022 (UTC)[reply]
I'm still absorbing all of this, but I'll toss out a few random thoughts:
1) I agree that the need to update the tools should not be a blocker to format changes.
2) For spi-tools, I've been using (more or less) Test driven development, so I've already got a decent set of test cases that can serve as regression tests.
3) There's already an instance of spi-tools running at https://spi-tools-dev.toolforge.org which we can use for integration testing. Spinning up additional instances shouldn't be terribly difficult if somebody wants their own sandbox.
4) I agree that combining {{checkuser}} and {{checkip}} into a single template is a good idea. People often use the wrong one anyway, and it's easy enough to pattern match to figure out which is which. We should support CIDR notation as well.
5) It might make sense to add an explicit schema declaration embedded in the wikitext. Then things that parse these pages don't have to intuit which flavor they're parsing, they can just look at the schema declaration and know for sure what they're looking at. -- RoySmith (talk) 18:09, 5 February 2022 (UTC)[reply]
@RoySmith: Re #4, Module:Sock list calls Module:IPAddress's ._isIpOrRange function, which I think does something a fair bit fancier than just string matching, although I haven't looked all the way under the hood. -- Tamzin[cetacean needed] (she/they) 18:14, 5 February 2022 (UTC)[reply]
Howdy. I'm one of the Twinkle maintainers. I tested Tamzin's Twinkle PR on testwiki, looks good, I will probably merge it soon. Any objections, or any timing issues? Once merged to master it could be deployed onwiki at any time, although realistically it would probably be a month or two, we don't deploy that often. Thanks. –Novem Linguae (talk) 05:17, 11 February 2022 (UTC)[reply]
spihelper-dev has the patch that allows this to work. That might take a bit of time to merge to the non-development version of SPI helper. I'm not sure that any progress has been made with updating SPI tools.
With that in consideration, I don't think that there needs to be any specific considerations on the time to push to the master branch, so I'd say go ahead whenever. Dreamy Jazz talk to me | my contributions 10:32, 11 February 2022 (UTC)[reply]
Was there anything for which people were waiting on me here? I was kind of expecting a pull request to show up for spi-tools, but never saw one. Just want to make sure I'm not a blocker on anything. -- RoySmith (talk) 20:42, 12 February 2022 (UTC)[reply]
My understanding is that Tamzin was working on this? Seeing as the deployment to enwiki is expected to take some time I don't see any particular rush on this. Dreamy Jazz talk to me | my contributions 22:36, 12 February 2022 (UTC)[reply]
Sorry, yes, things have kept coming up. Expect a PR Monday or Wednesday, hopefully. -- Tamzin[cetacean needed] (she/they) 20:17, 13 February 2022 (UTC)[reply]
Once the patch to SPI Tools is in and the patch I've added to spihelper-dev is pushed to the non-development version it should be fine to update this template. Dreamy Jazz talk to me | my contributions 01:27, 14 February 2022 (UTC)[reply]
Merged to master in Twinkle today (not deployed yet). Thanks all. –Novem Linguae (talk) 17:11, 17 February 2022 (UTC)[reply]

Can we eliminate the two names?

[edit]

I see we've got {{Socklist}} which redirects to {{Sock list}}. Can we pick one or the other and just go with that? Having two different names means people will randomly pick one or the other to use, and every tool that processes these pages will have to add code to handle both versions. -- RoySmith (talk) 15:44, 19 February 2022 (UTC)[reply]

If we choose one (and delete the other) there will always be the possibility that a redirect is re-created / other shortcuts on top of that could be created. When making my bots I wrote a function that got the template redirects for each template I wanted to search for, and stored this in a cache (which was re-generated every time the bot started). Because template shortcuts / alternative names are entirely possible, perhaps a function that gets the possible template redirects to a given template would be useful for both spihelper and spitools so that they are future proofed. spitools could, if I'm not wrong, have a server side cache to make the impact server response times low. Currently spihelper-dev and spihelper support both {{socklist}} and {{sock list}}. Although future proofing to ensure that furture redirects are handled is IMO a good idea, I'm neutral on whether to choose one. Dreamy Jazz talk to me | my contributions 02:49, 20 February 2022 (UTC)[reply]
Good point. https://github.com/roysmith/spi-tools/issues/208 -- RoySmith (talk) 03:38, 20 February 2022 (UTC)[reply]
Actually, I've been thinking about this some more and I'm back at my original idea. There's no benefit to having multiple ways to spell the same template name. The fact that somebody could come along at some point in the future and add a redirect is a non-sequitur because they shouldn't be allowed to do that. It just adds complexity with no value. -- RoySmith (talk) 03:02, 21 February 2022 (UTC)[reply]
I would note that when I was running my WikiProject tagging bots I had to have this code because there were so many template shortcuts for the WikiProject banners. SPI probably avoids this as it has a smaller active base of users who would interact with templates like {{sock list}}, with the other editors using twinkle to report users.
Future-proofing against multiple different names for the {{socklist}} template probably isn't necessary for the time being if you desire more compact code, but with regards to these two I can see active editors at SPI trying to use both variations regardless if one exists because whether to include a space is often different between templates. If we needed to choose one, then {{socklist}} would probably be better for consistency with other templates as {{checkuser}} and {{checkip}} do not have spaces. Dreamy Jazz talk to me | my contributions 03:16, 21 February 2022 (UTC)[reply]
I agree that {{socklist}} without the space is preferable. -- RoySmith (talk) 03:28, 21 February 2022 (UTC)[reply]
If the template is detected via regex, maybe just hard code space question mark and call it good. /\{\{Sock ?list/i –Novem Linguae (talk) 04:12, 21 February 2022 (UTC)[reply]
Most projectspace templates that are multiple words spaced out will have an unspaced alias, and vice versa. I thought it better to establish those two names from the get-go, rather than risk everyone setting up under the assumption that it's only one of the two, and another being created. If anyone tries to create further redirects beyond that one most obvious one, I'll be the first to RfD them. As to which of the two names should be the actual template name and which should be the redirect, that strikes me as bikeshedding. -- Tamzin[cetacean needed] (she/they) 04:17, 22 February 2022 (UTC)[reply]

v6?

[edit]

Is this supposed to handle IPv6 addresses? Is it supposed to handle IP ranges? — Preceding unsigned comment added by RoySmith (talk • contribs)

Yes. Module:IPAddress which this template uses relies on Module:IP which does handle IPv6 addresses. Furthermore _isIpOrRange which is used specifically handles both versions of IP addresses and ranges. Dreamy Jazz talk to me | my contributions 11:47, 21 February 2022 (UTC)[reply]
OK, I've udated Template:Sock list/doc to include a more representative set of examples. -- RoySmith (talk) 17:17, 21 February 2022 (UTC)[reply]

Changes live

[edit]

Okay, I have made the necessary changes to the template and the two preloads. I've tested things out and everything seems to be going fine, but of course if any issues arise feel free to revert. There's still a few tweaks I plan to make to the module (like a {{{remove_duplicates}}} option maybe), but those will all be non-breaking. Btw, see Template:Sock list/doc for some of the cool things I've thrown in.

SPIhelper now needs to be updated on its "write" side. Was sort of chicken-and-egg, one had to happen first. I'll try to get a PR in for that ASAP.

Thank you all for your help on this change. Hopefully it will improve clerk/admin/CU workflows down the line. -- Tamzin[cetacean needed] (she/they) 04:17, 22 February 2022 (UTC)[reply]

That probably needs a fix, but it won't break moving cases where {{socklist}} is being used (i.e. the new master is still added as a seperate use of {{checkuser}}). Let me know if you don't plan to make a PR for this, and I can see what I can do. Dreamy Jazz talk to me | my contributions 22:52, 24 February 2022 (UTC)[reply]
@Dreamy Jazz: I wrote something yesterday that I think will work, but didn't have the chance to test it then or today. Will try tomorrow. If I can't get it to work, maybe I can show you what I've done, and you can see if something workable can be made of it? -- Tamzin[cetacean needed] (she/they) 06:28, 25 February 2022 (UTC)[reply]
Sure. Dreamy Jazz talk to me | my contributions 10:03, 25 February 2022 (UTC)[reply]
I'll admit, I wasn't 100% convinced this was worth the effort, but now that it's a thing, I'm finding this really handy. Thanks for inventing it. -- RoySmith (talk) 00:14, 28 February 2022 (UTC)[reply]

FYI, Twinkle is getting deployed soon. I just put in the intadmin request. –Novem Linguae (talk) 13:42, 9 March 2022 (UTC)[reply]

Thanks for the heads up. From where I sit, everything looks good. -- RoySmith (talk) 14:38, 9 March 2022 (UTC)[reply]
Thanks. Should be good to go from my point of view. Dreamy Jazz talk to me | my contributions 22:43, 9 March 2022 (UTC)[reply]

Problem with parsing

[edit]

@Caeciliusinhorto, Tamzin, Dreamy Jazz, and Novem Linguae: In Special:Diff/1073633783, (and the two edits immediately after that), the parameters to {{socklist}} have explicit numbers (i.e. 1=, 2=, etc). I wasn't expecting that, so it's not being parsed correctly. I'm assuming those template calls were created manually? Or is Twinkle doing that? I had considered whether I needed to support both syntaxes and decided I didn't need to. I guess I was wrong. See https://github.com/roysmith/spi-tools/issues/212. -- RoySmith (talk) 15:35, 24 February 2022 (UTC)[reply]

PS, whoever's looking after the spihelper stuff should test that both flavors work in that code. -- RoySmith (talk) 15:36, 24 February 2022 (UTC)[reply]
The regex used in the fix explicitly handles both variations of unnamed arguments (i.e. with or without digits and the equal sign). Dreamy Jazz talk to me | my contributions 22:44, 24 February 2022 (UTC)[reply]
The Twinkle changes haven't been deployed yet and likely won't be for awhile. We tend to wait for a big batch of commits, then ping MusikAnimal to run the deploy script, as he's the only active intadmin that knows how to do it, and we don't want to bug him too much. I note this edit is not tagged with any tools in the edit summary, so perhaps this person did it manually. Could be a rarely occurring use case, but a case that may crop up from time to time and may need code. Up to you guys. –Novem Linguae (talk) 15:41, 24 February 2022 (UTC)[reply]
Yeah, that's pretty much what I figured, just checking to make sure. Unfortunately, mwparserfromhell makes it annoying to handle both ways. It's not a big deal, just annoying enough that I didn't bother on the first pass :-) -- RoySmith (talk) 15:49, 24 February 2022 (UTC)[reply]
Ah, I think I found the source. This page includes |1=, |2=, etc. by default. This page is reached via using the input box and submit button on the main SPI page. Modifying Wikipedia:Sockpuppet investigations/SPI/Inputbox blank report for ordinary use may be a solution. –Novem Linguae (talk) 15:47, 24 February 2022 (UTC)[reply]
Ah, cool, so that at least explains where it came from. In any case, I'm working on the code to handle both variations right now and expect I'll have that deployed within the hour. -- RoySmith (talk) 15:51, 24 February 2022 (UTC)[reply]
@Novem Linguae: Just to explain why I set it up that way, there's two reasons: One, it's surprisingly hard to write a clear, user-friendly comment saying "Just add new pipes for each sock's name". Two, if one sock has an equals sign in their username, then that parameter will need an explicit numbered param call, which a) is also hard to explain in a comment and b) can mean someone having to count back through 20 sox to find what number they're on. -- Tamzin[cetacean needed] (she/they) 19:27, 24 February 2022 (UTC)[reply]
Replied on GitHub. -- Tamzin[cetacean needed] (she/they) 15:49, 24 February 2022 (UTC)[reply]
@Caeciliusinhorto I'll expect you have no idea what we're talking about here. Don't worry, it's nothing you did wrong, you just happened to use some new code before it was fully debugged. -- RoySmith (talk) 16:26, 24 February 2022 (UTC)[reply]
@Novem Linguae @Tamzin I just found another (minor) issue with the 1= style. In Special:Diff/1076360932, the following was generated:
{{sock list|1=Jafaz|2=Tsans2|3=91.192.183.13|4=EricLewan|tools_link=yes}}
I want to delete the first one (Jafaz) because you don't need to duplicate the master's username in the list of socks. So, what am I supposed to do with the numbers? Manually renumber them all so they start at 1? Don't worry about it and just let them start at 2? It would be simpler if the numbers just weren't there in the first place. -- RoySmith (talk) 20:23, 10 March 2022 (UTC)[reply]
@RoySmith: Add the parameter |remove_master=yes and the template will take care of it for you. As I explained previously on this page, using the template without explicit numbered parameters will cause much greater issues anytime a username has an = in it; that's true of any template and is a fundamental limitation of MediaWiki template markup.
As to your question more generally—and everything here is just about how Lua and MediaWiki work, not how this particular template works—the template will work if there is no {{{1}}}} or if numbers are skipped, although this may display in an unexpected order. It is possible to put numbered parameters in a nonlinear order without issue, e.g. |2=foo. That will be treated identical to a linear order. -- Tamzin[cetacean needed] (she/they) 21:15, 10 March 2022 (UTC)[reply]
Thanks. I could rant about how stupid MediaWiki markup is in general, but I'll behave myself :-) -- RoySmith (talk) 22:18, 10 March 2022 (UTC)[reply]

Template-protected edit request on 2 March 2022

[edit]

Big tags are now deprecated. Please replace them with style attributes. NguoiDungKhongDinhDanh 10:38, 2 March 2022 (UTC)[reply]

 Done – replaced with template {{Big}}, which passes span style 120% font size. P.I. Ellsworth - ed. put'r there 11:28, 2 March 2022 (UTC)[reply]
@NguoiDungKhongDinhDanh @Paine Ellsworth this appears to have had an unexpected consequence. The {{big}} is now being included in the menu links, leading to URLs such as:
https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Rgalo10#{{big|Clerk,_CheckUser,_and/or_patrolling_admin_comments}}
which is pretty ugly. Was it really necessary to do this? -- RoySmith (talk) 00:05, 14 March 2022 (UTC)[reply]
@RoySmith: Not really. All I wanted to do was just replacing <big>...</big>, but Paine decided to use {{big}} instead of style="font-size: large;". NguoiDungKhongDinhDanh 00:09, 14 March 2022 (UTC)[reply]
Well, could you fix it? More to the point, might I suggest that before making changes like this, the people who actually use the templates be consulted? I note that WP:TPE says, They are also permitted to enact more complex or controversial edits after those edits are first made to a test sandbox, their technical reliability and their consensus among other informed editors having already been established which was not done here. -- RoySmith (talk) 00:13, 14 March 2022 (UTC)[reply]
To editor RoySmith: first, I had no idea that this would be controversial, so I ask your forgiveness. I would love to fix this, but first I have to understand it better. You say that the template appears in the URLs of the menu links. I checked on this menu, but did not notice this problem there. Even Rgalo10 at the bottom went straight to the page. And the link Wikipedia:Sockpuppet investigations/Rgalo10#Clerk, CheckUser, and/or patrolling admin comments goes straight to where it's supposed to, with a URL of https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Rgalo10#Clerk,_CheckUser,_and/or_patrolling_admin_comments. Would you mind pointing to one or more menu links where the problem you describe can be found? I've used such templates before in headers and they haven't been a problem, any more than the "big" html tags are a problem in headers. So if you can help me (understand), then maybe I'll be able to help you (and to fix this). P.I. Ellsworth - ed. put'r there 01:52, 14 March 2022 (UTC)[reply]
I first noticed it in my watchlist, where it says:
× Wikipedia:Sockpuppet investigations/JRM2018‎ 23:13:24 +383‎ ‎Paul 012 talk contribs block‎ (→‎{{big|Clerk, CheckUser, and/or patrolling admin comments}}: Reply) rollback
If I click on that, I get to:
https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/JRM2018#{{big|Clerk,_CheckUser,_and/or_patrolling_admin_comments}}
From there, if I click on the "1.1.3 Clerk, CheckUser, and/or patrolling admin comments" link in the contents box, I get to:
https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/JRM2018#Clerk,_CheckUser,_and/or_patrolling_admin_comments
I will confess to not being a wizard on templates, but it seems to me that at the very least, those two URLs should be identical. This seems like a minor cosmetic change that had no real urgency applying it, so I suggest this be backed out until we can better understand what's going on here.
It's not just that the URLs look funny. There are a number of scripts which parse these templates. For example, my code here does pattern matching on the "big" tags. That was the first thing I noticed (a couple of days ago) but I convinced myself that your change wasn't going to affect that, because that bit of code only runs on ancient pages. But still, this change really should have been discussed with the people who use these templates before making the change. There's other bits of code maintained by other people; I don't know exactly what they're looking for as they do their parsing, so I have no idea of this change affects them. So, this really should be backed out until everybody understands better what the implications are. -- RoySmith (talk) 02:50, 14 March 2022 (UTC)[reply]
To editors RoySmith and NguoiDungKhongDinhDanh: the change has been reverted back to the <big> tags. And after reading your comments above, I wonder what would happen if you changed line 114 in your code here from:
 map_5_to_3_pattern = re.compile(r"^=====<big>([a-zA-Z 0-9]*)</big>=====$", re.MULTILINE)
to:
1. map_5_to_3_pattern = re.compile(r"^====={{big|([a-zA-Z 0-9]*)}}=====$", re.MULTILINE)
or to:
2. map_5_to_3_pattern = re.compile(r"^=====<span style="font-size: 120%">([a-zA-Z 0-9]*)}}</span>=====$", re.MULTILINE)
Would the #1 code above accomodate the previous change to template {{Big}}? And would the #2 code be needed if the deprecated <big> tags are replaced with the span style tags?
Now here's what I think. I've seen varying things on HTML websites about deprecated elements. And I've watched as some elements were deprecated in HTML4 and then brought back (undeprecated?) in HTML5. It seems that when an element is widely used, for example the <s> strikethrough tags, which are also listed as deprecated on some sites, new versions of HTML still allow their usage. So I think we should go by Linter errors. If you use the <center> tags for example, the page will show a Linter error that needs to be fixed with CSS styling. If we look at the Template:SPI report page and click on the "Page information" link in the left column, then scroll all the way down, we come to an area where "Lint" (Linter) errors are shown. As we see, the SPI report page does not throw Linter errors, so while the <big> tags may be temporarily or permanently deprecated, they are not something that we should be too concerned about right now. When the time comes, the devs will either fix things or show us how to fix them. P.I. Ellsworth - ed. put'r there 06:56, 14 March 2022 (UTC)[reply]
Thanks for reverting. FWIW, I agree that the current formatting of SPI pages is bizarre; it is an artifact of how things were done when dinosaurs roamed the wiki (see the "h4 h5 h6" section at the top of this page). The idea that we've got random header levels and tags to make them look right is crazy. It doesn't seem to be hurting anything, however, so leaving good enough alone seems like the right move. -- RoySmith (talk) 13:42, 14 March 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:SPI_report&oldid=1125195430"