위키백과:마을 펌프(제안)/아카이브 145
Wikipedia:이 페이지에는 빌리지 펌프(제안)에서 보관된 토론이 수록되어 있다.이 페이지의 내용을 편집하지 마십시오.이러한 토론 중 하나를 다시 시작하려면 새 스레드를 시작하거나 해당 주제와 관련된 대화 페이지를 사용하십시오.
< 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
RfC: 아티클 설명 채우기
이 RFC를 닫는 중.첫 번째 질문에 대한 합의는 #5이다. - 빈칸으로 시작하여 수동으로 또는 봇(일반적인 봇 절차)으로 단어를 채울 수 있도록 함으로써 마법의 단어를 채운다.두 번째 질문에 대한 공감대는 #2이다. 마법의 단어가 존재하지 않는 곳에 대한 설명은 표시하지 않는다.Fish+Karate 13:00, 2018년 2월 6일 (UTC)[ |
- 다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.
2017년 3월 말 - 4월 초 위키백과:마을 펌프(제안)/아카이브 138#Rfc: en-WP의 모바일 뷰에서 위키다타에서 가져온 설명을 삭제하는 작업은 WMF가 "당분간 enwiki에 대해 위키다타 설명 기능을 해제하기로 결정했다"고 선언하면서 끝났다.
2017년 9월, 오해나 의사소통을 통해 이 기능은 단지 하나의 사건 일부에 대해서만 꺼진 채 엔위키에서 다른 것(일부 앱에서, 검색 결과, ...)으로 남아 있는 것으로 밝혀졌다. 이 설명의 효과는 이번 주 2시간 동안 영국의 헨리 8세를 검색하거나 끝까지 본 모든 사람들이라는 것이다.그 앱들 또는 "관련 페이지" 또는 그와 같은 일부에 "오비 히틀러"[2]라는 설명이 붙었다(얼마나 많은 사람들이 실제로 이것을 보았는지는 모르지만, 이 좋은 기사는 하루에 약 13,000번 시청되고 있으며 그러한 공공 기물 파손으로부터 보호하기 위해 여기서 무한히 반보호된다).
이에 대한 논의는 위키백과에서 시작되었다.마을 펌프(정책)/아카이브 137#위키다타 설명은 여전히 엔위키에 사용되며 주로 위키백과 토크에서 계속되었다.위키다타/2017년 국정현황 (아카이브 5부터 아카이브 12까지!)에서 토론을 찾을 수 있다.결국 WMF는 엔위키에 대한 위키다타 서술의 활용을 모든 경우에 대체하는 2018년 2월말에 모든 일이 잘 진행되면 실행할 새로운 마술어(결정될 이름)를 만들기로 합의했다.
우리는 이제 두 가지를 결정해야 한다.프람 (대화) 09:58, 2017년 12월 8일 (UTC)[
마법의 단어를 어떻게 지역적 설명으로 채울 것인가?
- 처음에 wikidata 설명을 bot에 따라 복사하십시오.
- 봇과 함께 기사의 첫 번째 문장(사용자가 설명한 방법:데이비드 엡스타인 및 사용자:위키백과의 앨시:위키다타/2017년 국정현황/아카이브 5#위키피디아 설명 대 위키다타 설명)
- 봇과 함께 infobox의 정보(예: 국가 + 직업 조합: "미국 가수", "네팔리 정치인" 등)를 사용한다.
- 빈칸으로 시작하여 수동으로 작성(모든 기사 또는 BLP 전용)
- 수동으로 또는 봇으로 채울 수 있는 빈칸으로 시작(일반적인 절차에 따라 봇 승인 후 봇 채우기)
- 기타
초기 모집단 논의
- #5 – 한 번에 결정할 필요가 없는 기준에 따라 크고 작은 기사 집합에 대한 봇 조작 허용, 항상 수동 오버라이드. --프랜시스 숄켄(토크) 10:28, 2017년 12월 8일(UTC)[
- #5는 아래 추론을 따르는 나의 선호다.
- Wikidata에서 복사한 옵션 1은 위키피디아에 정말 나쁜 설명들을 많이 넣을 것이고, 이것은 누군가가 그것들을 고칠 때까지 남아있을 것이다.나의 초기 대략적인 추정치는 좋은 위키디타 서술보다 나쁜/없다는 것이다.나는 누군가가 그것이 순이익이 될 것이라는 것을 나타내는 확실한 데이터를 내놓지 않는 한 그리고 그 옵션이 나올 때까지 이 옵션에 강력히 반대한다.
- 옵션 2, 첫 번째 문장이나 단락에서 유용한 설명을 추출하는 것은 언뜻 보기엔 좋은 생각인 것 같지만, 어떻게 할 것인가?이 옵션을 홍보하는 사람이 있다면 그것이 얼마나 효과적이고, 얼마나 오래 걸릴 것이며, 평균적으로 옵션 1보다 더 나은 설명을 생산할 수 있을지에 대한 좋은 아이디어를 가지고 있는가?이 옵션은 합리적으로 실행 가능하고 해보다 더 많은 이익을 줄 것이라는 증거가 제공될 때까지 적절하지 않은 것으로 간주되어야 한다.
- 옵션 3은 infobox에서 복사하는 것으로, 실제로 유용한 짧은 설명을 가진 infobox가 있는 일부 기사 또는 유용한 짧은 설명으로 조립될 수 있는 구성요소에 대해 작동할 수 있다.이것은 유용한 기사들의 부분집합에 효과가 있을 수 있지만, 얼마나 많은지는 아직 알려져 있지 않다.나는 절반도 채 안 되기 때문에 좋은 1차 선택지가 아니라고 추측할 수 있다.
- 빈칸으로 시작해서 수동으로 작성하는 옵션 4는 아마도 많은 비율의 기사를 위해 할 수 있는 유일한 방법일 것이다, 내 추측으로는 절반의 순서로 되어 있다.그것은 실행되어야 할 것이고, 아마도 사실상의 채무 불이행일 것이다.그것은 쉽고, 빠르고, 해를 끼치지 않을 것이다.그것은 첫 단계인 옵션 5와 완전히 호환된다.
- 옵션 5는 옵션 4로 시작하고 유용하다고 보여질 수 있는 임시 로컬 솔루션을 적용하고 있다.어떠한 위해도 국소화 되고, 위키다타 묘사는 적절할 때 사용할 수 있으며, 리드로부터의 추출물은 적절할 때 사용할 수 있으며, 인포박스의 매쉬업(mashup)은 적절할 때 사용할 수 있으며, 기사가 무엇에 관한 것인지 실제로 알고 있는 사람들의 수동 입력은 적절할 때 사용할 수 있다.나는 이것보다 더 좋고, 단순하고, 더 실용적인 선택은 없다고 생각하며, 프로젝트들이 그들의 기사를 다루는 방법을 고려해야 한다고 제안한다.WPSCUBA는 이미 기사의 절반 이상을 사용할 수 있는 짧은 설명을 수동으로 입력했는데, 나는 이를 실험으로 제공했다.그것은 꽤 시간이 걸리지만, 연습하면 더 쉬워진다.일부 편집자들은 이것이 재미있는 프로젝트라고 생각할 수도 있고, 다른 편집자들은 그렇지 않을 수도 있고, 필자는 BRD가 단순한 내용 불일치로서 관리해야 한다고 제안하는 충돌이 불가피할 것이며, 이것은 대화 페이지에서 논의되고 합의로 마무리되어야 한다.사실상, 옵션 5는 위키 방법이다.간단하고 유연하며 최소한의 피해로 최상의 결과를 낼 가능성이 높다.· ···피터(사우스우드) : 2017년 12월 8일(UTC) 11시 26분[
- (여기서 편집 충돌이 있었고, 모든 코멘트를 그룹화하기로 선택했다 ···· 피터 (사우스우드) : 11:26, 2017년 12월 8일 (UTC)[
- #5. Wikidata 설명이 적합한지 아닌지는 많은 기사 그룹에 걸쳐 매우 다르다.그룹별, 때로는 소그룹별로 (그리고 아마도 봇인) 결정되어야 하며, 그 때문에 빈칸 설명부터 시작해야 한다.--Ymblanter (대화) 11:23, 2017년 12월 8일 (UTC)[
- 어디에서도 사용하지 않고 상황에 따라 재정의용으로만 사용하십시오.—DJ (대화 • 기여) 2017년 12월 8일 (UTC) 12:09[
- 더DJ, 명확하게 하자면, 이것은 옵션 6: 당신이 여기서 제안하는 다른 것인가? 즉, 위키다타 짧은 설명이 적합하지 않은 기사에만 마법 단어를 추가하고, 누군가 문제를 발견하고 마법 단어를 추가할 때까지 모든 경우에 위키다타 설명을 기본값으로 사용하라. 그 후에 간단한 설명은 마법 단어에서 취해진다.만약 그렇다면, 나중에 어떤 이유로든 위키다타 서술로 되돌리는 것에 대한 당신의 의견은 어떠한가?· ···피터(사우스우드):(talk) 14:53, 2017년 12월 8일 (UTC)[
- @Pbsouthwood:맞아요.나는 나중에 되돌리는 것에 대해 의견이 없다.—DJ (대화 • 기여) 13:42, 2017년 12월 11일 (UTC)[
- 더DJ, 명확하게 하자면, 이것은 옵션 6: 당신이 여기서 제안하는 다른 것인가? 즉, 위키다타 짧은 설명이 적합하지 않은 기사에만 마법 단어를 추가하고, 누군가 문제를 발견하고 마법 단어를 추가할 때까지 모든 경우에 위키다타 설명을 기본값으로 사용하라. 그 후에 간단한 설명은 마법 단어에서 취해진다.만약 그렇다면, 나중에 어떤 이유로든 위키다타 서술로 되돌리는 것에 대한 당신의 의견은 어떠한가?· ···피터(사우스우드):(talk) 14:53, 2017년 12월 8일 (UTC)[
- #5. 그것은 모든 문제를 다루지는 않지만, 선택권을 고려할 때 내 견해에 가장 근접한다.WT에서 내 의견을 참조하십시오.Wikidata/2017년 국정/아카이브 12 및
WT:Wikidata/2017년WT에 보관된상태:위키다타/2017년 국정현안/아카이브 13. - 당크 (대화를 밀어) 14:06, 2017년 12월 8일 (UTC)[- 피터는 나에게 해명을 요구했다.사람들이 구체적인 질문이 있거나, 이전 게시물 요약을 원하면 최선을 다해 답변하겠다. - 당크 (밀어서 얘기) 2017년 12월 8일 (UTC) 15:30, 8 (
- 누가 이것을 마무리 하든지 간에: 여기서 시작된 논의는 위키다타 사용 링크의 새로운 RfC에서 계속 진행중인 것으로 보인다. - Dank (Push to Talk) 15:18, 2018년 1월 16일 (UTC)[
- #5 그러나 너무 오래 기다리지 말고 가능한 한 채워 넣는다.프람 (토크) 2017년 12월 8일 (UTC) 14:14 [
- #6 - 사용하지 마십시오.애초에 이 마법의 단어를 갖는 것에 대한 합의는 없었다 - 그것이 이 RfC에서 요구되었어야 하는 질문이다(여기서 토론 참조).나는 개인적으로 그것이 좋지 않은 생각이고 개발자 시간의 낭비라고 생각한다.대신 위키다타에 대한 묘사를 개선하는 데 주력하는 것이 좋다.마이크 필 (토크) 15:27, 2017년 12월 8일 (UTC)[
- #6 — Wikidata 설명을 모니터링하고 업데이트하는 솔루션 찾기 — 위키백과(ns)에 충분한 설명이 있다면 Wikidata에 있어야 한다.위키피디아에서 공공 기물 파손이 차단되면 위키다타에서 동시에 되돌려야 한다.Wikidata는 인터위키 링크의 허브로, 외부 지식 기반 검색 엔진에 의해 수집되는 설명과 구조화된 데이터 모두를 위한 저장 사이트다(생각해 보면 Siri, 알렉사, 구글의 지식 그래프).인터위키 목적을 위해, 우리는 위키다타에서의 짧은 설명이 정확하고, 다른 언어 위키피디아들이 엔위키와 연동될 때 그것이 용이하도록 해야 한다.외부 수확을 위해서는 공공 기물 파손이 전파되는 것을 막아야 한다.위키다타에서의 반달리즘과 소싱에 관한 문제는 현실이지만, 해결책은 위키피디아인들과 우리의 반반달리즘 봇들이 관련 위키다타 자료를 쉽게 감시하고 편집할 수 있도록 하는 것이다.가능한 해결책은 다음과 같다: (a) 트래픽이 많거나 논쟁이 많은 페이지에 대한 설명 변경에 대한 보류 중인 변경과 같은 기능 구현, (b) 위키백과 감시 목록, VisualEditor 내부 및 위키백과 편집자의 선호 옵션으로 눈에 띄게 보이는 짧은 설명 변경, (c) Wikiped 개발 및 구현일종의 클릭온 이 펜슬 도구를 사용하여 위키다타 짧은 설명을 편집함.--카르윌 (대화) 15:46, 2017년 12월 8일 (UTC)[
- 그러한 해결책이 구현된 후에는 이러한 설명을 하지 않기로 결정한 이전 RfC의 합의를 뒤집을 수 있는 RfC를 자유롭게 요청할 수 있다.본 RfC는 Wikidata가 하는 일에 간섭하지 않고 enwiki(VE, 모바일, ...로 설명)에서 원하는 것을 제공하는 솔루션을 얻기 위한 논의다.프람 (토크) 16:01, 2017년 12월 8일 (UTC)[
- Carwil, 위키피디아의 반달에 의한 접근을 위키피디아에게 어떻게 통제할 것을 제안하는가?위키백과 관리자가 위키다타 항목을 보호하고 위키다타 사용자를 차단할 수 있어야 한다는 말씀이십니까?
- 4를 강력히 반대하고 5를 강력히 반대하십시오. 짧은 설명을 대량으로 설명하는 모든 솔루션은 거부합시다. 이러한 솔루션은 모바일 브라우징과 VisualEditor의 기능적 부분이다.학생들을 위키백과 편집에 끌어들인 편집자와 교사로서, 후자의 기능성은 결정적인 시간 절약이다.Wikipedia는 모바일 기기에 의해 점점 더 많이 접속되고 있으며 짧은 설명으로 인해 원하는 페이지가 아닌 페이지를 클릭하는 것을 막을 수 있다.--Carwil (대화) 15:46, 2017년 12월 8일 (UTC)[
- 위키다타 서술의 전반적인 유용성을 분석하여 나쁜 서술보다 좋은 서술이 많다는 것을 발견했거나, 나쁜 서술이 모두 좋은 것으로 바뀔 수 있도록 찾아내는 방법을 찾아냈는가?만약 그렇다면, 여러분의 방법과 결과를 가리켜라. 그것들은 매우 가치 있을 것이기 때문이다.나쁜 서술에 의한 해악과 좋은 서술에 의한 선의 비교를 나타내기 위해 어떤 방법을 사용하셨습니까?· ···피터 (사우스우드) : 2017년 12월 8일 16:14, (UTC)[
- 응, 여기 샘플을 분석해 봤어.나는 30개 중 13개가 적절한 기술(그 중 7개는 개선될 수 있지만), 13개는 전혀 기술되지 않았고, 1개는 기사 제목이 잘못 기술되었다(파달리즘이 아니다), 2개는 기사 제목과 중복되었다(즉, 빈칸으로 재정의되어야 한다), 1개는 위키백과 기사 내용이 동일하지 않고 위키다타 실체가 동일한 경우를 나타내고 있다는 것을 발견했다.같은 인상착의를 공유하면 안 돼중복된 서술은 해를 끼치지 않을 것이다.볼리비아의 행정 구역에 볼리비아의 행정 구역이라는 부호를 붙이는 것은 가벼운 혼란을 야기할 것이다.설명에 의해 제공되는 가독성은 피해보다 훨씬 크다. (유일한 강력한 해악은 공공 기물 파손에 기인하는데, 이것은 프로젝트 간의 설명을 요구하지 않는 공공 기물 파괴 도구를 개선함으로써 해결되어야 한다.)--카르윌 (대화) 2017년 12월 8일 (UTC) 16:47, 2017년 12월 8일 (
- 옵션 4와 5는 아무것도 비우는 것이 아니라, 그들이 기술하는 기사에 텍스트 내용인 짧은 설명을 넣어야 하며, 기사의 내용을 실제로 알고 있는 사람들에 의해 적절히(또는 최소한 더 잘) 유지되어야 한다.Wikidata는 그들의 사용 조건이 허락한다면, 그리고 그것들이 실제로 Wikidata의 목적에 더 적합하다면 그것들을 사용할 수 있는데, 이것은 현재 결코 명확하지 않다.····피터(사우스우드):(talk) 16:14, 2017년 12월 8일 (UTC)[
- 옵션 4와 5는 어디에서나 빈칸으로 시작한다.전체 제안은 우리가 위키백과 기사를 설명하는 데이터 세트를 독립적으로 편집 가능한 두 가지 버전으로 분리해야 한다고 가정한다.데이터셋을 요청하면 항상 불일치가 발생하며 문제를 감시할 눈 수를 분할하여 문제의 가시성을 감소시킨다.두 프로젝트 사이에 벽을 허무는 것보다 위키피디아 사람들의 눈을 더 강력하고 문제를 발견하는 것이 더 낫다.내 샘플에 의하면 90% 이상의 시간 혹은 그 이상이 여기서 같은 목표를 향해 일하고 있다고 한다.--카르윌 (토크) 16:47, 2017년 12월 8일 (UTC)[
- 하지만 위키피디아 결과가 위키다타 결과와 다를 바 없을 때까지 WMF가 바뀔 것 같지는 않다. 위키피디아 결과가 어떻게 측정될지는 모르겠지만, 그들이 비교하고 있는 품질에 대해 잘 알지 못하거나, 그렇게 된다면, WMF가 그것을 공유하려고 하지 않을 것이기 때문이다.
- 그 데이터 집합은 위키피디아에 적합하지 않다.우리는 그것을 사용하도록 강요당해서는 안 된다.위키피디아에 적합한 데이터 집합은 위키다타에 적합하지 않을 수 있다.그들에게 강요해야 할까?두 개의 데이터 집합은 위키피디아가 그들 자신의 것을 돌볼 수 있다는 것을 의미하며, 위키피디아는 그것으로부터 유용하다고 생각되는 것을 사용할 수 있고, 위키피디아 사람들은 그들이 등록하지 않은 프로젝트를 편집하도록 강요받지 않는다.위키피디아를 편집하기 위해 위키피디아인들에게 압력을 가하기 위해 위키피디아에 관한 형편없는 양질의 데이터를 사용하는 것은, 물론 WMF를 손상시키기 위해 돈을 지불받지 않는 한, 기꺼이 감수할 위험이 아니라, 어느 쪽이나 두 프로젝트 모두에 해를 끼칠 수 있는 역풍을 일으킬 수도 있다. 하지만, 솔직히, 나는 그럴 가능성이 낮다고 생각한다.
- 나 또한 약간의 조사를 했는데, 내 결과는 너의 결과와 일치하지 않아. 그리고 그것들은 또한 통계적으로 신뢰할 수 없을 정도로 작은 표본에서 나온 것들이야.나는 또한 WPSCUBA에서 약 600개의 기사에 대해 짧은 설명을 썼지만, 기록을 보관하지는 않았다.대부분의 (반 이상) 기사들은 위키다타 기사가 존재하지도, 존재하지도 않았거나 부적절하다는 새로운 설명이 필요했다.완벽하게 적절한 것도 있었지만 실제로 존재했던 것 중 절반도 안 되는 것도 있었다.돌아가서 세어보는 것도 가능하겠지만, 그런 프로젝트에 기꺼이 동참할 사람이 있다면 새로운 일을 하는 것이 내 시간을 더 잘 활용할 수 있을 것 같다.어쩌면 위키피디아 주제의학, 아니 전기의학, 즉 질이 실제로 실생활에 영향을 미칠지도 모르지만, 나는 대개 그런 분야에서는 별로 일하지 않고 프로젝트 참여 없이 그 분야로 들어가기를 주저하고 있다.이미 프로젝트가 겹치는 불친절한 반응을 가끔 접했지만 다행히 극소수다.피터 (사우스우드) : 2017년 12월 8일 18:18 (UTC)[ ] ···
- 옵션 4와 5는 어디에서나 빈칸으로 시작한다.전체 제안은 우리가 위키백과 기사를 설명하는 데이터 세트를 독립적으로 편집 가능한 두 가지 버전으로 분리해야 한다고 가정한다.데이터셋을 요청하면 항상 불일치가 발생하며 문제를 감시할 눈 수를 분할하여 문제의 가시성을 감소시킨다.두 프로젝트 사이에 벽을 허무는 것보다 위키피디아 사람들의 눈을 더 강력하고 문제를 발견하는 것이 더 낫다.내 샘플에 의하면 90% 이상의 시간 혹은 그 이상이 여기서 같은 목표를 향해 일하고 있다고 한다.--카르윌 (토크) 16:47, 2017년 12월 8일 (UTC)[
- 옵션 4와 5는 아무것도 비우는 것이 아니라, 그들이 기술하는 기사에 텍스트 내용인 짧은 설명을 넣어야 하며, 기사의 내용을 실제로 알고 있는 사람들에 의해 적절히(또는 최소한 더 잘) 유지되어야 한다.Wikidata는 그들의 사용 조건이 허락한다면, 그리고 그것들이 실제로 Wikidata의 목적에 더 적합하다면 그것들을 사용할 수 있는데, 이것은 현재 결코 명확하지 않다.····피터(사우스우드):(talk) 16:14, 2017년 12월 8일 (UTC)[
- @Pbsouthwood:나는 위키피디아가 (아직 작성되지 않은) 이러한 설명에 대한 목적, 모바일 앱에 대한 가치, VisualEditor에 대한 가치, 그리고 여기서 논의한 Wikidata에 대한 가치 사이에는 그다지 밝은 빛이 없다고 생각한다.거기서 요건에는 "동일하거나 유사한 라벨의 품목을 모호하게 하기 위해 고안된 짧은 문구", POV, 편향, 프로모션 및 논란이 많은 주장을 회피하고, "변화할 가능성이 있는 정보"를 회피하는 것이 포함된다.마지막 것만 이상적인 위키백과 설명과 다를 것 같으며 약간은 다를 것 같다:예: "현 미국 대통령"은 "제45대 미국 대통령"으로 대체되어야 할 것이다.--카르윌 (대화) 22:11, 2017년 12월 12일 (UTC)[
- 설명 문제에 대해 커뮤니티와 WMF 사이에 광범위한 논의가 있었다.나는 이 RFC가 게시하기 전에 초안 단계를 거쳤으면 좋겠다.여기서 결과에 영향을 미칠 수 있는 다른 선택사항이나 문제를 해결해야 할 수 있다.후속 RFC가 필요할 수도 있다.
이전의 RFC[3]의 합의는 분명히 위키다타 서술의 제거를 위한 것이었고, 그것은 분명히 나의 입장이다.대체 옵션은 설명 키 워드를 만드는 것을 아예 건너뛰고, 리드 문장에서 설명을 듣는 것이다.그것은 (1) 모든 기사가 자동으로 서술문을 포함하도록 하는 것의 이점이 있다 (2) 서술문을 만들고 유지하는 일을 피하는 것, (3) 서술-반달리즘이라는 새로운 독립적인 문제를 만드는 것을 피할 것이다.단점은 리드 문장이 항상 짧은 설명을 하는 것은 아니라는 것이다.
새로운 설명 키워드로 간다면 #5 #2와 #1 모두 합리적이다.(#3과 #4는 기본적으로 #5에서 봇 승인을 위해 중복된다.)그러나 아래 질문에서 언급했듯이 #5는 일시적인 위키다타 디폴트로 구현될 수 있다.이것은 우리에게 위키다타 서술이 중단되기 전에 지역 서술문을 작성하기 시작할 시간을 준다.이렇게 하면 갑자기 설명이 공백이 되는 것을 피할 수 있을 것이다.알제 (대화) 21:49, 2017년 12월 8일 (UTC)[ - 2위, 5위 두 번째 선호.자동 생성된 설명은 대부분의 목적에 적합하게 보인다. 샌드스타인 16:14, 2017년 12월 10일 (UTC)[
- Sandstein, 당신의 테스트 샘플은 얼마나 컸으며, 어떻게 선택되었는가?· ···피터 (사우스우드) : 2017년 12월 10일 (UTC) 16:36[
- 5. WD 콘텐츠를 대량으로 수입하면 WD 서술이 없어지는 취지를 꺾는다.제임스 (/)talkcontribs 16:30, 2017년 12월 11일 (UTC)[
- 누군가가 필요한 곳에서 그것들을 바꿀 때까지 제한된 기간 동안만 진실이다.문제가 충분히 크면 수정 작업을 위한 봇 실행이 있을 것이므로 중간 기간 동안 위키피디아에 설명되어 있는 만큼 수정 작업을 할 수 있고 WP에 의해 더 이상 장애가 되지 않을 것이다.WMF의 난독화(Icanthear)중요한 부분은 우리가 그들을 통제할 수 있는 곳으로 데려가서 우리가 그들을 올바르게 만드는 일을 시작할 수 있도록 하는 것이다.· ···피터 (사우스우드) : 2017년 12월 13일 07:47 (UTC)[
- 5 기본적으로 피터가 말한 것.어떤 분야에서는 위키다타 묘사가 좋을 것이다.다른 곳에서는 첫 번째 문장 박리가 좋을 것이다.일부 데이터에서는 infobox를 사용할 수 있다.오르테라갤럽터 (pingo mio) 2017년 12월 19일 16:20 (UTC)[ 하라
- 5 - 이것에 대한 토론을 방금 읽은 후 나는 너무나 많은 반달리즘이 일어났다는 사실에 완전히 놀랐다. 어쨌든 위키다타는 반달리즘을 다루는 데 있어서 무용지물 이상의 것이 아니며, 그러한 5가 그것을 다루는 최선의 방법이다!–Davey2010 23:24, 2017년 12월 27일 (UTC)[
- 1과 5의 조합.중요하지만 WP에서 검토될 때까지 숨겨두십시오.Doc James (대화 · 기여 · 이메일) 06:19, 2017년 12월 30일 (UTC)[
- #6 Wikidata 설명을 유지하고 필요하지 않은 것만 우회한다 결국 모든 위키피디아들은 Wikidata를 사용해야 할 것이다.앞뒤로 움직이는 것은 그다지 말이 되지 않는다.우리가 할 수 있는 유일한 방법은 Wikidata를 직접 업데이트하는 기능을 추가하고, 마법의 단어를 로컬로 우회하는 기능을 유지하는 것이다. -- 매기올라디염 (대화) 15:56, 2017년 12월 30일 (UTC)[
- 5 - 위와 같은 이유로.토니탄 ·토크 04:17, 2018년 1월 17일 (UTC)[
- 5 - 위와 같은 경우. (내가 이 하위섹션을 편집한 시점에서는 피쉬가 토론을 종결하지 않았음을 명확히 하기 위해, 피쉬가 전체 스레드를 닫았을 때, 충돌은 없었고 나의 투표는 어쨌든 결과에 영향을 주지 않는다) 오직 죽음에서만 의무종료 (토크) 13:02, 2018년 2월 6일 (UTC)[
공백으로 수행할 작업
마법의 단어가 없거나 마법의 단어가 가치가 없을 때 우리는 어떻게 해야 할까?
- 대신 Wikidata 설명 표시
- 설명 표시 안 함
- 사전 정의된 사례 목록(목록, 설명 페이지 등) 및 Wikidata에 대한 설명을 표시하지 마십시오(사용자가 주장하는 솔루션:대니H (WMF)
- 기타
- #1에서 #2로 전환.초기 단계에서는 현지 서술이 부족한 기사는 위키다타로부터 설명을 계속 끌어낼 것이다.우리는 새로운 설명 키워드를 배치하고 Wikidata 설명을 무시하는 로컬 설명을 작성하기 시작한다.일단 충분한 현지 설명 기반을 구축한 후에는 Wikidata 설명을 완전히 끄면서 전환을 마무리한다. (참고: 2018년 1월 6일(UTC) 16:34 추가. 이전의 토론 참여자들은 빈칸 채우기: 옵션 #5) 하위섹션에서 이 새로운 옵션에 대해 논의하기 위해 ping을 받았다.
공백에 대한 토론
- #2 – 초기 중단 RfC에 대한 설명이 없는 경우, 원하는 사용자는 RfC를 작성하거나 (일반적으로 봇 승인 절차에 따라) 자동으로 작성할 수 있다. --Francis Schonken(대화) 10:28, 2017년 12월 8일(UTC)[
- 아래의 다양한 논의에 따른 합리적인 타협으로 #5.····피터 (사우스우드) : 18:24, 2018년 1월 6일 (UTC)
#2Wikidata 설명은 짧은 설명으로 제공될 만한 유용한 목적이 없는기본값으로 허용해서는 안 된다.마법의 단어에 대한 빈 매개변수는 짧은 설명이 필요 없다는 위키백과의 편집 결정으로 존중되어야 한다.이 결정은 항상 토크 페이지에서 논의될 수 있다.어떤 경우에도 WMF가 위키다타의 원치 않는 짧은 설명을 기본값으로 강제해서는 안 된다.Wikidata에 의해서도 사용되는 설명을 누군가가 수동으로 추가하는 것을 막는 것은 아무것도 없지만, 그것은 편집자의 개인적인 결정이고 그들은 다른 편집에 관해서도 개인적인 책임을 진다.미리 정의된 클래스 목록에 대한 설명을 자동으로 제공하지 않는 것은 문제가 있는데, 이러한 클래스가 일부 사람들이 생각하는 것처럼 쉽게 정의되지 않을 수 있기 때문이다.예를 들어, 대부분의 목록 기사는 짧은 설명이 필요하지 않지만, 일부 기사들은 설명이 필요하다.디스큐 페이지도 마찬가지일 수 있다.첫 번째 단계로 빈칸을 남겨두고 (희망적으로 유능한) 편집자가 하나를 추가할 때까지 짧은 설명을 표시하지 않는 것은 가장자리 사례에 대해 관리가 용이하며 모집단의 옵션 5당 다른 방법으로 관리할 수 있다.그것은 유연하고 모든 가능성을 다룰 수 있다.그것을 더 복잡하게 만들 필요가 없으며, 어느 정도 시간을 허비하기 쉽다.이상적으로는 왜 짧은 설명이 없어야 하는지에 대한 설명이 유용한 매개변수 대신 마법의 단어가 코멘트를 줄 수 있다.이 경우 코멘트를 표시해서는 안 되며, 코멘트를 놓쳤는지 궁금해 할 편집자에게 알려야 한다.· ···피터(사우스우드):2017년 12월8일(UTC)11시43분[ - #1 - 대신 위키다타 설명을 표시한다.—DJ (대화 • 기여) 2017년 12월 8일 12시 10분 (UTC)[
- #2. 어떤 마법의 단어(그리고 매개 변수가 없는 마법의 단어)도 아무런 설명이 없어야 하며, 일부 비엔위키 데이터가 독자들에게 혼란스럽게 보여져서는 안 된다(대부분의 공공 기물 파괴 행위 패트롤러들이 놓치고 있음).오늘, 8시간 동안, 우리는 하루에 10,000 페이지 뷰가 있는 한 페이지에 이런 노골적인 BLP 위반을 했다.기본적으로(또는 아예) 이러한 설명을 사용하는 것은 좋지 않은 생각이며, 이전 RfC에서 거부되었다.프람 (토크) 14:21, 2017년 12월 8일 (UTC)[
- #1 - WMF로부터: 위키피디아에 정의된 마법 단어가 없을 경우, 위키다타를 기본 설정으로 사용하는 것을 제안하는 것인데, 짧은 설명은 (검색 결과의 앱, 맨 위 읽기 모듈, 기사 페이지 맨 위)와 편집자(Visual Editor 링크 대화상자)에게 유용하기 때문이다.예를 들어, 여기 사진에서 9월에 나온 상위 읽기 모듈에서 5개의 상위 기사 중 3개는 짧은 설명으로 이득을 얻는다. - 나는 Gennady Golovkin과 Canelo Alvarez가 누구인지 알지 못한다. 그리고 그것들을 "카자흐스타니 권투 선수"와 "멕시코 권투 선수"로 묘사하게 하는 것은 내가 그것들을 클릭하는 것에 관심이 있는지 말해준다.(그것에 대한 답은 아니오, 난 정말 권투선수가 아니에요.)나는 마더!가 2017년 영화라는 것을 알지만, 설명 없이 그 기사 제목이 완전히 당황스러울 사람들이 많을 거라고 확신한다.상위 기사들의 전체 목록을 클릭하면 사람들이 알지 못할 많은 이름들이 있다. 앰버 탐블린, 아르잔 싱, 고란 드라기치.이것은 앱에서 정말 인기 있는 기능이고, 설명이 없으면 거의 쓸모가 없을 것이다.
- 우리는 위키백과 편집자들이 설명에 대한 편집권을 가질 수 있도록 마법의 단어를 만들고 싶다.그러나 위키백과의 마법의 단어가 빈칸으로 남겨진다면, 특히 위키백과 편집자들이 아직 설명을 쓰지 않은 경우라면, 대부분의 경우 위키다타의 설명을 보여주는 것이 아무것도 보여주지 않는 것보다 낫다.그 탑리딩 모듈을 보는 독자로서, 나는 게나디 골로프킨이 누구인지 알고 싶다. 그리고 그 텍스트가 위키백과에서 온 것인지 위키다타에서 온 것인지 "카자흐스타니 복서"라고 말해야 한다.
- 사람들이 위키다타 묘사를 보여주는 것에 대해 걱정하는 큰 이유는 위키다타 공동체가 때때로 위키백과 커뮤니티보다 더 느리게 반달리즘의 구체적인 예를 들 수 있기 때문이라는 것을 알고 있다.영국의 헨리 8세의 프람이 2시간 동안 "오비 히틀러"를 보여준 예는 실망스럽고 좌절스럽다.다만 짧은 묘사를 감시하는 지역사회의 능력을 향상시켜 공공 기물 파손이나 잘못을 더 빨리 발견하고 되돌릴 수 있도록 하는 것이 최선의 해결책이 되어야 한다고 생각한다.위키다타 팀은 위키백과의 감시목록에서 보다 세밀한 표시를 제공함으로써 위키다타 항목에 대한 다른 관련 없는 편집에 의해 묻히지 않고 위키백과 편집자들이 보고 있는 기사에 대한 설명을 수정할 수 있도록 노력하고 있다.그 작업은 이 페이브리카이터 티켓에서 추적되고 있다.T90436 - 하지만 현재 상태가 어떤지 잘 모르겠어.Ping for User:리디아 핀트셔(WMDE) -- 어떻게 진행되고 있는지 아십니까?
- 이제 와서야 다시 얘기해서 미안해.슬그머니 통과했다.그래서 우리는 위키다타에서 나온 최근의 변화와 감시목록에서 어떤 변화가 나타나는지 향상시키기 위해 계속 노력해 왔다.특히 우리는 현재의 시스템을 확장하는데 많은 노력을 기울였는데, 이것은 더 이상의 개선을 위한 요구 사항이다.우리는 우리가 보내는 변화들을 작게 만들었고 위키다타에서 위키피디아로 보내는 변화들이 줄어들도록 만들었다.우리는 또한 위키(카위키, 세위키, 코위키, 트루위키)가 어떻게 확장되는지 보기 위해 세부적인 사용 추적 기능을 제공했다.세부적인 사용량 추적을 통해 당신은 더 이상 현재 일어나고 있는 기사처럼 실제로 영향을 미치지 않는 최근의 변경사항과 감시목록의 변화를 볼 수 없을 것이다.지금까지 이 위키에서 발표된 내용들은 유망해 보인다.1월에 우리는 그것을 더 많은 위키에 계속 배포하고 그것이 엔위키에 맞게 충분히 확장되는지 볼 것이다.이와 함께 1월 개발자 서밋에서 여러 팀과 협의해 시스템 규모를 개선하거나 정비할 수 있는 다른 방안을 브레인스토밍할 예정이다. --Lydia Pintscher (WMDE) (토크) 09:31, 2017년 12월 19일 (UTC)[
- 우리는 이전 토론에서 위키다타 설명이 기사 표시에 유용하지 않은 페이지 유형에 대해 이야기한 적이 있다. 기사 주제가 아닌 페이지 자체를 설명하고 있기 때문이다.내가 지금 알고 있는 예로는 카테고리 페이지(현재 "위키메디아 카테고리 페이지"), 디컴파일 페이지("위키메디아 디스컴파일 페이지"), 리스트 페이지, 메인 페이지 등이 있다.그러한 것들은 VE 링크 대화상자, 특히 "해체 페이지"의 경우에 도움이 될 수 있지만, 기사 페이지 상단에 그것들을 표시할 이유는 없다. 그들이 불필요하고 어리석게 보인다.우리는 기사 페이지 디스플레이에서 그것들을 걸러내고, 그것들이 불필요한 다른 곳에서는 걸러내자고 제안하고 있다.사람들이 알고 있다면, 나는 짧은 설명이 유용하지 않은 페이지의 예시를 더 알고 싶다.
- 기사 페이지의 경우, 필자는 아직까지는 빈칸 서술이 필요한 사람들(VE의 링크를 읽고, 검색하고, 추가하는 사람들)에게 더 좋을 만한 예에 대해서는 알지 못한다."공백 설명 표시" 기능을 구축하려면 가장 좋은 결과가 될 수 있는 구체적인 사용 사례에 대해 설명하십시오.이것이 제품 개발의 작동 방식입니다. 제품이 어디에 유용할 지에 대한 어떠한 예도 없다면, 기능을 구축하지 않는 겁니다.사람들이 구체적인 예시를 든다면, 그러면 많은 도움이 될 것이다. -- 대니H (WMF) (토크) 14:58, 2017년 12월 8일 (UTC)[
- "기사 페이지의 경우, 빈칸 서술이 더 나을 만한 지금까지 어떤 예도 알지 못한다." 바로 이 토론에서 내가 제공한 바로 이 토론에서 오늘 8시간 동안 지속된 아주 노골적인 BLP 위반을 포함해 하루에 10K 이상의 페이지뷰를 가진 페이지의 반달리즘의 두 예를 확인해 보라.이 예에서, 빈칸 서술이 파손된 설명보다 훨씬 더 바람직했을 것이다, 그렇지 않은가?그나저나 두 기사는 모두 여기서 반보호를 하고 있어서, 반방범행위가 이곳의 IP들에 의해 행해질 수 없었을 것이다(그리고 훨씬 더 일찍 잡혔을 가능성이 매우 높다)."최상의 결과가 될 수 있는 특정 사용 사례" = 모든 기사, 그리고 확실히 BLP.프람 (토크) 15:19, 2017년 12월 8일 (UTC)[
- 위키다타에 비해 설명이 선호되지 않는 다른 예를 보려면 오른쪽을 보십시오.이것은 제2차 세계대전을 검색하는 사람들(또는 모바일 앱인 "관련 기사"에 있는 사람들)이 지금 바로 보고 5시간 이상부터 보고 있는 것이다(이것을 여기에 올렸으니 의심의 여지없이 곧 되돌릴 것이다).이런 일은 매일 일어나고, 우리가 가장 많이 보는 몇몇 페이지에서는 너무 자주 일어난다.프람 (토크) 15:38, 2017년 12월 8일 (UTC)[
- 나는 위키다타에 대한 반달리즘 응답률이 때때로 너무 느리다는 것에 동의한다.이에 대한 해결책은 위키백과 편집자들이 설명의 파괴 행위를 더 쉽게 감시하고 고칠 수 있도록 함으로써 응답률을 더 좋게 만드는 것이라고 생각한다.나는 가장 좋은 해결책이 사전 백지 서술이라는 것에 동의하지 않는다. 왜냐하면 우리는 그것들이 파손될 가능성이 있다는 것을 알기 때문이다.이미 위키다타에 나와 있는 대다수의 선에서 적절하고 적절한 서술보다 빈 서술이 더 좋기 때문에 편집자들이 기사 페이지에 설명을 표시하지 않도록 선택할 수 있는 구체적인 예를 요청하는 것이다. -- 대니H (WMF) (토크) 2017년 12월 8일 (UTC)[
- 그리고 나는 이것이 청어라고 말하고 있다.첫째로, 당신은 위키다타에 대한 대다수의 선에서 적절한 묘사가 존재한다고 주장하지만, 이것이 사실이라는 납득할 만한 증거는 없다.필자는 내가 제작한 수백 건의 짧은 서술 중에서 짧은 서술만으로 기사 제목 자체보다 뚜렷한 개선점이 없는 경우가 영(0)이 아닌 경우가 있었다고 말하고 있다.· ···피터(사우스우드) : 2017년 12월 8일 16:21, (UTC)[
- 나는 위키다타에 대한 반달리즘 응답률이 때때로 너무 느리다는 것에 동의한다.이에 대한 해결책은 위키백과 편집자들이 설명의 파괴 행위를 더 쉽게 감시하고 고칠 수 있도록 함으로써 응답률을 더 좋게 만드는 것이라고 생각한다.나는 가장 좋은 해결책이 사전 백지 서술이라는 것에 동의하지 않는다. 왜냐하면 우리는 그것들이 파손될 가능성이 있다는 것을 알기 때문이다.이미 위키다타에 나와 있는 대다수의 선에서 적절하고 적절한 서술보다 빈 서술이 더 좋기 때문에 편집자들이 기사 페이지에 설명을 표시하지 않도록 선택할 수 있는 구체적인 예를 요청하는 것이다. -- 대니H (WMF) (토크) 2017년 12월 8일 (UTC)[
- DannyH (WMF), 기사 페이지 뷰에서 설명을 필터링하는 것은 기술적으로 문제가 있을 수 있는 페이지 유형이 아닌 내용에 따라 필터링되지 않는 한 유지보수를 위해 보이지 않는다는 것을 의미하는데, 나는 필터 코드를 쓰지 않는다.어떤 공공 기물 파손 행위도 이 길로 몰래 들어갈 수 없다는 것을 보장할 수 있는가?그것들이 위키백과 기사와 관련하여 어느 곳에서나 보이는 한, 그것들은 위키백과 편집 문제일 것이다.· ···피터(사우스우드) : 2017년 12월 8일 15:39, (UTC)[
- 우리는 존재하지 않는 기술들을 배제하기 위해 개발 기능을 요구하는 것이 아니다. 그것은 가능한 가장 간단한 채무불이행이다.마법의 단어 매개 변수에 있는 모든 콘텐츠를 단순히 표시하는 것이 가장 간단하고 가장 다용도 있는 솔루션이며, 공백으로 두면 공백으로 두는 것이 더 좋기 때문이라는 것을 받아들이도록 노력하십시오.이런 경우 중 어느 경우든 짧은 설명을 원하는 사람이 있다면 위키피디아를 편집해 옳다고 생각하는 것을 넣을 수 있고, 이를 없애고 싶을 정도로 강하게 동의하지 않는 사람이 있다면 편집 불협화음의 표준 절차를 따를 수 있는데, 이것이 바로 토크페이지에서 공감대를 얻는 것이다.이것은 로켓 과학이 아니라 위키피디아 방식으로 이런 일을 하는 것이다.만약 마법의 단어가 매개 변수에서 코멘트를 처리하는 것이 어렵다면, 우리는 코멘트를 외부에 간단히 넣을 수 있다.사람들이 그것이 거기 있다는 것을 알아차리지 못하는 몇 가지 사례가 더 있을 수 있지만, 아마도 기차 충돌은 아닐 것이다.매개변수 공간의 코멘트를 설명이 없는 것과 동등한 것으로 구문 분석해서는 안 되는 이유가 있는가?나는 이것을 전에 물어본 적이 있고, 여전히 답변을 기다리고 있다.· ···피터(사우스우드) : 2017년 12월 8일 15:39, (UTC)[
- 위키다타에 비해 설명이 선호되지 않는 다른 예를 보려면 오른쪽을 보십시오.이것은 제2차 세계대전을 검색하는 사람들(또는 모바일 앱인 "관련 기사"에 있는 사람들)이 지금 바로 보고 5시간 이상부터 보고 있는 것이다(이것을 여기에 올렸으니 의심의 여지없이 곧 되돌릴 것이다).이런 일은 매일 일어나고, 우리가 가장 많이 보는 몇몇 페이지에서는 너무 자주 일어난다.프람 (토크) 15:38, 2017년 12월 8일 (UTC)[
- #1 - 그리고 Wikidata에 대한 설명을 개선하는 데 초점을 맞춘다.마이크 필 (토크) 15:27, 2017년 12월 8일 (UTC)[
- Wikipedia_talk에서 토론을 참조하십시오.Wikidata/2017_State_of_afferes#Circular_'sourcing'_on_Wikidata - 나는 1,000개의 글과 설명의 무작위 샘플을 올렸는데, 그 중 단 1개의 설명만이 오타를 가지고 있었고, 39%가 아직 설명을 가지고 있지 않지만 노골적으로 틀린 것 같았다.그래서 그 추가 설명들을 덧붙이자/기존 설명을 개선하자, 오히려 시스템을 개선하자.고마워요.마이크 필 (토크) 00:14, 2017년 12월 12일 (UTC)[
- 그 샘플은 위키다타에 옳고 일반 엔위키 독자들에게는 쓸모없는(또는 최소한 매우 불분명) 많은 전형적인 설명들을 포함하고 있다: "위키메디아 디스큐 페이지"(Wikimedia란 무엇인가, 위키백과가 되어야 하지 않을까, 그리고 그 후에도, 나는 위키피디아에 속해 있다는 것을 알고 있고, 우리는 표준 기사에 대한 설명으로 "위키피디아 기사"를 사용하지 않는다....) 또 다른 오타("영국 슬라브 육군 장교"), 쓸모없는 설명("인간의 정착", 좀 더 정확하게 말해줄 수 있을까"), 중복된 것(Shine On (Ralph Stanley 앨범) - "랄프 스탠리의 앨범") 등이 있다...그리고 언어에 기반한 문제들이 위키다타에서 유지되어서는 안되지만 특정 언어에서, 그것은 "포용"이 아니라 위키다타가 아닌 엔위키에 속하는 컨텐츠를 다시 가져가는 것이다.프람 (토크) 05:45, 2017년 12월 12일 (UTC)[
- 당신은 그 샘플의 문제 목록에 "Engels; Schilder; 1919; Londen (Engeland); 1984"를 추가할 수 있다.프람 (토크) 06:01, 2017년 12월 12일 (UTC)[
- 그리고 "동물이나 식물의 정해진 성"남성에게 Q6581097 사용"은 엔위키에서도 사용할 수 없다(그러나 위키다타에게는 아마도 완벽할 것이다).Neeraj Grover 살인 사건 - "TV 중역" 역시 잘못된 묘사처럼 보인다.스테판 테르지치 - "팀 핸드볼"도 어느 정도 개선이 필요할 수 있다.프람 (토크) 07:56, 2017년 12월 12일 (UTC)[
- 좋아, 그럼 아마도 1000분의 4가 영어로 오타가 있거나 틀릴지도 몰라. 그래도 나쁘지 않아.나머지 대부분은 WP인 것 같다.IDONTLICKIT (WP라면:Wikidata에 대한 SOFIXIT, 그러나 당신은 그것을 하고 싶지 않을 것이다.그렇다, 그것은 포킹이다 - 현재 위키다타에만 설명들이 존재하며, 위키피디아에서는 그런 설명들이 한번도 없었으며, 이것 때문에 설명들이 사라지지 않고 있다 - 그래서 여러분은 그것들을 포크로 만들고 싶어하고, 어떻게 보면 두 시스템이 나중에 (라이선스 문제로 인해) 포크를 풀 수 없다는 것을 의미한다.그것은 특히 장기적으로 도움이 되지 않는다.마이크 필 (토크) 2017년 12월 12일 (UTC) 19:58 [
- 나는 4가지 이상의 예를 들었고, 약 40%는 설명이 없고(그래서 그 중 많은 수가 설명이 필요하더라도 거의 틀릴 수 없다), 그리고 많은 수가 우리가 사용할 수 없거나 해서는 안 되는 설명을 가지고 있다.기본적으로, 실제로는 50%에 가까운 0.1%의 문제에서 출발하셨습니다.잠금 해제가 불가능할 수 있는 라이센싱 문제를 지정하십시오.이 비이슈들은 또한 위키다타 설명을 수입하는 것을 불가능하게 만들 것으로 보인다, 그렇지 않은가?나한테는 빨간 청어처럼 보여.그런데, 위키다타가 엔위키(및 다른 언어)로부터 수백만 개의 아이템으로 채워졌을 때, 그 이후로는 따로 진화할 수 있는 것에 대해 불평한 적이 있는가?아니면, 포킹은 위키다타에서 엔위키까지 행해질 때만 문제가 되는 것이지, 그 반대는 문제되지 않는 것인가?프람 (토크) 22:28, 2017년 12월 12일 (UTC)[
- 당신의 예시 문제들 중 몇 가지만 실제 문제인 것 같고, 나머지는 주관적이다.설명 없이 100%로 바꾸자고 제안하는 거잖아, 그래서 어떻게 40% 빈칸 서술에 대해 논쟁할 수 있는지 모르겠네(그리고 이 토론이 시작될 때 문제가 되지 않았다).0.1%는 아니지만 여기선 1%가 타당해 보인다.enwp 설명은 CC-BY-SA 라이센스인데, 이것은 CC-0 라이센스를 가지고 있기 때문에 Wikidata에 단순히 복사될 수 없다는 것을 의미한다(그리고 그렇다, 이것은 훌륭하지 않다, 그리고 간단한 설명의 저작권을 갖는 것은 말이 되지 않지만, 그것은 우리가 여전히 필요할 경우 Wikidata에서 이곳으로 복사할 수 있다는 것을 의미한다).나는 우리가 여기서 같은 일을 하기 위해(주제 서술), 더 나은 도구(구조화된 데이터베이스)가 아닌 잘못된 도구(해킹이 있는 자유 텍스트)를 사용하여 그렇게 하려고 한다고 불평하고 있다.마이크 필 (토크) 23:01, 2017년 12월 12일 (UTC)[
- 아, 예전 '구조화된 데이터베이스' vs '해킹이 있는 자유 텍스트' 주장, 왜 아직 언급이 안 됐는지 궁금했다.Wikidata에서 당신은 데이터베이스 필드에 자유 텍스트를 넣는 것이고, 그 다음 런타임에 읽기 및 표시된다.enwiki에서 당신은 "마법적인 단어" 템플릿에 자유 텍스트를 넣는 것이고, 그러면 런타임에 읽고 디스플레이 된다.Wikidata의 설명이 자유 텍스트가 아니고 enwiki의 자유 텍스트인 척 하는 것은 정말 설득력이 없다.그러나, 그 과제에 대한 잘못된 도구는 위키다타인데, 그것은 엔위키 페이지 역사와 위키텍스트의 일부가 아니므로, 따라서 적절히 감시하고 보호하며, ...할 수 없기 때문이다.유일한 "핵"은 현재의 것으로, 엔위키가 더 잘 할 수 있는 것을 하기 위해 위키다타를 사용하는 것이다(그리고 철학적으로도 엔위키에 속하는데, 그것은 언어에 기반을 둔 텍스트일 뿐이지 보편적으로 받아들여지는 가치는 아니다).프람 (토크) 07:53, 2017년 12월 13일 (UTC)[
- 당신의 예시 문제들 중 몇 가지만 실제 문제인 것 같고, 나머지는 주관적이다.설명 없이 100%로 바꾸자고 제안하는 거잖아, 그래서 어떻게 40% 빈칸 서술에 대해 논쟁할 수 있는지 모르겠네(그리고 이 토론이 시작될 때 문제가 되지 않았다).0.1%는 아니지만 여기선 1%가 타당해 보인다.enwp 설명은 CC-BY-SA 라이센스인데, 이것은 CC-0 라이센스를 가지고 있기 때문에 Wikidata에 단순히 복사될 수 없다는 것을 의미한다(그리고 그렇다, 이것은 훌륭하지 않다, 그리고 간단한 설명의 저작권을 갖는 것은 말이 되지 않지만, 그것은 우리가 여전히 필요할 경우 Wikidata에서 이곳으로 복사할 수 있다는 것을 의미한다).나는 우리가 여기서 같은 일을 하기 위해(주제 서술), 더 나은 도구(구조화된 데이터베이스)가 아닌 잘못된 도구(해킹이 있는 자유 텍스트)를 사용하여 그렇게 하려고 한다고 불평하고 있다.마이크 필 (토크) 23:01, 2017년 12월 12일 (UTC)[
- 나는 4가지 이상의 예를 들었고, 약 40%는 설명이 없고(그래서 그 중 많은 수가 설명이 필요하더라도 거의 틀릴 수 없다), 그리고 많은 수가 우리가 사용할 수 없거나 해서는 안 되는 설명을 가지고 있다.기본적으로, 실제로는 50%에 가까운 0.1%의 문제에서 출발하셨습니다.잠금 해제가 불가능할 수 있는 라이센싱 문제를 지정하십시오.이 비이슈들은 또한 위키다타 설명을 수입하는 것을 불가능하게 만들 것으로 보인다, 그렇지 않은가?나한테는 빨간 청어처럼 보여.그런데, 위키다타가 엔위키(및 다른 언어)로부터 수백만 개의 아이템으로 채워졌을 때, 그 이후로는 따로 진화할 수 있는 것에 대해 불평한 적이 있는가?아니면, 포킹은 위키다타에서 엔위키까지 행해질 때만 문제가 되는 것이지, 그 반대는 문제되지 않는 것인가?프람 (토크) 22:28, 2017년 12월 12일 (UTC)[
- 좋아, 그럼 아마도 1000분의 4가 영어로 오타가 있거나 틀릴지도 몰라. 그래도 나쁘지 않아.나머지 대부분은 WP인 것 같다.IDONTLICKIT (WP라면:Wikidata에 대한 SOFIXIT, 그러나 당신은 그것을 하고 싶지 않을 것이다.그렇다, 그것은 포킹이다 - 현재 위키다타에만 설명들이 존재하며, 위키피디아에서는 그런 설명들이 한번도 없었으며, 이것 때문에 설명들이 사라지지 않고 있다 - 그래서 여러분은 그것들을 포크로 만들고 싶어하고, 어떻게 보면 두 시스템이 나중에 (라이선스 문제로 인해) 포크를 풀 수 없다는 것을 의미한다.그것은 특히 장기적으로 도움이 되지 않는다.마이크 필 (토크) 2017년 12월 12일 (UTC) 19:58 [
- Wikipedia_talk에서 토론을 참조하십시오.Wikidata/2017_State_of_afferes#Circular_'sourcing'_on_Wikidata - 나는 1,000개의 글과 설명의 무작위 샘플을 올렸는데, 그 중 단 1개의 설명만이 오타를 가지고 있었고, 39%가 아직 설명을 가지고 있지 않지만 노골적으로 틀린 것 같았다.그래서 그 추가 설명들을 덧붙이자/기존 설명을 개선하자, 오히려 시스템을 개선하자.고마워요.마이크 필 (토크) 00:14, 2017년 12월 12일 (UTC)[
- #2 또는 #1에서 #2로 전환.나는 WMF와 Wikidata/2017년 국정현안 토크 페이지에 대한 설명-이슈에 대해 중요한 논의를 했다.WMF는 갑자기 빈칸을 만드는 것에 대해 타당한 우려를 가지고 있으며, 우리는 그러한 우려에 대해 협력하도록 노력해야 한다.일시적으로 빈 키워드를 wikidata(#1)로 디폴트하도록 하면 wikidata 설명(#2)을 종료하기 전에 빈 로컬 설명을 채우기 시작할 시간을 갖게 된다.그러나 장기적으로 보면 내 포지션은 단연 2위다.(대화) 21:02, 2017년 12월 8일 (UTC) #5에 대한 명시적 지지 추가, 이것은 본질적으로 나의 원래 투표와 일치한다.알제 (대화) 16:36, 2018년 1월 6일 (UTC)[
- 이거면 될 것 같아.우리가 짧은 설명을 작성하는 동안, 짧은 설명이 있어서는 안 될 기사가 발견될 때마다, 불필요한 위키다타 설명을 무시하기 위해 방해받지 않는 공간을 넣을 수도 있다.우리는 데스크톱에서 모바일에서도 실제 디스플레이를 봐야 하므로 우리가 무엇을 하고 있는지 알 수 있다.바탕화면에서 실제 사용 시 짧은 설명을 표시하는 한, 바꿀 필요가 없을 수도 있다.그렇게 되면 공정을 서두르라는 압박감이 줄어들게 되는데, 이것은 좋은 것일 수도 있지만 그렇지 않을 수도 있다.· ···피터(사우스우드) : 2017년 12월 9일(UTC) 10시 12분[
- 앨시, 고마워나는 영국 WP 커뮤니티가 결정해야 할 내용적 결정이라고 생각하기 때문에 마법의 단어가 언제 어떻게 쓰이고 어떻게 채워지는지에 대한 대화를 하지 않고 있다.위키백과 편집자들이 그 짧은 설명을 지금 사용하고 있는 독자와 편집자들의 경험을 해치지 않고, 어떻게 하면 그 짧은 설명에 대한 적절한 편집 통제권을 가질 수 있는 곳에 도달할 수 있는지 알아내고 싶다. -- 대니H (WMF) (토크) 23:29, 2017년 12월 11일 (UTC)[
- Q-코드, 간단한 설명 및 별칭은 다음 스크립트를 통해 볼 수 있다.[4]--Carwil (대화) 13:01, 2017년 12월 9일 (UTC)[
- Carwil, 이것은 정확히 내가 염두에 둔 전시품이다.다른 텍스트 크기의 다른 메타데이터와 함께 표시되기 때문에 쉽게 볼 수 있지만 분명히 글의 일부가 아니다.유용하게 쓰려면 품질이 낮은 설명을 개선할 수 있는 모든 편집자가 볼 수 있어야 하므로 바탕 화면에 기본 디스플레이가 되어야 한다.이것은 모두에게 좋은 반응을 얻지 못할 수도 있지만, 아마도 정말 알고 싶어하지 않는 사람들에게 선택권으로서 유용할 것이다.위키다타에 대한 설명을 가지고 있는 본질적인 문제들은 여전히 다루지 않는데, 위키다타의 콘텐츠 정책을 지시하고, 그들의 페이지 보호를 통제하고, 반달들을 차단하지 않는다는 점에서, 그러나 그것은 우리가 거기에 무엇이 있는지 보게 해주며, 비록 내가 공정한 아멘을 했기 때문에 편견을 가지고 있을지 모르지만, 사실 고치는 것은 꽤 쉽다.Wikidata에 대한 작업의 t.이 대본 사용에 대해 위키다타를 편집하지 않은 사람들의 의견을 듣고 싶다.위키다타 묘사를 감시하고 싶은 사람에게는 확실히 추천할 수 있다.야에랜드에게 쿠도스.· ···피터(사우스우드) : 2017년 12월 9일 16시 15분(UTC)[
- 그것은 또한 설명에 대한 서로 다른 필요성의 문제를 해결하지 않는다.위키다타 설명이 위키백과에 적합하지 않을 때, 위키다타의 목적에 잘 맞으면 임의로 변경해서는 안 되지만, 위키백과에 쓰이려면 그 정도만 해야 할 수도 있다.· ···피터 (사우스우드) : 2017년 12월 9일 (UTC) 16:21[
- Q-코드, 간단한 설명 및 별칭은 다음 스크립트를 통해 볼 수 있다.[4]--Carwil (대화) 13:01, 2017년 12월 9일 (UTC)[
- #2. 위키다타 수입은 그 내용이 위키백과의 편집 통제와 합의의 대상이 아니기 때문에 피해야 한다. 샌드스타인 16:16, 2017년 12월 10일 (UTC)[
- Sandstein, 나의 개인적인 선호도는 결국 모든 짧은 서술이 위키백과의 일부가 되어야 하고, 런타임에 수입되어서는 안된다는 것이다. 그러나, 중간 조치로, 일이 더 빨리 진행되도록 하기 위해, 나는 처음에 위키다타 설명을 빈 매직 워드 파라미터의 기본값으로 표시하는 것이 WMF보다 더 나쁘지는 않기 때문에, 위키다타 설명을 표시하는 데 있어 어느 정도 가치가 있다고 본다.이미 하고 있고, 내 생각에는 그들이 위키백과 지역 설명이 평균적으로 더 낫다고 생각할 때까지 계속 할 것 같다.만약 누군가가 전시된 위키다타 설명서가 적절하지 않은 것을 발견한다면, 그들은 마법의 단어에 더 나은 것을 삽입하기만 하면 바로 위키피디아의 일부가 된다.만약 당신이 좋은 위키다타 설명을 발견한다면, 당신은 그것을 마법의 단어에 삽입하여 국부적으로 만들 수도 있다. 그것은 반드시 CC0 면허가 있기 때문이다.100% 로컬 콘텐츠를 얻는 데 있어서 유일한 제한은 위키피디아인으로서 우리가 얼마나 많은 노력을 할 준비가 되어 있느냐 하는 것이다.Wikidata의 지지자들은 그것이 그들이 하고 싶은 것이라면 대신에 Wikidata에 대한 설명을 개선할 수 있고, 좋은 짧은 설명이 전시되는 한, 아무도 그것을 사용하는 것을 그만둘 만큼 충분히 강하게 느끼지 못할 수도 있다.나는 파손된 설명이 발견될 때마다 대부분의 위키피디아 사람들은 지역적인 짧은 설명을 제공할 것이고, 따라서 위키다타 설명을 사용하는 것을 찬성하는 사람들은 공공 기물 파손을 줄이고 더 빨리 고칠 수 있는 방법을 강구하도록 장려될 것이고, 이것은 위키다타를 크게 개선할 것이다.모든 사람이 이기는데, 어쩌면 어느 한쪽이 원하는 만큼은 아닐지 모르지만, 그렇지 않을 경우보다 더 많이 이기게 된다.WMF가 가장 많이 이기겠지만, 일부 사람들에게는 짜증나는 일이지만, 위키백과와 위키다타에 대한 순이익이 있는 한 우리는 그것을 가지고 살 수 있다.· ···피터 (사우스우드) : 2017년 12월 10일 (UTC) 16:58[
- 2. 우리는 정책에 정반대되는 프로젝트에 대해 WP 지침을 시행할 책임도 권한도 없다.WP의 편집통제권 밖의 콘텐츠는 우리의 페이지, 기간에 나타나서는 안 된다.제임스 (/)talkcontribs 16:34, 2017년 12월 11일 (UTC)[
- 2는 내 견해에 가장 근접해 있어, 선택권이 주어진다면.WT에서 내 의견을 참조하십시오.Wikidata/2017년 국정/아카이브 12 및 WT:위키다타/2017년 국정현안.또한 3월부터 RfC를 참조하라; 대부분의 경우 현재 질문과 동등하게 관련이 있다고 한다. - Dank (Push to Talk) 21:01, 2017년 12월 11일 (UTC)[ 하라
- WMF의 논평: 나는 타협과 합의에 대해 한 마디 하고 싶다.나는 지금 거의 석 달 가까이 이런 논의에 관여해 왔으며, 몇 가지 한결같은 점이 있다.
- 첫째는 기존의 특징으로는 위키백과 편집자가 설명을 편집 통제할 수 없다는 것을 인식하고 동의하며, 위키백과 편집자들이 기존의 설명을 보고, 변경사항을 모니터하고, 문제가 발생했을 때 문제를 수정하는 것은 너무 어렵다는 점이다.WMF 제품 팀 및/또는 Wikidata 팀이 해결해야 할 문제들이다.
- 둘째, 우리가 이 문제를 해결하는 방법은 형식이나 내용에 대한 편집 결정을 내리는 것을 포함하지 않는다.그것은 영어 위키백과와 위키다타 커뮤니티에 달려 있으며, 만일 그러한 커뮤니티의 사람들 사이에 의견 차이가 있다면, 궁극적인 통제는 위키다타가 아닌 위키백과에 위치해야 한다.다시 말해, 우리가 마법의 단어를 만들 때, 우리는 그것이 어떻게 사용되는지, 얼마나 자주, 또는 어떤 형식이 되어야 하는지를 통제하지 않을 것이다.나는 이 두 가지 점 모두 여기 있는 대부분의 사람들이 말하는 것과 일맥상통한다고 생각한다.
- 세 번째로는, 우리는 어떤 의미 있는 시간 동안, 기존의 기술들을 대량으로 공백으로 만드는 행동 방침에 동의하지 않을 것이다.나는 그것이 여기 있는 대부분의 사람들이 우리가 만들기를 원하지만, 그것은 그러한 설명을 사용하는 독자와 편집자들에게 해로울 것이라는 것을 알고 있다. 그리고 그것이 중요하다.이 해결책은 우리가 그것을 건설할 것이기 때문에 우리와도 합의를 볼 필요가 있다.나는 우리가 이 논의의 합의를 무시하겠다는 것이 아니라, 우리가 그 합의의 일부가 되어야 한다는 것이다. -- 대니H (WMF) (토크) 15:13, 2017년 12월 12일 (UTC)[ 하라
- 8개월여 동안 실제로 얼마나 많은 사람들이 모바일 뷰에서 묘사가 불가능하다고 불평했는가?"이러한 설명을 사용하는 편집자 및 편집자": 어떤 편집자가 될 것인가?어쨌든, 기본적으로 당신은 그 결과가 마음에 들지 않는 한, 내용 결정에 간섭하지 않을 것이다.그러나 동시에 당신은 당신의 특징을 순찰하고 통제하는 데 필요한 도구를 제공하는 것을 귀찮게 할 수 없다(그리고 당신의 첫 번째 요점은 이 마법의 단어가 살아서 어쨌든 요청된 대로 작동될 때 오히려 무트다).그건 당신이 Flow, Gather와 (개인적으로 그리고 WMF처럼) 했던 것과 같은 겁니다. 그것은 바뀌지 않고, 개선되고, 점진적으로 받아들여지지만, 단순히 화염에 휩싸인 채로, 동시에 많은 불필요한 마찰과 나쁜 피를 만들어내면서.너 정말 그 안경에서 배운 거 있어?여기 있는 대부분의 사람들은 실제로 설명을 듣고 싶어하며, 이러한 것들은 상당히 빠르게 채워질 것이다(대략 현재 위키다타에서 제공되는 것보다 더 높은 비율로).그러나 우리는 필요한 곳에 그것들을 채울 것이고, 우리가 그들이 비어있기를 원하는 곳에 그것들을 비워둘 것이다.당신은 지난 몇 달 동안 타협안을 제안할 수 있었는데, 여기서 "마술어 없음" 또는 "설명어 없음"은 "위키다타 설명을 받아들인다"를 의미하고, 다른 하나는 "설명어 없음"을 의미할 것이다.당신은 "마법적인 단어를 설치한 후, 우리는 3개월의 과도기 기간을 가지고 엔위키에 설명이 채워지는지 볼 것이다; 그 후에 우리는 "위키다타에서 추출 desc"를 완전히 무력화시킬 것이다."라고 제안할 수 있었다.대신 당신은 WMF가 최종 결정권을 가지고 있고 WMF가 사전 승인한 기사(또는 기사 그룹)의 목록이 아니면 공백이 허용되지 않을 것이라고 주장했다.왜? 모르겠어.WMF가 너무 귀찮아서 독자들이 무슨 일이 있어도 설명을 받아야만 한다면(아무리 많은 기사들은 애초에 위키다타 설명이 없더라도), 이런 것들을 감시할 사람들을 고용해서 돈을 주고 노골적인 BLP 위반 같은 것이 몇 시간이나 며칠 동안 남아 있지 않도록 해야 한다.그러나 우리의 의사에 반하여 그리고 그것을 순찰하는 데 어떤 심각한 도움도 주지 않고 우리에게 비엔위키 콘텐츠를 보여주도록 강요하는 것은 용납될 수 없는 일이다.프람 (토크) 15:44, 2017년 12월 12일 (UTC)[
- 프람, 그 절충안들이 내가 우리더러 의논하라고 요구하는 거야.네가 그 이야기를 꺼내서 기뻐, 그건 우리가 할 수 있는 대화야.나는 다음 주에 위키다타 팀과 순찰 및 절제 도구 구축에 대한 진행 상황에 대해 이야기 할 것이다.우리는 Wikidata 팀이 무엇을 선택했는지 직접 통제할 수는 없지만, 나는 그들과 함께 짧은 설명을 효과적으로 감시할 수 있는 방법이 계속적으로 부족한 것이 이 대화, 이 커뮤니티, 그리고 전체적인 특징에 어떤 영향을 미치고 있는지에 대해 이야기하고 싶다.영어 위키백과 편집자들은 설명을 효과적으로 채우고 감시할 수 있는 도구를 가지고 있어야 하며, 당신은 말이 되는 타임라인에 그것을 가지고 있어야 한다.더 많은 사람들과 대화하고 어떻게 하면 그렇게 될 수 있는지 계속 연구해야겠어.당신이 제안하는 과도기에 대해 내부적으로 사람들과 이야기할 겁니다. -- 대니H (WMF) (토크) 16:04, 2017년 12월 12일 (UTC)[
- 나는 enwp 콘텐트에 대한 통제력 부족이 주요 관심사라고 생각한다.지역사회가 통제할 수 없는 enwp 콘텐츠의 외부 출처는 현재 두 가지 밖에 없다: 하원과 위키다타; 하원이 enwp에서 남용되는 것을 막기 위해 그들의 콘텐츠 정책과 실패에 대한 신뢰 수준을 구축하는 데 몇 년이 걸렸다.오늘날 여기서 커먼즈 자료를 사용하는 유일한 이유는 1) 그들은 그들의 사업을 처리할 수 있다는 것을 증명했고 2) 투명하고 제정하기 쉬운 지역적 과잉 규제들이 존재한다는 것이다.Wikidata가 유용하고 우리가 여기서 보고 있는 그런 종류의 신랄함을 피하기 위해서는 우리는 Wikidata로부터 같은 것이 필요할 것이다.포인트 1)은 시간이 흐를 때에만 일어날 수 있고, 위키다타는 그 방향에서 증명되기에는 너무 새롭다.위키다타에서 공공 기물 파손 행위를 영구화하려는 최근의 실수도 도움이 되지 않는다.enwp 커뮤니티가 위키다타가 앞으로 유용하게 쓰일 수 있도록 하는 것에 대해 좋게 생각한다면, 그 신뢰가 하원이 성취한 것에 도달할 때까지, 우리는 무엇보다도 포인트 2가 필요하다.현장 외부 통제에 대한 현지 통제를 디폴트하는 것이 필요하며, 기술 통제를 미분해함으로써 직접 또는 기정사실로서 로컬 통제를 제거하는 하향식 정책은 실행 가능성이 낮다.만약 위키다타가 수년 동안 그들 자신의 사업을 안정적으로 돌볼 수 있는 능력을 증명할 수 있다면, 지역 공동체는 지금 하원과 함께 일하는 것처럼 그 지역 통제권의 일부를 그들에게 넘겨주는 것에 대해 더 기분이 좋아질 것이다.그러나 오늘날에는 그런 일이 있을 수 없고, 지역 재정의가 단순하고, 건실하고, 디폴트하지 않으면 일어날 수 없다. --Jayron32 17:32, 2017년 12월 12일 (UTC)[
- "영어 위키백과 편집자들은 설명을 효과적으로 채우고 감시할 수 있는 도구를 가지고 있어야 하며, 당신은 그것을 이치에 맞는 시간표에서 가질 필요가 있다."계속 토론을 지연시키고 오해를 불러일으키는 코멘트(항상 같은 방향으로, 실제 오해에 이상하고 고의적인 방해처럼 보이는)로 인해 이 일을 하면서 수개월을 허비했다.마법의 단어만 알려주면, 우리는 설명을 감시할 수 있는 도구를 가지고 있다. 최근의 변화들, 감시 목록, 페이지 기록들, 그리고 세미나 완전 보호 같은 도구들.우리는 이러한 변화를 구체적으로 확인할 수 있는 필터를 만들 수도 있다.우리는 그것들을 채우기 위해 봇을 만들 수 있다.처음부터, 여러분과 함께 이런 것들을 논의하던 모든 사람들 또는 거의 모든 사람들이 이런 것들을 제안하거나 진술했는데, 여러분만이 장애물을 만들고, 존재하지 않는 이러한 해결책들을 가지고 문제를 찾아내는 것이었습니다."다음 주에 위키다타 팀과 순찰 및 절제 도구 구축에 대한 진척상황에 대해 이야기 할 예정"이라고 말했다. 비록 이것이 일반적으로 매우 필요한 사항임에도 불구하고, 이 논의와 완전히 무관하다.위키다타 설명을 순찰하고 절제하는 것은 우리가 하지 않을 것이다; 우리는 ENWIKI 설명을 순찰하고 온건하게 할 것이다. 그리고 우리는 그렇게 할 수 있는 도구를 가지고 있다. (설명서가 데스크톱 버전에 표시될지 아닐지는 모르지만, 이것은 사용자 선호도가 가장 좋을 수 있지만, 당신이 의미하는 것은 아니다.)패배한 전투는 그만하고 대신 실제로 결정되고 필요한 것은 계속 진행하십시오.프람 (대화)17:54, 2017년 12월 12일 (UTC)[
- 나는 지금 여기 있는 커뮤니티, WMF 제품 팀, 위키다타 팀과 이야기를 나누고 있는데, 위키피디아 편집자들에게 당신이 필요로 하는 이 설명들에 대한 통제권을 주고 의미 있는 시간 동안 많은 설명을 블랭킹하지 않도록 하는 타협을 시도하고 있다.그것은 시간이 걸리는 과정이며, 나는 여전히 그 그룹들과 함께 일하고 있다.나는 네가 이것에 대해 나를 믿거나 믿을 이유가 별로 없다는 걸 알아.그냥 하는 소리야. -- 대니H (WMF) (토크) 18:02, 2017년 12월 12일 (UTC)[ 하라
- 프람, 여기서 '우리' '우리' 등을 다소 자유롭게 말하고 있는 겁니다.특히 자신의 견해를 동시에 전달할 때는 여기 있는 모든 편집자를 대변하지 마십시오.우리가 RfC를 가지고 있는 이유가...고마워요.마이크 필 (토크) 21:11, 2017년 12월 12일 (UTC)[
- 걱정 마, 내가 대신 말하는 게 아냐.그러나 우리(엔위키)는 이미 RfC를 가지고 있었고, 거기서 나온 합의(그리고 현재 이 RfC에서의 합의는 무엇인가) 나는 옹호하고 있다.우리가 RfC를 가지고 있는 데는 이유가 있고, 우리들 중 몇몇은 RfC의 결과를 존중한다.프람 (토크) 22:28, 2017년 12월 12일 (UTC)[
- 네가 나를 대변하지 않는 것은 다행이지만, 왜 나를 제외한 모든 사람들을 대변하려고 하는 거니?어떤 합의점을 말하는 겁니까? 이 RfC는 아직 가동 중인데 (!투표 섹션의 이러한 논쟁에 잠재적 참여자들이 겁을 먹고 있는 것이 아닌가 걱정되지만)내가 무례하다고 무슨 양해를 구하고 있는 거야?마이크 필 (토크) 22:40, 2017년 12월 12일 (UTC)[
- FWIW, 프람이 확실히 나를 대변한다.제임스 (/)talkcontribs 23:24, 2017년 12월 12일 (UTC)[
- 귀하가 해결책이 비 Wikidata 버전으로 되돌리지 않고 템플릿 사용을 거부된 템플릿과 동일한 /Wikidata 하위 페이지로 봇 이동했을 때 WHS RfC의 결과를 존중하지 않았던 것처럼, 이에 대한 이전 RfC의 결과에 대해서는 별로 신경 쓰지 않는 것 같다.기본적으로 enwiki에서 Wikidata 사용을 옹호하는 것과 RfCs를 존중하는 것 중 하나를 선택해야 할 때, 당신은 후자보다 전자를 더 많이 사용한다.프람 (토크) 07:53, 2017년 12월 13일 (UTC)[
- 네가 나를 대변하지 않는 것은 다행이지만, 왜 나를 제외한 모든 사람들을 대변하려고 하는 거니?어떤 합의점을 말하는 겁니까? 이 RfC는 아직 가동 중인데 (!투표 섹션의 이러한 논쟁에 잠재적 참여자들이 겁을 먹고 있는 것이 아닌가 걱정되지만)내가 무례하다고 무슨 양해를 구하고 있는 거야?마이크 필 (토크) 22:40, 2017년 12월 12일 (UTC)[
- 걱정 마, 내가 대신 말하는 게 아냐.그러나 우리(엔위키)는 이미 RfC를 가지고 있었고, 거기서 나온 합의(그리고 현재 이 RfC에서의 합의는 무엇인가) 나는 옹호하고 있다.우리가 RfC를 가지고 있는 데는 이유가 있고, 우리들 중 몇몇은 RfC의 결과를 존중한다.프람 (토크) 22:28, 2017년 12월 12일 (UTC)[
- 프람, 그 절충안들이 내가 우리더러 의논하라고 요구하는 거야.네가 그 이야기를 꺼내서 기뻐, 그건 우리가 할 수 있는 대화야.나는 다음 주에 위키다타 팀과 순찰 및 절제 도구 구축에 대한 진행 상황에 대해 이야기 할 것이다.우리는 Wikidata 팀이 무엇을 선택했는지 직접 통제할 수는 없지만, 나는 그들과 함께 짧은 설명을 효과적으로 감시할 수 있는 방법이 계속적으로 부족한 것이 이 대화, 이 커뮤니티, 그리고 전체적인 특징에 어떤 영향을 미치고 있는지에 대해 이야기하고 싶다.영어 위키백과 편집자들은 설명을 효과적으로 채우고 감시할 수 있는 도구를 가지고 있어야 하며, 당신은 말이 되는 타임라인에 그것을 가지고 있어야 한다.더 많은 사람들과 대화하고 어떻게 하면 그렇게 될 수 있는지 계속 연구해야겠어.당신이 제안하는 과도기에 대해 내부적으로 사람들과 이야기할 겁니다. -- 대니H (WMF) (토크) 16:04, 2017년 12월 12일 (UTC)[
- 8개월여 동안 실제로 얼마나 많은 사람들이 모바일 뷰에서 묘사가 불가능하다고 불평했는가?"이러한 설명을 사용하는 편집자 및 편집자": 어떤 편집자가 될 것인가?어쨌든, 기본적으로 당신은 그 결과가 마음에 들지 않는 한, 내용 결정에 간섭하지 않을 것이다.그러나 동시에 당신은 당신의 특징을 순찰하고 통제하는 데 필요한 도구를 제공하는 것을 귀찮게 할 수 없다(그리고 당신의 첫 번째 요점은 이 마법의 단어가 살아서 어쨌든 요청된 대로 작동될 때 오히려 무트다).그건 당신이 Flow, Gather와 (개인적으로 그리고 WMF처럼) 했던 것과 같은 겁니다. 그것은 바뀌지 않고, 개선되고, 점진적으로 받아들여지지만, 단순히 화염에 휩싸인 채로, 동시에 많은 불필요한 마찰과 나쁜 피를 만들어내면서.너 정말 그 안경에서 배운 거 있어?여기 있는 대부분의 사람들은 실제로 설명을 듣고 싶어하며, 이러한 것들은 상당히 빠르게 채워질 것이다(대략 현재 위키다타에서 제공되는 것보다 더 높은 비율로).그러나 우리는 필요한 곳에 그것들을 채울 것이고, 우리가 그들이 비어있기를 원하는 곳에 그것들을 비워둘 것이다.당신은 지난 몇 달 동안 타협안을 제안할 수 있었는데, 여기서 "마술어 없음" 또는 "설명어 없음"은 "위키다타 설명을 받아들인다"를 의미하고, 다른 하나는 "설명어 없음"을 의미할 것이다.당신은 "마법적인 단어를 설치한 후, 우리는 3개월의 과도기 기간을 가지고 엔위키에 설명이 채워지는지 볼 것이다; 그 후에 우리는 "위키다타에서 추출 desc"를 완전히 무력화시킬 것이다."라고 제안할 수 있었다.대신 당신은 WMF가 최종 결정권을 가지고 있고 WMF가 사전 승인한 기사(또는 기사 그룹)의 목록이 아니면 공백이 허용되지 않을 것이라고 주장했다.왜? 모르겠어.WMF가 너무 귀찮아서 독자들이 무슨 일이 있어도 설명을 받아야만 한다면(아무리 많은 기사들은 애초에 위키다타 설명이 없더라도), 이런 것들을 감시할 사람들을 고용해서 돈을 주고 노골적인 BLP 위반 같은 것이 몇 시간이나 며칠 동안 남아 있지 않도록 해야 한다.그러나 우리의 의사에 반하여 그리고 그것을 순찰하는 데 어떤 심각한 도움도 주지 않고 우리에게 비엔위키 콘텐츠를 보여주도록 강요하는 것은 용납될 수 없는 일이다.프람 (토크) 15:44, 2017년 12월 12일 (UTC)[
- 좋아... 지금부터 대니H, 사용자:마이크 필 및 사용자:Fram, 이 RfC에 더 이상 참여하지 마십시오.너희 셋과 너희의 의견 불일치가 다시 논의에서 완전히 지배하고 있어. Arbcom 사건이 경고했던 바로 그 문제 말이야.이것은 이 논의의 결과에 도움이 되지 않는다.—DJ (대화 • 기여) 14:24, 2017년 12월 13일 (UTC)[
- #3 – 위에서 말한 이유로 가장 이치에 맞는 말이다.나는 오직 다음과 같이 말하면서 3번을 수정하겠다.보호 페이지를 의미하거나 중재 집행의 대상이 되는 (해당되는 경우) 페이지를 의미할 수 있는 반달리즘으로부터 능동적으로 보호되는 모든 페이지에 대한 현지 설명을 즉시 작성하십시오.-Carwil (대화) 18:02, 2017년 12월 13일 (UTC)[
- #1 이 전체적인 생각은 단지 다소 작은 문제에 대해 복잡성을 가중시키고 있다.데이터 중복이 적을수록 좋다.우리는 위키미디아의 힘을 다른 모든 프로젝트에 분산시키기 보다는, 더 많은 프로젝트 추가 개요를 따르는 방법에 초점을 맞추고 위키피디아의 변화를 따르는 더 나은 도구에 초점을 맞춰야 한다.협력과 공유는 통제, 반항, 데이터 복제가 아닌 이들 프로젝트의 본질이다.TomT0m (대화) 16:34, 2017년 12월 15일 (UTC)[
- 대니H당 1위.또한 우리는 위키다타의 데이터를 절대 표시하지 않도록 보호된 기사를 구성할 수 있다.이 옵션을 사용하면 Wikidata가 해당 기사에 대해 보여주는 종류의 설명이 마음에 들지 않을 때 특정 기사에 대한 설명으로 ""를 넣는 봇을 실행할 수 있다는 점에 유의할 필요가 있다.크리스티안클 (토크) 2017년 12월 17일 (UTC) 15:29 [
- 설명을 위해, 우리가 어떻게 이것이 이루어질 수 있는지 아는 것에 근거하여 위키다타의 데이터를 절대로 표시하지 않도록 보호 기사를 구성할 수 있다는 당신의 주장과, 그것이 합리적으로 하기 쉬운 일이라는 것 또는 추측이 맞으십니까?WMF가 모바일 디스플레이의 데이터를 어떻게 사용하고 있는지 기억하십시오.나는 그들이 어떻게 그것을 하는지 모르기 때문에, 위키백과 쪽에서 차단하는 것이 얼마나 쉽거나 그렇지 않을지 예측할 수 없기 때문에 묻는다.일반적인 논리는 그것이 그렇게 쉽지 않을 수도 있고, 이미 행해졌을 수도 있다는 것을 암시한다.· ···피터(사우스우드):(talk) 04:44, 2017년 12월 18일 (UTC)[
- 마법 키워드가 활성화되지 않으면 쉽게 수입을 막을 수 없다.그러나 이 기능이 구현되면 보호되는 모든 기사 또는 기사 클래스가 Wikidata를 가져오지 않아야 하며 사용자에게 위키다타 설명 대신 ''을 보여주는 것이 더 낫다는 믿음이 있는 기사 클래스의 모든 기사에 대해 "마법 키워드 = ''''를 생성하는 봇을 꽤 쉽게 실행할 수 있을 것이다.
- 게다가, 나는 WMF가 위키백과가 일단 기사를 반보호하고 나면 그 기사가 위키다타에서 파생된 정보를 표시하는 것을 중단하는 제한을 하드코드로 해야 한다고 생각한다.그렇게 되면 WMF에 대한 작업이 좀 필요하겠지만, 만약 그들이 타협을 얻기 위해 그렇게 해야 한다면, 나는 그들이 그 보증을 기꺼이 제공할 것이라고 생각한다.크리스티안클 (대화) 2017년 12월 18일 12시 31분 (UTC)[
- 나는 WMF가 보증을 제공하는 것을 보면 용기를 얻기도 하고 조금 놀라기도 할 것이다.지금까지 그들은 우리가 요청한 어떤 것에도 어떤 약속도 하지 않으려고 매우 조심했다.보면 믿겠다.나는 기사가 보호되는지 반보호인지를 확인하는 필터를 코딩하고 짧은 설명이 표시될 때마다 실행할 수 있을 정도로 빠르고 효율적인 위키다타 설명이 사용되는지 제어하기 위해 그것을 사용하는 복잡성에 대해 개인적인 지식이 없다.하지만 나는 이것이 WMF가 피하고 싶어하는 추가적인 오버헤드라고 추측할 수 있다.그러한 추가 소프트웨어를 요구하는 것은 또한 잘못된 방향으로의 주요한 단계가 될 마법의 단어 구현을 지연시킬 수 있다.이것은 간단하고 효율적이어야 하므로 버그를 최소화하고 속도를 최대화할 것이다.빈 문자열로 표시되는 빈 문자열 파라미터를 입력하는 것은 쉽고 간단하며 복잡한 추가 코딩이 필요하지 않다.이것은 지역적으로 짧은 설명이 없는 기사를 보호하는 관리자가 할 수 있다.· ···피터(사우스우드):(talk) 16:33, 2017년 12월 18일 (UTC)[
- 설명을 위해, 우리가 어떻게 이것이 이루어질 수 있는지 아는 것에 근거하여 위키다타의 데이터를 절대로 표시하지 않도록 보호 기사를 구성할 수 있다는 당신의 주장과, 그것이 합리적으로 하기 쉬운 일이라는 것 또는 추측이 맞으십니까?WMF가 모바일 디스플레이의 데이터를 어떻게 사용하고 있는지 기억하십시오.나는 그들이 어떻게 그것을 하는지 모르기 때문에, 위키백과 쪽에서 차단하는 것이 얼마나 쉽거나 그렇지 않을지 예측할 수 없기 때문에 묻는다.일반적인 논리는 그것이 그렇게 쉽지 않을 수도 있고, 이미 행해졌을 수도 있다는 것을 암시한다.· ···피터(사우스우드):(talk) 04:44, 2017년 12월 18일 (UTC)[
- #1 대부분의 경우, 대부분의 목적을 위해 위키다타 서술은 괜찮다.#1은 특별한 민감성이 있는 경우에 대해 감각적인 과대포장 메커니즘을 제공한다.제힐드 (대화)20:55, 2017년 12월 17일 (UTC)[
- 당신이 이 예측을 근거로 합리적으로 확실한 분석을 하지 않는 한, 그것은 추측이다.그러나 마법의 단어를 통해 위키다타 묘사를 무시하는 것은 쉬울 것이기 때문에 장기적으로는 별 차이가 없을 것이다.550만 명 중 어느 비율을 해야 하느냐에 따라 얼마나 지루할 것인가에 대한 문제일 뿐이다.· ···피터 (사우스우드) : 04:44, 2017년 12월 18일 (UTC)[
- #2 알제의 말에 동의한다.가장 센스 있는.Wikidata 항목은 필요한 경우 초기에 가져올 수 있다.같은 지역, 같은 지역, 같은 지역, 같은 지역, 같은 지역, 같은 정책을 유지한다면 가장 쉽다.나는 Wikidata에 관한 것들을 가지고 있는 것의 이점이 정말로 보이지 않는다 - 그 설명은 모든 언어에 대해 다르다.Galobtter (pingo mio) 11:54, 2017년 12월 19일 (UTC) Peter Southwood는 훌륭한 실용적 포인트를 만든다.
중간조치로, 일
을 더빨리 진행시키기 위해, 나는 처음에 위키다타 설명
을 빈마법 단어 매개변수의 기본값
으로 표시하는데있어서
어느정도의 가치가 있다고 본다. 왜냐하면 그것
은 WMF가이미
하고있는 것과 다를
바없기 때문
이다.갤럽터 (pingo mio) 11:58, 2017년 12월 19일 (UTC) 부록, #5는 기본적으로, 그렇다.중요한 것은 결국 그것이 여기에 있다는 것이다.갤럽터 (pingo mio) 07:21, 2018년 1월 10일 (UTC)[ 하라
- 갤럽터-위키다타는 각 언어(또는 적어도 위키백과와 각 언어)에 대해 별도의 설명을 유지하는 데이터 구조를 가지고 있다.--카르윌(토크) 15:23, 2017년 12월 19일(UTC)[
- 나도 알아, 내가 하는 말은 왜 그 언어 위키백과에만 유용할 때 그 모든 것을 가지고 있느냐는 거야.Wikidata에 대한 기타 데이터는 위키피디아에서 유용하다 - 원시 숫자, 언어 링크 등 Galobtter (pingo mio) 15:27, 2017년 12월 19일 (UTC)[
- 갤럽터-위키다타는 각 언어(또는 적어도 위키백과와 각 언어)에 대해 별도의 설명을 유지하는 데이터 구조를 가지고 있다.--카르윌(토크) 15:23, 2017년 12월 19일(UTC)[
- 2 WMF는 위키다타는 어떤 기사에서 그것이 얼마나 좋은지에 상관없이 결코 사용되어서는 안 되기 때문에, 그 사이트를 순찰하고 그것에 대해 뭔가를 할 수 있는 충분한 권한을 가지고 있었지만, 대신에 그들은 계속해서 요청을 무시해 왔기 때문에 우리가 무언가를 할 때가 되었다. 어쨌든, 우리가 무언가를 할 때가 되었다. 어쨌든 누군가 공란을 덧붙인다면 더 좋다.바보 같은 묘사는 그들이 되돌아갈 것이고 의심의 여지없이 아무도 추가될 것이다.–Davey2010 23:31, 2017년 12월 27일 (UTC)[
- 2와 1의 조합: Wikidata 설명은 꺼지지만(약간 실행은 제외) 감시 목록에서 변경 사항만 발생할 수 있을 때 표시될 수 있다.Doc James (대화 · 기여 · 이메일) 06:24, 2017년 12월 30일 (UTC)[
- 2, 이런 종류의 내용에 대한 완전한 편집 통제가 필요하기 때문이다.대안으로 5번.토니 탄 · 토크 04:21, 2018년 1월 17일 (UTC)[
- 나는 공공 기물 파손 행위가 검색 결과의 간략한 설명이 어떻게 표시되는가에 영향을 미쳐서 1위에 투표하는 것을 꺼리게 한다고 확신한다.사실, 아무런 설명도 보이지 않는 것은 덜 알려진 제목/이름으로 덜 알려진 주제를 찾는 독자들에게 덜 도움이 될 것이다.그럼에도 불구하고 나는 중앙통제에 대한 지역통제를 선호하는 공감대를 본다.#5도 좋지만 위키다타 설명을 끄면 도움이 되지 않는다.오히려 수동으로 또는 봇에 의한 현지 작업이 너무 많을 것이다.#2가 되든 #5가 되든, 현지 서술은 (어떤 식으로 보호되지 않는 한?) 위키다타가 파괴된 것과 같은 방식으로 파괴될 것이다.자, 그럼 다른 사람당 2위를 차지합시다.또한 #4 - 사용자 환경설정을 통해 #1 및 #2 옵션을 사용하되 #2를 기본 선택으로 사용하는 것은 어떠한가?Wikidata 설명을 사용하려면 "사용자 기본 설정" 옵션을 제공하십시오.조지호(토크) 12시 23분, 2018년 1월 24일 (UTC)[
빈칸 채우기: 옵션 #5
Pinging everyone who !voted in the What to do with blanks discussion: Francis Schonken, Peter (Southwood), TheDJ, Fram, DannyH (WMF), Mike Peel, Sandstein , James, Dank, Carwil, TomT0m,ChristianKl, Jheald, Galobtter, Davey2010, Doc James.
토론을 단순 옵션 1 대 옵션 2 결과로 본다면 상황은 오히려 불쾌하다.내가 집계한 바에 의하면 현재 2위에 다수가 있지만, 그것이 정확히 압도적이지는 않다.반면에 #1은 상당한 소수 지지층을 가지고 있고, WMF는 우리가 새로운 설명으로 다시 채우기 전에 설명이 대량으로 공개될 가능성에 대해 강하게 반대한다.
원래 RFC 선택에 제시되지 않았던 대안에 대한 실질적인 논의가 있었다: #1에서 #2로의 전환.초기 단계에서는 현지 서술이 부족한 기사는 위키다타로부터 설명을 계속 끌어낼 것이다.우리는 새로운 설명 키워드를 배치하고 Wikidata 설명을 무시하는 로컬 설명을 작성하기 시작한다.일단 현지 설명의 충분한 기반을 구축한 후에는 Wikidata 설명을 완전히 끄면서 전환을 마무리한다.
나는 위의 많은 사람들이 이런 종류의 타협에 대해 위에 지지의 뜻을 표했다고 믿는다.반대편에 있는 사람들은 반대되는 이유로 이것을 이치에 맞지 않는다고 생각할 수도 있지만, 나는 모든 사람들이 협력적인 타협점을 만들기 위한 노력으로 이 계획을 고려하기를 바란다.알제 (대화) 16:24, 2018년 1월 6일 (UTC)[
- 나는 전환이 어떻게 이루어지든 별로 개의치 않는다. - 주된 목표는 결국 엔위키에 모든 것을 걸고 위키다타에 거의 의존하지 않거나 전혀 의존하지 않는 것이다.갤럽터 (pingo mio) 16:58, 2018년 1월 6일 (UTC)[ 하라
- WMF가 Wikidata 설명을 끄기 위해 엄격한 임시 마감일을 약속하는 한 나는 마지못해 전환을 지지할 것이다.제임스 (/)talkcontribs 18:06, 2018년 1월 6일 (UTC)[
- 그래, 나는 이 타협안을 받아들일 것이다.위키피디아 사람들이 현지 설명이 적절하다고 판단할 때 WMF가 꺼지는 한, 장기적으로는 별로 중요하지 않다.위키피디아 사람들이 설명을 채우는 것은 위키피디아 사람들의 몫이 될 것이다.Wikidata 설명을 더 빨리 종료하고 싶은 사람은 짧은 설명을 더 추가함으로써 이러한 일이 일어나도록 할 수 있다.· ···피터(사우스우드) : 2018년 1월 6일 18:11, (UTC)[
- 그것은 여전히 나에게 시간 낭비처럼 보인다.Wikidata 설명을 사용하고 거기서 개선하십시오.마이크 필 (토크) 2018년 1월 6일 (UTC) 19:05 [
- 아래에서 논의한 바와 같이, WMF 계획은 enwiki에 대한 200만개의 비빈칸적 짧은 설명이 있을 때 Wikidata-fallback에서 완전한 enwiki 제어로 전환하는 것으로, 이는 위키다타에 대한 기존 설명의 수와 대략 비교가 된다.그렇게 하면 이러한 설명을 사용하는 독자와 편집자가 갑자기 기능이 저하되는 것을 눈치채지 못하도록 하는 데 도움이 될 것이다. -- DannyH (WMF) (토크) 19:16, 2018년 1월 6일 (UTC)[
- 위에서 인용한 200만 건에 대해 어떠한 합의도 본 기억이 없다.· ···피터 (사우스우드) : 15:22, 2018년 1월 7일 (UTC)[
- 내가 이것에 대해 더 많이 생각할 때, 우리가 우리의 watchlist에 Wikidata의 한 아이템을 등장시킬 수 있다면 정말 더 쉬울 것이다.나는 단순히 WD를 계속 사용하는 것을 지지하지 않을 것이다.
- 또한 위키백과 본문 내의 짧은 정의를 희망하고 로그인한 사람들을 위해 보여주는 것이 좋을 것이다.Doc James (대화 · 기여 · 이메일) 06:51, 2018년 1월 7일 (UTC)[
- 그렇다면 그것이 디폴트(채무불이행)가 되어야 한다-그것만이 그것을 보는 동일한 양의 사람들을 얻을 수 있는 유일한 방법이다.또한 엔위키에서 편집할 때 어딘가에 나타나지만 위키다타에 저장되어야 한다.그것은 현재 어디에 저장되어 있는지 잘 알려져 있지 않다. 대부분의 사람들이 그들이 설명을 바꿀 수 있는 곳을 편집하는 것을 알아야 한다.그렇다면 어느 정도 타당하다.반대는 그들을 통제하는 엔위키일 것이다.갤럽터 (pingo mio) 07:00, 2018년 1월 7일 (UTC)[ 하라
- @Doc 제임스:우리는 이미 반은 enwp watchlist에서 Wikidata 편집을 보기 위해 Preferences -> watchlist -> watchlist에서 Wikidata 편집을 보기 위해 그리고 이 javascript는 기사 맨 위에 있는 wikidata 설명을 보여주기 위해 있다.만약 우리가 이 무의미한 마법 단어 대신 그 기능성을 향상시키는데 개발자 시간을 쓴다면 훨씬 더 이치에 맞을 것이다.고마워요.마이크 필 (토크) 07:58, 2018년 1월 7일 (UTC)[
- 아 정말 멋진 사용자 스크립트.켰어.Doc James (대화 · 기여 · 이메일) 08:05, 2018년 1월 7일 (UTC)[
- 그 대본은 꽤 괜찮다. 하지만 사람들이 공공 기물 파손을 발견할 수 있도록 디폴트(또는 편집 시 최소한 어디든 보여주어야 한다)가 필요하다.갤럽터 (pingo mio) 08:09, 2018년 1월 7일 (UTC)[ 하라
- Wikidata에 대한 설명을 유지하면 다른 프로젝트의 통제와 정책을 유지할 수 있다.영어 위키백과가 위키다타에 콘텐츠가 될 수 있는 것에 대한 정책을 부과한다면 위키다타에게 불공평한 일이다.위키백과 기사에 특정된 텍스트를 위키백과로 옮기는 것은 그 지렁이를 피할 수 있다.· ···피터(사우스우드):(talk) 15:22, 2018년 1월 7일 (UTC)[
- 워치리스트에 있는 것만으로는 충분하지 않아.우선, 우리는 다른 위키다타 변화도 감시할 필요가 있는데, 우리의 글에 위키다타를 디랙틱하게 사용하는 것이 허용되는 한(인포박스, "공식 웹사이트"와 같은 템플릿, 권한 통제) 그래서 우리는 우리의 감시목록에 기술만 있는 것이 아니라 다른 것들(그리고 현재와 오랫동안 이미 관련이 없는 창)도 가지고 있을 것이다.es 또한 일부 관련 항목이 누락되어 있는 동안).그것은 페이지 기록에도 있어야 하고, 즉시 (지금은 종종 우리의 워치리스트에 나타나기 전까지 몇 시간, 몇 시간씩 지연이 필요할 것이다.그리고 Wikidata가 우리의 블록과 보호를 우회할 수 있게 해주듯이 보호와 차단 문제가 있다.마지막으로, 이러한 설명은 내부 Wikidata용으로도 사용되지만, 이러한 설명은 우리의 목적(예: "Wikimedia list" 설명 또는 사용할 Q 번호에 대한 조언을 포함하는 설명)과 너무 자주 충돌한다.엔위키와 위키다타는 정책, 관행, 목적이 다른 두 개의 다른 세계인데, 강제적으로 혼합하는 것은 좋지 않은 생각(현재와 장기적으로 볼 때)이다.프람 (토크) 10:11, 2018년 1월 8일 (UTC)[
- 아래에서 논의한 바와 같이, WMF 계획은 enwiki에 대한 200만개의 비빈칸적 짧은 설명이 있을 때 Wikidata-fallback에서 완전한 enwiki 제어로 전환하는 것으로, 이는 위키다타에 대한 기존 설명의 수와 대략 비교가 된다.그렇게 하면 이러한 설명을 사용하는 독자와 편집자가 갑자기 기능이 저하되는 것을 눈치채지 못하도록 하는 데 도움이 될 것이다. -- DannyH (WMF) (토크) 19:16, 2018년 1월 6일 (UTC)[
- WMF 괴롭힘과 선택적 독서에 의해 강요된 어떤 "보상"에 반대하라.엔위키는 WMF 프람 (토크) 10:15, 2018년 1월 8일 (UTC)[ 이 아닌 위키다타 설명의 자동 사용을 언제 끌지 결정해야 한다.
- 나는 원래의 선택을 고수한다.—DJ (대화 • 기여) 11:58, 2018년 1월 8일 (UTC)[
- 나는 여전히 이것에 대해 마이크 필의 의견에 동의한다: WP 편집자들의 시간을 가장 잘 활용하는 것은 위키다타에도 잘 나타나는 좋은 설명을 하는 것이다.그리고 WMF 개발자의 시간을 가장 잘 활용하는 것은 en.wp를 위한 특별한 해결 방법을 만드는 것이 아니라 Wikidata에 저장된 짧은 설명 필드를 모든 위키피디아들이 모니터링하고 보호할 수 있는 도구를 만드는 것이다.그러나 시스템이 있을 가능성이 높으므로 (1) WMF는 보호된 페이지와 가장 많이 보는 페이지(기술적으로 어려울 수 있음)에 대한 편집 내용을 즉시 동결하는 방법을 찾아야 한다. 또는 en.wp 커뮤니티는 이러한 설명을 쓰기 위해 드라이브를 해야 하며, 마법을 사용하여 en.wp에 둘 다 삽입해야 한다.word and on Wikidata. (2) 마법의 단어 시스템에는 "의도적인 빈칸"이 포함되어 있어야 하며, 이는 아직 쓰지 않은 빈칸과는 다르다.WMF는 이러한 의도적인 공백들을 200만개의 목표의 일부로 간주해야 한다.커뮤니티 구성원은 설명이 이미 명확하기 때문에 페이지에 아무 것도 추가하지 않을 때만 이 시스템을 사용해야 한다(3) 목록 및 설명 페이지들은 상황에 따라 처리해야 한다(예: "Wikipedia 설명 페이지"가 VisualEditor에는 나타나지만 페이지의 모바일 또는 바탕 화면에는 나타나지 않는 것이 타당할 수 있다).-카르윌 (대화) 2018년 1월 9일 19시 15분 (UTC)[
- 12개월 동안 보 스카브러에 대한 설명은 "클렘슨이 그에게 'l'을 주었다"는 것이었다. - 내가 위키다타 설명을 보여주는 대본을 사용하여 보기 전까지는 14만 번 이상 (무명하지 않은) 조회되었다.여기 봐.마법의 단어로 저장되지 않은 반달리즘을 탐지할 수 있도록 100% 확실하게 엔위키에서 볼 수 있어야 한다.기사의 역사에서 볼 수 있어야 하며 프람이 지적하는 바와 같이 보호, 블록 등의 문제도 있다.현재 보안은 무명에 의한 것으로 보이며, 이는 상당히 끔찍하다(그리고 서술이 훨씬 더해질 가능성이 낮다는 것을 의미하기도 한다).나는 enwiki 제어와 같은 이유들 때문에, enwiki에 의한 가이드라인을 가지고 있고 그것을 enwiki에 더 적합하게 만드는 것) 그리고 그것은 마법의 단어 안에 있어야 한다고 생각한다.갤럽터 (pingo mio) 07:29, 2018년 1월 10일 (UTC)[ 하라
기타토론
- 나는 이 모든 것을 이해할 수 없다.누가 이것 좀 설명해 주시겠습니까?히드라 타코즈 (대화) 21:49, 2017년 12월 18일 (UTC)[
- @하이드라 타코즈:위키피디아의 일부 용도는 기사(예: 위키피디아 앱 또는 검색 엔진)에 대한 짧은 설명을 가지고 있다.우리가 이 정보를 어디서 어떻게 얻거나 저장하느냐가 논의되고 있는 것이다.그것을 지키기 위한 논리적인 장소는 위키다타지만 그것에는 약간의 문제가 있다.-저스틴 (코아프))T☮C☺M 18 21:55, 2017년 12월 18일 (UTC)[
- @Koavf Justin 고마워!그렇다면, 어떻게 위키다타는 안전한 장소일까?위키다타는 정확히 무엇인가?히드라 타코즈 (대화) 22:04, 2017년 12월 18일 (UTC)[
- @하이드라 타코즈:위키다타는 위키백과의 자매 프로젝트다:위키지만 이와 같은 백과사전이 아니라 구조화된 데이터를 저장하는 곳이다.만약 여러분이 데이터베이스에 익숙하지 않다면, 처음에는 혼란스러워 보일지도 모르지만 음악가(예: 존 콜트레인)를 상상하고 위키백과에서 우리는 그에 대한 전기를 쓰고 위키쿠테는 그에 대한 인용구를 가지고 있고, 커먼즈는 그에 대한 사진이나 녹음 파일 등을 가지고 있을 것이다.Wikidata는 출생일, 시민권 상태, 서명된 레코드 라벨 등과 같은 개별적인 사실들을 저장할 것이다.위키피디아와 같은 프로젝트를 위한 Wikidata의 내부 기능 중 하나는 주제에 대한 짧은 설명을 저장하는 것이다. 이 경우, "미국 재즈 색소폰 연주자 및 작곡가"와 같은 것이다.-저스틴 (코아프))T☮C☺M 18 22:07, 2017년 12월 18일 (UTC)[
- 명확히 하기 위해:위키다타에 대한 짧은 설명의 기능은 내부 위키다타 기능이다.Wikidata 이외의 Wikimedia 프로젝트에 의해 위키백과 기사명을 표시할 때 사용하기 위한 위키백과 기사의 설명으로 사용하기 위한 것은 아니다.WMF는 현재 이를 최선의 대안(기존의 거의 유일한 0이 아닌 옵션)으로 간주하기 때문에 이 목적으로 사용하고 있다.선택된 기사군 중 어떤 것이 가장 유용할 가능성이 높은지를 사용자가 파악할 수 있도록 도와주지만, 기술하는 데 사용되는 기사의 위키백과 편집자의 직접 통제를 벗어난다는 문제가 있고, 지속적인 반달리즘, 부적절하거나 차선의 서술에 문제가 있으므로 그 의도는 합리적이다.위키다타에서만 편집되고, 일부 위키백과 사람들은 위키다타 기사와 관련하여 공공 기물 파손이 나타나는 것을 막기 위해 위키다타를 편집하고 유지하도록 강요 받는 것을 좋아하지 않는다.또한 짧은 설명은 현재 데스크탑 뷰에서 볼 수 없고, 감시목록에 유용하게 나타나지 않기 때문에 공공 기물 파손은 위키피디아 사람들이 탐지하지 않고 갈 수 있다는 점에서 기술적인 문제도 있다.제안된 해결책은 위키피디아에 대한 간단한 설명을 제공하는 것인데, 위키피디아가 유용할 수 있는 어떤 목적을 위해서든, WMF 개발자들은 그것이 반드시 새로운 "마법적인 단어"에 의해 이루어져야 한다고 말한다. 그것은 내가 이해할 수 있는 한 더 효율적인 템플릿 기능과 같다.마법의 단어가 처음에 빈칸으로 채워졌는지 아니면 Wikidata 짧은 설명으로 채워졌는지 여부는 일단 존재하는 것처럼 장기간에 걸쳐 비교적 중요하지 않다. 위키피디아 사람들은 관련 기사의 위키백과 편집 환경 내에서 편집자들이 필요하다고 느낄 때 짧은 설명을 보고 변경할 수 있다.기사 자체의 일부가 될 것이고, 감시 목록에 변화가 나타날 것이다.· ···피터 (사우스우드) : 08:22, 2017년 12월 19일 (UTC)[
- @Koavf Justin 고마워!그렇다면, 어떻게 위키다타는 안전한 장소일까?위키다타는 정확히 무엇인가?히드라 타코즈 (대화) 22:04, 2017년 12월 18일 (UTC)[
- 이 검색 링크를 클릭하고 검색 상자에 Bar를 입력(입력 누르지 않음)하면 기사 목록이 나타난다.첫 번째 참가 대상은 아마도 바(Bar)가 될 것이다.그 텍스트는 여기서 논의되고 있는 짧은 설명이다.작은 화면의 모바일 사용자를 돕기 위해 해당 설명은 위키백과 앱에서 읽을 때 기사의 맨 위에 나타난다.그것은 모바일 브라우저 보기에도 나타나곤 했다.그것은 Visual 편집기의 링크 툴에 나타나며, 다른 곳에 나타날 수도 있다.그 텍스트는 위키피디아 어디에도 쓰여 있지 않다.그것은 술집을 위한 위키다타 항목에서 나온다.거기서 편집할 수 있다.다른 사람들이 주목했듯이, 위키다타는 위키미디어 가족의 자매 프로젝트다.Wikidata는 그들 자신의 사용을 위해 그러한 기술들을 만들어왔고, 재단은 이 기술들을 여기서 다시 사용하는 것이 편리할 것이라고 결정했다.엔위키 커뮤니티는 우리가 그것이 추가되었고 어떻게 작동하는지 알게 되었을 때 오히려 놀랐다.대부분의 엔위키 편집자들은 그런 설명들을 전혀 보지 못하고, 설사 본다고 해도 누구를 고쳐야 할지 모르는 경우가 많다는 우려가 있다.위키다타 공동체가 공공 기물 파괴 행위를 얼마나 잘 포착하고 고칠 수 있는지에 대한 우려/의견이 있다.설명이 엔위키 정책이나 페이지 보호, 사용자 차단 등의 대상이 되지 않는다는 우려가 있다.위키다타에서 편집(반달리즘, 편파적 편집-전쟁 등)하면 우리가 기사에 올린 페이지 보호를 우회할 수 있으며, 위키다타 관리자가 BLP와 같은 엔위키 정책에 동의하지 않을 경우 설명 편집이 차단될 수 있다.Wikidata-purposes를 위한 설명도 항상 우리의 목적에 가장 적합한 것은 아닐 수 있다.여기서 토론하는 것은 우리 기사 상단에 {{}}주류를 제공하는 소매업소를 설명하고, Wikidata의 설명 대신 그것을 사용하는 것이다.그러면 다른 기사 위키텍스트처럼 설명을 보고, 편집하고, 제어할 수 있다.단점은 EnWiki와 Wikidata는 유사한 목적으로 유사한 설명을 관리하는 병렬 시스템을 가지고 있다는 것이다.알제 (대화) 11시 25분, 2018년 1월 6일 (UTC)[
- @하이드라 타코즈:위키피디아의 일부 용도는 기사(예: 위키피디아 앱 또는 검색 엔진)에 대한 짧은 설명을 가지고 있다.우리가 이 정보를 어디서 어떻게 얻거나 저장하느냐가 논의되고 있는 것이다.그것을 지키기 위한 논리적인 장소는 위키다타지만 그것에는 약간의 문제가 있다.-저스틴 (코아프))T☮C☺M 18 21:55, 2017년 12월 18일 (UTC)[
WMF의 위키백과 호스트 설명 2단계 제안
우리는 위키백과 기고자들에게 짧은 설명에 대한 편집 권한을 부여하는 방법에 대해 오랫동안 논의해 왔다.여기서 해결책에 대한 새로운 접근법이 있는데, 어떻게 생각하시는지 알고 싶다.
첫째, 이러한 접근 방식이 어디에서 발생하는지 파악:
- 영어 위키백과 편집자들은 적극적인 위키다타 편집자가 되지 않고도 데스크탑과 모바일 웹의 짧은 설명을 보고 편집하며 효과적으로 조정할 수 있어야 한다.그렇게 하려면 위키백과 감시 목록과 페이지 역사에 의미 있는 통합이 필요하다.위키다타 팀이 작업하고 있는 특징들이지만, 현재 존재하지 않으며, 시간표도 없다.
- 짧은 설명은 모바일 앱의 독자와 VisualEditor를 사용하는 편집자에게 매우 유용하며, 의미 있는 시간 동안 상당한 수의 설명을 블랭킹하면 그러한 독자와 편집자의 경험에 해를 끼칠 수 있다.
- 영어 위키백과 편집자는 설명이 도움이 되지 않는 페이지를 지정할 수 있는 것을 포함하여 설명을 실제로 채우는 방법에 대한 내용을 결정해야 한다.
그 마지막 포인트가 우리가 한동안 씨름하던 포인트야.나는 설명이 있으면 안 되는 기사 페이지의 예를 묻고 있었는데, 몇 사람이 그 글에 해괴한 구절이 있는 예시를 들고 나왔고, 그 짧은 서술은 그 해괴한 구절에서 나온 정보만 되풀이하고 있었다.몇 가지 예를 들어보자.
- 월터 레만(체조 선수) - 체조 선수
- 반투명(폴리 스티렌 앨범) - Poly Styrene 앨범별 앨범
- EAR(파일 형식) - 파일 형식
나는 위에서 중복이 해롭다고 생각하지 않는다고 말했지만, 몇몇 사람들은 내가 골대를 옮기고 있다고 지적했다. 예를 들자고 한 다음, 그들은 중요하지 않다고 말했다.형식에 대한 내용적 결정을 하려고 했는데, 실제 집필과 절제 작업을 하고 있는 사람이 아니다.공정 지점이다.
그래서 나는 "위키메디아 리스트 페이지"와 "위키메디아 디스컴파일 페이지"를 꺼내고, 또한 그 설명이 그저 모호한 구절을 반복하고 있는 페이지들을 꺼내는 등, 현재 얼마나 많은 유용한 설명들이 있는지 추정해 보고 싶었다.
지난 주, 마이크 필은 1,000개의 무작위 기사와 설명 목록을 만들었고, 이것은 우리가 페이지의 적절한 단면에서 설명의 질을 조사하는 데 도움을 주었다.나는 더 큰 샘플을 원했기 때문에 우리는 10,000개의 기사와 설명을 작성했다.
여기 10,000개의 무작위 기사의 더 큰 표본에서 나온 분류가 있다.이것이 "유용하지 않은" 설명에 대한 나의 현재 정의다.
- 39.82%가 위키다타에 대해 짧은 설명이 없음
- 7.76%는 "위키피디아" 또는 "위키메디아"를 포함하는 설명을 가지고 있다.
- 1.16%는 기사 제목에 불명확한 구절이 있으며, 이는 설명에 완전히 중복된다(위의 링크된 페이지에 표시된 설명/10,000개).
이 두 가지를 종합하면 48.75%가 빈칸/비유용한 설명이 되며 51.25%가 유용한 설명이 된다.
550만 개의 기사를 추론해보면 약 282만 개의 위키백과 기사들이 유용한 설명을 가지고 있다는 것을 알 수 있다. (나는 사람들이 그것에 대해 생각한다면 유용한 것과 그렇지 않은 것의 정의에 대해 계속 반복할 수 있다.)
자, WMF 쪽에서 우리가 피하고 싶은 것은 280만 개의 유용한 설명에서 훨씬 낮은 숫자로 갑자기 전환되는 것인데, 기본적으로 빈칸인 마법의 단어를 만들면 어떻게 될까 하는 겁니다.그렇게 되면 서술에 의존하는 독자와 편집자의 경험에 상처를 줄 것이다.
그래서, 내가 제안하는 해결책은 WMF가 위키백과 편집자들이 설명으로 채울 수 있는 마법의 단어를 만든다는 것이다.
- 1단계: 처음에 설명의 표시는 위키백과에서 주최하는 마법 단어에서 따온 것이지만, 위키백과에서 주최하는 마법 단어가 없거나, 위키백과에서 비어 있는 버전이라면, 위키다타가 주관하는 설명을 보여주는 것으로 되돌아간다.
- 2단계: 대략 280만 개에 필적하는 다수의 기사에 위키백과가 호스팅하는 마법 단어가 있을 때, WMF는 위키백과가 호스팅하는 마법 단어에서만 끌어내는 것으로 전환하고, 우리는 위키다타가 호스팅하는 설명으로 되돌아가지 않는다.그 시점에서 위키백과 편집자들이 공백으로 남겨두는 설명은 실제로 그 사이트에서 빈칸이 될 것이다.
어떻게 280만개의 설명을 만들 것인가에 대한 결정은 위키백과 편집자들에 의해 내려질 것이며, 타임라인은 당신에게 달려 있다.그 과정이 어떻게 전개되는지 보고 싶겠지만, 그건 우리의 과정이 아니에요.우리의 역할은 위키피디아에서 주최하는 설명으로 전환하는데, 그것을 사용하는 사람들이 의미 있는 변질을 알아차리지 못할 정도로 충분한 설명이 있을 것이다.그래서 그런 생각이야.
마지막으로 한 가지 말씀드리고 싶은 것은 WMF를 비롯한 많은 사람들이 WMF를 비롯하여 위키다타와 위키백과의 보다 많은 통합과 상호의존성이 향후 운동의 성장과 성공에 열쇠가 될 것이라고 믿고 있다는 점이다.우리는 Wikidata가 그러한 통합을 현실적이고 실용적으로 만드는 기능을 구축할 수 있도록 돕기 위해 계속 노력할 것이다.
현재 위키다타는 짧은 설명을 보기 쉽고 위키백과에서 온건하게 만드는 작업 기능을 가지고 있지 않다.미래에는, 위키다타 팀이 그러한 종류의 기능을 구축함에 따라, 우리는 두 프로젝트들 사이의 생산적인 상호의존성을 장려하는 방법에 대해 사람들과 계속 이야기하기를 원할 것이다.나는 이 짧은 서술형 문제에 대한 긍정적인 해결이 미래의 대화를 위한 문을 열어두는 데 도움이 되기를 바란다.어떻게 생각하십니까? -- 대니H (WMF) (토크) 00:32, 2017년 12월 22일 (UTC)[
- 이걸 따라가는 데 어려움을 겪고 있어.물론 난 박스에서 가장 날카로운 크레용이 아니니까, 이 제안서를 클리프 노트 버전으로 좀 도와주겠니?충격여단 하베스터 보리스 (대화) 2017년 12월 22일 (UTC) :54 [응답
- WMF는 1만개의 기사와 일부 의심스러운 수학(116/1만개는 명백하게 0.01%는 아니지만 1.16%)을 바탕으로 약 280만개의 엔위키 기사에 유용한 위키다타 설명이 있다고 주장하고 있다. 이를 바탕으로 엔위키가 2.8mi를 채울 때까지 엔위키 기사에 대한 설명이 없을 때 위키다타 설명을 계속 사용할 것이다.마술의 말이때 '엔위키 설명이 없을 때 위키다타 설명 사용'과 스위치는 '엔위키 마법어 설명이 없을 때 빈 설명 표시'로 전원을 끈다.08:09, 2017년 12월 22일 (UTC)
- 너의 계산은 좀 낙관적이다.위에서 설명한 수학 오류와는 별도로, 나는 당신의 샘플 "12. en:독일 국제 학교 뉴욕 - 학교"에서 본다.나는 또한 혼란의 카운트에서는 동일하지 않은 것을 카운트하지 않는다는 것을 알 수 있다. 비록 그것이 디스패치보다 덜 구체적이고 유용하더라도 말이다: " 3. en:윌리엄 맥아두(뉴저지 정치인) - 미국 정치인" 또는 "15. en: Matt Jones(골퍼) - 프로 골퍼"라는 거의 쓸모가 없는 것을 덧붙인다.처음 15개 중 3개는 쓸모없는 설명으로 계산하지 않는 겁니다. 20% 정도 더요.그러면 288만에서 180만 정도...프람 (토크) 08:09, 2017년 12월 22일 (UTC)[
- 그리고 프람의 수학도 여기서 틀렸다.정확히 말하자면, 대니H(WMF)는 116개의 비정보적(복제적) 교리학적 해설을 발견했다.그 중 1197개가 있는데, 그 중 116개는 이미 결함이 있는 것으로 간주되어 나머지 20%를 더하면 116+216=332가 된다.그래서 모체 인용에 대한 잘못된 서술은 전체의 3.32%에 불과하다.아직 절반 정도의 유효 서술에 머물러 있다.(내 관점에서 '프로골퍼'는 '골퍼'보다 '미국 정치인'이 '뉴저지 정치인'보다 덜 유익하다는 것과 같은 방식으로 더 유익하다.)---카르윌 (대화) 2017년 12월 4일, 12월 23일 (UTC)[
- 나는 위에서 언급한 통계 분석이 면밀한 검사를 하지 않고 상당히 많은 수의 유용한 기술들을 주장한다는 Fram의 의견에 동의한다.몇 개가 좋고, 몇 개가 나쁘다는 식의 적색 청어를 논박하는 대신에, 나는 우리가 실제로 처음에 위키다타 설명으로 그 마법의 단어를 채우고, 즉시 위키백과에서 나온 설명만을 보여주는 것으로 바꾸는 것이 더 나을 것이라고 생각한다. 그렇게 되면 우리는 쓰레기를 더 쉽게 치울 수 있고, 그리고 그 안에서 자유로워질 수 있기 때문이다.가능한 한 빨리 기사와 외부적으로 공공 기물을 파손하는 행위. 또한 이 경로는 조건 없이 위키백과에서 설명 문자열을 생성하기만 하면 되기 때문에 코딩을 최소로 필요한 복잡성으로 줄여야 한다. 빈 설명 => 빈 표시, 비어 있지 않은 설명 => 비어 있지 않은 표시. 이것은 버그 발생 확률이 가장 낮은 가능한 오버헤드 중 가장 낮아야 하며, 우리가 더 일찍 고치는 것을 시작할 수 있도록 해야 한다. 위키다타 묘사가 어느 누구도 그것을 개선하는데 방해하지 않을 만큼 훌륭하다면, 그것은 그대로 있을 수 있다. 위키다타에서도 빈 서술은 비어있기 때문에 불이익이 없다. 위키다타에서 복사한 반달리즘은 한 번 삭제된 뒤 모바일과 VE 디스플레이에서 사라진다. 위키다타에서 복사한 쓰레기는 위키피디아에서 볼 수 있고, 더 나은 짧은 설명을 제공하거나, 단순히 삭제함으로써 제거될 수 있다. 위키다타에서 의심스러운 자료를 계속 끌어내는 것보다 위키백과에서 다소 자의적인 수의 비공백 설명이 만들어질 때까지 훨씬 낫다. 일단 매직 워드 구문이 정의되면, 위키피디아 사람들이 승인한 단일 봇이 표시 코드가 완성되기 전에 기사를 채울 수 있다.· ···피터(사우스우드) : 15:01, 2017년 12월 22일 (UTC)[
- DannyH (WMF), 나는 당신의 제안이 내가 여기서 설명한 것에 대한 개선이라고 생각하지 않는다. 그것은 위키백과 콘텐츠에 대한 내부 통제 부족을 부적절하고 유리하지 않게 연장시킨다.····피터(사우스우드):(talk) 15:19, 2017년 12월 22일 (UTC)[
- Pbsouthwood 및 Fram:우리는 복제품에 대해 잡초 속으로 들어갈 수 있지만, 나는 궁극적으로 그것이 그것이 필요로 하는 시간과 일에 대해 많은 명확성을 제공할 것이라고 생각하지 않는다.이것이 우리가 제공할 수 있는 가장 공정한 선택이며, 당신이 개선이 아니라고 한다고 해서 새로운 해결책을 계속 내놓을 수는 없다.결론부터 내야죠. -- 대니H (WMF) (토크) 17:56, 2017년 12월 22일 (UTC)[
- DannyH (WMF), 첫째로 나는 "복제물의 잡초 속으로 들어가라"는 것이 무엇을 의미하는지 알지 못하기 때문에 그것에 대해 더 이상 언급할 수 없다.둘째로, 나는 이 경우에 당신이 "공정"을 어떻게 정의하느냐에 따라, 내가 설명한 것보다 더 공정한 선택이라고 생각하지 않는다.세 번째로, 나는 당신의 선택이 실제로 "솔루션"이라고 생각하지 않는다.부분적인 해결책일 수도 있지절충안은 그렇다. 하지만 다른 대부분의 옵션들도 그렇다.나는 네가 또 요점을 놓치고 있다고 생각한다.위의 제 제안을 읽어보시고, 일괄해고 대신 기술적 문제가 어디에 있는지, 어떤 것인지 설명하십시오.· ···피터 (사우스우드) : 03:40, 2017년 12월 23일 (UTC)[
- 대니, 내가 어디서 "개선이 아니다"라고 말했지?나는 단지 너의 형편없는 계산에 대해 논평했을 뿐이다.어떤 의견도 수락할 수 없으면 이 RfC를 종료하고 WMF가 수행할 작업을 선언하십시오.프람 (토크) 11:11, 2017년 12월 23일 (UTC)[
- 프람과 핍스우드:우리는 몇 달 동안 이것에 대해 이야기해왔고, 나는 너희 둘 다 한 많은 요점들에 동의했어.내가 제안하는 이러한 타협은 WP 편집자들이 설명이 공백이어야 한다고 생각하는 개별 페이지를 통제하면서 위키백과에서 주최하는 완전한 설명을 초래할 것이다.네가 원한다고 한 말이 바로 이거야.내가 당신 쪽에서 요구하는 유일한 절충안은 위키백과 편집자들이 당신이 위키백과 편집자들이 쓰고 싶다고 말한 짧은 설명을 실제로 쓰는 것이다.이게 납득할 만한 절충안이라고 생각하십니까? -- 대니H (WMF) (토크) 22:44, 2017년 12월 23일 (UTC)[
- DannyH (WMF), 당신이 제안하는 타협안은 위키다타를 빈 마법의 단어 디폴트로 해제하는 것에 동의하기 전에 위키다타를 280만개의 설명을 만들도록 요구하는데, 이는 위키피디아가 그들이 선택한 장소에서 편집하는 자원봉사자들에 의해 편집되기 때문에, 반달리즘의 문제가 그 기간 동안 남아 있다는 것을 의미하는데, 이것은 긴 시간일 수도 있다.Fram은 이 숫자의 타당성에 대해 이의를 제기하고, 나는 WMF의 유용한 기능성의 손실 없이 Wikidata를 훨씬 더 빨리 차단할 수 있는 더 간단한 옵션을 선호한다. 당신은 기술적인 이의에 관한 나의 질문에 아무런 회답을 하지 않았으므로, 내가 아무것도 없다고 가정해야 하는가?내가 지금 이탤릭체로 쓴 나의 제안을 읽고 이해해서 네가 더 쉽게 찾을 수 있게 했니?이것은 수사적인 질문이 아니다. 나는 해결책을 찾는 것과 관련이 있을 수 있는 답을 얻기 위해 그들에게 물어본다.억지로 대답하게 할 수는 없지만, 주제를 바꾸는 대신 질문에 대답할 때 토론이 더 원활하고 생산적으로 진행된다는 것을 알게 될지도 모른다.
- 당신의 질문에 대한 대답으로, 아니, 당신이 우리의 질문에 대답하기 전까지는 나는 당신의 제안을 받아들일 수 없는 타협안으로 받아들일 수 없다. 왜냐하면 나는 그 결정을 하는데 중요한 자료가 부족하기 때문이다.하지만, 나는 나 자신을 위해서만 말한다.다른 사람들은 내 의견에 동의하거나 동의하지 않을 수 있으며, 나는 그 합의에 따를 것이다.내가 하고자 하는 것은 가능한 한 확실한 옵션을 얻어 그곳에 도착하게 하는 것이다.나는 또한 여기 있는 모든 정규 위키피디아 사람들이 다 그렇게 하고 있지는 않다고 생각한다.· ···피터(사우스우드):(talk) 16:57, 2017년 12월 24일 (UTC)[
- Pbsouthwood, 네가 위에서 설명한 것은 내가 제안한 범위 안에 절대적으로 들어 있다.위키피디아에서 주최하는 좋은 설명의 수가 그에 필적할 때 우리는 위키다타의 단점을 해제할 수 있다.우리는 마법의 단어들을 어떻게 채울지 결정하지 않을 것이다; 그것들은 위키백과 편집자들이 결정할 수 있는 내용적인 결정들이다.만약 사람들이 기존의 위키다타에 대한 모든 설명을 복사하기를 원한다면, 그것은 설명의 문턱에 도달할 것이고, 우리는 그 시점에서 위키다타 폴백을 끌 수 있을 것이다.그게 당신의 질문에 대한 대답인가? -- 대니H (WMF) (토크) 18:30, 2017년 12월 26일 (UTC)[ 하라
- DannyH (WMF), 그것은 부분적으로 내 질문에 대한 해답이다.위키피디아의 모든 허용 가능한 설명이 이전되었다고 위키피디아에서 결정할 때 WMF가 위키다타 폴백을 끄겠다고 약속한다면, 나는 그 제안을 받아들이겠지만, WMF가 작은 샘플과 의심스러운 분석에 기초하여 임의적이고 제대로 정의되지 않은 숫자를 고집할 계획이라면 그렇지 않다.s. · · · 피터(사우스우드): 19:01, 2017년 12월 26일 (UTC)[
- Pbsouthwood, 네가 위에서 설명한 것은 내가 제안한 범위 안에 절대적으로 들어 있다.위키피디아에서 주최하는 좋은 설명의 수가 그에 필적할 때 우리는 위키다타의 단점을 해제할 수 있다.우리는 마법의 단어들을 어떻게 채울지 결정하지 않을 것이다; 그것들은 위키백과 편집자들이 결정할 수 있는 내용적인 결정들이다.만약 사람들이 기존의 위키다타에 대한 모든 설명을 복사하기를 원한다면, 그것은 설명의 문턱에 도달할 것이고, 우리는 그 시점에서 위키다타 폴백을 끌 수 있을 것이다.그게 당신의 질문에 대한 대답인가? -- 대니H (WMF) (토크) 18:30, 2017년 12월 26일 (UTC)[ 하라
- 프람과 핍스우드:우리는 몇 달 동안 이것에 대해 이야기해왔고, 나는 너희 둘 다 한 많은 요점들에 동의했어.내가 제안하는 이러한 타협은 WP 편집자들이 설명이 공백이어야 한다고 생각하는 개별 페이지를 통제하면서 위키백과에서 주최하는 완전한 설명을 초래할 것이다.네가 원한다고 한 말이 바로 이거야.내가 당신 쪽에서 요구하는 유일한 절충안은 위키백과 편집자들이 당신이 위키백과 편집자들이 쓰고 싶다고 말한 짧은 설명을 실제로 쓰는 것이다.이게 납득할 만한 절충안이라고 생각하십니까? -- 대니H (WMF) (토크) 22:44, 2017년 12월 23일 (UTC)[
- Pbsouthwood 및 Fram:우리는 복제품에 대해 잡초 속으로 들어갈 수 있지만, 나는 궁극적으로 그것이 그것이 필요로 하는 시간과 일에 대해 많은 명확성을 제공할 것이라고 생각하지 않는다.이것이 우리가 제공할 수 있는 가장 공정한 선택이며, 당신이 개선이 아니라고 한다고 해서 새로운 해결책을 계속 내놓을 수는 없다.결론부터 내야죠. -- 대니H (WMF) (토크) 17:56, 2017년 12월 22일 (UTC)[
- '2단계' 솔루션 지원(설명서 작성 및 위키다타 끄기) 또는 위키다타 설명을 복사하고 위키다타를 더 빨리 종료한다.
10k 랜덤 위키다타 설명을 검토한 후 대니가 보인다.H가 위키다타에서 '유용한' 서술 280만 건을 계산한 것은 다소 과대평가된 것이다.0%의 값을 갖는 몇 퍼센트와 무시할 수 있는 값을 가진 다른 몇 퍼센트를 포함한다.그러나 나는 우리 모두가 현지 서술이 위키다타 서술 대신에 믿을 수 있게 대체될 모호한 한계점에 대해 합리적인 융통성을 가지고 있다고 기대한다.알제 (대화) 23:02, 2017년 12월 27일 (UTC)[
- Pbsouthwood와 Alsee:네, 좋네요.그래, 우리는 전환의 문턱을 어떻게 정할지 함께 일할 수 있어.처음에는 페이지마다(5.5m) 설명을 뽑아낼 수 있기를 바랐지만, 질의가 실행되려면 며칠이 걸릴 것이고, 어쨌든 수작업으로 샘플을 훑어보고 싶었다.그래서 무작위 1만 개를 사용한 겁니다.만약 누군가가 어떻게든 더 나은 견적을 얻고 싶다면, 멋지군, 그렇지 않으면 우리는 200만이라는 반올림 숫자를 말하는 거야.아니면 누군가가 그 문턱을 어떻게 판단하는지에 대해 더 나은 생각을 가지고 있을지도 모른다.어떻게 생각하십니까? -- 대니H (WMF) (토크) 21:21, 2017년 12월 29일 (UTC)[ 하라
- 대니H (WMF) 나는 우리가 짧은 서술의 원천으로서 위키다타의 유용성이 효과적으로 소진되었다는 것을 확립하기 위한 합리적으로 객관적인 방법에 동의할 수 있다면, 우리는 어떤 구체적인 숫자에 대해서도 동의할 필요가 없다고 생각한다.어떤 단계에서 위키피디아 사람들은 우리가 합리적으로 실행 가능하고 실제로 유용할 수 있는 짧은 설명들 중 많은 부분을 취했다고 제안할 것이고, 위키다타 폴백의 종료를 요청할 것이다.우리는 전통처럼 내부적인 논의와 합의에 의해 이 점을 확립할 것이다.이 시점에서 나는 WMF가 더 많은 것을 찾아내고 추출하는 노력의 가치가 있다는 것을 통계적으로 납득할 수 있는 증거를 확인하고, 그들을 찾아낼 수 있는 방법 또는 더 이상의 지연 없이 폐쇄를 할 수 있는 방법을 보여줄 것을 제안한다.마지막 몇 가지 유용한 기술들을 뒤지는 것이 셧다운 이후 언제라도 더 노력할 가치가 있다고 생각하는 사람들을 막을 수 있는 것은 아무것도 없다.믿을 만한 증거가 없는 상황에서 특정 숫자에 대해 흥정하는 것으로 이득을 얻는 사람은 아무도 없다.몇 주 또는 몇 달 동안 실제로 짧은 설명을 만들고 전송하는 것은 컷오프 포인트를 추정하는 방법에 대한 더 유용한 아이디어의 광범위한 영감을 불러일으킬 수 있다.· ···피터(사우스우드):(talk) 05:08, 2017년 12월 30일 (UTC)[
- 핍스우드, 나는 우리가 슛을 할 수 있는 어떤 목표가 필요하다고 생각한다.만약 우리가 그들이 그것이 끝났다고 느낄 때 지역사회가 결정할 것이라고 말한다면, 우리는 아무리 몇 달이나 떨어져 있어도 정확히 같은 장소에 있는 우리 자신을 발견할 것이다.우리가 합의할 수 있는 명확한 선이 있었으면 좋겠는데, 그래야 나머지 과정을 원만히 헤쳐나갈 수 있기 때문이다. -- 대니H (WMF) (토크) 19:08, 2018년 1월 1일 (UTC)[
- DannyH (WMF).이 최신 제안에는 두 가지 문제가 있다.
- 무엇이 지금 합리적이고 일반적으로 받아들여질 수 있는 고정된 숫자를 나중에 생각해 내는 것이 더 쉬울 것이라고 생각하는가?
- 통계적 타당성에 대한 일반적으로 받아들일 수 있는 근거나 실제 카운트 없이 신뢰할 수 있는 숫자를 누가 산출할 것인가?지금까지 너의 제안은 순진해 보였다.나는 위키피디아 사람들이 꽤 설득력 있는 증거 없이 당신의 제안을 받아들일지 의심스럽다. 그리고 고정된 번호를 요구하는 것은 당신이다. 그러므로 우리가 받아들일 수 있는 것을 찾는 것은 당신의 부담이다.만약 여러분이 가능한 한 일을 지연시키려 한다면, 이것은 어떤 진보도 돌로 막을 수 있는 매우 효과적인 방법처럼 보인다.· ···피터(사우스우드) : 05:16, 2018년 1월 2일 (UTC)[
- 숫자에 대한 최종 결정이 내려질 때까지 마법의 단어 개발이 지연되지 않는지 확인하십시오.· ···피터(사우스우드):(talk) 05:16, 2018년 1월 2일 (UTC)[
- Pbsouthwood, 우리 둘 다 여기서 성실하게 일하고 있어.나는 10k 랜덤 위키다타 설명 목록을 게시했는데, 내가 280만 건의 유용한 설명에 도달하기 위해 사용했던 방법론에 대한 설명과 함께 게재했다.나는 그 1만 명 리스트에 있는 모든 설명들을 표시해 놓았는데, 그 설명들은 단지 설명문구의 정보를 반복하고 있을 뿐, 그것들을 계산하지 않고 있다.만약 다른 사람이 내가 놓쳤다고 생각하는 것에 표시를 하고 싶다면, 그건 괜찮아. 그리고 내가 견적을 조절할게.
- 우리가 측정하고 있는 것은 부분적으로 판단 호출입니다 -- 혼란스러운 구절의 반복으로 중요한 것은? -- 그래서 스크립트가 정확히 할 수 있는 일은 아니에요.그것은 설명을 듣고 그 판단을 내릴 수 있는 사람이 필요하다.10,000건의 설명을 했는데, 몇 시간이나 걸렸어.나는 더 큰 샘플을 보는 데 더 많은 시간을 할애할 수 없다.
- 숫자에 대한 최종 결정이 내려질 때까지 마법의 단어 개발이 지연되지 않고 있다.우리는 위키다타 묘사를 무시하는 마법의 단어를 만들 것이다.위키다타 설명을 차단하고 위키백과 설명만 빼내는 전환은 우리가 말하는 숫자에 따라 달라질 것이다.기존 서술형 추정치보다 현저히 낮은 200만 서술형을 제안한다. -- 대니H (WMF) (토크) 18:58, 2018년 1월 2일 (UTC)[
- DannyH (WMF), 내 사생활에서 나는 장기간의 세부사항을 돌에 새기는 것을 좋아하지 않으며, 위키 공동체 또한 일반적으로 즉석에서 일을 처리한다.만약 설명이 빨리 입력된다면, 어떤 목표 번호도 크게 중요하지 않을 것이다.만약 일이 너무 느리게 진행된다면, 무슨 일이 일어나고 있는지에 대한 어떤 종류의 조사가 어쨌든 정당화될 것이다.하지만 분명한 목표가 있다면 어떤 사람들은 더 편할 수도 있다는 것을 이해할 수 있다.중요한 거라면 200만 혹은 그보다 이른 시간에 목표물을 잡을 수 있을 것 같아.필요하다면 wikidata 설명을 복사하여 그 목표를 항상 맞출 수 있을 것이다.알제 (대화)18:35, 2018년 1월 5일 (UTC)[
- DannyH (WMF).이 최신 제안에는 두 가지 문제가 있다.
- 핍스우드, 나는 우리가 슛을 할 수 있는 어떤 목표가 필요하다고 생각한다.만약 우리가 그들이 그것이 끝났다고 느낄 때 지역사회가 결정할 것이라고 말한다면, 우리는 아무리 몇 달이나 떨어져 있어도 정확히 같은 장소에 있는 우리 자신을 발견할 것이다.우리가 합의할 수 있는 명확한 선이 있었으면 좋겠는데, 그래야 나머지 과정을 원만히 헤쳐나갈 수 있기 때문이다. -- 대니H (WMF) (토크) 19:08, 2018년 1월 1일 (UTC)[
- 알제, 나는 너의 가장 최근의 분석과 논평에 동의해.···피터 (사우스우드) : 05:08, 2017년 12월 30일 (UTC)[
- 대니H (WMF) 나는 우리가 짧은 서술의 원천으로서 위키다타의 유용성이 효과적으로 소진되었다는 것을 확립하기 위한 합리적으로 객관적인 방법에 동의할 수 있다면, 우리는 어떤 구체적인 숫자에 대해서도 동의할 필요가 없다고 생각한다.어떤 단계에서 위키피디아 사람들은 우리가 합리적으로 실행 가능하고 실제로 유용할 수 있는 짧은 설명들 중 많은 부분을 취했다고 제안할 것이고, 위키다타 폴백의 종료를 요청할 것이다.우리는 전통처럼 내부적인 논의와 합의에 의해 이 점을 확립할 것이다.이 시점에서 나는 WMF가 더 많은 것을 찾아내고 추출하는 노력의 가치가 있다는 것을 통계적으로 납득할 수 있는 증거를 확인하고, 그들을 찾아낼 수 있는 방법 또는 더 이상의 지연 없이 폐쇄를 할 수 있는 방법을 보여줄 것을 제안한다.마지막 몇 가지 유용한 기술들을 뒤지는 것이 셧다운 이후 언제라도 더 노력할 가치가 있다고 생각하는 사람들을 막을 수 있는 것은 아무것도 없다.믿을 만한 증거가 없는 상황에서 특정 숫자에 대해 흥정하는 것으로 이득을 얻는 사람은 아무도 없다.몇 주 또는 몇 달 동안 실제로 짧은 설명을 만들고 전송하는 것은 컷오프 포인트를 추정하는 방법에 대한 더 유용한 아이디어의 광범위한 영감을 불러일으킬 수 있다.· ···피터(사우스우드):(talk) 05:08, 2017년 12월 30일 (UTC)[
- Pbsouthwood와 Alsee:네, 좋네요.그래, 우리는 전환의 문턱을 어떻게 정할지 함께 일할 수 있어.처음에는 페이지마다(5.5m) 설명을 뽑아낼 수 있기를 바랐지만, 질의가 실행되려면 며칠이 걸릴 것이고, 어쨌든 수작업으로 샘플을 훑어보고 싶었다.그래서 무작위 1만 개를 사용한 겁니다.만약 누군가가 어떻게든 더 나은 견적을 얻고 싶다면, 멋지군, 그렇지 않으면 우리는 200만이라는 반올림 숫자를 말하는 거야.아니면 누군가가 그 문턱을 어떻게 판단하는지에 대해 더 나은 생각을 가지고 있을지도 모른다.어떻게 생각하십니까? -- 대니H (WMF) (토크) 21:21, 2017년 12월 29일 (UTC)[ 하라
핵심 비트는 다음과 같다.
영어 위키백과 편집자들은 적극적인 위키다타 편집자가 되지 않고도 데스크탑과 모바일 웹의 짧은 설명을 보고 편집하며 효과적으로 조정할 수 있어야 한다.그렇게 하려면 위키백과 감시 목록과 페이지 역사에 의미 있는 통합이 필요하다.위키다타 팀이 작업하고 있는 특징들이지만, 현재 존재하지 않으며, 시간표도 없다.
이 기능이 생성되기 전에는 통합이 불가능하다.현재의 상황은 우리를 장기간의 공공 기물 파괴에 노출시키고, 따라서 우리의 명성을 해친다.Doc James (대화 · 기여 · 이메일) 06:12, 2017년 12월 30일 (UTC)[
비활성 사용자의 대화 페이지에 "nobots"를 표시하다.
13개월 이상 만에 편집을 피한 사용자의 토크 페이지에 {{nobots}}을(를) 올려놓으면 좋을 것 같다.아니면 12살 정도?
현재 이 기준에 맞는 사용자가 많다.그리고 그들은 많은 뉴스레터를 구독해 왔다.이것들은 봇에 의해 전달된다.그리고 사용자가 보관을 위해 봇을 설치했다면, 그것은 많은 자원이 낭비되고 있다는 것을 의미하며, 이것은 저장될 수 있다.
{{nobots}}을(를) 배치할 거면 {{nobots}정도 포함시켜야 할 것 같아.—usernamekiran(talk) 05:25, 2018년 2월 7일(UTC)[
- 대부분의 뉴스레터는 WP를 통해 전달된다.MMS, 사실 "봇"이 아니라 - 그리고 MMS는 그것을 존중하지 않는다.— xaosfluxTalk 05:41, 2018년 2월 7일 (UTC)[
- @Xaosflux: 내가 우연히 알게 된 비활성 사용자들의 대부분의 토크 페이지에는 피드백 서비스, 뉴스레터 등의 메시지가 쇄도한다.나는 MMS가 노봇을 존중하지 않는다는 것을 알지 못했다.레고봇은 노봇을 존중하는가?—usernamekiran(talk) 09:00, 2018년 2월 7일(UTC)[
- 사용자 스스로 그러한 기능을 사용하고자 하는 경우, 자유롭게 사용할 수 있다.그러나 그렇지 않으면, 비활동적인 것이 무엇을 의미하는지, 메시지를 받고 싶은지 사용자들을 결정해서는 안 된다. --Jayron32 11:50, 2018년 2월 7일 (UTC)[
- @Xaosflux: 내가 우연히 알게 된 비활성 사용자들의 대부분의 토크 페이지에는 피드백 서비스, 뉴스레터 등의 메시지가 쇄도한다.나는 MMS가 노봇을 존중하지 않는다는 것을 알지 못했다.레고봇은 노봇을 존중하는가?—usernamekiran(talk) 09:00, 2018년 2월 7일(UTC)[
- 아니, 그건 {{nobots}}}을(를) 위한 것이 아니다.Anomie⚔ 14:25, 2018년 2월 7일 (UTC)[
감시 목록에서 모든 리디렉션 페이지 제거 단추 추가
내 감시 목록에 있는 페이지의 절반 이상이 리디렉션되어 있고, 내가 새로운 배치를 만들 때마다 그 페이지들이 위로 밀려오는데 지쳤다. 그러면 15% 정도는 이중 리디렉션이기 때문에 봇에 의해 바뀐다.내가 감시 목록을 만들 때 감시 목록에 리디렉션을 추가하는 것을 중지했지만, 그것은 내 감시 목록에 이미 있는 리디렉션을 수정하는 데 아무런 도움이 되지 않는다.나랑 의견이 다르거나 의논할래?Nth User 03:01, 2018년 1월 30일 (UTC)[
- 나쁘지 않은 생각인데, 그 문제에 대해서, 당신의 감시 목록에서 한 번의 클릭으로 항목을 제거하기 위한 버튼 요청은 어떻게 되었는가?감시 목록(또는 이와 유사한)의 목록 옆에 '제거' 버튼을 놓는 스크립트가 있는가?— 여기 03:37, 2018년 1월 30일 (UTC)[
- @Nth 사용자:추가 시도
.watchlistredir { font-style: italic; }
당신들의 CSS로.그런 다음 Special로 이동하십시오.EditWatchlist.이탤릭체로 리디렉션을 고를 수 있을 것이다. --Izno (토크) 04:05, 2018년 1월 30일 (UTC)[- @Izno: 효과가 있었어, 하지만 카테고리 리디렉션은 어때?나랑 의견이 다르거나 의논할래?Nth User 04:19, 2018년 1월 30일 (UTC)[
- 만약 이중 간접 수정 봇이 지연으로 운영하기로 한 지역사회의 결정을 존중한다면(적어도 그들이 재빨리 나쁜 움직임을 되돌리는 결과를 초래하는 이중 리디렉션을 "수정"하는 것을 막을 수 있다면), 또는 미디어위키 소프트웨어가 일부 이중 리디렉션을 허용한 것에 대한 지역사회의 합의를 존중한다면, 이것은 그렇게 큰 문제가 되지 않을 것이다.– 우안팔라 (대화) 15:18, 2018년 2월 3일 (UTC)[
범주
일별 예 11월 15일 생년월일을 기준으로 범주를 만드십시오 — 5.119.149.1이 추가된 이전의 부호 없는 주석(토크 • 기여)
- 위키백과에서 이전 토론을 참조하십시오.Bot requests#bot 새 범주 생성
- 나는 WP에 의해 그러한 범주가 실현 가능하다고 생각하지 않는다.COPDF 및 여러 WP:OURCAT 이슈. --Francis Schonken (대화) 14:54, 2018년 1월 23일 (UTC)[
- 지원 WP에는 아무것도 없다.COPDF 또는 WP:OverCAT는 이를 방지하고, 생일 축하, 별자리, 또는 (죽은 날짜와 함께) 나이를 프로그래밍적으로 계산하는 능력을 고려하든 간에, 대부분의 사람들에게 생년월일은 분명히 결정적인 이슈다.범주 교차로들은 사용자가 주어진 날짜와 연도에 태어난 사람들, 또는 그들의 생일에 죽은 사람들의 목록을 찾을 수 있게 해준다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 21:38, 2018년 1월 30일 (UTC)[
- 지원 벌써 그런 식이 아니라는 걸 믿을 수가 없어그런데 그것은 "범주"이다.스파르타N (토크) 21:52, 2018년 1월 30일 (UTC)[
- 그 범주들은 다루기 힘들 것이다.우리는 11월 15일에 태어난 사람들에 대한 2897개의 기사를 가지고 있다.이러한 범주에 접근할 수 있도록 하려면 더 작은 범주로 나누어야 한다.그렇다면 어떤 기준을 사용하시겠습니까?년도? Mduvekot (대화) 22:20, 2018년 1월 30일 (UTC)[ 하라
- 그것은 그것을 하지 않을 이유가 아니다 - 그리고 우리는 많은 더 큰 범주를 가지고 있다.그러나 만약 그것들이 분할되어야 한다면, 그것을 달성하기 위해, 예를 들어, 세기, 성별, 혹은 둘 다로 나누어서 최적의 범주 크기를 결정하라.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 23:08, 2018년 1월 30일 (UTC)[
- 제발 안 돼.전기 기사의 범주는 이미 온갖 잡동사니들로 가득 차 있는데, 이것은 그것들을 더욱 악화시킬 것이다.– 우안팔라 (대화) 15:22, 2018년 2월 3일 (UTC)[
- 나는 그러한 분류가 필요한지 확신할 수 없다.특정 년도의 출생과 사망의 범주는 독자들이 사람이 살았던 역사적 시대를 보는 데 도움이 되지만, 나는 이 분류가 어떻게 그러한 목적을 달성할 수 있을지는 모르겠다.보르비 (토크) 20:06, 2018년 2월 4일 (UTC)[
- 이것은 그다지 유용하지 않을 것이다.그것은 기사를 더 복잡하게 만들 것이고 패트롤러들에게 더 많은 일을 야기시킬 것이다.하지만 아마도 우리는 특정한 생일을 가진 사람들을 찾을 수 있는 도구를 만들어야 할 것이다.Graeme Bartlett (talk) 06:36, 2018년 2월 7일 (UTC)[
어떤 의미에서, 우리는 이미 이 도구를 가지고 있다.연도의 날짜를 오른쪽 상단 모서리에 있는 상자에 입력하면 연도의 해당 날짜에 태어난 사람들의 목록이 나온다.보르비 (토크) 19:37, 2018년 2월 7일 (UTC)[
사용된 참조 시스템을 변경하는 Bot
안녕, 나는 표준 인라인 레퍼런스를 사용하는 것에서 정의된 레퍼런스 목록으로 이동하는 봇을 제안한다.자, 이것은 위키텍스트에 영향을 미치지 않는 변화다.대신에, 그것은 낯선 사람들을 위해 모든 참조를 그들 자신의 섹션으로 이동시킨다.분명히, 그것의 사용(또는 그렇지 않음)은 순전히 양식적이다.따라서, 봇은 사용자의 요청에 의해서만 이 과정을 작동시킬 것이다.나는 이것이 중요한 과정이라고 믿는다. 왜냐하면 큰 기사가 쉽게 다루어질 수 없기 때문이다.예를 들어, 나는 기사의 다른 부분에 있는 참고문헌의 제거를 고치기 위해 이런 변경을 해야 했다.그 결과 참고문헌의 두 번째 사용이 고아가 되었다.변화를 수동으로 만드는 것은 지루한 일이라는 바로 그 문제를 제기하는 바로 그 기사인 이와 같은 큰 기사에 있다.그러므로 나는 나의 봇을 제안한다.『벨레자솔로』 22:49, 2018년 2월 6일 (UTC) 토론[
- 제안된 것처럼 위험하다. 서류상으로는 괜찮겠지만, 이것은 잠재적으로 매우 논란이 많은 봇이 될 수 있다.사용자는 "Category의 모든 문서를 수행하자:물리학과 그것은 모든 범주에 대혼란을 가져올 것이다.만약 더 강력한 안전장치가 마련되었다면 나는 이런 봇에 전적으로 반대하지는 않는다."기사의 토크 페이지[또는 위키백과 제목]에 대한 토론에 따름" / "7일 간의 WP 후:"무음 기간"은 봇이 그러한 합의의 이행을 촉진할 수 있다.헤드폭탄 {t · c · p · b} 23:13, 2018년 2월 6일 (UTC)[
- 실행 취소? 제안된 봇이 문제가 있는 경우 사실(및 새로운 기사 편집 후) 이후 작업을 되돌릴 수 있는가? 아니면 수정판 번복이 필요할 것인가?— xaosflux 23:30, 2018년 2월 6일 (UTC)[
- 직접 변경하지 않은 경우 사용자:아노미봇은 사람들이 너무 자주 편집을 멈추면 같이 와서 했을 것이다.제안서 자체에 대해서는 봇, 심지어 주문형 봇이라도 승인하기 전에 강력한 공감대가 형성되기를 바란다.Anomie⚔ 00:10, 2018년 2월 7일 (UTC)[
- Headbombe에 대한 회신에서, 만약 봇으로부터 범주가 요청되었다면, 나는 그것이 효과가 있을 것으로 예상하기 때문에 범주 페이지 자체에 참조를 고정시킬 뿐이다.
- Xaosflux에 대한 답변으로, 나는 그 봇이 오류 발견 시 스스로 되돌아갈 수 있다고 확신한다 - 비록 내가 잘 모르지만, 그것에 대한 API가 있을 것이라고 추측한다.나는 개인적으로 그것이 위키백과 인터페이스가 있는 반자동 도구에 가깝고 WP와 같이 정확성을 보장하는 것에 대해 사용자가 책임을 지지 않아야 할 이유를 모르겠다.HG. 경험에 근거해 사용자가 요청할 수 있는 페이지 수를 제한하면 남용을 방지하기가 꽤 쉬울 것이다.
- 아노미에게 답장으로 아노미봇이 그 기능을 수행했는지 몰랐어.
- 『벨레자솔로』토론 00:22, 2018년 2월 7일 (UTC)[
- @Bellezasolo:단순히 봇의 편집 전 버전에 "반복"하는 것이 아니라, 스타일링이 끝난 후 어딘가에서 되돌릴 필요가 있다면, 봇이 프로그램적으로 적용한 스타일링을 풀 수 있을까?— xaosfluxTalk 00:56, 2018년 2월 7일(UTC)[
- @Xaosflux: 분명히 프로그래밍할 수 있을 거야 - 물론 가능하겠지만, 앞의 기사가 프랑켄슈타인 혼합의 어떤 종류였다면 한 스타일에서 다른 스타일로의 완전한 이동을 의미할 수도 있어. ∰벨레자졸로 ✡ 01:05, 2018년 2월 7일 (UTC) 디스코론[
- 오 나도 동의해, 그리고 이것은 지금 당장 "필수"가 아니야. 사람들이 ref 스타일에 대해 논쟁을 시작한다면, 그냥 생각하는 거야.나는 봇의 관점에서 그것이 대부분 하나 또는 다른 하나가 되어야 한다는 것을 이해한다.— Xaosflux 02:16, 2018년 2월 7일 (UTC)[
- @Xaosflux: 분명히 프로그래밍할 수 있을 거야 - 물론 가능하겠지만, 앞의 기사가 프랑켄슈타인 혼합의 어떤 종류였다면 한 스타일에서 다른 스타일로의 완전한 이동을 의미할 수도 있어. ∰벨레자졸로 ✡ 01:05, 2018년 2월 7일 (UTC) 디스코론[
- @Bellezasolo:단순히 봇의 편집 전 버전에 "반복"하는 것이 아니라, 스타일링이 끝난 후 어딘가에서 되돌릴 필요가 있다면, 봇이 프로그램적으로 적용한 스타일링을 풀 수 있을까?— xaosfluxTalk 00:56, 2018년 2월 7일(UTC)[
이 제안은 WP의 다음 구절과 일관되지 않는다.CITE [강조 추가]:
- 잡동사니 피하기
- 인라인 참조는 편집 창에서 위키텍스트를 크게 부풀릴 수 있으며 어렵고 혼동될 수 있다.편집 창에서 잡음을 방지하는 두 가지 주요 방법이 있다.
- 다른 인용 형식과 마찬가지로, 기사는 그렇게 하도록 합의되지 않은 채 형식 간에 대규모 변환을 거치지 않아야 한다.
따라서 WP:CITE를 바꾸려면 공감대를 얻어야 할 것이다.특정 기사에서 잡음을 피하는 몇 가지 가능한 접근법이 있기 때문에 그 대안은 봇을 고용하기보다는 기사의 토크 페이지에서 논의해야 할 것이다.Jc3s5h (대화) 02:43, 2018년 2월 7일 (UTC)[
- 반대 - Jc3s5h가 한 말, 즉 WP:CITEVAR은 인라인과 LDR 사이의 선택에 적용된다.게다가 LDR은 어쨌든 인라인보다 확실히 우수하지는 않다.다음과 같은 단점이 있다.
편집자가 ref를 사용하지 않는 콘텐츠를 삭제하면 소프트웨어는 참고문헌 섹션에 BIG Red Citter 오류 알림을 넣는다.이것은 편집자가 이를 알아차리고 사용하지 않은 참조를 삭제하거나 주석을 달기 전까지는 독자들에게 추악하게 보인다.대다수의 편집자가 올바른 참조를 이미 너무 복잡하게 하고 있다는 점을 고려하면, 편집자에게 리프레임의 다른 용도를 확인하고, 그 제거로 인해 LDR이 사용되지 않는 경우 이를 제거/코멘트하도록 요구하는 것은 합리적이지 않다.
그리고 나서, 때때로 원래의 제거 편집이 되돌아가고, 그리고 나서 우리는 정의되지 않은 refname에 대한 BIG Red 인용 오류 통지, 그리고 깨진 인용문이 있다.헹구고, 반복한다.몇 년 전 나는 사용하지 않는 참고자료에 대한 BIG 레드 인용 오류를 제거함으로써 이러한 효과를 막겠다는 생각을 제기했지만, 아무런 추진력을 얻지 못했다.
요약하면, CITEVAR과 LDR이 순긍정적이라는 지역사회의 공감대가 부족하다는 두 가지 주요 장애물이 있다.-맨드러스 인터뷰 03:20, 2018년 2월 7일 (UTC)[
그래, 아노미비보다 덜 논쟁적인 영역일 수도 있지OT는 다음 사항을 포함하지 않음:
참조 섹션에 큰 적색 오류가 발생하는 사용하지 않는 LDR을 수정하는 봇.이것은 오류를 감지한 다음 불쾌감을 주는 참조를 언급함으로써 효과가 있을 것이다.참고문헌을 주석을 달음으로써, 그것은 여전히 검토가 가능하다. (그리고, 만약 그 기사가 복사되고 있다면, 그것은 누군가에게 영향을 미치지 않는다.)그리고 나서 그것은 그들의 대화 페이지에 그들의 행동에 대한 공지를 게시할 것이다.『벨레자졸로』 04:09, 2018년 2월 7일 (UTC) 토론[
- 더 나은 대안:처음부터 큰 빨간 메시지를 생성하지 마십시오.이로 인해 사용되지 않은 일부 LDR이 무기한 보존되어 약간의 공간을 낭비하게 될 것이다. 그러나 어떻게 될까?이 메시지는 등록된 사용자의 CSS가 내 CSS의 첫 번째 줄과 유사한 특정 문구를 포함하는 경우에만 보이는 다른, 더 작은 빨간색으로 대체될 수 있다.그런 다음, 이런 종류의 정리에 관심이 있는 편집자들은 그러한 메시지를 주시하고 사용하지 않는 LDR을 논평할 수 있다. (우리는 새로운 CSS 제어를 문서화하기 위한 적절한 장소를 찾아야 할 것이다.)사용하지 않는 LDR은 이미 기사를 정리하기 위해 추적 카테고리에 배치하고, 유일한 차이점은 사소한 오류에 대한 덜 보이는 메시지일 것이다.어느 쪽이든, 나는 봇에 대한 설득력 있는 필요성을 느끼지 못한다.-맨드러스 인터뷰 05:40, 2018년 2월 7일 (UTC)[
- 에러 메시지가 큰 이유는 이것이 고쳐져야 할 것이지 숨겨야 하거나 우회해야 할 것이 아니기 때문이다.헤드폭탄 {t · c · p · b} 12:02, 2018년 2월 7일(UTC)[
템플릿:비무료감량봇
(위키백과의 대화에서 복사한 내용:비무료 콘텐츠/아카이브 68#기고자가 많지 않은 만큼 새로운 봇에 대한 제안]
{{Non-Free Reducation}}}}}}의 새로운 크기 비자유 이미지에 태그를 지정할 새로운 봇을 제안하고 싶다.나는 이 아이디어에 약간의 역사를 설명하고, 그것이 얼마나 많은 이미지들에 영향을 미칠지 설명하고 싶다.
- 2016년 10월, 약 55만 개의 무료 영상이 있었는데, 쉽게 찾을 수는 없었지만, NFCC 가이드라인보다 약 30만 개가 더 많았다!동시에 wiki는 검색엔진을 변경했다(mw: 참조).도움말:CirrusSearch#File_properties_search) - 다양한 파일 매개 변수(폭, 길이, 해상도 - 프로그래머가 "해상도"가 픽셀 카운트의 제곱근과 동일하다고 결정한 경우 - 이상하지만 참).이러한 변화에 따라 이 두드러지게 많은 수의 비자유 영상에도 서서히 작업할 수 있게 되었고, 현재 약 60만 개의 영상이 있으며, 그 중 크기가 초과된(다양한 이유로) 1,000개 미만인 영상은 다음을 참조하십시오.비록 이것들 중 일부는 약간 "시스템게이밍"이고 축소될 수 있다고 생각하지만, 무료 이미지는 감소하지 않는다. 하지만 그것은 아주 작은 소수다.
- 이 기간 동안, 일반적으로 매일 약 70-80개의 새로운 크기 초과 크기의 비자유 이미지가 업로드된다는 것이 명백해졌다.이들(약 80%)의 대부분은 완전히 새로운 것이며 나머지는 업데이트된 이미지들이다.이미 업로더가 추가한 {{Non-free redule}}은 10% 정도지만, 대다수가 어떤 식으로든 플래그가 붙지 않는다.최근 7일 동안의 업로드 목록(저감을 위해 업로더에 의해 즉시 태그가 지정된 목록은 제외)을 User:론존스/7일
- 따라서 업로드한 지 하루 만에 태그가 지정되지 않은 새로운 업로드를 목표로 하는 제안.따라서 업로더가 활성 상태임을 알 수 있으며, 따라서 적절한 경우 크기를 논의할 수 있다.새로운 봇(나는 대충 써보았지만 검증되지 않은)이 될 수 있었다.
- 위키 검색 엔진을 사용하여 파일러가 있는 모든 이미지를 찾으십시오. >=325(105625 픽셀 - 감소 봇은 어쨌든 10만5000픽셀 미만으로 줄어들지 않음).
- 마지막 업로드의 올바른 픽셀 수를 계산하고(아직 RevDel이 아닌 경우 이전 버전을 찾는 위키 검색과 달리), 크기가 정상이면 건너뛰십시오.
- {{Non-Free Reduct}, {{Non-Free No Reduct}, {{Permission OTRS}}이(가) 있는지 점검하고, 있는 경우 건너뛰십시오.
- 페이지 상단에 {{Non-free lend}} 추가
- 마지막 업로더의 토크 페이지에 템플릿을 추가하여 이미지가 축소되고 더 큰 이미지가 필요한 경우 수행할 작업과 하지 말아야 할 작업과 함께 그 이유를 설명하십시오.파일 형식(예: 비트맵 대 벡터)에 따라 추가할 템플릿 선택 가능.
내가 아는 편집자 몇 명을 ping하는 것은 이 분야에 관심이 있다 @BU Rob13, Stefan2, Diannaa:
의논할 시간이야...
- 지지하다.좋은 생각인 것 같아.이 페이지에 대한 최근 토론에 따라, 내가 제안하고 싶은 한 가지는 파일러: >=380-- 즉, 감소율이 약 선형 20% 이상일 때에만 감소하는 것이다.0.1Mpx 수치는 단지 느슨한 표시일 뿐이다. 20% 미만으로 감소하는 것은 업로더에게 지나치게 까다롭고 긁히는 것처럼 보인다. 크기 변화는 거의 감지할 수 없고, 확실히 법적인 차이가 없으며 이미지 품질에서 예술적인 효과를 낼 수 있다.우리가 정말로 통제하고 싶은 것은 이것보다 훨씬 큰 이미지들이다.업로더들의 시선이 여전히 쏠린 상태에서 업로드 후 바로 그런 이미지로 옮겨가는 IMO는 일리가 있다.제힐드 (대화) 22:16, 2018년 1월 30일 (UTC)[
- 문턱이 얼마나 낮은지는 공감대를 얻기 위한 분명한 항목이다."316이 가이드라인에 있을 것"이라며 "325는 현재 380이 144400이며 7일 목록 론존스 22:53, 2018년 1월 30일(UTC)에서 79개의 이미지를 삭제하겠다 고 밝혔다.
- @Ronhjones:비교하기에 유용한 숫자는 해당 기간에 추가된 총 비자유 이미지 수입니다.사용자로부터 알 수 없음:Ronhjones/7일 동안 105625 px를 초과하는 이미지만 표시되므로
- 문턱이 얼마나 낮은지는 공감대를 얻기 위한 분명한 항목이다."316이 가이드라인에 있을 것"이라며 "325는 현재 380이 144400이며 7일 목록 론존스 22:53, 2018년 1월 30일(UTC)에서 79개의 이미지를 삭제하겠다 고 밝혔다.
- 정확한 숫자는 알 수 없지만, "325" 이하의 숫자는 매우 적다.API 호출로 7일 동안 1160개의 무료 이미지를 얻을 수 있으며, 498개의 왼쪽 662개를 떼고, DatBot이 160개를 줄인 502개의 파일을 떼고, 91개(SVG I 수작업으로 줄였다)를 제거하면 "325" 이하로 69개의 무료 이미지를 업로드할 수 있다.그래서 내가 추정하는 새로운 업로드는 498 오버사이즈 + 69 언더사이즈 = 총 567이므로 88%가 오버사이즈였습니다.론존스 01:40, 2018년 2월 1일 (UTC)[
- (복사된 내용의 끝)론존스 14:24, 2018년 2월 3일 (UTC)[
- 지원 원칙, 문턱에 대해 확신할 수 없음.עוד וו od יו od od od od od od od od od od od od od od od od od 09:38, 2018년 2월 4일 (UTC)[
- 위키백과를 참조하십시오.봇/승인요청/Fbot 9 및 위키백과의 후속토론:봇/승인 요청/아카이브 9#Fbot 9.사람들은 봇이 모든 대형 파일을 태그할 때 행복하지 않았다.업로더가 더 활동적이고 태그가 눈에 띄기 쉬우므로 새로운 업로드에 더 효과적일 수 있다. --Stefan2 (토크) 21:00, 2018년 2월 5일 (UTC)[
- 동의한다 - 그래서 내가 업로더에게도 메시지를 보내자고 제안한 것이다.론존스 22:34, 2018년 2월 6일 (UTC)[
- 반대 당신은 모든 이미지가 사각형이라고 생각하는가?그렇지 않으면 봇이 400x10의 이미지를 잘못 표시하여 200x2000의 이미지를 놓칠 수 있기 때문이다.게다가, 나는 그 어떤 작은 이미지의 태깅도 반대할 것이다. 0.1 메가픽셀은 정책이 아닌 가이드라인이며, 가장
일반적인 화보상의
니즈로 사용되는 언어는약 10만 화소 이하의 이미지로 충족
될 수 있다(그리고 가이드라인에 그것을 추가한 마셈은 결코 어려운 한계가 될 의도가 아니었다고 말했다).그러나, 그 크기의 이미지로 니즈를 충족시킬 수 있는지의 결정은 봇이 아닌 사람에 의해 이루어져야 하며, 당신이 설명한 대로 봇을 풀어내는 것은 거의 틀림없이 "최소한의 사용" 기준을 충족시키는 불필요한 이미지 크기 조정의 결과를 초래할 것이다.이렇게 하려면 Fbot 9의 한계점인 16만4025는 절대 최소치가 되어야 한다고 말하고, 솔직히 30만7200에 가까운 숫자로 하는 것이 더 편할 것이다.그 이하로는 '인간의 검토가 필요하다'는 꼬리표가 붙을 수 있지만, atBot이 등장하게 하고, 사람의 개입 없이 자동적으로 이미지 크기를 조정하게 할 만한 것으로는 안 된다. --Ahecht (TOKPAGE
) 23:18, 2018년 2월 5일 (UTC)[
- Fbot9는 훨씬 더 큰 이미지를 주던 DashBot을 가리키는데, 이 작업은 2011년 테오의 봇에 의해 인수되었다(이미지 <10만 화소>를 만든다).400x10은 4000픽셀이고 플래그가 붙지 않을 것이고, 200x2000은 400,000픽셀이고 플래그가 붙을 것이다 - 높은 비율의 이미지는 현재 표준이 아니다.아이디어의 핵심은 사용자(우리가 아는 사람이 활동적인 사람)에게 경고하고 이미지가 특별한 치료가 필요한 경우 어떻게 행동해야 하는지에 대한 조언을 제공하는 것이다.론존스 22:31, 2018년 2월 6일 (UTC)[
- 사용자에게 경고하려는 경우, 봇이 대화 페이지에 메시지를 게시하도록 하십시오.{{Non-free reduction}}}은(는) 사용자에게 경고만 하는 수준을 훨씬 넘어, 24시간 내에 자동으로 이미지 크기를 조정하도록 봇에게 경고한다. --Ahecht (TOKPAGE
) 16:43, 2018년 2월 7일(UTC)[- 업로더가 확인하기 전이라도 늘 그렇듯 7일이면 되돌릴 수 있다.론존스 22:46, 2018년 2월 7일 (UTC)[
- 사용자에게 경고하려는 경우, 봇이 대화 페이지에 메시지를 게시하도록 하십시오.{{Non-free reduction}}}은(는) 사용자에게 경고만 하는 수준을 훨씬 넘어, 24시간 내에 자동으로 이미지 크기를 조정하도록 봇에게 경고한다. --Ahecht (TOKPAGE
- Fbot9는 훨씬 더 큰 이미지를 주던 DashBot을 가리키는데, 이 작업은 2011년 테오의 봇에 의해 인수되었다(이미지 <10만 화소>를 만든다).400x10은 4000픽셀이고 플래그가 붙지 않을 것이고, 200x2000은 400,000픽셀이고 플래그가 붙을 것이다 - 높은 비율의 이미지는 현재 표준이 아니다.아이디어의 핵심은 사용자(우리가 아는 사람이 활동적인 사람)에게 경고하고 이미지가 특별한 치료가 필요한 경우 어떻게 행동해야 하는지에 대한 조언을 제공하는 것이다.론존스 22:31, 2018년 2월 6일 (UTC)[
- 만약 그러한 봇이 있다면, 파일이 이미 줄었는지 또는 이전의 축소가 되돌아왔는지 또한 확인해야 한다.크기를 줄이지 않는 데는 다양한 이유가 있으며, 봇이 이 주제에 대한 가독성이나 이전의 논쟁을 이해하지 못할 것으로 예상된다.크기가 너무 큰 새로운 이미지에는 유용한 활동이 될 것이다.꽤 많은 이미지들도 pd-simple의 자격을 얻을 수 있고, 비록 공정한 사용이 라벨이 되어있더라도, 그것은 필요하지 않다.그러나 다른 것들은 실제로 CC-BY-ND(또는 -NC)와 같은 큰 사이즈를 사용할 수 있도록 허가되어 출시되지만 여전히 호환되는 라이선스를 받을 자격이 없다.Graeme Bartlett (talk) 06:27, 2018년 2월 7일 (UTC)[
- 이는 크기가 초과된 오래된 이미지(이미 {{non-free no remed} 태그가 지정된 이미지 제외)가 없기 때문에 크기가 초과된 새로운 이미지에서만 작동할 수 있다.나는 현재 매일 밤 수동으로 새로운 파일들을 배치하고 있다.나는 WP에서 세부 사항들을 정리할 수 있을 것이라고 확신한다.BRFA 론존스 22:46, 2018년 2월 7일 (UTC)[
- 관계없는 전이. 이 논의의 제목을 좀 더 서술적이고 덜 모호한 것으로 바꿀 수 있을까?봇과 관련된 여러 논의가 동시에 진행되고 있고, 나머지는 적어도 자신의 목적을 암시하고 있다.
{{Anchor Suggestion for new bot}}
연속성을 위해 배치될 수 있다.~톰.레딩(토크 ⋅dgaf) 20:51, 2018년 2월 9일 (UTC)[
논란이나 비판을 제거하거나 줄일 때 쉽게 발견할 수 있는 방법 제공
안녕
나는 수년 동안 IP 편집자(주로 회사와 정치인들)가 '복사본'이나 '문법 수정'과 같은 악의 없는 편집 요약을 통해 기사(주로 기업 및 정치인)의 '논란'이나 '비판' 부분을 삭제한 기사를 몇 개 발견했는데, 그 내용은 페이지를 보는 사람들에게 들키지 않았다(또는 아무도 없다).페이지를 보는 것).
이걸 플래그로 할 수 있는 방법이 없을까?아마도 논란과 비판과 관련된 섹션 제목이나 큰 텍스트 덩어리가 어디에 지워져 있는지 확인하고 어디선가 플래그로 플래그를 걸어 재점검하는 봇이 있을 수 있을까.
고마워요.
존 커밍스 (대화) 13:10, 2018년 2월 11일 (UTC)[
- 위키백과당 반대:비판: 많은 경우에 개별적인 논란 또는 비판 섹션은 나쁜 글쓰기의 증상이다. – 그렇게 나쁜 글을 강요하는 것은 봇의 몫이 아니다.최소한, 봇은 논쟁이나 비판들이 기사의 주요 서술에 더 잘 통합되어야 하는 경우와 그들이 별도의 섹션을 가질 자격이 있는 경우를 구별할 수 없을 것이다.별도 섹션 옵션은 매우 드문 예외여야 한다(실제로 "롤 자석"). 이 예외가 그리 드물지 않다는 사실은 이러한 많은 기사의 품질 부족을 말해준다: 대부분의 경우 기사의 전반적인 품질은 다루어야 하는 것이며, 봇이나 다른 보조 기사에 의해 운용될 수 없는 방식으로 말이다.애초에 이런 별도 섹션이 있어야 하는지에 대한 토론 페이지 토론이 없었던 기사들을 위해 "논의" 섹션 제목과 "비판" 섹션 제목을 삭제하는 봇을 지지한다.그것은 봇 작업으로서 다소 비현실적이겠지만, 그래도 나는 OP에서 제안된 것 보다 그것을 지지하고 싶다. --프랜시스 숀켄 (토크) 13:43, 2018년 2월 11일 (UTC)[
- 이는 이러한 편집 내용을 인간 검토를 위해 플래그로 지정하는 제안이 자동적으로 되돌리는 것이 아니라 오해하고 있는 것으로 보인다.에세이 위키백과:비판, 형식이나 스타일에 대해서는 타당하게 지적하고 있지만, 현실적으로는 비판하고 있는 섹션 레이아웃이 당분간 널리 퍼져 있으며, 그 제안은 레이아웃 변경이 아닌 내용 삭제 감지를 위한 것으로 알고 있다.안녕, HaeB (대화) 14:56, 2018년 2월 11일 (UTC)[
- 그러나 전체 아이디어에 반대하십시오. 별도의 논란 또는 비판 섹션에는 플래그가 표시되어야 하며, 바람직하지 않은 별도 섹션을 자주 다루는 편집은 표시되지 않아야 한다.임호 "...아직 널리 퍼진..."은 우리가 현상을 추구해야 할 문제가 아니라 (위에서 설명한 바와 같이) 문제의 일부분이다. 즉, 트롤이 WP와 함께 논쟁 또는 비판 섹션을 확장했을 때 플래그가 발생하지 않을 것이다.과도한 세부사항, 그러나 그러한 트롤링이 제거되면 플래그가 지정된다.기사 내용과 레이아웃에 대해 너무 자주 지지해선 안 된다. --프랜시스 숄켄(토크) 15:37, 2018년 2월 11일 (UTC)[
- @Francis Schonken: 명확하지 않아 유감스럽지만, COI 가능성이 높은 IP 편집자들이 종종 행하는 논란과 비판이 제거된 사례를 인간이 보도록 플래그를 달 수 있는 방법을 찾고 있다(수년에 걸쳐 지속적인 정보 PR 제거의 좋은 예로서 영국의회 IP 편집 참조).내가 제안하는 것은 이러한 공통적인 부분들은 (여러분이 아무리 그들의 존재에 대해 느끼더라도) 그것을 찾을 수 있는 유일한 장소가 되기 보다는, 이런 종류의 활동을 찾기 시작하기에 좋은 장소라는 것이다.— John Cummings가 추가한 이전 서명되지 않은 논평(대화 • 기여)
- 그러나 전체 아이디어에 반대하십시오. 별도의 논란 또는 비판 섹션에는 플래그가 표시되어야 하며, 바람직하지 않은 별도 섹션을 자주 다루는 편집은 표시되지 않아야 한다.임호 "...아직 널리 퍼진..."은 우리가 현상을 추구해야 할 문제가 아니라 (위에서 설명한 바와 같이) 문제의 일부분이다. 즉, 트롤이 WP와 함께 논쟁 또는 비판 섹션을 확장했을 때 플래그가 발생하지 않을 것이다.과도한 세부사항, 그러나 그러한 트롤링이 제거되면 플래그가 지정된다.기사 내용과 레이아웃에 대해 너무 자주 지지해선 안 된다. --프랜시스 숄켄(토크) 15:37, 2018년 2월 11일 (UTC)[
- 이는 이러한 편집 내용을 인간 검토를 위해 플래그로 지정하는 제안이 자동적으로 되돌리는 것이 아니라 오해하고 있는 것으로 보인다.에세이 위키백과:비판, 형식이나 스타일에 대해서는 타당하게 지적하고 있지만, 현실적으로는 비판하고 있는 섹션 레이아웃이 당분간 널리 퍼져 있으며, 그 제안은 레이아웃 변경이 아닌 내용 삭제 감지를 위한 것으로 알고 있다.안녕, HaeB (대화) 14:56, 2018년 2월 11일 (UTC)[
- 나는 그러한 편집이 문제라는 것에 동의한다.FWIW, 이미 "섹션 블랭킹"과 "참조 제거" 편집 태그가 있다.안녕, HaeB (대화) 14:56, 2018년 2월 11일 (UTC)[
- 그럼에도 불구하고, 레이아웃 문제를 다루기보다는 종종 바람직하지 않은 별개의 논란이나 비판 부분을 보호하는 편이다. --Francis Schonken (토크) 15:37, 2018년 2월 11일 (UTC)[
- @Francis Schonken: 비판과 논쟁 부분이 남용될 수도 있고 때로는 다른 부분으로 옮겨져야 한다는 당신의 지적은 고맙지만, 이것은 그것에 대한 토론이 아니다.위키백과의 범위 내에서 정확하고 정확한 정보를 삭제하는 COI 편집을 더 잘 찾아내고 검토 플래그를 지정하는 방법을 찾는 것에 대한 논의다.나는 이러한 편집을 표면화하는 한 가지 방법은 이 섹션에서 무슨 일이 일어나는지 주목하는 것이라고 제안한다.고마워, 존 커밍스 (대화) 16:47, 2018년 2월 11일 (UTC)[
- 그럼에도 불구하고, 레이아웃 문제를 다루기보다는 종종 바람직하지 않은 별개의 논란이나 비판 부분을 보호하는 편이다. --Francis Schonken (토크) 15:37, 2018년 2월 11일 (UTC)[
- 편집 필터로 하는 게 좋을 것 같은데.나는 이것이 Special:의 역할과 중복될 수도 있지만 구현하는 것이 그리 어렵지 않을 것이라고 생각한다.어쨌든 남용필터/172.Kb.au (토크) 15:06, 2018년 2월 11일 (UTC)[
- 고마워 @Kb.au: 기존 섹션 블랭킹 필터는 제목을 포함한 전체 섹션이 제거되는 경우를 설명하는가?존 커밍스 (대화) 16:33, 2018년 2월 11일 (UTC)[
- 특히 섹션 제목의 제거를 감지한다.개인적으로 나는 다른 어떤 것보다 비판 섹션의 제거를 강조하는 데 이점이 없다고 본다.나도 이 부분들은 대체로 문제가 있다고 생각하는 사람들의 의견에 동의한다. --zzuzz(talk) 17:48, 2018년 2월 11일 (UTC)[ 하라
- 고마워 @Zzuzzzz: 그래서 남용 필터는 이미 이런 종류의 활동을 보여주고 있어, 사람들이 그것을 잡지 못하고 있는 것뿐이야.누군가 편집이 너무 많아서 다 볼 수 없다는 거야?내가 본 것들 중 몇몇은 괜찮은 편집으로 보여질 수 있지만, 많은 사람들은 아니지만, 예를 들어 영국 총리들을 생각한다면, 많은 편집들이 사람들이 지출 스캔들 부분을 삭제하려고 시도하고, 때로는 되돌리지 않는 편집이 일어난다.존 커밍스 (대화) 18:24, 2018년 2월 11일 (UTC)[
- 나는 사람들이 그것을 잡고 있는지 아닌지를 말할 수 없지만 - 그들이 아마도 그렇다는 것을 아는 - 하지만 그들은 이미 다른 부분 블랭킹과 함께 플래그로 표시되어 있다.비판 구간의 삭제가 비판, 칭찬, 업적, 그 밖의 다른 어떤 이름으로도 구역을 제거하는 것보다 더 나쁘다고 누가 말할 것인가?(나는 "Expense scripts"는 영국 정치인들의 공통적인 섹션 헤더라는 점에 주목한다.)그런 필터는 문제가 있는 부분을 감지하는 데 유용할 수 있지만, 의도적이든 아니든 간에 '반전 리스트'라고 생각하고 싶지 않다. --zzuz 19:09, 2018년 2월 11일 (UTC)[
- 고마워 @Zzuzzzz: 그래서 남용 필터는 이미 이런 종류의 활동을 보여주고 있어, 사람들이 그것을 잡지 못하고 있는 것뿐이야.누군가 편집이 너무 많아서 다 볼 수 없다는 거야?내가 본 것들 중 몇몇은 괜찮은 편집으로 보여질 수 있지만, 많은 사람들은 아니지만, 예를 들어 영국 총리들을 생각한다면, 많은 편집들이 사람들이 지출 스캔들 부분을 삭제하려고 시도하고, 때로는 되돌리지 않는 편집이 일어난다.존 커밍스 (대화) 18:24, 2018년 2월 11일 (UTC)[
- 특히 섹션 제목의 제거를 감지한다.개인적으로 나는 다른 어떤 것보다 비판 섹션의 제거를 강조하는 데 이점이 없다고 본다.나도 이 부분들은 대체로 문제가 있다고 생각하는 사람들의 의견에 동의한다. --zzuzz(talk) 17:48, 2018년 2월 11일 (UTC)[ 하라
- 고마워 @Kb.au: 기존 섹션 블랭킹 필터는 제목을 포함한 전체 섹션이 제거되는 경우를 설명하는가?존 커밍스 (대화) 16:33, 2018년 2월 11일 (UTC)[
좋은 생각이 아니다. 그런 부분은 어쨌든 일반적으로 좋지 않은 생각이다.북8000 (대화) 18:54, 2018년 2월 11일 (UTC)[
- 관심 있는 경우 문제의 범위가 무엇인지 평가판 편집 필터를 얻을 수 있는가?만약 편집자들이 구조조정 논란, 즉 제안된 대로 기사의 다른 곳에 포함시킨다면, 그것은 한 가지다.하지만 나는 옹호 편집이 단순히 그러한 자료를 삭제하는 것을 여러 번 본 적이 있다.여기와 여기의 예.이런 종류의 위키 워싱 작업이 채용 게시판 중 하나에 광고되는 것은 꽤 흔한 일이다.◆ 브리(대화) 19시 40분, 2018년 2월 11일 (UTC)[ 하라
- 기껏해야 문제가 되는 "비판" 섹션은 거의 전적으로 부정적이고 모든 경우에서 거의 과도한 가중치를 갖는 경향이 있다.많은 경우에, 그들은 위키피디아 불순물로 보이는 것을 "비판"에 주는 문장을 사용하는데, 이것은 많은 정책들에 반한다.전형적으로 우리는 "조지 그나프는 A를 주장하지만, 모든 사람들은 A가 거짓이라는 것을 안다." 유형 편집.수집(대화)
논평: 아마도 같은 문제를 해결하기 위한 대안적인 제안은 비판, 스캔들, 불법, 유죄 판결 등과 같은 특정 단어가 나타나는 곳에서 많은 글자가 제거된 편집본을 보는 것일 것이다.존 커밍스 (대화) 09:42, 2018년 2월 12일 (UTC)[
- Re. "... 제거됨...": "... 제거 또는 추가됨..."이라고 나는 말하고 싶다.나는 그런 비판들이 제거되는 것보다 부질없는 비난이 더해지는 것에 더 공감하는 어떤 접근법도 반대한다.다시, 과장된 & WP 추가:과도한 비판은 방에 있는 코끼리보다 더 자주, 그리고 많은 기사에 걸쳐서 더 큰 문제다.전반적으로 좋은 아이디어인 "섹션 블랭킹(section blanking)" 태그는 회피적인 검증가능성에 기반한 그러한 섹션의 생성(종종 WP 도입:기사에 BLP 문제 등).나는 그 꼬리표 붙이는 것의 모든 이점 때문에 그 부작용과 함께 살 수 있다.그러나 자주 문제가 되는* 삭제에 대한 *문제성이 적은* 삭제에 대한 *문제성이 적은* 추가에 찬성하는 유지보수 시스템의 추가적인 불균형에 반대한다. 현재, 누군가가 비판을 별도의 절에서 기사의 주요 서술로 병합하고 바람직하지 않은 섹션 헤더를 삭제하는 경우, "섹션 블랭킹"으로 태그가 붙는 경우: 밀어 넣지 마십시오. --F랜시스 숄켄(토크) 10:09, 2018년 2월 12일 (UTC)[
템플릿 공간을 영구적으로 반보호하자는 제안
이 RFC를 닫는 중.참가자의 절반은 모든 템플릿에 대한 반보호에 찬성했고, 나머지 절반의 상당수는 포괄적 접근에 반대하면서도 일정 수 이상의 전횡으로 해당 템플릿을 반보호하는 것에 찬성했다(그림은 다양했다.현재로선 대략적인 합의가 있는 것으로 보이며 최소한 200~250건의 거래로 영구적으로 모든 것을 보호하고 나머지는 건별로 처리한다.Fish+Karate 12:20, 2018년 2월 12일 (UTC)[ |
- 다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.
템플릿 공간(여기 및 여기에 대한 ANI)에 대한 일련의 파괴적 편집에 이어 5k 이상의 트랜클로저로 MusikAmonaltemplate 보호(반대 없는) 템플릿 및 1000개 이상의 트랜클로저로 모든 템플릿을 반보호한다.
오늘 아침 일찍 956개의 전횡이 있는 템플릿이 파손되었다.
템플릿 공간이 광범위하게 순찰되지 않고, 매우 짧은 시간 내에 큰 피해를 줄 수 있는 가능성 때문에, 나는 모든 템플릿이 반보호될 것을 제안한다.이것은 소프트웨어 변화를 수반할 것 같지만, 상대적으로 사용되지 않는 템플릿의 주요 파괴 행위가 오랫동안 방관하지 않도록 하는 유일한 방법이라고 생각한다. 어떻게 고치는지를 우리에게 알려야 할지 모르는, 의심하지 않는 대중들에게 보여질 수 있도록 말이다.
나는 사이버파워678과 이 오프위키에 대해 간략히 논의했는데, 사이버파워678은 최소한의 트랜스런스 카운트(10+)가 있으면 지원하겠다고 했으므로 그 옵션에 순응할 수 있지만, 행정적인 관점에서 볼 때 (10+ 트랜스런스로 템플릿을 자동보호할 수 있는 보호봇을 구할 수 없다면) 모든 것을 일괄적으로 보호하는 것이 더 쉽다고 생각한다.이온. 프라임팩(대화) 18:18, 2017년 12월 21일 (UTC)[ 하라
- 지지자는 아래 Zzuzz의 주장에 따라 전체 공간이 아닌 작은 전폐 번호를
공간화한다.— 여기 18:25, 2017년 12월 21일 (UTC)[ - 그래, 그렇게 해순양성 -- Dlohcierkim (talk) 18:26, 2017년 12월 21일 (UTC)[ 하라
- 보호봇을 갖는 지원이란 누구나 10개 미만의 트랜랜스커런트로 어떤 템플릿이라도 그것을 초월하여 반비례할 수 있다는 것을 의미하기 때문에 약간 그렇다.해로울 가능성이 너무 많지는 않지만 그래도 말이야갤럽터 (pingo mio) 2017년 12월 21일 (UTC) 18:39 (
- 지지자들은 내가 이것을 지지할 것이라고 말했고 나는 이것을 시행하기 위해 쉽게 봇을 만들 수 있다.내가 10개 이상의 전횡을 말했을 때, 나는 기사공간에서 의미했다.따라서 위에서 언급한 것처럼 게임에는 너무 많은 잠재력이 없다.—사이버파워 (메리 크리스마스) 2017년 12월 21일 (UTC) 18:42, 하라
- Net 포지티브 지원.나는 IP와 새로운 편집기를 좋아하지만 그들은 로그인해서 4일을 기다릴 수도 있고 템플리트를 편집하기 위해 4일을 기다릴 수도 있다.L3X1 (distænt write) 18:53, 2017년 12월 21일 (UTC)[
- 나는 즈즈즈의 주장이 설득력이 없다고 생각한다."자동 확증된 양말은 쉽게 찾을 수 있다." 마우스를 계정 만들기 버튼에 갖다 대면 된다.드라이브비 반달은 보통 양말이 아니다.그리고 나는 이것이 탐지가 꽤 어려울 수 있는 단지 공공 기물 파손을 위한 치료법으로 제안되고 있다고 생각하지 않았다.기본 한도를 천 번의 전횡이나 그런 것으로 올리는 것은 괜찮지만, SEMI는 매우 효과적인 반반봉쇄다.또한 "누구나 편집할 수 있는 백과사전"은 여기에 적용되지 않는다.템플릿 공간은 백과사전의 유지와 틀이지 내용은 아니다.L3X1(distænt write) 20:19, 2017년 12월 21일 (UTC)[
- 내가 막은 오토콘 확증 양말의 개수 - 이 양말들은 드라이브 바이(drive-by)가 아니라 이것을 하는 헌신적인 일반 반달들이다.하지만 그것은 사소한 점이다-나는 템플릿의 사용에 대해 강하게 동의하지 않는다.일부는 실제로 유지보수 및 프레임워크 템플릿(특히 대상 템플릿)이지만, 대다수의 템플릿(특히, 등록되지 않은 사용자가 편집한 템플릿)은 목록, 이름, 숫자, 그리고 컨텐츠의 매우 많은 형태를 포함한다. -- zzuz 20:36, 2017년 12월 21일 (UTC)[
- 나는 즈즈즈의 주장이 설득력이 없다고 생각한다."자동 확증된 양말은 쉽게 찾을 수 있다." 마우스를 계정 만들기 버튼에 갖다 대면 된다.드라이브비 반달은 보통 양말이 아니다.그리고 나는 이것이 탐지가 꽤 어려울 수 있는 단지 공공 기물 파손을 위한 치료법으로 제안되고 있다고 생각하지 않았다.기본 한도를 천 번의 전횡이나 그런 것으로 올리는 것은 괜찮지만, SEMI는 매우 효과적인 반반봉쇄다.또한 "누구나 편집할 수 있는 백과사전"은 여기에 적용되지 않는다.템플릿 공간은 백과사전의 유지와 틀이지 내용은 아니다.L3X1(distænt write) 20:19, 2017년 12월 21일 (UTC)[
- CommentPrimfac, 모든 새로운 템플릿을 반비례하는 것보다 기술적 제한과 같은 ACTRIAL을 구축하는 것이 더 쉽지 않을까?토니발리오니 (토크) 2017년 12월 21일 (UTC) 19:08 [