Jump to content

Community Wishlist Survey 2022/Editing

From Meta, a Wikimedia project coordination wiki
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