Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at the idea lab.
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Renaming Category:WikiProject Infoboxes

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [1]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk) 18:04, 15 January 2017‎ (UTC)

Proposal to submit blockers on replacing our wikitext editor

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Tracked in Phabricator
Task T154843

Tracked in Phabricator
Task T154844

The Wikimeda Foundation is working on a new software project called New Wikitext Editor (also known as NWE, or 2017 Wikitext Editor). The "new editor" is being built as a new wikitext mode within the Visual Editor extension. This allows the WMF to consolidate on a single editor with both Visual and wikitext modes. The plan is for this to become the default wikitext editor in a few months. The current wikitext editor would be temporarily retained as an opt-in in preferences, but eventually the current wikitext editor would be removed completely. Please view mw:2017_wikitext_editor for a more thorough explanation of the project, as well as the WMF's reasons for it. The new editor is available for opt-in testing under the Beta features section of Preferences.

The WMF is still working on a number of issues with the new software, however over the last few months several editors have raised a pair of issues which (in my opinion) they have not constructively addressed. Both of these issues appear to be a direct consequence of designing the "new wikitext editor" as a mode within Visual editor. The issues are:

1. Slow load time, primarily on larger articles. Different people may experience different load times, but I will report my experience. With the current wikitext editor I am able to start editing the article United States within 3 seconds after clicking edit. (The toolbar at top took a moment longer to finish loading, but that does not obstruct editing.) The new editor took 30 seconds to load before I could begin editing. With the current wikitext editor it took 5 seconds until I could edit our largest article (List of named minor planets (numerical)). With the new editor my load time was 127 seconds.
2. Faulty previews. The new editor does not provide genuine article-view previews. Instead it uses the Visual Editor rendering engine for previews. This results in a large assortment of things that render incorrectly in preview, or fail to render at all. The WMF has been working to address these issues for years as part of the Visual Editor work, and they plan to continue hunting down and fixing many of these rendering problems. However the WMF has indicated that some of these rendering problems are CANTFIX or WONTFIX. They hope to address the common cases, and their goal is to eventually get 99+% correct previews.

The WMF has been developing a Technical Collaboration Guideline. According to the guideline, the community is invited to submit "actionable blockers" on any software project. These are issues that block deployment unless/until the issues are adequately resolved. This RFC is seeking consensus to formally submit the one or both issues as actionable blockers. You may support one issue as a proposed blocker while opposing the other.

EDIT FOR CLARIFICATION: The WMF has been developing a Technical Collaboration Guideline. It is currently a draft. At least one WMF staff member has been actively seeking to test the guideline in action (Qgil-WMF) and another WMF staff member subsequently requested removal of any mention of the guideline (Keegan (WMF)). Editors are reminded that it is merely a draft. This RFC could be interpreted by the WMF as a test of their draft best practices for collaboration with us, or it could be interpreted as some generic consensus on the New Editor's prospects for successful deployment if specific issues are or are not addressed, or it could be interpreted in some other manner. In any case, our goal is to work with each other as partners in a positive and constructive manner, seeking to serve our shared mission to the best of our ability. Added: Alsee (talk) 20:27, 19 January 2017 (UTC)

Proposals:

1. Actionable Blocker: Load time. Load time is a priority concern for both new editors and experienced editors. Possible resolutions:
   • We could happily retain our current wikitext editor; or
   • if possible, drastically reduce New Editor load times, particularly on large pages.
2. Actionable Blocker: Article previews. Previews are a critical part of the learning process for new editors, as well as a critical tool for experienced editors. Inaccurate previews will confuse, disrupt, and frustrate. Possible resolutions:
   • We could happily retain our current wikitext editor; or
   • previews must use the article-view rendering engine (this is called the PHP parser), as well as any other relevant parts of the article-view software stack. This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software.

Alsee (talk) 00:04, 17 January 2017 (UTC)

Responses

• Support both. The load time on large articles is gross, and using an entirely different rendering engine for previews was a bizarre design decision. Unless both of these issues are adequately resolved, our current wikitext editor is clearly superior to the proposed replacement. If it ain't broke, DON'T BREAK IT! Alsee (talk) 23:52, 16 January 2017 (UTC)
• Support both Loading time is a problem with VisualEditor, I am guessing that it's a problem with Parsoid. And the preview engine should use the parser, not it's own software, otherwise it's just reinventing a wheel. A square one most likely. Jo-Jo Eumerus (talk, contributions) 00:08, 17 January 2017 (UTC)
• Strongly oppose removal. To clarify, strongly support both (03:58, 17 January 2017 (UTC)). On some very large pages the text editor takes a bit to load, let alone the JavaScript-heavy visual editor. The visual editor has its uses and I support keeping/improving it, but making it the sole option would definitely make it harder for me to edit. Daß Wölf 01:34, 17 January 2017 (UTC)

  It is a mischaracterization to say that the WMF is making the VE the sole option--it is that both the VE and the 2017 WTE use the same root software. --Izno (talk) 13:43, 17 January 2017 (UTC)

  Thanks for your reply, I wasn't aware that VE and 2017 WTE were different things. Still, new WTE also has bad loading times. For example, the minor planets list referenced by Yodin below takes about 20 seconds to render in reading mode, 5 seconds in normal edit source (less than reading mode!), 114 seconds in new edit source and at least 5 minutes and 12 timeouts in VE (I gave up). This page takes around 2.5 seconds in both reading mode and old edit source and 21 seconds in the new edit source. In both cases loading the new edit source caused prolonged browser freezing and delayed keyboard and mouse response as long as the minor planets page was opened in a background tab. I'm going with "don't fix what ain't broke" here. Daß Wölf 01:10, 18 January 2017 (UTC)

• Support both. I'd rephrase the first one as "loading times must be less than or equal to the current wikitext editor". Previewing using Parsoid is a mind-bogglingly stupid decision, especially when proper previewing is just an API call away. MER-C 02:59, 17 January 2017 (UTC)
• Support load time as a blocker. Do not support previews as a blocker. Previews are pretty gosh-darn close. --Izno (talk) 13:43, 17 January 2017 (UTC)

  Dear Izno, would you submit an edit when you can't preview it? --NaBUru38 (talk) 00:13, 24 January 2017 (UTC)

  @NaBUru38: You can preview your edits in WTE2017, though the workflow is a little wonky: Click "Save Changes", and in the box that pops up is an option "Show preview". There's a task open to pull the "preview" button onto the main editing screen at phab:T153306. The original poster of this discussion is making the distinction that previews are not 100% equivalent to the PHP parser (which is a fact, but lacking the context that something like 99%+ renders using Parsoid are correct), not that they don't exist. --Izno (talk) 00:27, 24 January 2017 (UTC)

• Support both as I will any other reasonable measures that may achieve allowing us to "happily retain our current wikitext editor". — Godsy ^(TALK_CONT) 13:46, 17 January 2017 (UTC)
• Weak support 2, wary about 1. Load times are going to vary from computer to computer and browser to browser, and I think it's hard if not impossible to explicitly say that a specific measured load time applies to everyone. I support the idea of 1, that load times should be at worst comparable to the current editor, but I'm not sure that in practice this is something that could be a certain result. As for 2, I'm fine with the current previewer (I assume there's a good reason for using it), provided it reaches parity with the old one and is consistent with the saved contents of the page. For the record I very much support the new text editor, and apart from the unintuitive copy/paste behaviour (being debated elsewhere I believe), will be happy to use it. Sam Walton (talk) 15:48, 17 January 2017 (UTC)
• Support both noting that 2 is particularly egregious. Also comment that I do not want the current wikitext editor to be dropped for a very long time. BethNaught (talk) 15:51, 17 January 2017 (UTC)
• Support both Having a resource heavy GUI as the only option would prevent a lot of contributions from editors who don't have the hardware or bandwidth to handle it, which defeats the object of wikimedia encouraging grassroots participation. Not everywhere is wikisilicon valley. In addition inaccurate rendering of previews can cause countless problems, direct and indirect.Cesdeva (talk) 22:41, 17 January 2017 (UTC)
• Oppose I've been using the new source editor since the beta was announced and haven't run into anything like the load times you describe. I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf). There are definitely some irritating usability issues, but neither of the items on your list seems worth throwing a wrench in the works over. Opabinia regalis (talk) 23:25, 17 January 2017 (UTC)
• Support both. I have a decent computer, but don't have broadband, and decided to try both of the examples given above. United States: in the current editor took 4 seconds before I could start typing, and 6 seconds before the full page loaded; in the new Visual Editor text mode, it took 35 seconds! Then List of named minor planets (numerical): in the current text mode it took me 8 seconds before I could start typing, and 14 seconds for the entire page to load; in the new editor, it took 90 seconds before timing out, then timed out again at 120 seconds, and took about 122 seconds in total to load. As pointed out above, these figures are just anecdotal, but now that the issue has been raised, please provide reliable stats on a range of modern and old devices, at various internet speeds and in various countries – we don't want to become "Wikipedia, the encyclopedia that anyone with a fast enough connection can edit"! I'm genuinely pleased for people who enjoy using the Visual Editor, and wouldn't want to take it away from them, but likewise please at least provide an option that will allow me and others in a similar position to keep editing. ‑‑Yodin^T 00:29, 18 January 2017 (UTC)
  • The best answer to the problem with List of named minor planets (numerical) is that 1.12MB is just too big for one article. I hope the people responsible for the 26 views per day via mobile aren't actually using their mobile data for that. Opabinia regalis (talk) 01:28, 18 January 2017 (UTC)
  • Speed varies considerably per account, browser, device, and location. For example, it took me just six seconds in Safari 10 and nine seconds in Firefox 50 to open United States in the wikitext mode of VisualEditor – much less than the time it took your computer. In Safari, VisualEditor's wikitext mode is slightly faster than reading the page; in Firefox, loading the page in read mode is one second faster than opening it to edit.
    The team has a standardized system for testing this. In general, the results are that short pages take faster than long pages; that VisualEditor is faster in Europe and Africa than in North America; that any method of editing wikitext is faster than anything that shows a lot of images (e.g., reading a page); that newer computers are faster than older computers; and that IPs and new editors have faster load times than experienced editors (who tend to have a lot of performance-harming scripts in their accounts). For a reasonable sample of pages (i.e., not just the longest ones), when editing as an IP (e.g., with no scripts or gadgets), with nothing else running (e.g., no other scripts running or tabs refreshing in the background), in a highly standardized setting, the time-to-open speeds are approximately the same for VisualEditor's built-in wikitext mode vs the 2010 wikitext editor.
    And then you impose all of the real-world, non-standardized conditions that affect each of us, and the answer becomes: Who knows? Your experience is your real experience, and whether your experience is fast or slow, it's not safe to assume that the next editor will have the same experience. Whatamidoing (WMF) (talk) 19:33, 19 January 2017 (UTC)
• Oppose (edit conflict) both procedurally and on the merits. Firstly, the technical guide is still a draft, it's not a guideline like the proposer states. I think it's far too premature to start implementing things from it. Secondly, the draft says that "Development teams participate in the discussion focusing on the proposed blockers (whether they are sensible, consistent with the project, actionable, realistic…)" so I am hesitant to make any decisions until the proposer shows they've discussed this with the devs or until the devs actually participate in this discussion. Thirdly, the purspose of "actionable blockers" is that they be actionable, they, in my mind, need to have clearly defined criteria for when they have successfully been actioned. Neither the proposal nor the draft technical guide adequately lay out how it is determined that an actionable blocker has been overcome. The draft says: "If the development team solves the blockers, the community will be asked for a new review. If no surprises are found, the deployment will proceed." What constitutes "surprises"? What is the threshhold for these proposed actionable blockers? Load times are highly variable, how will we determine an adequate level of load time? What if we just happen to have a discussion full of people contributing via Windows 95 who oppose the re-review? More likely, what if we just keep inflating our standards saying it's not fast enough or the preview isn't good enough in order to filibuster implementation? Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 01:37, 18 January 2017 (UTC)
• Support both. Both have long been known as serious VE problems, to introduce these (and other VE problems) into normal editing would be a very bad idea. Fram (talk) 09:32, 18 January 2017 (UTC). To be sure these are still problems, I switched on the new Wikitext mode again, and edited Leuchtenberg Gallery. Not only does it take too long (15 seconds!) before I can start editing, the preview doesn't give ma good idea of how the page will look eventually (e.g. by eliminating the left sidebar, increasing the width of the page). On a second try, I first did "review changes" and from that window "preview", with the result "Error loading data from server: Failed to connect." This happened three times in a row. I could still edit the page and review my changes, so connection wasn't really lost... On preview, I don't get to see redlinks. This is one of the essential elements of preview for me, as it allows the correction of bad links before saving. Opening Exposition des primitifs flamands à Bruges first returns the standard editor for some reason, a second try gives me the new wikitext editor, but only after 50 seconds, which is way too long. I added an image, asked for a preview, and again got "Error loading data from server: Failed to connect.". In standard editing mode (I at this point switched back, quite relieved that that option still existed) opening the page took a few seconds, previewing went without any problem and showed the page as it would look after saving, including redlinks and the like. Fram (talk) 10:00, 18 January 2017 (UTC)
• Oppose. I use primarily use the Visual Editor for content work and find the Parsoid preview adequate 99% of the time. In the few instances where it's troublesome (e.g. not seeing references), there's a very easy workaround: save the page. Excessive load times are a concern, but the proposed "blocker" is too vaguely worded to achieve anything. It seems to me that submitting a phabricator ticket asking for it to be profiled and reduced would suffice (if one doesn't already exist). – Joe (talk) 10:12, 18 January 2017 (UTC)
  • A. It seems a bit rude for someone not affected by this change (since you are a VE user) to oppose those who are affected by this change. B. "Saving" is no workaround for previewing, previewing is also meant for testing, but the mainspace is no place to test things. Of course, one can copy a page to a sandbox, comment out the categories, and then start testing, but this is no longer an "easy workaround" but a lot of haasle. C. Excessive load times of VE have been noted from the very start of VE, and numerous times since then[2], but have four (five, whatever) years later not been corrected. Yet another phabricator ticket won't solve this. (the "redlinks should be red" issue has been a ticket for more than a month now[3], no activity as far as I can see; other issues also are already phab tickets). Note that the new editor also seems to break some well-used gadgets and tools like Twinkle, apparently (I haven't tested this). Fram (talk) 11:00, 18 January 2017 (UTC)
    • Fram, the new editor is an entirely new system. Gadgets and scripts will need to be rebuilt from scratch. That adds a one-time cost to switching, but I think it's fair to primarily focus on long-term pros and cons. (Although I'm not really seeing a long-term pro to the new editor.) Alsee (talk) 22:32, 18 January 2017 (UTC)
    • @Fram: I said primarily; I also use the wikitext editor so I'm as "affected" as anyone else. After seeing this I opted into the NWE beta and haven't experienced any appreciable slowness, making me think that this, like the very few edge cases where Parsoid previews aren't sufficient, isn't a hugely critical issue. We can't keep obstructing the WMF's efforts at improving our antiquated interface because the new versions have a few bugs. All new software has bugs. – Joe (talk) 09:23, 19 January 2017 (UTC)
• Support both, On point one, as a regular editor from developing countries the last thing I need is even slower download times. On point two, I'm mystified at the idea of a preview function that doesn't render the page as it would if you saved it. -- Euryalus (talk) 11:14, 18 January 2017 (UTC)
• Support both. Slower loading times are an issue for developing countries and mobile users who don't like the mobile interface (I know I'm not the only one). But having a preview that doesn't render the page exactly like it appears when saved (even if it is just a missing sidebar) is daft. As Alsee said, if it ain't broke, don't break it. There's no reason to eliminate the plain text editor; far from simplifying things, the proposal to ultimately eliminate it is a switch to a more resource hungry process for no real benefit. oknazevad (talk) 23:00, 18 January 2017 (UTC)
• Support both The optimism that allows programmers to ply their trade often leads them down strange paths, but none stranger than thinking these features should be imposed on everyone, with performance details on the todo list. Just save your edits for a true preview! That must be what was behind the fuss a couple of months back when someone dropped into WP:VPT to tell template/module writers they should not show extra error messages during preview. Johnuniq (talk) 23:04, 18 January 2017 (UTC)
• Support both per every single support listed here. I tried the new editor and did not enjoy it. If they do go ahead and bring the new wikitext editor out of beta, they must keep the old editor. — Gestrid (talk) 05:46, 19 January 2017 (UTC)
• Support both These sound like serious issues that need to be addressed. Change always makes me a bit uncomfortable, especially when there are problems. Also Support keeping old editor, as I think many editors would consider leaving if it was taken away, and we already have editor retention problems. Tamwin (talk) 05:50, 19 January 2017 (UTC)
• Support both per Euryalus. Ealdgyth - Talk 15:36, 19 January 2017 (UTC)
• Support both Don't fix what isn't broken: current editor working perfectly on my end. Psychotic Spartan 123 18:43, 19 January 2017 (UTC)
• Support both. Just tried it, clearly noticeable speed difference and the "preview" is unacceptable. Echoing BethNaught in that I do not want to see the current source editor (which is actually functional) to be removed. In what ways is the new source editor superior, other than "easy switching" (which is negated by the long load times of VE to start with) and the toolbar (whether that is even superior to the current setup is debatable)? This is a sham referendum, not that I expect any better from the WMF. feminist 09:38, 31 January 2017 (UTC)
• Support both. And under no circumstances should the existing source editor be removed. Peter coxhead (talk) 09:53, 31 January 2017 (UTC)
• Support both. Offer it as an option, but don't try to impose it on everyone, especially not with increased load times and preview that doesn't preview. SarahSV ^(talk) 15:58, 31 January 2017 (UTC)
• Support both and do not remove the existing editor. ThePlatypusofDoom (talk) 18:20, 31 January 2017 (UTC)
• Support both I support anything that obstructs WMF. Chris Troutman (talk) 20:19, 31 January 2017 (UTC)
• Support both per above. The current wikitext editor is not broken. -FASTILY 22:16, 31 January 2017 (UTC)
• Support both for all the reasons given, plus.
  • Previews are necessary: Opabinia regalis said

    I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf).

    I don't know what you use previews for, O. regalis, but a large part of their value for me is spotting errors of execution as well as errors of intention. For example, last night on my mobile I added a rather complex "cite" ref, incorporating a template call as the last item. When I tapped Next for the preview, I got an "unclosed reference" error (or whatever the wording is). It turned out that in the steps of constructing the ref, which involves a good bit more moving around on a smartphone than on a computer, instead of inserting the double double curly closing braces at the end (}}}}) I'd lost track and only inserted one pair (}}), and as a result the "</ref>" and everything after it got swallowed up as part of the citation. This is not "doing something pathological that caused the renderer to barf" in the apparently snarky way you used it. This is called "checking your work", and we all should be doing it regularly.

  • Loading time. If you think it's slow on a computer, be glad you're not using a mobile. I get fairly frequent browser crashes, and I'm sure some of them are due to timeouts.

  --Thnidu (talk) 00:10, 2 February 2017 (UTC)

