Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Editing

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



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.
  • More comments:
  • Phabricator tickets:
  • Proposer: Slashme (talk) 22:03, 21 November 2020 (UTC)[reply]

Discussion

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)[reply]
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)[reply]

Voting

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.

Discussion

Voting

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)[reply]

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)[reply]
  • 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)[reply]

Voting

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)[reply]

Discussion

Voting

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

  • 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)[reply]

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)[reply]

Voting

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

Discussion

Voting

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

  • 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)[reply]
  • Translator: Steven Sun (talk)

Discussion

Voting

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

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)[reply]
.mw-disambig { background-color:#AFEEEE; }
.mw-redirect { background-color:wheat; }

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

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)[reply]
Thanks for clarifying this. Geert Van Pamel (WMBE) (talk) 19:02, 20 December 2020 (UTC)[reply]
  • Ruwiki solution:
    ru:MediaWiki:Gadget-disambiguationLinks.css
    ru:MediaWiki:Gadget-disambiguationLinks.js Carn (talk) 20:13, 19 December 2020 (UTC)[reply]
  • 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)[reply]

Voting

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

Discussion

Voting

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).
  • More comments:
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:46, 20 November 2020 (UTC)[reply]

Discussion

Voting

Make insertable markup customizable

  • 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)[reply]

Discussion

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

@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)[reply]

@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)[reply]
Nah, localStorage is not persistent enough for some use cases. AS (talk) 20:01, 8 December 2020 (UTC)[reply]

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)[reply]

@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)[reply]

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)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets:
  • Proposer: BenJenkins (talk) 16:40, 17 November 2020 (UTC)[reply]

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)[reply]

  • 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)[reply]
Preview first is already an option though.... --Izno (talk) 05:23, 18 November 2020 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

Voting

  • 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)[reply]

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)[reply]
  • 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)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets: T123694
  • Proposer: GeoffreyT2000 (talk) 20:35, 16 November 2020 (UTC)[reply]

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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
+1 to this! --Slashme (talk) 21:53, 21 November 2020 (UTC)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets: phab:T55590
  • Proposer: Steven Sun (talk) 01:11, 18 November 2020 (UTC)[reply]


Discussion

Voting

Pinging discussants about wish selection and other updates

Hello everyone,

This is a ping to let you know that this wish and 3 other requests related to templates have been selected for development.

Secondly there are updates regarding the Wishlist Survey. A mockup of the new wish proposal form is available. There is also an update on changes coming to how participants vote.

Additionally, come let's explore this idea to group wishes into Focus Areas; a Focus Area may be adopted by various movement stakeholders for addressing. The first example is the Template Picker Improvements Project, which groups four related wishes about template improvements (e.g. adding infoboxes and bookmarking templates).

You can read more and join the discussion. –– STei (WMF) (talk) 14:40, 18 May 2024 (UTC)[reply]

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ Pinging discussants. –– STei (WMF) (talk) 14:41, 18 May 2024 (UTC) [reply]

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)[reply]

Discussion

Voting

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)[reply]

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)[reply]

  • 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)[reply]

@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)[reply]

Voting

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 cursor 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

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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]

Voting

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
  • Phabricator tickets: task T156439, task T7072
  • Proposer: czar 02:11, 22 November 2020 (UTC)[reply]

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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]

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

Voting

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.
  • More comments:
  • Phabricator tickets:
  • Proposer: WikiAviator (talk) 06:12, 17 November 2020 (UTC)[reply]

Discussion

Voting

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.
  • More comments:
  • Phabricator tickets: T125145
  • Proposer: Srđan (talk) 00:46, 20 November 2020 (UTC)[reply]

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)[reply]

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

+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)[reply]

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

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

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)[reply]

Voting

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

  • 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)[reply]

Discussion

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)[reply]
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)[reply]
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)[reply]
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)[reply]
2) that is the same as this request
3) it isn’t as it stands ESanders (WMF) (talk) 14:02, 24 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]

Voting

  • 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)[reply]

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)[reply]

