https://bugzilla.wikimedia.org/show_bug.cgi?id=73241
Bug ID: 73241
Summary: Auto-save to increase chances of lost edits recovery
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: Page editing
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Web browser: ---
Mobile Platform: ---
As a use who is preparing an edit, I'd like to be confident that if some bad
interruption happens before I save it (e.g. power outage) I'll likely be able
to recover most of my work when I try to edit the page again, even if other
countermeasures (e.g. browser cache, local copy) are missing or failed.
Local vs. remote storage, frequency of autosave, expiry etc. are negotiable.
The less interface there is, the better; there should be no added
preference(s).
Creating because of
https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079378.html and
the lack of a bug in core to track this.
----
Something else that I have had in the pipeline for a long while is autosave
drafts. Basically, whenever you type, the article is saved to your local
computer. If the browser crashes, and you visit the same article, it will
prompt you for recovery. Making a Special:Autosave drafts index page would be
trivial.
Implementation:
https://gerrit.wikimedia.org/r/#/c/5130/
<https://gerrit.wikimedia.org/r/#/c/5130/>
Of this, I also have an alternate implementation:
https://gerrit.wikimedia.org/r/#/c/157818/
<https://gerrit.wikimedia.org/r/#/c/157818/>
https://gerrit.wikimedia.org/r/#/c/159626/
<https://gerrit.wikimedia.org/r/#/c/159626/>
The original one is based on code by Joancreus and uses localStorage. It works,
quite well actually, but while improving it, I became of the opinion that
localStorage is basically so limited in storage and gives you so little
feedback as an API and an enduser, that it's not really suited for much more
than usersettings (big cookies). Not for saving potentially multiple 1MB
articles, with structured details.
As a storage layer, indexedDB is much nicer in that regard. API wise, it's a
bit convoluted, but a jQuery plugin makes it usable and readable. There are
WebSQL polyfills for platforms that don't have indexedDB, which would allow us
to support browsers of the past 6 years.
I would like some opinions on which way to go here. Additionally, i would love
to hear what else people think would be required to make this usable for the
Wikipedia audience and the naming. Would this be Drafts ? Autosave drafts ?
autosave ? Would you say 'recover' when asking the user to use the version from
drafts, or just 'use draft' etc?
Note that the '2nd' version also has a few more improvements like a separate RL
module and a preference option, but those can easily be added to the first
implementation as well.
----
Clearly, I prefer the word "autosave", which reminds people of the recovery
features endemic in any document editing software; rather than "draft", which
in the past caused a lot of confusion. LibreOffice, when restarted, asks if you
want to "recover" a previous document, and many other FLOSS productivity
softwares use the same terminology: what do they do on the devil's side (M$ and
Apple)?
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
