Wikipedia:Village pump (proposals)/Archive 131: Difference between revisions

Now that Wikidata often has info about a particular Wikipedia page's corresponding Wikimedia Commons category or Wikisource page or the like, is it really necessary to keep this kind of templates in the article? They have the same function! I've removed this kind of templates in these pages, however sometimes someone reverted my removals, so here I ask other Wikipedians' opinion.--RekishiEJ (talk) 03:35, 30 March 2016 (UTC)

Keep them. IMHO it is really necessary to keep this kind of templates in articles and you should not remove them.
I think you're proposing that rather than have a direct link from an article to its corresponding Commons category (say), readers would have to find and click the "Wikidata item" link and look in Wikidata simply to find whether there's a Commons category, and if so, go to it?
Technically, that works, but Wikidata isn't user-friendly (nor intended to be); and anyway, it's surely much more friendly to have a link from a WP article to its Commons category, rather than make the reader go elsewhere simply to find out whether there is one!
With the increasing amount of linkage in Wikidata, it'd be good if these link boxes could be placed automatically, so that articles wouldn't have to contain templates such as {{Authority control}} or, indeed, {{Commons category}}, because the information would appear automatically. But I don't know whether such an enhancement is on the radar. — Stanning (talk) 11:48, 30 March 2016 (UTC)

• Keep, our sister projects are so intertwined with Wikipedia and its editors that more links, not less, should be the norm. All the images, for example, are now "off-site" in commons, so the lines are not only blurred but come together nicely. I've strongly advocated including a few sister-project links at the bottom of topic templates, for example, and hopefully more editors are coming around to that position as well. Randy Kryn 11:57, 30 March 2016 (UTC)
  • I mean, now that these info on Wikidata are shown on the "In other projects" section, is it really necessary to keep the templates anymore? For example, readers of the Wikipedia article
    Wikiquotes}} should be removed from the article.--RekishiEJ (talk) 12:38, 30 March 2016 (UTC)
