Community Wishlist Survey 2021/Editing

Editing
39 proposals, 552 contributors, 1287 support votes
The survey has closed. Thanks for your participation :)



Unbreak selection in the wikitext editor

Edit proposal/discussion

  • Problem: In the new Wikitext editor, selected text doesn't work with Navigation Popups, so that I can't tell whether a link I just inserted is to the right thing just by selecting it and reading the popup, and when I want to copy and paste text, I can't just select the text and use middle-button paste on Linux: the selected text somehow doesn't get into the primary selection.
  • Who would benefit: Users of Navigation Popups who use the new wikitext editor
  • Proposed solution: I'm not sure what is causing this, so I'm not sure how to fix it.
  • More comments:
  • Phabricator tickets:
  • Proposer: Slashme (talk) 22:03, 21 November 2020 (UTC)

Discussion

  • @Slashme: Are you talking about the meta:2017 wikitext editor? Also Navigation Popups are not shown in any editor, but a similar looking link context is shown in the visual editor. ESanders (WMF) (talk) 16:41, 24 November 2020 (UTC)
    @ESanders (WMF): yes, I'm talking about the 2017 wikitext editor. Thanks for the correction! Without the Editing Toolbar, Navigation Popups does work. I've just tested it. When the editing toolbar is active, it doesn't work. --Slashme (talk) 12:43, 25 November 2020 (UTC)
    NavigationPopups is a community built gadget so I would suggest you talk to the maintainers about this feature request. ESanders (WMF) (talk) 12:14, 28 November 2020 (UTC)
  • Community Tech is happy to work on Navigation Popups, if maintainers will have us. But going directly to them might result in a quicker fix. Thanks for clarifying the issue. MusikAnimal (WMF) (talk) 16:06, 28 November 2020 (UTC)
MusikAnimal (WMF) it's not just about the navigation popups issue: it's also that somehow selected text isn't being seen as selected by the operating system, so that I can't just select text and then middle-button paste it. It would be nice to know whether that's a bug, a feature, or an inevitable side effect of the toolbar. --Slashme (talk) 12:43, 10 December 2020 (UTC)
I'm not sure I quite understand what the proposer is describing, but it really is remarkably problematic not to be able to move text around easily. Selection breaking is why I rarely use the Syntax Highlighter; it breaks the middle-click selection pasting in the editing pane. HLHJ (talk) 21:36, 19 December 2020 (UTC)

Voting

Round brackets

Edit proposal/discussion

Deutsche: Runde Klammern

  • Problem: Sometimes it takes a long time to put the corresponding words or sections in brackets in long lists. Would be nice if there was a tool to speed up this process.
Deutsche: Manchmal dauert es sehr lange bei langen Listen die ensprechenden Wörter oder Abschnitte in Klammern zu setzen. Wäre schön, wenn es ein Werkzeug geben würde, mit dem man diesen Vorgang beschleunigen könnte.
  • Who would benefit: People who work with brackets a lot.
Deutsche: Leute, die häufig mit Klammern arbeiten.
  • Proposed solution: Similar to curly brackets, link brackets or wikilinks, but just round.
Deutsche: Ähnlich wie Geschweifte Klammern, Linkklammern oder Wikilinks nur halt eben rund.
  • Phabricator tickets:
  • Proposer: --Melly42 (talk) 15:37, 24 November 2020 (UTC)

Discussion

  • Hi Melly42. Thanks for this proposal. Would you want to see this implemented in the wikitext editor or in the visual editor, or in both? Also, do want it to work that when you type "(" the editor automatically supplies ")"? How else would you trigger this? —The preceding unsigned comment was added by AEzell (WMF) (talk)
  • I do not understand what you are trying to say. Can you please elaborate on which feature you want? There are already rounded brackets available to use on most keyboards, but they're not meant to be used on the wiki's code since they're used very frequently in the text to highlight comments and such. MarioSuperstar77 (talk) 19:03, 8 December 2020 (UTC)
    • The proposal is also unclear to me. Hazard-SJ (talk) 04:27, 13 December 2020 (UTC)
  • Hello, you can use the old editor's synthax highlighter... Ok, I just tested it and it's no Notepad++. --NaBUru38 (talk) 20:40, 10 December 2020 (UTC)
  • ( ) – Round brackets. --BoldLuis (talk) 13:56, 11 December 2020 (UTC)
  • Sorry for replying lately. I was in a hospital the past two weeks. I wish round brackets in the Visual Editor and the wikitext editor (insertable wiki markup). That means when I mark a text segment both the open bracket and the closed bracket should be set automattically. That might be useful for long species' lists, where you set the Latin name in brackets. --Melly42 (talk) 10:28, 14 December 2020 (UTC)

Voting

Allow the usage of talk page specific markup inside the visual editor

Edit proposal/discussion

  • Problem: Some functionalities that are often used in talk pages are either not present in the visual editor or disabled outside of talk pages and due to that, every article where someone may use either of those features need the wikitext editor. Besides that, regular articles could benefit from more structured listing options and signatures.
  • Who would benefit: Bloggers who use signatures to state when each blog post was created with ~~~. People who wish to have more options for structured lists since currently only "*" (dotted) and "#" (numbered) structured lists are available.
  • Proposed solution: Per the title, create options for ":" and ";" inside the bullet list menu, make it possible to enable signatures on regular articles and enable different signatures such as date only or signature only.
  • More comments: What's above is more important, but I wish it was easier to look for media files with dubious filenames (E.G: 1234567890.jpg) because inputting into the search bar the file name gives a lot of PDF files from commons as a result, but the file in question is nowhere to be found.
  • Phabricator tickets: phab:T39938 Support for creating and editing definition-lists in VisualEditor
  • Proposer: MarioSuperstar77 (talk) 20:01, 18 November 2020 (UTC)

Discussion

  • @MarioSuperstar77: I kind of agree with this, and support it a little bit. Keep it up, and stay safe! MemeGod27
  • Regarding the signature bit, that's already configurable on a wiki level. The $wgExtraSignatureNamespaces config controls what namespaces the signature tool shows up on. Depending on the exact use-case, picking some more namespaces to have it enabled on by default could work (assuming community agreement)... or, more involved, providing some way for a user to override that setting. Choosing the type of signature is a little fiddlier from a visual stance, but we could maybe keep the current "turn it into a preview when you enter the ~~~~" behavior and a single signature menu-item, and then have some options on the signature-preview node that'd let the user toggle the type. DLynch (WMF) (talk) 16:42, 21 November 2020 (UTC)
  • It could be used a hidden template for this Template:TalkVE or another of the proposed solutions.--BoldLuis (talk) 15:15, 11 December 2020 (UTC)

