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

RfC: 포털 시스템을 종료하는 데 2가 소요됨

새 파일 이름 지정 기준 제안: 확장명 일치

해제 네임스페이스

해시 페이지는 백과사전적인 것으로 간주되지 않는데, 왜 주요 공간에 있는가?기사 개수(현재 588만7,631개)가 실제 백과사전의 기사들을 더 대표할 수 있도록 Dissambigation 네임스페이스를 갖는 것이 이전에 논의된 적이 있는가?바나나 공화국 (토크) 02:14, 2019년 7월 15일 (UTC)[응답]

• @Banana Republic:이 주제는 다른 대화의 맥락에서 몇 번 나타났지만, 내가 (빠르게) 찾을 수 있는 유일한 대화인데, 그것은 그것에만 전념하는 것이다—위키피디아:Billage_pump_(기술)/Archive_33#Disambigation:_namespace.이 대화는 그 생각에 부정적이고 약간의 논쟁을 제시한다.개인적으로, 나는 장기적으로 DAB 페이지가 제거되고 dab 데이터에 의존하는 검색 팩스로 대체되는 Wikidata 기능으로 해체될 수 있다고 생각하지만, 내가 아는 한 그것은 현재 논의되고 있는 것에 가까운 것이 아니다. --사용자:세요키(말씀) 02:30, 2019년 7월 15일 (UTC)[응답]

그것은 다소 짧은 토론이었고, 기본적인 오류를 담고 있었던 것으로 보인다.한 사용자는 "해제 페이지는 여전히 기사"라고 썼다.아마도 그들은 토론이 있었던 2008년에 기사로 간주되었지만, 위키피디아에서는 오늘날 기사로 간주되지 않는다."해산 페이지는 기사가 아니므로 고아로 태그해서는 안 된다"는 내용의 디스컴비게이션.따라서 그것들이 기사로 간주되지 않는다면 기사 네임스페이스에 있어서는 안 될 것으로 보인다.바나나 공화국 (토크) 02:43, 2019년 7월 15일 (UTC)[응답]

메인 스페이스에는 기사가 아닌 것이 많다.리디렉션, (일부) 목록 등킬리움두드 (대화) 02:48, 2019년 7월 15일 (UTC)[응답]

이 링크에 따라 리디렉션은 아티클 카운트에 포함되지 않는다.

위키백과별:스타일/목록 매뉴얼, 목록은 목록 기사로 간주된다.

즉, 불분명한 페이지를 자신의 네임스페이스에 넣게 되면, 기사 개수는 기사 수 플러스 1(본 페이지, 기사로 간주되지 않음)을 반영하게 된다.바나나 공화국 (대화) 02:59, 2019년 7월 15일 (UTC)[응답]

나는 일부 목록은 링크에 불과하다는 점에서 모호한 페이지와 유사하다고 지적하고 있었다.킬리움두드 (대화) 03:02, 2019년 7월 15일 (UTC)[응답]

리스트는 설명 페이지와 다르며, 다른 목적을 제공한다.바나나 공화국 (대화) 03:04, 2019년 7월 15일 (UTC)[응답]

템플릿에 따라:위키백과에는 약 190,000페이지의 설명서가 있다.이는 기사로 집계되는 589만 페이지의 약 3%에 해당한다.그 19만 개에 달하는 기사들을 기사집계에서 빼내고, 더 의미 있는 기사집계를 하는 것이 좋을 것 같다.바나나 공화국 (대화) 03:16, 2019년 7월 15일 (UTC)[응답]

그럼 그 연결고리가 어디로 갈까?그 타이틀들에는 무엇이 있을까?만약 편집자가 Seal, Pop 또는 Frank Smith에 링크를 만들거나, 독자가 그 용어를 검색한다면, 그 링크는 이 새로운 공간으로의 리디렉션을 가리킬 것인가?그 어떤 용어의 1차 주제라고 원격으로 생각할 수 있는 기사는 없다. bd2412T 03:54, 2019년 7월 15일 (UTC)[응답]

WP:INTDABLINK에 따르면, "주공간의 모호한 페이지로 연결되는 링크는 전형적으로 오류"이다.그러므로 내가 생각할 수 없는 몇 가지 예외를 제외하고는 메인 스페이스 기사 내에서 페이지 해체를 위한 어떤 링크도 있어서는 안 된다.바나나 공화국 (대화) 04:07, 2019년 7월 15일 (UTC)[응답]

나는 <코드>를 포함한 페이지들이__라고 꽤 확신한다.DISAMBIG__</code>는 기사합계에는 포함되지 않는다. --Izno (토크) 04:26, 2019년 7월 15일 (UTC)[응답]

아니, 내가 틀렸어.흥미롭군아마도 그건 데브에 대한 요청이 있어야 할 것이다. --Izno (대화) 04:27, 2019년 7월 15일 (UTC)[응답]

나는 개발자들이 그러한 변화를 실행하기 전에 합의를 보기를 원할 것이라고 생각한다.바나나 공화국 (대화) 05:38, 2019년 7월 15일 (UTC)[응답]

페이지가 불분명한 페이지인지 아닌지가 바뀌면서(우리가 무엇이 주요 주제인지 아닌지를 결정할 때), 여분의 네임스페이스의 첨예한 구분이 내게는 좋은 생각처럼 보이지 않는다.Mercury를 Dissambigation으로 리디렉션하는 경우:수성 또한 개선된 것처럼 보이지 않는다.제안된 변경안의 주요 장점은 그것이 우리의 기사 집계를 더 쉽게 만들 수 있다는 것 같지만, 그렇지 않으면 너무 길기 때문에 하위 기술자와 리스트가 여러 기사로 나뉘는 것은 어찌됐든 절망적이다.우리가 "정확한 숫자"를 3% 과대평가하든, 5% 과소평가하든, 10% 과소평가하든 (혹은 정말 별개의 주제를 다루고 있는 병합 때문에 과소평가하든) "기사 수"가 실제로 "위키피디아는 정말 크고, 여전히 성장하고 있다" 이외의 의미를 갖는다고 가장하지 않는 한, 관련성이 없다.그리고 우리는 그 이상의 의미를 갖는 척해서는 안 된다.—쿠스마 (t·c) 09:01, 2019년 7월 15일 (UTC)[응답]

그런 움직임은 백과사전의 개를 흔드는 기사 카운트 꼬리가 될 것이다.우리는 주로 백과사전을 짓기 위해서지 기사 수 같은 것에 대해 걱정하지 않기 위해서 이곳에 왔기 때문에, 어떤 결정이든 더 나은 백과사전을 만드는 것에 기초하여 이루어져야 한다.사람들은 백과사전이 수를 세기 위해 흐트러지지 않고 원하는 방식으로 자유롭게 기사를 셀 수 있다.필 브리저 (대화) 09:21, 2019년 7월 15일 (UTC)[응답]

기사 수는 한 가지 문제일 뿐이다.더 큰 이슈는 '해독 페이지는 기사가 아니다'는 WP:해독의 요점을 부각시키는 것이다.그들의 네임스페이스에 그들을 넣는 것만큼 그 점을 분명히 하는 것은 없다.바나나 공화국 (대화) 12시 43분, 2019년 7월 15일 (UTC)[응답]

그래서 당신은 이 점에 대한 혼란이 작은 문제를 야기시켰다는 어떤 증거도 제시하지 않고 특정 페이지를 고아로 분류해야 하는지에 대한 즉흥적인 발언으로 만들어진 포인트를 운전하는데 수백 시간의 편집자와 개발자 시간을 쓸 것을 제안하는가?나는 여기서 더 이상 논평하지 않을 것이다. 왜냐하면 나는 무의미한 제안들에 대해 논의하는 것보다 내 시간을 가지고 있는 것이 더 좋기 때문이다.필 브리저 (대화) 14:03, 2019년 7월 15일 (UTC)[응답]

그렇다, 그 전환은 정말로 약간의 노력이 필요할 것이다. 하지만 나는 그것이 노력할 가치가 있는 노력이라고 생각한다.나는 물건들을 깨끗하게 유지하고 비고문들을 기사 네임스페이스에 들어오지 못하게 하는 것이 가치 있다고 생각한다.바나나 공화국 (대화) 14:29, 2019년 7월 15일 (UTC)[응답]

IMHO는 독자들이 정말 읽고 싶은 기사를 찾을 수 있도록 도와주는 독서 보조 도구다.독자들을 위한 서비스.그것들을 숨기는 것은 전혀 도움이 되지 않는다.배너톡 13:09, 2019년 7월 15일 (UTC)[응답]

그 제안은 모호한 페이지를 만들지 않을 것이다.그것은 현재 조지 워싱턴과 같은 모호한 페이지들을 가리키는 모자 노트만 만들 것이다.대신 조지 워싱턴이요바나나 공화국 (토크)

그리고 그것은 많은 페이지들이 혼란스러운 네임스페이스로 리디렉션되도록 만들 것이다.백과사전의 작업복사를 원하는 사람은 기사뿐만 아니라 네임스페이스도 복사해야 할 것이다.당신의 오류는 기사 네임스페이스에 "기사"만 있을 수 있다고 가정하는 것이다.많은 목록과 개요는 적절한 "아티클"도 아니고 메인 페이지도 아니다. (예를 들어 포털이나 위키피디아와 같이 메인 페이지를 다른 네임스페이스로 이동하는 것은 내가 지지하고 싶은 제안이다.)—쿠스마 (t·c) 13:29, 2019년 7월 15일 (UTC)[응답]

기사 네임스페이스에 '예술가'만 있을 수 있다고 생각하는 게 너의 잘못된 생각이야그게 오류야?

많은 목록과 개요도 적절한 "아티클"이 아니다."outline(아웃라인)"이 무슨 뜻인지 모르겠지만(아마도 "stubs(스텁스)"를 의미했을 것이다) 이미 앞에서 지적했듯이 위키백과에서는 다음과 같이 말하고 있다.스타일/목록 매뉴얼, 목록은 목록 기사로 간주된다.바나나 공화국 (대화) 13:48, 2019년 7월 15일 (UTC)[응답]

생물학의 개요와 같은 개요.또는 템플릿을 초월하는 500개 이상의 기사 중 하나:바닥글의 윤곽을 그리다.종종 "거친 스케치"라고도 한다.배너톡 15:10, 2019년 7월 15일 (UTC)[응답]

위키피디아의 간단한 내용에 따르면:개요, 개요는 목록 기사로, 따라서 이 제안의 영향을 받지 않을 것이다.바나나 공화국 (대화) 2019년 7월 15일 (UTC) 16:10, 응답

요약하면, 개요는 어떤 주제에 대해 어떤 주제를 포함하는지, 그리고 그 주제들이 어떻게 서로 연관되어 있는지를 보여줌으로써 독자들이 어떤 주제에 대해 빨리 배울 수 있도록 돕는 목록 기사다.그래서 당신이 이것을 단지 목록으로 밀어내고 싶을 때에도, 그것은 여전히 특별한 종류의 목록이다.배너톡 17:09, 2019년 7월 15일 (UTC)[응답]

나는 이것이 어떤 혜택을 줄지 아직 확실하지 않다.독자층 POV로 볼 때, 현재와 똑같이 잘 되는 것이 최상의 시나리오인 것 같다.편집자 POV에게 이것은 단지 일을 복잡하게 만드는 것처럼 보인다.우선 DAB 페이지 대신 리디렉션 페이지가 필요한 것 같은데, 예를 들어 씰링에 대한 잘못된 링크가 Dissambiguration:seal로 제대로 전달될 수 있도록 말이다.나는 일반적으로 "문제를 찾아내는 해결책"이라는 말이 무시로 자주 사용되기 때문에 싫어하지만, 이 제안은 확실히 자격이 있는 것 같다.무엇이 고쳐질지 구체적으로 말해줄 수 있니?맷 드레스 (대화) 16:03, 2019년 7월 15일 (UTC)[응답]

나는 그것이 일을 더 깨끗하게 하는 방법이라고 생각한다.설명 페이지가 기사로 간주되지 않는 경우, 문서 네임스페이스에 포함되지 않아야 하며, 기존 네임스페이스에는 맞지 않으므로 자신의 네임스페이스에 포함되어야 한다.이 제안을 실행하면 기사 네임스페이스에서 메인 페이지가 유일한 비기사로 남게 된다(리디렉션은 어차피 계산되지 않기 때문이다).바나나 공화국 (대화) 16:13, 2019년 7월 15일 (UTC)[응답]

그런 측면은 이해하지만, 무슨 목적으로?사람들이 이것이 다룰 것이라고 생각하는 문제는 무엇인가?맷 드레스 (대화) 17:53, 2019년 7월 15일 (UTC)[응답]

02:14, 2019년 7월 15일 (UTC)의 게시물에 대한 회신: 예 - 위키백과의 대화에서 공지사항:네임스페이스#Disambigation 네임스페이스와 관련된 위키백과의 대화:위키피디아를 가리키는 디스암비게이브/아카이브 33#Dab 페이지 위치:마을 펌프(정책)/아카이브 50#ALL 해제를 끝내는 페이지(해제) 위키백과는 다음과 같이 말한다.Discambigation/Archive 31#Hatnote는 disambigation 페이지로 리디렉션된다.및 위키백과:Billage pump (정책)/Archive 84#Uniform Disambigation 페이지 이름 지정이러한 논의의 일부는 이전의 다른 논의와 연결된다. --Redrose64 🌹 (대화) 19:49, 2019년 7월 15일 (UTC)[응답]

• DAB를 위키다타에 어떻게든 연결하자는 생각에...OH HELL NO! 블루보아 (토크) 20:00, 2019년 7월 15일 (UTC)[응답]
• 난 이것에 반대할 것이다.문제를 찾아 솔루션을 구현하려면 막대한 작업이 필요할 것으로 보인다.--CNMALL41 (대화) 22:14, 2019년 7월 15일 (UTC)[응답]
• 또한 반대한다.깨지지 않았어, 원트픽스/돈트픽스.삼사라 11:47, 2019년 7월 16일 (UTC)[응답]

• 여기에 옵션만 던져 놓고도 몇 가지 문제가 있는 것 같다.우리의 검색 기능은 'Mercury'에 꽤 좋은 '해방'을 준다.우리는 기본적으로 모든 모호한 페이지들을 삭제 할 수 있다. annd는 그 점을 모호한 페이지로 리디렉션할 수 있다. 여기서 'mercury'에 대한 검색이 자동적으로 가능한 기사들의 목록으로 당신을 데려올 것이다.단지 문제는 http://en.wikipedia.org/wiki/Mercury이 당신을 검색결과로 직접 데려오는 것이 아니라 '이 페이지 만들기' 결과를 가져다준다는 것이다.(이제 거의 틀림없이 검색 결과는 적절하게 구획된 혼란 페이지보다 덜 유익할 것이다.)--Dirk Beetstra^{T C} 12:00, 2019년 7월 16일 (UTC)[응답]
  • 이것은 오직 개별적인 단어에 대해서만 효과가 있다.사람 이름을 포함한 여러 단어 문구의 경우 검색 기능은 모호함을 해소하기 위해 사용할 수 없다.만약 당신이 "존 스미스"를 찾고 있다면, 그것은 당신에게 "존"과 "스미스"라는 단어가 포함된 모든 기사를 줄 것이고, 종종 몇 페이지의 뒤죽박죽이 된 관련 없는 결과들 뒤에 분명히 관련 있는 결과를 묻게 될 것이다.또한, 여러분이 주목하듯이, 앤드류 잭슨이나 로스앤젤레스와 같이 주요 주제를 가지고 있는 페이지의 경우, 제목을 검색하는 것은 다른 결과를 쉽게 보기 위해 설명 페이지가 필요하다는 것을 의미하는, 그 주요 주제로 여러분을 안내할 것이다.그런 식의 디스패치 페이지는 수만 개에 달하는데, 일차적인 주제가 그 페이지를 디스패치된 제목에 놓이게 된다.bd2412T 23:50, 2019년 7월 16일 (UTC)[응답]
    • @BD2412: 내 생각에 분명히 바보 같은 것이 있다고 이미 예상했었는데 :-). --Dirk Beetstra^{T C} 13:42, 2019년 7월 17일 (UTC)[응답]
      • 검색 기능의 결함은 누군가가 검색 기능을 사용하여 모호한 페이지를 설정하기 전까지 전혀 명백하지 않다.어떤 경우에는, 제목이 모두 일치하는 적은 수의 의미를 가진 단어의 제목이 있는 경우가 있다.한편, Seal과 같은 페이지를 보고 나서 seal이라는 단어를 검색해보면, 검색결과가 얼마나 아래쪽으로 내려가야 가장 흔한 seal의 의미인 Pinniped를 찾을 수 있는지 보라.bd2412 T 15:55, 2019년 7월 17일 (UTC)[응답]
• 기치별로 반대하라.해설 페이지는 백과 사전의 일부분이기 때문에 메인 스페이스에 있다. 기사나 리디렉션과 같은 백과사전이다.다른 네임스페이스는 Encycopaedia를 구축하는 데 궁극적으로 도움이 되지만 그것의 일부가 아닌 것들을 위한 것이다.만약 통계적 목적을 위해 메인 스페이스에 있는 얼마나 많은 페이지가 기사인지, 얼마나 많은 페이지가 리디렉션되는지, 얼마나 많은 페이지가 혼란스러운지 분석하고자 한다면, 나는 프로그래머가 할 수 있는 일이 아닌가 의심한다.ϣerSpielCequers 09:04, 2019년 7월 20일 (UTC)[응답]

