Wikipedia:Village pump (proposals)/Archive 184

According to the current tally, the number of articles with link rot issues slowly but steadily approaches the 300K mark. Even though that's less than 5% of the English Wikipedia and mostly we deal with articles that have most of the citations being all right, I believe that becomes quite a problem when we have articles referenced to a page which can't be found on any archive, and in particular favts referenced to that source. The info, in that case, might require update, deletion (based on

concerns) or simply we might need to change the link in the reference, none of which can be handled by bots alone. This is also an area which seems not to be particularly touched by Wikipedia editors in general, as this is simply routine maintenance of encyclopedia instead of badges/honors connected with the more pleasant parts.

Since this is my first post at Village Pump, please assure me this is the proper venue for that proposal (or else redirect me to another forum), and, of course, I'd like to hear your opinions on it. Szmenderowiecki (talk) 14:40, 3 September 2021 (UTC)

Thanks for the idea, Szmenderowiecki! This village pump is used for proposals like this all the time, so you're at the proper venue. Resolving link rot is certainly a plus, so anyone who helps resolve it is doing good. I wouldn't say it's our most urgent backlog, though, as it's less severe than {{Citation needed}} (dead references at least likely supported the material, even if they're no longer verifiable, whereas citation needed references mark totally unsupported material) and we're never going to get through the citation needed backlog without radically increasing the number of editors.

One thing I'm wondering is where the more recently tagged instances of link rot are coming from, as Internet Archive is theoretically supposed to be archiving every outgoing link from Wikipedia. Are they old links from before IA was doing that, or editors mistaking links as permanently dead when actually they're available through IA, or is IA failing to capture everything? {{u|Sdkb}} ^talk 18:55, 3 September 2021 (UTC)

Probably all those things. Systematic saving of links at Wayback and Archive.today wasn't done prior to about 2012. Current save methods are not 100% for a couple reasons. Some percentage of {{dead link}} tags are resolvable but a bot or person has not done so yet. IMO a bigger problem is false negatives ie. links that are dead but not marked or being saved by the bots due to soft-404s and other issues. The methods we are using are problematic. The solution is every link is born archived ie. the archive URL is part of the rendered page automatically, no bots. -- GreenC 19:37, 3 September 2021 (UTC)

It seems to be the former case (as a lot of these are from 2007-2012, which is why it is often hard to find them; some are apparently cited in 2013 and dead (for example here), while this article describes a 2015 Spanish film, and yet the official website is dead and the link rot tag is there.

as Internet Archive is theoretically supposed to be archiving every outgoing link from Wikipedia but it isn't doing so automatically. At least the references in this article stay unarchived for two months or so (though to be honest, IA bot has gone once or twice through the page when the heat wave was in the news).

IMO a bigger problem is false negatives ie. links that are dead but not marked or being saved by the bots due to soft-404s and other issues. I haven't really encountered that problem at the time I was doing that on a sample of some 20-30 articles; and anyway we can't recognise it until we actually get to the page and check both the URL and archive, which can only be done by a person.

As for "citation needed" backlog, this one is going to be way more difficult than dead links, because the latter will just involve checking the page against its archived versions (or copying the title), while in the former, we would actually have to find the information, which often is difficult and involves several languages. I mean, the anti-link rot drive is a quicker fix (though admittedly not so fundamental).

The solution is every link is born archived ie. the archive URL is part of the rendered page automatically, no bots. You mean that we should automatically send queries of whatever links we submit to Wikipedia to IA, and then added to the citations? Sounds pretty cool, but that's hell of a load on IA's servers. Szmenderowiecki (talk) 01:30, 4 September 2021 (UTC)

"Sending every link.. we submit to Wikipedia to IA" is what Internet Archive does see Wikipedia:Link_rot#Automatic_archiving. To give a sense of scale, Wikipedia has about 100-200 million unique URLs in about 500 sites; Wayback machine has archived over 107 billion web pages. The false negative problem is not anecdotal, it can be extrapolated based on a decent size data set. It's not a wild guess to suggest there are many more than 300k articles containing silent dead links. For an example of links born archived, see frwiki - not recommending that solution, but is an example of how things can be done differently. -- GreenC 18:58, 4 September 2021 (UTC)

That's all the more reasons to initiate such drive in this case. Szmenderowiecki (talk) 06:47, 5 September 2021 (UTC)

There are also some problems with internal link rot that are worth considering as well. We have redirects (some categorized by {{r to section}} and {{r to anchor}}) which point to particular sections of articles that no longer exist or changed their name. These take you to the article, but sometimes the proper section or information can be hard to find. — Wug·a·po·des​ 20:59, 7 September 2021 (UTC)

Requirement of 2 votes for template deletion. I understand most experienced editors avoid deletion talks like a plague ....but...Think we need a basic number of votes for template deletion. As of now we have many templates deleted by 1 vote...in many cases that 1 vote is by an editor here editing for only a year or so.--Moxy- 20:03, 30 August 2021 (UTC)

Bad idea. A ton of TfDs are rubber stamping following cleanups like migrations of rail templates to

WP:SOFTDELETE). Is there actually any evidence of a problem here, such as links to DRVs showing TfDs closed in this manner reached incorrect decisions and thus were overturned? ProcrastinatingReader (talk

) 20:09, 30 August 2021 (UTC)

Correct as per

WP:NPASR...just to bad that area of Wikipedia does not have better oversite....one day one can hope for better.Moxy-

00:58, 31 August 2021 (UTC)

Agree with proc. A lot of TfDs don't get any votes, and like AfD and RfD, those can be deleted after a week. Of course, I think most admins would be willing to undelete upon request if the consensus is very weak. Elli (talk | contribs) 20:12, 30 August 2021 (UTC)

Proc said it well. A ton of TfDs are completely uncontroversial with many similar deletions occurring in the past with more discussion. These are often unused and not used on hundreds or thousands of pages like most of the templates that editors know about. If you have concrete TfDs you have issues with I'm sure the regulars are willing to discuss or change as appropriate. While there are a lot of problems with having a quite small pool of closers it does make changing norms a lot easier. --Trialpears (talk) 20:28, 30 August 2021 (UTC)

• Oppose. Agree with Proc's analysis of the situation. Also, strictly speaking, there are no votes in deletion discussions. Editors make recommendations, and the closing party decides based on quality of arguments as well as quantity. —C.Fred (talk) 20:32, 30 August 2021 (UTC)
• Oppose per Proc. {{u|Sdkb}} ^talk 00:48, 31 August 2021 (UTC)
• Oppose I guess per above. It the closers are admins, they're probably pretty good at figuring it out. Just treat it like a PROD I guess... somebody nominated it, nobody objected after a fair amount of time, the admin can deleted BUT use her discretion not to, and anyway yea undelete upon request in a case like that. I guess. Herostratus (talk) 00:47, 3 September 2021 (UTC)
• Oh no, all these editors editing for only a year or so, what could we possibly do about them? Oppose:
  WP:SOFTDELETE linked above can handle the job well enough in my experience. ~~~~
  User:1234qwer1234qwer4 (talk
  ) 17:44, 8 September 2021 (UTC)

Add a contact us button and a help button to the mobile view

File:Mobile Wikipedia Menu.png

It's very obvious that these two options would make the mobile version of Wikipedia more user-friendly. Interstellarity (talk) 16:31, 1 September 2021 (UTC)

• Support as nom. Interstellarity (talk) 16:31, 1 September 2021 (UTC)
• Would the proposed “contact us” button link to the article’s talk page, or are you proposing something different? Blueboar (talk) 16:47, 1 September 2021 (UTC)
• Wikipedia:Growth_Team_features#Help_panel is already being developed. If you're talking about the mobile left sidebar, that could probably benefit from some broader discussion. {{u|Sdkb}} ^talk 16:57, 1 September 2021 (UTC)
  • I've found that newbies make good use of the growth team features for essentially this purpose. I agree we should look into expanding its use if possible. — Wug·a·po·des​ 20:28, 1 September 2021 (UTC)
• ? @Interstellarity: which mobile view (please be specific)? What do you propose the target of these be? Is this something that we, the English Wikipedia editors, can technically implement? — xaosflux ^Talk 17:56, 1 September 2021 (UTC)
• Hi all,

The proposed contact us link would link to Wikipedia:Contact us and the help link would like to Help:Contents. In the mobile sidebar (the image to the right), I think both links are best placed next to the About Wikipedia and Disclaimers link. I'm not sure if it can be technically implemented by English Wikipedia editors, but I hope I provided enough information on this in detail. Interstellarity (talk) 18:19, 1 September 2021 (UTC)

There does not appear to be anywhere for us to do this locally, you could start by inquiring with the mobilefrontend developers to see if: (a) project-specific sidebar links could be supported here such as they are on the webui; (b) possibly if project specific parameters would be supported here; (c) if this is something they would want to incorporate in to the master extension. — xaosflux ^Talk 18:53, 1 September 2021 (UTC)

@Xaosflux: Could you provide the contact information for the people responsible for developing the mobile interface? That would help a lot. Thanks, Interstellarity (talk) 18:54, 6 September 2021 (UTC)

@Interstellarity: like most things, it is supported by the developer community. The workboard for this is here. @Fuzheado: is listed on that project and may have more information. — xaosflux ^Talk 19:17, 6 September 2021 (UTC)

Hmm.. not sure what you're referring to in terms of me being listed on a project? Fuzheado | Talk 00:25, 7 September 2021 (UTC)

@Fuzheado: click here you are actually listed as the only member of the "Mobile" project. I'm assuming phab project management is a sloppy mess now though! — xaosflux ^Talk 02:44, 7 September 2021 (UTC)

@SGrabarczuk (WMF), I think this idea might be mostly for Olga's team? Whatamidoing (WMF) (talk) 19:17, 9 September 2021 (UTC)

Also here is the MobileFrontend project listing. — xaosflux ^Talk 02:45, 7 September 2021 (UTC)

Would editors have any way of replying to such a contact? The most valuable part of this development could be a way around

WP:THEYCANTHEARYOU. Certes (talk

) 19:06, 6 September 2021 (UTC)

Interstellarity is proposing the addition of a prominent link to Wikipedia:Contact us, which recommends boldly editing articles, posting at the Teahouse, sending e-mail to the Wikipedia:Volunteer Response Team, and several other things. Most Wikipedia editors would be able to reply to some of those but would not see others. Whatamidoing (WMF) (talk) 19:20, 9 September 2021 (UTC)

So... I been seeing a lot of massively-viewed articles without a protection, due to it being expired. Should we start discussing the idea of an auto-protect bot for articles that get over 250K views a day, and depending on size like is it a B class or GA class, should it be protected. It will help most of the CVU/AVU jobs. MoonlightVector 16:21, 7 September 2021 (UTC)

You are seeing unprotected pages with lots of views because

requests for page protection where a human will review the best tools to stop the disruption. — Wug·a·po·des

​ 20:04, 7 September 2021 (UTC)

This has very little chance of passing, even with a very conservative threshold, but I wish we wouldn't dismiss it out of hand so quickly. We recently had a very acute lesson in what can happen when we wait to see if vandalism occurs rather than acting preemptively. There's not a huge difference in pageviews between a template that appears on 500 smallish articles and a single extremely high-visibility article. I would be interested to see a (hopefully non-public; feel free to email me) list of the unprotected pages with the most pageviews. There's good reasoning behind our founding-era principles, but at this point they're 20 years old and they're not gospel, so we shouldn't be afraid to re-examine them as needed. {{u|Sdkb}} ^talk 21:10, 7 September 2021 (UTC)

@Sdkb, while there might not be a huge difference in pageviews between a template that appears on 500 smallish articles and a single extremely high-visibility article, it is much more common for templates to use more complicated wikisyntax than for articles, so the protection likely prevents widespread damage from unsuccessful good-faith "fixes" by unexperienced editors and not just vandalism. Sure, this can (and does) of course as well happen to articles, but again, these usually have more simple syntax (and afaik the VisualEditor is now the standard option?) ~~~~
User:1234qwer1234qwer4 (talk) 15:43, 8 September 2021 (UTC)

Indeed, the reason for protecting templates isn't page views, it's the technical aspects of how templates work. The harm of good-faith-but-incorrect edits is a major reason, but the damage caused by bad faith edits to templates can persist even after a revert because of how pages are parsed and served to readers. Rather than processing each page every time a reader requests it from the server, we cache them. An edit always invalidates the cache, forcing a re-render of the content. Most vandalism is reverted quickly if it even gets past filters, and since the edit purges the cache the vandalism immediately disappears. This is not true for templates. Because updates to templates can invalidate millions of caches, any update to a template is slowly rolled out across pages that use it. So no matter how quickly vandalism to a template gets reverted, it can stay up on articles for potentially hours after the revert, until the cache gets updated. These are vastly different levels of damage, and the idea that preemptive template protection is the same as preemptive article protection only makes sense if you don't dig into the specifics of how these attacks work. Vandalism to a template used on many small articles can easily have much greater consequences than vandalism to a single highly visible article.

@

WP:HRT yesterday. If we are going to amend a foundational principle of the website and major clause of the protection policy, per the parable of Chesterton's fence I'd want a proposal that shows some understanding of the protection policy, or at least mentions it, before I support spending substantial volunteer time entertaining a perennial proposal. — Wug·a·po·des

​ 21:27, 8 September 2021 (UTC)

@

WP:PERENNIAL list yet, which might be a good idea. When recently-discussed topics are raised, it's good to have easy access to a concise history with wikilinks. {{u|Sdkb}} ^talk

21:35, 8 September 2021 (UTC)

@

pending changes protections, which, while allowing everyone to edit an article, would make edits subject to a review before being displayed. I don't have any strong opinion on the issue, but I wanted to point out that the "protection" mentioned in the opening comment does not necessarily refer to a protection from editing. ~~~~
User:1234qwer1234qwer4 (talk

) 15:55, 8 September 2021 (UTC)

I thought thatwe ecisevely rejected thatan idea in a vey well attended RfC afew yearsago. I don't see that we've beome any worse since then. (I sometimes think of editing deWP, but their pending change protection always causes me to go away.) DGG ( talk ) 06:35, 10 September 2021 (UTC)

Background

This is a proposal to expand the functionality of {{find sources}}, a template frequently used in {{Talk header}} (example) to help editors find sources to improve articles. Specifically, we seek to make it possible for different sets of links to appear for different types of articles, such as links to medical sources for medical articles.

Currently, there are three four related templates that generate find sources links:

• {{find sources}}, the basic set of sources starting with five Google links, plus JSTOR, NYT, and a couple more
• {{find video game sources}}, which contains the basic set above, plus three more links targeted to video gaming
• {{
  WP:MEDRS
  -compliant sourcing
• {{find biographical sources}}, a set of links aimed at supporting biographies.

We anticipate that additional templates in this family for other subject areas may be created in the future. Under this proposal, talk header will choose between the available templates, either automatically or on the basis of a manually set parameter, to display the one most appropriate for a given page.

Approaches for selection

We are considering several possible approaches for how to select which set of links to use:

1. Through a new parameter that can be manually set (i.e. to display medical links at Talk:Giardiasis, we'd change {{talk header}} to {{talk header|search-domain=medical}} at that page)
2. Through auto-detection of WikiProject banners (i.e. Talk:Giardiasis would switch to using medical links because it includes the {{WikiProject Medicine}} banner)
3. Through auto-detection of Wikidata properties (i.e. Talk:Giardiasis would switch to using medical links because an automated analysis of its Wikidata item identifies it as a medical topic)

It would be possible to combine these approaches, such as implementing a combined option 2 – 1 approach, which in the case of {{Talk header}} would default to option 2 (project auto-detect) but would allow any editor to set a parameter (e.g., {{talk header|search-domain=medical}}) which would then take precedence over the project auto-detect. Having the parameter available would also be extensible to use by other templates on article pages where project detection isn't applicable; see below.

Previous discussion is at Template talk:Talk header, and we have created functional prototypes of options 1 and 2 in the talk header sandbox, which can be seen at the associated test page. (Current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.)

Which approach(es) would you prefer?

Design

We are considering implementation via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes {{Find general sources}} by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where {{Find sources}} transcludes {{Find general sources}} which invokes the Module.

Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before.

Impact on other templates

Other templates use the {{

. Depending which approach is chosen, this could affect whether the other templates will be able to take advantage of them. A combined approach allowing auto-detect and via param would permit both.

We look forward to your feedback on the considerations above and the proposal overall. Thanks! Mathglot (talk) and {{u|Sdkb}} ^talk 23:20, 12 August 2021 (UTC) updatedto add biographical sources; by Mathglot (talk) 22:32, 13 August 2021 (UTC)

• Listed at: Wikipedia talk:WikiProject Medicine. Mathglot (talk) 23:49, 12 August 2021 (UTC)
• Listed at: Wikipedia talk:WikiProject Video games. Mathglot (talk) 23:53, 12 August 2021 (UTC)
• Support as helpfully expanding the utility of this talk page banner. I would in particular be a fan of the wrapper template idea, as it is the least disruptive imo. I think the parameter approach via "search-domain=medical" is the best solution for how to label pages as needing MEDRS in the banner, though I think the auto-labelling is a good idea. My suggestion would be to try the auto-labelling first, and revert to manual labelling anything that is medical if it goes haywire and labels a lot of unnecessary things.--Shibbolethink ^{(♔ ♕)} 23:57, 12 August 2021 (UTC)
• As co-nominator, I obviously support this. Given how widely the find sources links appear, I think it's important that they are as useful as possible, and this will help with that by making them more appropriate to their context.
  Regarding selection approaches, I favor mainly option 2 (project banners), with the ability to override via option 1 (manual parameter setting). That's because I think it's important to have an element of automation to get this adopted on a wide scale. Option 3 (Wikidata) doesn't seem technically feasible, so that leaves project banners. I think "Is this tagged with {{WikiProject Medicine}}?" is an excellent metric, because the project tag belongs on all medicine-related articles, which is also basically the set we want to have the medicine links. However, it's nice to have the ability to override the default for the rare cases where it isn't working as expected, and having the parameters from option 1 will allow that. The only thing weighing against them is added code complexity, which isn't a huge downside.
  Regarding the wrapper template implementation, that's been more Mathglot's area of focus, so I'll defer to them and others who comment here. Also, I realize all this is more complex than some of the stuff that comes across VPR, so if anyone has questions or wants clarification, please don't be afraid to ask! Cheers, {{u|Sdkb}} ^talk 05:50, 13 August 2021 (UTC)
• I support the general proposal. I do have some questions about the implementation - I think if an automated detection system is implemented it will need to have a bit more subtlety than 'does this have a WikiProject Medicine banner?'. Articles about people in medicine, healthcare companies, medical books or journals, the history or social/political aspects of medicine, etc. are usually tagged with WPMed, but these articles do not necessarily require MEDRS sourcing for all claims. I wouldn't say this is a 'rare' case. If it's possible to take the intersection of WikiProject banners into account (e.g. don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed) that might help, but I think this might need to be handled via a supervised AWB run or similar. Also, a hybrid of the 'find medical sources' and 'find general sources' template could be helpful for topics that might contain claims needing MEDRS sources but which are not strictly medical. Spicy (talk) 19:54, 13 August 2021 (UTC)

  I like the thought of the hybrid template, since for the examples you gave, most sources wouldn't need the MEDRS standard but several might. For instance, a medical researcher would need it for the part of the page discussing their discoveries, a company for discussing their products, a journal for discussing medical controversies about their work, a history page for discussing medical details about viruses involved in a pandemic, etc. {{u|Sdkb}} ^talk 20:40, 13 August 2021 (UTC)

  @Spicy:, regarding "don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed" this could definitely be added; it poses no great difficulty and would be isolated in the wrapper. It just depends on whether that idea gains consensus.

  Another option to consider, is that there's no need to choose only one set of "find sources" links. If the article is in both projects as in your example, one could imagine various outcomes: we could let the Talk header template grab the medical links automatically, and then add a biographical links below it, the second one either added automatically as well, or manually by adding {{

  biographical sources box

  }}. Yet another possibility, would be to have the order of WikiProjects matter: if Med is first and Biog second, then you only get the "find medical links" automatically, anything else you'd have to add manually; if Biography WikiProject was first, then it would be the other way round. But maybe it's too subtle operationally, even if well documented ("You mean, I'm spozed to read the stinkin' documentation?") Not sure why AWB would be involved; I think it's all doable in the wrapper.

  Sometimes having too much choice gets to be a problem because you can get

  paralyzed with all the possibilities, so at the outset I'm inclined to go with the simplest useful proposal that gains consensus; not because that makes it easier for template writers, but because that will give editors some time to see and use the new functionality, which may subsequently percolate into a more specific and informed wish list of increased functionality based on their real-world experience with the early version. Mathglot (talk

  ) 22:11, 13 August 2021 (UTC)

  The reason why I suggested AWB is because I think human judgment could be required for some of the edge cases - I don't think we should be giving people the impression that a MEDRS-compliant source is required to cite a medical device company's yearly revenue, for example. I suppose this could be handled in other ways, like the system you've described or Sdkb's hybrid template idea (although both of those rely on the assumption that the WikiProject tagging is accurate, which isn't always the case)... Spicy (talk) 06:16, 31 August 2021 (UTC)

  Not too familiar with

  AWB but would there be any significant downside to first using Mathglot's logic-based approached based on WikiProject with a manual override? Centralizing the logic where possible seems preferable. In the case of a medical company, maybe just add priority logic to check for 'WikiProject Companies' and assign those topics to display the general link set. AWB could still be used to mass apply overrides if there's a scenario that can't be accounted for in the root logic. - Wikmoz (talk

  ) 20:48, 31 August 2021 (UTC)

  @Spicy:, Hopefully as people see it live and perhaps read the expanded /doc, they'll see some of the options and apply whatever makes sense to get the desired display. As far as not requiring MEDRS links for the medical devices company revenue case, two possibilities occur to me without changing anything said prior (although these examples are no doubt not obvious since it's not live, and there's no doc):

  • Add an additional set of links to the header outside the scope of the new header functionality, by separately adding {{
    General sources box}} after the Talk header, so that you have both the medrs links automatically added by the new template functionality per Med project presence, and the "regular" links. You can see how this would look in this mocked up Talk page
    for the "Cochlear Limited" article (note: the actual Cochlear article TP does *not* have WikiProject Medicine on the Talk page; I had to add it to the mockup for the purposes of this test)
  • turn off find-source links with the existing 'hide' param, and add {{
    General sources box
    }} (i.e., the Talk page will look the way it does now) (the third, "hybrid" solution has been mentioned already)

  I was trying to find a medical devices company with the Medicine WikiProject already present so it would be a good example of your concern, but I gave up and had to force project medicine into the mockup for the test. (I didn't look very hard.) The question, I suppose, is this: "Is the benefit of having medrs links produced automatically via project detection worth the disruption that might be caused by losing the general "find sources" links for cases like medical device companies tagged with project Medicine, or in other cases where the correct WikiProjects are not applied and so the general link set would be better?" Is that a fair statement of your concern? I'm not sure we know the answer to that until we try it, unless someone wants to do some clever analysis and see what's out there now. I'm not opposed to undoing the installation after the fact, if on balance it turns out that the new approach is not helping editors improve the articles concerned by proposing a better set of reliable source links for most articles most of the time, because that is the whole point, right? Mathglot (talk) 01:47, 1 September 2021 (UTC)

• I broadly support the idea, allowing for tweaks to get the usability issues right. It's worth steering people towards suitale sources somehow. Shooterwalker (talk) 22:18, 13 August 2021 (UTC)
• Support. I think this is a good idea. Clovermoss (talk) 22:23, 13 August 2021 (UTC)
• Listed at: Module talk:Find sources. Mathglot (talk) 22:28, 13 August 2021 (UTC)
• Listed at: WT:WikiProject Biography. Mathglot (talk) 23:23, 13 August 2021 (UTC)
• Support. Very cool idea and great work Mathglot and Sdkb! I think Option 2 (with the manual override function) sounds like the best approach. It's probably not worth getting too hung up on the edge cases. For those, I'd favor whichever approach is easiest to engineer and maintain with a slight preference to avoid hybrid or stacked link sets. - Wikmoz (talk) 01:35, 22 August 2021 (UTC)
• Mathglot, Sdkb: What would be the next steps? - Wikmoz (talk) 04:46, 31 August 2021 (UTC)

  ​Thanks for the follow-up, Wikmoz. This hasn't garnered too much participation, but since it's been in a visible location and reactions so far have been positive, I'd say it's safe to move forward with implementation using option 2 with manual override function. {{u|Sdkb}} ^talk 20:31, 31 August 2021 (UTC)

  Yes, that sounds reasonable to me. Once it's been moved live in template form and had time to gain some page views, we could take another look to see if more tweaks or other changes are needed based on any feedback from those encountering it for the first time. Perhaps subsequent to that, I imagine one would check to see about moving parts of it into the module. Adding Sdkb. Mathglot (talk) 20:48, 31 August 2021 (UTC)

Hello! I am not sure if I am putting this post this in the correct place, so please excuse me it is not.

The article

is continually being vandalized by users (often anonymous IPs), who delete large, referenced blocks of texts. The reason for this appear to be that the information is slander against Islam. These edits are always reverted by experienced users, and since these edits are never referenced and instead removes referenced information, it is easy to make the assumption that there is a religios bias from users who which to remove referenced information because they think that this information put their religion in a bad light. Recently, I myself ask for citations from certain information in the article, but this was reverted by a user who claimed these sentences had references, even if they did not. Clearly, the article attracts emotions.

Another issue has come up: the article has long had a neutrality template. Because of the consistent vandalizing, I wondered if the neutrality template was in fact placed their originally because of religious bias. I made this question on the talk page, and the template was indeed removed. It has since been restored. I have to say, that the article is large, I have not read all of it, I am not an expert in the subject, and I cannot be entirely certain whether the neutrality template is warranted or not. And since I recognize that this is a sensitive issue, I simply don't have the energy to involve myself further.

However, it is safe to say that the article is about a very sensitive subject, and I am forced to revert vandalism so often that I wonder; should not an article that are so sensitive and vandalized so often as this one have some sort of protection? Many sensitive articles who are often vandalized have such a protection, at least against IP-editing. So my question is; can this article be protected? It truly needs it, I have to revert vandalism more often on it than any of the other articles on my watchlist. Best greetings, --Aciram (talk) 17:04, 8 September 2021 (UTC)

@

WP:RPP. ~~~~
User:1234qwer1234qwer4 (talk

) 17:07, 8 September 2021 (UTC)

The article is now semi-protected. Johnuniq (talk) 02:02, 9 September 2021 (UTC)

I agree that the page reads a bit non-neutrally and is possibly missing a lot of context. For something as contentious or sensitive as this, each statement should have multiple independent reliable sources, not just one. Else it could be taken as an attack page. I think the appropriate course of action is to take the matter to the talk page to discuss the issue, possibly nominate the page for deletion. Aasim (talk) 19:33, 13 September 2021 (UTC)

Hi y'all! I've been spending the last few hours and have realized that there is quite a heavy backlog of old split proposals that never got attention (in addition to a large amount of tags that have not been removed after a failed discussion). How could Wikipedia deal with this? The QPQ system for DYKs is very good at dealing with unresolved nominations, but I don't see how it could be applied here. Adding some kind of parameter to the

10:06, 14 September 2021 (UTC)

Not necessarily against the idea, but please note that about half of our Wikiprojects are moribund. Notifying a moribund Wikiproject won’t do much. Blueboar (talk) 12:46, 14 September 2021 (UTC)

Just as a reminder, splits and merges are covered in

b

} 23:33, 14 September 2021 (UTC)

Proposal to Improve Template:Infobox artist by adding parameter for existing works...

Hi Wikipedia users!

New users which are not eligible for editing new pages on English Wikipedia, cannot have an option "Submit the draft for review" when creating a draft at: https://en.m.wikipedia.org/wiki/Wikipedia:New_user_landing_page which they want to move the draft to the main article. Please add this option as it is needed for new Wikipedia users which create drafts in order for their drafts to be articles on English Wikipedia.

Thank you — Preceding

) 04:48, 18 September 2021 (UTC)

@ARBENTUZI The button Start creating! under their article wizard heading allows you to create a draft with the "submit" button , after navigating through the options. Is that what you were asking? ― Qwerfjkltalk 10:28, 18 September 2021 (UTC)

No I am asking to make an option on a draft "submit for review" in order for the draft to be moved as a main article.— Preceding

) 11:23, 18 September 2021 (UTC)

@ARBENTUZI The whole point of draftspace is that it is reviewed before being moved to namespace. Otherwise, there would be no point in preventing new users from creating articles. ― Qwerfjkltalk 11:58, 18 September 2021 (UTC)

All

Wikipedia:Autoconfirmed users can move

pages from Draft: to the article mainspace. I wonder what percentage of new editors could do that themselves, by the time they finish drafting the article? ARBENTUZI, for example, just needs another two edits.

Also, there's another process called "review", and that's done by Wikipedia:New pages patrol rather than Wikipedia:Articles for creation. Maybe the question is about that. WhatamIdoing (talk) 21:04, 20 September 2021 (UTC)

• To put this another way… When someone creates a draft in Draftspace, it is automatically “submitted” for review. No need for a button. Blueboar (talk) 13:24, 18 September 2021 (UTC)

  No, that's not a good idea. How would reviewers know when it was ready for review? You would have partially complete drafts getting declined and wasting reviewer's time. The backlog for reviews is already bad, putting every partway done draft into the review list would make it unbearable. RudolfRed (talk) 17:23, 18 September 2021 (UTC)

• When you create an article in draftspace, put the {{Draft article}} template at the top of the page. This includes an option, when you’re ready, to 'submit for review'. --Malcolmxl5 (talk) 19:56, 18 September 2021 (UTC)

Hi Wikipedia admins!

Please either allow new Wikipedia users to submit a draft for review or automatically be accepted as an article or allow them to create new articles directly without being required to make 10 edits. Like they create articles directly on every other Wikipedia.

Thanks — Preceding

) 21:40, 20 September 2021 (UTC)

