Wikimedia Meta-Wiki

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

< Community Wishlist Survey 2023
This page is a translated version of the page Community Wishlist Survey 2023/Edit-recovery feature and the translation is 100% complete.
Other languages:

편집 복구 기능(이전에는 자동 저장 기능으로 알려짐)은 2023년 커뮤니티 위시리스트 설문조사에서 8번째 희망 기능이었습니다. 이 기능은 입력하는 동안 위키 텍스트 및 기타 편집 양식 정보를 저장하고 브라우저가 실수로 닫힌 후 복원할 수 있도록 해줍니다. 또는 정전이나 네트워크 중단 또는 브라우저 충돌이 발생했습니다. 이 기능에 대한 요청이 두 번 이상 이루어졌습니다.

편집 복구 기능 Translate
편집하는 동안 손실된 저장되지 않은 편집 내용을 복구합니다.
그룹:커뮤니티 기술
팀원:Joydeep Sengupta, Dayllan Maza, Harumi Monroy, MusikAnimal, Sam Wilson, Karolin Siebert, Sandister Tei, Sammy Tarling
리드:Joydeep Sengupta, Dayllan Maza and Karolin Siebert (Product Owners)

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

이 기능은 모든 위키에서 활성화되어 있으며 특수:기본 설정으로 이동하여 활성화할 수 있습니다. 여기 토론 페이지에 피드백을 남겨주세요.

유용한 링크:

배경 및 문제 공간

역사

편집 복구 기능은 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.

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

2024년 10월 16일: 편집 복구에 대한 업데이트

편집 복구 기능에 대한 귀중한 피드백을 보내주신 모든 분들께 감사드립니다! 편집 복구 토론 페이지에 대한 여러분의 의견을 바탕으로 몇 가지 중요한 개선 사항을 만들었습니다. 이전에는 편집을 재개하면 기본적으로 이 기능이 자동으로 변경 사항을 복구한 다음 다음 단계로 되돌릴 수 있는 옵션을 제공했습니다. 이 업데이트에서는 먼저 변경 사항을 복구할지 여부를 묻습니다. 이제 편집자는 워크플로를 더 잘 제어할 수 있습니다.

이러한 변경 사항에 대한 시각적 데모를 보려면 아래 스크린샷을 참조하세요:

  •  
    이전 버전: 변경 사항은 자동으로 복구되었으며, 편집자는 원하지 않으면 변경 사항을 삭제해야 했습니다.
  •  
    새 버전: 편집자는 저장되지 않은 변경 사항에 대한 알림을 받고 변경 사항을 복구하거나 삭제할 수 있습니다.

2024년 9월 16일: 편집-복구 피드백 요청됨

안녕하세요 커뮤니티 여러분, 편집-복구 기능은 2024년 봄부터 Special:Preferences, 편집에서 활성화되었으며, 피드백을 바탕으로 이 기능이 앞으로 어떻게 작동해야 하는지 묻고자 합니다.

현재 편집-복구는 사용자가 페이지를 다시 로드하거나 다시 열 때 편집 내용을 복구"하고자 한다"고 가정하고 사용자에게 편집 내용을 삭제하도록 요청합니다. 그러나 토론 페이지의 피드백을 바탕으로 일부 사용자는 편집-복구가 사용자가 편집 내용을 복구하기를 "원하지 않는다"고 가정하고 대신 편집 내용을 "복원"하라는 메시지를 표시하기를 원합니다.

이 단계에서 커뮤니티 기술팀은 편집-복구가 예상대로 작동하는지, 아니면 사용자가 편집-복구에서 편집 내용을 "복원"하라는 메시지를 표시하는 것을 선호하는지에 대한 커뮤니티 의견을 구합니다.

토론 페이지에 피드백을 제공해 주세요. 2024년 9월 26일 수요일까지 결정을 내리기를 바랍니다.

October 25, 2023 – 이제 편집-복구를 베타 테스트에 사용할 수 있습니다.

안녕하세요 커뮤니티 여러분, 몇 가지 업데이트가 있습니다. 편집-복구 희망 사항(이전에는 자동 저장 기능)을 이제 베타 클러스터에서 사용할 수 있으며 테스트해 보시기 바랍니다.

베타 사이트의 모든 페이지(예: [https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page simple.wikipedia.beta.wmflabs.org) 편집을 시작하고 변경 사항을 게시하지 마세요. 5초 동안 기다린 후 탭을 닫습니다. 탭을 다시 엽니다. 편집 내용이 복구되어야 합니다!

우리는 편집 데이터를 복원할 때 토스트 알림과 같은 요소와 복구된 데이터를 삭제하는 옵션을 통해 이 기능을 더 눈에 띄게 만들기 위해 노력하고 있습니다.

질문과 피드백을 환영합니다.

감사합니다, 커뮤니티 기술 팀 ––– STei (WMF) (talk) 17:28, 25 October 2023 (UTC)[reply]

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)

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Edit-recovery_feature/ko&oldid=27777977"