위키백과:린터

Wikipedia:
Illustration of linter gathering up various MediaWiki code markup
보풀 정리

린터 확장자는 위키백과 페이지 코드에서 "lint", 구문 오류를 식별하는 것을 목적으로 하는 미디어위키 확장이다.이 경우 보풀이 깨지고 미디어위키가 자동으로 고칠 수 없는 모든 위키 페이지에 문제가 있는 마크가 표시된다.이 확장은 Special:에서 다음과 같은 오류 목록을 생성한다.편집자와 봇들이 주의가 필요한 페이지를 찾기 위해 참조할 수 있는 린트러버스.우선 순위가 높은 린터 문제는 페이지가 바람직하지 않은 방식으로 표시될 수 있기 때문에 수정해야 한다.MediaWiki 위키 도움말 페이지에는 18가지 유형의 보풀 오류가 설명되어 있다.

배경

린터는 문서의 작성자나 편집자(위키 페이지나 프로그래밍 파일 등)가 문서에 오류가 있는지 확인할 수 있도록 도와주는 소프트웨어다.이 확장자는 위키 페이지에 대해 이렇게 한다: 어떤 경우에서 페이지가 저자가 어제 의도한 대로 표시되는지(예를 들어, 일부 이미지 옵션은 "렌딩"되어 있는지), 그리고 MediaWiki 시스템이 위키텍스트에서 HTML을 만드는 방법의 변화로 인해 오늘날 저자가 의도한 대로 페이지가 표시되는지 여부를 확인하는 데 도움이 된다.추가 이유는 mw:도움말:확장:린터 § 왜 그리고 무엇을 고칠 것인가.

보풀 오류 목록

보낸 사람:린트어러시스

높은 우선순위

  1. 삭제해야 하는 테이블
  2. HTML5와 HTML4에서 서로 다른 렌더링으로 잘못 테스트된 태그
  3. 기타 이슈
  4. 목록의 다중 줄 테이블
  5. 닫히지 않은 여러 형식 태그
  6. 단락 래핑 버그 해결 방법
  7. 자체 닫힘 태그
  8. 링크 래핑 글꼴 태그의 이전 동작
  9. 화이트스페이스 구문 분석 버그
  10. 제목에 닫히지 않은 따옴표

중간 우선순위

  1. 보거스 파일 옵션
  2. 육성 콘텐츠
  3. 잘못 테스트된 태그
  4. 다중대장탈출
  5. 링크의 링크

낮은 우선순위

  1. 끝 태그 누락
  2. 사용되지 않는 HTML 태그
  3. 벗겨진 태그

당신이 도울 수 있는 방법

