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

Discussion

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

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)[reply]
  • This would be great! --Omnilaika02 (talk) 08:55, 11 January 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • @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)[reply]
    @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)[reply]
    @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)[reply]
@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)[reply]
"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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]

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

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

Voting

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

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

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

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)[reply]
  • You might rather use TOC right CCS code? — The preceding unsigned comment was added by Geertivp (talk) 16:20, 2 February 2022 (UTC)[reply]

Voting

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

Discussion

Voting

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

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

Hello @PPelberg (WMF), many thanks. I didn't know that! Jurbop (talk) 19:28, 28 January 2022 (UTC)[reply]
I'm glad to know you found this information useful ^ _ ^ PPelberg (WMF) (talk) 19:30, 28 January 2022 (UTC)[reply]

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

Discussion

Voting

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

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)[reply]
    Maybe this task should be called "make a gadget to turn redirects green". Jonesey95 (talk) 22:23, 28 January 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]

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

Discussion

Voting

Easy access Templates

  • Problem: Accessing and choosing popular templates takes more clicks than it should.
  • Proposed solution:
    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)[reply]


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

Voting

Pinging discussants about wish selection and other updates

Hello everyone,

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

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

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

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

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

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

Discussion

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

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

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

Voting

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

Discussion

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

Voting

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

Discussion

Voting

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

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

    Hi MusikAnimal! Thanks, that's exactly what I meant :) EpicPupper (talk) 20:10, 20 January 2022 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
  • Ah, where we would be if Flow had come to its end result. --Izno (talk) 21:25, 18 January 2022 (UTC)[reply]

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

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

Voting

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

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

Voting

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

Discussion

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

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

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

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

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

Voting

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

Discussion

Voting

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

Discussion

Voting

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

Discussion

Voting

Autosave edited or new unpublished article

  • Problem: Loss of information during editing for technical reasons.
  • Proposed solution: Autosave edited or new unpublished article every minute to a special autosave buffer.
  • Who would benefit: All registered participants.
  • More comments:
  • Phabricator tickets: phab:T75241
  • Proposer: Kurono (talk) 11:05, 22 January 2022 (UTC)[reply]

Discussion

AFAIK, VE and NWE save progress to LocalStorage. But on iOS at least, LocalStorage size is very limited and I lose my work when a tab reloads. Can I assume this proposal is about a server-side auto-save like what you get with Blogger, GDocs, Word Online, etc.? ⁓Pelagic (talk) 10:13, 28 January 2022 (UTC)[reply]

Yes, this suggestion is about server side autosave. Kurono (talk) 11:29, 29 January 2022 (UTC)[reply]
Isn't this already available in when translating articles? Because I find that very useful so this gets my support! Sabelöga (talk) 16:53, 2 February 2022 (UTC)[reply]
This does indeed exist within the mw:Content translation extension, with a time limit on inactivity after which the content is discarded. ~~~~
User:1234qwer1234qwer4 (talk)
20:04, 8 February 2022 (UTC)[reply]
VE/NWE/Flow/DiscussionTools actually use SessionStorage because of the quota issues with LocalStorage. SessionStorage is lost when you switch to a new tab, so LocalStorage would be an improvement. ESanders (WMF) (talk) 13:19, 29 April 2022 (UTC)[reply]

Voting

Auto-save wish fulfilment, your input needed

Hello Delta 51, and supporters of Auto-save feature wish, Community Tech is currently investigating this request and we need your input so our engineers can take decisions.

Please read the new project page we have created for the wish and then visit the talk page to give responses to some questions we have for you. –– STei (WMF) (talk) 18:07, 19 June 2023 (UTC) [reply]

Case conversion

  • Problem: Sometimes an editor needs to change the case of existing text, e.g., if caps lock was inadvertently on. Retyping the text in the correct case is laborious and error prone.
  • Proposed solution: Provide edit tools to change the case of existing text.
    • Lower case
    • Upper case
    • Sentence case
    • Title case
    • Reverse existing case
  • Who would benefit: Editors needing to capitalize existing text, remove capitalization, etc.
  • More comments:
  • Phabricator tickets: T52745
  • Proposer: Chatul (talk) 16:06, 11 January 2022 (UTC)[reply]

Discussion

