위키백과:고급 기사 편집

이것은 에세이입니다.

여기에는 한 명 이상의 위키백과 기여자의 조언이나 의견이 포함되어 있습니다.이 페이지는 백과사전 기사도 아니고, 위키백과의 정책이나 지침 중 하나도 아닙니다. 커뮤니티의 철저한 검증이 이루어지지 않았기 때문입니다.일부 에세이는 광범위한 규범을 나타내고, 다른 에세이는 소수의 관점만을 나타냅니다.

지름길

WP:EDITFAST

위키백과 문서의 편집을 개선하는 데 도움이 되는 몇 가지 고급 기술이 있습니다.여기에 제공되는 대부분의 팁은 일반적인 브라우저 설정 및 나란히 편집하는 경우와 같은 표준 텍스트 편집기 사용과 관련이 있습니다.사용자 정의 편집을 허용하는 특수 소프트웨어 패키지가 존재하지만 일반적으로 다른 컴퓨터를 사용하여 Wiki를 편집하는 경우에는 사용할 수 없습니다.

더 빠른 디스플레이

사용자 환경설정

편집 도구 모음 숨기기 – 편집 도구 모음을 해제하면 짧은 편집 페이지가 2배에서 4배 더 빨리 나타날 수 있습니다(오른쪽 버튼으로 상단 옵션 "내 기본 설정", 탭 "편집"을 차례로 클릭한 다음 "편집 도구 모음 표시" 옵션을 클릭합니다).
참고: 일부 기사 소개 섹션에는 모든 상위 이미지가 포함되어 있지 않으므로, 일부 기사 전체를 편집하는 것이 이미지 배치를 개선하는 데 더 빠를 수 있습니다.

기사의 느린 부분 건너뛰기

"미리보기 표시"를 누른 후, 미리보기 중에 모든 번거로운 테이블 또는 탐색 상자를 다시 포맷해야 하지만 주석 또는 #ifeq를 추가하여 건너뛸 수 있습니다.
일반적으로 기사 미리보기의 S-L-O-W-N-E-S-S를 두 배(또는 세 배)로 하는 거대한 하단 탐색 상자에 대해 언급하는 것을 고려해 보십시오. 하단 탐색 상자 템플릿 코딩 주위에 ""를 배치하기만 하면 됩니다. (고속 인터넷에서도 대형 탐색 상자를 로드하는 데 시간이 오래 걸립니다.)
MediaWiki #ifeq-문을 사용하여 텍스트를 조건부로 건너뛰는 것을 고려해 보십시오. 마크업 언어를 사용하여 생략된 섹션을 "{#if: skip part 1"로 둘러싸고 "}"로 끝냅니다."1부 건너뛰기"만 표시됩니다.HTML 주석을 중첩할 수는 없지만 #ifeq-문은 스팬 텍스트가 세로 막대 "" 또는 "}" 텍스트의 사용을 방해하지 않는 한 중첩할 수 있습니다.
반복적인 변경 및 미리 보기를 위해 문서의 문제가 되는 섹션을 테스트 페이지에 붙여넣어 보십시오. 사용자 공간 페이지(User:XXX/TestZZ)로 편집하고, 반복적인 변경 및 미리 보기를 위해 일부 텍스트를 복사/붙여넣습니다.항상 "edit-TestZZ" 창이 나타납니다.
참고: 광범위한 테스트를 위해 문서의 복사된 부분은 편집을 위해 한 섹션만 있는 것이 아니라 두 섹션 또는 세 섹션에 걸쳐 있는 경우가 많습니다.정확한 미리 보기를 위해 충분한 섹션을 복사해야 합니다.

나란히 편집

