The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".
"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.
I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]
We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
I think our motivation behind keeping it so aggressively-generic was that we weren't sure what places were using the "new section" form that this takes over, and we wanted to avoid something like "start a new discussion thread" as being too specific to only talk-page workflows. (The thing to watch out for is places outside the talk namespaces, that use __NEWSECTIONLINK__ to get that behavior...) DLynch (WMF) (talk) 17:12, 12 August 2024 (UTC)[reply]
Thryduulf, oops, looks like the URL contained NEWSECTIONLINK, which caused it to be parsed as the prop and not as a URL. I've edited it to add "deletethis" — follow the link and delete those words and then it'll work, or just use Anomie's better method below. Sdkbtalk02:20, 13 August 2024 (UTC)[reply]
I don't know how to use the API or run db queries, but the special page worked. I've not got time right now to look in detail, but that reports there are a lot more uses in non-talk namespaces than I expected:
Many of these are going to be appropriate (e.g. on this page, the portal page titles suggest they are nomination spaces) but I wonder especially about the articles. Thryduulf (talk) 02:17, 13 August 2024 (UTC)[reply]
I suspect the articles will turn out to be either vandals being weird or people not knowing what stuff does and throwing a bunch of magic words on the page trying to get Google to index a new article. Of the handful I spot-checked, I saw one that seems like the former and a bunch that seem like the latter. Anomie⚔02:36, 13 August 2024 (UTC)[reply]
There were 9 remaining in article space, all redirects. I have removed them, along with other code. It seems it was often added with other magic words in a group (eg.), so perhaps your second theory, although I wonder where the collection of magic words is found. CMD (talk) 20:49, 15 August 2024 (UTC)[reply]
This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkbtalk15:15, 8 August 2024 (UTC)[reply]
I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)[reply]
"Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss☎18:22, 9 August 2024 (UTC)[reply]
Thank you for the ping, @Sdkb. And thank you, @Belbury for prompting us to reconsider this message.
Generic enough to be helpful in the range of contexts it will ultimately appear
With the above in mind, what do you all think about starting with something a bit more specific like, Topic description and seeing if/how that proves effective? From there, we can consider whether further iteration is needed.
Meta: I feel moved to say: it's a delight to work on a project with folks like you all who consistently pay close attention to details of this sort in service of improving peoples' experiences contributing to our mission. Thank you to @NAyoub (WMF) for reminding the Editing Team of this point when discussing this offline earlier today ^ _ ^ PPelberg (WMF) (talk) 17:56, 15 August 2024 (UTC)[reply]
I like the idea, we can start with this! I still fear Topic description might still be a bit too abstract in a way, as it doesn't really indicate that the "description" corresponds to the message that will be posted on the page. Nonetheless, definitely an improvement over what we currently have. And yes, fully agree that details like this are much more important than people realize, happy to see the WMF team on board with this too! Chaotic Enby (talk · contribs) 18:03, 15 August 2024 (UTC)[reply]
I agree with ChaoticEnby about being too abstract. To me, "description" is meta; it's about something but isn't the thing itself. Your message or Your comment or even Your post are less confusing. Schazjmd(talk)18:17, 15 August 2024 (UTC)[reply]
I agree with Schazjmd that "description" is meta; it's about something but isn't the thing itself. - it's a better fit for the edit summary than the main substance. An exception might be if it was paired with "Title" but then I'd be expecting a third box in which to post the details. Thryduulf (talk) 18:34, 15 August 2024 (UTC)[reply]
Thanks for the response! The range of contexts where the message appears is definitely key to any decision here, so it would be good to establish for sure what that range is. The Special:Pageswithprop search above shows that the __NEWSECTIONLINK__ magic word (which causes the "Add topic" tab to appear, creating a Subject/Description box when clicked) is being used across various different types of non-talk page, which seem to break down into:
Pages of sequential, titled conversations which are effectively functioning as talk pages (like Wikipedia:SVG help, Help:Books/Feedback), where a string of "your comment/message" would still work.
There's also some unusual niche usage of the magic word to, I assume, create a handy shortcut for starting a new section on a log-type user page (User:Fabrickator/questionable edits).
Should the second and third cases be something to bear in mind when crafting a message, or can they be regarded as misuse of the __NEWSECTIONLINK__ magic word, and not something to worry about?
And are there any other places in Wikipedia where the discussiontools-replywidget-placeholder-newtopic "Description" string would appear, unrelated to __NEWSECTIONLINK__ magic word? Belbury (talk) 18:53, 15 August 2024 (UTC)[reply]
Those second/third cases are definitely the sort that we were concerned about when introducing the tool -- we thought that if we came in and took over the existing section=new behavior, we'd wind up stepping on the toes of people who had built up workflows around it (or at least, would be surprised by us auto-signing things). To that end we have a bunch of checks that determine when we actually take over from the old tool...
Summarizing here from the code that spells out whether following the ?section=new link on a page should open the new topic tool:
It must be an edit page (action=edit or veaction=edit) with section=new
It must either not be using any preloads (editintro, preload, etc) or have opted in via adding the `dtpreload` parameter to the URL
It mustn't be trying to preview / switch from some external tool via having posted a field named `wpTextbox1`
Then the new topic tool must be enabled for that page in general, meaning the URL has `dtenable=1` as a parameter OR
It's a wikitext content-model page (but not liquid threads)
It doesn't have the NOTALK or ARCHIVEDTALK magic words
It's in a namespage that wants signatures (any talk namespace, or $wgExtraSignatureNamespaces), or it has the NEWSECTIONLINK magic word
Finally, it must be available to the user, which is a combination of "turned on for that wiki" and the user actually having it turned on in preferences (Editing > Enable quick topic adding).
So! All that adds up to the challenging-to-search for part: pages in wants-signature namespaces that don't have NEWSECTIONLINK (we can probably assume that anything in an actual talk namespace is either really talk or won't be too offended if someone assumed it was), but which are somehow linking to the section=new tool as part of some on-page flow, perhaps even using the preload parameters so the user can fill out a form-template. Here on enwiki the extra signature namespaces are just Wikipedia (NS_PROJECT) and Help (NS_HELP) -- the question's much trickier if we were talking about some discussion/coordination focused wikis (mediawiki.org, metawiki, etc) which have their main namespace as an extra signature namespace.
For instance, if you follow this link to AfD with the right url parameters you'll get the new topic form, even though it doesn't have NEWSECTIONLINK. This is obviously not the way to interact with AfD specifically, but you can imagine some other process-page that does work this way...
That said, I think there's a fair extent to which "how should these process pages and magic words work?" is a community question. Our default message choices were kinda based around not wanting to cut off options / break existing processes, particularly since they had to fit more than just a single wiki, and I think (not having talked to Product about it) that we wouldn't want to drift too far away from that for the default... but a particular wiki wanting to tighten it up seems fine, so long as you're aware of the trade-offs. DLynch (WMF) (talk) 20:13, 15 August 2024 (UTC)[reply]
Yeah, separately from the question of exactly how talk-specific it should be, I agree that we might want to tweak the generic-default over to something a little more indicative of "this is the body-text of a message"... DLynch (WMF) (talk) 20:30, 15 August 2024 (UTC)[reply]
It will need a fine-toothed comb to find any "existing processes" that are deliberately using __NEWSECTIONLINK__ in a way that would conflict with a change to referring to the text as a "comment". But from a superficial look through the Wikipedia and User namespace usages (where the pages aren't structured as any kind of signed log or conversation), the existing processes that I can find do just appear to be using the magic word in error, for whatever reason - none of the pages appear to need or use their "Add a topic" tab to create new, sequential non-talk sections.
Making those already-non-standard pages a little more cryptic seems a very small trade-off for the benefit of every talk page on Wikipedia clearer to new users. Belbury (talk) 13:23, 23 August 2024 (UTC)[reply]
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
@Chipmunkdavis, if the community thinks that an intermediate step to trial out this among the newcomers who enable Visual Editor first is required, we should explore the idea. This may simply mean that window.MWVE_FORCE_EDIT_CHECK_ENABLED=true; or the query parameter should be set in MediaWiki:Common.js (and maybe MediaWiki:Mobile.js as well), of course with account restriction criteria being set to limit the force enablement to newcomers of <100 edits.
letuserEC=mw.config.values.wgUserEditCount// wgUserEditCount: null for anon editors and non null value for registered editorsif(userEC===null||(userEC!==null&&userEC<100){window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;}
I don't see how enabling edit check is an intermediate step, unless the plan is to later expand it to <500 or <1000 edits? CMD (talk) 03:42, 15 August 2024 (UTC)[reply]
It is intermediate step to see if Edit Check on enwiki does encourage an uplift in new/anon editors who are using VE adding content with references. Dependent on the result, we then can determine if it is beneficial to have VE to be the default editor with respect to Edit Check. – robertsky (talk) 05:30, 15 August 2024 (UTC)[reply]
@Robertsky: respectfully, I understand you've personally operationalized Edit Check deployment as involving making VE the default (which it may be recalled I thought was already the case), but these are two separate things. Linking them muddies the proposal and gives the impression of an agenda.I'd love for Edit Check to be enabled on this project, not necessarily for the initial check of adding a reference to a chunk of sufficiently long text (which sounds like a fuzzy test), but for all the stretch goals we could add to it for giving immediate feedback about identified categories of problem edits.Very little opposition should be expected if you disentangle all the Visual Editor stuff from this proposal, and if you wait until more kinds of checks are implemented – the kinds that save experienced editors from making the same kinds of corrections to newbie mistakes over and over – I think you'll see strong support for making Visual Editor the default when that separate question is revisited sometime down the line. Folly Mox (talk) 10:47, 16 August 2024 (UTC)[reply]
@Folly Mox you are mistaken that I am involved in the operationalizing of Edit Check with VE. I simply come across the feature and think that it is a good idea to have it enabled. Of course, there is also a strong desire to set VE as the default, but I am pragmatic. The immediate personal aim is to have Edit Check enabled and then we see if it is really beneficial for the English community. – robertsky (talk) 14:21, 16 August 2024 (UTC)[reply]
I must not know how to use the word operationalized correctly, which is actually something of a relief 🙃 I was trying to describe a comment of yours above where you explained the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Anyway, glad you're embracing the stepwise pragmatism. Should be an easy pass for the simpler "enable Edit Check" proposal. Often mistaken, Folly Mox (talk) 17:58, 16 August 2024 (UTC)[reply]
The likelihood that newcomers will include a reference the next time they add new content
And while we are confident that enabling the visual editor by default for people who are new will have a net positive impact on volunteers across experience levels, the idea @RoySmith, @FollyMox, and @Whatamidoing raised about decoupling the decisions to enable the Reference Check and VE for newcomers and people who are logged out seems wise. [i][ii]
Reason being: doing so, as I think @CMDput well, seems like a relatively lightweight and low-risk way for us to work together to:
Further, as @CMD, @Thryduulf, @RoySmith, @Novem Linguae, @Shushugah, @Folly Mox have mentioned [iv][v][vi][vii][viii][ix], it sounds like there are some facets of the reference experience that would be worth us talking together in more detail about.
The Link Check evaluates all external domains people attempt to link to against the globally-defined meta:Spam_blacklist and the locally defined, en:MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist lists.
The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
Zooming out, I think you all are in the best position to decide what you think the most effective deployment sequence here is. And please know: the Editing Team is ready to support you in what you decide.
Alright, I think this is a good place for me to pause.
Please ping me as new questions about Edit Check and/or VE emerge so that I, or another member of the Editing Team, can try to help.
In the meantime, we're going to continue following this conversation and will chime in when we think there is helpful information we can offer.
iii. We'll be able to filter Special:RecentChanges for edits made with Reference Check. You can see this in action at wikis like fr.wiki, es.wiki, and ar.wiki where Edit Check is already enabled.
x. Please boldly add tickets/issues as you see fit
xi. There is an open task the Editing Team will soon address to ensure each time the Link and Reference Reliability Checks are activated, a log entry is recorded in Special:Log/spamblacklistPPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)[reply]
@Robertsky, hi – would it be accurate for me to understand you as asking the following questions?
What steps would we (volunteers) need to take to activate the Reference Check at en.wiki?
How might we (volunteers) go about configuring the Reference Check? E.g. whose edits has the potential to activate Edit Check, where references are placed (before/after periods), the sections Reference Check should ignore edits to, etc.
Assuming the above are accurate, to activate reference check at en.wiki you all would need to:
Ask us to turn it on
Adjust the configuration on-wiki to reflect your preferences (e.g. example of frwiki’s ignoreSections)
And the Editing Team would need to then deploy a configuration-change patch to enable Reference Check on en.wiki.
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[1]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
@Fram You may see it as a false claim, but it may simply that for the end goal of Edit Check to encourage better content submissions among all anon and newly registered editors can be met by having VE be the default editor.
Your experience in testing out new tools certainly tempers one's expectations on the viability of tools on the platform. With respect to using AI to generated short description, I would also have similar reservations (my cautious approach to/use of AI is known), and still I have to say that it is an unfair comparison given that we are not expecting 91.3% of the new editors to give references. The A/B test in the impact report shows a more modest uplift of ~x2 inputs. Of course, further detailed analysis on a roll-out (in whatever form) on a trial basis can be made if we can tap on the existing tags (i.e. possible unreferenced addition to BLP) or edit filters or even sorting through the raw data.
With respect to the patchdemo wiki, maybe a more updated wiki mirrors better the current real world setup? The demo was generated back in June 2023, more than a year ago. I would have expected bugs and issues between then and now. Furthermore, it might be a patchdemo for limited use? i.e. to show partially the progress of the work? When testing directly on here in enwiki (until before publishing the edit), the reference are being added as a citation be it automatic or manual mode. – robertsky (talk) 19:05, 14 August 2024 (UTC)[reply]
If you insist that statements that VE must be made the default for this isn't a false claim, then I think we're done discussing this. And I see no reason to trust the WMF on any test results, considering that coincidentally just now they posted the results of that other software thing I mentioned above:
" By the time most of you provided feedback the experiment was already completed, and we already received support from some of your fellow experienced editors of English Wikipedia ". Yeah, right, like you posted in the "January update" which you posted in, er, August. And which is completely unverifiable, is based on a very small number of edits apparently by unknown "experienced" editors. They claim on that page that "If users that see the treatment do not select a suggestion more than 50% of the time after viewing the suggestions, we will not expand the feature". Let's see:
How often were Machine Suggestions Accepted, Modified or Rejected?
So why do they plan to continue with the feature anyway? Same as always, I guess, features aren't abandonded no matter how bad, no matter which promises were made, until after (usually) enwiki or dewiki find out how bad they really are, and even then only after an unnecessary, unwanted clash with WMF has been had and mutual distrust gets cemented for another 10 years. So yes, I don't trust WMF test results, I don't trust WMF promises, I don't trust WMF false claims and those defending them, and I don't support a rollout of such features without much better, verifiable (by us) testing or with added "requirements" which aren't needed but pushed by the WMF anyway. Fram (talk) 08:41, 16 August 2024 (UTC)[reply]
I don't support a rollout of such features without much better, verifiable (by us) testing sure. let's test Edit Check out, as what I have said in my previous replies to others. – robertsky (talk) 16:43, 16 August 2024 (UTC)[reply]
Let's test it by first providing us with a correct test environment. Sending editors to a test environment which doesn't reflect the actual environment is useless. Step 1: test if it is technically working. This should happen on a testwiki, not a live wiki. This is not an unnecessary step, there have been too many rollouts of supposedly ready new software addons which turned out to be very, very buggy and were not at the beta-stage but at some pre-alpha stage. Step 2: after approval from enwiki, do a limited test on enwiki completely reviewable by editors here, not a test where we just have to believe the results in good faith, and automatically shut down the test afterwards. Step 3: after approval, do a further rollout (larger test or full rollout). For this, we are not at step 1 yet. Fram (talk) 11:13, 19 August 2024 (UTC)[reply]
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
Heh, I just looked up the March 2022 discussion (which I had long since forgotten about) and discovered that I said almost exactly what I said here :-) RoySmith(talk)14:45, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Wikipedia already has loads of extra features that make it more enjoyable, most of which are dramaboards 😉 The true "extra feature" that makes Wikipedia so great is how lightweight and on-mission it is. Even on a bad connection, on a slow device with an old browser, I can navigate to a Wikipedia article, and it will load the whole thing for me to read (certain restrictions apply).I don't have to stop the page loading before stylesheets are applied because it can't reach an advertising partner, I don't have to leave the tab open two minutes and go do something else while my phone wearily executes javascript routines, I just open the page and read the page, like how the internet used to be before it became total capitalism garbage.Any extra interactive features added to the default experience reduce our availability and usability for people on the lower end of computing resource / network infrastructure privilege. It feels important to preserve that equity.So I guess my position is: no, Wikipedia isn't just an encyclopaedia— it's also an online community; but also no, Wikipedia isn't a general pedagogical resource— it's pretty much just an encyclopaedia with an active editing community. Folly Mox (talk) 13:27, 11 August 2024 (UTC)[reply]
For sure! I probably could have done a better job in selecting a qualifier than the term "general" in general pedagogical resource, or maybe should have chosen different words altogether. I was attempting to communicate my personal opinion on the OP's question on whether Wikipedia is just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site.Folly Mox (talk) 09:47, 13 August 2024 (UTC)[reply]
Sure, why not! It's an education website. This is something many loose track of, we are in the business of a non-profit education resource. The best way to do this is start a Project and run the quizzes in project space. Once it has a following and support, which might take years and press exposure, then consider something on the front page. -- GreenC20:37, 12 August 2024 (UTC)[reply]
Oppose - this is an encyclopedia, not Facebook or TikTok. We do not need to degrade ourselves by turning ourselves into a host for social media games. --Orange Mike | Talk20:58, 20 August 2024 (UTC)[reply]
Hi everyone, sorry for responding so late. I don't check Wikipedia as often as I used to. Unfortunately, I don't have all the time in the world to be dedicating to making the quizzes all by myself. I'd be open to suggesting ideas that will help make the quizzes better. I feel that if I had help with the quizzes rather than alone (not saying I won't contribute, but I don't to put a heavy load on my editing and my personal life), I think it would be helpful to increase the chances of it being a successful feature on the site. Interstellarity (talk) 22:50, 20 August 2024 (UTC)[reply]
It's not necessary for you to do all the work, if there are other interested contributors. As the one who seems most interested in the idea, though, you are a good candidate to co-ordinate the work, or even to just create some quizzes on whatever schedule is convenient for you to try to figure out what might be a sustainable way of working. isaacl (talk) 17:32, 21 August 2024 (UTC)[reply]
...and the best way to find out who could be involved is for you to start with a few questions. I'm sure you will get people saying "I wouldn't have asked that" so you can ask them what they would have asked instead, and the second quiz will already be written. Phil Bridger (talk) 19:23, 21 August 2024 (UTC)[reply]
I think you (and Mike) are being a bit bah-humbugish here. Of course this shouldn't be an official™ part of Wikipedia, but there's no reason why someone shouldn't ask a few questions in their user space if that's what floats their boat. It will probably fail anyway. Phil Bridger (talk) 19:24, 26 August 2024 (UTC)[reply]
The proposal was to put it on the main page, so it merits being discussed (and, in this case I guess, opposed) as a serious proposal, not assumed to be automatically relegated to a userspace project (which can be done without a village pump proposal). Honestly, having it on the main page or articles directly would be bloat, but I'm down for having quizzes on the Signpost, and it would definitely be fun! Chaotic Enby (talk · contribs) 19:54, 26 August 2024 (UTC)[reply]
To keep up with recent trend to keep relationships defined as per their choice, there are partnerships such as Civil Partnership, Platonic Relationships, or just Girlfriend and Boyfriend etc... please change spouse to partner or any culturally relevant term thar reflects the current state of preferences on bio pages of individuals. DhawanMohan13 (talk) 16:33, 18 August 2024 (UTC)[reply]
DhawanMohan13, why change "spouse" to "partner" in the majority of cases where it is correct? I am married. I have a wife (gender-neutral term "spouse") and she has a husband (gender-neutral term also "spouse"). Many people that I know have partners or boyfriends or girlfriends. We should describe everyone, incuding those who have a spouse, accurately. Phil Bridger (talk) 17:18, 18 August 2024 (UTC)[reply]
The definition of spouse is (written) your husband or wife, I doubt it acknowledges people who are in a relationship they dont want to label. For example just boyfriend girlfriend, civil partnership, etc... DhawanMohan13 (talk) 05:03, 19 August 2024 (UTC)[reply]
I think what Phil is saying is that if someone is married, there is no reason not to use the word 'spouse' accurately. Otherwise, 'partner' is fine. – Joe (talk) 05:06, 19 August 2024 (UTC)[reply]
Or is the concern in the opposite direction?
@DhawanMohan13, it's not clear which problem concerns you:
"Mrs. Married" is legally married, but you think we should write "her partner" instead of "her spouse", to sound current and trendy.
"Miss Girlfriend" is not married, but you have found a Wikipedia article that talks about "her spouse", when it ought to say "her partner" or "her boyfriend".
Of course the article about Miss Girlfriend should be corrected, but we should leave Mrs Married as is, unless we have sources saying that she prefers not to use the term. Phil Bridger (talk) 07:14, 19 August 2024 (UTC)[reply]
If there is no legally defined relationship, there is no reason to list the person. We don't list every girlfriend/boyfriend, we list people who are joined in a marriage or civil partnership. For those relationships the terms are "spouse" and "partner". --User:Khajidha (talk) (contributions) 14:54, 19 August 2024 (UTC)[reply]
Wikipedia follows; it does not lead. The onus is on you to show that any such "trend" has become predominant in reliable sources; you have not even attempted to do so. I fervently oppose cultural activism at Wikipedia (repeal the "mankind" ban until such time as the word is widely considered archaic, etc.). ―Mandruss☎19:53, 19 August 2024 (UTC)[reply]
The current dark blue color of hyperlinks in Wikipedia's Dark Mode can be difficult to read, especially for users with visual impairments. I propose changing the color of hyperlinks in Dark Mode to a brighter, more readable color, such as yellow.
This change would improve the overall usability and accessibility of Wikipedia for users who prefer Dark Mode. A brighter hyperlink color would provide sufficient contrast with the dark background, making it easier for users to navigate and read articles both on the website and the app.
Rationale:
Improved readability and accessibility for users with visual impairments
Enhanced user experience for Dark Mode users
Consistency with web accessibility guidelines, which recommend sufficient contrast between text and background colors
Implementation:
Change the color of hyperlinks in Dark Mode to a brighter color, such as yellow (#FFFF00)
Ensure the new color is consistent across all devices and browsers
Discussion:
I welcome feedback and discussion on this proposal. Please share your thoughts on the proposed change and suggest alternative solutions if you have any. Galilean-moons (talk) 14:53, 19 August 2024 (UTC)[reply]
If there is a standard colour for links in website dark modes we should use that (for the same reason we use blue as the standard link colour on light mode). I'm not a regular user of dark mode meaning I have little direct experience, so I looked for examples. Of about 20 websites with dark modes that were highlighted as good by various discussion forum contributors, only 3 were primarily text-based, had links of a different colour to the body text when not mousing over the link and had a dark mode that I could easily find and activate. Two of them used a pale blue (#3ebcf4 and #9eb1ff) and 1 used purple (#a667e4). A couple of git hub results were people commenting/complaining that yellow is not an intuitive colour for hyperlinks. Thryduulf (talk) 19:19, 19 August 2024 (UTC)[reply]
Further, it would probably be best if the color is set in same place where the light-mode link colors are set rather than us overriding them locally. That would likely be in the skin. Anomie⚔21:31, 19 August 2024 (UTC)[reply]
Light blue is good, although cyan could also be an option. It is visually brighter than blue at similar HSL lightness levels, while a light blue (higher lightness level, i.e. adding white) isn't visually as sharp, especially if we want to make it visually distinct from purple. Chaotic Enby (talk · contribs) 23:03, 20 August 2024 (UTC)[reply]
I use dark mode and am (slightly) vision impaired. The difficulty for me is less the blue hyperlinks and more the difference between blue and purple (non-visited/visited). Gnomingstuff (talk) 18:47, 20 August 2024 (UTC)[reply]
@Gnomingstuff Yeah, unfortunately I don't expect much improvement there, especially considering how many websites style away visited link coloring entirely, forcing them to the same color as unvisited links. (Something that will always earn them a UserStyle in my browser, restoring the difference, because WTH is it with site authors just deciding that a useful browser feature isn't necessary on their site?) So I guess we should be happy there's any color difference at all.
I know at least for the light-mode skin, in the last round of design updates not too long ago, the decision was made to slightly lighten the unvisited blue, and massively lighten the visited purple. The focus was on increasing their contrast relative to the black body text (for some reason), though I pointed out that it came at the cost of decreasing their contrast with the background color, particularly in infoboxes and other non-white sections of the page, but the whole contrast-with-unlinked-text thing was a big priority for some reason. It was an unfortunate additional side effect that the change also brought the two colors much closer to each other, but I suppose contrast in particular is always a balancing act. FeRDNYC (talk) 15:00, 23 August 2024 (UTC)[reply]
A new color might be useful, but yellow seems to me to be a pretty poor choice, as it's quite an aggressive color. I think another shade of blue would be optimal, as up to now people have made things with yellow backgrounds but not with blue ones, and yellow-on-yellow situations would violate MOS:CONTRAST. — Alien333 ( what I did why I did it wrong ) 20:20, 24 August 2024 (UTC)[reply]
@Alien333 I can see the point of yellow, in that it's the complementary color to blue in many color models, and yellow links inline with white text (remember, we're talking about dark mode here) wouldn't really be that "aggressive", I don't think. I'm not entirely sure how easy it would be to detect yellow links in white text, particularly for users with color-vision impairments. Though IIUC, both the yellow/white and yellow/blue pairings would be good choices because the difference would remain completely visible to those with the most common form, deuteranomaly ("red-green color blindness").
Also, just for the record, there are a ton of blue-background elements on Wikipedia, particularly in the article space — including all of the standard infobox, navbox, and table styles. (Heck, even the standard background for inline <code>...</code> elements used to be a subtle blue, though it seems it's been changed to a neutral gray.) Yellow may reign in Talk page headers, but blue is very common elsewhere.
The prevalence of blue backgrounds on article pages is why I tried to point out that lightening the blue link text in the light mode palette was an especially poor choice, because links often appear inside those boxes, and quickly become combinations that fail the WCAG's thresholds for text contrast against background color. In dark mode, those background colors either get erased entirely, become a shade of dark gray, or (least commonly) become a much darker blue, so it isn't as much of an issue there. FeRDNYC (talk) 21:18, 26 August 2024 (UTC)[reply]
After some CSS tinkering:
Actual yellow would be nearly invisible, and certainly not legible. Some kind of inverted yellow, such as this one, could do the trick, but as long as we're going to do that we might as well just take a cyan of the same level, like that one. Also this green, maybe. I'd prefer the cyan or green because that is more logically linked to the light blue of unvisited links. — Alien333 ( what I did why I did it wrong ) 22:57, 26 August 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello, I'm a new user and was wondering if we can have our username start with a small letter. Almost every website I use has my username as "brishtibheja" but only here it becomes "Brishtibheja". Brishtibheja (talk) 20:53, 20 August 2024 (UTC)[reply]
There are ways to make your username appear as brishtibheja in your signatures and on your user page and user talk page, etc. For help with that, I suggest WP:HD; it would be a misuse of this page. No proposal is in order. ―Mandruss☎21:04, 20 August 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Wondering why there are no articles on Sarbajeet Mohanty and Pooja Vijay? They have been a notable paranormal investigators for the last many years and are currently featuring on MTV India's Paranormal reality show, Dark Scroll as Paranormal Experts, streaming on a notable streaming platform Jio Cinema. Scareguy123 (talk) 19:32, 21 August 2024 (UTC)[reply]
I haven't looked at this particular case, but the usual reasons for a missing article are either that the subject is not notable or that they are notable but nobody has volunteered to write the article yet. The latter is particularly common for subjects based outside the Western Anglophone world. Phil Bridger (talk) 19:53, 21 August 2024 (UTC)[reply]
In the case of this ABC News, there are hundreds of articles with broken links, such as LGBT rights in Afghanistan.
It is even more common for it to omit a link to the "work", either displaying it in plain Wikitext or not at all. This excludes important contextual information, and goes against MOS:UL which says that proper names that are likely to be unfamiliar to readers, which would include news sources as few have global recognition, should be linked.
In the case of this ABC News, there are thousands of articles with missing links, such as Joel Reddy.
Following a discussion with Robertsky, I proposed a bot that would be able to rectify one or both of these issues, as well as add additional information to the citation template that can be determined from the URL or other content already in the template, such as the publisher or publication location.
To minimize impact on watchlists, it can be configured so that only some errors or omissions will trigger an edit, with the rest being done only if the article is already being edited.
I am raising this in the community now to determine whether the community believes that this task is worth completing.
In addition, the bot uses a configuration file that I would need the communities help to expand. Currently, it addresses issues with the following sources:
Please provide details for the other sources that you wish to see corrected by leaving a comment on the configuration talk page, or if you are sufficiently familiar with JSON to understand the configuration file by editing it directly. BilledMammal (talk) 09:02, 25 August 2024 (UTC)[reply]
Overall, I support more frequently linking publication names. For an article that doesn't use them, though, it should be kept consistent. Sdkbtalk22:41, 25 August 2024 (UTC)[reply]
I’ve already touched on this, with the above reference to WP:UL, but to address it in a little more depth in regards to consistency:
First, I don’t think we want to follow the pattern of the majority of the article, as in most cases they will be unlinked solely because RefToolbar doesn’t add links rather than because of any deliberate editor choice.
Second, a sufficiently expansive configuration file will be able to switch from unlinked majority to linked majority.
However, I would be able to alter the program to not include links under certain circumstances if that is what the community would prefer. BilledMammal (talk) 23:19, 25 August 2024 (UTC)[reply]
add additional information [...] such as the publisher or publication location. If that's done, it should be VERY selective, erring on the side of omission. Cites for The New York Times do NOT need to show that the publisher is A. G. Sulzberger or that the publication location is New York City. Et cetera. Bots should reduce work for human editors, not create work for them; we have too much of the latter already. ―Mandruss☎22:44, 25 August 2024 (UTC)[reply]
New York Times is actually a very convenient example, as it is already in the configuration file.
Not only will it not add the publisher or publisher location, it will actually remove them if it is already editing a page, in accordance with the specifications at {{cite news}}BilledMammal (talk) 23:09, 25 August 2024 (UTC)[reply]
People keep becoming confused because they think clicking "Publish" means "Move my changes to article space". But they should think that! – that IS what "Publish" must mean to any reasonable person in their situation, and there's no good reason for them to think it might have the meaning it currently does. "Publish" means to make something generally available and accessible, to put it on public display – it doesn't mean "commit changes to upstream server" (or whatever is actually happening), and it certainly can't mean that to the average person editing Wikipedia.
The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. TooManyFingers (talk) 17:09, 27 August 2024 (UTC)[reply]
I can see your point, but as far as editing Wikipedia goes, anything you 'publish' is both available and accessible by other people. Relabelling as 'save' could likewise be easily misunderstood. AndyTheGrump (talk) 17:17, 27 August 2024 (UTC)[reply]
Wikipedia's lawyers wanted the button changed to say "publish changes" to emphasize that all edits to any type of page are public. "Save" does not do that. 331dot (talk) 17:22, 27 August 2024 (UTC)[reply]
I think this is a case of 'fixing the wrong thing'. What is wrong is Drafts. It is an incomplete feature because it's just a public page in a public thing that isn't really 'public'. It could be fixed by making these particular cases "Publish draft" or something the like however, making every single control in MediaWiki super context specific is a bit difficult (it is designed on purpose to be a generic system after all). —TheDJ (talk • contribs) 19:00, 27 August 2024 (UTC)[reply]
Someone creating a draft has to grapple with several things...
Writing some text in their draft
Saving (which is published publicly; which means both legally it can be reused/edited/scrutinized)
Even with all that, they need to transclude {{subst:submit}} which is when it is really submitted for review...and still then it's not published in sense of being visible in Mainspace (not to be confused with Wikipedia namespace)
Every control being context specific, sure. But having the text for a few select UI elements being namespace-specific (or namespace-overridable) may not be the worst idea for a future WMF developer project. ― novov(tc)12:36, 28 August 2024 (UTC)[reply]
Just a general comment: even very common words do not mean the same thing to everybody. A change you think makes things clearer may make things more confusing for someone else. It's one of the areas where we have to find a rough consensus, using language that makes general sense to most users without leading too many astray. Discussions like this are how we figure it out. Donald Albury21:03, 27 August 2024 (UTC)[reply]
We're unlikely to find a word that can't be misinterpreted. "Save" is more ambiguous than "Publish", in my opinion. Perhaps "Commit". The absence of anything else that might mean "put this in the page" might be a clue. But, ultimately, any uncertainty lasts as long as it takes to try it and see what happens. Are we getting a lot of complaints from newbies who can't figure out what to do? If not, it's the proverbial solution in search of a problem. People keep becoming confused - Show me, please. Operative phrase is "a lot". A few is not enough. ―Mandruss☎23:07, 27 August 2024 (UTC)[reply]
But what you write is public, even in draft space. That's the whole thing. The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. Come on, that's an obvious strawman. The fact that the WMF already weighed on it, and that people gave it many thoughts before making this choice, should tell you there is probably a less dishonest reason for it. Chaotic Enby (talk · contribs) 23:09, 27 August 2024 (UTC)[reply]
We do cause confusion when we say (accurately) that every edit is 'published' but also use the verb 'publish' to refer to moving drafts to mainspace. But as others have said, the problem lies with the drafts, which is a poor choice of words to begin with (people don't usually publish 'drafts'). I've never heard or been able to come up with a better phrase, though. – Joe (talk) 08:39, 28 August 2024 (UTC)[reply]
@Joe Roe A simpler change would be to change verb for move from Draft to Article as "Promote" to indicate it's a positive thing, without touching the thorny legal/technical side of publish. It's celebratory and fits other descriptions of being declined/rejected. The namespace bit is an implementation detail. ~ 🦝 Shushugah (he/him • talk) 11:55, 28 August 2024 (UTC)[reply]
I think it important that editors understand that when they click the button, they are “publishing” whatever they have written. Where it is published does not matter. It may be published in Mainspace, in Draftspace, in Talkspace, in P&G space, etc. … but it is all a form of “publication”. Blueboar (talk) 12:16, 28 August 2024 (UTC)[reply]
Long story short, it's gonna stay "Publish" - lots and lots and lots of prior arguments about this were already made, and the WMF is going to enforce that. The OP thesis is that editors are confused when editing in draft space. We could add additional guidance to Template:Editnotices/Namespace/Draft - which appears in the edit window for all pages in the Draft namespace if there is special guidance needed. — xaosfluxTalk13:33, 28 August 2024 (UTC)[reply]