Jump to content

2017 위키텍스트 편집기

이슈 트래커: #VisualEditor-MediaWiki-2017WikitextEditor
From mediawiki.org
This page is a translated version of the page 2017 wikitext editor and the translation is 60% complete.
Languages:

2017 위키텍스트 편집기는 시각 편집기 확장 기능에 있는 모드로 위키텍스트 소스 코드를 편집하면서 사용자가 시각 편집기의 도구와 툴바를 사용할 수 있게 허용합니다. 시각 편집기 내에서 툴바의 버튼을 클릭하여 위키텍스트로 전환할 수 있습니다.

2017 위키텍스트 편집기는 2023년 위키미디어 재단이 호스팅하는 위키에 릴리스되었습니다. 이것은 기본적으로 켜져 있지 않습니다. 환경 설정으로 이동하여 "다른 위키텍스트 편집기 대신 시각편집기 내의 위키텍스트 모드를 사용하기" 확인란을 클릭한 다음 "저장"을 클릭하여 위키미디어 위키에서 사용하도록 선택할 수 있습니다.

이게 뭔가요?

2016-2017년 연간 계획의 목표 중 하나인 "현재의 콘텐츠 생성 및 큐레이션 인터페이스를 유지 관리하고 점진적으로 개선하기"를 지원하기 위해 편집부는 새로운 위키텍스트 편집기를 작업하고 있습니다.

이 둘 사이를 더 잘 전환할 수 있도록 시각편집기에 통합되어 있습니다. 디자인이 유사하며, citoid 서비스를 포함하여 시각편집기에 존재하는 도구들 다수를 갖추고 있습니다. 데스크톱 사용자는 새로운 위키텍스트 편집 모드를 사용할 수 있습니다. 파브리케이터의 주요 작업은 작업 T104479입니다(이 소프트웨어는 때때로 "모던 위키텍스트 편집기" 또는 "새 위키텍스트 편집기"/"NWE"라고도 함).

이것은 기존 위키텍스트 편집기를 수정한 것이 아닌 새로운 편집기입니다. As the editor is based on VE surface, and not a standard textarea, then many of the editing gadgets do not work with that (it requires using very specific API to access wikicode). Gadgets that open an edit form and require a textarea can switch to plain wikicode editor using action=submit (rather than action=edit).

이 프로젝트의 원인은 무엇입니까?

2010년에 위키미디어 재단은 사용성 프로젝트(현재 벡터 스킨, 업로드 도구 및 2010 wikitext editor 제공)를 완료하고 2010-2015 전략에서 커뮤니티가 선택한 문제로 전환했습니다. 여기에는 알림 및 기타 개선 사항과 함께 편집 도구, 특히 시각편집기에 대한 여러 가지 개선 사항이 포함되었습니다. 그러나 그 전략은 위키텍스트를 대체하는 것이 아니며 그런 적도 없습니다. 우리는 커뮤니티가 위키미디어 프로젝트를 지금처럼 성공적으로 만들 수 있도록 장기적으로 두 편집 시스템 모두가 중요하다고 생각합니다.

2016년 12월 기준으로, 거의 모든 위키미디어 위키에서 세 가지 주요 내용 편집기를 제공합니다. 외관, 작동, 성능, 도움말 및 지원 면에서 사용자에게 일관성이 없습니다. 그 중 하나는 WikiEditor라고 하는 2010년대 ​​데스크톱 위키텍스트 편집기이고, 다른 하나는 데스크탑 및 모바일 형식의 시각편집기이며, 마지막 하나는 기본 모바일 위키텍스트 편집기입니다.

2010년부터 우리는 새로운 사용자와 경험이 있는 사용자 모두가 우리 소프트웨어를 사용하는 방법과 그들이 우리 편집 소프트웨어에서 변경되기를 바라는 점에 대해 많은 것을 배웠습니다. 우리의 연구는 편집자에게 잘 작동하는 디자인을 중심으로 시각편집기를 구성하는 정보를 제공하여 새로운 사용자에게 사용 방법에 대한 명확한 신호를 제공하는 동시에 이미 알고 있는 WikiEditor를 선호하는 숙련된 사용자를 방해하지 않습니다. 완벽하진 않지만 저희는 새 사용자들로부터 시각 편집기 디자인, 워크플로 큐, 전반적 경험의 강력한 선호를 관찰해왔습니다. 공학적인 부문에서 저희는 많은 것을 학습했으며 문서("원본 편집" 클릭 시)나 도구(예: 플로)에서, 데스크톱이나 모바일에서 사용할 수 있도록, 또 다른 기능에 의해 확장가능한 방식으로 개발하고 있습니다.

