위키백과:마을 펌프(제안)/아카이브 132

영어 이외의 언어에서의 인신공격과 불친절은 동등하게 취급되어야 한다.

이 페이지에는 아프리카어, 아시아어, 유럽어에서의 인신공격에 대한 언급이나 섹션이 없다.종종 사용자들은 영어 이외의 인신공격이나 BLP위반으로 인해 차단되지 않는다.관리자는 피해자가 단어의 실제 의미가 부여된 출처를 제공한다면 그러한 언어와 단어를 무시해서는 안 된다.영어 알파벳을 사용하여 다른 언어로 인신공격하는 것은 시스템을 게임하는 것이다.'인신공격 금지'의 위키백과 정책 페이지에는 다른 언어로 인신공격을 하는 사람도 댓글이 너무 징그럽거나 폭력적이거나 불쾌할 경우 차단해야 한다는 내용이 반드시 적혀 있어야 한다. --182.66.56.52 (대화) 07:27, 2016년 5월 19일 (UTC)[응답]

피해자가 비영어로 인신공격성 발언을 신고하면 실제 의미가 부여된 곳에 출처가 제공되든 안 되든 간에, 그런 정책 추가가 어떻게 달라질지 이해할 수 없다.공격이 보도되는 한 다른 언어로 이뤄졌다고 해서 그런 공격을 무시하는 행정관은 상상도 할 수 없다.영어 이외의 언어로 된 인신공격성 보고서가 같은 날짜 또는 그 이후의 인신공격성 보고서가 처리되는 동안 무시된 사례를 보여줄 수 있는가?출처에 충실하라!Paine08:00, 2016년 5월 19일 (UTC)[응답]

사실 그 페이지에는 "Wipedia 어디에서도 인신공격하지 말라"고 적혀 있다.요점. 영어로 공격해야 한다고는 하지 않는다.행정관은 그것이 보고되면 행동할 것이고, 만약 그가 언어를 이해할 수 있다면, 그는 보고되지 않고 행동할 것이다.그래서 나는 Paine Elsworth에 동의한다. 예를 들어줄래?렉토나르 (대화) 08:29, 2016년 5월 19일 (UTC)[응답]

사용자가 다른 언어로 더러운 발언을 한 뒤 살아남은 예는 많다.몇 개 기억나.

• 이 IP는 다음과 같은 코멘트를 했다. 안녕하십니까 누누케테데보. 락토바코르보. 아미토마르 츄 샬락.이제 누누케테 데보. 락토바코르보. 아미토마르 체여 찰락. 뜻은 "내가 네 좆을 베겠다.나는 피를 가져올 것이다.나는 매우 영리하다고 말했다.IP는 이런 댓글 때문에 차단되거나 경고된 적이 없었다.

• 이 IP는 "아제이 싱 라즈푸트"라는 캐릭터의 이름을 "간두추티야 로라"로 바꾸었다.그 후, 영어를 말하는 관리자 Irongargoyle은 선의의 편집을 되돌렸다.간두는 개자식, 추티야는 개자식, 로라는 좆을 의미한다.

• 양말 하나가 이런 저속한 욕설들을 극단적으로 사용하고 있었다.피해자는 영어권 관리자들이 그 말의 의미를 모르기 때문에 SPI를 방문해야만 했다.

인도 사용자들이 힌두어, 우르두어, 벵갈어, 타밀어, 텔루구어, 푼자비어 등에서 인신공격에 직면했을 때는 참아야 한다.12.66.56.132 (대화) 09:15, 2016년 5월 19일 (UTC)[응답]

그리고 그들은 보고받았는가?만약 그렇다면: 어디?그리고 만약 보고된다면: 정말 아무런 조치도 없었는가?렉토나르 (대화) 09:20, 2016년 5월 19일 (UTC)[응답]

다음 두 가지를 염두에 두십시오.첫째로, 일부 관리자들은 대개 파괴적인 특정 단어들을 찾는데 도움을 줄 수 있는 도구를 가지고 있을 수 있다; 이 단어들은 거의 확실히 영어로 되어 있을 것이다.둘째로, 대부분의 행정가들은 영어 이외의 어떤 주어진 언어로 된 나쁜 말들을 인식하지 못할 것이다.나는 개인적으로 히브리어 사례들을 알아볼 것이다. (예를 들어, "넌 멍청해"라는 뜻의 Ata tipesh라는 사용자를 차단했다. 이것은 실제로 히브리어 사용자라는 증거가 없었기 때문에 부드러운 차단이었다.)나는 힌디, 우르두, 벵갈리, 타밀, 텔루구, 푼자비, 심지어 프랑스어에서의 문제들을 인정하지 않을 것이다.그리고 나는 내가 반드시 그 의미에 대해 누군가의 말을 받아들일지 확신할 수 없다 - 만약 어떤 것이 있다면, 나는 그 언어를 말하는 관리자의 주의를 끌려고 노력할 것이다.עודדוו odיו od mis od mis od mis 미셰후 19:50 (UTC)[응답]

여기선 고칠 게 없어 보인다.그 정책은 결코 영어 공격에만 국한되지 않는다.여기서 유일한 "문제"는 사람들이 종종 외국어로 공격을 읽거나 인식하지 못한다는 것이다.그것은 정책을 다시 써서 고칠 수 있는 것이 아니다.공격은 보고되어야만 대처할 수 있다.나는 관리자들이 일반적으로 보고된 외국 공격을 동등하게 취급할 것으로 예상하며, 대부분의 경우 그 공격은 온라인 번역기에 입력함으로써 검증될 수 있다.

만약 관리자들이 고의로 외국의 공격을 무시하는 사례의 패턴이 있다면, 나는 언어에 상관없이 적용된다는 정책에 (중복형) 형벌을 추가하는 것을 지지할 것이다.알제 (대화) 22:25, 2016년 5월 19일 (UTC)[응답]

기계 번역에도 문제가 있다.

1. 그것은 번역된 것이 아니라 언어의 실제 알파벳에서만 작동하기 때문에 프랑스어에서는 통할 수 있지만 라틴 알파벳으로 쓰여진 우르두 텍스트에서는 통용되지 않을 것이다.
2. 아마도 어떤 번역가도 다룰 수 없는 언어가 있을 것이다.
3. 짧은 글의 경우, 언어를 식별하는 사람이 필요할 것이다.
4. 기계가 어떤 의미를 의도하는지 알 수 없는 경우, 동일한 단어는 여러 의미를 가질 수 있다.예를 들어, "cock"이라는 단어의 특정 용어는 수컷 새를 가리키는 것인가, 아니면 공격 가능성이 있는 것인가?다른 언어들도 비슷한 문제가 있을 거야.

עודדוו odיו od mis od mis 미셰후 04:51, 2016년 5월 20일 (UTC)[응답]

Edward Fitzgerald Law에 대한 기사 작성

pdf 옵션 버튼에는 소스 .tex를 다운로드하는 .tex 버튼이 있음(라텍스일 가능성이 있음)

본 기사에서 PDF를 만드는 것은 좋은 생각이지만, 무거운 수학 기사에 대한 실질적인 결과가 좋지 않아 PDF를 사용할 수 없는 경우가 많다.만약 당신이 기초가 되는 .tex 파일을 다운로드 할 수 있는 옵션을 제공한다면, 텍스에 아주 익숙한 우리 중 한 명인 라텍스는 그것을 아주 좋은 문서로 해킹할 수 있을 것이다.기본 .tex 파일로 읽을 수 있는 PDF에 의 옆에 버튼을 추가하십시오.바로 그거야.— LarryHickey가 추가한 사전 서명되지 않은 논평 (대화 • 기여) 22:06, 2016년 5월 19일

"기반 .tex 파일"과 같은 것이 있다는 것을 나는 알지 못한다. 사실, 없다고 자신 있게 말할 수 있다. 사실, 수학(및 다른) 기사는 약간의 라텍스 마크를 포함할 수도 있지만, 페이지 전체는 라텍스에서 설정되지 않았고, 나는 라텍스에서 만들 수 있는 어떤 도구에도 익숙하지 않다.만약 당신이 그러한 도구를 알고 있다면, 당신은 그것을 활용하도록 제안할 수 있다. 그렇지 않으면, 이 제안은 실행될 수 없다.평화 - קיודנ ((일명 kipod) (토크) 23:20, 2016년 5월 19일 (UTC)[응답]

실제로 mw:확장:Wiki2LaTeX가 존재하지만 보안 위험으로 간주되며 아직 사용을 권장하지는 않는다.나는 그것이 위키피디아에서 실행되거나 곧 실행될 것이라고 믿지 않는다.인텔리전트시움 23:37, 2016년 5월 19일 (UTC)[응답]

원본 기사는 라텍스 출처가 아닌 것으로 알고 있지만, 왼쪽에 있는 (PDF를 만들어줘) 버튼을 클릭하면 위키에서 소리가 나 잠시 생각해보고 내가 다운로드 할 수 있는 .pdf를 가지고 돌아온다.출판된 기사에서 나에게 특별한 pdf를 만들어 주곤 했던 저것은 분명 .tex나 latex 출처인가?비록 원본이 아닐지라도?그렇지 않다고 하면, 당신은 .pdf를 만든 마크업 자료와 그 마크업을 .pdf 로 변환하는 도구를 릴리스할 수 있을 것이다(pdflatex는 latex 소스를 pdf로 변환하는 것과 같다).위키로 되돌리고 싶은 것은 없고, 단지 내 용도에 맞게 해킹하기 위해서, 긴 수식이 괜찮아 보이는 등 — LarryHickey (대화 • 기여) 00:53, 2016년 5월 20일 이전에 추가된 서명되지 않은 논평

@LarryHickey:먼저 WP:게시물에 서명하십시오. 두 번째, WP:DOW. 어쨌든, 여기서 문제는 오프라인 콘텐츠 생성기인데, 수년 동안 오프라인 콘텐츠 생성기와 관련된 다른 많은 문제들이 있어왔다. 예를 들어 위키백과:마을 펌프(기술)/아카이브 146#인쇄 가능/도서 버전여기 WP에서 공지사항:VPR은 어떤 조치도 취할 것 같지 않으며 WP가 더 나을 것이다.VPT 또는 이상적으로는 phab: --Redros64 (토크) 07:51, 2016년 5월 20일 (UTC)[응답]

드래프트 프로드

드래프트 스페이스의 비 AFC 초안에는 자동 삭제를 위한 G13 방법이 없다.아니면 어떤 리뷰를 위해.이처럼 오랜 시간 편집되지 않은 퀴퀴한 초안이 수백 건이나 된다.G13 또는 기타 기준을 추가하려는 시도는 반복적으로 그리고 명시적으로 거부되었기 때문에 WP에서 이 페이지들은 많은 시간을 소모한다.삭제가 다소 일상적인 MFD.아이디어 랩 제안을 제한하면서, 다음 규칙으로 새로운 초안 제안 삭제 시스템을 허용할 것을 제안하고 싶다.

1. 6개월 동안 편집되지 않은 AFC가 태그되지 않은 드래프트 스페이스 초안을 고려할 수 있다.
2. 삭제 제안이 있을 경우 다음과 유사한 날짜 범주로 변경될 수 있다.최소 한 달 동안 제안된 삭제로, 어떤 이유로든 제안서를 삭제할 수 있다.이는 다음 범주의 5개월 통보와 유사하다.AfC G13 지원 자격은 G13 이전 한 달과 함께 곧 제출된다.
3. 삭제하지 않고 한 달이 지나면 관리자가 삭제할 가치가 있는지 결정할 수 있다.

나는 또한 위키프로젝트에 초안을 태그하여 WP를 가질 수 있을 것 같다.프로젝트에서 관심 있는 내용이 있는지 확인할 수 있도록 이러한 초안에 대한 경고가 Prods와 유사하다.생각나는 거 있어?그것은 MFD 토론보다 훨씬 길지만 본질적으로 단일 거부권이지 합의는 아니다.prod가 실패해도 여전히 개선되지 않으면 MFD에서도 삭제가 가능하다. -- Ricky81682 (토크) 20:15, 2016년 5월 5일 (UTC)[응답]

우리가 최근에 비슷한 제안을 논의하지 않았니?나는 이와 같은 것을 지지하며, G13이 이 초안으로 대체되는 것을 선호한다.— 마틴 (MSGJ · talk) 20:43, 2016년 5월 5일 (UTC)[응답]

내 기억으로는 아무데도 안 간 것 같아.적어도 드래프트 스페이스는 공식화했으면 좋겠는데. -- 리키81682 (토크) 21:41, 2016년 5월 5일 (UTC)[응답]

• 반대한다. 사람들이 사용자들을 사이트에서 쫓아내려고 한다고 해서 좋은 초안을 삭제할 이유가 없다.— 166.171.121.222(대화) 21:02, 2016년 5월 5일(UTC)에 의해 추가된 사전 서명되지 않은 의견 스트라이크 금지 사용자 — JJMC89 (T·C) 02:15, 2016년 5월 6일 (UTC)[답글]

  WP에서 많은 G13 요청을 받고 있는 가운데:그 중 20% 정도는 여러 G13을 본 초안에 대해 재요청한다.이 중 약 60%는 재복구 요청자가 그 성격의 요청에 대한 후속 질문에 답하지 않기 때문에 복구되지 않는다.("만약 우리가 이것을 다시 삭제한다면, 당신은 그것을 받아들일 수 있는 기사로 만들기 위해 어떤 노력을 하겠는가?") —제레미 v^_^v 21:31, 2016년 5월 5일 (UTC)[응답]

• 좋아, 다음 단계는 뭐지?이것을 WP:PROD에 덧붙여 제안해야 하는가? -- Ricky81682 (토크) 18:53, 2016년 5월 18 (UTC)[응답]
  • WT에서의 푸시백 기준:PROD, 대신 위키백과에 공식 RFC를 만들었다.마을_펌프_(정책)#RfC:_Proposed_draftspace_deletion.@MSGJ, Jéské Curiano, FoCu SandLeArN:에 통지. -- Ricky81682 (토크) 21:39, 2016년 5월 20일 (UTC)[응답]
• 나는 또한 그러한 제안을 지지한다.상식이 널리 보급되어야 하며, 이것은 사례별로 쉽게 통제될 수 있는 반면 불필요한 관료주의적인 스톱은 제거될 수 있다.Best, FoCuS 기여, Talk to me! 2016년 5월 19일 (UTC)[응답]

수년간 리디렉션

안녕 VP 제안, "생년" "죽음"과 관련된 최대 6000개의 리디렉션을 수년 단위로 생성하라는 봇 요청이 있다는 점에 유의하십시오.위키백과에서 논평과 질문을 환영한다.봇/승인요청/SST봇 1감사합니다, — xaosflux 03:50, 2016년 5월 22일 (UTC)[응답]

위키백과:Archive.is RFC 4

위키백과에 RfC가 있다.Archive.is RFC 4에는 "스팸 블랙리스트에서 archive.is을 제거하고 새 링크(Opose/Support)를 추가할 수 있도록 허용"이라는 제안이 포함되어 있다.쿠나드 (대화) 06:20, 2016년 5월 23일 (UTC)[응답]

제거된 삭제 통지를 다시 설치하는 봇.

현재, 우리는 합법적인 삭제 통지를 삭제하는 것에 대해 많은 문제를 가지고 있다.나는 만약 불법적인 제거가 자동적으로 감지될 수 있다면, 이 통지들을 복구시킬 봇을 제안한다.다음과 같은 작업을 수행해야 한다.

• 기사 작성자가 삭제한 경우 빠른 삭제 통지 다시 삽입
• 토론이 종료되지 않은 경우 XfD 알림을 다시 삽입하십시오.
• 통지 삽입 후 기사에 대한 변경사항만 해당 통지 제거일 경우 BLP PROD 통지 다시 삽입
• 선택적으로, 봇은 이전에 제거 작업을 수동으로 되돌린 경우 PROD 알림을 다시 삽입할 수도 있다.

이렇게 하면 삭제 통지의 많은 문제를 해결할 수 있을 것 같다; 이 봇은 특히 불성실하게 편집하고 위키백과가 어떻게 작동하는지 어느 정도 알고 있는 끈질긴 반달들에게 도움이 될 것이다. --Laber□^T 18:32, 2016년 5월 16일 (UTC)[응답]

이런 일을 하는 봇이 이미 있는데, 어떤 봇을 기억하지 못한다."이전에 제거 작업을 수동으로 되돌린 경우 PROD에서 다시 알림"에 대해, 일반적으로는 다음과 같이 매우 주의 깊게 수행할 필요가 있다.{{proposed deletion/dated}}제거된 후에는 제거 이유가 무엇이든 다시 추가되지 않을 수 있다(WP: 참조).DEPROD. --Redros64 (대화) 20:21, 2016년 5월 16일 (UTC)[응답]

그렇다, PROD는 매우 제한된 상황에서만 복원될 수 있기 때문에, 나는 그 과정이 자동화될 수 있을지 의심스럽다.이 제안서는 신속성과 XfD 태그에만 초점을 맞추어야 한다.– 피누서톱 (토크 ⋅ 기여) 20:29, 2016년 5월 16일 (UTC)[응답]

당신은 이미 있는 것을 아십니까?tag 편집자가 확인할 수 있는 신속한 제거는 예를 들어, 여기를 참조하십시오.— Xaosflux^Talk 04:15, 2016년 5월 17일 (UTC)[응답]

응, 하지만 그건 여전히 수동 개입이 필요해. --Laber□^T 07:53, 2016년 5월 17일 (UTC)[응답]

BLP PROD가 아닌 경우 — Laberkiste(대화 • 기여) 07:54, 2016년 5월 17일(UTC)[응답]에 의해 추가된 서명되지 않은 코멘트 앞.

@Laberkiste: A WP:BLPPROD는 WP가 아니다.PROD, 그리고 같은 규칙에 얽매이지 않는다.만약{{Prod blp/dated}}제거됨, 그리고 여전히 해당 물품의 소스가 이루어지지 않음, 제거가 되돌릴 수 있음(또는 다음 사항).{{Prod blp/dated}}WP:BLPROD#Objecting. --Redros64 (토크) 11:50, 2016년 5월 17일 (UTC)[응답]에 따라 복권됨.

• 지지 먼저 2, 반대 마지막으로.수동 복구는 VOA 사용자가 제거했고, 누군가가 맹목적으로 복구했으며, 나중에 익명의 사용자가 삭제에 이의를 제기하는 것에 지나지 않을 수 있다.BLP PROD에 대한 확신이 없다. עודדוווו Od Mishehu 09:37, 2016년 5월 17일 (UTC)[응답]
• 첫 번째 지원 2. CSD 태그를 대체하는 데 사용되는 Kingpin13에서 운영하는 SDPatrolBot; 2년이 넘도록 운영되지 않고 있다; 현재 이 작업을 수행하는 다른 봇이 있는지 잘 모르겠다.내가 잘 모르는 세 번째 것은 BLP PROD가 잘못 추가되었기 때문에 제거된다면 어떨까?소스가 제공되지 않은 기사에서 삭제된 내용을 감지하고 되돌릴 수 있다면 더 좋겠지만, 일부 새로운 편집자는 외부 링크나 포맷되지 않은 일반 텍스트를 참조로 추가하기만 할 것이기 때문에 주의해야 한다.나는 마지막 것에 반대한다.PROD 교체는 몇 가지 특정한 상황에서만 이루어지기 때문에, 나는 그것이 수동으로 평가될 필요가 있다고 생각한다.사라즈2107 (대화) 12:24 (UTC) 2016년 5월 17일 (화)[응답]
• 반대, 신속한 삭제 태그 제거는 편집 필터를 사용하여 쉽게 찾을 수 있으며 손으로도 확인할 수 있다.명백히 경박한 CSD 태그를 제거하는 페이지 작성자는 괜찮지만, 봇에 의해 그것을 되돌리는 것은 괜찮지 않다.잠시 후에 AFD 템플릿을 다시 붙이는 봇이 있다고 생각해, 괜찮아.그러나, TFD는 종종 제외되어야 할 때 제거된다. 그리고 제거를 되돌리는 것은 아마도 최선의 방법은 아닐 것이다.—쿠스마 (t·c) 13:43, 2016년 5월 17일 (UTC)[응답]

만약 여러분이 무인클로스가 걱정된다면, 봇이 쓰여져 만약 XfD 태그를 전폐가 있는 페이지에 복원한다면 무인클로 태그에 추가할 수 있을 것이다.עודדהododOd Mishehu 18:17, 2016년 5월 17일 (UTC)[응답]

때로는 noinclude가 옳고, 때로는 그렇지 않다.봇이 어떻게 말해야 할까?—쿠스마 (t·c) 07:39, 2016년 5월 22일 (UTC)[응답]

• 의견: "기사 작성자"를 어떻게 정의하십니까?찬양(대화) 19:27, 2016년 5월 24일 (UTC)[응답]

글꼴: OpenDyslexic

Hey 나는 Questia에 있었는데 그들이 OpenDyslicic 글꼴을 가지고 있는 것을 보았다. OpenDyslexic.org]을 참조하십시오.위키피디아는 모든 사람을 위한 인터넷이 되어야 하기 때문에 우리도 그것을 가져야 한다.링지 ♦ (대화) 07:28, 2016년 5월 26일 (UTC)[응답]

