While editing Wikipedia articles, I often faced a situtation when I accidently pressed "Back" in browser, then spontaneously pressing random buttons, returning the edit form and... having a blank editor or the last submitted version of an article. I've been so much frustrated every time when I ruined the new article and had to start it over again.
What can we do to fix this? I propose to keep the current textarea state in localStorage, at least one version per article (we can store them by the relevant article ID, also adding the current timestamp and to the structure). We can also let the user disable key press triggered storage update, but to save backups every N secs, or just to save them by pressing a button.
[Timestamp and possibly other info would be stored to collect garbage. As we know, localStorage has a small quota.]
There is another approach: storing the backups at the server side. Some people ( :] ) suggest that it's quite cheap and may be reasonable. Anyhow, we cannow allow per-keypress backup update due to requests latency. And this would be a disaster to process a huge bunch of some way useless requests simultaneously, unless dedicated servers are run to serve swiftly and obediently.
All this stuff can be developed as a gadget. You can make it a WikiEditor plugin. And it would be re-e-aally fantastic to make this work with VisualEditor. Who would try to make this thing look good? Or should I do this otherwise? :)
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
On 30 April 2013 15:46, Paul Selitskas p.selitskas@gmail.com wrote:
There is another approach: storing the backups at the server side. Some people ( :] ) suggest that it's quite cheap and may be reasonable. Anyhow, we cannow allow per-keypress backup update due to requests latency. And this would be a disaster to process a huge bunch of some way useless requests simultaneously, unless dedicated servers are run to serve swiftly and obediently.
https://www.mediawiki.org/wiki/Extension:Drafts ? (IIRC, this was for some time considered to be used at (all?) WMF sites, but then somehow abandoned (?). I definitely recall seeing it working somewhere – at testwp or possibly mediawiki.org. Oh, now I see https://bugzilla.wikimedia.org/show_bug.cgi?id=37992)
-- [[cs:User:Mormegil | Petr Kadlec]]
Somebody tried to implement that in MediaWiki core about a year ago: https://gerrit.wikimedia.org/r/#/c/5130/ . It turned out to be harder than it looks and the patch is in a limbo now; maybe you could find someone to continue the work.
What about the Drafts extension?
-Chad On Apr 30, 2013 10:27 AM, "Bartosz Dziewoński" matma.rex@gmail.com wrote:
Somebody tried to implement that in MediaWiki core about a year ago: https://gerrit.wikimedia.org/**r/#/c/5130/https://gerrit.wikimedia.org/r/#/c/5130/. It turned out to be harder than it looks and the patch is in a limbo now; maybe you could find someone to continue the work.
-- Matma Rex
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 30 Apr 2013 16:32:17 +0200, Chad innocentkiller@gmail.com wrote:
What about the Drafts extension?
It seems to be slightly different, saving the drafts server-side instead of client-side, and apparently only on demand or every few minutes instead of basically continuously.
On Tue, Apr 30, 2013 at 10:59 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 30 Apr 2013 16:32:17 +0200, Chad innocentkiller@gmail.com wrote:
What about the Drafts extension?
It seems to be slightly different, saving the drafts server-side instead of client-side, and apparently only on demand or every few minutes instead of basically continuously.
Granted, but it's worth keeping in mind since these are all possible solutions to people losing their hard work :)
-Chad
We could mix these two approaches, but the working copy going behind the latest change is the main issue. We're not talking about git, and it is natural text to be merged, unlike the programming languages. That is why I'm certain that every draft stored at the server-side should be treated as outdated, a new change is contributed before the draft is actually used at the first time. That is why I think it's expensive. We pay "money" for nothing, for a spurious machine time.
That's why it is better to work locally at the client-side.
And one more moment: drafts should work slightly different when the user creates a new article. Every new article has Article ID == 0, that is why a different way to store the drafts (dedicated named drafts?) should be chosen.
On Tue, Apr 30, 2013 at 6:18 PM, Chad innocentkiller@gmail.com wrote:
On Tue, Apr 30, 2013 at 10:59 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 30 Apr 2013 16:32:17 +0200, Chad innocentkiller@gmail.com
wrote:
What about the Drafts extension?
It seems to be slightly different, saving the drafts server-side instead
of
client-side, and apparently only on demand or every few minutes instead
of
basically continuously.
Granted, but it's worth keeping in mind since these are all possible solutions to people losing their hard work :)
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Oh, thanks for pointing this out too. I should have prepare better.
Unfortunately, this patch has some obvious flaws. But they can be fixed, I hope so.
On Tue, Apr 30, 2013 at 5:27 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
Somebody tried to implement that in MediaWiki core about a year ago: https://gerrit.wikimedia.org/**r/#/c/5130/https://gerrit.wikimedia.org/r/#/c/5130/. It turned out to be harder than it looks and the patch is in a limbo now; maybe you could find someone to continue the work.
-- Matma Rex
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org