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
Regarding a potential NOSUBST option, substituting can always be helpful for test edits, to be able to see what a template actually outputs. Even if you're not supposed to substitute a template normally. Jochem van Hees (talk) 15:36, 6 February 2022 (UTC)[reply]
Not sure if @Izno was referring to "NOSUBST" as a "never substitute this template" option (in complement to this proposal) or "do not subst in this case" (in complement to the "subst:" syntax). ~~~~ User:1234qwer1234qwer4 (talk)18:52, 8 February 2022 (UTC)[reply]
As for the opt-outs requested below, I'm not sure what that implies but I think it's "I'm adding this template here but I don't want to subst it", which would indeed be some sort of {{nosubst: syntax I guess. I don't have an issue with that. Izno (talk) 19:38, 8 February 2022 (UTC)[reply]
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.
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)
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.
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.
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]
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?
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.
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.
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?
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"
@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]
@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]
Please, if it can't be done manually, anything that adds a slightly identifying feature would be a great improvement. Publisher, author, date, random long word from the Oxford dictionary. Anything that makes a citation reusable by a human. Chipmunkdavis (talk) 22:05, 27 January 2022 (UTC)[reply]
Support: if the team can automatically get sensible names like "guardian-0" from metadata by taking the URL and stripping words like "the" then that's fantastic. Another option to explore would be to have some way for wikis to customise the default names that references would get based on metadata so that en.wiki could, for instance, use "nyt-i" as the default for any website with URL "nytimes.com" and someone could even add something very specific like "CLRS-i" for anything with "Introduction to Algorithms" in the title parameter. Though, maybe this would be technically infeasible as a large number of conditional naming conventions could cause performance issues. — Bilorv (talk) 10:44, 6 February 2022 (UTC)[reply]
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.
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]
Oppose This is why we have Wikidata. We might as well take the time to build the tools to successfully use Wikidata in an article than waste it on creating a band-aid that still requires manually editing multiple articles. Lectrician1 (talk) 22:40, 28 January 2022 (UTC)[reply]
Yep, I came here to say this too. In several of my articles, I already use en:template:Wikidata to draw information, so that e.g. updating the number of students at a university automatically updates it in the infobox, the body, the university's people list page, and infoboxes in other languages. I'd encourage folks here to support "Tool to add Wikidata to an article" and "Editing Wikidata from Wikipedia", as that's what's needed to get the system more off the ground. {{u|Sdkb}}talk00:07, 29 January 2022 (UTC)[reply]
Support But like a Wikidata in articles, Wikibooks, Wikiversity, ... We don't have enough contents around it to use more of Wikidata in articles Thingofme (talk) 14:52, 30 January 2022 (UTC)[reply]
Oppose if you really want this functionality then you can get close with an editnotice or even one of the warnings that triggers when you submit an edit and allows you to go through with it by pressing "Publish changes" a second time. However, volunteers should be able to fix one thing without being bound to fix arbitrarily many other things (which they may not have the time or knowledge to do). On the English Wikipedia, unless it is part of completing one action (like starting an ANI discussion requires notifying the user under discussion) there are very few cases where anybody is compelled to do anything, so I would not support this feature being used on en.wiki, even if the Wishlist team were to produce it. — Bilorv (talk) 10:53, 6 February 2022 (UTC)[reply]
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.
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]
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.
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]
Oppose As noted this is more of a reading issue. However ... in the linked article the solution might be to write a proper full-length intro of some kind (yes, even lists can and should have them), thereby pushing the contents box down somewhat. It's also a unique situation since there's two boxes on the other side. And any text in there would be sandwiched, which is generally avoided in layout both on and offline.
Now, if we could find a way to make text corresponding to the space taken up by the art on either side left- or right-justify automatically, we might have something to work with IMO. Daniel Case (talk) 18:26, 31 January 2022 (UTC)[reply]
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.
Oppose XTools already have this tools, but it's in the Opting in for restricted statistics section, and sometimes we can't view it. Thingofme (talk) 15:05, 30 January 2022 (UTC)[reply]
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!
@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.
I think this would be more useful if it were made specific to the user. As in, when visiting a particular article, each user sees how many messages were added/edits were made to that article's talk page since their last visit to the talk page (or, if that's too resource demanding, a simple boolean indicating whether there were any messages/edits). Silver hr (talk) 20:10, 1 February 2022 (UTC)[reply]
Oppose Adds unnecessary clutter to the interface. If someone wants to talk, they would use the talk page. Instead the WMF Web Team work seems promising — DaxServer (t · c) 12:16, 6 February 2022 (UTC)[reply]
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.
I think we should see the suggested edits for more established users to be able to implement faster copyediting problems. But they are "designed" for beginners. Thingofme (talk) 11:48, 13 January 2022 (UTC)[reply]
MrMeAndMrMe, established editors can opt-in on those from the preferences. While I don't know the option name in English, it ahould be something along the lines of "Show homepage". You can then click on your username and instead of your user page, you'll be redirected to the page that newbies see. Strainu (talk) 06:00, 12 January 2022 (UTC)[reply]
Not everyone wants to show homepage, as the homepage is like for the newcomers. Some experienced users think they are experienced and not very new anymore. Thingofme (talk) 10:29, 15 January 2022 (UTC)[reply]
Oppose Experienced editors are expected to know what they are doing. The Suggested Edits feature helps newcomers; since editing on mobile app is still in its novice form, it could be helpful. If this wish is implemented, please disable it by default. — DaxServer (t · c) 11:49, 6 February 2022 (UTC)[reply]
While this is true, sometimes finding major formatting errors takes a little while for experienced people. Disabling it by default also defeats the purpose of it; to make people look at that general area more and maybe contribute in a faster way.
It isn't a required feature and disabling isn't difficult.
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).
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]
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.
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]
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.
A related and very frequent situation is forgetting to write an edit summary. For such cases, a more or less established convention is doing an "empty edit" with just the edit summary. One way to implement the suggested feature would be to take advantage of this existing convention and have empty edits modify the summary of the previous edit (assuming the edit is yours, of course). Another approach, perhaps more modern and intuitive, would be to have some sort of [edit summary] button next to your latest edit, that would open a dialog similar to the [thank] button. Sophivorus (talk) 00:51, 16 January 2022 (UTC)[reply]
I think this mean log of editing note changes being needed to avoid dispute. And I don't think log of changes in log is something productivity, even though I see the use case here. C933103 (talk) 06:51, 16 January 2022 (UTC)[reply]
Hello there, and thanks for taking the time to write this proposal. We've discussed as a team and found that the part asking for edit summaries to be editable would be declined for community alignment and perennial reasons, but the part about appending additional summaries could be in scope https://phabricator.wikimedia.org/T210327 Do you mind editing this proposal to be about that part only? If so, this can get accepted for the next phase to be voted on. Thanks so much, NRodriguez (WMF) (talk) 00:39, 18 January 2022 (UTC)[reply]
Support Some people should be able to edit the summary and reasons by users and admins, just to fix the broken archive links (talk page) or forget to edit summary. Thingofme (talk) 15:09, 30 January 2022 (UTC)[reply]
{{weak support}} only if it’s to append, not to edit existing summaries, and that it will be obvious for the website viewer what was part of the original summary and what wasn’t. -Gifnk dlm 2020From Middle English Wikipedia 📜📖💻 (talk) 15:24, 30 January 2022 (UTC)[reply]
Support Long overdue. Even experienced users such as myself can make a mistake in an edit summary, perhaps with an incorrect link [1]. My only suggestion would be to put some limit on it, to prevent misuse (e.g. edit summaries can only be changed before there's another edit). Voice of Clam (talk) 15:19, 4 February 2022 (UTC)[reply]
Oppose: complicating the page history interface (whether by viewing these additional summaries or seeing options everywhere to add additional summaries) is a cause of concern for making Wikimedia friendly to new volunteers. There's lots of misuse potential to be thought about, whereas the current dummy edit situation is not that complicated and can cause very few problems. The only genuine substantial use case where there's no alternative is in fixing a typo or link in an edit summary, but this cannot be addressed without causing serious misuse problems (there is no set of editors that can be trusted in altering their edit summaries without record, and "edit summary histories" circles back to my interface complication concerns). If you really mess up on an edit summary (like by accidentally pasting your phone number rather than the text you intended to copy) then you can get it revdelled. — Bilorv (talk) 10:50, 6 February 2022 (UTC)[reply]
Oppose Potential misuse and havoc. When someone is investigating something, they are not expected to comeback everytime to see if an user altered the edit summary. This is unfeasible and non-transparent, despite genuine intentions of fixing a typo or adding extra comments. Additional dummy edit, revdel offers effective alternatives and transparency. — DaxServer (t · c) 11:19, 6 February 2022 (UTC)[reply]
Oppose coming from a coding background & specifically from what I've learned with commit messages... yes, sometimes there are times you want to change, but I'd rather stick with the integrity of whatever message is left. I'm also worried about the the potential misuse that Bilorv mentions. = paul2520 (talk) 23:28, 6 February 2022 (UTC)[reply]
Weak support I like the idea of amending an edit summary ala Git, which is something I've been pondering for a while. I would rather this option be added as a gadget which could be optionally enabled, to address cluttering issues. Also, the original edit summary should always be viewable somehow. Asukite (talk) 20:20, 9 February 2022 (UTC)[reply]
Support I would like to have 5-10 minutes after editing during which I could change the summary. This may not be a change to the already recorded text, but an addition. There are many signs in the summary field, why not add new stacks until the field is exhausted. Sunpriat (talk) 00:52, 11 February 2022 (UTC)[reply]
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
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.
Support something configurable on an individual user or individual wiki basis (the team don't need to go down the road of automatically tracking and suggesting templates that an account frequently uses). — Bilorv (talk) 11:21, 6 February 2022 (UTC)[reply]
Support I thinks some level of 'often used by u' or 'often used by similar articles' functionality would be very good for most editors. Inspiration can be drawn from wikidata's Recoin. —TheDJ (talk • contribs) 18:36, 7 February 2022 (UTC)[reply]
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.
While I often get around this flaw by making line break addition and removal separate from other editing, I could stand to see it handled better. Dhtwiki (talk) 03:15, 29 January 2022 (UTC)[reply]
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.
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}}talk23: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]
Support I like the idea; I feel like more examples could be given in the proposal, though, such as an example of what such a link would look like vs. how a section title might change. paul2520 (talk) 23:31, 6 February 2022 (UTC)[reply]
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.
I have thought about this problem but generally I side on the "someone will correct the issue at some point if an appropriate file is available". Maybe a bot to notify local talk pages that an image has been deleted (even if for some reason the edit removing the image is insufficient). --Izno (talk) 05:42, 21 January 2022 (UTC)[reply]
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]
Oppose: we cannot automatically determine whether a file that has been deleted on Commons for some reasons still falls within, for example, en.wiki scope. It would be very bad to see easily ported attack images, images without sufficient copyright information for our non-free content criteria, or out of scope images. This affects legal issues as egregious cases could even fall afoul of fair use or piracy law (e.g. a film uploaded as a video). So this tool would have to be restricted to experienced users, who can be trusted to actually check that the image is appropriate for the wiki they want to use the image on, but by that point there is little use case as experienced users should (a) not often have images deleted on Commons and (b) be able to reupload the image without too much trouble. — Bilorv (talk) 10:58, 6 February 2022 (UTC)[reply]
Oppose Better not to tinker with copyright matters. If something belongs somewhere else, the user could be instructed to do so. If the user is unaware of how to achieve that, they can ask for help. — DaxServer (t · c) 11:44, 6 February 2022 (UTC)[reply]
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
Support This is also an accessibility feature. E.g a missing shortcut for inserting the current date into date fields effectively prevents me from contributing more to Wikidata. Trilemma2 (talk) 14:10, 29 January 2022 (UTC)[reply]
Support: if the issue is a lack of shortcuts that don't conflict with a user's device or browser, then making additional shortcuts customisable and opt-in would solve the problem. — Bilorv (talk) 11:05, 6 February 2022 (UTC)[reply]
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 MusikAnimalhere (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.
@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.
@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]
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]
Support Ensuring newcomers have a positive experience is nothing less than vital to the continuation of the encyclopedia. This would be a good step toward that. {{u|Sdkb}}talk22:38, 28 January 2022 (UTC)[reply]
Support What is like pending changes? Semi-protection is hard-core one, but you can have some dumping grounds like template sandboxes. Thingofme (talk) 14:54, 30 January 2022 (UTC)[reply]
Support I think this would make editing more accessible. I agree that good-faith new users shouldn't have to learn all the technical details to be able to submit beneficial edits. paul2520 (talk) 23:41, 6 February 2022 (UTC)[reply]
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>".
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]
Strong support Not being able to change the list of summaries has been annoying and discouraging me to contribute more on Wikipedia for years now. Please implement this essential feature. Nyq (talk) 13:11, 29 January 2022 (UTC)[reply]
Support I think having a "speed dial" for edit summaries would be very useful. One thing I've noticed is that, if I'm making a bunch of edits with the same summary, and I misspell it, it'll try to auto-complete the messed up version every time. Very annoying to try to avoid this! JPxG (talk) 00:40, 31 January 2022 (UTC)[reply]
Support I'm definitely a user across devices; this would also enable me to change them rather than clear my browser history (since I often rely on suggested summaries based on previous browsing history). paul2520 (talk) 23:32, 6 February 2022 (UTC)[reply]
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
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 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]
Make things like British/American part of the user profile. Then show differently spelled words according to the profile. There is no reason for editors to worry about this. Lfstevens (talk) 06:44, 31 January 2022 (UTC)[reply]
Oppose We should value: Linguistic plurality, diversity, inclusivity, Linguistic Flexibility, Freedom of Expression, Linguistic Richness, Creativity. User:afam1986 (talk) --Afam1986 (talk) 16:48, 9 February 2022 (UTC)07:07, 6 February 2022 (UTC)[reply]
Oppose: undesirable feature, off-putting to newbies and time-wasting in the false positive case (which could arise in a huge number of ways). Requires lots of language-specific work by the Wishlist team, so not of wide scope. The English Wikipedia has no major issue with spelling conventions. — Bilorv (talk) 11:09, 6 February 2022 (UTC)[reply]
Oppose This is something for EN wiki and not for Wikimedia to maintain the lists of variants, which is already done at [4]. Userscripts already assist in updating them according to the English variant of the page — DaxServer (t · c) 12:09, 6 February 2022 (UTC)[reply]
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.
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: You stated something similar to the other two users above and I would recommend you vote for this proposal.
Voting
Support Integrating Wikidata and Wikipedia is vital, as it helps us add and update information in bulk, i.e. with much less effort. We don't information like YouTube subscribers updated manually; we want it handled automatically on Wikidata and then imported. However, for this approach to work, we need more beginner-friendly editing features. This tool would provide that. {{u|Sdkb}}talk23:40, 28 January 2022 (UTC)[reply]
Support We can further integrating Wikidata, Wikifunctions to Wikipedia, Wikibooks and Wikiversity. That's a good idea to me, and we can search property/items/statements. Maybe a global Wikidata template? Thingofme (talk) 14:56, 30 January 2022 (UTC)[reply]
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.
Support – this would make it possible to use TemplateData as the only parameter documentation for most templates which has obvious maintainability advantages. GKFX (talk) 22:46, 29 January 2022 (UTC)[reply]
Support Wikilinks and wikitexts can't function in TemplateData is the obvious problem when editing templates, we want to provide information. Thingofme (talk) 14:58, 30 January 2022 (UTC)[reply]
Support Oh, yes, it's really strange this basic feature doesn't exist yet: there are many, many cases where you can't include all relevant information about a parameter: the best solution is to be able to add a wikilink to the relevant section of the documentation. Uanfala (talk) 12:24, 7 February 2022 (UTC)[reply]
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.
This seems like something we're already getting because it was top of the list last year, so is there any point in voting for it here? {{u|Sdkb}}talk23:57, 28 January 2022 (UTC)[reply]
I think MusikAnimal said above that making live preview default is not a part of Real-Time Preview project. Real-time preview would also probably not be enabled by default. SD0001 (talk) 04:13, 29 January 2022 (UTC)[reply]
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]
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]
Support After the crash of the browser, all information is lost and when you restart the browser, the visual editor opens a new edit without your changes. Sunpriat (talk) 00:05, 11 February 2022 (UTC)[reply]
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.
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.
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]
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]
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]
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.
This would need external scientific data which could be controversial and unprecise, especially for old currencies like Sestercius. In addition to historical bias, there is also a geographical bias which make scientifics sometimes to use non-monetary currencies like Big Mac Index. --Pols12 (talk) 21:29, 11 January 2022 (UTC)[reply]
I agree. This is one of those things that looks simple until you really start understanding how many caveats apply. It gets into original research territory in my opinion, which we should not have in Wikipedia. —TheDJ (talk • contribs) 10:40, 12 January 2022 (UTC)[reply]
And different countries have different inflation rate, as well as different currency exchange rate. Even among countries that use same currency. C933103 (talk) 01:01, 16 January 2022 (UTC)[reply]
On the English Wikipedia at least this is done automatically using things like en:template:inflation and en:template:To USD, there's already no need to manually update pages. Given that there is an element of editorial decision involved in choosing which inflation measures and conversion methods to use I think this is best left to individual wikis to set up, rather than being hardcoded into mediawiki. 86.23.109.10111:11, 12 January 2022 (UTC)[reply]
When translating templates, we have to include some internationalization and some phrase would different in other languages. The inflation is like using the outsider's data, which is sometimes third-party. Maybe getting the inflation data from Wikidata? Thingofme (talk) 10:31, 15 January 2022 (UTC)[reply]
Support I would also appreciate the option to convert currencies and adjust for inflation at the same time, ie. what is £1 million in today's UK£ and US$? JDspeeder1 (talk) 01:39, 29 January 2022 (UTC)[reply]
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".
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]
@Izno, Many thanks for all the information. I appreciated.
So the idea was already submitted and voted for many times during the last years! And in 2021, it was decided that, well you know, technically it is possible to do it (even if it is more difficult to do in VE).
And well, finally it is not a priority because not enough people voted for it!
I am wondering : do we want to improve the reliability of Wikipedia by adding easy ways for anyone (less advanced users in mind) to add citations for books? Jurbop (talk) 09:14, 29 January 2022 (UTC)[reply]
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
@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]
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]
Support When creating a section by archiving at enwiki for ArbCom (such as ARCAs), my signature is appended where it should not be. As such I now just edit the page directly to prevent my signature being added. However, making this work may be more difficult that said. Dreamy Jazztalk to me | enwiki14:30, 31 January 2022 (UTC)[reply]
Hard to do with long-standing templates and user scripts or other workflows adapted to them. Automatic signing is generally useful and saves you a couple clicks when using the plain source editor. ~~~~ User:1234qwer1234qwer4 (talk)19:28, 8 February 2022 (UTC)[reply]
Support From what I read, it's the templates that cause the problem. I only support MusikAnimal's alternative solution of Discussion Tools/Reply Tool detecting the signature, if possible — DaxServer (t · c) 11:27, 6 February 2022 (UTC)[reply]
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.
Totally agree. We could even continue the list : \hfill, \hdots, \substack, \smash and many environments (e.g. multline, split) from amsmath. — ElioPrrl (talk) 22:04, 16 January 2022 (UTC)[reply]
This seems like a consensus needed kind of request, not per community but with the math community (which is generally available on Phabricator already). --Izno (talk) 21:27, 18 January 2022 (UTC)[reply]
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).
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 (talk • contribs) 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]
Oppose: the issue can be quite technically nuanced (in wikitext terms) and I don't want newbies to be stopped from making contributions based on something an experienced editor with the page watchlisted can fix. We have a lot of social problems on en.wiki with accessibility being widely misunderstood, undervalued and arcane, but I do not believe these problems can be solved through technical redesign. People just ignore warnings that they don't understand. — Bilorv (talk) 11:07, 6 February 2022 (UTC)[reply]
Oppose per reasoning from Bilorv. And this adds extra hurdle to overcome in editing, when the user is unaware of how to resolve the issue. — DaxServer (t · c) 12:04, 6 February 2022 (UTC)[reply]
Oppose this is saying "apply secret sauce to everything" while secret sauce generally just doesn't deal with the complexities of our content in my experience. —TheDJ (talk • contribs) 18:32, 7 February 2022 (UTC)[reply]
Support From the experience of Special:LintErrors correction, it can be very difficult to find a problem. Many users can't even fix it. But a built-in tool for this like LintErrors would be interesting. Sunpriat (talk) 00:27, 11 February 2022 (UTC)[reply]
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)
This would be great! References can clog the text and make it unreadable. The only advantage of having references in the text is that they can be copy-pasted together with the text. Sylvain Ribault (talk) 13:25, 11 January 2022 (UTC)[reply]
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]
@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]
This exists at least on the English Wikipedia, with the References Segregator tool. According to its documentation, it can also work on any other MediaWiki project. Ɱ (talk) 04:33, 13 January 2022 (UTC)[reply]
Neutral I think more context is needed as we have WP:CITEVAR. Having references moved to the References section is only one citation method. If you mean a way for references to be hidden within the text then I see no issue. The Grid (talk) 13:50, 3 February 2022 (UTC)[reply]
There is a user script/gadget already available that adds an "edit lead section" button. That seems like it suffices today. --Izno (talk) 05:43, 21 January 2022 (UTC)[reply]
Indeed the suggestion in the four comments above seems reasonable, though the proposal is not quite clearly worded – I thought this was talking about some kind of visual interface specifically for adding an infobox. ~~~~ User:1234qwer1234qwer4 (talk)18:06, 8 February 2022 (UTC)[reply]
Voting
Oppose idea 1 as needlessly single-purpose ("insert a few specific things") when we already have a robust solution to the more general idea of editing the lede ("edit first section" feature). Oppose idea 2 because the mere presence of an infobox is contentious at best and against consensus in other cases. DMacks (talk) 22:03, 28 January 2022 (UTC)[reply]
Oppose as editing the lead section alone is already possible, but this request does emphasise the need for the edit lead section button to be switched on by default rather than hidden away as a gadget. GKFX (talk) 22:58, 29 January 2022 (UTC)[reply]
But why some wikis, even enwiki has no default lead section links? And what about IPs who wants to edit? Also, how can we configure it globally? The process is that global gadget is not possible. We can do this for IPs is to made default, IPs are human too. Thingofme (talk) 15:14, 30 January 2022 (UTC)[reply]
Neutral Would be more useful to have a section edit in VE. We already have 0-section edit link on pl.wiki for years (~10 years I guess). On en.wiki community can vote to add similar default gadget. Nux (talk) 18:16, 2 February 2022 (UTC)[reply]
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.
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]
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]
I can definetly see the benefit of adding options to align text, set sortability keys, flip between cell and header type etc. Also would be nice to highlight the option for importing CSV a bit more. —TheDJ (talk • contribs) 12:31, 11 January 2022 (UTC)[reply]
There is a lot of complexity here, even just considering alignment. Alignment can be set using the align attribute, the style attribute, or using a class. It can be set on the whole table, a whole table row, or a table cell. That's already 9 ways alignment could have been set that can all potentially interact with each other. ESanders (WMF) (talk) 13:33, 11 January 2022 (UTC)[reply]
I do have one question. Is it possible to manually move images around using visual editor? I'd love to see it and this would be a nice thing to add. Rzzor (talk) 19:06, 12 January 2022 (UTC)[reply]
I would like to further understand how you imagine this to work. Would you like to set the alignment of the of each table cell in the table properties dialog? KSiebert (WMF) (talk) 15:49, 14 January 2022 (UTC)[reply]
For instance, one should be able to select a few table cells, or a few rows/columns, then hit a "right-align" button on the toolbar, then expect all text in the selected cells would carry the property of being right-aligned. And, I think it would also be useful if it have features like cell merge and cell split like similar features found in spreadsheet software.C933103 (talk) 00:56, 16 January 2022 (UTC)[reply]
Just aA note that using colors for table cell backgrounds is often an accessibility problem and generally discouraged within larger wikis unless part of a templated system which ensures the accessbility. —TheDJ (talk • contribs) 14:58, 16 January 2022 (UTC)[reply]
Support Clearly important, given how frequent tables are and how they're already one of the areas where editors gravitate to VE. {{u|Sdkb}}talk00:10, 29 January 2022 (UTC)[reply]
Support Yes please. Now when editing (non-simple) tables I always need to change from visual editor to wikitext editor. Stryn (talk) 17:19, 30 January 2022 (UTC)[reply]
Proposed solution: Allow editors to choose a certain image within the article, not necessarily from within the lead section, to be displayed as the preview image. This could be done with a magic word or in the image syntax itself.
Who would benefit: Everyone who uses page previews when reading Wikipedia articles (presumably most desktop users).
I frequently see this issue confuse people in real life and am very happy to see it being addressed. Could the problem be fixed more speedily just by excluding all transcluded images from previews? It seems like manually selecting previews for every article would be a major effort in itself. I would also like to point out that the same image appears in mobile search, so the scope of benefit is even broader than just desktop users. --SmallJarsWithGreenLabels (talk) 20:05, 10 January 2022 (UTC)[reply]
The "transcluded image" is exactly what the infobox displays. If you exclude it or lower the priority, then significantly more articles will be broken than fixed. — putnik21:59, 10 January 2022 (UTC)[reply]
The problem is that by removing (or lowering the priority) images from the infoboxes of most articles, you will get a second image in these articles as the main one. And in a very large (much more than there are now) number of cases, there will be incorrect. — putnik22:58, 10 January 2022 (UTC)[reply]
The problem is that apparently the first picture in the article is chosen. When it is an info box, it is not a problem, but templates for series in pages that don't have info boxes are where the image is most disappointing. However, I just checked the preview for w:Anti-communism fearing that it had an sickle and hammer, and it has no image, I don't know how. A template like "PreviewImage" around a File:aa.jpg could prioritize it over the template images. --Error (talk) 17:50, 11 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. — Draceanetalkcontrib.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]
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]
Support Oftentimes, the first image in an article will not be an appropriate thumbnail to represent the concept that the article describes -- it's not just an issue with template images. I think that some more granularity on this would be very useful. JPxG (talk) 00:39, 31 January 2022 (UTC)[reply]
Support: this should have been part of the minimum viable product and Page Previews should not have been launched without it. — Bilorv (talk) 11:03, 6 February 2022 (UTC)[reply]
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.
@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]
Dialog that opens@Anupamdutta73: You should see a list of available parameters at the left pane of the TemplateWizard dialog; do you not see something like in the screenshot at right? At the moment, it's not possible to edit a template in this way. SWilson (WMF) (talk) 05:10, 18 January 2022 (UTC)[reply]
@SWilson (WMF): I am really sorry to say i have never encountered the correct layout in my 20 months as a wikimedian... Please let me know how to get the correct template and not the one I am getting... Anupamdutta73 (talk) 05:41, 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]
Weak support I dont use VE, but I see the help, the number of times I've opened a template doc page to check what the names of parameters are is more than I care to admit. IAmChaos (talk) 18:08, 31 January 2022 (UTC)[reply]
Support. I'd also like a NOSUBST option. --Izno (talk) 23:09, 28 January 2022 (UTC)
Oppose --Ciao • Bestoernesto • ✉ 18:37, 6 February 2022 (UTC)
22:15, 30 January 2022 (UTC)
It is doubtful too much of an all-in-one problem solving request. --Havang(nl) (talk) 15:55, 31 January 2022 (UTC)
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)
Done What do you think? HelenDegenerate (talk) 02:43, 18 January 2022 (UTC)
Strong support Tranhaian130809 (talk) 11:31, 29 January 2022 (UTC)
Weak support: I think this could be a nice feature if it was limited to maybe one hour after the edit → «« Man77 »» [de] 13:13, 30 January 2022 (UTC)
Neutral I think more context is needed as we have WP:CITEVAR. Having references moved to the References section is only one citation method. If you mean a way for references to be hidden within the text then I see no issue. The Grid (talk) 13:50, 3 February 2022 (UTC)