내가 다른 곳에서 썼듯이, 그것은 단지 기사 수만의 문제가 아니다.그것은 또한 비임시적 기사라고 여겨지는 것을 기사 네임스페이스에 포함시키지 않는 것에 관한 것이다.바나나 공화국 (대화) 00:01, 2019년 7월 22일 (UTC)[응답]

여기에는 문자 그대로 수십만 페이지를 이동하고, 기존 템플릿 정책 페이지 및 보고서에 수천 개의 다른 조정 및 수정 작업을 수행하는 것이 포함된다. bd2412T 00:22, 2019년 7월 22일(UTC)[응답]

맞아, 하지만 그건 한 번이고, 내 생각에는 노력할 가치가 있어.나는 대부분의 일이 자동화될 수 있다고 생각한다.바나나 공화국 (대화) 01:13, 2019년 7월 22일 (UTC)[응답]

• 이것은 문제를 찾는 해결책이다.같은 이름을 가진 사람과 사물에 대한 새로운 기사가 만들어지고, 별도의 네임스페이스에 불분명한 기사를 배치하는 것은 단지 과정을 복잡하게 만들고 명백하게 유용한 목적 없이 역사를 흐리게 하기 때문에 정규 기사와 불분규 사이에는 적당한 양의 움직임이 있다."그것들은 기사가 아니다"라는 모든 논쟁은 머리털을 깎는 연습이다.리디렉션도 기사는 아니지만, 기사 공간에 상주하며, 일반 기사 상태와 리디렉션 사이에서 일정량의 이동의 대상이 된다.어찌된 일인지 백과사전은 그럭저럭 잘 지내고 있다.그리고 위키다타 아이디어에서는... 아니다.전체 WP/WD 인터페이스는 대부분의 편집자들에게 블랙박스다.아크로테리온 (대화) 03:54, 2019년 7월 22일 (UTC)[응답]
• 기사 대 항법 보조 도구로 중요한 것은 어떤 경우에는 식별하기 어렵다.그것은 일종의 회색 지대일 수 있다. 원근법의 문제.예: 카트레이싱 챔피언십, Bagwat, Custos, 원격 운행 차량, 토론토 레이디얼 라인, 코카서스의 신화, 메르세데스-벤츠 SLC 클래스, ARD 디지털 -- GreenC 04:42, 2019년 7월 22일 (UTC)[응답]
• 내 생각에 이것은 WP에 근거하여 거절할 수 있는 좋은 경우다.IAR 혼자.그럼 디스컴파일 페이지는 기사 공간에 속하지 않는 겁니까?그게 무슨 해를 끼치는데?아크로테리온(Acroterion)이 위에서 지적했듯이, 이것은 백과사전에 거의 또는 전혀 도움이 되지 않는 헤어스타일 운동이다. --llywratch (talk) 19:47, 2019년 7월 25일 (UTC)[응답]

GA 및 FA 등급 기사의 요구사항으로서의 접근성(이해성)

WP:B 등급 기사의 요건은 "그 내용을 적절히 이해할 수 있는 방식으로 표현"하고 "가능한 한 광범위한 청중과 함께 작성"하도록 요구한다.이는 논리적으로 B(WP:GA?와 WP:FA?)보다 높은 클래스도 이 요건을 갖지만, 그렇지 않다는 것을 의미한다.이것은 기술적으로 어떤 개념을 설명하려는 노력 없이 글들이 읽기 전에 많은 사전 지식을 가질 수 있게 할 수 있다.현재 상태와 같이 접근성 요건에 가장 근접한 것은 산문이 GA에게는 "명료하고 간결해야 하며", FA에게는 "직접적이고 전문적인 표준"이어야 한다는 것이다.과학 논문은 보통 이러한 요구 사항을 통과시키지만, 그들은 일반인을 위한 것이 아니라 그 분야의 전문가를 위해 쓰여진다. 이런 유형의 글이 위키피디아가 지향하는 것이 되어서는 안 된다.

나의 제안은 간단하다: 접근성을 WP:GA?와 WP:의 "잘 쓰여진" 섹션에 따른 요구사항으로 언급한다.FA?. 이것은 단순히 단어 하나를 추가하는 것일 수도 있고, 기사에 대해 기대되는 것을 지명자와 평론가 모두에게 명확해질 것이다.--Megaman en m (토크) 09:04, 2019년 7월 4일 (UTC)[응답]

• "접근성"이 충족되도록 하기 위해 어떤 변경사항이 있는지 명확히 해 주시겠습니까?그 단어는 잠재적으로 거대한 영역을 포괄하고 있으며, 나는 무엇이 필요한지 알고 싶다."접근성"에 대한 요청을 추가하는 것은 생각만큼 명확하지 않다! - SchroCat (대화) 09:20, 2019년 7월 4일 (UTC)[응답]
• 그것은 말하기는 더 쉽지만 정의하기는 더 어려운 것으로 들린다: 어떻게 한 단어로 더 접근하기 쉬운 FA를 정의할 것인가?——SerialNumber54129 09:22, 2019년 7월 4일(UTC)[응답]
• WP:접근성은 우리의 스타일 매뉴얼의 일부로서, 현재 GA 및 FA 기준에 의해 인용된 MOS 페이지와 함께 연계될 수 있지만, 이것이 원본 포스터가 "접근성"에 의해 의미하는 것과 같은지 잘 모르겠다.필 브리저 (대화) 09:33, 2019년 7월 4일 (UTC)[응답]

나는 실제로 그런 종류의 접근성을 언급한 것이 아니라, 여전히 복잡한 주제를 포함하면서 가능한 한 쉽게 기사를 읽을 수 있도록 하는 것을 말하는 것이다.

그 문구에 관해서는, 내가 처음에 말했던 것보다 더 명확하게 정의되어야 할 것이라고 나는 지금 보고 있다.여섯 번째 요구사항인 WP:B?는 그것을 잘 설명하는데, 아마도 우리는 그것을 기반으로 사용할 수 있을 것이다.WP의 경우:GA? 우리는 접근성을 '잘 쓰여진' 섹션의 세 번째 요구 사항으로 추가할 수 있다. 예를 들어 "c"와 같은 말이다.기사는 과도한 사전 지식을 요구해서는 안 되며 가능한 경우 전문 용어를 설명해야 한다."WP의 경우:FA? 우리는 다음과 같이 덧붙일 수 있다: "b.액세스 가능:기사는 폭넓은 청중이 이해할 수 있고 기사 자체에서 기술적인 용어를 설명할 수 있다고 말했다.

FA와 GA의 문구가 달라야 하는지는 잘 모르겠지만, 나는 FA의 접근성 요건이 GA의 요건보다 "더 탄탄하다"는 식으로 써보려고 노력했지만, 그렇게 잘하지는 못했을지도 모른다.구체적인 표현은 잠정적이며 입력을 위해 공개된다.--Megaman en m (토크) 09:48, 2019년 7월 4일 (UTC)[응답]

문제의 징후 없이 이미 규칙이 많은 과정에 규칙을 더 추가하려고 하기보다는 FA와 GA의 몇 가지 예를 찾을 수 있는가?고마워 - 슈로캣 (대화) 10:02, 2019년 7월 4일 (UTC)[응답]

나의 제안은 문제가 있는 GA나 FA 기사를 폭로하려는 것이 아니라, 요건 사이의 내부 불일치를 시정하고 검토자와 지명자에게 명료성을 제공하는 것을 목표로 하고 있다.나는 GA나 FA 기사에서 다양한 용어가 일반 청중에게 적절히 설명되지 않는 것을 발견할 수 있었다. 예를 들어, 덴마크어로 "근접적인 형태론적 정렬"과 같이, 그러나 그것은 더 큰 요점을 놓칠 것이다.기술적으로 일관성을 높이는 또 다른 방법은 WP:B?의 접근성 요구 사항을 제거하는 것이겠지만, 내 의견으로는 그렇게 가는 것이 올바른 방법은 아니다.--Megaman en m (토크) 10:41, 2019년 7월 4일 (UTC)[응답]

내가 생각할 수 있는 한 예는 Crater (Constellation), 특히 Features 섹션이다.FA nom I에 대한 나의 논평에서, 그 부분을 언급하고 WP를 호출했다.청중들, 무엇보다도, 가능한 한 많은 독자들이 여러분의 기사를 접근하고 이해할 수 있도록 하라, 나는 이것이 바로 메가맨 엥이 말하고 있는 것이라고 생각한다.나는 이 특정 기사를 부끄럽게 하거나 FA로 승격하지 말았어야 했다고 말하려는 것은 아니지만, (비전문가) 독자에게 문맥을 제공하는 것은 여전히 이 기사가 개선될 수 있는 영역이라고 생각하고 있으며, FA/GA 기준의 명시적인 부분이라는 생각이 마음에 든다(간단히 언급될 뿐이라 하더라도).콜린 M (토크) 16:47, 2019년 7월 5일 (UTC)[응답]

나는 당신이 이것을 더 추구하고 싶다면, 당신의 첫 번째 단계는 다른 용어를 찾는 것이라고 생각한다.위키피디아의 경우, 접근성은 위에서 연계된 것으로 정의된다.뭔가 다른 걸 원하니까 다른 이름이 필요하겠지. --게르다 아렌트 (대화) 12:03, 2019년 7월 4일 (UTC)[응답하라]

접근성은 내가 말하는 것의 일반적인 용어일 것이다. 하지만 만약 비유가 필요하다면, 그냥 그 기사가 "이해할 수 있어야 한다"고 말할 수 있을까?같은 개념을 설명하는 완벽한 기사 에세이에서 사용하는 용어다.-메가만엔엠(토크) 12:44, 2019년 7월 4일(UTC)[응답]

만약 그것이 "이해성"이라면, FA는 이미 규정을 준수해야 한다 - 한 기사당 최소 5명의 리뷰어를 보유해야 한다(보통 비전문가의 경우, 주제와 관련되지 않음). - SchroCat (대화) 12:51, 2019년 7월 4일 (UTC)[응답]

이해할 수 있는 것은 관련 지침인 위키백과에 의해 사용되는 것이다.기술 기사를 이해할 수 있게 만들어라. 그리고 그렇다, 만약 당신이 "접근성"이라는 단어를 사용한다면 사람들은 혼란스러워 할 것이다. 그래서 나는 "이해성"을 추천한다.갤럽터 (pingo mio) 13:11, 2019년 7월 4일 (UTC)[응답하라]

그거 흥미로운 시각인데, 그건 생각해 본 적이 없어.그러나 이는 여전히 GA가 이해가능성 문제에 대해 "취약"을 남긴다. 단일 검토자는 일반적으로 일반 주제에 익숙하고 일반인의 관점을 고려하지 않을 수 있기 때문이다.예를 들어, GA에 지명된 비디오 게임 기사의 검토자는 일반인이 실제로 어떤 경험을 하는지 모를 수 있다는 생각을 멈추지 않을 수 있다.--Megaman en m (토크) 13:00, 2019년 7월 4일 (UTC)[응답]

나는 "그 기사는 넓은 청중들이 이해할 수 있다"는 것이 항상 가능하다고 생각하지 않기 때문에, 당신의 제안은 (적어도 FA에서) 일부 주제들을 전혀 다루지 못하게 할 것이다.예를 들어, 내가 작업한 기사는 현재 B급인 Dehn invariant로 평가되고 있는데, 수학적으로 표현된 고등학생들이 읽을 수 있기를 바라는 리드선이 있지만, 학부 수학 전공자들에게는 아마도 어려울 수 있는 일부 후기 내용(특히 "실현성")이 있다.그것은 기사를 어렵게 만들려는 어떤 의도 때문이 아니라, 내가 할 수 있는 한 쉽게 접하기 어려운 것이었기 때문이다; 그것은 기술적인 주제고 어떤 기술적인 것은 피할 수 없다.그러한 물품들은 자동적으로 상위 계층에 있는 것이 금지되어야 하는가?더 높은 계급으로 보상받을 수 없기 때문에, 그러한 기사들을 더 좋게 만드는 데 일하기 위한 동기가 없어야 하는가?—David Eppstein (대화) 18:47, 2019년 7월 4일 (UTC)[응답]

많은 사람들이 이해하기 어려운 모든 학문적 주제 영역에서 GA나 FA 클래스에 포함시키고 허용해야 하는 많은 기사들이 있다는 데이비드 엡스타인의 의견에 동의한다.우리는 사람들을 스트레칭해야 한다.하지만, 그런 말을 한 후에, 그리고 수학의 대학원생으로서, 나는 대부분의 수학자들이 명확하고 이해할 수 있는 방법으로 글을 쓸 수 없다는 것을 반영하는, 불필요하게 난독하다는 것을 발견한다.나는 대부분의 수학이 꽤 이해하기 쉽다는 것을 알지만, 또한 우리의 수학 기사들 대부분이 꽤 이해하기 어렵다는 것을 발견한다.필 브리저 (대화) 19:14, 2019년 7월 4일 (UTC)[응답]

어떤 기사가든 FA 지위를 획득할 수 있어야 하는 것은 물론 원칙적인 경우다.어떤 주제들은 좀 더 기본적인 개념에 대한 기존의 지식을 합리적으로 필요로 한다; 만약 우리가 유전학에 대한 진보된 기사에서 모든 전문 용어들을 설명해야 한다면, 그 기사는 다루기 힘들 정도로 장황해질 것이다.나의 제안은 이러한 기술성을 피하거나 가능한 한 설명(예: 한 두 문장에서 충분히 설명할 수 있는 경우)을 하기 위한 진지한 시도를 하는 것이다.만약 그 개념을 언급할 필요가 있고, 복잡하며, 간단히 설명할 수 없다면, 우리가 할 수 있는 것은 간단한 위키링크뿐이다.

예를 들어, 언어 기사는 명사나 시제가 무엇인지 설명해서는 안 된다.그러나 위에서 언급된 "추상적인 형태론적 정렬"과 같은 용어에 관해서는 언어학에 대한 입문 지식을 가진 사람조차도 머리를 긁적이는 것으로 남을 수 있다.나는 "기본" 개념과 더 진보된 개념의 개념을 결정하는 것이 때때로 어려울 수 있다는 것을 인정한다. 그러나 그것만으로는 제안된 이해가능성 요구사항을 해결할 수 있는 이유가 되어서는 안 된다.부연으로서, 보다 복잡한 개념은 기사 말미에 언급하는 것이 바람직하며, 도입은 사람들을 겁먹게 하지 말고 당면한 화제로 끌어들이도록 해야 한다.--Megaman en m (대화) 19:18, 2019년 7월 4일 (UTC)[응답]

그렇다, "넓은 청중들이 이해할 수 있다"는 것은 너무 강한 요구일 수 있다.하지만 WP:B?그 기사는 그 내용을 적절하게 이해할 수 있는 방법으로 제시한다는 표현을 사용한다.그것은 가능한 한 넓은 청중을 염두에 두고 쓰여진 것이라고 말하면서 그것을 확장한다. 위키피디아가 일반 백과사전 이상의 것이기는 하지만, 기사는 불필요한 기술적 배경과 기술 용어가 설명되거나 가능한 한 피해야 한다고 가정해서는 안 된다.내 생각에 이 문장의 문구는 당신의 우려를 해소할 것이고, 기술 주제에 관한 어떤 기사도 자동적으로 배제하지 않을 것이다."가능한 한 광범위한 청중"이라는 고도로 기술적인 과목은 실제로 상당히 좁을 수 있으며, 페이지에 실제로 도달할 가능성이 있는 독자들의 집합에 비추어 고려해야 한다.아주 기초적인 수학 교육만을 받은 사람은 Dehn 불변성에 도달할 가능성이 낮기 때문에, 기사의 내용을 이해하는 그들의 능력이 강한 고려사항이 되어서는 안 된다.콜린 M (토크) 17:17, 2019년 7월 5일 (UTC)[응답]

나는 그것을 "읽을 수 있는"이라고 부를지도 모른다.그러나 나는 적어도 대부분의 정규적인 FAC 지명자들은 적어도 평론가들이 이것에 대해 도움을 주기를 희망한다고 생각한다.나는 변호사로서 내 분야에서 전문 용어를 사용하는 경향이 있다는 것을 안다.그것은 때때로 평론가들이 "허어?"하는 것으로 이어졌다."이미 하고 있다"고 말하고 싶지만, 최근 FA에서 실제 사례가 나오기를 정말 기다리고 있다.--위활트(토크) 23:47, 2019년 7월 4일(UTC)[응답]

가독성은 내가 생각할 수 있는 가장 근접한 것으로 가독성 척도로 만들어진 점수가 있다.알란스코트워커 (대화) 00:00, 2019년 7월 5일 (UTC)[응답]

가독성은 관련되고 유용한 개념이지만, 내가 정확히 말하는 것은 아니다.가독성은 현재의 "잘 쓰여진" 요건에 쉽게 해당된다.