• Support both. If WMF really does adopt the concept of project-by-project blockers, I would welcome that improvement. Here, I think both issues are meaningful, and I see no reason to implement anything that has significant problems. Most of us are here to edit an encyclopedia, not to beta-test software that does not even address the issues that we care about. --Tryptofish (talk) 00:03, 3 February 2017 (UTC)
• Support both – It is supposed to be an upgrade, not a downgrade. And what is going to happen to WikEd? The Transhumanist 19:53, 6 February 2017 (UTC)
• Support load time as a blocker. I can live with the bad previews, but the slow load times will actually limit my editing activity. I frequently edit from countries where internet access is quite slow and having to wait more than a minute to edit a page isn't workable for me. I'm sure other people with slow internet access feel similarly. Kaldari (talk) 01:57, 12 February 2017 (UTC)

• Strong oppose, we should keep ONE editing mode and ONE reading mode. On other Wikipedias have I noticed that it's possible to wright directly in to the text. This

1. causes confusion
2. the "direkt wrighting" will attract pure vandals
3. there is no obvious benefit, with a new way of editing Wikipedia

Boeing720 (talk) 02:21, 14 February 2017 (UTC)

Note: Boeing720 explained[4] that they were attempting to oppose VisualEditor on EnWiki. Visual Editor is already here. This proposal is about a change to the wikicode editor. Boeing720, you may want to strike or revise your !vote here. Alsee (talk) 09:52, 21 February 2017 (UTC)

Alsee is 100% correct, like anyone who reads my explanation will understand. I made a huge mistake by turning the proposal. I Strongly support both. Sorry for the confusion I may have caused. Boeing720 (talk) 10:11, 21 February 2017 (UTC)

• Strongest possible support on the load time. Long load times make editing a chore, so quick fixes of simple errors are likely to be left alone. Editing in general will be discouraged. Support on the rendering. VisEd still can't render links properly? After all this time, that is totally sad. SpinningSpark 19:42, 18 February 2017 (UTC)
• Support on load times. I have just come back from the Phillipines. It was nearly impossible to edit even with the faster load times of the wikitext editor. If the only option becomes an even longer load times less of the world is going to be able to contribute. Also there is no "color coding". The color coding of WikEd is essential. The cite tool still adds unneeded urls when the pmid is give (this too needs fixing) Doc James (talk · contribs · email) 16:12, 20 February 2017 (UTC)
• The New Visual Editor =should replace the old Visual Editor, not the old wikicode editor. --NaBUru38 (talk) 13:04, 19 March 2017 (UTC)

Discussion

• Does anyone else think the current pasting behavior is weird, too? Whenever I copy a part of a page title and paste it, I want to get the text that I copied, not some empty bulleted lists and other wikitext cruft. Enterprisey (talk!) 03:03, 17 January 2017 (UTC)

  There's at least one currently open task for that. --Izno (talk) 13:50, 17 January 2017 (UTC)

  Enterprisey, the WMF is aware of the copy-paste issue. They'll address it. The ability to paste something like a fully formatted table could be really nice in some rare cases, but plaintext is what we want in nearly 100% of cases. Right now they are leaning towards the idea that a single line copy would be plaintext paste, and a multi-line copy would be markup-code paste. (I think that's probably the wrong fix, but I didn't comment on that.) Another idea is that ctrl-V would always paste plaintext, and ctrl-shift-V would always paste markup-code. (That's probably the better fix, but it would be hard to discover that ctrl-shift-V even exists.) The WMF will happily give us whatever we want. Alsee (talk) 14:52, 17 January 2017 (UTC)

  • Noo! @Alsee:, where did you see that conversation? That would be a terrible idea, having the worst of two worlds. Diego (talk) 16:24, 30 January 2017 (UTC)