There is a reason we stopped allowing freshly-registered accounts to create articles directly in mainspace, and there'd need to be a new consensus against this to roll the change back. And if you know how to edit source, you can use {{subst:submit}} to submit a draft for review. Stop relying entirely on there being a button for everything. —A little blue Bori v^_^v ^{Jéské Couriano} 21:46, 20 September 2021 (UTC)

@ARBENTUZI:

1. At the New user landing page, click Start creating.
2. Read the advice and click Next when finished.
3. Do that again.
4. Answer the next prompt honestly.
5. Depending on your answer, you may have to read a few more prompts, but eventually you will be asked to create a title for your draft page. Enter it in the bar and click Create new article draft to get started.
6. When you finish writing your page, click Publish changes to publish your draft.
7. Finally, when your product looks something like this, click Submit the draft for review! to do that thing. –MJL ‐Talk‐^☖ 17:26, 21 September 2021 (UTC)

To Arbentnui, I agree with all points mentioned above, please read the feedback that you have gotten here. Varousz (talk) 22:05, 22 September 2021 (UTC)

• I have to agree with ARBENTUZI that we really ought to have {{

  Submit}} (which sends articles to AfC) integrated into the interface in draftspace, rather than relying on editors to add it and not accidentally remove it themselves. {{u|Sdkb}} ^talk

  04:44, 23 September 2021 (UTC)

  @Sdkb When I was checking all the articles caught by the "AfC draft submitted with no references" tag, I found 3 malformed submissions. I'm sure a source search could easily turn up more. ― Qwerfjkltalk 19:59, 23 September 2021 (UTC)

