The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas. Before creating a new section, note:
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.
Before commenting, note:
This page is not for consensuspolling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
Discussions are automatically archived after remaining inactive for two weeks.
Some of the recent discussion on AN/I regarding Fastily and U5 closures centered on the challenges of properly addressing misuse of user pages. I believe the high volume of apparent misuse is causing difficulty in balancing protecting Wikipedia and taking due care in deletions. Anything that would reduce misuse (or reduce the consequences of misuse) should help relieve some of the pressure.
Thus my half-baked proposal below. The goal of this proposal is to reduce the attractiveness of putting up fake Wikipedia pages and holding yourself out to the world as having a page about you.
Proposal
The primary user page will automatically have the output of {{User page}} displayed at the top. Once a user becomes extended confirmed, they will have the ability to suppress display of the template. Extended confirmed users who abuse this by making an inappropriate user page can have the right to suppress display taken away by an admin. When first enacting this change, all current extended confirmed users will have the display suppressed, though they can enable the display if desired.
This is a Wikipediauser page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab).
Above is the output of the template, for those unfamiliar with it.
That could be a good idea. For new users who might not know it, a message could also be added to inform them that drafts should ideally not be written on their main userpage, with a link to automatically move it to their user sandbox. Chaotic Enby (talk · contribs) 20:16, 5 November 2024 (UTC)[reply]
I don't have any objection to this in principle. I think the application of this is likely to get pretty hairy, though. And I think most people write promo drafts on their userpage because they don't know they're promo and don't know that's not the place for drafts - so I don't think this would really help. But if I woke up tomorrow and this was the status quo, I wouldn't be mad about it or anything. -- asilvering (talk) 20:35, 5 November 2024 (UTC)[reply]
After giving it more thought, one objection I can see is that enforcing a banner on people's userpages might not be well-received, especially since the target demographic (non-ECP editors) likely won't overlap much with the people who will take the decision. I agree with your explanation for why people write promo drafts on their userpage, and a way to gently inform them that that isn't the place might be better.Now that I think about it, we need an equivalent of U5 that isn't "speedy deletion" but "speedy move to sandbox" (with a message informing the user of what happened, of course). Now that would be helpful. Chaotic Enby (talk · contribs) 20:40, 5 November 2024 (UTC)[reply]
The main issues with user pages seem to be promotional drafts and non-Wikipedia uses (like fake election articles for alternate history forums). It's non merely an enwiki issue - while userspace pages aren't prominently visible, images uploaded for them are. It's a big problem for Commons to have spam and hoaxes mixed in with other images. I'm not sure there's actually a common problem with userspace pages being passed off as real articles; I don't object to this proposal, but I think other changes might be more effective. In particular, I would propose stricter rules and other changes for userspace, with the primary aim of reducing incorrect userspace usage to reduce admin work:
Edit filters disallowing commonly misused elements like external links, images, and infoboxes for new users in userspace. This would essentially kill userspace for fake articles and make promotional userpages less attractive. Maybe even have a fairly strict character limit for new users - that would allow them to have a bluelinked user page introducing themselves, but not enough space for their CV or fake article.
Prominent edit notices for userspace explaining restrictions and directing users to draftspace
Disable the "upload file" link in userspace. The vast, vast majority of crosswiki uploads from userspace are junk.
Better bot patrolling of userspace. This could include creating lists of new userspace pages for easier patrolling, or even automatic moves of likely drafts to draftspace.
Partial blocks from userspace for those who misuse it. This should be more akin in seriousness to an edit filter than a mainspace block.
Formally expand U5 to include any clearly non-Wikipedia usage, regardless of whether the user has mainspace edits, after other interventions reduce userspace usage overall. Obvious junk shouldn't have to go to MfD just because the creator has mainspace edits.
As to passing off user pages as Wikipedia articles, I have encountered it once in real life, and everyone in that conversation was convinced it was real until I started reading the URL more carefully. Admittedly, this was a while ago, and perhaps people are more sophisticated now, but I suspect it is still a bit of an issue, and one that would be easily stomped out with this change. — rsjaffe🗣️22:21, 5 November 2024 (UTC)[reply]
I do agree that there's lots more things that should/could be done and appreciate your list. Perhaps the discussants here could put together a package of changes to improve the situation, though approval of each one would be independent, as some items in the package may be more of an issue than others. — rsjaffe🗣️22:23, 5 November 2024 (UTC)[reply]
I particularly like the edit filter preventing links idea. A plaintext page without through links is (generally) essentially harmless. I don't like the idea of a character limit unless it could be just applied to the top-level user page, rather than subpages which can legitimately be used for draft development. Espresso Addict (talk) 06:35, 6 November 2024 (UTC)[reply]
This is mostly in response to the first point. When creating a new article in mainspace, the little popup on the side always invites me to create the article in my userspace instead. Help:Your first article#Where to start writing also recommends placing drafts in a user subpage. I could very easily see a new editor not understanding the difference between their main userpage and a user subpage. If we block things such as infoboxes, external links, or set word limits, we will be sending a very mixed message to new users. Maybe an edit filter to block new editors from adding external links to commercial/social media sites? (LinkedIn, YouTube, blogspot, what have you). There's very valid reasons why we don't block these types of links in general, but if we're thinking about userspace spam from non-contributors, then maybe? Lots of good faith users do end up adding links to these sorts of websites, but I also think discouraging them from doing that until they've been around long enough to learn the intricacies of WP:SPS isn't a bad idea. I don't really know edit filters, however, so I have no idea how practical this would be. I also don't have enough data to throw myself behind this suggestion just yet.
Not a fan of expanding u5. But maybe, for abandoned SPAs with a spammy vibe, a process similar to PROD? A user tags something as obviously unencyclopedic, and the creator has a month or so to return to their account and contest it, or else an admin reads the userpage, confirms it's never likely to be useful, and either a)declines the tag (so it can never be tagged again) or b) bins it on the understanding that should the creator return, they can request undeletion. MfD doesn't get clogged up with long-abandoned quasi-spam, and it limits the risk of biting newer contributors since it wouldn't work on them. This won't do anything for active spam-like users, but neither does U5, seeing as they can just re-create the page as many times as they'd like before getting inevitably blocked. (And then we go back to userspace prod). There's probably flaws with this idea. I could absolutely see somebody trying to abuse it in the way U5 is abused. The most obvious way is if two editors get into a dispute, one of them is blocked, and the other tries to delete their userspace now that their "enemy" is gone. I like to think that would be noticeable, however. Also, admins would still be required, and thus required to read the pages before deleting them. If the admin fails to do so, that would be very bad.
I like the idea of removing the "upload file" link in userspace. I also think we should remove it in draftspace. I also think we should make the "upload to commons!" link less prominent. A few gours ago, I nearly accidentally uploaded a non-free book file to commons; it was only once I got to the second page when I realised I'd mistakenly clicked the giant blue box as opposed to the tiny grey one. If I'm doing that, then goodness knows what a new user who doesn't understand the difference between their own work and a screenshot is thinking. (And that's just talking about good-faith newbies who are still hunting for clues. Commons does not need anymore copyvio spam than it already puts up with.) This also would not stop users from adding images to their userspace. They would still have other ways. It would merely slow them down, force them to ask questions, and hopefully learn about copyright. GreenLipstickLesbian (talk) 09:46, 7 November 2024 (UTC)[reply]
This isn't a good template for this use. The header is harmless, but of the main text only the first sentence (to the effect of "this is not an encyclopedia article") is relevant. That sentence is needed, though, as well as a statement that this page hasn't been reviewed or quality-checked (even to the extent that normal Wikipedia articles are).Also, we don't need the option to let the page owner turn it off for everybody else, just a handy gadget to hide it for logged-in users who don't know to edit their own css. Without that, we could do this right now without the proposed software changes, which probably would never happen anyway. —Cryptic22:29, 5 November 2024 (UTC)[reply]
Oh, and I see no reason at all to limit it to the primary user page. I don't think I've seen anybody passing off a main user page in their "now read our article on Wikipedia!" link, but have to sandboxes and other subpages a couple times. —Cryptic22:34, 5 November 2024 (UTC)[reply]
Is there any way to get the software to display the namespace in User: and User talk: the way it shows up for every other namespace? Seems like that would be a step towards the goal here. Folly Mox (talk) 00:49, 6 November 2024 (UTC)[reply]
What is the onboarding (or whatever it's called) doing in the way of suggesting very new editors start user pages by the way? I did wonder if we were inadvertently inviting users to make a profile in their first or second edit, and then immediately deleting it U5 with unfriendly messages. Espresso Addict (talk) 06:59, 6 November 2024 (UTC)[reply]
Unless things have changed in the twelve months since I tested the new user signup flow, accounts are presented with a couple messages about Suggested Edits, then land at Special:Homepage. I don't remember there being (and definitely didn't screencap) anything related to creating a userpage. Folly Mox (talk) 11:19, 7 November 2024 (UTC)[reply]
It is, however, a pretty normal impulse to have, creating a userpage. Social media and various apps outright make you do it before being able to do anything else, and many newcomers will have been trained on that kind of behaviour. Also, if you're nervous, userspace edits feel safe, like you're not disturbing anybody while you're mucking around. -- asilvering (talk) 14:18, 7 November 2024 (UTC)[reply]
It's something that is encouraged in in-person training for new editors. A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink. Thryduulf (talk) 19:00, 7 November 2024 (UTC)[reply]
@Folly Mox, Asilvering, and Thryduulf: Thanks, Folly Mox. I think we need more advice on what the top-level user page may be used for, aimed both at new editors trying to create a profile and, perhaps more importantly, at patrollers. I've seen user pages that were entirely appropriate even for an editor with no other edits ("Hello world, my name is EA, I'm excited to edit Wikipedia!" sort of thing) being tagged G11/U5 by patrollers. (As far as I can tell, some patrollers think U5 is for anything created by a user with few non-userspace edits.) Asilvering writes, "if you're nervous, userspace edits feel safe", and I've found new patrollers think the same, it's a safe space to patrol without offending anyone who knows how to complain. And the flipside to Thrydulf's "A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink" is that patrollers are suspicious that a blue-linked user page is just the first step in a campaign of terror spam. Espresso Addict (talk) 23:09, 7 November 2024 (UTC)[reply]
Is there an editnotice for new users when they go to edit their userpage? I don't think there is. I don't see one when I try to edit mine, at any rate. -- asilvering (talk) 23:27, 7 November 2024 (UTC)[reply]
I'm getting the impression that some don't speak English at all and have used AI to draft something. Certainly that's true of promotional autobios submitted to draftspace in perfect American Marketing Speak, where I sometimes find it is impossible to communicate with the creator because they don't speak plain-old (British) English (and I don't speak their language). Espresso Addict (talk) 02:14, 8 November 2024 (UTC)[reply]
Having started some Wikipedia articles and added to others, I have the following questions and suggestions:
Why are there four different reference templates, when they all have roughly the same content?
Why does one template call it “Journal”, and another call it “Work”?
Why does there need to be a Page slot and a Pages slot? (printer drivers handle both together)
Should there not be one uniform format for all references when published? (see "Notes", David Graham Phillips: six different references, six different formats)
I suggest there be one reference template that has places for all necessary content, and that all references follow the same format when published:
Template
Title of source _________________ URL ___________________
Last name of source creator _________________ First name ________________________
News agency _____________________ Website name ___________________________
Name of journal, magazine, newspaper, etc. ___________________________ Volume _____ Issue _________ Page(s) ________
Name of publisher ________________________________ Location of publisher _________________________
Date source published __________________ Date source accessed____________________
Ref name ________________ Ref group __________________ Ref ID for anchor ___________________
There are quite a few more citation templates, it is just the four most commonly used that are available in the tool bar. All of the citation templates use the same set of fields, and you can build a citation from scratch using Template:Citation. The four citation formats available in the tool bar just start you with the fields most commonly used for each type of citation. You can leave fields empty, and you can add other fields as needed, as is needed when citing a chapter in a book, for instance. Donald Albury18:53, 7 November 2024 (UTC)[reply]
As a minor correction, not all of the CS1|2 templates support the same parameter set. For example, as of 2023, calling {{Cite book}} with the parameter |website= (or any of its aliases, like |work=, |journal=, |periodical=, |magazine=) will cause a template error, and add the article to Category:CS1 errors: periodical ignored (23,170).To address the substance of the OP, that there is any consistency among the most commonly used citation templates is the result of years of effort and discussion. The multiplicity of display formattings is a feature, not a drawback. There will never be just one single citation template, uniform in formatting across all sources and transclusions.Pbergerd, if you want the input fields in whatever editor you're using (not clear from tags in your contribs) to match the displayed format of those templates, that would best be addressed to whomever maintains your editing interface of choice (if anyone). The formatting will not be changed in the other direction (i.e. display matches input field ordering). Additionally, to my knowledge no citation template display leads with the title when the author is known, so I doubt you'll find consensus for your specific implementation proposal anywhere. All the best, Folly Mox (talk) 18:39, 9 November 2024 (UTC)[reply]
As a less gloomy follow up, our editing guideline WP:CITEVAR allows for articles to maintain the style used by the first major contributor or adopted by the consensus of editors already working on the page. So if you feel strongly about title-headed citations, you can implement your preferred formatting on articles you create, or unreferenced articles you provide the first citations for. But don't be surprised if bots come along and change it.With respect to your specific example David Graham Phillips § Notes: three two of the six citations – Fellow, Mencken, and Ravitz – are manually formatted (not the result of any citation template) and shouldn't be used as examples of a surfeit of citation formats. Two of the three four sources used in citation templates do not provide any authorial or editorial attribution (verified in sources), so naturally the format will differ from that of sources where the author is known.Tangentially, it is somewhat common for articles to use a mixture of Shortened footnotes and regular "defined in place" citations. Usually this is unintentional, as editors new to an article will almost never add citations in shortened format, except improperly, adding to Category:Harv and Sfn no-target errors (4,741). Converting all the new sources to shortened footnote form happens very irregularly. Sometimes articles will intentionally adopt a mixed style, where "main sources", multiply cited sources, or sources cited at more than one in-source location (a subset of the previous criterion) will be formatted in shortened form, and the remainder in the standard fashion. Folly Mox (talk) 19:22, 9 November 2024 (UTC)corrected per below 20:38, 10 November 2024 (UTC)[reply]
There are plenty of reasons not to use shortened footnote templates, and the lack of support for extra parameters is a feature (the footnotes, after all, are supposed to be short).I'm wondering why |access-date= in particular would ever be helpful to support: it's one of the cruftiest parameters, displaying rather a lot of text for information only really needed during archive snapshot hunting; it's not useful for print sources, which have a stable form per publication date, and are the most common types of sources where shortened footnotes are used; and why would you have different access dates for different sections of the source? Can't it just be added to the full citation template the shortened footnote links to?Quotes are another matter, but are easily included within the <ref>...</ref> tags following a harv family template like {{harvp}} or {{harvnb}}, which can be embedded within ref tags. Folly Mox (talk) 15:51, 10 November 2024 (UTC)[reply]
The attributes I mentioned were just random examples, but, e.g., |sectionlink= certainly seems important, and lots of printed sources are also available as PDF. Placing detail as free text in <ref>{{harvnb}}...</ref> does not create the proper metadata, so while it might work for |quote= it does not for other attributes. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:40, 11 November 2024 (UTC)[reply]
I agree with the OP that it's silly to have lots of different templates for citations – {{cite book}}, {{cite journal}}, etc. But there is a generic template for this and it's {{citation}}.
I usually use {{citation}} so that if, for example, I'm citing the Times using a URL, I don't have to worry about whether it's a web site or a newspaper when it's obviously both.
The main problem nowadays is that the Visual Editor generates the more specific templates rather than the generic one. I usually switch to the text editor to correct it but that's a nuisance.
"The article cites more than one reliable source and is better developed in style, structure, and quality than Start-Class, but it fails one or more of the criteria for B-Class. It may have some gaps or missing elements, or need editing for clarity, balance, or flow."
The heuristic for C-class is "substantial but is still missing important content". The heuristic for Start-class is, similarly "developing but still quite incomplete": not very different. As an alternative, you can try to determine whether the article is "Useful to a casual reader, but would not provide a complete picture for even a moderately detailed study" or "Provides some meaningful content, but most readers will need more."
And here's the military history version of C-class:
"The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.
Here, rather than having to make a difficult heuristic judgement between C-class and start-class, clear criteria determine whether an article is start-class and other clear criteria determine whether it is C-class. It seems to me to be a reasonable formalization of the two heuristics (referencing and completeness) used to determine C versus Start class anyways. I think if Wikipedia adopted this generally, it would make rating articles much faster and simpler and less confusing given that the criteria for distinguishing C-class articles are formalized rather than subject to essentially how complete the article feels. When I rate articles, I usually spend a good bit of time worrying about whether it is C-class or Start-class -- a major part of the decision making currently is informed by observing other people's decisions. WP:MILHIST has basically solved that and added a FAQ.
Has anybody ever proposed using the MILHIST criteria before? I do remember seeing proposals (not successful) to merge C and Start class, but not this specifically. Mrfoogles (talk) 08:55, 11 November 2024 (UTC)[reply]
Making the assessment process any more formalized than it is is a non-starter when we have hundreds of thousands of articles that aren't assessed at all. PARAKANYAA (talk) 15:32, 12 November 2024 (UTC)[reply]
My experience is that any article ratings other than those which are part of a formal process (i.e. all those except GA, A, and FA) tend to be assigned based on vibes rather than any strict concern with the criteria, and mostly are not updated when the article changes. If assessments are largely made without reference to the criteria, I'm not sure that changing the criteria will have much effect. Even assuming for the sake of argument that people are carefully rating articles based on the assessment criteria, ratings are updated so infrequently that there's no guarantee that they are still appropriate at any given time. I don't object to clearer criteria for what is a start/C/B class article, but I also don't know that I really see the point: at this point in Wikipedia's development, what if anything do people actually use these ratings for? Generally I agree with the view which has been expressed by various people in the past (I know Iridescent used to make this point, as in this thread) that the distinctions between start/C/B class are pretty pointless and we'd be just as well off scrapping them entirely and ending up with a scale which goes stub/standard/good/featured or even unassessed/good/featured. (You mention proposals to merge start- and C-class, but I cannot find them in the archives of Wikipedia talk:Content assessment or WP:VP) Caeciliusinhorto-public (talk) 12:58, 13 November 2024 (UTC)[reply]
I'd pretty much agree with this, adding that in my experience most ratings are assigned almost entirely on article length, and also that nearly all our readers and most of our editors never look at them. Johnbod (talk) 13:37, 13 November 2024 (UTC)[reply]
They are pointless, generally speaking, other than that it's nice to say you've improved the quality of X article to Y, which can be a nice achievement. You might be right than eliminating the distinctions might be a good idea -- stub/start/C are very difficult to distinguish meaningfully, and checking that everything is cited correctly in B requires a mini-GA review level of work for long articles. Mrfoogles (talk) 02:58, 14 November 2024 (UTC)[reply]
Given the reception, probably not going to propose this. What the system really needs is a reform based on determining what purposes it actually serves. Mrfoogles (talk) 02:59, 14 November 2024 (UTC)[reply]
The rating system was created by, belongs to, and primarily benefits the Wikipedia:Version 1.0 Editorial Team. This group is still active, even though they do most of their work via specialized off-wiki tools these days (so don't be fooled if you look at the page history and don't see any recent edits; that's not where the action is). AFAICT it serves their purpose (i.e., selecting articles for offline distribution based on a multi-factor calculation that reflects centrality [most internal links work], popularity [students want to read it], and quality [via ratings]) well. WhatamIdoing (talk) 20:57, 17 November 2024 (UTC)[reply]
My impression is that the ratings are associated with the projects such as Milhist but the project templates seem to be placed in an indiscriminate and rote way.
It would be good to rationalise the ratings in a functional way. For example, what I notice is that DYK and ITN perform their own independent quality assessments without regard to the project assessments. The {{article history}} attempts to pull all these things together but is only used on 50,000 pages. There ought to be a standard talk page template to unify these things.
One of the edits I most often do is to use author link to wiklink names in citations, including in citations that use templates like Template:Cite book. This works great if the author already has an article in English Wikipedia.
Unfortunately, when the author only has an article about him in some other language, this cannot be taken advantage of. Interlanguage links do not work in cite templates. I think Wikipedia does not allow one set of braces or curly brackets {{}} to be inside another set {{}}; in other words does not permit nested layers of templates.
Proposal
I propose that Wikipedia, via some way (whether or not that means allowing nested layers of curly-bracketed templates), enable interlanguage links in citations that use cite templates.
Eberhard Straub (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
The wiki markup for the citation reads:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
To make the author's name in the citation be a wikilink to his article, one would insert a new field in the citation like this:
|author-link=Eberhard Straub
but that would create a red link in English Wikipedia, because Eberhard Straub does not currently have an article in English Wikipedia.
However, he does in German Wikipedia, making it preferable for such a link to be an interlanguage link, thus empowering readers who want to know more about the cited author to at least be able to look at the article about him in German, and also inviting readers to be editors and create a new English-language article about him. If and when that English-language article is posted, then the red link to his name and the smaller bracketed blue link to the German article disappear from view and the link appears to readers to be an ordinary blue link to the new English language article.
How?
I don't know how to accomplish this.
I don't know if it's technically feasible to change the Wiki software to allow for a nested layer of curly-bracketed template to be used within another curly-bracketed template, using the already-existing author-link field, like this:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|author-link={{interlanguage link|Eberhard Straub|de}}|year= 2011|pages=17|publisher=Klett-Cotta}}
Or if a new interlanguage author-link field in the citation template needs to be created instead, like
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|ill-author-link-de=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
just put :de:Eberhard StraubEberhard Straub[in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.The real reason it didn't work is because the template already generated a [[]], so the parameter tries to linkify a link and render "[[[[:de:Eberhard Straub]]]]], causing it to fail. You can nest templates easily.
Doe, John (1 April 2020). [I witnessed Tom Hanks admitting to actually being born one year earlier, faking his age to enlist in the scouts] (Dream). Lucid. Recurring Tom Hanks scouts dream number 8. Doe's bedroom, 412 Example Street, Suburbiaville, London: REM stage R.
Thanks for your feedback, but the main problem with your suggestion is that it doesn't work with author links, which can draw from separately provided surnames and given names, and then display the results as surname first, then comma, then given name, hyperlinking to the article about the author. I didn't mention this in my original comment for reasons of space and focus.
In other words, what I really want to be able to do is to do something like
{{cite book|title=Eine kleine Geschichte Preußens|author-first=Eberhard author-last=Straub |ill-author-link-de=Eberhard Straub|year= 2011|pages=17|ill-publisher-de=Klett-Cotta}}
If you want to suggest something to do with with the citation templates I suggest you post it to Help talk:Citation Style 1. This, and similar ideas, have been discussed before. The solution is to use: {{cite book |title=Eine kleine Geschichte Preußens |author-first=Eberhard |author-last=Straub |author-link=:de:Eberhard Straub |year= 2011 |pages=17 |publisher=[[:de:Klett-Cotta|Klett-Cotta]]}} which produces: Straub, Eberhard[in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
Disclosure: I hate {{ill}} since it breaks title display in non-ASCII scripts on Firefox; i.e. you have to click through and load the sister Wikipedia page just to retrieve the title instead of a bunch of percent escaped garbage numbers for unicode codepoints. Folly Mox (talk) 14:08, 14 November 2024 (UTC)[reply]
In principle, one could set up a disambiguation page (thereby allowing for multiple languages) for the target and use {{interlanguage link}} on the disambiguation page. Of course, there may be a mild "surprise" for the user, but there can be sufficient explanatory text on the disambiguation page to explain the situation.
A side-effect of this (unless there's some provision to suppress this behavior), is that the page will be recognized as a valid "local wiki" page for other purposes as well, but IMO, that's not necessarily a bad thing ... and we can always include a qualifier in the title of the disambiguation page to help address that concern. Also, this is a little more work, but I think it's an improvement over the current practice of not providing the link. Fabrickator (talk) 15:26, 14 November 2024 (UTC)[reply]
Another option would be to create a stub/start article, link it to wikidata to get the language links, and tag it with the relevant "Expand language" template EdwardUK (talk) 17:49, 14 November 2024 (UTC)[reply]
I'm not sure a bunch of transwiki dabpages or nearly content-free stubs are the solution to this unproblem. {{ill}} formatting aside, what's wrong with linking an article on a sister project? We do it with Wikisource, Wiktionary, and Wikidata all the time. Folly Mox (talk) 21:44, 14 November 2024 (UTC)[reply]
In the context of citations, the actual target is only visible when you mouse over it (assuming the user bothers to examine the link preview), so it will typically be a surprise when a non-English page is displayed. Also, the general intent is to let the user select their preferred language, if multiple languages are available. (Of course, there will be a list of all available languages when you go to any language version of the article.) As a fairly minor point, the existing use of {{ill}} provides for the replacement of {{ill}} when a local link becomes available. Fabrickator (talk) 02:16, 15 November 2024 (UTC)[reply]
Hi. Before i joined Wikipedia, i always wanted a way to save my favorite articles somehow. When i logged in, i was excited to see a star button on a article (which signaled it was a sort of a favorite button) but to my disappointment it just made articles go on the watchlist. So what if there was a way to save certain articles to, say, read later or gather a collection for a school assignment. This would be very useful to both logged-out and in users. This could mean good for Wikipedia editing too! If you favorite a article, there should be a way to easily come back too it. This would make more efficient editing, rather then a confusing “watch list” of articles. Another way to implete this idea is to add it to a group, where you can come back to later. But either way, there should be a way to save articles to a dedicated area, logged in or not. Edit: I apologize if this is the wrong area,i couldn’t quite figure out if i should out this in Proposals or here.K.O.518 (talk) 06:49, 15 November 2024 (UTC)[reply]
Note that the “View and edit watchlist” tab of the watchlist has a list of all your watched articles in alphabetic order, which could be used as a favourites list. novovtalkedits10:44, 15 November 2024 (UTC)[reply]
It's been nearly two years since I brought this up here, but I've done some more work on articles about years since then and could use more feedback. I've just finished working on 2002. To ensure WP:WEIGHT/WP:PROPORTION, the information in the body of the article is based on sources that cover the year as a whole, such as Britannica Book of the Year and The Annual Register as well as more subject-specific sources. The timeline then reflects what's in the body, with sources like newspapers to verify the specific dates. I want to get more opinions to see if this is a good approach for other year articles going forward and whether there are any other ideas that should be considered. Thebiguglyalien (talk) 00:30, 17 November 2024 (UTC)[reply]
I’ve often noticed confusion on the part of both general readers and editors about what Wikipedia articles are AND aren’t. Truth be told, I suspect all of us editors probably had it not only before becoming editors but also well into our Wiki work.
So I got thinking that perhaps a cute (but not overly so!) little information box that would fly in or otherwise attract attention upon accessing a new article could help halt some common misunderstandings or lack of awareness of general readers. Because I think most editors here at the Pump would be aware of many such examples, I hope you’ll forgive my not providing e.g.’s.
(Of course if such an info box were put in place, there’d also need to be a way for readers not to see it again if they so wish.)
I started to check elsewhere at the Pump to see if a similar idea had ever been submitted before, but I couldn’t figure out a relevant search term. And I didn’t want to suggest an outright proposal if anything similar had in fact ever been proposed. So IDEA LAB just seemed a good place to start the ball rolling. Looking forward to seeing where it leads. Augnablik (talk) 10:58, 17 November 2024 (UTC)[reply]
I'm a strong supporter of providing more information about how Wikipedia works for readers, especially if it helps them get more comfortable with the idea of editing. Readers are editors and editors are readers—this line should be intentionally blurred. I don't know if a pop up or anything similar to that is the right way to go, but I do think there's something worth considering here. One thing I've floated before was an information panel featured prominently on the main page that briefly explains how every reader is an editor and gives some basic resources. Thebiguglyalien (talk) 17:49, 17 November 2024 (UTC)[reply]
The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)[reply]
The main page gets 4 to 5 million page views each day. And even so, I would guess that people who go out of their way to read the main page are better candidates to become frequent editors than people who treat Wikipedia like it's part of Google. Thebiguglyalien (talk) 15:12, 18 November 2024 (UTC)[reply]
I wasn't thinking of the main page. What I had in mind was that whenever someone requests to go to an article — irrespective of how he or she entered Wikipedia — the information box would fly in or otherwise appear. Augnablik (talk) 17:30, 18 November 2024 (UTC)[reply]
@Khajidha, i don't see the box as ONLY to dispel confusion but ALSO to point out some strengths of Wikipedia that probably readers wouldn't have been aware of.
A few things that came to my mind: although Wikipedia is now one of the world's most consulted information sources, articles should be considered works in progress because ... however, there are stringent requirements for articles to be published, including the use of strong sources to back up information and seasoned editors to eagle-eye them; writing that is objective and transparent about any connection between writers and subjects of articles ... and (this last could be controversial but I think it would be helpful for readers in academia) although not all universities and academic circles accept Wiki articles as references, they can serve as excellent pointers toward other sources.
if the idea of presenting an information box including the above (and more) is adopted, a project team could work on exactly what it would say and look like. Augnablik (talk) 18:58, 18 November 2024 (UTC)[reply]
I think that considerably overstates reality (the requirements are not stringent, sources do not have to be strong, many things are not checked by anyone, much less by seasoned editors, hiding COIs is moderately common...).
Ooops. Well, if stringent requirements, etc., overstate reality, then official Wiki guidance and many Teahouse discussions are needlessly scaring many a fledgling editor! 😱 Augnablik (talk) 19:40, 18 November 2024 (UTC)[reply]
All of these points also fall into the "well, DUH!" category. I did, however, want to respond to your statement that "not all universities and academic circles accept Wiki articles as references". I would be very surprised if any university or serious academic project would accept Wikipedia as a reference. Tertiary sources like encyclopedias have always been considered inappropriate at that level, as far as I know. --User:Khajidha (talk) (contributions) 19:38, 18 November 2024 (UTC)[reply]
Point taken about encyclopedias being generally unacceptable in academic writing.
But as we’re having this discussion in an idea lab, this is the perfect place to toss the ball back to you, Khajidha, and ask how you would describe Wikipedia for new readers so they know how it can be advantageous and how it can’t?
As I see it, that sort of information is a real need for those who consult Wikipedia — just as customers appreciate quick summaries or reviews of products they’re considering purchasing — to get a better handle on “what’s in it for me.” Augnablik (talk) 20:05, 18 November 2024 (UTC)[reply]
I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)[reply]
I would happily pay 25 cents per query if Wikipedia had its own AI chat interface. I use the Co-Star app (astrology) in this way already. I find the cost is worth the value. Free AI summaries available in search engines suffer from having too much garbage input (aka, the unrestrained data of the internet) to produce viable output. I would find it useful to have an AI interface built into Wikipedia. I already trust the information here and all "training data" for the hypothetical bot would effectively be open source. I would trust an AI bot managed by Wikipedia much more than I would trust an AI bot managed by any other entity. And I would be willing to pay for the service more often than I would be able to continue supporting the site through donation. 2603:6080:9F00:B05D:6205:4DF2:8C83:4343 (talk) 22:14, 18 November 2024 (UTC)[reply]
Well, Wikipedia is free and open-source, so we won't be implementing a paid AI chatbot on principle. Regarding the idea of an AI chatbot in general, they are often prone to hallucinations and not necessarily as accurate as they are confident. And they can't be edited by individual users in case they were trained on factual errors, which again goes against Wikipedia's principles. Chaotic Enby (talk · contribs) 22:22, 18 November 2024 (UTC)[reply]
New users, lack of citation on significant expansion popup confirmation before publishing
There are many edits often made where a large amount of information is added without citations. For new users, wouldn't it be good if it was detected when they go to publish an edit lacking citations with a large amount of text, and came up with a popup of some sort directing them to WP:NOR, and asking them to confirm if they wish to make the edit? I think you should be able to then turn it off easily (as in ticking don't remind me again within the popup), but my impression is that many make edits without being familiar with the concept of rules such as WP:NOR. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 01:36, 19 November 2024 (UTC)[reply]
If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)[reply]
@Aaron Liu, Edit check is available on the visual editor. Having it on wikitext won't make sense as the goal is to teach users to add citations, not to teach them both about citations and wikitext. Let's reduce complexity. :)
And the visual editor is still not the default editor at de.wp or en.wp. I advised to work on deploying both in parallel so that newcomers would have a better editing experience all at once (less wikitext, more guidance). Why am I not working on it now? Because it would take time. Now that the visual editor was used for years at all other wikis to make millions of edits, we should consider making it the default editor at English Wikipedia for new accounts. It could be a progressive deployment. I've not yet explored past reasons why English Wikipedia didn't wanted to have the visual editor being deployed, again for time reasons. But we would support any community initiative regarding VE deployment for sure.
We could deploy Edit check without VE, but I'm afraid of a low impact on newcomers: they are less likely to be helped as long as VE remains the second editor.
@Thryduulf, there were a discussion about Edit check in the past, you are correct. It covered multiple topics actually. I let you re-read it if you like; I didn't found "significant opposition" there, more questions about Edit Check, VE, citations and more, concerns on Edit Check and VE integration, and support for a better experience for newcomers (as long as it doesn't impact existing personal experiences).
If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)[reply]
Could you provide a couple of links to comments from people other than yourself, and which specifically opposed EditCheck (not the 'make the visual editor the default' or 'Citoid has some problems' sub-threads)? I just skimmed through the 81 comments from 19 editors in the proposal that Robertsky made, and while I might have missed something, your first comment, which was the 69th comment in the list, was the first one to oppose the idea of using software to recommend that new editors add more citations.
Most of the discussion is not about EditCheck or encouraging refs. Most of it is about whether first-time editors should be put straight into the visual editor vs asking them to choose. The responses there begin this way:
"I thought Visual Editor is already the default for new accounts and unregistered editors?" [1]
"In theory, this sounds like a great idea. I'm eager to try it out..." [2]
"I'd support making Visual Editor the default..." [3]
"I totally agree that VE should be the default for new users." [5]
which is mostly not about whether to use software to encourage newbies to add more citations (the second quotation is directly about EditCheck; not quoted are comments, including mine, about whether it's technically necessary to make the visual editor 'the default' before deploying EditCheck [answer: no]).
Then the thread shifts to @Chipmunkdavis wanting the citation templates to have "an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first", which is about how the English Wikipedia chooses to organize its CS1 templates, and @Thryduulf wanting automatic ref names that are "human-friendly" (to take the wording RoySmith used), both of which entirely unrelated to whether to use software to encourage new editors to add more citations.
I see some opposition to putting new editors into the visual editor, and I see lots of complaints about automated refs, but I don't see any opposition from anyone except you to EditCheck itself. Please provide a couple of examples, so I can see what I missed? WhatamIdoing (talk) 17:57, 19 November 2024 (UTC)[reply]
"which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)[reply]
VisualEditor is perfectly capable of accepting actual aliases such as |author=, and even non-existent parameters such as |fljstu249= if you want (though I believe the citation templates, unlike most templates, will emit error messages for unknown parameters). It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so. WhatamIdoing (talk) 05:12, 20 November 2024 (UTC)[reply]
If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)[reply]
If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement.
You missed that none of them tested it or checked it on other wikipedia versions, and that no support came along after I had tested it and posted my results? No surprise here... Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
There's a big gap between "The discussion stopped" and "There was significant opposition in this discussion".
In terms of EditCheck, I found most of the discussion to be off-topic, but I can honestly only find one editor (you) who opposed it in that discussion. I assume your failure to provide links to any other statement of opposition means you also honestly can't find a single comment in that discussion from anyone who agreed with you – just an absence of further comments, and an unprovable assumption on your part that its due to everyone agreeing with you. WhatamIdoing (talk) 19:28, 19 November 2024 (UTC)[reply]
Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)[reply]
I don't think I presented the discussion in the most WMF-favorable light. The discussion started off pretty enthusiastic, but it was mostly enthusiastic about something other than EditCheck itself. It then turned into a long digression into something completely unrelated.
(My own contributions to that discussion were technical in nature: It doesn't require the visual editor as the default; code may already exist for an unrelated change that someone wants; stats may already exist for something close to the numbers someone else wants.) WhatamIdoing (talk) 19:56, 19 November 2024 (UTC)[reply]
(ec) Fram, this is precisely because I reread the conversation that I wrote my previous message. We have the right to disagree, but it should remain civil and not convey accusations of bad faith. The way you try to depict me as a dishonest person is not acceptable at all.
I let other participants have a look at the previous discussion we linked, also take a look at the data we provided, and make their own opinion. We aren't the two people who will decide of a deployment here: I'm just the messenger, and you are not the person who has the final word on behalf of everyone. Trizek_(WMF) (talk) 18:00, 19 November 2024 (UTC)[reply]
Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
Since there are non-native English speakers in this discussion, I'd like to clarify that "dishonest", in English, means that the person deliberately told the opposite of the truth. For example, it is dishonest to say "I love Windows ME", when you actually hate it.
However:
Having incorrect or outdated information is not "dishonest".
Caring about a particular benefit more than a different problem is not "dishonest".
Disagreeing with you, or with a hypothetical average reasonable person, is not "dishonest".
There's a reason that English has an idiom about an "honest mistake": It's because it's possible to be factually wrong without being dishonest. For example, if you say "Oh, User:Example said something yesterday", but upon further inspection, it was a different user, or a different day. Or even if you say "The previous discussion shows significant opposition to EditCheck", but upon further inspection, nobody except you publicly opposed it. Such a sentence is only dishonest if the speaker believes, at the time of speaking, that the statement is factually wrong. Unless the speaker believes themselves to be speaking falsehoods, it's not actually dishonest; it's only a mistake or an error.
"Using someone's affiliations as an ad hominem means of dismissing or discrediting their views" – Claiming, or even implying, that WMF staff have a tendency to be dishonest is probably a violation of this point in the policy.
"Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done." – Claiming that anyone is "dishonest", especially when the difference between your view and theirs is a matter of opinion, is very likely a violation of this policy. It doesn't officially matter if the manner in which you say this is "you are dishonest" or "your replies are dishonest"; it's still insulting and disparaging another editor.
Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)[reply]
2013, not 2023. July was early days in VE testing, when I still thought you were helpful. A few months later I had become wiser. Fram (talk) 20:20, 19 November 2024 (UTC)[reply]
For what its worth, I do think a RfC can be made once the proposed details of the deployment is firmed up:
Do we make VE as the default for new editors?
Do we enable EditCheck as it is?
Current pop-up for new editorsAside, if we retain the current arrangement, i.e. letting new/anon editors selecting their preferred editor, can we change the buttons to be more balanced in colours and sizing? These do affect one's preference in choosing which button to click. – robertsky (talk) 18:16, 19 November 2024 (UTC)[reply]
robertsky, that's two RFCs, and – respectfully – conflating the two questions was a primary contributor to how far off the rails this conversation got last time.The UX alterations are probably best brought up at meta or mw for the skins devs to consider. Folly Mox (talk) 18:55, 19 November 2024 (UTC)[reply]
Gather was dropped after 3 months (without any "broken WMF promises" nor any time for them to have given such promises or to have acrimoniously debated), and Wikidata SDs seem to be deployed and working completely fine. Aaron Liu (talk) 18:25, 19 November 2024 (UTC)[reply]
Gather was deployed in March 2015 and immediately got severe backlash at the announcement: Wikipedia:Administrators' noticeboard/Archive270#Extension:Gather launching on beta. No good answers followed. So three weeks later we get Wikipedia:Administrators' noticeboard/Archive270#Moderation of Collections?, where we get (laughable) promises of what the WMF will do to solve some of the most basic problems of this tool they rolled out on enwiki but hadn't really thought about at all it seems. Instead, they created a new Flow page on enwiki for this tool (Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback) despite Flow being removed from enwiki long before this. So in January 2016 (hey, that's already 10 months, not 3), Wikipedia:Village pump (proposals)/Archive 130#Disabling Gather? was started. On 22 Januuary 2016, an answer was promised by the WMF "next week" (section "A WMF reply next week"): "by next week, the Gather team will have a major update to share about the feature". Things escalated, so another WMF person came along 6 days later to promise "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." (section "A Response from the WMF"). So instead of some great announcement after 1 week, we are now 6 days further and will get big news 2 weeks later... So, more than 2 weeks later, 12 February, we get "the analysis has taken longer than I anticipated. I'll post the results as soon as I can." So, on the 19th, they posted a "proposal" to which others replied "that proposal is an insult to the community." and "his smacks of yet more stalling tactics and an attempt to save face". Only when the RfC was closed with truly overwhelming supprt to disable it did they finally relent.
Do you really need a similar runthrough of Wikidata short descriptions, which are (or should be) disabled everywhere on enwiki and replaced by local descriptions instead? Or will you admit that perhaps you didn't remember details correctly? Fram (talk) 19:41, 19 November 2024 (UTC)[reply]
Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather. By no fault of its own, Shortdesc helper made me conflate WD descriptions and SDs. Aaron Liu (talk) 20:42, 19 November 2024 (UTC)[reply]
I never suggested deploying it on the source editor. Having not fully read the above discussion yet, it currently seems unreasonable that it's not deployed in the visual editor on enwiki and dewiki (while preserving the current "level of defaultness" of the visual editor itself instead of increasing the defaultness). Aaron Liu (talk) 16:30, 19 November 2024 (UTC)[reply]
@Aaron Liu, I never implied you suggested it, I was just one step ahead telling you that it is not available on source editor. :) We can deploy Edit check without changing the "level of defaultness" of the visual editor itself, but the impact might not be the same. Trizek_(WMF) (talk) 18:09, 19 November 2024 (UTC)[reply]
(ec) Probably Wikipedia:Village pump (proposals)/Archive_213#Deploying_Edit Check on this wiki. Having reread that thread, it combines all WMF rollout issues into one it seems, from starting with false requirements over a testing environment which isn't up-to-date at all to completely misreading everything that is said into something supposedly positive, ignoring the stuff that contradicts their "this must be pushed no matter what" view. But all in a very civil way, there's that I suppose... Fram (talk) 15:39, 19 November 2024 (UTC)[reply]
What an utterly weird objective for that tool "Newcomers and Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing to publish changes they are proud of and that experienced volunteers consider useful." Very neocolonial. Fram (talk) 15:25, 19 November 2024 (UTC)[reply]
Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)[reply]
I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)[reply]
Redone my check at Simple wiki, looking at the most recent edits which automatically triggered this tool[6]. 39 instances were automatically indicated as "declined", the other 11 contain 3 edits which don't add a reference anyway[7][8][9] and 6 edits which actually add a reference[10][11][12][13][14][15] (though 3 of these 6 are fandom, youtube and enwiki). And then there is this and this, which technically add a source as well I suppose... Still, 3 probably good ones, 3 probably good faith bad ones, 3 false positives, and 2 vandal ref additions. Amazingly, this is almost the exact same result as during the previous discussion[16]. Fram (talk) 16:21, 19 November 2024 (UTC)[reply]
I think just creating one good source addition is enough cause for deployment (without making VE the default editor), especially since it doesn't appear to be causing additional harm. Aaron Liu (talk) 16:59, 19 November 2024 (UTC)[reply]
If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)[reply]
I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)[reply]
What you observed (Editors who got a popup did not originally give a source when attempting to publish) is shown in the data we shared.
We already deployed checks to verify if a link added is not listed in rejection lists and make it more actionable by newcomers. Some users at other wikis expressed a need to have a list of accepted links (the ones that match RSP), but other said that it could prevent new good sources from being added. Thoughts?
Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)[reply]
I'm not sure to understand, sorry. Stats are about users adding a citation when asked compared from where not asked. It is not connected to RSP.
Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)[reply]
I don't trust WMF numbers at all
I'm new to all this, could you elaborate on why?
the 5 bad ones wouldn't have been included otherwise either
The 5 bad ones would have included no source at all if Edit Check wasn't there. I don't see how adding a blatantly terrible source is worse than adding text without a source at all. Both are checked the exact same way: eye-scanning. So there you go, net benefit and no harm. Aaron Liu (talk) 20:11, 19 November 2024 (UTC)[reply]
No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)[reply]
@Aaron Liu, I think this is a "reasonable people can disagree" thing. Some RecentChanges patrollers just revert any new unsourced claim, so if it's unsourced, it's quick to get out of the queue. Faster reverting means success to them, whereas encouraging people to add sources is like whispering a reminder to someone during a game of Mother, May I?: It removes an easy 'win' for the reverter.
OTOH, having a source attached to bad information has other advantages. It's easy to determine whether it's a copyvio if you have the source, and if you're looking at an article you know something about (e.g., your own watchlist rather than the flood in Special:RecentChanges), then having the source often means that you can evaluate it that much faster ("This is a superficially plausible claim, but I wouldn't trust that website if it said the Sun usually rises in the East").
For content that shouldn't be reverted, then IMO encouraging a source is always a good thing. For content that should be reverted, there are tradeoffs. WhatamIdoing (talk) 21:22, 19 November 2024 (UTC)[reply]
I miss things, especially on a workday. Sorry about that. I think the mobile short-descriptions thing is believable, as users . This is a case of the methodology being technically correct but misleading, which I don't see for the edit check study, unless you're willing to provide an argument.
an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious.
IMO, only slightly. Often, only users of experience patrol pages when reading them. (The unacquainted are also sometimes able to realize something's probably wrong with a swath of unsourced text, hence they make up part of the aforementioned "slightly".) And blatantly bad sources jump out to those experienced from the references section. Sources in the middle ground can often link to good sources, though there is a debate on how good it is to have both additionally middle-ground and bad sources vs. no sources at all. Personally, I think it's better. Aaron Liu (talk) 21:47, 19 November 2024 (UTC)[reply]
It would save time to have a true template but what would the word list be; y/Y/yes/Yes/YES n/N/no/No/NO t/T/true/True/TRUE f/F/false/False/FALSE? Anthony2106 (talk) 05:21, 19 November 2024 (UTC)[reply]
In templates like plot and AUD they have an option for "true" e.g {{AUD|10,000|link=yes}} putting "True" in place of "yes" does not work, so this functionality could be added into the AUD template or AUD could use a istrue template - a global template that has all the yeses and no's, so AUD would have a template in a template. This way each template that needed a yes/no could use this global template. Anthony2106 (talk) 07:32, 19 November 2024 (UTC)[reply]
You see, if someone edits Wikipedia and they are not signed in, their IP address is exposed. That means one could track where they live and dox them further. So yeah, don’t put the Ip adrees. But what if the person does an edit that ruins the page, or something bad? you see Wikipedia will have the ip address, and all what they have to do is report the anonymous person, Who will have a name, like not logged in or something, then Wikipedia will block it. Have a good day. Bye bye! Datawikiperson (talk) 09:46, 19 November 2024 (UTC)[reply]
IP addresses will give the location of the ISP node, or if the router has a location recorded with the ISP it will show that, most private routers do not show their location and will just show the ISP node. Try it yourself on a website like https://www.iplocation.net/. But you're right, sometimes it can that's true. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 18:12, 19 November 2024 (UTC)[reply]
While I'm not the most versed on that technical issue, one of the important points raised during Graham's RRfA was that admin tools were needed for him to do history merges and deal with more complex imports. Since Graham will no longer have these tools as an administrator, would there be a way to add these capabilities to the importer role? It could also help make the latter more accessible for non-admins potentially interested in helping out with this. Chaotic Enby (talk · contribs) 11:26, 20 November 2024 (UTC)[reply]
Yes, it would be possible. Need (a) a community discussion that supports adding the (mergehistory) permission to the import group, here on the English Wikipedia. Then (b) a configuration request can be made to add such. — xaosfluxTalk11:29, 20 November 2024 (UTC)[reply]
