Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Get rid of stub tags

I know this is a bold proposal, and is likely to be controversial, but stub tags aren't useful. They don't get people to edit stub articles, which is their stated purpose. They do have a number of negatives: They often remain in articles long after they has been brought up to Start-class and higher. They conflict with the classes stated on talk page banners, which are often more up-to-date. They add a useless image and clutter to the articles. It's time to begin to think about eliminating them. For those people who might be feeling reticent, perhaps an experiment should be run where stub tags are removed from a random subset of articles, then they are compared in, say, one year's time, to a subset of similar articles and measured for levels of (destubifying) improvements. Any thoughts? Abductive (reasoning) 00:35, 21 June 2020 (UTC)

I think you have actually identified two distinct issues here: 1) we don't have any evidence that stub tags are achieving their stated purpose, and 2) stub tags are conflicting with WikiProject assessments. For #1, I think an experiment could yield from interesting results. For #2, I think this would make a nice bot task to remove stub tags when a WikiProject assessment is upgraded from stub. It might be worth upgrading {{WPBannerMeta}} to generate a reassess flag for the bot to add when a stub tag is removed, but a WikiProject still has it assessed as a stub. For the experiment on #1, I would suggest:

1. Get a list of something like 10,000 random articles, and remove any that are not assessed as a stub by WikiProjects, or have neither a stub tag nor a WikiProject banner on its talk page.
2. Do an assessment of the remaining articles and remove any that aren't actually stubs.
3. Split WikiProject claimed articles by stub-tagged or not, and remove/add stub tags to get each WikiProject's article count roughly even (shoot for at least 1/3 of each). Remove stub tags from the unclaimed articles to even out the total count, again going no less than 1/3 for either group.
4. For the two groups, drop the top and bottom (quartile? ⅒th?) in terms of edit size, ignoring any bot edits, and compare the two groups by interest (number of edits by unique editors), engagement (number of non-revert, non-patrolling edits by registered editors), and overall article change (total prose added to article during experiment run time). VanIsaac_WS^cont 14:17, 21 June 2020 (UTC)

Thanks for your input. Abductive (reasoning) 23:07, 21 June 2020 (UTC)

• Oppose The OP doesn't present any evidence to support the proposal. Me, I'd rather eliminate project templates and assessments as I've never seen these do any good and they tend to stick around for longer. The stub templates are comparatively unobtrusive and have an encouraging and pleasant tone. Andrew🐉(talk) 22:47, 21 June 2020 (UTC)

So, I present no evidence, then you say talk page assessments don't do any good, and also present no evidence. Abductive (reasoning) 23:07, 21 June 2020 (UTC)

This is not my proposal and so it's not my responsibility to be providing evidence. But here's a couple of examples – both being articles that I created recently. Firstly, consider Ambarnaya. I created this with the {{river-stub}} tag. User:Catan0nymous added two more stub tags: {{Russia-stub}}, {{Siberia-stub}} and user:Abune then consolidated the stubs into {{Russia-river-stub}} and {{Siberia-stub}}. These tags seem to have three functions:

1. Placing the article into the categories: Category:Siberia geography stubs and Category:Russia river stubs
2. Displaying some appropriate icons -- maps of Russia and Siberia
3. Advising the reader that the article is just a start and inviting them to help expand it

My second example is List of longest-running radio programmes. In that case, I started out with the {{under construction}} tag because the page needed a good structure as a foundation and I wasn't sure what would be best. Once that was done, I removed the tag. By that time, the list structure was established and I used the {{dynamic list}} tag to indicated that the list was quite open-ended. That tag also invites the reader to add sourced entries and so I didn't see the need for a stub tag too.

Neither of these cases indicate that stub tags are a problem that needs fixing. Sensible editors use them as they see fit and they don't seem to cause any trouble. One feature which helps is that, by convention, they are placed of the foot of an article, where they don't get in the way.

Andrew🐉(talk) 08:00, 22 June 2020 (UTC)

• Andrew Davidson, I agree with the assessment system. It's absurd. Articles can be Stub, Start, C, B, GA, A, or FA. That's seven levels, which is absurd. The gradations are way to small, and the assessment criteria way to subjective. Class A articles are "Very useful to readers", but GA are, "Useful to nearly all readers". That's absurd. -- RoySmith (talk) 02:15, 22 June 2020 (UTC)

  The minimum acceptable standard for an article on the front page at ITN, OTD or DYK is effectively B class due to the requirement that they be fully referenced (the same goes for the de-stubathons), although we can't state that explicitly because B class ratings are in the hands of the projects. GA and FA are community assessments. B class articles are generally capable of becoming GA, but there is little incentive to submit them for review (GA is already backlogged enough), unless you are seeking to take it to DYK, FA or FT. Similarly, A class articles are generally capable of becoming FA after a review, but most cannot because each editor is limited in the number that can be submitted. So we have three categories (stub, start and C) for poor quality articles. The differences between them are fairly objective, but the value of the distinction is questionable. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

• Comment I doubt the suggested experiment would produce any clear results frankly. People are often reluctant to remove stub tags, or simply don't notice them. The wikiproject tags are just as prone to under-rate as the ones on the article in my experience. What might be more useful is a list of articles tagged as stubs where the article is over a certain size (not sure what). Reviewing these would I expect show most can be removed. Of course people still have to do this. Johnbod (talk) 23:59, 21 June 2020 (UTC)

• • The issue isn't so much as picking the certain size, it's defining what size is. The easy way out is to count the characters of wikitext, and you end up with quarry:query/46032. But plenty of those only have a half dozen or fewer sentences, despite their absolute length. —Cryptic 01:22, 22 June 2020 (UTC)

Like Negombo_Polling_Division - but that has massive tables, no doubt like the other Sri Lankan electoral districts, & certainly isn't a stub. In fact I'm pretty sure most of these are mainly tables. But thanks. Johnbod (talk) 02:44, 22 June 2020 (UTC)

• Do you know of any utilities for querying the size of the prose text? VanIsaac_WS^cont 02:06, 22 June 2020 (UTC)

• https://www.mediawiki.org/wiki/ORES articlequality is not bad at all. I think it guesses based on discounting common words and repeated words, which is often a feature of lists and tables. Abductive (reasoning) 04:07, 22 June 2020 (UTC)

  I'm not sure how it works, but the MilHist Project has been using it with considerable success over the last few months to assess unassessed or incompletely assessed articles. Articles that are auto-assessed as B class are flagged for human review. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

Considering I've run contests with over 1000 articles destubbed directly from stub categories like WP:The African Destubathon and Wikipedia:The Great Britain/Ireland Destubathon and am running Wikipedia:The 50,000 Challenge which directly feeds off stub tags this is one of the dumbest, most ignorant proposals I've seen for some time and that's saying something!! There is an issue with updating the project tags once an article is no longer a stub and stub tags remaining in articles not stubs but that's hardly a reason to get rid of them entirely. Rosiestep and myself proposed a bot to sort that out but the Wikipedia community being the divided way they are wouldn't get us the consensus we need to sort it out.† Encyclopædius 08:19, 22 June 2020 (UTC)