형식화된 문서 미리보기는 일반적으로 페이지의 위쪽에 있고 편집 버퍼는 일반적으로 페이지 아래쪽에 있기 때문에 Wikipedia 문서 편집 창은 나란히 편집할 수 있도록 설계되지 않았습니다.다양한 문제가 발견되었을 때 사용자는 편집 버퍼 내에서 각 문제가 발생한 위치를 잊어버렸을 수 있습니다.그러나 나란히 편집하기 위해 두 개의 브라우저 창을 사용하는 경우 텍스트(또는 이미지)가 한 창에 표시되고 다른 창에서 위치를 지정하고 변경할 수 있으므로 사소한 세부 사항을 잊지 않고 정확하게 변경할 수 있습니다.두 번째 창에는 편집 미리보기, 디프 또는 기록 탭 목록이 표시될 수 있습니다.하나의 브라우저 창만 사용하는 생산성과 비교하면 두 개의 창을 사용하는 것이 개선될 수 있습니다.

외부 편집기 사용

다양한 기능을 수행할 수 있는 많은 텍스트 편집기는 모든 주요 운영 체제에서 사용할 수 있으며, 일부는 텍스트 편집기 목록에서 확인할 수 있습니다.일부 텍스트 편집기는 일반 텍스트만 편집할 수 있으며, 다른 편집기는 리치 텍스트를 처리할 수 있으며 구문 강조 표시(MediaWiki용 포함) 및 철자 검사와 같은 편집을 지원할 수 있는 기능을 제공합니다.또는 워드 프로세서(워드 프로세서 목록 참조)를 사용할 수 있으며 일반적으로 아래에 설명된 문자열 대체를 포함하여 텍스트 편집기가 수행할 수 있는 많은 동일한 기능을 수행할 수 있습니다. 그러나 텍스트 형식 지정이 전송되지 않을 수 있으며(특히 소스 편집 시) 다른 문제가 발생할 수 있습니다.

나란히 편집할 수 있는 한 가지 방법은 브라우저 편집 창을 텍스트 편집기로 복사하고 외부 편집기에서 텍스트를 변경하지만 브라우저 편집 창 버퍼에서 결과를 복사, 붙여넣고 미리 보는 것입니다.그러나 최근에 변경된 버퍼를 잊어버릴 수 있기 때문에 위험할 수 있습니다.

게시되지 않은 변경사항의 손실을 방지하기 위해 외부 편집기(특히 자동 저장 기능이 있는 편집기)에서 항상 편집하고 브라우저 창에 붙여넣어 미리 볼 수 있습니다.최종 저장은 편집 내용을 게시할 때 브라우저 창에서 수행되지만 신중한 편집 미리 보기를 수행한 후에만 수행됩니다.신중한 미리 보기를 사용하면 나중에 문서의 변경 내용을 찾아서 다시 편집하는 데 소요될 수 있는 시간을 절약할 수 있기 때문에 후자가 중요합니다.속담에도 있듯이, "시간에 한 땀이면 아홉 땀을 절약할 수 있다".

더 안전한 방법은 샌드박스에서 편집하고 변경 사항이 확정된 후 게시할 기사로 전송하는 것입니다.변경 사항이 최종적인지 여부에 관계없이 샌드박스를 자주 저장함으로써 브라우저나 시스템이 손상된 경우 작업 손실 가능성을 최소화할 수 있습니다.

사본 편집 및 교정에 미치는 영향

기사를 복사하거나 교정하는 경우에도 나란히 편집하면 상당한 이점을 얻을 수 있습니다.문서를 처음 볼 때, 사용자는 문서 편집을 보증할 만큼 충분한 문제가 있는지 여부에 대해 "기다리는" 태도로 문서에 접근할 수 있습니다.이러한 상황에 처한 사용자는 새 창에서 기사 또는 섹션에 대한 편집 페이지를 연 다음 기사 또는 섹션 자체로 돌아가기를 원할 수 있습니다. 그러면 사용자는 첫 번째 창에서 현재 버전의 기사 또는 섹션에 대한 액세스 권한을 유지하면서 두 번째 편집 창에서 변경할 수 있습니다.

이 설정을 사용하면 페이지를 처음 읽을 때 편집 창을 별도로 사용할 수 없었더라면 훨씬 더 오랜 시간이 걸릴 수 있는 개선 작업을 수행할 수 있습니다.이것은 사소한 변경 사항처럼 보일 수 있지만, 때때로 변경하고자 하는 문서의 부분을 기억하고 재배치하는 데 상당한 시간이 소요됩니다. 나란히 편집하면 이를 줄이고 프로세스를 가속화할 수 있습니다.

