Community Wishlist Survey 2022/Editing

Editing
34 proposals, 449 contributors, 1215 support votes
The survey has closed. Thanks for your participation :)



Subst templates that should be substed automatically

  • Problem: Currently bots have to subst templates that should be substed after edits are saved. Bots can go offline, and they can be hard to maintain, especially for smaller wikis.
  • Proposed solution: Automatically subst templates that are specified to need substing before saving edits, through some sort of configuration.
  • Who would benefit: Bot operators, editors in general
  • More comments:
  • Phabricator tickets:
  • Proposer: EpicPupper (talk) 03:30, 23 January 2022 (UTC)

Discussion

  • Regarding a potential NOSUBST option, substituting can always be helpful for test edits, to be able to see what a template actually outputs. Even if you're not supposed to substitute a template normally. Jochem van Hees (talk) 15:36, 6 February 2022 (UTC)
    Not sure if @Izno was referring to "NOSUBST" as a "never substitute this template" option (in complement to this proposal) or "do not subst in this case" (in complement to the "subst:" syntax). ~~~~
    User:1234qwer1234qwer4 (talk)
    18:52, 8 February 2022 (UTC)
    No, it would be a "never subst" option.
    As for a sandbox, a sandbox can also have that removed. :) Izno (talk) 19:36, 8 February 2022 (UTC)
    As for the opt-outs requested below, I'm not sure what that implies but I think it's "I'm adding this template here but I don't want to subst it", which would indeed be some sort of {{nosubst: syntax I guess. I don't have an issue with that. Izno (talk) 19:38, 8 February 2022 (UTC)

Voting

VisualEditor should use human-like names for references

  • Problem: When a reference is used multiple times in the VisualEditor, it is given a numeric name like :0, :1, etc. This makes it hard for those who do source editing to reuse the reference, because you have to remember the number instead of something more specific like the name of the publication. It would be better if VisualEditor used citation metadata to give the references more human-like names.
  • Proposed solution: The original idea was to be able to change the names of references, and to do away with the numeric IDs altogether. However due to how the VisualEditor data model works, it is difficult to give the references non-numeric names, or to change them at all. While it's possible to name references when they are first added, there is concern this optional field will go unused or confuse new users.

    Following the discussion below, the idea is to compromise by using citation metadata (when available) to make the reference names more memorable, but potentially still retaining the IDs. For citations with websites, we would include the domain name and a number. For example, a reference from the Guardian website (www.guardian.com), may be "guardian-0" or "guardian-1." For citations that do not have a website, we could potentially also include some automatically generated names based on the author or book title, such as "adamslaura-0." So you still wouldn't be able to change the name of any references in VE, but the automated names would be more readable.

  • Who would benefit: Those who do source editing.
  • More comments: This is a counter-proposal to the 2019 wish, which had to be declined due to technical complexity.
  • Phabricator tickets: task T92432
  • Proposer: AleatoryPonderings (talk) 01:43, 11 January 2022 (UTC)

Discussion

Whilst Visual Editor's Re-use tab displays an existing RefName field (grey text at the right), it is impossible for users to manually add one in VE. (This has to be done by switching to Source Editor and changing it, and then switching back to VE to re-use it)
  • Yes, those autogenerated ref names are horrible. · · · Peter (Southwood) (talk): 08:38, 11 January 2022 (UTC)
  • This would be great! --Omnilaika02 (talk) 08:55, 11 January 2022 (UTC)
  • This is desperately needed. To be training people to edit with VE and then to have to tell them to switch to Source Editor just to add an essential field is plain ridiculous. You get offered over 160 additional optional fields you can add with VE’s Cite tool, but not REF NAME. Crazy. I've added an image to show the issue. I would suggest the 'benefits' section could be expanded to include all users of WP:Source Editor, especially those working on any article where a citation needs to be re-used. I've added an image to help support this proposal. Nick Moyes (talk) 09:56, 11 January 2022 (UTC)
  • This would be great, but better still: have an automated name that relates to the cite: last1 + year, for instance. Only if there is insufficient information, would it resort to numerical names. Femke (talk) 11:45, 11 January 2022 (UTC)
  • Yes! This is needed for using visual editor with "advanced" references (on enwiki, sfn and harv). Also would be amazing if the default names could be better than just ":1". --JackFromWisconsin (talk) 14:08, 11 January 2022 (UTC)
  • Yes, and like Jack above, I'd also like to see smarter naming than just ":0", ":1", etc. "Author_Date", for example, with "Author" falling back to "publisher", "work", the root domain name from the URL, or even the first non-article word of the title if the appropriate fields aren't present, and date falling back to the access-date or date the citation was added. Ahecht (TALK
    PAGE
    ) 15:33, 11 January 2022 (UTC)
  • @AleatoryPonderings: This was a top proposal in the 2019 survey. Unfortunately after talking with the Editing team and a thorough technical investigation, we concluded it's just not feasible to allow changing to any arbitrary name. However, there is an alternative, that if you're okay with, we should most certainly vote on this year. You can read the details at Community Wishlist_Survey 2019/Status report 1#Named References in VE, but to summarize here: Our counter-proposal is that, rather than such references only including a number and colon (such as “0:”), we provide an improvement to the existing format. For citations with websites, we would include the domain name and a number. For example, a reference from the Guardian website (www.guardian.com), may be “guardian-0” or “guardian-1.” For citations that do not have a website, we could potentially also include some automatically generated names based on the author or book title, such as “adamslaura-0.” So you still wouldn't be able to change the name of any references in VE, but the automated names would be a little more readable. Would this work for you? If so, would you mind adjusting the proposal to say this? We can help you too, if you'd like :) Thanks, MusikAnimal (WMF) (talk) 17:50, 11 January 2022 (UTC)
    @MusikAnimal (WMF): Thanks for your note. Two thoughts. And please bear in mind that I have no technical expertise whatsoever. I'm just speaking from experience editing, mainly on enwiki.
    1. In my experience, the annoying colon+number ref names only come up when you try to copy and paste a reference in VE. (A great feature, btw, and one I use all the time.) Would it be possible to change VE so that when a user tries to copy-paste a reference, they are asked to include a descriptive name for it—sort of like when you try to upload an image to Commons with a name that just has an unparseable set of characters? One failure mode here would be that the editor tries to use a name that is already "taken" (for instance, if it uses the same author-year combo as another reference, such that the CITEREF link would be the same). Then VE could tell the editor that they have to pick a different name. (My sense is that the architecture for this is already built in—since when any pages with cite errors render in enwiki, they tell the user there is a cite error that needs to be fixed.) I guess I'm just confused as to why you can name refs whatever you want in source mode but not in VE.
    2. If (1) is not possible, the alternative proposal at Community_Wishlist_Survey_2019/Status_report_1#Named_References_in_VE would certainly work better than the status quo. Could you and your colleagues update that, if necessary, and add as an alternative to this proposal? I would then strike my original proposal in favour of yours; I'd just rather you write it instead of me, since you have way more knowledge about what's feasible than I have.
    Basically, any change to the status quo of colon plus number would be good. One last thing: I and many users to use "advanced" ref formats, like en:Template:Sfn (which JackFromWisconsin mentioned), which are mainly for sources in print that do not have URLs. If you do end up changing VE to allow some form of renaming ref tags, it would really be helpful if it did not interfere with templates like these. AleatoryPonderings (talk) 18:42, 11 January 2022 (UTC)
    @AleatoryPonderings I'm going by memory from the meeting with the Editing team, so bear that in mind; As I understand it, the data model behind VisualEditor basically applies an ID to each reference. Templates like {{cite web}} are so common that support for them is built right into VE, hence we can leverage fields like author and the URL to "combine" with the ID of the reference. So instead of having ":1" you have "guardian-1"; in both cases it's still the ID of 1. If you were to introduce a new Guardian reference, the system would simply choose "guardian-2", etc., so there's no concern of using a name that's already taken. I do also seem to recall that it is feasible to add a completely custom name for a reference (no number at all), but only when you first add it. The reason they haven't implemented this is because of usability. "Naming references" is a concept that only makes sense in source editing. As a new user editing visually, you would probably be confused by a field that asked you to name the reference. I think from a product standpoint, it's more ideal to not have to worry about that because it doesn't make any difference at all visually. But if we make the automatic names more readable (like "guardian-1"), then it at least benefits those who do source editing. The problem comes when you want to change the name of a reference; from my understanding the VE data model apparently doesn't work well for that (but it's not easy in source editing either -- you'd have to change the name in every instance the reference is used).
    TL;DR: (1) We'd change VE to use citation metadata to make the automated reference names more human-readable, (2) we probably won't offer a way to add a custom name when adding a new reference, for newbie's sake, and (3) changing the names of references won't be supported.
    @ESanders (WMF): Would you mind reviewing what I've said here for accuracy?
    Once we get the go-ahead from Editing on what will work, I'd be more than happy to revise your proposal for you, and together we'll make sure it both satisfies your wish and is something we will be able to deliver on. Best, MusikAnimal (WMF) (talk) 19:33, 11 January 2022 (UTC)
@MusikAnimal (WMF) and AleatoryPonderings: May I chip in with a few observations?
  1. MA: you said "Naming references" is a concept that only makes sense in source editing. I cannot accept that statement at all; just look at the screenshot I added. On the right hand side it displays two simple reference names that, of current necessity, had to be added via Source Editor, even though the citations were created with VE. Those names ("Qui" & "Richalet") stand out, are easy to see, and make perfect sense to the person who found and planned to reuse them. They are, quite simply, a memorable word to refind and reuse a citation. Of the 25 sources I used in one biography, I ended up with 12 really good ones which I felt I might re-use, so I ref-named just those twelve. Let me, as a VE user, allocate a memorable name to a reference on its first use and I will be happy. I can scroll down to very quickly find the ones I had named. I would not expect to be able to go back and allocate a different name to those citations -that's far too specialised a need. If you're telling me that allowing the allocation of a useful short name to a citation at the time of entry is not relevant, or of no use to VE users, I must strongly disagree with you (and an email I had today with a WMF(UK) 'Train the Trainers' staff member on teaching VE would lend support to that). So, when you say "As a new user editing visually, you would probably be confused by a field that asked you to name the reference" I would reject totally. It's an option to enter a common-sense field that we're seeking, and I would certainly love to be able to include it in the training that I give to new users. After all, what is there in "give your citation an easy-to-remember name" that they wouldn't understand if they planned to use a source more than once?
  2. Automatic number allocation only appears to happen if an attempt is made to re-use a reference. Sources used only once don't seem to be automatically allocated any 'ref name' as far as I can tell from my VE edits at this draft article.
  3. An option to manually allocate a memorable 'ref name' at the time of citation creation (or even prior to second use) is logical and should not be that difficult to implement.
  4. This proposal's wording is unfortunately overly-demanding, and the Phabricator technical discussion you refer to was completely flawed because it focused only on changing/updating an already-allocated name or number. This seems to miss the key desideratum of being able to allocate a memorable 'ref name' on first entry of a citation. I see no consideration or explanation as to why that is not feasible. Is it simply unfortunate wording that has caused this confusion?
  5. Updating an already-allocated refname for citations used more than once would be a ridiculous demand for us to make if it has already been deployed more than once in an article. If necessary, changes could then be done with find/replace in Source Editor if an advanced editor really needed to. Simply adding a refname on first use seems to be the key point to make here; I fear however that this point has been misunderstood for the last few years.
If all the above are still rejected on technical grounds - and I see no reason why a 'on first use' naming function should be "out of scope" - I would then fall back on fully supporting the proposed solution from the 2019 WishList for automatic ref name generation that a human might understand if no other refname has been manually allocated in Source Editor.
No solution in VE should ever be permitted to overwrite a refname already allocated by someone who has used Source Editor to give a meaningful and memorable name to a citation. And VE should continue to display all manually-entered Ref name fields as it does at present, per the screenshot above. Nick Moyes (talk) 01:39, 12 January 2022 (UTC)
"Simply adding a refname on first use seems to be the key point to make here"
Getting new users to fill out a refname for a purpose they don't understand, and a use case that may never occur (the majority of references are never re-used) certainly adds confusion and complexity to the workflow. If this field is optional (as it probably should be) then many users will simply not use it, and there are also millions of existing references out there than don't have names.
Auto-generating better names would solve the ':0' problem immediately (at least for all future references).
"Would it be possible to change VE so that when a user tries to copy-paste a reference"
This would get very messy if large blocks of text were copied containing multiple references. ESanders (WMF) (talk) 01:52, 12 January 2022 (UTC)
@ESanders (WMF) Thanks for taking the trouble to read through the various observations. Regarding first use: I was not suggesting for one moment that Refname must be filled in every time. I, along with many other active editors, simply think it should be offered as an option to fill in within the citation template, and would like any user of Visual Editor, new or experienced, to have the opportunity to add one via the template at the time they create the citation.
There seemed to be confusion here that we need to be able to change a refname word by re-editing the template. I feel this missed the point entirely (hence my use of the term "first use"). In fact, I think the wording of the proposal should be changed to "Add a one-time Refname in Visual Editor". I would not for one moment expect to be able to come back to the template and change an existing refname, and have those changes cascade down through repeated reuse of my reference. That would be wholly unreasonable and impossible to implement .
I don't know if you've ever written any articles from scratch? But if you have, you'll immediately know if you're sitting in front of a darned good source that you're likely to want to use again and again throughout your article, or merely insert a quick ref to support a minor statement. Giving a really good citation a memorable name isn't something way beyond beginners' abilities, as you seem to be suggesting- it's actually a very valuable means to quickly name, re-find and re-use good content, irrespective of the editing tool being used. We've done it for years in Source Editor citation template windows, and it's a singular weakness of the Visual Editor template that's it's still missing, and it's not one just for advanced users. In fact, I've mentioned the value of allocating a Refname in virtually all the training I've ever given to new users. I currently advise users to always switch to Source Editor to enter references, and point out the value of the Refname field for their subsequent editing. New users become experienced users, so making a mess of citations to start with helps no one.
I see there are well over 100 additional fields that a new user could choose to add via the VE citation templates. I really think refname is one of the most important ones (we see it in every single Source Editor cite template) yet it isn't offered in VE at all. Don't get me wrong: I am impressed with what VE can do; but here I'm focussing on what it still does not do.
Note: When I started to responding to this yesterday, I sensed there were some edit conflicts or updates by @MusikAnimal (WMF), but am returning to posting 'as is', as my time has been limited since. Subsequent note: If you're genuinely telling us that you're team is unable or unwilling to permit manually adding a refname of one's choice the very first time the citation template is filled in (which I still can't appreciate why you can't deliver that) then I would still want to support the lesser solution of automatically generating names that a human can understand. Nick Moyes (talk) 11:00, 13 January 2022 (UTC)
@Nick Moyes Great observations! I admit I did not even realize ref names were listed in the insert citation dialog, though I must have, I guess subconsciously. I personally always use the search bar, since you can put anything you remember in there (author, URL, title, etc.) to find your reference. At any rate, I think automating the naming using both citation metadata and the ID is a nice compromise, and I hope it works for you, too. While not perfect, it makes the lives of source editors easier, and we aren't adding any complexity to the intentionally simplistic design of VE. It'll take time to iron out the logic so that it works well, but I think it can be done :) MusikAnimal (WMF) (talk) 02:48, 12 January 2022 (UTC)
@MusikAnimal (WMF) It's been a while since I thought about the problem in detail, but as a high level summary that is about right. ESanders (WMF) (talk) 01:47, 12 January 2022 (UTC)
@AleatoryPonderings Rather than change your proposal outright, I have added my suggested changes on the talk page. I also want to make sure the above discussion is retained. Please feel free to review my suggestions and copy them over to yours as desired. You can rename your proposal by moving the page, which I'm happy to do for you if you'd like. Regards, MusikAnimal (WMF) (talk) 03:28, 12 January 2022 (UTC)
  • Yes, I think that ref names should be changed in VisualEditor. It has so many limitations now. Thingofme (talk) 12:50, 12 January 2022 (UTC)
  • Please, if it can't be done manually, anything that adds a slightly identifying feature would be a great improvement. Publisher, author, date, random long word from the Oxford dictionary. Anything that makes a citation reusable by a human. Chipmunkdavis (talk) 22:05, 27 January 2022 (UTC)

Voting

Reminders to update other wikipages when updating the current one

  • Problem: Often times, when a change is made to one page, other related ones are forgotten about, leading to inconsistencies between pages.
  • Proposed solution: Don't know. Ideally, there would be a pop-up box that would remind you to edit the other page, giving the relationship and what kind of data needs to be considered for the update. The pop-up should be granular, such that it could apply for either any change on the page, or changes to a specific section. Also, it would be helpful if only users who are logged in were able to set these interdependencies.
  • Who would benefit: Editors would get reminders, allowing them to update the other pages. Additionally, users of Wikipedia will find information across pages to be more consistent.
  • More comments:
  • Phabricator tickets:
  • Proposer: RSStockdale (talk) 22:36, 10 January 2022 (UTC)

Discussion

  • As an example, when a sports competition takes place, there are suddenly dozens of athlete pages which need to be updated with medals and I regularly find athlete pages which don't yet have a particular medal added to their infobox. Perhaps there can be a way to make it clear that a particular page is a sports competition and there'd then be a way to find all athlete pages (linked with templates like {{Flagmedalist}} template on en.wiki) that don't yet have a link back to the sports competition page. This can also be discovered elsewhere using scripts or reports but the idea that the editing software provides tools / automated checks for a page, depending on what it is, might be useful so that it can assist with editing related collections of articles. Simeon (talk) 23:28, 10 January 2022 (UTC)
    @Simeon Going by your example, let's say team Foo wins the international cup. So now you want every member of that team to have a medal on their infobox, right? It would seem this, along with what @RSStockdale is describing could be solved with templates. Often times, when a change is made to one page, other related ones are forgotten about, leading to inconsistencies between pages. This is exactly what templates are for. Going back to the sports example, whatever part of the infobox that shows the medal could for example first check a "winners" template, passing in the subject's name. That template will have a big {{#switch:}} statement that returns a non-blank value if the given name is listed, hence you only need to change the info in one place and the other infoboxes update automatically. This is an oversimplified explanation of how you could solve it (I can go into more detail if you'd like), but the point being you should be able to do what you're after now with templates. Unless I'm missing something?
    The issue is how MediaWiki is supposed to know which pages need to be updated, when they need to be updated, or if they've already been updated. This would be a very challenging problem to solve, so the more examples you can give, the better; but so far in my mind "templates" seems like the best solution, since you – the editing community – get to decide and write the logic yourself for that specific need. I struggle to envision how the "need" for a notification could be automated without some editorial oversight. MusikAnimal (WMF) (talk) 21:19, 18 January 2022 (UTC)
    At the moment, I think both sports competitions and athlete infoboxes can be edited by new and experienced editors alike because it's all just text (so it's {{flagmedalist|[[name of athlete]]|country code}} on the competition page and in an athlete infobox it's something like {{Medal|Gold| [[competition page|<year> <location>]] | name of event }}). If that text-based approach is what the community prefers, then I can imagine the MediaWiki software assisting with that can be useful (so that both new and experienced editors can easily see what medals are missing in infoboxes without setting up externally generated reports etc). For example, there could be a button or UI element that allows one to run a list of (community-defined) checks for the competition page and its related pages (i.e., check for missing medals) and then you'd know that this collection of pages is considered 'consistent' with each other. But, I can also imagine an infobox (sub)template calling Wikidata to request all medals that a particular individual has won and the information is then automatically taken from Wikidata. That would also work, but it'd need to remain easy to edit for both new and experienced editors. So if that approach is implemented in an intuitive way, then I agree there's less of a need to notify editors of what infoboxes are missing medals (as the athlete infoboxes can be made aware of the data that relates to that page). In that case, both the competition page and the infoboxes could pull the medals from Wikidata. I like that approach, but I imagine it to be more work to make it easy to use as opposed to running a query for a collection of related pages (it'd be similar to what PetScan can do, but then when you're on the article page itself). Simeon (talk) 11:51, 19 January 2022 (UTC)
    Wikidata is an even better idea! I know English Wikipedia has reservations against it, but it would seem possible to add the medal to the athletes item on Wikidata, then the Wikipedia templates know to display it. This is definitely easier, scalable and practical than inventing a new configurable reminder system.
    When Community Tech reviews proposals, we look at the problem statement. The problem you describe seems solvable with templates and/or Wikidata. A generic reminder system (which sounds like the Article reminders wish from 2019) is more in-scope, but as we discovered when investigating that wish, time-based Echo notifications is incredibly more complicated and difficult that it would seem (phab:T156808). So unfortunately I'm leaning towards declining this proposal on the basis of existing solutions, and also it re-proposes a wish we declined in the past. However we're happy to let it live in our Larger suggestions category for further discussion. MusikAnimal (WMF) (talk) 23:42, 20 January 2022 (UTC)
  • Another use for this would be redirects, where if the target of one is changed then the target of a similar redirect (e.g. a different capitalisation) should also be changed to match. Thryduulf (talk: meta · en.wp · wikidata) 01:45, 11 January 2022 (UTC)
    There are a lot of uses of this idea. Because every page has linking to other pages, and they all relates to each other. Maybe, we can use Wikidata in articles? See also Wikidata proposal and we can think about this as updating other pages. When a significant prime is discovered, hundreds of page in other language must be updated, also; and updating is a very harsh task. Thingofme (talk) 10:26, 14 January 2022 (UTC)
  • This one honestly looks too vague/big to action practically. What criteria do you propose to establish that something is sufficiently related to some other to-be-edited content? --Izno (talk) 21:30, 18 January 2022 (UTC)
    Initially at least, I would leave it up to the wiki-editors to decide if the pages are sufficiently related. If they find that each time they're modifying one page that they then need to modify one or more others, that's when they'd use this new capability. Editors don't live forever, and what one person watches for today can be easily lost in the future, leading to more and more inaccuracies. RSStockdale (talk) 13:23, 19 January 2022 (UTC)
  • Not fully clear what the goal of this is. Can't editnotices be used to solve this? ~~~~
    User:1234qwer1234qwer4 (talk)
    17:53, 8 February 2022 (UTC)

Voting

  • Support Support Good idea Goodlucksil (talk) 19:10, 28 January 2022 (UTC)
  • Support Support agreed Aboudaqn (talk) 20:36, 28 January 2022 (UTC)
  • Support Support Jim Grisham (talk) 21:51, 28 January 2022 (UTC)
  • Oppose Oppose This is why we have Wikidata. We might as well take the time to build the tools to successfully use Wikidata in an article than waste it on creating a band-aid that still requires manually editing multiple articles. Lectrician1 (talk) 22:40, 28 January 2022 (UTC)
    Yep, I came here to say this too. In several of my articles, I already use en:template:Wikidata to draw information, so that e.g. updating the number of students at a university automatically updates it in the infobox, the body, the university's people list page, and infoboxes in other languages. I'd encourage folks here to support "Tool to add Wikidata to an article" and "Editing Wikidata from Wikipedia", as that's what's needed to get the system more off the ground. {{u|Sdkb}}talk 00:07, 29 January 2022 (UTC)
  • Support Support --Franzekafka (talk) 07:20, 29 January 2022 (UTC)
  • Support Support But using wikidata in articles directly i a great idea too Warmglow (talk) 17:03, 29 January 2022 (UTC)
  • Support Support But like a Wikidata in articles, Wikibooks, Wikiversity, ... We don't have enough contents around it to use more of Wikidata in articles Thingofme (talk) 14:52, 30 January 2022 (UTC)
  • Support Support Helga Wiki (talk) 15:23, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:15, 30 January 2022 (UTC)
  • Doubtful It is doubtful too much of an all-in-one problem solving request. --Havang(nl) (talk) 15:55, 31 January 2022 (UTC)
  • Support Support A good stopgap measure to implement while we get Wikidata to its intended functionality. Daniel Case (talk) 18:15, 31 January 2022 (UTC)
  • Oppose Oppose per Izno and Lectrician1. Silver hr (talk) 20:35, 1 February 2022 (UTC)
  • Support Support KingAntenor (talk) 06:20, 2 February 2022 (UTC)
  • Support Support Sir Proxima Centauri (talk) 09:29, 5 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 05:45, 6 February 2022 (UTC)
  • Oppose Oppose if you really want this functionality then you can get close with an editnotice or even one of the warnings that triggers when you submit an edit and allows you to go through with it by pressing "Publish changes" a second time. However, volunteers should be able to fix one thing without being bound to fix arbitrarily many other things (which they may not have the time or knowledge to do). On the English Wikipedia, unless it is part of completing one action (like starting an ANI discussion requires notifying the user under discussion) there are very few cases where anybody is compelled to do anything, so I would not support this feature being used on en.wiki, even if the Wishlist team were to produce it. — Bilorv (talk) 10:53, 6 February 2022 (UTC)
  • Oppose OpposeDaxServer (t · c) 11:23, 6 February 2022 (UTC)
  • Support Support Dominique.punsola (talk) 11:42, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:34, 6 February 2022 (UTC)
  • Support Support InterstateFive (talk) 20:32, 6 February 2022 (UTC)
  • Support Support Forrestkirby (talk) 15:33, 11 February 2022 (UTC)
  • Support Support AngryBiceps (talk) 15:57, 11 February 2022 (UTC)

List of parameters in modules

  • Problem: Creating an documentation for modules is harder than with templates, because there is no way of getting a list of parameters the module uses. With templates, there are several options, including the templatedata editor and tools. The same does not apply to modules, using those same tools for modules gives no results. This also makes it hard to compare two templates which makes updating templates from another wiki hard.
  • Proposed solution: Make a tool or mediawiki feature, either one works, that allows the user to specify an template and get a list of parameters the module uses back.
  • Who would benefit: Template editors, and once the documentation is created, other editors aswell.
  • More comments:
  • Phabricator tickets:
  • Proposer: Snævar (talk) 17:23, 21 January 2022 (UTC)

Discussion

  • Comment Comment Only 17% of modules on en.wikipedia, for example, have templatedata. VisualEditor and TemplateWizard users that use modules outside of those do not get a list of parameters, as the list does not exist and it is not auto-generated. This is an help template users to help other users type of task.--Snævar (talk) 15:59, 29 January 2022 (UTC)

Voting

Make the article text wrap around the Contents box

  • Problem: There's this huge gap at the top of a wikipedia article that is determined by the size of the Contents Box. On articles with a lot of headings, this can become pretty ludicrous.
  • Proposed solution: I think that the text should wrap around the contents box the way text often wraps around images on other websites. This would be a small adjustment, but it would be a major quality of life boost on larger articles.
  • Who would benefit: All Wiki readers
  • More comments: Hope this isn't in the wrong section, but I couldn't find a 'user interface' or 'visual' one.
  • Phabricator tickets:
  • Proposer: TiggyTheTerrible (talk) 21:02, 20 January 2022 (UTC)

Discussion

  • This should probably be in the "Reading" section. That said, 1) how the table of contents functions will change soon with Desktop Improvements, and 2) your suggestion of having the article text wrap around it seems decidedly like a negative experience with the contents that are usually to the right. In specific articles, even if these weren't true, there are some templates like en:Template:toclimit that can limit the length. I don't think this wish needs work at this time. --Izno (talk) 05:45, 21 January 2022 (UTC)
  • You might rather use TOC right CCS code? — The preceding unsigned comment was added by Geertivp (talk) 16:20, 2 February 2022 (UTC)

Voting

  • Support Support The most impactive way of this is in Wikivoyage, and we should do this in Wikipedia too. Thingofme (talk) 15:07, 30 January 2022 (UTC)
  • Oppose Oppose As noted this is more of a reading issue. However ... in the linked article the solution might be to write a proper full-length intro of some kind (yes, even lists can and should have them), thereby pushing the contents box down somewhat. It's also a unique situation since there's two boxes on the other side. And any text in there would be sandwiched, which is generally avoided in layout both on and offline.

    Now, if we could find a way to make text corresponding to the space taken up by the art on either side left- or right-justify automatically, we might have something to work with IMO. Daniel Case (talk) 18:26, 31 January 2022 (UTC)

  • Oppose Oppose You can just click "hide". Problem solved. KingAntenor (talk) 06:28, 2 February 2022 (UTC)
  • Oppose Oppose It will result in bad page layout. Geert Van Pamel (WMBE) (talk) 16:20, 2 February 2022 (UTC)
  • Support Support I think iterating on the idea and working on a good implementation would be a great improvement. Carlos Pozo (talk) 06:57, 6 February 2022 (UTC)
  • Oppose Oppose Results in bad layout and degraded reading experience — DaxServer (t · c) 11:56, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:27, 6 February 2022 (UTC)

Average edits per day in CentralAuth

  • Problem: Because different users are active for a different amount of time, it’s sometime hard to estimate which users are more active purely based on the amount of edits.
  • Proposed solution: There will be a new line in Special:CentralAuth called average edits per day. It will take the number of edits done globally and divide it by the number of days the user was active. This doesn’t mean the amount of days that passed from the day the user created his account until today, but the amount of days that passed from his first edit till his last one. Also, there will be another line telling the average amount of edits done in the last year/month/6 months.
  • Who would benefit: Everyone who uses Special:CentralAuth for statistics.
  • More comments:
  • Phabricator tickets:
  • Proposer: Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 10:03, 22 January 2022 (UTC)

Discussion

  • Isn't this already available in xTools, e.g. here? {{u|Sdkb}}talk 23:55, 28 January 2022 (UTC)

Voting

  • Oppose Oppose XTools already have this tools, but it's in the Opting in for restricted statistics section, and sometimes we can't view it. Thingofme (talk) 15:05, 30 January 2022 (UTC)
  • Oppose Oppose Per Sdkb, already provided by XTools. --Liuxinyu970226 (talk) 03:52, 6 February 2022 (UTC)
  • Oppose OpposeDaxServer (t · c) 12:48, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:44, 6 February 2022 (UTC)

Add a notification number next to the talk page tab if there are recent discussions

  • Problem: When I try to add sources and improve an article, I either, often forget to check if there were any recent discussions in the article page, or I click in the talk page for nothing as there is no discussion (which does not lead me to check it next time)!
  • Proposed solution: Add a notification number next to the talk page tab if there are recent discussions during the last (90?)x days.
  • Who would benefit: Everyone.
  • More comments: note: I see a problem with this proposal as some users will prefer just to discuss and forget to add content to the article!
  • Phabricator tickets:
  • Proposer: Jurbop (talk) 07:50, 23 January 2022 (UTC)

Discussion

@Jurbop: you raising the prospect of surfacing the level of activity on a talk page within the "article header" comes at an opportune time. Reason being: the Wikimedia Foundation's Web Team is currently exploring ideas that would do just as you're describing. I'm pinging @AHollender (WMF): in case he has more context to share about the work the Web Team is doing in this area.

Also, in case you're curious about improvements to talk pages themselves, the Editing Team is in the midst of making a series of improvements to make it easier for people to recognize and use talk pages as places to communicate with volunteers about improving the wiki's content. PPelberg (WMF) (talk) 23:30, 27 January 2022 (UTC)

Hello @PPelberg (WMF), many thanks. I didn't know that! Jurbop (talk) 19:28, 28 January 2022 (UTC)
I'm glad to know you found this information useful ^ _ ^ PPelberg (WMF) (talk) 19:30, 28 January 2022 (UTC)
  • I think this would be more useful if it were made specific to the user. As in, when visiting a particular article, each user sees how many messages were added/edits were made to that article's talk page since their last visit to the talk page (or, if that's too resource demanding, a simple boolean indicating whether there were any messages/edits). Silver hr (talk) 20:10, 1 February 2022 (UTC)
  • There's one user script that can do one part of what's described here: en:User:Enterprisey/talk-tab-count. It shows the number of discussion next to the talk page link (though it doesn't distinguish between new and old ones). Uanfala (talk) 12:45, 7 February 2022 (UTC)
    Indeed the proposal reminded me of this script, though I'm not quite sure how the proposer imagined the "notification" number. ~~~~
    User:1234qwer1234qwer4 (talk)
    18:00, 8 February 2022 (UTC)

Voting

Suggested Edits Implemented on Web

  • Problem: The "suggested edit" tab is useful on mobile of Wikipedia, but it would also be incredibly useful on the web version.
  • Proposed solution: Add a "suggested edit" area into the web version, perhaps in the contributions page or something like that. More things could be added as well, such as CS1 errors in citations.
  • Who would benefit: Mostly "Gnomes" who spend a lot of time adding captions and title descriptions.
  • More comments: This does exist on the web version, but it is made specifically for newcomers, along with the fact that it has the "newcomer tag" when you look at the edit. I do believe that this should be implemented for long-time users as well who don't want to browse until they find a random problem. I think that this would further encourage and promote things like fixing CS1 errors, fixing articles that have multiple issues, etc. if it is a visible and easy-to-find section in Wikipedia.
  • Phabricator tickets:
  • Proposer: MrMeAndMrMe (Talk) 12:42, 11 January 2022 (UTC)

Discussion

  • Newcomers do get suggested edits as part of mw:Growth/Personalized first day/Structured tasks (under development). It would be possible to piggyback on that and just make it available for established users as well.--Snævar (talk) 04:48, 11 January 2022 (UTC)
    I think we should see the suggested edits for more established users to be able to implement faster copyediting problems. But they are "designed" for beginners. Thingofme (talk) 11:48, 13 January 2022 (UTC)
  • Be careful that what is suggested does not encourage stupid edits. · · · Peter (Southwood) (talk): 07:04, 11 January 2022 (UTC)
  • This is already implemented with the Home Page. The home page can be enabled in the preferences panel. --JackFromWisconsin (talk) 14:06, 11 January 2022 (UTC)
    Yes, but as Snævar mentioned, it would be nice to make it available for newer editors as well as established editors. MrMeAndMrMeContributions 17:28, 11 January 2022 (UTC)
    Newer editors are allready getting thoose suggested edits. They just need to finish testing first.--Snævar (talk) 18:20, 11 January 2022 (UTC)
    MrMeAndMrMe, established editors can opt-in on those from the preferences. While I don't know the option name in English, it ahould be something along the lines of "Show homepage". You can then click on your username and instead of your user page, you'll be redirected to the page that newbies see. Strainu (talk) 06:00, 12 January 2022 (UTC)
    Not everyone wants to show homepage, as the homepage is like for the newcomers. Some experienced users think they are experienced and not very new anymore. Thingofme (talk) 10:29, 15 January 2022 (UTC)

Voting

  • Support Support - As proposer MrMeAndMrMeLet's talk 19:09, 28 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:26, 29 January 2022 (UTC)
  • Support Support Thingofme (talk) 15:04, 30 January 2022 (UTC)
  • Support Support Exilexi (talk) 18:20, 5 February 2022 (UTC)
  • Support Support Nkon21 (talk) 03:29, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 05:47, 6 February 2022 (UTC)
  • Oppose Oppose Experienced editors are expected to know what they are doing. The Suggested Edits feature helps newcomers; since editing on mobile app is still in its novice form, it could be helpful. If this wish is implemented, please disable it by default. — DaxServer (t · c) 11:49, 6 February 2022 (UTC)
    While this is true, sometimes finding major formatting errors takes a little while for experienced people. Disabling it by default also defeats the purpose of it; to make people look at that general area more and maybe contribute in a faster way.
    It isn't a required feature and disabling isn't difficult.
    Mobile does the same thing, there is not really any reason why this shouldn't be implemented on web. MrMeAndMrMeLet's talk 14:27, 7 February 2022 (UTC)
    I think you were trying to say "...why this shouldn't be implemented". ~~~~
    User:1234qwer1234qwer4 (talk)
    17:56, 8 February 2022 (UTC)
    Yes, thanks. MrMeAndMrMeLet's talk 14:10, 9 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:36, 6 February 2022 (UTC)
  • Support Support Worldbruce (talk) 15:59, 8 February 2022 (UTC)

Find redirects in navbox templates tool/function

  • Problem: If an article link in a navbox template is a redirect its text will not auto-bolden in the target article. Incomplete page moves leave navbox redirects behind. The navigation pop ups gadget does identify redirects when mouse hovering over them individually but it's a slow process with large navboxes.
  • Proposed solution: Develop a tool or gadget to identify and list all the redirects in a particular navbox template (and article pages?), a reversed version of 'what links here' seen in the left side bar.
  • Who would benefit: Wikipedia readers, they will see bolded alternate names in a navbox once they have been corrected (aircraft types often have a manufacturer's designation, a name and/or a military designation and name so they generally appear three times in a navbox).
  • More comments:
  • Phabricator tickets:
  • Proposer: Nimbus227 (talk) 12:04, 23 January 2022 (UTC)

Discussion

  • All this takes is a little snippet of CSS in your user CSS: .navbox .mw-redirect { font-style: italic; color: red; }. Style to your preference. --Izno (talk) 20:46, 24 January 2022 (UTC)
    Maybe this task should be called "make a gadget to turn redirects green". Jonesey95 (talk) 22:23, 28 January 2022 (UTC)
  • Does this refer specifically to redirects to the page itself, e.g. if article "Color" contains a navbox which lists "Colour" (a redirect to Color)? If so then I support replacing that self-link by bolded text, which would be difficult to do in CSS without changing all other redirects. Certes (talk) 01:03, 29 January 2022 (UTC)
  • Actually, while we currently still have this convention to not use redirects in navboxes, I think that it was a bad community decision to have this rule, as there are often very good reasons to deliberately link through redirects (and this does not stop at navboxes).
I'm not against bolding the text (although I consider it of cosmetical benefit only) and disabling circular links in a navbox if it would point (back) to the current page, but I'm against the suggestion to not use redirects, because not using redirects in navboxes clutters up "What links here", complicates reverse-lookup of specific (sub-)topics and makes it more difficult to (re)organize contents. I haven't investigated this further so far, but it should be technically possible to still achieve the former but without the latter (so that we basically get the best of both worlds) through the use of some kind of special *{{navbox-link|link|label}} template (where link could also be a redirect) instead of having to use direct (or piped) links *[[link|label]] in navboxes. Might be worth investigating this.
But even if it would not be possible I consider a circular link in a navbox an almost neclectable issue compared to the significant pollution of "What links here" (to the point that it is often not reasonably usable any more) and not to be able to take full advantage of redirects caused by the current way of doing things.
--Matthiaspaul (talk) 14:29, 29 January 2022 (UTC)
To be clear about it, I think we should make it a rule that all links from navboxes should go through redirects instead of pointing to articles directly, possibly even through a dedicated redirect featuring a " (navigation)" disambiguator in its name (similar to how we route all links from identifiers through special " (identifier)" redirects), so that links from navboxes are easy to identify in "What links here" and can be specifically muted or selected. And, if technically possible, achieve the (non-essential) bolding and circular link suppression by other means. --Matthiaspaul (talk) 14:46, 29 January 2022 (UTC)
  • I use en:User:BrandonXLF/NoRedirect.js and I can spot redirects easily with a little arrow next to them. I've fixed a navbox maybe twice now? Just that I've stumbled across I haven't looked for ones to fix so I don't know how much of a problem this is. IAmChaos (talk) 18:06, 31 January 2022 (UTC)
    There are definitely quite a few. It's quite easy to fix such links with navigation popups. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:49, 8 February 2022 (UTC)

Voting

Ability to append additional edit summaries to one’s own edits

  • Problem: Currently, once you write your edit summary and push the "Publish changes" button, you can't make changes to your edit summary. But what happens if you forget to mention something important? What happens if you make a typo (this one is meant for the typo police like me)? You're stuck with that edit summary for eternity.
  • Proposed solution: I suggest that we give editors the ability to append additional edit summaries to their edits— not other people’s, only their own. This would be a lifesaver for editors who forget something important in their edit summary (e.g. attribution) or who make typos-- if you're anything like me, you know how painful typos are. Now, to address the word 'almost' in the previous section, I don't think we should make this feature available to just anybody. As someone who mainly does counter-vandalism, I know that there is the potential of vandals abusing this feature. To address this, we would make the feature available only to those who are auto-confirmed and higher. This could be a tool that users enable/disable in their Preferences.
  • Who would benefit: Almost every editor-- more on the 'almost' in the next section.
  • More comments:
  • Phabricator tickets: phab:T15937, phab:T210327
  • Proposer: HelenDegenerate (talk) 18:22, 15 January 2022 (UTC)

Discussion

  • A related and very frequent situation is forgetting to write an edit summary. For such cases, a more or less established convention is doing an "empty edit" with just the edit summary. One way to implement the suggested feature would be to take advantage of this existing convention and have empty edits modify the summary of the previous edit (assuming the edit is yours, of course). Another approach, perhaps more modern and intuitive, would be to have some sort of [edit summary] button next to your latest edit, that would open a dialog similar to the [thank] button. Sophivorus (talk) 00:51, 16 January 2022 (UTC)
  • I think this mean log of editing note changes being needed to avoid dispute. And I don't think log of changes in log is something productivity, even though I see the use case here. C933103 (talk) 06:51, 16 January 2022 (UTC)
  • This is already proposed in 2015.--GZWDer (talk) 19:09, 16 January 2022 (UTC)
  • Hello there, and thanks for taking the time to write this proposal. We've discussed as a team and found that the part asking for edit summaries to be editable would be declined for community alignment and perennial reasons, but the part about appending additional summaries could be in scope https://phabricator.wikimedia.org/T210327 Do you mind editing this proposal to be about that part only? If so, this can get accepted for the next phase to be voted on. Thanks so much, NRodriguez (WMF) (talk) 00:39, 18 January 2022 (UTC)
    Yes check.svg Done What do you think? HelenDegenerate (talk) 02:43, 18 January 2022 (UTC)
    Looks great, thank you! MusikAnimal (WMF) (talk) 22:46, 25 January 2022 (UTC)

Voting

  • Support Support Danbloch (talk) 19:17, 28 January 2022 (UTC)
  • Support Support KylieTastic (talk) 19:34, 28 January 2022 (UTC)
  • Support Support Xn00bit (talk) 19:45, 28 January 2022 (UTC)
  • Support Support --YodinT 21:26, 28 January 2022 (UTC)
  • Support Support Lion-hearted85 (talk) 23:12, 28 January 2022 (UTC)
  • Support Support QOL + Fazart (talk) 00:38, 29 January 2022 (UTC)
  • Support Support We can follow up with a dummy edit, but the proposed method is much cleaner. Certes (talk) 00:54, 29 January 2022 (UTC)
  • Support Support Betseg (talk) 02:04, 29 January 2022 (UTC)
  • Support Support, but I also have a concern that it can be misused. Neocorelight (talk) 02:15, 29 January 2022 (UTC)
  • Support Support JopkeB (talk) 05:24, 29 January 2022 (UTC)
  • Support Support Graham11 (talk) 08:35, 29 January 2022 (UTC)
  • Support Support Curios7ty (talk) 09:13, 29 January 2022 (UTC)
  • Strong support Strong support Tranhaian130809 (talk) 11:31, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:08, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:25, 29 January 2022 (UTC)
  • Support Support Nyq (talk) 13:28, 29 January 2022 (UTC)
  • Support SupportBruce1eetalk 13:52, 29 January 2022 (UTC)
  • Support Support NguoiDungKhongDinhDanh 14:12, 29 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 20:23, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 22:16, 29 January 2022 (UTC)
  • Support Support Gusfriend (talk) 00:14, 30 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 07:46, 30 January 2022 (UTC)
  • GA candidate.svg Weak support: I think this could be a nice feature if it was limited to maybe one hour after the edit → «« Man77 »» [de] 13:13, 30 January 2022 (UTC)
  • Support Support Penlite (talk) 14:17, 30 January 2022 (UTC)
  • Support Support Some people should be able to edit the summary and reasons by users and admins, just to fix the broken archive links (talk page) or forget to edit summary. Thingofme (talk) 15:09, 30 January 2022 (UTC)
  • Support Support Geraki TL 15:15, 30 January 2022 (UTC)
  • {{weak support}} only if it’s to append, not to edit existing summaries, and that it will be obvious for the website viewer what was part of the original summary and what wasn’t. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 15:24, 30 January 2022 (UTC)
    • Oppose Oppose per KingAntenor. I think the disadvantages overcome the advantages. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 07:46, 4 February 2022 (UTC)
  • Support Support Titore (talk) 17:39, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:25, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:38, 31 January 2022 (UTC)
  • GA candidate.svg Weak support appending seems maybe useful, but additional edits to the page could add the information needed through additional edit summaries. Dreamy Jazz talk to me | enwiki 14:35, 31 January 2022 (UTC)
  • Support Support Daniel Case (talk) 18:09, 31 January 2022 (UTC)
  • Support Support IOIOI (talk) 20:43, 31 January 2022 (UTC)
  • Support Support Shooterwalker (talk) 22:23, 31 January 2022 (UTC)
  • Support Support Dave Braunschweig (talk) 22:26, 31 January 2022 (UTC)
  • Support Support Thanks, EDG 543 (message me) 14:28, 1 February 2022 (UTC)
  • Support Support Wargo (talk) 21:24, 1 February 2022 (UTC)
  • Oppose Oppose What's next? Edit summaries for edit summaries? I echo Gifnk dlm 2020's comments. KingAntenor (talk) 06:17, 2 February 2022 (UTC)
  • Support Support Downloader2282 (talk) 11:58, 1 February 2022 (UTC)
  • Support Support Nux (talk) 18:07, 2 February 2022 (UTC)
  • Support Support WikiAviator (talk) 10:05, 3 February 2022 (UTC)
  • Support Support Sounds like it would be quite useful! TimTheDragonRider (talk) 12:30, 3 February 2022 (UTC)
  • Support Support β16 - (talk) 10:29, 4 February 2022 (UTC)
  • Support Support Rzuwig 12:05, 4 February 2022 (UTC)
  • Support Support Long overdue. Even experienced users such as myself can make a mistake in an edit summary, perhaps with an incorrect link [1]. My only suggestion would be to put some limit on it, to prevent misuse (e.g. edit summaries can only be changed before there's another edit). Voice of Clam (talk) 15:19, 4 February 2022 (UTC)
  • Support Support Mikhail Ryazanov (talk) 19:58, 4 February 2022 (UTC)
  • Support Support Long overdue. But should be for all wikis, not just wiki.en. - Darwin Ahoy! 01:43, 5 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:30, 5 February 2022 (UTC)
  • Support Support Sashawiki2008 (talk) 16:37, 5 February 2022 (UTC)
  • Support Support Nkon21 (talk) 03:32, 6 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:10, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:15, 6 February 2022 (UTC)
  • Oppose Oppose: complicating the page history interface (whether by viewing these additional summaries or seeing options everywhere to add additional summaries) is a cause of concern for making Wikimedia friendly to new volunteers. There's lots of misuse potential to be thought about, whereas the current dummy edit situation is not that complicated and can cause very few problems. The only genuine substantial use case where there's no alternative is in fixing a typo or link in an edit summary, but this cannot be addressed without causing serious misuse problems (there is no set of editors that can be trusted in altering their edit summaries without record, and "edit summary histories" circles back to my interface complication concerns). If you really mess up on an edit summary (like by accidentally pasting your phone number rather than the text you intended to copy) then you can get it revdelled. — Bilorv (talk) 10:50, 6 February 2022 (UTC)
    Completely agree. Also, I strongly recommend contacting oversight when accidentally disclosing personal information. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:01, 8 February 2022 (UTC)
  • Oppose Oppose Potential misuse and havoc. When someone is investigating something, they are not expected to comeback everytime to see if an user altered the edit summary. This is unfeasible and non-transparent, despite genuine intentions of fixing a typo or adding extra comments. Additional dummy edit, revdel offers effective alternatives and transparency. — DaxServer (t · c) 11:19, 6 February 2022 (UTC)
  • Oppose Oppose --Ciao • Bestoernesto 17:43, 6 February 2022 (UTC)
  • Support Support But maybe it should do it a different way, like being able to edit them, rather than adding on. InterstateFive (talk) 20:38, 6 February 2022 (UTC)
    Have you read NRodriguez's comment above? ~~~~
    User:1234qwer1234qwer4 (talk)
    19:03, 8 February 2022 (UTC)
  • Oppose Oppose coming from a coding background & specifically from what I've learned with commit messages... yes, sometimes there are times you want to change, but I'd rather stick with the integrity of whatever message is left. I'm also worried about the the potential misuse that Bilorv mentions. = paul2520 (talk) 23:28, 6 February 2022 (UTC)
  • Support Support ~Cybularny Speak? 20:24, 7 February 2022 (UTC)
  • Support Support You should be able to amend an edit comment, but not to edit or delete. Revision histories are sacred ground. Bob Stein - VisiBone (talk) 21:00, 7 February 2022 (UTC)
  • Oppose Oppose IMO not important. --Ján Kepler (talk) 19:26, 9 February 2022 (UTC)
  • GA candidate.svg Weak support I like the idea of amending an edit summary ala Git, which is something I've been pondering for a while. I would rather this option be added as a gadget which could be optionally enabled, to address cluttering issues. Also, the original edit summary should always be viewable somehow. Asukite (talk) 20:20, 9 February 2022 (UTC)
  • Support Support I would like to have 5-10 minutes after editing during which I could change the summary. This may not be a change to the already recorded text, but an addition. There are many signs in the summary field, why not add new stacks until the field is exhausted. Sunpriat (talk) 00:52, 11 February 2022 (UTC)
  • Oppose Oppose I think Wikipedia should focus on really important tasks, there is no need to add further complexity for "problems" like this. --Betateschter (talk) 06:57, 11 February 2022 (UTC)

Easy access Templates

  • Problem: Accessing and choosing popular templates takes more clicks than it should.
  • Proposed solution:
    Easy access Templates.png
    Allow users to configure templates they commonly use so that they can be easily selected from the TemplateWizard dialog. Each community could also define their own list of "popular" templates that is shown by default and can be changed on a per-user basis.
  • Who would benefit: Editors who frequently use the same templates
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar.idma (talk) 06:09, 20 January 2022 (UTC)

Discussion

  • This would be difficult because we have no automated means to determine which templates are "popular" for editors. We'd also need to make this configurable per-wiki, since not every wiki has the same templates. MusikAnimal (WMF) (talk) 23:05, 20 January 2022 (UTC)
    Ok. Why not allow the users themselves to add their desired templates. Add a plus button underneath so users can search and implement the templates they want. Would this be less demanding engineering-wise? Omar.idma (talk) 00:25, 22 January 2022 (UTC)
    Yes, allowing you to configure it on a per-user basis may make more sense. We can also allow each community to define their own list of templates. That should be fairly easy to do I think. What we were avoiding was any "automatic" lists of popular templates. I have updated the proposal wording to reflect this, hope that's okay :) Thanks, MusikAnimal (WMF) (talk) 03:46, 25 January 2022 (UTC)
    @MusikAnimal (WMF)@Omar.idma@: Users of any wiki can help categorize these templates manually, although a variable can be defined and added manually for each template, and these variables can be used to categorize templates automatically.
    You can even allow any user to personalize; In any case, this idea will be very useful and practical. Mohammad ebz (talk) 06:44, 24 January 2022 (UTC)

Voting

  • Support Support — Draceane talkcontrib. 20:59, 28 January 2022 (UTC)
  • Support Support Legooverlord11 (talk) 21:40, 28 January 2022 (UTC)
  • Support Support Bertotits23 (talk) 05:05, 29 January 2022 (UTC)
  • Support Support Bilal Hoor (talk) 05:18, 29 January 2022 (UTC)
  • Support Support Mha12213 (talk) 05:42, 29 January 2022 (UTC)
  • Support Support Aca (talk) 12:54, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:15, 29 January 2022 (UTC)
  • Support Support Mohammad ebz (talk) 18:03, 29 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 07:44, 30 January 2022 (UTC)
  • Support Support Thingofme (talk) 14:47, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 22:00, 30 January 2022 (UTC)
  • Support Support BugWarp (talk) 02:53, 31 January 2022 (UTC)
  • Support Support Horza (talk) 10:36, 1 February 2022 (UTC)
  • Support Support Downloader2282 (talk) 12:01, 1 February 2022 (UTC)
  • Support Support Matěj Suchánek (talk) 12:34, 4 February 2022 (UTC)
  • Support Support Xurizuri (talk) 11:05, 5 February 2022 (UTC)
  • Support Support It will be more usefull if you can use it in both Visual and Code editor Thepuglover (talk) 11:16, 5 February 2022 (UTC)
    Are the template invocation dialogues in VE and source that much different? ~~~~
    User:1234qwer1234qwer4 (talk)
    19:14, 8 February 2022 (UTC)
  • Support Support SD hehua (talk) 15:12, 5 February 2022 (UTC)
  • Support Support I would find this very useful, since I use several Infobox templates and WikiProject templates very frequently. G. Moore (talk) 15:18, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:06, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 05:59, 6 February 2022 (UTC)
  • Support Support Carlos Pozo (talk) 07:02, 6 February 2022 (UTC)
  • Support Support something configurable on an individual user or individual wiki basis (the team don't need to go down the road of automatically tracking and suggesting templates that an account frequently uses). — Bilorv (talk) 11:21, 6 February 2022 (UTC)
  • Support Support only for user configurable list, but not a global list — DaxServer (t · c) 12:42, 6 February 2022 (UTC)
  • Support Support Mark D Worthen PsyD (talk) [he/his/him] 22:50, 6 February 2022 (UTC)
  • Support Support Annablazeprobable (talk) 00:45, 7 February 2022 (UTC)
  • Support Support Tom Ja (talk) 18:29, 7 February 2022 (UTC)
  • Support Support I thinks some level of 'often used by u' or 'often used by similar articles' functionality would be very good for most editors. Inspiration can be drawn from wikidata's Recoin. —TheDJ (talkcontribs) 18:36, 7 February 2022 (UTC)
  • Support Support Quiddity (talk) 07:56, 10 February 2022 (UTC)
  • Support Support Sunpriat (talk) 00:14, 11 February 2022 (UTC)
  • Support Support Sebastianleroy (talk) 09:21, 11 February 2022 (UTC)
  • Support Support Lectrician1 (talk) 15:07, 11 February 2022 (UTC)
  • Support Support HBB19 (talk) 15:25, 11 February 2022 (UTC)
  • Support Support Nehaoua (talk) 15:53, 11 February 2022 (UTC)

Better diff handling of paragraph splits

  • Problem: When an editor adds line breaks to split an existing paragraph, our diff viewer depicts the text as deleted and re-added rather than just repurposed. This makes it difficult to see what text changed between the two paragraphs.
  • Proposed solution: Directly compare the text changes between the "deleted" text and the new paragraphs, similar to how this handled moved paragraphs. In other words: diff ranks the line break much too high. It should rank it maybe like white space and rank resynchronization higher. Moreover, the differing characters could be shown more pronouncedly and the numbers of characters and their difference shown very similar to the Revision history.
  • Who would benefit: Editors and diff readers (fairly common type of edit)
  • More comments: This is a perennial request with continued need. It ranked #9 last year (score) and appeared in the 2019 and 2016 (#13) wishlists.
  • Phabricator tickets: task T156439, task T7072
  • Proposer: czar 23:09, 10 January 2022 (UTC)

Discussion

  • Hell, yes! · · · Peter (Southwood) (talk): 08:41, 11 January 2022 (UTC)
  • Yes. Please keep suggesting this until someone acts. Certes (talk) 18:01, 11 January 2022 (UTC)
  • I am wholly in favor of this. HapHaxion (talk) 20:15, 11 January 2022 (UTC)
  • Same to me. — The preceding unsigned comment was added by Nomen4Omen (talk)
  • Same to me, I don't like being removed. Thingofme (talk) 10:26, 14 January 2022 (UTC)
  • If I am reading this correctly, this is the bane of my existence. Or at least related to my bête noire my blank lines vanishing. Kencf0618 (talk) 01:18, 29 January 2022 (UTC)
  • While I often get around this flaw by making line break addition and removal separate from other editing, I could stand to see it handled better. Dhtwiki (talk) 03:15, 29 January 2022 (UTC)
  • Absolutely. Hate seeing this whenever I swap text around, or move it down a few paragraphs - this is a must. Fakescientist8000 (talk) 14:36, 29 January 2022 (UTC)
  • There are tools like en:User:Cacycle/wikEdDiff and de:Benutzer:Schnark/js/diff that handle diffs much better, but as far as I know, they work only on the dedicated diff page, and not in the little pop-up window when you hover over the diff link. Uanfala (talk) 13:03, 7 February 2022 (UTC)
    I think the little popup you are talking about is itself created by a user script/gadget, navigation popups. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:55, 11 February 2022 (UTC)

Community Tech has created a project page

Hello there, we have created a project page for the fulfillment of this wish! Please follow along on our progress, we welcome your feedback. Thank you. NRodriguez (WMF) (talk) 18:46, 14 November 2022 (UTC)

Voting

Native support for alternative section anchors

  • Problem: In order to create shorthand or stable links to sections, editors create fragment IDs (aka anchors) that point to sections that differ from the visible headings. This can be done using {{anchor}}, as in == {{anchor|Anchor}} Heading ==, or its substituted form, == <span id="Anchor"></span> Heading ==, but the first results in bad section links—as in /* {{anchor|Anchor}} Heading */, which shows up as →{{anchor|Anchor}} Heading—while the second is less self-evident as to what it's for, especially to newcomers. Another solution is to put the {{anchor}} or <span>...</span> at the end of the previous section, but this doesn't show up when editing the section (and shows up at the end when editing the previous), which is quite confusing.
  • Proposed solution: We need a way to add fragment IDs inside section headings that 1) communicates clearly what it's doing and 2) doesn't affect section links. E.g. a parser function like {{#sectionanchor:Anchor name}} that can be used anywhere inside a section and results in <span id="Anchor_name"></span> prepended at the top of (or inserted before) the nearest Hn element before the function call.
  • Who would benefit: Editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Nardog (talk) 07:00, 21 January 2022 (UTC)

Discussion

  • This is something that'd definitely be nice, but I'm not sure it rises to the level of importance for me to give it a support. If something was done, perhaps the software could just take templated anchors in section headers and not display them in edit summaries. {{u|Sdkb}}talk 23:53, 28 January 2022 (UTC)
  • If stable section fragment IDs are needed, the software should just create them automatically, without any user involvement. Also, the rendered page should have links to them, so the links can be easily copied. Silver hr (talk) 19:49, 1 February 2022 (UTC)
    Putting anchors heading is common after renaming a section, but still wanting old links to go to the section. Jochem van Hees (talk) 17:22, 3 February 2022 (UTC)

Voting

  • Support Support OwenBlacker (Talk) 22:24, 29 January 2022 (UTC)
  • Support Support Thingofme (talk) 15:35, 30 January 2022 (UTC)
  • Support Support Anchors currently look really bad in headings Jochem van Hees (talk) 17:21, 3 February 2022 (UTC)
  • Support Support Ynhockey (talk) 01:08, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:43, 6 February 2022 (UTC)
  • Support Support I like the idea; I feel like more examples could be given in the proposal, though, such as an example of what such a link would look like vs. how a section title might change. paul2520 (talk) 23:31, 6 February 2022 (UTC)
  • Support Support Uanfala (talk) 12:38, 7 February 2022 (UTC)
  • Support Support Would be very useful in translatable text where we use {{anchor}} a lot Quiddity (talk) 07:53, 10 February 2022 (UTC)
  • Support Support Gaurav (talk) 06:21, 11 February 2022 (UTC)

Add a modality to keep contested images of commons on Wikipedia

  • Problem: Sometimes, like it happened to me at Abdürrezzak Bedir Khan an image is nominated for deletion and deleted by a bot.
  • Proposed solution: Anyone who contests the deletion reasonably, can ask an admin or a file mover to start a bot which automatically loads it up to the wikipedia project in which the image is needed but deletes the contested image from wikipedia commons.
  • Who would benefit: All editors who contest a deletion of an image on commons with a reasonable argument.
  • More comments: A good example is also The Burning Giraffe of Salvador Dali. My image was deleted from commons but an image is still included as an image of Wikipedia. I wouldn't know how to upload an image correctly to Wikipedia. Something like a Schlurcherbot for migrating images from Commons to Wikipedias would be great.
  • Phabricator tickets:
  • Proposer: Paradise Chronicle (talk) 21:13, 20 January 2022 (UTC)

Discussion

  • I have thought about this problem but generally I side on the "someone will correct the issue at some point if an appropriate file is available". Maybe a bot to notify local talk pages that an image has been deleted (even if for some reason the edit removing the image is insufficient). --Izno (talk) 05:42, 21 January 2022 (UTC)
    I thought there was a bot for this already (at least on enwiki)? ~~~~
    User:1234qwer1234qwer4 (talk)
    18:02, 8 February 2022 (UTC)
  • This would only be useful for images that would fall under fair-use on Wikipedia, wouldn't it? Because other deletions would be valid and the image should not be allowed to be used on other wikis. Also, don't fair-use images also usually have to be reduced in size (or modified in other ways) to make them eligible for being uploaded to Wikipedia? That would make it hard to have a simple trans-wiki copying system. Note also that the Commons deletion notification bot already notifies talk pages of articles using images that are to be deleted. Anyway, this proposal can definitely proceed to voting, but I just wanted to check that you're happy that it won't run afoul of wiki policies? — SWilson (WMF) (talk) 02:41, 25 January 2022 (UTC)

Voting

  • Support Support For what it's worth, there was once a bot doing this, but it's operator was WMF global banned and no one else took on the task. * Pppery * it has begun 18:40, 28 January 2022 (UTC)
  • Support Support THainaut (talk) 11:03, 29 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 23:13, 29 January 2022 (UTC)
  • Support Support ok Thingofme (talk) 15:17, 30 January 2022 (UTC)
  • Support Support KingAntenor (talk) 06:22, 2 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 21:32, 4 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:13, 6 February 2022 (UTC)
  • Oppose Oppose: we cannot automatically determine whether a file that has been deleted on Commons for some reasons still falls within, for example, en.wiki scope. It would be very bad to see easily ported attack images, images without sufficient copyright information for our non-free content criteria, or out of scope images. This affects legal issues as egregious cases could even fall afoul of fair use or piracy law (e.g. a film uploaded as a video). So this tool would have to be restricted to experienced users, who can be trusted to actually check that the image is appropriate for the wiki they want to use the image on, but by that point there is little use case as experienced users should (a) not often have images deleted on Commons and (b) be able to reupload the image without too much trouble. — Bilorv (talk) 10:58, 6 February 2022 (UTC)
  • Oppose Oppose Better not to tinker with copyright matters. If something belongs somewhere else, the user could be instructed to do so. If the user is unaware of how to achieve that, they can ask for help. — DaxServer (t · c) 11:44, 6 February 2022 (UTC)
    Like how? This one didn't work out so far How else should I word my request? Request is still pending... Paradise Chronicle (talk) 00:50, 10 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:44, 6 February 2022 (UTC)

More keyboard shortcuts when editing -- for faster work

  • Problem: We could edit faster with more keyboard shortcuts. That's especially true for items that require multiple clicks to pull up in the VisualEditor, especially adding a Template or adding special characters or the References section on the bottom. For comparison, we can already add a citation with Ctrl+Shift+K
  • Proposed solution: More shortcuts like Ctrl+Shift+K for items in the VisualEditor or code editor menus. Stretch solution #1: make those shortcuts customizable (like this); Stretch solution #2: assign keyboard shortcuts for inserting specific special characters, e.g., „these open-close quotes“
  • Who would benefit: Frequent editors and new editors who are used to shortcuts in their other authoring tools (e.g., Microsoft Word, Excel, PowerPoint), and thus would decrease the risk of dropping off as Wikipedia editors
  • More comments: Not sure if the VisualEditor documentation is up to date: en:Wikipedia:VisualEditor/Keyboard_shortcuts
  • Phabricator tickets:
  • Proposer: Cryout (talk) 22:04, 13 January 2022 (UTC)

Discussion

  • Keyboard shortcuts that don't conflict with the OS/browser, and that work on all keyboard layouts, are hard to come by. Searching for shortcuts may be helpful too: T66905 ESanders (WMF) (talk) 23:12, 25 January 2022 (UTC)

Voting

  • Support Support DonBarredora (talk) 00:40, 29 January 2022 (UTC)
  • Support Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:23, 29 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 05:20, 29 January 2022 (UTC)
  • Support Support ESanders (WMF) Can you give users the opportunity to choose what and on which buttons to put? --Флаттершай (talk) 06:59, 29 January 2022 (UTC)
  • Support Support More keyboard shortcuts --> more useful.Tranhaian130809 (talk) 11:34, 29 January 2022 (UTC)
  • Support Support Aca (talk) 12:53, 29 January 2022 (UTC)
  • Support Support Nyq (talk) 13:25, 29 January 2022 (UTC)
  • Support Support This is also an accessibility feature. E.g a missing shortcut for inserting the current date into date fields effectively prevents me from contributing more to Wikidata. Trilemma2 (talk) 14:10, 29 January 2022 (UTC)
  • Support Support Thingofme (talk) 15:19, 30 January 2022 (UTC)
  • Support Support Jmaxx37 (talk) 18:44, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 22:04, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:22, 30 January 2022 (UTC)
  • Support Support Hanumandas (talk) 11:07, 31 January 2022 (UTC)
  • Support Support Browk2512 (talk) 00:52, 2 February 2022 (UTC)
  • Support Support Downloader2282 (talk) 11:53, 1 February 2022 (UTC)
  • Support Support WikiAviator (talk) 10:03, 3 February 2022 (UTC)
  • Support Support Rotavdrag (talk) 11:14, 3 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 13:51, 3 February 2022 (UTC)
  • Support Support Vega (talk) 18:28, 3 February 2022 (UTC)
  • Support Support Alice Redhotroof (talk) 11:18, 4 February 2022 (UTC)
  • Support Support But not limited to the English Wikipedia. - Darwin Ahoy! 21:18, 4 February 2022 (UTC)
  • Support Support More shorcuts -> Faster and better editing. Indeed a very usefull idea. :) Thepuglover (talk) 11:12, 5 February 2022 (UTC)
  • Support Support Exilexi (talk) 18:18, 5 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:22, 6 February 2022 (UTC)
  • Support Support: if the issue is a lack of shortcuts that don't conflict with a user's device or browser, then making additional shortcuts customisable and opt-in would solve the problem. — Bilorv (talk) 11:05, 6 February 2022 (UTC)
  • Support Support Many shortcuts conflict with user's device/browser. Customization [of all] would be beneficial — DaxServer (t · c) 12:02, 6 February 2022 (UTC)
    They're not too hard to customise (see source code of scripts listed at w:Wikipedia:Keyboard shortcuts#User scripts that modify keyboard shortcuts), but a more user-friendly interface would surely be beneficial. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:57, 8 February 2022 (UTC)
  • Support Support paul2520 (talk) 23:21, 6 February 2022 (UTC)
  • Support Support Annablazeprobable (talk) 00:40, 7 February 2022 (UTC)
  • Support Support}. I in particular miss one for inserting current-date DGG (talk) 20:14, 7 February 2022 (UTC)
  • Support Support ~~~~
    User:1234qwer1234qwer4 (talk)
    19:57, 8 February 2022 (UTC)
  • Support Support Ján Kepler (talk) 18:46, 9 February 2022 (UTC)
  • Support Support Nehaoua (talk) 16:09, 11 February 2022 (UTC)

Make the edit request process easier

  • Problem: Currently, it's hard to submit edit requests for protected (semi-protected, fully (admin) protected, etc) pages and pages where users have a COI (conflict of interest). Users often don't know how to use edit request templates, and for large edits, copying over text to talk pages is hard. On the other hand, it can also be difficult to review edit requests. Changes can be hard to implement, especially larger or more complicated ones.
  • Proposed solution: Allow users to propose edits by editing the article as if it were not protected, then instead of saving to the article, it saves the edit request on the talk page. This process should be configurable (which templates to use, etc.) to accommodate the different workflows across wikis. Additionally, the process should be easy and automatic for those submitting requests. To quote MusikAnimal here (in their volunteer capacity), As a good-faith new user, ideally I shouldn't have to learn about edit requests or any internal processes in order to contribute. I should just be bold and edit, inline with the spirit of the wiki.
  • Who would benefit: Users submitting and processing edit requests.
  • More comments: See also related discussion at the English Wikipedia Idea Lab.
  • Phabricator tickets:
  • Proposer: EpicPupper (talk) 00:36, 16 January 2022 (UTC)

Discussion

  • @EpicPupper: Thanks for proposing! I think what you're basically asking is to use FlaggedRevs as a way for a user to submit an edit request. So the edit request still works like it does now, only you get the exact changes since we can generate diff output. Is that correct? Perhaps taking it a step further, we don't use FlaggedRevs at all, and instead the "Edit" button reads "Propose edit", works just like VisualEditor, but "submits" the proposed edit on the talk page, with a message "Your edit request has been submitted." You get the idea. How does that sound? As you say, taking FlaggedRevs out of the picutre is probably good :)

    Finally, I don't think you are, but just in case you are asking for the community to simply use FlaggedRevs instead of semi-protection under certain circumstances, that is something we wouldn't be able to assist with, since this is something only your local wiki can decide on.

    Hope this helps and look forward to hearing your answers! MusikAnimal (WMF) (talk) 04:52, 18 January 2022 (UTC)

    Hi MusikAnimal! Thanks, that's exactly what I meant :) EpicPupper (talk) 20:10, 20 January 2022 (UTC)
    @EpicPupper Great! Would you mind if I reword your proposal a little bit so people better understand what they're voting for? I can more or less guarantee using FlaggedRevs isn't the right solution, and just that name appearing in your proposal could attract opposition since many people have reservations against it, in addition to it being unmaintained in general. I think a better title would be something like "Make the edit request process easier", then your proposed solution could be something like "Allow users to propose edits by editing the article as if it were not protected, then instead of saving to the article, it saves the edit request on the talk page. This process should be configurable (which templates to use, etc.) to accommodate the different workflows across wikis." We're hopefully not underestimating how much work this will be, but I think there's something we will be able to do to help this process. Anyway, your "Problem" statement is crystal clear, so no need to change that unless you want to. I just think it'd be a good idea to get rid of the FlaggedRevs part :) Thanks and let me know if you need help, MusikAnimal (WMF) (talk) 21:42, 25 January 2022 (UTC)
    @MusikAnimal (WMF) sure, thanks for the suggestion! I've moved this page and edited the contents. Is there anything else to do? EpicPupper (talk) 22:36, 25 January 2022 (UTC)
    This looks great, thanks (also *blush* for quoting me from the en:WP:VPIL discussion :) I'll get this proposal marked for translation now. Best, MusikAnimal (WMF) (talk) 23:05, 25 January 2022 (UTC)
  • Ah, where we would be if Flow had come to its end result. --Izno (talk) 21:25, 18 January 2022 (UTC)

+ Wouldn't pending changes cover this? If you can set pending changes for individual protection levels, that is. ScottishFinnishRadish (talk) 00:17, 30 January 2022 (UTC)

In a context sense, sort of, but we couldn't just loop it into that system - as pending changes is deliberately for "low threshold reviews". That is, don't use it if detailed review is to be needed, which probably would be the case for many of the COI use cases. Nosebagbear (talk) 10:17, 31 January 2022 (UTC)
  • Will this not just cause an enormous amount of vandalism and spam on talk pages, on pages that are protected due to frequent abuse? If someone thinks they can edit en:Donald Trump directly and don't realise it's protected then en:Talk:Donald Trump will get an inordinate amount of crap on a daily basis. Pending changes is really good, but sometimes the aim is just to stop wasting volunteer time with floods of garbage. I'm also worried about the potential for deliberate abuse (e.g. off-wiki targeted harassment campaigns), and some issues I won't spell out due to WP:BEANS. — Bilorv (talk) 11:19, 6 February 2022 (UTC)

Voting

  • Support Support See also: en:WP:Workflow improvements. Qwerfjkl (talk) 22:25, 28 January 2022 (UTC)
  • Support Support Ensuring newcomers have a positive experience is nothing less than vital to the continuation of the encyclopedia. This would be a good step toward that. {{u|Sdkb}}talk 22:38, 28 January 2022 (UTC)
  • Support Support Sea Cow (talk) 22:55, 28 January 2022 (UTC)
  • Support Support Izno (talk) 23:06, 28 January 2022 (UTC)
  • Support Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:22, 29 January 2022 (UTC)
  • Support Support Mha12213 (talk) 05:40, 29 January 2022 (UTC)
  • Support Support Aca (talk) 12:59, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:11, 29 January 2022 (UTC)
  • Support Support WhyIsNameSoHardOmg- - (talk) 19:36, 29 January 2022 (UTC)
  • Support Support Encycloon (talk) 22:11, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 22:21, 29 January 2022 (UTC)
  • Support Support What is like pending changes? Semi-protection is hard-core one, but you can have some dumping grounds like template sandboxes. Thingofme (talk) 14:54, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:43, 31 January 2022 (UTC)
  • Support Support Nosebagbear (talk) 10:17, 31 January 2022 (UTC)
  • Support Support Overall, any request that requires to use templates is not easy to use. Trizek from FR 12:08, 31 January 2022 (UTC)
  • Support Support Daniel Case (talk) 18:19, 31 January 2022 (UTC)
  • Support Support MONUMENTA (talk) 00:04, 1 February 2022 (UTC)
  • Support Support Browk2512 (talk) 00:58, 2 February 2022 (UTC)
  • Support Support KingAntenor (talk) 06:18, 2 February 2022 (UTC)
  • Support Support Sabelöga (talk) 16:55, 2 February 2022 (UTC)
  • Support Support YBG (talk) 08:03, 3 February 2022 (UTC)
  • Support Support Jochem van Hees (talk) 17:52, 3 February 2022 (UTC)
  • Support Support DeemDeem52 (talk) 22:31, 4 February 2022 (UTC)
  • Support Support Chrismartin76 (talk) 00:21, 5 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:24, 5 February 2022 (UTC)
  • Support Support Nkon21 (talk) 03:30, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 05:54, 6 February 2022 (UTC)
  • Support Support I think this would make editing more accessible. I agree that good-faith new users shouldn't have to learn all the technical details to be able to submit beneficial edits. paul2520 (talk) 23:41, 6 February 2022 (UTC)
  • Support Support Mohammad ebz (talk) 14:39, 7 February 2022 (UTC)
  • Support Support PtolemyXV (talk) 22:44, 7 February 2022 (UTC)
  • Support Support Worldbruce (talk) 16:06, 8 February 2022 (UTC)
  • Support Support Sunpriat (talk) 00:37, 11 February 2022 (UTC)
  • Support Support DSparrow14 (talk) 17:03, 11 February 2022 (UTC)

Custom edit summaries per user

  • Problem: Reuse of high quality edit summaries is difficult because there is no way to select them again at a later date or to use them across devices. In some cases, the browser shows recent edit summaries but older edit summaries tend to disappear after a while so they have to be written again.
  • Proposed solution: If there was a way to configure, say, a few dozen edit summaries that one commonly uses, it's possible to reuse them whenever a similar edit is made in the future. The edit summaries would belong to the user's account so this allows the software to show them on other devices and improve the quality of edit summaries when making edits on mobile. In user preferences, a text field could be provided and each line could be interpreted as an edit summary. It'd be a place to define these user edit summaries and these are then made available in the editor when filling the edit summary. This could be done using autocomplete or a dropdown or possibly a different solution.
  • Who would benefit: Anyone who wants to provide a detailed edit summary. The benefit of this feature is that you'd only need to write a long detailed edit summary once (possibly with links to relevant policies) and it'd be easy to reuse.
  • More comments: Examples of edit summaries include: "new stub, passes <some policy>, point 3" or "changed formatting of number, see <some policy>".
  • Phabricator tickets:
  • Proposer: Simeon (talk) 18:24, 10 January 2022 (UTC)

Discussion

  • This already exists as a user script on enwikipedia, see w:User:Enterprisey/CustomSummaryPresets. PorkchopGMX (on the go) (talk) 18:47, 10 January 2022 (UTC)
  • I think this may be still be best done via a gadget (enhanced userscript), similar to the example above, it could load from a personal page such as User:Username/myeditsummaries.json perhaps. — xaosflux Talk 19:04, 10 January 2022 (UTC)
  • I think it should be used in a opt-out feature, as block reasons, move reasons, delete reasons and protect reasons are custom and have frequently-used reasons. And so there are a lot of edit types, such as correcting, revert vandals, ... Thingofme (talk) 12:02, 13 January 2022 (UTC)
  • Installing and using user-scripts as a solution has a significant drawback: user-scripts are hard to find, hard to install and hard to configure for non-technical editors. I am not a novice user and I am a computer programmer by trade and even I could not find above mentioned user script until PorkchopGMX (on the go) has mentioned it above. Non-technical editors who are here for providing high-quality edits in the area of let's say, arts and literature, stand no chance of finding and installing the necessary script. Instead, they will just suffer through infuriating and uneditable collection of their prior edit summaries popping up in the drop-down menu and some of them will just leave annoyed and stop contributing. It is time for a modern GUI-based summary editor easily accessible in user account settings, exactly as the topic starter has suggested! Nyq (talk) 13:08, 29 January 2022 (UTC)

Voting

  • Support Support KylieTastic (talk) 19:30, 28 January 2022 (UTC)
  • Support Support Inspiration:cs:Wikipedista:Dvorapa/tools.js, but make it global. — Draceane talkcontrib. 21:01, 28 January 2022 (UTC)
  • Support Support JDspeeder1 Wookieepedia is a good example of pre-made wiki edit summaries. (talk) 01:42, 29 January 2022 (UTC)
  • Support Support Mha12213 (talk) 05:38, 29 January 2022 (UTC)
  • Support Support Šedý (talk) 10:35, 29 January 2022 (UTC)
  • Strong support Strong supportSvārtava [tcur] 12:19, 29 January 2022 (UTC)
  • Strong support Strong support Not being able to change the list of summaries has been annoying and discouraging me to contribute more on Wikipedia for years now. Please implement this essential feature. Nyq (talk) 13:11, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:12, 29 January 2022 (UTC)
  • Support Support Munfarid1 (talk) 19:27, 29 January 2022 (UTC)
  • Support Support --NGC 54 (talkcontribs) 23:31, 29 January 2022 (UTC)
  • Support Support Common edit summaries is very important. Thingofme (talk) 15:04, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 21:50, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:10, 30 January 2022 (UTC)
  • Support Support I think having a "speed dial" for edit summaries would be very useful. One thing I've noticed is that, if I'm making a bunch of edits with the same summary, and I misspell it, it'll try to auto-complete the messed up version every time. Very annoying to try to avoid this! JPxG (talk) 00:40, 31 January 2022 (UTC)
  • Support Support HugoHelp (talk) 04:15, 31 January 2022 (UTC)
  • Support Support Hanumandas (talk) 11:10, 31 January 2022 (UTC)
  • Support Support PorkchopGMX (on the go) (talk) 14:15, 31 January 2022 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 14:26, 31 January 2022 (UTC)
  • Strong support Strong support IAmChaos (talk) 18:03, 31 January 2022 (UTC)
  • Support Support Daniel Case (talk) 18:12, 31 January 2022 (UTC)
  • Support Support I have proposed something similar in some previous survey. JAn Dudík (talk) 20:32, 31 January 2022 (UTC)
  • Support Support IOIOI (talk) 20:44, 31 January 2022 (UTC)
  • Support Support MONUMENTA (talk) 00:51, 1 February 2022 (UTC)
  • Support Support Wargo (talk) 21:25, 1 February 2022 (UTC)
  • Support Support KingAntenor (talk) 06:24, 2 February 2022 (UTC)
  • Support Support Good idea. Alexcalamaro (talk) 21:12, 2 February 2022 (UTC)
  • Support Support LordPeterII (talk) 22:25, 2 February 2022 (UTC)
  • Support Support WikiAviator (talk) 10:11, 3 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 19:20, 4 February 2022 (UTC)
  • Support Support Lectrician1 (talk) 04:15, 5 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:28, 5 February 2022 (UTC)
  • Support Support Otr500 (talk) 18:01, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:06, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 05:36, 6 February 2022 (UTC)
  • Support Support Fehufanga (talk) 07:55, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 12:00, 6 February 2022 (UTC)
  • Support Support I'm definitely a user across devices; this would also enable me to change them rather than clear my browser history (since I often rely on suggested summaries based on previous browsing history). paul2520 (talk) 23:32, 6 February 2022 (UTC)
  • Support Support PamD (talk) 05:43, 7 February 2022 (UTC)
  • Support Support Meiræ 21:54, 10 February 2022 (UTC)
  • Support Support Sunpriat (talk) 00:07, 11 February 2022 (UTC)
  • Support Support Nehaoua (talk) 16:06, 11 February 2022 (UTC)

Uniformity in spelling

  • Problem: Some spellings have some variations, such as British English versus American English ("colour" versus "color"). This is prevalent in nearly all the languages. Some pages use some variant, while in other pages, the words are spelled differently.
  • Proposed solution: The editor should get a warning about the most prevalent spelling and the editor could mark "this is also spelled as......"
  • Who would benefit: All the stakeholders, i.e. readers, editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Anupamdutta73 (talk) 10:11, 12 January 2022 (UTC)

Discussion

Seems related to phab:T265163. — xaosflux Talk 15:18, 14 January 2022 (UTC)

This is already implemented as template in English Wikipedia. In Chinese Wikipedia due to the adoption of Language Converter this is a non-problem because the converter would automatically convert different words/different spellings/etc into user-selected variant. C933103 (talk) 00:51, 16 January 2022 (UTC)

Even if I can guess it a bit, I really don't get to grasp the explanation of this proposal. Could you develop it a bit more? Because in Catalan, we have two official Academies and our Wikipedia style book allows to use both variants indistinctly for the first editor who creates the article. Then, other editors must respect the first variant used and keep consistent along the text. If you could provide some examples, it would be great. I assume you mean kind of reminding the 2nd editor that this article follows a specific variant and suggesting the changes for it? Xavier Dengra (MESSAGES) 13:45, 22 January 2022 (UTC)
Not OP but Chinese has variations of their writing system, due to historical issues and geographic span. For example, there is Traditional and Simplified Chinese. Simplified Chinese came out of Mainland China in the 1950s and isn't used by Taiwan & Taiwanese. Here's a sentence with the same meaning but visually different characters:
  • 报告录下来了 (Simplified)
  • 報告錄下來了 (Traditional)
Means exactly the same, "the speech has been tape-recorded".
Users of Chinese Wikipedia can switch back and forth between those two plus a few other standards (Hong Kong, Macao, etc) thanks to the Language Converter. Xn00bit (talk) 19:33, 28 January 2022 (UTC)

I do not see any reason for this to come to fruition. Uniformity in spelling provides little besides being easier on the eyes. Bristledidiot (talk) 18:56, 28 January 2022 (UTC)

I rather agree, my gut feeling is that there's not that many variations in British and American English spellings for one to be unrecognizable to the other. Xn00bit (talk) 19:36, 28 January 2022 (UTC)
  • Make things like British/American part of the user profile. Then show differently spelled words according to the profile. There is no reason for editors to worry about this. Lfstevens (talk) 06:44, 31 January 2022 (UTC)

Voting

  • Support Support Sulaiman Gwanki (talk) 19:45, 28 January 2022 (UTC)
  • Support Support JDspeeder1 (talk) 00:46, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:02, 29 January 2022 (UTC)
  • Support Support Thingofme (talk) 14:47, 30 January 2022 (UTC)
  • Oppose Oppose See [2] and [3] KingAntenor (talk) 06:14, 2 February 2022 (UTC)
  • Support Support Hampcky (talk) 15:35, 2 February 2022 (UTC)
  • Oppose Oppose There are too many places (e.g., direct quotes, business names, poems...) where an automated tool would have to be overridden. Gary D Robson (talk) 22:46, 4 February 2022 (UTC)
  • Support Support Sir Proxima Centauri (talk) 08:16, 5 February 2022 (UTC)
  • Oppose Oppose Ayumu Ozaki (talk) 07:07, 6 February 2022 (UTC)
  • Oppose Oppose We should value: Linguistic plurality, diversity, inclusivity, Linguistic Flexibility, Freedom of Expression, Linguistic Richness, Creativity. User:afam1986 (talk) --Afam1986 (talk) 16:48, 9 February 2022 (UTC)07:07, 6 February 2022 (UTC)
  • Oppose Oppose: undesirable feature, off-putting to newbies and time-wasting in the false positive case (which could arise in a huge number of ways). Requires lots of language-specific work by the Wishlist team, so not of wide scope. The English Wikipedia has no major issue with spelling conventions. — Bilorv (talk) 11:09, 6 February 2022 (UTC)
  • Oppose Oppose This is something for EN wiki and not for Wikimedia to maintain the lists of variants, which is already done at [4]. Userscripts already assist in updating them according to the English variant of the page — DaxServer (t · c) 12:09, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 18:26, 6 February 2022 (UTC)
  • Support Support InterstateFive (talk) 20:19, 6 February 2022 (UTC)
  • Oppose Oppose --Ján Kepler (talk) 19:42, 9 February 2022 (UTC)
  • Support Support This sounds like it should be an optional gadget, but it could be a particularly useful one! Gaurav (talk) 06:09, 11 February 2022 (UTC)
  • Support Support Fatt-1 (talk) 09:18, 11 February 2022 (UTC)
  • Oppose Oppose DSparrow14 (talk) 17:01, 11 February 2022 (UTC)

Tool to add Wikidata to an article

  • Problem: Adding linked Wikidata data to articles like by using Template:Wikidata (Q8478926) is not user-friendly. You must inconveniently navigate between the item you want to add data from and the template editor in the VisualEditor. You cannot find the statement you are looking for or edit the Wikidata on Wikipedia from the editor itself.
  • Proposed solution: Make a tool that allows you to add data from Wikidata directly to an article's text. You should be able to:
    • Search for an item to add from.
    • Browse and select the value from on the item you want to show
    • Edit the statements and references of an item.
  • Who would benefit: Editors from making editing easier and readers from consuming centralized, directly-sourced Wikidata data.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lectrician1 (talk) 21:58, 12 January 2022 (UTC)

Discussion

Voting

  • Support Support Integrating Wikidata and Wikipedia is vital, as it helps us add and update information in bulk, i.e. with much less effort. We don't information like YouTube subscribers updated manually; we want it handled automatically on Wikidata and then imported. However, for this approach to work, we need more beginner-friendly editing features. This tool would provide that. {{u|Sdkb}}talk 23:40, 28 January 2022 (UTC)
    I note that I support this despite it clearly being a larger task, closely related to "Editing Wikidata from Wikipedia", which was moved to "larger suggestions". {{u|Sdkb}}talk 23:44, 28 January 2022 (UTC)
  • Support Support per Sdkb EpicPupper (talk) 00:00, 29 January 2022 (UTC)
  • Support Support Texttramp (talk) 03:21, 29 January 2022 (UTC)
  • Support Support Higa4 (talk) 07:00, 29 January 2022 (UTC)
  • Support Support JakobVoss (talk) 07:28, 29 January 2022 (UTC)
  • Support Support Steven Sun (talk) 07:33, 29 January 2022 (UTC)
  • Support Support This should be extended to the case of other Wiki projects, e.g. Author: pages in Wikisource. — ElioPrrl (talk) 11:18, 29 January 2022 (UTC)
  • Support Support Terber (talk) 11:57, 29 January 2022 (UTC)
  • Support Support Aca (talk) 12:55, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:14, 29 January 2022 (UTC)
  • Support Support ACortellari (talk) 14:16, 29 January 2022 (UTC)
  • Support Support BSMIsEditing (talk) 15:06, 29 January 2022 (UTC)
  • Support Support Mbrickn (talk) 15:37, 29 January 2022 (UTC)
  • Support Support Amazomagisto (talk) 16:00, 29 January 2022 (UTC)
  • Support Support Sea Cow (talk) 19:03, 29 January 2022 (UTC)
  • Support Support Bluerasberry (talk) 20:05, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 22:12, 29 January 2022 (UTC)
  • Support Support josecurioso ❯❯❯ Tell me! 00:11, 30 January 2022 (UTC)
  • Support Support Bluealbion (talk) 01:34, 30 January 2022 (UTC)
  • Support Support Ameisenigel (talk) 08:50, 30 January 2022 (UTC)
  • Support Support We can further integrating Wikidata, Wikifunctions to Wikipedia, Wikibooks and Wikiversity. That's a good idea to me, and we can search property/items/statements. Maybe a global Wikidata template? Thingofme (talk) 14:56, 30 January 2022 (UTC)
  • Support Support HaythamKenwai (talk) 20:03, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 21:51, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:12, 30 January 2022 (UTC)
  • Support Support SvenDK (talk) 06:36, 31 January 2022 (UTC)
  • Support Support FenyMufyd (talk) 11:45, 31 January 2022 (UTC)
  • Support Support Lrkrol (talk) 14:41, 31 January 2022 (UTC)
  • Support Support Daniel Case (talk) 18:19, 31 January 2022 (UTC)
  • Support Support Patsagorn Y. (Talk) 03:58, 1 February 2022 (UTC)
  • Support Support Silver hr (talk) 21:02, 1 February 2022 (UTC)
  • Support Support Doctorxgc (talk) 21:22, 1 February 2022 (UTC)
  • Support Support Sabelöga (talk) 15:15, 2 February 2022 (UTC)
  • Support Support Hampcky (talk) 15:32, 2 February 2022 (UTC)
  • Support Support Rotavdrag (talk) 11:17, 3 February 2022 (UTC)
  • Support Support The Grid (talk) 13:40, 3 February 2022 (UTC)
  • Support Support Rzuwig 12:03, 4 February 2022 (UTC)
  • Support Support Whisperjanes (talk) 15:53, 4 February 2022 (UTC)
  • Support Support SlowByte (talk) 18:46, 4 February 2022 (UTC)
  • Support Support ·addshore· talk to me! 22:58, 4 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:19, 5 February 2022 (UTC)
  • Support Support --Crosstor (talk) 06:45, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 15:03, 5 February 2022 (UTC)
  • Support Support Exilexi (talk) 18:19, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:06, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:05, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 11:35, 6 February 2022 (UTC)
  • Support Support Newt713 (talk) 14:01, 6 February 2022 (UTC)
  • Oppose Oppose --Ciao • Bestoernesto 18:33, 6 February 2022 (UTC)
  • Support Support paul2520 (talk) 23:34, 6 February 2022 (UTC)
  • Support Support Tom Ja (talk) 18:30, 7 February 2022 (UTC)
  • Support Support I only recently discovered we couldn't do this already Asukite (talk) 20:26, 9 February 2022 (UTC)
  • Support Support Ecritures (talk) 22:43, 9 February 2022 (UTC)
  • Support Support ZellmerLP (talk) 19:42, 10 February 2022 (UTC)
  • Support Support Gaurav (talk) 06:13, 11 February 2022 (UTC)
  • Support Support Betateschter (talk) 07:04, 11 February 2022 (UTC)
  • Support Support Wikidata Bridge should be deployed in more projects, not only in Catalan Wikipedia. — putnik 14:57, 11 February 2022 (UTC)
  • Support Support Nehaoua (talk) 16:11, 11 February 2022 (UTC)
  • Support Support While Wikidata Bridge exists, it doesn’t seem to be actively developed, so any work in this is welcome. stjn[ru] 16:54, 11 February 2022 (UTC)

Allow wikilinks and formatting in TemplateData

  • Problem: TemplateData is an important tool for making editing easier for newcomers. However, because it doesn't allow wikilinks and other formatting in the template description and parameter descriptions, its usefulness is limited in VisualEditor. It also makes it insufficient to suffice for template documentation pages, meaning that many have to have a largely redundant "parameters" section in addition to their TemplateData section. en:Template:Format TemplateData, a crude workaround, has numerous flaws.
  • Proposed solution: Build functionality into TemplateData to enable wikilinks and other basic formatting.
  • Who would benefit: Anyone who uses templates.
  • More comments:
  • Phabricator tickets:
  • Proposer: {{u|Sdkb}}talk 22:12, 22 January 2022 (UTC)

Discussion

Voting

  • Support Support * Pppery * it has begun 18:41, 28 January 2022 (UTC)
  • Support Support. An obvious need for improvement as part of a much larger rethink of the TemplateData system. Jonesey95 (talk) 22:21, 28 January 2022 (UTC)
  • Support Support Izno (talk) 23:08, 28 January 2022 (UTC)
  • Support Support Daud Iffa (talk) 00:07, 29 January 2022 (UTC)
  • Support Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:29, 29 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 02:15, 29 January 2022 (UTC)
  • Support Support Shizhao (talk) 03:47, 29 January 2022 (UTC)
  • Support Support Curios7ty (talk) 09:04, 29 January 2022 (UTC)
  • Support Support Dexxor (talk) 12:17, 29 January 2022 (UTC)
  • Support Support Aca (talk) 12:58, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:12, 29 January 2022 (UTC)
  • Support Support NguoiDungKhongDinhDanh 14:14, 29 January 2022 (UTC)
  • Support Support Wostr (talk) 19:34, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 22:10, 29 January 2022 (UTC)
  • Support Support – this would make it possible to use TemplateData as the only parameter documentation for most templates which has obvious maintainability advantages. GKFX (talk) 22:46, 29 January 2022 (UTC)
  • Support Support --LoraxJr (talk) 22:54, 29 January 2022 (UTC) 22:53, 29 January 2022 (UTC)
  • Support Support --TKOIII TKOIII (talk) 00:10, 30 January 2022 (UTC)
  • Support Support josecurioso ❯❯❯ Tell me! 00:16, 30 January 2022 (UTC)
  • Support Support YTRK (talk) 07:40, 30 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 07:47, 30 January 2022 (UTC)
  • Support Support Wikilinks and wikitexts can't function in TemplateData is the obvious problem when editing templates, we want to provide information. Thingofme (talk) 14:58, 30 January 2022 (UTC)
  • Support Support Matma Rex (talk) 16:33, 31 January 2022 (UTC)
  • Support Support Shooterwalker (talk) 22:28, 31 January 2022 (UTC)
  • Support Support MONUMENTA (talk) 00:50, 1 February 2022 (UTC)
  • Support Support Wargo (talk) 21:25, 1 February 2022 (UTC)
  • Support Support Sabelöga (talk) 16:54, 2 February 2022 (UTC)
  • Support Support Nux (talk) 18:03, 2 February 2022 (UTC)
  • Support Support DecrepitlyOnward (talk) 23:00, 2 February 2022 (UTC)
  • Support Support Vega (talk) 18:27, 3 February 2022 (UTC)
  • Support Support Lol1VNIO (talk) 20:50, 4 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:17, 5 February 2022 (UTC)
  • Support Support ogueScholar⚟ 🞛 ₨Talk📟 12:59, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:03, 5 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:04, 6 February 2022 (UTC)
  • Support Support Carlos Pozo (talk) 06:54, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 11:45, 6 February 2022 (UTC)
  • Support Support Oh, yes, it's really strange this basic feature doesn't exist yet: there are many, many cases where you can't include all relevant information about a parameter: the best solution is to be able to add a wikilink to the relevant section of the documentation. Uanfala (talk) 12:24, 7 February 2022 (UTC)
  • Support Support ~Cybularny Speak? 20:38, 7 February 2022 (UTC)
  • Support Support Hanif Al Husaini (talk) 00:42, 8 February 2022 (UTC)
  • Support Support ~~~~
    User:1234qwer1234qwer4 (talk)
    19:49, 8 February 2022 (UTC)
  • Support Support Yair rand (talk) 00:24, 11 February 2022 (UTC)
  • Support Support Gaurav (talk) 06:20, 11 February 2022 (UTC)
  • Support Support Nehaoua (talk) 15:52, 11 February 2022 (UTC)
  • Support Support stjn[ru] 17:03, 11 February 2022 (UTC)

Enable live preview by default

  • Problem: By default, previews cause a reload of the page, which is slow and loses the editor's undo stack.
  • Proposed solution: Live preview ("Show previews without reloading the page" preference) should be enabled by default. This may require fixing any bugs in the feature first.
  • Who would benefit: All MediaWiki users
  • More comments:
  • Phabricator tickets: phab:T41272
  • Proposer: SD0001 (talk) 16:09, 17 January 2022 (UTC)

Discussion

  • This was actually going to be part of our Real Time Preview for Wikitext project, but we managed to find a way forward without having to make Live Preview on by default. As a result, we have thoroughly investigated all the outstanding bugs listed at phab:T41272 and feel well-prepared to take on this wish :) MusikAnimal (WMF) (talk) 04:15, 18 January 2022 (UTC)
    This seems like something we're already getting because it was top of the list last year, so is there any point in voting for it here? {{u|Sdkb}}talk 23:57, 28 January 2022 (UTC)
    I think MusikAnimal said above that making live preview default is not a part of Real-Time Preview project. Real-time preview would also probably not be enabled by default. SD0001 (talk) 04:13, 29 January 2022 (UTC)

Voting