סקר רשימת משאלות קהילתית 2023/תכונת עריכה-שחזור
 | The Community Wishlist is now open
The new רשימת משאלות קהילתית (formerly סקר משאלות הקהילה) is now open for new wish submissions. We have an update on what to expect, and how to submit a wish. Read more. |
תכונת שחזור עריכה  | |
|---|---|
 | |
| שחזור עריכות שלא נשמרו שאבדו במהלך העריכה. | |
| קבוצה: | טכנולוגיה למען הקהילה |
| חברי צוות: | Joydeep Sengupta, Dayllan Maza, Harumi Monroy, MusikAnimal, Sam Wilson, Karolin Siebert, Sandister Tei, Sammy Tarling |
| מנהיג: | Joydeep Sengupta, Dayllan Maza and Karolin Siebert (Product Owners) |
תכונת שחזור עריכה (שנקראה בעבר תכונת שמירה אוטומטית) הייתה המשאלה השמינית בסקר רשימת המשאלות של הקהילה לשנת 2023. תכונה זו שומרת טקסט ויקי ומידע אחר מטופסי עריכה בזמן ההקלדה, ומאפשרת שחזורו לאחר סגירת הדפדפן בטעות, או הפסקת חשמל או רשת או קריסת דפדפן. בקשות לפונקציונליות זו הוגשו יותר מפעם אחת.
דף זה מתאר את גישתה של טכנולוגיה למען הקהילה לטיפול בצרכים המובעים בהצעת משאלה זו, וכן בהתחשב בדיונים קודמים סביב הבקשה.
התכונה הופעלה בכל אתרי הויקי וניתן להפעיל אותה על ידי מעבר לתפריט העדפות Special:Preferences. אנא השאר משוב בדף השיחה כאן.
קישורים שימושיים:
- Community Wishlist Survey 2023/Editing/Auto-save feature - הצעת רשימת משאלות מקורית
- mw:Help:Edit Recovery — דף עזרה למשתמש הקצה
- mw:Manual:Edit Recovery - תיעוד טכני
רקע ומרחב הבעיה
היסטוריה
פונקציונליות שחזור עריכה התבקשה בסקר 2016 ולאחר מכן בסקר גרסת 2022.
בנוסף, בשנת 2012 הוגשה תקלה עבור תכונת השמירה האוטומטית הזו ב-localStorage והופעל תיקון. גודל localStorage הוגבל לכ-5MB ויכול היה להכיל רק מחרוזות; התיקון ננטש בשנת 2017.
מאוחר יותר בשנת 2014 הוגשה תקלה עבור תכונת השמירה האוטומטית הזו בניסיון להוסיף שמירה אוטומטית באמצעות IndexedDB. תיקון זה ננטש גם הוא בשנת 2016.
היה דיון ש-sessionStorage אובד כשעוברים לכרטיסייה חדשה, כך ש-localStorage יהיה שיפור. הבעיה עם localStorage היא שיש מגבלת גודל, וסביר להניח ששמירה אוטומטית מרובת תעלה עליה.
אפשרות נוספת היא לאחסן את נתוני השמירה האוטומטית בצד השרת, שם לא תהיה מגבלת גודל ושחזור נתונים יוכל להתבצע גם במכשיר נפרד.
בשנת 2022, קהילת הטכנולוגיה פתחה בחקירה כדי לבחון את ממשק ה-API של StashEdit כפתרון אפשרי. משמעות הדבר היא אורך חיים של שמירה אוטומטית של בין 5 דקות לחצי שעה. לחלופין, ניתן ליצור טבלת מסד נתונים חדשה, ובמקרה כזה אורך החיים יכול להיות עד 90 יום.
אפשרויות יישום
לצורך משאלה זו, בחנו מספר דרכים שונות ליישם אותה. הבדל עיקרי בין אלה היה מיקום נתוני השמירה האוטומטית: האם הם מאוחסנים רק במכשיר המשתמש (מה שאנו מכנים 'צד הלקוח'), או מועברים לשרתי ויקימדיה ('צד השרת'). ראו להלן את החששות המשפטיים הקשורים לראשונים.
- בהתבסס על מחסן עריכה —
מגבלת הזמן אינה מספקת - While a user is editing a wiki page, every three seconds the page text is sent to the server as an 'edit stash'. This feature exists so that when the page is finally saved it is quicker to view because the wikitext has already been rendered to HTML. We wondered if we could leverage this feature by making it possible to retrieve the stashed wikitext when re-opening an edit session. This would involve a) increasing the time that the stashed edits are stored for (currently only five minutes); b) changing the stashedit API so that it'd return the wikitext given the unique hash of the content; and c) storing that hash in localStorage in the browser. Apart from not being a great idea to hack an existing feature to do something quite unrelated, this method would be limited to storing the autosave data for something around half an hour, which is not enough.
- טבלת מסד נתונים חדשה ו-API — חששות מסובכים בנוגע לפרטיות
- A whole new database schema and API could be created to store the autosave data. This would be the most flexible and powerful, allowing autosaves to be linked to users and stored indefinitely (much as Phabricator does it). However, with that comes a lot of complexity in devlopment, as well as concerns about data access (see below for the legal issues), and the worry that this would become a 'drafts' feature by another name. The data retention time would be limited to 90 days.
- צד לקוח מלא —
פרטי, מגן מפני אובדן קישוריות, פשוט יותר - Browsers have three main mechanisms for storing data: sessionStorage, localStorage, and IndexedDB. The first has a reasonably large storage quota but applies only to the 'page session' so is deleted after you close a tab. The second has a much smaller quota which is shared between all of a wiki's usages of localStorage and so also isn't suitable. The last, indexedDB, is most useful, as it allows for lots of data to be stored and persists even if the browser is closed or crashes etc. This is the most promising system to use for autosave, although there are still issues to be considered (such as how to reliably delete the data after it's no longer required).
The other aspect of implementation that we considered was where to build the feature: in MediaWiki core, or in an extension (either new or existing). We settled on Core, for a number of reasons:
- Extension
- There was no existing extension that was an obvious good fit for Edit Recovery, so the option was to create a new one. An extension would be suitable if the codebase will become large or have other dependencies, but we didn't think this very likely. It could also make deployment more complicated, as it'd have to undergo security review and the full new-deployment process.
- MediaWiki Core
- Features added to core should be applicable to every MediaWiki installation (including non-Wikimedia ones), regardless of what extensions it has installed. They may also be used by extensions, and so having them in core means that those extensions don't need to have extra dependencies on other extensions.
Legal considerations
In previous work around this topic, concerns have been raised about the possibility of people using a private data storage feature for undesirable purposes (for example, sharing an account username and password and then passing data via the autosave feature).
Community Tech asked WMF Legal to weigh in on this, and their analysis was that there are not any strict legal reasons to not build such a feature, but that a few points need to be kept in mind:
- A time limit on the time that the data is stored, with a maximum of 90 days (in line with other private data retention within Wikimedia).
- A way for Trust and Safety to access the data for a given user, if a court requests it (this is common in other systems with this sort of feature, such as email drafts).
- For all of a user's data to be able to be deleted if they request it.
These concerns do not apply if the data is stored client-side, because the data stays on the user's device and is their own responsibility.
Not a 'drafts' feature
One aspect we're very clear that we want to avoid is that it end up being a system for maintaining private drafts of pages. There is a long history around that topic, but the autosave wish is specifically around shorter-term recovery of in-progress edits.
Feature details
Summary: It is possible to close an in-progress edit form (via closing the window, the browser crashing, etc.) and have all data restored when you re-open that same page for editing again (at any later time).
- A page is identified by its title (so if a page is moved during an editing session, the recovery happens at the old name).
- A section of a page is identified by its number (so if a section is added or removed by a different user, the recovery might happen for the wrong section, or not happen at all). It's not possible to edit a section of an old revision.
- While editing, all edit form values are saved to the browser's IndexedDB storage. This is done after every one-second pause in typing, or any time a non-typing field (checkbox etc.) is changed. All core content types are supported (Wikitext, JavaScript, JSON, & CSS), and extensions may provide or remove support for edit recovery as they see fit.
- If a page (or section) is opened for editing and there is saved recovery data, it is loaded into the form.
- The edit-recovery data (for a page and all of its sections) is deleted in a few different situations:
- after a page is published;
- when the Cancel link is clicked;
- when the user logs out;
- when the user switches from wikitext to visual editing (Visual Editor has its own edit-recovery system);
- After edit-recovery data is loaded the page will show the normal 'are you sure' warning when the user tries to navigate away (even if no further changes have been made).
- If an editing session is underway for a page, and the user navigates away (or opens a separate tab) to edit an old version of the page, then the recovery data is not loaded and no changes to old revisions will be stored.
Still to be decided: What happens when someone edits the same page at the same time in two different tabs?
Updates
16 אוקטובר 2024: עדכון על שחזור עריכה
Thank you all for your valuable feedback on the Edit Recovery feature! We’ve made some important improvements based on your comments on the Edit Recovery talk page. Previously, the feature would automatically recover changes by default when you resume editing and then give you the option to revert them as the next step. With this update, you'll be asked first if you want to recover changes or not. Now, editors have more control over their workflow.
For a visual demonstration of these changes, please refer to the screenshots below:
-
Previous Version: Changes were automatically restored, editors had to discard the changes if they didn't want them. -
New version: Editors are notified of unsaved changes and have the choice to recover or discard changes.
16 ספטמבר 2024: התבקש משוב על עריכה-שחזור
Hello community, the Edit-Recovery feature has been active in Special:Preferences, Editing since spring 2024, and based on feedback, we wanted to ask how the feature should behave moving forward.
Currently, Edit-Recovery assumes that a user wants to recover their edits upon reloading or reopening a page, and prompts users to discard their edits. However, based on feedback on our Talk page, some users would prefer for Edit-Recovery to assume that a user does not want to recover edits, and instead, they should be prompted to restore edits.
The Community Tech team, at this stage, seeks community input on whether Edit-Recovery works as expected, or if users would prefer for Edit-Recovery to prompt users to restore edits.
Please provide feedback on the talk page. We hope to make a decision by Wednesday, 26 September 2024.
October 25, 2023 – Edit-Recovery is now available for testing in Beta
Hello community, we have some updates. Edit-Recovery wish (formerly known as Auto-save feature) is now available on Beta Cluster, and you are invited to test it.
Start editing any page on any Beta site, for example simple.wikipedia.beta.wmflabs.org, but don't publish your change. Wait 5 seconds and close the tab. Reopen the tab. Your edit should be recovered!
We are working to make the feature more visible with an element like a toast notification when restoring edit data, with the option of discarding the recovered data.
Questions and feedback are welcome.
Thank you, Community Tech Team
––– STei (WMF) (talk) 17:28, 25 October 2023 (UTC)
July 4, 2023 – Investigations and your input
The CommTech team is reviewing any investigations, discussions, patches that have happened around this wish to determine what is next.
We have would like you to answer some questions as follows:
- How long do we need to save the data for the auto-save functionality (Keeping in mind legal matters, as legal implications are reduced by reducing the amount of time we store edits)?
- What should we store in the database to be able to make autosave functionality work? I.e:
- עריכות
- גרסאות
- דפים
- טקסט
Please leave your responses on the talkpage if you have any.