Wikipedia:Books and articles have the option of converting to PDF. I propose we offer EPUB in addition. .... 0mtwb9gd5wx (talk) 01:15, 19 September 2021 (UTC)

@0mtwb9gd5wx: Wikipedia Books basically don't exist any more -- the Offline Content Generator was deactivated because there was no interest in maintaining it, the Books namespace was deprecated, and all existing books were deleted. The replacement "Download PDF" link is just running a copy of Chrome on a server and uses it's built in "print to PDF" function, so there is no option to convert it to other formats (since printing and converting are entirely different processes). You can, however, use MediaWiki2LaTeX (https://mediawiki2latex.wmflabs.org/) to convert pages to EPUB. --Ahecht (TALK
PAGE) 13:36, 24 September 2021 (UTC)

https://archive.is/zeW6f

(Sorry, wikipedia doesn't accept the full URL, hence archived page.) — Preceding unsigned comment added by 37.115.210.35 (talk) 19:10, 23 September 2021 (UTC)

I don't see what specific change is being proposed here. — JohnFromPinckney (talk / edits) 16:51, 25 September 2021 (UTC)

This is a notice that an RfC has been started requesting comment on if the draft of

) 16:34, 27 September 2021 (UTC)

 You are invited to join the discussion at MediaWiki talk:Editpage-head-copy-warn § Can we remove the content reuse disclaimer?. {{u|Sdkb}} ^talk 03:03, 2 October 2021 (UTC)