Voting

  • Support Support anythig to make talk pages better, of course Leftowiki (talk) 00:40, 9 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:30, 9 December 2020 (UTC)
  • Support Support Je ne comprends pas la proposition mais je soutiens tout ce qui peut améliorer ou faciliter l'écriture en mode visuel que j'utilise essentiellement. Cdmt' Mylenos (talk) 11:57, 9 December 2020 (UTC)
  • Support Support BoldLuis (talk) 15:15, 11 December 2020 (UTC)
  • Oppose Oppose MW isn't a blogging platform; you're free to bend it into one, but MW devs should spend no time on that, given how much work there is to do building tools for WMF's central mission. Also, there's already an internal mechanism to redefined pages in any namespace as talk pages (that's why things like w:en:WP:ANI and w:en:WP:VPPRO work like talk pages). So, the tools to do make random pages have talk-page features are already inherent in the system anyway.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:56, 15 December 2020 (UTC)
    • Comment Comment Even without the signatures (Which seems to be your main complaint here), having a more diversified structured list menu would not hurt anyone. I already use ; and : lists on my wiki, but they are only available inside the wikitext editor which is an inconvenient bummer. MarioSuperstar77 (talk) 16:47, 15 December 2020 (UTC)

Allow text and table colour to be featured on the visual editor to change

Edit proposal/discussion

  • Problem: There isn't an option to change the colour of the text or table
  • Who would benefit : Editors who can do tables in one go and people who make user pages
  • Proposed solution : Adding the colour option for text and tables for English Wikipedia, using the colour chooser; with the most common colours, consider that it can just be picked off a preset option.
  • More comments: If there is an option to make text bigger, why can't we have the option to change colour?
  • Phabricator tickets:
  • Proposer: Beetricks (talk) 07:25, 17 November 2020 (UTC)

Discussion

  • This has been discussed in previous years. --Izno (talk) 04:59, 18 November 2020 (UTC)
  • Wikipedia is not a colour book. I just like the standard CSS style. If we would require more colors at some places, then we might do this by using CSS code. Only then we are sure that the layout is always coherent. Geert Van Pamel (WMBE) (talk) 18:37, 23 November 2020 (UTC)

Voting

  • Support Support Support for convenience. MarioSuperstar77 (talk) 19:14, 8 December 2020 (UTC)
  • Support Support Arbornaos (talk) 20:00, 8 December 2020 (UTC)
  • Support Support --NGC 54 (talk / contribs) 20:11, 8 December 2020 (UTC)
  • Support Support changing table colour (as in individual cells) as this is an absolute pain when doing up results tables for sports, in that an editor must manually input the colour of every cell in the source editor. On the other hand, I do not support making text colour easier to change as this is significantly easier to do if needed but is not a common enough occurrence to be inconvenient, but could lead to vandalism. 5225C (talkcontributions) 00:09, 9 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:13, 9 December 2020 (UTC)
  • Support Support Omda4wady (talk) 07:13, 9 December 2020 (UTC)
  • Support Support Mylenos (talk) 12:13, 9 December 2020 (UTC)
  • Support Support JPxG (talk) 05:50, 10 December 2020 (UTC)
  • Support Support - yona B. (D) 07:35, 10 December 2020 (UTC)
  • Support Support Euro know (talk) 11:11, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 19:21, 10 December 2020 (UTC)
  • Support Support The easiest, the best. BoldLuis (talk) 15:02, 11 December 2020 (UTC)
  • Support Support. Meiræ 21:28, 11 December 2020 (UTC)
  • Support Support Vince789 (talk) 22:04, 11 December 2020 (UTC)
  • Oppose Oppose Colours should usually be left alone. Oh, DrPizza! (talk) 07:54, 12 December 2020 (UTC)
  • Support Support This is one of remaining reasons why I switch back to wikitext. Papuass (talk) 21:55, 14 December 2020 (UTC)
  • Oppose Oppose Adding semantics (through classes/templates) that use colors would be fine, but do not allow ordinary users to use arbitrary colors. Crissov (talk) 08:54, 16 December 2020 (UTC)
  • Support Support Vikrantkorde (talk) 12:06, 16 December 2020 (UTC)
  • Support Support Xhs 唯心而为 12:18, 16 December 2020 (UTC)
  • Support Support Tratser (talk) 06:38, 20 December 2020 (UTC)
  • Support Support No brainer aegis maelstrom δ 17:38, 21 December 2020 (UTC)

VE makes partially linked words and adds unnecessary tags to the wikitext

Edit proposal/discussion

  • Problem: By creating or changing links in VE (=Visual Editor), it often results unlinked word parts. It is language-dependent, but in some languages using unlinked suffix is never correct. Beside of the incorrect appearance, for example [[word]]s becomes [[word]]<nowiki/>s in the wikicode, and the unnecessary <nowiki/> tag just litter the wikitext and makes it unreadable in more complex situations.
  • Who would benefit: both readers and editors
  • Proposed solution: avoid adding <nowiki /> after links (on wikis, where this is required) (We could use a bot which frequently delete all the <nowiki/> syntax from the wikicode, but that increases the edit number (server traffic) and the length of the page histories. Why don't we just solve the problem rather than always making a mistake and then correct it in a second edit.)
  • More comments: this looks an easy to solve problem to me, but there is no real progress since 2015/16. If some language communities asks for having this behavior default, offer an option to be able to choose per wiki base. On the Hungarian Wikipedia VE has a bad reputation because of this kind of (long-time not solved) bugs and many editors think that we should not use VE at all until it generates clear mistake into the wikitext.
  • Phabricator tickets: T128060
  • Proposer: Samat (talk) 12:49, 29 November 2020 (UTC)

Discussion

I see a use case of this feature, specially in languages which combines words together. For example maybe somebody would link wishlist so, that only the wish or list is linked, because there will never be an article about wishlist. Wishlist is easier, but for wishlist VE should still offer a possible way to create I believe. Samat (talk) 12:56, 29 November 2020 (UTC)

Voting

  • Support Support MarioSuperstar77 (talk) 18:57, 8 December 2020 (UTC)
  • Support Support proposer Samat (talk) 19:02, 8 December 2020 (UTC)
  • Support Support CrystallineLeMonde (talk) 20:12, 8 December 2020 (UTC)
  • Support Support Teemeah (talk) 20:41, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:08, 9 December 2020 (UTC)
  • Support Support A longstanding issue with VE that I've seen a lot in practice. I had the sense that on the English Wikipedia this was one of the main reasons VE has a bad reputation too. — Bilorv (talk) 09:01, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 14:51, 11 December 2020 (UTC)
  • Support Support OosWesThoesBes (talk) 17:19, 11 December 2020 (UTC)
  • Support Support I would love to see this change made in VisualEditor. It irks me when I change a linked term (either by pluralising it or decapitalising the first letter) and it creates a few unnecessary bytes in the source code via piping. Tenryuu (talk) 21:29, 11 December 2020 (UTC)
  • Support Support the nowiki tags also annoys me when editing in VE LM150 (talk) 22:12, 12 December 2020 (UTC)
  • Support Support Tgr (talk) 08:10, 13 December 2020 (UTC)
  • Support Support Yes, this is annoying. Papuass (talk) 21:52, 14 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:05, 15 December 2020 (UTC)
  • Support Support Tacsipacsi (talk) 09:58, 16 December 2020 (UTC)
  • Support Support Vikrantkorde (talk) 12:07, 16 December 2020 (UTC)
  • Support Support this is one of the reasons I avoid VE! It's so great for adding citations but then I feel the need to switch back into source to remove all the nowiki tags and change words to words. Enwebb (talk) 16:24, 16 December 2020 (UTC)
  • Support Support Kku (talk) 06:48, 17 December 2020 (UTC)
  • Support Support Grüße vom Sänger ♫(Reden) 22:16, 18 December 2020 (UTC) VE is creating lot's of such useless, sometimes really annoying, clutter. It should behave in an acceptable way, without doing stuff, that's unwanted
  • Support Support Afernand74 (talk) 13:14, 20 December 2020 (UTC)
  • Support SupportOmegatron (talk) 15:05, 20 December 2020 (UTC)
  • Support Support EEMIV (talk) 14:55, 21 December 2020 (UTC)

Predictive edit summaries based on changes to article text

Edit proposal/discussion

  • Problem: Some edit summaries take longer to write than the edits themselves. Editors write edit summaries in jargony shorthand unfriendly to new editors ("r/re" for reply, "ce" for copyedit, if there is an edit summary at all).
  • Who would benefit: Page history readers and new editors
  • Proposed solution: Identify common types of edits and either offer or default to suggested edit summaries for simple edits: replies (new, indented comments), minor copyedits (a few characters tweaked), resolving an error, adding/removing X parameter in Y citation, all things a computer can identify.
  • More comments:
  • Phabricator tickets:
  • Proposer: czar 01:54, 22 November 2020 (UTC)

Discussion

Voting

  • Support Support Imetsia (talk) 18:47, 8 December 2020 (UTC)
  • Neutral Neutral Modern browsers can already remember edit summaries you've made. MarioSuperstar77 (talk) 19:22, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:03, 9 December 2020 (UTC)
  • Support Support + more checkboxes (or auto filling edit summary based on) for minor changes (like typo; categotries etc.) - often summary is longer than correction. => uniffied entries. Zombie(CZ) (talk) 11:43, 9 December 2020 (UTC)
  • Support Support - --Mylenos (talk) 11:46, 9 December 2020 (UTC)
  • Support Support Libcub (talk) 19:17, 10 December 2020 (UTC)
  • Oppose Oppose Even if mostly accurate (which I believe would take a huge amount of work), you might spend more time checking accuracy and correcting mistaken suggestions than you would just typing "copyedit", or forget to check and leave misleading summaries all over the place (or if it forces you to accept the predicted summary then we're back to the problem of this being slower than not having the feature). I think people type "ce" because they don't care, not because it's too cumbersome to. This is a user behaviour problem, not an interface problem. — Bilorv (talk) 09:58, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 15:00, 11 December 2020 (UTC)
  • Support Support Daylen (talk) 20:03, 11 December 2020 (UTC)
  • Support Support Helder 09:55, 12 December 2020 (UTC)
  • Oppose Oppose per Bilorv. Frankly, when WMF's devs can't even get basic HTML-specs-compliance taken care of, after 15+ years of the same bug reports about the same problems being open, the idea of them taking on advanced AI stuff is both wrongheaded and farcical.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:49, 15 December 2020 (UTC)
  • Support Support Wolfmartyn (talk) 14:15, 16 December 2020 (UTC)
  • Support Support Neon Richards (talk) 23:08, 18 December 2020 (UTC)
  • Oppose Oppose I could imagine a scenario in which this proposal and one further up about checkboxes for types of minor edits kind of pool together -- edit summary tags, for example. But anyway. This seems like something I'd probably turn off the first few times the suggestions are just wrong, ya know? EEMIV (talk) 14:54, 21 December 2020 (UTC)

Request to amend the preview of the "NoteTag" template (请求修正“NoteTag”模板的预览)

Edit proposal/discussion


  • Problem:{{NoteTag}} is widely used to add notes in articles. But there is a unfixed bug: this template will show a blue subscript (styled as [note 1] or [a] [b]), but the pop-up preview shows an icon of reference (an icon of book and text "Reference"). Footnote does not equal to reference. They are two different concepts, so the display must be made reasonable.
  • Who would benefit: All wikipedia users
  • Proposed solution: Remove the icon of "Reference", or develop another pop-up window to separate explain-notes and ref-notes.
  • More comments:
  • Phabricator tickets:
  • Proposer: 蕭漫 (talk) 02:44, 27 November 2020 (UTC)
  • Translator: Steven Sun (talk)

Discussion

Voting

Warn when linking to disambiguation pages

Edit proposal/discussion

  • Problem: Between 500 and 800 links are added to disambiguation pages each day. This means readers are less likely to get directly to a relevant article when they click on a link and instead are shown a list of possible matches for the term. A recent en RFC to en:Wikipedia:Village pump (proposals)#Make links to disambiguation pages orange by default suggested coming to the community wishlist.
  • Who would benefit: Readers - in helping them get to the relevant article and editors in not having to fix bad links.
  • Proposed solution: A warning message appearng on preview or publish when adding a link to a dab page asking whether the editor really wanted to do this.
  • More comments:
  • Phabricator tickets: T97063
  • Proposer: Rodw (talk) 08:34, 27 November 2020 (UTC)

Discussion

Sure, but if you know enough to install a userscript like that, you're probably already checking for accidental dabs. A warning to newer users along the lines of "are you sure you wanted to link to this page" seems like a good idea IMO, as long as there were an easy way to resolve it (i.e. pop up options linked from the dab page). — Rhododendrites talk \\ 17:54, 29 November 2020 (UTC)
  • On enwiki, even editors who wanted to link to this page should do so via its X (disambiguation) redirect. A simple warning would be very helpful to readers and to those of us who mend such links. A way to choose a correction and replace [[Mercury]] by [[Mercury (planet)|Mercury]], etc. would be even better. Certes (talk) 13:26, 1 December 2020 (UTC)
    Code to pick the correct link could be shared with a Dablinks replacement. Certes (talk) 17:10, 9 December 2020 (UTC)
  • For the solution. It can ask if you want to preview the disambiguation page in another browser window or tab. The user could surf from there to a disambiguated page (then could click a button in VE to add this page instead of the disambiguation page)--BoldLuis (talk) 14:39, 11 December 2020 (UTC)
  • As an easy solution, to activate this option for all your wikis, you can edit m:Special:MyPage/global.css to contain:
.mw-disambig { background-color:#AFEEEE; }
.mw-redirect { background-color:wheat; }

Geert Van Pamel (WMBE) (talk) 13:25, 12 December 2020 (UTC)

  • Thanks for this but I suspect most editors don't do this (or may not even know about it) otherwis we wouldn't be getting 500-800 links to dab pages being created every day.Rodw (talk) 11:55, 15 December 2020 (UTC)
    So this is why we want a global solution, thanks to the below "Support" votes... Geert Van Pamel (WMBE) (talk) 13:38, 15 December 2020 (UTC)
  • Heißt das, der Haken beim Begriffsklärungscheck (d:Q6047536) sollte automatisch gesetzt sein? Denn die Funktionalität ist ja schon lange vorhanden, auch ohne dafür zum Scriptkiddie mutieren zu müssen. Grüße vom Sänger ♫(Reden) 09:38, 19 December 2020 (UTC)
    This Gadget seems not to be available on all Wikis? Geert Van Pamel (WMBE) (talk) 16:23, 20 December 2020 (UTC)
Of course it's available on all Wikis, it only has to be implemented by the local communities. So there is nothing to do here for the devs, it's an existing gadget. Grüße vom Sänger ♫(Reden) 16:41, 20 December 2020 (UTC)
Thanks for clarifying this. Geert Van Pamel (WMBE) (talk) 19:02, 20 December 2020 (UTC)
  • Ruwiki solution:
    ru:MediaWiki:Gadget-disambiguationLinks.css
    ru:MediaWiki:Gadget-disambiguationLinks.js Carn (talk) 20:13, 19 December 2020 (UTC)
  • Comment Comment I supported this, but only on the assumption that implementation will focus on solving the problem in a modern and user-friendly manner, and not merely implement the disruptive workflow currently hinted at in the comments. I think it'd be a lot simpler and better for everyone if we focus on the act of writing itself. In the visual editor, we can prompt users contextually right as they are creating or inspecting a link, and suggest one of the destinations from the disambiguation page instead, at which point we can have a list of suggestions right there. A similar thing could be done in the 2017 wikitext editor, and even in the 2010 editor when using the dialog to create a link. I don't think this is important enough to distract readers with, nor to inject a primitive warning forcibly into the save workflow. Doing so would, I think, drain considerable amounts of energy and will power from contributors to still continue with their edit, and much more to actually rediscover and address the issue itself. That sounds more like abuse mitigation, and less like contributor education. --Krinkle (talk) 03:28, 21 December 2020 (UTC)

Voting

  • Support Support ValeJappo【〒】 18:29, 8 December 2020 (UTC)
  • Support Support Could be a convenient way to know whether a page is a direct link to an article or not. I will add that we should do that with redirects too if possible. MarioSuperstar77 (talk) 18:29, 8 December 2020 (UTC)
  • Support Support Eridian314 (talk) 18:30, 8 December 2020 (UTC)
  • Support Support Dr747 (talk) 19:14, 8 December 2020 (UTC)
  • Support Support DragonHawk (talk) 19:27, 8 December 2020 (UTC)
  • Support Support Quarz (talk) 20:08, 8 December 2020 (UTC)
  • Support Support MichaelMaggs (talk) 20:21, 8 December 2020 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:40, 8 December 2020 (UTC)
  • Support Support Berdajeno (talk) 20:41, 8 December 2020 (UTC)
  • Support Support Stryn (talk) 20:53, 8 December 2020 (UTC)
  • Support Support A subject expert who adds a link is better placed to pick its correct target than a polymath gnome. Certes (talk) 20:53, 8 December 2020 (UTC)
  • Support Support Pi.1415926535 (talk) 20:57, 8 December 2020 (UTC)
  • Support Support Silver hr (talk) 21:09, 8 December 2020 (UTC)
  • Support Support KTC (talk) 21:11, 8 December 2020 (UTC)
  • Support Support Kisnaak (talk) 21:21, 8 December 2020 (UTC)
  • Support Support Pmau (talk) 21:23, 8 December 2020 (UTC)
  • Support Support Nw520 (talk) 22:46, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:34, 8 December 2020 (UTC)
  • Support Support Redactedentity (talk) 23:47, 8 December 2020 (UTC)
  • Support Support 5225C (talkcontributions) 00:10, 9 December 2020 (UTC)
  • Support Support RXerself (talk) 00:34, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 01:05, 9 December 2020 (UTC)
  • Support Support Alkari (talk) 01:39, 9 December 2020 (UTC)
  • Support Support * Pppery * it has begun 02:01, 9 December 2020 (UTC)
  • Support Support Keepcalmandchill (talk) 02:37, 9 December 2020 (UTC)
  • Support Support Shizhao (talk) 02:55, 9 December 2020 (UTC)
  • Support Support // Lollipoplollipoplollipop :: talk 03:18, 9 December 2020 (UTC)
  • Support Support Ezlev (talk) 03:46, 9 December 2020 (UTC)
  • Support Support Flipchip73 (talk) 04:32, 9 December 2020 (UTC)
  • Support Support —— Eric Liu留言百科用戶頁 04:34, 9 December 2020 (UTC)
  • Support Support This would hopefully eliminate a tedious maintenance task, freeing up editor resources. {{u|Sdkb}}talk 05:52, 9 December 2020 (UTC)
  • Support Support Xgeorg (talk) 06:54, 9 December 2020 (UTC)
  • Support Support P40fA (talk) 07:03, 9 December 2020 (UTC)
  • Support Support Mbkv717 (talk) 07:11, 9 December 2020 (UTC)
  • Support Support Ardub23 (talk) 07:53, 9 December 2020 (UTC)
  • Support Support No such user (talk) 08:44, 9 December 2020 (UTC)
  • Support Support Nurg (talk) 09:12, 9 December 2020 (UTC)
  • Support Support SunDawn (talk) 10:37, 9 December 2020 (UTC)
  • Support Support Lion-hearted85 (talk) 10:55, 9 December 2020 (UTC)
  • Support Support JAn Dudík (talk) 11:01, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:08, 9 December 2020 (UTC)
  • Support Support Sakretsu (炸裂) 11:36, 9 December 2020 (UTC)
  • Support Support 1Mmarek (talk) 11:49, 9 December 2020 (UTC)
  • Support Support Lugnuts (talk) 12:30, 9 December 2020 (UTC)
  • Support Support MilkyDefer (talk) 12:46, 9 December 2020 (UTC)
  • Support Support Would help to optimize usability both for readers and editors. Jjkorff (talk) 13:31, 9 December 2020 (UTC)
  • Support Support Hb2007 (talk) 14:12, 9 December 2020 (UTC)
  • Support Support and ability to open it and choose the correct link would be even better Kaybeesquared (talk) 14:14, 9 December 2020 (UTC)
  • Support Support Mannivu · 15:02, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 15:23, 9 December 2020 (UTC)
  • Support Support Em-mustapha User | talk 15:50, 9 December 2020 (UTC)
  • Support Support Lirazelf (talk) 16:54, 9 December 2020 (UTC)
  • Support Support আফতাবুজ্জামান (talk) 17:38, 9 December 2020 (UTC)
  • Oppose Oppose Honestly, with so much concern over people mixing things up, there's not enough disambiguation in Wikimedia, and this would just be a deterrent. Tyrekecorrea (talk) 19:35, 9 December 2020 (UTC)
  • Support Support Paul1764 (talk) 20:46, 9 December 2020 (UTC)
  • Support Support Browk2512 (talk) 21:17, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 22:39, 9 December 2020 (UTC)
  • Support Support dwf² (talk) 22:54, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 01:52, 10 December 2020 (UTC)
  • Support Support Nyq (talk) 02:14, 10 December 2020 (UTC)
  • Support Support JPxG (talk) 05:52, 10 December 2020 (UTC)
  • Support Support - yona B. (D) 07:34, 10 December 2020 (UTC)
  • Support Support Szczot3k (talk) 08:03, 10 December 2020 (UTC)
  • Support Support extremely needed feature. —Omnilaika02 (talk) 11:29, 10 December 2020 (UTC)
  • Support Support Mike Peel (talk) 13:28, 10 December 2020 (UTC)
  • Support Support disambiguation links are almost never intentional, except in hatnote templates Dexxor (talk) 16:17, 10 December 2020 (UTC)
  • Support Support Afernand74 (talk) 20:15, 10 December 2020 (UTC)
  • Support Support Srđan (talk) 22:05, 10 December 2020 (UTC)
  • Support Support  Swazmo DiscBlanco.svg DiscWikiP.svg 22:56, 10 December 2020 (UTC)
  • Support Support Geniac (talk) 07:21, 11 December 2020 (UTC)
  • Support Support Adamoszkovics (talk) 10:20, 11 December 2020 (UTC)
  • Support Support Paucabot (talk) 12:17, 11 December 2020 (UTC)
  • Support Support Strong support. Must be prioritary. BoldLuis (talk) 14:35, 11 December 2020 (UTC)
  • Support Support ArnabSaha (talk) 15:11, 11 December 2020 (UTC)
  • Support Support Asartea Talk (Enwiki Talk (preferred)) 16:08, 11 December 2020 (UTC)
  • Support Support Bencemac (talk) 16:11, 11 December 2020 (UTC)
  • Support Support StringRay (talk) 16:23, 11 December 2020 (UTC)
  • Support Support Noel baran (talk) 16:52, 11 December 2020 (UTC)
  • Support Support Szalax (talk) 16:52, 11 December 2020 (UTC)
  • Support Support James Martindale (talk) 16:56, 11 December 2020 (UTC)
  • Support Support warning in preview but no warning modal, in which we risk losing the edit altogether czar 17:10, 11 December 2020 (UTC)
  • Support Support --Gereon K. (talk) 17:40, 11 December 2020 (UTC)
  • Support Support KasciJ (talk) 18:17, 11 December 2020 (UTC)
  • Support Support Anaxial (talk) 18:52, 11 December 2020 (UTC)
  • Support Support --Andyrom75 (talk) 19:19, 11 December 2020 (UTC)
  • Support Support This would be useful outside of the Wikimedia world as well. -Xbony2 (talk) 19:21, 11 December 2020 (UTC)
  • Support Support --Kusurija (talk) 19:25, 11 December 2020 (UTC)
  • Support Support Wutsje (talk) 20:02, 11 December 2020 (UTC)
  • Support Support. Meiræ 21:45, 11 December 2020 (UTC)
  • Support Support Prioritizing improvements that increase human productivity is strategic, and preventing problems in the first place is helpful. -- Beland (talk) 08:18, 12 December 2020 (UTC)
  • Support Support Jingkaimori (talk) 08:54, 12 December 2020 (UTC)
  • Support Support Helder 09:56, 12 December 2020 (UTC)
  • Support Support Francois-Pier (talk) 10:45, 12 December 2020 (UTC)
  • Support Support ~Cybularny Speak? 11:20, 12 December 2020 (UTC)
  • Support Support Tom Ja (talk) 12:38, 12 December 2020 (UTC)
  • Support Support Ad Huikeshoven (talk) 14:36, 12 December 2020 (UTC)
  • Support Support TheLatentOne (talk) 19:55, 12 December 2020 (UTC)
  • Support Support Theshumai (talk) 22:19, 12 December 2020 (UTC)
  • Support Support Vincent Simar (talk) 22:42, 12 December 2020 (UTC)
  • Support Support Emperork 🐋🐰 00:16, 13 December 2020 (UTC)
  • Support Support Kew Gardens 613 (talk) 02:38, 13 December 2020 (UTC)
  • Support Support TeKaBe (talk) 07:52, 13 December 2020 (UTC)
  • Support Support Edgars2007 (talk) 10:26, 13 December 2020 (UTC)
  • Support Support Gufosowa (talk) 10:50, 13 December 2020 (UTC)
  • Support Support Kaviraf (talk) 20:06, 13 December 2020 (UTC)
  • Support Support Podzemnik (talk) 21:14, 13 December 2020 (UTC)
  • Support Support Kimsey0 (talk) 22:21, 13 December 2020 (UTC)
  • Support Support β16 - (talk) 16:16, 14 December 2020 (UTC)
  • Support Support Papuass (talk) 21:42, 14 December 2020 (UTC)
  • Support Support and agree with Kaybeesquared: ability to open the disambiguation link and choose the correct link would be even better. RavBol (talk) 22:08, 14 December 2020 (UTC)
  • Support Support WTM (talk) 00:30, 15 December 2020 (UTC)
  • Oppose Oppose As noted above, this is already provided several times over by user-level JS and CSS. The MW devs have no reason to waste resources reinventing this wheel.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:33, 15 December 2020 (UTC)
  • Oppose Oppose per SMcCandlish's summary. I think there needs to be a really strong reason for new editors to be presented with a message and their edit unexpectedly not being saved, as it's a steeper learning curve, more time involved to make a simple change, and the person may not understand that their edit has not gone through and exit the page. 500 to 800 per day doesn't seem unreasonable, particularly given that many can be ignored given that they are from Articles for Creation drafts that will be insta-declined or edits not in article space etc. Experienced editors should be reminded of the options they have to be able to catch themselves before (or after) introducing dab links. — Bilorv (talk) 14:18, 15 December 2020 (UTC)
  • Support Support Definitely would come in handy for me Thanks, EDG 543 (message me) 15:13, 15 December 2020 (UTC)
  • Support Support Mollifiednow (talk) 18:08, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:17, 15 December 2020 (UTC)
  • Support Support Vacant0 (talk) 18:38, 15 December 2020 (UTC)
  • Support Support Vincent Ramos (talk) 19:27, 15 December 2020 (UTC)
  • Oppose Oppose per other opposers. This functionality does not need to be globalized, and there's no indication that this particular mistake needs to be warned against compared to any other mistake that could be made when editing a page. There are already methods to find disambiguation links in the bodies of mainspace articles, (i.e. the DAB orange link gadget,) so the errors are easily fixable, especially if you notify the user who introduced the DAB link by undoing their edit so that they know to be mindful in the future. I don't believe we automatically warn users for any other type of mistake that could be made, so I fail to see why this particular issue is worth the change. And if this does get implemented, I would hope this only applies in the mainspace or can be turned off in some way, because I would hate to be warned if I'm linking to a DAB page on a talk page or something along those lines. And even then, there are definitely reasons to link to DAB pages in mainspace articles anyway. I think the biggest problem with this proposal is that it would ignore context, which I think it does, at the proposal apparently just throws a warning if a DAB page is ever linked to. What if I want to link to that DAB page via a See Also section, or god forbid I use an about template. I could very well be misinterpreting the proposal, but I would rather continue edit with as few automatic warnings as possible, and there are good reasons to link to disambiguation pages as well that unfortunately appear as if they will be included in the warnings. Utopes (talk) 19:48, 15 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 21:01, 15 December 2020 (UTC)
  • Support Support Does anyone think a similar fuction when editing would be benficial for editors? DMT biscuit (talk) 21:44, 15 December 2020 (UTC)
  • Oppose Oppose Per SMcCandlish's rationale. This calls for the pertinent CSS/JS scripts to be ported to the projects who want them, it doesn't call for the WMF to reinvent the wheel. Jo-Jo Eumerus (talk, contributions) 13:56, 16 December 2020 (UTC)
  • Support Support Wolfmartyn (talk) 14:21, 16 December 2020 (UTC)
  • Support Support no brainer, and skips the talk page message the next day from DPL bot Enwebb (talk) 16:28, 16 December 2020 (UTC)
  • Support Support Dankowski (talk) 20:31, 16 December 2020 (UTC)
  • Oppose Oppose as others have noted, this may discourage (and be confusing to) new editors and it is a generally easy problem to fix already. --Ita140188 (talk) 02:18, 17 December 2020 (UTC)
  • Support Support Risk Engineer (talk) 15:43, 17 December 2020 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 02:04, 18 December 2020 (UTC)
  • Symbol strong support vote.svg Strong support ingenious idea! JN Dela Cruz (talk) 16:45, 18 December 2020 (UTC)
  • Support Support Mmitchell10 (talk) 20:02, 18 December 2020 (UTC)
  • Support Support Nadzik (talk) 11:57, 19 December 2020 (UTC)
  • Oppose Oppose Grüße vom Sänger ♫(Reden) 15:46, 19 December 2020 (UTC) Gibt's schon, da muss nichts neu entwickelt werden. Ist ein Helferlein (Gadget), das nur angekreuzt werden muss.
  • Oppose Oppose A link to a dab page is among the least significant errors that can occur in a newly contributed text and I see absolutely no reason to start harassing editors about it even more than we already do (on enwiki, they'd get a talk page message from DPLbot about the dablink any way). Also, this was proposed, and rejected, on enwiki back in 2016. Uanfala (talk) 17:32, 19 December 2020 (UTC)
  • Any change should exclude deliberate disambiguation links, the ones with "(disambiguation)" on the end; warning for this would just be annoying. Any warning should also mention this option. Would support visually distinguishing disambiguation links from links to pages. Since I enabled showing them in orange I've added far fewer unintentional DAB links; I catch it in preview. It's also useful as a reader, just as redlinks are. We might need to think about exactly how to distinguish, but readers would soon learn a new convention. HLHJ (talk) 18:29, 19 December 2020 (UTC)
  • Support Support Fringilla (talk) 19:49, 20 December 2020 (UTC)
  • Oppose Oppose, we already have a gadget that can highlight disambiguation links. T. Le Berre, the french serpent à plumesTry and talk to me buddy 01:08, 21 December 2020 (UTC)
  • Support Support, I'm supporting this on the assumption that implementation will focus on solving the problem in a modern and user-friendly manner, and not merely implement the disruptive workflow currently hinted at in the comments. --Krinkle (talk) 03:26, 21 December 2020 (UTC)
  • Support Support :JarrahTree (talk) 08:58, 21 December 2020 (UTC)
  • Support Supporttyseria 10:10, 21 December 2020 (UTC)
  • Support Support Rzuwig 11:20, 21 December 2020 (UTC)
  • Support Support David1010 (talk) 13:07, 21 December 2020 (UTC)
  • Support Support Wikipedia is about the reader, and it needs to be easy to read and coherent in order to get the information across to the reader. I believe that wikilinks are the backbone of wikipedia, and when clicked, it should bring you to the article you expect, not a disambiguation page. This policy would provide an easy way for editors to recognize disambiguation page links, and alter them to send the reader to the proper page. JazzClam (talk) 14:05, 21 December 2020 (UTC)
  • Oppose Oppose I was a strong support until I saw 1) this is do-able on a per-user JS basis and, 2) saw that this could introduce friction for novice editors. EEMIV (talk) 14:40, 21 December 2020 (UTC)
  • Support Support Mykola7 (talk) 14:52, 21 December 2020 (UTC)

Edit 'macros'

Edit proposal/discussion

  • Problem: I observe this on en.wikipedia, but it is likely everywhere. On en.wikipedia certain mainspace tags get a date. So if one adds {{fact}}, a bot follows up and changes it in {{fact|date=November 2019}}. That results in a second edit, sometimes conflicting with your follow-up edit.
  • Who would benefit: globally
  • Proposed solution: I suggest to write create the possibility to have 'macros', that result in pre-safe modification of the addition of {{fact}} and automatically adds the |date={{{CURRENTMONTH}}} {{{CURRENTYEAR}}}
    Obviously, it needs to be namespace-limited, and probably be handled by a protected page so that you don't get the vandal-addition of abusive macros. And one could consider to have a pre-save check there as well ('Wikipedia executed the following macro(s) on your written text: <list of macros>. Please [accept] or [reject] the changes made by the macro(s).', upon which the page is really saved).
  • More comments:
  • Phabricator tickets:
  • Proposer: Dirk Beetstra T C (en: U, T) 12:41, 30 November 2020 (UTC)

Discussion

  • {{subst:}} with a suitable template can already be used to achieve this. --Dominic Z. (talk) 20:06, 10 December 2020 (UTC)
    • @Dominic Z.: If you talk only about templates, maybe. But there are also cases like 'ISBN #######' ('magic word') which on en.wikipedia is by bot replaced with {{ISBN|#######}}. I maybe should have been clearer in that above. --Dirk Beetstra T C (en: U, T) 06:19, 13 December 2020 (UTC)
  • Some templates, when the parameter "time" is mandatory, coulde include the nowadays date and time by default.--BoldLuis (talk) 14:13, 11 December 2020 (UTC)
  • en:Wikipedia:AutoHotkey can be used as partial solution to this. --Papuass (talk) 21:44, 14 December 2020 (UTC)

Voting

  • Support Support MarioSuperstar77 (talk) 18:33, 8 December 2020 (UTC)
  • Support Support Shoeper (talk) 18:52, 8 December 2020 (UTC)
  • Support Support Ponor (talk) 22:07, 8 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 01:03, 9 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 03:51, 9 December 2020 (UTC)
  • Support Support No such user (talk) 09:14, 9 December 2020 (UTC)
  • Support Support --Magol (talk) 11:30, 9 December 2020 (UTC)
  • Support Support JPxG (talk) 05:51, 10 December 2020 (UTC)
  • Support Support Szczot3k (talk) 08:00, 10 December 2020 (UTC)
  • Support Support BoldLuis (talk) 14:13, 11 December 2020 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 16:40, 11 December 2020 (UTC)
  • Support Support Helemaal als dit kan voorkomen dat botjes die bij het toevoegen van zo'n datum ook andere, ongerelateerde en niet altijd oncontroversiële bewerkingen doen ("meenemen"), waarbij bijvoorbeeld de "onderwatercode" naar hun persoonlijke smaak wordt ingericht. Wutsje (talk) 20:09, 11 December 2020 (UTC)
  • Support Support DGG (talk) 01:19, 12 December 2020 (UTC)
  • Support Support as proposer. --Dirk Beetstra T C (en: U, T) 05:37, 13 December 2020 (UTC)
  • Oppose Oppose We have bots for a reason. The fact that they do stuff, and it involves edits, is a given, not a problem. If you're tired of seeing bot edits in your watchlist, turn them off. This is not something MW devs should waste any resources on.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:18, 15 December 2020 (UTC)
    That's not a solution: We still don't see the interesting edit. (It might be a solution if the Watchlist simply displayed the last change matching the filter.) ◅ SebastianHelm (talk) 12:28, 16 December 2020 (UTC)
  • Support Support because it's silly to not see the actual meaningful change. (See discussion above.) ◅ SebastianHelm (talk) 12:28, 16 December 2020 (UTC)
  • Support Support PeacefulJack (talk) 10:16, 17 December 2020 (UTC)
  • I don't support the proposed solution, because I think it wastes human time, but I do support attempts to solve this problem. Being edit-conflicted by a bot is silly, and it occurs and annoys me with some frequency; mostly Anomiebot is the one that edit-conflicts me (I appreciate the automatic adding of the date, just not the edit conflict). A simpler solution might be to have the editing interface silently roll back any bot edits which would otherwise edit-conflict a non-bot editor, and notify the bot. Or just have AnomieBot wait until the manual editor has stopped editing for an hour. HLHJ (talk) 22:51, 19 December 2020 (UTC)

Allow past edits to be filtered by size

Edit proposal/discussion

  • Problem: Records of edits, whether in page history, recent changes patrol or user edit history are often crowded by relatively insignificant minor edits, making it difficult to find edits that have made more substantial changes and therefore require greater scrutiny.
  • Who would benefit: Editors interested in reviewing major changes to Wikipedia.
  • Proposed solution: Enable records of edits to be filtered by the size of the change (by specific number characters added or removed).
  • More comments:
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:46, 20 November 2020 (UTC)

Discussion

  • This would be handy. I often want to find just the major contributions while looking at my watchlist or at an article's history. Abductive (talk) 11:43, 22 November 2020 (UTC)
  • How about merging all recent edits by the same editor into one, and then showing diffs (each edit in different color, perhaps)? I assume most edits are good; if one is bad, you go back and check one by one. Ponor (talk) 21:28, 22 November 2020 (UTC)
  • See also Miscellaneous/Add filters to history pages. the wub "?!" 15:43, 30 November 2020 (UTC)
  • Changes that are small in size are not necessarily minor in content. Sneaky vandalism or falsification can radically change content with a zero-byte change. Nurg (talk) 08:55, 9 December 2020 (UTC)
  • Une modification peut être désignée comme mineure ou apparaître comme mineure (1 lettre, 1 mot changé, voire une ponctuation) et pourtant, être du vandalisme ou une modification importante à vérifier. Cdmt' --Mylenos (talk) 12:19, 9 December 2020 (UTC)

Voting

  • Neutral Neutral I genuinely fail to understand how that feature will be useful to anyone. MarioSuperstar77 (talk) 18:36, 8 December 2020 (UTC)
  • Support Support Jax MN (talk) 18:41, 8 December 2020 (UTC)
  • Support Support --NGC 54 (talk / contribs) 19:40, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:15, 9 December 2020 (UTC)
  • Support Support —— Eric Liu留言百科用戶頁 04:33, 9 December 2020 (UTC)
  • Support Support Xinbenlv (talk) 05:55, 9 December 2020 (UTC)
  • Support Support P40fA (talk) 07:02, 9 December 2020 (UTC)
  • {{Neutral}} vs {{oppose}} (n'écrivant qu'en mode visuel, je ne sais pas écrire "contre" en code - Mylenos (talk) 12:23, 9 December 2020 (UTC)
    • Comment Comment @Mylenos: Veux-tu que je t'aide? Si tu es contre quelque chose, tu peux utiliser {{oppose}} MarioSuperstar77 (talk) 13:55, 9 December 2020 (UTC)
    • Merci Mario. (Voilà encore un problème rencontré par les contributeurs du mode visuel ; et je ne sais pas écrire le petit "+" vert. Pas grave.) Cordialement' - Mylenos (talk) 21:59, 11 December 2020 (UTC)
  • Support Support Would help to save time in monitoring Jjkorff (talk) 13:34, 9 December 2020 (UTC)
  • Support Support Drernie (talk) 04:21, 10 December 2020 (UTC)
  • Support Support Toom0007 11:22, 12 December 2020 (UTC)
  • Support Support Ad Huikeshoven (talk) 14:35, 12 December 2020 (UTC)
  • Support Support TheLatentOne (talk) 19:58, 12 December 2020 (UTC)
  • Support Support Yes, but as one of several better filtering options, like by user, by section edited, by string/regex in the edit, etc.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:41, 15 December 2020 (UTC)
  • Support Support RanuKanu (talk) 09:43, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 12:57, 15 December 2020 (UTC)
  • Support Support רון18 (talk) 07:31, 16 December 2020 (UTC)
  • Support Support If there was an option, then of course the usage of Wikipedia would become more versatile and handier. Thanks! JN Dela Cruz (talk) 16:43, 18 December 2020 (UTC)
  • Support Support but I think we may need to think about UI design, and not simply filter by text size change. This ties into other proposals for better diffs like Better diff handling of paragraph splits and Copy and paste from diffs. I recall a tool by Wikimedia Deutschland which had an excellent visual interface for choosing diffs. If you are interested in ANY large edits, the Listen to Wikipedia visualization has actually been useful. HLHJ (talk) 22:39, 19 December 2020 (UTC)
  • Support Support EEMIV (talk) 14:47, 21 December 2020 (UTC)

Make insertable markup customizable

Edit proposal/discussion

  • Problem: List of markups to insert (insertable wiki markup) is currently limited too much
Currently, there are 36 predefined markups (insertable wiki markup) at the bottom of the page (in the 2010 editor), and you only need to click on one of these to insert it in the article (examples from Wikipedia in French: [[Catégorie:]] [[Fichier:]] [[Media:]] [[Spécial:Diff/]] [[Spécial:Contribs/]] #REDIRECTION [[]] · [[commons:|]] [[m:|]] [[n:|]] [[q:|]] [[s:|]] [[b:|]] [[wikt:|]] [[v:|]] [[d:|]] · <></> <code></code> <math></math> <small></small> <u></u> <ref></ref> <ref name=""></ref> {{Références}} <noinclude>, etc.
For example, I would like to be able to insert with one click the following code, which I would have customized myself, which takes a very long time to write in manual mode:
<ref>{{Ouvrage|auteur=|titre=|année=|éditeur=|tome=|page=|pages totales=|lire en ligne=|consulté le=}}</ref>
  • Who would benefit: Everyone
  • Proposed solution: It would be extremely useful to allow each user to create predefined markups (insertable wiki markup) and make them available in the already existing list in order to be able to insert them with a single click. It would be super fast!
  • Phabricator tickets:
  • Proposer: Tubamirum (talk) 20:36, 17 November 2020 (UTC) (French Wiki)

Discussion

Sorry, my bad. I support this if you mean something like "own charinsert" Patsagorn Y. (Talk) 01:39, 19 November 2020 (UTC)

@Tubamirum: I've written such script for Ukrainian wikipedia (uk:MediaWiki:Gadget-ImprovedEditTools.js), it has edit dialog and serializes your insertions to this format: uk:User:AS/AStools.js. The only drawback is that it has to use your subpage as data storage, because Mediawiki devs can't add local metadata for years. I think it would make sense to have native solution with proper backend storage and plugins support. AS (talk) 17:06, 7 December 2020 (UTC)

@AS: your tool is very intresting. Another option could be saving them on the device via mw.store ValeJappo【〒】 18:35, 8 December 2020 (UTC)
Nah, localStorage is not persistent enough for some use cases. AS (talk) 20:01, 8 December 2020 (UTC)

This and Tool for easy user buttons should probably be merged. They're essentially same task, the difference is only which controls on page you want to bind with your insertion functions. AS (talk) 20:01, 8 December 2020 (UTC)

@Tubamirum: Try Using AutoHotKey macros to make typing – and life – easier (other, similar, tools are available). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:44, 8 December 2020 (UTC)

This is basically the same as "Tool for easy user buttons" (below), just without the button. Both are fine. Either one needs to happen yesterday. Don't particularly care which. --Joalbertine (talk) 16:25, 17 December 2020 (UTC)

Voting

  • Support Support That would definitely be far more convenient for editors to be able to just paste a long string of code than write all that code just to get the same effect. MarioSuperstar77 (talk) 18:39, 8 December 2020 (UTC)
  • Support Support AS (talk) 20:01, 8 December 2020 (UTC)
  • Support Support Kisnaak (talk) 21:24, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:09, 9 December 2020 (UTC)
  • Support Support No such user (talk) 09:10, 9 December 2020 (UTC)
  • Support Support --Timeshifter (talk) 08:37, 10 December 2020 (UTC)
  • Support Support --Green fr (talk) 18:41, 11 December 2020 (UTC)
  • Support Support very important; there are workarounds for some parts of this, but a built in feature would be much better DGG (talk) 01:24, 12 December 2020 (UTC)
  • Support Support Wedhro (talk) 20:06, 12 December 2020 (UTC)
  • Support Support Gufosowa (talk) 10:50, 13 December 2020 (UTC)
  • Support Support Krzysiek 123456789 (talk) 13:17, 14 December 2020 (UTC)
  • Support Support I actually like this version better than the one way up above, to allow customizable buttons (since this version doesn't require any icons).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:40, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:00, 15 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 21:23, 15 December 2020 (UTC)
  • Support Support Lt2818 (talk) 14:45, 16 December 2020 (UTC)
  • Support Support Joalbertine (talk) 16:32, 17 December 2020 (UTC)
  • Support Support Shenme (talk) 01:18, 18 December 2020 (UTC)
  • Support Support David1010 (talk) 13:10, 21 December 2020 (UTC)

Allow editors to write an edit summary from the edit preview

Edit proposal/discussion

  • Problem: After making an edit, I view a preview of the newly edited page before I describe what I've changed. Then, in the preview, there is no place to describe what I've changed before publishing unless I go back, which is a bit clumsy.
  • Who would benefit: Page editors and trackers of changes
  • Proposed solution: Add a "Describe what you changed" text box to the top of the preview edit page next to "Publish changes" so that is is easily visible and easily accessed.
  • More comments:
  • Phabricator tickets:
  • Proposer: BenJenkins (talk) 16:40, 17 November 2020 (UTC)

Discussion

This would be useful, I like the idea. I've been keeping notes in a separate editor. A little notebook could even be there while we're editing: done with a chapter, enter changes, continue to the next one. Ponor (talk) 17:01, 17 November 2020 (UTC)

  • I'd even go one further: With the addition of this functionality, it would then become desirable if we could choose an alternative workflow: Preview First, Preview Always. (Perhaps selected via an editing preferences checkbox, like "Prompt me when entering a blank edit summary" or our old, departed friend "Mark all edits minor by default".)
With the option enabled, an edit could progress from the editor interface, directly to Preview (including edit-summary field), and finally submitting the edit directly from the Preview view — never even seeing the redundant, unnecessary "Save your changes" popup.
We're always reminding our fellow editors "WP:TWWPK", and admonishing new Wikipedians whose edits are reverted that they need to Use The Preview™[, Luke?] (There's even a dedicated user warning template for that exact purpose.) The ultimate adherence to that philosophy would be (optionally) telling the system that you want to always preview every edit, automatically, before the option to submit is even presented. -- FeRDNYC 03:13, 18 November 2020 (UTC)
Preview first is already an option though.... --Izno (talk) 05:23, 18 November 2020 (UTC)
@Izno: How so? "Show preview on first edit" is still a checkbox in the Editing preferences, but as far as I can tell it does nothing for either of the Visual Editor's modes. (Visual editing mode doesn't have a Preview at all, only Review, so I guess it's not really relevant to any of this.) But in the wikitext mode, even with the preference switched on "Publish changes..." still takes you to the "Save your changes" popup, and you have to manually hit "Show preview" to preview the edit. -- FeRDNYC (talk) 18:19, 19 November 2020 (UTC)
Well, you don't need a preview in VE. But okay, the context for your comment is good since it wasn't clear you were talking about 2017 WTE. :) --Izno (talk) 23:22, 19 November 2020 (UTC)
  • I can't tell if this is for VE or for WTE, but I'd take it for wikitext editor in a heartbeat! --Izno (talk) 05:21, 18 November 2020 (UTC)
    • The proposer uses the 2017 wikitext editor (VisualEditor's wikitext mode). Whatamidoing (WMF) (talk) 06:35, 18 November 2020 (UTC)
  • I have the "alert me if I don't use an edit summary" preference checked, and whenever I do this (which is pretty much every edit) it takes me back and tells me to put an edit summary in. Certainly not an airtight solution, and I would like to see your suggestion implemented. Ghinga7 (talk) 17:24, 19 November 2020 (UTC)
  • This is phab:T140451 and/or phab:T148297. ESanders (WMF) (talk) 15:56, 24 November 2020 (UTC)
  • Also, (temporary) Edit Summary should not be lost when switching between Visual Editor & Source Editor. RavBol (talk) 22:49, 14 December 2020 (UTC)

I've just lost another Edit Summary after switching between Visual Editor & Source Editor on mobile, again...! RavBol (talk) 23:46, 4 April 2021 (UTC)

  • Huh? Is this specific to the mobile version, or VisualEditor, or ...? I don't have this problem. I load the page to edit, and I already have an "Edit summary:" line. I click "Show preview", and I now have a preview, and the edit window again, and the "Edit summary:" line again. There is no need to go back.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:46, 15 December 2020 (UTC)

Voting

Markdown syntax to wiki link conversion gadget

Edit proposal/discussion

  • Problem: I frequently add new web citations via firefox extensions such as Markor. apk and haven't found any link capture application that outputs link to Clipboard as wiki-text.
  • Who would benefit: Markdown citeweb user
  • Proposed solution: A new /user.js + /user.css toggle and or extension.
  • More comments:
  • Phabricator tickets: N/A: If only user-javascript without needing any other than simple documentation.
  • Proposer: Mkouklis(2) (talk) 03:42, 17 November 2020 (UTC)

Discussion

  • There's some future where this will be possible directly on the wiki, but of course that day is not today. Would be a neat thing to have a converter today of course, but I'm not sure of the practicality or driving need. --Izno (talk) 18:07, 17 November 2020 (UTC)
  • Can you link the tool you use? It's unclear to me what difficulty you're describing. If you are looking to generate web citations from webpages and convert to wikitext, you can use Zotero, which has many translators for specific websites. Different wikis have tools based on Citoid, which uses Zotero's translators to generate citations for the Visual Editor. Sounds like you're looking for that? (not watching, please {{ping}}) czar 17:14, 11 December 2020 (UTC)
    • Zotero will also auto-retrieve and format metadata like title, authors, etc.. On-wiki, Citoid does the same. Can you explain how this differs from what you are looking for, Mkouklis(2)? HLHJ (talk) 21:40, 19 December 2020 (UTC)

Voting

  • GA candidate.svg Weak support Why not? MarioSuperstar77 (talk) 19:11, 8 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 03:57, 9 December 2020 (UTC)
  • Support Support Xinbenlv (talk) 05:54, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 18:03, 9 December 2020 (UTC)
  • Support Support Szczot3k (talk) 08:04, 10 December 2020 (UTC)
  • Support Support BoldLuis (talk) 14:43, 11 December 2020 (UTC)
  • Symbol strong support vote.svg Strong support Having markdown support would be great -- and will be much better than the VE or the 2017 editor. acagastya 16:23, 11 December 2020 (UTC)
  • Support Support Shisma (talk) 19:30, 11 December 2020 (UTC)
  • Support Support S8321414 (talk) 14:12, 21 December 2020 (UTC)

Include "This is a minor edit" box in mobile editing

Edit proposal/discussion

  • Problem: When one edits a page in mobile view using the MobileFrontend extension, no checkbox is provided for marking the edit as a minor edit.
  • Who would benefit: Everyone
  • Proposed solution: When editing a page in mobile view, include the "This is a minor edit" box.
  • More comments:
  • Phabricator tickets: T123694
  • Proposer: GeoffreyT2000 (talk) 20:35, 16 November 2020 (UTC)

Discussion

  • Why? I mean, I think there have been more calls to remove the 'minor edit' than to add it to mobile, where it almost never applies anyway just based on how much vandalism happens from mobile. --Izno (talk) 21:51, 16 November 2020 (UTC)
    I'm not sure if not supporting the feature for a subset of mobile users (seems like it's partially supported) is a good approach, though. If it's not being removed from MediaWiki, I think it makes sense to properly support it on mobile (especially given that it's apparently available in the mobile visual editor). Perhaps it could be hidden with CSS on a case-by-case basis, or the ability to mark edits as minor could be a separate user right if it is/becomes a major problem for vandalism. Hazard-SJ (talk) 05:16, 13 December 2020 (UTC)
  • I've noticed this missing. Yes, lots of vandalism happens from mobile, but discriminating against users by platform doesn't seem appropriate. I'd like to see this done. {{u|Sdkb}}talk 02:39, 17 November 2020 (UTC)
  • As someone who enjoys making gnomic/minor edits, and who sometimes edits on a mobile device, I like this idea. Noahfgodard (talk) 05:10, 17 November 2020 (UTC)
+1 to this! --Slashme (talk) 21:53, 21 November 2020 (UTC)
  • I agree that we should be consistent across platforms. The mobile editing interface needs much improvement. Lots of vandalism may happen on your particular project on mobile, but it's the only way many people in developing countries have access to Wikipedia. — Bilorv (talk) 18:04, 17 November 2020 (UTC)
  • FYI The minor checkbox appears in the mobile visual editor. ESanders (WMF) (talk) 17:11, 24 November 2020 (UTC)

Voting

  • Support Support Imetsia (talk) 18:45, 8 December 2020 (UTC)
  • Support Support MarioSuperstar77 (talk) 19:06, 8 December 2020 (UTC)
  • Support Support Gabrasca (talk) 21:28, 8 December 2020 (UTC)
  • Support Support Ok, good idea شادي (talk) 22:15, 8 December 2020 (UTC)
  • Support Support 5225C (talkcontributions) 00:09, 9 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:32, 9 December 2020 (UTC)
  • Support SupportBilorv (talk) 01:39, 9 December 2020 (UTC)
  • Support Support BugWarp (talk) 01:50, 9 December 2020 (UTC)
  • Support Support * Pppery * it has begun 01:59, 9 December 2020 (UTC)
  • Support Support I use MobileFrontEnd extension to make some gnome edits, and I think the "This is a minor edit" box would be useful. Sashatrk (talk) 04:57, 9 December 2020 (UTC)
  • Support Support {{u|Sdkb}}talk 05:29, 9 December 2020 (UTC)
  • Support Support P40fA (talk) 07:06, 9 December 2020 (UTC)
  • Support Support Mbkv717 (talk) 07:14, 9 December 2020 (UTC)
  • Support Support Opalzukor (talk) 07:59, 9 December 2020 (UTC)
  • Support Support Kettchaap (talk) 08:37, 9 December 2020 (UTC)
  • Support Support No such user (talk) 08:59, 9 December 2020 (UTC)
  • Support Support Danbloch (talk) 09:11, 9 December 2020 (UTC)
  • Support Support Brewster239 (talk) 12:37, 9 December 2020 (UTC)
  • Support Support Zoizit (talk) 17:13, 9 December 2020 (UTC)
  • Support Support BladeRikWr (talk) 22:20, 9 December 2020 (UTC)
  • Support Support dwf² (talk) 22:54, 9 December 2020 (UTC)
  • Support Support - yona B. (D) 07:37, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 18:59, 10 December 2020 (UTC)
  • Support Support  Swazmo DiscBlanco.svg DiscWikiP.svg 22:50, 10 December 2020 (UTC)
  • Support Support BoldLuis (talk) 15:04, 11 December 2020 (UTC)
  • Support Support StringRay (talk) 16:26, 11 December 2020 (UTC)
  • Support Support DemonDays64 (talk) 18:38, 11 December 2020 (UTC)
  • Support Support Wanax01 (talk) 15:50, 12 December 2020 (UTC)
  • Support Support Ivanics (talk) 19:03, 12 December 2020 (UTC)
  • Support Support I think adding this makes sense for feature parity, especially since it is already being shown in some cases on mobile. Hazard-SJ (talk) 05:16, 13 December 2020 (UTC)
  • Support Support -- the wub "?!" 18:30, 13 December 2020 (UTC)
  • Support Support Dan100 (talk) 18:03, 14 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:17, 15 December 2020 (UTC)
  • Support Support Vacant0 (talk) 18:39, 15 December 2020 (UTC)
  • Support Support Mohanad Kh Talk 06:20, 16 December 2020 (UTC)
  • Support Support PinkPanda272 (talk) 08:52, 16 December 2020 (UTC)
  • Support Support this, and also feature-parity for edit summaries. Pelagic (talk) 22:46, 17 December 2020 (UTC)
  • Support Support JN Dela Cruz (talk) 16:38, 18 December 2020 (UTC)
  • Support Support, if it's useful on one platform it's useful on both. And it seems more likely that a mobile edit will be minor, given the interface discourages typing at length. HLHJ (talk) 18:14, 19 December 2020 (UTC)
  • Support Support Anomlia (talk) 09:43, 20 December 2020 (UTC)
  • Support Support Shagil Kannur (talk) 10:30, 20 December 2020 (UTC)
  • Support Support Malvinero10 (talk) 02:37, 21 December 2020 (UTC)
  • Support Supporttyseria 10:07, 21 December 2020 (UTC)
  • Support Support EEMIV (talk) 14:50, 21 December 2020 (UTC)
  • Support Support Schniggendiller (talk) 17:39, 21 December 2020 (UTC)
  • Support Support — Baidax 💬 17:58, 21 December 2020 (UTC)

Select templates by categories

Edit proposal/discussion

  • Problem: When contributors try to add templates to a page in visual editor or wikitext editor, we have to remember the accurate full name or prefix of the template.
  • Who would benefit: Everyone who want to add templates but don't know the accurate templates names.
  • Proposed solution: In most of wikis, templates were classified into categories by purpose and functions. We can add a templates browser to visual editor and wikitext editor, allowing contributors to browse and select templates by categories.
  • More comments:
  • Phabricator tickets: phab:T55590
  • Proposer: Steven Sun (talk) 01:11, 18 November 2020 (UTC)

Discussion

  • This is phab:T55590. ESanders (WMF) (talk) 16:55, 24 November 2020 (UTC)
  • I'll support this if it will work just by using existing categories. Developing a whole new template classification and search feature would be a bad idea until a full-fledged Global templates repository is implemented. --Amir E. Aharoni (talk) 18:58, 26 November 2020 (UTC)

Voting

List of nested templates

Edit proposal/discussion

  • Problem: When editing template, I can see on the bottom other templates used by this template, but only these, which are not nested in some {{{#if:}}.
  • Who would benefit: Template editors, and people who want to copy a template to another wiki.
  • Proposed solution: Search template for all{{foo}} which does not begin with # and are not in commonts.
  • More comments: The same for modules (here with require)
  • Phabricator tickets:
  • Proposer: JAn Dudík (talk) 15:18, 18 November 2020 (UTC)

Discussion

Voting

  • Support Support This feature needs an overhaul. MarioSuperstar77 (talk) 19:07, 8 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 03:46, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 15:19, 9 December 2020 (UTC)
  • Support Support Libcub (talk) 18:52, 10 December 2020 (UTC)
  • Support Support. Meiræ 21:33, 11 December 2020 (UTC)
  • Support Support Rdyornot (talk) 22:26, 12 December 2020 (UTC)
  • Support Support Wikibenchris (talk) 08:52, 13 December 2020 (UTC)
  • Support Support Definitely. Debugging complex templates is a massive headache, in large part because "walking the entire tree" of what they can do is a totally manual process, and it need not be.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:19, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:02, 15 December 2020 (UTC)
  • Support Support Kku (talk) 06:58, 17 December 2020 (UTC)
  • Support Support PrimaLInnstinct (talk) 20:48, 17 December 2020 (UTC)
  • Support Support Golmore (talk) 11:11, 18 December 2020 (UTC)

Add global LaTeX macros for math in math tags

Edit proposal/discussion

  • Problem: Certain math symbols, such as absolute value and expected value, are very tedious to type and make editing more cumbersome and error-prone.
  • Who would benefit: Anyone who types lots of math equations and uses proper symbols for spacing (ex. not just using pipe character for absolute value).
  • Proposed solution: A community-decided global list of macros enabled for anyone using math tags.
  • More comments: For example, if it is declared globally \DeclarePairedDelimiter\abs{\lvert}{\rvert}, then editors may type \abs{x} instead of \lvert x \rvert. Similarly for expected value, editors would avoid typing \operatorname{E} all the time. I proposed this last year at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_177#Equation_\operatorname_macros%3F where it got some interest and positive reception, though ultimately not implemented.
  • Phabricator tickets:
  • Proposer: Wqwt (talk) 01:22, 18 November 2020 (UTC)

Discussion

@Wqwt: you might be interested in joining Wikimedia Community User Group Math. There are several possibilities:

  • MathJax which we use to generate the formulas offers this possibility to define macros [1]. The problem with this is that unfortunately we do not use MathJax out-of-the-box but still have the setup (state-of-the-art 10 years ago), where people get delivered images of equations. Each formula is treated separately, which makes it impossible to have features other websites (like math.stackexchange you mention in village-pump) offer, i.e. macro definitions valid for several equations, cross-referencing equation numbers, automatic line-breaking and for me most annoying: Adjusting the math font properly to the text font.
  • Then, we have a list of global declarations already. They were defined in a pre-processing step called "texvc" which was needed when LaTeX was used to generate the images. Unfortunately some of the (re)definitions done in this pre-processing break any LaTeX document. We try to get rid of them so you can offer a LaTeX packet [2] and a corresponding MathJax packet [3] to render all Wikipedia equations with LaTeX or MathJax without the need for any pre-processing. Those macro definitions unfortunately do not contain useful things currently, e.g. in Wikipedia you can write \isin (like the html entity name) instead of \in or my personal favorite: You can write \varcoppa if you want to print \mbox{\\coppa}
  • I am not entirely against adding unproblematic definitions that are actually useful to this texvc package. However for pretty much all set of macros that people consider generally useful there are existing LaTeX packages. The \abs command you mention is part of the physics package [4] (and possibly others) in LaTeX and for this physics package there is also an equivalent MathJax package [5]. Unfortunately currently we do not include the physics package. Including such a package is very simple you want to do it on your own website. Unfortunately we in Wikipedia still have some remnants of texvc floating around where you have to try to teach it the behavior of all new macros so it does not reject or wrongly modify your code and secondly we are unfortunately not running the current version MathJax3, but the old MathJax2 and I am not entirly sure if the whole functionality of the physics package is also available in the old version.

@Physikerwelt: is of the very few volunteers, if not the only one, maintaining the math extension. There are plans to switch to MathJax3 and HTML rendering, he can probably tell more.--Debenben (talk) 22:04, 20 November 2020 (UTC)

  • Just a side remark. I personally am in favour of keeping the the approach to maintain a whitelist of allowed commands and to automatatically reformat LaTeX code to a standard format, w.r.t, to spacing and standard arguments. Adding new commands is thus independent of MathJax 2/3 which will primarily improve the rendering as described above. This being said, you or someone with basic programming skills can propose new aliases by extending this list:

https://github.com/wikimedia/mediawiki-services-texvcjs/blob/master/lib/texutil.js Note, that this will be availible to all wikis in all languages and all projects. Thus these additions should be very conservative. Moreover, the consensus on the changes by the Wikimedia Community User Group Math is required. --Physikerwelt (talk) 13:39, 27 November 2020 (UTC)

@Physikerwelt: Thank you for taking the time to answer and I am afraid it sounds ungrateful for all the work you have been doing over all the years, but I feel like can not leave your statement here without answer.
Maybe something changed that I am unaware of, but to my understanding texvcjs still tries to "validate" the expression. Consider e.g. the request for the \middle command task T137788. There is no reason to not support it, it does not need to be defined and would be supported already if texvc would not block it. In the ticket you say "a skilled nodejs programmer with a good understanding of a parser [...] should be able to implement it in two days." Just for this one command! There would be about 96 commands like this in the physics package.
Validating LaTeX without parsing the whole expression is like validating c++ code without compiling it. With the normal definitions "\sigma" is valid, "\color{blue}" is valid, "\color{\sigma}" is not. To determine if "\color{\sigma}" is valid you need to know the definition of \sigma, evaluate it, feed the result to the \color command and see if it can handle the input. This macro expansion is done in Mathjax already, why replicate it? You could simply go through the list of commands [6] and not load the packages and commands you don't want, that needs less than 2 days.
And the argument with spaces I also don't understand: Very often editors put unnecessary spaces and linebreaks in the code on purpose to improve readability. If you really need them removed, you can take MathJax and convert LaTeX->MathML->LaTeX which also takes less than 2 days. Note that the original form is more valuable, it contains the same information as the "validated" expression and additional information to improve readability of the source code which is lost in the conversion.--Debenben (talk) 22:33, 28 November 2020 (UTC)

Voting

Tool for easy user buttons

Edit proposal/discussion

  • Problem: Users can make their own buttons for better editing, which insert to edit area some templates, parts of code or patterns.

    This can be done by editing user javascript page. But majority of users is not skilled enough to make these buttons, only some of them copy it from other users, but when some problem occurs, they are not able to repair it.

  • Who would benefit: Editors
  • Proposed solution: Make some extension, where every user can easily make his own buttons.
    Tool can be based on User:Krinkle/Scripts/InsertWikiEditorButton.js. There will be table in the special:preferences
active name text before cursor text after cursor picture tooltip
X coord {{Coord|lat |lon|}} Button Globe.png Coordinates
X hello Hello world Button bienvenido.png insert hello world
O speedy {{Delete}} Button tidyman.png nominates for deletion
X char ʘ Ping button.png some weird character
  • Values from table will be copied to script (with escaping problematic characters) by tool and user can easily make another buttons without care about script changes or about malicious script.
  • More comments: originally proposed in 2019 survey
  • Phabricator tickets:T136152
  • Proposer: JAn Dudík (talk) 09:36, 23 November 2020 (UTC)

Discussion

  • @JAn Dudík: The #5 wish of the 2017 Wishlist was the Template Wizard. Are all the insertions that you're thinking of with these custom buttons related to inserting templates? If so, does the template wizard suffice? I guess the big difference is that the user has to know what the template is called because they need to search for it in the wizard, but the other functionality seems to be there, along with a good interface for inserting particular parameters etc. —Sam Wilson 10:00, 23 November 2020 (UTC)
    • It is probably not the same. My proposal is about buttons, which can insert any string, either{{Template foo|with parameters}} as lorem ipsum or . Somebody uses it for inserting single characters (eg. some ligatures in wikisource, ipa chars on wiktionary etc.), somebody for article skeleton, somebody for template. JAn Dudík (talk) 13:50, 23 November 2020 (UTC)
  • Yes, I wanted to come up with a similar proposal. This would be really useful. Another point is that the bad code is often copied over many JS pages making these codes inefficient. — Draceane talkcontrib. 17:36, 24 November 2020 (UTC)
  • This proposal reminds me of an older feature request to allow the definition of a number of scrap-macros in preferences by inserting user-definable keywords (like @mymacro1@) into the wiki markup which would be expanded according to their definition by the frontend when pressing "save". For users of visual frontends, such keywords could be dropped into the source by buttons or hotkeys, so it would work regardless of the way a user edits a page. (See [[7]]) Is this about what you want to accomplish as well? --Matthiaspaul (talk) 19:36, 25 November 2020 (UTC)
    Not exactly. if I write @coord@, I am not able to add parameters. And there is no difference between @coord@ and {{subst:User/mytemplate}}. With button I can easily insert to text empty template {{Coord||}} and only add values.
    Big pain of modern UI in many programs is ribbon menu, where are groups of tools and only one of them is active. But when I want use one or two tools in every group, i must permanently switch. In current wikitext editor is <nowiki> in one submenu, character t͡s in second and cite tools in third. ANd some more useful things are under textarea. But my user buttons are in the top, accesible from all submenus. JAn Dudík (talk) 20:54, 25 November 2020 (UTC)

Voting

  • Support Support Imetsia (talk) 18:43, 8 December 2020 (UTC)
  • Doubtful It is doubtful This could be a convenient feature, but I am not sure whether it is important enough or not for Wikipedia right now since the buttons are used exclusively on user profiles. MarioSuperstar77 (talk) 18:52, 8 December 2020 (UTC)
  • Symbol strong support vote.svg Strong support There are contents (templates, patterns of wikicode...) that I add very often, as a patroller, and beeing able to easily customize my wikitext editor toolbar with buttons that insert customized patterns would be very usefull. — Jules Talk 23:11, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:10, 9 December 2020 (UTC)
  • Support Support 1Mmarek (talk) 11:55, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 22:38, 9 December 2020 (UTC)
  • Support Support // Lollipoplollipoplollipop :: talk 05:39, 10 December 2020 (UTC)
  • Support Support --Omnilaika02 (talk) 11:31, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 19:04, 10 December 2020 (UTC)
  • Support SupportBilorv (talk) 09:53, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 15:20, 11 December 2020 (UTC)
  • Support Support. Meiræ 21:48, 11 December 2020 (UTC)
  • Support Support Robins7 (talk) 22:15, 11 December 2020 (UTC)
  • Support Support DGG (talk) 01:02, 12 December 2020 (UTC)
  • Support Support Podzemnik (talk) 21:20, 13 December 2020 (UTC)
  • Support Support This, or something like it (e.g. a custom drop-down menu in the editing tools below the editing window) would be super-badass.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:55, 15 December 2020 (UTC)
  • Support Support Yes please! — Draceane talkcontrib. 13:01, 15 December 2020 (UTC)
  • Support Support Sultec (talk) 11:18, 17 December 2020 (UTC)
  • Symbol strong support vote.svg Strong support OMG Yes! This would have saved me hours on Wikisource! (Proof-reading and styling, adding the same few templates over and over and over again!) Take my money! --Joalbertine (talk) 15:29, 17 December 2020 (UTC)
  • Support Support --Dick Bos (talk) 16:14, 17 December 2020 (UTC)
  • Support Support --Sphilbrick (talk) 14:04, 19 December 2020 (UTC)
  • Support Support Would be useful. Uanfala (talk) 23:48, 19 December 2020 (UTC)
  • Support Support Shagil Kannur (talk) 10:36, 20 December 2020 (UTC)
  • Support Support Iva (talk) 18:24, 20 December 2020 (UTC)
  • Support Support David1010 (talk) 13:10, 21 December 2020 (UTC)
  • Support Support S8321414 (talk) 14:13, 21 December 2020 (UTC)

Better diff handling of paragraph splits

Edit proposal/discussion

  • Problem: When an editor adds line breaks to split an existing paragraph, our diff viewer depicts the text as deleted and re-added rather than just repurposed. This makes it difficult to see what text changed between the two paragraphs.
  • Who would benefit: Editors and readers who view diffs of this fairly common type of edit
  • Proposed solution: Directly compare the text changes between the "deleted" text and the new paragraphs, similar to how this handled moved paragraphs
  • More comments: This is a perennial request with continued need. It ranked #13 in 2016, and it appeared in the 2019 wishlist if not elsewhere
  • Phabricator tickets: task T156439, task T7072
  • Proposer: czar 02:11, 22 November 2020 (UTC)

Discussion

  • Support for this! Maybe they could internally do a sentence-by-sentence diff, i.e. put every sentence in a new line before running diff.
  • The improved diff view of wikEdDiff handles this case well. Certes (talk) 00:38, 23 November 2020 (UTC)
  • Strong Support. It is useful for all editors, but I think it would also help in-experienced editors become more comfortable with editing. The instant feedback such a function would give would be very nice. Mulstev (talk) 07:10, 28 November 2020 (UTC)

Since wikimarkup treats a single line-break as a space, the diff tool should use both sections for the compare. If a line-break is removed two sections would be compared with the resulting single section. If a line break is added the original section would be compared with the resulting 2 sections. I would not suggest displaying every sentence as a new line; adding or removing periods would then have the same effect as adding or removing line-breaks. But it may be beneficial to increase the importance of sentence breaks in the diff. User-duck (talk) 18:50, 8 December 2020 (UTC)

For the English Wikipedia, I suggest you try wikEdDiff (it's in the gadgets). In my opinion a much better diff than the standard one in most cases. It does not replace the standard one, it's just in addition on the top. --Ita140188 (talk) 15:37, 13 December 2020 (UTC)

Overlaps with WMDE Technical Wishes/Edit Conflicts.--Snaevar (talk) 14:39, 21 December 2020 (UTC)

Voting

  • Support Support User-duck (talk) 18:51, 8 December 2020 (UTC)
  • Support Support Sagivrash (talk) 19:08, 8 December 2020 (UTC)
  • Support Support I admit that's annoying. I believe it is a bug caused by how Mediawiki handles text. MarioSuperstar77 (talk) 19:10, 8 December 2020 (UTC)
  • Support Support Movses (talk) 19:11, 8 December 2020 (UTC)
  • Support Support Alpöhi (talk) 19:16, 8 December 2020 (UTC)
  • Support Support I agree it's a common bug and we should fix it.--EternamenteAprendiz (talk) 19:17, 8 December 2020 (UTC)
  • Support Support Dr747 (talk) 19:25, 8 December 2020 (UTC)
  • Support Support --NGC 54 (talk / contribs) 19:45, 8 December 2020 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:57, 8 December 2020 (UTC)
  • Support Support Kisnaak (talk) 21:23, 8 December 2020 (UTC)
  • Support Support Pmau (talk) 21:25, 8 December 2020 (UTC)
  • Support Support Gabrasca (talk) 21:41, 8 December 2020 (UTC)
  • Support Support Luis Fernández García (talk) 21:47, 8 December 2020 (UTC)
  • Support Support Ponor (talk) 21:59, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:36, 8 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 01:04, 9 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:41, 9 December 2020 (UTC)
  • Support Support * Pppery * it has begun 02:01, 9 December 2020 (UTC)
  • Support Support {{u|Sdkb}}talk 05:50, 9 December 2020 (UTC)
  • Support Support kennethaw88talk 06:12, 9 December 2020 (UTC)
  • Support Support Danbloch (talk) 09:06, 9 December 2020 (UTC)
  • Support Support Nurg (talk) 09:11, 9 December 2020 (UTC)
  • Support Support Samwalton9 (talk) 09:45, 9 December 2020 (UTC)
  • Support Support Thomas Kinz (talk) 10:21, 9 December 2020 (UTC)
  • Support Support Lion-hearted85 (talk) 10:58, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:10, 9 December 2020 (UTC)
  • Support Support Ulanwp (talk) 12:49, 9 December 2020 (UTC)
  • Support Support Matěj Suchánek (talk) 12:55, 9 December 2020 (UTC)
  • Support Support Hb2007 (talk) 14:06, 9 December 2020 (UTC)
  • Support Support Mannivu · 15:04, 9 December 2020 (UTC)
  • Support Support I hate seeing this on the diff pages! BladeRikWr (talk) 22:17, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 22:32, 9 December 2020 (UTC)
  • Support Support This is one of the most annoying things about diffs and makes them quite hard to use at times. CaptainEek Edits Ho Cap'n! 03:56, 10 December 2020 (UTC)
  • Support Support // Lollipoplollipoplollipop :: talk 05:25, 10 December 2020 (UTC)
  • Support Support JPxG (talk) 05:52, 10 December 2020 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 06:44, 10 December 2020 (UTC)
  • Support Support ‐‐1997kB (talk) 12:05, 10 December 2020 (UTC)
  • Support Support Dexxor (talk) 16:37, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 18:46, 10 December 2020 (UTC)
  • Support Support MichaelSchoenitzer (talk) 18:49, 10 December 2020 (UTC)
  • Support Support —  HELLKNOWZ   ▎TALK   ▎enWiki 22:16, 10 December 2020 (UTC)
  • Support Support Geniac (talk) 07:20, 11 December 2020 (UTC)
  • Support SupportBilorv (talk) 09:08, 11 December 2020 (UTC)
  • Support Support Jc86035 (talk) 11:48, 11 December 2020 (UTC)
  • Support Support Paucabot (talk) 12:23, 11 December 2020 (UTC)
  • Support Support Strong support. Very good idea. Really, the chages are not so importants as pictured by the diff function. BoldLuis (talk) 15:17, 11 December 2020 (UTC)
  • Support Support Bencemac (talk) 16:13, 11 December 2020 (UTC)
  • Support Support Szalax (talk) 16:58, 11 December 2020 (UTC)
  • Support Support James Martindale (talk) 17:12, 11 December 2020 (UTC)
  • Support Support Hkoala (talk) 17:36, 11 December 2020 (UTC)
  • Support Support And sometimes its not only paragraph splitting… Akela NDE (talk) 17:44, 11 December 2020 (UTC)
  • Support Support Theklan (talk) 18:05, 11 December 2020 (UTC)
  • Support Support --IngenieroLoco (talk) 22:16, 11 December 2020 (UTC)
  • Support Support DGG (talk) 01:25, 12 December 2020 (UTC)
  • Support Support You'd think getting this right would be considered basic functionality for software based around editing text. But not in the WMF's world. Oh, DrPizza! (talk) 07:50, 12 December 2020 (UTC)
  • Support Support Making diffs easier to use not only increases human productivity, but makes change tracking feasible for more novice editors. -- Beland (talk) 08:20, 12 December 2020 (UTC)
  • Support Support ~Cybularny Speak? 11:21, 12 December 2020 (UTC)
  • Support Support Tom Ja (talk) 12:39, 12 December 2020 (UTC)
  • Support Support Gnom (talk) 15:51, 12 December 2020 (UTC)
  • Support Support tufor (talk) 16:11, 12 December 2020 (UTC)
  • Support Support Mike Linksvayer (talk) 19:17, 12 December 2020 (UTC)
  • Support Support Emperork 🐋🐰 00:21, 13 December 2020 (UTC)
  • Support Support This is so infuriating! Thanks for proposing it. Kew Gardens 613 (talk) 02:38, 13 December 2020 (UTC)
  • Support Support TeKaBe (talk) 07:54, 13 December 2020 (UTC)
  • Support Support Gufosowa (talk) 10:47, 13 December 2020 (UTC)
  • Support Support YTRK (talk) 12:58, 13 December 2020 (UTC)
  • Support Support Izno (talk) 16:46, 13 December 2020 (UTC)
  • Support Support Nikkimaria (talk) 17:17, 13 December 2020 (UTC)
  • Support Support 4nn1l2 (talk) 17:21, 13 December 2020 (UTC)
  • Support Support -- the wub "?!" 18:29, 13 December 2020 (UTC)
  • Support Support Kaviraf (talk) 20:12, 13 December 2020 (UTC)
  • Support Support Tgr (talk) 08:34, 14 December 2020 (UTC)
  • Support Support SchmiAlf (talk) 11:29, 14 December 2020 (UTC)
  • Support Support ~ Amory (utc) 13:16, 14 December 2020 (UTC)
  • Support Support β16 - (talk) 16:10, 14 December 2020 (UTC)
  • Support Support WhatamIdoing (talk) 18:44, 14 December 2020 (UTC)
  • Support Support I also have to wonder whether various open-source diff tools could not simply be repurposed. WMF's have always been a bit, eh, under-useful, especially when compared to things like Meld (graphical Linux diff tool).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:44, 15 December 2020 (UTC)
  • Support Support RanuKanu (talk) 09:37, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:04, 15 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 21:06, 15 December 2020 (UTC)
  • Support Support SpringProof (talk) 23:10, 15 December 2020 (UTC)
  • Support Support Crissov (talk) 08:49, 16 December 2020 (UTC)
  • Support Support PG (talk) 08:52, 16 December 2020 (UTC)
  • Support Support Uu70344 (talk) 11:39, 16 December 2020 (UTC)
  • Support Support Michael Childs (talk) 01:57, 17 December 2020 (UTC)
  • Support Support Rachel Helps (BYU) (talk) 17:06, 17 December 2020 (UTC)
  • Support Support Shenme (talk) 01:23, 18 December 2020 (UTC)
  • Support Support Diffs were always one of the best things in MediaWiki sites, but they can always get better, and this is a good proposal. Amir E. Aharoni (talk) 17:40, 18 December 2020 (UTC)
  • Support Support Mmitchell10 (talk) 20:04, 18 December 2020 (UTC)
  • Support Support Grüße vom Sänger ♫(Reden) 09:31, 19 December 2020 (UTC)
  • Support Support Joejose1 (talk) 16:30, 19 December 2020 (UTC)
  • Support Support, and second the request to look at whether existing open-source diff tools could be used. HLHJ (talk) 18:10, 19 December 2020 (UTC)
  • Support Support 5910 C (talk) 21:52, 19 December 2020 (UTC)
  • Support Support Whisperjanes (talk) 21:41, 20 December 2020 (UTC)
  • Support Support He's the Billy Australia can't afford (talk) 02:22, 21 December 2020 (UTC)
  • Support Support Golmore (talk) 12:37, 21 December 2020 (UTC)
  • Support Support EEMIV (talk) 14:49, 21 December 2020 (UTC)
  • Support Support Thibaut (talk) 16:54, 21 December 2020 (UTC)
  • Support Support Nadzik (talk) 17:23, 21 December 2020 (UTC)
  • Support Support Schniggendiller (talk) 17:40, 21 December 2020 (UTC)

Add indentation and alignment features to visual editor

Edit proposal/discussion

  • Problem: Currently controlling indentations and alignment is difficult since such edits can only be done in source mode by those with advanced HTML coding knowledge, and it is not available in Visual Editor.
  • Who would benefit: All editors
  • Proposed solution: Add alignment options (left, right, center, justified etc.) for text and multimedia items in the editor itself instead of through codes and template fields in the Visual Editor and enable the press "tab" indent feature.
  • More comments:
  • Phabricator tickets:
  • Proposer: WikiAviator (talk) 06:12, 17 November 2020 (UTC)

Discussion

  • What are specific changes you would like to see? --Izno (talk) 04:40, 18 November 2020 (UTC)
    Things like adjusting paragraphing syles, left-right indents, colour changes, spellchecks etc. WikiAviator (talk) 06:33, 18 November 2020 (UTC)
    I can see how these features could be useful. I am just going to pick on the colour changes feature, which seems a bit too advanced for new users using VisualEditor, and may cause inappropriate use/abuse. If more advanced formatting and colour features are eventually added, I hope they would be opt-in instead of opt-out. H78c67c (talk) 05:20, 19 November 2020 (UTC)
    I wouldn't call these features too advanced for new users (who hasn't used a word processor before?), and regarding the point of inappropriate use, we can add a warning chatbox when a user attempts to change the text colour or font to prevent inappropriate use and we don't often see this feature abuse problem with text size do we? Furthermore, for not-so-tech-savvy users like me who have problems with HTML formatting, it is really difficult when it comes to changing colours and fonts in Wikipedia, or resizing non-text elements (that's why my username is plain to this date), therefore this would be highly beneficial and we don't need this to be opt-in. WikiAviator (talk) 08:55, 19 November 2020 (UTC)
  • @WikiAviator: I'm afraid this proposal as written is too broad. We can't rewrite VisualEditor to work the same as popular word processors. It's much more complicated than that. Could you revise this to focus on specific features? Color changing is a good example (I assume you mean changing the color of text). Thanks, MusikAnimal (WMF) (talk) 23:07, 19 November 2020 (UTC)
    Actually changing the color of text/tables is proposed at Allow text and table colour to be featured on the visual editor to change, so if you could, find a different feature to be the focus of this proposal. Alignment or indentation I think is okay. Much appreciated, MusikAnimal (WMF) (talk) 23:27, 19 November 2020 (UTC)
    I've edited the proposal, thanks for your suggestion :) WikiAviator (talk) 00:53, 20 November 2020 (UTC)
  • I don't understand what options you want. VisualEditor is not a word processor, and we shouldn't be making it into one. — Omegatron (talk) 15:27, 20 December 2020 (UTC)

Voting

  • Support Support Support for convenience. MarioSuperstar77 (talk) 18:40, 8 December 2020 (UTC)
  • Support Support Jax MN (talk) 18:42, 8 December 2020 (UTC)
  • Support Support Wikiusuarios (talk) 19:06, 8 December 2020 (UTC)
  • Support Support Eric0892 (talk) 01:15, 9 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 03:44, 9 December 2020 (UTC)
  • Support Support It would certainly be convenient. Sthakur88 (talk) 05:43, 9 December 2020 (UTC)
  • Support Support Omda4wady (talk) 07:15, 9 December 2020 (UTC)
  • Support Support Je ne comprends pas tout-à-fait la proposition mais je soutiens tout ce qui peut améliorer ou faciliter l'écriture en mode visuel que j'utilise essentiellement. Cdmt' Mylenos (talk) 12:12, 9 December 2020 (UTC)
  • Support Support Mhare (talk) 17:38, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 19:14, 10 December 2020 (UTC)
  • Support Support. Visual Editor (VE) must make thing easier (or the easiest). BoldLuis (talk) 13:51, 11 December 2020 (UTC)
  • Support Support ArnabSaha (talk) 15:09, 11 December 2020 (UTC)
  • Support Support Vince789 (talk) 22:03, 11 December 2020 (UTC)
  • Support Support Ad Huikeshoven (talk) 14:34, 12 December 2020 (UTC)
  • Support Support YTRK (talk) 12:56, 13 December 2020 (UTC)
  • Support Support Ratnil1 (talk) 06:35, 17 December 2020 (UTC)
  • Support Support VKG1985 (talk) 17:45, 18 December 2020 (UTC)
  • Support Support Invertiert (talk) 08:28, 19 December 2020 (UTC)

Allow table columns and rows to be freely movable in the Visual Editor

Edit proposal/discussion

  • Problem: I often work on translating articles from en.wiki and whenever there is a table that's sorted alphabetically, I have to manually move each row item – either in the source code editor or using "Move above"/"Move below" in VE – to re-sort them alphabetically for the target language, which can be very tedious and time-consuming.
  • Who would benefit: Anyone who uses the Visual Editor to work with tables.
  • Proposed solution: You should be able to select a row or column in VE and, instead of moving it one row/column at a time, just drag and drop it wherever you want.
  • More comments:
  • Phabricator tickets: T125145
  • Proposer: Srđan (talk) 00:46, 20 November 2020 (UTC)

Discussion

Full disclosure: I talked to Srđan about this (otherwise I wouldn't be aware of the proposal), but I ran into the issue independently a few hours before. Being able to freely reorder columns in VE would be a major plus (wouldn't have to be drag and drop in my opinion, even being able to type in which row you would like to move something to would be a big improvement). Best, Blablubbs (talk) 00:52, 20 November 2020 (UTC)

A good and meaningful idea. +1 --Aca (talk) 01:00, 20 November 2020 (UTC)

+1 Having worked and suffered with big tables related to the COVID-19 pandemic, I support this as part of a general need to improve tables and data handling in Wikipedia, especially considering how absurdly difficult it is to do this kind of stuff in the source editor. Sophivorus (talk) 01:44, 21 November 2020 (UTC)

+1 Good idea, Maybe also make that we can add colors to the tables? --RG067 (talk) 09:38, 21 November 2020 (UTC)

I think this sounds like phab:T240114 as well. ESanders (WMF) (talk) 12:14, 26 November 2020 (UTC)

Adding drag-&-drop functionality like this would make VE far more attractive to experienced editors who have objected to VE. -- Llywrch (talk) 05:56, 27 November 2020 (UTC)

Voting

Make edits auto-recoverable if the editor's network crashes

Edit proposal/discussion

  • Problem: An WP edit is lost when the editor's network goes down. Saving in-progress work is a feature in VisualEditor and the 2017 wikitext editor, but not the older wikitext editor
  • Who would benefit: Users of classic wikitext editor who develop a post off-line.
  • Proposed solution: Like GMail, routinely autosave an editor's in-progress work
  • More comments: Again, like GMail, create periodic saved-data (a snapshot of work to date) that can easily take over from the lost data of whatever type (message, article text, etc.)
  • Phabricator tickets: T75241
  • Proposer: BrettA343 (talk) 23:36, 20 November 2020 (UTC)

Discussion

  • This exists for VisualEditor and the 2017 wikitext editor, as a result of the #7 wish in the 2017 survey. @BrettA343: I'm assuming your wish is to enable this feature for the older wikitext editor? Or were you unaware the feature already existed? MusikAnimal (WMF) (talk) 22:23, 21 November 2020 (UTC)
    • Is the feature enabled on all wikis? I've only noticed it on en.wiki. Would be cool to have a save button, or to know when a save has been made. Many editors publish (way too) often in fear of losing their changes. Ponor (talk) 03:05, 22 November 2020 (UTC)
      • Yes, this feature is enabled everywhere. Your edits are stashed in local storage almost instantly (every second or so). ESanders (WMF) (talk) 16:42, 24 November 2020 (UTC)
1) I am curious, in which cases/situations the VisualEditor and the 2017 wiki text editor are able to restore the lost sessions? If I close a browser tab with non-saved edits, and restore, my edits are gone. Unlike by the Reply tool (Discussion Tools). What is the difference?
2) Is T75241 ticket about a different topic? If not, is it resolved already? Samat (talk) 15:56, 29 November 2020 (UTC)
3) How this topic is related the Draft extension? Is it already in use for any of these tools? Samat (talk) 17:52, 29 November 2020 (UTC)
Motivation for my questions: request for an auto-save (restore) feature on the local wishlist, and I am not sure how and where to address it here: does it need new development, or only implementation of existing features. Samat (talk) 17:52, 29 November 2020 (UTC)
Edits are stored in sessionStorage, which means they should be recovered if you restore the same tab, but not if you reopen the page in a new tab. In order to support that we would need to use localStorage, but that comes with issues around storage limits. ESanders (WMF) (talk) 13:55, 24 December 2020 (UTC)
2) that is the same as this request
3) it isn’t as it stands ESanders (WMF) (talk) 14:02, 24 December 2020 (UTC)
  • I've boldly clarified the proposal to be about the classic non-VE wikitext editor. Best, MusikAnimal (WMF) (talk) 16:29, 7 December 2020 (UTC)
  • Have been having this problem for a while also. Yes, my edits are stored locally in some cases but in some others it is still able to be lost. The most recent that I remember was some months ago when a user starts editing a page after I started editing it and then they published it before I published mine. My edit was gone completely and I need to start it all over. Often happens by vandals or bots on Wikipedia. It has also happened before when my Internet went down so my edit was not published and when I went back in my browser, it showed the "can't connect" page so my cached edit was lost. RXerself (talk) 00:31, 9 December 2020 (UTC)
  • On iOS, LocalStorage is limited. I often lose work when a tab reloads in mobile-editor, VE, NWE, etc. But in the classic editor, I get prompted to resubmit the form and can recover to the last preview. Preview early, preview often. This is one of the major factors that keeps me on the classic editor over the alternatives. Pelagic (talk) 09:54, 18 December 2020 (UTC)
    The classic mobile editor does not have auto save. We use sessionStorage for VE/NWE. I’m surprised that reloaded tabs in iOS are not recovering. I would file a task about that if you can reproduce it. ESanders (WMF) (talk) 13:58, 24 December 2020 (UTC)

Voting

  • Support Support Jax MN (talk) 18:43, 8 December 2020 (UTC)
  • Support Support Definitely supporting that feature. I had an issue once during editing and I had to refresh the page which made me lose my precious time that I spent on editing in my own wiki. That feature would also be beneficial to Wikipedia users. MarioSuperstar77 (talk) 18:47, 8 December 2020 (UTC)
  • Support Support আফতাবুজ্জামান (talk) 19:05, 8 December 2020 (UTC)
  • Support Support Also, please dont disable the save button in visual editor for network failures during save. Its yust stupid neding to add a dummy space somewhere yust to be able to save the edit. If you realy want to do that, maybe keep track of how often the current edit failed to save, and only do that for more permanent failures Victor Schmidt (talk) 19:59, 8 December 2020 (UTC)
  • Support Support Sure. I had countless minor edits gone due to crashes but there's once I am really angry as I had almost an 丙级 (en:C Class) article gone at the moment the network crash, I spent almost 4 hours on it. Some recovery tool will be good. I had also several near misses too, thankfully my cache is still there. Camouflaged Mirage (talk) 20:03, 8 December 2020 (UTC)
  • Support Support Yes! Please! and although I know this suggestion is "different", but edits can maybe identified by some sort of session (like an etherpad session) where also multiple editors can work when invited. this might be too much changes to the way edits are stored in the database and the such; but it would be great if that would be the trajectory of this change. Uwe a (talk) 20:28, 8 December 2020 (UTC)
  • Support Support Even now, edits will sometimes, but only sometimes recover. There should be a draft version saved somewhere where it can be easily accessed and continued working on. It doesn't have to be public, it can be saved on user's computer or on WMF servers. I've lost hours of edits because of browser tab crashes and network outages. Ponor (talk) 22:00, 8 December 2020 (UTC)
  • Support Support Very useful idea, the edit page often crashes (automatic reset) on tablet after a long time without writing. Tubamirum (talk) 22:33, 8 December 2020 (UTC)
  • Support Support There are similar user scripts, but native should be. It may need to be manually enabled or warned for privacy and validity. YFdyh000 (talk) 23:42, 8 December 2020 (UTC)
  • Support Support Imetsia (talk) 00:13, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 00:49, 9 December 2020 (UTC)
  • Support Support Eric0892 (talk) 01:13, 9 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:29, 9 December 2020 (UTC)
  • Support Support BugWarp (talk) 01:45, 9 December 2020 (UTC)
  • Support Support Xinbenlv (talk) 05:53, 9 December 2020 (UTC)
  • Support Support it has often happened to me that I have lost a lot of what I have written, so this would be a very nice feature. Kogge (talk) 08:35, 9 December 2020 (UTC)
  • Support Support YasuakiH (talk) 10:17, 9 December 2020 (UTC)
  • Support Support Thomas Kinz (talk) 10:35, 9 December 2020 (UTC)
  • Support Support Oui Mylenos (talk) 12:09, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 18:02, 9 December 2020 (UTC)
  • Support Supportputnik 18:59, 9 December 2020 (UTC)
  • Support Support dwf² (talk) 22:54, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 01:53, 10 December 2020 (UTC)
  • Support Support badly needed Mhare (talk) 17:39, 10 December 2020 (UTC)
  • Support Support Srđan (talk) 21:56, 10 December 2020 (UTC)
  • Support Support RSLitman (talk) 02:20, 11 December 2020 (UTC)
  • Support Support Adamoszkovics (talk) 10:17, 11 December 2020 (UTC)
  • Support Support ArnabSaha (talk) 15:12, 11 December 2020 (UTC)
  • Support Support Szalax (talk) 16:50, 11 December 2020 (UTC)
  • Support Support Noel baran (talk) 16:51, 11 December 2020 (UTC)
  • Support Support I've installed a browser plug-in specifically because of the days of work I've lost due to not having this. I use the 2010 editor with syntax highlighting. czar 17:07, 11 December 2020 (UTC)
  • Support Support Ahecht (TALK
    PAGE
    ) 18:42, 11 December 2020 (UTC)
  • Support Support. Meiræ 21:50, 11 December 2020 (UTC)
  • Support Support Vince789 (talk) 22:09, 11 December 2020 (UTC)
  • Support Support As others have mentioned, the current feature does not always work. DGG (talk) 01:11, 12 December 2020 (UTC)
  • Support Support It will benefit editors using VPN Jingkaimori (talk) 08:52, 12 December 2020 (UTC)
  • Support Support Francois-Pier (talk) 10:50, 12 December 2020 (UTC)
  • Support Support ~Cybularny Speak? 11:22, 12 December 2020 (UTC)
  • Support Support Yiyi (talk) 19:23, 12 December 2020 (UTC)
  • Support Support LM150 (talk) 22:15, 12 December 2020 (UTC)
  • Support Support Emperork 🐋🐰 00:18, 13 December 2020 (UTC)
  • Support Support Kew Gardens 613 (talk) 02:39, 13 December 2020 (UTC)
  • Support Support DMySon (talk) 12:13, 13 December 2020 (UTC)
  • Support Support Xavi Dengra (MESSAGES) 17:10, 13 December 2020 (UTC)
  • Support Support 4nn1l2 (talk) 17:19, 13 December 2020 (UTC)
  • Support Support Cesc97 (talk) 19:30, 13 December 2020 (UTC)
  • Support Support Tgr (talk) 08:37, 14 December 2020 (UTC)
  • Support Support Yes: i have lost many changes, several times...! RavBol (talk) 21:31, 14 December 2020 (UTC)
  • Support Support Oh yes, oh yes. I've lost many entire articles because of this problem, despite using various browser add-ons that attempt to back up the contents of form fields (the lack of a specific identifier for a specific instance of the main editing window generally defeats these things, unless you strictly work on one page at a time).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:52, 15 December 2020 (UTC)
  • Support Support RanuKanu (talk) 09:10, 15 December 2020 (UTC)
  • Support Support Edits are still not always restored after some types of crashes in WE2010 (e.g. after ERR_CACHE_MISS). — Draceane talkcontrib. 13:06, 15 December 2020 (UTC)
  • Support Support Thanks, EDG 543 (message me) 15:48, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:17, 15 December 2020 (UTC)
  • Support Support Vacant0 (talk) 18:39, 15 December 2020 (UTC)
  • Support Support This is a long overdue functionality. Vanisaac (talk) 02:07, 16 December 2020 (UTC)
  • Support Support Wolfmartyn (talk) 14:20, 16 December 2020 (UTC)
  • Support Support Sultec (talk) 11:19, 17 December 2020 (UTC)
  • Support Support Grüße vom Sänger ♫(Reden) 22:08, 18 December 2020 (UTC)
  • Support Support Neon Richards (talk) 23:09, 18 December 2020 (UTC)
  • Support Support Iva (talk) 18:22, 20 December 2020 (UTC)
  • Support Support Anjen01 (talk) 20:47, 20 December 2020 (UTC)
  • Support Support Ahmadtalk 03:44, 21 December 2020 (UTC)
  • Support Support2d37 (talk) 10:24, 21 December 2020 (UTC)
  • Support Support David1010 (talk) 13:08, 21 December 2020 (UTC)

Unintentional false links in VE

Edit proposal/discussion

  • Problem: When user changes a link anchor in the text, the link target doesn't change, and there is no warning for that. The surface is not intuitive enough, therefore beside many newcomers even experienced editors make this mistake. Since trusted user's edits are not patrolled systematically, these edits stay long time in the text (and often not easy to discover them), hurt the reputation of Wikipedia and feelings and attitude of editors to VE (=VisualEditor) (so much that part of the community is repeatedly propose to disable VE and try to block any further implementation of VE).
  • Who would benefit: readers, editors, partrollers
  • Proposed solution: some kind of warning
  • More comments: This request is basically a resubmission of a wish from 2019 (resulted on place 59th of 212 last year)
  • Phabricator tickets: T56947 (related, solved ticket: T55973)
  • Proposer: Samat (talk) 11:49, 29 November 2020 (UTC) Taken over by Tacsipacsi (talk) 10:54, 30 November 2020 (UTC)

Discussion

I'm not sure that I understand this one, Tacsipacsi. Is it about the process for changing the link label? When I place the insertion point in a link to edit it, I see the target in the pop-up card. Pelagic (talk) 10:49, 18 December 2020 (UTC)

@Pelagic: Yes, you understand the point of this proposal correctly. The target is visible on the card, but apparently this is not enough, there are plenty of edits changing only either the text or the target (mostly the former), for example here or here. —Tacsipacsi (talk) 18:32, 20 December 2020 (UTC)
Visual Editor hyperlink edit card - where would you edit the label?
@Tacsipacsi: Maybe if the Text line at the bottom of the card was editable, and disallow changing it on the main editing surface? I always found it disconcerting to click Change text on the card then have the focus jump back onto the page like nothing happened. (Though my own preference would be to be able to change it in either place.)
If we were to show all the link targets in-line à la wikitext, then that would go against WYSIWYG and affect line wrapping. Pelagic (talk) 01:56, 21 December 2020 (UTC)
@Pelagic: I have no idea what the right solution would be. The good thing about CWS is that I don’t need to know it, either. When someone at WMF picks up this wish, they will do the necessary user tests and other user experience design tasks. —Tacsipacsi (talk) 20:02, 22 December 2020 (UTC)

Voting

Copy and paste from diffs

Edit proposal/discussion

  • Problem: It is difficult to copy and paste from a diff without having to edit the resulting text afterwards.
  • Who would benefit: Everyone
  • Proposed solution: 1) Add CSS similar to Github to not include the + or - signs when copying. 2) Allow the ability to select text from just one column rather than having to copy both columns.
  • More comments:
  • Phabricator tickets: T192526, T270775
  • Proposer: Rschen7754 01:16, 17 November 2020 (UTC)

