Talk:Community Wishlist Survey 2021/Warn when linking to disambiguation pages

Feedback on project page and proposed solutions

Hey all, thanks for your comments on the #2 Wish of the 2021 Community Wishlist Survey! The Community Tech has started work on this wish and we wanted to make you aware of this. We'd love to hear your input. Thanks for being such proactive members of the wishlist. NRodriguez (WMF) (talk) 20:00, 23 July 2021 (UTC)

Per request, I've pinged all voters. SGrabarczuk (WMF) (talk) 22:25, 26 July 2021 (UTC)

Thanks for letting us know. It is unfortunate that the proposal will only cover Visual Editor. Some of the answers to your questions (along with current tools etc are at en:Wikipedia:WikiProject Disambiguation, and I will add a note on that talk page + en:Wikipedia:Disambiguation pages with links (as that is where mst of the people who fix these discuss issues). The estimate is around 500-800 links per day & running totals can be seen at en:Wikipedia:Disambiguation pages with links/The Daily Disambig. If you need any clarification or other (non-technical) help just let me know.Rodw (talk) 20:41, 23 July 2021 (UTC)

That may not be a problem. Whatever we old hands think of VE, the newer editors who create most of the links to dabs are guided towards it. Although it would be better to include everyone, the proposal may be aimed at (or at least randomly hit) the users who need it most. Now we just need to enlighten those who think Apple is a technology company and Birmingham is in Alabama... Certes (talk) 21:51, 23 July 2021 (UTC)

Or indeed that Fox is a media company. Narky Blert (talk) 07:38, 26 July 2021 (UTC)

I welcome this proposal, and agree with Rodw's estimate of the size of the problem. The duplicates (most of the top 300 in his range) typically arise from failure to w:WP:FIXDABLINKS after a move. For a recent example, see w:Wikipedia talk:Disambiguation pages with links#Circa. I know of at least one editor who specialises in those, and they are usually fixed within a day or two. The remainder almost all result from failure to w:WP:TESTLINK, and those are the ones which this proposal can address. It takes at least three editors working full-time to keep them under control. (Between April and June 2021, we were short a warm body or two, and the headline number in w:WP:TDD#Table 1 Column 1 increased from 4,000 to 10,000.) I estimate that new links to DAB pages are all currently looked at, and either fixed or tagged, within 2 to 3 months; the first time I went through the main Disambiguation Pages with Links report, it took 8.

There's a setting in w:Special:Preferences-Gadgets which displays links to DAB pages in orange, which I highly recommend to DABfixers and other experienced editors. I recall a recent discussion (which of course I cannot find) at w:Wikipedia:Village pump (proposals)/Archive 174#Make links to disambiguation pages orange by default as to whether it should be the default. The general feeling (with which I agree) seemed to be that newbies are confused about enough things without deliberately confusing them further. Narky Blert (talk) 09:25, 24 July 2021 (UTC)

Do we know what proportion of edits are made using Visual Editor, or what proportion of editors use it? (I expect the two differ, with VE users making far fewer edits each.) Of course, no editing tool will address the aftermath of moving a disambiguation page to the base name, as the many articles which suddenly link to the dab have not been edited. Certes (talk) 20:04, 24 July 2021 (UTC)

As I've said over there in the proposal already: Heißt das, der Haken beim Begriffsklärungscheck (d:Q6047536) sollte automatisch gesetzt sein? Denn die Funktionalität ist ja schon lange vorhanden, auch ohne dafür zum Scriptkiddie mutieren zu müssen.Does that mean, the gadget Begriffsklärungscheck (d:Q6047536) should be made default-on? The functionality is something, that's there since a very long time, even without having to transform into a script-kiddie.

Or what else will be changed? And of course: What will be changed for normal editing in the WikitextEditor? Grüße vom Sänger ♫^(Reden) 08:37, 24 July 2021 (UTC)

Comment. I like the idea of subtly guiding users away from making a mistake rather waiting for them to make that mistake and then outputting a warning about it. There have sometimes been proposals over at enwiki for warning users when they attempt to save an edit of a certain type (including specifically for edits that introduce a dablink), but they have invariably been rejected by the community as the cost of deterring content contributions has been seen as greater than the benefit of avoiding certain fixable issues like dablinks. Uanfala (talk) 18:17, 25 July 2021 (UTC)

Wiki policy is complex enough, but e.g. 'orange' on automatically to show you have linked to a disambig page is surely no more compjext than blue or red links, and means it can be fixed there and then ( hopefully). That is much less discouraging to new/ Visual Edit only editors than a later alert Error message requiring new and interactive correction. Kaybeesquared (talk) 21:35, 26 July 2021 (UTC)

Don't bank on it. When I joined WP, it took me some time to work out the difference between red- and bluelinks. I doubt I am alone in my stupidity. Narky Blert (talk)

Comment. The feature to show disambiguated links in orange has been a godsend, and has allowed me to correct disambiguations accidentally created on transit articles I monitor.--Kew Gardens 613 (talk) 22:44, 26 July 2021 (UTC)

@Certes, Rodw, Kew Gardens, Narky Blert, and Sänger: Hello 👋🏼 Everyone! Thank you for the feedback! I will work my way through the handy links folks included and look at your comments with incoming detail. I wanted to clarify one point that I may have made confusing in the project page, we are focusing on the part of the experience after someone clicks on the link icon in the toolbar. A search box appears and people can type in links and search them. We are focusing on that because most users (even experienced and new alike) use that tool to introduce links on the platform. This link button is available outside of VE. Technically, someone using wikitext could click on the link button in the toolbar and benefit from the changes this project will focus on. Good to see that for the most part, the idea of moving dab links to the bottom of the search results and the proposed solutions on the project folks are sitting good with folks. Will dive deep into the links you sent now and that orange dab link you mention! Thanks again, those resources and your input are so important. NRodriguez (WMF) (talk) 14:08, 28 July 2021 (UTC)

Do editors see a short description or other clue in the dropdown? enwp dab SDs read "Topics referred to by the same term", which might give a clue that these are not the targets you are looking for. Certes (talk) 14:53, 28 July 2021 (UTC)

I'm glad that editors who don't use VE will have some access to the facility. Will they be given any warning if they don't use the link button, e.g. if they type in [[Mercury]] to link to dab Mercury? Certes (talk) 14:53, 28 July 2021 (UTC)

Or as a very common example, w:New York. That DAB page routinely collects 5-10 bad links every single day of the year. Narky Blert (talk) 14:30, 31 July 2021 (UTC)

When do we link to dab pages?

This question was asked in the proposal page. Deliberate linking to a disambiguation page happens most often from other disambiguation pages (typically, within their "see also" sections) or from within hatnotes (i.e. certain templated lines of text at the top of articles or sections). But links to disambiguation pages can be used anywhere – even within article text – if reference is being made not to a particular topic but to the ambiguous term itself. On the English Wikipedia at least, the conventions is that any sort of deliberate link is piped via the corresponding redirect ending in (disambiguation) (en:WP:INTDABLINK). Uanfala (talk) 18:17, 25 July 2021 (UTC)

AFAIK, that useful convention is unique to enwiki. Narky Blert (talk) 07:39, 26 July 2021 (UTC)

In der deWP werden nur dann Klammerlemmata angelegt, wenn es absolut notwendig ist. Wenn die Begriffsklärungsseite klammerlos ist gibt es keinerlei Anlass für eine mit Klammer, also gibt es diese seltsame Konvention auch nicht.

In the deWP lemmata with brackets are only there if unavoidable. If the disambiguation pages are without brackets, there is no reason for another one with brackets at all, so there is of course not this strange convention.

Grüße vom Sänger ♫^(Reden) 07:59, 26 July 2021 (UTC)

It should be done if it is a vague concept - Let's say the article mentions trees, then it should link to that disambuation page if the hyperlink highlights the word "tree" in the context of trees in literature, since there is not a single specific article mentioned it links to the disambiguation page instead, preferably with an anchor (Tree (disambiguation)#Literature). MarioSuperstar77 (talk) 22:14, 26 July 2021 (UTC)

You've got the idea - links should always be as useful to readers as possible. Narky Blert (talk) 22:35, 26 July 2021 (UTC)

I think that if there is a need to discuss trees in the context of literature, linking to the disambiguation page would be unhelpful, since it only lists works with the title "Tree", which may not be about trees at all. If it is useful to discuss this as a concept, we should have an article on "Trees in literature". The only time I would link to a disambiguation page is if the link itself were to deal with the ambiguity of the term. BD2412 T 03:34, 3 August 2021 (UTC)

Ich habe oft Links in dewiki gesehen, die auf eine Begriffsklärungseite fehlerhaft verlinken. Wenn Sie meinen Benutzerbeiträge überprüfen, werden Sie sehen, dass ich die reparieren habe. Narky Blert (talk) 22:18, 26 July 2021 (UTC)

Design considerations (personal musings)

The aims of this initiative are:

1. To help people become better editors
2. To improve the encyclopaedia
3. To reduce the workload on DABfixers

Strictly in that order. #2 and #3 will flow from #1.

Editors must not be prevented, or even discouraged (no matter how mildly), from adding ambiguous links. An inexperienced editor may not know how to create a good redlink, or how to find and link to a corresponding article in another language, or even how to identify which (if any) of several existing articles is the correct one; let alone how to assess w:WP:NOTABILITY. (1) Non-standard redlinks may get overlooked when an article is written, and become orphaned, or even result in duplicate articles. (2) Misguessing a bluelink damages the encylopaedia. The number of bad bluelinks is a w:unknown unknown, but is certainly not trivial; I've fixed bluelinks which had directed readers for over a decade towards badly wrong destinations. (The paradox is that readors who know the subject are unlikely to click on such a link, and notice.)

Don't even get me started on templates which combine several elements into a single link. w:Template:Sortname is probably the simplest, and it's possible to get that one wrong in several ways. Some of the others took me 15+ minutes to learn.

The message to inexperienced editors must always be, Don't worry about such problems - your best is good enough. Narky Blert (talk) 22:21, 26 July 2021 (UTC)

• I disagree with this. We prevent editors, experienced or not, from saving edits with blacklisted external links, and with other edit-filtered terms. The idea that editors must not even be mildly discouraged from making errors is excessive. At least with respect to very common cases (rock music versus rocks in geology, electric batteries versus artillery batteries, the U.S. state of Georgia versus the Asian country of Georgia), we should prompt people to correct themselves before saving an edit where possible. That is helping them become better editors. BD2412 T 16:16, 2 August 2021 (UTC)

  My point is - editors should be encouraged to fix ambiguous links if they can, but not be discouraged if they don't know how to. I would add w:New York, a notorious battleground, to BD2412's examples.

w:Bears, w:Eagles, w:Lions, w:Tigers, and so on are a separate issue. In my experience, w:Wikipedia:Requested moves on links like those almost always result in w:WP:NOCONSENSUS, because one or two participating editors see no problem in linking to an animal when a sports team is intended. Narky Blert (talk) 20:22, 3 August 2021 (UTC)

@BD2412@Narky Blert Thanks for having this thought provoking discussion on the page here! I agree with multiple points. I would chime in to say that the proposed solutions keep both objectives in mind:

• Editors should be be encouraged to fix ambiguous links if they can, but not be discouraged if they don't know how to.
• The platform should enable the desired linking behavior, which in majority of cases, is to cite a specific article, not a disambiguated page. In that way, our changes are preventative of mistakes, enabling the right behavior, rather than discouraging someone to publish at all.

I believe the difference is in the use of the word "preventative" versus "discouraging"-- it would be in bad form to discourage editors from publishing because they may have introduced a faulty link. In an ideal world, we allow editors to search links that are specific to the knowledge they seek to cite before we present them the disambiguated pages, which are not articles in and of themselves. In this framing, the onus is on the platform to serve as a tool to search for the right link when looking to cite a related article. Hope this makes sense, and we welcome all the musings! NRodriguez (WMF) (talk) 18:32, 6 August 2021 (UTC)

Revision tag for edits that add dablinks

I've just finished up phab:T287549 which would add a revision tag (aka change tag) to edits that add links to disambiguation pages. This would both make it easier for communities to track how many dablinks are added and by what means (VE/wikitext, mobile/desktop, etc.), but also help patrollers fix them since you'd be able to filter by this tag at Special:RecentChanges and in your watchlist. @Kew Gardens 613 @Narky Blert @Rodw @Certes @Kaybeesquared @Sänger What do you think of this idea? MusikAnimal (WMF) (talk) 17:52, 3 August 2021 (UTC)

I wouldn't use it. It takes me two months or so to cycle through Disambiguation Pages with Links as it is. I rely on my w:Spidey-Sense to check for possible serial offenders (who are mostly registered editors who can be woken up with a revert or a friendly notice on their talk page (I think I've now cleaned up after a recent one who was making good-faith edits which violated w:WP:INTDABLINK and had broken several hundred links), or more often unregistered editors to whom w:WP:THEYCANTHEARYOU applies, or very occasionally hopeless w:WP:CIR IPs who need a block).