• Once again, Alsee, you refer to a "large assortment" of rendering failures in the Parsoid previews, without providing a link or reference to help editors understand what you are talking about. With the exception of the fact that red links do not appear red (an obviously severe flaw that needs to be fixed), it seems to me that most of the issues that you are referring to are in fact obscure and rarely encountered. It would be helpful if you could link to or provide some examples of wikitext that does not preview as you expect. That way, editors can judge for themselves whether the problem is indeed as serious as you make it out to be. — This, that and the other (talk) 14:02, 17 January 2017 (UTC)

  This, that, I considered putting various examples in the RFC, but (1) I didn't want to bloat it up with a huge list, (2) the list that *I* happen to have compiled is an clearly an insignificant fraction of the issues that exist, and (3) I think the fundamental issue is broken previews, even if some of the cases are rare. I said in the RFC that the WMF is hoping to fix the common issues, and is aiming for 99+% accurate previews. If you think the exact list is important, then perhaps the WMF should compile a list. I'll happily contribute my pile of examples. Table of contents is missing. Redlinks, black links, external links, PDF links all show as plain blue links. Some links in the preview point to the wrong place... clicking them or opening-in-new-tab takes you to the wrong page. Markup on a link can completely break the link. Images can display in a completely wrong section (I haven't investigated why). Audio and video aren't included in the preview at all (they are replaced by a speaker-image). Oddly placed comments can break the preview. Some things that should be on one line are split onto multiple lines. Some elements - even entire paragraphs - can display in the wrong order. REFs can be missing from the reflist. I have multiple cases where it fails to render section-titles. Templating a template-name is is broken. Definition lists can render wrong. Some uses of elements like <code> <tt> and <s> can completely trash the preview. It can badly mangle table structure. Cases where stuff like <sub> doesn't get applied. Markup like #if can badly break if Parsiod doesn't like how it's arranged. And more. Some issues are related to Tidy, and the WMF is planning to remove Tidy, but so long as Tidy is part of the article view then Tidy must be part of the preview. And again, I'm sure the WMF can come up with far more examples than I have. And I'm sure that new examples will keep popping up. So let's consider the issue here as fix the endless render bugs that no one has listed yet, anywhere. In which case any particular list is irrelevant. Alsee (talk) 15:32, 17 January 2017 (UTC)

• I would also add that I forgot to switch off the VE before editing the above section... and for some reason was given the entire html of the page instead of the wikitext of just the section, <!DOCTYPE html><html prefix="dc: http://purl.org/dc/terms/ and all. I didn't dare click preview... ‑‑Yodin^T 00:34, 18 January 2017 (UTC)

  It's a problem I've been experiencing since the last software deploy. I believe that Parsoid is showing us the internals of the page (incorrectly). I would guess there's a phabricator task for this problem at this time but I haven't gone looking (nor have I reported one). It is well you did not save; I find that bypassing your cache fixes the problem. --Izno (talk) 01:10, 18 January 2017 (UTC)

  @Yodin: And I didn't see another task in Phabricator, so I've added one; tracked at phab:T155632. --Izno (talk) 15:26, 18 January 2017 (UTC)

• I tried the beta for this just now. I noticed the formatting issue when pasting text. That wasn't too bad but there was a major hiccup when I was using it to post an entry in a big RfC. There was an edit conflict and I chose the option to handle this manually. The resulting edit took an 86K bite out of the discussion. That was quite alarming so I reverted my edit immediately. I have stopped using the beta now as it's taking me too far out of my comfort zone when I want to get things done. Andrew D. (talk) 14:05, 18 January 2017 (UTC)

  @Andrew Davidson: This is tracked at phab:T154217. --Izno (talk) 15:14, 18 January 2017 (UTC)

• The Technical Collaboration Guideline is a document of guidance in communications that is in mid-draft and has nothing to do with this. It does not call for actionable blockers as framed here. Remove its mention, please. Keegan (WMF) (talk) 07:41, 19 January 2017 (UTC)

• Specifically, the very first line says "This is a recommendation for software projects following the Technical Collaboration Guideline (TCG)". No project is following the TCG since the thing is still being written. More importantly, the guideline is not a guideline in the sense of the word that the English Wikipedia knows, a form of directive. It's help, that's all. To the point: you can't put something under rules it doesn't qualify for, and that aren't rules to begin with. Remove its mention in the proposal. Keegan (WMF) (talk) 07:49, 19 January 2017 (UTC)

• Then consider this a Beta test of the TCG. A bit like we get from the WMF all kinds of software that is in mid-draft but which gets rolled out anyway... Fram (talk) 10:03, 19 January 2017 (UTC)

• No. Keegan (WMF) (talk) 18:26, 19 January 2017 (UTC)

Keegan (WMF), I have added a clarification on this issue. I hope you find it constructive and satisfactory. Alsee (talk) 20:29, 19 January 2017 (UTC)

I think the entire mention could have been taken out and the intent of the request is clear - I still think that's the better way to go, but meh. What I do not want is to see this as any sort of test or use of the TCG aside from "as an example." If that is your intent, that's fine. I'm working on building collaborative frameworks for the future years, and great harm can come from using them before everyone agrees and we're all ready. I hope you can appreciate that perspective. Keegan (WMF) (talk) 21:02, 19 January 2017 (UTC)

• This seems like a pretty pointless discussion, from a developer's perspective. Not sure what it is trying to accomplish. This feature is not being released yet, the feature is not bothering any of the people who are voting here, the previews will be aligned at some point in the next 1-2 years (mostly because maintaining 2 parsers is gonna be problematic), there is no plan to remove the current editor. If someone wants to be useful and constructive however, they could assist in some prototyping work, testing, design feedback etc etc. instead of nurturing your inner Statler and Waldorf. —TheDJ (talk • contribs) 01:49, 20 January 2017 (UTC)
  • "probably in mid-2017, we'll begin to provide it by default in place of the current wikitext editor"[5] If the WMF plans to roll out a new default editor in mid-2017, then early 2017 seems like the perfect time to discuss whether this really is fit to be the default editor, and which things surely need correcting before this can happen. The result of making this the default editor would be that new editors would encounter three editing environments instead of two (luckily we don't have Flow), as it has been shown here that there are circumstances where you always get the old wikitext editor, even if the new one would be the default. Sending out the message to the WMF that this is not acceptable is best done in time and not at the last minute (or even worse but rather typical, the WMF implements this, then a consensus emerges that we don't want it, the WMF refuses to roll it back because that would be too complicated or "confusing for new editors" or some similar excuse, and only after a long and bitter dispute does the WMF relent). This is a Beta, no one is arguing to end the availability as beta feature, but the stated plans by the WMF to roll out this out as the default in a few months time are simply premature. To dismiss this as "unconstructive" and "nurturing your inner grumpy old men" and adding the rather disingenious "this feature is not being released yet" (no, but it would be very stupid to wait with this discussion until it is released, wouldn't it?) is typical "shut up" behaviour of WMF supporters and not helpful, constructive, or open-minded at all. You could instead take the comments made in this very discussion as "testing and design feedback" and be happy that people care and voice their opinions. Fram (talk) 08:29, 20 January 2017 (UTC)
  • This is design feedback. An editor with broken previews and atrocious load times is clearly inferior to what we have, and should not be deployed unless the issues are resolved. Your suggestion that no issues should be addressed until deploy phase is silly. A primary reason the WMF has been developing the Collaboration guideline is to avoid having these sorts of issues (and RFCs) pop up at the last minute, during deploy. The best time to address issues is as early as possible, preferably during concept and design phase. Unfortunately there was no project page or information available until after it was built. Alsee (talk) 13:11, 30 January 2017 (UTC)
• Comment - (sigh) I don't understand why there always seems to be so much effort going on in this project to create alternatives to things that already work fine. I hope this isn't where the money goes that is donated to Wikipedia, which I'm sure that the donators assume is used for maintaining servers and organizing the development of the encyclopedia. That said, load times of software under development are often high, because of bloat left in for testing purposes and emphasis on functionality over speed in early phases. We can only hope that sincere efforts at optimization take place before the deployment.—Anne Delong (talk) 12:40, 7 February 2017 (UTC)

Third blocker: undo no longer works?

• Apparently from every page, if I am at "View History" (instead of "read") and then press "edit", I get the old editor instead of the new one. Apparently a page must be completely loaded in read mode before the new wikitext editor can be used. This would also mean that something like UNDO would no longer work when the new wikitext editor would be the only available editor. This seems to me to be a major blocker as well. Can others reproduce this and confirm this technically? Fram (talk) 11:18, 18 January 2017 (UTC)

  You're mischaracterizing the WMF's plans re the new editor, so far as I'm aware. It is not that there will be no other way to do it, but that the wikitext editor which will be available when e.g. Javascript fails to load will be a simple and plain text field (rather than include the editor bar and other such items). That said, I have reproduced that error multiple times, though no discrete steps for it (I think it's just clicking the 'undo' button, but I could be wrong). --Izno (talk) 13:04, 18 January 2017 (UTC)

  As long as the old wikitext editor remains, undo should keep on working, if they start it by default anytime the new editor fails (instead of e.g. only allowing it for people who have turned off the new editor explicitly). What their promises to keep the wikitext editor around are worth is anyone's guess of course. And obviously that "read - edit" gives a different result than "view history - edit" is perhaps not a technical blocker, but is it indicative of the total lack of adequate testing at the WMF, the thing that already sinked so many of their pet projects. The things that get discussed here are not exceptional occurrences or edge cases, these are basic functionality and actions. Fram (talk) 13:49, 18 January 2017 (UTC)

  I agree that undo is a regression--and I think their intent to keep a basic text box form is pretty sound because we do need to provide some support for Javascript-less users. --Izno (talk) 15:08, 18 January 2017 (UTC)

  Having activated and desactivated the new wikitext editor beta a few times, I now have all kinds of problems. At the moment, the beta (new editor) is activated: on most articles, I only get the old editor, and on some pages (e.g. Sumathi Murthy) I can,'t edit at all. This page has now opened in the new editor though (I thought it only worked in mainspace and user space?). Further testing confirms that I now can edit pages in the Wikipedia space with the new editor, but not in main namespace. I think I can safely conclude that this thing is far from ready to become a non-beta feature, never mind the default wikitext editor. Fram (talk) 14:28, 18 January 2017 (UTC)

  That sounds more like your cache is wonky. You should consider clearing it. --Izno (talk) 15:08, 18 January 2017 (UTC)

  Izno, Fram, I've also had issues where it seems random which editor starts up, and where turning the new editor on or off in preferences doesn't seem to take effect, among other problems. Bypassing local cache with shift-reload does not fix the issue. If it's a cache issue, it seems to be the server cache. I've also had cases preview fail to work at all, returning server errors. I suspect it's related to Parsoid, as I was trying to preview an article which the WMF had listed as generating a Parsoid roundtrip semantic error in their automated testing. Alsee (talk) 23:21, 18 January 2017 (UTC) On second thought, it might have been an article that generated Parsoid timeout in the automated testing. Alsee (talk) 23:45, 18 January 2017 (UTC)

  @Alsee: Yes, there's a handful of tasks documenting issues related to the 'wrong editor' in Phabricator. With Fram however "activating and deactivating a few times", that's not going to go well, I should think, and I'm pretty sure I've seen advice regarding other "Beta"-tab projects to the effect of "try to avoid turning things off and on multiple times". --Izno (talk) 23:54, 18 January 2017 (UTC)

My biggest failure mode with VE is undo failing. If there is any cut & paste in my undo buffer, trying to undo that step often fails in an odd way, and I have to reconstruct my edits piecemeal. If that's what Fram is talking about, and it would apply to NWE editing, that seems like a major issue to me as well. Not as big a blocker as performance, but significant for complex edits. – SJ + 22:28, 19 March 2017 (UTC)

There is no plan to remove the old wikitext editor

I have seen comments now on multiple pages that say something like, "eventually the current wikitext editor would be removed completely" – with the implication that this is definitely planned and will happen soon.

If we use a typical definition of "plan" like a "list of steps with timing and resources, used to achieve an objective" (to quote the article), then there is no plan to remove any of the wikitext editors from any WMF site. It would be far more accurate to say that the Editing department (and anyone who's been around computing for more than a few years) has a reasonable expectation that none of the current software will be used a hundred years from now, or even a few decades from now. So, sure, it's technically true that "eventually the current wikitext editor would be removed completely": someday, it presumably will be. However, it's also technically true that "eventually" I'm going to die (as will all of us) – and AFAICT it's still an open question as to which of those events will happen first.

On the other hand, I believe that we are all going to outlive the old parsing system, which is what the second proposed blocker concerns. They are planning to remove the old (HTML4-based) parser and to use (HTML5-based) Parsoid for saving all pages, no matter which of the many editing tools you're using. This epic project will certainly not be finished during 2017, but when it is finally completed, the odd differences between the two parsers will simply disappear. (One example: should [<!-- Invisible -->[Text]] produce a normal wikilink or should it display all the characters on the page or should it display the brackets but not the invisible HTML comment?) 

If you are interested in this project, then I recommend that you join WP:WikiProject Check Wikipedia. The first major step in replacing the old parsing system is described at mw:Parsing/Replacing Tidy; basically, some typos in HTML codes (e.g., someone typing </br> rather than the correct <br>) will no longer be silently fixed. (NB: This initial set of disruptive changes would have to happen even if Parsoid didn't exist; the library is unmaintained and outdated.) Whatamidoing (WMF) (talk) 07:25, 19 January 2017 (UTC)

@Whatamidoing (WMF): When you say that Parsoid will be used to save all pages, do you mean that pages will be saved in Wikitext but rendered with Parsoid, or saved in Parsoid HTML and round-tripped to Wikitext for source editing? I hope the former, as the latter will inevitably cause dirty diffs, and if made retroactive will change historical Wikitext revisions. BethNaught (talk) 09:00, 19 January 2017 (UTC)

I mean that what we've called "the parser" for years (Parser.php and a string of other supporting pieces in that system) will be completely removed – gone, not used, completely unavailable, deleted from the servers, given a death certificate that lists bitrot as the primary cause of death, etc. If you use (for example) the oldest, Javascript-free wikitext editor to save a change today, the resulting wikitext revision is currently turned into HTML by the old parser so that a reader can read it. When (2018? 2020?) the switch to Parsoid-based rendering is completed, even if you use exactly the same editor, the resulting revision will be turned into HTML by Parsoid instead. This change should have no practical effect on most Wikipedians, although I suppose that people may someday wonder why "obvious typos" like </br> were overlooked in articles for years. The change will be retroactive in the specific sense that it will no longer be possible to use the old parsing system to render any pages, so if you go look at a revision from 2003, then you will see how Parsoid turns it into HTML5, rather than how the old parser turned it into HTML4. (This is not very different from what we have now, since "the old parser" has changed quite a lot during its existence, and there's currently no way for you to see the 2003 revision with the 2003 parser, either.)

Whether revisions should be saved in wikitext alone or simultaneously saved in both wikitext and HTML+RDFa was an open question the last time I heard anyone mention it, but not one that affects the editing experience. (The idea seemed to be that dual-format saving would increase disk use but might be faster to read.) A few years ago, the devs discussed someday saving pages in HTML+RDFa alone and then turning them back into wikitext whenever someone wanted to edit, but interest in that option was limited. Maybe it's something they should consider again in future decades, but I don't expect it to happen in the foreseeable future. Whatamidoing (WMF) (talk) 17:13, 19 January 2017 (UTC)

@Whatamidoing (WMF): If we switch both editors to use Parsoid, issue #2 will be moot (as you explained above), but it isn't clear to me that that is actually going to happen. Can you provide any clarification on that issue? i.e. is the Editing Team planning on switching the old Wikitext editor to use Parsoid? Personally, I haven't heard of any such plans. On issue #1, my understanding is that there is little possibility of further improving the load time of the new WikiText editor due to its architecture (since it has to load most of the VisualEditor code in order to function). Is that also your understanding? Has the Editing Team considered re-architecting it to address the load time concerns or is that not a realistic option? Kaldari (talk) 02:23, 12 February 2017 (UTC)

Hi, Kaldari: Replacing the old parser with a modern one (i.e., some modern one/not necessarily Parsoid) has been expected for some time (software is not eternal, bitrot is real, etc.), but I believe that the decision to replace it with Parsoid (i.e., a modern replacement that happens to be Parsoid) was officially taken last quarter. (That decision belongs to ArchCom and Parsing, not to the VisualEditor team.) There is some information on the plans at on mediawiki.org; IMO the more interesting and informative page is the one about the two-systems problem itself.

The VisualEditor team is not currently working on performance issues. It's being considered for the coming year, but I don't know what they'll decide yet. There are some resource constraints that make it a difficult choice (e.g., inability to instantly clone certain members of Ops.  ;-) Whatamidoing (WMF) (talk) 18:40, 20 February 2017 (UTC)

Even if maintaining our "old" editor, have I experienced troubles at other Wikis, which uses more than one. All developments are not necessary good ones Boeing720 (talk) 00:52, 24 February 2017 (UTC)

A dozen different editing environments are officially supported on WMF wikis, and there are others that aren't officially supported (such as WP:WikEd). Whatamidoing (WMF) (talk) 21:44, 2 March 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Future of magic links

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Moved from WP:VPT

Magic links are being removed per the outcome of a Mediawiki RFC. What should we replace them with?

• Nothing
• Links ([[Special:BookSources/$1|$1]])
• Templates ({{ISBN|$1}})
• Parser functions ({{#ISBN:$1}}) [Requires Mediawiki changes]
• Interwiki links ([[ISBN:$1|$1]]) [Requires Mediawiki changes]

21:49, 5 February 2017 (UTC)

Um the widely unadvertised RFC. All the best: Rich Farmbrough, 23:54, 13 February 2017 (UTC).

Background

In the RfC meeting for the Future of magic links RfC, it was agreed upon to disable magic links for the MW 1.28 release by default and begin the deprecation for Wikimedia sites. MW 1.28 was released 2016-11-28. I proposed a bot to replace the magic link to templates. See: Wikipedia:Bots/Requests for approval/Yobot 27 -- Magioladitis (talk) 09:10, 3 February 2017 (UTC)

What meeting? All the best: Rich Farmbrough, 23:55, 13 February 2017 (UTC).

phab:E287. Anomie⚔ 13:53, 14 February 2017 (UTC)

@Xaosflux: to comment. -- Magioladitis (talk) 15:22, 3 February 2017 (UTC)

I'm not seeing where the English Wikipedia had this "RfC meeting for the Future of magic links RfC" please provide a link to the RfC closure here, if there was not a community discussion here then spin one up. — xaosflux ^Talk 15:35, 3 February 2017 (UTC)

@Xaosflux: This is a Mediawiki issue. It will affect all Wikipedias. See mw:Talk:Requests_for_comment/Future_of_magic_links. -- Magioladitis (talk) 15:44, 3 February 2017 (UTC)

And for the record, Wikipedia:Village pump (technical)/Archive 151#Tech News: 2016-46 said:

• Magic links might not work in the future. [6]

The linked post links the RfC. PrimeHunter (talk) 16:59, 3 February 2017 (UTC)

@PrimeHunter: mw:Requests_for_comment/Future_of_magic_links#Problem links to the discussion to turn this off on the software, it does not show support for which (or even IF) local communities replace it with something else. — xaosflux ^Talk 17:06, 3 February 2017 (UTC)

Sure, I just pointed out we had been informed about the discussion to turn it off. mw:Requests for comment/Future of magic links links to phab:T145604 where the RfC meeting is mentioned. What local communities do (if anything) is something to be discussed locally. I assume Special:BookSources will still be there if we want to add a link to it. Wikipedia:Bots/Requests for approval/Yobot 27 was denied so this section is currently the only open discussion I know. If another exists or is opened then please post a link here. PrimeHunter (talk) 17:35, 3 February 2017 (UTC)

@MZMcBride: to comment on this. -- Magioladitis (talk) 15:49, 3 February 2017 (UTC)

I understand that if the magic link gets disabled it will just revert these to plan text. I'm also in general support that having these be linkable text is a good thing, and that mass conversions would need to be handled by a bot. What I'm not see is community support for which mechanism should the new enwiki standard for presenting ISBN values. It could be a template, or a parser function to be, or a combination - a pseudonamespace, etc. It could be one of thees, supported by another one a is traditional for a module in a template. I don't have any strong preference for which one to use - just that it has widespread support. — xaosflux ^Talk 15:51, 3 February 2017 (UTC)

I'd agree with this. Replacement of the magic links in general with something else is probably not something we get to decide on, what the "something else" is on the other hand... Jo-Jo Eumerus (talk, contributions) 16:18, 3 February 2017 (UTC)

Discussion on how / if to replace magic links

My vote is using a template. It's consistent with how we treat other citations already and it allows page-level tracking of usage. We now have Template:ISBN and it's been working fine in live articles. Assuming that MediaWiki will no longer support magic links, does anyone object to using templates for their replacement? --MZMcBride (talk) 21:43, 4 February 2017 (UTC)

I don't. -- Magioladitis (talk) 23:27, 4 February 2017 (UTC)

Agree with replacing with templates. Keith D (talk) 23:52, 4 February 2017 (UTC)

Ditto, for each magic link. Jo-Jo Eumerus (talk, contributions) 16:16, 5 February 2017 (UTC)

• Support Seems like a sensible idea, as Jo-Jo says, it should be the same for each of those magic links. Regards SoWhy 16:27, 5 February 2017 (UTC)
• Support. We should also have a bot convert all future instances to {{}} format. I really wish this discussion had been better advertised, entering these things on mobile phone is going to be a big added nuisance. Daß Wölf 16:30, 5 February 2017 (UTC)

  Coming back to this, I support the use of a template now that the deed has been done. However, I would be absolutely in favor of going back to using magic links if that's possible. Daß Wölf 02:25, 17 February 2017 (UTC)

• Support conversion to {{ISBN}} and {{PMID}}, which provide error-checking that magic links do not currently provide. RFCs might need semi-automated conversion; I have read comments that some editors write something like "RFC 1048" but do not want that to actually link to https://tools.ietf.org/html/rfc1048. – Jonesey95 (talk) 22:37, 5 February 2017 (UTC)
  • Currently, if editors don't want magic linking of RFC links, I would expect they would use <nowiki> tags to suppress the links (e.g. RFC 1048). As long as the bots doing the replacements don't replace any text inside nowiki tags, I imagine this would work.Harryboyles 04:35, 11 February 2017 (UTC)
• Support magic links are annoying, produce an unexpected result, and inconsistent with how we actually want them to be. Replace them with a template.Headbomb {talk / contribs / physics / books} 22:43, 5 February 2017 (UTC)
• Support template for both ISBN/PMID. -- Magioladitis (talk) 23:19, 5 February 2017 (UTC)
• Support {{ISBN}} and {{PMID}} --S Philbrick(Talk) 18:27, 6 February 2017 (UTC)
• Support the use of the template, but request widespread explanation of it. Some editors never use any formats for inline citations or bibliography lists now (e.g., Jane Austen article), and now they will need to learn a template. If a bot makes the change for existing reliance on the "magic link", perhaps it should be in existence for more than a one time use. --Prairieplant (talk) 20:46, 6 February 2017 (UTC)
• Support use of {{ISBN}}, and a bot to go through and add the template to all existing ISBNs outside citation templates. PamD 22:45, 6 February 2017 (UTC)
• Support template solution as most intuitive and consistent. If a bot can switch all the bulbs, all the better. -- Elmidae (talk · contribs) 17:06, 7 February 2017 (UTC)
• Support templates. It's simple and consistent with almost everything else. The others are range from gross to vile. Alsee (talk) 22:13, 8 February 2017 (UTC)
• Comment: Should this discussion be linked from Template:Centralized discussion? The outcome of this discussion will affect at least 370,000 pages. – Jonesey95 (talk) 01:10, 10 February 2017 (UTC)
• Oppose at least for ISBN and ISSN. Why do we want to make Wikipedia harder to edit, instead of easier? All the best: Rich Farmbrough, 23:43, 13 February 2017 (UTC).
  
  • @Rich: This discussion is about how to replace magic links, not whether to replace magic links. Moreover, removing magic links at the MediaWiki level removes a headache in updating the wikitext parser(s), and therefore in updating VisualEditor and similar tools that ostensibly make it easier to edit Wikipedia. {{Nihiltres |talk |edits}} 16:27, 2 March 2017 (UTC)
    • Maybe, but that begs the question of whether we should. This has been proposed on an obscure page on an obscure wiki, and supported by an atypical collection of editors, from a point of view of information purism, and being unable to code what looks like some trivial internationalisation extensions. Purism is inappropriate for Wikipedia. The attitude that "we cannot make this work for Arabic, so we refuse to allow it for English" - is also indefensible. The money that the Foundation has poured into supporting internationalisation should enable this fairly trivial function to work in LtoR, RtoL and boustrophedon. All the best: Rich Farmbrough, 19:51, 2 March 2017 (UTC).
      
• Support templates for all the disappearing magic links. It's most consistent with what editors will expect from other contexts, such as {{Imdb}}. Definitely a job for a bot. Cabayi (talk) 09:24, 23 February 2017 (UTC)
• Support templates for everything currently handled by magic links, and by extension the creation of a bot to automatically wrap new instances of those non-magical links in an appropriate template. {{Nihiltres |talk |edits}} 16:27, 2 March 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Backlog of unpatrolled files

Request an autopatrolled group specific to files

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

File patrolling was technically introduced almost a year ago (phab:T11501). The backlog of unpatrolled files, visible at Special:NewFiles, is very significant. Autopatrolled users have their files automatically patrolled, but there are many users who are trusted to upload files that do not meet the requirements for autopatrol (which is concerned with new articles, not files). Thus I suggest we request a new usergroup, "File autopatrolled", with a single userrright (to be created): autopatrol-upload that autopatrols upload of the user. This way, we'll cut down a lot on the new files to patrol. Cenarium (talk) 18:36, 10 February 2017 (UTC)

• Support. Seems like a good idea. I don't think (article-)autopatrolled users should necessarily have their files autopatrolled either, since WP:PERM/A doesn't do anything to check that the editor is au fait with licensing policies etc. – Joe (talk) 15:52, 11 February 2017 (UTC)

Indeed these are very separate areas, in fact one would need separate userrights for patrolling uploads too, which should probably be bundled with the file mover usergroup. Cenarium (talk) 17:29, 11 February 2017 (UTC)

I can see the benefit of this in principle but there may be a difficulty in assessing a user's uploading experience. Files uploaded here may be transferred to Commons (sometimes wrongly leading to deletion there). Also, files uploaded here with a NFUR or with copyright outside the US are transferred to Commons when they fall out of copyright. Can an admin see the files I uploaded which were transferred to Commons on 14 January 2017? For example File:Boating in St Kilda, J Norman Heathcote, 1900.jpg. Thincat (talk) 18:17, 11 February 2017 (UTC)

Yes, admins can see it - both the 2 image versions and all the versions of the text from the page. עוד מישהו Od Mishehu 18:28, 11 February 2017 (UTC)

Oh, well, in that case I am in favour, supposing the standard of approval is appropriate. (BTW I think the article autopatrolled criterion is too high I see the level has sensibly been reduced.). Thincat (talk) 18:32, 11 February 2017 (UTC)

• Support and remove file auto patrolled from the normal auto patrolled per Joe Roe. -- Iazyges Consermonor Opus meum 13:08, 13 February 2017 (UTC)
• Support - Nifty idea and potentially good in practice. Criteria to obtain this permission may be needed, nevertheless. I don't know what the standards should be, but the criteria would be related to copyright and fair use. I don't know how many people would meet the criteria; the number would be the same as that of template editors or as high as the number of PC reviewers. George Ho (talk) 06:24, 14 February 2017 (UTC)

@Cenarium: May I add this discussion to "Centralized discussion" list? George Ho (talk) 19:49, 14 February 2017 (UTC)

• Support - writing good articles and properly tagging uploaded images are two totally different skillsets and should not be bundled. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)
• Support fully. ~ Rob₁₃^Talk 04:23, 20 February 2017 (UTC)
• Support: Helps reduce backlog of unpatrolled files. KGirlTrucker81 ^{huh? what I've been doing} 16:47, 24 February 2017 (UTC)
• Support - Image copyright is a little trickier than print copyright (even allowing for some of the excesses and dubious interpretations of some extremist patrollers), but it should be simple enough to separate the sheep from the goats with respect to file uploading so that the goats can be more carefully minded. Carrite (talk) 21:13, 24 February 2017 (UTC)
• Support Would make patrol status more meaningful. --AntiCompositeNumber (Leave a message) 23:09, 26 February 2017 (UTC)
• Support – No reason not to. J947 18:28, 27 February 2017 (UTC)
• Support, with the understanding that users will only get this right if they show an understanding in image patroll. עוד מישהו Od Mishehu 12:29, 5 March 2017 (UTC)
• Support splitting the current autopatrol right into autopatrol-upload and autopatrol-page (and having them separate permissions on enwiki). For other wikis which have just one autopatrolled group and want it to have the ability to do both, the two rights can just be added to it. If this comes up for a consensus check later I also support giving the autopatrol-upload right to file movers on the understanding that they are already experienced in this area. Callanecc (talk • contribs • logs) 06:02, 8 March 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@Jo-Jo Eumerus: Did you create a ticket for this? — Train2104 (t • c) 18:49, 22 March 2017 (UTC)

No. Jo-Jo Eumerus (talk, contributions) 19:08, 22 March 2017 (UTC)

Tracked in Phabricator
Task T161215

@Jo-Jo Eumerus: Done. First time I've done this, so hope I didn't screw up somewhere. — Train2104 (t • c) 13:37, 23 March 2017 (UTC)

Rename "File mover" usergroup to "File handler" and grant ability to patrol files (only)

Also to deal with the backlog of unpatrolled files. Patrolling files and patrolling new articles requires completely different abilities, editors with the file mover usergroup are knowledgeable about files and should be allowed to patrol files even if they aren't new page patrollers, and vice versa new page patrollers weren't vetted to patrol files. Hence I suggest to Nikkimariarename the file mover usergroup to file handler and grant them the ability to patrol files, while new pages patrollers would no longer be able to patrol files. Cenarium (talk) 21:18, 11 February 2017 (UTC)

I think this is getting too complicated - if someone just wants to patrol files, let them? The existing group can be used for that - if they are making bad patrols, it can be removed. — xaosflux ^Talk 13:05, 13 February 2017 (UTC)

I suppose this may make sense, but would users be given a newsletter and asked if they wish to get the new rights immediately, much like the grandfathering of the NPP rights? Because if not a massive backlog could ensue. -- Iazyges Consermonor Opus meum 13:10, 13 February 2017 (UTC)

Why not having two separate rights? Renaming a file is enough. Changing to "handler" would make things more complicated. Also, "file handler" is a little too new and needs to be practiced more. George Ho (talk) 21:07, 13 February 2017 (UTC)

We don't bundle page mover and new page patrol, so there's precedent for making them separate. But part of me says we're unbundling a bit too much. The suggested "file patrol" and the above "file autopatrolled" should be one right. Unlike article patrol where one can be good at identifying good articles/cleanup tagging but not that good at writing content from scratch, someone familiar with the file licensing polices should be easily able to apply them to their own uploads. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)

Echoing Xaosflux: Users who wish to patrol pages and demonstrate and understanding of what constitutes an appropriate page should be granted the new page reviewer user right. The right can be removed if they demonstrate a pattern of marking inappropriate pages as patrolled. — Godsy ^(TALK_CONT) 05:56, 25 February 2017 (UTC)

• Oppose rename, simply for the reason that this seems to be a Mediawiki thing, so the developers might have to do a bit of work just to do the renaming. I see no reason to disagree with the idea of allowing filemovers the ability to patrol files. Nyttend (talk) 00:20, 11 March 2017 (UTC)

RfC: Deprecate terms "edit history" and "revision history"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should the terms "edit history" and "revision history" be deprecated in favor of "page history"? ―Mandruss ☎ 22:37, 28 February 2017 (UTC)

If a Yes consensus is reached, occurrences of "edit history" and "revision history" would be replaced by "page history". This would begin with what are arguably the most visible occurrences, the links "revision history statistics" and "revision history search" on the page history page itself, and the "Revision history" in its heading. At Help:Page history, the sentence "A page history is sometimes called revision history or edit history." would change to "(The alternative terms 'revision history' and 'edit history' are deprecated.)" Other occurrences would be replaced as editors run across them, citing this consensus. ―Mandruss ☎ 22:37, 28 February 2017 (UTC)

Survey: Deprecate "edit history" and "revision history"

• Yes - I see absolutely no benefit to having multiple names for the same thing. Meanwhile, there is a downside in that new editors have to learn that the various names refer to the same thing. This is a good example of widepsread unjustifiable complexity that, collectively, serves as a barrier to entry. ―Mandruss ☎ 22:37, 28 February 2017 (UTC)
• request clarification Are we talking about changing links in policies and so forth or are we talking about what editors choose to call it, because those are two very different conversations. Beeblebrox (talk) 22:48, 28 February 2017 (UTC)

  Request clarification of your request for clarification. If you're asking whether it's about changing existing or future occurrences within editor comments in talk spaces, the answer is no. Communication is improved when we agree on the names of things, but we don't go around changing editor comments from "edit comment" to "edit summary", "intro" to "lead" or "lede", and so on. Rather, it's about non-talk occurrences in the WP and Help spaces, etc., and infrastructure software such as the page history display. We can't make the horses drink, but we can lead them to the water. ―Mandruss ☎ 22:52, 28 February 2017 (UTC)

• Yes makes sense. -- Iazyges Consermonor Opus meum 01:43, 1 March 2017 (UTC)
• No, because the different terms are used in different contexts. When we're talking largely about the page itself, editors tend to say "page history". When we're talking about specific diffs, editors tend to say "edit history". When we're talking about specific revisions (but not necessarily which individual edit led to them), editors tend to say "revision history". The terms "page", "edit", and "revision" are distinct and editors have to learn them anyway. Any editor who struggles to understand what "page history", "edit history", and "revision history" means after knowing those three terms must not know what a "history" is, and that's something we're not going to be able to fix. This is a solution in search of a problem, and it actually has a small chance of causing harm. Removing the alternative terms that have different contexts from all documentation will just make discussions held in those different contexts more difficult to understand. ~ Rob₁₃^Talk 08:27, 1 March 2017 (UTC)

Yes. As the OP poinyted out, we won't erase the terms from Help:Page history, and this will keep all current discussions consistant with the way major features of the software are refered to - this will make things easier for newcomers. Note that no automation should be used to fix anything here - each change needs to be reviewed by a human being (an admin inthe case of MediaWiki: namespace pages). עוד מישהו Od Mishehu 09:18, 1 March 2017 (UTC)

@Od Mishehu: "Current discussion" will be unaffected, just documentation pages. We obviously cannot ban editors from using the alternative phrases which are more descriptive in specific contexts. ~ Rob₁₃^Talk 09:20, 1 March 2017 (UTC)

Yes, but as we move towards the new terminology, the depricated ones will gradually fade out of use in discussions. We son;t ban editors from talking about the "Abuse Filter", yet I haven't seen anyone calling itby that name. עוד מישהו Od Mishehu 09:21, 1 March 2017 (UTC)

• No Outside technical and emergency contexts, there is no need for perfect consistency in language, especially in English. If I ask you for a pop from your ice chest, and you go and grab a soda from your fridge, we both know what I was asking for and effective communication happened. I see no evidence that effective communication is hampered by these terms. There isn't any real problem in referring to page history versus edit history versus revision history. They all refer to the record of past edits that revised the way a page displayed, and they all communicate effectively. We shouldn't try too hard to impose order on a usage area that will likely defy order. Eggishorn (talk) (contrib) 16:48, 1 March 2017 (UTC)
• No per there being no real reason to change. Not confusing and it doesn't hurt anything. Eggishorn also has a great explanation for why it doesn't matter. Just because it doesn't appear to hurt anything to change it doesn't mean we should do it. There should be a positive reason for the change, which I don't see here. TonyBallioni (talk) 14:37, 2 March 2017 (UTC)
• no. I too can see no reason for this, no benefit it will bring to the encyclopaedia, just a bunch of unnecessary edits and potentially a number of disputes as editors unaware or disagreeing with this proposal revert the changes.--JohnBlackburne^words_deeds 15:39, 2 March 2017 (UTC)
• No English has multiple different terms that mean essentially the same thing. Since the terms aren't confusing or misleading there's no real benefit to standardising on one, and trying to enforce a single term would only antagonise people. Hut 8.5 18:46, 2 March 2017 (UTC)

  There is no proposal to "enforce" anything. Also see today's further discussion in the following section. ―Mandruss ☎ 04:12, 3 March 2017 (UTC)

• No Per WP:CREEP, we should always have a real problem that is solved by any changes, and I'm just not convinced there is a real problem here that would require a new rule to solve it. Beeblebrox (talk) 05:06, 3 March 2017 (UTC)

  There is no proposal for a new rule. CREEP does not apply since the proposal is to replace two words, revision history or edit history, with a different two words, page history, in contexts referring to the tool described at Help:Page history. Also see today's further discussion in the following section. Per WP:BLUDGEON, this will be my last attempt to get participants to expend a bit of effort to understand the relatively simple question presented in this RfC, as well as the rationale for support. ―Mandruss ☎ 05:10, 3 March 2017 (UTC)

• No a waste of time RFC. The terms edit history and revision history are much more explanatory, esp. when it comes to external usage - by non-wikipedians. "Page history" is too vague. 103.6.159.75 (talk) 16:11, 16 March 2017 (UTC)

Discussion: Deprecate "edit history" and "revision history"

I don't want to vote yet, but I mean it sounds reasonable. Is there any any "against" argument? Herostratus (talk) 23:18, 28 February 2017 (UTC)

@Herostratus: Well, page history could refer to the history of things like deletion logs and such. I would value a single term for edit history/revision history, possibly just use one or the other? RileyBugz^{Yell at me} | _Edits 23:50, 28 February 2017 (UTC)

If I see significant support for a "choose the term or leave status quo" RfC, I will withdraw this and restart, pinging any prior participants. ―Mandruss ☎ 23:56, 28 February 2017 (UTC)

• My only concern would be if the use of edit history to refer to a users past edits accidentally get changed upon implementation, but that's unlikely to be a problem. -- Iazyges Consermonor Opus meum 01:43, 1 March 2017 (UTC)

  Right, none of this would be automated and I think human intelligence and BRD would prevent such a problem. ―Mandruss ☎ 01:46, 1 March 2017 (UTC)

I have generated a list of likely pages to look over for the term "revision history" - see here. The similar search for "edit history" has too many false positives to use this way. עוד מישהו Od Mishehu 09:24, 1 March 2017 (UTC)

A lot of the opposition is that there is no confusion. I fully understand that there is no confusion to us, after we have learned that they refer to the same thing. In my opinion experienced editors should put ourselves in the position of the newbie; this is about entry after all. Does anyone dispute that it does take longer to learn three synonyms than a single term? It doesn't take a lot longer, but combined with the numerous other such situations the learning curve is significantly longer than necessary. Does anyone not find it intuitively obvious that many newbies, especially those not coming from technical backgrounds, must be overwhelmed by the complexity of this environment?
The only way to address this is one nit at a time. The principle is that simpler is better, and the proper question is: What harm would be done by this small simplification?
The effort required to implement is miniscule; except for the trivial software changes (you don't have to do elaborate regression testing of a change to a few words on a generated page), I would do most of it myself. ―Mandruss ☎ 03:41, 3 March 2017 (UTC)

Counter-argument: Od Mishehu's comment above about "too many" false positives for a simple search on "edit history". In truth, it is not likely simple on a technical level, and certainly not simple on a behavioral level. Editors will continue to call and name these pages whatever they wish and banging them over the head with yet another stylistic preference is policy creep. Eggishorn (talk) (contrib) 04:00, 3 March 2017 (UTC)

(edit conflict) The question also shouldn't be What harm would be done by this small simplification? but Why should we do this? I haven't heard a good case for why we should do it. TonyBallioni (talk) 04:03, 3 March 2017 (UTC)

Changing the words used by Wikipedia is hardly banging anybody over any heads. I'm not proposing a warning template here. Hyperbole is not helpful to the debate or one's own thinking.
I think it's abundantly clear that editors would not be forced to use the "official" term any more than they are forced to use any other "official" terms. I merely assert that it makes sense to have one "official" term for each "thing". Some editors call the lead/lede the "intro", but does that mean we should rename Wikipedia:Manual of Style/Lead section to Wikipedia:Manual of Style/Lead or intro section? I think not. Does it mean we should call it lead/lede in some places and "intro" in others? I think not. Communication would be enhanced if everybody called it lead/lede, but we don't actively correct the editors who call it "intro". We simply hope that, at some point in their development as an editor, it will occur to them that Wikipedia calls it lead/lede and they will start calling it that instead. No head-banging.
I've made the best case I know how, but if I fail to convince a majority, I certainly know how to lose. I do ask that participants refrain from misconstruing the proposal, as that undermines any decision-making process. I've seen little evidence that closers take the time necessary to discount such !votes. ―Mandruss ☎ 04:09, 3 March 2017 (UTC)

Yes, yes. Disagree with your case, but wasn't trying to suggest you don't know how to lose. Sorry if the tone came off that way. Text being an imperfect means of communication :) TonyBallioni (talk) 04:12, 3 March 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:WikiProject Council/Proposals/Wiki Brain

Moved to Wikipedia:Village pump (idea lab) § Wikipedia:WikiProject Council/Proposals/Wiki Brain

 – Way too vague for this page. Needs incubation. ―Mandruss ☎ 09:52, 23 March 2017 (UTC)

Now at Wikipedia:Village pump (idea lab)#Intelligent Wikipedia that talks to you interactively ―Mandruss ☎ 23:12, 29 March 2017 (UTC)

Proposal - non-requested automated messages on talk pages must be short

As more bots edit Wikipedia more often, I think we should be mindful of the ways that interacting with bots can take time away from human engagement in Wikipedia. As a general rule, messages from bots, especially if they are routine and posted 100,000+ times, should be short so as to minimize the amount of human time and attention that they capture. The time of Wikipedia editors is valuable and any small grab for time multiplied by 100,000 has a big impact. I wish to propose a general rule that could be expanded if there is community support.

• Non-requested, mass-posted, automated messages on talk pages must be short.

Details can be sorted, but I mean that a message written by a bot and designed to capture the attention of thousands of users should be not more than about a sentence long.

Example case

InternetArchiveBot is operated by Cyberpower678 place dead external links with links to backup copies of the source at the Internet Archive. The bot and project are funded by a partnership between the Wikimedia Foundation and the Internet Archive to do tasks as described at meta:Community Tech/Migrate dead external links to archives. The project was the top-ranked request in the meta:2015 Community Wishlist Survey. Everyone likes the project and I like it too.

The part that I think is excessive is posting comments like this on talk pages:

• archive of talk page

---

Hello fellow Wikipedians,

I have just modified 2 external links on Gorham's Cave. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080827194258/http://www.jscarrion.com/pdf/neandertals_nature.pdf to http://www.jscarrion.com/pdf/neandertals_nature.pdf
• Added archive https://web.archive.org/web/20121113153308/http://www.gibraltar.gov.gi/archives/press-releases-archives/2011/1526-2302011-government-announces-details-of-the-recent-lands-agreement-with-mod- to http://www.gibraltar.gov.gi/archives/press-releases-archives/2011/1526-2302011-government-announces-details-of-the-recent-lands-agreement-with-mod-

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:56, 23 March 2017 (UTC)

---

Here are some problems with this post:

1. It is long and capturing too much volunteer attention. Research in eye tracking is raising awareness of how much time arbitrary decisions in online diversions take away from meaningful ways for people to spend their time. If someone reads or even sees this post that could take 15 seconds to a minute of time. Multiple visitors to a talk page might read the post, as it is persistent indefinitely and at current archiving rates probably has an average life of ~5 years.
2. The post asks for "source checking", where a human manually checks what the bot does. If a human does this task, that could take 2-3 minutes.
3. This is my own estimate, but my guess is that the average time consumed per talk page post is 1 minute. I think every talk page post will be viewed at least once for 15 seconds, many will be viewed multiple times by multiple users over a period of years, and in some cases some users will complete the sourcecheck task. Overall, I think guessing that each post consumes 1 minute is a fair place to start the conversation. Arguably the average time cost is higher.
4. This bot has made 700,000+ edits and is going to make millions more. If it edits 100,000 talk pages, then it consumes 100,000 minutes of time, or 1600 hours or 66 days. Also, the time it is consuming is time from the kind of person who would visit a Wikipedia article talk page, so this is the time of Wikipedia users who are among the 1% most engaged and whose time is most valuable.
5. 100,000 minutes of time is too much time to give to this talk page post, when typically, the post needs no response at all. These posts represent one of the biggest content publishing pushes from a single project in Wikimedia history. Practically all Wikipedia editors who read talk pages are going to spend time reading these posts repeatedly for years, giving some amount of attention to them.
6. In 95% of cases there is no reason for anyone to interact with any of these posts. They do not contain information which is of interest to most talk page readers.
7. There is no plan in place to expire or remove these posts. Even if they are checked, they will continue to be read for years in the current plan design.
8. I am not aware of any discussion demonstrating mindfulness about how much editor time this bot is designed to consume.

To lessen the impact of the bot, I propose that its posts to talk pages be restricted. Perhaps restriction to one sentence is sufficient. Either it can say everything it needs to in one sentence, or otherwise, the one sentence can link to a more detailed log somewhere else for users to follow and read if they really want to spend their time engaging with this bot.

In the future, as a general rule, talk pages on Wikipedia should emphasize human to human interaction and work tasks posted to talk pages by bots should be minimally invasive.

I discussed this with Cyberpower678 at T161108 and they told me they wanted Wikipedia community consensus for change. I am asking now for support to reduce the bot's posting to one short sentence, like one of these -

1. "A link went down and the Internet Archive Wikipedia Link Archiving Project fixed it by replacing it with an archived copy. - Internet Archive Bot"
2. "A link went down and the Internet Archive Wikipedia Link Archiving Project fixed it as described on the archive log, which anyone may see. - Internet Archive Bot"

I do not want to detract from the archiving project, which is important, but this is a big enough issue on a well-funded enough project that I think we can cut back to a sentence as an immediately measure then have longer discussions about whether more should be added back, if there is any dispute about exactly what should be cut and what is necessary.

Thoughts from others?

---

Operator comment: The settings for the talk page messages are controlled here, and it's documentation can be seen here. As a side note, the one sentence proposal of Bluerasberry is not feasible with current design considering that there are more than one links being fixed in most edits. This is in regards to sentence 1. In regards to proposed sentence 2, there is no archive log.

Also, talk page messages are only left when archives have been added or modified, and they're there for users to quickly be able to click on and verify their functionality.—CYBERPOWER (Chat) 15:38, 23 March 2017 (UTC)

Cyberpower678 Can you comment on how feasible it seems to you that your current design process is likely to attract about 100,000 minutes of editor attention for every 100,000 talk page posts? Do you have a better guess for how much time your project is designed to consume? Blue Rasberry (talk) 16:07, 23 March 2017 (UTC)

A user does not have to read the notifications if they do not want to. The notifications simply is there as a means to quickly verify the bot's edit if they choose to. The talk page messages provides tools for user to appropriately correct any errors found. Users would typically only read it once, and would be able to quickly identify any new message and act accordingly. So your estimate is likely smaller than that. The talk page messages can be shut off entirely too. It's all controllable on the config page I linked to.

There are a lot of organizations which post messages to twitter and Facebook to collect something called an Impression (online media). This is a contemporary advertising theory, and there is research describing how much thought people put into the messages to which they are exposed. I expect that posts on Wikipedia get read at least as much as something in a typical person's subscribed feeds elsewhere. If a message on a talk page lasts for ~3 years and gets read by 10 people for 6 seconds each over that 3 year period, then that adds up to one minute. Which of my numbers seem off to you? Does 6 seconds each by 10 users over 3 years per post seem excessive? What number would you tweak? Did your project do any calculation or put any thought into this yourselves, to present your own time cost estimate? Suppose that I am off by 50% - does a cost of 50,000 minutes per 100,000 posts seem reasonable to you? Blue Rasberry (talk) 16:40, 23 March 2017 (UTC)

---

• Support minimal posts to talk pages by bots Blue Rasberry (talk) 14:25, 23 March 2017 (UTC)
• Comment - Better placed at WP:VPR unless you propose a change to some written Wikipedia policy. I didn't see such a proposal. Also seems of little value as a vague statement and should be framed as a proposal for change to the specific bot. ―Mandruss ☎ 14:38, 23 March 2017 (UTC)

Mandruss I just moved this from policy to "proposals". Blue Rasberry (talk) 15:13, 23 March 2017 (UTC)

• Oppose as a policy. However, address with any bot operators and during bot task requests as needed. Without defining "short" I see some regular talk messages that I don't consider "short" but don't think should be forbidden - examples: Suggest Bot suggestions, Tech News - and basically anything else that is opt-in. — xaosflux ^Talk 14:57, 23 March 2017 (UTC)

xaosflux Thanks for early feedback. I changed this to only refer to non-opt in posts which are targeted to at least thousands of readers and written by a bot. Blue Rasberry (talk) 15:13, 23 March 2017 (UTC)

• Weak Support Losing the many "walls of words" would be a relief, but I usually skip them anyway. That right there tells you the impact it has on me - I have trained myself to ignore these post whenevr possible. GenQuest ^{"Talk to Me"} 15:24, 23 March 2017 (UTC)
• Oppose as effectively unenforceable. How long is too long? are we going to set a hard byte limit on bot talkpage notices? There are other problems, as well. There is already a mechanism in place for bot best practices, the BAG. The idea that a new, permanent, policy is needed because of notices posted by one bot that the community and the WMF agree is doing necessary work is policy creep. Lastly, and most importantly, talkpage reading is not mandatory and easily ignored. If this is really considered a problem, then institute archiving on the page and let Cluebot or lowercase sigmabot take care of it. There's a certin elegance in letting a bot clean up after a bot, afer all. Eggishorn (talk) (contrib) 16:59, 23 March 2017 (UTC)
• Oppose - if some specific bot is giving messages which are too long, discuss it as you would any other issue related to a bot's behavior not being up to your standards. This would mean starting with a discussion with the operator, and if you can't agree, moving on to more public discussion. No need to make this an explicit rule. עוד מישהו Od Mishehu 18:47, 23 March 2017 (UTC)
• Oppose - A good suggestion, but a poor requirement. Sometimes longer messages may be due. Also, "short" is vague. — Godsy ^(TALK_CONT) 20:25, 23 March 2017 (UTC)

@Xaosflux, Eggishorn, Od Mishehu, and Godsy: Can you say more about why you oppose? Would any of you feel comfortable saying that you disagree with any or all of these premises?

1. If 100,000 long messages are posted to 100,000 articles, then over the life of the message, about 100,000 volunteer minutes will be consumed in the process. This is a significant amount of time and volunteer attention.
2. Volunteer attention, measured in time, is poorly spent engaging with automated messages of the sort presented by Internet Archive Bot as compared to other Wikipedia activities which the Wikipedia community encourages by placing into focus on this scale.
3. Assuming that the messages are consuming large amounts of time, and assuming that the time consumption is a problem to address, then shortening the messages is a viable way to address the issue.

Which of these, if any, do you doubt? If you doubt all of them, then it would be useful feedback for me to hear that you think that what the IABot is doing is practice that the Wikimedia community should permit or encourage. Blue Rasberry (talk) 20:47, 23 March 2017 (UTC)

@Bluerasberry: My oppose was prior to the proposal being changed, I've stricken it for now - reason was that we should not restrict opt-in automated messages like in my exampled above to only be "small". — xaosflux ^Talk 22:28, 23 March 2017 (UTC)]

"Premise" #1 is a free-floating assertion with no evidence to back it up and supported by nothing more than assumed reading resources and back-of-the-envelope calculations. How are you deriving any of those numbers. Where is the data to believe that each message "consumes" volunteer minutes in anything like this amount? Premise #2 is a mere personal belief, again with no empirical data. Premise #3 is nothing more than a tautology. There is nothing in these premises to justify creating new rules. Here's a simpler solution: don't read the messages. Eggishorn (talk) (contrib) 23:04, 23 March 2017 (UTC)

I don't insist that all premises be "proven"; I think reason and intuition are enough in many cases. But reason and intuition tell me that most editors actually read the whole message once, if that. After that they recognize it at a glance and they already know what it says and what its purpose is. ―Mandruss ☎ 03:10, 24 March 2017 (UTC)

Personally, I usually don't either. If an editor tries to lay out their argument in terms of hypotheses and premises and suchlike, however, it is only natural for other editors to evaluate their arguments in similar terms. What I see in this set of premises is an editor raising their personal distaste to universal commonality, which is a really big leap in logic. Eggishorn (talk) (contrib) 15:36, 24 March 2017 (UTC)

Eggishorn You are correct - I used poor word choices and I did not communicate effectively. I wish that I could step outside this conversation and ask you somehow if you understood my intent, because I feel like I presented arguments that you are parsing as equations when actually I was trying to raise concern about a recurring social issue. Do you do video or phone chat? I will email you and ask. If you really are interested in this conversation, one point that you raise which I can address is a better calculation. The most solid number that I have is that 100,000+ messages are posted to talk pages. I hope that I could get you to agree with an assumption that these messages are viewed on average for not less than 1 second each, which is less than the 60 seconds which I imagined people like you would take as conservative. If the number is 1, and not 60, then the time cost is still 100,000 seconds or 27 hours. I would argue that this is not time well spent, and that we should not permit or encourage processes which are designed to consume time in this way even if it is in small pieces from many people. User experience is not enhanced by subjecting them to messages which are designed to not be read, and if these messages are designed to be read and actually are being read, then they are consuming even more time and for no apparent reason. The novelty in this case is that whatever the effect, it is multiplied by 100,000 and planned for 1,000,000+ messages. Despite my inability to articulate the cause and effect as a matter of logic, does any part of this strike you as unusual and worth examining as a matter of policy? Blue Rasberry (talk) 14:08, 28 March 2017 (UTC)

• Oppose Saying this is a must is excessive. The postings shouild be as short as is clear, sets the right tone, and motivates people in a suitable way. I don't see that there is much time wasted, as on most pages I see them, the messages are ignored by others. Not only that, talk pages get only a few reads. Perhaps some talk messages could be hatted or closed once dealt with, so that others don't repeat any effort requested. Graeme Bartlett (talk) 10:19, 24 March 2017 (UTC)
• Support As GenQuest stated above, i also tend to skip over these excessively large text walls; i've noticed many times the message given as the example at the beginning of this proposal, and as it's usually on pages i'm only visiting briefly, with no real interest in, i blur over the lines and move on; i'd be much happier to do that quickly ~ one or two lines-worth of quickly, rather than the dozen or more lines which are there. While the proposal as written does not define "short", i would think that any organisation such as the Internet Archive Wikipedia Link Archiving Project which is asking for help would see that a shorter, more definitive message would be better in terms of the help it generates. Speaking simply for myself, my definition of short would probably be no more than three lines and preferably less. Happy days, Lindsay^Hello 11:43, 29 March 2017 (UTC)
• Support Agree this is a best practice. One can than provide a link to further details. Doc James (talk · contribs · email) 18:23, 29 March 2017 (UTC)

Linking from Wikipedia to other wikis

Transferred from WP:AN. Nyttend (talk) 05:06, 24 March 2017 (UTC)

• There are external wikis that specialize about one subject or another. Examples are:
  • http://casualty.wikia.com/wiki/Casualty_Wiki (Casualty (TV series))
  • http://memory-alpha.wikia.com/wiki/Portal:Main (Star Trek)
  • http://pokemon.wikia.com/wiki/Pok%C3%A9mon_Wiki (Pokémon)
  • http://starwars.wikia.com/wiki/Main_Page (Star Wars)
  • http://gundam.wikia.com/wiki/The_Gundam_Wiki (Gundam)
  • http://manutd.wikia.com/wiki/Main_Page (Manchester United)
    • etc.
  • It would be useful if the main Wikipedia page about such a subject could be able to link to the specialized wiki about that subject, to let readers easily find the detailed in-world information about that subject, as within Wikipedia such information is liable to be deleted in a running edit war between inclusionists and exclusionists. For example, in the Pokémon field, some people think that in-world details about each Pokémon are specialized information but useful to some, and others think of it as "Pokécruft" and delete it. And mutatis mutandis for the other scenarios. If Wikipedia was allowed to link to those useful external wikis, that would give access to the full information for each scenario's fans without needing to clutter Wikipedia's server and without risk of it being deleted by exclusionists. But such links when put in, are often deleted. Please discuss this. Anthony Appleyard (talk) 23:26, 23 March 2017 (UTC)
• Admittedly, these wikis may vary in quality; for example the Manchester United wiki shows evidence of not enough routine checking to remove vandalism; access to these wikis may have to be decided separately for each wiki. Anthony Appleyard (talk) 23:36, 23 March 2017 (UTC)

  @Anthony Appleyard: You can link to these wikis, but only to the "good" ones per WP:ELNO#12. --Izno (talk) 00:00, 24 March 2017 (UTC)

  Why would we link to any unreliable fan sites (which these wikis all are). The only wikis we may occasionally link to are tightly controlled, supervised ones, not truly open wikis. Links to wikia (and similar ones) should be removed from every article but the wikia one (and other very rare exceptions where the wikia is e.g. the source of a notable controversy). Fram (talk) 09:26, 24 March 2017 (UTC)

  Your stance is not reflected in ELNO, so do not portray your stance as fact. We do routinely link to open wikis (some of which are at Wikia and others which are not) to provide additional information to the reader. (Or perhaps the word "open" to you means something other than "(most) anyone can edit"?) --Izno (talk) 14:05, 24 March 2017 (UTC)

• To me, the Casualty Wiki and the Star Trek Wiki at least, seem to be of good quality. It depends on how well each wikia is supervised by its administrators. It looks that each wikia will have to be judged separately to see if it can be listed as reliable. Anthony Appleyard (talk) 09:33, 24 March 2017 (UTC)
• WP:ELNO#12 says: "Except for a link to an official page of the article's subject, one should generally avoid providing external links to ... [o]pen wikis, except those with a substantial history of stability and a substantial number of editors. Mirrors or forks of Wikipedia should not be linked.". That is, more or less, "one can provide external links to open wikis which have a substantial history of stability and a substantial number of editors, (but not to mirrors or forks of Wikipedia). Anthony Appleyard (talk) 09:36, 24 March 2017 (UTC)
• Add: http://blakes7.wikia.com/wiki/Main_Page (Blake's 7)
• Add: https://www.festipedia.org.uk/wiki/Home_Page (Ffestiniog Railway)
• Anthony Appleyard (talk) 09:36, 24 March 2017 (UTC)
  • (edit conflict) I'm with Anthony and particularly Izno on this. I do think that such links need to be carefully marked though, perhaps a template such as {{wikisource}} but with suitable guarded wording. You'll see that other respectable websites like BBC news: Kent have a section of external links, indeed so do we on some articles. We maintain WP:NOTCENSORED internally, so why should we prohibit external links, provided there is a suitable warning about (1) no connection to WP, and (2) content unverifiable by WP. Martin of Sheffield (talk) 09:42, 24 March 2017 (UTC)
    • I am not opposing linking to external links, which is standard practice. An external link is only acceptable if it would also be acceptable as a reference or a primary source, but simply isn't used as such. The Blake's 7 wikia has had 5 articles edited the past month, 4 by IPs. I see no reason to add a link to such wikis. Fram (talk) 11:15, 24 March 2017 (UTC)

      I agree in the case of "Blake's" if those are the stats for activity. However, there are clearly wikis (Wowpedia, MemoryAlpha, MarvelDatabase, and Wookieepedia are perhaps the largest off-the-cuff) on the other end of the activity/stability spectrum which are clearly suitable for inclusion as external links here. --Izno (talk) 14:05, 24 March 2017 (UTC)

• Those are:-
  • http://wow.gamepedia.com/Portal:Main (World of Warcraft)
  • http://marvel.wikia.com/wiki/Marvel_Database (Marvel Comics and DC Comics)
  • http://macross.wikia.com/wiki/The_Macross_Wiki (Macross)
    • Anthony Appleyard (talk) 22:21, 24 March 2017 (UTC)

Magic link RFC follow up

As a follow up to Wikipedia:Village_pump_(proposals)#Future_of_magic_links, the following BRFAs have been made

• Wikipedia:Bots/Requests_for_approval/PrimeBOT_13
• Wikipedia:Bots/Requests for approval/CitationCleanerBot 2
• Wikipedia:Bots/Requests_for_approval/Yobot_54
• Wikipedia:Bots/Requests for approval/Magic links bot

On some of those at least, is the idea of converting non-magic word identifier instances either

• Only do magic word conversion (e.g. doi:10.1234/whatever, PMID 0123465 → doi:10.1234/whatever, PMID 123465)
• Alongside the magic word conversion (e.g. doi:10.1234/whatever, PMID 0123465 → doi:10.1234/whatever, PMID 123465)
• On their own (e.g. doi:10.1234/whatever → doi:10.1234/whatever)

As well as doing some standardization and cleanup (doi 10.1234/whatever → doi:10.1234/whatever)

This is not, however, a proposal to convert bare citations to templated citations, e.g.

• Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 doi:10.1234/whatever
  → {{cite journal |last=Smith |first=J. |year=2016 |title=Article |journal=Journal of Foo |volume=23 |issue=3 |pages=1–23 |doi=10.1234/whatever}}

only bare identifiers to templated identifiers, e.g.

• Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 doi:10.1234/whatever
  → Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 {{doi|10.1234/whatever}}

I can't think of any reason why the unlinked/untemplated version would be preferred over the linked/templated versions, but I figured I'd at least advertise these BRFAS. Headbomb {talk / contribs / physics / books} 14:09, 25 March 2017 (UTC)

This is a great task. -- Magioladitis (talk) 14:21, 25 March 2017 (UTC)

There needs to be a way for editors to opt-out of this if a particular circumstance requires it. The easiest way would be to put the content in "nowiki" tags, which should be enough to tell the bot that it is not intended to be linked. Can the bot recognize and respect that? — Carl (CBM · talk) 18:40, 26 March 2017 (UTC)

AWB has the option to "Ignore external/interwiki links, images, nowiki, math, and <!-- -->". I can't see why that wouldn't be enabled during such a run. Headbomb {t · c · p · b} 19:11, 26 March 2017 (UTC)

A proposed template for the draftspace

Hi,

Following early RfCs, I have made a proposal for the template that can be used to sort and classify pages in the draftspace (but not drafts in the user pages.) More participations are welcome and, well, needed at Wikipedia_talk:Drafts#RfC:_Draft_classifier_template. -- Taku (talk) 23:10, 25 March 2017 (UTC)

Ijabcd redirects for IJabcd articles

As you can see from IJ (digraph), many Dutch words are written with "IJ", both capitalised, as their initial letters. This looks odd to English-reading eyes, and if you remember how such a world is spelled (e.g. IJlst), you may forget to capitalise the J.

With this in mind, creation of "Ij" redirects seems like a good idea. Would it be desirable to request that a bot create an "Ij" redirect for every "IL" article? Nyttend (talk) 02:45, 26 March 2017 (UTC)

Is there some idea of how many there are? If there are only a few dozen programming a bot might not be worth it. A few hundred? Then yeah, a bot might be useful. --Majora (talk) 02:47, 26 March 2017 (UTC)

Once we scrap acronyms and the like (e.g. IJA 145th Division and IJCAI Award for Research Excellence), we're left with 70 titles, out of which 38 are articles, 30 are redirects, and 2 are irrelevant, IJustWantToBeCool and IJustine. So I guess you're right about doing these some other way. By the way, is there some custom way to cause Special:Allpages to exclude redirects, or is there some other special page that does the same thing as Allpages except without the redirects? If we'd had hundreds of pages, it would have taken an excessive amount of time to count all of them. Nyttend (talk) 03:11, 26 March 2017 (UTC)

How did you come up with 70? I just did a search for prefix:ij and then did a normal ctrl + f search for the word "Dutch" and came up with 29 articles. I don't think there is a way to eliminate redirects in Special:Allpages and the manual on searching is coming up empty as well. --Majora (talk) 03:22, 26 March 2017 (UTC)

Even better, search for Dutch in the entire article. Search for "Dutch prefix:ij" returns 37 articles. --Majora (talk) 03:27, 26 March 2017 (UTC)

I searched for titles beginning with IJ at Special:Allpages, deleted the ones that were acronyms and the like, and I was left with 70 titles. Probably 1 of the 38 is unrelated to Dutch and I made a mistake by including it. Nyttend (talk) 03:34, 26 March 2017 (UTC)

Whether it is 37 or 38 it would probably just be easier to do these manually. That isn't really enough to warrant making a bot, getting it approved, and running it. --Majora (talk) 04:00, 26 March 2017 (UTC)

I made an AWB request before leaving my last note here, and Certes fulfilled it a couple of hours ago. Nyttend (talk) 21:09, 26 March 2017 (UTC)

Should we also include titles with the word IJ rather than IJabcd (e.g. IJ (Amsterdam)) or containing IJabcd as a later word (Hoge vuurtoren van IJmuiden) or both (Brouwerij 't IJ)? Certes (talk) 23:12, 26 March 2017 (UTC)

Good point. The problem is that I don't know how to search for such pages; you won't find them easily with Special:Allpages of course, and if it's possible to get Special:Search to be case-sensitive (i.e. counting "Hoge vuurtoren van IJmuiden" but ignoring "Hoge vuurtoren van ijmuiden" if it existed), I don't know how. Judging by Help:Searching, if I searched for intitle:IJ and intitle:IJ*, I suppose it would give me all pages with "IJ" as a separate word and all pages beginning with IJ, but those might still have to be sorted by capitalisation status. Nyttend (talk) 23:31, 26 March 2017 (UTC)

Those articles are now done too, so that's probably the end of this job. Certes (talk) 12:28, 27 March 2017 (UTC)

Make the title of each column follow the scrolling in tables

Hi, I like to read statistics and I often find that with a large table with many columns and rows, I get lost while scrolling down. I think the first row of a table should 'magnetize' to the top of your screen and follow along as you read entries of the table that are lower. Often, the tables are incomplete and so, it is hard to follow along, remembering which row is which. It can be especially hard when the subject is a new one for the reader. Of course, this idea should be implemented in beta first to see if it works.

--Ṗḯƥỡȵẘẩ (talk) 00:56, 28 March 2017 (UTC)

I believe there is a phabricator task for this request. --Izno (talk) 02:14, 28 March 2017 (UTC)

I've been testing this lately in my personal CSS. It works quite well on sortable tables. For wiki tables, it's harder, since you need to guess where headers start and end, which is basically impossible (the JS of wiki tables has some pretty complicated logic to do that, which cannot be easily copied). It also only works on rather recent browsers. I'll turn it into a gadget. —TheDJ (talk • contribs) 11:18, 28 March 2017 (UTC)

@Piponwa:, @Izno: see the last gadget in the Testing and development section of Special:Preferences#mw-prefsection-gadgets. —TheDJ (talk • contribs) 11:24, 28 March 2017 (UTC)

@TheDJ: Doesn't appear to work on Fx 51.0.1 (32-bit--why do I have 32 bit? D:), though it does successfully remove the bottom border on the headers at List of multiplayer online battle arena games. Do you have a page where it works for you? --Izno (talk) 11:43, 28 March 2017 (UTC)

Works on Safari. On Chrome it seems that it only works halfway (no sticky support for thead elements...) and on Firefox it should be working but apparently it doesn't work at all. —TheDJ (talk • contribs) 12:30, 28 March 2017 (UTC)

Wow! Thanks! i added the gadget and it's great! --Ṗḯƥỡȵẘẩ (talk) 21:19, 28 March 2017 (UTC)

RfC on the new "Protector" permission

There is currently an RfC regarding this permission on Wikipedia talk:Protection policy#RfC on the new "Protector" permission. If you are willing to, could you please give feedback? Thank you --Cheers, FriyMan ^talk 09:13, 28 March 2017 (UTC)

Closed due to SNOW. Alsee (talk) 17:21, 29 March 2017 (UTC)

Fritz Angst

That's a one line article of an author of one book, which in turn is an eight line article. I'd say, ether delete both or merge them.

(Please forward if this is not the best location for this kind of proposal.)

bye217.248.40.182 (talk) 20:41, 28 March 2017 (UTC)

Wikipedia does have Wikipedia: Articles for deletion and you may have more joy there for this type of proposal. Carltonio (talk) 20:52, 28 March 2017 (UTC)

 Done I've redirected and trivially "merged" the author's article into the book article. The book article is not well developed, but it definitely does warrant a page here. There are a large number of significant sources which discuss this book. Alsee (talk) 20:08, 29 March 2017 (UTC)

RfC: Linking to details regarding the offline Medical Wikipedia app

Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

Should we allow a {{sister project}} style sidebar, i.e. Template:Offline in the form of {{offline|med}}, to be placed within the external links section of medical articles for the purpose of promoting Wikipedia:WikiProject Medicine/App? — Godsy ^(TALK_CONT) 17:36, 29 March 2017 (UTC)

Support

• Support Prior discussion here. Part of our efforts include "giving free access to the sum of all human knowledge" to all people. This should not be restricted to just when people have a functional Internet connection (something those in the developed world take for granted). Part of our work is to improve access to knowledge in the language of people's choice and in formats that they can use. For many of those in the developing world Internet access is only avaliable for a couple of hours a day or only when they visit larger urban centers. Offline content address these limitation. We know our online content struggles to reach those in the developing world. Our offline medical apps however have been downloaded by more than 150,000 people of which about 80% are from the developing world. Doc James (talk · contribs · email) 17:50, 29 March 2017 (UTC)
• Support I wasn't a great fan of a huge banner for this, but I can't see any problems with this template, and Doc James makes a compelling case for the apps usefulness. Sam Walton (talk) 17:57, 29 March 2017 (UTC)
• support per reason [7]--Ozzie10aaaa (talk) 17:58, 29 March 2017 (UTC)
• Support: The Offline Medical Wikipedia app is an application that allows Wikipedia's medical content to be downloaded in a choice of languages in compressed ZIM format (as well as a free, open-source offline browser, Kiwix, that will natively display the compressed data, if required). Its principal purpose is to allow mobile phone users in parts of the world where internet access is restricted, intermittent, or unreliable to have constant access to our medical content. As an additional means of distribution of our content, I'd personally prefer it to be a sidebar link (like "Download as PDF" is), but I'll certainly support a link somewhere in the footers of medical articles to the WikiProject Medicine page where it is documented. --RexxS (talk) 18:24, 29 March 2017 (UTC)
• Support. There are more than a million billion of people in developing countries that only have access to the Internet for a limited time. This banner is useful for million billion of readers who can use it when they are not online. The banner is the sum of all human knowledge at your fingertips for people who don't have unlimited Internet access or who want to use it while offline. Is there a better solution? QuackGuru (talk) 19:03, 29 March 2017 (UTC)

User:QuackGuru I think you mean more than a BILLION :-) Doc James (talk · contribs · email) 19:06, 29 March 2017 (UTC)

Yep. QuackGuru (talk) 19:17, 29 March 2017 (UTC)

• Support - I had thought this debate had already been resolved satisfactorily in the deletion discussion. Yes, the sidebar is non-intrusive and helping users access our articles is an important part of our mission. Sizeofint (talk) 19:35, 29 March 2017 (UTC)
• Support The debate had already been resolved to almost everyone's satisfaction, and this RFC appears to be unnecessarily pointy. • • • Peter (Southwood) ^(talk): 19:57, 29 March 2017 (UTC)
• Support I also support this. I think anyone working in a developing countries context knows how important it is to have Wikipedia content available offline. I wonder if the people opposing this have ever lived in an area with poor internect access and poor public health, few doctors available, no access to healthcare etc.? For people like that having the offline version of medical content (in several languages) is wonderful. Due to the fact that not many people are aware of this app yet, I strongly support having the template (or any other form of awareness raising for this app) in an appropriate place of many related Wikipedia articles. Having it at the bottom right seemed like a perfect solution to me! EMsmile (talk) 20:01, 29 March 2017 (UTC)
• support is a related WMF project, and will be limited to medical articles. Jytdog (talk) 00:18, 30 March 2017 (UTC)
• Support - would also support the "inline" type being discussed below. Note, this support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page. — xaosflux ^Talk 00:22, 30 March 2017 (UTC)
• Support - the proposal is similar to other boxes that we have, so should be understandable to people who consult Wikipedia for a variety of topics. I would particularly note that the template should also display on mobile devices (I was disappointed to find that {{Library resources box}} does not). --122.108.141.214 (talk) 00:55, 30 March 2017 (UTC)

This template should also be included in {{Sister project links}} if this goes ahead. --122.108.141.214 (talk) 01:05, 30 March 2017 (UTC)

• Support. This really is a very worthwhile initiative for the purpose of helping more people become readers of Wikipedia – which after all should be what we all want. In previous versions, there have been problems with potential advertising or with overly-large banners, but those problems have now been solved. And putting it in EL is the right way to do it. I think this RfC helps tie up loose ends from previous discussions, by spelling out where and how the box will be used. I also would support the inline idea described below. --Tryptofish (talk) 01:10, 30 March 2017 (UTC)
• Support. Seems like a worthwhile cause that could be very helpful in regions of the world with poor internet infrastructure. ---- Patar knight - ^chat/_{contributions} 02:29, 30 March 2017 (UTC)
• Support Wikipedia's health care articles are generally high quality and it is helpful to inform readers about the app which displays that content. Johnuniq (talk) 10:45, 30 March 2017 (UTC)
• Support, it's a good way to give the app visibility. Icebob99 (talk) 15:39, 30 March 2017 (UTC)

Oppose

• Oppose. Use formatting similiar to {{dmoz}} instead. KATMAKROFAN (talk) 20:28, 29 March 2017 (UTC)
  • Possibly an unfortunate analogy as DMOZ has just closed down. Nevertheless it's an interesting suggestion, so could you give an example of how this might look on an article like Pneumonia, please? --RexxS (talk) 21:05, 29 March 2017 (UTC)

• Village pump (proposals) at Curlie
• Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

KATMAKROFAN (talk) 21:35, 29 March 2017 (UTC)

• Thank you. So essentially, you'd prefer the content of the template as plain text among the external links, rather than in a box floated to the right of the page with the sister projects? That seems a possible alternative. --RexxS (talk) 22:05, 29 March 2017 (UTC)

  We also have Template:Commons-inline. The two are not exclusive of each other. Doc James (talk · contribs · email) 22:09, 29 March 2017 (UTC)

  (edit conflict)Seems a strange way to do it. The links placed there are almost always links external to the Wikimedia projects, whereas we tend to put links to Wikimedia related places (Commons for example) in a side box like the one being proposed here. Sam Walton (talk) 22:09, 29 March 2017 (UTC)

• I'm going to oppose.

  I'm sympathetic to the view that "offline reading" should be enabled.

  I do not, however, believe this is the way to do it. A systematic way, which relies not on en.WP's hack of a template, nor one which advertise a particular reader or viewer, is a) much better and b) provides the functionality for all pages, without c) the mess of a template addition to every article (within a certain scope) for d) every reader, mobile or not. To that end, there is a phabricator task for this funcitonality at phab:T113396. My final opinion: Just be patient. It's on the (WMF) radar. Courtesy ping to AGomez (WMF) who looks to have been editing the page at meta:New Readers/Offline. --Izno (talk) 12:58, 30 March 2017 (UTC)

  • • Yup more options for reading Wikipedia offline are coming :-) The page this template links to will discuss that option as soon as it is avaliable. The template is not specific to raising awareness about a single app but about raising awareness about offline options generally (options of course need to be free and under an open license). Doc James (talk · contribs · email) 13:16, 30 March 2017 (UTC)

Discussion

Relevant discussions preceding this RfC: Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Sidebar, Wikipedia talk:WikiProject Medicine/App#Sidebar, and Wikipedia talk:WikiProject Medicine/Archive 94#Sidebar. — Godsy ^(TALK_CONT) 17:36, 29 March 2017 (UTC)

• Would this only be placed on WikiProject Medicine articles? Sam Walton (talk) 17:43, 29 March 2017 (UTC)
  • Yes it would only be placed on medical articles. Doc James (talk · contribs · email) 17:48, 29 March 2017 (UTC)
  • @Samwalton9: There has been some discussion regarding other versions, i.e. {{offline|X}}, but I'm not sure what stage of progress those are in. That is one of the reasons Wikipedia:WikiProject Medicine/App/Sidebar was moved to Template:Offline. I've clarified medical in the RfC wording. — Godsy ^(TALK_CONT) 17:50, 29 March 2017 (UTC)

it seems s support vote is best for everyone, not clear what(or why) your position is such given prior general opinion[8]--Ozzie10aaaa (talk) 18:10, 29 March 2017 (UTC)

The initial heading was "non neutral". Have adjusted it so that it is.[9]. And here is the link to policy requiring the statement of the RfC to be neutral[Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief] Doc James (talk · contribs · email) 18:19, 29 March 2017 (UTC)

@Doc James: Advertising, i.e. "the act or practice of calling public attention to one's product or service", is not inherently non-neutral. However, raising awareness is inherently non-neutral. — Godsy ^(TALK_CONT) 18:32, 29 March 2017 (UTC)

Godsy you appear to dislike the app. Can you explain why? I was under the impression that we address your concerns. Doc James (talk · contribs · email) 18:34, 29 March 2017 (UTC)

@Doc James: Would you find "Publicizing the offline Medical Wikipedia app" or "Promoting the offline Medical Wikipedia app" agreeable for the RfC title? — Godsy ^(TALK_CONT) 18:40, 29 March 2017 (UTC)

We could use "Linking to details regarding the Offline Medical Wikipedia app" Doc James (talk · contribs · email) 18:43, 29 March 2017 (UTC)

 Done. I'll fix the existing links. — Godsy ^(TALK_CONT) 18:46, 29 March 2017 (UTC)

Godsy, although you're a relative newcomer, you must know very well by now that this encyclopedia is strongly opposed to any advertising. It is inconceivable that you do not understand that calling other editors' contributions "advertising" is rude and and offensive to them. To then edit-war your calumny back into this RfC is beyond acceptable behaviour, and I shall be considering seeking administrative assistance to ensure that you do not repeat that behaviour in future. --RexxS (talk) 18:56, 29 March 2017 (UTC)

@RexxS: Changing it to raising awareness was no better. I reverted twice, then came here to discuss; Doc James changed it thrice. If you do choose to seek administrative assistance, it will likely be fruitless, as I've done nothing inappropriate. — Godsy ^(TALK_CONT) 19:07, 29 March 2017 (UTC)

@RexxS: I misspoke, I reverted twice. I was concerned about the link at {{cent}}. Best Regards, — Godsy ^(TALK_CONT) 19:13, 29 March 2017 (UTC)

Changing it to raising awareness was no better - That's simply untrue. "Raising awareness" on Wikipedia carries none of the pejorative implication of "advertising" and it's not the "euphemism" that you claimed in your edit summary, ... if you euphemize inappropriately again, I expect you to check my contributions and fix all the existing links. You don't seem to understand edit-warring either. You called the template "Advertising the Medical Wikipedia app"; Doc James changed it to "Raising Awareness of the Offline Medical Wikipedia app". That's the point where you take it to talk, not after forcing your preferred version back into this page twice more. I understand your concern about having to update links at Cent, but that's a small price to pay for not offending other good-faith editors. Quite honestly, I'd much prefer not to have to waste my time at ANI, but I remain concerned that you're not willing to own up to mistakes like 22 reverts with no reason other than the edits you reverted didn't seek consensus beforehand and calling an RfC with a non-neutral title. --RexxS (talk) 19:33, 29 March 2017 (UTC)

Euphemize wasn't the best description, though it is not necessarily inaccurate; it and the rest of my edit summary was a reaction to behavior that I've come to expect from some wp:med participants. I created it at Title X (creation), Doc James changed it to Title Y (Bold), I revered it back to X (Revert) - that is the point where discussion should have taken place. Doc James shouldn't have changed it a second time (Discuss), especially as the title they changed it to was not any better neutrality-wise. The over 20 reverts you mention: Doc James added {{offline|med}} to a group of articles (Bold), I reverted the additions notifying them that the change was contentious and suggesting a venue for discussion, Doc James ignored that and restored them all (Discuss). History is important for context: Wikipedia:WikiProject Medicine/App/Banner was added to the top of a few articles, some about a year ago, and at least one with the edit summary "one week trial". I'm not sure if there was any local consensus at that point, but editors removed the banners, and they were restored by members of the WikiProject. Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Banner began. It was closed as "Keep, but not to be inserted into articles without obtaining consensus to do so." Editors removed the banners from the articles for a second time per that consensus, but again, members of the WikiProject restored them. Wikipedia:Village pump (proposals)/Archive 138#Use of Wikipedia:WikiProject Medicine/App/Banner on articles is opened, and finally 3 months later, the banners were removed after being present at the top of articles all that time (since the MfD) against community consensus. That's all I have to say on the matter here, as not to further detract from the RfC. — Godsy ^(TALK_CONT) 04:26, 30 March 2017 (UTC)

I think it would be worth showing the actual template in question, to allow those unfamiliar with the previous debates to get an idea of what we are discussing. --RexxS (talk) 18:29, 29 March 2017 (UTC)

Thanks User:RexxS have moved to the top of the RfC. Doc James (talk · contribs · email) 18:38, 29 March 2017 (UTC)

If it is advertising, then it is advertising for something benign. The real offender is the link to the "Wikipedia Shop" selling T-shirts which appears on every page. Matthew Ferguson (talk) 18:51, 29 March 2017 (UTC)

The app is developed by volunteers at WPMED and Wikimedia CH. It is free and without advertising. The development cost (paying for programmers) is covered by movement funds. We are not "selling" anything so the user of the term "advertising" IMO is inaccurate. Doc James (talk · contribs · email) 19:15, 29 March 2017 (UTC)

agree--Ozzie10aaaa (talk) 19:40, 29 March 2017 (UTC)

Promotion/advertising/raising awareness/etc. It's semantics. I feel the reason this is an issue with some is that it represents placing a link on encyclopedia pages to a program which is not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 20:40, 29 March 2017 (UTC)

It's more placing a link to the data - i.e. the compressed Wikipedia content. Surely the program (offline browser) is incidental. Wouldn't the reason you suggest be as logical as having an issue with the [Download as PDF] link, which is on every article page, because Adobe Acrobat "is not directly related to any given encyclopedia topic"? --RexxS (talk) 20:48, 29 March 2017 (UTC)

Invalid analogy really. 1. PDFs can be read with many programs, 2. downloading the article as PDF does not require you to download any program in particular, 3. the link gives you a PDF of the article you were on, I assume the link to the medical app will not directly link you to the article you were originally on. Matthew Ferguson (talk) 21:10, 29 March 2017 (UTC)

Not really. 1. ZIMs can be read by many programs; 2. downloading the data does not require you to download any program in particular – especially as ZIM is an open and standardized file format, unlike PDF; 3. the link gives you all of Wikipedia's medical content, including the article you are on, which allows you to go to all of the other medical articles that the article has wikilinks to (unlike a PDF). --RexxS (talk) 22:16, 29 March 2017 (UTC)

Yup exactly. The main WP app should be reading ZIMs soon aswell.Doc James (talk · contribs · email) 22:48, 29 March 2017 (UTC)

Rfc: Remove description taken from Wikidata from mobile view of en-WP

This stems from discussion at Wikipedia:Administrators'_noticeboard/Incidents#Hard_to_detect_mobile_vandalism and Wikipedia:Village_pump_(technical)#Discussion_at_ANI_about_Wikidata_use_in_mobile_view

Do you support the following statement: "The description taken from Wikidata that is currently being loaded in mobile views of en-WP pages, must be immediately removed from mobile views of en-WP pages"

Please !vote "support" or "oppose". Jytdog (talk) 00:07, 30 March 2017 (UTC)

Update: Hi all, based on the raised concerns, we have decided to turn the wikidata descriptions feature off for enwiki for the time being. However, we’d like to encourage the RfC to continue with a focus on identifying the blockers for turning the feature back on in the future - thank you for your comments on these issues so far. Posting current list of blockers in comments below - please review. As mentioned, users have found this feature useful as a means of providing an at-a-glance description of the article. I’d also like to note that releasing these types of features is a piece-wise process - we began with displaying the description to evaluate the feature and would like to continue with the next step - editing the description based on your feedback. Thus, this second iteration of the feature will take some time to complete, and would probably not be released until June 2017 at the earliest. Thanks! OVasileva (WMF) (talk) 17:21, 30 March 2017 (UTC)

!votes

• Support. StevenJ81 (talk) 00:30, 30 March 2017 (UTC)
• support Jytdog (talk) 00:32, 30 March 2017 (UTC) Adding rationales: 1) en-WP has a BLP policy and DS on BLP topics, because these are contentious issues and people get fierce about them, and there are legal ramifications. Wikidata has no BLP policy and in any case content changes there are not governed by anything in en-WP; content from there should not be the first thing people see when they go to read an en-WP article. 2) Same thing applies for non-BLP topics; V and NPOV and OR do not apply in Wikidata. 3) en-WP editors cannot see the Wikidata description. There are many possible ways they could but working that out is a huge issue itself. This practice should stop until things are worked out (if they ever can be) Jytdog (talk) 01:38, 30 March 2017 (UTC)
• Oppose I'm not aware of any Wikidata policies which encourageallow descriptions that would be disallowed here (or prevents editors from removing them). The problem is just some poor editors and vandals at Wikidata – something we have far more of at Wikipedia. Anyone can fix bad Wikidata descriptions by clicking the "Wikidata item" link under "Tools" in the desktop version of the article (a link on the mobile version might be nice but the mobile designers like streamlining). Wikipedia accounts work at Wikidata and you remain logged in when you switch site. They also allow anonymous editing. A script to display Wikidata descriptions in the desktop version was posted to Wikipedia:Village pump (technical)#Wikidata description in mobile view on enwiki. We could consider making a gadget version or at least list it at Wikipedia:User scripts. By the way, many Wikipedia templates import data from Wikidata. See Category:Templates using data from Wikidata. PrimeHunter (talk) 00:41, 30 March 2017 (UTC)

The issue is that when vandalism occurs to a Wikidata definition that is viewed by millions, it often remains unfixed for months. On EN Wikipedia this simply does not happen for such popular pages. I have proposed a solution below to fix the issue. Doc James (talk · contribs · email) 00:44, 30 March 2017 (UTC)

• Support - (edit conflict) I get the idea. For example, there are lots of other non-English Wikipedias that use templates to auto-generate infoboxes from Wikidata, but I think A) that in and of itself is a bad idea unless there's a way to incorporate the anti-vandalism team into it, which there currently doesn't seem to be, and B) we definitely shouldn't have someone making that decision for 5m articles without community consensus, which I don't think they would've gotten if they'd bothered to try. TimothyJosephWood 00:45, 30 March 2017 (UTC)
  • Yes we pulled the use of Wikidata for the number of our infobox parameters due accuracy issues as described here. Doc James (talk · contribs · email) 00:51, 30 March 2017 (UTC)