나란히 편집할 경우 잠재적인 영향

편집을 새로운 방법으로 나란히 배치하여 생산성을 높일 수 있는 잠재적인 이점은 수백 개의 흩어진 세부 정보를 쉽게 개선할 수 있는 능력에 있어 거의 마법과 같은 돌파구입니다.그것은 위지위그 편집기보다 더 강력합니다.4가지 이유로: (1) 완전히 다시 포맷된 페이지에 의해 산만해지기 전에 기본 테이블이나 정보 상자 마크업 언어를 보고 편집할 수 있습니다. (2) 미리보기 페이지가 두 번째 창에서 포맷/삭제되는 동안 편집을 계속할 수 있습니다. (3) 결과는 확인을 요구하지 않습니다. (4) 디프로그는 사용자에게 모든 것을 상기시킬 수 있습니다.편집.구체적으로:

WYSIWYG 편집자는 지속적인 재포맷이 발생할 때 다른 수많은 세부 사항에 대한 주의를 심각하게 분산시킬 수 있는 실시간 즉각적인 변환을 고집한다는 단점이 있습니다.결과를 확인하기 위해 몇 가지 세부 정보를 변경하고 다시 포맷하거나 거의 모든 세부 정보(위에서 아래로)를 단계적으로 변경한 다음 나중에 대대적인 다시 포맷을 기다릴 수 있습니다.다시 말하지만, 작은 변경 사항을 추가하면 출력이 왜곡되고 다른 많은 작은 세부 사항에서 주의를 끌지 못할 경우 WYSIWYG 편집은 매우 산만해질 수 있습니다.
편집 미리보기는 두 번째 창에서 처리되므로, 사용자는 현재 너무 산만한 경우에는 진행 중인 디스플레이 페이지 형식을 무시하도록 선택하면서 첫 번째 창에서 편집을 계속할 수 있습니다.
모든 변화가 (즉각이든 아니든) 검증되어야 한다는 것은 완전한 신화입니다.한 페이지에 57개의 변경 사항을 추가할 때, 각 변경 사항을 주의 깊게 살펴보고 다음 기사를 위해 시간을 허비하는 것보다 54개(57개 중)의 성공을 바라며 다른 기사로 이동하는 것이 더 나을 수 있습니다.기사를 나중에 누구나 편집할 수 있는 이 수준의 글쓰기에서는 완전한 "완벽함"이 필요하지 않습니다.
나란히 편집하는 동안 사용자는 기본 마크업 언어를 변경하는 데 집중할 수 있으므로, "변경사항 표시" 단추를 눌러 디프리스트를 실행할 때 사용자는 각 변경사항을 검토하고 익숙한 마크업 스타일로 텍스트를 비교할 수 있습니다.새 오타는 디프 목록에서 예기치 않은 키 입력으로 나타날 수 있습니다.

빠른 편집은 빠른 편집과 피드백뿐만 아니라 방해물을 피하거나 제한하고 강제적인 확인 단계도 포함합니다.장기적으로는 첫 번째 창에서 추가 편집을 계속하는 동안 두 번째 창에서 diff-listing을 사용하여 편집 문제를 발견하는 것에 따라 더 빨라질 수 있습니다.

복잡한 텍스트 대체

Microsoft 메모장과 같은 간단한 텍스트 편집기를 사용하여 여러 텍스트 문자열 대체를 사용하여 일부 복잡한 변경사항을 처리할 수도 있습니다.예를 들어, 위키링크 주위에 큰따옴표를 추가하려면 다음 단계를 수행합니다.

검색 및 바꾸기 기능을 사용하여 모두 변경[[로."[[.
모두 변경하려면 동일한 기능 사용]]로.]]".
이중 따옴표가 이미 있는 위키링크의 경우 모두 바꾸기""와 함께".