This is a quite big and good feature to have as of right now, i have been getting quite a bit of ip's vandalising my page and doing the request to protect my talk page is time consuming, a feature i would request is for all Extended users to be able to protect their talk page from ips. MoonlightVector^{Talk page} 14:50, 4 October 2021 (UTC)

MoonlightVector This is a form of a perennial proposal, see Wikipedia:Perennial proposals#Grant non-admins admin functions within their user space. 331dot (talk) 14:52, 4 October 2021 (UTC)

I don't think it's possible to gives users permission to protect specific pages without admin rights as if you're able to add protection to 1 page, you're able to add protection to all pages. However if this is possible then I think it should be a separate permission from Extended Confirmed similar to rollback to prove that the user will be able to use it correctly and not use it to just prevent people from warning them or something on their talk page. 331dot makes a good point above. ―

^Talk

_{Blaze Wolf#6545} 14:53, 4 October 2021 (UTC)

• If you have a habitual problem with IPs vandalizing your talk page, you may request indefinite protection. 331dot (talk) 14:55, 4 October 2021 (UTC)
• Another option is to treat your user talk page the way you might treat voicemail on a phone… simply clearing/deleting any messages you don’t want to keep.

I regularly clear my user talk page after I have read new messages (not just vandalism). And I have found that Vandals tend to go away if you don’t respond to them. Blueboar (talk) 15:16, 4 October 2021 (UTC)

Your 2nd part is the entire reason

^Talk

_{Blaze Wolf#6545} 23:39, 4 October 2021 (UTC)

It is well know that the results of UFC events are often subject to vandalism. Wouldn't it be better to semi-protect the articles (as the event nears) to allow only registered users to edit. Most of these fake edits come from IP accounts. Registered users would get banned if they do anything spooky. I posted this suggestion in WT:WikiProject Mixed martial arts. but was doubtful for a response as it is quite inactive. I am not a highly experienced editor. Just thought of sharing my suggestion to the editors here.--Atlantis77177 (talk) 10:09, 6 October 2021 (UTC)

As it is policy to encourage people to try editing Wikipedia without requiring that they first register an account, we in general do not pre-emptively protect pages. If repeated vandalism or disruption over a short period becomes a problem on a page, we can temporarily protect the page or block IP addresses or ranges from which abusive edits are being made. - Donald Albury 13:50, 6 October 2021 (UTC)

A common theme when seeking admin intervention against a troublesome IP is that too many productive users will be caught in large range blocks.

Would there be value in having a page that logs IP ranges with vandalism/spam issues and then produces a recent changes queue limited to these ranges? Slywriter (talk) 12:43, 1 October 2021 (UTC)

• Interesting concept. If you did such a thing, two (or more) issues come up. Likely, it would need to be "admin only" to read, like the page that shows article pages with few or no watchers. The idea is to prevent low hanging fruit for vandals. Second, having a bot determine what the proper range is presents problems. Ranges aren't cut and dry, and you have v6 and v4 ranges to consider, which is an lot of coding and debugging. I can see the value in page like that, basically a list of hot spot ranges, even if it was a little sloppy with the ranges, but the question would be: does the benefit outweigh the work involved? I don't know. Then the next question is, who is willing to write the bot to maintain this? Again, an interesting idea, but it would require a fair amount of investment for an unknown return, particularly because it may be limited to admin (at least at first). Dennis Brown - 2¢ 11:37, 7 October 2021 (UTC)

Dear colleagues, please comment on CentralNotice banner proposal for Alumni and Mentors of Russia 2021 articles writing contest. (15st September 2021 → 30th November 2021, all IPs from Russia, Wp, 3 banner impression per one weeks). Only for russian ip. Thank you. JukoFF (talk) 13:34, 11 October 2021 (UTC)

• This is at meta:CentralNotice/Request/Alumni and Mentors of Russia 2021. — xaosflux ^Talk 13:44, 11 October 2021 (UTC)

In follow up to Wikipedia:Village_pump_(technical)#Paalika_Keka and some edit summaries at MediaWiki:Preferences-summary/en-gb, I'm proposing that we specifically add verbiage that we "discourage" our users from selecting en-ca and en-gb interface variants. These variants cause users to miss any localization to our interface messages, and put them at the mercy of either falling back to the default message - or accepting whatever the editors of translatewiki have put in place. I'd much prefer we forcibly made these fallback, but that is not currently a software option. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

Pings to some recently involved editors: @PrimeHunter, Mike Peel, Redrose64, and Jdforrester:. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

• Yep, scrap the lot. I suspect that people who choose these options do so in the belief that it will configure the text of articles - which is the one thing that it doesn't alter. Most of us know that petrol and gasoline are the same substance, but how often do words with UK/US variants come up in the interface messages? --Redrose64 🌹 (talk) 20:50, 24 September 2021 (UTC)
• Fully support deprecating the lot for all the reasons above. They only cause problems that we then have to unravel at VPT(!). firefly ( t · c ) 20:55, 24 September 2021 (UTC)
• Support. I once examined the full en-gb file and it only made around ten minor spelling and punctuation differences like color/colour, not different words like petrol/gasoline. For that you lose a lot of messages customized for the English Wikipedia, e.g. with links to our policies, processes and help pages. For example, compare the edit page for a fully protected page in en and en-gb (admins must log out to see it). en-gb users sometimes cause confusion when discussing the interface with others, and some help pages don't match what they see. en-ca (Canadian English) has the same problems but few users so it rarely comes up. PrimeHunter (talk) 21:18, 24 September 2021 (UTC)
• Support; they are nothing but trouble. Customize some of the messages within the variants to point people to how to choose the right setting. – Jonesey95 (talk) 00:33, 25 September 2021 (UTC)
• Support per Primefac. – SD0001 (talk) 02:21, 25 September 2021 (UTC)
• Yep, support. Tol (talk | contribs) @ 02:41, 25 September 2021 (UTC)
• Comment since I was pinged. We already have a warning in the preferences: "Language (warning:selecting a language other than 'en - English' may prevent you from seeing custom parts of the interface on the English Wikipedia and you may see inaccurate external translations.):" (where the 'external translations' bit is weird/wrong - it's translations built into MediaWiki). Presumably that could be extended to warn against en-GB and en-CA. I'm generally in favour of giving people the choice, though. Also, it shouldn't be completely disabled, as it's useful to browse the interface in other languages when you're not a native language speaker (I quite regularly do this on other language wikis). Thanks. Mike Peel (talk) 10:11, 25 September 2021 (UTC)

The quoted warning was added to MediaWiki:Yourlanguage this year. It is only displayed if the language is still the default en. PrimeHunter (talk) 13:35, 25 September 2021 (UTC)

The bit about external translations is correct because it is done at Translatewiki.net, which is not a WMF wiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)

• @Mike Peel: I don't think we have the capability to remove these entirely locally, this is just about "discouraging" this right now - and may include adding warnings if your language is in those English variants. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Just to be clear, this proposal is only about the interface - and will have no impact in any way at all on the content of articles or the manual of style for engvar's in articles. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Support per nom. ― Qwerfjkltalk 14:21, 25 September 2021 (UTC)
• Support. Checking the last 30 days stats at translatewiki, en-gb has 44 translations and en-ca has only 4 translations. This shows that there are very few maintainers for these variants, which is what causes test edits and vandalism to go undetected until en.wp users notice it. Due to lack of active maintainers at both translatewiki and locally at en.wp, users who opt English variant interfaces get a suboptimal experience. So English variant interfaces should be discouraged in favour of base en. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)
• Can we not just get en-GB and en-CA removed? What purpose do they serve? – Joe (talk) 07:55, 26 September 2021 (UTC)

  @Joe Roe: in some cases yes - part of this proposal is to actually discourage editors from "selecting" that language - not just cleaning up the messages; some prior messaging had push back about discouraging someone from using those settings. Nothing intrusive - just labels on things like preferences warning that this option is discouraged if someone actually does set it. — xaosflux ^Talk 09:42, 26 September 2021 (UTC)

  I mean removed as option, so we don't have to have to have these messages. – Joe (talk) 09:46, 26 September 2021 (UTC)

  Probably non-zero development work from the languages team, especially since a user's interface preference can be global and not solely local. IznoPublic (talk) 15:15, 26 September 2021 (UTC)

  If development work is being done, then the right solution is to fix phab:T57473, rendering the whole issue moot. * Pppery * _{it has begun...} 22:57, 26 September 2021 (UTC)

  @Pppery: the general tech problem is that when a localized message exists in a base language, but the user is set to use a base-variant language, when the base-variant language is not localized the user's language fallback chain doesn't bring them to the base language. — xaosflux ^Talk 23:32, 26 September 2021 (UTC)

  Does phab:T57473 refer to something else? * Pppery * _{it has begun...} 23:34, 26 September 2021 (UTC)

  That one seems to be about the fallback chain for base languages only, I think there is another could of phab tickets about base-variant fallbacks that I'm not remembering right now.— xaosflux ^Talk 11:01, 27 September 2021 (UTC)

  Oh. I actually meant fix the general problem, not one specific manifestation I may have linked to by mistake. * Pppery * _{it has begun...} 14:14, 27 September 2021 (UTC)

• Yes, please, discourage away. I'm tired of getting confused questions at VPT. :^) --IznoPublic (talk) 15:16, 26 September 2021 (UTC)
• Forcibly deprecate if we can get the developers to allow us to do it, and Support as second choice if not. No reasonable user who understands the situation would choose en-XX, and keeping the options around only confuses people and makes them waste their time figuring out the correct choice. We also ought to be doing all we can to discourage editors from wasting their energy maintaining the en-XX UI sets—having those forked makes precisely as much sense as forking English Wikipedia into American English Wikipedia and British English Wikipedia, i.e. zero sense. {{u|Sdkb}} ^talk 18:03, 1 October 2021 (UTC)
• Support. I've had a problem caused by selecting GB- User_talk:SilkTork#What's_broken?, which has now been fixed by reverting to standard en. What it offers (a simple spell check) can be problematic in itself as I am aware that I have automatically "corrected" spellings in articles which shouldn't have been corrected because that option is offered even when the article is supposed to be in American spelling. So it's a fairly useless gadget. SilkTork (talk) 16:45, 5 October 2021 (UTC)
• Support I did set en-GB in my global preferences, and had to revert back to en after some issues in multiple projects. When I selected, I did not foresee the kind of problems it would bring, and even when facing problems, it was not always clear that they were caused by the en-GB preference. MarioGom (talk) 08:36, 13 October 2021 (UTC)
• Support. The behaviour when there are customised messages (which are very common on en.wikipedia) is just confusing for users. Far worse than having to see the occasional US spelling. the wub "?!" 09:35, 13 October 2021 (UTC)

It seems to me that WebCite is obsolete now. I suggest to perform a script run/bot run to migrate all archive links that use WebCite to archive links using the Wayback Machine. According to our article, WebCite has not been accepting new archive requests since February and the site seems to be down since August. It seems unclear if WebCite will come back or not, so I think switching to a more stable archive service seems desirable. In particular, I think in cases were the original link is dead and a WebCite archive link is used, that link should be replaced by a Wayback Machine link if possible. I do not know how many replacements this task would entail, but I expect it would be impractical doing it manually. Toshio Yamaguchi (talk) 09:16, 30 September 2021 (UTC)

• Seems sensible. Stifle (talk) 11:13, 13 October 2021 (UTC)

I have this bot WaybackMedic has approval to run and ran in the past, converting WebCite to Wayback. It's harder than it seems. The problem: WebCite for a long time was the only provider who offered a "save page now" feature, allowing users the ability to save a page at that moment in time. Everyone else including Wayback only did sporadic automated crawls (they eventually offered a SPN). As such, it was the preferred site if you wanted to save a page that had content drift eg. weather stats on a page that are continually changing. So when converting from WebCite to Wayback it's darned tricky to get it right because it requires Wayback to have an exact match of the same day, or risk creating an archive with content drift. The ideal method is copy the WebCite page to another provider, and this is something I am looking into, but don't have much more to say right now. For the record, there are 238,851 WebCite links on enwiki - manual moves are the best option but that would take years of community effort. If there is a page you really care about, recommend doing so. -- GreenC 16:36, 13 October 2021 (UTC)

Fascinating info - I always learn something from you GreenC. Seems like the perfect task for an edit-a-thon, it is a shame we don't do those anymore :-( Thanks again for your expertise. MarnetteD|Talk 16:57, 13 October 2021 (UTC)

Thanks MarnetteD, I think you are right it is fascinating, many faceted. One idea is to convince the CS1|2 group to add a visible message that WebCite is deprecated and to find a new archive link. There is an RfC to support deprecation, and the situation has become worse since then. -- GreenC 17:18, 13 October 2021 (UTC)

Hello,

When I was navigating through articles of

.

I've therefore two questions:

• Is it a good idea? (I think so, but as I'm recurrent contributor to the UNCAT project, I want to ask some questions of principle, in order to know the opinions of the contributors and to be able to clarify certain dilemmas I can ask myself when a categorization seems to me to be done.)
• If yes, can someone help me for the creation of the best-named categories (if necessary) in the relevant parent categories, to make a list of templates to categorise and to do the job.

--Anas1712 (talk) 16:02, 17 October 2021 (UTC)

PS: If not in the best place to ask, please older people in the community indicate me where to repost the asking.

Would you please translate the french part of your statement, to english. GoodDay (talk) 16:53, 17 October 2021 (UTC)

Y --Anas1712 (talk) 17:57, 17 October 2021 (UTC)

I've left a note about this discussion at Wikipedia talk:WikiProject Politics. Thryduulf (talk) 16:55, 17 October 2021 (UTC)

I would like to propose creating a multiauthor space for creative writing: WikiFiction (or WikiNovelist).

Wikinovelists should contribute with donations to be able to participate in multiauthor books and everyone should previously register in order to contribute. This process will hopefully keep bored haters/destroyers away from busy creators -or modern serial witch burners from potential intelligent life out there.

WikiFiction could be a way to get funds for this or other wikimedia projects.

This new platform could recycle the current Wikipedia platform, with the added registration requirement, perhaps with a valid cellphone. A maximum of authors per book should be set for a given time, to avoid some books getting too crowded and the content confusing and neverending changing.

There should be authors and editors, who could review the final book for coherence. All versions should be stored until the final version is agreed. Authors and editors could go by name or nick, but all should be registered with a way to prove identity.

Any profits from any WikiFiction book should ideally be offered to non-profit charity organisations, chosen by votation of main authors, with a percentage dedicated to maintain WikiFiction.

Part of the donations for wikinovelists could be saved in a fund, which will offer free passes for those who could not contribute otherwise. So a young Leonardo da Vinci from a remote village somewhere in this planet, could still contribute to a book with perhaps unique ideas, even if her income is zero.

Creative writing or imagination in general is urgently needed to find solutions for the future we are facing. Encyclopedias and history are giving us great (or terrible) ideas from the past. Some novels (a bit as science) can be a valuable means to predict or create the future.

I will contribute with a first novel first chapter idea as a test. It is aimed to be a multiauthor book that would focus on a paradigm change related to Climate, from looking at plastic or recycling as the big problem here, to admitting we human overpopulation are the real issue on this planet. The book will revolve around that.

This creative piece of work requires the input of scientists, modern philosophers, social anthropologists... And needs to start rolling asap... — Preceding unsigned comment added by 94.252.121.207 (talk) 13:44, 16 October 2021 (UTC)

You are not just on the wrong page for this, you are at entirely the wrong project. Your suggestion is completely outside the

purpose of Wikipedia. You could try reading meta:Proposals for new projects. --Redrose64 🌹 (talk

) 14:38, 16 October 2021 (UTC)

This thing is just not for Wikipedia. It might not even be for Wikimedia. 🐔 Chicdat  ^{Bawk to me!} 09:58, 17 October 2021 (UTC)

@Chicdat: Agreed. The entire purpose of the wikimedia foundation is to run free, open-content wiki projects. A project where you need to pay for access, where only a limited number of people are only allowed to edit each page, and where registrations with a phone number is required to edit is completely at odds with what the foundation is about. There's also the rather strange proposed structure here where donations go to other charities, rather than funding the rest of the foundation? It honestly reads like a proposal for a completely separate website. 192.76.8.77 (talk) 18:40, 18 October 2021 (UTC)

I believe that you will find that the Wikimedia Foundation's charitable purpose is "education". US federal law names six common charitable purposes for a tax-exempt 501(c)(3) organization. See also https://www.irs.gov/charities-non-profits/charitable-purposes. Whatamidoing (WMF) (talk) 02:33, 20 October 2021 (UTC)

@Whatamidoing (WMF): Indeed, but the Wikimedia foundation mission statement [1] makes it clear that the way they intend to go about providing educational materials is by running multilingual wiki projects. My point was that a website where you need to pay/"donate" to be able to edit and where editing is restricted to a small number of people would be entirely contrary to the concept of running wiki based projects, which are generally supposed to be reasonably open and editable. 192.76.8.77 (talk) 09:10, 20 October 2021 (UTC)

Correct. IPv4 nominator, the closest you'll ever get to this is a different website entirely. 🐔 Chicdat  ^{Bawk to me!} 10:22, 20 October 2021 (UTC)

The mission statement says that the goal is "to collect and develop educational content". It is not clear to me why crowd-sourcing novels should be considered any form of "educational content". Whatamidoing (WMF) (talk) 20:01, 21 October 2021 (UTC)

• This is a nice idea, and I like it, but would it not have been better proposed at the section of Wikipedia:Village pump headed WMF? YTKJ (talk) 19:24, 22 October 2021 (UTC)

What should the English Wikipedia community do to communicate about the current election for the Movement Charter Drafting Committee? 03:58, 12 October 2021 (UTC)

WP:BOLDly in light of the discussion below. Mz7 (talk ) 02:54, 13 October 2021 (UTC)

Hi everyone, the election for the Movement Charter Drafting Committee (which is charged with drafting a "Movement Charter", or essentially a constitution for the global Wikimedia community) is now open and will be open for about two weeks, until 24 October 2021. (Info: announcement email, local info page.) There are three things that we should decide, hopefully while the election still has some time to run:

1. Should the election be publicized by MassMessage to eligible voters on enwiki (like for ArbCom elections)?
2.  Already done - Should we post a watchlist notice for the election (like for RfAs)?
3.  Already done - Should enwiki maintain and use a local info page about this election with appropriate information/FAQs and links? I started a rough draft (Wikipedia:2021 Movement Charter Drafting Committee Election) when I noticed that the meta documentation is really not well organized and the messaging thus far has already had a few screwups (the election not being announced when voting opened a day ago; the ballot said there are 19 candidates, but there are actually 70; etc.). If the answer to this question is yes, we could use that local link (instead of the meta links) for all of the local announcements (including watchlist/MassMessage if desired). In any event, please be bold in helping build out the local info page.

Because the election is over in 13 days, this RfC will by necessity run shorter than the standard 30 days. Best, KevinL (aka L235 · t · c) 03:50, 12 October 2021 (UTC)

• Yes on 1, 2, and 3. Apologies for the haste with which this was written – it had not come to my attention sooner that there would not be coordinated communication about this election. KevinL (aka L235 · t · c) 03:53, 12 October 2021 (UTC)
• Support all three. This is a big deal, more so than is recognized: it could fundamentally change the way the movement is organized. It's in our best interest to make sure that en-wiki is well represented in this election, and all three ideas strike me as reasonable ways to do that. (Mass messaging is a bit intrusive, but it's also quite easy to opt out of.) I also hope that, in the spirit of IAR, this RfC is closed promptly, preferably within the week. Regards, Extraordinary Writ (talk) 05:04, 12 October 2021 (UTC)
• Support all 3, and honestly, just BOLDly do the latter two. Enterprisey (talk!) 06:47, 12 October 2021 (UTC)
• Support all 3, do 2 and 3 ASAP. firefly ( t · c ) 07:12, 12 October 2021 (UTC)
• [Disclosure: candidate] - 2 & 3 right now please, and support all three Nosebagbear (talk) 08:46, 12 October 2021 (UTC)
• So: strongest possible oppose to sending tens of thousands of talk messages; There is already a Central Notice up for this, we don't normally put a WLN when there is already a CN - but if people want it, sure; if someone wants to run a local page more power to them. — xaosflux ^Talk 10:13, 12 October 2021 (UTC)
  • Not even sure what a local page would need to do, but I don't really care. The candidates are already selected (meta:Movement_Charter/Drafting_Committee/Candidates) and the voting is already open (meta:Special:SecurePoll/vote/390) - all that is left for the community to "do" really is send in voters. — xaosflux ^Talk 10:17, 12 October 2021 (UTC)

    @

    WP:ACE2021. What I do know is that I've explained what the MCDC is and why people should care and how to vote and find out info to a dozen Wikipedians, all generally well informed, who tried to read the meta pages and couldn't understand what the MC would be, so we need some kind of local page. KevinL (aka L235 · t · c

    ) 14:43, 12 October 2021 (UTC)

    I'm currently working on a page to show candidate's basic stances on the compass questions in a simple table format, but it is taking a while given the sheer numberJackattack1597 (talk) 22:00, 12 October 2021 (UTC)

  • FWIW, I've prepped a WLN at MediaWiki_talk:Watchlist-messages#Movement_Charter/Drafting_Committee/Elections. — xaosflux ^Talk 11:08, 12 October 2021 (UTC)
  • If this global initiative is something that needs the level of advertisement as sending talk pages to every eligible voter, that should be requested upstream, of all WMF projects I'm not aware of any others doing something like that. While this seems important, it doesn't seem to be at the point of some sort of extinction level event for the English Wikipedia. — xaosflux ^Talk 10:51, 13 October 2021 (UTC)
• Do 2 and 3 (right away), neutral on 1. In a situation like this, the RfC should run about 30 minutes. The ArbCom messages are kind of irritating, but at least I know what an ArbCom is; I fear I am the only Wikipedian who had never heard of the Wikimedia Movement, a Movement Charter, and did not know we needed to draft one and were going to have elections for it. Now I have to weigh the three candidates whose names I even recognize against the other 69 people. My point: I am dubious as to how much acceptance editors will have for a MassMessage about something they've never heard of. Or maybe I'm the only ignorant one here. — JohnFromPinckney (talk / edits) 12:12, 12 October 2021 (UTC) Edited: apparently there are 72 candidates. — JohnFromPinckney (talk / edits) 12:16, 12 October 2021 (UTC)
• Confusion I just quickly read Wikipedia:2021 Movement Charter Drafting Committee Election, meta:Movement Charter and meta:Global Council and I don't really have the slightest idea what this election is about or in what way it would affect the English Wikipedia (or any other Wikipedia). Well, I get it is essentially about meta:Movement Charter, but what effect this "charter" will have/is supposed to have on the project (EN Wikipedia) is not readily clear to me. I wish someone who understands could write up a quick overview on the immediate effects this would have on EN Wikipedia. Toshio Yamaguchi (talk) 13:58, 12 October 2021 (UTC)

  @Toshio Yamaguchi: This question is precisely the most important reason to have a local discussion and info page. The short answer is, the Movement Charter will regulate how all future changes to the Wikimedia movement will occur. It will constitute a "Global Council" (m:Global Council) with the authority to represent the global movement to the Foundation; depending on what the MCDC writes, it could also have a budget, staff, lawyers, power to adopt binding global policy and overrule local projects, the ability to consent to changes to WMF-project relations going forward, etc. Essentially, it will be a GovCom for the entire global Wikimedia movement, and the MCDC is in charge of saying how it will be formed: whether it will be elected or appointed (or a mix), what diversity requirements there will be, what voice each project will have in selecting it, what powers it will have, etc. Enwiki is likely to have a fairly small share of the seats on the council. I hope this helps – and if you can help translate that into a concise statement of why this is important, please BOLDly edit Wikipedia:2021 Movement Charter Drafting Committee Election to say so. Best, KevinL (aka L235 · t · c) 14:31, 12 October 2021 (UTC)

@L235: that's actually a really clear and concise summary. I'd encourage you to add it to that page! The Land (talk) 18:11, 12 October 2021 (UTC)

• Notice WMF has placed an update on this here: Wikipedia:Village_pump_(miscellaneous)#Voting_to_elect_members_for_the_Movement_Charter_drafting_committee_is_now_open. — xaosflux ^Talk 17:17, 12 October 2021 (UTC)
• So: Definitely 2. Probably 3. Neutral on 1, but that's getting more support than I expected so far. Regarding a local info page - anything that demystifies what the whole thing is for the English Wikipedia audience would be a good move. The Meta documentation has improved a bit during the course of today, but there's much more to do on that. Happy to contribute to that (albeit, I'm somewhat limited in what I can say as I'm one of the candidates). Regards, The Land (talk) 18:08, 12 October 2021 (UTC)
• Support all three, more communication is definitely a good thing.Jackattack1597 (talk) 18:49, 12 October 2021 (UTC)
• Oppose mass message please don't flood my notifications when we already have a site banner. Support watchlist notice, neutral on local page though if someone wants to maintain it, more power to you. — Wug·a·po·des​ 20:57, 12 October 2021 (UTC)

  @Wugapodes: Hm, I would argue that a mass message does better than a site banner to (1) overcome banner blindness, (2) link to the local info page and/or 5-minute-guide page to emphasize the importance of the election (surely as or more important than ArbCom elections), and (3) send emails to those with that enabled. Best, KevinL (aka L235 · t · c) 02:56, 13 October 2021 (UTC)

  @L235: I think you overestimate how many people care to read through 70-odd statements from people they don't know for a position on a committee they've never heard of. While I obviously agree about the importance of the meta election, simply being important doesnt imo justify tens of thousands of notifications that are redundant with information in two other prominent locations. I skimmed my user talk history and I don't think I ever got a mass message about Board elections despite that being far more important and easier to understand. The way to combat banner blindness is to design better banners, not bludgeon people with information about things they already chose to ignore or participate in. Not everyone is interested or cares about what happens on meta, and those who do have numerous ways of finding out. For all the talk of banner blindness, you forget that constant useless mass messaging risks people opting out of mass messaging in general. We already send out tons of ACE mass messages, and there are almost 5,000 editors who opt out of mass message delivery. It's easy to fix banners, it's hard to get people to resubscribe to mass messages. Besides, if someone is so disconnected from the goings-on of enWiki that they missed a central notice and watchlist banner for weeks then I doubt a talk page message and email are going to be what spurs them to read almost four score nominations for a committee they probably haven't heard about. I just don't see the value in flooding watch lists, talk pages, and email inboxes with information already widely available for an election of niche interest to most people. Is it important? Sure, but that's why we have a banner at the top of every page. — Wug·a·po·des​ 18:01, 13 October 2021 (UTC)

• WP:BOLDly in light of the discussion above. Mz7 (talk
  ) 02:54, 13 October 2021 (UTC)
• Note: options 2 and 3 are already done - so unless someone wants to argue to UNDO them, this is really just about #1 now. While shorter than 30 days seems OK, before running and sending huge numbers of talk messages, I think this should be at the least "very well attended" for that part. — xaosflux ^Talk 10:42, 13 October 2021 (UTC)

  @Xaosflux: I have been watching this conversation, and talked briefly with Mz7 before he implemented the watchlist notice confirming that I saw consensus for it. I agree with you that per our polices, guidelines, and procedures, we do not necessarily have to wait 30 days to find consensus, especially in this case, but given the magnitude of the impact, more editor participation will be required. Best, Barkeep49 (talk) 00:40, 14 October 2021 (UTC)

• Support all 3, this may be the most important election in Wikimedia history The stakes of this election include great influence on some percentage of Wikimedia donations. This Movement Charter is going to be a governance document lasting at least 10 years, and in that time, the Wikimedia Foundation will collect about US$1 billion in donations to the Wikimedia community. This governance document could direct allocations of anywhere between 10-70% percent of that. Conservatively, I think at minimum this document will send $100,000,000 within 10 years to causes, purposes, people, and places which previously were never considered or in discussion for getting funding. This is a really big deal. This situation and notice is a candidate for doing more communication in more channels than we ever have for any other community notice previously. However, this election is only part of this, and we might want to direct people's attention to a landing page for the part which comes immediately after and is just as impactful. After we elect these drafters, while they are writing the Movement Charter, anyone in the Wikimedia community can post comments to them on talk pages. Think of this like the United States Bill of Rights. If someone suggests text for the drafters to include, then they may put that in the Charter which would make it a Wikimedia Movement constitutional right. Beyond voting for drafters, people should be getting ready to give comments to the elected drafters. Blue Rasberry (talk) 00:24, 15 October 2021 (UTC)
• Oppose 1, but Support 2 and 3. 1 strikes me as unnecessary and redundant to it being listed on
  WP:CENT. OhKayeSierra (talk
  ) 00:49, 15 October 2021 (UTC))
