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

다양한 정보 및 정책 페이지에 요청 편집 마법사 추가

이해 상충이 있거나 편집 요청을 적절히 포맷하기 위해 편집 투쟁을 하는 일부 사용자.WP:Edit Request Wizard는 서식을 자동으로 처리하며, 요청의 적절한 표현을 권장해야 한다.WP:관심충돌 및 유료 편집에 관한 정책 및 정보 페이지에서 이 도구를 언급해야 하는가?특히 다음 페이지에서 이 페이지에 연결할 것을 제안한다.

• WP:유급공시 #이해충돌지침,
• WP에서:{{요청 편집}} 템플릿이 언급될 때마다 COI 가이드라인,
• WP:간단한 이해 상충의 편집 요청 및
• WP:요청을 편집하십시오.

또한 마법사 자체에 대한 개선사항에 대한 코멘트는 환영한다.

샘-2727 (대화)20:02, 2020년 9월 4일 (UTC)[응답]

• 난 이게 존재하는지 전혀 몰랐어!실제로 토크 페이지에도 추가하기를 제안하고 싶다. 어떤 패션에서는 노즈백베어(토크) 14:53, 2020년 9월 5일 (UTC)[응답]
  • 만약 당신이 토크 배너 같은 것을 의미한다면, 우리는 (그리고 대부분은 쓸모없는) 그런 것들을 너무 많이 가지고 있기 때문에 나는 요즘 아무도 그것들을 읽는 것을 귀찮게 생각하지 않는다.게다가 그것들은 모바일 기기에는 분명하지 않게 숨겨져 있다.늑장부리는 Reader (대화) 13:52, 2020년 9월 6일 (UTC)[응답]