위활트 대응=FA가 평소 식견이 없는 복수의 평론가를 필요로 한다는 점도 이해도 문제를 잘 해결해 준다.그러나 GA 기사에는 여전히 문제가 남아 있는데, 이는 주로 주제에 대해 정통한 단일 검토자만 필요하기 때문이다.나는 또한 모든 수업의 요구사항이 내부적으로 일치하기를 바란다.즉, 하위계급이 상위계급에서 부족한 요건을 갖추어서는 안 된다는 뜻이다(WP:B의 6번째 요건을 말하는 것이다).

간단히 말해서, 나는 이제 이해가능성 요건이 FA 클래스에 실질적으로 필요하지 않다고 생각한다.그러나, 일관성과 검토 과정의 이유로, GA는 위에 언급된 이유 때문에 여전히 이 요구사항의 혜택을 받을 것이다.--Megaman en m (토크) 07:47, 2019년 7월 5일 (UTC)[응답]

B급 기준은 "그 내용을 적절히 이해할 수 있는 방식으로 표현한다"와 "가능한 한 광범위한 청중을 염두에 두고 작성한다"는 것은 합리적으로 실행 가능하고 목적상 합리적으로 명확하다.어떤 특정한 경우에서 그것들이 어떻게 해석될지는 주제에 달려있을 것이다.GA와 FA에 대한 기사가 제안될 때 B급 기준이 더 이상 적용되지 않는다고 가정할 이유가 있는가?무엇이 적절하고 가능한지에 대한 피드백은 대상 청중에게 필요한 배경을 가진 사람으로부터 나와야 한다.이것은 대개 이미 전문가가 아닌 사람이지만, 많은 경우에 주제의 더 넓은 수준에 대해 어느 정도 현존하는 이해를 가지고 있어야 한다.검토자 간에 불확실성이나 이견이 있을 때는 우선 누가 대상인지에 대해 어느 정도 합의를 하는 것이 유용할 수 있다.제안자는 이에 대해 합리적으로 잘 알고 있어야 하며, 그 이유를 설명할 수 있어야 한다.· ··· 피터 사우스우드 : 08:23, 2019년 7월 5일 (UTC)[응답]

B급은 안전 점검이 필요 없기 때문에 일부 B급 기사가 B급 요건을 완전히 충족하지 못할 가능성이 크다.GA는 처음으로 공정한 검토자가 요구사항을 준수하는지를 면밀히 검토한다.따라서 최소한 이해가능성을 포함하여 하위계층의 모든 요구사항을 포함해야 한다.평균(지식 가능한) GA 검토자는 열거된 요건, 특히 산문, 문법 및 소싱에 더 초점을 맞출 것이다.이해가능성이 균열로 떨어져 FA 지명 가능성 중 '재발견'될 수 있다.--메가만 en m (토크) 08:39, 2019년 7월 5일 (UTC)[응답]

• 이것을 전폭적으로 지지하라.이것은 이미 내가 GA 리뷰를 할 때 고려하는 요소다. (그리고 나는 무의식적으로라도 많은 다른 사람들도 그렇게 한다고 생각한다.)당신은 이것이 WP의 문구에 이미 존재한다고 주장할 수 있다.'프로세스는 명확하고 간결하다'와 '불필요한 디테일에 들어가지 않고 주제에 집중한 스테이즈' 사이의 GACR을 굳이 명시적으로 언급하는 것이 유익할 것 같다.완전히 새로운 기준이 될 필요는 없으며, 몇 단어를 추가하는 것만큼 간단할 수 있다는 것에 동의한다. cfWP:AUDENUS, "가능한 한 많은 독자들이 접근 가능하고 이해할 수 있는" 기사를 만드는 이유와 방법에 대해 확장한다.콜린 M (토크) 16:57, 2019년 7월 5일 (UTC)[응답]

그래서 대부분의 사람들은 B 등급의 여섯 번째 요건이 FA 및/또는 GA 요건에 어떤 식으로든 포함되어야 한다는 것에 동의하는가?따로 섹션이 있을 필요는 없다.--Megaman en m (토크) 06:34, 2019년 7월 6일 (UTC)[응답]

• 나는 실제로 많은 청중들이 이해할 수 있지만 그렇지 않은 방식으로 쓰여질 수 있는 기사는 FA가 되어서는 안 되며 아마도 GA가 되어서는 안 된다는 것에 확실히 동의한다.내 걱정은, 누가 그것이 기술적으로 쓰여질 수 있는 정도를 정확히 판단하느냐 하는 것이다.
  제외 : 이것은 {{technical}} 템플릿의 영원한 문제다.어떻게 이해가능성이 향상될 수 있는지 또는 심지어 가능한 한 이해할 수 없는 곳에 대한 표시가 없는 기사에 매우 자주 추가된다.가장 간단한 설명은 태깅 편집자들이 자료 자체를 이해하지 못하고, 그런 이유로 사실일 수도 있고 아닐 수도 있지만 판단할 준비가 되어 있지 않은 박람회에 문제가 있다고 가정하는 것으로 보인다.
  따라서 비기술 검토자에게 기술 자료의 홍보에 대한 거부권을 주거나, 아니면 그 자료가 가능한 한 명확하게 제시되어 있다는 전문가들의 판단을 단순히 신뢰해 달라고 부탁하는 것이다.그 두 가지 옵션이 특별히 매력적이라고는 할 수 없다. --트로바토어(토크) 08:06, 2019년 7월 6일 (UTC)[응답]
• 나는 WP를 고려할 때 이 제안에 반대한다.따라서 CREF와 일반적인 관점에서 쓸 수 없는 충분히 틈새 있는 주제가 FA 지위에서 제외될 것이라는 막연한 가능성.또한, FASR의 다음 섹션은 이미 접근성 요구사항을 암시하는 것으로 해석될 수 있다고 주장한다.

그 산문은 ...을 흥미롭게 한다.(1a부터)

주요 사실이나 세부사항을 무시하지 않고 주제를 문맥에 배치한다(1b부터).

(둘 다 내 것임)

만약 그 산문이 매력적이면, 그것은 일반 청중들과 어울리는데, 이것은 일반 청중이 그것을 이해할 수 있다는 것을 암시한다.만약 주제가 문맥에 놓여진다면, 글에서 문맥에 대해 충분히 알고 있는 사람은 세부사항을 이해할 수 있을 것이다.

그 모든 것을 말하였지만, 합의가 압도적으로 유리하게 진화되었다면, 나는 그 제안에 소리 높여 반대하지는 않을 것이다. – John M Wolfson (대화 • 기여) 05:31, 2019년 7월 7일 (UTC)[응답]

@Trovatore:질문을 받으면 기사의 청중이 누구여야 하는지를 명기할 수 있어야 한다.이러한 방식으로 심사자는 이해도 요구사항을 어떻게 시행해야 하는지를 평가할 수 있다.예를 들어, (대부분?) 전기들은 모두를 위해 쓰여져야 한다.검토자가 설명할 수 없는 전문 용어를 발견하면, 그들은 설명될 것을 요청해야 한다.언어의 문법에 관한 기사는 언어학/문법에 기초적인 배경을 가진 사람들을 위해 작성되어야 한다.필요한 배경이 없는 사람들을 위해 그런 글을 쓰는 것은 거의 불가능할 것이다; 대부분의 글은 언어의 문법에 대해 말하기 보다는 기본적인 언어학에 대해 설명하는 것으로 끝날 것이다.'모두들'을 위해 글을 쓰는 것이 타당하지 않다고 주장하는 것은 지명자의 몫일 것이다.물론 "언어학의 기본 배경"이 실제로 무엇인지에 대해 동의하지 않을 위험은 여전히 존재한다.그러나 이 문제는 이해가능성에만 국한된 것이 아니다.그 산문은 "명료하고 간결하며" 그리고 무엇이 3b를 구성하는지이다."세부적인 세부사항"은 유사한 문제에 부딪힐 수 있다.요컨대, 나는 검토자와 지명자 둘 다 가능한 한 많은 청중들을 염두에 두도록 하는 것의 장점들 때문에 어떤 잠재적인 단점들은 더 크다고 믿는다.--Megaman en m (토크) 07:46, 2019년 7월 7일 (UTC)[응답]

@Megaman en m: 글쎄, 내 우려의 일부에 대한 해답인 것 같은데, 여기서 더 깊은 문제는, 어떻게 리뷰어가 기사의 주제를 이해하는 데 필요한 배경을 가지고 있지 않은지, 그것이 의도된 청중을 위해 적절히 쓰여졌는지에 대한 판단이 기대되는가?이러한 검토자가 이러한 문제에 대해 전문가의 도움을 요청할 것으로 예상된다고 명시할 수 있는가? --Trovatore (대화) 22:21, 2019년 7월 10일 (UTC)[응답]

@John M Wolfson:Trovatore에 대한 위의 나의 대답은 FA/GA에서 우연히 배제된 틈새 기사를 가지고 있는 당신의 두려움을 덜어줄 것이다.현재 FA 요건에서:나는 그들이 6. WP:B?에서 언급된 바와 같이 이해가능성을 강요하는 것에 동의하지 않는다.언어학에 관한 기술 논문은 찾았지만 비전문가가 읽지는 않았을 겁니다.그들은 또한 보통 훨씬 더 많은 전문용어를 도입함으로써 그렇게 하기는 하지만 주제를 올바른 맥락에 배치한다.이해도 요건은 현재 다른 FA/GA 요건에서 다루지 않으며, 검토 과정에 있는 사람들이 의도된 청중을 염두에 두어야 하는 중요한 과제에 집중하는데 도움이 될 것이다.--Megaman en m (토크) 07:46, 2019년 7월 7일 (UTC)[응답]

@Megaman en m:, 그것은 틈새 주제에 대한 쓰기 가능성에 대한 나의 두려움을 다소 완화시켜 준다.언어학(기본 문법 등)과의 올바른 문맥에 배치하는 것에 대해서는, 내적 연계가 바로 그것인 것 같다.– John M Wolfson (대화 • 기여) 07:52, 2019년 7월 7일 (UTC)[응답]

@John M Wolfson:내부 링크는 유용하지만, 주로 "필요한 독서 자료"보다는 그 주제에 대해 더 많이 읽기를 원하는 사람들을 위한 것이어야 한다.마지막 수단으로만 의존해야 한다.--메가만 en m (토크) 08:08, 2019년 7월 7일 (UTC)[응답하라]

모든 것이 달려 있다.내가 '101개 기사'(미국 기초대학 과정 고전적 지정에서 나온 것)라고 부르는 것이 많은 지식을 상정해서는 안 되는 것이다.그리고 "202" 기사들이 있는데, 지식의 경우 "사전 요건"이 있고, 기본 개념을 위한 링크에 의존해야 할 수도 있고, 우리가 전문화됨에 따라 숫자가 더 늘어날 수도 있다.일부 물품은 혼성품이며, 선박의 역사에 관한 한 "101"이 될 수 있지만, 선박의 사양과 장비에 관한 한 "202" 이상이 될 수 있다.내가 원하는 만큼 독자의 반응에 대한 정보는 없지만(구식 피드백 도구를 지지했다) FA 지명자와 평론가는 많은 토크 페이지 댓글과 TFA데이 리액션, 다른 사람들의 리뷰 등을 보고 제대로 기어를 짜는 일을 잘 해내고 있다.우리가 뭘 다르게 해야 할지 확신이 서지 않을 뿐이다.--위활트(대화) 11:01, 2019년 7월 7일 (UTC)[응답하라]

나는 대부분의 편집자들이 GA도 물론 일반적인 B급 기준을 충족시켜야 한다는 것을 본능적으로 이해한다고 생각한다.이 아이디어에는 다소 복잡한 문제가 있지만, B급 평가는 대개 위키프로젝트에 의해 이루어지는데, 위키프로젝트는 B급 기준을 그들의 특별한 필요에 맞게 수정한다.그리고 다소 성가신 것은 6 GA 기준의 번호 매김이 6 B 등급 기준과 너무 달라서 심각하게 혼란스럽다.B1은 GA2로 강화되고, B2는 GA2-GA4로, B3-B4는 GA1로, B5는 본질적으로 GA6 + 인포박스를 요구하고, B6는 GA1로 명시적으로 커버되지 않는다.

Megaman en m이 발견한 마지막 점은 GA1b가 MOS를 포함하지 않고 특정 섹션만 필요로 하기 때문이다.JARGON, 이건 MOS:JARGON은 적용되어서는 안되지만 GA1b에 열거된 것과 대조적으로 그것은 단지 아주 작은 부분이기 때문이다.어차피 리스트에 추가될 수도 있지 않을까?

GA 기준에 추가할 수 있는 또 다른 사항으로, 실제로 충분할 수도 있다: 일반적으로 GA는 적절한 위키프로젝트의 B급 기준을 충족해야 한다.그러나 이것은 GA 검토자들이 확인할 필요가 없는 것으로 분명히 표시되어야 한다.위키프로젝트가 B급 기준에 대해 이상한 생각을 갖고 있는 경우(예: WP만 사용할 수 있음)에는 상당한 추가 노력이 필요하고 원치 않는 영향을 미칠 수 있다.지원 대상) 또는 범위 내에 있는 MEDRS 소스에 관계 없이 MEDRS 소스한스 아들러 11시 53분, 2019년 7월 7일 (UTC)[응답]

이 논의를 진전시키기 위해 투표 절차를 시작했다.--메가만 en m (토크) 10:30, 2019년 7월 8일 (UTC)[응답]

대부분의 사람들이 이 제안에 괜찮다는 반대가 없는 것을 받아들일 수 있을까?--Megaman en m (대화) 19:19, 2019년 7월 14일 (UTC)[응답]

아니다(WP: 참조):폴실런스.)

나로서는 꼭 반대한다고는 할 수 없지만, 고민거리가 제대로 해소된 것 같지는 않다. --트로바토어 (대화) 19:41, 2019년 7월 14일 (UTC)[응답]

나는 당신이 FA에 대해 당신의 주장을 펴지 않았다고 생각한다. 그리고 그 논평에서 나는 WP에 변화를 주기 위한 시도를 별로 보지 못했다.WIAFA. GA.- (Wehwalt) -19:44, 2019년 7월 14일 (UTC)에 대한 의견은 없다.

@Trovatore:이 제안은 WP를 준수하기 때문에 이해가능성이 소재의 본질적인 어려움에 상대적이라는 것을 보장할 것이다.청중.당신의 다른 관심사에 대해서는, 우선 지명자는 더 넓은 청중을 위해 그 기사가 합리적으로 작성될 수 없다는 것을 주장해야 한다.이 경우, 검토자가 필요한 지식을 갖추지 못한 경우에는 전문가의 도움을 청하거나, 또는 스스로 어떤 기초적인 연구를 하는 것이 기대되어야 한다.이를 반영해 제안서를 변경했다.--메가먼엔엠(토크) 13:47, 2019년 7월 16일(UTC)[응답]

@Wehwalt:FA의 경우는 하층계급과 일치하느냐에 달려 있다.FA가 복수의 리뷰어를 보유하고 있어 GA의 경우보다 확실히 약하기 때문에 제안이 GA에 집중하게 되었다.--Megaman en m (토크) 13:47, 2019년 7월 16일 (UTC)[응답]

지금 어떻게 진행하면 되는 겁니까?이 정도면 GA의 이해가능성에 대한 문구가 어떻게 구현되어야 하는 것인가?--Megan en m (토크) 07:08, 2019년 7월 20일 (UTC)[응답]

@Megaman en m: 그래, 그게 좋을 것 같아.새로운 하위섹션 하에서 이 토론의 계속으로 만들 생각이었는지 아니면 새로운 논의를 시작할 생각이었는지는 모르겠지만, 만약 후자라면 위키피디아는 다음과 같이 이야기한다.좋은 기사 기준은 사실 더 좋은 장소일 수도 있다.전반적으로 교통량이 적지만, 그 페이지를 보는 사람들은 GACR에 대한 의견과 높은 관심도를 알고 있었을 가능성이 훨씬 더 높을 것이다.그리고 물론 여기와 WT에 관련 공지를 올릴 수도 있다.GAN. 그냥 생각 좀 해 봐.콜린 M (토크) 16:57, 2019년 7월 22일 (UTC)[응답]

GA 시행을 논의하기 위해 주제발표를 시작했다.--Megaman en m (토크) 09:13, 2019년 7월 24일 (UTC)[응답]

문제

제안:B 클래스의 6번째 요구 사항을 GA와 FA에 통합한다(정확한 표현은 나중을 위한 주제임).즉, GA 및/또는 FA 조항이 WP를 공식적으로 준수하도록 한다.청중.평론가들은 주제가 생소할 경우 전문가의 도움을 요청하거나 연구를 할 것으로 예상된다.

왜?: "이해성"은 매우 중요하지만, FA나 GA 지위에 특별히 요구되는 것은 아니다.이 새로운 요구사항은 검토 과정에 있는 사람들이 평균적인 독자를 유지하는데 도움을 줄 것이다.이렇게 하면 수업 간 일관성도 향상된다.--Megaman en m (토크) 10:30, 2019년 7월 8일 (UTC)[응답]

투표하다