그러나 일반적으로 모든 텍스트 편집기 또는 워드 프로세서가 이 기능을 수행할 수 있으며, 편집기 도구 모음의 "고급" 섹션에서 찾을 수 있는 위키백과 및 대부분의 자매 프로젝트에서 이미 사용 가능한 온라인 리치 텍스트 편집기도 이 기능을 수행할 수 있습니다.

실수로 편집한 내용을 게시하지 않기

Wikipedia에는 편집 섹션에 있는 사용자 기본 설정이 있습니다. 이 설정이 구현되면 사용자에게 빈 편집 요약 행에 대해 경고하고 게시 전에 확인을 요청합니다.그러나 편집이 거의 완료되면 사용자가 편집 요약 텍스트 작성을 시작하려고 할 수 있으며, 이로 인해 영구적인 부분 요약 행이 있는 부분 편집이 실수로 게시될 수 있습니다.HTML 주석 태그를 사용하여 편집 요약 행을 페이지의 마지막 행으로 구성하는 것을 방지할 수 있습니다.그 선을 숨기기 위해.예:

(...위의 문서 텍스트...) `<!--` 31개 변경사항: +2개 소스, 9개 철자 수정, 8개 변환 ft/m, 6개 이미지 이동 + 이미지 이동 `-->`

사용자가 게시를 계속할지 수동으로 확인하지 않는 한 편집 요약 필드가 비어 있기 때문에 해당 주석 행을 페이지 끝에 두면 실수로 게시할 위험 없이 전체 편집 요약 텍스트를 보고 수정할 수 있습니다.준비가 되면 사용자는 해당 맨 아래 줄을 편집 요약으로 복사하여 붙여넣을 수 있으며, 맨 아래 줄을 제거하는 것을 잊어버린 경우 숨겨진 주석일 뿐이므로 해당 사용자(또는 다른 사용자)가 해당 페이지를 추가로 변경할 때 해당 주석을 삭제할 때까지 기다릴 수 있습니다.

다른 사용자가 완료되지 않은 변경사항을 보고 불만을 제기하거나 페이지를 다시 변경하여 실수로 게시된 불완전한 편집을 완료하고 제출하려고 할 때 편집 충돌이 발생하는 부분 편집을 저장하는 것보다 더 나쁜 것은 거의 없습니다.이를 방지하기 위해 특정 기사에 전체 편집 내용을 한 번만 게시하거나 불완전한 편집 내용을 제출한 후 20분 동안 기다릴 수 있습니다. 다른 편집자에게 경고가 표시되고(예: 감시 목록을 통해) 기사에 대한 자체 변경 작업이 시작될 수 있기 때문입니다.

이중 가새 마크업 표시

기사에 더블 브레이스 마커가 포함된 경우는 거의 없지만,{{그리고.}}이 중괄호는 위키 문서 페이지에서 일반적으로 사용됩니다.템플릿 활성화(테이블 내부 제외)를 방지하기 위해 다음과 같은 하나의 HTML 숫자 참조를 추가하여 이중 괄호 마커를 인코딩할 수 있습니다.

왼쪽 복좌.{{이라{{바와 함께 ~하듯이|그리고
오른쪽 양다리 걸치기}}이라}}.

테이블 내부의 텍스트를 편집할 때는 테이블이 단일 왼쪽 대괄호를 찾기 때문에 이중 숫자 또는 nowiki 태그를 사용해야 합니다.{두 개의 숫자가 있는 문자는 단순합니다.{{위해서{{그리고.}}위해서}}.

먼 미래

아마도 가까운 미래에 위키백과 편집 창에는 형식화된 출력을 위한 스크롤 영역과 함께 어떤 유형의 나란히 표시가 있을 것입니다.그러나 스크롤 영역에서 형식화된 페이지를 시뮬레이션하는 작업이 복잡하기 때문에 단일 브라우저 페이지에서 이러한 나란히 편집을 구현하려면 몇 년이 걸릴 것입니다.하지만 그것은 번역을 위해 구현되고 있습니다.

참고 항목

Search