Community Wishlist Survey 2023/Editing

21 proposals, 464 contributors, 1164 support votes
The survey has closed. Thanks for your participation :)

Allow users to selectively disable code editor functions

  • 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.
  • Phabricator tickets:
  • Proposer: Al12si (talk) 20:28, 5 February 2023 (UTC)Reply[reply]


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


Nested templates in Visual Editor

  • 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)
  • Proposer: XanonymusX (talk) 22:34, 23 January 2023 (UTC)Reply[reply]


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


Quickly add favorite and related templates

  • 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.
  • Phabricator tickets: T55590
  • Proposer: —TheDJ (talkcontribs) 16:11, 5 February 2023 (UTC)Reply[reply]


  • This is similar to another proposal, but I liked my own description better, so... we'll figure it out :) —TheDJ (talkcontribs) 16:11, 5 February 2023 (UTC)Reply[reply]
    • @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[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[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[reply]


VisualEditor should use proper names for references

  • 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
  • More comments:
  • Phabricator tickets: task T52568, task T92432, task T245199
  • Proposer: Grüße vom Sänger ♫(Reden) 10:25, 24 January 2023 (UTC)Reply[reply]


  • Support: Yeah the :0, :1... ref names assigned by the VE aren't exactly great. There should be an option in the VE to name them. Findingmoney100 (talk) 16:54, 24 January 2023 (UTC)Reply[reply]
  • @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 "", "", 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[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[reply]
In 2022 we had a similar wish which made it into the top 30: KSiebert (WMF) (talk) 14:32, 26 January 2023 (UTC)Reply[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[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[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[reply]
@Sänger: if we/you rename it to last year's wish, it'll be clearer for votes imo. Femke (talk) 17:27, 30 January 2023 (UTC)Reply[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[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[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[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[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[reply]
No, every other citation software will auto-generate something like Sänger-2023 with no problem. I asked for the same in Community Wishlist Survey 2023/Editing/Clean up Visual Editor wikitext output. Regards Matthias (talk) 20:08, 25 January 2023 (UTC)Reply[reply]
  • They still haven't fixed this...? --JackFromWisconsin (talk) 15:20, 27 January 2023 (UTC)Reply[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[reply]

What the heck are human-like names btw? I asked for proper names, why did you change it? Grüße vom Sänger ♫(Reden) 23:41, 8 February 2023 (UTC)Reply[reply]

@Sänger Wait one moment, I will fix this. MusikAnimal (WMF) (talk) 23:51, 8 February 2023 (UTC)Reply[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[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[reply]
No, proper is completely fine, no need to change it whatsoever. Grüße vom Sänger ♫(Reden) 23:56, 8 February 2023 (UTC)Reply[reply]
Okay :) It may take a few minutes to change this, so hang tight (the translation subpages and what not all need to be moved, too) MusikAnimal (WMF) (talk) 23:59, 8 February 2023 (UTC)Reply[reply]
The translations I did are already with the proper title, not the machine-readable stuff you invented. Grüße vom Sänger ♫(Reden) 00:01, 9 February 2023 (UTC)Reply[reply]
I don't know what you mean by machine-readable stuff that I invented, but anyway the move is now complete :) Thanks again, MusikAnimal (WMF) (talk) 00:09, 9 February 2023 (UTC)Reply[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[reply]

This has been a perennial Community Wishlist item since at least 2017, possibly earlier. As I understand it, WMF is already committed to solving this; see task T92432 as well as other tickets. For many other related links, see w:WP:VENAMEDREFS. Mathglot (talk) 22:28, 10 February 2023 (UTC)Reply[reply]

I should add here that user script RefRenamer by User:Nardog fixes these *after the fact*, converting all VE numeric-name references to Lastname-YYYY where feasible, and to other reasonable choices where necessary. Mathglot (talk) 22:40, 10 February 2023 (UTC)Reply[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[reply]
FLOW has definitely not been invested to after 2017, but yeah, it's just a straw man. --Matěj Suchánek (talk) 08:40, 20 February 2023 (UTC)Reply[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[reply]


"Preview page with this template" should only accept/suggest pages that transclude the template

  • 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).
  • Phabricator tickets: T279736
  • Proposer: Nardog (talk) 13:35, 28 January 2023 (UTC)Reply[reply]


  • Somewhat related: Community Wishlist Survey 2023/Editing/Create a private sandbox page for a Wikipedia user: create a private sandbox that would replace the "Preview page with this template" feature. Taylor 49 (talk) 10:18, 5 February 2023 (UTC)Reply[reply]
    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[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[reply]
  • A more generic solution is to preview a page using the current page instead of some template, e.g. preview Article with Template:T/sandbox (which I'm editing) in place of Template:T. User:Jackmcbarn/advancedtemplatesandbox.js achieves this on enwp, and I find it very useful. Certes (talk) 21:12, 10 February 2023 (UTC)Reply[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[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[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[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[reply]


Create a private sandbox page for a Wikipedia user

  • 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.
  • Phabricator tickets:
  • Proposer: WikiFer msg 15:03, 2 February 2023 (UTC)Reply[reply]


  • 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[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. WikiFer msg 17:09, 3 February 2023 (UTC)Reply[reply]
    @Taylor 49, no, it's not a good idea. Mr. C.C.Hey yo!I didn't do it! 09:46, 11 February 2023 (UTC)Reply[reply]
  • This would raise this same legal problems as server-side storage for the auto-save feature. --Tgr (talk) 05:29, 5 February 2023 (UTC)Reply[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. WikiFer msg 12:50, 5 February 2023 (UTC)Reply[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[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. WikiFer msg 21:10, 5 February 2023 (UTC)Reply[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[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
    • limiting the feature to "good users"
  • Taylor 49 (talk) 10:27, 5 February 2023 (UTC)Reply[reply]
    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[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[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 (talk) 12:24, 6 February 2023 (UTC)Reply[reply]
    @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[reply]

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


  • Support 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[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[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[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[reply]
  • Strong oppose This gives people essentially a private website, courtesy of WP. What's wrong with a text editor? --Rconroy (talk) 22:38, 17 February 2023 (UTC)Reply[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[reply]
    @Magnoliasouth, never say sorry when you've done nothing wrong. Mr. C.C.Hey yo!I didn't do it! 09:27, 11 February 2023 (UTC) Mr. C.C.Hey yo!I didn't do it! 09:27, 11 February 2023 (UTC)Reply[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#6545 23:25, 10 February 2023 (UTC)Reply[reply]
  • Oppose Oppose per everyone above. See also w:WP:NOTWEBHOST * Pppery * it has begun 03:50, 11 February 2023 (UTC)Reply[reply]
  • Oppose Oppose --Jim Hokins (talk) 08:15, 11 February 2023 (UTC)Reply[reply]
  • Strong oppose, this will never be a thing and should never be proposed again. The cons have already been stated. Mr. C.C.Hey yo!I didn't do it! 09:38, 11 February 2023 (UTC)Reply[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[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[reply]
  • Support Support Smetanakaviar (talk) 12:08, 11 February 2023 (UTC)Reply[reply]
  • Oppose Oppose --Crosstor (talk) 13:17, 11 February 2023 (UTC)Reply[reply]
  • Support Support Joseph (talk) 13:19, 11 February 2023 (UTC)Reply[reply]
  • Support Support CROIX (talk) 15:12, 11 February 2023 (UTC)Reply[reply]
  • Oppose Oppose per WP:NOWEBHOST. Thingofme (talk) 15:57, 11 February 2023 (UTC)Reply[reply]
  • Support Support Radio-Somewhere (talk) 16:47, 11 February 2023 (UTC)Reply[reply]
  • Oppose 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[reply]
  • Strong oppose Aquí en WP luz y taquígrafos siempre, aunque a veces duela. --LauraFarina (talk) 17:56, 11 February 2023 (UTC)Reply[reply]
  • Support Support De nue pw (talk) 22:10, 11 February 2023 (UTC)Reply[reply]
  • Oppose 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[reply]
  • Support Support Spectrallights (talk) 00:15, 12 February 2023 (UTC)Reply[reply]
  • Oppose Oppose Mauricio V. Genta (talk) 07:52, 12 February 2023 (UTC)Reply[reply]
  • Support Support 沁水湾 (talk) 11:44, 12 February 2023 (UTC)Reply[reply]
  • Oppose 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. — xaosflux Talk 15:08, 12 February 2023 (UTC)Reply[reply]
  • Strong oppose Per w:WP:NOTWEBHOST --HenriHa (talk) 17:48, 12 February 2023 (UTC)Reply[reply]
  • Support Support Lalaithan (talk) 21:45, 12 February 2023 (UTC)Reply[reply]
  • Oppose Oppose Per others, goes against the intended nature/spirit/principles/etc. of this encyclopedia. Funcrunch (talk) 23:59, 12 February 2023 (UTC)Reply[reply]
  • Oppose Oppose Error (talk) 13:21, 13 February 2023 (UTC)Reply[reply]
  • Oppose Oppose Per others. Titore (talk) 14:21, 13 February 2023 (UTC)Reply[reply]
  • Support Support Gillum (talk) 20:26, 13 February 2023 (UTC)Reply[reply]
  • Support Support --Erbiton (talk) 20:59, 13 February 2023 (UTC)Reply[reply]
  • Neutral 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[reply]
  • Oppose Oppose --Amtiss (talk) 21:39, 13 February 2023 (UTC)Reply[reply]
  • Strong Support Support - 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[reply]
  • Support Support See my comments far above. Taylor 49 (talk) 04:04, 14 February 2023 (UTC)Reply[reply]
  • Support Support Zwd626 (talk) 04:22, 14 February 2023 (UTC)Reply[reply]
  • Strong Oppose Oppose 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[reply]
  • Oppose 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[reply]
    You cannot spam anyone with a sandbox visible to you only. Taylor 49 (talk) 16:23, 14 February 2023 (UTC)Reply[reply]
  • Oppose Oppose --cyrfaw (talk) 12:21, 15 February 2023 (UTC)Reply[reply]
  • Strong oppose Thooompson (talk) 14:33, 15 February 2023 (UTC)Reply[reply]
  • Support Support אסתר66 (talk) 14:04, 16 February 2023 (UTC)Reply[reply]
  • Oppose Oppose Hey man im josh (talk) 15:42, 16 February 2023 (UTC)Reply[reply]
  • Oppose Oppose ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:25, 17 February 2023 (UTC)Reply[reply]
  • Support Support बडा काजी (talk) 12:40, 17 February 2023 (UTC)Reply[reply]
  • Oppose Oppose lots of good reasons to oppose above. pile-on. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:54, 17 February 2023 (UTC)Reply[reply]
  • Support 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[reply]
  • Support Support Mr. Thistle (talk) 11:10, 18 February 2023 (UTC)