• (Disclosure: Am candidate.) There are 17 hours remaining in the election. Probably time to close this, one way or another? --Yair rand (talk) 18:52, 24 October 2021 (UTC)
• I've removed the RFC banner. This discussion is OBE at this point, namely the end of the vote. --IznoPublic (talk) 18:59, 25 October 2021 (UTC)

We need a new |url-status= value, something like live paywall escape, for when the original url is live and behind a paywall and the archive-url is not behind a paywall. In this situation, with the markup |url-status=live, the link will be to a less desirable source for most readers, but |url-status=dead would not be true. —Anomalocaris (talk) 06:20, 29 October 2021 (UTC)

Should we really be purposefully encourag ing links to bypass the source's website to a paywall bypass? I mean it's one thing to have a source link and an archive link, it's another to have a source link and a ---> CLICK HERE TO BYPASS PAYWALL <-- (in icon form). ProcrastinatingReader (talk) 12:33, 29 October 2021 (UTC)

I think we should do so if and only if the alternative is legal. Do we have any proper legal advice on this? Some of us are used to circumventing links from Wikipedia's DOIs, which often point to a greedy publisher when there are free legal alternative sources such as the author's university. Certes (talk) 12:40, 29 October 2021 (UTC)

I often cite articles from a journal that is included in JSTOR (not a problem for me, as I have a personal account), but is also free-access fron a university site. I recall an editor removing the free-access url entry from a citation because I had included the JSTOR ID. Related to this is the availability of free access to draft versions of articles, with the final, published, version behind a paywall. It is nice to be able to read the draft, but I do not know what changed in the official published version. I have also cited an article from Nature that was available through the university of the principal author, until it was taken down (I expect that Nature is very protective of material it holds copyright to). So, there is always the possibility that the non-paywall source may be taken down because of a publisher exerting its copyright. Overall, though, I think we ought to be doing everything we can to link readers to free-access sites for sources, as long as we are reasonably certain that copyright is not being violated. - Donald Albury 18:11, 29 October 2021 (UTC)