I don't see why, User:Encyclopædius. I won some sort of prize in one of your excellent contests, but when looking for articles to improve, I remember just removing the stub tag on about five for every one that actually was a stub. I don't agree with complete abolition, but they are in a serious mess & should be sorted out. Johnbod (talk) 13:58, 22 June 2020 (UTC)

Yup, and can you believe when I proposed a bot to control the inconsistency and remove stub tags from articles with over 1.5 kb readable prose and update the talk page tags some people opposed? Andrew Davidson for a start. † Encyclopædius 14:04, 22 June 2020 (UTC)

Can a bot at least go around and remove stub tags from all really huge articles that have talk page templates that claim Start-class or above? Then maybe work its way down to smaller articles until it on the verge of making errors? Abductive (reasoning) 04:18, 24 June 2020 (UTC)

Yes. In fact, the MilHistBot is already capable of carrying out this task. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

• "stubs" help navigate articles that need attention. They typically are located at the very bottom of article and do not interfere with regular reader who has no intention to improve article. Basically nothing is wrong with "stubs" as far as I'm concerned. User:Abune (talk) 13:04, 22 June 2020 (UTC)

Very true, User:Abune. Readers rarely notice them, and even if they do, it is hard to see that they have any negative impact. Some editors find them useful. What's the problem? (A: there isn't one). Edwardx (talk) 14:34, 22 June 2020 (UTC)

• Qualified support. I generally agree with the issues raised by the proposer. Stub tags are not particularly aesthetically pleasing, and do tend to linger after the article has been expanded to the point where they are no longer appropriate. Efforts to just find and remove them at that point become busywork. I am wondering if there is some template magic that can be applied so that stub tags on articles that are likely not stubs can turn invisible, and just show up as categories. BD2412 T 15:11, 22 June 2020 (UTC)

@BD2412: no problem: Template magic. 10000 might be a tad much. Also you'd have to make all stub templates pass the forcestub parameter in order to be able to force the stub template on articles longer than 10000 bytes. - Alexis Jazz 01:16, 21 July 2020 (UTC)

• Simpler solution: If you come across an article that you think is no longer a stub... remove the tag. Problem solved. Blueboar (talk) 15:19, 22 June 2020 (UTC)

Not really - pretty much no one who would know how to do this ever looks at these articles, all xxx,xxx of them (what is the number, does anyone know?). Johnbod (talk) 21:44, 22 June 2020 (UTC)

There are 3,399,601 stubs as of now. You can see the stats here. TryKid ^{[dubious – discuss]} 23:28, 22 June 2020 (UTC)

Yikes! Over half our articles. These are project ratings though. I see 4,310 "top importance" stubs! Thanks, Johnbod (talk) 01:28, 23 June 2020 (UTC)

I'd like to see one of those top importance stubs. To make a start I followed TryKid's link to find Category:Stub-Class_articles. From this, I selected Category:Stub-Class Accounting articles because there is a systemic bias against business articles. Accounting standard looked promising and I found that this is assessed as High importance but Stub class. This is all coming from the project template as the article page doesn't have any tags. It could use some because I immediately noticed a blatant howler, "Accounting standards were largely written in the early 21st century." What I also notice is that while its talk page only had 7 readers in the last 30 days, the article itself had 2,481. I could now tag-bomb the article but what it really needs is improvement... Andrew🐉(talk) 08:55, 23 June 2020 (UTC)

Yeah, 3M project rating stubs. The number of "tagged" stubs seems to be 2,265,086, from Category:All stub articles. This number looks more correct since many of the "top importance stubs" aren't stubs anymore and are already detagged but the talk page wasn't updated. As previously pointed out, even many of the "tagged" stubs aren't stubs. Maybe a bot that automatically upgrades project rating of stubs to "start" if a tag isn't found on the main page is needed. Blofeld's idea of automatic detagging if the article is above a certain size was also good. TryKid ^{[dubious – discuss]} 12:59, 23 June 2020 (UTC)

• Support In my early (2005) days, stub-sorting was one of my favorite hobbies, and it saddens me to finally deprecate the stub templates, but nowadays they are duplicative of the assessment templates on the talk page and thus unnecessary. -- King of ♥ ♦ ♣ ♠ 01:58, 23 June 2020 (UTC)
• Possible alternative, I lean towards oppose but perhaps we could link the stub tags to the WikiProject banner, if the article is assessed as a Stub class a bot adds the tag, if (hopefully when) the article is upgraded to Start or higher a bot removes the tag. Cavalryman (talk) 02:19, 23 June 2020 (UTC).
  • This is a very good idea. It fixes the discrepancy between main page and talk, while keeping some level of friendly encouragement at the main page. - Nabla (talk) 14:52, 27 June 2020 (UTC)