Discussion

  • Good idea. I've noticed this annoying problem before, and it shouldn't be too hard to fix. --Piotrus (talk) 04:43, 17 November 2020 (UTC)
    • It is harder to fix then you think. That's because browsers for security reasons, don't like it when you copy things and then 'leave out' parts of what you have selected. That can be abused in phishing for instance. Perhaps we can completely revamp the layout of the diff, maybe with grid layout CSS or something to avoid this problem... Haven't checked yet if that is possible now, but a couple of years ago, browser support wasn't there yet to enable an alternate layout. Could be worth a revisit. —TheDJ (talkcontribs) 11:39, 17 November 2020 (UTC)
      • It's fine to change what gets written to the clipboard. The onCopy event fires just before the data is written to the clipboard so you can modify the selection. We use such a technique in VE to ensure we write Parsoid HTML to the clipboard instead of what you see on the page. ESanders (WMF) (talk) 15:39, 24 November 2020 (UTC)
      • Grid is still not greatly supported by the long tail. --Izno (talk) 01:18, 21 November 2020 (UTC)
  • +1 ~~ CAPTAIN MEDUSAtalk 12:11, 17 November 2020 (UTC)
  • Agreed it should be done. Anyway you can hold ctrl while selecting text and it should do the trick (at least on Firefox / Windows). Stryn (talk) 20:17, 17 November 2020 (UTC)
    What? Just holding Ctrl? No way that could… Oh, it works! Thanks! --Mormegil (cs) 08:13, 15 December 2020 (UTC)
  • Absolutely. This is a pretty annoying problem especially in communities where quoting from diffs is common practice (such as enwiki where I copy from diffs hundreds of times a year at least, no exaggeration). Best, KevinL (aka L235 · t) 06:44, 1 December 2020 (UTC)
  • This appears to have been resolved. (Many thanks to TheDJ and PeterTheOne, and code reviewers ESanders and Thiemo Kreuz.) Deployment will happen over the next couple days, if I understand correctly. --Yair rand (talk) 07:46, 1 December 2020 (UTC)
    • The indicators part appears to be, but not the columns. --Rschen7754 19:17, 1 December 2020 (UTC)
      • You are correct. My mistake. --Yair rand (talk) 23:54, 1 December 2020 (UTC)
  • What is a diff? I assume it's a 'Difference revision' of an article --RanuKanu (talk) 09:33, 15 December 2020 (UTC)