편집자(대부분 위키Gnomes)는 보풀 오류를 정리하기 위해 위키피디아를 돌아다니고 있는데, 보풀 오류는 심각도에 따라 고, 중, 저 세 가지 우선순위 수준 중 하나로 분류되는데, 이는 이 오류가 페이지 디스플레이에 얼마나 큰 영향을 미치는지, 또는 미디어위키 파싱이 바뀌었을 때 페이지 디스플레이가 얼마나 변화했는지와 관련이 있다.너는 이 노력에 동참하는 것을 환영한다.다음은 몇 가지 힌트:

  • 각 보풀 오류 페이지에는 해당 오류 유형에 대한 자세한 정보가 있는 페이지로 연결되는 도움말 링크가 오른쪽 상단 모서리에 있다.
  • 보풀 에러 페이지는 가장 최근에 편집된 순서대로 마지막에 정렬된다.일부 오류 페이지는 다른 페이지보다 더 잘 정렬된다.
  • 보풀 오류 페이지가 반드시 완전한 것은 아니다.새로운 보풀 오류 유형이 발견되어 페이지가 작성되거나 보풀 오류 유형의 정의가 변경될 때, 보풀 오류 페이지는 비어있기 시작하고 몇 주 또는 몇 달이 걸릴 수 있는 프로세스에 의해 점차 채워진다.
  • 모든 페이지의 페이지 정보는 해당 페이지에 있는 보풀 오류 유형별 오류 수를 자세히 설명한다.이 구간은 종점에 가까우며 보풀 오류가 없을 경우 생략한다.
  • 보풀 오차의 경우, 카운트는 한 페이지에서 최대 20으로 제한된다.
  • 다른 사용자의 사용자 및 사용자 대화 페이지와 다른 사용자의 대화 페이지 의견을 편집하는 것은 괜찮지만 편집하는 경우 다음 웹 사이트를 참조하십시오.Talk 페이지 가이드라인 § 다른 사람의 코멘트를 편집하여 안내한다.
    • 다른 편집자들의 말을 바꾸지 마라.
    • 외모를 보존하도록 노력하라.
    • 원래 의도를 보존한다면 경우에 따라 외형을 변경해도 괜찮다.
      • 다음과 같이 누락된 엔드 태그를 수정해도 괜찮다.<small>잘못 닫은 꼬리표를 다른 꼬리표를 달다.<small>대신에 꼬리표를 달다</small>이것이 외관을 바꾸더라도.특히 누락된 엔드 태그가 나타나는 코멘트의 범위를 벗어난 어떤 것에 영향을 미치는 경우 더욱 그렇다.페이지 중간에 있는 사용자의 코멘트가 후속 주석이나 섹션을 잘못 들여쓰게 하거나 볼드체 또는 기울임체 또는 다른 글꼴로 된 경우, 페이지가 "항상" 잘못되었더라도 누락된 끝 태그를 삽입해야 한다.
        • 미디어 이후 이러한 오류 해결이 더욱 시급해졌다.위키의 2018년 7월 새로운 린터 패키지로 전환하는데, 오류에도 불구하고 멀쩡해 보이던 많은 페이지는 연속적인 미닫힘 크기 요소로 인해 페이지를 더 아래로 스크롤할수록 글꼴이 점점 작아지는 등 끔찍한 모양과 접근성 문제를 보여주고 있다.
      • wiki나 HTML 마크업에 관한 논의에서는, 닫히지 않은 태그가 사용되기도 한다.예를 들어, 에 대한 토론에서<div>태그, 태그에 의해 태그가 둘러싸이지 않을 수 있음<nowiki>마크업, 그러니까<div>태그는 단순히 태그를 표시하는 대신 끝 태그가 누락된 상태로 표시된다.이런 경우에는 삽입하는 것이 도움이 된다.<nowiki>...</nowiki>디스플레이를 변경하는 비피싱 마크업 주위에는 원래 코멘트의 의도를 표시하고, 누락된 엔드 태그 또는 비피싱 마크업으로 인한 기타 오류를 수정한다.
    • 예를 들어 오류에 대한 토론에서, 「[]를 사용할 때 디스플레이가 왜 엉망이 되는가.some bad markup]]" 그렇지 않으면 토론이 말이 되지 않을 것이기 때문에 종종 나쁜 점수를 그대로 두는 것이 최선이다.
    • 특히 사용자 및 사용자 대화 페이지에서는 첫 번째 시도에서 수정 사항을 정확히 파악하여 중단을 최소화하도록 하십시오."미리보기 표시"는 네 친구야.
      • 기본적으로 기본 사용자 대화 페이지를 편집하면 사용자에게 알림이 트리거되며, 이는 귀찮을 수 있으므로 대규모로 수행해서는 안 된다.이 문제를 방지하려면 플래그 지정된 봇 계정을 사용하고 편집에 "새 메시지가 있음" 알림을 무시하는 사소한 항목으로 플래그를 지정하십시오.
  • WP를 참조하십시오.HTML 5 § CSS를 통해 탐지할 수 있는 유효하지 않은 태그 및 속성 목록의 구식 요소 및 속성.아래를 참조하십시오.
  • 사용자 서명과 템플릿 대체에 의해 발생하는 린트 오류는 많은 페이지에 걸쳐 존재한다.수동 편집보다는 봇 작업에서 이러한 오류를 수정하는 것이 더 효율적이다.regex 기반 소스 검색을 사용하여 봇이 수정할 수 있는 오류 패턴을 식별할 수 있다.

