Policy | Technical | Proposals | Idea lab | Miscellaneous |
New ideas and proposals are discussed here. Before submitting:
|
« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130 |
Contents
- 1 Proposal: Enable Hovercards by default
- 2 RFC: Corrections on Main Page?
- 3 Displaying pronunciation of a word in regional language
- 4 Banter
- 5 About {{Commons category}} , {{Commons category-inline}}, {{Wikisource}}, {{Wikisource-inline}}, {{Wikisource author}} and the like
- 6 Show full section hierarchy in edit summaries
- 7 Article assessment comment subpages
- 8 One-month focus on 5-6 link disambiguation pages.
- 9 Move reason preview
- 10 Use of local forms of English
- 11 Auto-hyphenating words for alignment in all articles?
- 12 Introduce different colours for links to different things
- 13 RfC: Preferred protocol for external links
- 14 Religious messages
- 15 Implementing Help:Maintenance template removal
- 16 Automatically setting PC protection level for BLP's
- 17 Using the edit filter to enforce ArbCom or Community bans Reply
Proposal: Enable Hovercards by default
Hovercards is a Beta feature that displays a short summary of an article and an image when a user hovers over a link. When enabled, there is an option to disable it by clicking on the gear icon and selecting "Disable previews", which can be undone by clicking a link in the footer, similar to the disabling system used by Reference Tooltips.
Hovercards can be tested via Special:Preferences#mw-prefsection-betafeatures. Currently, about 46,000 English Wikipedia users are testing the feature.
Some background information: Navigation popups, a tool providing easy access to article previews and several Wikipedia functions, was created as a user script in 2005 primarily by User:Lupin, with help from numerous other Wikipedians. It was made into a gadget in 2007, and became one of the most popular gadgets, with over 40,000 users opting in to use it on the English Wikipedia, and nearly 40,000 more users on other Wikipedias. In 2014, the Wikimedia Foundation started working on "Restyling and Enhancements" for the feature, greatly simplifying the appearance of the popups, emphasizing the lead image, and hiding by default the extra Wikipedia functions, targeting the feature primarily towards casual readers. The new version was re-branded as "Hovercards", and made into a Beta feature. In 2015, Hovercards was rolled out to all users on the Greek and Catalan Wikipedias for a two month test, gathering feedback via a survey, which mostly received positive responses, along with many bug reports and suggestions for improvement.
Note that this feature still has several remaining bugs, including the popups occasionally getting "stuck" and not vanishing properly, and popups having issues with certain types of article leads. Hovercards is also still lacking many features supported by navigation popups. (Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.) For links to certain articles, an image not directly related to the article topic is displayed, due to a bug in the PageImages API.
If anyone considers any particular bugs/gaps/tasks to be blocking (that is, we should wait until they're fixed before enabling the feature by default), please say so. Waiting until certain things are fixed is an option. Simply not turning the feature on by default at all is also an option. So is waiting until it has received more testing on other projects. The WMF is willing to work on this as necessary, provided the community actually wants the feature.
Should Hovercards by enabled by default on the English Wikipedia? --Yair rand (talk) 10:29, 16 March 2016 (UTC)
NOTE: There is a discussion at policy talk: Non-free_content#Hovercards. It seeks to determine whether it is acceptable for non-free images to appear in Hovercards. Alsee (talk) 16:55, 16 March 2016 (UTC)
Discussion
- Wait until the extension has reached feature parity with navigation popups, then reconsider. Note that popups have always been opt in for editors. MER-C 11:03, 16 March 2016 (UTC)
- Hovercards are primarily intended for readers who don't need all the fancy bells-and-whistles of Lupin's navigation popups. These are also the people who can't easily "opt-in" or "opt-out" of this feature, as most of them aren't logged-in. Power-users can easily disable Hovercards using the button on the card. With 45,955 registered users already having opted-in at the moment, I think "enable by default with an easy opt-out" would be the sensible default setting. —Ruud 11:34, 16 March 2016 (UTC)
- This will never happen (within the next five years), nor was it a goal of hovercards. (disclaimer, i'm a former navigation popups developer) —TheDJ (talk • contribs) 12:24, 16 March 2016 (UTC)
- In which case, oppose for editors. Let's make it opt in for readers first while the bugs are squashed then try to measure how many readers found it useful and how many turned it off, and perform A/B tests. MER-C 06:50, 23 March 2016 (UTC)
- I need to understand "(Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.)" -- As I don't use NPopups, is the "Advanced" mode part of popups or hovercards? Does that basically mean that popups is hooking into hovercards? --Izno (talk) 11:39, 16 March 2016 (UTC)
- @Izno: The option for "Advanced" mode is in the Hovercards menu, but the option currently only appears when one also has Navigation popups turned on, and those popups themselves come from Navigation popups. Hovercards normally suppresses Navigation popups to avoid duplication. I'm pretty sure that all the "Advanced" setting does is turn off Hovercards and remove the suppression of the Navigation popups. (I imagine the eventual plan is to have "Advanced" mode actually be fully part of Hovercards and not use the gadget.) --Yair rand (talk) 11:58, 16 March 2016 (UTC)
- Enable by default. However, I would consider either phab:T105782 or phab:T92932 to be blockers of the definite sort and not just the "kinda'" sort that we usually associate with blockers in Phabricator, so one of the two needs to be resolved prior to enabling by default. --Izno (talk) 12:21, 16 March 2016 (UTC)
- I've been using Hovercards for at least a few months now and the "getting stuck" thing happens perhaps once a week or so. The easy solution is to press F5 and refresh the page. So it's not really a blocking issue for me. But if it could be fixed, that would be better, yes. —Ruud 12:44, 16 March 2016 (UTC)
- Oppose. Should be opt in only. NOT enabled by default. These things are quite cumbersome when reading articles anywhere on the Internet and bothersome. They are extremely incredibly distracting to readers and editors alike. Both during the reading process or editing process. — Cirt (talk) 14:39, 16 March 2016 (UTC)
- Well, I personally find this feature to be incredibly useful. You actually need to hover your cursor over the link for a while before the card opens, so I rarely open it by accident. The survey among readers does indeed show that there is a strong "love it" or "hate it" response:
- but 1) the people that like it vastly outnumber the people that don't (6 to 1) and 2) it's much easier to disable this thing (click the button on the card) than it is to enable it (create an account and find a checkbox hidden on one of the preferences tabs). —Ruud 15:45, 16 March 2016 (UTC)
-
- Ruud Someone below pointed out that the survey included opt-in en wikipedia users. I filtered those out and the results are here. It doesn't change much, but I did want to be precise as this was an oversight. I will update all the survey questions shortly. Jkatz (WMF) (talk) 20:36, 6 April 2016 (UTC)
- Enable by default I find Hovercards to be very useful and based on the number of people that have enabled this Beta feature and the survey responses I think this will be useful for a majority of the readers. Most of those readers won't be able to enable this feature if it remains as an opt-in feature, while those that find this a nuisance can disable it quite easily. —Ruud 16:51, 16 March 2016 (UTC)
- Enable by default, but first they should add the standard "X" at the top right allowing the user to close the card, doubleso if there is a bug that sometimes prevents them from closing automatically. Diego (talk) 17:51, 16 March 2016 (UTC)
- Enable by default provided there's a means to disable the feature from the card itself. (Disclaimer: I've used Lupin's popups for the past several years.) —Jeremy v^_^v Bori! 21:03, 16 March 2016 (UTC)
- Very Strong Enable by Default This is very, very useful. When I get on WP at lunchtime from work to just browse stories, I find it horrible that I have to actually click a term link to find out the bare info about it. Annoying. I am on several computers a night and hardly ever in the same location again. To me, the hovercard is a godsend for quick reading about items and terms I may not be that familiar with. With my casual reader hat on, I find it is a huge time saver. It should be available standard, with an opt-out feature for those who don't like it. GenQuest "Talk to Me" 22:28, 16 March 2016 (UTC)
- Oppose Just leave NAVPOPS alone(Redacted)--Stemoc 23:36, 16 March 2016 (UTC)
- Enable - I've used hovercards for years. I like hovercards. And I'm not going to argue with the data at mw:Beta_Features/Hovercards#Qualtrics_Survey_Results. But the WMF should just get more data to avoid these discussions where input is limited to a small group of power-users who are not representative of the audience and have no insight into design or usability. Just run A/B tests on x% of the audience, find out how hovercards effect their behaviour. Bring in volunteers on site in SF and do eye-tracking or something. Anything to expedite circular discussions on-wiki. - hahnchen 23:55, 16 March 2016 (UTC)
- Enable For once a Mediawiki beta feature that is really good and everyone should get. Oiyarbepsy (talk) 04:41, 17 March 2016 (UTC)
- Oppose per Cirt. Any kind of pop up content should be disabled by default. I assume that be having this on by default, page load time would be increase and that there would be further drain on client resources by Javascript. - MrX 12:56, 17 March 2016 (UTC)
- Oppose - one of the most annoying things on web pages is when unexpected popups appear. While anyone who wants this would certainly not complain, it shouldn't be forced on anons, nor enabled for registered users except by explicitly asking it to b enabled (such as in the "Preferences" page). עוד מישהו Od Mishehu 15:42, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
- You move the mouse carelessly, happen to leave it on a link, and then a popup shows up... that would certainly be unexpected. I do use Lupin's popups, but would certainly oppose it being imposed on anons or enabled for registered users by default. עוד מישהו Od Mishehu 18:14, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
-
- @Od Mishehu: Note that we have already decided to enable the very similar Reference Tooltips popups as an opt-out feature for both registered and for non-logged-in users (Wikipedia:Village_pump_(proposals)/Archive_89#Reference_Tooltips).
- I think that it is to be expected that there are going to be some users who will like these popups and some that are going to be annoyed by them. (The survey that was run shows that 76% of readers like them, 13% don't like them, and the remaining ones don't care either way.) Whether you want to use them should indeed be an individual choice. But if we leave this as an opt-in for registered users only, most people will not have the opportunity to make that choice, simply because they have no way of knowing that making the choice to enable this feature is an option. Making this an opt-out feature is probably the closest we're going to get to giving everyone a chance to make that explicit choice for themselves. Yes, a few people will be annoyed when these popups appear, but disabling them is easy. Enabling them, on the other hand, is nigh impossible for most readers at the moment. —Ruud 19:53, 17 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- If my first experience with Wikipedia had been a popup showing up unexpectedly, I would have probably decided it was a spam site and stayed away from it. עוד מישהו Od Mishehu 14:47, 18 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- Oppose Who the hell do you people think you are? So now you think we should have users experience pop-ups by default without them specifically asking for it? That's nonsense. Look, I use navigational popups and I think everyone should but I'm not supporting enabling intrusive features for users without their consent. I'm guessing someone wants to push hovercard use and isn't happy with the number of opt-ins; this is a sad measure to force the issue. Chris Troutman (talk) 21:32, 17 March 2016 (UTC)
- Oppose. Great feature, but no way this should be enabled by default. Doing so will only cause confusion for those who have dealt without them for so long, some of which may have never touched the "Preferences" tab before. However, as a caveat, I am neutral on this being enabled by default for IP editors only; this opinion is similar to how the "media viewer" ended up being set up. — Preceding unsigned comment added by Steel1943 (talk • contribs)
- Oppose - No it fucking shouldn't be the default, I've just enabled it and well I absolutely hated it .... so it's now disabled and I'd rather leave it like that, If I wanted to know what for example a "convertible" was I would read a dictionary not expect some irritating pop up to tell me every single linked word my mouse goes over!, Although I do support enabling it for IPs as that way IPs might hate it as much as I do and would hopefully signup .... Anyway no don't enable it - Just let people who want it to enable it via their preferences. –Davey2010Talk 22:50, 17 March 2016 (UTC)
- Oppose. This would reduce article traffic, and interferes with the reading of text when readers unintentionally hover their cursor on a wikilink. Personally, I find this feature annoying. sst✈ 02:03, 18 March 2016 (UTC)
- How would it reduce article traffic? Hovercards are very simple to understand, and users can still just click on the link to open the article in a new page, there's no difference in behaviour there. If you feel that by serving up the lead to readers in a hovercard, that the reader will not then read the rest of the article, you are saving time and resources needed to serve a new page. - hahnchen 23:43, 18 March 2016 (UTC)
- Comment – I can see the use for this, but I can also see how it can become really annoying. What we really need is a solution that would make it much easier for readers (that is, non-editors) to notice these add-ons and enable them voluntarily. Something like a prominent "reading preferences" menu at the top of the page, next to "Create account", that all of our users could have to personalize their reading experience. If there is widespread support for a particular add-on from this setup, a discussion of whether to enable by default would be more successful. Mz7 (talk) 05:03, 18 March 2016 (UTC)
- @Mz7: How would you define "widespread support"? (Currently there are 46,071 registered users who enabled this beta. A survey among anonymous users found that over three quarters found this useful, one in eighth disliked it.) —Ruud 09:56, 18 March 2016 (UTC)
- @Ruud: Careful with statistics! Those 46,071 are less than 0.2% of the 27,968,589 registered users of English WP – is that widespread support? How self-selecting were those who responded to that survey among anonymous users? Stanning (talk) 10:21, 18 March 2016 (UTC)
- @Stanning: It would indeed be very interesting to know not only how many people have enabled a particular feature, but also how many enabled it at some point and then decided to disable it again. So we could classify people into "tried it and liked it", "tried it and didn't like it", and "didn't try it yet". We could even break this number further down into categories for "very active registered users", "active registered users" and "registered users that don't edit". And plot these numbers over time. All of this information should ideally be visible on the Beta tab.
- But even if we know these numbers, my original question still stands. How should we define "widespread support"? —Ruud 11:12, 18 March 2016 (UTC)
-
-
-
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
- How about a large scale A/B test on the English Wikipedia? While the data we have from the Greek and Catalan Hovercards trial is useful, we could do with a lot more. Instead of solely relying on survey responses (which is still useful), the foundation should be looking at performance impacts, hovercard disable rates, hovercard "alive" times (are people reading the hovercards), click-through rates (do hovercards encourage more page views, or do they keep the reader focused on the current one?). At some point, there should be enough data one way or another that those arguing on "personal preference" can be mostly ignored. - hahnchen 23:43, 18 March 2016 (UTC)
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
-
-
- Oppose. I agree with Mz7: can be useful, can be annoying. But no way should it be enabled by default, even for IPs, even with a little gear-wheel to turn it off (if you know what the gear-wheel means).
As Mz7 says, it'd be good anyway to make Preferences, or some of them, available to IP users (I guess that'd mean a WM change to keep some preferences on the device, instead of centrally, for non-logged-in users).
Maybe a compromise would be to enable it by default once only and on first pop-up include a line saying something like "Do you want this feature? Click here to enable it" and if the user doesn't click, turn it off at once (not the other way round).
Personally I dislike pop-ups because usually they're ads or otherwise irrelevant. Of course on WP we're pure and undefiled, but that doesn't mean that we should feel free to push features like this, however 'cool' they seem to us. Stanning (talk) 09:41, 18 March 2016 (UTC) - Oppose for now. I would support if they contained no images. The current WMF fad to include large images in everything (this, related articles, Gather before it was disabled, apparently some new search as well) is very annoying; we are a knowledge engine (ha!) that also includes images, not an image repository with some accompanying text. (The indication of how long ago the hovered page is last edited is also completely unnecessary, as it gives no information related to the hovercard text or even interesting to 99.9 of the people using the hovercard) Fram (talk) 11:37, 18 March 2016 (UTC)
- I think an image usually adds value to the card. What I don't particularly like is that the PageImage extension tries way too hard to extract an image from the article. If we have an image in the lead section, great, use it. But don't pick an image that's several sections down in the article. You can find complaints all over the place about this, ranging from nonsensical images being displayed, to outright problematic ones. —Ruud 12:00, 18 March 2016 (UTC)
- Oppose per the KISS principle. Andrew D. (talk) 17:49, 18 March 2016 (UTC)
- Oppose It's a useful feature but I would expect it be a preference to have enabled or not, and starting with it on by default is not good as well made impede people on older computers or browsers. I would reasonably expect to have a banner announcement that this feature is now available and how to enable it for those that want it. --MASEM (t) 18:00, 18 March 2016 (UTC)
- Oppose forcing it on readers as the default - not everyone is going to know they can turn it off and may want to for the reasons given above. Doug Weller talk 11:50, 19 March 2016 (UTC)
- comment (leaning on oppose). I use them for some time. They are quite good in giving us a glimpse about the linked to article, often that is enough to get why it is linked from 'here' and to know if we want to get there. Still they have two issues that make me think that not having it by default is better. One, these things can be quite annoying when you do not want them, so I'd rather have people missing them for a while until they realise they can have them, than annoying the readers. Two, the images, as many already said, are often a poor choice. Don't try too hard to have an image, if there is not one in the lead, do not look any further (if there was a good image, generally describing the subject in a whole, full, proper way, our editors will push them to the lead soon enough, no need to have a script making guesses) - Nabla (talk) 18:22, 19 March 2016 (UTC)
- Oppose: I have reason to believe that activating this feature by default would only give more ground to North America exceptionalists to created unnecessary templates like {{Football squad start2}}, {{football squad player2}}, etc. while using accessibility as their excuses. Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:49, 19 March 2016 (UTC)
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Oddly enough, I just addressed some of this in a different context, at WT:CFD. Short version: MOS:TIES, though basically an article content rule, can affect templates, if they generate content for articles; so, it is essentially required that there be AmEng templates that use AmEng terms in lieu of Commonwealth English ones, for AmEng articles. There is also a consensus against using US state flags for things; MOS:ICONS wants flags in sport to be for sporting nationality, period, and this has been arrived at through years of contentious discussion. If this still doesn't address your concern, I must be missing too much of the back-story regarding disputes about these particular templates. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- When it comes to enabling hovering images, my main concern is that North American exceptionalists would attempt to come up with new "conventions" like "Don't use certain kind(s) of images in North-American-related articles". Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:47, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Support enabling by default. It's an extremely useful, time-saving feature. I've been using for many months in multiple browsers and OSes with no problems. Turning it off is trivial, finding and turning it on is not. WP cannot remain exactly the same "built in 2005" site forever. We are losing readers because of our shite interface and utility, and this is great improvement to it. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Conditional support. Looking at the survey above in this discussion, I think this feature is great for previewing articles because many people said they like it (301 participants), but some said they don't (52 participants). So, we would want to balance the needs of the majority of supporters to the few people who say they disagree with it. Therefore, The hoverboards should give a brief explanation of what they're, so they won't keep readers and editors wondering "What is that little popup"; Facebook uses a similar method when introducing new features, and also, they should clearly explain how to opt out of using this feature and to turn it back on as they wish because it can get a little bothersome to some readers and editors alike, as per some commentors above. Sam.gov (talk) 18:48, 21 March 2016 (UTC)
- Great idea. For anons, I guess it could work on the cookie basis; any that accept the cookie, and don't want the hovers can save that preference, and not lose if if their IP address changes, at least in theory. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- Yes, but not now. Hovercards needs some tweaks before being rolled out by default, but I strongly support it being rolled out by default eventually. {{Nihiltres |talk |edits}} 21:22, 21 March 2016 (UTC)
- Support, but with the option to opt out easily delineated on each popup. Hovercards isn't perfect, but maybe we can implement an opt-in option first, then we can roll it out by default after the bugs are fixed. epicgenius (talk) 13:59, 22 March 2016 (UTC)
- Oppose. There is no need to force this feature on the users who find this feature annoying (and it looks like the number of such users is noticeable). Also, I suspect that seemingly the main argument of the supporters - that otherwise those other anonymous readers will not be able to use this feature without registering - seems to be outweighed by the fact that such state of affairs would gently encourage such users to register, and, perhaps, to start editing as well. For examle, I have also registered to get a "registered-only" feature (justified alignment). --Martynas Patasius (talk) 22:03, 23 March 2016 (UTC)
- Oppose - If the feature always performed as well as the display in the example screenshot of this proposal, enabling them would be something to discuss.—Godsy(TALKCONT) 07:27, 24 March 2016 (UTC)
- Oppose – Not for every user's taste, or CPU. A rather gratuitous add-on feature, not a core necessity, should be off by default. SteveStrummer (talk) 01:47, 25 March 2016 (UTC)
- Oppose It's not just the number of users on each side but the minor additional value for those who like it, and the major distration for those who do not. DGG ( talk ) 04:27, 25 March 2016 (UTC)
- Oppose As far as I remember, it was enabled my default, then I went and disabled it. I find hovercards useful. You know what, I'm gonna try it right now and decide. --QEDK (T 📖 C) 06:48, 25 March 2016 (UTC)
- Why does it have to pull a picture and there's no infobox information, just the lede. Random hovers are an issue but they're an issue on every website with hovercards enabled. It's going to work just fine on most articles but on ones with linked ones, it will definitely be annoying. Sometimes, the preview text is absolutely useless and the picture isn't useful in most cases either (it'd be good for animals and plants but those are very limited uses). --QEDK (T 📖 C) 06:57, 25 March 2016 (UTC)
- In the name of God, enable by default. Frankly, hovercards increase the quality of Wikipedia in that they are useful for obtaining information quickly and easily. As has been stated above, anyone who dislikes hovercards has the option to disable them, and those who do find them useful will be grateful of their existence. While there are a few problems (such as the inclusion non-free images, etc.), I see no great cause of concern over their activation. If anything, we can enable them sometime in the future when all of the bugs have been worked out, but personally, I feel they're just fine as is. Colonel Wilhelm Klink (Complaints|Mistakes) 16:43, 25 March 2016 (UTC)
- Don't you dare mess with the preferences of existing registered users. As for IPs, oppose, at least until the bugs are ironed out. BethNaught (talk) 22:15, 25 March 2016 (UTC)
- Comment I think the primary question here is about IP's and NEW accounts. I agree with BethNaught that changing existing editor preferences should not be on the table. For IPs, enabling by default and making it very easy to turn off is being proposed to solve the issue of discoverability for a feature that the majority of readers appear to like (when it was auto-enabled in Greek and Catalan). Without enabling the feature, we don't have a great way of allowing users to try it. There is no user preference area (solvable, but not easily) and, even if there was, there is no good way we have identified to help users discover this feature without showing them. Someone above mentioned running a central notice banner to inform users that it is an option, but this raises other issues--when do you turn the banner off, for instance? Do we turn it on 1 day a month in perpetuity? I am very interested in hearing suggestions, but tend to feel that allowing organice discovery when a user mouses over a link and then providing a very easy way to disable is the way forward. It seems that an easy path to disablement is the biggest issue. Maybe a blocker for rollout would be developing a dialogue on that first hover that shows users how to turn it off? Just an idea. Jkatz (WMF) (talk) 00:18, 26 March 2016 (UTC)
-
- I really liked Stanning's alternative proposal earlier of showing a hovercard once, and with it a dialogue asking whether the reader would like to continue using the feature. If no response, we would assume no and disable it. I also think the idea of a reader preference area deserves some looking into—if not for Hovercards, then for future add-on features. Ultimately that's what enabling and disabling these kind of features boils down to: preference. Wikipedia has enabled by default a host of these add-ons now—VisualEditor, Media Viewer, Reference Tooltips—and while it is possible to disable each even without a registered account, it would be easier if there were a centralized location for readers (i.e. unregistered users) to switch these on and off. It could also be a place to put beta features like Hovercards, in order to expose them to our readership (the ones who really matter). Mz7 (talk) 18:31, 29 March 2016 (UTC)
- Oppose. Screen clutter which should be opt-in only.--Smerus (talk) 09:03, 26 March 2016 (UTC)
- Support WP:ILikeIt. As an editor I find it useful for quickly telling if the link is correct. It also makes Wikipedia look more professional. AIRcorn (talk) 02:01, 27 March 2016 (UTC)
- Support, I've been using Hovercards for some time and I love it. Really improves my reader experience. --SSneg (talk) 09:44, 27 March 2016 (UTC)
- Strong Support For once, let's think of the readers. I've been using it for a while and it's one thing I really miss when I'm reading on my phone or other computers. It solves a major problem: clicking on links in running prose. When I'm reading an article on a subject I don't know a lot about, I can hover over a blue link, read a brief blurb to try and get the gist of the term, and keep going without having to open a new tab or leave the page. It makes reading and understanding text easier. Enabling by default will introduce a number of people who don't even know this exists to the feature and if they don't like it they can easily opt out. For IPs, it not only makes it easier for them to read and understand articles, but it also enhances our user experience and spurs innovation.
- I'm not convinced by these opposes of "screen clutter" or that it will encourage users to register. It's only screen clutter if you hover. If you don't hover on links, it doesn't clutter your screen. I'd be willing to say most registered users don't even know about this feature, so the idea that an unregistered user would find out about it and be so amazed by the feature that they make an account is not something I find hard to believe. For its bugs it is actually really stable in practice and having it enabled by default will probably get those bugs fixed even faster. I strongly believe that this feature will drastically improve the experience of anonymous readers, even if some editors find it suspect. We are an encyclopedia first, and this is a well designed feature that easily, minimally, and creatively solves a big problem readers have. If that harms your editing workflow, then opt-out, but I don't see why we should be blocking a useful feature because editors don't want to talk the 30 seconds to opt-out of it. Wugapodes (talk) 14:11, 27 March 2016 (UTC)
- Strong support per what Wugapodes said Common: how many experienced editors don't have navigational popups turned on? over 44,000, its our most commonly used opt-in gadget. Our readers would greatly benefit from that simple little bit of help finding the content. I can't believe we are making "clutter" arguments. The readers that are using desktop (an increasingly shrinking portion), are used to this kind of design in almost every other website -- lets not take our own IDONTLIKEIT arguments, to assume they apply for our readers. Sadads (talk) 13:57, 28 March 2016 (UTC)
- Support, per Ruud and Wugapodes. I personally like Hovercards, even though I quickly turned it off in favor of nav popups, so I decided to read the oppose votes first. I didn't find any of them convincing. There's a clear way to opt out, so whatever annoyance might be experienced by people encountering it for the first time would be minimized. APerson (talk!) 13:14, 30 March 2016 (UTC)
- Oppose. In my opinion, this feature is interesting and I'm glad it exists but quickly Hovercards become annoying and stressful as you find yourself hoping your mouse doesn't land on any links. I also think it undermines people participating in the encyclopedia. People are less likely to edit and improve pages they never visited. This feature is flashy and sounds like a great idea, but in practice it would make Wikipedia like a man wearing too much jewelry. Overkill so let's keep it simple. Jason Quinn (talk) 15:27, 30 March 2016 (UTC)
- Oppose. I like the hovercards but making them default will create a cultural expectation that everyone is using them, which is a major faux pas with blind readers, mobile phone users, and people who just choose to disable javascript. Also, based on what Jason Quinn said above, I wonder if hovercards might account for the reduced page visits the WMF has observed? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 15:46, 30 March 2016 (UTC)
- Oppose making them opt-out. Pop-ups are, indeed, fantastic, and i expect these Hoverthings are too; but they will be annoying (Pop-ups sometimes annoy me, and i've used them for years) and a distraction from the actual content on the page; there is bound to be an effect on performance, especially on those users who have poorer connexions and slower machines, and particularly if they are used without the described freezing resolved. In all honesty, and i don't believe this is an IDONTLIKEIT argument, i oppose making almost anything opt-out on the principle that simpler is better, and we should be making it as easy as possible for our users to access our content; cheers, LindsayHello 11:17, 2 April 2016 (UTC)
- Oppose being enabled by default - Hovercards are a radically different feel and function from the rest of Wikipedia. Not long ago "pop-up" was a dirty word on the Web (thanks, Tripods). We may be moving into a post-post-popup age, but they are nonetheless a loud feature that some may like, but for those who don't like them, it'll be a terrible first impression (in other words, people who like them might really like them, but for people who don't like them, they really don't like them). Yes, those who don't like them can simply opt-out .... and if it's not enabled by default those who do like them can simply opt-in (i.e. I don't see "you can just..." as a good argument here). I would want to see much better evidence of a broad positive impact and limited negative impact. That chart above, if I understand it correctly, is terribly misleading as-is. I'm sure others have pointed this out already, but the survey was not a random sample of users but a self-selected sample among those users who already have enabled it (and not those who enabled it then disabled it in horror). I should hope 75% of people who made a conscious choice to turn the feature on actually agree that it's a good one. — Rhododendrites talk \\ 20:57, 3 April 2016 (UTC)
- Hi Rhododendrite This is a great catch, but only partially true. The survey in question went to a random sample of Greek and Catalan Wikipedia users during a period when hovercards were enabled by default to all users of those wikipedias. However, it also went to english users who were opted in. Going back into the survey results, I was able to generate a report that filters out the opt-in English users. Here is what it looks like--you will see that the numbers do not change significantly.
- I will add it above, as well. Jkatz (WMF) (talk) 20:30, 6 April 2016 (UTC)
- @Jkatz (WMF): Does the WMF have the capability to conduct A/B testing on the English Wikipedia? There are all sorts of metrics that you can't measure, from a much wider audience, than just with just a user survey. - hahnchen 08:45, 10 April 2016 (UTC)
- @Jkatz (WMF): Aha. Thanks for the clarification. Sorry, I didn't catch that. I do still have to stand by my position that I'd want to see more evidence (for the English Wikipedia) before it's enabled by default in any "permanent" capacity. Maybe a shorter period with a set end date for testing purposes? — Rhododendrites talk \\ 14:40, 10 April 2016 (UTC)
- Question. The discussion feels weighty to me, like it might benefit from a careful close. It's listed at WP:CENT, but it's not an RfC. Does this discussion need a close? Should the close wait till the 30-day point, as if it were an RfC, or would 21 days be enough if things continue to slow down? - Dank (push to talk) 22:19, 3 April 2016 (UTC)
- Apologies, I was thinking about helping out with this one, but I can't, life has gotten a little crazy. - Dank (push to talk) 02:53, 9 April 2016 (UTC)
- Comment: I see Hovercards as being primarily a reader's feature, and simply feel that this question is being asked of the wrong crowd. From a reader's perspective, this would appear to be a major change; we (here) might already know about it, and know about our preferences and this conversation, but to the vast majority of users, it would be a fairly big surprise. Perhaps if the foundation is considering getting involved with the development, and thus we're talking about the full scale introduction of (what will appear to most users to be) a new way of reading the world's most popular and complete online encyclopedia, it's the users they should be asking. I suggest that if the foundation wants to know if users want new features before developing and rolling them out, the foundation should post a site wide banner asking ALL readers to try it and decide for themselves, then click either I like this feature or I don't .... If the feedback is positive (enough) then the foundation has their call to arms - otherwise, it remains opt in. We here, are not the average user. fredgandt 23:38, 3 April 2016 (UTC)
- @Fred Gandt: A survey of readers/users was already conducted. See above. Are you suggesting running another one, perhaps with a simpler format? --Yair rand (talk) 23:58, 3 April 2016 (UTC)
-
-
- Yes, much simpler and shorter. Show a banner stating that a new feature is being considered, with a Try it now button. If clicked, enable the Hovercards for the session and automatically disable the feature at the end of the session or if the user returns to the banner and clicks the now visible I don't like it button. If they return to the banner and click the I like it button during their session, provide registered users the option to permanently enable the beta feature, and thank the IPs. Metrics gathered, no surprises, and no particular effort required of the user (a few clicks). fredgandt 00:20, 4 April 2016 (UTC)
-
- Oppose I had popups enabled for some time and found it annoying to have the window blocking my view (I have a large tendency to close sites where I get a 'popup' with advertising or with a request to subscribe to their newsletter - I am there to read the article). Below there was a suggestion of 'holding shift while hovering' which makes sense to me (though I understand the concern that that would unclear to non-regular readers). --Dirk Beetstra T C 03:23, 7 April 2016 (UTC)
Accessibility
Please can someone point us to the accessibility impact assessment for hovercards, showing their effect on people with disabilities, and/ or those using assistive software? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:57, 28 March 2016 (UTC)
- Their panels are opened and closed when you focus a link, so they are usable for users relying on keyboard navigation. Similarly for screenreaders, but you can't interact with them. The popups have aria annotations to declare them as tooltips (even though they are more like floating windows), but the link is not connected to the tooltip, preventing the screenreader from being able to do anything with them. That's probably fine in this particular case. It's probably more efficient for a screenreader user to directly navigate to a link, instead of trying to figure out what a popup like this does and how it should be controlled. It might possibly be improved in the future, but it is not degrading the experience. —TheDJ (talk • contribs) 15:56, 10 April 2016 (UTC)
Possible compromise: Require holding SHIFT to pop-up?
A [simple?] tweak that would mostly retain the functionality and allow it to be enabled by default without being intrusive to people who don't like it: require the shift key (or another key) to be held for the hovercards to appear (i.e. same as normal, but only when shift is held). Doable? Desirable? Apologies if this has been discussed and I didn't see it. — Rhododendrites talk \\ 21:19, 3 April 2016 (UTC)
- I don't see what the point would be. Nobody would know that the feature was available. We don't exactly have a way of communicating with the average reader, and it wouldn't make sense to waste their time with this "Hold shift" information even if we did. --Yair rand (talk) 22:59, 3 April 2016 (UTC)
- For someone who thinks Hovercards could be useful, the information wouldn't be a waste of time, but it's a fair point that we don't have great ways to communicate with readers. I suppose I was thinking more about newly registered users. Regardless, the zero other replies in this subsection says to me it's not as promising an idea as I thought :) — Rhododendrites talk \\ 14:45, 10 April 2016 (UTC)
RFC: Corrections on Main Page?
The Main Page sometimes has factual errors (mainly on WP:DYK, also in other sections). At the moment, these get quietly corrected or removed, but no acknowledgment of this is being made. Similarly to what happens with e.g. newspapers (Correction (newspaper)), we could make a note of factual errors we featured on the Main Page in either the same spot (so a DYK error gets noted in the DYK section of the main page) or in a separate section on the Main Page. This should only be done for facts, not for grammatical errors, capitalization changes and the like. This was recently done a few times, but met with mixed reactions. How exactly this should be done is not really important, first we need to agree on whether this is wanted or not. Fram (talk) 10:42, 23 March 2016 (UTC)
(Note: this is not intended for ITN items which were correct at the time of posting but were outdated at some time: this is not an error but normal progression of events). Fram (talk) 10:46, 23 March 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) Fram (talk) 14:09, 23 March 2016 (UTC)
- 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 main problem with the main page currently is that the disclaimer is buried at the bottom in fine print. It should be made more prominent as it's our general position that that any of our content might be wrong. Publishing corrections should only be done when the error or issue is important as it is quite easy to nitpick details. For example, the blurb for yesterday's FA said, "The animals lived for at least 12 to 20 years..." This is erroneous because some of these creatures died young while at least one specimen was found to have reached age 27. But the exact range of lifespans of creatures that have been extinct for millions of years is not a big deal and argument about the best wording for our tentative knowledge of them is likely to be protracted. What might help is having WP:ERRORS turned into a noticeboard with the usual structure of topical sections, archives and the like. Currently 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)
- 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)
- 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)
- 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:RFA. 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. SSTflyer 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 almostWe 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 atime 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 reportedif 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 noticeit 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(TALKCONT) 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)
- 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#PAPER and 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) )
- 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)
- 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)
- 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)
- 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)
- 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)
-
- 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. --Jakob (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 considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ 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)
*Once as an exercise, I went through one of the worst offenders's articles line-by-line annotating every untrue statement, claim not supported by the source, use of inappropriate sources, improper synthesis and even a citation to a novel as if it were fact. This was an extreme case, but not extreme enough as to be unique. ‑ Iridescent 15:27, 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)
- Okay! Fram (talk) 12:21, 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 considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ Iridescent 12:18, 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)
- 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).
- 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)
Displaying pronunciation of a word in regional language
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)
- User:PGAwade, may I suggest that this idea is far more appropriate for wiktionary? That said, I suggest that you learn IPA (IPA for English should help) and use those pronunciations where available. Oiyarbepsy (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)
Banter
I don't know how many people feel like me but I've always wanted Wikipedia to be a fun kind of place. We get work done, but let it not feel like drudge. So, I propose we make a page for banter where we can get together and do some shiz. I don't know how will other people will feel about this but hey, atleast I've spoken my mind. --QEDK (T 📖 C) 16:53, 27 March 2016 (UTC)
- Maybe Wikipedia:Village pump (banter) ? All the best: Rich Farmbrough, 22:06, 27 March 2016 (UTC).
- We had that many years ago. It was called Wikipedia:Esperanza. It was killed with pitchforks and torches for upsetting the local villagers. --Jayron32 02:09, 28 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
- I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
- I've seen other online entities that had a "work" part and a "banter" part. The banter parts were so lightly used that a little banter remained in the "work" part, because if it were put in the banter part hardly anyone would see it. Jc3s5h (talk) 12:51, 30 March 2016 (UTC)
- I think this would be a good thing to have. We need a place to see our fellow editors as human beings and make links. In fact, it would help me no end in my NPP and newbie welcoming tasks if I knew some editors working in various areas. However, get ready for the shouts of wp:nothere :) Happy Squirrel (talk) 01:16, 31 March 2016 (UTC)
- I've seen other online entities that had a "work" part and a "banter" part. The banter parts were so lightly used that a little banter remained in the "work" part, because if it were put in the banter part hardly anyone would see it. Jc3s5h (talk) 12:51, 30 March 2016 (UTC)
- I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
- Wikipedia is not a social network. Such a page cannot be reconciled with our policies. RGloucester — ☎ 01:58, 31 March 2016 (UTC)
-
- Given that the goal of this banter page would be to increase collaboration by allowing less structured interraction, the end goal does focus on Wikipedia. I would tend to see this more as similar to meetups being organised on-wiki. From reading the policy you linked, I rather got the impression it was forbidding using Wikipedia as a place to conduct one's off wiki social life, not as forbidding social interractions with people we are contributing to Wikipedia with. Happy Squirrel (talk) 02:11, 31 March 2016 (UTC)
- Support as log as it is just a room or two in which a few admins can act as moderators... nothing else is needed. Fritzmann2002 18:31, 7 April 2016 (UTC)
I like the idea, but the possibility of vandals doing whatever they want is just too great. ThePlatypusofDoom (talk) 21:00, 7 April 2016 (UTC)
I'm totally behind this! It would need some moderation of course, but I'm sure that can be sorted out. Commissaress (talk) 21:25, 7 April 2016 (UTC)
- All but died on the vine in January 2015, here, albeit with a slightly different context/angle. Beware the scarlett letter P(erennial). ―Mandruss ☎ 21:50, 7 April 2016 (UTC)
About {{Commons category}} , {{Commons category-inline}}, {{Wikisource}}, {{Wikisource-inline}}, {{Wikisource author}} and the like
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 Dmitry Rogozin can access the corresponding English Wikiquote page simply by clicking the Wikiquote link shown on the IOP section, in my opinion {{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), –Davey2010Talk 01:59, 2 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. –Davey2010Talk 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).
Show full section hierarchy in edit summaries
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)
- 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)
- 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 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)
Article assessment comment subpages
I am finally trying to complete a task for which consensus was established 7 years ago - to deal with several thousand /Comments subpages in article talk space. (Please see WP:DCS for more details.) Here is one example: Talk:Vegetarianism and religion/Comments. Basically these pages have barely been used for years and we are going to migrate the content to the article's talk page and then redirect. If anyone is interested, please comment at WT:DCS or at the bot request for approval where we are ironing out the details. — Martin (MSGJ · talk) 09:21, 4 April 2016 (UTC)
One-month focus on 5-6 link disambiguation pages.
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)
Move reason preview
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)
Use of local forms of English
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)
Auto-hyphenating words for alignment in all articles?
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)
Introduce different colours for links to different things
Anyhow, I basically just wanted to suggest that different colours should be used for different things when links are used in articles. I will give an example.
For example, when you read an article about a person or a war or something similar, there might be a reference to a rebellion or something similar, now very often if you click on a link where it says "rebellion", is takes you to an article about said rebellion, but very often you also come to an article that explains what a rebellion is.
So basically I would just like to see (in the future), maybe links having different colours if it's an explanation of a certain term, compared to a link to something that is not a description of terminology, such as an event, person etc.
I know that if you hold your mouse cursor over a link it shows where it leads most of the time, though when you are on slow internet or in a public library or so, this might take a lot of time, also loading pages back and forth when you realize you are being explained what a rebellion or an apple is.
It's a small problem I know, I just think it would be helpful.
RfC: Preferred protocol for external links
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 {{Centralized discussion}} and at WT:EL. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:26, 8 April 2016 (UTC)
Prefer 'a'
Prefer to use https://
- 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)
- Kaldari (talk) 19:00, 9 April 2016 (UTC)
Prefer 'b'
Prefer to use http://
- [your comment & sig]
Prefer 'c'
Prefer to use //
- [your comment & sig]
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.
- 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)
Invalid Question
Please explain exactly why you think this is invalid (wrong place, consensus already established, begs the question, etc)
- 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)
Religious messages
I propose that people should not be allowed to use their Wikipedia user pages, signatures etc. to promote their religious beliefs. 81.152.70.247 (talk) 00:28, 9 April 2016 (UTC)
- Wikipedia:What Wikipedia is not#Wikipedia is not a soapbox - Says no advocacy.
- Wikipedia:User pages#What may I not have in my user pages? - Agrees.
- Wikipedia:Userboxes#Content restrictions - Agrees, but
- Wikipedia:Userboxes#Life, personal status and situation - lists religious userboxes
- User:UBX/Userboxes/Religion - like these.
- Wikipedia:Userboxes#Life, personal status and situation - lists religious userboxes
- I'd imagine this has been discussed many times before, and it's all very open to interpretation. I personally couldn't care less; each to their own fredgandt 04:59, 9 April 2016 (UTC)
-
- Personally, I have no problem with a user identifying his religious beliefs (or the lack thereof) on his user page with an infobox or otherwise. There is a difference between mere identification (which can, indeed, be useful in understanding where a user is coming from and it's the kind of revealed information about a person which helps to build community here) and advocacy or promotion, which I agree is inappropriate, though I think a good deal of tolerance should be exercised in regard to user pages. A couple of infoboxes, even if kind of fervant, should be tolerated; long rambling essays, proselytizations, or screeds should not. Raising it in a signature, however, might well be pushing the line, since a signature will be repeated again and again. On the other hand, I think that existing policies and guidelines, including those listed by Fred Gandt, above, are more than sufficient to deal with any situation which might come up and I'd be opposed to writing any new specific rules about the issue. If you have doubt about a particular user's usage, first take it up with them, then if you get no satisfaction take it to an administrator or to ANI. Regards, TransporterMan (TALK) 05:44, 9 April 2016 (UTC)
- There is really only something to pick a fight over, and it would not surprise me to find more people promoting their atheist religious beliefs, and that they would have a lot hard time reining that in without feeling extremely suppressed. Mangoe (talk) 12:28, 9 April 2016 (UTC)
- In addition to the hurdles Fred has already pointed out WP:CSD#U5 applies "where the owner has made few or no edits outside of user pages". Users need to be substantial contributors before they start writing about their imaginary friends or anything else "not closely related to Wikipedia's goals". Bazj (talk) 12:50, 9 April 2016 (UTC)
- Don't care if someone espouses their beliefs, relgious or non-religious, on their user page. And actually it is a good way to vet bias in articles. Jaldous1 (talk) 16:06, 10 April 2016 (UTC)
-
- Something Bazj points out (purposefully or not) is where policy and good manners will decide inappropriate posts of pretty much any kind.
- "This user is [insert personal choice here]" is fine within reason, whereas "This user thinks [insert other's personal choices here] are deluded" or even "This user [insert thing that typifies a personal choice here] in order to save your retched souls" is definitely NOT okay.
- In other words, stating simply that one is inclined a certain way is (within reason) fine, but stating that not being that way inclined is bad, or that being inclined another way is bad, or even stating that being a particular way is especially good, begins to smack of advocacy or derision, which is not acceptable. fredgandt 16:23, 10 April 2016 (UTC)
Implementing Help:Maintenance template removal
- Note: the genesis for this started with Wikipedia:Village pump (miscellaneous)/Archive 51#Are notice tags demotivating?--Fuhghettaboutit (talk) 01:57, 10 April 2016 (UTC)
Hey all. For years we regularly get questions at various fora about maintenance template removal. (In fact, a few questions related to this issue were posted today (1, 2.) The questions we often receive show that:
- i) it is not obvious to many that maintenance templates are placed and removed manually. Many people assume there’s some mysterious automated threshold or A.I. program that governs removal;
- ii) some people seem put off from helping out in the first place—refrain from tackling the problem the template flags—because the process of template removal is neither obvious nor transparent;
- iii) because there’s nothing in the display of most templates to indicate to the reader that they can dive in to help, and no link to a page explaining the process (as proposed here), they assume it’s some job for an elite class of user (and so we lose the desperate help we need from the masses); and
- iv) people often do not grasp what needs to be done to address the issue flagged by the template, despite the links in them.
So, I’ve drafted Help:Maintenance template removal. The intent is that we add to the display of a variety of maintenance templates the following text, linked to this help page:
I’ve spent a lot of time at this help page not just describing the ins and outs of the removal process, but a section addressing some some of our more important and high-use templates — explaining the issues involved, relevant guidelines and policies, and what needs to be done before removal.
If consensus is gained to add such a proposed link to maintenance templates, whether as currently drafted or as suggested after discussion, I will need some help from the more tech-savvy as to the proper way to incorporate the link into the templates. Right now my manner of adding it, as seen in the {{unreferenced}} example I used at the help page, does not play well with that template’s date parameter (“April 2016”), which should appear after the main text, not after the proposed link.--Fuhghettaboutit (talk) 01:57, 10 April 2016 (UTC)
- Misunderstandings about the purpose of templates and the process of removing them seem to be fairly common among new editors. I would Support adding a notice like this to maintenance templates. It is possible that this could lead to some templates being removed prematurely, but I think making the process easier to understand is worth it. Howicus (Did I mess up?) 02:11, 10 April 2016 (UTC)
- Support. One thought: new editors who this is aimed at may not understand that the message they are seeing comes from a template. So might it be more meaningful to refer to "how and when to remove this message"? --Gronk Oz (talk) 02:36, 10 April 2016 (UTC)
-
- Hey Gronk Oz. How about "how and when to remove this template message"? I kind of like the idea that we're being precise and teaching what the "thing" is (a template), but I like your idea too. Plus, this mirrors the name of WP:TM.--Fuhghettaboutit (talk) 02:49, 10 April 2016 (UTC)
- Support A great idea. I would not object to minor wording changes. Cullen328 Let's discuss it 06:44, 10 April 2016 (UTC)
- Support Excellent idea. Templates are about 3rd dan for most new editors, and some more accessibly presented How-To would clearly be welcome.-- Elmidae (talk) 13:33, 10 April 2016 (UTC)
- I would definitely support this. This issue comes up over and over at the Teahouse. DES (talk) 15:14, 10 April 2016 (UTC)
- Support anything that helps new uses is welcome. I assume that it only apples to the box type templates and not the inline versions. Keith D (talk) 15:54, 10 April 2016 (UTC)
-
- Hey Keith D. At present, yes, this is geared toward and would only apply to the box type. The templates for which I provided specific instructions at the help page are where I thought these would first be added.--Fuhghettaboutit (talk) 16:58, 10 April 2016 (UTC)
- Support. Needed and necessary. GenQuest "Talk to Me" 16:48, 10 April 2016 (UTC)
- Support per everybody. ―Mandruss ☎ 17:16, 10 April 2016 (UTC)
- Good idea. If anything, it's a way to help people realise they can edit Wikipedia. BethNaught (talk) 17:23, 10 April 2016 (UTC)
- Support. Excellent idea. --ColinFine (talk) 17:35, 10 April 2016 (UTC)
- Support - great idea. Thanks for working on this. Ajraddatz (talk) 17:42, 10 April 2016 (UTC)
- Support - this issue comes up a lot at the Teahouse, and this seems a good way to try to help new users understand the issue. Cordless Larry (talk) 17:44, 10 April 2016 (UTC)
- Support - and a hearty pat on the back for the effort. Comment - There's currently a RfC at {{Multiple issues}} (talk) about showing links to related talk page sections, for discussion of the issues raised, in the concise versions of maintenance templates. I would suggest that this proposed change and any that may arise from that discussion be borne in mind together. fredgandt 17:51, 10 April 2016 (UTC)
- Support — I think the tendency for most people who aren't experienced with Wikipedia's mechanisms is to view maintenance tags simply as red flags over particular articles' reliability, and not as actionable issues that can be resolved and then checked off. This change is a good idea that would perhaps put them to better use. —Nizolan (talk) 01:57, 11 April 2016 (UTC)
Automatically setting PC protection level for BLP's
Hello folks,
Our BLP policy states that "contentious material about living persons (or, in some cases, recently deceased) that is unsourced or poorly sourced – whether the material is negative, positive, neutral, or just questionable – should be removed immediately and without waiting for discussion." Having said this, it seems that anonymous editors frequently make changes to BLPs without citing properly. Since in most cases these changes are immediately visible to the public and could potentially lead to misinterpretation, I would like to suggest that all BLP article edits be subject to review by default, so any material that violates the violate the BLP rule could be removed without being visible to general users who don't really do editing but just reading.
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 762,500 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)
- 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)
Using the edit filter to enforce ArbCom or Community bans Reply
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)