Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Editing

< Community Wishlist Survey 2016
Editing
34 proposals, 299 contributors, 655 support votes



Tracking translation sources in revision history of translated articles

Formerly: Statement translation sources in the revision history (Machine translated)
  • Problem: Articles translated from other wikis should clearly show their sources. A list of contributors including, but not limited to, source wiki and local wiki editors, as well as translators, should be made easily accessible.
    • 问题：从其他wiki翻译的文章要清楚的表明来源。应该可以容易地看到（访问）一个贡献者的目录（包括但不限于wiki来源和本地wiki的编者及译者)。
  • Who would benefit: This improvement would make the system more friendly to contributors by giving proper credit and showing a clearer and more complete revision history.
    • 对谁有益：这一改进将使次系统对贡献者更加友好，更加尊重贡献者付出的劳动，同时也使修订历史更加清晰完整。
  • Proposed solution: CX already links edit summary to source revisions in its edits, but what about other translations? We can use a git-style approach of forking and branching (or marking multiple parent revisions in particular). A translations would then effectively become a fork (or a merge if the article already exists), and the revision history would display a fork tree/network.
    • 提议的解决方案：现在CX 已经在编辑摘要中给出翻译的版本的链接，但从其他页面过来的翻译内容如何解决？一种方案是采用类似于现在流行的git版本控制的分枝fork的办法（特别是多重来源). 一个译文相当于分出一个分枝（若文章已经存在就合并，然后在修订历史页展示修订历史和这个树网fork tree。

(Please help translate)

  • Phabricator tickets:

Community discussion

Voting – Tracking translation sources in revision history of translated articles

  1.   Support--Shizhao (talk) 02:44, 28 November 2016 (UTC)[reply]
  2.   Support Maybe the software could automatically ask users submitting more than 500 bytes or creating new pages if their contribution is a translation from another wiki. If yes, the user informs both the language and the article name and then the software automatically appends to the summary the most recent oldid to the original article in that moment. ArgonSim (talk) 23:14, 5 December 2016 (UTC)[reply]
  3.   Support On Polish Wikipedia when translate tool is used a link to oryginal article is in edition history. It's helpful. Plogeo (talk) 19:51, 10 December 2016 (UTC)[reply]
  4.   Support Michal Lester לסטר (talk) 11:45, 12 December 2016 (UTC)[reply]

  • Problem: Can't add dead link template to a ref in VE
  • Who would benefit: Editors
  • Proposed solution: Add support for dead links to VE. A checkbox would do it. Have the code date the template creation.
  • Phabricator tickets:

Community discussion

  1.   Support Libcub (talk) 02:36, 2 December 2016 (UTC)[reply]

Wikitext editor syntax highlighter

  • Problem: Wikitext is a markup language, and for some cases, it will be more beneficial if there is official support for syntax highlighting in the wikitext editor.
    • Day-to-day editing in articles with many references in paragraph. When there are a lot of <ref></ref> tags inline with paragraph, the paragraph takes a lot of effort to edit, since mentally, one needs to separate the text with the codes for references.
    • Editing a template when handling multiple parameters like {{{a|{{{b|{{{c}}}}}}}}}. Many times, translating templates comes with this cost of missing a few curly braces due to the wikitext editor not being clear enough to detect it.
  • Who would benefit: Article editors, template editors
  • Proposed solution: I'm aware of the syntax highlighter created by User:Remember the dot, and would like to see something similar to this tool to be more integrated to MediaWiki, to be loaded faster in the wikitext editor, and also having more theme-friendly colours. Hence, official support by WMF is needed for a syntax highlighter in the wikitext editor.
  • More comments: #20 in last year's results, 2015 Community Wishlist Survey/Editing#Color-coded WikiText editing
  • Phabricator tickets: phab:T101246
  • Proposer: Kenrick95 (talk) 14:25, 13 November 2016 (UTC)[reply]

Community discussion

  • This is currently on the radar at the next-generation wikitext editor. I don't think there's anything the Community Tech team can do here this year. MER-C (talk) 01:51, 14 November 2016 (UTC)[reply]
    • Also, if I'm remembering what I heard correctly, the main obstacle to including syntax highlighting in the 2017 editor is not the difficulty of coding it but the difficulty of keeping it from slowing down the editor unacceptably. And I doubt that's specific to the 2017 editor; I remember trying a syntax highlighter gadget for the existing wikitext editor and finding it slowed down the experience so much that it turned it off. So this may be a more difficult task than it appears initially. On the other hand, the fact that it is difficult may be a good reason for the Community Tech team to take it on when volunteer-built gadgets already exist.Neil P. Quinn-WMF (talk) 18:16, 17 November 2016 (UTC)[reply]
  • I really like this idea and I'm glad the Wikipedia community is working on it. I think it will make the general public view Wiki Markup Language as an actually programming language thats simple and easy to use and instantly useful. Hopefully it will be the first programming language people learn in school. Wikideas1 (talk) 23:49, 21 November 2016 (UTC)[reply]
  • I'm not sure the biggest syntax recognition issue I have is addressed by this proposal. I may have tried user Remember the dot's highlighter at one point but disabled it after finding it not particularly helpful. Per § Customizing, templateColor is set to {{template}}. When there are several levels of nested templates, it would be more helpful to highlight the highest nested levels in different colors. For example, templateColor1 is {{template}}, templateColor2 is {{template}} and templateColor3 is {{template}}.