A diff is the difference between two versions of any wikipage, where the differences are shown. Something like this, and those little + are copied with the real stuff, if you mark them and press ctrl-c. If there is text on both sides of the relevant parts, that's included as well. Grüße vom Sänger ♫(Reden) 23:11, 20 December 2020 (UTC)

Voting

New keyboard shortcuts

Edit proposal/discussion

  • Problem: There are no keyboard shortcuts available for the "User contributions" and "Log out" links. Keyboard shortcuts for working with the various Watchlist filters and view settings in particular would be welcome. Other missing features that would be great are keyboard shortcuts to quickly put in focus the version-selecting bullets on "Revision history" pages, and shortcuts to more readily navigate those (show a different number of revisions per page, jump to a list of earlier revisions, etc.). Another one that comes to mind is a keyboard shortcut to facilitate access to non-English versions of an article or WP page. I'm sure there are other similar features that users would appreciate.
  • Who would benefit: People who are accustomed to using keyboard shortcuts and anyone looking to save some time when editing.
  • Proposed solution: Create such keyboard shortcuts and/or functionalities.
  • More comments:
  • Phabricator tickets:
  • Proposer: Toccata quarta (talk) 07:56, 25 November 2020 (UTC)

Discussion

  • I would vote for this if there were a clear list of the keyboard shortcuts and the proposed key mappings. --Hb2007 (talk) 15:42, 9 December 2020 (UTC)
  • Toccata quarta - does w:en:Wikipedia:AutoHotkey help? - Cabayi (talk) 20:58, 9 December 2020 (UTC)
    Cabayi: I'm not familiar with that tool. It looks interesting but also a bit tricky at first. My proposal is for "preset" keyboard shortcuts, like the ones we are already have for accessing "Special pages" or the Watchlist, the "Preview" function, etc. Toccata quarta (talk) 07:53, 10 December 2020 (UTC)

