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

*L'infobox infernale*
L'infobox infernale
Opera semiseria in 25 acts by John Smith
	The final scene
Translation	The Hellish Infobox
Librettist	Jane Doe
Language	Italian
Premiere	23 December 2005; Wikipedia
Website	Infobox wars

Infobox wars
	; WP:ALLROADSLEADTOINFOBOXES
Date	2013–present
Location	English Wikipedia
Status	Possibly petered out due to exhaustion
Belligerents
radical infobox inclusionists	radical infobox exclusionists
Casualties and losses
	bystanders' sanity

마을펌프
- 정책
- 기술
- 제안. (iii)
- 아이디어 랩
- WMF
- 잡다한

마을 펌프(제안) 아카이브

이 페이지에는 빌리지 펌프(제안)에서 보관된 토론이 수록되어 있다.이 페이지의 내용을 편집하지 마십시오.이러한 토론 중 하나를 다시 시작하려면 새 스레드를 시작하거나 해당 주제와 관련된 대화 페이지를 사용하십시오.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125,126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188

왼쪽 사이드바 업데이트 후속 조치

위키백과로 이동:의견 요청/2020 좌측 사이드바 업데이트 § 후속 조치

–{{u Sdkb}} 02:33, 2020년 10월 7일(UTC)[응답]

로컬 언어 요구 사항

간단히 말해서, 가능한 장소 이름에는 지역 언어 이름이 수반되어야 한다.EG 스코틀랜드 게일릭(Gaidhlig)의 학습이 증가하고 있다.따라서 글래스고와 같은 플래카드도 글래스추로 표시해야 하며, (글래스고는 스코틀랜드에서 게일어 화자의 비율이 가장 높다) 윌리엄 요새는 안기라스단을 표시해야 한다.— Tartaning이 추가한 사전 서명되지 않은 의견(대화 • 기여)

내 생각에 글래스고가 가장 높은 비율을 가지고 있는 것이 아니라 가장 높은 절대수를 가지고 있다는 뜻인 것 같아.필 브리저 (대화) 13:25, 2020년 9월 12일 (UTC)[응답]

글래스고 기사에 이미 현지 이름이 나와 있지 않은가?– Teratix₵ 04:10, 2020년 9월 14일 (UTC)[응답]

그들은 또한 포트 윌리엄, 하이랜드 기사에 있다.장소에 대한 대체 "로컬 언어" 이름을 포함하는 것은 상당히 표준적인 관행이다.블루보아 (대화) 11:36, 2020년 9월 14일 (UTC)[응답]

지역 도로 표지판에 쓰인 이름만 붙일 가치가 있다는 것은 적어도 선도에는 붙일 가치가 있다는 것이 경험의 법칙이라고 생각한다.지난번에 글래스고에 갔을 때 나는 "글래스추"를 간판으로 본 기억이 없다.먼 곳의 독자들이 로마나 나폴리 사람들이 말하는 것처럼 현지인들이 제목에서 그것과 다른 이름을 사용한다고 제안하는 것은 잠재적으로 오해의 소지가 있다.포트 윌리엄 역은 플랫폼 표지판 등에 게일어 이름(때로는 저절로)을 사용하는 것으로 알고 있지만 글래스고 중앙역은 그렇지 않다."Glaschu"는 전혀 "지역 언어" 이름이 아니다 - 그것은 Glasgow이다.존보드 (대화) 17:02, 2020년 9월 14일 (UTC)[응답]

존보드는 그것이 모든 장소의 이름에 적용되어야 한다고 말하는 거야 아니면 스코틀랜드 이름에만 적용되어야 한다고 말하는 거야?케임브리지 베이는 전통적인 이름인 Iqaluktutiaq를 가지고 있지만 도로 표지판이 붙어 있지 않은 것이 그 예다.이전 문장과 키예프나 키이브에 예시처럼 다른 이름을 사용하는 것은 위키백과에서 흔히 볼 수 있다.아마도 많은 스코틀랜드의 지명들이 누락된 이유는 아직 아무도 그것들을 추가하지 않았기 때문일 것이다.케임브리지베이날씨, 우카크투크(토크), 훌리바 23:56, 2020년 9월 15일(UTC)[응답]

선두가 시작될 때 우리가 바로 보여주는 것으로 볼 때, 그렇다.나는 우리가 두 버전 모두 실제로 사용되는 벨기에 이름들과 그렇지 않은 다른 장소들을 구분하지 못함으로써 자주 독자들을 오도하고 있다고 생각한다.나는 그것이 주먹구구식이라고 말했다. 길거리에서 이칼루크투티아크를 들을 것 같니?존보드 (대화) 03:01, 2020년 9월 16일 (UTC)[응답]

네, 들렸답니다.이칼루크투티악 코옵이나 이칼루티악 교육청 같은 이름으로 사용하는 단체가 여럿 있다.Inuinnaqtun이나 Inuktitut을 사용하는 사람은 누구나 그것을 사용할 것이다.이러한 언어에서 캠브리지 베이의 적절한 이름은 Iqaluktutiaq이며, 몇 가지 다른 방법을 쓴다.문서에는 케임브리지 베이가 항상 Iqaluktutiaq로 번역되어 있다.케임브리지베이날씨, 우카크투크(토크), 훌리바 18:29, 2020년 9월 16일(UTC)[응답]

(믿음) - 오, 그럼 괜찮아.하지만 도로 표지판에 그것을 덧붙여야 하지 않을까?존보드 (대화) 13:25, 2020년 9월 23일 (UTC)j[응답]

2020년 9월 19-26일 "Wiki loves SDGs"를 위한 중앙 공지 배너 토론

이 배너가 전시되었을 한 주가 지났다.비쇼넨 tålk 08:11, 2020년 9월 27일(UTC)[답답하다]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

나는 2020년 9월 19일부터 26일까지 내가 참여하는 온라인 편집전에 대한 중앙 공지 배너 요청을 게시했다.그것은 이미 다른 배너를 동시에 가지고 있지 않은 나라들의 영어 위키백과를 위한 것이 될 것이다(위키가 기념비를 사랑하고 9월에 모금하는 것 또한 증가할 것으로 보인다).메타 담당 관리자로부터 "빌리지 펌프에 대해 논의해야 한다"는 말을 들었다, 그래서 지금 여기에 글을 쓰고 있다(적절한 섹션에 넣었으면 좋겠다).지금까지 논의한 내용을 링크해 봅시다: https://meta.wikimedia.org/wiki/CentralNotice/Request/Wiki_loves_SDGs_2020#Wiki_loves_SDGs_2020.그 관리는 나에게 다음과 같이 충고했다. "안녕 @EMMile: 그 동안: 영국 사회는 또 다른 세계적인 배너로 괜찮을까?이 문제가 논의된 장소의 링크를 공유해 주시겠습니까?영국 공동체는 때때로 다른 배너를 허용하는 것을 약간 망설이는 경우가 있기 때문에, 공동체를 알리고 합의를 모색하는 것이 좋을 것이다."여러분들은 어떻게 생각하십니까?이 캠페인에 대한 자세한 내용은 https://meta.wikimedia.org/wiki/CentralNotice/Request/Wiki_loves_SDGs_2020#Wiki_loves_SDGs_2020를 참조하십시오.또는 온라인 편집자톤에 대한 자세한 내용은 여기를 참조하십시오.그것은 17개의 지속 가능한 개발 목표와 그것과 관련된 모든 주제들에 관한 것이다.EMsmile (대화) 11:13, 2020년 9월 7일 (UTC)[응답]

나는 지금과 같은 반대 의견을 가지고 있다 - 나는 "위키 러브즈 X" 스타일이 별로 마음에 들지 않는다. 왜냐하면 만약 여러분이 현장에서 더 나은 실행을 위해 공개적으로 캠페인을 하자고 한다면, 사람들은 우리가 캠페인을 하면 안 된다는 이유로 반대할 것이기 때문이다.이제 우리 나라(영국)에서 운영되지 않을 것이고, 편집자는 GF에 있고, 중요한 것은 아니므로 나는 이 문제에 대해 중립적인 태도를 취할 용의가 있다.코백베어 (토크) 10:49, 2020년 9월 8일 (UTC)[응답]

Hi User:코백베어, 코멘트 고마워.편집자가 GF에 있다는 게 무슨 뜻인지 궁금해서?이것은 더 많은 사람들이 Global South(개발도상국)에서 Global South와 관련된 주제들을 편집하도록 하기 위한 캠페인이며, 특히 새로운 여성 편집자들이다.기존의 위키백과 기사를 개선하기 위한 캠페인이다.어떤 의미에서 "우리는 선거운동을 하면 안 된다"는 말씀이세요?개인적으로, 나는 "위키가 SDG를 사랑한다"보다 "위키피디아가 SDG를 사랑한다"를 선호했을 것이다. 그러나 이것을 시작하는데 관여했던 다른 사람들은 프로젝트 타이틀의 더 짧은 버전을 선호했다.EMsmile (대화) 14:07, 2020년 9월 8일 (UTC)[응답]

@EMMile: - 그냥 "편집자는 GF(성실한 믿음)"라고 쓰려고 하다가 문법에 걸려 넘어졌다.위키보다는 위키피디아에 대한 선호를 공유하지만, 얼마 전까지만 해도 그것을 죽을 언덕으로 꼽을 가치가 없다고 판단했다.위키피디아는 우리의 기능성에 내재된 위협적인 것 외에는 캠페인을 하지 않는다(예를 들어, 가장 최근, BLM에 대한 블랙아웃에 대해 매우 강력한 감소가 있었다).나는 SDG에 관한 더 많은/더 나은 기사들에 대해 전혀 반대하지 않는다.하지만 "Wiki는 SDG를 사랑한다"는 좀 더 진부한 버전의 "Wiki (pedia)는 SDG에 대해 쓰는 것을 좋아한다"는 것이 아니다. 만약 당신이 누군가에게 그것이 무엇을 의미하는지 말해달라고 한다면, 그들은 그것을 위키피디아가 SDG에 대해 밀어붙이는 것처럼 읽었다고 느낄 것이다.코백베어 (토크) 14:13, 2020년 9월 8일 (UTC)[응답]

이것이 주로 기사를 작성/개선하고 있다면 '위키가 글을 쓴다.' 또는 '위키가 에 대해 쓴다.' 알란스코트워커(토크) 14:21, 2020년 9월 8일(UTC)[응답하라]를 추천하고 싶다.

그것은 주로 기사를 개선하고 그것들을 더 잘 연결시키는 것에 관한 것이다.둘 다 이것에 대한 배너에는 개의치 않는다는 말인데, 배너에는 "위키가 SDG를 사랑한다"고 쓰여 있으면 싫다는 말씀이세요?배너에 텍스트가 다른 경우 더 행복하시겠습니까?이 현수막은 위키백과에 관한 SDG 관련 기사(수백 건, 여기 참조)를 개선하기 위한 일주일간의 노력(글로벌 목표 주간 동안)에 참가하도록 사람들에게 경고하기 위한 것이다.EMS마일 (대화) 14:55, 2020년 9월 8일 (UTC)[응답]

위키는 누구인가?우리가 아는 사람인가?위키는 지각력이 없어서 어떤 것도 사랑할 수 없다.위키피디아 사람들은 다른 사람들(위키페디아인인지 아닌지)을 사랑할 수도 있지만, 이 경우 그들은 예리하고, 열정적이며, 단호할 수도 있고, 심지어 홍보하고, 격려하고, 강화하거나 심지어 간청하고, 초대하기를 원할 수도 있다."SDG"나 "SDGs"에 대해서는, 그냥 전체 철자를 쓰세요.우리가 그렇게 공간이 부족한가?그래서, 모두 끔찍한 표현 선택이었습니다.아니면 본질적인 잘못은 단지 우리의 관심을 끌기 위해 만들어진 것인가?— 고스트인The Machine 17:34, 2020년 9월 8일 (UTC)[응답]

좋은 생각이야!정리해주셔서 감사하다.어떤 사람들은 "Wiki Loves"를 좋아하지 않는다.왜냐하면 그것은 모든 사람들의 지지를 의미하기 때문이다.따라서 "위키 러브스 프라이드" 행사를 광고하는 것은 실망스럽지만 놀라운 일은 아니었다.하지만 꽤 잘 확립된 명명 형식(Wiki Loves Monuments, Wiki Loves Earth 등)인데 SDG가 논란이 되고 있는가?"빈곤 없음"과 "공복 없음"과 같은 것들을 지지하고 있는 것이 보여지는 것을 원하지 않는 사람들이 있는가?어떤 이름으로 끝나든 이 고시를 지지하겠지만, 이미 그 이름 뒤에 어떤 조직적인 것이 있는 것처럼 보이기 때문에, "Wiki Loves"가 다른 동사들보다 더 망설이게 만든다는 것을 미래의 조직자들을 위해 이 고시를 현 상태로 유지하는 것이 최선일 것이다.\\ 17:03, 2020년 9월 8일 (UTC)[응답]
그렇다. 어떤 사람들은 위키피디아가 만들어낸 사회 및 생태학적 위기를 바로잡는 세계화된 자본의 부조리에 대해 도안된 기술정치적 상투적 상투의 세탁목록을 승인하는 것에 반대할 수도 있다.하지만 항상 반대하는 사람이 있을 거야나는 그것이 그 프로젝트에 참여를 늘리기 위해 선의의 노력을 하는 사람을 멈추게 해서는 안 된다고 생각한다.– Joe (대화) 18:07, 2020년 9월 8일 (UTC)[응답]