• Keep - All templates are extremely helpful here and not only that but in the last 3/4 years of me being here I've never ever known about the "In other projects" section and that's because I obviously never pay attention to that area, So having these links makes it so much easier expecially for those who have no idea about the IOP thing, (BTW sorry but I've reverted you on the Dimitry article as you should really get consensus to remove them anyway), –Davey2010^Talk 01:59, 2 April 2016 (UTC)

  @Davey2010: "In other projects" has only existed outside of a Beta for a month or two. Before that, maybe another 6 months. So it is no wonder that "in the last 3/4 years of [you] being here" that you have not really known about them. --Izno (talk) 19:55, 3 April 2016 (UTC)

Ah well that would completely explain why I've never known in the 3/4 years ... cos it's never been there for that long! !, Other than checking a users contributions or to upload a file... I've never needed to use that bar so obviously don't pay sod all attention to it, Well I still believe the templates are better than the sidebar thing but that's just MHO. –Davey2010^Talk 20:41, 3 April 2016 (UTC)

• Keep. The template determines the display of the information – placement in the article, box at right, inline, individual or a list with others, the text for the link, and so on. The casual reader may well not expand and look through all the side links, indeed I also normally don't. In some cases the target name is not the best for the link text in a particular article, for example with Caroline Matilda of Great Britain, the corresponding commons category is commons:category:Queen Caroline Mathilde of Denmark: it is a matter of human judgement in each case whether the link text should be the target name, the article name, or something else. --Mirokado (talk) 21:00, 3 April 2016 (UTC)
• Keep, though it should be clear that mandatory inclusion of these should not be done. They're good templates to advertise content on these sites, and most of the time are purposely included to highlight this. However, while we might categorize some free content with a topic, it might not always make sense to force a link to that in the body (but letting Wikidata handle that otherwise), especially if the other content is otherwise thin, like one or two pictures that already used in the article in question. --MASEM (t) 22:06, 3 April 2016 (UTC)
• Keep in this article, the {{Commons category}} template is 19 pages from the "In other projects". Secondly, the side bar isn't part of the article. These are valid external links.

All the best: Rich Farmbrough, 13:06, 4 April 2016 (UTC).

Every month we have a disambiguation link-fixing contest at Wikipedia:Disambiguation pages with links, with the winners receiving immortality by being recorded in the Disambiguator Hall of Fame (and the top three being eligible for a free t-shirt from Wikimedia). There are two ways to earn points in the contest - one is to fix links to the top 1,000 most-linked pages at the beginning of the month, and the other is to fix links on the "bonus list", which includes all disambiguation pages with four or fewer incoming links. Over the years that we have been working on this, we have steadily beaten down the average number of disambiguation links per page until we have now reached the point that many of the top 1,000 have only five links. In fact, as of now, there are fewer than 1,000 pages with more than 5 incoming links. If we can keep that number below 1,000 through the end of the month, then we will have bridged the gap between the main list and the bonus list, and every single disambiguation link in Wikipedia at the beginning of May will count for the contest. If we could get a few dozen Wikipedians to each knock out a few dozen disambiguation links to pages with 5 or 6 incoming links before the end of the month, I'm sure we would handily make this goal. Cheers! bd2412 T 15:04, 4 April 2016 (UTC)

When we edit a page section, the edit summary is automatically populated with /* The section name */ which is parsed to form a link to that section.

We can manually alter that value, and even add more /* Section links */ using the same syntax.

I'd like to see the full section hierarchy automatically added when we're editing inside a nest i.e. If we edit a level 3 section, the edit summary would be auto-populated with something like /* Level two section *//* Level three child of level two section */.

This would make edit summaries clearer to understand (and in many cases that clarity is practically essential), especially in our watchlist. fredgandt 17:58, 3 April 2016 (UTC)

It would add clarity, but it would become an issue of too much automatic text in the edit summary restricting space for manual comments. What about including the level 2 header by default, and then the smallest section actually edited? For example, /* Level two section *//* Level three / four / five child of level two section */? Ajraddatz (talk) 18:13, 3 April 2016 (UTC)

I agree; it eats into the real-estate. I felt the proposal would be more acceptable if the change isn't drastic. Utilising the system already in use, with a little tweak would be trivial in coding terms (on the backend), and remain familiar. Ideally however, I'd prefer to see a more grown up system which required no special text in the summary at all. But yeah, as long as the end result shows the root section and that the edit was performed on a child, I could get behind leaving out a few parents. fredgandt 18:49, 3 April 2016 (UTC)

I would tend to support it, as long as it doesn't eat into the maximum edit summary length - which it currently does. עוד מישהו Od Mishehu 20:58, 4 April 2016 (UTC)

I can't speak for them (of course), but I doubt the WMF would be open to a lightweight request to consider removing section link handling from being text based. I think something like that would require a massive majority !vote. So assuming we're stuck with a text based solution, all we might hope for is to remove section links from the 255 byte count per summary, and to be honest, I doubt they'd go for that without a fight. The thing is, whilst section links are text based, we can remove them if they're in the way, so any additional ones automatically added would be not much more bother than the ones we already get. fredgandt 00:17, 5 April 2016 (UTC)

The only objections to your suggestions that I see are technical matters: "removing section link handling from being text based" would require a rework of quite a bit of code to store the section links in some unspecified other manner, and "remove section links from the 255 byte count per summary" (while keeping the summary as a text-based field) would similarly require some major reworking since the byte count limit comes from the size of the database field in which the summary is stored rather than being some arbitrary number chosen for nontechnical reasons.

There is T6715 which is about simply raising the byte limit, which is probably your best bet for getting action here. I think it's currently stalled on "new DBA objects to the old plan, new ideas are proposed but no one is working on making those new ideas happen"; you should probably ask on the task if you want to find out more. BJorsch (WMF) (talk) 20:03, 6 April 2016 (UTC)

It is possible to link to diffs (e.g. Special:Diff/12345678) and permanent links (e.g. Special:PermanentLink/12345678) in the move reason. In order to more easily check the links for errors, I propose a preview feature like the one for edit summaries. Iceblock (talk) 22:32, 5 April 2016 (UTC)

This calls for a change to the software - see Wikipedia:Bug reports and feature requests. As a workaround, click on any edit link, use the desired summary, and preview the edit; it should work the same way as the move reason. עוד מישהו Od Mishehu 11:26, 6 April 2016 (UTC)

It should be reasonably easy for someone to make a user script to do the preview using action=parse&prop=&summary=.... Anomie⚔ 20:08, 6 April 2016 (UTC)

On the side note, no task is hard for you, Anomie. --QEDK (T ☕ C) 14:27, 7 April 2016 (UTC)

I have seen long, lengthy words pushed from one sentence to another. Shall we have a system automatically detect syllables of every word and then break them to smooth alignments of every article? I was going to take this to "Idea lab", but this idea is as far as I go. --George Ho (talk) 19:23, 7 April 2016 (UTC)

On Firefox, Safari and IE 11 this is as easy as adding a hyphens: auto to the stylesheet. See e.g. User:Ruud Koot/vector.css. On Chrome this currently requires loading a rather large piece of Javascript. Automatic hyphenation will also screw up occasionally. Firefox's hyphenator also seems a bit too aggressive IMHO. —Ruud 20:00, 7 April 2016 (UTC)

I see your policies recommend that local forms of English (Indian, South African and so on) should be used on topics specific to a particular country. I've just commented as follows in the Talk section of the article on the Indian film 'Om Shanti Om' (which is obviously specific to India): "As a non-user of Indian English, I can't help wondering what such a specifically Indian word as 'lathicharge' is doing in a Wikipedia article. At first I thought it was a misprint, then looked it up and discovered what a 'lathi' is. I suppose there's no reason not to use such terms in Wikipedia (any more than 'lakh' and 'crore', or that ugly euphemism 'eve-teasing'), but it doesn't make for easy reading, especially if (like many Wikipedia users) your native language isn't English in the first place. As for 'Shahrukh Khan is communal' (just after 'lathicharge'), I can again only assume it's Indian English, since it means nothing whatever to me as a native English-speaker - except a vague hint that the guy may be sexually promiscuous! By the same token, I wouldn't use the word 'bold' in its common Irish meaning ('naughty', 'cheeky') or the Australian word 'bogan' in the middle of a text for an international readership." I really think there comes a point where keeping to local forms of English gets confusing, as I think it is here. Of course, I can look up 'lathicharge' and find out the meaning (as I have done), but I still have no idea what 'is communal' is supposed to mean. Perhaps Manoj Kumar (who apparently used the expression) simply doesn't know English very well, or perhaps this was an over-literal translation from Hindi (or another Indian language). Anyway, my proposal is that the policy be amended (if only slightly) in the interests of international intelligibility.213.127.210.95 (talk) 16:06, 7 April 2016 (UTC)

MOS:COMMONALITY says to attempt to use common words. The reason many articles (especially the Indian topics) don't is because (I suspect) most editors interested in those articles are from India or speak Indian English natively. --Izno (talk) 16:13, 7 April 2016 (UTC)

Thanks for this prompt and helpful reply! I was going to add that when translating into English (which I do for a living) I now tend to avoid English words that can easily be misconstrued by non-native speakers of the language. Classic examples are 'eventually' and 'actually', whose direct equivalents in other languages ('éventuellement', 'actuellement' and so on) mean something quite different ('possibly' and 'currently'). I now try to replace these two words with 'ultimately', 'sooner or later', and 'in fact', 'really' (whose meanings are clear to all), unless I'm quite sure that my readers will be native speakers.213.127.210.95 (talk) 16:21, 7 April 2016 (UTC)

Even if there is a localised English template on an article, it should not be any issue to convert jargon only understood in that region to more internationally known words. The example of Australian unique words would need converting as most of them are colloquial or slang, and not appropriate for written use. If a unique term is needed, then it should be explained, the same as for other technical language used. Graeme Bartlett (talk) 07:04, 10 April 2016 (UTC)

Hello Friends, I would like to suggest to Display pronunciation of the word searched by user in regional language, like in India, Regional language is Hindi or Marathi.

For Ex. consider a word Revoke so while displaying on wikipedia page as

Revoke ( रिवोक )

This will help reader to know the correct pronunciation of the word.— Preceding unsigned comment added by PGAwade (talk • contribs)

There's too many languages to do that, and many local languages cannot accurately represent sounds in other languages. Many articles do feature the International Phonetic Alphabet pronunciation, which is meant to be language neutral (in other words, anyone who speaks any language who learns how to read the IPA can use it to pronounce any word). Ian.thomson (talk) 04:03, 24 March 2016 (UTC)

• Strongest possible oppose This is the ENGLISH Wikipedia. We should never, ever have text in languages other than English except for cases like the native names of proper nouns. Also, in your example, there's nothing at all that would make Hindi or Marathi special with regards to the term "revoke", so the only way we could fairly do that would be for every word to be accompanied by hundreds of languages' worth of pronunciations. Jackmcbarn (talk) 20:49, 28 March 2016 (UTC)
• talk) 04:33, 29 March 2016 (UTC)
• Oppose, per Jack. The IPA for the standard English pronunciation should sufficeThere is already too much of English-as-an-official-2nd-language countries trying to turn the English Wikiedia into their Wikipedia. More effort should be spent by those nationals in developing and expanding their home-language Wikis (and believeme, living in the thick of it here in Asia, I know what I;m talking about). Kudpung กุดผึ้ง (talk) 11:23, 30 March 2016 (UTC)
• Oppose Unless the word is from another language, or is a proper noun, no real need to do this. My feeling is that it would just slow down Wikipedia. ThePlatypusofDoom (talk) 23:24, 7 April 2016 (UTC)
• Comment: Just what exactly the OP is proposing is highly ambiguous, and some of the above responses seem to have adopted different of the multiple possible interpretations. If the user simply wants a script that allows them to view a rough translation of a given word, utilizing manual selection I'd direct them towards [translate.google.com google translate]. If they want a script that translates and transcribes a term when places in our internal search engine, that would be a major project, though probably not infeasible in theory. If they want to have actual parentheticals which include a transcription of every term introduced for every language that could reasonably be concerned with the topic (of the article or term), that is obviously just not possible for a variety of reasons. Again, it's quite questionable what PGAwade is asking for here, but the least we can tell them is that, as a general rule, non-English content (especially in non-English scripts) is severely restricted to certain niche contexts on this project, as as a matter of longstanding community consensus as to pragmatics and the fact that this particular Wikipedia is meant to facilitate the sharing of information through English, insofar as article content is concerned. Snow ^{let's rap} 11:13, 11 April 2016 (UTC)

Problem a new article just by a small and big letter difference. an article "Vettar River" is made two times in name of "Vettar river".--wiki tamil 100 11:43, 11 April 2016 (UTC)

@

Vettar river) while leaving a redirect (as it appears a reasonably common typo). --Dirk Beetstra ^{T C} 11:49, 11 April 2016 (UTC)

