# Community Wishlist Survey 2021/Editing

Editing
41 proposals, 89 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!

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

• Problem: By creating or changing links in VE, 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)

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

• 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.
• 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)

• Problem: Google Translate has some unnatural Japanese, so it's better to use deepl.

• Who would benefit: The person who translates

• Proposed solution:
• Phabricator tickets:
• Proposer: IPadBoy123 (talk) 07:03, 17 November 2020 (UTC)

## Allow editing an entire page at once in the mobile app

• 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)

## Allowing VisualEditor to edit by section

• 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)
• 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)

## Round brackets

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 Visual Editor for math tags should be usable without the mouse

• Problem: When using the visual editor you waste always a little bit of time when adding a math tag because you have to leave the keybord, click on the apply changes button and click again at the point you inserted the math tag in the text to return the curser and continue writing. On some articles this really adds up and breaks the writing flow.
• Who would benefit: Everybody who uses the math tag a lot
• Proposed solution: A shortcut like shift+enter to apply changes and after that the curser should be behind the new math tag.
• Phabricator tickets:
• Proposer: Nabloodel (talk) 21:51, 18 November 2020 (UTC)

### Discussion

• Good idea.AMX (talk) 18:00, 21 November 2020 (UTC)
• I'd love to see this too. It's easier for me to copy and paste a short formula and update it with new contents than to "Insert>More>(where is it?!)>Math formula" with the mouse. Ctrl+M as in LyX would be good, and the whole way math editing is done there too: Alt-M-a for α, Alt-M-f for \frac{}{}, etc. (maybe in 2022?). When formulas are inserted, they should be in a (new) "math paragraph style", indented, so that the hackish :[itex] would not need to be used any more. Ponor (talk) 03:33, 22 November 2020 (UTC)
• You can press Ctrl+Enter in any VE dialog to submit it. This works in Math dialogs too. ESanders (WMF) (talk) 16:21, 24 November 2020 (UTC)
Or Cmd+Enter on macOS. the wub "?!" 15:13, 30 November 2020 (UTC)
• I just came to say that I agree with the editor above. It would be awesome if we had a keyboard shortcut to insert math equations in the visual editor instead of insert>more>etc. —The preceding unsigned comment was added by Braulio rs (talk) 00:59, 27 November 2020 (UTC)
There is a shortcut sequence <math that will launch the math dialog. ESanders (WMF) (talk) 16:42, 28 November 2020 (UTC)
• Do the above keyboard shortcuts work for you? —SWilson (WMF) (talk) 02:50, 3 December 2020 (UTC)
The shortcuts do work, but are undiscoverable and unconfigurable (?). Any reason why Ctrl+M could not be a shortcut for (one of) the math dialog(s)? Are there any other shortcut sequences we should know about? Thnx, Ponor (talk) 07:23, 3 December 2020 (UTC)
• The <math shortcut is the same as for various other wikitext shortcuts: if you start typing the beginning of a known construct, VE realises and gives you the appropriate dialog (e.g. <ref to get a reference). The ctrl-enter shortcut is a fairly common one, and is standard in OOUI and therefore in lots of Wikimedia software. As for making them more known about, I think the main reference is mw:VisualEditor/Portal/Keyboard shortcuts. —SWilson (WMF) (talk) 08:13, 3 December 2020 (UTC)
There is a keyboard shortcut help dialog within the editor itself (under the help menu, or ctrl + ?). There are very few single letter shortcuts that aren’t already in use by VE, the browser or the operating system. The few that are left we probably wouldn’t want to assign to less-frequently used tools like the math dialog.
Other options here may be to implement user customisation as you suggest (although that would be a very complex undertaking) or to use more complex modifiers, like ctrl+shift, or alt+shift. ESanders (WMF) (talk) 12:39, 3 December 2020 (UTC)
There is the acronym RT*M for a reason, I guess :) My apologies. What's confusing is that other menus in VE list the shortcuts, but not the Insert menu. That should be an easy fix. (shortcuts like <MM [or <mm], <SS, <CC would be even more awesome, even if only as easter eggs) Thanks for your responses! Ponor (talk) 16:09, 3 December 2020 (UTC)
We distinguish between shortcuts (pres "ctrl+x") and sequences (type "<math") as they behave slightly differently. We currently only short shortcuts in the menu, although what you are suggesting is that we show sequences as well. I think there is an argument for that to happen, especially when no other shortcut is available. ESanders (WMF) (talk) 20:17, 3 December 2020 (UTC)

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