• support. As I wrote at YPT, the descriptions (I spent 5 mins in mobile mode browsing them) add nothing to articles. At best they just restate what is in the lead. At worst they are badly written or a poor summary. Mobile view should display the same content as desktop view, as far as is possible. Editors editing a lead to present the clearest definition of a topic do not expect it to be preceded by another definition, one they can’t even see if editing on the desktop. They are an obvious target for vandalism and disruptive editing; Wikidata’s terrible editing interface probably keeps some of them away, but it also deters anyone wanting to fix them. There is as far as I can see no way to edit them from the mobile view.--JohnBlackburne^words_deeds 01:03, 30 March 2017 (UTC)
• Support Until (1) there is the ability to have changes from WD to JUST the definitions appear on my watchlist on WP. (2) there is the possibility to set the definition locally. When this has occurred I will support the use of definitions from Wikidata/WP again. Doc James (talk · contribs · email) 01:19, 30 March 2017 (UTC)

• User:OVasileva (WMF) and User:Jkatz (WMF) is what I have requested a possibility? I like the feature, just need assurances that the few small technical fixes need to assure accuracy will be implemented. Doc James (talk · contribs · email) 11:22, 30 March 2017 (UTC)

• Oppose First, one important point: if wikidata use on enwiki is problematic for BLP reasons, please note Wikidata is displayed not only on mobile view, but also on desktop view at www.wikipedia.org when you type into the search bar. I have previously had the same problem of trying to change the wikidata text without knowing where it was from. Wikidata text in these contexts seems quite useful and rarely problematic, so the key is finding a way of displaying the source of wikidata text when it appears on enwiki so that editors know where to change it. NPalgan2 (talk) 01:41, 30 March 2017 (UTC)
• Support per the arguments presented at the ANI thread by the unlikely unity ticket of Fram and RexxS. -- Euryalus (talk) 02:35, 30 March 2017 (UTC)
• Support per my comments in the AN/I thread mentioned immediately above by Euryalus. WMF needs to pay more attention to this find of feedback from the editors of en.wiki, its primary website. Beyond My Ken (talk) 03:29, 30 March 2017 (UTC)
• Oppose, this seems to be kneejerk change aversion rather than an actual problem. The correct solution rather than taking a step backwards, is to make it easier to identify and correct the vandalism when it does occur. Lankiveil ^{(speak to me)} 03:52, 30 March 2017 (UTC).
• Support as emergency action until a technical solution is developed to address the issues raised here. This is the only prudent course of action to stop this highly visible vandalism. I do question its usefulness as a subtitle when viewing mobile pages, but I have found it to be very helpful in the search function, so there should be a long-range solution developed. Having this value locally stored in a template or magic word is the best idea. No matter the degree of watchlist and edit-button connectivity implemented between Wikipedia and Wikidata, there remains the fact that unless some pretty drastic permissions changes are made, administrators here will have no additional power to fight this vandalism than any other user. Given the prominent placement of these descriptions, it's better to take as few risks as possible. – Train2104 (t • c) 05:25, 30 March 2017 (UTC)
• Conditional oppose – I use the mobile Wikipedia a lot and I find these descriptions very useful, especially for searching. However, it is undeniable that the amount of vandalism occurring is too high. I suggest that only autoconfirmed users can change labels on Wikidata (these "descriptions" are item labels). I believe the WD descriptions should be kept on two conditions: 1) that this is enabled in the desktop view, considering that most of our editors edit via desktop; and 2) that an "edit" link is included next to the description so editors know what to do if they spot vandalism. OVasileva (WMF) or Jkatz (WMF), is this possible? Thanks, Laurdecl ^talk 05:37, 30 March 2017 (UTC)
• Support. The idea behind these descriptions (for mobile and for search) is good. But the implementation is poor. This is a language-based thing, not some common information, and should thus be stored and edited at the language version (enwiki), not at one of the common resources (Wikidata and Commons). Creating a template (a kind of hatnote) which goes above the infobox for mobile view and gives the description is easy (and initially a bot can probably copy the existing descriptions from Wikidata and import them here if people feel that that would be useful). Making that description turn up in the search results would probably require cooperation with WMF, and for that purpose it would be best if we could agree on some template form and name to be used across all wikilanguages (a bit like Persondata in the past). But the end result would be that the description is an integral part of the article here, subject to our policies, protection, ... and visible in watchlist, recent changes, history, ... Much simpler than trying to fix this on Wikidata, with e.g. an option to only show changes to this in our watchlist, and a direct link from here to there to edit it there, and so on. Keep it simple, keep it here. Fram (talk) 06:51, 30 March 2017 (UTC)
• Support It's a knee jerk reaction, but that is how en.wp rolls :) I'd like to see some actual data. In my anecdotal experience, the vandalism rate on wikidata is significantly lower than on English Wikipedia, even though the 'online' time per incident might be a bit higher than we are used to here. I also think that this isn't significantly solving the problem, and that isolationism definitely isn't the solution. But we can create solutions later. —TheDJ (talk • contribs) 08:32, 30 March 2017 (UTC)
• Conflicted. My immediate response is a knee-jerk reaction to the knee-jerk reactions, namely that I oppose disabling this because I feel like it would be an over-reaction and we would struggle to gain consensus to re-enable it in the future because 'WMF did a thing I didn't explicitly agree to and it's not perfect'. Equally, I totally agree that it's troubling there is content that is being displayed to enwiki readers that we can't easily monitor. As I said elsewhere, I think T161596 would be the best solution, adding the wikidata description to the desktop view for logged in users (perhaps optionally), to provide some extra oversight from this community. I'm sympathetic to disabling the feature until better checks are in place, I just worry that it would never be re-enabled. Sam Walton (talk) 09:01, 30 March 2017 (UTC)
• Support. Actual vandal rates may still be lower on Wikidata than here, but the level of vandal watching is also quite inadequate, and I've seen examples myself where vandalism on Wikidata remained uncorrected for unaaceptably long times. Plus, evidently, the system is not transparent enough for users of the mobile app to understand how and where to report and/or correct this kind of vandalism when they notice strange entries, and most regular Wikipedia talkpage watchers never notice these problems. Fut.Perf. ☼ 09:03, 30 March 2017 (UTC)
• Oppose. From my experience (1,936 pages on watchlist on enwiki 15,007 pagew on watchlist on wikidata) vandalism rate on wikidata is comparable to rate at enwiki, even a bit smaller. While wikidata are weaker with fast response to vandalism at popular themes, enwiki is weaker with vandalism at less popular themes (vandalism edits at less popular articles covered with some bot edit are mostly unnoticed). Meta:Resolution:Biographies of living people is fully binding for Wikidata and it is respected (see w:Wikidata:Wikidata:Autobiography). Jklamo (talk) 11:49, 30 March 2017 (UTC)
  • "Meta:Resolution:Biographies of living people is fully binding for Wikidata and it is respected (see w:Wikidata:Wikidata:Autobiography)" From that page: "You may raise such concerns on the Village Pump, on the Administrators' Noticeboard, or on the talk page of the editor concerned. If you are not satisfied with the response of editors and admins to a concern about biographical material about living people, you can contact the Wikimedia Foundation directly." The page was only created on 16 March 2017, and it is too bad that the links to the Village Pump and the Admin Noticeboard don't link to any Wikdata page and thus will never be seen by Wikidata editors. Just goes to show how serious this is taken by Wikidata... (plus, who will look for this at "autobiography"? That's only for pages you write about yourself, not for pages written by someone else where you have a complaint). Fram (talk) 13:12, 30 March 2017 (UTC)
