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]