Jump to content

Community Wishlist Survey 2023/Editing

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

Discussion

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

Voting

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]

Discussion

  • 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

  • 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: VisualEditor: task T55590; TemplateWizard: task T347370
  • Proposer: —TheDJ (talk • contribs) 16:11, 5 February 2023 (UTC)[reply]

Discussion

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

Pinging discussants about wish selection and other updates

Hello everyone,

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

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

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

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

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

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ Pinging more discussants –– STei (WMF) (talk) 14:28, 18 May 2024 (UTC)[reply]

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ Pinging more discussants –– STei (WMF) (talk) 14:29, 18 May 2024 (UTC) [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]

Discussion

  • 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]
  • @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]
In 2022 we had a similar wish which made it into the top 30: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Editing/VisualEditor_should_use_human-like_names_for_references KSiebert (WMF) (talk) 14:32, 26 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]
@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]
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]
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]

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]

@Sänger Wait one moment, I will fix this. MusikAnimal (WMF) (talk) 23:51, 8 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]
No, proper is completely fine, no need to change it whatsoever. Grüße vom Sänger ♫(Reden) 23:56, 8 February 2023 (UTC)[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]
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]
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]
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]

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]

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]
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]
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]
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]

Voting

"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]

Discussion

Voting

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]

Discussion

@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
    • limiting the feature to "good users"
  • Taylor 49 (talk) 10:27, 5 February 2023 (UTC)[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]
    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 (talk) 12:24, 6 February 2023 (UTC)[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]

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]

Voting

  • 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.
  • Phabricator tickets: T190224
  • Proposer: Evedawn99 (talk) 14:32, 25 January 2023 (UTC)[reply]

Discussion

Voting

Allow template wizard to substitute a template with a checkbox

  • Problem: After I use the template wizard with a template that I want to substitue rather than transclude, I have to manually add the subst: notation
  • Proposed solution: I propose adding in a checkbox to template wizard that would automaticly add in the subst: bit
  • Who would benefit: Anyone who uses this extension
  • More comments:
  • Phabricator tickets:
  • Proposer: NightWolf1223 (talk) 17:50, 31 January 2023 (UTC)[reply]

Discussion

  • 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]
    +1 to this idea. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:58, 17 February 2023 (UTC)[reply]
    Jeeputer (talk) 21:37, 20 February 2023 (UTC)[reply]
    @Tacsipacsi by SHOULD be substituted do you mean must be (always is substituted)? Or do you mean that checkbox is ticked by default? Nux (talk) 17:23, 24 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]

Voting