Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go
...help using Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Guideline discussion at TfD

Please come participate: Wikipedia:Templates for discussion/Log/2017 July 27#Template:Recent death Aboriginal Aus. Thank you. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 05:30, 29 July 2017 (UTC)

Just for the record, the result of the discussion was to delete the template in question. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 05:07, 8 August 2017 (UTC)

Edit summaries

Any ideas on how to get an editor to leave edit summaries please, for example here and here. Aoziwe (talk) 14:31, 31 July 2017 (UTC)

Leaving {{Uw-editsummary}} on their talk page is the standard method I'd know to try. Dhtwiki (talk) 22:01, 31 July 2017 (UTC)
Thanks. I will see what happens. Already tried a request. Aoziwe (talk) 11:06, 1 August 2017 (UTC)


Seems to be not working. Aoziwe (talk) 10:27, 3 August 2017 (UTC)
Forget about it. People should use edit summaries but unless there are other problems with the editing there is no practical way to force the issue. Cases at WP:ANI have usually overlooked a lack of cooperation regarding edit summaries, or even a failure to respond on talk pages. It's only if there are persistent problems affecting content that action is likely. Johnuniq (talk) 11:17, 3 August 2017 (UTC)
Thanks Aoziwe (talk) 12:25, 3 August 2017 (UTC)
Aoziwe, I've seen editors described as not being cooperative if they don't use edit summaries or ever communicate on talk pages (and I do find such editors frustrating because they are so often problematic), but action isn't taken against them unless their lack of cooperation is shown to be a problem; for example, the editor keeps making edits that go against WP:Consensus and isn't trying to work the matter out on the talk page. This leads verbal editors to wonder if the non-verbal editor is actually aware of the issue. Such non-verbal editors are usually blocked on WP:NOTHERE and/or WP:COMPETENCE grounds. Flyer22 Reborn (talk) 22:30, 6 August 2017 (UTC)

Notability of political candidates

In general, people who are only notable for losing an election to the United States Senate or UK House of Commons do not meet WP:NPOL and are deleted at AfD. As a result, people who are only notable as a candidate for the Senate or Commons are not notable, either. This leads to many contentious debates during election seasons.

Defining which specific lower-level political offices are notable is almost always controversial and should be avoided. To minimize controversy, I feel Wikipedia should generally wait until after the election for deletion discussions. As "important" elections often generate a lot of media coverage, the candidates will meet WP:GNG.

However, having a specific rule for elected offices poses an additional problem. In races where (for example) a mayor is running against a scientist, there is an implicit bias for electing candidates with prior electoral experience. To avoid this bias, either all of the candidates meeting GNG through coverage of the race should be included, or none of them should be included. Power~enwiki (talk) 19:53, 2 August 2017 (UTC)

Just in the United States alone, there are elections every two, four or six years for 435 seats in the US House of Representatives, 100 seats in the US Senate, 50 state governorships, thousands upon thousands of seats in state legislatures, a few hundred mayors of cities that are large enough to get their mayors over NPOL, and a couple of hundred city council seats in the couple of dozen cities that are large and important enough to get their city councillors over NPOL too. And there are almost always somewhere between two and a dozen (or more) candidates for each of those seats, adding up to thousands upon thousands of articles about candidates. Then you have to do the same for Canada — 338 seats in the federal House of Commons, 750 seats in provincial and territorial legislatures, lots of mayors and half a dozen metropolitan cities large enough to NPOL the city councillors, again times three-to-twelve candidates per race. And then you have to do the same for the UK and Australia and Germany and France and Italy and the Netherlands and South Africa and Brazil and every other country on earth which has democratic elections, in many of which it can get even worse because the number of parties running candidates makes Canada and the United States look like amateurs in the political diversity sweepstakes.
And if your response is going to be "I only mean the candidates who clear GNG", I've got news for you: at the depth of coverage that's normally brought as evidence of passing GNG for most articles about political candidates, every candidate would always clear GNG — covering local elections in their coverage area is local media's job, so every election and every candidate in it always gets some coverage in the campaign context.
And furthermore, Wikipedia has a rule that notability is not temporary — we cannot deem somebody "temporarily notable pending a future condition they may or may not meet, but then losing that notability if they fail to meet it". Notable today, notable forever (except in the rare instance that notability criteria evolve to the point that the person's base notability claim no longer even meets the standards anymore, which is possible but not actually very common at all.)
Again, the core reason that Wikipedia established the notability criteria that we have for politicians, namely requiring that they hold office and only in certain very rare situations get to claim notability just for the fact of being a candidate in and of itself, is precisely because such articles have an extremely high tendency to get misused as promotional campaign brochures. And we simply don't have the editor base needed to properly monitor or maintain tens of thousands of articles about election candidates for neutrality and sourcing issues, any more than we have the ability to properly monitor or maintain every article that some aspiring wannabe in some other field of endeavour (musicians, writers, artists, high school football players, etc.) wants to create about themselves either.
So no, what you propose simply isn't sustainable at all. Bearcat (talk) 02:59, 5 August 2017 (UTC)
+1 to excellent Bearcat post. Nailed it. Alsee (talk) 14:20, 7 August 2017 (UTC)
Me, too. Well written, Bearcat. FWIW, in south India it is not uncommon to have > 10 candidates per seat, and the record was something like 40 for one seat. - Sitush (talk) 07:10, 16 August 2017 (UTC)
Bearcat is on point here; I will just add that even with NPOL where it is, we have been flooded with low-grade bios, typically for state/province-level legislators. I shudder to think what the outcome may be if we lowered this threshold. Vanamonde (talk) 06:25, 17 August 2017 (UTC)

Blatant BLP Violations Being Ignored

Moved to BLPN Only in death does duty end (talk) 19:43, 7 August 2017 (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.

Hello all. We have a somewhat unusual problem developing at Administrators' noticeboard/Incidents. An editor is repeatedly and egregiously violating BLP policies within the very AN/I report filed for the same BLP violations that got the editor to the board in the first place[1]. So far it has received zero attention from an administrator, and so the BLP violations and defamatory edits continue. As I understand BLP policy, unsourced/poorly sourced or slanderous material (which this certainly is) must be removed immediately from the project. What is the best course of action, here? I believe at least two administrators have been pinged to draw their attention, to which no response has been received to date. Pinging James_J._Lambden in case he has anything to add, as the filer of the report. I apologize if this isn't the appropriate forum for this situation, but it's so unusual that I really have no clue where this belongs. Hidden Tempo (talk) 19:22, 7 August 2017 (UTC)

The correct place is WP:BLPN. However since all those 'BLP violations' are trivially easy to reliably source, I suspect you would be wasting your time. Either way that is the correct venue to discuss alleged BLP violations on wikipedia. Only in death does duty end (talk) 19:40, 7 August 2017 (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.

ACTRIAL length discussion

Hi all, there is currently a discussion with the WMF about the length of ACTRIAL that is happening at Wikipedia_talk:Autoconfirmed_article_creation_trial#Trial_duration. All are welcome to give their thoughts. TonyBallioni (talk) 16:00, 9 August 2017 (UTC)

Plea for a slightly less blunt WP:G5

Earlier this month, I went to make sure that the disambiguation page, "Nies" contained Judge Helen Nies, late of the Federal Circuit. I was surprised to find that not only was this entry lacking, but that there used to be a Nies (surname)—a completely innocuous (and useful) list of people sharing that surname—which was deleted with no discussion as WP:G5, a page created by a banned or blocked user. I have seen a number of other instances where perfectly useful and benign pages and redirects have been deleted on this basis, apparently with absolutely no thought going into the process. It is distressing to me to think that our policy is so blunt as to allow (much less require) that we punish our readers for the transgressions of editors through the deletion of good articles on this basis. Is there any way we can refine this policy to avoid outcomes that do more harm than good to the encyclopedia? bd2412 T 23:57, 15 August 2017 (UTC)

I agree with this wholeheartedly. Perhaps a gentle reminder for administrators to use good common sense when thinking of deleting the article at WP:G5? Or change the rationale to "Disruptive creations by banned or blocked users"? I also wonder whether there was a historical reason for this criterion that we are now forgetting... Malinaccier (talk) 00:01, 16 August 2017 (UTC)
Agreed. Judging by content and not by the author makes sense. — Preceding unsigned comment added by Jjjjjjdddddd (talkcontribs) 10:59, 16 August 2017 (UTC)
  • Deleting a disambiguation page is a bit blunt, but I do want to point out that when G5 is applied to BLPs it is often for the case of the protection of the subject: G5 is most commonly applied to sock farms with likely PAID issues. Unfortunately PAID cuts several ways: you have payment for promotion, payment for blackmail (Orangemoody-esque), and also payment to disparage competition. G5 is a blunt instrument, but it is very effective in helping us protect actual people from harm. For these reasons I'd oppose any change to the current wording, but agree that commonsense should prevail in cases like dab pages. TonyBallioni (talk) 00:10, 16 August 2017 (UTC)
    Perhaps we have the beginnings of a refinement there - definitely use G5 for BLPs, probably for any article on an extant business, organization, or product. Avoid using it on useful redirects, disambiguation pages, and the like. The problem, as I see it, is that there is nothing presently in the wording of G5 that even calls for the use of common sense. It does say "Pages created by a topic-banned user may be deleted if they come under that particular topic, but not if they are legitimately about some other topic"; I don't see how that limitation could have been applied in the case of the page deleted in this instance. bd2412 T 02:55, 16 August 2017 (UTC)
Having seen lists created as supporting material for spam articles, and having seen A7 fall from being a useful deletion criterion to becoming a battleground, I favour leaving the matter at the admin's discretion. While I appreciate BD2412's intent, blocked should mean blocked, and blocked users shouldn't be offered loopholes in their blocks. Cabayi (talk) 06:40, 16 August 2017 (UTC)
  • For non-banned editors, we keep their good edits and pages and revert their bad edits and delete their bad pages. If an editor is banned, we also reject their good edits and pages. If we do not delete good pages per G5 or revert good edits on sight, the only difference between banned and non-banned editors is that the banned editors have to change username once per day. —Kusma (t·c) 06:49, 16 August 2017 (UTC)
  • The principle of a ban is very simple: As long as the edit is just the edit of a banned user, it can be removed - revert an edit to an existing page, delete a new page. If an established editor (not necessarily an admin, but clearly not a sock of a banned user) declares that (s)he is willing to take responsibility for that edit, it ceases to be "just the edit of a banned user". This can be done after the edit was removed as well as before - if you restore a correctly G5-ed page, that is generally taking responsibility for it. עוד מישהו Od Mishehu 11:04, 16 August 2017 (UTC)
An important principle here is that the meaning of words like may and can is NOT a synonym for the word must. G5's language is fine, but the problem is enforcement. The problem becomes where damnatio memoriae becomes cutting off the nose to spite the face. We shouldn't have to jump through extra hoops to delete contributions of banned users. However, saying that, we shouldn't feel the requirement to delete them where it creates a greater hassle than just leaving it alone. --Jayron32 11:39, 16 August 2017 (UTC)
To quote the first line of the prose of WP:CSD: The criteria for speedy deletion (CSD) specify the only cases in which administrators have broad consensus to bypass deletion discussion, at their discretion, and immediately delete Wikipedia pages or media. They cover only the cases specified in the rules here. The key words here are "at their discretion". עוד מישהו Od Mishehu 06:22, 17 August 2017 (UTC)
Some administrators seem to be reading "at their discretion" to mean "delete everything without a second thought". bd2412 T 18:23, 18 August 2017 (UTC)
If an admin sees a pattern of bad edits, they may decide reverting some good ones is worth the price of reverting the whole bunch automatically, to avoid the cost of checking every edit which is pretty high. -- GreenC 18:40, 18 August 2017 (UTC)
  • I quite agree with the sentiment set out above by BD2412, in that we are not doing our readers any favours at all, and the phrase used by Jayron32 above about cutting off ones nose seems apt here. While I agree some banned users' contributions are always problematic, others are not necessarily, and admins should be reminded on these occasions to use appropriate judgement, rather than blindly follow the rules as set out. On reading the actual policy, it says This applies to pages created by banned or blocked users in violation of their ban or block, and that have no substantial edits by others. G5 should not be applied to transcluded templates or to categories that may be useful or suitable for merging... Perhaps this could be tightened up somehow, along the lines of "Administrators should use their discretion when applying G5, so that it does not unintentionally inconvenience readers". Aiken D 19:01, 18 August 2017 (UTC)

G11 AfC modification

Recently, a lot of Articles for Creation drafts have been speedily deleted under CSD criterion G11. I can think of at least five examples in the last week but unfortunately I cannot provide diffs as they have been deleted.

Many of these could have plausibly conveyed notability with enough content to satisfy notability guidelines. The whole point of the draftspace and the Articles for Creation project is to allow the development of drafts and is a place where fundamental rewrites can occur to create articles satisfying both notability and neutrality guidelines and policies.

The discussion at Wikipedia:Miscellany for deletion/Draft:Chloe + Isabel is the biggest discussion to date about this issue but that was based on one example of current policy application. The spirit of the draftspace is to stop new editors who don’t yet understand our rules from being chided and driven away. Not only has this conduct doubtlessly bitten new editors, it has driven away reviewers such as myself and Chrissymad, as noted by Primefac and Legacypac here.

Therefore, I propose that speedy deletion criterion G11 be modified with the explicit provision that it does not apply to Articles for Creation drafts which have had fewer than three declined submissions and make a credible claim of significance.

I am pinging all the users who participated in the Chloe + Isabel MfD from both sides of the debate and the closing administrator. I would also like to note that some of the delete !votes were on the grounds that the draft was unambiguously promotional and could never be notable. @SwisterTwister, Waggie, Primefac, 78.26, KMF, There'sNoTime, Piotr Konieczny aka Prokonsul Piotrus, Zppix, DGG, Fortunavelut luna, Legacypac, Jimfbleak, Onel5969, DES, Robert McClenon, K.e.coffman, Winged Blades of Godric, TimTempleton, and CambridgeBayWeather:

DrStrauss talk 11:14, 20 August 2017 (UTC)

  • Wouldn't we want to change "is not notable" to "is not notable and can not be made notable" for everyone? --Gryllida (talk) 11:18, 20 August 2017 (UTC)
  • I voted delete on the example based on ST's analysis, not my most studied vote ever. In general I'm not thrilled with how high a bar AfC has become. I'm inclined to send topics with proven notability (and no really serious CSD level issues) on to mainspace for the wide world to edit. It's not reasonable to expect brand new editors to create perfect articles. Anyway, evidently I'm viewed as too inclusionist because I was banned from page moves or creations even though no one provided any evidence my moves or creations get deleted except occasionally - which is ironic because I seek deletion on so many pages. Legacypac (talk) 11:27, 20 August 2017 (UTC)
  • @Legacypac: I didn't know that... I wouldn't have considered you an inclusionist. I might return to AfC after ACTRIAL starts. DrStrauss talk 11:47, 20 August 2017 (UTC)
  • I believe that G11's current wording is good enough: This applies to pages that are exclusively promotional and would need to be fundamentally rewritten to conform with Wikipedia:NOTFORPROMOTION. If a subject is notable and the content could plausibly be replaced with text that complies with neutral point of view, this is preferable to deletion. Note the words in italics (these are from the original) and the second sentence. עוד מישהו Od Mishehu 12:06, 20 August 2017 (UTC)
  • Strong oppose any blanket ban---Admins are good enough to differentiate that the content that is G11-able in main space, might not be (and generally are not) in draft-space.And, the statement--The spirit of the draftspace is to stop new editors who don’t yet understand our rules from being chided and driven away. is horribly wrong.[{WP:DRAFT]] states--They help facilitate new articles to develop and receive feedback before being moved to Wikipedia's mainspace. Draftspace is for the development of potential article(s), not potential garbage.Otherwise, we may as well blanket-exclude any draft from any deletion except in copy-vios/attack pages.But, at any event, it's highly regretful that you have chosen to walk out from AFC. Winged Blades of GodricOn leave 12:42, 20 August 2017 (UTC)
  • Oppose. I understand DrStrauss' intent (at least I think I do). But as someone who has done quite a bit of work on AfC, I also understand the constraints of the editors who do such mind-numbing work slogging through all the submissions. Personally, I think we need to have some sort of codified standards as to who can, and who can't do AfC reviews. Right now, if I'm not mistaken, any editor can participate. This leads to very uneven standards being applied, which can lead to confusion among new editors. I also (now, and this hasn't always been the case, believe me) always try to leave a comment in addition to any decline, however sometimes the decline is just so blatantly obvious, that commenting is just a waste of time. I used to do quite a bit in G11, and my goal there was not to delete (and again, that was an evolution over several months), but to try and find articles to clean up and move into the mainspace. I think I found somewhere over 100 that I did that with. I also don't know how many "postpones" I did as well. All that being said, I would oppose the constraint that a draft had to be declined 3 times. Often drafts are done, and declined once, and the creator never comes back. I also think that promotional articles must stand the WP:TNT test. I think perhaps that more discernment needs to go into clicking that CSD-G11 button. But sensible editors can disagree. I see no need to change the current verbiage. On a side note DrStrauss, I don't think some of your pings up above (e.g. DeSiegel) went through. Onel5969 TT me 12:43, 20 August 2017 (UTC)

Technical

Save changes buttons - accessibility

At some point between 23:23 and 23:34, 18 July 2017 (UTC), the edit interface has changed. Is it Thursday already? I notice that the buttons at the bottom (Save changes, etc.) have changed, are bigger and less readable: there's a contrast problem. Accessibility is something to be careful of. --Redrose64 🌹 (talk) 23:57, 18 July 2017 (UTC)

+1 I am not entirely sure what was wrong with the old version either, and it is certainly not yet Thursday. ^_^ Double sharp (talk) 00:00, 19 July 2017 (UTC)
They've been dutifully warning us of the buttons' fuglification for weeks, including that there's no practical way to repair them with user css. I'd have complained earlier, but of course it would've done no good. —Cryptic 00:07, 19 July 2017 (UTC)
Redrose, accessibility for people with low vision is one of the main points. The contrast has been dutifully checked (several times by now, at least for Vector) and easily clears all of the standards.
Note that this is more than an aesthetic change, so a few old editing scripts may also break. See mw:Contributors/Projects/Accessible editing buttons for information on how to fix anything that's broken.
(P.S. It's a config change, which means it can descend on you on any day of the week. ;-) So far, it's only reached the Wikipedias and Meta. Other wikis will happen in a couple of weeks.) Whatamidoing (WMF) (talk) 01:20, 19 July 2017 (UTC)
They look perfectly fine to me. I don't see where any potential readability issues would come from even for those with eyesight issues. They're compliant. Amaury (talk | contribs) 01:27, 19 July 2017 (UTC)
Whatamidoing (WMF), could you please explain how making various interface elements exceedingly disproportional (like buttons being about 4 times bigger than hyperlinks) improves accessibility? If you care so much about these people (by the way, what is their fraction among the editors?), then maybe it would be better to make a special "accessible" style for them, with everything large and contrast? I can tell about my own experience with "accessibility": when I need to use a website with small fonts, I just press Ctrl++, and my browser magnifies everything proportionally. If I would do that with the current WP design, these ugly buttons will take half of the screen, actually decreasing the usability. And I also wonder very much: how artificially limiting the summary line to 80% of the width is supposed to help people with low vision? — Mikhail Ryazanov (talk) 09:46, 19 July 2017 (UTC)
The intention, at least as stated in prior posts here, was to improve accessibility for readers using the desktop version on mobile devices. Never mind that this affects editors, not readers, and significantly degrades the desktop version on the desktop. —Cryptic 16:50, 19 July 2017 (UTC)
Not just mobile devices. Touch devices. This includes things like Windows Surface laptops for instance. —TheDJ (talkcontribs) 18:49, 19 July 2017 (UTC)
I thought that all modern OSs have user preferences for sizes and colors, such that any interface built from standard elements will have a comfortable look and feel. Am I wrong? I do not have much experience with touch devices (believing that text editing on a keyboardless device is a bad idea), but how can it be that these users can tap hyperlinks, but cannot tap standard buttons (which are usually about twice bigger)? And again, how reducing the summary width to 80% helps them? Especially considering the problems (discussed below) with its wrong alignment and an overlapping counter. — Mikhail Ryazanov (talk) 22:57, 19 July 2017 (UTC)
Web pages cannot access OS user preferences (it would be a leak of privacy if they could), nor directly use the user interface elements provided by the OS (they use the user interface elements provided by the web browser, which may or may not resemble those natively provided by the OS). isaacl (talk) 23:54, 19 July 2017 (UTC)
Web pages do not need to access OS user preferences because the browser itself should. In any case, browsers have user preferences for default colors, fonts, and overall magnification. — Mikhail Ryazanov (talk) 04:42, 20 July 2017 (UTC)
Sure, the browser could retrieve and expose this data to web servers, but I don't believe there's currently a mechanism for web servers to retrieve this info from web browsers, and it would still be a potential privacy issue. There are defaults for colours and fonts, but not size information for user interface elements. Most users, though, appreciate greater variety in the web sites they visit, and would not want all of them to use only the default background and text colour. Even just considering the implications on a single site, visual elements such as side bars would blend into the main text flow without a distinguishing background colour. isaacl (talk) 18:31, 21 July 2017 (UTC)
Browser do not need to expose these preferences to web servers, they use them locally for rendering pages. If you have no idea how it works, please see [2], [3], [4], [5].
A variety in the web sites is fine, but kind of interferes with the accessibility, which was the declared reason for the changes we discuss here. And I still assert that neglecting user's setting actually does not "improve accessibility". — Mikhail Ryazanov (talk) 10:02, 24 July 2017 (UTC)
Thanks; I am familiar with how the default settings work. I was only responding to your original post regarding using the OS user preferences. Sure, it's possible to go back to the late 1990s look, with the web site using only defaults, and a single flow of content such as seen on many sites that are designed with mobile devices in mind as the primary viewing experience. But it's unlikely for any highly popular site such as Wikipedia to drop all styling, and in particular judicious use of background and foreground colours. For better or worse, most readers today expect both accessibility features to be respected and an engaging site design. Specifically regarding buttons: the key problem is that browsers don't offer good customization options to tailor their accessibility, and there is uneven support in adjusting their appearance via CSS. Accordingly sites will substitute their own button elements for the default ones. It's not a perfect solution, but it's what we have available. isaacl (talk) 16:29, 24 July 2017 (UTC)
Mikhail, the use of 80% width on the edit summary box has nothing to do with this change. It's been like that for years (possibly since the creation of the MonoBook skin). However, the team can change it, and if people don't like the result, then they can complain. Whatamidoing (WMF) (talk) 17:37, 24 July 2017 (UTC)
Yes, they have tried their best to impede user's CSS. I have added to my common.js some code to remove the offending classes:
// remove ugly styles from buttons:
$(".oo-ui-buttonInputWidget").removeClass("oo-ui-buttonInputWidget")
$(".oo-ui-buttonElement-button").removeClass("oo-ui-buttonElement-button")
// and checkboxes:
$(".oo-ui-checkboxInputWidget").removeClass("oo-ui-checkboxInputWidget")
// remove inflated field margins:
$(".oo-ui-fieldLayout-header").removeClass("oo-ui-fieldLayout-header")
This seems to help against the most evil stuff, at least so far... — Mikhail Ryazanov (talk) 09:31, 19 July 2017 (UTC)
What a relief! The awful new buttons couldn't be styled by CSS (by me at any rate), but this returns them to a usable legible state. And fixes my widgets too. Lithopsian (talk) 14:02, 19 July 2017 (UTC)
I regret that I have but one thanks button to click for this edit. A css solution would be better - removing the classes in javascript still shows the irritatingly immense buttons briefly until the page finishes loading - but this is still a huge improvement. —Cryptic 16:50, 19 July 2017 (UTC)
@Cryptic: Since they are classes, you can redefine them using user CSS. For example, I have changed the color. If you want to have boring grey buttons again, you can use
.oo-ui-buttonElement-button {
border: 1px solid black !important; 
background-image: linear-gradient(to bottom,#eee,#eee 100%) !important;
border-radius: 0 !important;
padding: 0.5rem !important;
transition: none !important;
}
for example. Regards SoWhy 12:29, 20 July 2017 (UTC)
Is there a CSS style that is just "look like a button, like all the other buttons - eg 'Go' and 'Search' in Monobook"? Mitch Ames (talk) 11:28, 24 July 2017 (UTC)
I just took a screenshot at File:Save_dialog_Wiki.jpg (FF 52.0.2, Windows desktop, Vector skin). Maybe that helps a bit to find remaining problems and script incompatibilites (obviously the buttons need fixing, and the "edit summary" field is cut by 1-2 pixels on the left side). GermanJoe (talk) 02:45, 19 July 2017 (UTC)
wikEd is making it's own style modifications. It will need an update. —TheDJ (talkcontribs) 07:17, 19 July 2017 (UTC)
I think they're awful – unattractive and huge, but I am more concerned with the fact that I no longer have any ability to leave an edit summary. Gone. The field is not even presented to me. I do/did have my interface tweaked to get rid of the gallons of material at the bottom of the page, and order it better. I'm assuming that is the issue. Can anyone advise if there's any way to tweak my customization or can identify the issue between my common.js and my my common.css?--Fuhghettaboutit (talk) 12:03, 19 July 2017 (UTC)
@Fuhghettaboutit: Eh, yeah you are doing some very uncommon manipulations there with both JS and CSS on your editOptions. If you want to hide something, you should always target as narrow as possible, not go high level and then selectively move things out of it with JS... —TheDJ (talkcontribs) 15:37, 19 July 2017 (UTC)
  • Any chance we have a preference like with VE ?, My main dislike is the huge blue button as well as the rather big tick (image) - Wouldn't be so bad if it was smaller, ofcourse I realise it's been designed for people with eyesight issues however without being disrespectful we're not all blind so surely there should've been common ground in terms of the design ?,
It pleases those with eyesight issues (which is absolutely great) but it pisses those off that don't have eyesight issues (FWIW I am short sighted and do wear glasses however the previous design was never an issue),
If we could have a preference option like with VE that'd be great - I know we can't please everyone I understand that but atleast to me the big blue button/tick is rather extreme... –Davey2010Talk 16:41, 19 July 2017 (UTC)
Davey, I know it seems like a pretty big visual change, but my bet is that if you wait a couple of weeks, you won't notice it as much any longer. Most people adapt to visual changes pretty quickly. Also, since most of us here are experienced editors, most of us don't really look at the buttons much anyway: It's just Tab ↹ to the edit summary box, type the edit summary, and Return to save the page. The buttons don't even need to be above the scroll.
We made this change at half a dozen big wikis two weeks ago. There were a few comments about the size and color there on the first couple of days, but I've seen nothing about it since then. Whatamidoing (WMF) (talk) 20:04, 19 July 2017 (UTC)
Ah see I don't do that - I usually hit any part of the scrollbar thus making it "ping" to any place - I then type whatever or use the arrow keys for autofil and then hit return,
Ofcourse I mean changes happen everywhere and not all are liked but we live with it but usually if something changes to my dislike I'll "dislike it but live with it" but here and I hate to be a little drama-queen but I actually hate it, The button is "too in your face" if that makes sense, I love the colour Blue always have so I love the colour choice here no problem but the button and tick are too big,
It would've been better to have it the same size as the previous and perhaps have implemented a tool where it could be made bigger in preferences or something, But I suppose it all goes back to "you can't please everyone",
Ah well it's changed and I guess there's nothing I can do except look in anger! Face-tongue.svg, –Davey2010Talk 20:37, 19 July 2017 (UTC)
Is this why the button is green?— Vchimpanzee • talk • contributions • 20:52, 20 July 2017 (UTC)

Show changes clicks Editing help on Android

On Google Android phone (Google Chrome) browser, the new oversize "Show changes" (button 3) clicks into "Editing help" (cheatsheet link) which is very bizarre because no "Cheat" buttons onscreen, and "Show changes" really should show changes on mobile phone edits (which are hard enough already). This glitch shows the horrors of user-hinterface experiments which can hinder simple processing, as the inverse consequence of wanting a modest improvement in user interfaces. "Kids don't do this: never move the brake pedal, gas petal or steering wheel while a car is being driven". We need an essay, "wp:Computer Screwups 101" to remind people to use alpha/beta testing steps on crucial user-interfaces, where experimental glitches can have horrific impacts (over 20,000 mobile phone edits per month). -Wikid77 (talk) 08:32, 20 July 2017 (UTC)

This report misses critical information. which page, which editor, which skin, which android device, which version of google chrome, did you test with disabling all your gadgets and userscripts ? How to report bugs effectivelyTheDJ (talkcontribs) 07:05, 21 July 2017 (UTC)
It happens on any page (wikitext editor) in Vector skin (Monobook skin ok) while suppressing License blurb, but when logged out then "Show changes" clicks Show preview, on Android phone LG Escape2, version 5.1.1. To avoid preview horrors, the Monobook skin can be used (which shows avocado " Save_changes " rather than Vector blue  Save changes ). -Wikid77 (talk) 06:08, 24 July 2017 (UTC)

New Edit summary window

The redesigned Edit summary window has the text left-anchored, with the result that most of the time you can't see what you're typing because it's off the right-hand end of the window (on an ordinary 13" laptop). Can that really be what the designers wanted to achieve? The remaining-character count is good, though. Justlettersandnumbers (talk) 08:27, 19 July 2017 (UTC)

@Justlettersandnumbers: It is supposed to right align. If it is not for you, then that might be a browser specific bug. Please report what browser and version of it you are using. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
Safari Version 5.1.10, TheDJ. Justlettersandnumbers (talk) 09:14, 19 July 2017 (UTC)
Ah, that browser is not really supported anymore, so I guess it's not too surprising. I've been saying that we should disable JS support for Safari 5, but so far it seems it's still included. —TheDJ (talkcontribs) 09:51, 19 July 2017 (UTC)
Similar but not identical problem in Chrome Version 49.0.2623.112; Firefox 48.0.2 is OK, though. Justlettersandnumbers (talk) 09:20, 19 July 2017 (UTC)
I use Chrome 36 (after I abandoned Firefox because v. 51 got waaay too slow - five minutes to load a Wikipedia diff, and ten mins to click "back" from that? Ridiculous) and I find that it's right aligned, but the last two or three characters are hidden by the bytes-remaining counter. Pressing End reveals them though. Perhaps that counter could be put outside the box? --Redrose64 🌹 (talk) 10:06, 19 July 2017 (UTC)
Counter, what counter? Using the latest version of Chrome with Vector. Doug Weller talk 10:58, 19 July 2017 (UTC)
Are you using wikEd? That makes its own edit summary box with no counter. PrimeHunter (talk) 12:38, 19 July 2017 (UTC)
@Doug Weller: I suspect this might be interfering. And indeed so will wikEd. —TheDJ (talkcontribs) 12:57, 19 July 2017 (UTC)
@PrimeHunter and TheDJ: I got rid of the CSS but I want to keep WikiED, I'm ok without the counter, just nice to know why I can't see it. Doug Weller talk 15:40, 19 July 2017 (UTC)
@Doug Weller: I'm not going to fix wikEd though, you will need to contact it's maintainer. —TheDJ (talkcontribs) 15:50, 19 July 2017 (UTC)
@TheDJ: Of course not, why should you? As I said, I'm not bothered, I want to keep WikiED. Doug Weller talk 19:09, 19 July 2017 (UTC)
@Doug Weller: By "that counter", I mean the one described at Help:Edit summary#The 250-character limit (the bit about the figure 143). --Redrose64 🌹 (talk) 20:02, 19 July 2017 (UTC)
I have the same problem on Firefox 52.2.1. Deli nk (talk) 12:43, 19 July 2017 (UTC)
I have the same problem with latest version of Chrome for Windows. When I undo a change, I find myself removing most of the default stuff in the box so I can see what I'm doing. Annoying. Any way to go back until they fix it?--Bbb23 (talk) 14:04, 19 July 2017 (UTC)
  • Please roll back the change to the edit window. This makes it harder to write edit notes. It is cute to have the little twitter character counter but it actually gets in the way many, many characters from the end. This must go'. Jytdog (talk) 22:19, 19 July 2017 (UTC)

Edit summary field hidden

Not sure if this is related, but I came here wondering about why I was not able to see any edit summary field at all. I'm editing on a Kindle fire at the moment with the vector skin. olderwiser 08:57, 19 July 2017 (UTC)
You have #wpSummaryLabel hidden in your vector.css (as did I). Just remove the line.[6] -- zzuuzz (talk) 09:06, 19 July 2017 (UTC)
Hmm, that seems like an oversight in one of the IDs.. Please file a bugreport. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
(edit conflict) The id wpSummaryLabel ended before the box in an old version I compared to. You can currently place the below in your CSS to hide the heading but not the box. PrimeHunter (talk) 09:32, 19 July 2017 (UTC)
#wpSummaryLabel .oo-ui-labelElement-label {display:none;}
@Bkonrad and Zzuuzz: You can increase the specificity of the selector, like this. --Redrose64 🌹 (talk) 09:31, 19 July 2017 (UTC)
Thanks @Redrose64 and PrimeHunter:. Both your suggestions work, though I noticed PrimeHunter's suggestion also hides the count of remaining characters (something I had not seen before and is nice touch). olderwiser 10:02, 19 July 2017 (UTC)

What is this number?

When I'm in the edit window in Firefox 54.0.1, logged in, there is an odd 3-digit number outside and to the right of the Edit Summary box. That same number appears no matter what article I open up. So, I opened Microsoft Edge without logging in. That same number appears no matter what article, except it's inside the Edit Summary. Are you tracking us? What is this number, and why is it the same number no matter what article, no matter if I'm logged in or not? — Maile (talk) 11:54, 19 July 2017 (UTC)

@Maile66: Type some letters into the edit summary box and you will see what it means! See also the first point at Help:Edit summary#Edit summary properties and features. — This, that and the other (talk) 11:57, 19 July 2017 (UTC)
Ahhhhh ... it counts the characters in our edit summary and tells us when we've reached the limit. Thanks. — Maile (talk) 12:00, 19 July 2017 (UTC)
@Maile66: Specifically, it counts bytes rather than characters; if you type in non-Latin characters like "카나다", "Канада", or "קאנאדע" you'll see it drop more quickly. My colleagues in the MediaWiki team are working on making it possible to write more than the current limit of 250 bytes, which was a highly-rated Community Tech wishlist item recently. Jdforrester (WMF) (talk) 15:56, 19 July 2017 (UTC)
Seems pretty pointless TBH. Another good reason why I ditched using edit summaries years ago. Lugnuts Fire Walk with Me 13:04, 19 July 2017 (UTC)
Actually, it counts the bytes, not the characters. This distinction is what makes it particularly useful for people who aren't typing in English. Whatamidoing (WMF) (talk) 15:34, 19 July 2017 (UTC)
@Maile66 and This, that and the other: A better link is Help:Edit summary#The 250-character limit, in particular the bit about the figure 143. @Jdforrester (WMF): 255 bytes, not 250. Same link. --Redrose64 🌹 (talk) 20:00, 19 July 2017 (UTC)
The counter is cool but should be outside the text field. The rest of the changes are just ugly. RivertorchFIREWATER 23:28, 19 July 2017 (UTC)

Last characters in summary are hidden

I came here to ask a related question, and saw this thread. How do I turn off the count box? I couldn't find anything in preferences. Is there a .css or setting that will kill it? On Google Chrome (with MonoBook skin), the box hides the last couple characters typed in the Edit Summary box - as a result, it just gets in the way. To verify I didn't leave off anything I need to back arrow then forward arrow to trick the UI to show me all the typed characters. If I type again at that point, they are again hiddent and I need to use the stupid back arrow/forward arrow thing again to view all my typed characters. --- Barek (talkcontribs) - 17:06, 19 July 2017 (UTC)
Put
.oo-ui-textInputWidget > .oo-ui-labelElement-label { display:none !important; }
in your common.css. —Cryptic 17:13, 19 July 2017 (UTC)
Doesn't work—the countdown is still there. I'm sure this was implemented with the best of intentions but please, disable it until you can get it working properly—not being able to see what you're typing is remarkably irritating. We survived for 15 years without it, I'm sure we can survive another week while you work the bugs out. ‑ Iridescent 17:18, 19 July 2017 (UTC)
You're right - I was able to change the positioning and opacity with that selector, but display doesn't stick. I've added an "!important" to the above, which does work. (At least for me, in cologneblue, in preview.) Try that? —Cryptic 17:24, 19 July 2017 (UTC)
Even if CSS allowed to hide it, note that this will not prevent the extra scripts from loading and running (every typed character will still be processed by them). —PaleoNeonate - 17:21, 19 July 2017 (UTC)
Works here. It is an element and so it can be easily hidden. The selector is correct, make sure you copied it exactly and placed it in the correct file. Not to say it won't change tomorrow though. Also the count doesn't hide anything for me, so might be a browser-specific issue. Or just that skin? Either way, might work one day! Lithopsian (talk) 17:25, 19 July 2017 (UTC)
Sorry, my mistake, I was using a different selector:
#wpSummaryWidget > .oo-ui-labelElement-label
Lithopsian (talk) 17:28, 19 July 2017 (UTC)
Since "that browser" is Chrome and "that skin" is Vector, this is the most frequently occurring combination among Wikipedia editors by an order of magnitude—we're talking a major issue, not some obscure glitch that only affects a few users using archaic systems. ‑ Iridescent 17:30, 19 July 2017 (UTC)
I figured out why this is occurring. Let's hope someone can find a fix for it soon. —TheDJ (talkcontribs) 18:31, 19 July 2017 (UTC)
I also experience a strange bug where sometimes characters become hidden under the counter when typing using FF, after typing enough it resets and I can see the new characters again. I would really like if most of those new features systematically came with corresponding disable/enable preferences (large buttons, interwiki search, this counter are examples of recent features which lacked systematic toggling options. There's now a gadget to disable the search aspect (and it could be hidden by CSS), but that was still introduced afterward and does not prevent unnecessarily loading extra scripts (and all the interdomain pages, as can be seen in inspectors or security control addons); I also noticed that page loading time increased in the last months, scripts often lagging behind the actual page. I commonly click on the watchlist star before all scripts are loaded, causing the page to reload with the "add/remove" question like if JS was disabled. Another common occurence is for the page to load and jump at the proper anchor with scripts lagging, which when loaded cause sudden scrolling/jump, where I have to select the address bar and press enter again to scroll to the anchor. It's unfortunate for this bloat to become obvious for features I don't need, even on a fast system and fast connection... —PaleoNeonate - 22:50, 19 July 2017 (UTC)
  • Yes please turn this "counter" off. It is a bug, not a feature. Jytdog (talk) 22:23, 19 July 2017 (UTC)

Character counts on subject/edit summaries?

I'm seeing character counts on the Subject and Edit summary boxes now, which I wasn't before a few days ago. However, for long edits (such as after a revert) the cursor and last few characters are hidden.

Is this on for everyone, or is my Javascript (currently only OneClickArchiver) somehow causing this? Power~enwiki (talk) 21:37, 19 July 2017 (UTC)

see #What is this number? above, sounds like the same. Nthep (talk) 21:46, 19 July 2017 (UTC)
yup, same thing. Closing. Power~enwiki (talk) 23:44, 19 July 2017 (UTC)

Process

What is the process through which this "Improvement" was implemented? Jytdog (talk) 22:24, 19 July 2017 (UTC)

God only knows. At the very least, there should have been a banner warning users of it. When I first saw it yesterday, I wondered for a moment if I'd somehow wound up on a spoofed site. RivertorchFIREWATER 23:26, 19 July 2017 (UTC)
Obviously someone at WMF who never uses this site thought it would be a great thing to implement. Hats off to them! Lugnuts Fire Walk with Me 12:11, 20 July 2017 (UTC)
It was pointed out to me here that this was done via phab:T36984. That in turn was related to phab:T165856. It ~appears~ to me that User:Jdforrester (WMF) was the person who implemented the request? I don't understand how the process of changing code works or how decisions are made to actually implement things. I suppose somebody thought this was a trivial tweak. I have no idea.
There is a Tech news thing where the devs communicate what they are doing, but I looked through the current issue and one previous issue and don't see this mentioned. Jytdog (talk) 12:31, 20 July 2017 (UTC)
Obviously someone at WMF who never uses this site is wrong per Jytdog's phabricator link (which I dug up). The original feature had implementations on other wikis in gadget form (especially the non-Latin alphabetic wikis) and has anyway existed in VisualEditor for 5 years (without seeming complaint anywhere on phabricator, besides a handful of breakages). --Izno (talk) 12:37, 20 July 2017 (UTC)
User:Izno - I have appreciated your providing information but the implementation in the WikiEditor was crappy and broke things. Period. Whether it worked somewhere else is entirely irrelevant. People get angry when their tools get broken - irrelevant argument pours oil on the fire. Jytdog (talk) 13:10, 20 July 2017 (UTC)
Indeed. So I guess we all need to start using VisualEditor so that we'll be forewarned about interface "improvements". It never ceases to amaze me: there are so many areas of the editing experience that could be improved, and WMF developers have repeatedly shown themselves capable of coming up with brilliant solutions, but they keep fixing things that aren't broken. And failing to give fair warning. RivertorchFIREWATER 13:57, 20 July 2017 (UTC)
It is rather amusing to see that almost everything now on my common.js and common.css pages exists solely to reverse various changes WMF developers made. And I certainly cannot thank enough everyone who has contributed here with wonderful solutions, with a special shout-out going to Mikhail Ryazanov and Cryptic! ^_^ Double sharp (talk) 14:36, 20 July 2017 (UTC)
@Rivertorch: Not having an indicator of how much information I could pack into an edit summary was more-or-less broken behavior and I'm personally surprised this change wasn't made earlier. "No-one got around to it because it would have been a pain before the train got rolling on the big blue Publish button" seems to be the indication from the phabricator task for the "why" of that. --Izno (talk) 15:11, 20 July 2017 (UTC)
@Izno: As I indicated elsewhere in this ever-growing section, the counter isn't a bad thing; the implementation of it is. The implementation is half-baked and was rolled out without proper notification. (It certainly wasn't urgently needed; one becomes rather adept over the years at estimating summary length and trimming as needed.) RivertorchFIREWATER 18:19, 20 July 2017 (UTC)
@Rivertorch: Agreed, generally. --Izno (talk) 18:31, 20 July 2017 (UTC)
@Jytdog: Having feelings about an (un)expected change is understandable. Communicating that in a non-collegial manner (that is, dripping sarcasm and obvious lack of research) is not. I am perturbed that you did not state an issue with his behavior but instead targeted my response, but sure, I'll move along. --Izno (talk) 15:11, 20 July 2017 (UTC)
User:Izno this was not feelings about an unexpected change - it is frustration with a change that broke something I rely on for every edit I make, that adds a "feature" that provides no value for me. Your initial responses were helpful and provided information. These last responses have not been helpful but are causing "feelings" that are decidedly not good. Jytdog (talk) 05:12, 22 July 2017 (UTC)

Make it stop

Please kill this counter. It is turning my edit notes into garble. This is so unbelievably stupid. TURN THE COUNTER OFF.Jytdog (talk) 03:00, 20 July 2017 (UTC)

This issue is being worked on. —TheDJ (talkcontribs) 09:32, 20 July 2017 (UTC)
The counter should be removed and made an option for people who want to see how much space they have left. I do not want this clutter. Removing it should be simple and fast, no? Whatever it takes to fix it can be worked out at leisure then, and It can be re-implemented as an option. Jytdog (talk) 13:13, 20 July 2017 (UTC)
The counter gets in the way of editing on a mobile / tablet and makes it impossible to leave a meaningful edit summary when reverting an edit using the web interface on an iPhone. For example: Undid revision 12345689 by Example (talk) consensus on the talk page is that this information violates the biographies of living persons policy and should not be used. Ritchie333 (talk) (cont) 09:43, 21 July 2017 (UTC)
  • It stopped!! Thank you devs, very much. Such a relief not to have to fight with the software to leave an edit note. We take simple things that work for granted, so I wanted to be sure to say thanks. I would prefer not to have the counter re-implemented but if it must be, please keep it out of the way. Jytdog (talk) 21:42, 21 July 2017 (UTC)

Cancel button no longer a button

Why is the Cancel button no longer a button, just a bolded red text link?

What on earth is that about? --BrownHairedGirl (talk) • (contribs) 09:20, 20 July 2017 (UTC)

The link has changed colour and size, but it wasn't a button before: 2014 screenshot -- John of Reading (talk) 09:29, 20 July 2017 (UTC)
The word "Citations", also without button, is floating just above the line between "Show changes" and "Cancel". (Monobook, desktop, current Firefox): Noyster (talk), 12:32, 20 July 2017 (UTC)
That sounds like you have a user script or gadget that needs updating. Anomie 12:45, 20 July 2017 (UTC)
The color change was not a good idea, because now it looks like a redlink, instead of just an editing page option. kennethaw88talk 00:00, 22 July 2017 (UTC)
Well... to experienced Wikipedians perhaps.. to the rest of the world, probably not as much. —TheDJ (talkcontribs) 10:05, 28 July 2017 (UTC)
It may not have been a button before but it looked okay then. It doesn't now. It looks wrong. Jason Quinn (talk) 10:19, 31 July 2017 (UTC)
@TheDJ: In Vector it is a bit more readable - do we have an wiki-side options for increasing the font weight in monobook? — xaosflux Talk 11:35, 31 July 2017 (UTC)
I've added bolding to the cancel button in MediaWiki:Monobook.css. — xaosflux Talk 01:44, 1 August 2017 (UTC)
Jason Quinn, I agree entirely. The new implementation is visually, and cognitively jarring. "Cancel" is an option at least as important as "Save" or "Preview". For workflow option choices such as this my brain would expect to be choosing between a set of equally prominent buttons, or a set of equally prominent links, not an odd, indiscriminate mixture. If it was "wrong" before then it never really caught my attention as such, so, for me at least, it must now be more jarringly "wrong" - probably due, in part, to the increased prominence of the buttons. I use vector. -- Begoon 11:44, 31 July 2017 (UTC)

Shortened edit summary

Nobody else seems to have mentioned it, so I will: Since the implementation of the accessible save buttons, the length of the edit summary seems to have been cut in half. I usually edit on a Windows 7 machine using 64-bit Firefox 54.0.1, using WikEd and these scripts; here is my CSS. Any suggestions? If I undo an edit, the automatically generated portion of the edit summary (the diff number and the links to the editor's contribs and talk page) take up more than half the length of the (shortened) edit summary. Thank you. — Malik Shabazz Talk/Stalk 02:47, 21 July 2017 (UTC)

I was wondering about that, but I think it's unchanged. There is a bug in that when scripting is disabled in the browser, there is no visible cursor in the edit summary box once the cursor hits the end of the box (129 characters in my browser window at the moment—that depends on how wide the window is). I can continue typing (with no visible cursor) until 200 bytes have been entered. I think that is the same as it used to be, although 255 bytes are available when scripting is enabled. Johnuniq (talk) 01:40, 23 July 2017 (UTC)
The 200-byte limit was lifted for everybody with the release of MediaWiki 1.17 back in February 2011; making this gadget somewhat redundant (it's no longer listed at Preferences → Gadgets). --Redrose64 🌹 (talk) 08:42, 23 July 2017 (UTC)
OK, but I tested before posting my comment above, and 200 bytes is all I can put in an edit summary box with scripting off, and 255 with it on. Johnuniq (talk) 09:57, 23 July 2017 (UTC)
I think it is just wikEd racing the oojs ui. If wikEd is first, it gets 200 limit (because that is the fallback if OOjs UI has not finished enhancing the view). —TheDJ (talkcontribs) 15:06, 24 July 2017 (UTC)
Thank you all for your comments and assistance. I tend to agree that it's probably a conflict with WikEd, because it doesn't happen on every edit. Just the ones for which I need a long edit summary. Face-smile.svg — Malik Shabazz Talk/Stalk 02:02, 26 July 2017 (UTC)

No preview of edit summary with live preview

I'd like to also express my disapproval of the new bigger "Save changes" etc buttons. More importantly though, I no longer get a the preview of edit summary that I used to get when I clicked "Show preview" or "Show changes". I use the MonoBook skin, but the same problem occurs when I switch to Vector. The preview of the edit summary itself is quite useful because I frequently include wiki-links in my edit summaries - most often to the relevant MOS guideline shortcut (eg MOS:BOLD) when editing pages to meet those guidelines. The summary preview showed me a clickable link (red if I've mistyped it) which I can ctrl-click (open in new tab/page) to check. Can we have the summary preview put back please. Mitch Ames (talk) 09:52, 24 July 2017 (UTC)

When I try it, in both Monobook and Vector, the preview shows up just under the edit summary input. I don't think it has even moved due to this change. Anomie 12:11, 24 July 2017 (UTC)
If I try in in a "private browsing" window, so I'm effectively not logged in, the preview appears, so perhaps there's something in the new style that conflicts with one or more of the settings in my preferences. I could reset them all to defaults and work through them all, but that will be tedious. Does anyone have any suggestions as to specific settings to try? Mitch Ames (talk) 13:34, 24 July 2017 (UTC)
Mitch Ames, if you are using the Live Preview option of your preferences, then there is currently a bug where the preview of the summary doesn't work. This is ticket phab:T171156. —TheDJ (talkcontribs) 14:59, 24 July 2017 (UTC)
Thanks - that's the cause in my case. I do have live preview enabled, and if I disable it the summary preview reappears. Mitch Ames (talk) 11:22, 25 July 2017 (UTC)
By the way, does anybody know how to get "Templates used in this preview" working with "live preview"? Now it shows "Wikidata entities...", "...member of categories" and a rather useless "Parser profiling data", but not the templates, so getting to template documentation is a nontrivial task. (In :ru, "live preview" is invoked by a different button, so a "regular" preview can still be easily done as a work-around. But why can't it just work properly?). — Mikhail Ryazanov (talk) 22:42, 8 August 2017 (UTC)

Show Preview and Show Changes on a single button

Since everyone's focused on this general topic, can I renew my plea for a single button that will give "Preview" and "Changes" at the same time? It's such a perfectly obviously useful thing, and there should be zero design issues. I'll just sit here and hold my breath until that's done. Thanks. EEng 13:43, 27 July 2017 (UTC)

@TheDJ:: What's the status of your experimental script for this? Whatamidoing (WMF) (talk) 16:13, 27 July 2017 (UTC)
@TheDJ:, I'd kill for this feature. EEng 12:53, 29 July 2017 (UTC) Note: Not actual threat to kill anyone.
You didn't say that you'd kill a person. How about killing off your choice of maintenance categories instead?  ;-) Weeding the stale templates out of Category:Pages actively undergoing a major edit looks a fair trade, if the script is still viable. WhatamIdoing (talk) 05:56, 31 July 2017 (UTC)
Completely fair. I'll do it in dribs and drabs today over the next few days (visitors). EEng 13:29, 31 July 2017 (UTC)
A month of visitors, it turns out. I sure hope you're ready to make good on your side of the bargain. I'm counting on you. EEng 17:26, 18 August 2017 (UTC)

Citation expander

The Wikipedia:Citation expander gadget adds as "Citations" link that hasn't been beefed up for the new button scheme. Would somebody more familiar with whats going on with the buttons right now be willing to file a phab report about that? Jason Quinn (talk) 14:51, 31 July 2017 (UTC)

@Smith609: I assume that you don't actually want a Phab task about MediaWiki:Gadget-citations.js. Whatamidoing (WMF) (talk) 16:45, 31 July 2017 (UTC)

Delete page

The Delete page button looks like a redlink. --Redrose64 🌹 (talk) 21:53, 6 August 2017 (UTC)

Pagecounts-ez dataset hasn't generated since JUL-23

The daily page-view files at [7] stopped generating/aggregating on JUL-23. Any ideas on who to ping to get this restarted? Documentation suggests they should still be chugging along. West.andrew.g (talk) 19:17, 28 July 2017 (UTC)

Thanks for reporting. We migrated to new stats server (faster than originally scheduled). I'll look into this Monday. Erik Zachte (talk) 15:56, 29 July 2017 (UTC)
@Erik Zachte: Ping! Not a huge deal, but this does delay the WP:5000 and WP:Top25Report. Thanks, West.andrew.g (talk) 13:00, 1 August 2017 (UTC)
@West.andrew.g: The server switch was an emergency, so not time for preparation. Thing were placed in different setup folder structure. I'm looking into it. Erik Zachte (talk) 14:23, 2 August 2017 (UTC)
Thanks Erik Zachte, a resolution would help immensely. Kindly keep us posted. — JFG talk 19:59, 4 August 2017 (UTC)
Thank you Erik Zachte. Please do resolve this. We don't need to manually count the top 25 for next week. FunksBrother (talk) 04:28, 6 August 2017 (UTC)
Job is running, processing backlog. Data should appear within 24 hours. Erik Zachte (talk) 10:41, 6 August 2017 (UTC)
All data have been generated. Now I'm waiting for rsync to be fixed on new server. Request has been sent to operations. Erik Zachte (talk) 13:10, 7 August 2017 (UTC)
Files are online till August 6. Sorry for long outage. Reorganization of Wikistats environment after emergency move to new server is ongoing. Erik Zachte (talk) 09:26, 8 August 2017 (UTC)
Thanks so much! West.andrew.g (talk) 13:52, 8 August 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Erik Zachte: Errrr... Things came to a stop again. Last date generated is 2017-08-08. Thanks, West.andrew.g (talk) 03:18, 14 August 2017 (UTC)

Yeah, the script worked manually, but failed as a cron job with different settings. Fixed. Erik Zachte (talk) 08:17, 16 August 2017 (UTC)

Searching for visible pipe

Using the standard search, what's the expression for a visible pipe? I want to find and fix the bad edits made by Ruttnpark (talk · contribs) such as those to Midland and Great Northern Joint Railway and Dunstable Branch Lines. I've tried this this and this, none worked. It seems to be treating the pipe as a logical OR, I want it literal. --Redrose64 🌹 (talk) 15:12, 6 August 2017 (UTC)

@Redrose64: Searching for insource:/Class 31\|/ should work, if you're only looking for Class 31|. I think symbols are ignored without both regex and insource. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
15:31, 6 August 2017 (UTC)
I'm not looking for piped links (although that editor has been violating WP:NOTBROKEN too). I'm looking for double piped links, those where the second pipe is visible in the rendered text, as with the content of this section. --Redrose64 🌹 (talk) 17:17, 6 August 2017 (UTC)
I would start with this. There may be more, but I am bad at regex so the search times out. A database scan may be the best way. (WT:AWB has some pretty good regex types that you might inquire with.) --Izno (talk) 17:58, 6 August 2017 (UTC)
I think this is a subset of CheckWiki error 32, so the scan is already done for you. -- John of Reading (talk) 18:25, 6 August 2017 (UTC)
How often is that updated? The relevant report seems to be mostly from July. --Redrose64 🌹 (talk) 20:57, 6 August 2017 (UTC)

Short answer : No, it is not possible to search for certain visible tokens or symbols such as a pipe on a page. Proof (https://en.wikipedia.org/w/index.php?search=%7C). There's no way only a single article has it visible ...

Longer answer: The search engine deliberately removes this to improve general search.

The best way to use insource is to make the regex efficient and to use a very good filter to prevent it from timing out.

One sneaky and a bit crazy way of searching all those pages edited by that user, is to temporarily add a hidden category to each of them. Then this would be as simple as writing "insource:/\[\[.*\|.*\|.*\]\]/ hascategory:temporary_search_cat123". Considering that at the time of this writing the user has only edited ~ 204 pages, it is probably a non-issue. Though others may disagree. Other possibilities include finding a common category / template or term in all those pages and using or alternating between all of them, for example, a lot of those page titles contain the word "rail"(intitle:rail), "line", or "class".

This won't help if the general goal is to find all these.In such cases the dumps are better. Fine tuning a query like : "insource:/\[\[[A-Za-z0-9 \_]*?\|[A-Za-z0-9 \_]*?\|[A-Za-z0-9 \_]*?\]\]/ hastemplate:reflist" will make it possible to find all such occurrences. As a sidenote, even google chokes with a similar search : '"|" site:en.wikipedia.org'. 22:06, 6 August 2017 (UTC) — Preceding unsigned comment added by 197.218.90.95 (talk)

  • The user has "only" edited 198 articles so I cheated by downloading the current wikitext of them all, and searching that. There are no occurrences of problematic links like [[...|...|...]]. Johnuniq (talk) 23:03, 6 August 2017 (UTC)
Nice workaround, it might be suitable for a basic userscript for users with few contributions. Anyway, it seems that at least a few search engines can find such characters, e.g. http://symbolhound.com/?q=%7C&l=&e=&n=&u=en.wikipedia.org . According to that site there currently seem to be ~ 570 indexed pages with visible pipe symbols. Scrapping that site for such occurrences could be used as a short term workaround for this problem. 10:24, 7 August 2017 (UTC) — Preceding unsigned comment added by 197.218.88.42 (talk)


Sample data for viewing:

[[British Rail Class 31|Class 31|Brush Type 2]]

while formulating:

insource:/"[["[^\]]*\|[^\]]*\|[^\]]*"]]"/ prefix: a

and refining:

insource:/"[["[^\]]*\|[^\]]*\|[^\]]*"]]"/ -insource: image -insource: file prefix: a

Note how the regexp pattern only works on pages whose titles begin with A, (otherwise it will timeout), without images, but captures unwanted "double pipes" caused by instances of valid template pipes informing the wikilink label. From the highlighted matchings, note the impossibility of the existing or other further refinements.

Please find and contribute time towards the improvement of the search documentation. It's on WP, MW, {{search link}}, {{regex}}, etc. Prod their talk page. Then bring it up on phabricator. But, I know, here at WP:VPT it is so big city, and there their talk pages are small country. — Cpiral§Cpiral 09:43, 14 August 2017 (UTC)

New pages -- patrolled?

On the New pages page, which lists recently created articles, it says, "Yellow highlights indicate pages that have not yet been patrolled." Lately when I look there I don't see any articles highlighted, though I used to see highlighted ones pretty often. Is the highlighting function broken? Or is there some other explanation? Mudwater (Talk) 19:59, 5 February 2017 (UTC)

I am getting yellow-highlighted entries. Of the first 10 pages listed, 3 are yellow, 1 was marked as patrolled by Twinkle while PRODing it, and the other 6 were created by users with the Autopatrolled right. עוד מישהו Od Mishehu 21:48, 5 February 2017 (UTC)
@Mudwater: As of November 16, 2016, you need to be a new page reviewer to be able to patrol new pages. Before then, all autoconfirmed users could patrol new pages. GeoffreyT2000 (talk, contribs) 04:59, 6 February 2017 (UTC)
A lack of yellow-highlighted pages normally means that people have been patrolling from the front (newest) and not the back (oldest), contrary to the advice at the top; and this in turn means that unpatrolled pages at the back eventually get old enough (31 days?) to drop right off the list without ever being patrolled. Apart from that issue, patrolling from the front can be WP:BITEy, since pages get CSD-tagged within seconds of creation. --Redrose64 🌹 (talk) 10:28, 6 February 2017 (UTC)
Although not in contradiction, it's worth recalling that it says here that While it is a good idea to reduce the backlog of unreviewed pages by working from the back of the list, it is nevertheless important that serious breaches of policy such as spam and attack pages are deleted very quickly. O Fortuna!...Imperatrix mundi. 10:48, 6 February 2017 (UTC)
Yep, those two (possibly also copyvios) are the sort of thing where CSD should be applied ASAP; but that does not extend to every CSD criterion. I have seen pages tagged {{db-nocontext}} or {{db-person}} within a couple of minutes - in cases like these, the page creator must be given the chance to flesh it out. --Redrose64 🌹 (talk) 20:06, 6 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Hello. I'm reviving this archived thread because, in case anyone is interested, I just figured out the answer. Some months ago -- October 2016, maybe? -- the rules for patrolling new pages were changed. Now non-admin editors, such as myself, can only patrol new pages if they have new page reviewer rights. I didn't know that until quite recently. I just got new page reviewer rights, and now, on the New pages page, I can see the yellow highlights again, indicating which pages have not been patrolled. To say the same thing in a different way, the yellow highlights are only visible to editors who have new page reviewer rights, and as of some months ago that's a much smaller group. Mudwater (Talk) 02:28, 7 August 2017 (UTC)

This discussion just made me realize that this is a total accessibility issue, where information is communicated solely by color highlighting.. —TheDJ (talkcontribs) 00:09, 8 August 2017 (UTC)
@TheDJ: not "solely" there is a separate li class name in use not-patrolled - it could be hooked by someone interested. — xaosflux Talk 03:14, 11 August 2017 (UTC)
@TheDJ and Xaosflux: Just now I noticed that no pages are highlighted, and none of the li's have the not-patrolled class associated with them. As far as I know, I still have my NPP bit. Are either of you aware of any recent CSS changes that may have caused this? – Train2104 (t • c) 02:08, 18 August 2017 (UTC)
These do appear to all be broken now as well, similar to a long ignored phab ticket, phab:T144132 on arwiki. — xaosflux Talk 02:39, 18 August 2017 (UTC)
Phab ticket phab:T173556 opened for now. — xaosflux Talk 02:46, 18 August 2017 (UTC)
Having the same problem. Makes it difficult to patrol pages right now. At first I thought I might have accidentally been logged out, but that didn't happen. Can this be fixed easily? Narutolovehinata5 tccsdnew 04:17, 18 August 2017 (UTC)

Recent changes is actually a kitchen sink that many other pages related to new changes steal content from. So, as a side-effect of the new filters, everyone can actually see the patrolled status of a "new" page using it. Even if that weren't the case, this has probably always worked using the API. As a workaround (until this is fixed) simple way to see all new pages that haven't been patrolled is to use a link like so:

https://en.wikipedia.org/wiki/Special:RecentChanges?hidenewpages=0&hidepageedits=1&hidepatrolled=1&hidelog=1&limit=1000&&days=30

Or simply use the Special:newpagesfeed which has its own filters. 08:38, 18 August 2017 (UTC) — Preceding unsigned comment added by 197.218.83.162 (talk)

Nested tables

Is it technically possible to allow collapsing only part of a table, such as in {{Collapsed infobox section begin}}, {{Infobox station}} and {{3 (New York City Subway service)}}, without nesting tables within each other? The Norwegian Wikipedias have a sort-of-solution, but this only allows for one collapse button per table. (In addition, is it possible to prevent a table cell containing only images from wrapping, so that the images stay left to right? This would solve the other nested table problem in the third template.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
12:32, 8 August 2017 (UTC)

In principle, yes but someone needs to do the work: to write the code, introduce necessary classes etc. Ruslik_Zero 20:47, 8 August 2017 (UTC)
Also, collapsing of content, however popular is also ill advised: Wikipedia:Manual_of_Style#Scrolling_lists_and_collapsible_content. If you need to collapse content to hide it on Desktop, then you likely should have already changed the form of the content for editorial reasons anyway. My opinion on this is "Collapsed content is a signal of a lazy editor". —TheDJ (talkcontribs) 14:49, 9 August 2017 (UTC)
@TheDJ: Some infoboxes (e.g. station, Chinese, soap character) have the collapse built in, probably for the sake of not filling up people's screens. I suppose it's bad to do this in the middle of the prose, but for sidebars, etc., it's not really problematic to collapse content. FWIW the Wikipedia app automatically collapses all infoboxes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:19, 10 August 2017 (UTC)
"In addition, is it possible to prevent a table cell containing only images from wrapping" yes, you set a fixed width using CSS on the table cell that contains the images. —TheDJ (talkcontribs) 14:49, 9 August 2017 (UTC)
The problem with this is that {{Routemap}} does not have a parameter for the width of the centre icon column, and some icons have the wrong width prefixes/suffixes so it's not yet possible to calculate width automatically. If it's not possible with HTML then it's not really a big deal (a regular screen reader couldn't read the diagrams anyway) and the problematic icons will probably be renamed eventually. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:19, 10 August 2017 (UTC)

Lua error - searching

On doing the search:

incategory:"All orphaned articles" incategory:"Genes on human chromosome 6"

One of the results is showing:

UNC5CL
Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead. Unc-5 homolog C (C. elegans)-like is a protein in
539 bytes (51 words) - 13:53, 1 August 2017

Eno Lirpa (talk) 13:31, 10 August 2017 (UTC)

It's temporary. The error was recently displayed on many articles. Individual pages can be fixed by a purge. The search function happened to cache (computing) the article UNC5CL when it displayed the error. A search on part of the error message "data.schemaVersion must be a number, got nil instead" currently gives me 326 pages. None of the examined pages display the error now. The search cache could be updated faster by editing the articles (a null edit might be insufficient), but I wouldn't worry about it. PrimeHunter (talk) 13:48, 10 August 2017 (UTC)
Thanks Eno Lirpa (talk) 13:54, 10 August 2017 (UTC)

Windows 10 and spellchecker

I recently started using Windows 10 and am having trouble with spellchecker in the Wikipedia edit window. Apparently, Windows 10 tries to spellcheck every box that can be typed in whether it is a Windows application or not. The result is that every piece of wikicode on the page gets a squiggly red line under it. I have turned off autocorrect and spelling highlighting in the settings page. I have also run the registry changes downloaded from this forum page but nothing seems to work. Anybody here got any ideas how to deal with this? SpinningSpark 19:28, 10 August 2017 (UTC)

@Spinningspark: Which browser are you using? (((The Quixotic Potato))) (talk) 19:52, 10 August 2017 (UTC)
Various browsers have the wiggly red line. I ignore it. --Redrose64 🌹 (talk) 21:12, 10 August 2017 (UTC)
I'm using Firefox, but I don't think it's especially browser related. Word has the same problem for instance. I never had any of this while I was using Windows 7 (still don't on my old PC). Definitely seems to be an issue with Windows 10. SpinningSpark 21:51, 10 August 2017 (UTC)
Not new. XP does this. --Redrose64 🌹 (talk) 22:40, 10 August 2017 (UTC)
See https://support.mozilla.org/en-US/kb/how-do-i-use-firefox-spell-checker#w_disabling-automatic-spell-checking. PrimeHunter (talk) 00:00, 11 August 2017 (UTC)
Solved, thanks. @Redrose64: I have an XP Notebook (now only used in the kitchen for recipes) and I have never seen this before on Wikipedia. SpinningSpark 17:27, 12 August 2017 (UTC)

Watchlist changes

It's Thursday. The watchlist has changed. Previously, at Preferences → Watchlist → Maximum number of changes to show in watchlist, if you had set a value of zero this would be treated as "infinite". Now it's treated as zero, so I now need to set a positive non-zero integer - with an enforced maximum at 1000. This means that when somebody with AWB and editcountitis has decided to make changes to 1001 pages on my watchlist (and it has happened, several times), there are going to be changes that I will simply never see. At present, my watchlist won't show me anything earlier than 14:06, 8 August 2017 - 55 hours ago. --Redrose64 🌹 (talk) 21:02, 10 August 2017 (UTC)

  • Please change this setting back. Who discussed this. Why was this change made? Ridiculous. GenQuest "Talk to Me" 21:21, 10 August 2017 (UTC)
  • I'm not experienced with the issue you're facing, but from a technical standpoint "zero really means zero" somewhat makes sense. If there was no enforced maximum, maybe -1 should be made to mimic the old behavior? I can only guess this change was done for performance reasons, but until someone who knows tells more I don't know. 2001:2003:54FA:D2:0:0:0:1 (talk) 22:02, 10 August 2017 (UTC)
  • I suspect this is a side effect of the improvements to deal with watchlist queries crashing. Ticket phab:T171027. In that case it's possibly an intentional limit to guarantee performance for of the system. —TheDJ (talkcontribs) 02:28, 11 August 2017 (UTC)
  • Please change it back (or atleast revert these "watchlist fixes" as instead of fixing the watchlist another problem has been created instead, Mistakes happen so not going off on one but going from 3 days worth of pages to 250 isn't ideal for me at all..... –Davey2010Talk 11:47, 11 August 2017 (UTC)

As usual, TheDJ is correct. I asked around, and learned that this is a WP:PERFORMANCE issue. Disallowing infinite page length on Special:Watchlist was the least-bad of several bad options.

I understand that a partial workaround is in the works, to let you filter out changes you've already looked at. (So you read the most recent 1000, then hide the ones that you've already read, and see the next-most-recent 1000, and repeat – you'll never miss any, but you won't see 1,0001+ on the screen at the same time.) However, this probably won't be available for approximately one month. In the meantime, please reset your watchlist numbers to something greater than 0.

If you'd like, I believe that 0 could be re-defined as whatever the maximum is. However, even if that change were written today, it wouldn't reach this wiki until next Thursday. Because of the delay, I'm not sure that it's worth it: most of the few editors affected by this will want to reset their watchlist lengths immediately, rather than waiting a week for an automatic fix. Whatamidoing (WMF) (talk) 21:04, 11 August 2017 (UTC)

  • Comment - Is there a way to make the default number of watchlist items 50 items? Can the system require the user to specify a date range? --Jax 0677 (talk) 15:28, 15 August 2017 (UTC)

My watchlist is suddenly blank?

My watchlist has recently stopped listing any articles. I've tried this on several browsers and OSes. I have also logged out and back in. I have also removed all the filters. I have over 2,400 watched pages, so I know I have stuff on there. Any help? (EDIT: I won't really be able to tell if anyone has replied to this since... well, my watchlist isn't working. I'll be sure to check back frequently.) PureRED (talk) 01:39, 11 August 2017 (UTC)

from above: "at Preferences → Watchlist → Maximum number of changes to show in watchlist, if you had set a value of zero this would be treated as "infinite". Now it's treated as zero". Try setting it to 500 or 1000. Power~enwiki (talk) 01:43, 11 August 2017 (UTC)
Thank you so much! PureRED (talk) 01:51, 11 August 2017 (UTC)

Bot edits?

If I recall correctly, if the "filter bot edits" checkbox was selected, you would see the most recent non-bot edit to a page, even if a bot had edited it in the meantime. Now, it pages where the most recent edit was by a bot are filtered from the watchlist entirely. is it just me, or is this a regression? Power~enwiki (talk) 03:25, 12 August 2017 (UTC)

Help:Watchlist#Options says:
  • If the most recent edit to a page is hidden and "Expand watchlist to show all changes, not just the most recent" is not enabled in preferences then the page will not appear on the watchlist. An earlier edit is not shown instead.[1]

References

  1. ^ Bug 9790: Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits.
I added it in 2014 [8] and it has always been like this as far as I know. PrimeHunter (talk) 11:35, 12 August 2017 (UTC)
OK. I must have mis-interpreted how it was working before. Power~enwiki (talk) 01:59, 14 August 2017 (UTC)

Is my watchlist limited to 250 changes?

When I look at 30 days of my watchlist, it only shows a few days. Is it limited to 250 changes? Please {{ping}} me when you respond. --Jax 0677 (talk) 14:54, 15 August 2017 (UTC)

MediaWiki revision navigation is not excluded from printing

MediaWiki:Print.css does not exclude #mw-revision-nav from printing.

Consider an old revision such as Special:Permalink/794918659 and print the page (or use print preview). The navigation for previous/latest/next revision is printed, despite not being interactive or useful on paper, unlike the #mw-revision-info above it.

Can the useless-on-paper #mw-revision-nav element be hidden in print? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:26, 10 August 2017 (UTC)

  • I've hidden it on en.wp for now, but we will need to add this to core soon. —TheDJ (talkcontribs) 22:03, 10 August 2017 (UTC)
    • Thanks. Could you also update the code comment above it to include a fifth item, the revision navigation? 2001:2003:54FA:D2:0:0:0:1 (talk) 22:10, 10 August 2017 (UTC)
    • The issue ticket title could also use improvement: Hide mw-revision-nav on old revisionsHide mw-revision-nav on old revisions in print mode. 2001:2003:54FA:D2:0:0:0:1 (talk) 22:13, 10 August 2017 (UTC)

HotCat disappeared

I opened a tab and HotCat was gone. Cat-a-Lot as well. Can anyone tell me why and how to re-enable them? ―Justin (koavf)TCM 04:47, 11 August 2017 (UTC)

Will return soon. A sockpuppet investigation concluded that an account was a sockpuppet, was then blocked on en.wp and consequently went on a deletion spray on with his sysop rights on Commons. quite sad. Over 1600 pages/files deleted, including the Commons mainpage, several gadgets etc.. restoration is being worked on. —TheDJ (talkcontribs) 05:29, 11 August 2017 (UTC)
@TheDJ: Thanks. All's well now. ―Justin (koavf)TCM 15:44, 11 August 2017 (UTC)

Page history of WP:BN doesn't show in Popups

Resolved: This is so odd. I've changed nothing at all, but suddenly it's working fine again. --Dweller (talk) Become old fashioned! 10:28, 11 August 2017 (UTC)

Any Popups guru out there? As a Crat, WP:BN is a really important page for me, but weirdly I can't see its page history using Popups when I hover over the appropriate place on my Watchlist.

Just to deepen the mystery, other Projectspace pages seem to work fine.

Advice welcomed. Just go easy on me, I'm not very technical. --Dweller (talk) Become old fashioned! 09:28, 11 August 2017 (UTC)

It works for me in Firefox on Windows 10 when I hover over the "hist" link. PrimeHunter (talk) 10:09, 11 August 2017 (UTC)
All other pages seem to work fine. Using Windows 8.1 Pro and Chrome 60.0.3112.90. Irritating. --Dweller (talk) Become old fashioned! 10:26, 11 August 2017 (UTC)
There is some issue that effects a number of scripts that work only intermittently. Possibly a resource that for some reason could not be loaded, which stops further loading on that particular page. I have turned to bookmarking those pages and reopening from the bookmark list, which has a high success rate. Agathoclea (talk) 08:46, 18 August 2017 (UTC)

Why does autoblock disclose the name of the blocked account associated with the autoblocked IP address

As mentioned here [9], apparently when autoblock does its thing (blocking not-logged-in access via an IP recently used by a blocked account) it declares the name of the blocked account which is causing the IP to be blocked, thereby doing something we go to great lengths elsewhere not to do i.e. associate IPs with accounts. This obviously isn't a problem if only the blocked editor is using that IP, but where an IP is shared (e.g. at work) it does something we go to great lengths elsewhere not to do i.e. tell people the IP from which a named account has been editing. It is really necessary for the autoblock message to give the name of the blocked account? EEng 11:35, 11 August 2017 (UTC)

I believe this is phab:T55008. Jo-Jo Eumerus (talk, contributions) 15:07, 11 August 2017 (UTC)
Phabulous, thanks. EEng 15:12, 11 August 2017 (UTC)
Unfortunately, we need some reasonable mechnism to allow normal admins to see who the original blocked user is. The only alternative is that only CheckUser users be allowed to deal with autoblocks - and I think that would be worse. עוד מישהו Od Mishehu 02:42, 14 August 2017 (UTC)
How does showing a not-logged-in IP editor the name of the blocked user help admins see the name of the blocked user? EEng 23:41, 14 August 2017 (UTC)
As the software is right now, the only way anyone, including admins, can see this information is in the publicly-visible autoblock reason. עוד מישהו Od Mishehu 07:57, 15 August 2017 (UTC)
I guess I'm confused. I thought this was a message displayed to the IP when it makes an attempt to edit. When/where is this message displayed such that an interested admin (or, perhaps, any editor) can see it? EEng 15:36, 16 August 2017 (UTC)
At Special:BlockList. You can see an individual autoblock by entering its number (everything from the number sign onwards) in the "IP address or username" textbox. עוד מישהו Od Mishehu 13:37, 17 August 2017 (UTC)
  • I think we're talking past each other, but anyway I've lost interest. Thanks, though. EEng 14:04, 17 August 2017 (UTC)

Navbox formatting

Is it possible in {{Challenge Cup}} to remove the first six entries in list1 and maintain the right alignment of the remaining entries? I can see that previous editors want the columns lined up in decades and the first entries are dummies solely to achieve this as the competition didn't start until 1896–97. I did wonder about using template:0 but I couldn't work out a way to make the bullets invisible. Nthep (talk) 15:45, 11 August 2017 (UTC)

I do not think that you can do this with in the standard navbox. Ruslik_Zero 20:27, 11 August 2017 (UTC)
@Nthep: Will this do? – Srdjan m (talk) 20:59, 11 August 2017 (UTC)
Brilliant, thx. Nthep (talk) 21:15, 11 August 2017 (UTC)

Template help

Hey guys. I was wondering how you can make one parameter replace the whole texts on a template if a value is given? For example: this is an example template. {{#if: {{{example2}}} | yes | this should replace the previous texts entirely.}} can you do that? ◂ ‎épine talk 01:04, 12 August 2017 (UTC)

@Épine: I'm not sure what you're trying to do. If you want to ignore the rest of the template if |example2= has text, then your template should look like {{#if: {{{example2|}}} | «text to display if example2» | «if not, then rest of template here» }}. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:14, 12 August 2017 (UTC)
@Jc86035: that's exactly what I wanted. Thank you! ◂ ‎épine talk 07:25, 12 August 2017 (UTC)
If you want to understand how it works so you can make other code in other situations: If the parameter example2 is not set then {{{example2}}} produces itself, i.e. that exact 14-character string. But {{{example2|string}}} will produce string if example2 is not set. So {{{example2|}}} with nothing after the pipe will produce empty. {{#if:string|yes|no}} produces yes if string is non-empty and no if it's empty. Therefore {{#if: {{{example2|}}} |yes|no}} produces yes if example2 is set to something non-empty , and no if it's not set or is set to empty, i.e. |example2= with no value. PrimeHunter (talk) 11:24, 12 August 2017 (UTC)

Edit section not appearing on mobile view

[10]

The problem appears to be TOC not appearing, but I am not sure what exactly is causing the issue. Any thoughts? Alex ShihTalk 03:23, 12 August 2017 (UTC)

The problem is solved if I close the table properly, but is there another way? Alex ShihTalk 03:31, 12 August 2017 (UTC)
I tried rewriting the page in plain script, but still cannot figure out what is preventing the TOC and the page content from appearing in mobile view. Alex ShihTalk 03:54, 12 August 2017 (UTC)
@Alex Shih: Try using <div> tags instead of tables (the width attribute might need to be changed to CSS). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:29, 12 August 2017 (UTC)
@Jc86035: Thank you for your response. I tried doing both but the edit section/the content still wouldn't appear. So frustrating :( Alex ShihTalk 07:43, 12 August 2017 (UTC)
@Alex Shih: You've left in the td and tr tags. Remove the tr tags, replace td with div, remove the width: 70%;, and change platinum to silver (platinum is apparently not a real colour). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:52, 12 August 2017 (UTC)
@Jc86035: Thanks again, I followed these instructions, and it's looking better but the edit section still wouldn't appear (sad face). Alex ShihTalk 07:59, 12 August 2017 (UTC)
@Alex Shih: It doesn't seem to work inside tags. I've filed a bug, but I don't think it'll be fixed unless a developer really wants to have their talk page decorated nicely. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
08:09, 12 August 2017 (UTC)
@Jc86035: I see! I feel less silly now, thank you so much. I'll make adjustments accordingly in the meanwhile... Best regards! Alex ShihTalk 08:11, 12 August 2017 (UTC)

the search box on my watchlist isn't working

Most common search strings work, and I can type in words I see on the screen and see them light up. But my most common search string, "scout" automatically turns red, although I have myself made 3 edits on my watchlist to Scouting topics in the last 72 hours. What's afoot?--Kintetsubuffalo (talk) 07:34, 12 August 2017 (UTC)

Wikipedia has no feature to search the watchlist so I guess you are using a browser feature to search a string on the current page. Check whether it has enabled options which limit search results, e.g. by being case sensitive or only searching whole words. Are you sure the watchlist actually displays the exact string you search for? PrimeHunter (talk) 11:01, 12 August 2017 (UTC)
I'm certain because it's worked for 9 years until yesterday, on two unconnected computers.--Kintetsubuffalo (talk) 12:54, 12 August 2017 (UTC)
Maybe this could be related to the change in the maximum number of watchlist entries? Jc86035 (talk) 13:01, 12 August 2017 (UTC)
Jc86035I betcha that's it, the timing matches! Thank you! What thing do I need to reset from zero?--Kintetsubuffalo (talk) 13:24, 12 August 2017 (UTC)
@Kintetsubuffalo: Go to Special:Preferences#mw-prefsection-watchlist and set the maximum number of changes to a bigger number. Jc86035 (talk) 13:26, 12 August 2017 (UTC)
Thanks, got it working, kinda! The new maximum means I can't ever take a break or I'm lost...--Kintetsubuffalo (talk) 13:56, 12 August 2017 (UTC)
Help's on the way, in the form of filters that will show the most recent n changes that you haven't seen yet. (So just no breaks for the next month or so.  ;-) Whatamidoing (WMF) (talk) 21:23, 12 August 2017 (UTC)
@Whatamidoing (WMF): By "changes that you haven't seen yet", does that mean that I would need to view the most recent edits before any earlier edits become available to view? Seems backwards. What about introducing offset= and dir= parameters into the query string, as presently permitted by page history or a user contributions? Then, if I knew that my last watchlist check was at, say, 22:15 yesterday, I could use the query string parameters dir=prev&offset=20170811221500 to view watched edits going forward from that moment. --Redrose64 🌹 (talk) 22:54, 12 August 2017 (UTC)
That's my impression, although it's not my project, so I could be wrong.
I like the &offset= idea, but it feels like the sort of thing that's really only useful if you show each change individually (rather than the default). I know one editor who never checked diffs until the page hadn't been edited for a week, so s/he would probably appreciate an offset that hid the most recent 6 days. (Apparently, it's a good strategy for avoiding disputes.)
I believe that you could also filter by namespace to 'extend' the list: the 1000 most recent changes that I haven't read in this namespace, followed by the 1000 most recent changes in that namespace, etc. If your watchlist is reasonably diverse, then this may work around the problem now. Whatamidoing (WMF) (talk) 00:09, 14 August 2017 (UTC)
Might have been practical when we had 16 namespaces, two of which (MediaWiki and MediaWiki talk) I never touched; but now we have 32. --Redrose64 🌹 (talk) 08:41, 14 August 2017 (UTC)

Broken edit syntax highlighting on (expected) unclosed tags

When editing, bare tags such as <br>, <hr>, or <p> will highlight subsequent text in pink (as long as there is a "<" somewhere below). In the case of the first two, one can manually close them, however<p /> (which fixes the incorrect highlighting) is invalid per Category:Pages using invalid self-closed HTML tags. Has this issue already been reported? Thanks, ~Hydronium~Hydroxide~(Talk)~ 12:31, 12 August 2017 (UTC)

I'm guessing that you are using the Syntax Highlighter gadget. See mw:User:Remember_the_dot/Syntax_highlighter#Parsing for an explanation. – Jonesey95 (talk) 15:05, 12 August 2017 (UTC)
Thanks Jonesey95. That's it. ~Hydronium~Hydroxide~(Talk)~ 08:13, 17 August 2017 (UTC)

References are now unordered lists

I just edited Begin the Begin and see that the references are no longer numbered--this is a very useful feature. Does anyone know why this is happening? ―Justin (koavf)TCM 16:56, 12 August 2017 (UTC)

If I had to guess, probably something to do with the reference wedged into the reflist template. Ian.thomson (talk) 16:59, 12 August 2017 (UTC)
Fixed by Nthep.[11] PrimeHunter (talk) 18:48, 12 August 2017 (UTC)

"Place the category box above all other content" and section anchors

This is an oldie but goodie. When "Place the category box above all other content" is checked under Preferences > Gadgets, the category box is moved to the top of the screen, which makes categories more accessible, etc. However, if this is checked when the editor arrives via an anchor/section link, the category box often moves after the browser view has navigated to the section, offsetting the the link or visual anchor by the height of the category box such that the link/visual anchor is no longer at the top of the editor's window. Would there be any way to change the loading order such that the category box moves to the top of the page in advance of the window navigation, so I can navigate as intended? (Please {{ping}} me if you respond with a question.) czar 20:03, 12 August 2017 (UTC)

The movement is done with javascript, so it is probably impossible. Ruslik_Zero 20:45, 12 August 2017 (UTC)
It's a browser problem. As noted above, the cat box is moved by javascript; but some browsers (like Firefox and Opera) navigate to the anchor as soon as the page is loaded, they don't wait for javascript to finish first. This is probably because on some web pages, the Javascript is non-terminating - it executes continuously (rolling banner adverts are an example, as are news feeds), and so on these pages, the browser would be waiting for an event that will never happen, and so will never jump to the anchor. --Redrose64 🌹 (talk) 21:04, 12 August 2017 (UTC)
As a stopgap, would it be possible/practical to have the browser re-navigate to the anchor after the category box moves, as part of the gadget? czar 22:26, 12 August 2017 (UTC)

"national youth handball team" or "youth national handball team"

Resolved: This section is neither the correct forum (there are no technical issues here, only naming policy issues), nor still relevant (as the OP has moved the "youth national" titles to "national youth"). עוד מישהו Od Mishehu 12:28, 13 August 2017 (UTC)

Which word order is correct? Men's national teams use "national youth", women's – "youth national". For example:

Maiō T. (talk) 23:43, 12 August 2017 (UTC)

@Maiō T.: This is not a VPT matter. A good place to have such a discussion would be the talk page of an interested WikiProject, such as Wikipedia talk:WikiProject Handball. --Redrose64 🌹 (talk) 07:34, 13 August 2017 (UTC)

Help with category renaming

I'm trying to figure out how to cause the code {{Expert-subject|New York|reason=Foo}} to populate Category:New York (state) articles needing expert attention in stead of Category:New York articles needing expert attention. Can some one please help me on this? עוד מישהו Od Mishehu 06:32, 13 August 2017 (UTC)

@Od Mishehu: Not a good idea. New York is ambiguous; the problem should be fixed at source, by altering each individual template use to be either {{Expert-subject|New York (state)|reason=Foo}} or {{Expert-subject|New York City|reason=Foo}} as appropriate. --Redrose64 🌹 (talk) 07:43, 13 August 2017 (UTC)
KISS principle supports Redrose64's answer. The template will soon become unwieldy if it has to cater for every disambiguation. If you're sure that every NY means NYS, not NYC then AWB or a bot could churn through the job of altering the template call. Cabayi (talk) 07:55, 13 August 2017 (UTC)
How would we do that so the WikiProject link will point to Wikipedia:WikiProject New York, not to Wikipedia:WikiProject New York (state)? עוד מישהו Od Mishehu 10:12, 13 August 2017 (UTC)
Is that necessary if you just redirect Wikipedia:WikiProject New York (state)? PrimeHunter (talk) 10:19, 13 August 2017 (UTC)
Until/unless the WikiProject is renamed, we shouldn't be displaying the name "WikiProject New York (state)". עוד מישהו Od Mishehu 10:40, 13 August 2017 (UTC)
The documentation for the template states "These subcategories are named after WikiProjects." Until the project changes name there's no need to include this change (nor to move the category) in the workflow from the RM - is there? Cabayi (talk) 12:28, 13 August 2017 (UTC)

MinervaNeue skin

Hi, like this new skin, big improvement but there is an issue with editing. When you click "edit" it tends to ignore the lede and go to sections lower down. I would rather just a simple "Edit" button and you can access the whole article at the top. Can this be fixed?♦ Dr. Blofeld 08:02, 13 August 2017 (UTC)

@Dr. Blofeld: Feel free to create a ticket in Wikimedia Phabricator by following the instructions How to report a bug. This is to make developers of the software aware of your request. Thanks. --AKlapper (WMF) (talk) 14:53, 13 August 2017 (UTC)

template:Archive-top on mobile

When viewed using the internet browser on my Android phone, the {{archive-top}} templates, at least as used at WP:ITN/C, are showing several screens worth of blank space between the horizontal line under the header and closure summary box and the start of the included text. I haven't time atm to investigate whether it is just this template or other similar ones and/or if it is idiosyncratic to that page. Awkward42 (talk) [the alternate account of Thryduulf (talk)] 11:44, 13 August 2017 (UTC)

It looks like what's happening there is that the skin sets overflow:auto on all <dd> and sets class quotebox to auto-width (and also sets word-wrap:break-word at a high level). So when the browser (at least desktop Firefox 52.2.0) tries to lay out the <dd> containing the "The following discussion is closed" and so on next to the floated quotebox with the close reason, it winds up making it 0 width and breaks the line between every letter. Anomie 12:28, 13 August 2017 (UTC)
Is that fixable? Thryduulf (talk) 19:33, 13 August 2017 (UTC)
Many things are possible, but they often have side effects. Here, it would likely break phab:T160946 again.. Hard calls. —TheDJ (talkcontribs) 03:10, 19 August 2017 (UTC)

Wanted pages almost broken

Special:WantedPages is somehow not matching up with my expectations of the 'New Page' box at the top of my contributions page, it is never updated and should link to the help pages on how to create an article. A Guy into Books (talk) 14:20, 13 August 2017 (UTC)

The button saying New page at top of your own contributions is made by enabling "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. Linking to Special:WantedPages seems a bit odd. There are other ways to get there and users following those ways may not have the same expectation as you but you have a point. The top of Special:WantedPages displays MediaWiki:Wantedpages-summary which is currently just a MediaWiki default. We could customize it to include links to help and process pages at the English Wikipedia. By the way, Special:WantedPages is pretty useless at the English Wikipedia because the highly redlinked mainspace pages are mainly pages which happen to be in WikiProject to-do lists with many transclusions, e.g. HaRav Moshe Nehemia Cohenov in Wikipedia:WikiProject Israel/to do2. It has 0 links from mainspace but around 19,600 from talk pages transcluding {{WikiProject Israel}}. PrimeHunter (talk) 15:24, 13 August 2017 (UTC)
We have Wikipedia:Most-wanted articles, but that list hasn't been updated since May 2016. Thryduulf (talk) 19:36, 13 August 2017 (UTC)
I have added the below to MediaWiki:Wantedpages-summary. PrimeHunter (talk) 11:15, 14 August 2017 (UTC)

Moving to commons

Can someone please help in moving these files to commons? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:00, 14 August 2017 (UTC)

@Capankajsmilyo: You can do it yourself using one of these. Jc86035 (talk) 14:37, 14 August 2017 (UTC)
That is a complex process. I don't want to break anything. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:07, 14 August 2017 (UTC)
This is a Wiki that anyone can edit. If you 'break' something, then I'm sure someone else will see it and fix it :) -FASTILY 06:06, 16 August 2017 (UTC)

You can't "page back" from a random article

Perhaps this is a Safari thing, but while poking about the Wiki using Random article (which demonstrates the Wiki to consist largely of gazetteer entries and obscure one-season sports players) I found that hitting the "back" button did not, in fact, return me to the last article, but the first one it served up, a disambig page for Petts. This seems wrong. Maury Markowitz (talk) 10:37, 14 August 2017 (UTC)

It works for me in Firefox, Microsoft Edge, Internet Explorer and Google Chrome. PrimeHunter (talk) 11:03, 14 August 2017 (UTC)
If you have a setting which causes a new window or tab to open when clicking links, this could be the reason. It also works for me, although I don't have Safari to test. —PaleoNeonate – 11:16, 14 August 2017 (UTC)
Known problem with some browsers. —TheDJ (talkcontribs) 13:20, 14 August 2017 (UTC)

Advanced search parameters

I want to search for articles that come within the scope of WikiProject Medicine in the hidden category Category:All articles to be merged. There are several thousand articles in that category, so is there a search parameter or tool that will allow me to filter those out more easily? Regards CV9933 (talk) 15:16, 14 August 2017 (UTC)

To get a cross section including categorization from talk pages, you need to use WP:Petscan. --Izno (talk) 15:46, 14 August 2017 (UTC)
This link is to the correct query, if I'm not mistaken. עוד מישהו Od Mishehu 17:36, 14 August 2017 (UTC)
Thank you both for providing the above information, running the query was a very useful way of letting me know which box I wasn't ticking. Cheers. CV9933 (talk) 19:38, 14 August 2017 (UTC)

Tech News: 2017-33

23:28, 14 August 2017 (UTC)

Category:Renault vehicles

There are two problems at Category:Renault vehicles. The first is simple: the page (last edited in May 2014) is broken—click edit then preview to see what it should look like. Please don't purge the page until others have had a chance to see a new kind of problem, namely that templates can be broken by some underlying system glitch, probably related to T170039. The second problem concerns unraveling the history. Why does a category have a navbox, and why does the page have a history showing edits over a ten-year period? Is the page the inadvertent result of a move to the wrong namespace? Johnuniq (talk) 11:00, 15 August 2017 (UTC)

The edit history looks OK to me - most of it is the gradual addition (and then final removal) of interwiki links, plus various tweaks to the categories. DH85868993 (talk) 12:01, 15 August 2017 (UTC)
There's no reason a category can't have a navbox. It is not typical--I've been thinking it should be, but that's a discussion for another forum. Either the template needs to be fixed (this is simply due to someone missing some brackets somewhere in the template) and then the category page purged, or the category page simply purged if the template has already been fixed. --Izno (talk) 12:40, 15 August 2017 (UTC)
Yes, this edit from a few days ago broke the template. It has since been fixed; we are just waiting for the job queue to catch up. --Izno (talk) 12:41, 15 August 2017 (UTC)
The template now appears correctly in the category. DH85868993 (talk) 22:49, 15 August 2017 (UTC)
Thanks, I missed seeing that diff, and I have got a bit paranoid after seeing a handful of weird issues while checking articles with script errors. Johnuniq (talk) 22:50, 15 August 2017 (UTC)

Automated creation of thematic world maps

Some time ago, I found GunnMap, a pretty interesting tool that allows the creation of thematic world maps directly from an excel file (e. g. File:World Map of Price Levels 2015.svg). But the tool is somewhat inflexible, as the colors cannot be chosen manually. Now I had the idea that such a tool could be developed for WP porposes, as editable basic maps like File:World location map (W3).svg do already exist. Since I do not having any programming skills: Is that an idea that could be possible realized?--Antemister (talk) 12:55, 15 August 2017 (UTC)

Yes, it is possible. But there are many places where one can create maps like those, and creating one for Wikipedia specifically is not necessary as long as there is a tool that uses a worldmap that has a license that is compatible to our licenses.
https://developers.google.com/chart/interactive/docs/gallery/geochart
https://developers.google.com/chart/interactive/docs/gallery/intensitymap
(((The Quixotic Potato))) (talk) 20:55, 15 August 2017 (UTC)
You might also be interested in what can be done with the Graphs extension. Ckoerner (talk) 00:09, 16 August 2017 (UTC)
I did not know that something like this already exists here, I'll ask the guys from the Graphs extension!--Antemister (talk) 17:57, 16 August 2017 (UTC)

Discrepancy between count of pages in a category and actual number of pages

Apologies if this has been covered before. I did a half-hearted search but didn't find anything.

On some maintenance categories, there is an inconsistency in the page count message when compared with the actual number of pages in the category, even when taking into account the delayed update. For example, a category might tell me "The following 200 pages are in this category, out of 209 total." (looking at you, Category:Wikipedia articles incorporating text from the Schaff-Herzog), yet when you page through after the first 200 entries, it says "The following 14 pages are in this category, out of 209 total." and indeed there are 214 total pages listed in the category. One page is in non-main space, which isn't enough to account for the discrepancy.

At this time, I can see the same effect in Category:Wikipedia articles incorporating a citation from the 1911 Encyclopaedia Britannica without Wikisource reference (641 in the message, but 97 displayed on the 4th page); Category:Wikipedia articles incorporating text from Easton's Bible Dictionary (322 in the message, 326 displayed).

I suspect, and in one case I know, that the affected categories have had articles added to them recently. But even accounting for a possible delayed update, resulting maybe in the total count coming from a different database table than the list itself, shouldn't the "page count" message reflect the count of pages being actually displayed? If not, it damages credibility. Or change the message to say "out of 209 or more total." David Brooks (talk) 00:25, 16 August 2017 (UTC)

I have removed the none main name-space entry for the Schaff-Herzog category as it was accidental added by me some years ago -- PBS (talk) 08:05, 16 August 2017 (UTC)
This is behavior that has existed for a long time. My understanding is that it is related to the job queue, and also in a larger way to T132467, T157670, or both. The short version of those bugs is that it takes way too long for categories to catch up when something changes that affects them.
My rudimentary understanding is that MediaWiki maintains a category member count, which may not be correct, and it increments or decrements that count by the correct number as pages are added or removed, but the number will remain incorrect. My personal experience has been that the category count on the category page becomes trustworthy only after the category membership drops below 200.
I could be wrong about any or all of this, but that has been my experience over the last few years of editing. (Edited to add: T18036 appears to be the canonical ticket for this problem.) – Jonesey95 (talk) 01:13, 16 August 2017 (UTC)
The message is made by MediaWiki:Category-article-count. If a discrepancy is common and it can go both ways then we could change "out of $2 total" to "out of around $2 total". If it's only an issue for more than 200 pages then we could add "around" in that case: out of {{#ifexpr:{{formatnum:$2|R}}>200|around}} $2 total. PrimeHunter (talk) 10:30, 16 August 2017 (UTC)
I think it would be great to be honest about this eight-year old bug. I would love to see "out of approximately NNN" ("approximately" seems less jargon-y to me than "around") in category lists. Whoever edits that MediaWiki page could add a hidden comment or a note on the corresponding talk page pointing to T18036. Thanks. – Jonesey95 (talk) 15:10, 16 August 2017 (UTC)
Can anyone confirm whether the proposed trigger of 200 articles is coincidentally the same as the display chunk size, or if it is directly related in some way? For example, I would find it believable that a one-page display would count its contents directly while the first of a multi-page display would have to use the (sometimes incorrect) category count. David Brooks (talk) 18:18, 16 August 2017 (UTC)
It's directly related. When viewing the category without using the 'from' or 'until' parameters, if there are fewer than the display chunk size pages shown in the view then MediaWiki can easily check that the stored count is correct or not (and if not, it can trigger an update in the expectation that it'll be cheap to do so). Anomie 19:01, 17 August 2017 (UTC)
ETA: I realize that's exactly what happens. "The following n pages are in this category" is correct; it's "out of n total" that's often wrong. Perhaps the solution, until and unless the database error is fixed, is to do something like the History display, with a set of next/prev/first links. Or is the database bug rare enough that this would be overkill? David Brooks (talk) 18:53, 16 August 2017 (UTC)
What do you mean by next/prev/first links? There are already "next page" when you are not on the last page, "previous page" when you are not on the first page, and clicking the "Category" tab jumps to the first page. Do you mean not displaying a count at all, like history pages? We could omit the count in MediaWiki:Category-article-count but I oppose that as long as the count is not wildly off most of the time. PrimeHunter (talk) 20:20, 16 August 2017 (UTC)
Well, yes, that's what I meant, and I guess I was mistaking form for function. "Next 200" might be an alternative label, but that's confusing on the penultimate page (also true of History). And, as you imply, the effort may not be justified if (a) I'm the only one making a fuss or (b) as you imply, the count is right most of the time. Can the fraction of seriously-wrong counts be measured?. David Brooks (talk) 22:38, 16 August 2017 (UTC)
In my experience, the count is almost always wrong (although usually approximately close, within a few percent) unless the count is below 200. I think that adding the word "approximately" would be far better than omitting the total altogether. As for the "next 200" discussion above, I don't understand how that would be better than the existing "next page" link that exists at the bottom of each populated page in the category. And as for a "first" link (or any other place within the category), that is what the TOC templates are for. What am I missing? – Jonesey95 (talk) 00:57, 17 August 2017 (UTC)
You're not missing anything; I was being overly precise in my comparison with the History listing. David Brooks (talk) 01:16, 17 August 2017 (UTC)
I have added "approximately" to MediaWiki:Category-article-count for totals above 200. PrimeHunter (talk) 09:50, 17 August 2017 (UTC)

Wikipedia:WikiProject Women in Red/The World Contest

I need somebody to code a bot to run this contest. Wikipedia:ContestBot would be an ideal name. It will need to read article prose length when submitted and check there are no unsourced paragraphs. I will pay for the work if you want it.♦ Dr. Blofeld 09:15, 16 August 2017 (UTC)

Thanks. I'll need something which can tick or cross entries as they're submitted on the contest pages though, prose count for the contest is important.♦ Dr. Blofeld 18:52, 16 August 2017 (UTC)

Who here has wmflabs access

User:Citation Bot has had major code updates in the pipeline for a long while, but they've never been deployed because the updates (github link) never get deployed to wmflabs.

How can we make them happen? Headbomb {t · c · p · b} 11:07, 16 August 2017 (UTC)

Smith609, Kaldari, Fhocutt, and Maximilianklein are the listed maintainers. — JJMC89(T·C) 14:14, 16 August 2017 (UTC)
Gonna ping the noping'd ones. @Kaldari:, @Fhocutt:, and @Maximilianklein:. Smith609 hasn't been active, if he were, the updates would have gone live years ago. Headbomb {t · c · p · b} 15:50, 16 August 2017 (UTC)
@Headbomb: The actual live code lives in the "citations" tool, which I don't have access too. None of the maintainers of that tool are still active on Wikipedia, though :( Kaldari (talk) 17:48, 16 August 2017 (UTC)
@Kaldari: - As a "solution", could the current citations tools be taken down/disabled, and new ones be uploaded instead. I don't mean uploading over the existing ones, but rather something like creating a User:Citation Bot 2, blocking User:Citation Bot, and pointing all scripts/gadgets/whatever towards the new code rather than the old one? Headbomb {t · c · p · b} 01:16, 17 August 2017 (UTC)
If you can let me know how to pull the necessary code updates, I'm happy to do it. Afraid I haven't the time to remind myself of the process. Drop me an e-mail. Martin (Smith609 – Talk) 09:23, 17 August 2017 (UTC)

AWB subrules

I am having trouble figuring out how the advanced find/replace rules in AutoWikiBrowser work. I have nested some regex rules (if rule 1 then (if rule 2 then (rules 3–5))), but the subrules are run regardless of whether or not their parent rules are actioned upon. Is this a bug, or am I doing this wrong? Are the rules for the entire tree ignored if there is a match in the "Not contains" panel, or does it do something else? Jc86035 (talk) 14:40, 16 August 2017 (UTC)

@Jc86035: You should ask @Magioladitis: (I have pinged him). (((The Quixotic Potato))) (talk) 23:49, 17 August 2017 (UTC)

Jc86035 It is highly possible that the Advanced F&R is broken. Reedy what do you thing? -- Magioladitis (talk) 17:02, 18 August 2017 (UTC)

Gadgets

What MediaWiki/Module is resposinble for showing the gadgets section from the preferences? I would like to see the source codes. ◂ ‎épine talk 17:49, 16 August 2017 (UTC)

I'm not sure what you want. https://en.wikipedia.org/wiki/Special:Preferences?uselang=qqx#mw-prefsection-gadgets shows the names of the displayed MediaWiki messages. For example, "(gadgets-prefstext)" at the top means that MediaWiki:Gadgets-prefstext is displayed there. The message for the English Wikipedia can be edited there. MediaWiki:Gadgets-definition defines the gadgets used by the English Wikipedia. Special:Gadgets has links to the JavaScript and CSS pages. PrimeHunter (talk) 18:30, 16 August 2017 (UTC)
I think he's asking about mediawikiwiki:Extension:Gadgets. --Izno (talk) 19:22, 16 August 2017 (UTC)
@PrimeHunter: thanks, that's exactly what I wanted. ◂ ‎épine talk 15:59, 17 August 2017 (UTC)

Is it just me?

Hi,

I'm having a problem with editing pages. Sometimes, things such as the editor buttons and Twinkle simply do not load. When they do not, I have to keep refreshing until they do. I could not find any other mention of this problem in recent threads. I'm using Firefox 55.0.2 64-bit (Windows 10), but this was also happening with older versions. Is this a problem with Wikipedia, or is there an issue with my connexion? It's worth noting that I had a look at Firefox's Web Console, and in the cases when they do not load, I get a "TypeError: mw.util is undefined" message for index.php:329:3 that I do not get when it does load. The problem happened to me when I went to type this thread, and I got the same message (that said, it happened again when I tried to preview, and I did not get that message, so who knows?). I have tried cleaning my browser's cache. Does anyone else have this problem, because it is getting rather annoying. It sometimes hinders anti-vandalism work, as I sometimes cannot warn vandals and report them to AIV because I have to fight with the system just to be able to do so. Thanks. Adam9007 (talk) 23:10, 16 August 2017 (UTC)

@Adam9007: It's not you. It's Firefox, and it's been going on at least since the previous release a month or so ago. Straight across the board on Wikimedia. Firefox is not compatible with everything in the editing window. I do the same thing you do. — Maile (talk) 23:20, 16 August 2017 (UTC)
@Maile66: Is there no workaround? I'd hate to have to switch browser because of this. Adam9007 (talk) 23:28, 16 August 2017 (UTC)
I haven't read about a workaround. I use Firefox. You should try it on WikiSource, repeated refreshing of the page combined with repeated clicking on "Preview", to get all the tools to load. I like Firefox and don't want to switch at this time. But Firefox and Wikimedia are not currently compatible. — Maile (talk) 23:33, 16 August 2017 (UTC)
@Maile66: Has this problem been reported somewhere? Adam9007 (talk) 23:49, 16 August 2017 (UTC)
I don't know if the problem I came to report is exactly the same, but it's similar enough. Along with Twinkle, many of the helper scripts that I regularly use (including WP:POPUPS for example) are not loading, and it's becoming more often than not. But I'm on Chrome in Win10. Any ideas? Ivanvector (Talk/Edits) 23:53, 16 August 2017 (UTC)
@Adam9007: 1, 2 a couple of times this has been reported. — Maile (talk) 23:59, 16 August 2017 (UTC)
Actually, this problem sounds like one that can be fixed--it sounds like one of your user scripts/gadgets is not declaring its dependency on mw.util. Which gadgets are you using? (Cc TheDJ, the prognosticator of scripts.) --Izno (talk) 23:54, 16 August 2017 (UTC)
@Izno: I'm using (under "Editing"): "Add two new dropdown boxes below the edit summary box with some useful default summaries", Citation Expander, Syntax highlighter, HotCat, "Form for filing disputes at the dispute resolution noticeboard" (what's this anyway? I never use it), CharInsert (which also doesn't load when the buttons and Twinkle don't), refToolbar, and "Add extra buttons to the old (non-enhanced) editing toolbar". Adam9007 (talk) 00:02, 17 August 2017 (UTC)
You could try blanking User:Adam9007/common.js. PrimeHunter (talk) 00:15, 17 August 2017 (UTC)
@PrimeHunter: Nope, didn't work Face-sad.svg. I also still get the "TypeError: mw.util is undefined" message. What is of interest is that I also get messages like "This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead." Maybe this has something to do with the problem? Adam9007 (talk) 00:34, 17 August 2017 (UTC)
per my userpage, im on the road atm, so i cannot debug a persons scripts right now. Blanking everything, and then waiting for the cache to expire is the guaranteed way out. —TheDJ (talkcontribs) 14:52, 17 August 2017 (UTC)
I want to note that I usually encounter this issue with Safari as well. I mostly have this issue with the summary sections.◂ ‎épine talk 16:04, 17 August 2017 (UTC)

Adam9007: User:Adam9007/common.js is importing User:Ohconfucius/script/EngvarB.js, which in turn imports m:User:Pathoschild/Scripts/Regex menu framework.js, and that script uses mw.util.addCSS, but nowhere in this chain of script importing is the ResourceLoader module mediawiki.util loaded. If you wrap your entire common.js like this:

mw.loader.using( 'mediawiki.util', function() {
	//Just put your entire common.js inside here
} );

it should work, or at least give you another error. Face-smile.svg Nirmos (talk) 16:08, 17 August 2017 (UTC)

@Nirmos: I'll try that, but I'm not sure that'll help: I just had two instances of the editor of that page open. One loaded correctly, the other did not. There was no difference in errors between them except the one that loaded correctly had an additional message: "Automatically scrolling cursor into view after selection change this will be disabled in the next version set editor.$blockScrolling = Infinity to disable this message". Also, by "editor buttons", I meant the toolbars, not the save, preview, and show changes buttons. Adam9007 (talk) 22:09, 17 August 2017 (UTC)
Latest version of Chrome, Win 10, sometimes Twinkle loads, sometimes it doesn't. Doug Weller talk 10:16, 20 August 2017 (UTC)

Requesting OCR help at mr.wikisource

Hi,

At Marathi language mr.wikisource we have planned a student workshop tomorrow. We are looking for unicodification support from people using linux operating system. Since our usual voluntters to are not around.

  • Steps
    • Step 1: Download & install OCR4Wikisoource
    • Step 2: Google API
    • Step 3: API Enable
    • step 4: Change file config.ini fill URL link of the book to be OCRed then wikisource log in and pass word.
    • Step 5: use OCR4wikisource

Thanks & Regards

Mahitgar (talk) 07:57, 17 August 2017 (UTC)

Problems with my user rights.

Hi, I have auto confirmed status then even I am not able to edit most semi-protected pages. I have had a discussion over this with MusikAnimal and he only suggested me to seek help here. Bingobro(Chat) 11:01, 17 August 2017 (UTC)

Are you sure that they are semi-protected and not extended-confirmed protected articles? The latter require the extended-confirmed group, which is automatically added after 500 edits and a minimum of 30 days. Maybe that specifying the name of the semi-protected article you cannot edit would be a good idea. It's also possible that an edit filter issue prevents your edits, but the only event that I can see is Special:AbuseLog/18906070 which was an article creation attempt without references. Thanks, —PaleoNeonate – 12:46, 17 August 2017 (UTC)
@Bingobro: I saw some of your posts on the other pages, and it is unusual. A few questions: have you tried editing from a different computer? Have you made any edits from tor? — xaosflux Talk 12:49, 17 August 2017 (UTC)
Possibly related to phab:T136044. Would you be able to share the operating system and browser you are using? — xaosflux Talk 12:50, 17 August 2017 (UTC)
Yup, Cars is a semi-protected page and as for the article I created I did provide references although they may not have been considered valuable.And for tor , the only browsers I have installed are Chrome and Internet Explore and my OS is Windows 8.1.And I doubt my pc's specs could be a problem? Bingobro(Chat) 13:50, 17 August 2017 (UTC)
Permalink to the discussion on my talk page (and at WP:PERM/C), for reference. I agree with Xaosflux – let's try editing from a different computer. If it still doesn't work, while you are logged in, please create a new account at Special:CreateAccount. This will show up as an account created by Bingobro, which we can then manually confirm. If with the new account you find you are able to edit these semi-protected pages, we can isolate the issue to some weirdness with the Bingobro account, and rule out your browser and operating system MusikAnimal talk 16:13, 17 August 2017 (UTC)
Wait, wait.. Wont creating a new account loose all my contributions i.e. around 200+ and my media from commons.I thought I soon would have an extended confirmed account but creating a new account I'll have to start all over again! And if you guys wont to try out the confirmed flag again, I'd suugest to do it with this account. Bingobro(Chat) 10:47, 18 August 2017 (UTC)
Hello, anyone here? My problems aren't yet fixed so, somebody can perhaps still help. Thank you! Bingobro(Chat) 15:22, 19 August 2017 (UTC)
@Bingobro: have you tried using a different computer yet to rule that out? — xaosflux Talk 16:36, 19 August 2017 (UTC)
@Xaosflux: Sorry, forgot to metion that. Yup, I have tried it out and no help. Bingobro(Chat) 16:52, 19 August 2017 (UTC)
@Bingobro: When MusikAnimal (talk · contribs) suggested that you create a new account, this wasn't with the intention that you use it in future and abandon your present account - the idea is to see if an account which is uncustomised, and so still has the default settings, is having the same trouble. If it is not having such trouble, we consider the customisation that has been applied to your main account; for example, you might have enabled two gadgets that are not happy together. For this reason, I created Redrose64a (talk · contribs) some years ago, where I have not altered any of the configuration settings; and to make sure that I have all of the current defaults, I periodically use the "Restore all default settings (in all sections)" feature at Preferences (n.b., if you have any Custom CSS / Custom JavaScript pages (see Preferences → Appearance), this will not alter or disable anything set up in those). If I have trouble with my main account, I try out Redrose64a and if the trouble is gone, I know that it's a settings issue. Such additional accounts are permitted under WP:VALIDALT. --Redrose64 🌹 (talk) 09:23, 20 August 2017 (UTC)

@Redrose64: Well, I have created the account User:BingobroA but its still 4 days till I know whether it worked or not.Bingobro(Chat) 13:30, 20 August 2017 (UTC)

Dropping support for Internet Explorer 8 on Windows XP

As announced several times, Ops is dropping all support for Internet Explorer 8 on Windows XP (and a few other, even rarer, combinations), for privacy and security reasons. "All support" means that if you are using an affected web browser, you will not be able to either read or edit pages.

Sometime today, affected browsers will start getting an error message on 5% of page views. Reloading the page will (95% of the time) get you to the article. But support is going away, and the number of errors will increase steadily until it reaches 100% in approximately two months or so, so please change browsers as soon as you can. Whatamidoing (WMF) (talk) 17:50, 17 August 2017 (UTC)

Sort of the iron fist in the velvet glove. EEng 17:54, 17 August 2017 (UTC)
Google.com works for me with IE6 (with a better dense interface). Anyway, can we link to www.getfirefox.com or use call-to-action buttons (Buy Windows 10 for US$ 99)? — Dispenser 18:06, 17 August 2017 (UTC)
IE8? I have thought that only IE10+ are officially supported as of now? Ruslik_Zero 18:48, 17 August 2017 (UTC)
IE under 10 doesn't receive JavaScript. Here, we're talking about removing the ability to connect to Wikipedia for even older stuff. Max Semenik (talk) 18:51, 17 August 2017 (UTC)
There will be a link to download Firefox 52 ESR. /Johan (WMF) (talk) 19:45, 17 August 2017 (UTC)
This will affect roughly 0,1% of our traffic, by the way. /Johan (WMF) (talk) 19:48, 17 August 2017 (UTC)
You're violating our Manual of Style by using comma as the decimal separator. You WMF guys think rules don't apply to you.[FBDB] EEng 19:56, 17 August 2017 (UTC)
Nah, he's just showing off his non-English language skills. Someday, I'm going to fill his userpage with Babel boxes.  ;-) Whatamidoing (WMF) (talk) 20:16, 17 August 2017 (UTC)
A day may come when I learn to pause and think about which language I'm writing in when I come to the decimal separators. But it is, apparently, not this day.
(1,000.67 is written 1.000,67 in my native language. This is seriously one of the most confusing aspects of switching back and forth between languages.) /Johan (WMF) (talk) 21:51, 17 August 2017 (UTC)
@Johan (WMF): You work for the WMF and in the weekends you make extra money as a Kane impersonator? (((The Quixotic Potato))) (talk) 23:45, 17 August 2017 (UTC)

Template namespace shortcut

Why is it that t: works as a shortcut in English Wiktionary but not Wikipedia? This small change could save a whole lot of time. Pariah24 (talk) 19:31, 17 August 2017 (UTC)

Because editors disagree about whether T: should be Template: or Talk:. There's no technical impediment. Whatamidoing (WMF) (talk) 20:17, 17 August 2017 (UTC)
See also Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. Anomie 04:02, 18 August 2017 (UTC)
It works in English Wiktionary because mw:Manual:$wgNamespaceAliases is used to add it in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php:
# wgNamespaceAliases @{
'wgNamespaceAliases' => [
...
        '+enwiktionary' => [
                'WS' => 110, // Wikisaurus
                'WT' => NS_PROJECT,
                'CAT' => NS_CATEGORY, // T123187
                'T' => NS_TEMPLATE, // T123187
                'MOD' => 828, // T123187
                'AP' => 100, // T123187
                'RC' => 118, // T123187
        ],

// T123187 is a comment indicating it was requested in phab:T123187 which links to wikt:Wiktionary:Votes/2015-11/Namespace abbreviations. PrimeHunter (talk) 17:34, 18 August 2017 (UTC)

Cite magazine

Dear editors: I edit a lot of music articles, so I often reference Billboard Magazine. There are four Cite templates on the drop down list in the edit window: web, news, book and journal. Since "Cite journal" is the closest, I have been using that. While attending a session at Wikimania, I learned that there is also a "Cite magazine", and that using the journal template for magazines can cause categorization problems. Is it possible to add "Cite magazine" to the drop-down menu?—Anne Delong (talk) 19:47, 17 August 2017 (UTC)

Categorization problems? How so? {{cite journal}} and {{cite magazine}} are essentially the same except in how they render volume, issue and pagination:
{{cite journal |title=Article title |journal =Journal |volume=1 |issue=2 |page=3}}
"Article title". Journal. 1 (2): 3. 
{{cite magazine |title=Article title |magazine=Magazine |volume=1 |issue=2 |page=3}}
"Article title". Magazine. Vol. 1 no. 2. p. 3. 
The rendering engine Module:Citation/CS1 does not categorize according to the type of cs1 template used. Perhaps you can explain what it is that you mean by categorization problems.
Trappist the monk (talk) 19:58, 17 August 2017 (UTC)
There's a gadget somewhere (found it Wikipedia:RefToolbar!) that has a default list of templates to use: Cite web, cite news, cite book, cite journal. The request is to add cite magazine to that list. Headbomb {t · c · p · b} 20:12, 17 August 2017 (UTC)
There's possibly MW:Citoid as well, which has a json mapping (MW:Citoid/MediaWiki:Citoid-template-type-map.json). I tried leaving a message over there to update "magazineArticle": "Cite news"," to "magazineArticle": "Cite magazine",", but the talk page is weird, and I'm not dealing with figuring out how to use that interface. Looking at the json map, some other entries could be updated as well. We have {{cite thesis}}, {{cite patent}}, {{cite dictionary}} that could be used, and {{cite arxiv}}/{{cite biorxiv}} that should be added to cite arxiv/biorxiv preprintsHeadbomb {t · c · p · b} 20:16, 17 August 2017 (UTC)
MediaWiki_talk:Citoid? EEng 20:20, 17 August 2017 (UTC)
Just click in the white box at the top, where it says "Start a new topic". It will likely all make sense after that. However, Anne doesn't seem to be using VisualEditor, so the citoid service isn't immediately related to her request.
(I am also curious about the claim that problems are created by using the "wrong" template.) Whatamidoing (WMF) (talk) 20:22, 17 August 2017 (UTC)
It is possible that by that she means such citations get picked up by WP:JCW/POP, or just makes people think Billboard is a journal, rather than a magazine. I'll let Anne Delong (talk · contribs) speak for themselves, however. Headbomb {t · c · p · b} 20:38, 17 August 2017 (UTC)
Sorry, I was away from my computer. The presenter whose talk I attended ([15]) was using an algorithm to harvest and analyze journal citations from Wikipedia articles, creating statistical information about which academic journals were being cited with what frequency by articles in which categories, etc. He was using this information to find and fill gaps in Wikipedia's coverage of notable journals. Billboard kept coming up on his list of journal citations, much to his annoyance (I sat quietly embarrassed in the audience and said nothing....) He was categorizing references, rather than articles, so the categorization problem was indirect, but still, I was cluttering his dataset by using the wrong template. It appears I can just change the word "journal" to "magazine" after the citation is rendered, but I thought if it wasn't too much work for the tech people to add one more item to the citation template list, it would be helpful to others who add magazine references as well as to me. There are a LOT of citations to magazines. I could also just cite the magazine directly without using the Cite template, but several talks at Wikimania have convinced me of the value of structured data.—Anne Delong (talk) 21:57, 17 August 2017 (UTC)
We could rename it {{cite periodical}}, to reduce the belief that "journal" means "academic publication", but then we'll have people using that template for newspapers (which are also periodicals). WhatamIdoing (talk) 23:36, 17 August 2017 (UTC)
Glad you attended my talk Anne! A few things, most of the issue comes from way back, when {{cite magazine}} redirected to {{cite journal}} and were rendered the same. That changed a few years ago, but as far as the project is concerned, misuse of the templates concerning magazines vs journals really isn't that big of a deal. Sure it might be a cleaner dataset when excluding the magazines, and it might be nice to have a "Magazines Cited by Wikipedia" compilation (I think I'll ask J-LaTondre to build one in fact, because why not?), but it doesn't really affect our work as far as categorization/article creation goes.
It causes issues when you try to do what I did and try to find some patterns in the data, or do original research like I did, but short of that, it's not a critical difference. There are actually some benefits, as magazines that make their way on the list get more attention.
Best practice would be to use the correct {{cite magazine}}, but it's not horrifyingly horrible to use {{cite journal}}. Cheers! Headbomb {t · c · p · b} 01:06, 18 August 2017 (UTC)
Okay, thanks for listening.... I will use the magazine template by adding it manually.—Anne Delong (talk) 03:33, 18 August 2017 (UTC)

When closing a picture (in Media Viewer), it doesn't return to original scroll position (regression, Chrome only)

Repro:

  1. Open https://en.wikipedia.org/wiki/Battle_of_Long_Tan#Battle
  2. Click on the image on the right
  3. Close Media Viewer by "X" or Esc

What happened: it scrolls all the way to top instead of staying at your original position. Chrome only, tested with Version 61.0.3163.49 (Official Build) beta (64-bit) and 62.0.3188.0(Official Build)canary.--fireattack (talk) 07:11, 18 August 2017 (UTC)

Don't worry you can disable that horrible thing by going into your user preferences, clicking on the "Appearance" tab and unchecking "Enable Media Viewer". Then click Save. (((The Quixotic Potato))) (talk) 09:08, 18 August 2017 (UTC)
I cannot reproduce the problem using Chromium 59. Scroll position remains correct. Have you reported a bug to the Chrome developers? --Malyacko (talk) 11:57, 18 August 2017 (UTC)
Just did: https://bugs.chromium.org/p/chromium/issues/detail?id=756868 seems like a regression caused by a change in ver. 61 -fireattack (talk) 17:30, 18 August 2017 (UTC)

JPG missing content when thumbnailed

Something is up with File:Stonehenge Q&R.jpg - at full size (and some thumbnail sizes) it has overlaid key text and stone locations marked (eg. [16]), but at other thumbnail sizes, including the one used in the Q and R Holes article, it just shows the grey background blocks (eg. [17]). What's happening here? --Gapfall (talk) 10:51, 18 August 2017 (UTC)

That image, as well as the others uploaded by that user, have the hallmarks of not actually being free images. New user, claims they are his images, clearly zoomed-in on some page or another. The question might be somewhat moot. --Izno (talk) 13:12, 18 August 2017 (UTC)

Template:la and wikisyntax

Can someone who knows templates check this template (and others with the same code)? Currently article titles starting with * cannot be parsed by the template, creating code like this: [[:

Regards SoWhy 12:29, 18 August 2017 (UTC)

That appears to be the very old bug T14974. Anomie 15:01, 18 August 2017 (UTC)
Per Help:Template#Problems and workarounds, you can replace * with &#42; in the call:

* (edit | talk | history | protect | delete | links | watch | logs | views)

PrimeHunter (talk) 17:20, 18 August 2017 (UTC)
or use  * (edit | talk | history | protect | delete | links | watch | logs | views), not the best solution, but seems to generally work. Frietjes (talk) 17:21, 18 August 2017 (UTC)
I have made {{Encodefirst}} as a general workaround which can also be used in templates without the caller having to do anything. {{la|{{Encodefirst|*}}}} produces:

* (edit | talk | history | protect | delete | links | watch | logs | views)

If {{Encodefirst}} were used in two places in {{la}} then {{la|*}} would also work. Should we start thinking about complicating some templates by using {{Encodefirst}} or something similar to work around this issue? PrimeHunter (talk) 20:48, 19 August 2017 (UTC)
Please don't add more internal complexity to {{la}}, it was a series of "enhancements" (by Technical 13) to that and related templates that caused a large number of XFD listings to fall over with WP:TLIMIT problems back in 2013-14. --Redrose64 🌹 (talk) 10:24, 20 August 2017 (UTC)

New feature: LoginNotify

Hi everyone,

The Community Tech team has released a new security feature this week: LoginNotify, which gives you a notification when someone tries and fails to log in to your account. This project was wish #7 on the 2016 Community Wishlist Survey.

Here’s how it works:

If someone tries and fails to log in to your account from a device or an IP address that hasn’t logged into your account recently, then you’ll get an on-wiki notification at the first attempt. For a familiar device or IP address, you’ll get an on-wiki notification after 5 failed logins. This is on by default, but you can turn it off in your preferences; you can also turn on email notifications.

It’s also possible to turn on email notifications when there’s a successful login from a new device or IP address. This is turned off by default, but it might be useful for admins or other functionaries who are concerned that their user rights could be misused. This means that you’ll get a notification every time you log in from a new device or IP address.

We want to take this opportunity to thank Brian Wolff for all of his work in writing the underlying extension for this feature.

There’s more information on the feature on the Community Tech project page on Meta, and please feel free to post questions on the talk page: Community Tech/LoginNotify

If you're also active on another wiki, please feel free to copy and share this information with your community.

PS: If you’re wondering what happened to the Syntax Highlighting beta feature that we deployed a couple weeks ago and then had to roll back: it’ll be back soon! -- DannyH (WMF) (talk) 23:19, 18 August 2017 (UTC)

Thanks, I will test it on my own MediaWiki install. (((The Quixotic Potato))) (talk) 23:36, 18 August 2017 (UTC)

Edit position lost on "Show preview"

When I am editing a page, click the "Show preview" button, than go back to the edit window my position is lost – the text now starts at the top again. I have to scroll back down to find the text I was changing. With "edit this page" on a large article it introduces a fair amount of scrolling. This is a new feature. Will it be fixed? Aymatth2 (talk) 22:23, 19 August 2017 (UTC)

Not broken in Firefox... Try fixing it with Preferences → Editing → Show previews without reloading the page, live preview.— Cpiral§Cpiral 04:59, 20 August 2017 (UTC)
  • @Cpiral: The editing preferences change fixes it with Chrome. For some reason the display momentarily fades before showing the preview, but edit position is not lost. Solved. Thanks, Aymatth2 (talk) 10:53, 20 August 2017 (UTC)
It does this in Opera, don't know if it's always been the case. --Redrose64 🌹 (talk) 09:24, 20 August 2017 (UTC)
  • @Redrose64: This just started a few days ago in Chrome. Cpiral's solution works - probably for Opera too. Aymatth2 (talk) 10:53, 20 August 2017 (UTC)

Wikimedia Commons watchlist problem

Hi, I've recently had a problem with my watchlist on Commons (elsewhere, everything is fine). It doesn't open, instead I get the following message:

  • "[WZlJ3gpAMFoAADyMDKwAAAAE] 2017-08-20 08:36:42: Fatal exception of type »Wikimedia\Rdbms\DBQueryError«"

Can anyone help here? Where should I report this?

Thanks in advance. --Eleassar my talk 08:39, 20 August 2017 (UTC)

@Eleassar: This may be related to #Watchlist changes above. How many pages are there on your watchlist (approximately)? At c:Special:Preferences#mw-prefsection-watchlist, what value do you have for "Maximum number of changes to show in watchlist"? --Redrose64 🌹 (talk) 09:29, 20 August 2017 (UTC)

There are about 90,000 pages on my watchlist. I don't exactly remember the maximum number of changes, but I would say it is 1,000. --Eleassar my talk 10:48, 20 August 2017 (UTC)

Yes, I've checked this up. Correct: there are 1,000 changes shown. --Eleassar my talk 10:53, 20 August 2017 (UTC)

It could be related to these changes. Anyway, at this moment, my watchlist does not work at all... Re work here, I find this rather urgent. In addition, I'm most probably not the only one with a non-functioning WL. --Eleassar my talk 11:32, 20 August 2017 (UTC)

There are others with huge watchlists at commons:Commons:Village pump#Filtered whatchlist causing Database error. PrimeHunter (talk) 12:21, 20 August 2017 (UTC)
Thanks. I'll report there. --Eleassar my talk 13:03, 20 August 2017 (UTC)

Proposals

Automatic column mode for references element

Recently it became possible for <references /> to automatically use responsive columns when there are more than 10 references in the generated list. Currently this behaviour is an opt-in mode (<references responsive="1"/>). The opt-in was intentional as throughout Wikimedia, we had many templates that already relied on pre-existing behaviour. Recently I prepared {{Reflist}}, to be able to deal with both situations. As such it would now be possible, to switch the default of <references />, without influencing {{Reflist}}. I think a default column mode is easier for most situations that do not require {{Reflist}} and I want to propose to switch the default of <references /> to automatic responsive columns. So to summarise:

  1. Currently <references /> never has columns
  2. When we switch the default, <references /> will have columns if there are more than 10 references (30em wide, same size as most Reflist usages).
  3. This switch of the default will not influence {{Reflist}}, which can be used for changing column width and a few more advanced features.
  4. It will be possible to disable these columns by using <references responsive="0" />.

If there is agreement, then we can file a phabricator bug report to make the change. —TheDJ (talkcontribs) 09:15, 13 July 2017 (UTC)

  • Yes please! --Izno (talk) 12:21, 13 July 2017 (UTC)
  • It would be great! --Jennica / talk 14:52, 13 July 2017 (UTC)
  • The change reduces the size of the text. This change was not mentioned in the description of this change. I prefer that the type size match the body of the article. Jc3s5h (talk) 15:39, 13 July 2017 (UTC)
    • @Jc3s5h: I'm not sure how you reached that conclusion, but I cannot confirm it. All references lists have a font-size of 90%. It has been like that since 2011 as far as I can tell. Can you please give examples, and information regarding the skin you use perhaps ?—TheDJ (talkcontribs) 15:55, 13 July 2017 (UTC)
      • When I tried to reproduce the problem, I realized the article I used as an example has several reference-related subheadings and I had been mixed up about which section I changed (in preview mode only, of course). Jc3s5h (talk) 16:12, 13 July 2017 (UTC)
  • I agree with this change. The columns seem to be just slightly too wide at the moment, but maybe this is deliberate. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    05:58, 14 July 2017 (UTC)
  • I support this change. There will no doubt be some minor unintended consequences and some necessary cleanup to a few articles, but that is the price of progress. – Jonesey95 (talk) 16:19, 14 July 2017 (UTC)
  • Mild oppose. Personally, I prefer the single column style, and think that the change to 2 column that is often made is rarely an improvement. Making it the default will mean this is done with little thought far too widely. If this is to be done, the threshold of 10 is much too low, 30 is about right, at the lowest. DES (talk)DESiegel Contribs 14:44, 15 July 2017 (UTC)
  • This sounds like a nice improvement. I support making it the default. Kaldari (talk) 18:40, 15 July 2017 (UTC)
  • I kind of oppose this. As {{reflist}} already does this, changing <references /> too would make creating a single column ref list needlessly complicated. DaßWölf 21:53, 15 July 2017 (UTC)
  • Oppose. Multiple columns are fine for simple citations, but make it difficult to read long explanatory footnotes. In considering whether to use columns, and of what width, our first consideration should be what makes things easiest for the reader. That has to be done on a case-by-case basis rather than according to an arbitrary standard based on the number of citations. Ammodramus (talk) 16:55, 16 July 2017 (UTC)
    • @Ammodramus: You consider the case of NOT having columns for lists larger than 10 items to be more common than having columns ? I think we should cater to the largest group of users and to 'safe' defaults. I think that if we can have 90% of the cases right and only need to modify 10%, then that is better than the reverse for the casual editor right ? —TheDJ (talkcontribs) 10:17, 17 July 2017 (UTC)
  • Would support if the proposal is limited to two columns only. Even long citations / quotes are reasonably easy to read if in a two-column format. Is that what's intended by the proposal. K.e.coffman (talk) 21:20, 16 July 2017 (UTC)
    • The columns of the responsive column mode of the references tag, are the same as the most common setting for {{Reflist}}: 30em. The amount of columns depends on the width of your screen. —TheDJ (talkcontribs) 12:01, 17 July 2017 (UTC)
  • Oppose Support because we already have this with {{Reflist|}}. Why re-invent the wheel? What are the benefits of having two paths to get to the same place? Also, with today's screen proportions trending towards wider screens, three ref columns are being used more and more; so if this change were to take place, that capability should be available as well. I'd still oppose this, however, for the same reason as above. It's not a needed universal change, and we already have the way to do it. GenQuest "Talk to Me" 11:16, 17 July 2017 (UTC)
    • I see several errors in reasoning here. (1) The wheel is already reinvented, it just needs turning on. Our {{reflist}}'s multi-column support was liked so much it got added to the extension itself. (2) This change would use three columns on wide enough screens, it's more or less equivalent to {{reflist|30em}}, not {{reflist|2}}. (3) Two ways to do it already exist. The only thing this change changes is to make the default when "responsive" isn't specified in <references /> be <references responsive=1 /> rather than <references responsive=0 />. Anomie 12:14, 17 July 2017 (UTC)
      • Still not clear on there being a need for this. Users of reflist have pretty much moved away from using the column to the width parameters anyway. Doesn't this have the same effect as your #2 above? What, if any, are the differences? GenQuest "Talk to Me" 13:36, 17 July 2017 (UTC)
        • This form of arguing can also be inverted. Why would you want to keep a difference between two existing methods for the same purposes, now that we have the ability to not have this difference ? Is there a need for columns to begin with ? Well probably not, yet people still like using them. Is there a need to change the default ? Well no one will die if we don't, but if it's already the most common form, then why not align the default with that form and make the exception the more laborious process ? —TheDJ (talkcontribs) 13:52, 17 July 2017 (UTC)
          • Still doesn't answer the question. Why do we not just deprecate <references> and use the more powerful {{reflist}} ? GenQuest "Talk to Me" 16:05, 23 July 2017 (UTC)
  • Support People generally like multiple columns, which is why {{reflist}} is so widely used. We may as well make it the default for a bare <references /> too, where it will use what is currently recommended as the multi-column setting in Template:Reflist/doc#Columns. Anomie 12:14, 17 July 2017 (UTC)
  • Support. There's no harm in doing so since automatically adding columns would actually reduce the amount of space that one has to scroll down. epicgenius (talk) 21:25, 17 July 2017 (UTC)
  • If we were to remove all paragraph dividers and section headers the one would scroll less but that does not mean that the article would be more readable. -- PBS (talk) 16:57, 12 August 2017 (UTC)
Hey, DGG. I see some typos and errors above in your post. Kind regards, --George Ho (talk) 11:31, 19 July 2017 (UTC)
(fixed, though that won;t fix the ping)--S Philbrick(Talk) 19:44, 27 July 2017 (UTC)
  • Support --S Philbrick(Talk) 19:44, 27 July 2017 (UTC)
  • Support -- less work for editors and bots.--Nizil (talk) 07:41, 31 July 2017 (UTC)
    @User:Nizil Shah How is it less work? -- PBS (talk) 16:57, 12 August 2017 (UTC)
    Editors do not have to check and arrange refs in columns when number of refs increases. So one less thing to care about.--Nizil (talk) 06:40, 15 August 2017 (UTC)
  • Support, especially given that it's only a change to the default. Peter coxhead (talk) 08:14, 31 July 2017 (UTC)
  • Strong Oppose, at least unless the following issues can be proven not to apply: You're talking about reformatting hundreds of thousands of pages automatically, sight unseen. (I'd say millions, but alas, I think our average article's sourcing may be too scanty) What happens when the multi-column references interact with infoboxes, graphics, tables, elements that editors have customized by hand with HTML and CSS markup? If they break the format, do editors of that page have any way to know that the references behavior was changed? Even if an editor goes back to the history version, will he see the references appear the way they used to or will he see a broken page was always there? (I think the latter). I'm sorry, but as a general rule, please do NOT mess with default behavior. There's not even any obvious reason I can see why two columns are "better" for "more than 10" references but "worse" for less! Personally I've used the simple references / on even stubs with just a few references because it seems easier to read and keep track of a plain list, so I admit some bias against the idea to begin with, but I think the backward/history compatibility and formatting are serious issues. Wnt (talk) 11:39, 4 August 2017 (UTC)
    • Wnt, can you give a couple of examples of pages that might be affected? The pages you're talking about would have to meet all three of these conditions:
      1. they use <references /> (not {{reflist}} or similar templates),
      2. they have more than ten refs in the group, and
      3. they have hand-customized HTML and CSS markup that affects the list.
    • I don't ever remember seeing an article that meets all three conditions, and I think that a few examples would help people figure out what you're talking about. This search should give you the list of all articles that meet the first condition (plus maybe an extra 25% that don't), which might help you start your search. If my very quick spot-check is reasonably representative, then something on the order of 100,000 articles meet the first two conditions, but I can't find any that meet all three. I look forward to seeing your examples. Whatamidoing (WMF) (talk) 17:44, 6 August 2017 (UTC)
      • @Whatamidoing (WMF): Your search isn't working for me - it pulls out things with reflist and references responsive, etc. Also, checking ten more or less totally random articles using that search, as I did, is not checking a hundred thousand. So I did not find the exact thing you mention. But I *did* already find Paladin (Dungeons & Dragons) in that ten, which has a list of twelve footnotes that I think would be less readable when you decide, sight unseen, to put them into columns. If you want, you're welcome to go put a reflist|2 or references responsive into that section and see how the local editors respond. But if it seems pointless or counterproductive to make that change to one article, how can it be OK to do it to all of them? Wnt (talk) 18:02, 6 August 2017 (UTC)
        1. The search pulls out pages using the reflist template, because the proposed change here is "to switch the default of <references />, without influencing {{Reflist}}" (emphasis added), so those pages are irrelevant.
        2. Your written objection above is about "elements that editors have customized by hand with HTML and CSS markup". If nobody can find any examples of such elements actually existing in articles that will actually be affected by this, then perhaps you'd like to withdraw your objection?
        3. User research demonstrates that splitting long (but not short) lists of refs into responsive columns (NB that'd be {{reflist|30em}}, not {{reflist|exactly two fixed columns no matter what, because that's what looks pretty on my screen}}) makes it easier/faster to find what you're looking for in the refs. So, yes, I do think changing that article to use columns for the refs would be a pointful and productive change. Is it (IMO) hugely important for 12 brief refs to use columns on wider screens? Probably not. The longer the list (and the wider the screen), the greater the benefits. Readers will get some benefits at this length, and they will get more benefits with longer lists. Whatamidoing (WMF) (talk) 17:52, 7 August 2017 (UTC)
    • We have had this discussion. In my opinion it's worth it to break a few rare exceptions if we improve behavior for the far larger majority. For almost any change it is possible to find a small downside and if we give that undue weight, then we will never move forward on anything. Besides if editors have expectations about article content never changing in either format or contents, then they are misguide, per WP:OWN. Styling should never be relied upon when writing. We are not typesetting a book or a newspaper, we are using HTML, to deliver to each and every person a page that is optimized for his or her usage of the content. And before we get wound up about backwards compatibility, let us not forget that we regularly delete entire templates, even though they have been used in articles. Everything is relative. —TheDJ (talkcontribs) 15:38, 9 August 2017 (UTC)
  • Support – The majority of articles use, with good reason, {{Reflist}}, {{Reflist|30em}}, and some other variations that display responsive columns. Making <references /> behave the same way will improve consistency across Wikipedia. A 1-column display for >10 references can still be done. No downside. -- Michael Bednarek (talk) 13:20, 8 August 2017 (UTC)
    @User:Michael Bednarek what is you evidence for this even if the template {{Reflist}} is used it is usually used without any column formatting and until User:TheDJ changed it recently it too displayed one column by default. -- PBS (talk) 16:57, 12 August 2017 (UTC)
  • Support - this is something novice editors can almost never understand, and I don't believe new article creators should have to worry about it. There are few articles for which a multi-column reference list would be inappropriate, and it shouldn't be necessary to manually recode the reflist to be multi-column once it swells up - it should certainly be an automatic thing. Blythwood (talk) 22:17, 9 August 2017 (UTC)
  • Support - thanks for taking this hard work on. I'm glad to see this proposal come to fruition - as editors we really shouldn't have to manually set how many columns a reference list has. Legoktm (talk) 03:39, 10 August 2017 (UTC)
  • Support. As I understand it, the facilities to produce other column widths and numbers will remain for those rare occasions where they may be useful, so I see no real down side, only imaginary/hypothetical ones. • • • Peter (Southwood) (talk): 10:08, 10 August 2017 (UTC)
  • Support. Where {{reflist}} section 2.1, bullet 3 applies it can be overridden (see for example Edith Cavell). The only problem is if someone lets loose a bot or goes off on a spree removing all reflist parameters without reading and thinking. Martin of Sheffield (talk) 11:13, 10 August 2017 (UTC)
  • Comment I think that this needs to be decided by an RfC, and as this affects the citation style I think it appropriate to hold it on the talk page of the guideline that covers this issue, so see Wikipedia talk:Citing sources#RfC: Number of columns when displaying ref..tags -- PBS (talk) 11:31, 10 August 2017 (UTC)
    • Why do you think this isn't an RFC? Anomie 12:57, 10 August 2017 (UTC)
  • This is not an RfC because it has not RfC banner at the top! -- PBS (talk) 16:57, 12 August 2017 (UTC)
  • Support, so long as the behaviour can be turned off by code. While this would work with the vast majority of pages, some will be better off with refs in a flat list rather than columns. Ivanvector (Talk/Edits) 19:26, 10 August 2017 (UTC)
  • Comment I first saw this earlier today, and was at first in the negative camp wrt a new default for {{reflist}}, but have softened somewhat because I see its value in the majority of cases. I recognize that the ship has probably sailed, but I'm with PBS (talk · contribs) in regretting its effect on readability for articles that have at least one reference generated by templates referring to EB1911, EB9, DNB, CathEnc etc (of which there are probably tens of thousands) due to their inevitable length. Great Officer of State is the current canonical exhibit A, but even one such reference tightly wrapped into multiple lines in a column is plain ugly. Fortunately, it's the nature of such articles dependent on old PD sources that this citation is often the only one, and having more than ten is a small minority. I don't know of a good solution for these cases; manually forcing some to one column on the basis of visual style is way down the totem poles of priority for me. I am aware that using {{sfn}} with a single "source" notation is an alternative, but have other issues with that approach.
Some have suggested that we use {{reflist|1}} as an override. But I thought the unnamed parameter was deprecated, so that confuses me.
I'm also in agreement with whoever said that the XML element looks like the old Wikipedia, as opposed to the more concise reflist, especially with LDRs. But, if it's going to be used, I hope we don't literally mean people should write <references responsive /> (an attribute without a value) because it's invalid XML. David Brooks (talk) 21:12, 10 August 2017 (UTC)
ETA: I realize I'm not being constructive above. Does the implementation have the ability to increase the column width if it detects that there are footnotes with more than a certain number of characters? Great Officer of State looks much better at 48em, and slightly better at 40em, than the default (I realize that would often just end up in a single column). Also, now that I understand the syntax I see that my comment about LDRs above is backwards, so I withdraw it.
To Mike Christie's comment below - may be true for new articles, so long as the editor is up to date on the responsive feature, but for existing articles requires first finding candidates, which would take some deep analysis. Not so simple. David Brooks (talk) 01:45, 11 August 2017 (UTC)
  • Support. This should be the default behaviour; it can be over-ridden if needed so I see no issue with the rare articles that don't want this. Mike Christie (talk - contribs - library) 22:53, 10 August 2017 (UTC)
  • Support Seems like a sensible change that would improve article readability. AlasdairEdits (talk) 14:24, 11 August 2017 (UTC)
  • Support, currently we let article editors to decide on the number of columns, which means that articles have whatever looks best on particular peoples' screens. We can serve our readers better by adapting to everybody's screens. Max Semenik (talk) 20:22, 11 August 2017 (UTC)
  • Commment @user:Winged Blades of Godric I have re-open this as I created an RfC two days ago about this issue and my questions there were not addressed. There is no reason for closing this so quickly particularly as it was not well advertised. It is a very big change that affects a lot of pages so I think that there needs to much more widely advertised, than it has been so far. -- PBS (talk) 16:57, 12 August 2017 (UTC)
@PBS: Besides being listed at Template:Centralized discussion (as mentioned by Godric), there were notifications at Wikipedia talk:Citing sources, Help talk:Citation Style 1, Help talk:Footnotes, Template talk:Reflist, and Wikipedia:Village pump (technical). Were they not adequate enough? --George Ho (talk) 20:34, 12 August 2017 (UTC)
  • Oppose keeping default as 1 column. It was the change to the template {{reflist}} that now displays multiple columns as seen on the page Great Officer of State that alerted me to this change. While I agree that short citations are better displayed with multiple columns, the majority of pages I have looked at, if they have inline citations, they are full citations and I do not think that full citations are better wrapped into narrow columns because it makes them harder to read. -- PBS (talk) 16:57, 12 August 2017 (UTC)
  • Comment @User:TheDJ, I think your comments at VP show a misunderstanding of why people use {{reflist}}. They may use it to display multiple columns, but they may also use it for its other attributes of making the text smaller, or simply use it because it is used elsewhere. It would be interesting to see a proper search done, but using insource:/\{\{[Rr]eflist/ (which times out), and the small sample returned on the first page of results: twelve of the 20 have no parameter, two use "2" as the parameter five use "em30" and one uses "em35".-- PBS (talk) 16:57, 12 August 2017 (UTC)
  • Comment @User:TheDJ On the page Wikipedia talk:Citing sources you wrote "I will just note that people on this page were informed and invited, several sections up: #Proposal to default references element to column mode. —TheDJ (talkcontribs) 13:53, 10 August 2017 (UTC)"
    (1) what makes you think that "Proposal to default references element to column mode" would be a very significant header or that "I have started a proposal to switch the default behaviour of to automatic column mode" would be understood by most people that you intended to change the behaviour of the default setting? (2) why did you make changes to the default behaviour of {{reflist}} before there was a general consensus for such a change? -- PBS (talk) 16:57, 12 August 2017 (UTC)
For your kind information, this was listed at Centralized discussion for an entire month.Your RFC was already closed.Now, move on or take this to AN.Winged Blades Godric 17:04, 12 August 2017 (UTC)
@PBS:--Winged Blades Godric 17:07, 12 August 2017 (UTC)
@User:Winged Blades of Godric This was not an RfC so there was no reason to close it after a month. Besides people are clearly still posting the section so why close it? Are you in favour of the proposition or against it? -- PBS (talk) 17:22, 12 August 2017 (UTC)
  • Comment Since this thread is still active but it seems the feature is now established, I want to reiterate a request I made above that may have been overlooked. PBS (and I) make a valid point: the impact on long references is deleterious to readability. There are probably thousands of articles with long refs in their footnotes (and I may be underestimating by a ten-factor or more). Finding and editing the subset of such articles that have 10+ footnotes in order to widen the columns may be beyond my abilities to automate. So the request is: can the "references responsive" code be enhanced to detect long lines in the footnotes, and substitute a column width of 48em? For some definition of "long", and some tweaking of "48", of course. David Brooks (talk) 17:31, 12 August 2017 (UTC)
That's because your text isn't like footnotes, with its mixture of very short and moderately short lines. Using our admittedly extreme example of Great Officer of State, compare the default setting with one I forced to 42em width (not even the 48 I mentioned) at different window sizes. I think wider is better in this case, although 30 is probably OK for the typical footnote. Now consider the pages many where the full footnote is generated by {{EB1911}} with inline parameter, like "One or more of the preceding sentences incorporates text from a publication now in the public domain: Chisholm, Hugh, ed. (1911). "Antithesis". Encyclopædia Britannica. 2 (11th ed.). Cambridge University Press. pp. 146–147." (see Antithesis, where I experimented with 40em) for the more extreme effect. Or consider editors who put a fully-populated {{Cite book}} in an inline ref. David Brooks (talk) 00:02, 14 August 2017 (UTC)
In both examples you give, I like the two-column approach better than the one-column approach. (Those widths work out to that number of columns on my screen; it may be different on yours.) Whatamidoing (WMF) (talk) 00:40, 14 August 2017 (UTC)
What we are talking about here is a style preference. As most editors who have subsituted {{reflist}} for <references/> have presumably chosen the number of columns they want, it is reasonable to assume that they chose none because they wanted one column. As that was a style preference, I do not see why that ought to be changed particularly as it runs contrary to the spirit of WP:CITEVAR. A change such as this that affects 100,000s of pages ought not to be made by about a score of editors in a discussion that is not even an RfC. -- PBS (talk) 09:41, 15 August 2017 (UTC)
PBS, while I agree with you in this particular debate, I don't see support for your assertion that "most editors who have subsituted {{reflist}} for <references/> have presumably chosen the number of columns they want". I make the substitution in any case, often through an AWB template, because I remember reading some time (years?) ago that the template is preferred to the xml - in part because it does allow for parameters, but also because raw XML in a document seems so 20th century. Yes, it's more transclusion work for the backend, but that's what servers are for. David Brooks (talk) 16:41, 15 August 2017 (UTC)
@DB surly if you replace <references/> with {{reflist}} then you choose how many columns you want. Personally I often use {{reflist|30em}} but that is because I expect there to be 2 columns on a typical computer display (more or less depending on the width of the window). If I set it to {{reflist}} then I have deliberately chosen to one column. -- PBS (talk) 17:38, 15 August 2017 (UTC)
I took a look at 10 pages currently using the <references /> tag. I found two added before {{reflist}} was created, and another just days after its initial creation (in late 2006). Two were added by editors who primarily edited at wikis that don't use that template. One was added in 2007, three by experienced editors in 2008, and the last by a logged-out editor in 2009. I found no examples of editors removing the template in favor of the native code (although I've personally done that, because the visual editor does live updates for the native code, but not the template, while you're editing).
Another way of stating this is that some of these were added before the reflist template was an available option, and all of these were added before {{reflist}} was used by the Article Creation Wizard or otherwise recommended as the "normal" way to add refs (which, if memory serves, had much more to do with the size of the font than anything else, but now the two methods use the same font, so that distinction no longer exists).
None of this suggests that a deliberate choice against having columns in the article. PBS, if you have evidence that the use of <references /> is a deliberate request for a single column, then please share it. (Remember, the change under discussion has no effect whatsoever on what happens to any article that is using {{reflist}}. It's only about what happens to pages such as Original video animation, where <references /> was added before the {{reflist}} template even existed, and has never been replaced. So if anyone changed an article from <references /> to {{reflist}}, then that article will not be affected by this. It's only if you changed it the other way around that the article could be affected – and I found no examples of people doing that.) Whatamidoing (WMF) (talk) 18:28, 15 August 2017 (UTC)
It is not an issue of <references/> because that has always been one column. However in anticipation of a change to <references /> {{reflist}} has been changed to emulate it. As the majority of the {{reflist}} I surveyed in a crude search were single column, it seems reasonable to assume that it is a reasonable proxy for the preferred number of columns among those editors who have exercised a choice. -- PBS (talk) 14:41, 18 August 2017 (UTC)
It looks like {{reflist}} has been changed to explicitly specify either responsive=1 or responsive=0 on every page, but this proposal is unrelated to that. Supporting or opposing this change will not have any effect on {{reflist}} or any page that is using that template.
Given that the Article Wizard puts plain {{reflist}} in all articles, and given that plain {{reflist}} seems to have been put by bot/AWB into more than a million articles during the last five years, I am not convinced by your assertion that the use of the plain template indicates an intentional use of one column. Perhaps a better measure would be the use of columns in GAs and FAs, since those generally include long lists of references, and are generally written by editors who know how to change the default.
But even if I were convinced by your argument that not changing the template indicates intentionality, it's pretty much irrelevant, because this change will not have any effect whatsoever on the reflist template, or on any page that is using the reflist template. This change amounts to "When the responsive status is not specified (e.g., when the responsive-status-specifying reflist template is not used), then it should produce two or maybe three columns, on long lists of references, if your screen is wide enough."
This change will likely affect ≤2% of articles. Whatamidoing (WMF) (talk) 16:36, 18 August 2017 (UTC)
  • DavidBrooks, your example, Great Officer of State, has quite short references compared to fully expanded references for books, institutional web pages, and journal articles used in many areas of Wikipedia. To have reflist detect such short references and use overly wide columns would completely undo the point of responsive references for much of the English Wikipedia. StarryGrandma (talk) 21:00, 14 August 2017 (UTC)
  • That PBS and a few others feel that more disc. is needed, I would like to request the discussants to re-post this thread at Cent and make some fresh advertisements at related notice-boards.Otherwise, from the mini-post-closure discussion that is taking place, I fear, that it may be the same set of faces arguing/discusing broadly on the same set of themes.Esp. in an area where perceptions (rel. to readability et al) matter considerably, new faces would be welcome for sure.Winged Blades Godric 10:02, 14 August 2017 (UTC)
I reinserted the entry into CENT template, Godric. I also notified others about this discussion. I wasn't sure whether to notify at WT:V or request posting an announcement at MediaWiki talk:Sitenotice, or MediaWiki talk:Watchlist-details, but I should be careful about canvassing before doing any of those options. --George Ho (talk) 10:34, 14 August 2017 (UTC); partially struck, 13:05, 15 August 2017 (UTC)
thats fine, but I will not spend more time on this than I have. —TheDJ (talkcontribs) 02:57, 15 August 2017 (UTC)
PBS, may this discussion be mentioned in MediaWiki:Watchlist-details or MediaWiki:Sitenotice? You said that the discussion needs more input, right? --George Ho (talk) 12:50, 15 August 2017 (UTC)
George Ho, a watchlist or site notice for this would be inappropriate. This a minor formatting change, not a major policy issue. TonyBallioni (talk) 13:03, 15 August 2017 (UTC)
Rescinded consideration. --George Ho (talk) 13:04, 15 August 2017 (UTC)
  • Comment@ StarryGrandma I agree with you, but the problem I have finding a really good example is that most of the pages I edit tend to use short citations and separate references section, and I think that columns are preferable for short citations. I tend to come across articles with 100 of large inline references only when I am running AWB scripts to fix something else, and as this is not an issue that has come up before I have not kept a record of such articles. Perhaps someone else has a few examples which can be used so that others view them and made an informed decision. -- PBS (talk) 09:24, 15 August 2017 (UTC)
Try Pythagoreanism and Birecik, both of which contain two of the "long" version of the EB1911 template. Now I look at those, with some other long citations, I'm even more against the idea of forcing a width without reference to the line lengths. There are many other pages with multiline references due to book citations etc. But I am sensitive to the problem that choosing a bigger width (42 or 48) would result in just one column anyway, on most displays that aren't fullscreen on a PC. David Brooks (talk) 16:41, 15 August 2017 (UTC)
  • Support - Since it's re-opened, I then add my full support. Making <references /> adopt to different screen sizes is always a plus to readers, this can be easily overridden with {{Relist|1}}(with this version) or <references responsive="0" /> for editors who prefer a single column, the latter can also be added to charinsert gadget for an even easier access. --Lam-ang (talk) 15:15, 16 August 2017 (UTC)
  • Support Headbomb {t · c · p · b} 15:53, 16 August 2017 (UTC)
  • Support all the supporting arguments above. — Stanning (talk) 17:24, 16 August 2017 (UTC)

Allow users in the Account Creator user group to add users to the Confirmed user group

WITHDRAWN:
I'm going to withdraw the proposal, as it's clear there is no consensus for it. About 40% of respondents supported the proposal and about 60% opposed it. Most of those opposing it oppose it due to the lack of vetting/qualifications for Account Creators. I'm going to follow-up this proposal with a new proposal to create an "Event Coordinators" user group that includes a vetting process and specific qualifications, as I think that might address the concerns of both the supporters and opposers. Kaldari (talk) 23:03, 15 August 2017 (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.

Some time in the next month or so, the Wikimedia Foundation will be implementing WP:ACTRIAL at the request of the English Wikipedia community. (See the RfC.) During this trial, new (non-autoconfirmed) users will not be able to create new pages in the main (article) namespace. There is concern this could interfere with legitimate new article creation during edit-a-thons and similar events. In order to address this issue, I would like to propose that we modify the Account Creator user group (which is commonly assigned temporarily to people running edit-a-thons) so that users in this group can add other users to the Confirmed user group, thereby allowing vetted users to create new articles at these events. (Note that these articles will still be added to the reviewing queue at Special:NewPagesFeed.) The purpose of this change is basically to provide a work-around during ACTRIAL, so that disruption to these events can be minimized during the trial. As such, it can either be a temporary or permanent change, depending on what the community prefers. Kaldari (talk) 21:23, 4 August 2017 (UTC)

  • Support as a temporary change during WP:ACTRIAL. Most users who are added to the Account Creator user group are experienced event coordinators who are at least providing some basic guidance on how to create proper articles. Although I'm sure there will still be a fair percentage of low quality new articles from edit-a-thons, this will hopefully keep us from throwing the baby out with the bathwater. We should remember that ACTRIAL is about reducing the volume of spam and COI articles, not 100% eliminating all bad new articles. Overall, I think the contributions from edit-a-thons are a net positive for Wikipedia and we shouldn't cut those contributions off. Kaldari (talk) 21:23, 4 August 2017 (UTC)
One of the major objectives of ACTRIAL is to reduce the workload for reviewers and other maintenance workers. Last week an editathon in South Africa organised by the SA chapter and the Swedish embassy was publicised during a TV interview and received a high participation. Unfortunately, the facilitator was ill prepared for the unexpected high participation and a number of articles were produced in good faith but were totally unsuitable for an encyclopedia. It's a shame to have to delete these otherwise good faith efforts. Rather than making any changes to the User Group permissions, perhaps it would be more appropriate for editathon facilitators to teach their students how to edit by getting them to create their articles in their sandbox or or in the Draft namespace instead. Facilitators could them move suitable articles to mainspace for them. Kudpung กุดผึ้ง (talk) 00:20, 5 August 2017 (UTC)
See the TV article on SABCnews. Kudpung กุดผึ้ง (talk) 03:05, 5 August 2017 (UTC)
Ha! Kaldari, you should know by now that "experienced" has a multitude of meanings. You are aware of the issues relating to the recent Dalit campaign, which involved edit-a-thons and was a disaster. This summary only brushes the surface and is replete with poor decision-making from admins and past/present WMF staff. I can assure you that I am not alone in my estimation that it was a complete mess. I wouldn't trust people like that to make exceptions to whatever the standard operating procedure/policy/guidelines might be. There is no deadline for creating articles but we have a limited number of regulars who actually know what they're talking about, and they're stretched as it is. - Sitush (talk) 00:37, 5 August 2017 (UTC)
Oppose/Needs improvement first as-is, way too many people are getting added to account-creator already that aren't even confirmed themselves! (See this list). I would normally support this, but not unless we put some actual requirements on being an account creator first. — xaosflux Talk 01:04, 5 August 2017 (UTC)
Xaosflux There are 338 names on that list, probably a lot more than are needed, a very large number of which whose edit count is only double figures. Recently buttons were added to the User Rights Manager to be able to accord rights for a limited period after which they would expire. This was particularly useful for Account Creator. However this feature seems to come and go for various user groups and is again not available for Account Creator. Curiouser and curiouser. Kudpung กุดผึ้ง (talk) 03:37, 5 August 2017 (UTC)
@Kudpung: the expiration should be always available to assign, if you see a case where it's not I'd be happy to check and get a bug open if it is not. Many, many of these were added for "events" and a specific administrator did the majority - I'm following up with them. — xaosflux Talk 12:34, 5 August 2017 (UTC)
It's a browser problem, Xaosflux. The buttons are not rendering in Firefox on Mac. Kudpung กุดผึ้ง (talk) 16:37, 6 August 2017 (UTC)
Re: needs improvement: To be clear, what I think needs fixing first is qualifications/expiration needs for the account creators themselves. — xaosflux Talk 20:04, 7 August 2017 (UTC)
  • Support as useful: as a Lead Trainer for WMUK, I've been running editathons and other training events for the last five or six years and have trained hundreds, perhaps thousands of new editors. As I stated at Wikipedia talk:Autoconfirmed article creation trial #Supporting edit-a-thons and similar events, it would be helpful – but by not means essential – to be able to grant autoconfirmed status to event participants on occasion. Most participants work in their sandboxes, and it is not so often that they want to create a new article, so ACTRIAL won't impact much on most of them. In those cases where an non-autoconfirmed editor has the ability to create a new article on the day, there are work-arounds available. Nevertheless granting autoconfirmed status to someone who is clearly capable of producing a new article that early in their editing career doesn't seem like much of a risk, so I can't see any problem with account-creators being able to do that. Either you trust account-creators to do these sorts of jobs, or you don't; if you don't, then I can understand you opposing the proposal here. --RexxS (talk) 12:12, 5 August 2017 (UTC)
    I don't - but I think I could - if we vetted the account creators more (e.g. they had to be extended confirmed to use this). Guidance would be to add confirmed with say a short expiration date, if the people are editing they will end up getting autoconfirmed in a few days anyway. — xaosflux Talk 12:34, 5 August 2017 (UTC)
    So the instructions at the editathon might be: "You've made 10 edits, so now all you have to do is sit around here for a few days and you'll able to move your new article into mainspace." It kinda misses the immediacy I usually hope for. :D --RexxS (talk) 15:10, 5 August 2017 (UTC)
    No, assuming this gets supports, I'm saying that attendees would get +confirmed for say a month - if they never come back it just expires, else by the time it expires they would already be autoconfirmed. — xaosflux Talk 16:15, 5 August 2017 (UTC)
    That sounds very reasonable. In practical terms then, what would be the difference between having the right expire after a month and not having the right expire after a month (assuming all participants at an editathon/training event will make at least 10 edits on the day)? --RexxS (talk) 16:24, 5 August 2017 (UTC)
  • Support per RexxS; and speaking as an equally-active trainer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 5 August 2017 (UTC)
  • Support as a temporary change during ACTRIAL: Some newbies go through the ACC process, but during edit-a-thons etc; will be a major disruption to events. KGirl (Wanna chat?) 18:49, 5 August 2017 (UTC)
  • Support per RexxS, but with the understanding that there will be clear guidelines for granting that would include among other things time limited granting, both of the confirmed status and of account creator status. Note, I don't think ACTRIAL will be a major disruption for editathons per feedback we've received at those discussions. This is, however, a nice plus to make it easier. TonyBallioni (talk) 18:55, 5 August 2017 (UTC)
  • Support on a temp basis Maybe we can see how this works in the future as well. My name isnotdave (talk/contribs) 08:19, 6 August 2017 (UTC)
  • Support on a temp basis during the trial, for in person event coordinator use only, due to the time and logistical limitations of such events. Any other use of the ability (in the ACC process, etc) should be treated as misuse and grounds for removal of the bit. – Train2104 (t • c) 12:27, 6 August 2017 (UTC)
Oppose Per the comments below and some review of the list of users with this flag, I have some serious concerns about a relatively large number of users with little to no experience/knowledge of WP policies having this ability. If/when the eligibility requirements for accountcreator are stricter, we can revisit this. See also this apparent free-for all request page. – Train2104 (t • c) 16:48, 8 August 2017 (UTC)
  • Support during ACTRIAL per above for now. There is no need for having this on a permanent basis. I don't think it should be limited to event coordinators though. Regards SoWhy 16:44, 6 August 2017 (UTC)
  • Support - both as a temporary change during ACTRIAL and as a permanent change. It would be good to have this on a permanent basis because of the fact that it would help those at Edit-a-thons upload images for the articles they are creating. RileyBugz会話投稿記録 16:52, 6 August 2017 (UTC)
  • Support during ACTRIAL. Edit-a-thons often involve creating articles. —MRD2014 Talk • Edits 00:25, 7 August 2017 (UTC)
  • Support at least for now until we work out something better. This won't deal with all difficulties in training, but it will help. About 9/10 of the trainees usually do not come back after a month, so there ought to be some expiration date, or they might come back years later and still have the confirmed right (unless this proves to be too difficult to program, it which case we just think of it as a minor problem. However, it is essential that for relatively inexperienced group leaders granted account creator for a particular editahon, that both account creator and this userright expire . DGG ( talk ) 05:26, 7 August 2017 (UTC)
  • Support for the duration of ACTRIAL, and or if that experiment becomes permanent. Sadads (talk) 17:57, 7 August 2017 (UTC)
  • Support on an ongoing basis. Enabling edit-a-thons and other events with training and editing on the same way is good for the encyclopedia.--Carwil (talk) 20:34, 7 August 2017 (UTC)
  • Support Give the userright and let participants make wiki articles. I sympathize with Xaosflux's reasons for opposing but the reality is that at the current pace of conversation, the account creator userright will not be developed sufficiently within the next 3 years. Despite the potential for abuse, there is no public history of problems documented with this userright or with in-person Wikipedia editing events. I do not think that this userright is the origin of the tension, but rather, the tension is between the WMF and Wikimedia communities who are organizing large numbers of in-person wiki events while some of the Wikipedia community are unwilling and uninterested to acknowledge the existence of the events. If the events will happen, then the user right should be granted. If anyone opposes the events, then please take the argument to the WMF which sponsors them and has capacity to host discussions on how they should be managed. Blocking events with private discussions with the lower level, more vulnerable, and well meaning volunteer organizers who do not want to be swept into wiki politics is not the way to develop the Wikimedia community's event policy. Blue Rasberry (talk) 21:15, 7 August 2017 (UTC)
  • Support confirmed is not a very dangerous user right to have and the threshold for getting it normally is very low. I would support making this permanent. Hut 8.5 21:20, 7 August 2017 (UTC)
  • Support I think account creators are trustworthy enough to know who should and shouldn't be able to create pages during ACTRIAL, and this seems to be beneficial for letting them create pages without making a given # of minimum edits. Everymorning (talk) 22:12, 7 August 2017 (UTC)
  • Support This seems like an eminently reasonable proposal, and in cases of abuse it seems easy enough to reverse. Ancient Studies major (talk) 22:40, 7 August 2017 (UTC)
  • Oppose Let these new editors write drafts. I've been to a fair number of edit-a-thons and I don't think most account creators are doing enough to control what the attendees write. Show me that account creators are always being held responsible before I place any trust in their discretion. Chris Troutman (talk) 22:45, 7 August 2017 (UTC)
  • Support - Sure. Account creators are trusted individuals, and this addition makes sense for their work. -- Ajraddatz (talk) 23:07, 7 August 2017 (UTC)
  • Support per RexxS. Thanks. Mike Peel (talk) 23:20, 7 August 2017 (UTC)
  • Oppose until we prune the list of account creators. As of now, I count some 320 account creators, 221 of which have made fewer than 1000 edits (including 50 that have made <10 edits, and another 96 that have between 10 and 99 edits). T. Canens (talk) 23:30, 7 August 2017 (UTC)
  • Oppose per T. Canens. There are very few editors I'd trust with this tool. Callmemirela 🍁 talk 23:55, 7 August 2017 (UTC)
  • Support per Blue Rasberry. Double sharp (talk) 23:59, 7 August 2017 (UTC)
  • Oppose first per Chris Troutman (I wish all editathon organizers were RexxS but that is not what the incoming pages stream suggests) and then additionally for sake of ACTRIAL's data. I'd rather see what ACTRIAL does when "fully" implemented rather than muddy the data by allowing account creators with potentially widely varying standards to override the limit on new users sending pages straight to mainspace. Innisfree987 (talk) 00:30, 8 August 2017 (UTC)
  • Oppose. Let's be clear on a few things. There is nothing bad about editors creating drafts as part of edit-a-thons and submitting those drafts through AfC. In fact, that's the whole point of ACTRIAL; new editors submitting to AfC instead of mainspace. Second, keep in mind this opens the door of removals of account creator for cause. If this passes and I see an account creator grant the right to an editor who goes on to create inappropriate articles, that account creator will lose their user right. That's going to affect edit-a-thons more severely than submitting drafts to AfC. ~ Rob13Talk 01:12, 8 August 2017 (UTC)
    • BU Rob13, from some of the comments here re: account creators, creating clear guidelines for revoking the tool seems like a positive to me, not a reason to oppose. Re: ACTRIAL, we received some pretty vocal feedback from users who cared about editathons and similar programs. We do have some very bad editathon creations, but we also have some very good ones that I think are probably a large part of the 20% of articles by non-AC users that don't get deleted. Your comment did remind me though that I think that if this is implemented, there should be an explicit guideline preventing its use as a part of the education program/WikiEd/school courses: those are the organized events that in my opinion have the most inappropriate creations directly in article space. TonyBallioni (talk) 03:04, 8 August 2017 (UTC)
      • @TonyBallioni: Here's the scenario I'm worrying about. Account creator grants the confirmed flag during an editathon, and the editor they grant it to creates an article that is immediately speedy deleted as a copyright violation. At this point, the account creator has bypassed ACTRIAL for an editor who doesn't know what they're doing, and the only recourse to prevent this from recurring is to yank the account creator right. Now the account creator is 30 minutes into their edit-a-thon without the ability to help editors create accounts and everyone's worse off. That's surely a concern. ~ Rob13Talk 12:30, 8 August 2017 (UTC)
        • Rob, thanks for the response. I still see having a fleshed out policy as to when to remove the account creator bit is needed, and think that this conversation has shown that. Your example is a good one, but by giving people clear guidelines, I think it would be rare. As an aside that is probably better for one of our talk pages, the issue of copyvios in new content is really something that we need to work on educating people at NPP/AfC about. So much gets through that isn't caught by EranBot. TonyBallioni (talk) 15:07, 8 August 2017 (UTC)
  • Oppose mainly for the reasons highlighted in my initial comment above, which Chris Troutman reflects in a more succinct manner.; also per BU Rob13 and Innisfree987. I think T.Canens; figures may be slightly skewed because there are some obvious low-count entries in the results list where it would seem experienced contributors have created "roaming"/"public place" accounts for use at edit-a-thons. Nonetheless, there are enough scary examples in there to make me wonder who has been granting these user rights. - Sitush (talk) 02:57, 8 August 2017 (UTC)
  • support seems like a good idea. this way, during editathons and such, they can edit semi-protected articles, and create new pages during the ACTRIAL. really, confirmed is not that much of an additional privilege. if there are problems, it can always be rescinded. -- Aunva6talk - contribs 03:22, 8 August 2017 (UTC)
  • Oppose This sounds like a horrible idea in my opinion. Whispering 03:31, 8 August 2017 (UTC)
  • Oppose As a recent participant in a Wikipedia Meetup, almost all users were creating articles as drafts or in the sandbox anyway. There is no reason why edit-a-thon contributors cant just submit their drafts for review to AfC as intended, and no reason why these drafts cannot simply be added to a list and edit-a-thon helpers (like myself) can't review their AfC creations themselves, or else move the drafts to mainspace for them (after reviewing them). In the worst case, a draft has to go through a bit of a wait at AfC... what is the problem here? This is the whole point of ACTRIAL, and shouldn't be sidestepped during edit-a-thons or meetups. — InsertCleverPhraseHere 04:05, 8 August 2017 (UTC)
  • Oppose per Xaosflux Keira1996 04:10, 8 August 2017 (UTC)
  • Oppose per Xaosflux, Kudpung, and Sitush. Vanamonde (talk) 04:40, 8 August 2017 (UTC)
  • Oppose: I fundamentally oppose to all measures increasing any rights of those organizing mass events. This is just WM-agenda, increasing their maneuverable volume, but decreasing WP-quality by under cover agenda pushing. See all further arguments above. Purgy (talk) 06:32, 8 August 2017 (UTC)
  • Oppose I see no real reason why new editors should be given the ability to easily make pages, they should go through the proper autoconfirm process. or they should create an account before the event like a sensible person would, to learn about Wikipedia, rather than jumping into the deep end of Wikipedia's most difficult task. making bulk new pages does not really help Wikipedia much anymore, since it just 'bungs up' the new page patrol system. A Guy into Books (talk) 07:23, 8 August 2017 (UTC)
  • Oppose. The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. The participants are then being taught the method which they will need to know when the edit-a-thon is over, and there is an encouragement and incentive for participants to get the article right in order for it to go live. It also encourages the attitude that while anyone can edit Wikipedia, what we're after these days is quality contributions. I would rather an edit-a-thon resulted in just one good quality contributor remaining active than have 100 well meaning but less than competent contributors remaining active adding inappropriate unsourced material which then has to be dealt with. SilkTork ✔Tea time 08:03, 8 August 2017 (UTC)
  • Support This should be granted on a long-term basis as it's a hassle if this keeps lapsing. For example, I currently have the account creator right. On Aug 17, I'll be attending an event at the Royal Society of Chemistry. So far as I know, the main organisers are not admins and neither am I. Because it will be on a weekday, participation by volunteers may be limited and so this seems a good example of an event that might be disrupted by over-zealous throttles on account and article creation. The institution and organisers are of impeccable quality and so it's us that will look bad if we can't handle the smooth onboarding of novices at such an event. As another example, I was recently discussing setting up an event at the Wiener Library. At the last event there, the main organiser was actually blocked by an admin, which caused considerable bad feeling. Such hostility is contrary to policy and is foolish. I was myself checking out Everipedia this morning. I don't know much about it yet but get the impression that it has some momentum because it is more open and welcoming. Wikipedia is not the only game in town. As a further example, I just got an edit conflict posting this. This place really tries one's patience... Andrew D. (talk) 08:06, 8 August 2017 (UTC)
  • "Impeccable quality" as scientists, sure. But in terms of Wikipedia knowledge? - Sitush (talk) 08:17, 8 August 2017 (UTC)
  • The main organisers I'm thinking of are Dr Jess Wade and Dr Alice White. They are bright, energetic and personable. And they are fun to work with – that's why I'm going to take a day's leave to support this event. They exemplify "good faith" and so we should strive to facilitate their work rather than putting obstacles in their way. Andrew D. (talk) 09:44, 8 August 2017 (UTC)
  • Encouraging users to use the appropriate process should not be viewed as an obstacle. No one here is suggesting putting obstacles in anyone's way; rather, that the due process we have been developing to protect Wikipedia and to enable and encourage positive participation should not be specially put aside. All new articles are over-viewed by the community, be they articles created in someone's home, place of work, university library or an edit-a-thon. The users at the edit-a-thon are no different to any other user - their work will be seen by our new page patrollers and dealt with. If inappropriate articles are rejected by the patrollers this will have a dispiriting effect on the edit-a-thon editors. I'd rather they were shown the right way of editing Wikipedia, so they don't have the experience of their work being speedy deleted, but have it go through AFC where if it gets rejected reasons are given, and the work is still available for the user to work on. Not an obstacle, but an assistance. SilkTork ✔Tea time 11:43, 8 August 2017 (UTC)
  • That sounds like you are suggesting that some people are more equal than others, more deserving of special treatment that is not available to other new contributors. As I said way, way above, it is evident that course organisers etc cannot or do not always vet what goes on and so such special treatment both undermines the trial and doesn't fix the longer-term problem. I realise different edit-a-thons attract different people but the ones I've come across have had pretty universally poor outcomes that have entailed a massive amount of clean up for BLP violations, copyright issues, sourcing and, well, pretty much everything. Being keen is good; being au fait with how Wikipedia works takes time. Edit-a-thons tend to rush through a lot in a short span. Tbh, I'd be quite happy if they didn't exist. - Sitush (talk) 12:03, 8 August 2017 (UTC)
  • All users are not equal – that's the point of this discussion as we're talking about permissions and privileges. Confirmed status seems designed mainly as a pure obstacle. The main issue is the four-day wait and that has no functional purpose as nothing much happens during that time; it's just a cooling-off period to discourage people. One consequence of not having confirmed status is that you have to supply CAPTCHAs when adding references. Adding citations is painfully difficult for experienced users; that's why so little of it gets done. When you have to do CAPTCHAs too then it becomes really annoying because they are not easy; I have trouble with them myself. Again, this is another obstacle especially designed to make it difficult for new users rather than encouraging them. Experienced users and admins tend not to appreciate how obnoxious Wikipedia is for a new user because, thanks to their privileged status, they don't have to deal with these obstacles. But all our current experienced users will not exist in due course because we don't live forever. Who will edit Wikipedia in the future if we make it increasingly difficult to get in? Andrew D. (talk) 17:50, 8 August 2017 (UTC)
  • All new user are equal. They have no privileged rights unless someone grants them. I don't trust the edit-a-thon environment (plenty of empirical evidence) nor, indeed, quite a few of the account creators to grant rights appropriately and I don't see why a new user should so arbitrarily be able to leapfrog a system that by far the majority of new users have to go through. I'm well aware of the issues of not being autoconfirmed because I've edited occasionally when logged out (one or two edits, in subject areas I never visited before or since). Not having the arbitrary account creatoin process does not make it more difficult to "get in" than it already is. - Sitush (talk) 18:49, 8 August 2017 (UTC)
  • Empirical evidence? I have attended over 10 events so far this year. They were all of high quality and were typically in partnership with world-class academic and GLAM institutions. They were typically focussed on a new event or on filling in red links, such as missing women. Article creation is a fundamental aspect of such events and it's something that our partners like and can get funding for, because it's productive – an outcome that they can measure and boast about. If you invite people to a one-day event with such a focus it is then ridiculous to tell them that they have to wait four days. That's what ACTRIAL would mean; it would make us look like jobsworths rather than the encyclopedia that anyone can edit. Andrew D. (talk) 06:48, 10 August 2017 (UTC)
  • I've given you some empirical evidence, Andrew and I've already explained that being an expert in an academic field has no bearing on abilities as a newcomer to Wikipedia. This isn't really about biting the edit-a-thon newcomers, who would be treated just like any other newcomer, but rather the people who grant the rights. Too many, including admins and WMF staffers, demonstrated cluelessness in this area and are so set on their pet "social justice" projects, grant income etc that they can't see the wood for the trees. Sue Gardner's much maligned Indian Education Program was another example. That said, even a select group of newcomers - whom you for some reason think automatically know what they're doing here - would be less likely to be bitten if they went through the usual processes of AfC etc. - Sitush (talk) 07:20, 10 August 2017 (UTC) (Sorry, my "biting" bit makes little sense because you edited your comment while I was writing mine. - Sitush (talk) 08:18, 10 August 2017 (UTC))
  • Oppose As per SilkTork, while we want to encourage the view that anyone can edit Wikipedia, we also want to encourage the view that creating quality material requires learning about policies and processes, particularly the need for reliable sourcing. Peter coxhead (talk) 08:47, 8 August 2017 (UTC)
  • Oppose, per Xasoflux. Joefromrandb (talk) 08:51, 8 August 2017 (UTC)
  • Support while I haven't been involved in many editathons since I left WMUK, I have been involved in quite a few in the past. This userright would be useful in running such events, and it is a reasonable mitigation of ACTRIAL. I have seen attendees at such events not get the importance of having some reliable sources before they hit save, but most attendees create articles that meet our notability threshold, and I've never encountered a commercial spammer or a vandal at an editathon. More to the point, such articles created at editathons are almost always more encyclopaedic than the aspiring not yet professional model, musician or sportsperson who NPP is deluged with. ϢereSpielChequers 10:01, 8 August 2017 (UTC)
  • Oppose, I agree with Xasoflux and Kudpung, and, this imho is where draft process is for.ronazTalk! 10:18, 8 August 2017 (UTC)
  • Oppose Until there some kind of vetting policy for Account Creator, I can't see giving that user group that kind of power. Sario528 (talk) 11:59, 8 August 2017 (UTC)
  • Oppose Edit-a-thons & other wiki-events will be far more productive if they aim to develop new wikipedians who understand why wikipedia is the way it is and happen to have a specialist knowledge rather than incubating COI editors who will abandon the wiki as soon as the event is over and they encounter the real requirements of the wiki. The problem as outlined is more about how the event is conducted rather than about how ACTRIAL and Wikipedia operate.
Encouraging new editors by promoting their articles from userspace/draft rather than setting them up for a bruising review experience the next day will be more likely to encourage them to stay - and that is the purpose of these events, isn't it?
The objectives of the proposal would be better met by:
  • A template on the draft/article stating that it was produced as part of event, identifying the event's coordinator, categorising the article/draft into a maintenance category for the event, and requesting that during the event (start date & time, end date & time) it would be appreciated if all review action were focussed on helping the author grow as a wikipedian rather than cleanup.
  • An editnotice onthe draft/article to the same effect, with an expiry set for the event's end.
  • Getting Twinkle & Huggle to observe the event's template & refuse to add deletion tags during the event. Cabayi (talk) 11:57, 8 August 2017 (UTC)
  • Oppose - for the reasons stated by Chris Troutman, and BU Rob13. The draft process has a greater control aspect as to the quality of the work proposed. Kierzek (talk) 13:34, 8 August 2017 (UTC)
  • Oppose, users participating in edit-a-thons should experience the same Wikipedia processes as everyone else. (If my brother goes to an edit-a-thon and then tells me how he created an article, and I then I make an account but can't create an article, I will give up on Wikipedia right away). Also, edit-a-thons and other newbie-sirected activities should probably try to focus on editing existing articles. —Kusma (t·c) 13:38, 8 August 2017 (UTC)
  • Oppose per those in favor of using the draft space. Bending the rules for new users may have the opposite effect of what the edit-a-thons are trying to accomplish. May as well use the processes your typical new user has to use and adequately prepare them for what Wikipedia is really like. ZettaComposer (talk) 14:05, 8 August 2017 (UTC)
  • Oppose Primarily the reason being not all account creators are properly vetted. I do not feel autoconfirmed is a high bar and recommend reaching this bar stay in situ. While necessarily removing a hindrance, this also can be wrongfully abused, accidentally or not. --QEDK () 15:24, 8 August 2017 (UTC)
  • Support as temporary change during WP:ACTRIAL. Unless a large portion of the members of the account creator group suddenly decides to join the dark side en masse, I can't see how this can blow up in any meaningful way during a short trial period. I would however suggest combining this with somewhat greater circumspection in handing out the right (500/30 seems like a reasonable bar). --Elmidae (talk · contribs) 15:32, 8 August 2017 (UTC)
    • @Elmidae: That isn't possible, because we have people who aren't familiar with Wikipedia running edit-a-thons from an administrative perspective all the time. Do we bar such edit-a-thons from occurring? Moreover, the concern isn't "those evil account creators". I don't doubt our account creators act in good-faith. The concern is that they hand out the "confirmed" right to everyone participating in the edit-a-thon, and the edit-a-thon participants create articles not suited for mainspace. That happens all the time in connection with edit-a-thons. ~ Rob13Talk 15:54, 8 August 2017 (UTC)
      • @BU Rob13: My thinking is that any edit-a-thon participants of events held during the envisioned ACTRIAL period are unlikely to make much of a blip on the radar, compared to the usual flood of unsuitable creations. a) There wouldn't be all that many of them (don't have any stats - a couple of thousand people? I may be way off); b) as someone noted above, they are well-intentioned and at least somewhat supervised. So, I doubt much potential damage in total, compared to business as usual. Thus an evaluation of the effectiveness of ACTRIAL should still be very possible - and isn't that the main goal?
Regarding experience thresholds of edit-a-thon organizers - I was under the impression these would be somewhat seasoned users. If that's not generally the case, a high threshold for account creation rights wouldn't be sensible, of course. --Elmidae (talk · contribs) 19:04, 8 August 2017 (UTC)
  • The granting guidelines for ACC seem to be rather permissive at present, perhaps better to instruct coordinators on the process to request confirmed and try to have an administrator or two to keep an eye on the permission page during the event if the participants are expected to require 'confirmed'. –xenotalk 17:12, 8 August 2017 (UTC)
  • Oppose- it is what, four days and 10 edits? If someone is going to come onto WP, I think 4 days is a logical minimum to understand the ropes of article quality. Further, the 10 edits shouldn't even be an issue, as if the user is creating the article in the sandbox or similar space, they should make at least 10 edits in creating the article there. I don't think edit a thons deserve special treatment (though I'm not wholly familiar with what they are). And being a part of an edit a thon doesn't make someone more trustworthy. Summary - 4 days and 10 edits do not create undue hardship for anyone, and giving power to lift it arbitrarily because someone is part of some organization does not seem rational. Even if we trust the admin more than anything, how can they have any idea if the individual is trustworthy? Leave it be ‡ Єl Cid, Єl Caɱ̩peador ᐐT₳LKᐬ 19:23, 8 August 2017 (UTC)
  • Support as a temporary change per those above. JTP (talkcontribs) 21:16, 8 August 2017 (UTC)
  • Support If one of the goals of editathons is to bring in new editors and get them to write articles, making them potentially wait weeks to get their articles reviewed (and possibly shot down by a reviewer with really high standards anyway) is going to be really unsatisfying. The discussions on ACTRIAL happened before article-creation editathons were as frequent as they are now (in particular, WikiProject Women in Red didn't exist back then), and we need a measure like this to account for that change. TheCatalyst31 ReactionCreation 23:50, 8 August 2017 (UTC)
I literally just participated in a women in red editathon meetup and I have to say that there is no need for this. Everyone was working in the draft space anyway, it it was much better to review the articles myself before submitting them to namespace than to let the new users do it themselves (a result of some users working in the mainspace resulted in some articles getting prodded, and another article getting onto mainspace with copyright violations. These problems would have been avoided if these users needed help promoting their articles as the issues would have been flagged when doing so. — InsertCleverPhraseHere 00:02, 9 August 2017 (UTC)
  • Support during ACTRIAL. --joe deckertalk 01:29, 9 August 2017 (UTC)
    Comment I'd be far, far, more amenable to arguments that "let 'em use drafts" if we had a Draft review process that wasn't badly backlogged. --joe deckertalk 03:35, 11 August 2017 (UTC)
  • Neutral. Assigning any user right should be left in the hands of administrators. But, then again, aren't account creators supposed to have their identities confirmed by the foundation? With that being said, I'm torn on where I stand, given that the requirement to have account creators' identities confirmed by the foundation adds accountability. Steel1943 (talk) —Preceding undated comment added 01:40, 9 August 2017 (UTC)
    Account creators who work in the request an account process are identified, but the user right is more commonly handed out to event organizers, who need not be identified. Many of these organizers are new users who have not even reached extendedconfirmed yet. – Train2104 (t • c) 03:51, 9 August 2017 (UTC)
    I now oppose this proposal now that I know there is a group besides Administrators that can have the account creation permission other than Account Creators. Steel1943 (talk) 18:49, 9 August 2017 (UTC)
  • Question - Would implementing this proposal allow account creators to add existing accounts to the confirmed user group, or only allow for assigning this right during the creation of an account? I am inclined to support the latter but quite reserved on the former. Thank you.--John Cline (talk) 02:25, 9 August 2017 (UTC)
As far as I can tell, it would be the former, just like an admin can assign permissions to any user. – Train2104 (t • c) 03:58, 9 August 2017 (UTC)
  • Comment - It seems to me that supporting this as a temporary measure to mitigate the effects of ACTRIAL is tantamount with supporting a measure to reduce the value of the statistical data being assessed, and the trail itself. Am I wrong?--John Cline (talk) 05:48, 9 August 2017 (UTC)
    Comment I've been assuming that that the effects of this on the trial results would be insignificant, that new articles from these events do not make up anything like a signficant fraction of incoming articles from new editors. Am I mistaken? --joe deckertalk 15:00, 9 August 2017 (UTC)
Same here. Any numbers available on that? --Elmidae (talk · contribs) 16:54, 9 August 2017 (UTC)
  • Oppose. With Wikipedia's increasing maturity, the bar for article creation needs to be higher to maintain quality. Editathons seem too often to be a source of low quality article by newbies whose convenors are unwilling to criticize. Xxanthippe (talk) 06:06, 9 August 2017 (UTC).
  • Oppose Creating them in Draft adds extra work at the beginning for experienced users to review them but I feel that it will also allow to better guide new users and improve the quality of articles in main space. --Crystallizedcarbon (talk) 15:37, 9 August 2017 (UTC)
  • Oppose per Kudpung, xaosflux, Sitush, and many others above who have observed quite serious problems with the provision of the account creator userright and suitability for mainspace of articles created at these events. Draft space is the way to go for these events. Ivanvector (Talk/Edits) 16:45, 9 August 2017 (UTC)
  • Oppose. New editors should be encouraged to create drafts, and that's what editing event organizers should have them do anyway. I had people do that at an editing event I worked on and there were no issues with it at all, and a much reduced risk of having to field the question "Why does someone say my article should be deleted?". (Never happened.) Creating an article that's immediately mainspace ready is not something we should encourage new users to try, it's just likely to cause frustration on all sides. Seraphimblade Talk to me 17:10, 9 August 2017 (UTC)
  • Oppose Per BU Rob13. This just doesn't make sense. Let me get this straight, the community decided to increase the prerequisite for article creation from "nothing" to "4 days and 10 edits" (addendum, per Kaldari: for a trial run). But the WMF blocked this, and more than 6 years later they're just getting around to testing it? But they want to add the caveat where Account Creators, of all people, can exempt anyone as they see fit? What's even the point then, honestly? It seems like WMF is just trying to add a major loophole to something that they apparently disagree with enough to block a community decision for 6 years. As one of the admins involved at Requests for Permissions, I'll share something that not everyone may realize: Account Creator has fairly high requirements usually, including identification to the foundation, but it's also granted to basically anyone who says they need it for an event. These users may well just barely be autoconfirmed themselves. They're not some well-vetted, highly trusted class. They're literally random people, many of them inexperienced, who claimed they were running an event, and were permanently granted this flag (the ability to grant it temporarily finally exists, but it was only recently implemented). The task of revoking the flag from these users was reinforced by a community consensus, but it has yet be undertaken by admins, due it being a large, tedious and relatively unimportant task in an area where not many admins are involved. Anyway, if you're going to give Account Creators the ability to confirm accounts, you may as well give it to everyone. I just can't see the logic of delegating an administrative responsibility to a ragtag group of users who were rubber stamped. Swarm 18:09, 9 August 2017 (UTC)
    • @Swarm: I don't think the WMF is seeking this change; it's community members who for some reason think edit-a-thon participants going through AfC would be harmful (how? no clue). The WMF, if anything, would likely oppose this change because it would pollute the statistical results of the trial. ~ Rob13Talk 18:17, 9 August 2017 (UTC)
      • Rob, my impression is that the WMF has as one of its goals increasing new editors. I don't think @Kaldari and DannyH (WMF): and the Community Tech team have strong opinions either way on this. I believe Sadads who works in another WMF department was one of the first to bring this up as an issue. JMatazzoni (WMF) also probably has thoughts on this as his team more directly deals with editor retention, but I don't know what his thoughts are on it in terms of affecting the trial. The short: my impression is that different parts of the WMF are viewing ACTRIAL in different ways. There is definitely some support for something like this there, but there are likely others who oppose it for the reasons you pointed out. TonyBallioni (talk) 18:24, 9 August 2017 (UTC)
      • I see what you're saying about WMF not wanting to dilute the data, and that's certainly what you would think they would want. However, after the six-year delay in implementing this, a WMF employee's request for a major exemption for all outreach initiatives certainly does not give the appearance that they are actually supportive of this idea. I'm not saying Kaldari is disingenuously pursuing some sort of hidden agenda, and I think Tony's comment makes sense. I'm just pointing out that the ACTRIAL is such a modest change, and combined with the ridiculousness of this proposal (see my comments on ACCers above), which would gut it, the whole thing seems disingenuous. Swarm 18:57, 9 August 2017 (UTC)
        • @Swarm: With all due respect, much of what you said above is wrong. First, the community didn't decide to increase the prerequisite for article creation, they decided to request a trial of such a limitation. The WMF is now running that trial. The WMF doesn't want to add a caveat; the community expressed support for a very similar idea at Wikipedia talk:Autoconfirmed article creation trial#Supporting edit-a-thons and similar events. No one at the WMF has any strong opinions on this proposal (that I know of). If you don't want to AGF, that's fine, but I promise there's no conspiracy here. Kaldari (talk) 19:15, 9 August 2017 (UTC)
          • Again, I was not assuming bad faith, nor alleging some sort of conspiracy, and I expressly clarified that in my previous comment. Thank you, but I don't actually need assurances from WMF staff that there are no nefarious motives at play. I'm sure we can both agree that such a notion is a bit ridiculous. And I'll point out that that aspect of my comment was not even my reason for objecting. It was just an observation on how ridiculous this proposal looks, in the context of my perspective on Account Creators and my perceived significant ramifications for the ACTRIAL. Swarm 20:03, 9 August 2017 (UTC)
The Community Tech team is helping to support ACTRIAL as a research experiment, because it'll give us better information about how all these processes work. It's possible that restricting page creation to autoconfirmed users will drive new people away to an unacceptable extent, and we'll lose good editors and good content. But creating a new page and having it deleted within a couple hours is a terrible experience for new users, so it's possible that if we redirect them to the Article Wizard and Drafts, then they'll be more likely to stick around and learn how to edit. Opinions on both sides are pretty entrenched, and running this trial will help us all have informed discussions about it. So that's why Community Tech is working on this -- you can see the hypotheses and measures that we're working on at Research:ACTRIAL on Meta.
Running this trial has an impact on other people's work, so we want to minimize that if we can. People at the WMF who work with program leaders, like Sadads, want to make sure that people can run events successfully during the trial. We haven't actually looked at the experiment-pollution angle; we should see if we could get an estimate of the number of main namespace articles created in editathons, to see if it would make a difference to the statistical significance.
But this is a community decision; that's why Kaldari proposed this here. Running ACTRIAL isn't dependent on this decision; we've committed to running the experiment. -- DannyH (WMF) (talk) 19:18, 9 August 2017 (UTC)
Those are the events that bring in a bunch of (often conflicted) new contributors who are enabled by people who often don't have much experience themselves (honourable exceptions) or who share similar conflicts and want to steamroller over policy etc in order to get their way (per the link to my talk page right near the top). "More editors" seems to be the overarching mantra and it should not be. - Sitush (talk) 19:29, 9 August 2017 (UTC)
DannyH (WMF), how much research has been done into what type of editing productive long term users do when they first become active on Wikipedia, compared with the type of editing done by short term or single purpose editors whose work is largely unhelpful? Anecdotally, my impression is that the sort of editors on this page commentating on this (representative of the productive heart and core of Wikipedia), would not have started on Wikipedia by attempting to create a new article. While those editors who have started off by creating a new article, have tended to be those who have a vested interest in the subject they are introducing onto Wikipedia (and no real interest in editing on any other subject), and either disappear soon after they have created the article, or simply hang around to feed that article and none other. My anecdotal experience might well be shared by others on this page. We have spent a disproportionate amount of our time over the years, attempting to clean up messes created by users who are not interested in Wikipedia itself, but only in their particular subject appearing on Wikipedia. If WMF wishes to encourage new users, perhaps conduct research into what attracts productive users compared to what attracts disruptive or unhelpful users, and then work on attracting productive users while discouraging unproductive users. It seems to me, again purely anecdotally, that directing new users to go through an approved article creation procedure is likely to attract, develop and retain the sort of editor we want, while discouraging the sort of editor we don't want. SilkTork ✔Tea time 08:53, 11 August 2017 (UTC)
I'm not sure that I can agree with the implicit idea that only long-term users are desirable. However, you may be interested in a quick check that I did: The first (undeleted) edit for three of the current 22 bureaucrats was creating an article in the mainspace. Adding internal or external links (including adding a line to WP:Build the web to the linked article) was the most common first edit, and a couple fixed typos or similar small errors. Only two made major changes to an article. Two created their user pages, one moved a page (back then, you didn't have to be autoconfirmed to do that), one warned a spammer, one voted in a discussion, one expressed an opinion about a merge proposal on a talk page, and the other inserted an image to an article. So if you assume that bureaucrats are "productive, long-term users", then the answer seems to be: they did almost everything for their first edit.
There has been some research into the effect of sandboxes and draft space. Someone involved in that project will have more information, but the TLDR seems to be "Draftspace is where articles (and their creators) go do die". WhatamIdoing (talk) 22:11, 11 August 2017 (UTC)
  • Oppose, Whether via Edit-a-thons or not, articles created by non-autoconfirmed editors should go through AfC, or draft-to-AfC. Softlavender (talk) 22:29, 9 August 2017 (UTC)
  • Support Trim the list by all means, but this will help the trial not be skewed.L3X1 (distænt write) )evidence( 22:58, 9 August 2017 (UTC)
  • Oppose - in my opinion, Edit-a-thons ought to focus on editing instead of article creation, especially if the editors are so inexperienced that they are not even autoconfirmed. And I think the ability to add a user right necessitates the ability to remove that user right, which this proposal does not address.--John Cline (talk) 23:40, 9 August 2017 (UTC)
  • Support for a number of reasons - if the purpose of opposing is to force new people into AFC/Draft process thats is nothing but a power trip to many of the reviewers with expectations of content being GA/FP ready. I always encourage new editors to ignore that process, just we did when we started editing its a learning curve becuase its almost certain negative experience. The big issues at editathons isnt so much the creation of new articles but rather that every edit the user gets a captcha thats really unproductive especially as new editors in a workshop are being supervised anyway. There is already a limit on the number of accounts an IP can create so generally need an account creator or an admin, having run workshops for most of the last 10 years as an admin I actually prefer to edit user rights as auto confirmed so that I can capture the new editors usernames and monitor post event whether they return, what issues they run into, review their edits, and generally keep in contact. Gnangarra 00:24, 10 August 2017 (UTC)
The captcha argument is the most convincing argument I've seen here (as it really is very disruptive to new users at meetups). AfC also does sometimes require far too much of new articles. However, the arguments that this change would undermine ACTRIAL, as well as the fact that there are so many users that currently have account creator rights that clearly shouldn't have the ability to do what is proposed here are stopping me from changing my !vote. — InsertCleverPhraseHere (or here) 18:40, 10 August 2017 (UTC)
  • Oppose On the theory that the current system works reasonably well. If an editor feels that the confirmed right is needed, it can be requested through an admin at WP:PERM. Dolotta (talk) 00:33, 10 August 2017 (UTC)
  • Oppose during ACTRIAL, Support a trial run afterwards if we decide to go forward with ACTRIAL changes. One experiment at a time, please. DaßWölf 01:29, 10 August 2017 (UTC)
  • Oppose as proposed. Kudpung has presented a number of reasons. In brief, too much chance of trouble that will be hard and/or long to undo. Let them create in draftspace. — No stance on experimenting in a more controlled and limited way. --Thnidu (talk) 04:56, 10 August 2017 (UTC)
  • Oppose Per Timotheus Canens and Xaosflux. Way too many users with the ACC flag, in my opinion, that list needs to be pruned by about 300 users and a vetting process for the flag needs to be hammered out. - FlightTime (open channel) 07:10, 10 August 2017 (UTC)
  • Oppose I'm generally uncomfortable with tool unbundling, but this is just a bad idea. As many people above me have stated, giving relatively new editors (and yes, we do hand out Account Creator to almost new accounts who are perhaps running an editathon) the ability to not only bypass ACTRIAL themselves, but to allow the rest of their group to do it too. I also fail to see how articles created at these events are automatically legitimate new article[s] - does being at an editathon just magically make you an experienced editor? There's the implied understanding that perhaps these participants have been given training, but that's entirely down to the organisers. -- There'sNoTime (to explain) 07:35, 10 August 2017 (UTC)
  • Oppose per Xaosflux, Kudpung, Sitush, SilkTork and others. Callanecc (talkcontribslogs) 08:46, 10 August 2017 (UTC)
  • Oppose per Swarm and several others. I can add that I took a quick look at the 50 or so first names on the list of users with the "account creator" right, and found a whole bunch of users who aren't even autoconfirmed themselves (several of them have only two or three edits of their own...), but would still be given the right to autoconfirm other users if this proposal passes... - Tom | Thomas.W talk 17:22, 10 August 2017 (UTC)
    • Worth mentioning that they could autoconfirm themselves and any socks they wanted to create (should they not actually be running an editathon shock horror) -- There'sNoTime (to explain) 17:37, 10 August 2017 (UTC)
  • Oppose As per SilkTork and many others. We must continue to encourage the fact that anyone can edit Wikipedia, but we must be cognizant that not everyone can simply jump in without learning policies and processes. High quality standards have taken years of collaborative effort to create and changing this will undermine a lot of that effort. Spacini (talk) 18:13, 10 August 2017 (UTC)
  • Oppose per Kudpung amongst others. (((The Quixotic Potato))) (talk) 19:29, 10 August 2017 (UTC)
  • Oppose I'm not so enthusiastic about the qualities of newly created articles by non-confirmed users. — JudeccaXIII (talk) 19:50, 10 August 2017 (UTC)
  • Oppose per @Train2104: way up above. If anything, this flag needs to be tightened, not loosened in any way. GenQuest "Talk to Me" 21:41, 10 August 2017 (UTC)
  • Oppose - My reasoning is the same as many of the other editors on this page. All Wikipedians should go through the same processes when joining the website, regardless of the circumstance. The drafting process, in addition to vetting some of the more incomprehensible work that's produced, can serve as an important teaching moment for newer users. Those who are committed to collaborating on Wikipedia will hopefully have the patience to learn from that experience. The only real problem I see here is that new editors unable to directly publish their work might feel discouraged (like they aren't truly editing the encyclopedia "anyone can edit") from the onset and never bother sticking around. But if an editor is committed and goes through with the processes they will almost certainly come out of it more competent than their peers. So I say its worth it if we break a few eggs if that keeps the one-time contributors with their "drive-by" articles under proper supervision. Lastly, I think that this proposal would undermine ACTRIAL and its effects, which would by extension undermine the research that's to be conducted. -Indy beetle (talk) 06:54, 11 August 2017 (UTC)
  • Oppose. My early thought on this were to support, but I declined to comment for a few days until some of the arguments for and against had been brought up. Now that I read them I'm swayed the other way. Optimist on the run (talk) 09:54, 11 August 2017 (UTC)
  • Oppose - As per Swarm, I do not think it is a good idea. Adityavagarwal (talk) 12:52, 11 August 2017 (UTC)
  • Oppose - As per SilkTork, in addition I feel that this proposal would undermine the research that is being conducted with regards to ACTRIAL --Imminent77 (talk) 13:45, 11 August 2017 (UTC)
  • Oppose - Per many others, allowing many new editors to obtain confirmed status is a dangerous prospect. Edithons are a good thing, but they also overload editors like myself that cruise the new page feed. Diverting traffic through our existing system of drafts is the best way to do things. SamHolt6 (talk) 16:54, 11 August 2017 (UTC)
  • Oppose - encouraging new editors to jump into creation causes more problems than it solves. I am a case in point. Let them cut their teeth on the million plus articles that have problems, so they don't create more. Rhadow (talk) 19:44, 11 August 2017 (UTC)
  • Oppose per many editors here (too many to name) - If newbies want to create articles we have drafts which is more than sufficient - I see no valid reason as to why we should allow account creators to go on a mass-adding spree especially when most (judging by the link by Xaosflux) shouldn't even be account creators anyway!. –Davey2010Talk 21:43, 11 August 2017 (UTC)
  • Oppose: it would be a big security risk, especially as many of the account creators are inactive. Esquivalience (talk) 22:34, 12 August 2017 (UTC)
  • Support as a temporary change during ACTRIAL: This will be a major help during edit-a-thons, which are already guided environments. Sayan rc (talk) 13:57, 13 August 2017 (UTC)
  • @Sayan rc: The right to auto-confirm other users, and even themselves and whatever socks they might create, isn't a temporary right connected to a certain event, so it wouldn't be limited to just whatever edit-a-thon they were to take part in but would be a "full-time" right that they can use as they want, whenever they want to, and would also be given to several hundred existing user accounts that haven't been screened at all... - Tom | Thomas.W talk 14:16, 13 August 2017 (UTC)
  • oppose new editors should put articles through AfC - there is no shame in that, and there appears to be an underlying assumption that there is. Doing that does not harm editathons in any way, and actually helps teach new users to respect that they are new and learning and that it takes time to understand the policies and guidelines that allow WP articles to realize the mission of providing high quality articles summarizing accepted knowledge to the public. There is a learning curve. Not impossible to travel up, but there.
On a further note, once permissions are given it is often very hard to take them back, and i do not think it is wise to add this particular permission to this particular class of users.
A better way to manage the trial, if an editathon organizer really wants to give participants the immediate gratification of seeing their work published, would be to recruit independent article reviewers to participate in real time, which also would be helpful in teaching new users how to interact with independent community members. Jytdog (talk) 18:54, 13 August 2017 (UTC)
  • Oppose: It doesn't help as it can be workaround. I think we can work out a better measure to support edits. Also could be harmful for less developed Wikipedias in other languages take this action. MaoGo (talk) 16:06, 14 August 2017 (UTC)
  • CommentSupport: Does this proposal affect the 500/30 rule? If so, I'm against it because it is not fair to allow some but not all people to circumvent that process. Otherwise, I'm in favor. ImTheIP (talk) 18:14, 14 August 2017 (UTC)
    @ImTheIP: no, this would not allow adding "extended confirmed". It would allow bypassing the "10/4" autoconfirmed period only. — xaosflux Talk 02:23, 15 August 2017 (UTC)
  • Comment I think all of the opposed (and my currently ambivalent self) would feel better if this "trial period" (as others have suggested) is transparent to confirmed users without account creation rights. Apologies for my prepossession if it already is. :/--Monochrome_Monitor 19:59, 14 August 2017 (UTC)
  • For reference, here's a histogram of account creators by age and edit count. As stated above, I can't support this right when this chart looks like this.
    Data as of August 14, 2017 23:15 UTC
    – Train2104 (t • c) 23:40, 14 August 2017 (UTC)
    @Train2104:How do people with less than 100 edits get creation rights? That histogram is very concerning. It's quite the opposite of a normal distribution.--Monochrome_Monitor 01:36, 15 August 2017 (UTC)
    @Monochrome Monitor: in short: this permission is given out a few basic ways: (a) For editors actively working in the WP:ACC program, (b) For editors doing work in the Education program, (c) By request (typically short term for specific events) at WP:PERM, and (d) Ad-hoc by any admin, presumably in support of general community standards. If the standards need better definition or a change, a discussion for what works best may be needed. — xaosflux Talk 10:59, 15 August 2017 (UTC)
  • Support. This is more than about the drafts process. The purpose of autoconfirmed is to filter out potential abuse from newly registered accounts, mainly socking. Confirmed / autoconfirmed merely means "based on personal acquaintance or track record, we trust that this account is operated by a well-meaning human being". As an admin who regularly grants confirmed status at editathons so new editors can move pages and edit semi-protected pages, I am persuaded that if a user is trusted enough to be given accountcreator rights, they should be trusted enough to give new users confirmed rights. If this opens up the possibility of demoting accountcreators, well, that means the system worked. Deryck C. 11:06, 15 August 2017 (UTC)
  • Comment The ability to grant confirmed status to a new user during edit-a-thons and similar events could be helpful, if in the right hands. I have been watching this for a while, and Deryck finally convinced me that it could work. My previous main concern was the potential abuse of this privilege by inexperienced users (such as myself) that happen to have been granted this option. The user group in question, that of account creators, is a fairly small one. Yet its impact is quite large, and apparently a large portion of current account creators may not be trustworthy with this proposed ability. I apologise beforehand if the following question has been brought up and turned down before, but why not create a new user group: "account confirmers", with stricter criteria for acceptance? Inatan (talk) 17:51, 15 August 2017 (UTC)
  • Oppose: Creators of new articles should be experienced Wikipedians. I am suspicious about edithons anyway. Zezen (talk) 22:33, 15 August 2017 (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.

Upgrade WP:DRAFTIFY to policy or guideline and disallow moves to Draft- or userspace without discussion or consent

Since it's been pointed out to me that currently a number of editors believe in draftifying articles without prior discussion or request/consent (see previous discussions here and here for example), I hereby suggest that the WP:DRAFTIFY portion of WP:Drafts is given the status of policy (or at least guideline) and that it's clarified that moves that are not the result of i) a deletion discussion, ii) an undeletion request, or iii) userfication [upon request] are not allowed, except by an admin as an alternative to speedy deletion (provided the article could have been deleted otherwise).

The reasoning is this: Such moves circumvent the deletion policy by removing articles from mainspace without either discussion at WP:AFD or applicability of WP:CSD. Just as admins are not allowed to outright delete such articles if they don't fall under WP:CSD, so other users shouldn't be allowed to "pseudo"-delete them by removing them from mainspace without prior discussion. While such drafts might still be available (until deleted under a new G13 as proposed after six months), they are removed from the public eye, the result is thus the same as with outright deletion. Also, such moves usually violate WP:IMPERFECT and WP:PRESERVE, since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted.

While I understand that some editors feel that they are actually helping the project by draftifying content that would otherwise be deleted, allowing such moves without prior discussion is too risky, especially if G13 is expanded to allow deletion of all pages in Draft: space just based on age. Regards SoWhy 13:02, 8 August 2017 (UTC)

IMO, any speedy deletable content may be draftified; if it's subsequently deleted under G13, it can be REFUNDed by request of a user who intends to work on it. עוד מישהו Od Mishehu 13:09, 8 August 2017 (UTC)
This proposal is about content that is not speedy deletable. I won't argue that we shouldn't draftify instead of deletion. I've clarified it above. Regards SoWhy 13:13, 8 August 2017 (UTC)
Actually, it isn't. This proposal specifically disallows draftification as an option to non-admins even when speedy deletion criteria apply. — InsertCleverPhraseHere 14:57, 8 August 2017 (UTC)
If an article is about a clearly notable topic, but is so appallingly written that it shouldn't be visible to readers of the encyclopedia in its current form, then moving to draft space is a sensible move until it can be fixed. Peter coxhead (talk) 13:17, 8 August 2017 (UTC)
@SoWhy: I'd recommend waiting on the close for the current discussion to expand G13 before we discuss this. My opinion would change based on whether we'd be retaining these drafts indefinitely or not. ~ Rob13Talk 13:17, 8 August 2017 (UTC)
Unfortunately, the current proposal does not make an exception for such drafts, which is the reason I brought this here in the first place. Regards SoWhy 13:38, 8 August 2017 (UTC)
@SoWhy: I'm not sure exactly what you mean. My point is that if G13 is not expanded and draftifying stuff means indefinitely retaining something unsuited for mainspace, I'd oppose this. If it is expanded, I would need to think on it more, but I'm leaning support. ~ Rob13Talk 15:51, 8 August 2017 (UTC)
  • Oppose PRESERVE says nothing about this (or deletion, by the way), and anyway we have WP:DON'T PRESERVE right below it that points out when removal may be appropriate. While I appreciate SoWhy's concerns, I think they are very far removed from the practical use of this tool and also would serve to create a distinction between admins and non-admins on the use of the move tool. The content that I move to draft is either 100% in violation of WP:V, is speedy deletable, or is an abandoned article that is so poorly formatted with few sources to the point where it would be likely PRODed or CSD tagged and deleted regardless of the actual content in it. Moving content like this to draft to give the user time to improve it rather than taking to to AfD, or PRODing It, or CSD tagging it is the definition of not biting newcomers and BOLDly improving the encyclopedia rather than letting it sit and rot in main space or be deleted. TonyBallioni (talk) 13:21, 8 August 2017 (UTC)
Both WP:DEL and WP:DPR are quite clear on how articles can be deleted: CSD, PROD or AFD. Moving to draft-space? Not on that list. In fact, WP:DPR explicitly mentions it as a potential outcome of a deletion discussion. Saying you move content that is a violation of WP:V or because it's poorly formatted is basically my point: Both are either fixable - then per WP:IMPERFECT they should stay - or they are not - then what's the point of moving it to Draft-space? After all, doesn't policy say Even poor articles, if they can be improved, are welcome.? Regards SoWhy 13:38, 8 August 2017 (UTC)
SoWhy, except draftification is the exact opposite of deletion, which is why it has no business being in the deletion policy. As for WP:V: if there is a two sentence stub about a village with nice palm trees in Foo that searching provides no sourcing and is completely inappropriate for mainspace there are three options: blank and redirect, PROD, or send to draft. Draft:Cantabaco is an example of the type of article that would easily be deleted via PROD for failure of WP:V, but is notable as a named placed and the author should be given more time to update it. Sending it to draft is much better than either redirecting or PRODing.
We also get articles such as Draft:Nerds On Ice that would be G2 eligible. Also ones like Draft:Loctote that were apparently AfC submissions that were accidentally created in mainspace. I can go through countless other examples, but draftification is actually a major tool in upholding WP:PRESERVE, a policy I know you care deeply about. TonyBallioni (talk) 14:00, 8 August 2017 (UTC)
It removes articles from sight, so how is it different from the reader's point of view? As for your examples: If it's a village, WP:GEOLAND says it's notable, so remove the incoherent stuff and leave it in mainspace. The second is an AFD submission in mainspace, not an example of draftifying. The third example is not really something to be proud of. Draftifying within seconds of creation? Most likely the user was working on it but when they were done, the page was gone and they left the project for good. Regards SoWhy 14:21, 8 August 2017 (UTC)
Except that notability isn't the issue. Of course it was notable, the question is whether or not we should delete a notable article that fails our most central content policy (per WP:DEL7) or whether we should give the author time to develop it. I vote for giving the author more time to develop it. Re: Draft:Nerds On Ice, the creator was clearly trying to create a draft article and moving it to the right namespace for them to have that opportunity is already anticipated by WP:PM/C#3. Its the exact same as the AfC submission above, and if it weren't draftified it would have been deleted within minutes via G2 by someone who is much less conservative than I am on G2. I was acting quickly to prevent deletion because the front of the feed is where overtagging for CSD is most common. I'm also pinging Boleyn, who is one of our best and most dedicated reviewers, as a courtesy since you used an article she touched as an example below. TonyBallioni (talk) 14:29, 8 August 2017 (UTC)
But that's the point, isn't it? If the subject is a geographic location, source will exist. So why move to Draft when you could easily spend five seconds on GBooks and add a source? Doesn't that violate WP:FIXTHEPROBLEM? After all, this is a project that strives on collaboration, so why should any one editor be responsible to "develop it"? ICPH bemoans below that "tag bombing" is not the correct solution but how is moving stuff out of sight any different? Both imply that it's somebody else's problem when in fact it's ours. And leaving it in mainspace at least allows others to fix it. Regards SoWhy 15:52, 8 August 2017 (UTC)
SoWhy, the issue is as ICPH points out below that no one fixes it, and per WP:CANTFIX when this is the case it might justify removal from article space. Most of these types of articles require knowledge beyond a simple Google Book search to fix the problem: I know absolutely nothing about the Philippines, and that Google Book search told me nothing that was of use in verifying the content in the article or in creating what you would expect for a geographic article. I assume the article creator will know enough about the article to find sources and improve it and then move it to mainspace. Draft space is a much better place to do this. This is similar to when I remove CSD tags I leave a note for the nominator rather than sending it to AfD myself if I think it should be deleted: I assume the first person who spots the issue is going to be better at explaining their reasoning than I am, and giving them the space to do it is important. I think this principle applies even more for content that someone who isn't a generalist wouldn't be able to verify. TonyBallioni (talk) 16:13, 8 August 2017 (UTC)
(edit conflict) SoWhy. Editor discretion is what is needed to decide the appropriate action in each specific case, not a top-down ban of draftification. If it looks like the editor might keep working on it, I'd draftify an article rather than leave it to get PRODed or worse by another less-kind patroller. A big deletion notice tends to discourage editing... why bother if it is going to be deleted anyway? but draftification with a message indicating how the problems can be solved can encourage further editing. Generally the only editors that see stuff in the New pages feed are patrollers anyway, as these articles are not indexed, so either you are suggesting A) we should tag bomb articles and then mark them as reviewed and hope for the best in 'the wild', or B) that NPP has an obligation to improve every half-baked article with a potentially notable subject that comes into the feed to an acceptable standard, regardless of how bad it is.
All of this supposes whether we are sure that the subject even is or is not notable. In many cases the subject is a two line article with a couple crappy blog sources about some Pakistani actress that may or may not be notable, and all the potential sources are not in english. Or else it is a single sentence article on a long dead scottish playright with one dubious cite to an offline source that may or may not be reliable, or can't be confirmed to exist, and where most other likely sources are offline as well. These sorts of grey area examples are where draftification is often a very good fit, and NPP often is not black and white the way you want it to be. — InsertCleverPhraseHere 16:22, 8 August 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── I think there is some misunderstanding here. I don't oppose draftifying per se, in fact, I believe it to be a good alternative to deletion where possible. What I do object to is unilateral draftifying, one editor deciding an article is not worthy of inclusion or not fit for inclusion even when it would not be deleted at AFD and speedy deletion is not applicable. The current practice relies on a single editor (sometimes with an user right he got from a single admin (w/o discussion usually)) making the "right" call, often the same people who are unable to apply speedy deletion tags correctly. I know NPP is not black and white, I was a NPPer once as well (nine years ago...damn, now I feel old). But I also know that clear rules are extremely important in this area because these are the editors most newbies encounter first and thus whose actions will have a lasting impact. That's why CSD is so strict and that's why draftifying needs to have strict rules too. And just like CSD it's dangerous if there is not a second pair of eyes forced to check each action. I can think of a lot of alternatives, from allowing AFD nominations with the intent to draftify to a PROD-like system (draftify after seven days if no one objects) but in all cases it needs to be clear that draftifying is only an option if the article were otherwise deleted without a doubt. It can't be (as it has become for some) a way to push sub-standard articles out of mainspace. I welcome any wording suggestions. Regards SoWhy 17:37, 8 August 2017 (UTC)
  • Oppose Draftification is useful. It is often more appropriate, and less BITEy to retain a badly written article for further work as a draft than any other option available to NPP (tag bombing or various deletion options). This proposal seems to specifically only allow admins to draftify articles (even when speedy deletion criteria apply). This would mean that non-admin NPPatrollers would need a whole new system in place to tag articles for draftification instead of CSD if this was their preferred choice. Without some other whole level of tagging that would need to be implemented with the Page Curation tool (good luck getting the WMF to work on this in a timely manner) this proposal would essentially hogtie non-admin NPP into proposing deletion or tag bombing and would remove the option for Draftification from non-admin NPP altogether. — InsertCleverPhraseHere 13:35, 8 August 2017 (UTC)
Speedy deletion uses a four-eyes-principle for a reason: One user tags, an admin (usually) reviews and decides. Unilateral draftification is like speedy deletion without the second pair of eyes. Considering how many things are tagged for speedy deletion incorrectly, one can easily guess how many articles are moved to draft-space that shouldn't be without anyone ever noticing. Why should NPPers who are not allowed to delete pages, be allowed to "pseudo"-delete them in such a manner? Why bother about WP:CSD at all if you can just move everything out of sight? Regards SoWhy 13:43, 8 August 2017 (UTC)
No one is suggesting 'moving everything out of sight', most problem articles are still clearly best served by other options, but it is the best option for some new articles. The only users that can move articles without a CSD on the redirect (i.e. without oversight) are admins and page movers. Policy reflects current practice, not the other way around. What I see is this: Wikipedia:New_pages_patrol#Drafts, as the current accepted practice of draftification as it relates to NPP. If you want to see a change to the current implimentation, I would suggest starting over at NPP rather than trying to pull the rug out from underneath patrollers that are simply trying to find the best solution for each individual problem (and draftification often is the best solution). I don't object to a proposed draftification tag, or something similar being added to the Page Curation Tool, but I wouldn't hold my breath: a proposal to add draftification to the PC tool has been on the list for over 10 months already. — InsertCleverPhraseHere 14:05, 8 August 2017 (UTC)
The problem is not what someone is suggesting or not, it's what is possible at the moment. What policy is stopping someone with "an agenda" from moving thousands of articles to draft? Articles such as Siamese buffalo don't belong in Draft: space, yet there they were. Saying something is current practice does not make it right. In fact, that it is current practice is the reason I proposed this change in the first place. Regards SoWhy 14:14, 8 August 2017 (UTC)
No doubt people make mistakes (though I'd point out that the article you linked above was named Krabue buffalo at the time, so this particular mistake was understandable given there was also no refs for verification at the time). Admins also make mistakes and delete articles that clearly shouldn't be deleted as well (i.e. Speed Langworthy as a recent example that I dealt with the aftermath of), but you don't see me advocating completely taking away admins' power to delete articles do you? I don't object to a clarification as to when draftification is appropriate and when it is not; this would be useful to NPP. I object to your proposal for several reasons that I have stated above. It is unnecessarily restrictive to non-admins and destroys the usefulness of draftification entirely by essentially making it not allowed except as admin discretion during CSD, and removes a useful tool from NPP when we need all the help we can get at the moment. — InsertCleverPhraseHere 14:34, 8 August 2017 (UTC)
Lets also not forget that we have WP:ACTRIAL coming up soon as well, which will essentially mean that all new articles not from autoconfirmed editiors will be essentially forced to use the draft space anyway. It seems to me that you are trying to force the rigid rules of deletion policy on a system that needs flexibility now more than ever. — InsertCleverPhraseHere 14:38, 8 August 2017 (UTC)
@Insertcleverphrasehere: To my knowledge there has never been a consensus amongst NPPers about draftification. Wikipedia:New_pages_patrol#Drafts was inserted recently and isn't the result of any prior discussion as far as I'm aware. Draftifying has crept in because individual users have decided it's a good idea (which is fine), but when it has actually come up in a discussion there have been objections to it. In my opinion SoWhy is absolutely right to seek a wider consensus on this issue. Even if there were a prior consensus amongst NPPers (and again, I don't see one), WP:LOCALCONSENSUS applies. – Joe (talk) 15:05, 8 August 2017 (UTC)
I never claimed any consensus. However, this is how draftifaction is currently implemented by patrollers, both in the tutorial for NPP (for the last 10 months) and in practice as I experience it 'at the coal face' so-to-speak. No offence meant here, but if you had actually done a bit more coal digging yourself you might understand the usefulness of draftification. I respect SoWhy, and I don't dissagree with his seeking wider consensus about the future of draftification (I agree that we need clarification on the dos and don'ts). However, I think that the current proposal is misguided and both of you seem to not quite get why so many experienced patrollers find draftification to be a useful tool in many cases. — InsertCleverPhraseHere 15:29, 8 August 2017 (UTC)
I've never claimed to be a very active patroller, but I wasn't aware that was a requirement for having an opinion on policy. I have been doing AfC reviewing and WikiProject new article monitoring for over five years, if that counts. Not all patrollers agree with draftifying, as you well know, which is why it's disingenuous to declare it the status quo and argue that "policy reflects current practice". That we don't get why draftification is useful is exactly the point: none of the oppose !voters have been able to explain why it's useful beyond that fact that they WP:DONTLIKE the established processes for deletion and cleanup (i.e. "tag bombing"). – Joe (talk) 18:25, 8 August 2017 (UTC)
I presented an argument below. RileyBugz会話投稿記録 18:56, 8 August 2017 (UTC)
I moved Siamese buffalo to draft for very good reason. My edit summary was 'unref sub-stub with no clear indication of notability. Please move back to mainspace when it's ready.' However, that was only part of it, I had spent several hours over weeks on that editor's unreferenced and unclear articles, and was finding no evidence that some were subspecies at all, rather than just, for instance, buffalo in Thailand. The editor had repeatedly refused to communicate and been warned about his behaviour by more than one editor on several occasions. I was hoping that moving to draft would stop us propagating something unverified, as well as encouraging the editor to stop the constant stream of unclear, unreferenced one-line articles. Boleyn (talk) 06:29, 9 August 2017 (UTC)
  • Strong support. I've noticed the draftification trend creeping in for some time now (e.g. perennial requests to make it a built-in feature of the Page Curation tool), so thank you for finally opening it up to a wider community discussion. I understand why superficially draftifying seems an attractive option when faced with tough calls at WP:NPP, but for me it is a very bad solution for two reasons. The first is that it is a form of "soft" deletion. Brand new editors are not going to understand that they have the right to move it back to mainspace if they disagree, and if they aren't autoconfirmed they won't have the technical ability to. In all likelihood most draftified articles are going to hang around in draftspace for six months (possibly bouncing back and forth to AfC a few times first) until they're G13'd six months later. The end result is that an article is deleted based on a single editor's opinion. This flies in the face of Wikipedia:Deletion policy, which requires a broad consensus at AfD, or at least, in in a small number of well-defined circumstances previously established by broad consensus (i.e. CSD and PROD), the agreement of the nominator and an administrator. Proponents contend that the deletion processes are more bitey than draftifying, but what would you prefer: a prompt and clear message that unfortunately your contribution is not suitable for Wikipedia; or being kept in limbo for six months whilst you struggle to jump through the hoops given to you in vaguely worded templated messages, until you give up and it's summarily deleted anyway?
My second objection is that any purpose draftifying might serve is pre-empted by WP:IMPERFECT. Although many NPPers and AfC reviewers seem to think otherwise, there is no minimum quality standard required for articles to exist. If the subject is not suitable for inclusion, you should nominate it for deletion via AfD, PROD, or CSD. If the subject is suitable for inclusion, you should do as much cleanup as you fancy, and tag the rest for someone else to do at a later date. Poor articles on suitable subjects are much more likely to be improved in mainspace than hidden away as drafts. – Joe (talk) 14:46, 8 August 2017 (UTC)
  • Oppose - This makes it so that users don't have to go through a stressful deletion process. It makes it so that, if I find an unsourced science article with lots of jargon while looking at new pages, I can give the creator the opportunity to improve it. More accurately, I can make it more likely that the creator will improve it so that when they move it to the mainspace, they don't have to worry about it being moved back to draftspace. This does violate WP:PRESERVE, but, as stated in the banner at the top of the page, "It describes a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus." (emphasis mine) This shows that the nature of policy is to describe standard, accepted practice. Thus, we should follow standard practice when we know it, and policy when we don't. This, of course, is overruled by ignore all rules. Anyways, standard practice is to draftify these things instead of having a tag sitting on top of an article forever, with the problem never being fixed. RileyBugz会話投稿記録 14:52, 8 August 2017 (UTC)
Also, we don't need more bureaucracy to slow us down. RileyBugz会話投稿記録 14:53, 8 August 2017 (UTC)
@RileyBugz: Your examples, like so many of the explanations I've seen people give for draftifying, don't appear to me to match policy at all. Why would deleting an "unsourced science article with lots of jargon" even be on the table? As long as it's viable subject, you can tag it with {{unreferenced}} and {{jargon}} at all. Why do you think it has to be in draftspace to be improved? Can't it be improved in mainspace? What if the creator can't or doesn't know how to move it to draftspace, and just gives up instead? – Joe (talk) 14:57, 8 August 2017 (UTC)
I do it because nobody would fix it otherwise. And besides, I move it to draftspace, and then leave a note describing to the creator 1. that I did it 2. where they can find it 3. how they can move it out when they are done. To answer not matching policy, isn't this for discussing policy? RileyBugz会話投稿記録 14:59, 8 August 2017 (UTC)
How is you moving it to draftspace "fixing it"? How is it different from "tag bombing"? In both cases the problem persists, however, in case of draftifying it's now out of sight of "common" editors who might stumble upon it otherwise and fix it. Regards SoWhy 15:57, 8 August 2017 (UTC)
First off, I never said that it was fixing it. What moving the page to draft does is keep a potentially bad page off the mainspace while allowing the creator to easily improve it. Overall, it is a win-win, even if the page wouldn't be deleted by an AfD. Also, I want to present another argument. This rests on the fact that 1. tag bombing is bad, as it is BITE-y and doesn't fix much 2. Not doing anything to an article is slightly bad, as it significantly decreases the chance that somebody will fix the problem, although it does not help BITE the creators or anything. 3. Draftifying is slightly positive in terms of the fact that it helps encourage creators to actually fix their page but slightly negative in that it is a bit BITE-y. This makes Draftifying a neutral process. 4. AfDing an article is the best, as it encourages people to fix it, although in some cases (such as for an unreferenced article with lots of scientific jargon), the fact that people would not have an incentive to clean it up (as they would vote keep no matter what, as you don't have to save it from deletion) makes the BITE factor of AfD outweigh the cleanup part. If we follow this model, we can see that, in some cases, Draftifying is the best idea. RileyBugz会話投稿記録 16:50, 8 August 2017 (UTC)
Tag bombing is NOT the universal solution that you seem to think it is Joe. We currently have 206,011 articles tagged with 'unreferenced' and 320,706 articles tagged with 'needs additional references' on EN wiki. — InsertCleverPhraseHere 15:10, 8 August 2017 (UTC)
@Insertcleverphrasehere: And? – Joe (talk) 18:25, 8 August 2017 (UTC)
I thought my point was clear, but here you go: my point is that tags do next to nothing in many cases. A quick look at Category:Articles_lacking_sources will reveal that there are many articles without sources there that have remained unsourced since 2006. — InsertCleverPhraseHere 20:43, 8 August 2017 (UTC)
"I do it because nobody would fix it otherwise." RileyBugz, I heard recently (but don't have a link) that there's been the effect of putting a page in draftspace. One conclusion: articles in the mainspace are far more likely to be improved than articles in draftspace or userspace. If your main goal is more like "hide imperfect articles from readers", then moving them to draftspace is fairly effective. If your main goal is to get articles improved, then moving them to draftspace is counter-productive. They will get fewer edits and less improvement. Moving the articles to draftspace with a message seems plausible (you're basically trying to bribe the initial editor to make extra efforts, in return for a promised 'reward' of some AFC regular eventually moving the article back in the mainspace), but it doesn't actually work. WhatamIdoing (talk) 02:33, 9 August 2017 (UTC)
  • Oppose: draftifying a new user's article is sometimes better than a long deletion discussion because it is less bite-y and less bureaucratic. For the most part, I trust the discretion of new page reviewers and draftifying is a legitimate alternative to tagging which requires no discussion. I've not witnessed any draftification wars so I think this solution is probably unnecessary. DrStrauss talk 15:04, 8 August 2017 (UTC)
  • Suggest drafting a guideline. I'm seeing good arguments from both sides. At the moment the discussion seems to be leaning "opposed" to flat prohibition on draftification. However I think there is implicit support for a guideline to clarify what is or isn't appropriate. I'm personally leaning to the position that draftification could be a good option, at least in some circumstances. Given the uncertainty here, it would probably be best to draft different levels of allowance/prohibition. Then an RFC can more clearly sort out what we want. Alsee (talk) 15:39, 8 August 2017 (UTC)
Alsee, agreed. I think this is a good solution, and long overdue. One suggestion that I have is that we should have a specific CSD template made up that is to be used on the redirect by patrollers who have draftified articles without admin or pagemover rights. This will tip off admins to review the decision to draftify and check whether the choice was correct when compared to whatever we decide are the acceptable limits of draftification. I think that page movers can be trusted to generally work without a second set of eyes and follow whatever guidelines we decide upon, given the requirements of that user-right, though I suppose this point is debatable. — InsertCleverPhraseHere 15:53, 8 August 2017 (UTC)
  • Oppose. If speedily deletion remains possible, then the lesser recourse of speedy draftification must remain possible. bd2412 T 19:04, 8 August 2017 (UTC)
  • Support It is our policy that "Even poor articles, if they can be improved, are welcome." Pushing an article into draft space is not welcoming. If it is done without leaving a redirect, as I've seen happening then it is effectively deletion by stealth – exploiting a loophole to subvert all our deletion policies. This loophole should be closed. If it isn't then you're going to see move warring and article recreations causing chaos and confusion. Andrew D. (talk) 19:14, 8 August 2017 (UTC)
I'm not sure how others do it, but if a user decides to simply move the article back to mainspace, or to recreate it, I simply give up on draftification and persue other means of patrolling the new page via CSD/PROD/AfD/tagging/etc in order to avoid any kind of move warring. I agree that clarification for patrollers is needed here and I'd like to see some version of this (don't force draft if new users don't want to work in draft) recommended as part of the proposed guidelines in a future RfC per Alsee. — InsertCleverPhraseHere 20:37, 8 August 2017 (UTC)
  • Strong Oppose setting up yet another restriction applicable only to non-Admins that Admins like SoWhy can sanction lowly regular users on is not welcome. There are already so many conflicting rules it is hard to keep track. This restriction will just remove another tool from the toolbox of NPPers that are struggling to keep up with the firehose of garbage pages being created. Many new mainspace pages should have been started in Draft and putting them where they belong is a kind and appropriate gesture. Legacypac (talk) 21:32, 8 August 2017 (UTC)
  • Oppose moving something to draft space counts as a WP:BOLD step that can be reversed. Limiting it to admins will have an artificial divide between activities admins and non-admins can do. Sure, moving to draft space has its disadvantages, but leaving a piece of junk in article space does too. Instead of blocking out this option, explain what patrollers should do, ie notify the writer(s) about the move and how to fix the page up so that it can be returned. Those that think this is a problem can look at the move log to see when draftification happens. Graeme Bartlett (talk) 22:13, 8 August 2017 (UTC)
  • Support I can see no reasons for draftifying. If an article falls under CSD then it should be deleted. If there is a dispute about that, it should be sent to discussion (AfD). If the article is a crappy stub, well, that makes it par for the course. Hawkeye7 (talk) 22:18, 8 August 2017 (UTC)
  • Very strong Oppose - this is a classic example of a solution looking for a problem. There would need to be proof and evidence of misuse of the 'Draftify' solution. Precisely the reason the Draft mainspace was created was for good faith creations that are however absolutely not ready for publication in mainspace. and to undo now would be a significant step backwards. The 'move to draft' is actually used much less frequently than the non NPP voters would claim, and AFAIK, no creators have complained. Of those new articles that I have moved to Draft, the creators have actually thanked me for it. To be absolutely honest, I see this RfC, while in good faith, not only as totally superfluous, but a drain on our time having to respond to it. Kudpung กุดผึ้ง (talk) 02:48, 9 August 2017 (UTC)
    • Well, "less frequently" is a loose term. I don't think 200 such moves in a week alone (cf. https://quarry.wmflabs.org/query/20795) can be considered infrequent. I don't have time now to check all those moves but I am fairly certain not all of them were correct (and those are just moves without a redirect, i.e. those not leaving a trace for a second pair of eyes to check). Regards SoWhy 07:23, 9 August 2017 (UTC)
      • I have made a somewhat easier to read list of the moves mentioned above here.Mduvekot (talk) 14:10, 11 August 2017 (UTC)
    • That's a common misconception. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated, or the games begin. The Draft space cannot be used for this purpose. The Draft space is reserved for the use of AFC Project. Hawkeye7 (talk) 22:10, 9 August 2017 (UTC)
That's not been my experience, and I think the discussion about G13 at WT:CSD makes it clear this is far from universal. @Legacypac and Premeditated Chaos: both of you have much more experience than I do in this area. Is what Hawkeye saying the current standard practice? TonyBallioni (talk) 00:36, 10 August 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Not remotely, which is the entire reason we've been having the discussion at WT:CSD about expanding G13 to cover all drafts in draftspace. Drafts don't get tagged for AfC until someone (usually their creator) submits them to AfC for review. Anything submitted to AfC and subsequently abandoned is eligible for G13. At present, anything not submitted to AfC will not have an AfC tag and will therefore never be eligible for G13. There's no mandate that items in draftspace must have an AfC tag and I honestly have no idea where Hawkeye7 got that impression. (Check out the stale drafts report for confirmation that there is plenty in draftspace without an AfC tag) ♠PMC(talk) 00:55, 10 August 2017 (UTC)
As noted in the links, that is exactly what happened. Articles in the draftspace were tagged for AFC without my submitting them. That then made them G13-eligible. You cannot honestly assert that you have no idea where I got that impression when I have presented the evidence. Furthermore, I note the discussion at WT:CSD#Expand G13 to cover ALL old drafts under which AFC asserts the right to delete articles under G13 regardless of whether they are AFC tagged. The reading of Editors may also optionally submit drafts for review via the articles for creation process by AFC is that any editor may submit any article in the draftspace to AFC, not just the article creators. Hawkeye7 (talk) 21:23, 10 August 2017 (UTC)
You are correct in saying that any article in draftspace may be tagged by anyone for submission. I clearly acknowledged that in my original comment (until someone (usually their creator) submits them to AfC). However, it is not the case that, as you said, anything placed in the Draft space will be tagged with a AFC submission template. Just because it can happen does not mean that it will happen to all drafts. Your experience is far from the norm; if you look at the stale drafts report you will see that the vast majority of those do not have AfC tags and never will. ♠PMC(talk) 05:33, 11 August 2017 (UTC)
How about a way of preventing it from ever happening? Hawkeye7 (talk) 03:37, 12 August 2017 (UTC)
Not the scope of this RfC, so not worth arguing about further here. If you'd like to change the way Draftpace/AfC works, you should make your own RfC asking to prohibit other editors from putting AfC tags on other peoples' drafts. You will almost certainly encounter strong resistance; the possibility of editors finding and improving other peoples' drafts is supposedly one of the main benefits of draftspace so I doubt the community would agree to a measure that would prevent that. ♠PMC(talk) 07:27, 12 August 2017 (UTC)
Which brings us back to the draftspace being AFC's playground, and unusable for any other purpose. Hawkeye7 (talk) 13:00, 14 August 2017 (UTC)
  • strong support - draftifying should be viewed as a type of deletion, ands only be used when outright deletion would be appropriate. עוד מישהו Od Mishehu 03:08, 9 August 2017 (UTC)
  • Oppose Draft-space is a useful 'stick' to motivate contributors, especially UPEs and those with COIs who only care about getting an article into the encyclopedia to improve their articles and avoid perpetual tags. It is also useful as an alternative to deletion, where an otherwise useful new contributor might find that their article is at AfD or speedy deletion because they don't know about the various hurdles and notability criteria that they have to demonstrate. In draftspace, especially if they submit to AfC, they can get feedback regarding this. I agree that this RfC is not in bad faith, and I do think there should be more monitoring to make sure it isn't being used as a 'quick deletion' option, but that fundamentally the option to draftify should remain. jcc (tea and biscuits) 09:10, 9 August 2017 (UTC)
  • Oppose - draftification should be kept as a viable interim step to other deletions. I would support a pohibition on subsequent attempts to draftify if the measure was contested, similar to PRODs, but nothing more stringent.--John Cline (talk) 10:07, 9 August 2017 (UTC)
  • Guideline Per Alsee. A soft delete without due process invalidates Prod, xfD etc. Yet I do see Kudpung's point. In case this is a solution looking for a problem, writing up a guideline will prevent loss of time in the future. Started it, might as well finish it right now...ronazTalk! 11:06, 9 August 2017 (UTC)
  • Oppose you show a picture of a cute buffalo, but what I think about is this. I have nothing against buffalos. So far, I have draftified exactly one article - a rejected AfC draft moved to main by one of nearly 100 blocked socks of a paid editor. It had 68 references, and had been rejected as "improperly sourced". I moved it back to draft space where it belongs. See also Jasmine Directory for a nice example how draftifying a promotional article prompted an editor to come forward, fix it and resubmit through the proper channels. Please consider these anecdotes when writing a guideline regarding draftification. Rentier (talk) 15:34, 9 August 2017 (UTC)
  • Oppose. Moving an article to draft is a substantially "softer" way of doing things than tagging for various forms of deletion on a new editor. It keeps stuff that isn't ready for mainspace out of it, but still keeps what they've done intact to get fixed. There still might be clearly unsalvageable stuff that needs deletion outright, but other stuff can go to draftspace and either become a viable article there or eventually fall into G13. Seraphimblade Talk to me 17:06, 9 August 2017 (UTC)
    • Seraphimblade, who gets to decide what's truly "ready for mainspace"? Should every autoconfirmed editor be allowed to boldly move pages to draftspace, without any kind of notification, discussion, or determination of consensus? What if other people disagree? Should they just boldly move the same article back to the mainspace? And what's the standard for "not ready for mainspace"? Anything that's WP:IMPERFECT? WhatamIdoing (talk) 22:18, 11 August 2017 (UTC)
  • Oppose. Draftifying allows new article creators to learn through feedback and communication, instead of feeling unwelcome – never to return or try again. GenQuest "Talk to Me" 17:16, 9 August 2017 (UTC)
  • Strong support. "since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted." is the key here, really. WP:FIXTHEPROBLEM - shoving a poor article behind a curtain means less chance of editors actually seeing and correcting the article. If a topic is notable enough for inclusion, then it can stay and be fixed, if not deleted. The only argument for draftifying is that an editor (usually they who created the article) is going to expand it - but surely then it can stay in mainspace? I see no real place for draftifying articles on Wikipedia - after all, we are the encyclopaedia that anyone can edit, not the encyclopaedia that require some arbitrary standard of quality otherwise your edits will be hidden from view and forgotten about. There is no difference between draftification and deletion, except that the content is still accessible - if you know where to look. Keira1996 00:09, 10 August 2017 (UTC)
  • Oppose a blanket ban, support the creation of some kind of guideline. ♠PMC(talk) 01:02, 10 August 2017 (UTC)
  • Oppose. If a new editor believes that they can WP:BOLDly move a draft into the article namespace, I do not see why experienced editors cannot, in return, WP:BOLDly disagree with that move, return the page to the "Draft:" namespace, and get the indexed redirect in the article namespace removed via WP:R2. Also, I agree with GenQuest's approach about how to communicate with the draft creator and/or publisher after moving the article back into the "Draft:" namespace; we are not in the business of chasing new editors away, but we have to ensure that the content being published is either up to our standards (usually eligible for WP:CSD) or on the way to becoming an article worthy of being in the article namespace (and thus moved back in the "Draft:" namespace pending further improvements). Steel1943 (talk) 06:22, 10 August 2017 (UTC)
  • Qualified Oppose Move to draft should be retained as an option when the creator has been told what improvements are necessary and there is reason to think they will make these improvements. However, we are no longer in the days when most creators could be assumed to be both competent and willing to follow guidance, engage in discussion and bring their articles up to scratch; it should be discouraged to fill draftspace with pages that have no hope of improvement. Such pages need to be improved by others, tagged, or deleted: Noyster (talk), 07:46, 10 August 2017 (UTC)
  • Strong oppose: Draftifying articles that is still under development or other issues is useful for newbies rather than being bitten by editors. KGirl (Wanna chat?) 20:13, 10 August 2017 (UTC)
  • Strong oppose per Seraphimblade. (((The Quixotic Potato))) (talk) 23:19, 10 August 2017 (UTC)
  • Oppose unless there is data showing that limiting draft moves is beneficial. Esquivalience (talk) 00:49, 11 August 2017 (UTC)
  • Strong oppose per TonyBallioni and Kudpung. Draftifying or userfying is in no way a form of deletion, since the article still exists, and can be restored to articlespace whenever it is appropriate. Inappropriate draftifications or userfications can be dealt with the old-fashioned way, through consensus discussion between editohrs. Beyond My Ken (talk) 13:34, 12 August 2017 (UTC)
  • Oppose  A bold move to draftspace or a "Speedy incubate" is fine, and strongly supported by our fundamental principles.  The remedy to a bold move is a revert.  Imposing a new bureaucracy violates policy. 

    I've written before about this, and Andrew D. points to a key flaw in the current design, which is the semi-auto deletion of the remaining redirect, which causes a loss of information.  Editors can't revert the bold move if they don't know that it is there. 

    If an article is present in drafspace, we need technical support to lockout the creation of an article in mainspace.  This lockout mechanism must not prevent a mainspace redirect.  We also need the ability to edit articles (i.e., add to the edit history) under a redirect.  This is not a proposal here, just elements of what have been many proposals over the years.  Unscintillating (talk) 14:13, 12 August 2017 (UTC)

    • What purpose does a redirect serve that {{There is a draft for this article}} does not? Does it just need to be displayed more prominently, or maybe for Draft: to be searchable by default along with mainspace? —Cryptic 17:33, 12 August 2017 (UTC)
      • Well, my experience has been that editors object to having a working redirect going from mainspace to draftspace.  Nor do I think that draftspace should be searchable from Google. 

        Here is a new proposal: Adding Category:Wikipedia draftspace to a redirect, soft or hard, in mainspace moves the edit history to draftspace, and no further edits are allowed until the draft article is moved back to mainspace.  A common redirect is {{soft redirect|Wikipedia draftspace}}.  Then we'd need to write the article at Wikipedia draftspace to attract new editors and explain how to locate articles in draftspace.  Unscintillating (talk) 19:43, 12 August 2017 (UTC)

  • Strong support. We are supposed to be the encyclopedia that anyone can edit. Articles in draftspace are effectively invisible to most editors (=readers), because you will only find them if you know exactly what you are looking for. It becomes a form of deletion by the back door and (with the exception of the cases covered by speedy deletion) deletion should require discussion. I also see draftification being used contrary to WP:BITE. Matt's talk 22:56, 13 August 2017 (UTC)
  • Strongest possible oppose – articles that do not meet notability guidelines such as WP:NFF or WP:TVSHOW, etc., but which are likely to once the guidelines are met to, should be moved to Draft space in the meantime, post haste. It doesn't take an Admin to figure this out – any NPP'er or experienced editor, can figure it out on their own. Making it an "Admin only" thing is another attempt to give Admins "super powers" over other editors. Now, if someone wants to come up with a better policy for when clarifying exactly when this can/should be done, then fine. But banning the practice outright is beyond harmful, and is likely to be roundly ignored even it's formalized. --IJBall (contribstalk) 03:49, 14 August 2017 (UTC)
  • Oppose - I had never even heard of "draftification" before but I find the oppose arguments above, particularly that of Kudpung and InsertClever...., to be compelling. Carrite (talk) 11:34, 14 August 2017 (UTC)
  • Strong oppose per Kudpung, Seraphimblade, TonyBallioni etc – in many cases, this is the least bitey method of dealing with new articles that have, in their current state, little or no chance of survival in mainspace. It gives inexperienced new editors breathing-space in which to learn what is expected of an article and how to fulfil those expectations, and is – I believe – far more likely to contribute to editor retention than is summary speedy deletion. Our guidelines should be rewritten to clarify that this an acceptable option and an integral part of what the draft space was created for. Disclosure: my name is among the most frequent on the list of such moves provided by Mduvekot above. Justlettersandnumbers (talk) 14:23, 14 August 2017 (UTC)
  • Strong oppose - No, moving articles to draft is not deletion. There is very little upside to this proposal, and significant downside as it would tend to make maintenance much more onerous while bringing down the average article quality in main space. Articles are moved to draft space because they are poorly written, poorly sourced, poorly translated, lack sufficient context, written like essays, or are of unknown notability. It's a simple matter for the creators of any such articles to improve them so that they approximate the quality of other articles, before they are republished in main space.- MrX 15:08, 17 August 2017 (UTC)
  • Strong oppose - qualified reviewers granted such rights, especially for use in NPP and/or AfC are, well...qualified to do so and for good reason. If they abuse the right, there are remedies. I see no reason to keep articles in main space that simply are not ready for main space or that fail one way or another. The quality of our articles is essential to the integrity of the project which is why we have the process in the first place. Atsme📞📧 12:10, 20 August 2017 (UTC)

Implement Highlight, Underline, Note, and "share notes" features into Wikipedia.

Implement a highlighting, underlining, and notes feature into Wikipedia.

All changes and uses of these features will be completely unique to every account unless a "share notes" button was added.

Imagine the possibilities of adding these features. Usage of Wikipedia will go up Time management will go up Literacy will go up Efficiency will go up The Learning Curve will dwindle

These 3 features and the "share notes" feature will be great tools for college students and professors, and essentially everyone because it will make learning that much quicker

My general proposal of this will be the follow; Add a Highlighting feature Add a Underlining feature Add a note/comment feature Add a "share notes (highlights, underlines, notes)" feature to other users

And if a page gets updated or a pice of information is removed on a page and you highlighted that part, it will give you a prompt saying "This edit has been changed. Will you like you review it?", something of this nature.

I do a ton of reading on Wikipedia and enjoy learning, and this is certainly a feature that is missing in my life and certainly millions of other users as well.— Preceding unsigned comment added by Aviartm (talkcontribs) 15:47, 11 August 2017 (UTC)

The ability to highlight text Template:Highlight already exists but I don't recall it being used often.--76.65.42.75 (talk) 23:07, 13 August 2017 (UTC)
  • This seems to be more about implementing notetaking features into Wikipedia, rather than strictly text formatting options. I weak support it due to these being cool features that can be potentially helpful in some situations, but I wonder about the overall usefulness of such added features, and how they would even be implemented. I think some more thought needs to be given into how how these features will be implemented, and into the actual, concrete problems and situations this will be useful in. The original proposal seems to be trying to advertise these features, rather than simply proposing them. JaykeBird (talk) 06:57, 14 August 2017 (UTC)
    I'd oppose increasing "private storage" areas - how and by who would they be policed? — xaosflux Talk 02:24, 15 August 2017 (UTC)
  • Oppose - I see little value in this use of developer's time and system storage space for all the notes that no one will ever read. Beyond My Ken (talk) 01:52, 16 August 2017 (UTC)

Proposal to change the existing displayed title "Ching Hai" to "Supreme Master Ching Hai"

Wrong venue. ―Mandruss  11:33, 15 August 2017 (UTC)

As said in the subject, I suggest the title of the article "Ching Hai" should be changed to "Supreme Master Ching Hai" due the following reasons:
According to the Wikipedia policy for article titles,
1. When the subject of an article is referred to mainly by a single common name, as evidenced through usage in a significant majority of English-language reliable sources, Wikipedia generally follows the sources and uses that name as its article title (subject to the other naming criteria). And "Supreme Master Ching Hai is the name of the subject that is most frequently used to refer to the subject in English-language reliable sources.
2. Ching Hai can be meant to be anyone's name, a name of a place, a name of a thing, and even a phrase of certain meaning in Chinese Language. You will find all different kinds of information related to these two words "Ching Hai" not related to the subject depicted in this article while searching on the internet. And therefore, due to ambiguity in the name "Ching Hai", I suggest "Supreme Master Ching Hai" is the most adequate title name for the article. -- Orwuck (talk) 06:12, 15 August 2017 (UTC)

That is not the purpose of this page. See Wikipedia:Requested moves for information about how to propose a move (title change) of an article. ―Mandruss  06:54, 15 August 2017 (UTC)
Also, that would not be a correct move. We don't even have the page name Emperor Akihito for Akihito. We don't call the queen of the U.K. "Queen" in the title of the article either. RileyBugz会話投稿記録 10:55, 15 August 2017 (UTC)

Bot to add Template:High-use and Template:High-risk to templates that need them

Template:High-use and Template:High-risk are templates which are meant to be added to the documentation pages of templates which are transcluded on more than 2,500 (Template:High-use) or more than 100,000 (Template:High-risk) pages. They notify people viewing these templates that changes to them are risky since they are transcluded on so many pages. But, many templates that need the high-use or high-risk templates still don't have them. For example, many of the templates in the lower ranks of the top 3000 most transcluded templates don't have the high-use template, even though most of them are transcluded on 5,000-6,000 pages. To solve this problem, I propose a bot that would look through the templates in Category:Wikipedia templates and see how many transclusions they have. If one had more than 2,500 and less than 100,000 transclusions, the high-use template would be added to its documentation page. However, if it had more than 100,000 transclusions, the high-risk template would be added to its documentation page. PhilrocMy contribs 15:42, 15 August 2017 (UTC)

RfC notice: Remove "adult" as a descriptor from the opening sentence of Family Guy

I've made a proposal to have "adult" removed from the opening sentence of Family Guy at Talk:Family Guy#RfC: Remove "adult" as a descriptor from the opening sentence. Curly "JFC" Turkey 🍁 ¡gobble! 13:15, 15 August 2017 (UTC)

Bot to move superscript/subscript pages to their correct location

Unicode superscripts and subscripts cause several accessibility and display issues.

This is a proposal to

  • mass-move pages with unicode super/subscript in their titles to their non-unicode version (e.g. move Foo²bar to Foo2bar)
  • add the appropriate displaytitle key to the new page (e.g. {{DISPLAYTITLE:Foo<sup>2</sup>bar}}) so "Foo²bar" is displayed as "Foo2bar"
  • update the main text (e.g. change Foo²bar to Foo<sup>2</sup>bar in the article)

For a practical examples of where this is done, see Vitamin B6, Golem100, 12e Régiment blindé du Canada, Aice5, or Tommy heavenly6 discography.

This has several advantages

  • Accessibility issues: Most screen readers will not be able to handle titles such as Gen¹³ (normally pronounced 'Gen thirteen'), pronouncing either 'Gen-supercript one-superscript three' or 'Gen-superscript one-cubed'. Modern screen readers would handle Gen13 as 'Gen-superscript 13'.
  • Several characters lack corresponding unicode superscript/subscripts.
  • Consistency in how we present our articles. Over 2000 pages correctly display the superscripts/subscripts. About 120 don't.
  • MOS compliance. See Wikipedia:Manual of Style/Superscripts and subscripts (which failed because the information was elsewhere / didn't need its own page, not because the information was disputed) Wikipedia:Manual_of_Style/Mathematics#Superscripts_and_subscripts and also. There is also MOS:UNITSYMBOLS.
  • Easier to find/search engine friendly. Someone looking for INXS²: The Remixes will type INXS2: The Remixes.
  • Non-unicode superscripts/subscripts read way better and have wider font support

The list of affected pages would be

Articles

Extended content
  1. (ISC)²
  2. 101²
  3. 12m² Sharpie
  4. ABCD² score
  5. AM²
  6. America³
  7. America³ (1992 yacht)
  8. Atm⁵
  9. A² Records
  10. A¹ homotopy theory
  11. Book:E=MC² (Mariah Carey album)
  12. Carl²
  13. Chhut-thâu-thiⁿ
  14. Counterfeit²
  15. DNA²
  16. Don Omar Presents MTO²: New Generation
  17. E=MC² (Giorgio Moroder album)
  18. E=MC² (Mariah Carey album)
  19. E² (album)
  20. GA²LEN
  21. Gen¹³
  22. Gen¹³ (film)
  23. Gen¹³/Monkeyman and O'Brien
  24. Heavy Metal: F.A.K.K.²
  25. Hi-Teknology²: The Chip
  26. INXS²: The Remixes
  27. I²C
  28. I²S
  29. K² (band)
  30. List of political and geographic subdivisions by total area from .1 to 1,000 km²
  31. List of political and geographic subdivisions by total area from .1 to 250 km²
  32. List of political and geographic subdivisions by total area from 1,000 to 3,000 km²
  33. List of political and geographic subdivisions by total area from 1,000 to 5,000 km²
  34. List of political and geographic subdivisions by total area from 10,000 to 20,000 km²
  35. List of political and geographic subdivisions by total area from 100,000 to 1,000,000 km²
  36. List of political and geographic subdivisions by total area from 100,000 to 200,000 km²
  37. List of political and geographic subdivisions by total area from 20,000 to 30,000 km²
  38. List of political and geographic subdivisions by total area from 20,000 to 50,000 km²
  39. List of political and geographic subdivisions by total area from 200,000 to 500,000 km²
  40. List of political and geographic subdivisions by total area from 250 to 1,000 km²
  41. List of political and geographic subdivisions by total area from 3,000 to 5,000 km²
  42. List of political and geographic subdivisions by total area from 30,000 to 50,000 km²
  43. List of political and geographic subdivisions by total area from 5,000 to 20,000 km²
  44. List of political and geographic subdivisions by total area from 5,000 to 7,000 km²
  45. List of political and geographic subdivisions by total area from 50,000 to 100,000 km²
  46. List of political and geographic subdivisions by total area from 50,000 to 200,000 km²
  47. List of political and geographic subdivisions by total area from 500,000 to 1,000,000 km²
  48. List of political and geographic subdivisions by total area from 7,000 to 10,000 km²
  49. List of political and geographic subdivisions by total area in excess of 1,000,000 km²
  50. List of political and geographic subdivisions by total area in excess of 200,000 km²
  51. Live at the O² Arena
  52. L² cohomology
  53. MAC³PARK Stadion
  54. MD² International
  55. Magnavox Odyssey²
  56. Mercedes-Benz G500 4×4²
  57. Me²
  58. M² (album)
  59. PC²
  60. Rite²
  61. SGI Indigo² and Challenge M
  62. SR² Motorsports
  63. Sailing at the 1920 Summer Olympics – 30m² Skerry cruiser
  64. Sailing at the 1920 Summer Olympics – 40m² Skerry cruiser
  65. Sailing at the 1956 Summer Olympics – 12m² Sharpie
  66. Secretory Pathway Ca²⁺ ATPase
  67. Stella Women’s Academy, High School Division Class C³
  68. V-Partei³
  69. Why Does E=mc²?
  70. Zeit²
  71. Z² (album)

(I'd exclude Chhut-thâu-thiⁿ from the bot however, since this might be a grammar specific thing. Likewise for and 101², which would clash with 1012. I'd make a formal WP:RM for either of those.)

Categories

Extended content
  1. Category:(ISC)²
  2. Category:12m² Sharpie
  3. Category:12m² Sharpie class Olympic sailors
  4. Category:12m² Sharpie class sailors
  5. Category:30m² Skerry cruiser class Olympic sailors
  6. Category:30m² Skerry cruiser class sailors
  7. Category:40m² Skerry cruiser class Olympic sailors
  8. Category:40m² Skerry cruiser class sailors
  9. Category:40m² Skerry cruisers
  10. Category:Gen¹³ and DV8 characters
  11. Category:Suspected Wikipedia sockpuppets of Eep²

(I'd exclude Category:Suspected Wikipedia sockpuppets of Eep² from the bot however, since the user was User:Eep² and no readers would come across it anyway.)

Files

Extended content
  1. File:Carl².png
  2. File:Counterfeit².jpg
  3. File:E=MC² 1.png
  4. File:E=MC² cover.jpeg
  5. File:Gen¹³ FilmPoster.jpeg
  6. File:Gen¹³ vol. 2 6 Coverart.jpg
  7. File:I²C bus logo.svg
  8. File:Me² (Red Dwarf).jpg
  9. File:SABIN【420 stoⁿer】.jpeg
  10. File:Sini Sabotage - 22 m².jpg
  11. File:Why Does Emc².jpg

Templates

Extended content
  1. Template:Footer Olympic Champions 30m² Skerry cruiser
  2. Template:Footer Olympic Champions 40m² Skerry cruiser
  3. Template:S³ University Alliance
  4. Template:The EMC² Barnstar

Discussion

Personally, I'd support moving everything, but files and templates don't really need to be. Starting the discussion to see what the support is for this. Headbomb {t · c · p · b} 11:57, 16 August 2017 (UTC)

I have made previous comments at Wikipedia:Bot requests#Unicode subscript.2Fsuperscript bot. --Izno (talk) 12:32, 16 August 2017 (UTC)
I'd support this in full: screen readers have very variable unicode support, and having something closer to plain text would be almost always an improvement in the experience of readers using assistive technology. I've taken the liberty of changing the pseudo-headings above to real headings in the interest of accessibility. --RexxS (talk) 20:48, 16 August 2017 (UTC)
Oppose mass bot moves. Only 101 titles are listed above. They can be evaluated manually, and some should have navbox updates if they are moved (to make the bold selflink feature work). DISPLAYTITLE only works on the page itself, not in categories, search results and so on. The mentioned guidelines are about article content and don't consider this limitation in page names. If a sub/superscript is usually ignored in pronunciation then dropping it is usually acceptable, but if a superscript means a power like a square then it's pronounced differently and looks confusing without it. We should consider the common plain text notation "^2", like moving 12m² Sharpie to 12m^2 Sharpie or 12 m^2 Sharpie instead of the cryptic 12m2 Sharpie. The "^" character can be hidden by DISPLAYTITLE with positioning like Kalai's 3^d conjecture at Template:DISPLAYTITLE#Examples. I don't know how screen readers pronounce "^" but I guess their users are used to it meaning a power. There are other special cases like 101² which might be moved to 101 Vol. 2 like some sources call it. 1012 would be strange (and is taken by the year). PrimeHunter (talk) 22:59, 16 August 2017 (UTC)
Here is where we ought to evaluate them. 12m2 Sharpie is not 'cryptic', because that's not how people would see it. They would see it as 12m2 Sharpie. The only place you would see 12m2 Sharpie is in the edit window, and is no more unclear than seeing '5-HT2C receptor' in the edit window, rather than '5-HT2C receptor' (which cannot be rendered with unicode subscripts). 101² may required some additional thought however, but moving to Highway 101, Vol. 2 or similar would likely be the correct solution to that one. Headbomb {t · c · p · b} 13:44, 17 August 2017 (UTC)
  • Oppose moves by a bot, the number of items involved is quite small per PrimeHunter, and each article/category requires individual review. Templates and files, whose names aren't exactly reader-facing, should definitely not have these characters in them (they have to be typed by editors). FYI, I've sent one of the files to FFD. – Train2104 (t • c) 23:55, 16 August 2017 (UTC)
Why oppose those moves by a bot? Are there any listed above that should not be moved, beyond the few I've already mentionned? If so, we can just exclude those, and let the bot perform these rather tedious things for us. Headbomb {t · c · p · b} 02:44, 17 August 2017 (UTC)
  • Do not use a bot, and do not rename files or templates for this reason. Files or template names will not be read by screen readers. And why can't screen readers be updated to include more unicode characters like this? Superscripts have been there for a long time now. Anyway there may be reasons to rename apart from this. Windows 10 Narrator reads these correctly as "superscript 2" or even "square meters". Windows 10 narrator does not handle the ^2 as well as ² so please don't change this to ^2. So screen readers are not a good reason the alter these. Graeme Bartlett (talk) 00:36, 17 August 2017 (UTC)
The reason mostly is because unicode superscripts/subscripts are pretty much deprecated everywhere, and are an incomplete set. <sup></sup> and <sub></sub> tags support all characters, so that's what people use. There's no effort to improve unicode subscript support, because it's an incomplete character set, and the effort required to improve it would duplicate the existing solution by doubling the unicode character sets, and then somehow develop an alrorithm that could parse ₕₑₗₗₒ as 'subscript hello'. And update thousands of fonts to line up and kern subscripts/superscript characters. Headbomb {t · c · p · b} 14:06, 17 August 2017 (UTC)
  • I support this in principle, as a relatively minor and handy improvement. However, I'm really not in a position to look into this in great detail ... except to reply to the points by Graeme Bartlett that Windows Narrator is not widely used as a screen reader by blind people, screen reader makers have enough trouble updating their products to work with new software versions rather than thinking about Unicode characters, and file names can sometimes be read by screen readers because of the way Wikipedia's image syntax works (as most images are linked and have no alt text). Graham87 02:38, 17 August 2017 (UTC)
  • Support I don't care what tools you use (bot or manual), end result is what matters. Not sure what the issues are with template and files, but I would support the Articles anyway if had to narrow the choice. -- GreenC 03:11, 17 August 2017 (UTC)
  • Support, after giving users a reasonable amount of time to review trhese lists and request individual exclusions. עוד מישהו Od Mishehu 19:44, 17 August 2017 (UTC)

Create a new Event Coordinators user group

This is a follow-up to the previous RfC about extending the Account Creator user group. Per the comments in that RfC, there seems to be general agreement that there should be some technical means for people who have experience running edit-a-thons and similar events (and have a proven track record of successfully onboarding new editors) to be able to work around the limitations of WP:ACTRIAL during its duration—specifically, the limitation that non-autoconfirmed users can't create new articles. The main objection raised in the previous RfC was that the Account Creator user group wasn't a good user group to use for this purpose since it is given out freely to editors who haven't been adequately vetted for the ability to onboard new editors and thus shouldn't be trusted to grant autoconfirmed status to other users. For this RfC I am proposing the following:

  • A new user group is created called Event coordinators with the following rights: noratelimit (can create more than six accounts in a 24-hour period with Special:CreateAccount), ability to add group Confirmed users (See WP:CONFIRM).
  • This new user group will have the following requirements to be granted:
    • User must be auto-confirmed themselves
    • User must have a proven record of running successful Wikipedia editing events
    • User must have good understanding of key Wikipedia policies and guidelines related to article creation

Kaldari (talk) 21:56, 18 August 2017 (UTC)

  • Support at Wikipedia:Account creator there is text about giving account creation rights to people coordinating events. Account creator userights include the right to make more than 6 accounts from one IP and also some odd rights related to account creation which can cause extra damage. For the sake of event coordinators organizing Wikipedia editing events, we need a userright to bypass the 6-account limit and which admins can grant freely to users who cannot be fully trusted with the extra privileges which come with account creator. This issue has been discussed for several years on the talk page of the account creator rights. In 2018 probably 100 accounts would need this event coordinator right and the use is likely to increase over time. Many people are uncomfortable with the account creator right being granted so freely to so many new users. Blue Rasberry (talk) 22:07, 18 August 2017 (UTC)
    Not seeing how this is much differnt - yes this one doesn't have list override, but it still has wide open throttle override. — xaosflux Talk 22:10, 18 August 2017 (UTC)
Striken then - I am expecting a solution which addresses the technical issue raised years ago, and which has been the focus of discussion since then. I just want new users to be able to create accounts to contribute someplace, and I would prefer to maintain status quo in other regards. Blue Rasberry (talk) 22:52, 18 August 2017 (UTC)
  • Comment @Kaldari: have you seen the discussions at Wikipedia talk:Account creator - talking about event needs? — xaosflux Talk 22:08, 18 August 2017 (UTC)
    • @Xaosflux: I agree we need better tools for events, especially around account registration issues (and related security concerns). Although this proposal won't solve that, I think it might be a useful stopgap during WP:ACTRIAL. Kaldari (talk) 22:30, 18 August 2017 (UTC)
  • Oppose - Per SilkTork's oppose at the previous RfC, The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. - FlightTime (open channel) 22:18, 18 August 2017 (UTC
    • The feedback that I've seen from actual event coordinators doesn't seem to support that conclusion. For example: "I don't know any edit-a-thon organizers using AW+Draft space at events, and personally I've never found AW to be super useful."[18] Kaldari (talk) 22:26, 18 August 2017 (UTC)
  • Oppose I oppose granting account creators or event organizers the ability to make new users autoconfirmed. I've seen no evidence that these new users are better than other new users at creating new pages. New users should work in Draft. The event organizers can use their own accounts and judgement to move anything new into mainspace. That way if there are inappropraite moves we can discuss it with an established user. Or let AfC do it's job. New users should not be starting by creating new pages anyway - they shoudl learn on improving and expanding established articles. Legacypac (talk) 22:23, 18 August 2017 (UTC)
  • Oppose This is an even worse idea. Even an experienced event-coordinator can't oversee all the new editors that show up, not that they would even want to. If anything, admins should be more careful who they give account creator to; we need not create a new user group to fix past errors in judgement. There's no reason to ameliorate the effects of ACTRIAL. All new editors should be going through AfC, no exceptions. Chris Troutman (talk) 22:30, 18 August 2017 (UTC)
  • Support for a different reason Per Gnangarra's comments in the last RfC, The ability of an event coordinator to confirm other users would remove the very annoying and disruptive CAPTCHAs that come up constantly for non-autoconfirmed users. This by itself would immeasurably improve the experience for new editors at editing events. — InsertCleverPhraseHere (or here) 23:00, 18 August 2017 (UTC)
  • Comment @Kaldari: Respectfully, I'm not sure I agree with your reading of consensus on the previous RfC, which you withdrew without an uninvolved closure, as is permitted. I see two main objections to the prior proposal, with the second one being that all new users should go through the draft / AfC process, as argued by SilkTork, Ivanvector, Kudpung, et al. What I do not see is a general agreement that there exists a need to "work around the limitations of WP:ACTRIAL". I wonder if the Foundation seriously considered Cabayi's proposal centred on "event" templates, or Jytdog's idea to recruit reviewers for real-time feedback through the AfC process. I have no strong opinion on the present RfC, but don't read it as significantly different to the prior one. Snuge purveyor (talk) 23:25, 18 August 2017 (UTC)
  • Support as per my comments in the previous RfC, somewhere along the way we forget where we started and the mistakes we made. AfC is the problem, being bitten by that process is the biggest issue in editor retention and positive experiences by new users from workshops. Putting a time limit on being able to create accounts for event organisors would remove the issue of the tool being given to readily and not monitored. As we grow we have a habit of developing fiefdoms and power structures when maybe we should be reminding ourselves "Anyone can edit" and "Assume good faith" before a new process is created and ask are we hindering that. @Kaldari: is trying to address that and refine the previous rfc based on comments there, the opposes so far have raised nothing new they continue to be new user shouldnt be able to create articles not much AGF there. Projects like WikiWomen, Women in Science, Education and many other Wikibombs are specifically aimed at the creation of new content in areas where we lack coverage while at the same bringing in new editors. Either we start to address the concept that we truly want to share the sum of all knowledge and we want to address systemic bias and the cultural bias of editors or we choose to say stuff it this is a male dominated community and only the knowledge of interest to males matters. Gnangarra 23:45, 18 August 2017 (UTC)
  • There is nothing in the present system that hinders addressing any perceived systemic bias. Unless you have evidence that AfC enforces such bias? Allowing a bunch of avowedly single-purpose accounts to by-pass standard procedure on any grounds is surely not A Good Thing. - Sitush (talk) 20:43, 19 August 2017 (UTC)
  • Neutral I supported the previous RfC as a measure of goodwill towards event coordinators who said they wanted this during conversations around ACTRIAL. I still don't see it as that big of a deal, but I also think the last RFC revealed that the community didn't want event participants to actually be exempted, and some appeared to be under the false impression that ACTRIAL was a permenant thing that had already been implemented, and were opposed to any exemption from it. Given both set of concerns raised by editathon coordinators and those who opposed the ability to confirm in general last time, I am neutral on this request, but thougut it appropriate to make it clear here since I have been heavily involved with the ACTRIAL conversation. TonyBallioni (talk) 23:56, 18 August 2017 (UTC)
  • Comment: While this is slightly different, I'm not changing my stance from the previous RfC: One of the major objectives of ACTRIAL is to reduce the workload for reviewers and other maintenance workers. Last week an editathon in South Africa organised by the SA chapter and the Swedish embassy was publicised during a TV interview and received a high participation. Unfortunately, the facilitator was ill prepared for the unexpected high participation and a number of articles were produced in good faith but were totally unsuitable for an encyclopedia. It's a shame to have to delete these otherwise good faith efforts. Rather than making any changes to the User Group permissions, perhaps it would be more appropriate for editathon facilitators to teach their students how to edit by getting them to create their articles in their sandbox or or in the Draft namespace instead. Facilitators could them move suitable articles to mainspace for them.
I think that good preparation for an editathon should enlist an admin who will be present or online during the event. The recent editathon in South Africa went wrong. This does not instill confidence that event organisers are automatically any more qualified than anyone else. That said, I would like to invite the comments of RexxS, a highly experience editathon facilitator and qualified teacher and instructor who generally ensures that his editathon students make their creations in their sandboxes. Kudpung กุดผึ้ง (talk) 01:30, 19 August 2017 (UTC)
Perhaps there is a broader question of how much help we give to event organisers in general. I've faced a lot of unexpected problems at events over the years, and eventually you learn how to anticipate the commoner ones (e.g. have a spare laptop and AV cables available), but getting examples of good practice beforehand can help. To be honest, I dislike losing time in creating accounts on the day, so I strongly encourage participants to register an account at least four days before the event. That's the single easiest means of completely avoiding the non-confirmed problems. Sometimes you can't, so I try to catch participants before the event starts (maybe over coffee) and get them registered then without using up scheduled time and keeping a group waiting. Otherwise you need an assistant who knows how to use Special:CreateAccount, who can make accounts while you get the rest of the group started. As for AfC - I simply prefer not to use Draft space, sorry. Despite all your good efforts, the quality of reviewing remains variable, and I much prefer working entirely in user sandboxes, at least until the participants can comfortably add referenced content. Even then, many will not be capable of getting to grips with WP:N, so ought not to be creating new articles until they are somewhat more experienced. In the rare cases where a new editor does have a notable subject with good sources, then I have no problem with doing any moves for them, if needed. I should say that the participant:instructor ratio really ought not to exceed around 12:1 (and half of that is better). It's always a good idea to have a capable assistant who is learning how to be an instructor anyway, as you can never be sure when you're going to be needed to solve an urgent problem, so the assistant can step-in to avoid "downtime". Anyway, my point is that I don't particularly need the ability to confirm new editors. It will be perfectly possible to run an event without it, even when ACTRIAL is running. It just means that some organisers may find that modifying how they work will yield better results. I'm always happy to talk through organising with folks who are uncertain. Please feel free to contact me on my talk page or by wiki-mail, if I can help. --RexxS (talk) 13:32, 19 August 2017 (UTC)
Though I don't do it exactly like RexxS does, my experience with running editathons as the Wikipedian in Residence of a museum is the same as his and, I too avoid the draftspace and encourage people to work in their sandboxes. While I'm not opposed, per se, to this proposal, neither do I have a need for it. Regards, TransporterMan (TALK) 20:24, 19 August 2017 (UTC)
  • Kaladri, one specific point: just dealing with ratelimit does not solve the problem. Many school and some library and university websites have their ip blocked because of persistent abuse--the even coordinator also needs ip block exempt. This would be necessary also. More generally, we also need to provide for unofficial editathons. Anyone can run an editathon, and some satisfactory ones have been done without contacting us at all. (A good number of unsatisfactory ones have been done that way also). Obviously we cannot extend special privileges to those who don't know enough to ask for them, but we shouldn't pose too great difficulties either. Incidentally, I think must people who use the internet are accustomed to CPATCHAs in all sorts of situations--that doesn't bother me.
My experience in NYC is a special situation, unlike many places, we have sufficient experienced event leaders and administrators to deal with this problem for all events that ask us for assistance--even when there are multiple events on the same day. We need to keep the others in mind also. DGG ( talk ) 04:22, 19 August 2017 (UTC)
CAPTCHAs for every single edit are not disruptive? — InsertCleverPhraseHere (or here) 05:33, 19 August 2017 (UTC)
@Insertcleverphrasehere: see Special:Captcha. CAPTCHA's are not required for every single edit at all. Even non-logged in users can make most edits without captchas. — xaosflux Talk 12:44, 19 August 2017 (UTC)
On the contrary, Special:Captcha is clear that "Unfortunately, this may inconvenience users with limited vision or using text-based or speech-based browsers. At the moment we do not have an audio alternative available." This is an accessibility barrier and needs to be resolved. In addition, making edits that add content require sources, most of which will be web-based and hence contain an external link that requires a CAPTCHA. I've had editathons where some well-prepared new editors actually were getting a CAPTCHA on every edit. --RexxS (talk) 13:32, 19 August 2017 (UTC)
I had the same issue at a recent editathon, editors adding external links getting CAPTCHAs on nearly every edit. It actually ends up discouraging new users from adding sources, which is pretty much the last thing we want to do to new editors at an editathon. — InsertCleverPhraseHere (or here) 14:48, 19 August 2017 (UTC)
  • Weak oppose. So many things could go wrong. Positions could be seized by special interest groups etc. Quis custodiet ipsos custodes? Xxanthippe (talk) 07:10, 19 August 2017 (UTC).
  • Support the technical details can be discussed later, but I think this right will help clarify and centralise the discussion and management of event coordinators, by viewing them as a separate group. Overall in the right direction. --Tom (LT) (talk) 08:26, 19 August 2017 (UTC)
  • Oppose I still don't see the need for editathons to bypass ACTRIAL... just going to an editathon doesn't mean you're going to write quality articles that don't need review.. -- There'sNoTime (to explain) 13:39, 19 August 2017 (UTC)
    • There's a misunderstanding here. Anyone can write an article in their userspace and then move it into mainspace without review. During ACTRIAL, it will simply mean that they have to wait four days before they can do that. It should be the case that the delay won't matter to an enthusiastic new editor who may work on an article for longer than that anyway; whereas the typical spammer will find it a barrier. The whole point is to decrease the number of unsuitable articles dropped directly into mainspace, not simply divert them into an ever-increasing queue at AfC. Being at an editathon certainly ought to mean that your work is reviewed there and then, by an experienced editor in person, before being moved into mainspace. --RexxS (talk) 14:33, 19 August 2017 (UTC)
  • Commentary There is still a need for people to "make accounts" at editathons - and auto confirmation is primarily intended to stop vandals; ACTTRIAL actually raises the overall bar for "what autoconfirmed means" here - to me it means "brand new editors" should use drafts - not skip it because they are at a specific location. I don't think having inexperienced edits (such as the ones getting account creator access today) is the way to manage an event at all though. — xaosflux Talk 14:31, 19 August 2017 (UTC)
  • Oppose This is little more than an attempt at an end-run round the previous withdrawn proposal. It has similar problems, as I and others have documented elsewhere. In particular, I documented some specific instances of long-standing event co-ordinators and past/present WMF staff who made the most ridiculous errors. While errors can slip through anyway, I don't trust any carte blanche being given that might imply some sort of "supervote" regarding the quality of submissions etc. - Sitush (talk) 20:31, 19 August 2017 (UTC)

Reviving WP:WikiProject Neutrality

I've been looking at the Articles with a promotional tone category, and it worries me that it keeps rising in article count month after month. While the Neutral point of view Noticeboard is useful for situations where neutrality is unclear or debated, in many situations it is obvious that an article is promotional, with some articles remaining promotional for over 9 years. I believe that promotional articles are one of the worst problems on Wikipedia, as companies or individuals take advantage of the influence of Wikipedia to promote themselves. I believe that if promotional articles had a similar WikiProject to the Guild of Copy Editors, the number of promotional articles would begin to go down. WikiProject Neutrality could be revived and altered to help solve the problem of promotional articles. Thoughts? CoolieCoolster (talk) 13:09, 20 August 2017 (UTC)

Idea lab

3-segment wikilinks

  • For use in making wikilinks, particularly in languages with case-endings and similar, try allowing 3-segment wikilinks:-
    1. [[X]] displays and links to X , as now.
      • [[X]]Y links to X and displays XY , as now.
    2. [[X|Y]] links to X and displays Y , as now.
      • [[X|Y]]Z links to X and displays YZ , as now.
    3. And idea: let [[X|Y|Z]] link to XY and display XZ . For example, "he [[procrastinat|ion|ed]]" would be more compact than "he [[procrastination|procrastinated]]".
      • And if so, [[X|Y|]] would link to XY and display X .
That could be interesting. --167.58.26.73 (talk) 19:55, 3 August 2017 (UTC)
  • I don't think this is that much needed on the English wikipedia, but it could be massively helpful for other language versions. I think this should be proposed at the next Wishlit Survey (the last one was in 2016), with input sought from the other language projects. – Uanfala 11:10, 6 August 2017 (UTC)
Commenting exclusively on English as it's the only language I'm fluent in, my concern here is that while "[[procrastinat|ion|ed]]" is marginally more compact than the current "[[procrastination|procrastinated]]", it's significantly less readable, and requires the reader to parse the string in their head. Reading it for the article that will be linked to (procrastination) is still fairly trivial, but the text that will be displayed in the article ("procrastinated") is far less clear and obvious. Whereas the current form, while perhaps not perfect, explicitly displays both of those pieces of text.
The ability to append characters to article links (e.g. [[link]]ing) is a nice shorthand because it's still easily readable as both the article name (inside the brackets) and the link text (ignore the brackets). The expanded form "[[link|linking]]" would contain two adjacent instances of the same string (in bold), so it's convenient to "reduce" them for clarity and conciseness. But by chopping up the non-redundant bits of the text, and reducing strings that aren't adjacent, isn't that conciseness coming at the expense of both clarity and convenience? -- FeRD_NYC (talk) 03:47, 19 August 2017 (UTC)

Text searching

Currently the searching templates {{look from|xxxxx}} and {{intitle|xxxxx}} seem to look only for letters and numbers and ignore punctuation etc. This can be a nuisance, because, currently there is a policy to remove the comma when a page name ends in ", Sr." or ", Jr.", and to help to do this work, there is no easy way to search for these two character sequences, but someone must look at every page name by eye, and requests to remove these "senior and junior commas" come in endlessly in dribs and drabs instead of someone being able to quickly call search for ", Sr." and ", Jr." and get the job complete and done and over. Please provide an option for Template:look from and Template:intitle to search for all characters, not only for letters and numbers. Anthony Appleyard (talk) 05:34, 2 August 2017 (UTC)

The latter is phab:T156510. I'm not sure how you mean to use the former for your use case, but it doesn't seem reasonable off the cuff. --Izno (talk) 12:31, 2 August 2017 (UTC)
@Izno: As regards Template:intitle , what is the likely progress with https://phabricator.wikimedia.org/T156510 ? Ability to search for characters other than letters and numbers would be useful. Anthony Appleyard (talk) 05:17, 3 August 2017 (UTC)
I do not know. That is something to ask on the phabricator task. :D --Izno (talk) 13:37, 3 August 2017 (UTC)
There is a beta search tool on wmflabs that uses regexp to search article titles. Unfortunately, you're on your own for constructing efficient regexp searches. Also, the tool can be very slow and can return a LOT of results if you put in a too generic a regexp. For example, this search for ", Sr." took quite a while to run, but it looks like what you describe. (and I'll refrain from commenting on whether it is a worthwhile use of time to "fix" such trivial formatting differences). olderwiser 14:11, 3 August 2017 (UTC)
Having regular expressions in page search seems a bit excessive. With a one-character sign ('.') and an any string sign ('*'), that should be enough. --167.58.26.73 (talk) 19:58, 3 August 2017 (UTC)
Are you just looking for https://en.wikipedia.org/w/index.php?search=insource%3A%2F%5C%2C+Sr%5C.%2F&title=Special:Search&profile=default&fulltext=1 or for something else? Whatamidoing (WMF) (talk) 22:37, 11 August 2017 (UTC)

Subject IDs for noticeboards

I've come across situations where looking through a public noticeboard fails to find an item of interest because it has been renamed since the discussion was archived. Examples:

  • Articles - articles are moved or merged
  • Editor account names - editors can rename themselves including the "vanished user" rename
  • Sockpuppet investigations - the sockmaster under which the SPI is filed can be reassigned

Is there a technical solution to this, such as searching the archive for a certain code like the WP database page ID for users, or a Wikidata Q-code ID for an article? Could certain things be annotated automatically to make future searching more tenable, like the {{la}} and {{userlinks}} templates for instance? ☆ Bri (talk) 20:35, 6 August 2017 (UTC)

Tool that suggests images to add to articles without an image (using Wikidata item's image)

Many Wikipedia articles have no image despite the associated Wikidata image having a P18 (image) property.

For instance, the article Thug Behram has no image, despite the Wikidata item having a perfectly usable image. Wikidata has more images because in non-English speaking countries (ie most of the world) the local language article is usually the best illustrated, and images make it to Wikidata via infobox harvesting or WDFIST.

Idea: How about having a tool that would suggest images for articles?

Use case: I am presented with an English Wikipedia article on the left, and an image (together with its title/description/categories/discussion) on the right. If I find the image fitting, I press a button and the image is automagically added to the article. Ideally the image is added to the article infobox if there is one with a recognized image property.

Images make Wikipedia articles much more attractive and informative, so I believe that would help a lot. Such a tool could then be ported to other Wikipedias too. Is there maybe such a tool, and I have not managed finding it? Cheers! Syced (talk) 03:28, 9 August 2017 (UTC)

Sounds like a great idea. — InsertCleverPhraseHere 04:18, 9 August 2017 (UTC)
There is an opportunity to go in multiple directions here. It isn't just Wikidata that has images. Many articles have an image from commons in one language but not in several other language versions. Lots of species have a category on Commmons but no images in articles, or only in one language. I do a bit of categorisation on Commons and I sometimes add images to species articles when I create a new species category on commons. There are big opportunities for apps that make it easy to add images, and if you speak the language to add a caption. We have done proof of concept editathons as long ago as 2011 in London inviting donors in and showing them how to add images, even quite hesitant people got very confident when you explain that a computer can suggest a dozen images for an article, but we still need a human to choose the image. Unfortunately we lost access to the donor data when the fundraising as centralised in San Francisco. ϢereSpielChequers 09:50, 9 August 2017 (UTC)
Indeed, the tool could be extended once the low-hanging fruits are harvested. The low-hanging fruits are Wikidata, because if Wikidata has an image then you can be 100% sure this image is a good addition to the article. On the opposite, pictures from the Commons category can be a bit random, and many are only remotely related to the topic, for instance most pictures in the category about Jonan Island are pictures of airplanes rather than pictures of the island. I am not saying Commons categories are bad, I am saying Wikidata is probably easier to start with. Thanks for the idea, and thanks for adding images to Wikipedia articles! :-) Syced (talk) 14:44, 9 August 2017 (UTC)
VE already does this. If you open Thug Behram in VE, and choose Insert->Media, it will suggest the image. I believe it simply searches based on the article title, and perhaps a more sophisticated search would be useful, but as it stands I've found this feature very helpful. Mike Christie (talk - contribs - library) 10:51, 9 August 2017 (UTC)
Interesting! Unfortunately 1) that takes many clicks 2) Image metadata is not available so it is hard to tell whether the picture is actually appropriate or not 3) Most importantly, going through all Wikipedia articles without pictures and opening VE for each of them hoping that some pictures will be suggested would be very inefficient. The VE approach is great for people who know what article they want to add images to. Thanks for your input! :-) Syced (talk) 14:44, 9 August 2017 (UTC)
What metadata do you want? Right now, if you click a plausible looking image, then it gives you size, license, author, etc. data on the next screen. What else would be helpful? (Please {{ping}} me.) Whatamidoing (WMF) (talk) 22:41, 11 August 2017 (UTC)
Whatamidoing (WMF): When I add an image, I look at the image's categories, as they often give hints about what is going on in the picture. For instance, if there is a "Chess World Cup 1987" category then I can write a better caption like "Tom Beh at the Chess World Cup 1987". If the image has a category "Joe Csze" then I will double-check who is really pictured. I also look at the discussion page in the rare cases where it is not a red link, because any information there is often useful, for instance an anonymous saying "This is not Tom Beh this is his brother" is a valuable tip. Also, a really neat thing would be to see all articles the image is used in, together with the caption for each (most writers can understand several languages so that would help a lot when writing the caption). Thanks! :-) Syced (talk) 05:48, 15 August 2017 (UTC)
When you click on an image in the media dialog, it lists some machine-readable information (e.g., license, upload date, image size, file type, etc.) Then it has a link labeled "More information", which takes you to the Commons page. I think that you would probably find that the most useful approach, especially if you want to read the talk pages at Commons. Whatamidoing (WMF) (talk) 17:21, 15 August 2017 (UTC)

Interesting idea. Building a naive tool do to this is trivial. The problem is dealing with all the drama that comes with it and the mangling that may happen in complicated cases.

There also aren't that many apparently. A bot could probably add all images within a day or two, less than a week for sure. The problem of course is that it has false positives because it relies on mw:Extension:PageImages, and some images may come with all the drama that naturally follows any automated task of that nature. Any semi-automated tool doing this on a continuous basis would fail miserably without a lot of work because of the unstructured nature of wikitext, the inconsistent way in which templates add images to pages, and a lot of edge cases.

It might be easier to make a bot that suggests such images on the talk page, and then editors can easily add (or not) them as needed. This would also reduce the need to randomly come across an article that needs file. Currently though, it might be better to create a bot that suggests images that are used in linked interwiki pages, maybe if 3 wikis or more are using the same image it then adds it to the talk page (and / or wikidata).

See also: https://tools.wmflabs.org/wikidata-todo/wp_no_image/enwiki.html , https://phabricator.wikimedia.org/T54464, https://phabricator.wikimedia.org/T53031 . 197.218.80.151 (talk) 21:14, 9 August 2017 (UTC)

197.218.80.151: The wp_no_image page is great, it could be used as a source. I don't think a bot add images automatically, because only a human can write captions. Adding to infoboxes might be an exception, as some infoboxes do not require a caption. "Lot of edge cases"? I would put the image just before the first line of text that does not start with "{", if you know articles where that would not work please send me the wikilinks, thanks! Syced (talk) 06:43, 10 August 2017 (UTC)
It is possible to generate simple captions automatically, after all the data stored in wikidata is structured.
There are so many edge cases that are easy to find, you've already mentioned the most common, many articles have template (e.g. notices or warnings) in the first line and no image at all elsewhere, along with other issues:

Templates in first section but without images:

Images in another section

The funny thing about "wikidata no image" is that in some cases even if the image is added it might continue showing up there because of how the pageimage extension works. The images need to fulfill certain criteria (e.g. certain resolution) before they are labelled as "page images". Just to be clear, this is a good idea, it just needs a good implementation that won't cause more problems than it solves ... 08:54, 10 August 2017 (UTC) — Preceding unsigned comment added by 197.218.88.131 (talk)
197.218.88.131: No problem with "Templates in first section but without images", I can automatically find a line to put the images in such cases. No problem with "Images in another section" as these articles will not appear in the list of articles with no images. No problem with "The_Jungle_Book" and similar, as Wikidata is much more stricter on copyright than wp.en: For instance, Wikidata does not contain any "fair use" image. Syced (talk) 02:25, 14 August 2017 (UTC)

With no provenance suggesting that it might have been drawn from life, the Thug Behram image linked from Wikidata blatantly fails WP:PORTRAIT. It should not be used as is. My fear is that making bots or automatic tools suggest the addition of such images means making the rest of us spend too much more of our time policing the articles they're added to and undoing the damage. —David Eppstein (talk) 07:40, 13 August 2017 (UTC)

David Eppstein: You raise an important point, Wikidata items may contain a mistaken image. Google Scholar does not have many papers about Thug Behram, and even less about its portraits. How about limiting automatic import to Wikidata images that have a reference? By the way, what do you think a reference for an image should look like? Do you have good examples that I could study? Thanks! Syced (talk) 02:25, 14 August 2017 (UTC)
In this case it's not mistaken (I have good faith that the artist really did intend to depict Behram) so much as valueless (if we don't know the context for the image then we can't put it into context in an article and we certainly can't use it without context as if it were an actual photographic depiction of the subject). In contrast, looking for other people from around the same time period found File:JOHN ADAIR colour corrected.jpg, a painting for which we know the artist, date, and that it was painted from life rather than from the imagination. That's the sort of information I'd look for when determining whether a painting or drawing should be used. But I got all that from its page on commons; on Wikidata it is just an image with no references. I conclude from this that the metadata on images that we're placing into Wikidata is still too sparse to be useful for this task. And because Wikidata only seems to allow "references" on image links, not any other kind of metadata, it will remain too sparse until the schema changes. —David Eppstein (talk) 04:02, 14 August 2017 (UTC)
In the idea proposal, I wrote that the tool should show the image's "title/description/categories/discussion" to the user. That's because I believe this information enables the user to decide whether an image is usable, and know what to write in the caption. Syced (talk) 05:29, 15 August 2017 (UTC)
At the very least there needs to be a way of flagging an image as unsuitable (making any such tool automatically skip it) so that people don't keep trying to add it over and over and over and over and over and... —David Eppstein (talk) 06:28, 15 August 2017 (UTC)
Indeed, the tool should include that flagging feature, similar to WDFIST. Syced (talk) 07:46, 16 August 2017 (UTC)

There's an image adding section at Wikidata:The Game. --167.58.55.39 (talk) 15:05, 18 August 2017 (UTC)

Upgrading Authority control

I guess the time has come to upgrade {{authority control}} to a core component of wikipedia. As it already uses wikidata, it would be a good step to show authority control bar above categories on pages by default, if it has values and get rid of the manually added templates in all the articles. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 07:24, 13 August 2017 (UTC)

Authority control is not always applicable to every topic. Also strictly speaking these are controlled topic identifiers (e.g., we also have LCSH in there and strictly speaking that is not authority control) that are most often in the form of external links (I know some editors have confused them with references). If your intention is to make this some sort of core component (which I am not sure we are ready for), methinks it might be more interesting to put these vertically in the navigation sidebar, e.g., under the interwiki and interlanguage links. 50.53.1.33 (talk) 01:42, 17 August 2017 (UTC)
I am proposing it as a core component only. The locations you have proposed seem good too. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:26, 18 August 2017 (UTC)

Wikiproject Members

Currently members have to be added to Wikiproject directory manually. Is there a way to auto-populate the list based on certain criteria like User pages with Userbox WikiProject, etc.? Also to know more about the level of user, his permissions and contribution history links can be shown. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:09, 13 August 2017 (UTC)

Userboxes usually add users to a category, which can be used to list participants who added it to their user page. A bot task could produce a more detailed or prettier list, but I'm not sure if a currently active bot does this. —PaleoNeonate – 23:44, 13 August 2017 (UTC)
You might be interested in Wikipedia:WikiProject Directory/All.
Mind the gap between "happens to work on these articles" and "actually wants to work as part of a group to work on these articles". Only some editors want to be part of a WikiProject (a WP:WikiProject is the people, not the subject area). WhatamIdoing (talk) 23:58, 13 August 2017 (UTC)
That's quite nice, thanks for the link. —PaleoNeonate – 01:54, 14 August 2017 (UTC)
@WhatamIdoing:That is indeed great, thanks! Is it possible show these results in Wikiproject page? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:34, 14 August 2017 (UTC)
You could transclude a subpage, e.g., Wikipedia:WikiProject Directory/Description/WikiProject Mythology (just pretend the page is a normal template, wrap it in curly braces, and the contents will appear on another page), but it's not very elegant, especially if you have a long list (WikiProject History's page, for example).
User:Harej is probably the best person to ask about this. WhatamIdoing (talk) 15:33, 14 August 2017 (UTC)

Wikiproject articles by size

A list of articles by size and quality comparison would be good, just as we have importance and quality comparison. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 07:14, 14 August 2017 (UTC)

Rather nice idea, I like it. Vorbee (talk) 07:59, 16 August 2017 (UTC)

Improving Merge procedure

Article Merger procedure is pretty slow and cumbersome, and most editors choose to stay away from the same. Category merger and template merger procedures have improved over time, but article Merger hasn't progressed as much as it was required to. Few of the major factors include lack of standardisation, non-effective templates, complex process and no bots involved for any of the tasks. I would like to invite suggestion to improve upon the same. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:54, 17 August 2017 (UTC)

On the contrary: The process is quite easy. You turn on Twinkle, nominate the pages for deletion, write a brief note, and determine if there's any opposition.
The problem is getting someone to actually merge the pages. This is easy, but it requires someone to care enough to actually copy content out of one page, paste it into the other page, and then copyedit the results. If you've got maybe 100 edits and know how to create a redirect, then you already have all of the skills. You just need the time and interest in doing important but slightly boring work. WhatamIdoing (talk) 20:10, 17 August 2017 (UTC)

Or, Capankajsmilyo, you can use the RfC process instead. But, like WhatamIdoing said, merging is a lot of work with needed skills. --George Ho (talk) 20:27, 17 August 2017 (UTC)

Some areas of Wikipedia require you to do one before nominating one, eg GA and DYK. This is a QPQ. Perhaps nominating for merge should be the same. Nominators have to do a merge before nominating another page for a merge. Graeme Bartlett (talk) 22:07, 17 August 2017 (UTC)

Unsourced info

Would it be a good idea to involve bots in the process of removing unsourced info from Wikipedia? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:56, 17 August 2017 (UTC)

@Capankajsmilyo: I dont think so. First of all, it will be very difficult to explain "what unsourced content is" to a bot. How do we define it? "a citation after every fullstop"? or "a citation after every 15 words"?
I have seen content in which an entire paragraph is covered by only one source, as well as content where just one sentence requires 4-5 sources.
How do we tell the bot to handle the paragraph mentioned above? He might keep only the last two sentences of the para, and remove everything preceding to it as "unsourced". If we need a bot to this task, the bot would require artificial intelligence. I couldnt find the essay/policy where I read it, but I think a bot with artificial intelligence is not recommended on wiki projects. —usernamekiran(talk) 13:31, 17 August 2017 (UTC)
@Usernamekiran: ClueBot NG is an artificial intelligence as we use the term when applied to bots. --Izno (talk) 13:42, 17 August 2017 (UTC)
@Izno: Yes. I think it was related to Clue family where I read about it. There is a cap/upper limit for the IQ of bots. —usernamekiran(talk) 13:54, 17 August 2017 (UTC)
To start with such a bot can start cleaning those articles and sections which don't have even a single source / cite. I am sure this simple logic can be fed into a bot. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:21, 18 August 2017 (UTC)
Why do you think that is a good idea? --Izno (talk) 15:37, 18 August 2017 (UTC)
To support WP:V and reliability of info on Wikipedia I guess... -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 16:00, 18 August 2017 (UTC)
Even that isn't as simple a problem as one might think. A naive approach would be to consider any article without any <ref> tags as uncited, but that is vulnerable to both false positives (articles which use {{sfn}}, articles which use plaintext references in parentheses) and false negatives (explanatory notes in ref tags which do not cite any articles). A limited approach could be to work on category:All articles lacking sources, but even that category contains articles which have external links to sources supporting claims in the article, even if they are not explicitly used as references (Special:RandomInCategory/All articles lacking sources gave me BoyBand (film) in four tries, for instance). Even if we could target this bot precisely, however, there's still the issue that we would be losing a significant amount of potentially valuable content (over 200k articles are tagged as having no references at all) without any oversight. Even if 99% of that is crap which is better off being TNT'd, that's still 2,000 articles which have value which we are losing. Caeciliusinhorto (talk) 17:02, 18 August 2017 (UTC)
A possible solution to preserving that information could be to move that info to talk page for active editors to consider. Then they can decide whether to source it properly and restore or to let it die. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 17:23, 18 August 2017 (UTC)

About offices

First of all, does every conceivable type of office really need its very own Infobox? For example, Template:Infobox Political post, Template:Infobox Bishopric, and Template:Infobox Monarchy are all arguably merge-able into Template:Infobox official post. Political posts, bishoprics, and even monarchies are all examples of offices, right?

Also, the Article Acting president is less than a stub and could easily be a Section of another Article, or maybe 2 other Articles. I could see a sort of fork-merge where it is "merged" into both Acting (law) and--hear me out on this--Regent. There are countries that don't fit neatly into a single category. The United Arab Emirates, although it consists of monarchies at the local level, actually has a President and not a King at the national level. (Although the Presidency is customarily held by the Emir of Abu Dhabi, strictly speaking the Council could elect someone else as President if it saw fit.) North Korea behaves exactly like a hereditary monarchy where the actual means of succession is concerned, but all 3 of its rulers have still insisted on calling themselves "President" and not "King." Here on Wikipedia we insist on calling Vatican City a "monarchy," but that is not what the Roman Catholic Church teaches! The Church's teachings are very clear that the Pope is not a King, but rather, a servant of Jesus Christ the King. (And this is coming from a Catholic.)

It is, however, quite cut-and-dry as to when an office is technically vacant and has a placeholder or substitute to tie things over. My point is this: The concept of a placeholder or substitute for a vacant office is much clearer than the exact borderline between a monarchy and a presidential republic. The qualifier "acting" and the title "regent" are 2 names for the same concept, albeit usually the application of that concept in different forms of government.

I know not which one of these 2 office- and officeholder-related issues to bring up first, which is why (for now) I brought them both up in the Idea Lab area of the Village Pump. The Mysterious El Willstro (talk) 03:08, 17 August 2017 (UTC)

A doubt regarding generalised notability

While reviewing new pages, I am often seeing articles of the pattern "List of programs broadcast by <TV channel>". I have even nominated an article for deletion before. Even though wikipedia has list articles, I am not sure about encyclopaedic nature of the lists of TV shows, as such a list is ever on-going, most of the lists are but this list would be increasing a lot as there are obviously many shows in a given month on a TV channel. Even though such a list would be "harmless", I believe it would not be an encyclopaedic one. (I cant think of any reason that would make such lists encyclopaedic.)

I am not sure what's going on with me. Maybe, with time, my expectations for standards of the term "encyclopaedic" have gone very high. But talking about these lists, I am not sure if a person checks such lists to find a show. If a particular show is notable enough for enwiki, the article obviously explains on which TV channel(s) it was/is broadcast. If a show doesnt have an article but is mentioned somewhere in another article, it can be mentioned where the show ran. Not exactly, but it is sort of "existence is not notability" here.

Do we have to create lists of everything that exists? These lists of TV shows are exactly same to "List of United States Armed Forces employees". A common argument to defend that list is "it is list of shows broadcast by a notable TV channel, it should be kept". A same argument can be made: "it is a list of employees of a notable armed force". Do we include only the subjects in the list who have their own article (TV shows, and employees of armed forces)?

What I am trying to say here is, I think the lists are not encyclopaedic, and we should come up with a guideline regarding the lists. Kindly let me know what you think. —usernamekiran(talk) 13:06, 17 August 2017 (UTC)

WP:LISTN exists; I suspect that the argument for notability for many/most channels's lists can be made based on that current guidance. Where these pages might fall afoul of current PAG is WP:NOTDIR. --Izno (talk) 13:24, 17 August 2017 (UTC)
@Izno: Apologies for not mentioning the WP:LISTN in original post. After the failed nomination I did go through it carefully, along with many other policies. Cant/shouldnt we make appropriate changes to this criteria, being a little precise about list of TV shows without being too hard/strict? —usernamekiran(talk) 13:42, 17 August 2017 (UTC)
@Usernamekiran and Izno: WP:LISTN is a terribly weak guideline. It lists one accepted notability criteria for lists, implying that other implicit criteria exist. For complex "List of X of Y" lists (which probably most lists are, including "List of programs broadcast by <TV channel>"), it simply notes that there is no consensus. In practice this is interpreted that such lists are always notable, which is terrible and the opposite of what notability guidelines are supposed to do. We should arrive at a consensus regarding this and make the implicit assumptions in LISTN explicit. – Finnusertop (talkcontribs) 16:25, 17 August 2017 (UTC)
List articles, such as list of programs that have been aired on a network, are frequently seen as split-off material from the main article on the network itself (in this case); if we didn't have WP:SIZE issues, that content would be part of the article on the network. Assuming we're talking only the programs that the national broadcaster airs , and not all the other programming its affiliates have, this can be historically relevant information if it is presented appropriately (eg by decades at a high level). However, wit SIZE, we often delegate such information to a separate page, and this is where and why LISTN has to be vague because there is no consensus that such splits have to have separate notability. LISTN prefers if you can, but if you try to make it stronger, there can be other valid lists that, as a whole, don't have notability as a list but are valid list in en.wiki's eyes, such as the numerous "List of people from (place)". I've offered the idea long ago that while these don't have inherited notability, which such lists are otherwise natural parts of coverage of a larger topic and just split off due to SIZE issues, that's a reasonable allowance for such lists. --MASEM (t) 16:46, 17 August 2017 (UTC)

External links to religious texts (e.g. Bible)

I noticed that quite a few articles contain biblequotes that have external links. Why don't we replace them with a link to Wikibooks-hosted version of the bible? I assume its public domain by now. (((The Quixotic Potato))) (talk) 21:01, 18 August 2017 (UTC)

such as wikisource:Translation:Genesis#Chapter_1_.E2.80.94_Originally ? — xaosflux Talk 21:09, 18 August 2017 (UTC)
@Xaosflux: Exactly. I don't see the point of linking to an external site when we (can) host these texts ourselves. (((The Quixotic Potato))) (talk) 21:36, 18 August 2017 (UTC)
I think it's a good idea, although the choice of translation(s) should be made, the external links are likely to remain when refering to a specific translation that is not locally hosted. —PaleoNeonate – 00:12, 19 August 2017 (UTC)
@PaleoNeonate: I am not an expert (I am an ignostic theological non-cognivist who knows next to nothing about copyright law) but I think that for example the King James Version can be hosted on a Wikimedia project, copyright-wise, and it seems to be widely used in the areas where most Wikipedians come from. https://en.wikisource.org/wiki/Bible_(King_James). Of course there may be a minority of links to translations that cannot be hosted on a Wikimedia project, but I think that that will be a small minority. (((The Quixotic Potato))) (talk) 00:41, 19 August 2017 (UTC)
Some of these are incorporated already, see {{Bibleverse}} — xaosflux Talk 02:27, 19 August 2017 (UTC)
We should assume that when the article links to a certain translation, it is done on purpose. Namely, the translation is the exact source that was consulted and that verifies the article content. For quotations this is painstakingly obvious: you can't quote one translation and add a citation to something entirely else. Why that particular translation is cited or quoted in the first place is a different question (for instance, KJV is not considered a particularly good translation and that is why modern academic scholarship doesn't reference it). We obviously cite the best, most reliable sources, not those that we can hoard to Wikisource. – Finnusertop (talkcontribs) 10:40, 19 August 2017 (UTC)
Agreed, we should only do this when it is the same translation. (((The Quixotic Potato))) (talk) 19:34, 19 August 2017 (UTC)

Talk header

Would it be a good idea to add talk headers to all article talk pages? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 09:34, 19 August 2017 (UTC)

The template documentation currently reads: "In accordance with Wikipedia:Talk page guidelines, this template should not be added to otherwise empty talk pages"; I myself for a short while was adding it to talk pages as part of routine citation cleanup but have stopped when an editor pointed me to this. Some (like the recent deletion nominator) have suggested to replace the talk header by automatic messages which would be another possibility... —PaleoNeonate – 17:14, 19 August 2017 (UTC)

Removal of subject's name

It is not uncommon for someone to write into Wikimedia (OTRS) expressing concern that a search engine search of their name produces some hits in Wikipedia. We have well-established procedures in the case of two situations:

  • Existing article If there is an existing article about them, we explained that we do not simply delete upon request, but we show them how they can request deletion (which they typically cannot do on their own) and offer to nominate at AfD if they need help. We encourage them to express their views in the AfD as some editors feel that in the case of a borderline case the subject's views ought to be considered.
  • Afd In some cases, an article about them has been deleted but the AfD discussion has some commentary about them that, while it might not qualify as an attack, is nevertheless not very positive. In those cases we may use {{Xfd-privacy}} which hides the discussion from immediate view but is easily accessible for knowledgeable editors. It will also be found in a search of their name. (As an aside, we are discussing whether this ought to be done automatically upon request or whether it should be more selective but will sort that out.)
  • Other mentions In other cases, the name may be mentioned in pages such as this archive page or this archive . It is is clear to me how this should be handled which is why I am posting this, to get community feedback. On the one hand, these archive pages may be viewed as necessary for editors to keep track of various things, and the fact that it mentions that an article about John or Jane dough has been deleted is a fact and we shouldn't go out of our way to hide it. On the other hand, some people are extremely concerned about privacy, and perhaps we shouldn't tell them simply that it is too bad, we insist on retaining the information in an easily accessible way. While no indexing might make it invisible to search engines, I think we ought to be careful about overuse of no indexing, and it may turn out that no indexing makes it difficult for editors to find (some still use internet search engines rather than the internal search function.)

I'm currently looking at a real live request (ticket:2017080410013898) where a person's name is mentioned in the page I linked and they have requested that we remove it. How does the community think we should respond?--S Philbrick(Talk) 19:05, 19 August 2017 (UTC)

AFD is currently NOINDEXed, so they are getting to those pages some other way. --Izno (talk) 20:39, 19 August 2017 (UTC)

Watchlist

I suggest a slight modification to user watchlist pages. Instead of just showing pages updated since the last view with a green dot, the modification proposed is to show the number of edits since the last view - say, a number following the dot or a number within a larger dot. The utility of the proposed would facilitate whether the user chooses the dif option (to see just one change) or the hist option (to track all changes since the last view). Regards Cinderella157 (talk) 08:17, 20 August 2017 (UTC)

I agree that it would be nice to see a pending changes count. I myself generally click on the history by default, because multiple edits may have occurred. However, with the multiple option, it is possible to see a certain number of recent edits. I don't use this feature because I find it more difficult to follow efficiently. For discussions I more often click on the little arrow before the edit summary, although oftentimes this is missing depending on the editor in use or if the user left a summary. What I find the most difficult is tracking new messages in huge threads where editors also comment anywhere instead of at the bottom. In this case I generally resort to using the diff (or the history if I've not tracked it recently enough). I also enable the bold option for unchecked edits because the green bullet is very small; making this bullet larger may be a good idea. A larger edit summary arrow would also be welcome as it is difficult to quickly click. I tried using custom css to make it larger but I couldn't target it without also affecting other unwanted elements. —PaleoNeonate – 10:18, 20 August 2017 (UTC)

Miscellaneous

Editing Archives

When did Wikipedia change to allow editors to post in Archives? What was the rationale for this? Is there a protocol or etiquette to follow when adding to or editing archived discussions???--Jack Upland (talk) 18:28, 8 August 2017 (UTC)

@Jack Upland: Do you have examples? ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:39, 8 August 2017 (UTC)
I meant Talk page archives; for example, recently at Talk:Joseph Stalin. I don't have a great problem with what the other editor did, but (unless I'm mistaken) it wasn't possible for editors like me to do that until recently (???) but now it is... There seems to have been a change with the permissions, and I was wondering if anyone could enlighten me when and why???--Jack Upland (talk) 20:19, 8 August 2017 (UTC)
It's possible that some archives are protected, or that there's an edit filter for new editors which checks for that, but I reverted edits to archives multiple times and have sometimes unarchived discussions. —PaleoNeonate – 20:28, 8 August 2017 (UTC)
As far as I know, there's no policy or guideline which restricts editing archives per se. The {{aan}} archive page header template says not to do so, but neither templates nor template documentation create policy. It is, of course, a idea which varies from bad to futile for several different reasons but to my knowledge there's nothing that authoritatively says that you can't do it. That doesn't mean, on the other hand, that it couldn't be seen as being disruptive depending on the apparent intent and circumstances and, of course, it could also violate the talk page guidelines depending on what is done. Regards, TransporterMan (TALK) 20:49, 8 August 2017 (UTC)
And if you're talking about the edits here, I'd say that they fall in the futile category, that is, edits by a newcomer who doesn't realize that they'll probably never be seen since they're on an archive page. — TransporterMan (TALK) 20:55, 8 August 2017 (UTC)
I've undone those edits and left a message on that user's talk page. That's generally the best way to deal with it (at least in my experience). ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 21:02, 8 August 2017 (UTC)
The usual protocol is to un-archive the discussion, and then reply. (Cut the old discussion out of the archive, paste it onto the regular talk page, and then reply as you normally would.)
There's never been a technical restriction beyond suppressing the section editing links, and sometimes edits are very helpful. For example, I've corrected links to other discussions (e.g., Archived Discussion #1 links to the now-archived Discussion #2) and added links to Phab tasks. It's not usually worth it, but sometimes the archived discussion is being actively discussed (e.g., at WP:DRV or in an WP:ARBCOM case). WhatamIdoing (talk) 03:18, 9 August 2017 (UTC)
The Teahouse archives don't have section links, which makes it harder for me, but the Help Desk archives do. Every now and then I see a link to a section on the Teahouse and because everything was archived, the link doesn't work, so given that there is a chance someone will find the discussion, I make sure the link works. There are other times when information just has to be corrected, or perhaps there was a response on a talk page and I just want to make clear the question was resolved.— Vchimpanzee • talk • contributions • 15:06, 9 August 2017 (UTC)
Thanks for all those responses. It appears that I naively assumed that editing archives was undoable, not just "not done" (inappropriate). You learn a new thing every day! I want to stress that I did not object to what Sein und Zeit did; I was just surprised that it was possible. Clearly it's better to post your comments in live discussions rather than comment in archived ones that other people are unlikely to read... The previous and more serious example I saw was that Sagecandour had peppered the archives of Talk:Whataboutism with comments re-asserting the opinion that he amply explained on the current Talk page. Putting this together with the Stalin edits by Sein und Zeit, I wrongly assumed that there'd been a change in policy... Evidently, I was wrong... Thanks once again to all who have responded.--Jack Upland (talk) 17:30, 9 August 2017 (UTC)

AFD nominations of "Sport at X games" and "Country at X games" articles

Lately, I have noticed an increased number of such articles being nominated for deletion, mostly for failing WP:GNG (examples include Wikipedia:Articles for deletion/Denmark at the 2017 World Championships in Athletics, Wikipedia:Articles for deletion/Tennis at the 2017 Commonwealth Youth Games and Wikipedia:Articles for deletion/Three-cushion billiards at the 2017 World Games – men's singles). While I personally have no strong feeling about such articles, I think such nominations are possibly problematic, since we literally have thousands of articles, all of them in the same format and usually with the same amount of sources (or lack thereof). There is WP:NOLY as a guideline already but it only applies to Olympic Games, not others. Should we have an RFC on whether such articles should exist? Again, no real interest, just bringing it to wider attention to avoid a potential overwhelming of AFD. Regards SoWhy 11:05, 9 August 2017 (UTC)

Such "event/team at multi-nation multi-sport tourament" articles only exist because it is impractical to cover every aspect of the entire tournament in a single article. An Olympic, Paralympic or Commonwealth Games spawns several hundred such articles - merged into one it would probably end up several megabytes long. Similarly, continental or world athletics championships result in dozens of articles. If the tournament as a whole is notable then every team, medallist, race/match at such a tournament is almost by default also notable because the media of every participating country will report on their team's performance. How often do such AFDs end in deletion? Excessive subdivision of articles should be avoided - sometimes a separate stubby article for every permutation of men's/women's singles/doubles heavy/middle/light is not justified, then merging is a solution. Roger (Dodger67) (talk) 10:25, 11 August 2017 (UTC)
"If the tournament as a whole is notable then every team, medallist, race/match at such a tournament is almost by default also notable because the media of every participating country will report on their team's performance." Not at all. While this is true for the major things like the Olympics, it is not true at all for small tournaments (like many youth tournaments or regional tournaments), where there are e.g. some articles about the tournament in the press of the organizing country ("Belgium welcomes young athletes from 12 countries in the 2017 U-17 Korfbal tournament"-style articles), but not enough coverage by far to warrant more detailed articles on "Luxemburg at the 2017 U-17 Korfbal tournament" or some such.
The above example is imaginary, but we have e.g. Gibraltar at the 2011 Commonwealth Youth Games, which is a "Good Article" but one that should be deleted anyway. It has at the moment "zero" independent sources (and yet it is a Good Article? GA assessment is an area in serious trouble...). Fram (talk) 10:47, 11 August 2017 (UTC)
I have started the GAR process for that article. The user listing it should be investigated to see if he made similar errors in judgement with other pages. --Izno (talk) 13:18, 11 August 2017 (UTC)
Here are sampled articles deleted per AfD: Hockey at the 2013 East Asian Games, Aquatics at the 1983 Southeast Asian Games, Lists of soccer matches at <venue>, Weightlifting at the 2015 Commonwealth Youth Games (redirected), etc. More at Wikipedia:WikiProject Deletion sorting/Sports/archive or Wikipedia:WikiProject Deletion sorting/Events/archive; type Ctrl+F (i.e. use your browser's "Find" tool) and then type " at " to narrow down results. Seems to me that such topics are subject to notability rules. --George Ho (talk) 15:17, 11 August 2017 (UTC)

Renaming

Should be renamed articles:

--SrpskiAnonimac (talk) 14:23, 9 August 2017 (UTC)

@SrpskiAnonimac: This is the wrong venue for requesting renaming. WP:RM has instructions for requesting page moves (and these move are not uncontroversial and need discussion to establish consensus to change the existing primary topic redirect arrangements. olderwiser 14:34, 9 August 2017 (UTC)
@Bkonrad: If they are similar articles (English, Spanish, Scandinavian, German, etc) why the debate is needed?--SrpskiAnonimac (talk) 14:43, 9 August 2017 (UTC)
@SrpskiAnonimac: While superficially similar, the context is quite different. For example, English and German have never been anything other than a disambiguation page while Spanish and Scandinavian have been disambiguation pages since 2001 and 2002 respectively. Putting aside that both Scandinavian and Spanish are currently pretty poor examples of a disambiguation page, English, Spanish, and German are inherently ambiguous in that they may refer to the language or to the people. Scandinavian arguably should be a redirect to Scandinavia as nearly all the entries are partial title matches, but that would be a separate matter. Español, at least as used in English, pretty unambiguously refers to the language. Even in Spanish, the term for people is Españoles, not Español. Except for relatively short periods, Español has consistently and mostly uncontroversially been a redirect to Spanish language. Old German is perhaps a weaker case. It was first created in 2004 as a redirect to Old High German, then almost immediately changed to be a disambiguation page. Then in 2006 it was moved to Old German (disambiguation) with the edit summary This title should redirect to "Old High German." The other usages are far less common and Old German has been a redirect to Old High German until your recent edit. Looking at the page, I'm inclined to agree with the edit summary for the 2006 move, but perhaps there is some evidence to indicate otherwise. Similarly, Aramaic (disambiguation) is nothing but a list of partial title matches and the Aramaic language article is clearly the primary topic. olderwiser 15:37, 9 August 2017 (UTC)

The Wikipedia Library Card platform

Wikipedia Library owl.svg

The Wikipedia Library team are happy to announce the migration of our free research access signups to the Library Card platform! The Library Card is a centralised location for signing up to all of the free resources available through the library - now totalling over 60 publishers and databases offering access to more than 80,000 paywalled periodicals to help you research and find citations for Wikipedia articles. On-wiki signup pages have been archived, and all future signups will be coordinated on the platform.

Log in directly with your Wikipedia account via OAuth, and if you find resources that would be useful to you, please sign up! Ongoing development will be occurring for the site, so please let us know if you run into any error messages or unexpected behaviour. You can flag bugs directly on Phabricator.

Later this year we'll be integrating an authentication system, enabling direct access to resources using your Wikipedia login. No more need to remember separate logins for each website! We'll also be using this system to allow automated no-application-required access to a subset of partners, and integrating it with a search tool to make it easier to figure out which aggregator or publisher has the content you need! Samwalton9 (WMF) (talk) 20:28, 9 August 2017 (UTC)

RfC about references and airport articles

Hello, your input would be appreciated at this RfC about how we should give references for the "Airlines and destinations" tables of articles about airports. Thank you. — Sunnya343✈ (háblamemy work) 11:44, 19 August 2017 (UTC)