• 지원(제안자) GA는 대개 기사가 동료 평가를 받는 첫 번째 경우, 검토자는 문법 및 소싱만큼 이해가능성에 중점을 두어야 한다.FA 심사는 복수의 검토자가 처음 읽는 것처럼 행동하도록 함으로써 기술적으로 이 문제를 해결하므로, 이해가능성을 위해 "수정"한다.GA에 대한 단일 검토자는 보통 주제에 대해 박식하며, 이것은 그들이 평균적인 독자의 배경 지식을 과대평가하게 할 수 있다.비록 계급간의 내적 일관성을 위해서라 할지라도, 나는 여전히 이해가능성이 FA에서 언급될 가치가 있다고 믿는다.--Megaman en m (talk) 10:30, 2019년 7월 8일 (UTC)[응답]
• 내가 위에 쓴 이유에 대한 지지.나는 이것을 하기 위한 가장 눈에 띄지 않는 방법은 WP에 몇 마디를 추가하는 것이라고 생각한다.WP에 연결된 GACR 1a:청중.1(즉, 1c)의 완전히 새로운 하위 기준도 괜찮지만, 템플릿 변경이 필요하다.콜린 M (토크) 22:09, 2019년 7월 8일 (UTC)[응답]
• 대기 중이다.이해가능성은 자료 고유의 난이도에 상대적이며, 자료의 이해에 필요한 배경이 없는 검토자는 이 기준의 평가에 전문가 도움을 요청해야 한다는 것이 명확해진다면 이를 뒷받침할 수 있을 것이다.---Trovatore (대화) 20:00, 2019년 7월 14일 (대화) 개정된 대로 지원. --Trovatore (대화) 16:47, 16:162019년 7월(UTC)[응답하라]
• 그래서 위의 내용은 내게 가능한 GA 기준으로서 어느 정도 의미가 있는 접근성에 대해 시작했다.그러나 이 특정한 언어는 내가 항상 GACR 1A에서 다룬다고 생각했던 것들이 어떻게 쓰여지는지에 관한 것이다.그래서 나는 접근성에 관한 몇몇 언어에 찬성하지만 이 특정한 언어는 이미 다루어져 있다고 생각한다.Best, Barkeep49 (대화) 16:06, 2019년 7월 16일 (UTC)[응답]

• 확실히, 이 제안은 WP의 관점에서 "접근성"에 관한 것이 결코 아니었다.접근성.그 선택이라는 단어는 약간 레드 청어였다. (그래서 토론이 "이해성"을 대신 사용하는 쪽으로 더 옮겨간 것이다.)내가 읽은 WP:GACR#1a(현재 쓰여진 바와 같이)는 내용보다 형식에 관한 것이다. 즉, 철자법과 문법이 정확하고 문장 구조가 구문 분석하기 쉬우며, 문장이 모호하지 않다.나는 내용 수준에서 "이해성"이 더 많이 적용되는 것을 본다. 즉, 문맥을 적절하게 제공하고, 명백한 것을 명시하고, 불필요한 전문 용어를 사용하지 말 것(그리고 필요할 때, 그것의 의미를 설명하라).콜린 M (토크) 16:20, 2019년 7월 16일 (UTC)[응답]

• 때로는 전문용어에 대한 설명이 반드시 다른 전문용어를 사용하게 될 것이라는 단서와 함께, 잠재적으로 유용할 수 있는 기사들을 쓸모 없게 만들지 않고서는 항상 주제의 시작 부분까지 거슬러 올라갈 수는 없다. --Trovatore (토크) 16:49, 2019년 7월 16일 (UTC)[응답]

• 공연에 늦었지만, 나는 이것이 기사에 있어서 일반적으로 매우 중요한 기준이라고 생각하며, 특히 GA와 FA에서 그것에 더 중점을 두는 것을 환영한다.펨케 니제 (대화) 15:32, 2019년 7월 31일 (UTC)[응답]

위키러브 사과의 말

이것은 예의범절을 향상시키고 사용자들이 도망가는 것을 막을 것이다.비록 여러분 자신만의 맞춤형 상을 만드는 것은 수작업으로 가능하지만, 템플릿은 더 많은 것을 격려하고 현재 이 커뮤니티에 부족한 중요한 속성을 촉진할 것이다.THE NEW ImperativeWizard(챗) 19:13, 2019년 7월 22일(UTC)[응답]

나는 조작된 사과를 진정한 사과로 여기지 않을 것이다.사과하고 있는 것과 관련이 있는, 자신의 말로 간단하게 사과하는 것이 훨씬 낫다.영어 백과사전을 편집할 수 있는 자격을 갖춘 사람이라면 템플릿 없이 영어로 두어 문장을 쓸 수 있어야 한다.필 브리저 (대화) 19:22, 2019년 7월 22일 (UTC)[응답]

나는 동의할 마음이 있다.만약 당신이 사과를 정당화할 만큼 충분한 실수를 했다면, 나는 단지 템플릿 하나를 받았다면 감명받지 않을 것이다.콧수염 (토크) 20:58, 2019년 7월 22일 (UTC)[응답]

@노세백곰과 필 브리저:나는 임파서블위저드가 여기서 템플릿을 언급하고 있다고 생각하지 않는다.이것은 맞춤형 메시지가 필요한 Banstars와 더 유사해 보인다.@ImmortalWizard: 당신은 이론적으로 사용자에게 새끼 고양이, 염소, 또는 맞춤식 옵션을 줌으로써 당신의 제안을 이미 제정할 수 있었다.나는 많은 사용자들이 미안하다는 뜻으로 이미 새끼 고양이를 보낸다는 것을 안다.하지만, 우리는 음식과 음료 코너에 "사과 케이크"와 같은 것을 추가할 수 있다.미안하다고 말하는 케이크의 좋은 사진을 찍어야 하지만, 아마 더 잘 할 수 있을 거야.또한 음식들 중 가장 먼저 목록에 오른 바클라바를 추월할 것이다.그것에 대해 희비가 엇갈리지만. –MJL ^☖▲토크 18:05, 2019년 7월 31일 (UTC)[응답]

사과 IMHO는 예쁜 꽃과 화려한 색깔 등을 필요로 하지 않는다 - 단순한 흑백 사과만으로도 충분하다.–Davey2010^Talk 18:30, 2019년 7월 31일 (UTC)[응답]

2607:fb90::/32에 대해 어떻게 해야 하는가?

워, 이 범위는 수십억 명의 T-Mobile 사용자들에게 영향을 미치고 있다.블록이 너무 길어서 어떡하지?줄여야 하나, 연장해야 하나.2600:1702:38D0:E70:B4CD:9550:507:3ED1 (토크) 18:12, 2019년 8월 2일 (UTC)[응답]

제안 - 기사 간략한 설명을 사용한 통합 색인, 용어집 및 범주

배경...
새로 구성된 WP와의 협력:위키프로젝트 기후변화 나는 그 때 장기간의 유지 두통에 부딪쳤다.

• 기후변화 기사 지수 대
• 기후변화의 용어집 대
• 범주/기후 변화

매우 피상적으로 주위를 둘러보면 다른 과목의 중복이 유사하다는 것을 알 수 있다.

이는 다음과 같은 문제를 시사한다.
A. 겹치는 부분이 너무 많지만, 서로 간의 동시성이 충분하지 않다.

• 주제별 기사 분류
• 주제 기사 색인
• 주제 용어 해설

B. 위의 세 개의 총알은 세 개의 서로 다른 수동 편집이 필요하다(현재 문제에 관여하지 않지만 해결책의 일부인 네 번째 편집본이 있으며, 그것은 각 기사에 간단한 설명을 추가하고 있다).

C. 내가 살펴본 모든 용어집 WP:검증. 왜냐하면 인용문이 있을 경우 몇 가지 인용문만 있기 때문이다.

제안된 유니파이드 솔루션
1. 편집자가 인덱스의 항목이 적절히 분류되었는지 확인할 수 있는 시간 창을 제공하고, 시간이 지나면 분류에 따라 모든 수동 인덱스를 봇 생성 인덱스로 자동 교체(인덱스가 처음부터 중복되지 않는다고 가정)

2. 용어집만 빼고 1과 같다.분류 확인 외에도 각 기사의 짧은 설명이 간단한 용어 설명으로 적합한지 확인하십시오.

3. 봇이 용어집을 자동생성할 때, 위를 보고 템플릿의 짧은 설명을 복사한다:짧은 설명

장점...

• 용어집 + 색인 + 카테고리 + 간단한 설명을 만드는 네 가지 단계 대신 두 가지 단계만 있으며, 카테고리에 대한 기사를 태그하고 간단한 설명을 추가한다.
• 색인, 용어집 및 범주 항목 사이에 자동으로 1:1:1 관계가 설정됨
• 용어집은 여전히 참고 문헌을 가지고 있지 않지만, 글들이 훨씬 더 많은 관찰자를 가지고 있는 반면, 용어집은 동료 검토가 거의 없이 지어질 가능성이 있다.아마도 다른 ED들로부터 안전 점검이 증가했기 때문에 짧은 설명이 더 정확할 것이다.
• 기사 짧은 설명과 용어집 텍스트는 자동으로 동기화 상태를 유지한다.
• 편집자에게 주어진 주제 영역에 있는 모든 기사가 짧은 설명(템플릿 설명서에 포함된 목표)이 양호한지 확인하도록 촉구
• 구현 후에는 간단한 설명과 범주 태그만 추가하면 이 모든 것이 처리되는 반면, 봇은 4가지 도구(인덱스, 용어집, 고양이, 짧은 설명) 모두 동기화 상태를 유지한다.아주 간단하다.

댓글, 질문, 토론?NewsAndEventsGuy (talk) 02:48, 2019년 8월 1일 (UTC)[응답]

토론