• Oppose While I agree that many of the problems you listed are real and affect Wikipedia, stub tags are necessary. They may not be very effective at getting readers/editors to add content to or destubify articles, but they make a vital contrast between what is and is not a reasonable length for an encyclopedic article. Most readers don’t care to browse Wikipedia’s myriad informational pages on article length, the different classes, prose, etc. Stub tags are simple, easily understood, and to-the-point. If we’re going to get rid of stub tags, why not just get rid of the stub classification altogether? It doesn't make sense. Improvements should be made, but we need them. Their importance to the project overrides any negative aspects. MrSwagger21 (talk) 02:26, 23 June 2020 (UTC)
• Oppose per MrSwagger21. - ZLEA _T\^C 02:52, 23 June 2020 (UTC)
• Comment on balancing editor and reader needs. Regarding editor needs (which we always tend to overprioritize, given the systemic bias introduced by who we are), my takeaway here is that it seems there's no evidence that the tags draw editors, and while it's perfectly plausible they do, this might be a good thing for someone to do a research study on. Regarding reader needs (which I don't see really getting proper attention here), the way we indicate article quality is a little quirky — we indicate GA/FA with a topicon, but stubs with a tag at the bottom, and nothing in between. I think there's a reasonable case to be made that stubs, given their low quality, ought to have the tags as a sort of warning. The counterargument would be WP:NODISCLAIMERS and the fact that there's a distinction between low quality and just short, and most stubs in my anecdotal experience are not lower quality than start/C class pages, just shorter. I'm not sure where I land on the necessity of stub tags, but I hope we'll consider how they impact the experience of non-editing readers, not just editors. I have brought up before that there is room for improvement in how we present content assessments to readers more generally (particularly, the difference between GAs and FAs is not made clear), and I'd like to see more work in that area. {{u|Sdkb}} ^talk 07:53, 23 June 2020 (UTC)
• Oppose no. They are helpful and low-key. Not in anybody's way. Regards, GenQuest ^{"Talk to Me"} 10:47, 23 June 2020 (UTC)
• Comment: sorry for the somewhat self-promo, but this is something that could hopefully be done with relatively little consternation were my proposal for an extension that adds categories from tags on the talk page successful. Such a move would allow the pages to retain the stub categories, without the duplication of effort in tagging the article with stub tags and also doing the assessments on the talk page. Naypta ☺ | ✉ talk page | 13:07, 23 June 2020 (UTC)
• weak oppose for now - People I talk to (non editors) are often not aware a talk page even exists for an article. If a stub tag encourages the occasional person to add content then I see that as a Good Thing. If there were some way of showing that there was no evidence that this occurs, then I'd support their deprecation. I should add that the proposal was worth bringing up and I did consider supporting, and I do think the topic is worth exploring. Cas Liber (talk · contribs) 04:54, 24 June 2020 (UTC)
• Conditional support. Stub templates are messy and outdated, and does not do what they are supposed to do, although they have other important uses. I suggest removing the templates, but replacing them with categories or a function within WikiProject banners. Rehman 05:21, 24 June 2020 (UTC)
• Support - simplification is good. What stubs do can/is/should be done in a talk page banner, e.g. wikiproject assessments. Bottom line is we should have one place where we record what state an article is in, and that one place should probably be in a talk page banner. Levivich ^{[dubious – discuss]} 19:26, 26 June 2020 (UTC)
• Oppose per Cas Liber. Stub tags are at worst benign. They're the literal bottom of the article and if a reader wants to ignore it, they can. I really can't understand how they can be seen as harmful. On the other hand, if they get 1 reader to help expand an article, the encyclopedia benefits greatly at pretty much no cost. They're a clear net positive. Putting them on the talk page may be convenient for us and our internal categorizations, but that's counterproductive for article improvement. Most people don't know about talk pages (seriously, ask your friends the last time they looked at an article talk page), so hiding the stub tags where only insiders will find them is in my mind a net negative. — Wug·a·po·des​ 21:37, 27 June 2020 (UTC)
• Oppose. Stub templates are a type of maintenance template. Because of their ubiquity, we've decided to put them at the bottom instead of the top of the page. They share all the pros and cons of other maintenance templates. One one hand, we think that – given the dynamic nature of Wikipedia – we should alert readers and editors if something is not right with an article. On the other hand, we don't know if more time is spent tagging or actually fixing articles. The main problem I see with stub templates is what others have pointed above. We have two systems to mark an artcle as a stub: stub templates and talk page banners. These are not always in synch. When this happens, the fault is with the editor who (de)stubs an article using only one method. The guideline at WP:DESTUB says to do it using both. I'm sure we're moving toward automatic article assesment (WP:ORES) at some pace. In the meantime, we should automatize getting rid of the discrepancies between stub templates and talk page assesments using a bot. – Finnusertop (talk ⋅ contribs) 23:20, 27 June 2020 (UTC)

"we don't know if more time is spent tagging or actually fixing articles" Probably the first one, in my considered opinion. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC)

*Support A good solution, as already proposed by others, would be for categorisation via wikiproject banners on the talk page. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC) Striking sockpuppet.P-K3 (talk) 22:47, 8 July 2020 (UTC)

• Oppose I'm not joking in saying that this is normally how I find GAs to write. Stub tags are invaluable. TonyBallioni (talk) 02:17, 6 July 2020 (UTC)
• Oppose I hate creating articles (for some reason), I don't think I've created an article yet. I do help massively improve existing articles, and have plans to edit a couple of stub articles and make them more full. Stubs have their benefits, help find topics that may look interesting, and give one a chance to expand them. Also, what Tony said above. ProcrastinatingReader (talk) 12:23, 6 July 2020 (UTC)
• Comments: Leaning toward oppose, as the WikiProject placement on Talk pages make them less obvious to readers and editors, to the point that I tend to forget about them. I would also to interested to know:
  • Do all stub categories have associated WikiProjects?
  • Is if there an easy way to get a list of articles pages (as opposed to the talk pages; c.f. Category:Stub-Class video game articles to Category:Video game stubs) from the WikiProject categories?
  • Could WikiProject stubs be organized into subcategories like the stub templates?
• —Ost (talk) 22:27, 9 July 2020 (UTC)
• Weak Conditional support. As per @Rehman above. However, few editors may still use those stub templates. If they were at the top, maybe it would be diffwerent, but I say drop them and go with what Rehman said above. --Guitarist28 (talk) 14:32, 14 July 2020 (UTC)
• Oppose removal. I think the format of the tag should be changed, though. I am coming from the perspective of a wikiHowian, where stub tags are placed on top of stub articles. I think it would be more useful if the stub tag was in the form of other maintenance templates. Something like:
  
  That way, readers see what they can do to help Wikipedia. By having them at the top, readers can work on expanding the article, and then remove the stub tag once the article provides more coverage. Aasim 08:06, 18 July 2020 (UTC)

  Awesome Aasim, I like the idea of a more clear tag, although it should be ambiguous that it isn't a major issue with the article itself, and should actually encourage people to build the page, like:
  

  Ed6767 talk! 00:21, 21 July 2020 (UTC)

• Comment One badly needed step would be to go thru all of these stubs & verify that they are, in fact, stubs. In my own browsing thru articles I've found that a quarter should be re-graded to "Start" or better. And about 1 in 10 of the "Start" class should be regraded as "C" or better. (Since my experience is at odds with Johnbod above, maybe my evaluation is more strict than his?) In any case, I figure re-evaluating as many stubs as possible would help reduce the number of stubs in Wikipedia to less than half the total number. --llywrch (talk) 21:52, 20 July 2020 (UTC)

  There are two types of articles here: (1) articles that have already been re-graded as start or higher, but still have Category:Stub message templates on them; and (2) articles that are classed as stubs, but really are start or higher. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

  Possibly, or we're looking at different articles. I feel most assessors pretty much only take length into account, whereas for some subjects a few lines might be C or even higher. The official definitions for the classes are actually pretty generous, & I think most assessors are rather too strict (as well as judging mainly on length). Johnbod (talk) 00:08, 21 July 2020 (UTC)

  Responding to both comments together. Hawkeye7 the first case could easily be addressed with a bot -- & probably needs to be done in any case -- while the second describes the phenomenon I was talking about. Johnbod I suspect we might be looking at different articles, or groups of articles. When calling an article a "stub", I look more to how completely the article covers the topic than the length -- there are some notable historical personages about whom all we can write is limited to 2 or 3 sentences, which means we are stuck with what I call a "permastub" -- although if an article is, say, 5,000 bytes in size & marked as a "stub", I'm going to look hard at why it has that assessment instead of a "start" or "C" class. And sometimes it requires expert knowledge to know what information is available about a given topic, in order to know if the article completely covers it. -- llywrch (talk) 16:55, 21 July 2020 (UTC)

  Ah, perhaps different standards then - I stand with User:Grutness/Croughton-London rule of stubs, and indeed the official definition, though of course "the breadth of coverage expected from an encyclopedia" (which stubs lack) is wonderfully vague. But most articles in most print encyclopedias would be called "stubs" by most WP assessors imo. Johnbod (talk) 17:23, 21 July 2020 (UTC)

• While I support the idea, there are a few things we should consider:

1. The public. Stub came to have meaning outside the editing community: The list gradually changing colour on Haskell's screen represented hundreds of women scientists who have either never had a Wikipedia entry, or whose lives and work are dismissed in a stub a few lines long.
2. I'd favor something more descriptive, like {{Television needs production section}}. Stub tagging is kinda lazy. (guilty as charged)
3. I very much support an experiment. I would suggest we pick a number of articles. For half of them a hash is created and only the hash is published. For the other half you remove or hide the stub tag, but don't publish a list. Sure one could look at the contributions of the bot that does it, but we can't control that. We'll have to wait until a decent number of articles on the list has been improved beyond stub status, at which point we'd publish the list of still-stubbed articles and compare.
4. As BD2412 suggested, Template magic. - Alexis Jazz 01:16, 21 July 2020 (UTC)

• Oppose the editors at College Football Project often use the stub tag to focus editing efforts and assist with improving articles.--Paul McDonald (talk) 13:20, 24 July 2020 (UTC)

How to get many more editors

A great way to encourage very many new people to start contributing to WP (and prevent many from complaining about or even trying to sue WP) would be to change the off-putting, formal, bland, boring "From Wikipedia, the free encyclopedia" at the top of every page to something more welcoming and more informative, f.ex. "From Wikipedia, the free encyclopedia that its users make and are responsible for". --Espoo (talk) 09:07, 9 July 2020 (UTC)

I don't think it would discourage anyone actually wanting to sue WP, but it might bump up how many people want to issue legal threats at individual users. It also sounds like we are in aggregate legally responsible for the nature of the pages Nosebagbear (talk) 09:45, 9 July 2020 (UTC)

Can you think of something else that wouldn't cause those misinterpretations but is welcoming and informative? --Espoo (talk) 13:50, 9 July 2020 (UTC)

I guess I don't see what you are seeing with the existing line, nor do I see how changing it would accomplish the goal you have. 331dot (talk) 13:56, 9 July 2020 (UTC)

Correct me if I'm wrong, but didn't the slogan use to say "The Free Encyclopedia That Anyone can Edit?" Anyone know when/why the last part was removed? – Anne drew 14:11, 9 July 2020 (UTC)

Wow, long memory! Not since 2010... history of MediaWiki:Tagline. Cabayi (talk) 14:29, 9 July 2020 (UTC)

@Anne drew Andrew and Drew and Cabayi: The slogan on the main page still says "the free encyclopedia that anyone can edit", the tagline at the top of the page was only extended to the full thing for two days in 2010, and both before and since has been the abbreviated version. --Yair rand (talk) 20:41, 9 July 2020 (UTC)

It looks like there's already been lots of discussion regarding this many years ago - see MediaWiki talk:Tagline/Archive 1#"that anyone can edit" Ed6767 talk! 15:35, 9 July 2020 (UTC)

There was also a proposal in 2017 to say just "From Wikipedia"; it never got a ton of discussion. {{u|Sdkb}} ^talk 20:07, 9 July 2020 (UTC)

The tagline we currently use for the Main page is the free encyclopedia that anyone can edit. Adding a link to our welcome tutorial in this way would certainly drive a ton of traffic to it, but we're already slated to add a link to a welcome tutorial from the left sidebar as a result of WP:SIDEBAR20, so this would be somewhat redundant to that. {{u|Sdkb}} ^talk 20:16, 9 July 2020 (UTC)

Having more than one link to the welcome tutorial wouldn't hurt anyone.

The main point is that the current tagline is what most readers see as the definition of what Wikipedia is (and even if some will glance at the left sidebar, even most of those will not see the future link to the tutorial in that list) and it misinforms them more than it informs them.

The most important thing they need to know is that this is just as much their encyclopedia as anyone else's and that we want to welcome them, not turn them off, and especially if they disagree with something they read on the page they're looking at.

The current tagline says nothing about that. Instead it says only 2 things about WP that are probably obvious to almost all readers -- that it's an encyclopedia and that it's free -- so it's a very sad waste of prime layout real estate and a very sadly wasted chance to inspire readers to become editors. In fact, since the word "free" confusingly has more than one meaning in English, this tagline even distracts the reader's attention from thinking about editing.

More specifically, the current tagline not only sadly wastes a great opportunity millions of times a week: it's off-putting, formal, bland, and boring. It makes readers think of Wikipedia as an institution that exists apart from them, something huge that exists like dozens of volumes of a traditional paper encyclopedia on a shelf. We need a more welcoming and more informative tagline. We probably don't even need to use the word encyclopedia and we probably need to say that comments on the discussion page are welcome and valuable:

Most people are afraid to edit articles due to language, content, and technical reasons and very confused by things most of us don't even think about like the wikitext markup and the very annoying habit of the first line of most articles being "hidden" by being without a free line after hatnotes and often many infobox lines. --Espoo (talk) 12:31, 11 July 2020 (UTC)

Espoo, I very much agree with this. My main concern is just keeping the tagline concise and streamlined, which is why I haven't expressed explicit support for any of the proposals so far. To reply to Blueboar below, yes, everyone knows that they could edit Wikipedia, but unless they're actively reminded of that fact, they're very unlikely to actually do so. We need to advertise if we want editing to be something that actually comes to mind. {{u|Sdkb}} ^talk 06:48, 12 July 2020 (UTC)

• Um... Wikipedia has existed for almost two decades now. An entire generation has grown up with it. I seriously doubt that there is a large pool of potential editors out there who don’t already know that our content is user generated and that “anyone” can contribute.

No, the real reason that we don’t have as many editors as we used to have is quite simple... there isn’t as much for new editors to do (the obvious topics have already been covered). And what still needs to be done isn’t as much fun. Blueboar (talk) 14:07, 11 July 2020 (UTC)

How about this for a radical idea:

• Long term editors organise the resurrection / reactivating of the many seemingly dormant projects.
• When a new editor submits their first draft article they are welcomed and mentored by a member of the relevant project.
• etc - you get the drift.

Downsize43 (talk) 21:56, 11 July 2020 (UTC)

Your idea sounds great Downsize43, Especially #2! W.K.W.W.K...ALL Lives matter FAQ 02:53, 12 July 2020 (UTC)

Great ideas, Downsize43, but they don't address the problem of people who don't edit despite reading something that is said in a clumsy or wrong way or that they know or are pretty sure is wrong.

Yes, most people know they could edit, but most don't dare to, don't know how to, find it too difficult or confusing, don't realize they could instead write on the talk page, weren't treated kindly when they once edited something, and other reasons.

Your suggestions mostly apply to readers who have already edited. Instead, we need to encourage and inspire the much larger number of readers who have never edited.

So, instead of "From Wikipedia, the free encyclopedia", how about something like this:

This is a Wikipedia article, so it's as reliable as its sources.

Help improve it by clicking here.

--Espoo (talk) 08:01, 12 July 2020 (UTC)

I don't think "This is a Wikipedia article, so it's as reliable as its sources." is an improvement. Dutchy45 (talk) 13:46, 12 July 2020 (UTC)

