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

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

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

Voting

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

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

Discussion

  • This has been discussed in previous years. --Izno (talk) 04:59, 18 November 2020 (UTC)Reply[reply]
  • 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)Reply[reply]

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

Discussion

Voting

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

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[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[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[reply]
  • 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)Reply[reply]
    Code to pick the correct link could be shared with a Dablinks replacement. Certes (talk) 17:10, 9 December 2020 (UTC)Reply[reply]
  • For the solution. It can ask if you want to preview the disambiguation page in another browser window or tab. The user could surf from there to a disambiguated page (then could click a button in VE to add this page instead of the disambiguation page)--BoldLuis (talk) 14:39, 11 December 2020 (UTC)Reply[reply]
  • As an easy solution, to activate this option for all your wikis, you can edit m:Special:MyPage/global.css to contain:
.mw-disambig { background-color:#AFEEEE; }
.mw-redirect { background-color:wheat; }

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

  • Thanks for this but I suspect most editors don't do this (or may not even know about it) otherwis we wouldn't be getting 500-800 links to dab pages being created every day.Rodw (talk) 11:55, 15 December 2020 (UTC)Reply[reply]
    So this is why we want a global solution, thanks to the below "Support" votes... Geert Van Pamel (WMBE) (talk) 13:38, 15 December 2020 (UTC)Reply[reply]
  • Heißt das, der Haken beim Begriffsklärungscheck (d:Q6047536) sollte automatisch gesetzt sein? Denn die Funktionalität ist ja schon lange vorhanden, auch ohne dafür zum Scriptkiddie mutieren zu müssen. Grüße vom Sänger ♫(Reden) 09:38, 19 December 2020 (UTC)Reply[reply]
    This Gadget seems not to be available on all Wikis? Geert Van Pamel (WMBE) (talk) 16:23, 20 December 2020 (UTC)Reply[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[reply]
Thanks for clarifying this. Geert Van Pamel (WMBE) (talk) 19:02, 20 December 2020 (UTC)Reply[reply]
  • Ruwiki solution:
    ru:MediaWiki:Gadget-disambiguationLinks.css
    ru:MediaWiki:Gadget-disambiguationLinks.js Carn (talk) 20:13, 19 December 2020 (UTC)Reply[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[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[reply]

Discussion

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

Voting

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

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

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)Reply[reply]
  • 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)Reply[reply]
  • See also Miscellaneous/Add filters to history pages. the wub "?!" 15:43, 30 November 2020 (UTC)Reply[reply]
  • Changes that are small in size are not necessarily minor in content. Sneaky vandalism or falsification can radically change content with a zero-byte change. Nurg (talk) 08:55, 9 December 2020 (UTC)Reply[reply]
  • Une modification peut être désignée comme mineure ou apparaître comme mineure (1 lettre, 1 mot changé, voire une ponctuation) et pourtant, être du vandalisme ou une modification importante à vérifier. Cdmt' --Mylenos (talk) 12:19, 9 December 2020 (UTC)Reply[reply]

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[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[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[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[reply]
Nah, localStorage is not persistent enough for some use cases. AS (talk) 20:01, 8 December 2020 (UTC)Reply[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[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[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[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[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[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[reply]
Preview first is already an option though.... --Izno (talk) 05:23, 18 November 2020 (UTC)Reply[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[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[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • This is phab:T140451 and/or phab:T148297. ESanders (WMF) (talk) 15:56, 24 November 2020 (UTC)Reply[reply]
  • Also, (temporary) Edit Summary should not be lost when switching between Visual Editor & Source Editor. RavBol (talk) 22:49, 14 December 2020 (UTC)Reply[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[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[reply]

Voting

Markdown syntax to wiki link conversion gadget

  • 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[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[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[reply]
    • Zotero will also auto-retrieve and format metadata like title, authors, etc.. On-wiki, Citoid does the same. Can you explain how this differs from what you are looking for, Mkouklis(2)? HLHJ (talk) 21:40, 19 December 2020 (UTC)Reply[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[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[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[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[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[reply]
+1 to this! --Slashme (talk) 21:53, 21 November 2020 (UTC)Reply[reply]
  • 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)Reply[reply]
  • FYI The minor checkbox appears in the mobile visual editor. ESanders (WMF) (talk) 17:11, 24 November 2020 (UTC)Reply[reply]

Voting