링크 감사, 사용자:조 로.SDG와 그 과정을 비판하는 기사들은 바로 내가 위키피디아에 가져오고 싶은 것이다.우리는 이미 SDG 기사(https://en.wikipedia.org/wiki/Sustainable_Development_Goals#Reception)에서 그러한 것들을 논의/인용할 수 있는 섹션의 "properties"를 가지고 있다.그 섹션은 이전에도 "비판"이라고 불렸지만 나는 WP:CRIT에 따라 그렇게 하는 것이 올바른 방법이 아니라고 들었다.나는 확실히 균형 잡힌 시각을 제공하고 싶다. 그리고 SDG를 비판한 학자와 NGO가 있다면, 이것은 포함되어야 한다.그것은 "SDG에 대한 논쟁"과 같이 그것을 구체적으로 다루는 기사 스핀오프도 보증할 수 있다. SDG를 설명하는 기존의 UN 웹사이트들은 분명히 매우 편향되어 있고 모든 것을 명확하고 쉽게 들리게 한다.그 말을 했더라면, 우리는 또한 모든 SDG 관련 주제들을 편집하기를 원한다; 이것들은 산모 사망률, FGM, 출생 등록, 강제 결혼과 같은 주제들뿐만 아니라 기후 변화, 에우트로피케이션, 해양 산성화 등과 같은 것들이다.편집자톤은 SDG와 관련된 주제(SDG뿐만 아니라)에 관한 것이 될 것이라고 말함으로써 우리는 실제로 많은 기사를 다루게 될 것이며, 이들 중 상당수는 전통적으로 위키백과에 대한 관심이 적은 분야인 글로벌 남부/개발도상국들과 관련이 있다. 단지 편집자들이 자원봉사자여서 어떤 주제에 대해 글을 쓰는 경향이 있기 때문이다.그들은 알고 아끼고 있다.만약 편집자들이 유럽과 북미 출신이라면 당연히 그들은 즉시 그들에게 영향을 주지 않는 그러한 주제에 대해 쓰는 경향이 덜하다.EMsmile (대화) 04:22, 2020년 9월 9일 (UTC)[응답]

이렇게 하면 나는 잠시 멈추게 된다. 가장 활동적인 9명의 자원 봉사자들은 각각 100유로씩 편집이 끝나면 상금을 받게 된다(위키피디아:Meetup/Online 편집-a-thon SDGs 2020년 9월#Pries).당신은 "적극적인"이 무엇을 의미하는지 모호하게 생각하고 잠재적으로 수천 명의 새로운 편집자들에게 메시지를 보낸다. 그것은 많은 편집은 돈이 혼란을 야기할 수 있다.WLM의 상은 양이 아닌 품질에 대한 것임을 분명히 함으로써 이를 극복한다.– Joe(토크) 18:26, 2020년 9월 8일 (UTC)[응답]

지적해줘서 고마워, 조나는 지금 이렇게 바꾸었다: "편집경연대회에서 가장 값진 공헌을 한 9명의 자원봉사자들은 각각 100유로 편집의 마지막에 상금을 받게 될 것이다.주최 측은 편집 기고 내용의 질과 양에 따라 가장 값진 기고를 가진 자원봉사자가 누구인지 가려낼 예정이다.이러한 판단을 내리기 위해 편집자들은 여기 이벤트 대시보드에 수집된 데이터에 따라 자원봉사자들의 기여도를 신중하게 검토할 것이다." (위키피디아:Meetup/Online Edit-a-thon SDGs 2020년 9월#Pries) 나는 가치관이 품질과 양과 대체로 동일하다고 생각하는데, 동의하시겠습니까?나는 WLM이 그들의 상품을 위해 사용하는 정확한 기준을 찾을 수 없었다. (있으면 정확한 위치를 알려주시겠습니까?네가 준 링크는 나에게 그런 정보를 보여주지 않았다.)

현수막의 문구와 관련하여 타협을 위해 이것을 하는 것은 어떨까?우리는 긴 버전과 짧은 버전을 모두 포함한다.짧은 버전은 "Wiki는 SDG를 사랑한다"이다. 긴 버전은: "Wikipedians는 온라인에서 만나 지속 가능한 개발 목표와 관련된 주제를 다루는 기사를 개선한다." (나도 짧은 버전에 대해 큰 팬은 아니지만, SDG에 대한 자원봉사자들과 활동 경험이 있는 사람들로부터 이것이 효과가 있고 잠재력이 있다는 말을 들었다.사람들을 행동으로 옮기고, 호기심을 갖게 하고, 위키피디아에 오게 한다.)아마도 "Wiki는 SDG를 사랑한다"라는 제목이 위키백과 밖에서는 더 잘 통할지 모르지만, 위키백과의 내부에서는 더 긴 버전을 더 많이 밀어붙일 수 있을까?EMsmile (대화) 04:26, 2020년 9월 9일 (UTC)[응답]
다음과 같은 이유로 반대한다.
- 센트럴 노티스는 최근 많이 이용되고 있다.우리는 특히 모금 시즌이 다가옴에 따라, 모든 사용자를 대상으로 또 다른 광범위한 캠페인을 벌이지 말아야 한다.배너를 너무 자주 사용하지 않는 것이 중요하다.
- SDG는 정확히 말하자면 그렇게 광범위한 주제가 아니어서, 예상 편집은 그렇게 넓은 청중(즉, 전체 독자층)에게 배너를 표시하는 것을 정당화하기에 충분할 것 같다.이것에 기여할 만한 것을 가지고 있는 사용자는 극소수일 것이다.
- 공공정책 분야에 가까운 것은 중립적인 관점에서 보면 위험하다.우리가 이 주제에 대해 쓰고 싶다고 동시에 의사소통하기는 어렵지만, 우리는 중립적이고 이 목표들 중 어떤 것도 실제로 달성하는 데 관여하지 않으며, 그것들을 지원하는 데 관심이 없다."Wiki Loves SDGs"라는 이름은 더욱 어렵다.
--에어랜드 (대화) 04:32, 2020년 9월 9일 (UTC)[응답]

나는 단지 이 현수막이 영어 위키백과 독자들 전체를 위한 것이 아니라 위키백과나 기금 모금 현수막을 아직 가지고 있지 않은 나라들에 있는 사람들을 위한 것이라는 것을 지적하고 싶다.가능하다면, 나는 "글로벌 사우스" 개발 도상국의 모든 독자들이 그것을 볼 수 있게 하고 싶다. 또는 그것이 너무 어렵다면, 아프리카와 아시아 전 지역(SDG가 가장 뒤처져 있는 곳)을 볼 수 있게 하고 싶다.- 지원 암시 여부 관련:또 다른 선택은 "위키는 지속 가능한 개발을 좋아한다"라고 말하는 것일 수도 있다.아니면 "위키는 지속가능성을 좋아한다"?내가 잘못 알고 있는 것이 아니라면 위키미디어 재단이 공식적으로 지지한 개념들이 될 것이다(예를 들어, 작년에 위키미디어 재단이 지속가능성 컨소시엄이라는 단체를 만들었다는 것을 참조하라). - 현수막 남용으로: 아마도 그것은 당신이 어느 나라에 살고 있는가에 달려 있을 것이다.나는 호주에 살고 있는데 여기 현수막은 거의 없어.지난 12개월 동안 내가 본 유일한 것은 위키백과가 기념물을 좋아하고 어쩌면 모금 현수막인 것 같다 - 적어도 나는 다른 어떤 것도 기억하지 못한다.과용할 것 같지 않아.아마도 그들은 미국과 유럽에서 더 많이 이용될까?잘 모르겠어.(결국 그들이 실제로 더 많은 편집자들을 끌어들이는지 나도 잘 모르겠어; 어딘가에 그것에 대한 연구가 있을 것 같아) EMsmile (토크) 06:45, 2020년 9월 9일 (UTC)[응답]

영어를 널리 사용하는 큰 나라 중 제안된 배너가 나타나는 나라는?--Wehwalt (talk) 14:06, 2020년 9월 9일 (UTC)[응답]

우리는 개발도상국에 초점을 맞출 것이다.우리는 이 목록(영어가 공용어인 영토주체 목록)을 참고할 수 있다. 9월에 위키사랑기념물이 현수막을 내걸고 있는 나라(여기 보이는 것)에서 모금 현수막이 있는 나라(즉, 모두 미국, GB, MZ, AU, CA, IE가 아니다)를 빼면 된다.위키 러브 기념물에는 베냉, 브라질, 이집트, 인도, 네팔, 우간다를 제외한 많은 개발도상국이 포함되어 있지 않다.따라서 단순성을 유지하고 아프리카, 아시아, 캐리비안 등의 국가만 다음과 같이 할 수 있다.

영어가 사실상의 공용어인 나라들

Nr	나라	알파-3 코드	지역	인구¹	1차 언어?
5	보츠와나	BWA	아프리카	1,882,000	아니요.
6	부룬디	BDI	아프리카	10,114,505	아니요.
7	카메룬	CMR	아프리카	22,534,532	아니요.
11	에스와티니	SWZ	아프리카	1,141,000	아니요.
13	감비아	GMB	아프리카	1,709,000	아니요.
14	가나	GHA	아프리카	27,000,000	예(언어 프랑카로 사용)
20	케냐	켄	아프리카	45,010,056	예(사업 및 교육 분야)
22	레소토	LSO	아프리카	2,008,000	아니요.
23	라이베리아	LBR	아프리카	3,750,000	네
24	말라위	MWI	아프리카	16,407,000	아니요.
29	나미비아	NAM	아프리카	2,074,000	아니요(언어 프랑카로 사용)
31	나이지리아	NGA	아프리카	182,202,000	예(언어 프랑카로 사용)
37	르완다	RWA	아프리카	11,262,564	아니오(그러나 공식 및 교육)
43	시에라리온	슬레	아프리카	6,190,280	네
46	남아프리카 공화국	ZAF	아프리카	54,956,900	네 (그리고 공식, 교육 및) 공식 경제에서의 언어 프랑카)
47	남수단	SSD	아프리카	12,340,000	아니요.
48	수단	SDN	아프리카	40,235,000	아니요.
49	탄자니아	TZA	아프리카	51,820,000	아니요.
53	우간다	UGA	아프리카	37,873,253	아니오(그러나 공식 및 교육)
55	잠비아	ZMB	아프리카	16,212,000	아니요.
56	짐바브웨	ZWE	아프리카	13,061,239	아니요(언어 프랑카로 사용)
27	모리셔스	MUS	아프리카 / 인도양	1,262,000	아니요.
42	세이셸	SYC	아프리카 / 인도양	87,000	아니요.
17	인도	인디아	아시아	1,247,540,000	아니오(그러나 공식 및 교육)
33	파키스탄	PAK	아시아	212,742,631	아니오(그러나 공식 및 교육)
36	의 국가	PHL	아시아	102,885,100	예(필리핀과 공동공식)
44	싱가포르	SGP	아시아	5,469,700	예(대부분 및 널리 사용되고 교육적으로 사용되는 언어 프랑카로 사용)
1	앤티가 바부다	ATG	카리브해	85,000	네
2	바하마	BHS	카리브해	331,000	네
3	바베이도스	BRB	카리브해	294,000	네
10	도미니카	DMA	카리브해	73,000	네
15	그레나다	GRD	카리브해	111,000	예(소규모 프랑스 크리올 인구 제외)
19	자메이카	잼	카리브해	2,714,000	네
38	세인트키츠네비스	크나	카리브해	50,000	네
39	세인트루시아	LCA	카리브해	165,000	네
40	세인트빈센트 그레나딘	VCT	카리브해	120,000	네
51	트리니다드 토바고	TTO	카리브해	1,333,000	네
4	벨리즈	BLZ	중앙아메리카	288,000	네

EMS마일 (대화) 05:02, 2020년 9월 10일 (UTC)[응답]

나는 정보에 약간 빠져 있는 것 같다.이렇게 표현하면, 미국, 캐나다, 영국, 호주, 뉴질랜드, 인도, 파키스탄, Eire 중 누가 제안된 배너를 가져갈 것인가?--Wehwalt (대화) 17:51, 2020년 9월 10일 (UTC)[응답하라]

사용자:Wehwalt 당신이 언급한 목록 중 오직 개발도상국만이 SDG를 사랑하는 위키 배너를 얻을 수 있기 때문에, 그것은 당신의 목록에서 파키스탄과 인도(이미 위키가 동시에 Mombumbles 배너를 가지고 있다면 인도는 아니다)이다.

대단히 감사합니다, 감사합니다만--위활트(대화) 06:51, 2020년 9월 11일 (UTC)[응답

미국 남부 거주자로서, 나는 "글로벌 사우스"라는 용어가 암시하는 어떤 유사점에도 크게 불쾌감을 느낀다.게다가 [지리학적으로 부정확하다]는 것이다.그것이 실제로 현수막에 등장할 생각은 없기를 바란다.-cobaltcigs 00:37, 2020년 9월 11일 (UTC)[응답]

User:cobaltcigs, yea well, global South라는 용어가 존재하며 자체적인 논란이 있으며 이는 위키백과 기사(Global South)에 잘 설명되어 있다.그것이 "붙어있는지" 여부는 두고 봐야 한다.마찬가지로, 호주에 사는 누군가는 불쾌감을 느낄 수 있다.어쨌든, 나는 개발도상국이라는 용어를 사용하는 것을 선호하지만, 그 용어에 반대하는 다른 사람들도 있다.여기 봐.쉽지 않다.이 현수막에는 '글로벌 사우스'라는 용어가 포함되지 않고 '개발도상국'이라는 용어를 사용하거나 실제로 이 지역을 전혀 언급하지 않을 것이다.내 제안은 다음과 같았다.짧은 버전은 "Wiki는 SDG를 사랑한다" 입니다. 긴 버전은 "Wikipedians는 온라인에서 만나 지속 가능한 개발 목표와 관련된 주제를 다루는 기사를 개선한다" 입니다.SDG는 공식적으로 전 세계를 위한 것이지만, 물론 SDG를 달성하기 위해 가장 어려운 직업을 가진 것은 개발도상국들이다.EMS마일 (대화) 06:34, 2020년 9월 11일 (UTC)[응답]

멋진 프로젝트 엠마일, 나는 그것을 좋아한다.2015년 유엔 회원 190여 명이 합의한 만큼 글로벌 목표 자체가 위키백과에서 철저히 다뤄질 만하다.2019년 위키미디어 운동은 스톡홀름에서 연례 국제 회의 위키마니아를 열었다.그 회의의 모토는 "함께 더 강하게:위키미디어, 자유로운 지식 및 지속 가능한 개발 목표."위키백과는 SDGs 프로젝트를 매우 좋아하는데, 1주일의 가상 편집자톤은 이 컨퍼런스의 자연스러운 후속 조치다.우리는 이 일을 한 것은 세상에 빚진 것이다.그것은 우리가 1년 전에 스톡홀름에 군중들과 함께 모여 우리가 무엇을 할 수 있는지에 대해 이야기한 후에 우리가 할 수 있는 최소한의 일이다.Ad Huikeshoven (talk) 14:28, 2020년 9월 15일 (UTC)[응답]

고마워, 애드 후이케스호벤.작년 위키마니아의 주제를 상기시키는 것은 정말 유용하다. - 만약 내가 위에 열거한 나라들을 위해 그 배너를 올린다면, 여러분 중 많은 사람들이 이 배너 제목에 동의하겠는가?:"Wiki는 SDG를 사랑한다" 9월 19일부터 26일까지 참가하십시오.위키피디아가 온라인에서 만나 '지속가능발전목표' 관련 기사를 개선한다.그 주에 우리가 상호작용을 위해 사용할 온라인 플랫폼은 Facebook by Facebook 입니다. 여기를 참조하십시오.EMsmile (대화) 15:53, 2020년 9월 15일 (UTC)[응답]

배너의 초안은 이제 여기에서 볼 수 있다(페이지 맨 위 참조).https://meta.wikimedia.org/w/index.php?title=Announcement_Universal_Language_Selector/ja&banner=WLSDG2020&force=1. 주로 개발도상국(위에서 논의한 바와 같이)을 중심으로 한 특정 국가에서만 전시될 것이다.현수막에 대해 어떻게 생각하십니까?너는 그것을 가지고 살 수 있니?개선을 위한 제안이 있으십니까?EMsmile (대화) 03:26, 2020년 9월 18일 (UTC)[응답]

WP는 정보를 위한 것이지 옹호하기 위한 것이 아니다.우리는 이 분야에서 우리의 취재 범위를 넓힐 필요가 있을지도 모르지만, 그것으로부터 도덕적 원칙을 만들어내거나, 지나치게 시각적으로 눈에 띄는 것을 주거나, WPED가 아닌 낯선 약어를 사용해서는 안 된다.그냥 기사를 써야지.만약 우리가 필요한 정보를 찾기 위해 조직해야 한다면, 그것은 좋은 일이지만, 우리는 실제 작업을 할 필요성과 함께 눈에 띄는 현수막을 전시하는 것을 착각해서는 안 된다. DGG (토크) 00:59, 2020년 9월 19일 (UTC)[응답]

그래서... "우리"가 이걸 하기로 결정했나?지금 일어나고 있는 일인가?— JohnFromPinckney (토크) 10:26, 2020년 9월 24일 (UTC)[응답]

나는 결코 답을 얻을 수 없을 것 같아. (괜찮아, 내 인생에 미해결 미스터리가 많아.) — 존프롬피니 (토크) 21:56, 2020년 9월 26일 (UTC)[응답]

어떤 현수막, 어떤 장소, 어떤 때라도 반대하라.위키백과 미션 선언문을 읽어보십시오.GenQuest 11:13, 2020년 9월 24일 (UTC)[응답]

나는 그러한 스팸, 옹호 또는 더 나쁜 것에 대한 반대 의견에 동의한다.여기에서 내 전체 의견을 참조하십시오: Village_pump_(정책)#Request_to_stop_non-enclopedic_self_adverting:

나는 위키의 일부분이고 X를 사랑하지 않는다.내 이름으로는 안 돼.

제젠(대화) 18:55, 2020년 9월 26일 (UTC)[응답]

SDGs는 (이제 그것이 의미하는 바를 찾아봤으니) 특히 일주일 동안만, Wiki가 분명히 내 이름으로 오랫동안 사랑한 것으로 보이는 퇴폐적인 기념물들(언제, 만약 있다면, 그 현수막은 언제 사라질까?) 보다 더 합리적인 것이다.그러나 문제의 주(州)인 9월 19일부터 26일까지가 막 지났다.이 실 좀 닫아 주시겠습니까?EMsmile, 나는 편집 대회가 잘 진행되었기를 바란다.비쇼넨 tålk 19:36, 2020년 9월 26일 (UTC)[답답하다]

고마워, 비쇼넨네, 지금 닫을 수 있는 실입니다(스레드는 어떻게 닫지?)엠스마일 (대화) 02:20, 2020년 9월 27일 (UTC)[응답]

{{archive top}과{archive bottom}} 템플리트를 사용할 수 있다.제가 하죠.비쇼넨 tålk 08:11, 2020년 9월 27일(UTC)[답답하다]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

A 클래스 주제 표시

안녕 여러분, 내 이름은 Revestalic이야.

요컨대 A급 기사에 대한 A급 토픽을 전시해야 할까?

내가 J 밀번, 니나 시모네, 부산 방어선 전투와 흥미로운 토론을 시작하기 전에, 토픽이 없는 A급 선수들은 히로시마와 나가사키의 원자 폭탄 테러에 대한 것을 포함시킨 반면, 이 토픽의 표시는 일관성이 없다.

빗자루(REBESTALIC IS A TOADY Alert)인 J Milburn은 '그들의 포함을 권하는 어떤 정책이나 가이드라인을 알지 못했다'고 언급했다.어쩌면 지금이 그런 정책을 세울 때일까?

〇 Rebestalic^{[leave a message....]} 00:43, 2020년 8월 27일 (UTC)[응답]

J 밀번, 빗자루(REBESTALIC IS A TOADY Alert) 네?ST47(토크) 05:02, 2020년 8월 27일(UTC)[응답하라]

나는 이것이 J Milburn의 관리자 지위를 언급하는 약간의 가벼운 유머라고 믿는다.– Teratix₵ 05:45, 2020년 8월 27일 (UTC)[응답]

짧은 배경으로서, 우연히 "토피콘"이 있는 A급 기사를 우연히 발견하여 삭제하였다.나중에 확인해보니 15개 정도의 기사가 A급 토픽온을 갖고 있어 모두 삭제했다.이 기사들은 대부분 군대 역사였지만 A급이 아닌 것을 포함해 몇 가지 더 있었다.주요 기사, 특집 목록 및 GA는 일상적으로 토픽을 가지고 있다.제 머리 위로는, 우리가 GA를 위한 주제들을 소개했을 때 -- 제 기억에는 있었지만, 최근에는 아니었죠 -- 그것에 대해 집중적인 논의가 있었다.A급 기사에 토픽론이 있어야 하는지에 대해서는 그다지 강한 의견을 갖고 있지 않지만(A급 기사들이 FA나 GA만큼 집중화되거나 코드화되지 않는다는 이유만으로 적어도 내가 볼 수 있는 한에는 A급 기사들이 더해져야 한다고는 생각하지 않는다.그렇게 되려면 그에 대한 중심적인 논의가 있어야 한다.만약 이것이 그 중심적인 토론이라면, 그렇게 하시오.조시 밀번 (대화) 07:26, 2020년 8월 27일 (UTC)[응답]

@ST47:내가 할 수 있는 한 명확하지 못한 것에 대한 사과, Teratix가 나의 끔찍한 유머 Revestalic^{[leave a message....]} 21:22, 2020년 8월 27일 (UTC)[응답하라]에 옳다.

분권화가 의심스럽지만 기울어진 지지.– John M Wolfson (대화 • 기여) 23:58, 2020년 8월 27일 (UTC)[응답]
의견: MILHIST와 별도로 A등급 검토를 적극적으로 실시하는 프로젝트는 무엇인가?그들의 A급 기사의 품질은 비견될 만한가?그러한 모든 프로젝트에 대해 토피콘이 일관되게 표시되어야 한다.그렇지 않으면 프로젝트별로 승인이 날 수 있다. --Paul_012 (대화) 09:38, 2020년 8월 28일 (UTC)[응답]

폴 012야, 내가 위키피디아에 가입한 직후에 이것에 대해 실제로 질문을 했어!찻집에서였는데, 환지기가 A급 기사 카테고리로 나를 안내했다.방금 살펴봤는데, 대부분 빈 카테고리에 불과했다.니나 시몬이 어느 범주에 들어맞는지 전혀 알지 못하는데, 왜냐하면 그녀가 군대 역사와 별로 관련이 없었던 것 같기 때문이다.

그러나 내용 평가 페이지의 등급 섹션을 고려해 보십시오. 클래스 코드가 있는 열에는 피처링 기사, 피처링 리스트, 좋은 기사 및 A 클래스 필드가 모두 토픽을 포함하지만(B-클래스, C-클래스 등) 모든 불량 등급은 그렇지 않다.왜 '좋은 리스트' 같은 것도 없는 걸까?하지만 내 실에 네 의견을 말해줘서 고마워!나에게 매우 흥분되는 Revestalic^{[leave a message....]} 11:10, 2020년 8월 28일 (UTC)[응답]

기대기 - 나는 적절하고 중앙 집중화된 동료 검토에 기초하여 플러스/스타만 가지는 것을 선호한다.A-클래스가 작동하려면, 우리는 그들에게 제공하고자 하는 각각의 프로젝트를 검토하고 그 프로젝트가 그 검토를 처리할 수 있을 만큼 충분한 시스템을 가지고 있다고 판단해야 할 것이다. 아마도 그 프로젝트의 외부적인 상장폐지 절차를 가지고 있을 것이다.코백베어 (토크) 14:23, 2020년 8월 30일 (UTC)[응답]
설명:우리는 A클래스를 지정함으로써 무엇을 달성하고자 하는지를 근본적인 차원에서 파악해야 이 질문에 답할 수 있다.토피콘을 건너오는 독자들이 그것을 구별할 수 있으리라고 기대하기는커녕 A클래스가 GA보다 높은지 낮은지조차 우리가 동의할 수 있을지 모르겠다.(여기서 나의 간단한 질문 외에) A급 기사의 비호 및 군사 역사 기사의 검토를 GA 내에서 일종의 하위 트랙으로 하는 것에 대한 논의가 있었는가?

그렇긴 하지만, 일반적으로 말해서, 나는 (과거의 내가 그랬던 것처럼) 기사 등급을 독자들이 더 많이 이용할 수 있도록 하는 것을 지지한다.그들이 일반적으로 신뢰할 수 있는 백과사전의 어느 부분을 우리가 분명히 하고 있고 아직 공사 중인지를 분명히 하는 것이 신뢰 유지에 중요하다. 걸림돌은 시청률이 충분히 정확하다는 것을 확실히 하고 있으며, 특히 스펙트럼의 중간에 있는 시청률에 문제가 있다.{{u Sdkb}}}20:51, 2020년 9월 3일(UTC)[응답]

린은 반대한다.A급 평가를 받는 것은 기사 품질을 잘 나타내는 것이지만, 그것은 어떠한 통일된 또는 표준화된 동료 검토 과정의 산물이 아니다.플레이스(기사의 토크 페이지)가 있지만, (모든 위키피디아 대상 평가와 마찬가지로) 완전히 현지화된다는 점에서 GA나 FA와는 다르다.커뮤니티 차원의 지정과 같은 곳으로 올려서는 안 된다. --ExParte 16:19, 2020년 9월 5일 (UTC)[응답]

내 표를 기울어진 지지로 바꾸는 중..나는 A등급 등급과 같은 통일된 표준으로 무언가를 올리는 것에 대해 여전히 약간의 의구심을 갖고 있지만, 위키프로젝트는 아마도 그들의 관점에 있는 기사의 신뢰성을 평가할 수 있는 가장 적합한 자격이 있을 것이다.그리고 어떤 기사가 그 지정을 받았을 때, 독자들이 그것에 얼마나 기댈 것인가를 결정할 때 그것을 고려할 수 있도록 하는 것은 유용한 일이다. --ExParte 07:56, 2020년 9월 9일 (UTC)[응답]

여기까지 와줘서 고마워, 엑 파르트!레베스타닉^{[leave a message....]} 01:51, 2020년 9월 11일 (UTC)[응답]

나는 밀히스트 이외의 A급 공정에 대해 알지 못한다.있어?만약 그들이 밀히스트사가 하는 것과 동등하다면 나는 이 아이디어를 받아들일 것이다.MilHist만이 활동적인 과정을 가지고 있다면 나는 반대한다.Best, Barkeep49 (대화) 00:42, 2020년 9월 24일 (UTC)[응답]
비디오 게임은 GA를 지지하지 않았고, 대부분의 다른 위키프로젝트들은 기본적으로 A급에 대한 흥미/관련된 평가를 받지 않았다고 추측할 수 있다.대부분 A급 시스템이 작동하는 MILHIST와 허리케인처럼 보인다. --Izno (대화) 01:29, 2020년 9월 24일 (UTC)[응답]
와우, 그럼 우리 정말 기능적으로 두 개의 프로젝트만 할 수 있는 수업이 있는 거야?만약 이것이 위키피디아를 제외한 다른 곳이었다면, A클래스는 오래 전에 더 이상 사용되지 않았을 것이다.{{u Sdkb}}^talk 02:36, 2020년 9월 24일 (UTC)[응답]
이전에도 논의가 있었다.그렇지 않은 가장 큰 이유는 품질 수준이 위키프로젝트가 (지역사회가 제공해야 하는 것이 아니라) 위키프로젝트가 제공해야 할 최고로 사물을 평가할 수 있게 해주기 때문이다.표면적으로는 GA/FA가 요구하는 것과 다른 초점을 표시하기 위함이기도 하다.마지막으로, 그들은 GA/FA가 가지고 있는 서로 다른 관심사에 대한 그들의 질을 높이기 위한 좋은 발판이다.그런 그룹들에게 효과가 있다면 시스템을 그대로 두는 것이 근본적인 문제는 아니라고 본다. --Izno (대화) 02:48, 2020년 9월 24일 (UTC)[응답]
A급 기사가 실린 프로젝트는 밀리터리 히스토리(629건), 사이클로인(133건), 미국 로드(22건), 화학(8건), 자동차(7건), 일본(7건), 카니발(3건), 레바논(2건), 사이언스 픽션(2건) 등이다.약 3/4가 처음 두 곳에 속하는 반면, 또 다른 250여 개가 수십 개의 프로젝트에 흩어져 있다.호크예7 (토론) 03:10, 2020년 9월 24일 (UTC)[응답]
고체는 반대한다.이 분류는 위키프로젝트에 특정하며, GA와 FA가 제공하는 커뮤니티 검토 프로세스를 대표하지 않는다.(그리고, 분류는 기본적으로 2개의 특정 프로젝트 이외에서는 사용되지 않는다.) --이즈노 (토크) 02:48, 2020년 9월 24일 (UTC)[응답]
FA는 이것을 제공하지 않기 때문에 A학급은 우리가 가지고 있는 가장 높은 검토 과정이다.호크예7 (토론) 03:10, 2020년 9월 24일 (UTC)[응답]
한 프로젝트에서만 실제로 사용되므로 반대하십시오.밀히스트의 평가를 더 넓은 커뮤니티에서 사용하는 것에 매핑할 수 있는 방법을 찾는 것이 좋을 것이다(예: 밀히스트의 A급 기사를 GA로 자동 인식하는 프로세스를 제공하는 것).– 조 (대화) 10:04, 2020년 9월 24일 (UTC)[응답]

개별 위키백과 과목 평가 등급에 반대한다.에어콘 (토크) 06:08, 2020년 9월 28일 (UTC)[응답]

기사 Infobox에 IMDb & Roat 토마토 등급 추가(가능한 경우 어디서든)

현재 위키피디아에 있는 영화, 단편 영화, 웹 시리즈 등에 관한 어떤 기사(또는 극소수)도 이 기사의 Infobox에서 IMDb & Rottle 토마토와 같은 저명한 출처에서 제공하는 등급을 포함하고 있지 않다.많은 사람들이 위키피디아를 방문하여 영화 <비평가적 리셉션>에 대한 가능한 모든 정보를 얻는다.어떤 웹사이트에 대해 쓰여진 대부분의 기사들은 알렉사 순위를 포함하고 있다.만약 그런 기사들이 알렉사 순위를 포함할 수 있다면, 나는 영화에 관한 기사들은 그들의 IMDb & Rottle 토마토 등급들을 포함해야 한다고 믿는다.수카리아 (대화) 18:11, 2020년 8월 17일 (UTC)[응답]

나는 별도의 논의를 위해 이 실을 아래 부분들로 나누었다.해당 섹션에 추가 의견을 제시하십시오.{{u Sdkb}}19:12, 2020년 8월 17일 (UTC)[응답]

이 논의의 주제는 제안과 관련한 추가적인 혼란을 피하기 위해 '인포박스'라는 단어를 포함하도록 편집되었다.수카리아 (대화) 12시 4분, 2020년 8월 18일 (UTC)[응답]

조사: infobox의 IMDb

infobox에서 IMDb를 사용하지 않는 것에 대한 합의.제안자 말고는 아무도 지지하지 않는다.이 논의에 앞서 최근의 합의가 있었다(WP:RSP#IMDb) IMDb는 사용자가 생성하기 때문에 등급에 대해 신뢰할 수 없다는 것이다.여기서는 이 결정을 뒤집거나, 그러한 내용을 infobox에 포함시키자는 데 의견 일치가 없다. — 빌로프 (대화) 21:27, 2020년 9월 28일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

믿을 수 없도록 블록 조작의 대상이 되는 사용자 생성 데이터 출처인 만큼 좋은 생각이 아닌 것 같다.이 등급들을 순찰할 수도 없고, 그 등급이 포함된 노트(예: "이 등급은 조작된 것으로 알려져 있다")를 함께 포함할 수도 없다. 왜냐하면 그때는 신뢰할 수 없는 데이터를 포함하기 때문이다.--조름 (대화) 18:25, 2020년 8월 17일 (UTC)[응답]
@Jorm: 나는 이 실을 더 잘 정리하기 위해 하위섹션을 만들었고, 여기에 당신의 코멘트를 놓았다.필요하다면 얼마든지 리액터링하십시오.{{u Sdkb}}} 19:18, 2020년 8월 17일(UTC)[답글]
흠, 나는 항상 이 등급을 조금밖에 받지 않아.IMDb 등급은 투표를 귀찮게 할 수 있는 사람들을 대표하고 있으며, 로튼 토마토에 대한 등급 또한 주관적이다.주류 비평가들의 후기를 고수하는 것이 최선이다.--1998년 8월 17일 (UTC)[응답]
@Ianmacm:나는 이 실을 더 잘 정리하기 위해 방금 하위섹션을 만들었고, 여기에 당신의 코멘트를 넣었어.필요하다면 얼마든지 리액터링하십시오.{{u Sdkb}}} 19:18, 2020년 8월 17일(UTC)[답글]
반대하라, 왜냐하면 그들은 조작의 대상이 될 수 있고 또 조작의 대상이 되었기 때문이다.예: 참조워싱턴포스트의 트롤이 '고스트버스터즈' 리부트를 끌어내리기 위해 할 수 있는 모든 것을 다하고 있고, IMDb 시청률이 어떻게 시스템적으로 남성의 선호에 치우쳐 있는지를 분석하는 파이브서티어티스트의 분석은.{{u Sdkb}}19:12, 2020년 8월 17일 (UTC)[응답]
반대 IMDB는 사용자 정의 점수여서 폭탄 및 기타 요인에 취약하므로 신뢰할 수 있는 측정치로 간주해서는 안 된다.(그러나 그것은 단 하나의 문제일 뿐이다...) 사용자 검토 기반 점수는 일반적으로 제3자(검토 폭탄과 같은)가 애초에 지적하지 않는 한 어떤 기사에도 포함되지 않는다. --Masem (t) 19:38, 202년 8월 17일.0 (UTC)[응답하라]
과거 토론 때마다 파일프로젝트에서 반대한다.마넷D 토크 20:00, 2020년 8월 17일 (UTC)[응답]
infobox에 IMDB 등급을 포함하면 MOS를 위반할 수 있음:FILM#관중_응답 자료에는 "인터넷 동영상 데이터베이스, 메타크리트어 또는 로튼 토마토와 같은 웹 사이트에 제출된 사용자 등급은 표 쌓기와 인구통계학적 왜곡에 취약하므로 포함하지 마십시오."라고 나와 있다.베티 로건 (대화) 23:18, 2020년 8월 17일 (UTC)[응답]
매우 조작하기 쉬운 반대.그 링크는 내가 가장 좋아하는 유투브 비디오 중 하나를 보여준다...하지만 여러분은 IMDb를 보면, 그 점수가 다수의 유튜브 관찰자들이 점수를 조작한 결과라는 사실을 무시한 채, 여러분이 생각하듯이, IMDb에서 가장 높은 평가를 받은 영화다.또한, IMDb를 infobox에 넣는 것은 사람들이 그것을 다른 것에 사용하도록 격려할 뿐인데, 그것은 RS가 아니기 때문에 우리가 이미 맞서 싸우려고 하고 있다.선장이크 ek 21:36, 2020년 8월 19일 (UTC)[응답]
반대 IMDb는 일반적으로 신뢰할 수 있는 공급원이 아니며 매우 제한된 상황을 제외하고는 사용을 금지해야 한다.컬런³²⁸ 2020년 8월 19일 21시 40분 토론하자[응답하라]
반대 믿을 수 없는 출처.물품 공간에 사용을 권장해서는 안 된다. --Malcolmxl5 (대화) 14:03, 2020년 8월 25일 (UTC)[응답]
절대 반대: 위의 모든 것에 대해.누가 스노우 닫을 수 있어?GenQuest 18:16, 2020년 8월 30일 (UTC)[응답]
우리가 이것들을 인용하지 않는 것과 같은 이유로 강력하게 반대하라.그들을 ELs에 허락하는 것만으로 충분하다.DES 22:26, 2020년 9월 8일 (UTC)[응답]
위의 모든 사항에 대해 강력하게 반대하십시오.엘 밀로 (대화) 22:45, 2020년 9월 8일 (UTC)[응답]
반대 0 데 투티 반대.위에서 언급했듯이, 이것은 거의 가능한 한 많은 수준에서 좋지 않은 생각이다.Qwirkle (대화) 01:05, 2020년 9월 9일 (UTC)[응답]
반대한다. 절대 청중의 리뷰를 믿지 말라.지금까지. --세계의 기쁨 (대화) 12:17, 2020년 9월 16일 (UTC)[응답]
강하게 반대한다. 나는 이 제안이 올바른 의도로 만들어졌다고 생각한다. 그러나 투표 서핑은 IMDB에서 사용자가 만든 사이트일 뿐만 아니라 알려진 문제다.당신은 영화를 보지도 않고 리뷰를 남길 수 있고 따라서 리뷰 통계학은 상당히 왜곡되어 있다.인터앤안트로 (대화) 01:44, 2020년 9월 25일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

조사: 비평가들은 infobox의 집계를 검토한다.

비평가들을 사용하지 않는 것에 대한 합의는 Rotten 토마토와 메타크리틱을 포함하되 이에 국한되지 않는 infobox의 집계를 검토한다.그러한 집계는 인포박스에 적합한 종류의 사실적인 내용이 아니라는 데 의견이 일치한다.추가 컨텍스트 없이 infobox로 표시할 경우 어떤 개별 집계 방법론도 적절하지 않다는 우려가 제기되었다.(비관리자 폐쇄) — Bilorv (대화) 21:31, 2020년 9월 28일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

예: 썩은 토마토, 메타크리트어

독자들에게 적절한 정보이기 때문에 이 점수들 중 하나를 추가하는 것을 지지하라.{{u Sdkb}}19:12, 2020년 8월 17일 (UTC)[응답]
반대 적어도 비디오 게임에서 나오는 것은, 단지 총점만을 제시하는 것이 게임의 리셉션을 어떻게 받아들여야 하는지에 대한 잘못된 말이라는 너무 많은 경우가 있다.점수를 다른 리뷰와 코멘트와 함께 제시하여 관점을 부여해야 한다. (최근의 사례는 The Last of Us II).영화에서도 마찬가지라고 말할 수 있을 것이다; 비판적으로 판을 친 영화는 단 한 점으로도 포착되지 않는 관객의 호감일 수 있다. --Masem (t) 19:40, 2020년 8월 17일 (UTC)[응답]
과거 토론 때마다 파일프로젝트에서 반대한다.마넷D 토크 20:00, 2020년 8월 17일 (UTC)[응답]
반대 인포박스는 사실을 위한 것이다.로튼 토마토와 메타크리틱은 리뷰 집계기 때문에, 그들의 점수는 비평가들이 승인하고 세는 "주관"과 더불어 모든 리뷰의 주관성을 동반한다.두 점수를 모두 infobox에 넣는 것은 그들이 해서는 안 되는 사실의 질을 제공할 것이다.엘 밀로 (대화) 20:07, 2020년 8월 17일 (UTC)[응답]
나는 인포박스가 사실에 입각한 정보에 가장 적합하다는 엘 밀로의 의견에 반대한다.이 설문 조사의 바로 다음 질문(즉, Infobox에서 RT 또는 MC를 사용해야 하는가?)집계기 포함에 대한 주장을 약화시키다.WP별:AGG는 비판적인 수신에 대한 단일 권한은 없다.때때로 RT와 MC는 서로 다른 방법론과 다른 리뷰를 샘플링하기 때문에 다른 결론에 도달할 수 있다.또한, 이러한 집계업자들은 외국 영화(표본 크기가 너무 작을 때가 많다)나 오래된 영화(평론가는 종종 현대적인 평론과 수정주의적인 평론의 혼합을 의미하며, 특히 당신은 초기 리셉션을 고전 영화를 위해 서 있는 현대적인 것과 비교하기를 원한다)에서는 특별히 잘 작동하지 않는다.베티 로건 (대화) 23:25, 2020년 8월 17일 (UTC)[응답]
반대 우리는 전문 영화 평론가들의 평가를 요약해야 한다. 집계자들이 우리를 위해 요약하도록 허용하는 대신에 말이다.컬런³²⁸ 2020년 8월 19일 21:43 (UTC) 토론하자[응답하라]
반대: InfoBox는 사실에 대한 것이며, 반드시 모든 사실에 대한 것도 아니다.사실 InfoBoxes는 선택 사항이다.퍼 크리프.GenQuest 18:19, 2020년 8월 30일 (UTC)[응답]
반대 나는 이것이 결코 "가능한 한" 것이 아니라, 인포박스에 들어가서는 안 된다고 생각한다. 그러한 시청률을 유용한 방법으로 제시하기 위해서는 너무 많은 맥락이 필요하다.있다면 기사 산문에도 있어야 한다.DES 13:34, 2020년 9월 9일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

조사: 썩은 토마토 vs.Infobox용 메타크리트어

모든 비평가 검토 집계가 infobox에 적합하지 않다는 위의 근접성 때문에 실시되지 않은 결과. (비관리자 폐쇄) — Bilorv (대화) 21:34, 2020년 9월 28일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

만약 우리가 위에서 비평가 검토 집계를 포함하기로 결정한다면, 우리는 어떤 서비스를 포함시켜야 하는가?

나는 이것에 대해 대담한 결정을 내릴 준비가 되지 않았지만, 그것들 사이에서 고민해야 할 요소들은 로튼 토마토가 더 인기 있지만 메타크리트틱은 통계를 더 잘 활용한다는 것이다.{{u Sdkb}}19:12, 2020년 8월 17일 (UTC)[응답]

위치가 잘못됨!votes

과거 토론 때마다 파일프로젝트에서 반대한다.마넷DTalk 20:00, 2020년 8월 17일 (UTC)[응답]
마넷디, 이건 지지/반대 섹션이 아니라 로튼 토마토와 메타크리트릭 사이의 A/B 질문이야당신이 이미 표기한 위의 섹션은 둘 중 하나를 포함시킬 것인가를 묻는 섹션이다.{{u Sdkb}}} 19:04, 2020년 8월 18일 (UTC)[응답]
- 나는 둘 다 반대하기 때문에 나의 이전 직책이 정확하다.마넷D 토크 20:02, 2020년 8월 18일 (UTC)[응답]
둘 다 반대하다.컬렌³²⁸ 21:44, 2020년 8월 19일 (UTC) 토론하자[응답하라]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

총론

이에 대한 정책 및 지침은 이미 존재한다는 점에 유의하십시오.위키백과 참조:Style/Film#Critical 응답 및 MOS 설명서 :TVREECTION과 이 에세이 위키백과:집계자 검토.OP는 영화 기사 중 많은 비율이 RT 등급을 포함하고 있다는 것을 알지 못할 수 있다.IMDb는 단순히 팬 투표일 뿐 비판적이거나 학술적인 가치가 없기 때문에 포함되지 않아야 한다.마넷D 토크 19:16, 2020년 8월 17일 (UTC)[응답]

@MarnettD:나는 OP가 주로 infobox에 대해 묻고 있다고 생각한다.나는 단지 그것을 분명히 하기 위해 하위섹션들을 수정했다.여기서 공격적으로 리팩터링을 해서 미안해. 너무 멀리 떨어지기 전에 집중/정의된 경로에 이걸 놓으려고 해.수카리아, 무슨 문제가 있으면 알려줘.{{u Sdkb}}^talk 19:26, 2020년 8월 17일 (UTC)[응답]

~~OP의 진술에서 어느 지점도 사용된 infobox라는 단어는 없다.~~만약 그것이 그들이 의미하는 것이라면, 이것은 여러 번 파일프로젝트에서 논의되었고 거부되었다는 것을 알아두십시오.아마도 베티 로건이나 에릭(둘 다 나보다 훨씬 더 좋은 기억을 가지고 있는 사람)이 아카이브된 토론으로 당신을 안내할 수 있을 것이다.마넷DTAK 19:32, 2020년 8월 17일 (UTC)[응답]

사실 나사산의 머리글에는 "IMDb & 썩은 토마토 등급을 기사(가능한 곳이라면 어디든 포함)에 추가"(내 것을 강조함)라고 분명히 적혀있기 때문에 "~~인포박스"~~라는 단어를 추가하기 위해 ~~부제목들을 리팩터링하는 것~~은 단지 ~~이슈를 혼란~~스럽게 만들 ~~뿐이다.~~나는 이것에 대한 정책이 이미 존재하기 때문에 이 실을 닫을 것을 제안하고 싶다.마넷DTAK 19:43, 2020년 8월 17일 (UTC)[응답]

여기에 '인포박스'가 추가됐다.버스정류장 (대화)19:48, 2020년 8월 17일 (UTC)[응답]

에러에 대한 버스정류장 사과문을 잘못 읽어줘서 고마워.실의 제목은 혼란의 일부분이다.나는 아직 과거의 논의를 찾지 못했지만 WP를 찾았다.FLIMATING WhIXh도 WP의 일부분이다.모스필름. 매넷DTAK 19:54, 2020년 8월 17일 (UTC)[응답]

다음은 과거 토론 템플릿 토크:Infobox 필름/아카이브 24#로텐 토마토.또 다른 문제는 일단 하나의 종합 웹사이트를 위한 공간을 만들고 나면, 여러분은 그것들을 계속 추가해야 하고, 이것은 항상 피해야 하는 것, 즉 Infobox bloat를 야기시킨다.마넷DTAK 19:59, 2020년 8월 17일 (UTC)[응답]

만약 우리가 인포박스에 어떤 등급을 추가해야 하는지에 대한 합의에 도달한다면, 우리는 어떤 집계 웹사이트가 가장 신뢰할 수 있는 웹사이트가 될 수 있는지에 대한 논의를 계속할 수 있고, 대부분의 위키백과 편집자들이 인식할 수 있는 몇 개의 집계 웹사이트의 등급을 허용하는 정책을 고수할 수 있다.수카랴 (대화) 12시 17분, 2020년 8월 18일 (UTC)[응답]

불편을 끼쳐드려 죄송하고, 제목을 좀 더 유익하게 만들기 위해 편집한 실 제목으로 이 문제를 강조해 주셔서 감사드린다.수카랴 (대화) 12시 17분, 2020년 8월 18일 (UTC)[응답]

이 실이 아무데도 안 가는 것 같아서 스노우 닫아도 괜찮아.우리는 언젠가 신체에서 RT 대 메타크리트틱에 대해 토론하고 싶을지도 모르며, 언제나 그렇듯이 과거의 합의사항의 문서화를 개선하기 위해 해야 할 많은 일들이 있다.{{u Sdkb}}}^talk 05:52, 2020년 8월 18일 (UTC)[응답]
OTOH, 특히 IMDb는 수천 개의 기사에서 ==외부 링크===로 추가된다.템플릿과 비슷한 작은 바닥글 바에서 보는 게 낫겠어.의료 리소스(일반적으로 매우 크지 않은 랩톱 화면에서 단일 라인을 차지하는 경우, 많은 옵션이 있지만 특정 주제에 적용되는 경우는 극히 일부에 불과하기 때문이다.나는 WP에서 다음과 같이 물었다.이것에 대한 BOTREQ는, 우리가 이러한 외부 링크를 제공할 수 있는 무언가를 만들기를 원했다면, 그러나 각각의 항목을 글머리표 리스트에 별도 항목으로 나열하는 것보다 더 적은 공간을 차지한다면, 그들은 대부분의 기사가 봇에 의해 더 작은 형식으로 변환될 수 있다고 생각했다.WhatamIdoing (대화) 03:51, 2020년 8월 20일 (UTC)[응답]

나는 제안으로 이 ^^를 확실히 지지할 것이다.GenQuest^{"Talk to Me"} 18:21, 2020년 8월 30일 (UTC)[응답]

그런 종류의 변화는 현장 전체의 합의가 필요할 것이고, 나는 그것을 얻기가 어려울 것이라고 생각한다.DES 13:36, 2020년 9월 9일 (UTC)[응답하라]

나는 인포박스가 이런 종류의 콘텐트에 절대적으로 잘못된 장소라고 생각한다.로튼 토마토, iMDB, 메타크리트틱 등과 연계하여 총 평점을 포함하는 "중요 수신" 섹션과 같은 부분에 표준화된 템플릿의 여지가 있을 수 있지만, 나는 그것이 위키프로젝트 필름/시네마/영화/그 어떤 것에 대해서도 양식적이고 운영적인 결정이 될 것이라고 제안하고 싶다.반아이작_WS^cont 01:52, 2020년 9월 25일 (UTC)[응답]
Vanisaac과 Inter&anthro, 당신의 논평은 선의의 것이었지만, 합의는 이미 명확했고 토론은 몇 주 전에 끝났기 때문에 유감스럽게도 그들은 이 실을 막 보관하려고 할 때 보관 시계를 재설정하여 이 페이지를 더 오랫동안 어지럽혔다.다음 번에는 그냥 무시하고 보관하는 것을 고려하십시오.{{u Sdkb}}}^talk20:05, 2020년 9월 26일 (UTC)[응답]
내가 눈치채지 못한 것에 대해 후회가 된다.불편을 끼쳐드려 죄송합니다만.인터앤안트로 (대화) 20:08, 2020년 9월 26일 (UTC)[응답]

@Sdkb:나는 당신이 나를 죽은 말을 구타하는 것으로 폄하하지 말아 달라고 부탁하고 싶다.내 논평에서 나는 그 제안이 죽었을 수도 있지만, 그것이 다루려고 했던 문제들은 여전히 살아있고 잘 남아 있기 때문에, 건설적인 방향으로 나아가야 한다는 생각을 구체적으로 덧붙였다.우리는 협력적인 환경에서 서로 그 배려를 해야 한다.토론에 추가되는 것을 방지하려면 토론을 닫거나 보관하는 것이 목적이다.반아이작_WS^cont 21:26, 2020년 9월 26일 (UTC)[응답]
Vanisaac, 미안, 나는 그것을 폄하하려는 것이 아니었고 그 에세이가 가장 적절한 연결 고리가 아니었다.내 논평의 자극은 여기서의 긴 토론이 명백한 눈이 내리자마자 실을 줄였어야 했던 편집자 시간을 매우 효율적으로 사용하지 않았다는 것을 관찰하는 데서 비롯되었다.그 펌프(그리고 일반적으로 위키피디아)는 잘 축소된 메커니즘을 가지고 있지 않아서 이런 실들이 자주 생기게 된다; 나는 결국 우리가 그 보다 근본적인 문제를 더 잘 다룰 수 있는 방법을 찾기를 바란다.{{u Sdkb}}^talk 21:47, 2020년 9월 26일 (UTC)[응답]
Sdkb, 괜찮아.우리 모두는 함께 일할 때 약간의 은총이 필요하며, 나는 아마도 데드호스에 대한 언급을 너무 개인적으로 받아들였을 것이다.추가하려는 경우{{User:ClueBot III/ArchiveNow}}이 섹션의 맨 위에, 두 번의 인터로케이션 전에 마지막으로 추가된 것은 9일 전이었고, 이미 자동 보관을 시작했을 것이다.그렇지 않으면 내일 보관해 놓을게.반아이작_WS^cont 22:08, 2020년 9월 26일 (UTC)[응답]

제안:깨진 {{DISPLAYTITLE}}을(를) 추가하기 전에 편집자에게 물러날 수 있는 기회 제공

최근 기사 페이지에서 {{DISPLAYTITLE} 마법 단어를 잘못 사용한 새롭고 순진한 편집자들이 절반 이상을 차지하고 있다.이것은 다른 편집자의 시간을 낭비한다. 왜냐하면 우리는 그들의 뒷정리를 해야 하기 때문이다.

편집자에게 경고하고 페이지를 카테고리:에 넣을 수 있는 편집을 하기 전에 물러날 수 있는 기회를 줄 것을 제안한다.DisplayTITLE 수정사항이 허용되지 않는 페이지.

이렇게 하려면 편집마다 0이 아닌 비용이 드는 편집 필터가 필요할 것 같아, 그래서 내가 먼저 여기서 제안하는 거야. davidwr/(토크)/(contracties) 18:13, 2020년 9월 29일(UTC)[응답]

@Davidwr:간단히 보면, 그 범주의 많은 페이지들이 사용자 페이지용인 것 같다.아마도 첫 번째 단계는 사용자 공간에서 템플릿을 허용하지 않고 나머지 문제를 해결하는 것이 될 것이다.루돌프레드 (대화) 18:32, 2020년 9월 29일 (UTC)[응답]

봇이 사용자/사용자 대화를 통해 실행해서 모두 제거했으면 좋겠어.FWIW, 425는 "Draft:" 우주에 있다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 9월 29일 (UTC)[응답]

사실, 나는 사용자: 그리고 초안: 공간에서의 잘못된 사용에 대해 크게 걱정하지 않지만, 사용자에게 새로운 사용자-페이지와 초안 페이지를 그 범주에 추가하는 것을 경고하는 것은 나쁘지 않을 것이다.나는 메인 스페이스가 더 걱정돼.만약 여러분이 봇을 가지고 있다면, 아마도 가장 쉽게 할 수 있는 일은 한 시간에 한두 번 그 범주의 메인 스페이스 페이지에 대해 봇을 실행하는 것이다.페이지 이동을 기대하여 누군가가 변경을 하거나 자신의 실수를 되돌릴 경우에 대비하여 15분간의 유예기간을 주겠다.davidwr/(talk)/(contracts) 20:15, 2020년 9월 29일(UTC)[응답]

기사공간에 이런 일이 얼마나 많은가?처음 몇 페이지에는 사용자 공간이 가장 많고 나머지는 대부분 초안 공간에 있는 카테고리를 살펴볼 준비가 안 된 것 같아 걱정이다.만약 새롭고 순진한 편집자들이 반을 넘는다면 그것은 중요하지 않다: 그것은 중요한 절대 숫자다.필 브리저 (대화)20:30, 2020년 9월 29일 (UTC)[응답]

1분 전만 해도 실시간 리스트[1]는 언제든지 확인할 수 있다.카테고리 설명 페이지에 모든 네임스페이스에 있는 링크와 버전에 대한 링크가 있다.참고 - "최근"이 아닌 목록에 항목이 누락되었을 수 있지만, 그 이유는 잘 모르겠다.

그 이유는 내가 내 감시목록에 있는 카테고리를 가지고 있고 나와 다른 사람들이 하루에 몇 번씩 최소 몇 번씩 기사 페이지를 그 카테고리로 옮길 때 엉뚱하게 놀기 때문이다.저 "두더지 때려"는 오프닝 코멘트에서 언급했던 "다른 편집자의 시간"이다.davidwr/(토크)/(기고) 21:51, 2020년 9월 29일 (UTC)[응답]

@Davidwr and Phil Bridger:범주를 더 쉽게 충돌하도록 하려면 MediaWiki를 편집하십시오.서로 다른 네임스페이스에 있는 페이지를 다른 범주에 넣기 위해 제한된 표시제.방금 테스트위키에 설정했어MediaWiki:제한된 표시 제목이 무시되므로, 이제 testwiki:범주:제목이 무시된 기사 및 기타 모든 항목이 테스트위키:범주:제목이 무시된 페이지.아마 우리도 여기서 그런 일을 할 수 있을 거야.잭mcbarn (대화) 06:39, 2020년 9월 30일 (UTC)[응답하라]

그리고 놀랍게도, 내가 처음 확인한 5개의 사용자 공간은 모두 디스플레이 제목에 대한 손 비주얼 편집기 확인란에서 나온 것이다. 이 확인란은 이미 "여기 위키코드를 입력하면 첫 번째 문자의 대문자를 포함하여 페이지 제목의 스타일 마크업을 변경할 수 있다. 이 필드는 페이지 제목의 텍스트를 변경하는 데 사용할 수 없다. 페이지 제목을 변경하려면 이동 기능을 사용하십시오.물론 아무도 그것을 읽지 않는다.VE 개발자들은 VE에서 별개의 라벨을 사용하지 않으며, 아마도 일부 투표에서 다음과 같은 결과를 얻는다.T110329가 도움이 될 것이다 - 만약 이것들에 라벨이 있다면 우리는 적어도 새로운 물건에서 그 부분을 제거할 수 있을 것이다.— Xaosflux^Talk 22:55, 2020년 9월 29일 (UTC)[응답]

VE가 또 공격해!EEng 05:41, 2020년 9월 30일 (UTC)[응답]

MoS 고정자 길드

위키피디아가 있는 것처럼:위키프로젝트 복사 편집자 길드, MoS 수정자 위키피디아 대상 길드를 갖는 것은 어떨까?이 위키피디아 주제에 따라 편집자들은 요청된 기사에서 MoS 문제를 해결할 것이다.그것은 GOCE와 비슷한 방식으로 작동할 것이다.나는 그것이 새로운/경험이 없는 사용자들에게 도움이 될 것이라고 생각한다.나는 내 개인적인 경험에서 이것을 제안했다.여러 번 GA 실패, mos 문제(주로 인용)로 인해 보류.❯❯ S A H A 13:53, 2020년 9월 30일 (UTC)[응답]

MoS의 문제는 종종 소수의 편집자들이 만든 무수한 규칙들이라는 것이다. 실제로 우리 대부분은 그러한 지침을 정확히 따르지 않거나 (만약 있다면) 토론이 있었다면).이것이 야기하는 마찰은 대부분 MoS 전체를 다수의 기사에 부과하려는 조직적인 노력도 없고, 변화를 부과할 수 있는 같은 생각을 가진 편집자 그룹을 만드는 MoS 알림판도 없기 때문에 견제된다.MoS의 많은 부분을 부여받는 것은 대부분의 시간에는 짧은 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 대월 등길드가 합리적인 생각처럼 들리지만 난 길드가 Hey, Rube로 바뀌지 않기를 바란다.-- GreenC 16:06, 2020년 9월 30일 (UTC)[응답]
카피 에디터 길드의 역할 중 일부는 기사의 MoS 규정 위반 문제를 수정하는 것이므로, 이것은 중복적으로 들린다.{{u Sdkb}}} 16:09, 2020년 9월 30일(UTC)[응답]