Examples: A possible approach to such a correction, or this one (that one wasn't a Beatles recording, only Harrison was involved). (these were added after the first two comments below were made)

• I think how we do things now is fine. Most of the items which come up for discussion at
  WP:ERRORS are ephemeral anyways, and most changes are minor differences of wording or updates of changing or fluid situations. --Jayron32 11:47, 23 March 2016 (UTC)
  • The proposal is not for those kind of changes, but for real errors. I'll add some recent examples above.
    Fram (talk) 14:09, 23 March 2016 (UTC)
• The main problem with the main page currently is that the
  WP:ERRORS is too emphemeral and this makes it quite poor at handling issues which would benefit from some continuity, history and discussion. Andrew D. (talk) 13:46, 23 March 2016 (UTC)

  One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on.

  Fram (talk) 14:11, 23 March 2016 (UTC)

  Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)

  The general disclaimer page gets about 5000 hits per day. That's about the same as a mediocre DYK, which isn't much. Consider that this page appears not just at the foot of the main page but at the foot of every page. Hardly any of our readers are clicking on the link. One reason for that is that the link is blandly bureaucratic and boring. If, instead, every page said

  Wikipedia is not reliable!, it might get more attention. Andrew D. (talk) 21:54, 23 March 2016 (UTC)

• Oppose We are a website, not a printed source. A newspaper cannot edit already sold papers. And we have five million articles where lots of errors are found and corrected. The main page gets a lot of views and hopefully has fewer errors than average articles but I still don't see good reason to single it out and point out already corrected errors unless they are directly harmful, and I don't recall cases of that on the main page. PrimeHunter (talk) 14:35, 23 March 2016 (UTC)
  • The reason to single out the main page is that unlike other pages, it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors. It's not the part that anyone can edit, with all advantages and disadvantages that has, but the part that we (the community) choose explicitly to highlight, to showcase. That may of course not be enough for you to consider supporting this, and I don't intend to badger all opposes, but I just wanted to indicate why I do see good reasons to single it out.
    Fram (talk) 14:51, 23 March 2016 (UTC)
• Weak oppose, per PrimeHunter above. Rehman 14:46, 23 March 2016 (UTC)
• While I think reminding people that Wikipedia is full of errors is a good idea (there was something good about the time when the wiki was full of harmless vandalism of the "Kusma is gay! tell everyone!" variety, as that served as a reminder that Wikipedia is edited by random people and not always accurate), I don't like having extra policies for errors on the Main Page as opposed to errors in the content everywhere else. The main problem I see here is that it took more than two hours until the problem was corrected, which is embarrassingly long and probably something to point out whenever somebody opposes a good faith editor at
  WP:ERRORS is one of the more urgent admin areas. —Kusma (t·c) 15:09, 23 March 2016 (UTC)
  • Actually, more than 6 hours in that instance between reporting and correction. Getting errors off the main page (by correction or removal) is of course more important, and shouldn't wait until a correction has been written; it should be consecutive processes, with the error handling not dependent on the addition (or not) of a correction.
    Fram (talk) 15:14, 23 March 2016 (UTC)
• Oppose. Primarily because I don't see an actual point. Resolute 19:15, 23 March 2016 (UTC)
• Weak support I can see this helping the accuracy and transparency of Wikipedia. My main concern would be the implementation, but I'm open to a trial run to see whether there is any way of doing this. Jolly Ω Janner 19:49, 23 March 2016 (UTC)
• Oppose except where BLP issues are involved. For the most part, the readers who saw the error won't be likely to see the correction. עוד מישהו Od Mishehu 20:56, 23 March 2016 (UTC)
• Support A few years ago I would have agreed with the oppose arguments. However, it now seems to be standard practice on the web to indicate how a news story or other posting has been corrected, in the interest of fuller transparency. It is not a question of who might or might not see it, or what type of website we like to think we still are. It's a matter of principle; we may find ourselves behind the curve sooner than we think. Daniel Case (talk) 21:09, 23 March 2016 (UTC)
• Oppose it's not clear what errors qualify for main page "corrections". It's not clear how the demonstration of such errors fits into the main page design considering that errors can occur in every panel of the main page. There may be a case for a "Corrections" page which can be linked from the main page somewhere so we can confess our sins, but given today's little outburst, it's clear that "disclaimers" will be as erroneous as the errors they are attempting to disclaim. This is not path we need to tread, all articles in Wikipedia are subject to errors, after all. The Rambling Man (talk) 21:25, 23 March 2016 (UTC)
• Support I like this idea, and I agree with Daniel Case that this is a common practice that we should be adopting. Of course, my general opinion is that we put an enormous amount of volunteer effort into selecting and assembling content for main-page visitors who are mostly indifferent to it, and we'd be far better off coming up with alternative, more targeted processes of serving curated content to those likely to be interested in it. But given that we have what we have, I think we should be transparent about our errors and use the opportunity to highlight the wiki process. Opabinia regalis (talk) 21:55, 23 March 2016 (UTC)
• Oppose Errors can occur anywhere. We work on a basis of making corrections as we go. Hawkeye7 (talk) 22:03, 23 March 2016 (UTC)
• Oppose due to the nature of Wikipedia, errors are commonplace. We don't acknowledge previous errors on other articles, not even BLPs. The main page should not be an exception.
  flyer 07:51, 24 March 2016 (UTC)