• Problem: An WP edit is lost when the editor's network goes down.
• Who would benefit: Any editor who doesn't 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:
• 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. 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)

## Add monospaced text in Visual Editor

• 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
• 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)

## Add indentation and alignment features to visual editor

• 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.
• 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)
• 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)

## Allow past edits to be filtered by size

• 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).
• 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)

## Edit 'macros'

• 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).
• Phabricator tickets:
• Proposer: Dirk Beetstra T C (en: U, T) 12:41, 30 November 2020 (UTC)

### 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.
• 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)

## New keyboard shortcuts

• 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.
• Phabricator tickets:
• Proposer: Toccata quarta (talk) 07:56, 25 November 2020 (UTC)

## Add functionality to "insert reference" shortcut

• Problem: Fully completing all the information for a good citation referencing a URL can be daunting for new or inexperienced users
• Who would benefit: Pretty much all editors, I think.
• Proposed solution: When someone adds a citation using the shortcut (ref/ref insertable markup), either:
1) automatically recognize when a URL has been cited, format it properly (perhaps even test it), add a retrieval date and take care of other housekeeping, or
2) bring up a dialog box to allow the editor to (optionally) complete the citation
• Phabricator tickets:
• Proposer: Patrickwooldridge (talk) 17:58, 18 November 2020 (UTC)

### Discussion

• Hello Patrickwooldridge! If you don't mind, could you please fill out the "Problem" statement above? That will help give context to the issue you're facing. Thanks, MusikAnimal (WMF) (talk) 21:09, 18 November 2020 (UTC)
Hi MusikAnimal. Done. Sorry Patrickwooldridge (talk) 23:29, 18 November 2020 (UTC)
• Well, Reftools already has functionality for filling out portions of a reference automatically using the magnifying glass; it's particularly good for journal articles with a DOI. But it's not as great for newspapers; some, such as Bloomberg, have issues (see task T210871) or just don't work. And none do things like wikilinking the publication name, which would be nice. {{u|Sdkb}}talk 02:53, 19 November 2020 (UTC)

## Warn when linking to disambiguation pages

• 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.
• Phabricator tickets:
• Proposer: Rodw (talk) 08:34, 27 November 2020 (UTC)

### Discussion

en:User:Anomie/linkclassifier has similar functionality, I think. Jo-Jo Eumerus (talk, contributions) 14:15, 27 November 2020 (UTC)

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)

## Шаблоны

• 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)

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

• 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

• 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)

## Convert typographic replacement characters like straight apostrophes and quotation marks

• 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.
• Proposed solution: Substitute ASCII replacement characters while editing.
• 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)

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

• 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.
• 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'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)

## Add global LaTeX macros for math in math tags

• 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

• 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.

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)

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)

## Allow editors to control PageImage

• Problem: The PageImage for a given page is automatically selected by the software. Normally this works well, but there can be instances where it does not pick the most appropriate image e.g. w:Jim Crow laws where it takes the image from apartheid South Africa which is used in the navbox. Another example: Articles on upcoming elections often contain an image of each candidate. PageImage can grab one candidate photo and use it as the image for the election itself (thanks Alsee for pointing this issue out on Phabricator). PageImages are used in many places such as Page Previews, mobile search results, and fairly soon will start being used in desktop search bar results (as part of Desktop Improvements. There's also other potential uses such as in social media previews.
• Who would benefit: Editors through having more control, readers through seeing more appropriate images
• Proposed solution: It should be possible for editors to override the automatic PageImage choice, by use of a "magic word" or some other method.
• Phabricator tickets: phab:T91683, phab:T265713
• Proposer: the wub "?!" 17:54, 30 November 2020 (UTC)

## Unbreak selection in the wikitext editor

• 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.
• 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)
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)
• 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)