Sdkb, 나는 부분적으로 동의하지 않을 것이다.인용문 형식과 같은 문제는 다루어지지 않는다.❯❯ S A H A 16:29, 2020년 9월 30일 (UTC)[응답]
동의한다. 이것은 철자 수정과 같은 것들을 포함하는 소위 "최소 복사 편집"의 일부분이다.아마도 그것은 복사 편집 조합의 우산에 해당될 것이다. 그 이름으로 보아, 이것은 완전히 불필요하고 불필요해 보인다.앞의 코멘트 다시, 인용문 서식은 MoS와 내가 아는 바로는, 인용문 서식은 아무 상관도 없고, 인용문 서식은 우리가 길드 서식을 받지 않아도 잘 할 수 있을 것 같다.-맨드러스 ▷인터뷰 03:06, 2020년 10월 1일(UTC)[응답]

아니, 아니, 아니, 천 번 아니. "MOS 해결사의 길드"라는 이름만으로도 나는 말할 수 없는 공포로 가득 차 있다.이미 너무 많은 생각없는 지노밍이 일어나고 있다.만약 GOCE(경험이 풍부한 편집자 기반을 가진)가 포맷-ref 서비스 같은 것을 제공하기를 원한다면, 괜찮다.EENG 02:50, 2020년 10월 1일 (UTC)[응답]

User:EENG 이름은 샘플일 뿐이다.그것은 바뀔 수 있다.어쩌면 우리는 GOCE의 지점/안넥스를 가질 수 있을지도...❯❯ S A H 09:14, 2020년 10월 1일 (UTC)[응답]

아르나브사하, 이건 정말 나쁜 생각이야.내가 탓하는 것은 아니지만, 형편없는 포맷이 문제지만, 스타일리스트적인 선호인 MOS를 BLP나 NPOV와 같은 콘텐츠 정책을 지배하려는 시도를 놓고 너무 서투른 편집 전쟁이 많이 있어, 이것은 단지 거대한 드라마 자석이 될 것이고, MOS-obsess가 지속적으로 포맷을 선호하는 것이 정당하다고 느끼도록 조장할 것이다.추하게 보이는 사실에 헛소리를 하다가이(도움말! - 오타?) 09:59, 2020년 10월 1일 (UTC)[응답]

나는 너의 포스트를 MOS 인증으로 만드는 것을 자유자재로 했다.당신은 꺼리지 않길 바라요.EENG 10:26, 2020년 10월 1일 (UTC)[응답]

추가/편집 : 받은 피드백을 바탕으로 제안서를 편집하고 싶다.MoS 전체를 고치는 것은 큰 일이다.그렇다면, 좀 더 구체적인 것은 어떨까?인용문을 고치는 것 처럼요GA/DYK 중에 제대로 포맷되지 않고 문제를 일으키는 경우가 많다(개인 경험에서 말한다).❯❯ S A H A 11:14, 2020년 10월 1일 (UTC)[응답]

편집, 기록, 삭제 및 새 섹션 링크에 외부 링크 대신 내부 링크 사용

Special을 사용하는 방법:EditPage, Special:PageHistory, Special:삭제 및 특수:NewSection은 외부 링크를 사용하는 것보다 더 좋으며 어디든 도입되어야 한다.(이 토론 참조) 217.117.125.72 (대화) 18:17, 2020년 9월 29일 (UTC)[응답]

나는 이것이 훌륭한 "선호" 옵션이 될 것이라고 생각한다.외부 링크를 선호하는 경우도 있지만, 대부분 가능하다면 내부 링크를 선호한다.davidwr/(토크)/(contracts) 19:49, 2020년 9월 29일(UTC)[응답]

위키피디아 내의 링크는 내부 연결이며, 외부 연결 아이콘의 상징성을 유지하기 위해 반드시 이와 같이 표시되어야 한다.이것은 논란의 여지가 없는 유지 보수여야 할 것 같다.{{u Sdkb}} 21:11, 2020년 9월 29일 (UTC)[응답]

제안된 변경사항을 지원한다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 08:16, 2020년 9월 30일 (UTC)[응답]

전체 URL을 통해 내부 링크를 사용할 경우 어떠한 것도 손상되지 않는 사소한 성능 개선 지원높은 우선순위는 아니지만, 위키백과의 "개선" 링크와 함께 24개의 템플리트를 바꿀 가치가 있는 것 같다.템플릿 인덱스/정리.

\langle

\langle

Forbes

\langle

₇₂ Talk

{\displaystyle

\angle

}18

15

\rangle

, 2020년 10월 1일(UTC)[응답]

부록 - 진행 중인 동안, 버튼을 누를 때 캐시를 "구입"할 수 있는 페이지에 대해 설명해줄 수 있는가?사용자들에게 이것은 꽤 순수하며 오래된 캐시된 정보를 새로 고치기 위한 것이라는 것은 명확하지 않다.그렇지 않으면, "퍼지"는 매우 폭력적이고 파괴적으로 들린다.:) 이와 관련된 페이지에는 특별이 포함된다.https://en.wikipedia.org/w/index.php?title=Foo&action=purge과 같이 URL에 "action=properties"가 있을 때 정리하십시오.하지만 이것을 어디에 보관해야 할지 확실하지 않다. -- 푸즈헤도 토크 13:45, 2020년 10월 2일 (UTC)[응답]

어? 내가 보기엔 둘 다 특별해 보이네삭제 및 https://en.wikipedia.org/w/index.php?title=Foo&action=purge에는 "페이지를 구입하면 캐시가 지워지고 최신 개정판이 나타나게 된다.무작위 구성요소가 있는 페이지의 경우, 새로운 무작위 선택을 강요한다." 그리고 두 가지 모두 WP와의 링크를 가지고 있다.PURGE는 "이것은 무엇을 하는가?"라고 라벨을 붙였다.〈Forbes₇₂ Talk〉 08:05, 2020년 10월 3일 (UTC)[응답]

위키백과에 탭 및 탭 확장 추가

그래서 내가 이것을 요청하는 이유는 일부 사용자 페이지와 프로젝트 페이지에 탭이 있다는 것을 알기 때문이다.그러나 다른 부분에 다른 텍스트를 숨길 수 있기 때문에 이 두 개의 확장자를 함께 추가하는 것이 더 좋으며, 이것은 다른 텍스트 조각을 분리할 때 매우 유용하다.사용자 페이지의 경우 여러 페이지를 만들지 않고 사용자 상자, 바이오 및 링크를 다른 섹션으로 분리할 수 있다.프로젝트 페이지도 마찬가지야기사 페이지도 같은 것을 사용할 수 있는데, 한 페이지에 한 다발을 넣을 거면 그냥 다른 탭에 표를 넣을 수 있다.탭이 있는 페이지의 예는 다음과 같다. --slaps/\/\/\TheGeometryDashFan/\/\/\cHB(대화) 18:00, 2020년 10월 8일(UTC)[응답]

제안자로서 강력한 지원.또한 최상의 품질을 위해 두 확장자를 모두 추가하십시오.TheGeometryDashFan/\/\/\cHB(대화) 18:16, 2020년 10월 8일(UTC)[응답]
왜 이것이 필요한가? --Izno (대화) 19:27, 2020년 10월 8일 (UTC)[응답]

위키피디아에 따라 반대:하위 페이지.기사에는 이런 하위 페이지가 없어야 한다.케임브리지베이날씨, 우카크투크(토크), 훌리바 04:10, 2020년 10월 9일(UTC)[응답]

기사에는 하위 페이지가 없을 거야, 이건 대부분 사람들에게 유용해.Wikipedia:그리고User:네임스페이스또한 나는 우리가 하위 페이지를 갖지 못하도록 이것을 제안했다.TheGeometryDashFan/\/\/\cHB(대화) 19:56, 2020년 10월 9일(UTC)[응답]

원하는 대로 사용자 권한 설정 및 해제

나는 편집자가 필요에 따라 보유하고 있는 고급 사용자 권한을 활성화하고 비활성화할 수 있는 사용자 선호 또는 기타 메커니즘을 제안한다.

왜?

나는 자동변속 및 보류중인 변경사항 검토자 사용자 권한을 가지고 있다.특정 편집 시간에 둘 다 끄고 싶을 때가 있어.

계좌가 두 개 있다거나 로그아웃하는 것 외에는 방법이 없다고 본다.만약 내가 틀렸다면, 나에게 알려줘.

이러한 설정의 혜택을 받으려면 회신하십시오.지원이 충분하면 정식으로 피쳐 요청을 하겠다.davidwr/(토크)/(기여) 16:21, 2020년 10월 4일(UTC)[응답]

나는 다른 사람들을 대변할 수는 없지만, 지역 사회가 얼마나 더 긴급한 기술적 요구를 가지고 있는지를 고려할 때, 이것이 내 최우선 순위에 있지는 않을 것이라고 말해야 한다.주어진 사용자 권한 없이 편집이 어떤 것인지 보기 위해 로그아웃하는 것이 항상 가능하다.{{u Sdkb}}} 16:40, 2020년 10월 4일(UTC)[응답]
나는 왜 누군가가 그들의 사용자 권리를 다른 데로 돌리고 싶어하는지 궁금하다...이득이 있는가?블루보아 (대화) 16:49, 2020년 10월 4일 (UTC)[응답]
소프트웨어/인터페이스/etc 개발에서는 다른 권한을 가진 사용자의 외모/작업 방식을 테스트하는 것이 보통이지만, 관리자, 일반 사용자 또는 로그아웃(최소한 관리자로서의 경험에서)을 제외하고는 매우 드물다.로그아웃은 분명히 매우 쉽게 볼 수 있으며, 관리자가 이러한 목적으로 사용할 수 있는 안전하지 않은 연결에 사용할 수 있는 두 번째 계정을 가지고 있는 경우가 많다(나는 President42를 사용한다).지난 5년 동안 두 번 정도 오버파이터가 아닌 행정관에게 어떤 것이 어떻게 보였는지 확인하고 싶었던 적이 있었는데(왜 그런지 자세한 것은 기억나지 않지만), 두 번 모두 우연히 그 청구서에 맞는 사람과 같은 물리적 위치에 있었다.전반적으로 나는 이와 같은 사용자 권리의 전환을 허용하는 기능이 그것을 만드는 노력의 가치가 있다고 생각하지 않는다.특히 이러한 도구는 사용자가 직접 제거했기 때문에, 다른 사용자가 제거했기 때문에, 또는 사용자가 직접 제거했기 때문에, 특정 사용자 권한이 없는지 여부를 판단할 수 있어야 하기 때문에 더욱 그렇다.만약 이것이 현재 추적되고 있다면 나는 매우 놀랄 것이다. 그래서 그것은 모든 미보유 권리에 대해 적어도 두 개의 주(당신이 그것을 제거했기 때문에 보유하지 않았거나 어떤 다른 이유로 보유하지 않은 것)가 필요할 것이다(약 28개의 권리가 있다).모든 사용자에 대해 wiki 사용자가 보유해야 함)Thryduulf (대화) 20:43, 2020년 10월 4일 (UTC)[응답하라]
개인 브라우저 세션에서 Wikipedia를 여십시오.로그인한 창을 개인 창과 직접 비교할 수도 있다.반아이작_WS^cont 20:49, 2020년 10월 4일 (UTC)[응답]
소프트웨어에서 이미 이 기능을 지원하므로 원하는 경우 구성 변경을 요청하면 된다는 점에 유의하십시오."자동 압축 사용 가능"이라는 새 그룹을 만든 다음 "자동 압축"을 "$wgroupsAddToSelf['자동 압축 사용 가능'] 및 "$wgGroupsRemoveFromSelf['자동 압축 사용 가능'"에 추가하면 된다. 마찬가지로, 이 작업을 원하는 나머지 그룹도 이와 유사하게 된다.그러면 관리자는 기본 그룹과 함께 사용 가능한 그룹을 부여할 것이다.잭mcbarn (대화) 20:56, 2020년 10월 4일 (UTC)[응답]
- @Jackmcbarn: 다른 위키에서 이 계획을 사용하는가?어떤 단점이 있을까?양성이고 다른 곳에서 잘 작동했다면 사용 사례가 협소하더라도 해볼 만할 수도 있을 것 같다.— Wug·a·po·des 19:33, 2020년 10월 5일 (UTC)[응답]
  - 나는 어떤 위키도 여기서 제안된 것만큼 광범위한 일을 한다고는 생각할 수 없지만, 가장 가까운 아날로그는 다국어 위키에 대한 번역 관리자 권한으로, 관리자들은 스스로 허용하고 제거할 수 있지만, 관료들만이 다른 사용자들에게 허용하거나 제거할 수 있다.그것은 내 경험에 어떤 문제도 일으키지 않았다.나는 이 제안이 그것의 이익에 의해 정당화되지 않은 복잡성이라고 생각한다.* 삐삐 * 20:33, 2020년 10월 5일 (UTC)[응답]
자, 기술적으로 가능한 일이고, 나를 포함한 몇몇 편집자들에게는 불필요한 복잡성이라는 것을 보여주고, 다른 편집자들이 왜 그것이 더 나아질 가치가 있기 전에 그것이 유용하다고 생각하는지 말할 필요가 있다고 생각한다.공개 - 나는 보통 길들여진 관리자 설정 계정으로서 훈련을 하거나 보조하기도 하지만 트레이너들이 신입들에게 무언가를 증명하기 위해 사용자 권한이 없는 계정이 필요한 이유를 이해한다.하지만 선언된 alt 계정은 바로 그거야...그럼 다른 사람들이 이점을 보지 않는 한, 이것은 이미 해결책이 있는 문제에 대한 해결책이란 말인가?ϣereSpielCequers 08:07, 2020년 10월 6일 (UTC)[응답]
나는 두 개의 계정을 사용하여 현재 시스템에서 이미 처리할 수 없는 사용 사례를 찾기 위해 애쓰고 있다.예를 들어, 나는 현재 확장 확인된 사용자, 파일 이동기, IP 블록 면제, 새 페이지 검토자, 보류 중인 변경 검토자, 롤백기 등의 권한을 가지고 있다.나는 또한 긴 임의 사용자 이름(좋은 이름 중 하나를 사용하고 싶지 않음)을 가진 대체 계정을 가지고 있고 새로 등록된 사용자에게 페이지가 어떻게 보이는지 보기 위해 사용하는 편집한 적이 없는 사용자 권한을 가지고 있지 않다.어떤 이유에서인지 롤백을 끈 상태에서 편집 테스트를 실행하기로 결정했지만 IP 블록의 예외를 켠 채로(만약 그들이 내가 다시 미국을 떠날 수 있게 해준다면 나는 중국에 있을 때 Tails OS에서 편집하는 것이 필요할 것이다)라고 하자.사용자:Guy Macon Alternate Test Account E694E42C05C5995D7D613720A9C69146F544F18C80F5에 대체 계정 통지를 붙이고 관리자에게 롤백기 없이 내 사용자 권한을 복사하도록 요청하십시오.사용자 권한 설정 및 해제 필요 없음. --Guy Macon (대화) 10:18, 2020년 10월 6일 (UTC)[응답]
페이지 참조:T153454 및 Phab:이러한 측면을 포함하는 T210909는 기본적으로 정지되어 있다.— Xaosflux 10:51, 2020년 10월 6일(UTC)[응답]
개인적으로 나는 이것에 대해 일리가 없다고 생각한다 - 만약 당신이 일시적으로 권리를 원하지 않는다면 계정을 만드세요?무례하게 들리진 않지만 로그아웃하거나 로그인하는 것은 그렇게 어렵지 않다...–Davey2010^Talk 13:31, 2020년 10월 9일(UTC)[응답]
위에 언급된 대부분의 사람들은 당신이 대부분의 시간을 당신의 고급 권리를 사용할 것이라는 가정으로부터 진행되는 것 같고, 드물게, 예를 들어 공용 컴퓨터에서 편집하거나 새로운 사람들에게 인터페이스가 어떻게 보이는지 볼 필요가 있을 때만 그러한 권리를 끌 필요가 있는 것 같다.그러나 이 시나리오만이 아니다. 예를 들어, 자동 확인 이외의 사용자 권한 없이 편집의 99.99%를 수행한다.내 생각엔 계좌 보안에 대해 항상 걱정해야 하는 것, 또는 키보드를 걷고 있는 고양이에 대해 고민해야 하는 것이 정말 0.01%의 관련성만 있다면 그것은 일종의 지겨움일 수 있다.– 우안팔라 (대화) 18:44, 2020년 10월 10일 (UTC)[응답]
- 현재 시스템으로 쉽게 처리 가능.대체 계정을 만들고 관리자에게 기본 계정에 축소된 권한을 부여하면서 고급 권한을 부여해 달라고 요청하십시오. --Guy Macon (대화) 20:51, 2020년 10월 10일 (UTC)[응답]
- 예를 들어, 나는 이 작동 방식에 대해 뭔가를 쓸까 생각 중이었는데, 이것은 당신의 컴퓨터에 로그인할 때 가장 좋은 방법이다.보안 고도 접근방식으로, 정기적인 권한으로 이루어졌든 상승했을 때 사용자가 편집한 모든 내용을 쉽게 함께 연결할 수 있다.그러나 잘못 클릭하는 시나리오는 이것이 어디에 유용한지 생각할 수 있는 유일한 것이다. (나는 위키백과 관리자를 대상으로 하는 악성코드로부터 방어하는 것은 또 다른 방법일 것이라고 생각한다.)계정 보안은 보안 특권을 상향 조정할 때 인증을 다시 받아야 하는지 여부에 관계없이 여전히 유지될 필요가 있다.아마도 관리자 인터페이스에 익숙한 누군가가 우발적인 관리 조치를 피하는 것의 가치를 고려할 수 있는가?아이작 (토크) 21:09, 2020년 10월 10일 (UTC)[응답]

해당 문서에 사용된 참조를 제거하는 RfCs에 대한 기사 토크 페이지 알림 요구

위키백과에서 RfC를 시작했다.광범위한 입력으로 수행할 수 있는 신뢰할 수 있는_source/NoticeboardRS 통지판은 기사 편집자에게 통지하지 않고 기사로부터 후속적으로 제거되는 소스를 더 이상 사용하지 않는 RfCs를 보관한다.나는 기사 편집자가 RfC를 닫기 전에 RfC에 참여할 수 있도록 RfC에 연결된 통지를 해당 기사의 토크 페이지에 추가할 것을 제안한다.고마워요.마이크 필 (토크) 20:38, 2020년 10월 12일 (UTC)[응답]

RfC: Infoboxes에서의 알렉사 랭킹

알렉사의 인포박스 순위는 어떻게 해야 하는가? -- GreenC 17:19, 2020년 9월 18일 (UTC)[응답하라]

약 1년 전 이곳에서 알렉사 랭킹을 인포박스에서 어떻게 할 것인가에 대한 논의가 잘 이뤄진 데 따른 후속 조치다.예를 들어 WebCite는 alexa=10만7988명(2018년^[update] 12월)

문법요미:

알렉사 수치는 매달 바뀌며 시대에 뒤떨어지면 빠르게 오도하게 된다.
순위 데이터는 소유권(아마존)이며 API를 통해 액세스하려면 계층별 요금이 부과되며, 무료 계층은 월 1,000개의 쿼리로 제한된다.약 5,000개의 사례가 있다.{{infobox website}}을 포함하는 alexa=.
ㅇㅇ로 ㅇㅇㅇ 수 있다. 에 위배되는 그러나 정기적으로 위키피디아에 로딩될 경우, 완전한 IP 차단을 야기하지는 않더라도 저작권 또는 이용약관 규정을 위반할 것이 거의 확실하다.
데이터를 수동으로 확인하고 위키피디아에 추가할 수 있다.그러나 산발적으로 행해진 실습에서 웹 사이트 예시(이 게시물 현재 2세)를 보면, 나는 5년 이상 지난 것을 보았다.

RfC는 다음 세 가지 옵션을 제안한다.

알렉사 랭킹은 현재와 같이 Infobox로 유지한다.
알렉사 순위를 인포박스에서 완전히 제거한다.
반복적인 아티클 편집이 없는 솔루션 자동화가능성에는 다음과 같은 가능성이 있다.
- 월 1,000의 비율로 Amazon API를 사용하여 알렉사에서 로컬 호스팅(Commons 표 데이터, Wikidata 등)으로 데이터를 끌어다 놓으십시오.이것은 루아를 통해 인포박스에 표시된다.예를 들어 다음과 같이 보일 수 있다.
  alexa={{alexa webcite.com}}
- 정적 일반 링크를 표시하는 새 템플릿을 만드십시오.예를 들어 현재 위키백과 infobox:
  alexa= 13 (글로벌, 2020년^[update] 8월)
  
  대신 다음과 같이 표시됨: webrank=Alexa, SimilarWeb

자동화된 해결책은 혼용될 수 있다.상위 1000개는 API를 통해, 나머지는 정적 링크를 통해 이루어진다.아니면 다른 생각일 수도 있고.#3은 RfC 목적을 위한 단일 옵션이다.

우선 순서에 따라 투표하십시오."1, 2 또는 3 순서에 따라" 또는 단어를 원하는 경우.

Due to length of time previous participants pinged: @Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists: -- GreenC 17:19, 18 September 2020 (UTC)[reply]

조사(인포박스 내 알렉사 순위)

이전의 논의에서와 같이, 그것은 제거되어야 한다.그래서 대담한 2. --Izno (토크) 18:42, 2020년 9월 18일 (UTC)[응답]
옵션 2 이러한 순위는 WP에서 두 개 이상의 항목을 강타한 것으로 보인다.WP를 포함하지 않음:비디렉토리 및 WP:무차별.이 순위는 독자들에게 심지어 어떤 시점에서 어떤 사람들은 알렉사를 어떤 것에 사용했다고 말해주는 것이다.IMO 그들은 IMDb 등급만큼 중요하거나 학술적인 가치가 없다.또한 왜 알렉사가 시리 같은 다른 것들보다 더 선호되는가?레이 브래드버리가 마을 전체나 국가의 아이들을 대신하는 자동화된 서비스 중 하나에 대해 짧은 이야기를 쓰지 않았는가? 만약 그가 아직 살아있다면, 나는 그가 지금 펜을 하나 쓸 것이라고 추측한다.마넷D 토크 18:59, 2020년 9월 18일 (UTC)[응답]
옵션 2 순위는 많이 바뀌기 때문에 비순환적이다.또:방화범 (대화)19:30, 2020년 9월 18일 (UTC)[응답]
https://www.realskeptic.com/2013/08/12/why-you-shouldnt-use-alexa-traffic-statistics/
교통 메트릭스 같은 것을 유지하십시오.나는 이 질문을 처음 듣지만, 기본적인 수준에서 웹사이트가 받는 트래픽의 양은 인포박스에 적합한 중요한 백과사전적 정보다.우리는 그것이 순위나 월간 페이지뷰의 형태로 되어야 하는지에 대해 논의할 수 있다.2만분의 1이 방문한 웹사이트가 실제로 무엇을 의미하는지 아무도 모르기 때문에, 그리고 우리가 순위를 유지한다면, 그것이 알렉사로부터 온 것이어야 하는지 아니면 다른 곳에서 온 것이어야 하는지, 특히 순위가 낮은 사이트들에게 더 유용하게 보인다.하지만 우리가 더 나은 대안을 찾을 때까지, 나는 그것을 제거하는 것을 지지할 수 없다.만약 지역 호스팅이 가능한 옵션 3이 실현 가능하다면, 그것이 최선일 것이다.우리는 2020년에 있다; 우리는 자동화할 수 있는 어떤 것을 업데이트하도록 편집자의 작업을 요구해서는 안 된다.{{u Sdkb}} 19:49, 2020년 9월 18일 (UTC)[응답]
옵션 2 - 정확하지도 않다.O3000 (토크) 20:41, 2020년 9월 18일 (UTC)[응답]
옵션 2 그것들은 관용적이지 않다.제프 베조스를 설득해서 우리에게 주라고 해도 상관없어모든 공기업의 종가를 끌어낸 {{infobox company}에 대한 사료도 자동화할 수 있었다.하지만 그것이 백과사전이 존재하는 이유일까?아니다. 인포박스는 정적인 데이터(또는 웹사이트의 소유자처럼 정적인 거의 정적인 데이터)를 위한 것이다. 지속적으로 변화하는 데이터는 백과사전에 속하지 않는다.사이트 트래픽이 눈에 띄는 경우 기사 텍스트에 신뢰할 수 있는 보조 소스를 사용하는 것이 훨씬 더 좋다. 예를 들어 "2020년 현재, Wikipedia.org은 인터넷에서 가장 많이 거래되는 2단계 도메인 중 하나" (ref tag에 신뢰할 수 있는 소스를 포함)UnitedStatesian (대화) 20:50, 2020년 9월 18일 (UTC)[응답]
옵션 2 - 순위는 비절제적, 독점적, 부정확함, 끊임없이 변화하며 시간과 노력의 완전한 낭비다.만약 웹사이트가 인기 있거나 인기가 있었다면, 우리는 역사와 장수의 중요성과 관계없이 웹사이트의 역사 맥락에서 산문을 통해 최신 인터넷 유행과 트렌드를 우리의 인포박스에 반영하려 하지 말고 설명해야 한다.칼다리 (대화)20:52, 2020년 9월 18일 (UTC)[응답]
옵션 2가 불안정하고 일관성이 없다.--Moxy 🍁 22:06, 2020년 9월 18일(UTC)[응답]
옵션 2.예전엔 뭔가 의미가 있었을 텐데, 지금은?그렇게 많지는 않다.가이 (도움말! - 오타?) 22:07, 2020년 9월 18일 (UTC)[응답]
옵션 2.일화적으로, 나는 실제로 유용한 정보를 제공하거나 신뢰할 수 있는 출처를 다룬 알렉사 순위를 아직 보지 못했다.문제는 이 숫자가 불분명한 알고리즘에 의해 생성된 임의의 숫자라는 점인데, 이 숫자는 즉시 눈에 띄는 (예를 들어 메타크라이트와 같은) 어떤 것에 근거하지 않고 있다는 점이다.그리고 믿을 만한 소식통들은 이 순위를 논하는 것도 마다하지 않고, 정기적으로 따르기 마련이다.인포박스는 이미 절반의 시간 동안 소싱이 없는 주제에 대한 모든 통계들의 큰 덤프다.여러분은 웹사이트가 받는 "인터넷 점수"가 큰 문제가 될 것이라고 생각하겠지만, 그것은 신뢰할 수 있는 정보원이 이것을 다루는 방식이 아니다.— HELLKOWNZ 22:36, 2020년 9월 18일 (UTC)[응답]
위와 같은 거의 모든 것에 대해 옵션 2, 특히 몇몇은 비-임시-절제-ness; 행복한 날들, 린제이^Hello 23:16, 2020년 9월 18일 (UTC)[응답]
옵션 2 단조롭고 당파적인 가짜 순위.Fiddle Faddle 23:39, 2020년 9월 18일 (UTC)[응답]
옵션 3은 중도로다.문제를 인식하고 이를 해결한다. 감시 목록 이탈, 완전 자동화, 수동 작업 불필요, 일부 사이트에 대한 데이터는 매월 최신 상태로 유지되며 나머지 정적 링크(등급 데이터는 표시되지 않음)알렉사 데이터의 정확성에 대해서는, 이것은 알렉스 위키백과 기사의 주소와 이전 논의의 JC에 의한 것이다.위키피디아는 때때로 자신을 포함한 많은 것들을 순위를 매긴다.만약 지역사회의 지원이 있다면 시스템이 가동되고 있다면 연간 25달러의 저렴한 WMFundation 지원금으로 매월 5,000개 사이트 모두를 업데이트할 수 있을 것이다. -- GreenC 00:54, 2020년 9월 19일 (UTC)[응답]
옵션 2. , 그러나 기사의 어딘가에 주기율표 같은 것으로 보관한다.그들은 불안정하고, 명성과 대중성을 혼동하지만, 인기는 무관한 정보가 아니다.그러나 현재의 가치를 인포박스에 넣는 것은 지나친 강조다. DGG (토크) 01:14, 2020년 9월 19일 (UTC)[응답]
옵션 2:

아니면 '알렉사 트래픽 구매' 구글 검색이나 해

신용카드를 가진 사람이 통계를 부풀릴 수 있다면, 그 통계는 위키피디아 출처로서 무용지물이다.그냥 하는 말이야. --Guy Macon (대화) 13:02, 2020년 9월 19일 (UTC)[응답]

옵션 2 우리는 미국 기업들을 위해 싸구려가 아니다.GenQuest 13:10, 2020년 9월 19일 (UTC)[응답]
옵션 2 - 그들은 너무 쉽게 조작될 수 있기 때문에 그 주제에 대한 사실의 진술이 아니다.그들은 확실히 인포박스에 속하지 않는다.그들은 주제를 홍보하는 데 악용될 수 있다.더그 웰러 대화 18:28, 2020년 9월 21일 (UTC)[응답]
옵션 2 - 알렉사 랭킹은 전혀 가치가 없으니, 포함시켜도 소용없다.우리는 자동으로 url 매개변수에 있는 도메인에 대한 일련의 정보를 보여줄 수 있어야 한다. 나는 알렉사 등급을 포함한 그것과 함께 살 수 있다. 그러나 우리는 그런 터무니없는 것을 포함시키기 위해 우리의 방황에서 벗어나서는 안 된다.춘투크 (토크) 11:22, 2020년 9월 28일 (UTC)[응답]
옵션 2 이 수치가 제공하는 값이 무엇인지 확신할 수 없으며, 얼마나 정확하고 유지보수가 가능한지에 대해 우려한다.PaleAqua (대화) 18:52, 2020년 10월 5일 (UTC)[응답]
옵션 2 나는 이 RFC를 읽기 전까지 알렉사 랭킹이 무엇인지조차 몰랐다.상관없는 것 같군.웨스 사이드맨 (대화) 21:22, 2020년 10월 5일 (UTC)[응답]
옵션 2 알렉사 도구 모음을 설치하셨습니까? ...안 그러니?나도 마찬가지야.알렉사는 우리의 웹서핑을 통계에 넣지 않는다.선택 치우침을 참조하십시오.P.S. 울타리 위에 있다면 가이 매콘이 올린 글을 몇 개 읽어 심층 분석을 해달라.마크 D 워튼 싸이디 (토크) [그/그/그] 22:56, 2020년 10월 5일 (UTC)[응답하라]
옵션 2 나는 이 정보가 infobox에 속한다고 생각하지 않는다.또 다른 짜증나는 문제는 빨간 삼각형/녹색 삼각형이 극도로 혼란스럽다는 것이다; 나는 그것이 순위가 올라가는 것을 의미하는지 (인기가 떨어진다는 의미) 아니면 인기가 올라가는 것을 의미하는지 (반대라는 의미) 알 수 없다.순위에서 훨씬 안정된 위치를 차지하고 있는 가장 인기 있는 웹사이트(상위 100여 개)에 대한 정보를 포함시키는 것이 타당할 수 있다.하지만 여전히 나는 "알렉사 인터넷에 따르면, google.com은 2010년 이후 가장 많이 방문한 웹사이트"와 같은 기사 본문에 더 잘 속한다고 생각한다.진심으로 오비너스 (토크) 07:42, 2020년 10월 6일 (UTC)[응답]
옵션 2 - 이러한 요점을 전혀 알 수 없음 - 위에서 언급한 바와 같이 종종 구식이 되어 독자에게 잘못된 정보를 제공한다.–Davey2010^Talk 19:43, 2020년 10월 14일(UTC)[응답]

토론(알렉사 랭킹(Infoboxes))

알렉사와의 나의 주된 문제는 "무엇을 넣어야 하는가, 무엇을 얻어야 하는가?"이다.봇을 넣거나, 알렉사에게 자료를 요청하거나, 아니면 그냥 수동으로 하면, 우리가 거기서 얻는 것보다 더 많이 넣는다고 해도 별로 문제가 되지 않는다.알렉사에게서 뭘 얻을까?사람들이 정말로 알렉사 계급에 대해 알기 위해 위키피디아에 오는가?방화범 (대화) 17:44, 2020년 9월 18일 (UTC)[응답]

아마존에 연락했나?나는 기술 대기업들에게 옳은 일을 할 수 있는 기회를 주고, 그들이 하지 않을 때 우리가 분명한 양심을 가지고 그들을 미워할 수 있도록 하는 확고한 신봉자다.하지만 가끔 그들은 놀란다. 아마존이 우리가 모든 웹사이트를 매월 업데이트 할 수 있도록 요율 제한이 없는 계정을 우리에게 제공할 가능성이 있을까?{{u Sdkb}}^talk 19:52, 2020년 9월 18일 (UTC)[응답]
- 나는 그것이 의심스럽다. 왜냐하면 아마존은 차라리 돈을 벌고 인포박스에서 작은 세부사항들을 도우려 하기 때문이다.그게 우리에게 결정적이었다면 그들을 설득할 수 있었을지도 몰라하지만 이렇게는 아니다.방화범 (대화)20:00, 2020년 9월 18일 (UTC)[응답]
  나는 아마존이 인기있는 웹사이트의 모든 기사에 알렉사와의 링크의 위치를 공고히 하는데 도움을 줄 것이라고 생각한다.그러나 이것은 단지 이 정보가 infobox에 저장되어야 하는지에 대한 질문과는 별개의 문제일 뿐이다.아이작 (대화)20:14, 2020년 9월 18일 (UTC)[응답]
  - 그들이 시멘트로 된 직책과 돈을 얻을 것이라고 거의 확신했다.알렉사가 여기에 랭크된 것은 아마존에게는 여전히 승리다.그래서 그들은 아마 무료 계좌를 거절할 것이다, 왜냐하면 왜 돈과 광고를 받지 않는가?방화범 (대화)20:31, 2020년 9월 18일 (UTC)[응답]
    왜냐하면 한 계좌에서 나온 돈은 아마존의 수익에 전혀 도움이 되지 않는 반면 페이지 순위는 금이기 때문이다.그리고 현재 이 논의를 토대로 볼 때, 순위 정보가 남아 있을 것이라는 것이 "확실히" 확실하지는 않다.아이작 (토크) 22:03, 2020년 9월 18일 (UTC)[응답]
@Sdkb: 이 정보는 어떻게 백과사전적인가?자주 바뀌는 순위는 백과사전이 아니다.방화범(대화) 19:56, 2020년 9월 18일 (UTC)[응답]
@Arsonxists: 내가 백과사전이라고 한 것은 웹사이트의 인기를 나타내는 수치적 척도였지만 알렉사 순위는 그런 척도 중 하나이다.나는 그것이 바뀐다는 사실이 그것을 덜 백과사전적인 것으로 생각하지 않는다; 그것은 인구 수나 미국 뉴스 대학 순위를 나열하는 것과 다르지 않다.{{u Sdkb}}}^talk20:04, 2020년 9월 18일 (UTC)[응답]
@Sdkb: 중요한 것은, 미국 대학 선거 투표와 같은 것들은 일정 시간이 지나면 변화가 멈추고, 미국 인구 추정치는 단지 추정치에 불과하지만, 알렉사 순위는 결코 멈추지 않고 추정치가 아니라는 것이다.매일 순위가 바뀌는 것은, 너무 많이 바뀌어서 들어갈 수 없다는 뜻이다.백과사전방화범 (대화)20:13, 2020년 9월 18일 (UTC)[응답]
접선 아이콘 증가/감소:이전 논의에서 녹색/적색 증가/감소 아이콘이 부적절한 WP인지에 대한 질문이 있었다고 본다.근세주의.개인적으로, 나는 그것을 거래 위반자로 보지는 않지만, 아이콘들이 비교를 위해 어떤 기간이 사용되고 있는지 말하지 않는 것은 나쁘다고 생각한다.또한 최근 {{fluc}}이(가) 생성됨에 따라 템플릿/자동화를 보다 효과적으로 사용할 수 있는 가능성이 있다.{{u Sdkb}}}20:01, 2020년 9월 18일 (UTC)[응답]
@GreenC:Two things: one, this edit will not have notified anybody (not even Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists) because you didn't sign it; two, what is your brief and neutral statement?2,600바이트 이상에서 위의 문장은 (에서){{rfc}} 내가 추가한 타임스탬프 태그)는 레고봇(토크·캐릭터)이 처리하기에 너무 길어서 위키백과에서 올바르게 표시되지 않는다.논평/미디어, 예술 및 건축에 대한 요청.또한 RfC는 WP를 통해 공개되지 않을 수 있다.더 짧은 문장이 제공될 때까지 FRS. --Redrose64 🌹 (대화) 20:33, 2020년 9월 18일 (UTC)[응답]