Voting

  • Support Support Why not? MarioSuperstar77 (talk) 18:49, 8 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:43, 9 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:12, 9 December 2020 (UTC)
  • Support Support Cherryblossom000 (talk) 07:17, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:05, 9 December 2020 (UTC)
  • Support Support Clarinetjo (talk) 12:09, 9 December 2020 (UTC)
  • Support Support Jjkorff (talk) 13:45, 9 December 2020 (UTC)
  • Support Support Browk2512 (talk) 21:23, 9 December 2020 (UTC)
  • Support Support Libcub (talk) 18:48, 10 December 2020 (UTC)
  • Support Support Vince789 (talk) 22:06, 11 December 2020 (UTC)
  • Support Support DGG (talk) 01:18, 12 December 2020 (UTC)
  • Support Support~SHEKH (Talk) 15:48, 14 December 2020 (UTC)
  • Comment Comment You want to make it easy to accidently log yourself out? That's a use case? Shenme (talk) 07:27, 17 December 2020 (UTC)
  • Support Support but there is a shortcut for user contributions (y). Golmore (talk) 11:05, 18 December 2020 (UTC)
  • Support Support VKG1985 (talk) 17:49, 18 December 2020 (UTC)

Make a dialog box with an editable preview of the template.

Edit proposal/discussion

  • Problem: Templates take up a lot of memory and space and are hard to edit.
  • Who would benefit: Those who work with templates.
  • Proposed solution: Make a dialog box with an editable preview of the template.
  • More comments: I myself faced a similar problem when I edited the article "Cryptography"
  • Phabricator tickets:
  • Proposer: SiriUsBLacK143924 (talk) 14:22, 18 November 2020 (UTC)