3가지 일정치 않은 편집 시스템을 보유하고 있는 것은 좋지 않습니다. 한 편집기로 배워왔던 새로운 편집자들은 다른 상황(예: 토론 문서 편집)에 적용하기 어렵기 때문에 좋지 않습니다. 숙련된 편집자에게는 초보자에게 어떤 상황인지, 그리고 어떻게 도움을 줄 수 있는지 알아내기 전에 몇 가지 질문에 답해야 하기 때문에 좋지 않습니다. 관리자의 경우 편집자별로 자신들의 공동체가 요구하는 바를 별도로 구축하거나 일부 편집기에서 가져올 수 없는 것을 발견할 필요가 있으므로 좋지 않습니다. 스크립트 및 소도구 개발자의 경우 각기 다른 수많은 상황을 다루거나 무시해야 하므로 좋지 않습니다. 개발자의 경우 무언가를 고치고 기능을 추가할 때마다 복잡성이 3배나 증가하는 것을 고려해야 하기 때문에 좋지 않습니다. 위키미디어 재단의 기부자들의 경우 기부금이 이러한 복잡한 병행 작업 스트림 지원에 쓰여야 하기 때문에 좋지 않습니다.

결과적으로, 우리는 새로운 위키텍스트 편집기인 2017 위키텍스트 편집기를 개발 중입니다. 이것은 데스크톱과 모바일, 그리고 위키텍스트와 시각편집기 사이에 통합되고 일관된 단일 경험을 제공할 것입니다. 경험을 가능한 여러 상황 간에 가능한 일치시킬 수 있도록 다른 편집기에도 통합이 가능한 플랫폼이 될 예정입니다. 기존 기능에 발생되는 문제를 제한하면서 사용자에게 가능한 좋은 경험을 제공할 예정입니다.

마음에 들지 않는 사용자는 끌 수 있습니다. 현재의 위키텍스트 편집기는 적어도 앞으로 수년 간은 사라지지 않습니다. 우리가 궁극적으로 이 기능을 철수시키더라도 해당 기능을 원하는 누구든지 해당 기능을 유지할 수 있습니다.

개발 목표 및 상태

첫 번째 버전 (베타 기능)

프로젝트의 초기 목표는 사용자가 일관된 경험을 가질 수 있도록 시각편집기와 동일한 위치에 동일한 버튼이 있는 동일한 도구 모음을 사용하여 기존 위키텍스트 편집기인 WikiEditor와 동등하게 만드는 것이었습니다. 이것은 매우 드문 버튼을 제외하고는 위키텍스트 편집기에서 최소한 모든 컨트롤을 제공한다는 것을 의미합니다.

  • 기본 도구 (굵게, 기울임, 서명, 링크와 사진);
  • 고급 도구(문단, 글머리 기호 목록, 번호가 매겨진 목록, 크게, 작게, 위 첨자와 아래 첨자, 갤러리와 표);
  • 특수문자 삽입; 그리고
  • 찾아서 바꾸기

이 모든 것은 2016년 8월에 완료되었으며 기존 위키텍스트 편집기에는 없는 많은 도구(취소선, 밑줄, 템플릿 삽입 등)와 붙여넣은 HTML과 같은 기능이 자동으로 위키텍스트로 변환됩니다. 특히, 사용자가 URL 또는 DOI를 기반으로 참조를 빠르게 추가할 수 있는 "citoid" 자동 인용 도구도 제공합니다. 이 기능은 영어 위키백과와 다른 일부 위키가 이미 자체적으로 개발한 소도구와 비슷하거나 더 진보화된 것이며 이제 모든 위키에서 사용할 수 있게 됩니다.