고마워! -- GreenC 21:50, 2020년 9월 18일 (UTC)[응답]

WikiData와 함께 작업하거나 WMF 보조금을 받을 수 있는가?WikiData는 아마도 이런 종류의 데이터를 호스팅하는 것을 좋아할 것이고 거기서부터 인포박스를 채울 수 있을 것이다.WMF의 보조금은 다음 계층이 무엇이든 간에 우리가 한 달에 5k에 달하는 요청을 할 수 있도록 우리가 이것들을 갱신할 수 있도록 하기 위해 우리는 다음 계층에 대한 수수료를 지원할 수 있다.— Wug·a·po·des 23:35, 2020년 9월 18일 (UTC)[응답]
- GreenC와 연계된 요금 구조를 보면, 월 1만 건의 요청으로 끝나더라도 5달러 정도 된다 — Wug·a·po·des 23:37, 2020년 9월 18일 (UTC)[응답]

응, 지금 당장 필요한 건 연간 25달러야.제도적 뒷받침이 없으면 영구적으로 지급이 유지될 수 있는 보증금도 없다.여기서의 결과와 상관없이, 여전히 위키다타나 위키콤에서 주최하고 다른 언어 위키에 사용될 수 있다. -- GreenC 00:43, 2020년 9월 19일 (UTC)[응답]

@I JethroBT (WMF): 우리가 이것을 탐색하는 것을 도와주겠니?500달러의 보조금은 이것을 20년 동안 지속시킬 수 있는데, 이것은 급행보조금의 최대 12개월보다 약간 길기 때문에, 나는 우리가 보조금을 받을 자격이 없다고 생각한다.우리는 보조금 이외의 WMF 프로그램을 봐야 하는가?— Wug·a·po·des 01:16, 2020년 9월 19일 (UTC)[응답]

@Wugapode:나는 이 제안에 대한 모든 세부사항을 가지고 있지는 않지만, 일반적으로 Rapid Grant에 500달러를 요청하고 첫 해 이후에 결과/데이터를 간단히 보고하는 것은 문제가 되지 않는다.자금 지원의 일부가 12개월을 넘어 계속된다는 것은 문제가 되지 않으며, 사실 기본적으로 이상적이다.만약 이 프로그램/서비스의 이익이 첫 해 후에도 지속될 것이라면, 내가 보기에 그것은 분명히 자금을 댈 가치가 있다.I JethroBT (WMF) (토크) 20:00, 2020년 10월 1일 (UTC)[응답]

연간 방문자 매개 변수?

좋아, 그럼 뭔가 바뀌지 않는 한 알렉사 매개변수가 곧 나올 것 같군하지만 나는 웹사이트의 인기를 나타내는 어떤 종류의 측정 기준을 갖는 것이 유용하다고 주장한다.지역사회가 다음 작업을 수행할 수 있도록 지원하시겠습니까? annual visitors=(또는) annual pageviews= ) 매개 변수?{{Infobox Museum}}}에 대한 연간 방문자 매개 변수가 있는 것과 별로 다르지 않아 보인다.{{u Sdkb}}^talk00:47, 2020년 9월 21일 (UTC)[응답]

비용도 들지 않고 자유롭게 허가받을 수 있을 것 같은 그 데이터에 대한 출처를 염두에 두고 있는가? --Izno (토크) 02:33, 2020년 9월 21일 (UTC)[응답]

@Izno: 나는 그 데이터를 규모에 맞게 수집하는 실체가 없다고 생각하는데, 그래서 그것은 개별 웹사이트에서 나온 겁니다.예를 들어, 위키피디아의 경우, 우리는 8억8천2백만^[1] 개의 웹사이트를 인용할 것이다. 많은 웹사이트들은 그들의 번호를 공개하지 않지만, 나는 아무것도 가지고 있지 않는 것보다 그렇게 하는 웹사이트를 포함시키는 것이 더 낫다고 생각한다.{{u Sdkb}}^talk04:21, 2020년 9월 21일 (UTC)[응답]

위키피디아에서도 통계는 명확하지 않다.8억8200만 명이라는 수치는 연간 수치가 아닌 월별 수치로 방문객보다는 독특한 장치를 나타낸다.사람들이 전화기, PC, 노트북, 게임 콘솔에서 인터넷을 검색한다는 것을 고려하면, 방문자들에게 독특한 장치를 동일시하는 것은 간단하지 않다.리처드 네벨(대화) 10시 2분, 2020년 9월 21일 (UTC)[응답]

참조

^ "Wikistats - Statistics For Wikimedia Projects". Wikimedia Foundation. Retrieved 21 September 2020.

하지만 우리는 WP:V와 WP를 마주하게 된다.RS 문제.(아마도) 얼마나 많은 방문객이 방문하는지 아는 사람은 사이트 자체일 것이다. (그리고: 방문자들 앞에서 믿을 만한 페이지뷰)그러한 인포박스 파라미터는 우리가 그들의 가치에 대해 신뢰할 수 있는 누군가가 있다는 것을 가정한다.— JohnFromPinckney (대화) 09:41, 2020년 9월 21일 (UTC)[응답]

사실, "얼마나 많은 방문자를 구하는지 (아마도) 아는 유일한 사람들은 사이트 그 자체일 것이다."라고 말하는 것은 사실이 아니다.이 사이트는 방문객이 얼마나 되는지 알 수 없다.이유는 캐싱이다.여러분이 뉴질랜드에서 개최되는 정말 멋진 웹사이트를 가지고 있다고 가정해 봅시다.뉴욕에서 동일한 ISP를 사용하는 천명의 사람들이 거의 동시에 방문한다.이제 ISP는 뉴질랜드로 수천 건의 요청을 보낼 수도 있고, 한 건의 요청을 보내고, 그 결과를 로컬로 저장하고, 나머지 999명의 사용자에게 서비스를 제공할 수도 있다.ISP의 경우 저렴하게 페이지를 넘겨주지만 뉴질랜드의 사이트는 방문객이 얼마나 되는지 모른다.

그 사이트들은 캐싱을 물리치고 각각의 방문객들이 뉴질랜드로 가도록 강요하는 많은 속임수들을 가지고 있지만, 지역 ISP, 브라우저 제조사, 애드블럭터, 추적기 차단기, 그리고 NZ와 NYC 사이의 거의 모든 컴퓨터들이 그러한 속임수를 물리치기 위해 일하고 있다.자세한 내용은 지루하지 않겠지만 최종 결과는 통계는 모두 교육받은 추측이라는 것이다. --Guy Macon (토크) 16:19, 2020년 9월 29일 (UTC)[응답]

모든 통계는 교육받은 추측이 아닌가?매년 박물관을 방문하는 사람들, 혹은 기차역을 이용하는 승객들은 단지 교육받은 추측일 뿐이다.그것이 지나친 정밀함을 피해야 하는 이유인 것 같지만 그래도 그 수치는 가치가 있다고 생각한다. --폴 카펜터 (대화) 13:55, 2020년 9월 30일 (UTC)[응답]

위키프로젝트 법의학

현재 새로운 법의학 위키프로젝트를 시작하자는 제안이 있다.위키백과 참조:위키프로젝트협의회/제안/천연과학에 관심 있는 모든 분들을 위해 감사드린다.저름 (대화) 04:05, 2020년 10월 16일 (UTC)[응답]

봉사상