Discussion

Voting

Writing a : in visual editor shouldnt add a blockquote but a : to the source code

Edit proposal/discussion

  • Problem: Writing a : and getting a blockquote is not intuitive and breaks with the convention of being able to write source code in the visual editor. There is also no other way to get an : into the source code. Equations are always indented with a : so it's an important feature to have.
  • Who would benefit: Everybody who needs an : indent aka everybody who writes equations.
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Nabloodel (talk) 19:17, 19 November 2020 (UTC)

Discussion

  • @Nabloodel: Note : is not intended to be used for indentations in article text. : creates a definition list (which is why VE maps it to blockquote instead, which is a proper indentation). This is a very unfortunate and longstanding habit that grew out of talk page discussions, but it is VERY bad for people relying on screenreaders to read an article
  • but character : is used in discussions and there are pages, where is allowed visual editr on talkpages or forum chats. JAn Dudík (talk) 16:39, 20 November 2020 (UTC)
  • This is most often used with equations, which look weird with no indentation. I know of no other ways of indenting them. So maybe add a paragraph style for equations instead (and use a bot to change millions of :<math> to the new style)?
    • Indenting article text with colons is semantically invalid and bad for accessibility. A div tag can and should easily be used to provide a block indent. See en:Template:Block indent. Jonesey95 (talk) 19:09, 22 November 2020 (UTC)
      • Editors should never have to use html tags. That's why we have the wiki markup language. Paragraph styles are the way to go; we use them for headings and quotes, there should be one for math equations. Ponor (talk) 21:16, 22 November 2020 (UTC)
  • I notice that under the dropdown menu for VisualEditor - Icon - Bullet-list-ltr.svg there are two options that I normally can't click on, even in articlespace: Decrease indentation and increase indentation, both of which have keyboard shortcuts. Any clue as to why those may have been disabled? Tenryuu (talk) 04:23, 24 November 2020 (UTC)
    @Tenryuu, I did a quick test: increase/decrease indentation were enabled when the cursor is in a list item and disabled when it's a normal paragraph. (When I changed a paragraph to a bullet-item, I needed to click away somewhere else then put the cursor back into the changed block for the menu to update.) Hope that helps, Pelagic (talk) 22:38, 16 December 2020 (UTC)
    Ah, that explains a lot. Thanks @Pelagic! Tenryuu (talk) 22:40, 16 December 2020 (UTC)
  • The :<math> issue is phab:T111712. As mentioned here and on that task, it would be better to not (ab)use the : syntax for this. ESanders (WMF) (talk) 16:44, 24 November 2020 (UTC)
  • Equations can be indented by <math display=block> instead of :<math> so :-indentation is not really required for that. Threading of discussion pages is a bigger issue. —David Eppstein (talk) 18:01, 26 November 2020 (UTC)
  • Wikimarkup : does not do a <blockquote>, it does a <dd> (which is actually invalid markup in most circumstances). This problem does need to be fixed, but it is to use a <div>, <article>, or something else (especially on talk pages, perhaps with IDs for thread-building). The short version is that <dl> markup is only valid if there is a <dl>...</dl> that contains at least one <dt> followed by either another <dt> or a <dd>; and at least one <dd> preceded by either a <dt> or another <dd> (that is, at least one each of <dt> and <dd> must be present, and in that order). Thus, every use of : markup that is not preceded by a ; instance (either immediately or with one or more other intervening : instances) is invalid. Same goes for any ; that isn't followed by a :, either immediately or with an intervening additional ;. If these conditions are not met, then ;... should be converted to ''...''[blank line here] (or directly into <p style="font-weight: bold;">...</p>). There's been a ticket open about this, in every MW bug-tracker, since the dawn of time, and the devs just never do anything about it. This is probably the no. 1 HTML-compliance problem in MW, and it's what makes talk pages (and many articles) a confusing hellhole of invalid list gibberish for users of screen readers. It's utterly shameful that this has not been fixed yet.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:34, 15 December 2020 (UTC)
    I heartily agree with you about the abuse of definition lists, @SMcC. Which might be why they mapped the ':' magic key in VE to <blockquote> instead of the <dd> that you would get from literal wikitext :. Most of the other magic keystrokes are the same as their wikitext equivalents, but this is an exception. Maybe the key could be '>' instead of ':', or they could require the space after ': ' like they do with '# ' and '* '.
    Note that on mobile VE, which has fewer toolbar buttons than desktop VE, these secret keys are the only way to do block formatting. For a list, see mw:User:Pelagic/Mobile keyboard shortcuts for Visual Editor. Pelagic (talk) 23:09, 16 December 2020 (UTC)
    Thanks for the counter-correction. I had no idea that VE was doing something different here. But ARGH! It's just trading one spec-violating markup abuse for another one. The <blockquote> element is reserved for actual quoted material (only, not even include citation information for it). WhyTF can't they just get it through their heads that <span>, <div>, <article> and other generic, non-semantic elements exist for a reason? It's like their development is being directed by Basil Fawlty.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:34, 17 December 2020 (UTC)
  • Part of the problem is that we don't have a standard, agreed way to "do indentation" in HTML. Blockquote adds extra vertical space, and a grey left bar, and has specific semantics. Naked DD is so wrong that I almost have an apoplexy every time I think on it. Then we nest them 10 deep?! What would be useful is a set of classes like "mw-indent-1", "mw-indent-2", with a new wikitext symbol that maps to those. Maybe '.' at the beginning of a line? ..My indented comment isn't a big leap from ::My indented comment, and ties in with a traditional use of dots as leaders. Only problem with that is if someone wants to start a line with an ellipsis. Perhaps ',' instead? It's not something that would normally appear at the beginning of a line, even singly. ,,My indented comment. It looks weird, but so does '''''bold italic'''''. Pelagic (talk) 23:47, 16 December 2020 (UTC)
    Yes, this is essentially what the devs have been told by us (with actual HTML compliance experience) for nearly 20 years, and they just don't do it. It's like arguing with a cat.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:37, 17 December 2020 (UTC)