@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)[reply]
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)[reply]
@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)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets: T192526, T270775
  • Proposer: Rschen7754 01:16, 17 November 2020 (UTC)[reply]

Discussion

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)[reply]

Voting

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

Discussion

Voting

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

  • 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)[reply]

Discussion

Voting

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

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)[reply]
  • 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)?
  • 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)[reply]
    @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)[reply]
    Ah, that explains a lot. Thanks @Pelagic! Tenryuu (talk) 22:40, 16 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]

Voting

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)[reply]

Discussion

Voting

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.
  • Phabricator tickets: task T267048
  • Proposer: Tenryuu (talk) 23:39, 24 November 2020 (UTC)[reply]

Discussion

Voting

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)[reply]

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 (talk • contribs) 09:36, 24 November 2020 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]

Voting

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
  • More comments:
  • Phabricator tickets:
  • Proposer: Dixy52 (talk) 14:01, 19 November 2020 (UTC)[reply]

Discussion

Voting

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.
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]

Voting

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)[reply]

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)[reply]

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)[reply]

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)[reply]

  • 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)[reply]
    @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)[reply]

Voting

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

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)[reply]

@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)[reply]
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)[reply]
The Chrome spellcheck does not work for me when editing. Keepcalmandchill (talk) 03:45, 17 November 2020 (UTC)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

@Ladsgroup: 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)[reply]

@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)[reply]

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)[reply]

  • 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)[reply]

A spellchecker and grammer-checker would be both be useful tools. They should be separate tools. The spellchecker should have the ability to set the English variety. I have encountered many articles that use several varieties and it would be useful tool to edit to the desired variety. User-duck (talk) 18:32, 8 December 2020 (UTC)[reply]

English Wikipedia already has an active spellchecking project that finds spelling errors and a small number of manual of style violations in the latest database dump - see en:Wikipedia:Typo_Team/moss. We're currently doing this by making wiki pages full of lists and relying on editors to go through the lists. It's taking years to get to all the likely typos, and though we're catching up, of course more are added all the time. Any UI that increases automation of this task, either by interested volunteers working from lists or by capturing work done by folks who just happened to be reading the article, would be very helpful. We are slowly starting to advertise problematic cases to readers using tags in the articles themselves (see en:Template:Typo help inline). This sort of tag could be a hook for a little interactive UI that resolves the spelling issue into a small number of bins (add to dictionary, proper noun, change to correct spelling, unsure). Or a reader-centric spell checker could find typos on its own without help from tags. Though there's something to be said for storing "not a typo" sorts of information in the article itself, so that if a different spelling or grammar checker comes by later, we won't duplicate work. As for dialect detection...many English Wikipedia articles also have templates declaring the preferred dialect, and in some cases the category membership associates an article with a specific country, too. But even without these things in most cases I think it's pretty easy to tell which dialect a page is mostly or completely written in. Wiktionary already knows which words go with which dialect, and we can simply count up the number that are unique to one or the other. Any reader's web browser's built-in spell checker is probably going to properly handle only their own dialect, and that's too cumbersome for most readers to change. (So it's helpful to build a new system that's smart enough to deal with multiple dialects.) -- Beland (talk) 08:37, 12 December 2020 (UTC)[reply]

Voting

  • 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.
  • More comments:
  • Phabricator tickets:
  • Proposer: Omer123hussain (talk) 05:34, 23 November 2020 (UTC)[reply]

Discussion

Voting

Request Feedback (Richiedi feedback)

italiano: Richiedi feedback

  • Problem: Sometimes it happens to want to add info but do not have sufficient certainty.
italiano: Talvolta capita di voler aggiungere info ma di non avere certezze sufficenti.
  • Who would benefit:
  • Proposed solution: A function could be added to request feedback on a change
italiano: Si potrebbe aggiungere una funzione per richiedere feedback su una modifica