• Support per Future Perfect Ealdgyth - Talk 12:52, 30 March 2017 (UTC)
• Support I've been editing for almost nine years and had no idea mobile users see completely different text from what I see and edit. I feel either clueless, stupid, uninformed, or worse. First Light (talk) 14:22, 30 March 2017 (UTC)
• Oppose wikidata is the backbone of Wikipedia so start using it and fix problems when you find it. Get good quality descriptions in WIkidata will add value to the user experience not just in the mobile phone but also on other platforms - Salgo60 (talk) 14:50, 30 March 2017 (UTC)
• Support per Euryalus, First Light and others above.Smeat75 (talk) 15:04, 30 March 2017 (UTC)
• Support - Making it easily visible to all desktop editors is not a solution, as it would introduce a new battleground of highly visible content (titles, lead sentences, infoboxes) without enough added reader value to justify that battleground. In short, the cost exceeds the nonzero benefit. ―Mandruss ☎ 15:31, 30 March 2017 (UTC)
• Support. Whatever fine words its defenders come up with, Wikidata doesn't have the participant numbers to conduct any meaningful form of recent changes patrol or sweeps for vandalism/errors. To take my standard example, this edit—to a fairly high-profile figure averaging about 500 views a day, not some obscure page nobody ever reads—remained in place for over a year. ‑ Iridescent 15:52, 30 March 2017 (UTC)
• Support. Content on en must be from en. We cannot trust wikidata to maintain our standards for BLPs or other such issues. And showing material on mobile that is not even visible to non-mobile users is especially problematic because if our editors not using mobile devices can't see it, how can they even notice it to fix it? The same content must be shown on all access methods. —David Eppstein (talk) 16:30, 30 March 2017 (UTC)
• Support. I don't agree with statements such as "all content on en must be from en", but if any data is not coming from en then I think it's a minimum requirement that it's easy for en editors to see the change, e.g. in their watchlists. If that can be done we could revisit this. I would also prefer that editing data that affects en-wiki should happen on en-wiki, but that's more debatable. Mike Christie (talk - contribs - library) 17:19, 30 March 2017 (UTC)

