Jump to content

Community Wishlist Survey 2023/Editing

From Meta, a Wikimedia project coordination wiki
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:
  • Proposer: —TheDJ (talkcontribs) 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 (talkcontribs) 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

Avoid editing conflicts

  • Problem: Conflicting edits are confusing when 2 or more users are editing the article at the same time.
  • Proposed solution: Display an alert message when another user tries to edit an article that is already being edited.
  • Who would benefit: publishers
  • More comments:
  • Phabricator tickets: phab:T329975
  • Proposer: Elilopes (talk) 14:04, 25 January 2023 (UTC)[reply]

Discussion

- KSiebert (WMF) keep the proposal, for the community to decide
- Significa liberdade collaborative editing is a good one. maybe even this function is dangerous. Elilopes (talk) 15:00, 13 February 2023 (UTC)[reply]

Voting

Extend formula handling to cope with actuarial notation

  • 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.
  • More comments:
  • Phabricator tickets: phab:T175673
  • Proposer: Stelio (talk) 12:42, 24 January 2023 (UTC)[reply]

Discussion

Voting

Auto-save feature

  • 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).

Discussion

  • 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]
      @DLynch (WMF) @Jdforrester (WMF), two questions:
      1. Is there something I need to do to turn this on in the 2017 wikitext editor? My drafts don't persist following a browser crash.
      2. For making it "more user-visible", is that something that an existing team would take on without needing a community vote?
      czar 22:13, 29 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]
      @Czar, you'd have to turn on the 2017 wikitext editor to get its features. It's the not-so-new "New wikitext mode" in Special:Preferences#mw-prefsection-betafeatures. Whatamidoing (WMF) (talk) 17:51, 31 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]
  • For what is worth, there is a similar request from last year. DMaza (WMF) (talk) 18:19, 25 January 2023 (UTC)[reply]
    It is also known that there were a lot of votes in that proposal. Thingofme (talk) 03:40, 29 January 2023 (UTC)[reply]
    And in 2021, and in 2016 (36th and 31th, respectively). The relevant task is T75241. --Tgr (talk) 05: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]

Voting

Auto-save wish fulfilment, your input needed

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.

Please read the new project page we have created for the wish and then visit the talk page to give responses to some questions we have for you. –– STei (WMF) (talk) 18:07, 19 June 2023 (UTC) [reply]

Custom edit summaries per user

  • 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
  • Phabricator tickets:
  • Proposer: Simeon (talk) 18:27, 23 January 2023 (UTC)[reply]

Discussion

  • 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]
  • The 2017 wikitext editor gives you a drop-down menu with previously-used edit summaries, if it helps. -BRAINULATOR9 (TALK) 19:23, 23 January 2023 (UTC)[reply]
    This is generic feature of the visual editor, so it is available in both visual and wikitext modes (aka visual editor and 2017 wikitext editor). ESanders (WMF) (talk) 12:27, 26 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]
    But if you're talking about mobile devices (ie: phones and tablets), that's another issue. Mr. C.C.Hey yo!I didn't do it! 16:12, 11 February 2023 (UTC)[reply]
    Autofill is terrible. Sometimes it works, sometimes it gives you things that are completely irrelevant. Al12si (talk) 03:32, 18 February 2023 (UTC)[reply]

Voting

More functionality for the talk-page reply gadget

  • 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.
  • Who would benefit: Everyone, really.
  • More comments:
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 21:35, 2 February 2023 (UTC)[reply]

Discussion

Voting

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.

Discussion

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]

@Evedawn99. Thanks for your kind comment . 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)[reply]
Something might already by covered by Community Wishlist Survey 2023/Citations/Prompt for page number(s) for compatible cite sources (e.g. book, journal) and Community Wishlist Survey 2023/Larger suggestions/Re-use citation with different page number in VisualEditor. --Matěj Suchánek (talk) 09:02, 2 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!
Ok. For 2) maybe some things can be easily implemented inside Web2cit (I am notifying User:Diegodlh)? For instance, adding page numbers like this photo (excerpted from a 2019 phabricator ticket by User:ESanders (WMF)) inside the second part of this photo from a random New Yorker article (you get the idea if it was a book) ? It should be easy as Web2Cite take the data by default from another provider! Jurbop (talk) 10:18, 2 February 2023 (UTC)[reply]
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]