서비스 어워드 자격은 현재 "편집자가 위키백과에 기여한 횟수 및 등록된 기간"을 기준으로 한다.나는 (https://xtools.wmflabs.org/)에서 볼 수 있는) 사용자의 평균 편집 크기가 적어도 이 기준들만큼 중요하다고 믿는다.어떤 사람이 크게 기여하지만 상당히 적은 수의 큰 편집을 한 반면, 다른 사람은 매우 좋은 거래를 기여하지만 각 편집은 매우 작다면, 후자는 사이트만큼 강력한 정보원이 되는 것에 대한 책임이 다소 적은 경우에도 높은 등급으로 귀결될 수 있다.그것은 큰 문제는 아니지만, 나는 어떤 사람들이 위키피디아에 가장 중요한 기여자인지를 더 잘 반영할 수 있도록 추천된 종류의 변화가 서비스 어워드 제도를 더 잘 반영할 것이라고 생각한다.그들 모두가 가장 다작지 않은 이유는 다양하다.AndrewOne (대화) 19:43, 2020년 10월 11일 (UTC)[응답]

나도 동의해.기여 횟수만 사용해도 큰 편집 대신 작은 편집이 여러 번 이뤄지는 나쁜 행태를 부추길 수 있다.굿/필수품의 개수를 고려해야 한다고 생각한다.T8612 (대화)20:21, 2020년 10월 11일 (UTC)[응답]

아 그래, 하지만 또 다른 형태의 WP:편집증. --Izno (대화) 20:37, 2020년 10월 11일 (UTC)[응답]

나의 평균 편집 크기는 -122.5바이트야.나는 이것이 어떻게 유용한 것을 나타내는지 잘 모르겠다.이러한 "Awards"를 개선하려는 당신의 시도를 너무 무시하는 것처럼 들리지 않기 위해서입니다.하지만 나는 이것이 무의미한 해결책이라고 생각한다. 왜냐하면 서비스 상이 어떤 해결책을 가지고 있다는 생각은 결함이 있는 전제이기 때문이다.주관적 측정에 적용되는 지표라 객관적으로 판단할 때는 절대 사용할 수 없다.당신이 하고 있는 모든 것은 단지 그것에 더 많은 규칙과 요소들을 추가하는 것이다.여기 또 다른 극단적인 가정이 있다: 수천 명의 빠른 삭제 후보들을 검토하고 태그를 붙인 누군가와 기사에 "lol penis"를 덧붙이고 되돌아가서 금지된 누군가는 어떨까?전 편집자의 편집은 모두 삭제되지만 후자의 편집자는 +9의 내용 추가가 있기 때문에 후자의 편집자는 여전히 순위가 더 높다.— HELLKOWNZ 20:55, 2020년 10월 11일 (UTC)[응답]

나는 평균을 얻을 수 없다. 나는 단지 다음과 같은 것만을 얻을 뿐이다.사용자가 너무 많이 수정했음!BD2412 T 21:04, 2020년 10월 11일 (UTC)[응답]

와우! 2005-02-20 이후 1640315 편집, 그거 음반이야?더그 웰러톡 08:42, 2020년 10월 17일 (UTC)[응답]

그래, 그게 문제지.사람들은 위키피디아에서 너무 많은 편집을 하고 있다.나를 포함해서, 분명히. --A D Mono III^(talk) 21:17, 2020년 10월 11일 (UTC)[답글]

편집 카운트는 항상 매우 조잡한 측정이었다.편집 크기, 반자동화 대 수동 편집 등을 조정해 볼 수도 있지만 시시페안 작업이다.우리가 할 수 있는 유일한 현실적 방법은 편집 횟수를 줄이고 사람들에게 미터법으로서의 한계를 알리는 것이다.

개인적으로, 나는 그것이 주로 새로운 편집자들에게 유용하다는 것을 발견한다. 50과 5 편집은 500과 다르지만, 몇 천이 지난 후에, 나는 모든 사람들을 같은 "경험이 풍부한 편집자" 범주로 묶을 뿐이다.{{u Sdkb}} 22:21, 2020년 10월 11일 (UTC)[응답]

사용자 배지는 모두 자체 할당되므로 마음에 드는 순위 체계를 자유롭게 구상하십시오. 이삭(토크) 22:29, 2020년 10월 11일(UTC)[응답]

그 서비스 상은 공식적인 중요성이 없고 아무 의미도 없다.그들은 당신이 당신의 초기 포스트를 타이핑하는 것을 필요로 했고, 이러한 답변들이 당신이 그들에게 자격 문제에 대해 소비했어야 하는 것보다 더 에너지라는 것을 읽는다. --Jayron32 17:48, 2020년 10월 12일 (UTC)[응답하라.

편집자가 편집한 횟수에 따라 서비스 상을 받는 것이 위키피디아를 장려할 수 있다고 생각하는 사람이 있는가? 편집카운트염?보르비 (대화) 10시 40분, 2020년 10월 15일 (UTC)[응답]

그래, 위에서 말했지.T8612 (대화) 10:43, 2020년 10월 15일 (UTC)[응답]

많은 요소들이 편집 카운트를 무용지물로 만드는 경향이 있다.나처럼 쥐에 대해 말할 수 없었던 사람에게, 나는 iPad에서 편집하면 참조나 정보 화면을 열고 편집 화면으로 돌아갈 때 입력된 텍스트가 자주 손실된다는 것을 발견했다.따라서 이 방법을 사용할 때 내 편집 횟수는 참조 및 검색 횟수가 적은 작은 글의 경우 일반적으로 컴퓨터에서 5배 이상이다.다운사이즈43 (대화) 23:48, 2020년 10월 15일 (UTC)[응답]

그들은 그저 재미로 하는 것이다.지적된 바와 같이, 해결책은 없으며, 상을 받기 위해 사람들이 허용 가능한 편집을 하더라도 아무도 신경써서는 안 되며, 그들이 나쁜 편집이라면, 음, 블록이 바로 그것이다.더그 웰러 토크 08:42, 2020년 10월 17일 (UTC)[응답]

위키백과 - 신문이 아님 - 2020년 나가노-카라바흐 분쟁 기사

잘못 배치된 요청—이 게시판은 프로젝트 전반에 걸친 우려 사항을 위한 것이다.Talk:2020 Nagorno-Karabakh 분쟁에서 당신의 제안을 제기하라.{{u Sdkb}}07:56, 2020년 10월 18일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

위키백과 기사, 특히 2020년 나고르노-카라바흐 갈등 기사에 '속보'를 포함시키는 것에 관한 제안을 하고 싶다.그 기사의 타임라인 부분을 보면, 공격과 공격 거부에 대한 공식/정부 기관들의 보도가 많다.우리 모두가 알다시피 위키피디아는 신문이 아니다.나는 우리가 현재 진행중인 뉴스를 추가하고, 그들이 통합될 수 있는 시간을 주기 위해, 그리고 2차 출처에 청구와 성립될 청구들의 중립성을 검증하기 위해 최소한 24시간에서 48시간 동안 보류할 것을 제안한다.현재의 배치로, 위키백과 독자가 지상에서 일어나고 있는 일에 대해 일방적 견해를 갖게 될 위험이 있다.이것은 또한 이러한 주장을 검증하기 위해 2차적인 출처를 끌어들이는데 추가 작업이 필요하며, 위키피디아가 신문이 아닌 사타랄린드 (토크) 16:30, 2020년 10월 17일 (UTC)[응답]이라는 점을 감안할 때, 애초에 기사에 있을 필요가 없을 수도 있다.

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

대화 페이지 색인 삭제

의견 일치가 없다.편집자들은 26개의 디인덱싱 토크 페이지를 선호하고 있으며, 23명의 편집자들은 이에 반대했다.토크 페이지는 유해한 콘텐츠(BLP 위반, 저작권 위반 등)를 가질 가능성이 높으며, 이 콘텐츠를 검색 엔진에서 직접 찾을 수 있어 독자들이 혜택을 받지 못할 것이라고 주장하면서, 디인덱싱에 찬성하는 주장은 비교적 일률적이었다.유해 콘텐츠에 대한 우려가 부풀려졌고, 구글 검색은 편집자들이 내부 검색이 일치하지 않는 토크 페이지를 검색하는 중요한 도구라며, 위키피디아는 투명해야 하며, 따라서 검색 엔진으로부터 토크 페이지를 숨기지 말아야 한다고 주장했다.개표에서 작은 차이가 나고 제시된 주장을 할인할 근거가 부족한 점을 감안하면 공감대가 형성되지 않은 셈이다.한 편집자는 관리자 게시판 페이지의 색인 해제를 제안했고, 다른 편집자는 가장 유해한 내용을 완화하기 위해 BLP 기사에 대한 대화 페이지의 색인 해제를 제안했다.그러나 관리자 게시판은 이미 MediaWiki에 의해 색인화되지 않았다.로봇.txt 및 {{BLP} 태그는 이미 대화 페이지를 색인화했다(후자는 BLP 페이지의 토크 페이지 아카이브에 영향을 미치지 않지만, 이는 추가 논의를 위한 포인트가 될 수 있다)._signed,로스길 19:38, 2020년 10월 18일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

위키피디아의 모든 대화 페이지를 검색 엔진에서 색인화해야 할까?이는 일부 비내용 네임스페이스를 색인화할 때의 잠재적 이점과 단점에 대한 유사한 RfC(비-RfC) 토론이 있은 지 약 한 달 후에 나온 것이다.아심 17:23, 2020년 8월 19일 (UTC)[응답]

컨텍스트를 제공하려면:어느 날 나는 내가 선택한 검색 엔진을 탐색하다가 결국 토크 페이지에만 포함된 이미지를 찾게 되었다.내가 이 제안을 하는 이유는 (1) 우리는 어떤 주제에 대한 부정확한 (그리고 잠재적으로 명예 훼손을 초래할 수 있는) 정보가 검색 결과에 나타나기를 원하지 않는다. (2) 대화 페이지는 독자들에게 전혀 도움이 되지 않는다[명백하다: 내 말은 그들이 상위권을 찾는 독자들을 돕지 않는다는 것이다.ic on Google 또는 Bing].나는 그들이 (거부권에도 불구하고) 더 많은 혼란을 야기하는 것으로 보고, 여기서 내가 인용하고자 하는 것은, [토크페이지의 이미지]의 출처를 확인하는 사람들은 전통적인 위키백과 기사 대신에 일부 사람들만이 논평할 수 있는 이상한 종류의 포럼처럼 보이는 것을 보고 혼란스러워할 것이다.이 두 가지 주요 이유로 나는 이 RfC를 시작했다.아심 17:29, 2020년 8월 19일 (UTC)[응답]

우리 대화 페이지를 색인화해야 할까?

강한 반대 - 위키피디아의 검색 도구는 특정 토론 검색을 위해 99%의 시간을 낭비한다.토론 페이지를 검색하는 것이 미디어보다 훨씬 쉽고 유연한 경우가 많다.Wiki가 내장된 검색과 이 제안을 수락하는 것은 나와 구글과 다른 검색 엔진을 사용하는 많은 다른 편집자들이 특히 많은 사람들이 색인 변경을 인식하지 못할 수 있기 때문에 토크 페이지나 다른 토론을 찾는 것을 훨씬 어렵게 할 것이다.에드토크 ! 2020년 8월 19일 18시 44분 (UTC)[응답하라]
Ed6767, 나는 위키피디아의 검색이 특정한 토론을 검색하는 데 사용하기에는 다소 비양심적일 수 있다는 것을 이해한다.나는 방금 MfD에 투표했고, MfD 이전에 삭제 후보로 지명된 페이지가 주제를 검색할 때 검색 결과에 나타나고 있다는 것을 알게 되었다.[2]를 참조하십시오.나는 이것이 우리가 독자들이 보기를 원하는 것이라고 생각하지 않는다.아심 20:43, 2020년 8월 19일 (UTC)[응답]
@Awesome Aasim:분명히 하자면, 폴 A를 말하는 것인가. 보나찌는 구글에서 보여주고 있었다; (ii) 그 토크:Paul A. Bonacci가 보여주고 있었다; (iii) 위키백과:삭제/대화 오류:폴 A. 보나치가 보여주고 있었나? --Redros64 🌹 (토크) 18:33, 2020년 8월 20일 (UTC)[응답하라]
레드로스64, 방금 구글과 검색해 봤는데, 확실히, 토크 페이지가 있어.아심 18:37, 2020년 8월 20일 (UTC)[응답]

@Redrose64: (ii).안녕, 뉴욕브래드 (대화) 18:43, 2020년 8월 20일 (UTC)[응답]
템플릿별:NOINDEX#Warnings, 주요 검색 엔진은 다음 항목을 존중해야 함{{NOINDEX}}태그를 지정하지만 이미 인덱싱된 콘텐츠가 삭제되기까지 며칠 또는 몇 주가 걸릴 수 있다.이 경우 24시간도 채 안 돼 태그가 추가됐다.이상적으로는, 그 토크 페이지에는 다음과 같은 태그가 붙었어야 했다.{{WikiProject Biography living=yes}}몇 년 전. --Redros64 🌹 (대화) 2020년 8월 20일 19:48 (UTC)[응답]
~~나는 대화 페이지가 독자들에게 전혀 도움이 되지 않는다는 주장에 동의하지 않는다.~~토크 페이지는 외부 검색 엔진을 통해 주제에 대한 정보를 찾는 독자들에게 아무런 도움이 되지 않는다는 것을 명확히 했다. 22:03, 2020년 8월 19일 (UTC) 독자로서, 나는 주로 NPOV의 특정 유지 관리 태그를 볼 경우 일반적으로 기사의 토크 페이지를 확인할 것이다.그리고 편집을 시작하기 전에, 예를 들어, 혼란스러운 언어에 대한 명확성을 찾기 위해 가끔 토크 페이지에 가서 ip로서 질문을 하곤 했다.그 두번째 사용 사례가 내 경험을 결격시킬지는 모르겠지만, 내가 질문한 것이 내가 독자가 아닌 편집자가 될지는 확실하지 않지만, 나는 페이지를 편집하려는 의도가 전혀 없더라도, 내가 익숙하지 않은 주제에 대한 사전 논의를 체크하는 데서 분명히 이득을 보았다.

제안 자체에 대한 코멘트는 없지만 사용자:멋진 Aasim, 당신이 이 페이지에서 시작한 이전 토론에 참여한 다른 10명의 편집자들을 한 달 전에 보관할 수 있다고 생각하십니까?내가 틀릴 수도 있지만 나는 그것이 RFC 제안자들에게 표준적인 관행이라고 믿는다.<3 우둔한 몰스 (대화) 20:22, 2020년 8월 19일 (UTC)[응답]

우둔한 Mox, Okay. @Ed6767, Rmhermen, þjarkur, TheDJ, Teratix, Orangemike, GenQuest, John M Wolfson, DGG, Phil Bridger, Schazjmd: 예의 핑핑.아심 20:31, 2020년 8월 19일 (UTC)[응답]

바보같은 몰스, "도움이 없다" 부분을 분명히 하는 것: 토크 페이지는 기사를 개선하고자 하는 편집자들에게만 정말로 유익하다.많은 독자들은 정보의 출처를 찾기 위해 대화 페이지를 찾지 않는다.그들은 주제를 찾는 독자들에게 도움이 되지 않을 것이다.나는 RfC의 맥락에서 그것을 분명히 했어야 했다.아심 20:33, 2020년 8월 19일 (UTC)[응답]

나는 "컨텍스트"에 그 설명을 추가했다.아심 20:54, 2020년 8월 19일 (UTC)[응답]

동의 - 토크 페이지의 쓰레기 함량이 훨씬 더 높으며, 우리가 결코 기사에 남아 있을 수 없는 것들은, "펀치볼 속의 t**d"라는 격언처럼, 단순한 정보 추구자에 의해 우연히 마주칠 준비가 되어 있는, 그냥 대화 페이지에 놓여 있을 수 있다. --오렌지 마이크 토크 21:08, 2020년 8월 19일 (UTC)[응답]
멋진 "대화:" 네임스페이스는 당신의 제안에서 꽤 쉽게 식별될 수 있지만, "다른 논의"에 관한 한, 어떻게 이것을 정의하고 있는가?예를 들어 마을 펌프 전체를 색인화하지 말 것을 제안하는 것인가?— Xaosflux 22:47, 2020년 8월 19일 (UTC)[응답]

Xaosflux 음...일단, 내 생각엔 그냥 대화 페이지나 하자.머리글과 질문을 업데이트해서 그것을 명확히 할 것이다.아심 23:26, 2020년 8월 19일 (UTC)[응답]

구글에 대한 지원은 적절하지 않으며, 나는 내부 시스템이 "너무 어렵다"는 주장 등은 말도 안 된다고 생각한다; 많은 토론 장소(마을 펌프스, 관리자 안내판 등)는 보관 검색 도구를 가지고 있고, 나머지는 특별하다.접두사 색인.불행히도 그런 균열을 뚫고 떨어지는 사람은 결국, 그저 무뚝뚝하게 대할 수 있다.– John M Wolfson (대화 • 기여) 23:01, 2020년 8월 19일 (UTC)[응답]
이전 토론별 토크 페이지 지원.그 이상의 것은 일단 반대하라.— Wug·a·po·des 23:09, 2020년 8월 19일 (UTC)[응답]
지지자들은 솔직히 그것들이 처음부터 색인화된 것에 놀랐다.헤드폭탄 {t · c · p · b} 23:14, 2020년 8월 19일 (UTC)[응답]
모든 *_talk: 네임스페이스에 대한 지원.나는 또한 이 페이지들이 색인화되어 있다는 것에 놀랐다.공개적으로 이용이 가능하긴 하지만, 대부분의 웹사이트들이 비공개하고 우리가 기사로부터 신속하게 제거할 자료를 보관하는 막후 토론에 해당된다.독자들은 거의 항상 기사를 찾고 그것이 어떻게 만들어졌는지에 대한 토론으로 넘어가기를 원하지 않는다.Certes (talk) 00:43, 2020년 8월 20일 (UTC)[응답]
지원 - 어찌된 일인지 이미 이런 상황이라고 생각했다.사용자 공간이 색인화되지 않았다는 것은 알지만, 일반적으로 나는 기본적으로 토크 네임스페이스를 색인화할 필요는 없다고 생각한다(그러나 사례별로 예외를 둘 수 있는 좋은 경우가 있을 수 있다).\\ 01:32, 2020년 8월 20일 (UTC)[응답]
반대(이전 논의에서):나는 대화 페이지를 인덱싱하는 것의 부정적인 영향이 너무 적어서 일반적인 관행을 바꾸는 것을 정당화 할 수 없다고 생각한다. 검색 결과에서 토크 페이지를 접하는 사용자들이 자신의 제목에 분명한 접두사를 부여하여 토론 허브로서의 본질을 파악하여 콘텐츠에 대한 기대치를 적절하게 조정하기를 기대한다. 문제는 아심 빙 검색에서처럼 검색엔진이 토크 페이지 내용을 오해의 소지가 있는 방식으로 제시했을 때다. 빙은 구글과 달리 마우스를 넘기지 않으면 이미지의 도메인을 주지 않고, 그마저도 애매하게 차트의 출처를 '위키피디아'(토크 페이지에서 클릭해야 한다)로 알려준다. 그것은 고쳐야 할 그들의 책임이지 우리의 책임이 아니다. 이 차트의 출처가 분명하지 않게 제시되었다면 문제가 없을 것이다.– Teratix ₵ 03:14, 2020년 8월 20일 (UTC)[응답]

또 다른 이슈는 미디어를 싫어하는 사용자들에게 잠재적으로 부정적인 영향을 미친다는 것이다.위키의 검색엔진, 그리고 외부 엔진을 통해 토론 기록물을 탐색하는 것을 선호하는데, 에드6767의 언급에서 알 수 있듯이, 이런 일은 흔치 않은 관행이다.– Teratix ₵ 03:19, 2020년 8월 20일 (UTC)[응답]

Teratix는 우리가 아니라 [빙의 책임]이라고 말하는 것은 하지 않을 것이다.무언가가 우리의 책임이 아닐 수도 있다는 것은, 특히 빙이 그것에 대해 아무것도 하지 않는다면, 그것을 덜 우리의 문제로 만들지는 않는다.빙이 하는 일은 우리가 통제할 수 없지만 우리가 하는 일은 통제할 수 있다.당신의 다른 주장은 타당하지만(내가 동의하지 않더라도, 위에서 보시오), 나는 단지 그 특정 요점을 주목하고 반박하고 싶었을 뿐이다.– John M Wolfson (대화 • 기여) 03:57, 2020년 8월 20일 (UTC)[응답]

누가 물어보면 빙이 그 문제에 대해 아무 조치도 취하지 않을 것이라는 것을 우리는 확실히 알고 있는가?– Teratix₵ 02:10, 2020년 8월 21일 (UTC)[응답]

그들은 그럴 수도 있고 아닐 수도 있지만, 그것은 우리가 다른 웹사이트들이 우리의 페이지에 대해 "해야 한다"거나 "해서는 안 된다"는 것에 전적으로 또는 부분적으로 근거한 다른 좋은 제안을 거부해서는 안 된다는 요점과는 거리가 있다.– John M Wolfson (대화 • 기여) 03:08, 2020년 8월 21일 (UTC)[응답]

나는 그것이 "그렇지 않으면 좋은 제안"이라고 생각하지 않는다; 그것은 몇몇이 증명했듯이 토론을 탐색하기 위해 외부 검색 엔진을 사용하는 편집자들에게 심각한 부정적인 영향을 미칠 것이다.– Teratix ₵ 03:20, 2020년 8월 21일 (UTC)[응답]

구글에서 검색하는 것에 반대하는 사람들은 정보가 존재하는 맥락을 알아야 한다.기술 노트 섹션에 명시된 바와 같이, BLP의 토크 페이지는 이미 색인화되지 않았다.또한 모든 삭제 토론, 저작권 조사 등 우리가 인덱싱하기 싫은 대부분의 내부 페이지도 이미 노인덱싱되고 있다.모든 대화에 포괄적으로 노인덱싱을 적용할 필요는 없다.구글은 우리가 내부적으로 가지고 있는 검색 엔진보다 훨씬 더 정교한 검색 엔진이다 - 만약 누군가가 토론 페이지에서 어떤 말을 했지만 정확한 표현을 기억하지 못한다면 구글 검색은 내부 검색보다 정확한 결과를 산출할 가능성이 더 높다.내부 검색은 정확한 현에 대해서만 좋다.SD0001 (대화) 03:25, 2020년 8월 20일 (UTC)[응답]
SD0001, 도널드 트럼프 대통령의 토크 페이지가 색인화됐는지 빙을 점검했을 뿐이다.나는 도널드 트럼프 대통령의 토크 페이지만 색인화 되어 있다는 것을 발견했다; 모든 기록들이 색인화 되어있으며, 이것은 잠재적으로 모욕적인 콘텐츠로 BLP에 관한 문제를 여전히 제기하고 있다. 어떤 검색 엔진 순위에도 나타나서는 안 된다.Talk: 네임스페이스의 페이지 색인을 지울 수 있는 것.아심 07:24, 2020년 8월 20일 (UTC)[응답]
이에 대한 해결책은 노인덱싱된 대화 페이지의 아카이브를 만들 때 아카이브봇이 noindexing을 적용하도록 하는 것이다.SD0001 (대화) 07:52, 2020년 8월 20일 (UTC)[응답]
만약 우리가 1000000개 이상의 BLP를 가지고 있지 않다면, 그것은 효과가 있을 것이다.기록물이 적다면, 이것은 분명 실질적인 해결책이 될 것이다.우리가 가지고 있는 수백만 개의 아카이브(또는 {{talkarchive})에 __NOINDEX__를 추가하면 불필요하게 많은 서버 리소스가 낭비되고, 검색 엔진에서 수백만 개의 아카이브에 대한 디인덱싱을 중단하는 데 시간이 걸릴 것이다.게다가, 위에서 언급했듯이, 우리는 비 BLP자들의 토크 페이지에 명예훼손적인 내용을 가지고 있고, 이 명예훼손적인 내용을 각각 억압하려고 하는 것은 비현실적일 것이다.토크 페이지 인덱싱을 해제하면 이 콘텐츠가 깊고 어두운 웹의 일부가 된다.나는 그것이 우리 편집자들이 기록물을 찾는데 불편할 수 있다는 것을 안다. 하지만 이것은 기록 보관소를 거치는 모든 독자들의 1%도 안 되는 것이다.편집자들에게는 익숙해져야 할 일이겠지만, 어쨌든 그들 중 많은 사람들이 대화 페이지를 보지 않기 때문에 독자들은 아마도 덜 신경쓸 수 있을 것이다. (나는 우연히 그 이름표들 각각의 페이지에 걸려 넘어질 때까지 다양한 이름표와 유지 관리 페이지에 대해 배우지 않았다.)아심 15:09, 2020년 8월 27일 (UTC)[응답]
수백만 개의 아카이브에 __NOINDEX__ 추가
중 백만개 이상의 은 전혀 않다백만개 이상의 BLP 기사들 중 가장 많은 수가 대화 기록 보관소를 가지고 있지 않다.
될 이고, 개의 아카이브에 색인을 삭제하는 이 걸릴 것이다. 불필요하게 많은 서버 리소스를 낭비하고 검색 엔진에서 수백만 개의 아카이브에 대한 색인을 삭제하는 작업을 중단하는 데 시간이 걸릴 수 있음
우리가 어떤 방법을 사용하든 검색엔진이 색인을 중단하는 데는 같은 시간이 걸릴 것이다.서버 자원에 관한 한, 그것은 우리에게 큰 관심사가 아니다.WMF는 수백만 달러의 기부를 받고 충분한 자원을 가지고 있다. 서버 자원을 위해서 우리의 끝에서 더 가난한 해결책을 채택하는 것은 어리석은 일이다.
게다가, 위에서 언급했듯이, 우리는 비 BLP자들의 토크 페이지에 명예훼손적인 내용을 가지고 있고, 시도한다는 것은 비현실적일 것이다.과잉진압]]] 이 명예훼손성 내용 각각.
왜 억압하는가?단순히 제거하면 인덱싱이 발생하지 않는다.그 자료는 명예 훼손이 심해서 페이지 색인 작성 여부와 상관없이 어차피 리빌더링/억제되어야 한다.SD0001 (대화) 08:29, 2020년 8월 29일 (UTC)[응답]
몇 가지 수치를 살펴보니 13494개의 BLP 대화 자료만이 존재한다는 것이 밝혀졌다.그것은 봇을 사용하는 노인덱스로서는 꽤 사소한 것이다.SD0001 (대화) 16:04, 2020년 8월 30일 (UTC)[응답]
위와 같은 지원.또한 이것이 이미 사실이 아니라는 것에 놀랐다.나는 당신의 평균적인 조 독자들이 그들이 보기를 기대했던 페이지의 내용이 그들이 실제로 보고 있는 페이지의 내용과 일치하지 않을 때 무관심이나 좌절감으로 반응하는 것을 상상할 수 있다.기껏해야 순 마이너스. -FASTILY 07:45, 2020년 8월 20일 (UTC)[응답]
우리의 토크 페이지에 강한 반대는 위키피디아를 독특하게 만드는 중요한 부분이다.우리는 그것을 숨기지 말아야 한다.—DJ (대화 • 기여) 08:00, 2020년 8월 20일 (UTC)[응답]
DenDJ가 위에서 말한 것과 대조적으로, 우리의 대화 페이지는 기껏해야 너무 자주 당황하고, 때론 모욕적이고 때로는 용납할 수 없는 모욕으로 명예훼손을 일삼고 있다.나는 모욕과 외침만으로 구성된 적어도 하나의 토크 페이지를 지적할 수 있다.우리 내부 엔진은 작동한다.모욕적인 내용을 대중에게 공개하는 것은 IMHO를 용납할 수 없다.더그 웰러 대담 2020년 8월 20일 08:53 (UTC)[응답]
강한 반대 - 나는 토크 페이지가 독자와 편집자 모두에게 검색 결과로서 유용하지 않다는 것에 동의하지 않는다.벤자민 (토크) 09:55, 2020년 8월 20일 (UTC)[응답]
반대 독자가 우연히 대화 페이지에 도착하면, 그들은 그것이 일반적인 위키백과 기사가 아니라는 것을 금방 알게 될 것이다. 게시물이 서명되고, 서로 답장하는 사람들이 있고, &c.나는 그것이 토론 페이지라는 것을 독자들이 이해할 수 있다고 믿는다.기사만 찾고 있었다면 위에 링크가 있는데 금방 찾을 수 있을 것 같아.게다가, Xaosflux가 지적했듯이, "BLP" 템플릿에는__NOINDEX__그래서 명예훼손은 사실 관심사가 아니다.토크 페이지 토론은 꽤 흥미로울 수 있다. 그래서 만약 우리가 전체 토크: 네임스페이스를 색인화한다면 독자의 가치는 없어질 것이라고 생각한다.PJvanMill)talk (11:26, 2020년 8월 20일 (UTC)[응답]
반대 검색 엔진은 사용자들이 원하는 것을 찾도록 돕기 위해 이미 정교한 알고리즘을 사용하고 있다.우리의 토크 페이지는 비공개적이고 특권층이기 보다는 공개적이고 모두에게 열려있다.그것은 바로 그들이 수색자가 찾고 있는 것일지도 모른다.우리는 그러한 결정들을 조사자들과 제공자들에게 맡겨야 한다. 그들을 재평가하고 모든 것을 선제적으로 검열하기 보다는 말이다.문제가 있다면, 우리의 토크 페이지가 너무 적게 이해되고 사용된다는 것이다.이 제안은 상황을 더 악화시킬 것이다.Andrew🐉 (대화) 13:50, 2020년 8월 20일 (UTC)[응답]
지원 토크 페이지는 흥미로울 수 있지만 위키백과 콘텐츠는 아니다.기사는 내용이고 나머지는 모두 내용물을 만드는 과정을 지원하기 위해 존재한다.— 고스트인The Machine 15:17, 2020년 8월 20일 (UTC)[응답]
반대 토크 페이지는 충분히 숨겨져 있지만 위키피디아의 근본적인 부분이다.나는 그들이 더 이상 숨겨서는 안 된다고 생각하는데, 이 포괄적인 제안을 실행하기 위해서는 당신이 보는 것처럼 문제가 있는 내용을 삭제하는 것이 좋다.고마워요.마이크 필 (토크) 2020년 8월 20일 16:09 (UTC)[응답]
지원 "우리의 검색이 불충분하다"는 주장을 접하면서도(꼭 동의하는 것은 아니지만) 기사 주제를 비하하기 위해 대화 페이지에 올라온 BLP 위반 횟수를 생각해 보고, 그 다음 검색 결과에 나타나는 아이디어를 생각해본다.그것 때문에 피부가 기우뚱거린다.--조름 (토크) 18:38, 2020년 8월 20일 (UTC)[응답하라]
설명 - 특별:PermaLink/862856598#새 사용자가 사용자 페이지의 검색 엔진 인덱싱을 허용하지 않도록 방지하여 사용자 공간의 스팸이 하룻밤 사이에 절반으로 줄어들었다.나는 토크 네임스페이스에서 어떤 체계적인 스팸메일을 인지하지 못한다.MER-C 19:08, 2020년 8월 20일 (UTC)[응답]
미디어위키 검색엔진이 크게 개선될 때까지 반대한다.207.161.86.162 (대화) 22:36, 2020년 8월 20일 (UTC)[응답]
지원 토크 페이지는 독자들을 혼란스럽게 할 수 있다.사용자의 검색에 따라 검색엔진이 토크 페이지(검색엔진이 완벽하지 않음)를 끌어 올릴 수도 있다.P,TO 19104 (대화) (연출) 23:03, 2020년 8월 20일 (UTC)[응답]
전략적 지원, 나의 실제 투표는 기권하는 것으로, 나는 검색 엔진 결과에 대한 전문가가 아니기 때문에 WP:이것의 모든 잠재적인 영향에 대해 고려할 자격이 없다.그러나 위의 !votes로부터, 나는 일부 편집자들이 WP를 넣기보다는 구글에서 페이지를 검색할 수 있기를 원하는 그들 자신의 욕구를 우선시하고 있는 것이 걱정된다.리더 먼저 균형을 잡기 위한 전략적 지원으로 나를 밀어 넣는다.나는 토크 페이지가 적절한 백과사전의 일부가 아니므로(WP에서처럼 잘못 정의된 개념) 일반적으로 구글 검색 결과에 설득력 있게 나타나서는 안 된다는 위의 지지 주장을 발견한다.{{u Sdkb}}02:39, 2020년 8월 21일 (UTC)[응답]

토크 페이지 인덱싱은 독자에게 어떤 상처를 주며, 왜 "컨트롤러피디아 적절한" 페이지의 일부만 인덱싱되어야 하는가?– Teratix₵ 03:20, 2020년 8월 21일 (UTC)[응답]

Teratix, 많은 지원자들!이곳에서는 왜 그럴까, 그리고 왜 우리가 내부 페이지가 구글 결과에 나타나기를 원하지 않는가에 대해 논쟁을 벌여왔다.나는 여기서 위키백과에서 독자를 대면하는 것과 비독자를 대면하는 것에 대한 나의 견해를 확장한다. 요약하자면 우리가 만드는 제품(백과사전)과 그 제품을 만드는 데 들어가는 노력을 구별할 수 있어야 한다는 것이다.WP:Reader로 돌아가면, 내가 여기서 가장 강하게 지지하는 견해는 단지 그것이 적절하지 않다는 것이다! 투표는 단지 또는 주로 위키백과 사용자들의 99%가 아닌 우리 자신만을 위한 위키백과를 만드는 것이기 때문에, 우리를 매우 걱정하지만, 위키백과 사용자들의 99%가 아닌 내부 페이지를 찾을 수 있기를 바라는 우리의 욕구를 고려한 것이다.적어도 위에 있는 몇몇 사람들은 독자들의 것보다 그들 자신의 욕구를 더 명확하게 집중시키고 있는 것 같다. 따라서 나의 투표.{{u Sdkb}}^talk00:24, 2020년 8월 22일(UTC)[응답]

내가 지금까지 본 바로는, 지지 논거는 독자의 혼란과 명예훼손과 오해의 소지가 있는 정보의 제시 가능성에 대해 막연히 손을 흔드는 것으로 요약된다.그러나 그들은 이것이 몇 가지 고립된 경우를 넘어서는 중대한 문제라는 어떤 증거도 제시하지 않았다."읽기 대상"과 "읽기 대상"의 구분은 흥미로운 점이지만(토크 페이지가 읽지 않은 페이지일 것이라는 것에 이의를 제기할 수 있지만), 단지 다른 질문을 던질 뿐이다. - 왜 읽지도 않은 페이지는 색인화되어야 하는가?마지막으로, 반대자들이 단지 그들 자신의 경험만을 고려한다고 가정하는 것은 다소 모순적이다.아마도 그들은 단지 대화 페이지의 색인화 여부가 독자들의 경험에 거의 영향을 미치지 않는다는 것을 발견했을 뿐이고, 따라서 그들의 논평에 이러한 고려사항을 포함시키지 않았을 것이다.– Teratix₵ 02:06, 2020년 8월 23일 (UTC)[응답]

나는 여기서 BLP에 대한 우려가 대수롭지 않거나 고립된 사례에 국한되어 있다고 생각하지 않는다.우리는 사생활에 영향을 미칠 수 있는 민감한 정보를 포함시킬 것인지 아니면 제외할 것인지에 대해 BLP 토크 페이지에 대한 논의를 일상적으로 한다.우리는 세계 10위권 안에 드는 웹사이트니까, 우리가 여기서, 심지어 우리의 토크 페이지에도 게재하는 모든 것은 우리가 그것을 발표하지 않았을 때보다 훨씬 더 많은 사람들에게 그 내용을 노출시킬 수 있는 잠재력을 가지고 있다.Take Talk:2020 트위터 비트코인 사기#Premptive 주의사항, 주목할 만한 사이버 범죄를 저지른 것으로 지목된 17세 청소년을 지명해야 하는지를 놓고 불과 몇 주 전 벌어진 토론이다.지금 토론에서, 누군가가 불명확한 주 법원 웹사이트에 법원 기록에 접근하는 방법에 대한 지침을 붙여넣었다.그렇다, 그 정보는 기술적으로 공개되어 있지만, 여기에 포함시킴으로써 정보의 노출을 증가시켰다(WP 위반일 것이다).BLPRIMARY는 모든 BLP 콘텐츠의 유일한 출처로서 법원 기록에 의존한다.즉, 우리는 일상적인 토론에서 대화 페이지에서 용인하는 것에 대해 너무 관대해서 대화 페이지가 색인화되는 것을 좋은 아이디어로 만든다.Mz7 (대화) 06:17, 2020년 8월 23일 (UTC)[응답]

이 링크는 지난 8월 1일 게시된 이후 약 3만 회를 조회했지만 토크 페이지는 181회만 조회했다.나는 토크 페이지를 본 모든 사람들이 실제로 링크를 클릭하지는 않았다고 말하고 싶다.; 토크 페이지를 방문하고, 아래로 스크롤하고, 링크를 클릭하고, 실제로 레코드를 검색하고, 그렇지 않았다면 그것을 찾으려는 열망과 능력이 거의 없을 것이다.(또한 토크 페이지가 검색결과에 나열되어 있기 때문에 발견한 금액은 더욱 적을 것이다) – Teratix ix 04:54, 2020년 8월 24일 (UTC)[응답]

지지, 그리고 이것이 현재 상황이 아니라는 것도 놀랍다.우리는 특히 WP와 관련하여 대화 페이지 대 메인 스페이스에 머물 수 있도록 허용하는 정보의 종류에 대해 꽤 관대하다.BLP 내용.예를 들어 특정 경계선 정보가 BLP 위반에 해당하는지(예: 피해자 이름, 범죄 혐의, 정식 이름과 생년월일 등)에 대해 토의할 수 있으며, 설사 글에서 내용을 생략하기로 합의하더라도 일반적으로 그 내용이 토크 페이지에 가시적으로 남아 있는데 독자가 이를 읽는다면 문제가 된다.s는 구글 검색을 통해 그것에 일어날 수 있다.대안은 그러한 논의에 예의를 표하는 것을 좀 더 자유자재로 적용하는 것이어야 할 것인데, 그것은 오늘날 일상적으로 행해지지 않고 있다.미디어에 대한 논쟁을 찾은 경우Wiki의 검색 기능은 납득할 수 없다; 우리는 특히 독자가 독자를 대면하려는 것이 아닌 콘텐츠를 우연히 발견하게 될 확률을 줄일 수 있는 혜택으로 구글의 토크 페이지 아카이브 검색 없이도 확실히 살 수 있다.Mz7 (대화) 05:32, 2020년 8월 21일 (UTC)[응답]
지원:토크 페이지는 의도된 공개 기사 네임스페이스에 대한 내부 토론이다.외부 검색 엔진에서 색인화할 필요가 없는 부적절한 콘텐츠가 토크 공간에 엄청나게 많이 들어 있다.또한 모든 검색 엔진 사용자들이 위키백과가 어떻게 작동하는지 이해하고, 토크 페이지가 기사 내 위키백과 정책을 위반할 수 있는 사용자 생성 헛소리를 포함할 수 있다고 기대할 수는 없다.— 마크H₂₁^talk 06:21, 2020년 8월 21일 (UTC)[응답]
지원:위키백과:관리.." 행정 네임스페이스는 컨텐츠 구축을 지원하기 위해 사용되며 연계가 필요한 경우를 제외하고 컨텐츠 페이지와 상호 배타적인 것으로 간주되어야 한다.즉, 관리 페이지는 배경에 있어야 하며 독자가 볼 수 없어야 한다."--Moxy 🍁 10:11, 2020년 8월 21일 (UTC)[응답]
반대하라, 왜냐하면 대화 페이지는 우리의 과정에서 매우 중요한 부분이고 우리의 내용을 밝히기 때문이다.무시당하면 누구나 더 멍청해진다.네모 11:08, 2020년 8월 21일 (UTC)[응답]
반대 나는 다른 사용자들을 대변할 수 없지만, 나는 대화 페이지를 찾기 위해 검색 엔진(Google, 내 경우)을 사용한다.검색엔진은 위키피디아의 검색창보다 훨씬 효과적일 뿐이고, 만약 그것들이 색인화되지 않았다면 나는 토론을 찾는데 많은 어려움을 겪었을 것이다.그러나 나는 이 토론이 WP에 관한 것이라는 것을 인정한다.사용자가 아닌 독서자.그것에 관한 한, 나는 그들을 계속 색인화 시키는 것의 해악을 정말로 보지 않는다.기사마다 들어가는 비하인드 작업을 누구나 자유롭게 볼 수 있으며, 자신이 읽은 기사를 작성하고 유지하는데 도움을 준 끝없는 토론에 사람들이 노출될 때 위키피디아의 신뢰도를 더 높여준다고 생각한다.OP는 독자들이 검색 엔진 결과에서 마주치는 토크 페이지 때문에 혼란스러울 수 있다고 언급했다.이것은 사실일지 모르지만(그리고 나는 그것이 사실이라고 확신하지 않는다), 그것은 무관하다.토크 페이지가 무엇인지 모른다는 것은 그들이 접하는 기사를 읽는 것을 더 이상 어렵게 하지 않는다.그냥 링크를 클릭해서 일반 기사가 아닌 걸 보고 떠난다는 뜻이야.검색엔진 결과에서 곧바로 기사로 나간 사람의 경험을 방해하지 않는다. --Puzzledgetable^{Is it teatime already?} 13:29, 2020년 8월 21일(UTC)[응답]
지지하다.나는 내부 검색 엔진이 형편없다는 것에 동의한다.하지만 위키피디아는 현실 세계에 있다.명예훼손의 대상은 우리가 오래된 토크 페이지 토론을 찾는 능력에 개의치 않는다.그렇다, 대부분의 BLP 토크 페이지는 색인화되지 않았지만, 기록 보관소는 그렇지 않고, 비 BLP 토크 페이지에서도 명예 훼손이 발생할 수 있다.황색 투병 (토크)20:41, 2020년 8월 21일 (UTC)[응답하라]
여기 있는 많은 사람들이 무심코 읽는 독자를 너무 많이 생각하는 것 같아.사람들이 Paul A를 올려다 볼 때.보나치(Bonacci)를 클릭하고 (지난 30일 동안 2천명이 한 것처럼) 첫 번째 문장으로서 "이것은 진짜 사례다.Paul은 진짜 사람이다.이 사건은 그가 들어야 할 필요가 있다. 그것은 첫 번째 피자집이다.여기서 자길 찾으면 멈추지 말고...계속 파헤쳐라, 그것은 모두 거기 있다" 위키피디아 자체는 본질적으로 잘못된 정보를 퍼뜨리고 있다; 비록 선별된 소수의 독자들이 이 페이지의 목적을 정확하게 추측할 수 있지만, 이런 일이 일어날 때마다 신뢰할 수 있는 출처로서의 우리의 명성은 손상된다.우리의 목표는 대중에게 세계의 지식에 대한 접근권을 주는 것이며, 편집자들에게 토크 네임스페이스에 대한 조금 더 편리한 검색 도구를 제공하는 것이 아니라, 백과사전의 일부가 아닌 페이지와 모든 것을 위반하는 기사와 다소 유사한 형식으로 제시된 내용을 연결함으로써 그들을 적극적으로 호도하지 않는 것이 가장 확실하다.위키피디아의 기둥.독자들을 위해서, 토크 페이지는 구글에 나타나서는 안 된다.Zoozaz1 (대화) 03:39, 2020년 8월 22일 (UTC)[응답]
반대하다. 앤드류 데이비슨은 다음과 같이 정곡을 찌른다: 문제가 있다면, 그것은 우리의 토크 페이지가 너무 적게 이해되고 사용된다는 것이다.나는 어떤 반대자들처럼 독자들이 대화 페이지를 건너다 보면 그들이 보고 있는 것을 즉시 이해할 수 있을 것이라고 확신하지 않는다.우리의 논의 방법은 현재 시대에 뒤떨어져 있다.하지만 독자들이 기사가 아닌 페이지에서 자신을 발견하는 것은 더 쉽고 흔한 일이어야 한다.누군가 대화 페이지를 찾는 것은 그들에게 위키백과가 무엇이고 어떻게 작동하는지 더 많이 배울 수 있는 관문이 될 수 있다.독자들은 마술처럼 나타나거나 혹은 지금까지 존재해 온 사실적 내용의 웹사이트를 보고 있는 것이 아니라, 시간이 흐르면서 협업과 소통에 의해 구성되는 증명되지 않은 미완성, 불완전한 작품을 보고 있다고 믿어야 한다.모든 편집자는 이미 독자가 되어 있지만, 모든 독자는 편집자가 되어야 한다(오자를 교정할 줄 안다는 의미에서만 알고 있거나, 볼 때 공공 기물 파손이나 허위의 제거가 가능하다면).— 빌로프 (대화) 20:02, 2020년 8월 22일 (UTC)[응답]
- 빌로브, 나는 우리가 대화 페이지와 사용성 면에서 다소 뒤떨어져 있다는 것에 동의한다.나는 또한 위키피디아가 어떻게 작동하는지 알고 싶어하는 독자가 대화 페이지를 볼 수 있다는 것에 동의한다.위키피디아의 어떤 페이지도 전적으로 사적인 것은 아니라는 것을 기억하는 것이 중요하다; 우리는 몇 개의 개인 위키와 미디어위키 소프트웨어가 페이지를 숨기는 것을 허용하지만, 영어 위키피디아에서는 그러한 기능들 중 어느 것도 사용할 수 없다.독자는 여전히 모든 페이지의 상단에 있는 "대화" 또는 "토론" 링크를 눌러 토론 페이지를 볼 수 있다.하지만 그때까지도 대부분의 독자들은 위키피디아가 어떻게 운영되는지에 대해 그다지 관심이 없다.그리고 만약 그렇다면, 그들은 우리의 정책, 가이드라인 등과 우리의 튜토리얼을 직접 보거나, 혹은 그들 스스로 편집하려고 할 수도 있다.그러나 구글이나 빙의 주제를 찾는 대부분의 독자들은 대화 페이지를 찾지 않는다.아심 08:53, 2020년 8월 23일 (UTC)[응답]
Support 메인 스페이스 자체는 명예훼손 편향과 POV 해설의 공정한 몫을 가지고 있지만, 토크 페이지는 훨씬 더 적은 통제력을 가지고 있다.그리고 그것들은 수백만 개가 있다.폐차장은 울타리가 있는 것도 이유가 있다. --푸도(토크) 23:44, 2020년 8월 22일 (UTC)[응답하라]
한번은 BLP에 대한 우려를 보도한 적이 있고, 한 가지(다른 이유들이 있었다) 그것을 제거하지 않은 이유는 그것이 토크 페이지에 있다는 것이었다.우리는 다른 사람들보다 이 공간에 더 많은 미끄럼틀을 놓았어.만약 편집자가 구글에서 기사를 찾고 있다면, 그들은 그 기사가 만들어지게 된 이면 과정이 아닌 구글에서 기사를 찾고 있는 것이다.우리가 소시지를 어떻게 만드는지 숨기지 말아야 하지만, 우리는 정육점을 찾는 사람들을 고깃덩어리로 보낼 필요는 없다.에어콘 (토크) 02:22, 2020년 8월 23일 (UTC)[응답]
강한 지지: 독자는 소시지가 어떻게 만들어지는지 볼 필요가 없다.적극적인 편집자들은 그들이 찾는 "대화" 정보를 찾는 방법을 안다.GenQuest 16:59, 2020년 8월 24일 (UTC)[응답]
지원' 기사가 개선되는 과정은 프로젝트 내부적인 것이며, 대중적이기는 하지만 필요 이상으로 검색 엔진에 광고되어서는 안 된다.이상하게도 최근까지 구글 검색 토크 페이지 조회수를 받은 기억이 없어 이미 디폴트가 될 것 같은 인상을 받으며 살고 있었다. --Matthiaspaul (talk) 18:45, 2020년 8월 24일 (UTC)[응답]
강한 반대 - 무언가를 숨기는 것보다 찾는 것이 낫다.엘렌CT (대화) 01:37, 2020년 8월 25일 (UTC)[응답]
반대 그들은 이미 매우 높은 순위를 차지하지 않았고, 그것은 우리보다 더 나은 검색 엔진을 가지고 특별히 그들을 검색할 수 있기를 원하는 사람들에게 유용하다.잭mcbarn (대화) 05:58, 2020년 8월 26일 (UTC)[응답하라]
대부분 양면적이긴 하지만, 균형을 맞추면 잭 한 사람 당 반대한다.정말로 지지하는 주장은 토크 페이지는 독자들에게 도움이 되지 않으며 완전히 잘못된 내용을 포함할 수 있다는 것이다. 그러나 실제로, 그것들은 매우 높게 색인되지 않았고 일반적인 독자들은 우연히 그것들을 우연히 발견하지 않을 것이다.그러나 색인화해야 할 이유가 있으며, 그것은 (솔직히) 다음과 같다.미디어위키의 검색은 형편없을 수 있다.늑장부리는 Reader (대화) 20:36, 2020년 8월 26일 (UTC)[응답]
만약 토크 페이지 컨센서스를 찾을 수 있는 믿을만한 다른 방법이 있다면 나는 이것을 지지할 것이다. 하지만 그렇지 않기 때문에 나는 그것에 반대해야 한다.—S 마샬 T/C 13:01, 2020년 8월 27일 (UTC)[응답]
지원 만약 사람들이 우리가 왜 무언가를 넣었는지 알고 싶다면, 그 대화 페이지를 찾기가 어렵지 않다.하지만, 나는 서버 자원이 많이 낭비되는 것을 원하지 않는다; 나는 컴퓨팅에 대해 잘 모르지만, 만약 그것이 웹사이트의 속도를 늦추지 않기 위해 RAM(?)을 얼마나 사용하는지에 대한 제한을 두는 것이 가능하다면, 그것이 최선일 것이다.응답할 때 ping해줘, 얘들아!The Kaloo talk 23:35, 2020년 8월 27일 (UTC)[응답]
외부 검색엔진이 오래된 토론 내용을 확인하려는 편집자에게 종종 비판적이라는 위의 다른 사람들의 지적에 반대한다. --Paul_012 (대화) 09:43, 2020년 8월 28일 (UTC)[응답]
반대 나는 우리 독자들이 기사가 어떻게 쓰여지는 과정에 꽤 관심이 있다고 생각한다.토크에 대한 논평:카말라 해리스가 불과 2주 전에 뉴스를 만들었는데, 그것은 위키피디아가 토크 페이지 토론을 광범위하게 인용하는 현재의 사건을 다루는 방법에 관한 많은 기사들 중 하나일 뿐이다(더 최근의 몇 가지 예는 [3][4][5] 참조).xkcd는 토크 페이지를 풍자하는 여러 가지 코미디를 했다.토크 페이지 토론을 찾고 기사의 내용이 어떻게 형성되었는지 보는 것을 더 어렵게 만드는 것은 위키피디아를 덜 투명하게 만들고 독자들에게 해를 끼친다.TheCatalyst31^{Reaction•Creation} 15:20, 2020년 8월 29일 (UTC)[응답]
나는 동의하지 않는다.여전히 '토크'를 클릭해 토크 페이지 토론을 찾을 수 있다.토크 페이지를 찾으려는 사람들은 여전히 현대의 검색 엔진에 비해 상당히 오래된 "미디어위키" 검색을 사용할 수 있다.그리고 위에서 언급했듯이, Talk:Kamala Harris는 이미 색인화되지 않았다.그것은 대서양과 같은 주요 뉴스 출판물들이 미디어를 사용해야 했다는 것을 의미한다.어쨌든 위키의 수색은.아심 19:24, 2020년 8월 29일 (UTC)[응답]
지원 토크 페이지는 내부 토론 과정의 일부로서 독자들이 찾고 있는 것이 아니라고 생각한다.그들은 또한 학대하기 더 쉽다.최근에 만들어진 대화 페이지를 관련 기사 없이 순찰하는 동안, 나는 탐지되지 않기 위해 스팸과 공격 페이지를 만드는 데 여러 개의 대화 페이지가 사용되고 있는 것을 보았는데, 때로는 관련 기사가 삭제되고 소금에 절인 후였다.당시 이 페이지들은 예상대로 여전히 검색 결과에서 높은 순위를 기록했다. - 22^{t • c}:00, 2020년 8월 29일 (UTC)[응답]
지원 토크 페이지는 위키피디아의 내부 토론 과정의 일부여서 색인 해제를 받는 것이 더 나을 것이다.마법사의 파라오 (대화) 04:03, 2020년 9월 1일 (UTC)[응답]
균형에 반대하라, 투명성이 떨어지는 방향으로 움직이는 것은 나에겐 좋지 않은 것 같다.모든 BLP Talk 페이지와 그 아카이브에 NOINDEX를 추가하기 위해 봇을 실행하는 것은 매우 사소한 것으로 들리고, 그것은 사생활/거의 우려를 적절히 커버할 것이다.위에서 언급된 사건인 오래된 기록물들이 미끄러져 들어가 인덱싱된 채로 남아 있는 것은 전체 공간을 디인덱싱하기 위해서가 아니라 좀 더 철저하게 태그를 붙여야 하는 이유가 된다.XOR'easter (대화) 18:47, 2020년 9월 1일 (UTC)[응답]
일반 디인덱싱 반대.절충안으로 BLP 디인덱싱을 지원하십시오.미디어위키 검색이 매우 열악하기 때문에 완전한 디인덱싱은 편집자의 사용성을 감소시킨다.pburka (토크) 20:04, 2020년 9월 1일 (UTC)[응답]
토크 페이지의 콘텐츠로서의 지원에는 허위 정보, 저작권 침해 및 공개 백과사전의 소시지 제작의 일부인 기타 모든 종류의 콘텐츠가 포함될 수 있지만, 조사된 콘텐츠 자체는 아니다.사람들은 WP의 인터페이스를 통해 여전히 이러한 정보를 찾을 수 있지만, 우리는 그것을 외부에 홍보할 필요는 없다. --ZimZalaBim 00:27, 2020년 9월 3일 (UTC)[응답]
지원, 토크 페이지의 내용은 위에서 설명한 것처럼 엔진 방문자를 검색하는 데 사용할 수 없다.우리는 사생활의 문제로서 무작위적인 사람들이 대화 페이지에 접근하지 못하게 해야 한다.Swordman97 05:35, 2020년 9월 3일 (UTC)[응답]

부차적인 측면으로서, 대화 페이지의 색인을 삭제하는 것은 "투명성 저하"로 이어지지 않을 것이다.토크 페이지는 편집자가 되면 가장 먼저 알게 되는 것 중 하나이기 때문에 아예 찾기가 그리 어렵지 않다.Swordman97 05:40, 2020년 9월 3일 (UTC)[응답]

지지하다.토론에 관심이 있는 사용자들은 토크 페이지를 찾을 것이다.토크페이지의 내용은 내부소비를 위한 것으로, 검색결과에 나타날 필요가 없다.그리고 토크 페이지에 나타날 수 있는 유해한 내용의 종류에 대한 OP의 논평은 의미심하다.내부 검색엔진이 엉터리라는 게 문제라면 내부 검색엔진을 개선해야 한다.카아스토크 토크 20:40, 2020년 9월 3일 (UTC)[응답]
위키피디아의 검색기능에 반대하는 것은 "퍼지" 검색에는 상당히 끔찍하며, 기사들은 부담스럽고 비양심적이다.위키피디아의 검색 도구로는 찾을 수 없는 토크 페이지 토론을 찾기 위해 구글을 자주 이용해야 했다. --아헤흐트(TOKPAGE
) 14:17, 2020년 9월 4일(UTC)[응답]
반대한다, 우리는 가능한 한 많이 수색할 수 있도록 해야 한다.미디어위키 검색이 지난 10년간 많이 개선된 반면, 이 제안이 덧붙이는 편집자들의 불편에 대한 이득은 너무 적다.필요한 경우 대상 디인덱싱을 사용하십시오.—쿠스마 (t·c) 09:54, 2020년 9월 8일 (UTC)[응답]
지원 – Talk 페이지에는 확인되지 않고 확인되지 않은 심각한 BLP 위반이 많이 포함되어 있다.대화와 같은 페이지 허용:일한 오마르가 지수화 되는 것은 우리로서는 무책임한 일이다.모든 대화 공간은 색인을 제거해야 한다.이 이슈는 그 자체가 BLP인 페이지에만 국한되지 않는다.모든 토크 페이지는 이 BL 이슈와 카피비오 이슈에 취약하다. --- C&C (커피앤드루션) 05:43, 2020년 9월 10일 (UTC)[응답]
- @커피 앤 크러시:사실, Talk:일한 오마르는 2016년 8월 1차 개정에서 이미 지수화되지 않았다.검색엔진이 noindex를 존중하지 않아 나타나는 경우, 또는 noindex를 존중하지 않는 사이트에 미러링되는 경우. --Dirk Beetstra 14:07, 2020년 9월 10일(UTC)[응답]
반대 - 자료를 검색할 수 있어야 한다.BLP, 저작권 위반 또는 기타 유해한 콘텐츠의 토크 페이지에 심각한 위반이 있다는 것은 명백한 사실이다. 그것은 사람들이 구글에서 그것을 찾든 말든 간에 어쨌든 존재하는 것이다.만약 그것이 문제라면, 그것은 단지 제거되어야 하고 심지어 평가/과시일 수도 있다. --Dirk Beetstra 13:55, 2020년 9월 10일 (UTC)[응답]
Beetstra에 의해 문제를 찾는 해결책으로 반대하라.OhKayeSierra (대화) 12:51, 2020년 9월 11일 (UTC)[응답]
앤드류 데이비슨, 잭맥바른, 니모, 그리고 특히 RusingingReader가 다른 곳에서 표현한 이유로 반대하라. 즉, 현실은 토크 페이지가 이미 대부분의 검색 결과에서 상당히 낮은 순위를 차지하고 있으며, 당신은 종종 나타나기 위해 의도적으로 그것들을 찾을 필요가 있다.검색자들에게 어느 페이지를 가르칠 것인가 하는 문제는 검색 엔진들을 위한 것인데, 검색 엔진들은 이것을 결정하는 데 있어 꽤 정교한 방법을 가지고 있다. 단순히 우리가 그것이 우리의 최고의 작품이라고 느끼지 않기 때문에 우리는 아니다.여기 많은 이들이 강연 페이지를 시대에 뒤떨어진 틈새 포럼에 비유하고 있는데, 이것은 완전히 부정확한 것은 아니다.그러나 현실은 내가 검색엔진을 사용해보고 다른 사람들이 포럼에 올린 정보를 찾고자 할 때가 얼마든지 있다는 것이다.검색엔진은 기사스페이스 품질의 결과를 사용자에게 지적하기 위해서만 존재하는 것이 아니며, 우리는 무엇을 찾아야 할지에 대한 결정을 사용자나 검색엔진에게 결정하지 않고 그대로 두어야 한다.그들은 어쨌든 대화 공간에 너무 많은 관심을 주지 않고 대체로 잘 하고 있다. (이 논의는 BLP 아카이브에 대한 좋은 우려를 불러일으키는데 도움이 되었다. 그러나 나는 거기에 추가적인 특별한 고려사항들을 고려해 볼 때 BOT를 사용하여 자동으로 색인을 표시하지 않을 것이다.한계비용 (대화) 04:20, 2020년 9월 17일 (UTC)[응답]

토론(대화 페이지 색인화)

한 가지 예로, 나는 대화 페이지의 색인을 제거하는 것을 지지하는 사람들이 대화: 네임스페이스가 백과사전의 일부가 아니며 종종 부정확하고 모욕적인 자료들이 흩어져 있다는 것을 암시하는 것 같다는 것을 안다.또 다른 예로, 반대하는 사람들은 구글과 빙에 비해 미디어위키 검색엔진이 형편없다는 것을 암시하는 것 같다.독자들을 위해 대화 페이지를 숨겨두지만, 그것을 찾는 사람들에게 보이는 해결책을 찾을 수 있는 방법이 있을까?아심 03:53, 2020년 9월 9일 (UTC)[응답]

사이트별 검색을 사용해야 누군가가 찾을 수 있는 방법이 있을까?그들이 쓴다는 의미site:en.wikipedia.org수색의 일환으로엘 밀로 (대화) 04:03, 2020년 9월 9일 (UTC)[응답]

그것이 내가 궁금해 하는 것이다.일반적인 검색을 할 때(예: "사이트:en.wikipedia.org cars"와 같이) 토크 페이지가 숨겨져 있고 특정 검색을 할 때(예: "사이트:en.wikipedia.org cars") 볼 수 있는 방법이 있다면 좋을 것이다.아심 04:16, 2020년 9월 9일 (UTC)[응답]

그것은 이미 실제로 일어나는 일이다.메인 네임스페이스에는 대부분의 페이거랭크 등이 있다.외부 검색엔진에서 주의 깊게 페이지를 찾을 수 있다는 사실이 검색결과에 정상적으로 표시된다는 것을 의미하지는 않는다.누군가가 검색 엔진에서 해당 페이지의 실제 인상과 클릭에 대한 통계를 보여주기 전까지는 디인덱싱이 문제를 찾는 해결책이 될 것으로 보인다.네모 18:40, 2020년 9월 9일 (UTC)[응답]

나는 빙의 검색 결과 제거 정책을 발견했다: [6] 그들에 따르면 그들은 법적 요청이나 콘텐츠 제어 시스템을 통해 검색 결과를 제거할 것이다.아마도 페이지를 읽을 것이다; 토크 페이지에는 저작권 침해, 스팸, 민감한 개인 정보가 포함되어 있는가?정답은 한번에 3개 중 어느 것도 가질 수 있다는 것이다.

구글은 개인 정보나 저작권 위반을 사이트에서 제거하기 위해 웹사이트 소유자에게 연락하는 것이 최선이라고 말한다.기본적으로, 구글은 우리의 페이지에 나쁜 내용이 없는지 확인하기 위해 우리에게 책임을 떠넘기고 있다.그냥 정보를 밖에 내놓는 거야.찬성도 반대도 없는 것 같아 이 RFC가 통과될 가능성이 어느 정도인지 모르겠다.하지만 우리가 독자와 편집자 모두에게 효과가 있는 절충안을 마련할 수 있기를 바란다.아심 19:44, 2020년 9월 15일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

두 번 클릭 옵션

다른 섹션 중복. 로그아웃에 대한 내용은 위의 스레드를 참조하십시오. 롤백에 대해서는 아래 참고 사항 참조.— Xaosflux 02:25, 2020년 10월 20일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

롤백 및 로그아웃 작업을 수행하려면 기본적으로 또는 User Prefs에서 사용할 수 있는 옵션으로 두 번 클릭(예: "확실하십니까?")해야 함을 제안하고 싶다.현재, 특히 작은 화면의 휴대 전화에서는, 본의 아니게 이 버튼들을 잘못 클릭하는 것이 너무 쉽다.일부 js 가젯은 os에 따라 롤백(Rollball)에 효과가 있지만, 완전히 효과적이지는 않다. JGHowes 18^talk:44, 2020년 10월 11일 (UTC)[응답]

가젯에서는 이미 롤백할 수 있는 옵션이지만, 아마 그렇게 말하고 있을 것이다. 331닷(토크) 19:05, 2020년 10월 11일(UTC)[응답]

331 도트 나는 그 장치가 고장났다고 생각한다.꾸물꾸물 Reader (대화) 22:51, 2020년 10월 11일 (UTC)[응답]

@ProcrasisingReader: 로그아웃에 대한 내용은 위의 섹션을 참조하십시오.위키백과:빌리지_펌프_(제안)#Log_out_second_chance.롤백에 대한 내용은 관련 작업에 대한 롤백 작업 게시판에 대한 확인 메시지를 참조하십시오.이러한 기능을 비게젯 방식으로 개발하려면 이러한 개발 작업을 완료해야 할 것이다. 이 시점에서 특정 조합에 대한 옵트 인 대 옵트 아웃(예: 로그인 상태/브라우저 유형/모바일 앱)에 대한 몇 가지 선택사항이 있을 수 있다.이 실에 또 특별히 덮고 싶은 것이 있으십니까?— Xaosflux^Talk 13:46, 2020년 10월 16일(UTC)[응답]

고마워, Xaosflux.위의 섹션을 보지 못했으며 로그아웃(그리고 롤백, 이미오)을 두 번 클릭할 수 있는 만족도에 대해 언급하였다. JGHowes 17^talk:48, 2020년 10월 16일 (UTC)[응답]

Xaosflux 나는 당신이 JGHowes를 ping할 의도라고 생각하나? (나는 331dot re 롤백 가젯 제안에 답하고 있었을 뿐인데, 나는 그 가젯이 적어도 모바일 가젯은 고장 났다고 믿는다.)핵심 소프트웨어 기능은 T219781에 의해 추적된다고 생각하는데, 아마도 머지않아 멀리 가지 못할 것이다. 하지만 우리가 무엇이 문제인지 알아낼 수 있다면 우리의 지역 기기를 수리하는 것이 좋을 것이다.미루는 Reader (대화) 16:40, 2020년 10월 16일 (UTC)[응답]

웁스:D 미디어위키 토크에서도 실마리를 열었다.가젯 확인롤백-모바일.js.— Xaosflux 16:54, 2020년 10월 16일(UTC)[응답]

이 섹션을 닫는 중 - 롤백은 이제 핵심 기능입니다, 특수:기본 설정#mw-prefection-rendering, "롤백 링크를 클릭할 때 확인 프롬프트 표시"로그아웃에 대한 내용은 위의 섹션을 참조하십시오.— Xaosflux 02:24, 2020년 10월 20일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

홈 페이지에 로그인 정보가 필요함

www.wikipedia.org 레이아웃은 당사 범위를 벗어났으며, 개선을 위한 구체적인 아이디어가 있는 경우 기능 요청이 제출될 수 있다.— Xaosflux 19:08, 2020년 10월 20일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

내 겸허한 생각으로는 무작위 기사를 먼저 검색한 다음 내 감시목록을 선택하여 접속하는 것이 다소 방해가 된다고 본다.대부분의 사람들은 그들 자신의 감시목록을 책갈피로 채우겠지만, 쉽게 이용할 수 있는 옵션이 없는 것은 직관에 반하는 것처럼 보인다.토크 페이지, 샌드박스, 선호도, 워치리스트, 로그아웃/로그인 버튼 등 개인 계정 정보를 추가할 수 있는가?블루 호박파이 17^Contribs:11, 2020년 10월 20일 (UTC)[응답]

이해가 안 되는 것 같은데, 로그인을 하려면 임의의 페이지를 검색해서 로그인 프롬프트가 뜨도록 감시 목록을 작성해 보라는 말씀이세요?벡터 바탕화면의 오른쪽 상단 모서리에 로그인 버튼이 이미 있어야 한다.{{u Sdkb}} 18:17, 2020년 10월 20일 (UTC)[응답]

@Blue Pumpkin Pie : 어떤 거래처와 피부를 사용하십니까?모든 화면의 맨 위에 있는 대부분의 그것들에 대한 두드러진 연결고리가 있다.— Xaosflux 18:18, 2020년 10월 20일 (UTC)[응답]

Sdkb와 Xaosflux 나는 단지 표준 스킨을 사용하고 있고 나는 구글 크롬을 사용한다.내가 "홈페이지"를 의미할 때.나는 말 그대로 네가 갈 때 첫 페이지를 말하는 거야.https://www.wikipedia.org/아닌https://en.wikipedia.org/wiki/Main_Page . "메인 페이지"를 선택할 수 있는 옵션이 없다.로그인하거나 당신의 계정으로 가는 방법이 없다.첫 페이지에는 임의의 기사를 검색하는 옵션이 있다.편집자로 액세스해야 할 내용을 보려면 기사를 검색하거나 빈 옵션만 검색하면 된다.블루 호박파이^Chat^Contribs 18:25, 2020년 10월 20일 (UTC)[응답]

@파란 호박 파이:아, 그래. 우리의 메인 페이지는 https://en.wikipedia.org이야. 그러니 다른 페이지는 영어 위키피디아에 포함되어 있지 않기 때문에 우리가 특별히 할 수 있는 것은 아무것도 없다는 것을 쓰세요.그것은 또한 위키도 아니고, "감시 목록"과 같은 것과의 링크를 가지고 있는 것은 어차피 어디로 가야 할지 모를 것이다. 예를 들어 독일어 위키백과나 스페인어 위키백과를 읽기를 원할지도 모른다. 이 페이지는 알 길이 없을 것이다.— Xaosflux^Talk 18:32, 2020년 10월 20일 (UTC)[응답]

이해한다.블루 호박파이 19^Contribs:06, 2020년 10월 20일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

공공 기물 파손 혐의와 반달트레이스봇을 평가하는 것?

지난 4일간 @Suffusion of Yellow: 명백한 반달리즘이었던 위키백과 기사에 대한 매우 유사한 편집 3개를 되돌렸고, 3개 모두 현재의 미국 대통령 선거가 끝난 것처럼 쓰여졌으며, 최근 바이든-우크라이나 스캔들에서의 폭로는 "부패한 조의 대통령 당선 가능성을 끝냈다"고 그는 말했다.11월 3일 선거에서 첫 두 건에서 압승하여 패배했고, 세 번째 사건에서는 "민주당의 소아성애자 후보가 11월 3일 엄청난 표차로 패배했다"고 했다.명백한 공공 기물 파손의 세 가지 사례는 사용자에 의한 것이었다.회색지, 사용자:Indanon 및 사용자:조삭.

위키미디어 재단은 현재 다음과 같은 일을 할 수 있는 "vandalTraceBot" 같은 것을 가지고 있는가?

일단 호출되면, "vandalTraceBot"은 의심스러운 사용자에 의한 다른 최근 변경사항을 식별하여 역순으로 사람에 의한 수동 평가를 위해 제시할 수 있다.
평가자는 각 편집에 대해 "좋은 실질 편집", "파달리즘이 아닌 미니어처", "편집 농업", "질문할 수 있고 참조할 수 없는", "검증할 수 없는 파괴 행위", "분명히 무관한 출처를 인용한 질문 편집", "인용된 참조의 부차적 왜곡"과 같은 수준의 등급을 매길 것을 요청할 수 있다(긍정적인 것에서 악의에 이르는 범위).탐지하기 어려운 파괴적 편집에 사용)
평가를 기록한 후에는 사용자에게 편집이 되돌렸는지 여부를 알려주고, 해당 기사와 해당 기사의 현재 상태를 보여주고, 직접 수정하도록 초대하거나, 해당 기사에서 합리적인 편집 기록이 활성화된 두세 명의 사용자에게 S를 검토하도록 요청하는 요청을 Talk 페이지에 게시하는 데 도움을 줄 것이다.평론가가 좀 이상하게 들리는 선출된 글
또한 "vandalTraceBot"은 동일한 IP 주소와 그 밖의 유사한 IP 주소 및 관련 IP 주소의 익명 편집을 사용하는 다른 사용자를 선택적으로 찾을 수 있다.가능한 삭스푸펫 리스트도 상담할 수 있고 평가에 포함될 수 있다.(확인된 socketpuppet 그룹의 몇 퍼센트가 동일하거나 유사한 IP 주소를 사용하십니까?)
잠재적인 반달과 IP 주소의 추적 노력은 점수가 매겨질 것이므로 위키미디어 재단의 임무에 대항하여 활발하게 활동하는 사용자와 IP 주소를 쉽게 식별할 수 있다.
이러한 추적에 대한 기록은 위키미디어 관리자 및/또는 사용자 위원회에서 검토하기 위해 저장될 것이며, 이들은 이러한 종류의 작업을 자발적으로 수행할 것이다.가장 노골적인 공공 기물 파괴 행위 가해자들은 차단될 수 있는데, 아마도 기물 파괴 행위나 실질적으로 편향된 편집으로 표시되지 않은 최근의 편집에 대해 좀 더 면밀한 검토를 거친 후일 것이다.
이 감사 프로세스의 공정성을 문서화하는 데 도움이 되도록 이 평가는 표준 맹목적인 실험 프로토콜을 따라야 한다.평가자가 되기 위해 자원하는 사람들은 보고된 사용자와 무작위로 선택한 다른 사용자를 짝을 지어 평가하도록 요청받을 수 있다.이 데이터 분석은 또한 감지되지 않은 공공 기물 파괴의 비율을 추정하는 데 도움이 될 뿐만 아니라 기물 파괴의 보고서의 신뢰성을 평가하는 데 도움이 될 수 있을 뿐만 아니라 위키피디아의 질을 향상시키는 데도 도움이 될 수 있다.

이와 같은 기능이 현재 존재한다면 어떻게 하면 더 많은 것을 알 수 있을까?그런 능력을 전혀 모른다면, 그런 능력을 만들어 내는 것에 대해 어떻게 생각하십니까?

나는 최근 @무보슈구에게 이와 같은 것에 대해 물었는데, 그는 "그런 도구는 믿을 수 없을 정도로 유용할 수 있고, 그것을 어떻게 창조할 것인지 전혀 알지 못한다.봇 요청 페이지도 있고 아니면 빌리지 펌프에서 의논할 수도 있어."

User:Yellow의 Suffusion of Yellow는 이렇게 썼다, "사용자가 한동안 그 일을 하고 있는 FYI.WP 참조:Sockpuppet 조사/Fishguyen.그들을 막는 데 어떤 도움이라도 고맙게 생각한다고 말했다.

고마워, 데이비드 MCEddy (토크) 12:39, 2020년 10월 19일 (UTC)[응답]

공공연한 공공 기물 파손의 가해자들은 이미 매일 수십 명, 매년 수천 명의 곡조를 차단하고 있다는 겁니다.나는 그들이 이미 노즈백베어 (토크) 19:23, 2020년 10월 19일 (UTC)[응답] 차단되었기 때문에 고반달리즘 비율에 대한 검토의 한 걸음도 내딛는 것을 볼 수 없다.

나는 위키피디아가 User와 같이 노골적인 반복 위반자들에게 큰 문제가 없다는 것에 동의한다.회색지, 사용자:Indanon 및 사용자:조삭, 모두 피쉬구옌의 삭푸펫일지도 모르는, 내가 정확히 이해한다면, 옐로우:의 @Suffusion의 코멘트가 될 것이다.

위키피디아는 더 미묘한 "인용된 참고문헌의 부수적 왜곡"으로 더 큰 문제를 안고 있다.

그 문제를 해결하기 위해 다른 사용 사례와 위의 수정 사항을 제안할 수 있도록 허락한다.사용자:X가 사용자:Warring 또는 스토킹 편집의 Y.

사용자:X에 의한 편집과 사용자:X에 의한 후속 편집 사이의 시간에 대한 데이터를 컴파일할 수 있어야 한다.Y와 그 반대의 경우도 X나 Y가 다른 X나 Y가 뒤따르지 않고 편집한 경우를 추적한다.이런 분석에서 노골적인 스토킹이 명백해져야 한다.

편집은 더 미묘하다.우리는 스토킹과 유사한 통계적 평가를 할 수 있지만 위에서 설명한 바와 같이 인간적 평가로 이를 보완할 수 있다.

이를 위해서는 두 명의 평가자가 필요하다.User:X를 컨트롤과 비교하도록 요청받을 수 있다.다른 하나는 사용자:컨트롤이 있는 Y.그런 다음 평가자들에게 사례 또는 통제권자가 편집 전쟁에 관련되어 있다고 인식하는지, 그리고 만약 그렇다면, 각 양측이 충돌을 부적절하게 다루고 있는 정도를 질문할 것이다.

위키피디아가 고용주의 이미지를 파괴하고 고용주의 반대자들을 공격하려는 유료 편집자들의 문제에 직면해 있다는 것은 확실하다.bandalTraceBott와 같은 것을 사용하는 이 평가 방법론은 ⑴ 조정기로 선택한 사용자들 사이의 그러한 활동의 수준, ⑵ 사용자가 타인을 얼마나 자주 오판하는지, 제3자에 의해 평가될 때 그곳에 없는 것처럼 보이는 동기를 추론하는지, ⑶ 사용자가 주요 문제인 것처럼 보일 때 얼마나 자주 타인에 대해 불평하는지에 대한 데이터를 산출할 것이다.편집 전쟁의 주된 선동자 또는 심지어 편집 전쟁의 주요 선동자.

필요성에 대해 물어봐줘서 고마워.현재의 절차로 보다 쉽고 저렴하고 적절하게 처리되는 문제를 해결하기 위한 값비싼 방법론을 개발해서는 안 된다.데이비드 MCEdddy (대화) 20:05, 2020년 10월 19일 (UTC)[응답]

@DavidMCEddy:아니, 나는 제안서를 제대로 읽지 않았다는 뜻이었고, 당신이 나에게 ping을 한 이후로 단지 그 한 장의 반달에 대해 당신에게 기입하고 있었다. :-) 지금 읽어보면, 여러 개의 등록된 계정의 반달리즘에 반복적으로 사용되어 온 플래그링(개인적으로 CheckUsers) IP를 제안하고 있는 것처럼 보이십니까?이것은 위키피디아처럼 들린다:마을 펌프(제안)/아카이브 169#제안 : 더 큰 선을 위한 대규모 자동화된 사생활 침해.모든 사람을 신고하는 대신 신뢰할 수 있는 사용자가 반달이라고 생각하는 사용자만 신고하면 된다.이는 WP를 근본적으로 뒤집었을 원래의 제안보다 훨씬 더 건전하다.낚시하지 말 것.