@Lingzhi: 위키백과 참조:난독증 독자 Fred Gandt · talk · contribs09:13, 2016년 5월 26일 (UTC)[응답하라]

관리자가 아닌 사용자가 감독 플래그를 보유하도록 허용

CheckUser에 대한 관리자 권한을 갖는 것은 사용자만 차단할 수 있는 능력 때문에 필요한데 관리자가 아닌 사람이 오버래이터가 될 수 없는 이유를 모르겠다.— Music1201 03:51, 2016년 5월 25일 (UTC)[응답]

장난꾸러기 콘텐츠를 억제하는 데 필요한 모든 권리는 감독그룹에 포함된다.내가 아는 바로는 오버세이터도 관리자가 될 수 있는 정책적 요건은 없다.실제로 OS 권한을 신뢰할 수 있는 사용자는 이미 관리자 역할을 하는 경향이 있다.Ajraddatz (대화) 04:18, 2016년 5월 25일 (UTC)[응답]

WMF는 삭제된 개정판에 접근할 수 있는 사용자가 RfA 또는 RfA와 유사한 프로세스를 거쳐야 한다.현재 영어 위키피디아에 대한 감독 권한을 얻는 유일한 방법은 중재위원회에 선출되거나 중재위원회에 의해 임명되는 것이다.왜냐하면 임명은 RfA와 같은 과정으로 간주되지 않기 때문에 비관리자는 이전 옵션만 남게 된다. Mike V • Talk 04:52, 2016년 5월 25일 (UTC)[응답]

모든 것이 전 지역사회 옹호 국장에게 경의를 표한다. 하지만 나는 그것이 얼마나 사실인지 잘 모르겠다.

• m:비공개 정보 정책에 대한 액세스#비공개 정보 권한에 대한 액세스를 신청하는 커뮤니티 구성원의 최소 요구사항은 RfA 또는 RfA와 유사한 프로세스에 대한 참조 없이 비공개 정보에 대한 액세스가 할당되는 조건을 명시한다.
• m:오버라이트 정책#액세스(Access)는 중재 커뮤니티(지방선거를 선호하지 않는)가 있는 위키에서 RfA와 같은 프로세스에 대한 언급 없이 "사용자도 중재위원회에 의해 임명될 수 있다"고 명시한다.유일한 요건은 엔위키가 분명히 충족시키는 25표 이상의 지지를 얻어 ArbCom을 선출하는 것이다.
• 위키미디어위키에 대해 공시와 일주일간의 토론(RfA와 유사한 과정)을 거쳐 임시 관리권이 부여될 수 있다는 점을 감안할 때 WP가 어떻게 다음과 같은지 알 수 없다.CUOS 시스템은 필요한 경우에도 그것과 같은 조건을 충족시키지 못할 것이다.예, ArbCom이 약속을 하지만 관리 권한을 부여하는 기본 기준에 부합하는 방식으로 커뮤니티가 참여할 수 있는 기회가 있다.

나는 2년 넘게 승무원으로 일해 왔지만, 여기서 다시 엔위키로 활동하기 전까지는 이 RfA 요건에 대해 듣지 못했다.그것은 우리의 어떤 정책이나 가이드라인에도 없다.오래된 요구사항인지, enwiki에만 적용하려는 것인지, 아니면 WMF가 결정한 "모범 사례" 이상이 결코 아닌지는 잘 모르겠다. 어느 쪽이든, Stewards는 실제 코드화된 정책에 근거하여 CU/OS 권한에 대한 액세스를 할당하기 때문에, 비관리자는 Arbcom의 요청에 따라 현지 관리자가 되지 않고도 오버파이터가 될 수 있다.Ajraddatz (대화) 05:06, 2016년 5월 25일 (UTC)[응답]

