Page MenuHomePhabricator

Create proof-of-concept script for warning wikitext editors after typing links to disambig pages
Closed, ResolvedPublic5 Estimated Story Points

Description

For the Disambiguation-Wish-2021, it occurred to me we could have JavaScript monitor text input and once they type a link to a page, we can query the API to see if it's a disambiguation page and if so show a "toast" notification (via mw.notify).

I'm creating this task to document the work done and collect feedback. A rudimentary script is now available for testing.

Installation on English Wikipedia

  • Make sure you're using the 2010 wikitext editor ("New wikitext mode" is disabled in your Beta preferences)
  • In your gadget preferences, under "Editing", enable the "Install scripts without having to manually edit JavaScript files" gadget. You can use this to easily enabled/disable user scripts.
  • Go to User:MusikAnimal/dablinkwarn.js then click on "Install" next to the page title.
  • Test anywhere in the mainspace. For now, it can be used in the userspace too, so your sandbox is a good place to test. Try typing for instance [[New York]]
  • You should see a notification bubble with suggestions of other similar articles. This is just a prefix search, so for "New York" you'll see suggestions for page titles starting with "New York".

Known caveats

  • Does not work in the 2017 wikitext editor (yet)
  • Can only detect links after ]] is typed. For instance, it does not detect dablinks added from a copy/paste.
  • Probably other bugs...

Further ideas

  • Only enable this feature for new users
  • Only enable for desktop, because on mobile the suggestions list could take up too much visual space for a toast notification.
    • Alternatively, we can omit the suggestions list for mobile users.

Event Timeline

MusikAnimal set the point value for this task to 3.Aug 11 2021, 4:33 AM

Installed in my username, and was able to successfully test here are some screenshots at different screensizes! Exciting to see the beginning of this work! I know this is a proof of concept ticket so not sure if this is the place to a few bugs below

The toast shows up twice if I have the link twice in the text box, after I type it in the second time, it triggers twice:

image.png (1×1 px, 362 KB)

In this example, I got a warning for the prior link I added, if you look closely in the screenshot, I had introduced a link to mercury, but earlier on in my text, I had typed new york, it only warned me for new york, not for Mercury:

image.png (1×1 px, 355 KB)

If I click on any of the links that the toast displays, it changes to that link in-tab and leaves the page and hence my edits. I think it should open in a new tab, and perhaps it should display the links as wikitext rather than as links? so that the author can paste them into the article if they meant one of them, rather than taking them to a new tab? thoughts!

Some other open questions for @nayoub/ @MusikAnimal
Is color something we can introduce to the toast? I definitely think we should make the toast last longer-- like 10 seconds? I worry about people with screenreaders or any other accessibility concerns.

This is really cool! We can explore different options with color as well that will emphasize the warning.
Agreed for the longer toast. I'm also curious as to what happens when you click one of the suggestion links? Does it pop up the link selector and replace it for the user to approve? Or does it simply link to the article?

@NRodriguez @nayoub Alrighty, all reported bugs fixed, I think!

Is color something we can introduce to the toast?

We can explore different options with color as well that will emphasize the warning.

I've changed the notification type to warn which makes it a bit more prominent.

If I click on any of the links that the toast displays, it changes to that link in-tab and leaves the page and hence my edits. I think it should open in a new tab, and perhaps it should display the links as wikitext rather than as links?

I'm also curious as to what happens when you click one of the suggestion links? Does it pop up the link selector and replace it for the user to approve? Or does it simply link to the article?

The current article link and the disambiguation help page link now open in a new tab.

I've also made it so that when one of the suggestions are clicked, it attempts to replace the dablink with the suggestion. This part I think can be somewhat fragile. For instance, if you change the wikitext while the popup is still open, it won't know what to replace anymore. For now, I have it so that it does a strict comparison to ensure the wikitext link is the same as when the popup appeared. If it changed, it will instead open the suggested article in a new tab. In all situations, you can still open the link in a new tab by using your brower's secondary click (i.e. right click) context menu.

We could show wikitext in the popup as NRodriguez suggests, but I worry people will attempt to copy/paste it and that would (by default behaviour) dismiss the popup. Additionally, it's possible the wikitext could be very long and hence would make the popup overly large, especially if there are a lot of suggestions. For instance, [[New York City|the largest city in the United States and the second largest in North America]] – then multiply that times however many more suggestions there are.

I definitely think we should make the toast last longer-- like 10 seconds? I worry about people with screenreaders or any other accessibility concerns.

I've changed it to be a "long" type of notification, which lasts for 30 seconds.

Re: accessibility for screen readers – When we worked on Expiring-Watchlist-Items, we added aria controls to alert the user about the popup (T261431), but this apparently didn't do anything, at least for one prominent user who uses a screen reader (T261431#6500675). Regardless, I believe the accessibility issue with these toast notifications is a broader issue in MediaWiki and not unique to this project. But +1 for at least thinking about screen readers! :)

With the aforementioned issues addressed, I'd like to stop now for this proof of concept. The code I've written thus far is a bit hacky and will need some cleanup if it were to go into MediaWiki (as opposed to a user script as it is now, where hackyness is acceptible :)

That said, I'm assuming we'll want to move forward with this? The feedback from the community thus far has been supportive. So from here we can write a new ticket to get this into MediaWiki (the Disambiguator extension, specifically).

I'll also note that while the code largely works as it is now, it revolves around regular expressions which makes me think it is highly prone to error. We will need extensive testing. It might even be worth having QA try out the user script now so that we know what to focus on as we do the proper implementation. But perhaps we should come up with a list of product requirements first.

Additionally, the rollout will need to be very slow, starting with just a few pilot wikis who show interest. On larger wikis, at least English Wikipedia, this will need prior community consensus, seeing as a 2016 request for comment about warning users about disambig pages failed miserably. That RfC was about warning on save, however, so it's no surprise to me people were against it. The toast notification does not introduce a strict barrier to saving edits, so hopefully this will be less controversial. It may be worth getting a head start on the communication. Once we have the product requirements ironed out, we should solicit broader community input. This is assuming we want the feature to be on by default. If it is opt-in, we can probably proceed without as much worry, but that sort of defeats the point because new users are unlikely to try out random features in their preferences, especially something confusingly called "disambiguation".

Yes, we will be moving forward once we get feedback on the designs. Sorry for the delay in response! Glad to see the early feedback. Here are the state of the designs today:

WE_Toast.png (1×2 px, 376 KB)

Going to post in project page and get feedback, but i think it's ok to stop the proof of concept and move forward with it as a polished ticket!

NRodriguez changed the point value for this task from 3 to 5.