• As a technical note, this is probably more appropriate for |url-access= than |url-status=. {{u|Sdkb}} ^talk 20:34, 29 October 2021 (UTC)
• I think there's an ethical dimension to this moreso than a legal one. Wikipedia depends on high-quality sources, and producing quality journalism isn't free. If a struggling newspaper has chosen to put up a paywall as their response to the dire situation of the industry, I'm not sure we should make it so easy for readers to get around it that they're not even alerted to the fact the source is asking for a contribution. For anyone who really needs the info, the archive link will still be there, making it pretty easy to get around the paywall. {{u|Sdkb}} ^talk 20:34, 29 October 2021 (UTC)

  There's a difference between The Guardian researching and writing a story then making it available to all with a polite request for donations, and Elsevier locking away a research paper to which their only contribution is web hosting. Certes (talk) 20:48, 29 October 2021 (UTC)

  There are absolutely publishers that charge outrageous prices, but trying to determine what's a "valid" paywall and what's not is way beyond the appropriate scope for us. {{u|Sdkb}} ^talk 21:09, 29 October 2021 (UTC)

• IMO we should not be in the overtly stated business of bypassing paywalls. -- GreenC 20:44, 29 October 2021 (UTC)
• The more ethical, less user friendly option would be to always defer to the archive over live version. That would be the equivalent of providing the source as it was when the editor sourced the content. Slywriter (talk) 21:25, 29 October 2021 (UTC)

