Wikipedia:Village pump (proposals)

  (Redirected from Wikipedia:VPR)
 Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172

Left sidebar update follow-upEdit

Read each section for more detailed close information:
  • Introduction page: weak consensus for Help:Introduction
  • Label and tooltip: consensus for Learn to edit as the text and Learn how to edit wikipedia as the tooltip
  • Positioning: consensus for below Help
  • Current events tooltip: consensus for Articles related to current events
  • Community portal tooltip: weak consensus The hub for editors
  • Miscellaneous proposals: no consensus
There was additional discussion below that also did not resolve into any additional consensuses. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Wikipedia:Requests for comment/2020 left sidebar update was recently closed by Barkeep49 and DannyS712, and most of the results have been implemented. A huge thank-you to everyone who participated! Per the close, several items require follow-up due to low participation or lack of consensus. I am opening this discussion as a space for those discussions to take place. It is being transcluded to the WP:SIDEBAR20 page and will be moved there when it concludes. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)

Introduction pageEdit

Help:Introduction narrowly has the most support, followed by WP:The Wikipedia Adventure and WP:Contributing to Wikipedia, with a few editors opining that all of the present options are bad. Specific arguments in favor of H:Introduction were that it's easy to use, looks good, and is supported by WMF. Arguments against H:Introduction were that it's too long and that it's suppported by the WMF. Supporters of The Wikipedia Adventure argued that it's more engaging and gets people actually editing quicker (one argument that it's particularly well-suited for children seems ill-considered, as there's no reason to assume that this link will primarily be used by children). Editors opposed to The Wikipedia Adventure argue that its gamified format may be offputting to some prospective editors. Supporters of WP:Contributing to Wikipedia felt that it was a better, one-page version of the information that H:Introduction tries to communicate. Editors opposed to present options suggested that we can do better, and that we should prioritize introductions that more briefly explain what Wikipedia is. In the absence of a status quo to fall back on, the outcome of this discussion is to adopt the frontrunner, although editors can continue to workshop better solutions. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

The RfC found consensus to add an introductory page for new editors, but asked for further discussion on the details.


Previously discussed options: Help:Introduction (5 !votes), Wikipedia:Contributing to Wikipedia (1 !vote), and Wikipedia:The Wikipedia Adventure (1 !vote)

  • Support Help:Introduction. To put it simply, this is our best introduction. It's where the deprecated Wikipedia:Introduction now redirects and was made the primary link in the standard welcome template. It covers all the basics without going into unnecessary detail. It is mobile-friendly and accessibility-compliant. It follows the usability best practice of splitting information into easily digestible bite-sized chunks, rather than a single overwhelming page (although it has an option to be viewed as such if one wants). It's the preferred choice of the WMF Growth Team's product manager. It's being actively maintained and is overall ready for inclusion on the sidebar. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
Support any page that is not Help:Introduction a huge 66 page tutorial that is not user friendly. Stats show us that almost no-one is clicking the non-action action buttons to learn more so why send even more there??? . The fact someone from the WMF with less then 350 edits and zero edits in the help namespace likes the page should be a big red flag...last thing we need is another non experienced WMF member telling us what is best.--Moxy 🍁 11:14, 12 June 2020 (UTC)
The WMF Growth Team is literally the team in charge of new user retention. They're not trying to force anything on us (I was the one who sought out their opinion), but I trust that they know what they're talking about when they say We think that help pages are better when they have a fewer number of links and options -- too many can be overwhelming. In that vein, I think that WP:Contributing to Wikipedia would likely overwhelm, and Help:Introduction would be better. As for the traffic stats, most people come to the page looking for help doing a specific thing and then click on the page relevant to that. Since there are 13 pages linked, of course none individually will be getting as much traffic as the portal. There's also the general 1% rule of the internet to consider. Even the custom-designed newcomer tasks feature only results in 9% of newcomers coming back after 3 days (compared to a baseline 4-5%), so keeping them around is a huge challenge. The stats for the Wikipedia Adventure are similar, and while we don't know how many people who visit WP:Contributing to Wikipedia actually read to the bottom of the page, my guess is that it's shockingly low. {{u|Sdkb}}talk 15:25, 12 June 2020 (UTC)
Yup same team that brought us VE.--Moxy 🍁 15:32, 12 June 2020 (UTC)
The team was formed in 2018, so no. {{u|Sdkb}}talk 15:58, 12 June 2020 (UTC)
I guess I should have been more specific..old timers will understand--Moxy 🍁 17:35, 12 June 2020 (UTC)
  • Support Help:Introduction. Although I don't disagree it is quite voluminous, it covers all the necessities in a fairly well-structured manner and I used it myself for getting started.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Support Wikipedia:The Wikipedia Adventure as I did in the previous discussion. I'm aware of accessibility criticisms and I'm even aware of data that suggests TWA doesn't improve editor retention (though I can't find the place where I read that a few years ago). However, the purpose of the link should be to get people thinking about becoming an editor—it's before the retention period, the part where we need to show them something just interesting enough to get them to make an account. I don't want another dry link with 400 subpages, none of which actually give me something to start editing or give me enough information to have my first edit not be immediately reverted. Barring TWA, I don't believe we have a page suitable for purpose but I would support Help:Introduction as a second and support any other page as better than nothing. — Bilorv (Black Lives Matter) 13:21, 12 June 2020 (UTC)
  • Support Wikipedia:Contributing to Wikipedia Its a one page, one stop wonder. Already well trafficked, lots of videos (which new users are always asking for), and long enough to be actually useful. I would also support Help:Introduction to Wikipedia, but would strongly oppose just Help:Introduction, as it is full of ...meaningless links for newbies, and already confuses folks with the VE/source distinction, and there are plenty more useful pages. CaptainEek Edits Ho Cap'n! 14:39, 12 June 2020 (UTC)

Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diff)

