Consultation des souhaits de la communauté pour 2023/Fonction d'enregistrement automatique des éditions

La fonctionnalité Récupération d'édition (précédemment connue sous le nom de Sauvegarde automatique) était le #8 souhait dans le Sondage sur les souhaits de la communauté 2023. Cette fonctionnalité enregistre le wikitext et d'autres informations du formulaire d'édition pendant la saisie, et permet de les restaurer après que le navigateur a été accidentellement fermé, ou qu'une panne d'électricité ou de réseau ou un crash du navigateur s'est produit. Cette fonctionnalité a été demandée à plusieurs reprises.

Fonctionnalité d'enregistrement automatique
Récupérer les modifications non enregistrées, perdues durant l'édition.
Groupe :	Équipe Technologies communautaires
Membres de l’équipe :	Joydeep Sengupta, Dayllan Maza, Harumi Monroy, MusikAnimal, Sam Wilson, Karolin Siebert, Sandister Tei, Sammy Tarling
Direction :	Joydeep Sengupta, Dayllan Maza and Karolin Siebert (Product Owners)

Cette page présente l'approche de Community Tech pour répondre aux besoins exprimés dans la proposition de ce vœu, ainsi que les discussions antérieures autour de la demande.

Vous pouvez tester l'état actuel de la nouvelle fonctionnalité sur Test Wikipedia. Veuillez laisser vos commentaires sur la page de discussion ici. La fonctionnalité sera activée sur d'autres wikis à partir de février 2024.

Liens utiles :

• Consultation 2023 des souhaits de la communauté/Rédaction/Enregistrement automatique - proposition originale de liste de souhaits
• mw:Help:Edit Recovery - page d'aide pour l'utilisateur final
• mw:Manual:Edit Recovery - documentation technique

Contexte et problématique

Historique

La fonctionnalité de récupération des modifications a été demandée dans l'enquête 2016, puis dans l'édition 2022.

En outre, en 2012, un ticket a été soumis pour cette fonctionnalité de sauvegarde automatique dans localStorage et un correctif a été lancé. la taille de localStorage était limitée à environ 5MB et ne pouvait contenir que des chaînes de caractères ; le correctif a été abandonné en 2017.

Plus tard en 2014, un ticket a été soumis pour cette fonctionnalité de sauvegarde automatique avec une tentative de ajouter une sauvegarde automatique en utilisant IndexedDB. Ce correctif a également été abandonné en 2016.

Une discussion a eu lieu sur le fait que le sessionStorage est perdu lorsque l'on passe à un nouvel onglet, de sorte que le localStorage serait une amélioration. Le problème avec localStorage est qu'il y a une limite de taille et que de multiples sauvegardes automatiques risquent de la dépasser.

Une autre option consiste à enregistrer les données de sauvegarde automatique sur le serveur, où il n'y a pas de limite de taille et permettant la récupération des données sur un appareil séparé.

En 2022, l'équipe technique ouvre une enquête pour étudier l'utilisation de l'API de StashEdit comme solution possible. Avec cette solution, la sauvegarde automatique aurait une durée de vie de l'ordre de cinq minutes à une demi-heure. Une autre solution consisterait à créer une nouvelle table de base de données, auquel cas la durée de vie pourrait aller jusqu'à 90 jours.

Options de mise en œuvre

Pour ce souhait, nous avons examiné plusieurs manières différentes de le mettre en œuvre. L'une des principales distinctions était l'emplacement des données de sauvegarde automatique : si elles sont stockées uniquement sur l'appareil de l'utilisateur (ce que nous appelons "côté client"), ou transférées vers les serveurs de Wikimédia ("côté serveur"). Voir ci-dessous les problèmes juridiques liés au premier cas.

Se baser sur edit stash —  durée de vie de la sauvegarde insuffisante