여기서 Ajraddatz는 WMF가 사용자에게 삭제된 수정본에 대한 액세스 권한을 부여하기 위해서는 "RFA 또는 RFA 식별 프로세스"를 거쳐야 한다고 명시했다.그것은 2013년이었다. 그 이후로 상황이 어떻게 변했을지 확실하지 않다.옴니 불꽃^{let's talk about it} 05:21, 2016년 5월 25일 (UTC)[응답]

나도 잘 모르겠지만, 그것은 CU/OS 권리(또는 관리자 권리)를 얻기 위한 정책 요구사항이 아니다.그리고 그것이 요구사항이라고 하더라도 WP는 다음과 같은 매우 설득력 있는 주장을 할 수 있다.CUOS는 삭제된 개정판이나 비공개 정보에 대한 접근을 허가하는 유사한 프로세스와 비교할 때 그러한 요건을 충족한다.Stewards는 실제 서면 정책에 따라 CU/OS 권한을 할당한다.그러나 위에서 말한 것처럼 엔위키 전용인지, 아니면 다른 것을 의도한 것인지 궁금하다.Ajraddatz (대화) 05:34, 2016년 5월 25일 (UTC)[응답]

그러한 논평은 현재의 비공개 정보 정책보다 앞서 있기 때문에, 이 2013년 성명이 여전히 적용되는지에 대한 WMF의 설명을 들을 가치가 있을 것이다.오파비니아 레갈리스 (토크) 23:37, 2016년 5월 25일 (UTC)[응답하라]

@Ajraddatz:내 스튜어드위키 페이지를 뒤져보면, 그것에 대해 더 많은 것이 있을 수 있지만, 그것은 "비공식" WMF 요구 사항이다.다만 엔위키에만 시행된 것으로 보인다. --Rschen7754 00:35, 2016년 5월 26일 (UTC)[응답]

고마워, Rschen7754, 나는 그것에서 몇 가지를 찾았다.Opabinia regalis가 언급했듯이, WMF에 다시 한번 요청할 가치가 있고, WMF가 그것을 관련 정책 중 하나에 쓰도록 한다면 그럴 가치가 있을 것이다.Ajraddatz (대화) 04:09, 2016년 5월 26일 (UTC)[응답]

• 새로운 프로세스에 대한 요청인가, 감독 요청인가, 아니면 이 작업을 수행하는 다른 방법인가?관리자 권한과 별개의 감독 액세스 프로세스를 별도로 만들지 못할 이유가 없다.하지만, 왜 이것이 필요할까?관리자가 필요 없는 오버타이터를 더 많이 사용할 수 있는 프로세스는? -- Ricky81682 (대화) 06:43, 2016년 5월 25일 (UTC)[응답]

  정말; 혹시 밀린 일이 있을까?감독 팀에게 보내는 이메일이 반나절이나 그 이상 응답하지 않는가?오버서더들로부터 팀원이 더 필요하다는 요청이 있었는가?초과 근무자 수가 감소했는가?

  마지막 질문으로:나는 그렇게 생각하지 않는다. 현재 50명의 오버파이터가 있는데, 이는 2012년 1월 35명(약 3년 전 41명)에 비해 상당히 증가한 수치다.감독권의 마지막 제거는 2016년 5월 7일 18시 12분 비블브록스(토크 · 기여)의 자청이었고, 마지막으로 감독권을 부여한 것은 2016년 1월 31일 19시 3분 플로켄빔(토크 · 기여)에 대한 것이었다.

  어쨌든 이것은 영어 위키백과 문제가 아니다. 왜냐하면 감독권은 steward에 의해 부여되기 때문이다. m:Steward 요청/허용#Overmissions 액세스를 참조하라. "사용자에게 이 권한을 부여하기 전에 현재 정책을 확인하고 사용자가 Wikimedia 재단과 비밀 유지 계약에 서명했는지 확인하십시오."나는 정말로 이러한 정책들을 바꾸는 것이 우리의 소관에 있다고 생각하지 않는다. --Redros64 (대화) 09:48, 2016년 5월 25일 (UTC)[응답]

  위에서 말한 것은 글로벌 정책에 따르면 관리자가 되는 것은 오버파이터가 되기 위한 정책적 요건이 아니라는 것이다.따라서 수년 전 WMF 직원이 제공한 이상한 의견 때문에 유일한 블록이 엔위키 지역에 있는데, 만약 그렇다면 이곳 아르브콤 약속에만 적용되는 것 같다.Ajraddatz (대화) 21:32, 2016년 5월 25일 (UTC)[응답]

• 나는 여기서 좋은 질문을 ArbCom에게 할 것이라고 생각한다 - 그들은 위키피디아를 가질 계획이 있는가:중재_위원회/CheckUser_and_Oversight/2016_CUOS_지명 프로세스?만약 그렇다면 비관리자가 신청을 시도하거나 최소한 그들이 신청할 수 있어야 한다고 주장할 수 있다.— Xaosflux^Talk 21:52, 2016년 5월 25일 (UTC)[응답]
  • 물어봐! 위키피디아 토크에서:중재 위원회.— Xaosflux^Talk 21:55, 2016년 5월 25일 (UTC)[응답]
    • 지난해 ArbCom은 감독 역할에 관심이 있는 사람들에게 설문지를 보냈다.본질적으로 이것은 후보가 그 역할과 그것이 관여하는 것을 확실히 이해하도록 하기 위한 것이었고, 우리는 그들이 왜 그것을 원하고 그들이 적합한지 이해할 수 있었다.질문 중 두 가지는 "(해당되는 경우)관리자 권한 요청:" 및 "(관리자일 경우) 수정사항 삭제 사용에 동의하지 않은 모든 상황을 나열하고 의견을 제시하십시오."내가 기억하기로는 작년에 지원했던 모든 사람들이 이미 관리자였지만, 비관리자들이 그 역할에 고려될 것이라는 것을 시사한다.나는 올해 위원회에 속해 있지 않기 때문에 현재 계획이 무엇이고 바뀌었는지 말할 수 없다.트리듀울프 (대화) 22:36, 2016년 5월 25일 (UTC)[응답하라]
• 감시는 삭제를 강화한다.오버세이터의 역할의 중요한 측면은 삭제 수정(또는 페이지의 직선 삭제)이 실제 억제 없이 목적을 달성하기에 충분한지를 결정하는 것이다.따라서 실제로 제안되고 있는 것은 삭제 도구를 비관리자에게 제공할 것인가 말 것인가 하는 것이다, 감독 도구는 삭제 도구에 대한 보충이다.이와 같이, 나는 이 생각에 별로 찬성하지 않는다; enwiki 커뮤니티는 관리 후보들이 삭제 도구를 얻기 전에 도달하기를 기대하는 매우 높은 (내 생각에, 지나치게 높은) 기준을 확립했다.엔위키는 51명의 오버사이터를 가지고 있는데, 이것은 위키미디어 프로젝트의 나머지 부분과 거의 비슷하다.OTRS 감독 요청에 가장 먼저 대응하기 위해 오버사이터가 서로 걸려 넘어지는 기간(최근 포함)이 연장되었다.우리는 거의 절망적인 곤경에 처해 있지 않다.리스크 담당자(대화) 04:32, 2016년 5월 26일 (UTC)[응답]

  @Risker:51까지 어떻게 가십니까?나는 현재 49를 세고 있다; 어제 나는 50을 세었지만, 앨리슨(대화·출연자들)은 12시간도 채 못되어 자발적으로 감시를 포기했다. --Redros64 (대화) 10:41, 2016년 5월 26일 (UTC)[응답]

  예 {{NUMBERINGUMP:압박}}이(가) 제공

45

— 마틴 (MSGJ · talk) 10:54, 2016년 5월 26일 (UTC)[응답]

• 번호표를 봤는데감시는 51개라고 말했다.아마도 누군가가 그것을 고쳐야 할 것 같다. 무슨 이유에서인지 나는 그 페이지를 편집할 수 없다.리스크 담당자(토크) 16:28, 2016년 5월 26일 (UTC)[응답]

  그 목록을 볼 때 내가 가장 먼저 알아차린 것은 앨리슨이 상장되어 있다는 것인데, 그 사람은 내가 어제 권리를 포기했다고 위에서 언급했던 사람이다. 그리고 나서 나는 조금 더 아래를 내려다보다가 위에서 언급했던 다른 이름, 즉 내가 위에서 언급한 다른 이름을 발견했다.Beeblebrox; 그래서 그것은 최신 상태로 유지되지 않았다.좀 더 주의 깊게 살펴보니 2016년 1월 1일 23시 32분에 비트 손실을 본 세라핌블레이드도 리스트에 포함되어 있다는 것을 알게 되었다.이로써 51에서 48로 줄어들게 되었다. - 그것과 나의 49의 불일치는 짐보 웨일즈가 오버사이터 권리를 가지고 있음에도 불구하고 목록에 없다는 것이다. --Redros64 (토크) 17:32, 2016년 5월 26일 (UTC)[응답]

  해당 페이지는 m:감독 정책/감독요청. 이것은 표시된 "en" 버전을 업데이트하기 위해 편집될 때마다 번역을 표시해야 하는 것으로 보인다.목록을 편집하는 유일한 방법은 그 페이지로 가서 변경하는 것이다.정말 악몽 같군...지금 고쳤다.Ajraddatz (대화) 2016년 5월 26일 18:45 (UTC)[응답]

  이제 48 더하기 짐보를 보여주네 49명 목록과 일치해 고마워 --Redros64 (토크) 2016년 5월 26일 19:16 (UTC)[응답]

웨이백 머신 vs.Archive.is

이미 논의되고 있을 수도 있기 때문에 나는 큰 논쟁을 시작하고 싶지는 않지만 왜 웨이백 머신이 Archive.is보다 더 많이 사용되는지 물어보기 위해서입니다.

예를 들어, 나는 Archive.is에서 훨씬 더 좋은 경험을 했다.훨씬 빠르다 + 웨이백보다 훨씬 많은 페이지를 보관하고 있다 + 웨이백에 비해 URL이 훨씬 짧다(일반적으로도). --Obsuser (토크) 00:35, 2016년 6월 1일 (UTC)[응답]

문제는 archive.is(오늘날 archive.is)이 WP에 그들의 아카이브 링크를 주입하기 위해 봇을 사용함으로써 이 사이트의 진정한 목적을 문제 삼았다는 것이다(archive.is 링크를 블랙리스트에 올린 첫 번째 RFC 참조).웨이백 머신/archive.org은 매우 분명한 목표를 가지고 있으며 로봇과 같은 것들에 대한 존경을 보여준다.txt (이러한 이유로 일부 장소의 보관이 PITA가 되는 경우에도).단일 페이지 아카이빙의 경우 의도와 목적이 분명한 WebCite를 다시 지원한다는 점에 유의하십시오. --MASEM (t) 01:06, 2016년 6월 1일(UTC)[응답]

archive.is이 어디 있는지 알기나 해?로버트 맥클레논 (대화) 01:18, 2016년 6월 1일 (UTC)[응답]

오의, archive.is의 첫 문장에 따르면.-맨드러스 인터뷰 01:20, 2016년 6월 1일 (UTC)[응답]

개인적으로 나는 인터넷 아카이브(Wayback)가 불분명한 동기부여로 변덕스러운 행동을 하는 것 같은 archive.is 뒤에 있는 한 사람과 대조적으로 선의로 디지털 유산 사업을 장기적으로 보존하는 것에 대해 더 자신감을 가지고 있다.– 피누서톱 (토크 ⋅ 기여) 01:26, 2016년 6월 1일 (UTC)[응답]

@Obsuser, Masem, Robert McClenon 및 Finusertop:사실 지금 RfC가 있어.RfC를 접한 이후 내가 수집할 수 있었던 것을 바탕으로 당신의 질문에 답하기 위해...

Archive.is 프로: 어떤 페이지도 로봇을 존중하지 않고 보관한다.txt(이 효과적인 옵트아웃 허용량 때문에, archive.org은 특정 도메인을 보관하지 않을 것이며, 도메인 소유자가 로봇을 구현하면 기존 아카이브가 제거될 수 있다.txt 나중).

Archive.is의 반대자: archive.org과는 달리, 그것은 불투명한 자금모형을 가지고 있고, 광고를 할 수도 있고, 그렇게 오래되지 않았고, 앞으로 몇 년 후가 될 것이라고 확신하기가 더 힘들며, 사람들이 링크를 통해 위키피디아를 반복적으로 스팸 발송했다.

추가: 링크 단락기가 내장되어 있기 때문에 URL이 더 짧다.만약 당신이 archive.org 링크를 가져와서 bit.ly을 통해 보냈다면 (링크 단축제도 일반적으로 블랙리스트에 올라 있다.)— Rhodendrites \ 02:34, 2016년 6월 1일 (UTC)[응답]

• 내가 지금까지 봇에게 archive.is은 악몽이라고 지적해도 될까?헤더 정보가 보존되지 않아 봇이 아카이브의 작동 여부를 판단하기 어렵다.단축된 URL도 도움이 되지 않는데, 특히 InternetArchiveBot을 실행하는 Cyberbot II는 항상 원래 URL을 저장해야 하며, 아카이브 URL에서 해결해야 하는 경우도 있다.요약하자면, archive.is에 보관소를 문의할 때 잘못된 긍정을 얻을 가능성이 archive.org에 비해 훨씬 크다.—^cyberpower_{Chat:Limited Access} 03:25, 2016년 6월 1일 (UTC)[응답]

그래, 고마워.웨이백이 프로페셔널하고 그렇게 생겼기 때문에 내가 이 결과를 받아들였어.하지만, 실제로 더 많은 페이지와 로봇들이 있다.Txt는 Archive.is에 보관되어 있어서 유용하다.

나는 심지어 Archive.is이 위키피디아에서 블랙리스트에 올라있는 도메인이라고 추측했다. 왜냐하면 그것은 일종의 해적이나 그런 것이기 때문이다.Wayback에 특정 웹 페이지가 보관되어 있지 않은 경우 Archive.is URL을 추가하는 것이 권장되는가?그렇지 않은 것 같아, 특히 웨이백이 로봇이나 로봇 때문에 그것을 표시/보관할 수 없다면 말이야.txt와 Archive.is은 그것을 아름답게 보관하고 있다.

하지만 내가 지금 그것을 할 수 있기 때문에 모든 사람들이 어떤 웹 페이지의 스냅숏을 찍어서 어딘가에 저장하는 것이 허용되어야 하지 않을까?그것은 한 순간에 공개되었다. 즉, 누군가가 그 순간에 스냅 사진을 찍을 수 있고, 무엇이 표시되었는지 기억할 수 있다는 것을 의미한다.—Obsuser (대화) 03:38, 2016년 6월 1일 (UTC)[응답]

그래서 내가 이렇게 한 페이지를 저장하는 좋은 방법인 WebCite [1]을 언급했던 것이다.archive.is과 같은 기능을 하지만 Archive.org과 같이 우리는 그들의 목적과 이유를 알고 있다. --MASEM (t) 04:58, 2016년 6월 1일 (UTC)[응답]

내가 RfC에 던진 아이디어도 잘 틀어놓지 못했어 : (그것은 일종의 접선이다):archive.is이 블랙리스트에서 삭제되었는지 여부와 상관없이 템플릿에 매개 변수를 추가하는 것이 유용할 것 같다.둘 이상의 아카이브를 허용하려면 웹을 인용하십시오.가능하면 archive.org을 이용하는 것이 가장 좋은 방법이라고 생각하지만 만약의 경우를 대비해서 웹 사이트 아카이브(또는 블랙리스트에서 삭제된 경우 archive.is 또는 그 밖의 다른 것)도 가질 수 있을 것이다.링크 부패는, 나에게 있어서, 인용문에 몇 글자를 저장하는 것보다 위키피디아의 장기적 문제에서 훨씬 더 중요한 것이다.나는 그것을 실행하는 가장 좋은 방법을 모른다.최소한 두 번째 아카이브는 reflist에 표시하지 않아도 되고, "백업"이나 "웹사이트"와 같은 링크된 단어일 수도 있다.— Rhodendrites \ 15:43, 2016년 6월 1일 (UTC)[응답]

활동에 따라 WikiProject 참가자 목록 업데이트

위키프로젝트 공간에 있는 "참가자" 목록은 종종 활성 사용자와 비활성 사용자를 구분하지 않는다.이로 인해 특히 비활성 사용자의 긴 목록에 활성 사용자가 몇 명만 있는 경우 활성 사용자를 찾기가 어려워진다.나는 봇이 모든 참가자 목록(또는 우리가 동의할 수 있는 부분 집합(예: 선택한 프로젝트만 해당)을 검토하고 비활성 사용자를 각 목록의 "비활성 참가자" 섹션으로 이동시킬 것을 제안한다.예를 들어, 봇이 참가자 대다수가 비활성 상태임을 감지할 경우, 대신 "활성 참가자" 섹션을 만들 수 있다.현재, 활동에 대한 좋은 정의는 "지난 3개월 동안 적어도 한 번의 편집"이라고 생각한다.

당신은 어떻게 생각하나요?이것이 시행되어야 하는가?옵트인(opt-in)일까, 옵트아웃(opt-out)일까?나는 개인적으로 봇이 하는 일은 프로젝트 참여자들이 나열되는 순서를 바꾸고 섹션 제목을 추가하는 것뿐이라는 점에서 옵트 아웃을 하는 것이 효용성을 떨어뜨린다고 생각한다. 하지만 물론 그렇지 않다면 나는 합의를 연기할 것이다.

나는 이미 이것에 대한 샘플 코드를 작성했다; 이전 논의는 2009년 6월 VPPR 스레드와 2014년 8월 VPPR 스레드를 포함한다; 현재 논의는 봇 요청과 승인 요청을 포함한다.봇 요청에서 사용자를 ping하는 중: 트랜스휴머니스트, 조니시95, 와르스피엘체커스, 리치 팜브루, BU 롭13.엔터프라이즈y (토크!) 03:26, 2016년 5월 31일 (UTC)[응답]

@Enterprisey:위키프로젝트 디렉토리 보셨어요?그것은 주제에서 활동 중인 다른 회원들뿐만 아니라 활동 중인 회원들의 목록을 자동으로 생성했다.— 로도덴드라이트 \\ 17:03, 2016년 5월 31일 (UTC)[응답]

응, 본 적은 있지만, 이 특정한 문제를 정확히 다루지는 않는 것 같아(예: WP:WPX 목록은 자체 선택되지 않지만 Wiki Project-space 목록은 다음과 같다.그러나, 예를 들어, 나는 참여자 페이지에서 디렉토리로 연결되는 링크가 도움이 될 것이라고 생각한다.엔터프라이즈y (토크!) 17:25, 2016년 6월 1일 (UTC)[응답]

요청 투명성 차단 해제

현재 모든 블록의 로그가 존재하며, 이 로그는 검사할 수 있다.그것이 존재하고 검사될 수 있다는 사실은 투명성에 결정적으로 중요하다.부여 여부와 상관없이 해당 요청에 연결/목록하는 차단 해제 요청의 로그는 존재하지 않는다.그러므로, 블록 없는 요청의 영역에서 무슨 일이 일어나고 있는지 큰 그림의 감각을 얻는 실질적인 방법은 없다; 단지 큰 그림의 투명성은 없다.나는 (진실일 수도 있고 아닐 수도 있지만 알 방법이 없다) 이 영역에서 거래하는 블록 해피 관리자가 상대적으로 적어서 잠재적 편집자를 쫓아가서 위키백과(새로운 편집자를 모집/유지하는데 큰 문제가 있는 것으로 보인다)에 대해 걱정한다.로그를 이행할 것을 제안한다(기술적으로 어떻게 이행할 것인지 나중에 결정해야 한다).68.48.241.158 (대화) 13:36, 2016년 5월 30일 (UTC)[응답]

분명히 op.68.48.241.158 (대화) 13:53, 2016년 5월 31일 (UTC)[응답]으로 지원

이 링크에서 모든 블록을 찾을 수 있다.그리고 대부분의 차단 해제 요청은 이 페이지 기록에서 연결된 수정본에서 찾을 수 있다.עודדהododOd Mishehu 14:33, 2016년 5월 30일 (UTC)[응답]

이것들은 흥미로운 연결고리들이다.전에 본 적이 있는지는 잘 모르겠네, 고마워.내가 설명한 전반적인 투명성 문제는 그들이 해결하지 못할 것 같다.첫 번째 링크는 거부당한 것과 반대로 부여된 것만을 보여주는 것처럼 보이고 다른 링크는 상당히 비실용적이어서 전혀 투명하지 않다.모든 차단되지 않은 요청에 대한 간단한 로그를 보고, 해당 요청의 승인 여부를 나열하는 것을 좋아한다.68.48.241.158 (대화) 14:50, 2016년 5월 30일 (UTC)[응답]

나는 그 과정이 전반적인 투명성을 얻을 수 있을지 모르겠다: WP에 대한 요청이 있다.특히 이 과정에서 개인 정보가 공개되는 경우 공공의 정밀조사를 위해 개방되어서는 안 되는 UTRS.—C.Fred (대화) 15:02, 2016년 5월 30일 (UTC)[응답]

이것은 사실처럼 보이지만, 우리는 최소한 전통적이고 가장 자주 사용되는 차단되지 않은 요청(완벽한 것을 선의 적으로 보지 말 것)까지 투명성을 얻을 수 있다.68.48.241.158 (대화) 15:25, 2016년 5월 30일 (UTC)[응답]

참고 항목: 위키백과:빌리지_펌프_(idea_lab)#어떻게_are_technical_changes_이행되었는가.3F - WP별로 다음 사항을 병합할 수 있음:Multi. — xaosflux^Talk 15:03, 2016년 5월 30일 (UTC)[응답]

나는 강력히 반대할 것이다...이건 실제 제안이야...나는 거기서 아무것도 제안하지 않았지만 기술 변경사항의 실행방법에 대한 일반적인 정보를 구했다.68.48.241.158 (대화) 15:28, 2016년 5월 30일 (UTC)[응답]

내 말은 여기나 저기나 합쳐질 수 있다는 뜻이야, 적어도 각 페이지에는 링크를 걸도록 해.또한 개발에 오랜 시간이 걸릴 경우(그 후 이 페이지에서 중앙 집중화된 페이지를 연결) 어딘가에서 자체 페이지를 얻을 수도 있다.— Xaosflux^Talk 16:18, 2016년 5월 30일 (UTC)[응답]

당신이 한 연결은 괜찮지만, 그 실이 특정 제안과 직접적으로 관련이 없는 많은 기술적인 논의인 것처럼 복잡함을 결합하는 것은 괜찮다고 생각한다.68.48.241.158 (대화) 16:53, 2016년 5월 30일 (UTC)[응답]

맞아. 다른 곳에 포스팅을 해서 다른 답변을 기대하는지 모르겠네.그들은 이미 이 정보를 찾는 데 필요한 모든 것을 제공받았어. 조금만 노력하면 될 거야.HighInBC 15:05, 2016년 5월 30일 (UTC)[응답]

다시 한 번 이해를 못하는구나, 하이스비시다른 실에서는 기술적 사물이 바람직하다고 판단될 경우 어떻게 구현되는지 묻고 있었다...나는 거기서 아무것도 제안하지 않았지만 일반 정보를 찾고 받았다...내가 제안할 게 있어68.48.241.158 (대화) 15:21, 2016년 5월 30일 (UTC)[응답]

"나는 로그가 구현될 것을 제안한다." - 분명히 말하지만, 영어 위키백과에서 이러한 행동에 대한 일종의 로깅을 요구할 수 있는 과정을 제안하는가? ("어떻게 구현될 것인가"라는 역학을 제쳐두고)?— Xaosflux^Talk 16:21, 2016년 5월 30일 (UTC)[응답]

난 그 질문을 이해할 수 없다.'필요'가 있는 건지는 모르겠지만...그러나 만약 그것이 좋은 아이디어라고 생각되었다가 실행된다면 그것은 존재할 것이다(위에는 "사진가"라는 것이 있다)..68.48.241.158 (대화) 16:40, 2016년 5월 30일 (UTC)[응답]

우리는 모두 자원 봉사자들이다.우리는 누군가가 이 도구를 쓰기로 한 제안에서 합의를 볼 수 없다.만약 누군가가 그것을 쓰려고 한다면 그들은 그렇게 할 수 있지만 우리는 단체로 누군가가 그것을 해야 한다고 결정할 수 없다.당신은 이 도구에 대한 당신의 욕구를 두 곳에서 모두 표현해서 정말로 불필요한 것이다.우리는 엇갈린 주제들을 병합하여 논의를 한 곳에서 계속하려고 노력한다.HighInBC 16:44, 2016년 5월 30일 (UTC)[응답]

다시 말하지만, 당신은 물건들을 섞고 혼란스럽게 하고 있다.68.48.241.158 (대화) 16:48, 2016년 5월 30일 (UTC)[응답]

문제를 더 잘 정의하자.차단 해제 요청 로그 또는 거부된 차단 해제 로그를 원하십니까?—C.Fred (대화) 16:53, 2016년 5월 30일 (UTC)[응답]

나는 이와 같은 것을 상상한다: 전통적인 차단되지 않은 요청이 대화 페이지에 만들어질 때마다 항목이 생성되는 로그. 또한 열려 있는지, 등록되어 있는지, 거부되어 있는지를 보여주는 칼럼이 있다.그리고 그들 모두가 초과근무를 한 것을 기념할 것이다.아주 직설적인..68.48.241.158 (대화) 16:57, 2016년 5월 30일 (UTC)[응답]

따라서, 우리는 차단되지 않은 템플릿이 추가된 사용자 대화 페이지를 찾는 봇이 필요하며, 그런 다음 요청이 여전히 열려 있는지, 거부되었는지, 허가되었는지 여부를 결정해야 한다.차단 해제 템플릿이 제대로 삭제된 경박하거나 유효하지 않은 차단 해제 요청은 어떻게 처리하시겠습니까?—C.Fred (대화) 2016년 5월 30일 (UTC) 17:00[응답]

(충돌 편집)로그는 다양한 형태를 취할 수 있고, 소프트웨어가 생성되거나, 수동(예: Wikipedia_talk:IP_block_면제/log).수동 로그는 주로 소프트웨어 로그가 자동화되는 관리 제어(즉, 정책)를 통해 시행할 수 있다.소프트웨어의 경우 기본적으로 2가지 옵션이 있다: 누군가(당신도!)는 편집 내용을 검사하고 결과를 기록하기 위해 봇을 실행할 수 있다. 또는 백엔드를 확장 또는 패치를 통해 변경할 수 있다.모든 소프트웨어 로그는 입력 매개 변수를 충족해야 하며, 이 매개 변수가 99%의 사용률을 충족하려면 정책도 필요하다(예: 이 메커니즘을 통해 차단 해제 요청이 이루어져야 하며, 관리자 및 편집자는 이메일 요청과 같은 다른 입력을 무시해야 함).— Xaosflux^Talk 17:03, 2016년 5월 30일 (UTC)[응답]

기술적 문제는 최종적인/결정적인 코드 작성자들에 의해 처리되어야 할 것이다. 나의 감각은 오늘날의 기준에 의한 상당히 사소한 코딩일 것이다.난 네가 말하는 대부분의 것을 이해하지 못하겠다.어쨌든 그건 정말 다른 논의야68.48.241.158 (대화) 17:07, 2016년 5월 30일 (UTC)[응답]

Xaosflux는 행동전선에 매우 타당한 점을 제기한다.로깅 시스템에서 {{unblock}} 템플릿을 사용해야 하는 경우, 이를 사용하지 않는 요청이 무시되거나 관리자가 요청을 처리하기 전에 템플릿을 적용해야 하는가?또는 로깅 시스템이 열려 있는 동안 로깅되지 않았던 거부/grated Unblock을 인식할 수 있을 만큼 충분히 익숙해질 것인가?

만약 당신이 모든 차단되지 않은 요청들을 수동으로 기록하도록 제안한다면, 나는 규칙이 교활하고 더 많은 남용 가능성을 이유로 그것에 반대한다.거부된 차단 해제 사항을 모두 수동으로 기록해야 하는 경우 차단 해제를 반복적으로 요청하는 사용자에 대해서는 많은 관리자가 짧은 퓨즈를 얻게 되며, 차단된 사용자가 더 많아지면 대화 페이지 액세스가 취소된다.—C.Fred (대화) 17:11, 2016년 5월 30일 (UTC)[응답]

이 제안된 프로세스가 캡처할 차단 해제 요청의 백분율을 선택하십시오.{{unblock}}}의 사용만을 모니터링하려고 하시거나, 누군가가 차단 해제 요청을 할 수 있는 방법(예: UTRS 티켓, 토크 페이지 메시지, 템플릿을 사용하지 않은 요청)을 모니터링하려고 하시는지요?— Xaosflux^Talk 17:13, 2016년 5월 30일 (UTC)[응답]

전통적인 템플릿만 있는 것 같은데...많은 투명성을 얻기 위해 필요한 것은 이것뿐입니다.68.48.241.158 (대화) 17:17, 2016년 5월 30일 (UTC)[응답]

물론, 코딩에 필요한 경우 템플릿을 삽입해야 한다.뭐가 그렇게 중요해? 암호화가 되면 다 자동화가 될 텐데, 이 매뉴얼을 이해하지 마.그러나 이러한 논의는 기술 문제에 대해 추측하는 대신 제안서와 그 자체로 좋은 아이디어인지에 초점을 맞추지 못할 수 있음.68.48.241.158 (대화) 17:16, 2016년 5월 30일 (UTC)[응답]

• 나는 한 블록을 단지 하나의 특정한 메커니즘으로 어필하려는 편집자들을 제한하는 어떤 것에 강력히 반대한다.나는 차단되지 않은 요청/결과/노트의 보고서를 작성하기 위한 봇 아이디어를 지지한다.— Xaosflux 17:19, 2016년 5월 30일 (UTC)[응답]

동의해, 길 제한에 관심 없어68.48.241.158 (대화) 17:21, 2016년 5월 30일 (UTC)[응답]

당신은 WP의 로그와 비슷한 것을 찾고 있는 것 같다.SPI. 열린 로그가 아닌 연속 로그를 찾고 있는 것 같은데 -- GB 팬 00:23, 2016년 5월 31일 (UTC)[응답]

기록하기는 꽤 쉬울 것이다.{{Unblock}}다른 요청은 기록되지 않은 상태로 남아 있을 것이라는 이해에 따라.물론 이것은 게임의 대상이 될 것이다.최상의 선택:리치 팜브루, 2016년 5월 31일 (UTC)
[답글]

'게임하기 쉬운 게임'에 대해 무슨 말을 하는 거야?기록만 남길 뿐이지..사람들이 어떤 의미로든 '게이밍(gaming)'하고 있었는지(이것이 어떤 의미인지 전혀 모르겠다) 그때 볼 수 있었다. (대화) 11:29, 2016년 5월 31일 (UTC)[응답]

• 그렇다면, 이 제안의 동기는 무엇인가?내 경험상, 내가 접하는 대부분의 거절된 차단되지 않은 요청은 합법적이었다.나는 왜 이것이 제안되고 있는지 잘 모르겠다.왜 우리는 그런 통나무조차 필요할까? 나는 여기서 어떤 막힘없이 감소하는 전염병이 일어나고 있는지 알지 못한다.세르게크로스73 msg me 12:34, 2016년 5월 31일 (UTC)[응답]

동기 부여를 위해 OP를 참조하십시오. 명확하게 설명되어 있다.'내 경험상'..그게 문제야...난 투명성을 추구한다. 너의 경험에 의존하는 것에는 관심이 없다.68.48.241.158 (대화) 12:50, 2016년 5월 31일 (UTC)[응답]

좋아, 그게 네 설명의 정도라면, 그리고 이게 네가 시큰둥해서 너의 차단되지 않은 요청이 거절당한 거라면, 난 그 제안의 필요성에 근거해서 반대해.세르게크로스73msg me 13:02, 2016년 5월 31일 (UTC)[응답]

당신의 의견은 불안정하고, 나쁜 평가를 받는다고 가정하고, 관리자로서 완전히 부적절하다.따라서 할인될 것이다.사실, 내 제안은 내가 걱정하는 관리자들의 활동에 대한 투명성을 높이기 위해 고안된 것이다.그리고 분명히 당신의 행동은 그 걱정을 덜어주는데 아무런 도움이 되지 않는다.좋은날..68.48.241.158 (대화) 13:12, 2016년 5월 31일 (UTC)[응답]

내 대답은 부적절하지 않다 - 나는 우리가 왜 개념적으로 이것을 필요로 하는지에 대해 더 많은 이유를 물었고, 당신은 나에게 게으른 "에, 가서 찾아봐"라는 대답을 했다.그게 정말 날 설득할 생각이었나?아니면 누구라도?만약 여러분이 동기 부여에 대한 추측을 원하지 않는다면, 여러분 자신을 더 잘 설명하도록 노력하라.나 혼자가 아니다. 대부분의 참가자들은 당신이 실제로 원하는 것이 무엇인지 혼란스러워 하거나 실현가능성이나 허점에 대해 염려하는 것 같다.당신의 토론의 대다수가 결국 이와 같은 방식으로 흐지부지되는 것을 눈치채지 못하셨습니까?세르게크로스73msg me 13:39, 2016년 5월 31일 (UTC)[응답]

수술실에 가능한 한 명확하게 설명되어 있어내 동기도 명확하게 설명해주는데..68.48.241.158 (대화) 13:49, 2016년 5월 31일 (UTC)[응답]

그리고 나는 이미 그것에 대해 납득할 수 없다고 말했다.그래서 나는 내 "반대"를 고수하고 있다.세르게크로스73 msg me 14:00 2016년 5월 31일 (UTC)[응답]

위키피디아에 차단되지 않은 요청의 로그를 만드는 것의 문제는 로그에 큰 구멍이 생길 것이라는 것이다.WP를 통해 (내가 알아낼 수 있는 것으로부터) 약 16,000건의 언블록 요청이 있었다.UTRS. 약 한 달 동안 요청서에 일부 위키 정보가 게시되었지만, 논의되고 있는 대부분의 정보는 로그에 포함되지 않았다.요청이 왔다가 닫혔다는 것은 기본적인 정보일 뿐이다.그것은 요청에 대한 자세한 정보를 포함하고 있지 않다.또 다른 구멍은 관리자들에게 이메일로 보낸 차단 해제 요청으로, 그것들은 어디에도 기록되지 않을 것이다. -- GBfan 13:27, 2016년 5월 31일 (UTC)[응답]

괜찮아, 완벽을 선의 적이 되게 놔둘 이유가 없어. 공개 토크 페이지에 있는 차단되지 않은 표준 템플릿 요청의 일지는 투명성의 큰 증가가 될 거야.68.48.241.158 (대화) 13:30, 2016년 5월 31일 (UTC)[응답]

참고: 제안서를 누가 코딩/실행할 것인지 검토하기 전에 제안서에 대한 지지를 얻고/거부하는 것이 좋다는 가정 하에 운영하고 있다.그러나 공공 위키백과 데이터의 로그/봇/앱은 다른 사람의 지원과 무관하게 간단하게 만들 수 있을 것이다....?68.48.241.158 (대화) 13:56, 2016년 5월 31일 (UTC)[응답]

위에 언급된 것인지 확실하지 않지만(모든 디프트를 확인하지 않음) 여기에 열려 있는 차단 해제 요청이 이미 기록되어 있음:RFU. 카테고리를 갖는 것은 아마도 큰 스트레칭은 아닐 것이다, CAT:한 페이지에 여러 개의 차단되지 않은 요청을 처리하는 시스템을 마련하기 위해 코더에게 맡기겠지만 닫힌 차단되지 않은 요청에서 거부된 플래그를 찾는 URFU(실패한 차단 해제 요청?)블랙매인 (대화) 14:23, 2016년 5월 31일 (UTC)[응답]

네, 코드 맞추기 힘들진 않을 것 같은데...그리고 여러 번 요청해도 괜찮을 겁니다. 나는 그 요청들이 포함되었으면 좋겠는데.리스트에 또 다른 항목이 있을 거야68.48.241.158 (대화) 15:56, 2016년 5월 31일 (UTC)[응답]

A FINAL NOTE: (내 생각에).....어떻게 봇이 만들어지고 도입되는지에 대해 더 많은 것을 알게 된 후, 이 실이 특별히 필요한지는 잘 모르겠지만... 단순히 봇을 만들 의향이 있는 사람이 있는지 알아보고, 봇이 승인되었는지 확인하는 것이 더 문제인 것 같다...분명히 내 것으로 보인다.제안은 좀 더 투명성을 만들어낼 수 있는 잠재적인 이익만...그러니 이건 좀 무의미한 논의야68.48.241.158 (대화) 18:40, 2016년 5월 31일 (UTC)[응답]

• 위키피디아에는 평행한 실이 있는데,마을 펌프(아이디어 랩)/아카이브 20#기술 변경사항 구현 방법그리고 위키백과에서:마을 펌프(기술)#기술 질문 다시 시도 중.이는 WP에 위배된다.Multi. --Redros64 (대화) 18:26, 2016년 6월 2일 (UTC)[응답]

사용자공간에서 제안된 삭제 초안

제안된 초안 공간 삭제에 맞추어, 나는 기사 마법사 시대부터 사용자 공간에 수만 개의 오래된 초안이 있다는 것을 주목한다. (2009년으로 거슬러 올라가지만 2004년으로 거슬러 올라가면 5,000여 개의 초안이 있고, 그 초안은 그 템플릿을 사용하는 초안만 있다.)본 RFC의 합의는 WP에 의해 "GNG를 결코 충족하지 못할 것"이라는 초안을 삭제할 수 있다는 것이었다.WEBHOST. MFD에서 정기적이고 반복적인 논쟁보다는, 다음과 같은 규칙으로 새로운 사용자 공간 제안 삭제 시스템 초안을 허용할 것을 제안하고 싶다.

1. userspace 초안: (a) 사용자가 5년 동안 편집하지 않은 경우, (b) 5년 동안 초안(부록 봇)이 편집되지 않은 경우, 그리고 선의의 편집자는 초안이 "WP를 결코 충족하지 못할 것"이라고 믿는 경우 (c)GNG"는 삭제를 제안할 수 있다.
2. 삭제를 제안할 경우, 작성자와 사용자 공간을 위한 대화 페이지(다르면)는 초안이 카테고리(Category)와 유사한 날짜 범주로 변경되었음을 통지한다.최소 6개월 동안 제안 삭제. 이 기간 동안 어떤 이유로든 제안 삭제를 삭제할 수 있다.
3. 제안된 삭제를 삭제하는 사람이 없는 이 6개월 기간이 지나면 관리자는 이를 검토할 수 있으며 관리자가 페이지가 WP를 결코 충족하지 못할 것으로 믿는 경우:GNG, 그 페이지는 이 5년 반 동안의 무활동 기간이 지나면 삭제될 수 있다.
4. 일단 삭제 제안이 삭제되면 다시 5년간 삭제 제안으로 재등록할 수 없다.그것은 항상 WP로 가져갈 수 있다.언제든지 또는 CSD 기준에 미달하는 경우 MFD는 반쪽짜리 상황이지만, 이는 1회 반쪽이다.

지금, 나는 5년 동안 재미나 WP를 만들기 위해 또는 약간의 WP를 만들기 위해 활동하지 않은 것을 제안하는 것이 아니다.포인트(POINT)는 다른 논의 사항을 제공했다.WP:STale은 현재 1년 표준을 사용하지만 WP에서 반복적인 논의를 하고 있다.MFD는 정기적으로 (내 말은 규칙적으로) 3~4년, 7년, 9년, 심지어 10년 동안 활동하지 않은 편집자들은 복귀를 두려워하여 자신의 내용을 삭제해서는 안 된다고 주장한다.가장 극단적인 예는 10년 초안이지만 5년이라는 기간은 MFD의 "정규직"이 나에게 그 정도의 활동을 하지 않는 것에 대한 반반으로 보인다.이러한 논쟁들 중 어떤 것도 초안이 실제로 실행 가능한 내용인지 아닌지에 대한 것이 아니며, 그것은 다른 문제라는 점에 유의하십시오. 단지 어느 정도 합의된 페이지를 쓰레기처럼 삭제하는 것이 전혀 이루어져야 하는지에 대한 것이다.마지막으로 편집한 후 5년이 지난 후에도 5년은 2011년 5월로 이어져 WP에서 공간을 차지하지 않고도 6개월 내에 어느 정도 해결될 수 있는 약 17K의 오래된 기사 마법사의 초안 또는 그 미등록의 절반에 해당하는 내용을 다루고 있다는 점에 유의하십시오.MFD. 댓글 있어? -- 리키81682 (대화) 09:17, 2016년 5월 22일 (UTC)[응답하라]

아무 문제 없어. --QEDK (T ☕ C) 09:28, 2016년 5월 22일 (UTC)[응답하라]

이것이 반갑지 않은 접점이 아니길 바라며, 리키81682는 이미 다른 곳에서 해싱이 되었는지는 나보다 더 잘 알겠지만, 초안이 삭제된 사용자들에게 제공하는 메시지/메커니즘에 대한 트윗을 통해 이 문제를 완화시킬 수 있을 것 같다."12개월 이상 편집하지 않았고 12개월 이상 이 초안은 편집하지 않았기 때문에 일상적인 정리의 일환으로 삭제된 것이다.나중에 다시 돌아와서 이 초안을 복원하려는 경우(또는 다른 사용자가 복원하기를 원하는 경우) 아래 단추를 클릭하면 관리자가 이전과 동일하게 복원한다. ["내 기사 제목 초안 복원"이라고 쓰여 있는 큰 단추]

내 언어는 신중하게 생각하지는 않지만, 그 아이디어는 모든 기준, 어떤 사람들은 불쾌한 표정, 삭제 메시지, 심지어 "삭제"라는 단어도 메시지에서 지우는 것이다. "최근에 집에 들르지 않았기 때문에 우리는 그것을 지하실의 한 상자로 옮겼지만, 우리에게 알려주면 우리는 그것을 다시 당신의 침대에 놓을 것이다.그렇게 되면 많은 사람들이 미룰 수 있을 것 같지가 않아.

즉, 기사의 손쉬운 복원을 위한 체계가 내장되어 있기 때문에 삭제를 제안하는 아이디어가 좋다.비록 기술적으로는 삭제되어 있지만, 우리가 걱정하는 것이 사람들을 멀어지게 하는 것이라면, 프레임과 그것이 쉽게 회복될 수 있다는 확신은 도움이 될 것 같다.— 로도덴드라이트 \\ 13:02, 2016년 5월 22일 (UTC)[응답]

이것은 말이 된다; 긴 태그 지정 후 삭제 전 윈도우가 이의 제기 시간을 충분히 준다.우리는 이것이 "너희는 나빴다"는 것이 아니라 단지 청소 과정이라는 것을 분명히 하는 메시지를 보내야 한다. 나는 로도덴드라이트가 쓴 것 이상의 어떤 것도 생각할 수 없다.나이튼드 (대화) 13:54, 2016년 5월 22일 (UTC)[응답]

동의한다. 언어는 완전히 달라야 한다."오랜만에 뵙는군"(5년 동안 여기서)에 가깝지만 다시 돌아오면 WP로 오십시오.관리자를 환불하거나 도청하면 복구된다." -- Ricky81682 (대화)20:00, 2016년 5월 22일 (UTC)[응답]

• 왜 이 제안된 방법이 단순히 휴면 페이지를 "courtsy blanking"하는 것보다 우월할까?–xeno^talk 13:58, 2016년 5월 22일 (UTC)[응답]

  나는 그것이 여전히 제목에 근거한 검색에 나타나기 때문에 여전히 문제 페이지나 복구 가능한 페이지를 찾는 사람들에게 방해가 되기 때문이라고 추측한다.조조 유메루스(토크, 기여) 15:11, 2016년 5월 22일 (UTC)[응답]

  나는 그것이 그렇게 실용적인 것이 아니라고 생각한다.예를 들어, 페이지가 완전히 "해결되었다"고 느끼는 더 큰 느낌인, 그것은 개인적인 삭제 선호에 지나지 않는 것 같다.WhatamIdoing (대화)20:07, 2016년 5월 22일 (UTC)[응답]

  블랭킹은 블랭커와 크리에이터만 포함하며 일회성 해결책이다.이를 통해 더 많은 사람들이 오래된 초안을 볼 수 있고, 그들이 원한다면 분류할 수 있으며, 그들이 원한다면 정리할 수 있고, 만약 사람들이 성향이 있다면 검토할 수 있다.다른 사람이 작업할 가치가 있다고 생각한다면, 그들은 할 수 있다.그렇지 않다면, 내가 검색을 하고 사용자 공간을 체크하면 내가 뭔가를 찾을 수 있을 것이다.이제, 5년 6개월 후에 우리가 그것을 지워야 한다고 주장할 수 있을 것 같은데, 나는 그렇게 많은 시간이 지난 후에 우리는 그것을 삭제하고 넘어가는 것이 낫다고 말하고 싶다.또한, 어떤 사람들은 페이지의 작성자가 되는 것을 매우 선호한다. (내가 초안 공간 버전을 정기적으로 삭제할 것을 제안하는 이유 중 하나) 그리고 나는 도메인 이름 스쿼트 스텁을 메인 스페이스 버전에 끼워넣은 사람들에 의해 오래된 페이지를 둘러싼 논쟁들이 생겨나는 것을 본 적이 있다. 다른 누군가가 적극적으로 크레딧 래트를 얻기 위해 노력했던 메인 스페이스 버전에.er. 그런 감정들을 감안할 때, 반년 전 무언가를 한 사람을 그런 경건함으로 대우하는 것에 대해 지금 이곳 사람들을 격려하는 것이 무슨 문제가 있는지 모르겠다. -- 리키81682 (대화) 20:19, 2016년 5월 22일 (UTC)[응답]

• 블랭킹이 훨씬 낫고 같은 목적을 위해 쓰이기 때문에, 우리는 그렇게 한다.초안은 아무 것도 하지 않고 거의 주목을 받지 못하기 때문에, 우리가 그 정밀도를 완화해야 하는 이유가 0이라고 본다. 그러나 "feew" 편집자는 그냥 내버려둘 수 없고 나는 타협안을 제안하는 것 외에는 할 수 없다. --QEDK (T ☕ C) 17:04, 2016년 5월 22일 (UTC)[응답]
  • 다른 토론에서, 사람들은 적어도 어떤 통지와 지시사항보다 사전 통보 없이 일방적으로 초안을 비우는 것이 편집자들을 몰아내고 무슨 일이 일어났는지 설명하고 알아낼 수 있다고 생각했다.적어도 제작자가 무슨 일인지 알기 때문에 MFD 토론에서 블랭킹을 제안해도 나는 문제가 없다. -- Ricky81682 (토크) 20:00, 2016년 5월 22일 (UTC)[응답]
    • 이미 5년 동안 편집하지 않은 사람들에 대해 말하고 있으니, 나는 우리가 "아마도 언젠가 그들이 다시 로그인할 것"이라는 것을 무시할 수 있다고 생각한다.<1,000개의 편집과 몇 개월이 없는 회계는 거의 돌아오지 않는다.WhatamIdoing (대화)20:07, 2016년 5월 22일 (UTC)[응답]
      • 이와 같은 몇 페이지는 적극적으로 감시되고 있다.그들은 로그인하지 않을 수 있지만, 당신이 그것을 블랭킹하거나 삭제하도록 지명하면, 그들은 목공예에서 나온다.블랭킹이 되면 (어쨌든 아주 사소한) 시청이 아니면 블랭킹되지 않았는지는 분명하지 않을 것이다.--리키81682 (토크) 20:14, 2016년 5월 22일 (UTC)[응답]
        • 그리고 만약 그것이 비어있지 않다면, - 그렇게 오래된 어음으로는 드물게 - 당신의 제안에 따라 더 이상 삭제 대상이 되지 않을 것이기 때문에, 그 경우에는 삭제되지 말았어야 했다.이런 생각을 하면 할수록, 나는 PROD의 생각이 절망적인 페이지의 논란의 여지가 없는 삭제에 대한 정상적인 기준을 가지고 있고, 나머지는 그냥 비워두는 것이 좋다.WhatamIdoing (대화) 01:38, 2016년 5월 23일 (UTC)[응답]
• 나는 우리가 PROD(관리자의 시간이 필요한)를 귀찮게 하지 말고, 그 대신 페이지를 즉시 비우는 방법에 대한 지침이 포함된 템플리트로 내용을 교체하는 빠르고 간단하며 가벼운 무게 옵션을 사용하는 것이 좋다.봇이 리스트를 만들고, 관심 있는 편집자(있는 경우)가 각 페이지의 내용을 빠르게 검토할 수 있도록 허용하고, 목록에서 제거되지 않은 내용을 삭제하는 것이 더 바람직할 수 있지만, 나는 반드시 봇이 이런 일을 하는 것에 반대하지는 않을 것이다.WhatamIdoing (대화)20:07, 2016년 5월 22일 (UTC)[응답]
  • 반면, 내가 실제로 쏘는 목표는 6개월 이상이다.AfC G13은 사람들이 그들이 원한다면 훑어볼 수 있도록 곧 지원 가능하다.그것이 AFD의 통지가 어떻게 진화했는지, 그리고 기사 구조 대대가 프로드로부터 어떻게 시작되었는지를 보여주는 것이다.만약 블랭킹이 되면 블랭커와 크리에이터가 무슨 일이 일어났는지 아는 사람 이외에는 아무도 없는 상태로 블랭킹이 된다.정기적으로 AFC G13 고양이에 관한 일을 하는 사람으로서, 나는 비 AFC 페이지에 대한 검토가 심각하게 부족하다는 것을 알아차렸고, 적어도 검토 시스템을 갖추는 것이 낫다고 생각한다.5년 전에 시작한 일, 작업할 가치가 있는 것을 발견하면 우리 모두 잘 될 겁니다. -- 리키81682 (대화) 20:14, 2016년 5월 22일 (UTC)[응답]
• 나는 마감일에 몇 달 혹은 몇 년이 걸리는 일반적인 생각을 지지한다.우리는 오래된 페이지를 제거하기 위한 어떤 과정을 거쳐야 한다. 우리는 WP가 얼마나 오래, 어쩌면 몇 년, 어쩌면 한 세기 동안 해가 터지거나 그 너머까지 지속될지 모른다. 하지만 어쨌든, 우리는 "무한도"를 증가시키는 것을 피할 수 있는 과정을 가져야 한다. 그리고 이것은 좋은 과정인 것 같다. (그리고 결국 사용하지 않는 사용자 이름을 한쪽으로 옮길 수 있는 과정이 있어야 한다) 누군가 그렇게 하지 않기를 바란다.ake over user:nabla in the next century, while whatever is kept from me becomes user:nabla(2004-2051) :-) No joke, really.) - Nabla (talk) 20:28, 22 May 2016 (UTC) PS: I mean support the deletion, blanking solves little to nothing - Nabla (talk) 20:32, 22 May 2016 (UTC)[reply]
• 반대한다. 충분히 명확한 기준 없이 미공개 자동 삭제 메커니즘에 너무 가깝다."WP는 절대 만나지 않을 것이다.GNG"는 절망적일 정도로 주관적이며, 사용자 공간(또는 드래프트 스페이스)에서 GNG를 충족시킬 필요가 없다는 최근의 매우 명확한 RfC에 직면해 있다.만약 기준이 "WP의 어느 시점도 실패한 초안"이었다면:"그렇지 않다"는 것이 훨씬 더 입맛에 맞을 것이다.나는 끔찍한 초안의 빈번한 예가 WP에서 더 잘 설명된다는 점에 주목한다.WP가 아닌 (정책) 위반이 아님:GNG 위반(매우 뉘앙스적이고 논쟁적인 가이드라인)."통보성"과 "GNG"는 WP의 많은 부분, 즉 초안을 정리하는 데 사용해서는 안 된다.충분치 않다. --SmokeyJoe (토크) 22:53, 2016년 5월 22일 (UTC)[응답]