I informed all that were in prior discussions even the ones that like your page. If I missed any fell free to inform..--Moxy 🍁 17:35, 12 June 2020 (UTC)
With 50 views a day its clear most do not send people there. The Wikipedia:Adventure has more then a 50 percent drop in views by the second page....with a loss of 90 percent by page 3. Not as bad as Help:Introduction but close.--Moxy 🍁 17:42, 12 June 2020 (UTC)
  • Support Wikipedia Adventure as I think Bilorv makes the best case. As the most prominent link for readers, we want to convert them to editors as fast as possible. For all the problems of TWA, it's best feature is that it gets readers editing quickly without having to read an entire manual. We can fix the other problems as we go along, and with added urgency given its prominent placement. Support the others as better than nothing. Wug·a·po·des 19:18, 12 June 2020 (UTC)
  • Support Wikipedia:TWA. It's where I'd send new editors, without a doubt; it's clear, concise, to-the-point, and engaging as a tutorial of how the site works technically as well as in policy, working with both in a hands-on environment. This approach is well-tested on other sites - indeed, it's what the onboarding experience looks like on many popular social media platforms - and it works in keeping people engaged throughout, making people less likely to skip the "boring policy bits" because they're actively doing something. Naypta ☺ | ✉ talk page | 19:43, 12 June 2020 (UTC)
    @Naypta, Wugapodes, Interstellarity, and Bilorv: I tried TWA recently and had high hopes for it, since the graphics are definitely nice and the interactivity is a plus. But I came away from it concluding that there are just too many problems, and those problems are too hard to address given how rigidly it's built. To list them out:
    • The JavaScript that keeps track of where you are is very buggy; several times it lost my place and I had to go back to the start of the module. Every time that happens, it's a potential exit point for someone to decide to give up.
    • It displays terribly on mobile, which loses us half of all potential editors right off the bat (and probably more in developing areas).
    • It's not accessibility-compliant, which introduces further issues of discrimination.
    • It's longer than Help:Introduction without really covering anything important that H:I doesn't, and it doesn't touch on all the most important things right off the bat the way H:I does. I don't think most newer editors will have that much patience.
    • There's no instruction on VisualEditor, and while that may not be what we all use, for newer editors it's a very important transition aid.
    • The juvenile tone seems to be okay with some people but very off-putting to others. We can be friendly without being juvenile, and I think H:I strikes a better balance.
    Putting all those together, they add up to a dealbreaker for generalized use, and they would require a ton of work to solve. By comparison, expanding the sandbox elements for H:I into something more fully interactive would not be hard (I might work on it later today). {{u|Sdkb}}talk 20:34, 12 June 2020 (UTC)
    As I said in my original comment, I'm aware of its problems. These are all things that can (and should) be fixed. Despite that, the most important function of this link is getting readers to make an edit, not teaching them rules. For its problems, TWA's really good at that. Wug·a·po·des 20:47, 12 June 2020 (UTC)
    @Wugapodes: I agree on that point. I think the very best thing is to present newcomers with easy edits to make on Wikipedia itself, since it's infinitely more satisfying to make a live edit than one to a sandbox. That's what the Newcomer Tasks feature the WMF is developing will hopefully do extremely well, and we'll want to integrate it once it goes live. For some things, though, a quiz/sandbox environment is best. I've opened up a discussion at H:I and we'll work on adding more of those features; help is welcome from anyone who wants to contribute. Cheers, {{u|Sdkb}}talk 21:25, 12 June 2020 (UTC)refactored 22:42, 12 June 2020 (UTC) to link to discussion
    @Sdkb: I think the points you raise here are definitely important ones. It ought to be possible for an interface admin to add code to MediaWiki:Guidedtour-tour-twa1.js that would automatically redirect mobile users from TWA to H:I, and for accessibility, it might be a good idea to add markup to the top of the page offering H:I as a more accessible alternative. One other option might be to have a choice - something like the below:Welcome to Wikipedia! Would you like to read a short, accessible introduction to editing Wikipedia, or learn interactively how to edit Wikipedia by taking a tour of the site?
    That could then redirect mobile users automatically to H:I as described above. Naypta ☺ | ✉ talk page | 21:22, 12 June 2020 (UTC)
    Closer's note: I had to remove a template from the above comment because it was interfering with archive templates. The code of the original comment was {{Quote frame|{{fake heading|sub=1|Welcome to Wikipedia!}}Would you like to '''read a short, accessible introduction to editing Wikipedia''', or '''learn interactively how to edit Wikipedia by taking a tour of the site'''?}} signed, Rosguill talk 22:22, 21 September 2020 (UTC)
  • Support Help:Introduction - TWA's format makes it difficult for a new editor to jump to exactly the information they need. Plus, the whole concept of an interactive "adventure" would be offputing and distracting for many newcomers. While Help:Introduction is far from perfect, it is clearly the better option, and it's a lot easier to iterate on and improve. - Axisixa T C 22:00, 12 June 2020 (UTC)
  • The proposals are dreadful—design-by-committee with every second word linked and pointless decorations. • Help:Introduction might be ok if each button led to a single page of information. However, few people want to dive into a labyrinth where you never know if you've missed vital points, and later you can never find anything you vaguely recall seeing. • WP:TWA would be suitable for, umm, certain levels of potential editors but a sidebar link should be for useful information you might want to see more than once. • Wikipedia:Contributing to Wikipedia is the best but has too much waffle. There should be a short page with core facts and many fewer links (something that can be searched after a first read), with links to the proposals here. Johnuniq (talk) 01:52, 13 June 2020 (UTC)
H:E is shorter then WP:CTW and just about additions ...not sure why so many think new editors will read over 50plus pages to learn anything considering the data we have about them ...odd very odd to me.-Moxy 🍁 12:23, 13 June 2020 (UTC)
  • Only support something that makes it clear in the first few sentences that Wikipedia is an encyclopedia based upon what reliable sources say about a subject and that editors' opinions and knowledge/expertise are not to be used. This could be followed by something short about reliable sources, being a mainstream encyclopedia and about original research. Doug Weller talk 11:15, 14 June 2020 (UTC)
  • Support Quickstart – not sure about anybody else, but I just try out my new phone, program, tv remote, without reading the manual, or only after briefly scanning it. Maybe later, after I can't turn the phone off, or find Netflix, will I go to the manual (and then, slightly annoyed that the user interface is so poorly designed, that it isn't self-evident). I support an introduction that can fit on 3/4 of a laptop page and takes about a minute to scan. As a new Wikipedia editor, I just want to edit something, anything, to see how it works, and then learn by doing; not spend time reading endless explanations, and trying to remember what I read forty pages ago, and whether that was more important. I'll get to reading all that later, after I've got some experience. Remember learning to ride a bike? The manual is for explaining how to adjust your seat height, attach a lamp, or change a tire; it's not about teaching you how to ride on two wheels. Mathglot (talk) 09:35, 16 June 2020 (UTC)
    @Mathglot: The first content page of Help:Introduction, Help:Introduction to Wikipedia, is basically what you're describing. {{u|Sdkb}}talk 10:22, 16 June 2020 (UTC)
  • Support Wikipedia Adventure great for younger editors. (talk) has made no other edits. The preceding unsigned comment from a Canadian IP address was added at 05:50, 17 June 2020 (UTC).
  • Support Help:Introduction it is easy to use and looks good. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
  • Update: Following up for those here who haven't clicked through to the Help:Introduction discussion, we've added a slew of interactive components, including custom sandboxes, quizzes, and invitations to make easy live edits to articles through tools like Citation Hunt. We're planning on adding a few more quizzes, and as mentioned above the interactivity will get a further boost once the new Growth Team features are implemented, but I hope the present efforts will be enough to satisfy the concerns of some of those who opted for TWA above and perhaps resolve the deadlock we seem to currently be at. {{u|Sdkb}}talk 06:11, 1 July 2020 (UTC)
  • Support Help:Introduction, other pages have too many paragraphs, poor structure, and are too daunting. It keeps annoying me how we have dozens of introduction/"read this" pages, which are all so long, and then we try to create simplified versions of these but they're also so long, but also not comprehensive enough so you end up needing to read the even longer one anyway. Help:Introduction pretty much gets the point across and looks less scary. And as a sidenote, would like to say thanks to Sdkb's for their broad and important work to make Wikipedia easier to access for new editors. ProcrastinatingReader (talk) 13:04, 6 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.

Label and tooltipEdit

The result of this discussion was broad support for Learn to edit as the text and Learn how to edit wikipedia as the tooltip signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed label options: "Tutorial" and "Editing tutorial". Previously discussed tooltip option: "Learn how to edit Wikipedia".

  • Support Tutorial, with "Learn how to edit Wikipedia" as tooltip. The renaming of the section where this will presumably be located to "contributing" makes it clear that this is an editing tutorial, not a tutorial on how to read Wikipedia, so we should go with the shorter label for conciseness. No one has raised any concerns about or suggested any alternatives for the previously discussed tooltip. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support Tutorial, with "Learn how to edit Wikipedia" as tooltip per Sdkb's reasoning.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
    5225C (talkcontributions) 23:53, 12 June 2020 (UTC)
  • In the new condensed sidebar there's less chance of the link getting lost, but I'd still prefer something very in-your-face as a label. I like an idea alluded to by MMiller (WMF) here: "Start editing". Or "Learn to edit". (As a tooltip, "Learn how to edit Wikipedia" or similar would be fine.) As a last resort, I'd prefer "Editing tutorial" to "Tutorial". (Who reads the section title? People navigate much more non-linearly than that. I want to know what a link is the instant I look at it, no contextual clues needed.) — Bilorv (Black Lives Matter) 13:09, 12 June 2020 (UTC)
    I like "Learn to edit" a lot — it gives a nice call to action. "Start editing" would imply that you're making actual edits during the tutorial, which isn't the case apart from the sandboxes. {{u|Sdkb}}talk 16:33, 12 June 2020 (UTC)
  • Support - first preference: "Learn to edit", then "Tutorial". MER-C 16:56, 12 June 2020 (UTC)
  • Learn to edit for label since it's short and actionable; no strong opinions on the tool tip. Wug·a·po·des 19:20, 12 June 2020 (UTC)
  • Learn to edit per Wugapodes seems best to me. Tutorial isn't quite as clear - tutorial of what? Especially for an educational site, for people for whom English is not their native language, that could potentially lead to confusion. "Learn to edit" is clear in intent and action. For the tooltip, "Learn how to edit Wikipedia" seems good. Naypta ☺ | ✉ talk page | 19:43, 12 June 2020 (UTC)
  • Support "Learn to edit" with "Learn how to edit Wikipedia" as the tooltip.
    5225C (talkcontributions) 04:21, 14 June 2020 (UTC)
  • Learn to edit. Simple and straightforward --Tom (LT) (talk) 07:41, 21 June 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.


Consensus for placement below "help" with 5 suppporting and 1 editor for above help. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed option: Contribute section, just below Help.

  • Support previously discussed option. This seems like the logical placement, and no one has raised any concerns about it or suggested any alternative. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support placement below Help as the logical spot.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Above help, as the first thing under "Contribute" should be something that leads me somewhere where I will learn to contribute. — Bilorv (Black Lives Matter) 13:22, 12 June 2020 (UTC)
  • Immediately below help, please. MER-C 16:57, 12 June 2020 (UTC)
  • Below help. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
  • Below help. ProcrastinatingReader (talk) 14:20, 6 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.

Current events tooltipEdit

"Articles related to current events" received unanimous approval from four editors this time around signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed options: "Find background information on current events" (status quo, 0 !votes), "Articles related to current events" (2 !votes), and "Articles on current events" (1 !vote).

  • Support "Articles related to current events", since "on" would imply that we're writing news articles, which we're not, especially in cases like recent deaths. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support "Articles related to current events", per Sdkb and for clarity with WP:NOTNEWS.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Support "Articles related to current events" as above. — Bilorv (Black Lives Matter) 13:23, 12 June 2020 (UTC)
  • Per above Wug·a·po·des 19:23, 12 June 2020 (UTC)
  • Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:14, 15 June 2020 (UTC)
  • Articles related to current events. This is a very clear description of what the page contains. --Tom (LT) (talk) 07:41, 21 June 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.

Community portal tooltipEdit

"The hub for editors" has weak support, despite editors having mixed feelings about that tooltip in the prior discussion. No alternatives have been suggested. Given that this has already been raised for discussion twice, I think that the current weak consensus will serve for the time being, pending someone objecting strongly. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed options: "About the project, what you can do, where to find things" (status quo, 0 !votes) and "The hub for editors" (2 !votes)

  • Support "The hub for editors". This concisely sums up the portal's role. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Weak support for "The hub for editors", since I have no viable alternative.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:15, 15 June 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.

Miscellaneous discussionEdit

No consensus for proposals made in this section. Editors were roughly evenly divided on the suggested proposals
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.

  • There were several other proposed tooltip changes that got very little discussion and closed as no consensus. I don't want to overwhelm this discussion by creating a section to follow up on each of them, but I'll just throw them out here, and if they turn out to be uncontroversial, perhaps we can find consensus to implement them. They are:
  • For Special pages, change from "A list of all special pages" to "List of automatically generated pages for specialist purposes"
  • For Page information, change from "More information about this page" to "Technical information about this page"
  • For View user groups, change from nothing to "view the permissions of this user" (for non-admins) and "manage the permissions of this user" (for admins)
How do those sound? {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • The suggested extra wording for special pages and page information does not help, the original wording is good. For user groups, I don't see why different text for admin/non-admin users is needed, just "Permissions of this user" would be fine (that's all that is needed for a hint about what groups do). Johnuniq (talk) 07:27, 12 June 2020 (UTC)
  • I concur with Johnuniq regarding special pages. Although the current tooltip is pretty useless, the proposal seems far too long. I would instead propose "List of pages for specialised purposes" to cut out some unnecessary elaboration and to clarify that special pages are for particular uses, not particular users.
    I support the proposed changes for page information and user groups, they seem to clarify their respective purposes quite well.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • I'd like "List of system pages" for "Special pages", because that's effectively what it is. Support the other suggestions. Naypta ☺ | ✉ talk page | 19:46, 12 June 2020 (UTC)
"List of system pages" sounds good to me. {{u|Sdkb}}talk 06:31, 22 June 2020 (UTC)
  • Support all three: "A list of automatically generated pages for specialist purposes" ,"technical information about this page", and "view the permissions of this user." All three proposals make it more clear and are more accurate about what the targets do. In the past I have been confused by the titles and I think these tooltips would have helped. --Tom (LT) (talk) 07:41, 21 June 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.

Sidebar in mobile viewEdit

@Sdkb: All of the discussion on the sidebar has been about the sidebar in desktop view. I think we should also discuss how we can improve the sidebar in mobile view. Do you have any opinions on how we can do that? Interstellarity (talk) 20:49, 12 June 2020 (UTC)

Interstellarity, I think we could certainly have a discussion analogous to WP:SIDEBAR20 for mobile. My sense is that the WMF has been more heavily involved with that than they have been with the desktop view, so it might be good to start at the idea lab and research the background. There are also other discrepancies such as the fact that mobile makes it very easy to see a user's edit count whereas desktop mostly hides it; we could talk more about those at WP:Usability. {{u|Sdkb}}talk 21:32, 12 June 2020 (UTC)

Tidying up the sidebarEdit

I recently had an edit request declined at MediaWiki_talk:Sidebar#Protected_edit_request_on_12_June_2020 that should tidy up the sidebar a little bit. I think it is best that we seek consensus for this change. Pinging @MSGJ: if he would like to comment. Interstellarity (talk) 11:08, 19 June 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.

Adding IMDb & Rotten Tomatoes ratings to article infobox (wherever possible)Edit

Currently, no (or very few) articles about films, short-films, web-series, etc. on Wikipedia contains ratings provided by prominent sources like IMDb & Rotten Tomatoes at the Infobox of the article. Many people visit Wikipedia to get all the possible information about the Film including about its Critical Reception. Most articles written about any website contains its Alexa rank. If such articles can contain Alexa rank, then I believe that articles on movies must contain their IMDb & Rotten Tomatoes ratings. Soukarya (talk) 18:11, 17 August 2020 (UTC)

For the sake of keeping separate discussions distinct, I've split this thread into subsections below. Please place further comments in those sections. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
The topic of this discussion has been edited to include the word 'Infobox' to avoid further confusions regarding the proposal. Soukarya (talk) 12:04, 18 August 2020 (UTC)

Survey: IMDb in the infoboxEdit

Consensus to not use IMDb in the infobox. No-one but the proposer is in support. Prior to this discussion, there was recent consensus (WP:RSP#IMDb) that IMDb is not reliable for ratings as they are user-generated. There is no consensus here to overturn this decision, or to include such content in the infobox. (non-admin closure)Bilorv (talk) 21:27, 28 September 2020 (UTC)
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.

  • I don't think this is a good idea because they are user-generated data sources that are often subject to bloc manipulation so that they can't be trusted. We can't patrol these ratings, nor could we include notes alongside our inclusion of them (e.g., "This rating is known to have been manipulated") because then we're just including non-reliable data.--Jorm (talk) 18:25, 17 August 2020 (UTC)
    @Jorm: I've just created subsections to better organize this thread, and placed your comment here. Please feel free to refactor if needed. {{u|Sdkb}}talk 19:18, 17 August 2020 (UTC)
  • Hmm, I always take these ratings with a pinch of salt. IMDb ratings are representative of the people who could be bothered to vote, while ratings on Rotten Tomatoes are also subjective. It is best to stick to reviews by mainstream critics.--♦IanMacM♦ (talk to me) 18:21, 17 August 2020 (UTC)
    @Ianmacm: I've just created subsections to better organize this thread, and placed your comment here. Please feel free to refactor if needed. {{u|Sdkb}}talk 19:18, 17 August 2020 (UTC)
  • Oppose, since those can and have been subject to manipulation. See e.g. Washington Post's Trolls are doing whatever they can to bring down the 'Ghostbusters' reboot, and FiveThirtyEight's analysis of how IMDb ratings are systemically skewed toward the preferences of men. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
  • Oppose IMDB is a user-defined score and thus susceptible to review bombs and other factors and thus should not be considered a reliable measure. (but that's only one issue...) User review-based scores are normally not included in any article unless it is noted by third-parties (like review bombs) in the first place. --Masem (t) 19:38, 17 August 2020 (UTC)
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
  • Oppose Including IMDB ratings in the infobox would violated MOS:FILM#Audience_response which states "Do not include user ratings submitted to websites such as the Internet Movie Database, Metacritic, or Rotten Tomatoes, as they are vulnerable to vote stacking and demographic skew." Betty Logan (talk) 23:18, 17 August 2020 (UTC)
  • Oppose Very easy to manipulate. That link shows one of my favorite YouTube videos of all time...but you wouldn't know that looking at IMDb, as you would think it one of the top rated movies on IMDb of all time, ignoring the fact that its score is a result of a bunch of YouTube watchers manipulating the score. Also, putting IMDb in the infobox would only encourage folks to use it for other things, which we are already trying to fight against, as it is not a RS. CaptainEek Edits Ho Cap'n! 21:36, 19 August 2020 (UTC)
  • Oppose IMDb is generally not a reliable source and its use should be discouraged, except in very limited circumstances. Cullen328 Let's discuss it 21:40, 19 August 2020 (UTC)
  • Oppose An unreliable source. Its use in article space should be deprecated not encouraged. --Malcolmxl5 (talk) 14:03, 25 August 2020 (UTC)
  • Absolutely OPPOSE: per all of the above. Can this be SNOW closed by someone? GenQuest "Talk to Me" 18:16, 30 August 2020 (UTC)
  • Strongly oppose for the same reasons we don't cite these. Allowing them in the ELs is quite enough. DES (talk)DESiegel Contribs 22:26, 8 September 2020 (UTC)
  • Strongly oppose per all of the above. El Millo (talk) 22:45, 8 September 2020 (UTC)
  • Oppose-0 de tutti opposi. As mentioned above, this is a bad idea on almost as many levels as possible. Qwirkle (talk) 01:05, 9 September 2020 (UTC)
  • Oppose. Never trust audience reviews. Ever. --Enjoyer of World (talk) 12:17, 16 September 2020 (UTC)
  • Strongly oppose I think this proposition was made with the right intentions, but vote surfing is a known problem on IMDB in addition to it being a user-generated site. You can leave a review without ever even watched the film and thus the review statics are pretty skewed. Inter&anthro (talk) 01:44, 25 September 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.

Survey: Critic review aggregations in the infoboxEdit

Consensus to not use critic review aggregations in the infobox, including but not limited to Rotten Tomatoes and Metacritic. There is consensus that such aggregations are not factual content of the sort suitable for an infobox. Concerns have been raised that any individual aggregator methodology is not appropriate when presented in an infobox without further context. (non-admin closure)Bilorv (talk) 21:31, 28 September 2020 (UTC)
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.

E.g. Rotten Tomatoes, Metacritic

  • Support adding one of these scores, since it is pertinent information for readers. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
  • Oppose At least coming from video games, there are far too many times that just presenting the aggregate score by itself is a misnomer of how the game's reception should be taken. The score needs to be presented alongside other reviews and comments to give it perspective. (A recent case being The Last of Us II). I am sure the same can be said for films; a critically-panned film may be an audience favor which won't be captured by a single score. --Masem (t) 19:40, 17 August 2020 (UTC)
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
  • Oppose The infobox is for facts. Rotten Tomatoes and Metacritic are review aggregators, so their scores come with the "subjectivies" of which critics are approved and counted by them, plus every review's own subjectivity. Putting either or both scores in the infobox would give a quality of fact that they shouldn't have. El Millo (talk) 20:07, 17 August 2020 (UTC)
  • Oppose I agree with El Millo that the infobox is best reserved for factual information. The very next question in this survey (i.e. should we use RT or MC in the infobox?) undermines the argument for including an aggregator. Per WP:AGG there is no single authority on critical reception. Sometimes RT and MC can arrive at different conclusions due to their differing methodologies and sampling different reviews. Also, these aggregators don't work particularly well for foreign films (sample size is often too small) or older films (reviews are often spread out meaning a mix of contemporary reviews and revisionist ones—ideally you want to compare the initial reception with the modern day standing for a classic film). Betty Logan (talk) 23:25, 17 August 2020 (UTC)
  • Oppose We should be summarizing the assessments of professional film critics instead of allowing aggregators summarize for us. Cullen328 Let's discuss it 21:43, 19 August 2020 (UTC)
  • OPPOSE: InfoBoxes are for facts, and not necessarily all the facts, either. In fact, InfoBoxes are optional. Per CREEP. GenQuest "Talk to Me" 18:19, 30 August 2020 (UTC)
  • Oppose I don't think these should ever go in an infobox, much less "whenever possible" Too much context is needed to present such ratings in a useful way. If present, it should be in the article prose. DES (talk)DESiegel Contribs 13:34, 9 September 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.

Survey: Rotten Tomatoes vs. Metacritic for infoboxEdit

Outcome not implemented due to the close above that all critic review aggregations are inappropriate for the infobox. (non-admin closure)Bilorv (talk) 21:34, 28 September 2020 (UTC)
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.

If we decide above to include a critic review aggregation, which service should we include?

  • I'm not ready to make a bolded !vote on this, but the factors to weigh between them are that Rotten Tomatoes is more popular but Metacritic makes better use of statistics. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
Misplaced !votes
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
    MarnetteD, this is not a support/oppose section, it's an A/B question between Rotten Tomatoes and Metacritic. The section above where you already !voted is the one asking whether to include either. {{u|Sdkb}}talk 19:04, 18 August 2020 (UTC)
    • I oppose both so my previous post is correct. MarnetteD|Talk 20:02, 18 August 2020 (UTC)
  • Oppose both. Cullen328 Let's discuss it 21:44, 19 August 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.

General discussionEdit

Please note that policies and guidelines for this already exist. See Wikipedia:Manual of Style/Film#Critical response and MOS:TVRECEPTION as well as this essay Wikipedia:Review aggregators. The OP may not be aware that a large percentage of the film articles include RT ratings. IMDb should not be included as they are simply a fan poll and of no critical or scholarly value. MarnetteD|Talk 19:16, 17 August 2020 (UTC)

@MarnetteD: I think the OP is asking primarily about infoboxes. I just refactored the subsections to make that explicit. Sorry for doing such aggressive refactoring here; I'm trying to put this on a focused/defined path before it gets too far off the ground. Soukarya, please let me know if you have any issue with it. {{u|Sdkb}}talk 19:26, 17 August 2020 (UTC)
At no point in the OP's statement is the word infobox used. If that is what they mean then please note that this has been discussed numerous times at the filmproject and been rejected. Perhaps Betty Logan or Erik (who both have much better memories than I do) can direct you to the archived discussions. MarnetteD|Talk 19:32, 17 August 2020 (UTC)
In fact the header for the thread clearly reads "Adding IMDb & Rotten Tomatoes ratings to articles (wherever possible) (emphasis mine) so your refactoring the subheaders to add the word "infobox" is just confusing the issue. I would suggest closing this thread down as (again) policies already exist regarding this. MarnetteD|Talk 19:43, 17 August 2020 (UTC)
"Infobox" is added here. Bus stop (talk) 19:48, 17 August 2020 (UTC)
Thank you for fixing my misreading of the post Bus stop Apologies for the error. The title of the thread is part of the confusion. I didn't locate the past discussions yet but I did find this WP:FILMRATING whixh is also part of WP:MOSFILM. MarnetteD|Talk 19:54, 17 August 2020 (UTC)
Here is one past discussion Template talk:Infobox film/Archive 24#Rotten Tomatoes. Another problem is once you make room for one aggregate website then you have to keep adding them which leads to infobox bloat - a thing that is always to be avoided. MarnetteD|Talk 19:59, 17 August 2020 (UTC)
If we reach any consensus on whether to add any ratings to the infobox, then we can continue our discussion on what aggregate websites could be the most reliable ones and stick to some policy that allows ratings of only a few aggregators that would be recognised by most of the Wikipedia editors. Soukarya (talk) 12:17, 18 August 2020 (UTC)
Sorry for the inconvenience caused to you, and thanks for highlighting this issue with the title of the thread, which I have edited to make the title more informative. Soukarya (talk) 12:17, 18 August 2020 (UTC)
  • It looks like this thread isn't going anywhere, so I'm fine with it being SNOW closed. We may at some point want to discuss RT vs. Metacritic in the body, and as always there's tons of work to do to improve documentation of past consensus. {{u|Sdkb}}talk 05:52, 18 August 2020 (UTC)
    OTOH, several of these, especially IMDb, get added as ==External links== in thousands of articles. I'd rather see them in a little(!) footer bar, similar to Template:Medical resources (which normally takes up a single line on a not-very-big laptop screen, because while there are lots of options, only a few apply to any particular subject). I asked at WP:BOTREQ about this, and if we wanted to build something that would provide these external links, but take up less space than listing each as a separate item in a bulleted list, they thought most articles could be converted to the smaller format by bot. WhatamIdoing (talk) 03:51, 20 August 2020 (UTC)
I would certainly support this ^^^ as a proposal. Regards, GenQuest "Talk to Me" 18:21, 30 August 2020 (UTC)
That kind of change would need site-wide consensus, and I think it might be hard to get. DES (talk)DESiegel Contribs 13:36, 9 September 2020 (UTC)
  • I think the infobox is the absolutely wrong place for this kind of content. There might be room for a standardized template in something like the "critical reception" section to give links to Rotten Tomatoes, iMDB, Metacritic, etc. that would include aggregate ratings, but I would suggest that would be a stylistic and operational decision for WikiProject Films/Cinema/Movies/whatever. VanIsaacWScont 01:52, 25 September 2020 (UTC)
    Vanisaac and Inter&anthro, your comments adding on to the pile were well-intentioned, but the consensus was already clear and the discussion had died weeks ago, so unfortunately all they did was reset the archiving clock when this thread was just about to be archived, keeping it cluttering this page for longer. Next time, please consider just ignoring it and letting it be archived. {{u|Sdkb}}talk 20:05, 26 September 2020 (UTC)
    Whoops sorry about that I had not noticed. My apologies for the inconvenience. Inter&anthro (talk) 20:08, 26 September 2020 (UTC)
    @Sdkb:I would kindly ask that you not disparage me as beating a dead horse. In my comments I specifically added thoughts on a constructive way forward, as the proposal may be dead, but the issues it was trying to address remain alive and well. We owe that consideration to each other in a collaborative environment. If you want to prevent further additions to a discussion, the proper ways of effecting that end are to have the discussion closed or archived. VanIsaacWScont 21:26, 26 September 2020 (UTC)
    Vanisaac, apologies, I didn't mean it as disparagement and that essay wasn't the most fitting link. The impetus for my comment came from just observing that the long discussion here wasn't a very efficient use of editor time, when the thread should have been curtailed as soon as it was clearly snowing. The pump (and Wikipedia in general) doesn't have a good curtailing mechanism, which leads to threads like this fairly often; I hope we'll eventually find a way to address that more fundamental issue better. {{u|Sdkb}}talk 21:47, 26 September 2020 (UTC)
    Sdkb, that's okay. We all need a bit of grace when working together, and I probably took the reference to DEADHORSE a little too personally. If you want to add {{User:ClueBot III/ArchiveNow}} to the top of the section, the last addition before our two interlocutions was more than 9 days ago, and would have triggered automatic archiving already. Otherwise I'll get it archived tomorrow. VanIsaacWScont 22:08, 26 September 2020 (UTC)

Displaying A-class topiconsEdit

Hello everyone, my name is Rebestalic

In short: Should we display A-class topicons for A-class articles?

The display of these topicons is inconsistent--before I entered into an interesting discussion with J Milburn, Nina Simone and the Battle of Pusan Perimeter had it on beside their Good Article topicons, while A-classers without the topicon included the one for the Atomic bombings of Hiroshima and Nagasaki.

J Milburn, who is a broom (REBESTALIC IS A TOADY ALERT), mentioned that he was 'not aware of any policy or guideline recommending their inclusion'. Perhaps now would be the time to make such a policy?

🤔 Rebestalic[leave a message....] 00:43, 27 August 2020 (UTC)

J Milburn, who is a broom (REBESTALIC IS A TOADY ALERT) What? ST47 (talk) 05:02, 27 August 2020 (UTC)
I believe this is a bit of light humour referencing J Milburn's administrator status. – Teratix 05:45, 27 August 2020 (UTC)
As a quick bit of background -- I came across an A-class article with a "topicon" by chance and removed it. I later checked, and found about 15 articles had A-class topicons, and removed them all. These articles were mostly military history, but there were a few of others, including one that decidedly was not A-class. Featured articles, featured lists, and GAs routinely have topicons. Off the top of my head, when we introduced topicons for GAs -- it was in my memory, but not that recently -- there was a centralised discussion about it. I don't have a very strong opinion about whether A class articles should have topicons (I lean against, simply because A class is not as centralised or codified as FA or GA, at least as far as I can see) but I don't think they should just be added in by a few editors who'd like to see them. If it's going to happen, there needs to be a central discussion about it. If this is that central discussion, so be it. Josh Milburn (talk) 07:26, 27 August 2020 (UTC)
@ST47: My apologies for not being as clear as I could be, Teratix is right with my horrific sense of humour Rebestalic[leave a message....] 21:22, 27 August 2020 (UTC)
  • Lean support although I have my doubts w/r/t decentralization. – John M Wolfson (talkcontribs) 23:58, 27 August 2020 (UTC)
  • Comment: Apart from MILHIST, what other projects actively conduct A-class reviews? Are the qualities of their A-class articles comparable? They should be if a topicon is to be consistently displayed for all such projects. Otherwise, approval could be on a project-by-project basis. --Paul_012 (talk) 09:38, 28 August 2020 (UTC)
Hey Paul 012, I actually asked a question about this just after I joined Wikipedia! It was at the Teahouse, and the replier directed me to the A-class articles category. I had a look at it just now, and it was mostly just empty categories. I haven't the faintest clue which category Nina Simone fits into, because I don't suppose she had much to do with military history
Consider the Grades section of the content assessment page though; on the column with the class codes, the Featured Article, Featured List, Good Article and A-class fields all have their topicons beside, while all the poorer-quality classes (like B- and C-class) don't. I wonder why there's no such thing as a 'Good List' as well? But thank you for giving your opinion to my thread! Very exciting for me Rebestalic[leave a message....] 11:10, 28 August 2020 (UTC)
  • Lean against - I prefer only having the plus/star, based on proper, centralised, peer review. For A-class to work, we'd have to review each project that wanted to offer them and decide that the project had a good enough system to handle that review, probably with a delisting process external to that project. Nosebagbear (talk) 14:23, 30 August 2020 (UTC)
  • Comment: We need to figure out, at a fundamental level, what it is we're hoping to achieve by having A-class as a designation before we can answer this question. I'm not sure we can even agree on whether A-class is higher or lower than GA, let alone expect readers coming across the topicon to be able to distinguish it. Has there been talk (other than my brief question here) about deprecating A-class and making review of military history articles some sort of subtrack within GA?
That said, generally speaking, I support (as I have in the past) making article ratings more available to readers. It's important for maintaining trust that we make it clear which parts of the encyclopedia they can generally trust and which are still under construction The stumbling block is making sure that ratings are accurate enough, and there's issues particularly with the ratings in the middle of the spectrum. {{u|Sdkb}}talk 20:51, 3 September 2020 (UTC)
  • Lean oppose. While receiving an A-class assessment is a good indication of article quality, it's not the product of any uniform or standardized peer-review process. It has a place (the article's talk page), but it's different from GA or FA in the sense that it (like every Wikiproject assessment) is completely localized. It shouldn't be elevated to the same place as a community-wide designation. -- ExParte talk 16:19, 5 September 2020 (UTC)
Changing my !vote to lean support.. While I do still have some misgivings about elevating something w/o a uniform standard like an A-class rating, WikiProjects are probably best qualified to assess the reliability of an article within their purview. And when an article receives that designation, it's a useful thing for a reader to be aware of so they can consider that when determining how much to lean on it. -- ExParte talk 07:56, 9 September 2020 (UTC)

Thanks for your contributions here, Ex Parte! Rebestalic[leave a message....] 01:51, 11 September 2020 (UTC)

  • I am not aware of any A class processes outside of MilHist. Are there any? If they were equivalent to what MilHist does I'd be open to this idea. If it's only MilHist that has an active process I'm opposed. Best, Barkeep49 (talk) 00:42, 24 September 2020 (UTC)
    Video games deprecated theirs in favor of GA, and I would guess most other WikiProjects basically never had an interesting/relevant A-class assessment. Looks like mostly MILHIST and Hurricanes with functioning A-class systems. --Izno (talk) 01:29, 24 September 2020 (UTC)
    Wow, so we really have an entire class that's functionally reserved for just two projects? If this were anywhere but Wikipedia, A-class would have been deprecated long ago. {{u|Sdkb}}talk 02:36, 24 September 2020 (UTC)
    There are have been previous discussions. The biggest reason why not is because the quality level allows WikiProjects to assess things as the best that WikiProject has to offer (rather than as the community has to offer). Ostensibly, it's also to indicate a different focus from what GA/FA have to require. Lastly, they are good stepping stones for the two projects to get their quality up on the different interests that GA/FA have. I don't see a fundamental issue with leaving the systems in place if it's working for those groups. --Izno (talk) 02:48, 24 September 2020 (UTC)
    Projects with A-class articles include Military History (629), Cyclones (133), US Roads (22), Chemicals (8), Cars (7), Japan (7), Carnival (3) Lebanon (2) and Science Fiction (2). While about three quarters belong to the first two, there are another 250 or so scattered across dozens of projects. Hawkeye7 (discuss) 03:10, 24 September 2020 (UTC)
  • Solid oppose. This classification is specific to the WikiProject and is not representative of the community review processes that GA and FA provide. (And, the categorization is basically-unused outside two particular projects.) --Izno (talk) 02:48, 24 September 2020 (UTC)
    FA does not provide this, so A class is the highest review process we have. Hawkeye7 (discuss) 03:10, 24 September 2020 (UTC)
  • Oppose since it's only really used by one project. It would be better to find some way to map MilHist's assessments onto those used by the wider community (e.g. providing a process to automatically recognise MilHist's A-class articles as GAs). – Joe (talk) 10:04, 24 September 2020 (UTC)
  • Oppose Individual wikiproject assessment ratings belong on the talk page. AIRcorn (talk) 06:08, 28 September 2020 (UTC)

Succession boxes for US PresidentsEdit

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:

  1. The succession boxes should be included in all U.S. presidents' BLPs.
  2. The succession boxes should be omitted from all U.S. presidents' BLPs.
  3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

I genuinely believe they help navigation between articles, though they could often be trimmed down to avoid trivial items, and if they are too large, they can be collapsed into the Offices and distinctions box. That way if you are looking for them, they are there, but if not they are not taking up a lot of space at the bottom of the article. ScottishNardualElf (talk) 08:55, 1 September 2020 (UTC)

  • 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss  09:26, 1 September 2020 (UTC)
  • 2 - succession boxes are such an outdated navigation tool on We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)
  • 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)
  • 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)
  • 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)
  • 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. (talk) 05:38, 15 September 2020 (UTC)
  • 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)

Flatten your succession boxes and/or absEdit

So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed):

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

Unrecognized positions such as Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss  12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss  13:35, 1 September 2020 (UTC)
Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss  13:03, 1 September 2020 (UTC)
A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)
@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss  13:23, 1 September 2020 (UTC)
No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)
Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)
@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss  15:14, 11 September 2020 (UTC)
  • I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)
  • Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ~Hydronium~Hydroxide~(Talk)~ 02:28, 19 September 2020 (UTC)

Expansion of scope: succession boxesEdit

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss  14:44, 1 September 2020 (UTC)
It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)
That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss  15:49, 1 September 2020 (UTC)
I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)

Central notice banner discussion for "Wiki loves SDGs" on 19-26 September 2020Edit

The week during which this banner would have been displayed has now passed. Bishonen | tålk 08:11, 27 September 2020 (UTC).
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.

I put up a central notice banner request for an online editathon that I am involved with for the period 19-26 September 2020. It would be for the English Wikipedia in those countries that don't already have another banner at the same time (there is one for Wiki loves Monuments and for fundraising also going up in September, it seems). I was told by an admin on Meta that it should be discussed on Village Pump, that's why I am writing here now (I hope I have put it in the right section). Here is the link to the discussion so far: . The admin advised me: "Hi @EMsmile:, in the meantime: is the English community okay with yet another global banner? Could you please share a link to a place where this was discussed? The English community sometimes is a bit hesitant to allow another banner, therefore it would be good in inform the community and seek consensus. " What do you all think? More details about the campaign is here: Or see for more information about the online editathon here. It's about the 17 Sustainable Development Goals and all the topics related to that (which are loads). EMsmile (talk) 11:13, 7 September 2020 (UTC)

  • I have the same opposition to this as I do to the current one - I don't really like the "Wiki Loves X" style, since if you asked us to openly campaign for their better implementation on-site, people would oppose on the grounds that we aren't supposed to be campaigning. Now, it won't be running in my country (UK), the editor is in GF, and it's not a major thing, so I'm willing to be neutral on the issue. Nosebagbear (talk) 10:49, 8 September 2020 (UTC)
Hi User:Nosebagbear, thanks for your comment. Just wondering what you meant with "the editor is in GF"? This is a campaign to get more people from the Global South (developing countries) to edit topics that are particularly (but not only) relevant to the Global South, and especially new female editors. It's a campaign to improve existing Wikipedia articles. In which sense do you mean "we aren't supposed to be campaigning"? Personally, I would have preferred "Wikipedia loves SDGs" over "Wiki loves SDGs" but others that were involved in starting this preferred the shorter version of the project title... EMsmile (talk) 14:07, 8 September 2020 (UTC)
@EMsmile: - I meant to just write "the editor is GF (good faith)", and just tripped up over the grammar. I share the preference for Wikipedia over Wiki, but I decided a while back it wasn't worth picking that as the hill to die on. Wikipedia doesn't campaign except on things that are inherent threats to our functionality (most recently, for example, there was a very staunch decline on blacking out for BLM). I've no objections to more/better articles on the SDGs at all. However "Wiki loves SDGs" isn't just a more pithy version of "Wiki(pedia) loves writing about the SDGs" - if you asked someone to tell you what it meant, they'd feel it read as Wikipedia pushing them, hard. Nosebagbear (talk) 14:13, 8 September 2020 (UTC)
If this is mainly creating/improving articles, I would recommend: 'Wiki writes . . .' or 'Wiki writes about . . .'. Alanscottwalker (talk) 14:21, 8 September 2020 (UTC)
It's mainly about improving articles and interlinking them better. Are you both saying you don't mind a banner on this, but you don't like if the banner says "Wiki loves SDGs"? Would you be happier if the banner had a different text? The banner is meant to alert people to join the week-long effort (during Global Goals Week) to improve SDG-related articles on Wikipedia (of which there are hundreds, see here). EMsmile (talk) 14:55, 8 September 2020 (UTC)
Who is Wiki? Do we know this person? A wiki is not sentient and so cannot love anything. Wikipedians may love other people (Wikipedians or not), but in this case they might be keen, enthusiastic, determined or they might wish to promote, encourage, enhance or even solicit, importune, invite. As for "SDG's" or "SDGs", just spell it out in full. Are we that short of space? So, all in all a horrible choice of wording. Or is the inherent wrongness just contrived to catch our attention? — GhostInTheMachine talk to me 17:34, 8 September 2020 (UTC)
  • Sounds great! Thanks for organizing. Some people don't love "Wiki Loves..." because it implies endorsement by everyone. Hence it was disappointing but not surprising when advertising a "Wiki Loves Pride" event was controversial. It is a fairly well established naming format (Wiki Loves Monuments, Wiki Loves Earth, etc.), though, and are the SDGs controversial? Are there people who don't want to be seen endorsing things like "no poverty" and "zero hunger"? Would support the notice under whichever name it winds up being, but since it seems like there's already some organizing behind this under that name, it's probably best to keep it as-is, noting for future organizers that "Wiki Loves" causes more hesitancy than other verbs. — Rhododendrites talk \\ 17:03, 8 September 2020 (UTC)
    Yes. Some might object to Wikipedia endorsing a designed-by-committee laundry list of technocratic platitudes papering over the absurdity of globalised capital fixing the social and ecological crises it created. But hey, there's always going to be someone who objects. I don't think that should stop anyone making a good faith effort to increase participation in the project. – Joe (talk) 18:07, 8 September 2020 (UTC)
Thanks for this link, User:Joe Roe. Those articles that criticise the SDGs and their process is exactly what I ALSO want to bring to Wikipedia. We already have a section on "reception" in the SDG article ( where those things can be discussed / cited. The section was called "criticisms" before but I was told as per WP:CRIT that's not the right way to do it. I definitely want to provide a balanced view and if there are scholars and NGOs who have criticised the SDGs then this ought to be included. It might even warrant a spin off article lated that deals specifically with that, like "Controversies about SDGs". Existing UN websites that explain the SDGs are obviously very biased and make it all sound clear and easy... Having said that, we do also want to edit all the SDG-related topics (and link them with SDG articles); these are topics like maternal mortality, FGM, birth registration, forced marriage but also climate change, eutrophication, ocean acidification and so forth (see list here). By saying that the editathon will be about SDG-related topics (not just the SDGs) we would actually cover a large number of articles, many of which are highly relevant to the Global South / developing countries - an area that has traditionally received less attention on Wikipedia, simply because editors are volunteers and tend to write about what they know and care about. If the editors are from Europe and North America then naturally they are less inclined to write about such topics which don't immediately affect them. EMsmile (talk) 04:22, 9 September 2020 (UTC)
  • This gives me pause: The nine most active volunteers will receive a cash prize at the end of the edit-a-thon of 100 Eur each (Wikipedia:Meetup/Online edit-a-thon SDGs September 2020#Prizes). You're vague about what "active" means and sending the message to potentially thousands of new editors that lots of edits = money could cause a mess. WLM's prizes get around this by making it clear they're for quality not quantity. – Joe (talk) 18:26, 8 September 2020 (UTC)
Thanks for pointing this out, Joe. I have changed it now to say: "The nine volunteers who have made the most valuable contributions during the editathon will receive a cash prize at the end of the edit-a-thon of 100 Eur each. The organizers will determine who the volunteers with the most valuable contributions were based on quality and quantity of their editing contributions. To make this judgement, the editors will carefully review the volunteers' contributions as per the data collected in the event's dashboard here. " (Wikipedia:Meetup/Online edit-a-thon SDGs September 2020#Prizes) I think valuable equates broadly to quality and quantity, would you agree? I couldn't find the exact criteria that WLM uses for their prizes (could you point me to the exact location if you have it? The link that you gave didn't show me that information).
  • How about this for a compromise with regards to the wording of the banner: We include both the long version and the short version. Short version is "Wiki loves SDGs". Long version is: "Wikipedians meet online to improve articles that touch on topics related to the Sustainable Development Goals"? (I am also not a big fan of the short version but I have been told by people with experience with volunteers and activities on SDGs that this would work and has potential to galvanise people into action, get them curious and get them to come to Wikipedia). Maybe the title "Wiki loves SDGs" works better outside of Wikipedia but for inside of Wikipedia we could more push the longer version? EMsmile (talk) 04:26, 9 September 2020 (UTC)
  • Oppose, for the following reasons:
    • The CentralNotice has been heavily overused recently. We should not have another broad campaign to all users now, especially with Fundraising season coming up. It's important to not use the banners too frequently.
    • SDGs are not exactly such a broad topic that the expected editing is likely to be sufficient to justify displaying the banner to such a broad audience (that is, the entire readership). Very few users are likely to have something to contribute to this.
    • Anything near the area of public policy is risky from a neutrality standpoint. It's difficult to simultaneously communicate that we'd like to write about these topics, but we are neutral and have no involvement in actually accomplishing any of these goals, and are not interested in supporting them. It's even harder when the name is "Wiki Loves SDGs".
  • --Yair rand (talk) 04:32, 9 September 2020 (UTC)
I just want to point out that the banner wouldn't be for the entire English Wikipedia readership but only for people in those countries who don't already have the Wiki loves Monuments banner or the Fundraising banner. If possible, I would like to have it visible for all readers in the "Global South" developing countries, or if that's too hard, all of Africa and Asia (which is where the SDGs are furthest behind). - Regarding the issue of implying support or not: Another option could perhaps be to say "Wiki loves sustainable development"? Or "Wiki loves sustainability"? as those would be concepts that Wikimedia Foundation has officially endorsed if I am not mistaken (see for example here where it says "Last year, the Wikimedia Foundation created a group called the Sustainability Consortium"? - With regards to overuse of banners: perhaps it depends which country you live in. I live in Australia and I find we get very few banners here. The only ones I have seen in the last 12 months seem to be Wiki loves monuments and perhaps a fundraising banner - at least I can't remember any other ones. Doesn't feel like overuse. Perhaps they get used more in the United States and Europe? I am not sure. (whether they actually attract more editors in the end I don't know either; I guess there is some research about that somewhere) EMsmile (talk) 06:45, 9 September 2020 (UTC)
Which of the large countries where English is widely spoken would the proposed banner appear in?--Wehwalt (talk) 14:06, 9 September 2020 (UTC)
Our focus would be on developing countries. We could go by this list (List of territorial entities where English is an official language) minus the countries where Wiki Loves Monuments has a banner in September (those are shown here), minus the countries where there is a fundraising banner (they are all not developing countries, i.e. US, GB, MZ, AU, CA, IE). Wiki Loves Monuments does not have many developing countries on the list, except for example Benin, Brazil, Egypt, India, Nepal, Uganda. So maybe keep it simple and only take countries in Africa, Asia and Carribean which would be these (taken from here):
Countries where English is a de jure and de facto official language
Nr Country Alpha-3 code Region Population1 Primary language?
5 Botswana BWA Africa 1,882,000 No
6 Burundi BDI Africa 10,114,505 No
7 Cameroon CMR Africa 22,534,532 No
11 Eswatini SWZ Africa 1,141,000 No
13 Gambia GMB Africa 1,709,000 No
14 Ghana GHA Africa 27,000,000 Yes (used as lingua franca)
20 Kenya KEN Africa 45,010,056 Yes (in business and education)
22 Lesotho LSO Africa 2,008,000 No
23 Liberia LBR Africa 3,750,000 Yes
24 Malawi MWI Africa 16,407,000 No
29 Namibia NAM Africa 2,074,000 No (used as lingua franca)
31 Nigeria NGA Africa 182,202,000 Yes (used as lingua franca)
37 Rwanda RWA Africa 11,262,564 No (but official and educational)
43 Sierra Leone SLE Africa 6,190,280 Yes
46 South Africa ZAF Africa 54,956,900 Yes (and official, educational and

lingua franca in formal economy)

47 South Sudan SSD Africa 12,340,000 No
48 Sudan SDN Africa 40,235,000 No
49 Tanzania TZA Africa 51,820,000 No
53 Uganda UGA Africa 37,873,253 No (but official and educational)
55 Zambia ZMB Africa 16,212,000 No
56 Zimbabwe ZWE Africa 13,061,239 No (used as lingua franca)
27 Mauritius MUS Africa / Indian Ocean 1,262,000 No
42 Seychelles SYC Africa / Indian Ocean 87,000 No
17 India IND Asia 1,247,540,000 No (but official and educational)
33 Pakistan PAK Asia 212,742,631 No (but official and educational)
36 Philippines PHL Asia 102,885,100 Yes (co-official with Filipino)
44 Singapore SGP Asia 5,469,700 Yes (used as lingua franca, mostly and widely spoken, and educational)
1 Antigua and Barbuda ATG Caribbean 85,000 Yes
2 Bahamas BHS Caribbean 331,000 Yes
3 Barbados BRB Caribbean 294,000 Yes
10 Dominica DMA Caribbean 73,000 Yes
15 Grenada GRD Caribbean 111,000 Yes (except for small French Creole population)
19 Jamaica JAM Caribbean 2,714,000 Yes
38 Saint Kitts and Nevis KNA Caribbean 50,000 Yes
39 Saint Lucia LCA Caribbean 165,000 Yes
40 Saint Vincent and the Grenadines VCT Caribbean 120,000 Yes
51 Trinidad and Tobago TTO Caribbean 1,333,000 Yes
4 Belize BLZ Central America 288,000 Yes

EMsmile (talk) 05:02, 10 September 2020 (UTC)

I feel a little drowned in information. Let me put it this way, of the US, Canada, UK, Australia, New Zealand, India, Pakistan, Eire, which of these would take the proposed banner?--Wehwalt (talk) 17:51, 10 September 2020 (UTC)
User:Wehwalt Of the list that you mentioned, only developing countries would get the Wiki loves SDG banner, so that's Pakistan and India from your list (but not India if it already has the Wiki loves Monuments banner at the same time).
Much obliged, thanks.--Wehwalt (talk) 06:51, 11 September 2020 (UTC)

As a resident of the Southern United States, I take great offense to any analogies implied by the term "Global South". Moreover, it's [geographically inaccurate]. I hope you don't intend for it to actually appear in the banners. ―cobaltcigs 00:37, 11 September 2020 (UTC)

User:cobaltcigs, yea well, the term global South exists and has its own controversies which are well explained in its Wikipedia article (Global South). Whether it "sticks" remains to be seen. Equally, someone living in Australia could take offence. Anyhow, I prefer to use the term developing countries but there are others who object to that term as well. See here. It's not easy. The banner would not include the term Global South, but would use the term "developing countries" or actually not mention the region at all. My proposal was: Short version is "Wiki loves SDGs". Long version is: "Wikipedians meet online to improve articles that touch on topics related to the Sustainable Development Goals". The SDGs are officially for the entire world, but of course it's the developing countries that have the hardest job to achieve them. EMsmile (talk) 06:34, 11 September 2020 (UTC)
Great project EMsmile, I love it. The global goals are worthy in itself to be thoroughly covered in Wikipedia as they have been agreed upon by more than 190 members of the UN in 2015. In 2019 the Wikimedia movement held its annual international conference Wikimania in Stockholm. The motto of the conference was: "Stronger Together: Wikimedia, Free Knowledge and the Sustainable Development Goals." The Wiki loves SDGs project, a one week virtual editathon, is a natural follow up to this conference. We owe it to the world to do this. It is the least thing we can do after we have gathered with a crowd in Stockholm over a year ago, and have been talking about what we can do. Ad Huikeshoven (talk) 14:28, 15 September 2020 (UTC)
Thanks, Ad Huikeshoven. That's really useful to be reminded of last year's Wikimania's theme. - If we get that banner up for those countries that I have listed above, would many of you agree with this banner title?: "Join us for "Wiki loves SDGs" during 19-26 September: Wikipedians meet online to improve articles related to the Sustainable Development Goals". The online platform that we'll use for interactions in that week is Workplace by Facebook by the way, see here. EMsmile (talk) 15:53, 15 September 2020 (UTC)
the draft of the banner is now visible here (see at the very top of the page): . It will only be displayed in certain countries, mainly developing countries (as discussed above). What do you think of the banner? Can you live with it? Any suggestions for improvements? EMsmile (talk) 03:26, 18 September 2020 (UTC)
  • WP is intended for information, not for advocacy. We may need to extend our coverage in this area, but we shouldn;t be making a moral principle out of it, or giving it undue visual prominencem or using using what will be to a non-WPedian unfamiliar abbreviations. We should just write the articles. If we need to organize to find the necessary information, that would be a good thing, but we shouldn;t mistake displaying prominent banners with the need to do actual work. DGG ( talk ) 00:59, 19 September 2020 (UTC)
So... did "we" decide to do this? Is it happening right now? — JohnFromPinckney (talk) 10:26, 24 September 2020 (UTC)
I guess I will never get an answer. (IT's okay, there are many unsolved mysteries in my life.) — JohnFromPinckney (talk) 21:56, 26 September 2020 (UTC)

Oppose any banners, any place, any time. Please read the Wikipedia Mission Statement. GenQuest "Talk to Me" 11:13, 24 September 2020 (UTC)

I concur in this opposition to such spam, advocacy or worse. See my fuller comment here: Village_pump_(policy)#Request_to_stop_non-encyclopedic_self_advertising:

I am a (minuscule) part of Wiki and I do not love X. Not in my name.

Zezen (talk) 18:55, 26 September 2020 (UTC)

  • SDGs are (now that I've looked up what it means) a more reasonable thing to love, especially for one week only, than the effing monuments that Wiki apparently loves in my name for an extremely long time (when is that banner going away, if ever?). But the week in question, 19-26 September, has just passed. Could this thread be closed now, please? I hope the editathon went well, EMsmile! Bishonen | tålk 19:36, 26 September 2020 (UTC).
thanks, Bishonen. Yes, the thread could be closed now (how do I close a thread?). EMsmile (talk) 02:20, 27 September 2020 (UTC)
You can use the {{archive top}} and {{archive bottom}} templates. I'll do it. Bishonen | tålk 08:11, 27 September 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.

Local Language requirementsEdit

Simply that where available place names should be accompanied by their local language name. EG The learning of Scots Gaelic (Gàidhlig) is increasing. So, placenames like Glasgow should also display as Glaschu,(Glasgow has the highest percentage of Gaelic speakers in Scotland) Fort William should display An Gearasdan. — Preceding unsigned comment added by Tartanthing (talkcontribs)

I think you mean that Glasgow has the highest absolute number, not the highest percentage. Phil Bridger (talk) 13:25, 12 September 2020 (UTC)
Aren't local names are already displayed in the article on Glasgow? – Teratix 04:10, 14 September 2020 (UTC)
They are at the Fort William, Highland article as well. Including alternate “local language” names for places is a fairly standard practice. Blueboar (talk) 11:36, 14 September 2020 (UTC)
  • I think a rule of thumb is that only names used in the local road signs are worth putting in, at least in the lead. Last time I was in Glasgow I don't remember seeing any "Glaschu" in signage. It is potentially misleading for readers from far away to suggest that the locals use a different name from that in the title, the way those in say Rome and Naples do. I see that Fort William railway station uses the Gaelic name (sometimes by itself) in platform signs etc, but Glasgow Central station does not. "Glaschu" is not the "local language" name at all - that is Glasgow. Johnbod (talk) 17:02, 14 September 2020 (UTC)
Johnbod are you suggesting that should apply to all place names or just Scottish ones? An example is Cambridge Bay which has the traditional name Iqaluktuuttiaq but there are not any road signs with that on it. Tartanthing the use of other names is common on Wikipedia as per the example in the previous sentence and Kiev or Kyiv. Perhaps the reason many Scottish place names are missing is because nobody added them yet. CambridgeBayWeather, Uqaqtuq (talk), Huliva 23:56, 15 September 2020 (UTC)
In terms of what we show right at the start of the lead, yes. I think we are frequently misleading readers by failing to distinguish between eg Belgian names, where both versions are actually used, and other places where they aren't. I said it was a rule of thumb - are you likely to hear Iqaluktuuttiaq on the street? Johnbod (talk) 03:01, 16 September 2020 (UTC)
Yes it is heard. There are several organizations using it in the name like the Ikaluktutiak Co-op and the Ikaluktutiak District Education Authority. Anybody speaking Inuinnaqtun or Inuktitut will use it. In those languages the proper name for Cambridge Bay is Iqaluktuuttiaq, spelt several different ways. In written documents Cambridge Bay is always translated as Iqaluktuuttiaq. CambridgeBayWeather, Uqaqtuq (talk), Huliva 18:29, 16 September 2020 (UTC)
(Belatedly) - oh well, that's fine then. But shouldn't they add it to the road signs? Johnbod (talk) 13:25, 23 September 2020 (UTC)j

RfC: Alexa Rankings in InfoboxesEdit

What should be done with Alexa rankings in infoboxes? -- GreenC 17:19, 18 September 2020 (UTC)

This is a follow-up to the well-attended discussion here about a year ago about what to do about Alexa Rankings in infoboxes. For example WebCite contains |alexa=  107,988 (December 2018)

Summary of problems:

  1. The Alexa numbers change monthly and quickly becomes misleading when outdated.
  2. The ranking data is proprietary (Amazon) and there is a tiered fee to access it via API, with the free tier limited to 1,000 queries a month. There are about 5,000 instances of {{infobox website}} that contain |alexa=.
  3. It can be web scraped.. but when done on a regular basis and loaded into Wikipedia it would almost certainly violate copyright or a terms of use rule, if not cause an outright IP block.
  4. The data can be manually checked and added to Wikipedia.. but in practice done sporadically see the WebCite example (2 years old as of this post), I have seen some over 5 years out of date.

The RfC proposes three options:

  1. Keep Alexa rankings in infoboxes as is currently done.
  2. Remove Alexa rankings from infoboxes entirely.
  3. Automate a solution that has no recurring article edits. Possibilities include:
    • Pull data from Alexa to local hosting (Commons tabular data, Wikidata, etc.) using the Amazon API at the rate of 1,000 per month. This would then display in the infobox via Lua. For example it could look like:
    • Create a new template {{webrank}} that displays static generic link(s). For example the Wikipedia infobox currently:
      |alexa=  13 (Global, August 2020)
      Would instead appear as: |webrank=Alexa, SimilarWeb
Automated solutions could be mixed ie. the top 1000 are done via API and the remainder via static links .. or some other idea. #3 is a single option for RfC purposes.

Please !vote your preference in order eg. "1 or 2 or 3 in that order" or however you want to word it.

Due to length of time previous participants pinged: @Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists: -- GreenC 17:19, 18 September 2020 (UTC)

Survey (Alexa Rankings in Infoboxes)Edit

  • As in previous discussions, it should be removed. So I guess that's a bold 2. --Izno (talk) 18:42, 18 September 2020 (UTC)
  • Option 2 These rankings seem to hit more than one item in WP:NOT including WP:NOTDIRECTORY and WP:INDISCRIMINATE. What do the rankings even tell a reader - that some people at some point in time used Alexa for something. IMO they are of no more critical or scholarly value than IMDb ratings. Also why is preference being given to Alexa over other things like Siri? Didn't Ray Bradbury write a short story about one of these automated services taking over the children of an entire town or country. If he was still alive I guessing he would pen one now. MarnetteD|Talk 18:59, 18 September 2020 (UTC)
  • Option 2 The rankings are uncylopedic, as they change alot. Also: Arsonxists (talk) 19:30, 18 September 2020 (UTC)
  • Keep some sort of traffic metric. I'm new to this question, but at a basic level, the amount of traffic that a website receives is important encyclopedic information that is appropriate for an infobox. We can discuss whether that ought to be in the form of a ranking or in the form of monthly pageviews (is that available for most sites? it seems potentially more useful, especially for lower-ranked sites, since no one knows what 20,000th-most visited website actually means in practical terms), and if we keep a ranking, whether it ought to be from Alexa or somewhere else. But until we have some better alternative, I can't support just removing it. If option 3 with local hosting turns out to be feasible, that would seem the best. We're in 2020; we shouldn't be requiring editor work to update something that could be automated. {{u|Sdkb}}talk 19:49, 18 September 2020 (UTC)
  • Option 2 - They're not even accurate. O3000 (talk) 20:41, 18 September 2020 (UTC)
  • Option 2 They are unencyclopedic. Doesn't matter if we could convince Jeff Bezos to give it to us. We could also automate a feed into {{infobox company}} that pulled in the closing stock price of every public company. But is that what an encyclopedia exists for? No. Infoboxes are for data that is static (or near-static, like a website's owner); data that changes continuously does not belong in the encyclopedia. Much better to use a reliable, secondary source in the article text if a site's traffic is notable, e.g. "As of 2020, is one of the most heavily trafficked second-level domains on the internet" (with a reliable source in a ref tag). UnitedStatesian (talk) 20:50, 18 September 2020 (UTC)
  • Option 2 - The rankings are unencyclopedic, proprietary, inaccurate, constantly changing and a complete waste of time and effort. If a website is popular, or has been popular, we should explain that in the prose in the context of the website's history, not try to reflect the latest internet fads and trends in our infoboxes, without regard to the importance of history and longevity. Kaldari (talk) 20:52, 18 September 2020 (UTC)
  • Option 2 unstable and inconsistent.--Moxy 🍁 22:06, 18 September 2020 (UTC)
  • Option 2. It probably meant something way back when, but now? Not so much. Guy (help! - typo?) 22:07, 18 September 2020 (UTC)
  • Option 2. Anecdotally, I am yet to see an Alexa ranking that actually provided some useful information or was covered reliable sources. The problem is that it's an arbitrary number produced by an unclear algorithm that isn't basing it on something immediatelly tangible (like MetaCritic, for example). And reliable sources do not care to discuss this ranking, nor follow it on regular basis. Infoboxes are already a big dump of all the stats about a topic that don't have sourcing half the time. You'd think that an "Internet score" a website receives would be a big deal, but that's not how reliable sources treat this one. —  HELLKNOWZ   ▎TALK 22:36, 18 September 2020 (UTC)
  • Yup, Option 2, per almost all above, especially the several pointing out the non-encyclopaedic-ness; happy days, LindsayHello 23:16, 18 September 2020 (UTC)
  • Option 2 Unencyclopaedic and partisan faux rankings. Fiddle Faddle 23:39, 18 September 2020 (UTC)
  • Option 3 is the middle road. It recognizes the issues and addresses them - no watchlist churn, fully automated, no manual work required, data is kept up to date monthly for some fraction of the sites, and the rest static links (no ranking data displayed). As for accuracy of Alexa data this is address in the Alex wikipedia article and by JC in the previous discussion. As for unencylopedia, Wikipedia ranks many things, including itself on occasion. All 5,000 sites could be updated monthly with a cheap $25/year WMFoundation grant once the system is working down the road if there was community support for it. -- GreenC 00:54, 19 September 2020 (UTC)
  • Option 2. , but keep them as some sort of periodic table somewhere in the article. They're unstable, and confuse notability with popularity, but popularity is not irrelevant information. But putting the current value in thee infobox is overemphasis. DGG ( talk ) 01:14, 19 September 2020 (UTC)
  • Option 2:
...or just do a google search on "Buy Alexa Traffic".
If anyone with a credit card can inflate a statistic, the statistic is useless as a Wikipedia source. I'm just saying. --Guy Macon (talk) 13:02, 19 September 2020 (UTC)
  • Option 2 We are not shills for corporate America (or shouldn't be). GenQuest "Talk to Me" 13:10, 19 September 2020 (UTC)
  • Option 2 - they aren't a statement of fact about the subject since they can so easily be manipulated. They certainly do not belong in an Infobox. They can be misused for promoting a subject. Doug Weller talk 18:28, 21 September 2020 (UTC)
  • Option 2 - Alexa ranking is utterly worthless, there's no point in including it. We ought to be able to automatically show a set of information about the domain held in the url parameter, I could just about live with that including Alexa rank (if Amazon provided it for free), but we shouldn't go out of our wayy to include such nonsense. Chuntuk (talk) 11:22, 28 September 2020 (UTC)

Discussion (Alexa Rankings in Infoboxes)Edit

My main problem with alexa is "What are we putting into it, and what are we getting out of it?" If we put in a bot, request data from Alexa, or just do it manually, it doesn't really matter if we are putting in more than what we get out of it. So, what are we getting out of Alexa? Do people really come to Wikipedia to know about the Alexa rank? Arsonxists (talk) 17:44, 18 September 2020 (UTC)
  • Have we reached out to Amazon? I'm a firm believer in giving tech giants the opportunity to do the right thing, so that we can hate on them with a clear conscience when they don't. But once in a while they surprise—is there some chance Amazon might be willing to provide us with an account that's not rate-limited so that we could update all the websites monthly? {{u|Sdkb}}talk 19:52, 18 September 2020 (UTC)
    • I doubt that, because Amazon would rather get money then trying to help a minor detail in an Infobox. Maybe if it was crucial to us, maybe we could convince them. But not like this. Arsonxists (talk) 20:00, 18 September 2020 (UTC)
      I imagine Amazon would like to help cement the position of a link to Alexa on every article on a popular website... But this is just an aside from the question of whether or not this information ought to be placed in infoboxes. isaacl (talk) 20:14, 18 September 2020 (UTC)
      • Pretty sure they would get the cemented position, and the money. Having Alexa ranks on here is still a win for Amazon. So they would probably refuse the free account, because why not get the money AND the advertisement? Arsonxists (talk) 20:31, 18 September 2020 (UTC)
        Because the money from one account is nothing to Amazon's revenue, while page rank is gold. And based on this discussion at present, it's far from clear that it's "pretty sure" the ranking information will remain. isaacl (talk) 22:03, 18 September 2020 (UTC)
  • @Sdkb: How is this info encyclopedic? A ranking that changes frequently isn't encyclopedic. Arsonxists (talk) 19:56, 18 September 2020 (UTC)
    @Arsonxists: the thing I said was encyclopedic was a numeric measure of a website's popularity, but an Alexa ranking is one such measure. I don't think the fact that it changes makes it less encyclopedic; it's no different than listing population counts or U.S. News college rankings (both of which we do). {{u|Sdkb}}talk 20:04, 18 September 2020 (UTC)
    @Sdkb: The thing is, things like U.S College elections votes stop changing after a certain amount of time, and U.S population estimates are just an estimate, but Alexa rankings never stop and are NOT an estimate. The ranks change every single day, meaning that it changes too much to be in. encyclopedia. Arsonxists (talk) 20:13, 18 September 2020 (UTC)
  • Increase/decrease icons tangent: In the previous discussion, I see that there was some question as to whether the green/red increase/decrease icons were inappropriate WP:Recentism. Personally, I don't see that as a dealbreaker, but I do think it's bad that the icons don't say what time period is being used for comparison. There's also some potential for better use of templates/automation due to the recent creation of {{fluc}}. {{u|Sdkb}}talk 20:01, 18 September 2020 (UTC)
  • @GreenC: Two things: one, this edit will not have notified anybody (not even Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists) because you didn't sign it; two, what is your brief and neutral statement? At over 2,600 bytes, the statement above (from the {{rfc}} tag to the timestamp that I added for you) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Media, the arts, and architecture. The RfC may also not be publicised through WP:FRS until a shorter statement is provided. --Redrose64 🌹 (talk) 20:33, 18 September 2020 (UTC)
Thanks! -- GreenC 21:50, 18 September 2020 (UTC)
  • Is this something we could work with WikiData on and/or get a WMF grant? WikiData would probably love to host this kind of data and it could populate the infobox from there. A WMF grant could fund the fees for whatever the next tier is so we can make the ~5k requests a month that we need to update these. Wug·a·po·des 23:35, 18 September 2020 (UTC)
    • Looking at the fee structure GreenC linked, even if we wind up with 10k requests a month it winds up being like $5. Wug·a·po·des 23:37, 18 September 2020 (UTC)
Yeah it's cheap, $25 a year for current needs. Without institutional support there is no guarantee payments could be maintained in perpetuity. Regardless of the outcome here, it might still be hosted at Wikidata or Wikicommons, and used for other language wikis. -- GreenC 00:43, 19 September 2020 (UTC)
@I JethroBT (WMF): Could you help us navigate this? A $500 grant could keep this going for 20 years which is a bit longer than the 12 month max for Rapid Grants, so I don't think we'd qualify for any of the grants. Should we be looking at WMF programs other than grants? Wug·a·po·des 01:16, 19 September 2020 (UTC)

Annual visitors parameter?Edit

Okay, so it seems that, unless something changes, the Alexa parameter is on its way out. But I maintain that it is useful to have some sort of metric that indicates the popularity of a website. Would the community support having an |annual visitors= (or |annual pageviews=) parameter? It really doesn't seem all that different than having an annual visitors parameter for {{Infobox museum}}. {{u|Sdkb}}talk 00:47, 21 September 2020 (UTC)

Do you have a source for that data in mind that is likely to be both free of cost and freely licensed? --Izno (talk) 02:33, 21 September 2020 (UTC)
@Izno: I don't think there's any entity that collects that data at scale, so it'd come from individual websites. E.g. for Wikipedia, we'd cite as 882 million[1] Many websites don't release their numbers, but I think it'd be better to include it for the ones that do than to have nothing at all. {{u|Sdkb}}talk 04:21, 21 September 2020 (UTC)
Even for Wikipedia, the stats aren't clear. The figure of 882 million is a monthly rather than yearly figure and represents unique devices rather than visitors. Considering that people browse the internet on phones, PCs, laptops, games consoles, equating unique devices to visitors isn't straightforward. Richard Nevell (talk) 10:02, 21 September 2020 (UTC)


  1. ^ "Wikistats - Statistics For Wikimedia Projects". Wikimedia Foundation. Retrieved 21 September 2020.
But then we're facing WP:V and WP:RS issues. The only people who (possibly) know how many visitors they get are the sites themselves. (And: pageviews I'd believe before visitors.) Such an infobox param supposes we have somebody to trust for their values. — JohnFromPinckney (talk) 09:41, 21 September 2020 (UTC)

Log out second chanceEdit

Isn't it about time Wikipedia had a "safety valve" on the "Log out" icon? I have accidentally logged out many times because I clicked the icon by mistake, and then I had to log in all over again. It should be a simple matter to modify the software so when an editor clicks the icon, a message appears, asking, "Are you sure you want to log out? Yes, No."—Anita5192 (talk) 18:16, 27 September 2020 (UTC)

  Agree . {{u|Sdkb}}talk 18:24, 27 September 2020 (UTC)
Only to succumb to the documented "unconscious me always press Yes so I'll press Yes this time oh oops conscious me didn't mean to press Yes". Yeah, no. --Izno (talk) 18:33, 27 September 2020 (UTC)
@Izno: That has never happened to me. I think it is very common for a visitor to any web-site to make the first mistake, but extremely uncommon to make the second mistake. When I accidentally click "Log out," I mean to click something else, and I don't automatically click "Yes."—Anita5192 (talk) 19:34, 27 September 2020 (UTC)
I am glad you are so conscientious (see also anecdotal evidence). Most people are not. That said, there is discussion at phab:T217914 about the issue on mobile. --Izno (talk) 20:17, 27 September 2020 (UTC)
phab:T217914 has a discussion on this. A personal user script (see FlightTime's User:FlightTime/confirm-logout.js) can be used to add this for your own account if you want. — xaosflux Talk 20:20, 27 September 2020 (UTC)
I edit Wikipedia from my laptop computer only, using Google Chrome. I noticed on the phab:T217914 page that someone wrote, "It's not a mobile-only problem; I've clicked log out accidentally on desktop using a mouse." However, I did not see a response to that post on the page. I loaded the JavaScript code at User:FlightTime/confirm-logout.js into my common.js page and bypassed my cache, but it doesn't seem to do anything.—Anita5192 (talk) 21:59, 28 September 2020 (UTC)

Proposals for ending the Infobox warsEdit

The infobox wars have now been raging for longer than the duration of World War II. Despite 2 ArbCom cases and ArbCom's request for community discussions, nothing's really changed since the opening salvos were fired back in 2013. Personally, I'm tired of seeing the same people show up en masse to talk page after talk page to debate over and over and over again whether or not an infobox should be in an article, especially since all such discussions quickly degenerate into back and forth name-calling. To take just one example, Mary Shelley has had 4 infobox proposals in the past 3 years. With this in mind, here are some ideas for ending (or at least reducing) the infobox wars. Feel free to add more ideas. Kaldari (talk) 00:00, 29 September 2020 (UTC)

  • Proposal A - No one may propose adding or removing an infobox to an article if there has already been such a discussion within the past 2 years.
  • Proposal B - No one may propose adding or removing an infobox to an article unless they are one of the top 10 contributors to that article (as judged by the Xtools authorship tool).
User:RexxS/Infobox_factors is good reading. --Izno (talk) 00:09, 29 September 2020 (UTC)
  • Radical idea and one I know will be met with contention, but another idea would be an RFC to discuss whether all articles where it is feasible that an infobox should be present, though editors are not required to use all fields present even if there is data to fill those fields (knowing for example the concerns those at Kubrick have of that). 95% of the issue of infoboxes are people coming here expecting to find "structured" data that 99% of all other articles have. I know the past discussions in this, including ArbCom have been to leave this to a page-by-page consensus, but that is clearly not working, and things have changed since (the introduction of Wikidata, Google/Bing's presentation of search results, etc.). Again, this would be an RFC to discuss this possibility, which I know certain editors will refuse adamantly, but this is a consensus thing. --Masem (t) 00:22, 29 September 2020 (UTC)
Is there a WP:RS for any of those numbers. Having been through over 110,000 of the 'pedia's articles in my own editing I can guarantee that the number that have infoboxes is nowhere near 99%. It is also interesting how everyone talks about what readers expect to see without ever having performed a scientific survey to validate their statements. MarnetteD|Talk 00:35, 29 September 2020 (UTC)
I should add there are types of articles that we have no canned infobox for that we can make the topic conform into, and so in such cases, this would be reasonable where an infobox could be omitted. These are usually for more abstract terms that lack any type of hierarchical data. (This is what I meant by "where it is feasible".
And as a rough test, I used Category:American women by occupation with Petscan, adding in a number of known infoboxes common for this group. Of the 9790 entries, I got to about 3000 pages without the most common infoboxes, and spotchecking those (to find any other infoboxes) the ones that were missing it were all observed to be stub, not well developed articles. Nothing of the type like Kubrick or other pages that have been fully developed and where consensus presently has been to leave an infobox out. This is far from scientific, but I would definitely say that for well-developed (non-stub, non-start articles), the number that lack infoboxes is far fewer then 5% based on this very unscientific study. --Masem (t) 01:32, 29 September 2020 (UTC)
I think that is about right. I am not sure the restrictions above are the path forward. More we need a discussion on making them standard and if so in what capacity. PackMecEng (talk) 00:37, 29 September 2020 (UTC)
  • Both A and B are awful proposals and completely biased in their presentation. --Gonnym (talk) 00:56, 29 September 2020 (UTC)
You're going to have to explain what you could possibly mean. Both proposals look to be completely neutral - they take absolutely no inherent side in disputes other than stability - and while you can certainly disagree with them on any number of grounds, e.g. proposal B is unacceptably inimical to WP:OWN (my opinion), your comment neither adds to collective understanding nor actually advocates for your position in a meaningful way. VanIsaacWScont 01:11, 29 September 2020 (UTC)
  • If it came up at an RfC I would support proposal A. For no other reason it streamlines what has become a sort of drag on the community. -- GreenC 01:54, 29 September 2020 (UTC)
  • I have never encountered a contentious infobox discussion. If the problem is a cabal of editors going from page to page starting infobox discussions, we should just topic ban those editors. If that is not possible, we should develop project-wide guidance similar to Masem's suggestion. Wug·a·po·des 01:57, 29 September 2020 (UTC)