Its a "Phab as old as time" T75299: implementing topicons into the mobile skin. As more and more of our readership becomes mobile, fewer and fewer of our readers can understand when a page is truly quality or not. The significant time and effort we put into GA and FA articles becomes unappreciated. There was some spirited discussion on the Phab last year, and no obvious solution. We need a coder who can suggest a technical solution and a community consensus as to how topicons should be placed (if at all). Alternatively, we need to rethink how we present topicons in general. Thus: I would appreciate brainstorming how to fix our presentation of GA/FA status so that mobile readers can see it too. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:33, 29 October 2021 (UTC)

• I've been pushing to get that phab ticket addressed, and it seemed to be making progress in March but then it trailed off. It's definitely extremely important, but I'm not sure how much brainstorming there is left to do—what it needs is just some attention from the WMF to get it implemented. {{u|Sdkb}} ^talk 21:44, 29 October 2021 (UTC)
• As someone who edits about as much from my phone as from my PC (especially when needing to use vpn for my pc) any and all improvements to mobile use would be really really appreciated. Although not part of your suggestion, has there been discussion recently on ways to show talk page banners (such as coi/paid disclosures, sanction alerts, or other highly important ones)?
  Talk
  23:40, 3 November 2021 (UTC)

Hi, I recently write a bot to create article lists in other languages. The bot is running in jawiki and zhwiki now, you may see the result, the bot will create a list for every language like this. How about enhancing Wikipedia:Featured articles in other languages like this? Kanashimi (talk) 03:40, 20 October 2021 (UTC)