I don't work w:WP:TDD#Today's highlights, which reports DABlinks created in the last 24 hours, but I know editors who do.

Finding DABlinks isn't a problem. Stopping them being made and fixing them once made (500-800 per day) is. Narky Blert (talk) 20:58, 3 August 2021 (UTC)

I have to support it as being better than nothing, but notifying the army of volunteers needed to undo the damage is very much a second choice to preventing the problem from occurring in the first place. As the previous comment says, finding bad links is a solved problem. We were hoping to avoid their creation, and not just in Visual Editor. Certes (talk) 22:10, 3 August 2021 (UTC)

Indeed. The idea came about because we wanted data on a breakdown of how dablinks are added (VE/wikitext, user experience levels, etc.). Originally we were going to use EventLogging to record this data, but revision tags would allow us to get the same data and expose the edits for the benefit of patrollers. English Wikipedia seems to have many tools to assist with this but I take it other wikis do not, so hopefully the revision tag will be of use to them.

I just had a slight worry about a tag called "Disambiguation links" showing up in change lists would catch folks by surprise and perhaps they wouldn't like the clutter. Unfortunately it doesn't seem possible to have an "invisible" tag that can still be used at Special:RecentChanges.

So anyway I think we'll move forward with tagging the edits, barring objections. MusikAnimal (WMF) (talk) 02:31, 4 August 2021 (UTC)