Statement from WMF reading team

A comparison of mobile frontend with and without wikidata descriptions

• Hi, we are open to switching this off while we identify next steps for fixing identified blockers. We do, however, want to make sure everyone understands the rationale behind the feature, which is designed to provide an at-a-glance article description for people who:

(a) have to scroll through many screens to get past the infobox before they can learn about the topic, and (b) for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences.

We have currently identified these items as blockers:

• Difficulty of editing wikidata descriptions in Wikipedia - for mobile, we are currently testing the mobile version of this solution on the Android app and have begun looking at ways to bring it to the mobile web (phabricator task https://phabricator.wikimedia.org/T141230). For desktop, we are in the process of brainstorming solutions along with the wikidata team
• In terms of tracking the changes to these descriptions, we have some planned tasks for creating easier ties between Wikidata and Wikipedia. Currently:

1) Edits do show up in recent changes and watchlist if the user has enabled it and is using the non-enhanced recent changes setting (Phabricator tickets: https://phabricator.wikimedia.org/T108688, https://phabricator.wikimedia.org/T90436)

2) Edits do not show up in recent changes and watchlist if the user is using the recent changes setting (Phabricator ticket: https://phabricator.wikimedia.org/T46874)

3) Edits do not show up in the article history (Phab ticket: https://phabricator.wikimedia.org/T42358)

Please contribute your thoughts along with your vote, and lets continue to discuss productively how to help serve these diverse demographics. OVasileva (WMF) (talk) 00:52, 30 March 2017 (UTC)

Discussion

• Note - please don't turn this into bigger issues, of which there are many. These descriptions from Wikidata are added to content generated by the en-WP community that is subject to en-WP policies, but comes from a source that is outside the control and oversight of the en-WP community, and can only be fixed off-enWP. We already have examples of BLP violations showing up in mobile views because of this feature. This should be a quick/yes no, and if it is "yes, remove it" we can have subsequent discussions about adding it back or setting up some safeguards, in other discussions. Not here please. Jytdog (talk) 00:07, 30 March 2017 (UTC)

Agree this is a serious issue as often the vandalism introduced is the first thing people see and En WP editors only hear about it when a reader posts on the talk page of the article in question (of which all are not that well watched).

Would like to hear proposed solutions and that the issue is being taken seriously before making up my mind. We should ping the app people to let them know of this discussion. I must sleep first though. Doc James (talk · contribs · email) 00:22, 30 March 2017 (UTC)

• User:TNegrin (WMF) not sure who to direct this to. A few things that would help include:

1) These descriptions show on EN WP (so we can pick up issues)