하지만 정교한 점수 체계가 필요할지는 잘 모르겠어.요약에 "Vandalism" 또는 "스팸"이 포함된 영구 블록을 찾는 봇만 있으면 되고, 90일 창에서 N개 이상의 기본 IP가 동일한 경우 CU에 연락하십시오.하지만 CU가 가능한 봇이라는 생각은 나를 경련하게 만든다.보안이 어렵다.황색 투병 (대화) 22:12, 2020년 10월 19일 (UTC)[응답]

기본적으로 동일한 메시지를 다른 단어로 사용한 "정치적 부패"에 대한 또 다른 편집은 사용자가 한 것이다.WokyBond가 60초 후에 사용자에 의해 반환됨:그레이조이.나는 이것이 양말뿌리개라는 것을 확인할 수 있는 도구가 없지만, 내 눈에는 그렇게 보인다.

나는 이것이 단지 이것만으로 실질적인 노력을 정당화할 만큼 큰 문제가 아니라는 것에 동의한다.하지만, 위키피디아는 편향된 편집에 더 심각한 문제를 가지고 있고, 그런 문제들이 얼마나 큰지를 특징짓는 데 도움이 될 수 있다.DavidMCEddy (대화) 05:50, 2020년 10월 21일 (UTC)[응답]

전기의 중복 템플릿

위키피디아에 대한 추가 설명:Bot 요청/아카이브 81#중복 템플릿 쌍{{u Sdkb}} 21:11, 2020년 10월 21일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

