커뮤니티 위시리스트 설문조사 2023/편집 복구 기능

편집 복구 기능
편집하는 동안 손실된 저장되지 않은 편집 내용을 복구합니다.
그룹:	커뮤니티 기술
팀원:	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년 커뮤니티 위시리스트 설문 조사에서 8번째 희망 사항이었습니다. 이 기능은 입력하는 동안 위키 텍스트 및 기타 편집 양식 정보를 저장하고 브라우저가 실수로 닫히거나 전원 또는 네트워크 중단 또는 브라우저 충돌이 발생한 후 복원할 수 있습니다. 이 기능에 대한 요청이 두 번 이상 이루어졌습니다.

이 페이지는 요청에 대한 이전 논의를 고려할 뿐만 아니라 이 희망 사항의 제안에 표현된 요구 사항을 해결하기 위한 커뮤니티 기술의 접근 방식을 간략하게 설명합니다.

피드백이 있다면 남겨주세요.

Useful links:

• 커뮤니티 위시리스트 설문조사 2023/편집/자동 저장 기능 — original wishlist proposal
• mw:Help:Edit Recovery — end-user help page
• mw:Manual:Edit Recovery — technical documentation

배경 및 문제 공간

역사

편집 복구 기능은 2016년 설문조사와 2022년 설문조사에서 요청되었습니다.

또한 2012년에 localStorage에서 이 자동 저장 기능에 대한 티켓이 제출되었고 패치가 시작되었습니다. localStorage 크기는 약 5MB로 제한되었고 문자열만 포함할 수 있었습니다. 패치는 2017년에 중단되었습니다.

2014년 후반에 IndexedDB를 사용하여 자동 저장을 추가하려는 시도와 함께 이 자동 저장 기능에 대한 티켓이 제출되었습니다. 이 패치도 2016년에 중단되었습니다.

localStorage가 개선되도록 새 탭으로 전환하면 sessionStorage가 손실된다는 논의가 있었습니다. localStorage의 문제점은 크기 제한이 있고 여러 자동 저장이 이를 초과할 가능성이 있다는 것입니다.

또 다른 옵션은 자동 저장 데이터를 서버 측에 저장하는 것입니다. 여기서 크기 제한이 없고 데이터 복구도 별도의 장치에서 수행할 수 있습니다.

2022년 커뮤니티 기술은 가능한 솔루션으로 StashEdit API를 조사하기 위해 조사를 시작했습니다. 이것은 대략 5분에서 30분 정도의 자동 저장 수명을 의미합니다. 또는 수명이 최대 90일인 경우 새 데이터베이스 테이블을 만들 수 있습니다.

구현 옵션

이를 위해 이를 구현하는 몇 가지 다른 방법을 살펴보았습니다. 이들의 주된 차이점은 자동 저장 데이터의 위치였습니다. 데이터가 사용자의 기기에만 저장되는지('클라이언트 측'이라고 함) 위키미디어 서버로 전송되는지('서버 측')입니다. 전자와 관련된 법적 문제는 아래를 참조하십시오.

편집 숨김 기반 구축 —  시간 제한 부족

사용자가 위키 페이지를 편집하는 동안 3초마다 페이지 텍스트가 '편집 숨김'으로 서버에 전송됩니다. 이 기능은 위키텍스트가 이미 HTML로 렌더링되었기 때문에 페이지가 최종적으로 저장될 때 더 빨리 볼 수 있도록 하기 위해 존재합니다. 편집 세션을 다시 열 때 숨겨진 위키 텍스트를 검색할 수 있도록 하여 이 기능을 활용할 수 있는지 궁금했습니다. 여기에는 a) 숨겨진 편집 내용이 저장되는 시간(현재 단 5분)을 늘리는 작업이 포함됩니다. b) 콘텐츠의 고유한 해시가 주어진 위키텍스트를 반환하도록 stashedit API를 변경합니다. c) 해당 해시를 브라우저의 localStorage에 저장합니다. 관련 없는 작업을 수행하기 위해 기존 기능을 해킹하는 것은 좋은 생각이 아니라는 점 외에도 이 방법은 자동 저장 데이터를 약 30분 동안 저장하는 것으로 제한되며 이는 충분하지 않습니다.

새로운 데이터베이스 테이블 및 API —  복잡한 개인 정보 보호 문제

자동 저장 데이터를 저장하기 위해 완전히 새로운 데이터베이스 스키마와 API를 생성할 수 있습니다. 이것은 가장 유연하고 강력하여 자동 저장을 사용자에게 연결하고 무기한 저장할 수 있습니다(파브리케이터가 하는 것처럼). 그러나 이로 인해 데이터 접근에 대한 우려(법적 문제는 아래 참조) 및 이것이 다른 이름으로 '초안' 기능이 될 것이라는 우려뿐만 아니라 개발 과정에서 많은 복잡성이 발생합니다. 데이터 보존 기간은 90일로 제한됩니다.

완전히 클라이언트 측 —  비공개, 연결 손실 방지, 단순

브라우저에는 데이터 저장을 위한 세 가지 주요 메커니즘인 sessionStorage, localStorage 및 IndexedDB가 있습니다. 첫 번째는 상당히 큰 스토리지 할당량을 갖지만 '페이지 세션'에만 적용되므로 탭을 닫으면 삭제됩니다. 두 번째는 위키의 모든 localStorage 사용 간에 공유되는 할당량이 훨씬 적기 때문에 적합하지 않습니다. 마지막 indexedDB는 브라우저가 닫히거나 충돌하는 등의 경우에도 많은 데이터를 저장하고 지속할 수 있으므로 가장 유용합니다. 여전히 고려해야 할 문제가 있지만 자동 저장에 사용할 가장 유망한 시스템입니다(더 이상 필요하지 않은 데이터를 안정적으로 삭제하는 방법 등).

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

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:

• 자동 저장 기능을 사용하려면 얼마나 오래 데이터를 저장해야 하나요(편집 내용을 저장하는 시간을 줄임으로써 법적인 영향이 줄어들므로 법적인 문제를 염두에 두십시오)?
• 자동 저장 기능을 작동시키려면 데이터베이스에 무엇을 저장해야 합니까? 즉:
  • 편집
  • 개정
  • 페이지
  • 텍스트

답변이 있으시면 토론 페이지에 남겨주세요.

피드백 라운드에 대해 더 많은 유권자/사용자에게 신호를 보냅니다. ––– ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (토론) 2023년 7월 4일(UTC) 10:50

피드백 라운드에 대해 더 많은 유권자/사용자에게 다시 핑합니다. ––– ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (토론) 2023년 7월 5일 16:33(UTC)