Template talk:Dablinks

Kill it with fire

Removed complaint about inability to opt out from this on needful pages. It was poor documentation: simply include the {{bot}} template at the top of the page, with the instruction "|deny=DPL bot". — LlywelynII 14:36, 12 April 2012 (UTC)[reply]

It should go without saying that this should not be standard for all pages, but merely those which by their nature will and should link to many disambiguation pages which this well-intentioned bot will simply wreck otherwise. — LlywelynII 14:37, 12 April 2012 (UTC)[reply]

Broken links

The links that go to dispenser.info.tm seem broken for me, they don't load anything. Can anyone check if it works? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:25, 18 June 2020 (UTC)[reply]

See VPT. I removed the dispenser link because apparently it goes to some other website now. Johnuniq (talk) 01:53, 18 June 2020 (UTC)[reply]

Still, or again broken? Clicking "check" or "fix" gets you a 404 for dispenser.info.tm. @Johnuniq, Piotrus, Dispenser, and Naypta: can someone help? (The VPT link is now in Archive 182.) Thanks, Mathglot (talk) 10:28, 13 July 2020 (UTC)[reply]

I am getting 404 at https://dispenser.toolforge.org/cgi-bin/dablinks.py?page=Template:Dablinks with a suggestion to go to https://dispenser.info.tm/~cgi-bin/dablinks.py?page=Template:Dablinks that ends in a timeout. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:31, 13 July 2020 (UTC)[reply]

The situation is again at VPT, see here. Attempts to use dispenser.info.tm are unwise because it appears that the domain has been taken over and is controlled by someone (not Dispenser) who might be sitting on it hoping to be paid for its return, or who may be injecting malware into the browsers of anyone visiting the site. The suggestion at VPT is that if desperate you could try using what is believed to be Dispenser's IP. For some reason unknown to me, you have to use https (not http) with the IP—see the examples at the VPT link. Problem: If you are using a decent browser, it will complain a lot about visiting the https IP link because either there will be no certificate, or the certificate will be for a name, not an IP. You can override the browser's objection if confident. Johnuniq (talk) 11:05, 13 July 2020 (UTC)[reply]

@Johnuniq:, thanks for the comment. I understand about certificates and how to evaluate my own risk, but I don't believe Wikipedia should display links that require everyone to make that same evaluation. Unless there's some objection, I'm going to disable these links for now. Adding @Piotrus and Naypta:.

Not sure if xtools has a utility that will just list all the dablinks on page, but I wish the DPL bot would do so, since it apparently already has the code to discover and identify them, as it counted "7 or more" dablinks at War of 1812 (diff). Does it at least have some configurable option that can be used to run it again, this time pointing straight at that article, and requesting a full dablink dump, so we can fix them? Ideally to the article talk page, but anywhere that's convenient. Mathglot (talk) 02:33, 14 July 2020 (UTC)[reply]

I concur that the links should be disabled until the script can be hosted on safe servers. Why hasn't this been done? I know this is off topic, but we should simply project-ban any tool that uses 'private' servers, this type of a problem comes up again and again. Host on safe servers that community will maintain or you don't get to share your tool with the community for reasons of security and convenience (as in, wasting our time here). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:38, 14 July 2020 (UTC)[reply]

Done. Links removed, pending further discussion/resolution of this. Mathglot (talk) 04:00, 14 July 2020 (UTC)[reply]

In my opinion, Dispenser's tools save time rather than wasting it. Like other tools, wherever hosted, they suggest changes for editors to consider, ready for us to review then publish, refine or cancel as we judge fit. The IP address for Dispenser's tools is 69.142.160.183; for example Dabfix is at http://69.142.160.183/~dispenser/view/Dabfix. http: and https: are both problematic. Some tools redirect http: requests to https:, presumably to meet security requirements, but in doing so divert them to the non-functional info.tm domain. https: gives a bad certificate warning, as it is certified for dispenser.info.tm rather than for the IP address. It would be helpful to bring these tools in-house to tools.wmflabs.org or similar. Certes (talk) 10:40, 14 July 2020 (UTC)[reply]

Please comment on the feature request at User talk:DPL bot#Feature request: dump dablink list into the template. Adding @Piotrus, Naypta, Johnuniq, and JaGa:. Thanks, Mathglot (talk) 06:56, 14 July 2020 (UTC)[reply]

Dispenser's source code is available at http://69.142.160.183/~dispenser/sources/. I don't see any technical reason why these programs could not be ported to Toolforge, if someone has the time and energy to do it. --R'n'B (call me Russ) 13:18, 14 July 2020 (UTC)[reply]
@R'n'B: As far as I am aware, there's no evidence that these programs were licensed under a free license, so they would need to be rewritten to avoid copyright infringement. Naypta ☺ | ✉ talk page | 15:51, 14 July 2020 (UTC)[reply]