Lorsqu'un utilisateur modifie une page wiki, toutes les trois secondes, le texte de la page est envoyé au serveur sous la forme d'une « réserve d'édition » (en anglais, edit stash). Cette fonction existe pour que, lorsque la page est sauvegardée, elle soit plus rapide à visualiser car le texte du wiki a déjà été rendu en HTML. Nous nous sommes demandés si nous pouvions tirer parti de cette fonctionnalité en rendant possible la récupération du wikicode reçu par le serveur lors de la réouverture d'une session d'édition. Cela impliquerait a) d'augmenter la durée de conservation des modifications sur le serveur (qui n'est actuellement que de cinq minutes) ; b) de modifier l'API de stashedit pour qu'elle renvoie le wikicode à partir du hachage unique du contenu ; et c) de stocker ce hachage dans la mémoire locale du navigateur. Outre le fait que ce ne soit généralement pas une bonne idée de bricoler à partir d'une fonctionnalité existante pour faire quelque chose qui n'a rien à voir, cette méthode se limiterait à stocker les données de sauvegarde automatique pendant environ une demi-heure, ce qui n'est pas suffisant.

Nouvelle table de base de données et API —  laborieux, soulève des problématiques de confidentialité

Un nouveau schéma de base de données et une API pourraient être créés pour conserver les données de sauvegarde automatique. Il s'agit de la solution la plus flexible et la plus puissante, permettant aux sauvegardes automatiques d'être liées aux utilisateurs et conservées indéfiniment (comme le fait Phabricator). Cependant, cela s'accompagne d'un développement complexe, ainsi que de préoccupations concernant l'accès aux données (voir ci-dessous pour les questions juridiques), et l'inquiétude que cela devienne une fonction « Brouillon » sous un autre nom. La durée de conservation des données serait limitée à 90 jours.

Intégralement côté client —  privé, protège des pertes de connexion, plus simple

Les navigateurs disposent de trois mécanismes principaux pour enregistrer temporairement des données : la mémoire de session, la mémoire locale et IndexedDB. La première dispose d'un espace disponible important, mais il ne s'applique qu'à la « session de la page » et est donc supprimé lorsque vous fermez un onglet. La seconde dispose d'un espace beaucoup plus faible, partagé entre toutes les utilisations de la mémoire locale par un wiki et n'est donc pas adaptée. Le dernier, indexedDB, est le plus utile, car il permet l'enregistrement de nombreuses données et leur conservation même lors de la fermeture du navigateur, son blocage, etc. C'est le système le plus prometteur pour la fonctionnalité de sauvegarde automatique, bien qu'il y ait encore des problèmes à prendre en compte (comme la manière de supprimer de manière fiable les données une fois qu'elles ne sont plus nécessaires).

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?

Mises à jour

October 25, 2023 – Edit-Recovery est maintenant disponible pour être testé en Beta

Bonjour la communauté, nous avons des actualités !

Le souhait d’une récupération des modifications (précédemment connu comme fonctionnalité de sauvegarde automatique) est désormais sur la grappe de serveurs bêta, et vous êtes invités à le tester.

Commencez à modifier n'importe quelle page sur n'importe quel site Beta, par exemple [1 $], mais ne publiez pas vos modifications. Attendez 5 secondes et fermez l'onglet. Rouvrez l'onglet. Votre modification devrait être récupérée !

Nous travaillons à rendre la fonctionnalité plus visible avec une notification évanescente lors de la restauration des données de modification, avec la possibilité de rejeter les données récupérées.

Les questions et les commentaires sont les bienvenus.

Remerciements L'équipe technique communautaire ––– 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:

• Combien de temps devons-nous conserver les données pour la fonctionnalité d'enregistrement automatique (en gardant à l'esprit les questions juridiques, car les implications juridiques sont réduites en réduisant le temps de stockage des modifications)?
• Que devrions-nous conserver dans la base de données pour que la fonctionnalité de sauvegarde automatique fonctionne ?
  • Modifications
  • les révisions
  • les pages
  • Texte

N'hésitez pas à laisser une réponse en page de discussion.

Je demande à d'autres votants/utilisateurs de me faire part de leur avis sur le tour de table. --- ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (talk) 10:50, 4 juillet 2023 (UTC)

J'ai demandé à d'autres votants/utilisateurs de me faire part de leur avis sur le tour de table. --- ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (talk) 16:33, 5 juillet 2023 (UTC)