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, 131 |
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 Use of local forms of English
- 6 Introduce different colours for links to different things
- 7 RfC: Preferred protocol for external links
- 8 Religious messages
- 9 Implementing Help:Maintenance template removal
- 10 Automatically setting PC protection level for BLP's
- 11 Using the edit filter to enforce ArbCom or Community bans Reply
- 12 Problem a new article just by a small and big letter difference
- 13 Watson and next generation improvements to the standard Wikipedia search box
- 14 Seeking opinion about edit-protected request
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 28,003,268 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)
- Support – It seems unconscionable to me to feed readers incorrect information and fail to take any proportional remedial action. Firstly: of course there is a difference between minor edits of the style commonly requested at Main Page/Errors and outright falsities. It should be assumed that correction notices are unnecessary for grammatical or stylistic subtleties, minor ambiguities and the like. The proposal already states that this would only apply to factual errors. As far as the idea of a "shame list" goes, people should be wary of introducing factual errors, and perhaps it will serve as an incentive to be thorough in editing. I don't consider an impersonal correction notice to be a "shame list" anyway, though; very few people check or care about the individual people behind the DYK hooks anyway. The "encyclopedia, not a newspaper" point is well-taken, but highlighting information on the main page is an editorial judgement and should be subject to similar standards of integrity to other forms of edited publishing. —Nizolan (talk) 01:17, 12 April 2016 (UTC)
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)
- Comment: Just what exactly the OP is proposing is highly ambiguous, and some of the above responses seem to have adopted different of the multiple possible interpretations. If the user simply wants a script that allows them to view a rough translation of a given word, utilizing manual selection I'd direct them towards [translate.google.com google translate]. If they want a script that translates and transcribes a term when places in our internal search engine, that would be a major project, though probably not infeasible in theory. If they want to have actual parentheticals which include a transcription of every term introduced for every language that could reasonably be concerned with the topic (of the article or term), that is obviously just not possible for a variety of reasons. Again, it's quite questionable what PGAwade is asking for here, but the least we can tell them is that, as a general rule, non-English content (especially in non-English scripts) is severely restricted to certain niche contexts on this project, as as a matter of longstanding community consensus as to pragmatics and the fact that this particular Wikipedia is meant to facilitate the sharing of information through English, insofar as article content is concerned. Snow let's rap 11:13, 11 April 2016 (UTC)
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)
Successful WikiProjects usually have some chatter going. You might find a large WikiProject in an area that interests you, and join in. Alternatively, some of this happens on a few users' talk pages. WhatamIdoing (talk) 05:29, 13 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)
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.— Preceding unsigned comment added by Chronicler87 (talk • contribs) 10:14, 8 April 2016
- The manual of style for linking already strongly encourages articles to be written such that "the reader knows what to expect when clicking on a link", for this reason. It can be achieved by the structure of the sentence and the link alone - "Cao Qin led the rebellion against the Emperor" links to the general article about rebellions, and "Cao Qin led the rebellion against the Emperor" links to an article about that specific rebellion. --McGeddon (talk) 10:48, 14 April 2016 (UTC)
- At the top of this page, there's a discussion about enabling hovercards by default which is quite relevant.
- Whilst the manual of style dictums on link formation (noted by McGeddon above) provide guidance, the actual encyclopedia is massive and full of errors - which is of course where WikiGnomes come to the rescue; there's nothing that can't be fixed.
- Some kind of automatic solution is at present practically impossible, and would require either powerful AI or a Semantic Web - neither of which is likely to rule the roost here any time soon. fredgandt 11:16, 14 April 2016 (UTC)
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)
- Per Mandruss. APerson (talk!) 00:36, 15 April 2016 (UTC)
Prefer 'b'
Prefer to use http://
- Less things that can go wrong. –Be..anyone 💩 22:59, 12 April 2016 (UTC)
- Most websites will upgrade the connection to https:// if the browser supports it, like Wikipedia does, and if we link to http:// websites that do not support https:// with https:// links, then those links will appear to be not working. Tom29739 [talk] 17:36, 13 April 2016 (UTC).
- This RfC has nothing to do with websites that do not support HTTPS. Please read the intro. However, http://news.google.com does in fact upgrade to HTTPS, as you say. That would appear to change the issue somewhat. I wasn't involved in previous discussions, so I don't know whether that was considered there. ―Mandruss ☎ 17:48, 13 April 2016 (UTC)
- Bender235? ―Mandruss ☎ 18:00, 13 April 2016 (UTC)
- Update: The upgrade was apparently being done by my browser (Firefox), not by Google, because I had previously visited news.google.com in that browser using HTTPS. When I tried it in Microsoft Edge, which had never visited that site, it did not upgrade. ―Mandruss ☎ 18:30, 13 April 2016 (UTC)
Prefer 'c'
Prefer to use //
- No reason to force the protocol on people; the encryption adds overhead and some people (e.g. on metered bandwidth) don't want it. Second preference is for 'a'; if we were to force one, it should be the secure one, per common sense. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:07, 12 April 2016 (UTC)
- @SMcCandlish: One of us is misinformed. As I understand it, this option merely carries forward the existing protocol, which for Wikipedia is now always HTTPS. Thus, 'a' and 'c' are identical in effect, for links from this site. There is no option that does not "force" one protocol or the other; 'a' and 'c' "force" HTTPS and 'b' "forces" HTTP. ―Mandruss ☎ 18:32, 12 April 2016 (UTC)
- If you tell it "//", will it not try https://, and failing that, fall back to http://? I thought that was the point. I might well be misinformed. If it's just an alias for "https://", then yes, let's use that instead. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:01, 12 April 2016 (UTC)
- @SMcCandlish: One of us is misinformed. As I understand it, this option merely carries forward the existing protocol, which for Wikipedia is now always HTTPS. Thus, 'a' and 'c' are identical in effect, for links from this site. There is no option that does not "force" one protocol or the other; 'a' and 'c' "force" HTTPS and 'b' "forces" HTTP. ―Mandruss ☎ 18:32, 12 April 2016 (UTC)
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)
- Oppose 'c' - Less recognizable as a link to the layman.—Godsy(TALKCONT) 04:14, 12 April 2016 (UTC)
- @Godsy: This seems easily recognisable as a link to me: Layman. How does it not, to you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:16, 13 April 2016 (UTC)
Invalid Question
Please explain exactly why you think this is invalid (wrong place, consensus already established, begs the question, etc)
- Invalid Question The question says "there seems to be no consensus" but the strong consensus as established in multiple discussions is to use HTTPS whenever and wherever possible (including external links) and to use HTTP only when HTTPS fails to bring up the desired page. (This is also posted in the wrong place, IMO, but that can be easily fixed with a move and a link to the new location.) --Guy Macon (talk) 15:10, 8 April 2016 (UTC)
-
-
- This pretty much sums it up. Google and Archive.org support and encourage HTTPS connections, but so do Yahoo.com and a couple of other sites. For instance, HTTPS works for a lot of university websites, such as U of Chicago or Brown U, therefore we should link to the secure connection preferably. Only if HTTPS is not supported, we should leave HTTP. --bender235 (talk) 20:14, 13 April 2016 (UTC)
-
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)
- There are no "atheist religious beliefs". HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 11 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)
- If a user starts to add major Jewish (or Muslim, or Catholic, or atheist) POV issues in articles, it would be very useful for the project if this user also happens to admit to being Jewish (or Muslim, or Catholic, or atheist) prominently on his/her userpage. עוד מישהו Od Mishehu 05:41, 11 April 2016 (UTC)
- If a user starts to add any non-neutral POV we already have policies to deal with that. WP is about facts with sources not about opinions or biases, religious or otherwise. Saying we need to ask a user to divulge their religious views to ensure good editing is saying WP's key policies of WP:V, WP:RS, WP:NOR, and WP:AGF do not work. The day that becomes true I will quit editing and even quit reading WP. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 06:28, 11 April 2016 (UTC)
- The OP's question was about promotion which would clearly be POV if it were in article space. In their own user space, not so clear. As Od Mishehu pointed out, disclosure is good. Even better to edit in such a way that nobody ever suspects you even have an opinion, and that the question of POV never arises.
- If the disclosure crosses the line into proselytising or bearing witness, it's clearly "not closely related to Wikipedia's goals", and clearly flags up a topic on which the editor may be easily trolled (as Fred_Gandt called me on above). As the late, great Dave Allen used to sign off, "May your god go with you", Bazj (talk) 07:18, 11 April 2016 (UTC)
- Obviously, there are red lines even in this context; certainly, though, any content which would fit into a normal-sized userbox in normal-sized text would be too short to be proselytising. עוד מישהו Od Mishehu 14:40, 11 April 2016 (UTC)
- If a user starts to add major Jewish (or Muslim, or Catholic, or atheist) POV issues in articles, it would be very useful for the project if this user also happens to admit to being Jewish (or Muslim, or Catholic, or atheist) prominently on his/her userpage. עוד מישהו Od Mishehu 05:41, 11 April 2016 (UTC)
- Unless sharing sharing personal preferences of any type that aren't strictly related to encyclopedia editing is prohibited, which would basically force everyone to edit anonymously, expressing personal preferences of any type could fall under the first three bulletin points the IP mentions (if we interpret them in the manner the IP is).—Godsy(TALKCONT) 04:24, 12 April 2016 (UTC)
-
- We only ask that editors be professional, not perfect. Set aside your personal biases to the best of your ability and only add content that can be appropriately sourced. That is all. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 05:00, 12 April 2016 (UTC)
- @Koala Tea Of Mercy: My comment is mainly in response the notion users shouldn't be allowed to put userboxes (or just state it in general) stating their religion on their userpage (and signatures to a certain extent). Nothing to do with editing articles. To sum it up: Almost all preferences are allowed to be expressed (pedophilia is a notable exception). They are either all in or all out. We can't discriminate upon the expression of religious views by assuming expressing that particular preference is an attempt to proselytize, advocate, or an indication of more bias than any other association or veiw expression. Statements and expressions like rainbow flags, peace signs, Flying Spaghetti Monsters, and even nationality (notably those Canadians with their 🍁 signatures ) and sex would all have to be disallowed.—Godsy(TALKCONT) 06:45, 12 April 2016 (UTC)
- We only ask that editors be professional, not perfect. Set aside your personal biases to the best of your ability and only add content that can be appropriately sourced. That is all. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 05:00, 12 April 2016 (UTC)
- This proposal is rather broad. As for signatures - I don't really have issue with someone adding a character to their signature unless it is specifically offensive; I'm opposed to adding POV messages to signatures though - they are meant to be identification points only. As for user pages - I'm fine with people self identifying their beliefs (e.g This user is a christian) because it also helps identify potential COI's -- but I'm opposed to using userpages for "promoting" of personal beliefs in general. — xaosflux Talk 18:34, 12 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)
Discussion (maintenance tag removal)
- 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)
- Comment, good help page, maybe start with 1..3 cleanup templates to test/show your intended link feature. –Be..anyone (talk) 22:25, 11 April 2016 (UTC)
- Support-- I read the Help article and it was like a breath of fresh air. Thank you so much User:Fuhghettaboutit for this long overdue addition. Fritzmann2002 18:11, 13 April 2016 (UTC)
- Support - excellent work. JohnCD (talk) 19:10, 13 April 2016 (UTC)
- Support - Well thought out solution. Gmcbjames (talk) 00:12, 14 April 2016 (UTC)
- Support - A good solution to a real problem. The help page is good and very accessible. Happy Squirrel (talk) 04:54, 14 April 2016 (UTC)
- Support all efforts and any implementation approach to do this. We have a major problem with new editors believing that some anointed admin needs to decide even the most obvious of cases, so they add refs but leave {{unref}} at the top of the page for months afterwards. Seriously: it's occasionally awkward if we screw up a widely used template, but the fact is that this is a wiki, and if we don't like the first place/color/size/style/whatever, then we can change it later. Let's do this. WhatamIdoing (talk) 18:07, 14 April 2016 (UTC)
Implementation discussion (maintenance tag removal)
- This section was originally posted to Wikipedia:Village pump (technical)#Template help and relocated here.
<introductory text removed as out of context here> What I need is help with the technical aspect of doing this – a standardized way to pass that link through to the templates. It should appear after all other content, after a line break. The way I've done it up to now (as seen in the examples I placed at the linked help page) is to just add the message after a break (<br />) to the fix= parameter these template all have. But the result is that the date parameter of the templates appears after the link:
- • Learn how and when to remove this template message. (April 2016)
So, what needs to be done in order to leave the date parameter where it belongs, after the main template content, and have the link appear after all of that content? Is there a way to keep it in the fix parameter but make the date not appear after it? If not, do we need a new parameter in Ambox to accomodate the link (which if I understand correctly is just a conduit for Module:Message box, so is there a change needed there?)? Thanks--Fuhghettaboutit (talk) 00:34, 14 April 2016 (UTC)
@Fuhghettaboutit: Would this be any better (I know it's not exactly what you want, but appears to be an improvement)?
Mdann52 (talk) 12:13, 14 April 2016 (UTC)
- Thank for responding Mdann52. I really think it should be set off in the manner proposed. It's not part of the main text, and interrupts its flow.--Fuhghettaboutit (talk) 12:17, 14 April 2016 (UTC)
- Please add
{{multiple issues}}
near the top of your test list, it should not trigger multiple links to the same help page. A WikiProject Templates exists or existed, maybe you find more support there. –Be..anyone 💩 12:58, 14 April 2016 (UTC)
- Please add
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 763,003 BLPs on Wikipedia (number dynamically updated). I doubt this would be feasible, though I agree with your concerns. BethNaught (talk) 07:19, 10 April 2016 (UTC)
- Technically, I think that writing an adminbot to handle this would probably be practical; a one-time run on all non-protected BLPs, and real-time maintenance would probably work. It could certainly remove PC on any BLP when the category is removed by an account with over X months and Y edits when the protection reason includes any of specific words; and report any BLPs with PC when either the removal is done by a newer account or where the protection reason is anything different. It could also monitor any additions to CAT:LP and use a protection reason which uses one of these words. I think, though, that we have a different issue here - the backlog of pending changes. עוד מישהו Od Mishehu 04:49, 14 April 2016 (UTC)
- To put it in perspective, that's approx. 15% of all articles.—Godsy(TALKCONT) 05:24, 14 April 2016 (UTC)
- Per Jasper, basically. Not all BLPs need the extra layer of scrutiny. I do like PC in that it lets anyone still edit (I would certainly oppose any attempt to mass-protect articles), but I don't think this idea is practical or particularly needed. Ajraddatz (talk) 08:51, 10 April 2016 (UTC)
- Oppose partly as per Bongwarrior and Jasper. Also i dislike PC protection in general, it takes away from the immediacy that is the Wiki experience, adn can confuse new editors. DES (talk) 15:10, 10 April 2016 (UTC)
- Qualified Support I would point out that certain areas now have a more stringent rule than this (the 500 edit rule), and that the "backlog" of BLPs is exceedingly unlikely to reach even 2,000 edits, much less hundreds of thousands. In fact, many articles are not edited as often as once a year in the first place. So the "it would inconvenience us to require vetting of edits by IPs" is weak. Rather, it is the fact that some edits may cause actual harm to living persons which should govern our actions - if we have a tool to prevent harm, we would be remiss in dismissing it. Collect (talk) 14:55, 11 April 2016 (UTC)
- Weak support I think the fact that vandalism to BLP-articles doesn't go "live" is slightly more positive than the problem of, admittedly, confused new editors. As for the workload....we just would have to see. Lectonar (talk) 15:10, 11 April 2016 (UTC)
- Oppose - we need to keep PC down to an appropriate workload level; since BLP edits are too frequent, it will make the PC log be too backlogged all the time. עוד מישהו Od Mishehu 09:33, 12 April 2016 (UTC)
- Oppose due to the surety of a backlog in this proposed process. There aren't enough WikiGnomes out there. GenQuest "Talk to Me" 00:12, 14 April 2016 (UTC)
- Oppose - I've been known to check Special:PendingChanges and review pending changes from time to time. It isn't uncommon for some changes to remain un-reviewed for 12 hours or so. To apply this en masse to biographies of living people which haven't been shown to be problematic would be in violation of the regulations community consensus set for pending changes protection. Secondly, this would be way too many edits for our volunteer community here to reasonably review in a timely manner (on a side note: only approx. 8,000 users have currently have this right). The only pragmatic way to guard articles in this way would be to disallow un-registered and non-autoconfirmed users the ability to edit biographies of living people, though I wouldn't support that either, and I believe similar proposals have failed to gain consensus in the past.—Godsy(TALKCONT) 05:12, 14 April 2016 (UTC)
- A more useful approach might be to sit down with a database query and make a list of the "1,000 most reverted BLPs", and consider just those. WhatamIdoing (talk) 18:09, 14 April 2016 (UTC)
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)
- Any eidt filter we create must meet 2 basic criteria: They must have a reasonable number of hits (not too few, since that would make it a waste of resources; not too many, since that would probably show that the filter is catching too many false positives); and it must be quick enough to check for every edit. I doubt that there is much ArbCom enforcement that could be written into filters which meet both of these criteria. עוד מישהו Od Mishehu 09:36, 12 April 2016 (UTC)
- Mwaagh, I think that this is in principle a good idea that I c/would support, it may only be a technical problem why we don't. But these filters can be reasonably fast:
IF (user_name) EQUALS <restricted user>
results in a false for almost every edit, and would not cost a lot of resources. Adding a"AND page_name IS ONE OF "list of pages"
will add some processing time for the edits that do hit (but then, only for the restricted user .. and such an editor did not get restricted for nothing; it would need some paperwork to get the list done, which could always be expended when necessary), but in general this will not bring down Wikipedia. Then you add further specifications down the line if needed, or you leave it at this and let it just 'tag'. It only becomes a problem if the restriction is not too page and not too user specific ("no-one should edit these 2000 pages long list of pages more than 3 times in any stretch of 7 days"). If the filter is tag only, it becomes a quick checklist, and if it is specific enough it can be restricted as well. - I think that the real question is, why does the WMF not either allocate more processing power to the edit filters to both speed them up ánd so the community has the possibility to write more edit filters, or have the development team write 'clones' of the abusefilter for commonly used tasks and which can then run much faster by design: a check enforced by code (only apply this when
user = <username>
) or only apply this whenuser-right = unconfirmed-checkbox
) is always faster than a check of an interpreted code (interpret "if user = <username>" or "NOT user-right = confirmed", fill in the variables and then get the result) - and there are many filters that start with these checks that we now don't write just because overall it is too slow at the moment, and the suggested filters are among them. --Dirk Beetstra T C 10:57, 12 April 2016 (UTC)
- I oppose of this, if a sanctioned editor can't follow the terms of their restriction the door is right over there. — xaosflux Talk 12:14, 12 April 2016 (UTC)
- That is true regardless if you use an edit filter to block the edits / detect possibly conflicting edits or not (in the end, this just gives you an easy to access on-wiki record), so I am not sure what you oppose here. --Dirk Beetstra T C 13:03, 12 April 2016 (UTC)
- To clarify, managing the edit filter is a careful balancing act of scalability of the tool, and administrative overhead of the filters - managing comprehensive lists of user to page/category mappings is setting us up for a management nightmare - we already have enough headache when short-term filters have to be built for individual vandals. — xaosflux Talk 18:29, 12 April 2016 (UTC)
- I see that point, but that goes both ways. The current bans are an administrative nightmare as well. Sneaky editors could circumvent bans, and many editors are not aware that a certain editor is banned from certain topics, and edits may go through because of that. It needs quite a number of editors to keep an eye on the edits of a banned editor to see if they are editing in violation of said ban (and you see that happening, some editors turning into a form of WikiPolice, and just a couple of the editors become the judge of the appropriateness of the edits by the banned editor). --Dirk Beetstra T C 08:06, 13 April 2016 (UTC)
- To clarify, managing the edit filter is a careful balancing act of scalability of the tool, and administrative overhead of the filters - managing comprehensive lists of user to page/category mappings is setting us up for a management nightmare - we already have enough headache when short-term filters have to be built for individual vandals. — xaosflux Talk 18:29, 12 April 2016 (UTC)
- That is true regardless if you use an edit filter to block the edits / detect possibly conflicting edits or not (in the end, this just gives you an easy to access on-wiki record), so I am not sure what you oppose here. --Dirk Beetstra T C 13:03, 12 April 2016 (UTC)
- If the edit filter system were optimized to the point that we could have 1000s of filter with no discernible impact on performance, then sure we could apply per user and per page filters. Right now the limits placed on the filter system (in part due to design issues that could be improved) mean that we need to prioritize its use for filters that are likely to get significant hits and avoid filters that are so specialized that they will rarely be triggered. Dragons flight (talk) 13:21, 12 April 2016 (UTC)
- Even if we had much more powerful hardware and software, Dragons flight, even if we could apply the full power of, say, IBM's "Watson" to each and every edit separately, correctly determining which edits do and which do not fall within a complex topic ban is not a trivial task for an algorithmic system. And a filter that gets it right more often than not but has a significant error rate might be worse than useless - we might trust the filter more than we should, leading to worse outcomes. Until we can run edits though HAL9000 or some other truly intelligent system, I don't think this is a task to approach with a program. DES (talk) 18:24, 12 April 2016 (UTC)
- I'm imagining that an Arbcom directive gets implemented as a filter simply saying that X person is not allowed to edit articles A, B, and C. Human(s) would have to decide on the list of which articles are covered, but the filter itself would be easy to implement. To the extent that the targeted list ends up being incomplete / incorrect, one would have to allow for additional articles be added or removed from the list, again subject to human review. However, we already have edge cases and discussion about interpretation of various Arbcom restrictions. All of this HAL9000 stuff is a red herring in my mind. We don't need an edit filter that can decide which articles involve "Neoclassical Romanticism" (or whatever the prohibition de jour happens to be). We simply need humans that are willing to discuss what the prohibitions ultimately mean and try to spell it out in concrete terms. (Of course if humans aren't willing to do that, then such filters will probably never be created.) Dragons flight (talk) 18:46, 12 April 2016 (UTC)
- But in practice I have yet to see a topic ban defined in terms of an explicit list of articles. It is always of the form "Editor:Example may not edit articles connected with Neoclassical Romanticism, broadly construed". Sanctioning admins are supposed to employ judgement in assessing any given edit as to whether it violates the terms of the ban. In some cases things are broader: "Editor:Example may not make any edits on the subject of Neoclassical Romanticism, broadly construed, in any any article at all". Here it is the subject of the edit, not the subject of the article, that is the criterion, and human judgement at the edit-by-edit level is even more obviously required. This flexibility is by design, to avoid the subject of the ban gaming the system, and to afford the sanctioning party some leeway when what seems to be a technical violation doesn't fit the reasons for the TBAN. If the cost of programmatic enforcement is that an explicit list of affected articles must be compiled in advance, i don't think most people will see it as an improvement. And in the absence of such a list, separating violations from legit edits is a hard problem. I honestly don't think current AI is up to making that distinction with sufficient accuracy to serve this purpose at this time. DES (talk) 22:14, 12 April 2016 (UTC)
- When I use edit filters, I generally do that to detect editors. I have a block-evading editor with reasonably signature edits using one or two ranges, or mainly targetting specific pages, and I write a filter on that. Does that filter catch everything? No, it catches maybe 90% (and people find a way around). Does that make the filter useless? No. If the editor trips the filter once, I know to check the other edits as well. Is my filter finished? No, I regularly have to add pages, signature edits, etc. Do I have to now consider that if my filter is not tripped that I can assume the editor is not there? No, but instead of checking every day the whole range, I check once every week. The filter is saving me work.
- The same would be true here. Some bans are plain clear: 'stay away from subject X'. Hence, there are no edits that are not a violation of TBAN, every single edit is. The instruction is clear, stay away. That is very easy to catch in a blocking filter, an expandable list of pages not to touch. If the ban is not that black and white, then indeed the edits may not be blockable, but then the filter goes to tag-only and people will check the hits to the filter (if it has a visible tag, even other editors may do that work for you, bringing down the workload). And there will be bans that are not suitable for this at all, and nothing will change, you will have to do everything by hand. A sneaky banned editor may be able to do edits under the radar, but with the help of filters, that radar has a much finer maze to detect. --Dirk Beetstra T C 07:56, 13 April 2016 (UTC)
- It should be noted that I think the filter does not use short-circuit evaluation (I think it's a long-requested feature though), which would negate the benefit of checking the username first in an and expression (as would be required by the filter).--Jasper Deng (talk) 21:21, 14 April 2016 (UTC)
- But in practice I have yet to see a topic ban defined in terms of an explicit list of articles. It is always of the form "Editor:Example may not edit articles connected with Neoclassical Romanticism, broadly construed". Sanctioning admins are supposed to employ judgement in assessing any given edit as to whether it violates the terms of the ban. In some cases things are broader: "Editor:Example may not make any edits on the subject of Neoclassical Romanticism, broadly construed, in any any article at all". Here it is the subject of the edit, not the subject of the article, that is the criterion, and human judgement at the edit-by-edit level is even more obviously required. This flexibility is by design, to avoid the subject of the ban gaming the system, and to afford the sanctioning party some leeway when what seems to be a technical violation doesn't fit the reasons for the TBAN. If the cost of programmatic enforcement is that an explicit list of affected articles must be compiled in advance, i don't think most people will see it as an improvement. And in the absence of such a list, separating violations from legit edits is a hard problem. I honestly don't think current AI is up to making that distinction with sufficient accuracy to serve this purpose at this time. DES (talk) 22:14, 12 April 2016 (UTC)
- I'm imagining that an Arbcom directive gets implemented as a filter simply saying that X person is not allowed to edit articles A, B, and C. Human(s) would have to decide on the list of which articles are covered, but the filter itself would be easy to implement. To the extent that the targeted list ends up being incomplete / incorrect, one would have to allow for additional articles be added or removed from the list, again subject to human review. However, we already have edge cases and discussion about interpretation of various Arbcom restrictions. All of this HAL9000 stuff is a red herring in my mind. We don't need an edit filter that can decide which articles involve "Neoclassical Romanticism" (or whatever the prohibition de jour happens to be). We simply need humans that are willing to discuss what the prohibitions ultimately mean and try to spell it out in concrete terms. (Of course if humans aren't willing to do that, then such filters will probably never be created.) Dragons flight (talk) 18:46, 12 April 2016 (UTC)
- Even if we had much more powerful hardware and software, Dragons flight, even if we could apply the full power of, say, IBM's "Watson" to each and every edit separately, correctly determining which edits do and which do not fall within a complex topic ban is not a trivial task for an algorithmic system. And a filter that gets it right more often than not but has a significant error rate might be worse than useless - we might trust the filter more than we should, leading to worse outcomes. Until we can run edits though HAL9000 or some other truly intelligent system, I don't think this is a task to approach with a program. DES (talk) 18:24, 12 April 2016 (UTC)
Problem a new article just by a small and big letter difference
Problem a new article just by a small and big letter difference. an article "Vettar River" is made two times in name of "Vettar river".--wiki tamil 100 11:43, 11 April 2016 (UTC)
- @Wiki tamil 100: can you not just move the article to the right place (Vettar river) while leaving a redirect (as it appears a reasonably common typo). --Dirk Beetstra T C 11:49, 11 April 2016 (UTC)
Watson and next generation improvements to the standard Wikipedia search box
Although natural language use in search boxes is still a long way off, the recent press is full of announcements of IBM making massive investments into the use of WATSON software in the search boxes of the medical industry and various specialized business sectors. Is Wikipedia evaluating or talking about the possible use of WATSON software for improvements and enhancements to the standard Wikipedia search box currently in use at the top of the page. Fountains-of-Paris (talk) 15:28, 11 April 2016 (UTC)
- You are suggesting using advanced artificial intelligence to a software development team that, despite millions spent of search, created a search box where searching for "a = b" returns "R.A.B.", "A-B", "(a,b)-tree", "A. B. Guthrie, Jr.", and "A/B testing". If, for whatever reason (I strongly suspect bad management, not technical incompetence) they cannot manage to provide basic functionality such as searching for a literal string, for FSM's sake don't ask them to partner with IBM to try to provide A.I.! --Guy Macon (talk) 01:37, 12 April 2016 (UTC)
- You mean, just like google does and any other modern search engine. This is how search engines work these days, they ignore things like punctuation. If you want a 100% literal match, you need to use insource regexp searches. —TheDJ (talk • contribs) 16:07, 12 April 2016 (UTC)
- A point you probably have not considered is that WATSON is not just software, it is also highly proprietary hardware customized for high-speed AI algorithms. The software and the hardware are an inter-dependent system and one is useless without the other. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 05:08, 12 April 2016 (UTC)
-
- I believe that you are incorrect. Watson runs on SUSE Linux Enterprise Server with Apache Hadoop. Such systems are readily available, but the IBM hardware is presumably much faster. The real problem is that all of that expensive hardware answers one question by one user at a time. It would take a lot more computing power to handle all of the searches Wikipedia gets. --Guy Macon (talk) 05:50, 12 April 2016 (UTC)
-
-
- You are correct that WATSON uses SUSE Linux Enterprise Server and Apache Hadoop but these two software packages are only a fraction of the whole WATSON system. The core software is called DeepQA and that runs only on the proprietary POWER7 processors.
- From our own article on WATSON (see Watson_(computer)#Current_and_future_applications) allow me to point out this: "IBM also intends to market the DeepQA software to large corporations, with a price in the millions of dollars, reflecting the $1 million needed to acquire a server that meets the minimum system requirement to operate Watson."
- For a quick but detailed overview of the scope of the software and hardware used by the WATSON system take a glance at this pdf of a presentation made by IBM at one of the SHARE conferences. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 06:34, 12 April 2016 (UTC)
-
-
-
-
- You mean the PDF that says "All of the hardware is available for sale at your friendly international purveyor of business machines"? Your claim that Watson is "highly proprietary hardware customized for high-speed AI algorithms" is factually incorrect. Call IBM, pay them three million dollars, and they will deliver a shiny new cluster of ninety IBM Power 750 servers and all the networking hardware needed to run Watson -- none of it custom. Then of course you need to buy the Watson software, which looks like it will run you a couple of million more. Or you can accept a slower response time and use fewer servers. --Guy Macon (talk) 13:47, 12 April 2016 (UTC)
-
-
- The whole point is moot I think, since it is a proprietary system if I'm not mistaken, and we only use Free and open-source software for the core functionality of the website. —TheDJ (talk • contribs) 15:58, 12 April 2016 (UTC)
- TensorFlow is open source. Praemonitus (talk) 21:31, 14 April 2016 (UTC)
The "distance" of capability between Watson and the current Wikipedia search box
@Guy Macon, TheDJ, and Koala Tea Of Mercy:The distance between Watson and the current Wikipedia search box was discussed here [1]. Basically the current conventional search box does a little bit more than a simple search look-up which simply fails if the search item is not found. This was slightly improved a month ago to a 3-character look-back algorithm to correct letters only at the very end of the search item. For example "David Bowtie" will be corrected to "David Bowie" because the correction is only done at the end; if you type in "Fostoevsky" you get a failed search error message and no correction to "Dostoevsky" is even attempted. There are super fast algorithms for single letter correction, but Wikipedia is still short of accomplishing even that level. If Watson in the search box is not even on the radar screen for the Wikipedia search box, then what should be the expectation for the next generation of the standard Wikipedia search box improvement? Fountains-of-Paris (talk) 14:54, 13 April 2016 (UTC)
- You have to keep in mind that many AI problems are known to be NP-complete, i.e. we don't think we have efficient algorithms for them. This is part of why even Google pours tons of research into its search engine many years after it was first invented.--Jasper Deng (talk) 21:35, 14 April 2016 (UTC)
Seeking opinion about edit-protected request
Template_talk:Autoblock#Template-protected_edit_request_on_14_April_2016. Comments here or there are welcome. Feel free to throw questions at me. --QEDK (T ☕ C) 15:12, 14 April 2016 (UTC)