저희는 기능이 예측한 대로 동작하는지, 그리고 검토 및 구조화된 사용자 테스트에 관한 광범위한 QA 테스트에 착수했습니다. 의도한 대로 적절히 동작한다고 생각되면, 그리고 (적어도) 새 사용자에게 더 부정적인 부분이 없다면 베타 기능을 통해 모든 수준의 숙련된 사용자들로부터 의견을 구할 것입니다.

마지막 베타 버전 (일반 배포 전)

The point of the first release as a Beta Feature is to get some initial feedback on how well this new editor works for people. We expect the feedback to include a lot of suggestions for changes. There are a number of improvements that we're already considering. Some of these probably need to be addressed before the new wikitext editor would be released outside of a Beta Feature. Some of these are technically difficult and so have been postponed, whilst others would benefit from real-world feedback from existing users to shape the features as usefully as possible.

For the first category (big challenges), we believe that we will need to address section editing, in which clicking edit will show small parts of the page to edit, and a fully responsive design, so that the interface can scale up and down more cleanly for smaller devices, where users are zoomed-in, or other accessibility and platform reasons; these will let us provide the feature in mobile as a beta example as well, to ensure it works for all our editors, not just those on desktop.

For the second category (feedback needed), we will need to provide in-editor help to guide users through the editing process from the very first time they click edit to later in their editing careers. Right now the wikitext editor has a "help" tab with some brief wikitext guidance; in the visual editor, we have a link to the user-guide, which we could replicate for this purpose. How this should work, and what it should highlight, is likely to be something on which many members of our communities have expert ideas. We will also need to clean up how gadgets extend the editor, as the new editor integration right now is complex and confusing. This would make converting some gadgets harder than it should be. Many wiki communities depend on particular gadgets to speed up their editing workflow, and we need to preserve the ability for wikis to flexibly experiment with improvements like this.

Naturally, any change of this scale is likely to be disruptive for some users' workflows, and will have a few issues with relative 'edge cases' not being addressed. We look forward to uncovering and addressing these over the weeks and months following the release of the Beta Feature.

Nice-to-haves

Alongside the above, there are other, new features we'd love to provide if possible, but which may prove too costly to develop or too slow for users, and so are not planned from the outset. One feature we'd be interested in providing is saving automatic local drafts as users edit, so that if their browser or computer crashes or loses power mid-edit, they can resume rather than having to restart. This would rescue users from quite frustrating, if uncommon, occurrences, particularly people with old computers or poor network connections.

A big feature that often gets discussed is syntax highlighting of wikitext to help guide people's eyes to the right content for which they're looking. This feature was built for the existing wikitext editor back in 2011, but we had to abandon it because the very high complexity of wikitext means that this was exceedingly slow for most users. Five years later, most users' machines are a fair bit faster than they were back then, which helps a little. Also, it might be worth exploring how performant we could make a feature doing this if we were to make some simplifications of the kinds of wikitext which we try to highlight.

(In the meantime, syntax highlighting is provided by Remember the dot's syntax highlighter and WikEd , which are available on some wikis as gadgets). Syntax highlighting has also been introduced gerrit:343878 to the 2017 wikitext editor using Extension:CodeMirror .

More complex and error-prone than syntax highlighting, but possibly even more useful, would be a feature for folding wikitext structures into blocks so that users can easily ignore things they don't want to edit without having to read through them. For example, long infobox invocations or references could be folded up into blocks until you want to edit them. The technologies we built for the visual editor are particularly well-suited for providing this use case in a reliable fashion, so this may be something we could look at doing. Again, as with syntax highlighting we might need to compromise on the complexity of wikitext that we recognize in return for providing something performant enough to be useful to most of our users.

Another nice feature we could provide would be to prompt users when they save with two or three buttons to add one-click edit summaries based on their recent activities. This kind of feature is quite popular on some wikis as a gadget and it would be nice to provide it to all users on all wikis, without those wikis needing to have a gadget guru on hand to help set it up and maintain it.

참고자료


같이 보기

Retrieved from "https://www.mediawiki.org/w/index.php?title=2017_wikitext_editor/ko&oldid=6531022"