## Dropdown list option for edit summary

• Problem: Include Dropdown list option for edit summary
• Who would benefit: all editors, specially new editors, minor edits etc.
• Proposed solution: right or left corner of edit summary field, an optional dropdown list can be included which will fill edit summary, insted of typing summary, it will alternately benefit new editors to understand how to fill the edit summary.
• Phabricator tickets:
• Proposer: Omer123hussain (talk) 05:34, 23 November 2020 (UTC)

### Discussion

• I see little added value. Modern browsers have an autocomplete function, that shows previously and frequently used summaries. Geert Van Pamel (WMBE) (talk) 18:46, 23 November 2020 (UTC)
• @Geertivp: I'm not sure I particularly care about / support this proposal, but on the question of possible benefit to those who would: The value could be summed up as simply the difference between typing 2 or 3 characters, and typing zero. (And if you still don't see any potential value, write a few edit summaries from a mobile device and get back to us...) -- FeRDNYC (talk) 00:31, 24 November 2020 (UTC)
I have tried it on my smartphone. The browser proposes me a list of matching edit summaries immediately after I start typing at least 1 character... Geert Van Pamel (WMBE) (talk) 18:46, 26 November 2020 (UTC)
• AFAIK, there are some local tools already doing this. — Draceane talkcontrib. 17:41, 24 November 2020 (UTC)
This function already exists on the en: Wikipedia. Geert Van Pamel (WMBE) (talk) 22:27, 26 November 2020 (UTC)
I believe the relevant gadget is w:en:MediaWiki:Gadget-defaultsummaries.js. —The Editor's Apprentice (talk) 22:56, 28 November 2020 (UTC)

## Copy and paste from diffs

• 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.
• Phabricator tickets: T192526
• 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)
• 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)

## Allow editors to write an edit summary from the edit preview

• 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.
• 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)

## List of nested templates

• 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)

## Let Visual Editor to edit references in notes

• Problem: Visual Editor cannot handle references in notes.
• Who would benefit: every editor, new editors
• Proposed solution: Let Visual Editor to handle references in notes the same way as every other reference on the page.
• Phabricator tickets:
• Proposer: Juandev (talk) 20:01, 21 November 2020 (UTC)

### Discussion

• Can you be more specific? VE will let you edit references that are used to generate a "notes" section. ESanders (WMF) (talk) 16:38, 24 November 2020 (UTC)

## Better diff handling of paragraph splits

• 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
• 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)

## 请求修正“NoteTag”模板的预览

• 問題: {{NoteTag}} 模板用于添加备注，在大量条目中被广泛使用，但官方版本存在一个长期未被修正的 bug：使用此模板后会出现相应的蓝色角标（样式为[注] 或 [a] [b] 等字母），而点击角标后弹出的预览上面，却显示着参考文献的标志（一本书的图标和加粗的“参考文献”字样，英文维基百科为“CITATION”字样）。备注无疑不等于参考文献，它们是两个不同的概念，如此显示肯定是不合理的。
• 有益於誰: 所有维基百科用户
• 提案的解決方案: 去掉备注预览中的参考文献标志，或者专门制作一个备注预览弹窗，与纯粹的参考文献预览弹窗区分开来。
• 更多評論:
• Phabricator請求:
• 提案者: 蕭漫 (talk) 02:44, 27 November 2020 (UTC)

• 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 unreasonable.
• 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.
• Phabricator tickets:
• Translator: Steven Sun (talk)

## Live preview

Live preview
• Problem: Wikitext editors often skip the step of previewing their edits, missing simple typos and formatting errors that could be easily avoided if previewed live.
• Who would benefit: Wikitext editors
• Proposed solution: Something akin to w:User:TheDJ/Actual Live Preview, though this script hasn't worked for me in years, that would display a live preview side-by-side with the wikitext editor
• Phabricator tickets:
• Proposer: czar 20:05, 22 November 2020 (UTC)

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