See also: WMDE Technical Wishes/Book referencing --Wargo (talk) 23:43, 13 February 2023 (UTC)[reply]

Voting

Voluntary pending changes

  • 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.)
  • Phabricator tickets:
  • Proposer: 3mi1y (talk) 02:40, 25 January 2023 (UTC)[reply]

Discussion

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

Voting

Create an easy-to-use editing interface for JSON tabular data

  • 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.
  • More comments:
  • Phabricator tickets: phab:T248897
  • Proposer: Wikideas1 (talk) 09:18, 25 January 2023 (UTC)[reply]

Discussion

I tried it is too complicated. --Wikideas1 (talk) 05:57, 4 February 2023 (UTC)[reply]

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]
That all sounds good to me.
Thank you Wikideas1 (talk) 04:03, 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.
Wikideas1 (talk) 19:13, 6 February 2023 (UTC)[reply]

Voting

Quickly visit template's page in Visual Editor

  • 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.
  • Proposed solution: Add another a button.
  • Who would benefit: Visual Editors
  • More comments:
  • Phabricator tickets: T328021
  • Proposer: बडा काजी (talk) 16:13, 24 January 2023 (UTC)[reply]

Discussion

Such a link already exists on the top of the form with two different wordings:

  • The "Foo" template doesn't yet have a description, but there might be some information on the template's page.
  • Templates are user-generated and may lack complete descriptions. There might be additional information on this template's page.

--Geraki TL 10:37, 26 January 2023 (UTC)[reply]

However the requester want the links to be next to the "Edit" button. Thingofme (talk) 15:50, 11 February 2023 (UTC)[reply]

Voting

Quickly add infobox

  • 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.
  • Who would benefit: editors and readers
  • More comments:
  • Phabricator tickets: T55590
  • Proposer: Elilopes (talk) 13:51, 25 January 2023 (UTC)[reply]

Discussion

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

Voting

Pinging discussants about wish selection and other updates

Pinging to let you know that this wish and 3 other requests related to templates have been selected for development. Additionally 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 an 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), as mentioned above. You can read more and join the discussion. –– STei (WMF) (talk) 12:57, 18 May 2024 (UTC)[reply]

Pinging more discussants –– STei (WMF) (talk) 13:24, 18 May 2024 (UTC)[reply]

Pinging more discussants –– STei (WMF) (talk) 13:56, 18 May 2024 (UTC)[reply]

Pinging more discussants –– STei (WMF) (talk) 13:59, 18 May 2024 (UTC) [reply]

Exchange rate template

  • 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.
  • Phabricator tickets:
  • Proposer: Kitabc12345 (talk) 12:30, 30 January 2023 (UTC)[reply]

Discussion

  • 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]
  • I don't think this requires WMF's engineering resources. All you need is a bot to update Wikidata and a template. Nardog (talk) 18:11, 10 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]

Voting

Collaborative editing

  • 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.
  • More comments:
  • Phabricator tickets: T3898, T76546, T112984
  • Proposer: MyCatIsAChonk (talk) 23:06, 23 January 2023 (UTC)[reply]

Discussion

  • 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 (talkcontribs) 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 (talkcontribs) 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]
    CollabPad is a good idea for the new project, and it can be considered to be alternatives. Thingofme (talk) 16:04, 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]
    It’s only for VE not 2010 source though. Aaron Liu (talk) 18:30, 10 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]
    I'm pretty sure they mean you can see the cursors of everyone that's editing. Aaron Liu (talk) 22:17, 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]

Voting

Structure request pages

  • 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:
  1. fill which article you'd like to undelete
  2. 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)
  3. Same as step 2, for the second source.
  4. fill your undeletion reasons
  5. 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!).

Discussion

Voting