• I just want to point out that the tag line under discussion only appears at the top of a page if you are seeing it in “desktop view”... there IS no tag line (at all) when using mobile view. If the goal is to somehow attract new editors by changing the tag line, it will have limited effect. The cosmetic change won’t be seen by those using mobile devices. Blueboar (talk) 13:41, 12 July 2020 (UTC)

  Blueboar, I think it's appropriate not to have a tag line on mobile, where there is more limited space. But your point is definitely good to keep in mind. We've improved the way our introductory resources work on mobile a bunch recently, and there's certainly more work to do. {{u|Sdkb}} ^talk 17:54, 12 July 2020 (UTC)

Ok, ok, I know it's not an actual grammar rule that sentences shouldn't end in prepositions, but the above wording grates on my pedantic copy-editing self. I don't really think the wording as it stands is preventing anyone from editing. Retswerb (talk) 06:19, 14 July 2020 (UTC)

Maybe one day. We have done everything to show them they can edit the article. We have edit buttons at the top of each page. We have edit buttons in each section header. We have edit links in maintenance templates. Our front page says that anyone can edit it. It gets really repetitive and plus it prob will mess up with the horizontal layout. For now, I think the "From Wikipedia, the free encyclopedia" tagline is good. Aasim 08:10, 18 July 2020 (UTC)

Clickbait header. And the tagline is irrelevant. I know how newbies are treated. Very few users are capable of effectively helping newbies. Nearly everybody lacks the patience. So newbies run into walls and give up. The learning curve is still too high. That is partially a technical problem but mostly a community problem. Without good teachers, the learning curve will always be too high. - Alexis Jazz 01:26, 21 July 2020 (UTC)

The learning curve is too high because things are too complex, and unnecessarily so. Things are too complex because (1) the natural tendency is always toward more complexity, and (2) there is nothing in our system to prevent that from happening. Few editors understand the cumulative costs of complexity, but any editor can participate in the development of the site's infrastructure. Do that for 19 years and you end up with a monumental mess, which is what we have. If you want good bridges, you don't let just anybody design them. In short, the problem is intractable without a sea change in project philosophy and a major overhaul of our system, which seem highly unlikely. Learn to live with it. ―Mandruss ☎ 11:57, 21 July 2020 (UTC)

• Oppose changes - I don't see how any of the above will improve project involvement. -Indy beetle (talk) 04:18, 22 July 2020 (UTC)

Dealing with Wikipedia clones

The issue of WP clones has been persisting since at least 2004. Today it struck me tangibly when I googled for one person's biography in Russian and ended up at Qwe wiki as the top search result. Several more seconds were spent to learn that the site is a known clone that was reported to Google AdSense on or around June 23. Other facets aside, spamdexing and the usage of Wikipedia to generate profit are often prominent on such websites. I think some decisive action is needed by now. Perhaps we as community can ask the WMF or its legal team to require noindexing of known clones and mirrors? As an extension, perhaps it's also possible to demand the removal of known COI violators (such as the likes of wikiprofessionals inc) from search results. Brandmeister^talk 19:28, 13 July 2020 (UTC)

The license allows reuse with attribution for any purpose whatsoever and keeping the same license as its source. There's nothing else to do about websites that follow those terms. (I imagine Google is not kind to the PageRank of copies in general.) Qwe wiki, as the link you provided points out, complies with those terms. --Izno (talk) 19:37, 13 July 2020 (UTC)

We don't only allow reuse of our content, for profit or not, but positively encourage it. That is one of the ways in which content is the property of the people who write it rather than the foundation which is supposed to serve them. But anyway, the foundation does not have the power to require noindexing or anything else that you are asking for. Phil Bridger (talk) 20:20, 13 July 2020 (UTC)