• 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)

## Tool for easy user buttons

• 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 cusrsor text after cursor picture tooltip
X coord {{Coord|lat |lon|}} Coordinates
X hello Hello world insert hello world
O speedy {{Delete}} nominates for deletion
X char ʘ 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

• 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)

## Spellchecker

• 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.
• Phabricator tickets:
• Proposer: Amir (talk) 18:31, 16 November 2020 (UTC)

### Discussion

I think most operation systems and browsers support spellchecking on their site so this is not needed in MediaWiki. --GPSLeo (talk) 18:40, 16 November 2020 (UTC)

@GPSLeo You wouldn't see the typos unless you go to edit mode. How to find them in articles is not doable with browsers and operating systems. Amir (talk) 19:33, 16 November 2020 (UTC)
Ah, you want a tool to find mistakes in articles just while reading not for editing. I did not got this. Now I understand and think this could be useful. --GPSLeo (talk) 21:23, 16 November 2020 (UTC)
The Chrome spellcheck does not work for me when editing. Keepcalmandchill (talk) 03:45, 17 November 2020 (UTC)

There is a similar user script for the MOS called en:User:Ebrahames/Advisor.js on EN.WP. I don't think I've seen a spelling gadget. I also tend to disagree that a spelling gadget is necessary. (Mis)Spellings can be context dependent. --Izno (talk) 21:55, 16 November 2020 (UTC)

@Izno The spelling gadget would just highlight potential spelling mistakes. Even in the tool in fawiki, you can set highlights as false positive on per-article basis. Amir (talk) 03:33, 22 November 2020 (UTC)

I usually just use Grammarly to check grammar (not sponsored). Félix An (talk) 02:27, 17 November 2020 (UTC)

Would this also take regional variants of English into comparison? English Wikipedia articles can vary depending on regional relevance or by a "first-come first-serve" edit. Tenryuu (talk) 02:29, 17 November 2020 (UTC)

English is not the only language with spelling variances, so good question. --Izno (talk) 18:08, 17 November 2020 (UTC)

Note, that also in Wikisource are various variants of language, language of 100 years old work is different from todaylanguage, but it is also correct. THere should be some project-specific spellchecker, which allows local variants. JAn Dudík (talk) 14:09, 18 November 2020 (UTC)

I think the points made by other users about language variation are good, but as long as the changes are not automated and a human is always involved that person should be able to recognize when a word was incorrectly marked as a misspelling and not act to fix it. For languages that have detailed Wiktionaries, they might be a good source to use for checking what is and isn't a recognized spelling. This orange links gadget has functionalities that also might relevant to this proposal. —The Editor's Apprentice (talk) 19:21, 20 November 2020 (UTC)

thanks for posting this. How does the Check Dictation tool work? Does it use some open-source Persian spellchecker? Or is it handmade with a list of common mispellings? I ask because the Growth team is building "structured tasks", which use machine learning to help newcomers find specific edits to make, e.g. adding wikilinks. Here are notes from a conversation about how to make spellchecking possible across languages, and we're thinking about whether it would have to be done language by language. -- MMiller (WMF) (talk) 17:19, 23 November 2020 (UTC)

@MMiller (WMF) The code for it is w:fa:مدیاویکی:Gadget-CheckDictation.js and it seems it calls a service in the cloud VPS (I didn't write this gadget so I'm not 100% sure of its internals) but I assume it uses a unix library for spellchecking. As I said, it has an exception list for each page as well [8]
The fun thing is that this was originally was developed to find spelling mistakes but it grew to basically any sort of copy-editing issues from links to disambig pages, to unclosed links/templates, to much more. Amir (talk) 00:28, 24 November 2020 (UTC)

I would support the idea, but in the context of a typographic checker, not just a spellchecker. It would check grammar, adjectives, orthography, etc. MarioSuperstar77 (talk) 21:06, 24 November 2020 (UTC)

• I'm merging a similar wish:
• Problem: عربى: وجود مدقق لغوي داخلي للنصوص شبيه بما يقوم به برنامج word
• Proposer: عمر الشامي (talk) 21:09, 22 November 2020 (UTC)

