Problem: The code editor currently tries to do too much, such as inserting an additional quote or bracket when you press a quote or bracket key, or delete an additional quote or bracket when you delete a quote or bracket. More often than not it guesses wrong and actually causes bugs by inserting things it shouldn’t have inserted and/or deleting things it shouldn’t have deleted. The coder would often stare at their code wondering why it doesn’t work before they realized it was the code editor that had corrupted their code.
Proposed solution: Add a button (or more) to allow the coder to selectively disable these automatic functions, such as autocomplete, auto-delete, and auto syntax checks.
Who would benefit: Wikipedians who write or edit Lua modules.
More comments: Currently coders have the option to disable the code editor entirely, but that is not ideal because line numbers and syntax highlighting are actually useful.
This can already be achieved by pressing Ctrl+, while the focus is inside the code editor and unchecking "Enable Behaviours". This settings panel is part of the Ace library, which underlies CodeEditor, and is not well integrated with the MediaWiki interface, but it is possible nonetheless. Nardog (talk) 05:49, 6 February 2023 (UTC)[reply]
Support TIL for me as well about the shortcut. Never knew about such a thing. I'd support adding a button to the toolbar as ESanders suggested — DaxServer (t · m · c) 20:05, 10 February 2023 (UTC)[reply]
Problem: In Visual Editor, a template within another template cannot be edited properly. Not only does the user get wikitext (which should not happen in Visual Editor), but it is also confined to a tiny field in the template editor window. Whenever the main part of a template has to be inside another template for technical reasons, this makes the template editor and TemplateData for that template useless.
Proposed solution: Nested templates should be detected and every single template should be editable using the template editor of Visual Editor.
Who would benefit: Users of Visual Editor.
More comments: I remember first discussing this at Wikimania 2017. Unfortunately, there seems to have been little progress on the matter.
Phabricator tickets: phab:T52355 (at least part of it)
Thanks for the wish, we would need to inquire how feasible this is for us as a team, I doubt it can be done in a quarter, but we could still move it to larger suggestions and track interest in terms of votes. I see lots of interest already in the phab ticket linked. Thoughts, User:ESanders (WMF)? KSiebert (WMF) (talk) 18:06, 25 January 2023 (UTC)[reply]
It certainly is very complex, and to be done properly would require changes to Parsoid to have the template parameters supplied as HTML. There may hackier approaches that sidestep this (I haven't thought about this problem in details for a while) but it would still be reasonably complex. ESanders (WMF) (talk) 18:33, 25 January 2023 (UTC)[reply]
It's easier said than done, as the hardest thing is to figure out how to do this. One possible way is to use VS editor on template parameters. Thingofme (talk) 03:55, 28 January 2023 (UTC)[reply]
Yeah, there have always been lots of ideas around this topic, but no idea has ever been seriously pursued, as far as I can tell. It is a bit frustrating that at this point in time (almost five years after the conversation I had at Wikimania 2017), on large pages like de:Elvis Presley/Diskografie Visual Editor is still basically useless and causes more harm than good. I was also repeatedly asking the Technical Wishes team at WMDE to work on this while they were improving the template editor, but it seemed too complex to them too.
Personally I clearly prefer nested templates to templates with unbalanced wikitext, but at this point the latter seems to be much better for the editing experience. I hope the solution won’t be to change all nested templates to multi-part templates.
Without having too much insight into the technical basis here, the most obvious solution to me seems to imitate the behaviour of the reference editor in VE. If I choose for adding/editing a reference manually in VE, I get a full wikitext editor with the option of adding a template, which will then open the template editor in a new window. If this works for references, why not for templates? And there can of course be a reasonable limit to nesting (even a maximum of 2 would already make things much better). I am happy to work closely with the team on this, but unfortunately I cannot do the development myself. XanonymusX (talk) 13:40, 29 January 2023 (UTC)[reply]
Voting
Support. I think the inability to use nested templates in VE is the main reason for me to constantly switch back to source editing. I would love to be able to add books to a bibliography for instance (which contains {{cite book}} in {{reflist}}). A very basic citation action that is nearly impossible to do. Femke (talk) 19:14, 10 February 2023 (UTC)[reply]
Support VisualEditor has a couple other issues that require switching back to Wikitext, which is bothersome, so I support its further development. KingisNitro (talk) 12:15, 11 February 2023 (UTC)[reply]
Support but not all parameters of all templates – some templates may have parameter that looks like wikitext but isn’t (e.g. SPARQL). I think this could be stored in TemplateData (e.g. load VE mode only for parameters that have content type). Tacsipacsi (talk) 14:09, 13 February 2023 (UTC)[reply]
Problem: It can be very difficult to find a template if you don't exactly remember its name
Proposed solution: To the template insertion wizard (which is currently empty upon opening) add a list with favorited and related templates. Once you use the searchbar, the searchresults will replace this list.
Who would benefit: Beginning editors who do not know the common template names (like infobox/navbox even), and experienced users who keep using the same templates over and over.
More comments: Templates could have an option to favorite them and these favorites would show up in a list in the initial dialog (a first version could maybe use your watchlist data for this, instead of a separate list). Ideally, it would also show you "Related templates", which are used on pages that share categories with your article. This is similar to how WikiData's recoin works.
@TheDJ: "...but I like my own description better, so..." With all do respect, that childish. It's not similar at all. What you're proposing is to favourite a template. That's not the same as easily adding infoboxes. That proposal is suggesting to auto suggest or have a button with a list of infoboxes. Nothing to do with favouriting. New editors wouldn't know the name of a template which in turn makes it hard for them to favourite it. But let's ignore that. Mr. C.C.Hey yo!I didn't do it!14:06, 12 February 2023 (UTC)[reply]
I'm not clear how this would help beginning editors. If they don't know the name of a template, how would they find it to favorite it? Libcub (talk) 07:06, 11 February 2023 (UTC)[reply]
It’s not about finding templates for the first time, it’s about re-finding them. As a beginner, one may spend half an hour finding the appropriate template – and if it doesn’t have an easy-to-remember name (what is easy-to-remember is subjective, so it may not be possible to find a name that’s easy to remember for everyone), one needs to spend this half hour the second, third and fifteenth time as well. This wish doesn’t solve the problem of the first half-hour search, but it does solve the ones of the subsequent ones. —Tacsipacsi (talk) 19:00, 13 February 2023 (UTC)[reply]
Voting
Support Yes, please. I use a handful of templates 99% of the time. Searching for them everytime I open the wizard is rather tiresome and would improve UX by a ton! — DaxServer (t · c) 19:57, 10 February 2023 (UTC)[reply]
Support I used to make thousands of edits (and even make templates), but now I'm not less often and have to search like almost a beginner for something I vaguely remember existing. Elf (talk) 22:33, 20 February 2023 (UTC)[reply]
Problem: There should be proper names for references possible in the VisualEditor
Proposed solution: Currently the VE utilizes only nonsensical :0, :1 or such als names for bundled references, not proper (<ref name="Me">), the authors have no say in this regard and have to correct this later in the source code to proper, human names. If such a proper name there could be used from the beginning, with the implementation of such a bundled reference, this would be of great help for all those, who would like to work later with the text.
Who would benefit: All authors, that work on articles, especially those, who use the wikitext editor
@Sänger: This was actually investigated in 2019 as part of Community Wishlist Survey 2019/Citations/VisualEditor: Allow references to be named. Unfortunately, it was determined that allowing a manual name to be provided for a reference was too complicated to implement, on top of concerns with usability, especially among new users. Imagine, as a new user, all you have to do is enter a URL into Citoid and you get a reference. It would be an odd thing to ask them to also provide a "name", even though this name isn't visible anywhere to VE users or readers. Regardless, we did determine that creating automatic names based on citation data (such as the domain or author name) is feasible.
Does this counter-proposal sound okay to you? You can learn more by reading our status update on that project. We hope that even though you won't be able to manually provide arbitrary names, that having automatic names like "example.org-0", "example.org-1", etc., is still better than ":0" and ":1". Let us know what you think, and thanks for participating in the survey. MusikAnimal (WMF) (talk) 18:10, 25 January 2023 (UTC)[reply]
Anything is better then the stupid ":0" and ":1", whoever came up with this non-solution was obviously not a Wikipedia content contributor, but someone restricted to technicalities. There is something mentioned about 2021, what happened that year? Grüße vom Sänger ♫(Reden)22:26, 25 January 2023 (UTC)[reply]
It was quite top of the list, but as absolutely nothing has happened in this regard, be prepared to get such wishes every year, until the lots of devs employed by the WMF, i.e. us, will finally fix this bug.
As a side note: Why is here an answer button (in the old nice layout with brackets and without screaming), but using it results in en error? Either it works, or it should be turned off. Grüße vom Sänger ♫(Reden)16:38, 26 January 2023 (UTC)[reply]
Agree with MusicAnimal that it would be better to continue automatic naming, but then in a more sensible way (author-last name + year, with fallback on editor/publisher/newpaper and no year). Can this wish be reworded? Or better to start a new wish? Femke (talk) 20:47, 26 January 2023 (UTC)[reply]
Imho this would be a solution for my wish. Whether you chose one yourself, of some software generates some better name automagically is secondary, we just need to get rid of those colons and numbers, they are a bug, not a feature.
So I don't know why I should change anything or write something new, as this is already an accepted solution. OK, really choosing the names would be even better, as authors are far better in such stuff then bots, but better 70% then stuck to the complete nonsense. Grüße vom Sänger ♫(Reden)05:12, 27 January 2023 (UTC)[reply]
You mean this one? I think, I forgot an interim i my last answer, as that's not far enough for my wish, it'll be just an interim solution, far better then the extremely annoying non-solution now at work, but not my wish. Grüße vom Sänger ♫(Reden)17:44, 30 January 2023 (UTC)[reply]
@Sänger We've got just one day to figure this out. Above you said the automatic (and sensible) names would satisfy your wish, but you're saying VisualEditor should use human-like names for references from last year, which proposes the same thing, doesn't go far enough for you. I think we simply re-title your wish as suggested, or even use the same proposal from last year, then we're good to go. Is that alright? It's even better if you're okay using the wish from last year, as I can copy over the translations as well. Let me know what you'd like to do and I can do all the editing for you :) Thanks! MusikAnimal (WMF) (talk) 21:42, 8 February 2023 (UTC)[reply]
As I've said: that would be a fine interim solution, but not my wish. It should be possible for the user to define a name, users are better in doing this, if they know, what they are doing. VE is fime for n00bs, that would do something wrong possibly, but giving the users a possibility to correct it is the far better solution.
Last years wish still stands, it was not worked on, so it's still a valid wish the devs at WMF should work on (and no, this is not just for the small amount of Comminty Tech devs, this is the community wishlist, all the devs of the WMF should work on this). Grüße vom Sänger ♫(Reden)21:55, 8 February 2023 (UTC)[reply]
I agree, and having talked with the Editing team it seems being able to add a custom reference name is doable, it just doesn't make much sense for a VisualEditor user, as they won't know what a "reference name" means because they don't see the wikitext. It adds another step to adding citations, something that we know is critical and should be easy for new users.
I'm going go with just re-titling to "VisualEditor should use human-like names for references" and leave the rest of your proposal as-is. Hope this okay, and thanks for participating in the survey! MusikAnimal (WMF) (talk) 22:02, 8 February 2023 (UTC)[reply]
Imagine, as a new user, all you have to do is enter a URL into Citoid and you get a reference. It would be an odd thing to ask them to also provide a "name", even though this name isn't visible anywhere to VE users or readers. What about asking for the name only when copying (re-using) the reference? --Matěj Suchánek (talk) 08:43, 20 February 2023 (UTC)[reply]
Absolutely. Even when pasting ie. "Smith01", a bug happens, and on the next instances it is pasted as "Smith02". #fatalFlaw.--A09 (talk) 22:26, 1 February 2023 (UTC)[reply]
@Sänger Okay, please don't move the page as that won't work as expected now that I approved the proposal. I can take care of renaming for you. Is "human-readable" okay? "Proper" sounds a bit ambiguous, but as long as we're not implying custom names as we were initially, it doesn't matter. MusikAnimal (WMF) (talk) 23:54, 8 February 2023 (UTC)[reply]
As for why "human-like", I just went with what was used last year. "Human-readable" is better but I think voters know what is meant by "human-like" (as in names that humans would create, not :0, :1, etc. that machines make). MusikAnimal (WMF) (talk) 23:55, 8 February 2023 (UTC)[reply]
Human-like is Ingrid, John, Laila, or such, at least for me as a human. Perhaps machines interpret something else in it, at least they can manage those completely nonsensical :1 etc, that someone obviously without any knowledge of Wikipedia editing invented. Grüße vom Sänger ♫(Reden)00:15, 9 February 2023 (UTC)[reply]
Is committed to solving this seems to be a wee bit exaggerated. Since 2017 they managed to invest millions in useless and completely unwanted projects like rebranding or FLOW, while this heavy bug is still not fixed. Grüße vom Sänger ♫(Reden)23:45, 10 February 2023 (UTC)[reply]
It's not s straw man, it's one of many examples, where the ivory tower burned lots of money against the communities while don't gibe any thought about real wishes. Grüße vom Sänger ♫(Reden)12:38, 20 February 2023 (UTC)[reply]
Support Literally just implement it so that the parts of VisualEditor codebase can be cleaned up. Worked with it myself and it's an utter nightmare. Lectrician1 (talk) 22:42, 10 February 2023 (UTC)[reply]
Support Better automatic refnames should have been there at launch, manually editable refnames a nice addition on top of that. CMD (talk) 03:02, 13 February 2023 (UTC)[reply]
Problem: I've used the "Preview page with this template" many times and wondered why my changes weren't being applied, only to realize e.g. I was editing the sandbox and the page was using the live version.
Proposed solution: If the specified page does not transclude the template, the server will return an error instead of the unaltered version of the page. Similarly, the autocomplete feature of the textbox only suggests pages that transclude the template.
Who would benefit: Template editors
More comments: The autocomplete improvement is difficult with the currently available APIs, except in extremely inefficient ways (see T279736#7142483).
I respectfully disagree and believe that to be entirely different. Creating a page and editing a page are two different things. The only thing in common is the sandbox, so they're only in the same category so to speak, but not similar. Magnoliasouth (talk) 22:56, 10 February 2023 (UTC)[reply]
It would be better if it asked if you want to replace the template with the sandbox version, when you preview the sandbox (template/sandbox) on an article which includes the production template. MarMi wiki (talk) 20:18, 10 February 2023 (UTC)[reply]
@MarMi wiki and Certes: I don't think you've understood the problem. The sandbox vs live thing is just an example. The problem is that the server returns the unaltered version of the page before checking if it transcludes the template in the first place. Nardog (talk) 22:51, 10 February 2023 (UTC)[reply]
Either solution would work for the sandbox example. There are places where your proposal would work but mine wouldn't, and vice versa. I'd support them both. Certes (talk) 23:07, 10 February 2023 (UTC)[reply]
So you want the server to constantly monitor and filter out the pages? This could be more resource consuming than sending entire page and checking it on demand. Or not. MarMi wiki (talk) 00:01, 11 February 2023 (UTC)[reply]
No, the server can check if the page transcludes the template only after the form is submitted, then output an error instead of the unaltered version. Nardog (talk) 00:09, 11 February 2023 (UTC)[reply]
Problem: Currently, every user has a sandox (Special:MyPage/sandbox) when creating an account from Wikipedia. However, when you edit it, it appears in the user's contributed list (Special:Contributions). This is a problem for users working on featured articles, as some users may steal content from those issues, pasting all of that person's work into this article before the project is ready.
Proposed solution: Create a private sandbox for the user to develop their editorial work without appearing in the list of contributions.
Who would benefit: Everyone would benefit, as it would be a private space, where no one could know how that user is using his private sandbox, in addition to being the only place where he could edit as many times as he wanted without counting his edits, being able to click several times on the "publish changes", but which would only be available to the user. This will prevent content theft by this account.
More comments: With the approval of this proposal, it will be implemented in all global Wikipedias.
ONE of many places where I have tested Good idea. Create also a private sandbox for new versions of templates and modules, that would be completely invisible to other users, and could be irrecoverably deleted when testing work is done. And do this for all wikis of course, not only wikipedia. But this is a difficult task. Taylor 49 (talk) 16:57, 3 February 2023 (UTC)[reply]
@Taylor 49 If it can be applied to all wiki projects, great. I highlighted Wikipedia because it is an encyclopedia, so it would require a private space to develop perfect articles. WikiFermsg17:09, 3 February 2023 (UTC)[reply]
@Tgr I believe it is necessary to limit the storage time that the privacy sandbox holds user content for 1 week, 15 days or 1 month, for example. WikiFermsg12:50, 5 February 2023 (UTC)[reply]
That's not really the issue, it can still be used to share illegal content etc. OTOH ContentTranslation already lets you store drafts so maybe storing drafts in one more place wouldn't make much difference at this point... Tgr (talk) 20:35, 5 February 2023 (UTC)[reply]
@Tgr ContentTranslation it's just an example of how it's possible to create a private space without anyone having access, since it's just a space for translating articles into other languages, not for developing a project where the content can be in the same language as the project. Regarding the alleged “illegal content”, it is enough to allow CheckUsers to view the private sandbox, as long as there is evidence that justifies a check, as they cannot violate the privacy policy. WikiFermsg21:10, 5 February 2023 (UTC)[reply]
@WikiFer:, you don't need a private sandbox to do anything. Common sense dictates, if you don't want people seeing it, you shouldn't be doing it. Also, it's not just illegal content. It's also WP:OWN and WP:NOTAWEBHOST.
At the risk of WP:BEANS, any registered user can privately store arbitrary data in user preferences (though I'm sure there's a cap). There is in fact a user script taking advantage of this to allow a private sandbox (by SD0001), but a drawback is that the server has to send the data on every page you visit while logged in so you get slower page load. Nardog (talk) 11:44, 6 February 2023 (UTC)[reply]
Well, maybe: "server-side data storage can be shared between multiple users by sharing account credentials, and that can be used for all kinds of illegal activities". What illegal activities can be promoted by storing just plain text? I do not think that this is a BIG problem. It can be reduced by:
limiting the time of storage (say 3 days)
allowing sysops and other privileged users to inspect the private sandboxes
Devils advocate: you can abuse WMF wikis to transmit any potentially illegal data anyway. Just hide it in a large image or audio file and upload that file to Commons. The file will remain forever, or at least for a week, sufficient to commit your organized crime. IMHO the objection "can be used for all kinds of illegal activities" is invalid. Taylor 49 (talk) 10:34, 5 February 2023 (UTC)[reply]
That does in fact happen, see e.g. here or here. But as long as it's happening in the open, the community is reasonably well-equipped to do something about it. If it's happening via data no one but the sharing "role account" can see, that problem lands with the developers/sysops who have much less capacity to deal with it. Tgr (talk) 20:44, 5 February 2023 (UTC)[reply]
Well, thank you for sharing that. Obviously, the private sandbox should have some sane restrictions:
only plain text
limited size (say up to 4 pages and totally 1 Mi)
limiting the time of storage (say 3 days)
allowing sysops and other privileged users to inspect the private sandboxes
limiting the feature to "good users" (some time since registration, valid email address, good contributions on some wiki) and maybe enable only upon request (similarly to "rollback" or "file mover" rights)
@Taylor 49, "limiting to good users." Is that supposed to be a joke? Common sense dictates, if they don't want people seeing it, they shouldn't be doing it. The cons (listed in the votes) outweighs these so-called pros. Plus, it's redundant to have a private sandbox if certain people have access to it. Mr. C.C.Hey yo!I didn't do it!09:43, 11 February 2023 (UTC)[reply]
Comment The Extension:ContentTranslation allows users to work on translating an article without anyone having access to the content they are translating. Therefore, I believe the MediaWiki developers could develop a similar platform for a private sandbox. WikiFermsg13:35, 5 February 2023 (UTC)[reply]
Voting
Support There should be, in my opinion, some area of Wikipedia to test things out that is NOT visible to anyone else, including admin. If no one else could see it, then I (as a regular, high-volume, recent changes patroller) do not see what possible harm could be done. This "private" feature should only exist as a sandbox, but should exist as an option. Moops (talk) 20:01, 10 February 2023 (UTC)[reply]
@Moops, common sense dictates, if they don't want people seeing it, they shouldn't be doing it. Plus, the fact you don't see the harm as a recent change patroller says a lot. See the various comments with SHB2000 and Blaze Wolf's votes. This will never be a thing. Mr. C.C.Hey yo!I didn't do it!09:37, 11 February 2023 (UTC)[reply]
Strong oppose Couldn't you do the same thing off-wiki? Having a private sandbox that cannot be seen from anyone would just make it a haven for users who use their sandbox as their personal web host, which can also be used to host illegal content, and there's also no way of knowing if someone mass-pasted copyvios into this "private" sandbox. The downsides outweigh the minimal benefits of this proposal. --SHB2000 (talk | contribs)22:42, 10 February 2023 (UTC)[reply]
@User:SHB2000 Theoretically YES, in practice NO. It is extremely difficult to install a private wiki with ca 1'000 extensions and a reasonably same configuration as WMF wikis (svwikt). It is difficult and causes disruption to test large template and module changes involving several pages. The sandbox would be limited to plain text and a sane size (say 2 Mi totally) making it useless as a "personal web host" or "piracy spot". Also, some users contribute from public computers where local storage is not available. Taylor 49 (talk) 04:02, 14 February 2023 (UTC)[reply]
Strong oppose If the user did not set one up, that means that they do not want one and would not read it. I think their pages are their pages and not other users pages. I understand the dilemma but cannot vote for this. I'm sorry. Magnoliasouth (talk) 23:03, 10 February 2023 (UTC)[reply]
Strong oppose There are way to many issues with this, including the potential to add copyvios, illegal content, and various other things. This would also go against en:WP:OWN which states that no user owns any page on Wikipedia. ― Blaze WolfTalkBlaze Wolf#654523:25, 10 February 2023 (UTC)[reply]
Strong oppose There is no good reason to allow this, it has been said clearly : "if they don't want people seeing it, they shouldn't be doing it". It just makes harder or impossible some verifications, which makes no sense on communitary website like Wikipedia and such. CaféBuzz (talk) 10:17, 11 February 2023 (UTC)[reply]
Strong oppose per everyone above. This is opposite to the spirit and the principles of Wikipedia. If a user ever wants to keep some content private before publishing and releasing it with a Creative Commons license, they should use a different editor. Lion-hearted85 (talk) 11:27, 11 February 2023 (UTC)[reply]
Oppose per WP:NOWEBHOST. Just save your drafts locally with any word processor or available apps if you are concerned about this. And if this happens just take the content dispute to an appropriate discussion board. Terasail[✉️]17:12, 11 February 2023 (UTC)[reply]
Oppose My immediate reaction was that this violates multiple policies, if not directly, then at least in spirit. I am reassured to see that so many others agree. Toadspike (talk) 22:34, 11 February 2023 (UTC)[reply]
Oppose pile-on, we should not have private storage server-side per lots and lots of the above. Possible incorporate this to the mobile client, but store it client-side. — xaosfluxTalk15:08, 12 February 2023 (UTC)[reply]
Neutral This idea can benefit people who want to test things privately, but this idea can also go against core principles of Wikipedia. NPRB (talk) 21:08, 13 February 2023 (UTC)[reply]
StrongSupport - I oftentimes want to be testing out new template code, phrasing sentences, notes about sites I'm writing about, etc., and am self-conscious about seeing these messy notes and things done perhaps incorrectly to be in public view and on permanent record. And no, I can't just use a word processor; enwiki has so much more functionality, formatting, scripts, links, templates, etc. that MS Word will never have. Ɱ (talk) 02:37, 14 February 2023 (UTC)[reply]
StrongOppose Seeing as this proposal has many potentially negative uses, such as: Copyright violations, hosting of illegal content, even potentially providing a space where cyber-attacks directed at Wikipedia could be tested on the site itself without repercussions, I believe that (and I am surprised that no-one has brought this up), that this entire proposal is simply a [1]WP:BADIDEA. SpacedShark (talk) 06:00, 14 February 2023 (UTC)[reply]
Oppose This feature would be massively used by spammers, pornographers and copyviolators to create non-encyclopedic content. Taivo (talk) 14:59, 14 February 2023 (UTC)[reply]
Support Currently it’s very difficult to do test changes that involve a lot of things (articles, templates and modules) without polluting Recent Changes and category pages. Especially with the recent change to list category changes in Recent Changes. Some bugs (in templates and modules) never get fixed because it’s impossible to test things. Either this or (ideally) devs need to think more like users (what we call “empathy” in design. From my interactions with Wikimedia tech our devs have zero empathy). Al12si (talk) 03:23, 18 February 2023 (UTC)[reply]
Oppose I oppose this idea wholly unless an agreement can be found where only admins can see the page and not regular users. This cuts off a large portion of Wikipedia whilst also allowing moderation and checking for non-encylopedic stuff. 56independent (talk) 11:20, 18 February 2023 (UTC)[reply]
Support With restrictions: Limited duration, limited size, accessible to admins, by request only, extended confirmed or equivalent required, other precautions. May not be worth the development time, however. Constant314 (talk) 17:46, 19 February 2023 (UTC)[reply]
Support An interesting idea, which if implemented simply would be very successful.
You should look at this as an unsaved preview page. A page in the special namespace that can be edited visually or in wiki syntax, and will allow the result to be previewed, without being able to publish anything. —מקף⁻ණ (Hyphen)23:48, 20 February 2023 (UTC)[reply]
Problem: Galleries contribute significant information to articles and are a great way to illustrate the breadth of a topic. However, their captions are significantly more difficult to edit in the Visual Editor than those of individual images. Individual images' captions can be clicked and edited while still viewing the article. In contrast, gallery captions require the editor to double-click to pop up the gallery, navigate to the specific image, and add the caption, then Apply Changes and exit. This requires significantly more steps. The current process does not streamline the process and may alienate newer editors.
Proposed solution: Allow gallery captions to be editable while editors are viewing the full page.
Who would benefit: Editors who wish to display multiple images, particularly those creating articles about cultural festivals, painters, and the arts. This would save time incrementally and expedite the creation of galleries.
More comments: Thank you very much for your consideration.
Support I'd think this is (in 2023) expected behavior, even if the click only opens up the existing modal window focused on the clicked image ponor (talk) 10:54, 13 February 2023 (UTC)[reply]
It’s a wizard, I don’t want to set such basic things every time I use a particular template. Instead, this information should be in TemplateData, probably three-valued: the template SHOULD NOT be substituted (default) / SHOULD be substituted / MAY be substituted (then show the checkbox). —Tacsipacsi (talk) 18:47, 13 February 2023 (UTC)[reply]
Since this wish is about the Template Wizard, which works in the wikitext editor, I wouldn’t display the checkbox for SHOULD/SHOULD NOT templates – if one wants to substitute a template which is not designed to be substituted (or wants not to substitute one that’s designed to be always substituted), they’ll still have the option to add/remove the prefix after closing the wizard, just like today. So it’s a MUST before closing the wizard, but it’s a SHOULD before saving the edit. (If it was about the VisualEditor template editor, that would be a different matter, as VE doesn’t allow toggling the prefix outside of the wizard.) —Tacsipacsi (talk) 00:43, 25 February 2023 (UTC)[reply]
I discussed this above with collaborative editing. I wonder if there could be something like Google Docs where you can see another editor in the document making changes. If we could see the changes made by each editor, that'd be great! This is especially useful for working with current events and/or doing large edits when someone comes in, makes a small change, and leaves. Significa liberdade (talk) 21:49, 10 February 2023 (UTC)[reply]
This is also like collaborative editing like in Google Docs where we can see other editors making edits together and may be more like social media when we can see other users are typing their edits. Thingofme (talk) 15:56, 11 February 2023 (UTC)[reply]
Answer to Libcub, this is just a simple alert to let you know that the article is being modified. this alert should not prevent another editor from making changes. Elilopes (talk) 14:54, 13 February 2023 (UTC)[reply]
Yes. That's why I said "intimidate or exhaust" not "prevent". I think taking care in the wording of the alert could help ameliorate the issue. Libcub (talk) 03:09, 14 February 2023 (UTC)[reply]
Support Seems like a good idea to me. It is so annoying when you go hit "publish" and there is an edit conflict! Why not just know about it before you hit that button and save yourself a small amount of grief? :) Moops (talk) 20:03, 10 February 2023 (UTC)[reply]
Oppose, probably. How would we define "being edited"--clicking the Edit or Edit source button, clicking that and typing something, clicking Edit and then typing something else within some timeframe (15 seconds, a minute, 30 minutes)? Also, I am concerned that this could be abused. A problem editor may keep the page or section in almost permanent "being edited" mode to intimidate or exhaust less experienced editors into not editing that page or section. Libcub (talk) 06:38, 11 February 2023 (UTC)[reply]
I would probably be responsible for that without even realising. Quite often I'd hit edit, make some changes, get distracted by something and move to another tab where I'd start editing something new without finishing and publishing the original edit. Mesidast (talk) 10:15, 20 February 2023 (UTC)[reply]
Support It's only happened once (luckily) since I work on less popular pages but it's so frustrating of you lose an edit because someone fixed a spelling mistake. I do think it needs limits though based on the oppose below. Potentially a certain number of (unreverted?) edits to gain access? Maybe it could be investigated if the same person is editing after a certain amount of time and someone else wants access through a popup. And if someone is found to be abusing it (should be obvious from the edit logs), there should be a ban system in place. Obviously it's impossible to get around all the issues, but I do think some variation of this would be very valuable. OddBiologist (talk) 21:39, 11 February 2023 (UTC)[reply]
Support Although I think it would be more annoying to wait until the other user it's done, and the solution should be more complex than a solid message (more like a warning that informs of a part of the article to the user before he edits). De un millón (talk) 23:06, 15 February 2023 (UTC)[reply]
Oppose Might be misused to block articles and then complain if they're edited ("didn't you see I was editing?") or the waiting person might complain if one takes too long and just the knowledge that someone might be waiting could be a little stressful, also some could intentionally cause conflicting edits (how to prove?). Otherwise useful, but I'm not convinced it would lead to less annoyances, probably just different ones. In Google Docs style shared editing I also wonder how that would work if the other person is a vandal. How would you be able to report someone for something that's not published? So unpublished editing would have to be stored at least temporarily as soon as more than one person is involved. There should also be some kind of parallel chat then to coordinate and shared editing should also only be available to users with an account to avoid vandalism problems. --Lupe (talk) 11:31, 20 February 2023 (UTC)[reply]
Support Yes, merging manually conflicting edits is hell. Contributors are here to disseminate free knowledge, not fix technical issues. Juandev (talk) 10:44, 23 February 2023 (UTC)[reply]
Support IMHO easier to solve _and_ more useful than real time collaborative editing: In collaborative editing, you cannot anticipate what the other is going to do next, i.e. whether both changes are semantically inconsistent / conflicting – and most of the times in most of the MediaWiki-installations I do use, I can easily wait for the other user to finish his/her work and then start on a solid base. Schoschi (talk) 18:03, 23 February 2023 (UTC)[reply]
Problem: I'm looking to improve the formatting of actuarial notation on Wikimedia sites. The most important bit that is missing from the current capabilities is the angle notation used to denote a period of years (but there are other features of the notation which are also difficult to implement). In the example image to the right, it's the angle over the 'n' that is marked as '3'.
Our current workaround is to use a separate horizontal and vertical line, thus: . But it's a poor workaround, as you can see.
Proposed solution: There is a TeX extension that provides all the required functionality for actuarial notation: actuarialsymbol. Adding this (or a similar equivalent package) to the Wikimedia installation solves the problem.
Who would benefit: Users reading and writing about actuarial mathematics.
Support The only proposal which has anything to do with mathematics. (I was looking for a proposal, which enables mathimatical operations in a Wiki table. I haven't found one. This was the closest. Therefore I wote on it.) Editor Pirate (talk) 10:11, 12 February 2023 (UTC)[reply]
Problem: When making larger edits, and in particular writing new articles, there is a possibility of data loss (possibly a few hours worth) due to:
a power outage,
a browser crash,
a network outage (if one chooses to preview their changes while network is temporarily offline),
accidental browser closure.
It is a fairly standard feature in modern software to auto-save user edits to guard against such incidents. Auto-saving is ubiquitous in cloud-based software, where it has the added (or perhaps main) benefit of allowing the user not to think about saving their work/to carry on working on the same document in multiple sittings/across multiple devices. (This would arguably be desirable to have on Wiki in its own right.) "Offline" software also often has an auto-save feature, though generally for crash recovery only (e.g. LibreOffice).
The code editor does not currently provide any kind of auto-save functionality, while the Visual Editor appears to have some sort of auto-save implemented, or so I gather based on phab:T57370 (I do not normally use Visual Editor, so cannot tell whether it is indeed present; if it is, then it appears to be both undocumented and hidden, with no indication in the UI that anything is being saved - so almost as good as if it wasn't there at all).
Some workarounds that users, especially those who have experienced data loss in the past, are likely to employ include:
periodically copying their work from the Wiki editor to an external program (e.g. Notepad) and saving it locally;
writing whole articles in an external program and only copying them into a Wiki editor once ready;
writing their article in their sandbox and saving regularly.
Each of these is inconvenient/time-consuming/decreases productivity.
Proposed solution: A reliable auto-save functionality which regularly saves user edits in the background, which works both in the code editor and the Visual Editor, which allows these edits to be restored in the 4 cases listed above.
Desirable:
An indicator in the UI of the editor which tells the user if or when the page they are editing was last saved - to reassure them that auto-save is indeed present and functioning, and thus they do not need to resort to any of the workarounds mentioned above.
Saving these edits online (to Wiki servers), so as to allow the user to carry on working on one page in multiple sittings/across multiple devices. (Just to clarify: until published by the user, these edits should remain private and not visible to anyone else than the user in question).
Who would benefit: All editors, but in particular:
those who write larger articles, and two groups which, I believe, Wikimedia is particularly keen to recruit/retain:
new editors, who are likely to be particularly discouraged if their hard work is lost,
editors in countries, where power outages/"load shedding" occur frequently, which are disproportionally likely to be in the Global South (such as India or South Africa, if media reports are to be believed).
This already exists in the visual editor and 2017 wikitext editor, as a client-side only feature. Clearly it's not obvious though! The part of the request to extend this to the 2010 wikitext editor seems reasonable. Saving private drafts to the server is a really huge legal problem for obvious reasons. Jdforrester (WMF) (talk) 18:10, 25 January 2023 (UTC)[reply]
But it doesn't work (at least for me) when browser crashes or on power outage. It only seems to remember small changes, mostly when you don't need them - additionally you can't deny them, because they're automatically restored. Some more reliable process should be developed, even a manual one. MarMi wiki (talk) 20:32, 10 February 2023 (UTC)[reply]
I think that the major changes we could make to the existing autosave (without talk-to-Legal repercussions) are to add UI so it's more user-visible that it's happening, and to make it more durable -- it's currently in SessionStorage (which means it's great for the "oops I reloaded the tab / navigated-away / my browser crashed" cases but not for anything where you later come back in a different tab), which we picked because it mostly avoids us having to care about the many limits on LocalStorage. However, the new mw.storage API got added very-recently and automates this sort of expiry-needed case which might make it more appealing to use for us.... Adding it to WikiEditor is of course doable, albeit as an entirely separate implementation. Promoting 2017 out of beta (even without changing any defaults) would be another way to make this more accessible with minimal changes needed...DLynch (WMF) (talk) 19:05, 25 January 2023 (UTC)[reply]
@Czar I don't know for sure, but it sounds like you might have a browser config/extension set that is clearing your local storage (inside your browser), which is where the draft is saved. There's no MW/VE preference involved. On the second point, I can't speak for the Editing team's planning, sorry! I imagine things will be clearer around what each team are doing once the Foundation's annual planning process is complete. Jdforrester (WMF) (talk) 17:08, 30 January 2023 (UTC)[reply]
We have recently merged a patch to move to LocalStorage for DiscussionTools' reply tool which will be an improvement. The problem for doing this in full document edits is we have to store the original document state (to avoid data-parsoid corruption) which could be several hundred kb. Multiply this by a few edit sessions and you could quickly overwhelm the low limits on LocalStorage (a few mb). If we could find another way to reliably stash the initial document state, this would be fairly trivial to switch over to. ESanders (WMF) (talk) 12:33, 26 January 2023 (UTC)[reply]
Also note that LocalStorage is used for caching ResourceLoader modules (ie. CSS/JS). Given it usually has low quotas (5MB or such, and even that might be shared between sites with the same parent domain), storing article drafts there would reduce the amount of CSS/JS that gets cached, and potentially hurt site performance. Tgr (talk) 00:19, 5 February 2023 (UTC)[reply]
I noticed a clear improvement on Discussions. Chrome can suspend a tab, or I can open the same talk page in a new tab, and my reply will be there in the edit box. Extremely nice. DFlhb (talk) 00:24, 5 February 2023 (UTC)[reply]
I don't think the reasons for not wanting to do that on the server side are all that obvious, so it might be worth spelling (one of?) them out: server-side data storage can be shared between multiple users by sharing account credentials, and that can be used for all kinds of illegal activities. This has happened in the past with similar features. Tgr (talk) 00:22, 5 February 2023 (UTC)[reply]
I had a Safari crash which lost me hours of editing, with the Visual Editor; it's still not bullet-proof enough. If you can figure out how to get around LocalStorage restrictions, that'd be really great. I still feel the need to constantly copy-paste things into text files, even with the Visual Editor. DFlhb (talk) 00:27, 5 February 2023 (UTC)[reply]
This seems like a reasonable proposal. A concern I have for implementation is that we make it VERY clear to editors that this is not for storing drafts of pages/sections. We don't want a new editor work on a section over a period of several days, then try to publish it, only to find out there was an edit conflict. Perhaps delete the auto-saved text after a certain length of time (and inform the editor of such). Libcub (talk) 06:54, 11 February 2023 (UTC)[reply]
Support Absolutely! I've had many instances where my browser freezes during a long edit and/or the page won't submit for whatever reason due to timing out. The auto-saved regularly doesn't work. Significa liberdade (talk) 21:38, 10 February 2023 (UTC)[reply]
Oppose WMF needs to stop working on the 2010 Wikitext editor and finally replace it with the 2017 Wikitext editor (where this feature is already supported) as they intended they were going to do. A feature should not be sitting in Beta this long. Maintaining 2 different editors at the same time is a nonsensical waste of resources. Lectrician1 (talk) 22:47, 10 February 2023 (UTC)[reply]
Strong oppose anything about that part that wants to create a server-side "private storage" location for individual editors. See also the huge oppose to such regarding sandboxes in a related wish. Improving this with mobile-client as client-side, and/or client-side with VE etc - sure, go for it. — xaosfluxTalk15:12, 12 February 2023 (UTC)[reply]
Support Most Wikipedia users have asked me this, and I have no concrete answer yet. Right now, this can only be done using a user script. This would be very convenient for users who use source mode if this feature is available. ···🌸Rachmat04·☕10:05, 14 February 2023 (UTC)[reply]
Oppose. If you want to auto-save, just save it! If you are afraid of browser freezing (like happened a lot with me), then work with local text file in your computer like me, save it as often as you like in your local computer and then copy-paste it into Wikipedia. Taivo (talk) 14:52, 14 February 2023 (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: 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 next to the dropdowns which are availabe when ticking the "Add two new dropdown boxes below the edit summary box with some useful default summaries" box under Preferences > Editing.
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: In en.wiki, there is now an option to tick "Add two new dropdown boxes below the edit summary box with some useful default summaries" box under Preferences > Editing, which is helpful for common use. This particular proposal is to extend that functionality with user-specific edit summaries. Examples of edit summaries include: "new stub, passes <some policy>, point 3" or "changed formatting of number, see <some policy>". This proposal has been adapted from Community Wishlist Survey 2022/Editing/Custom edit summaries per user
This has been adapted from a 2022 proposal (2022 Community Wishlist Survey); I have created it again for the Community Wishlist Survey 2023 as I believe it should be part of the software, easily available for technical and non-technical users (as opposed to user scripts). Simeon (talk) 18:32, 23 January 2023 (UTC)[reply]
That drop-down for years have no function to edit its contents - make one mistake typing some edit summary wrong and you will be stuck with in in dropdown forever, because its contents is stored on the server side and user have no control over its contents. What's worse, the mistyped values will often displace good ones out of the limited pool of suggestions that dropdown shows, rendering the whole thing useless, making the user retype nearly the whole edit summary every time before a correct suggestion appears in the dropdown. So no, drop-down is not a solution, not in its current dysfunctional form. I will vote for the present proposal as at least it will allow me to never use that dropdown again and stop retyping edit summaries every time Nyq (talk) 07:46, 18 February 2023 (UTC)[reply]
Assuming it's accurate for me to understand this wish as wanting to make it easier for people publishing edits to accompany them with edit summaries that other volunteers and their future selves find useful, I wonder if it's worth considering T54174 as a potential solution in this context. T54174 describes a future where the edit summary input is more feature-rich and could support things like: auto-complete for other peoples' usernames, linking to specific pages, links to diffs, etc. Stussll (talk) 00:29, 24 January 2023 (UTC)[reply]
If you have autofill enabled on your browser, that shouldn't be an issue. It's not for me since I have it enabled. That's something you should considered turning on. Mr. C.C.Hey yo!I didn't do it!10:17, 11 February 2023 (UTC)[reply]
Support Fully support, this is long overdue solution proposal for the problem that many of us heave been complaining about for years Nyq (talk) 09:07, 18 February 2023 (UTC)[reply]
Support I would find this very useful as i frequently fix speling erors as part of my wikiGnome activities. These often require repetitive edit messages. 56independent (talk) 11:27, 18 February 2023 (UTC)[reply]
Problem: The new talk-page reply/new section tool introduced a year ago took some getting used to at first, but now I can't imagine Wikimedia wikis without it. It has, for one, vastly eliminated the need to go back and correct typos that resulted in redlinks. Nonetheless I have found two ways in which it could bear improvement:
The default to the normal four-tilde signature. There are times (such as when issuing a level-1 warning, where the newer syntax automatically includes my name) where I'd rather end with the five-tilde sig (just the date and time). There are also times (like when filing a case at WP:3O) where editors are required to use the three-tilde version (unlinked username, date and time). Yet in order to do that with this gadget, it is necessary to go back in and edit the result manually after saving ... if you type in the three or five tildes, the result is added in addition to your signature.
The lack of an option (unless it's there and I don't know about it) to add an edit summary. In a potentially contentious discussion, I'd like to know more about what the other person is saying to me if I see in the history that they've made some 4-digit, bolded-green response before I actually read it (Though I could see this non-feature's utility in keeping people from writing hostile, insulting edit summaries, I think it's better that we let people by default write edit summaries; were we to add this feature it wouldn't be too hard to make it something that could be turned off for those who use it abusively).This is already possible
Proposed solution: Make it possible to override the default sig when the editor manually types in just three, or five, tildes. And add a bar to write in an edit summary if the user desires.
@DWalden (WMF): Shouldn't the summary part removed from the proposal? Also the title is not clear as to whether this is a wish for more functionality in the reply tool in general, or more specific. For example, I could use an ability to edit a comment I already made, but it is not clear whether that's covered by this wish (the body suggests not). Nardog (talk) 11:52, 6 February 2023 (UTC)[reply]
Invalid. This should not have made it to phase 3. The title is pretty broad yet the body is about two very specific requests, one of which is already possible. Clarify the scope or archive it. Nardog (talk) 18:02, 10 February 2023 (UTC)[reply]
Easily add page numbers with "cite" automatic button for books and then easily "reuse" listed book references with/without new page number(s) if needed.
Problem: Adding book references is more difficult than adding press articles with an url in Wikipedia's articles with the "cite" button.
Proposed solution: Why ? It is best described with an example :
Use the "Cite" button ; add the ISBN of a book ; click generate (until there it is working fine!) ;
But now you can't add the page number(s) of the book (*) ! This must be available easily for the average user. After that, all the things can be automated by code!
Bonus: once you have added the book in the References section, you should be able to use the Cite button/reuse to reuse the book with the same page number or not!
Voila! No need to use complex templates (create sfn template with anchors,...).
edit: (*) For ebooks, we could use chapter number and/or start/end of the relevant citation.
Thanks for suggesting this. I too get a big headache when I use books rather than websites specifically because I can't easily place page numbers! I usually use Google Books and Visual Editor. When I paste the link into the auto-cite, I too wish it automatically detected the page number, as it's included in the URL. The ability to copy-paste the same reference but only change the pages would be helpful too. I appreciate your wish as it would help virtually all editors and hope this gets the attention it deserves. Evedawn99 (talk) 15:07, 1 February 2023 (UTC)[reply]
@Matěj Suchánek Thanks for pointing these existing suggestions that I haven't seen before. They are right to the point (Thanks User:Femke). By reading them, apparently, these kinds of suggestions were already made several times over the previous years! The answers of the coding teams are always, it seems, along the following : 1) not a priority as not enough people vote for them in the International Community Wishlist request (maybe only with some regional one, like DE-wiki that uses the Visual Editor by default)! 2) Technically, it is difficult to do in visual editor!
Hi, @Jurbop! Thanks for thinking of Web2Cit to help address this. However, I think its usefulness in this case would be very limited.
Visual Editor's automatic citations are generated based on Citoid response to a URL, ISBN, or other unique identifiers. Web2Cit is used to collaboratively improve Citoid responses to URLs.
Currently Web2Cit supports a limited set of citation fields, not including page numbers. Adding page number support to Web2Cit would be possible; this has already been proposed in T321669. However this would be useful in cases where page number(s) can be inferred from the URL or from the corresponding target webpage's content. That is, it should always return the same page number(s) for the same URL. For other cases it would still be useful to have a prompt to add page number(s), as suggested in T216817. Either case, as I see it, Web2Cit would not be useful to "reuse book references with/without page number(s)" either. Diegodlh (talk) 18:07, 13 February 2023 (UTC)[reply]
Support Not being able to reuse book citations with different page numbers NOR being able to add books to a bibliography (nested templates) is the biggest VE weakness imo. Femke (talk) 19:16, 10 February 2023 (UTC)[reply]
Problem: On enwiki, we have a months-long backlog of COI edit requests. I don't really look at them anymore, because (of those that would be acceptable) many of them are frustratingly vague but not quite decline-worthy, many of them are incredibly long multi-part requests, and for the rest the process is frustratingly manual: copy the proposed text, go find the place in the article where it should be, make the edit, go copy the requester's username, write an edit summary attributing it to them, save, go back to the talk page, and mark the request as done (for which you can't even use the reply button because you need to also flip the 'answered' bit in the original request template). Many requests are declined with the {{ECOI|xy}} template ("Not done for now: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format.").
I've dealt with a few COI editors who noticed how big this backlog was and were hesitant to submit totally reasonable changes. I assume some large percentage of them are fully discouraged, and either don't submit their request or just disregard the policy and edit the page anyway.
Proposed solution: Allow editors to mark their own edits as needing review, in a similar manner to how Pending Changes works. This is like minor edits but in the other direction, and could be presented in the same way.
This forces the submitter to specify exactly what edit they want made, gives us correct attribution automatically (because the edit was submitted by the author, not the reviewer), and gives the reviewer a diff to easily review the change in context.
Who would benefit: Editors who submit COI edit requests, and those involved in responding to them. (I think the encyclopedia can benefit from well-behaved COI editors, because those are often the people most willing to put in the effort to keep an article up to date. The current process does not encourage them to be well-behaved.)
Secondarily, I've occasionally found myself considering fixing what looks like an error in an article, but not confident enough in my own understanding of the subject to be sure I'm not introducing an error. I can see occasional non-COI uses for an "I think this is right, but someone who knows more should verify this" checkbox, in a code review sort of way. Currently, the best we have is to post on the talk page and hope someone sees it within the next 6 months.
More comments: I leave it open to discussion who should be able to review the edits. The existing pending changes reviewers seem like a reasonable choice, as do any of the *confirmed groups. (This is probably per-wiki configuration anyway.)
I haven't the slighest idea how this wound up in mobile and apps, and I don't appear to have page move permissions on meta. Would someone move it over to Editing, please? 3mi1y (talk) 02:42, 25 January 2023 (UTC)[reply]
Logically if we were going to code a way to make this voluntary, we should have it as something we can place on a user, so communities can consider it as an alternative to TBANs in certain cases. Nosebagbear (talk) 13:36, 1 February 2023 (UTC)[reply]
I like this idea conceptually, but how would it work practically? "Topic" in the broad sense meant by a TBAN isn't really a thing the software knows about. The closest approximation I can think of is categories. 3mi1y (talk) 09:00, 5 February 2023 (UTC)[reply]
The key thing to understand about the Pending Changes system is that essentially it lets you manage a "last reliable revision" pointer within the page history. All edits made to a page that has any pending edits will themselves become pending, regardless of who made them. So between the time the pending edit is made and the time it is reiewed, the page is effectively "frozen" for all anonymous readers. That makes the labeling of changes as pending (voluntarily or otherwise) very disruptive, and also opens up all kinds of trolling opportunities (e.g. make a controverisal change to some page that's in the news cycle, then make a good but hard-to-review pending edit to it). --Tgr (talk) 00:34, 5 February 2023 (UTC)[reply]
This one reminds me of phab:T113004. Which would be a lot of work. And anyway, getting these people to opt in to a selection probably isn't going to work from the UX side (who hits the minor edit button still? :). I'm not sure what the solution would look like but I tend toward Nosebagbear above that it should be something that communities place on individuals rather than a voluntary selection. Izno (talk) 07:23, 13 February 2023 (UTC)[reply]
Support. It would encourage new users to make their first edit when they fear that they would break up something. --魔琴 (talk) 08:42, 12 February 2023 (UTC)[reply]
Support The actual style of use will need some thinking by the community tech team, but the difficulties with handling COI requested edits on a practical timescale encourages violations of the rules by people who would otherwise comply. This could offer an option there, as well as a less-punitive sanction possibility in other areas. Nosebagbear (talk) 17:49, 13 February 2023 (UTC)[reply]
Support This could be very useful. My support is conditioned on this being sufficiently easy to implement -- if it's a large change, all bets are off. CRGreathouse (talk) 19:59, 21 February 2023 (UTC)[reply]
Problem: Most graphs are uploaded by the creator as an image and can't be edited by anyone else. You can use tabular data that can be edited by anyone, but this requires knowledge of JSON and the tabular data system.
Proposed solution: Create an easy-to-use editing interface for JSON tabular data pages. This same tool could seemingly be used to edit any JSON page.
Who would benefit: Editors of tabular data, and readers who want to consume more up-to-date data.
IMO there are a number of problems that make Graph + tabular data infeasible in practice, solving any one of them would be a good step.
Make the tabular data editor a little more functional (T248897).
On top of that, maybe make it possible to edit without going to Commons.
Allow flexible (more granular that the whole spreadsheet) sourcing (T250919).
Show a useful diff for changes to a data table (as opposed to raw JSON diffs).
Figure out change propagation (right now Vega is just making cross-wiki API requests which is not a reasonable solution).
Figure out the no-JS experience for graphs (T249419) although this is probably too big for CommTech.
Add some kind of templating system for Graph, where you can plug in basic chart settings and get a Vega definition out of it. Maybe this can be done already with normal templates, not sure; there are some that are pretty easy to use (mw:Template:Graph:World Historical Highlights, mw:Template:Graph:Weather monthly history) but those all assume a very rigid data format and a very narrow use case.
Expose some of that functionality via VisualEditor.
On the more general topic of how to store data tables, there has been some discussion (related to Covid data) at T250065.
The improvements to the tabular data editor would be a good sized project for CommTech IMO, although in itself it doesn't help that much with this wish, but goes maybe third of the way towards decent graph management functionality. --Tgr (talk) 04:31, 5 February 2023 (UTC)[reply]
Thanks for the detailed breakdown of the situation, Tgr! I agree and am thinking that overall, rewording this proposal to suit the first task you mention (Create an easy-to-use editing interface for JSON tabular data pages) would make for a perfectly-sized project for us and would be helpful even beyond management of graphs. @Wikideas1: How do you feel about that? With your permission, I will make these changes to your proposal, then run them by you once more for approval. Let me know what you'd like to do. Thanks, MusikAnimal (WMF) (talk) 03:21, 6 February 2023 (UTC)[reply]
@Wikideas1 How does it look now? I also would like to rename the proposal to "Create an easy-to-use editing interface for JSON tabular data pages", but I'd like you to first confirm your happy with the rewording I've done to your proposal. Thanks, MusikAnimal (WMF) (talk) 18:49, 6 February 2023 (UTC)[reply]
Sounds interesting I like it. I’m looking forward to seeing what it looks like.
Support And please, make it easier to use them on a Wikipedia, mention exactly on the Help page what to write on a Wikipedia page, for a beginner, to get a Data file there (and make it as easy as placing a photo on Wikipedia); I did not succeed to even get an existing Data file in my Sandbox. --JopkeB (talk) 06:02, 11 February 2023 (UTC)[reply]
Problem: When you select a template in Visual Editor it currently has a option of editing the template. I want another button that takes me directly to the template.
Problem: despite being optional, the infobox is a great summary tool. And there is a huge list due to the diversity of topics in the encyclopedia.
Proposed solution: Or having a button with a list of infoboxes to add quickly, or when creating a new article the assistant suggests a related infobox; for example: article biographies, biography infobox. In addition to adding the option to hide the infobox, this is good on mobile.
I did some work on this at the 2019 Hackathon, but paused it when WMDE picked up template UI improvements. That project is now finished but they didn't get around to browsing templates. My patch from 2019 is still up and wouldn't take a lot of effort to improve. ESanders (WMF) (talk) 14:46, 31 January 2023 (UTC)[reply]
This sounds like something that will benefit some Wikipedias more than others. Most Wikipedias do not have a large number of specialized infobox templates. For example: enwiki has thousands, dewiki has hundreds, tlwiki has dozens, igwiki has 8. WhatamIdoing (talk) 00:30, 11 February 2023 (UTC)[reply]
@Elilopes, I agree that we need Global templates. The smallest wikis need Wikidata-enhanced infoboxes. Most of the articles at htwiki are bot-like articles made from the 2000 US census. They simply don't have enough editors to update the population numbers to the 2020 census data. But why should they? That number could be pulled in from Wikidata instead. They shouldn't have to update it personally; nobody at any of the ~300 smallest Wikipedias should have to update it by hand. WhatamIdoing (talk) 18:27, 15 February 2023 (UTC)[reply]
You can easily go to WP:IB to see a list of infoboxes and see what you need. There are articles that use multiple such as Antonio Inoki for example. There are three in that article. Pro wrestling, Chinese, and officeholder. So auto suggest wouldn't work in cases like that. Drawbacks and limitations need to be considered. Mr. C.C.Hey yo!I didn't do it!10:08, 11 February 2023 (UTC)[reply]
I have a personal script (it's not production-ready) that uses SPARQL query to find proper infobox using Wikidata, and it works pretty well (example for Michael Jordan). So I think that the solution could be more intelligent than just an extended search interface. We have a lot of data about templates (not only infoboxes) and can suggest the best ones for the current article. — putnik14:50, 13 February 2023 (UTC)[reply]
It would be a very nice thing to have, but until we have Global templates, the configuration for infoboxes will have to be written for each wiki separately, so we'll get stuck with the same problem we have now: some of the larger wikis will enjoy this feature after investing some effort in developing this configuration, and the smaller ones will have nothing. So this should be done after we have global templates. That's exactly what I meant when I wrote the Semantic section in the project proposal. --Amir E. Aharoni (talk) 11:54, 22 February 2023 (UTC)[reply]
Totally agree. As an 3x5ension, it would be nice if the choice was part of the new article wizard and brought up the notability requirements. Wakelamp (talk) 01:23, 20 February 2023 (UTC)[reply]
I noticed the Catalan Wikipedia has moved to single-line infobox utilizing Wikidata as source. I was impressed by their accomplishment, that we also implement that in Indonesian Wikipedia, although for now it's still limited to Biographies, Geographies, and Species. ✒Bennylin09:56, 13 February 2023 (UTC)[reply]
Support Integration with Wikidata would be desirable. Fields can be populated from Wikidata, but having visual feedback during editing would also be useful (for example, look up in advance which fields have available data in Wikidata and show the data in the editor before publishing). Lion-hearted85 (talk) 12:24, 11 February 2023 (UTC)[reply]
Yep. Wikidata integration is the future of infobox. More projects should adopt the Catalan Wikipedia approach (I'm under the assumption that they're the first to do this, I apologize if this is not the case, and it was based on another project's codes) ✒Bennylin09:57, 13 February 2023 (UTC)[reply]
Support We should have a fast way to include infobox in the article, or edit infobox. That accounts for a majority of lead section -- moreover navbox in the end of the article would have an add / remove button. Thingofme (talk) 15:52, 11 February 2023 (UTC)[reply]
Support Short and succint proposal. This is inline with mw:Global templates/Discuss that has been discussed more broadly (and harder to implement). But the spirit is the same: make adding infobox not a nightmare for non-techies communities. I suggest to utilize Wikidata, and make it an opt-in gadget or per project site setting. ✒Bennylin09:54, 13 February 2023 (UTC)[reply]
Problem: Sometimes we're going to write a story, and I really want one, and I type in the original local currency, and like other financial sites, they can actually convert that local currency for me, in real time, into my local currency, and present it in parentheses.
Proposed solution: I type in the original local currency, and just like any other financial news site, it converts that local currency into my local currency in real time, and the exchange rate automatically converts the national currency template, which is presented in brackets.
Who would benefit: Wikinews, All Wikimedia projects and readers.
More comments: Currency templates are especially useful for wikinews in all languages. Because actually for Chinese Wikinews, especially we cover various countries, including Taiwan dollar, Chinese yuan, Hong Kong dollar, patacas, Japanese yen, Korean won, Thai dollar, Singapore dollar, Malaysian RMbil US dollar, British pound, euro, rubles and some African currencies.
Thank you for suggesting this! I think this would be a fantastic idea (and it gives me another idea: to create one that says "$20 USD in 1920 is worth $__ today"). However, is there a trusted and open database we can connect to for international money conversions? I assume this database would need to update in realtime, as conversation rates may change day by day. Evedawn99 (talk) 15:04, 1 February 2023 (UTC)[reply]
As encyclopedias, do we really need the currency conversion of historical numbers in real-time? The fluctuations may end up resulting in differences in the presentation of the information, and introduce more distrust in the content by readers when they compare their versions as viewed at different times. It seems that :en:Template:FXConvert has been imported into zhwiki, with some templates in en:Category:Currency conversion templates as well. These show historical inflation rates, and are up to date to the previous year, if the inflation/exchange rates are updated accordingly. Maybe this can be a starting point to work on universal template/module with the data residing in wikidata. Robertsky (talk) 19:25, 10 February 2023 (UTC)[reply]
Currency conversion rates are highly complex due to buy/sell differences, purchasing power differences, official fixed rates which do not correspond to black market rates, hyperinflation and revaluation. And rates now fluctuate on a second-by-second basis. And don't get me started about crypto-currencies. Given such variability then quoting a calculated exchange rate would effectively be original research. We should stick to the facts. Andrew D. (talk) 22:25, 10 February 2023 (UTC)[reply]
Oppose. The French Wikivoyage already does this (see voy:fr:Modèle:Prix), and this wouldn't require the WMF's resources to do. The wikis that would need such a template can always import the template from fr.voy (or another wiki that uses the template). --SHB2000 (talk | contribs)22:54, 10 February 2023 (UTC)[reply]
Support I see the value of having real time conversion for non-encyclopedic projects. The wikivoyage fr setup is a good start, however, we may need additional work if we want additional stuff like allowing users to select their preferred currency. Robertsky (talk) 17:12, 11 February 2023 (UTC)[reply]
Problem: There is no problem at the moment, but this is an idea. See below.
Proposed solution: Google services, like Docs and Sheets, offer real-time collaborative editing. I love this feature, as it makes editing with others very easy and makes collaboration run smoothly. This is very difficult on Wikipedia, because two people would have to be on a call or next to each other and edit from one account. This proposal is to create collaborative editing, a system that would allow two or more editors to edit on one page at once without there being conflicts when the publish button is clicked.
Here are some ideas of how this could work. Editors would set up some sort of group entity- I'll call it an "edit party" for now. The edit party acts as a single entity; one user would be the leader of the party, and they would navigate the party across the Wiki and click edit. Once the edit party is in edit mode, the users within the party can edit throughout the article; maybe have different colored cursors like Google Docs. Now, who presses the publish button seems like a place for disagreement, so maybe there could be a system where all the members of the party (or some percentage) must approve a "publish proposal". This would then publish the edits. When a different user makes edits and attempts to publish, an edit conflict could still be relevant, as it would be the user versus the edit party. The edit party would look like a single person in edit history pages; maybe something like "Edit Party: User:___, User:___" etc. Of course, there are a number of problems with this that would need to be worked out (max number of people in a party? Can users join cross-Wiki? Maybe have a real-time chatbox in the party? Could the party respond to threads and create articles?) but this is just an idea that I think would be beneficial to the Wikis.
Who would benefit: Users who desire to edit with others. Users who want to develop an article together could all pitch in and increase productivity; revising an article could take thrice as fast as it would with a single person.
This has been investigated before and there have even been some demo's. One of the bigger unsolved problems for this so far are how exactly to do copyright attribution when people collaboratively worked on something at the same time, saved at the same time. Say we both enter a session, we both make some edits, I give permission to publish, then I leave, you change my text and make it something about several illegal acts that I would never morally support. And then you do the final save.. By whom is this text, who can be sued, whose names come up when we bring up that history ? etc etc etc. —TheDJ (talk • contribs) 23:14, 23 January 2023 (UTC)[reply]
If you're familiar with Google Docs, it has a edit history (similar to wiki, but based on intervals of time rather than "save" button) viewer where it correctly attributes which person added/deleted text, similar to diff viewers. So only the text that one person touched would be attributed to that person. --JackFromWisconsin (talk) 00:39, 24 January 2023 (UTC)[reply]
Yes, but we have a revision system that uses wikitext, not keystrokes. So unless you want everyone to do away with wikitext as a storage method, you can't really mix those.... Perhaps you could keep a duplicate history of every single keystroke in a separate table or something but... Its not simple. —TheDJ (talk • contribs) 11:11, 24 January 2023 (UTC)[reply]
Our current thinking is similar to the proposal here, that the "host" of the edit session would be the attributed author, and all other "guests" would agree to no-attribute license their contributions to the "host" (e.g. Public Domain). ESanders (WMF) (talk) 15:26, 25 January 2023 (UTC)[reply]
Is it not possible to connect the edits to both, if both are still online, and to the editors still active, when others have left the session? With a new article in the process of creation this should be unproblematic. And only those in the team that set out to write it should be allowed in (others only after admittance by the active editors or the "admin" of the editing group. Group editing should end when the article is put into the normal dictionary space. — Zapyon (talk) 10:00, 11 February 2023 (UTC)[reply]
Is this really a large proposal? AIUI CollabPad is pretty close to being deployable. (Not sure how easy it would be for a team other than Editing to make progress on it, though.) --Tgr (talk) 02:11, 1 February 2023 (UTC)[reply]
I didn't know this existed until now, thanks for showing me this. I'd love to see it get implemented, and hope this pushes for its development. MyCatIsAChonk (talk) 19:10, 4 February 2023 (UTC)[reply]
@ESanders (WMF) and KSiebert (WMF): any thoughts about moving this to the Editing category? I only have superficial knowledge of CollabPad, but my impressions is that by building on that, this proposal would fall into the range of what wishes are acceptable for CommTech to work on. --Tgr (talk) 06:11, 5 February 2023 (UTC)[reply]
I'm curious how this might work for people who are simultaneously editing, too. Especially for current events, it can be frustrating to try to make small, quick edits to an article so that someone doesn't update the page while you're editing. I don't know how many times I've been doing a large edit, only to try to publish and find that I'm working with a historic version of the page. At that time, I need to figure out what they changed, whether it's worth saving, and how to incorporate my edit. Significa liberdade (talk) 21:44, 10 February 2023 (UTC)[reply]
Perhaps the attribution issue could be solved with a system of "locking a part of the page" and saving regularly independent individual versions. For instance you are participing in an edit-a-thon on a single article: when someone edits a paragraph they own temporarily this paragraph and nobody else can modify it, and when this person moves its cursor outside of this paragraph their edit is saved with only this changed paragraph (or possibly with a timeout of 1 minute of inactivity). It would be a sort of medium-frequency merge (while seeing others’ independent changes), and the locking system would limit the number of small diffs (typically someone else add a letter while you are writing some sentence). The locked paragraphs could be highlighted to warn other editors that they cannot edit (for now) these parts. ~ Seb35[^_^]13:06, 22 February 2023 (UTC)[reply]
Oppose Attributing individual keystrokes to each user would rapidly inflate page history archives. In articles on current events, the chaotic environment serves as a useful deterrent to redundant efforts. Under an altered system, it would be difficult to attribute malicious and vandalizing edits by diving into submenus of group edits BluePenguin18 🐧 ( 💬 ) 23:38, 10 February 2023 (UTC)[reply]
Oppose per BluePenguin19. This, at least with the implementation suggested above, also ruins the fundamental wiki concept that people are accountable for the edits they make. * Pppery *it has begun03:47, 11 February 2023 (UTC)[reply]
Oppose because of accountability reasons mentioned above. If there is an edit war between 2 edit parties, how would sanctions be meted out? Also, I am concerned that large edit parties could intimidate a single user by emphasizing their size. Libcub (talk) 06:18, 11 February 2023 (UTC)[reply]
Oppose Unnecessary in my opinion. It would be a complete mess to try and edit with how many other users on the same page at the same time, especially on something like a featured article... Phrogge (talk) 19:32, 11 February 2023 (UTC)[reply]
Oppose - Realtime editing would obviously be a great feature, but this is a big and hairy technical topic that deservers a lot more time than just a single proposal here. Husky (talk) 20:57, 12 February 2023 (UTC)[reply]
It is doubtful I think this is a great feature, but the implication of this feature would be a mess. I don't know how the servers could handle multiple edits simultaneously. Don't get me wrong I believe this feature would boost community efforts, but there is also the attempt to track vandalism, and collaboration could make the efforts to track vandalism more arduous. NPRB (talk) 21:38, 13 February 2023 (UTC)[reply]
Oppose Nice to have feature in an ideal world, but with too many disadvantages: No longer any personal accountability for each contributor, edit wars impossible to resolve and to control, more vandalism, spam robots starting to edit, huge "diff" files in the WP database, page history cluttered by too many entries becoming no longer readable, loss of traceability, ... ruine of Wikipedia (not only physically, but also its fundamental spirit). Shinkolobwe (talk) 12:33, 18 February 2023 (UTC)[reply]
Oppose Aside from the previously discussed copyright issues this possesses, I doubt this is really something that should be worked on. If you have the motivation to set up an 'edit party' with another editor, you can certainly coordinate your edits in a different manner. Is this really necessary? Will it be used? Or will it just remain an unclicked option at the bottom that maybe 20 real people will accidentally hit? WhoAteMyButter (talk) 03:16, 20 February 2023 (UTC)[reply]
Oppose The copyright issue could be solved by shared editing, but seperate saving (so still one version per editor which only contains his/her contribution). For that while editing the unpublished edits would have to be saved temporarily once a second person is involved in order to be able to separate them for the version history. However vandals could just keep deleting/changing what you write when editing is shared and you would only see the published endresult. How would that be avoided without having to save every keystroke to track vandals? Maybe the first person could kick the second out of shared mode? Maybe one has to even be invited by the first editor? Make it a separate right for users/articles? It also could probably only be "published" once everyone has hit that button so noone is in mid-sentence. The time stamp of each editos contribution version is then that individuals publishing time - so the first editor could hit "publish", but it's only saved once the second one hits publish as well, and both separated version wil appear with their respective time stamp. It's still too complicated and I'm not convinced it's worth the effort. Just use the talk pages to coordinate or the In Use template for larger edits. --Lupe (talk) 15:38, 20 February 2023 (UTC)[reply]
Support I can say that this is an idea that will work wonderfully in a number of collaborative projects within the Hebrew Wikipedia.
However, I highly recommend restricting it to outside the articles namespace (so that it works mostly in the draft, user, etc. namespaces). —מקף⁻ණ (Hyphen)23:39, 20 February 2023 (UTC)[reply]
Support The attribution issue could be managed with a semi-collaborative editing: editors can only modify a part of the page that nobody is currently modifying, see my comment in the discussion. ~ Seb35[^_^]13:11, 22 February 2023 (UTC)[reply]
Support Wikipedia was called a social network, a collaborative environment, but software limitations don't allow real-time collaborations, which is a shame. There are various examples showing it could work, and various examples of how conflicts could be solved. So why not on Wikipedia? Juandev (talk) 10:48, 23 February 2023 (UTC)[reply]
Oppose As a general feature on any page, I anticipate that feature will introduce many side and follow up issues, e.g. one user discards made changes thus rendering the 2nd user's changes garbarge because words, images,... are missing that the 2nd user references or relied to be existing. Similar for reverting. In contrast, I'd be happy to support adding mediawiki syntax support (maybe even the visual and code editor) to an existing collaborative editor and let this run inside mediawiki, so if buddies want to collaboratively edit some text like a meeting protoccol or brainstorming results, they do not need to copy & paste existing wiki page source to an existing collaborative editing platform, edit there without any mediawiki syntax support, and copy & paste back – but instead have that editor nicely integrated; but it's still a special section clearly distinct from usual context & editing. --Schoschi (talk) 18:16, 23 February 2023 (UTC)[reply]
Problem: Some communities have tried to structure request pages: request for deletion, for undeletion, requests to admins, request to merge or split pages, request to proofread a draft, request to provide permission to reuse an image, and more. These usages vary from wiki to wiki, but they all lack formal structuring.
When someone wants to submit a request on wiki, they have to take the information from an information page, and then submit their request on a different page. It is okay if you already know the local culture, how the process works, or if the submission is simple (for instance, voting is easy). It is much more complicated if you need to provide multiple, different items, which are not clearly defined to you. Even with preloads and editnotices, it is not always helping. The abandonment rate can be high, as users tend to give up when something is complicated.
A simple example: to submit this wish, I had to use wikitext, and fill the different fields of a template as if I was using a text processor. Hopefully, I'm an experienced user to know how to handle it. Guidance wasn't provided while writing this wish (or I missed it). Even if very best efforts have been put to streamline wishes submissions, it would be much better if a proper, well designed tool was available, and not only for this survey.
Proposed solution: The idea is to offer community customizable forms, to create proper step by step. Each step would complete the previous one. Each step by step would be sorted locally, like a template. They could be JSON based, as more and more customization options now exist on wiki (TemplateData, Growth Community configuration, etc.)
Who would benefit: People less accustomed to our way of submitting requests, but anyone could enjoy a more guided way to submit requests.
More comments: Here is an example on how we could structure undeletion requests. At the moment, cases I saw go from a blank page with a wikitext template to fill to a tentative of step by step where you have to memorize each step before submitting the request. It would be replaced by the following:
fill which article you'd like to undelete
what is your source 1? This step provides guidance (you can say that Facebook is not a source there and, even better, the form prevent users from submitting it)
Same as step 2, for the second source.
fill your undeletion reasons
Recap, and post. The form posts the request on the right page, with the proper request template, the two sources listed and the justification (and signature!).
Support TIL for me as well about the shortcut. Never knew about such a thing. I'd support adding a button to the toolbar as ESanders suggested — DaxServer (t · m · c) 20:05, 10 February 2023 (UTC)
22:59, 11 February 2023 (UTC)
Strong support. — Jules* talk 19:24, 10 February 2023 (UTC)
Comment The Extension:ContentTranslation allows users to work on translating an article without anyone having access to the content they are translating. Therefore, I believe the MediaWiki developers could develop a similar platform for a private sandbox. WikiFer msg 13:35, 5 February 2023 (UTC)
Strong oppose Couldn't you do the same thing off-wiki? Having a private sandbox that cannot be seen from anyone would just make it a haven for users who use their sandbox as their personal web host, which can also be used to host illegal content, and there's also no way of knowing if someone mass-pasted copyvios into this "private" sandbox. The downsides outweigh the minimal benefits of this proposal. --SHB2000 (talk | contribs) 22:42, 10 February 2023 (UTC)
Oppose per everyone above. See also w:WP:NOTWEBHOST * Pppery * it has begun 03:50, 11 February 2023 (UTC)
Neutral This idea can benefit people who want to test things privately, but this idea can also go against core principles of Wikipedia. NPRB (talk) 21:08, 13 February 2023 (UTC)
Jeeputer (talk) 21:37, 20 February 2023 (UTC)
. It is a good idea too to automatically add page number for Google Book urls. I believe the same idea can be done for archive.org book pages. Maybe this can already be done with Web2Cit ? Example for the url of a french article? If you are a coder, you can create your own here and you can see the list of already done urls with Web2Cit monitor. Jurbop (talk) 16:13, 1 February 2023 (UTC)
Done SWilson (WMF) (talk) 02:56, 25 January 2023 (UTC)
It is doubtful I think this is a great feature, but the implication of this feature would be a mess. I don't know how the servers could handle multiple edits simultaneously. Don't get me wrong I believe this feature would boost community efforts, but there is also the attempt to track vandalism, and collaboration could make the efforts to track vandalism more arduous. NPRB (talk) 21:38, 13 February 2023 (UTC)