AFAIK, ruwiki is the only WP other than enwiki which highlights links to DAB pages in any way (by backlighting in purple; see e.g. w:ru:Анна Каренина (значения)), though I haven't checked preference settings everywhere. It is a source of considerable annoyance to find, when attempting to solve a DABlink problem in enwiki, that the article in the home language also links to a DAB page. Most of my edits to non-English WPs have been fixing such problems whose solutions I've found by other means. Narky Blert (talk) 09:14, 5 August 2021 (UTC)

Monitoring effectiveness (Aug 2 update)

This seems to be moving forward and it will be interesting to see what effect it has. On the August 2 update it says "monitoring the numbers inside The Daily Disambig to see if it has any impact on the number of unwanted dab links being added". It may be worth noting that Today's Dablink Report, Disambiguation pages with links, Articles with the most disambiguation links & Templates with disambiguation links are updated twice a day whereas The Daily Disambig is only updated once a day, therefore any new dab links fixed after the 12 hourly updates, but before 24 hours, are not included in the Daily Dab report. This may not be significant if a trend over multiple days is used for the monitoring.Rodw (talk) 19:59, 5 August 2021 (UTC)

Hello! Thanks for pointing us in that direction. Will monitor those links as well given that they are updated twice a day rather than once. Appreciate the input and close watch to the release! NRodriguez (WMF) (talk) 18:01, 6 August 2021 (UTC)

