Jump to content

Community Wishlist Survey 2021/Editing/Make edits auto-recoverable if the editor's network crashes: Difference between revisions

From Meta, a Wikimedia project coordination wiki
Content deleted Content added
HLHJ (talk | contribs)
→‎Voting: oppose, with really long rationale because I'm opposing a lot of previous views and it seems only polite
Tag: Reverted
HLHJ (talk | contribs)
Undo revision 20864460 by HLHJ (talk) self-revert because I think I misunderstood the proposal
Tag: Undo
Line 83: Line 83:
* {{support}} Grüße vom [[User:Sänger|Sänger&nbsp;♫]]<sup>([[User Talk:Sänger|Reden]])</sup> 22:08, 18 December 2020 (UTC)
* {{support}} Grüße vom [[User:Sänger|Sänger&nbsp;♫]]<sup>([[User Talk:Sänger|Reden]])</sup> 22:08, 18 December 2020 (UTC)
* {{support}} [[User:Neon Richards|Neon Richards]] ([[User talk:Neon Richards|talk]]) 23:09, 18 December 2020 (UTC)
* {{support}} [[User:Neon Richards|Neon Richards]] ([[User talk:Neon Richards|talk]]) 23:09, 18 December 2020 (UTC)
* {{oppose}} because I'd prefer an asynchronous offline editor for really long edits. Repeated automated saving would presumably cost on bandwidth, server load, and CO2 footprint. This would discourage editing by people who pay a lot for bandwidth, exacerbating a systemic bias. Keeping far too many browser tabs and windows open, which I sometimes do, I've found that more complex, script-laden pages seem to increase the chance of a crash, while WP markup editor is remarkably stable.

:On other platforms, I've had more problems with auto-saving than with losing data, though admittedly many of them with systems that fail to distinguish auto-saved versions from manually-saved ones, making it really hard to pick what I want out of the clutter. I prefer predictable loss to unpredictable copies.

:I agree with Ponor on local storage; I'd rather not have things stored elsewhere until I hit the button and explicitly request it (especially since I sometimes temporarily paste a few sections of some sources into an editing window for easy reference, which might be a copyvio if it was copied outside my own system). Local storage also seems more likely to succeed at the technically-difficult goal of "never lose stuff I didn't want to lose". I take SMcCandlish's point that browser add-ons ([https://addons.mozilla.org/en-US/firefox/addon/form-history-control/ like, say, this one]) may not actually do this well; a custom Wikipedia-editor's browser plugin might do better.

:Obviously losing 4hrs of edits is bad (if you have done this, not touching the browser and grepping the dump will often work). I have every sympathy with those who have lost data, and agree that this is a problem that might reasonably be addressed through technical solutions. I'm just not sure that auto-saving is the best solution to this problem; can we think about some alternatives? A simple (?) measure in the right direction might be a preview warning if you haven't saved your edits in the last 10 min, getting bigger and more conspicuous as you push past 30min and 1 hour, and omitted for really short edits. This would also encourage more, smaller edits, which I often find preferable for other reasons. [[User:HLHJ|HLHJ]] ([[User talk:HLHJ|talk]]) 18:01, 19 December 2020 (UTC)

Revision as of 18:03, 19 December 2020

Make edits auto-recoverable if the editor's network crashes

  • Problem: An WP edit is lost when the editor's network goes down. Saving in-progress work is a feature in VisualEditor and the 2017 wikitext editor, but not the older wikitext editor
  • Who would benefit: Users of classic wikitext editor who develop a post off-line.
  • Proposed solution: Like GMail, routinely autosave an editor's in-progress work
  • More comments: Again, like GMail, create periodic saved-data (a snapshot of work to date) that can easily take over from the lost data of whatever type (message, article text, etc.)
  • Phabricator tickets:
  • Proposer: BrettA343 (talk) 23:36, 20 November 2020 (UTC)[reply]

Discussion

1) I am curious, in which cases/situations the VisualEditor and the 2017 wiki text editor are able to restore the lost sessions? If I close a browser tab with non-saved edits, and restore, my edits are gone. Unlike by the Reply tool (Discussion Tools). What is the difference?
2) Is T75241 ticket about a different topic? If not, is it resolved already? Samat (talk) 15:56, 29 November 2020 (UTC)[reply]
3) How this topic is related the Draft extension? Is it already in use for any of these tools? Samat (talk) 17:52, 29 November 2020 (UTC)[reply]
Motivation for my questions: request for an auto-save (restore) feature on the local wishlist, and I am not sure how and where to address it here: does it need new development, or only implementation of existing features. Samat (talk) 17:52, 29 November 2020 (UTC)[reply]
  • I've boldly clarified the proposal to be about the classic non-VE wikitext editor. Best, MusikAnimal (WMF) (talk) 16:29, 7 December 2020 (UTC)[reply]
  • Have been having this problem for a while also. Yes, my edits are stored locally in some cases but in some others it is still able to be lost. The most recent that I remember was some months ago when a user starts editing a page after I started editing it and then they published it before I published mine. My edit was gone completely and I need to start it all over. Often happens by vandals or bots on Wikipedia. It has also happened before when my Internet went down so my edit was not published and when I went back in my browser, it showed the "can't connect" page so my cached edit was lost. RXerself (talk) 00:31, 9 December 2020 (UTC)[reply]
  • On iOS, LocalStorage is limited. I often lose work when a tab reloads in mobile-editor, VE, NWE, etc. But in the classic editor, I get prompted to resubmit the form and can recover to the last preview. Preview early, preview often. This is one of the major factors that keeps me on the classic editor over the alternatives. Pelagic (talk) 09:54, 18 December 2020 (UTC)[reply]

Voting