That page is marked historical, so if you can revive it with a bot, please do! {{u|Sdkb}} ^talk 00:56, 21 October 2021 (UTC)

Thank you. Now preparing... Kanashimi (talk) 11:31, 21 October 2021 (UTC)

@

WP:BRFA. — xaosflux ^Talk

11:36, 21 October 2021 (UTC)

Ok. I will wait for some days if there are other opinions. Kanashimi (talk) 11:41, 21 October 2021 (UTC)

Sure! If you bot will only being updating 1 page (for now at least) it should have no problem getting approved. You are also welcome to do low-volume testing in your bot's own userpage (e.g. User:Bot/SampleReport). Having an example is a good way to demonstrate. — xaosflux ^Talk 11:50, 21 October 2021 (UTC)

(edit conflict) Maybe we can discuss related issues about this task here, so that we do not need to open a BRFA but find that it is worthless, does not meet the requirements, or does not feasible at last. Kanashimi (talk) 11:53, 21 October 2021 (UTC)

@Sdkb@Xaosflux I have generate a list of Afrikaans in Wikipedia:Featured articles in other languages/Afrikaans. May you help me to see if there are problems? Thank you. Kanashimi (talk) 05:02, 22 October 2021 (UTC)

You might want to replace the 、 separator by something more common in English, like a standard semicolon or a centred dot. You'll also need some explanation (tick mark and green background means the article exists etc.) Other than that it looks good to me. —Kusma (talk) 06:34, 27 October 2021 (UTC)

Oh yes, I forget this. Now fixed, please give some feedback, thank you. Kanashimi (talk) 09:13, 27 October 2021 (UTC)

@Kanashimi, that is feedback. ― Qwerfjkltalk 09:36, 27 October 2021 (UTC)

Some more comments or it looks good now? Kanashimi (talk) 09:40, 27 October 2021 (UTC)

Looks much better. Making Wikipedia:Featured articles in other languages/header an editable subpage is a great choice and allows others to further improve the descriptions. —Kusma (talk) 09:45, 27 October 2021 (UTC)

Thank you. :) Kanashimi (talk) 10:01, 27 October 2021 (UTC)

I do not understand what is meant by "article with the same name" at Wikipedia:Featured articles in other languages/Afrikaans. "No article" or "article does not exist" is clear enough, but not the "same name" thing. — JohnFromPinckney (talk / edits) 13:11, 27 October 2021 (UTC)

If you ask me, the color coding + ✓ or ✗ before each entry is self-explanatory enough to ditch the legend altogether. AngryHarpy‍^talk 14:12, 27 October 2021 (UTC)

Thank you for the comments. @JohnFromPinckney It means "the article title is the same with wikidata label". I have changed the commentary and hope this will help. @AngryHarpy It is for sort. I will remove the color so it will only have this function. Kanashimi (talk) 17:50, 27 October 2021 (UTC)

Ah. So for the ✗ red cells under Articles in English, if there's a red-linked title that matches the Afrikaans title, it means the English article doesn't exist, and if there's a blue-linked matching title, it's a link to an en-WP dab page with that name. If there's a different name in that column it means that there is an en-WP article corresponding to the Afrikaans subject, but it's got a different title. And in any case, ✗ red cells with a {{d:Q12345678}} link to a Wikidata item that has some connection to the Afrikaans article (even if it's not named the same).

Have I got all of that right?

And the Languages column shows how many Wikipedias have an article on that topic (although the number doesn't seem to match in the articles "languages" list). Yes? — JohnFromPinckney (talk / edits) 07:41, 28 October 2021 (UTC)

Oh, yes you got it! I hope someone adding more explanation so everyone will understand the meaning. Kanashimi (talk) 08:04, 28 October 2021 (UTC)

Cool. I am trying out some edits of the /header page right now, in the hopes of making things clearer. Which brings me to another question:

The first column is labelled "#" but not otherwise explained. Do the numbers in this column have some specific meaning? Do you expect them to be of some use to editors sorting on other columns? To me, it appears that this is just a semi-coincidental ranking based on a sorting by "Languages" (and which is arbitrary when, say, 5 articles all have the same number of articles there). So: can we do without this column? (It would save having to explain it, among other things.) — JohnFromPinckney (talk / edits) 11:03, 28 October 2021 (UTC)

Yes, the "#" field is basically sorting by "Languages". If there are two rows with the same "Languages", then they will sort by "Articles in English", this is the major different. You may click on the header of "Languages" to sort by "Languages", and should see the "#" field is not continuously. Kanashimi (talk) 11:28, 28 October 2021 (UTC)

Okay, have a look, please, at this edit. I hope it makes some of the details clearer; in any case, it provides a bit of an introduction to the /whateverlanguage page. Feedback welcome. — JohnFromPinckney (talk / edits) 12:29, 28 October 2021 (UTC)

Good! Thank very much! Kanashimi (talk) 13:09, 28 October 2021 (UTC)

I would advise that you omit any reference to Wikidata. A LOT of editors here at WP.en are not big fans of that particular project. Blueboar (talk) 21:29, 27 October 2021 (UTC)

Well, this is really a problem. I can remove links to Wikidata, but there will be nothing left for the foreign articles without wikidata label. Would this be more beneficial? Kanashimi (talk) 22:04, 27 October 2021 (UTC)

Just wanted you to know that including WD links IS a problem… better that you know that before you spend lots of time on them. Blueboar (talk) 12:46, 28 October 2021 (UTC)

Thank you for your advice. Kanashimi (talk) 13:10, 28 October 2021 (UTC)

Including WD links in mainspace is certainly controversial, but there's absolutely no need to avoid linking WD in project pages. – SD0001 (talk) 07:43, 10 November 2021 (UTC)

~@Kanashimi: Your page for Afrikaans looks great! If you are planning to run this bot for other wikis, maybe Wikipedia:Featured articles in other languages can be archived somehow, to make place for newly updated data? Artem.G (talk) 19:16, 2 November 2021 (UTC)

Yes, I am planning to run for other wikis. In the end Wikipedia:Featured articles in other languages should looks like ja:Wikipedia:諸言語版の秀逸な記事 or zh:Wikipedia:其他语言的维基百科典范条目. Kanashimi (talk) 21:48, 2 November 2021 (UTC)

BRFA filed --Kanashimi (talk) 06:25, 10 November 2021 (UTC)