Warning wikitext editors after typing links to disambig pages

Hello gang! We have devised a possible solution for wikitext. Just after a user types a disambig link, we can show a toast notification warning them what it is and possible alternatives. I have made a rudimentary user script to illustrate this idea. See phab:T288589 for details and installation instructions.

In particular, be mindful this could be buggy and comes with some caveats. For instance it does not (yet) work in the 2017 wikitext editor, and it only detects links after the user types closing brackets ]], so it won't detect dablinks from copy/paste or other means. Some of these issues are resolvable, others may not be, but I just wanted to get a high-level evaluation of what you think of this solution. Is it too intrusive? Too confusing for newbies? I was thinking we'd probably only enable this for new users, should we be concerned it could be an annoyance for the more experienced folks such as yourselves.

Pinging recent participants on this talk page: @Rodw @Narky Blert @Certes @Kew Gardens 613 @BD2412 @Uanfala. Thanks for your feedback, MusikAnimal (WMF) (talk) 21:10, 11 August 2021 (UTC)

Let's see what happens!

IDK how this is going to work, but this experienced editor won't be fazed in any way at all by a message telling me that I'm trying to make a mistake.

It's much more important to ensure that newbies aren't puzzled or put off. Narky Blert (talk) 21:19, 11 August 2021 (UTC)

NOTE: some editors, in my experience particularly from the Subcontinent, have a habit of adding unnecessary/useless spaces inside all sorts of parentheses, braces and brackets. Any worthwhile DABlink filter must check for this. If FizBuz were a DAB page, [[ FizBuz ]] is as useless a link as [[FizBuz]] (and as [[FizBuz|FizBuz]]). Almost every experienced DABfixer will have seen examples of both, as attempts to react to a DPL bot nastygram. Narky Blert (talk) 21:33, 11 August 2021 (UTC)