이들의 설명서에 따르면 {{COI}과(와) {{자율생물학}은 상호 배타적이다.고려 사항:

{{COI}}: 이 태그는 일반적으로 글의 일부 또는 전체가 자서전적인 것으로 보인다는 것을 독자들에게 알리는 데 사용되지 않는다.이런 경우라면 좀 더 구체적인 {{autobiography} 태그를 사용하십시오.자서전 태그를 사용하는 것에 대한 예외는 그러한 사용이 위키백과 편집자의 신분을 드러내는 것이다.
{{autobiography}}}: 이 태그는 널리 사용되는 {{COI} 템플릿보다 더 구체적이다.문제의 기사가 이해충돌에 의해서만 영향을 받는 것이 아니라 그 갈등이 특히 본질적으로 자서전적인 것일 때 그 템플릿에 우선적으로 사용되어야 한다.

그리고 이 검색에 따르면, 현재 206개의 기사가 이 두 가지 모두를 담고 있다.

나는 이것을 치료하기 위해 봇에게 요청할 것을 제안한다; 우리는 각각의 경우에서 덜 구체적인 경우인 {{COI}이(가) 제거되어야 하는 것이라는 것에 동의할 수긍할 수 있는가?Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 9일 (UTC)[응답]

피그선더윙, 문제를 찾는 해결책처럼 들린다.S 필브릭 (토크) 21:34, 2020년 10월 9일 (UTC)[응답]

운이 좋군 - 난 이미 문제를 발견했어: 206개의 기사들은 한 개만 가지고 있어야 하는 두 개의 정리 템플릿이 있어.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 10일 (UTC) 14:43[응답]

좋아.WP에서 이 얘기를 꺼내는 게 좋을 것 같다.BOTREQ는 토론 포럼 그 자체이기 때문에 펌프를 거치지 않아도 된다.나는 위의 Spilbrick에 동의하지 않는다; 한 페이지에 너무 많은 배너를 갖는 것은 분명히 문제다.{{u Sdkb}}}^talk 22:35, 2020년 10월 10일(UTC)[응답]
피그선더윙, 봇 승인을 받는 것보다 수동으로 태그를 제거하는 게 더 빠를 것 같아.WhatamIdoing (대화) 04:53, 2020년 10월 14일 (UTC)[응답]

중복 소스 필요 템플릿

위와 마찬가지로 인용이 더 필요한 {{}}(일명 {{Reftength})과 {{One 소스} 모두 포함된 기사가 많은데, 이런 경우 전자를 제거할 수 있는가?

프레토리아#자카란다 시와 같은 단일 구역에서 템플릿이 사용되는 경우는 피해야 할 겁니다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 9일 (UTC)[응답]

{{Reftene}}}은(는) 명시적으로 WP:V에 관한 것이지만, {{One source}}은(는) WP를 의미할 수도 있다.POV 문제.

그러나 이와 비슷한 노트에 {{Reftene}}, {{More 각주}}은 중복된다.– 피누서톱 (토크 ⋅ 기여) 01:15, 2020년 10월 10일 (UTC)[응답]

당신의 이전 논점에서, 제안된 바와 같이, 제거가 어떤 영향을 미칠 것인가?나는 너의 후자의 지적에 동의한다; 5,539개의 그런 기사가 있다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 10일 (UTC) 14:45[14:45]

일부(예:)는 특정 섹션에만 {{one source}} 태그를 사용하기 때문에 이것은 좀 더 어렵다.

또한, 이것들 중 많은 것들은 시대에 뒤떨어져서 그냥 완전히 제거되어야 한다.내가 연결한 예는 둘 이상의 소스를 포함하는 섹션에 대한 것이다.WhatamIdoing (대화) 04:56, 2020년 10월 14일 (UTC)[응답]

내가 위에 썼듯이, "우리는 단일 섹션에 템플릿이 사용되는 경우는 피해야 할 필요가 있다.나는 많은 예들이 시대에 뒤떨어져서 제거되어야 한다는 것에 동의한다. 그러나 그것은 이 문제와 직교한다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 08:09, 2020년 10월 14일 (UTC)[응답]

요청 제출됨

위키백과 참조:Bot 요청#중복 템플릿 쌍Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 21일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

2020년 위키백과의 아시아 달을 위한 CentralNotice 배너

동료 여러분, 위키백과 아시아인의 달 2020 (2020년 11월 1일 ~ 30일)을 위한 CentralNotice 배너 제안에 대해 의견을 보내주십시오.고마워! --KOKUYO (토크) 19:09, 2020년 10월 22일 (UTC)[응답]

카테고리에 대화 페이지 대신 실제 기사 나열:물품_by_품질

품질별로 기사를 검색할 때 검색된 품질의 예로서 표시되고 연계된 기사가 실제 기사보다는 토크 페이지로 나열된다.Ex: 카테고리:FA-Class_aviation_articles.

이것은 토크 페이지 자체가 FA, GA, C, 또는 다른 품질 표준의 예라는 암시로 인해 혼란스럽다.그리고 당신이 클릭할 때, 그 링크는 여전히 당신을 기사보다는 토크 페이지로 안내한다.

Ex: 509_Composite_Group이 FA 기사임을 확인하려면, 다음 항목을 클릭해야 한다: A) Category:FA-Class_articles(이러한 내용이 Talk 페이지를 연결한다는 명백한 징후는 없음), 다음 B) 범주:FA-Class_aviation_articles (갑자기 모든 Talk 페이지?) Talk 페이지 자체 Talk:509th_Composite_Group (509번 복합 그룹이 FA 기사인데, 여전히 혼란스러울 수 있다는 점에 유의) 실제 509th_Composite_Group에 도착하기 전에 실제의 509번째_Composite_Group을 오른쪽 상단의 작은 별을 볼 수 있다.

(또한, 부차적인 참고: 카테고리 목록을 [[카테고리:]의 변형으로 연결할 수 없는 이유가 있는가?카테고리_이름] {{Cl 카테고리_이름}이(가) 아닌 형식?Talk와 같은 위키피디아에 있는 그룹의 다른 페이지들은 브라우저 바를 잘라내는 것만으로 연결될 수 있다.)

제안: 토크 페이지보다 기사를 직접 나열하십시오.아레스모조 (대화) 21:23, 2020년 10월 19일 (UTC)[응답]

Araesmojo, 위키백과:Billage_pump_(proposals)/Archive_169#Allowing_pages_to_be_categorated_by_tags_on_their_talk_page, 예의 ping Naypta.{{u Sdkb}}}^talk05:50, 2020년 10월 20일 (UTC)[응답]

그것은 중요한 텍스트의 벽이다.네프타의 제안이 그 연결고리가 된건가?{{#pageCat:The category you want}}이 변경에 영향을 주거나 영향을 줄 수 있거나 사용자가 많은 항목보다 이 주제에 대해 더 많이 알고 있기 때문에?어느 쪽이든 예의 ping @Naypta: 그리고 응답에 감사한다.아레스모조 (대화) 19:17, 2020년 10월 20일 (UTC)[응답]

@아레스모조:두 번째 질문에 답하려면 다음 범주에 직접 연결하십시오.[[:Category:Category name]](이것은 모두 {{Cl}})이유[[Category:Category name]] 이 구문은 페이지를 카테고리에 넣을 때 사용된다는 것이 효과가 없다.이 콜론 트릭은 일반적으로 특수 효과를 가지는 네임스페이스에 대한 링크와 함께 사용될 수 있다: 카테고리, 파일, 인터위키 링크 등 – Joe(토크) 11:35, 2020년 10월 20일 (UTC)[응답]

@Joe Roe:고마워 조, 훨씬 더 단순하고 기능성이 존재한다는 것을 깨닫지 못했어.아레스모조 (대화) 16:58, 2020년 10월 20일 (UTC)[응답]

범주:주요 기사 및 카테고리:좋은 기사는 둘 다 존재하며(숨겨서) 그들의 대화 페이지보다는 직접적으로 기사를 포함하고 있다.즉, 간단한 답은 이러한 범주를 대신 검색해 보는 겁니다.

이러한 범주의 멤버십은 작은 FA/GA "top icon" 템플릿에 의해 배출된다.이것들은 낮은 품질 평가 수준에는 존재하지 않지만, 아마도 그들은 그래야 할 것이다.

나는 토크 페이지 배너를 전혀 좋아하지 않는다.기사의 토크 페이지가 어떠한 토론도 받지 못했다면, 나는 그것이 무한정 레드 링크로 남아 있기를 바란다.그러나 아니, 거의 모든 것에 대한 단점을 만들고 하루 안에 토크 페이지에는 5개의 서로 다른 위키백과 주체가 그것을 주장했고 상호 중복되는 "stub-class, 저임계" 등급을 부여했다는 배너가 표시될 것이다.나는 왜 이것이 필요한지, 심지어 얼마나 많은 사람들이 그것을 읽었는지 모르겠다.

결론적으로, 나는 다음을 지지한다.

FA/GA 아이콘 템플릿을 스텁 클래스까지 내려가 모든 설정에서 숨겨진 범주(기사)를 방출하는 통합 "품질 아이콘" 템플릿으로 통합하여 OP와 같은 것에 관심을 갖는 사용자를 위한 탐색에 도움을 준다.
- 나는 또한 CSS를 사용하여 기본적으로 낮은 품질의 아이콘을 숨기는 것에 반대하지 않는다. 그래서 (우리가 캐주얼 독자들이 신경쓰지 않는다고 가정하는 "C 클래스" 또는 "Start-class"의 그래픽 표현을 보기 위해) 로그인하고 선택하지 않는 사용자들에게 시각적 경험은 변하지 않는다.
화염방사기를 다른 평가절차에 가져가는 것은 기사 자체에 콤팩트한 아이콘으로 표현될 수 없다(또는 표현되어서는 안 된다).만약 그것이 "관용"의 규모를 없애버린다는 의미라면, 난 괜찮아.
"Talk:" 네임스페이스에서 전체 기록에 서명된 주석이 0개 있는 모든 페이지 삭제.

-cobaltcigs 10:33, 2020년 10월 23일 (UTC)[응답]

외부 링크에 IMDb, 썩은 토마토 및 메타크리트어 추가(가능한 경우)

투표 전에 위키피디아를 검토하십시오.마을 펌프(제안)#IMDb & Rottle 토마토 등급을 기사 인포박스에 추가(어디서나 가능)많은 같은 주장들이 적용된다.

조사: IMDb, 썩은 토마토 및 외부 링크의 메타크리트어

IMDb, 로튼 토마토, 메타크리트어 또는 유사한 사이트를 위키백과 페이지의 외부 링크 섹션에 그들이 리뷰하는 영화를 대량으로 추가해야 하는가? --Guy Macon (토크) 22:55, 2020년 9월 30일 (UTC)[응답]

모두에게 아니다.

이전 RfC의 결과는 다음과 같았다.

"비평가들은 로튼 토마토와 메타크리트틱을 포함하되 이에 국한되지 않는 등 인포박스에 대한 리뷰 집계를 사용하지 않기로 합의했다.그러한 집계는 인포박스에 적합한 종류의 사실적인 내용이 아니라는 데 의견이 일치한다.추가 컨텍스트 없이 인포박스로 제시하면 어떤 개별 집계 방법론도 적절하지 않다는 우려가 제기돼 왔다."

...그리고...

"인포박스에서 IMDb를 사용하지 않는 것에 대한 동의.제안자 말고는 아무도 지지하지 않는다.이 논의에 앞서 최근의 합의가 있었다(WP:RSP#IMDb) IMDb는 사용자가 생성하기 때문에 등급에 대해 신뢰할 수 없다는 것이다.이 결정을 번복하거나, 그러한 내용을 infobox에 포함시키자는 데 여기서는 의견이 일치되지 않는다."

내 의견으로는, 외부 링크 부분에서도 정확히 같은 주장이 적용된다.나는 이것들을 신체의 원천으로 사용하는 것에 대해 전혀 의견을 갖고 있지 않으며, 여기서 일부러 그런 질문을 하지 않았다. --Guy Macon (토크) 22:55, 2020년 9월 30일 (UTC)[응답]

모든 IDMB에 대한 아니요는 피해야 한다.RT와 MC는 ref로서 reception 섹션에 적합하므로 EL 섹션에 있어서는 안 된다. --Masem (t) 23:07, 2020년 9월 30일 (UTC)[응답]
위에서 지적한 바와 같이, 이러한 모든 웹사이트에 도움이 되는 EL을 만드는 경우는 거의 없다.나는 IMDB 링크를 대량으로 제거하는 것을 좋아하지 않을 것이다.(t · c) 23:24, 2020년 9월 30일 (UTC)[응답]

문제는 그들이 "대량적"이어야 하는가이다.그런 면에서 이것은 거의 봇물 요구처럼 보인다.이러한 링크가 외부 링크 섹션에 있을 수 있는지 또는 있어야 하는지에 대해서는 여기서 의문의 여지가 없다.만약 그러한 노선을 따라 합의점을 찾으려는 의도가 있다면, 질문은 그것을 명시적으로 질문할 필요가 있을 것이다(그리고 질문이 직접적이면 그것이 영향을 미칠 수 있는 수천 개의 기사를 고려할 때, 일단 그 질문이 RfC가 되어 CENT에 게시되어야 한다).일반적인 주제로는, 나는 영화 기사를 자주 편집하지 않는다고 말하겠지만, 나는 대개 아래쪽에 있는 이러한 링크들에 대해 기쁘다.사실, 내가 독자로써 위키피디아를 가장 많이 사용하는 것 중 하나는 영화 기사들(흔히 이 링크를 클릭하는 것을 포함하며, 때로는 이 링크들의 준비된 배열을 사용하기 위해 특별히 위키피디아를 방문하는 것을 포함한다)이라고 감히 말할 수 있다.명백히 그것들은 로튼 토마토 퍼센트 그 자체와 별도로 출처로 사용되어서는 안 되지만, EL 섹션은 출처를 위한 것이 아니다.\ 23:26, 2020년 9월 30일 (UTC)[응답]
- 확실하지 않아서 미안해.나는 최근의 Infobox RfC의 표현을 베꼈다.나는 이런 종류의 링크를 추가하는 봇 덩어리를 원하지 않지만, 봇 덩어리가 그것들을 제거하는 것도 원하지 않는다.편집자가 한두 편의 영화에서 IMDB에 대한 외부 연계가 필요하다고 판단한다면, 나는 그냥 내버려두고 그럴 만한 이유가 있었다고 추측할 수 있다.그러나 내가 보고 있는 것은 모든 영화에 IMDB, 로튼 토마토 등에 외부 링크를 추가하고 있는 편집자들이다.수천 페이지에 외부 링크를 수작업으로 추가하는 편집자는 여전히 '매스 추가'를 하고 있다. --Guy Macon (대화) 21:11, 2020년 10월 1일 (UTC)[응답]
로튼 토마토와 메타크리트어 둘 다 거절하겠어 왜냐면 이미 리셉션 섹션에 인용됐을 가능성이 높거든그러나 IMDb는 참고문헌에 대한 신뢰할 수 없는 출처인 동시에 독자와 편집자 모두에게 매우 유용한 링크라고 여겨지기 때문에, 나는 참고문헌에 결코 사용되지 않는 IMDb를 외부 링크에 추가하는 것에 대해 "예"라고 말하고 싶다.이 토론이 가능한 한 광범위한 청중에게 광고되어야 한다는 점에서 로덴드라이트가 옳다.엘 밀로 (대화) 23:52, 2020년 9월 30일 (UTC)[응답]
질량 추가 또는 질량 제거 없음로튼 토마토와 메타크리트릭 링크(Metacritic Links)는 이미 참조에 있는 경우 제거할 수 있지만 수신 섹션이 없는 기사가 많아 기사를 확장하는 데 사용하고자 하는 편집자에게 유용하며 또한 영화의 공신력을 빠르게 테스트하는 데에도 유용하다.IMDb는 참조로 허용되지 않지만, 미성년 출연자 명단 등에 유용한 외부 링크로서, imv Atlantic306 (토크) 00:14, 2020년 10월 1일 (UTC)[응답]
- 질량 제거는 괜찮지?만약 편집자가 한 두 편의 영화에서 IMDB에 대한 외부 연결이 필요하다고 결정했다면, 그것은 한 가지다.하지만 모든 영화에 IMDB에 외부 링크를 추가하고 있는 편집자들을 만나고 있다. --Guy Macon (토크) 21:03, 2020년 10월 1일 (UTC)[응답]
  - 검토 섹션 없이 페이지에서 Rotten 토마토 링크를 제거하려면 Rotten 토마토 링크를 추가했다가 나중에 External Links에서 제거하십시오.(토크) 08:38, 2020년 10월 1일 (UTC)[응답]
그것들은 일반적으로 존재해야 하지만, 질량을 더해서는 안 된다.간단히 말해서, 그들은 독자들에게 유용하다: 메타크리트어 및 로튼 토마토는 비평가 리뷰의 디렉토리를 제공하고 IMDB는 부모 가이드처럼 비정부적이지만 유용한 정보를 제공한다.외부 링크 가이드라인의 맥락에서 설명하자면, 메타크리트어 및 로튼 토마토는 WP에 속한다.ELIES 기준 3은 주제에 대한 백과사전적 이해에 관련되고...상세 양... 또는 기타 이유로 위키백과 기사에 통합될 수 없는 중립적이고 정확한 자료를 포함하는 사이트로, IMDB는 "고려해야 할 링크" 기준 4, 의존 기준을 충족하지 못하는 사이트를 포함한다.유능한 출처들은 여전히 지식있는 출처로부터 기사의 주제에 대한 정보를 포함하고 있다.우리는 그들을 믿을만한 출처라고 여기지 않는다; 우리는 우리의 독자들이 그들이 탄핵으로 확인되지는 않았지만 여전히 그것들을 사용하고 있다는 것을 알 만큼 충분히 똑똑하다는 기본적인 신뢰가 필요하다.

그것들을 참조와 외부 연결로 둘 다에 대해 WP를 검토했다.ELDUP, 그리고 난 뭐가 문제인지 잘 모르겠어.그것들은 비평가들의 의견 일치를 위한 인용문으로서도 유용할 수 있고 위키피디아의 세부 수준을 넘어 더 많은 독서를 위한 외부 연결고리로서도 유용할 수 있다; 그것들은 공존할 수 있는 별도의 목적이다.

대량 추가와 관련하여, 나는 그것을 지지하지 않는다. 왜냐하면 리뷰가 없거나 적은 영화나 IMDB 페이지가 축소되거나 손상되었을 수도 있는 영화와 같은 예외적인 영화들이 있기 때문이다.{{u Sdkb}}00:56, 2020년 10월 1일(UTC)[응답]

모두에게 아니다.IMDB 등이 일반적으로 '추가 정보'를 추가한다는 데는 동의하지만, 확실히 담요는 없다.나는 IMDB가 IMDB이기 때문에 지금 많은 IMDB가 추가되고 있고, IMDB가 실제로 추가의 가치가 있는지에 대한 비판적 평가 대신 '일반적으로 예스'로 표시되어 있다는 느낌을 갖고 있다.IMDB는 종종 더 광범위한 목록을 가지고 있지만 항상 그렇지는 않으며 때때로 그것이 위키백과의 자료에 대한 확장된 정보인지 물어볼 수 있다.또한 주제 또는 다른, 보다 신뢰할 수 있는 공식 웹사이트의 (일반적으로 연계된) 공식 웹사이트에서 이미 이용할 수 있는 것과 중복될 수 있다.사용자 생성자가 되는 것 또한 그들이 항상 정확한지 물어볼 수 있다.또한 IMDB에 대한 많은 정보가 우리의 기사에 통합될 수 있으며, 그것은 주로 광범위한 목록에 추가적으로 사용될 수 있다.다른 검토는 이미 참조로 사용되거나 참조로 사용되어야 하는 경우가 많다.WP:ELDUP를 일반적으로 따라야 하지만 IMDB나 검토 중 하나가 실제로 훨씬 더 많은 정보를 가지고 있는 예외도 있다.
그러나. 나는 '아마도 미래에는 언젠가'라는 글에 무언가를 쓰는데 사용될 수 있는 자료의 폐기장을 만드는 것에 강력히 반대한다: a) 그럼 그냥 글에 쓰세요, '== 리뷰=========================================================================================메타크리트어 평가...<ref>metacritic url</ref>는 외부 링크 섹션에 '*[<metacritic url>metacritic review]'를 쓰는 데 걸리는 것으로, b) 외부 링크 섹션뿐만 아니라 토크 페이지에도 그냥 덤프하면 된다.불행하게도, 그곳에 첫 번째 리뷰를 갖는 것은 더 많은 (때로는 좋지 않은) 리뷰를 추가하도록 하는 경향이 있다.
이러한 링크는 WP의 지침을 사용하여 사례별로 추가해야 한다.EL과 상식. --Dirk Beetstra^{T C} 07:13, 2020년 10월 1일 (UTC)[응답]
모두에게 아니오(우선순위), 그리고 확실히 메타크리트틱과 로튼 토마토에 대해서는 아니오.모두 다른 곳에서 이용할 수 있어야 하는 사용 가능한 콘텐츠(예: 주목할 만한 비평가들의 리뷰)와 사용자가 만든 콘텐츠의 혼합물을 포함한다.심지어 UGC가 아닐 때도 홍보다.예: IMDB의 플랑드르코믹에 대한 IMDB 엔트리는 COVID-19 전염병에 관한 다큐멘터리 시리즈로, 주요 의료 기관, 언론 및 의사결정자들 사이의 주요 이해 상충을 보여준다.가이 (도움말! - 오타?) 09:50, 2020년 10월 1일 (UTC)[응답]
{{Authority control}}(으)로 마이그레이션하여 해당되는 모든 물품에 사용하십시오.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2020년 10월 1일 (UTC)[응답]
- 권력 장악을 반대한다.외부 링크나 infobox 링크를 삽입하는 것에 반대하는 동일한 주장이 권한 제어에 동일한 사이트를 추가하는 데 적용된다. 이러한 영화 리뷰 소스는 회피적이고 자주 변경되며, 조작이 용이하며, 일부는 사용자가 생성하는 것이다. --Guy Macon (talk) 20:58, 2020년 10월 1일(UTC)[응답]
  나는 ==외부 링크=== 섹션을 채우기보다는 그것들을 작은 템플릿으로 만드는 것이 더 낫다.템플릿 같은 것:의료 자원이면 좋을 텐데.BOTREQ에서 물어봤는데, 봇이 (기사에 이미 나와 있는 모든 것을 추가하지 않고) 현재 링크 목록을 가져다가 우리가 컴팩트하게 (선택적으로, 모바일에서는 전혀) 표시하지 않고 좀 좁은 템플릿에 넣는 것이 가능하다고 하더라.WhatamIdoing (대화) 03:06, 2020년 10월 14일 (UTC)[응답]
모든 사람에게 아니오(이것은 권한 제어에 해당 링크를 추가하는 것을 포함하며, 링크를 더 이상 포함하지 않아야 하며, 더 낮은 품질의 콘텐츠도 포함하지 않아야 한다.'권한관리'가 '고품질 콘텐츠'를 의미하는 것이 아니라는 것을 알고 있지만, 링크를 원하든 위키다타에서 유용하든, 엔위키에서 자동으로 낮은 품질의 콘텐츠에 링크를 추가하는 것은 말이 되지 않는다.)일반적으로 EL(권한통제 포함)의 수는 크게 줄여야지 증가해서는 안 된다.(모든 조상과 족보 관계를 없애기 위해 봇을 제안하는 사람은 누구나 내 지지가 있다.)프람 (대화) 16:29, 2020년 10월 1일 (UTC)[응답]
모든 사람에게 아니다 - 일반적으로 이러한 순위는 너무 덧없어서 백과사전적으로 사용할 수 없다.예외는 특정 순위를 주목할 때(예: 평론가 대 일반인에 의한 순위 차이가 상당히 컸을 때)이다. 그러나 그러한 경우, 특정 주목할 만한 순위를 본문에 언급하고 제3자 출처에 인용해야 한다.순위 사이트 자체에 연결할 이유가 전혀 없다.블루보아 (대화) 20:24, 2020년 10월 1일 (UTC)[응답]
모두 대량 추가에 대한 아니오 - IMdB가 직접 독자와도 관련이 있다면, 추가되어야 하지만, 현재 사용하지 않는 기사에는 확실히 대량 추가되지 않는다.RT와 MC는 일반적으로 WP에 따라 인라인 참조로 존재한다.ELNO, 그런 다음 외부 링크로 복제해서는 안 된다. - Favre1fan93 (대화) 21:16, 2020년 10월 1일 (UTC)[응답]
@Favre1fan93:WP의 어느 지점:ELNO를 언급하는 겁니까?#15일 경우 설명 각주에 주목하십시오. 이 지침은 기사에 내용을 제공하기 위해 출처로 사용되고 있는 웹 사이트와의 연결을 제한하지 않으며, 이는 여기 있는 일부 편집자들이 따르고 싶어하는 것처럼 보이는 "규칙"이 실제로 존재하지 않는다는 것을 상당히 명확히 한다. (실제 WP:ELDUP, 위 내용을 읽어 보십시오.){{u Sdkb}}00:21, 2020년 10월 2일(UTC)[응답]
IMDb에 대한 예, 로튼 토마토 - IMDb에 관한 설명으로, 무엇보다도 (명시적으로 전문적인 버전의 IMDb Pro가 있음에도 불구하고) 데이터베이스가 있다.그것은 위키백과나 다른 웹사이트가 더 나은 개봉일 정보와 영화 위치 등과 함께 제공하는 것보다 기본적으로 만들어진 어떤 영화에 대해 훨씬 더 완전한 출연자 목록과 제작진 목록을 제공한다.가장 큰 영화를 제외한 모든 영화들은 IMDb가 제공하는 관련 정보가 부족할 것이다.영화의 공식 웹사이트(존재하는 경우)와 IMDb는 눈에 띄는 어떤 영화도 포함해야 할 명백한 외부 링크라고 생각한다.로튼 토마토에 대해 나는 가이 마콘이 언급하고 있는 "매스 더하기"(5년 정도의 기간에 걸쳐 손으로 꼼꼼하게 추가) 로튼 토마토는 아마도 5만페이지에서 1만페이지의 필름으로 연결된다(아마도 위키피디아에 대한 거의 모든 편집은 로튼 토마토 링크를 추가하거나 고치는 것 중 하나일 것이다).대다수의 영화 페이지에 리셉션 섹션이 부족하면 독자들이 영화 리셉션을 확인할 곳이 없어졌고, 리셉션 섹션은 종종 "당시 리셉션"에 가깝기 때문에 시간이 지나면서 리뷰가 더 추가되면서 업데이트되지 않았거나 업데이트 되어야 했기 때문에 그렇게 했다.나는 또한 지난 5년 동안 위키피디아가 제시한 정책을 고수하기 위해 최선을 다했다고 믿는다.이 모든 것은, 나는 유지 관리자들이 영화의 외부 링크 섹션에서 허용하는 것을 엄격히 제한하도록 정책을 바꾸기를 원한다면, 그들 중 몇몇은 최소한으로 말하는 것이 쉽지 않다는 것을 이해한다.로튼 토마토는 데이터베이스라기보다는 수익성 브랜드에 훨씬 더 가깝다고 생각한다. 그래서 제 활동이 지지로 해석될 수 있다는 것을 알게 되었다.그러나 나는 메타크리트어와 로튼 토마토의 혼합은 옳지 않다고 주장할 것이다.박스 오피스 모조와 마찬가지로 메타크리틱은 IMDb 페이지를 통해 접근할 수 있다(동일한 모회사 아마존을 공유하기 때문에), 따라서 IMDb 링크와 함께 이러한 링크를 추가하는 것은 다소 불필요하지만, IMDb 링크와 썩은 토마토 링크를 연결할 수 있는 무료 서비스는 (내가 아는 한) 없다.여기서 구체적으로 어떤 변화가 제안되고 있는지는 불분명하지만, 영화 페이지의 위키백과 외부 링크에 관한 어떠한 정책 변경도 분명히 고수할 것이다. -- LudaChrisKlein (대화) 09:20, 2020년 10월 2일 (UTC)[응답]
나는 어떤 것이든 질량화하는 것에 반대한다.나는 이러한 웹사이트를 반자동화 과정으로 위키백과에 추가하는 것을 반대한다.그러나, 나는 또한 그러한 연계가 적절히 사용되고 있는지 여부에 대해서는 고려하지 않고 그러한 연계를 신속하게 제거하는 것에 대해서도 똑같이 반대할 것이다.하지만, 나는 위키백과 정책이나 어떤 종류의 "대량 편집" 행동을 장려하는 지도에 있는 어떤 것도 포함시키는 것에 반대할 것이다. --Jayron32 15:52, 2020년 10월 2일 (UTC)[응답]
- 연결된 텍스트가 없는 외부 링크 섹션에 링크를 추가한 경우, "지원하기 위해 그러한 검토가 사용된 설명 텍스트"가 없다.그리고 한 편집자가 로튼 토마토의 링크를 두어 페이지의 외부 링크 부분에 덧붙인다면, 비록 손으로 한다고 해도, 그것은 확실히 "대량 추가"가 된다.그렇다면 정확히 어떻게 하면 "로튼 토마토에 대한 외부 링크가 적절하게 사용되었는지 여부에 관계없이 그러한 링크의 신속한 제거를 피할 수 있을까?"외부 링크 외에는 "상관"할 것이 없다. --Guy Macon (대화) 16:45, 2020년 10월 2일 (UTC)[응답]

아니, 다 같이 제거해도 괜찮을 거야이것들은 기본적으로 스팸 링크 입니다. --K.e.coffman (토크) 03:27, 2020년 10월 3일 (UTC)[응답]

대량 추가는 아니지만, ELs에 있는 것은 그렇다.나는 대량 추가가 조금 불편하지만, EL 부분 전체에서 IMDb의 존재감을 정말로 제거할 필요는 없다고 생각한다.다른 사람들이 말했듯이, 그곳에 있는 것은 유용하고, 그리고 솔직히...위키피디아는 구글 검색보다 영화를 위한 IMDb 링크를 클릭하기 위해 전에 위키피디아에 가본 적이 있는데, 그것이 항상 상위 결과는 아니기 때문이다.나만 그렇게 하는 게 아니라고 장담할 수 있어.필자는 모든 영화 기사에 꼭 필요한 것은 아니라고 생각하지만, 그것이 결국 EL 섹션의 거의 모든 기사에 추가된다면, 그것이 출처로 사용되지 않는 한 반드시 끔찍한 것은 아니다.ReaderofthePack(구 토쿄그롤79) (｡◕‿‿) 05:44, 2020년 10월 3일 (UTC)[응답]
No mass removal I don't think we should mass add them either. ~ HAL333([7]) 03:52, 5 October 2020 (UTC)[reply]
- Would that include a prohibition on reverting a previous mass-addition or mass removal without changing any other pages? --Guy Macon (talk) 06:56, 5 October 2020 (UTC)[reply]
  - I think you really need to talk to people more involved in the film part of Wikipedia about this. Not least of which because in the manual of style (https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Film) it specifically says "For example, Rotten Tomatoes and Metacritic can provide listings of more reviews than sampled in the article body. They can be included as external links instead of links to individual reviews." So I think this is much more of a actual policy change than some sort of "reverting a past wrong." --LudaChrisKlein 14:16, 5 October 2020 (UTC)[reply]
    - Except that nearly all film pages include RT and MC as part of a reception section (for new films, as a standard part, for older films, predating when RT/MC started, usually as a "contemporary reception" section as well). I've not seen a "well developed" film page that does not use RT or MC in this fashion. --Masem (t) 14:27, 5 October 2020 (UTC)[reply]
      - Looking through a small sample (1000 film pages) only about 20% of pages with Rotten Tomatoes links (which is about 90% of film pages) have them as a reference. About 60% have them as external links. The other 20% have them in both places. Those 20% certainly can have the link removed from the external links. The other 60% with links only in external links sections I'm less sure about. If you go to the talk page for that Manual of Style even the presence of Reception sections seems to be a point of some consternation (merely providing RT/MC links being much less maintenance for editors seems to be the gist of the argument against Reception sections in general). --LudaChrisKlein 08:53, 7 October 2020 (UTC)[reply]
No to keep and No to remove. As usual, editorial decisions should be left to editors, not to robots. When watching the series Queen Insoo, the IMDb review is amusing. They are saying that Hahm Eun-Jung (23 yo) appears there during the 60 episodes, as well as Chae Shi-ra (43 yo). The former is playing Insu before 1457, the later is playing Insu afterwards. How could they both appear in each and every episode ? Moreover the review "three women struggle with one another as each vies for power in the royal court", piously reproduced here, at en:wp, is rather misleading. The whole series is a romanced account of a 50 years clash between the hungu and the sarim factions, and revolves around the seizure of power by King Sejo (1417-1455-1468). This series involves more than 250 actors named in the credits and gives a detailed depiction of more than 150 people, a majority of them belonging to real life History. Missing that gives rather the impression that none of both reviewers watched the series. But this is not a plea for a mass removal, since this doesn't prove that other IMDb reviews are pityful to the same level. Pldx1 (talk) 10:13, 5 October 2020 (UTC)[reply]
No Mass Adds This is a terrible proposal which is quickening the heartbeats of spammers everywhere. GenQuest ^{"Talk to Me"} 14:27, 5 October 2020 (UTC)[reply]
Add ELs only when applicable because per WP:EL, we should only include external links when they provide unique resources "beyond what the article would contain if it became a featured article". We should separate consideration of IMDb from consideration of RT and MC. IMDb, while not reliable for citing, has numerous sub-pages of different kind of resources that usually meets the unique-resource criteria. As for RT and MC, it is only happenstance that the inline citation for the aggregate score and the external link for the directory of reviews (which is a unique resource) are the same link. The ELs for RT and MC can more specifically point to the sub-page listing full reviews. But RT and MC do not need to be used if there are no reviews, or if the reviews on either website can be fully sampled in the Wikipedia article body. For example, if a film has only eight or nine reviews on RT/MC, then these can be sampled in the reception section, and no EL is needed. I think other editors need to be more nuanced beyond just saying that because RT/MC is used as an inline citation, it shouldn't be used as an EL either. The ELs exist to provide access to more reviews. Erik (talk contrib) ^{(ping me)} 16:40, 5 October 2020 (UTC)[reply]
Very well put. {{u Sdkb}} ^talk 17:14, 5 October 2020 (UTC)[reply]
No to all These websites are infamous for being biased --♦/\/\/\TheGeometryDashFan/\/\/\♦ (talk) 18:03, 8 October 2020 (UTC)[reply]
There's no evidence of a bias in either of these websites. El Millo (talk) 18:11, 8 October 2020 (UTC)[reply]

Note: GeometryDashFan12 originally (I presume accidentally) inserted their !vote above my reply to Erik, giving the false impression that I was praising their !vote, not his. I have restored the correct ordering and urge you to be more cautious in the future. {{u Sdkb}} ^talk 18:24, 11 October 2020 (UTC)[reply]
No to all per Masem - IMDB shouldn't be added and MC and RT should be used as cites. –Davey2010^Talk 13:38, 9 October 2020 (UTC)[reply]
No We already have an overreliance on these websites, and a lot of newbies think they are reliable when they clearly aren't. We should not be furthering that perception, nor do we need to be providing SEO for these websites. If folks want it, they can google it themselves. External links should be for relevant yet somewhat hard to find links of interest. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:23, 23 October 2020 (UTC)[reply]

Things I am finding alongside IMDB and Rotten Tomatoes

There are some other external links that I am finding alongside the movie review website external links discussed above. What should I do if I run into the following? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

YouTube of the entire film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

This seems like a clear copyvio, and I have removed them when I found them. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

Keep in mind some short films may be uploaded by the owner of the work, which would be valid. But you need to cross check and confirm the account owner, they hold the rights, etc. If this all checks out, this would be okay, it would be akin to linking to the music video uploaded by the copyright owner (legit) on the WP page about that song. But 999 times out of 1000, for film works, the upload of the full work is likely a copyvio of some means or another.

Films/works confirmed to be in the PD should be kept, though ideally we should go to a source like Archive.org where these are better preserved. For example [8] for Manos: The Hands of Fate rather than any YT version. --Masem (t) 16:55, 2 October 2020 (UTC)[reply]

YouTube of a scene from the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

Nope, unless the scene is extremely well-known to the point that the film is primarily known for the specific scene, and the YouTube license is clear. {{u Sdkb}}^talk 08:56, 2 October 2020 (UTC)[reply]

Any scene from a film (non-PD) that is a subject of discussion should be used as a non-free media file encoded and trimmed per our NFC policies and used as a File: directly. --Masem (t) 16:57, 2 October 2020 (UTC)[reply]

And of course if it is only found in a link in the external links section, it isn't a subject of discussion.

Public domain movies are something I didn't mention above. What about an external link to a YouTube copy of a scene or even an entire film from 1913? At first blush this seems OK, but I think it should be disallowed for the following reasons: [A] any YouTube video can be taken down at any time. [B] many of these old public domain silent films have been released on DVDs with added music or maybe just an introduction that is copyrighted. [C] Many YouTube videos have ads inserted in the in the middle of the content. Besides being undesirable just because they are ads, the ads are not PD. [D] Someone is making money off of that YouTube video, and if we link to it we are encouraging spamming more of the same to make more money. None of these problems apply to a file without any added copyrighted material that we host on commons. --Guy Macon (talk) 17:47, 2 October 2020 (UTC)[reply]

Which I all agree with. Its better to use a commons version or Archive.org version than YouTube which may remain questionable. --Masem (t) 21:39, 2 October 2020 (UTC)[reply]

[A] is true for all web pages, and may even be less true for public domain materials on YouTube than average. [C] is not a problem for YouTube, because Wikipedia:External links permits a reasonable amount of advertising. [D] is irrelevant because Wikipedia:We don't care what happens to your website. Somehow encouraging people to provide appropriate external links is not actually a real problem. WhatamIdoing (talk) 03:15, 14 October 2020 (UTC)[reply]

YouTube of a trailer for the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

Not so sure about this. Doesn't the copyright holder want as many people to see the trailer as possible? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

Hmm, perhaps. Seems a reasonable enough EL. {{u Sdkb}} ^talk 08:56, 2 October 2020 (UTC)[reply]

Perhaps it should be restricted to "official" trailers if possible, just to mitigate the risk that the YouTube link will break in the future if the video is taken down (this is a particular problem on TMDb I encounter on occasion). But I tend to agree that a trailer is a good EL that can't really go into the body of the article as a reference.--LudaChrisKlein (talk) 09:39, 2 October 2020 (UTC)[reply]

I would not include this normally. If the trailer is the subject of discussion beyond just when it was released , we have {{external media}} that can be used to embed a box to direct people to see that near where it is discussed. (eg not a movie but this is used in Untitled Goose Game where the trailer is discussed related to how its popularity and music impacted its development). --Masem (t) 16:15, 2 October 2020 (UTC)[reply]

Trailers are ads and ads are not encyclopedic, thus they violate WP:ELNO and shouldn't be included. (This is different to a discussion about a trailer, but then that would be reliably sourced with secondary sources.) — HELLKNOWZ ▎TALK 16:24, 2 October 2020 (UTC)[reply]

Agree with HK 100%. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)[reply]

OK, unless someone gives me a compelling argument to the contrary, I will remove external links to movie trailers on YouTube when I run across them per Masem and Hellknowz. --Guy Macon (talk) 16:36, 2 October 2020 (UTC)[reply]

Facebook page? Twitter account? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

My big question here is whether I would have to research to see if the account was official. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

I think you would. Facebook accounts are at least sometimes official especially for smaller films. I do think you'd want to confirm that they aren't official before removing them. --LudaChrisKlein 08:49, 2 October 2020 (UTC)

Way easier said than done. There are probably hundreds of thousands of such accounts, how do you get editors to check each one before changing? You don't, because ain't nobody got time for dat! We should not be using FB or Twitter in any capacity on Wikipedia in my opinion, or only in very rare instances where they may actually be the article subject. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)[reply]

If there's an official website, that's sufficient; no need for the Facebook and Twitter. {{u Sdkb}}^talk 08:56, 2 October 2020 (UTC)[reply]

Sorry if I was unclear, I agree. But the issue is that you can't just remove all Facebook links because some of them will be the official site. If there is another official site in the external links then yes, I think you can remove the facebook link without checking. But whether Guy will have to "research if the account was official" I think the answer is generally yes. In my experience facebook accounts are not typically included in External Links sections, and so when they are (and no other official website is listed) I think you'll definitely have to check to make sure it isn't the official website for the film. --LudaChrisKlein (talk) 09:24, 2 October 2020 (UTC)[reply]

Link to Getty Images or any other image hosing site? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)[reply]

I would just consider the official website and the IMDb page to be somewhat-essential as part of External links. El Millo (talk) 22:51, 1 October 2020 (UTC)[reply]

Official website, yes; Imdb, not always. Can someone tell me why we locked into IMDb and not some other publicly edited movie site. I think they all should probably go in most cases. At the least these EL entries should be limited to just one per article. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)[reply]

Can we get an example of an image hosting site in the external links section? I can't really think why something like that would belong in external links, but maybe in some cases. --LudaChrisKlein (talk) 08:51, 2 October 2020 (UTC)[reply]

I'm confused as to why this would be present, same as Luda. {{u Sdkb}}^talk 08:56, 2 October 2020 (UTC)[reply]

Grant Crabtree#External links and Women's American Basketball Association#External links have links to photobucket. Both photobucket pages have been taken down, so I assume that they were not official pages. If somebody put links to now-deleted photobucket pages in the external links to those two articles, I am pretty sure that an exhaustive search would turn up some examples of external links to pages from photobucket or other image hosting sites that haven't been taken down yet. --Guy Macon (talk) 16:10, 2 October 2020 (UTC)[reply]

@LudaChrisKlein, you might want an Instagram account for a photographer. WhatamIdoing (talk) 03:17, 14 October 2020 (UTC)[reply]

@WhatamIdoing: but those are generally already linked from the official website of the photographer already. --Dirk Beetstra^{T C} 06:14, 14 October 2020 (UTC)[reply]

I was thinking of cases when the Instagram account is the official website. WhatamIdoing (talk) 06:43, 14 October 2020 (UTC)[reply]

Guy Macon, many movies have an official page on the company website (https://frozen.disney.com/??), and I can hardly imagine that any commercial movie will not have such a page somewhere. Per WP:ELMINOFFICIAL, we link only one (original bolding) official site, twitters, facebooks, youtube-trailers, etc. etc. are then hardly useful. Only for old movies that do not have an official website (anymore) I would consider to add youtube uploads of their out-of-copyright movies, and even official movies that have been uploaded by the owner are generally linked from (if not embedded in) the official website of the owner (and I then find it hard to imagine that any facebook or twitter is 'the official <social media>' of the subject). Beyond ELMINOFFICIAL, I do think that we should generally minimize the number of links, and an official website generally links to most of the rest of the material. --Dirk Beetstra ^{T C} 06:14, 14 October 2020 (UTC)[reply]

Template:cite web: New keyword(s) for url-access / New parameter(s)

Library Card access

In template:cite web, under Subscription or registration required, the url-access parameter should support indicating that access is permitted via the The Wikipedia Library Card Platform.

I realize that there are some considerations regarding this approach:

Access is not universal, but rather depends on the ongoing accomplishments, and in some cases the successful application, of the individual editor.
Access to a database may shift, as it can withdraw its participation.
Access to a database might be limited to a specified number of editors.
An editor might attempt to game the access requirement by making many trivial edits.

However, there is also a potentially positive aspect: potential users of the Library Card might be incentivized to be more productive in their Wikipedia efforts. Larry Koenigsberg (talk) 20:45, 2 October 2020 (UTC)[reply]

Oppose per WP:READER. {{u Sdkb}} ^talk 21:14, 2 October 2020 (UTC)[reply]

I think I would oppose because there is very little guarantee that TWL will always have the same access to the various databases it currently enjoys. --Izno (talk) 21:17, 2 October 2020 (UTC)[reply]

Oppose The content of pages in article space should be useful to readers, but anything about The Wikipedia Library is only useful to editors. Jackmcbarn (talk) 21:01, 4 October 2020 (UTC)[reply]

Comment is knowing that content could potentially be accessed without paying really not useful for readers? If someone really wanted to learn more but didn't have the financial means, giving them a viable alternative sounds useful to me. --Paul Carpenter (talk) 01:17, 10 October 2020 (UTC)[reply]

Oppose per above. BUT it would be nice if there was a way like how we have Special:BookSources for when we link ISBN's , that we could do the same for DOIs and other academic papers so that a reader and/or editor can determine if they have access quickly. But this would be outside the template's ability. --Masem (t) 15:37, 5 October 2020 (UTC)[reply]

Comment From a Wikipedia Library perspective, I just want to echo the above comments and say that I also don't think this is the best way to go about this. That said, I do think it would be great to be in a place where the links between citations on Wikipedia and access through the Library Card was more direct for editors - the underlying problem here is very reasonable. You could imagine a world in which editors could, for example, turn on a preference which automatically redirected links from Wikipedia through The Wikipedia Library's proxy if the user is eligible for access at that time. The database lists and authorization would then be kept up to date and always contextually accurate, you wouldn't need to take multiple steps to access the source, and it wouldn't bother readers. Would that solve the underlying issue identified here? To be clear this is just an idea, not something we plan or have capacity to work on in the short term :) Samwalton9 (WMF) (talk) 10:37, 13 October 2020 (UTC)[reply]

Samwalton9 (WMF), having a gadget that did that sort of redirect would be fantastic! {{u Sdkb}} ^talk 20:57, 24 October 2020 (UTC)[reply]

Geographical Restrictions (inc GDPR)

An innocent European has been locked out from a world news source.

Many news websites have, since GDPR, stopped serving content visitors in the European Union^[1]. This is often pitched as a temporary measure, but I doubt the ones that are still doing this are going to change any time soon. It's not hard to get around, but it does limit verifiability for the casual reader. I don't know if there are other common geographical restrictions but I'd guess there are some.

The url-access= field in citations doesn't have an option to cover this. There is the option limited but this gives the alt text "Free access subject to limited trial, subscription normally required" so it's not exactly descriptive. My proposal is that there be a keyword allowed for geo-restricted that would look give a image instead of a padlock and alt text saying: "Can only be accessed from certain countries". --Paul Carpenter (talk) 00:56, 10 October 2020 (UTC)[reply]

@Paul Carpenter: Sounds good. In the template code, {{{url-access {{Geoblock check url={{{url}}}}}}}} can be used (see {{Geoblock check}}) to automatically mark all the domains from data.verifiedjoseph as geo-restricted. Perhaps it would be better to have geo-restriction as a separate parameter though. — Alexis Jazz (talk or ping me) 15:12, 10 October 2020 (UTC)[reply]

@Paul Carpenter: Some YouTube videos are geo-restricted as well. — Alexis Jazz (talk or ping me) 15:20, 10 October 2020 (UTC)[reply]

Yes I was wondering if having a separate parameter might be better, after all something could be geo-restricted and limited access once you get there. I'd hope that if/when this is implemented, it should be pretty easy for a bot to add it to all offending citations. And good point about the Youtube videos, that's definitely worth highlighting. --Paul Carpenter (talk) 15:23, 10 October 2020 (UTC)[reply]

@Paul Carpenter: Such a bot would have to run continuously and also go after any changes to the list so that things get updated when a site is added to or removed from the list. So I wouldn't call it "pretty easy". — Alexis Jazz (talk or ping me) 23:57, 10 October 2020 (UTC)[reply]

I mean to say, easy for a bot to do once, rather than to monitor it, which would obviously be a lot harder. -Paul ❬talk❭ 07:14, 11 October 2020 (UTC)[reply]

Thoughts Trappist the monk? ProcrastinatingReader (talk) 15:28, 10 October 2020 (UTC)[reply]

Adding different keywords and tool-tip text for the already existing access icons is simple so not hard to do this: url-access=geo-blocked →

. I'm not at all enthusiastic about the pink globe. Too many words were spent and an rfc required before we could settle on the three access icons we have now. I'd rather avoid that sort of bikeshedding.

—Trappist the monk (talk) 21:30, 10 October 2020 (UTC)[reply]

I support the idea of indicating geo-restricted sources, I'm not particularly interested in bickering over what icon to use. So I'm with you on that. — Alexis Jazz (talk or ping me) 23:57, 10 October 2020 (UTC)[reply]

I imagined the icon would need to be distinct from the ones currently in use, but I can't say I hold a strong opinion about what the icon should be. -Paul ❬talk❭ 07:14, 11 October 2020 (UTC)[reply]

I would not support indicating this. Support for worldwide access will come and go, and there are ways to work around it besides. On an aside, this has come up before; please review the WT:CS1 archives. --Izno (talk) 03:35, 11 October 2020 (UTC)[reply]

Part of the problem here is that the editor adding the reference would not know that the content was geographically restricted - it's only people who can't get at the content who would know this.Nigel Ish (talk) 10:51, 13 October 2020 (UTC)[reply]

This would be very useful for European readers. Just as it is helpful to know that an article requires registration or subscription and I shouldn't waste my time clicking the link (or I should use the archive link instead) the same applies to GEO-blocked links, and we don't expect the person adding the reference to include those either.

Much as I would like this to happen I do think it would need to be quite specific, and not a too generic because there are readers from many other countries (many websites blocked in China for example) that are blocked in a less predictable or consistent way than the groups that block Europeans readers over GDPR.

A picture is worth a thousand words: please don't use a picture, use a few well chosen specific words instead, tooltips as Trappist the monk suggested sounds pretty good too. -- 109.76.205.197 (talk) 00:04, 23 October 2020 (UTC)[reply]

References

^ Jeff South (2018-08-07). "More than 1,000 U.S. news sites are still unavailable in Europe, two months after GDPR took effect". Websites had two years to get ready for the GDPR. But rather than comply, about a third of the 100 largest U.S. newspapers have instead chosen to block European visitors to their sites.

Listings of Articles by Both Quality and Importance with Quick Links

I'm in a mode of trying to find worthy candidates for editing, so second proposal. Currently, well sorted Category lists appear to exist for articles ranked by Quality Category:Articles_by_quality and separately by Importance Category:Wikipedia_articles_by_importance. There is also a listing for Category:Articles_by_quality_and_importance, however, it does not appear to be nearly as complete and looks almost compiled by hand. A natural connection for these groups appears to be the table shown below from the article on Wikipedia:Content_assessment.

All rated articles by quality and importance
Quality	Importance
Quality	Top	High	Mid	Low	???	Total
FA	1,445	2,265	2,211	1,598	174	7,693
FL	165	610	681	631	107	2,194
A	312	631	745	510	94	2,292
GA	2,872	6,517	13,118	16,237	1,670	40,414
B	14,916	28,806	46,427	49,588	17,325	157,062
C	14,872	46,516	113,715	220,548	71,665	467,316
Start	18,738	89,035	385,149	1,312,435	380,612	2,185,969
Stub	4,374	32,161	278,059	2,566,129	833,241	3,713,964
List	4,429	15,399	46,711	159,946	74,173	300,658
Assessed	62,123	221,940	886,816	4,327,622	1,379,061	6,877,562
Unassessed	118	466	1,490	15,205	396,299	413,578
Total	62,241	222,406	888,306	4,342,827	1,775,360	7,291,140

About this table

Suggestion: Adding links to this table so that if I want to find a Stub article with High importance to Wikipedia, I can simply click on the correct box. Being able to immediately find those articles seems like it would be valuable for potential editors. Araesmojo (talk) 22:13, 19 October 2020 (UTC)[reply]

@Araesmojo: That sounds fine to me. To make it happen, you don't really need to come here; just find the underlying template that's generating the tables like the one above, edit its sandbox to introduce the functionality you're describing, and then make an edit request to implement the change.

As a side note, if you're looking for articles needing improvement, check out WP:TAFI or the WP:Vital articles lists. {{u Sdkb}}^talk 05:57, 20 October 2020 (UTC)[reply]

@Sdkb:Thank you for the answer Sdkb. I didn't want to undertake a change that seemed so significant without at least checking here. Modifying anything related to ratings seemed like it might set off a firestorm. I will try implementing the change later today. Araesmojo (talk) 16:17, 20 October 2020 (UTC)[reply]

@Sdkb:Making a larger second response because I looked into the situation and it is non-trivial to say the least.