이러한 제안은 관리자 중심적이라는 WhatamIdoing의 의견에 동의하십시오.그것은 기본적으로 모든 가치 없는 초안에 대해 신뢰할 수 없는 관리자 검토를 함축하는 관리자 조치를 필요로 한다.소수의 관리자 중 누구라도 이 일을 지루하지 않게 오래 할 수 있다고 생각하는 것은 타당하지 않은 판단이다.UserSpace 초안은 관리 과부하의 원인이 되어서는 안 된다.PROD/삭제 측면은 잊어버리고 잘못된 초안은 설명 템플릿으로 교체하십시오. --SmokeyJoe (토크) 22:57, 2016년 5월 22일 (UTC)[응답]

나는 이것이 어떻게 공개되지 않았는지 잘 모르겠다.우리는 메인 스페이스에 대한 기본적인 기준을 가지고 있고 그것은 기능적으로 몇 년 동안 작동했다.만약 그것이 가능하지 않다면, 밀린 일이 발생할 것이고 우리는 이것을 그냥 닫을 수 있다.첫 번째 밀린 일은 아닐 겁니다. -- 리키81682 (대화) 04:52, 2016년 5월 24일 (UTC)[응답]

카테고리의 기사를 검토하는 사람이 있는 것은 사실이지만:제안된_deletion, PROD를 정당화하는 주요 검토 프로세스는 관심 있는 페이지 감시자가 있다는 가정이다.페이지가 중요할수록 들어오는 위키링크가 많아지고, 이를 눈치챈 편집자들이 많아질수록 더 많은 관찰자를 갖게 될 것이다.그리고 그것은 메인 스페이스를 깨끗하게 유지하는 것의 중요성에 의해 정당화되었다.이러한 것들은 드래프트 스페이스나 사용자 스페이스에 해당되지 않는다.PROD를 감시되지 않는 페이지로 확장하는 것은 새로운 디팩토 CSD 기준을 만드는 것이며, 새로운 CSD 기준으로서 새로운 CSD 기준 기준의 끔찍할 정도로 실패한다.