Fortunately the API doesn't care about leading/trailing spaces, so we don't even need to implement trimming. But I will anyway for good measure. Thanks for pointing this out, MusikAnimal (WMF) (talk) 22:36, 11 August 2021 (UTC)

I've installed the .js and it looks very useful. I expect it to annoy me occasionally, but that's no problem because it's aimed at less experienced editors. One thing may confuse newcomers: clicking on a link such as New York City in the toast(?) dialog takes me out of edit and into the NYC article (consistent with every other wikilink) but a newcomer might expect it to magically fix their new wikilink and let them carry on editing. Certes (talk) 21:23, 11 August 2021 (UTC)

I too am baffled as to whether "toast notification" refers to the commonest meanings, namely w:toast (food), w:toast (honor), and w:toasting (Jamaican music), or to something else. What does it mean? Narky Blert (talk) 21:43, 11 August 2021 (UTC)

Hehe, it's just a fancy word for w:Pop-up notification (it is the second alias in bold in lead sentence). To me toast notifications are usually stackable and off to the side, rather than an "alert" or the like that is meant to grab your immediate attention. I'm not sure what they're actually called in MediaWiki, but there are many other types of notifications so this is the word that came to mind :) MusikAnimal (WMF) (talk) 22:29, 11 August 2021 (UTC)

This is a useful tool. I've just tested it out and I think I've come across the first bug (try it: just type a second dablink). The list of suggestions in the pop-up window is useful, but clicking on a link just takes you to the corresponding article: my first thought when seeing a link was that clicking on it will fix the offending dablink with a link to that article.

If the gadget doesn't work for copied text, that's actually a good thing: the last thing you'd want when merging or restoring is a pop-up nagging you about a minor imperfection of the pre-existing text.

This is a great tool to have as an opt-in. I'm not sure it will be a good idea to enable it by default for newbies though, at least not on enwiki: it's less intrusive than the proposed notification from the 2016 RfC, but given how soundly that was rejected, I won't hold my breath if this gets proposed. Uanfala (talk) 21:34, 11 August 2021 (UTC)

@Uanfala Could you link to the RfC you're referring to? I tried searching the Village Pump archives. At any rate, if the community won't allow this to be default-on for newbies (I suggest only default-on for newbies), than that kind of defeats the purpose. New users are unlikely to try out random features in their preferences, particularly for something called "disambiguation" which to most people is gobbledygook.

Certes also made the suggestion to make the links replace the dablink. I will look into that but it might be tricky. Also thank you for pointing out the bug with adding a second dablink. I had already fixed that once but I guess I broke it again! MusikAnimal (WMF) (talk) 22:46, 11 August 2021 (UTC)

The RfC is at Wikipedia:Village pump (proposals)/Archive 133#Confirm on save when adding links to disambiguation pages. Uanfala (talk) 22:54, 11 August 2021 (UTC)

Ha! I even commented on the proposal myself. How quickly I forget…! Anyway, this proposal was explicitly about warning on save, which of course is also what the wish asked for, but I don't think we (Community Tech) were ever planning on that. We don't want to introduce more barriers to saving, and it's no surprise to me the community shared the same sentiment. This is precisely why I thought up the idea for the pop-up notification to be shown as the user is typing. This does not introduce any barrier to saving, and also conveniently notifies you right after you introduce the dablink. Nonetheless, we will certainly solicit broader input from the community before moving too much further with this. Thanks for reminding me of the RfC :) MusikAnimal (WMF) (talk) 00:24, 12 August 2021 (UTC)

There was also a more recent RFC (2020) at en:Wikipedia:Village_pump_(proposals)/Archive_174#Make_links_to_disambiguation_pages_orange_by_default.Rodw (talk) 10:39, 16 August 2021 (UTC)

Hello everyone, I wanted to share the latest update on the proposed designs which relate to this topic! Find the designs here here @Rodw @Narky Blert @Certes @Kew Gardens 613 @BD2412 @Uanfala. Thanks for your continued feedback and for testing the user script for the proof of concept, NRodriguez (WMF) (talk) 22:24, 18 August 2021 (UTC)

August 18, 2021: Design Feedback

That looks very promising. I'd make a couple of minor wording changes:

• Replace "…it's a disambiguation page that leads to more articles on the topic" by something like "…it's a disambiguation page (a list of topics with similar names)". Rationale: the alternatives aren't articles on the same topic; they're articles (or redirects to articles) on similarly named but different topics.
• Replace "This page is not article, it groups all articles by the same term." by something like "This page is not an article; it lists topics with similar names." Rationale: The dab is more of a list than a group, and not all of its entries are articles.

I almost wrote "index" rather than "list". The term is not used in this context on enwp, where an "index" is a type of article rather than a dab, but it might convey our main point (being a non-article page) more clearly to an inexperienced editor. Certes (talk) 23:05, 18 August 2021 (UTC)

Thank you so much for outlining your rationale @Certes! The designer, @Nayoub_(WMF) and myself really appreciate the level of thought that went into this note and word choice. We will be incorporating this language since it brings clarity to these descriptions! NRodriguez (WMF) (talk) 23:35, 18 August 2021 (UTC)

@NRodriguez (WMF), I tried to to "Mercurie" at the English Wikipedia in the visual editor. (It's a redirect to the disambiguation page for Mercury.) The term I typed didn't appear in the search box at all. The last item was the page (Mercury) that it redirects to. Is this expected? (I'm definitely not saying it's bad, I'm just curious whether it's intentional.) Whatamidoing (WMF) (talk) 19:21, 24 August 2021 (UTC)

Hello there! We did not change any of the underlying search functionality, so the search you did should yield the same search results as if you had searched "Mercurie" two weeks ago-- since the page does not actually exist but it is rather a redirect, it also previously not appear in search. The only difference from our changes in the VE this month is that the disambiguated page that it redirects to "Mercury" will now appear last in the top 10 rather than as the first option. Is this an expected behavior for you? Where you testing it to so you could see the interaction pattern and expecting a different outcome? NRodriguez (WMF) (talk) 13:30, 25 August 2021 (UTC)

Thanks. I was testing it at the English Wikipedia, for the purpose of seeing what would happen. I think in the past that the redirect's target page has been first, and the redirect itself has been second. I wonder whether "Mercurie" is now link #11. Whatamidoing (WMF) (talk) 17:31, 25 August 2021 (UTC)

Participate in a short Usability Test for this Wish

@Certes@Rodw@Narky Blert@Kew Gardens 613@BD2412@Uanfala

Hello everyone, hope you've been well! I am writing to you all because are looking for volunteers to try out a prototype of our new changes to the software. We would like to test them before we release them. This method is known as usability testing. It helps us understand if what we built is something editors can easily use.

The test will be conducted through a tool called UserTesting.com. It requires:

• Download of the software as well as an email address.
• Access to microphone and screen recording so that we can see how you use the software.
• Between 5 minutes to 15 minutes of your time.

There is no "right or wrong" way to participate.

We will not be using any of the personal data publicly. Your data will be deleted once we review the test and make sure that the software works as intended. We understand if this makes it difficult to participate.

If you would like to participate, please respond to this thread letting us know and then visit the user test website to complete the test.

If you are unable to participate and want to help us test functionality without recording yourself, we can send you the test script if you respond with interest here. Then you will be able to conduct a test on your own and post feedback here. NRodriguez (WMF) (talk) 19:19, 30 September 2021 (UTC)

I have neither a microphone nor a screen recorder (sooo 20th Century), but would be happy to help. Narky Blert (talk) 19:29, 30 September 2021 (UTC)

@Narky Blert Great, totally understand not having either a mic or a screen recorder! We really appreciate your willingness to help anyway. Here is a pdf I uploaded with written instructions on how to participate on the test. Feel free to section off your feedback here on the talk page. Thanks so much again! NRodriguez (WMF) (talk) 20:32, 30 September 2021 (UTC)

Wow, that's a SEAOFRED!. If I preview the first suggested change, Mercury is a bluelink! It's only if I mouseover it that I see the msg "This title relates to more than one page". On saving (which saw me as an IP (has that global block been lifted?); now self-reverted), I got no warning of any kind. Narky Blert (talk) 20:51, 30 September 2021 (UTC)

Ah ok, this is good for us to know! And yeah re: sea of red, we were worried that all the red links on beta would be disorienting. We pasted the same article from English Wikipedia, but unfortunately that meant all the links that do not exist on beta will appear as red which could be startling to the eye if you don't know why they're red. Anyway, thanks for taking the time and giving us the notes about only seeing the message on mouseover. It's helpful to know this! NRodriguez (WMF) (talk) 21:21, 30 September 2021 (UTC)

Is there a deadline/preferred time frame to participate? BD2412 T 20:04, 30 September 2021 (UTC)

We would love to receive feedback by next Thursday October 7, 2021. Any time zone is ok with us as long as it is at the end of the day then. Can't believe it's October next week already! Anyhow, thank you so much for being willing to participate. NRodriguez (WMF) (talk) 20:33, 30 September 2021 (UTC)

Thank you for developing this functionality and for starting the feedback process. The message box pops up at the correct times and explains the problem well. Experienced editors should know how to fix the link (or to identify a rare occasion when they shouldn't). Newer contributors will probably click "Review link", watch it select the wikilink they just typed, and may be confused about what to do next, i.e. how to improve that wikitext. Of course, a good way to do that is to open the message box's handy "Mercury" link in a new browser tab, peruse the links and copy the most appropriate one to the start of the wikilink followed by a pipe character, e.g. to change [[Mercury]] to [[Mercury (planet)|Mercury]]. Whether those steps are sufficiently obvious depends on the target audience. Certes (talk) 23:45, 30 September 2021 (UTC)

Re: open questions

Is there a way to see the latest text in the usability test? I don't want to give feedback on an old revision :)

Notification as one types, while not getting in the way of saving, does sound like a good solution. [And on save, could provide a summary of issues w/ the save -- compare how Overleaf provides a tiny summary of errors+warnings while not interrupting the edit - render cycle. –SJ talk  20:53, 27 October 2021 (UTC)

Hey @Sj thanks for writing! We usually run one round of user testing and then gather feedback on the talk page on the open questions. This feedback is useful!

> [And on save, could provide a summary of issues w/ the save -- compare how Overleaf provides a tiny summary of errors+warnings while not interrupting the edit - render cycle.

This is out of scope for the solution given the complexity of building a technology that would scrape the change and summarize at the end. The research validated that a subtle warning during the edit is a better way to prevent the edit rather than at the end when people are reviewing and ready to publish.

Our designer just wrote up a summary of the findings which I am going to post in the project page. Thanks again for the input and for your continued feedback! NRodriguez (WMF) (talk) 18:04, 8 November 2021 (UTC)

Jan 2022 update

Thank you to everyone who has been involved in this work. I will keep an eye on the stats and see if we can identify the effects.Rodw (talk) 08:35, 21 January 2022 (UTC)

Seeing this, too; it looks good!

@NRodriguez (WMF), I'm curious, what's the name of the light orange box that pops up, and is there any documentation on it? I'm asking since there are several other situations in which we might want to trigger something like it, such as adding an external link to a body section, and I'm wondering how feasible it'd be for the community to try building triggers/notices for some of those. Best, {{u|Sdkb}} ^talk 07:24, 24 January 2022 (UTC)

Thanks for writing (and for participating in the 2022 wishlist as well) The documentation we generated for the project can be found here Not sure if it's immediately applicable to the use case you mentioned, but I hope this can be of help! I think that re-using this component to give feedback in other instances where it makes sense could be a powerful use of the feature. Regards, NRodriguez (WMF) (talk) 23:38, 24 January 2022 (UTC)

@Sdkb The notification itself is just a mw.notifty() with type: 'warn' passed into the options hash, if that's what you're asking about. Anyways, yes, a similar gadget to enforce w:WP:ELPOINTS #2 is certainly feasible. Unlike the disambig notification, this wouldn't require an API request and could be implemented completely with regular expressions, so I would guess the performance impact is slim to none. In my opinion it would make more sense to implement it this way than with an edit filter. MusikAnimal (WMF) (talk) 21:45, 30 January 2022 (UTC)

@MusikAnimal (WMF), that's good to know! Discussion on this has moved to w:Wikipedia:Village_pump_(technical)#Adding_a_new_edit_filter_trigger_action:_pop-up_box, so I'd love to hear your thoughts there. It would be amazing if we got something like this working and established a process for designing triggers and warnings. {{u|Sdkb}} ^talk 21:51, 30 January 2022 (UTC)

t would be amazing if we got something like this working and established a process for designing triggers and warnings.

@Sdkb I'm dropping by here to mention that in the coming months (once work on Phase 1 of the Talk Pages Project wraps up, the Editing Team will be working on developing a way to offer people editing within VE real-time feedback about the changes they are in the process of making.

Would you like me to ping you when we have a project page up on mediawiki.org?

...in the meantime, I've added the "external links in body sections" idea to the Phabricator ticket where we are organizing this work: T265163#8129130.

Thank you to @NRodriguez (WMF) for making me aware of this discussion! PPelberg (WMF) (talk) 18:15, 3 August 2022 (UTC)

That sounds great, @PPelberg (WMF); please do let me know! {{u|Sdkb}} ^talk 18:45, 3 August 2022 (UTC)

Will do :) PPelberg (WMF) (talk) 18:48, 3 August 2022 (UTC)

opt out?

Is there a normally supported method to opt-out of this popup thing per user? — xaosflux ^Talk 00:02, 29 January 2022 (UTC)

@NRodriguez (WMF): perhaps? I'd rather not disabled the entire notifications area to just avoid this one. — xaosflux ^Talk 00:26, 29 January 2022 (UTC)

@MusikAnimal (WMF): (from several of the phab tasks). — xaosflux ^Talk 00:27, 29 January 2022 (UTC)

mw:Just make it a user preference doesn't scale well. SD0001 (talk) 14:51, 29 January 2022 (UTC)

@SD0001: since this is an extension, adding a single hook for it shouldn't be a big deal. Not loving that we have an only-on extension to force text evaluation of every keystroke. — xaosflux ^Talk 16:28, 29 January 2022 (UTC)

@Xaosflux We will not be adding a preference, per SD0001, but we can make it so you can hide it with your personal CSS. I thought we had already done this but it doesn't appear it has a unique ID or class name... we'll get that added, but in the meantime, since this is probably the only notification of type "warn" you'll experience, you could hide it with .mw-notification-type-warn { display: none; }. Sorry for the inconvenience, MusikAnimal (WMF) (talk) 19:33, 29 January 2022 (UTC)

@MusikAnimal (WMF): yea, I was thinking of that lack-of-class thing, but then got to thinking about the architecture of this - I haven't dove in to it: where is the keystroke by keystroke real-time analysis taking place, client side script right? Are more of such things planned, pretty sure we'd reject a lot of gadgets that forces that sort of behavior on to clients. — xaosflux ^Talk 23:11, 29 January 2022 (UTC)

@Xaosflux If your concern is performance, I can assure you that isn't an issue. The thought of monitoring every keystroke seemed expensive for the cost/benefit at first, but then I realized, well, JavaScript is fast! CodeMirror (syntax highlighting), VisualEditor and the 2017 wikitext editor all observe every keystroke as well and contain considerably more hefty logic. The disambig notification feature does make an API request, but it's a cheap one and it only happens after you type a link. Community Tech doesn't have any further plans to add any keystroke-monitoring features. I am not sure about other teams/volunteers. But in my opinion, the keystroke listener bit by itself is nothing to be concerned about. MusikAnimal (WMF) (talk) 21:34, 30 January 2022 (UTC)

Adding to that, almost every textarea touched by javascript is likely to have keyup listeners for one reason or other. Even the basic editor without CodeMirror monitors keystrokes and sends an action=stashedit request with the entire text content – all of which sounds significantly more expensive (and non-opt-outable) than what Disambiguator does – which is to just check if the character you just entered is a ] (only then it checks if that ends a wikilink, before sending an API call). CodeMirror on the other hand has to literally re-balance parse trees. SD0001 (talk) 04:16, 31 January 2022 (UTC)

Totally seconding that! I do a bit of dab-related work and I make intentional links to dab pages all the time – in hatnotes, on other dab pages, in discussions, when creating redirects... it's supremely annoying to have this thing pop up every single time.

There should be a way for people to turn that off that doesn't involve figuring out what this unnamed feature is, tracking down its page on Meta and then browsing through the talk archives to get a piece of code that could do the job after some fiddling. Couldn't we turn that off for the whole enwiki? This is a useful feature for many of the smaller projects, because they don't have other means of tracking down or fixing dablinks, but I doubt this is needed on the English Wikipedia. If you insert a dablink there and you ignore the pop-up, then you'll soon receive a talk message by a bot notifying you of that, and unless you then fix the link by the end of the day it will end up in the reports at DPL, whose hyperactive editors will have fixed it by the time you get the message. That's too much redundancy for something that's not crucial to the project. How about using all this machinery for something that matters a little bit more, like additions of unsourced text? Uanfala (talk) 14:32, 9 April 2022 (UTC)