2) If the description changes on Wikidata it shows within the watchlist for the EN article (I do not have the bandwidth to follow all changes on Wikidata but would be willing to watch this one section)

3) We can set it locally to override Wikidata.

With this done I would support keeping the descriptions from WD. Doc James (talk · contribs · email) 00:36, 30 March 2017 (UTC)

User:OVasileva (WMF) can these three things be done? Doc James (talk · contribs · email) 00:59, 30 March 2017 (UTC)

Hi Doc James. Thanks for thinking through this with us. I totally agree that having them show in moderation queues and allowing editing are important. We've been thinking about these for awhile the issues we're facing might reflect us needing to change the order of operations bit. I'll quote what OVasileva (WMF) wrote on the Admin board [10] about this:

In terms of tracking the changes to these descriptions, the Wikidata team has been focusing on creating easier ties between Wikidata and :Wikipedia. Currently:

1. Edits do show up in recent changes and watchlist if the user has enabled it and is using the non-enhanced recent changes setting (Phabricator: https://phabricator.wikimedia.org/T108688, https://phabricator.wikimedia.org/T90436)
2. Edits do not show up in recent changes and watchlist if the user is using the recent changes setting (Phabricator: https://phabricator.wikimedia.org/T46874) 
3. Edits do not show up in the article history (Phabricator: https://phabricator.wikimedia.org/T42358 )

In terms of allowing edits on Wikipedia:

• Currently the android team has built a way of editing wikidata descriptions from within the app - more information on the short descriptions page as well as the project page in phabricator We’re currently rolling it out as a pilot on three languages and our plan is to measure and evaluate the interest for this feature on the apps before approaching the solution for mobile web - we’re curious to know if there is any interest in pursuing a similar solution for the mobile website? Some of our initial mockups and ideas for the mobile website can be found in this phabricator task

I also believe there are some gadgets for showing it on desktop, but until we solve the editing and tracking issues, showing it to everyone might increase the impact of the issues rather than improving upon them. Jkatz (WMF) (talk) 01:12, 30 March 2017 (UTC)

User:Jkatz (WMF) The problem is I cannot watch all those wikidata entries as the number of changes are simply too great a load. If only changes to the "definition" could show up in my watchlist I would than turn that feature on. Doc James (talk · contribs · email) 01:17, 30 March 2017 (UTC)

Those are the complicated alternatives that in my view are too much to get into now. Endlessly debateable with many variations possible. Bottom line is that right now everybody reading en-WP on mobiles is seeing at the top of every article, content from Wikidata that is not subject to BLP or any other en-WP content policy for that matter. Jytdog (talk) 00:46, 30 March 2017 (UTC)

If 2 and 3 were done the issue would be more or less dealt with. Doc James (talk · contribs · email) 01:09, 30 March 2017 (UTC)

Not really. 1) It is an ad hoc solution based on en-WP editors turning on a feature, while the description is in every mobile view by default. It is apples and oranges. 2) Also, Wikidata has no BLP policy. You are in a Wild West when you make a change there and there is nothing stopping who ever did it in the first place from coming right back and re-adding it, over and over. We have a BLP policy and we have discretionary sanctions on BLP topics because of this kind of thing. Jytdog (talk) 01:26, 30 March 2017 (UTC)

As those definition show on EN WP by default, the changes to that part of WD should initially occur on the EN WP watchlists of all users by default (until a person turns it off).

If you can set a local definition that overrides WD that addresses your second concern of "re-adding". I like the overall functionality of these short definitions. They just need to be handled better. Doc James (talk · contribs · email) 01:31, 30 March 2017 (UTC)

You are not going to bed, mister!  :) Three issues: (LIke I said all these "solutions" are endlessly complicated and we should not be discussing them here!! 1) It appears to me that the WMF reading team draws the field from Wikidata. I am not sure that an override in an infobox on en-WP solves the problem; 2) adding the 'definition" field in an infobox means displaying another field in an infobox and one of the things Olga says above is that infoboxes are already a problem in mobile view; and 3) we have our own battles about infoboxes in en-WP right? What about articles without infoboxes or where that field get suppressed? Not feasible. Jytdog (talk) 01:48, 30 March 2017 (UTC)