• Oppose - Once something is printed or published electronically by a reputable news organization, it isn't expected to change. Wikipedia articles on the other hand are fluid and change is an expectation. By enshrining the errors within a certain version because it appeared prominently almost We shouldn't give the impression that we are holding our articles to the publishing standards of organizations who employ correction (newspaper), which we cannot due to the nature of the project. Errors both big and small can exist, and unless we have a body of volunteer scrutinizers to check articles (which begs the question why not preemptively do it), We already reasonably scrutinize the text before it appears on the main page, so if there is an error it might not be discovered or brought to light until much later. In that case more than likely individuals won't check to see if it was present in the version that was linked on mage page (in the unlikely case they even know or remember it has been there) when it is corrected, and the "correction acknowledgment notice" would fail to have listed it (unless there was to be a time limit to catch errors?). Furthermore, consensus would be needed on which errors to report (along the lines of which items to include in the news section). Obviously errors like falsely stating someone was a suspect in a notable assassination attempt nature would be reported if linked on the main page, but what about smaller factual errors. How long would an error within the text have to be live if it is corrected during the day to warrant a notice it is linked on the main page? This proposal would probably increase the rate of complex non-factual information being purposely introduced to the pages slated to be displayed there (or planted long before that then nominated) by malevolent editors with the goal of "making the correction acknowledgment notice". Lastly, maintaining a "correction acknowledgment notice" along with the other processes I've described above adds more non-essential work for our volunteers, who could instead be improving encyclopedia articles. Interesting idea, I liked it before I thought to hard about it.—Godsy^(TALK_CONT) 08:38, 24 March 2016 (UTC)
  • The proposal is not for errors in the articles linked to from the main page, only for errors actually put on the main page (e.g. for DYK, only errors in the one-line hook would apply, not all errors elsewhere in these articles). All texts put on the main page are already vetted extensively by editors here (through the FA process or the DYK process), so your question about the preemptive vetting is besides the point.
    Fram (talk) 09:24, 24 March 2016 (UTC)
    • I've amended my comment to reflect that, a good part of it still stands. Regards,—Godsy^(TALK_CONT) 13:23, 24 March 2016 (UTC)
• Comment: many people compare the main page to other pages, where no corrections are indicated. There are of course a few major differences, including the lack of history on the main page (it is relatively easy to see when an article stated version X or version Y of the truth; it is much harder for most people to find when the main page said X or Y, as it exists of transcluded subpages with different names). Articles are pages "anyone can edit", with the inbuilt risk that they will contain errors. The Main Page is not a page anyone can edit, but a severely restricted and vetted one. This of course doesn't mean that one should support this proposal, but I don't think that only opposing this because we don't do this on articles, is really a sufficient argument ("we have references on all articles, we should have them on the main page as well" would be a comparable reasoning, which I think many of you would oppose).
  Fram (talk) 09:24, 24 March 2016 (UTC)
• Oppose, per
  WP:NOT#NEW. Newspapers publish retractions and paper book publishers include errate sheets because they can't correct the extant copies. That does not apply here; we simply issue a corrected "edition" instantly.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:18, 24 March 2016 (UTC)
• Comment it would be worth adding a "correction" notice to the talk page of DYKs, for instance, that have suffered major issues and still been on the main page, after all the "DYK" hook is usually added within a template to the article talkpage. It would be easily traceable to add a "correction" parameter to this, or simply add a "Correction" section to the talkpage. The Rambling Man (talk) 11:22, 24 March 2016 (UTC)
• Oppose. We already know where these errors are coming from, this will do nothing to address the underlying issues. Gamaliel (talk) 14:59, 24 March 2016 (UTC)
• Oppose. What concerns me mainly about this proposal is that it would essentially create what amounts to a "DYK shame file" on the front page which would give incentive to those users opposed to DYK to find fault with DYK hooks and/or the underlying articles in order to add hooks to the file. Disputes over content and processes occur all the time on Wikipedia, the front page is not the place for them. Gatoclass (talk) 16:38, 24 March 2016 (UTC)
  • DYK is its own shame file sometimes already, this wouldn't change a lot about that. As has been said before, errors in the underlying articles have nothing to do with this proposal. This is about errors (not "finding faults with", but "finding factual errors in"). No idea why you add "disputes over processes", perhaps for the same reason you added "the underlying articles" to your oppose. Still, after your recent comments at WT:DYK, I'm not amazed about these inaccuracies, I just hope not to many uninvolved editors believe them.
    Fram (talk) 19:56, 24 March 2016 (UTC)

So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)

I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles.

Fram (talk) 10:32, 25 March 2016 (UTC)

Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)

Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above.

Fram (talk) 11:36, 25 March 2016 (UTC)

On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)

(on second thoughts, forget it. I'm done with replying to your wild accusations time and time again. People who follow DYK without seeing DYK as a goal in itself will know my real objections against it (which is not triviality), the amount of errors, and the amount of those I catch after they have been approved but before they hit the mainpage as well. Those things are more telling than whatever you may come up with next.

Fram (talk) 13:12, 25 March 2016 (UTC)

)

• Oppose - Serves no purpose. We already have Wikipedia:Main Page/Errors. — Maile (talk) 18:32, 24 March 2016 (UTC)
  • That page is for readers to contact us (editors) to correct a page. This proposal is for the reverse, to let the readers know that despite our vetting, we posted incorrect information on the main page. Which you are free to oppose, of course, but confusing things doesn't help.
    Fram (talk) 19:56, 24 March 2016 (UTC)
• Support assuming it's not ugly or intrusive. I think it'd be a service to readers to let them know when they have been accidentally misinformed. --
  talk) aka Jakec 19:27, 24 March 2016 (UTC)
• Support; above all, Wikipedia is a source for information, and any incorrect information which is distributed by Wikipedia should be corrected. Because of the high traffic volume of the main page, a mistake there carries more weight than a mistake elsewhere, and should be treated thusly. Something along the lines of the first of Fram's two examples above appeals to me; a small notation under the day's DYK's is nonintrusive yet useful. Colonel Wilhelm Klink (Complaints|Mistakes) 21:41, 24 March 2016 (UTC)
• Support Noting that online editions of newspapers do include corrections. As the possible negative impact on living persons where incorrect contentious claims have been made are clearly significant, and as
  WP:BLP avers that we must avoid damage to living persons, any error which might improperly affect living persons should be corrected with the same visibility as was given the incorrect claim or information. For matters of "how old was the fossil" - such errata are of far less importance, but where specific living persons are concerned, I find the "but facts are of minor value" position to be wrong. Collect (talk) 23:25, 24 March 2016 (UTC)
• Oppose. My opinions on the main page's accuracy issues are fairly well known, and I'd seriously consider abolishing the MP altogether and replacing it with www.wikipedia.org given the amount of hassle it causes for dubious benefit. That said, I agree with every word of I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not above. ‑ 
  Iridescent 11:29, 25 March 2016 (UTC)
  • Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK.
    Fram (talk) 11:39, 25 March 2016 (UTC)
    • You know my opinion of DYK, which I consider an embarrassment to Wikipedia, but in practice it's kept as a recruiting tool ("if you write an article, we'll showcase it on the main page") and virtually nobody actually reads the things. (The MP gets about 15-20 million hits per day, and the DYK project
      Iridescent 12:18, 25 March 2016 (UTC)
      • Okay!
        Fram (talk) 12:21, 25 March 2016 (UTC)
        • What I certainly would support is a three-strikes system at DYK, where any nominator who has three substantive "this hook is not true" complaints against them upheld is banned from DYK. I don't think I'm giving away any great secret in saying that a couple of editors are responsible for a disproportionate amount of the fabrications and mis-citations that get into DYK,* but AGF discourages people from calling them out on it because of the inevitable backlash from the regulars closing ranks. ‑ 
          Iridescent 15:27, 25 March 2016 (UTC)