New functionality in sandbox

Responding to the situation discussed above, I thought it would be useful to extend the functionality of the page to allow the user to add some dablinks to the display as optional parameters. This is now available in the sandbox as a backward-compatible upgrade, and examples can be viewed on the test cases page. Here's one example, to give you an idea. This is for War of 1812:

This example uses real dablinks, as reported for the article War of 1812 by PetScan.

These unnamed parameters (up to ten) can be added manually by a user. Or, assuming an upgrade to DPL bot, they could be autogenerated, which would be helpful, while we wait for the check/fix links to be fixed. There's one fishy thing going on with the date param, which I haven't looked at yet; see the test cases. Your feedback would be appreciated. Thanks, Mathglot (talk) 07:41, 15 July 2020 (UTC)[reply]

A discussion of circular links seems unnecessary to me. We are only looking for links to disambiguation pages; unless this template is appearing on a disambiguation page itself (possible, but rare), any link to a disambiguation page is not going to be circular. --R'n'B (call me Russ) 15:04, 15 July 2020 (UTC)[reply]

@R'n'B: Yes, that makes sense, thanks; I'll remove that part. I had second toughts about the "Please find..." verbiage; should it say, "Please find and fix..", or just a neutral statement like, "The following links in the article may need attention..." or what do you think? Mathglot (talk) 19:43, 16 July 2020 (UTC)[reply]

JJMC89 Thanks for the answers to the questions at my Talk page. I know that this edit was an attempt to fix something we talked about at my Talk page, but unfortunately it broke something: namely keeping the show/hide link top right. If you look at the example above now, the show/hide has dropped down into the middle of the template; it's kind of ugly that way and there's some overlap (in my browser, anyway). The earlier version, was the solution I found for keeping the show/hide link top right, and that required the {{hidden}} to be invoked before the 'issue' or any other text is evaluated. The only way I found to do that, required the boilerplate to be accessed twice, and while that's not very elegant, I give much more weight to a clean UX than the look of the wikicode, and let's face it, any template's code looks pretty ugly. The previous version did the best by the user, which is why I went with it. If you can find a way to keep that show/hide link at the top, and keep using issue/fix, all without invoking boilerplate twice, then that would be ideal, but I'd prefer to back up to the previous version if you can't. There may be a way, but I tried various things and just couldn't find it. If you look at the History of User:Mathglot/sandbox/Templates/Dablinks, you'll see I went through some of the same thoughts you just did, and somewhere around this rev, I came up with that solution. Hopefully you'll find a better way. Mathglot (talk) 07:52, 17 July 2020 (UTC)[reply]

In my opinion, it looks nicer with the show/hide link top right (examples in my sandbox), rather than where it is currently. The trade-off appears to be, simpler wikicode in exchange for a non-standard placement of the link. (Is there a standard? Or is it just long convention?) But I don't feel strongly about it, either, as long as we can get the list-links functionality in. If there's no objection to JJMC89's version, I'll move that one live after leaving some time for comment; say, a week? Mathglot (talk) 18:45, 21 July 2020 (UTC)[reply]

I still think it looks nicer with the link top right, but since I'm the newbie here, I just went with JJMC89's version, with the link at the bottom. Previous versions are in the sandbox history, should there be a future consensus for show/hide link at the top. Also, it appears to interact with the date, which gets pushed below the dab list, and an extra blank line above. Mathglot (talk) 02:17, 2 August 2020 (UTC)[reply]

mobile view

JJMC89, at my Talk page, you said,

I've tweaked the sandbox to keep using |issue= and |fix= (and not need the boilerplate text in two places). Using |text= instead without appropriate classes impactes the mobile view.