• 프로포즈로 지원NewsAndEventsGuy (토크) 02:48, 2019년 8월 1일 (UTC)[응답]
• 나는 이것이 많은 분야에서 효과가 있을 것이라고 생각하지 않는다.우리는 용어집과 색인 기사가 상대적으로 적으며, 두 가지 모두를 다루는 영역은 여전히 적으며, 우리가 기사를 쓰는 곳은 종종 몇 가지 범주에 걸쳐 분산될 것이며, 대부분의 색인 기사들이 용어집에 있어서는 안 된다.따라서 "지수, 용어집, 범주 항목 사이에 자동적으로 1:1:1 관계가 있게 될 것"이라고 해서 반드시 좋은 것으로 생각되는 것은 아니다.색인이나 용어집 기사 모두 내가 일하는 분야에서는 오히려 소홀히 취급되고, 별로 보지 않는다.다른 곳에서는 다를 수도 있다(사실 어떤 것을 보면, 나는 어떤 용어집에서는 괜찮은 견해를 본다.존보드 (대화) 03:17, 2019년 8월 1일 (UTC)[응답]

코멘트를 해줘서 고마워, 그런 것들은 쉽게 극복될 수 있을 것 같아.

첫 번째 요점은, 예시 없이, 우리는 추측하고 있다.기후 변화 주체를 구문 분석하여 여러 하위 캐트로 나눌 수 있지만, 여전히 어머니 범주인 "기후 변화"가 있다.나는 지수나 용어집 둘 중 하나를 가질 수 있을 만큼 충분히 한 가지인 과목에 모든 것을 잡아내는 비슷한 모든 종류의 슈퍼 카테고리가 없다는 것을 믿기가 힘들다.그것은 반드시 존재해야 하며, 따라서 미래 봇 생성 지수 또는 용어집들은 그 슈퍼 범주에 기초할 수 있다.당신은 이 가정을 반증하는 타당하지 않은 예를 찾을 수 있는가?

두 번째 포인트(지수 항목이 용어집 엔트리가 되어서는 안 될 수도 있음)가 좋은 포인트다.인덱스와 용어집을 모두 갖춘 피험자의 경우, 우리는 인덱스와 용어집이 의도적인 불일치를 가지도록 편집자들이 생각하고 올바른 버튼을 누르게 한다.다음 편집자는 첫 번째 편집자의 사고 기록이 없기 때문에 그 불일치를 유지하지 못할 수 있다.vaila! 봇이 용어집이나 색인을 실행할 때 포함을 억제하기 위해 슈퍼카테고리 템플릿에 대한 매개 변수를 추가하기만 하면 된다.그러면 편집자들은 여전히 그 결과를 얻기 위해 올바른 생각을 하고 버튼을 누를 수 있고, 우리는 여전히 내가 설명한 장점을 누릴 수 있고, 미래의 편집자들은 용어집 포함을 억제하기 위한 첫 번째 편집자의 작업에 대한 기록을 보게 될 것이다.

NewsAndEventsGuy (talk) 03:30, 2019년 8월 1일 (UTC)[응답]

• 나는 이 제안을 충분히 고려할 시간이 없었고, 아마도 며칠 동안은 아닐 것이다. 그러나 일반적으로 나는 지수, 카테고리, 용어집 사이의 중복이 더 많은 고려가 필요한 것이라는 것에 동의한다.이 페이지들은 다른 많은 페이지들의 특징과 목적을 복제하는데, 이것은 사물이 매우 빨리 동기화되지 않고 세트로서 유지되기 어렵다는 것을 의미하기 때문에 이상적이지 않다.얼핏 보면 1을 좋아하고 2와 3에 대해 확신이 서지 않지만(대부분 짧은 서술이 그것에 대해 믿을 수 있을지 확신하지 못하기 때문) 좀 더 생각해 보겠다.Wug·a·po·des 03:47, 2019년 8월 1일(UTC)[응답]

그렇다, 현재 대부분 헌신적인 비전문가에 의해 쓰여진 짧은 서술일 뿐만 아니라, 그것들은 용어집에서 사용하기에는 거의 항상 너무 짧고 모호하며 서술적이지 않다.아이디어를 범주에서 인덱스를 자동 컴파일하는 것으로 제한하는 것은 더 간단해야 하며 경우에 따라서는 좋은 생각이 될 수도 있지만, 나는 그것이 매우 유용하기에는 너무 많은 시간이 걸릴 수 있다고 의심한다.존보드 (대화) 11시 2분, 2019년 8월 1일 (UTC)[응답]

프로포져가 말하길...현재의 관행은 현재의 관행을 개혁하는 데 장애가 되지 않기 때문에 그것은 순환논쟁의 일종이다.짧은 설명과 용어집 둘 다 불충분하게 조사되었다 - 충분한 안구, 충분한 출처 확인.물론, 이 제안은 간단한 설명에 대한 단어 선택을 바꿀 것이다.그것은 또한 용어집과 짧은 서술 모두에 대한 주의와 관심을 증가시킬 것이며, 이것은 양쪽 모두에게 좋은 일일 것이다.NewsAndEventsGuy (talk) 11:47, 2019년 8월 1일 (UTC)[응답]

그래, 그래서 기본적으로 당신은 비교적 전문화된 편집자들이 해야 하는 엄청난 양의 작업을 제안하고 있어. 소수의 사람들이 보는 기사에 대해서 말이야.인덱스 기사를 몇 개 더 보면, 꽤 높은 비율을 드래프트 공간이나 사용자 공간으로 옮겨야 유용한 완성도를 얻을 수 있다고 생각한다(자동화 또는 기타).2월 17일에 마지막으로 편집된 르네상스 시대의 완전히 쓸모없는 기사들을 보라. 그리고 약 1%가 완성되었다.하지만 나는 이제 입을 다물고 다른 사람들이 어떻게 생각하는지 볼 것이다.존보드 (대화) 21:19, 2019년 8월 1일 (UTC)[응답]

우리의 인덱스 기사는 현재 상태로는 쓸모가 없을 뿐만 아니라 (르네상스 기사 지수는 35개의 기사만으로 특히 나쁘다 – WP:PETSCAN은 다음 범주에서 461개의 기사를 찾아냈다.르네상스나 즉석 서브캣의 하나, 또는 3개 범주로 내려가면 거의 만 개에 가까운 기사) 그러나 그 요점이 무엇인지도 알 수 없고, WP도:Indexes 또는 WP:WPINDEXES는 계몽적이다.카테고리나 개요는 적어도 계층 구조는 있어서 항해에 도움이 된다; 나는 내가 알파벳순으로 특정 주제에 관한 기사를 찾을 이유가 전혀 생각나지 않는다.Caeciliusinhorto (talk) 22:01, 2019년 8월 2일 (UTC)[응답]

• 일부 생각은 다음과 같다.
  1. 한편으로, 편집자와 사용자 모두 우리의 현재 가장 좋은 도구인 하이퍼링크, 네비박스, 그리고 카테고리 시스템이 실패하는 관련 주제를 찾기 위해 색인이나 포털과 같은 것이 필요하다.부지런히 검색해도 내가 작업하는 것과 관련된 기존 기사를 발견하지 못한 적이 여러 번 있었다.
  2. 반면 지수/포털/아웃라인/목록은 자동화가 아닌 수작업이기 때문에 실패한다.그 페이지들 중 하나를 편집하는 것은 지루하고 오류가 발생하기 쉬운 많은 작업이다.그러면 그것들은 유지되고 최신 상태로 유지되어야 한다; 사람들은 종종 예고 없이 위키피디아에 기고하는 것을 중단하는 것으로 알려져 왔다.
  3. 그러나 우리가 피험자에게 어떤 자동화된 도구를 만들 때 까지 -- Wikidata에서 정보를 적용할 수 있는 수단이나, 거기서 어떤 종류의 감시를 유지한 채, 또는 그곳에 있는 사실을 쉽게 수정할 수 있는 능력을 말할 때까지 -- 우리는 우리가 가지고 있는 것에 얽매여 있다. (그렇다, 우리는 WMF가 그러한 어플리케이션에 자금을 지원한다고 주장할 수도 있지만, 나는 그들이 그것을 제공하기를 기다려 왔다.위키백과 템플릿에 대한 포괄적인 안내서, 그리고 내가 처음 제안한 지 적어도 10년이 되었다.) -- (대화) 19:47, 2019년 8월 2일 (UTC)[응답]
• 이런 식으로 짧은 설명을 사용하면 안 된다.짧은 설명은 모바일 기기 등을 대상으로 하기 때문에 40자 미만으로 짧게 유지한다.이 요구사항은 이 제안에서와 같이 다른 영역에서의 사용을 제한한다. 즉, 그들은 적절한 문법, 과도한 일반화 등과 같은 일반적인 백과사전적 사용을 위반할 수 있다(그리고 종종 그렇게 한다).더 나쁜 것은, 짧은 설명을 위해 여러 개의 상충되는 미션을 갖는 것은 의도된 주요 목적에 덜 유용하도록 그것들을 바꾸도록 장려한다.만약 우리가 이 제안에서와 같이 좀 더 일반적인 목적을 위해 새로운 "짧은 설명 방식" 시스템을 시작하고 싶다면, 괜찮다. 만약 그것이 가능하다면, 우리는 심지어 하나의 시스템이 다른 시스템이 제공하는 설명을 사용하는 것을 허용할 수도 있다.(아마 현재의 짧은 서술은 좀 더 좁은 목적을 강조하기 위해 모바일 서술로 이름이 바뀌어야 할까?) (그리고 그렇다, 나는 현재의 짧은 서술이 짧지 않다는 것을 알고 있다; 그것은 들끓는 문제를 가진 매우 새로운 시스템이지만, 우리는 이것이 해결될 것이라고 가정해야 한다.Wikipedia_talk를 참조하십시오.단축_설명#_a_short_description_define_or_distanguish?) --A D Mono III^(talk) 16:27, 2019년 8월 3일 (UTC)[응답]
• 링크된 오픈 데이터 리포지토리와 그것으로부터 위키피디아 페이지를 만드는 도구가 있다면.오, 잠깐, 우리: 위키백과:리스테리아.Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 17:46, 2019년 8월 3일 (UTC)[응답]

여러 문제

나는 하나의 상위 기사 문제 템플릿만 있는 기사에서 주기적으로 {{여러 이슈}를 본다. 예: 핫 기사 또는 비 기사 수정본을 참조한다.이러한 상황에서 봇이 돌아다니며 이 템플릿을 제거하도록 하는 것이 가치가 있을까? 현재 일회성 실행과 향후 정기적인 실행 둘 다?정리 템플릿의 요점은 문제의 문제에 주의를 끄는 것이지만, {{복수 이슈}}은 그렇게 하지 않는다 — 물론 문제가 많으면 괜찮지만, 한 문제만 있어도 템플릿이 특별히 도움이 되지 않으며, 또한 독자들에게는 "이것은 여러 문제가 있다"고 말하고 나서 하나만 주는 것은 다소 바보같이 보인다."기사에 또 무슨 문제가 있나?"라고 생각할 수도 있다.기술적 관점에서, 이것은 매우 쉬워야 한다: 이 템플릿을 초월하는 모든 페이지의 목록을 얻고, 각각의 페이지를 확인하고, 하나 또는 제로 정리 템플릿을 포함하면 템플릿을 제거하고, 둘 이상의 템플릿을 포함하면 템플릿을 건드리지 않는다.나이튼드 (대화) 22:44, 2019년 7월 22일 (UTC)[응답]

아마도 {{여러가지 이슈}}}이(가) 2개 이하인지 감지할 수 있도록 조금 더 영리하게 만들 수 있고, 아무것도 표시되지 않고, 디스플레이가 있다면 {{여러가지 이슈}에 포장되지 않은 것처럼 표시할 수 있을까?나는 이것이 우리의 많은 루아 전문가들 중 한 명이 실행하기에 그리 어렵지 않을 것이라고 확신한다.필 브리저 (대화) 17:54, 2019년 7월 23일 (UTC)[응답]

이 문제의 가장 빈번한 원인은 원래 적절한 다중 이슈 템플릿이 있는 페이지가 일부 이슈를 제거했기 때문일 것이다.나는 이것을 수백 번 했지만, 여러 개의 템플릿도 제거하기 위해 한두 번밖에 생각하지 않았다.문제가 있다는 걸 알았으니, 이렇게 하겠지만, 프로그램을 통해 하는 게 더 실용적일 거야. DGG (토크 ) 17:02, 2019년 7월 26일 (UTC)[응답]

이슈가 하나뿐일 때 없는 것처럼 행동하는 똑똑한 {{여러가지 이슈}가 내가 느끼는 최고일 것이다.그렇지 않은 경우, WP:BOTREQ가 실행될 수 있다.헤드폭탄 {t · c · p · b} 21:09, 2019년 7월 26일 (UTC)[응답]

내가 여기 루아 모듈 프로토타입을 만들었어. 모듈:샌드박스/마리오곰/여러 문제.이 작업에는 두 가지 매개 변수가 필요하다.첫 번째 파라미터에 템플릿이 하나 또는 아예 없는 경우 첫 번째 파라미터가 반환된다.그렇지 않으면 두 번째를 돌려주게 되는데, 이것은 포장된 버전이 될 것이다.이 프로토타입을 정식 템플릿 버전으로 만들어 볼게.템플릿에서 생성해야 하는 경우:여러 문제/샌드박스 또는 다른 곳?베스트, --MarioGom (talk) 23:42, 2019년 7월 26일 (UTC)[응답]

필 브리저, DGG, 헤드밤, 마리오곰이 만든 모듈에 대해 어떻게 생각하십니까?며칠이나 늦어서 미안해. 템플릿이 중복되지 않은 경우를 또 제거하고 나서 생각났어.나이튼드 (대화) 12시 2분, 2019년 8월 3일 (UTC)[응답]

불행히도, 여기서 마리오곰이 취한 접근법은 실제로 효과가 없다. 왜냐하면 루아 모듈은 입력 후-템플릿-팽창으로 인해 확인할 곱슬 교정기를 보지 못하기 때문이다.* Papery _{it has begun...}* 14:19, 2019년 8월 3일 (UTC)[응답]

:-(그렇다면 봇 의뢰가 필요한 시점인가?나이튼드 (대화) 19:06, 2019년 8월 3일 (UTC)[응답]

위키백과 라이브러리에 등록된 편집자 공개

철자가 틀린 파일 이름

파일:내 피는 비행기들로 가득 차있어. 파일대신 jpg:내 피는 aiplanes.jpg로 가득 차 있다.리디렉션을 사용하여 파일을 올바른 이름으로 이동하고 리디렉션을 {{R 타이포}}(으)로 표시하십시오.— Monniasza (대화 • 기여) 11:32, 2019년 8월 11일 (UTC)[응답]에 의해 추가된 이전의 서명되지 않은 논평

@몬니아사: 완료. 다음에는 {{rename media}}을(를) 사용하여 파일 이동을 요청하십시오. --AntiCompositeNumber (talk) 11:40, 2019년 8월 11일(UTC)[응답]

내 호버크래프트는 장어로 가득하다. --Redrose64 🌹 (토크) 16:42, 2019년 8월 11일 (UTC)[응답]

재량 제재 통지 결합

어떤 기사는 여러 가지 이유가 적용될 때, 그들의 대화 페이지에 다재다능한 제재 고지를 남기기도 한다.토크:2019 데이튼 촬영은 지저분하고 혼란스럽고 읽기 어려운 결과의 한 예다.나는 그것들을 결합하는 것을 제안할 것이다.하나 이상의 이유가 있는 단일 템플릿을 사용하는 것처럼 템플릿:여러 가지 문제가 작용한다.사쿠라 (토크) 19:23, 2019년 8월 10일 (UTC)[응답]

이들 중 일부는 템플릿과 같은 구체적인 제재 조치를 취하고 있다.ArbCom 아랍-이스라엘 집행.한 페이지에 여러 개가 있는 것이 뭐가 헷갈릴지 모르겠다. --Doug Weller talk 18:10, 2019년 8월 11일 (UTC) repreping @Sakkura: --Doug Weller talk 18:12, 2019년 8월 11일 (UTC)[응답]

여러 개의 위키백과 주제가 나쁘지 않을 때 우리가 가지고 있는 컨테이너 박스는 "이 기사는 다재량 제재 대상:"으로 이어질 수 있고 각 고지를 포함할 수 있다. --Masem (t) 18:14, 2019년 8월 11일 (UTC)[응답]

DS 토크 페이지 배너는 어쨌든 기술적으로 쓸모가 없다.WP:Discastary_sanctions#Awaency_and_alerts에 따르면 편집자는 기술적으로 "인식" DS가 적용되는 경우에만 DS에 따라 제재를 받을 수 있으며, 다양한 기준에 따라 기술적 인식이 정의된다.토크 페이지 DS 템플릿 배너가 있는 기사에서 작업하는 것은 그 중 하나가 아니다.따라서 실제로는 이러한 것들은 전적으로 FYI이지만 현재의 DS 절차를 적용하기 위해서는 그 존재 자체가 문제가 되지 않으며 따라서 광택과 형태와 내용이 있다.언급된 모든 내용은 다음과 같이 수정 지원.만약 무트가 있지만 FYI 템플릿 텍스트가 있다면, 그것은 그 텍스트를 보기 위해 링크를 클릭할 수 있는 종류의 사람이다.그래서 나는 동의한다, 각 주제에 대한 세부사항을 팝업할 수 있는 링크와 함께 주제를 나열하는 간단한 배너셸이 있으면 좋겠다.하지만, 현실은, 그들이 뭐라고 말하든, 그들이 읽을 사람들이 거의 없다는 것이고, 그렇게 하도록 충분히 신경을 쓰는 사람들이 문제의 근원이 될 것 같지 않다.그러니... 물론이지, 좀 치워줘.하지만 기술적으로나 어느 쪽이든 큰 차이는 없을 겁니다그들은 중요하지 않다.NewsAndEventsGuy (talk) 18:17, 2019년 8월 11일 (UTC)[응답]

편집 내용을 저장하기 전에 끊어진/비정상적인 참조 이름에 대한 경고 추가

참조 이름이 깨진 경우 편집 미리보기 상단에 경고가 있어야 한다고 생각한다.나는 많은 시간을 고장난 참조 이름이 있는 페이지들의 엄청난 뒷줄들을 뒤져보면서 보냈는데, 그 중 많은 페이지들이 누군가가 한 글에서 다른 글로 텍스트를 복사/붙여넣고 부모 참조를 잡는 것을 잊어버릴 때 발생한다는 것을 발견했다.또, 책이나 출판물의 이름을 잘못 <ref name> 매개변수에 넣는 경우도 있다.나는 대부분의 사람들이 편집을 미리 보기만 하면 참조 섹션을 더블 체크하기 위해 페이지 하단으로 스크롤하지 않고, 이것이 문제를 해결할 수 있다고 생각한다.편집자가 이 경우 부모 참조를 찾는 데는 한두 분밖에 걸리지 않는 반면, 1년 후 다른 사람이 참조를 찾아내야 할 때는 시간이 오래 걸릴 수 있다.이게 내가 여기에 대해 게시해야 할 것인지 아니면 페이브리케이터에 게시해야 할 것인지 잘 모르겠으니, 더 좋은 방법이 있다면 알려줘.세쿤더스 제피루스 (대화) 19:29, 2019년 7월 24일 (UTC)[응답]

경고는 아주 좋은 생각일 것이다.이것은 몇 년 동안 문제였고 약간의 진전이 있었다.아노미비OT의 OpianReferenceFixer는 이러한 오류들 중 많은 부분을 해결하는데 성공한다. 그렇지 않으면 우리는 침수될 것이다.여기 로그를 참조하십시오.한동안 또 다른 봇인 ReferenceBot이 있었는데, 이 봇은 AnomieB의 오류에 대한 메시지를 편집자의 토크 페이지에 남길 것이다.OT는 고칠 수 없었다.하지만 2017년 2월 이후 운영되지 않고 있다.스타리그랑마(토크) 04:15, 2019년 7월 25일 (UTC)[응답하라]

+1헤드폭탄 {t · c · p · b} 04:32, 2019년 7월 25일(UTC)[응답]

이것은 큰 발전이 될 것이다.필요한 곳에 <ref name>의 끝에 성가신 "/"를 포함하지 못하는 경우를 자동으로 감지하는 것도 도움이 될 것이다.롭듀치(토크·컨텐츠) 07:01, 2019년 7월 25일 (UTC)[응답]

동의함. 특히 섹션 편집(모든 참조가 표시되는 전체 페이지가 아님) 및 참조가 고아가 될 수 있는 다른 섹션의 확인을 잊어버릴 때 중요하다.ComplexRational (대화) 19:42, 2019년 7월 29일 (UTC)[응답]

콤플렉스라이언스, 그런 가능성은 생각도 못했는데, 정말 좋은 지적이야. --Secundus Zephyrus (대화) 20:29, 2019년 7월 29일 (UTC)[응답]

위의 모든 훌륭한 아이디어들.기술적 배경을 가진 사람이 미리보기 창 위의 경고가 어떻게 루아에서 생성되는지 알고 있는가? --헤카토 (대화) 10:23, 2019년 7월 25일 (UTC)[응답]

• 흠, 이 상황에서 3,000개 이상의 기사가 실렸다.내 활동에서 시간을 좀 더 벌어야 할 것 같아. --사용자:씨요키(말씀) 21:57, 2019년 7월 30일 (UTC)[응답]
• 네.나조차도 이것에 대해 유죄라는 것을 인정한다.돈을 더 내려고 했는데, 그냥 너무 많아.그 범주는 매우 크다. –MJL ▲Talk ^☖▲ 18:07, 2019년 7월 31일 (UTC)[응답]

  나는 또한 WP의 일반적인 오류를 고치려는 사람들에 대한 조치를 보고 싶다.LDR. –MJL ▲Talk ^☖– 18:13, 2019년 7월 31일(UTC)[응답]

• 강력히 지지하다.너무 많은 편집자들이 정의되지 않은 참조를 추가하는 것에 대해 유죄 판결을 받았다.던컨힐 (대화) 18:16, 2019년 7월 31일 (UTC)[응답]
• 지원 - 완료 후 항상 ref를 확인하지만 1% 소수인 것으로 가정:P, –Davey2010^Talk 18:27, 2019년 7월 31일(UTC)[응답]
• 제안대로 반대하다.아이디어는 좋지만, 만약 페이지가 이미 깨진 참조를 가지고 있다면, 이것은 새로운 기사들과 경험 많은 편집자들의 좋은 몫을 혼란스럽게 할 것이다.오류가 새로운 경우에만 경고를 표시할 수 있는 방법이 있다면(즉, 편집 전에는 경고가 없었지만 미리 보기된 콘텐츠에는 경고가 있을 것이다), 나는 기꺼이 그것을 지지할 것이다.나이튼드(토크) 19:10, 2019년 8월 3일 (UTC)[응답]

니튼드, 좋은 지적이야신인들과 경험 많은 편집자들 사이에서 균형을 잡을 수 있는 덜 과장되게 표현될 수 있을까?내가 묻는 이유는 수년 전 깨진 참고문헌이 있는 페이지를 우연히 발견했기 때문인데, 경험이 풍부한 편집자가 오래된 오류에 대한 통지를 받았다면 시간이 있으면 고치려고 할 가능성이 더 높다고 생각한다. --Secundus Zephyrus (대화) 18:55, 2019년 8월 11일 (UTC)[응답]

CentralNotice를 사용하여 사진 공모전 홍보 제안

메타에는 이전과 같이 위키 사랑 기념비 사진 콘테스트를 홍보하기 위해 9월 1일부터 9월 30일까지 위키백과와 다른 위키미디어 프로젝트에 CentralNotice 배너를 운영하자는 공개 제안이 있다.제안서는 m:CentralNotice/Request/Wiki Loves Monuments 2019에서 코멘트를 하십시오. --Airland (talk) 06:10, 2019년 8월 14일 (UTC)[응답]

시민 교구 봇

나는 위키피디아에서 토론을 시작했다.봇의 요청 #시민교구 봇에게 영국에서 사라진 시민 교구(약 700개)를 만들어 달라고 요청하지만, 몇 가지 문제, 즉 내 지시가 충분히 명확하지 않다는 것, 그것이 나의 창작 제한을 위반하는 것일 것이라는 것(그렇지 않다), 그리고 그들이 주목할 수 없을지도 모른다는 것(그렇지 않다, 교회 교구와는 반대로 시민 교구는 합법적인 것이다.WP당 인정된 행정 구역:GEOLAND).

사용자 작성:Crouch, Swale/Bot 작업/Civil Pishes(현재 모델)/간단한 현재 모델도 User:Crouch, Swale/Bot 작업/Civil Parish(현재)/Coded 및 User:사용자에서 봇에 대한 반대 의견과 더 많은 지침을 제공하는 Crouch, Swale/Bot 작업/Civil Pishes(현재):Crouch, Swale/Bot 작업/시민 도시(현재)#프로세스.

여기에는 이러한 봇을 프로그래밍할 수 있는 이해관계가 있는 두 가지 질문이 있으며, 이것이 올바르게 작동하는지 또는 다른 방법으로 기사를 개선하기 위해 개선/변경해야 할 다른 사항이 있는가?

우리가 결국 다른 나라에서도 같은 일을 할 수 있다면 좋겠지만 일단 영국부터 시작하자.크라우치, 스와일 (대화) 12시 2분, 2019년 8월 5일 (UTC)[응답]

WP에 전화한다.이것에 관한 다른 부모: 비록 Crouch, Swale은 위키피디아를 연결했다.봇의 요청 #시민 교구 봇은 위키피디아 토크와 같이 그들이 요청한 다른 장소들을 연결하지 못한다.위키프로젝트 영국/아카이브 4#Bot이 기사를 만들었다. --Redrose64 🌹 (토크) 20:53, 2019년 8월 5일 (UTC)[응답]

그다지 좋지 않은 WP:포룸샵은 "무엇을 하고 싶지만 무엇을 해야 할지 모르기 때문에 모든 것을 시도해보고 무엇인가 고착되는지를 보는 것" 이상의 의미를 갖는다.진실은, 특히 명확한 예가 없기 때문에, 봇 논리가 명확하기 때문에, 아무도 이것에 관심을 보이지 않는 것 같다.그리고 그것들이 들어설 때까지, 이자는 낮게 유지될 것이다.헤드폭탄 {t · c · p · b} 03:19, 2019년 8월 6일 (UTC)[응답]

• 코멘트 나는 이것이 세계에서 가장 필요한 봇이라고 확신할 수 없지만(예를 들어 나는 미국의 카운티들이 봇에 의해 만들어졌다고 믿지 않는다), 그리고 만약 모든 꼬인 것들이 해결된다면 원칙에 따라 완강히 반대하지도 않는다.– John M Wolfson (대화 • 기여) 00:34, 2019년 8월 7일 (UTC)[응답]

• 미국의 카운티들은 정착지와 같은 방식으로 만들어지지 않았더라면, 램맨은 나중에야 봇에 대한 별도의 계정을 갖지 못한 것으로 보인다[4][5].어쨌든, 우리가 그것이 괜찮다고 확신하기 전까지는 봇이 승인되어서는 안 된다.크라우치, 스와일 (대화) 17:15, 2019년 8월 8일 (UTC)[응답]

• 내 지시대로라면 누구라도 봇을 위한 코드를 만들 능력이 있는가?만약 그렇게 될 수 있다면, 우리는 공감대가 있는지 제대로 된 방향으로 가고 있을 것이다.크라우치, 스와일 (대화) 08:00, 2019년 8월 10일 (UTC)[응답]

  BON에게 알려줬어.크라우치, 스와일 (대화) 11시 7분, 2019년 8월 13일 (UTC)[응답]

  @Crouch, Swale: 그런 봇을 부호화할 수 있을지도 모르지만, 정보가 좀 더 필요해./간단한, /coded 및 (현재)는 혼란스럽다.당신이 만들어 줄 수 있는가: 완전한 예시 기사 1개(봇이 생산할 수 있어야 하는 것)와 모든 기사에 공통적인 내용을 담은 1개의 "껍질"을?(모든 사람이 다 가질 것처럼)== References ==및 {{Reflist}} 대니S712 (대화) 11:13, 2019년 8월 13일 (UTC)[응답]

  @DannyS712: 사용자:Crouch, Swale/CP의 예로서, "완전한 기초 기사"를 예로 들 수 있다(분명히 범주가 비활성화되지는 않을 것이다).사용자:Crouch, Swale/Bot 작업/Civil Pishes(현재)/코드화된 예제 "에 없는 단어"는 모든 기사에 공통적인 내용이다.즉, 모든 기사에는 '교구적 접촉'이라는 텍스트가 붙겠지만, 파리의 이름은 가변적일 것이다.주어진 예(Rattlesden)는 이미 존재하지만 그것이 존재하지 않는다면 어떻게 생성될 것인가를 보여준다.코드화된 노트에서 노트를 제거했지만 봇 운영자에게 유용할 것이라는 점에 유의하십시오.크라우치, 스와일 (대화) 11시 35분, 2019년 8월 13일 (UTC)[응답]

  @Crouch, Swale:좋아. 그래서 나는 그것을 다음과 같은 매개변수가 필요한 껍데기로 본다.

  1. 이름(해부되지 않음)
  2. 지역
  3. 도시 인구의 중심점
  4. 지구명
  5. 군명
  6. 인구
  7. 면적
  8. 구(區) 이름(해제 포함)
  9. 감동적인 도시들
  10. 상장건물수

  각 기사에 대해 해당 기사의 제목이 있어야 한다.모든 정보가 사용 가능한 형식으로 검색될 수 있는 한, 꽤 간단해 보인다.그 자료를 얻을 수 있는 좋은 방법이 있니?만약 그렇다면, 나는 봇 요청을 기꺼이 이행할 것이다. 만약 그것에 대한 진정한 합의가 있다면.대니S712 (대화) 11:58, 2019년 8월 13일 (UTC)[응답]

  @DannyS712: 사용자:크라우치, 스웨일/봇 작업/시민 도시(현재)/간단하지만 여기에 조금 더 추가하겠다.

• 이름(해부되지 않음)

  만약 타이틀이 모호하지 않다면, 이것은 타이틀과 같을 것이다 (래틀즈든 예와 같을 것이다), 타이틀이 모호해졌을 때 (박스포드, 서퍽과 같은) 그러면 그것은 "공식_이름" "civil_parish"와 처음부터 대담한 얼굴에서 제거될 필요가 있을 것이다.다시 말해, 박스포드의 경우, 서퍽의 예시 3가지는 모두 시티포드에 사용된 이름을 말하는 "박스포드, 서퍽"이 아니라 "박스포드"일 것이다.

• 지역

  "East of England" 또는 "North East"와 같이 infobox에 연결되지 않은 City Popular에 지정된 지역 이름.

• 도시 인구의 중심점

  이것은 도시 인구에서 교구를 위해 주어진 지역의 중간(중심) 지점이며, 만약 봇이 그것을 얻는 것이 불가능하다면, Ordnance Survey 링크된 데이터의 좌표를 사용할 수 있다.이것은 또한 카운티 타운으로부터의 거리를 측정하는 데에도 사용된다.

• 지구명

  Babergh(및 범주:Babergh) 혼란스럽지 않은 경우 Arun(및 범주:아룬 구(Arun District) 또는 스태포드(및 카테고리:스태포드 자치구라면.또한 단일 군부의 권위인지 기억한다.

• 군명

  따라서 올니의 경우 밀턴 케인스가 아닌 버킹햄셔 주의 의례적인 카운티.

• 인구

  도시 인구가 데이터를 주지 않을 경우(주로 100명 미만의 파리에 대해) 생략하는 2011년 도시 인구가 제시한 수치도 "2011년에는 교구의 인구가 X명이었다"는 문장이 삭제된 점에 주목한다.

• 면적

  도시 인구에서 항목을 클릭하면 해당 지역(래틀즈덴의 경우 13.2)이 표시된다.이것은 인포박스에만 추가된다.

• 구(區) 이름(해제 포함)

  위의 구명과 마찬가지로, 구(區) 기사(및/또는 범주)가 위에서 설명한 대로 훼손될 수 있다는 뜻이며, 만약 해당 기사라면 설명된 대로 텍스트로 파이핑할 필요가 있다.

• 감동적인 도시들

  교구가 건드리는 다른 교구의 이름(이름도 없어질 수 있음)은 봇이 대상 기사의 좌표를 확인하거나 내가 고칠 수 있는 자격 없는 이름만 연결시킬 수 없다면 올바른 기사의 내용을 풀어낸다.

• 상장건물수

  목록에 있는 건물지에서(영국의 유산지가 더 나은 선택일 수 있지만 나중에 논의할 수 있다) 즉, 지역별로 교구를 찾음으로써 군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/군/구크라우치, 스와일 (대화) 18:56, 2019년 8월 13일 (UTC)[응답]

  @Crouch, Swale: 나는 그들이 무엇을 상징하는지 이해한다.내 질문은 스프레드시트나 모든 해당 데이터가 있는 다른 장소가 있는지입니다.2011년도 수치 등은 수동으로 입력하지 않는 것이 좋다.대니S712 (대화) 03:14, 2019년 8월 14일 (UTC)[응답]

  @DannyS712: 2011년 수치는 모두 지역별, 영국 동부, 웨스트 미드랜드, 사우스 웨스트, 요크셔, 험버, 이스트 미들랜드, 노스 이스트에서 워크턴 25,207과 같은 "인구조사 2011-03-27" 행이다.(Wythop과 같은) 인구 데이터는 없지만 (영역을 클릭하면) 여전히 해당 영역이 있다.크라우치, 스와일 (대화) 07:22, 2019년 8월 14일 (UTC)[응답]

  @Crouch, Swale: 나는 남동부를 위해 사용자:위에 올린 링크의 데이터를 가지고 있는 DannyS712 test/parish.json.근데 생각보다 오래 걸렸어.이것을 도와주길 원한다면 한 장소에 있는 모든 데이터(한 출처의 모집단, 다른 출처의 좌표 등)를 봇(bot-readable) 형식으로 (이상적으로 json). --DannyS712 (talk) 08:59, 2019년 8월 14일 (UTC)[응답]

진행 중인 문제에 대한 토론

안녕하십니까, 홍콩 위기 기사처럼 진행 중인 이슈들의 토크 페이지에서 토론 코너를 제안하고 싶었습니다.이것은 전 세계의 다른 사람들의 견해를 향상시킬 것이고 이것은 이전에 편집을 두려워했던 사람들의 대담성을 장려할 것이고 따라서 위키피디아의 '대담한' 정책의 비전을 실현시킬 것이다.고마워 -RazorTheDJ (대화) 19:45, 2019년 8월 14일 (UTC)[응답]

위키피디아는 포럼이 아니다.토론 코너는 포럼의 문자 그대로의 정의에 가까울 것 같다. --Izno (토크) 03:16, 2019년 8월 15일 (UTC)[응답]

그렇다, 토크 페이지는 토론이나 기사의 주제에 대한 일반적인 토론을 위한 공간이 아니다.단, 그러한 섹션이 서로 다른 편견을 가진 출처의 관점과 기사에 포함되는 가치관을 분석하는 데 전념하는 경우, (토크 페이지 지침에 따라 개인적인 의견에 치우치지 않는 한) 좋은 생각이 될 수 있다.그러한 유형의 토론은 토크 페이지의 성격에 있다.ComplexRational (대화) 09:24, 2019년 8월 15일 (UTC)[응답]

강박적인 자위행위를 기사 스터브로 만들기

강박적 자위행위에는 진단기준이 있어 백과연하다.강제적인 자위행위에 대한 기사를 작성해서 리디렉션을 대신할거야.— Monniasza (대화 • 기여) 17:28, 2019년 8월 14일 (UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평

너 혼자서도 할 수 있어!도움말 참조:조언과 세부사항을 위한 첫 번째 기사.Anomie⚔ 11:14, 2019년 8월 15일 (UTC)[응답]

주 문서 없이 주제 범주에 문서 정리 태그 허용

일부 주제 범주에는 주요 기사가 없다.예를 들어, 기사 다큐멘터리는 다큐멘터리 영화로 리디렉션되며, 따라서 카테고리는 다음과 같다.다큐멘터리는 주요 기사가 없다.대신 범주의 본문은 스텁과 같은 기사 내용을 가지고 있다.특히 편향성명이 있었다.

“

다큐멘터리는 역사가들이 사건의 진실로 받아들일 수 있는 것과 다양한 관계를 가지고 있으며, 대체로 선전일 수도 있다.

”

대부분의 문서에 빛을 비추는 것 - 의도된 것은 아닐지도 모른다.어쨌든 나는 간단히 그 말을 덧붙였다.{{where}}정리 태그해당 태그는 승인되었지만 어떤 정리 범주에도 범주를 추가하지 않았다.내가 제안하는 것은 (대부분의 정리를 위해) 청소하는 방법 때문에 다른 제목이 필요할 수 있다는 것을 이해하지만, 청소하는 방법 때문에 그렇게 해야 한다는 것이다.

대안은 모든 주제 범주에 모든 진술이 적절히 소싱될 수 있는 관련(공유될 가능성이 있는) 기사를 포함하도록 요구하는 것이다.

Dpleibovitz (대화) 21:37, 2019년 8월 20일 (UTC)[응답]

나는 여기의 전제가 혼란스럽다...다큐멘터리 영화는 카테고리의 주요 기사로 간주되지 않을까?블루보아 (대화) 22:00, 2019년 8월 20일 (UTC)[응답]

아니, 그것이 카테고리의 주요 기사일 것이다.다큐멘터리 영화.단, 카테고리:다큐멘터리는 세트 인덱스 기사나 디스패치 페이지처럼 읽힌다 - 많은 종류의 다큐멘터리가 있는데, 영화는 그것들 중 하나일 뿐이다.(모든 종류의 문서들을 위한) 편향과 같은 문제들이 균형 있게 논의되는 별도의 (스텁) 기사가 정말로 있어야 한다 - 카테고리는 그렇게 하기 위한 포럼이 아니다.그럼에도 불구하고, 나는 무엇이 그러한 기사에 들어가야 하는지를 나타내듯이 단순히 불쾌감을 주는 선을 삭제하는 것을 혐오한다.Dpleibovitz (대화) 22:12, 2019년 8월 20일 (UTC)[응답]

• 범주 공간에 기사 정리 태그가 사용되는 경우, 주요 기사가 필요함을 표시해야 할 것 같다.아마 새로운 것을 가질 것이다.{{main article needed for category}}이러한 범주의 맨 위에 배치할 템플릿.이것은 위키피디아에서 또 다른 것일 것이다.분류 § 카테고리 정리 템플릿(실제로 이 목록은 카테고리 페이지가 아닌 아티클용이지만)위키백과:분류는 지나치게 복잡한 (기사 같은) 범주의 문제를 다루지 않는다.Dpleibovitz (대화) 22:49, 2019년 8월 20일 (UTC)[응답]

자매 프로젝트 제안에 대한 감시 목록 메시지

사이트 알림으로 Wikimania 프레젠테이션 비디오

위키마니아의 프레젠테이션 비디오와 연결되는 배너를 세우는 것이 올해 또는 그 이후 해의 가치가 있을까?그렇지 않으면 위키미디어 커뮤니티 활동이 얼마나 광범위한지 모르는 독자들에게 '막후'에서 일어나고 있는 일들을 좀 더 널리 알리는 방법이 될 수 있을 것이다.사람들이 관여하는 것에 대해 생각하도록 자극할 수도 있다.티샤피(Evo&Evo)^talk 02:29, 2019년 8월 21일 (UTC)[응답]

위키마니아 연설을 듣는 것이 뒤에서 일어나는 일을 정확하게 이해하는 좋은 방법이라고 생각하지 않으며, 사이트 공지사항을 이용하는 것도 그런 것을 알리는 좋은 방법이라고 생각하지 않는다. --에어랜드(토크) 05:19, 2019년 8월 21일 (UTC)[응답]

진화와 진화 가능성, 당연히 그렇지 않을 것이다.특히 일부 리서치 세션은 정말로 접근하기 쉬운 버전의 논문으로, 연구 논문 전체를 읽고 싶지 않은 사람들에게는 매우 통찰력이 있어야 한다.—DJ (대화 • 기여) 07:30, 2019년 8월 21일 (UTC)[응답]

자막은 제대로 되어 있는가?출처든 정보원이든 청각장애인이 접근할 수 없는 영상이 점점 더 많이 사용되면서 점점 더 좌절되고 있다. - 시투시(토크) 07:35, 2019년 8월 21일 (UTC)[응답]

@Sitush: 슬프게도, 현재의 자막은 꽤 기초적인 것 같아(유튜브의 기계 번역만 한 것)비디오와 사운드 녹음의 장기적인 품질은 이벤트 이후 비디오와 음원을 가치 있게 만드는 데 큰 도움이 될 뿐만 아니라 wmania:2019:비디오 탐색(관련: meta: meta: 관련: meta:위키프로젝트_원격_이벤트_참여@다니엘 미에첸, 호구-456, 제인023, 푸즈헤도:).만약 WMF가 회의 참석을 할 여유가 없거나 회의장에 비행기를 타지 않기로 선택한 사람들을 위해 원격 참여를 실현하고 싶어하는 것에 대해 진지하게 생각한다면 이것은 특히 중요할 것이다.T.Shafee (Evo&Evo)^talk 07:59, 2019년 8월 21일 (UTC)[응답]

적어도 알려줘서 고마워.YT 기계 번역은 무용지물이나 다름없다. - 시투시(토크) 08:02, 2019년 8월 21일 (UTC)[응답하라]

고마워, 핑거 고마워.아니, 사이트 고지가 로그인한 사용자들에게 다시 전달되지 않는 한 유용하지 않다고 생각한다. 왜냐하면 나는 위키마니아 콘텐츠의 주요 가치를 보다 넓은 독자들의 커뮤니티에 아무 의미도 없는 다양한 중요한 내부 프로젝트에 대한 진행 상태 보고서와 방법이라고 보기 때문이다. 따라서 키노트만이 더 널리 인정받을 것이고 당신은 더 많은 관심을 가질 것이다.사이트 통지에 있는 (또는 관련 WMF 블로그 포스트)만 게시하는 것을 중단한다.나는 사이트 공지가 일시적인 소비를 위한 것이라고 보는 반면, 이러한 중요한 상태 업데이트는 추적되어야 할 "위키피디아 역사"의 중요한 표시들이다.Wikimania 관련 사항( 커먼즈/제출/에더패드/유튜브)을 추적하기 위해서는 별도의 위키베이스가 필요하다고 생각하는데, 이를 위해 "Wiki Loves Wikimania"가 필요할지도 모른다.제인 (토크) 08:26, 2019년 8월 21일 (UTC)[응답]

RfC: 인터페이스에 '기사 만들기' 옵션 추가

새 사용자에 대한 기본 설정 업데이트

나는 편집자 모임에서 새로운 사용자들을 훈련시키는 것을 돕는다.기본 설정 기본 설정은 새로운 사용자에게 적합하지 않다.편집 운동에서 우리는 종종 사람들에게 그것들을 바꾸라고 조언하는 데 몇 분 정도 걸린다.그래서 나는 모든 사람들을 위해 그것들을 바꾸고 싶다. 그것은 많은 사람들에게 시간을 절약해 줄 것이다.나는 Phabricator에서 영어 위키피디아에 "구성 변경"을 요청 할 수 있지만 제안된 변경에 대한 합의가 있다는 것을 보여주어야 한다.몇 년 동안 내가 원했던 두 가지 변경안에 대한 피드백을 부탁한다.

• 편집에서 편집 모드: 새 사용자가 Visual Editor로 빠르게 이동할 수 있도록 "두 편집기 탭 모두 표시"로 기본 설정되어야 한다.우리는 일반적으로 새로운 사용자들에게 즉시 Visual Editor를 사용할 것을 권고한다.그들은 요즘 프로그래머 타입이 될 것 같지 않다.
• 감시 목록에서 아래 네 개의 토글을 기본적으로 즉시 켜야 하며 그렇지 않으면 감시 목록은 자신의 이전 작업에 대한 업데이트를 찾는 데 유용하지 않다.이유는 모르겠지만, 새로운 사용자의 경우 기본적으로 모두 켜져 있는 것은 아니다.
  • 편집하는 페이지 및 파일을 내 감시 목록에 추가
  • 내 감시 목록으로 이동하는 페이지 및 파일
  • 내가 만든 페이지와 내 감시 목록에 업로드하는 파일
  • 내 감시 목록에 업로드하는 새 파일 추가

어떻게 생각하십니까? -- econterms (대화) 14:13, 2019년 8월 16일 (UTC)[응답]

@Whatamidoing (WMF) : 이번 건에 대해서는 이전의 연구/논의가 좀 있을 것 같은데 --Izno (토크) 14:27, 2019년 8월 16일 (UTC)[응답]

@Econterms:나는 너의 요청을 잘 따르지 않고 있어. 나는 단지 옵션을 보기 위해 새로운 테스트 계정을 만들었어.

1. 첫 번째 편집에서 이미 Visual Editor(비주얼 편집기)를 원하는지 묻는 거대한 팝업이 표시되었으며, 이 팝업을 선택하면 기본값이 됨
2. "내가 만든 페이지와 내 감시 목록에 업로드한 파일 추가"는 기본적으로 이미 설정되어 있음
3. "내 감시 목록에 이동 페이지 및 파일 추가"가 기본 설정의 감시 목록 섹션에 없음
4. "내 감시 목록에 업로드하는 새 파일 추가"가 기본 설정의 감시 목록 섹션에 없음
5. "편집한 페이지 및 파일 추가"는 기본적으로 해제되어 있다.

   이것은 "소유"를 저해하고 시간이 지남에 따라 워치리스트가 끔찍하게 커지는 것을 방지하는 것이어야 한다고 생각한다.— Xaosflux^Talk 14:33, 2019년 8월 16일 (UTC)[응답]

   좋아, 이거에 대해 좀 더 말해봐.사용자가 확인/자동 로그온이 확인되면 "내 감시 목록에 업로드하는 새 파일 추가"(기본적으로 설정됨) 및 "내 감시 목록에 이동 중인 페이지 및 파일 추가"(기본적으로 해제됨)에 액세스할 수 있다.— Xaosflux 14:54, 2019년 8월 16일 (UTC)[응답]

• 고마워, Xaosflux.나도 방금 확인했는데 정정했어; 네가 말한 것처럼 그 프리프들 중 오직 두 명만 나타나고 새로운 사용자가 실제로 시각적 편집기에 갈 수 있지만, 그들은 두 편집자를 모두 볼 수 있게 하기 위해서는 어떤 것을 바로 잡아야 해.사용자가 Visual Editor(시각 편집기)에 접속하여 당신이 말한 대로 고정시킬 수 있다는 것을 이해하지만, 나는 기본적으로 두 편집기 탭이 모두 누구에게나 보이는 것을 선호한다.그래서 나는 여전히 그 요청을 하고 싶다.그리고 그 모든 것들이 가능한 한 빨리 감시 목록에 있어야 한다고 생각한다.경험이 풍부한 사용자만이 대형 감시 목록 문제를 가지고 있으며, 문제를 해결할 수 있는 충분한 정보를 가지고 있다.비교적 새로운 사용자들은 그들의 첫 번째 편집이 나타날 때에만 감시 목록 시스템에서 뭔가를 얻지만 종종 그렇지 않다.새로운 사용자가 수정하고 시스템이 제대로 작동한다는 고무적인 느낌을 얻기를 원할 때 즉시 기술적 선호도를 설정하는 데 관여하는 것은 사기를 떨어뜨린다.그래서 나는 여전히 내가 언급했던 대로 이 채무불이행을 조정하기를 원한다.연구해줘서 고마워. -- econterms(토크) 15:18, 2019년 8월 16일 (UTC)[응답]

  탭 단추 추가는 "쉬운" 작업이며 다른 프로젝트(예: w:es:특수:무작위야, 그냥 여기서 합의만 하면 돼— Xaosflux 15:34, 2019년 8월 16일 (UTC)[응답]

두 편집 탭이 모두 즉시 열려야 한다는 데 동의한다(내가 사람들에게 어떤 탭으로 시작하라고 말하는지는 이전 컴퓨터 배경에 따라 다름).우리는 보통 사람들에게 기존의 기사들을 편집하는 것으로 시작하라고 말하므로, 편집된 감시 목록 페이지의 기본값은 켜져 있어야 한다.대부분의 참가자들에게, 불행히도 그들의 감시목록은 혼란스러울 만큼 커지지 않을 것이다. DGG (토크 ) 17:53, 2019년 8월 16일 (UTC)[응답]

나는 "내가 편집한 페이지와 파일 추가"가 기본적으로 켜져 있어야 한다는 것에 확실히 동의한다. 우리 대부분에게 이것은 감시목록이 있는 것의 대부분이고, 그것이 없으면 별로 쓸모가 없다.불행히도 대부분의 새로운 편집자들은 "끔찍한" 감시 목록을 얻을 만큼 오래 머물지 않는다. 그래서 나는 "소유"를 억제하는 것 보다도 그 우려에 감명받지 않는다.존보드(토크) 02:29, 2019년 8월 17일 (UTC)[응답]

안녕, econterms

영어 위키백과 (아마도 100개 정도의 다른 위키백과는?)mw:VisualEditor/Single edit 탭 구성 스타일그러나, 다른 것들과는 달리, 여기서 첫 번째 옵션은 2010 위키텍스트 편집기 입니다.1 대 2 편집 탭을 갖는 것에는 장점과 단점이 있다.일반적으로 말해서, 경험이 부족한 편집자와 무작위 사용자 테스트에서는 시각적 모드에서 시작하는 하나의 탭이 사람들이 원하는 것처럼 보인다.그러나 그것은 압도적인 불가항력은 아니다, 왜냐하면 IP로서 수 년 동안 편집해 왔으며, 이제 계정을 만들기로 했다면, 자신이 익숙한 것과 다른 것을 실제로 보고 싶지는 않기 때문이다.

오랜 경험의 편집자들 사이에서 우리는 2013년에 두 개의 탭이 있는 것에 익숙해졌고, 우리가 '잘못된' 탭 하나를 클릭하는 것을 멈추는 데 1~2주가 걸렸지만, 우리는 그것을 극복했고, 우리들 대부분은 쉽게 왔다 갔다 한다.재해 포맷?위키텍스트 줘봐테이블에 열을 삽입해야 하는가?시각 모드, 매번.그러나 새로운 편집자는 각 접근방식의 상대적인 장단점을 알지 못할 것이기 때문에 그들에게 유리한 점들은 상당히 작다.문서화된 단점은 상당히 크다.비슷한 두 개의 버튼을 제공하면 많은 혼란이 생긴다.

편집팀이 올해 이 문제를 다룰 계획은 없다고 생각하지만, 사람들이 시각적 모드에서 시작하도록 버튼을 전환하고 싶다면, 내가 팀에 그것에 대해 물어볼 수 있다.Whatamidoing (WMF) (토크) 03:15, 2019년 8월 17일 (UTC)[응답]

Whatamidoing(WMF): 기능성에 대한 부분적인 공개보다 두 탭을 모두 제공하는 것이 덜 혼란스럽다는 것을 알았다.탭이 필요한 이유를 설명하고, 탭이 시각적으로 다르게 보인다는 것을 보여주며, 다음으로 넘어간다.직설적이고 분명하다.두 기능 모두 중요하다.누군가가 그것을 필요로 하고 그들의 마음이 다루어져야 할 실질적인 문제에 놓여 있을 때 그것을 보지 않는 것은 더 주의를 산만하게 하는 것이라고 나는 생각한다.뭔가 다른 것을 보여주는 전문가적 지식을 가지고 있는 것처럼 들리십니까? -- econterms(토크) 08:20, 2019년 8월 17일 (UTC)[응답]

econterms, 편집기 내부에서 두 모드 사이를 전환하는 방법을 보여 주셨습니까?Whatamidoing (WMF) (토크) 03:03, 2019년 8월 18일 (UTC)[응답]

교육을 편집하는 사용자는 기본 "두 편집기 탭 모두"를 만드십시오.그리고 IP에도 두 개의 탭이 주어지지 않아야 하는 타당한 이유가 있는가?많은 선의의 IP newbies가 소스 편집기를 사용하여 구문을 해독하지만, Visual Editor에서 구문을 해독하는 것은 훨씬 어렵다(ok, 100% 보장된 것은 아니지만, 매우 가능성이 희박하다).05:37, 2019년 8월 17일 (UTC) — Kerry Raymond에 의해 추가된 서명되지 않은 이전의 논평 (토크 • 기여)

케리, IP가 위키텍스트를 불균형하게 망친다면, 그것은 그들에게 버튼 하나를 주어야 한다는 주장처럼 들리는데, 이것은 시각적 편집자로 이어진다.Whatamidoing (WMF) (토크) 03:05, 2019년 8월 18일 (UTC)[응답]

나도 IP로는 괜찮을 것 같아.고장난 구문을 훨씬 덜 정리하고 인용하는 방법을 더 명확하고 쉽게 만들면 인용문의 사용이 개선될 수 있다.신입생이 인용문을 추가하려고 하는 경우, 일반적으로는 알몸 URL이기 때문에 Visual Editor에서 "Cite > Automatic"을 사용하는 것은 소스 편집기의 URL에 대해 그들이 관리하는 것에 비해 크게 개선될 것이다.케리 (토크) 03:25, 2019년 8월 18일 (UTC)[응답]

어그러진 구문에 대해서는 잘 모르지만(나 스스로도 상당한 양을 창출한다고 생각한다) 대부분의 의도하지 않은 WP는 다음과 같다.비주얼 편집기를 사용하여 에그와 같은 링크를 만든다.경험이 부족한 VE 에디터나 경험이 부족한 Wikitext 에디터들의 정리가 덜 필요한지 잘 모르겠다.설문조사가 이루어져야 한다.— 아서 루빈(토크) 10:43, 2019년 8월 18일 (UTC)[응답]

일부 테스트를 실행하는 것은 가능할 수 있다(애널리틱스 팀은 항상 과부하 상태여서 나는 그것이 곧 가능할 것이라고 확신하지 않는다).어떤 것이 가장 중요한지를 아는 것이 도움이 될 수도 있다.참조 태그 사용?링크를 추가하시겠습니까?되돌리지 않을래?다른 거?위키피디아를 만들 수도 있다.라벨은 수시간 투자 의향이 있는 사람이 몇 명이라면 수작업으로 수정하는 캠페인을 벌인다. (다음 주 이맘때쯤이면 "에스터 에그 링크" 문제가 크게 개선될 수 있을 것이다.모바일 비주얼 편집 모드로 전환하면 https://en.m.wikipedia.org/wiki/Special:Random#/messages/0에서 일반 모델을 볼 수 있다.)Whatamidoing (WMF) (토크) 16:09, 2019년 8월 19일 (UTC)[응답]

• 나는 새로운 사용자를 위한 설정을 단순화하는 것이 중요하다는 것에 동의한다.유용한 작업을 시작하기 전에 수행해야 하는 모든 사소한 구성 요소는 1) 잘못 설정될 수 있는 기회, 2) 새로운 사용자에게 해제.어쩌면 해결책으로, 새로운 사용자들을 위해 모든 것을 제대로 설정하는 자바스크립트 조각과 "먼저 나를 클릭해!"라고 쓰여 있는 편집톤 홈 페이지에 커다란 친근한 버튼이 있을 수도 있다.더 멋진 것은, 나는 계정을 복제하는 시스템을 상상할 수 있었다.그래서, 편집자톤 조직자는 새로운 계정을 템플릿으로 만들고 그들이 그들의 교육 스타일/환경에 가장 적합하다고 생각하는 방식으로 구성할 수 있었다.그런 다음, 이 구성을 중지하고 "먼저 나를 클릭!" 버튼을 사용하여 새 계정을 동일한 방식으로 구성하도록 할 수 있다.— RoySmith (대화 • 기여) 16:02, 2019년 8월 17일 (UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평
  • RoySmith, 만약 편집자톤 사용자들이 독립된 신인들과는 다른 무언가를 필요로 한다면, 이것은 유용한 생각일 것이다.가능할 것 같아.mw:에도 관심이 있을 수 있다.성장/개인화된 첫날 작업으로, "큰 친근한 버튼" 아이디어와 비슷한 것을 시도한다.Whatamidoing (WMF) (토크) 03:07, 2019년 8월 18일 (UTC)[응답]
• 이 모든 것이 합리적이고 가치 있게 들린다. - 우리는 유치를 돕고 새로운 사람들의 삶을 더 좋게 만들기 위한 정말 복잡하고 논란의 여지가 있는 방법들을 가지고 있다.낮게 매달린 과일을 잡아보는 것은 어떨까?코백베어(토크) 15:42, 2019년 8월 19일 (UTC)[응답]
• 초기부터 시각적 편집기가 크게 개선된 상황에서 사용자는 어떤 편집 방법을 사용할지 선택할 수 있도록 두 탭을 모두 표시하는 것이 합리적일 것이다.—피톤코더(토크 기여) 01:17, 2019년 8월 23일 (UTC)[응답]
• 새로운 사용자에게 도움이 되는 것은 항상 고려할 가치가 있는 아이디어다.그러나 위의 Xaosflux에 따르면, 나는 편집된 페이지를 기본적으로 보는 것을 추천하지 않는다; 그것은 WP의 분위기를 가지고 있다.기본 설정과 기타 기술적 측면에 대해 배우기 전에 많은 페이지를 편집하는 사용자들을 위해 불필요한 혼란을 야기할 수 있다.하지만 다른 생각이 있어아직 그렇지 않다면 refToolbar를 디폴트로 사용하는 것을 추천하고 싶다. 참조는 기본이지만 때때로 새로운 사람에게 약점이기도 하기 때문이다. 특히 wikitxt와 템플릿 구문은 생소할 수 있기 때문이다.ComplexRational (대화) 15:01, 2019년 8월 24일 (UTC)[응답]

애매한 JOB에 대한 제안제목

여러분 안녕하십니까?

여기에 직함을 어떻게, 언제 자본화할 수 있는 좋은 절충안이 되었으면 좋겠다는 제안을 추가했다.

이것이 좋은 정책이라고 생각되면 나에게 알려줘.건배! --Woko Sapien (토크) 16:24, 2019년 8월 26일 (UTC)[응답]

아티클에 대한 툴팁:섹션이 연결된 경우 섹션의 미리보기 텍스트를 표시하십시오.

마우스 포인터를 그 위로 이동시킬 때 기사 미리보기를 보여주는 툴팁은 글의 한 섹션이 링크되어 있더라도 기사의 시작을 보여준다.

이것은 개인적으로 나를 괴롭히는 것이 아니라, 누군가 유용하다고 생각할 수도 있기 때문에, 나는 단지 이 점을 여기서 다루어야 한다고 생각했다. --Handroid7 (대화) 16:18, 2019년 8월 26일 (UTC)[응답]

@Handroid7:페이지 참조:T156041. --에어랜드 (토크) 21:52, 2019년 8월 26일 (UTC)[응답]

불행히도 비독점적인..—DJ (대화 • 기여) 07:50, 2019년 8월 28일 (UTC)[응답]

템플릿에서 "용의자" 필드 제거:인포박스 민간인 공격

Bot는 결함이 있는 Wiki 링크를 전체 URL로 수정한다.

이것이 이미 존재하는지는 잘 모르겠지만, 봇은 이것을 바로잡을 수 있어야 한다.

• [하지만 전체 URL(잘못됨) 포함]

--Handroid7 (대화) 12:56, 2019년 8월 20일 (UTC)[응답]

안녕 @Handroid7:, 무엇을 요구하는지 잘 모르겠어?봇이 고장을 일으킨다고 생각될 경우 WP에 게시하십시오.BOTN. 중소 규모의 반복 작업을 봇이 하기를 원한다면 WP에서 다음과 같이 물어 볼 수 있다.BOTREQ. 여기서 토론하는 봇이 아주 큰 것(수천 개 이상의 편집)을 하기를 원한다면 좋은 시작이지만, 우리는 진행하기 위해 약간의 정보가 더 필요할 것이다.좋은 예로는 봇이 하고 싶은 편집 유형을 수동으로 만든 다음 여기서 여러분 자신의 디프로 연결하는 것이다.— Xaosflux^Talk 13:10, 2019년 8월 20일 (UTC)[응답]

@Xaosflux : URL이 [[http://example.org 이렇게] 쓰여 있으면 봇이 고쳐야 한다. --Handroid7 (토크) 23:39, 2019년 8월 30일 (UTC)[응답]

2019년 중재위원회 선거전 RfC

댓글 요청은 2019년 영어 위키백과중재위원회 선거의 구조와 규칙, 절차를 수정하고 기존 규칙에서 다루지 않은 사안을 해결할 수 있는 기회를 제공하기 위해 공개된다.Mz7 (대화) 21:35, 2019년 8월 31일 (UTC)[응답]

대화형 기록 시간 표시 막대 추가

위키피디아는 이미 주요 페이지의 "오늘날" 섹션에서 증명되었듯이 특정한 역사적 사건들의 날짜에 대한 배경 정보를 가지고 있다.그럼에도 불구하고 한 지역의 역사와 특정 기간 동안 일어난 사건들을 알고 싶다면 이런 페이지를 이용해야 한다.사용자가 위치(또는 지역), 범주 및 시간대를 입력하여 해당 매개변수를 언급하는 모든 위키백과 페이지의 목록을 얻을 수 있는 페이지를 제안한다.나는 이것이 역사적 정보에 흥미가 있거나 필요한 사람들을 위한 발견과 학습을 크게 간소화할 것이라고 믿는다.— Slevercreeper1 (대화 • 기여) 23:56, 2019년 8월 28일 (UTC)[응답]에 의해 추가된 이전의 서명되지 않은 논평

예를 들어 범주를 사용해 보셨습니까?카테고리:캐나다에서 1750년대?위키데이터도 볼만한 가치가 있을 것이다.덱스도르 ^(talk) 20:38, 2019년 8월 29일 (UTC)[응답]

그래, 멋질 거야.위키피디아에서 발견된 정보를 우리가 표면에서 긁어내기 시작하지 않은 여러 가지 방법으로 사용하고 대표할 수 있다.WikiData를 통해 정보가 더 전송되면 제안하는 것과 같은 시각자료로 더 쉽게 변환될 수 있다.Killiondude (대화) 23:14, 2019년 8월 29일 (UTC)[응답]

나는 어느 정도 이 일을 해냈거나 진행 중인 외부 프로젝트에 대해 읽은 적이 있다; 어떤 이유에서인지, 나는 아마도 위키마니아 2018에서 이 일에 관련된 사람을 만났을지도 모른다고 생각한다.불행히도 어디서 찾아야 할지, 어디서 찾아봐야 할지 기억이 나지 않지만, 팻말 기사에서 나온 것이 아닌가 하는 의심이 든다.그 비주얼은... 기막히게 좋았던 것으로 기억한다.리스크 담당자(대화) 03:52, 2019년 8월 30일 (UTC)[응답]

공식 Wikidata SPARQL 끝점은 타임라인 보기로 출력할 수 있다(d: 참조):위키다타:SPARQL 쿼리 서비스/쿼리/예제#타임라인.위키다타 타임라인에는 커뮤니티 툴과 히스트로피디아(Histropedia)라는 제3의 툴도 있다. --Izno(토크) 03:36, 2019년 9월 1일(UTC)[응답]

RFC: 새 자물쇠 시스템

의견요청(RfC) 프로세스 개선 제안

(참고: 내 제안서가 필요하다고 생각되면 자유롭게 수정하거나 확장하십시오.)

WP의 문제:RFC 과정은 위키피디아에 유용한 기능 향상이지만, RfCs는 "피드백 서비스"를 홍보하기 위한 최선의 노력에도 불구하고 매우 오랫동안 Talk 페이지를 열어두는 경우가 많은 것 같다.

제안서: 공동체가 결정하는 대로 맨 위 또는 맨 아래에 선택적으로 RfC를 기사 페이지에 표시할 수 있는 기능을 추가한다.많은 위키피디아 페이지에는 페이지 상단에 태그가 있으므로, 이것은 중요한 부과사항이 아닌 것 같고, 주어진 RfC에 대한 더 많은 피드백을 장려할 수 있다.

그것은 다른 매개변수, 시간 제한, 재목록 기능으로 사용자 정의될 수 있고, 또한 내가 보기에 꽤 매끄럽게 보이는 페이지 이동 과정과 마찬가지로 그들을 가입된 위키프로젝트에 자동 홍보하도록 봇을 프로그래밍할 수도 있다.더그 메후스 (토크) 18:35, 2019년 8월 28일 (UTC)[응답]

개인적으로 나는 RfC의 주제인 모든 기사에 그러한 제안된 통지가 추가되어야 한다고 생각하지 않는다.먼저, 얼마나 많은 독자들이 다양한 위키피디아인들 사이의 편집 분쟁에 대해 알고 있거나 관심을 가질 것인가?모든 논쟁이 동일한 것은 아니지만, 일부 분쟁은 외부 의견(기존 편집자 또는 독자/잠재적 편집자)을 얻는 데 도움이 될 수 있는 반면, 다른 분쟁은 유용하지 않을 수 있다. 그러나 이는 모든 기사가 아닌 사례별로 이루어져야 한다.그러나 위키프로젝트에 공지를 추가하는 것은 유용해 보인다. 다시 한번, 인간의 판단 없이는 이루어질 수 없는 기사의 논쟁 범위에 따라 말이다.사쿠라 카트렛^Talk 23:44, 2019년 8월 28일 (UTC)[응답]

• 드메후스가 어디서 오는지는 이해하지만 사쿠라 말이 맞는 것 같다.나는 단지 우리가 어떤 것이 논의되고 있는지 몰랐던 참가자들을 더 많이 가질 것이라고 생각한다(RfCs는 이름붙여주는 기술 논쟁에 관한 많은 기사들).위키프로젝트에 추가하는 것은 좋은 생각인 것 같다.코백베어(토크) 10:04, 2019년 8월 29일 (UTC)[응답]

• 단일 범위 기사 RfC의 경우, 해당 기사의 편집 공지에 추가해도 괜찮아 보인다.드메후스가 언급했듯이, 이러한 통지들은 독자들에게 그다지 유용하지 않다.일부 광범위한 RfC의 경우(예: 모든 날짜를 1980년에서 1980년으로 변경)AD) 날짜와 함께 모든 기사에 추가되는 것은 엄청난 노력의 낭비일 것이다.— Xaosflux 10:35, 2019년 8월 29일 (UTC)[응답]

• 지금까지 답변해 준 것은 모두 고맙지만 @Xaosflux: 그러한 태그의 맨 위(또는 맨 아래)에 대한 지원만이 내가 찾던 기사 한 페이지였다.나는 사실 당신이 RfC 태그로 여러 개의 기사 페이지나 다양한 페이지, 또는 심지어 전체 카테고리에 태그를 달 수 있는지 몰랐지만, 그 후자의 예에서, 나는 그것이 어떻게 문제가 되는지 알 수 있다.나는 주로 토론과 비교적 잘 알려지지 않은 기사 페이지의 토크 페이지에 내가 제기했던 질문들에 대한 흥미를 유발하고자 했다.Wittington Investments는 아무런 응답도 생성하지 않았으며, 다른 RfCs를 살펴본 결과, 많은 관심을 유발하지 않는다는 것을 알게 되었다.더그 메후스 (대화) 2019년 8월 29일 (UTC) 15:00[응답]

• @Dmehus: 분명히, 나는 독자를 마주보는 현수막을 지지하는 것이 아니라 편집통지서를 지지하는 것이었다.이것들은 누군가가 기사를 편집하려고 할 때에만 나타나는 것이지, 단지 그것을 읽으려고 하는 것이 아니다.예를 들어 도널드 트럼프를 편집할 때 이런 예들을 볼 수 있다.— Xaosflux 15:22, 2019년 8월 29일 (UTC)[응답]

• @Xaosflux: 아, 고마워.나는 아마도 내가 매우 논쟁적인 주제들에 관여하지 않는 경향이 있기 때문에 편집 통지가 있다는 것을 깨닫지 못했다.내가 편집한 가장 논란이 되는 페이지는 PAC가 연간 서류 작성 요건을 위반하고 있다는 FEC 파일링 정보를 추가하기 위해 Onward Together PAC였다.편집자가 이 페이지를 임의의 페이지에 추가할 수 있는가?그것은 잠재적으로 WP를 예방하는 데 도움이 될 수 있다.BRD 페이지가 이동한다.그래도 많은 사람들이 위키피디아를 편집하지 않기 때문에 기사 페이지의 페이지 이동 통지 같은 일종의 미묘한 통지가 도움이 될 수 있을 것 같다.확실히 다른 모든 배너들보다 더 도움이 된다.하지만, 나는 확실히 RfC가 여전히 뛰어나고 편집자가 흥미를 잃지 않았다면 다시 광고될 수 있지만, 그것이 아마도 60-90일 제한으로, 단일 페이지로 제한되어야 한다고 생각한다.더그 메후스 (토크) 15:39, 2019년 8월 29일 (UTC)[응답]

• 위키백과 참조:편집통지.— Xaosflux 15:45, 2019년 8월 29일 (UTC)[응답]

• +1. 더그 메후스 (토크) 15:58, 2019년 8월 29일 (UTC)[응답]

로그인한 사용자만 읽기 모드로 표시되는 알림을 추가할 수 있는 방법이 있는가?그래야 익명의 방대한 독자들이 볼 필요가 없겠지만 로그인한 사람들은 이 문제에 대한 견해를 가질 수 있는 경쟁자가 될 가능성이 높다.케리 (토크) 2019년 8월 31일 (UTC) 16시 3분 (답변)

@Kerry Raymond: 기술적으로 공지를 올릴 수 있고, 작동 중인 자바스크립트를 가지고 있는 로그아웃한 사용자들에게 그것을 숨길 수 있게 할 것이다.그러나, 위키피디아는 다음과 같은 사실을 명심하라.IP는 역시 인간이고 또한 편집자일 수도 있다.— Xaosflux 16:11, 2019년 8월 31일 (UTC)[응답]

• 지지하다.기사 맨 위에 있는 꼬리표가 말이 될 것 같아.우리는 이미 일상적인 이동, 분열, 합병 논의를 위해 그것을 하고 있다.다른 유지관리 템플리트도 토크 페이지의 토론으로 연결하도록 권장한다.광범위하고 강력한 합의에 도달한다는 명시적인 목적을 가지고 보다 무거운 리프팅 과정이 되어야 하는 RfCs에 대해서는 왜 그렇게 하지 않는가?

현재 진행 중인 분쟁에 대해 아무것도 모르는 사람들이 몰려올 것에 대한 우려와 관련하여, 사실 이것은 편집자들이 주로 RFC에 도착해서 그들이 들어본 적도 없는 "봇에 의해 요약된" 기사 주제에 대해 이야기 할 때 일어나고 있는 일이다.오히려 노즈백베어가 언급하는 '이름과 같은 기술적인 논쟁'에 대한 논의는 이미 기사 상단에 태그가 붙도록 의무화돼 있다.독자들이 편집자가 되기로 결정하더라도, RFC를 큐레이션하고 닫는 것은 항상 어떤 코멘트를 고려해야 하고 어떤 코멘트를 고려하지 말아야 하는지 정확히 아는 숙련된 (비)관리자들에 의해 이루어진다.우리는 실제로 기사를 읽고 있는 사람들로부터 나쁜 투표 전용 댓글을 받지 않는다.우리는 백과사전 밖에서 조사받은 사람들로부터 그것들을 얻는다.– 피누서톱 (토크 ⋅ 기여) 16:43, 2019년 8월 31일 (UTC)[응답]

@Finnusertop:, 지지해줘서 고마워.그래, 아마도 더 넓은 제안으로서, 우리는 페이지 혼란을 줄이기 위해 3-4조 페이지 머리글 통보의 최대 한도를 부과할 수 있을 것이다. 하지만 논쟁의 여지 없이, RFC 통지는 실제로 비편집자가 위키피디아를 편집하거나 최소한 토론에 기여하도록 부추길 수 있다.이런 식으로, 나는 "그의 페이지에 여러 문제가 있다는 헤더 통지보다 더 도움이 된다고 생각한다.이유를 알아보려면 여기를 클릭하십시오.";-) 미디어위키/위키피디아 기능 개선 요청에 대한 제안으로 앞으로 나아갈 수 있도록 몇 가지 추가 지원을 환영하며, 이에 대한 합의가 필요하다.더그 메후스 (토크) 19:29, 2019년 8월 31일 (UTC)[응답]

• 반대한다. 이것은 일반 독자들에게 소시지가 어떻게 만들어지는지를 보여주는 것에 너무 가깝다.관심 있는 편집자들은 관심 있는 페이지를 감시하기 위해 감시 목록을 사용한다.강연의 RfC 태그:페이지에는 이러한 편집자에게 경고가 표시된다.또한 위키피디아에는 "시간 제한 없음"이 있어서 시간은 문제가 되지 않으며, 문제가 되지 않아야 한다.그러나 프로젝트 토크 페이지에 대한 통지는 RfC 프로세스의 일부로 유용할 것이다.GenQuest 20:53, 2019년 8월 31일 (UTC)[응답]
• 대부분 피누서톱을 지지한다.RfC의 기사 토크 페이지는 거의 항상 내용 질문을 중심으로 진행되었고, 이를 위해서는 일반적으로 기사를 보거나 편집하는 편집자나 독자들 사이에서 더 잘 표현되는 주제에 대한 지식으로 참가자들을 끌어 모을 방법이 필요하다.그리고 RfC가 일반적으로 중요한 문제에 사용되어야 한다는 점을 감안할 때, 삭제, RM, 병합/분할 제안 등과 마찬가지로, 이러한 것들은 정말로 관련 페이지에 광고되어야 한다.– 우안팔라 (대화) 14:01, 2019년 9월 3일 (UTC)[응답]
• 지원 - 많은 RfCs가 더 많은 참여를 통해 할 수 있으며, 그러한 조치는 특히 프로젝트의 특정 부분에서 수가 감소하는 상황에서 새로운 편집자들을 혼란에 빠뜨릴 수 있는 훌륭한 방법이 될 것이다.RfC를 해당 템플릿에 요약하여 일반 독자/저활동 편집자가 관심 있는 이슈인 경우 토크 페이지에 끌릴 수 있도록 하는 것이 좋을 것이다.

비록 RfC의 특정 범주를 제외하는 것이 좋을 것이라는 데 동의한다. - 내 관심은 사용자들이 관심을 갖지 않는 것이 아니라, 정보를 모르는 사용자들이 합의 도출된 규제에 의해 요구되는 것 보다는 그들이 원하는 것에 투표하는 것이다. - Axixa T C 03:39, 2019년 9월 6일 (UTC)[응답]

• 반대 - 너무 많은 RfC는 수많은 위키백과/자르곤을 포함하는 많은 텍스트를 포함한다.만약 그것이 꽤 무해하고 직설적인 것이었다면, 그래서 누군가의 판단이 도움이 될 수도 있겠지만, 나는 대부분의 경우에 이것은 위키피디아에 대한 지식이 없는 사람들에게 위키피디아를 적용하도록 애원하는 것 같다.\\ 13:39, 2019년 9월 6일 (UTC)[응답]