• Oppose per Primehunter. Most DYK errors are not egregious enough and do not receive enough complaints from people to warrant special notice on the main page, especially since they are quickly corrected. If for some reason it does, a special case could be made, but I find that situation unlikely. I would instead suggest that stronger fact-checking is done during the nomination process to prevent this situation from occurring in the first place.
  ZettaComposer (talk) 14:11, 25 March 2016 (UTC)
• Oppose although I get where Fram is coming from. Not only is running a corrections column going to take extra editor work as well as valuable real estate on the Main Page, it really advertises shameful inaccuracies instead of being transparent with the reader. I agree with Andrew D that the disclaimer need to be far more prominent. Instead, why don't we hand out one-day blocks of editors responsible for these errors making it to the Main Page? Like Iridescent's three strikes concept, the editor is banned from those processes (DYK, ITN, etc.) where they've proven incompetent. Let's cure the disease (inaccuracy causing reader unhapiness) rather than treat the symptom (mollifying readers thru Mea culpa). Chris Troutman (talk) 15:35, 27 March 2016 (UTC)
• Support. I think that if a statement appears on the Main Page but is determined to be incorrect, it would be appropriate to post a correction on the Main Page, in hopes that the truth will reach as many people as the false statement did. Blocking the editors responsible for the incorrect information may be an appropriate punishment, but it doesn't by itself promulgate the correction. --Metropolitan90 (talk) 05:34, 28 March 2016 (UTC)

Blocking is not necessarily appropriate, because

blocks are not for "punishment". Especially on a first offense, the editor responsible for the incorrect information was more than likely submitting it in good faith, and mistakes happen even among competent, good-faith contributors. The correct approach is to advise them to learn from the mistake and move on. If the editor repeatedly makes the mistake in spite of numerous warnings/advice in response, that's when a preventative block or a ban from the process should be considered. Mz7 (talk) 21:15, 2 April 2016 (UTC)

• Support If the Main Page is run like a newspaper, then why not have corrections as well? Obviously some people are reading the DYKs. If the facts are in error, then we should attempt to inform those readers of the error. I also would support either a three strike or block policy for those responsible. FuriouslySerene (talk) 14:09, 29 March 2016 (UTC)
• Support Not only is pointing out mistakes important. Having corrections on the main pages seems like it can further Wikipedia's goals. One it emphases that all sources should be understood with critical thinking. Two it can be used to encourage new editors to help fact check. Wikipedia is building a information store to do that we need to engage with people that might be future editors. A DYK "editted" section seems like it could benefit us. PaleAqua (talk) 19:32, 3 April 2016 (UTC)
• Support ... but we can do better. Fram said the reason to single out the main page is that "it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors". I disagree, firstly the reason is that the main page is different type of publication, more like a journal than an encyclopaedia. But more importantly it should get heavily scrutinised, but DYK, as both Fram and I have pointed out in the past (and unless things have changed) is often inaccurate. I would suggest we consider a pre-publication of the queues so that the DYKs get more eyes on them. (At the moment the queues are all empty... which is not a good situation.)

All the best: Rich Farmbrough, 12:05, 4 April 2016 (UTC).

• Support It has become standard for on-line sources to acknowledge changes made. I'd go a step further and note any changes made, but what Fram has proposed is a fine start and maybe enough. Hobit (talk) 08:17, 6 April 2016 (UTC)
• Create own page It would be best to have a special page, in a link at the bottom of the screen. It shouldn't be part of the actual encyclopedia. ThePlatypusofDoom (talk) 23:26, 7 April 2016 (UTC)
• Oppose. I too appreciate Fram's motivation here, but this seems unwieldy and inconsistent with our encyclopedic model. The main page has little enough space as is, and is largely already monopolized by the news and media elements; little enough space is already given to navigation and other pragmatic uses in order to accommodate these features without adding one more section that seems to suit anything but an encyclopedia. As others have said above, mistakes occur all over the project every day, but our model is the correct mistakes and focus on revising content, not tracking historical errors for our readers.