This table has been created by WP_1.0_bot, perhaps one of the most prolific bots on Wikipedia. Including @Audiodude: and @Kelson: because they appear to be the current owners. The bot is in its 3rd generation. Originally written by Oleg_Alexandrov with a 1st gen until 2010, transitioned to Theopolisme with a 2nd gen until ~2019, and now is in its 3rd gen developed primarily by audiodude. Its source code currently appears to be primarily Python / SQL with small portions of Javascript frameworks related to Wikipedia. It has a github source code page at WP1.0 Bot Source with approximately 1 MB of uncompressed source files after download.

The 3rd gen WP1.0 Bot actually generates tables very similar to those I requested on a project by project basis such as User:WP_1.0_bot/Tables/Project/Catholicism or those shown at User:WP_1.0_bot/Tables. It is run off of Toolforge with a tool account. It can be used to summarize or update individual projects using Wikipedia 1.0 Server. The WP1.0 Bot has had a difficult history of both crash issues and unusually high numbers of logins ~13k / day because of the extremely complex compilation task it has and the large number of pages it needs to touch.

Because of these versions (1st, 2nd, 3rd) and issues where for a significant time it wasn't even clear who the WP1.0 Bot's owner was, there is some chance there may be a separate issue that the table I linked may actually be woefully out of date. Its possible it hasn't been updated since 1st gen. That's all the info I currently have and perhaps the authors will be able to add further. Araesmojo (talk) 20:37, 20 October 2020 (UTC)[reply]

Hi @Araesmojo: That's a pretty good history of the WP 1.0 bot! You are correct that it's on its third generation, and I am the primary maintainer with help from Kelson. You are correct about the location of the bot's source code. One thing to note is that while the 2nd gen ran on toolforge, and there is still a redirect there from the old web frontend to the new one, the 3rd generation runs primarily on Wikimedia Cloud VPS. The table you linked actually transcludes this page which was updated on October 12 (though it's supposed to be updated every day, I'll file a bug for that in the project's Github page). So it is pretty up to date.

Anyways, as you've noticed, there is a web frontend that allows you to browse individual WikiProjects, which make up the entirety of what is included in the "master" table. This allows you to browse articles in specific categories, with links back to Wikipedia, much like you were suggesting, except that it's limited in scope to the specific WikiProject. I would recommend this as a great place to look for articles that need improvement, in an area where you might have expertise. The only reason that we don't have the overall articles table in the web frontend is that it deals with so many millions of articles that it would be very slow to generate for the user and difficult to browse. Hope this helps, audiodude (talk) 22:12, 20 October 2020 (UTC)[reply]

@Audiodude:Thank you for the reply and clarification audiodude. The distinction about the Wikimedia Cloud VPS was not clear from the bot's landing page. I can comprehend the lack of including the overall article table, as a user generatable table requiring looking at all of Wikipedia to create it would be quite complex. Would it be possibly to simply have the master table generated purely by the bot and not an option for normal users? Then it could be effectively static from their perspective and point to links such as the third item in my original post Category:Articles_by_quality_and_importance that seems to be out of date "last generated 28 August 2019‎" and with only 95 categories.

Ex: If I want to find Category:C-Class_Computer_Security_articles_of_High-importance I would click on the pre-made table in the box for C-Class, High Importance, it would then take me to a listing of Category:C-Class_articles_of_High-importance (doesn't exist), then the previously mentioned Category:C-Class_Computer_Security_articles_of_High-importance listing, and then perhaps Botnet if it struck my interest since we're on the topic of bots. Some of these pages seem to already exist, they're just not rolled into the new generation bot. Thank you for your work maintaining what looks like a rather complex bot. Araesmojo (talk) 23:31, 20 October 2020 (UTC)[reply]

@Araesmojo: That sounds like a lot of work, with also writing a lot of pages to Wikipedia, for questionable benefit. Like I mentioned, you can already browse listings for WikiProjects such as Computer Security here and here is the listing for High Importance, Stub quality. audiodude (talk) 19:29, 23 October 2020 (UTC)[reply]

@Audiodude: That's fine. You're the owner and maintainer of the WP 1.0 bot not me. Purely a suggestion. I'm already progressing in the direction of just looking for links and articles. Araesmojo (talk) 19:33, 23 October 2020 (UTC)[reply]

@Araesmojo: the assessment scheme does not and cannot answer your question (such as what Stub articles are High-importance to Wikipedia). Assessments only record an article's importance to a particular WikiProject. The same article can be Top-importance to one WikiProject and Low-importance to another. Sure, you can infer that an article that is Top-importance to any WikiProject is relatively important to Wikipedia as a whole, but comparisons become needlessly complicated (obviously, a Top-importance Countries article is probably more important than a Top-importance Sheffield article, but comparisons need to be judged by a human).

Luckily, there is a system that records an article's overall importance to Wikipedia. Vital articles lists 50,000 articles that are most important to Wikipedia as a whole, in 5 "levels". The categories are here. You'll discover that there are two C-class articles in the highest level-1 that could need some work. Level-4 even has some Stub-class articles. – Finnusertop (talk ⋅ contribs) 21:22, 26 October 2020 (UTC)[reply]

A new category :-)

Hi, how are you, hope you're great. I was reading about the First World War and I came across Frank Buckles, last American survivor. I read he was a National Rifle Association member and I added the category "American gun rights activists", and I had an idea, what if I create the category "NRA members"?, or "NRA people"?, do you think it complies policies?. Well, I anxiously look forward to advice. Sweet greeting. –Iván– CoryGlee (talk) 23:07, 23 October 2020 (UTC)[reply]

Category:National Rifle Association is small enough that members don't need their own sub-category. Presidents already have one. davidwr/(talk)/(contribs) 23:57, 23 October 2020 (UTC)[reply]

See WP:OCAT. For almost all members, it is not "defining", & I imagine such a category would be deleted at WP:CFD. Johnbod (talk) 03:45, 27 October 2020 (UTC)[reply]

Proposal for new WikiProject to conduct a sweep of all old articles

You are invited to join the discussion at Wikipedia:WikiProject Council/Proposals/Sweep. {{u Sdkb}}^talk 08:11, 27 October 2020 (UTC)[reply]

Simplify making templates

Not appropriate for this page, since not a defined proposal. {{u Sdkb}} ^talk 04:07, 8 November 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I asked at Wikipedia: Help desk how I would go about making a template for Wikipedia: WikiProject Mysticism. I was told I would have to go to Template: WPBannerMeta to read the instructions there. The instructions there I found very long-winded and complicated. I tried creating a template on the sandbox of my user page, but always with no avail. Would it be possible to simplify instructions for making templates? Vorbee (talk) 19:33, 7 November 2020 (UTC)[reply]

Ask for help at Template talk:WPBannerMeta and someone will help you. WikiProject banners are an incredibly complex piece of machinery, so these are not the place to start to get familiar with templates writting. Headbomb {t · c · p · b} 19:49, 7 November 2020 (UTC)[reply]

Note that {{WikiProject Mysticism}} already seems to exist. Headbomb {t · c · p · b} 19:51, 7 November 2020 (UTC)[reply]

What do you want the template to do? Perhaps an example would help — GhostInTheMachine ^{talk to me} 20:28, 7 November 2020 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

UBX pseudo-namespace

In order to browse userbox galleries easily, I propose to use the UBX pseudo-namespace for the purpose (a la MOS: pseudo-namespace). Note that this pseudo-namespace is proposed to browse userbox galleries, not individual userboxes. I created UBX:GAL to redirect WP:UBXG more than a year ago, but was deleted since UBX: is not currently recognised by community. --Soumya-8974 ^talk _contribs ^subpages 16:50, 6 November 2020 (UTC)[reply]

WP:XNRs have a consensus not to create more, and certainly we should not put these directly into main space. --Izno (talk) 20:03, 6 November 2020 (UTC)[reply]

Oppose too niche, unlike MOS or CAT, IMO. – John M Wolfson (talk • contribs) 00:35, 10 November 2020 (UTC)[reply]

Log out second chance

Tracked in Phabricator
Task T217914

Isn't it about time Wikipedia had a "safety valve" on the "Log out" icon? I have accidentally logged out many times because I clicked the icon by mistake, and then I had to log in all over again. It should be a simple matter to modify the software so when an editor clicks the icon, a message appears, asking, "Are you sure you want to log out? Yes, No."—Anita5192 (talk) 18:16, 27 September 2020 (UTC)[reply]

Agree . {{u Sdkb}}^talk 18:24, 27 September 2020 (UTC)[reply]

Only to succumb to the documented "unconscious me always press Yes so I'll press Yes this time oh oops conscious me didn't mean to press Yes". Yeah, no. --Izno (talk) 18:33, 27 September 2020 (UTC)[reply]

@Izno: That has never happened to me. I think it is very common for a visitor to any web-site to make the first mistake, but extremely uncommon to make the second mistake. When I accidentally click "Log out," I mean to click something else, and I don't automatically click "Yes."—Anita5192 (talk) 19:34, 27 September 2020 (UTC)[reply]

I am glad you are so conscientious (see also anecdotal evidence). Most people are not. That said, there is discussion at phab:T217914 about the issue on mobile. --Izno (talk) 20:17, 27 September 2020 (UTC)[reply]

phab:T217914 has a discussion on this. A personal user script (see FlightTime's User:FlightTime/confirm-logout.js) can be used to add this for your own account if you want. — xaosflux^Talk 20:20, 27 September 2020 (UTC)[reply]

I edit Wikipedia from my laptop computer only, using Google Chrome. I noticed on the phab:T217914 page that someone wrote, "It's not a mobile-only problem; I've clicked log out accidentally on desktop using a mouse." However, I did not see a response to that post on the page. I loaded the JavaScript code at User:FlightTime/confirm-logout.js into my common.js page and bypassed my cache, but it doesn't seem to do anything.—Anita5192 (talk) 21:59, 28 September 2020 (UTC)[reply]

Agree in a lightweight way if possible. That is, not changing MediaWiki itself but building it into a skin, user preferences or Javascript. I have often hit the logout accidentally at the top of the screen, and many times in the middle of teaching Wikipedia editing in front of dozens of people. As the Phabricator discussion mentioned, it is currently the only "destructive" action in that bar of links, so having a safety net to warn about logging out would be consistent with the user interface. -- Fuzheado Talk 14:30, 29 September 2020 (UTC)[reply]

Agree, I've done it often enough to comment here, a few times a year. For me it occurs when I want to check my contributions for something and the uploaded page has a slight hesitation and then slides left as I click. The second-chance would save some of the time involved to log back in. Randy Kryn (talk) 14:38, 29 September 2020 (UTC)[reply]

I have also done it when I meant either to check my contributions or to click one of the Chrome icons.—Anita5192 (talk) 15:57, 29 September 2020 (UTC)[reply]

Agree and please do this. Otherwise it sucks. ❯❯❯ S A H A 11:00, 1 October 2020 (UTC)[reply]

Agree not a feature I'm personally looking for, but seems to be useful. However, if the logout button is ever removed as a stand-alone button and placed inside a menu,(like gmail for example) a further confirmation would be unnecessary. In other words, the actions necessary to logout should be two-clicks at most.

\langle

Forbes₇₂ Talk

\rangle

17:56, 1 October 2020 (UTC)[reply]

There might be a preference but it is likely that the default would remain as it is now to avoid the problem of a hasty exit from a shared computer. A typical scenario is that someone logs in at a university or similar public place. Later, they notice they are half an hour late, and click "log out" while running away. They never see the "are you sure?" and they stay logged in. Johnuniq (talk) 00:40, 2 October 2020 (UTC)[reply]

Agree I like Fuzheado's idea of having it in user preferences. Personally, it discourages 2FA a bit because it takes a while to log in (might have to find the phone too, which can be a challenge). Ovinus (talk) 07:44, 6 October 2020 (UTC)[reply]

Agree , a very nice proposal. Enjoyer of World^💬 02:53, 13 October 2020 (UTC)[reply]
Agree. A good proposal, seems like a no-brainer to me. Herbfur (talk) 17:02, 14 October 2020 (UTC)[reply]
Agree , I didn't see this thread when I posted the same thing farther down at WP:Village_pump_(proposals)#Double-click_option. On a mobile phone's small screen, "Contributions" and "Log out" are a millimeter apart and it's so frustrating to accidentally log out. ~~Roll-back should also require a double-click, rather than a gadget that sometimes works and sometimes not.~~ JGHowes ^talk 17:33, 16 October 2020 (UTC)[reply]
I'm agree with JGHowes about rollback. There should be a pop-up asking the rollbacker to confirm the rollback. I had made several accidental rollbacks in another wiki. Enjoyer of World^💬 23:40, 19 October 2020 (UTC)[reply]
@JGHowes: and @Enjoyer of World: there is an option in Special:Preferences#mw-prefsection-rendering titled Show a confirmation prompt when clicking on a rollback link - have you tried that? — xaosflux^Talk 00:55, 20 October 2020 (UTC)[reply]
Xaosflux Had not seen that "Show a confirmation prompt" Prefs option for Rollback — is that a recent enhancement? Indeed, it works! Thanks for that, no more inadvertent rollbacks, yeah! JGHowes ^talk 02:15, 20 October 2020 (UTC)[reply]
@JGHowes: came out last year (phab:T215020). — xaosflux^Talk 02:21, 20 October 2020 (UTC)[reply]
Same for me, it works! Thanks Xaosflux. Enjoyer of World^💬 04:52, 20 October 2020 (UTC)[reply]
Oh, please, please, please do this. See the above cited phab ticket for details, but this is particularly bad because not only do you accidentally log yourself out, you log yourself out of ALL devices current login sessions (which seems particularly stupid). And it especially sucks if you use 2FA and you happen not to have your token generator with you. I forget who told me this, but a workaround is to hide the logout link entirely in CSS so you can't click it by accident. See User:RoySmith/common.css for an example of how to do that (it's the #pt-logout rule). -- RoySmith (talk) 01:34, 20 October 2020 (UTC)[reply]
- ^ this is the truth. We should do more to encourage 2FA, not punish it. - Bri.public (talk) 17:50, 5 November 2020 (UTC)[reply]

I think the m:Community Wishlist Survey will open soon, and I encourage you all to propose this as a wish. The next wishlist will be a little different, but from our perspective, that mostly just means that they aren't sure exactly how many wishes they'll get done, so they aren't committing to a specific number in advance. Maybe five will get done, or maybe 15. Whatamidoing (WMF) (talk) 20:08, 26 October 2020 (UTC)[reply]

Just a quick comment that I tried the FlightTime script (as well as the one from User:Guywan/Scripts/ConfirmLogout that it is based on—just changes colors) thanks to Xaosflux's recommendation above, and they both work wonders. I highly recommend people try using either one of these in the meantime. Just pick which one based on a red/pink or a blue/gray color scheme. -2pou (talk) 22:15, 4 November 2020 (UTC)[reply]

Agree ... I have accidentally logged out so many times. Aza24 (talk) 02:01, 10 November 2020 (UTC)[reply]

Proposals for ending the Infobox wars

There is a clear consensus against implementing either proposal. 207.161.86.162 (talk) 03:08, 29 October 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The infobox wars have now been raging for longer than the duration of World War II. Despite 2 ArbCom cases and ArbCom's request for community discussions, nothing's really changed since the opening salvos were fired back in 2013. Personally, I'm tired of seeing the same people show up en masse to talk page after talk page to debate over and over and over again whether or not an infobox should be in an article, especially since all such discussions quickly degenerate into back and forth name-calling. To take just one example, Mary Shelley has had 4 infobox proposals in the past 3 years. With this in mind, here are some ideas for ending (or at least reducing) the infobox wars. Feel free to add more ideas.

Proposal A - No one may propose adding or removing an infobox to an article if there has already been such a discussion within the past 2 years.
Proposal B - No one may propose adding or removing an infobox to an article unless they are one of the top 10 contributors to that article (as judged by the Xtools authorship tool).

-- Kaldari (talk) 00:00, 29 September 2020 (UTC)[reply]

User:RexxS/Infobox_factors is good reading. --Izno (talk) 00:09, 29 September 2020 (UTC)[reply]
Radical idea and one I know will be met with contention, but another idea would be an RFC to discuss whether all articles where it is feasible that an infobox should be present, though editors are not required to use all fields present even if there is data to fill those fields (knowing for example the concerns those at Kubrick have of that). 95% of the issue of infoboxes are people coming here expecting to find "structured" data that 99% of all other articles have. I know the past discussions in this, including ArbCom have been to leave this to a page-by-page consensus, but that is clearly not working, and things have changed since (the introduction of Wikidata, Google/Bing's presentation of search results, etc.). Again, this would be an RFC to discuss this possibility, which I know certain editors will refuse adamantly, but this is a consensus thing. --Masem (t) 00:22, 29 September 2020 (UTC)[reply]
- Is there a WP:RS for any of those numbers. Having been through over 110,000 of the 'pedia's articles in my own editing I can guarantee that the number that have infoboxes is nowhere near 99%. It is also interesting how everyone talks about what readers expect to see without ever having performed a scientific survey to validate their statements. MarnetteD Talk 00:35, 29 September 2020 (UTC)[reply]
  - I should add there are types of articles that we have no canned infobox for that we can make the topic conform into, and so in such cases, this would be reasonable where an infobox could be omitted. These are usually for more abstract terms that lack any type of hierarchical data. (This is what I meant by "where it is feasible".
    And as a rough test, I used Category:American women by occupation with Petscan, adding in a number of known infoboxes common for this group. Of the 9790 entries, I got to about 3000 pages without the most common infoboxes, and spotchecking those (to find any other infoboxes) the ones that were missing it were all observed to be stub, not well developed articles. Nothing of the type like Kubrick or other pages that have been fully developed and where consensus presently has been to leave an infobox out. This is far from scientific, but I would definitely say that for well-developed (non-stub, non-start articles), the number that lack infoboxes is far fewer then 5% based on this very unscientific study. --Masem (t) 01:32, 29 September 2020 (UTC)[reply]
- I think that is about right. I am not sure the restrictions above are the path forward. More we need a discussion on making them standard and if so in what capacity. PackMecEng (talk) 00:37, 29 September 2020 (UTC)[reply]
Both A and B are awful proposals and completely biased in their presentation. --Gonnym (talk) 00:56, 29 September 2020 (UTC)[reply]
- You're going to have to explain what you could possibly mean. Both proposals look to be completely neutral - they take absolutely no inherent side in disputes other than stability - and while you can certainly disagree with them on any number of grounds, e.g. proposal B is unacceptably inimical to WP:OWN (my opinion), your comment neither adds to collective understanding nor actually advocates for your position in a meaningful way. Van Isaac_WS^cont 01:11, 29 September 2020 (UTC)[reply]
If it came up at an RfC I would support proposal A. For no other reason it streamlines what has become a sort of drag on the community. -- GreenC 01:54, 29 September 2020 (UTC)[reply]

To add.. Option A is recommended, but it does not "solve" this problem because like water erosion there is no solution rather you redirect, slow down and so on. "A" is a way to reduce the disruption, which is the main issue, the particulars about infoboxes is almost a side issue to the larger problem of disruption. -- GreenC 05:35, 30 September 2020 (UTC)[reply]

I have never encountered a contentious infobox discussion. If the problem is a cabal of editors going from page to page starting infobox discussions, we should just topic ban those editors. If that is not possible, we should develop project-wide guidance similar to Masem's suggestion. — Wug·a·po·des 01:57, 29 September 2020 (UTC)[reply]
Have a quick look at Talk:Frank Sinatra. The argument goes back forever and has been re-launched zillions of times. — GhostInTheMachine ^{talk to me} 08:38, 29 September 2020 (UTC)[reply]

Lucky you! One of the editors in Talk:Frank Sinatra opposing infobox change also deep-sixed my infobox request on Talk:Michael Tilson Thomas — Germsteel ^(talk) 09:58, 23 October 2020 (UTC)[reply]
Proposal B codifies article ownership into policy and should be a nonstarter. – Teratix ₵ 06:50, 29 September 2020 (UTC)[reply]
I've added {{Infobox war}} to this discussion since it seems apropos. Please feel free to fill in more parameters. E Eng 09:39, 29 September 2020 (UTC)[reply]
Mleh- I am indifferent to infoboxes, except when they're used to try and make substub non-articles look deceptively like articles. I oppose both options: the first one strikes me as "Thou shalt not talk. Thou shalt not think" and the second one amounts to assigning ownership of articles to prominent editors. Reyk _YO! 10:25, 29 September 2020 (UTC)[reply]
Argh, is this still going on? Good grief. Personally I have never encountered a contentious infobox discussion in my own editing, but maybe I have just been lucky. I may be wrong, but my impression right now is that these "infobox wars" are limited to a small number of highly opinionated editors arguing over and over between themselves on a relatively small number of articles. If that is the case, then a better solution would be to issue a bunch of community topic bans to them for 2-3 years and then have some peace. If the problem goes deeper, then something like what Masem suggest makes sense to me. An RfC proposal to formalize the existence and structure of infoboxes along the lines that Masem mentioned seems likely to me to gain broad consensus. On the other hand, proposals A and B suggested above seem both extreme an unnecessary. Nsk92 (talk) 10:45, 29 September 2020 (UTC)[reply]
- This is pretty much my read of the situation: there's probably a few dozen, very senior editors that have been very vocal on not wanting infoboxes on certain articles for multiple reasons. Most of us experienced editors know not to touch that. Newer editors - who see nearly every other developed page with infoboxes and have no knowledge of the infobox ARBCOM cases or the like - add infoboxes or ask valid questions of why no infoboxes, and that will never be a cycle that we can get out of beause there will always be new editors. So either we're going to have these going on forever (and as others point out, the two suggested RFC questions don't solve this), or we actually readdress the consensus around infoboxes, because if we're catering to a few dozen editors when hundreds more want it a different way (if that is what consensus is), then there's a problem. But best I can recall we have not had an RFC on how mandatory or optional infoboxes are for at least 5 years so I don't know that read: I know they're expected, but that's different. --Masem (t) 14:09, 29 September 2020 (UTC)[reply]
I would reject both. B has problems, but it's also a strength of Wikipedia, and this kind of 'ownership' seems incompatible with the purpose. A does not exactly fix the issue -- the Sinatra RfC was brewing for 2 years. Masem's proposal probably doesn't help either - infoboxes are, indeed, not required on all articles. Particularly it'd look silly on short ones, and it's likely to annoy some editors who focus on their writing and don't like IBs. Further, their values are likely to get bloated so there will still be arguments on what labels to keep/remove. It's a difficult problem to solve from a central level, if pushing down a single rule, seemingly. I think what is more likely to be effective is prescribing actual guidelines which will help determine whether an infobox should be on an article (an expansion of MOS:INFOBOXUSE).
One route to a solution is just making the infoboxes more palatable. Maybe modifications to infoboxes will help, too. People are opposed to too many fields, so maybe trimmed down 'wrappers' of contentious infoboxes with only support for some fields will be a sustainable middleground. Kaldari maybe WMF design input could be helpful? mw:Streamlined Infoboxes seems interesting. ProcrastinatingReader (talk) 18:14, 1 October 2020 (UTC)[reply]
I would reject both, B just seems both against our ethos to an unacceptable level but also a potential source of its own aggravations and gaming. Articles can change a simply staggering amount in 2 years, so don't think that's wise. But perhaps some process to enable more targeted 1 year moratoria at specific troublesome pages. Nosebagbear (talk) 13:28, 29 September 2020 (UTC)[reply]
The moratoria can already be applied to specific troublesome pages under the existing Infobox DS. I don’t think it’s working. We need a broad solution to the issue. And the issue is targeting behaviour and conduct on individual pages doesn’t work when the underlying issue is a fundamental content dispute. The issue can only be resolved by addressing the content issue.
In usual cases, a clear MOS guideline etc would be sufficient clarification to put the matter to rest if it’s just individuals acting out (or just enact topic bans), but since the community is unable to agree on a standard I don’t think the conduct (which is a symptom) is the root of the issue here. Thus sanctions and topic bans likely not the appropriate way to address legitimate content concerns, however expressed. Banning the vocal opponents may dim the issue, but doesn’t seem to be the correct way to proceed. If their concerns were without merit, the community would have no objection passing an update to guidelines to say so. ProcrastinatingReader (talk) 14:18, 29 September 2020 (UTC)[reply]
Can someone link to one of these specific contentious infobox discussions, preferably a recent one? Like many other people here have commented, I've never seen one ever, contentious or otherwise, other than meta-discussions like this one about how bad the problem is and what to do about it. Ivanvector (^Talk/_Edits) 14:20, 29 September 2020 (UTC)[reply]
- Check the Cary Grant talk page, aye, where many a dusty hill has been held under heavy fire (someone should write an epic poem). Randy Kryn (talk) 14:41, 29 September 2020 (UTC)[reply]
- The Arbcom case over this is here Wikipedia:Arbitration/Requests/Case/Civility in infobox discussions. Other pages I know that have been a hot bed have included Talk:Stanley Kubrick and Talk:Frank Sinatra but you likely need to look through archives of those to find the discussions. --Masem (t) 14:53, 29 September 2020 (UTC)[reply]

An editor deep-sixed my infobox request on Talk:Michael Tilson Thomas — Germsteel (talk) 10:27, 23 October 2020 (UTC)[reply]

Two editors heavily involved in this dispute (Cassianto and SchroCat)—they're the primary participants in all the discussions cited here so far—have recently left the project. Maybe we should wait to see if that changes things before considering a fresh round of sanctions? – Joe (talk) 15:06, 29 September 2020 (UTC)[reply]
It's my sense that this imbroglio is largely in some biography article areas, so maybe start whatever proposed new "rule" there is with biographies, and see how that goes. (In that biography realm, it is something to observe, because that debate (or war) in effect regularly centers around not whether there will be something in a box in the top right corner, but whether it will be limited to a picture-box, or contain more). -- Alanscottwalker (talk) 16:48, 29 September 2020 (UTC)[reply]
- There is a idea I've had for some specific types of bios - mostly creative people with a widely varied career - that most of the typical {{infobox person}} or its variants just don't work well and thus can be argued that an infobox doesn't help that much or if used will draw people to add the "missing" information that was purposely omitted because it can't easily be summarized in an infobox (Kubrick's fits this idea well). But at the same time, there is basic structured data like birth date + date, death place + date, broad profession list, and notable spouses and the like that can still be documented in an infobox that is the type of information that I see being asked for by the new editors that are the ones asking for infoboxes. This would need to be a discussion under my suggested RFC about the nature of infoboxes altogether. --Masem (t) 17:29, 29 September 2020 (UTC)[reply]
Oppose B for WP:OWN per User:Teratix and others. RudolfRed (talk) 17:32, 29 September 2020 (UTC)[reply]
Oppose both. Just add an infobox to every article (preferably from Wikidata), job done. Thanks. Mike Peel (talk) 17:47, 29 September 2020 (UTC)[reply]

Seeing as this seems to be cropping up as a bone of contention in biographies, where I'm sure much of the heat comes from the question of the choice of infobox, I would suggest that at the very least the generic {{Infobox person}} should be a default whenever you have an article about a non-fictional person. I edit in too many esoteric parts of Wikipedia to be able to say that every article has an appropriate infobox available, e.g. Perkins Brailler. Van Isaac_WS^cont 07:38, 30 September 2020 (UTC)[reply]

If the Perkins Brailer absolutely needed an infobox then I think {{Infobox keyboard}} could be made to fit: since it only has four uses already, I'm sure it could be adapted somewhat. But you're right, adding an infobox to every article does pose a challenge when it's not immediately obvious what type of thing a thing is. I would suggest that some things (persons, buildings, countries, songs, books, animals) can't really get away without having them but applying to every article ever, especially newer ones, would be too much. --Paul Carpenter (talk) 13:34, 30 September 2020 (UTC)[reply]

Vanisaac, you could also use Template:Infobox product for that article. WhatamIdoing (talk) 03:00, 14 October 2020 (UTC)[reply]

I don't see why option B is perceived to go against WP:OWN. The question of whether to have an infobox in a particular article has little relevance to the function and encyclopedicity of that article, and Wikipedia's core policies have no bearing either. It's largely a stylistic choice, and for stylistic choices it is only common sense – in infoboxes or elsewhere – to accord greater weight to the preferences of the people who have put in the most work. A somewhat similar principle operates in MOS:RETAIN, which guides the choice of British or American spelling. – Uanfala (talk) 14:54, 30 September 2020 (UTC)[reply]

WP:RETAIN is absolutely nothing like option B above. It simply identifies a default consensus for an English variant based on the history of a page. It privileges absolutely no editors, and that default consensus is only used as a stability policy in the absence of an established consensus. Option B, on the other hand, privileges certain editors, allowing their opinion to veto consensus. It is not a stability policy, as those privileged editors can impose a decision no matter how entrenched another choice might have been. Option B is the epitome of WP:OWN, where certain editors are elevated as the masters of a page in regard to infoboxes, no matter the consensus or stability. Van Isaac_WS^cont 21:55, 30 September 2020 (UTC)[reply]

I agree with Vanisaac. Proposal B is a pure form of WP:OWN. Completely unacceptable and goes against the fundamental editing principles of Wikipedia. The proposal offers a cure that is a hundred times worse that the desease. Not only would it create a group of privileged editors for each article with veto powers over certain decisions, it would also encourage gaming and trickery in running the edit count in order the become one of those top 10 editors. Really, it would have been hard to concieve of a worse idea than Proposal B. Nsk92 (talk) 22:31, 30 September 2020 (UTC)[reply]

Oppose both, especially oppose B for all the reasons above and zero good reasons in favor. Natureium (talk) 01:50, 2 October 2020 (UTC)[reply]
Oppose both If a specific infobox, or lack thereof, proves to be a constant issue, a moratorium on bringing it up on the talk page can be agreed to on that talk page. This should really be decided by local consensus. ~ HAL333([9]) 03:50, 5 October 2020 (UTC)[reply]
Oppose Both "B" per WP:OWN. For "A" 2 years is too long. PaleAqua (talk) 18:54, 5 October 2020 (UTC)[reply]
"Two years" is simpler than what we'd probably want, which is an escalating length. "Infobox change, discussion 2" should be at least a few months after the first; if it fails, then "Infobox change, discussion 3" should probably be at least six months (maybe a year) later; "Infobox change, attempt 4" should probably be even later than that. WhatamIdoing (talk) 03:02, 14 October 2020 (UTC)[reply]

No real need as very very few articles have this problem. Its a small group of editors involved and getting smaller all the time.--Moxy 🍁 01:50, 20 October 2020 (UTC)[reply]

Oppose both. I put an infobox requested on Talk:Michael Tilson Thomas and an editor took out the request. As it stands now most people would not even know there had been a request. That editor may not agree with the request but they should not erase it. They should see if somebody provides one or doesn't. And its not like they have contributed anything else to that page. Cheers. Germsteel (talk) 09:30, 23 October 2020 (UTC)[reply]
Oppose both. (A) A request to "back off and calm down" for a "reasonable" interval is reasonable, but an outright ban for a fixed time is excessive. (B) is WP:OWN-ish and limits the debate to those who have already been too involved. It also is a block on new editors, wise uninvolved third-parties or anybody who is "just passing" but has a valid view. — GhostInTheMachine ^{talk to me} 10:23, 23 October 2020 (UTC)[reply]

Oppose both. What infobox wars? Did they even exist? If yes I believe they ended long ago, as a wise voice said back in 2018. Some - very few! - editors don't like infoboxes, and I won't stress them. It's so easy. Do you remember WP:ARBINFOBOX? The infobox on the side is taken from there, 2013. The case was requested because of troubles about the introduction of {{infobox opera}}, vs. operatic side navboxes. Successful, finally. - Try to treat infoboxes like other article feature (images, tables), and observe WP:BRD, - that's all it takes to end the rumor that these wars exist. --Gerda Arendt (talk) 10:29, 23 October 2020 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The above discussion should be reopened and closed by an editor with an account. It is a bad idea for an IP, no matter how storied, to be closing discussions. BD2412 T 23:56, 5 November 2020 (UTC)[reply]

If you wish to challenge the result of the closure, please see WP:CLOSECHALLENGE. 207.161.86.162 (talk) 07:35, 12 November 2020 (UTC)[reply]

Discussion notice: Infobox officeholder successor=

There is an RfC about whether the successor= parameter of {{Infobox officeholder}} should be added immediately after the article's subject loses re-election, or wait until the successor takes office. Interested parties may participate at: Template talk:Infobox officeholder#RfC: Interim use of successor=. ―Mandruss☎ 14:05, 13 November 2020 (UTC)[reply]

[1] "Wikistats - Statistics For Wikimedia Projects". Wikimedia Foundation. Retrieved 21 September 2020.

[2] Jeff South (2018-08-07). "More than 1,000 U.S. news sites are still unavailable in Europe, two months after GDPR took effect". Websites had two years to get ready for the GDPR. But rather than comply, about a third of the 100 largest U.S. newspapers have instead chosen to block European visitors to their sites.

1

[1]

[1]

Search

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

왼쪽 사이드바 업데이트 후속 조치

로컬 언어 요구 사항

2020년 9월 19-26일 "Wiki loves SDGs"를 위한 중앙 공지 배너 토론

A 클래스 주제 표시

기사 Infobox에 IMDb & Roat 토마토 등급 추가(가능한 경우 어디서든)

조사: infobox의 IMDb

조사: 비평가들은 infobox의 집계를 검토한다.

조사: 썩은 토마토 vs.Infobox용 메타크리트어

총론

제안:깨진 {{DISPLAYTITLE}}을(를) 추가하기 전에 편집자에게 물러날 수 있는 기회 제공

MoS 고정자 길드

편집, 기록, 삭제 및 새 섹션 링크에 외부 링크 대신 내부 링크 사용

위키백과에 탭 및 탭 확장 추가

원하는 대로 사용자 권한 설정 및 해제

해당 문서에 사용된 참조를 제거하는 RfCs에 대한 기사 토크 페이지 알림 요구

RfC: Infoboxes에서의 알렉사 랭킹

조사(인포박스 내 알렉사 순위)

토론(알렉사 랭킹(Infoboxes))

연간 방문자 매개 변수?

위키프로젝트 법의학

봉사상

위키백과 - 신문이 아님 - 2020년 나가노-카라바흐 분쟁 기사

대화 페이지 색인 삭제

우리 대화 페이지를 색인화해야 할까?

토론(대화 페이지 색인화)

두 번 클릭 옵션

홈 페이지에 로그인 정보가 필요함

공공 기물 파손 혐의와 반달트레이스봇을 평가하는 것?

전기의 중복 템플릿

중복 소스 필요 템플릿

요청 제출됨

2020년 위키백과의 아시아 달을 위한 CentralNotice 배너

카테고리에 대화 페이지 대신 실제 기사 나열:물품_by_품질

외부 링크에 IMDb, 썩은 토마토 및 메타크리트어 추가(가능한 경우)

조사: IMDb, 썩은 토마토 및 외부 링크의 메타크리트어

Things I am finding alongside IMDB and Rotten Tomatoes

Template:cite web: New keyword(s) for url-access / New parameter(s)

Library Card access

Geographical Restrictions (inc GDPR)

Listings of Articles by Both Quality and Importance with Quick Links

A new category :-)

Proposal for new WikiProject to conduct a sweep of all old articles

Simplify making templates

UBX pseudo-namespace

Log out second chance

Proposals for ending the Infobox wars

Discussion notice: Infobox officeholder successor=