Discussion

  • I'm somewhat mixed about this. On the one hand, it's something that I see new editors in particular wanting quite a lot. On the other hand, this proposal doesn't really lay out concretely how it would work. Would it be another button in the edit window alongside the preview button? Who would provide the feedback? What would happen if the page changed in the meantime? Etc. I'd want to see this fleshed out more before supporting. {{u|Sdkb}} talk 05:49, 9 December 2020 (UTC)[reply]
  • I think the Talk page exists for this reason. When an editor is not confident enough to revise the article, changes are proposed and discussed there. Anyway, I don't think that content the editor is uncertain about should be published immediately in the article. Lion-hearted85 (talk) 11:19, 9 December 2020 (UTC)[reply]
  • You select instead of publish button, the "request feedback" button. The changes would be added as a section in the talk page with a {{feedback requested}} template in the beginning of the section.--BoldLuis (talk) 14:57, 11 December 2020 (UTC)[reply]
  • Are these proposals – when developed – globally enabled on all wikis? I feel like this specific proposal would work for some wikis but in smaller Wikipedias like rowiki the feedback would just clutter talk pages without getting any attention from anyone. Gikü (talk) 23:15, 17 December 2020 (UTC)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nabloodel (talk) 21:51, 18 November 2020 (UTC)[reply]

Discussion

  • @Nabloodel: 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)[reply]
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)[reply]
@SWilson (WMF) and ESanders (WMF): 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)[reply]
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)[reply]
@ESanders (WMF):The thing is, only people familiar with wiki markup will discover those sequences, most likely by chance; you can see that from this very proposal and the comments. If my only experience is with VE, I will not want to enter <math>, because that's not something I want to be shown. So yes, please add (some of) those sequences to the menu, I'm sure many will be grateful. You know how bad people are at reading manuals ;) Ponor (talk) 14:47, 4 December 2020 (UTC)[reply]

Voting

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.
  • More comments:
  • Phabricator tickets: phab:T91683, phab:T265713
  • Proposer: the wub "?!" 17:54, 30 November 2020 (UTC)[reply]

Discussion

PageImages should not take the image from a navbox in any case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 8 December 2020 (UTC)[reply]