The world would definitely be better off without clones that spam ads at people, but modifying the license to try to stop them would be a huge change (the replies above start from the assumption it's not even within the scope of discussion), and it'd have to be done carefully to avoid blocking more benign commercial reuses, such as the Google search results knowledge panels. Overall, despite the one instance you encountered, I don't think clones are all that big a problem compared to other challenges we face like UPE. We should consider ourselves lucky that Wikipedia is featured so prominently in search results – for an example of a nightmare alternative universe, look at the situation of Wikivoyage, where an old inactive clone filled with ads (Wikitravel) regularly outranks it in search results. The only way I could see a nightmare scenario like that come to pass here is if, say, Google decided they wanted to create their own competitor to Wikipedia and then started prioritizing it in search results and luring contributors by paying them like Baidu Baike (the Wikipedia of China) does. Thankfully, they (wisely) don't seem to have much interest in doing that at present, but the WMF should have the back of their minds the need to make sure that that remains the case. {{u|Sdkb}} ^talk 22:17, 13 July 2020 (UTC)

We don't only allow reuse of our content, for profit or not, but positively encourage it. That's baked into the DNA of the Wikipedia. It's a terrible idea, it doesn't seem to do anybody except bad actors and parasites much good, and it's the seed of, not just our destruction, but the corruption of the database we've made -- because if they ever get in the mood, Google could fork the encyclopedia, monetize it, set up an organization to keep it improving, and downgrade us in search results. Amazon or some other large rich enity (including a foreign government) could do this too, except for that last part (unless they arrange it). But you don't need the last part if your product is better, which it might be.

It's only a matter of time, probably. There's nothing to be done about it, though. It is what it is. Herostratus (talk) 06:49, 14 July 2020 (UTC)

• I totally agree with the above there's not much to do about WP clones, especially with the WP content licence. However the interesting parallel is this: Wikivoyage (the official Wikimedia travel guide) was actually a fork of WikiTravel! Wikivoyage is the clone, and if I recall correctly was due to ads (or some sort of commercialisation) being placed on the Wikitravel content so the users decided to migrate. This is the benefit of the licence being used. - Master Of Ninja (talk) 06:54, 14 July 2020 (UTC)

• I'd disagree, firmly, with it doesn't seem to do anybody except bad actors and parasites much good - there's huge amounts of Wikipedia content being used by good faith actors, including individuals and organisations. There's also ongoing massive usage of Commons photos. As to the possibility of google (et al) forking Wikipedia - I've seen some rough estimates of suggested costing for trying to upkeep English Wikipedia if you were paying every editor. Trying to do it without advertising would be a nightmare, and I think they'd face some ludicrous amount of backlash. Probably a bigger issue is that they'd then be liable for all the ongoing edits made, and people would be way happier to C&D and sue Google (et al), because they might actually get something from it. Nosebagbear (talk) 10:41, 16 July 2020 (UTC)

Brandmeister, it should be noted that google for instance heavily punishes duplicate content in their rankings. This is why clones and mirrors will never score very high overall in their rankings. If we spent more time on writing good content and less on chasing things that we can't really influence, than we win. —TheDJ (talk • contribs) 11:08, 17 July 2020 (UTC)

I see your points. Hope this is indeed so. My issue was posing as Wikipedia and using its name to place ads which is rather different from fair license compliance for commercial purposes (e.g. in books and other publications for sale). Brandmeister^talk 11:23, 17 July 2020 (UTC)

If this site is actually posing as Wikipedia and using its name then it is in breach of rules about trade marks. Can you provide evidence that it is doing so? Phil Bridger (talk) 17:00, 21 July 2020 (UTC)

Qwe offers machine translated articles. For example Josh Robert Thompson in Dutch is a machine translation of Josh Robert Thompson. It's not very good, but I guess for some people it's useful. If Wikipedia stopped being freely licensed, I would quit. No point in contributing unpaid to that. I could just as well start writing for a site that pays its contributors. - Alexis Jazz 16:12, 21 July 2020 (UTC)

• I find it rather strange that editors are suggesting that the Wikimedia Foundation, which wants to rename itself to something including "Wikipedia" for commercial branding purposes to support its bloated bureaucracy, should have a monopoly of the content that we produce. As Alexis says above, that just turns us into employees of the Foundation, and as such we should be paid. It is certainly unusual for searches in English to turn up "bad actors" above Wikimedia sites, and I think that this was an exceptional case that shouldn't be used to drive policy. Phil Bridger (talk) 16:55, 21 July 2020 (UTC)

In addition to that last point: we shouldn't allow Google search results to drive policy, whether the case is exceptional or not. - Alexis Jazz 03:04, 22 July 2020 (UTC)

Thoughts on deindexing (some) non-content namespaces

I just did a Bing image search for "united states language pie chart" and ended up at a pie chart that is only used on a talk page. I cannot judge the accuracy of such an image, but I do not picture readers being directed to talk pages being super helpful.

Basically, I think it would be beneficial if talk pages in general are deindexed. I think there are certain queries that will take the user to where they want to go, on Google or otherwise, like searching "Wikipedia village pump", but I do not think people looking for information on a topic is going to be helped by many talk pages, as it is only for discussing improvements to an article. Aasim 22:35, 13 July 2020 (UTC)

Either way though, that image will still end up being indexed on commons? I don't really support the idea of deindexing talk pages, especially as they could contain topically relevant info. Ed6767 talk! 01:14, 15 July 2020 (UTC)

Ed6767 that is true. But it would be a lot more helpful if the image was indexed from its file description page and not some random talk page (or talk page archive). Or they should be indexed lower on search results. The last thing I want is an image that is on a talk page that is not accurate showing up in image search results. I am guessing the image is accurate? IDK like I said. Aasim 18:31, 15 July 2020 (UTC)

That chart was only created as part of a discussion about which style of graph is most useful to display that information. It was not intended to be used elsewhere. Rmhermen (talk) 03:57, 16 July 2020 (UTC)

I agree that the talk namespace should be deindexed. Talk pages and especially archived talk pages do occasionally show up in Google and they're always just random speculations or semi-serious BLP violations. – Thjarkur (talk) 09:53, 17 July 2020 (UTC)

Þjarkur, completely disagree. That also makes them unfindable for those who WANT to find them. Undesirable content should just be deleted and ppl have a bit of responsibility to interpret what they are looking at. —TheDJ (talk • contribs) 11:04, 17 July 2020 (UTC)

There have been a few (now decade-old) discussions about whether talk pages should be indexed, mostly as part of broader proposals about indexing, which are catalogued here. One point to note is that talk pages of BLPs are already deindexed, which helps reduce the likelihood of especially harmful material appearing in search results.

Arguments against deindexing that were raised at the time include its impact on users who dislike MediaWiki's search engine and prefer to browse discussion archives through external engines. Given the native engine has presumably improved since then, I'm not sure whether this practice is still prevalent. Another was the possible effect of deindexing millions of pages on Google's PageRank of articles – an FAQ for a 2009 proposal claims the impact would be "very difficult to predict", though I'm not equipped to judge whether this is true.

Either way, I think the negative effects of indexing talk pages are too slight to justify changing the usual practice. I agree with TheDJ; I would expect users who come across talk pages in their search results will grasp their nature as discussion hubs, given the clear prefix in their titles, and adjust expectations of their content accordingly. The problem is when search engines present talk pages' content misleadingly, as in Aasim's Bing search. Bing, unlike Google, does not give an image's domain without a mouseover, and even then it ambiguously gives the chart's source as "Wikipedia" (you have to click through to see it's from a talk page). That is their responsibility to fix, not ours. If the chart's source was presented unambiguously, there wouldn't be a problem. – Teratix ₵ 13:31, 17 July 2020 (UTC)

The main issue that I have with many talk pages being indexed is that we do not want inaccurate information showing up high on search results. Because Wikipedia is a very popular website for information, we do not want to mislead readers with images that is potentially inaccurate. It would be a lot better if used images were indexed if they were only in main namespace. The problem with indexing talk pages is the same problem as this (now-deleted) template: they provide no help whatsoever for someone searching the topic. And people that check the source of the image will be confused that they see what looks like a weird kind of forum that only some people can comment on instead of the traditional Wikipedia article. I am providing a bit of a reader-focused view on Wikipedia. I think it would be in our and our reader's best interest to deindex talk pages. Aasim 20:44, 17 July 2020 (UTC)

Oh, and deindexing does not mean that they will not show up on MediaWiki search results; they just won't show up on Google or Bing. Aasim 20:46, 17 July 2020 (UTC)

I concur with the Awesome One: the garbage content on talk pages is much higher, and stuff we would never allow to remain in an article can just lie there on a talk page, like the proverbial "t**d in a punchbowl", ready to be stumbled on by an unsophisticated seeker of information. --Orange Mike | Talk 21:20, 17 July 2020 (UTC)

Agreed with the arguments for the de-listing as explained above, per Aasim and Orangemike. Regards, GenQuest ^{"Talk to Me"} 07:26, 18 July 2020 (UTC)

• I agree that talk namespaces should be deindexed and find the arguments against deindexing to be wanting; while it is likely true that search engines such as Bing "should" improve their search engine algorithms to remove the undesirable effects of indexing talkpages, we cannot assume that they will take that responsibility nor can we control whether they do. Besides, talkpages have vanishingly negligible value outside of Wikipedia editors anyway, so there's no real harm in deindexing them. – John M Wolfson (talk • contribs) 07:36, 18 July 2020 (UTC)
• I would very strongly support deindexing article talk pages. The sane reason we deindex BLP talk applies to all talk: they contain a high percentage of misinformation, spam, and unsupported accusations. The peoplewho needto find them are active WP contributors, andour own search function now works well enough for that. DGG ( talk ) 16:59, 21 July 2020 (UTC)
• I must admit that I assumed that this happened already, but it seems that I was wrong. I, for one, have never used an external search engine to find anything on Wikipedia outside the article space. Has anyone? Having said that I don't think that this was a particularly good example, because images on Commons are designed to be found and used. But that is a matter for Commons. Phil Bridger (talk) 17:13, 21 July 2020 (UTC)

  I often use a search engine to look for content on Wikipedia. The internal WP search is useful for exact strings but I don't have the skill to get it to work finding concepts or related information; a search engine search scoped to wikipedia.org frequently helps me find what I'm looking for when I don't know the title or precise phrase. Schazjmd (talk) 17:39, 21 July 2020 (UTC)

  Ok, it's good to hear that such a strategy can be useful. Phil Bridger (talk) 18:39, 21 July 2020 (UTC)

Bot requests for perms

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Can we have somewhere to request permissions for bots? Another Wiki User the 2nd (talk) 16:08, 16 July 2020 (UTC)

@Another Wiki User the 2nd: these are normally dealt with as part of a WP:BRFA. — xaosflux ^Talk 16:19, 16 July 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

www.imdb.com/title

Change templates for iMdb titles to URL/reference

example:

• https://www.imdb.com/title/tt3444938/

to:

• https://www.imdb.com/title/tt3444938/reference

same as the older:

• https://www.imdb.com/title/tt3444938/combined

this results in more information to the reader 0mtwb9gd5wx (talk) 21:35, 21 July 2020 (UTC)

Please note that per WP:RS/IMDB the site should not be used as a reference. OTOH if you are referring to how it is used in the "External links" section of an article other editors will be able to assist you. MarnetteD|Talk 22:29, 21 July 2020 (UTC)

I think the proposal is to change the default URL generated by Template:IMDb title. Probably a proposal better suited for Template talk:IMDb title, in my opinion. ―Mandruss ☎ 01:04, 22 July 2020 (UTC)

Make future WP:ANI threads individual pages, like WP:AFD

Currently on WP:ANI there is one page in which editors discuss incidents. However, there are some issues with this approach:

• It is usually very active, and editors often encounter annoying edit conflicts
• ANI has over 1000 archive pages. This can make sifting through them all rather difficult, even with search, i.e. finding the archive through loads of results, scraping through them all, then finding the subsection (of which an archive can have many), then copying the permlink
• If a user wants to check on discussion for a specific case, they have to watch the entire page, meaning that their watchlist will likely be filled with irrelevant changes.
• ANI usually gets very long. This can make it harder to load on slower computers, and some bots or scripts may fail to edit it due to its often extreme length.

Due to these issues, I propose that a new subpage is made, either per thread, or per day on WP:ANI, similar to current process on WP:AFD and other similar pages, as this would resolve a large majority of these issues, along with a number of additional benefits. Ed6767 talk! 01:56, 22 July 2020 (UTC)

Interetsing idea. Technology-wise, I have never had any problem reading the ANI threads on my 2011 Macbook pro. The archive might be better managed though. ThatMontrealIP (talk) 02:29, 22 July 2020 (UTC)

• Support per nom, as this seems very reasonable, with the caveat that I'm not an expert in the technical functioning of these forums, so if there's some big downside I'm missing, feel free to discount my !vote. {{u|Sdkb}} ^talk 07:08, 22 July 2020 (UTC)
• Not going to happen due to the complexity. People who positively contribute at ANI won't want to click through to a hundred subpages and add them to their watchlist (and remove them after sufficient time to avoid the watchlist overhead). At ANI, people can search for a particular user name, article name, or date and quickly find all occurrences. That becomes a major undertaking with multiple subpages. Johnuniq (talk) 07:20, 22 July 2020 (UTC)
• Please don't. Johnuniq has it right. - Sitush (talk) 07:24, 22 July 2020 (UTC)
• It is not unusual for ANI to have spurious posts or vandalism; such pages would need to be deleted instead of merely reverted. 331dot (talk) 07:37, 22 July 2020 (UTC)

  Surely then that would be the benefit of having new daily pages for new threads then? You can still have the benefits of having shorter, more manageable pages, and also be able to revert vandalism as per usual then? Ed6767 talk! 10:19, 22 July 2020 (UTC)

All users can revert vandalism; only admins can delete pages. This would make more work for admins (if each discussion has a page) with little tangible benefit. Daily pages would require people to follow more pages, and require more archiving, and be harder to manage, not easier. 331dot (talk) 11:00, 22 July 2020 (UTC)

• Oppose- Edit conflicts generally affect edits to the same subsection. That is, if I am editing section "User:blerpyface is a fink" and someone else is editing section "User:fnordbot is broken" simultaneously, we will not run in to an edit conflict. Those that do happen come from editing the same section, and that problem would affect individual pages as well. As for the archives, yes, there are over a thousand of them. So what? Will replacing 1,000 archives containing multiple sections with tens of thousands of individual pages be any better? No. This proposal seems to me to be a solution in need of a problem. Reyk _YO! 10:34, 22 July 2020 (UTC)
• There are problems presented here, but I'm not sure if these are the right solutions? Regarding edit conflicts, Reyk is correct. Regarding searching, AfD is easier because the title of the AfD always follows the title of the article being discussed, (give or take nth nomination). ANI sections follow no titling pattern, so searching won't necessarily be improved in that sense. I suppose it could be easier to identify relevant sections from Special:Search though. The third point is reasonable, I suppose. But is it significant enough that it's worthwhile reworking the system? Obviously noting that doing this will mean watchlisting ANI itself for updates to any section stops working. ProcrastinatingReader (talk) 11:18, 22 July 2020 (UTC)
• Oppose - whereas AfD pages are functionally all independent, AN & ANI threads branch, merge, move etc all the time. There is also more need to be able to move around the full set smoothly, though that's a lesser issue. I also feel that edit conflicts are already within sections anyway, so branching into pages would be problematic. Don't get me wrong, there are benefits, particularly making it viable to watchlist individual discussions where the whole page would overwhelm a watchlist. But I think the issues outweigh the positives. Nosebagbear (talk) 12:44, 22 July 2020 (UTC)
• Strong oppose - the main purpose of ANB is to get the attention of an admin. It is possible to get an email every time a page is edited (I do for some pages I watch). It is not possible to do this every time a subpage is edited created. Plus, most threads are very short (like "Can you please block X because they did Y" or "Can you delete the page X that I created on accident"). We do occasionally have long discussions, but those very few cases when we have long ANB discussions do not warrant putting individual discussions on individual pages. AfD, though, gets hundreds of nominations per day, which warrants individual pages for these nominations. Plus, some of these nominations can get a very heated discussion. For these reasons, I strongly oppose this proposal. Aasim 20:30, 24 July 2020 (UTC)
• Support trial - one ANI page per editor, like how SPI does it. I think that would make a big difference to how discussions play out and it would cut down on "repeat offenders". There could also be a "general/misc" page for the more minor matters that don't merit their own page. Something like this is worth trying out I think. ANI desperately needs a shake up; it's next to useless and has been for years. Levivich ^{[dubious – discuss]} 07:05, 25 July 2020 (UTC)

  As the Wheel turns... --Izno (talk) 13:51, 25 July 2020 (UTC)

  Iztrue. Levivich ^{[dubious – discuss]} 14:26, 25 July 2020 (UTC)

Harassment solutions RfC

Please see: Wikipedia talk:Requests for comment/Harassment solutions. EllenCT (talk) 19:22, 22 July 2020 (UTC)

Mass Move pages

The ability to mass move pages would be really useful for sports team renames, would you want it? — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 20:45, 2020 July 23 (UTC)

Another Wiki User the 2nd, that would require a software change, and I think such functionality would be better as a userscript or gadget, rather than being implemented into MediaWiki itself, like other mass x scripts. Ed6767 talk! 23:54, 23 July 2020 (UTC)

We already have a tool that can do many automated tasks. It is called autowikibrowser. An admin needs to grant you permission to use the tool first. Aasim 20:42, 24 July 2020 (UTC)

Also, you have to be an admin to use the tool to move pages, so... Aasim 21:31, 24 July 2020 (UTC)

Notification when another language links to an article on your watchlist

I occasionally note that articles I have created or worked on have been translated into new articles on other language versions of Wikipedia. When new articles are created and linked to a page on my Watchlist, would it be possible to receive automatic notification?Roundtheworld (talk) 07:57, 25 July 2020 (UTC)

Roundtheworld, you might want to take this to the idea lab or WP:VPT, since there are presumably some technical challenges to be figured out before this can be a concrete proposal. Personally, I find the Wikidata notices that show up in my watchlist sufficient, but it'd be nice to have the option to turn some things in one's watchlist into notifications. {{u|Sdkb}} ^talk 04:59, 26 July 2020 (UTC)

Audio name and music

All name should be recorded in the pronouncation in which every one will understand to every sector of the world like some people pronounce xavi as x avi not knowing it is pronounce shavi and all music will have audio file in which one can listen to some part of it and if full you can. This what makes article more interesting and back up article. let enforce it more let use wpwp campaign to enforce this more.Tbiw (talk) 14:03, 6 July 2020 (UTC)

Tbiw, see WP:WikiProject Spoken Wikipedia for full recordings of articles and WP:SAMPLE for fair use music samples. {{u|Sdkb}} ^talk 04:52am, 26 July of 2020 (UTC)

GS Alert Changes

The GS templates tend to get less love than the DS ones. It is proposed at WT:GS that {{Gs/alert}} be updated to the sandbox version at {{Gs/alert/sandbox}}, to bring it in line with changes made to {{Ds/alert}} since it was copied over, and to remove (now-)redundant sentences and generally clean up the template. Comments and thoughts over there are greatly appreciated. ProcrastinatingReader (talk) 11:14, 25 July 2020 (UTC)

Clearly display each Default setting at Special:Preferences

Tracked in Phabricator
Task T70689

Have you ever gone to Special:Preferences and wondered whether to "Restore all default settings", only to realise you have absolutely no idea which ones you might already have changed, or which helpful Gadget or Editing settings you might lose if you did so?

A recent Teahouse discussion has prompted me to propose a long-held feeling that a User's Preferences page should indicate the original Default setting (whether enabled or disabled). Only that way can a user who has, over some years, tweaked their Preferences appreciate what they've actually activated or disabled, and what they see differently from a brand new user.

This seems a reasonable and obvious thing to propose, and with no disbenefits. Or is this better put forward as a broader cross-wiki suggestion at https://meta.wikimedia.org/wiki/Help_talk:Preferences ? Nick Moyes (talk) 20:15, 25 July 2020 (UTC)

• Strong support - although, this is a MediaWiki issue will probably be better suited for phabricator instead of here Ed6767 talk! 20:26, 25 July 2020 (UTC)
• Support this being done, wherever it needs to be requested. This is an obvious no-brainer case of bad design. Phil Bridger (talk) 20:57, 25 July 2020 (UTC)
• The preferences pages can already be overwhelming. I don't think this would be a good idea. Starting a documentation of these defaults at e.g. Help:Preferences seems reasonable. --Izno (talk) 21:36, 25 July 2020 (UTC)

  Surely, some simple design ideas could resolve that concern? For example, items that are actively selected by default could be shown in bold. Hardly overwhelming. What I think is genuinely "overwhelming", is not being able to discern what was or was not once a default setting when looking at the Preference pages themselves . Nick Moyes (talk) 00:15, 26 July 2020 (UTC)

  Then you need to explain to both sighted and unsighted users what the bold means, and the latter group doesn't get anything for that besides some text to that effect, and the former still needs that to fit somewhere on the page in question. --Izno (talk) 00:37, 26 July 2020 (UTC)

  It can't be too much of an effort to append (default) to the end of default preference options? And it should look okay too from some tests I've done Ed6767 talk! 00:32, 26 July 2020 (UTC)

  On which resolutions? :) --Izno (talk) 00:37, 26 July 2020 (UTC)

  Personally, I'd rather to see them on the preferences page than on a separate help page (I'd more likely use MediaWiki:Gadgets-definition as a source of truth since it is more universal and I know that it won't be outdated). As for the page already being overwhelming, thoughts on the Wikimedia Commons approach of using a superscript "d" with tooltip (^d), along with a sentence at the top of the page that also explains what it means?  Hazard SJ  02:30, 26 July 2020 (UTC)

• Support per nom, assuming that it is implemented with good design that doesn't overwhelm the page. This request arose because we realized users who created an account prior to 2014 still don't have RefToolbar (the thing that allows you to click "cite web" etc.) enabled by default. Most big websites force new changes on all users, and while that wouldn't go over well here due to status quo bias from power users (i.e. ourselves), the least we should do is note when something has changed by marking the default. Personally, this would be useful for me since, even though I may not change any settings, marking the default would give me a cue as to when the appearance of something might differ from that of the average reader. {{u|Sdkb}} ^talk 04:49, 26 July 2020 (UTC)
• Support per nom and User:Sdkb. I've wondered about just what were the defaults myself. Regards, GenQuest ^{"Talk to Me"} 09:13, 26 July 2020 (UTC)
• Support. Then update Help:Preferences. Also link to Help:Preferences rather than MW:Help:Preferences. — GhostInTheMachine ^{talk to me} 09:56, 26 July 2020 (UTC)
• So there are a couple of ways to do this: (a) with a bunch of hacks to some of the labels, this would be local and would need to be done for each language a user may use - so I strongly oppose that in bulk (maybe for gadgets - since these are project-specific). phab:T70689 is already open to fix this mediawiki side, so I suggest anyone that wants this to be developed subscribe there and voice support. — xaosflux ^Talk 11:42, 26 July 2020 (UTC)

Sort Order of Languages list on the left

The order on the left is no longer ordered by two-letter code as described at Wikipedia:Language order poll, and I can't find anywhere explaining how it's now ordered and why. It's really annoying and hard to find other languages. In other editions of Wikipedia the list is folded up which is even more annoying.--عبد المؤمن (talk) 21:30, 25 July 2020 (UTC)

This is an issue for WP:VPT for the future. WP:Village pump (technical)/Archive 183#Tech News: 2020-30 documents that this is a bug and is anticipated to be fixed. --Izno (talk) 21:43, 25 July 2020 (UTC)

See Wikipedia:Village pump (technical)/Archive 182#Sidebar language order changed? as well. {{u|Sdkb}} ^talk 04:56, 26 July 2020 (UTC)

Proposal to mass-create category redirects to resolve ENGVAR variation in the spelling of "organi[sz]ations"

BrownHairedGirl has initiated this proposal at Wikipedia talk:WikiProject Categories#Organi[SZ]ations_category_redirects. Please keep all discussion there. Thryduulf (talk) 12:11, 26 July 2020 (UTC)