Besides, I also agree with those who have pointed out that an ounce of prevention here would be worth a pound of cure; rather than creating a system to call out our mistakes, we should have more robust editorial/consensus processes for those elements of the main page, if people are truly convinced that errors there are of significant concern. Though I think talk of banning people for good-faith mistakes is excessive as well. How about we start with a certain proscribed amount of fact-checking and increasing the number of editors who must validate a given fact in DYK or ITN. I've never contributed more than incidental edits in those spaces, so I'm not sure if there are certain editors known for sloppiness and a gung-ho behaviour, but it might be worth discussing TBANs for them, but only under the most severe of circumstances where there is broad consensus that they exhibit a combination of incompetence and IDHT. Snow ^{let's rap} 04:01, 9 April 2016 (UTC)

Note: {{Did you know/Queue/{{Did you know/Queue/Next}}}} should display the next queue. I have added this to my talk page header. All the best: Rich Farmbrough, 12:13, 4 April 2016 (UTC).

• Oppose - It seems redundant and unnecessary to make an additional note or create a new page for any corrections/errors. Because we can correct the information immediately, I see no reason to do anything further. Meatsgains (talk) 03:57, 9 April 2016 (UTC)
• Support – It seems unconscionable to me to feed readers incorrect information and fail to take any proportional remedial action. Firstly: of course there is a difference between minor edits of the style commonly requested at Main Page/Errors and outright falsities. It should be assumed that correction notices are unnecessary for grammatical or stylistic subtleties, minor ambiguities and the like. The proposal already states that this would only apply to factual errors. As far as the idea of a "shame list" goes, people should be wary of introducing factual errors, and perhaps it will serve as an incentive to be thorough in editing. I don't consider an impersonal correction notice to be a "shame list" anyway, though; very few people check or care about the individual people behind the DYK hooks anyway. The "encyclopedia, not a newspaper" point is well-taken, but highlighting information on the main page is an editorial judgement and should be subject to similar standards of integrity to other forms of edited publishing. —Nizolan ^(talk) 01:17, 12 April 2016 (UTC)

Template_talk:Autoblock#Template-protected_edit_request_on_14_April_2016. Comments here or there are welcome. Feel free to throw questions at me. --QEDK (T ☕ C) 15:12, 14 April 2016 (UTC)

No, comments here should not be welcome - please don't encourage people to go against

WP:MULTI. --Redrose64 (talk) 15:58, 14 April 2016 (UTC)

My bad. I was expecting questions here about that actually but well. I will claim innocence with that "or". --QEDK (T ☕ C) 16:36, 14 April 2016 (UTC)

Hello folks,

Our

Please let me know how you think about this proposal. Thank you!

Regards, <<< SOME GADGET GEEK >>> (talk) 02:24, 10 April 2016 (UTC)

Just to throw one practical concern out there, this seems like it would cause a massive backlog of edits awaiting review, something like a week or more. --Bongwarrior (talk) 02:30, 10 April 2016 (UTC)

Support Even though I agree with Bongwarrior, BLPs have become a major issue across Wikipedia and I have had to revert a countless amount of vandalism on BLP articles. — Music1201 ^talk 05:40, 10 April 2016 (UTC)

• Strong Oppose I agree with Bongwarrior, the backlog would just be way too much. — Omni Flames (talk contribs) 07:12, 10 April 2016 (UTC)
• Oppose because not all BLP's need this level of scrutiny. I know of quite a few BLP's that are hardly edited (not even vandalized).--Jasper Deng (talk) 07:18, 10 April 2016 (UTC)
• There are presently 1,092,447 BLPs on Wikipedia (number dynamically updated). I doubt this would be feasible, though I agree with your concerns. BethNaught (talk) 07:19, 10 April 2016 (UTC)
  • Technically, I think that writing an adminbot to handle this would probably be practical; a one-time run on all non-protected BLPs, and real-time maintenance would probably work. It could certainly remove PC on any BLP when the category is removed by an account with over X months and Y edits when the protection reason includes any of specific words; and report any BLPs with PC when either the removal is done by a newer account or where the protection reason is anything different. It could also monitor any additions to
    CAT:LP and use a protection reason which uses one of these words. I think, though, that we have a different issue here - the backlog of pending changes. עוד מישהו Od Mishehu 04:49, 14 April 2016 (UTC)
  • To put it in perspective, that's approx. 15% of all articles.—Godsy^(TALK_CONT) 05:24, 14 April 2016 (UTC)
• Per Jasper, basically. Not all BLPs need the extra layer of scrutiny. I do like PC in that it lets anyone still edit (I would certainly oppose any attempt to mass-protect articles), but I don't think this idea is practical or particularly needed. Ajraddatz (talk) 08:51, 10 April 2016 (UTC)
• Oppose partly as per Bongwarrior and Jasper. Also i dislike PC protection in general, it takes away from the immediacy that is the Wiki experience, adn can confuse new editors. DES ^(talk) 15:10, 10 April 2016 (UTC)
• Qualified Support I would point out that certain areas now have a more stringent rule than this (the 500 edit rule), and that the "backlog" of BLPs is exceedingly unlikely to reach even 2,000 edits, much less hundreds of thousands. In fact, many articles are not edited as often as once a year in the first place. So the "it would inconvenience us to require vetting of edits by IPs" is weak. Rather, it is the fact that some edits may cause actual harm to living persons which should govern our actions - if we have a tool to prevent harm, we would be remiss in dismissing it. Collect (talk) 14:55, 11 April 2016 (UTC)
• Weak support I think the fact that vandalism to BLP-articles doesn't go "live" is slightly more positive than the problem of, admittedly, confused new editors. As for the workload....we just would have to see. Lectonar (talk) 15:10, 11 April 2016 (UTC)
• Oppose - we need to keep PC down to an appropriate workload level; since BLP edits are too frequent, it will make the PC log be too backlogged all the time. עוד מישהו Od Mishehu 09:33, 12 April 2016 (UTC)
• Oppose due to the surety of a backlog in this proposed process. There aren't enough WikiGnomes out there. GenQuest ^{"Talk to Me"} 00:12, 14 April 2016 (UTC)
• Oppose - I've been known to check Special:PendingChanges and review pending changes from time to time. It isn't uncommon for some changes to remain un-reviewed for 12 hours or so. To apply this en masse to biographies of living people which haven't been shown to be problematic would be in violation of the regulations community consensus set for pending changes protection. Secondly, this would be way too many edits for our volunteer community here to reasonably review in a timely manner (on a side note: only approx. 8,000 users have currently have this right). The only pragmatic way to guard articles in this way would be to disallow un-registered and non-autoconfirmed users the ability to edit biographies of living people, though I wouldn't support that either, and I believe similar proposals have failed to gain consensus in the past.—Godsy^(TALK_CONT) 05:12, 14 April 2016 (UTC)
• A more useful approach might be to sit down with a database query and make a list of the "1,000 most reverted BLPs", and consider just those. WhatamIdoing (talk) 18:09, 14 April 2016 (UTC)

I have never understood why this does not already happen. The edit filter is the closest way to technically prevent editing on a certain topic.
Example: User XYZ was topic banned from editing restaurant related topics. An edit filter could be enabled to prevent user XYZ from editing articles with the "Restaurants" category. — Music1201 ^talk 05:37, 10 April 2016 (UTC)

But is the breaking of topic bans really a major problem? When it does happen, the user who breaks the ban is usually blocked very quickly by administrators. — Omni Flames (talk contribs) 05:45, 10 April 2016 (UTC)

I'm not sure how many users have topic bans, but we have a tough enough job maintaining the filters we already have. The number of filters/changes required would what, triple? The Category:Restaurants contains 22 direct subcategories, and would not contain all restaurant-related topics. The relevant categories to be checked would include things like Restaurateurs, Gastropubs in the United States, and Soup kitchens. The categories don't include templates, project pages, or talk pages. Additionally, most topic bans have several exceptions. These things add up to quite complex tests, which are also expensive in terms of the edit filter condition limit - a limit which disables the edit filter when there are too many matches. In my experience there is nothing better to pick up topic ban violations than other users editing in the same areas - edit filters are no match. -- zzuuzz ^(talk) 06:46, 10 April 2016 (UTC)

The problem is that I don't think there's a straightforward algorithm to tell if a user is violating a topic or interaction ban, and our edit filter system already can't handle this many more filters.--Jasper Deng (talk) 06:53, 10 April 2016 (UTC)

To expand on what Jasper Deng said, there is a restriction on how many filters there can be, because they are all applied while saving, and if there were too many of them then the save time would become noticeably longer. It's also very technically difficult to make a filter which would match every case for the topic ban, and so I think manual scrutiny is a better option for most cases. There would be ways to accomplish this through new extensions here, but probably the abusefilter isn't the best way. Ajraddatz (talk) 08:53, 10 April 2016 (UTC)

• I would oppose this as per zzuuzz's and Jasper Deng's comments above. Edit filters must be applied to ewvery edit saved by every editor, and may not be too complex. many topic bans are quire complex and not really suited for algorithmic detection, even with a rather more powerful system than edit filters can support. I would hate to try to program such a filter. Consider how many topic bans include the words 'broadly construed'. DES ^(talk) 15:07, 10 April 2016 (UTC)
• Any eidt filter we create must meet 2 basic criteria: They must have a reasonable number of hits (not too few, since that would make it a waste of resources; not too many, since that would probably show that the filter is catching too many false positives); and it must be quick enough to check for every edit. I doubt that there is much ArbCom enforcement that could be written into filters which meet both of these criteria. עוד מישהו Od Mishehu 09:36, 12 April 2016 (UTC)

• Mwaagh, I think that this is in principle a good idea that I c/would support, it may only be a technical problem why we don't. But these filters can be reasonably fast: IF (user_name) EQUALS <restricted user> results in a false for almost every edit, and would not cost a lot of resources. Adding a "AND page_name IS ONE OF "list of pages" will add some processing time for the edits that do hit (but then, only for the restricted user .. and such an editor did not get restricted for nothing; it would need some paperwork to get the list done, which could always be expended when necessary), but in general this will not bring down Wikipedia. Then you add further specifications down the line if needed, or you leave it at this and let it just 'tag'. It only becomes a problem if the restriction is not too page and not too user specific ("no-one should edit these 2000 pages long list of pages more than 3 times in any stretch of 7 days"). If the filter is tag only, it becomes a quick checklist, and if it is specific enough it can be restricted as well.
• I think that the real question is, why does the WMF not either allocate more processing power to the edit filters to both speed them up ánd so the community has the possibility to write more edit filters, or have the development team write 'clones' of the abusefilter for commonly used tasks and which can then run much faster by design: a check enforced by code (only apply this when user = <username>) or only apply this when user-right = unconfirmed-checkbox) is always faster than a check of an interpreted code (interpret "if user = <username>" or "NOT user-right = confirmed", fill in the variables and then get the result) - and there are many filters that start with these checks that we now don't write just because overall it is too slow at the moment, and the suggested filters are among them. --Dirk Beetstra ^{T C} 10:57, 12 April 2016 (UTC)