Voting

  • Support Support That seems to be a bug. Hopefully, it gets fixed. MarioSuperstar77 (talk) 18:43, 8 December 2020 (UTC)
  • Support Support Ponor (talk) 21:58, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:23, 9 December 2020 (UTC)
  • Support Support, but see above. This has not been described correctly. The problem is much more specific than this, and a much more severe problem than a trivial one about layout stuff.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:35, 15 December 2020 (UTC)
  • Support Support Neon Richards (talk) 23:13, 18 December 2020 (UTC)

Expand "minor edits" checkbox-feature

Edit proposal/discussion

  • Problem: could be easier to keep track of recent changes
  • Who would benefit: everyone checking for vandalism, everyone wanting to quickly describe, what has been done within an edit
  • Proposed solution: add checkboxes and markers (like for minor edit and bot) e. g. for "spelling", "linkfix", "syntaxfix", "answer" (for discussions),...
  • More comments: I suppose by adding this the list of recent changes becomes even more sortable
  • Phabricator tickets:
  • Proposer: HirnSpuk (talk) 11:57, 17 November 2020 (UTC)

Discussion

Voting

  • Support Support Imetsia (talk) 18:45, 8 December 2020 (UTC)
  • Support Support It should use change tags. MarioSuperstar77 (talk) 18:58, 8 December 2020 (UTC)
  • Support Support Dr747 (talk) 19:22, 8 December 2020 (UTC)
  • Support Support Berdajeno (talk) 20:44, 8 December 2020 (UTC)
  • Support Support Kisnaak (talk) 21:23, 8 December 2020 (UTC)
  • Support Support ✍ Janwo Disk./de:wp 03:23, 9 December 2020 (UTC)
  • Support Support Ezlev (talk) 03:43, 9 December 2020 (UTC)
  • Support Support This would be beneficial for editors to mark their edits accordingly, and also patrollers to note if there are discrepancies. Sthakur88 (talk) 05:46, 9 December 2020 (UTC)
  • Support Support --Till.niermann (talk) 06:52, 9 December 2020 (UTC)
  • Support Support Lion-hearted85 (talk) 10:45, 9 December 2020 (UTC)
  • Support Support Zombie(CZ) (talk) 11:44, 9 December 2020 (UTC)
  • Support Support Jjkorff (talk) 13:38, 9 December 2020 (UTC)
  • Support Support Libcub (talk) 18:56, 10 December 2020 (UTC)
  • Oppose Oppose After more than two tags you'd need a checkbox dropdown and then I'm not sure how this is faster than typing "spelling" in the edit summary. I also don't know why this would be more meaningful/readable than an edit summary to users patrolling the changes (I don't want to hide all changes marked "Fixed typo"/"spelling" because a lot of vandals use such a canned edit summary). — Bilorv (talk) 09:23, 11 December 2020 (UTC)
  • Support Support This would also make clearer what is and is not a minor edit. VaneWimsey (talk) 02:30, 12 December 2020 (UTC)
  • Support Support A really good idea for expert wikpedians. Despotismo Ilustrado y Barroco (talk) 19:49, 12 December 2020 (UTC)
  • Support Support Rdyornot (talk) 22:25, 12 December 2020 (UTC)
  • Support Support ThomasLendt (talk) 15:31, 13 December 2020 (UTC)
  • Support Support Hadi (talk) 18:03, 13 December 2020 (UTC)
  • Support Support This is useful so that I don't have to give edit summaries on small edits I make SuperSkaterDude45 (talk) 18:01, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:21, 15 December 2020 (UTC)
  • Support Support Yilku1 (talk) 05:13, 21 December 2020 (UTC)

Enabling preview data on the 2017 wikitext editor

Edit proposal/discussion

  • Problem: The new 2017 beta wikitext editor has a decent visual preview feature, but it lacks some information like templates used in the preview and parser profiling data, the latter of which has some useful information like the amount of PEIS used.
  • Who would benefit: Editors who are trying to analyse things like PEIS on (large) articles without needing to switch out of beta.
  • Proposed solution: Add an icon that can be clicked or hovered over to display the data.
  • More comments : If this could somehow be implemented for the VisualEditor that would be nice as well, but something tells me the lack of a preview function for the VE would make it harder for my proposal to be worked into it.
  • Phabricator tickets: task T267048
  • Proposer: Tenryuu (talk) 23:39, 24 November 2020 (UTC)

Discussion

Voting

Allowing VisualEditor to edit by section

Edit proposal/discussion

  • Problem: The VisualEditor always loads the entire page regardless of which "edit" link is clicked on the page. An editor who is trying to edit one section may encounter edit conflicts from another section being edited.
  • Who would benefit: Editors who are only trying to edit one section.
  • Proposed solution: Make an option to toggle between section editing and full page editing.
  • More comments: The beta feature "New wikitext mode" kind of does this already by only taking the section where "edit source" is clicked.
  • Phabricator tickets: phab:T221908
  • Proposer: Tenryuu (talk) 04:35, 24 November 2020 (UTC)