Doesn't need to be within the infobox and actually should not be in the infobox. Should just be setable locally. Doc James (talk · contribs · email) 01:51, 30 March 2017 (UTC)

Not convinced on #3 at all. Seems like we are proposing that incorrect wikidata content be buried beneath possibly correct enwiki content, rather than the incorrect wikidata content be fixed. #2 is already a preference in the Watchlist - perhaps one way of going about this would be to change the preference so that all Wikidata description edits show on local watchlists irrespective of preference, while edits to the rest of a wikidata item can display or not on local watchlist according to the preference. Jo-Jo Eumerus (talk, contributions) 14:49, 30 March 2017 (UTC)

No #2 is NOT an option right now. This would be good "all Wikidata description edits show on local watchlists" Doc James (talk · contribs · email) 15:51, 30 March 2017 (UTC)

• User:PrimeHunter please provide a link to Wikidata's BLP policy. I looked and found none. Jytdog (talk) 00:50, 30 March 2017 (UTC)

I was about to reformulate my post to say I'm not aware of any Wikidata policies which encourage descriptions which would be disallowed here, or prevent editors from removing them. PrimeHunter (talk) 00:53, 30 March 2017 (UTC)

:) Sorry to be too quick and thanks for replying. But what you write there, is entirely different from having a policy that forbids content like this, and that allows taking action against users who add such content. And what is worse, if I take the time to go fix an en-WP BLP violation in Wikidata and another editor there restores it, there is no Wikidata BLP policy to fall back on. This is not a feasible situation. Jytdog (talk) 01:01, 30 March 2017 (UTC)

Nothing to apologise for. I did save it and should have thought more about it first. I have limited Wikidata experience and don't know whether edit warriors readding crap is a serious problem. The Wikidata descriptions are also displayed in mobile searches. Bandwidth is limited or expensive for many mobile users so they may like a brief description before clicking a link. It may seem odd if the clicked link then doesn't contain what they clicked on. PrimeHunter (talk) 01:18, 30 March 2017 (UTC)

• User:OVasileva (WMF) Does this mean that WMF Reading team has switched it off, or just that it is willing to, pending the outcome of this RfC? Please clarify. I have more to say but this is the essential point right now. Jytdog (talk) 01:10, 30 March 2017 (UTC)

• User:OVasileva (WMF) I will go ahead and add this before I forget. Above in (b) you wrote that the Reading team did this in part for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences.. I am not sure you understand how explosive that is - WMF is overriding en-WP on a content issue. Yikes. Jytdog (talk) 01:20, 30 March 2017 (UTC)

Yes, if that's the way they want to play it, just do away with volunteer editors altogether and have the staff write the encyclopedia by themselves. Beyond My Ken (talk) 03:32, 30 March 2017 (UTC)

• History --I am playing catch up on all this but an IP posted these two threads from VPT about this happening - almost no one responded. No RfC.
  • August 2016: Wikipedia:Village_pump_(technical)/Archive_148#.5BIdea.5D_Wikidata_descriptions_to_help_disambiguate_article_topic_on_mobile_web
  • January 2017: Wikipedia:Village_pump_(technical)/Archive_152#Showing_Wikidata_descriptions_underneath_article_title_on_mobile_web
  • I also looked and found this Phab from late 2015; These two comments there -- here and here -- were important and were blown off and are what we are talking about now. For pete's sake. Jytdog (talk) 03:59, 30 March 2017 (UTC)

• WMF people (and others), is there a good reason why this needs to be on Wikidata and not in the enwiki (dewiki, frwiki, ...) article? I have described (in my "support" above) how I would see this working as a templated part of the article, not a Wikidata item. As it is something that needs to be typed out for every language and every article, it provides no profits to store it centrally (on Wikidata) as far as I can see. Otherwise why not store the whole article on Wikidata and get rid of all these language-based projects? I understand (and support) the reasons why these descriptions were added, but not the implementation of it through Wikidata (certainly not the current one, but not the philosophy behind it either). Fram (talk) 07:01, 30 March 2017 (UTC)

• User:Laurdecl thanks for !voting above, but you are talking about a dramatic change to Wikidata with respect to who can edit what, and that is an extremely long and complex issue. There are other workarounds but they too will be long and complex discussions. This RfC is about stopping this now. Would you please respond to the RfC question? Thx Jytdog (talk) 07:25, 30 March 2017 (UTC)

{My suggestion is a way to stop this – now. If we restrict changing descriptions to autoconfirmed editors then we lose 99% of vandalism. Allowing new editors/IPs to change descriptions is similar to allowing them to move pages. "Now" is a relative term; this RfC will probably end up going on for three months, assuming the WMF even comply. Anyway, I have responded to the RfC question. Laurdecl ^talk 07:32, 30 March 2017 (UTC)

{ping|Laurdecl}} - BLP issues are not just due to "vandalism" - people add BLP-violating content all the time for reasons they think are very good. This is why en-WP has BLP policy and discretionary sanctions. Framing this as just a vandalism thing misses a lot of the point. Two examples were brought up in the ANI - see this diff at Wikidata (did the person who added "boyfriend" think that was true? I don't know) and see here about ethnicity. Neither is vandalism-like. BLP issues are not simple. Jytdog (talk) 07:42, 30 March 2017 (UTC)

@Jytdog: I feel that it is too extreme to remove this from ~5,000,000 articles because someone found 2 BLP violations. I definitely agree with you that BLP violations should not be permitted, neither here nor Wikidata. Has anyone proposed the BLP policy over at Wikidata? Assume that this is removed, what would you then do? Laurdecl ^talk 07:52, 30 March 2017 (UTC)

OK, you don't understand the problems here. Thanks for talking though. 07:56, 30 March 2017 (UTC) — Preceding unsigned comment added by Jytdog (talk • contribs)

Slightly rude, but I'll bite. Can you please dumb it down for me and make it more overly simplistic? Perhaps you could actually reply to what I said, namely introducing a BLP policy on Wikidata? Thanks. Laurdecl ^talk 08:02, 30 March 2017 (UTC)

There are three different groups here, each of which have no control over the other. 1) en-WP; 2) WMF Reading team; 3) the Wikidata community. None of them can tell the other what to do. You seem to be suggesting that WMF Reading team "force" Wikidata to make dramatic changes in their policies. On top of that, it is hard to change policy. Wikidata is a big community that is very young, with almost no policy and no good way of making new policy, and people with their own set of very strong ideas and feelings. Doing something as radical as restricting editing fields or as huge as setting up a BLP policy there will take a very, very long time. And no one can make them do it, and they might never agree in any case. It is not any kind of real world solution.

The problem here is that on its own the WMF reading team decided to insert content from Wikidata that it doesn't control and that is uncontrolled by any en-WP policy and unmonitored by the en-WP community, into every single en-WP article viewed on a mobile, including BLPs. The WMF has no jurisdiction over en-WP content. What they have done here is an over-reach and one that puts en-WP and the WMF in legal danger every day. It was clueless. It should be stopped immediately. Jytdog (talk) 08:16, 30 March 2017 (UTC)

No, I'm not saying the WMF should force policy onto Wikidata (although it could because, as you say, BLP is a legal issue). How do you know Wikidata wouldn't accept a BLP policy; have you proposed it over there, on their Village Pump? I'll support it. Sidenote: Who cares if the WMF is sued, it's their responsibility. We can always fork Wikipedia. Laurdecl ^talk 08:41, 30 March 2017 (UTC)

No, the WMF cannot force it. Look at BLP on the commons. I am done with this discussion. Jytdog (talk) 08:45, 30 March 2017 (UTC)

Yes they can, they can force anything they want, they own this place. Why do you not want to propose a BLP policy on Wikidata? If you can only consider one viewpoint and ignore any compromise or suggestions then I'm done as well. Laurdecl ^talk 09:08, 30 March 2017 (UTC)

Having a BLP policy on Wikidata is not enough. You would also need people patrolling and interested in enforcing it. Doc James (talk · contribs · email) 11:34, 30 March 2017 (UTC)

• I would just care to say that the solution for BLP problems seems to be Pending Changes/Flagged Revisions/whatever. Getting rid of Wikidata is just admitting that 'the wikiway' doesn't scale towards BLP. Just because we have put a defensive mob in front of the en.wp wikiway, doesn't solve the larger problems of BLP on a movement scale. We are implementing the wrong solutions for the problem. —TheDJ (talk • contribs) 08:32, 30 March 2017 (UTC)

What we need is a BLP policy on Wikidata. Why doesn't someone propose it over there? Laurdecl ^talk 08:41, 30 March 2017 (UTC)

Not the real world. They don't even have a Verify policy. Done here too. Jytdog (talk) 08:45, 30 March 2017 (UTC)

Propose one? Laurdecl ^talk 09:08, 30 March 2017 (UTC)

Any verify policy on Wikidata cannot help in this case, because the item description has no means of being associated with a reference to verify it. --RexxS (talk) 10:51, 30 March 2017 (UTC)

I've created a template to show what I think ought to be done. This template renders either the text of the first unnamed parameter or the item description from Wikidata if there is no parameter. It could be wrapped in a span to make it visible only in mobile view, but it provides a demonstration of a local override for the Wikidata description which is sorely needed. On the article Priyanka Chopra (Priyanka Chopra (Q158957)) it works like this:

• {{DescriptionWD}} → Template:DescriptionWD
• {{DescriptionWD |Indian actor and singer}} → Template:DescriptionWD

This is not a solution in itself, because the subheading in mobile view is not derived from wikitext. But it should be. --RexxS (talk) 10:51, 30 March 2017 (UTC)

While it is an improvement, it sidesteps the question of why we would ever take this language-dependent text from Wikidata in the first place. Fram (talk) 11:02, 30 March 2017 (UTC)

Indeed. I honestly do understand your antipathy to such procedures (although I don't share it generally), and in the case of item descriptions I am very sympathetic, because of the inability to associate them with sources. My intent was merely to illustrate how – given there exists a determination to make use of these descriptions in mobile view – we might restore control of what is displayed to the English Wikipedia. In many cases the Wikidata description is innocuous and serves to further disambiguate between articles like:

• Newport, Rhode Island ("Template:DescriptionWD");
• Newport, Wales ("Template:DescriptionWD"); and
• Newport, Pembrokeshire ("Template:DescriptionWD").

Disambiguation is exactly what descriptions were designed to do (and nothing else). --RexxS (talk) 11:34, 30 March 2017 (UTC)

Thanks. Fram (talk) 11:40, 30 March 2017 (UTC)

As far as I can tell this isn't mentioned in the discussion above; these descriptions are also used in the links dialog in VE. If you edit an article in VE, select "Newport", and hit Ctrl-K, you get a list of possible targets, with the description string attached. I'm sympathetic to this RfC and am leaning towards supporting it, but for completeness I should say that these descriptions are extremely useful in VE, and make adding links much more efficient. As written this RfC would not remove this function from VE. Mike Christie (talk - contribs - library) 13:18, 30 March 2017 (UTC)

The feature wasn't mentioned in the FAQs so I made Wikipedia:FAQ/Editing#How do I edit mobile subtitles? The top of page histories display MediaWiki:Histlegend. We could also consider a "Wikidata item" link there for users who don't notice it in the left pane. PrimeHunter (talk) 13:23, 30 March 2017 (UTC)

Thanks. The idea behind the RfC is to disable the use of these Wikidata descriptions anywhere on enwiki, whether at the top of mobile articles, in search results, in the "related articles" (where they also seem to be used), ... And of course suggested future solutions should then also apply everywhere (if possible): whichever tool, code, toggle... populates these now, should fetch the text from e.g. a new template on enwiki instead of fetching it from Wikidata~, for every use of this text. The problem is the same in all cases, the RfC should apply to all cases, and the future solution as well (but the RfC is not strcitly dependent on any solution). Fram (talk) 13:29, 30 March 2017 (UTC)

I think I agree with you that if this RfC should succeed, the VE usage should disappear too, but I think it should be made explicit in the wording (and we might ping those who've !voted already so they can update their positions in the unlikely event they would change their views on that basis). Mike Christie (talk - contribs - library) 13:36, 30 March 2017 (UTC)

OVasileva (WMF) above says this feature "is designed to provide an at-a-glance article description... for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences." It is not possible to "dumb down" every article to such a level, some topics actually need a little more explanation. Take an article I have been watching and editing for a long time, Christ myth theory. In the mobile view [11] the description imported from wikidata says "Opinion that biblical Jesus was purely fictional." Editors have spent years on the talk page and article space arguing about the definition of the theory and that description would not be accepted as accurate either by me or editors on the opposing "side" as me. I think it is outrageous that these simplistic descriptions are being added to every WP article on mobile view with no consultation or notice to the editors that write and edit the articles, yes it should be stopped, and reversed immediately.Smeat75 (talk) 15:22, 30 March 2017 (UTC)

• Added to T:CENT. – Train2104 (t • c) 16:28, 30 March 2017 (UTC)
• In my view this problem was created by a combination of two local content issues: (1) infoboxes at the top of articles that, on mobile, mean you have to scroll down a long way to reach the lead sentence, and (2) cruft in the lead sentence (in overlong parenthetical remarks giving translations into other languages, birth and death dates, eponyms, or other extraneous information) that, again on mobile, mean you have to scroll down a long way to reach the meat of the sentence. These issues create pressure to show what the article is about earlier, and mediawiki responded to that pressure by grabbing a convenient source of information, the wikidata description. That was wrong, but we should still do something about the underlying issues. (1) could probably be fixed either technically, by moving the infobox down or minimizing it in mobile, or locally in a content-driven way, by changing our standards for infoboxes so that they start with a short description similar to the wikidata ones but locally sourced. (2) can only be fixed by changing our standards for leads to demand that the parenthetical junk be no more than a certain length. —David Eppstein (talk) 16:47, 30 March 2017 (UTC)

Enable Visual Editor on the Wikipedia namespace

I do a lot of edit training mostly to or through the GLAM sector. My earlier edit training using the wikitext editor produced very few ongoing contributors. However, I now teach Visual Editor (VE) and this has been very popular (including the those previously taught the wikitext editor) and I am seeing the VE training producing more ongoing contributors (e.g. [12]) which is a good result for the VE. The stumbling block I am now enountering is these users increasingly want/need to contribute to pages in the Wikipedia name space, where the VE is not enabled. Here are some examples:

• VE users cannot use the VE to report bugs or give feedback on the Visual Editor because it is located at Wikipedia:VisualEditor/Feedback, so who knows what bugs/feedback are not being reported because of this
• VE users cannot use the VE to get help from the Wikipedia:Teahouse
• the GLAM work is documented in the Wikipedia name space. So I have VE-trained libraries wanting to edit these pages about Wikipedia projects involving their library but can't. My only workaround is to redirect the page from the Wikipedia name space as a subpage of a User account (where the VE is enabled). See this example [13].

We need to reduce the barriers to VE users from being unable to contribute more fully. I note that Talk is not currently enabled for the VE due to the earlier plan to replace Talk with Flow (which appear to have been dropped). At this time, the VE is currently unable to produce indentation as the colon does in wikitext, so I am not proposing enabling the VE on Talk pages at this time. However, opening up the Wikipedia name space would facilitate greater engagement for our new VE cohort of contributors. Kerry (talk) 02:14, 30 March 2017 (UTC)

@Kerry Raymond: Wikipedia pages have lots of odd markup that I'm not seeing as a good fit, for example look at this page - now head over to testwiki:Test1MarchA or test2wiki:Test2017MarchA and try it out with the visual editor. — xaosflux ^Talk 02:22, 30 March 2017 (UTC)

I think there are some problems with the sites you used for the copy (red links everywhere). But I copied this page into a the sandbox in my user space (i.e. still on the enWP site) and I didn't see any big issue with editing it in the VE. Kerry (talk) 03:23, 30 March 2017 (UTC)

The primary issue I found was that you can't properly indent comments in threaded discussions. Trying to add a comment here, for example, tried to add a paragraph one indent level back, and it wasn't obvious to me how to get it indented out again to the right place. VE also seems to add a lot of whitespace all over the place when editing, making the page very hard to read. Sam Walton (talk) 10:00, 30 March 2017 (UTC)

Indeed. VisualEditor is not supposed to be used in discussions at all. Jo-Jo Eumerus (talk, contributions) 14:43, 30 March 2017 (UTC)

If folks object to it being enabled everywhere, perhaps some method to enable it on a page-by-page basis where demand for such a thing exists? Lankiveil ^{(speak to me)} 04:18, 30 March 2017 (UTC).

• Support page by page enabling of VE on non main space pages. Doc James (talk · contribs · email) 11:18, 30 March 2017 (UTC)
  • If I remember correctly, it's not technically possible to enable VE on a page by page basis. —TheDJ (talk • contribs) 14:33, 30 March 2017 (UTC)

    TheDj: Would it be possible to enable VE globally for a namespace, suppress the edit tab at the top of the page (so VE would work but you'd have to construct the URL), and then unsuppress on a page-by-page basis? Mike Christie (talk - contribs - library) 14:41, 30 March 2017 (UTC)