In order to change text from uppercase to lowercase, wrap the text in {{lc:}}. For the reverse, from lowercase to uppercase, use {{uc:}}. Those are both functions in the software, you do not need templates for those.--Snævar (talk) 17:49, 11 January 2022 (UTC)[reply]

Don't forget to use subst: if you want to save the change, e.g. replace FOO by {{subst:lc:FOO}} (which saves as foo) rather than {{lc:foo}}. Certes (talk) 18:06, 11 January 2022 (UTC)[reply]
Also see mw:Help:Magic words for more formatting modifiers (lcfirst, uc, ucfirst).--Strainu (talk) 07:50, 12 January 2022 (UTC)[reply]
subst: is a game-changing model to fix mistakes. {{subst:lc:FOO}} is to fix mistake, however third-party sites are avaliable. Thingofme (talk) 11:53, 13 January 2022 (UTC)[reply]
There are browser tools to do this; for example, TitleCase plugin for Firefox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 12 January 2022 (UTC)[reply]

MS Word has a little-known keyboard shortcut (Shift+F3) that cycles the selected text through all four capitalisation types. It's a lot more intuitive than some set of sequences like Alt,something,1 / Alt,something,2 / etc. {{Subst:lc: is a fair bit of typing, and works in source-edit mode, not visual-edit. Pelagic (talk) 01:56, 15 January 2022 (UTC)[reply]

The fact that we can't used in visual editing makes {{subst:lc very terrible and hard to cover. Thingofme (talk) 10:41, 15 January 2022 (UTC)[reply]

Copy the text, Ctrl+X, Ctrl+T, type google.com, Ctrl+Enter, type case converter, enter, click on any of the top few result, Ctrl+V, select desired output, Ctrl+C, Ctrl+W, Ctrl+V. But one thing need to check is would it also converted cases of things undesirably, like words like "iPhone". Same problem will also be faced by any integrated assistance tool.C933103 (talk) 01:06, 16 January 2022 (UTC)[reply]

There is w:user:WikiMasterGhibif/capitalize; not sure if it still works though. ~~~~
User:1234qwer1234qwer4 (talk)
18:49, 8 February 2022 (UTC)[reply]

Voting

Automatic currency converter and inflation calculator

  • Problem: There are many articles where where currency is updated to current costs; e.g., on film pages, you might see "Such and Such earned $134 million ($445 million in 2022 dollars)" to indicate how much that is equal to in today's dollars. This is a lot to update on a slew of articles. Likewise, there are often references to money in one country with a parenthetical saying how much in US dollars, euros, etc. With database tables to pull from for inflation and currency conversion, could a template or tool be devised to auto-update these?
  • Proposed solution: Develop a template or tool to reference the amount and automatically display the inflation amount, and a similar template to convert to other currencies (perhaps such a template could convert from the cited currency to ANY currency available in the tool)
  • Who would benefit: A tool or template to automatically update examples for inflation, or to convert foreign currencies, would greatly reduce manual updating of many pages and result in up-to-date accuracy on any such pages. For movies, it's enough to auto-convert the inflated amount for the most recent year in the table. For currency conversion, it could pull the daily conversion rate from a table.
  • More comments: Updating a database of inflation rates and one for conversion rates on a regular basis should be enough to pull from the database in a quick calculation with such a tag or tool to return the amount.
  • Phabricator tickets:
  • Proposer: Indyfitz (talk) 20:50, 11 January 2022 (UTC)[reply]

Discussion

Voting

Like for citations, "Re-use" mode for already listed books in bibliography

  • Problem: When trying to add a source from an already displayed book in an article, I would love to "re-use" one of the listed book and add its page number, for instance. Then it automatically adds the correct reference.
  • Proposed solution: Like for what is already existing with citations, add a "Re-use" mode for all the already listed books in the bibliography section.
  • Who would benefit: Articles with a bibliography section which contains the "Template:Cite book".
  • More comments:
  • Phabricator tickets: phab:T100645
  • Proposer: Jurbop (talk) 08:10, 23 January 2022 (UTC)[reply]

Discussion

This is quite the same request as here, if I understand correctly: Community_Wishlist_Survey_2022/Citations/Automatic_duplicate_citation_finder Skimel (talk) 16:12, 23 January 2022 (UTC)[reply]