• I oppose of this, if a sanctioned editor can't follow the terms of their restriction the door is right over there. — xaosflux ^Talk 12:14, 12 April 2016 (UTC)
  • That is true regardless if you use an edit filter to block the edits / detect possibly conflicting edits or not (in the end, this just gives you an easy to access on-wiki record), so I am not sure what you oppose here. --Dirk Beetstra ^{T C} 13:03, 12 April 2016 (UTC)
    • To clarify, managing the edit filter is a careful balancing act of scalability of the tool, and administrative overhead of the filters - managing comprehensive lists of user to page/category mappings is setting us up for a management nightmare - we already have enough headache when short-term filters have to be built for individual vandals. — xaosflux ^Talk 18:29, 12 April 2016 (UTC)
      • I see that point, but that goes both ways. The current bans are an administrative nightmare as well. Sneaky editors could circumvent bans, and many editors are not aware that a certain editor is banned from certain topics, and edits may go through because of that. It needs quite a number of editors to keep an eye on the edits of a banned editor to see if they are editing in violation of said ban (and you see that happening, some editors turning into a form of WikiPolice, and just a couple of the editors become the judge of the appropriateness of the edits by the banned editor). --Dirk Beetstra ^{T C} 08:06, 13 April 2016 (UTC)

• If the edit filter system were optimized to the point that we could have 1000s of filter with no discernible impact on performance, then sure we could apply per user and per page filters. Right now the limits placed on the filter system (in part due to design issues that could be improved) mean that we need to prioritize its use for filters that are likely to get significant hits and avoid filters that are so specialized that they will rarely be triggered. Dragons flight (talk) 13:21, 12 April 2016 (UTC)

  Even if we had much more powerful hardware and software, Dragons flight, even if we could apply the full power of, say, IBM's "Watson" to each and every edit separately, correctly determining which edits do and which do not fall within a complex topic ban is not a trivial task for an algorithmic system. And a filter that gets it right more often than not but has a significant error rate might be worse than useless - we might trust the filter more than we should, leading to worse outcomes. Until we can run edits though HAL9000 or some other truly intelligent system, I don't think this is a task to approach with a program. DES ^(talk) 18:24, 12 April 2016 (UTC)

  I'm imagining that an Arbcom directive gets implemented as a filter simply saying that X person is not allowed to edit articles A, B, and C. Human(s) would have to decide on the list of which articles are covered, but the filter itself would be easy to implement. To the extent that the targeted list ends up being incomplete / incorrect, one would have to allow for additional articles be added or removed from the list, again subject to human review. However, we already have edge cases and discussion about interpretation of various Arbcom restrictions. All of this HAL9000 stuff is a red herring in my mind. We don't need an edit filter that can decide which articles involve "Neoclassical Romanticism" (or whatever the prohibition de jour happens to be). We simply need humans that are willing to discuss what the prohibitions ultimately mean and try to spell it out in concrete terms. (Of course if humans aren't willing to do that, then such filters will probably never be created.) Dragons flight (talk) 18:46, 12 April 2016 (UTC)

  But in practice I have yet to see a topic ban defined in terms of an explicit list of articles. It is always of the form "Editor:Example may not edit articles connected with Neoclassical Romanticism, broadly construed". Sanctioning admins are supposed to employ judgement in assessing any given edit as to whether it violates the terms of the ban. In some cases things are broader: "Editor:Example may not make any edits on the subject of Neoclassical Romanticism, broadly construed, in any any article at all". Here it is the subject of the edit, not the subject of the article, that is the criterion, and human judgement at the edit-by-edit level is even more obviously required. This flexibility is by design, to avoid the subject of the ban gaming the system, and to afford the sanctioning party some leeway when what seems to be a technical violation doesn't fit the reasons for the TBAN. If the cost of programmatic enforcement is that an explicit list of affected articles must be compiled in advance, i don't think most people will see it as an improvement. And in the absence of such a list, separating violations from legit edits is a hard problem. I honestly don't think current AI is up to making that distinction with sufficient accuracy to serve this purpose at this time. DES ^(talk) 22:14, 12 April 2016 (UTC)

  When I use edit filters, I generally do that to detect editors. I have a block-evading editor with reasonably signature edits using one or two ranges, or mainly targetting specific pages, and I write a filter on that. Does that filter catch everything? No, it catches maybe 90% (and people find a way around). Does that make the filter useless? No. If the editor trips the filter once, I know to check the other edits as well. Is my filter finished? No, I regularly have to add pages, signature edits, etc. Do I have to now consider that if my filter is not tripped that I can assume the editor is not there? No, but instead of checking every day the whole range, I check once every week. The filter is saving me work.

  The same would be true here. Some bans are plain clear: 'stay away from subject X'. Hence, there are no edits that are not a violation of TBAN, every single edit is. The instruction is clear, stay away. That is very easy to catch in a blocking filter, an expandable list of pages not to touch. If the ban is not that black and white, then indeed the edits may not be blockable, but then the filter goes to tag-only and people will check the hits to the filter (if it has a visible tag, even other editors may do that work for you, bringing down the workload). And there will be bans that are not suitable for this at all, and nothing will change, you will have to do everything by hand. A sneaky banned editor may be able to do edits under the radar, but with the help of filters, that radar has a much finer maze to detect. --Dirk Beetstra ^{T C} 07:56, 13 April 2016 (UTC)

  It should be noted that I think the filter does not use short-circuit evaluation (I think it's a long-requested feature though), which would negate the benefit of checking the username first in an and expression (as would be required by the filter).--Jasper Deng (talk) 21:21, 14 April 2016 (UTC)

As discussed at Wikipedia:Village pump (technical)/Archive 145#Preferred protocol for external links templates, there seems to be no consensus as to whether, if an external site uses both https and http, our links to it should use the former, the latter, or be in the protocol-agnostic form //example.com/foobar. This is particularly significant for templated links, such as those in {{TED speaker}}, but also applies to hand-crafted links.

I therefore ask should we:

• a: use https://
• b: use http://
• c: use //

I will post neutrally-worded links to this discussion, in {{

Moved from Wikipedia:Village pump (technical) § RfC: Preferred protocol for external links

 – Per user suggestion, with OP's blessing. ―Mandruss ☎ 19:06, 8 April 2016 (UTC)

Prefer 'a'

Prefer to use https://

1. I'll play. Support this option per prior RfC, which established clear consensus for HTTPS for links to Google and Internet Archive—until someone shows how these cases are substantially different from those and therefore need a new debate and separate consensus. ―Mandruss ☎ 18:50, 8 April 2016 (UTC)
2. Kaldari (talk) 19:00, 9 April 2016 (UTC)
3. Per Mandruss.
   talk!) 00:36, 15 April 2016 (UTC)

1. Less things that can go
   wrong. –Be..anyone 💩 22:59, 12 April 2016 (UTC)
2. Most websites will upgrade the connection to https:// if the browser supports it, like Wikipedia does, and if we link to http:// websites that do not support https:// with https:// links, then those links will appear to be not working. Tom29739 ^[talk] 17:36, 13 April 2016 (UTC).

   This RfC has nothing to do with websites that do not support HTTPS. Please read the intro. However, http://news.google.com does in fact upgrade to HTTPS, as you say. That would appear to change the issue somewhat. I wasn't involved in previous discussions, so I don't know whether that was considered there. ―Mandruss ☎ 17:48, 13 April 2016 (UTC)

   Bender235? ―Mandruss ☎ 18:00, 13 April 2016 (UTC)

   Update: The upgrade was apparently being done by my browser (Firefox), not by Google, because I had previously visited news.google.com in that browser using HTTPS. When I tried it in Microsoft Edge, which had never visited that site, it did not upgrade. ―Mandruss ☎ 18:30, 13 April 2016 (UTC)

That's an Edge bug, I suppose. Most major sites like Google have HSTS enabled now. --QEDK (T ☕ C) 17:11, 14 April 2016 (UTC)

Prefer 'c'

Prefer to use //

1. No reason to force the protocol on people; the encryption adds overhead and some people (e.g. on metered bandwidth) don't want it. Second preference is for 'a'; if we were to force one, it should be the secure one, per common sense.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 12 April 2016 (UTC)

   @

   this option merely carries forward the existing protocol, which for Wikipedia is now always HTTPS. Thus, 'a' and 'c' are identical in effect, for links from this site. There is no option that does not "force" one protocol or the other; 'a' and 'c' "force" HTTPS and 'b' "forces" HTTP. ―Mandruss ☎ 18:32, 12 April 2016 (UTC)

   If you tell it "//", will it not try https://, and failing that, fall back to http://? I thought that was the point. I might well be misinformed. If it's just an alias for "https://", then yes, let's use that instead.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:01, 12 April 2016 (UTC)

   If that's how it works, our article is incorrect (see "this option" link in my previous comment). ―Mandruss ☎ 20:22, 12 April 2016 (UTC)

   A relative URL starting with "//" means to use the protocol of the current page containing that link (so https) 162.198.40.56 (talk) 21:57, 12 April 2016 (UTC)

Discussion of link protocols

• Speedy close. Did you ignore or simply not see the below from the Archive 145 discussion:

  @Pigsonthewing: The January 2014 link [Izno: inserted link] is that general consensus; the individual site consensuses have been specifically to modify all uses of those protocols for those websites to HTTPS via (semi-)automatic method (so as to explicitly suggest that the edits being made do not run afoul of WP:COSMETICBOT). You can probably make an argument after-the-fact, if questioned, that those RFCs show that COSMETICBOT is not infringed on w.r.t. TED links, but it is usually better to show such a priori.

  People arguing against that consensus after-the-fact does not make that consensus disappear and are just (equivalently)
  forumshopping. --Izno (talk) 11:53, 8 April 2016 (UTC)
  • How is that related to the RfC above? It seems pretty reasonable to ask how an external link should be formed. I saw the VPT discussion and it was a bunch of mumbo jumbo in response to a simple question—what is preferred? Johnuniq (talk) 12:16, 8 April 2016 (UTC)
  • I neither ignored nor missed it. Did you ignore or miss me explaining why the claimed consensus is not apparent? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:42, 8 April 2016 (UTC)
• Oops, I followed a link without noticing this is VPT. That is not a good place for an RfC. Please put it somewhere else because this is a high-turnover page focused on technical stuff, not interminable discussions. Johnuniq (talk) 12:19, 8 April 2016 (UTC)
  • Be my guest. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:42, 8 April 2016 (UTC)
    • Moved here (VPR) from VPT. ―Mandruss ☎ 01:16, 9 April 2016 (UTC)
• Oppose 'c' - Less recognizable as a link to the
  layman.—Godsy^(TALK_CONT) 04:14, 12 April 2016 (UTC)
  • @Godsy: This seems easily recognisable as a link to me: Layman. How does it not, to you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:16, 13 April 2016 (UTC)

Invalid Question

Please explain exactly why you think this is invalid (wrong place, consensus already established, begs the question, etc)

1. Invalid Question The question says "there seems to be no consensus" but the strong consensus as established in multiple discussions is to use HTTPS whenever and wherever possible (including external links) and to use HTTP only when HTTPS fails to bring up the desired page. (This is also posted in the wrong place, IMO, but that can be easily fixed with a move and a link to the new location.) --Guy Macon (talk) 15:10, 8 April 2016 (UTC)

This pretty much sums it up. Google and Archive.org support and encourage HTTPS connections, but so do Yahoo.com and a couple of other sites. For instance, HTTPS works for a lot of university websites, such as U of Chicago or Brown U, therefore we should link to the secure connection preferably. Only if HTTPS is not supported, we should leave HTTP. --bender235 (talk) 20:14, 13 April 2016 (UTC)

WP:Related_Pages_extension/RfC isn't quite a "proposal" at the moment, but it could become one and it needs more people to comment. The WMF built an extension to add machine-generated "See Also" style links at the bottom of all articles. They are asking for our view on it, and how we might want it improved. It is currently available in the Beta Features section of preferences, and they may offer it for default-activation on wikis that want it. Alsee (talk) 11:35, 15 April 2016 (UTC)

I'd like to announce an IEG proposal I am working on titled "Learning from article revision histories". The goal of the project is to help editors see how the editing process unfolds over time by visualizing revision histories as trees of edits. In particular, the project evaluates the effectiveness of the

This proposal has benefited greatly from community feedback since its inception, and now integrates more closely with the ongoing work by the WMF in this area. If you have a chance to give me your feedback on the project as an editor, a software engineer, or a researcher, I would be appreciative and the project would surely benefit. -- Evoapps (talk) 15:38, 16 April 2016 (UTC)

Per Wikimedia's Global bans policy, this is a notice to a community in which WayneRay participated in that there's a proposal to globally ban his account from all of Wikimedia. Members of the community are welcome in participate in the discussion. --

— Cirt (talk) 19:12, 18 April 2016 (UTC)

@

WP:AN, where we discuss local bans. עוד מישהו Od Mishehu 02:55, 21 April 2016 (UTC)