보고서

  • 반딧불 도구 테이블인 enwiki의 미결 린터 오류는 네임스페이스와 보풀 오류 유형에 대한 열이 있는 차트로, 차트의 각 셀에는 오류 수(기사당 오류 유형당 최대 20개)가 나열된다.이 차트는 관리 가능한 크기의 프로젝트를 찾거나 문서 네임스페이스와 같은 네임스페이스에서 특정 유형의 보풀 오류 수를 신속하게 확인하는 데 도움이 될 수 있다.이 페이지는 한 시간에 몇 번 업데이트된다.
  • User:Galobot/report/Articles by Lint Errors는 보풀 오류가 가장 많은 기사(즉, 기사 네임스페이스의 페이지)의 보고서(구식 HTML 태그 제외)이다.

User Javascript 도구: lintHint

User:PerfektesChaos/js/lintHint에는 wiki 편집기의 문서에서 보풀 오류를 식별하는 자바스크립트로 코딩된 가젯인 lintHint를 설치하고 사용하는 방법에 대한 지침이 있다.

동일한 편집 세션에서 반복적으로 lintHint를 실행하여 오류를 수정했는지 확인하고 오류 포인터를 다시 초기화하십시오.에러 포인터들은 기사 상단과 관련되기 때문에, 아래에서 위로 오류를 수정하면 에러 포인터들을 다시 계산하기 위해 lintHint를 다시 실행할 필요가 없을 것이다.

lintHint 도구는 상대 링크를 확장하지 않는다.예를 들어, 포털에서:과학,{{/Header}}정말 뜻있는{{Portal:Science/Header}}그러나 lintHint는 이것을 하지 않는다.lintHint가 작동하도록 하려면 수동으로 상대 링크를 확장하십시오.또한 템플리트 확장을 사용하고 페이지 이름을 다음 위치에 입력하십시오.Context title페이지 전체 또는 일부를 에 복사Input wikitext. 그런 다음 클릭OK그리고 나서 누르다.lintHint. 확장 템플릿은 종종 lintHint를 로컬로 설정하고 페이지 정보에 나열된 보풀 오류를 식별하는 데 도움이 되지만, 보풀은 자체적으로 찾을 수 없다.

편집 후, 페이지는 보통 몇 초 이내에 보풀 오류에 대해 다시 점검되지만, 과거에는 때때로 몇 시간 동안 지연되기도 한다.린트힌트가 하나 이상의 보풀 오류를 수정했다고 말한다면, 페이지 정보와 특정 보풀 오류 페이지가 아직 업데이트되지 않았더라도 보풀 오류를 수정했을 것이다.그러나 언급했듯이, 린트힌트는 확장되지 않은 상대적 링크에서 오류를 감지할 수 없다.

사용자 CSS 도구: lint.css

정리하기를 좋아하는 위키그노메인 경우, 사용자 CSS를 쉽게 채용해, 당신이 읽은 페이지의 많은 "보송한" 오래된 HTML 4 코드를 탐지할 수 있다.메타 참조:사용자:SMCCandlish/lint.css가 다양한 사용되지 않는 순항로를 만드는 샘플 CSS 선언(예:<tt>,<font>,<center>그리고<strike>– 아픈 엄지손가락처럼 튀어나오도록 분홍색으로 변한다.자신의 Special에 대해 원하는 대로 사용자 정의할 수 있다.MyPage/common.css 또는 meta:특수:MyPage/global.css 또는 lint.css의 지침을 따르십시오.@import(전송) lint.css를 이 또는 다른 WMF wiki에서 직접 사용자 CSS에 넣으십시오.

이 CSS는 더 길지 않은 유효 마크업만 감지하며, 다른 코딩 오류를 감지할 수 있는 수단이 없다.

다른 예는 여기를 참조하십시오.

참고 항목