Can you elaborate on that? Is it enough to stick en.m. in front of the rest of the url for mobile testing from a laptop, or do I have to use the mobile device for testing (I'm able to, I just like the larger interface, where possible). Mathglot (talk) 08:11, 17 July 2020 (UTC)[reply]

Broken ping, I think; here's another. JJMC89. Mathglot (talk) 08:11, 17 July 2020 (UTC)[reply]

In mobile only what is in |issue= is shown on the article. This is the same thing that gets shown when wrapped with {{multiple issues}}. |fix= is then visible after clicking on "Learn more". You don't need a mobile device; you can check by using the "Mobile view" link in the footer. When |text= is used, it will get truncated since it is too long unless you add the appropriate class. Also, {{hidden}} does not work on mobile. — JJMC89 (T·C) 00:28, 5 August 2020 (UTC)[reply]

Released

The new functionality has been released as of this edit. Note: this change incorporates a change to safesubst added to the sandbox version but not by me, and I'm not sure how to test that separately; testcases seem fine, and I spot-checked a bunch of live transclusions, and everything looks fine.

Updates to the /doc page to follow. Thanks all, for review and tweaks! Mathglot (talk) 23:03, 1 August 2020 (UTC)[reply]

Done. First cut, anyway. Please have a look at the doc, and see if it needs anything. Thanks, Mathglot (talk) 06:36, 2 August 2020 (UTC)[reply]

External link transcluded from doc page stops working

Hi, Certes, can you help me figure out a problem I'm having with an external link? If you looks at the #External links section on the /doc page, and click the "Sample run", it works for me, and returns the three links listed higher up on the doc page as the example. If you go to the Template:Dablinks page and try the same thing, it doesn't work, and I'm not sure why. To get it working at all, I had to uri escape the left and right brackets; is there something I'm missing here? I just don't see why transcluding an external link from the doc page, would make it stop working. I must be missing something, but I don't see it. Mathglot (talk) 07:42, 2 August 2020 (UTC)[reply]

Okay, wait; now I'm getting inconsistent results, and for the first time, it's working on the Template page, but a couple of times, it didn't work from the /doc page. Could this be something about how it interacts when creating a named page (or unnamed, like '_NEW')? Could it depend on the history of my previous clicks from the same browser? I switched to another browser (Chrome) and it doesn't work on direct click from the Template page, but right-click + "Open link in new tab" it does work. From iOS (iPhone) it always opens in a new tab, and works. I'm confused. Do you see anything wrong with my url? Mathglot (talk) 07:50, 2 August 2020 (UTC)[reply]

Getting inconsistent results. I have one theory now, but haven't fully tested it; I think it might be naming the window, and if you already have a tab/window open with that name, it stops returning results. If this is right, then solution is kill all other tabs, and try again. Does it sound like I'm onto something? Mathglot (talk) 07:54, 2 August 2020 (UTC)[reply]

Nope; killed all PetScan tabs, still no go. Purged the page, started working again; clicked again, now it worked in two tabs. I give up. (For now.) Mathglot (talk) 08:03, 2 August 2020 (UTC)[reply]

@Mathglot: I'm also getting inconsistent results. It works the "first time" (I can't pin down exactly what I mean by that) but fails later. Also, taking a run which works and clicking Link to a pre-filled form for the query you just ran with ... auto-run fails, which suggests that we're not doing anything different and there's a bug in PetScan or something it uses. I make heavy use of Dispenser's tools and for now I'm continuing to run them via the IP address, constructing the URLs manually where the convenience links have been removed from the templates. Certes (talk) 09:25, 2 August 2020 (UTC)[reply]

@Certes:, thanks for the feedback. Do you know anything about the internals, or in particular, how to check how expensive the query is? It seems to come back very quickly, so I'm guessing not too expensive, but I don't know. The reason for the question is, I wonder if adding that link to the /doc page as I did, might give it too much exposure, and cause too much increased load on the servers. Then again, who reads a /doc page, lol... Do let me know if you think I should remove the link, or hide it in the middle of some talk page discussion or something, to make it less appealing to click. Mathglot (talk) 10:40, 2 August 2020 (UTC)[reply]

I don't know PetScan's internals, so run time is my only clue to efficiency. I think it's safe to advertise; not many of us will use it and we generally know our way round. I'd mention that it excludes redirects. I still prefer Dispenser's tool and it's a shame that it seems to be becoming deprecated. Certes (talk) 14:31, 2 August 2020 (UTC)[reply]

Should we include dispenser tool links from the doc page?

Should we add these links:

[https://69.142.160.183/~dispenser/cgi-bin/dablinks.py?page=ARTICLEPAGENAME check this page]
[https://69.142.160.183/~dispenser/cgi-bin/dab_solver.py?page=ARTICLEPAGENAME fix this page]

to the "External links" section of the doc page, perhaps with a brief warning about invalid certificates and the risk involved, linked to some standard explanation? (Maybe even our own, if there is such a page; we have DNS Certification Authority Authorization, but it's not very helpful for evaluating risk.)

Having them on the doc page seems like a level of indirection that would reduce usage from casual users compared to having check/fix links embedded in many articles, but would keep the links available for those who sought them out. Is this a good compromise, as far as exposing these links? At least on the doc page, we'd have the room to include whatever caveats we felt like including, whereas that's not really practical from inside the template banner. At least if they were on the doc page, those willing to accept the risk could still use them without too much difficulty. Mathglot (talk) 22:10, 4 August 2020 (UTC)[reply]

I think so. I keep dropping the links into talk pages but /doc seems like a better place to store them. It's also somewhere to advertise resumption of normal service or a replacement if one should appear. Certes (talk) 13:56, 5 August 2020 (UTC)[reply]

That's just what I was thinking, too. Mathglot (talk) 04:04, 6 August 2020 (UTC)

Done. Please have a look, and update as needed. Mathglot (talk) 04:19, 6 August 2020 (UTC)[reply]

Law of unintended consequences

The addition of the new optional parameters to this template has had an unintended consequence: editors helpfully fix the links in the body of the article, but forget to (or are not aware they should) remove them from the template at the top of the page. ~~If the editor fixes all of the ambiguous links in the article, no problem, since the bot will then remove the template on its next daily run.~~ But if the editor is only able to fix some of the ambiguous links, the links in the template remain as false positives on lists such as https://dplbot.toolforge.org/disambig_links.php. --R'n'B (call me Russ) 17:48, 25 August 2020 (UTC)[reply]

Oops. As the links in the template are intentional links to dabs, should they go to [[Foo (disambiguation)|Foo]] (or perhaps [[Foo (disambiguation)|Redirect to Foo]] where appropriate)? Certes (talk) 19:13, 25 August 2020 (UTC)[reply]

R'n'B, point by point:

editors helpfully fix the links in the body of the article..
Are they really doing that already? That's great!
..but forget to... remove them from the template at the top of the page
Yeah, not surprising. Are you saying that this is a problem? When I think of the number of {{Refimprove}} templates on pages that are full of footnotes, or other maintenance templates that outlast their usefulness by a decade, it's hardly surprising that a dablinks message might stay up there too long, until someone finally gets tired of it and removes it. Seems like worry #99 on the list.
...the links in the template remain as false positives on lists
Yeah, I can totally see that. And that's bad, why? Are they reporting on dablinks in the article, or dablinks listed in the template? If the latter, I would modestly suggest that that is the wrong approach. Those stats should be based on an actual count.

@Certes:, we may have interpreted Russ's comment differently; I don't see any problem with the sample links in the template itself, or rather, in the template /doc page; are you saying that those three links are skewing the statistics somewhere by three false positives because they are intentional? Oor perhaps it's your comment that I don't understand? Mathglot (talk) 00:09, 26 August 2020 (UTC)[reply]

I think Russ is reporting the following behaviour. If I've misunderstood then please disregard my comment above.

Editor adds links to dabs to article
Links to dabs correctly appear on lists such as disambig_links
Template appears on article, duplicating up to ten of those links to dabs
Editor fixes some but not all links to dab in article
Entire template remains on article because some links are unfixed. Unfixed links correctly remain on lists. Fixed links incorrectly remain on lists, because they are still in the template.

The problem is the bit in italics. The three links in the /doc are inconsequential. Is that right, R'n'B? Certes (talk) 00:27, 26 August 2020 (UTC)[reply]

@Certes: Yes, you've got that right. The links in the /doc page don't cause any problems. --R'n'B (call me Russ) 13:33, 26 August 2020 (UTC)[reply]

@Certes: Thanks, now I understand you, at least. We could simply place them in plain text, instead of linked, and then the problem goes away. It reduces the utility of the template somewhat, by making it harder to click through and examine the supposed dab page, but a user could still manage that via copy-paste and search. My question to you (or Russ) would then be, "Okay, some fixed links remain on lists. So what?" Not trying to be flip, just trying to cut to the heart of the matter. If we want to take away the links, I'd like to get more support (pro or con) than just the three of us. Mathglot (talk) 00:56, 26 August 2020 (UTC)[reply]

P.S. What if we code it as an external link (https...wiki/dabpage) instead of a wikilink; does it still remain on the lists in that case? Mathglot (talk) 01:01, 26 August 2020 (UTC)[reply]

Any of plain links, external links or the piped links I suggested above should solve the problem, and it's not a disaster if we fail to solve it – assuming, again, that I've understood Russ correctly. Certes (talk) 10:38, 26 August 2020 (UTC)[reply]

My initial assessment actually was wrong. If it were correct, this would probably be classified as merely a minor annoyance. However, on further study, what actually happens is that the bot looks at each page with {{dablinks}} on it and counts the number of remaining disambiguation links on the page. If there are four or fewer, it removes the template. However, the links inside the template count, so if no one manually removes them after fixing the links, and assuming there were more than four to start with, the bot will not remove the template. This is not just an annoyance, it is a problem. Either intentional dablinks or external link syntax should eliminate it. --R'n'B (call me Russ) 00:39, 1 September 2020 (UTC)[reply]
Assume you mean, [[Mary Jones (disambiguation)|Mary Jones]], generating Mary Jones; correct? Mathglot (talk) 08:48, 1 September 2020 (UTC)[reply]
That's one way, as recommended (without this circumstance in mind) at WP:INTDAB. Certes (talk) 11:26, 1 September 2020 (UTC)[reply]
Yes, that's what I meant by "intentional dablink(s)." --R'n'B (call me Russ) 12:52, 1 September 2020 (UTC)[reply]