SGrabarczuk (WMF) (talk) 20:25, 3 December 2020 (UTC)

## Translation tool for wikitext snippets

• Problem: AFAIK Translator only works for whole existing pages, and if you need only a part of the content from somewhere it cannot be used if target page already exists. Also, such translator could be used in case of bugs while loading the original page, which occurs from time to time.
• Who would benefit: All
• Proposed solution: Implement translator functionality to enable wikitext snippet input as an alternative to page focused approach. After wikitext is copied into the translator input window, the translator should continue to function in visual mode, and the final result should be available again as a wikitext or alternatively as a page in user space.
• Phabricator tickets:
• Proposer: Imbehind 21:00, 18 November 2020 (UTC)

### Discussion

• If I understand correctly and you're talking about Content translation, this suggestion is the same as what the upcoming Section translation feature of the ContentTranslation extension will do. This project is already in development, so it doesn't have to compete in the wishlist vote :) --Amir E. Aharoni (talk) 18:47, 26 November 2020 (UTC)
@Imbehind: Does Amir understand you correctly? If so, we will archive this wish as it's already being worked on. Thanks, MusikAnimal (WMF) (talk) 03:01, 3 December 2020 (UTC)
, @Amire80: - not necessarily. Section translation would be a big improvement, of course, but why don't just go all the way? New sentences of wikitext, for example, once inserted in the original text, would not be translatable via section translator feature, or could be, but it would be complicated. Also, there is often an example of ordinary text to be newly inserted into the article and translated, not inserted anywhere within WP before. Or if you want to translate a snippet of related page to be inserted on different target language page. I could go on and on. All of that would be easily solved with one button which would display a modal window for arbitrary wikitext insertion. Once the wikitext is inserted, switch to VE, and after the translation is done you could either save the snippet in your user space, as a new page, or (even better) copy/paste the translated wikitext into the article you are working on. For instance, I'm working on evolution related content. As such, I often have the need to pick and choose at least 10-15 snippets from English wiki article, translate them, and insert them into the Croatian wiki. Those snippets are from different sections, say 2-3 from each. If I would need to use by section translation, it would complicate my work considerably. The alternative would be to give the users the ability to translate any page in their user space to any language - I would prepare the snippets within my userspace, translate, save, and than copy to the article. I would still prefer copy/paste arbitrary wikitext approach in any case. Cheers! Imbehind 04:15, 3 December 2020 (UTC)
User:Imbehind, thanks for the clarification! What do you think about Community Wishlist Survey 2021/Miscellaneous/Templates translation? See the section at the bottom, "Practical suggestion: refactor CX template adaptation". What you suggest here sounds very similar to what I suggest there: a panel that allows the translation of a template from one wiki to another. I even added mock-ups there. My suggestion there is more modest, only talking about automatic translation of the template title and parameters, and leaving the translation of parameter values to the human editor. But if this is done, it can later be easily extended to covering any wikitext and not just templates. --Amir E. Aharoni (talk) 07:43, 3 December 2020 (UTC)
@Amire80:, I'm not sure if your template request is more modest. It doesn't sound complicated but for my proposal, everything apart from a button and modal window for input and output is already there. I'm not sure the same could be said about the templates, but your proposal is also worthwile. Imbehind 14:00, 3 December 2020 (UTC)

## Enabling preview data on the 2017 wikitext editor

• 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.
• Proposer: Tenryuu (talk) 23:39, 24 November 2020 (UTC)

## Predictive edit summaries based on changes to article text

• 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.
• Phabricator tickets:
• Proposer: czar 01:54, 22 November 2020 (UTC)

## Expand "minor edits" checkbox-feature

• 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)

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

• 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:
• Phabricator tickets:
• Proposer: Nabloodel (talk) 19:17, 19 November 2020 (UTC)

### Discussion

• 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 :[itex] 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 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)
• The :[itex] 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 :[itex] 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)

## Unintentional false links in VE

• 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 (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)

## Select templates by categories

• 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.