Indeed! That's just ridiculous, and certainly explains many instances of senseless and confusing PageImages.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:52, 15 December 2020 (UTC)[reply]
I think English Wikipedia is already set to only pull PageImages from the lead (lede) section? (Remember reading somewhere there is a per-wiki setting for that, correct me if I'm wrong.) In some cases this is undesirable, for example if there is no infobox, or the infobox image is the wrong aspect ratio, but there is a better image lower down in the article. Pelagic (talk) 21:59, 17 December 2020 (UTC)[reply]
Perhaps need two settings: (a) use specified image, (b) exclude this image from consideration. Then we could build (b) into templates like "part of a series on..." (If PageImages is pulling the info from Parsoid rather than raw wikitext (?), it might be unable to distinguish surrounding context though.) Pelagic (talk) 22:10, 17 December 2020 (UTC)[reply]

I'd also like to have the options to set a separate banner image, to specify a crop area within an image, and to pad a specified colour around a wide image like a logo. The banners on iOS Wikipedia app are automatically cropped down from the page image and often look sub-optimal. Perhaps the PageImage API should support an aspect parameter with values like square, wide so that other consumers can tap into the choice also. Pelagic (talk) 21:59, 17 December 2020 (UTC)[reply]

Comment Comment I've opposed the solution as-proposed as I believe it would be harmful to the quality of our content and community long-term. The immediate proposal might help you and I to fix a few pet-peeves in the short-term but ultimately, I think it helps no-one. We don't need yet another thing for every editor to discover, learn about and use "correctly". We need to think more outside the box and long-term. This isn't meant as criticism on the author, I love that attention is drawn to this problem. But figuring out appropiate and scalabe solutions that don't result in a net-loss for our mission isn't always easy. It also doesn't need to be decided during the wishlist process as far as I'm concerned, it'd be more than fine to defer that to the implementation phase. Sometimes issues have easy, obvious, and harmless solutions. But, in this case I think we need to approach the problem differently. Others have already pointed out that it would be challenging to surface this in an intuitive manner, and to avoid it going out of sync as the article evolves.

  • If we copied the name of the second image to the proposed PageImage override, what would happen if that image is deleted or otherwise delinked? It'll go straight back to the "wrong" image.
  • This would introduce yet another novel new way to attach media files to an article, which CommonsDelinker, AutoWikiBrowser, pywikibot etc would all need to understand and support.
  • If a regular infobox is added or otherwise a good image is added in the introduction section, it would not be picked up by PageImages due to the override.
  • If the natural instance of the photo in the article is replaced with an improved or similar photo of the same subject, the override would become outdated, which would likely not be obvious to most, and perhaps conside the editor into thinking the software is broken or outdated/cached for some reason.

In the given example of w:Jim Crow laws I think the problem isn't so much that "we" like a non-first image more than the first image, but rather the first image isn't meant for consideration at all. Providing tools for editors to mark and exclude such images would, I think, help us long-term and ultimately allows contributors to spend more time on other things instead. In the very unlikely scenario where there are multiple good images to consider but we still like the later ones more, we could apply the same marker to the first real image. The behaviour would be contextual, obvious, easily discoverable, and naturally evolve with the content when things are added or re-arranged. --Krinkle (talk) 03:47, 21 December 2020 (UTC)[reply]

Voting

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
  • More comments:
  • Phabricator tickets:
  • Proposer: czar 20:05, 22 November 2020 (UTC)[reply]

Discussion

If implemented, this should be a per-edit action (like the existing Preview or Show Changes button), not a per-user preference. I might want a side-by-side preview on a big, wide desktop monitor, but not when using desktop-web on a tablet in portrait mode. For users who change between devices, visiting the pref's each time would be cumbersome. Pelagic (talk) 22:27, 17 December 2020 (UTC)[reply]

This is a very good idea, but it doesn't go far enough. I propose an enhancement under which an editor could freely toggle between three editing modes:

  1. Only wiki markup editing.
  2. Only visual editing.
  3. Both kinds of editing, available concurrently. In this mode, an editor could choose whether the two editing windows will be side by side or one above the other, and which window will be above or at the left. These preferences could be saved. The editor could then edit the wikitext and quickly see the effect on the appearance of the page. This is what Czar had in mind. With this enhancement, however, the editor also could edit visually and quickly see the effect on the wikitext. Why display a non-editable preview, when a visual editing tool exists? Instead, let's open both the wiki markup editing tool and the visual editing tool simultaneously, on a split screen. The editor could then switch from one kind of editing to the other kind, simply by moving the cursor from one editing window to the other editing window.

Continuous, automatic updating might be impractical. It might require too much processing and data transmission. If so, let it occur on demand, whenever the editor clicks on the Update button or invokes the corresponding keyboard shortcut. Ubzerver (talk) 13:33, 21 December 2020 (UTC) Revised. Ubzerver (talk) 14:15, 24 December 2020 (UTC)[reply]

I hadn't even noticed that people had suggested this one (based on something I made before). I do have some points on this and I figured I'd add them for future reference.
Yes, it really only works when you have a pretty large/wide screen. My gadget also used to work like that. It would check if your screen was a certain size and only then enable this functionality, without the appropriate width (1200 web pixels), you would only get the 'regular' preview above or below the edit window, with not updates. While this 'worked', it was also rather confusing to many people. Interface elements that 'randomly' disappear often have this effect and it's a bit bad form. Instead, looking at it again, It would probably be better to have a tabbed interface to switch between source and preview mode (the original WE2010 editor actually had such a tabbed mode interface, but it was never released). Then we could have a separate control to switch between tabbed and side-by-side modes if you have sufficient screen real estate and a control to enable/disable live previews.
Another big problem was keeping proper track of what wiki text corresponded to which part of rendered html (allowing you to keep the part you are editing in the displayed part of the preview). With something like parsoid that might be much easier to fix however. And I do agree that live preview should be an option you can easily toggle on and/or off. Ideally it would test the performance and based upon the test increase or decrease how often an update would occur.
Perhaps it is a good idea to think about the resizable panes and boxes inside IDEs etc for instance, that can be pinned and unpinned in various different ways, orientations and layouts. I think that would make for an interesting exploration. —TheDJ (talk • contribs) 12:58, 6 January 2021 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Editing&oldid=20877422"