• 위에서 말했듯이, 이것이 존재하는지 전혀 몰랐다.이런 것은 좀 더 널리 알려야 한다.나는 이 페이지가 앞에서 언급한 페이지들과 연결되어 있다는 것을 지지한다. 그것은 포맷을 훨씬 덜 고통스럽게 만들 것이다.— Berrely(대화 • 기여) 18:18, 2020년 9월 5일(UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평
• 다시:이것이 존재하는지 전혀 몰랐음:새 제품이기 때문일 것이다. Wikipedia_talk를 참조하십시오.찻집#요청 편집 마법사 - 컨텍스트 추가나는 버그를 검토하고 테스트할 수 있는 편집자로부터 듣고 싶다.만약 독립 검토자들이 그것이 준비되었다고 말한다면 나도 지지할 것이다.usedtobecool ☎ 20:29, 2020년 9월 5일 (UTC)[응답]
• 내 생각을 지지해 주는 걸 잊었어나는 약간의 테스트가 필요하다는 것에 동의한다.바라건대 이 RfC의 과정에서 누군가가 모든 것이 예상대로 작동하고 있다는 것을 확인할 수 있기를 바란다.내가 수행한 테스트 사례: 사용자:Sam-2727/ERW 테스트 사례.샘-2727 (대화) 00:12, 2020년 9월 6일 (UTC)[응답]

대학교 색상 데이터를 Wikidata로 마이그레이션

일부 스포츠 팀 컬러 데이터를 로컬 루아 모듈에서 Wikidata로 마이그레이션하는 것에 대한 논의가 진행 중: 모듈 토크:대학 색상#제안: Wikidata로 마이그레이션하십시오.–IagoQnsi (대화) 07:35, 2020년 8월 11일 (UTC)[응답]

• 하지만 "이봐, 우리는 이미 하고 있는 이 일을 위해 위키다타를 사용할 수 있어"의 또 다른 사례도 있다.사양하겠습니다블루보아 (대화) 21:50, 2020년 8월 11일 (UTC)[응답]
• 반대는 단지 미묘한 파괴 행위를 더 쉽게 만드는 데 도움이 될 것이다.이득이 없다.DES^(talk)_{DESiegel Contribs} 02:14, 2020년 8월 13일 (UTC)[응답]
  • @DESiegel:모듈토크 페이지에서 논의했듯이 자료 모니터링과 반달리즘 퇴치 방법은 얼마든지 있다.여기 대학 스포츠팀의 가장 최근의 색깔 특성 변화를 보여주는 질문이 있다.봇은 위키피디아에 있는 페이지를 이러한 쿼리 결과로 업데이트하고, 잘못된 색상을 쉽게 발견할 수 있도록 시각적으로 표시하도록 쉽게 구성할 수 있다.만약 공공 기물 파손이 만연했다면 위키다타는 위키피디아에 있는 것과 동일한 보호 도구를 가지고 있고, 그곳의 정책은 가시성이 높은 항목이 필요하다면 무기한 보호를 받을 자격이 있다고 말한다.

  "무효익" 부분에 대해서는, 이것이 영어 위키백과에 한정된 혜택을 주는 것은 사실이다.그러나 그것은 다른 위키피디아와 위키미디어 커뮤니티의 나머지 부분에 혜택을 줄 수 있는 큰 잠재력을 가지고 있다.대학 스포츠 팀 컬러의 정기적인 갱신형 레퍼런스 지원 데이터베이스를 보유하는 것은 일반 대중에게 큰 가치가 있다; 나는 이것이 멋진 데이터 시각화에 이용될 것이라고 예상할 수 있다.–IagoQnsi (대화) 00:09, 2020년 8월 14일 (UTC)[응답]

  위키다타를 운영하는 사람들이 이 데이터를 수입하고 싶다면, 그들은 자유롭게 그렇게 할 수 있고 다른 프로젝트들은 그것을 자유롭게 사용할 수 있다.현시점에서 나는 위키다타에 대해 행해진 소싱과 검증을 신뢰하지 않으며, 어떤 en에 있는 어떤 정보에도 강력히 반대한다.위키다타에서 자동으로 위키백과 기사를 수입하고 있다.예외는 없다.나는 몇 년 전에 RFC에서 기사에서는 위키다타를 전혀 사용하지 말아야 한다고 의견을 냈고, 나는 오늘날 그러한 견해를 고수하고 있다.나는 여기서 위키다타의 모든 이용 확대에 반대한다.DES 00:15, 2020년 8월 14일 (UTC)[응답]

• 지원 혜택은 많고 IagoQnsi는 더 많은 것을 말할 수 있을 것 같다.300개 이상의 모든 위키에서 액세스할 수 있도록 데이터를 중앙 집중화하는 것이 타당하다.300이 아닌 한 곳에서만 데이터를 변경하면 된다.한 곳에서 공공 기물 파손 여부를 감시한다.실수를 한 곳에 고치다.기타.. 강력한 방법을 수용하기 위한 거래의 일부가 될 공공 기물 파손 감시 도구와 방법이 있다.IagoQnsi가 지적한 바와 같이, 현재 대학 스포츠팀만이 아닌 중앙 컬러 데이터베이스로 구축될 수 있는 미래의 어플리케이션은 제공되지 않고 있다. -- GreenC 02:54, 2020년 8월 13일 (UTC)[응답]
• SupportModule:대학 색깔/데이터는 데이터를 저장하기 위한 끔찍한 해킹이며, 데이터를 생성하지 말았어야 했으며, 그 안에서 무언가를 바꾸기를 원하는 누구에게나 사용적합성의 악몽이다.Wikidata는 제약 조건 위반과 데이터 쿼리를 통해 더 나은 모니터링 도구를 사용하여 보다 사용자 친화적이고 교차 위키 방식으로 이 문제를 처리할 수 있다.고마워요.마이크 필(토크) 19:45, 2020년 8월 13일 (UTC)[응답]
  • 질문:모듈의 794 인용 템플릿:대학 컬러/데이터는 위키다타에 저장? --RexxS (토크) 23:11, 2020년 8월 13일 (UTC)[응답]
    • @RexxS: Wikidata는 문장에 대한 참조 첨부를 지원한다. Wikidata: 참조:도움말: 리소스.나는 그들이 사용하는 매개 변수의 전체 목록을 얻기 위해 모든 참조 템플릿에 대해 스크립트를 실행했다: 액세스 날짜, 아카이브 날짜, 아카이브url, 날짜, 언어, 페이지, 게시자, 제목, URL 상태, 웹 사이트, 작업, 연도.그 모든 것들은 위키다타에 상응하는 속성을 가지고 있기 때문에 꽤 쉽게 수입될 수 있다.속성 '퍼블리셔', 'website', 'work'는 위키다타 항목에 매핑되어야 할 것이다(해당되는 위키다타 속성이 문자열보다는 항목을 취하기 때문이다).하지만, 방금 확인했는데, 그 속성들을 모두 합치면 100개도 안 돼서 OpenRefine과 조정하기가 쉬울 거야.–IagoQnsi (대화) 23:45, 2020년 8월 13일 (UTC)[응답]

      @IagoQnsi: MOS를 한 번 보십시오.인덴트믹스.당신은 스크린 리더를 사용하는 모든 사람들을 위해 이 실을 엉망으로 만들었다.(응답: 고정! –이아고Qnsi (대화) 01:35, 2020년 8월 14일 (UTC)별로. --RexxS (대화) 01:50, 2020년 8월 14일 (UTC)[응답]

      그렇다, 데이터 유형의 불일치를 수용하기 위해 수백 개의 새로운 Wikidata 항목을 생성해야 한다 하더라도(그리고 새로운 인용문이 추가될 때마다 더 많이) 대부분의 매개변수를 위키다타에 저장할 수 있을 것이다.인용문을 정확하게 재구성할 수 있도록 사용된 인용문 템플릿 유형을 어떻게 저장하시겠습니까?그런 종류의 문제를 고려해 볼 때, Wikidata가 정말로 이런 종류의 데이터를 저장하기에 가장 좋은 장소인지 자문해 볼 필요가 있다. --RexS (토크) 00:51, 2020년 8월 14일 (UTC)[응답]

      @RexxS: 새로운 아이템을 많이 만들 필요는 없을 것 같아, 만약 있다면.내가 말했듯이, 그 794개의 인용구들은 위키다타 항목에 매핑되어야 하는 매개변수의 100가지 용도를 가지고 있다.그리고 그러한 사용의 대부분은 새로운 항목을 요구하지 않을 것이다. 대부분의 참고문헌은 대학에서 출판한 것이고 우리는 이미 모든 대학의 WD 항목을 가지고 있다.

      사용되는 템플릿의 종류에 대해서는 이러한 인용문 모두 {{cite web} 또는 {{cite manual}} 중 하나를 사용한다.구분이 다소 자의적인 것 같지만(즉, 'cite web'의 많은 것들은 매뉴얼로 간주되어야 할 것 같다), 원한다면 'cite 매뉴얼'에 대한 참조 유형(P3865)=사용자 가이드(Q1057179)를 저장할 수 있다.그러나 궁극적으로 여기서의 목표는 정확히 동일한 기초의 위키텍스트를 생성할 수 있는 것이 아니라, 동일한 의미적 의미를 지닌 인용문을 생성하는 것이다.실제로, 결과적으로 인용문은 훨씬 더 깨끗해질 것이다 – 위키피디아에서는 '일'과 '출판사' 그리고 '제목' 사이에 다소 무작위로 정보를 배포하는 경우가 많지만, 위키다타는 더 일관성을 유지하도록 강요한다.–IagoQnsi (대화) 01:35, 2020년 8월 14일 (UTC)[응답]

      @IagoQnsi: 대학 컬러를 사용하는 편집자들이 정확한 바탕을 이루는 위키텍스트를 재현하는 데 상당히 관심이 있을 것 같다는 것을 발견할 수 있을 것 같다.인용문을 여러 개의 명백한 참조 한정자로 구성하는 모든 작업을 포함하여 Wikidata에 대학 색상을 추가하는 작업과 함께 스크리펀토 모듈에 항목을 추가하는 편집자의 워크플로우(단순하지는 않지만 복사할 예가 많고 인용문이 익숙할 형식을 사용함)를 고려해 본 적이 있는가?s. 생각해 볼 만한 가치가 있는. --RexxS (대화) 01:50, 2020년 8월 14일 (UTC)[응답]

      @RexxS: 정확히 쓰여진 대로 재현하지 못한 것이 아니라, 현재 쓰여진 방식보다 더 잘 보이도록 정리하는 것이 훨씬 더 이치에 맞는다는 것이다.이렇게 지저분한 것들을 완벽하게 보존할 이유는 없다. title=Color {{!}} Brand and Messaging {{!}} University of Colorado at Boulder예를 들어, 다음과 같이 인용하십시오.{{cite web url=https://brand.cornell.edu/design-center/colors/ title=Colors publisher=Cornell University Brand Center accessdate=July 17, 2019}}"코넬 대학 브랜드 센터"의 새로운 아이템을 만들 가치가 없기 때문에 그것을 위키다타로 이전할 때, 나는 이것을 다음과 같이 변화시킬 것 같다.

• • • 이것은 정확히 같은 것은 아니지만, 기본적으로 개선은 아니더라도 중립적인 변화다.다시{{표창}로}그 데이터를 그리고 올해 완벽하게 흡족한 표창:.mw-parser-output cite.citation{font-style:상속을 하다;word-wrap:break-word}.mw-parser-output .citation q{인용:")"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output.id-lock-freea,.mw-parser-output .citation다.a,.mw-parser-output .citationa,.mw-parser-output .citation .cs1-lock-registration{.cs1-lock-limited.cs1-lock-free a{배경:linear-gradient(transparent,transparent),url("//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg")right 0.1emcenter/9pxno-repeat}.mw-parser-outputa,.mw-parser-output .id-lock-registration .id-lock-limited.배경:linear-gradient(transparent,transparent),url("//upload.wikimedia.org/wikipedia/commons/d/d6/Lock-gray-alt-2.svg")right 0.1em center/9pxno-repeat}.mw-parser-output .id-lock-subscription a,.mw-parser-output .citation .cs1-lock-subscription{.배경:linear-gradient(transparent,transparent),url("//upload.wikimedia.org/wikipedia/commons/a/aa/Lock-red-alt-2.svg")right 0.1em center/9pxno-repeat}.mw-parser-output{배경 .cs1-ws-icon:linear-gradient(transparent,transparent),url("//upload.wikimedia.org/wikipedia/commons/4/4c/Wikisource-logo.svg")right 0.1emcenter/12pxno-repeat}.mw.-parser-output .cs1-code{색:상속을 하다;배경:상속을 하다;국경 아무 것도 없고 패딩: 물려받다}.mw-parser-output .cs1-hidden-error{디스플레이:아무도, 색:#d33}.mw-parser-output .cs1-visible-error{색:#d33}.mw-parser-output .cs1-maint{디스플레이:아무도, 색:#3a3, margin-left:0.3em}.mw-parser-output .cs1-format{:95%font-size}.mw-parser-output .cs1-kern-left{.Padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflinkᆫ"색", Cornell대학 브랜드 센터, 코넬 대학 7월 17일 2019년 비교(에 회수된, 여기에 원래 표창:"색".코넬 대학 브랜드 센터.Retrieved 7월 17일 2019년.).–IagoQnsi(이야기)02:29, 8월 14일 2020년(CoordinatedUniversalTime)[답장].

      @IagoQnsi: MOS를 관찰해 보십시오.인덴트믹스.너처럼 들여쓰기를 망치는 것은 화면 판독기에 그리 친절하지 않다.

      WP를 읽는 경우:CITEVAR, 나는 당신이 한 변화가 중립과는 거리가 멀다는 것을 알게 될 것이라고 생각한다.제목과 출판사의 명백한 재할당과는 별도로 인용 스타일을 {{cite web}}에서 {{citation}}(으)로 변경하셨는데, 절대 있어서는 안 될 일이었습니다.액세스 날짜도 mdy 형식으로 설정하십시오.Wikidata 레코드에서 그 정보를 어떻게 복구하셨습니까?내가 지난 7년간 모듈에서 고심해 온 문제들은 다음과 같다.위키다타IB와 나는 당신이 어떻게 해결했다고 생각하는지 보고 싶을 것이다. --RexxS (대화) 03:51, 2020년 8월 14일 (UTC)[응답]

• outdented - GhostInThe^{talk to me} Machine 10:16, 2020년 8월 29일 (UTC)[응답]
• @RexxS: 이미 완벽하게 괜찮은 인용구를 바꾸지 않을 필요성은 이해하지만, 여기서는 그렇지 않다.이 모듈의 인용구들을 훑어보면, 그것들 사이에 일관성이 거의 없다.그들은 인용문과 이탤릭체를 번갈아 쓴다; 일부는 임의로 모든 대문자로 되어 있다; 출판사의 이름은 때로는 제목 필드에, 때로는 작품/웹사이트 필드에, 때로는 완전히 존재하지 않는다.일반적으로, 이 모든 것들은 작가들이 URL에 붙여넣고, 그들의 인용 도구에서 "자동 채우기"를 클릭하며, 그것을 하루라고 부르는 것처럼 보인다.나는 현존하는 어떤 인용문 스타일을 보존하고 싶다. 하지만 여기에는 인용문이 없다.
• 내용과 스타일을 구분하는 것은 정말로 위키다타의 전체 목적이다. 당신은 어떤 인용 스타일, 어떤 날짜 형식, 심지어 당신이 원하는 어떤 언어라도 가지고 위키다타의 정보를 표시할 수 있다.{{citation}}}을(를) 사용하고 있는 기사에서 이러한 인용문 중 하나를 보여주고 싶다면 그렇게 할 수 있고, {{cite web}}을(를) 사용하거나 다른 것을 사용하고 싶다면 그렇게 할 수도 있다.Wikidata로 마이그레이션하는 목적은 특정 발표 스타일을 강요하는 것이 아니라 단순히 발표와 데이터를 분리하는 것이다.–IagoQnsi (대화) 06:18, 2020년 8월 14일 (UTC)[응답]

  @IagoQnsi: 모듈에 저장되어 있는 인용구에 대해 잘못 알고 있는 것 같아.대학 색상/데이터.ISO 형식의 하나의 액세스 날짜를 제외하고, 그것들은 현저하게 일치한다.인용구에 하드 코딩된 이탤릭체의 예는 단 한 가지도 없다."문구와 이탤릭체"에 대한 당신의 불만은 MOS의 결과물이다.ILT : "작품 제목(책, 영화, 텔레비전 시리즈, 명명된 전시, 컴퓨터 게임, 음악 앨범, 그림 등)에 이탤릭체를 사용하라. 기사 제목, 장, 노래, 에피소드, 연구 논문, 기타 짧은 작품들은 대신 큰따옴표를 받는다.인용 템플릿은 우리의 스타일 매뉴얼에 맞는 적절한 형식을 사용할 수 있을 만큼 충분히 스마트하다.사용된 인용 스타일은 WP:CS1과 당신이 마음대로 다른 스타일로 바꿀 수 있다고 생각한다면 당신은 큰 문제에 직면할 것이다.당신은 그것이 어떻게 저장되든 사용된 인용문 스타일을 보존해야 할 것이다. 그래서 Wikidata가 인용문을 위한 실행 가능한 저장 메커니즘이 되기 전에 문제가 해결되어야 할 것이다.

  프리젠테이션에서 콘텐츠를 분리하는 것은 Wikidata의 실제적인 것이지 그것의 목적("데이터 저장")이 아니다.불행히도 위키다타는 현재 일반 데이터의 수입을 수용하도록 구조화되어 있으며, 수출 및 재사용 방법에 대해서는 거의 고려하지 않고 있다.위키백과 기사의 데이터베이스 백엔드로 사용되려면 해당 기사에서 현재 사용 중인 프리젠테이션 선택사항을 존중할 수 있어야 한다.인용 템플릿은 당신에게 많은 일을 할 수 있다(그들은 심지어 하나를 설정한 기사에서 날짜 형식을 감지할 수도 있다). 그러나, 특정 기사에 사용되어야 할 인용 방식을 결정하는 것은 현재 위키 텍스트 이외의 다른 형식으로 인용문을 저장하려는 시도의 걸림돌이다. --RexxS (대화) 12:45, 2020년 8월 14일(U)TC)[응답하라]

  @RexxS: 인용 스타일이 위키다타에 저장되었다면, WP 위반을 야기할 것이다.CITEVAR, 그들을 막지 마라.이렇게 하면 다음과 같은 결과를 얻을 수 있다.ClaimX위키다타는 두 개의 위키백과 기사에서 사용된다.ArticleA({{property web} 사용) 및ArticleB({{citation}} 사용)이제 사용자:업데이트 예ClaimX{{ternal web}}}을(를) 사용하려면.이 가설에서 우리는 스타일 정보를 위키다타에 저장하고 있는데, 그 의미는 다음과 같은 것이다.ClaimX에 나타날 것이다.ArticleB{{ternal web}}} 포함.오 안돼, 이것은 WP를 위반한다.CITEVAR!

  따라서, 우리는 대신 다음과 같이 한다.ClaimX위키다타에는 정의된 스타일이 없는 인용문이 있다. ArticleA그리고ArticleB둘 다 수입하는 것ClaimX그러나 그들은 각각 다른 스타일로 그것을 렌더링한다.사용자:예:편집 작업ClaimX.Wikidata는 인용 스타일 정보를 저장하지 않기 때문에 인용문은 계속해서 {{cite web}에 나타날 것이다.ArticleA그리고 {{citation}}}에ArticleB인용문은 일관성을 유지한다. WP:CITEVAR은 복종하고, 모두가 행복하다.–IagoQnsi (대화) 05:31, 2020년 8월 18일 (UTC)[응답]

  @IagoQnsi: ArticleA"그리고 둘 다 수입하지만 각각 다른 스타일로 렌더링한다." 따라서 인용문은 각 기사에 대해 수작업으로 제작되어야 하며, 따라서 모듈의 대상을 물리쳐야 한다.자동으로 정보를 렌더링하기 위한 대학 색상.모듈만 보십시오.College color/doc #확실한 예에 대한 테스트 테이블.테이블은 한 줄에 의해 생성된다.{{#invoke:{{BASEPAGENAME}}/contrast testtable style=background:#FDFDFD }}그러나 원하는 형식으로 참조를 제공할 수 있도록 1132개의 행을 개별적으로 작성해야 한다.

  모듈의 전체 요점:대학 컬러는 팀별 인용 스타일과 함께 컬러 배색을 저장하는 것이다.그 장점은 아빌린 크리스티안 와일드캣츠가 영스타운 주 펭귄과 같은 기준 스타일을 가질 필요가 없다는 것이다.단점은 아빌레네 크리스티안 와일드캣츠에 대한 다른 기사가 쓰여진다면 기본 기사와 같은 인용 방식이 필요하지만, 그것은 작가들과 유지 관리자들이 취해온 경로로, 단지 인용 양식을 저장하지 않기 위해서 각 기사에 더 많은 작업을 하도록 강요해서는 안 된다고 본다.솔루션이 전달할 수 없음. --RexxS (대화) 17:17, 2020년 8월 18일 (UTC)[응답]

  @RexxS: 인용문은 개별적으로 렌더링할 필요가 없을 것이다. 인용문 전체를 렌더링하는 템플릿/모듈이 있을 것이다. 그리고 그 템플릿에 모든 인용문들을 스타일링하는 방법을 알려주기만 하면 된다.다음과 같은 경우:{{#invoke:{{BASEPAGENAME}}/contrast testtable style=background:#FDFDFD citation-style=CS1 date-format=mdy }}–IagoQnsi (대화) 20:11, 2020년 8월 18일 (UTC)[응답]

  @IagoQnsi: 그럼 1132행으로 다른 템플릿/모듈을 작성해서 전부 표시만 하는 겁니까?우리는 이미 그것을 한 줄로 하는 모듈을 가지고 있다.그렇지 않으면, 어떻게 할 것인가?{{#invoke:{{BASEPAGENAME}}/contrast testtable style=background:#FDFDFD ''' citation-style=CS1''' date-format=mdy }}의 가치를 알다 citation-style=그래? 나머지 자료와 함께 위키다타에 저장하지 않을 거라고 말했잖아. --RexxS (토크) 02:24, 2020년 8월 19일 (UTC)[응답]

  @RexxS: 당신의 주장에 대한 나의 이해는 기본적으로 어떤 주어진 인용문의 스타일은 절대 바뀌지 말아야 한다는 것이다.그러나 WP는 그렇게 생각하지 않는다.CITEVAR은 말한다.그것은 편집자들이 기사의 확립된 인용 스타일을 바꾸려고 시도해서는 안 된다고 읽는다(강조 추가).인용 스타일은 인용 기준이 아닌 기사별로 설정된다.그 정책에 따르면, 어떤 인용문도 정해진 형식을 가져야 할 이유가 없다. 대신 인용문이 나오는 글의 형식으로 제공해야 한다.그것이 현재의 정책이 시사하는 바이며, 솔직히 가장 이치에 맞는 말이다.

  예를 들어보자.나(인간 편집자)가 인용으로 뒷받침되는 사실을 에서 보았다고 가정하자.ArticleA, 그리고 나는 그 사실(및 그 인용문)을 에 포함시키는 것 또한 유용할 것이라고 결정했다.ArticleB. 이 정보를 복사하는 과정에서 반드시 인용문을 편집하여 인용문 양식을ArticleB,그렇지 않을까?인용 부호가 다음과 같을 경우ArticleA{{citation}}스타일이지만ArticleB{{cite web}}을(를) 사용하고, 그러면 그 인용문을 {{cite web}을(를) 사용하기 위해 변환해야겠죠?새로운 기사로 옮길 때 인용의 스타일을 바꾸는 것이 내가 받아들일 수 있다면, 왜 위키다타도 이렇게 해도 괜찮지 않을까?–IagoQnsi (대화) 17:59, 2020년 8월 26일 (UTC)[응답]

  @IagoQnsi: 당신은 이 모듈이 어떻게 사용되는지 오해하는 것 같다.각 색상 입력은 효과적으로 하나의 기사에 적용되며, 데이터 모듈은 해당 기사의 팀에 대한 색상 정보뿐만 아니라 해당 기사에 사용된 인용 스타일을 저장한다.이젠 그런 식이다.정보를 저장할 수 있는 계획의 기능에 맞게 작동 방식을 변경하고 사용할 인용 스타일에 대한 정보를 삭제하려는 경우.이 모듈을 만들고 사용하는 편집자들은 이제 간단한 방법으로 이 모듈을 사용한다. 그리고 당신은 그들에게 그들의 인용 스타일이 있는 별도의 기사 목록을 로컬에 저장하거나 각 기사에 인용 스타일을 수동으로 삽입하도록 요구할 것이다. 당신이 제안한 해결책이 현재 그들이 일하고 있는 방식으로는 작동할 수 없기 때문이다.그것은 개를 흔드는 꼬리다.

  당신의 예를 보자.A 팀의 색상이 에 사용되었다고 가정할 때ArticleA에 있어서 어느 정도 유용할 수 있다.ArticleB나는 그것이 사실이라는 증거가 없다고 본다.현재의 제도하에서는, 그것은 아직 달성하기에 사소한 것이다.ArticleB인용 스타일이 와 같다.ArticleA; 관련 템플릿만 복사하면 인용문이 생성된다.스타일이 다를 경우 인용문을 수동으로 업데이트해야 한다.그러나, 당신의 계획에서 인용문은 각 지역별로 설정되어야 할 것이다.ArticleA의 기존 스타일에 맞는 경우(그것이 어떻게 이루어질 수 있는지에 대한 어떠한 예도 제시하지 않은 경우)에 사용하고 싶다면 로컬로 다시 설정ArticleB스타일이 맞든 안 맞든나는 그것을 장점으로 보지 않는다.각 팀의 기사에 사용된 인용 스타일을 모듈에 저장된 정보와 분리할 수 있는 입증된 이점은 없다.현재 데이터 모듈에는 기사와 입력 사이에 일대일 대응 방식이 효과적으로 존재하며, 이를 통해 간단한 저장 방법이 가능하다.편집자가 기사와 색상 정보 간의 2대 1(또는 그 이상) 서신을 원하는 곳이 있을 수 있도록 좀 더 복잡한 스토리지 시스템(Wikidata에 대한 일부 정보, 로컬에서 일부 정보)을 사용하는 것을 지지하지만, 이에 대한 필요성이나 요구를 입증하지 못하고 있다. --RexS (대화) 19:06, 2020년 8월 26일 (UTC)[응답]

  @RexxS: 이 모듈은 단문제로 전혀 사용되지 않는다.각 학교의 색깔은 대학 스포츠를 다루는 많은 기사들을 가지고 있기 때문에 아마도 수백 개의 기사들에 사용된다.예를 들어, 듀크 대학교, 듀크 블루 데블스, 듀크 블루 데블스 남자 농구, 1990–91 듀크 블루 데블스 남자 농구팀, 애틀랜틱 코스트 컨퍼런스, 2018–19 애틀랜틱 코스트 컨퍼런스 남자 농구 시즌, 그리고 그 기사들의 모든 다양성(즉 다른 해/시즌, 다른 해들)에서 볼 수 있다.rts). 만약 우리가 위키다타에 자료를 전송한다면, 색깔은 또한 위키백과의 다른 판에 있는 많은 페이지들에 의해 사용될 것이고, 아마도 모두 그들만의 인용 스타일을 가지고 있을 것이다.

  스타일을 정하는 것은 어렵지 않을 것이다.아마도, 우리는 CS1 스타일로 디폴트 할 것이다. CS1 스타일은 내가 접한 대학 스포츠 기사의 압도적 다수에 사용된다.그러나 이것은 {{College color box 인용=cs2}}(예: {{College color box 인용=cs2}}) 또는 기사별로 쉽게 오버라이드될 수 있으며, 현재 {{Use mdy date}와 같은 템플릿으로 작동할 수 있다.현재 이 모듈의 인용문은 전혀 기사로 옮겨지지 않기 때문에, 이 모든 것은 현재 가설이다.–iagoQnsi (대화) 19:52, 2020년 8월 26일 (UTC)[응답]

  @IagoQnsi: 현재 모듈 내에 저장된 인용문을 사용하고자 하는 어떤 기사도 그렇게 사소한 것으로 할 수 있다.모듈에 저장된 인용문은 {{cite web}}과(와) {{cite manual}}이(가) 거의 동일한 혼합물은 {{cite book}}.

  당신은 "스타일을 정하는 것은 어렵지 않을 것"이라고 주장한다. 이것은 쉽게 무시될 수 있다... {{CS2}}"와 같은 것을 사용하는 것" 여기 인용문이 있다.{{cite manual url=http://www.thepacwest.com/documents/2015/6/22//pacWest_colorways_spring2015.pdf title=Pacific West Conference Visual Identity Standards accessdate=March 23, 2017}}. CS2를 어떻게 설정하는 것이 어렵지 않은지 보여 주었으면 좋겠다.당신의 해결책을 얼마나 기다려야 할지 대략 알려달라. --RexxS (대화) 21:30, 2020년 8월 27일 (UTC)[응답]

  @RexxS:Wikidata에 저장되어 있는 그 인용문을 가지고 있다면, 어느 쪽이든 쉽게 뱉어낼 수 있다.파라미터는 {{cite manual}}과(와) {{citation}사이에 정확히 동일하다. 사실 둘 다 동일한 기본 모듈에 의존한다.우리의 템플릿은 모든 참조 파라미터를 모듈로 전달한다.인용/CS1을 선택한 다음, 페이지가 CS2를 사용할 경우 인용 클래스를 "초대"로 설정하거나, 페이지가 CS1을 사용할 경우 CS1 값(예: 책, 웹, 뉴스 등) 중 하나로 설정하십시오.어떤 CS1 값을 사용할지 결정하려면 약간의 논리가 있어야 할 것이다. 기본적으로 참조에 참조 유형(P3865) 값이 포함되어 있으면 해당 매체 유형에 해당하는 인용 클래스를 사용할 것이다. 그렇지 않으면, {{citation}}이(가) 사용되는 것과 같이 포함된 속성을 바탕으로 최선의 추측을 할 수 있을 것이다.–IagoQnsi (대화) 22:45, 2020년 8월 27일 (UTC)[응답]

  @iagoQnsi:좋아, 보여줘.나는 그 "어떤 CS1 값을 사용할지 결정하는 약간의 논리"에 정말 관심이 있다.그렇다면 CS1과 CS2에서 다르게 정의되어 있는 장과 기사 제목을 어떻게 다룰 것인지 물어볼게. --RexxS (토크) 23:20, 2020년 8월 27일 (UTC)[응답]

  @RexxS: 참조 유형(P3865)이 설정되어 있으면 참조 유형 항목을 인용 클래스 값(예: 지도책(Q571)에서 인용 클래스='book' 등으로)에 1:1 배열 매핑만 하면 된다.P3865가 설정되어 있지 않으면 어떤 속성이 설정되어 있는지 살펴본다.매우 기본적인 해결책은 볼륨/편집/페이지가 설정된 경우 '책'을 사용하고, 그렇지 않은 경우 '웹'을 사용하는 것이다.물론 그것은 강력한 해결책은 아니지만, 이미 이 모듈의 모든 기존 참조를 처리하기에 충분하다.위키피디아에 관한 모든 인용문을 위키다타로 옮기자고 제안하는 것이 아니다. 나는 단지 이 모듈에 있는 인용문들을 옮기자고 제안하는 것이다.사용 중이고 엣지 케이스가 점점 많아지기 시작하면 시간이 지날수록 구현이 좋아질 것이다. –IagoQnsi (토크) 23:56, 2020년 8월 27일 (UTC)[응답]

  @iagoQnsi: 아무것도 보여주지 않은 것 같은데.그리고 그런 종류의 참고문헌(P3865)이 당신이 생각하는 것을 의미하지는 않을 것 같다. --RexxS (토크) 00:14, 2020년 8월 28일 (UTC)[응답]

• 반대하라, 나는 이 프로젝트가 뒷문을 통해 위키다타에 더 의존하게 만드는 많은 시도들 중 어떤 것도 계속 반대할 것이기 때문이다.데시겔은 바로 이 경우에 그것을 가지고 있다.아무리 안 좋은 일이 있어도, 그 곳은 더 낫지 않다. - 시투시 (대화) 19:48, 2020년 8월 13일 (UTC) 하지만, 잠깐만, 토론은 다른 것 같아? - 시투시 (대화) 19:49, 2020년 8월 13일 (UTC)[응답]
• 지원 나는 보통 WikiData로 물건을 이전하는 것에 대해 의심스럽지만, 이것은 공공 기물 파손의 측면에서 위험성이 낮은 것 같다.대부분의 사람들은 그 가치가 색이 아닌지를 인식할 것이고, 비록 미묘하다고 해도, 모든 이미지에서 정확한 색이 무엇인지 명백해야 한다.다른 이들은 마이그레이션될 경우 컨텐츠 개선이 이루어지므로 순 개선처럼 보인다는 점에 주목한다.— Wug·a·po·des 19:57, 2020년 8월 13일 (UTC)[응답]
• 지지하다.Wikidata가 가장 잘 작동하는 데이터 유형.– 피누서톱 (토크 ⋅ 기여) 02:34, 2020년 8월 14일 (UTC)[응답]
• 반대. 위에 이아고온시는 "데이터를 감시하고 반달리즘과 싸우는 방법은 얼마든지 있다"고 주장하며, 이용할 수 있는 질의를 덧붙인다.문제; 이것은 다른 사이트에서 (감시자와 통합되지 않은) 추가적인 조치로서, 좋지 않은 결과를 초래한다.무엇이 바뀌었거나 어떤 diff(날짜만)인지를 보여주지 않을 뿐만 아니라, 색상 변경과 무관한 변화를 포함하고 있다.예: 2020년 5월 24일 포틀랜드 파일럿에 대한 엔트리가 있지만, 그 날짜의 유일한 변경 사항은 중국어 레이블[1]을 추가하는 봇이다.쿼리는 봇의 변화를 필터링하거나 표시하지 않는다.분명히 그 질의는 과거 어느 시점에 공식 색상이 변경된 페이지를 보여주고, 그 변경이 무엇이었든 간에 가장 최근에 위키다타 항목에 변경된 날짜를 보여준다.즉, 청구와는 반대로, 가장 최근의 출품작들은 색깔에 대한 최근의 변화를 보여주지 않을 것이기 때문에, 그 질의를 가지고 이것을 감시하는 것은 불가능하다는 것을 의미한다.나는 윈킹 시스템을 모니터링하기 어려운 시스템으로 바꿀 이유가 없다고 본다.다른 위키언어가 필요하다면, 여기, 위키다타에 모듈의 변화를 베끼는 봇을 쓰면서 위키다타를 우리와 동기화시키는 것이 더 좋을 것이다.하지만 위키다타에게 통제권을 주는 것은?사양하겠습니다프람 (토크) 11:51, 2020년 8월 14일 (UTC)[응답]
  • @Fram: 그 질문에 대한 사과; 나는 그것을 이해하지 못했다.그러나, 봇이 쿼리로 목록을 업데이트하도록 하는 접근법은 의도한 대로 계속 작동할 것이다.매일/시간/일시/일시/일시마다 봇이 로컬로 저장된 목록을 업데이트하는 경우 목록 페이지를 감시 목록에 추가하여 변경 사항을 모니터링하는 것이 쉬울 것이다.목록 페이지는 색상이 변경될 때만 업데이트된다.–IagoQnsi (대화) 04:46, 2020년 8월 18일 (UTC)[응답]
• DES.와 Fram에 의해 반대한다.위키다타에서 온 누군가에게 이 자료를 복사해서 그들이 원한다면 다른 위키피디아에 사용할 수 있도록 게시하라고 제안하라.그러나 이 데이터의 자체 호스팅을 마이그레이션하는 데 있어 en-WP에 대한 혜택은 전혀 없으며, 지역 기고자들의 편집성 감소 측면에서 위험은 0이 아니다. -- Eurialus (talk) 12:10, 2020년 8월 14일 (UTC)[응답]
• 실제로 반대하다.그것은 위키다타가 엔위키만큼 많은 관심을 가지고 있다면 잘 될 수 있는 고귀한 생각이다.그러나 경쟁자의 색채계획을 똥과 토사로 바꾸는 것은 너무나 유혹적이며, 눈치채는 무심코 편집하는 사람은 코드와 데이터의 미로를 통해 문제의 근원으로 가는 길을 찾지 못할 수도 있다.mw:다국어 템플릿 및 모듈이 좋은 대안이 될 수 있다.Certes (talk) 2020년 8월 14일 12시 40분 (UTC)[응답]

  왜 MediaWiki.org의 다국어 템플릿이 위키다타에 대한 진술보다 공공 기물 파손에 덜 노출되는가?* 삐삐 _{it has begun...}* 13:52, 2020년 8월 14일 (UTC)[응답]

  좋은 질문.아마도 그들은 찾고 편집하는 것이 더 어려우며, 코더의 감시 목록에 있을 것이다.만약 mw:가 공공 기물 파손을 일으키기 쉽다면, 우리는 있는 그대로 내버려둬야 한다.Certes (talk) 13:58, 2020년 8월 14일 (UTC)[응답]

  (ec) 모든 Wikidata에 대한 무료와는 달리, 그 의도는 이러한 다국어 템플릿이 우리의 템플릿 편집자와 비교 가능한 그룹에 의해서만 편집 가능하도록 만드는 것이라고 생각한다(그러나 분명히 엔위키 편집자에 국한되지는 않음).만약 그렇지 않다면, 이것은 물론 해결책이 아니다.프람 (대화) 2020년 8월 14일 (UTC) 14:00[응답]

  다국어 템플릿과 모듈이 반달리즘과 관련이 없는 이유로 강력히 반대하기 때문에 이 문제에 대답할 수 있는 최적의 사람은 아닐 것이다(내가 mw:글로벌 템플리트/토론/반대) 그러나 편집 가능한 사용자를 제한할 어떤 확립된 계획인지 잘 모르겠다.게다가, 비다국어 다국어 템플릿은 종종 Commons의 표 형식 데이터에 의존하는데, 마찬가지로 공공 기물 파손을 방지하기 위해 보호되어야 할 수도 있다.* 삐삐 * 14:39, 2020년 8월 14일 (UTC)[응답]

  이 프로젝트는 봇 대신 도구를 사용하는 것으로 전환되었고, 이것은 템플릿 자체에 대한 공공 기물 파괴에 대한 우려를 불식시키는 것으로 보인다.아마도 더 중요한 것은 템플릿이 사용하는 데이터 집합에 대한 공공 기물 파괴에 대한 우려와 물론 코드 팽창의 영구화에 대한 나의 독립적인 우려일 것이다.* Papery * 16:24, 2020년 8월 14일 (UTC)[응답]

• GreenC, Mike 및 기타 지원.레만 13:26, 2020년 8월 14일 (UTC)[응답]
• 반대 DESiegel의 말처럼 Wikidata는 영어 위키백과 모듈에서 데이터를 가져올 수 있기 때문에 이 제안이 실패하더라도 다른 위키백과들을 도울 수 있기 때문에 이것은 문제를 찾기 위한 해결책처럼 보인다.* 삐삐 _{it has begun...}* 13:52, 2020년 8월 14일 (UTC)[응답]
  • @Pppery:봇이 데이터를 한 번 가져오게 할 만큼 쉽지만 시간이 흐를수록 데이터를 동기화시키기는 어렵다.enwiki에 대한 새로운 편집은 수동으로 또는 주기적으로 실행되는 봇에 의해 다시 가져올 필요가 있다(그러나 일반적인 Wikidata 사용자가 그러한 봇이 여전히 작동하고 있는지 확인하는 쉬운 방법은 없다).그리고 Wikidata에서 새로운 편집이 이루어지면, 봇으로 해결할 수 없는 갈등이 생긴다.전체적인 효과는 Wikidata를 통해 컬러 데이터를 사용하는 사람이면 누구나 열등/신뢰할 수 없는 버전을 얻고 있다는 것이다. –IagoQnsi (토크) 05:14, 2020년 8월 18일 (UTC)[응답]
• Fram, Certes, Eurialus, Pppery에 반대한다.애초에 이것을 만드는 모든 포인트는 모든 색상 데이터를 중앙 집중화된 한 장소에서 수집하는 것이었습니다.WD가 다른 위키들을 돕기 위해 이것의 복사본을 만들고 싶다면, 그건 괜찮지만, 이 데이터를 수백 페이지에 걸쳐 퍼뜨리는 것은 말 그대로 이 모듈이 만들어지기 전에 우리가 가지고 있던 것이다.아무도 그 혼란으로 돌아가고 싶어하지 않는다.Ejgreen77 (대화) 07:37, 2020년 8월 16일 (UTC)[응답]
  • @Ejgreen77:이것은 조립 전 시절에 존재했던 것과 같은 혼돈을 일으키지는 않을 것이다.우리가 가지고 있던 문제는 색상이 수십 개의 기사에 저장되어 있어서 수동으로 동기화되어야 한다는 것이다.Wikidata에서는 모듈에서와 마찬가지로 팀의 아이템인 한 곳에만 저장된다.예를 들어, 듀크 블루 데블스 팀에 관한 수십 개의 모든 기사들은 듀크 블루 데블스 (Q2907160)로부터 학풍을 끌어낼 것이다.그리고 Wikidata를 질의하면 이 질의와 같이 한 페이지에 모든 색상을 표시하기 쉽다.–IagoQnsi (대화) 05:01, 2020년 8월 18일 (UTC)[응답]
    • 그럼에도 불구하고, 현재 이 모듈에는 수백 개의 출품작들이 있기 때문에, 이 모든 출품작들은 각각 별도의 장소에 저장될 것이다.애초에 이것을 만든 모든 요점은 모든 데이터를 하나의 중앙 집중화된 위치에 저장하여 모니터링이 용이하도록 하는 것이었다.Ejgreen77 (대화) 10:42, 2020년 8월 26일 (UTC)[응답]
      • @Ejgreen77: 봇이 나의 위의 질의의 결과로 페이지를 업데이트 할 수 있도록 하여, 하나의 중앙집중화된 위치를 쉽게 감시할 수 있도록 할 수 있다.–IagoQnsi (대화) 20:44, 2020년 8월 27일 (UTC)[응답]
• 반대 Wikidata가 위키백과에 사용하기 위한 정보를 저장하는 데 유효한 용도가 있을 수 있지만, 데이터를 사용 가능한 구조로 유지하는 것은 더 이상 신뢰할 수 없다는 것이 점점 더 명백해지고 있다.이 관련 자료 모음은 enwiki 제어 하에 한 장소에 보관하는 것이 가장 좋다. --RexxS (대화) 18:42, 2020년 8월 16일 (UTC)[응답]
  • @RexxS: 인용 스타일 문제에 대한 우리의 의견 차이 외에, 나는 자료의 구조에 대한 어떠한 논의도 보지 못했다.모듈 토크 페이지에서는 데이터가 어떻게 구조화될 것으로 예상하는지 예를 들어 보여 주었다. wikidata:Q2892868#P6364.비판은 환영하지만 아직 본 적이 없다.건배, 이아고Qnsi (대화) 20:38, 2020년 8월 27일 (UTC)[응답]
  • @Mike Christie and Johnbodd:두 분 모두 렉시스의 발언을 반대 이유로 들으셨습니다.나는 당신이 위키다타 구조의 어떤 부분을 사용할 수 없다고 생각하는지 궁금하다.앞서 토론에서 렉시스가 제기한 인용 스타일인가, 아니면 다른 것인가.다른 누구도 나와 렉시스의 인용 스타일 실타래에 무게를 싣지 않았기 때문에 나는 더 넓은 공동체 의견에 대한 감각이 없다.고마워, IagoQnsi (대화) 20:38, 2020년 8월 27일 (UTC)[응답]

    • Mike는 "위 코멘트들 중 많은 부분에 대해, RexxS는 그것을 잘 요약한다"고 말했고 나는 "RexxS와 다른 사람들"이라고 말했다.나는 RexxS의 요약이 충분히 명확하다고 생각한다. 그리고 다른 사람들이 만든 많은 요점들이 있다.존보드 (대화) 21:16, 2020년 8월 27일 (UTC)[응답]

      내게 있어, RexxS의 핵심 요점은 데이터를 사용 가능한 구조로 유지하는 것이 더 이상 신뢰할 수 없다는 것이 점점 더 명백해지고 있다는 것이다.짧은 설명을 업데이트하는 것은 엔위키 자원의 엄청난 사용이고 다른 곳에서 더 잘 지시될 수 있지만, 그것은 실행되어야만 한다. 해당하는 위키다타 설명에 대한 파괴 행위는, 사실상, 여기에서는 관찰자들이 볼 수 없기 때문이다.그것은 여기서 똑같이 잘 될 수 있는 모든 것에 위키다타를 사용하는 것에 대해 나를 짜증나게 했다.이러한 이동에 명백한 주요 이점이 없는 한, 엔위키가 정보를 로컬에서 모니터링하고 관리할 수 없는(보호할 수 없는) 곳으로 옮기는 것을 보고 싶지 않다.마이크 크리스티 (대화 - 기여 - 라이브러리) 21:36, 2020년 8월 27일 (UTC)[응답]

• 지금 반대론 이 아이디어의 지지자들은 Wikidata에 색상 정보를 자유롭게 복사하고 다른 위키피디아에서 사용할 수 있는 모듈을 개발할 수 있다.6개월간의 성공적인 운영 후에, 이 제안은 enwiki에 대해 고려될 수 있었다.그러나 그때까지 한 페이지에 모든 정보를 담고 있는 것이 효과가 있는 것으로 알려져 있으며 미묘한 오류와 노골적인 반달리즘에 저항하는 것으로 알려져 있다.enwiki에서는 누구나 색상 변경을 제안할 수 있지만 템플릿 편집자만이 편집할 수 있다.Wikidata에서, 어떤 IP도 1140개소 중 어느 곳에서든 색을 바꿀 수 있다.조누니크 (대화) 09:52, 2020년 8월 18일 (UTC)[응답]
  • @요누니크:Wikidata의 보호 정책은 500페이지 이상에서 사용되는 모든 항목은 반보호되어야 한다고 말한다.각 학교의 색상은 수백 페이지에 걸쳐 사용되고 있으며, 이러한 색상을 이용하는 다른 위키의 출현 가능성이 있는 상황에서, 이 제안이 이루어진다면 반보호 요청이 승인될 가능성이 높다.–IagoQnsi (대화) 20:59, 2020년 8월 27일 (UTC)[응답]
    • 누구든 모든 데이터를 위키다타에 복사하고 그것이 기사에서 작동하도록 하기 위해 필요한 모든 것을 설정하는 것은 환영한다.그런 다음 다양한 위키피디아(엔위키가 아님)에서 테스트하여 6개월 동안 어떻게 진행되는지 확인하십시오.그 후에 다시 와서 여기서 쓰자고 제안한다.조누니크 (대화) 23:48, 2020년 8월 27일 (UTC)[응답]
• 위의 모든 지원 !보트에 따라 지원하십시오.나는 최근에야 대학 컬러 기구 전체와 상호작용을 시작했는데, 사라진 학교를 추가하기 위해 템플릿으로 보호된 편집 요청이 필요한 끔찍한 해킹이다.이것은 모든 언어와 그것을 사용하고자 하는 다른 사람들이 이용할 수 있는 위키다타에 저장하기에 이상적인 가치다.학대와 관련하여, 나는 반달들이 푸바 대학을 빨간 색에서 파란색으로 바꾸기를 원하거나 그렇게 하는 데 성공하는 것을 정말 보지 못한다.{{u Sdkb}}07:46, 2020년 8월 24일 (UTC)[응답]
• 지원 이 값은 사용자가 현재 위키백과에서 일반적으로 템플리트를 편집하는 방법으로 편집할 수 없는 템플릿의 값이다.데이터를 편집하기 위해 https://en.wikipedia.org/wiki/Module:College_color/data으로 가야 하는 것은 완전히 직관에 반하는 것이다.크리스티안클 ❪✉❫ 15:04, 2020년 8월 26일 (UTC)[응답]

위키피디아에서 다른 페이지로 가야 하는 것이 직관에 반하는 것이라면... 편집하기 위해 완전히 다른 WIKIData(위키다타)로 가야 하는 것은 훨씬 더 직관에 반하는 것이 아닐까?블루보아 (토크) 16:41, 2020년 8월 26일 (UTC)[응답]

@Blueboar:위키미디어 자매 사이트를 이용하는 것은 너무 어렵지 않을 것이다; 커먼즈는 사람들을 너무 많이 괴롭히는 것 같지 않다.현재 {{CBB 로스터} -> {{CollegePrimaryStyle} -> 모듈:대학 색상 --> 모듈:대학 색깔/데이터, 위키다타도 알아낼 수 있을 것이다.–IagoQnsi (대화) 17:32, 2020년 8월 26일 (UTC)[응답]

• 반대하라, 위의 많은 논평에 따르면, RexxS는 그것을 잘 요약한다.마이크 크리스티 (대화 - 기여 - 라이브러리) 17:36, 2020년 8월 26일 (UTC)[응답]
• RexxS 등에 반대한다.존보드 (대화) 18:06, 2020년 8월 26일 (UTC)[응답]
• 논평 - 나는 왜 내가 위키다타에 대해 그렇게 부정적인지 생각해왔다.그리고 그것이 아주 간단한 이유들로 귀결된다는 것을 깨달았다.첫째, 나는 텍스트 지향적이고 데이터 지향적이지 않다.나는 단지 저장되고 검색될 데이터의 비트의 관점에서 세상을 보지 않는다.둘째(그리고 더 중요한 것은), 나는 나이든 사람이고, 이 모든 것들을 기술화 하는 것에 쉽게 혼란스러워한다.나는 템플릿(모든 혼란스러운 매개변수와 필드를 포함)을 싫어하며, 가능하면 피하고(예를 들어 인용 템플릿을 사용하지 않고, 여전히 <ref>text</ref> 포맷을 사용하여 인용문을 손으로 모두 수행한다.)하지만, 나는 위키다타를 편집하는 것에 비해 템플리트를 쉽게 생각한다.나는 노력했고, 매우 빠르게 포기했다.단도직입적으로 말하면...나는 내가 위키다타를 편집할 수 없다고 느낀다.우리가 Wikidata로 물건을 옮길 때, 그것들은 편집자로서 나의 손이 닿지 않는 곳에 있게 된다.내가 위키다타에서 빼낸 정보를 편집해야 한다면 그렇게 할 수 없었을 것이다."누구나 편집할 수 있다"는 건 그만이다.블루보아 (대화) 21:53, 2020년 8월 27일 (UTC)[응답]
• 내 의견은 위의 인용 토론은 대체로 청어라는 것이다.그것은 구현의 문제고 나는 Trappist가 다른 누구도 CS1이나 CS2에서 각 색상과 관련된 참조 데이터에 대해 기능적인 인용문을 제공할 수 없다면 (그리고 나는 기본적으로 이미 다른 템플릿으로 그것을 해냈기 때문에 그것을 할 수 있는 적어도 한 명의 다른 사용자를 선택할 수 있을 것이라고 확신한다.

  나는 적어도 한두 가지 토론의 관심사를 가지고 있는데, 그 첫 번째는 색채의 이행에 관한 문제다.기억력(모바일 > 나)에서, 대학 컬러 모듈은 접근성을 위해 항상 진정한 색상을 제공하지 않으며, 전면과 배경 색상이 AA 준수를 충족하는지 확인할 수 있다(또는 때때로 우리는 이 질문을 완화하지만 공식적이지는 않은 특정 학교 테마에 색을 추가한다).이것은 Wikidata가 가져가고 싶어해야 할 데이터가 아니며 나는 확실히 그것을 그들에게 강요하고 싶지 않다.그 문제를 어떻게 해결하자고 제안할 것인가? (내 질문이 근거 없는 것이 아니라고 가정할 때)

  나의 두 번째 관심사는 메인스쿨 페이지(다른 것들 중 네이브박스)에 없는 것을 사용하는 것인데, 이것은 때때로 비싼 운영 횟수를 증가시킬 수 있다.당신은 그것을 분류할 실행이 마음에 드십니까?

  Navbox에서 사용하는 것을 고려할 때, 나는 이것이 우리가 Wikidata에서 사용해야 하는 데이터인지 확신할 수 없다.(Q1)에 관심을 가질 만한 데이터인 만큼 데이터를 이동/복사하는 것은 당연히 인정받을 것이다. --Izno (대화) 21:57, 2020년 8월 27일 (UTC)[응답]

  • @Izno: 좋은 질문이야!나는 이 모듈의 어떤 색상도 공식적이지 않다는 것을 알지 못했다.이 비공식적인 색깔들은 어떻게 선택되는가?만약 그것들이 공식 색상에서 체계적으로 파생되고 있다면, 나는 우리가 위키다타에 공식 색상만 저장하고 위키백과에 있는 우리의 모듈로 하여금 그것들을 검색할 때 접근 가능한 색상을 도출하도록 할 수 있다고 생각한다.만약 그들이 다른 방법으로 선택된다면, 우리는 그것들을 보관하기 위한 스키마를 알아내고 싶을 것이다. 아마도 공식적 색과 비공식적 색상을 구별하기 위해 진술의 특성(P5102)을 사용할 것이다.나는 이러한 비공식적인 색상을 위키다타에도 저장하는 것이 유용할 것이라고 생각한다; AA 준수는 우리뿐만 아니라 모든 위키미디어 프로젝트들이 관심을 가질 만한 것이다.그것은 단지 공식적인 색깔에서 그것들을 묘사하는 좋은 방법을 찾는 일이다.
  • 고가의 운영 문제에 대해서는 특별히 염두에 두고 있는 것이 아니었다.한 가지 방법은 봇이 매시간 모든 대학 색깔에 대한 질의의 결과로 로컬 페이지를 업데이트한 다음, 템플릿/모듈이 Wikidata에서 직접 색상을 추출하도록 하는 것이다.만약 우리가 이것을 단지 대학 스포츠에만 사용되도록 확대한다면 장기적으로 그렇게 훌륭한 해결책은 아닐 것이다. 하지만 아마도 이것을 효율적으로 캐쉬할 다른 방법들이 있을 것이다. 그것은 내가 알지 못하는 것일 수도 있고, 어쩌면 위키다타 루아 개발자들과 함께 제기될 수 있는 것일 수도 있다.
  • 우리는 또한 하나의 값비싼 질의를 여기서 사용할 수 있도록 허락할 수도 있다.대부분의 기사들은 한 학교의 색상만 사용하므로 별로 큰 문제가 되지 않을 것이다.애틀랜틱 코스트 컨퍼런스와 같은 몇몇 기사들은 많은 학교의 색을 사용하며, 우리는 그들을 위한 더 나은 해결책을 갖고 싶다.우리는 아마도 SPARQL 쿼리를 이용하여 많은 학교의 색을 사용하는 기사를 시간 단위로 업데이트하도록 할 수 있을 것이다.하지만 단기적으로는, 값비싼 기능 한계에 부딪힐 만큼 충분히 다른 학교들의 색깔을 이용하는 페이지가 없다고 생각하므로, 우리는 아직 이것에 대해 최종적인 해결책을 반드시 가질 필요는 없다.–iagoQnsi (대화) 23:42, 2020년 8월 27일 (UTC)[응답]
• 일단 요누니크 당은 반대하라.어느 한 시스템에 익숙하지 않은 사람들의 사용 편의성, 편집자의 작업 부하 감소, MoS 준수, 공공 기물 파손에 대한 저항성 등 실제 현재 시스템보다 더 잘 작동하고 있다는 것이 입증되고 증명된 것을 보고 다시 생각해 볼 용의가 있다.· ··· 피터 사우스우드 : 13:55, 2020년 8월 28일 (UTC)[응답]
• 정확히 @Blueboar:의 이유 때문에 반대하라.Wikidata는 매우 기술적이다.나는 영어 위키백과의 텍스트를 이해한다.나는 위키다타를 전혀 이해하지 못한다.당신이 영어 위키백과에서 위키다타로 데이터를 더 많이 옮길수록, 당신은 영어 위키백과를 편집하는 나의 능력을 더 떨어뜨리고 있다.미스터 Serjeant Buzfuz (대화) 14:29, 2020년 9월 6일 (UTC)[응답]
• 반대자들은 WD가 공공 기물을 파괴하고 있다고 말할 수 있지만, 만약 당신이 운이 좋아서 지역 위키가 그것을 잡지 못한다면 기물 파손은 며칠, 몇 주 동안 머무른다.버킹엄 궁전은 1826년, 2018년, 2013년, 1999년, 2018년(again, 현재 22일), 2017년, 2012년(현재 4개월), 2012년, 2012년, 2011년(한 달), 1703년(한 달), 1703년(한 달), 1200년(가치 없음), 1720년, 5555년, 1720년, 1715년에 정식으로 문을 열었다.골라봐.자, 그것은 사람들이 실제로 알고 있을 수 있는 숫자지만, 색깔에 대해서는 결정할 수 없는 숫자인가?#FEFEFE 아니면 #FFEFF?그냥 로컬로 유지, 보호, 감시 용이. --Dirk Beetstra 15:17, 2020년 9월 6일 (UTC)[응답]

일부 보호 자물쇠를 보다 일관적으로 업데이트

#WPWP 편집 후 정리

지난 7월부터 메타에서 진행돼 오는 8월 31일까지 진행되는 위키피디아 페이지 Want Photos 캠페인의 결과, 이미지 사용 정책/MOS에 익숙하지 않거나 품질에 신경을 쓰지 않는 편집자들의 질 낮은 편집이 많이 있었다.몇몇은 잘못된 이미지 배치를 가지고 있었고, 몇몇은 잘못된 캡션을 도입했고, 몇몇은 전혀 상관없는 이미지를 삽입했으며, 몇몇은 완전히 망가진 Infobox와 다른 템플릿들을 가지고 있었다.영향을 받는 많은 기사들은 잘 보이지 않는 주제들이기 때문에, 조정된 청소 노력이 필요할 수도 있다.문제가 있는 편집자를 식별하고 기고문을 확인하기 위해 중앙집중식 게시판을 사용하는 것은 어떨까?앞서 AN에서 논의가 있었지만 결론에 이르지 못한 것 같았다. --Paul_012 (대화) 09:27, 2020년 8월 28일 (UTC)[응답]

필터가 1073을 기록해서 추적하는 건 어렵지 않지만 조회 수는 32,000건이야늑장부리는 Reader (대화) 14:13, 2020년 8월 28일 (UTC)[응답]

고마워, Rowling Reader.편집 필터가 이미 구현된 것을 놓쳤다.필터를 트리거한 중복된 사용자 목록을 얻을 수 있는 방법이 있는지 알고 싶으십니까? --Paul_012 (대화) 17:02, 2020년 8월 28일 (UTC)[응답]

편집 필터가 변경되고 설정되어야만 편집이 허용되지 않고 이 시점부터 이 이벤트는 모든 수단을 동원해서 이 프로젝트에 금지되어야 한다. 그것은 파괴적이고 매우 무뚝뚝해야 하는 우리로서는 골치 아픈 일이다. 모든 편집 내용을 점검하는 데 기여하는 모든 과정을 거쳐야 하는 우리에게는.–Davey2010^Talk 20:51, 2020년 8월 30일 (UTC)[응답]

확실히 하자면, ANI에 대한 합의는 그것이 파괴적이지 않고, 모든 사람의 편집을 확인할 필요는 없다는 것이었다.우리의 정상적인 커뮤니티 작업 흐름은 이미 많은 실수를 잡아냈을 것이고, 편집의 질이 다른 새로운 편집인 사다드 (토크) 20:02, 2020년 9월 9일 (UTC)[응답]과 크게 다르다는 증거는 없다.

비록 그들이 아직 일을 제대로 하고 있지 않더라도, 이것의 일환으로 새로운 편집자들이 있다는 것은 멋진 일이다.나는 네가 그들을 환영하고 그들에게 위키피디아를 가장 잘 편집하는 방법을 가르쳐주길 바란다.고마워요.마이크 필 (토크) 19:35, 2020년 9월 3일 (UTC)[응답]

Mike가 말한 것에 +1: 내가 본 대부분의 편집은 건설적이고 다른 위키미디어 커뮤니티의 작업을 기반으로 하기 때문에, 사람들과 관계를 맺는 데 사려깊게 생각해 주길 바란다.사다드 (토크) 20:02, 2020년 9월 9일 (UTC)[응답]

홈 페이지 상단에 있는 다음 내게 필요한 옵션 기능에 대한 링크

첫 번째 페이지와 맨 위에 다음 항목에 대한 접근성 단축키가 있어야 한다.

1. https://en.wikipedia.org/wiki/Help:Multilingual_support , 글꼴 및 렌더링 지원, IPA, 점자 등.
2. https://www.mediawiki.org/wiki/Universal_Language_Selector
3. https://en.wikipedia.org/wiki/Wikipedia:Spoken_articles
4. 위키 마크업 언어 지원(마크업 언어란?, 위키 마크업 언어, 코드 목록, 수표 등)

이것은 간곡한 부탁이다.이것은 접근성 하이퍼링크로 모든 페이지의 맨 위에 추가되어야 한다.이마저도 위키백과 홈페이지는 물론 다른 모든 위키백과에도 추가해야 한다.미리 고맙다.RIT RAJARSHI (토크) 22:23, 2020년 9월 13일 (UTC)[응답]

2는 이미 사이드바에 연결되어 있다.3은 구어 버전이 없는 대부분의 기사에는 무관하며, 구어 버전이 있는 기사에는 이미 적절한 템플릿이 있다. 1 또한 이미 유사한 템플릿으로 연결되어 있다.4는 위키백과를 방문하는 모든 방문객들 중 극히 적은 부분인 마크업으로 편집하는 사용자들을 제외한 모든 사람들에게 관련되지 않는다.– Teratix₵ 01:59, 2020년 9월 14일 (UTC)[응답]

동의. {{u Sdkb}} 03:58, 2020년 9월 14일 (UTC)[응답]

나는 일부 기능이 존재한다는 것에 동의하지만 "그 기능을 사용하는 방법"은 첫 페이지에서 직접 사용할 수 없다.내가 연결한 페이지는 대부분 일부 '도움말 페이지'이며 메인페이지에 링크되어야 한다.리트 라자르시 (토크) 10:03, 2020년 9월 14일 (UTC)[응답]

그러나 왜 도움말 페이지가 모든 기사에 표시되어야 하는가? 대부분의 시간을 관련 없는 잡음이 될 것이다.– Teratix ₵ 11:03, 2020년 9월 14일 (UTC)[응답]

주의를 산만하게 하기 위해서가 아니라, "말하는 글"은 그 이상이 아닌 더 적은 것으로 연결되어야 한다.요즘 스크린 리더는 괜찮다.위키피디아를 이런 식으로 항해하는 사람들은 스크린 리더가 말하는 현재의 글과 6년 전 1%의 글과 같이 알 수 없는 내용의 무작위 스냅샷을 원한다.그리고 드물게 1%의 시간 동안 그들은 인간이 말하는 버전을 선호할 수도 있다.많은 외래어?)는 대개 존재하지 않는데, 이는 WP 기사가 수동으로 구사한 경우가 거의 없기 때문이다.스노우파이어 (토크) 00:26, 2020년 9월 15일 (UTC)[응답]

템플릿의 일부 사용 마이그레이션:템플릿에 공통:커먼스 카테고리

모두 안녕하십니까. 커먼스에 대한 일반 링크를 제공하는 {{Commons}과 커먼스 카테고리에 특별히 링크하는 {{Commons 카테고리}이(가) 있다.매개변수 없이 사용할 경우, {{Commons}}은(는) Commons 검색 페이지로 연결되며, 매개변수와 함께 사용할 경우 해당 매개변수를 사용하여 해당 Commons 갤러리 또는 카테고리에 특별히 연결한다.한편, 파라미터 없이 사용하는 {{Commons 카테고리}}}}은(는) 위키다타를 사용하여 커먼스 카테고리(Wikidata에서 시텔링크를 통해 정의됨) 또는 제공된 명명된 매개변수(Wikidata에서 커먼스 카테고리 시텔링크와 교차 확인되어 추적 카테고리에 추가된다.

다음과 같은 상황에서 {{Commons}}에서 {{Commonscat}}까지의 사용을 봇 마이그레이션하고 싶다.

1. {{Commons}}은 매개 변수(= 검색 페이지 링크) 없이 사용되지만 Commons 범주는 페이지/카테고리(category)에 연결된다.
2. {{Commons}}} 공용 범주에 대한 링크
3. {{Commons}}}은(는) 존재하지 않거나 리디렉션된 갤러리에 연결되지만 Commons 범주는 sitelinked(시텔링됨
4. 선택 사항: {{Commons}}이(가) 존재하지 않거나 리디렉션된 갤러리에 연결되면, commons 범주가 없는 a) 링크를 제거하거나 b) 매개 변수를 제거할 수 있다.

이는 일회성으로 실시하거나 새로운 사례를 포착하기 위해 정기적으로 실행할 수 있다.현재 {{Commons}}({Commons 범주}}의 약 780k 사용과 비교)의 사용이 약 65k이다.만약 이것이 괜찮다면, 나는 봇 제안서를 제출할 수 있다 - 나는 이미 내가 쉽게 봇으로 전환할 수 있도록 반자동 피위키봇 코드를 가지고 있다. 나는 그것을 지난 며칠 동안 대화식으로 실행해 왔지만, 경우의 수와 높은 정확도를 고려하면 아마도 이것은 봇으로서 더 나을 것이다.(예: 사례 1, [2] 또는 사례 2, [3] - 사례 3, 4는 아직 코드화되지 않음)이것은 내가 wip <--> wikidata <--> commons sitelinks를 정리하기 위한 폭넓은 작업의 일부인데, 필요하다면 더 많은 배경을 제공할 수 있다.

(BTW, 나는 이것이 RfC여야 하는지 아니면 단지 지푸라기 여론조사여야 하는지 잘 모르겠다. 만약 RfC여야 한다고 생각하는 사람이 있다면 태그를 추가해도 무방할 것이다.)고마워요.마이크 필 (토크) 18:17, 2020년 8월 30일 (UTC)[응답]

• 지지하다.두 가지 주의: 1) Commons에는 갤러리로부터 범주(의도적으로 또는 크로스 ns 이동의 잔해로서)로 가리키는 크로스 ns #REDirects (page_is_redirect = 1)가 많다.- 대상 고양이는 방향을 바꾸는지 확인해야 한다.#REDirected가 아닌 템플릿에 의해 태그가 지정되지만 c:Category:카테고리 리디렉션. --Achim (토크) 18:57, 2020년 8월 30일 (UTC)[응답]

  @Achim55: 나는 보통 공통의 용도를 확인하는 코드를 사용한다.템플릿:범주 리디렉션 및 해당 템플릿으로 리디렉션된 알려진 목록(모든 항목을 잡을 수는 없지만 보수적으로 작동함) - 템플릿을 찾을 수 없는 경우 유효한 갤러리로 가정한다.고마워요.마이크 필(토크) 19:06, 2020년 8월 30일 (UTC)[응답]

  마이크, 마지막 단어 ^는 내 생각에 '범주'였어야 했다고 생각한다.템플릿 사용에 대한 테스트도 가능하겠지만 "캐스캐딩" c:템플릿:잘못된 Taxon 범주 리디렉션도.베스트, 아킴 (토크) 19:19, 2020년 8월 30일 (UTC)[응답]

  • @Achim55: 아니, '갤러리'가 맞아. 시텔링크를 이용해서 카테고리를 확인하니까 갤러리 체크만 더 까다로워.나는 항상 코드를 향상시키는 것이 행복하지만, 그것은 아마도 봇 제안에서 더 잘 논의될 것이다 - 우선 우리는 이것이 우리가 공동체로 하고 싶은 일인지를 규명할 필요가 있다.고마워요.마이크 필(토크) 19:23, 2020년 8월 30일 (UTC)[응답]

제안 나는 같은 목적을 달성하고 봇 편집이 덜 필요하며 독자들에게 더 나은 것을 만들어 줄 것이라고 생각하는 대안이 있다.나는 {{Commons}}을(를) 다시 일반적인 "Commons at Commons" 템플릿으로 만들 것을 제안한다. 그것은 Commons 검색의 의미론이 바뀌기 전이었다.{{Commons}} 사용 모듈:{{Commons-inline}}이(가) 하는 것처럼 Commons 링크.{{Commons}}에 매개 변수가 없는 경우 모듈:커먼즈 링크는 위키다타를 사용하여 커먼스 갤러리 또는 커먼스 카테고리(있는 경우) 중 하나를 찾을 수 있다.그 모듈은 "실패 소프트"이다. 만약 위키다타가 일관성이 없다면, 그것은 다시 커먼즈 검색으로 돌아간다.이 모듈을 사용하면 위의 마이크 필의 사례 (1)과 (3)에 대해 다룰 수 있다.위의 사례(2)를 처리하기 위해 봇을 사용하는 것을 열렬히 지지한다(편집자의 의도가 명확하기 때문이다).{{Commons Category:Foo}}분명히 그래야 한다{{Commons category Foo}}나는 그것이 일회용 봇이 될 것이라고 확신한다.

이 모듈의 사용은 템플릿에서 프로토타입으로 제작된다.템플릿에 테스트 케이스가 있는 커먼스/샌드박스:커먼즈/테스트케이스

다른 편집자가 가질 수 있는 질문에 답하기 위한 일부 추가 참고 사항:

• 약 2년 전, 커먼즈 검색의 의미가 바뀌었다.'Foo'라는 검색어가 있을 때 'Foo'라는 갤러리가 있었다면 독자들은 바로 그 갤러리로 끌려가곤 했다.그렇지 않다면, 그리고 "Foo"라고 불리는 카테고리가 있다면, 독자들은 그 카테고리로 바로 옮겨질 것이다.그렇지 않으면 그것은 "Foo"에 대한 일반적인 검색으로 되돌아갈 것이다.이것은 현재의 상황보다 훨씬 더 우호적이었다.모듈:커먼즈 링크(getGalleryOrCategory 함수)는 Wikidata를 사용하여 그 행동을 (가능한 한) 복원하도록 설계되었다.그렇지 않으면 다시 검색으로 돌아간다.
• Module:Commons 링크가 프라임 타임에 준비됨.{{Commons 및 category}, {{Commons 및 category-inline}, {{Commons-inline}, {{Sister links}}}이(가) 25,000개 이상의 기사에 사용된다.그것은 시험 케이스가 있고 나는 지난 몇 달 동안 아무런 불만도 받지 않았다.
• 모듈:Commons 링크는 페일 소프트 및 비침해성:
  • 매개 변수가 제공되면 Wikidata를 통해 검색하는 대신 그것을 사용한다.
  • 가능한 갤러리 및 카테고리에 대해 복수의 위키다타 필드(예: 시텔링크)를 조사한다. 갤러리 또는 카테고리를 사용할 수 있는 경우, 이를 사용한다.위키다타가 자기 모순적이면 포기하고 다시 커먼즈 검색으로 넘어간다.
  • RexxS와 Mike Pel에게 이 모듈을 구축하는 방법에 대한 조언에 감사드린다.모듈에 의존했다.위키다타IB 영감!
• Mike Pel이 궁금한 경우: P373이 더 이상 사용되지 않는 경우, 모듈:커먼즈 링크는 오류 없이 작동한다.그것은 P373을 갤러리 링크의 가능한 원천으로 사용하지만, 만약 그것이 비어 있거나 제거된다면, 그것은 단지 더 적은 갤러리를 찾을 것이다.

모듈:커먼즈 링크는 커먼즈 시팅크(예:)가 변경될 때 자동으로 최신 정보를 제공하면서 마이크의 제안서 목표의 대부분을 충족한다.

다른 편집자들은 이것에 대해 어떻게 생각하는가?— 하이라이트395 (대화) 19:44, 2020년 8월 30일 (UTC)[응답]

• @Hike395: {{Commons} 대 {{Commons 범주}}} 템플릿의 사용 여부에 대한 구체적인 이슈에 초점을 맞추고자 했는데, 그것이 지금 우리가 취할 수 있는 실질적인 조치인 것이다.만약 우리가 이것을 좀 더 넓은 토론으로 전환한다면, 나는 우리가 갤러리 및/또는 카테고리에 연결되는 단일 템플릿을 사용하는 것을 보고 싶다. 그것은 Wikidata의 시텔링크를 통해서, 가능한 한 모듈을 통해서.@RexxS: 모듈과의 호환성을 확인할 수 있는 경우 커먼즈 링크:위키다타IB. 고마워.마이크 필 (토크)20:02, 2020년 8월 30일 (UTC)[응답]
  • @Mike Pell: 모듈 보기:커먼즈 링크, 나는 그것이 위키다타와 같은 방식으로 상호 작용한다는 것을 확인할 수 있다.IB가 한다.본질적으로 Commons 상의 카테고리 및 갤러리와의 협력을 위한 복수의 유틸리티 기능을 추가하고, 관련 카테고리 및 갤러리를 Wikitext에 각각 2개의 주요 통화를 추가한다. --RexS (토크) 23:11, 2020년 8월 30일 (UTC)[응답]

@Mike Pel: 토론을 무작위로 진행시킨 것에 대해 사과한다.추가 참고 사항:

• 이에 대한 합의가 이루어진다면 템플릿 홍보:템플릿에 대한 커먼스/샌드박스:즉시 공유하여 봇에게 원하는 것의 일부를 기다리지 않고 즉시 실행하십시오.그것은 오늘날 우리가 취할 수 있는 실질적인 조치다.이 경우 {{Commons}이(가) 제안하는 것("Wikidata의 시텔링크를 통해 사용 가능한 갤러리 및/또는 범주로 연결되는 템플릿")이 되고, 폴백 및 일관성에 대한 다른 속성으로부터 추가 점검을 받게 된다.
• 지난 3월 RexxS는 모듈 코드 검토를 관대하게 실시했다.커먼즈 링크는 생산에 들어가는 문제를 보지 못했다.Mike: 모듈:커먼즈 링크가 모듈과 다름:위키다타IB?주요 진입점은 getGallery, getCategory, getGalleryOrCategory(리턴 1), getGalleryAndCategory(둘 다 리턴) 등 4가지다.Wikidata를 직렬로 검사하는 대신 첫 번째 항목이 발견된 후 보석금을 지불하는 모듈:커먼즈 링크는 모듈(Module)과 동일한 모든 위치를 검색한다.위키다타IB, 그리고 불일치가 발견되면 커먼즈 링크를 반환하지 않는다.
• 같은 토론에서 마이크는 커먼즈 템플릿을 결합하는 흥미로운 아이디어를 내놓았다.모듈과의 간단한 통화를 위해 논의를 연기할 수 있는가?커먼즈 링크 {{Commons}}?네가 말했듯이, 모듈 콜은 우리가 오늘 구현할 수 있는 간단한 실용적인 아이디어야.우리가 의견 일치를 얻는다면, 하원 템플릿은 나중에 언제든지 통합될 수 있다.

더 많은 논평/제안/이슈를 환영한다!— 하이라이트395 (대화) 23:09, 2020년 8월 30일 (UTC)[응답]

@Hike395: 이것을 좀 더 자세히 보면, 템플릿의 변화:커먼즈/샌드박스는 나쁜 연결고리의 수를 줄이기 위한 유용한 개선책이며, 나는 즉시 그 변화를 만들어야 한다고 생각한다(권한이 없다면 나는 그것을 살려낼 수 있다).그러나 {{Commons cat}}}은 추적 범주를 포함하며, 특히 Wikidata에 정의된 파라미터가 없고(=이 템플릿의 검색에 대한 링크) 로컬 텍스트가 Wikidata와 일치하지 않는 경우에 해당된다.이러한 것들은 유지보수에 정말 유용하지만, 범주와 갤러리를 모두 가지고 있을 때(특히 편집자가 어떤 것에 연결하고자 하는지 모르는 경우) 다루기가 더 복잡해진다.범주에 대한 링크를 유지하기 위해 Pi bot도 설치되어 있는데, 이는 갤러리 링크를 제거하지 않고 가능한 경우 {{Commons category}을(를) 사용하기 위해 케이스를 마이그레이션하려는 이유의 일부다.장기적으로, 나는 우리가 (Wikidata를 사용했을 뿐) 매개 변수 없이 두 템플릿을 사용하고 갤러리 및 범주(그리고 관련 범주) 둘 다로 연결하는 것을 보고 싶지만, 그것은 별개의 토론이다.

요컨대, 나는 당신이 일하는 것이 좋고 라이브로 해야 한다고 생각하지만, 그것은 내가 여기에 제시한 구체적인 제안과 평행하다.두 사람 다 병행해서 앞으로 나갈 수 있을 것 같아.고마워요.마이크 필 (토크) 19:01, 2020년 9월 1일 (UTC)[응답]

@Mike 껍질:고마워!그냥 생방송으로 만들었어.모듈:커먼즈 링크는 당신의 제안을 보완한다.너의 제안서에는 우리가 실행해야 할 귀중한 정리정돈이 포함되어 있다.이쯤에서 정리정돈에 대한 세부적인 논의만 하고 있는 것 같아.

모듈에서 {{Commons 카테고리}}의 추적 카테고리 로직을 구현하게 되어 매우 기쁘다.커먼즈 링크.루아에서는 그게 쉬울 거야.동의하신다면 그 논리를 {{Commons}}에 추가할 수 있다.나도 진입점으로 노출시킬 수 있어 {{Commons category}}을(를) 좀 더 컴팩트하게 만들 수 있다(원하신다면).모듈에서 관련 작업을 시작하겠다.커먼즈 링크/샌드박스그것을 실행한 후에, 우리는 추적 카테고리를 얻기 위해 템플릿을 변경할 필요가 없을 것이다.

{{Commons}}과{Commons 범주}}}은(는) 서로 다른 편집자의 의도를 표현한다고 생각하고 있다.후자는 "나는 정말 범주에 연결시키고 싶다"는 뜻이고, 전자는 "나는 어떤 종류의 가장 좋은 하원을 원한다"는 뜻이다.난 그저 편집자의 의도를 바꿀 수 있는 엄청난 변화를 봇이 하게 하는 것에 대해 매우 조심하려고 하는 것뿐이야.당신이 개략적으로 설명한 가능성 있는 사례들을 분류하고 편집자의 의도를 보존할 수 있는 제안을 하겠다.

1. {{Commons}}에는 범주인 첫 번째 매개 변수가 있음 -- 분명히 {{Commons 범주로 이동됨}
2. {{Commons}}에는 범주로 리디렉션되는 첫 번째 매개 변수가 있음 --{Commons 범주}로 이동하면 정확할 가능성이 매우 높음
3. {{Commons}}에는 Commons에 존재하지 않는 첫 번째 파라미터가 있다.두 가지 가능성이 있다.
   • 편집자가 실수를 한 것 같다 - 정답은 첫 번째 매개 변수를 삭제하고 모듈에서 다음 작업을 수행하도록 하는 것이다.커먼즈 링크는 위키다타 마법을 부린다.
   • 편집자가 Commons 검색을 호출할 의도였을 수 있음(비슷하지만 가능)

   첫 번째 매개 변수를 삭제하고 예상하지 못한 경우를 무시하면 되는 겁니까?또는 다음 항목을 추가할 수 있다. fallback=파라미터 to {{Commons} 및 모듈:Commons 링크, Wikidata 실패 후 Commons 검색 실행다른 편집자들은 어떻게 생각하는가?

4. {{Commons}}에는 첫 번째 매개 변수가 없음 --- 이제 모듈을 사용 중이므로:이 사건을 위해 특별히 고안된 커먼즈 링크(Commons link)는 이 사건을 그냥 두겠다.(특히 추가 추적 범주를 추가한 후)

요약하자면, 나는 나의 경우 (1)과 (2)에서 봇을 사용하는 것을 지지하고, 위의 경우 내 경우 (4)에서 봇을 사용하는 것에 반대하며, 내 경우 (3)에 대해 토론해보자.추적 범주에 대해 알아볼게.

다른 편집자들은 어떻게 생각하는가?마이크? — 하이킹395 (대화) 14:37, 2020년 9월 2일 (UTC)[응답]

@Hike395: 너의 첫 번째(나의 #2)와 나의 #3의 일부인 두 번째에 우리는 동의한다고 생각한다.세 번째와 네 번째 요점은 검색 연결이 정확했다고 가정한다(여기 있는 기존 갤러리에 대한 링크를 자동으로 제외한다). 나는 그것이 합리적인 가정이라고 확신할 수 없다.특히 카테고리에서는, 검색 결과보다는, 그런 카테고리가 존재하는 곳(그리고 존재하는 곳만)에 링크하는 것이 타당하다고 생각한다.만약 그런 시텔링된 범주가 없다면, 내 제안은 그 사건들을 바꾸지 않을 것이다.아마도 여기서 일반적인 질문은 우리가 이 주제에 대한 기존의 하원 범주가 아닌 검색으로 연결하기를 원하는가 하는 것이다.고마워요.마이크 필 (토크) 17:55, 2020년 9월 2일 (UTC)[응답]

@Mike Pel: 나는 검색 링크가 나쁜 사용자 경험이라는 것에 동의한다.그러나 이제 모듈:커먼즈 링크는 {{Commons}}에서 사용되며, 내 사례 #4는 더 이상 검색 링크를 사용하지 않는다.나의 사례 #4는 이제 직접 커먼즈 카테고리로 간다(해당 갤러리 없는 경우, 그렇지 않으면 그것을 사용할 것이다).나는 루아에 추적 범주 논리를 작성했다(그러나 아직 테스트되지 않았다).곧 4번 케이스를 {{Commons 범주}}(내 생각엔)로 옮길 만한 설득력 있는 이유가 없을 것이다.— 하이킹395 (대화) 19:16, 2020년 9월 2일 (UTC) I[응답]

@Hike395: 좋아, 좋아.그러면 템플릿이 Commons 범주에만 연결되는 경우, {{Commons 범주}를 사용하여 Commons 범주에 대한 링크임을 명확히 하는 것이 좋은지 여부가 문제가 된다.갤러리와 카테고리는 따로 유지한다.그러나 그것을 바라보는 또 다른 방법은, 자동적으로 그것을 분류하는 하나의 커먼즈 템플릿에 병합하는 첫 번째 단계라는 겁니다.고마워요.마이크 필 (토크) 17:34, 2020년 9월 3일 (UTC)[응답]

@Mike Pell: 템플릿(편집자의 의도를 바꿀 수도 있고, 새로운 갤러리가 나타나면 틀릴 수도 있음)을 변경하는 대신, 템플릿의 출력을 변경하여 편집자(및 독자)에게 Wikidata가 카테고리로 가져간다는 것을 경고해야 하는가?즉, {{Commons}}(또는 관련 템플릿)이 갤러리 대신 위키다타에서 범주를 찾는 경우, 자매 링크 상자에 범주 레이블을 채워야 한다.Foo 대신 Foo? 아니면 독자들이 너무 혼란스러울까? 14:56, 2020년 9월 6일 (UTC)

나는 일반적인 규약이 'Category:'를 보여주지 않는 것이라고 생각한다 - 기사 하단의 카테고리들이 접두사를 가지고 있지 않은 것과 같은 것이다.내 선호도는 여전히 템플릿을 변경하는 것이다.고마워요.마이크 필 (토크) 14:16, 2020년 9월 12일 (UTC)[응답]

@Mike Pel: 나는 아직도 우리 둘 다 받아들일 수 있는 타협을 할 수 있을지 의문이다.그렇다면 이러한 종류의 템플릿에 대한 출력 텍스트를 변경할 수 있는가?

템플릿이 갤러리에 연결되면 다음과 같은 내용을 읽을 수 있다.

위키미디어 커먼즈에는 푸를 위한 갤러리가 있다.

만약 그것이 범주에 연결된다면, 그것은 다음과 같은 것을 읽을 수 있다.

위키미디어 커먼즈는 Foo를 위한 카테고리를 가지고 있다.

만약 그것이 어떤 종류의 검색으로 되돌아간다면, 그것은 오늘날과 같이 읽힐 수 있을 것이다.

위키미디어 커먼즈에는 Foo와 관련된 미디어가 있다.

그리고 {{Commons와 category}}}이(가) 둘 다 반환되면 읽을 수 있다.

위키미디어 커먼즈는 Foo를 위한 갤러리와 카테고리를 둘 다 가지고 있다.

나는 이것이 위키다타 논리를 편집자와 독자 모두에게 더 투명하게 만들기 때문에 이것을 좋아한다.다른 편집자들은 어떻게 생각하는가?— 하이킹395 (토크) 00:58, 2020년 9월 13일 (UTC)[응답]

@Hike395: 장기적으로 우리가 도달하는 것을 보고 싶은 해결책이지만, 이 단계에서 내가 제안했던 것 이상의 것이다.그런데 왜 당신이 범주 링크를 다른 템플릿으로 옮기는 것을 좋아하지 않는지 이해가 안가, 정의한 매개변수가 없는 곳에서?만약 그렇게 하는 것에 대한 합의가 있다면, 우리는 언제든지 미래에 템플릿을 병합할 수 있다. (그리고 나는 그것이 우리가 지금까지 여기서 보고 있는 것보다 더 넓은 논의가 필요하다고 생각한다.)고마워요.마이크 필 (토크) 20:16, 2020년 9월 13일 (UTC)[응답]

@Mike Pel: 여기 한 가지 사례가 있다.편집기 A는 Foo에 {{Commons}}을(를) 사용하며 Commons만 사용:범주:Foo는 Commons에 존재한다.봇이 뚫고 들어와 {{commons category}}}(으)로 변환한다.달라질 것 없어.그러나 편집자 B는 다음과 같이 Commons를 만든다.Foo. 봇이 없으면 페이지가 자동으로 업데이트되어 Commons에 연결된다.봇이 있으면 페이지가 자동으로 업데이트되지 않는다.자동 업데이트 기능을 해제하려는 이유는?

여기 또 다른 예가 있다.나는 WP를 위반하는 기사를 우연히 발견했다.IG: 나는 갤러리를 하원에 넘기고, 그것을 좋게 만들려고 노력한다(FP 포함, 섹션으로 구성하기 등).만약 그 기사에 {{Commons}}이 있다면, 나는 그것을 그냥 내버려두는데, 어떤 사전 편집자가 일종의 커먼즈 링크를 원했기 때문이다.기사에 {{Commonscat}}이(가) 있다면, 어떤 사전 편집자가 명시적으로 Category에 연결하기를 원한다는 것을 알기 때문에 {{Commons 및 Category}}로 변환하고, 만약 내가 그들의 카테고리 링크를 빼앗았다면 그들은 불행할 것이다.로봇이 {{Commons}}을(를) {{Commonscat}}(으)로 변환하면 편집자의 의도가 무엇인지 알 수 없다.역사를 되돌아볼 수도 있어, 사실이지만, 왜 기능적인 차이 없이 일을 시키지?

이게 설명하는데 도움이 되길 바래.— raight395 (대화) 05:13, 2020년 9월 16일 (UTC)[응답]

기술 노트

이제 네임스페이스:1("Talk:")을 대상으로 하므로 기술 구현은 설정을 통해 수행될 것이다.(noindex,follow)에$wgNamespaceRobotPolicies 이 작업은 Phab에서와 같은 Phabricator 요청을 통해 수행할 수 있다.T104797, 그러한 요청은 성공적이고 폐쇄적인 지역사회 논의에 영구적인 연계를 포함해야 한다.— Xaosflux^Talk 23:27, 2020년 8월 19일 (UTC)[응답]

부차적인 결정은 다음의 사용 여부다.__INDEX__페이지별 인덱싱을 의도적으로 허용해야 한다(이것은 다음에 대한 업데이트임).$wmgExemptFromUserRobotsControlExtra ) - 기본적으로 인덱싱에 대한 수동 태그 지정은 허용되지만, 필요한 경우 금지할 수도 있다.인덱싱하기 위해 수동으로 태그가 지정된 페이지가 카테고리:추적 및 검토를 위한 색인된 페이지.— Xaosflux^Talk 23:27, 2020년 8월 19일 (UTC)[응답]

이와 관련하여, 현재 BLP의 대부분의 대화 페이지는 범주에서 볼 수 있듯이 NOINDEX 지시어를 삽입하는 템플릿을 갖는 방법으로 색인화되지 않는다.색인된 페이지 없음.— Xaosflux 23:30, 2020년 8월 19일 (UTC)[응답]

아래로부터, 일부 토크 페이지 복사-붙여넣기 "아카이브"는 이렇게 태그가 붙지 않을 수도 있다.원한다면 봇이 이 일에 적합할 수도 있다.— Xaosflux^Talk 13:09, 2020년 8월 20일 (UTC)[응답]

BLP의 대부분의 대화 페이지는 NOINDEX 지시어를 삽입하는 템플릿을 갖는 방법으로 noindex된다. 왜냐하면 이러한 대화 페이지는 Template을 초월하기 때문이다.BLP(Blp)는 다음과 같은 내용을 담고 있다.__NOINDEX__. 관례상{{BLP}}직접 사용되지는 않지만, 두 가지 방법 중 하나 또는 둘 다에 의해 수행된다.{{WikiProject Biography living=yes}}또는{{WikiProject banner shell blp=yes 1=...}}. --Redrose64 🌹 (대화) 19:37, 2020년 8월 20일 (UTC)[응답]

• 내가 새로 만든 페이지를 위해 방금 관찰한 것은, NPP에서 체크아웃되지 않았기 때문에 아직 구글에 나열되지 않았음에도 불구하고, 그 대화 페이지가 나열되어 있다는 것이다.그건 분명히 우리가 원하는 게 아니야.{{u Sdkb}}} 23:49, 2020년 8월 31일(UTC)[응답]

샌드박스 남용을 억제하기 위한 대책?

이전에 제안된 것일 수도 있지만, 샌드박스 편집이 자동 확증 상태에 반영되지 않도록 MediaWiki 소프트웨어를 수정하는 것이 가능할까, 아니면 프로젝트의 무료 백과사전 목표를 지키면서 자동 확증 특권을 조금 더 엄격하게 만드는 것이 가능할까?나는 내가 양말 계정을 통해 말하지 않을 어떤 트롤의 공공 기물 파손 행위를 본 적이 있다. 그의 이름은 양말 계정을 통해 샌드박스를 남용하는 것이다. 단지 자동 확증된 보호장치를 사용하기 위해 사용하는 것을 심지어 끈질긴 반보호 기능이 있는 페이지에서도 본 적이 있다.트롤이 얼마나 끈질기고 끈질기게 프로젝트를 방해하고 그와 손발을 맞댄 사람들 사이에 불화를 뿌리는지 생각하면 나는 솔직히 분개한다.블레이크 그리플링 (대화) 13:45, 2020년 9월 10일 (UTC)[응답]

제한하는 것은 꽤 쓸모없고, 역효과적일 것이다.나는 생방송 기사에 무작위적이고 부정확한 쉼표를 삽입하기 보다는 누군가 샌드박스에서 빈둥거리게 하고 싶다.자동 확증의 목적을 고려해야 하며, 이는 매우 최소 요구 사항이며 얻기 어렵게 의도된 것이 아니다.만약 당신이 그것을 바꾸려고 한다면, 이 "롤링"들은 멈추지 않을 것이고, 당신은 무심코 메인 스페이스로 이슈들을 보낼 것이다.미루는 Reader (대화) 15:38, 2020년 9월 10일 (UTC)[응답]

자동 그룹에 대한 액세스 권한을 부여하기 위해 다른 유형의 임계값을 사용할 수 있지만, 위의 PR 노트처럼 "자동 확인"의 막대는 주로 비위키피디아 봇과 캐주얼 스팸 발송자/밴달에 대한 화면으로서 매우 낮음을 의미한다.— Xaosflux 16:06, 2020년 9월 10일(UTC)[응답]

• 이것이 당신의 원래 질문을 직접적으로 다루지 않는다는 것을 알지만, 만약 남용되고 있는 특정 페이지(또는 작은 페이지 세트)가 있다면, WP:ECP를 적용할 수 있다.WP에서 요청 가능:RFP, 또는 정말로 위키에서 논의될 수 없다고 생각되면 언제든지 이메일을 보내주십시오. -- RoySmith (대화) 16:20, 2020년 9월 10일 (UTC)[응답]
• 이 질문은 상당히 규칙적으로 어떤 형태로든 자주 "주공간 편집에 대한 허락을 제한하기 위해" 제기된다(WP에 있는 것이 거의 확실하다).이 시점에서 PEREN).자동화된 권한이 부여되는 방법에 있어 상당한 재작업이 필요할 것이다.사용자 게임 허가는 해당 사실 이후 일상적으로 처리된다. --Izno (토크) 16:37, 2020년 9월 10일 (UTC)[응답]

강력한 반대 샌드박스는 샌드박스다.만약 누군가가 샌드박스를 파괴한다면 위키에 어떠한 피해도 입히지 않는다.그래, 누군가 실험 페이지를 만들어 봤다면 넌 얼간이야 하지만 그건 영구적이지 않아이건 말도 안 돼.또한, 샌드박스가 연습과 같다면, 그것은 편집에 반영되어야 한다.설명이 필요 없다.방화범 (대화) 00:19, 2020년 9월 11일 (UTC)[응답]

설명:분명한 것은, 이것은 샌드박스 편집이 기록되고 자신의 기여 이력에 반영되는 것을 막기 위한 것이 아니라, 사용자들이 자동 확증 상태에 대한 자격을 얻기 위해 시험 편집을 함으로써 사용자들이 게임을 하는 것을 막기 위한 것이다.블레이크 그리플링 (대화) 02:01, 2020년 9월 11일 (UTC)[응답]

나는 네가 10번 수정했더라도 확증 상태를 오토콘하기 전에 4일을 기다려야 한다고 확신해.무슨 말인지 알겠어, 하지만 정확히 말하자면, 학대자들은 샌드박스에 가서 확증된 상태를 얻는 게 아니라, 누구나 편집할 수 있는 것을 파괴하는 거야.방화범 (대화) 14:50, 2020년 9월 11일 (UTC)[응답]

그리고 그렇게 하는 사람들은 자동 확인 상태를 다른 방법으로 우회할 수 있는 다른 방법을 찾을 것이다.개방된 백과사전이야, 이것이 그 임무 성명의 부작용이야.—DJ (대화 • 기여) 14:36, 2020년 9월 14일 (UTC)[응답]

• 나는 사용자: DragingReader에 동의하는 경향이 있다.주요 기사를 반달리즘하는 것보다 샌드박스에서 빈둥거리는 사람이 더 낫고, 예를 들어 위키피디아가 노골적인 조작을 삽입한다면 샌드박스가 보르비(토크) 15:30, 2020년 9월 14일(UTC) 실험용이라는 메시지를 받을 가능성이 높다[응답하라].
• @Blakegripling ph: Won't help, 샌드박스를 사용하지 않고 10개의 편집을 생성하는 것은 식은 죽 먹기이다.나는 수면자들이 4일 후에 확증되는 것을 막기 위해 10개의 편집이 더 많다고 생각한다.그리고 물론 선의의 신인들도.나는 그것이 공공 기물 파손 행위를 막기 위한 의도였는지 의심스럽다.— 알렉시스 재즈 (나에게 말하거나 ping me) 16:57, 2020년 9월 14일 (UTC)[응답]
  • 그것은 실제로 도움이 된다. 왜냐하면 만약 반달들이 자동으로 보호되는 위키피디아의 일부를 파괴하고 싶다면, 그것은 반달에게 그 부분을 파괴하지 않도록 강요하거나, 4일 동안 공격을 지연시키거나, 혹은 잠시 위키피디아의 반론적인 부분이 되도록 강요할 수 있기 때문이다.그래서 그래, 샌드박스 편집 카운트를 없애는 것은 별로 도움이 되지 않을 거야.방화범 (대화) 18:46, 2020년 9월 14일 (UTC)[응답]

• 그들이 위키피디아의 건설적인 부분을 좀 잘 하지 않는다는 점을 제외하면 말이다.오토콘 버스터는 보통 아주 사소한 1자 편집이나 Null 공간을 편집하여 10자 편집에 도달한다.샌드박스가 이런 목적을 위해 계산되는지 아닌지는 중요하지 않다. 왜냐하면 샌드박스는 다른 곳에서 편집만 할 것이기 때문이다.—조금 푸른 보리 v^_^v 20:41, 2020년 9월 14일 (UTC)[응답]

• 샌드박스에 대한 자신의 기여가 하나의 편집 카운트에 반영되어서는 안 된다는 제안자의 말이 있는가?위키피디아에서 "편집 카운트"를 클릭할 경우 샌드박스에 대한 단순한 편집 횟수가 얼마나 되는지 알 수 있는 방법이 있는가?보르비 (토크) 07:50, 2020년 9월 16일 (UTC)[응답]
• 위키피디아의 편집 횟수 함수에 방금 참여했는데, 이 함수는 토크 페이지 편집 횟수, 메인 페이지 편집 횟수, 사용자 대화 횟수, 카테고리 대화 횟수 등을 알려 주지만 샌드박스에 편집 횟수를 명시하는 섹션은 따로 없다.샌드박스에 대한 편집이 어떤 카테고리에 속할지 잘 모르겠고, 기술적으로 어려울 수 있다는 점은 높이 평가하지만, 편집 카운트에 "샌드박스" 섹션을 도입하는 것이 실현 가능한지 궁금하다.보르비 (대화) 06:41, 2020년 9월 17일 (UTC)[응답]

CentralNotice 배너: Indictor Wikisource Profredthon 2020

동료 여러분, 인디케이터 위키소스 콘테스트 2020년 10월 1일(10월 1일~10월 15일, 인도의 모든 IP, WP, only)에 대한 CentralNotice 배너 제안에 대해 의견을 제시하십시오.감사합니다.자얀타 (CIS-A2K) (토크) 12:32, 2020년 9월 18일 (UTC)[응답]

상태에 따라 작동하는 "스마트" 사용자 지정 토글 구현

Phabricator에서 개선 요청을 검토하는데 얼마나 걸리는지 아십니까?내가 일을 만들었어, 팸:T262622, 지난 주에도 아직 논평이 나오지 않았다.나는 그곳의 작업흐름을 잘 모르기 때문에, 만약 그러한 변경이 2-3주 이상 걸릴 것 같으면, 여기(미디어위키 네임스페이스에서) (허용된 것으로 볼 때) 이 요청을 이행하는 것이 적당할까?작업에서 연결된 스크립트는 나의 샌드박스다.알렉시스쿠티뉴 (대화) 14:06, 2020년 9월 18일 (UTC)[응답]

@Xaosflux 및 TheDJ:

스텁 태그 제거

나는 이것이 대담한 제안이라는 것을 알고 있고, 논란이 될 것 같지만, 짧은 꼬리표는 유용하지 않다.그들은 사람들이 그들의 명시적인 목적인 단조로운 기사를 편집하도록 하지 않는다.그들은 많은 부정적인 면을 가지고 있다.그들은 종종 스타급 이상으로 올려진 후에도 오랫동안 기사에 남아있다.그들은 종종 더 최신식인 토크 페이지 배너에 언급된 수업들과 충돌한다.그들은 기사에 쓸모없는 이미지와 잡동사니를 더한다.이제 그것들을 없애는 것에 대해 생각해 볼 때가 되었다.말수가 적은 사람들을 위해, 아마도 실험이 실행되어야 할 것이다. 스텁 태그가 무작위적인 기사 부분집합에서 제거된 다음, 예를 들어, 1년 동안 유사한 기사 부분집합과 비교되고 개선 수준을 측정해야 한다.생각나는 거 있어?납북(이유) 00:35, 2020년 6월 21일 (UTC)[응답]

여기서 실제로 두 가지 분명한 문제를 확인했다고 생각한다. 1) 스텁 태그가 명시된 목적을 달성하고 있다는 증거는 없으며, 2) 스텁 태그가 위키프로젝트 평가와 충돌하고 있다.#1의 경우, 나는 실험이 흥미로운 결과에서 나올 수 있다고 생각한다.#2의 경우, 위키프로젝트 평가가 스텁에서 업그레이드될 때 스텁 태그를 제거하는 멋진 봇 작업이 될 수 있을 것 같다.스텁 태그를 제거할 때 추가할 봇에 대한 재평가 플래그를 생성하기 위해 {{WPBannerMeta}}을(를) 업그레이드할 가치가 있을 수 있지만 Wiki Project에서는 여전히 스텁으로 평가되고 있다.#1에 대한 실험을 위해 나는 다음과 같이 제안한다.

1. 10,000개의 무작위 기사 목록을 가져오고, 위키프로젝트에 의해 스텁으로 평가되지 않거나, 해당 토크 페이지에 스텁 태그나 위키프로젝트 배너가 없는 것을 제거하십시오.
2. 나머지 기사에 대한 평가를 수행하고 실제 스터브가 아닌 것은 모두 제거하십시오.
3. 위키프로젝트는 스텁태그를 지정했는지 여부에 따라 문서를 분할하고 스텁태그를 제거/추가하여 각 위키프로젝트의 문서 수를 대략적으로 균등하게(각 항목 1/3 이상 촬영)한다.할당되지 않은 문서에서 스텁 태그를 제거하여 총 카운트를 균등하게 조정하고, 다시 두 그룹 중 하나에 대해 1/3 이상 진행하십시오.
4. 두 그룹의 경우 봇 편집은 무시한 채 편집크기의 측면에서 상하(사분위수??th?)를 삭제하고, 관심(독특한 편집자의 편집 횟수), 관여(반복되지 않은 편집자의 편집 횟수, 등록 편집자의 등록 편집자 편집 횟수), 전체적인 기사 변경(실험 실행 시간 동안 기사에 추가된 총 산문)을 비교한다.반아이작_WS^cont 14:17, 2020년 6월 21일 (UTC)[응답]

   조언해줘서 고마워.납치 (이유) 23:07, 2020년 6월 21일 (UTC)[응답]

• 반대 OP는 그 제안을 뒷받침할 어떤 증거도 제시하지 않는다.나는, 프로젝트 템플릿과 평가를 없애고 싶어. 난 이런 것들이 좋은 일을 하는 것을 본 적이 없고, 그것들은 더 오래 지속되는 경향이 있거든.그 단조로운 템플릿은 비교적 눈에 띄지 않고 격려와 유쾌한 음색을 가지고 있다.Andrew🐉 (대화) 22:47, 2020년 6월 21일 (UTC)[응답]

  그래서, 나는 어떤 증거도 제시하지 않고, 당신은 토크 페이지 평가가 아무런 도움이 되지 않는다고 말하고, 또한 어떤 증거도 제시하지 않는다.납치 (이유) 23:07, 2020년 6월 21일 (UTC)[응답]

  이것은 나의 제안이 아니므로 증거를 제공하는 것은 나의 책임도 아니다.하지만 여기 몇 가지 예가 있는데, 둘 다 내가 최근에 만든 기사들이다.첫째, 암바르나야를 고려하라.{{river-stub}}} 태그로 이것을 만들었다.사용자:Catan0nymous가 스텁 태그 2개를 추가함: {{러시아-스텁}, {{Siberia-스텁}} 및 사용자:그런 다음 아부네는 그 스터브를 {{러시아-강-스텁}}과{시베리아-스텁}}로 통합했다.이 태그는 세 가지 기능을 가지고 있는 것 같다.

  1. 기사를 카테고리에 배치하는 방법:범주:시베리아 지리학 스터브 및 범주:러시아강 둔치
  2. 적절한 아이콘 표시 - 러시아 및 시베리아 지도
  3. 이 글은 시작에 불과하다고 독자들에게 조언하고, 기사를 확장하는데 도움을 주기 위해 그들을 초대하는 것.

  나의 두 번째 예는 최장수 라디오 프로그램 목록이다.그럴 경우, 페이지에는 파운데이션으로서 좋은 구조가 필요하고 어떤 것이 가장 좋을지 확신할 수 없었기 때문에 {{공사 중}} 태그로 시작했다.일단 그것이 끝나면, 나는 태그를 제거했다.그 무렵 목록 구조가 확립되어 {{동적 목록}} 태그를 사용하여 리스트가 상당히 열려 있음을 표시했다.그 태그는 또한 독자에게 소싱된 항목을 추가하도록 유도해서 나도 스텁 태그의 필요성을 못 느꼈어.

  이 두 경우 모두 스텁 태그가 수정해야 하는 문제임을 나타내지 않는다.현명한 편집자들은 그들이 적합하다고 생각하는 대로 그것들을 사용하고 그들은 어떠한 문제도 일으키지 않는 것처럼 보인다.한 가지 도움이 되는 특징은 관습에 의해, 그것들이 기사의 발 밑에 놓여진다는 것이다. 그들이 방해가 되지 않는 곳에 말이다.

  Andrew🐉 (대화) 08:00, 2020년 6월 22일 (UTC)[응답]

  Andrew Davidson, 나는 평가 시스템에 동의한다.어처구니없는 일이다.기사는 Stub, Start, C, B, GA, A 또는 FA일 수 있다.그것은 7단계인데 터무니없다.그 등급은 아주 작으며, 평가 기준은 주관적이다.A급 기사는 "독자들에게 매우 유용하다"고 하지만 GA는 "거의 모든 독자들에게 유용하다"고 말한다.말도 안 돼. -- 로이스미스(토크) 02:15, 2020년 6월 22일 (UTC)[응답하라]

  ITN, OTD 또는 DYK의 1면 기사에 대한 최소 허용 기준은 프로젝트 수중에 있기 때문에 명시적으로 언급할 수는 없지만, 완전히 참조되어야 한다는 요건(디슈바톤도 동일함) 때문에 사실상 B등급이다.GA와 FA는 지역사회의 평가다.B급 기사는 일반적으로 GA가 될 수 있지만, DYK, FA 또는 FT로 가져가려고 하지 않는 한 검토를 위해 제출할 동기가 거의 없다(GA는 이미 충분히 밀렸다).마찬가지로 A급 기사는 일반적으로 검토 후 FA가 될 수 있지만, 대부분의 경우 각 편집자가 제출할 수 있는 숫자에 제한이 있기 때문에 FA가 될 수 없다.그래서 우리는 세 가지 카테고리를 가지고 있다(스텁, 스타트, C).그들 사이의 차이는 상당히 객관적이지만 그 구별의 가치는 의심스럽다.호크예7 (토론) 22:57, 2020년 7월 20일 (UTC)[응답]

• 코멘트 나는 제안된 실험이 솔직히 어떤 명확한 결과를 만들어낼 수 있을지 의심스럽다.사람들은 종종 짧은 꼬리표를 제거하기를 꺼리거나, 단순히 그것을 알아차리지 못한다.위키피디아 표제는 내 경험에 비추어 볼 때 기사에 나와 있는 것만큼 저평가되기 쉽다.더 유용할 수 있는 것은 기사가 일정한 크기를 초과하는 곳에 스텁(stub)으로 태그가 붙은 기사 목록이다(무엇을 알 수 없는 것).이것들을 검토하면 대부분의 쇼는 삭제될 수 있을 것으로 예상된다.물론 사람들은 여전히 이것을 해야 한다.존보드 (대화) 23:59, 2020년 6월 21일 (UTC)[응답]
  • 문제는 특정 크기를 선택하는 것이 아니라 크기를 정의하는 것이다.쉽게 빠져나갈 수 있는 방법은 위키텍스트의 등장인물을 세는 것이고, 당신은 결국 채석장:query/46032로 끝나게 된다.그러나 그 중 상당수는 절대 길이에도 불구하고 6개 이하의 문장만 가지고 있다.—크립틱 01:22, 2020년 6월 22일 (UTC)[응답]

    Negomboke Negombo_투표_분할 - 그러나 그것은 다른 스리랑카 선거구들과 마찬가지로 어마어마한 테이블이 있고 확실히 그루터기가 아니다.사실 나는 이것들 대부분이 주로 테이블이라고 거의 확신한다.하지만 고마워.존보드 (대화) 02:44, 2020년 6월 22일 (UTC)[응답]

    • 산문 텍스트의 크기를 쿼리하는 데 도움이 되는 유틸리티를 알고 있는가?VanIsaac_WS^cont 02:06, 2020년 6월 22일 (UTC)[응답]
      • https://www.mediawiki.org/wiki/ORES articlequality전혀 나쁘지 않다.흔히 목록과 테이블의 특징인 공통어와 반복 단어를 할인해 추측하는 것 같다.납치(이유) 04:07, 2020년 6월 22일 (UTC)[응답]

        어떻게 작동하는지 잘 모르겠지만 밀히스트 프로젝트는 지난 몇 달 동안 평가되지 않았거나 불완전한 평가를 받은 기사를 평가하는데 상당한 성공을 거두고 그것을 사용해 왔다.B등급으로 자동 평가되는 물품은 인간 검토를 위해 플래그가 부착되어 있다.호크예7(토론) 22:57, 2020년 7월 20일 (UTC)[응답]

        WPMED는 이를 성공리에 사용해 왔으며, ORES의 '스텁(stub or not stub)' 작업 중 일부는 의약품 관련 기사에 대한 교육을 받았다.참고 항목 m:연구:위키프로젝트 의학 기사를 스크리닝해서 질의를 받았어 몇 번 날 위해 검사해줬어나는 WPMED에 대한 모든 스터브 등급의 등급을 ORES 기반 봇 세트(및 제거)를 갖는 것이 아주 편할 것이다.WhatamIdoing (talk) 00:34, 2020년 8월 7일 (UTC)[응답]

WP와 같은 스터브 카테고리에서 직접 1,000개 이상의 기사가 포함된 콘테스트를 운영한 것을 고려하면:아프리카 데스터바톤 및 위키백과:영국/아일랜드 데스터바톤과 위키백과를 운영하고 있다.5만 챌린지라는 짧은 꼬리표를 직접 잡아먹는 이 도전은 내가 한동안 본 것 중 가장 멍청하고 무지한 제안 중 하나인데, 그건 뭔가를 말하고 있는 거야!!한 기사가 더 이상 스텁이 아닌 아티클에 남아 있는 스텁과 스텁 태그가 아닌 경우 프로젝트 태그를 업데이트하는 데 문제가 있지만, 그렇다고 완전히 제거할 이유는 아니다.Rosiestep과 나는 그것을 분류하기 위해 봇을 제안했지만, 위키백과 커뮤니티는 그들이 분열된 방식으로 우리가 그것을 분류하는데 필요한 합의를 이끌어내지 못할 것이다.『 백과사전』2020년 6월 22일 08:19 (UTC)[응답]

왜 그런지 모르겠네, 사용자:백과사전.나는 너의 훌륭한 경연대회에서 상을 받았어. 하지만 개선시킬 기사를 찾을 때, 나는 단지 5개의 꼬리표를 떼는 것을 기억하지. 사실 모든 것이 단조롭다는 것을 말이야.나는 완전한 폐지에 동의하지는 않지만, 그들은 심각한 혼란에 빠져 있고 해결되어야 한다.존보드 (대화) 13:58, 2020년 6월 22일 (UTC)[응답]

맞아, 그리고 내가 모순을 통제하고 1.5kb가 넘는 읽을 수 있는 산문이 있는 기사에서 스텁 태그를 제거하고 몇몇 사람들이 반대하는 토크 페이지 태그를 업데이트하기 위해 봇을 제안했을 때 믿겨져?앤드류 데이비드슨부터 시작합시다.『 백과사전』 14:04, 2020년 6월 22일 (UTC)[응답]

적어도 봇이 돌아다니면서 시작 클래스 이상을 주장하는 토크 페이지 템플릿이 있는 모든 거대한 기사에서 스텁 태그를 제거할 수 있을까?그럼 오류가 날 때까지 더 작은 기사로 작업하는 게 어때?납북(이유) 04:18, 2020년 6월 24일 (UTC)[응답]

응. 사실 밀히스트봇은 이미 이 임무를 수행할 수 있어.호크예7(토론) 22:57, 2020년 7월 20일 (UTC)[응답]

AWB는 또한 (일반적인) 크기 이상의 아티클에서 스텁 태그를 제거함으로써 비슷한 일을 한다.WhatamIdoing (대화) 00:35, 2020년 8월 7일 (UTC)[응답]

• "해당"은 주의가 필요한 기사를 탐색하는 데 도움이 된다.그들은 전형적으로 기사 맨 아래에 위치하며 기사를 개선할 의사가 없는 일반 독자들을 방해하지 않는다.기본적으로 내가 아는 한 "스텁"에는 아무 문제가 없다.사용자:Abune (대화) 13:04, 2020년 6월 22일 (UTC)[응답]

  매우 정확함, 사용자:아부네. 독자들은 거의 눈치채지 못하고, 그렇다고 해도 부정적인 영향이 있다고 보기 어렵다.일부 편집자들은 그것들이 유용하다고 생각한다.문제가 뭐죠?(A: 없다.)에드워드x (대화) 14:34, 2020년 6월 22일 (UTC)[응답]

• 자격 있는 지원.나는 제안자가 제기한 문제에 대체로 동의한다.스텁 태그는 특별히 미적으로 만족스럽지 않으며, 기사가 더 이상 적절하지 않을 정도로 확장된 후에도 남아 있는 경향이 있다.그 시점에서 그들을 찾아내 제거하려는 노력은 바쁜 일이 된다.스텁이 아닐 것 같은 글에 스텁 태그가 보이지 않게 되고 그냥 카테고리로 나타날 수 있도록 적용할 수 있는 템플릿 마법이 있는지 궁금하다.BD2412T 15:11, 2020년 6월 22일 (UTC)[응답]

  @BD2412: 문제 없음:템플릿 마법.10000은 조금 많을지도 모른다.또한 모든 스텁 템플릿이forcestub10000바이트 이상의 기사에 스텁 템플릿을 강제 적용할 수 있도록 매개 변수. - 알렉시스 재즈 01:16, 2020년 7월 21일(UTC)[응답]

• 간단한 솔루션:만약 당신이 더 이상 뭉툭한 기사가 아니라고 생각하는 기사를 우연히 보게 된다면...꼬리표를 떼다문제는 해결됐습니다.블루보아 (대화) 15:19, 2020년 6월 22일 (UTC)[응답]

  그렇지 않다 - 이런 일을 할 줄 아는 사람은 거의 없을 것이다. 이 기사들 중 xxx, xxx를 모두 본다. (숫자란 무엇인가, 아는 사람 있는가?)존보드 (대화) 21:44, 2020년 6월 22일 (UTC)[응답]

  스텁은 현재 339만9601개다.통계는 여기서 볼 수 있다.트라이키드^{[dubious – discuss]} 23:28, 2020년 6월 22일 (UTC)[응답]

  이런! 우리 기사의 반 이상이네.하지만 이것들은 프로젝트 등급이다.4,310개의 "가장 중요한" 스텁이 보인다!고마워, 존보드 (대화) 01:28, 2020년 6월 23일 (UTC)[응답]

  나는 그 가장 중요한 단어들 중 하나를 보고 싶다.시작하려면 TryKid의 링크를 따라 Category를 찾으십시오.Stub-Class_articles.여기서 Category를 선택했다.Stub-Class Accounting 기사는 비즈니스 기사에 대한 체계적 편견이 있기 때문이다.회계기준은 유망해 보였고 나는 이것이 Stub 등급이 아닌 높은 중요도로 평가된다는 것을 알았다.기사 페이지에 태그가 없기 때문에 이 모든 것은 프로젝트 템플릿에서 나온 것이다."회계기준은 대부분 21세기 초에 작성된 것"이라는 노골적인 울부짖음을 즉각 알아차렸기 때문에 어느 정도 쓸모가 있을 수 있었다.내가 또한 주목하는 것은 그것의 토크 페이지는 지난 30일 동안 7명의 독자를 가진 반면, 기사 자체는 2,481명의 독자를 가지고 있다는 것이다.이제 그 기사를 태그 폭격할 수도 있지만, 정말로 필요한 것은 개선이다...Andrew🐉 (대화) 08:55, 2020년 6월 23일 (UTC)[응답]

  그래, 3M 프로젝트 등급 스텁이야"태그된" 스텁의 수는 다음과 같은 범주에 속하는 2,265,086개로 보인다.모든 단조로운 기사들.이 숫자는 더 이상 "가장 중요한 스터브"의 많은 수가 스텁이 아니며 이미 삭제되었지만 토크 페이지가 업데이트되지 않았기 때문에 더 정확해 보인다.앞서 지적했듯이, "태그된" 스텁조차 스텁이 아니다.메인 페이지에 태그가 없는 경우 스텁의 프로젝트 등급을 자동으로 "시작"으로 업그레이드하는 봇이 필요할 수 있다.글의 크기가 일정 이상이면 자동으로 디태깅을 하겠다는 블로펠트의 생각도 좋았다.TryKid 12:59, 2020년 6월 23일 (UTC)[응답]

• 지지 나의 초창기(2005) 시절, 스텁코팅은 내가 가장 좋아하는 취미 중 하나였고, 마침내 스텁 템플릿을 폄하하는 것은 나를 슬프게 하지만, 요즘 그것들은 토크 페이지에 있는 평가 템플릿을 복제하여 불필요하다. -- -- ♦ 01 01:58, 2020년 6월 23일 (UTC)[응답]
• 반대한다. 가능한 대안은 스텁 태그를 Wiki Project 배너에 연결하는 것이지만, 기사를 Stub 클래스로 평가하면 봇이 태그를 추가하고, 기사를 Start(시작) 이상으로 업그레이드하면 봇이 태그를 제거한다.기병(토크) 02:19, 2020년 6월 23일(UTC)대체품 보유를 반대하도록 코멘트 수정. 기병(토크) 06:55, 2020년 7월 27일(UTC)[답답하다]
  • 이것은 매우 좋은 생각이다.메인 페이지와 토크 간의 불일치를 바로잡고, 메인 페이지에서는 어느 정도 우호적인 격려를 유지한다. - 나블라 (토크) 14:52, 2020년 6월 27일 (UTC)[응답]
• 반대하라 당신이 열거한 많은 문제들이 현실적이고 위키피디아에 영향을 미친다는 것에 동의하지만, 간단한 태그는 필요하다.그들은 독자들/편집자들이 내용을 기사에 추가하거나 기사의 가치를 떨어뜨리도록 하는데 그다지 효과적이지 않을 수 있지만, 백과사전 기사에 적당한 길이와 길이가 아닌 것 사이에 중요한 대조를 이룬다.대부분의 독자들은 위키피디아의 무수한 기사 길이, 다른 수업, 산문 등을 찾아보는 것을 좋아하지 않는다.스텁 태그는 간단하고 쉽게 이해할 수 있으며 핵심을 찌른다.스텁태그를 없애려면 스텁 분류만 아예 없애는 게 어때?말이 안된다.개선이 이루어져야 하지만, 우리는 개선이 필요하다.그 프로젝트에 대한 그들의 중요성은 부정적인 면보다 우선한다.미스터 스웨거21 (대화) 02:26, 2020년 6월 23일 (UTC)[응답]
• MrSwager21. - ZLEA \^C 02:52, 2020년 6월 23일 (UTC)[응답]
• 편집기 및 판독기 요구의 균형에 대한 주석.편집자 니즈(우리가 누구인가에 의해 소개된 체계적 편견을 고려할 때, 우리는 항상 지나치게 우선시하는 경향이 있다)에 대해, 여기서의 나의 테이크아웃은 태그가 편집자를 그린다는 증거는 없어 보이고, 완벽하게 그럴듯하지만, 이것은 누군가가 연구 연구를 하는 데 좋은 것일 수 있다.(여기서는 제대로 주목받지 못하는) 독자의 필요성에 대해, 우리가 기사 품질을 나타내는 방법은 약간 이상하다. 즉, 우리는 토픽콘으로 GA/FA를 표시하지만, 아래에는 태그가 있는 스텁(stub)을 표시하며, 중간에는 아무것도 표시하지 않는다.내 생각에 스터브는 품질이 낮기 때문에 일종의 경고로서 태그를 부착해야 하는 합리적인 사례가 있다.이에 대한 반론은 WP:NODISCLAIMERS와 저품질과 단지 짧은 것의 구분이 있다는 사실 그리고 나의 일화 경험에서 대부분의 단편들은 단지 짧은 시작/C 클래스 페이지보다 낮은 품질은 아니다.스텁 태그의 필요성에 대해 내가 어디에 대해 생각하는지는 잘 모르겠지만, 편집자뿐만 아니라 편집자가 아닌 독자들의 경험에 어떤 영향을 미치는지 생각해 봤으면 좋겠다.나는 그 전에 우리가 보다 일반적으로 내용 평가를 독자들에게 제시하는 방법에 대해 개선의 여지가 있다고 생각해 왔으며(특히, GA와 FA의 차이가 명확하지 않다) 그 부분에 대해 더 많은 작업을 보고 싶다.{{u Sdkb}}}07:53, 2020년 6월 23일 (UTC)[응답]
• 반대하다.그들은 도움이 되고 키가 작다.아무도 방해하지 않는다.GenQuest 10:47, 2020년 6월 23일(UTC) [응답]
• 논평: 다소 자화자찬한 것에 대해 미안하지만, 이것은 내가 토크 페이지에 있는 태그로부터 카테고리를 추가하는 확장을 제안하는 것에 대해 기대하지 않고 거의 경악하지 않고 할 수 있는 일이다.이러한 움직임은 스텁 태그로 기사를 태그하고 토크 페이지의 평가도 수행하지 않고도 페이지가 스텁 범주를 유지할 수 있게 한다.Naypta ☺ ✉ 토크 페이지 13:07, 2020년 6월 23일 (UTC)[응답]
• 현재로서는 약한 반대 - 내가 (비편집자와) 대화하는 사람들은 종종 기사를 위한 대화 페이지가 존재한다는 것을 알지 못한다.만약 스텁 태그가 가끔 그 사람에게 내용을 추가하도록 부추긴다면, 나는 그것을 좋은 것으로 본다.만약 이런 일이 일어난다는 증거가 없다는 것을 보여주는 어떤 방법이 있다면, 나는 그들의 퇴폐를 지지할 것이다.나는 그 제안이 제기될 만한 가치가 있었고 나는 지원을 고려했으며, 나는 그 주제를 탐구할 가치가 있다고 생각한다.캐스 리버 (토크 · 기여) 04:54, 2020년 6월 24일 (UTC)[응답]
• 조건부 지원.스터브 템플릿은 지저분하고 구식이며, 다른 중요한 용도가 있지만, 그들이 해야 할 일을 하지 않는다.나는 템플릿을 삭제하되, 그것들을 위키프로젝트 배너 내의 범주나 함수로 대체하는 것을 제안한다.레흐만 05:21, 2020년 6월 24일 (UTC)[응답]
• 지원 - 단순화는 좋다.스텁이 하는 일은 토크 페이지 배너(예: 위키백과 제목 평가)에서 할 수 있다/있다/해야 한다.요컨대, 우리는 기사가 어떤 상태인지 기록하는 한 곳을 가져야 하고, 한 곳은 아마도 토크 페이지 배너에 있어야 한다.레비비치 19:26, 2020년 6월 26일 (UTC)[응답]
• 캐스 리버에 대항하라.스텁 태그는 최악의 양성이다.그들은 그 기사의 문자 그대로 바닥이고 독자들이 그것을 무시하고 싶다면, 그들은 할 수 있다.나는 그것들이 어떻게 해로운 것으로 보여질 수 있는지 정말 이해할 수 없다.반면에, 만약 그들이 한 명의 독자가 기사를 확장하는데 도움을 준다면, 백과사전은 거의 아무런 비용 없이 큰 이익을 얻는다.그들은 명백한 순양성이다.그것들을 토론 페이지에 올리는 것은 우리와 우리의 내부 분류에 편리할 수 있지만, 그것은 기사 개선에 역효과를 준다.대부분의 사람들은 대화 페이지에 대해 잘 모르기 때문에(진심하게, 마지막으로 기사 대화 페이지를 볼 때 친구들에게 물어봐), 내부자들만 찾을 수 있는 스텁 태그를 숨기는 것은 내 마음속에 순 부정적이다.— Wug·a·po·des 21:37, 2020년 6월 27일 (UTC)[응답]
• 반대. 스텁 템플릿은 유지 관리 템플릿의 일종이다.그들의 편재성 때문에, 우리는 그것들을 페이지의 맨 위가 아닌 맨 아래에 두기로 결정했다.그들은 다른 유지보수 템플릿의 장단점을 공유한다.한편, 위키피디아의 역동적인 성격을 감안할 때, 우리는 기사에 맞지 않는 것이 있으면 독자와 편집자에게 경고해야 한다고 생각한다.반면에, 우리는 더 많은 시간이 태깅을 하거나 실제로 기사를 고치는 데 소비되는지 모른다.내가 스터브 템플릿에서 보는 주요 문제는 다른 사람들이 위에서 지적한 것이다.우리는 두 가지 시스템을 가지고 있는데, 그것은 스텁 템플릿과 토크 페이지 배너 입니다.이것들은 항상 일치하지는 않는다.이렇게 되면 한 가지 방법만으로 기사를 게재하는 편집자의 잘못이 있다.WP의 가이드라인:DESTUB가 두 가지를 다 사용해서 하라고 한다.나는 우리가 어느 정도 속도로 자동 기사 심사(WP:ORES)로 나아가고 있다고 확신한다.한편, 우리는 봇을 사용하여 스터브 템플릿과 토크 페이지 보증 사이의 불일치를 자동화할 필요가 있다.– 피누서톱 (토크 ⋅ 기여) 23:20, 2020년 6월 27일 (UTC)[응답]

  "더 많은 시간을 태그하거나 실제로 기사를 수정하는 데 할애하는지는 알 수 없다." 아마도 첫번째일 것이다.랜덤캐나디언 (대화/기여) 03:43, 2020년 7월 5일 (UTC)[응답]

• 다른 사람들이 이미 제안한 바와 같이, 좋은 해결책은 대화 페이지의 위키백과 배너를 통한 분류가 될 것이다. RandomCanadian (대화/기여) 03:43, 2020년 7월 5일 (UTC) 타격용 삭푸펫.P-K3 (대화) 22:47, 2020년 7월 8일 (UTC)[응답]
• 반대하라. 나는 농담이 아니다. 이것이 내가 일반적으로 쓸 GA를 찾는 방법이라고.짧은 꼬리표는 매우 귀중하다.토니발리오니 (토크) 02:17, 2020년 7월 6일 (UTC)[응답]
• 반대 나는 기사를 만드는 것을 싫어한다(어쩐지), 나는 아직 기사를 만들지 않은 것 같다.나는 기존 기사를 대대적으로 개선하는 데 도움을 주고 있으며, 몇 개의 짧은 기사를 편집하여 좀 더 꽉 차게 만들 계획을 가지고 있다.스텁은 그들의 장점이 있고, 흥미로워 보일 수 있는 주제를 찾도록 도와주며, 그것을 확장할 기회를 준다.또, 토니가 위에서 말한 것.미루는 Reader (대화) 12:23, 2020년 7월 6일 (UTC)[응답]
• 논평: 반대쪽으로 기울어짐으로써, 토크 페이지에 위키프로젝트를 배치하는 것은 독자와 편집자들에게 그들을 덜 명백하게 만들기 때문에, 나는 그것들을 잊어버리는 경향이 있다.나는 또한 다음과 같은 것을 알고 싶다.
  • 모든 스텁 범주에 Wiki Project가 관련되었는가?
  • 기사 페이지 목록을 쉽게 얻을 수 있는 경우(토크 페이지, c.f).범주:Stub-Class 비디오 게임 기사를 카테고리:Wiki Project 범주의 비디오 게임 스텁)?
  • 위키프로젝트 스텁을 스텁 템플릿과 같은 하위 범주로 구성할 수 있는가?
• —Ost (토크) 22:27, 2020년 7월 9일 (UTC)[응답]
• 약한 조건부 지원.위의 @Rehman에 따르면.그러나 이러한 스텁 템플릿을 여전히 사용하는 편집자는 거의 없을 것이다.만약 그들이 정상에 있었다면, 아마도 그것은 다른 것일지도 모르지만, 나는 그들을 떨어뜨리고 위에서 레만이 말한 대로 가라고 말한다. --Guitarist28 (토크) 14:32, 2020년 7월 14 (UTC)[응답]
• 제거에 반대하다.하지만 나는 태그의 형식이 바뀌어야 한다고 생각해.나는 단조로운 기사 위에 스텁 태그가 놓여 있는 위키하위안의 관점에서 왔다.스텁 태그가 다른 유지 관리 템플릿의 형태라면 더 유용할 것 같아.다음과 같은 경우:
  

  이 물건은 몽둥이로 낙인찍혀 있다 그것은 그 기사가 좋은 출발을 하고 있지만 여전히 그 주제에 대한 완전한 백과사전적 보도는 제공하지 못한다는 것을 의미한다.이 기사를 확장하여 위키피디아를 도와주십시오. (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

  
  그렇게 해서, 독자들은 위키피디아를 돕기 위해 그들이 할 수 있는 일을 보게 된다.독자들은 그것들을 맨 위에 올려놓음으로써 기사를 확장하는 작업을 할 수 있고, 그 기사가 더 많은 커버력을 제공하면 스텁 태그를 제거할 수 있다.아심 08:06, 2020년 7월 18일 (UTC)[응답]

  멋진 아심아심, 기사 자체에 큰 이슈가 되지 않는다는 것이 모호해야 하고, 실제로 사람들이 다음과 같이 페이지를 만들도록 장려해야 하지만, 나는 좀 더 명확한 태그의 아이디어가 좋다.
  

  이 글은 장황한 페이지다. 누구나 이 글을 확대함으로써 위키피디아를 만드는 것을 도울 수 있다. (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

  에드6767톡! 00:21, 2020년 7월 21일 (UTC)[응답]

• 코멘트 한 가지 절실히 필요한 단계는 이 스텁들을 모두 통과해서 실제로 스텁인지 확인하는 것이다.내가 직접 살펴본 기사에서 나는 1/4을 "시작" 또는 그 이상으로 다시 채점해야 한다는 것을 발견했다.그리고 "시작" 수업의 10분의 1 정도는 "C" 혹은 그 이상으로 등록되어야 한다. (내 경험이 위의 존보드와 대립하고 있기 때문에, 내 평가가 그의 것보다 더 엄격하지 않을까?)어쨌든, 나는 가능한 한 많은 스텁을 재평가하는 것이 위키백과의 스텁 수를 전체 수의 절반 이하로 줄이는 데 도움이 될 것이라고 생각한다. --llywrch (talk) 21:52, 2020년 7월 20일 (UTC)[응답]

  여기에는 두 가지 유형의 기사가 있다. (1) 이미 시작 이상으로 재졸업되었지만 여전히 카테고리가 있는 기사는 다음과 같다.스텁 메시지 템플리트 및 (2) 스텁으로 분류되지만 실제로 시작 또는 그 이상인 문서.호크예7 (토론) 22:57, 2020년 7월 20일 (UTC)[응답]

  아니면 다른 기사를 보고 있을 수도 있어나는 대부분의 평가자들이 길게만 고려한다고 생각한다. 반면에 몇몇 과목의 경우 몇 줄은 C 또는 그 이상일 수도 있다.수업의 공식적인 정의는 사실 꽤 관대하고, 대부분의 평가자들은 다소 엄격하다고 생각한다.존보드 (대화) 00:08, 2020년 7월 21일 (UTC)[응답]

  두 코멘트에 함께 응답.Hawkeye7은 봇으로 쉽게 다뤄질 수 있는 반면, 두 번째는 내가 말한 현상을 기술한다.Johnbod 나는 우리가 다른 기사들, 또는 기사들의 그룹을 보고 있다고 의심한다. 때"스터브"기사 전화에 매달리다니, 나 어떻게 완전히 그 기사가 길이보다 그 주제를 덮고 있는 것이 누구에 대해서 우리가 쓸 수 있는데, 이것은 우리에게 나는"permastub"는 주장으로--, 비록 만약 기사가 있지만,``stu로 표시되 크기 및에 5,000바이트라고 붙어 있다는 것을 의미하면 2~3문장에만 한정된다 몇가지 주목할 만한 역사적 personages이 많이 봅니다.b",나는 왜 그것이 "시작"이나 "C" 수업 대신에 그런 평가를 받는지 열심히 살펴볼 것이다.그리고 때로는 기사에서 해당 주제에 대해 어떤 정보를 입수할 수 있는지 알기 위해 전문가적 지식이 필요할 때도 있다.--llywrch (talk) 16:55, 2020년 7월 21일 (UTC)[응답]

  아, 그렇다면 아마 다른 기준일 것이다 - 나는 User:물론 "백과사전으로부터 기대되는 광범위한 커버리지"(스텁이 부족한)는 놀랍도록 모호하지만, 그루티스/크루튼-런던의 법칙, 그리고 실제로 공식적인 정의는 분명하지 않다.그러나 대부분의 인쇄물 백과사전에는 대부분의 WP 평가자들이 "스텁"이라고 부를 것이다.존보드 (대화) 17:23, 2020년 7월 21일 (UTC)[응답]

• 나는 이 아이디어를 지지하지만, 우리가 고려해야 할 몇 가지가 있다.
  1. 대중.스텁은 편집 커뮤니티 밖에서 다음과 같은 의미를 갖게 되었다.하스켈의 스크린에서 점차적으로 색이 변하는 리스트는 위키백과 입력을 한 번도 하지 않았거나, 몇 줄의 짧은 줄에 삶과 일이 없어지는 수백 명의 여성 과학자들을 대표했다.
  2. {{텔레비전 프로덕션 섹션}}}}과 같이 좀 더 설명적인 것을 선호한다.스텁 태깅은 좀 게을러.(충전된 것으로 표시됨
  3. 나는 실험을 매우 지지한다.나는 우리가 많은 기사를 고를 것을 제안한다.그 중 절반에 대해 해시가 생성되고 해시만 게시된다.나머지 절반의 경우 스텁 태그를 제거하거나 숨기지만 목록을 게시하지 마십시오.물론 그 일을 하는 봇의 기여를 볼 수는 있지만, 우리는 그것을 통제할 수 없다.우리는 리스트에 올라 있는 상당한 수의 기사가 스터브 상태를 넘어 개선될 때까지 기다려야 할 것이다. 그 때 우리는 여전히 고정되어 있는 기사들의 목록을 발표하고 비교를 할 것이다.
  4. BD2412가 제안한 대로 템플릿 매직. - 알렉시스 재즈 01:16, 2020년 7월 21일 (UTC)[응답]
• 컬리지 풋볼 프로젝트에서 편집자들을 반대하는 사람들은 편집에 집중하고 기사 개선에 도움을 주기 위해 종종 스텁 태그를 사용한다.--폴 맥도날드 (토크) 13:20, 2020년 7월 24일 (UTC)[응답]
• 스텁 템플릿을 제거하는 것에 반대한다. 그들은 기능이 있다.또한 다음이 필요할 수 있다.
  1. 스텁 템플릿에 노트 선택사항 추가
  2. 스텁 플래그와 평가 시스템을 통합하는 방법을 모색하다.
  3. 봇 작업을 만들어 편집이 전혀 없는 짧은 기사를 찾아내고 평가의 변화를 가져온다.— 고스트인The Machine 13:05, 2020년 7월 27일 (UTC)[응답]
• 논평 - 나는 주로 RS를 추가하여 수백 개의 음악 스텁 기사를 편집했다.나는 적어도 이 특정한 점에서, 분류에 유용한 스터브를 발견한다.카로7200 (대화) 15:55, 2020년 7월 29일 (UTC)[응답]
• 스텁 태그가 무엇이고, 무엇을 달성해야 하는지, 그리고 그들이 그렇게 하는지에 대해 완전히 다시 생각해 보십시오.내가 보기에, 우리가 달성하고자 하는 것은 세 가지가 있다: (i) 사람들에게 그 기사가 완성되지 않았다고 말하고 (ii) 그들에게 기부를 요청하고 (iii) 우리는 사람들이 관심 있는 지역의 스터브에 집중할 수 있도록 스터브 태그를 분류한다.요점(i)은 태그가 없는 것이 분명하지만, 유용한 것을 그만둔 후에도 기사에 남아 있는 경우가 많다.일부 기사들이 얼마나 오랫동안 뭉툭한 상태로 남아 있는지를 감안할 때, 우리는 분명히 (ii)와 함께 대단한 일을 하고 있지 않다.스터브 정렬은 부분적으로 위키백과 제목 태그 지정과 일반적으로 훨씬 개선된 카테고리 시스템으로 대체되었다.나는 단조로운 구혼자들이 그곳에 있다는 사실이 마음에 든다는 것을 인정해야 한다. (기사를 "거품"으로 태그하는 것은 기껏해야 몇 시간 안에 단조로운 구혼자를 소환하기 때문에 한 쌍의 눈을 더 붙일 수 있는 빠른 방법이다.그러나 나는 스텁을 태그하고 분류하는 것이 실제로 크게 개선되거나, 기사 플러스 토크 페이지에 스텁/비 스텁 태그가 중복되는 것이 어떤 유용한 일을 한다는 최근의 증거를 본 적이 없다.어떤 카테고리나 목록의 링크에 대한 기사 품질(스텁/스텁 상태가 아닌)을 쉽게 표시할 수 있는 방법이 훨씬 도움이 될 것이다.단지 그루터기만이 개선되어야 하는 것은 아니다.—쿠스마 (t·c) 22:47, 2020년 8월 1일 (UTC)[응답]
• 논평 나는 아무도 위키피디아에 대해 언급하지 않은 것이 흥미롭다고 생각한다. 위키프로젝트 스텁 정렬 - 구성원이 이 토론에 기여할 수 있는 내용(나도 프로젝트에서 여기 코멘터를 전혀 인식하지 못함)우리 회원 중 한 명이 어제(8월 1일) 이 토론을 발견하고 WPSS 토크 페이지에 쪽지를 올린 것으로 보인다.나는 나중에 여기 있는 모든 출품작들을 읽을 기회가 있을 때 2p를 넣을 것이다.건배, 허페그십 (?) 20:32, 2020년 8월 2일 (UTC)[응답]
• 반대: 나는 개인적으로 내 관심사와 관련된 몇 개의 스터브 카테고리를 즐겨찾기에 추가하고 정기적으로 확장하여 스텁 태그가 "스텁 기사를 편집하지 못하게 한다"는 주장과 모순된다.나는 여기서 유일한 진짜 문제는 더 이상 스텁이 아닌 기사가 여전히 그렇게 태그되어 있는 것이라고 생각한다.때때로 나는 내가 언제 기사를 아주 점진적으로 개선하는지 잘 모르겠다. 어느 시점에서 그것들이 뭉쳐지지 않게 되었는지.나는 봇이 토크 페이지 평가나 기사가 확실히 스텁이 아닌 장벽을 넘어 오래된 스텁 태그를 제거할 수 있도록 지원하겠다.~ oulfis 🌸(토크) 01:11, 2020년 8월 3일 (UTC)[응답]
• 서포트 스터브는 지저분하고 시각적인 잡동사니는 독자들에게 엄청나다.에펠레논 (대화) 05:25, 2020년 8월 3일 (UTC)[응답]
• 지지 스텁 태그는 이전 시대의 유물이다.이제 모든 기사가 토크 페이지의 여러 프로젝트에서 품질 등급을 받기 때문에, 주요 기사 페이지에서도 스텁으로 언급되는 것은 불필요하다.태그를 추가하고 올바른 범주를 찾는 데 걸리는 시간, 그리고 태그를 제거하는 데 걸리는 시간은 낭비되는 시간이다.선장Eek 0 06:57, 2020년 8월 3일 (UTC)[응답]
• 반대한다. 위키프로젝트가 많은 주제를 다루는 반면, 모든 짧은 기사가 위키프로젝트의 관점에 포함되는 것은 아니며, 모든 프로젝트가 평가 태그를 사용하는 것은 아니다.프로젝트 평가 태그에 대한 의견은 없지만, 스텁 태그/유형/고양이는 전체 백과사전에 적용 가능하고 유용할 뿐만 아니라, 다른 종류의 유지보수가 필요한 주제를 측정하는 방법이기도 하다. (스텁 기사를 구성하는 항목의 매개변수를 다시 살펴봐야 한다고 믿는다.)마지막으로 중요한 것은 위키백과의 편집자들:위키프로젝트 스터브 분류는 (내가 알고 있는) 15년 이상 스터브 유형을 충실히 유지, 분류, 표준화해왔으며, 백과사전에서 그 작업의 결실을 없애는 것은 역효과를 낳을 것이다.그녀의 Pegship (?) 17:36, 2020년 8월 3일 (UTC)[응답]
• 반대: 나는 태그와 태그 폭격에 자주 불만을 느낀다.그러나 나는 스텁 태그가 가장 덜 거슬리고 가장 값진 태그 중 하나라는 것을 알았다.기사나 대화 페이지가 변경될 때 업데이트하는 봇 작업은 가치가 있지만, 태그는 편집자들이 관심 있는 카테고리에서 스텁을 찾는 데 도움이 된다.스텁 카테고리와 위키프로젝트는 내가 처음 지적한 것도 아니고 버그가 아닌 특징이라고 생각한다.— 빌로프 (대화) 23:13, 2020년 8월 3일 (UTC)[응답]

  기사 페이지 태그와 토크 페이지 프로젝트 태그 간의 불일치는 확실히 "특징"이 아니다 - 그것은 순전히 편집자측의 부주의/연민/무시함에서 비롯된다.스텁 정의는 일반적이다 - 다른 품질 등급은 특정 프로젝트에 대한 기사의 관련성에 따라 달라질 수 있지만, 기사는 모든 사람을 위한 스텁이어야 하거나 그렇지 않아야 한다.이런 "성격"의 이점은 무엇일까?존보드 (대화) 01:28, 2020년 8월 4일 (UTC)[응답]

  빌로프가 "스텁 카테고리와 위키프로젝트가 잘 맞지 않는다"는 말은 스텁 태그의 등급과 위키프로젝트 평가 사이의 불일치가 아니라 스텁 카테고리와 현존하는 위키프로젝트(기사)의 차이라고 믿는다.18C 소설에는 위키피디아 주제가 없음에도 불구하고 '18C-노벨-스텁'이라는 꼬리표가 붙어 있다.나는 빌로브에 동의한다. 이 두 번째 종류의 잘못 정렬은 버그가 아닌 특징이다. 반면에 위키피디아는 다소 광범위해야 하기 때문에 스터브 카테고리를 갖는 것이 유용하기 때문이다.예를 들어, 영국과 아일랜드 데스터바톤에게는, 비록 전체 Shropshire 위키백과 주체가 존재한다는 것은 말도 안 되는 일이겠지만, 꽤 특정한 지리적 지역별로 분류된 스텁을 갖는 것은 매우 유용했다.~ oulfis 🌸(대화) 19:51, 2020년 8월 4일 (UTC)[응답]

  오울피스 고마워, 이게 바로 내 뜻이야. 혼란스러워서 미안해.— 빌로프 (대화) 20:47, 2020년 8월 4일 (UTC)[응답]

  그래, 설명해줘서 고마워.존보드 (대화) 21:07, 2020년 8월 4일 (UTC)[응답]

• 지지하다.스텁 태그는 프로젝트 등급 시스템(그리고 선행 프로젝트)의 하위 집합이다.몇몇 사람들은 그들이 할 일을 찾기 위해 짧은 꼬리표를 사용한다고 말했다.훌륭하군, 하지만 그들은 범주 같은 해당 프로젝트 스텁 범주를 책갈피로 지정함으로써 정확히 같은 일을 할 수 있었다.Stub-Class 동물 기사 또는 범주:스텁 클래스 기사.소프트웨어맨으로서, 나는 DRAY를 믿으며, 이제 프로젝트 등급이 나왔으니 스텁 태그가 그것을 위반한다.--로이스미스(talk) 01:55, 2020년 8월 4일 (UTC)[응답]
  • DRAY에 대한 언급은 재미있게도 방향을 잘못 잡았다.내 경험에 따르면, 기사는 보통 여러 개의 스텁 태그를 가지지 않지만, 사람들은 종종 토크 페이지에서 프로젝트 태그가 엄청나게 확산되는 것을 발견한다.그래서 나는 종종 {{Wiki ProjectBannerShell}}을(를) 사용하여 잡동사니를 줄인다.예를 들어, 나는 최근에 위키프로젝트 대체 뷰에서 위키프로젝트 세계유산 등 11개의 프로젝트 템플릿이 있는 스톤헨지를 업데이트했는데, 이는 명백히 비활성화된 프로젝트였다.다양한 프로젝트 등급은 일관성이 없으며 Vital 등급과 GA 검토와 같은 다른 독립적인 평가도 있다.반복적인 잡동사니를 줄이고 싶다면, 시작할 장소는 토크 페이지다.예를 들어, 모든 관련 프로젝트를 하나의 결합 목록에 나열하는 프로젝트에 대한 템플릿이 한 개도 없는 이유는 무엇인가?각 프로젝트마다 고유한 템플릿이 있어야 하는 이유는 무엇인가?여기서 발명된 게 아닌 것 같아.Andrew🐉 (대화) 09:59, 2020년 8월 4일 (UTC)[응답]
• 의견: "모든 기사는 토크 페이지의 여러 프로젝트에서 품질 등급을 받는다"?아니, 그들은 그렇지 않아나는 많은 스터브들을 분류하고, 자주 토크 페이지를 만들고 프로젝트 배너를 추가한다.많은 독자들은 프로젝트에 대해 잘 알지 못하며, 그들은 한 곳에 속하지 않고 단지 그들 자신이 선택한 기사들의 서브셋을 편집하거나, 그들이 가장 좋아하는 Wikigoming의 서브셋을 공연한다.만약 프로젝트가 모든 것을 한다는 믿음으로 스터브 카테고리가 폐지된다면, 우리는 "토크 페이지가 프로젝트 배너가 없는 페이지(dab 페이지 또는 리디렉션 제외)"와 같은 유지 관리 카테고리와 심지어 {{}페이지가 있는 페이지도 필요할 것이다.WP Bio}}이(가) 그러나 이보다 더 구체적인 것은 결국 분실될 것이다.PamD 19:02, 2020년 8월 4일 (UTC)[응답]
• 지지 - 스텁 태그는 시각적으로 복잡할 뿐이다.보통 위키프로젝트 범주에서 동일한 정보를 얻을 수 있다.여러 곳에서 동일한 정보를 유지하는 것은 시간과 노력(및 화면 공간)의 낭비다.칼다리 (대화)20:35, 2020년 8월 4일 (UTC)[응답]
• 지지하다.더 이상 필요 없다.우리는 아마도 더 이상 필요하지 않은 왼쪽 오버 기능들을 꽤 많이 가지고 있고, 이것은 그것들을 정리하는데 좋은 시작이 될 것이다. DGG (토크) 00:26, 2020년 8월 5일 (UTC)[응답]
• 강력한 지원 - 쓸모없는 쓰레기.쉬에르베커 (대화) 14:22, 2020년 8월 5일 (UTC)[응답]
• 반대 - 스텁 태그는 방해가 되지 않으며, 기사를 읽는 데 방해가 되지 않으며, 더 많은 내용이 필요한 기사를 분류하고 주의를 끄는 데 도움이 된다.그것들을 제거하는 것은 역효과를 낳을 것이다.우리 시대를 더 잘 활용하면 일정한 산문 크기를 넘는 글에서 짧은 꼬리표를 떼는 봇이 될 것이다.시라대 (토크) 2020년 8월 5일 16:30 (UTC)[응답]
• 지지하다.유일한 잠재적인 혜택은 확장하기 위해 매우 짧은 기사를 검색하는 것이 쉽고, 그것은 이미 위키피디아 대상 등급으로 이루어질 수 있다.한편 2020년의 독자들은 더 이상 스텁 태그가 필요하지 않을까 싶다.스노우파이어 (토크) 21:39, 2020년 8월 5일 (UTC)[응답]
• 반대한다. 스텁 태그는 백과사전의 다른 부분에 연결되며, 위키피디아 대상 등급과 함께 작동하기 때문에 삭제하는 것은 다른 모든 문제를 일으킬 수 있다.솔직히, 나는 이 짧은 꼬리표가 마음에 들어, 그들은 확실히 몇몇 독자들이 이 프로젝트에 긍정적으로 기여하도록 격려했다.위키피디아가 새로운 기고자를 잃고 있는 시대에 우리는 더 많은 기고자를 끌어들이기 위해 노력해야 하지 않을까?그것은 또한 그들이 서버의 공간을 차지하고, 상단에 있는 이슈 태그만큼 기사를 복잡하게 만들지 않는 것과도 다르다.그것들을 수정하는 것이 원래의 포스터가 원하는 것을 성취하는 더 좋은 방법인 것 같다.사용자:Heyoostorm^_talk! 16:26, 2020년 8월 6일 (UTC)[응답]
• 지지 — 내 의견으로는 그루터기는 낙서여서 쓸모가 없다.—¿philoserf?(토크) 08:07, 2020년 8월 8일 (UTC)[응답하라]
• 나는 s-o 스펙트럼의 반대편에 빠지는 것 같다.나는 WP 등급에 의존하는 것은 이치에 맞지 않는다고 생각한다(위에서 언급했듯이 많은 페이지들은 결국 스텁 태그로 끝나지만 WP 태그는 없다).효용성을 위해, 나는 "확장을 사용할 수 있는 짧은 기사를 찾는다" 측면이 효용-에스테틱스 스펙트럼에서 상당히 설득력 있다는 것에 동의하는 경향이 있다.가끔 이런 것들이 WP 등급과 일치하지 않는 것은 좀 불쾌하지만, 그것은 (위에서 언급된 바와 같이) 봇을 위한 일이다.스텁 태그가 있는 고충점이 있다면, 기본적으로 기사 쪽이든 WP 쪽이든 우리의 카테고리 구조를 복제하고 스텁 태그를 선택하는 데 훨씬 더 작은 트리를 사용할 수 있다는 것이다. (모든 서브 스텁 태그를 제거하고 적절한 범주와 적절한 WP 태그에 무게를 두어야 한다고 제안할 수도 있다; 편집자:관심 범주에 대한 ted in stub는 WP와 같은 교차 도구 중 하나를 사용할 수 있다.페트스캔).가시적인 관점에서 볼 때, 나는 사실 그것들에 대해 {{ambox}}}}}을(를) 가득 채우는 아이디어를 좋아한다.

  접선적인 관점에서, 나는 너무 많은 행동요청들이 대화 페이지에 숨겨지려고 시도되거나 숨겨진 범주로 전환되는 것에 대해 약간 슬프다.우리는 새로운 편집자들을 원하고 아마도 그것들을 얻을 수 있는 최선의 방법은 확실히 숨겨져 있는 것이 아닐 것이다. (모바일에서 지금-60%의 독자들처럼 20년 만에 세상이 바뀐 다른 모든 방식에는 신경쓰지 말라.) --이즈노 (대화) 22:58, 2020년 8월 9일 (UTC)[응답]

• 지지하다.왜 그런 것들이 일반 독자들에게 쓸모없는 것인지에 대한 배너 맹목적인 의무적인 읽기.포포 르 치엔 18:44, 2020년 8월 10일 (UTC)[응답]
• 스텁 템플릿 사용 안 함템플릿의 가시적인 부분은 편집자가 아니라 독자를 위한 것이다.위키피디아가 완성되지 않았다는 메시지를 보낸다.또한 반응을 진정시킨다."WTH, 당신이 이 주제에 대해 가지고 있는 것은 이것이 전부인가?"라고 말하면서 "그래, 우리는 이것이 불완전하다는 것을 안다"고 말했다.배너 실명 현상이 자주 일어나는 독자들에게 적용될 수도 있지만, 우리는 더 일상적인 독자들에게도 고려해야 한다.비교 {{사용자 페이지}}과(와) {{사용자 샌드박스}을(를) 비교하십시오.비록 행동에 대한 요구가 즉각적인 행동으로 이어지지는 않을지라도, 그것은 "누구나 편집할 수 있다"는 생각을 강화한다.Pelagic (메시지 ) – (17:23 Tue 11, ACCY) 07:23, 2020년 8월 11일 (UTC)[응답]
• 댓글.대화 페이지 템플릿은 모바일에서 억제되지만 스텁 태그는 억제되지 않는다(참조 또는 외부 링크를 확장해야 할 수도 있지만 마지막 섹션은 무엇이든).또한, 토크 페이지가 품질 등급과 같은 다른 기사 메타 데이터를 찾는 곳에 있어야 한다는 것은 명백하지 않다.Pelagic (메시지 ) – (17:23 Tue 11, ACCY) 07:23, 2020년 8월 11일 (UTC)[응답]
• 질문.백과사전이 스텁과 품질 태그를 직접 업데이트하는 봇에 대한 합의를 얻지 못했다면, 이를 카테고리처럼 검토하기 위해 카테고리에 추가하는 봇은 어떨까?스텁이 아닌 스터브?아니면 다른 대화형 질문?ORES를 통해 기사를 실행하는 것이 얼마나 자원비용이 큰가, 저장/게시판에 자동으로 계산되어 개정판에 저장되는가, 아니면 ORES 점수를 스텁 태그에 비교하는 봇이 실행하는데 얼마나 많은 비용이 들까?Pelagic (메시지 ) – (17:23 Tue 11, ACCY) 07:23, 2020년 8월 11일 (UTC)[응답]

위키백과:최근에 업데이트된 데이터베이스 보고서/긴 스텁출품작을 확인할 수 있는 봇이 있는지, 아니면 사람만이 할 수 있는 것인지 모른다.그녀의 Pegship (?) 17:36, 2020년 8월 12일 (UTC)[응답]

• DGG당 지원.나는 그들이 유용성보다 오래 살았다는 것에 동의한다.그들은 또한 그렇지 않으면 더 유용한 일들을 하고 있을 gnome 편집자들을 위한 일거리의 구덩이가 된다.캘리오페젠1 (대화) 00:16, 2020년 8월 16일 (UTC)[응답]

우리들 중 몇몇에게는 스터브 정렬이 WP 편집의 유일한 측면이다.스텁을 보관할 이유가...그냥.;P 허 페그십 (?) 00:52, 2020년 8월 16일 (UTC)[응답]

• 지원 위키피디아에 관한 몇 가지 기사가 있는데, 짧은 글은 아니지만, 여전히 짧은 글로 분류된다.https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Long_stubs으로 이동하십시오. 일부 작은 아티클은 스텁으로 분류되지 않으므로 스텁 태그의 가치가 감소함.힌디어 위키백과나 벵골어 위키백과 같이 널리 사용되지 않는 위키백과에서는 문제가 더욱 뚜렷하게 나타나는데, 여기서 작은 기사들(일부는 100단어 미만)은 대부분 스텁으로 분류되지 않는 반면, 그 이후 개선된 일부 이전의 스텁 기사에는 스텁 태그가 여전히 포함되어 있다.수카리아 (대화) 13:07, 2020년 8월 18일 (UTC)[응답]

  힌디와 벵골어 위키피디아들이 스텁 태그로 하는 것은 그들만의 일이다.아마도 그들은 참조의 양이나 글의 질과 같은 기사 길이에만 관계하지 않는 규칙을 가지고 있을 것이다.또는 100단어 이하의 글을 만드는 사람은 단순히 스텁 태그에 대해 알지 못할 수도 있다.이유가 무엇이든 간에, 그것은 우리와 아무 상관이 없다; 우리는 그들에게 그들의 위키피디아에 있는 스텁 태그를 다루는 법을 알려줄 수 없다. --Redrose64 🌹 (토크) 15:14, 2020년 8월 18일 (UTC)[응답]

  그렇다, 스텁 태그를 추가하거나 제거하는 방법을 아는 편집자는 많지 않다. 일부 기사를 스텁 태그로 분류하거나 제거하기 위해 어떤 기준을 충족해야 하는지, 이것이 내가 스텁 태그 제거를 전적으로 지지하는 이유다.결국, 영어 위키피디아의 Stub 태그는 때때로 매우 오해를 불러일으킬 수 있다. (앞서 내가 언급했던 이 웹링크 https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Long_stubs,을 통해 아직도 Stubs로 태그가 되어 있는 길고 잘 다듬어진 기사들과 대부분의 Stub 태그를 인도의 인기 있는 토속어로 볼 수 있다.(힌디앤벵갈리처럼) 위키백과들은 모두 쓸모가 없고, 필요한 기사에서는 편집자들이 거기에 넣지 않는다.힌디 위키백과에서 100단어 이하의 Stub 기사의 예로는 인도의 유명 유튜버에 관한 https://hi.m.wikipedia.org/wiki/%E0%A4%A7%E0%A5%8D%E0%A4%B0%E0%A5%81%E0%A4%B5_%E0%A4%B0%E0%A4%BE%E0%A4%A0%E0%A5%80이 있다.수카리아 (대화) 15:34, 2020년 8월 18일 (UTC)[응답]

  힌디 위키피디아는 우리와 아무 상관이 없다.그들의 관행을 바꾸고 싶다면 이곳이 아니라 그들의 토론 포럼에서 그렇게 하라. --Redrose64 🌹 (대화) 17:00, 2020년 8월 18일 (UTC)[응답]

• 아니야? 내가 잘못하면 누군가 고쳐줄 수 있는데, 프로젝트에 관한 기사들 절반 이상이 엉터리인 것 같아.그럼... 수백 개의 템플릿을 없애고 수백만 개의 기사를 편집하는 이유는?그들의 유용성에 대해 대체로 무관심한 느낌이 있는가?미안. 그건 네가 할 일이 아니야. 주 논점이 "meh"일 때.em이 싫으면 em을 사용하지 마라.아무도 널 ANI로 끌고 가지 않을거야 왜냐면 넌 스텁 정렬에 별로 관심이 없거든GMG^talk 13:34, 2020년 8월 18일 (UTC)[응답]
• 반대하라, 문제를 찾는 해결책이다.숨막힘 (대화) 2020년 8월 21일 16:05 (UTC)[응답]
• 반대한다. 나는 의 논쟁에 대해 납득이 가지 않는다.나는 아마 그 단편적인 정보가 기사 페이지에 보이지 않아야 한다고 확신할 수 있을 것이다. 독자들은 신경 쓰지 않을 것이기 때문이다. 그들은 이미 우리가 그들을 도와줄 필요 없이 짧은 기사라고 말할 수 있다.위키프로젝트가 토크 페이지의 스텁 위에 있는 기사를 평가한 경우 스텁 태그를 보이지 않게 하거나 특정 기사 크기 위에 태그를 숨기는 등의 다른 제안도 나는 괜찮다.그러나 그것들을 없애는 것은 목욕물과 함께 아기를 버리는 것이다; 위에서 논의된 사소한 이익보다 더 큰 스텁을 위한 합법적인 용도가 있다.마이크 크리스티(대화 - 기여 - 라이브러리) 16:20, 2020년 8월 21일 (UTC)[응답]
• 한 가지 이상의 짧은 기사를 그룹화하고 접근하여 작업하는 것을 반대하는 것은 전적으로 합리적인 제안이다. 그래서 이것은 바보 같은 제안이다.그것들을 제거하는 것은 단지 프로젝트를 약화시킬 뿐이다.기사 페이지의 '스텁' 분류는 대다수의 독자들에게는 눈에 띄지 않지만, 정말로 Talk 페이지 Wiki Project 평가와 일치해야 한다.나는 종종 후자를 수정하지만 전자를 제거하는 것을 잊었다고 고백한다.봇이 오래된 스텁 태그를 제거하는 작업을 수행하는 데 동의하지 않는다면, 적어도 일부 편집자들에게 토크 페이지 사이의 불일치를 식별하는 도구가 유용할 수 있다.개인적으로, 내가 좌절감을 느끼는 것은 그 평가가 모든 위키프로젝트에 걸쳐 동일할 때, 토크 페이지에 3, 4개의 '스텁' 평가를 개별적으로 변경해야 한다는 것이다.품질 평가는 하나의 '중요성' 평가만 개별 위키프로젝트에 특정하게 남겨두면서 오직 하나만 변경될 필요가 있도록 통합하는 것과 함께 실제로 할 수 있다.내가 그걸 밖에 던질 줄 알았어.닉 모예스 (대화) 2020년 8월 21일 19:18 (UTC) [응답하라]

대부분의 경우 동일해야 하지만, 그리고 여러 개를 변경해야 하는 것은 정말로 고통스러운 일이기는 하지만, 특히 프로젝트가 대상의 일부에만 적용되는 경우, 다른 프로젝트에 대해 다른 등급을 갖는 것이 전적으로 적절한 경우가 많다.분명히 그것은 중요도 등급에 대한 경우가 훨씬 더 많으므로, 어쨌든 모든 행을 편집해야 할 것이다.존보드 (대화)20:33, 2020년 8월 21일 (UTC)[응답]

• 반대 - 스텁은 여전히 그 용도가 있으며 위에서 언급된 바와 같이 기사 하단에 직접적으로 있기 때문에 독자들에게 간섭하지 않는다. 그들은 해롭지 않고 IMHO 나는 스텁을 제거하거나 비난할 타당한 이유가 없다고 본다.— Davey2010에 의해 추가된 이전의 서명되지 않은 논평 (대화 • 기여)
• 반대하다. 위키피디아가 진행 중인 작품이라는 것은 오랜 정책이고, 스텁 태그는 그것에 대한 가장 눈에 띄는 반영 중 하나이다.그러나, 그루터기의 편협성 경향은 있어왔고, 2006년에 완벽하게 받아들여졌을 그루터기는 이제 토론 없이 일상적으로 초안을 작성한다.스텁 태그는 스텁이 위키백과의 자연적인 부분이라는 것을 상기시켜주는 역할을 하는데, 스텁을 제거하면 그 편협함이 더욱 심해질까 염려된다. --Paul_012 (대화) 09:57, 2020년 8월 28일 (UTC)[응답]
• 반대 - 사용자로서:Anomie/linkclassifier.js 스텁 태그 및 해당 범주는 이러한 링크가 위키백과를 검색하는 동안 다른 색상으로 나타나도록 하는 원인이 되며, 이를 통해 개선하고자 하는 기사를 찾을 수 있다.하지만 나는 재설계에 반대하지 않을 것이다.CSJ104 (대화) 14:54, 2020년 8월 30일 (UTC)[응답]
• 반대 – 단순히 기사를 확대하라는 초대일 뿐, 위키피디아가 진정으로 필요로 하는 것이다.짧은 글을 삭제하는 것은 많은 위키피디아가 가지고 있는 당혹감을 감추는 것이다 – 불충분한 연구와 주제 커버리지.– ishwar (speak) 05:05, 2020년 8월 31일 (UTC)[응답]
• 반대 – 나는 스텁이 유용하고 독자들이 기사를 확장하는 것을 고려하도록 격려하는 데 도움이 된다는 이전의 논평에 동의한다.나는 또한 너무 많은 완벽하게 받아들여지는 스터브들이 그것을 확장하기 위해 주도권을 행사하는 대신에 AFD를 받는 것을 보았다.나는 위의 어썸 아심이나 에드6767이 제안했던 '친절한' 유지 관리 태그가 독자들에게 기사 확대를 부추긴다는 점이 정말 마음에 든다.카터 (대화) 00:29, 2020년 9월 1일 (UTC)[응답]
• 반대 – 다섯 가지 이유: (1) 나는 그것들이 새로운 편집자에게 유용하다고 생각한다.대담해지라고?처음 가입했을 때 편집하는 게 무서웠어.무슨 일이 있어도 위키백과 스타 챔버 앞에서 전화를 걸 수 있을 것 같았다.하지만 그 후 나는 내가 읽고 있는 기사에서 단조로운 안내문을 보기 시작했고, 실제로 그것들을 개선하려고 나를 초대했다.그것이 내가 조금 알고 있는 짧은 페이지들을 편집하기 시작하게 한 것이다.스터브 노트는 새 편집자에게 보내는 초대장이다: "진짜 진심이야. 이 기사를 개선하려고 해 봐. 한번 해 봐!" (2) 그들은 눈에 띄지 않는다.페이지 하단에 있는 그들은 기사를 읽는 데 전혀 간섭하지 않는다.여기까지 읽으면 이 글이 더 나을 수 있다는 인정과 그것을 고쳐보자는 청첩장을 받게 된다.(3) 반대로 제안된 대로 페이지 상단에 큰 해트노트를 덧붙이는 것은 "이 글은 더럽다, 기사에 의지하지 말고, 할 수 있다면 얼마든지 더 좋게 만들도록 노력하라"는 것이다.기사를 읽게 하는 것은 그다지 큰 자극이 되지 않는다. (4) Talk 페이지가 있다고?누가 알았을까?왜 말하지 않았을까?(5) 스터브와 카테고리와의 복잡한 연관성에 대해 더 많이 알게 되면서, 같은 주제 안에서 서로 다른 기사들, 특히 일이 필요한 기사들 간의 상호연계를 보는 데 매우 유용하다는 것을 알게 되었다. --세르장 부즈푸즈씨 (토크) 03:36, 2020년 9월 1일 (UTC)[응답]
• 반대 – 이것은 큰 사안이며 장기적인 효과를 염두에 두고 검토해야 한다.스텁 태그는 스텁 기사를 확장하는 데 직접적으로 효과적이지 않을 수 있지만, 스텁 태그는 모든 독자들에게 "당신과 같은 사람들은 위키백과에 가입할 수 있다"는 인식을 심어주기 때문에 위키백과에 매우 유용하다고 생각한다.이것은 어떤 독자들이 편집자가 되는 방법의 중요한 부분이다. 만약 그들이 어떻게 도울 수 있는지를 나타내는 스텁 태그나 다른 유사한 태그가 없었다면 편집자의 상당수는 참여하지 않았을 것이다. 그들은 당신이 위키피디아를 편집할 수 있는지 알지 못했을 것이다.만약 짧은 꼬리표가 없었다면 위키피디아는 열린 커뮤니티보다는 책처럼 느껴질 것이고, 이런 유혹적인 느낌이 없다면 위키피디아의 편집자 수가 줄어들면 전반적으로 기사의 질이 떨어질 것이다.설문조사를 기다리는 대신 반대하기로 한 것은 설문조사가 마음에 드는 효과를 보여줄 수 없다는 생각 때문인데, 이는 엄청난 비율의 기사가 사용되어야만 느낄 수 있기 때문이다.수업 시간이 늘어난 후에도 스텁이 기사에 남아있을 수 있다는 것은 사실이지만, 특히 더 큰 기사에서는 스텁 태그를 깨닫기 어렵기 때문에, 이것은 일반적으로 독자들에게 문제가 되지 않는다.그들은 여러분이 실제로 짧은 글을 보고 있는 경우에만 여러분의 관심을 끌게 되는데, 그들이 그 기사에 있는 몇 안 되는 텍스트 조각들 중 일부일 때 입니다.파괴하는 것이 편집자들에게는 힘든 일일지 모르지만, 그것은 위키피디아 구조의 필요한 부분으로부터 발생하는 필수품이다.

KnolGua (대화) 09:53, 2020년 9월 2일 (UTC)[응답]

• 나는 항상 그것들이 무의미하다고 생각해왔다.지지하다.Foxnpichu (대화) 14:43, 2020년 9월 3일 (UTC)[응답하라]
• 지지하다.비록 그것이 대부분의 독자들에게 충분히 주제를 설명할 수 있지만, 짧은 꼬리표는 그 기사에 뭔가 문제가 있다는 인상을 준다.나는 독자들에게 기사를 확대하거나 개선하도록 호의적으로 초대하는 것이 괜찮다는 반대편의 논평자들의 의견에 동의한다. -- econterms(토크) 01:02, 2020년 9월 10일 (UTC)[응답]
  • 현재 표준 스터브 템플릿에는 "위치를 확장하여 위키백과를 도울 수 있다."라는 친절하고 긍정적인 초대장이 존재한다.그녀의 페그십(?) 20:45, 2020년 9월 10일 (UTC)[응답]
• 나는 기사 끝의 스텁 태그가 기사들의 토크 페이지에 있는 기사들의 위키프로젝트 등급보다 덜 문제가 있다고 생각한다.기사 '나라로 탈출'에 가서 토크 페이지를 보면 위키프로젝트 BBC가 관심을 갖고 있지만 이번 위키프로젝트에서는 스텁클래스로만 평가된다.글을 읽으면 너무 길어서 몽둥이로 셀 수 없다는 것을 알게 될 것이다.내 생각에 문제는 위키프로젝트가 얼마나 활동적인지보다는 스텁 태그에 덜 관련된 것 같다.보르비 (대화) 15:02, 2020년 9월 11일 (UTC)[응답]
  • 그렇다, 문제는 위키프로젝트들과 그들이 얼마나 활동적인지에 관한 것이다.그러나 우리는 여전히 스터브 태그를 제거해야 한다. 스터브 태그를 가진 비 스텁을 찾아 식별하는 것은 귀찮은 일이기 때문이다.특히 역사상 가장 큰 웹사이트 중 하나를 통해서 말이다.끝이 없다.위키프로젝트가 비활성화되면서 확장된 페이지에 스텁 태그가 많이 나온다.방화범 (대화) 15:18, 2020년 9월 11일 (UTC)[응답]
• 솔직히 말해서, 나는 Stub 등급을 받은 적이 없다.위키피디아 기사의 절반은 스텁이기 때문에 스텁 태그가 많다는 뜻이다.또한 Stub 태그를 제거하면 시작, C, B, A 등급이 남아 있는 WikiProject 등급에는 아무런 영향을 미치지 않는다.방화범 (대화) 15:47, 2020년 9월 11일 (UTC)[응답]
• 반대하다. 편집자들은 위키프로젝트로 대체될 수 없는 방식으로 그것들이 유용하다고 생각한다. 예를 들어, 18세기 소설 스텁 태그는 그 소설 기사에는 위키프로젝트가 없기 때문에 유용하다.게다가, 그들은 아마도 기사에 있는 위키피디아를 편집하기 위한 가장 큰 초대장일 것이다.난 아마 스텁 태그가 없었다면 여기 없었을 거야.재설계하는 것이 좋을지도 모른다. --Danre98^{(talk^contribs)} 03:09, 2020년 9월 14일 (UTC)[응답]
• 지지 나는 수천 개의 기사에서 스텁 템플릿을 수동으로 제거했다; 그것들은 보통 너무 오래 머무른다.또한 스텁 템플릿이 여러 개인 문서가 너무 많음.(부기사에서 스텁 템플릿을 모두 제거할 수 있는 원클릭 솔루션이 있는가?) --WS(토크) 13:10, 2020년 9월 14일(UTC)[응답]
  • 내가 믿는 바로는, 아니다.그것을 제거하는 데는 원클릭 해결책이 없다.그래도 좋은 생각이야.우리는 그것에 대한 제안을 해야 한다.방화범(대화) 14:48, 2020년 9월 14일 (UTC)[응답]
• Serjeant Buzfuz 외 연구진에게 반대하지만, 계속해서 템플릿을 개선하고 기사 등급과 더 잘 통합할 수 있는 방법에 대해 이야기합시다.레츠워브 (대화) 03:50, 2020년 9월 15일 (UTC)[응답]
  • 모든 기사에 등급 토피콘이 있었다면 스텁을 기사 등급과 더 통합시킬 수 있는 방법이 있다고 생각한다.방화범 (대화) 2020년 9월 15일 19:24 (UTC)[응답]

    원하는 경우, "페이지 헤더에 문서의 품질 평가 표시"라는 선택사항이 있다.이것은 기사의 제목을 현재의 평가를 나타내는 색상으로 표시하기 때문에 훨씬 더 좋다.(문서) Hawkeye7 (토론) 2020년 9월 15일 19:42 (UTC)[응답]

• 혼동을 피하기 위해 프로포즈리스트는 스텁(stub) 태그를 없애지, 스텁(stub)이라고 할 정도로 짧은 기사를 제거하려는 것이 아니라는 점을 지적한다.나는 아무도 그것을 제안하고 있다고 생각하지 않는다. DGG (토크 ) 22:32, 2020년 9월 18일 (UTC)[응답]

infobox에서 현재 계절 지정

예로부터 링크된 {{Infobox Award}}을(를) 본다.퓰리처상, 지구본과 타이머가 상이 수여된 가장 최근의 한 해를 나타내는 것은 분명하지 않다.가능한 접근성 문제를 제시하며, 또한 이미지가 {{Current} 유지 관리 템플릿에서 자주 사용되기 때문에 편집자에게 혼란을 야기하여, 처음에는 업데이트가 필요한 것이 있을 수 있다고 믿게 한다.샌드박스(여기 테스트 케이스 참조)에서 설명한 대로 "Current:"를 대신 사용할 것을 제안한다.그래도 되나요?업데이트: 아래 내용에 따라 유사한 상황이 있는 다른 Infobox의 유사한 변경사항을 포함하도록 이 제안을 확장하고 있다.{{u Sdkb}}} 18:32, 2020년 9월 16일 (UTC)[^{Minor refactoring done to retain context during move.}응답]

메모처럼 {{인포박스 풋볼 리그}}와 다른 스포츠 시즌 템플릿 12개가 이 또는 이와 유사한 버전의 "시계" 이미지를 사용한다.나는 이러한 이미지들의 일반적인 사용에 대한 합의를 얻기 위해, 아마도 마을 펌프스 중 하나에서 논의의 범위가 좀 더 넓어질 것을 제안하고 싶다.프라임팩 (대화) 19:04, 2020년 9월 16일 (UTC)[응답]

프라임팩, 지적해줘서 고마워!이 모든 템플릿에도 비슷한 고려 사항이 적용될 것 같으니 VPR로 이동하겠다.템플릿 목록을 작성하거나 다른 일부에 대한 구체적인 대체 표현(예: {{Infobox 축구 리그}의 경우 Current 시즌이어야 하는가?)을 제안하고 싶은 사람이 있다면 도움이 될 것이다.{{u Sdkb}}} 23:06, 2020년 9월 16일 (UTC)[응답]

지지 - 저 이미지가 의미하는가?나는 아무런 실마리도 없었고, 그것이 도대체 무엇이었는지 자주 궁금했다.이미지를 클릭하면 파일 자체로 이동할 뿐 컨텍스트는 제공되지 않는다.심지어 infobox도 편집되어 있고, 매우 명확하지 않으며, 템플릿 문서에는 이미지를 사용할 것이라는 내용이 설명되어 있지 않다. 점의 연결이 상당히 필요하다.적어도 {{Current}} 템플릿에서는 verbiage가 설명을 제공한다.논의가 확대되면 다른 사례를 봐야겠지만 적어도 {{인포박스 축구리그}}}에서는 프리미어 리그를 볼 때 그 이미지가 특별히 도움이 되는 것은 아니지만 적어도 풋볼 리그 템플릿 문서에서는 그 이미지를 사용하는데, 이는 어워드 infobox 19:31, 2020년 9월 16일(UTC)에서 한 단계 상승한 것이다.충분히]

Current라는 단어도 이탤릭체로 되어 있을 수 있을까?나머지 사람들이 동의하는지 모르겠다.나는 그것을 실행했고 내 생각에는 그것이 더 좋아 보인다.엘 밀로 (대화) 00:06, 2020년 9월 17일 (UTC)[응답]

지지 - 나는 이것을 전에 본 적이 없다고 믿지만, 시력을 가진 사용자로서 나에게 있어 그것의 의미는 완전히 불투명하며 따라서 정확히 0의 가치가 있다.무자격 사용자들의 유용성은 확실히 그것보다 적다. (우리 사이트를 이용하려는 더 많은 혼란/마약함).만약 사람들이 Current:라는 단어를 좋아하지 않는다면, 우리는 그것을 완전히 포기할 수 있을 것 같다: 이미지도 없고 말도 없고, 단지 현재의 어떤 것에 대한 링크일 뿐이다.— JohnFromPinckney (토크) 10:21, 2020년 9월 17일 (UTC)[응답]

지원 이 사람들이 무엇을 제안하려고 했는지 알아내는 데 10분이 걸렸다는 사실은 변화가 필요하다는 것을 말해준다.방화범 (대화) 16:25, 2020년 9월 17일 (UTC)[응답]

기존 제품에 대한 설명을 지원하십시오.나는 그 제안서를 세 번 읽고 새것과 옛것을 보았는데 아직도 그 물건이 무엇이어야 하는지를 이해할 수 없었다.나는 현재 버전 또한 모든 면에서 접근성을 침해한다고 생각한다.— HELLKOWNZ 22:41, 2020년 9월 18일 (UTC)[응답]

표에 항상 열 머리글 표시

긴 테이블(x축과 y축 모두)을 보는 것은 정말 짜증나는 일이다. 열 머리글은 맨 위쪽에 있지만, 필드에서 "예"와 "아니오" 값의 목록을 보고 있기 때문에 무슨 뜻인지 알 수 없기 때문이다.수십 개의 항목을 아래로 보기 전에 모든 테이블 헤더를 기억해야 한다(예: 이 페이지 표의 "US Mobile": https://en.wikipedia.org/wiki/List_of_United_States_mobile_virtual_network_operators )

테이블 위를 스크롤하면서 칼럼 라벨이 페이지 상단에 화면에 남아 있다면 매우 좋을 것이다.

현대의 웹 페이지에서는 내용을 스크롤할 때에도 페이지 상단에 "검색" 막대를 표시하는 것이 가능하고 다소 일반적이기 때문에 이 기법을 쉽게 사용할 수 있었다.

이 동작은 매우 높은 컬럼 헤더가 있는 작은 화면에 문제를 일으킬 수 있으므로 이 옵션은 테이블의 왼쪽 상단 모서리에 있는 토글 버튼(첫 번째 셀)로 구현해야 한다.— CambridgeBay가 추가한 이전 서명되지 않은 논평날씨(토크 • 기여) 23:56, 2020년 9월 15일 (UTC)[응답]

• 이 아이디어는 꽤 좋다.그것은 독자들을 불안감 없는 좌절감으로부터 지켜줄 뿐만 아니라, 테이블을 암기하는 데 낭비되는 시간을 이것으로 절약할 수 있을 것이다.방화범 (대화) 01:52, 2020년 9월 16일 (UTC)[응답]

그 배치가 가장 좋은지는 모르겠지만, 잠재적으로 고정 가능한 콜 헤더가 환영 옵션일 것이다(예: 디폴트로 꺼진 경우, 예를 들어 작은 테이블의 경우).— JohnFromPinckney (대화) 01:53, 2020년 9월 16일 (UTC)[응답]

기본적으로 활성화되는 지점은 아래 15개, 열 5개 입니다.그런 한계는 필요 없는 테이블을 없애고 그렇지 않은 테이블을 차지함으로써 테이블을 더욱 잘 정리할 수 있을 것이다.방화범 (대화) 02:02, 2020년 9월 16일 (UTC)[응답]

• 이 문제는 이전에도 몇 차례 논의된 적이 있다. 도움말 대화:표#스티커 테이블 헤더? - COVID 문서 중 일부에 대해 수행됨.기본 설정을 통해 사용할 수 있는 실험 가젯을 사용해 보십시오...— 고스트인The Machine 08:18, 2020년 9월 16일 (UTC)[응답]

• 지원 - "실험 기기"를 사용할 필요는 없으며, 모든 독자가 사용할 수 있어야 한다.아자24 (대화) 22:22, 2020년 9월 17일 (UTC)[응답]
• 이것은 우리가 지지하거나 반대할 필요가 없다.T42763은 8년째 영업 중이니 조만간 요청이 이뤄지길 기다리며 숨을 죽이지 마라.– SD0001 (대화) 03:51, 2020년 9월 19일 (UTC)[응답]

인용봇이 제기한 문제