Hello, I don't think it is really exactly similar. The idea is not to add a duplicate. It is to use in "Visual editing" mode something that is already available in the bibliography section, not the references section. So I don't have to use any other complex template (like for instance Template:Harvard citation). Thanks in advance Jurbop (talk) 07:22, 24 January 2022 (UTC)[reply]

Voting

No option to enable/disable automatic signing in DiscussionTools

  • Problem: When I use the Reply tool or New Discussion Tool, placing a template already with the signature inside the template, it does not allow me to disable automatic signatures.
  • Proposed solution: Add an option within "Advanced" being a checkbox written "Allow automatic signature" (checked by default, but allowing the user to choose whether to keep it activated or not) next to the "Watch this page" checkbox. Alternatively, if feasible, Discussion Tools could automatically detect whether the comment already ends in the user's signature, in which case it would know not to duplicate it.
  • Who would benefit: Anyone having the same problem as above
  • More comments:
  • Phabricator tickets: T278442
  • Proposer: Juan90264 (talk) 01:36, 18 January 2022 (UTC)[reply]

Discussion

  • What specific template do you have as an example? --Izno (talk) 21:28, 18 January 2022 (UTC)[reply]
    @Izno: I can present an example of a specific template being from my homewiki (Ptwiki), example: pt:Predefinição:WAM/convite in "(sua assinatura)" looks like the signature as soon as you publish that template, but as I can't disable it from New Discussion Tool ends up leaving the signature of the template and the New Discussion Tool. Juan90264 (talk) 06:36, 19 January 2022 (UTC)[reply]
    One of the selling points of Discussion Tools is that no user ever has to worry about adding signatures again. In my opinion, it would be more future-proof to change your templates to not include signatures (at least the templates designed to be used in discussions). It is certainly possible to add an option to disable automatic signatures to Discussion Tools, but this clutters the UI for a narrow use case. Better might be for Discussion Tools to check the parser output of the comment (which we know it already does in real time), and if a signature is included at the end of the comment, refrain from appending the automatic signature. I am not certain but I would think this is feasible to implement. MusikAnimal (WMF) (talk) 23:19, 20 January 2022 (UTC)[reply]
    @Juan90264 Would you mind I reword your proposal to be about having Discussion Tools automatically omit a signature if one is provided at the end of the comment from a substituted template? I do not think adding an option to disable automatic signatures is the right solution and would probably not be well-received by the designers, since Discussion Tools is intended to be very simple to use. Thanks, MusikAnimal (WMF) (talk) 21:49, 25 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): I don't mind rephrasing, your solution seems to be better than I initially left it and ends up solving it anyway. You can proceed with the rewording of the proposal. Juan90264 (talk) 23:42, 25 January 2022 (UTC)[reply]
    I'm actually going to keep your wording and just append mine as an additional possible solution. This way we leave it open-ended :) I'm going to put this up for translation now. Thanks, MusikAnimal (WMF) (talk) 03:26, 26 January 2022 (UTC)[reply]
    I wonder how efficiently this would work since it appears that the tool would need to parse the substituted wikitext before every preview, which I assume isn't done at this point. Convenient Discussions has an "Omit signature" button when adding a new topic, though it is obviously more advanced and probably not aimed at newcomers. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:30, 8 February 2022 (UTC)[reply]

Phabricator ticket: phab:T278442--Strainu (talk) 20:56, 28 January 2022 (UTC)[reply]

Voting