나는 PROD가 소개되었을 때, 대부분의 페이지에는 다수의 관찰자가 있었고, 대부분의 편집자는 편집자가 활동적이었다고 믿는다.그것은 더 이상 사실이 아니다.기능적으로 작동하는지 어떻게 아십니까?PROD 삭제가 발생하고 있다는 사실에 대해 결정하시겠습니까?매우 느슨한 가정이라고 생각한다. --스모키조(토크) 05:20, 2016년 5월 24일 (UTC)[응답하라]

WP에서의 활동은 다음과 같다.AFC는 이 페이지를 검토할 관심 있는 사람들이 존재한다는 것을 보여준다.MFD에서 정기적으로 논의하잖아그리고 prod는 WP의 일부로서 지속적으로 수행된다.NPP. 방금 본 페이지들이 많이 만들어졌나 보군.만약 내가 페이지를 보고 싶다면, 나는 이 페이지를 보기 전에 5년 이상의 활동을 하지 않는 것을 제안할 것이다.나는 그들이 감시받지 않기 때문에 그것을 정확하게 제안하는 것이다.관심거리가 있다면 내가 직접 작업해서 메인 스페이스로 옮겼으면 좋겠다.그것은 문제가 되지 않는 것이다.우리는 MFD를 계속 사용할 수 있고, MFD에 대해 반복적인 논쟁을 할 수도 있고, 아마도 그것들을 비워둘 수도 있고, 그냥 무시하고 추적 카테고리가 무한대로 커지게 할 수도 있다. -- Ricky81682 (토크) 05:29, 2016년 5월 24일 (UTC)[응답]

추적 카테고리를 그만 볼 수도 있어.무한정에는 한참 모자란다.당신은 이것이 프로젝트에 어떻게 좋은지, 특히 WP를 위반하지 않는 페이지의 삭제에 대해 아직 명확하게 설명하지 않았다.NOT. --SmokeyJoe (대화) 10:03, 2016년 5월 24일 (UTC)[응답]

• 가장 강력한 반대 시간 이것은 불충분한 시간이고, 편집자들은 많은 다년간의 휴식을 취할 수 있고 할 수 있으며, 이것은 정당한 이유 없이 단지 과도한 작업량을 만들어낸다. 107.72.98.9 (대화)
  • 5년이면 시간이 부족하다고?아마 이때쯤이면 저자는 그 일을 잊어버렸을 것이다.עודדהododOd Mishehu 12:13, 2016년 5월 23일 (UTC)[응답]
    • 내가 말했듯이, 이것은 당신이 MFD에서 얻는 것의 중간지점이었기 때문에 나는 그것에 대해 충분히 논쟁을 기대했다. -- Ricky81682 (토크) 04:52, 2016년 5월 24일 (UTC)[응답]
• 지원 5년 동안 초안을 편집하지 않고 수정하지 않으면 삭제해도 안전하다.데니스 브라운 - 2016년 5월 26일(UTC) 2시간 21분 02초[응답]
  • 난 그런 거 안 할 거야.만약 그렇지 않다면, 그들(또는 다른 사람)은 6개월을 더 가지고 있고 그것은 삭제될 수 있다. -- 리키81682 (대화) 21:25, 2016년 5월 26일 (UTC)[응답하라]