Discussion

  • This is a very hard problem to solve, because while sections exist as a 'unit' in wikitext, wikitext when rendered can affect multiple sections. As such, a rendered section can't really exist without the other rendered sections. Work to improve this situation happens continuously, but they are major problems in the core design (or rather lack of design) of wikitext, for which no quick fix exists. —TheDJ (talkcontribs) 09:36, 24 November 2020 (UTC)
  • We actually already solved this problem last year for the mobile visual editor (and as TheDJ suggest above, it was not easy). The feature works fine on desktop too but we have it disabled because we felt it might be disruptive to editors who have come to expect the current behaviour. Enabling this would just require a one line config change: phab:T221908. We do not yet have the ability to dynamically switch between section and full page editing, but that is technically possibly too. ESanders (WMF) (talk) 16:04, 24 November 2020 (UTC)
Thanks for the heads-up. I'll subscribe to the ticket to keep myself apprised of new developments. Tenryuu (talk) 23:21, 24 November 2020 (UTC)
How about having it enabled for new accounts? It would greatly help with visual editing large pages on older hardware.--Strainu (talk) 10:14, 12 December 2020 (UTC)
  • There re many circumstances where this wiould be an enormous help. If it is not ready for universal adoption, could it be selectable as a gadget? DGG (talk) 10:19, 29 November 2020 (UTC)
    • It could just be a user preference but it would be better if it were just enabled for everyone, as every user preference we add incurs some technical debt by increasing the amount of testing we need to do in perpetuity. ESanders (WMF) (talk) 13:23, 2 December 2020 (UTC)
  • Is this accurate? According to en:WP:VisualEditor, Opening an entire page for editing does not increase edit conflicts, which are (roughly) based on editing the same paragraph. From reading this, I concluded that the visual editor does its own edit conflict checking, and it's based on paragraph, not on entire page. The reason I researched this the other day is I saw in the history that somebody edited at the same time that I did, but I didn't have an edit conflict, so I wondered why. Novem Linguae (talk) 16:08, 21 December 2020 (UTC)
    From Help:Edit conflict#Prevention:

    The system uses CVS-style edit-conflict merging, based on the diff3 utility. This feature triggers an edit conflict only if users attempt to edit the same few lines.

    ..so yes, section editing does not reduce edit conflicts. Also VE has no special handling for edit conflicts, it is all done at the wikitext level. ESanders (WMF) (talk) 12:53, 23 December 2020 (UTC)
Ping Tenryuu. The answer above may be of interest to you. It suggests this proposal is not needed, since the visual editor avoids most edit conflicts. –Novem Linguae (talk) 09:28, 5 January 2021 (UTC)
That's interesting to note. While this would make my original proposal moot, would it still be beneficial to do section editing so that loading times are shorter? I find that loading takes exorbitantly long with articles chock-full of images and transcluded templates. Tenryuu (talk) 11:00, 5 January 2021 (UTC)
@Tenryuu that is correct. As you can see in this diagram there is a significant load time reduction when using section editing, especially on long articles. (Cc @Novem Linguae) ESanders (WMF) (talk) 13:16, 5 January 2021 (UTC)
@ESanders (WMF): One final question, if I may. Does the source code editor in full article mode prevent edit conflicts the same way the visual editor does? That is, using CVS-style edit-conflict merging, based on the diff3 utility. This feature triggers an edit conflict only if users attempt to edit the same few lines.? The en:Help:Edit conflict article has some clarity and contradiction issues, so I plan to copyedit it, I want to make sure to use the correct information. Thank you. –Novem Linguae (talk) 17:31, 5 January 2021 (UTC)
@Novem Linguae Yes: all visual edits are converted to wikitext before we attempt to save to the database, so as far as edit conflicts are concerned there is no difference between the modes. Regardless of the editor used, your edit conflict will be detected based on the wikitext using the diff3 utility. ESanders (WMF) (talk) 18:31, 5 January 2021 (UTC)

Voting

Add monospaced text in Visual Editor

Edit proposal/discussion

  • Problem: As far as I know, you can't select the monospaced text in the Visual Editor
  • Who would benefit: Those who work from mobile or frequently use the Visual Editor, in additon to less experienced users
  • Proposed solution: Add a "monospaced" button in text style selector
  • More comments:
  • Phabricator tickets:
  • Proposer: Dixy52 (talk) 14:01, 19 November 2020 (UTC)

Discussion

  • VE has a "Compute code" option in the text style menu (Ctrl+shift+6) that produces monospaced text. ESanders (WMF) (talk) 15:41, 24 November 2020 (UTC)

Voting

  • Support Support MarioSuperstar77 (talk) 18:37, 8 December 2020 (UTC)
  • Support Support Dr747 (talk) 19:16, 8 December 2020 (UTC)
  • Support Support --NGC 54 (talk / contribs) 19:39, 8 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:22, 9 December 2020 (UTC)
  • Support Support Magol (talk) 11:33, 9 December 2020 (UTC)
  • Support Support Franchement, je ne comprends pas la proposition mais seulement qu'elle aiderait les utilisateurs en mode visuel, ce que je suis toujours. Cdmt' Mylenos (talk) 11:50, 9 December 2020 (UTC)
  • Support Support  Swazmo DiscBlanco.svg DiscWikiP.svg 22:52, 10 December 2020 (UTC)
  • Support Support Rdyornot (talk) 22:24, 12 December 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose We should be using semantic markup like <code>, etc., not purely visual font trickery. This would be a step backwards.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:57, 15 December 2020 (UTC)

Convert typographic replacement characters like straight apostrophes and quotation marks

Edit proposal/discussion

  • Problem: While many Wikipedias written in the Latin script have adopted the use of local quotation marks (usually distinct one for opening and closing) and typographic (curly) apostrophes instead of straight " and ' as well as proper em or en dashes instead of the hyphen-minus -, this has traditionally not happened on the English Wikipedia out of fear that it would be too complicated for contributors and that mixing styles would look unpleasant or unprofessional.
  • Who would benefit: Readers.
  • Proposed solution: Substitute ASCII replacement characters while editing.
  • More comments:
  • Phabricator tickets: phabricator:T40724
  • Proposer: Crissov (talk) 11:04, 20 November 2020 (UTC)

Discussion

  • The EN Wiki MOS has this footnote

Curly quotation marks and apostrophes are deprecated on the English Wikipedia because:

  • Consistency keeps searches predictable. Though most browsers do not distinguish between curly and straight marks, Internet Explorer still does (as of 2016), so that a search for Alzheimer's disease will fail to find Alzheimer’s disease and vice versa.
  • Straight quotation marks and apostrophes are easier to type reliably on most platforms.

Gbear605 (talk) 23:03, 20 November 2020 (UTC)

Which IMHO is a terrible thing. But except enwiki, indeed many projects would profit a lot from the feature.–XanonymusX (talk) 20:05, 22 November 2020 (UTC)
  • Making ' and equivalent in titles would be needed. --Pols12 (talk) 02:42, 10 December 2020 (UTC)
  • I don't feel strongly either way, BUT I am concerned about all the possible ways it will get messed up during the editing process. One example I can think of is when people mean to type ’08, but word processors end up autocorrecting to ‘08 by virtue of it being seen as an opening quotation.   — TARDIS Builder (talk)   |     00:32, 16 December 2020 (UTC)
  • I know itʼs in the proposal, but it must be emphasized that this is language-specific, and cannot be imposed everywhere. Seb az86556 (talk) 22:05, 19 December 2020 (UTC)
It's not even language-specific, it's country-specific in the same language. Different country, different customs. Grüße vom Sänger ♫(Reden) 22:40, 19 December 2020 (UTC)

Voting

  • Support Support Alechri (talk) 18:35, 8 December 2020 (UTC)
  • Support Support I actually have that issue on my wiki. I have a category with a curly apostrophe. They should definitely be converted and make that a toggle option. MarioSuperstar77 (talk) 19:20, 8 December 2020 (UTC)
  • Support Support 5225C (talkcontributions) 00:05, 9 December 2020 (UTC)
  • Support Support Lion-hearted85 (talk) 03:07, 9 December 2020 (UTC)
  • Support Support Ciao • Bestoernesto 04:01, 9 December 2020 (UTC)
  • Support Support Flipchip73 (talk) 04:28, 9 December 2020 (UTC)
  • Support Support No such user (talk) 08:53, 9 December 2020 (UTC)
  • Support Support Abductive (talk) 08:55, 9 December 2020 (UTC)
  • Support Support It's also missing in the German Wikipedia. Jjkorff (talk) 13:36, 9 December 2020 (UTC)
  • Support Support Other websites (e.g., Medium) have implemented automatic conversion to typographic punctuation. This is a good feature and the fact that it would break functionality in IE shouldn't be relevant in 2021 in my opinion, since IE support officially ended. Hb2007 (talk) 14:18, 9 December 2020 (UTC)
  • Oppose Oppose Every editor I've ever used that tries to auto-convert simple consistent punctuation for purely stylistic reasons does a terrible job at it and accumulates inconsistencies that increase manual cleanup work. Consistency should not be compromised for style. DKEdwards (talk) 19:31, 9 December 2020 (UTC)
  • Oppose Oppose per DKEdwards Libcub (talk) 18:50, 10 December 2020 (UTC)
  • Support Support However, there must be an option to disable this. Dominic Z. (talk) 19:57, 10 December 2020 (UTC)
  • Oppose Oppose Context- and language- sensitive changes should not be done like this. —  HELLKNOWZ   ▎TALK   ▎enWiki 22:23, 10 December 2020 (UTC)
  • Support Support StringRay (talk) 16:25, 11 December 2020 (UTC)
  • Oppose Oppose That we only have plain ' and " available is in my opinion a major advantage in the enWP -- it prevents great deal of unnecessary tinckering and errors. DGG (talk) 01:08, 12 December 2020 (UTC)
  • Support Support Gnom (talk) 15:47, 12 December 2020 (UTC)
  • Oppose Oppose Way too easy to break things, and various projects have different standards anyway. We already have search-replace tools for use in wikicode, e.g. I'm using one on en.wikipedia (probably from a gadget, though I couldn't tell you which one right off-hand) that works quite well, including regex. (I use it to convert curly quotes to straight ones, normalize citation parameter names, etc.)  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:09, 15 December 2020 (UTC)
  • Support Support Vincent Ramos (talk) 19:30, 15 December 2020 (UTC)
  • Oppose Oppose Grüße vom Sänger ♫(Reden) 16:08, 19 December 2020 (UTC) definitely nothing for the whole Wikiverse, as this is done on a country by county base, in deWP we have different styles for articles, depending whether ist about Austria, Switzerland or Germany, how in earth should this be treated with the big brush for all and everything? If some project wants this for itself, they should ask their programming members about it.

Allow editing an entire page at once in the mobile app

Edit proposal/discussion

  • Problem: The mobile app only allows one section (including the lede) to be edited at a time
  • Who would benefit: Mobile editors.
  • Proposed solution: Allow the whole page to be edited at once.
  • More comments: Sometimes I want to move content between sections, or check that another section does not already cover the issue, and it is annoying having to go out of edit mode to do anything that involves the sections I'm not editing at the moment.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 03:47, 17 November 2020 (UTC)

Discussion

This is also an issue for the mobile browser version, so that should also be changed. Keepcalmandchill (talk) 04:20, 17 November 2020 (UTC)

  • Template:Agree this would be useful PAC2 (talk) 06:41, 17 November 2020 (UTC)
    I accidentally submitted too many proposals, so please consider resubmitting it after it gets removed. Keepcalmandchill (talk) 06:43, 17 November 2020 (UTC)

Supported your proposal. But this is what I do when I need to move contents between sections:

  • Say I would like to add a new section, Section B, in between Section A and Section C; I will edit Section A and just add the new content (with the header of the new section) below Section A.
  • Or if I would like to swap the positions of Section A and Section B; I will copy the source code of Section A and paste it below Section B (via editing only Section B), and later on edit the former Section A (above Section B) and just blank it.

It is very inconvenient, that's why I support your proposal, but just in case you didn't already know, those are the more inconvenient but possible ways of moving contents between/swapping sections. Also I wholeheartedly agree with you on the "have to go out of edit mode to refer to other sections" part. -Colathewikian (talk) 05:34, 9 December 2020 (UTC)

For now, on the mobile browser version, tapping the "edit" icon (that looks like a pen) on the top of an article only allows us to edit the lead section. I suggest that we be given two options when tapping that "edit" icon on the top:

  1. edit only the lead section;
  2. edit the whole page.

--Colathewikian (talk) 05:58, 9 December 2020 (UTC)

  • I do a lot of editing on a tiny mobile screen. But I always use Desktop view, and have no issues whatsoever editing an entire page. Why worry about the Wikipedia mobile app (which seems aimed at reading, not editing) when browser editing is easy and straightforward. Nick Moyes (talk) 09:50, 9 December 2020 (UTC)
    @Nick Moyes: I almost always edit on mobile too, but Desktop view on a mobile screen is really inconvenient to me: I have to constantly pinch to zoom in and out and I end up reading the words without caring to zoom in, which hurts my eyes. This is an issue not just for editing on the mobile app, but also the mobile browser. -Colathewikian (talk) 10:12, 16 December 2020 (UTC)
  • @Keepcalmandchill: Is it possible for you to edit your proposal to acknowledge that this is a problem for editing on the mobile browser too? (Since you only mentioned “mobile app” up there) -Colathewikian (talk) 10:05, 16 December 2020 (UTC)

Voting

  • Support Support MarioSuperstar77 (talk) 18:56, 8 December 2020 (UTC)
  • Support Support Dr747 (talk) 19:22, 8 December 2020 (UTC)
  • Support Support Kisnaak (talk) 21:21, 8 December 2020 (UTC)
  • Support Support Yes I totally support you; we should improve editing in Mobile App. شادي (talk) 22:07, 8 December 2020 (UTC)
  • Support Support Doggo375 (talk) 23:53, 8 December 2020 (UTC)
  • Support Support Also, this proposal is something I prefer to raise. ArriehM (talk) 00:02, 9 December 2020 (UTC)
  • Support Support 5225C (talkcontributions) 00:04, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 00:48, 9 December 2020 (UTC)
  • Support Support This would be useful Eric0892 (talk) 01:13, 9 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:29, 9 December 2020 (UTC)
  • Support Support BugWarp (talk) 01:44, 9 December 2020 (UTC)
  • Support Support * Pppery * it has begun 01:57, 9 December 2020 (UTC)
  • Support Support Yeah it doesn't make sense for mobile to be restricted like this ──post by kenny2wiki  Talk  Contribs  02:32, 9 December 2020 (UTC)
  • Support Support I do not use mobile app to edit. But I definitely support this proposal. Flipchip73 (talk) 04:24, 9 December 2020 (UTC)
  • Support Support —— Eric Liu留言百科用戶頁 04:33, 9 December 2020 (UTC)
  • Support Support Colathewikian (talk) 05:19, 9 December 2020 (UTC)
  • Support Support Munfarid1 (talk) 09:57, 9 December 2020 (UTC)
  • Support Support Brewster239 (talk) 12:36, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 22:34, 9 December 2020 (UTC)
  • Support Support dwf² (talk) 22:54, 9 December 2020 (UTC)
  • Support Support Srđan (talk) 18:11, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 19:07, 10 December 2020 (UTC)
  • Support Support Strong support for that one. It also will prevent that "vandalism police" thinks you are deleting content while you are moving text from one section to another. Alexcalamaro (talk) 06:22, 11 December 2020 (UTC)
  • Support Support one of the main barriers I've experienced when mobile editing. — Bilorv (talk) 09:05, 11 December 2020 (UTC)
  • Support Support Strong support. And the solution is OK. BoldLuis (talk) 14:41, 11 December 2020 (UTC)
  • Support Support Ameisenigel (talk) 16:35, 11 December 2020 (UTC)
  • Support Support TheLatentOne (talk) 19:56, 12 December 2020 (UTC)
  • Support Support Lalviarez (talk) 22:37, 12 December 2020 (UTC)
  • Support Support I am supporting this proposal, think is good. Farpen (talk) 13:45, 14 December 2020 (UTC)
  • Support Support~SHEKH (Talk) 15:52, 14 December 2020 (UTC)
  • Support Support Mobile editing is a "user-hateful" experience so far, and this problem is one of the major reasons why.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:49, 15 December 2020 (UTC)
  • Support Support ItsPugle (talk) 08:26, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:18, 15 December 2020 (UTC)
  • Support Support Natemup (talk) 05:09, 16 December 2020 (UTC)
  • Support Support especially useful for medium-lenght articles with ~ 2-3 sections Kku (talk) 06:42, 17 December 2020 (UTC)
  • Support Support Patsagorn Y. (Talk) 13:01, 17 December 2020 (UTC)
  • Support Support This is needed badly. Perhaps a preference setting could be made to switch between the two options of section only and entire page. JackFromReedsburg (talk) 17:55, 17 December 2020 (UTC)
  • Support Support Malvinero10 (talk) 02:46, 21 December 2020 (UTC)
  • Support Support Ahmadtalk 03:46, 21 December 2020 (UTC)
  • Support Supporttyseria 10:10, 21 December 2020 (UTC)
  • Support Support EEMIV (talk) 14:45, 21 December 2020 (UTC)

Spellchecker

Edit proposal/discussion

  • Problem: One of the most important aspects copy-editing workflow for users is finding and fixing spelling mistakes and typos.
  • Who would benefit: Editors who would have less frustration in their work and readers who would read a higher quality articles.
  • Proposed solution: There is something in Persian Wikipedia which I would expect can be used as inspiration and turn into an extension. That tool is called Check Dictation. When an editor who enabled the gadget sees an articles, on top of the page, they see list of mistakes and inside the article they get color coded. It actually has different colors for different issues: Typos, bad wikitext, informal words, links to disambig pages, and many more types. Here's an example File:Rechtschreibung-fawiki.png. You can also define per-article list of okay words an example. The code for the gadget can be found in here but it's highly hard-coded to fawiki and it can be improved drastically.
  • More comments:
  • Phabricator tickets:
  • Proposer: Amir (