Missing LaTeX capabilities for math rendering

  • Problem: Some of the basic LaTeX features required for writing esthetic math formulae seem to be unavailable, like the \phantom and its variants to adjust horizontal / vertical spaces. For instance the enumeration (from this page) exhibits a badly shaped square root, where one expects a formula like , which one would normally write using a \vphantom{p'} in the first square root to adjust its vertical size to that of the second square root. And how complex would be the possible usage of some additional LaTeX packages like bigint for large integrals, in order to display properly formulae like integrals on this page?
  • Proposed solution: I'm wondering why some of the basic LaTeX features, like the \phantom mentioned above, or raisebox, can't be used?
  • Who would benefit: Readers of scientific articles on Wikipedia or scientific books on scientific texts on Wikisource.
  • More comments: The display of math formulae is also not always satisfactory, see the Improve LaTeX rendering proposal
  • Phabricator tickets:
  • Proposer: F0x1 (talk) 17:04, 15 January 2022 (UTC)[reply]

Discussion

Voting

Alert editors when a change would reduce accessibility of the entry or page

  • Problem: Editors often make changes that make an entry inaccessible or less accessible to people with disabilities.
  • Proposed solution: Aggregation (or duplication if unavoidable) of existing accessibility checking tools such as https://webaim.org/resources/contrastchecker/ or the https://wave.webaim.org/ suite.
  • Who would benefit: People with disabilities (readers and editors), editors not familiar with accessibility requirements (such as subject matter experts about the entry's topic), editors with a commitment to accessibility (less work, less required knowledge of sometimes-conflicting accessibility requirements).
  • More comments: General discussion of accessibility checker features at https://webaim.org/articles/tools/.
  • Phabricator tickets:
  • Proposer: PauAmma (talk) 23:45, 17 January 2022 (UTC)[reply]

Discussion

  • having worked with some of this, just giving ppl tools is not going to help them achieve this. Tools need to be very targeted and tightly integrated if you want users to achieve this goal. Wikis are however very unstructured and this thus makes it by definition very hard to achieve. Do you have specific problems that you would like to see tackled ? —TheDJ (talkcontribs) 11:28, 18 January 2022 (UTC)[reply]
  • Maybe this could be used to check the edit before saving and give a warning message when accessibility will be degraded. To start off it would probably be better to allow override or opt-in for registered users, but if it works well it could be upgraded to default. Anyone overriding the warning takes responsibility, but sometimes it may be necessary, specially in beta. · · · Peter (Southwood) (talk): 13:49, 24 January 2022 (UTC)[reply]

Voting

Collect and move references to reference section on bottom of article

  • Problem: For translation, it may be helpful if all references are coded in the reference section, not inline.
  • Proposed solution: Tool
  • Who would benefit: Editors (check duplicates) and translators. Moving all reference content to the bottom speeds up manual translation a lot and text has better readability.
  • More comments: Of course, the tool will need to be adaptable for different language conventions (e.g. English Wikipedia and German Wikipedia do it differently)
  • Phabricator tickets:
  • Proposer: Ernsts (talk) 12:09, 11 January 2022 (UTC)[reply]

Discussion

Of course. I have translated some 200 articles, mostly about viruses, from en to de. For the reason you mentioned, I meanwhile move all reference contents to the reference section at the bottom of the article, end then do the translation. Whilst the the move process is boring, the translation process is so much easier! A tool performing the moving or supporting it might ease the first part. However, chosing proper reference names might be a complication. A second problem might be sorting of the references. I personally prefer a combination of the 1st author family name and the year.This might be difficult for automation. But these names could be renamed later using the find-and-replace-tool, e.g. as provided at the right upper corner of the edit field (iPad). --Ernsts (talk) 19:31, 11 January 2022 (UTC)[reply]
It's like using the references template, with refs= parameter; and only the names are used in the body. It would mean better readings; however, we can't edit the citations in VisualEditor. Thingofme (talk) 11:41, 13 January 2022 (UTC)[reply]
@Thingofme References defined at the bottom of the article can be edited using VisualEditor, but only if you use the <references>…</references> syntax, rather than a template. Matma Rex (talk) 03:58, 22 January 2022 (UTC)[reply]
In the past, we can edit directly, but now we can't do that anymore. Thingofme (talk) 04:12, 22 January 2022 (UTC)[reply]
@Thingofme Can you share a link to a page or diff where it isn't working correctly? (I'm one of the VisualEditor developers, and we'd like to fix it if it's broken.) I just tested and I was able to edit the references here: [5]. Matma Rex (talk) 05:08, 22 January 2022 (UTC)[reply]
I don't know if there is a link yet, I only remember about the way we can do that, and it showed the {{reflist}} template in the VE. Thingofme (talk) 08:59, 22 January 2022 (UTC)[reply]

Voting

Add infobox without editing whole article

  • Problem: To add infobox it is necessary to edit the article, search the infobox, and enter the data.
  • Proposed solution:
  1. Add a button in the corner of the article to insert infobox without needing to press edit the whole article (similar to adding image).
  2. Or add automatic infobox in article according to categories.

Discussion

Voting

Formatting columns in table

  • Problem: When editing a table in wikitext, it is possible to add CSS properties to rows and to cells, but not to columns. When a property applies to an entire column, we are compelled to copy-paste this property in every cell of the column; it would be easier and shorter to write it only once, at the beginning of the column.
  • Proposed solution: Enable in some way the use of the <colgroup> and <col> HTML attributes within {| |}.
  • Who would benefit: Contributors who create or edit tables on any Wiki project.
  • More comments:
  • Phabricator tickets: phab:T2986, phab:T103276
  • Proposer: ElioPrrl (talk) 16:27, 11 January 2022 (UTC)[reply]

Discussion

  • I can see this as being useful for centering a column of flags (images) or right aligning a numeric column, but my tests on Windows 10 (Chrome, Edge, Firefox) browsers showed that the "text-align" style on the colgroup's col didn't work. I found some other styles didn't work too like "font-weight". It needs more browser support to be effective. Jroberson108 (talk) 10:43, 30 January 2022 (UTC)[reply]
    Browser support can improve in the future, but what surely can be done right now is to modify the wiki engine to parse these attributes and just duplicate them in each cell of corresponding columns. This will of course bloat the output HTML compared to native col (if it were working...), but no more that current manual insertion of all this stuff, and it will greatly relieve us of doing such manual insertions. Maybe this can be optimized by properly defining and automatically using CSS classes. — Mikhail Ryazanov (talk) 23:33, 4 February 2022 (UTC)[reply]
  • A mostly numeric table can be right-aligned as a whole. But there are usually also 1 or more columns that need to be left aligned. style=text-align:left has to be added to every cell in those columns. I can usually find a mass find-and-replace method to do that, but it can be difficult. It would be nice if the Visual Editor could do that to selected columns. --Timeshifter (talk) 14:31, 31 January 2022 (UTC)[reply]
  • And please add an option for decimal point alignment. Current "solutions" are even more painful than plain left/right/center override. — Mikhail Ryazanov (talk) 20:04, 4 February 2022 (UTC)[reply]
  • Note that <col> explicitly doesn't support text alignment properties or anything that requires styling the cell itself. It would only be useful for setting the background colour. ESanders (WMF) (talk) 16:33, 29 April 2022 (UTC)[reply]

Voting

Advanced table tools on Visual Editor

  • Problem: When we use the VisualEditor, we cannot align the contents of the table cells, change the text color or the cell color.
  • Proposed solution: Adding paint, alignment properties to the table tool in the VisualEditor
  • Who would benefit: Wikipedians can get their work done much faster with this innovation.
  • More comments:
  • Phabricator tickets: T54180, T183976, T103276
  • Proposer: Jelican9 (talk) 11:09, 11 January 2022 (UTC)[reply]

Discussion

Voting

Select preview image

Discussion

Here is an example of the problem, seen when hovering over Civil war on Revolution:

Toadspike (talk) 18:43, 10 January 2022 (UTC)[reply]

I think people participating in the discussion would benefit from knowing the rules for image selection: mw:Extension:PageImages#Image_choice. So if the request is not chosen, you can still ask for the algorithm to be customized on your wiki. Correctly populating MediaWiki:Pageimages-denylist helps a log - for instance ro:MediaWiki:Pageimages-denylist has cleared tens of thousands of inappropriate images from being chosen.--Strainu (talk) 07:45, 12 January 2022 (UTC)[reply]

  • I think image choices when previewing the article should be chosen, as some article have the main image not in the first image of the text. This would include more subjects and make the article more viewable. Thingofme (talk) 10:35, 14 January 2022 (UTC)[reply]
  • I have always felt that there is a lot of magic behind Page Previews – as an user I cannot simply look how this thing works... And yeah, the images tend to be weird sometimes. Moreover, the denylist doesn't seem to be a clever way to affect the choice of the image. — Draceane talkcontrib. 23:06, 14 January 2022 (UTC)[reply]
  • Could the PageImages be editable, like in a wiki? (Just have a template or magic word that allows editors to choose the image?) Currently it seems to use AI instead of crowdsourcing, which makes sense if you have to pay the people choosing the images, not so much for Wikipedias. It could allow all free images used on the page plus images on a special whitelist (things like File:Placeholder_staff_photo.svg come to mind). A bot run could be used to initialise the editable PageImage with the current automatic one. Kusma (talk) 19:52, 22 January 2022 (UTC)[reply]
  • I could imagine this being implemented on the action=info interface, where you can already change the content model and (depending on the wiki) content language. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:50, 11 February 2022 (UTC)[reply]
    Update: The civil war image issue has been fixed as a result of https://phabricator.wikimedia.org/T301588 thanks to this being highlighted in the community wishlist.
User:Toadspike are there other issues that we're hoping to address outside the one you posted here? I've gone through phab:T91683 and am struggling to find a problem which can't be resolved using T301588 so it would be good to document what those are to assist Community tech in understanding the problem statement(s). Jdlrobson (talk) 21:46, 17 February 2022 (UTC)[reply]
User:Jdlrobson I have looked through the Phabricator links you provided. That seems to fix the problem I'm getting at, and I'm very glad the wishlist submission helped. This will work much better than phab:T91683 for images in templates. One example where it might not work as well is if one wants the second image on a page to be the PageImage: One would add class=notpageimage to the first image to exclude it, but someone else might later add another image above the desired image, replacing it as PageImage. Thus, outside of templates, a system like phab:T91683, where the PageImage is permanently specified, regardless of edits to images around it, would still be an ideal solution. Please tell me if I am misunderstanding anything, and thank you again for your work. Toadspike (talk) 03:12, 18 February 2022 (UTC)[reply]

Voting

More easily view template parameters in VE

  • Problem: Many articles have Infobox with many blank parameters (i.e. data not supplied)
  • Proposed solution: The mastercopy of the infobox, i.e. list with all the parameters available should be available in both "Visual Edit" and "Source Edit" mode, so that an editor can automatically choose the parameters needed. A future editor can also add parameter(s) easily.
  • Who would benefit: Editors
  • More comments: This will clear up the unnecessary spaces in the Infobox.
  • Phabricator tickets: T74083
  • Proposer: Anupamdutta73 (talk) 07:47, 13 January 2022 (UTC)[reply]

Discussion

  • @Anupamdutta73: Have you used the TemplateWizard tool (in the wikitext editing toolbar)? This is one way to get a list of all available parameters for a given infobox or other template. I'm not sure if you're suggesting that all unused parameters be removed from template invocations (that's a matter for local wiki style guides), but one potential solution to your problem could be to extend the TemplateWizard to make it possible to open a template invocation for editing — that'd mean you could click on a given template title in the wikitext and open it in TemplateWizard where all it's filled and unfilled parameters would be visible (with nice labels and descriptions etc.). There's more description of that in task T206494; do you think this would be a reasonable solution? — SWilson (WMF) (talk) 02:46, 18 January 2022 (UTC)[reply]
  • @SWilson (WMF): Frankly, I am missing something.... Whenever I use the template (even a few minutes back) for new or editing, no suggestions popup for the paramaters.... For example for infobox Person the first parameter is name, which is not shown... Hence my suggestion on the left pane the full list (uneditable but scrollable) which gives both the new and the seasoned editors a clear idea the list of available parameters.... Anupamdutta73 (talk) 03:13, 18 January 2022 (UTC)[reply]
  • @Anupamdutta73: Ah, right! Sorry, I was incorrectly thinking you were talking about the WikiEditor rather than Visual Editor. You're right, for VE there is a different way of viewing template parameters in the template-insertion dialog. If you switch to 'source editing' you can try out the TemplateWizard, with the left pane that lists all parameters. Perhaps this proposal could be changed to make this sort of list available in VE? — SWilson (WMF) (talk) 03:22, 19 January 2022 (UTC)[reply]
Seems like this is related: phab:T280078 TemplateData support for specifying parameters that are allowed to be empty. We have a workaround [[[:pl:MediaWiki:Gadget-veKeepParameters.js|patch that make VE keeps empty parameters]] on pl.wiki. This way VE keeps parameters marked as suggested and so people editing code do not have to look up basic parameters. Works fine since November, so quite a long time. Obviously would be great if a more permanent solution would be added. --Nux (talk) 18:36, 2 February 2022 (UTC)[reply]

Voting