Syntax: {{#ifeq:string1 | string2 | result1 | result2}}
Syntax: {{#ifexpr:expression | result01 | result02}}
e.g. {{#ifeq:{{#expr:{{PAGENAME}}}}|{{PAGENAME}}|{{#ifexpr:{{PAGENAME}} > 0 and {{PAGENAME}} < 10 | AD {{PAGENAME}} | {{PAGENAME}} }} | {{PAGENAME}} }} (only one level is highlighted, templateColor is set to {{template}})
e.g. {{#ifeq:{{#expr:{{PAGENAME}}}}|{{PAGENAME}}|{{#ifexpr:{{PAGENAME}}> 0 and{{PAGENAME}}< 10 | AD{{PAGENAME}}|{{PAGENAME}}}}|{{PAGENAME}}}} (3 levels are highlighted)
  • string1 = {{#expr:{{PAGENAME}}}}
  • string2 = {{PAGENAME}}
  • result1 = {{#ifexpr:{{PAGENAME}}> 0 and{{PAGENAME}}< 10 | AD{{PAGENAME}}|{{PAGENAME}}}}
    • expression = {{PAGENAME}}> 0 and{{PAGENAME}}< 10
    • result01 = AD{{PAGENAME}}
    • result02 = {{PAGENAME}}
  • result2 = {{PAGENAME}}
I generally only see a need for syntax highlighting in more complex templates; highlighting links, comments and headings seems unnecessary. So, if nested template highlighting is part of this proposal, I support it, otherwise, why bother? There are more important priorities. Wbm1058 (talk) 19:26, 29 November 2016 (UTC)[reply]

Voting – Wikitext editor syntax highlighter

  1.   Support--Shizhao (talk) 02:45, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  3.   Support Ninovolador (talk) 11:33, 28 November 2016 (UTC)[reply]
  4.   Support --Boehm (talk) 13:51, 28 November 2016 (UTC)[reply]
  5.   Support Samwalton9 (talk) 14:47, 28 November 2016 (UTC)[reply]
  6.   Support -Nocowardsoulismine (talk) 17:59, 28 November 2016 (UTC)[reply]
  7.   Neutral since this is already on the development radar, and I (even as a user of the gadget) have trepidation about the less-than-optimal performance of this, potentially putting off multitudes of editors. Not everyone has my degree of patience. :) Stevie is the man! Talk • Work 20:46, 28 November 2016 (UTC)[reply]
  8.   Support JAn Dudík (talk) 21:49, 28 November 2016 (UTC)[reply]
  9.   Support, on the condition that the performance issue can be figured out - this would be very lovely to have! SamanthaNguyen (talk) 22:26, 28 November 2016 (UTC)[reply]
  10.   Support Anthonyhcole (talk) 03:33, 29 November 2016 (UTC)[reply]
  11.   Support Very useful tool when it works. · · · Peter (Southwood) (talk): 08:26, 29 November 2016 (UTC)[reply]
  12.   Support  @xqt 14:02, 29 November 2016 (UTC)[reply]
  13.   Support ChristianKl (talk) 17:24, 29 November 2016 (UTC)[reply]
  14.   Weak support I like the idea, but Stevie has a point. StevenJ81 (talk) 17:44, 29 November 2016 (UTC)[reply]
  15.   Support Would it be possible to add Lua highlighting as well? ShakespeareFan00 (talk) 21:07, 29 November 2016 (UTC)[reply]
  16.   Support --Telaneo (User talk page) 21:41, 29 November 2016 (UTC)[reply]
  17.   Support --Nikola (talk) 22:17, 29 November 2016 (UTC)[reply]
  18.   Support --Gnom (talk) 09:42, 30 November 2016 (UTC)[reply]
  19.   Support I use the gadget when I edit wikitext for tricky cases and I really appreciate it. Trizek from FR 17:59, 30 November 2016 (UTC)[reply]
  20.   Support — Pajz (talk) 12:02, 1 December 2016 (UTC)[reply]
  21.   Support Ahm masum (talk) 17:32, 1 December 2016 (UTC)[reply]
  22.   Support Flor!an (talk) 17:59, 1 December 2016 (UTC)[reply]
  23.   Support Oliv0 (talk) 18:04, 1 December 2016 (UTC)[reply]
  24.   Support Definitely needed. --Vachovec1 (talk) 19:25, 1 December 2016 (UTC)[reply]
  25.   Support -- Wikideas1 (talk) 20:43, 1 December 2016 (UTC)[reply]
  26.   Support in principle, since these supports appear to be more for the 2017 editor improvements than anything else czar 01:44, 2 December 2016 (UTC)[reply]
  27.   Support Libcub (talk) 02:36, 2 December 2016 (UTC)[reply]
  28.   Support Jmvkrecords ⚜ (Intra talk) 08:01, 2 December 2016 (UTC).[reply]
  29.   Support --Thgoiter (talk) 08:17, 2 December 2016 (UTC)[reply]
  30.   Support Draceane (talk) 09:58, 2 December 2016 (UTC)[reply]
  31.   Support but only for the new 2017 wikitext editor. —TheDJ (talk • contribs) 10:15, 2 December 2016 (UTC)[reply]
  32.   Support —Jc86035 (talk) 11:11, 2 December 2016 (UTC)[reply]
  33.   Support --Continua Evoluzione (talk) 14:16, 2 December 2016 (UTC)[reply]
  34.   Support Sannita - not just another it.wiki sysop 14:22, 2 December 2016 (UTC)[reply]
  35.   Support --Banfield - Reclamos aquí 15:06, 2 December 2016 (UTC)[reply]
  36.   Support --Framawiki (talk) 20:31, 2 December 2016 (UTC)[reply]
  37.   Support // Martin Kraft (talk) 00:00, 3 December 2016 (UTC)[reply]
  38.   Support --Ranjithsiji (talk) 06:05, 4 December 2016 (UTC)[reply]
  39.   Support -- Aspiriniks (talk) 09:10, 4 December 2016 (UTC)[reply]
  40.   Support Gareth (talk) 11:10, 4 December 2016 (UTC)[reply]
  41.   Support --Anika (talk) 14:12, 4 December 2016 (UTC)[reply]
  42.   Support --By erdo can (talk) 14:18, 4 December 2016 (UTC)[reply]
  43.   Support -<(kmk)>- (talk) 01:44, 5 December 2016 (UTC) It is about time to upgrade from the user provided scrip wikEd[reply]
  44.   Support. Waiting for the feature. ··· 👦 Rachmat04 · 💬 07:34, 5 December 2016 (UTC)[reply]
  45.   Support --Andropov (talk) 17:19, 5 December 2016 (UTC)[reply]
  46.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  47.   Support But this should be implemented in a way that doesn't impair performance, because most gadgets that execute this function tend to run sluggishly on big codes. ArgonSim (talk) 19:07, 5 December 2016 (UTC)[reply]
  48.   Support --Troubled @sset (talk) 17:19, 5 December 2016 (UTC)[reply]
  49.   Support --WinTakeAll (talk) 22:01, 5 December 2016 (UTC)[reply]
  50.   Support --Zone42 (talk) 12:03, 6 December 2016 (UTC)[reply]
  51.   Support Still waiting for years and years. Rdrozd (talk) 22:27, 6 December 2016 (UTC)[reply]
  52.   Support. - Mailer Diablo (talk) 07:02, 7 December 2016 (UTC)[reply]
  53.   Support --Assianir (talk) 07:44, 7 December 2016 (UTC)[reply]
  54.   Support 4nn1l2 (talk) 08:07, 7 December 2016 (UTC)[reply]
  55.   Support--Afernand74 (talk) 08:18, 7 December 2016 (UTC)[reply]
  56.   Support —Ynhockey (talk) 13:49, 7 December 2016 (UTC)[reply]
  57.   Support, long overdue — NickK (talk) 18:46, 7 December 2016 (UTC)[reply]
  58.   Support - Frankly somewhat small for the Community Wishlist, but still long overdue. If we want to continue allowing markup-editing as a viable alternative to Visual editor it needs support from the getgo. WikEd is too slow... CFCF 💌 📧 20:33, 7 December 2016 (UTC)[reply]
  59.   Support - This would really help people and be good for larger edits. RileyBugz (talk) 21:57, 7 December 2016 (UTC)[reply]
  60.   Support - DPdH (talk) 00:17, 8 December 2016 (UTC)[reply]
  61.   Support - JackTracker JackTracker (talk) 06:08, 8 December 2016 (UTC)[reply]
  62.   Support — Rhododendrites talk \\ 06:11, 8 December 2016 (UTC)[reply]
  63.   Support This is the dream TheLordJagged (talk) 09:21, 8 December 2016 (UTC)[reply]
  64.   Support Jianhui67 talk★contribs 10:57, 8 December 2016 (UTC)[reply]
  65.   Support --Tractopelle-jaune (talk) 15:40, 8 December 2016 (UTC)[reply]
  66.   Support -- Amir (talk) 18:28, 8 December 2016 (UTC)[reply]
  67.   Support - DPdH (talk) 19:58, 8 December 2016 (UTC)[reply]
  68.   Support Miniapolis 23:50, 8 December 2016 (UTC)[reply]
  69.   Support But only if it wouldn't slow older computers down. Espresso Addict (talk) 04:13, 9 December 2016 (UTC)[reply]
  70.   Support --Psychoslave (talk) 09:59, 9 December 2016 (UTC)[reply]
  71.   Support--Nizil Shah (talk) 06:46, 10 December 2016 (UTC)[reply]
  72.   Support Absolutely. --Waldir (talk) 11:13, 10 December 2016 (UTC)[reply]
  73.   Support (only as an option, of course) --g (talk) 12:09, 10 December 2016 (UTC)[reply]
  74.   Support --OrsolyaVirág (talk) 13:03, 10 December 2016 (UTC)[reply]
  75.   Support --NaBUru38 (talk)
  76.   Support --Alaspada (Talk) 03:57, 11 December 2016 (UTC)[reply]
  77.   Support I already use an available syntax highlighter, but it is terrible. What's shown above would be a vast improvement.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:48, 11 December 2016 (UTC)[reply]
  78.   Support Tinss (talk) 17:50, 11 December 2016 (UTC)[reply]
  79.   Support --Plagiat (talk) 18:07, 11 December 2016 (UTC)[reply]
  80.   Support – Uanfala (talk) 23:35, 11 December 2016 (UTC)[reply]
  81.   Support But by default it should only trigger on pages that are less than ~nkilobytes (TBD), with an override button to manually trigger it in those instances. To prevent annoying slowdowns for massive pages and/or slow computers.
  82.   Support--Mikheil Talk 21:00, 12 December 2016 (UTC)[reply]

Drag and drop Commons files to Wikimedia projects

  • Problem: Adding Commons files on Wikimedia projects relies on two different processes : either, using the search engine of the Visual Editor, or knowing the name of the file and copy/cut it with the rest of the wikicode. None of these methods relies on categories, which are maintained by the Commons community and the (currently) only way that Commons is structured.
  • Who would benefit: Editors who add Commons files on Wikimedia projects.
  • Proposed solution: The possibility to drag and drop a file from a Commons category to a Wikimedia project. This would automatically trigger the visual editor, and add the file at the identified place.
  • Phabricator tickets: phab:T151647
  • Proposer: Léna (talk) 11:44, 8 November 2016 (UTC)[reply]

Community discussion

  • Like this idea, a lot. Seems very handy, doable and non-controversial. —TheDJ (talk • contribs) 15:25, 8 November 2016 (UTC)[reply]
  • @Léna and TheDJ: Just letting you know I've moved this proposal here from the Editing category, as it seems the technical challenges would originate with Commons. Thanks for participating! MusikAnimal (WMF) (talk) 01:26, 15 November 2016 (UTC)[reply]
  • I probbaly won't use it but I don't see why it shouldn't be added as a feature, I see no specific reason to oppose.--Alexmar983 (talk) 03:19, 15 November 2016 (UTC)[reply]
  • I don't understand what you mean by drag and drop: do you envision people opening two browser windows, with a Commons category in one window and a page in the other window, just to drag an image from one window and drop it on the other? Seems overly complex and unlikely to be widely used. Wouldn't it suffice to make the "insert media" dialog also search categories, so that one can "drag and drop" from within the same window? (I thought it did, but maybe the feature can be made more discoverable.) Nemo 08:24, 15 November 2016 (UTC)[reply]
    Yes this is what I have in mind. Your alternative supposes that the editor starts with a Wikipedia article (or a wiktionnary definition, or... ), and is looking for relevant files to add. What I'm talking here is a user that starts from a Commons category (for instance, a GLAM donation, or Wiki Loves Monuments, or all the pictures they took during an event), and tries to add these files to improve articles. Léna (talk) 13:22, 15 November 2016 (UTC)[reply]
    either way start with Commons or start with Wikipedia, it would likely be used by many folks. So, have 2 windows open. Click on a Commons photo, drag and drop to an article. Add a caption, and display size or "upright=". Automatically added to the article. I'd use it. Of course, most folks would want to fine tune the caption, size, and placement after the photo was added, but that would be a lot less work. Smallbones (talk) 17:56, 16 November 2016 (UTC)[reply]
  • This should not be very difficult to implement in VisualEditor. It already has good support for dragging and dropping different things. Matma Rex (talk) 17:37, 25 November 2016 (UTC)[reply]

Voting – Drag and drop Commons files to Wikimedia projects

  1.   Support--Shizhao (talk) 02:45, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  3.   Support Sadads (talk) 14:36, 28 November 2016 (UTC)[reply]
  4.   Support MichaelMaggs (talk) 20:07, 28 November 2016 (UTC)[reply]
  5.   Support Ahm masum (talk) 17:32, 1 December 2016 (UTC)[reply]
  6.   Support, in principle. Low priority overall. czar 01:44, 2 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 02:38, 2 December 2016 (UTC)[reply]
  8.   Support easier is better —TheDJ (talk • contribs) 10:16, 2 December 2016 (UTC)[reply]
  9.   Neutral Something like this would be nifty to have, but I would place this as a very low priority compared to other proposals. This isn't a critical need. Stevie is the man! Talk • Work 12:55, 2 December 2016 (UTC)[reply]
  10.   Support --Barcelona (talk) 14:16, 2 December 2016 (UTC)[reply]
  11.   Support--Ranjithsiji (talk) 06:05, 4 December 2016 (UTC)[reply]
  12.   Support This would be nice, but not a high priority. It also needs to be discoverable by users. the wub "?!" 16:18, 4 December 2016 (UTC)[reply]
  13.   Support - DPdH (talk) 00:18, 8 December 2016 (UTC)[reply]
  14.   Neutral Nice, but low priority. --Tryptofish (talk) 22:30, 5 December 2016 (UTC)[reply]
  15.   Support --Assianir (talk) 07:44, 7 December 2016 (UTC)[reply]
  16.   Support — NickK (talk) 18:51, 7 December 2016 (UTC)[reply]
  17.   Weak support — Rhododendrites talk \\ 06:12, 8 December 2016 (UTC)[reply]
  18.   Support - I like it. Just make sure that it works correctly most of the time because something like that could have errors. CLCStudent (talk) 15:53, 8 December 2016 (UTC)[reply]
  19.   Support --g (talk) 12:09, 10 December 2016 (UTC)[reply]
  20.   Support --OrsolyaVirág (talk) 13:04, 10 December 2016 (UTC)[reply]
  21.   Support I don't think this is something that would be easy to do without a major redesign of the software though. Reguyla (talk) 18:54, 10 December 2016 (UTC)[reply]
  22.   Support Quiddity (talk) 06:22, 12 December 2016 (UTC)[reply]
  23.   Support nice idea but it should be restricted Flow234 (talk) 21:14, 12 December 2016 (UTC)[reply]

Add a community-modifiable help system to VisualEditor

  • Problem: VisualEditor is more user-friendly than the older wikitext editor, but still has a large number of aspects that are not obvious to many or most who use it.
  • Who would benefit: Newer users of VE would benefit most, but all but the most experienced editors could still benefit.
  • Proposed solution: Admins should be able to (a) add a help link, as an icon, to any menu item in VE [currently, links are only available on the Options menu - click the "Options" item on the menu to see the "info" icons, at least in the English version of VE], (b) create the text for the pop-up that appears when a specific icon/link is clicked [currently, only developers have had that ability]; and (c) be able, in that help text (pop-up window), to include links to other Wikipedia pages [currently, help text has no links] - help pages, policy pages, a specific section of the user manual, whatever.
  • More comments: The only external link for help, within VE, is to the user manual. While the user manual can be quite helpful, it's not context-specific. Nor is the user manual a good place to put policy information - for example, that when creating a footnote, it should (at least, in the English-language version of Wikipedia) use a "reliable" source.
  • Phabricator tickets: Phab:T53798
  • Proposer: John Broughton (talk) 01:56, 8 November 2016 (UTC)[reply]

Community discussion

  • I quite like this idea! I have had moments myself where I don't know what a button does, or how to use a set of dialogues, in VE. We crowdsource most other things, including help pages; why not let community members produce documentation for VE? Extension:GuidedTour could potentially be of use in building this. Fluffernutter (talk) 15:45, 9 November 2016 (UTC)[reply]
  • Love it! This would be quite useful :) SamanthaNguyen (talk) 18:58, 12 November 2016 (UTC)[reply]
  • Discreet links to existing pages are rather innocuous, but creating more pages should not be encouraged. Nemo 08:34, 15 November 2016 (UTC)[reply]
    • This isn't intended, at all, to be the impetus for creating new help or info pages - Wikipedia has more than enough of these. Even two sentences, with a single link to the relevant section of the VE user manual, would be far superior to the current situation. Or, to put it differently, we have lots of documentation, and lots of potential questions about how something works in VE (and what the relevant guidelines are), but no direct connection between the two. -- John Broughton (talk) 23:56, 16 November 2016 (UTC)[reply]

Voting – Community-modifiable help system for VisualEditor

  1.   Support --Gryllida 23:54, 1 December 2016 (UTC)[reply]
  2.   Support--Ranjithsiji (talk) 06:06, 4 December 2016 (UTC)[reply]
  3.   Support I believe that a short sentence triggered by hovering your cursor over a tiny (?) icon should suffice, since newer users rarely read the documentation, anyway. The help texts could be hosted on meta, similar to what's already done with WMF tools, and then anyone willing to collaborate could translate them there. ArgonSim (talk) 19:13, 5 December 2016 (UTC)[reply]
  4.   Support SamanthaNguyen (talk) 04:18, 8 December 2016 (UTC)[reply]
  5.   Support Miniapolis 21:33, 8 December 2016 (UTC)[reply]
  6.   Support zanzu. Quiddity (talk) 06:23, 12 December 2016 (UTC)[reply]

Add button "export to mainspace" to user sandbox

  • Problem: During Wikipedia courses for newbies, we have seen that Sandbox has several disadvantages which make the work in this environment more difficult, especially for beginners.
  • Who would benefit: Mostly people starting to contribute to Wikipedia, but generally all Wikipedians who use sandboxes.
  • Proposed solution:
    1. Add button "export to mainspace" into the panel above the user sandbox. This will make it easier for beginners to publish their drafts. We have seen that this is a considerable problem for people who are just beginning to edit Wikipedia; the more beginners get their drafts to mainspace, the more of them will feel rewarded and thus will be more likely to become Wikipedians.
    2. Additional tweak: do not display user sandboxes in categories in which the drafts are inserted (i.e. give Wikipedia language editions the ability to switch off the categorization of sandbox pages), including categories inserted by a template (eg. a translation template). This will help beginners who want to prepare their drafts as complete as possible, including the categories.
  • More comments: There might be more tweaks needed for establishing a smooth flow from the user sandbox into the main namespace. For example, make sure that the exported pages are displayed in Special:Newpages.
  • Phabricator tickets: None yet.
  • Proposer: Vojtěch Dostál (talk) 11:44, 8 November 2016 (UTC)[reply]
--Vojtěch Dostál (talk) 11:44, 8 November 2016 (UTC)[reply]

Community discussion

I'm definitely on board with #2 as I have to remove sandbox categories from mainspace every now and again. #1 sounds acceptable too. Stevie is the man! Talk • Work 15:10, 8 November 2016 (UTC)[reply]

not a good idea. Most user drafts are in such a state that they need to be reviewed as if they were in form Draft space. I'd support a button: move to draft space. Otherwise user space drafts will remain a place where experienced promotional editors can hide their edits. DGG (talk) 23:28, 8 November 2016 (UTC)[reply]
My emphasis is on supporting #2. #1 isn't that important to me, although I don't see why we couldn't have this ability for experienced article creators. Stevie is the man! Talk • Work 16:30, 13 November 2016 (UTC)[reply]
An experienced promotional editor can simply move his article himself. He doesn't need a button to make it easy for him. On the other hand new users, especially users from demographics that are underrepresented benefit from a more straightforward UI. ChristianKl (talk) 10:47, 17 November 2016 (UTC)[reply]
I also disagree. In addition to the reasons DGG mentions above, en.wp at least needs to focus on article quality, not quantity. We need to encourage newbies to improve existing articles, this proposal expedites the creation of even more promotional and/or marginally notable (at best) crap. Our ability to patrol new pages is already overwhelmed. MER-C (talk) 06:21, 9 November 2016 (UTC)[reply]
Please explain. What does my proposal have to do with standards of quality? If anything, careful drafting of your article in sandbox actually improves the articles, doesn't it? --Vojtěch Dostál (talk) 11:55, 9 November 2016 (UTC)[reply]
That's not what happens in reality. I encourage you to spend some time in the sewers at en.wp, we get a lot of drive-by users who have no interest in improving the encyclopedia. The vast majority of drafts are unfit for mainspace -- take w:Category:AfC submissions by date/14 September 2016 for instance, less than 25% of drafts were of acceptable quality even after feedback from established users. See also w:Wikipedia talk:The future of NPP and AfC and w:Wikipedia talk:The future of NPP and AfC/The DGG discussion. en.wp already has enough crap articles as it is, we do not want to make it easier to create more. MER-C (talk) 02:19, 10 November 2016 (UTC)[reply]
Don't worry about that, we'll get rid of all those obtrusive article-writing people very soon...--Vojtěch Dostál (talk) 08:36, 10 November 2016 (UTC)[reply]

Isn't #1 just the existing move tab? #2 seems poorly thought out, there are probably maintenance categories that should be included on drafts. It might make more sense to be able to flag individual categories to hide pages in certain namespaces by default (with a link to show the hidden pages), something like how we can already flag a category as being hidden from display at the bottom of pages. Anomie (talk) 16:14, 11 November 2016 (UTC)[reply]

Regarding an easy move to articlespace - no way. That's why we have put all sorts of obstacles in the way of newcomers creating articles - but most are junk. Now if this was a move to the Draft namespace, that might be okay. -- John Broughton (talk) 05:48, 12 November 2016 (UTC)[reply]
I wasn't sure if move could do this but apparently it can. It takes some fiddling with the target name. Perhaps #1 is about making this process more direct? Stevie is the man! Talk • Work 16:40, 13 November 2016 (UTC)[reply]
You could add the "Move to mainspace" button to the template that is automatically put in the sandbox. On enwiki this is Template:User sandbox, which currently has a "Submit draft" button. The "Move to mainspace" button would act as an alternative, simply bringing the user to Special:MovePage, where they only need to hit one more button to make the move. If your wiki does not have a preloaded template for sandboxes, this can be easily configured by admins. However moving pages may be limited to autoconfirmed users, depending on the wiki's configuration MusikAnimal (WMF) (talk) 01:23, 15 November 2016 (UTC)[reply]
@Vojtěch Dostál: I wanted to make sure you saw my reply above. Does this work for you? MusikAnimal (WMF) (talk) 21:49, 21 November 2016 (UTC)[reply]
MusikAnimal (WMF) Thanks, yes, I read your suggestion. I feel demotivated by the community which consistently makes it harder and harder for newcomers to edit Wikipedia, as seen from reactions above. We are slowly killing this project by trying to create order in what used to be self-organized chaos.
Generally it is also better when all Wikipedia versions look the same (have identical buttons etc), so that newcomers switching between projects are not confused. However, your suggestion is better than nothing and probably the only viable option in the current atmosphere. We will look at the template and try to adapt it for our needs.--Vojtěch Dostál (talk) 22:35, 21 November 2016 (UTC)[reply]

Voting – "Export to mainspace" button in user sandbox

  1.   Neutral There seems to be too much controversy with the #1 part of the proposal, even though maybe something like it can be done for some users. The #2 part is something we've needed for a long time. Stevie is the man! Talk • Work 01:17, 1 December 2016 (UTC)[reply]
  2.   Support Draceane (talk) 10:01, 2 December 2016 (UTC)[reply]
  3.   Oppose There are a lot of student editing projects that are done in sandboxes, and this could result in a lot of bad-quality student pages being carelessly moved into mainspace. It would also conflict with the Article Creation Tool. --Tryptofish (talk) 22:33, 5 December 2016 (UTC)[reply]
  4.   Support #2,   Neutral #1 --Jan.Kamenicek (talk) 21:14, 7 December 2016 (UTC)[reply]
  5.   Oppose; DGG's solution (export to draft space) is much better. Miniapolis 21:37, 8 December 2016 (UTC)[reply]
  6.   Support #2,   Oppose #1 --Ydb2 (talk) 10:05, 9 December 2016 (UTC)[reply]

Add wikitext editor Options mode button

  • Problem: While editing a page, it is cumbersome to hide toolbar, change lines-per-window, hide the release disclaimer, or stop auto-save by Enter key in edit-summary. An "[Options]" button should show options to set lines-per-window, activate toolbar, or suppress the disclaimer ("By clicking Save you agree..."), or other common options.
  • Who would benefit: All users who edit multiple pages and want to quickly reset edit-options during edit-preview.
  • Proposed solution: It is difficult to set editor options for a larger/smaller lines-per-window, or hide the toolbar, or stop auto-save of a default edit-summary, for users not familiar with Special:Preferences. Instead, if users had a wikitext editor "[Options]" button, then they could quickly alter some options, and redisplay during edit-preview. In fact, people have asked to re-edit the Summary text because pressing Enter key (rather than Backspace) during a half-written Summary, will accidentally save the edit (and that should be disabled as an option), or actually a design flaw which should have ignored Enter in an edit-summary unless a user requests that mid-summary-save as a special option.
  • More comments: When selecting an option to hide the release-disclaimer (legal notice), perhaps ask are-you-sure that you have read and understand by clicking Save then you agree to release your contributions, because the legal team has objected to moving the disclaimer, and so suppression of the disclaimer should be a similar warning.
  • Phabricator tickets:
  • Proposer: Wikid77 (talk) 18:12/18:22, 20 November 2016 (UTC)[reply]

Community discussion

none

Voting – wikitext editor Options mode button

  1.   Support Miniapolis 21:39, 8 December 2016 (UTC)[reply]

Administrator- and Page mover-editable display titles, that make more than cosmetic changes to the title

  • Problem: The community has tied itself in knots over the title of the article about New York State. As someone born and raised in Upstate NY, I understand both sides of this issue. "This entire episode reflects our community's pattern of focusing entirely disproportionate amounts of the time and effort of our editors, which is Wikipedia's most important resources, on minor matters of nomenclature. It is the sort of thing that brings the project into mockery, and it should not go on any longer." Newyorkbrad (talk) 19:43, 25 October 2016 (UTC) See the discussion at en:Wikipedia:Move review/Log/2016 October.
  • Who would benefit: Editors and the project, from less time wasted in endless debates
  • Proposed solution: Such problems beg for a software solution. We have a magic word {{DISPLAYTITLE:title}} which is used to amend the displayed form of the page's title, but it only allows us to make minor, cosmetic changes to the title, such as changing the first letter to lowercase or putting all or part of the title in italics. Implement an enhanced version of {{DISPLAYTITLE:title}} that allows us to move the page to New York (state) so that accurate internal links to the article may be maintained, while using {{DISPLAYTITLE:New York}} to change the title that readers see to New York. The actual page titled New York may then either be a redirect to New York (state) or to any other page as determined by editor consensus, or perhaps a disambiguation page if consensus is that there is no primary topic for the title. To guard against title vandalism, make this feature available by another link to "Display title", along side the "Group notice" and "Page notice" links that administrators see when editing a page. Such "special display titles" would be maintained in a special area separate from the mainspace text that ordinary editors edit, so that only administrators and page movers could change the special display-title overrides.
This feature would also render Template:Correct title unneeded and obsolete.

Community discussion

  • I believe we would still need a process to determine whether there is consensus to move the existing page. This question might more readily be applied to existing pages like Georgia (U.S. state) and Georgia (country), where each could theoretically display without the disambiguator. BD2412 T 23:33, 3 December 2016 (UTC)[reply]
    Right, but my assumption is that this feature could satisfy the opposition to the move, enabling a consensus to move where there currently is none. Sure, the Georgias could benefit from this too. I suppose this would need to be implemented in a way that didn't confuse editors. Though the page title would read Georgia, in editing mode editors would still see "Editing Georgia (U.S. state)", and right below that: Display title: Georgia -- Wbm1058 (talk) 00:20, 4 December 2016 (UTC)[reply]

Voting – Admin/page mover-editable display titles

  1.   Oppose, no thanks. We will replace edit wars for article titles with edit wars for display titles, replacing page moves (something that is easy to protect against) with addition of DISPLAYTITLE (requires either full page protection or an abuse filter, neither is practical) — NickK (talk) 18:54, 7 December 2016 (UTC)[reply]
    NickK, you should re-read my proposal. This could only be changed by admins and page-movers, thus no edit wars, vandalism or other abuse risks. Unless you fear admin-level wheel-warring. I suppose there could still be endless talk-page infighting over what the display title should be, but I think people are just lacking a little imagination here. BTW my model for this idea is Britannica -- look up New York there, and see how they handle it. -- Wbm1058 (talk) 16:12, 8 December 2016 (UTC)[reply]
    @Wbm1058: On most wikis all autoconfirmed users have page-mover rights, thus the risk is the same. In general I see very little use in adding a new level beyond of title. If the title of an article is already subject to discussion, so will be the display title, thus this will just move talk-page infighting to another level — NickK (talk) 17:16, 8 December 2016 (UTC)[reply]
    NickK, I was thinking English Wikipedia. en:Wikipedia:Page mover: "Users are expected to have at least 6 months of editing history and at least 3,000 edits. There are currently 95 users with page mover, which makes the total number of users with this permission 1,368 (the rest are administrators)." If other wikis aren't set up this way, they can restrict the feature to full-blown administrators. Just a simple matter of configuration; I'm assuming that if this somehow gets sufficient support that the developers can make it flexible in how permissions to the feature are set up and configured. I'm more optimistic that rank-and-file editors will accept this and not argue any more about display-titles than they currently do about titles and display-titles in general. I anticipate there will be less disagreement, particularly with making "correct titles" the display title. Wbm1058 (talk) 17:48, 8 December 2016 (UTC)[reply]
  2.   Support This seems like a big improvement for many pages with disambiguated titles; if parenthetical disambiguation isn't necessary to clarify what the page is about, we wouldn't need to show a parenthetical in the title that the reader probably doesn't care about. TheCatalyst31 (talk) 02:47, 8 December 2016 (UTC)[reply]
  3.   Support Miniapolis 21:41, 8 December 2016 (UTC)[reply]
  4.   Support – This option would likely help resolve some perennial disputes. I don't see much potential for abuse if it's restricted similarly to page edit notices. Admins or page movers would apply the results of community discussions, which would actually prevent further title-warring. As noted by Wbm1058 the underlying page title would remain disambiguated, so that readers can easily find the desired article in search engine results. JFG (talk) 11:23, 11 December 2016 (UTC)[reply]

All-in-one-place edit conflict resolution

  • Problem: Current edit conflict resolution involves giving the user two versions of the source, "current" and "yours", and having them merge the versions by themselves. Looking between two potentially long sources and nodding up and down is not cool.
  • Who would benefit: Editors dealing with long sources, working with a slow pointing device, or the web version in general. Mobile users may suffer more, but I am not familiar with conflict resolution on mobile platform.
  • Proposed solution: Define a set of new tags that effectively serve as diff3-style merge markers. As a primitive example:
MediaWiki is the best wiki server software ever. {{fact|date=1927-02-31}}
<conflict><theirs>
=== Example ===
In fact, the best online encyclopedia uses MediaWiki.
</theirs><original>
<ref>{{cite blog|url=...}}</ref>
</original><yours>
<ref>{{cite blog|url=...}}</ref>

Why are we dealing with POV issues in sandbox?
</yours></conflict>
    • Front-end scripts can further enhance such representation by providing functions like simple enumeration ("list all conflicts") and goto ("next conflict", "previous conflict"). The same applies to VE.
  • More comments: Make sure the abuse filter rejects these tags.
  • Phabricator tickets: phab:T72163 (Edit conflicts (tracking))
  • Proposer: Artoria2e5 (talk) 04:56, 19 November 2016 (UTC)[reply]

Community discussion

Voting – All-in-one-place edit conflict resolution

  1.   Support But without the specific implementation requirements regarding tags. --Izno (talk) 00:11, 29 November 2016 (UTC)[reply]
  2.   Support, the current approach is very unusable and this is long overdue. I agree with User:Izno. --Fixuture (talk) 22:11, 29 November 2016 (UTC)[reply]
  3.   Support--Alexmar983 (talk) 05:38, 30 November 2016 (UTC)[reply]
  4.   Support A support for myself. (And yes, the tags are just a poorly-thought example for embedding). --Artoria2e5 (talk) 17:14, 30 November 2016 (UTC)[reply]
  5.   Support per Izno. We could use something along these lines. The current conflict resolution really doesn't help resolve anything. Stevie is the man! Talk • Work 02:32, 1 December 2016 (UTC)[reply]
  6.   Support Oliv0 (talk) 18:08, 1 December 2016 (UTC)[reply]
  7.   Support without the specific implementation requirements regarding tags too like Izno said. Gryllida 23:55, 1 December 2016 (UTC)[reply]
  8.   Support Libcub (talk) 02:42, 2 December 2016 (UTC)[reply]
  9.   Support Draceane (talk) 10:01, 2 December 2016 (UTC)[reply]
  10.   Support —TheDJ (talk • contribs) 10:17, 2 December 2016 (UTC)[reply]
  11.   Support: I like this one and am too often frustrated by the status quo. Thanks, Artoria2e5. --Zefr (talk) 19:30, 3 December 2016 (UTC)[reply]
  12.   Support--Ranjithsiji (talk) 06:07, 4 December 2016 (UTC)[reply]
  13.   Support - Best regards, Kertraon (talk) 11:52, 4 December 2016 (UTC)[reply]
  14.   Support. ··· 👦 Rachmat04 · 💬 07:35, 5 December 2016 (UTC)[reply]
  15.   Support Even though I'm not sure this one is the best way to implement it. ArgonSim (talk) 19:18, 5 December 2016 (UTC)[reply]
  16.   Support Troubled @sset (talk) Anything is better than the actual situation …   06:07, 4 December 2016 (UTC)[reply]
  17.   Support something like this, if it is technically feasible. Certainly, some way of making edit conflicts less conflicting would be a good thing. --Tryptofish (talk) 22:35, 5 December 2016 (UTC)[reply]
  18.   Support --Assianir (talk) 07:46, 7 December 2016 (UTC)[reply]
  19.   Support Please fix edit conflicts somehow. 4nn1l2 (talk) 10:09, 7 December 2016 (UTC)[reply]
  20.   Support Yes please. The current solution is so cumbersome that I always just copy my full version out, go to current version, paste, and make manual adjustments. Bacially, there is no functional solution right now.--Elmidae (talk) 15:19, 7 December 2016 (UTC)[reply]
  21.   Support Per proposer and above comments Iadmc (talk) 05:03, 8 December 2016 (UTC)[reply]
  22.   Support - DPdH (talk) 06:36, 8 December 2016 (UTC)[reply]
  23. Strong   Support Miniapolis 21:44, 8 December 2016 (UTC)[reply]
  24.   Support The current interface is extremely frustrating. If I've made many trivial copy edits I sometimes just walk away when I get a conflict. Espresso Addict (talk) 04:11, 9 December 2016 (UTC)[reply]
  25.   Support, but then this would just about eliminate the entire rationale for "Flow" then, wouldn't it? lol -- Wbm1058 (talk) 15:39, 9 December 2016 (UTC)[reply]
  26.   Support Jack who built the house (talk) 19:40, 9 December 2016 (UTC)[reply]
  27.   Support – Rather obvious improvement; let the computer do the leg work of hunting down differences, and the human make the decision of what to keep. JFG (talk) 11:28, 11 December 2016 (UTC)[reply]
  28.   Oppose Editwarring tool. What should matter is what the output is, not who wrote what when.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:49, 11 December 2016 (UTC)[reply]
  29.   Support--Mikheil Talk 21:02, 12 December 2016 (UTC)[reply]

Automated edit suggestions for articles' categories & WikiProjects

  • Problem: Very often all articles being in two specific categories (x & y) are also in a third category (z). Example: all entries that have Category:1964 films & Category:Science fiction films set should also be in Category:1960s science fiction films.
    Furthermore there are categories whose members should all have a specific category set. Example: all members of Category:Science fiction films should have the WP Science Fiction banner set; actually sometimes they are even synonymous (e.g. Category:Internet culture & WP Internet culture). However while from a first glance it looks like this could be fully automated it can not: I tried it out using PetScan for category intersection and found that in many cases one category was set falsely or that it's an exception.
  • Who would benefit: People who would like contribute to Wikipedia via categories & WikiProjects, as well as users & members of said. It would also be very useful for newcomers - they could get acquainted with Wikipedia-editing this way so that at first they only check edit-suggestions and later go on on their own.
  • Proposed solution: A system that allows users to add such category-combination rulesets and make use of said for displaying edit suggestions which can be confirmed, declined or skipped with the click of a button.
  • More comments: This system of edit-suggestions could later be built upon for more than categories and WikiProjects.
  • Phabricator tickets:
  • Proposer: Fixuture (talk) 12:55, 20 November 2016 (UTC)[reply]

Community discussion

none

Voting – Automated edit suggestions for articles' categories & WikiProjects

  1.   Support--Shizhao (talk) 02:40, 28 November 2016 (UTC)[reply]
  2.   Oppose -- Though I support the concept of better tagging of Wikipedia articles, I don't think this should be through the existing Category tools: more conceptual relationships need to be logged into Wikidata, where this data can be used to create categories -- creating more categories first, reinforces a lot of bad data assumptions. Sadads (talk) 14:40, 28 November 2016 (UTC)[reply]
    @Sadads: Why would they need to be "logged into Wikidata"? And how? And why would it reinforce a lot of bad data assumptions? --Fixuture (talk) 21:39, 29 November 2016 (UTC)[reply]
    @Fixuture: Many of the categories that you talk about, are actually "tag/data intersections"-- in that they are intersections of two different concepts, that are true for that particular item, and could also be intersected with other concepts (for example, you should be able to find sets like "Western Films" & 1950s Film & 1960s Films with John Wayne as an actor). If we had to generate a category for every reasonable and interesting query from readers or editors, it becomes a huge labor problem: every new article needs to be checked against 100s of category possibilities, meaning its much more likely to miscategorize the pages. On the other hand, if we work on integrating basic data concepts inito Wikidata, like when a film was produced, its genre, and its actors, and then we empower folks to ask questions of it (or populate a "category" page automatically, instead of having to manually curate it), then we don't have to worry about human error and maintenance of the categories. Sadads (talk) 14:50, 30 November 2016 (UTC)[reply]
    @Sadads: Yes of course they are intersections - I also said that in the description and that's why I linked petscan. Category intersections are one major way how automated suggestions can be created in the first place. Intersecting the categories "Western films" & "1950s films" makes sense if there is a category called "1950s Western films".

    If we had to generate a category for every reasonable and interesting query from readers or editors [...]

  1. Why would we have to do that?!
    It's just that categories such as the ones I named do exist and could be populated semi-automatically. But yes, this data should be added to wikidata (btw the categories should be used for that). I'm still not sure how "creating more categories first, reinforces a lot of bad data assumptions" though. --Fixuture (talk) 20:23, 30 November 2016 (UTC)[reply]
  2.   Oppose For category system newbies, suggestions, whether warranted or not, lead to selections. I am leery of any category suggesting. This should be manual work based on knowledge of the guidelines. I'd rather editors not categorize at all than over-categorize or mis-categorize. I'd much prefer new features that help editors understand the category system. Stevie is the man! Talk • Work 02:41, 1 December 2016 (UTC)[reply]
  3.   Support Daylen (talk) 06:08, 3 December 2016 (UTC)[reply]
  4.   Oppose RileyBugz (talk) 21:59, 7 December 2016 (UTC)[reply]
  5.   Support but with options. The example given shouldn't "also" be in the more specific category, it should be removed from the redundant parent categories. On Wikipedia, anyway. As a general too, it could be configurable differently on different wikis; some prefer redundant/complete categorization.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:52, 11 December 2016 (UTC)[reply]

Auto-merge simple edit-conflicts

  • Problem: Edits to adjacent lines, by different users, should be allowed to SAVE without edit-conflict, rather than require one unchanged line between any edited lines. Also, allow different users to add lines after the same spot, in LIFO order (last-in, first-out), such as first user adds new text "==section==" then 2nd user adds "Furthermore..." comment at same spot which would auto-merge above the new "==section==" in LIFO order (especially valuable in talk-pages where 2 users post after the same message line), as would become no edit-conflict.
  • Who would benefit: Users who edit a busy page with numerous edits near the same lines.
  • Proposed solution: Change the MediaWiki en:diff3 utility to allow separation as zero (0) lines between changed lines. Plus, at added lines, then insert 2nd user's edit-conflict line above prior user's text, but perhaps compare lines to ensure not the same line as merely modified differently by 2 users. A special case rejection might be 2nd user has new text that begins as "==section==" then perhaps deny merge or insert above the next unchanged line (or bottom if no further lines below).
  • More comments: To allow auto-merge at page bottom, perhaps treat end-of-page as an extra blank line, where new text is inserted above that special bottom blank line. Also, the algorithm needs to discern whether a line is "changed" rather than "new" (perhaps by noting subsequent 2 lines are unchanged but current line is altered). The 2-to-5 line lookahead could be implemented by storing several lines from each revision, perhaps as revision bnextline, bnextline2, bnextline3, bnextline4 comparing cnextline, cnextline2, (etc.) but shifted as pointers to text lines. The merge speed is further retained because it only compares next lines when current lines differ. Near end-of-page, zero each subsequent nextline variable so they only compare as same when all revisions end with same text.
As I recall, the auto-merging of 2 edits might require a test-and-set en:resource lock to delay other edits during the auto-merge. Also the improved auto-merge needs to check if some lines were split (as 2 shorter lines) similar to the original line split in half. Plus detect near-match changes, such as 30 characters match at line start, or 30 at end, or 15 characters match at both start+end of split segment. If these ideas scare developers, then perhaps make auto-merge a user option under Special:Preferences, rather than run auto-merge on every edit-conflict across the whole wiki. -Wikid77 (talk) 23:23, 20 November 2016 (UTC)[reply]
Last year, a related wish to reduce edit-conflicts was voted as #11 highest rank for improvements. -Wikid77 (talk) 23:29, 20 November 2016 (UTC)[reply]

Community discussion

#21 in those results was "Reduce edit conflicts by treating different parts of the page as separate" aka Halve edit conflicts.
There have been many detailed suggestions of various means to mitigate edit conflicts, these have been consolidated to the tracking phab phab:T72163 -- Wbm1058 (talk) 16:07, 9 December 2016 (UTC)[reply]

Voting – Auto-merge simple edit-conflicts

  1.   Support Guycn2 · ☎ 17:57, 29 November 2016 (UTC
  2.   Support--Alexmar983 (talk) 05:37, 30 November 2016 (UTC)[reply]
  3.   Support Alexei Kopylov (talk) 09:20, 30 November 2016 (UTC)[reply]
  4.   Support the exploration of a solution for this. This problem really is a common one. Stevie is the man! Talk • Work 02:44, 1 December 2016 (UTC)[reply]
  5.   Support Oliv0 (talk) 18:09, 1 December 2016 (UTC)[reply]
  6.   Support --Grabado (talk) 18:58, 1 December 2016 (UTC)[reply]
  7.   Support At least some investigation could be done. Matěj Suchánek (talk) 21:10, 1 December 2016 (UTC)[reply]
  8.   Support Gryllida 23:55, 1 December 2016 (UTC)[reply]
  9.   Support per Stevie—support putting this on the radar for a solution, regardless of whether any solution proposed is the right one czar 01:46, 2 December 2016 (UTC)[reply]
  10.   Support Draceane (talk) 10:02, 2 December 2016 (UTC)[reply]
  11.   Support // Martin Kraft (talk) 00:00, 3 December 2016 (UTC)[reply]
  12.   Support--Ranjithsiji (talk) 06:08, 4 December 2016 (UTC)[reply]
  13.   Support -- KylieTastic (talk) 19:25, 5 December 2016 (UTC)[reply]
  14.   Support As I said in another proposal in this section, I don't know what will work technically, but I'd like to see a way to clear up edit conflicts. --Tryptofish (talk) 22:38, 5 December 2016 (UTC)[reply]
  15.   Support -- Amanda (aka DQ) 20:56, 6 December 2016 (UTC)[reply]
  16.   Support Ks0stm (T•C•G) 21:10, 6 December 2016 (UTC)[reply]
  17.   Support No edit conflicts. 4nn1l2 (talk) 10:23, 7 December 2016 (UTC)[reply]
  18.   Support Iadmc (talk) 05:04, 8 December 2016 (UTC)[reply]
  19.   Support - DPdH (talk) 06:38, 8 December 2016 (UTC)[reply]
  20.   Support If this were feasible it would be time saving. Espresso Addict (talk) 04:08, 9 December 2016 (UTC)[reply]
  21.   Support, but then this would just about eliminate the entire rationale for "Flow" then, wouldn't it? lol -- Wbm1058 (talk) 16:13, 9 December 2016 (UTC)[reply]
  22.   Support --LikeLifer (talk) 16:24, 9 December 2016 (UTC)[reply]
  23.   Support Jack who built the house (talk) 19:33, 9 December 2016 (UTC)[reply]
  24.   Support --g (talk) 11:30, 10 December 2016 (UTC)[reply]
  25.   Support Another improvement that should have been done years ago. Reguyla (talk) 18:49, 10 December 2016 (UTC)[reply]
  26.   Support Flow234 (talk) 21:15, 12 December 2016 (UTC)[reply]

Auto-saving edits

  • Problem: At times, a web browser will crash causing an editor to lose their progress
  • Who would benefit: Wikimedia editors with a unstable Wi-Fi connection and/or software which has bugs, causing their web browser to crash
  • Proposed solution: Auto-saving edits for users that are logged in; putting them under a drafts tab at the top of the screen.
  • Phabricator tickets: phabricator:T75241
  • Proposer: Daylen (talk) 03:29, 15 November 2016 (UTC)[reply]

Community discussion

  • This would benefit me considerably; my work ends up lost frequently due to battery loss, accidental browser closure, programs freezing, etc., and the only tool I'm aware of is Lazarus, which doesn't seem to work for my preferred browser. Ɱ (talk) 05:56, 15 November 2016 (UTC)[reply]
  • Early edit-preview helps recover crashed edit: Many browsers save an in-progress copy of an edit-session during each edit-preview, and could recover minutes or hour later after recharge of device battery. I think there is a Special:Preferences option to force edit-preview at start of each edit, but also user should do periodic edit-preview to re-cache the recent work. -Wikid77 (talk) 23:04, 20 November 2016 (UTC)[reply]
  • Chrome has kept my drafts between accidental page navigation, browser and computer crashes, etc. Would lead me to believe that this has been considered already, but not sure how much of this is strictly browser issues czar 01:47, 2 December 2016 (UTC)[reply]

Voting – Auto-saving edits

  1.   Support ChristianKl (talk) 16:18, 29 November 2016 (UTC)[reply]
  2.   Support Guycn2 · ☎ 17:57, 29 November 2016 (UTC)[reply]
  3.   Support --Mikey641 (talk) 18:28, 29 November 2016 (UTC)[reply]
  4.   Support --Telaneo (User talk page) 21:32, 29 November 2016 (UTC)[reply]
  5.   Support, if it's not already possible. Until then there's the Lazarus: Form Recovery browser extension for Chrome & Firefox. --Fixuture (talk) 21:43, 29 November 2016 (UTC)[reply]
  6.   Support --Nikola (talk) 21:58, 29 November 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 00:07, 30 November 2016 (UTC)[reply]
  8.   Support--Alexmar983 (talk) 05:36, 30 November 2016 (UTC)[reply]
  9.   Support --Yurik (talk) 08:58, 30 November 2016 (UTC)[reply]
  10.   Support Alexei Kopylov (talk) 09:21, 30 November 2016 (UTC)[reply]
  11.   Support --Gnom (talk) 09:42, 30 November 2016 (UTC)[reply]
  12.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 02:46, 1 December 2016 (UTC)[reply]
  13.   Support I can see the value of this, although it should be opt-in. Stevie is the man! Talk • Work 02:47, 1 December 2016 (UTC)[reply]
  14.   Oppose as obsolete. Recent browsers recover more edits, and some mobile phones will power-down at low battery quick enough to save all windows/tabs, but user should periodically run edit-preview or even save partial edit to sandbox version or quicknote (to allow more hours to develop text), rather than rush-to-save partial as live version, for fear of crashed edits. -Wikid77 (talk) 07:20, 1 December 2016 (UTC)[reply]
    Hi Wikid77! Browsers with auto-save are great; however, not everyone has access to a device with the latest technology. This proposal would fix the problem for the majority of users! It would also allow users to opt-out in settings. Daylen (talk) 04:08, 6 December 2016 (UTC)[reply]
  15.   Support (One of the reasons I'm reluctant to use VE, by the way; with the "classic" editor, Lazarus has me covered in these cases) — Pajz (talk) 12:06, 1 December 2016 (UTC)[reply]
  16.   Support Ahm masum (talk) 17:32, 1 December 2016 (UTC)[reply]
  17.   Oppose Editors should be able to check their edits before saving, autosaving or not. If implemented, it should be opt-in only. Beagel (talk) 18:14, 1 December 2016 (UTC)[reply]
    Beagel: the proposal is not meant to automatically save the page into Wikipedia. It is meant to automatically save the page somewhere in your account where only the user has access, something like the draft folder of Gmail, so that you can restart working on the article later, and when you're done, save the page into Wikipedia for real. --Una giornata uggiosa '94 · So, what do you want to talk about? 19:48, 2 December 2016 (UTC)[reply]
  18.   Support Ermahgerd9 (talk) 18:36, 1 December 2016 (UTC)[reply]
  19.   Oppose For the same grounds as User:Beagel. The user needs to retain control about the material which is published. Remember, the material once published under CC-BY-SA licence cannot be retracted. --Vachovec1 (talk) 19:35, 1 December 2016 (UTC)[reply]
    Hi Vachovec1! These drafts would be stored under a private page for each user, and not automatically appear on the public site. A drafts tab would appear on the top right corner of the screen for registered editors. I hope this clears up the confusion! Daylen (talk) 04:08, 6 December 2016 (UTC)[reply]
  20.   Support but store it client-side only using javascript - not on server (privacy/licensing issues, maybe I mispasted my home address or credit card number into my draft by mistake) Gryllida 23:57, 1 December 2016 (UTC)[reply]
  21.   Support Libcub (talk) 02:43, 2 December 2016 (UTC)[reply]
  22.   Oppose Jmvkrecords ⚜ (Intra talk) 08:03, 2 December 2016 (UTC). Per Vachovec1[reply]
    Hi Jmvkrecords! These drafts would be stored under a private page for each user, and not automatically appear on the public site. A drafts tab would appear on the top right corner of the screen for registered editors. I hope this clears up the confusion! Daylen (talk) 04:08, 6 December 2016 (UTC)[reply]
    Hi Daylen! If you are working on an online draft and there is an interruption of the Wi-Fi connection, the draft can not be saved online or you will not be able to consult it offline. Some programs like Chrome or Office already safeguard periodically your work and also allow you to work in wiki format. Also, it seems to me that this tool may be an extreme use of resources. Jmvkrecords ⚜ (Intra talk) 05:49, 6 December 2016 (UTC).[reply]
  23.   Support However I agree with the restrictions suggested by Gryllida. Emir of Wikipedia (talk) 15:17, 2 December 2016 (UTC)[reply]
  24.   Support --Framawiki (talk) 20:32, 2 December 2016 (UTC)[reply]
  25.   Support --My Chemistry romantic (talk) 03:04, 3 December 2016 (UTC)[reply]
  26.   Support Daylen (talk) 05:49, 3 December 2016 (UTC)[reply]
  27.   Support Jianhui67 talk★contribs 10:05, 3 December 2016 (UTC)[reply]
  28.   Support--Ranjithsiji (talk) 06:08, 4 December 2016 (UTC)[reply]
  29.   Support --By erdo can (talk) 14:20, 4 December 2016 (UTC)[reply]
  30.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  31.   Neutral I'm concerned that making sure that the edits are saved only for the editor, rather than prematurely entered into the actual page that readers see, will slow down performance. --Tryptofish (talk) 22:43, 5 December 2016 (UTC)[reply]
  32.   Oppose any server-side solution per [1] and [2]. MER-C (talk) 03:05, 6 December 2016 (UTC)[reply]
  33.   Support Ks0stm (T•C•G) 21:10, 6 December 2016 (UTC)[reply]
  34.   Support -- Movses (talk) 08:55, 7 December 2016 (UTC)[reply]
  35.   Comment There must be a way to opt-out as in LMICs (low and middle-income countries) Internet is usually offered in limited data packages. 4nn1l2 (talk) 10:36, 7 December 2016 (UTC)[reply]
  36.   Oppose per MER-C. This will create serious issues regarding management of these drafts: they have to be stored somewhere on our servers and there have to a completely new procedure on deletion of these drafts (as many of them will be unwanted, such as failed attempts to fix some page) — NickK (talk) 18:58, 7 December 2016 (UTC)[reply]
  37.   Weak support in principle. It seems like there are many ways to go about this. Maybe just having reused pages in one's own userspace for each open editing window, or possibly even using a cookie? Seems like an interesting possibility for an opt-in tool. — Rhododendrites talk \\ 06:15, 8 December 2016 (UTC)[reply]
  38.   Support - There surely are significant number of users with older browsers, so a recovery function would be helpful. DPdH (talk) 06:41, 8 December 2016 (UTC)[reply]
  39.   Support -- Akela (talk) 21:47, 8 December 2016 (UTC)[reply]
  40.   Support Whats new? (talk) 22:43, 8 December 2016 (UTC)[reply]
  41.   Support Miniapolis 22:47, 8 December 2016 (UTC)[reply]
  42.   Support although I would also propose it active by default, with an option to opt out. Exoplanetaryscience (talk) 04:10, 10 December 2016 (UTC)[reply]
  43.   Support (but only as a reversible opt-in feature) --g (talk) 11:32, 10 December 2016 (UTC)[reply]
  44.   Support, implemented with personal drafts. --NaBUru38 (talk)
  45.   Support Ale And Quail (talk) 05:15, 11 December 2016 (UTC)[reply]
  46.   Support --Helium4 (talk) 08:20, 11 December 2016 (UTC)[reply]
  47.   Oppose – This would certainly be a useful feature, however as noted by other commenters, this is a client-side issue, which most browsers already handle gracefully. No need to invest foundation resources into this (development time or operations overload). JFG (talk) 10:41, 11 December 2016 (UTC)[reply]
  48.   Support --  AnselmiJuan (discusión) 12:08, 11 December 2016 (UTC)[reply]
  49.   Oppose There are already browser add-ons for this. Try Lazarus.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:52, 11 December 2016 (UTC)[reply]
    SMcCandlish, Lazarus is only available for Firefox and Chrome desktop versions. That still leaves out many editors.
  50.   Support Client-side saving would be great. Quiddity (talk) 06:30, 12 December 2016 (UTC)[reply]
  51.   Support would be useful on my computer as chrome does not autosave and i cant downloand Lazarus as the computer i have does not allow downloading Flow234 (talk) 21:17, 12 December 2016 (UTC)[reply]

Blame-like feature - who wrote a phrase, when, and why

  • Problem: Incremental changes can transform an article in various ways, to the point that the meaning of a given phrase is obscured. It helps to recover the context when the phrase was written. However, navigating back and forth through the history page (en:Weierstrass method) is the only available means.
  • Who would benefit: Editors cleaning up overburdened pages, especially when authors use different variants of English, can better assess the value/scope of a phrase if they can see what the page was like when the phrase was added, and the edit summary the author wrote at the time.
  • Proposed solution: If a phrase is selected when view history is hit, display only the entries which regard the selected text.
  • More comments: This achieves some of the purposes of 2016 Community Wishlist Survey/Categories/Reading#Display the authorship of a Wikipedia page, but is less prone to gaming.
  • The subversion solution, to display all attributions at once, works better for line-oriented text. However, it may be helpful to also have a means to visualize what passages are more often edited (e.g. by color, like historical GPLv3 drafts.)
  • Phabricator tickets: Phab:T2639
  • Proposer: Ale2006 (talk) 09:09, 14 November 2016 (UTC)[reply]

Community discussion

Voting – "edit blame"-like feature — who wrote a phrase, when, and why

  1.   Support. Samwalton9 (talk) 09:08, 28 November 2016 (UTC)[reply]
  2.   Support Léna (talk) 11:12, 28 November 2016 (UTC)[reply]
  3.   Support שי אבידן (talk) 13:25, 29 November 2016 (UTC)[reply]
  4.   Support  @xqt 13:55, 29 November 2016 (UTC)[reply]
  5.   Support ChristianKl (talk) 16:19, 29 November 2016 (UTC)[reply]
  6.   Support --YMS (talk) 16:35, 29 November 2016 (UTC)[reply]
  7.   Support --Mikey641 (talk) 18:29, 29 November 2016 (UTC)[reply]
  8.   Support --Telaneo (User talk page) 21:33, 29 November 2016 (UTC)[reply]
  9.   Support --Alex Blokha (talk) 23:13, 29 November 2016 (UTC)[reply]
  10.   Support I like this idea, although I think naming it "blame" could potentially give some negative connotations. Although, I'm not sure what else it could be named, so I'll try to think about it :) SamanthaNguyen (talk) 01:58, 30 November 2016 (UTC)[reply]
    WP:WikiCredit to give proper credit for good, positive content additions -- Wbm1058 (talk) 04:57, 30 November 2016 (UTC)[reply]
  11.   Support Alexei Kopylov (talk) 09:08, 30 November 2016 (UTC)[reply]
  12.   Neutral but only because we have WikiBlame to use for now. I'd rather have the WMF not work on an alternative (even if a better one) to a tool that already exists when there are so many other worthwhile projects to take on. Stevie is the man! Talk • Work 03:05, 1 December 2016 (UTC)[reply]
  13.   Oppose per Stevietheman. There are higher priorities than this. MER-C (talk) 10:36, 1 December 2016 (UTC)[reply]
  14.   Oppose, per Stevietheman. — Pajz (talk) 12:07, 1 December 2016 (UTC)[reply]
  15.   Support --Grabado (talk) 18:59, 1 December 2016 (UTC)[reply]
  16.   Support Doc James (talk · contribs · email) 03:45, 3 December 2016 (UTC)[reply]
  17.   Support Please. ImperfectlyInformed (talk) 18:32, 4 December 2016 (UTC)[reply]
  18.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  19.   Support ArgonSim (talk) 19:45, 5 December 2016 (UTC)[reply]
  20.   Oppose We can already examine the edit history, and I'm not convinced that the added convenience would justify adding this. I'm also worried that this could make it easier for one editor to follow and harass another editor. --Tryptofish (talk) 22:46, 5 December 2016 (UTC)[reply]
    Tryptofish, examining the edit history is very difficult on high-activity pages, and frankly very time-consuming. Neither do I see your issue with harassment, because that is already possible by simply going through user contributions. This is far more likely to strike bad content and to weed out nefarious vandals who add "almost true" or plausible falsehoods. CFCF 💌 📧 20:37, 7 December 2016 (UTC)[reply]
    Thanks for the ping. It seems to me that if it speeds up finding information from the edit history, it will speed up tracking another editor for harassment. One can't have it both ways. Balancing harassment concerns against content concerns certainly is one of the thorniest issues that WM projects are going to face (cf paid editing versus outing). --Tryptofish (talk) 00:01, 8 December 2016 (UTC)[reply]
  21.   Support I think this would help a lot for discussing edits and finding who wrote what, I do agree though that it can be used to harass other users, maybe make it a gadget or only available to registered users? -glove- (talk) 18:22, 6 December 2016 (UTC)[reply]
  22.   Oppose Web interface works fine, we have bigger priorities. -- Amanda (aka DQ) 20:58, 6 December 2016 (UTC)[reply]
  23.   Support as I could not work with WikiBlame in Persian Wikipedia. 4nn1l2 (talk) 10:48, 7 December 2016 (UTC)[reply]
  24.   Support--Elmidae (talk) 15:35, 7 December 2016 (UTC)[reply]
  25.   Support — NickK (talk) 18:59, 7 December 2016 (UTC)[reply]
  26.   Support — Utterly necessary to track down copyvio, poor content and to make sure that this kind of thing stays off Wikipedia. Currently we have no good way of seeing who added poor content if it's been more than say 20 revisions ago... CFCF 💌 📧 20:34, 7 December 2016 (UTC)[reply]
  27.   Support — Rhododendrites talk \\ 06:16, 8 December 2016 (UTC)[reply]
  28.   Support - DPdH (talk) 06:43, 8 December 2016 (UTC)[reply]
  29.   Support —Ynhockey (talk) 11:49, 8 December 2016 (UTC)[reply]
  30.   Support Miniapolis 22:50, 8 December 2016 (UTC)[reply]
  31.   Support Often I find information that feels wrong but isn't clear vandalism and then spend ~20 mins going through months or even years of edit history to find who added/amended it. Espresso Addict (talk) 04:05, 9 December 2016 (UTC)[reply]
  32.   Support OrsolyaVirág (talk) 12:55, 10 December 2016 (UTC)[reply]
  33.   Support Ale And Quail (talk) 05:09, 11 December 2016 (UTC)[reply]
  34.   Support This would be extremely useful, gaining time and clarity to help editors resolve disputes or understand complex page history. As an aside, I always wondered why Wikipedia hasn't switched to a git backend, which would make this a breeze. Given that the natural unit of information in Mediawiki is the diff, not the article, the git structure is a perfect fit. JFG (talk) 10:37, 11 December 2016 (UTC)[reply]
  35.   Support Strong support; all serious community development projects have this, except WP I guess. Just don't call it "blame". That's funny in hackish jargon, but will be off-putting outside that subculture.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:40, 11 December 2016 (UTC)[reply]
  36.   Support Will be of great help, especially in cleaning up heavily edited pages. Uanfala (talk) 23:25, 11 December 2016 (UTC)[reply]
  37.   Support --Malyacko (talk) 18:46, 12 December 2016 (UTC)[reply]

Build disambiguation test into preview (text editor)

  • Problem: When editing I sometimes link to an disambiguation page end only after submitting i get a PM warning that I linked to such a page.
    I would like to be warned about this when previewing (preference) or by submitting of the edit
  • Who would benefit: Editors
  • Proposed solution: During preview or submitting from edits give warning about links to disambiguation pages
  • More comments: Maybe we can even add more tests to the preview or submitting.
    Editors must have to option to bypass the warning.( so submit an edit with links to disambiguation pages)
  • Phabricator tickets:
  • Proposer: WillemienH (talk) 00:02, 15 November 2016 (UTC)[reply]

Community discussion

  • I support this. I hate to get bot notices about disambiguation at my Talk page but I would be happy to see a notice about disambiguation on-screen when I preview or submit an edit. I hate to get bot notices at my Talk page about almost any other topic, too, partly because they seem to be trying to shame me in front of all other editors, and the information is usually not timely anyhow (e.g. I have already done the necessary disambiguation in another edit, while still working on the given article and seeing that my first edit didn't accomplish what I wanted). --Doncram (talk) 08:11, 15 November 2016 (UTC)[reply]
  • Please include links to redirects in this as well. Bcharles (talk) 21:34, 15 November 2016 (UTC)[reply]
  • One way to handle this would be to have links to disambiguation pages, and links to redirect pages, be a different color, plus a tooltip that makes clear that a disambiguation page or redirect page was at that link. Maybe purple for the disambiguation page, and yellow for the redirect? [And, yes, I realize that colors aren't helpful for those with visual issues, but if this change can help only 95% of editors, it's worth doing.] Why colors? Because neither the wikitext editor nor the VE is designed to display errors - of any kind - during a preview; VE only generates error messages during dialogs. -- John Broughton (talk) 00:07, 17 November 2016 (UTC)[reply]
  • You guys need to install Navigation popups. And then some custom installation, see en:User talk:Wbm1058/Archive 3#Disambiguation links, once that's done you can forget it. Maybe this can be the default installation for all editors? This is one of three "top icons" I have on my user page: my must have tools (the other two are AutoWikiBrowser and HotCat). Anyhow, once you've got that installed, problem solved. Wbm1058 (talk) 05:14, 18 November 2016 (UTC)[reply]
Is this available in all languages? I definitely like the idea of having a default option. --Tbennert (talk) 07:00, 26 November 2016 (UTC)[reply]
Maybe a stop-gap solution would be to include this gadget link with the disamb notice? We'd still get the notice but then be given a solution to avoid the problem, and notice, again. Finding gadgets can be a pain. Easier means more people find and use this one. Thanks! --Tbennert (talk) 07:00, 26 November 2016 (UTC)[reply]
Good idea. I just added this gadget to the en:User:DPL bot/Dablink notification FAQ that's linked from the existing notice. —Patrug (talk) 22:33, 1 December 2016 (UTC)[reply]

Voting – Build disambiguation test into preview (text editor)

  1.   Support JAn Dudík (talk) 21:43, 28 November 2016 (UTC)[reply]
  2.   Support --Izno (talk) 00:13, 29 November 2016 (UTC)[reply]
  3.   Support --Aracali (talk) 02:05, 29 November 2016 (UTC)[reply]
  4.   Oppose, already implemented - see User:Quiddity (WMF)'s comment above. The same thing is still needed for redirects though. --Fixuture (talk) 21:45, 29 November 2016 (UTC)[reply]
  5.   Oppose per Fixuture. Solutions already exist. Port to other wikis if they don't have them. Stevie is the man! Talk • Work 02:52, 1 December 2016 (UTC)[reply]
  6.   Support Libcub (talk) 02:45, 2 December 2016 (UTC)[reply]
  7.   Oppose per Fixture/Quiddity. --JJBers (talk) 03:37, 2 December 2016 (UTC)[reply]
  8.   Support Draceane (talk) 10:03, 2 December 2016 (UTC)[reply]
  9.   Support'ish. We have the information, should be easy to use this at least for the link insertion inspectors of wikieditor and VE. —TheDJ (talk • contribs) 10:20, 2 December 2016 (UTC)[reply]
  10.   Support -- SBaker43 (talk) 23:31, 2 December 2016 (UTC)[reply]
  11.   Support -- I would go further and suggest likely solutions to the most common instances, based on the formula currently used in the dabsolver. If you're writing an article on a rock band and you link "heavy metal", chances are slim that you mean the chemical sense of it. BD2412 T 04:09, 5 December 2016 (UTC)[reply]
  12.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  13.   Oppose, no need for Community Tech actions here. Such gadgets already exist and may be turned on for everyone if there is a community consensus. For example, Ukrainian Wikipedia had a similar gadget, uk:MediaWiki:Gadget-DisambigHili.css, implemented by default — NickK (talk) 19:08, 7 December 2016 (UTC)[reply]
  14.   Support - DPdH (talk) 06:55, 8 December 2016 (UTC)[reply]
  15.   Support Miniapolis 22:57, 8 December 2016 (UTC)[reply]
  16.   Support --Ydb2 (talk) 10:08, 9 December 2016 (UTC)[reply]
  17.   Support--LikeLifer (talk) 16:27, 9 December 2016 (UTC)[reply]
  18.   Support warning,   Oppose blocking. --NaBUru38 (talk)
  19.   Support -- but wording needs to be super-clear, to help newbies who havent a clue about dab pages. PamD (talk)
  20.   Support – This should be a no-brainer. I'm not sure why it's not getting more support... IJBall (talk) 19:13, 11 December 2016 (UTC)[reply]

Category move should also move stuff inside that category

  • Problem: Whenever we do a category move, we need a bot or some time to move the articles or other stuff inside it.
  • Who would benefit: All editors.
  • Proposed solution: Maybe a server-run bot like FuzzyBot for the Translate extension who detects the moves and goes around changing the categories for us. This will require that the right to move categories be only assigned to trusted users to avoid misuse of this.
  • Phabricator tickets:
  • Proposer: —MarcoAurelio 12:23, 17 November 2016 (UTC)[reply]

Community discussion

w:fr:MediaWiki:Gadget-RenommageCategorie.js does this job on a few wikis for several years. JackPotte (talk) 22:41, 17 November 2016 (UTC)[reply]

Voting – Category move should also move stuff inside that category

  1.   Support —MarcoAurelio 15:12, 28 November 2016 (UTC)[reply]
  2.   Support with some safeguards. I'm not sure a new right is necessary, but at the very least there should be a time buffer between the category move and the system action to move the category belongings, in case someone sees fit to revert the move. Stevie is the man! Talk • Work 15:40, 28 November 2016 (UTC)[reply]
  3.   Support Seems like a useful option to have, but I some discussion needs to take place on how to safeguard its use, per the above. Samwalton9 (talk) 16:01, 28 November 2016 (UTC)[reply]
  4.   Support Lsanabria (talk) 19:34, 28 November 2016 (UTC)[reply]
  5.   Support IKhitron (talk) 12:06, 29 November 2016 (UTC)[reply]
  6.   Support שי אבידן (talk) 13:26, 29 November 2016 (UTC)[reply]
  7.   Support StevenJ81 (talk) 17:38, 29 November 2016 (UTC)[reply]
  8.   Support Guycn2 · ☎ 17:59, 29 November 2016 (UTC)[reply]
  9.   Support --Telaneo (User talk page) 21:33, 29 November 2016 (UTC)[reply]
  10.   Support, afaik currently there's people watching category moves that then use cat-a-lot to move all their entries (this script in particular). --Fixuture (talk) 21:54, 29 November 2016 (UTC)[reply]
  11.   Support--Strainu (talk) 09:39, 30 November 2016 (UTC)[reply]
  12.   Support Sadads (talk) 14:41, 30 November 2016 (UTC)[reply]
  13.   Support Chandra Varena (talk) 14:55, 30 November 2016 (UTC)[reply]
  14.   Support --β16 - (talk) 15:40, 1 December 2016 (UTC)[reply]
  15.   Support if necessary safeguards per Stevie is the man! and Samwalton9 are implemented. Beagel (talk) 18:18, 1 December 2016 (UTC)[reply]
  16.   Support I have experienced the pain of moving articles in a category firsthand. This would be great! --AmaryllisGardener talk 18:59, 1 December 2016 (UTC)[reply]
  17.   Support --Grabado (talk) 19:00, 1 December 2016 (UTC)[reply]
  18.   Support as an option to the feature → «« Man77 »» [de] 22:29, 1 December 2016 (UTC)[reply]
  19.   Support —Patrug (talk) 22:37, 1 December 2016 (UTC)[reply]
  20.   Support Libcub (talk) 02:46, 2 December 2016 (UTC)[reply]
  21.   Oppose Jmvkrecords ⚜ (Intra talk) 08:08, 2 December 2016 (UTC). In one clic you can vandalize hundred of articles.[reply]
  22.   Support Daylen (talk) 05:48, 3 December 2016 (UTC)[reply]
  23.   Support Jo-Jo Eumerus (talk, contributions) 09:40, 3 December 2016 (UTC)[reply]
  24.   Support--Ranjithsiji (talk) 06:09, 4 December 2016 (UTC)[reply]
  25.   Support Gareth (talk) 11:14, 4 December 2016 (UTC)[reply]
  26.   Support --Yeza (talk) 13:02, 4 December 2016 (UTC)[reply]
  27.   Oppose per Jmvkrecords. But I'd support making a tool that would require a specific right maybe?--Dixtosa (talk) 15:13, 4 December 2016 (UTC)[reply]
  28.   Support But how will this work with templates? --MGChecker (talk) 15:58, 4 December 2016 (UTC)[reply]
  29.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  30. Cautious   Support, with the caveats about safeguards raised above by other editors. Not something that an inexperienced editor should be able to do without safeguards. --Tryptofish (talk) 22:51, 5 December 2016 (UTC)[reply]
  31.   Support with a safeguard. --SuperJew (talk) 19:29, 6 December 2016 (UTC)[reply]
  32.   Support Rdrozd (talk) 22:30, 6 December 2016 (UTC)[reply]
  33.   Support --Geolina163 (talk) 09:02, 7 December 2016 (UTC)[reply]
  34.   Support 4nn1l2 (talk) 10:54, 7 December 2016 (UTC)[reply]
  35.   Oppose, this can and should be done by a bot, although with a certain delay. The proposal as is will createa new vandalism type: imagine a vandal moving en:Category:All stub articles with 2M of pages having to be updated immediately — NickK (talk) 19:11, 7 December 2016 (UTC)[reply]
  36.   Support, with qualifications. I agree that the potential for disruption and vandalism exists, but that's not a reason to not go ahead with something that would improve Wikipedia process and reduce the amount of time involved in category editing; it's a reason to find a way to address that concern in the process of implementing the solution. Bearcat (talk) 18:15, 8 December 2016 (UTC)[reply]
  37.   Support Amir (talk) 18:27, 8 December 2016 (UTC)[reply]
  38.   Support Miniapolis 22:58, 8 December 2016 (UTC)[reply]
  39.   Support Ivi104 (talk) 12:14, 9 December 2016 (UTC)[reply]
  40.   Support--LikeLifer (talk) 16:29, 9 December 2016 (UTC)[reply]
  41.   Support God yes. --Waldir (talk) 11:10, 10 December 2016 (UTC)[reply]
  42.   Oppose per Jmvkrecords --g (talk) 11:38, 10 December 2016 (UTC)[reply]
  43.   Support OrsolyaVirág (talk) 12:56, 10 December 2016 (UTC)[reply]
  44.   Support but this really only applies to admins I think since I believe only admins can move categories. There does need to be something in place to prevent someone from moving very large categories though. Reguyla (talk) 18:51, 10 December 2016 (UTC)[reply]
  45.   Support--Plogeo (talk) 19:57, 10 December 2016 (UTC)[reply]
  46.   Support as optional. --NaBUru38 (talk)
  47.   Support --Plagiat (talk) 17:25, 11 December 2016 (UTC)[reply]
  48.   Support Should have been done this way originally.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:41, 11 December 2016 (UTC)[reply]
  49.   Support provided this is technically feasible and suitable restrictions on use are imposed upon implementation. Uanfala (talk) 23:27, 11 December 2016 (UTC)[reply]
  50.   Support--Mikheil Talk 21:03, 12 December 2016 (UTC)[reply]
  51.   Support Samat (talk) 23:19, 12 December 2016 (UTC)[reply]

Easy way to find last reviewed version

  • Problem: Wikipedia has several levels of article review (featured article, good article, assessed article). I'm not aware of any easy way to find the version of the article that passed review. I would like to be able to see the diff between the final reviewed version and the current version, or, better, any other version. Without such a capability, reviews are almost meaningless. ("You are now reading an article that may bear some resemblance to an article that was carefully scrutinized -- or it may not."
  • Who would benefit: Users who see that an article has passed some level of review and would like to know what has changed since that review was completed.
  • Proposed solution: One possible solution might be a button on the history page that would take you to the history entry where the article was last approved. One could then diff to any other version, with the current as default. Ideally the solution would b flexible enough to support other forms of review that may not have even been established yet.
  • Phabricator tickets:
  • Proposer: ArnoldReinhold (talk) 01:54, 21 November 2016 (UTC)[reply]

Community discussion

Voting – Easy way to find last reviewed version

  1.   Support Anthonyhcole (talk) 02:56, 29 November 2016 (UTC)[reply]
  2.   Support Alexei Kopylov (talk) 09:10, 30 November 2016 (UTC)[reply]
  3.   Support as a worthwhile and perhaps not difficult idea to implement. Stevie is the man! Talk • Work 19:39, 30 November 2016 (UTC)[reply]
  4.   Support --Gerwoman (talk) 18:39, 1 December 2016 (UTC)[reply]
  5.   Oppose At least on English Wikipedia, this already seems to exist. For a case like en:OPEC, the Good Article approval added a banner to the top of the Talk page. One click on the milestone date brings you to the Listed version of the article. One click from there gives you the Latest revision (diff). —Patrug (talk) 22:50, 1 December 2016 (UTC)[reply]
  6.   Support --Haku (talk) 23:59, 1 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 02:47, 2 December 2016 (UTC)[reply]
  8.   Support --Continua Evoluzione (talk) 14:18, 2 December 2016 (UTC)[reply]
  9.   Support --Ranjithsiji (talk) 06:10, 4 December 2016 (UTC)[reply]
  10.   Support 4nn1l2 (talk) 10:57, 7 December 2016 (UTC)[reply]
  11.   Support - DPdH (talk) 13:09, 8 December 2016 (UTC)[reply]
  12.   Neutral Don't some wikis use the system for pending changes that requires anons'/newbies' changes to be reviewed? Matěj Suchánek (talk) 20:45, 11 December 2016 (UTC)[reply]

Editor-focused central editing dashboard

  • Problem: I imagine that for most users (this is certainly the case for me) that Special:Watchlist is the default editing home page - it's where I click back to after editing a page to see what the latest changes to pages I'm interested in are. It serves as my launching off point for editing during the majority of my editing sessions. The Watchlist is a limited view of what's happening on the encyclopedia, however. Pages such as Special:RecentChanges, Special:PendingChanges, Special:NewPages, and Special:Notifications are all also useful pages that editors may find it valuable to check on, but these are spread out around the encyclopedia and not accessible from one location.
  • Who would benefit: All users
  • Proposed solution: The creation of an editor-focused dashboard, which would serve as editors' home page for editing Wikipedia. It could be customisable to include different Special pages (with the option to have them auto-update) such as those listed above. It could also have features such as a notepad and/or to-do list, and MediaWiki:Watchlist-details could be posted there instead of / as well as Special:Watchlist.
  • More comments: As well as the benefits for established editors, I have a suspicion that the lack of a truly useful and intuitive central place for editors to go to start an editing session may contribute to editor retention issues; "just go edit" isn't particularly useful to a new editor, but "go to your dashboard and see if anything catches your eye in RecentChanges, NewPages, etc." might.
  • Phabricator tickets: T91655
  • Proposer: Samwalton9 (talk) 11:37, 13 November 2016 (UTC)[reply]

Community discussion

  • This sounds useful especially for the "power editor". I guess implementing this depends on how many editors would definitely make use of it vs. the required development resources. Stevie is the man! Talk • Work 17:46, 13 November 2016 (UTC)[reply]
  • You're right. Sometimes I just want to know "what's new", why can't I have a single customized interface to control that?--Alexmar983 (talk) 06:02, 14 November 2016 (UTC)[reply]
  • In favor, though I would suggest scoping this to building an 'initial prototype' instead, because i think you would need several iterations to get this where you would want it to be. —TheDJ (talk • contribs) 21:06, 14 November 2016 (UTC)[reply]
  • It's true that some of the recent special pages were poorly designed and hardly integrated with the established ones; but I don't see a problem in Special:RecentChanges and its filtered views Special:Watchlist/Special:NewPages. The first step to improve the situation is to abolish all extensions which don't respect mw:Everything is a wiki page. Nemo 08:03, 15 November 2016 (UTC)[reply]
  • Collaboration Team is prototyping a powerful new filtering interface that adds ORES and other tools to Recent Changes (here's a video demo). The new tools will debut on the Recent Changes, but we assume people will want them on the other pages mentioned here as well. In researching this, it's struck me, too, that it would be relatively simple to collapse the scattered array of special-purpose pages into one central edit-review page. Doing so feels more logical, efficient and discoverable. I do worry about taking away pages people are used to, though—particularly Watchlist. How valid is that concern, do you think? JMatazzoni (WMF) (talk) 00:26, 17 November 2016 (UTC)[reply]
    @JMatazzoni (WMF): I don't see a need to replace the Special pages with this dashboard, for a few reasons. First, I doubt that every user will want to use this rather than the individual pages, and we shouldn't force them to. More importantly, though, I see the dashboard as being customisable, such that users could tailor the pages they transclude there for their editing style, and ideally you would be able to put things other than Special pages there. In a broader sense it should be modular (perhaps including the ability for editors to design their own modules for individual wikis!). Here are some examples:
  • I might want to transclude my Watchlist, Recent Changes, Pending Changes (because I have the user right to be able to accept or reject them), and the Abuse Log (because I work on abuse filters). I might also want something related to the number of speedy deletion tags currently placed (i.e. the number of pages in Category:Candidates for speedy deletion), or the number of Articles for Deletion discussions ongoing.
  • An editor focused on anti-vandal efforts might rather have their Watchlist alongside two Recent Changes windows, one showing everything and one filtered using ORES, and the new pages feed. But if they don't have pending changes user rights they might not want that, and they may not be interested in modules like the to-do list.
  • A content creator might only want their Watchlist alongside a list of their created articles, they may also have a to-do list and an open edit window to a sandbox or subpage for placing notes. Samwalton9 (talk) 10:55, 17 November 2016 (UTC)[reply]

Samwalton9, just a heads-up -- I moved your proposal to this page. -- DannyH (WMF) (talk) 20:21, 23 November 2016 (UTC)[reply]

  • "ORES and other tools" seems interesting, but we'll have to see them in action to see how effective they are as filters in the real world. Garbage in, garbage out, as they say. But the user interface looks slick. Wbm1058 (talk) 15:25, 4 December 2016 (UTC)[reply]
  • It's not hard to build your own dashboard (BYOD). What I need is better tools for leveraging my time to fix issues that have already been identified. Wbm1058 (talk) 15:25, 4 December 2016 (UTC)[reply]

Voting – Editor-focused central editing dashboard

  1.   Support--Shizhao (talk) 02:41, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:00, 28 November 2016 (UTC)[reply]
  3.   Support As proposer, if I'm allowed! Samwalton9 (talk) 09:11, 28 November 2016 (UTC)[reply]
  4.   Support It would be very useful to me, as patroller, sysop and abusefilter. Jules78120 (talk) 12:57, 28 November 2016 (UTC)[reply]
  5.   Support--Micru (talk) 13:30, 28 November 2016 (UTC)[reply]
  6.   Support - Having a plug and play dashboard for engaging Wikipedia, could be a great way to also allow for other widgets to be built in, once machine learning and other tools become more widely available (or sticking in games likehttps://tools.wmflabs.org/citationhunt/ , which could make contribution more direct). Sadads (talk) 14:42, 28 November 2016 (UTC)[reply]
    Yes! If this was developed I'd love for it to support user-created 'widgets'. Samwalton9 (talk) 18:42, 28 November 2016 (UTC)[reply]
  7.   Support -Nocowardsoulismine (talk) 17:55, 28 November 2016 (UTC)[reply]
  8.   Support because this has the potential to make editing considerably more exciting than it is today. I am concerned about the development costs vs. the actual use of it, but I'm willing to let this proposal go forward anyway. Stevie is the man! Talk • Work 19:37, 28 November 2016 (UTC)[reply]
  9.   Support MichaelMaggs (talk) 20:01, 28 November 2016 (UTC)[reply]
  10.   Support JAn Dudík (talk) 21:44, 28 November 2016 (UTC)[reply]
  11.   Support Anthonyhcole (talk) 02:59, 29 November 2016 (UTC)[reply]
  12.   Support Spinster (talk) 15:05, 29 November 2016 (UTC)[reply]
  13.   Support Guycn2 · ☎ 18:00, 29 November 2016 (UTC)[reply]
  14.   Support SamanthaNguyen (talk) 00:06, 30 November 2016 (UTC)[reply]
  15.   Support This would be wonderful to have and an added bonus is that I think it would help admins in particular to be more active and more efficient with that activity. Julia\talk 22:32, 30 November 2016 (UTC)[reply]
  16.   Oppose as nebulous user task. A customized dashboard is a user to-do blogpage, where many users just want a "to-read" list, with no editing. Currently, users can click browser "favorite page" to return to pages to read/edit. Yet long-term, we need essays for users to create their own customized to-do lists ("en:wp:How to create a user dashboard page" & link several examples). For example, enwiki admins have en:wp:DASHBOARD for noticeboards & requests, while en:wp:BACKLOG acts as dashboard for maintenance backlogs, or en:wp:CS1CAT lists cite-category page counts to fix citations by type of problem category. Overall, a dashboard is a user-specific, customized page (could explain by how-to essays), but oppose as nebulous feature. -Wikid77 (talk) 07:48, 1 December 2016 (UTC)[reply]
  17.   Support Ahm masum (talk) 17:32, 1 December 2016 (UTC)[reply]
  18.   Support Ermahgerd9 (talk) 18:35, 1 December 2016 (UTC)[reply]
  19.   Oppose - Not needed. How to do this is explained by w:Wikipedia:Tip of the day/July 28 Your very own Wikipedia bookmark page. JoeHebda (talk) 19:47, 1 December 2016 (UTC)[reply]
    @JoeHebda: See my example use cases in the description; the idea is that this is about more than simply linking somewhere. Samwalton9 (talk) 20:07, 1 December 2016 (UTC)[reply]
  20.   Support NMaia (talk) 02:28, 2 December 2016 (UTC)[reply]
  21.   Support —TheDJ (talk • contribs) 10:21, 2 December 2016 (UTC)[reply]
  22.   Support, that dashboard should also integrate ones WikiProjects. There are many ways how that could look like: for instance there could be a tile that gets updated with links to new discussions, drafts or new articles of a WikiProject. --Fixuture (talk) 18:18, 2 December 2016 (UTC)[reply]
  23.   Support--Ranjithsiji (talk) 06:11, 4 December 2016 (UTC)[reply]
  24.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  25.   Support It's actually quite surprising how scattered most pages are as of now, requiring that you click and click and click in order to get there. ArgonSim (talk) 19:49, 5 December 2016 (UTC)[reply]
  26.   Neutral I'm worried that this would be too much information too soon for new editors, even if they are just being offered the possibility of configuring their own dashboard. --Tryptofish (talk) 22:56, 5 December 2016 (UTC)[reply]
    What to put on a new user's dashboard is definitely something worth thinking more about. Perhaps someone could design a Wikipedia Adventure-style widget with some kind of tutorial to get users started. Samwalton9 (talk) 10:05, 6 December 2016 (UTC)[reply]
  27.   Support brilliant idea 4nn1l2 (talk) 11:00, 7 December 2016 (UTC)[reply]
  28.   Support--Elmidae (talk) 15:39, 7 December 2016 (UTC)[reply]
  29.   Support --Newbiepedian (talk) 02:22, 8 December 2016 (UTC)[reply]
  30.   Support — 0x010C ~talk~ 03:54, 8 December 2016 (UTC)[reply]
  31.   Support Iadmc (talk) 05:40, 8 December 2016 (UTC)[reply]
  32.   Support in principle, though it sounds like there are a lot of specifics to work out to make this actionable — Rhododendrites talk \\ 06:18, 8 December 2016 (UTC)[reply]
  33.   Support TheLordJagged (talk) 09:02, 8 December 2016 (UTC)[reply]
  34.   Support I'm not sure this should be the highest priority, but it sits well will my general desire to get Wikipedia unstuck from the design paradigms of the early 00s. A customizable dashboard for editing tasks would certainly be very convenient for very active editors. —Ynhockey (talk) 12:00, 8 December 2016 (UTC)[reply]
  35.   Support - if business applications have dashboards as a homepage for transactional users, why not wikipedia for theirs? DPdH (talk) 13:14, 8 December 2016 (UTC)[reply]
  36.   Support - This may have some interesting applications. Garycompugeek (talk) 22:57, 8 December 2016 (UTC)[reply]
  37.   Support Magalia (talk) 07:24, 9 December 2016 (UTC)[reply]
  38.   Support Ivi104 (talk) 12:16, 9 December 2016 (UTC)[reply]
  39.   Support Jack who built the house (talk) 19:08, 9 December 2016 (UTC)[reply]
  40.   Support Gareth (talk) 05:28, 10 December 2016 (UTC)[reply]
  41.   Support--Nizil Shah (talk) 06:36, 10 December 2016 (UTC)[reply]
  42.   Support --OrsolyaVirág (talk) 12:57, 10 December 2016 (UTC)[reply]
  43.   Support Stylez995 (talk) 16:11, 10 December 2016 (UTC)[reply]
  44.   Support --Tinss (talk) 17:46, 11 December 2016 (UTC)[reply]
  45.   Support This would be cool, in particular if it didn't require to reload the page. Matěj Suchánek (talk) 20:43, 11 December 2016 (UTC)[reply]
  46.   Support – Uanfala (talk) 23:29, 11 December 2016 (UTC)[reply]
  47.   Support I think some of our backlogs are because there are so many damn separate pages, which should instead be options within a single page to encourage both discovery and use. Quiddity (talk) 05:32, 12 December 2016 (UTC)[reply]
  48.   Support --Malyacko (talk) 11:57, 12 December 2016 (UTC)[reply]
  49.   Support--Mikheil Talk 21:03, 12 December 2016 (UTC)[reply]
  50.   Support --Yann (talk) 23:10, 12 December 2016 (UTC)[reply]

  • Problem: Internal links to article sections are allowed, but are difficult to follow up, for example if an author changes the title of a section. The functionality "What links to here" shows all internal links to the article and cannot be restricted to show only the links to a given section of an article. Even if authors occasionally add edit comments in the source code that specify links to here from another article, there is no way for an author to easily and systematically identify all internal links that link to a given section. Those internal links would need to be fixed in view of a section title change.
  • Who would benefit: The consistency of internal section links would be improved, for the benefit of all readers and authors.
  • Proposed solution: It is proposed that, when editing a section, an additional tool appears in the left column under "What links here" that leads to a list of articles that link to that section of the article. The additional tool could be called "What links to section", for example.
  • Phabricator tickets:
  • Proposer: Chris Howard (talk) 12:49, 19 November 2016 (UTC)[reply]

Community discussion

  1.   Support Guycn2 · ☎ 18:01, 29 November 2016 (UTC)[reply]
  2.   Support please see my ticket here: phab:T103281 - "What links here" for article sections" (you may link it above if you'd like to). Note that this would be especially useful when renaming section-headers. --Fixuture (talk) 22:01, 29 November 2016 (UTC)[reply]
  3.   Support SamanthaNguyen (talk) 00:08, 30 November 2016 (UTC)[reply]
  4.   Support I remember discussions about that in the past. If it is possible, good!--Alexmar983 (talk) 05:22, 30 November 2016 (UTC)[reply]
  5.   Support Alexei Kopylov (talk) 09:12, 30 November 2016 (UTC)[reply]
  6.   Support as long as the scenario I describe above is taken into account when designing this change. Stevie is the man! Talk • Work 19:45, 30 November 2016 (UTC)[reply]
  7.   Support Very helpful indeed. — Pajz (talk) 12:00, 1 December 2016 (UTC)[reply]
  8.   Support --Achim (talk) 20:27, 1 December 2016 (UTC)[reply]
  9.   Support Jack who built the house (talk) 21:35, 1 December 2016 (UTC)[reply]
  10.   Support Libcub (talk) 02:23, 2 December 2016 (UTC)[reply]
  11.   Support Emir of Wikipedia (talk) 15:17, 2 December 2016 (UTC)[reply]
  12.   Support --Kvng (talk) 16:31, 2 December 2016 (UTC)[reply]
  13.   Support --Adert (talk) 22:23, 2 December 2016 (UTC)[reply]
  14.   Support --Tbennert (talk) 06:32, 5 December 2016 (UTC)[reply]
  15.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  16.   Support --Cobblet (talk) 05:11, 7 December 2016 (UTC)[reply]
  17.   Support — Rhododendrites talk \\ 06:18, 8 December 2016 (UTC)[reply]
  18.   Support, not necessarily in the way proposed: it might be easier just to flag links that point to a section, in the way:
    The following pages link to Wikipedia
    Arabic (link to section Language editions) — NickK (talk) 10:40, 8 December 2016 (UTC)[reply]
  19.   Support--LikeLifer (talk) 16:32, 9 December 2016 (UTC)[reply]
  20.   Support--Similartothissimilartothat (talk) 17:58, 11 December 2016 (UTC)[reply]
  21.   Support --Soluvo (talk) 00:37, 12 December 2016 (UTC)[reply]
  22.   Support – Uanfala (talk) 01:23, 12 December 2016 (UTC)[reply]

Generate automatic summary when manually adding a section heading

  • Problem: Some background for those who may not realize this: /* section link */ in edit summaries generates a section link in revision histories. Clicking on the blue arrow on a particular line of the revision history of a page, for example, takes you to that section on the page: (→Generate automatic summary when manually adding a section heading: reply) So, /* section link */ may be thought of as an alternative form of [[#section link]]
Editors initiate potentially controversial page move discussions by entering {{subst:Requested move}} at the bottom of the talk page of the page which they want moved. That template, when substituted, automatically generates a unique section heading of the form: == Requested move 16 November 2016 ==. We had a problem with talk pages having multiple == Requested move == sections on the same page as RMCD bot was linking to the older section on the page, when it should have linked to the newer one. However, when an editor saves their RM edit, /* Requested move 16 November 2016 */ doesn't automatically make it into the edit summary. I'd like it to, and have been unable to find a way to make it happen in that use case. However, Template:RMassist is able to do it with the links it saves at Requested moves/Technical requests. Click on one of the (discuss) links on the page, and you will see that the "Subject/headline" box in that "(new section)" is preloaded with the correct edit summary section-link. The magic is in the URL that you get when clicking on the saved link:
&action=edit&editintro=Template:RMassist/editintro&section=new&preloadtitle=Requested+move+16+November+2016
I've been unable to find a way to make this magic happen with a substituted template rather than a saved link to click on.
  • Who would benefit: All editors, particularly those using Requested moves
  • Proposed solution: Finish this code review and make the code changes needed to allow this enhancement to go live.
  • More comments: This item ranked #43 in the 2015 Community Wishlist Survey. Unfortunately it found itself stuck in the "no-mans-land" between those projects sexy enough to make the top ten and those easy enough for a volunteer to finish at a hackathon.
  • Phabricator tickets: phab:T22307 In that ticket I suggest in more detail how this functionality should work for more general use cases.
  • Proposer: Wbm1058 (talk) 18:41, 16 November 2016 (UTC)[reply]

Community discussion

One thing which happens with me: I edit a section in the edit box, type the "Tab" key, and then type an edit simmary without stopping to think about the fact that I'm deleting the section linmk in the process. This proposal would easily fix that problem. עוד מישהו Od Mishehu 20:36, 20 November 2016 (UTC)[reply]

Voting – Generate automatic summary when manually adding a section heading

  1.   Support--Alexmar983 (talk) 05:24, 30 November 2016 (UTC)[reply]
  2.   Support to spur this to completion. Stevie is the man! Talk • Work 19:54, 30 November 2016 (UTC)[reply]
  3.   Support SamanthaNguyen (talk) 21:59, 1 December 2016 (UTC)[reply]
  4.   Support --Framawiki (talk) 20:33, 2 December 2016 (UTC)[reply]
  5.   Support — NickK (talk) 10:42, 8 December 2016 (UTC)[reply]
  6.   Support. עוד מישהו Od Mishehu 12:09, 8 December 2016 (UTC)[reply]

Graphs, charts, and timelines tools

  • Problem: Graphs, charts, and timelines on Wikipedia are not intuitive to create content. Time lines are pretty tough to deal with especially Graphical timelines
  • Who would benefit: Moderate wiki editors who want to make a timeline, graph, or chart.
  • Proposed solution: Timeline or graphic tool to input data with a GUI instead of having to input the whole graph via Wiki Markup Language
  • More comments: Graphs, charts, and timelines are a great way to communicate information and Wikipedia should put a lot of effort and energy into making graphs and charts intuitive to make.
  • Phabricator tickets:
  • Proposer: Wikideas1 (talk) 20:24, 12 November 2016 (UTC)[reply]

Community discussion


Page views for this page
 
State and Federal gas taxes bar graph
Made using Numbers for Mac

Voting – Graphs, charts, and timelines tools

  1.   Support--Wesalius (talk) 07:00, 28 November 2016 (UTC)[reply]
  2.   Support JAn Dudík (talk) 21:46, 28 November 2016 (UTC)[reply]
  3.   Support --Ziko (talk) 21:56, 28 November 2016 (UTC)[reply]
  4.   Support if it includes the ability to use data/queries from Wikidata. Spinster (talk) 15:07, 29 November 2016 (UTC)[reply]
  5.   Support SamanthaNguyen (talk) 00:07, 30 November 2016 (UTC)[reply]
  6.   Support--Alexmar983 (talk) 05:34, 30 November 2016 (UTC)[reply]
  7.   Support --Yurik (talk) 08:59, 30 November 2016 (UTC)[reply]
  8.   Support although perhaps the scope should be narrowed to one of the tools for a start. Stevie is the man! Talk • Work 20:02, 30 November 2016 (UTC)[reply]
  9.   Support --Nouill (talk) 13:06, 1 December 2016 (UTC)[reply]
  10.   Support --β16 - (talk) 15:33, 1 December 2016 (UTC)[reply]
  11.   Support --Gerwoman (talk) 18:26, 1 December 2016 (UTC)[reply]
  12.   Support --AmaryllisGardener talk 18:56, 1 December 2016 (UTC)[reply]
  13.   Support NMaia (talk) 02:10, 2 December 2016 (UTC)[reply]
  14.   Support —— DePlusJean (talk) 05:30, 2 December 2016 (UTC)[reply]
  15.   Support--Harvinder Chandigarh (talk) 07:07, 2 December 2016 (UTC)[reply]
  16.   Support, not exactly intuitive and currently uneditable in VisualEditor. —Jc86035 (talk) 11:09, 2 December 2016 (UTC)[reply]
  17.   Support,Matthewmayer (talk) 11:17, 2 December 2016 (UTC)[reply]
  18.   Support Sannita - not just another it.wiki sysop 14:10, 2 December 2016 (UTC)[reply]
  19.   Support --Barcelona (talk) 14:16, 2 December 2016 (UTC)[reply]
  20.   Support currently, many graphs are uploaded as images due to the lack of such a tool. I would prefer text-only editing. MartinThoma (talk) 14:44, 2 December 2016 (UTC)[reply]
  21.   Support --Entbert (talk) 14:57, 2 December 2016 (UTC)[reply]
  22.   Support Emir of Wikipedia (talk) 15:15, 2 December 2016 (UTC)[reply]
  23.   Support --Adert (talk) 22:24, 2 December 2016 (UTC)[reply]
  24.   Support Pamputt (talk) 11:09, 4 December 2016 (UTC)[reply]
  25.   Support --By erdo can (talk) 14:21, 4 December 2016 (UTC)[reply]
  26.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  27.   Support 4nn1l2 (talk) 19:33, 5 December 2016 (UTC)[reply]
  28.   Support ArgonSim (talk) 19:51, 5 December 2016 (UTC)[reply]
  29.   Support Pabouk (talk) 13:02, 6 December 2016 (UTC)[reply]
  30.   Support -- Amanda (aka DQ) 21:00, 6 December 2016 (UTC)[reply]
  31.   Support. - Mailer Diablo (talk) 07:03, 7 December 2016 (UTC)[reply]
  32.   Support --Assianir (talk) 07:49, 7 December 2016 (UTC)[reply]
  33.   Support 朝彦 | Asahiko (talk) 10:13, 7 December 2016 (UTC)[reply]
  34.   Support Sounds useful but should be narrowed down a little, as this seems a time-intensive task.--Elmidae (talk) 15:42, 7 December 2016 (UTC)[reply]
  35.   Support CFCF 💌 📧 20:39, 7 December 2016 (UTC)[reply]
  36.   Support — Rhododendrites talk \\ 06:20, 8 December 2016 (UTC)[reply]
  37.   Support — NickK (talk) 10:43, 8 December 2016 (UTC)[reply]
  38.   Support I originally proposed this many years ago, but it was very hard to get anything wiki-related developed then unless you developed it yourself. A convenient tool for charts and graphs would go a really long way. —Ynhockey (talk) 12:03, 8 December 2016 (UTC)[reply]
  39.   Support - DPdH (talk) 19:25, 8 December 2016 (UTC)[reply]
  40.   Support --Fixer88 (talk) 20:55, 8 December 2016 (UTC)[reply]
  41.   Support Miniapolis 23:47, 8 December 2016 (UTC)[reply]
  42.   Support--LikeLifer (talk) 16:33, 9 December 2016 (UTC)[reply]
  43.   Support Elekhh (talk) 23:53, 9 December 2016 (UTC)[reply]
  44.   Support --g (talk) 11:40, 10 December 2016 (UTC)[reply]
  45.   Support --OrsolyaVirág (talk) 12:58, 10 December 2016 (UTC)[reply]
  46.   Support --Plogeo (talk) 19:58, 10 December 2016 (UTC)[reply]
  47.   Support --NaBUru38 (talk)
  48.   Support improvements to Module:Chart.   Oppose developing an Excel-like GUI. Edits to data and presentation commands must remain clearly visible and trackable, which is better achieved with a text-based representation. JFG (talk) 10:57, 11 December 2016 (UTC)[reply]
  49.   Support SarahSV talk 15:37, 11 December 2016 (UTC)[reply]
  50.   SupportTinss (talk) 17:48, 11 December 2016 (UTC)[reply]
  51.   Support Tdslk (talk) 19:19, 11 December 2016 (UTC)[reply]
  52.   Support --Soluvo (talk) 00:39, 12 December 2016 (UTC)[reply]
  53.   Support For a GUI - great tool, but currently hard to use. Quiddity (talk) 05:35, 12 December 2016 (UTC)[reply]
  54.   Support Michal Lester לסטר (talk) 11:38, 12 December 2016 (UTC)[reply]
  55.   Support--Mikheil Talk 21:03, 12 December 2016 (UTC)[reply]

Improve diff to handle splitting a paragraph

  • Problem: Minor split of a paragraph create large diffs that are very hard to read: example.
  • Who would benefit: All people reviewing articles, but also all those newcomers that wait for their edits to be approved. Less work doing review = quicker reviews.
  • Proposed solution: Either somehow improve the diffing algorithm or allow users to click on different sections and re-diff them... Or maybe allow user to change wikicode on both sides and re-run diff on new wikicode.
  • More comments: Here is an example edit [3]. Just added some whitespace (new lines) and changed one word, but current algorithm shows the second paragraph as something completely different. Things that could be done here:
    1. Click on the 1st paragraph on the left side (select it).
    2. Click on the 2nd paragraph on the right side.
    3. Having those paragraphs selected I would have an option like "Re-diff from selected paragraphs".
  • Or if I could change wikicode:
    1. I would add new line in wikicode on the left side.
    2. I would have an option like "Re-run diff on temporary changes".

Both versions would allow me to quickly see malicious change.

I could imagine some better diff algorithm that could figure on its own that new line needs to be added to better see actual changes. But that would probably take a lot research to be useful.

Community discussion

A mention in 2005, phab:T21092 (imported from bugzilla, marked as wontfix). I would agree it could be useful to fix. phab:T7072 open since 2006. --Gryllida 03:21, 15 November 2016 (UTC)[reply]

  • Smart-diff algorithms must handle partial lines: As noted above, the diff could check if two shorter lines now were the original line split, but it also needs to detect when lines were split then further modified, by using a near-match comparison which checks if start/end of lines are similar, then conclude near-match as like 30 characters match at start, or 30 at end, or 15 characters match at both start+end of text line. Plus, it has been known since 1980s that a resync bracket of 'n' subsequent lines must match to consider other text as unchanged, such as 3 rows (6 lines) in a wikitable which all have the same data values in a monotonous table of similar rows. Meanwhile the splitting of lines should be done as a separate edit, from changing text within those split portions, to get a precise diff of changes. -Wikid77 (talk) 22:54, 20 November 2016 (UTC)[reply]

Voting – Improve diff to handle splitting a paragraph

  1.   Support This would help a lot. -Nocowardsoulismine (talk) 17:55, 28 November 2016 (UTC)[reply]
  2.   Support Johnuniq (talk) 22:03, 28 November 2016 (UTC)[reply]
  3.   Support this has annoyed me since long Megatherium (talk) 12:19, 29 November 2016 (UTC)[reply]
  4.   Support --Telaneo (User talk page) 21:35, 29 November 2016 (UTC)[reply]
  5.   Support --Fixuture (talk) 22:01, 29 November 2016 (UTC)[reply]
  6.   Support --Nikola (talk) 22:04, 29 November 2016 (UTC)[reply]
  7.   Support --Gnom (talk) 09:41, 30 November 2016 (UTC)[reply]
  8.   Support this being explored and fixed somehow, although I want any work by the user (e.g. aligning text blocks) to be kept to an absolute minimum. Stevie is the man! Talk • Work 20:17, 30 November 2016 (UTC)[reply]
  9.   Support as security crisis. For years, vandals have split long lines and hidden falsified text (or nonsense). Fortunately, many hack-edits occur in template parameters which show as invalid keywords or invalid parameter values, to reveal hacked text or vandalism. However, false words in split paragraphs can remain for months/years because recent-change patrollers cannot see diff words in split paragraphs. This seems likely #1 of top-ten wishlist for 2016. -Wikid77 (talk) 07:02, 1 December 2016 (UTC)[reply]
  10.   Support Yes yes yes. --Coemgenus (talk) 17:57, 1 December 2016 (UTC)[reply]
  11.   Support Oliv0 (talk) 17:59, 1 December 2016 (UTC)[reply]
  12.   Support AWhiteC (talk) 18:30, 1 December 2016 (UTC)[reply]
  13.   Support --Grabado (talk) 18:31, 1 December 2016 (UTC)[reply]
  14.   Support --AmaryllisGardener talk 18:56, 1 December 2016 (UTC)[reply]
  15.   Support Semmendinger (talk) 20:09, 1 December 2016 (UTC)[reply]
  16.   Support Small improvements to the diff algorithm would make the process much more effective & efficient for human readers. Ditto if someone could darken the often-invisible pink shading in the diff output. —Patrug (talk) 21:32, 1 December 2016 (UTC)[reply]
  17.   Support A thousand times yes. Just mentioned this issue in another proposal without knowing of this section's existence czar 01:36, 2 December 2016 (UTC)[reply]
  18.   Support Libcub (talk) 02:26, 2 December 2016 (UTC)[reply]
  19.   Support Would be very helpful. Woodstone (talk) 02:44, 2 December 2016 (UTC)[reply]
  20.   Support Dalba 04:37, 2 December 2016 (UTC)[reply]
  21.   Support Draceane (talk) 09:58, 2 December 2016 (UTC)[reply]
  22.   Support —Jc86035 (talk) 11:09, 2 December 2016 (UTC)[reply]
  23.   Support --Continua Evoluzione (talk) 14:15, 2 December 2016 (UTC)[reply]
  24.   Support Kvng (talk) 16:15, 2 December 2016 (UTC)[reply]
  25.   Support --Fixer88 (talk) 20:48, 2 December 2016 (UTC)[reply]
  26.   Support --Quark (talk) 00:17, 3 December 2016 (UTC)[reply]
  27.   Support I didn't know I needed this until just now. And now I don't see how I can live without it! -- Kndimov (talk) 00:21, 3 December 2016 (UTC)[reply]
  28.   Support --My Chemistry romantic (talk) 02:58, 3 December 2016 (UTC)[reply]
  29.   Support SamanthaNguyen (talk) 03:11, 3 December 2016 (UTC)[reply]
  30.   Support MER-C (talk) 03:18, 3 December 2016 (UTC)[reply]
  31.   Support Henryk Borawski (talk) 03:44, 3 December 2016 (UTC)[reply]
  32.   Support Gareth (talk) 11:18, 4 December 2016 (UTC)[reply]
  33.   Support --By erdo can (talk) 14:22, 4 December 2016 (UTC)[reply]
  34.   Support --Andropov (talk) 18:03, 5 December 2016 (UTC) Very useful.[reply]
  35.   Support -- KylieTastic (talk) 19:16, 5 December 2016 (UTC)[reply]
  36.   Support 4nn1l2 (talk) 19:27, 5 December 2016 (UTC)[reply]
  37.   Support ArgonSim (talk) 19:52, 5 December 2016 (UTC)[reply]
  38.   Support --Papuass (talk) 20:57, 5 December 2016 (UTC)[reply]
  39.   Support Tiggerjay (talk) 20:51, 6 December 2016 (UTC)[reply]
  40.   Support -- Amanda (aka DQ) 21:00, 6 December 2016 (UTC)[reply]
  41.   Support Rdrozd (talk) 22:29, 6 December 2016 (UTC)[reply]
  42.   Support Diff improvements should be one of the highest priorities imo. --YodinT 03:21, 7 December 2016 (UTC)[reply]
  43.   Support, long overdue. - Mailer Diablo (talk) 07:04, 7 December 2016 (UTC)[reply]
  44.   Support Current state can be rather confusing/misleading.--Elmidae (talk) 15:43, 7 December 2016 (UTC)[reply]
  45.   Support. Jules78120 (talk) 01:12, 8 December 2016 (UTC)[reply]
  46.   Support The diffs are often difficult to decipher at the best of times. And indeed a vandal can "hide" edits in such diffs as shown above... it took me a while to find the one word that had changed in the above Lorem text—and I only looked because the editor told me to... a vandal would not be so courteous Iadmc (talk) 05:15, 8 December 2016 (UTC)[reply]
  47.   Support — Rhododendrites talk \\ 06:20, 8 December 2016 (UTC)[reply]
  48.   Support — NickK (talk) 10:44, 8 December 2016 (UTC)[reply]
  49.   Support - DPdH (talk) 19:27, 8 December 2016 (UTC)[reply]
  50.   Support - Diffs are difficult to work out for what is very simple changes, such as line insertion/deletion. Needs to be improved. Keith D (talk) 21:53, 8 December 2016 (UTC)[reply]
  51.   Support Opabinia regalis (talk) 06:45, 9 December 2016 (UTC)[reply]
  52.   Support — it's about time this was fixed. Smalljim (talk) 15:03, 9 December 2016 (UTC)[reply]
  53.   Support--LikeLifer (talk) 16:35, 9 December 2016 (UTC)[reply]
  54.   Support Jack who built the house (talk) 19:58, 9 December 2016 (UTC)[reply]
  55.   Support Of course. --Waldir (talk) 11:12, 10 December 2016 (UTC)[reply]
  56.   Support --g (talk) 11:40, 10 December 2016 (UTC)[reply]
  57.   Support --NaBUru38 (talk)
  58.   Support --Alaspada (Talk) 04:03, 11 December 2016 (UTC)[reply]
  59.   Support Tdslk (talk) 19:20, 11 December 2016 (UTC)[reply]
  60.   Support – Uanfala (talk) 23:31, 11 December 2016 (UTC)[reply]
  61.   Support --Soluvo (talk) 00:40, 12 December 2016 (UTC)[reply]
  62.   Support Quiddity (talk) 05:37, 12 December 2016 (UTC)[reply]

Improve Lupin's anti-vandal live spellchecking tool

  • Problem: Whilst Lupin's anti-vandal live spellchecking tool is relatively good at monitoring recent edits for uncorrected errors, it (or another tool like it) really ought to operate much more slickly and allow for far fewer false reports or repeat returns. The number of false returns can quite demoralising and very time-wasting to check each one. It does not operate for long enough, only yielding circa 20 genuine edits per session before timing out.
  • Who would benefit: Article readers and content creators, plus all users of Lupins Live Spellchecker
  • Proposed solution: The following enhancements are suggested:
    • Do not report spelling errors within reference urls (a large number of false reports occur this way, especially media stories using the string "...todays-news-..." which the tool always suggests is changed to "...today's-news...")
    • Do not report spelling errors within File of Image names
    • Do not report spelling errors followed by [sic] or {{notatypo}} template
    • Run automatically for longer (a prompt requires user-input before the tool continues monitoring, and is currently set at only c.1hr 40minutes. An option to run for at least four times this length would assist bulk monitoring and reporting without the current need to frequently return to the computer.
    • Edit summary could include the text (Lupin) in the same way that edits made with Twinkle are identified with (TW). A mouseover on this word would allow other editors to understand how/why the edits were made, and probably increase take-up by other editors prepared to commit to bulk-check for basic mistakes.
  • Phabricator tickets:
  • Proposer: Parkywiki (talk) 01:53, 17 November 2016 (UTC)[reply]

Community discussion

Which languages would the tool detect? ShakespeareFan00 (talk) 13:57, 17 November 2016 (UTC)[reply]
I don't know whether Lupin's tool works in languages other than English - presumably it would just needs access to the relevant languages dictionaries and an appropriate, simple interface to work in any language. BTW: I was the orginal proposer of this - it appears I wasn't logged in at the time.Parkywiki (talk) 08:52, 19 November 2016 (UTC)[reply]
I'm surprised it still works... Last time i made fixes to it was some 6 years ago.. Anyway. full rewrite is advisable. It's a codebase from 2003 —TheDJ (talk • contribs) 10:09, 2 December 2016 (UTC)[reply]

Voting – Improve Lupin's anti-vandal live spellchecking tool

  1.   Oppose Seems more like something that the local community should work on, since this will hardly benefit anyone but the English Wikipedia. --ArgonSim (talk) 19:53, 5 December 2016 (UTC)[reply]
  2.   Neutral Would like to support this only if the tool becomes multilingual — NickK (talk) 16:02, 8 December 2016 (UTC)[reply]

Improve the history UI

  • Problem: The history UI currently could be improved to provide a better user experience, as it has some flaws:
  • It's not responsive (doesn't flow very well when viewed on smaller devices).
  • It's hard to scan through with the current format, since the length of edit summaries and usernames vary, along with the names of months.
  • There's so much text that at a very first glance, it can be confusing to understand.
  • When comparing versions, the comparison can get confused if line breaks have been removed - makes it difficult to know what's changed.
    To a veteran wiki editor it will make sense, but not to new editors! The goal of wikis is to enforce the feeling of a community - new people should be included.
  • Who would benefit: Wikimedia members who actively edit and/or interested in getting into editing.
  • Proposed solution: Wikis are quite a huge learning curve, so with these points in mind, a new concept has been developed as an attempt to make it friendly regardless of that person's experience. :)

It introduces:

  • Grouped edits by date for easier scanning (similar to how RecentChanges groups edits by date)
  • Generous whitespace so it's easier on the eye, including more space to read edit summaries
  • Visual icons...
    • On the left quickly identify the type of the revision (editing, protecting, deleting, renaming/moving, minor edit, bot edit, etc.)
    • On the right that act as buttons in an attempt to better represent each action:
      • The search icon: For viewing the diff, same as the 'prev' function
      • A backwards arrow icon: For undoing the edit
      • An eye crossed out icon: For hiding the revision
      • A thumbs up icon: For thanking the user of that edit
      • Clipboard icon: For a quick 1 click copy to the revision
  • A design visually consistent with other interfaces such as Echo, Flow, VisualEditor, and RevisionSlider

Here's the gallery of icons for identifying different types of edits so other people can see:

  •  
    Normal edit
  •  
    For reverting an edit
  •  
    Icon for creating a file
  •  
    Icon for creating a template
  •  
    For deleting a page
  •  
    For restoring a page
  •  
    Icon for marking an article or image as "Featured"
  •  
    For protecting/locking a page
  •  
    For unprotecting/unlocking a page
  •  
    For starting a discussion
  •  
    For replying to a comment
  •  
    For translating an article

NOTE: For minor edits and bot edits, I was thinking it'd be like the same icon for undoing an edit presented up above, except the arrow is replaced with a capital M for minor edit, and B for bot edit respectively :)

  • In theory for handling responsiveness, the revision actions on the right would be pushed into a dropdown menu via JavaScript

Currently of course, there are still flaws such as including the total amount of bytes and a button for comparing the revision to the current revision. This is still a concept, but I would love feedback and constructive criticism on how this could be improved! Thanks :) A rough concept demo is at https://samanthanguyen.github.io/mediawiki-demo-VisualChanges/ (which is still being actively worked on)

Nice-to-haves
  • Modal popups for actions without having to leave the page
    • For viewing a diff (Thanks for the suggestion Nizil Shah!)
    • Undoing edits
    • Thanking a person for their edit
    • Hiding a revision
  • Configurable stuff such as:
    • Switching between relative and absolute time-stamps
    • Color accessibility for diffs
    • Distinguishable icons (possibility)
  • Great suggestions by User:Zefr!
    1. color newly added text to enable quick visual review and a work area within the document
    2. color the editor's revision to simplify review
    3. color duplicate references to facilitate quick hunting and repair
    4. auto-refresh the page, with a notice to a simultaneous editor that the page is under revision (think of the frustration resulting from an edit conflict when considerable editing has already been done)

I'd also like to state that the rough concept is also just a suggestion which should be taken with a grain of salt; the main purpose of this proposal is to push forward the goal of improving the history interface.

  • Phabricator tickets: Added all related and affected tickets that I could find below! Please let me know if I've missed any :)
    • phab:T5640 - Mark edits that were {reverted/rollbacked} (in the logs history/contribs pages and data dumps)
    • phab:T6717 - The history view should be changed to accommodate larger edit summaries
    • phab:T15516 - Interface support to mark bot edits in histories
    • phab:T13181 - Mark bot edits in histories
    • phab:T20674 - History page excessively cluttered, esp. with suppressrevision
    • phab:T30131 - Modernize the look and usability of page histories
  • Proposer: SamanthaNguyen (talk) 03:14, 8 November 2016 (UTC)[reply]

Community discussion

The benefits are clear. --Wesalius (talk) 07:16, 8 November 2016 (UTC)[reply]

Would be very helpful. I guess more editors would be thanked if a thumbs up symbol replaces the current text, probably motivating them to edit more. --Kaartic (talk)

To avoid any confusion: voting phase is not until ~two weeks. This space is mainly for discussing the proposals. Cheers. :) -- NKohli (WMF) (talk) 11:21, 8 November 2016 (UTC)[reply]

Some users does not like colorbooks, so it should be optional (disablable) JAn Dudík (talk)

As long as users can view the "classic" history listing, this general idea sounds reasonable. I don't think I would like scrolling through all the new whitespace and graphics. But if it helps new users, that's a good thing. Stevie is the man! Talk • Work 15:06, 8 November 2016 (UTC)[reply]

I like this, but there will be lots of people who won't like it, and want to disable it (like always), which means we have to have two systems, which well.. sucks. It will also break any and every tool that depends on the old layout. My suggestion is to do this for just the mobile skin and hope that from that point it will be able to conquer a place into the hearts of more editors. As sad as it might be, there is no way in hell you'll get this live on the bigger wikipedia sites. :( —TheDJ (talk • contribs) 15:22, 8 November 2016 (UTC)[reply]

Yeah, that's very true! People will always have an opinion which will slant to one of the sides either way. Perhaps we can just try our best to improve the interface as much as possible? SamanthaNguyen (talk) 00:26, 9 November 2016 (UTC)[reply]
There's a problem with this: for experienced editors, the ability to scan the maximum possible extent of the history is critical. Therefore, the current display, possibly a little enhanced, should must kept, or work be much more difficult for people who do the sort of work I do, One feature only of the proposed change would help, and could be enabled even on the classic interface:grouping the edits by date. For people just starting, there might be reason to simplify, but the proposal is not a simplification but an over-elaboration, with obtrusive unobvious icons They may seem acceptable above, but they won't look good when reduced to the necessary size.DGG (talk) 23:25, 8 November 2016 (UTC)[reply]
I resized the icons to about how it looks in the demo; have you checked the demo yet? Since they're SVGs, they'll scale down and retain the same quality - I also believe there isn't too much detail in them. Another note, I added a comment of how it could be disabled by default but could be enabled via Special:Preferences up above. :) Thanks for the feedback, is there more suggestions you could provide on making it easier to scan? SamanthaNguyen (talk) 00:26, 9 November 2016 (UTC)[reply]
  • Is there any way that we can have history page where on top we have a rectangular window where we can watch changes by clicking respective edits? So we do not have to check everytime with diff and most recent edit is readily visible when we open the history. -Nizil Shah (talk) 02:27, 11 November 2016 (UTC)[reply]
    • There is! We can use a technology called AJAX to achieve that :) This would require some more experienced programmers to create it, but it's definitely possible. I'll put it under the "More comments" section of this proposal :) SamanthaNguyen (talk)

I made a similar proposal last year, so I strongly support the goal of making history pages better. That said, I must criticize the prototype here (self-conscious that my own prototype was terribly ugly!). Forgive me if it's harsh, but I mean it all constructively:

  • Icons are a trap. Icons work best when they address a small number of highly concrete, highly recognizable concepts; history pages are full of highly abstract, Wikipedia-specific ones. While replacing labelled links with icon links is excellent for reducing both the space needed, and the "visual load" of the replaced labels, I cannot at a glance be sure of the purpose of every icon in the mockup. I'm an expert user who knows what features to expect—what's the experience for a newbie?
  • Some features don't match real-world needs. For example, the icons at the left of the prototype, for distinguishing the type of log item, are likely to be useless most of the time, because the vast majority of history items are edits; most article histories will be a sea of needless pencil icons. If these icons are found to be desirable at all, I would suggest using them exclusively on non-edit items: the main desirable distinction is between edits and other kinds of log item. Similarly, splitting up histories by day makes a lot of sense in the context of frequently-edited articles, but low-traffic articles would make histories a sea of date headers, since individual edits might be spaced out by weeks, months, or years. We need to make sure that the design is not infuriating for common situations like that.
  • We should not design exclusively for newbies. Our goal in keeping interfaces simple is not actually "support newbies", it's "make onboarding easy". A design that caters to newbies while harming the needs of expert users is dangerous because expert users can and will route around it with their own tools, resulting in a split between the set of tools used by newbies and by experts, which is harmful to onboarding. In particular, we should be looking for ways to highlight the "core" features that everyone (particularly newbies) needs, while supporting the data-dense, feature-rich design ultimately preferred by expert users—without letting it become overwhelming for newbies.

Improving the history pages is not going to be an easy task, but as a core feature of each wiki, we need to make sure we get it right. {{Nihiltres |talk |edits}} 18:26, 11 November 2016 (UTC)[reply]

First off, thank you so much for the feedback! I definitely appreciate it and would love to see this interface continiously improve that it would be stable enough to be used and be helpful by wiki communities, so this is very helpful  :)
  • "Icons are a trap": Well said! The actions are more explicit and actually have text tooltips once you hover over the icon buttons, but of course that's a hidden affordance and not easily discoverable (there's nothing that conveys a tooltip will pop up if you hover them). I'll have to think about this one.
  • "Some features don't match real-world needs. " - Makes sense - perhaps the icons for distinguishing between revisions could be a configuration settings. (We could make this discoverable by having a button saying "settings" with a gear icon attached, similar to MultiMediaViewer except there's just a gear icon button). As for about splitting revisions via timeframes, I agree with that statement. I didn't quite think about that actually :) With PHP, it could be possible to organize them in different length of timeframes by using a switch and different expressions. The expression could be something like "if there was x edits within y days". Depending on the value of x and y, it would divide groups of revisions by either day, weeks, months, or years.
  • "We should not design exclusively for newbies" - About the onboarding, I think that's a good approach to it. :) I'll have to read more into it.

In the mean time, I'll be thinking about your feedback and see how I can implement the feedback to improve the interface, along with doing some other stuff like implementing AbuseFilter tags into the demo, such as "Visual edit" or "Blanking", etc etc Thank you very much again! SamanthaNguyen (talk) 23:18, 11 November 2016 (UTC)[reply]

I second the finding of a diff problem when line feeds are removed. There's no way of telling if any other changes have been made. A world-by-word diff in these situations would be helpful. Bob Burkhardt (talk) 15:47, 12 November 2016 (UTC)[reply]

Hmm sorry, could you explain what you're saying? If you're referring to the diff viewer, then this proposal is only about the main history UI viewer itself. :) SamanthaNguyen (talk) 05:10, 14 November 2016 (UTC)[reply]
  1. color newly added text to enable quick visual review and a work area within the document
  2. color the editor's revision to simplify review
  3. color duplicate references to facilitate quick hunting and repair
  4. auto-refresh the page, with a notice to a simultaneous editor that the page is under revision (think of the frustration resulting from an edit conflict when considerable editing has already been done)
  5. auto-refresh the Watchlist when logged in but inactive
Thanks. --Zefr (talk) 02:16, 18 November 2016 (UTC)[reply]
These are great! I'll add those up above and give the credit to you for the 5 suggestions under the nice-to-haves! I appreciate it :) However I believe the last one is more related to Special:Watchlist rather than the history UI, so I'll leave it here down below. Perhaps you could make that into a proposal?

SamanthaNguyen (talk) 02:22, 19 November 2016 (UTC)[reply]

Voting – Improve the history UI

  1.   Support--Shizhao (talk) 02:42, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:00, 28 November 2016 (UTC)[reply]
  3.   Support This is one of the hardest elements of Wikipedia to teach folks, Sadads (talk) 14:44, 28 November 2016 (UTC)[reply]
  4.   Support-Nocowardsoulismine (talk) 17:55, 28 November 2016 (UTC)[reply]
  5.   Oppose. Please no. All those button colouring tasks yield is either nothing or pages loading more slowly on not-so-new devices like old 512Mb RAM and less computers or slow connections which do not render all cool CSS and JS right away. Do redesign as an optional gadget if you really need it. --Base (talk) 18:27, 28 November 2016 (UTC)[reply]
  6.   Support--Afernand74 (talk) 18:56, 28 November 2016 (UTC)[reply]
  7.   Neutral The thrust of this proposal is very useful and I appreciate its intentions. I just don't want the WMF tied up with making an alternative to something we already have while we have plenty of other proposals that seem more badly needed. Maybe someone should just create a beta gadget to "gussy up" the current history pages, and have this promoted to new users. With use and feedback over time, we will then see whether this will become valuable enough for WMF resources to make it "built in". Stevie is the man! Talk • Work 19:44, 28 November 2016 (UTC)[reply]
  8.   Support—with the caveat that this needs design work before being implemented. {{Nihiltres |talk |edits}} 21:11, 28 November 2016 (UTC)[reply]
  9.   Support --Jack Phoenix (Contact) 22:45, 28 November 2016 (UTC)[reply]
  10.   Oppose Low priority and best tackled by other WMF departments. MER-C (talk) 05:38, 1 December 2016 (UTC)[reply]
  11.   Support Ahm masum (talk) 17:32, 1 December 2016 (UTC)[reply]
  12.   Support GeorgeBarnick (talk) 19:03, 1 December 2016 (UTC)[reply]
  13.   Support Libcub (talk) 02:27, 2 December 2016 (UTC)[reply]
  14.   Support Draceane (talk) 09:58, 2 December 2016 (UTC)[reply]
  15.   Support —TheDJ (talk • contribs) 10:09, 2 December 2016 (UTC)[reply]
  16.   Support Emir of Wikipedia (talk) 15:16, 2 December 2016 (UTC)[reply]
  17.   Support – Sandiooses (talk) 17:29, 2 December 2016 (UTC)[reply]
  18.   Support, checked the demo and really like it. It's 2016 - almost 2017. Apparently Wikipedia with all its funds doesn't get that. Look at any other comparable website (except maybe reddit): they all have a modern UI. Also this shouldn't be too hard to implement and the argument that it may take longer to load is an argument of the last decade. --Fixuture (talk) 18:24, 2 December 2016 (UTC)[reply]
  19.   Support: Very valuable to improve and facilitate the editor's work experience. --Zefr (talk) 19:44, 3 December 2016 (UTC)[reply]
  20.   Support--Ranjithsiji (talk) 06:12, 4 December 2016 (UTC)[reply]
  21.   Support --By erdo can (talk) 14:22, 4 December 2016 (UTC)[reply]
  22.   Neutral -- there's a lot of good stuff here, but but it should be split into separate feature requests so we're clear on what we're actually talking about. ImperfectlyInformed (talk) 18:35, 4 December 2016 (UTC)[reply]
  23.   Oppose Feels like it would have the same problems as Visual Editor. --Tryptofish (talk) 23:00, 5 December 2016 (UTC)[reply]
  24.   Neutral Interesting but I find it challenging to follow everything written here in this proposal. Blue Rasberry (talk) 19:15, 6 December 2016 (UTC)[reply]
  25.   Support --Assianir (talk) 07:51, 7 December 2016 (UTC)[reply]
  26.   Support 4nn1l2 (talk) 11:08, 7 December 2016 (UTC)[reply]
  27.   Support - As long can be opted out (or in). DPdH (talk) 19:32, 8 December 2016 (UTC)[reply]
  28.   Neutral per Bluerasberry. That said, I would support highlighting the lines in the history that are maintenance tags (orange), deletion tags - PROD, BLPPROD, CSD, AfD (red), and bot added warnings on the edit summary (yellow). But AFAICS, none of this has been proposed here. Perhaps Tryptofish could comment on this. Kudpung (talk) 03:21, 10 December 2016 (UTC)[reply]
    Thanks for asking. For me, what it boils down to is that I don't find the proposed icons particularly easy to understand, relative to presenting it in words. Thus, like Visual Editor, I don't think the payoff would justify the change. As for your idea of using colors in that way, I think it's better than monochrome, but users would still have to understand what each color would signify. Just my individual reaction. --Tryptofish (talk) 21:56, 10 December 2016 (UTC)[reply]
  29.   Support Would love to see some options for how history (et al) pages are formatted and what info is included. Ending up with a simple version that contains less than current, and a power version that contains more than current, and anything in between. Quiddity (talk) 05:39, 12 December 2016 (UTC)[reply]
  30.   Support Michal Lester לסטר (talk) 11:43, 12 December 2016 (UTC)[reply]

Improved "pipe trick" behaviour

  • Problem: The "pipe trick" (WP:PIPETRICK, Help:Magic#Pipe trick, m:Help:Piped link) has a number of shortcomings which should be addressed for a greater utility value of this neat feature:
    1. It does not work for links containing #anchors.
    2. It does not work for /subpages.
    3. It does not work inside of <ref> and <gallery> sections.
    4. It does not work inside of edit summaries
  • Who would benefit: Experienced editors
  • Proposed solution: In addition to the cases already discussed under "pipe trick", the following cases (with empty pipe) should be expanded as follows in Preview and when Saving an article:
1.
  • a. [[link#anchor|]] -> [[link#anchor|anchor]]
  • b. [[#anchor|]] -> [[#anchor|anchor]]
This one is most useful for article cross-links within the same article. This is effectively the same as specifying link (in case 1.a. above) as the title of the article, but has the advantage that links do not need to be renamed when the article would be renamed. For an example, see the "ASA" and "DIN" links in the first sentence in this article.
  • c. [[link#|]] -> [[link#name|name]]
where name is the title of the current article, with (parenthesized) and comma- or colon-separated stuff stripped off as for the normal pipe trick.
  • d. [[link##|]] -> [[link#subname|subname]]
where name is the title of the current article, with (parenthesized) and comma- or colon-separated stuff stripped off, and with (number of # characters minus 1, here: 2 - 1 = 1) words of name stripped off at the beginning of the title.
This one is particularly useful for ordering categories via category links.
For example: Assume name would be Microsoft Windows (following the common naming scheme "<vendor> <product>"), so [[Category:Microsoft operating systems##|]] would result in [[Category:Microsoft operating systems|Windows]].
In addition to this, if the link contains "Category:" the pipe trick should preserve optional whitespace in front of the name, so that [[Category:Microsoft operating systems##| ]] would result in [[Category:Microsoft operating systems| Windows]].
  • e. [[#|]] -> [[#name|name]]
  • f. [[link#]] -> [[link#name]]
where name is the title of the current article, with (parenthesized) and comma-separated stuff stripped off as for the normal pipe trick.
This one would be particularly useful in redirects from topics which are discussed in sections of other articles, f.e. the topic "Slowfeld" redirects to a section named "Slowfeld" in "Hellschreiber", hence the redirect would look like:
#redirect [[Hellschreiber#Slowfeld]]. With the suggested pseudo-pipe trick implemented, this could be written shorter as #redirect [[Hellschreiber#]].
  • g. [[link##]] -> [[link#subname]]
where name is the title of the current article, with (parenthesized) and comma-separated stuff stripped off, and with (number of # characters minus 1, here: 2 - 1 = 1) words of name stripped off at the beginning of the title.
This one would be particularly useful in redirects like Nikon F3HP (following the common <vendor> <product> scheme) pointing to [[Nikon F3#F3HP]]. With the suggested pseudo-pipe trick implemented, the redirect could be simply written as #redirect [[Nikon F3##]] instead of #redirect [[Nikon F3#F3HP]].
2.
  • a. [[link/subpage|]] -> [[link/subpage|subpage]]
  • b. [[/subpage|]] -> [[/subpage|subpage]]
  • c. [[link/|]] -> [[link/name|name]]
where name is the title of the current article, with (parenthesized) and comma-separated stuff stripped off.
  • d. [[/|]] -> [[/name|name]]
  • Phabricator tickets:
(partially covered)

Community discussion

  • WAIT, piped-wikilinks DO WORK, in reftags or edit-summary, and cross-wiki: For many browsers, a piped link works well, even with section-headers "#Header" and within reftags or edit-summaries, also cross-wiki. For example, even here on Meta, an edit-summary can contain "[[:en:Einstein#Cosmology|]]" and will link, cross-wiki, into English Wikipedia at redirect page "en:Einstein" and link to header "Cosmology" within the base page "en:Albert Einstein" as accepting not only the pipe-bar, but also transforming a redirect, pointing to a #Header section, plus get this, all as cross-wiki from Meta into en:enwiki pages. Now, within a en:wp:reftag footnote, a piped-wikilink must specify the visible anchor text, not empty "[[xx|]]" (see: [1]), but that is a minor bug, for very rare cases, when the visible anchor text is often specified in many wikilinks. So meanwhile, piped-wikilinks are good enough for years to come, in reftag footnotes or edit-summaries, etc. -Wikid77 (talk) 17:07, 15 November 2016 (UTC)[reply]
References
  1. ↑ This is a footnote linking the 2016 Survey and enwiki Einstein's Cosmology: link en:Einstein#Cosmology (click link to verify it goes to header "Cosmology")
  • @Wikid77: Sure, pipes do work fine (with all browsers), but the so called "pipe trick" does not (at least not in the cases discussed above).
By "pipe trick" we refer to a number of special cases with empty pipe arguments, something that does not normally make sense as it would result in an invisible link. So, a number of rules have been defined in the mediawiki software what to do in these cases (see WP:PIPETRICK for details). The idea for all of these rules is to make advanced editing tasks easier and less errorprone in some intuitive way which is not conflictive with "normal" pipes as these cases are never used for standard cases. My proposal above suggests a number of additional special cases which would be convenient to have in some editing scenarios.
--Matthiaspaul (talk) 20:03, 15 November 2016 (UTC)[reply]

Voting – Improved "pipe trick" behaviour

  1.   Support--Wesalius (talk) 07:00, 28 November 2016 (UTC)[reply]
  2.   Support please Ninovolador (talk) 11:34, 28 November 2016 (UTC)[reply]
  3.   Support Anthonyhcole (talk) 03:03, 29 November 2016 (UTC)[reply]
  4.   Support  @xqt 14:00, 29 November 2016 (UTC)[reply]
  5.   Support in principle. I don't consider the list above to be final, though, and I'd want a specific discussion of cases. StevenJ81 (talk) 17:41, 29 November 2016 (UTC)[reply]
  6.   Support Alexei Kopylov (talk) 09:15, 30 November 2016 (UTC)[reply]
  7.   Neutral Potentially useful but to a limited user community (advanced users). I'd rather WMF take on more widely useful tasks in this survey. Stevie is the man! Talk • Work 21:07, 30 November 2016 (UTC)[reply]
  8.   Support So I'm not the only one to struggle with this issue. Fixing this would be an improvement to the editing experience. -- Llywrch (talk) 06:45, 2 December 2016 (UTC)[reply]
  9.   Support Jerodlycett (talk) 12:51, 2 December 2016 (UTC)[reply]
  10.   Support Hmich176 (talk) 22:56, 2 December 2016 (UTC)[reply]
  11.   Support SamanthaNguyen (talk) 22:57, 3 December 2016 (UTC)[reply]
  12.   Support --Andropov (talk) 18:09, 5 December 2016 (UTC)[reply]
  13.   Neutral I'm not convinced that the need is urgent enough. --Tryptofish (talk) 23:02, 5 December 2016 (UTC)[reply]
  14.   Support, particularly for ref's and galleries — NickK (talk) 16:05, 8 December 2016 (UTC)[reply]
  15.   Support --g (talk) 11:59, 10 December 2016 (UTC)[reply]

List-to-table converter

  • Problem: Many articles are plain lists which would be way more useful if they were clearer, sortable tables.
  • Who would benefit: Everyone (people viewing lists and people creating lists)
  • Proposed solution: Create a list-to-table converter that allows users to easily convert a list with entries to a table. I guess there is much room for improval for it but it would be enough for a start if e.g. lists with one wikilink and a year per entry (at least most of its entries) would be converted to a table with 2 columns.
  • More comments: I'm not sure if this is the right category for this here? Maybe it should be moved over to Bots and gadgets?
  • Phabricator tickets:
  • Proposer: Fixuture (talk) 11:43, 20 November 2016 (UTC)[reply]

Community discussion

Voting – List-to-table converter

  1.   Support JAn Dudík (talk) 21:47, 28 November 2016 (UTC)[reply]
  2.   Support StevenJ81 (talk) 17:41, 29 November 2016 (UTC)[reply]
  3.   Support Guycn2 · ☎ 18:08, 29 November 2016 (UTC)[reply]
  4.   Support Making it easier to generate tables is useful. Stevie is the man! Talk • Work 21:14, 30 November 2016 (UTC)[reply]
  5.   Support --Gerwoman (talk) 18:28, 1 December 2016 (UTC)[reply]
  6.   Support --JB82 (talk) 01:17, 2 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 02:28, 2 December 2016 (UTC)[reply]
  8.   Support Draceane (talk) 09:58, 2 December 2016 (UTC)[reply]
  9.   Support SamanthaNguyen (talk) 22:58, 3 December 2016 (UTC)[reply]
  10.   Support--Ranjithsiji (talk) 05:55, 4 December 2016 (UTC)[reply]
  11.   Support - Best regards, Kertraon (talk) 11:42, 4 December 2016 (UTC)[reply]
  12.   Support - Yes please, coding tables is boring and easy to make a mistake. DPdH (talk) 19:35, 8 December 2016 (UTC)[reply]
  13.   Support --Fixer88 (talk) 20:56, 8 December 2016 (UTC)[reply]
  14.   Support --Kusurija (talk) 19:44, 9 December 2016 (UTC)[reply]

Mobile preview from desktop editing

  • Problem: For editors it can be difficult to assess what their content looks like on smaller form factors and on the mobile website.
  • Who would benefit: Readers, because editors would be able to take into account different output more easily
  • Proposed solution: Add a mode into editing, that would allow you to load the mobile website in a separate frame and allow you switch between several sizes (See also Responsive design mode of browser's web inspectors).
  • More comments: This would be a further refinement and integration of User:Brion_VIBBER/mobile-sidebar.js
  • Phabricator tickets: There might be one, but I couldn't find it.
  • Proposer: —TheDJ (talk • contribs) 16:14, 8 November 2016 (UTC)[reply]

Community discussion

Voting – Mobile preview from desktop editing

  1.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  2.   Support--Strainu (talk) 10:22, 28 November 2016 (UTC)[reply]
  3.   Support-Nocowardsoulismine (talk) 17:56, 28 November 2016 (UTC)[reply]
  4.   Support --Nikola (talk) 22:05, 29 November 2016 (UTC)[reply]
  5.   Support KPFC 💬 23:31, 29 November 2016 (UTC)[reply]
  6.   Support SamanthaNguyen (talk) 00:08, 30 November 2016 (UTC)[reply]
  7.   Support Trizek from FR 17:56, 30 November 2016 (UTC)[reply]
  8.   Neutral Useful idea but shouldn't be prioritized by WMF for the next year. Due to how many approaches are potentially viable with this, I think a WMF-external developer should take a stab at creating a beta gadget for this. Stevie is the man! Talk • Work 21:35, 30 November 2016 (UTC)[reply]
  9.   Support Libcub (talk) 02:29, 2 December 2016 (UTC)[reply]
  10.   Support —— DePlusJean (from FR) 06:09, 2 December 2016 (UTC)[reply]
  11.   Support as proposer :) —TheDJ (talk • contribs) 10:10, 2 December 2016 (UTC)[reply]
  12.   Support --Kvng (talk) 16:21, 2 December 2016 (UTC)[reply]
  13.   Support --Framawiki (talk) 20:29, 2 December 2016 (UTC)[reply]
  14.   Support - would be useful for editors concerned about exactly how the articles appear on different sized screens. Thanks. Mike Peel (talk) 23:50, 2 December 2016 (UTC)[reply]
  15.   Oppose I feel like in a few years I would change my mind, but currently, I don't think many desktop users will take the time to preview their work twice. They will just use the one we have now and not do the extra work. I mean, most of us (except the person reading this), are too lazy to even check the "minor edit" box below the edit summary. I don't think it's worth the investment at this time. -- Kndimov (talk) 00:25, 3 December 2016 (UTC)[reply]
  16.   Support--Ranjithsiji (talk) 05:56, 4 December 2016 (UTC)[reply]
  17.   Support -- the wub "?!" 15:51, 4 December 2016 (UTC)[reply]
  18.   Support Studmult (talk) 08:06, 5 December 2016 (UTC)[reply]
  19.   Oppose I believe most people would simply ignore this feature completely; updating the Manual of Style's guidelines in a way that mobile output is also taken into account seems more reasonable (and also a prerequisite for this proposal). ArgonSim (talk) 20:03, 5 December 2016 (UTC)[reply]
  20.   Support as nice-ish, but low priority. I also would like to see displays on different screen sizes, not only mobile. --Tryptofish (talk) 23:05, 5 December 2016 (UTC)[reply]
  21.   Support - This will make sure that users who edit from desktops/;aptops (most of the editors) will understand how viewers from mobile devices (most of the readers) see the site. עוד מישהו Od Mishehu 12:13, 8 December 2016 (UTC)[reply]
  22.   Support - Nice to have but not a priority now.
  23.   Oppose plenty of browser extensions available, no need for a common tool since experiments should be tested in sandbox first --g (talk) 12:03, 10 December 2016 (UTC)[reply]
  24.   Support Quiddity (talk) 05:41, 12 December 2016 (UTC)[reply]

Mark redirects that have typos

  • Problem: Some redirects are just spelling errors and should not be used in normal content. If they are used as links in normal content, then the link should be visually marked to stand out from other links.
  • Who would benefit: All projects that use free-form internal links
  • Proposed solution: Mark the redirect page with a special magic word like __SPELLING_ERROR__ and propagate it to the created link as a class spelling-error and there use it to add some styling like like this (only visible in Firefox).
  • More comments:
    • It might be necessary to be able to turn this feature on and off, as the visual clutter might be too pronounced for some users.
    • It is not quite obvious if it is the redirect page that should be marked, or if it is the categories used for the redirect pages that should be marked.
    • Misspelling of redirects is not something that can be found by ordinary spell checkers. It might be something like writing "Bysantiske Rike" in Norwegian, when the correct is "Det bysantiske riket". Both will be found to be correct by a spell checker, but someone fluent in Norwegian would know that the second is correct. It is opposite of what one would assume in English.
  • Phabricator tickets:
  • Proposer: — Jeblad 23:24, 17 November 2016 (UTC)[reply]

Community discussion

  • Misspelled redirects are marked with {{R from misspelling}}
  • There are 26,000 transclusions of {{R from misspelling}} on English Wikipedia
  • e.g., Barrack Obama and Massachusets
  • Wikipedia:Database reports/Linked misspellings is a weekly bot-generated report of all links to marked misspelled redirects
  • I believe I'm about the only editor who has worked this beat in the last 6 months and would appreciate some help
    Someone helped out and cleared a bunch of these this week, and I much appreciate that. Thanks! Wbm1058 (talk) 16:04, 28 November 2016 (UTC)[reply]
  • It would be nice if these were color-highlighted in similar fashion to the way Navigation popups highlights links to disambiguation pages for easy repair via a mouse-click
  • Often the misspelled redirect appears on the same page multiple times, with only the first occurrence linked. Tools should correct all like misspellings, including the non-linked ones
  • One "gotcha" to watch out for: a misspelled redirect to a person's name could be the correct spelling of a different person's name, which should be red-linked

-- Wbm1058 (talk) 03:54, 18 November 2016 (UTC)[reply]

In other languages names could be changed heavily due to inflection, not just with suffix rules, and this could make automatic correction difficult. — Jeblad 09:09, 18 November 2016 (UTC)[reply]
This solution is way to heavy for general use. It might be a solution in VisualEditor, but not for general reading of the articles. — Jeblad 19:33, 21 November 2016 (UTC)[reply]
Setting it up may seem complicated, but perhaps it could be made as easy as marking the checkbox to activate a gadget. Once set up, this should be easier and quicker to use than VisualEditor. Wbm1058 (talk) 05:10, 29 November 2016 (UTC)[reply]
I'd appreciate it if anyone fluent in Javascript could answer the question I asked at en:Wikipedia talk:Tools/Navigation popups#Fixing redirects - does it work?. Thanks! Wbm1058 (talk) 16:27, 28 November 2016 (UTC)[reply]
...I think a fix to Popups for this shouldn't be hard to do. I finally have it working; see en:Wikipedia talk:Tools/Navigation popups#Fixing redirects - does it work? for an update and a screenshot! Wbm1058 (talk) 05:10, 29 November 2016 (UTC)[reply]
Yes, both will speed up removal of links that should not be used. This solution makes it possible for all to track them down, no matter if the page is on the watchlist or not. — Jeblad 23:05, 22 November 2016 (UTC)[reply]
We can find important misspellings by using page visits on the redirect. If a redirect has a certain amount of page visits compared to whatever is the correct spelling, then we know that the redirect is important. We don't know why it is important, only that is important in some sense because the redirect has visits. Such numbers are although a bit misleading as we may know that a redirect should be there, but still the traffic number is far to low. This can be important in some languages. It may also be a redirect that is confusing, so it should be removed. — Jeblad 22:00, 29 November 2016 (UTC)[reply]
If spelling corrections were to be prioritized, I would do it by visits to the page with the correct spelling. For example I would prioritize fixing any misspelling of the name of a head of state such as Dilma Roussef (frequently misspelled with only one "f") over fixing a misspelled name of someone who barely survived an article deletion discussion. Wbm1058 (talk) 22:38, 29 November 2016 (UTC)[reply]
  • It seems to me that in the final analysis, making linkclassifier available as a gadget for everyone, along with a default setting for linked-misspellings in the .CSS, solves this. Can we agree this is the solution? By the way, I wasn't aware of this setting, so now I can easily find these linked misspellings in all the articles I come across. This is especially nifty as AWB doesn't correct these. Stevie is the man! Talk • Work 22:45, 30 November 2016 (UTC)[reply]
  • Sounds like something that can easily be fixed by a bot checking and fixing pages linking to {{R from misspelling}} automatically - not much development needed here. Thanks. Mike Peel (talk) 23:52, 2 December 2016 (UTC)[reply]
    Mike Peel, that would have to be a very intelligent bot. It would need to detect vandalism, where someone had tagged a legitimate spelling as an {{R from misspelling}}. It would need to recognize "linked misspellings" that were actually legitimate spellings of another person's name. What we're asking for doesn't require much development, but a good bot would require much more work than implementing a good semi-automated system for humans who can watch over the changes. Why not support something just because it's relatively easy to implement. The bottom line is that this should have been done a decade ago, and still hasn't been finished yet. Wbm1058 (talk) 15:04, 4 December 2016 (UTC)[reply]

Voting – Mark redirects that have typos

  1.   Support--Wbm1058 (talk) 13:13, 29 November 2016 (UTC)[reply]
  2.   Oppose  @xqt 13:59, 29 November 2016 (UTC) Either delete spelling mistakes or use a template but don't use it as redirect. This will be a good reason to update the misspelled link (an can be done by a bot as well).[reply]
  3.   Support --Telaneo (User talk page) 21:38, 29 November 2016 (UTC)[reply]
  4.   Support An apparent solution in the form of a script already exists. Let's make it an easy-to-access gadget with a default setting to show these linked misspellings. Stevie is the man! Talk • Work 22:48, 30 November 2016 (UTC)[reply]
  5.   Support --JB82 (talk) 01:17, 2 December 2016 (UTC)[reply]
  6.   Support --Kvng (talk) 16:24, 2 December 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 23:04, 3 December 2016 (UTC)[reply]
  8.   Oppose--Ranjithsiji (talk) 05:58, 4 December 2016 (UTC)[reply]
  9.   Support --Vicedomino (talk) 18:45, 4 December 2016 (UTC)[reply]
  10.   Support as redlink try template. Beyond marking spelling errors, the wikilink could autocorrect spelling by running a template named as the misspelled word, such as Template:Germeny called from wikilink "[[Germeny]]" when page "Germeny" no longer exists. New template {Germeny} would bluelink "Germany" plus link any related warning categories about internal misspelled links. By using such redlinked template-names to run templates, then bluelinked pages would format as fast as now, but redlinks would check for same-name template before showing actual missing-page redlink if no template. That is a broader solution than just misspelled link, to respell some redlinks by template. -Wikid77 (talk) 10:09, 5 December 2016 (UTC)[reply]
  11.   Oppose Redirects are cheap. A redirect to a misspelling is of course undesirable, but a redirect from a common spelling mistake is actually helpful to readers who misspell the word in the search box. --Tryptofish (talk) 23:09, 5 December 2016 (UTC)[reply]
  12.   Oppose, redirects are cheap indeed, and the best way to manage them can be chosen individually by each project. There is little need in such technical features: for instance, for Ukrainian Wikipedia we would need not only a separate class for misspelled names but also a separate class for redirects from outdated spellings. This should be managed by local templates and local bots — NickK (talk) 17:17, 8 December 2016 (UTC)[reply]

MediaWiki:Edittools section should not be below "Save Changes" but closer to text editing area

Die Zeile mit dem Dropout-Menü unten wo die Klammern, Sonderzeichen etc. abrufbar sind würde sich in größerer/unmittelbarer Nähe zum Bearbeitungsfenster (entweder auch direkt darüber, oder direkt darunter) sehr viel besser handhaben lassen. Dank und Grüße --06:44, 18 November 2016 (UTC)

Community discussion

  • @Lorenz Ernst: Was genau ist das "Bearbeitungsfenster"? Geht es um den klassischen Wikitext-Editor oder um den neueren VisualEditor? Im klassischen Wikitext-Editor sind Sonderzeichen bereits direkt ueber dem Textfeld. Geht es um die "Insertable wiki markup"-Box ganz unten, unter dem Feld fuer die Zusammenfassung? Koenntest Du bitte Deinen Wunsch bearbeiten und aufteilen in die Bereiche "Problem", "Who would benefit / Wer wuerde profitieren", "Proposed solution / Moegliche Loesung" und "Proposer / Vorschlagender", um in der gleichen Form zu sein wie andere Wuensche? Und die Ueberschrift bearbeiten um auszudruecken was gewuenscht wird, da dies kein "Wunsch nach Sonderzeichen" ist? :) (Translation: What exactly is the "editing window"? Is this about the classic wikitext editor or the new VisualEditor? In the classic wikitext editor, the special characters are already directly above the text field. Is this about the "Insertable wiki markup" box at the bottom, below the field for the edit summary? Could you please split your proposal into sections like the other proposals? And edit the summary to express what is requested?) --AKlapper (WMF) (talk) 16:50, 18 November 2016 (UTC)[reply]
Nun danke erstmal, aber hier ist auch schon Schluss. Ich verstehe nicht viel von dem was mir geantwortet wurde und werde auch keine weitere Zeit kompliziert darauf verwenden, das Problem aufzuteilen und umzugestalten. Es ist einfach so: wenn ich editiere und eckige Klammern oder Bindestriche benötige (hier bei Bearbeitung unten nach Insertable wiki markup:) sind die am unteren Bildschirmrand und ich muss scrollen um sie zu verwenden, verliere dabei den eigentlichen Text welchen ich bearbeite aus dem Auge. Wenn ich jedoch eine Fußnote setzten möchte, kann ich das direkt über den Bearbeitungsfenster machen (fängt hier mit B an), kann also die Sonderzeichen bzw. die Toolleiste (?) und den Text gleichzeitig sehen. Für mich wäre es halt eine Vereinfachung, wenn die Sonderzeichen (Klammern, Bindestriche etc.) von unten, so wie sie sind, nach oben kämen. Noch besser wäre natürlich, könnte ich (vll. Jede/r) oben eine individualisierte Toolleiste haben wo ich nur die Zeichen und Befehle (?) hätte die ich benötige. Danke --Lorenz Ernst (talk) 16:20, 19 November 2016 (UTC)[reply]
If I understand everything correctly: The content comes from MediaWiki:Edittools. And that should be way closer to other content (like in the toolbar like other functionality such as adding references) and not just down there. --AKlapper (WMF) (talk) 17:48, 21 November 2016 (UTC)[reply]
I can confirm that the Wikimedia Foundation has a prototype editor with this and several other functionalities. --NaBUru38 (talk)

Voting – Better placement of MediaWiki:Edittools section

  1.   Support --Gerwoman (talk) 18:32, 1 December 2016 (UTC)[reply]
  2.   Support it is an essential requirement--Ranjithsiji (talk) 05:59, 4 December 2016 (UTC)[reply]
  3.   Support - Best regards, Kertraon (talk) 11:44, 4 December 2016 (UTC)[reply]
  4.   Support --Andyrom75 (talk) 08:50, 6 December 2016 (UTC)[reply]
  5. No need for Community Tech here, this can be done by a script locally (already implemented in Ukrainian Wikipedia, for example, but I have no time to find the exact code for this, sorry) — NickK (talk) 17:23, 8 December 2016 (UTC)[reply]
  6.   Support - class="mw-edittools-wiki-markup" must be nearby class="wikiEditor-ui-text" --MatthiasDD (talk) 21:41, 11 December 2016 (UTC)[reply]

Notify editors of detectable errors they have created with an edit

  • Problem: Both new and experienced editors accidentally create errors that they are not aware of and it would be useful to all if this was clearer so editors could self-fix. This is often done by accident while validly fixing other content problems. Examples are:
  • Fixing spelling, typos, styles in media file-names - this has become a daily task to fix and is done by users at all levels
  • Attempting to hot-link image files (often then removing a valid image file) - often done by new users in good faith
  • Fixing spelling, typos, styles in wiki-links, categories, commons cats etc. - although maybe a valid/correct edit an indication that other work (renaming/moving) is needed would be helpful
  • Breaking or adding invalid templates
  • Breaking urls - I know this could be difficult to detect, especially in real-time, but if the software could detect an existing url exists, but the new version returns a 404 it would be great. However this is probably more a function suitable for a bot.
This is especially a problem on big articles where the errors are not visible without scrolling down.
It may be best to start with just the easy to detect: hot-linked media files and breaking (replacing) exiting media with invalid file-names.
  • Who would benefit: Everyone, from new editors to experience editors and all readers
  • Proposed solution: When an edit is saved, and hopefully previewed, clear warning information should be displayed (probably in red) at the top of the page that errors have been introduced to the page. Certain problems such as attempts to hot-link files should always be displayed (with appropriate links to why not valid and how to fix). Other errors such as invalid file-names, categories, commons cats, should maybe only be displayed is they are changes to existing valid fields rather than new 'errors'. Thus invalidly correcting the text in a file-name or wiki-link should always to flagged, but adding a new invalid image should either not be shown or shown as a lesser priority problem (bottom of the list in orange rather than red maybe).
* To clarify - this is only to warn the editor at time of save/preview that a possible error has been introduced accidentally - not to permanently tag the article. This would be like the current red warning messages you get if you preview an article if the infobox has an invalid parameter. i.e.
WARNING! You appear to have broken 3 wiki-links and 2 images with this edit. Please review and check if this was not intended. (links to help/info...)
WARNING! You appear to have tried to hot-link an external media file, this is not possible (links to help/info...)
  • More comments: Warnings of problems should be clear but not require extra clicks to dismiss/acknowledge for experienced users who expect and understand the 'errors' they are creating.
  • Phabricator tickets: none
  • Proposer: KylieTastic (talk) 21:05, 19 November 2016 (UTC)[reply]

Community discussion

  • Hi WhatamIdoing although I'm sure a tool could help some experienced editiors who do a lot of edits catch the odd accident, as you would have to choose to use it then it would not help the magority of problems which are done by new users. I had considered doing a bot that would leave talk page notices like DPL bot but it's still not as good as being informed at the time as a lot of people ignore bot messages or don't see them. KylieTastic (talk) 13:18, 22 November 2016 (UTC)[reply]
    • BracketBot doesn't seem to have solved the very simple problem of unmatched brackets, so I doubt that another message-leaving bot would work. It's possible to force users to preview a page; perhaps that would be more effective (the Chinese Wikipedia, which has articles written in a mix of two different scripts, but displays so that readers can see whichever they prefer, does this). WhatamIdoing (talk) 07:35, 23 November 2016 (UTC)[reply]
  • It seems to me that the editors making mistakes like these will also tend to not fix them, no matter what is done. I think a better approach may be found elsewhere: 1) add articles with such issues to hidden categories, and from there, more experienced editors will discover and fix the problems. 2) for those issues that can be readily caught while saving, perhaps the new "deferred changes" can be configured to catch them, passively or actively. In either case, I'm not sure that we have a WMF-level technical project to pursue. Stevie is the man! Talk • Work 23:50, 30 November 2016 (UTC)[reply]
  • Hi Stevietheman I agree many may not care to fix however there are several categories of people I think would fix: A number of editors in the 50,000+ edits still make infrequent mistakes by volume of edits and thus I think would fix as they are purely accidental; new editors keen on learning and don't understand the technicalities and thus this becomes instant feedback help (they added a similar thing for invalid parameters in infoboxes when you preview). As for you suggestion of adding to hidden categories this is how I currently fix many, all I'm saying is since some of the problems are detected already just tell the editor at the point of the edit and hopefully a number will self-fix, and if not the rest of us will hopefully post fix. Cheers KylieTastic (talk) 18:58, 5 December 2016 (UTC)[reply]

Voting – Notify editors of detectable errors in an edit

  1.   Neutral for now, per my comments above. Stevie is the man! Talk • Work 23:50, 30 November 2016 (UTC)[reply]
  2.   Support Libcub (talk) 02:33, 2 December 2016 (UTC)[reply]
  3.   Oppose --Banfield - Reclamos aquí 15:04, 2 December 2016 (UTC)[reply]
  4.   Support Daylen (talk) 06:11, 3 December 2016 (UTC)[reply]
  5.   Oppose --Ranjithsiji (talk) 05:59, 4 December 2016 (UTC)[reply]
  6.   Support, FWIW. Wbm1058 (talk) 17:19, 4 December 2016 (UTC)[reply]
  7.   Oppose as grandstanding on trivialities. Let me clarify. Many people tag pages with numerous opinions about wrong text, as "This page has multiple issues...blah-blah-blah" ({{Multiple issues}}), or cite templates redflag a page with glaring "Invalid date format in |accessdate=". Instead, I have compared the complaint-messages to en:wp:SOFIXIT and found the best action is, indeed, "So fix the problem" when detected, rather than post glaring messages, but if unable to (auto-)fix, then link the page to an error-warning category for dedicated users to fix. Otherwise, the typical result becomes en:wp:Grandstanding on trivialities, which would likely distract new users from adding new content or rewording or clarifying text due to the need to fix 16 cite dates "10 Dec. 97" to be "10 Dec 1997" as if date mystery. Instead, cite templates should autofix many dates like "20.5.11" as "2011-05-20" and link a date-warning category, rather than saddle other users with "Hear Ye! Hear Ye!" messages pretending nobody knows what ".20." means in a date. A vast number of error messages are repetitive, sub-petty trivia which could be auto-fixed by smarter templates running in the current revision as well as any older revisions to autofix many invalid date formats. Similarly, if "location=" is misspelled as "located=London" then show "located: London[fix]" and link a warning category rather than redflag trivial details into glaring page-top complaints which grandstand on tiny minutia and distract major improvements. -Wikid77 (talk) 08:37/08:43, 5 December 2016 (UTC)[reply]
    Hi Wikid77, I think you miss-understood the proposal - this is not too add any tag to the article, just a one off notice to the editor that introduced the possible errors - much like the red warning message you see if you preview a page with an invalid infobox parameter. I absolutely agree it would be horrible to add a visible tag to a page, it is only a proposal to inform the editor at the time of save/preview that they may have unintentionally caused errors. Cheers KylieTastic (talk) 18:41, 5 December 2016 (UTC)[reply]
  8.   Support - Unsure about false positives. DPdH (talk) 19:44, 8 December 2016 (UTC)[reply]
  9.   Support -- I amhappy to be alerted to any mistakeI am making, in real time.PamD (talk) 10:04, 11 December 2016 (UTC)[reply]
  10.   Support I already subscribe to some tools that do limited things of this sort, like notifying me of links that needs to be disambiguated. More would be great.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:46, 11 December 2016 (UTC)[reply]
  11.   Support Real-time or preview-time alerts about easily-fixable errors, would be great. Help the person making the edit, to improve the quality of their edit. (But without giving a nitpicky overabundance of suggestions). Quiddity (talk) 05:45, 12 December 2016 (UTC)[reply]
  12.   Support Michal Lester לסטר (talk) 11:44, 12 December 2016 (UTC)[reply]
  13.   Support support as proposer KylieTastic (talk) 23:06, 12 December 2016 (UTC)[reply]

Real time group editing

  • Problem: When two or more contributors edit an article at the same time, an edit conflict happens
  • Who would benefit: Everyone editing
  • Proposed solution: Collaborative real-time editing showing who is editing at which moment, like w:Etherpad.
  • More comments: Pictures
Related discussions and proposals

Community discussion

  • How to recognize that somebody is editing? Often somebody clicks edit and then close tab without saving changes or have edit open for long long lime... What about editors without javascript? There should be many false positives... JAn Dudík (talk) 06:34, 15 November 2016 (UTC)[reply]
  • Instead of a warning that the page is being edited, a small notification that says an edit has been saved to the page you're working on. That would eliminate false positives and be more useful/informative. Julia\talk 22:43, 30 November 2016 (UTC)[reply]
    An other option: When you load an edit window, it warns you if someone else has openned a conflicting eidt window in the last X time and neither save dnor cancelled the edit; clicking on the preview and "show changes" buttons would be considered openning an edit window. עוד מישהו Od Mishehu 12:17, 8 December 2016 (UTC)[reply]
  • This would be a major change in wiki-editing style and culture. An improvement in edit conflict handling and resolution that keeps focus on a specific section, would help without the full overhaul. Bcharles (talk) 21:26, 15 November 2016 (UTC)[reply]

Voting – Real time group editing

  1.   Support Léna (talk) 11:14, 28 November 2016 (UTC)[reply]
  2.   Oppose—This would represent a fundamental change to the software, and I don't think that the ripple effects of its complexity would be beneficial, even though it's cool in the short term. More of a direct blocker is that this would be heavily dependent on JavaScript, and it's worth being firm on a requirement for users to be able to edit even with JavaScript disabled. Sure, there are workarounds, but they'd just result in either a) edit conflicts in simultaneous editing sessions (yikes) or b) repeated edit conflicts against the JS-free user that effectively denied them editing. {{Nihiltres |talk |edits}} 21:21, 28 November 2016 (UTC)[reply]
  3.   Oppose I love the creative thinking behind this idea, but I honestly just think it is too advanced for the vast majority of users to wrap their heads around. If this was for enterprise-grade documentation specialists, I would probably find myself more agreeable to the proposal. Stevie is the man! Talk • Work 22:55, 30 November 2016 (UTC)[reply]
  4.   Neutral --Gestumblindi (talk) 21:34, 1 December 2016 (UTC) In most articles, edit conflicts rarely happen. This could be a feature for switching on only in specific articles with lots of concurrent edits due to a current event or the like.[reply]
  5.   Comment In practice, I don't think this concept would be an effective replacement for the existing editor, as very rarely are articles litigated word for word. However, especially in recent articles, there are times when a separate pad would be useful for fleshing out a single paragraph without going back and forth on a talk page. For what it's worth, those editors could split out to any number of existing solutions if they so wanted, but if that type of interaction was encouraged, perhaps it would lead to better drafts. That said, I see this as a minor issue compared to more dire proposals. czar 01:41, 2 December 2016 (UTC)[reply]
  6.   Oppose terribly complex subject, that would fall outside the scope of what the community tech team should focus on. —TheDJ (talk • contribs) 10:13, 2 December 2016 (UTC)[reply]
  7.   Oppose --Banfield - Reclamos aquí 15:05, 2 December 2016 (UTC)[reply]
  8.   Support This should result in less edit conflicts. Emir of Wikipedia (talk) 15:16, 2 December 2016 (UTC)[reply]
  9.   Oppose for the proposal in the peculiarity described here, but   Support for the following: instead of changing the core of Wikipedia, Wikipedia could be extended by this functionality in that WikiProjects and teams could collaborate on articles this way. So a WikiProject could hold an realtime-editing-collaboration-event in which an article is selected (or multiple; by one or multiple of its members) and copied over to such a realtime editor (or a new draft is started). Editing in realtime brings various benefits: things get written much faster, sentences get corrected at the info and grammar level while writing, everybody can bring in something different and isn't expected to do the whole package on their own so to speak - it raises quality, neutrality, consensus etc. and drafts are started much easier. --Fixuture (talk) 18:36, 2 December 2016 (UTC)[reply]
  10.   Comment Cool idea but likely very difficult to implement. Doc James (talk · contribs · email) 03:43, 3 December 2016 (UTC)[reply]
  11.   Comment I appreciate the intention and the idea of this proposal, but like what others said, I'd believe it'd be too difficult to implement. SamanthaNguyen (talk) 23:03, 3 December 2016 (UTC)[reply]
  12.   Support it is very difficult to implement. but as a first step if we can show someone is currently editing the article. or a part of an article then it is more helpfull to others. Collaborative editor is the essential requirement of modern world. but unfortunately it is not happening in wiki.--Ranjithsiji (talk) 06:03, 4 December 2016 (UTC)[reply]
  13.   Oppose I don't see situations where groups of people are rushing to create or add to an article. More trouble than it's worth. How to join group? Can you exclude somebody you don't want? What if you can't agree? --Vicedomino (talk) 18:49, 4 December 2016 (UTC)[reply]
  14.   Oppose I think that the regular editing process accomplishes what we need of this. --Tryptofish (talk) 22:25, 5 December 2016 (UTC)[reply]
  15.   Oppose I agree with Czar and Fixuture: Not for Wikipedia, but maybe for a dedicated side-project that will benefit Wikipedia.
    Cheers, Thouny (talk) 22:27, 5 December 2016 (UTC)[reply]
  16.   Oppose A better way to deal with edit conflicts sounds easier to implement. ArgonSim (talk) 23:02, 5 December 2016 (UTC)[reply]
  17.   Support I like the idea of real-time collaborating on article, which will be very helpful for giving live editing workshop, though I think will be technically very hard to implement. This idea was discussed during Wikimania 2015: "Real-Time Collaborative Editing" though I didn't join the discussion. It would be helpful to add in comments from the attendees of this discussion. Kenrick95 (talk) 05:02, 6 December 2016 (UTC)[reply]
  18.   Support - Good idea, sounds complex so should be investigated and developed in more time than a year. DPdH (talk) 19:47, 8 December 2016 (UTC)[reply]
  19.   Oppose – Would introduce unnecessary complexity to support a rare use case. JFG (talk) 11:06, 11 December 2016 (UTC)[reply]
  20.   Support FoCuSandLeArN (talk) 22:58, 11 December 2016 (UTC)[reply]

Support for reverse sorting different from forward sorting for wikitables

  • Problem: Currently, the wikitables only allow custom forward sorting, but no custom reverse sorting. So, if you have for instance elements (forward sorted)
    • A
    • A,C
    • A,D
    • B
    • C
    • D
and you want reverse sorting to be
  • D
  • A,D
  • C
  • A,C
  • B
  • A
there is no way of doing that.

Community discussion

Stevietheman, sorry for not seeing your comment sooner. "Custom" means "decided by the user by providing a sorting key". This is explained in mw:Help:Sorting#Sorting_rows_of_a_table, with a very simple example where a table containing names is sorted by the last name no matter what is shown in the table. My proposal basically means that we should also have a way to specify a different key for reverse sorting.--Strainu (talk) 09:24, 9 December 2016 (UTC)[reply]
How should the rows in the example above sort if the railway station have more then 2 lines? ... This problem can only solved with a filter for tables. --MatthiasDD (talk) 19:22, 11 December 2016 (UTC)[reply]

Voting – Reverse sorting different from forward sorting for wikitables

  1.   Support as initiator--Strainu (talk) 09:42, 30 November 2016 (UTC)[reply]
  2.   Support Although I've only had this problem once or twice, I do think we should fix it. -- Kndimov (talk) 00:27, 3 December 2016 (UTC)[reply]

table-style template for all Wikis

  • Problem: Formatting tables beyond the limits of Wiki markup currently requires the use of CSS. Although this is not necessarily a major performance issue, typing a lot of per-cell formatting code, is time consuming and error prone, especially for a large or complex table, with a lot of formatting.
    The templated approach at English Wikisource {{ts}} works, and is used quite extensively, but in my view has a slight weakness in that to add format codes, requires that the main parsing template (And associated documentation) be modified indvidually for each new format code.
  • Who would benefit: Table writers, and the developers of certain templates.
  • Proposed solution: Implement a means to use shorthand sequences similar those in currently use within the {{ts}} template on English Wikisource, within the parser itself, so as to ease the generation of tables.
    Ideally, the list of format codes (and their expansions) should in my view be stored separately from the code that does the actual expansion, so that adding a format code can be done independently by approved/ trusted users. A list of "known" shortcodes should also be generated automatically, so that the relevant documentation remains in synch when new shorthand codes are added, or existing ones modified. (Currently on English Wikisource requires the format code to be added directly to the relevant template directly, the documentation having to be updated manually.
    Optionally, it would eventually be nice to have some kind of extension to the Visual Editor which would hide the insertion of the short codes into the underlying markup concerned, but provide the sort of spreadsheet-style formatting users coming from site like Google Docs would be used to.
  • More comments: Some table cells in works on English Wikisource, use a printers convention of 'dotting' white space, although not essential it would be nice to have a way of at least attempting to do add these without the current template overheads ( I appreciate that the current approaches used may be due to HTML limits.)
  • Phabricator tickets:
  • Proposer: ShakespeareFan00 (talk) 12:56, 10 November 2016 (UTC)[reply]

Community discussion

I don't know. inventing a markup language on top of a presentation language... I'd rather see something like Template styles which encourages reuse of an existing presentation language. —TheDJ (talk • contribs) 10:58, 11 November 2016 (UTC)[reply]

My proposed solution: We write the style attribut for all columns only in the first body row (maybe with special class or markup) and the parser copy this styles as standard style in every body row of this table. --MatthiasDD (talk) 20:50, 11 December 2016 (UTC)[reply]

Voting – table-style template for all Wikis

  1.   Oppose proposed solution per TheDJ above but that doesn't mean the stated problem isn't a challenge that should be dealt with. TheDJ and Ryan Kaldari, I think, express ideas with stronger solution potential. Stevie is the man! Talk • Work 00:10, 1 December 2016 (UTC)[reply]

Template for translated articles

  • Problem: Articles are being translated between languages, which is fine. There is a challenge though in the fact, that if you translate an article with its sources, without having consulted the sources, you may risk to redistribute truths or claims that you have not verified yourselves. An easy-to-add template, where all you need to enter would be the name of the original article and its language, would establish a direct connection to and could bring the original article's history and its writer(s) closer to the translated article in the "new" language. If the article translated into the new language is being translated into a third language, the history of the original article should follow.
  • Who would benefit: The original writers would benefit from this because they indirectly would be credited. The readers of the translated article would also benefit from this, because they would be able to see the original poster and its resources through one click, and therefore also be able to critically judge the quality of the article in a different and more profound way.
  • Proposed solution: Make this template easily (and semiautomatically) accessible whilst translating an article from another language. It credits the original authors.
  • Phabricator tickets:
  • Proposer: Orphée (talk) 11:44, 16 November 2016 (UTC)[reply]

Community discussion

Hi Orf3us, Can you add some more information about this idea? What's the problem that this would solve? -- DannyH (WMF) (talk) 01:28, 17 November 2016 (UTC)[reply]

Orf3us Is this proposal basically saying we should handle translations like we do splits, where we post a template on the talk page to point back to the previous article (in this case, on another wiki)? Stevie is the man! Talk • Work 00:21, 1 December 2016 (UTC)[reply]

I guess so, could you please show me an example? I find Gestumblind's description of German wikipedia interesting. Orphée (talk) 18:59, 4 December 2016 (UTC)[reply]

@Orf3us: Re: Translations, e.g. w:no:Diskusjon:Joseph Haydn contains w:no:Mal:Oversatt
Re: Splits, e.g. w:en:Template:Split article is used at w:en:Talk:Naming of comets and at w:en:Talk:Comet.
Re: Imports, see w:de:Special:Log/import or w:no:Special:Log/import etc, with documentation at d:Q8615327#sitelinks-wikipedia.
Hope that helps. Quiddity (talk) 06:17, 12 December 2016 (UTC)[reply]

Voting – Template for translated articles

  1.   Neutral Good idea, but per my understanding of this, templates on various wikipedias could be created for this purpose without the need for WMF involvement. Stevie is the man! Talk • Work 00:23, 1 December 2016 (UTC)[reply]
  2.   Neutral --Gestumblindi (talk) 21:40, 1 December 2016 (UTC) There already is such a template in many language versions of Wikipedia, e.g. en:Template:Translated page. As Stevietheman says, the creation of such templates doesn't require WMF involvement. Additionally, some language versions (e.g. German-language Wikipedia) even routinely import the version history of translated articles, thus retaining all original contributors in the "local" history.[reply]
  3.   Oppose → «« Man77 »» [de] 22:26, 1 December 2016 (UTC)[reply]
  4.   Neutral I do believe that ContentTranslation should automatically tag a translation to the original article and its oldid, but most wikis already have a template for that. ArgonSim (talk) 23:06, 5 December 2016 (UTC)[reply]
@ArgonSim: ContentTranslation does link the original article and oldid in the edit summary, e.g. https://pt.wikipedia.org/w/index.php?title=Especial:P%C3%A1ginas_novas&tagfilter=contenttranslation - But doesn't add anything to the talkpage header templates automatically - are you suggesting that it should do both these things? Quiddity (talk) 06:07, 12 December 2016 (UTC)[reply]
@Quiddity: Yes, mostly because this oldid will get buried when the article history gets too many edits. {{Tradução/ref}} is a nice addition to the article's reference, since it lists both original language and version. As far as I can tell (for pt-wiki, at least), you have to add it manually, and most people simply won't do it. --ArgonSim (talk) 06:20, 12 December 2016 (UTC)[reply]
EDIT: It seems that using this corresponding template on en-wiki has been effectively deprecated, so it doesn't seem like the proposal would be widely accepted. --ArgonSim (talk) 06:27, 12 December 2016 (UTC)[reply]

Tool to list pages with no image

  • Problem: Many articles have no pictures
  • Who would benefit: Readers: better understanding and more visually appealing articles
  • Proposed solution: Tool like those at Special Pages that lists any articles without an image
  • More comments: Potential to encourage editors to contribute useful images to Commons. Potential for encouraging editors to help with descriptions at Commons.
  • Phabricator tickets:
  • Proposer: Tbennert (talk) 06:09, 18 November 2016 (UTC)[reply]

Community discussion

Thanks - I knew there was something for requested images but couldn't find it. What I'm asking for is a bit different. It does not require a tag for an article lacking images. It should catch lesser looked at pages. Plus I don't know if everyone knows about the template, or how often it is used on smaller wikis. It is a start though so I appreciate the comment. Thanks!--Tbennert (talk) 00:08, 22 November 2016 (UTC)[reply]
  • Although I like the general idea, as it does not require someone to have found and requested the images, the list would be huge so it would probably need to be divided maybe by category. That way also people who are only interested in certain topics etc. KylieTastic (talk) 20:18, 19 November 2016 (UTC)[reply]
Excellent suggestion. I was thinking small wikis with fewer articles, but even so the list would be huge. Thanks!--Tbennert (talk) 00:08, 22 November 2016 (UTC)[reply]
  • It would be nice to have a list, but it would be even nicer to have a list that suggests potential sources of images, e.g., a relevant Commons category or links to matching articles in the other language editions of Wikipedia that contain images. So not just "no image in this article", but "no image in this article, and you can probably use the same images that exist in the Foo Wikipedia article about this subject". WhatamIdoing (talk) 23:03, 21 November 2016 (UTC)[reply]
That would be really nice. Make it easier for editors less experienced with Commons to contribute. And I know I've run into plenty of pictures on Commons that are in another language and I have no idea if they are accurate for an article. The Foo Wikipedia selection would really help with that issue. Thanks! --Tbennert (talk) 00:08, 22 November 2016 (UTC)[reply]

Voting – Tool to list pages with no image

  1.   Support I could also see a lot of applications for Wikidata, structured Commons, and GLAM and other partnership models for such a system. Sadads (talk) 14:38, 28 November 2016 (UTC)[reply]
  2.   Support -Nocowardsoulismine (talk) 17:57, 28 November 2016 (UTC)[reply]
  3.   Support – A special page such as Special:PagesWithoutImages can be useful. Guycn2 · ☎ 18:11, 29 November 2016 (UTC)[reply]
  4.   Support Agreed with Guycn2 above. NMaia (talk) 02:21, 2 December 2016 (UTC)[reply]
  5.   Support -- Kndimov (talk) 00:28, 3 December 2016 (UTC)[reply]
  6.   Support Even better if there is a way to filter it. Jo-Jo Eumerus (talk, contributions) 09:39, 3 December 2016 (UTC)[reply]
  7.   Support--Ranjithsiji (talk) 06:04, 4 December 2016 (UTC)[reply]
  8.   Support --By erdo can (talk) 14:18, 4 December 2016 (UTC)[reply]
  9.   Support — Hmxhmx 18:16, 5 December 2016 (UTC)[reply]
  10.   Support — but as per comment in discussion I think this should be sub categorised to firstly break up the list into more manageable sections, and secondly to allow users with interests in certain areas locate areas they can help with. KylieTastic (talk) 19:10, 5 December 2016 (UTC)[reply]
  11.   Oppose I'm not convinced that having the list will result in obtaining the images. --Tryptofish (talk) 22:28, 5 December 2016 (UTC)[reply]
  12.   Neutral I think the other way around would be better: having Commons suggest articles with no image where that picture could be used (Wikidata would be essential for this). ArgonSim (talk) 23:08, 5 December 2016 (UTC)[reply]
  13.   Oppose Not a good use of WMF resources, and articles without images don't necessarily need them. I would prefer to continue to let users request images on talk pages, and voila, these requests fill categories! :) Stevie is the man! Talk • Work 13:51, 6 December 2016 (UTC)[reply]
  14.   Oppose As Stevie is the man! says, not all articles need images; worse still it could encourage copy-vio images to appear at Commons and on BLP pages etc etc. Further, the list would be unmanageably huge... Iadmc (talk) 05:26, 8 December 2016 (UTC)[reply]
  15.   Weak support — Rhododendrites talk \\ 06:24, 8 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Editing&oldid=24950199"