• 반대 나는 합법적으로 사용자 공간 초안에 대해 신경쓰지 않으며, 왜 우리가 그것이 필요한지에 대한 논쟁의 페이지를 읽었음에도 불구하고, 우리는 그들을 위해 삭제 과정이 필요하다는 것을 아직 확신하지 못하고 있다.만약 그것이 이미 어떤 종류의 빠른 기준에 맞다면, 그것에 태그를 붙이고 넘어가라. 그렇지 않으면 우리는 왜 신경써야 하는가?우리는 6,474,920개의 기사를 가지고 있다. 나는 수 천 개의 오래된 초안이 하드웨어에 정말 문제가 될 것 같지는 않다.그것은 AfC 드래프트 스페이스가 어떤 조직을 필요로 하는 검토 과정을 가지고 있는 것과는 다르다.게다가, 그것은 단지 사용량이 부족하고 밀린 상태로 끝나게 될 또 다른 평범한 과정으로 보인다. 그리고 또 다른 RfC가 그것을 그것의 고통에서 벗어나게 해야 할 필요가 있다.나는 단지 이것이 필요하거나 유익하다고 생각하지 않는다.우가포드[ttk^h][칸트antɻɪbz] 19:12, 2016년 6월 2일 (UTC)[응답하라]
  • 범주:문서 마법사를 통해 작성된 사용자 공간 초안은 유지관리 범주로, 카테고리:초안 AfC 제출은 유지관리 범주다.MFD를 통해 메인 스페이스 또는 삭제된 페이지와 수년간 삭제된 추적 카테고리를 검토했다(카테고리:2009년 1월부터 기사 마법사를 통해 작성된 사용자 공간 초안은 2012년에 삭제되었다.문제는 AFC와는 달리 G13의 선택지가 없었기 때문에 몇 년 동안 그 자리에 앉아 있던 페이지들이 몇 년 동안 그대로 놓여 있고 말 그대로 한 달에 2-3k 페이지가 만들어지는 것을 지켜볼 수 없기 때문에 산더미처럼 쌓인 잡초를 뽑으려다 그만둔다는 것이다.문제는, 우리는 AFC 산하에서 현재 페이지를 검토하고 삭제한다는 것이다.우리는 절대 쓰레기의 양이 어마어마하기 때문에 오래된 쓰레기들을 치우지 않았다.그곳에는 48k 페이지가 넘었고, 단지 "그 사람은 말 그대로 옛날 기사 마법사의 범위를 넘어 단 한 글자도 추가하지 않았고, 그것은 1년이 넘었다"는 CSD 기준을 추가하기만 해도 15k 이상이 정리되었다.또 다른 절반은 "출처 없이 한 문장을 추가한 사람"과 같은 기준으로 바뀌면 쉽게 없어질 수 있지만 CSD 기준을 흔들기 보다는 좀 더 합리적인 도매 접근법을 찾고자 한다.그렇지 않으면 MFD에서도 삭제될 것이고, MFD에서도 삭제될 것이다. "왜 삭제하는 겁니까?우리가 2008년 이후로 아무도 신경 쓰지 않고 해냈다면 누가 상관하겠어?아니, 9년 전에 편집한 사람이 원칙에서 벗어나서 돌아오기 때문에 반대할 거야. 적어도 1000페이지에 달하는 쓸모없는 쓰레기들을 감시하는 봇들, 템플릿 조정, 그리고 다른 수만 개의 가치 없는 편집들을 당신 때문에 가지고 있는 것 보다 말이야.개인적으로 다른 사람들이 50년 된 고물들을 몇 번이고 헤쳐나가다가 그만둬도 상관하지 않는다.이번에도 2013년 대신 2009년 G13을 생각했다면 여기서 할 얘기가 없었을 것이다.--리키81682(토크) 01:12, 2016년 6월 3일 (UTC)[응답]
• 우가포드 당 반대한다.매년 점점 더 저렴해지고 있는 하드웨어 공간 외에도, 관리자들은 선택과 함께 일해야 할 많은 밀린 업무들을 가지고 있다.이러한 모든 밀린 업무와 이 새로운 업무도 정리할 수 있도록 관리자 수준이 상당히 상승해야 한다(거의 그럴 가능성은 거의 없음).이러한 백로그는 실제로 프런트 엔드 리더 경험을 크게 또는 작게 향상시키는 것처럼 보인다 - 이 과정은 다른 곳에서 사용할 수 있는 시간을 소모하지 않으며 단순히 시간을 소모하지 않는다. -NottNottalkNotify me with {{re} 19:28, 2016년 6월 2일(UTC)[응답]
  • 어쨌든 이것들은 여전히 MFD에 등재되어 있다.당신의 주장이 삭제에 전혀 반대한다는 것이 아니라면, 그리고 그것이 왜 "바보라고 생각하고 나는 당신이 다른 일을 하도록 자원봉사를 하기로 결정했다"는 것 외에 다른 것에 대한 어떠한 주장도 없었더라면, 그것은 단지 MFD에서 새로운 하위 페이지를 만들고 관리자들을 위해 더 많은 일을 하는 것일 뿐이다.날 믿어, 난 그것들을 만들고 닫아.다시 말하지만 G13이 2013년이 아니라 2008년에 시작되었다면, 우리는 할 말이 없을 것이다.이 페이지들은 수년 전 CSD였을 것이고 아무도 편집자 보유나 공간, 하드웨어 문제에 대해 논쟁하지 않을 것이다. 그들은 단지 "당신이 문자 그대로 얼마나 오래 있었든 절대 쓰레기 같은 페이지를 삭제할 수 없다고 말한다면 아무도 AFC 리뷰를 자진해서 하지 않을 것이다. 그리고 우리가 1000페이지로 끝나더라도 상관없다.원격으로 사용할 수 있는 단 한 가지라도 찾아낼 수 있는 잡동사니를 찾아낼 수 있도록 말이야."편집자에 관한 거야오늘 G13을 없애고 6개월 된 무가치한 초안을 삭제하지 말고 5세부터 무가치한 초안을 삭제하자고 제안하는 사람이 어떻게 진지하게 제안하고 있는지 이해할 수 없다.--리키81682 (토크) 01:19, 2016년 6월 3일 (UTC)[응답]

사과 한 입 더?

• Wikipedia_talk:제안된_deletion#RfC:_PROD_in_user_space

이 논의는 그 토론이 종결된 지 4일 후에 시작된 것 같은데...- jc37 10:59, 2016년 5월 31일 (UTC)[응답]

• • 공정하게 말하면, 그것은 현재의 prod를 사용자 공간으로 확장하기 위한 제안이었고 어떤 삭제도 허용했다.이번 건은 최소 5년의 활동기간이 필요하고 한 달보다는 6개월의 복습기간을 갖는다.--리키81682(토크) 18:48, 2016년 6월 2일(UTC)[응답]

RFC: TeX/LaTeX(및 MathJax)에서 [h]의 모든 인스턴스를 [tcb]로 교체하십시오.

SVG와 PNG 폴백이 있는 MathML에서 우리는 phab에서 문제를 얻었다.T136688 및 Phab:T136685.이 모드는 phab으로 인해 기본적으로 연결된다.T131177.현재 이것은 phab을 유발한다.T136688, 페이지:T136685, 페이지:T136672 및 Phab:T136709.다른 해결책은 아직 찾을 수 없지만, 다음과 같은 해결책은 찾을 수 없다.T136688 및 Phab:T136685 TeX/LaTeX(및 MathJax)에서 [h]의 모든 인스턴스를 [tcb]가 유효한 태그가 아니며 PNG 렌더링 모드에서 [tcb]로 보였으나 이제 새로운 모드에서 오류를 발생시킴으로써 해결될 것이다.나는 TeX/LaTeX (및 MathJax)에서 [h]를 [tcb]로 자동 또는 반자동으로 대체하여 다음과 같은 종류의 봇 또는 AWB 스크립트를 작성하여 이 문제를 해결할 것을 제안한다. 이 문제는 이미 팸에서 올바른 해결책으로 받아들여졌기 때문이다.T136685#2345546.

위에서 내가 한 말을 이해하지 못하는 분들을 위해 결정되었다.T136685#2345546) 경우에 따라 [h]를 [tcb]로 대체하기 위해 작은 편집-a-thon이 필요하다.이 RFC는 그것을 할지 말지를 결정하기 위한 것이다.헝거스 (대화) 02:59, 2016년 6월 2일 (UTC)[응답]

지원(RFC: ...의 모든 인스턴스 교체)

• 지원 비록 그것이 별로 문제가 되지 않는다고 생각하지만.2014년 en wiki에서 수학 식에 대한 덤프를 확인했는데 선택적 매개 변수가 있는 어레이와 [h] 매개 변수가 없는 어레이를 사용한 사례가 11개 있다.빛의 스핀 각도 운동량이 가지고 있었다.\begin{array}[l]그것도 고쳐놨어. --Salix alba (토크): 06:14, 2016년 6월 2일 (UTC)[응답하라]
• Support Note, that\begin{array}[h]으로 교체할 필요가 있다.\begin{array}(\[[tcb]\]-> t -> top, b-> bottom, c-> c-> c->의 중심일 수 있음을 나타내는 정규식이다. --Physikerwelt (talk) 16:09, 2016년 6월 2일 (UTC)[응답]
  • @Physikerwelt:로 대체해야 한다는 말인가.[tcb]또는 그 중 하나[t],[c]또는[b]만약 그렇다면, 우리는 단지 꼬리표를 가지고 있지 않을 수 있다.[h]그리고[l]아무것도 하지 않는다.— Hungce(대화 • 기여) 16:21, 2016년 6월 2일(UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평

의 하나[t],[c]또는[b]--Physikerwelt (대화) 19:19, 2016년 6월 2일 (UTC)[응답]

• 그래서 @Physikerwelt: 우리는 의도된 용도가 무엇인지 전혀 모르기 때문에 우리가 알고 있는 한 동일하게 보이기 때문에 그것들을 c로 대체해야 하는가?헝거스 (대화) 23:36, 2016년 6월 2일 (UTC)[응답]

• 지지 나는 이것이 적어도 유용하다고 확신한다.Wugapodes [tɔk^h] [칸트ʃɻɪbz] 18:20, 2016년 6월 2일 (UTC)[응답하라]
• 팸과의 연계에 대한 감사를 표하다내가 보기엔 좋아보이고, 비교적 논란의 여지가 없어.어떻게 하는가에 대해서는, 자동화할 수 있을 정도로 간단하다면, 봇 요청이 가는 길이 될 것이다.--JohnBlackburne^words_deeds 19:32, 2016년 6월 2일 (UTC)[응답]

반대(RFC: ...의 모든 인스턴스 교체)

편집 방법(RFC: 모든 인스턴스 교체...)

토론(RFC: ...의 모든 인스턴스 교체)

• 뭐? 첫째, 산문에 있는 모든 링크에 대해 404개의 오차가 있을 뿐이야.사이드 링크는 작동하지만, 페이브리케이터가 어떻게 작동하는지, 내가 뭘 해야 하는지 아직도 이해가 안 가.우리 중 패브릭터와 TeX에 대한 폭넓은 지식이 없는 사람들을 위해, 이 모든 것이 무엇을 의미하는지 누군가 설명해 줄 수 있을까?Wugapodes [tɔk^h] [칸트ʃɻɪbz] 02:52, 2016년 6월 2일 (UTC)[답글]

  Hungce가 위의 설명을 해주어서 고마워.그러나 모든 좋은 대답과 함께, 그것은 더 많은 질문으로 이어진다.나는 위와 같은 지지에 기대고 있지만 아직 약간의 정보가 더 필요하다.이것이 문맥에 민감한 변화인가?이것은 화장품 문제인가 아니면 내용물인가?나는 봇 정책과 답변이 전용 봇이나 AWB 스크립트가 가장 유익한/유용한/내부 정책인지에 영향을 미치기 때문에 묻는다.우가포드[ttk^h][칸트antʃɻbz] 16:35, 2016년 6월 2일 (UTC)[응답하라]

  h가 방정식에 사용되지 않고 bot가 그렇게 생각할 수 있기 때문에 나는 AWB 스크립트를 생각하고 있다.h가 있는 곳이 매우 맵기 때문에 큰 문제는 아닐 것 같아.나는 이 문제가 외관적인 것이라고 추측한다. 왜냐하면 방정식이 PNG 모드를 사용하는 사람들에게 어떻게 보이는지는 바꾸지 않겠지만, SVG나 PNG 폴백(새로운 기본 및 권장 옵션)을 사용하는 사람들에 대한 방정식보다는 여기서의 오류처럼 보일 것이기 때문이다.헝거스 (대화) 17:57, 2016년 6월 2일 (UTC)[응답]

• 내 생각에 이건 너무 논란의 여지가 없어서 여기에 RFC가 필요 없는 것 같아.기껏해야 WT에서 비공식적인 논의:수학이면 충분할 거야.— 이것과 저것과 (대화) 2016년 6월 2일 (UTC) 10시 30분[응답]
  • 고마워 @이것, 저것, 저것: RFC를 선택하게 된 이유는 봇/AWB 스크립트를 쓸 수 없기 때문이다(아직 AWB에 대한 액세스 권한조차 없다).— Hungce가 추가한 선행 미서명 논평 (대화 • 기여) 15:50, 2016년 6월 2일 (UTC)[응답]
• 나도 네가 쓴 글을 이해할 수 없고, 그 중 하나에 답이 있는지 알아보기 위해 모든 페이브릭터 링크를 읽지는 않을 거야.그렇다면 이미 제공된 링크 중 하나만이라도 '결정되었다' 비트에 대한 링크 하나를 제공할 수 있는가?--JohnBlackburne^words_deeds 16:34, 2016년 6월 2일 (UTC)[응답하라]

  @JohnBlackburne:: phab:T136685#2345546(설명서에 수정하겠다)헝거스 (대화) 17:57, 2016년 6월 2일 (UTC)[응답]

• 허기스, 뭐가 문제야?요약해 주시겠습니까?뭐? 왜? 뭐가 좋아질까? 어떤 축소판일까?아무런 설명 없이 링크 묶음을 가리키는 대신(누구나 "사진:T136685#2345546"?"사진:T123456#7890", "사진:T1#22" 또는 "사진:T333#44444...? - 나블라 (대화) 12:50, 2016년 6월 4일 (UTC)[응답]

• @Nabla: 네시시사리가 아니므로 페이브릭레이터 비트를 읽고 싶지 않다면 마지막에 요약본을 넣으려고 노력했다.문제는 교체할 봇 또는 AWB 스크립트 작성을 지원하는가입니다.[h]와 함께[c]수학 방정식의 맥락에서왜냐하면 이것은 중요하지 않다.[h]수학 방정식에 대한 유효한 인수는 아니지만 무시되고[c]디폴트로 사용되었다.새로운 디폴트 연산 렌더링 시스템은 무시되지 않고 독자들에게 적색 오류를 야기하며 그들은 그 방정식을 스스로 볼 수 없다.당신은 이 오류들 중 하나의 예를 여기서 볼 수 있다.잘못된 것이 교체되는 것 없이 단점이 있다는 것을 알고 있지만 그것은 일어나지 않을 것이다.헝거스 (대화) 13:33, 2016년 6월 4일 (UTC)[응답]

• (위 링크 고정) 사용자:배고프다.요약본에는 "MathML [...]에서 [h]를 [tcb]로 대체하기 위해 필요한 경우도 있다"라고 나와 있다.보통의 위키백과 편집자는 그것이 무엇을 의미하는지 알아야 하는가?나는 가끔 TeX 공식을 쓰는데 네가 무슨 말을 하는지 전혀 생각이 없었다.네 설명에서 뭔가 나온다면, 예전에는 무시되었지만 현재는 오류를 일으켜서 그 방정식을 렌더링할 수 없게 만드는 것이 글쓰기에 사용된 매개변수(MathML?TeX?)가 있다는 것이다.그래서 우리는 "어떤 경우에는" 매개 변수를 교체해야 한다고?어떤 경우?저것들 중 얼마나 많은 것들이 존재하는가?어떤 것의 10여 가지 발생을 대체하는 것(상기의 코멘트를 읽고 있는 것 같음)이나 그 중 1000만 건을 대체하는 것은 같지 않다.만약 그들 중 몇 명을 교체하는 경우.가서 교체해줘, 난 괜찮아. 방정식은 당연히 만들어야 해. - 나블라 (대화) 14:02, 2016년 6월 4일 (UTC)[응답하라]

• @나블라: 우리는 현재 몇 개가 있는지 모르고 있을 수도 있지만, 그냥 돌아다니면서 고치는 것이 좋을 것 같다고 생각해.헝거스 (대화) 2016년 6월 4일 17시 19분 (UTC)[응답]

• 잠재적인 문제를 스캔하는 봇을 쓰는 것은 어떨까?리스트를 얻는 것 만으로도 실제로 변화를 일으키는 봇과는 달리 심각한 승인 문제가 요구되어서는 안 된다.그리고 그것이 몇 가지 잘못된 긍정을 되돌려준다면, 그렇게 할 것이다.페이지마다 RegEx를 하는 봇을 말하는 거야?그건 사소한 일일 거야.만약 그것이 약간의 (잠재적인) 문제들을 되돌려준다면, 우리는 손으로 해결할 것이다.수천 명이 있다면, 그런 일을 하는 봇이 말이 될 것이다.샐릭스 알바(talk · concernes)의 직책으로는 소수일 가능성이 있어 보인다.르웨셀 (대화) 05:53, 2016년 6월 5일 (UTC)[응답]

• 그것은 다소 사소하다.2015년 12월 덤프(이미 컴퓨터에 저장해 둔 덤프, 사용 준비 완료)를 스캔하면 629페이지에 달하는\begin{array}4개의 템플리트, 1개의 도움말 페이지, 2개의 초안, 622개의 기사(그리고 위키백과 네임스페이스에 있는 몇 개의 문서, 모든 문서들은 신경 쓰지 않는 것이 좋을 것이다).그 7개 기사 중 오직 1개(또는 그 이상)의 기사가 있었다.\begin{array} [b](1),[c](3),[l](1),[t](2)가 있는 사람[l]위에서 이미 언급된 것.전체 목록:

-나블라 (대화) 13:57, 2016년 6월 5일 (UTC)[응답]

• 고마워 @나블라:내가 regenx bot을 만들지 않은 이유는 어떻게 해야 할지 몰라서 RFC가 누군가 regenx bot을 만들 수 있도록 내 요청을 백업해 주길 원하기 때문이다.내가 가서 네가 발견한 것들을 고쳐줄게.아마 그것들 뿐일 거야. 하지만 만약을 위해서 최신 검색을 하고 싶어.

• 나는 단지 한 가지 잘못된 공식이 있는지 확인하기 위해 봇을 운영하는 이유를 알지 못한다. 하지만 아마도 그렇지 않을 것이다.위키는 어쩔 수 없이 몇 개의 에로(erros)를 가질 것이고, 결국 누군가가 그것을 발견하고 고칠 것이다.오, 뭐 어쨌든, 나도 반대하지 않을게.위의 검색에서 한 가지 알 수 있는 것은 이러한 매개 변수를 사용하는 방법이나 사용하지 않는 방법을 설명하는 도움말 페이지가 단 한 장도 없었다는 것이다. 앞으로 이 매개 변수를 사용하는 편집자를 피하기 위해 내가 환영할 만한 개선책이 될 것이다. - 나블라 (대화) 21:05, 2016년 6월 5일 (UTC)[응답]

RfC: 관리자 도구 집합에서 '삭제' 사용자 권한 분리

유지 관리 태그 제거: 여러 가지 문제

유지관리 태그에 "이 템플릿 메시지 제거 방법 및 시기 학습" 링크를 포함하자는 최근 제안은 크게 호평을 받았다.단일 유지 관리 태그에 대해 구현되었으므로, 두 개 이상의 태그가 다음에 번들링될 때 유사한 것이 포함될 수 있다.{{Multiple issues}} 템플릿?예를 들어, 이 문서 상단에 있는 "방법 및 시기 학습" 상자를 비교해 보십시오." 링크, 여기에는 여전히 그러한 제안이 없는 다중 채널 박스가 있다. 노이스터(토크), 10:47, 2016년 6월 2일(UTC)[응답]

The{{Multiple issues}} 템플릿은 이미 이러한 항목을 제거하는 방법에 대한 링크, 여기서 누락된 항목이 무엇인지 확실하지 않은 경우.예를 들어 Lea_Salonga_discography에서는 (방법 참조) 라인의 지시에 연결된다.이 기능은 확장될 수 있으며, 일부 모의 실행이 있는 경우 템플릿 토크에서 편집 요청 또는 제안을 작성하십시오.여러 문제.— Xaosflux^Talk 17:53, 2016년 6월 2일 (UTC)[응답]

Done(완료됨) 이 업데이트 코드는 다음 시간에 활성화됨{{Multiple issues}} . — xaosflux^Talk 20:49, 2016년 6월 5일 (UTC)[응답]

그리고 노이스터의 퍼레이드에 빗발치기도 했는데, 그 기사를 편집해서.{{Multiple issues}} 이제 단 하나의 이슈만을 가질 수 있도록.노이스터가 지적한 개정안은 이렇다. --태기시몬(토크) 15:50, 2016년 6월 7일 (UTC)[응답하라]

RfC: 페르시아만과 아라비아만

마지막 문자 전치를 위해 리디렉션하시겠습니까?

여러분, 만약 누군가가 기사가 없는 일정 수의 글자에 대해 위키 검색에 들어간다면 좋은 생각이겠지만, 마지막 두 글자가 바뀐다면, 그것은 그 글자로 바뀐다.만약 그렇다면, 이것은 어떻게 이루어 질 것인가?치즈나칸 (토크)

• Google 또는 Bing 등의 'site: https://en.wikipedia.org' 접두사를 사용해 보십시오.컴퓨터 엔지니어로 말하면, 검색 문자열에서 최종 문자를 바꾸려면 매우 특별한 검색 소프트웨어가 필요할 것이다.애플리케이션 프로그램의 예상 데이터 형식에 맞게 사용자 지정해야 할 경우 웹 스크립팅(java, php 등)은 검색에 필요한 메모리 요구 사항으로 게임을 실행하기 위해 작업하는 가상 시스템의 로컬 램에 액세스할 수 없다.그래도 행운을 빌어!프랭크비 17:32, 2016년 6월 7일 (UTC)[응답]

시도해봐: "Abraham Linconl"을 검색해봐.아베 총리의 기사로 곧장 가지는 않지만 아브라함 링컨에 대한 결과물 제시라는 제목의 한 페이지를 제공한다.대신 아브라함 린콘을 찾아라."나는 그것이 올바른 접근법이라고 생각한다.춘투크 (대화) 13:08, 2016년 6월 9일 (UTC)[응답]

RfC: 외부 링크에 대해 선호하는 프로토콜

비경쟁 AfDs에 대한 제안

위키백과 강연에서 RFC를 시작했다.삭제조항#논란되지 않은 AfDs를 논란의 여지가 없는 삭제로 처리한다.고마워, SSTflyer 09:03, 2016년 6월 13일 (UTC)[응답]

토론 통지:인포박스 민간인 공격

템플릿 토크:유형 분야의 예로서 인포박스 민간 공격#바이오테러리즘
{{인포박스 민간공격}}유형분야의 예에서 바이오테러리즘을 제거하고 이를 매스슈팅으로 대체할 것을 제안한다.근거에 대한 제안서를 참조하십시오.-맨드러스 인터뷰 09:03, 2016년 6월 14일 (UTC)[응답]

사용자 토크 페이지에 대한 제안된 변경

아마도 토크 페이지에는 특정 사용자가 온라인 상태인지(특정적으로, 자신의 계정에 하나 이상의 위키백과 탭이 열려 있는지)를 나타내는 일종의 지시자가 있어야 할 것이다.그냥 제안일 뿐이다.98.195.88.33 (대화) 21:45, 2016년 6월 1일 (UTC)[응답]

이것이 기술적으로 타당하다고 가정하더라도, 그것은 심각한 사생활 문제를 야기할 것이다.뉴욕브래드 (대화) 21:48, 2016년 6월 1일 (UTC)[응답]

그것을 선택사항으로 만들면 개인 정보 보호 문제가 해결되지만, 웹 개발에 대한 많은 지식이 없다면, 페이지가 열릴 때 브라우저와 서버 간에 지속적인 통신이 이루어지지 않을 것으로 생각되므로, 서버는 사용자가 페이지를 보고 있는지 알 방법이 없을 것이다; 누군가가 웹 페이지를 요청하지 못하게 하는 것은 아무것도 없다.그리고 연결을 닫는다.나는 어디든 열려있는 모든 위키백과 탭의 지속적인 ping 또한 이상적이지 않을 것이라고 추측할 수 있다.KSFT^C 05:39, 2016년 6월 4일 (UTC)[응답]

많은 편집자들이 이미 이렇게 하고 있다.그것은 선택사항이며, 남아야 한다.--S 필브릭(Talk) 17:32, 2016년 6월 4일 (UTC)[응답하라]

나는 여기서 무엇을 의미하는지 잘 모르겠다. 확실히, 만약 한 사람이 위키피디아를 읽고 있다면, 한 명은 온라인에 있을 것이다.보르비 (토크) 23:42, 2016년 6월 9일 (UTC)[응답]

당신이 읽고 있는 토크 페이지의 사람이 온라인에 있는지 볼 수 있다고 나는 확신한다.– 피누서톱 (토크 ⋅ 기여) 23:56, 2016년 6월 9일 (UTC)[응답]

이를 위해 사용자:스탠드/사용자 정보는 꽤 괜찮다.편집자가 가장 최근에 편집한 시간을 보고 있는 사용자 페이지에 표시된다.누군가 10초 전, 아니 몇 분 전에 편집했다면 '온라인'일 가능성이 높다.– 피누서톱 (토크 ⋅ 기여) 23:56, 2016년 6월 9일 (UTC)[응답]

상대적으로 자원 조명 가능성은 로그인한 모든 사용자에게 사용자 인터페이스의 버튼을 제공하는 것으로, 이 버튼을 누를 때만 사용자가 사이트 전체 온라인 사용자 목록에 추가된다.이 목록은 API를 포함한 다양한 방법으로 접근할 수 있으며, 사용자는 마지막으로 열었던 위키백과 탭을 닫을 때 또는 그 다음에 읽을 버튼을 수동으로 클릭할 때 목록에서 즉시 삭제될 것이다.이러한 수동 방법은 지속적인 서버-클라이언트 통신이 필요 없으며 해킹이나 특별한 서버 측 구성(예: 서버 이벤트 및 기타를 차단하지 않는 Node.js)이 필요하지 않으며 완전히 선택된다.악마는 디테일에 있지만, 만약 그것을 원한다면, 그것은 특별한 조치 없이도 쉽게 실행될 수 있을 것이다.Fred Gandt · talk · contribs01:19, 2016년 6월 10일 (UTC)[응답하라]

나는 1단계는 필요성을 보여주는 것이라고 생각한다. 즉, 어떤 중요한 문제가 해결되었는가?OP는 그렇게 하지 않았고, 응답자 중 누구도 그렇게 하지 않았다.큰 필요없이 우리는 정당화될 수 없는 특색 크리프를 가지고 있다.-맨드러스 ☎ 01:31, 2016년 6월 10일 (UTC)[응답]

나는 이 제안이 소셜 네트워킹 사이트로 의도된 것이 아니기 때문에 찬성한다고 말할 수 없다.하지만 만약 그것이 활성화되었다면 나는 내 토크 페이지에 그것을 비활성화할 수 있는 수단을 선호한다.찬양(대화) 19:08, 2016년 6월 13일 (UTC)[응답]

만약 그것이 단지 편의의 도구라면, 나는 "마지막 기여 날짜/시간" 필드가 사용자의 토크 페이지에 추가되고 자동 업데이트되는 것에 동의할 수 있을 것이다.이용자의 기여 이력을 확인하는 것이 큰 부담은 아니지만, 이용자의 토크 페이지에서 대화를 시작한 것은 그들이 본질적으로 휴면 상태라는 것을 알기 위해서만은 나뿐만이 아닐 것이다.돈이야고 (대화) 19:40, 2016년 6월 13일 (UTC)[응답]

DonIago, User:스탠드/사용자 정보가 해당됨.나는 그것을 설치하는 것을 추천한다. 나는 그것이 매우 편리하다고 생각한다.

설치 방법을 알아내는 데 문제가 있으면 마지막 두 줄의 m:사용자:WhatamIdoing/global.js.Meta의 global.js 파일로 복사하여 자신의 계정(예: m:사용자:Doniago/global.js).WhatamIdoing (대화) 04:39, 2016년 6월 15일 (UTC)[응답]

음, 그건 꽤 이상해!고마워!돈이야고 (대화) 04:50, 2016년 6월 15일 (UTC)[응답]

NPP/AFC

위키마니아에서 일주일 남짓 있으면 새로운 페이지의 제어 시스템에 대한 위키백과 간 토론이 있을 것이라는 것을 상기시켜 주는 것이다.이것은 발표나 강의보다는 원탁이다.의제로는 새로운 기사에 대한 개혁과 새로운 사용자들이 우리의 콘텐츠 정책을 더 잘 이해할 수 있도록 돕는 방법들이 있다.이탈리아에 가셔서 참가하고 싶은 분은 회의 일정을 확인해주시고, 그곳에서 뵙기를 고대한다. --쿠드풍 pungุดผึง ( ((토크) 16:44, 2016년 6월 14일 (UTC)[응답]

이 세션은 페이지 작성 단계뿐만 아니라 모든 단계에서 편집 검토 도구, 특히 신실한 새 편집자에 대한 지원을 중심으로 구성된다.우리는 RC에서 허걸까지 모든 것에 대해 토론하기를 바란다.(전체 회의 일정은 wm2016:프로그램).도움과 관심에 감사한다.:) 퀴디티 (WMF) (토크) 21:07, 2016년 6월 15일 (UTC)[응답]

검색 결과 - 링크에서 텍스트 구분

용어를 검색할 때, 당신은 때때로 설명적으로 아직 연결되지 않은 용어를 찾기를 원한다.(예: *backage*이(가) 연결된 장소를 찾기 위해)

이미 링크된 것을 찾는 역방향 상황은 '여기서 어떤 링크(what links here)'에 의해 처리된다 — Fmadd(대화 • 기여) 03:29, 2016년 6월 13일(UTC)[응답]에 의해 서명되지 않은 코멘트 앞에 추가된다.

제안서를 올바르게 이해하면, 이것은 오늘날 이미 지원되고 있다: 검색어에 tilde( ~ )를 붙인다. 예를 들어, Special:검색/워싱턴은 워싱턴으로 연결되지만, 특별함:검색/~~워싱턴은 텍스트나 기사 이름에 단어가 포함된 기사를 표시해야 한다."intertle:"과 "intertle:"을 함께 사용하여 텍스트에 검색어가 포함된 기사를 볼 수 있지만 문서 이름에 일부 구문을 포함하지 않음("-"로 검색어를 미리 작성함)을 요청할 수도 있다. 특수:검색/워싱턴 -내부:워싱턴의검색에 대한 자세한 내용은 도움말:검색 중. 제안서를 제대로 이해하지 못한 경우, 최소한 한 명 이상 이해하지 못한 사람이 있다고 가정하고 제안서를 다시 작성하십시오.평화 - קיודנ ((kipod) (talk) 19:05, 2016년 6월 13일 (UTC)[응답]

그것을 알게 되어 반갑다.나는 검색 양식을 얻기 위해 null 필드를 사용하여 검색한 다음 용어를 입력해 왔다.고마워요.칭찬 (대화) 2016년 6월 16일 (UTC) 18:59 [응답]

페이지 보호 요청 시 BLP에 대한 별도의 섹션을 설정하는 RFC

• 얘들아.위에 RFC에 대한 메모를 여기에 남겨야겠다고 생각했을 뿐이다.논평에 관심이 있는 사람들은 여기에 반대, 지지 또는 논평을 남길 수 있다: 위키백과의 대화:페이지 보호 요청#별도의 BLP 보호 섹션 추가.Xender Lourdes (대화) 16:10, 2016년 6월 17일 (UTC)[응답]

최대 500,000페이지에 대한 인터넷 보관(WayBack) 링크를 업데이트하는 Bot

페이지에 인터넷 아카이브 링크를 대규모로 업데이트하기 위한 봇 요청이 위키백과에서 논의되고 있다.Bots/승인요청/GreenC bot 2질문, 의견 또는 우려 사항이 있는 경우 토론에 참여하십시오.BAG의 경우, — xaosflux 01:33, 2016년 6월 18일(UTC)[응답]

• 지지하다.여기서 수행되는 주요 작업은 https를 사용하도록 특정 웨이백 머신 링크의 포맷을 수정하고 WM의 URL의 전체 버전을 사용하는 것이다.이 논의에서 이러한 링크를 https로 전환하자는 데 폭넓은 공감대가 형성되었다.또한 약 5%의 편집이 작동하지 않는 아카이브 링크를 제거하거나 적절한 아카이브로 대체한다.그것은 분명히 유용하다.나머지 수정사항은 전체 수정사항 중 비교적 적은 비율에 영향을 미치지만, 모든 보관 링크를 올바르게 작동하도록 하기 위한 유용한 수정사항이다.~ 롭 01:46^Talk, 2016년 6월 18일 (UTC)[응답]

파일:Barbra Streisand - 1966.jpg... 준비됐나?

안녕, 난 노르웨이 위키피디아에서 왔어. 그리고 바브라 스트라이샌드 기사를 쓰고 있어.나는 바브라 스트라이샌드 - 1966.jpg 파일을 사용하고 싶지만, 현재 저작권 조사 기고자인 유저가 이 파일을 업로드했다.그런 만큼 철저한 조사가 이뤄질 때까지 파일을 하원으로 옮겨서는 안 된다고 말했다.그러나 아직 132장의 사진이 남아 있는 가운데 수사가 끝난 것으로 보인다.적절한 권한을 가진 사람이 스트레이샌드 파일을 확인해서 커먼스에 업로드해도 괜찮은지 확인해 줄 수 있어?토필름 (토크) 2016년 6월 19일 (UTC) 18:50 [응답]

CCI 조사는/이것이...약간 녹초가 된 것 같아.업로더 위키왓처1(이용자 라이트쇼로도 추정)은 홍보용 스틸에 대한 저작권이 없다고 주장했지만 위키미디어의 법률 자문은 거의 같은 결론에 이르렀지만, 미세한 인쇄물(이미지가 등록/재등록되지 않았음을 증명할 수 있다)에 대해서는 약간의 흥정이 있었고, 마음의 만남('공개'에서 거래하는 업로더)이 아니었다.wikimedia 변호사들이 "프로덕션 스틸"과 이야기를 나누고 있다.내 느낌은 가는 것이 정말 좋다는 것이다.그러나 ping @Munledgirl : 더 오피네이션 할 수 있을지도 모르는 사람. --Tagishsimon (대화) 19:06, 2016년 6월 19일 (UTC)[응답]

학술적 참조에서 외부 링크를 자유롭게 읽을 수 있도록 강조 표시

WP:OABOT 프로젝트는 인용 템플릿이 이용 가능할 때 참조 링크를 무료로 읽을 수 있도록 강화하는 것을 목표로 한다.우리는 많은 인용문 템플릿의 시각적 외관을 바꿀 계획이며, 그래서 우리는 먼저 여기서 의견을 구한다 - 우리는 당신의 의견이 필요하다!

구체적으로, 우리는 무료로 읽을 수 있는 자원으로 연결되는 것으로 알려진 링크의 스타일을 바꿀 계획이다.PDF 파일 링크가 끝에 작은 PDF 아이콘이 있듯이 링크를 페이월(paywall)이 없다는 것을 나타내는 작은 로고를 추가할 계획이다.예를 들어, 우리는 모든 링크가 arxiv=무료이므로 이 매개변수를 사용하는 모든 인용 템플릿은 다음과 같이 된다.

{{cite arXiv collaboration = LIGO Scientific Collaboration and Virgo Collaboration last1 = Abbotty first1 = Benjamin P. arxiv=1602.03840 제목=Binary 블랙홀 병합 GW150914 date=2016년 2월 11일}}}

애벗, 벤자민 P.; 외 (LIGO Scientific Collaboration and Virgo Collaboration) (2016년 2월 11일)"이진 블랙홀 병합 GW150914". arXiv:1602.03840

이 경우, 템플릿 인수를 변경하지 않고 자유롭게 읽을 수 있는 아이콘(모듈:인용문/CS1은 직접 수정될 것이며 이는 전 세계적으로 모든 인용문 템플릿에 영향을 미칠 것이다.우리는 다음과 같이 반드시 자유롭게 읽을 수 있는 다른 식별자에 대해 이러한 변경을 할 것이다. pmc=. 기술적으로, 이 아이콘은 CSS 코드를 사용하여 삽입될 것이다(현재 PDF 아이콘이 표시되는 방식과 동일).공간을 절약하기 위해 외부 링크 아이콘(->)을 교체할 수 있다.

우리는 또한 다음과 같이 항상 자유롭게 읽을 수 있는 것이 아닌 인수에 이 아이콘을 추가할 수 있기를 원한다. url=또는 doi=. 그렇게 하려면 예를 들어 링크를 추가함으로써 링크가 무료임을 표시하도록 템플릿을 변경해야 할 것이다. doi-free=true또는 doi-free=10.1016/S0168-0072(03)00052-6

{{Cite journal  doi = 10.1016/S0168-0072(03)00052-6  doi-free=true  issn = 0168-0072  volume = 124  issue = 1–3  pages = 71–106  last1 = Coquand  first1 = Thierry  last2 = Sambin  first2 = Giovanni  last3 = Smith  first3 = Jan  last4 = Valentini  first4 = Silvio  title = Inductively generated formal topologies  journal = Annals of Pure and Applied논리일 = 2003-12-15}

코칸드, 티에리, 삼빈, 지오반니, 스미스, 얀, 발렌티니, 실비오(2003-12-15)."인덕적으로 생성된 공식 토폴로지"순수 및 응용 논리 124 (1-3): 71-106. 도이:10.1016/S0168-0072-6. ISSN 0168-0072.

물론, 동일한 인용 템플릿의 여러 링크가 무료 읽기 아이콘과 함께 나타날 수 있다.- 핀토치 (대화) 15:16, 2016년 6월 19일 (UTC)[응답]

이 변경 사항은 Help_talk에서 논의하십시오.인용_Style_1#Adding_open_access_links_to_reference.이것은 수백만 페이지에 영향을 미칠 것이다. 우리는 명확한 합의가 필요하다!- 핀토치 (대화) 20:59, 2016년 6월 19일 (UTC)[응답]

내림차순 편집 카운트 시퀀스의 감시 목록 사용자 이름

기본 설정, 감시 목록 탭에서 "최근뿐만 아니라 모든 변경사항을 표시하도록 감시 목록 확장" 옵션은 사용자 이름을 오름차순 편집 순서로 표시한다.우리가 가장 높은 기여자에 관심이 있다고 가정할 때, 대신 내림차순 편집 수열로 정렬하는 것이 더 유용할 것이다.그러면 목록 끝까지 검색하는 데 시간을 낭비하지 않을 것이다.처음부터 시작하여 편집 카운트가 너무 작아서 계속할 수 없다고 간주될 때까지 스캔하십시오.할 만해?-맨드러스 인터뷰 02:16, 2016년 6월 20일 (UTC)[응답]

@Mandruss:나는 너의 제안을 잘 이해하지 못하겠다 - 특별:워치리스트는 시간순으로 정렬되어 있다. 더 많은 정보를 제공할 수 있는가?— Xaosflux^Talk 03:32, 2016년 6월 20일 (UTC)[응답]

@Xaosflux: 이 옵션을 활성화하면 각 페이지에 대한 기여자 목록(해당 날짜에 1을 초과할 때 카운트 편집 포함)도 제공된다.그 목록들이 내가 언급하고 있는 것이다.옵션을 활성화하고 살펴보십시오.-맨드러스 인터뷰 03:43, 2016년 6월 20일 (UTC)[응답]

그래, 이제 알겠어. 그런 행동을 하려면 '그룹 변경'과 '보여줄 감시 목록 확대'의 조합이 나와야 해. - 위에 스크린샷을 올렸어.— Xaosflux^Talk 03:57, 2016년 6월 20일 (UTC)[응답]

내 생각에 다음 질문은 이것이 어디에서 생성되는지 결정하는 것 같다. 코드를 통해 기후변화가 없는 사람은 누구인가?— Xaosflux^Talk 03:59, 2016년 6월 20일 (UTC)[응답]

그리고 목록은 사용자 이름 수와 창 너비에 따라 두 줄, 세 줄 또는 그 이상의 행으로 갈 수 있다.예측 가능하거나 일관된 위치에서 끝나지 않기 때문에 끝을 찾는 데는 비견할 수 없는 양의 스캔이 필요하다.한 번 일어난 일은 아무 것도 아니지만, 이런 내용이 합산된다. -맨드러스 인터뷰 04:58, 2016년 6월 20일 (UTC)[응답]

사용자들이 기여 #의 오름차순 또는 내림차순으로 나열되어 있다고 주장하는 이유는 확실하지 않다. 문서를 어디에선가 읽었는가, 아니면 관찰인가?만약 후자의 경우, 한 두 개의 샘플을 더 찾아야 할지도 모른다 - 이것은 단순히 사실이 아닌 것처럼 보인다.

나는 사용자들이 이 모드로 나열되는 순서를 잘 이해할 수 없다 - 그것은 완전히 임의적일 수 있지만, 나는 그것이 기여의 수와는 전혀 관계가 없다고 확신한다.나는 이 숫자를 쉽게 구할 수 있다고 생각하지 않으며, 이름들이 그것에 의해 분류될 수 있도록 그것을 얻는 것은 지나치다고 생각한다 - 그것은 상당한 비용이 들 것이고 아무런 이득도 없을 것이다.평화 - קיודנ ((일명 kipod) (토크) 05:22, 2016년 6월 20일 (UTC)[응답]

아마도 우리는 다른 것들을 보고 있는 것 같아.이 목록의 또 다른 실제 예는 다음과 같다. [Lowercase sigmabot III‎; Neutrality‎; 71.182.239.232‎; DHeyward‎; WWGB‎; Computationsaysno‎; Shearonink‎ (2×); Ad Orientem‎ (2×); Victorgrigas‎ (2×); Wnt‎ (2×); Penwhale‎ (3×); Felsic2‎ (3×); MrX‎ (4×); Pincrete‎ (5×); Ianmacm‎ (5×); Alanscottwalker‎ (6×); Mandruss‎ (15×); InedibleHulk‎ (15×)] 내 화면에 보이는 것처럼 그 번호는 분명히 쉽게 구할 수 있다.나는 그것이 오름차순 편집 수열이기 때문에 오름차순 편집 수열이라고 주장한다. (나는 이런 종류의 일을 꽤 잘한다.)혹시나 해서 내 전체 워치리스트를 다시 확인해 봤는데, 모든 리스트가 오름차순으로 나열돼 있어.나는 이미 상당한 비용이 지출되고 있다고 믿는다.고마워요.-맨드러스 인터뷰 05:31, 2016년 6월 20일 (UTC)[응답]

아마 편집 카운트가 아니라 계정 ID로 계정 연령을 표시하는 것일 겁니다. --Izno (대화) 11:07, 2016년 6월 20일 (UTC)[응답]

나는 명시된 대로 편집 카운트를 통해 오더가 상승하고 있음을 확인할 수 있다.사용자 환경설정을 직접 보려면 최근 변경사항 및 감시목록에서 페이지별로 그룹 변경 및 감시목록 확장, 최신 변경사항뿐만 아니라 모든 변경사항을 표시하기 위해 감시목록 확장 등을 선택해야 한다.HTML 페이지 소스에 마크업(JavaScript에서 실행되지 않음)이 포함되어 있기 때문에 확장 시 서버 측에서 처리가 이루어진다. Fred Gandt · talk · contribs13:13, 2016년 6월 20일 (UTC)[응답하라]

여기 언어 혼동이 있는 것 같아.wpo에서 "편집 카운트"는 일반적으로 사용자가 처음 등록한 이후 특정 wiki에 대해 수행한 총 편집 횟수를 측정한다.이 스레드에서 언급된 "편집 횟수"는 완전히 다른 것이다. 즉, 사용자가 특정 날짜에 특정 페이지에서 편집한 수입니다.이것은 이전의 혼란을 설명해준다.그렇긴 하지만, 제안은 말이 되지만, 나는 엔위키에서 다른 곳과 다르게 행동하는 것은 말이 안 된다고 생각해, 이런 것은 엔위키 제안 페이지보다 페이브릭커에서 더 적절하다고 생각해.평화 - קיודנ ((kipod) (talk) 17:42, 2016년 6월 20일 (UTC)[응답]

아, 그 설명이 도움이 되네!분류가 그렇게 중요한 건 아닌 것 같아.가장 최근에 페이지를 개인적으로 변경한 사람이 순서를 보고 싶은 것 같은데, 어느 쪽이든 별로 신경 안 써. --Izno (토크) 17:46, 2016년 6월 20일 (UTC)[응답]

여기서 먼저 공감대를 얻은 다음, 팸으로 가는 것이 내 경험이었다.-맨드러스 ☎ 21:08, 2016년 6월 20일 (UTC)[응답]

더 나은 검색, 더 나은 편집 및 작업 부하 감소

1. 코드 템플릿과 같은 더 나은 지침 페이지를 제공하고 찾기 쉽게 만드십시오.
2. 큰 그림을 한 눈에 볼 수 있도록 정확한 주제를 쉽게 찾을 수 있도록 더 나은 사이트 맵, 콘텐츠, 인덱스 등을 추가하십시오.(단 한 번에 장과 서브스크립션을 보여주는 책꽂이처럼).
3. 각 지침 페이지에서 더 많은 흐름도, 작은 애니메이션 지침, 간단한 요약 또는 개요를 사용하십시오.
4. 문제가 가장 많이 발생하는 것은 위키피디아의 특징을 알고 있고, 그것을 사용하고 싶을 때, 그러나 기능의 이름은 전혀 알지 못하거나("갤러리" 또는 "인포박스" 등), 또는 그 기능의 사용법을 알지 못할 때(테이블 또는 컬러 텍스트 등)이다.따라서 위키 페이지에 있는 물체의 "본질"을 검사하는 기능, 즉 "이는 모자 노트", "이는 인포박스", "이는 단락" 등이 있을 수 있으며, 이러한 항목을 만들기 위해 관련 위키 텍스트 코드, 시각 편집 옵션 등을 사용하는 방법을 보여주는 기능이 있을 수 있다.또한 wiki의 기능 목록에 액세스할 수 있는 왼쪽 작업 표시줄의 링크를 제공하십시오.
5. 사용자가 잘못된/관련되지 않은 도움말 페이지 또는 포럼에 대한 질문/문제/제안을 (허용 한도까지) 보관하는 경우, 해당 대화는 버튼 하나로 오른쪽 헬프데스크/포탈/카테고리까지 이동/복사될 수 있다.

리트 라자르시 (토크) 12:28, 2016년 6월 21일 (UTC)[응답]

원칙적으로 동의한다.그러나 편집자가 꼭 알아야 할 것은 단 한 가지, 즉 WP:HD. -Mandruss 인터뷰 14:19, 2016년 6월 21일 (UTC)[응답]

나는 가독성을 높이기 위해 당신의 원래 게시물에서 볼드체를 자유롭게 제거했다. (Per WP:TPO:다른 사람의 의견을 적절하게 편집하는 몇 가지 예:재료를 읽기 어렵게 만드는 형식 오류 수정)얼마든지 되돌아가십시오.엔터프라이즈y (토크!) 2016년 6월 21일 (UTC) 17:38[응답]

광고 차단 소프트웨어를 검색하는 사이트에 대한 인용문 공개

다양한 이유(주로 보안 및 웹 브라우저 성능 유지)로 인해 광고 차단 소프트웨어의 사용이 증가하고 있으며, 이를 고용하는 사용자에 대한 대응 조치의 사용이 유사하게 증가하고 있기 때문에, 특정 출처가 광고블로를 스캔하기 위한 기술적 조치를 채택한다면, 인용문은 사용자에게 알릴 수 있는 통지가 있어야 한다고 생각한다.cking 소프트웨어, 메시지 생성 또는 광고 차단기가 탐지될 경우 콘텐츠에 대한 액세스를 완전히 제한한다.우리는 이미 페이월(paywall)을 고용하거나 등록을 필요로 하는 사이트에 대해 유사한 일을 하고 있다(예: {{가입 필요); 콘텐츠에 접근하기 위해 광고를 시청해야 하는 명시적 요건은 그 중요성 때문에 유사한 방식으로 공개되어야 한다.

나는 우리가 이것을 어떻게 말할지 모르지만, 그것은 서브스크립션 요구 공지와 유사하게 제시될 것이고, 웹 페이지가 광고 차단 소프트웨어를 탐지하려고 할 때에만 콘텐츠에 대한 접근을 제한하거나 공지사항을 제시하는 인용구에 사용될 것이다.광고 차단은 일반적으로 개인 정보 보호 조치로 사용되며, 이러한 스캔들은 광고 차단의 행동을 읽음으로써 광고 차단을 감지하기 위한 스크립트의 실행을 야기한다.ViperSnake151 Talk 19:40, 2016년 6월 7일 (UTC)[응답]

포브스라고 생각하나? --Izno (대화) 19:59, 2016년 6월 7일 (UTC)[응답하라]

• 반대: 편집자들은 그들이 좋아하는 인터넷 광고에 관한 어떤 원칙도 자유롭게 가질 수 있지만, 광고(또는 광고 차단 탐지기) 때문에 어떤 것을 검증하기를 꺼리는 것은 출처의 검증가능성에 전혀 영향을 미치지 않는다.광고 차단에 대한 그들의 의견이 무엇이든, 우리는 위키피디아 정책을 요점을 만들기 위해 바꾸지 않기로 합의했다.{{구독 필요}}}}을(를) 보유하고 있는 이유는 비용이나 등록이 검증가능성에 실제적인 장애가 될 수 있기 때문이다(그러나 WP:PayWall 노트는 검증이 실패하는 것을 수반하지 않는다.반면에 웹사이트에 광고(또는 광고 차단 탐지)가 존재하더라도 출처의 검증가능성에 부정적인 영향을 미치지 않는다.보안 문제는 WP에서 이미 다루고 있다.ELNO; 그리고 애드-차단기 검출기는 아마도 "악의적인 스크립트"에 해당하지 않을 것이다.(물론 이미 알고 있는) 독자 자신의 원칙 외에는 독자들이 '경계'될 필요가 없다.– Finusertop (토크 ⋅ 기여) 20:08, 2016년 6월 7일 (UTC)[응답]

Well, wait User:Finusertop -- 나는 이러한 출처가 인용문으로 사용될 수 있다는 것에 동의하지만, 만약 사이트가 사용자의 이익에 반하는 행동을 한다면, 적어도 우리의 독자들에게 경고하지 않는 것은 꽤 불친절하지 않은가?사고 실험으로, 어떤 사실을 신뢰성 있게 검증하는 사이트가 있지만, 그 사이트로 가면 러시아 마피아에 모든 사용자의 파일을 복사한 다음 하드 드라이브를 포맷하는 맬웨어가 예기치 않게 설치된다고 가정해 보십시오.우리는 사람들에게 경고하지 않고서는 말할 것도 없고, 그 사이트를 전혀 참고 자료로 사용하지 않을 것이다, 그렇지 않은가?그렇지 않다면 그것이 그 사실에 대한 믿을 수 있는 증거였다고 가정하고, 그것이 중요한 사실이고 그것이 유일한 신뢰할 수 있는 검증이었다고 가정하더라도, 우리는 여전히 그렇게 하지 않을 것이다.그렇지? 그러길 바래.애드웨어 차단 사이트들이 '러시아 마피아, 그렇다면 포맷 <--> 문제없음'이라는 연속물에 어디에 맞는지 모르지만, 편집자가 "애드차킹은 전형적으로 사생활 보호 대책으로 사용된다"고 했으니, 우리-걱정하지 말자-이-전혀 이런-전혀 안 되는 표에 서명하기 전에 우리가 얼마나 많은 사생활 손실을 이야기하고 있는지 좀 더 듣고 싶다.헤로스트라투스 (대화) 2016년 6월 9일 00:19 (UTC)[응답]

나는 우리가 위키피디아가 현재 (내일 그것들을 사용하는 숫자와는 다를지도 모르는) 악성코드에 대한 러시아 마피오시에 대한 어떤 터무니없는 빨치산들에 근거하여, 위키피디아가 하는 모든 참고자료들을 광고 차단기를 사용하는 사이트에 게시하는 엄청난 노력을 기울여야 한다고 생각하지 않는다.웹 사이트가 독자가 좋아하지 않을 수 있는 행동의 개수는 얼마든지 있다.위키피디아가 그것을 감시할 것이라고 기대할 수는 없다.우리가 할 수 있는 모든 것은 "이 사이트가 이 문구를 검증한다"고 말하는 것이다. (수백만 개의 링크에 대해 최신 정보를 유지하는 것은 할 수 있는 일보다 더 많은 작업이다.)춘투크(토크) 13:01, 2016년 6월 9일 (UTC)[응답]

헤로스트라투스의 주장에 대해, 애드블록 플러스 페이지에서는 [8]의 말처럼, "애드들이 우리가 온라인에서 무료로 즐기는 콘텐츠의 많은 부분을 연료로 공급한다"고 말했다.구글, 유튜브, 페이스북과 같은 광고 지원 웹사이트들이 광고 수익 감소로 인해 상당수의 웹사이트가 폐쇄된다면, 그것은 "사용자의 이익에 반대"하는 것이라고 주장할 수 있다.나는 개인적으로 애드블록플러스의 "수용 가능한 광고로 취급되어야 할 광고의 일반 기준"[9]을 모든 광고를 차단하고 광고를 차단하지 않는 것 사이의 허용 가능한 타협으로 매우 좋아한다. --Guy Macon (토크) 00:39, 2016년 6월 10일 (UTC)[응답]

• 반대한다. 만약 웹사이트가 구독 통지에 대한 생각을 바꾸고 우리는 여기서 무슨 일이 일어나든 특정 인용문에 대한 모든 참조를 수정해야 한다면 이것은 시간낭비가 될 것이다.그리고 왜 광고 차단 소프트웨어를 검색하는 사이트들은?개인 정보 보호 정책이 미흡한 웹 페이지를 식별해야 하는가?팝업 광고가 있는 웹 페이지?과도한 스크립팅 또는 타사 스크립팅이 있는 웹 페이지?이것이 그렇게 불쾌한 경우, 특정 웹 사이트 링크에 대한 해결책을 제안하거나 특정 페이지에 대한 웹 링크 제거를 제안하십시오.아니면 그렇게 하고 싶으면 사이트 자체를 블랙리스트에 올리거나. -- 리키81682 (대화) 09:07, 2016년 6월 9일 (UTC)[응답하라]
• 반대: 첫째, 질문한 질문이 편파적이다."Ad-blocking은 일반적으로 개인 정보 보호 조치로 사용된다"는 것은 사실상 거의 확실하지 않다.가장 일반적인 이유는 사용자의 불편함을 줄이기 위함입니다.광고 차단 프로그램 Adblock Plus[10]의 웹 사이트 비교("성가시적인 광고 없이 웹 서핑! ...눈에 띄지 않는 광고는 차단되지 않는다.""개인 정보 오소리[11]"개인 정보 오소리는 광고주와 다른 제3자 추적자들이 당신이 어디로 가고 어떤 페이지를 웹에서 보는지를 몰래 추적하는 것을 막는 브라우저 추가 기능이다.) 애드블록 플러스는 짜증나는 광고를 차단하고 눈에 띄지 않는 광고를 통과시키려 하고, 개인 정보 오소리는 당신을 추적하는 광고를 차단하려고 노력한다.es 통과하지 못하는 것.웹에는 애드블록 플러스를 물리치기 위해 대항책을 사용하는 사이트들이 가득하지만, 나는 프라이버시 오소리를 물리치려는 어떤 사이트도 들어본 적이 없다.둘째, 광고 차단제는 사생활을 보호하는 끔찍한 방법이다.그들은 또 다른 문제를 전적으로 다루고 있으며 사생활 보호 혜택은 우발적인 부작용이다.셋째, 광고로 뒷받침되는 광고 차단 사이트와 사이트 간의 현재 진행 중인 군비 경쟁에 대해 위키피디아가 어떤 입장을 취할 자리는 아니다.광고는 페이월(paywall)과 달리 검증에 지장을 주지 않는다. --Guy Macon(talk) 14:05, 2016년 6월 9일(UTC)[응답]
  • @Guy Macon:누군가가 Adblock Plus나 Privacy Badger를 사용하든 상관없다. 만약 그들의 광고가 추적자로 차단된다면, 그 웹사이트는 여전히 당신이 Privacy Badger를 사용하는 것을 차단할 수 있다. 이것은 큰 광고 네트워크에서는 꽤 흔한 일이다.개인적으로 나는 광고와 추적기를 차단하기 위해 필터 리스트와 함께 uBlock Origin을 사용한다.어쨌든, 나는 이 생각이 실현 가능하지 않다는 것에 동의한다.다른 대안은 WebCite와 같은 사전 보존 아카이브를 추가하는 것일 수 있다.와의 가장 두드러진 연결고리는 아닐 것이다. deadurl=no그리고 그것은 어쨌든 보존에 유용할 것이다.nyuszika7h (대화) 10:27, 2016년 6월 11일 (UTC)[응답하라]
  • 나는 페이월, 광고 차단 스캔, 국가 기반의 제한 또는 그와 같은 것들이 검증가능성을 방해한다고 생각하지 않는다.귀하는 개인적으로 출처를 확인할 수 없거나, 지불할 수 없거나, 웹사이트가 선호하는 소프트웨어 설정을 사용하지 않거나, 웹사이트가 승인하는 국가에서 인터넷에 접속할 수 없거나, 그렇지 않은 경우, 출처를 확인할 수 없지만, 검증가능성은 귀하에게 개인적으로 가능한 것이 아니다.그것은 모든 독자들에게 가능한 것이 아니라 누군가(원래 그 자료를 추가하는 사람이 아닌 누군가)에게 가능한 것에 관한 것이다.WhatamIdoing (대화) 04:48, 2016년 6월 15일 (UTC)[응답]
• 반대하다. 이상적인 세계에서는, 그것이 효과가 있을지 모르지만, 자동적으로 그것을 추가하고 그것을 제거하는 일종의 목록이 없다면, 그것과 함께 모든 것을 태그하는 것은 너무 오래 걸릴 것이다.또한, 만약 이것이 시행된다면, 다른 것들의 선은 어디에 그려질 것인가?리키81682의 말처럼 팝업 광고 등에 대해서도 공지할 것인가.무정부상태 (워크톡) 07:24, 2016년 6월 11일 (UTC)[응답]
• 이의는 없지만 나는 이것이 중요한 템플릿이라고 생각하지 않지만, 누군가가 그것이 적절하다고 믿을 때 그것을 가지고 그것을 사용하는 것은 문제가 되지 않는다.{{구독이 필요한}}}}}은 그다지 자주 사용하지 않으며, 이것은 인기가 적겠지만 해롭지 않다.WhatamIdoing (대화) 04:48, 2016년 6월 15일 (UTC)[응답]
• 반대한다, 이것들은 별로 없어 보인다.어차피 Noscript나 Greasemonkey/Tampermonkey 스크립트로도 꽤 쉽게 우회할 수 있고, 그러한 스크립트는 쉽게 구할 수 있다.세라핌블레이드 17:47, 2016년 6월 22일 (UTC)[응답]

두 개의 새 유지 관리 태그

나는 유지 관리 태그가 있어야 한다고 생각했다 - 이 기사는 죽은 링크(또는 존재하지 않는 페이지에 대한 링크)를 포함하고 있으며, 이 기사는 영어가 아닌 언어로 된 외부 참조를 가지고 있다 --Varun FEW2003 14:25, 2016년 6월 21일 (UTC)[응답]

이것은 위키백과에도 게시되어 있다.마을 펌프(아이디어 랩)#A suggesion. -- GB팬 14:28, 2016년 6월 21일 (UTC)[응답]

이것은 여기 있을 만큼 충분히 구체적이고, 많은 사람들이 여기에 머무르고 있다.WP에 따라 아이디어 랩 버전을 삭제한다.Multi. -Mandruss 인터뷰 14:35, 2016년 6월 21일 (UTC)[응답]

@Varun DEF2003: WP에 따라 이 제안서의 아이디어 실험실 사본을 삭제했다.Multi, 그리고 내가 여기서 너의 헤딩을 바꿨어.-맨드러스 인터뷰 14:50, 2016년 6월 21일 (UTC)[응답]

@Varun DEF2003: 우리는 "이 글에는 죽은 링크가 포함되어 있다"는 템플릿이 없는데, 그것은 아마도 모호하기 때문일 것이다(사람들이 어떤 것이 좋은 링크인지, 어떤 것이 죽은 것인지 어떻게 알 수 있을까).우리가 가지고 있는 것은{{dead link}}작동되지 않는 특정 링크에 적용되어야 한다.그러나 이러한 링크가 참조로 사용되지 않고 "외부 링크" 섹션의 항목일 뿐이며 작업 링크로 업데이트하는 방법이 없는 경우, 일반적인 관행은 해당 링크를 제거하는 것이다. WP:엘데드

영어 이외의 외부 링크에 대해서는 - 다시 말하지만, 각 외부 링크는 별도로 고려해야 하므로 기사 전체의 템플릿은 적절하지 않다.영어 이외의 모든 외부 링크가 문제가 되는 것은 아니다. WP:NONENGEL; 각각의 영어 이외의 외부 링크를 차례로 고려하여 유용성 여부를 결정한다.그렇지 않으면 제거하십시오. 유용할 경우 다음과 같은 적절한 언어 마커를 추가하십시오.{{es icon}}스페인어 외부 링크가 필요함. --Redros64 (대화) 22:14, 2016년 6월 21일 (UTC)[응답]

이것들은 인라인 태그를 사용하여 가장 잘 다루는 사소한 문제처럼 보인다.위쪽에 유지 관리 태그가 어지럽게 흩어져 있는 페이지는 이미 충분하다.칭찬 (대화) 2016년 6월 23일 (UTC) 18:53 [응답]

나는 상기에 동의하는 경향이 있다.이 태그들은 특히 특정 문제를 언급하는 일반적인 태그로 나타날 때 어떤 문제를 해결하기 위한 것인가?돈이야고 (대화) 2016년 6월 23일 (UTC) 19:37 [응답]

@도니아고:Varun DEF2003(토크 · 기여)은 원래 게시물 당시의 라말 탈카-콘티누시온에 대해 작업을 해오고 있다. --Redros64 (토크) 19:48, 2016년 6월 23일 (UTC)[응답]

빠른 웹 인용 태그

현재 웹에서 인용할 때 나는 타이핑을 한다.

<ref>{{ref 웹타이틀=blah blah blah blah blah blah blah url=laim:/fair/bar/bar/blah_blah}}}</ref>

게으른 지름길 인용 태그가 이것을 다음과 같은 것으로 간소화하기 위해 고안될 수 있을까?

{{quickcite http:/somewhere/foo/bar/blah_blah_blah}}

- 'ref' 태그를 추가하고 링크에서 제목을 추출한다.이것은 사소한 것처럼 보일 수도 있지만, 그것은 편집자들이 기사에 계속 집중할 수 있게 하고, 실제로 링크를 추가하는 데 드는 노고를 줄일 수 있게 할 것이다.때때로 제목이 모호한 파일 이름이 될 수도 있지만, 게으른 사람들이 실제로 더 많은 링크를 얻을 수 있다는 점을 고려하면, 나는 그것이 덜 나쁜 악일 것이라고 나는 생각한다.(지진은 정말로 다른 것에 초점을 맞추고 에너지를 절약하는 것이다) — Fmadd가 추가한 서명되지 않은 이전의 논평 (대화 • 기여) 20:57, 2016년 6월 17일

당신은 최근 며칠 동안 많은 새로운 기능들을 요구하는 것 같고, 거의 당신의 게시물에 서명을 하지 않는 것 같다; 또한, 당신이 요구하는 것을 해결하는 것이 항상 쉬운 것은 아니다.그러나 위키백과 템플리트는 제목이 링크의 일부가 아니기 때문에 "링크에서 제목을 추출"할 수 없다.또,<ref>...</ref>태그와 템플릿은 여분의 공간을 가득 채워 펌핑하면 예상대로 작동하지 않는다. --Redrose64 (토크) 22:19, 2016년 6월 17일 (UTC)[응답]

내가 제안하는 것은 최악의 경우에는 파일 이름만 사용한다는 것이다. (때로는 제목과 관련이 있다.)나는 또한 웹페이지에서 제목을 얻는 데 흔히 유용한 기능을 상상할 수 있다.컴퓨터는 반복적인 작업으로부터 우리를 구하고, I를 점 찍고, T를 가로지르기 위해 여기 있다.Fmadd (대화) 23:03, 2016년 6월 17일 (UTC)[응답]

Fmadd, 당신이 원하는 것은 mw:citoid 서비스로 이용할 수 있다.시각적 편집기로 전환하여 사용해 보십시오. 기사를 열고 오른쪽 상단 모서리에 있는 연필 아이콘을 찾아 클릭한 다음 최신 워드프로세서처럼 보이는 것으로 변환될 때까지 잠시 기다리십시오.도구 모음 가운데에 있는 "Cite" 버튼에는 일부 인기 소스(예: PubMed, The New York Times, Google Books)에 뛰어난 인용구를 제공하는 "Automatic" 설정이 있으며, 거의 모든 (PDF 이외의) URL에 대한 제목을 추출한다.

"Save" 옆에 있는 [[ ] 버튼을 누르면 위키텍스트 편집기로 돌아가게 된다.Whatamidoing (WMF) (토크) 22:59, 2016년 6월 17일 (UTC)[응답]

고마워, 먹어볼게. 난 보통 낮은 레벨의 편집기를 사용하지만, 한번 볼게.Fmadd (대화) 23:04, 2016년 6월 17일 (UTC)[응답]

제안사항을 반추해 봅시다 - 나는 VE 편집기를 참고용으로 사용하고, 그것은 방금 당신이 요청한 것 이상의 것을 하고, 당신의 제안보다 훨씬 더 쉽게 한다. -S Philbrick (Talk) 02:58, 2016년 6월 18일 (UTC)[응답]

• 사용자:Ark25/RefScript.Fmadd, 나는 Arc25의 기준 발전기를 사용한다.나는 VE로 바꿀 필요가 없다.그리고 버튼 클릭으로 {{cite}} 참조를 생성하여 거의 모든 링크에서 제목을 추출해 문제없이 많은 파라미터를 채운다.긍정: 시간을 많이 절약한다.부정적인 내용: 당신은 자료를 두 번 확인해야 하며, 때때로 뉴스 링크에 적절한 메타 데이터가 없는 경우 매개변수 중 일부는 채워지지 않은 채로 남아있다.또한, 만약 당신이 책이나 웹 뉴스가 아닌 것을 언급하고 있다면, 참조 생성기는 인용 책자나 관련 인용 템플릿 대신에 인용 웹을 생성할 것이다.수동으로 변경해야 하지만 그래도 시간이 많이 절약된다.한 번 시험해 보고 어떻게 찾았는지 말해 봐.나한텐 정말 대단해.루르데스 00:57, 2016년 6월 24일 (UTC)[응답]

모바일 기본 페이지 변경 사항

추가 옵션도 있지만, 화면 크기가 다양하니 참고해줘.우리 집에서는 갤럭시 에이스 2의 4인치부터 아이폰 6+의 6인치까지, 갤럭시 탭의 10인치, 13인치 크롬북의 현재 2 x 21인치 듀얼 모니터 설정까지 다양하다.한 가지 사이즈가 모두 맞는 것은 아니다.어쨌든 나의 요점은 바로 오늘 모바일의 시각이 바뀌었다는 것을 알아차렸다는 것이다.출퇴근할 때 아이폰6+로 보는 게 익숙해.보통 메인 페이지는 ITN 섹션과 함께 추천 기사를 보여주고 그 아래를 따른다.다른 섹션은 표시되지 않는다.그러나 오늘 처음으로 모바일 뷰(https://en.m.wikipedia.org)에는 표준 메인 화면의 압축된 버전에 모든 섹션이 표시된다.이것은 여러 개의 열을 표시할 공간이 부족하기 때문에 잘 작동하지 않는다.누가 이것을 통제하고 그들은 어디에서 어울릴까?피드백을 드리고 싶은데...앤드류 D. (토크) 2016년 6월 24일 (UTC) 13:05[응답]

이것은 phab과 관련이 있는 것으로 보인다.T32405. 굼벵이?!" 13:32, 2016년 6월 24일 (UTC)[응답하라]

알고 보니 이건 벌레였습니다(사진:T138578) 그리고 이제 고쳤다.ub "?!" 13:23, 2016년 6월 25일 (UTC)[응답]

위키백과 언어: 바스크어 위키백과는 250,000개의 기사를 가지고 있다.

인터랙티브 체스 보드

#2: 파일: 바브라 스트라이샌드 - 1966.jpg ... 가볼 만해?

(노력 #1) 누구라도 나를 더 도와줄 수 있을까?토필름 (토크) 2016년 6월 28일 (UTC) 17:32 [응답]

제2차 세계 대전 순교자 108명을 위한 새로운 카테고리 및 기사 제안, 폴란드어를 아는 분이라면 누구나 나와주십시오.

안녕하십니까, 여러분.폴란드어 위키백과에 Kategoria:108 bwogoswawionych polskich męczennikwe zokresu II wojny światowej라는 카테고리가 있다.그것은 2차 세계대전의 폴란드 108 순교자들에 관한 것이다.그것은 다른 위키에는 없지만 매우 중요한 것으로 보인다.나는 그것들에 대한 기사를 몇 개 만들었지만 폴란드어를 읽지 않기 때문에 기본적인 정보만 만들 수 있다.순교자들은 모두 폴란드 위키에 기사가 실려 있다.만약 폴란드어를 읽는 사람이 있다면, 영어 기사가 없는 사람들을 위한 영어 기사를 만드는 것을 도와줘.감사합니다.지이 머니(토크) 08:35, 2016년 6월 30일 (UTC)[응답]

"페이지 저장" 단추 변경 가능

WMF가 "저장" 버튼에 대해 변경하고 있는 변경 사항과 이를 enwiki에 표시하는 방법 또는 방법에 대해서는 위의 VPT 링크를 참조하십시오.감사합니다, — xaosflux 20:03, 2016년 7월 2일 (UTC)[응답]

RfC: 긴 URL 또는 짧은 URL

archive.is과 webcitation.org에 연결할 때 긴 URL 또는 짧은 URL을 사용해야 하는 경우 RfC가 열려 있음 -- GreenC 23:23, 2016년 7월 5일(UTC)[응답]