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

작업 그룹 위키백과 닫기 제안

• wg:기본 페이지 (토크 내역 링크 감시 로그 편집)

이 위키백과 프로젝트는 영어 위키백과 프로젝트와만 관련이 있기 때문에, 나는 그들이 일반적으로 위키백과 위키백과의 종료 여부를 결정하는 메타 대신에 이 제안을 여기에 배치하기로 결정했다.이것은 .wikipedia.org 도메인 이름으로 등록되어 있음에도 불구하고 진짜 백과사전은 아니다.영어 위키백과의 단일 이슈에 전념하는 위키 전체가 그것이다.나는 우리가 위키미디어 위키에서 일어나는 모든 사건에 대해 위키를 개방해야 한다고 생각하지 않는다; 우리는 예를 들어 http://wg.ur.wikipedia.org이라고 불리는 새로운 도메인을 열 필요가 없을 것이다.그리고 어쨌든, 이 위키백과 제목과 2008년의 관련 보고서에 따르면, 위키백과 주제의 분쟁이 해결되었기 때문에 이 위키백과는 닫혔어야 했다. : TelCoNaSpVe : 05:29, 2010년 11월 22일 (UTC)[응답]

그것은 사실상 폐쇄되었다.어떤 페이지를 보려 할 때 나타나는 시테노티스가 그것을 잘 보여주는 것 같아.Killiondude (대화) 06:36, 2010년 11월 26일 (UTC)[응답]

접을 수 있는 {{Infobox 뮤지션상}}

안녕, 템플릿 {{Infobox 뮤지션 어워드}}}은 옆에 있는 모든 테이블을 수축시켜 항해가 매우 어렵고 매우 길다.그래서 나는 그 템플릿의 수상 부분을 접을 수 있게 해서 그것이 표를 구속하지 않도록 하자고 제안하고 있었다.또한 그것은 더 프로페셔널해 보인다.수동으로 코딩된 접이식 템플릿의 예는 프레셔스가 받은 표창장 목록에서 찾을 수 있다.나는 HTML로 코딩을 잘 못 해서 접을 수 있는 것을 반영하기 위해 템플릿을 어떻게 변경해야 할지 모르겠어.링크된 기사는 이 코드를 사용한다.

{{!}}}콜스판=3 {{!}}}{{!}}} 클래스="접을 수 있는 접을 수 있는 접을 수 있는" 너비=100%<! 콜스판=3 스타일="백그라운드-컬러: #D9E8FF; 텍스트 정렬: 가운데;" {{!{{}}}상 및 후보작 {{!}}}->모두들 뭐라고 할까?— 레골라스 09:56, 2010년 11월 22일 (UTC)[응답]

저 infobox는 내포된 접을 수 있는 테이블을 사용한다.가장 좋은 해결 방법은 템플릿의 토크 페이지(템플릿 토크:Infobox 뮤지션상). — Edokter • Talk • 2010년 11월 22일 (UTC)[응답]

기부금 페이지에서 계정 바꾸기

간단한 제안: 대체 계정 링크(WP:사용자 기여 페이지의 SOCK#LEGit).이를 위해서는 대체 계정에 대한 기본 설정에 추가 항목을 입력한 다음 페이지 상단에 다른 계정에 대한 링크가 주어지는 간단한 소프트웨어 변경(누군가가 그것 없이 이를 수행할 수 있는 현명한 방법이 없는 경우)이 필요하다.우리는 이미 사용자 페이지를 위한 템플릿을 가지고 있지만, 이것은 더 명확하고 놓치기 어려우며 더 편리할 것이다.Rd232 13:36, 2010년 11월 25일 (UTC)[응답]

스팸 링크

이거 딱 맞는 곳이야?해당 사용자가 블랙 리스트 링크에 연결할 수 있도록 자동 확인 또는 기타 사용자 기준을 설정할 수 있는 방법이 있는가?다른 사용자들이 스팸에 사용하기 때문에 GAC에 링크를 표시할 수 없는 것은 말도 안 되는 일이다.CTJF83 채팅 02:32, 2010년 11월 23일 (UTC)[응답]

사용자 그룹이 스팸 블랙리스트에서 면제되는 권한을 갖는 것은 기술적으로 가능하다.권리가 아직 존재하는지 모르겠지만, 나조차도 이것을 위해 어떻게 만들어야 하는지 알고 있다.그리고 그것은 무엇인가 말하고 있다:P Ajraddatz (Talk) 03:45, 2010년 11월 23일 (UTC)[응답하라]

그렇다면 이런 사용자 권리를 구현하는 것이 옳은가?CTJF83 채팅 03:50, 2010년 11월 23일 (UTC)[응답]

맨 위에 있는 사용자 권리 제안서를 보면 그렇다고 할 수 있다.하지만, 이것은 새로운 권리를 개발하는 것을 포함하기 때문에, 기술 부분에서는 더 나을 수 있다.그래도 난 모른다.Ajraddatz (토크) 03:56, 2010년 11월 23일 (UTC)[응답]

아니, WT를 잠깐 보면WPSPAM은 위키피디아를 1년 이상 스팸 발송한 스팸 발송자 몇 명을 공개한다.MER-C 02:02, 2010년 11월 26일 (UTC)[응답]

그리고 얼마나 많은 사용자들이 확증된 것은 말할 것도 없고?권리는 검토자 그룹에 추가될 수 있고, 검토자 그룹에 상당한 통제력을 더하고, 경험이 풍부한 편집자에게 장벽이 되는 것을 막을 수 있다.Ajraddatz (토크) 23:53, 2010년 11월 26일 (UTC)[응답]

편집통지 봇

문제:우리는 현재 기본적으로 관리자에 의해서만 유지 가능한 편집통지 시스템을 가지고 있다.우리는 이것을 안전성을 유지하는 방식으로 확장할 수 있다(핵심 문제는 편집고지 반달리즘은 대부분의 편집자들에게 특히 탐지하고 고치기가 어려울 것이라는 것이다).제안: 기사 토크 페이지에 추가된 템플리트에 기초하여 편집 사항을 유지하는 봇을 만든다.범주:편집통지 템플리트가 확장되고, 대화 페이지에서 적절한 템플리트 요청을 발견하면 봇이 편집통지에 추가한 표준 편집통지 템플리트가 확장된다.예를 들어 토크 페이지에서 {{British English}}을(를) 발견하면 페이지 편집통지에 {{British-English-editnotice}를 추가한다.이 기능은 토크 페이지 요청 템플릿을 편집 템플릿으로 변환하여 템플릿의 완전 보호된 목록에서 작동하며(그 자체가 완전하게 보호될 수 있음.

약간의 변화로, 토크 페이지의 템플릿이 아닌 기사 내의 카테고리에 근거하여 동일한 작업을 수행하는 것도 가능할 것이다; 이것은 정확히 같은 방식으로 작동하며, 카테고리의 보호된 목록은 편집자로 번역될 것이다.이것이 더 나은지, 아마도 조금 더 직관적이고 (?) 아마도 더 광범위하게 구현될 것 같다(아마도 과도하게 사용되었을 것이다) 그러나 템플릿 방법은 적절하다면 토크 페이지에도 메모를 보장할 것이며, 이것은 유용할 수 있다.

왜 그럴까? 예를 들어 Arbcom 제한을 편집 단계에서 필요한 곳에 알리는 등 편집 공표를 훨씬 더 광범위하게 사용하는 것이 훨씬 더 쉬워질 것이기 때문에 한 가지 예를 선택하십시오.사용 가능성의 측면에서는, 봇과 중앙 리스트에 의해 제어되기 때문에, 필요한 곳에서만 그것을 추적하고 확실히 사용하는 것이 비교적 관리 가능해야 한다(예를 들어, 봇은 요청이 특정 카테고리 내의 페이지에 적용되는 경우에만 편집 통지 템플릿을 적용할 수 있다).댓글?Rd232 02:15, 2010년 11월 26일 (UTC)[응답]

내가 그 아이디어를 지지할지 말지는 결정되지 않았지만 사용자:아노미봇 II는 이미 tboverride를 보유하고 있어 지역사회가 이 아이디어를 지지하면 그 일을 할 수 있다.한 가지 고려해야 할 점은 {{영국식 영어}}}}이 기사에 속하는지 아닌지를 두고 편집자들이 다툴 가능성이다.아노미에 02:47, 2010년 11월 26일 (UTC)[응답]

충분히 그럴 가능성이 있다. 하지만 우리는 이미 그것을 가지고 있고, 봇은 속도 제한이 내장되어 있을 수 있다(그래서 지속적으로 편집자 추가/제거를 하지 않음). 또는 심지어 토크 페이지 템플릿을 둘러싼 편집 전쟁을 감지하고 약간의 안정성이 있을 때까지 무시한다.Rd232 02:59, 2010년 11월 26일 (UTC)[응답]

언어의 변형을 주목하려면 나머지 기사 스타일 옵션을 받는 것이 좋다. -- - Gadget850 (Ed) 15:17, 2010년 11월 26일 (UTC)[응답]

그것은 하나의 예에 불과했다.그 제안은 시스템을 위한 것이다; 어떤 내용이 될 수 있는지 아는 것은 좋다. (그리고 나는 다른 스타일 옵션이 포함될 수 있다는 것에 동의한다. 그것들을 합리적으로 깔끔하게 짜내기 위해서는 아마도 다른 스타일 매개변수 옵션의 사용자 지정 템플릿이 필요할 것이다.) 하지만 그것은 지역 사회가 그것을 어떻게 사용하는지에 대해 완전히 개방적이다.Rd232 15:57, 2010년 11월 26일 (UTC)[응답]

나는 이런 종류의 스타일 문제가 아마도 다른 많은 사람들보다 더 널리 퍼져 있고(보통 악의보다는 오보에 의해) 이런 시스템에 반대하지 않을 것이라는 데 동의한다.그것은 또한 편집 고지를 좀 더 유용하게(안전하게) 만드는 역할을 할 수도 있는데, 이것은 항상 좋은 것이다.Ale_Jrb^talk 15:25, 2010년 11월 26일 (UTC)[응답]

나는 {{영국-영어-편집}}}과 같은 편집자는 편집자에게 약간의 불안정한 영향을 미칠 수 있기 때문에 증명할 수 있는 원인이 있을 때만 사용해야 한다고 생각한다.봇이 편집공고를 편집해 달라는 요청이 있다면 BRFA를 통해 사례별로 검토해야 한다고 생각한다.중요한 것은, 향후 어느 시점에는 범주별 편집 고지가 있을 수 있으며, 이는 그러한 문제에 대한 더 나은 해결책을 제공할 수 있다는 점이다.세나륨 (대화) 01:32, 2010년 11월 27일 (UTC)[응답]

나는 방금 그 벌레들에게 투표했다. 그것을 갖는 것이 좋겠다.그러나 발전 속도는 어쨌든 이렇게 할 만한 가치가 있을지도 모를 정도로 느리다.특정 편집자에 대한 우려가 있는 경우 중앙 봇 목록에서 완전히 제외하거나 관련 템플릿 또는 범주를 추가하기 위한 명확한 합의를 요구할 수 있다.Rd232 01:44, 2010년 11월 27일 (UTC)[응답]

특수 작성:접미사 색인

Special을 보완하기 위한 추가 특수 페이지:PrefixIndex는 특정 접미사가 있는 특정 페이지를 검색하는 데 큰 도움이 될 수 있다. 자세한 내용은 이 토론을 참조하십시오.(내가 보지 못한 것에 대해 이전에 토론이 있었다면 미안하고, 만약 누군가 그것을 발견한다면, 다음에 내가 더 잘 알 수 있도록 여기에 연결시켜줘.고마워.) : TelCoNaSpV: 01:45, 2010년 11월 21일 (UTC)[응답]

제목이 ville로 끝나는 기사를 찾으려면 검색 상자에 *ville을 입력하고 검색 버튼을 클릭하십시오.[1]

—파장 (대화) 02:21, 2010년 11월 21일 (UTC)[응답]

아, 하지만 스페셜:검색/*/FAQ에서 FAQ 하위 페이지를 제공하지 않음. : TelCoNaSpVe : 2010년 11월 23일 (UTC)[응답]

이것은 길게 서있는 벌레 btw - bugzilla:10808이다.기본적으로 현재의 db 스키마에서는 비효율적이다(현재 페이지는 알파벳순으로 정렬되어 저장되므로, 어떤 접두사로 시작하는 첫 페이지로 바로 이동할 수 있지만, 어떤 접두사로 끝나는 첫 페이지로 껑충 뛰려면 모든 페이지의 제목을 보아야 하고, 페이지 수가 많다).효율적이기 위해 만들어질 수도 있지만, (내가 아는 바로는) 현재 노력의 가치가 있다고 여겨질 만큼 충분한 관심이 없다.바월프 (대화) 04:52, 2010년 11월 28일 (UTC)[응답]

연간 CSB 개선 드라이브

제안서: 매년 1월, 한 달 내내 유명한 위키백과를 조직한다.Wiki Project 시스템 편향 개선 드라이브에 대응."약속"이라는 말은, WP: watchlist 공지사항과 함께 눈에 띄는 것을 의미한다.SIGNPOST 취재 및 비영어 위키피디아에 대한 홍보 조정."드라이브"의 핵심 부분은 편집자들이 문제에 대해 더 많이 알고 CSB 개선의 어떤 측면에 관심이 있는지 조사할 수 있는 랜딩 페이지일 것이다.나는 이것의 일부가 일종의 마법사나 가이드일 것이라고 생각한다. 예를 들어 야구의 어떤 면들이 제도적으로 무시되고 있는지, 즉 미국 밖의 야구 주제 목록과 함께 야구에 관심이 있는 사람들에게 제안하는 방법일 것이다.게다가, 특히 첫 해에 그러한 마법사/가이드를 구축하는 것은 드라이브 자체의 일부가 될 것이다; 나는 위키프로젝트 개개인이 여기서 일을 시작하는데 특별한 역할을 하기를 기대한다.기본적으로, 제안서의 핵심 요점은 (i) 사람들이 좋아하지만 생각하지 않은 방식으로 사람들의 기존 이익을 활용하려고 노력한다. (ii) CSB 적용 이슈의 성격에 대한 이해도를 향상시킨다(iii) 일반적으로 CSB 이슈의 프로파일을 높인다.Rd232 11:42, 2010년 11월 24일 (UTC)[응답]

그래, 해보자!이러한 일이 일어나도록 하기 위해 12월 중에 할 일 목록을 작성하는 것은 물론, 지리적 편향(A, B, C, D... 기사를 전 세계적인 관점을 반영하게 한다), 위키백과 목록 상의 과소대표 그룹 등 의미 있는 방법으로 업무를 세분화하는 것이 필수적일 것이다--카르윌(토크) 14:22, 2010년 11월 27일(UTC)[응답]

새 사용자 도움말 페이지

위키피디아를 연결하자고 제안하고 싶다.새로운 기고자들의 도움은 더 많은 곳에서 더 많은 페이지를 방문하여, 새로운 기고자들이 가기에 도움이 되고 친근한 곳을 찾는 사람들의 수를 증가시킬 수 있다.미디어위키를 보고 있다.미디어위키도 경고, 아마도 MediaWiki:세미프로텍스트 페이지 경고 및 MediaWiki:보호 페이지 경고.또한 아직 자동확인이 되지 않은 신규계좌가 보는 편집통지에서 연계해 줬으면 좋겠는데, 타겟팅 방법이 있을지는 잘 모르겠다.제안서는 해당 페이지의 내가 제안한 재설계와 관련이 있다(Wikipedia_talk:좀 더 친근한 랜딩 페이지가 되고 트래픽 증가에 더 잘 대처할 수 있게 될 New_collators_help_page#Redesign).피할 수 없는 한 가지 반대에 대한 선제적인 반대: 만약 그것이 너무 많은 트래픽을 발생시키고 페이지를 압도하고 우리가 그것을 다룰 방법을 찾을 수 없다면, 우리는 다시 링크를 제거할 수 있다.나는 우리가 편집장직의 감소에 대해 더 많은 문제를 가지고 있고, 위키피디아가 더 크고 더 복잡해질수록, 새로운 사람들을 위키피디아가 되도록 하는 데 더 많은 노력을 기울여야 한다고 생각한다. 단지 독자로 남아 있거나, 단지 열심히 일해서 그것을 발견하기 위해서 말이다.이 도움말 페이지를 좀 더 눈에 띄게 연결하면 도움이 되겠지만, 다른 아이디어는 듣고 싶다.Rd232 22:15, 2010년 11월 24일 (UTC)[응답]

해. 펜스&윈도우 22:25, 2010년 11월 25일 (UTC)[응답]

고마워. 우연히 재설계에 도움을 준다면 환영이야. 기본적인 접근방식은 만족스럽지만 레이아웃을 제대로 볼 수가 없어.위키백과:새로운 기고자의 도움말 페이지/헤더 재지정.왜 상자들이 줄을 서지 않는가? :(Rd232^talk 22:49, 2010년 11월 25일 (UTC)[응답]

이전에는 도움말에 새로운 기고자의 도움말 페이지에 대한 링크가 있었다.내용; 그러나 페이지를 재설계한 이후, 별로 촉망되지 않는 링크가 있는 페이지로 가려면 아래쪽에 있는 "질문"을 클릭해야 한다.WP 페이지 왼쪽에 있는 "Help" 링크를 클릭하는 사람들이 NCHP를 찾지 못하는 한 가지 이유일 수 있다.Deor (토크) 22:46, 2010년 11월 27일 (UTC)[응답]

물체, 동물, 국가의 성별에 관한 기사가 가능한가?

안녕하십니까, 세계의 영어회화 위키백과 여러분.내 영어 근사치인 거 이해해줘, 난 거품쟁이거든.몇 달 전, 나는 참조 데스크(언어)에서 비인간적인 것들의 성별에 대해 영어로 질문했다.특히 배나 보트 등에 대해 생각하고 있었다.나는 흥미로운 답을 많이 얻었다: 배는 "그녀"이고 배는 "그녀"라는 농담과 함께 "그녀"이다.답변:배에 배를 띄울 수 있다."

나는 (이유를 모르고) 기차를 제외한 대부분의 교통수단이 '그녀'라는 것을 알게 되었다고 그는 말했다.하지만 모토바이크는 어떨까?자전거에 대해서?

영어 실력을 향상시키는 것이 모든 사람에게 도움이 될 것이고, 영어 교사인 내 아내조차도 그것에 대해 모든 것을 알지 못한다는 것을 알아두십시오.예를 들어, 그녀의 문법 책들은 이 주제에 대해 포괄적이지 않다.

예를 들어, 이 페이지: http://en.wikipedia.org/wiki/Gender_in_English#Modern_English은 기차, 자전거, 산악 지대 등에 대해 말하지 않는다.

그 답들 중 하나는, 데스크가 그 주제에 관한 기사를 쓰는 것이 좋을 것이라고 제안하면서, 이런 종류의 질문들이 빈번히 나온다는 것을 고려했다.

이 주제에 대한 기사를 작성해 줄 수 있는지, 아니면 위에서 인용한 기사를 좀 더 간단하게 작성해 줄 수 있는지 물어보기 위한 그 모든 소개.

네가 하는 모든 일에 정말 고마워.조데스바티뇰스-르하임스-프랑스---90.18.67.249 (대화) 13:33, 2010년 11월 27일 (UTC)[응답]

여기에 성(性)에 대한 전체 사상에 대한 오해가 있는 것은 아닌지 궁금하다.명사는 다른 언어와 같은 방식으로 영어에 성별을 가지고 있지 않다.우리는 실제로 중립적인 확정 기사("프랑스어 "le" 대 "la"가 아닌")를 가지고 있다.'선박'이 여성 명사라는 것이 아니라, 특정 선박이 통상적으로 여성 물체로 간주된다는 것이다.그리고 어떤 성으로 취급되는 물체는 거의 없다(대부분의 모든 것이 그저 '그것'일 뿐이다).배의 기원을 '그녀'로 찾는다면 흥미로울 것이다.DMACKs (대화)20:36, 2010년 11월 30일 (UTC)[응답]

배는 적어도 페니키아 사람들이 살던 때부터 "그녀"라고 일컬어졌는데, 그 이유는 그녀가 항해한 여신에게 배를 바치는 것이 관습이었기 때문이다. (브래쉬, R, 1969년).어떻게 시작됐을까?)조데즈바티뇰스-르하임스-프랑스는 어떤 것에 열중하고 있을지도 모르며, 아마도 왜 어떤 물체들이 종종 여성으로 여겨지는지를 설명하는 기사가 필요할 것이다.말레우스 파투오름 21:14, 2010년 11월 30일 (UTC)[응답]

나는 영어의 문법적 성별이라는 기사를 지지하고 그것을 내 감시목록에 미리 추가했다.

—파장 (대화) 22:08, 2010년 11월 30일 (UTC)[응답]

이 주제를 적절히 다루는 것 같은 영어의 젠더가 이미 있다. 나는 거기서 제안된 제목을 바꾸었다.확장이 필요할 수도 있다.Dcoetzee 01:43, 2010년 12월 1일 (UTC)[응답]

제안

예를 들면 다음과 같다.

전쟁은 지금/현재 계속되고 있다.위키백과 텍스트로 사용 가능

현재 단어와 현재 단어를 사용하지 마십시오.당신은 이 문제에 대해 모든 회원들에게 경고해야 한다.지금 현재 단어들은 제거된다.

왜냐하면;

예를 들면 다음과 같다.

전쟁은 지금/현재로 계속된다. 또는 현재 단어는 2009년 9월 1일에 쓴다. 나는 2010년 6월 1일에 이 텍스트를 본다.

아마도 전쟁은 2010년 6월 1일에 끝났을 것이다.나는 아직도 전쟁이 계속되고 있다고 생각한다.

오류를 수정하는 로봇 및 멤버에 대해 경고하십시오.그들은/우리는 이 단어를 삭제한다.그들은/우리는 더 적절한 문장과 단어들로 변화한다.

88.235.131.60 (대화) 14:45, 2010년 11월 27일 (UTC)[응답]

"전류"의 사용은 상황에 따라 다르다.더 이상 전류가 아닌 "지금" 또는 "현재"라는 단어가 사용된다면, 편집자는 단지 그것을 변경해야만 할 것이다.위키피디아가 바뀐다.이 사이트에서는 특히 실제 문맥이 없으면 특정 단어를 사용할 수 없다고 말하는 것은 불가능하다.수정할 필요가 있다고 생각되는 특정 기사가 있는가?Ian.thomson (대화) 2010년 11월 27일 (UTC) 14:52 [응답]

{{}}}}이(가) 이를 설명한다.펜스&윈도우즈 23:39, 2010년 11월 27일 (UTC)[응답]

위키백과를 참조하십시오.Style#Precise 언어 설명서.프라임헌터 (대화) 05:18, 2010년 11월 28일 (UTC)[응답]

{{}}}} --사이버코브라 (대화) 02:43, 2010년 11월 29일 (UTC)[응답]

지미 웨일스에 관한 기사 (인터넷 밈)

얘들아, 오랜만이다.

위키피디아 설립자 지미 웨일스를 중심으로 한 새로운 인터넷 밈에 대한 기사를 쓰는 것이 아직 적절하지 않을까?몇몇 주목할 만한 언론 매체들은 이 밈의 증가를 다루었고 나는 그것이 포함에 대한 일반적인 공신력 지침을 충족시키는지 확신할 수 없다.고마워요. 말리스 (토크) 2010년 11월 27일 17:57 (UTC)[응답]

나는 위키피디아 내의 위키피디아의 기금 모금 노력에 대해 작고 균형 잡힌 시각으로 시작하겠는데, 우리를 응시하고 있는 지미의 얼굴 주변의 푸로레에 초점을 맞추고 있는 근현상과 해군의 놀라움을 피했다.펜스&윈도우즈 23:04, 2010년 11월 27일 (UTC)[응답]

알았어, 고마워.나는 단지 그것이 얻어낸 유의미한 관심이 일반적인 요약의 가치가 있을 수 있다는 것을 느꼈다.그것 또는 새로운 밈은 위키피디아의 기금 모금과 관련하여 현재 존재하는 기사의 일부가 될 수 있다. 말리스 (토크) 01:23, 2010년 11월 30일 (UTC)[응답]

좋은 2차 공급원은 [2]이다.그러나 KnowYourMeme wiki는 호환 가능한 라이센스가 없으므로 직접 복사할 수 없다는 점에 유의하십시오.Dcoetzee 01:26, 2010년 12월 1일 (UTC)[응답]

위키백과의 역사에 자료를 추가해 보십시오.기금 마련.펜스&윈도우즈 01:36, 2010년 12월 1일 (UTC)[응답]

관측 중단 모드 및 관측 중단되지 않은 모드

좋은 생각이 있다:욕설, 섹스 레퍼런스, 고어, e.tc, 이 모든 것을 검열하고 검열하는 기사에 대해 모드를 선택해야 한다. 82.13.79.52 (토크) 07:57, 2010년 11월 24일 (UTC)[응답]

위키백과를 참조하십시오.그런 종류의 위키백과 CD 선택.위키피디아에서 하는 것 자체는 여러 번 제안되어 왔고 매우 심한 반대가 있다.하지만 만약 당신이 몇몇 브라우저들을 위해 다양한 종류의 일반적으로 원하는 검열을 하기 위한 추가 기능을 쓰고 싶다면, 나는 그것이 위키피디아가 현재 그것을 피하고 있는 더 많은 사람들에게 도움이 될 것이라고 생각한다.여러분이 고려하고 싶은 다른 다양한 종류의 검열은 창조주의자들을 위한 진화론, 자유주의 기후 변화, 낙태 그리고 공화주의자들을 위한 오바마, 사이언톨로지 신학자들을 위한 Xenu, 총기 그리고 자유주의자들을 위한 폭력, 당신은 심지어 9/11과 같은 선택된 기사들을 탈레반 독자들을 위한 그들의 신념에 더 부합하는 다른 사이트로 바꿀 수 있다.더 이상 위키피디아가 접속되지 않는다는 것이 독자들에게 명백하다면, 나는 이것이 사람들에게 위키피디아를 가져오고 그들이 놓치고 있는 것을 보여주는 데 도움이 될 것이라고 생각한다.Dmcq (대화) 10:43, 2010년 11월 24일 (UTC)[응답]

학교용 위키피디아 버전은 아마도 이 시점에서 가장 좋은 선택일 것이다.Killiondude (대화) 06:32, 2010년 11월 26일 (UTC)[응답]

아마 안 될 거야, 학교를 위해 만들어진 거니까, 그리고 난 프로그래밍을 잘 못해.주변에 검열할 수 있는 부가기능이 있을까? 82.13.79.52 (대화) 16:56, 2010년 11월 29일 (UTC)[응답]

아마 아닐 것이다.Killiondude (대화) 2010년 11월 29일 17:12 (UTC)[응답]

미:(참 안됐군.섹스 리플리프, 고어, 욕설, 에티씨 싫어.

거대한 푸시!

M: 아니, 난...

거대한 푸시!

나: 그만해!

82.13.79.52 (대화) 08:47, 2010년 12월 1일 (UTC)[응답]

특수:삭제 취소 및 특수:개정삭제

현재 DeleteRevision은 삭제된 수정본의 내용을 사용할 수 없는 것으로만 표시하며, 관리자는 이러한 수정본이 특수:에 표시되지 않는 것을 알 수 있다.무절제하다.수정사항을 "정상" 방식으로 삭제하려면, 관리자는 여전히 전체 페이지를 삭제한 후 유지하고자 하는 수정사항을 복원해야 한다.DeleteRevision이 실제 "삭제" 기능을 가지고 있다면 좋을 것이다. --Ixfd64 (대화) 23:05, 2010년 11월 28일 (UTC)[응답]

개정판을 삭제하는 구태의연한 방법을 사용할 실질적인 이유는 없다.특수:RevisionDelete는 지금 "정상적인" 방법으로 간주되어야 한다.미스터 지만 23:29, 2010년 11월 28일 (UTC)[응답]

특수 시와 같음:RevisionUndelete? : TelCoNaSpVe : 23:57, 2010년 11월 28일 (UTC)[응답]

옛 방법(삭제&복원)이 역사를 들여다보면 보통 사람을 '취미'하고 있다는 것을 알게 된다.나는 그것이 행해져야 할 유일한 시간은 역사 병합의 경우라고 생각한다.2010년 12월 1일 (UTC) ododשווodOd Mishehu 09:47 (UTC)[응답]

ZMan당, 이전 방법을 사용할 이유가 없어야 한다.또한 TelCo, 나는 당신이 RevDel 인터페이스를 정말 이해한다고 생각하지 않아...수정본은 삭제된 방법과 동일하게 복원된다.Ajraddatz (토크) 19:18, 2010년 12월 1일 (UTC)[응답]

기본 벡터 스킨에 무언가를 추가하기 위한 제안

이 페이지를 체크아웃하고 화면 왼쪽 아래를 보고 아래로 스크롤하여 내 제안이 완전히 적용되는지 확인하십시오.나는 이것을 직접 만들었고, 나는 그것의 변형된 버전이 특히 나처럼 느린 스크롤을 가진 사람들에게 유용하고, 멋지고, 어쩌면 불필요한 도구가 될 것이라고 생각한다.무작위로 또는 의도적으로 다른 기사를 검색하기로 결정한다면 긴 글에 도움이 될 것이다.야수의 충고 한 마디:바보같이 굴지 마, 윌리 쌈! 03:37, 2010년 11월 28일 (UTC)[응답]

나는 그것이 확장 가능한 도구 상자와 함께 재생되지 않고, 아마도 인터위키 링크와 함께 재생되지 않을 것이라고 생각한다.절대 포지셔닝의 표준적인 문제인데, 고정할 수 있을 것 같지 않다.전체 사이드바를 그렇게 하면 효과가 있을 텐데, 심각한 문제 없이 화면 높이만큼의 사이드바 링크를 둘 이상 가질 수 없다.검색 상자에 이미 액세스 키가 할당되어 있으므로 alt-shift-f(Firefox의 경우, 다른 브라우저의 경우 약간 다를 수 있음)를 눌러 검색 상자에 표시되는 모든 위치에서 입력 포커스를 설정할 수 있다는 점에 유의하십시오.— 가비아 임머 (대화) 03:56, 2010년 11월 28일 (UTC)[응답]

Indeed, it's painfully easy to bring focus to the search box as it is; on my machine (Mac 10.6, Safari 5.03), all I have to do is hit tab to get to the search box. (which is to say nothing of how badly that would interact with a long list of interwiki links) EVula// talk // ☯ // 20:07, 30 November 2010 (UTC)[reply]

그러나 당신이 무슨 말을 하는지 모르고 너무 게을러서 나처럼 위쪽으로 스크롤하여 알아내는 것은 게으른 사람들에게 페이지와 함께 아래로 스크롤하여 우리의 커서를 [여기에 검색 상자 게시물 삽입]으로 옮겨서 알아보는 것이 더 쉬워질 것이다.말할 것도 없고, 이미 검색 상자로 이동하는 방법과 상관없이 벡터 스킨에 쿨/편안한 추가가 될 수도 있다.그리고 그게 인터위키 링크를 어떻게 방해하겠어?야수의 충고 한 마디:바보같이 굴지 마, 윌리 쌈! 23:53, 2010년 12월 3일 (UTC)[응답]

기사 뒤에 어떻게 가는지 누가 말해줄래? 지금은 다 가려져 있으니까.내 사용자/대화 페이지와 하위 페이지에서 이 템플릿을 사용할 예정이기 때문에 이 질문을 하는 겁니다.이 페이지에 응답하지 말고 여기에 응답하십시오.야수의 충고 한 마디:바보같이 굴지 마, 윌리 쌈! 00:25, 2010년 12월 4일 (UTC)[응답]

템플릿으로 변경:reflist 글꼴을 wiki 전체로 변경하시겠습니까?

대부분의 신상품에는 {{reflist}}이(가) 사용되는 것 같다.역사적으로, 템플릿이 개발되었을 때 우리는 이미 가지고 있는 기사에 <참조/>를 남겼다.우리는 봇이 reflist 템플릿을 대신 사용하기 위해 <reference/>의 나머지 용도를 검토하여 변환하도록 해야 하는가? 템플릿이 <참조/> 태그와 약간 다른 모양(작은 글꼴)을 주기 때문에, 이점은 획일적인 스타일링이 될 것이다.단점은 <참조/>를 사용하는 페이지의 확립된 스타일을 바꾸는 것일 것이다.— 칼 (CBM · talk) 20:28, 2010년 11월 29일 (UTC)[응답]

참고: 논의 중에 제안서가 {{reflist}}과 같이 <참조> 형식을 만들기 위해 CSS를 편집하는 것으로 변경되었다.— 칼 (CBM · talk) 03:16, 2010년 11월 30일 (UTC)[응답]

모든 기사에 {{reflist}의 스타일링을 적용하고 싶다면 기사보다 CSS를 바꾸는 것이 더 쉽지 않을까?대수학자 20:31, 2010년 11월 29일 (UTC)[응답]

그것이 가능하다면 우리는 (a) 그렇게 해야 하고 (b) reflist에서 이용할 수 있는 추가 옵션이 사용되는 경우에만 reflist로 reflist를 교체해야 한다고 선언해야 한다.사소한 포맷에 대한 많은 봇 편집이 변경되거나 (CSS가 업데이트된 경우) 포맷이 변경되지 않도록 하는 것은 도움이 되지 않는다.Rd232^talk 20:42, 2010년 11월 29일 (UTC)[응답]

그렇다, 모든 인용구를 스타일링할 수 있어야 한다.Mediawiki에서 스타일을 수정하여 php 참조:common.css.이는 <참조> 또는 {{reflist}}을(를) 사용하는 기사에 영향을 미칠 것이다.단, {{reflist}}}의 글자가 두 번 줄지 않도록 의 스타일링과 동기화되어야 한다.스타일링이 이미 같다면 마이너 편집 이슈에 동의한다; 아마도 AWB 같은 것에서 마이너 수정될 수 있을 것이다.그러나 그 순간 스타일이 같지 않은 까닭에, 콘세누스가 <참조/>를 사용하는 페이지에 대해 획일적인 스타일을 선호하는지, 아니면 기존의 스타일을 보존하는 것을 선호하는지를 평가하고자 하는 것이다(Carl (CBM · talk) 20:46, 2010년 11월 29일 (UTC)[응답]

그럼 CSS를 바꿔서 스타일을 균일하게 만들자(Reflist style에 따라 표준화).그렇게 하면, 내가 말했듯이/ reference에서 reflist로 전환하는 것은 reflist 옵션을 실제로 사용하는 경우에만 필요하다.reflist는 결국 참조용 포장지일 뿐/ 그래서 불필요하게 사용할 필요는 없지 않은가?Rd232^talk 22:13, 2010년 11월 29일 (UTC)[응답]

reflist가 남아 있는 유일한 옵션은 많이 사용되는 컬럼이다.common.css를 간단히 편집하면 동기화가 충분히 쉽다.나는 CSS 글꼴 크기를 로 옮기는 것을 지지한다.내가 예상하는 유일한 문제는 피부 CSS에 사용자 정의 선언이 있는 사람들이다; 그들은 우리가 템플릿에서 제거하지 않는 한 그들의 글꼴 크기가 누적적으로 감소할 것이다. 왜냐하면 그 클래스 이름은 더 이상 의미가 없기 때문이다. — Edokter • Talk • 22:24, 2010년 11월 29일 (UTC)[응답]

이것을 제거할 때의 위험은 만약 사람들이 css 파일의 캐시된 버전을 가지고 있고 우리가 템플릿에서 div를 제거한다면, 그들은 css 파일의 새로운 버전을 얻을 때까지 어떠한 글꼴도 줄이지 않을 수 있다는 것이다.따라서 참조를 잠시(기본 캐시 지연보다 더 길게) 두는 것이 안전할 수 있다.— 칼 (CBM · talk) 22:49, 2010년 11월 29일 (UTC)[응답]

좋은 생각인 것 같아, 난 그걸 지지해.하지만, 나는 어떤 사람들은 참고문헌보다 음이 더 큰 것을 선호한다는 것에 주목한다.이것은 극히 소수의 이용이며, 이와 같은 것에 의해 사례별로 쉽게 취급될 수 있다.{{reflist text-size=regular}}, 또는 비슷한.헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 11월 29일 (UTC) 23:09 [응답]

으, 아니.우리가 일관성을 유지하기를 원한다면, 이것은 좋은 생각이 아니다. — Edokter • Talk • 2010년 11월 29일 (UTC)[응답]

그래, 나도 동의해.나는 사실 그런 시각적 디자인 문제를 기사-지역적 합의에 맡기는 것이 유익하다고 생각하지 않는다.—chaos5023 (대화) 23:24, 2010년 11월 29일 (UTC)[응답]

그런 다음 common.css를 변경한 후 30일 후에 div classname을 제거한다. — Edokter • Talk • 2010년 11월 29일 (UTC)[응답]

그것이 그것을 하는 가장 좋은 방법인 것 같다.— 칼 (CBM · talk) 23:27, 2010년 11월 29일 (UTC)[응답]

이것은 참고문헌의 글꼴 크기에 관한 것이 아니다.교체에 관한 것이다.<references />와 함께{{Reflist}}"colwidth"와 같이 Reflist가 제공하는 추가 기능 때문에.개인적으로, 나는 보고 싶지 않다.<references />위키피디아에서 금지되어 있지만, Reflist를 사용하라는 일반적인 추천이 좋을 것이다.—벤더235 (대화) 23:19, 2010년 11월 29일 (UTC)[응답]

사실, 그것은 템플릿에서 CSS로 기능인 Fonsize를 제거하는 것이다.나는 우리가 <참고/>나 <{reflist}}>의 사용을 금지하거나 금지해서는 안 된다고 생각한다.사실, 이러한 변화는 그들이 서로 더 일치하도록 만들 것이다. — Edokter • Talk • 2010년 11월 29일 (UTC)[응답]

나는 봇 변환이 있거나 없는 <참조/>보다 {{Reflist}}}에 대한 일반적인 선호 설정을 지지한다.—chaos5023 (대화) 23:20, 2010년 11월 29일 (UTC)[응답]

AWB에 대한 코멘트: AWB는 소개한 편집자가 작은 글꼴 크기를 요청하지 않는 한 <참조/>를 두고 {{Reflist}}}을(를) 변경하지 않는다. -- Magioladis (토크) 23:23, 2010년 11월 29일(UTC)[응답]

응. 하지만 스타일이 같다면 원칙적으로 AWB에 대한 사소한 일반적 수정으로 추가될 수 있어 — 칼 (CBM · talk) 23:26, 2010년 11월 29일 (UTC)[응답]

나는 보통 참고자료가 정말 적을 때(최대 3 또는 4) <참조자/>를 사용하고 5개 이상의 참고자료는 reflist를 사용한다.30개 이상일 경우 기둥 2개가 있는 refelist를 사용한다. -- Magioladitis (talk) 23:24, 2010년 11월 29일 (UTC)[응답]

나는 다음 사이트를 통해 자세한 내용을 인용하는 것을 매우 선호한다. refs={{Reflist}}에 대한 인수를 사용하므로 <참조/>를 사용하지 마십시오.—chaos5023 (대화) 23:27, 2010년 11월 29일 (UTC)[응답]

위키피디아 창은 너무 많은 것들이 뒤섞여 있어서, 점점 더 작은 글꼴 크기들이 한 화면에 충분한 내용을 이해하기가 쉽도록 표시하기 위해 주문에 의존한다.나는 읽기 어렵다는 이유로 실행 텍스트에 사용되는 크기보다 작은 글꼴을 사용하는 것을 반대한다.Jc3s5h (대화) 00:31, 2010년 11월 30일 (UTC)[응답]

• 전에도 이 문제에 대해 여러 번 논의했었죠, 아이서클나는 항상 {{reflist}}}을(를) 사용하는 것을 지지하지만, 진지하게, 그것을 사용하지 않는 몇 개의 참고문헌이 있는 페이지에는 별 문제가 되지 않는다.이제 한 페이지에 50개의 ref가 있다면, 우리는 아마도 {{reflist}}}}로 글꼴 크기를 약간 압축해야 할 것이지만, 기사 작성 자체가 더 중요한데, 아니? :) / /ETCOMMS/ 01:57, 2010년 11월 30일 (UTC)[응답]
  • 우리는 현장 전체의 CSS 변경을 통해 약간 더 작은 크기(AFAIR 90%)를 표준화하는 것에 대해 이야기하고 있다.만약 우리가 참조를 교체하는 문제로 우리의 주의를 산만하게 하는 것을 피할 수 있다면/ {{reflist}} 또는 그 반대로, 어떤 것이 사용되는지는 중요하지 않다는 것을 보장하는 것은 정말로 작고 간단한 변화다. (편집자가 reflist의 고급 옵션을 사용하고 싶지 않은 경우)Rd232^talk 02:16, 2010년 11월 30일 (UTC)[응답]
    • 그래, 글쎄, 문제는 CBM이 글자크기에 해당하는 섹션 헤더를 쓰고, <참조 />를 {{Reflist}}로 대체하는 오프닝 단락을 썼기 때문에, 주어진 참가자가 생각하는 토론이 실제로 무엇이라고 생각하는지 동전 던지기라는 것이다.이것은 내가 CBM이 의심스러운 행동을 하고 거의 연관성이 없는 논의로 그것을 정당화하는 것을 이미 보고 있을 때 나를 정말 행복하게 하지 못한다.—chaos5023 (대화) 02:20, 2010년 11월 30일 (UTC)[응답]
      • ?<참조 />를 {{Reflist}}로 대체하는 실질적인 효과는 글꼴의 변화로, 참조 목록에서 글꼴의 표준화가 가능하다.이를 표준화할 수 있는 더 나은 대안은 CBM에 의해 제시되었고 명확해졌다.정말 그렇게 신비로운 일은 아니다.Rd232^talk 02:32, 2010년 11월 30일 (UTC)[응답]
        • 음케이. {{Reflist}}}을(를) 사용할 때 글꼴 크기를 신경 써서가 아니라 원해서 그런 식으로 구문 분석하지 않는 것 같아. colwidth=그리고 refs=어떤 경우에도 봇 집행을 배제시킬 수 있었을 것 같지만 괜찮아애시스턴스 시선은 물러났다.—chaos5023 (대화) 02:44, 2010년 11월 30일 (UTC)[응답]
          • 그 의문스러운 행동은 편집자들이 광범위한 변화가 일치한다는 공감대를 먼저 얻지 못한 채 참조 태그를 reflist 템플릿으로 바꾸는 것이었다.역사적 합의는 광범위한 변화는 바라지 않지만, 그것은 바뀌었을지도 모른다는 것이었다.나는 이 실이 이미 글꼴 크기 문제에 대해 유용한 피드백을 수집하고 있으며, 더 많이 모일 것 같아.실마리를 완전히 끝내는 것보다 실제로 그럴듯한 제안으로 표현하는 것이 더 생산적이다.더 좋은 피드백을 얻는다.— 칼 (CBM · talk) 03:13, 2010년 11월 30일 (UTC)[응답]
            • {{reflist}}은(는) 필요 없음refs=기억만 하면 돼<references/>빈 실체로 쓸 필요는 없다.너는 쓸 수 있다

              <참고 문헌><참조하다 …><참조하다 …><참조하다 …></참고 문헌> 

              역시. 삼촌 G (토크) 11:53, 2010년 12월 1일 (UTC)[응답]

• 아니, 우리는 참조에 더 작은 글씨체를 강요해서는 안 된다.논쟁의 여지가 있다.편집자는 작은 글꼴 참조를 반대하는데, 이는 작은 글꼴이 CSS로 이동된 경우, CSS를 반전시키기 위해 템플릿이 생성될 것이라고 합리적으로 예상할 수 있다.김메투 (토크) 02:49, 2010년 11월 30일 (UTC)[응답]
  • 더 작은 글꼴 참조에 반대하십니까?나는 어딘가에 있는 거부자들을 "충분히" 생각하는 것 보다 실제적이고 살아있는 거부자에게 더 많은 무게를 부여할 것이다.—chaos5023 (대화) 02:51, 2010년 11월 30일 (UTC)[응답]
  • {{reflist}}}이(가) 아닌 <참조>를 사용하는 글의 예를 명시적으로 제시하여 글꼴 변경을 피할 수 있는가?네가 묘사하는 것은 내가 항상 공감대라고 생각했던 것이지만, 사람들은 최근에 나에게 더 작은 글꼴을 사용하는 것에 대한 일반적인 공감대가 있다고 말하고 있다.그것이 사실이 아니라면 이 실타래는 다시 공감대를 형성하는 좋은 자리가 될 것이다.— 칼 (CBM · talk) 03:13, 2010년 11월 30일 (UTC)[응답]
    • 내 입장에서, 나는 내가 생각하기에 일치된 것이 아니라 내가 보고 싶은 것을 말하는 것이다. 그리고 나는 더 많은 사람들이 거대하고 모호한 편집자와 독자들의 몸을 불러 일으키는 대신에 그렇게 하기를 바란다.그렇긴 하지만, 나는 항상 {{Reflist}}이(가) 그것을 특정한 방법으로 했다는 사실 자체가 그것을 하는 최선의 방법이라는 공감대를 나타낸다고 생각했다.템플릿의 목적은 표준화라는 거지?그래서 만약 지역사회가 특정한 방법으로 하기를 원한다면, 나는 그 템플릿이 그것을 반영할 것이라고 생각했다.이것은 내게 제시했을 때, 한때 흔히 하던 대로 인용 인용 인용문 주위에 <작게>를 더 이상 붙이지 않게 만들었던 것과 같은 주장인데, 그것은 일반적으로 그렇게 되어야만 한다면 템플릿이 그것을 그렇게 구현해 낼 것이라는 추론이다.—chaos5023 (대화) 04:19, 2010년 11월 30일 (UTC)[응답]
      • 만약 템플릿이 생성되었을 때 더 작은 글꼴 크기로 넓은 스위치를 만들기로 합의했다면, 그들은 템플릿이 글꼴 크기를 바꾸도록 하는 대신 글로벌 CSS를 변경했을 것이다.그것은 표준화였을 것이다.템플릿이 글자 크기를 변경해야 한다는 것은 그 문제에 대한 원래의 합의 부족을 반영한다.아마도 그것은 지금 바뀌었을 것이다; 나는 우리가 보게 될 것이라고 생각한다.— 칼 (CBM · talk) 04:54, 2010년 11월 30일 (UTC)[응답]

• 개인적으로 레퍼런스보다 Reflist를 사용한다./나는 reference보다 reflist의 일관된 사용에 대한 변경/ 또는 cSS에 대한 변경을 지지한다/ 그래서 그것이 어쨌든 동일한 방식으로 포맷되도록.어느 쪽이든 효과가 있을 것이다.나는 양쪽의 주장을 이해하지만, 어쨌든 우리는 더 많은 참고문헌의 사용을 지지해야 하기 때문에, 훨씬 더 멋져 보이고 칼럼으로 더 잘 포맷된다.그래서... 어느 쪽이든 결정되면, 어느 쪽이든 효과가 있어.하지만 CSS를 바꾸는 것이 아마도 더 쉬울 것이라고 나는 예상한다.실버스렌^C 03:17, 2010년 11월 30일 (UTC)[응답]

다시 한 번 원론적인 주제에서 흐트러지지 않도록 당부한다.사용자 구성 요소:CBM은 다음과 같은 WP였다.ANI. 위키백과 사용자들의 교체를 허용해야 하는지에 관한 것이다.<references />와 함께{{Reflist}}(또는 그 반대) 표준 수정 사소한 오류 프로세스의 일부로.나는 그렇다고 말했고 CBM은 반대했다.—벤더235 (대화) 12:04, 2010년 11월 30일 (UTC)[응답]

당신이 주장하는 것은 <참고/>를 대신하여 {{reflist}}}을(를) 사용하는 기사를 변경하자는 공감대가 있다는 것이다.그 변화는 사소한 해결책이 아니다. 그것은 참고문헌의 스타일을 바꾼다.하지만, 나는 네가 그 변화를 광범위하게 만들 수 있는 공감대가 있다고 생각해.만일 그렇다면, 우리는 <참조/> 태그의 CSS를 같은 스타일을 제공하도록 변경하기만 하면 훨씬 쉽게 할 수 있다.

여기서 제안의 요점이 바로 그것이다.우리는 오랫동안 두 개의 평행 시스템을 가지고 있었고, 이제 그것들을 병합할 때가 된 것 같다.만약 지금 더 작은 글꼴 크기로 변경하는 것이 위키와이드의 적절한 크기라는 공감대가 형성된다면, 우리는 CSS의 글꼴 크기를 변경할 수 있고 그것을 달성하기 위해 기사 페이지를 편집할 필요가 없다.— 칼 (CBM · talk) 12:43, 2010년 11월 30일 (UTC)[응답]

제안자와의 개인적인 문제로 인해 건설적인 논쟁을 틀어지게 하지 마십시오: 네, 그러한 문제들은 그 주제와 매우 관련이 있지만, 만약 그 제안이 통과된다면, 그 문제들은 깔끔하게 없어질 것이다.그래서 이것을 내 이름으로 좀 더 명확하게 재제안했다.Rd232 13:23, 2010년 11월 30일 (UTC)[응답]

프로포즈

확실히 하자: 미디어위키를 바꾸는 것이 현재 제안되고 있다.Common.css <참조 />가 {{Reflist}}}과(와) 동일한 스타일링을 갖도록 한다.이를 통해 표준화가 보장된다.이렇게 하면, 페이지가 {{Reflist}}의 고급 옵션을 필요로 하지 않는 한, <참조 />와 {{Reflist}} 중 어느 것을 사용하는지 형식에 상관없다.찬성 모두 찬성이다.Rd232 13:23, 2010년 11월 30일 (UTC)[응답]

• Aye — Edokter • Talk • 14:03, 2010년 11월 30일 (UTC)[응답]
• Aye - d'oh! 2010년 11월 30일 14:13 (UTC)[응답하라]
• Aye.—Emil J. 14:20, 2010년 11월 30일 (UTC)[응답]
• Aye cap'n. - 포인트리스트 (대화) 14:23, 2010년 11월 30일 (UTC)[응답]
• Aye ({reflist})는 스타일리시하게 더 좋고 균일성은 확실히 좋은 생각이야 --Errant [tmorton166] 14:25, 2010년 11월 30일 (UTC)[응답]
• 그래, 일관성을 지켜줘.—chaos5023 (대화) 14:48, 2010년 11월 30일 (UTC)[응답]
• 그래, 난 일관성에 찬성해.이것 때문에 실제로 한동안 신경이 쓰였다. --Dorsal Axis 15:03, 2010년 11월 30일 (UTC)[응답하라]
• Aye, aye /ƒETECCOMMS/16:07, 2010년 11월 30일 (UTC)[응답]
• aye - Aese, SunCreator 16:50, 2010년 11월 30일 (UTC)[응답]
• 아니 - 글꼴이 너무 어려워서 읽을 수 없다.Jc3s5h (대화) 16:53, 2010년 11월 30일 (UTC)[응답]
  • 90% 글꼴 크기는 Windows에서 일반 글꼴 크기와 거의 구별할 수 없으며, 주로 콘덴드가 더 많다. — Edokter • Talk • 2010년 11월 30일 (UTC)[응답]

• 귀찮아!Jc3s5h (대화) 18:59, 2010년 11월 30일 (UTC)[응답]

• 나는 Jc3s5h의 반대를 지지한다.나 자신도 리플리스트를 유연성으로 사용하지만, 읽기에는 너무 작다.100시 90분이라고 하면 3시 2분이 보인다.보르쇼프 동쪽 19:34, 2010년 11월 30일 (UTC)[응답하라]

• 3:2 보이시죠?그것은 정말로 일어나서는 안 된다. — Edokter • Talk • 19:58, 2010년 11월 30일 (UTC)[응답]

• 안됐구나.하지만 공감대를 형성하는 과정은 가능한 한 많은 사람들을 행복하게 하는 것이다. — Edokter • Talk • 19:58, 2010년 11월 30일 (UTC)[응답]

• Aye Consistency는 좋고 매우 희망적이다.또한, 이것을 CSS 레벨에 배치한다는 것은 더 큰 참조를 좋아하는 사람들이 자신의 스타일시트를 {{reflist}과 <reference/>를 모두 포함하도록 업데이트할 수 있다는 것을 의미한다. (그리고 이제 참조 크기를 사용자 기본 설정에서 옵션으로 만들 수 있게 되었다.)헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 11월 30일 (UTC) 18:55, 답변
• 그렇다. 나는 90%의 글꼴 크기와 그것이 상징하는 모든 것을 싫어한다. 그리고 즉시 그것을 더 이상 사용하지 않기 위해 나 자신에게 바쁠 것이다. 그럼에도 불구하고, 이러한 표준화는 현재로선 진전된 방법이다.기둥 서포트가 결국 베어 속에 내장돼 별도의 템플릿이 필요 없게 되기를 바라는 것이다.— 가비아 임머 (대화) 2010년 11월 30일 (UTC) 19:48[응답]
• 일단 표준화가 되면, 너무 작다고 느끼는 사람들은 그것을 증가시킬 수 있고 정확하게 업데이트할 수 있다(아마도 한 번의 클릭으로 쉬운 해결책을 찾기 위해 간단한 기기를 집어 던질 수 있을 것이다.EVULA// talk // talk // 20:15, 2010년 11월 30일 (UTC)[응답]
  • MediaWiki:가젯-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css가 만들었다.나는 몇 가지 요소를 놓칠 수밖에 없다. 얼마든지 추가해라.이제 승인을 받으려고. — Edokter • Talk • 22:05, 2010년 11월 30일 (UTC)[응답]
• Aye 이것은 위키백과 기사의 조직과 외관을 개선해야 하며, 참고문헌이 어떻게 보이는지에 대한 기준을 따르도록 해야 한다.실버스렌^C 20:27, 2010년 11월 30일 (UTC)[응답]
• 그래 훨씬 낫지.Goodvac (대화) 22:10, 2010년 11월 30일 (UTC)[응답]
• 지지(의회, 이게 뭐야?)승리를 위한 표준화. --사이버코브라 (토크) 05:20, 2010년 12월 1일 (UTC)[응답]
• 설명: 이후{{Reflist}}더 많은 기능을 제공하므로, "의 사용"이라는 지침을 가지지 않는 것이 좋다.{{Reflist}}추천하시겠습니까?또는 적어도 "10개 이상의 ref가 있는 경우, 다중 열(예:{{Reflist colwidth=30em}})이 권장됨"?왜냐하면 그 기둥들이 가장 큰 장점이기 때문이다.{{Reflist}}에 비해<references />, 더 작은 글꼴 크기가 아님.—벤더235 (대화) 2010년 12월 1일 (UTC) 14:00[응답]
  • 그것은 이 제안의 범위 밖이다.이것은 순전히 . — Edokter • Talk • 14:06, 2010년 12월 1일 (UTC)[응답]과 동일하게 보이기 위한 것이다.
    • 이 제안은 말도 안 되는 것이기 때문에 나는 반대할 수도 있다.—벤더235 (대화) 19:39, 2010년 12월 1일 (UTC)[응답]
      • 왜 말도 안 되는 소리야?다른 것보다 reflist나 reference를 선호하기 위한 원래 추론은 기사에 따른 일관성이었다.이제 일관성을 보장하는 또 다른 방법이 생겼으니, 이제 더 이상 하나를 다른 것으로 치부할 필요도 없고, 둘 중 어느 하나를 비난할 필요도 없다. — Edokter • Talk • 20:47, 2010년 12월 2일 (UTC)[응답]
        • 글꼴 크기가 비슷하더라도 선호하는 이유가 여전히 있다.{{Reflist}}에 걸쳐서<references />, 그리고 그것이 기둥 특징이다.—벤더235 (대화) 00:11, 2010년 12월 3일 (UTC)[응답]
          • 네, 하지만 컬럼은 선택적 기능이기 때문에 컬럼을 사용하지 않을 경우 reflist 사용을 선호할 필요가 없으므로, {{reflist}}까지 대량 변환 <reference />를 할 이유가 없을 것이다. — Edokter • Talk • 01:59, 2010년 12월 3일 (UTC)[응답]
• 반대한다. 어떤 사람들은 작은 글꼴 크기에 반대한다.참고문헌을 위한 작은 텍스트는 거의 틀림없이 웹 미디어에 직접 적용되지 않는 종이 미디어 출판과 관련된 관행과 비용의 잔재일 것이다.작은 텍스트는 읽기 어렵고 참조를 강조하지 않는다.'90% 폰트 사이즈는 윈도 일반 폰트와 거의 구분이 안 되고, '정합성'이 목표라면 리플리스트에서 100% 폰트 크기 텍스트를 제작하도록 해 일관성을 얻을 수 있을 것이다.김메투(토크) 18:16, 2010년 12월 1일 (UTC)[응답]
  • 나는 이 점에 관해 내가 하고 싶었던 대답이 있어서 이 점에 대해 기쁘게 생각한다.기본적으로; 글에서 내용은 독자에게 흥미있는 것이다.참고문헌은 그들 대다수를 걱정해서는 안 된다; 우리가 기사에 참고문헌을 붙이는 유일한 이유는 편리함, 그리고 대부분 편집자의 편의 때문이다.참고문헌은 도전할 수 있는 내용(또는 인용문 또는 논쟁의 소지가 있는 자료 등)을 검증하기 위해 있다.따라서, 독자의 혼란을 피하기 위해 축소된 크기의 참고문헌을 갖는 것은 허용된다.Errant [tmorton166] 18:26, 2010년 12월 1일 (UTC)[응답]
    • 일반적으로 본문의 나머지 부분과 동일한 글꼴 크기로 참조를 볼 때 "읽기 혼란"이 발생할 수 있는 방법은 무엇인가?김메투(토크) 18:32, 2010년 12월 1일 (UTC)[응답]
      • 단지 양식적인 요점일 뿐, 기사 텍스트에 추가적인 비중을 부여한다. (내 생각에는 참고문헌을 그냥 흔쾌히 쓰러뜨릴 수도 있다) --Errrant [tmorton166] 18:35, 2010년 12월 1일 (UTC)[응답]
    • @Errant:나는 반대되는 관점을 취한다: 만약 그들이 백과사전을 출발점으로 사용하기를 원한다면, 참고문헌을 사용하여 자료를 더 깊이 파고들 수 있도록 하기 위해서 독자들을 위한 참고문헌이 먼저 있다.위키피디아인들 사이의 논쟁은 토크 페이지에 속한다.글씨 크기 변화는 인쇄물에서 나온 유물이라는 김밋수의 말에 동의하지만, 이곳에서는 풍토화된 것 같다.— 칼 (CBM · talk) 18:39, 2010년 12월 1일 (UTC)[응답]
      • 나는 참고문헌이 먼저 독자들을 위한 것이라는 것에 동의한다.글씨 크기 같은 것이 인쇄물이라는 것은 아마 사실일 겁니다만, 스타일리시하게 좋아한다는 것은 인정하겠소.그러나 스타일을 표준화하고 작은 리플을 쉽게 정해질 수 있는 선호도로 만드는 것이 위키백과 전체 독자들에게 나의 디자인 감각을 해치는 것보다 훨씬 더 나은 것 같다.—chaos5023 (대화) 19:09, 2010년 12월 1일 (UTC)[응답]
        • • 좋아, 하지만 이건 완전히 틀렸어.참고문헌은 정보를 검증하는 것이다. (이것은 독자의 노력일 수 있지만, 훨씬 더 일반적으로 편집자의 작업일 수 있다.)기사에 대한 참조 요건은 없다(공인성을 확립하기 위한 것과 별도로, 정책 용어로는 반드시 나타나야 한다) --Errrant [tmorton166] 19:15, 2010년 12월 1일(UTC)[응답]
            • 음, 음.나는 WP:검증가능성은 최소한 참고문헌의 존재를 강하게 장려하고 있으며, 그것은 "거의 도전받을 만한" 자료에서 명백히 그것들을 요구한다고 말하고 싶다.다른 출처를 요약한 3차 출처로서의 위키백과의 전체 모델은 CBM이 기사와 그 언급이 출발점이 되는 것에 대해 말하고 있는 것을 강하게 지적한다.—chaos5023 (대화) 19:39, 2010년 12월 1일 (UTC)[응답]
              • 나는 그렇게 생각하곤 했다.실제로 이 정책은 무분별하게 ref를 사용하지 않는 것을 막연히 지지하지만 도전받을 가능성이 있는 물질로부터 ref를 요구한다.이것은 많은 사람들이 나에게 설명해 주었기 때문에 널리 받아들여지고 있다고 생각한다.외부 링크는, 칼의 토크 페이지에서 언급했듯이, 바로 이런 이유로, "토끼 구멍 아래로" 스타일의 바깥쪽 링크 때문에 --Errrant [tmorton166] 19:43, 2010년 12월 1일 (UTC)[응답]
• Aye - 변화를 좋아하지 않는 선임 편집자에 대해서는, 이 (IMO)은 순 긍정적이다.또한 헤드밤 Mlpearc wow 18:55, 2010년 12월 1일 (UTC)[응답]
• Aye Magioladis (talk) 19:16, 2010년 12월 1일 (UTC)[응답하라]
• Aye Sonttyung 19:56, 2010년 12월 1일 (UTC)[응답]
• 지원 나는 Casliver (대화 · 기여) 20:38, 2010년 12월 1일 (UTC)[응답]
• Aye, Support - let the silization. --Kumioko (talk) 21:31, 2010년 12월 1일 (UTC)[응답]
• 위의 코멘트 중 일부와 아래의 기기는 주요 이슈 중 일부가 누락된 것 같다.이는 '변화를 싫어하는 원로 편집인'의 문제가 아니다.(일부에서는 이를 인신공격으로 받아들일 수도 있다.)어디에서나 작은 글꼴이나 참조 목록에 대해 논쟁하는 사람들 중 다수가 WP의 참고 문헌 참조가 모든 사람을 위한 100% 기본 글꼴 크기여야 한다고 생각한다는 것을 추측할 수 있다(단기음이나 매우 긴 참고문헌 목록은 예외일 수 있지만).일반적으로 독자들에게 가장 읽기 쉬운 옵션은 참고문헌과 텍스트가 같은 것이다."가젯"은 그런 문제를 다루지 않는다.실제로, 관점을 위해 WP 디폴트를 100%로 만드는 것은 어떨까? 그리고 일부 사람들이 양식적인 이유로 텍스트의 일부를 다르게 하고 싶다면, 가젯을 통해 그 옵션을 이용할 수 있도록 한다.김메투(토크) 03:25, 2010년 12월 2일 (UTC)[응답]
  • 책에서 각주를 보면 보통 글과 크기가 같지 않다.또한, 만약 더 많은 사람들이 일방적 방법으로 그것을 좋아한다면, 그것은 일치된 것이고, 그래서 우리는 그것을 더 작게 만드는 것이 아니라 더 크게 만드는 장치를 가질 것이다. /ƒETECCOMMS/04:01, 2010년 12월 2일 (UTC)[응답]
  • 합의의 형성은 최소한 다양한 견해에 대한 이해를 필요로 한다. 그렇지 않으면 그것은 직감적인 선호도를 가진 단지 다수일 뿐이다.스타일 문제에 대해, 다수는 - 심지어 다수는 - 심지어 큰 다수는 - 공감대를 형성하지 못하는 것으로 보인다.예를 들어, WP 편집자 대다수는 구두점 뒤에 인용 부호를 붙일 것으로 추정되지만, 그것을 의무화할 합의는 없다.그리고 이 문제에 직접적으로, 다른 글꼴 크기를 구현하는 다른 reflist 대안이 있었다.이것은 얼마 전 일이어서 기억이 흐릿하지만, 그 중 하나는 약 800여 개의 기사에 존재했던 것으로 기억하는데, 그 중 대부분은 그들이 보기에 맞지 않는다는 이유로 글자크기를 90% 반대하는 커플 편집자에 의해 유지되었던 것이다.어떤 직선적인 투표에서든 통합이 10:1이 되겠지만 WP는 반대 의견이 처리되고 거부자들이 통합에 대한 반대를 멈출 때까지 그렇게만 하지는 않았다.김메투 (토크) 04:21, 2010년 12월 2일 (UTC)[응답]
    • 나는 너무 많은 MOS 단골들이 "우리들과 의견이 다른 사람은 그 문제를 정말로 이해하지 못하므로 우리는 그들의 의견을 무시할 수 있다"는 태도를 보이고 있다는 것을 안다.Anomie⚔ 15:53, 2010년 12월 2일 (UTC)[응답]
      • 당신의 의견을 좀 더 자세히 설명하십시오.나는 그것이 여기서 어떻게 적용되는지, 내 코멘트에 어떻게 적용되는지 모르겠다.김메투 (토크) 2010년 12월 2일 (UTC) 16:19[응답]
        • "합의체 형성에는 최소한 다양한 견해에 대한 이해가 필요하다"고 하셨는데, 필자는 여기서 "일부 사람들의 견해를 이해한다면, 그들이 나에게 동의할 것이기 때문에 우리는 무시해야 한다"고 추론했다.나는 정기적으로 MOS 문제에 관여하는 사람들 사이에서 흔한 태도라는 것을 발견했는데, 그것이 내가 보기에 MOS 논의가 합의보다는 소모(즉, 한쪽이 결국 포기하거나 관련자들이 차단 가능한 행동으로 자극)를 통해 종종 결정되는 이유 중 하나로 보인다.
          또한, BTW, 구두점 이후 참조와 관련하여 기한이 지난 것으로 보이거나 WP:REFPUNC는 합의를 대표하지 않는다.Anomie⚔ 17:22, 2010년 12월 2일 (UTC)[응답]
          • 흠. 문장 부호 뒤에 ref에 이의를 제기하던 사람들이 이의를 제기하는 것을 그만둔 건 아닐까?하지만 네 코롤리어는 따라오지 않아, 어쨌든 분명히 2부는 아니야.Fetch는 책 속의 각주는 크기가 다르다고 말했지만, 종이 매체의 관행은 웹 미디어에 직접적으로 적용되지 않는다고 이미 말해왔다.그러므로 단순히 "책이 이렇게 하는 것"을 반복하는 것은 우려를 해소하는 것이 아니다.그 우려를 해소하기 위해서는 어떤 이유에서든 "이것이 웹 미디어에서 하는 올바른 방법"이라고 주장해야 할 것이다.적어도 이유가 있을 거라고 생각할 수 있지만, 일부 논평은 이유를 밝히지 않고 "발톱이 더 작아야 한다"고만 언급하고 있다.마찬가지로 '스트림라이닝은 좋다'는 주장이지만, WP 판례는 이의제기가 제기되거나 이의제기가 중단될 때까지 '스트림라인'을 하지 않는 것이었고, 나는 두 가지 예를 들었다.김메투(토크) 17:45, 2010년 12월 2일 (UTC)[응답]
            • "종이 미디어로부터의 정보는 웹 미디어에 직접 적용되지 않는다."마찬가지로, 우리는 종이 미디어가 웹 미디어에 적용되지 않는다고 해서 종이 미디어에서 관행을 바꿀 필요가 없다.내가 알 수 있는 바로는, 참고문헌의 글자 크기를 작게 하는 것에 대한 당신의 주된 반대는, 이 페이지가 인쇄된 페이지가 아니기 때문이다(그러므로 표준은 달라야 한다). 이것은 나에게 그다지 큰 비중을 두지 않는다(개인적으로).우리가 여전히 유지하고 있는 인쇄된 페이지 유형 선택사항들이 많이 있는데, 주된 이유는 매체를 불문하고 읽기가 여전히 읽기 때문이다.EVula // talk // talk // 18:57, 2010년 12월 3일(UTC)[응답]

• aye 표준화는 좋으며 각주는 기사 텍스트보다 작아야 한다.아래의 기기는 작은 글꼴을 싫어하는 사람들에게 충분해야 한다.짐 밀러 ^{See me Touch me} 08:04, 2010년 12월 2일 (UTC)[응답]
  • 아래 기기는 나의 걱정을 다루지 않는다.김메투 (토크) 2010년 12월 2일 (UTC) 16:19[응답]
    • 우려를 좀 더 분명히 표현해 주시겠습니까?네가 왜 90%가 나쁘다고 생각하는지 너의 코멘트를 통해 알 수 없었어. — Edokter • Talk • 20:50, 2010년 12월 2일 (UTC)[응답]
• 끝없는 말다툼보다 표준화를 더 선호하기 때문에 지원하라.나는 아래 절에서 비슷한 문제를 제기한다.Tijfo098 (대화) 10:38, 2010년 12월 3일 (UTC)[응답하라]
• Aye - 표준화가 항상 최선인 것은 아니지만, 이 경우에는 그러하다.비욘드 마이 켄 (토크) 04:51, 2010년 12월 13일 (UTC)[응답]
• 지원 - 표준화는 거의 항상 최선의 경로다. - 버펠슨 AFB ✈ 14:34, 2010년 12월 13일 (UTC)[응답]

질문

사용자 지정 시각적 스타일을 선호하는 사람도 있는 것 같다(토크:줄리안 어산지#스크롤 박스 비주얼 스타일.이에 대한 가이드라인이 있는가?또 다른 이슈는 WP의 혼합이다.기사 본문에 있는 글과 함께 하는 LDR 형식의 인용문—여기서는 독자를 위한 시각적 차이는 없지만, 편집자를 위한 (조직적) 인용문은 있다.Tijfo098 (대화) 10:23, 2010년 12월 3일 (UTC)[응답하라]

나는 적어도 스크롤 문제가 MOS:SC롤에서 해결되었다고 본다.Tijfo098 (대화) 12:14, 2010년 12월 3일 (UTC)[응답하라]

정보봇 제안

나는 RC 피드를 감시하고 다양한 통계자료로 한 페이지를 적시에 업데이트 하는 봇을 제안한다.

내가 제안하는 통계는 다음과 같다.

• 이전 시간의 편집 수
• 이전 시간의 새 계정 수
• 이전 시간의 새 페이지 수
• 이전 시간의 역방향 편집 수("반달리즘")
• 되돌린 편집 비율
• 템플릿을 대체하기 위해 이상적으로 공공 기물 파손 정보의 표준화된 척도{{Vandalism information}}
• 업데이트 시점의 Hugle 사용자 수
• 이전 시간 동안의 평균 Hugle 사용자 수

이동 평균, 일 평균 등 더 많은 것.

나는 이것이 우리에게 풍부한 정보를 줄 것이라고 믿는다. 우리는 이것을 예시로 삼아 서버 로딩 시간을 일주일 동안 시간당으로 보여주는 그래프를 만들 수 있다.

지역사회가 그런 봇에 관심을 가지고 있으며, 어떤 개선사항과 통계를 더 제안하는가?930913 (축하/불만) 09:53, 2010년 12월 1일 (UTC)[응답]

개인적으로 나는 그것이 유용하고 흥미롭다고 생각하지만 일부는 그것이 필요하다고 주장할지도 모른다. --쿠미오코 (토크) 21:29, 2010년 12월 1일 (UTC)[응답]

타인의 불가피한 외침을 사전에 차단하기 위해 반달들을 무장시키지 말자. - 재리1250^{[Who? Discuss.]} 22:11, 2010년 12월 1일 (UTC)[응답]

단순한 숫자로 야수를 어떻게 풀어낼지 모르겠다. --쿠미오코(토크) 22:19, 2010년 12월 1일 (UTC)[응답하라]

• 나한테는 비교적 의미 없는 편집들이 많은 것 같아.기껏해야 현재 RPM으로 매 4시간/6시간마다 {{wdefcon} 봇 업데이트를 할 수 있을 것이다.반달리즘 정보에는 항상 통계를 나열하는 봇이 필요하지 않다... / /ETECCOMMS/04:05, 2010년 12월 2일 (UTC)[응답]
  • 난 공공 기물 파손자 명단을 작성했어 왜냐면 난 주로 기물 파괴자 싸움에 관심이 있거든지역사회가 원하는 대로 많은 다른 통계들이 포함될 것이다.둘째로, RPM은 반비례적인 반달리즘 반달리즘 반달리즘이다.930913 (축하/불만) 08:15, 2010년 12월 2일 (UTC)[응답]
    • 때때로 나는 온라인상의 유일한 AV가 될 것이고, 카운터가 7RPM이라고만 말함에도 불구하고 매우 빠르게 되돌아갈 것이기 때문에 Huggle 사용자의 수가 더 좋다.다른 때에 나는 웨인 슬램/액세스 거부와 같은 사람들과 온라인에 접속해서 가끔씩만 되돌아갈 것이고 카운터는 16RPM이라고 말한다.그러나 우리는 반달들이 허글 사용자들이 없는 시간을 찾아보는 것을 원하지 않는다.리퍼 이터널(토크) 03:04, 2010년 12월 4일 (UTC)[응답]

일부 피드백 요청

분명히 하자 - 지난 12개월 동안 어떤 제안이 성공적이었는지 어떻게 피드백을 받을 수 있을까?위키피디아의 이러한 특징이 유용한 기능을 제공한다고 생각하면 좋을 것이다.ACEOREVIVEED (토크) 2010년 12월 2일 (UTC) 19:28 [응답]

제안 정책이나 원하는 것을 만들기 위해 RfC를 시작하시겠습니까?이 제안서는 무엇인가? / /ETECCOMMS/01:24, 2010년 12월 3일 (UTC)[응답]

누군가 VPR/Idea Lab 아카이브를 통해 결과를 요약할 것을 제안하는가?흥미롭겠지만, 열심히 일해야죠.Rd232 12:00, 2010년 12월 3일(UTC)[응답]

상태

상태를 업데이트할 수 있는 기능을 원하십니까?Online,Offline다른 편집자가 볼 수 있도록 , 또는 심지어 )?그리고 기여를 방해하지 않고 그렇게 하는 것은 어떨까?

일반적인 코멘트는 여기서 응답하십시오.기능의 배포에 직접적인 영향을 미치는 코멘트는 토론에 참여하거나 Bugzilla:26246에서 직접 참여하십시오.고마워!레흐만 00:54, 2010년 12월 4일 (UTC)[응답]

가젯 제안:노 스몰폰츠

위의 논의에 의해 촉발되어 EVula가 제안하고 "글꼴이 너무 작다!" 때문에 항상 개체가 바뀌는 요소와 페이지 설계에 관한 과거의 논의에 의해 촉발된 나는 작은 글꼴을 혐오하는 이들에게 원클릭 솔루션을 제공하는 기기를 제안한다.기본적으로 Navbox, infobox 및 참조 목록과 같은 요소의 글꼴 크기를 100%로 재설정한다.내가 몇 가지를 잊어버릴 수밖에 없기 때문에 그 명단은 연장될 수 있다.이것은 작은 글꼴에 문제가 있는 사용자의 가독성에 도움이 될 것이다.

코드는 여기 있다: MediaWiki:가젯-NoSmallFonts / MediaWiki:가젯-NoSmallFonts.css.테스트 드라이브를 원하는 사람들은 단순히 CSS 코드를 그들의 벡터.css 파일에 복사할 수 있다. — Edokter • Talk • 2010년 12월 1일 (UTC)[응답]

이의제기를 포함한 어떠한 반응도 보이지 않기 때문에, 나는 그냥 이 기기를 사용할 것이다.그 암호는 페일 세이프인데 나는 그것이 시력 장애가 있는 사람들에게 도움이 될 것이라고 생각한다. — Edokter • Talk • 21:38, 2010년 12월 1일 (UTC)[응답]

강력히 지지하다.이제 Gadgets(가젯) → Infoboxes(인포박스), Navboxes(내보박스) 및 Reference(참조) 목록과 같은 요소의 작은 글꼴 크기 사용 안 함. -- - - - Gadget850(에드) 15:51, 2010년 12월 2일(UTC)[응답]

정반대의 문제도 있다.많은 사람들이 작은 코드를 가지고 작은 캡을 만들려고 하지만 이것은 작동하지 않는다.예: 화학 이름.--Wickey-nl (대화) 17:35, 2010년 12월 3일 (UTC)[응답]

{{smallcaps} 템플리트를 사용하여 적절한 스타일링을 사용해야 한다. — Edokter • Talk • 18:09, 2010년 12월 3일 (UTC)[응답]

[즉, 작은 모자 스타일링]에 필요한 것은?그리고 <작은 것>은 또 어떤 용어로 쓰이고 있는가?봇이 이걸 식별/수정할 수 있을까?Rd232 18:13, 2010년 12월 3일 (UTC)[응답]

그것은 템플릿 설명서에 부분적으로 설명되어 있다.주로 인용문의 저자 이름에 사용되며, 기술 텍스트에 유용할 때도 있다.그러나 <작은 것>의 사용은 내 소견으로는 불로 죽여야 한다. — Edokter • Talk • 18:25, 2010년 12월 3일 (UTC)[응답]

나는 위키피디아에서 작은 대문자를 본 적이 없다.단지 템플릿의 창작자에 대한 이론일 뿐일까, 아니면 실제로 이런 식으로 어디선가 사용되고 있는 것일까?—Emil J. 18:36, 2010년 12월 3일 (UTC)[응답]

꽤 많은 기사들은 저자 이름이 작은 캡으로 장식된 참조 목록을 사용한다.[3] Brassicales(예: --)를 참조하십시오. ---- Gadget850(Ed) 18:47, 2010년 12월 3일(UTC)[응답]

Special을 사용할 줄 안다.WhatLinksHere.중요한 것은, 내가 시도했던 목록의 맨 위에 있는 기사들은 인용에 작은 모자를 사용하지 않고, 사실 작은 모자를 전혀 사용하지 않고, 단지 다른, 임시적인 목적으로 사용되는 지역별 유럽의 수도 목록{{List of European capitals}을 그냥 초월한다는 것이다.—Emil J. 18:54, 2010년 12월 3일 (UTC)[응답]

작은 모자는 화학 명칭의 일부분이다(Chirality_(화학) 참조).#By_configuration:_D-_and_L-; 특히 머리글의 편집자 시도 참조).그것은 아직 WP에서는 거의 적용되지 않는다. 왜냐하면 거의 아무도 스몰캡스 템플릿을 모르기 때문이다.스몰캡 편집 버튼이 가능한가?--Wickey-nl (토크) 10:45, 2010년 12월 4일 (UTC)[응답]

페이지 기록에 외부 도구를 추가하기 위한 새로운 페이지 기록 통계 도구

페이지 기록 통계에 대한 상세 그래픽과 통계 보기를 볼 수 있는 toolserver.org의 새로운 도구가 있다.이것은 역사 페이지의 외부 도구들 중 하나일 뿐이다.누군가가 해당 섹션에 도구를 추가하거나 해당 기능이 있는 기술 팀에 문의하십시오.

여기에서 위키백과의 페이지 기록 통계를 볼 수 있다.빌리지_pump_(proposal): http://toolserver.org/~soxred93/generinfo/index.php?기사=Wikipedia%3AVillage_pump_%28proposals%29&lang=en&wiki=wikipedia&begin=&end=&end=&end=&end=

나만 그런가, 아니면 이 페이지의 판독이 7개월 전에 멈춘 것처럼 보이나? - Jarry1250^{[Who? Discuss.]} 11:03, 2010년 12월 4일 (UTC)[응답]

기본적으로 이 도구는 이 페이지가 2010년 4월 20일 14:02:46에 도달한 맨 위에 표시되는 메시지처럼 처음 5만 편집에 대한 통계만 보여준다.이후 편집에 대한 통계는 2010년 4월 20일, 14:02:47을 시작일로 입력하여 볼 수 있다.
http://toolserver.org/~soxred93/기사info/index.php?기사=%09Wikipedia%3AVillage+pump+%28proposals%29&lang=en&wiki=wikipedia&begin=20+2010%2C+14%3A02%3A47&end=
가장 최근에 편집한 시간을 시작 날짜 없이 종료 날짜로 입력하려고 했지만 도구가 오류를 반환했다. - 로고스111 (토크) 00:13, 2010년 12월 6일 (UTC)[응답]

A급 템플릿

템플릿과 같은 A급 기사를 위한 템플릿을 제안한다.좋은 기사 및 템플릿:특집 기사.A급 기사가 GA를 넘어섰고 그럴 만한 가치가 있는 기사인데, 왜 없는 건지 모르겠네.존경?좋아, 이렇게 한 장 생각하고 있었어CrozRSA 19:59, 2010년 12월 5일 (UTC)[응답]

이것은 이전에도 여러 차례 제안된 바 있다.일반적인 장애물은 A-Class가 프로젝트 전반에 걸쳐 사용되지 않기 때문에(실제로 이를 활용하는 몇 안 되는 프로젝트 중에서 매우 적게 사용됨) 따라서 실질적인 표준이 없다는 것이다.개인적으로, 나는 우리가 A-Class를 어떻게 할 것인가에 대해 사이트 전체에서 또 한번 토론할 때가 되었다고 생각한다.나는 본래 그 아이콘을 보여주는 것에 반대하지 않지만, 그렇게 많은 기사가 실제로 A-클래스 등급을 받을 가능성을 결코 갖지 못할 때 그것을 하는 것이 오히려 혼란스러워 보인다. --Dorsal Axe 20:03, 2010년 12월 5일 (UTC)[응답]

현실적으로 A급이 널리 쓰이는 것은 군사사업뿐일 것이다.그것은 위키피디아의 제국주의적 측정에 상당하는 것이다 - 그것은 여전히 그것을 사용하는 소수의 보류자들로 인해 대부분 고갈되어 있다.2010년 12월 5일 결연한 20:21 (UTC)[응답]

그래. 광고보다 A클래스를 더 부정하는 게 좋을 것 같아.펜스&윈도우 23:28, 2010년 12월 5일 (UTC)[응답]

그것은 훌륭한 제안으로 들리는데, 즉 WPMILHIST가 그 메트로링크에 약간 적대적일 것이라는 점을 제외하면, 사다드 (대화) 02:28, 2010년 12월 6일 (UTC)[응답]

그들과 누구의 군대?펜스&윈도우즈 00:39, 2010년 12월 8일 (UTC)[응답]

편집 요약에 배치될 때 템플릿 링크 생성 및 템플릿에 대한 Wikilink 만들기

그래서 나는 편집자들이 템플릿을 추가하거나 제거할 때 일반적으로 "템플릿:아무거나."종종 스페이스 태깅(스텁 카테고리 채우기 또는 Wiki Project용)을 진행했을 때, 나는 단순히 템플릿 코드를 기사에 붙여넣은 다음 요약에 붙여넣을 것이다.거의 모든 편집자가 "{Disney-videogame-stub}}" 편집 요약은 기사가 해당 템플릿으로 태그되었다는 것을 의미한다는 것을 알게 될 것이다.어떤 이유에서인지 나는 항상 이것이 일반 링크에서 가능한 것처럼 요약에 위키링크를 만들어냈다고 추측했지만, 나는 단지 이것이 사실이 아니라는 것을 깨달았다.

구체적으로 말하면, 편집 요약의 템플릿 링크를 해당 템플릿에 대한 위키링크로 취급할 것을 제안한다.그래서 "{Disney-videogame-stub}}"은 "{Disney-videogame-stub}}"로 표시된다.분명히 얻을 수 있는 큰 혜택은 없으며, 그것은 단지 독서 이력과 시계 목록을 더 유익하게 만들 것이다.사소한 소프트웨어 변경이어야 하는데, 지역사회의 지원이 있는지 알고 싶었어.고마워! ★ 조니미르닌자 07:24, 2010년 12월 7일 (UTC)[응답]

그것은 "rv"와 "역전"과 같은 단축키와 약어 그리고 키워드를 자동 링크하는 것과 마찬가지로 좋을 것이다.우리는 더 많은 새로운 사람을 원한다!이것은 분명히 전에 논의된 적이 있고 나는 심지어 버질라 벌레가 있을지도 모른다고 생각한다 - 누가 이전의 논의를 찾을 수 있을까?Rd232^talk 09:01, 2010년 12월 7일 (UTC)[응답]

WP에 문의:VPT. 내 기억이 정확하다면, 편집 요약 상자는 MediaWiki에 의해 다른 방식으로 파싱되므로 기술적으로 어려운 일이거나 그렇지 않을 수 있다.Titoxd^{(?!? - cool stuff)} 10:31, 2010년 12월 7일 (UTC)[응답]

물품에 곱슬곱슬한 인용 부호를 허용하는 제안

WT:를 참조하십시오.MOS#Quotation mark glyph graw poller.A. di M. (토크) 11:59, 2010년 12월 7일 (UTC) 고정 링크. --Stephan Schulz (토크) 12:16, 2010년 12월 7일 (UTC)[응답]

위키백과 문서별 변동성 지수

다음은 새로운 위키백과 기능에 대한 제안이다. 특히, 각 글의 머리글에 내장된 각 글에 대한 변동성 지수:

우리 모두가 알고 있듯이, 위키피디아를 둘러싼 대중적인 불만/긴장은 그것의 정확성/신뢰성이었다.이러한 오명은 일반적으로 나이든 세대(웹 2.0 이전에 성장한 세대)가 온라인 커뮤니티, 특히 위키백과 독자와 기고자의 커뮤니티와 같은 큰 커뮤니티에서 자기 포기의 속도와 효과를 불신하기 때문이다.내가 여기서 제안하는 특징에 대한 나의 희망은 위키백과 기사의 살아있는 본성을 활용하여 기성세대의 공포를 완화시키는 메커니즘을 제시하는 것이다.

내가 이 신뢰성/정확성 문제에 대해 제안하는 접근방식은 우선 우리가 어떤 한 순간에 어떤 기사의 정확성을 100% 확신할 수 없다는 것을 받아들이도록 요구한다(Wikipedia 또는 그 외의 경우), 그러나 위키피디아의 경우, 우리가 할 수 있는 것은 특정 순간에 특정 기사를 신뢰하는 데 수반되는 위험에 대해 정말로 좋은 아이디어를 얻는 것이다, 따라서.위키피디아 사용에 대한 전반적인 대중의 불안감을 대폭 줄였다.

접근방법은 다음과 같다: 각 위키백과 기사의 상단 오른쪽, 즉 몇 일 또는 몇 개월 또는 몇 년에 걸쳐 시간당(또는 분 또는 일) 기사에 대한 변경(편집) 수를 나타내는 작은 그래프를 표시하면 투자자가 1-h를 보고자 할 수 있듯이 사용자는 이러한 시간 프레임 중 관심 있는 것을 클릭할 수 있어야 한다.1일, 1주 또는 10년 간의 그래프에 관심 있는 주식 가격을 표시하십시오.

이 기능이 어떻게 작동하는지 보여 주는 예는 다음과 같다.회의적인 사용자가 새로운 주제에 대해 스스로 교육하기를 원하기 때문에 위키피디아를 검색하여 적절한 기사를 찾아낸다고 상상해보자.다음으로, 우리 사용자가 연구 중인 주제가 최근에 인기를 끌었고, 따라서 이 기사는 현재 "읽기 전용"과 "편집" 트래픽 모두에서 높은 수치를 보이고 있다고 상상해 보십시오.사용자가 기사/웹페이지에 도착하고, 화면 오른쪽 상단에 지난 달(또는 주 또는 요일 또는 시간) 동안 이 기사에 대한 변경 횟수를 보여주는 작은 그래프가 있다. 즉, x축은 시간, 일(또는 시간 또는 분)이고 y축은 변경 횟수다.사용자는 위에서 언급한 바와 같이 브로커의 웹사이트에 있는 주가 정보를 가지고 그래프를 확대/축소할 수 있는 옵션이 있다고 본다.

위키피디아(또는 http://stats.grok.se/),)가 실시간으로 최신 정보를 제공하는 이 그래프를 통해 사용자는 주식 거래자가 VIX(http://en.wikipedia.org/wiki/VIX))와 같은 지수를 사용하여 시장의 변동성을 보는 것처럼 자신이 보고 있는 기사의 현재와 과거의 변동성을 한눈에 볼 수 있다.위키백과 기사의 높은 변동성(단위시간당 현재의 변동폭이나 변동폭)은 독자에게 (주식시장을 병렬적으로 지속하기 위해) 현재 변동성이 있거나 불안정한 상태며, 이 시점에서 기사(예: 학교신문)에 나타나는 정보를 이용하는 것은 위키백과 캐스에 더 많은 위험(불확실성의 위험)을 수반한다는 것을 알려준다.e. 높은 위험(시간 당 높은 변화)은 기사의 주제가 발전하는 상황이기 때문일 수도 있고, 논쟁적이고 반대되는 관점이 편집 전쟁 중에 있기 때문일 수도 있다.요점은, 이제 독자는 글의 현재 내용을 빠르게 변화시킬 것 같은 일이 벌어지고 있다는 것을 한눈에 알 수 있는 방법이 생겼다는 것이다.사용자는 나중에 다시 확인하기로 결정하거나, 즉 시간당 변경사항이 기사를 감시해 온 모든 잠재적 편집자들 사이에서 더 높은 합의를 나타내는 수준으로 정착될 때까지 기사 정보를 사용하지 않기로 결정하는 등의 선택을 할 수 있다(오류 위험 감소).

만약 한 단계 더 나아가고 싶다면 이동 평균은 보여질 수 있고 심지어 사용자에 의해 조작될 수 있다(예: 30일 또는 180일). 그리고 교사들은 예를 들어 시간당 현재 시간당 기사의 변화가 그들이 선택한 이동 평균보다 낮거나 낮지 않는 한, 기사를 사용하지 말라고 학생들에게 조언할 수 있다.실제 사용된 숫자는 원하는 위험 수준에 따라 사용자(또는 그의 교사)가 조정할 수 있다.

그러나 한 단계 더 나아가서는 기사의 신뢰성을 설명하는 더 나은 방법을 결정하는 것이 될 것이다. 즉, 시간당 편집이나 시간당 편집의 변화 대신 (편집/뷰)/시간과 같은 공식은 더 신뢰할 수 있는 것으로 판명될 것이다. 관심 있는 통계학자와 계량학자에게 맡기겠다.

요약하자면, 위키피디아에서는 모든 사람들이 위험을 알고 있다.그들을 홍보 문제로 취급하는 것은 실수일 것이다.위험을 계량화하고 대중에게 쉽게 협력할 수 있는 방법을 제공하는 것은 위키피디아에 대한 일반 대중의 신뢰도를 높여야 한다.

--알도비엘라 (대화) 02:10, 2010년 12월 8일 (UTC)[응답]

위키트러스트라고 들어보셨나요? --사이버코브라(토크) 02:33, 2010년 12월 8일 (UTC)[응답하라]

• 위키 트러스트가 더 나은 해결책이다.당신이 제안한 조치인 알도비엘라(Aldobiella)의 구체적인 문제점은 위키피디아에서 가장 터무니없이 잘못된 페이지가 오래전에 만들어졌고 오랫동안 탐지되지 않고 편집되어 왔기 때문에 어떤 식으로든 정확하지 않고 "매우 안정적"으로 등록된다는 것이다.편집자의 교정에 근거하여 기사를 평가하는 시스템(위키 트러스트와 같은 시스템)은 일반적으로 더 좋다 - 페이지를 거짓으로 정확하지 않고 부정확한 것으로 반환할 가능성이 더 높으며, 이것은 또한 플러스다. - 더스트폼스워즈 (talk) 02:40, 2010년 12월 8일 (UTC)[응답]

WT의 가치는 언뜻 보기에 별로 보이지 않는다.기고자에 근거하여 자료를 평가하고, 다른 사람이 기고자의 의견에 동의하는 경향이 있는지 여부에 근거하여 기고자를 평가한다.그것은 "합의"와 같은 결과를 줄 것 같다.피터 잭슨 (토크) 2010년 12월 9일 (UTC) 18:01 [응답)

세 번째 탭: 사람들이 신뢰성을 판단하는 데 도움이 되는 통계 페이지

기사 상단에 변동성 지표를 추가하는 것은 좋지 않을 수 있지만, 편집자와 기사의 신뢰성에 대한 판단을 위해 편집자와 보고자 하는 사람들이 그러한 도구를 이용할 수 있도록 하는 것이 유용하다.

그렇기 때문에 나는 통계, 기사 통계, 변동성 또는 이와 유사한 용어로 명명할 수 있는 제3의 탭을 기사 편집 통계를 볼 수 있는 제3의 탭을 추가해야 한다고 제안한다.

이러한 통계 뷰어를 만드는 데 도움이 되는 도구를 사용할 수 있다.

기사 역사 통계 도구를 통해 영어 위키백과에서 "위키피디아" 기사의 역사 통계를 볼 수 있다: http://toolserver.org/~soxred93/generinfo/index.php?기사=위키피디아

세 번째 탭의 통계 페이지는 대중이 위키백과의 기사와 정보의 신뢰성을 판단하는 데 도움을 주기 위한 것으로, 위키백과의 사용성, 신뢰성 및 투명성을 향상시키기 위한 자연스러운 단계처럼 보인다.그것은 그것이 사용자 생성 콘텐츠의 무료 백과사전에서 신뢰할 수 있는 정보를 제공하는 임무를 수행하도록 허용할 것이다.그리고 그것의 창조의 기초는 이미 갖춰져 있는 것 같다.그리고 세번째 탭으로서, 그것은 토론 탭보다 더 이상 기사를 무심코 읽는 데 방해가 되지 않을 것 같다.보람 있고 보람 있는 발걸음이 될 것 같다.

기사 기록 통계 도구는 기사 개정 페이지의 외부 도구에도 추가되어야 하며, 이는 탭과 달리 편집자에게 더 적합한 것으로, 독자와 대중에게 기사 신뢰성과 주의 행사에 대해 더 잘 알려준다.λόγο idea 아이디어 → ✉ 19:10, 2010년 12월 9일 (UTC)[응답]

• 반대 - 변동성에 대한 이전의 토론을 읽었음에도 불구하고, 나는 이것이 어떤 편집자에게 어떤 이익을 가져다 줄 것인지, 또는 기사의 역사 페이지를 주의 깊게 읽었을 때 그것이 실질적으로 어떻게 개선될 것인지 확실히 알지 못한다.당신이 제안하는 것은 캐주얼한 시청자들에게는 볼 수도 없고 찾을 수도 없는 것으로, 경험이 풍부한 편집자들이 기존의 도구를 통해 이미 접근할 수 있는 정보를 제공한다.게다가, 그것은 어느 페이지 반달리즘이 감지될 것 같지 않은 페이지 반달리즘에 대한 단서를 제공한다는 점에서, 우리가 얼마나 많은 사람들이 특정 한계 이하의 페이지를 보고 있는지 보여주지 않는 많은 같은 이유들로 반칙된다. - 더스트폼스워즈 (talk) 05:22, 2010년 12월 10일 (UTC)[응답]

• 게다가 위키피디아 기사의 정확성을 판단하는 가장 좋은 방법은 단순히 정보를 읽고, 출처가 신뢰할 수 있는지에 대해 스스로 현명한 판단을 내리는 데 필요한 기술을 갖추는 것이다.나는 알고리즘과 측정 기준을 사용하여 사람들이 스스로 이러한 중요한 기술을 개발하는 것을 피하도록 하는 방법에 대해 철학적으로 회의적이다.즉, 적어도 우리가 훨씬 더 나은 알고리즘과 지표를 얻을 때까지는 말이다. - 더스트폼스워즈 (대화) 05:25, 2010년 12월 10일 (UTC)[응답]

• 연결된 도구에 대한 통계가 신뢰성과 어떤 상관관계를 가지고 있는가?편집량이 많거나 편집 빈도가 높은 기사가 더 신뢰성이 있다고 주장할 수도 있겠지만, 특히 '신뢰성'은 양적 속성이 아니기 때문에 약한 관계가 될 가능성이 높다.위키러스트는 누가 편집을 했는지를 고려하기 때문에 더 좋지만, 더 중요한 것은 문장 수준에서 작동한다는 것이다.기사가 커질수록 각 편집이 영향을 미치는 글의 양이 줄어들기 때문에 편집 때마다 전체적으로 글의 신뢰성이 향상된다는 생각은 정확하지 않게 된다.미스터 Z맨 05:46, 2010년 12월 10일 (UTC)[응답]

"White 위키백과에서 무료 백과사전" - 기사 제목 아래 암호화 텍스트

여기 스크린샷.맨 위 왼쪽 모서리에 이미 같은 메시지/문자가 있다('퍼즐' 벌룬 아래).그래서 우리가 불필요한/반복적인 것들을 없애면 좋지 않을까?어쨌든 더 깨끗한/간단한 범위/인터페이스가 더 낫다.Userpd (대화) 2010년 11월 26일 19:12, (UTC)[응답]

About Mirror 사이트는 로고를 가지고 있지 않으며, 기사 상단에 있는 "From Wikipedia" 메시지만 복사한다. : TelCoNaSpVe : 19:33, 2010년 11월 26일 (UTC)[응답]

거울 사이트 같은 거?위키피디아를 한번 가본 사람은 무료라는 것을 읽었을 것이다/알고 있다, 왜 기사 내용과 관련이 없는 너무 많은 텍스트들이 그것을 너무 관료적으로 꽉 채울 뿐이다.게다가 여전히 대다수는 위키백과의 내용을 미러링하기로 결정한 일부 사람들로부터가 아니라 위키백과 자체에서 읽을 것이다.어쨌든 위키피디아에서 내용을 복사하려는 사람들은 어쨌든 내용과 함께 이 메시지를 복사하지 않을 것이기 때문에, 기사의 페이지에서 반복적으로 언급하는 것은 부적절하다.인구밀집형 프로젝트니까 최대한 간단하게 하는 게 좋을 것 같아.Userpd (대화) 22:28, 2010년 11월 26일 (UTC)[응답]

위키백과 읽기:미러와 포크는 그러한 웹사이트에 대해 알려준다.그들은 때때로 로고나 문구를 포함하지 않지만, 다른 하나는 유지한다. : TelCoNaSpVe : 23:14, 2010년 11월 28일 (UTC)[응답]

그들이 또한 그것을 제거할 수 있다면, 그 문구를 가지고 있는 이유가 무엇인가?내가 만나는 모든 미러 사이트들은 WP를 모방하기 위해 그들이 할 수 있는 모든 것이라고 믿었다. -- 도! 00:06, 2010년 11월 29일 (UTC)[응답]

• 지원 - 도! 00:06, 2010년 11월 29일 (UTC)[응답]
• 반대: 로고는 CSS를 기리는 인쇄본에서 생략된다. 이러한 경우 기준선은 귀속성을 제공한다.또, 나를 향수를 불러일으킨다고 불러 :) --사이버코브라 (토크) 02:46, 2010년 11월 29일 (UTC)[응답]

동일한 CSS 규칙을 사용하면 페이지가 인쇄될 때까지 문구를 숨길 수 있다.CSS 규칙이 '존경'되지 않으면 로고가 대신 그곳에 있게 된다. -- '오! 03:13, 2010년 11월 29일 (UTC)[응답]

그러면 그것을 인쇄된 버전의 기사 끝에 놓는 것이 요령이다.Userpd (대화) 03:51, 2010년 11월 29일 (UTC)[응답]

나는 종종 텍스트 전용 브라우저로 위키피디아를 찾아본다.로고는 거기엔 내게 나타나지 않아. --카닐도(토크) 02:14, 2010년 11월 30일 (UTC)[응답하라]

• 지원 불필요한 텍스트 없음.--Wickey-nl (대화) 15:03, 2010년 11월 30일 (UTC)[응답]
• 지원, 미러 사이트 "문제"를 해결하기 위한 기술 해결책이 얼마든지 있다.한편, 우리는 가능한 한 유용하고 정돈되지 않은 우리만의 인터페이스를 만들어야 한다.--코트니스키 (토크) 16:49, 2010년 11월 30일 (UTC)[응답]
• 반대 이 태그 라인은 독자들이 이 글의 출처를 알 수 있도록 돕는다.사용하다#siteSub { display:none; }그렇게 신경 쓰이시다면..Anomie⚔ 18:40, 2010년 11월 30일 (UTC)[응답]

나는 왼쪽에 있는 큰 위키피디아 로고가 독자들에게 그들이 어디에 있는지 알려 줄 것이라고 생각한다.거울의 관점에서 보면, 내가 아는 모든 거울은 문구를 삭제했지만, 여전히 페이지 하단에 있는 위키피디아를 탓하고 있다.게다가, 그 CSS는 상위 아이콘들의 정렬을 잘못되게 한다. -- 도!_[talk] 23:44, 2010년 11월 30일 (UTC)[응답]

그리고 다른 방법으로 제거해도 같은 방식으로 상단 아이콘이 잘못 정렬되지 않는가?"제거"가 "미디어위키 편집:Vector.css에서 설정 중지display:inline에 관하여#siteSub", 피부에서 CSS를 사용하는 것과 거의 동등한 것은?Anomie december 00:57, 2010년 12월 1일 (UTC)[응답]

분명히 우리는 개인적으로 그것을 가지고 원하는 것은 무엇이든 할 수 있다(그만큼 원한다면 태그라인을 다시 붙이는 데 자바를 사용할 수 있다고 나는 똑같이 주장할 수 있다) 그러나 그것은 우리가 그러한 선택권이 없는 수백만 독자들에게 어떻게 페이지를 제시하느냐 하는 문제다.몇 센티미터 이내에서 같은 증기성 발언을 두 번 하는 이유는 무엇인가? --Kotniski (토크) 07:00, 2010년 12월 1일 (UTC)[응답]

오, 그게 훨씬 낫군.우리가 그것을 선호할 수 있는가, 아니면 그것을 조언하는 도움말 페이지가 있는가? --Bsher (대화) 17:29, 2010년 12월 8일 (UTC)[응답]

신경 쓰지 마, 효과가 없어.제목 오른쪽의 아이콘 위치에 더 큰 영향을 미친다. --Bsherr (talk) 18:04, 2010년 12월 8일 (UTC)[응답

• 무관심 나는 사실 어느 쪽이든 그것에 대해 문제를 가지고 있지 않다; 그것은 약간 중복된다, 물론, 하지만 이미지의 텍스트와 페이지의 실제 텍스트 사이에는 (기술적인 수준에서) 차이가 있다.스크린-미디어 CSS(인쇄-미디어 CSS에서도 볼 수 있음)에 숨겨도 괜찮을 것 같다.EVula // talk // talk // 20:13, 2010년 11월 30일 (UTC)[응답]
• 지원 그것은 그곳에 오래 있었고 나는 그것을 더 이상 볼 수 없지만, 그것은 기사 내용에 더 잘 바쳐지는 약간의 공간이다.거울이 많으면 태그도 많이 제거되고, 물론 태그 자체만으로는 라이선스 준수를 보장할 수 없기 때문에 미러 문제가 내게는 큰 요인이 되지 않는다.Dcoetzee 01:47, 2010년 12월 1일 (UTC)[응답]
• 반대 - 모든 페이지에 핵심 단어가 직접 쓰여지는 것은 아니기 때문에, 그것을 제거하면 우리의 SEO가 줄어들 것이다.또한, 그들은 아무것도 해치지 않는다.Ajraddatz (토크) 19:17, 2010년 12월 1일 (UTC)[응답]

CSS(제거되지 않음)를 사용하여 숨겨진 문구로 크롤러와 다른 봇에 대한 문구가 나타날 것이므로 SEO 문제는 없다. -- 도! 00:52, 2010년 12월 4일 (UTC)[응답]

• 약한 반대 또는 중립 - 어느 쪽이든 크게 소란스럽지 않으며 지켜야 할 주장은 약간 더 강하다.에 대해 주어진 .css 코드는 필요한 경우 유용한 선택이다.캐스리버 (토크 · 기여) 20:43, 2010년 12월 1일 (UTC)[응답]
• 반대야, 우리 브랜딩에 문제될 거 없어본문은 기사에 없고, 재이용자의 권리에 간섭하지 않는다. -- ۩ 마스크 02:16, 2010년 12월 12일 (UTC)[응답]

프로젝트 이름이 잘못 지정됨:()

너의 백과사전의 이름이 잘못되었다는 것을 알려드리게 되어 유감이다.접미사 -pedia 앞의 부분은 백과사전의 화두가 되는 것이지, 백과사전이 만들어지는 방식이 아니다.예를 들어, 메드페디아는 의학정보에 관한 것이고, 와우페디아는 WoW에 관한 것이고, 컨버지피디아는 보수당의 횡설수설, 베이비네임스페디아는 아기 이름에 관한 것이다.특별히 백과사전은 접두사 백과사전을 제외한 모든 경우에 접미사가 암시하는 위키라고 말할 필요는 없다 —서명되지 않은 코멘트를 142.244.236.20 (대화) 01:06, 2010년 12월 5일 (UTC)[응답]

위키피디아는 그 모든것보다 앞서있다."-pedia"는 위키백과가 아니었다면 위키백과를 의미하지 않았을 것이다.미스터Z맨 02:09, 2010년 12월 5일 (UTC)[응답]

그가 한 말.또한 위키피디아는 분명히 위키백과사전이라는 단어를 간단히 수정한 것이다.Ajraddatz (토크) 23:37, 2010년 12월 5일 (UTC)[응답]

우리는 142.244라는 불완전한 세계에 살고 있다.위키백과 호텔의 위키백과로 가는 위키백과 셔틀을 탈 때 작은 일에 진땀을 흘리지 않도록 하라.–Whitehors1 23:41, 2010년 12월 5일 (UTC)[응답]

위키피디아는 명사가 아닌 고유명사이기 때문에, 우리는 분명히 그것을 무엇이라고 부를 것인가에 대해 합리적으로 자유롭게 생각할 수 있다.어쨌든, 1997년 초에 누피디아가 있었다. 나는 그것이 누스에 관한 것이 아니라고 확신한다.사실, 위키피디아의 일부 정보는 위키에 관한 것이다. 예를 들어 우리는 위키에 관한 기사를 가지고 있다.ACEOREVIBED(대화)

위키백과가 위키백과사전이 아니라면 위키백과사전을 뭐라고 부를 것인가?(답변:위키인덱스).Dcoetzee 18:38, 2010년 12월 11일 (UTC)[응답]

기본 페이지 거부권

위키백과에 오신 것을 환영합니다라는 제목의 메인 페이지에는 위키리크스와 연관되어 있지 않다는 명백한 부인으로 한정된 기간 동안 어떠세요?이것에 대한 혼란은 널리 퍼진 것 같다.86.184.239.37 (대화) 20:55, 2010년 12월 7일 (UTC)[응답]

"우린 위키리크스와는 관련이 없지만, 그것들에 대한 백과사전 기사가 있어."?꽤 광범위한 혼란인 것 같다. 현재의 표지판 기능을 보라.상황이 이렇다 보니 메인 페이지 노트가 과민반응인지 확실치 않지만, 그런 일이 일어나는 것은 보이지 않는다.Rd232^talk 21:42, 2010년 12월 7일 (UTC)[응답]

요전 날 라디오 2에서 그들은 토크쇼를 열었고 한 사람이 "잘한 위키백과"라고 이메일을 보냈다.이건 분명히 이상한 문제야. 페이스팜 --Errgent^(chat!) 22:01, 2010년 12월 7일 (UTC)[응답]

그것은 더 큰 문제의 증상으로서, 일반 대중이 "위키"를 듣고 "위키피디아"를 생각한다는 생각이다.위키리크스 비즈니스는 가장 최근의 에피소드지만, 그것이 처음이 아니며 마지막이 아닐 것이다.나는 재단이 그것을 교육하고 불식시키기 위해 더 많은 노력을 하는 것을 보고 싶다.그렇긴 하지만, 나는 개인적으로 메인페이지의 공지사항이나, 아니면 시테노티스가 될 수도 있다는 것에 동의하지만, 나는 솔직히 그와 같은 어떤 것이든 합의를 얻을 수 있을지 의심스럽다.--Fyre2387^{(talk • contribs)} 22:49, 2010년 12월 7일 (UTC)[응답]

메인 페이지 통지는 단순히 문제 밖이다.그런 일은 절대 일어나지 않을 것이다.

사이트 전체에 걸친 통지는 가능하지만, 나는 단지 여러 가지 이유로 그것이 일어나는 것을 볼 수 없다.그래도 투자할 만한 가치가 있는 가능성이다.이것들은 결국 독특한 환경이다.또한 실제 위키리크스 기사에 대한 면책 조항이 있다는 점에 유의하십시오. --Dorsal액스 23:05, 2010년 12월 7일 (UTC)[응답]

그리고 그것조차 논쟁의 여지가 있는 것 같다. --사이버코브라(토크) 02:24, 2010년 12월 8일 (UTC)[응답]

나는 사이트 전체의 통지에 동의할 것이다.메인 페이지는 실행 가능한 선택사항이지만 수정사항에 대한 합의를 얻는데 너무 오랜 시간이 걸린다.지금 우리는 빠른 무언가가 필요하고 그 메시지는 모든 페이지에 걸쳐 보여진다.더 많은 정보를 모르는 일반 대중들이 위키백과 = 위키리크스를 잘못 믿기 전에 상황을 바로잡자.오하나^{Talk page} 유나이티드 2010년 12월 9일(UTC) 15:25[응답]

발견자를 위한 메시지(모든 페이지 위, 클릭으로 제거할 수 있는)와 같은 메시지는 정보 제공, 모호하지 않아야 하며(다른 옵션과 비교했을 때), 생성하기 쉬워야 한다(이미 존재하는 메시지(새로운 기능이나 메인 페이지 유추에 대해 이야기하지 않아야 함) MBelgrano(대화) 15:40, 2010년 12월 9일(U)TC)[응답하라]

나는 시테노티스를 지지할 것이다. 하지만 우리가 어떻게 그런 메시지를 말할 수 있을까?내 생각에 미디어위키:그 어떤 것보다도 아논노티스가 적합할 것이다.하지만 잘 모르겠어... --DorsalAxe 11:53, 2010년 12월 10일 (UTC)[응답]

MediaWiki Talk에서 다음을 제안해 보십시오.시테노티스: 아마도 "위키피디아와 위키미디어 재단은 이름이 유사함에도 불구하고 내부고발 사이트 위키리크스와 관련이 없다." --Errant^(chat!) 12:44, 2010년 12월 10일 (UTC)[응답]

제안 위치: MediaWiki_talk:시테노티체#위키리크스.Rd232^talk 13:05, 2010년 12월 10일 (UTC)[응답]

이 제안은 아마도 미디어위키 토크에서 더 적절할 것이다.아논노티케, 거기서 내가 주목한 바 있다.편집자들은 이미 알고 있겠지만, 애논과 독자들은 그렇지 않다. 바하무트0013^words_deeds 17:43, 2010년 12월 10일 (UTC)[응답]

FWIW, 나는 다른 위키미디어 페이지에서 거부권을 본 적이 있다.(한 가지 예를 보려면 여기를 참조하십시오.)이러한 혼란은 나에게 가장 중요한 위키백과 관련 항목은 아니지만, 다른 기고자의 삶을 더 쉽게 진행시키고 1면에 고지사항을 추가한다면 WP:AN & WP:A/I는 물론 WP:부사장 --llywratch (대화) 21:10, 2010년 12월 9일 (UTC)[응답]

제발 안돼.우리는 지금 위키리크스를 먹일 뿐이다. / /ETECCOMMS/02:34, 2010년 12월 11일 (UTC)[응답]

자연 : 위키백과의 지혜를 뒷받침할 시간

네이처지의 최근 기사(2010년 12월 8일)는 다음과 같이 말하고 있다: 공공 기금이나 자선 기금을 받는 과학자들은 위키백과 기사들이 이해할 수 있고, 과학적으로 정확하며, 잘 소싱되고, 최신인지 확인할 기회를 잡아야 한다. 과학계의 많은 사람들이 위키피디아를 가끔 사용한다는 것을 인정할 것이지만, 내용물을 제공한 사람은 거의 없다. 사회를 위해서, 과학자들은 이 자원을 받아들이기를 꺼려하는 것을 극복해야 한다.자연 : 위키백과의 지혜를 뒷받침할 시간이다.흥미롭군조잔 (토크) 2010년 12월 10일 (UTC) 14:39 [응답]

나는 그것을 표지판에 베꼈다.샤이말(토크) 14:50, 2010년 12월 10일 (UTC)[응답]

그러나 실제로 흥미롭게도, 이것은 또한 효과 있는 기사들 안에서 편향될 가능성을 만들어내는데, 이것은 지켜볼 필요가 있을 것이다.Ajraddatz (토크) 15:18, 2010년 12월 10일 (UTC)[응답]

실제로 꽤 많은 과학자들과 다른 전문가들이 위키피디아를 연구하고 있다.'작동하는 방식'에 혐오감을 느껴 포기한 사람도 꽤 있고, 차단되거나 금지된 사람도 적어도 2명이나 된다.어떤 분야에서는 그것이 전문가 친화적이라는 평판을 가지고 있지 않다.피터 잭슨 (대화) 2010년 12월 10일 (UTC) 16:00[응답]

그래, 기여도가 좋은 과학자도 많고, 자기 이론을 홍보하는 과학자도 있고, 남들보다 '잘 아는' 것에 대한 공감대를 형성하지 않아 결국 차단되거나 금지된 과학자도 몇 명 있어. / /ETECCOMMS/ 02:38, 2010년 12월 11일 (UTC)[응답]

글쎄, 모든 편집자들의 범주처럼, 그것은 보인다.과학자 자신으로서(경고:파렴치한 자기 홍보) 나는 과학자들을 위한 WP에 기여하기 위해 이 작은 안내서를 쓰면서 편지의 저자들과 협력했다.그 후 어떤 과학자가 그것을 읽고 나서 WP에 기여하기 시작했는지는 흥미로울 것이다. --사이클로피아^talk 10:51, 2010년 12월 11일 (UTC)[응답]

1년 후 메인 스페이스의 페이지에 대한 편집 보호 상한

메인 스페이스 기사에 편집 보호(일반적으로 반보호)를 1년 동안 사용할 수 있는 "캡(cap)"을 제안하는 것.나의 이유는 편집 보호를 "무시하게"로 설정하는 것이 "설정하고 잊어버려" 기능에 가깝기 때문이며, "미결 변경" 재판에서 보듯이, 그 당시에는 확실히 보호가 필요했지만 영구적인 (세미) 보호가 필요하지는 않은 기사가 꽤 있었다고 생각한다.이것은 새로운 사용자나 익명 사용자가 더 많은 기사를 편집할 수 있도록 계속하는 데 도움이 될 것이다.–MuZemike 01:01, 2010년 11월 24일 (UTC)[응답]

보호 페이지 목록이 있는데, 이것은 무기한 보호를 보여줄 수 있다.그 리스트를 가끔 훑어보는 것은 그렇게 어렵지 않지만, 나는 네가 말하는 것을 보고 동의해.현실적으로 어떤 페이지도 무한정 보호되어서는 안 되며, 기본 페이지와 기타 매우 높은 사용 페이지와 템플리트를 저장해야 한다.Ajraddatz (토크) 02:12, 2010년 11월 24일 (UTC)[응답]

납득이 가지 않는다.예를 들어, 공공 기물 파손에 대한 특정 취약성이 입증된 저명사 BLP는 1년 후에 갑자기 그것에 노출되어서는 안 되며, 확장하거나 재보호하는 것을 기억하는 누군가에게 의존해서는 안 된다.비한드는 적게 사용해야 하며, 비한드를 사용하는 페이지 목록은 정기적으로 확인해야 하지만, 비한정도는 따로 있다.Rd232 02:44, 2010년 11월 24일 (UTC)[응답]

나는 강하게 반대한다; 때때로 보호가 켜지고 어떤 이유로 "잊혀지는" 것이다.이것의 훌륭한 예는 2006년 7월 31일 이후로 효과적으로 보호되어 온 코끼리일 것이다.우리가 그것을 무너뜨릴 때마다 파괴 행위는 즉시 복구되고, 그래서 그것은 빨리 복구된다.EVULA// talk // talk // 20:19, 2010년 11월 30일 (UTC)[응답]

몰라, 나는 우리가 결국 사람들이 콜버트가 코끼리에 대해 행동하라는 요구를 잊어버릴 것이라고 합리적으로 추정할 수 있다고 생각해.내 말은, 그건 그냥 TV쇼의 한 에피소드였어.5년 정도 지나면 보호받지 못하는 걸 시도해봐Dcoetzee 18:42, 2010년 12월 11일 (UTC)[응답]

사이비 종교 추종자들은 들어본 적이 없겠지?난 여전히 Evil의 반달리즘을 되돌리고 있어 2006년에 농담을 했던 어떤 웹툰에서 유래한거지인터넷에는 정말 헌신적인 사람들이 있다.— 당신을 먹여 살리는 손:^Bite 2010년 12월 13일 (UTC) 15:45[응답]

• 메인 스페이스의 페이지에서 1년, 그리고 보호가 종료되기 한 달 전에 편집 보호를 상한으로 수정하면, 봇이 이를 전용 게시판이나 RFP 오프슈팅으로 올리도록 한다.이것은 편집자들에게 괜찮을까? 위피오네 03_....... ^{Leave a message}:34, 2010년 12월 7일 (UTC)[응답하라]

나는 예년의 이 날에 보호되거나 반보호된 기사를 보여주는 보고서가 가치 있을 것이라고 생각한다.그러나 우리는 그러한 모든 결정이 부정확하거나 다양한 BLP 문제가 사라졌다고 가정해서는 안 된다.우리 편집자들이 왔다 갔다 하는데 특정 연예인들의 악명은 종종 덧없는 것이다.그러나 어떤 실생활 스토킹과 왕따 사건은 여러 해 동안 계속되며, 우리는 적절한 대응을 해야 한다.나는 관리인이 그들이 고리를 보고 있고 필요하다면 보호를 부활시킬 준비가 되어 있다면, 기사에 대한 보호를 줄이기로 고려된 결정을 내린 것에 대해 기쁘다.나는 특히 보호 관리자가 더 이상 기사를 볼 수 없다면, 기사에 대한 경계를 낮추는 자동화된 과정이 마음에 들지 않는다.2010ereSpielCequers 13:29, 2010년 12월 7일 (UTC)[응답]

BLP 인포박스의 종교 분야

나는 BLP infoobox의 종교 분야는 개인의 종교로서 제거되거나, 종교의 결여는 개인적인 성질의 것이며, 종종 유동적인 성질의 것이며, 오직 그/그 사람에 의해서만 정의될 수 있다고 제안한다.이 문제는 에드 밀리밴드 휘하의 BLP 공지 게시판에 올라왔는데, 이 게시판에서 그를 '유대인'으로 등재할 것인지 '유대인 혈통'으로 등재할 것인지에 대해 어느 정도 논란이 일고 있다.만약 인포박스에 종교 분야가 없다면 논쟁은 존재하지 않을 것이다.많은 사람들이 이 관점을 공유하고 있을 것이다.마크^Dask 07:35, 2010년 12월 6일 (UTC)[응답]

• 반대 - 위키피디아에 대한 논쟁을 없애는 가장 확실한 방법은 기사를 갖지 않는 것이다.어려운 주장은 콘텐츠 제공을 회피할 이유가 아니다.전통적으로 우리는 어떤 종교, 국적 또는 민족성에 대한 질문을 우리가 그들의 이름을 결정하는 것과 같은 방식으로 해결한다 - 그들이 어떻게 자기 정체성을 갖는지 그리고 어떻게 그들이 신뢰할 수 있는 대부분의 출처에서 설명되는지를 참조한다.사람의 종교에 대한 합의가 없는 경우에는 그 분야를 공백으로 둘 수 있다.이 분야를 삭제하는 것은 종교가 주체성의 중요한 부분인 BLP 기사에 해를 끼칠 것이다. - 더스트폼스워즈 (대화) 08:23, 2010년 12월 6일 (UTC)[응답]
• 이 필드의 주석 사용은 WP에 따라 강력하게 금지되어야 한다.BLPCAT. 그것은 어느 정도는 누군가의 종교가 그들의 공공 생활과 관련이 있는지 여부를 규명하는 것이 어렵기 때문에 최소한으로 시행되는 BLP 정책이다.Ed Miliband의 예에서, 나는 BLPCAT가 아마도 적용된다고 생각한다. 왜냐하면 그가 반대파의 리더라는 관점에서 그의 종교에 대한 어떤 미디어(또는 다른) 관심도 출처가 불가능하기 때문이다.하지만 완전히 제거될 수 있는지는 잘 모르겠다. --정확한 09:49, 2010년 12월 6일 (UTC)[응답]
• Comment 이것은 편집자들의 더 문제다.그 분야는 종교가 그들의 삶에서 중요한 매우 많은 사람들을 위해 그곳에 있어야 한다.그러나 필드를 채우기 위해 검색해야 한다면, 그것은 정보원이 말하는 것이어야 한다.불행히도 어떤 편집자들은 모든 필드 콤플렉스를 채워야 하는데, 그것은 마치 어떤 작곡가의 아내가 그를 짜증나게 하고 싶을 때 피아노로 연주해서 그가 일어서서 연주해야 했던 이야기와 같다.Dmcq (대화) 2010년 12월 6일 12시 31분 (UTC)[응답]
• 대부분 DustFormsWords에 의해 반대한다.만약 출처가 종교적인 제휴에 일치한다면, 우리는 그 분야를 채울 수 있을 것이다.그들이 그렇게 하지 않으면, 우리는 그것을 비워둘 수 있다.쉬워요존재하지 않는 문제에 대한 해결책을 제시하지 말자. --Cyclopia^talk 12:37, 2010년 12월 6일 (UTC)[응답]
• 나열된 모든 이유로 반대한다.때때로, 그것은 관련성이 있고 매우 인용 가능한 사실이며, 포함되어야 한다.다른 때에는 스케치되거나, 불손하거나, 검증되지 않은 경우가 있으므로, 공백으로 두어야 한다.모든 infobox의 모든 분야가 채워질 필요는 없으며, 필요한 것은 편집자의 관심사 부분에 대한 diligence뿐입니다. --Jayron32 13:17, 2010년 12월 6일 (UTC)[응답]
• 반대하라. 단지 어떤 것이 남용될 수 있다고 해서 그것이 금지되어야 한다는 것을 의미하지는 않는다.반대로 성직자의 한 구성원에 대한 기사가 피험자의 종교적 소속에 대해 아무런 언급도 하지 않는 것은 오히려 어리석은 일일 것이다.상식과 편집상의 판단은 모든 상황을 하나의 크기로 구둣발로 만들도록 요구하는 것보다 더 나은 해결책이다. --Alen3 14:20, 2010년 12월 6일 (UTC)[응답]
• 지원 만약 누군가의 종교적 신념(또는 결여)이 그들의 신뢰성과 관련하여 중요한 것이라면(이것이 그들이 전혀 주어지지 않는 유일한 이유), 이것은 적절하게 논의될 수 있는 BLP 본문 본문에서 다루어져야 한다.infobox에 필드를 갖는 것은 정당한 이유 없이 그것을 채우기 위한 공개적인 초대장이며, 포괄적인 일반화를 장려한다.그것은 모두 편집자들로부터 근면함과 주의력이 필요하다고 말하는 것은 당연하지만, 그 증거가 그것이 항상 주어지는 것은 아니라는 것을 암시하는 것 같다.그의 인포박스 분야를 포함시키는 것은 BLP에 특유한 지나치게 범주화하는 경향이 더 넓어질수록 피험자의 적절한 백과사전적 치료에서 멀어진다는 징후다.또한 식별 가능한 종교에서 실제로 가져야 하는 개념(또는 그 개념에 대한 잘 정의된 거부)은 유대/기독교/이슬람 전통에 깊이 뿌리박고 있는 보편적인 개념은 아니지만, 모든 맥락에서 거의 적용이 안된다는 점에도 주목할 필요가 있다.아마도 '종교' 분야는 그것이 잘못 사용될 수 있기 때문이 아니라 그것의 존재 자체가 중립적이지 않은 POV를 내포하고 있기 때문에 인포박스에서 제거될 필요가 있을까?나는 여기서 이 논쟁에 크게 동의할 수 없을 것 같지만, 그것은 말할 필요가 있다.Andy TheGrump (talk) 2010년 12월 6일 16:30, (UTC)[응답]
• {{BLP infobox}}}은(는) 없다...그러나 예를 들어 {{Infobox person}} 설명서에는 "관련될 경우 종교"라고 나와 있다.필자는 (존재하는 많은 BLP Infobox 템플릿에서) 필드를 삭제하는 것이 별로 도움이 되지 않는다고 생각하지는 않지만, 종교가 단순히 그 Infobox를 사용하는 BLP와 충분히 관련성이 없다는 근거에 따라, 특정 Infobox 템플릿이 이를 제거할 수 있을 것이다.또한, 우리는 봇이 종교 분야를 사용하는 infobox가 있는 모든 기사에 HTML 코멘트를 추가하도록 할 수 있다. "이 분야는 그 사람의 명성과 충분한 소스와 관련이 있는 경우에만 채워져야 한다."와 같은 것 말이다.Rd232^talk 17:40, 2010년 12월 6일 (UTC)[응답]
  • 종교 분야의 BLPCAT에 대해 {{infobox person}}에게 메모를 추가했다.그것이 논란의 여지가 없기를 바라며 --Errant 00:15, 2010년 12월 7일 (UTC)[응답]
  • 다른 필드인 Show_Collision_As_Is_Related가 true로 설정되지 않은 경우 종교 필드를 기본적으로 표시하지 않도록 설정하는 것은 어떨까?Rd232 08:58, 2010년 12월 7일 (UTC)[응답]

• 앤디로서의 지원위에서 언급한 그럼프는, 상당히 복잡한 상황이 될 수 있는 것에 대해 한 마디로 설명하는 것은, 우리가 쓰는 대부분의 사람들에 대한 모욕이다.나의 견해가 몇 문장 이하로 표현될 리가 없다.우리 나라 호주에서, 다른 사람들의 종교는 우리 대부분에게 전혀 중요하지 않다.그러나, 항상 기사에 그것을 추가하기를 원하는 소수의 사람들이 있다.최근에 이것은 몇몇 기사에 대한 매우 광범위한 논쟁으로 이어졌다.특히 우리의 새 총리 줄리아 길라드는 자신이 종교적이지 않다고 선언했다.이것은 종종 그녀의 종교가 무신론자라고 말하기 위해 그 기사를 편집하려는 시도로 이어졌다.그것과 관련된 몇 가지 문제들.첫째로, 그녀는 무신론자라고 말하지 않았으니, 그것은 합성이야.둘째로, 무신론은 종교가 아니다.셋째, 그러한 상태를 나열하고자 하는 사람들은 종종 POV의 이유로 그렇게 하는 것을 볼 수 있다.모두 매우 건강하지 않다.그리고 괜찮은 백과사전을 만들려고 노력하는 진지한 편집자들에게는 시간낭비였다.HiLo48 (대화) 00:36, 2010년 12월 7일 (UTC)[응답]

• 지지대 제거도.DOB나 성별이나 다른 것과 달리, 종교는 내가 "안정할 수 없는" 것이다.종교는 사람 자신의 신념이며, 가족도 모르게 바뀔 수도 있다.이것을 검증하는 데 필요한 출처를 얻는 것은 거의 불가능하다.만약 우리가 그런 분야를 유지한다면, 분쟁은 결코 끝나지 않을 것이라고 확신한다.레흐만

• 살아있는 사람들의 반대 전기들은 이 사이트에 포함된 전기의 극히 일부분일 뿐이다.필드가 존재한다면 이를 채워야 한다고 생각하는 사람들에 의해 BLP에서 오용될 수 있는 것이 염려되는 경우 템플릿 설명서에 고지 사항을 포함시키십시오.MBelgrano (대화) 21:28, 2010년 12월 7일 (UTC)[응답]

논평 - 그것은 당신이 말한 것처럼 쉽게 다룰 수 있는 문제의 사소한 부분이다.위에 언급된 다른 이슈들은?HiLo48 (대화) 21:53, 2010년 12월 7일 (UTC)[응답]

당신이 나열하는 다른 문제들은 모두 "논쟁적으로, 무지하게, 또는 불신하게 편집하는 사람들"의 범주에 속하는데, 요컨대 위키피디아의 문제다.그것에 대한 간단한 해결책은 없으며, 인포박스에서 밭을 제거하면 문제가 해결되거나 가장 사소한 방법 외에는 그 피해를 완화시키지 못한다.문제를 관리하는 가장 좋은 방법은 토크 페이지 토론 + 널리 사용되는 템플릿 변경이 아닌 롤백 권한을 가진 숙련된 편집자의 관심이다. - DustFormsWords (토크) 01:26, 2010년 12월 8일 (UTC)[응답]

어떤 식으로든 기사에 어리석은 덧셈의 빈도를 줄이는 '다양한' 방법이 있다면, 그것을 이용하자.HiLo48 (대화) 03:44, 2010년 12월 8일 (UTC)[응답]

• 위키피디아에서 사소한 잡담. 즉, 백과사전에서 설 자리가 없다는 것이다.이러한 변화로 얻을 수 있는 이득은 독자들에게 한 눈에 명확하게 읽을 수 있는 정보를 제공하는 우리의 능력에 미치는 피해를 상쇄하지 않으며, 그것이 해결하기 위해 제안하는 문제는 이미 기존의 과정과 절차를 통해 잘 관리되고 있다. - DustFormsWords (대화) 03:54, 2010년 12월 8일 (UTC)[응답]

• 반대하라. 기사 주체의 종교가 적절하고 논란의 여지가 없는 경우가 많은데, 그런 경우에는 인포박스에 넣어 두는 것이 타당하다.다른 경우에는 해당 필드를 언제 사용하지 않을지에 대한 지침만 제공하면 된다.현재 거의 모든 게시판에 게시된 Ed Miliband 사례처럼 파괴적인 분쟁이 계속되고 있는 소수의 사례에 대해, 문제는 infobox 매개변수가 아니라 편집자에 의해 발생하며, 문제의 원인을 해결함으로써 해결되어야 한다.— 가비아 임머 (대화) 01:40, 2010년 12월 8일 (UTC)[응답]

• 반대 내용 논쟁은 만약 그 개념이 infobox 대신에 산문에 제시된다면 여전히 일어날 것이다.이 제안은 근본적인 문제를 해결하는 데 아무런 도움이 되지 않으며, 단지 편의를 위해 널리 사용되는 분야를 제거한다.기사 내에서 내용이 나타나는 부분이 차이를 보이는가?나는 그들이 템플릿 문서를 읽고 그러한 분야가 존재한다는 것을 보았기 때문에, 갑자기 어떤 이의 종교적인 관점이 포함되어야 한다고 결정하는 편집자들이 있다고 믿지 않는다.사실, 나는 얼마나 많은 편집자들이 템플릿 설명서를 읽는지 종종 궁금하다.짐 밀러 01:51, 2010년 12월 8일 (UTC)[응답]
• DustFormsWords에 따라 반대하십시오.킬러치후아어드바이즈^?!? 01:54, 2010년 12월 8일 (UTC)[응답]

• 반대 많은 사람들은 작가 T. S. 엘리엇과 C. S. 루이스가 로마 가톨릭 교회의 신도였다고 생각한다(엘리엇은 스스로를 앵글로 카톨릭 신자라고 불렀지만 둘 다 영국 교회의 신도였다).이것은 소개 단락에 반드시 기재된 것은 아니지만 쉽게 검색할 수 있어야 하는 중요한 정보다.종교에 들어가는 것에 대한 경고는 논쟁의 여지가 없고 편집자가 확실할 때에만(특히 신뢰할 수 있는 출처와 함께), 다른 곳에 문서화하지 않고 Infobox 템플릿의 종교 라인에 <!-- 뾰족한 괄호 -->를 넣어야 한다.—— 셰익스피어 (토크) 02:13, 2010년 12월 8일 (UTC)[응답]

논평 - 나는 종교가 눈에 띄지 않으면 안 된다고 주장하고 싶다. 종교가 우리가 그 사람에 대해 기사를 쓰는 이유와 관련이 없다면 그렇게 해야 한다.infobox에 필드가 있는 것은 경험이 적은 편집자들에게 그것이 식별될 수 있는지 여부를 항상 주목할 수 있다고 말한다.이미 언급된 또 다른 이슈는 자신을 "종교적이지 않다" 또는 "종교가 없다"와 같은 것이라고 선언하는 무신론자 또는 불가지론자로 분류하기로 결정한 편집자들의 것이다.매우 흔하지만 명료한 종합성이며, 무신론이나 불신론이 종교 분야에 유효한 출품작인지에 대한 의문을 제기한다.그들은 분명히 종교가 아니다.요약하자면, 그 분야가 잘못 사용될 수 있는 많은 방법들이 있다.위키피디아에는 좋지 않다.HiLo48 (대화) 03:56, 2010년 12월 8일 (UTC)[응답]

'편집'과 '반전' 기능이 잘못 사용될 수 있는 방법은 여러 가지가 있는데, 이를 잘못 사용하면 인포박스의 종교 분야보다 훨씬 더 큰 피해를 볼 수 있다.문제는 도구가 아니라 사용자다.도구를 제거한다고 해서 사용자가 수리되는 것은 아니며, 사용자는 의심의 여지 없이 다른 도구를 집어 잘못 사용할 것이며, 그 동안 합법적인 사용자는 건설적인 작업에 지장을 받게 된다.이러한 문제를 해결하는 적절한 방법은 교육, 토론, 그리고 당신의 감시 목록에 대한 책임 있는 수준의 주의를 통해서이다.또한 대부분의 사람들에게 AD 300년에서 AD 1960년 사이에 서구 세계에서 태어난 모든 사람들은 그들의 삶에서 중요한 요소로서 종종 국적보다 더 많이, 그리고 기본적으로 그 분야를 포함하기를 옹호하는 숫자에 대해서만 기사를 쓰고 있다. - 더스트폼스워즈 (talk) 04:02, 2010년 12월 8일 (UTC)[응답]

그리고 분명히 POV 성명의 확실성에는 내가 논의하고자 하는 문제의 완벽한 증거가 있다.편집자들이 그 분야로부터 관련 없는 항목들을 삭제하기 위해 너무 많은 시간을 소모하는 것은 바로 이와 같은 논쟁이다.HiLo48 (대화) 05:09, 2010년 12월 8일 (UTC)[응답]

미안하지만, 나는 우리의 생물 기사의 대다수가 AD 300에서 1940년까지 태어난 서양인에 관한 것이어야 한다고 말하는 것이 아니다. 나는 그들이 통계적 사실의 문제로서, 그리고 우리가 아무리 문화적 편견을 다루려고 해도, 영어 위키피디아는 가까운 미래에 바뀔 것 같지 않다.AD 300년 이전의 출생이나 더 많은 수의 비서방 출생아들이 그 문제를 해결할 수 있을지 모르겠다; 사실 종교의 중요성을 경시하는 것은 현대, 서구, 선진국의 자만인 것 같다.나는 여기서 무신론자로 말하지만, 또한 지난 세기의 사람들에 대한 기사를 편집하는데 꽤 많은 시간을 소비한 누군가는, 짜증스럽게도, 이런 오래된 사례에서 누군가의 종교(또는 종교의 결핍)를 결정하는 것이 그들의 삶에 대한 적절한 백과사전적 이해를 얻는 데 상당히 중요한 단계라는 것을 발견했다. - 더스트폼스워우rds (대화) 05:35, 2010년 12월 8일 (UTC)[응답]

• 우리는 사람들에게 증명할 수 있는 사실들을 알리기 위해 여기 있는 것에 반대한다. 그리고 이것은 그것들 중 하나이다.정보가 없는 경우 공백으로 두고, 인용할 수 없는 한 "없음" 또는 "불가침"을 구성하지 마십시오.아마도 우리는 논평에 인용에 필요한 태그를 부착한 사전 필름이 필요할 것이다.Graeme Bartlett (대화) 21:06, 2010년 12월 9일 (UTC)[응답]

• 반대 - 왜 제거하시겠습니까?몇몇은 감히 내가 위키피디아 기사에 나올 만큼 주목할만한 많은 사람들이 기독교든 무신론이든 어떤 신앙의 일원으로서 확인된다고 말한다.정보가 없으면 필드를 비워 두십시오.만약 누군가가 실제로 그들만의 작은 종교를 창시했다면, 물론, 하지만 그것은 상자 안에 있다.확실히 그것이 조달되었는지 확인해라.Ajraddatz (토크) 17:03, 2010년 12월 11일 (UTC)[응답]
• 반대하라. 정말로 개인의 종교가 명확하게 규정되어 있지 않거나 유동적이지 않다면, 그것을 한 단어로 요약하려고 하지 말라 - 인포박스에 넣지 말고 기사 본문에 넣으라.말이 되네.그러나 이것은 모든 사람들에게 해당되는 것은 아니다 - 종교가 상당히 명확하게 정의되어 있고, 명확하며, 그들의 삶에 주목할 만한 사람들이 많이 있다.Dcoetzee 18:36, 2010년 12월 11일 (UTC)[응답]

그럼 거절하겠네. 그냥 물어봐야겠다고 생각했을 뿐이야.마크^Dask 20:45, 2010년 12월 13일 (UTC)[응답]

절대 반대는 아니지만, 하지만 많은 사람들이 그것이 중요하다고 생각하고, 비록 그들이 그것을 없애기를 원하는 사람들의 요점은 일반적으로 무시했지만, 현 단계에서 그것을 제거할 기회는 없다.나는 여전히 인포박스의 그 분야의 편집자들에게 강력한 지도가 도움이 될 것이라고 주장한다. 왜냐하면 나는 분명히 그것으로부터 쓰레기를 치워야 했기 때문이다.그리고 아무도 불가지론자는 종교가 아니라는 나의 주장을 받아들이고 싶어하지 않는 것 같았다.HiLo48 (대화) 21:21, 2010년 12월 13일 (UTC)[응답]

OpenID 재방문

이제 다시 냄비를 휘젓고 오픈 사용 문제에 대해 새로운 시각을 가질 때가 되었다.위키백과의 아이디.WP 참조:OpenID Proposal.적어도 외부 오픈을 연결할 수 있는 데 걸림돌이 되는 기술적 세부 사항이 보이지 않는 경우사용자의 Wikipedia 계정에 대한 ID 계정 및 이후 열기를 통해 로그인 가능ID 제공자 선택.그건 옵트인이니까, 어떻게 오픈하는지 모르는 사람들은 다치지 않을 거야.아이디가 작동한다.

여기서 합의를 본 다음에 버질라의 기술자들에게 이 일을 완수하도록 압력을 가할 수 있을까?버그 9604는 이미 "지원[개방]"을 목적으로 출원되어 있다.모든 위키미디어 프로젝트에 대한 ID 확장" 및 제안 전략:제안:지원_열림아이디도 같은 생각을 갖고 있다.선두로 나아가자.위키백과. ...이름?~BFIZ 23:44, 2010년 12월 11일 (UTC)[응답]

나는 다른 시스템들 위에 있는 기술들을 아주 좋아한다. 그래서 나는 네가 이 질문에 겁먹지 않았으면 좋겠다.큰 장애물이 아니다.하지만 오픈을 사용함으로써 얻을 수 있는 몇 가지 이점을 주시겠습니까?아이디연계정?나는 막연하게만 그것에 익숙할 뿐이고, 지나가는 지식조차도 구시대적이다.주로 10년 상반기에 생방송에 나온 기억이 있는데, 이것이 '우리가 할 수 있기 때문'인지, 아니면 'X를 하고 싶은 사람들에게 이로울 것'인지 알고 싶다. -- ۩ 마스크 16:25, 2010년 12월 12일 (UTC)[응답하라]

당신의 제안으로 인해, 나에게 당신의 모든 로그인 정보를 하나의 암호로 저장하는 것이라고 읽혀지지만, 그 기능은 파이어폭스와 크롬의 계정 매니저를 재구성한 것처럼 보이기 때문이다. -- ۩ 마스크 16:28, 2010년 12월 12일 (UTC)[응답]

물론. 장점 1: OpenID는 사용 중인 컴퓨터에 상관없이 작동하며, 브라우저 기반 계정 관리자는 설치된 컴퓨터에 대해서만 작동한다.장점 2: 많은 오픈이 있는 제품ID 제공자, 로그인한 후에는 로그아웃할 때까지 로그인 상태를 유지하므로 위키백과에 로그인하기 위해 암호를 다시 입력할 필요가 없으므로 "로그인"을 눌러 로그인하십시오.ID" 단추를 누른 후 열기 선택더 안전한 ID 제공자(A. 당신의 비밀번호가 에테르를 통해 다시 전송되지 않기 때문이고 B. 키로깅 소프트웨어가 읽을 만한 것이 없기 때문이다).그게 도움이 되길 바래. 마차 (대화) 15:40, 2010년 12월 13일 (UTC)[응답]

'계정관리자' 타입의 일은 괜찮다.하지만 한 가지 예로, 컴퓨터에서는 작동하지 않고 브라우저에서는 작동하지 않는다는 겁니다.그들은 안전한 키링 타입 시스템의 매우 서투른 구현이다.오픈ID는 지금보다 훨씬 더 선호된다.–톰 모리스 (대화) 20:04, 2010년 12월 13일 (UTC)[응답]

그런 것들은 나를 위해 정당화하기에 충분하다, 나는 이것을 무조건 지지할 수 있다. -- ۩ 마스크 02:07, 2010년 12월 14일 (UTC)[응답]

아티클 공간에서 하위 페이지 사용

나는 이 일을 오랫동안 생각해 왔으니 너무 빨리 나를 화나게 하지 말아 줘.하위 대화 페이지만 사용할 수 있는 것이 아니라 주요 기사 공간에서 하위 페이지를 사용 가능. (그리고 더 나은 AND를 위해서는 대화 페이지가 볼륨 있고 일시적이라는 것을 인식해야 한다.쓰여진 것은 모두 몇 개의 항목이 더 있는 즉시 보이지 않고, 그 직후에 기록 보관소의 건초더미에 바늘이 꽂혀 있을 것이다.)여기에는 두 가지 목적이 있을 것이다.

• 기사 내의 주요 주제 및 "프로젝트"에 대한 체계적이고 체계적인 토론을 활성화하십시오.이렇게 하면 하위 기사 페이지에서 편집 가능하고 요약 가능한 작업이 가능하며 관련 하위 기사 대화 페이지에서 정기적으로 토론할 수 있다.존재의 예와 존재 이유/효익을 보여주는 예로는 중재 카발 작업에 이 구조를 사용하는 것이다.
• 특정 이름 하위 페이지를 지정하여 기사와 관련된 주요 결정 사항 및 기타 반영구적 기록을 기록하는 관행이 설정될 수 있다.예를 들어, 만약 편집자들이 주요 단락을 합의하는 데 한 달을 보낸다면, 그러한 내용이 거기에 기록될 것이다.지금 현재 유일한 기록은 토크 페이지 자료실에서 사라진다.모든 사람들은 그러한 중대한 노력이 그 결정에 도달했다는 것을 잊고 있다.이것은 불안정한 물품에 약간의 안정성을 제공하는 데 도움이 될 것이다.North8000 18:48, 2010년 12월 9일(UTC)

당신이 제안하는 방식으로 서브 페이지를 사용하려고 시도하는 것은 완벽하게 타당하지만, 나는 그 서브 페이지가 기사 공간에 있어야 할 이유가 전혀 없다고 본다.그들은 단지 토론 페이지의 맨 위에서 적절하게 연결되고 적절하게 조직될 필요가 있다.Rd232^talk 19:33, 2010년 12월 9일 (UTC)[응답]

그들이 또 어디에 있을까?내가 착각할 수도 있지만, 네가 "프로젝트-토크" 페이지 쌍을 만들 수 있는 유일한 장소는 사용자 공간과 에세이뿐이야.그리고 그들을 그들이 찬성하는 기사와 결부시키는 것이 훨씬 나을 것이라고 생각하고 있었다.진심으로, North8000 19:59, 2010년 12월 9일 (UTC)

또 어디 있지?예: 대화:흥미로운 주제/강력한 토론 및 대화:흥미로운 주제/아무것도 아닌 것에 대한 아도, 제발 다시 꺼내지 마십시오. 두 가지 모두 토크의 맨 위에 언급되어 있다.흥미로운 주제.Rd232 20:59, 2010년 12월 9일 (UTC)[응답]

나는 이것이 슬래시를 사용하는 기사를 허용하기 위해 장애인이었다고 믿는다.예를 들어, Nip/Tuck은 "Nip"의 하위 페이지로 "Tuck"이라는 이름이 붙을 것이다.Killiondude (대화) 20:02, 2010년 12월 9일 (UTC)[응답]

나는 그런 변화가 기사 제목에서 슬래시를 빼야 한다는 것을 알고 있었지만(그것은 드문 일이라고 생각한다) 그것이 그 이유라는 것은 들어본 적이 없었다.개가 꼬리를 흔드는 것 같아!North8000 20:06, 2010년 12월 9일(UTC)

하지만 당신은 대화 페이지의 하위 페이지를 만들 수 있기 때문에, 기사들의 하위 페이지를 만드는 것은 필요하지 않다.펜스&윈도우즈 21:43, 2010년 12월 9일 (UTC)[응답]

지금도 Talk:Nip/Tuck은 Talk의 하위 페이지로 보여진다.Nip과 Nip/Tuck의 대화 페이지도 함께, 그것은...혼란이다.DMACks (대화) 21:51, 2010년 12월 9일 (UTC)[응답]

기사에 대한 논의는 기사 공간이나 서브페이지에 속하지 않는다.토론은 토크 페이지에 속한다.편집 결정의 기록은 기사 공간에 속하지 않는다. 예외적인 경우를 제외하고, 위키텍스트의 <!!-- 숨겨진 논평 ->의 문제 지점에 메모가 포함될 수 있다.Anomie 9 22:02, 2010년 12월 9일 (UTC)[응답]

• 토크 아카이브 인덱스에 사용할 수 있는 도구가 이미 있거나, {{archivebox auto=yes search=yes}}}을(를) 사용하여 검색 상자로 설정할 수 있다.서브페이지의 문제점은 워치리스트에 올려질 사람이 너무 적다는 것이다.변화를 놓치기란 너무 쉽다.하위 페이지가 "나쁜" 이유에 대한 일부 배경은 이 페이지와 지난해 주석 하위 페이지가 더 이상 사용되지 않았을 때의 기본 토론을 참조하십시오.짐 밀러 22:04, 2010년 12월 9일 (UTC)[응답]

To RD232: 그러나 그것들은 토론된 이점을 제공하지 못하는 제한된 대화 페이지들이다.

To: Anomiex 해당 유형의 페이지가 존재하지 않도록 하기 위한 이유로 존재하지 않는 규칙(기사가 존재하지 않는 유형의 페이지에 올려져서는 안 됨)을 언급하는 경우.

수신:짐 밀러그 정보 고마워.당신의 논평은 비기사 페이지에 대한 기사 내용을 의미하며, 이것은 계속 금지될 것이다.성심껏 북8000 22:17, 2010년 12월 9일 (UTC)

"논의된 이점"?당신은 대화 페이지 하위 페이지들이 갖지 못할 기사 하위 페이지들로부터 어떠한 장점도 주지 않았다.Rd232 00:53, 2010년 12월 10일 (UTC)[응답]

혼란스럽겠지만, 당신의 원래 제안은 기사 공간 하위 페이지에 토크 페이지 자료를 넣는 것 같았다.나는 그것을 하는 것이 금지되어 있다는 것을 지적하는 위의 반응에 기대를 걸고 있었다.기사에 대한 토론은 오직 대화 페이지에 있을 뿐이다.하위 페이지에 대한 요점은 여전히 유효하다.기사를 편집하거나 볼 때, 토크 페이지는 자동으로 감시 목록에 추가된다.두 공간 모두 하위 페이지에서는 이러한 현상이 발생하지 않는다.나는 단지 새로운 하위 페이지를 만드는 것은 감시되지 않은 페이지가 되고, 어떤 네임스페이스에서든 가장 마지막으로 필요한 것은 감시되지 않은 페이지라는 것을 지적하고 싶었다.짐 밀러 ^{See me Touch me} 23:59, 2010년 12월 9일 (UTC)[응답]

보지도 않은 페이지는 공정한 포인트다.이러한 종류의 하위 페이징은 주제별로 구성된 토론의 역사적 기록이나 다른 접근법이 비실용적인 경우 가장 활발한 토론 페이지를 위해 상당히 많이 유지되어야 한다.한 번의 클릭으로 한 페이지의 모든 하위 페이지를 볼 수 있는 능력이 있다면 달라질 것이다...소프트웨어에서, 물론, 어쩌면 장비로도 그렇게 하기 어렵지 않을 것 같은 것은?Rd232 00:53, 2010년 12월 10일 (UTC)[응답]

아마도 나는 그곳에 어떻게 갈 것인가에 대한 기술적 문제보다는 의도된 결과를 설명함으로써 내 자신을 더 잘 설명할 수 있을 것이다.그리고 단순함을 위해서, 그리고 나중에, 나는 토론에서 나의 "영구적인 기록" 목표를 철회할 것이다.따라서 다음과 같다.

2페이지 작업영역을 기사에 첨부할 수 있는 능력. 1/2은 WP토크 페이지 규칙이 없는 임시 프로젝트의 "프로젝트" 페이지로서, 토론의 응축되고 편집 가능한 "워크 제품"이다.예를 들어, 작업 중이거나 논의 중인 대규모 신규 섹션의 개발 초안 또는 개발/삭제 중인 참조 목록.나머지 절반은 그 작업 공간과 관련된 토크 페이지다.예를 들어, 이 구조는 이미 기사와 관련된 조정 카발 사건에 사용되고 있는데, 그럴 만한 이유가 있다...그러한 구조는 필요하고 유용하다.그러나 다른 방법으로는 이용할 수 없다.North8000 02:32, 2010년 12월 10일(UTC)

나는 대규모 토론을 비공식적으로 중재/정리할 때(예를 들어, 토크 페이지에서 "편집 가능한 작업영역"을 정의 및 설정하거나, 토크 하위 페이지를 "편집 가능한 작업영역"으로 정의) 이러한 것들을 토크 페이지에 비공식적으로 설정해 놓았지만, 그것은 일반적인 토크 페이지 규칙과 반대되기 때문에 사람들에게 매우 어색하고, 또한 또한 매우 중요하다.활성 대화 페이지인 경우 이전 섹션(아직 활성화되어 있는 동안)에서 "로스트".그리고, 토크 하위 페이지가 「편집 가능한 업무 공간」으로 설정되어 있는 경우는, 그것과 연계된 토크 페이지가 없는 경우, 주요 기사 토크 페이지의 4가지 바람으로 토론이 분산된다.North8000 02:39, 2010년 12월 10일(UTC)

토크 하위 페이지는 여전히 자체 기사/토크 페이지 쌍을 가지고 있다.대화 참조:임시 아일랜드 공화국군/초안Rd232 08:57, 2010년 12월 10일 (UTC)[응답]

내가 당신을 제대로 이해하고 있다면, 당신은 본 기사 토크 페이지를 서브 워크스페이스의 토크 페이지로 사용하는 것을 언급하고 있는 것이다.그것은 내가 언급하고 있던 "사풍에 대한 충격" 상황이었다.[[4]에 있는 사람들 중 하나를 예로 들어보자.성심껏, North8000 10:22, 2010년 12월 10일 (UTC)

알았어, 이제 네 요점을 더 잘 이해했어.여기에는 두 가지 기존 옵션이 있다: (i) 사용자가 활동 중일 때, 일반적인 프로젝트/토크 페어링이 있을 때 초안을 사용자의 사용자 공간에 두고, 완료되었을 때 여러 개의 토크 하위 페이지에 보관한다(iii) 해당 쌍을 대화 페이지 하위 페이지에 재생산한다(예: Talk:임시 아일랜드 공화국군/초안 및 대화:임시 아일랜드 공화국군/초안 대화, 각 페이지 상단에 다른 페이지를 가리키는 메모가 있음(그 예 참조).Rd232^talk 17:49, 2010년 12월 10일 (UTC)[응답]

아이디어 고마워, 내가 쓸게.나는 내 아이디어의 취지를 좀 더 일반적인 용도로 사용하는 것이 좋을 것이라고 생각한다.비록 통과하지 못하더라도.문서 공간에서 하위 페이지 활성화.아마도 그것은 두 개의 하위 대화 페이지를 페어링하고, 그 중 하나를 편집 가능한 작업 공간으로 다시 정의하라는 지침일 것이다.North8000 13:18, 2010년 12월 11일(UTC)

좋은 생각 - 도움말 페이지일 수도 있고 기존 페이지의 단락일 수도 있다.나는 이런 종류의 초안이 매우 도움이 될 수 있고 장려되어야 한다고 생각한다.Rd232^talk 13:43, 2010년 12월 12일 (UTC)[응답]

몇 가지 기사에 써보려고 한다.결국 에세이로 제안된 틀을 쓸지도 모른다.그렇지 않으면 이런 일을 하는 모든 사람들은 매번 무언가를 꾸며내야 할 것이다.North8000 15:29, 2010년 12월 15일(UTC)

도움말:대화 공간 초안.Rd232 22:31, 2010년 12월 17일 (UTC)[응답]

프로젝트 네임스페이스에서 편집 통지 사용

위키프로젝트 페이지의 맨 위에 등록 사용자가 편집 고지를 추가할 수 있도록 허용하면 많은 혜택과 상대적으로 단점이 있을 수 있다고 생각한다.위키백과로 시작하는 페이지에 대해 활성화할 수 있는가?위키프로젝트 ? - ʄooʏiaɲ 21_¢:07, 2010년 12월 14일 (UTC)[응답]

제발 그러지 마. 다른 데서도 충분히 짜증나니까, 차라리 모든 네임스페이스에서 없애 버릴래.던컨힐 (대화) 21:10, 2010년 12월 14일 (UTC)[응답]

그것들은 아마도 당신이 짜증나게 하는 개별적인 예일 것이다. 능력 그 자체는 아니다.프로젝트 페이지 맨 위에 메모 한두 장만 추가하면 정확한 장소로 사용자를 안내할 수 있을 것 같아.BLP는 짜증나긴 하지만 인정해- 2010년 12월 14일 (UTC) 21:14 (응답τ_¢)

나는 내가 짜증나지 않는 것을 본 적이 없다.던컨힐 (대화) 01:14, 2010년 12월 15일 (UTC)[응답]

프로젝트 토크 페이지에서 제안된 노트에 대한 토론을 시작하고, 의견이 일치하면 관리자가 쉽게 편집 공지를 작성할 수 있다.Anomie december 21:19, 2010년 12월 14일 (UTC)[응답]

WP에 관심이 있을 수 있다.CSHIDE. 각 편집자마다 고유 ID가 있어야 CSS 파일을 사용하여 숨길 수 있다.Rd232^talk 21:38, 2010년 12월 14일 (UTC)[응답]

왜 관리자 시간을 낭비하는가?일부 프로젝트 페이지(예: 여기)에서는 볼 수 있지만 다른 페이지에서는 볼 수 없다.왜 이 위키백과 네임스페이스 페이지에는 하나의 자리 표시자가 있지만 다른 페이지에는 없는가? - ʄooɗiaia^τ_¢: 22:50, 2010년 12월 14일 (UTC)[응답]

X,Y,Z 페이지에 표준 템플릿을 추가하도록 요청하거나 사례별로 처리하거나 심지어 (템플릿을 사용하여) 요청하는 것은 정말 큰 문제가 아니다.일반적으로 이 페이지를 허용하는 것의 문제점은 이 페이지들 중 많은 부분이 별로 감시되거나 편집되지 않는다는 것이다. 그래서 다양한 종류의 남용들이 용납할 수 없을 정도로 오래 지속될 가능성이 더 높다.Rd232^talk 01:01, 2010년 12월 15일 (UTC)[응답]

나는 편집자:3 - 그 이상, 위키프로젝트 공간에 있는 몇몇이 어떻게 어떤 것도 다치게 할 수 있는지 모르겠다.Ajraddatz (토크) 15:16, 2010년 12월 15일 (UTC)[응답]

{{PD-self-}}->{self cc-zero}}}

모든 업로드 양식에서 {{PD-self}}을(를) {{Self Cc-zero}}로 변경하는 것을 제안한다. 왜?우리는 개방된 표준의 세계에 살고 있다.우리는 이미 라이선스 상태를 표시하기 위해 크리에이티브 커먼즈 템플릿을 많이 사용하고 있지만, 저자에 의해 공개 도메인에 무언가가 공개된다는 것을 표시하기 위해 우리는 우리만의 커스텀 템플릿을 가지고 있다.이를 변경함으로써 저작자와 (재)사용자가 작품의 라이센스 상태를 쉽게 결정할 수 있도록 한다.Commons에서 우리는 이미 이 주제를 변경했다. 2010년 11월 24일 (UTC) 20:09, 20:09[응답]

공공 영역 헌신을 "브랜드화"하는 것은 이상하지만, CC 헌신은 더 잘 쓰여져 있다."법률상 허용되는 최대 한도" 등나는 그것을 해 보라고 말했다.—Noisalt (대화) 20:33, 2010년 11월 24일 (UTC)[응답]

CC-0(그러나 아래를 보라)에는 아무런 문제가 없지만, 이런 변화를 만들면 어떻게 인식될 것인가 하는 우리의 기본적 공공영역 헌신으로 활용해서는 안 된다고 생각한다.크리에이티브 커먼즈는 공공영역의 개념을 소유하지 않으며, 우리는 그들이 그렇게 한다고 암시해서는 안 된다.그런 말을 했으니 나도 개인적으로 {{Pd-self}라는 표현이 마음에 들지 않는다.CC-0과 대부분의 다른 PD수첩과 마찬가지로, 그것은 사법적으로 발명한 "권리"가 존재하지 않았기 때문에 원래 헌신에 주어지지 않았던 "권리"의 잠재력에 대항할 만큼 충분히 강하지 않다. 그리고 유럽 법학의 "도덕적 권리"의 역사는 그러한 이중 비밀권이 계속해서 발명될 것임을 암시한다.차라리 우리가 사용자 PD 부분에 맞춰 언어를 사용하는 것이 낫겠다.가비아 임머/저작권, 대부분의 사람들이 그 문제에 대한 내 정확한 견해를 공유하지 않는 것 같아 의심스럽다.— 가비아 임머 (대화) 21:46, 2010년 11월 24일 (UTC)[응답]

• 지원, 또한 저작권 태그의 폭이 커먼스와 다른 이유가 있는가?템플릿 너비 허용(템플릿:CC-레이아웃 등)을 100%로 변경하여 Commons와 일치? -- 도! 01:04, 2010년 11월 25일(UTC)[응답]

• 지원 - CC-0은 대안보다 훨씬 더 철저해 보인다.표준으로 가는 것은 또한 우리에게 덜 일한다는 것을 의미하며, 아마도 면허 설계의 배경에는 더 많은 전문지식이 있을 것이다.'브랜드'에 대한 불편함은 작은 대가를 치러야 할 것 같다. --Avenue (토크) 14:13, 2010년 11월 27일 (UTC)[응답]
• 지원 CC-0은 더 많은 법적 조사를 받았고 법정에서 더 잘 설 것 같다. --사이버코브라 (대화) 03:04, 2010년 11월 29일 (UTC)[응답]

• 지원, 그런데 왜 아직도 영어 WP 업로드 양식을 가지고 있는지 궁금하다.자유로운 이미지가 필요한 무료 백과사전이다.우리는 커먼즈 업로드 양식만 사용해야 한다.--Wickey-nl (대화) 12:35, 2010년 11월 29일 (UTC)[응답]
  • 우리가 무료 이미지를 선호하더라도 여전히 공정한 사용 이미지를 허용하기 때문에, 그리고 여기 Commons에 없는 자유라고 여겨지는 몇몇 이미지들이 있기 때문이다.Anomie november 16:38, 2010년 11월 29일 (UTC)[응답]
    • 나는 그것이 사실 한 장소에서 자유롭지만 다른 곳에서는 자유롭지 않다는 점에서 그 반대라고 믿는다.많은 게르만 국가들에서 독창성의 기준은 여기보다 훨씬 더 높다.표준적인 예로는 스타워즈 로고가 있다.검정색 배경의 문자일 뿐 독일이나 네덜란드에서는 저작권의 자격이 없으며 (있었는가?마지막으로 이것이 나온 것은 06년에 커먼즈에서 주최했던 것 같다.내 기억이 맞다면 유럽에 서버를 내려놓는 게 전부였던 것 같아, 드위키는 미국의 규칙이 공용어로 사용되는 것에 약간 화가 나 있었다. -- -- 마스크 02:15, 2010년 12월 12일 (UTC)[응답하라]
      • 지난 번에 나는 Commons가 저작권이 미국과 원산지 둘 다 만료되도록 요구했고, 우리는 단지 미국만 요구한다고 들었다.de에 대해서.위키, 어쩌면 우연의 일치일 수도 있지만 내가 하원에서 만난 대부분의 짜증나는 삭제론자들은 독일인으로 자명했다; 나는 그것이 개선이라고 확신할 수 없다.Anomie 12 03:42, 2010년 12월 12일 (UTC)[응답]
        • 성가신 삭제론자?와우, 내가 들어본 적 있는 말인데...그건 아직 위키미디어 프로젝트야, 그런 사람에 대해 함부로 말할 필요 없어.일부 사람들이 경멸적으로 하는 것에 대해 논평하는 것과 같은 진술을 적용하는 것 사이에는 다소 뚜렷한 차이가 있다.'너 지금' 또는 '너 지금 연기하고 있구나'의 차이점이다.---۩ 마스크 10:05, 2010년 12월 12일 (UTC)[응답]
          • 그들이 삭제주의자들이고 그들이 그것에 대해 짜증난다면...Anomie⚔ 13:27, 2010년 12월 12일 (UTC)[응답]
• 나는 위의 가비아에 동의한다.CC-0은 문제없지만, 우리의 표준 PD 템플릿에는 문제가 없다.Killiondude (대화) 2010년 11월 29일 17:15 (UTC)[응답]

• • 실제 우리 PD수첩 템플릿은 얼마나 조사했나? --사이버코브라(토크) 18:16, 2010년 11월 29일 (UTC)[응답]
    • 아마도 라이센싱과 관련하여 우리가 가지고 있는 다른 템플릿만큼.Killiondude (대화) 18:38, 2010년 11월 29일 (UTC)[응답]
• 지원 - CC0은 우리가 생각해 낼 수 있는 어떤 것보다 훨씬 더 잘 설계되어 있다.CC의 목표는 우리 자신의 목표와 매우 일치하기 때문에, 「브랜드」라는 것은 논현안 IMO이다.Mr.Z-man 00:24, 2010년 12월 1일 (UTC)[응답]
• 지지하다.커먼즈는 이미 최근에 이런 일을 했다.단, PD-self를 CC0으로 리디렉션하거나, 그렇지 않으면 PD-self를 CC0으로 대량 변환할 수 없다는 점에 유의한다(다른 것 중, CC0은 인접 권리를 포기한다).물론 CC0 매체는 이곳이 아닌 커먼스에 업로드되어야 하지만, 일부 신참 사용자들은 기여하기 위해 다른 위키로 이동하는 것을 불편해 한다.Dcoetzee 01:49, 2010년 12월 1일 (UTC)[응답]
• 내가 본 주요 이슈는 CC-0이 무엇을 의미하는지 아는 사람은 극소수지만 그들은 아마도 공공영역에 대해 들어본 적이 있을 것이라는 것이다.그러나 그것은 많은 나라에서 공공영역에 무언가를 공개하는 것이 불가능하다는 장점을 가지고 있다.그리고 풀려날 수 없는 도덕적 권리는 그것이 어쨌든 면허증인지 여부에 적용된다.Graeme Bartlett (대화) 09:39, 2010년 12월 1일 (UTC)[응답]
• 지원하지만 배후와 유사한 이유로 리디렉션(또는 "기술적"이 되고자 하는 경우 "뒤집기")만 할 수는 없다는 점을 유념하십시오.{{GFDL-with-disclaimers}}(즉, 법적 이유로) PD는 cc-0과 정확하게 동일하지 않기 때문이다.또한 cc-0의 문구는 누구나 발명한 권리도 그에 의해 포기될 정도로 되어 있다.--NYKevin @771, 즉 17:29, 2010년 12월 3일 (UTC)[응답]
• 지원 개념, 하지만 이 업로드를 커먼즈로 보내야 하지 않을까?!?！??ɥʇM0N0^farewell 23:34, 2010년 12월 9일 (UTC)[응답]
  • 됐어. 물론 사람들이 하원에 직접 업로드해야 하지만 그게 훨씬 더 큰 문제야.멀티칠 (대화) 18:01, 2010년 12월 18일 (UTC)[응답]

개방형 플라크 통합

나는 이것이 이것을 놓기에 가장 좋은 장소인지 잘 모르겠다: 그것은 RFC로서 더 나을지도 모르지만 나는 여기서부터 시작해서 그것이 어디로 가는지 볼 것이다.

나는 Open Plaques 뒤에 있는 오픈 소스 코드베이스의 개발자로, 영국(그리고 점점 더 다른 곳에서도) 건물들에 부착된 기념 명판의 공공 도메인 데이터베이스다.개방형 플라크 데이터베이스의 각 사용자는 위키백과(en)에 대한 링크를 갖고 위키백과의 레드를 재사용하는 경향이 있다.우리는 또한 DBpedia로 연결하기 위해 RDFA를 사용하고 있다.

어제 런던 위키미디어 미팅에서, 나는 F with과 어떻게 하면 오픈 플레이크와 위키피디아를 더 많이 연결할 수 있을지에 대해 토론했다.내가 조사하는 한 가지 방법은 Open Plaque가 Commons의 이미지를 어떻게 재사용할 수 있는가 하는 것이다: 우리는 Flickr에서 Creative Commons의 허가된 이미지를 사용하지만, 우리는 또한 Commons의 이미지를 사용하기 시작할 수 있고, 또한 사람들이 그 사이트에 바로 업로드 할 수 있도록 허용하기를 원할 수 있다. 이 경우, 우리는 그 이미지들을 어떤 것이 아니라 Commons에 저장하는 것을 고려할 수 있다.직접 호스트하거나 Flickr 계정을 얻어야 한다.

우리가 통합할 수 있는 다른 방법은 링크를 통해서입니다.우리는 이미 위키피디아에 접속하고 있다.그리고 토마스 터너(다이아리스트)와 호크허스트(그리고 다른 사람들)는 오픈 플라크와 연결된다.나는 오픈 플레이크 커뮤니티가 봇을 만들어 위키백과에 기여할 수 있을 것이라고 제안하고 싶다: 기본적으로, 이 봇은 새로운 사람이 우리의 데이터베이스에 추가될 때마다 위키백과 기사에 오픈 플레이크 링크를 추가할 것이다.문제의 기사를 편집하는 커뮤니티에서 부적절하다고 느꼈다면 이는 삭제될 수 있다.우리는 id로 특별히 링크할 수 있는 템플릿을 가질 수 있고, 우리의 데이터베이스가 변경되면 쉽게 업데이트될 수 있다.

이것이 적절한지, 아니면 위키피디아나 위키피디아에서 대체적으로 공감대를 구하는 데 어떻게 나아가고 있는지 모르겠으니, 이런 종류의 것이 실용적이고 바람직한 것인지에 대한 조언을 듣고 싶다.미리 고맙다.—톰 모리스 (대화)20:23, 2010년 12월 13일 (UTC)[응답]

봇을 사용할 때의 문제는 올바른 기사가 명판에 연결되어 있는지 확인하기 위해 인간의 개입이 필요할 수 있다는 것이다.예를 들어, 오픈 플라크는 제임스 왓슨을 위한 항목이 있고 영어 위키백과는 제임스 왓슨이라는 이름을 가진 사람들을 위한 17개의 기사, 제이미 왓슨을 위한 2개의 기사, 그리고 짐이나 지미 왓슨을 위한 8개의 기사를 가지고 있다.그것은 잘못된 연결을 만들 수 있는 많은 잠재력이다.물질의 양이 정말로 봇을 만들고 유지하는 것을 정당화하는가?매달 얼마나 많은 새로운 사람들이 당신의 데이터베이스에 추가되나?아마도 링크를 만들기 위해 인간을 사용하는 것은 데이터의 질을 교차 점검할 수 있는 유용한 기회를 제공할 것이다. - 점술가 (대화) 22:14, 2010년 12월 13일 (UTC)[응답]

응답해줘서 고마워.우리는 우리가 링크하는 사람이 올바른 사람인지 확인하기 위해 우리 쪽의 인간을 이용한다!내부적으로는 각 개인에 대한 위키백과 URL을 저장하여 눈에 보이는 링크에 모두 사용하며, 레드를 안으로 끌어당겨 DBpedia에 연결한다.오히려 위키백과 커뮤니티에서 듣고 싶은 질문은 다음과 같다.

1. 우리 둘 다 '열린 콘텐츠' 자료를 생산하고 있다는 점을 감안할 때, 오픈 플레이크에 기사에 링크를 추가한다면 스팸메일로 간주될 것인가?

2. 그렇지 않다면, 그러한 링크를 자동으로 추가할 수 있는 봇을 만드는 것이 허용될 것인가?

(1)에 대한 대답이 예, 괜찮다면, 우리는 하지 않을 것이다.우린 얼간이처럼 되고 싶지 않아!하지만 우리가 링크를 추가해도 괜찮다면, 우리는 소프트웨어에 작은 콜백을 추가하는 것이 쉬울 것이다. 그것은 봇 계정에서 나온 것처럼 봇이 관련 위키백과 기사를 자동으로 편집하기 위해 줄을 서게 될 것이다.우리는 봇을 갖는 것이 더 쉬울 것이다. 왜냐하면 우리는 지역사회에 있는 누군가가 위키백과 기사에서 링크를 걸어오는 것을 기억하지 못하게 하는 것에 의존하지 않을 것이다.—톰 모리스 (대화) 22:21, 2010년 12월 13일 (UTC)[응답]

(2)는 일반적으로 WP:BRFA를 통해 결정된다. --Cybercobra(토크) 08:15, 2010년 12월 14일 (UTC)[응답]

커뮤니티가 이러한 링크를 원하고 봇이 추가하기를 원하는지 아니면 BAG가 토론을 위해 질문을 다시 여기로 보낼 수도 있고 지금 결정해야 한다는 점에 유의하십시오.Anomie⚔ 13:28, 2010년 12월 14일 (UTC)[응답]

명패의 본문에도 저작권 문제가 있다.예를 들어, Commons는 저작권 상태가 의심스럽기 때문에 더 많은 판권 이미지를 버리는 것을 심각하게 고려하고 있다.명심해야 할 것.—DJ (대화 • 기여) 2010년 12월 18일 (UTC) 15:46[응답]

대화형 테이블

나는 미디어위키 소프트웨어가 테이블의 상호작용이 가능하도록 업그레이드를 구현하는 것이 크게 개선될 것이라고 생각한다.내가 어떤 종류의 프로필로 정의된 일부 행과 열을 표시하거나 숨길 수 있는 기능에 대해 생각하고 있다고 말할 때.이 목록을 예로 들어보자: 인구별 국가 목록.예를 들어 대화형 표는 사용자가 필요로 할 때 단일 대륙의 국가를 표시하고 다른 대륙으로부터 숨길 수 있다.또한 사용자가 예를 들어 각 대륙에서 처음 5개국을 볼 수 있도록 돕는다.당신이 누군가와 대화를 할 때, 당신은 표에 있는 일부 데이터만 보여주고 싶을 수 있다. 그러므로 당신은 4,5와 6열은 당신의 토론과 관련이 없기 때문에 그것들을 숨길 수 있기를 원한다.프로파일링 테이블은 일부 필터(단순하거나 정교함)를 추가하거나 각 프로파일을 수동으로 정의하는 것을 의미한다.그러나 소프트웨어에서 구현되는 것은 프로그래머들에게 광범위한 작업을 요구하지 않을 것이며, 또한 브라우저에 JavaScript를 너무 많이 로딩하지 않을 것이라고 생각하지만, 데이터가 제공되고 이용될 수 있는 방법에 대한 대규모 개선은 확실하다.고마워요.— Arc25 (대화) 03:17, 2010년 12월 16일 (UTC)[응답]

누군가가 현재 http://tablesorter.com을 새로운 버전의 MediaWiki에 통합하는 작업을 하고 있는데, 이것은 우리의 이전 테이블포트 코드를 대체하기 위한 것이다.당신이 하고 싶은 일은 기사가 아니라 내 생각에 데이터베이스로 가는 것이 더 적합하다.여기서 시멘틱 미디어위키가 해답이 될 수도 있지만 SMW는 미공개 코드가 많고 우리의 캐싱 서비스와 시스템 부하에 막대한 영향을 미칠 잠재력이 있다(적어도 지난번에 조사해봤을 때).—DJ (대화 • 기여) 2010년 12월 18일 (UTC) 15:38[응답]

참고 목록과 같은 스타일링 <레퍼런스 />

참고 항목: #참조 목록에서 20개 이상의 열 권장

미디어위키 변경 제안:Common.css <참조 />가 {{Reflist}}}과(와) 동일한 스타일링을 갖도록 한다.이를 통해 표준화가 보장된다.이렇게 하면, 페이지가 {{Reflist}}의 고급 옵션을 필요로 하지 않는 한, <참조 />와 {{Reflist}} 중 어느 것을 사용하는지 형식에 상관없다.이에 대한 토론은 2주 동안 열려있었고 강력한 의견 일치를 보였으며, 활동 부족으로 자동 보관되었다: 위키백과:Village_pump_(proposals)/Archive_67#Change_template:reflist_fontsize_wiki-wide.3층. 스타일 변경은 무엇을 수반하는가?참조 섹션을 만드는 것은 90% 글꼴 크기로 일관되게 표시된다.이제 새로운 가젯 "Infoboxes, Navboxes 및 Reference 목록과 같은 요소의 더 작은 글꼴 크기 사용 안 함"을 출시했다는 점에 유의하십시오(MediaWiki:Gadget-NoSmallFonts.css).Rd232 12:34, 2010년 12월 13일 (UTC)[응답]

• 지지하다.가장 건전하고 논리적이며 합리적이고 합리적인 아이디어. -- Cirt (대화) 12:57, 2010년 12월 13일 (UTC)[응답]
• 다른 스레드의 이전 코멘트별 지원 --Errant 13:03, 2010년 12월 13일(UTC)[응답]
• 주어진 이유에 대한 지원.일관성이 좋다. — Edokter • Talk • 13:42, 2010년 12월 13일 (UTC)[응답]
• 질문 이것은 이미 공감대를 얻는다...왜 이 새로운 RfC가 필요한가?헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 12월 13일 (UTC) 14:05, 응답
  • 실제로 변경을 하는 것은 AN에 대해 제기되었고 RFC의 형태로 더 많은 입력이 필요하다는 의견이 제시되었다(나는 동의하지 않지만, 당신은 간다) --Errant 14:10, 2010년 12월 13일 (UTC)[응답]
  • 사이트 전체의 변화이기 때문에, 비록 사소한 변화일지라도, 나는 "왜 아무도 나에게 물어보지 않았지?"라는 변경 후의 너무 많은 변화는 없을 것이라고 확신하고 싶었다.Rd232 14:13, 2010년 12월 13일 (UTC)[응답]
• 질문 이 스타일링이 변경되는 경우 어떻게 해야 하는가?<references />비전문가의 참고자료를 보여주려고?아니면 내가 더 이상 그렇게 할 수 없다는 의도가 아닐까?— JohnFromPinckney (대화) 14:35, 2010년 12월 13일 (UTC)[응답]

IIUIC, 퍼팅

ol.dll { font-size: 100%!중요

사용자:JohnFromPinckney/vector.css(벡터 스킨을 사용한다고 가정할 때)가 이 작업을 수행해야 한다.—EmilJ. 15:00, 2010년 12월 13일 (UTC)[응답]

위에서 말한 바와 같이, 이것을 하기 위한 가젯이 있다.가젯 아래의 기본 설정에서 "Infoboxes, Navbox 및 Reference 목록과 같은 요소의 작은 글꼴 크기 사용 안 함"을 확인하십시오.Rd232^talk 15:32, 2010년 12월 13일 (UTC)[응답]

사용자가 원하는 것이 될 수도 있고 아닐 수도 있지만, 그는 infobox나 navbox에 대해 아무 말도 하지 않았다.—EmilJ. 15:57, 2010년 12월 13일 (UTC)[응답]

맞아, 하지만 이 장치가 그런 식으로 작동하는 이유는 10% 더 작은 리프를 좋아하지 않으면 다른 작은 것도 좋아하지 않는다는 가정 때문이지.일반적으로 그렇지 않다면 가젯을 분할해야 할 수도 있다(가젯에는 옵션이 있을 수 있다).Rd232 19:20, 2010년 12월 13일 (UTC)[응답]

그 아이디어는, 편집자가 명시적으로 지정한 경우를 제외하고, 참조는 기본적으로 모두 같은 크기여야 한다는 것이다.고려하다

현재 기사가 서로 일관성이 없기 때문에(어떤 것은 정상적인 참고문헌을 가지고 있고, 어떤 것은 참고문헌이 작기 때문에) <참고문>과 {{reflist}}이 정확하게 같은 결과(소규모 참고문헌)를 준다는 생각이다.만약 당신이 하이브리드 케이스와 같은 것, 즉 정상적인 크기의 "해설"과 작은 크기의 적절한 참조가 있기를 원하는 것이 걱정된다면, 그것은 {{reflist group=nb size=normal}}과 같은 것에 의해 달성될 수 있다(아직 구현되지 않았지만 추가하는 것은 사소한 것일 것이다).작은 크기 참조를 전혀 읽지 않으려는 경우 사용자 기본 설정에서 이 항목을 설정하십시오.헤드폭탄 {토크 / 기여 / 물리학 / 책} 15:06, 2010년 12월 13일 (UTC)[응답]

(붕괴된 상자는 제안된 90% 대신 작은 참조의 글꼴 크기를 88%로 줄임) — Edokter • Talk • Talk • 2010년 12월 13일 (UTC)[응답]

문제는 대부분의 위키백과 사용자들이 css 파일을 편집하는 방법을 모른다는 것이다.이용이 쉽고 열람이 용이한지에 따라 머물거나 떠나게 된다.레이스패킷(토크) 17:36, 2010년 12월 13일 (UTC)[응답]

그들은 CSS 파일을 편집할 필요가 없다 - 원하는 대로 가젯이 있다.그렇지 않다면, 90%가 우리가 전혀 사용하지 말아야 할 정도로 나쁘다고 생각한다면(특히, 로그인하지 않은 독자들을 염두에 두고), 다른 방법을 표준화하기 위한 대체 제안을 하라: 참조와 같은 스타일링 reflist/, 100%.Rd232 18:33, 2010년 12월 13일 (UTC)[응답]

{{reflist}}에 내장된 "size=normal" 매개 변수가 없을 것이다.일관성의 요점은 표준으로부터의 일탈은 없을 것이라는 것이다. — Edokter • Talk • 21:29, 2010년 12월 13일 (UTC)[응답]

일관성은 둘 중 하나일 필요는 없으며, 언제 사용할 수 있는지를 제안하는 스타일 가이드(누군가가 오래된 스타일을 선호하기 때문만이 아니라 특정한 이유를 제시함)와 함께, 여기서는 여전히 제한적인 예외를 허용할 수 있다.Rd232^talk 21:33, 2010년 12월 13일 (UTC)[응답]

그러한 예외는 아마도 처음에 {{reflist}}을(를) 사용하지 않아야 한다. — Edokter • Talk • 22:06, 2010년 12월 13일 (UTC)[응답]

포괄적인 사례에 감사한다.내가 우려하는 것은 하이브리드 케이스에 접근하는 것이 아니었는데, 나는 그것이 바람직하다고 보지 않는다(페이지 내에서는 일관성이 없고 보통보다 작은 텍스트를 포함한다).나는 정말로 내가 어떻게 기사에 참조를 추가할 수 있는지 알아내려고 노력했다. 그래서 그들 둘 다나 세 명 모두가 읽기 쉬운 크기로 되어있는지, 나를 위해서가 아니라, 그 위키백과 페이지의 모든 독자들을 위해.

50개 이상의 리프가 있는 기사는 다소 작은 리프 리스트에서, 그리고 내가 사용하거나 유사한 리프 리스트에서 이익을 얻는다는 것을 이해하고 수용한다.그러나 한두 개의 참고문헌이 있는 기사는 축소된 참조문헌을 필요로 하지 않으며, 위키백과의 표준 글꼴 크기는 AIUI로, 이미 사용자의 기본 글꼴 크기의 100% 미만이다.나는 WP에 다음과 같은 진술이 있다고 생각했다.풀사이즈 텍스트에 대한 액세스 권한은 있지만, 지금은 보이지 않는다.

분명, 하지만, 그 합의는 이미<references />WP에서 동일한 크기의 결과를 도출해야 하며, 여기서 논의되는 내용은 단지 어떻게 하면 그러한 결과를 부정하지 않고 실현시킬 수 있는가 하는 것이다.<references />즉시 봇이 그것을 Reflist로 대체하도록 한다.템플릿의 설명서:Reflist#Font size는 어떤 경우든 기한이 지난 것으로 보이며, 늦어도 이 제안이 채택될 때 변경될 필요가 있다.— JohnFromPinckney (대화) 22:27, 2010년 12월 13일 (UTC)[응답]

• 이전 제안에서 이미 언급한 바와 같이 지원.—Emil J. 15:00, 2010년 12월 13일 (UTC)[응답]
• 지지 - Mmm 일관성.Ajraddatz (토크) 15:01, 2010년 12월 13일 (UTC)[응답]
• 지원 - 표준화 시작shoy (reactions) 15:09, 2010년 12월 13일 (UTC)[응답]
• 그래, 그럴 때가 됐군—erzhiki(Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2010년 12월 13일; 15:36(UTC)
• 지원 가져오기. 마차 (대화) 15:44, 2010년 12월 13일 (UTC)[응답]
• 반대: 작은 글꼴 크기로 짧은 참조 목록을 읽기 어렵게 만들 이유는 없다.위키피디아의 san serif 체형은 이미 읽기 어렵다.레이스패킷(대화) 16:35, 2010년 12월 13일 (UTC)[응답]
  • 10%만 작을 뿐이고, 사용자 한 명당 전원을 끌 수 있다.그리고 위의 Headbombum의 제안에 따라 {{Reflist}}도 새롭게 선택적 파라미터를 부여하도록 변경하여 특별히 필요한 곳에 100% 사이즈를 사용할 수 있도록 해야 한다.Rd232 18:30, 2010년 12월 13일 (UTC)[응답]
• 서포트 음, 정말 일관성이 있다.2010년 12월 13일 (UTC) 19:11, Der Wohltemierte Fuchs^(talk) (UTC)
• 서포트 일관성은 사랑스러울 것이다, 그렇다.—chaos5023 (대화) 19:40, 2010년 12월 13일 (UTC)[응답]
• 서포트 일관성이 좋다.비행기 승무원 ✈ 19:53, 2010년 12월 13일 (UTC)[응답]
• 지원 지난번과 동일한 이유:이 경우 일관성이 더 좋다. --Cybercobra (대화) 20:06, 2010년 12월 13일 (UTC)[응답]
• 일관성 지원.구구오12--토크--21:08, 2010년 12월 13일 (UTC)[응답]
• 지원 - 포인트리스트 (대화) 21:34, 2010년 12월 13일 (UTC)[응답]
• 지원 시간 전에는 안 된다. 론존스 22:56, 2010년 12월 13일 (UTC)[응답]
• 지원:모든 위키백과 기사에 걸쳐 참조 목록에 일관성이 있어야 한다.그것은 단지 좀 더 전문적이다.내 생각에는 개별 사용자가 내 사전 설정 페이지에서 참조 리스트에 대해 선호하는 글꼴 크기({reflist}} 또는 <reference/> 형식)를 설정할 수 있어야 한다.이렇게 하면 참조 목록 글꼴 크기에 비해 이 모든 어리석음이 해결되며, 기사의 "설립된 스타일" 문제도 해결되기를 바란다.[ 레트로00064 ▷인터뷰> 23:56, 2010년 12월 13일 (UTC)[응답]
• 지지 나는 이것이 아직 이루어지지 않았다는 것이 놀랍다. 그것에 대한 다른 논의들을 고려할 때.예. EVULA // talk // ☯ // 00:03, 2010년 12월 14일 (UTC)[응답]
• 참고문헌 섹션에는 또한 많은 참고문헌 섹션이 <참조문헌/> 출력물에 따른 글머리표도 포함되어 있는데, 글꼴 크기가 변경되면 섹션 전체에 걸쳐 동일한 크기를 유지하려면 {{Refbegin} & {{Refend}}로 포장해야 한다.키스 D (토크) 00:06, 2010년 12월 14일 (UTC)[응답]

• 질문 이것이 잘못된 포럼일 수도 있는 멍청한 질문이 무엇이냐고 물어봐서 미안하지만, (이 제안에서 제시된 바와 같이) {{reflist}}}이(가) <참조>보다 우월하다면 왜 후자는 (기존 이유를 넘어서) 여전히 선택사항인가.편집자로서 왜 참고문헌에 대한 두 가지 선택지가 있는지 내게는 항상 혼란스러웠다.Ajbpearce (대화) 00:07, 2010년 12월 14일 (UTC)[응답]
  • 답변: <참조/> 태그는 MediaWiki 소프트웨어가 참조 목록으로 번역하는 표준 미디어위키 마크업입니다(<ref>와 마찬가지로...</ref> 태그는 소프트웨어에 두 태그 사이의 텍스트가 참조임을 알리는 데 사용된다.<참조/>는 내가 아는 한 맞춤식 옵션을 지원하지 않는다.그러나 {{Reflist}}은 사용자 정의 가능한 옵션을 지원하는 템플릿으로 참조 목록의 서식에 유연성을 부여한다.[ Retro00064 ▷인터뷰> 2010년 12월 14일 (UTC) 00:44[응답]
  • 답변: 그래, (생각해) 그건 이해하지만, 단순히 봇에 의해 쫓기고 엔위키에 있는 더 다재다능한 {{Reflist} 템플릿으로 대체되는 <참조/>의 예들이 있는 것은 아닐까?Ajbpearce (대화) 01:16, 2010년 12월 14일 (UTC)[응답]
    • 답변: 당면한 이 문제에 대한 한 부분/논의({Reference/>{Reflist}}와 동일하게 만드는 것)는 "개별 기사에 확립된 스타일"의 주장이다.사람들이 모두 <참고/>를 {{Reflist}}로 대체하는 것에 동의하고 동의하지 않는다는 것은 그것이 합의 없이 전자의 모든 인스턴스를 후자로 대체하는 것은 받아들일 수 없다는 것을 의미했다.이 제안에 따른 최종 합의에 따라 <참조/>의 모든 인스턴스를 {{Reflist}}(으)로 대체하는 것이 좋을 것이다.[ Retro00064 ▷인터뷰> 2010년 12월 14일 (UTC) 01:38 [응답]
      • 여기서 제안된 변경사항이 이루어진다면, "{reflist}}"를 "{reflist}}"로 대체할 이유가 없을 것이다.CSS를 통해 변경해야 하는 이유는 모든 페이지를 편집할 필요가 없기 때문이다.그러나 이 제안의 근본적인 문제는 외모가 같아야 하는지를 결정하는 것이다. 표준화에 대한 편집자의 의견은 어떤 의미에서 내려온다.— 칼 (CBM · talk) 01:45, 2010년 12월 14일 (UTC)[응답]
      • 그래, 도움이 되는 답장 고마워.Ajbpearce (talk) 18:27, 2010년 12월 14일 (UTC)[응답]의 가치에 대해 지금 그 변화를 지지하십시오.
• 댓글을 달다.기본 피부(벡터)에서 {{reflist}}}은(는) 더 작은 텍스트와 컬럼을 주지 않고 </참조>가 주는 것과 정확히 같은 것을 주는 것을 눈치챈 사람이 있는가?펜스&윈도우즈 00:19, 2010년 12월 14일 (UTC)[응답]

그래, 그걸 알아차렸고, 사실 벡터가 도입되었을 때 이슈로 제기했었지.어떤 사람이 내가 사용자 구성 파일 중 하나에 추가한 수정 사항을 가리켰는데, 이 수정은 작은 유형을 복원하지만, 물론 로그인할 때만 복원된다.흥미가 있으면 돌아가 실과 고정을 찾겠다. --Tryptofish (토크) 00:35, 2010년 12월 14일 (UTC)[응답]

사실, 글꼴은 작지만, 비호감적일 수 있다.기본 글꼴이 있는 Windows의 경우 90%는 글자 간격이 좁고 대문자가 작아지는 반면 소문자는 기본적으로 동일한 크기로 유지된다. — Edokter • Talk • 2010년 12월 14일 (UTC)[응답]

아, 맞아.Drat, 나는 정말 더 작은 것이 좋아.그러나 어떤 일이 있어도 일관성은 내 개인의 취향을 능가한다. --Tryptofish (토크) 01:54, 2010년 12월 14일 (UTC)[응답]

나는 위에서 벡터 아래 스스로 글꼴 크기를 표시하는 방법을 바꿀 수 있는 방법이 있다고 언급하였다.이 구성은 로그인할 때 보는 방식에만 영향을 미치며 나머지 국가의 보기에는 영향을 미치지 않는다는 점에 유의하십시오.그러나 대형 또는 소형 글꼴 디스플레이를 개인적으로 선호하는 경우, 원하는 비율의 비율로 Vector.css 파일에 다음과 같이 입력하십시오.

/* {{reflist}}*/ .reference-작은 {글꼴 크기: 88%;}의 글꼴 크기 설정

--Tryptofish (대화) 21:17, 2010년 12월 17일 (UTC)[응답]

• 지지하다.공교롭게도 F&W는 이 질문에 대해 내가 가장 관심을 갖는 이슈에 대해 정확히 질문했을 뿐이다.벡터(Vector)를 사용하면, 하나의 (컴퓨터?)로부터 훨씬 더 큰 불일치가 있는 것 같다.운영 체제?비디오 드라이버? 브라우저?달의 위상?)을 다른 위상으로.그렇다, 일관성이란 바로 우리가 원해야 할 것이다. 그리고 이 제안은 벡터의 모순을 고칠 수도 있다.해보자! --Tryptofish (대화) 00:35, 2010년 12월 14일 (UTC)[응답]
• 다시 지원하다.이전 토론에서 언급했듯이, 나는 축소된 크기의 언급이 혐오스럽다고 생각하며, 다른 모든 사람들도 그래야만 한다고 생각한다.글꼴 크기를 줄인다는 일부 편집자의 믿음을 재조명하는 데 사용되는 모든 변형을 제거하지 않고는 적절한 참조 서식을 얻을 수 없기 때문에, 나는 이 필요한 첫 단계를 지지한다.— 가비아 임머 (대화) 01:05, 2010년 12월 14일 (UTC)[응답]
• 나는 그 변화를 지지한다.나는 일반적으로 가비아 몰입에 동의하지만, 시간이 지날수록 각주를 표시하는 두 가지 방법의 차이를 갖는 것이 덜 지속가능해지고 있으며, 모든 스타일을 하나의 CSS 클래스로 옮기는 것이 유리하다고 생각한다.— 칼 (CBM · talk) 01:41, 2010년 12월 14일 (UTC)[응답]
• 변화를 지지하다.벡터에 대한 불평에 대해서는, 왜 누가 그것을 사용했는지 이해할 수 없다.벡터보다 더 많은 걸 방해한 피부를 본 적이 없어그것은 당신의 생산성과 탐구를 방해하기 위해 만들어진 것 같다.그리고 그건 엉덩이 못생긴 것 외에. -- ۩ 마스크 03:19, 2010년 12월 14일 (UTC)[응답]
• 이것들을 지원하면 서로 같은 결과가 나와야 한다. -- 지우개헤드1 <토크> 08:38, 2010년 12월 14일 (UTC)[응답]
• 지지하다.이전 논의에도 뚜렷한 공감대가 형성됐다.Reflist가 본문을 너무 작게 만든다는 이유로 유일한 이의는 제기되었다.여기서의 목적이 단순히 표준화이기 때문에 그것은 곁가지 반대인 것처럼 보인다 - 만약 Reflist가 텍스트를 너무 작게 만든다는 진정한 우려가 있다면, 그것은 일반적으로 인용문 서식에 접근하는 방법에 대한 토론이다. 이러한 위키 코드가 병합되지 않더라도 텍스트 크기 문제는 남을 것이기 때문이다(Reflist가 널리 사용됨).그리고 만약 그 코드가 병합되지 않는다면, 그것은 전쟁 편집의 가능성을 열어놓게 되는데, 이것은 부적절하다.병합해 봅시다. 나중에 누군가가 원한다면 인용문 서식에 대한 접근성 문제에 대한 별도의 논의를 시작할 수 있을 겁니다.실크토크 ^YES!* 2010년 12월 14일 (UTC) 11:36[응답]
• 지원 - 모든 위키백과 기사에 걸쳐 더 균일하게 보이도록 한다.2010년 12월 14일(UTC) 오드 미셰후 11:56[응답]
• 지지하다.참고문헌의 표시를 표준화하는 것이 좋은 생각이다, IMO. Kaldari (토크) 02:50, 2010년 12월 16일 (UTC)[응답]
• SilkTork의 추론에 따라 지지하십시오.디데롯의 꿈 (대화) 02:58, 2010년 12월 16일 (UTC)[응답]
• 반대 우리가 마지막으로 해야 할 일은 이미 작은 글꼴 크기를 훨씬 더 많은 장소에서 작게 만드는 것이다.우리는 지금 정말 반대로 해야 한다: {{Reference}} 표시는 100% 글꼴 크기로 만든다.access_denied (대화) 03:12, 2010년 12월 16일 (UTC)[응답]

• 그래서 더 큰 텍스트를 볼 필요가 있는 사람들을 위한 장치가 있는 것이다.90%는 극히 작지 않다. 많은 도서 및 기타 출판물에서도 본문보다 작은 각주. /ƒETECCOMMS/16:31, 2010년 12월 16일 (UTC)[응답]

• 지지하다.일관성.글자 크기로 본문 텍스트와 참조를 구분하는 것은 인간공학적이다. 샌드스타인 07:29, 2010년 12월 16일 (UTC)[응답]
• 지원, 진작에 했어야 했는데.마법사맨 18:58, 2010년 12월 18일 (UTC)[응답]
• 지원, 큰 발전이 있을 것이라는 데 동의한다. --쿠미오코(토크) 02:26, 2010년 12월 20일 (UTC)[응답]
• 지원, 일관성 최고 품질 : TelCoNaSpV : 02:36, 2010년 12월 20일 (UTC)[응답]
• 지원, 둘 다 마음에 든다 - 일반적으로 일관성과 작은 각주/참조.---reo 18:47, 2010년 12월 20일 (UTC)[응답]
• 일관성을 위한 지원. ----- CharlesGillingham (대화) 21:01, 2010년 12월 20일 (UTC)[응답]
• 반대는 오히려 모든 텍스트를 보통 크기로 만든다.WP는 종이가 아니므로 참조를 짜낼 필요가 없다.읽을 수 없는 참고문헌은 참고문헌이 없는 것보다 거의 낫지 않다.접근성에 따라 문서 텍스트와 동일한 크기로 만들어야 한다.Rich Farmbrough, 01:21, 2010년 12월 22일 (UTC)
  [답글]

구현 이후

나만 그런가, 아니면 편집이 세 개의 컬럼을 모두 가지고 {{Reflist colwidth=30em} no-longer 함수 결과를 얻었는가?얼마나 많은 사람들이 이 기능을 가진 브라우저를 사용하는지는 확실하지 않지만, 이것이 해결되어야 한다고 생각한다.뜸(토크) 2010년 12월 21일 (UTC) 18:12, 응답

글꼴 크기가 더 큰 경우 캐시를 삭제하십시오. — Edokter • Talk — 22:39, 2010년 12월 21일 (UTC)[응답]

질문

벡터 피부는 작은 활자를 혐오한다는 말을 다른 곳에서 들었다.그래?만약 그렇다면 왜 모노북이 같은 방식으로 일하게 하지 않는 걸까?Rich Farmbrough, 01:27, 2010년 12월 22일 (UTC)
[답글]

도움말:Talkspace

최근 스레드에서 영감을 받아 도움말을 작성했다.도움말에서 수정된 토크 공간 초안:사용자 공간 초안.약간의 개선점을 사용할 수 있지만, 나는 기본적인 생각이 명확했으면 좋겠어.사람들은 어떻게 생각하는가?Rd232 15:30, 2010년 12월 13일 (UTC)[응답]

나는 이 부분이 마음에 들지 않는다. "...기사 자체에서 시행되는 것, 위키피디아에 페이지를 나열하라.관리자(admin)가 사용할 수 있도록 이동 수리 홀딩 펜을 잘라 붙여 넣으십시오..." 본질적으로 여러 사용자 초안이 병합될 경우 비논리적 기록이 생성될 수 있다.(MediaWiki가 git 등의 버전 제어 시스템처럼 "신속한 분기 및 병합"을 지원하지 않는 것은 유감스러운 일이다.)최소한 가능하다면 이런 유형의 초안은 피하고, 초안이 필요한 경우에만 a) 편집 요약에 일부 "초안 ID"를 추가하여 필요할 때 쉽게 이력을 재구성할 수 있도록 하거나, b) 메인 토크 페이지나 편집 요약에 모든 관련 사용자를 나열하고, 이력을 병합하지 않는다.장기적으로는, 편집이 복수의 사용자에게 귀속되도록 허용하고, 초안이 병합된 후 자동 보호되는 초안 페이지로 원활하게 연결되도록 하는 등, 보다 나은 추적 초안을 개선해야 한다.2010년 12월 13일 (UTC) 21:39, 응답하십시오.

그래, 내가 그걸 바꿨어. 그래서 설명서에 복사해서 편집 요약에 있는 초안 페이지에 영구적인 링크를 제공하라고 했어.이제 알겠지?Rd232 21:44, 2010년 12월 14일 (UTC)[응답]

참고: Template_talk에서 이 기능의 특성/용도에 대한 관련 논의가 있다.Talkspace_draft.Rd232 22:58, 2010년 12월 21일 (UTC)[응답]

Redlinked 영상 및 삭제 로그

빨간색으로 연결된 이미지 링크를 클릭할 때 삭제 로그를 표시할 수 있는 방법이 없을까?파워스 14:03, 2010년 12월 15일 (UTC)[응답]

놓다importScript('User:Gary King/show upload deletion logs.js'); 사용자:LtPowers/벡터.js(또는 사용 중인 피부)—EmilJ. 14:22, 2010년 12월 15일 (UTC)[응답]

그것은 좋은 해결책이지만 나는 좀 더 통합된 솔루션을 원한다.파워스^T 14:44, 2010년 12월 15일 (UTC)[응답]

나도 그래. 적어도 관리자한테 돌려줄 수 있다면.그러나 일반 편집자에게도 삭제 로그는 즉시 업로드 화면보다 더 실용적으로 보인다.가리온96 (대화) 15:36, 2010년 12월 15일 (UTC)[응답]

이것은 기본적으로 1.16으로 깨진 것이었고, 1.17로 다시 고쳐져야 한다 —TheDJ (대화 • 기여) 15:41, 2010년 12월 18일 (UTC)[응답]

이것은 서버나 툴서버에 있어야 한다; 관리자로 로그인한 상태에서 임의 사용자 스크립트를 가져오는 것은 좋은 생각이 아니다. 67.117.130.143 (대화) 02:06, 2010년 12월 20일 (UTC)[응답]

계정의 기여를 단일 목록에 병합

어떤 목적을 위해, 반드시 다중 소크 행동을 더 잘 이해해야 한다. 여러 계정의 기여금을 단일 리스트로 통합하는 것이 도움이 될 것이다.소프트웨어가 어떻게 해서든 이것을 할 수 있다면 정말 좋을 것이다. 그러나 그 동안 도구 서버 도구가 이것을 하는 것은 그리 어렵지 않아야 한다: 여러 계정의 기여를 통상적인 날짜 순서에 넣고 다른 열에 서로 다른 계정과 함께 넣는다.아니면 이미 존재하는지도 모르고, 놓쳤는지도 모른다.Rd232 22:51, 2010년 12월 17일 (UTC)[응답]

기술적으로 그렇게 하는 것이 어렵지 않을 것이다(WHERE 계정 IN { list }). 그러나 잠재적인 양말-양말-양말-양말 패턴 검사를 위해 이 계정을 선택하려면, 선택할 계정의 목록을 직접 만들어야 한다.그러한 보고서가 IP 범위 파괴 행위와 스팸 발송 패턴을 식별하는 데 어떻게 도움이 되는지 알 수 있지만, 이와 같은 특징은 또한 사람들이 지금까지 가능했던 것보다 더 쉽게, 그리고 어쩌면 덜 선의적인 투자를 할 수 있게 만들 것이다. - 포인트리스트 (talk) 23:20, 2010년 12월 17일 (UTC)[응답]

이것은 도구 서버나 데스크탑에서 API 클라이언트로 구현하기 매우 쉬워야 한다.나는 그것이 정말로 서버에 넣을 가치가 있다고 확신하지 않는다.실제로 얼마나 자주 그런 것을 원하십니까? 67.117.130.143 (대화) 00:35, 2010년 12월 20일 (UTC)[응답하라]

음, 그것은 많은 양말 조사의 유용한 부분이 될 것이다.Rd232^talk 01:25, 2010년 12월 20일 (UTC)[응답]

양말 토론에서 계속 보고 있는 화려한 그래프와 차트의 수를 보면 이미 사용 중인 그런 도구들이 많을 것이다.그냥 개인적으로 그래프를 만드는 사람에게 연락해서 도구에 접근할 수 있는지 물어보는 게 가장 간단한 방법일 수도 있어.Per Pointillist, 나는 왜 그들이 일반적인 유통이 되지 않는지 이해할 수 있다. 67.117.130.143 (대화) 01:35, 2010년 12월 20일 (UTC)[응답]

이런 유형의 더 유용한 도구 중 하나는 위키스토크다.그것은 Mediawiki 도구 서버의 많은 버전에 존재한다.내가 사용하는 것을 봐. --Jayron32 21:45, 2010년 12월 20일 (UTC)[응답하라]

알아, 하지만 겹치는 페이지만 나열돼 있어.Special과 같은 모든 기여에 대한 시간/날짜/diff 세부사항을 제공하지 않는다.기부금은 그렇다.Rd232 10:26, 2010년 12월 21일 (UTC)[응답]

또한 그룹 활동을 이해하는 데도 유용할 것이다.Rich Farmbrough, 01:33, 2010년 12월 22일 (UTC)
[답글]

20개 이상의 참조 목록의 열 권장

내가 아는 한 참조 리스트에 열을 사용할지 안 사용할지, 그리고 어떤 (열 고정 집합, 예를 들면 고정된 열 집합)의 사용 여부는 명확한 권고사항이 없다.{{Reflist 2}}, 또는 유연한 집합(예:{{Reflist colwidth=30em}}). 물론 유연한 세트는 방문자의 모니터 크기에 맞는 열의 양만 표시할 수 있는 이점을 제공한다(즉, 모니터에 20+가 있는 사람은 4-5개의 열을 보는 반면 넷북에 10개가 있는 사람은 2개만 보게 된다는 것을 의미한다.칼럼의 이상적인 폭은 위키백과에서 논의되었다.위키프로젝트 사용성).그러므로 나는 WP에 부록을 제안하고 싶다.일반적으로 다음을 권장하는 CITE{{Reflist colwidth=30em}}(특정 기사의 편집자의) 지역 합의가 반대하지 않는 한, 20개 이상의 참고 문헌에 대해.—벤더235 (대화) 02:33, 2010년 12월 15일 (UTC)[응답]

• 그것은 합리적인 것 같다.나는 두 가지 관찰을 가지고 있다: 편집자들이 "colwidth=30em" 코드를 기억하는 것보다 Reflist에 "2"를 추가하는 것이 더 쉽다 - 코드를 단순화할 수 있는가?; 그리고 모든 편집자가 플렉시블 세트의 세부 기능인 템플릿의 지침을 알고 있는 것은 아니다.reflist#Columns는 "최소 폭 30m"의 기술적 재잘거림보다 유연성을 예측하는 위의 제안에 더 부합할 수 있다."페이지에 있는 참조의 평균 너비에 적합한 열 너비를 선택하십시오"라는 조언은 적절한 너비를 선택하는 방법을 설명하지 않기 때문에 대부분의 편집자의 머리 위로 쓸 것이다.지침이 더 명확하고 코딩 적용이 용이하다면 더 많은 편집자가 지침을 사용하고 있을 수 있다.실크토크 ^YES!* 10:01, 2010년 12월 15일 (UTC)[응답]

내가 생각하면서 가는 곳은 사람들이 이해할 수 있는 단어로 열 너비를 정의하기 위해 {{reflist concolumns}, {{reflist standard columns}}이(가) 있을지도 모른다는 것인데, 우리가 "30em"으로 특정한 너비 의미를 하드코딩하고 있지 않다는 이점이 있다.그것은 이해하기 쉽고, 표준화에 더 적합하며, 미래의 변화에 도움이 될 것이다.Rd232 13:51, 2010년 12월 15일 (UTC)[응답]

"편집자가 "colwidth=30em" 코드를 기억하는 것보다 "2"를 Reflist에 추가하는 것이 더 쉽다 - 코드를 단순화할 수 있는가?;"

그것은 이미 간소화되었다.입력할 수도 있다.{{Reflist 30em}}. ——bender235 (대화) 10:29, 2010년 12월 15일 (UTC)[응답]

내가 위키피디아를 위해 주로 사용하는 브라우저들 중 어떤 것도 여러 개의 열을 지원하지 않기 때문에, 나는 무엇이 적절한지, 어떻게 작동하는지 알 수 없다.그러나 내가 이용할 수 있는 다른 브라우저 중 하나를 사용하여 재점검을 하면, 이 브라우저를 사용하는 많은 경우들은 매우 추하게 나타난다.가장 두드러진 사용 사례 중 일부에서는 칼럼이 비활성화된 경우에도 대부분의 참조가 한 줄 이상이라 사용하기에 명백히 부적절하다.— 아서 루빈(토크) 10:34, 2010년 12월 15일 (UTC)[응답]

현대의 와이드스크린 디스플레이에서 25-40단어의 다중 행 참조 또는 참조 중 어느 것이 더 명백히 부적절한가?내가 관심 있는 참조서를 읽을 수 없다는 것은 매우 추한 일이다, IMHO. — JohnFromPinckney (토크) 11:09, 2010년 12월 15일 (UTC)[응답]

참조는 본문 텍스트와 거의 같으므로 사용자가 본문 텍스트에 만족하면 참조도 괜찮고, 그렇지 않으면 창을 축소하여 두 가지 모두를 수정한다.Rd232 11:29, 2010년 12월 15일 (UTC)[응답]

나는 특히 참조가 더 작은 글꼴 크기이기 때문에 전체 화면을 다루기 위해 좁고 여러 줄의 참조를 읽는 것이 훨씬 더 낫다고 생각한다.화면 22의 한 열 참조는 거의 읽을 수 없다.—벤더235 (대화) 12:55, 2010년 12월 15일 (UTC)[응답]

많은 줄에 걸쳐 작은 스크린을 표시하지 않는 편이 더 중요하다 - 대형 스크린에서는 창을 항상 작게 만들 수 있다(그리고 본문 텍스트가 칼럼에 포함되지 않아도 괜찮다면 참조도 크게 다르지 않다).Rd232^talk 13:05, 2010년 12월 15일 (UTC)[응답]

그것도 그렇고. 그것도 그렇고...—17:27, 2010년 12월 16일 (UTC)벤더235 (대화)

질문에 답하려면 한 걸음 물러서서 "주어진 기사에 대해 내 화면에서 보고 싶은 것이 무엇인가"라고 물어봐야 할 것 같다.그러면 우리는 다른 맥락에서 어떻게 다른 욕구/요구를 충족시킬 수 있는지에 대해 생각할 수 있다.참조가 몇 개만 있는 경우(i) 매개변수는 (i) 열이 없고, (ii) 대부분의 참조는 줄 바꿈이 안 되거나 적어도 2줄 이상 줄 바꿈이 되지 않아야 하며, (iii) 대부분의 참조는 열의 75%(더 많이?)를 차지해야 한다.게다가, 어떤 사람들은 칼럼을 전혀 좋아하지 않지만, 그것은 소수인 것 같고 사용자당 선호도 설정이 없다면 우리는 그것을 수용할 수 없다.

우리는 이 변수들을 야구장으로서 동의하는가?만약 그렇다면, 다음 질문은 어떻게 다른 맥락에서 그것을 성취할 것인가 이다.컨텍스트는 기본적으로 (a) 다른 화면 크기(작고, 전형적이고, 큼)와 (b) 다른 기준 스타일이며, 기본적으로 유형 A(표준 스타일, 대부분 상당히 긴 참조)와 유형 B(대부분 매우 짧은, 작성자(연간:페이지) 스타일 참조)이다.현재 상황은 기본적으로 A타입 참조에는 {{Reflist2}}, B타입에는 {{Reflist 3}}을 사용하는 것이다.이것은 일반적인 화면 크기에 적합하고 큰 화면 크기에 적합하다.이 접근방식이 실질적으로 떨어지는 곳은 작은 스크린으로, 화면은 작지만 2개의 기둥으로 고정되어 매개변수 ii(참고가 너무 많이 줄면 안 됨)는 모두 지옥으로 쏠리게 된다.대형 화면에서는 매개 변수 Ⅲ(너무 공백)를 깨게 될 수도 있지만, 이는 그리 심각하지는 않다.적절한 값으로 사용하면 이러한 문제를 해결할 수 있을 것이다. 일반적인 화면에서는 콜 너비=40em 작업을 {{Reflist2}}개에 해당하는 반면 작은 화면에서는 하나의 컬럼을 허용하고 큰 화면에서는 3개의 컬럼을 허용하고, 콜 너비=30em 작업을 {{Reflist 3}}에 해당하는 것으로 제안한다.이것은 아마도 더 많은 시험과 토론이 필요하겠지만, 나는 (만약 이것이 정확하다면, 그렇지 않을 수도 있다!) 고정된 열 개수보다 이러한 값을 가진 콜 너비의 사용을 권장하는 쪽으로 기울고 있다.Rd232 11:29, 2010년 12월 15일 (UTC)[응답]

나도 네 말에 동의해, 하지만 난 이렇게 말하고 싶어.{{Reflist 2}}실제로 와 같다.{{Reflist 30em}}, 한편{{Reflist 3}}로 대체되어야 한다.{{Reflist 20em}}. 예를 들어, 통가 작전에는 짧은 언급이 있고20em괜찮아—벤더235 (대화) 12:55, 2010년 12월 15일 (UTC)[응답]

음, 여기가 까다로운 곳인데...하지만 FWIW 나는 네가 옳다고 생각하지 않는다.각주에 20em을 사용하는 통가 작전에서는 1680년 화면에 완전히 6개의 열이 있다!Reflist 3과 거의 동등하지 않다.그렇긴 하지만, 거기에 있는 각주는 모두 B형이 짧고, 위에서 설명한 파라미터 i-iii를 존중한다는 측면에서 모든 크기에서 잘 작동하는 것 같다.그래서 B형 20em이 거의 맞을 수도 있지만 A형의 경우 30em이 너무 좁다고 생각한다.Rd232^talk 13:01, 2010년 12월 15일 (UTC)[응답]

그래서 아마 여기서 A형, B형, C형에 대해서 이야기를 하고 있을 겁니다.30em적절하다.사실 나는 이 제안의 표적이 된 권고안이 정확한 칼럼 너비에 대해 구체화 되어서는 안 된다고 생각한다.그 결정은 저자들에게 맡겨져야 한다.ref가 20개 이상인 경우에만 컬럼을 사용하도록 권장해야 한다.—벤더235 (대화) 13:14, 2010년 12월 15일 (UTC)[응답]

나는 C타입이 존재한다고는 보지 않는다. 그것은 기본적으로 짧은 형태의 참조(B), 표준적인 긴 형태(A), 또는 길고 중간적인 것(특히 불완전한 경우)의 혼합물로서, 혼합물이 매우 강하게 짧은 형태로 치우치지 않는 한 A로 취급해야 한다.Rd232 13:45, 2010년 12월 15일 (UTC)[응답]

• 응. 화면상이나 인쇄시 칼럼이 더 좋아 보이는 것 같아. --스모키조(토크) 11:53, 2010년 12월 15일 (UTC)[응답]
• 내 시스템에 따르면 "작은" 화면은 너비가 1122px 미만이고 "정상" 화면은 최소 1123px여야 한다(40m에서 두 열을 얻으려면 브라우저의 크기를 조정해야 하는 너비임).나한텐 좀 과한 것 같아.1024px 폭에서 최대 35em까지 사용할 수 있어 여전히 2개의 컬럼을 볼 수 있다.그러나 40em조차 1680px 폭의 설정에서 3개의 컬럼을 주는 것으로 알려졌는데, 일부에서는 이 컬럼이 너무 많은 것으로 보고 있다.여기 있는 모든 사람들을 만족시킬 만한 가치를 찾을 수 없을 것 같아.2010년 12월 15일 12시 15분(UTC)[응답]
  • 위의 매개 변수에 대한 논의에서, 나는 열을 전혀 좋아하지 않는 사람들을 제외하고, 선호되는 열 개수에 대해 아무 말도 하지 않았다.이건 의논할 사안인가?내가 위에서 언급한 다른 변수들에 어떤 영향을 미치든, 어떤 사람들은 2개 이상의 열을 갖는 것을 반대하는가?Rd232 12:55, 2010년 12월 15일 (UTC)[응답]

나 개인적으로는 중요한 숫자보다는 폭이다.좁은 기둥에 많은 짧은 참조가 잘 나타나며, 긴 참조는 더 넓은 기둥이나 심지어 어떤 기둥도 필요하지 않다(출처가 대부분 외국어로 되어 있고, 제작자가 각주에 번역을 넣고 있다고 말한다면) 도로의 엘렌 (토크) 13:31, 2010년 12월 15일 (UTC)[응답]

글쎄, 나는 대부분의 사람들이 칼럼을 전혀 좋아하지 않는 소수의 사람들 외에는 그렇게 생각한다고 추측했지만, 아노미 교수는 다른 가능성("너무 많은 칼럼")을 한 칼럼 안에 언급된 글들이 어떻게 보이는지와 별개의 문제로서 제기했다.Rd232^talk 13:42, 2010년 12월 15일 (UTC)[응답]

문제는 어떤 사람들은 50em보다 작은 기둥을 원하지 않지만 그들은 두 개의 50em 기둥을 맞출 수 있는 큰 1680px-screen을 가지고 있고, 다른 사람들은 같은 기사에 좀 더 정상적인 1024px 크기의 화면에 35em으로 괜찮고 또한 두 개의 기둥을 원한다는 것이다.Anomie⚔ 15:36, 2010년 12월 15일 (UTC)[응답]

모든 사람을 기쁘게 할 수는 없지만 그렇다고 해서 반드시 여기서 포기해야 한다는 뜻은 아니다.그리고 이 문제에 대해 순전히 고정된 전자파 용어로 이야기하는 것은 도움이 되지 않는다. 사용자가 실제로 원하는 (확실히 전자파 번호가 아닌) 매개변수(i-iii)에 대한 위의 의견을 보십시오.Rd232 15:40, 2010년 12월 15일 (UTC)[응답]

• 추천{{reflist 30em}}디폴트는 나쁜 생각이다.몇 주 전만 해도 우리는 그 디폴트 행동을 실험했는데, 이 실험은{{reflist 2}}기둥 너비 30mm를 할당하고, 많은 성질을 얻었고, 실험은 실패하여 되돌아가게 되었다.하지만 벤더는 그것을 너무 좋아해서 그는 계속해서 다음과 같은 방법으로 기사를 바꾸었다.{{reflist 30em}}그리고 그는 WP에 관리자로 임명되었다.ANI는 사람들이 그 변화를 좋아하지 않기 때문에 그만둘 것을 요구했다.그리고 이제 그는 지역사회에서 이미 두 번이나 거부당한 것에 대한 자신의 의견을 확인하기 위해 RFC를 설립한다.권고사항이 있을 경우, (각주 등) 매우 짧지 않은 한, 표준 2 열 참조인 일반적인 관행을 따라야 한다.그러나 WP:CREP의 관심에 있어서, 나는 그것이 편집자들의 개별적인 판단에 맡겨지는 것이 최선이라고 생각한다. — Edokter • Talk • 2010년 12월 15일 (UTC)[응답]

음, 나는 그것이 벤더에게 좀 가혹하다고 생각한다. 왜냐하면 그는 (나로부터도 마찬가지겠지만) 세계적인 합의를 구하라는 권유를 받았기 때문이다.그가 내 충고를 더 정확하게 따르지 않은 것은 유감스러운 일이지만(제안서를 제출하고, 초기 논의를 한 다음 RFC를 발족) 그러나 지금 우리는 여기에 와 있으니, 만일 칼럼을 언제 사용해야 하는가에 대해 (정확한 방법에 대해 합의할 수 없다면) 논의가 유용할 수 있고 MOS 지침이 적절할 것이라고 생각한다.특히 고정 너비(다른 상황에 적합한 너비에 동의할 수 있는 경우)가 고정 열 개수보다 대형 화면과 특히 소형 화면 모두를 더 잘 수용할 수 있는 방법을 살펴보십시오.이전 실험의 문제는 (기존 설정의 행동을 바꾸는 것 역시 혼동을 야기할 수밖에 없었던) 원칙보다는 벤더가 선호하는 30em 폭이었을지도 모른다고 생각한다.Rd232^talk 13:39, 2010년 12월 15일 (UTC)[응답]

흠. 예를 들어, 9/11에서 대부분의 참조는 내 1280 px 화면에 있는 둘 이상의 흐름 선(여러 개의 짧은 참조와 일치하는 다중 선 참조와 구별됨) 텍스트로 확장된다.{{reflist 3}} 황당하다.우리의 지침은 그것을 칼럼이 없는 것으로 남겨두어야 한다.(그것이 벤더의 것인지는 확인하지 않았고, 어쨌든 200개 이상의 참고자료가 있으면 칼럼을 싫어하지만, 말이 되는 가이드라인을 찾으려고 했을 뿐이다.)— 아서 루빈(토크) 14:59, 2010년 12월 15일 (UTC)[응답]

무슨 말인지 잘 모르겠는데...특히 200이 넘는 언급에 대해서.어쨌든, 나는 9/11 기사가 3개가 아니라 2개의 칼럼이 있어야 한다는 것에 동의한다.Rd232^talk 15:22, 2010년 12월 15일 (UTC)[응답]

솔직히 나는 9/11에 있는 세 개의 칼럼이 괜찮아 보이고 하나의 칼럼은 그저 어리석기 때문에 외부 링크와 다른 유용한 콘텐츠에 대한 접근을 막는다.만약 우리가 단일 칼럼만을 추진한다면, 우리는 또한 독자들의 내용보다 더 많은 편집자 내용이 있기 때문에 페이지의 맨 아래에 ref를 채택해야 한다고 생각한다.나는 다중 행의 ref에 문제가 없다고 본다. 참고문헌은 당신이 기사 산문처럼 앉아서 읽는 것이 아니라 참고문헌으로 되어 있지 않다.내용을 확인하거나 백업하려면 인용 링크를 클릭하여 올바른 내용을 강조 표시하십시오.그렇지 않으면 효율적인 공간 활용이다. --Errgent^(chat!) 15:29, 2010년 12월 15일 (UTC)[응답]

너무 많은 선에 분할된 참조는 스캔하기가 더 어렵다.나는 내가 그러한 참조 리스트를 실제로 훑어보지 않고 내가 확인해야 할 특정한 참조들을 보는 것을 발견한다.Rd232^talk 15:32, 2010년 12월 15일 (UTC)[응답]

센스 있는 포인트.무작위적인 생각; 가젯/페이지 도구 또는 reflist 템플릿의 일부로서 클릭해서 하나의 열로 만드는 어떤 자바스크립트는 어떨까?결국 이것은 편집자의 필요(즉, 읽을 수 있는 ref)와 독자의 균형을 맞추는 것이라고 생각한다(즉, ref에 대한 걱정을 훨씬 덜고 대부분 무시하는 정도까지). --Errrant 15:38^(chat!), 2010년 12월 15일 (UTC)[응답]

사용자들이 이러한 문제에 대해 어느 정도 선택할 수 있도록 해주는 실행 가능한 모든 것이 좋을 것이다.Rd232 15:43, 2010년 12월 15일 (UTC)[응답]

내 생각에 실험은{{Reflist 2}}처럼 행동하다{{Reflist colwidth=30em}}많은 사람들을 놀라게 했기 때문에 실패했다.들어가면{{Reflist 2}}템플릿에서 두 개의 열이 생성될 것으로 예상하는 경우.하지만 그 실험 후에 템플릿은 완성되지 않았다.나는 결코 이것을 하는 것에 찬성하지 않았다.

또한, 나는 구현을 중단하라는 요청을 받지 않았다.{{Reflist colwidth=30em}}사람들이 좋아하지 않았기 때문이지만, 위키백과 규칙이나 지침이 없기 때문에 (또는 다른) 이런 스타일을 추천한다.따라서 이 제안은 실제로 참조 리스트에 관한 세계적 합의가 무엇인지에 대한 명확성을 확립하기 위한 것이다.—벤더235 (대화) 14:54, 2010년 12월 15일 (UTC)[응답]

나는 다른 것들보다 더 큰 폭의 스타일에 대한 추천이 없다는 것과 그것을 싫어하는 사람들이 있다는 것을 알고 있다는 것이 둘 다 문제라고 생각한다 — 칼 (CBM · talk) 16:56, 2010년 12월 15일 (UTC)[응답]

누가 나를 위해 그 제안을 명확히 해줄 수 있니?이 중 어떤 것이 제안되고 있는가?

1. 현재 여러 개의 열이 없는 참조가 20개 이상인 기사는 colwidth=30으로 변경해야 한다.
2. 현재 여러 개의 열이 없는 참조가 20개 이상인 기사는 colwidth=30 또는 reflist 2로 변경해야 한다.
3. 참조가 20개 이상인 기사는 이미 reflist 2를 사용하고 있더라도 colcount=30을 사용하도록 변경해야 한다.

그것들은 전혀 다른 제안일 것이다.#1이나 #2가 #3보다 더 좋은 것 같아. —칼 (CBM · talk) 16:56, 2010년 12월 15일 (UTC)[응답]

참조가 20개 이상인 기사는 이미 여러 개의 열을 사용하든 상관없이 다음 항목으로 변경해야 한다.colwidth그러나 기둥의 정확한 너비는 각 기사에 대해 결정되어야 한다.이것은 사실 특정 폭을 규정하는 것이 아니라 전반적으로 유연한 기둥의 사용을 권고하는 것이다.—벤더235 (대화) 22:48, 2010년 12월 15일 (UTC)[응답]

이 문제에 대한 나의 의견이다.내 생각에, 우리는 긴 참조 리스트를 위해 칼럼을 사용해야 한다. (그리고 이 근처에는 많은 것들이 있다.)이런 식으로, 사람들은 단지 외부 링크 섹션 등에 갔다가 다시 돌아오기 위해 오랜 기간 동안 긴 참조 목록을 스크롤할 필요가 없다.[ Retro00064 ▷인터뷰> 2010년 12월 16일 (UTC) 00:33, 답변

그렇다면, 적어도 참조 리스트가 긴 기사(20+ ref)는 너비와 숫자에 상관없이 칼럼을 사용해야 한다는 그들의 의견 일치는 아닐까?—벤더235 (대화) 2010년 12월 17일 (UTC) 14:19[응답]

칼럼을 쓰자는 공감대는 있다고 생각하지만 어떤 방법을 써야 할지 공감대는 보이지 않는다.그러므로 나는 우리가 오랫동안 일반적인 관행이었던 것을 추천해야 한다고 생각한다. 즉, 사용하는 것이다.짧은 참고 자료와 각주 목록에 너비 기반 열을 사용하도록 권고를 추가하겠다. — Edokter • Talk • 14:44, 2010년 12월 17일 (UTC)[응답]

난 그렇게 생각하지 않아.사용.{{Reflist 2}}다른 방법이 없을 때 임시방편적인 해결책에 가까웠지하지만 이제 우리는colwidth그리고 그것은 훨씬 더 나은 선택이다.따라서 사용자에게 열등한 옵션을 구현하도록 권고함으로써 현 상태를 공고히 하기보다는, 사용자에게 열을 사용하도록 권고해야 하며, 사용 가능한 옵션을 가리켜야 한다.—벤더235 (대화) 14:59, 2010년 12월 17일 (UTC)[응답]

컬럼 카운트와 컬럼 너비는 모두 CSS3의 동일한 기능 세트의 일부분이며, 동시에 사용할 수 있었다.우리가 {{reflist 2.}}}}}을(를) '일시적인' 것으로 간주하고 있다는 것을 몰랐고, 내가 아는 바로는, 우리는 결코 그렇게 하지 않았다.나는 역동적인 기둥의 필요성에 전혀 만족하지 않는다...어떤 사람들은 기둥이 넓어졌다고 말하는가?그렇다면 기사 텍스트 자체에 대해서는 어떤 생각을 하고 있는 것일까.2열 참조를 선택한 이유는 공간이 제한된 짧은 참조와 긴 참조 목록 사이의 사용 가능한 공간을 균형 있게 조정했기 때문이다.칼럼이 많아지면 일이 복잡해지기 시작한다. — Edokter • Talk — 21:35, 2010년 12월 17일 (UTC)[응답]

글쎄, 그게 네 관점이야.나는 그것에 대해 왈가왈부할 수 없다.그러나 나는 칼럼이 두 개만 있으면 "닫을 수 있다"고 생각하지만 화면 폭은 600px 정도밖에 안 된다.여러 개의 컬럼 리스트의 미학에 대해 여러분과 동의하는 사람들이 많을 겁니다. 물론 많은 사람들이 동의하지 않을 겁니다.하지만 그 논쟁은 "우린 항상 그래왔었다.{{Reflist 2}}, 그리고 그것은 더 자주 사용되어왔다"는 것은 중요하지 않다. 왜냐하면 그 논쟁에 따라 우리는 그 논쟁까지 거슬러 올라가야 하기 때문이다.<references />.

또한, 기사 텍스트에 대한 그 논쟁은 틀렸다.연속 텍스트는 1920 px 화면에서도 줄 전체를 쉽게 채울 수 있다.그러나 "밀러(2000년), 페이지 10"과 같은 참조가 두어 개라도 있다면, 왜 1920 px의 전체 폭을 각자에게 주었을까?아니면 절반?그냥 어색해 보일 거야—벤더235 (대화) 22:20, 2010년 12월 17일 (UTC)[응답]

레트로: 만약 모든 참조가 한 줄의 반 이상을 연장한다면, 칼럼으로 가는 것은 사용되는 부동산을 감소시키지 않을 것이다.기둥 사이의 공간 때문에, 그것은 부동산 사용량을 증가시킬 것 같다.나는 여전히 칼럼을 채무불이행으로 반대하지만 사실만을 지적한다.— 아서 루빈(토크) 14:48, 2010년 12월 17일 (UTC)[응답]

사실이지만 행의 절반 이상을 확장하는 참조는 드물다.하지만 그런 경우에는 어느 쪽도 아니다.{{Reflist 2}}아닌{{Reflist colwidth=30em}}유용하다.그렇지만{{Reflist colwidth=60em}}지도 모른다따라서 이것은 실제로 숫자가 아니라 저자가 결정해야 할 열의 너비라는 점을 더한다.—벤더235 (대화) 14:59, 2010년 12월 17일 (UTC)[응답]

대체 제안

{{reflist}}}을(를) 확장하여 {{reflist 좁은 columnns}}, {{reflist 표준 columns}}}이(가) "30em"과 같이 특정 폭의 의미를 하드코딩하지 않는다는 장점을 가지고 사람들이 이해할 수 있는 단어로 열 너비를 정의한다.그것은 이해하기 쉽고, 표준화에 더 적합하며, 미래의 변화에 도움이 될 것이다.좁은 색상은 처음에 20em(논의 및/또는 나중에 변경될 수 있음)으로 설정하고 표준 색상은 40em(ditto)으로 설정할 것을 제안한다.이러한 새로운 매개변수를 사용하면 MoS 추가사항을 쉽게 파악할 수 있다.

참조가 20개 미만인 경우 참조 목록에서 열을 권장하지 않는다.그 이상 좁은 컬럼이 필요한 경우(특히 저자(년:페이지) 스타일 참조가 기사에 주로 또는 독점적으로 사용되는 경우), 그 외의 경우 {{reflist 표준컬럼}을 사용할 수 있다.단, 칼럼의 사용은 필요하지 않으며, 칼럼의 대체 포맷은 특정한 이유가 있다는 지역적 합의가 있는 경우에 사용할 수 있다.

Rd232 15:30, 2010년 12월 15일 (UTC)[응답]

부록: 칼럼 너비를 전혀 사용해야 하는 이유를 약간 더 설명(위 섹션 참조):현상은 기본적으로 대부분의 참조 목록에 대해 {{Reflist2}}, 짧은 형식(예: 작성자/년/페이지) 참조에 의해 지배되는 참조 목록에 대해 {{Reflist 3}을 사용하는 것이다.이것은 일반적인 화면 크기에 적합하고 큰 화면 크기에 적합하다.이 접근방식이 실질적으로 떨어지는 곳은 작은 스크린으로, 화면은 작지만 2개의 칼럼으로 고정되어 있다.대형 스크린에서는 너무 많은 공백이 생길 수도 있지만, 그렇게 심각하지는 않다.적절한 값으로 사용하면 이러한 문제를 해결할 수 있을 것이다. 일반적인 화면에서는 콜 너비=40em 작업을 {{Reflist2}}개에 해당하는 반면 작은 화면에서는 하나의 컬럼을 허용하고 큰 화면에서는 3개의 컬럼을 허용하고, 콜 너비=30em 작업을 {{Reflist 3}}에 해당하는 것으로 제안한다.내가 20em을 좁은 색채에 제안했는데, 왜냐하면 충분한 참고자료를 가지고 있는 경우, 그게 더 잘 풀리기 때문이다.Rd232 01:41, 2010년 12월 16일 (UTC)[응답]

나는 그것을 좋아하지 않는다.그것은 하드코드로 보이지 않을 것이고, 비트 코드는 여전히 하드코드로 되어 있으며, 여전히 다른 사람들에게 예측할 수 없는 결과를 준다.{{Reflist}}}은 CSS3 컬럼 기능을 사용하며, 그런 점에서 충분히 구성 가능하다. 템플릿의 핵심 재미도를 넘어서는 의미론적 파라메터로 비대해져서는 안 된다. — Edokter • Talk • 2010년 12월 15일 (UTC)[응답]

나는 완전히 이해하지는 못한다.만약 당신이 이 매개변수를 가지고 있다면, 당신은 무엇이든지 최상으로 그것들을 구현할 수 있다.만약 CSS4가 나타나거나 누군가가 단순히 더 나은 방법을 생각해 낸다면, 당신은 그것을 쉽게 바꿀 수 있다.당분간은 스탠더드컬럼을 리플리스트 2에 대한 요청으로, 좁은컬럼을 리플리스트 3에 대한 요청으로 취급할 수도 있다.Rd232 16:47, 2010년 12월 15일 (UTC)[응답]

템플릿 코드 안에서 다소 임의적인 숫자(30em)를 한 번 고르는 것이 수천 개의 글에서 임의의 숫자를 고르는 것보다 낫다고 생각하는데, 나중에 고치기 훨씬 어려울 것이다.— 칼 (CBM · talk) 2010년 12월 15일 16:58 (UTC)[응답]

바로 그거야그리고 그것은 개선을 위한 더 쉬운 길을 허락한다.Rd232 17:54, 2010년 12월 15일 (UTC)[응답]

아니, 이걸 다시 일률적인 결정으로 만들 수는 없어. 30em대부분의 기사에는 잘 어울리지만, 확실히 전부는 아니다.그 칼럼들이 얼마나 넓어야 하는지에 대한 결정은 지역적 합의에 맡기라.—벤더235 (대화) 00:42, 2010년 12월 16일 (UTC)[응답]

하지만… 적극적으로 다른 일을 하고 싶어하는 사람들을 위해 (내 제안대로) 명시적으로 허용한다면 "대부분"이면 충분하다.Rd232 00:57, 2010년 12월 16일 (UTC)[응답]

• 나는 인용 서식을 위한 표준화된 규칙을 만들려는 모든 시도에 반대한다.취향이 다른 작가들이 각기 다른 전통으로 쓴 글이다.이것은 외관상의 문제로서 강제적인 표준화에 대한 유효한 주장이 없다.·마우너스 · ƛ·17:02, 2010년 12월 15일 (UTC)[응답]
  • 그렇다, 유효한 주장이 있다: 작은 화면에서 현재 reflist 2 접근방식에 대한 접근성 문제가 있다.제안된 MoS 추가는 사람들이 원한다면 다른 것을 하도록 명시적으로 허용했다; 나는 규칙이 아닌 권고안을 제안하는 것이다.Rd232 17:54, 2010년 12월 15일 (UTC)[응답]
  • 나는 인용 서식을 위한 표준화된 규칙을 만들려는 모든 시도에 반대한다는 마우누스의 주장에 동의하지 않는다. 취향이 다른 작가들이 각기 다른 전통으로 쓴 글들이랍니다."필자가 보기에 작가의 전통과 취향은 무관하며 가장 일반적인 마크업(예: 높은 이미지에 초상화 파라미터를 적용하는 것)과는 별개로 기여자들은 발표 형식을 결정해서는 안 된다. - 포인트리스트 (토크) 00:41, 2010년 12월 16일 (UTC)[응답]

그것은 흥미로운 관점이다 - 그렇다면 누가 어떤 기준 스타일을 따라야 할지를 결정해야 하는가?친애하는 지도자?·마우너스 · ƛ·22:27 (UTC) 2010년 12월 17일 (회신)

나는 그 제안이 마음에 든다.—벤더235 (대화) 18:04, 2010년 12월 15일 (UTC)[응답]

헷갈려 (대체로?)제안)

나는 지금 우리가 무엇을 하려고 하는지 혼란스럽다. 단지 2가 아니라 2가 필요하다. 항상, 때로는?등. 최근에 콜 너비를 디폴트로 사용하려고 했지만 와이드 크레인에서는 4개 또는 5개의 컬럼을 만들었고 각 컬럼마다 몇 개의 리프만 달아서 읽기 어려웠기 때문에 귀찮았다.왜 그냥..

참조가 20개 이상인 페이지나 참조 목록이 긴 페이지의 경우, 작은 화면을 사용하는 독자를 수용할 수 있도록 열을 사용하는 것이 좋다.

긴 참조 목록/바이블리오그래피가 있는 페이지를 2열로 변경하는 것은, 예를 들어, iPod Touch나 iPad를 켜면 더 쉽게 탐색할 수 있기 때문이지, 추가 긴 참조 목록을 스크롤하지 않아도 된다.colwidth specification을 사용할 것인지에 대한 문제에 대해서는, 문제가 되지 않으며, 해당 페이지에서 가장 잘 작동하는 것에 대해서라면 무엇이든 할 수 있어야 한다고 생각한다. / /ETCHCOMMS/23:06, 2010년 12월 15일 (UTC)[응답]

네가 그 문제를 제대로 이해하지 못한 것 같아.좀 헷갈리는 건 알지만, 첫 번째 섹션에 있는 내 큰 글과 다른 제안서를 한 번 더 봐줘.Rd232 01:05, 2010년 12월 16일 (UTC)[응답]

최근에 콜 너비를 디폴트로 사용하려고 했지만 와이드 크레인에서는 4개 또는 5개의 컬럼을 만들었기 때문에 귀찮았다. 각 컬럼마다 몇 개의 리프가 있다.

그렇다, 따라서 이 제안서는 참조 목록이 긴 기사만을 대상으로 한다.ref가 20개 미만인 기사에서는 보통 칼럼을 아예 사용하지 않는 것이 좋다.—벤더235 (대화) 00:40, 2010년 12월 16일 (UTC)[응답]

나는 최근의 실험이 실패했다고 믿는다. 왜냐하면 ⑴ 명백한 방법으로 기존 설정의 행동을 변화시켰기 때문이다. (b) 선택 폭이 대부분의 기사에 비해 너무 좁았다. (c) 참조가 많지 않은 일부 기사의 경우 2개의 기둥이 괜찮아 보이지만, (큰 화면에) 4개의 칼럼이 바보같이 보이기 때문이다.다시 말하지만, 열 너비가 더 넓어지면 도움이 되기 때문에, 보통 대형 스크린을 제외하고는 3개 컬럼을 넘지 않을 것이다.그러나 가장 중요한 것은 어떤 칼럼 포맷이든 편집자가 특정 문맥에 대해 무엇을 해야 하는지에 대한 구체적인 결정을 함으로써 항상 수동으로 적용되어야 한다는 것이다(다른 사람들이 이에 동의하거나 동의하지 않을 수 있음).결정을 내리는 방법에 대한 권고는 도움이 되지만, 최근의 실험은 권고가 아니라 강제적인 변화였다.Rd232^talk 01:05, 2010년 12월 16일 (UTC)[응답]

하지만 여기서 제안하는 것은 강제적인 변화를 위한 것인데, 중요한 것은 만약 그것이 통과된다면, 사람들은 20개 이상의 각주가 있는 모든 기사에 그것을 통과하여 시행한다는 것이다.— 칼 (CBM · talk) 01:33, 2010년 12월 16일 (UTC)[응답]

그건 봇이 할 수 있는 거잖아?—벤더235 (대화) 01:38, 2010년 12월 16일 (UTC)[응답]

찬성 의견이 있다고 가정하면, 봇이나 AWB, 혹은 어떤 조합에 의해 이루어질 수 있다.— 칼 (CBM · talk) 01:41, 2010년 12월 16일 (UTC)[응답]

우리가 그것을 허락하고 싶지 않다면, 우리는 그것을 허락하지 않을 수 있다!하지만 그게 단지 권고사항이라면, 그건 괜찮을 거야. 누구나 그걸 취소할 수 있으니까.본질적으로, 만약 우리가 이것에 대한 BRD 접근법을 정책에 쓴다면, 그것은 문제가 되지 않을 것이다.(이러한 경우, 봇은 같은 기사를 두 번 편집하는 것을 피할 수 있는 한 괜찮지만, AWB는 제외될 것이다.)Rd232 01:48, 2010년 12월 16일 (UTC)[응답]

FWIW, 만약 우리가 동의할 수 있는 유일한 것이 "긴" 참조 목록에 어떤 종류의 칼럼 포맷을 사용하라는 MoS 권고라면, 그것은 여전히 없는 것보다 낫다.Rd232 01:34, 2010년 12월 16일 (UTC)[응답]

그래.—벤더235 (대화) 01:38, 2010년 12월 16일 (UTC)[응답]

글쎄, 그것은 MOS (또는 WP:CITE, 이것이 가장 가능성이 높은 고향이다.현재 AFAIK 칼럼에 대한 언어는 없다.중요한 질문은: 우리는 사람들이 20개의 참고문헌을 가지고 있는 기사에 칼럼을 추가하기를 원하는가? 입니다.만약 그렇다면, 우리는 그들이 reflist 2, reflist 30em 또는 무작위 혼합물을 추가하기를 원하는가?— 칼 (CBM · talk) 01:39, 2010년 12월 16일 (UTC)[응답]

글쎄, 나는 그들이 적절한 reflist concolumns나 reflist standardcolumns를 추가하는 것을 보고 싶다.그리고 나는 그러한 설정들이 큰 폭의 관점에서 템플릿에 정의되어야 한다고 생각한다; 아주 작은 화면에 있는 2개의 리플리스트 기사를 보고 그것이 얼마나 형편없어 보이는지 보라.그런 다음 콜폭 기사(예: Ivo_Sanader)로 똑같이 하고 그것이 어떻게 우아하게 1열로 내려가는지 보라!Rd232 02:00, 2010년 12월 16일 (UTC)[응답]

그래, 아직 좀 혼란스럽긴 하지만 "필수"의 변화보다는 추천이 더 낫겠어.정확히 몇 개의 열을 가질 것인지, 몇 개의 열을 가질 것인지 선택하는 것이 가장 좋을 때가 있다. / /ETECOMMS/ 03:04, 2010년 12월 16일 (UTC)[응답]

맞아.그러므로 나의 원래 제안서는 다음과 같이 말했다."(특정 기사 편집자의) 지역 합의가 반대하지 않는 한 칼럼을 사용한다."—벤더235 (대화) 07:56, 2010년 12월 16일 (UTC)[응답]

표시 형식은 사용자/에이전트에 의해 결정되어야 함

어떤 화면을 사용하느냐에 따라 다른 규칙을 사용하여 위키백과 페이지를 렌더링할 수 있었으면 좋겠다.왼쪽 열 네비게이션과 각주 열 너비는 이 중 일부여야 한다.스마트폰을 사용할 때 필요한 레이아웃은 현대적인 비즈니스 데스크톱을 사용할 때의 레이아웃과 경쟁적으로 다르다.Hard-coding the layout was a temporary expedient, a quick-and-dirty approximation because 1993-era browsers couldn't handle SGML/XSL. Nowadays named accounts should be able to view wikpedia using multiple screen formats (e.g. 400x800 smartphone, 640x480 netbook, 1024x768 and 1280x800 tablet, 1600x1200 and 1200x1600 DVI, 1920x1080 and 1920x1200 HD). 기여자들은 이러한 모든 조합을 확인할 것으로 기대할 수 없으므로 위키 마크업은 가능한 한 레이아웃 옵션을 일반화해야 한다.각주 레이아웃을 일반화하고 영상에 대한 사용자 정의 왼쪽 폭을 방지하는 것은 시작하기에 좋은 장소다. - 점묘사(토크) 01:12, 2010년 12월 16일 (UTC)[응답]

좋은 생각이야.꽤 괜찮은 것 같군.일리가 있어. ;-) [Retro00064 ▷인터뷰토크 ] 01:15, 2010년 12월 16일 (UTC)[응답]

내가 당신을 정확히 이해한다면, 당신은 레이아웃의 모든 형태의 하드 코딩을 제거하기 위해 훨씬 더 일반적인 사례를 만들고 있는 겁니까?그건 삼키기 힘든 약이야!나는 당신의 헤드라인 감정에 동의한다. 가능한 한 우리는 다양한 화면 크기를 수용할 수 있도록 노력해야 한다. (만약 우리가 사용자당 화면 크기를 감지할 수 있다면 그것은 많은 도움이 될 것이다...하지만 그런 일은 일어나지 않을 것이다.이 스레드는 실제로 "고정" 열 너비를 잘 활용하는 방법에 대한 훨씬 더 제한적인 문제에 관한 것이다. (실제로 고정된 열 너비는 고정된 것이 아니며, 실제로 우리가 하고 있는 것은 실제로 고정된 열 수를 지정하는 것보다 화면 크기에 걸쳐 잘 동작할 가능성이 더 높은 최대 너비를 지정하는 것이다.)Rd232^talk 01:25, 2010년 12월 16일 (UTC)[응답]

음, 그래, 난 삼켜야 할 약이 있다고 말하고 있는 거야.그것을 세 가지 방법으로 받아들일 수 있다: (1) 미래 모든 기기에 대해 완벽한 단일 하드 코드 솔루션을 찾도록 노력해야 한다는 것, (2) 설계 결정을 내릴 때 서로 다른 화면 해상도를 존중해야 한다는 것, (3) 설계 결정을 해서는 안 된다는 것. 우리는 미래에 효과적으로 배치될 수 있도록 데이터를 의미론적으로 표시하기만 하면 된다.내가 처음 이런 말은 아니지만 IMO 옵션 2가 1보다 좋고, 3이 2보다 낫다.옵션 3에 가까워질수록 현재 사용 중인 브라우저의 레이아웃과 기술 기능에 따라 사용자 환경을 최적화하고자 할 것이다.첫 번째 단계는 사용자가 자신의 사용자 에이전트 기능에 따라 위키백과의 "다른" 버전을 사용하여 동일한 계정에 로그인할 수 있도록 하는 것이다.만약 당신이 그 단계에 동의한다면, 표시장치 매개변수의 하드 코딩은 가능한 모든 브라우저 시나리오에 대해 신중하게 검토되어야 한다.실패하는 레이아웃은 더 이상 사용하지 말고 성공하는 레이아웃은 권장해야 한다. - 포인트리스트(토크) 01:53, 2010년 12월 16일 (UTC)[응답]

사실colwidth네가 원하는 대로 하는 거야참조 목록의 열 수를 미리 결정하는 대신,colwidth사용자의 웹 브라우저(즉, 화면 너비 및 글꼴 크기)에 남긴다.대형 모니터를 가진 사람들은 3~4개의 칼럼이 가용한 모든 스크린 부동산의 최대치를 보는 반면 스마트폰과 넷북을 가진 사람들은 같은 기사에서 1~2개의 칼럼만 본다.—벤더235 (대화) 01:46, 2010년 12월 16일 (UTC)[응답]

AFAICS 좌측 내비게이션 컬럼은 어떤 스마트폰에서도 너무 많은 공간을 차지한다.우리는 어떤 장치 레이아웃이 필요한지에 따라 명명된 계정이 다른 스타일시트를 사용할 수 있는 모델이 필요하다. - 포인트리스트 (토크) 01:58, 2010년 12월 16일 (UTC)[응답]

내 아이폰에 (적어도 나를 위해) 디폴트로 올라오는 모바일 사이트가 있다: http://en.m.wikipedia.org/ — Carl (CBM · talk) 02:38, 2010년 12월 16일 (UTC)[응답]

어떤 사람들은 (나처럼) 편집할 수 있도록 아이폰의 그 피부를 무력화시킨다.그래서 그것이 모든 것을 해결해주지는 않는다.access_denied (대화) 03:08, 2010년 12월 16일 (UTC)[응답]

자신만의 아이폰 스킨을 가지고 있는 사용자들이 있다.충분히 열심히 검색하면 찾을 수 있을지도 모른다.MediaWiki에도 다음과 같은 예가 있다.아이폰 크기의 스크린 장치를 대상으로 하는 방법을 보여주는 Common.css.("@미디어 전용 화면..."을 찾으십시오.) —DJ (대화 • 기여) 15:44, 2010년 12월 18일 (UTC)[응답]

최종제안

좋아, 이제 논의가 끝난 것 같아 보이는데, WP에 다음 사항을 추가하자고 제안한다.Citefoot:

참조가 20개 미만인 경우 참조 목록에서 열을 권장하지 않는다.이 위에.{{reflist 20em}}좁은 열이 필요한 경우(특히 작성자(년:페이지) 스타일 참조가 기사에 주로 또는 독점적으로 사용되는 경우) 또는 다른 경우에 사용할 수 있다.{{reflist 30em}}추천한다.기사에 특히 긴 참조가 포함되어 있는 경우 다음을 고려하십시오.{{reflist 30em}}대안으로단, 칼럼의 사용은 필요하지 않으며, 칼럼의 대체 포맷은 특정한 이유가 있다는 지역적 합의가 있는 경우에 사용할 수 있다.

이는 기본적으로 위로부터의 사용자:Rd232의 제안이며, 그러한 제안과 매개변수가 아직 존재하지 않는다는 것을 제외한다.분명히 내 쪽에서 지지해 주겠지.—벤더235 (대화) 23:01, 2010년 12월 19일 (UTC)[응답]

• 나는 콜 너비 사양을 제외한 모든 것에 동의한다.reflist 2 over reflist 30em 또는 reflist 3 over reflist 20em 등을 사용하는 것이 완벽하게 허용되어야 한다.고정숫자 또는 고정폭의 사용 여부는 기사별로 다르며, 이에 대한 분쟁이 있을 경우 현지 합의가 결정요인이다. /ƒETECCOMMS/23:19, 2010년 12월 19일 (UTC)[응답]

사용자에게 말한 대로:위에 에독터, 나는 제안하지 않을 것 같다.{{reflist 3}}의 대용으로서{{reflist 20em}}(등)이 맞다.예를 들어, 이 페이지에서 몇 개의 열을 추천하시겠습니까?사실, 이제 여러분은 2에서 8까지의 숫자를 말할 수 있지만, 여러분이 결정한 열의 수가 너무 많거나 너무 적은 스크린이 항상 있기 때문에 둘 중 하나는 부정확할 것이다(또는 적어도 불완전할 것이다).내 22인치 1920 px 화면에는 6개의 칼럼이 딱 들어맞는다.하지만 만약 내가 10인치 짜리 넷북을 가지고 있다면, 그건 너무 심할 거야.반면에, 그 넷북에서는 두 개의 칼럼이 완벽해 보일 수도 있지만, 더 큰 화면에서는 그저 어색해 보일 뿐이다.

요점은 열 수를 결정하는 것은 유용하지 않다는 것이다. 왜냐하면 그것은 처음에 결정되었던 화면 크기를 제외하고 어디에서나 어색한 결과를 초래하기 때문이다.그러나 열의 너비를 결정하는 것은 화면 크기에 관계없이 항상 완벽한 결과를 낳는다(너무 적은 수의 참조에 대해 열이 너무 많은 경우는 제외한다). 따라서 이 권장사항은 20개 이상의 참조 목록에만 적용된다.—벤더235 (대화) 23:45, 2010년 12월 19일 (UTC)[응답]

그것은 일부 페이지에 유용하다.예를 들어, 나는 21개의 ref가 있는 한 페이지에 대해 넓은 화면에 8개의 칼럼을 원하지 않는다.내 아이팟이든 27인치 아이맥이든 두 개의 컬럼이면 충분하다.그 점에 있어서 절대적인 것은 없어야 한다고 생각한다; 최근에 {{reflist}}}에 콜폭 디폴트를 시도했다가 다시 변경되었다. / /ETECCOMMS/ 01:28, 2010년 12월 20일 (UTC)[응답]

일반적으로 나는 멀티 컬럼의 reflist에 전혀 열광하지 않으며, 어떤 것의 적절한 폭은 화면 크기, 창 크기, 사용자 선호도에 따라 다르기 때문에 고정 너비라면 무엇이든 대체로 반대한다.어쨌든 나는 현상에 머물러 있는 편이 낫겠다, 기사별로 일이 일어나고 우리는 일관성을 너무 걱정하지 않는 것이다. 67.117.130.143 (대화) 00:31, 2010년 12월 20일 (UTC)[응답]

여기서 혼란스러운 것 중 하나는 colwidth=xxx가 고정 너비가 아니라 최대 너비라는 것이다. 반면, 열의 수(reflist 2 등)를 명시하는 것은 실제로 고정 형식이다(얼마나 적절한지에 관계없이 항상 정확히 2 또는 3 또는 어떤 열이다).Rd232^talk 00:33, 2010년 12월 20일 (UTC)[응답]

사실, colwidth는 열의 최소 폭이다. — Edokter • Talk — 01:32, 2010년 12월 20일 (UTC)[응답]

"나는 일반적으로 어떤 것의 적절한 폭은 화면 크기, 창 크기, 사용자 선호도에 따라 다르기 때문에 고정 너비라면 무엇이든 반대한다."

글쎄, 사실은 아니야.이 참조의 적절한 너비는 20자를 넘지 않는다.20em)) 화면 크기에 상관없이.화면 크기는 한 줄에 표시할 수 있는 문자 수만 결정하므로 화면에 맞는 열의 수만 결정된다.

"어쨌든 나는 현상 유지에 머무르고 싶어, 기사마다 일이 일어나고 우리는 일관성에 대해 너무 많이 걱정하지 않아."

나는 스타일 데크레이션이 가능한 한 분산되어야 한다는 것에 동의한다. 따라서 그 제안은 결국 결정하게 되는 지역적 합의라고 말한다.하지만 적어도 우리는 그 문제에 대해 일반적인 추천을 받아야 한다.—벤더235 (대화) 00:58, 2010년 12월 20일 (UTC)[응답]

만약 (위에서 링크된 비틀즈 기사처럼) 그 기사가 그 참조를 매우 짧게 유지하는 스타일로 쓰여진다면, 20em이나 30em은 잘 작동할 수 있다.참조 항목이 길어지는 경향이 있을 정도로 쓰기 스타일이 길 경우, 해당 항목을 30em으로 제한하면 해당 항목을 망칠 수 있다.글쓰기 스타일은 기사별로 다르므로 형식도 다양해야 한다. 67.117.130.143 (대화) 01:15, 2010년 12월 20일 (UTC)[응답]

"참조 항목이 길어지는 경향이 있을 정도로 쓰기 스타일이 길다면, 30em으로 제한하면 그것들을 망칠 수 있다."

그것은 절대적으로 옳다.경우에 따라 기준 폭은 45em 또는 60em이어야 한다.그건 문제 없어.이 제안은 사람들이 칼럼의 너비를 결정하도록 장려하기 위한 것이었다.20em, 30em, 또는 그 이상인지는 항상 특정 기사에 달려 있다.

사용하시겠다면{{reflist 2}}사용자의 모니터가 작거나 스크린의 절반에 대한 참조가 너무 길면, 그것은 또한 기사를 망칠 수 있다.—벤더235 (대화) 01:25, 2010년 12월 20일 (UTC)[응답]

사실, 나는 Reflist가 전에 알아차리지 못했던 창 너비에 따라 열의 수를 바꾼다는 것을 이제 알았다.적어도 전체 크기의 브라우저에서는 참조 섹션의 글꼴 축소 때문에 30em이 정상으로 작동한다.기준치로는 50em에 가깝지만, 그렇게 제한적이지는 않다.음. 더 가지고 놀지도 몰라.어쨌든 이런 일에 집착하는 것은 건강에 좋지 않다. 67.117.130.143 (대화) 01:31, 2010년 12월 20일 (UTC)[응답]

내가 알기로는, 이 제안의 요점은 편집자들이 대량 변경을 시작하여 20개 이상의 참조가 있는 기사에 열을 추가할 수 있도록 하고, 지금 당장 reflist 2에서 reflist 20em 또는 reflist 30em으로 형식을 변경하는 것이다.그래?— 칼 (CBM · talk) 00:41, 2010년 12월 20일 (UTC)[응답]

본질적으로 그렇다, 만약 컨센서스가 reflist 30em을 사용한다면, 왜 적절한 곳에서 그것을 시행하지 않는가?반면에, 만약 합의된 것이 "colwidth"를 사용하지 않는 것이라면, 왜 그런 기능이 전혀 있는 것일까?—벤더235 (대화) 00:58, 2010년 12월 20일 (UTC)[응답]

둘 다 쓸모가 있으니까나는 이 문제에 대한 어떤 "필수"에도 동의하지 않는다; 그것은 페이지 단위로 이루어져야 한다. /ƒETECCOMMS/ 01:30, 2010년 12월 20일 (UTC)[응답]

네, 하지만{{reflist 2}}20개 미만의 리프만 사용할 수 있다.따라서 이 제안은 20개 이상의 조항에만 적용된다.이것은 대체하려는 제안이 아니다.{{reflist 2}}, 그러나 단지 20 ref가 넘는 기사에는 사용하지 말 것을 권고하기 위해서입니다.—벤더235 (대화) 01:36, 2010년 12월 20일 (UTC)[응답]

• 지지하다.기본적으로 {reflist}이(가) 그렇게 하도록 하는 것도 지원하지만,{{reflist 1}}인용구가 거의 없는 기사에서 그것을 무효로 하기 위해 사용될 수 있다.A. di M. (토크) 02:14, 2010년 12월 20일 (UTC)[응답하라]

그건 사실 좋은 생각이야.—벤더235 (대화) 03:07, 2010년 12월 20일 (UTC)[응답]

나도 그런 생각을 했지만, 참조가 거의 없는 기사에는 평이한 {{reflist}}이(가) 너무 널리 쓰이기 때문에 거절했다.원래 좋은 방법일 수도 있었는데 지금은 잘 모르겠어.Rd232 08:42, 2010년 12월 20일 (UTC)[응답]

• 강한 반대다.정확한 ref 카운트에 대한 참조를 위해 얼마나 많은 ems와 얼마나 많은 열이 있어야 하는지 의무화하는 것은 터무니없는 양의 WP:CREP이다.Tijfo098 (대화) 2010년 12월 20일 (UTC) 12시 5분 (답변)

(편집 충돌) 게다가 칼럼 코드는 제대로 작동하지 않는다[5].Tijfo098 (대화) 2010년 12월 20일 12시 30분 (UTC)[응답하라]

사실 나는 한다.네가 거기서 보고하는 것은 벌레가 아니다.—벤더235 (대화) 13:40, 2010년 12월 20일 (UTC)[응답]

만약 엄청나게 불평등한 기둥을 생산하는 것이 이 템플릿 매개변수의 특징이라면, 그것은 내가 결코 사용할 수 있는 것이 아니기 때문에, 나는 반대 앞에 "강력"을 더했다.Tijfo098 (대화) 21:03, 2010년 12월 24일 (UTC)[응답]

이 제안은 당신이 몇 개의 열을 사용해야 하는지 또는 얼마나 넓어야 하는지를 의무화하지 않는다.기사에 ref가 20개 이상인 경우에만 칼럼을 사용하도록 의무화된다.나머지는 현지에서 결정할 수도 있다. 20em그리고30em단지 제안일 뿐이지 지시는 아니다—벤더235 (대화) 12:24, 2010년 12월 20일 (UTC)[응답]

참조 수는 원하는 열 수를 결정하는 데 좋은 매개 변수가 아니다.각 열의 텍스트 양은 다음과 같다.만약 참고문헌이 실제로 "Smith(2006, 페이지 42)"라면, 3열 각주는 책 리스트를 위한 단 하나의 칼럼이 있는 것이 더 보기 좋다.요점은 참조의 수가 열 크기나 숫자와 관계가 없다는 것이다.Tijfo098 (대화) 2010년 12월 20일 13:17 (UTC)[응답하라]

(1) 본 제안서는 도서목록에는 적용되지 않는다.

(2) 만약 당신이 "Smith(2006, 페이지 42)" (여기처럼)에 대한 참조만을 가지고 있다면, 세 개의 컬럼 – 당신과 같은 1024p 스크린에서 볼 수 있다.하지만 나와 같은 1920p 화면에서는, 그들은 그러지 않을 것이다.—벤더235 (대화) 13:40, 2010년 12월 20일 (UTC)[응답]

또한, 나는 몇몇 사람들이 스크리 사이즈의 기둥의 스케일링 문제를 위에서 논의하고 있는 것을 본다.위키백과 기사의 주요 텍스트가 창 크기에 맞게 잘 조정되지 않기 때문에 그것은 관련 없는 주제다.기본 글꼴 크기에서는 1920년도의 창/스크린에서 위키피디아를 읽는 것이 매우 어려워지고, 때때로 더 넓은 글꼴을 사용할 수 있다(2560px 폭).본문이 Arial에서 한 줄에 200자 이상이면 참조용 umpteen 칼럼을 갖는 것은 오히려 무의미하다. 왜냐하면 보통 사람들은 그렇게 편안하게 읽을 수 없기 때문이다.Tijfo098 (대화) 2010년 12월 20일 13:17 (UTC)[응답하라]

어떤 사람들은 네가 말한 그 문제를 가지고 있을지도 몰라.그들을 위한 해결책은 그들의 브라우저 창의 크기를 줄이는 것이다.그러나 한편, 창문 크기에 따라 기둥의 수가 줄어들어야 하지 않을까?—벤더235 (대화) 13:40, 2010년 12월 20일 (UTC)[응답]

당신은 어떻게 참조의 수가 열 수에 대한 결정 요인이 되는지 설명하지 않았고, 그것이 당신의 제안이 주로 무엇에 관한 것처럼 보인다.나는 "씨앗"이라고 말한다. 왜냐하면 그것은 아주 자주 변하는 것처럼 보이기 때문이다.Tijfo098 (대화) 15:09, 2010년 12월 20일 (UTC)[응답]

이전에 설명했지만 그럼에도 불구하고: 20개의 ref가 칼럼의 최소가 되어야 한다. 왜냐하면, ref가 적으면, 기존 ref에 비해 너무 많은 열이 있기 때문이다. (1개의 ref가 두 개 또는 열로 분할될 수 있는데, 그것은 보기에 좋지 않다.)따라서, 기둥은 일반적으로 유용하지만, 작업할 참조가 너무 적으면 유용하지 않다.—벤더235 (대화) 17:08, 2010년 12월 20일 (UTC)[응답]

WP:CREP에 반대하십시오.나는 왜 이 문제가 고쳐져야 하는지 이해할 수 없다.아래 - CharlesGillingham (대화) 20:38, 2010년 12월 20일 (UTC)[응답하라]를 참조하십시오.

• 반대하라. 여기서는 특정 형식을 의무화하는 정당한 이유를 볼 수 없다.--Kmhkmh (대화) 19:40, 2010년 12월 21일 (UTC)[응답]
• 우리가 단순히 너무 좁은 35em이 아닌 30em을 사용하는 한 반대하라.나는 그 개념을 지지하지만, 세부사항에는 악마가 있다.내 화면이 1920년 1080년이라고 해서 브라우저가 항상 전체 화면으로 설정된 것은 아니다.나는 여기서 2, 3을 디폴트한다고 생각하지 않는다, 명령하는 크리프라고.단, 시각적 영향이 크므로 합의와 긍정적인 피드백 없이 구현해서는 안 된다.라스베이거스위키안 (토크)20:15, 2010년 12월 21일 (UTC)[응답하라]

"단순히 너무 좁은 35em이 아닌 30em을 사용하는 한 반대"

정확한 값(폭)은 제안서의 일부가 아니다.이것은 단지 "colwidth"를 사용하도록 권고한 것일 뿐, 특정 폭을 사용하도록 권고한 것은 아니다.당신이 옳기 때문에, 30em은 어떤 페이지에는 너무 좁다(확실히 전부는 아니지만, 어떤 경우에는 너무 넓다).—벤더235 (대화) 03:40, 2010년 12월 22일 (UTC)[응답]

대체 제안 2: 기능 제거

현재 {{reflist}}이(가) 여러 열을 생성할 수 있는 파라미터를 제거한다.

{{reflist}}의 칼럼 폭 파라미터와 그것이 제공하는 기능성은 독자에게 정확하고 검증 가능한 내용을 제공하는 데 필수적인 부분이 아니다.그것은 불필요하다.백과사전을 해치는 방법은 다음과 같다.

1. 이 기능을 설명하면 설명서가 복잡해지고 새로운 편집자가 필요한 정보를 찾기가 더욱 어려워진다.
2. 그것은 새로운 편집자들의 학습 곡선을 연장시킨다. 왜냐하면 그들은 기사에서 이 특징을 발견했을 때 연구하는데 시간을 낭비할 것이기 때문이다.
3. 편집자들은 이 기능을 사용하는 최선의 방법에 동의하지 않으며, 그들의 의견 불일치는 덜 신경쓸 수 있는 다른 편집자들에게 불필요한 혼란이다.
4. 만약 이 기능이 버그를 가지고 있거나 미래에 버그를 개발한다면, 이러한 버그는 파괴적일 것이다.이 기능이 존재하지 않으면 버그를 개발할 수 없다.
5. (위에서 제안한 바와 같이) 이 기능에 WP가 필요한 경우:MOS 규칙, 그리고 나서 그것은 편집자들이 더 많은 작업을 할 것을 요구한다: 그들은 규칙을 배워야 하고 그들은 규칙을 따르도록 기사를 고쳐야 한다.
6. (위에서 제안한 바와 같이) 이 기능에 WP가 필요한 경우:MOS 규칙, 그렇다면 위키피디아의 300만 + 기사는 이 규칙이 시행되는 것을 확인하기 위해 지속적인 유지보수가 필요할 것이다.이 기능이 존재하지 않는다면 이 유지보수는 불필요할 것이다.

이러한 이유로 나는 {{reflist}}의 '칼럼' 기능이 백과사전의 가장 큰 관심사라고 생각하지 않는다.

주의사항: 그러나 "칼럼" 기능이 {{reflist}}에 내장되어 있거나, 아니면 더 나은 Cite 그 자체라면, 내 주장은 하나도 적용되지 않는다.나의 주장은 사용자가 통제하는 매개변수의 존재에만 적용된다.칼럼 자체가 아니라 ---- 찰스길링엄(토크) 20:38, 2010년 12월 20일 (UTC)[응답]

지지. (제안대로) ----- Charles Gillingham (대화) 20:38, 2010년 12월 20일 (UTC)[응답]

반대 어떠한 것도 쓰여진 미린이 이 특정한 특징에 다른 템플릿보다 더 많이 적용된다.독자들에게 유용하다고 생각하지 않는다고 해서 아무도 그렇게 하지 않을 것이라는 뜻은 아니다. --Jayron32 21:08, 2010년 12월 20일 (UTC)[응답]

'문제'를 해결할 방법이 아니라 반대하라. --SerkOfVulcan (대화) 21:22, 2010년 12월 20일 (UTC)[응답]

반대 열거된 문제들 중 가장 현학적인 의미 외에는 어떤 것도 실제로 문제가 되지 않는다.Anomie december 21:59, 2010년 12월 20일 (UTC)[응답]

반대하다. (1), (2), (5): 새로운 편집자들이 미디어위키의 모든 뉘앙스를 배우리라고는 아무도 예상하지 못한다.고치는 데는 항상 베테랑 편집자들이 있을 것이다.(6)에: MOS 권고사항이 밤새 위키백과의 3m 이상의 모든 기사에 "강제"될 필요는 없다.어떤 기사들은 이것을 절대로 실행하지 않는다 해도 세상은 끝나지 않을 것이다.On (4) : 컬럼(고정 및 유연성 모두)은 구형 브라우저에서 지원되지 않는다(CSS3 기능이기 때문에).그러나 나는 그것을 문제로 보지 않는다.오래된 브라우저가 열을 보지 않는다고 해서 적어도 어떤 브라우저에서는 열을 볼 수 없다는 뜻은 아니다.(3)에:이 논의의 목적이 바로 이것이다. P.S: "색깔"은 인용에 직접 실행되어서는 안 된다.php, 왜냐하면 그것들은 모든 물품에 적합하지 않기 때문이다.—벤더235 (대화) 23:17, 2010년 12월 20일 (UTC)[응답]

반대하다. 우리가 어떤 것을 어떻게 사용하는지에 대해 동의할 수 없다고 해서 우리가 그것을 꺼내야 한다는 뜻은 아니다. — Edokter • Talk — 23:34, 2010년 12월 20일 (UTC)[응답]

강한 반대; 유용한 스타일링 옵션을 제거할 필요가 없으므로 참조가 많은 페이지는 독자들에게 혼란스럽고 혼란스러울 것이다. --Errrant 09:51, 2010년 12월 21일 (UTC)[응답]

반대하다. 나는 그 특징을 없애야 할 정당한 이유가 없다고 본다. 왜냐하면 나는 그것을 의무화해야 할 정당한 이유가 없다고 보기 때문이다.모든 것에 맞는 신발도 없고 게다가 그런 신발은 필요 없다.정말 중요한 것은 출처를 쉽게 읽을 수 있고, 어느 쪽이든 달성할 수 있다는 것이다.--Kmhkmh (토크) 19:45, 2010년 12월 21일 (UTC)[응답]

반대한다. 매우 유용한 기능을 사용하는 것을 멈출 이유가 없다.이것은 우아한 실패 특징을 가진 하나의 특징이다.브라우저에서 지원하지 않는 포맷은 이것 없이 될 것이다.라스베이거스위키안 (토크)20:19, 2010년 12월 21일 (UTC)[응답하라]

"Author year" 목록과 별도로 온건한 지원은 이것이 잘 작동할 것이다.Rich Farmbrough, 01:31, 2010년 12월 22일 (UTC)
[답글]

반대한다. 특히 대부분의 사용자에게 4개의 열이라도 잘 맞을 수 있는 50여 개 문자의 긴(100+) 참조 목록에는 유효한 용도가 많다.실제 주장은 대부분의 파라미터에 적용 가능하다.대부분의 템플릿 매개변수 설명서는 복잡한 문서, 편집자는 지속적으로 동의하지 않으며, 어떤 기능도 미래에 버그를 가질 수 있으며, MoS 규칙이 이미 존재하기 때문에 이 규칙이 어떤 것도 변경하지 않을 수 있으며, 모든 기사는 이미 수십 개의 MoS 규칙을 적용해야 한다.— HELLKOWNZ ▎토크 13:14, 2010년 12월 23일 (UTC)[응답]

반대 — 칼럼 사용에 대한 공식적인 규칙이나 지침이 없다고 해도, 일반적으로 위키백과 기사의 발표(어쨌든 내 의견)를 향상시킨다고 생각한다.나는 우리가 그 특징을 유지하고 어떤 필요를 충족시키기 위해 그것을 개선하기 위해 노력하기를 원한다.관심 있는 사용자가 이를 보증할 수 있을 만큼 충분한 경우, 참조 목록을 하나의 열로 유지하는 사용자 선호도가 있을 수 있다.CF84 (토크) 21:02, 2010년 12월 25일 (UTC)[응답]

이 제안에 대한 제안

새 코너를 개설해서 미안한데, 이걸 어디에 놓아야 할지 모르겠어.

나는 위키피디아의 모든 내부 작업에 대한 전문가는 아니지만, 현재 양식의 참조 리스트의 모양과 행동은 위키피디아가 어떻게 개선될 수 있는지에 대한 어느 정도의 논의를 보장한다고 생각한다.아마도 여기서 정확히 무엇을 제안해야 하는지에 대해 좀 더 논의가 있어야 할 것이다. 왜냐하면 나는 당신이 제안하는 것 외에 많은 가능한 해결책들이 있다고 보기 때문이다.만약 우리가 참고자료가 어떻게 표시되는지 개선해야 한다는 데 의견을 모을 수 있다면, 공식 제안을 내놓기 전에 어떻게 그것이 달성될 수 있는지에 대한 제안을 할 수 있을 것이다.예를 들어 사용자 에이전트(클라이언트측 스크립트?)를 고려해야 한다고 생각한다.중간, 해상도, 브라우저 지원 등을 고려해야 하며, 열 수에 어느 정도 상한선이 있어야 한다.그런 다음 예외적인 경우를 위해 템플릿 매개 변수를 사용하여 이 동작을 재정의할 수 있다.하지만 그것은 단지 하나의 아이디어일 뿐이고, 아마도 그것을 제안하고 많은 !보트를 얻기 전에 그것을 기반으로 구축될 수 있을 것이다.아마도 WP 절차상의 모호함에 대해 더 많은 지식을 가진 누군가가 당신에게 어떻게 시작해야 하는지 알려줄 수 있을 것이다.나는 확실히 리플리스트의 외모를 개선하는 데 관심이 있다고 말할 수 있다. :-) 그것이 잘난 체하는 것처럼 보이지 않았기를 바란다. 당신은 인터웹에 대해 전혀 알지 못한다. 또한, 내가 누군가를 초대해서 생선으로 때리는 경우는 내가 틀렸을지도 몰라. :-) 메리 크리스마스!CF84 (토크) 21:48, 2010년 12월 25일 (UTC)[응답]

삭제 토론에서 업로더/작성자

이에 따라 관련 삭제 논의(AFD, TFD, RFD 등)에서 업로더/크리에이터를 템플릿의 일부로 언급하는 것이 좋을까?레만 10:56, 2010년 12월 22일 (UTC)[응답]

나는 그런 생각에 강력히 반대할 것이다.파일 내용과 저작권 상태는 종종 공정한 사용 등의 정당성을 위해 업로더의 입력을 필요로 한다.창조자를 다른 과정에 나열하는 것은 내용에서 저자로 디쿠시온을 이동시킬 가능성이 너무 높다.짐 밀러 ^{See me Touch me} 19:55, 2010년 12월 22일 (UTC)[응답]

그 이유는 창작자가 댓글을 달면 발견하기가 더 쉬울 것이기 때문이다.나는 이 변화가 큰 문제가 아니라고 확신한다; 단지 템플릿에 몇 개의 문자를 추가하는 것만으로...레흐만 01:33, 2010년 12월 23일 (UTC)[응답]

나는 아직도 우리가 왜 이 정보를 원하는지 의문이다.우리는 창조자가 제안된 삭제안에 대해 논평하기를 기대하며, 우리는 그것이 제안될 때 그들의 의견을 다른 편집자들만큼 헤아린다.삭제 토론에서 템플릿의 작성자를 식별하여 얻을 수 있는 것은?삭제 논의와 실질적인 관련이 없고, 어떤 식으로든 다른 논평자에게 편견으로 작용할 수 있는 정보를 추가하는 것 같다.짐 밀러 ^{See me Touch me} 14:27, 2010년 12월 23일 (UTC)[응답]

예를 들어, TFD에서 작성자가 미사용 템플릿에 대해 코멘트를 하는 경우, 템플릿 존재의 의도(작성자가 코멘트를 하는 경우), 또는 의견/제안/코멘트(다른 사용자가 코멘트를 하는 경우)를 쉽게 이해할 수 있다.나는 이것이 매우 유용하다고 생각한다.그것은 작은 개선이고, 관련 편집도 그렇다.레만 02:45, 2010년 12월 24일 (UTC)[응답]

인명 표시:날짜 및/또는 생활 상태 포함

예를 들어, 나는 종종 영화의 배역들의 목록을 보고, (구영화의 경우) 아직 생존하고 있는 것이 있는지 궁금해 한다.

아마도 생년월일을 표시하거나(혹은 생년월일을 표시하거나, 생년월일을 표시하면 표시 가능하도록 한다) 단순히 한 가지 방법으로 이름을 표시하는 것이 유용할 것인가?

관련된 출연진들은 위키백과 영화 기사에 일반적으로 모든 출연진들이 나열되지 않는다는 점에서 다른 모든 영화에 대해 특집기사가 될 수 있다.--Jrm2007 (토크) 03:53, 2010년 12월 23일 (UTC)[응답]

대부분의 유명 배우들은 자신만의 기사가 있기 때문에, 목록에 있는 이름들이 위키와 연결되어 있다면, 당신은 "내비게이션 팝업" 기기를 사용할 수 있다.대부분의 전기 기사에는 DOB(및 해당되는 경우 DOD)가 첫 번째 문장에서 사용자 이름 옆에 괄호화되어 있으므로, 링크된 이름 위에 마우스를 올려 놓으면 날짜를 알 수 있다.살아있거나 죽은 상태 목록 같은 것은 일반적으로 영화 기사와 관련이 없을 것이라는 것이 내 의견이다.링크 위에 마우스를 올리면 기사의 infobox에서 특정 정보를 표시하는 사용자 지정 스크립트를 코딩할 수 있으며 링크에는 추가 정보가 있음을 나타내는 사용자 지정 스타일이 있을 수 있다.멋질 거야.CF84 (토크)20:38, 2010년 12월 25일 (UTC)[응답]

네가 기술한 그 기계는 유용할 것 같아.하지만 생년월일이 생물학에서 사람의 이름 바로 다음에 나열된다는 사실은 실제로 누군가가 생사하는 것이 관심의 대상이기 때문에 인명명 표시에 암호화되어 있는 이 정보가 비합리적인 것이 아니라 어쩌면 단순히 아직까지도 누군가의 이름 뒤에 있는 상징이 될 수도 있다는 것을 단언하고 싶다.사는 것(그러나 십자가는 논란의 여지가 있을 것 같다).내가 이 가젯을 이해한다면 꼭 다운로드해야 하는 물건인가?만약 그렇다면, 이것은 아마도 많은 사람들이 그것을 이용할 수 없게 만들 것이다; 예를 들어, 나의 엄마와 아마 너의 엄마와 같이.우리 아빠는 확실히 그런 대본을 다운로드 받을 수도 없었고 심지어 그럴 필요성도 이해하지 못했을 것이다.Jrm2007 (대화) 22:21, 2010년 12월 25일 (UTC)[응답]

대부분의 경우, 나는 이 정보가 단순히 높은 유지보수의 혼란일 것이라고 생각한다.거의 모든 사람이 결국 죽는 것 같기 때문에 높은 유지보수를 하는 것이고, 이 변화는 그들이 죽으면 우리가 단지 그들에 대한 기사를 업데이트하는 것이 아니라 그들을 언급하는 모든 기사를 업데이트하는 것을 의미할 것이다.대부분의 경우 개개인의 생년월일은 영화나 스포츠 행사에 관한 기사와 거의 무관하기 때문이다.그러나 각각의 날짜는 참조되어야 올림피아드의 참조 부분이 참가자들의 다음 오보에 대한 참조의 숲이 될 수 있을 것이다.2010년 12월 26일 (UTC) :erSpielCequers 00:30, 회신

나는 그것이 당연히 자동화되는 것을 상상한다; 관련 기사가 있는 어떤 이름이라도 DOD를 조회하여 이름을 표시하는 방법을 결정할 것이다.나는 인간에 대한 모든 언급이 DOB/DOD와 함께 해야 하고 따라서 모든 곳에서 업데이트 되어야 한다고 결코 제안하지 않을 것이다.Jrm2007 (대화) 02:22, 2010년 12월 26일 (UTC)[응답]

내가 그렇게 할 수 있는 유일한 방법은 출연자 명단에서 사용할 수 있는 배우 이름 템플릿이 있을 것이고, 그러면 그 배우를 위한 템플릿을 간단히 변경하면 출연자 명단이 포함된 모든 출연자 명단이 업데이트될 것이다.하지만 실행이 번거로울 수 있다. -- ۩ 마스크 05:51, 2010년 12월 27일 (UTC)[응답]

이 모든 것에 필요한 것은 무엇인가?다른 사이트와 달리 위키피디아는 영화와 각각의 배우에 대한 항목을 둘 다 가질 수 있다.이 제안은 출연자들의 사생활이나 경력이 아닌 영화인 그들의 주제에 초점을 맞추는 데 도움이 되지 않는다.만약 배우가 촬영 중에 죽거나, 영화가 새로운 영화로 상영되는 몇 달 동안에 죽는다면, 그것에 대해 이야기할 가치가 있을지도 모르지만, X 배우가 그것을 찍은 지 30년 후에 죽었다는 영화의 기사에서 언급할 때 언급된 수많은 다른 영화들을 언급할 때 어떤 소용이 있을까?영화 그 자체와 무슨 상관이야?MBelgrano (대화) 11:48, 2010년 12월 27일 (UTC)[응답]

단지 다음을 명확히 하기 위해서.이것은 영화나 연기자에 관한 것이 아니다. 이것은 전기적인 이름들에 관한 것이다.나는 이름이 표시되는 방식이 그 사람이 살아있는지 죽었는지 자동으로 암호화되어야 한다고 제안하는 것이다. 아마도 색깔이나 서체나 이름 뒤에 있는 기호로 말이다.나는 각각의 장소에서 이름이 언급되는 것을 제안하는 것이 아니다. 누군가가 들어가서 이 정보를 덧붙이고 물론 그것을 유지한다.

기사에 나오는 사람의 이름을 볼 때마다, 예를 들어, 영화의 출연진들을 나열하는 사람의 이름을 볼 때마다, 나는 그 사람이 아직 살아 있는지 궁금하다는 것을 단순히 알아챘다.어쩌면 나 혼자만 이러는 것인지도 몰라, 그런 경우에는 신경 쓰지 마.--Jrm2007 (대화) 19:02, 2010년 12월 27일 (UTC)[응답]

개인적으로, 나는 약간의 잠재적인 이익을 볼 수 있었지만, 나는 그것이 비용(즉, 유지 보수 노력)보다 더 크다고 생각한다.

한편, 위키피디아가 이미 누군가에 대한 전기적 정보를 가지고 있다면, 그들의 이름은 파란색 링크가 되어야 한다. 따라서 그들의 상태에 대한 추가 정보는 클릭 한 번이면 된다.

보브레이너 (대화) 03:34, 2010년 12월 28일 (UTC)[응답]

어떤 유지 보수 작업?제안대로 기존의 전기 정보에 접근하는 자동 기능이다.Jrm2007 (대화) 07:05, 2010년 12월 28일 (UTC)[응답]

설명되지 않은 삭제 자동 되돌리기

상당량의 내용을 삭제하고 편집 요약이 없는 편집(예: 이 편집 요약)은 자동으로 되돌릴 것을 제안한다.86.184.232.12 (대화) 14:48, 2010년 12월 27일 (UTC)[답답하다]

• 반대한다. 만약 그러한 콘텐츠가 제거되어야 한다면 어떻게 될까?만약 그것이 공공 기물 파손이라면, 그것은 어쨌든 서든체인지스 패트롤러나 페이지 감시자에 의해 되돌아갈 것이다.그리고 반달(Bandal)이 IP라면 경고나 차단, IP와 같은 일반 사용자라면 경고나 차단, 오토레뷰어라면 권리가 취소된다.레흐만 15:07, 2010년 12월 27일 (UTC)[응답]

여기서의 결함은 "만약 그것이 반달리즘이라면, 그것은 어쨌든 되돌릴 것이다"라는 진술이다.이것은 확실히 항상 그런 것은 아니다. (나의 링크는 수많은 예들 중 하나일 뿐이다.)내용을 합법적으로 삭제하는 사람들에게 간단한 설명을 요구하는 것은 그다지 부담스럽지 않으며, 어떤 경우에도 대개는 이미 행해져 있다. 86.184.232.12 (토크) 18:30, 2010년 12월 27일 (UTC)[답답하다]

• 코멘트 - 나는 이것과 함께 울타리 위에 있다.한편으로 그들은 여름 편집기를 사용해야 하기 때문에 그들이 의심스럽지 않다면 다른 한편으로 그것이 공공 기물 파손이라면 우리는 여름 편집기를 그대로 두어서는 안 된다.내 직감으로는 대부분의 반달리즘은 여름을 가지고 있을 것이라고 말하지만 나는 확실하지 않다.어떻게든 여기서 타협점을 찾을 수 있는 방법이 있어야 할 것 같다. --쿠미오코(토크) 18:37, 2010년 12월 27일 (UTC)[응답]

나는 대안으로 이 자동 반전이 익명의 편집자에게만 적용될 수 있다는 것을 언급하는 것을 잊었다.아마도 "undo" 행동도 제외될 수 있을 것이다.86.135.25.173 (대화) 18:43, 2010년 12월 27일 (UTC)[답답하다]

• 반대 극도의 일상적인 반달리즘(약간 결정된 반달리즘도 편집 요약을 삽입할 필요가 있다는 것을 빨리 알아낼 수 있기 때문에 거기서 효과적이지 않을 것이다)을 기사에 붙여진 30KiB의 반달리즘을 제거하려는 신입생을 물릴 때까지 막는 것이 좋은 생각이다.Anomie december 20:36, 2010년 12월 27일 (UTC)[응답]

아논에 의해 많은 양의 삭제를 되돌리는 봇이 있다.Corvus_talk cornix 22:46, 2010년 12월 27일 (UTC)[응답]

있어야 하는데, 그 증거는 그것이 신뢰성 있게 작동하지 않는다는 것이다(예를 들면 왜 이것을 되돌리지 않았는가).한때는 그걸 추구하려고 했지만 아무런 관심도 얻지 못해서 포기했지...나는 이것이 정말 같은 제안이라고 생각한다: 봇을 안정적으로 작동시키도록 하라. (토크) 02:27, 2010년 12월 28일 (UTC)[답답하다]

아마도 충분히 큰 제거는 아니었을 것이다.페이지 전체를 비우는 것과 같이 가장 극단적이거나 노골적인 상황을 제외하고는 맹목적으로 되돌려서는 안 되는 내용을 삭제하는 데는 타당한 이유가 충분하다.미스터 지만 03:52, 2010년 12월 28일 (UTC)[응답]

자동 입력 편집 요약 및 개요 삭제 이전 시절로 돌아가 이 문제에 대한 추가 주의를 환기하지 않기 위해 편집 요약이 없는 현재 BLP 위반을 되돌리곤 했다.나는 오늘날 사람들이 선의로 같은 행동을 하는 것을 상상할 수 있다.Rmhermen (대화) 2010년 12월 28일 (UTC) 15:36 [응답]

• 내가 그 이면의 이유를 이해할 수 있지만, 이것에 반대해야 한다.나는 반달리즘, BLP 위반, 포괄적 금지를 지지하기 위한 비위생적인 자료들을 제거함으로써 백과사전을 개선하는 IP들의 예를 너무 많이 보았다.알자리아16 (대화) 2010년 12월 28일 (UTC) 16:22 [응답]

인용문 업데이트.영국 영어 php 메시지

Cite 각주 시스템을 위한 MediaWiki 인터페이스 페이지는 영어 위키백과에서 크게 사용자 정의되었다.현재, 만약 당신의 선호에 설정된 언어가 en-GB(영국식 영어) 또는 en 이외의 언어라면, 대부분의 인터페이스 페이지는 기본값으로 설정된다.이는 참고문헌의 인용문에는 en 관습 대신 ↑이 표시되며, 그 밖의 여러 변경사항이 있음을 의미한다. 이것은 또한 오류 메시지에 사용자 정의 메시지처럼 도움말 페이지에 대한 링크가 없다는 것을 의미한다.

enGB 인터페이스 페이지를 en 인터페이스 페이지로 업데이트하여 enGB를 설정한 사용자도 동일한 보기 및 편집 경험을 가질 것을 제안한다.

en 인터페이스 페이지가 변경될 때 en-GB가 업데이트될 필요가 없도록 단순히 리디렉션을 만드는 것이 가능한가?

---- Gadget850 (Ed) 04:57, 2010년 12월 28일 (UTC)[응답]

언어선택의 유용성

(위 논의에서 화합에 대한 반대)

그냥 지나가는 사람이 남긴 메모:에 관한 수많은 지역들이 있다.en업데이트되지 않음en.gb그리고 많은 다른 언어들, 이 위키뿐만 아니라 대부분의 다른 위키에도 있다.예를 들어 로그인한 경우xx.wiki에en인터페이스는 영어로 표시되지만, 만약 있다면en.gb하지만 대부분 그 언어는 저장되지 않았다.en.gb인터페이스가 거의 100%와 동일en접점위키 콘텐츠(아티클)는 어떤 영어 변종을 사용해야 할지에 대한 정책을 가지고 있고, 랭크 변종을 선택한다고 해서 내용이 실제로 바뀌지는 않기 때문에, 때로는 특정 영어 변형을 모두 삭제하는 것이 실제로 더 나을지 궁금할 때도 있다(아티클).en.us,en.gb, 또는 어쩌면 인도는 하루라도.en.in, 등) 그리고 오직 하나의 영어 인터페이스를 사용한다...그렇게 나쁘진 않을 거야...레흐만 05:11, 2010년 12월 28일 (UTC)[응답]

나는 왜 사람들이 엔을 그냥 사용할 수 없는지 이해할 수 없다.핵심 미디어위키 소프트웨어에는 전체 2833개 중 en과 다른 메시지가 23개에 불과하다.그 중 15개는 EXIF 태그 설명이고, 하나는 여기서 사용할 수 없는 특수 페이지를 위한 것이다.지역적으로 정의된 것은 6개뿐이다.미스터 지맨 07:10, 2010년 12월 28일 (UTC)[응답]

이것은 바보처럼 들릴 수도 있지만, en.gb을 완전히 제거하면 어떤 결과가 나올까?아무 소용이 없는 것 같은데...2010년 12월 28일(UTC) 레흐만 11:53[응답]

우리는 오래 전에 이 토론을 했다. - 약간의 반대가 있었지만, 지금은 기억이 나지 않는다. ---- - Gadget850 (Ed) 13:30, 2010년 12월 28일 (UTC)[응답]

MediaWiki에 언어를 추가하거나 제거하는 것은 enwiki 커뮤니티의 권한 내에 있지 않다.나는 이 특정한 지역 사투리가 여기 이 특정한 프로젝트에 제한적으로 사용된다는 것에 동의하지만, 근본적으로 그것은 어떤 다른 언어의 변종들과 다를 바 없으며, 그 중 일부는 매우 정치적, 문화적 중요성이 크다(그리고 많은 공동체 긴장감의 원천:T25217 등).우리는 프랑스어 메시지를 영국 메시지와 일치시키기 위해 어떤 노력도 하지 않는다. 그리고 이것은 전혀 다르지 않다.Enwiki는 "영어(영국)"나 "영어(미국)" 또는 "영어(uʍop ǝpısdn)"가 아닌 "세계(world)"로 쓰여져 있으며, 완전한 enwiki 경험을 원한다면, 당신이 말한 대로 적절한 인터페이스 언어를 사용한다.그러나 인터페이스에 사용할 수 있는 언어는 enwiki 커뮤니티 문제가 아니라 MediaWiki 개발 문제다.해피멜론 15:25, 2010년 12월 28일 (UTC)[응답]

나는 원래 논의의 응집력을 유지하기 위해 이 부분을 나누었다.기본 설정 페이지에는 371개의 언어를 사용할 수 있다. 내가 보기엔 업로드 대화상자에 사용되는 MediaWiki 인터페이스 페이지를 선택한다. 경고, 인용.php 각주 시스템 및 기타 무수한 용도이것들이 인터페이스 페이지의 번역된 버전으로 유지된다 하더라도 기사는 여전히 영어로 되어 있을 것이다.나는 텍스트의 기계 번역이 효과가 있다면 언어 선택이 유용할 것이라고 생각하지만, 그것은 다른 곳에서 논의되어 오고 있다.

특히 WMF가 국제화에 전념하고 있어 언어선택이 없어질지 의문이다.한 가지 해결책은 렌더링 시 인터페이스 페이지를 확인하는 것이다. 사용자 지정 영어 인터페이스 페이지가 있지만 선택한 언어의 사용자 지정 인터페이스 페이지가 없으면 영어 페이지를 사용하십시오.또 다른 방법은 기본 설정 페이지에 언어 선택이 하는 것과 하지 않는 것을 설명하는 노트를 추가하는 것이다. ---— Gadget850 (Ed) 16:31, 2010년 12월 28일 (UTC)[응답]

페이지 이동과 관련된 제안

안녕. 나는 요청된 이동에 대한 토론 링크를 올리기 위해 여기에 왔다.거기서 토론하는 사람들은, 내가 생각하기에, 우리가 해야 할 모든 것을 말했고, 우리는 합의에 도달하지 못했다(즉, 나는 납득할 수 없다.나는 위키피디아인들의 더 넓은 단면에서 더 많은 의견을 듣고 싶다.미리 댓글 달아줘서 고마워. -GTBaccus^(talk) 20:53, 2010년 12월 28일 (UTC)[응답]

노카체

제안: 확장 설치:MagicNoCache(또는 동등한 기능을 다른 방식으로 구현)를 수행한 다음 민감한 페이지에서 NOCACHE를 사용하십시오.이미 {{NOINDEX}}이(가) 있는데, 이건 합리적인 보완책인 것 같아.관련 노인덱싱(noindexing)을 요청한 후에도 일정 시간 동안 Google에서 볼 수 있음...NOINDEX는 항상 검색 엔진에 들어가지 않도록 관련 템플릿 중 일부에 추가되어야 한다.Rd232 13:01, 2010년 12월 28일 (UTC)[응답]

• 이거 무슨 문제라도 있는 거야?
  • 기사 링크를 자동 관리하는 프랑스어 위키백과(Wikiwix I think)는 실행될 경우 현지 사용 방법에 따라 영향을 받을 수 있다.
  • 그것이 실행되어야 하는지 아니면 실행되어서는 안 되는지는 모르지만, 많은 사람들이 삭제된 캐시된 버전을 사용한다는 것은 사실이다. 예를 들어, 삭제 템플릿에 그것을 추가하는 것이 영향을 미칠 수 있다.
  • 마찬가지로, 속도를 위해 캐시된 버전에 대한 링크를 사용하는 것이 일반적이다. 여기에는 텍스트 전용 버전이 포함된다.
• 그것들은 큰 문제가 아닐 수도 있고 이것이 실제로 어떻게 작용하는지에 대한 혼란에 기초할 수도 있다.그럼에도 불구하고, 이것은 모든 측면을 고려하기 위해 철저히 탐구되어야 한다.
  {{NOINDEX}} 템플릿은 8,7,5천 번을 초월한다.흠. –화이트호스1 13:50, 2010년 12월 28일 (UTC)[응답]

나는 그 연장이 네가 생각하는 것과 같지 않다고 생각한다.이 확장은 MediaWiki 내에서 페이지가 캐시되는 것을 방지한다.그것은 구글의 캐시 같은 것에는 영향을 미치지 않을 것이다.미스터 지맨 2010년 12월 28일 (UTC) 16:38[응답]

메, 내 말은 그런 뜻이 아니야.NOINDEX의 no-index HTML 헤더에 해당하는 no-cache HTML 헤더를 의미했다.Rd232 08:51, 2010년 12월 29일 (UTC)[응답]

감사합니다, Z-man씨.:) –Whitehors1 14:40, 2010년 12월 29일 (UTC)[응답]

이 기능은 미디어를 사용하지 않도록 설정하는 것이다.NOCACHE 동작 스위치가 있는 페이지는 액세스될 때마다 항상 데이터베이스에서 재생성되도록 Wiki의 내부 캐싱 아키텍처.Wikimedia 클러스터의 성능이 캐싱에 크게 의존하고 있기 때문에 sysadmins에 의해 그러한 행동이 허용될 수 있을지 의심스럽다.클러스터 서버의 90%는 캐슁된 데이터를 사용한다. 마지막으로 소프트웨어 에지 케이스가 캐슁 인프라가 작동하지 못하도록 막았을 때(마이클 잭슨의 사망), 서버에 대한 로드는 말 그대로 클러스터 전체를 잠갔다.이 기능은 NOCACHE를 크고 복잡한 페이지로 몰래 가져간 다음 이를 슬래시 도트하거나 다른 방법으로 가상 분산시키는 유혹적인 공격 벡터를 열어 데이터베이스 서버에 매우 높은 부하를 초래한다.바람직하지 않다.해피멜론 16:41, 2010년 12월 28일 (UTC)[응답]

내 실수야, 내가 원하는 대로 하고 내가 찾은 줄 알았던 내선 번호를 찾고 있었어.당연히 아니지!구글 등에 의한 외부 캐싱이 걱정된다.예를 들어, 의심스러운 제출의 캐싱을 방지하기 위해 새로운 페이지(<24시간, 예를 들어)에 추가할 수 있다.Rd232^talk 10:08, 2010년 12월 29일 (UTC)[응답]

나는 그것에 대한 또 다른 토론 마을 펌프 토론이 생각나서 검색을 했다.나는 내가 참여했다고 생각했지만, 나는 분명히 그것들을 읽었을 뿐이고, 너는 참여했어.
링크: WP:VP/T:#Deleted 페이지 캐시를 Google 및 WP에서 제거할 수 있음:VP/PR#Indexing을 위한 24시간 미만 페이지.비록 그 문제에 대해 토론이 많은 참여를 보이지 않았지만, 그것은 별로 지지를 받지 못한 것 같다.사람들이 제기한 요점을 볼 때 유용할 수 있다. –Whitehors1 14:40, 2010년 12월 29일 (UTC)[응답]

하, WP도 있어방금 찾은 NOCACHE, 구글 캐시 제거 요청 시 여기서 보이는 지시사항의 바로 가기입니다.(NOINDEXED 페이지인 경우, 페이지를 root.txt에서 제외했다고 체크하는 상자가 있다.)Rd232^talk 15:13, 2010년 12월 29일 (UTC)[응답]

저거 못 봤어!다른 대안이 있다. "위키피디아:'구글캐쉬'는 있지만, 이미 적용이 되었는지 아래 검색 결과를 확인해 보십시오.;) –Whitehors1 15:22, 2010년 12월 29일 (UTC)[응답]

확인, 도움말 작성:Google 캐시 제거(다음 기존 위키백과로 리디렉션):Google 검색 결과 삭제:()그러나 그것은 애초에 구글에 의해 캐시되는 것을 막아야 하는지에 대한 원래의 문제를 다루지 못한다.Rd232 18:37, 2010년 12월 29일 (UTC)[응답]

문서에서 텍스트 강조 표시

안녕하십니까, 우선 죄송합니다만, 제가 이 제안을 반복하고 있는 것은 알지만, 자료실을 검색하려고 했는데, 200개 정도의 결과가 나왔고, 그 중 40 - 50개가 나왔다.)

데모(컨트롤은 사이드바에 있음)

요점은 다음과 같다.우리가 읽을 때 무언가를 강조하는 것은 흔한 습관이다.생산성을 높이고 향후 참고자료에 큰 도움이 된다.나 자신도 위키피디아를 참조할 때마다 그것이 매우 필요하다고 느꼈다.그래서 그것을 돕기 위해, 나는 이 확장(여기를 클릭)을 만들었는데, 나는 이것이 많은 위키백과 사용자들에게 도움이 될 것이라고 믿는다.또한 그것은 이 문제에 대한 해결책을 준다.의견을 게시하십시오. 이 기능이 위키백과에 제공할 가치가 있다고 생각되면 이 제안을 지지하십시오.

--Apeksharma (대화)20:43, 2010년 12월 29일 (UTC)[응답]

작성 프로세스 문서

알다시피, 이것은 위키백과 현상에 대한 일종의 주요한 재구성이지만(그리고 말이 사라진 후 헛간 문을 닫는 경우일 수도 있다) 그러나, 만약 기사 작성이 sysops로 제한된다면 백과사전은 훨씬 더 백과사전적(그리고 프로젝트에 있는 모든 사람들에게 훨씬 덜 번거로울 것이다)이 될 것이라는 생각이 오늘 떠올랐다.사람들이 새로운 기사 아이디어를 제안할 수 있는 AfC(창작을 위한 조항) 과정을 가지고 있었다.대부분의 경우 그것은 고무줄타기 과정이 될 것이다 - 누군가 기사를 제안하고, 그것은 2주 동안 앉아있지만 아무도 반대하지 않는다. 그러나 그것은 그들이 메인 스페이스에 도달하기 전에 많은 짜증나는 문제들을 멈출 기회를 줄 것이다.그것은 우리가 POV-forks, BLP 문제, 기사 명명 문제, 농담 기사, 그리고 공신력 문제를 토론하고, 기사를 사용자 공간에서 먼저 개발해야 하는지 아니면 기사 인큐베이터에서 먼저 개발해야 하는지 결정하고, 메타 구조(주제 영역 내에서 서로 다른 기사를 균형 있게 조정)를 훨씬 쉽게 만들며, 좌절하는 AfD를 많이 없애줄 것이다.프로젝트에 투입한 부적절한 내용을 옹호하려는 사람들과의 논쟁여러분들은 어떻게 생각하십니까? --Ludwigs2 23:49, 2010년 12월 21일 (UTC)[응답하라]

위키피디아가 있다:기사 인큐베이터, 누구에게나 열려있지만.우리는 또한 위키피디아의 하위집합인 보류 중인 AFC 제출을 가지고 있다.위키프로젝트 작성/제출용 문서.그게 네가 생각한 이유니?소리샘플1 (대화) 03:48, 2010년 12월 22일 (UTC)[응답]

인큐베이터는 삭제되었거나 삭제될 위험이 있는 재료에 대해서만 용도 변경됨.펜스&윈도우즈 03:59, 2010년 12월 22일 (UTC)[응답]

오 와우 - 나는 그것에 대한 전체 토론을 놓쳤다.나는 우리가 여전히 시간제한에 대해 논의하고 있다고 생각했다.지적해줘서 고마워.사운드비전1 (대화) 04:09, 2010년 12월 22일 (UTC)[응답]

다음 항목에 대한 사전 논의:자동 로그온이 아닌 사용자에 대한 새로운 페이지 작성 제한, 지원되지 않는 문서 작성에 대한 자동 확인, 새로운 사용자에 대한 RFC: 문서 작성 - 비지원 문서 작성에 대한 자동 확인펜스&윈도우즈 03:59, 2010년 12월 22일 (UTC)[응답]

음... 나는 사실 우리가 새로운 기사를 만드는 사람들의 능력을 제한하자는 것이 아니라, 오래된 아이디어를 위키피디아에 순간적으로 집어넣는 그들의 능력을 제한하자는 것이었다.그것을 사전 사용자화라고 생각해라 - 편집자들은 사용자 공간에서 자유롭게 기사를 만들 수 있다(AfC 과정의 일부일 수 있다), 그러나 지역사회는 여전히 그 아이디어가 메인 스페이스 현실이 되기 전에 그 아이디어를 검토하고 NPOV를 할 시간을 가질 수 있다.거꾸로 AfD라고 생각해 보라: 무작위로 날아드는 잡초 만 개를 잡초 잡초를 뽑으려 하지 말고, 애초에 괜찮은 씨앗만 심도록 함으로써 메인스페이스 콘텐츠를 조절하는 것이다. --Ludwigs2 05:06, 2010년 12월 22일 (UTC)[응답]

응, 그게 이전 제안서도 원했던 거야.펜스&윈도우 19:21, 2010년 12월 22일 (UTC)[응답]

미안하지만, 이것은 위키백과라는 바로 그 생각과는 반대인 것 같다. 보통의 위키백과 사람들이 도움 없이 그것을 할 수 없다면 기사 작성이 매우 낮은 수준으로 떨어질 것이다.나는 일반 관리자들이 일반 등록 사용자들보다 더 자주 만든다고 확신한다. 왜냐하면 사람들은 처음에 관리자로 선출되려면 적극적이어야 하지만 대부분의 콘텐츠는 비관리자들이 기여하기 때문이다.우리 관리자들은 지금 이대로도 바쁘다. 만약 우리가 모든 새로운 기사를 승인해야 한다면, 내가 예상했던 대로 창조가 급감하더라도, 우리는 매우 혹사당할 것이다.나이튼드 (대화) 01:13, 2010년 12월 28일 (UTC)[응답]

나는 펜스와 창문 & 나이튼드에 동의할 것이다.또한, 나는 작업량 문제를 강조할 것이다.현재, NPP는 위키백과 "생태학"에서 유사한 틈새를 차지하고 있다; 일부 제3자는 최근에 만들어진 모든 기사를 검토하고, 심각한 문제가 있는 기사를 걸러내거나, 아니면 고치기 쉬운 것을 고치기 시작할 것으로 예상된다.단, 특수:뉴페이지는 잠재적인 패트롤러 수가 관리자 수보다 훨씬 더 많음에도 불구하고 이미 엄청난 밀도를 가지고 있다.만약 그 일이 이미 다른 일로 바쁜 훨씬 더 작은 사람들에게 넘겨진다면 어떻게 될까?초안이 승인을 받기 위해 관리자에게 전달되기 전에 우리는 어떤 종류의 심사 과정이 필요할까?

¹적절한 기사작성 이력서를 가진 사람들이 만든 것 중에서 다수의 준수 기사를 만들어 낼 가능성이 있는 것.나는 이 제안에도 비슷한 면제가 적용될 것이라고 추측할 수 밖에 없다.그렇지 않다면, 작업량은 훨씬 더 많을 것이다.
보브레이너 (대화) 02:25, 2010년 12월 28일 (UTC)[응답하라]

어떻게 나한테 동의하는지 모르겠어!의견을 진술한 게 아니라 그냥 링크 몇 개를 올렸어.사실, 나는 WP를 통해 새로운 기여자들을 웃기는 아이디어를 어느 정도 좋아한다.비록 수천 개의 기사가 대규모의 밀린 채 쇠약해지는 잠재적 단점을 볼 수 있지만, AFC는 그들이 새로운 기사를 새로 만드는 것을 허락하지 않고 있다.펜스&윈도우즈 00:06, 2011년 1월 2일 (UTC)[응답]

이 제안의 핵심은 적절한 곳에 있지만, 우리는 이것을 알아내는 데 필요한 적극적인 편집자들이 많지 않다.지금도 일부 기사의 경우 NPP의 밀린 업무는 거의 한 달이나 길고 이것은 단지 버튼을 누르는 것과 관련이 있다.우리는 선의의 기고자들에게 기사 제출을 위해 한 달 동안 줄을 서라고 말하고 싶지 않다.이것은 새로운 사람들이 장기 편집자가 되는 것을 단념시킬 것이다.ThemeFromSpace 00:29, 2011년 1월 2일 (UTC)[응답]

대부분의 새로운 사용자들은 새로운 기사를 만드는 것으로 시작하지 않는다.신규 사용자의 75%가 기존 기사 편집부터 시작한다.문서를 처음 편집하는 사용자 중 80% 이상이 첫번째 문서를 삭제했다.미스터 지맨 00:53, 2011년 1월 2일 (UTC)[응답]

교육용으로 조작 페이지를 복원하는 제안

얼마 전에 위키피디아를 옮겼는데:위키백과에서 위작의 역사를 연구하는 데 관심이 있는 학자들과 같은 사람들을 돕기 위해 메인 스페이스 프로젝트 공간으로 위키백과에서 위작된 내용의 목록.이것은 짐보 웨일스의 이 인용구에서 영감을 얻었다.

"학생들에게 의도적으로 Wkipedia를 조작하라고 요구하는 것은 매우 나쁜 일이다...은행 경비원을 양성하는 반이라면 은행을 털러 반을 내보내지 않는다.배움의 경험이 될 수도 있겠지만, 여기 잘못 된 은행 강도 사건 50건의 리스트가 있는데, 한 건씩 조사해 봅시다..."

그러나, 원래의 가짜 기사들은 사용할 수 없기 때문에 교육 자원으로서의 그것의 유용성은 제한적이다.복원해서 위키백과의 하위 페이지로 옮기자고 제안하는 겁니다.위키피디아의 장난 목록, 그리고 그것들을 장난으로 표시한 템플릿으로 분명히 라벨을 붙였다.나는 이것이 위키피디아와 마주하고 있다는 것을 깨달았다.인정은 부정하지만, 만약 우리가 과거에 대해 결코 배우지 않는다면, 우리는 미래에 상황을 개선할 가망이 거의 없다.2010년 12월 29일(UTC) 08:14(Dcoetzee 08:14)[응답]

• [6] 사용자 공간에서 프로젝트 공간의 현재 위치로 이동한다는 말씀이십니까?나는 메인 스페이스로의 이전을 반대한다.프라임헌터 (토크) 2010년 12월 29일 (UTC) 12시 44분[응답]
  • 연구 목적의 프로젝트 공간에서 허위 자료를 풀어내는 것이 타당할 수 있다고 생각하지만, 자료의 실체가 명백해야 한다고 생각한다. --SmokeyJoe (토크) 13:27, 2010년 12월 29일 (UTC)[응답]
    • 나는 그것들을 분명히 날조라고 라벨을 붙이는 템플릿을 그들에게 추가하자는 제안을 위에 추가했다.나는 이것이 그들이 진짜 기사로 오인될 수 있다는 우려를 해소하는데 도움이 될 것이라고 생각한다.Dcoetzee 14:58, 2010년 12월 29일 (UTC)[응답]
  • 미안해, 프로젝트 공간 말이야.Dcoetzee 14:57, 2010년 12월 29일 (UTC)[응답]
• Dcoetzee, 당신이 잘 아는 누군가에게 그 페이지를 옮겼다는 사용자들의 편집자인가?–Whitehors1 14:02, 2010년 12월 29일 (UTC)[응답]
  • 아니, 난 그들을 전혀 몰라.돌이켜보면 내가 먼저 그들에게 물어봤어야 했지만, 어떤 이유에서인지 나는 삭제 토론 후 그것이 사용자화되었다는 인상을 받았다(이런 일은 일어나지 않았다).Dcoetzee 14:57, 2010년 12월 29일 (UTC)[응답]
• 목록에 그러한 성격의 하위 페이지를 포함하려면 엄격한 포함 기준이 있어야 한다고 생각한다.내 말은, 거짓말이 많다는 거야.예를 들어, 이것을 공부함으로써 배울 수 있는 것은 많지 않을 것이다; 마찬가지로 이것은 재미있지만 공부할 가치가 거의 없다.장소에서는, 아마도 메타: 물건인가?–Whitehors1 14:02, 2010년 12월 29일 (UTC)[응답]
  • 그 아이디어는 가치가 있지만 신뢰할 수 있는 제3의 출처에서 언급된 거짓말로 제한되어야 한다.A. di M. (대화) 2010년 12월 29일 14:25 (UTC)[응답]
  • 현재 리스트는 확실히 범위를 좁히는 '한 달 넘게 악화된 포획이나 언론에서 언급된 것'에 한정되어 있다(대부분의 가짜는 빨리 삭제된다).Dcoetzee 14:57, 2010년 12월 29일 (UTC)[응답]
• Derrick에게 미안한데, 나는 정확히 그 리스트에 있는 가짜 페이지를 복원하는 것에 반대한다. 왜냐하면 그것이 사기꾼들에게 더 많은 동기를 주기 때문이다.나는 가능한 한 반달에 대한 인정을 적게 원한다.나는 네가 그 목록을 프로젝트 공간으로 옮겨서 기쁘다. 내가 몇 년 전에 허구를 쓰기 시작했을 때 찾기 어려웠기 때문이다.하지만 나는 그것을 교육적인 목적이 아닌 이전의 제목, 이름, 사용자 등을 확인하기 위해 사용한다.학자들을 위한 속임수에 관한 교육 페이지까지, 당신은 이 위키다양성 페이지를 Detecting_and_preventing_hoaxes_in_wikis에 개발하여 Edward Owens나 [7]과 같이 상당한 외부 커버리지가 있는 극소수의 사례로 한정하기를 원할 것이다.(그런데, 위키다양성 페이지를 우리만의 조작 페이지로 연결해야 한다.) — — 캑터스라이터 18:45, 2010년 12월 29일 (UTC)[응답]
  • 만약 누군가가 정말로 연구를 위해 조작 페이지의 텍스트가 필요하다면, 그들은 항상 친절한 관리자에게 복사본을 요청할 수 있다.Anomie december 2010년 12월 29일 (UTC) 19:07 [응답]
• 나는 WP에 의해 삭제된 거짓말들을 되살리는 것에 강력히 반대한다.콩 및 WP:부정. 위키피디아의 거짓말 리스트는 충분히 좋지 않다. 여기 AFD가 더 많은 시간을 간청한 후, 그가 동등한 9위를 달성했다고 비웃는 거짓말쟁이가 있다.나는 위키 다양성 신문에도 그다지 만족하지 않는다 - 나는 속임수를 탐지하는 가이드를 쓰는 것을 고려했지만, 같은 이유로 그 생각을 포기했다: 왜 사기꾼들에게 탐지를 피하는 법을 말하는가?

유용한 것은 모든 사람들이 의심이 있는지 확인하도록 하는 것이다 - 장기간의 조작이 감지될 때, 그것의 역사는 종종 많은 선의의 편집자들이 그것을 정리하고, 맞춤법을 바로잡고 심지어 "이 페이지 전체가 가짜"라고 말하는 반달리즘 IP 편집으로 되돌아갔지만, 한 두 개의 참고문헌을 확인할 생각은 전혀 하지 않았다.ces 또는 약간의 검색을 한다.의심스럽다면 의심스럽지만 확인할 사람을 더 많이 데려올 수 있는 "호아스" 태그를 추가하십시오. 제대로 공급하고 재활하십시오.JohnCD (대화) 2010년 12월 30일 (UTC) 14:46[응답]

나는 존CD에 전적으로 동의하고, 또한 우리가 가능한 한 반달과 사기꾼들에게 인정을 적게 주어야 한다는 선인장 작성자의 의견에 동의한다.[ Retro00064 ▷인터뷰> 08:57, 2011년 1월 1일 (UTC)[응답]

우려는 이해하지만 근시안적인 것이 인지도를 부정하는 것이 가장 중요하다는 입장도 알게 된다.기고자 모집단에는 정기적으로 이직하고 있으며, 공공 기물 파손으로 얻는 첫 번째 경험은 전해지지 않고 있으며, 이는 궁극적으로 미래의 기만 행위가 발각되지 않을 때 기물 파손으로 인한 더 오래 지속되는 피해로 이어진다.비유하자면, 범죄가 신문에 실릴 때 모방 범죄를 부추기기도 하지만, 그것이 그러한 범죄를 언론에 노출시키지 않을 이유는 아니다.아마도 이러한 생각들 중 일부는 일반적인 안내를 통해 전달될 수 있을 것이지만, 실물을 대신할 수는 없다.Dcoetzee 12:51, 2011년 1월 1일 (UTC)[응답]

나는 리스트에 몇 개의 삭제된 장난감을 추가했다. 대부분은 다양한 거울에 남아 있기 때문에, 그것을 찾고자 하는 사람이 있다면 우리는 그것들을 주최할 필요가 없다.펜스&윈도우 18:10, 2011년 1월 2일 (UTC)[응답]

새로운 생각

위키피디아를 비디오 미디어로 만들어, 선생님이나 강사를 사용하여 위키피디아 주제를 칠판에 가르치는 수업으로 바꾸고 시각 보조기구를 사용하여 시각적 보조기구를 사용하여 메시지를 전달하십시오.

그리고/또는 위키대학을 만들면 크리에이터들이 비디오를 보고 난 후 쉽고, 중간이고, 어려운 학습 수준의 객관식 퀴즈를 만들 수 있는 선택권을 줄 수도 있다.사용자들은 로그인할 수 있고 그들이 치른 시험의 점수를 유지할 수 있을 것이다.— 209.105.142.191 (대화 • 기여) 19:31, 2011년 1월 1일 이전에 추가되지 않은 의견

위키다양성]은 이미 존재한다.~~GB팬 ~~19:43, 2011년 1월 1일 (UTC)[응답]

그리고 우리는 심지어 위키 다양성에 대한 기사도 가지고 있다:---— Gadget850 (Ed) 19:46, 2011년 1월 1일 (UTC)[응답]

위키미디어 커먼즈는 자유롭게 허가된 동영상을 받아들인다.펜스&윈도우즈 22:57, 2011년 1월 1일 (UTC)[응답]

명확히 하기 위해, Commons는 자유롭게 허가된 비디오, 하나의 허용 가능한 형식(Ogg Thera), 100MB 이하를 허용한다. — Gavia Immmer (talk) 23:05, 2011년 1월 1일 (UTC)[응답]

위키백과를 참조하십시오.위키프로젝트 강의실 조정. œ^™ 15:36, 2011년 1월 2일 (UTC)[응답]

특정 ENSO 시즌에 대한 개별 기사 작성

안녕. 이것은 특정 ENSO 시즌 기사를 만드는 주제에 대해 더 많은 토론을 하기 위해서야.고마워 ~AH1^(TCU) 19:52, 2011년 1월 2일 (UTC)[응답]

감시 목록 링크

미디어위키토크에서 토론을 시작했다.Watchlist-details/Archive 4# "Your watchlist"가 링크하는 페이지 변경에 대한 "Your watchlist" 링크 변경토론을 좀 더 가시적인 곳으로 끌고 와 달라는 부탁을 받고 여기로 가지고 왔다.댓글?— Train2104 (대화 • 기여 • 카운트) 21:49, 2011년 1월 2일 (UTC)[응답]

WP:요청된 병합

우리는 현재 WP의 깔끔한 절차를 가지고 있다.RM: 토크 페이지에 템플릿을 배치하고 WP에 대한 봇 업데이트를 하는 경우:RM은 훨씬 더 넓은 지역사회에 도달하기 위해서입니다.

WP:요구되는 병합 기능을 동일한 방식으로 만들 수 없을까?현재의 합병 제안은 때로는 몇 년까지 몇 가지 사항만 주변에 두고 수 년 동안 계속 열려 있다.WP와 같은 병합 토론 플랫폼 작성:RM은 놀랍도록 속도를 높일 수 있고 주제 밖에서 편집자들을 끌어들일 수도 있다.댓글?레흐만 01:44, 2010년 12월 2일 (UTC)[응답하라]

• BRD. 문제 해결. /ƒETECCOMMS/04:05, 2010년 12월 2일 (UTC)[응답]

WP와 같은 일은 없을 것이다.RM은 좀 더 활동적이거나 쿨한가?레흐만 05:54, 2010년 12월 2일 (UTC)[응답]

내 생각에 xe는 "가서 먹어봐, 사람들이 좋아하지 않으면 되돌리고 토론될 거야"라는 뜻인 것 같아.또한, 그것은 나에게 좋은 생각처럼 들린다. 왜냐하면 내가 최근에 문제를 상당히 경험했기 때문이다.Rd232 07:25, 2010년 12월 2일 (UTC)[응답]

• 응답이 없는 경우 템플릿을 제거해야 한다.보통, 그것은 너무 적은 수의 관찰자를 가진 더 작은 페이지다.합치는 것은 당연히 작은 페이지에 대한 최선의 해결책은 아니다.반응이 없다는 것은 보통 좋은 생각이 아니라는 것을 의미한다.--Wickey-nl (대화) 10:58, 2010년 12월 4일 (UTC)[응답하라]

좋아, 이상한 질문이지만, 무엇이 "WP:Requested Merge"가 WP:RM이 아닌 위의 응답에 해당하게 만드는가? (두 가지 모두 존재하지 않았고, 둘 다 제안되고 있는 것을 고려한다면)레만 11:33, 2010년 12월 4일 (UTC)[응답]

그와는 정반대로, 만일 합병 제안에 대해 (찬성이든 반대든) 대처할 관측자가 너무 적다면, 합병이 좋은 생각일 수도 있다는 것은 훌륭한 징조다.Rd232^talk 11:46, 2010년 12월 4일 (UTC)[응답]

나는 조심스럽게 합병 요청을 촉진하는 것에 대해 말하고 싶었다. (반대가 없는 한 그렇게 하라.)모든 페이지를 유용하게 보기 위해 자주 볼 필요는 없다.하지만 내가 좀 과민반응을 보였나봐, 반대 꼬리표를 뗐어.--Wickey-nl (대화) 12:08, 2010년 12월 4일 (UTC)[응답]

글쎄, 아무도 그 아이디어에 대해 언급하지 않는다고 해서 사람들이 모호한 페이지를 병합하는 습관을 가져서는 안 된다고 말하는 것은 공평하다.그것이 바로 이 제안이 도움이 되는 이유다: 모호한 페이지에서도 그러한 제안들이 적절한 관심을 받을 수 있도록 하는 것이다.Rd232^talk 12:15, 2010년 12월 4일 (UTC)[응답]

버튼 바로 위에!레만 12:28, 2010년 12월 4일 (UTC)[응답]

• 우리는 이전에 AfD의 이름을 "논의하기 위한 예술"로 바꾸기로 합의했지만, 합병을 포함한 "논의하기 위한 예술"로 바꾸기로 합의했지만, 그렇게 하는 기술적 특성은 그것이 실행되지 않았다는 것을 의미했다.위키백과 대화 참조:토의/제안1조(원래 [8])펜스&윈도우즈 01:14, 2010년 12월 6일 (UTC)[응답]

그것이 성공하지 못한 정확한 이유(IMO, 좋은 생각/제안이다)를 찾지는 못했지만, 이 제안은 전혀 새로운 영역을 만드는 것이기 때문에, 이 제안의 경우는 아닌 기존의 절차와 내용을 수정하는 것이 포함되기 때문에 만들어지지 않은 것이 아닌가 하는 의심이 든다.임명 편집자에게 연락하여 이 제안에 대해 어떻게 생각하는지 알아보겠다.레흐만 09:45, 2010년 12월 6일 (UTC)[응답]

• 업데이트: 방금 위키피디아를 발견했다.제안된 합병은 내가 전에 보지 못했던 것이다.이 제안에 대한 페이지가 이미 확보되었으므로, 이제 WP와 같이 봇이 페이지의 병합 제안을 업데이트하도록 하는 것은 단지 문제라고 생각한다.RM이 한다.나는 이제 필요한 봇 운영자에게 연락해서 우리가 무엇을 할 수 있는지 알아보겠다.레만 10:31, 2010년 12월 6일 (UTC)[응답]

  페이지 이름을 WP:요청된 합병, WP:요청된 움직임과 일치하도록 WP:요청된 움직임으로 바꿀 수 있는지 궁금하다.그럴 수 있을까?RM이동해도 괜찮을까, RM레흐만 32, 2010년월 6일ᆩ[응답]요청이.

내 봇이 이미 WP:PM. WP와 같은 방식으로 운영되지 않는다.RM; 그것은 밀린 보고에 가깝다.헤레j 19:39, 2010년 12월 6일 (UTC)[응답]

WP:RM에서 하는 방식 그대로 업데이트 될 수 있을까?내 생각엔 합병 템플릿을 수정해야 할 것 같은데, 그렇지?레흐만 00:06, 2010년 12월 7일 (UTC)[응답]

• 내 생각에, 여기서 가장 좋은 방법은 주요 WP에 밀린 업무 섹션을 추가하는 것이다.RM 페이지 (추가적인 2단계 헤더 섹션이 여기서 의미하는 것이다.예를 들어, "완성해야 할 머거" 같은 것, 아마도?).그러면 헤레즈의 봇은 24시간마다 업데이트 할 수 있을거야, 만약 그렇게 마음이 내키면."토론회"는 정치적인 이유로 일어나지 않을 것이다. 그래서 나는 그것을 기다리지 않을 것이다.— V = IR (Talk • 기여) 18:08, 2010년 12월 8일 (UTC)[응답]

• 참여자를 확보하는 문제 외에도 합병은 삭제, 이동 또는 리디렉션보다 구현에 더 많은 노력이 필요하다.{{afd-message from}}}부터 밀린 일이 364로, 진행해야 한다는 공감대가 형성돼 있다.플랫스캔 (토크) 05:29, 2010년 12월 9일 (UTC)[응답]

@OhmsLaw 및 Flatscan:그렇다면 현재 WP의 이름을 바꾸는 것은 어떨까.RM에서 "위키피디아:"토론용 조항"은 WP에서 삭제만 한 채 명칭 변경과 병합만 논의된다.삭제용 기사.그렇게 하면, 우리는 같은 페이지에 같은 봇에 의해 갱신된 병합과 이동이라는 두 개의 섹션을 가질 수 있을 것이다.레흐만 05:37, 2010년 12월 9일 (UTC)[응답]

아니, 나쁜 생각이야, 그건 너무 혼란스러울 거야. --SerkOfVulcan (대화) 15:44, 2010년 12월 9일 (UTC)[응답]

왜? 각각에 대해 간단한 두 섹션이 그렇게 혼란스럽진 않겠지, 그렇지?나는 사실 그것이 전혀 혼란스러울 것이라고 생각하지 않는다.사실, WP 외부에서는 다음과 같다.RM, 이 두 가지가 한 페이지로 넘어가기 때문에, 변화는 덜 혼란스러울 것이다.레흐만 16:16, 2010년 12월 9일 (UTC)[응답]

나는 RM과 PM을 결합하는 데 어떤 이점도 없다고 본다: 그것들은 별개의 이슈를 다루고 다른 속도로 진행된다.합병 논의는 AfD(WP:Guide to deletion#Recommends and results)와 더 공통적이다.플랫스캔 (토크) 05:18, 2010년 12월 10일 (UTC)[응답]

이점은 우리가 더 이상 "필수적으로 쓸모없는" 혹은 "안정적인" 합병 제안을 하지 않을 것이라는 것이다.합병과 명칭을 한 페이지에 붙이는 것은 그 안을 들여다볼 수 있는 더 많은 머리를 갖게 될 것이다.이는 또한 합병을 위한 논의가 합의당 적절한 조치와 함께 종결되는 2주(등) 기간을 시행할 수 있게 해줄 것이다.이것은 현재의 "무시" 상태에 비해 이러한 절차들을 좀 더 심각하거나 형식적으로 만들 것이라고 나는 말하고 싶다.레만 07:58, 2010년 12월 10일 (UTC)[응답]

병합 논의에 부실한 참여가 끈질긴 사안인 것으로 알고 있다.그것들을 결합하면 어떻게 RM 단골들이 PM 리스트에 관심을 가질 수 있는지 모르겠다.플랫스캔 (토크) 05:25, 2010년 12월 11일 (UTC)[응답]

WP:RM은 현재 "광고"가 잘 되어 있고, 실제로 많은 사람들이 그것을 시청하고 있어 상황이 정체되지 않도록 한다.같은 페이지에 두 개의 섹션이 있는 것은 쉽게 감시자의 주의를 끌 수 있을 것이다.그리고 한 페이지에 모든 "기사(메르그와 이동)" (별도의 페이지에 "삭제"만 있음)를 가리키는 것은 아마도 그 분야에 기여하는 사람들의 수를 배가시킬 것이다.레흐만 05:38, 2010년 12월 11일 (UTC)[응답]

• 나는 cname을 토론용 조항으로 바꾸기로 한 이전의 결정을 실행할 준비가 되어 있다; 나는 봇과 대본을 제외한 모든 곳에서 cname을 변경할 수 있다.우리가 어떻게 저것들을 처리할 수 있을까?(나는 단어 그 자체 외에는 어떤 변화도 하지 않을 것이다. 그렇지 않으면 지시사항을 수정하는 것은 두 번째 단계일 것이다. 그리고 나는 사람들이 그 문구를 수정하는 것을 받아들일지 조금 기다릴 것이다.나는 25일처럼 느린 날에 그것을 실행할 수 있었다. DGG (토크 ) 2010년 12월 16일 19:19, (UTC)[응답]
  • 나는 그것을 하기 위해 진정한 합의를 이룬 것에 반대한다.여러 코멘트에 의하면 나는 그 이전의 토론에 대해 그들 중 한 명이다.–Whitehors1 21:24, 2010년 12월 16일 (UTC)[응답]

좋아, 참고로, 나는 병합해서 페이지를 AfD로 옮기고 토론의 조항으로 개명하는 것을 강력히 지지한다.우리는 너무 많은 장소를 가지고 있다 - 병합/이동 페이지는 뒤로 기록되고 충분히 검토되지 않고, AfDs는 종종 합병과 이동으로 끝나며, 그것은 AfD의 흑백 대립적 초점을 빼앗는다.이번 건은 내가 행운을 빌게.카스리버 (토크 · 기여) 20:22, 2010년 12월 16일 (UTC)[응답]

제 2의 소견: WP:제안된 합병은 제안된 합병들을 한 곳에 나열할 수 있는 좋은 플랫폼이지만, 적어도 네 가지 문제가 있다: 1.나는 그것이 충분히 인기가 있다고 생각하지 않는다.RM, WP:AfD 등; 2.사용자들이 WP:제안된 합병안에 그들이 제안하고 있는 합병안을 열거할 필요가 없다. 3.이와 함께 WP에 대해서도 모르는 인수합병(M&A)을 제안하는 사람들도 있을 것으로 보인다.제안된 합병, 4.합병 제안이 공개되는 데는 정해진 시간 제한이 없다.병합 제안서는 별다른 활동 없이 수개월 동안 대화 페이지에 앉아 있을 수 있다(특히 저통행 페이지에서는 토크 페이지를 체크아웃하고 병합 제안에 참여하는 사용자가 그리 많지 않은 경우).이는 제안이 WP에 열거되어 있더라도 1번 문제와 관련이 있다.PM, 제안은 여전히 장기간 활동하지 않을 수 있다.병합 제안은 삭제 제안과 이동 제안만큼이나 중요할 수 있다.더 많은 사람들이 참여한다면 합병 제안은 훨씬 더 잘 진행될 수 있을 것이다.[ Retro00064 ▷인터뷰> 2010년 12월 17일 (UTC) 00:11, 답변

내 생각엔 네가 오해하는 것 같아.이 페이지는 논란의¹ 여지가 있거나 복잡한² 합병안을 나열하기 위한 것이라고 기록하고 있다.합병 제안의 중요성에 대해서는 동의해, Retro'64.–Whitehors1 12:09, 2010년 12월 18일 (UTC)[응답]

1. ARBPIA와 같은 적극적 중재적 구제책의 주제, 이스라엘-팔레스타인 분쟁 등을 생각해 보라.
2. 예를 들어, 의학이나 개념 이론과 같은 복잡한 주제에 대한 4자 제안서, 이차적 연구가 심지어 평가하도록 요구한다.

합병을 제안하는 전체 아이디어는 지역사회의 합의를 이끌어 내거나 말거나 하는 것이다.이는 합병에 대한 논란이 잠재적으로 있다는 것을 의미한다.WP:요청된 움직임에는 논란이 될 수 있는 움직임의 섹션과 관리자의 도움이 필요한 논란의 여지가 없는 움직임의 섹션이 있다.조치가 수행되기 전에 합의가 필요한 모든 조치는 잠재적으로 논란의 소지가 있는 것으로 분류될 수 있으므로, 그 문제에 대한 외부 의견을 얻는 데 도움이 되도록 중앙 리스트(예: WP: 제안된 합병)에 열거해야 한다.합의가 필요하지 않은 어떤 행동도 그냥 할 수 있다.예를 들어, 위키피디아의 정책을 따르기 위해 필요한 합병이라면, 과감하게 해.[ 레트로00064 ▷인터뷰> 2010년 12월 19일 (UTC) 01:17 [응답]

너는 사과와 오렌지를 비교하고 있다.WP:요청된 움직임은 페이지 제목을 바꾸는 것이다.

너 또한 용어를 헷갈리게 한다.어떤 사물에 대해 다른 생각을 가진 두 편집자는 완전히 다르다.사과와 오렌지.위키피디아에서는 다음과 같이 논쟁의 여지가 있다.논란의 여지가 있다.

병합에는 내용 편집, 흐름을 보장하기 위한 복사, 주제와 직접 작업, 삭제할 내용에 대한 판단이 포함된다.동작은 그렇지 않다.
둘 다 중요하다.그러나 그렇다고 해서 한 사람에게 적용되는 치료가 다른 사람에게 적합할 수 있다는 뜻은 아니다.그것들은 다른 동물들의 열매다.–화이트호스1 04:33, 2010년 12월 19일 (UTC)[응답]

WP와 달리 분할에 대한 중앙 토론 목록이 전혀 없기 때문에 WP:요청된 분할도 존재한다면 좋을 것이다.병합 PM. 184.144.166.27 (대화) 18:59, 2010년 12월 30일 (UTC)[응답]

분할과 병합은 밀접하게 연관되어 있기 때문에 아마도 같은 페이지에 나열되어 처리될 수 있을 것이다...레만 02:01, 2010년 12월 31일 (UTC)[응답]

나는 이 제안을 지지한다.WT:제안된 합병/아카이브 2#제안된 합병 *및 분할*?(2009년 9월)은 이를 위해 시작되었지만, 봇 작업이 완료되지 않았다고 생각한다.플랫스캔 (토크) 04:58, 2010년 12월 31일 (UTC)[응답]

누가 고양이에게 종을 울릴 것인가?

사전 논의를 검토하는 것이 여기서 큰 도움이 될 것 같다.불행히도, 그것들은 주변에 퍼져있다.이것은 그들이 찾기가 더 어렵다는 것을 의미하지만, AfD와 관련된 페이지들의 검색은 몇몇으로 이어졌다.AfD와 그 외 다른 곳에서는 독립형 제안과 잘 홍보된 실들이 있었다.이것은 과거에 여러 번 공감대를 얻는 데 실패한 것으로 보인다.

여기 몇몇 토론에서 나온 몇 가지 논평이 있다.

…문제는 'merge'가 콘텐츠의 100%에서 1%까지 어느 곳에나 있을 수 있다는 점이며, 한정된 시간인 AfD는 보통 어떤 것이 병합되어야 하는가를 논하기에 최적의 장소가 아니라는 점이다.이것은 전형적으로 주체의식을 필요로 하며 실제로 많은 대체 제안과 타협을 필요로 한다… -- DGG 09:33, 2008년 11월 23일 (UTC)

나는 "merge and redirect"가 보관보다는 삭제에 가깝다는 것에 전적으로 동의한다.병합/재간접은 삭제와 마찬가지로 더 이상 독립된 기사가 없는 주제를 낳는다. -- 칼 (CBM) 12:51, 2008년 11월 23일 (UTC)

합병 결정이 얼마나 효과적인가?우리는 "merge"로 마감된 수백 개의 기사를 가지고 있고, 여전히 열려 있다.폴 블레이클리(역사 편집) • 기사토크(역사 편집) • 워치(Watch) 등 일부는 두 달째 편집되지 않고 있으며, " 위키백과를 확장하면 도움이 될 수 있다"는 짤막한 메시지도 갖고 있다.이것은 내가 보기에 합병 결정이 종종 효과적이지 않다는 것을 나타내는 것 같다.나는 그것이 사람들이 AfD에서 "merge"라고 말하는 것이 쉽기 때문이라고 추측하지만, 실제로 그 일을 하는 것은 더 어렵다.사람들이 합병을 찬성할 때 실제로 돕도록 장려할 방법이 있을까?아니면, 예를 들어, 한 달 후에 자동으로 그러한 페이지를 리디렉션으로 바꾸는 봇과 같은 기술적인 해결책에 의존할 필요가 있는가?— 세바스찬 17:52, 2009년 12월 15일 (UTC)

Merge는 "Somebody Other's problem"으로 보여진다.관리자는 충분히 신경 쓰지 않는다. 그들은 단지 문을 닫고 있을 뿐이다.유목민들은 그것이 없어지기를 원했기 때문에 그들은 그 자료를 보존하기 위한 일을 하기를 원하지 않는다.관리인들은 합병 결정에 분개하니 무시해라.나는 합병을 위해 몇몇 AfDs를 닫았고, 때때로 내가 직접 그것을 하고 다른 때 나는 위키프로젝트나 !voter를 찔러 그들이 끝까지 해낼 수 있는지 확인한다.합병은 그 프로젝트에서 매우 방치된 부분이다.

^{—Fences&Windows 01:49, 16 December 2009 (UTC)}

• 제안-논의(완료와는 거리가 먼)

• 위키백과:병합용 기사
• 토론을 위해 이 프로세스의 이름 바꾸기
• 위키백과:논의를 위한 합병
• 합병 결정이 얼마나 효과적인가?
• AFD의 합병
• 삭제 논의 결과 합병
• 삭제 검토:병합으로 닫힌 AFD를 처리하도록 범위 업데이트
• AfD가 합병 및/또는 리디렉션에 대해 논의하기에 부적절한 장소인가?
• 스타일 유지/메르기/삭제
• 라이브 AfD 중 병합
• 선택 목록에 대한 제안된 변경 사항
• 통합
• 합병 제안 시 대화 페이지 알림
• 제발, ... 기억하라 - 리디렉션과 병합은 매우 다른 것이다.

문제는 이렇게 요약된다."네, 합병"이라고 말하는 것은 쉽다. /사이비-머거싱과 반대로 머거싱 - 이른바 빈+리디렉트(blank+redirect)는 시간이 많이 걸리고 더 어렵다.관리자가 병합 토론을 종료할 경우 병합 작업을 수행하지 않으려는 경우.토론 참가자들 중 특히 그들이 동의하지 않거나 어느 한 기사에 적극적이지 않은 경우, 토론 참가자들 역시 매우 자주 하지 않는다.그래서 많은 쥐들이 고양이에게 방울을 달아서 다가오는 소리를 들을 수 있게 하는 것은 좋은 생각이라고 말한다. 누군가가 "누가 고양이에게 방울을 달겠느냐?"라고 물으면 방만 조용해진다. –Whitehors1 21:24, 2010년 12월 16일 (UTC)[응답하라]

내 말이 맞다면 '합의가 합치되면 유목민이 하지 않으면 누가 수행하겠느냐'는 뜻일 뿐이지?만약 그렇다면, 우리는 합의를 얻은 후 1주일 정도 더 안에 (토론 종결의) 지명자(또는 다른 자원봉사자)가 합병을 실시해야 한다는 규칙을 대신 세울 수 있을 것이다.그리고 만약 그 때까지 실행되지 않았다면, "Merger가 지원되었지만 수행되지 않음"과 같은 것에 따라 닫기 위해서; 아마도 그것을 더 자세히 설명하는 링크된 템플릿일 것이다.레만 11:29, 2010년 12월 18일 (UTC)[응답]

음, 아니 - 그건 내가 말한게 아니야.어떤 배경에서는 관련 토론도 대충 훑어볼 가치가 있다.네가 언급하는 그런 재미있는 아이디어들은 오늘 중으로 그것에 대해 답할 것이다.고마워, 화이트호스1 12:15, 2010년 12월 18일 (UTC)

종종 명명자는 (비행기를 조종할 수 없듯이) 그것을 수행할 수 없다.WP별:Earth, 실제로 힘든 일을 하고 싶지 않은 더 가까운/참여자들이 있는 Earth, 시간 제한은 아무런 효과도 없다.마감일은 의욕적인 사람들에게 동기를 부여하는 데 도움을 줄 수 있지만, 누군가 밑에서 불을 붙이는 것은 결과를 얻기 위한 촉매제가 아니다.토론을 마무리하고 결과를 기록하기 위한 템플릿이 존재한다. 대부분의 경우 그러한 템플릿은 필요하지 않다.어떤 경우에는, '드라이브비' 또는 주관적으로 적용된 태그를 포함하여 오랜 기간 동안 병합된 태그가 필요한지, 그리고 어떤 작업이 필요한지 명확히 할 수 있는 경우에는, 단순히 삭제하는 것이 덜 관료적인 프로세스-creep으로 더 합리적일 수 있다.–Whitehors1 20:23, 2010년 12월 18일 (UTC)[응답]

좋은 지적이야, 대부분의 경우 시간을 제한하면 무메르로 끝나겠지.그러나 타임러 없이 두 가지 주제(모브와 병합)를 한 페이지에 나열하는 것이 여전히 더 나을 것이다. 그렇지 않은가?레만 02:49, 2010년 12월 19일 (UTC)[응답]

다시 이(잠)로 돌아올게.그런데 너의 고양이들은 정말 멋져! –Whitehors1 04:33, 2010년 12월 19일 (UTC)[응답하라]

고마워 나는 너의 답장을 기다린다.안부의 말레흐만 11:01, 2010년 12월 19일 (UTC)[응답]

• 반성하는 데 시간이 걸렸지만, 과정/페이지를 결합하는 것은 효과가 없었다.그들은 극과 극이다.
  • 이동 페이지의 이름은 "요청된 이동"으로, 일부 기여자는 전체 또는 특정 페이지(확증된 계정 필요 또는 편집된 리디렉션 이동에 필요한 관리 비트)를 이동할 수 없으므로 요청해야 하기 때문이다.이에 비해 IP를 포함한 편집자와 지난 화요일 갑자기 합류한 편집자는 누구나 합병이 가능하다.
  • "논쟁"이라는 단어는 Requested Moves에서 매우 뚜렷한 의미를 갖는 것 같다. 예를 들어, 철자 수정과 같은 간단한 변경은 누군가가 대안이나 현존하는 것을 선호한다고 말할 때까지 "논쟁하지 않는다" 또는 "논쟁하지 않는 것으로 처음 나열되는 논쟁적"이 된다.한편, "논쟁"은 최고의 제목에 대해 잡담이 있거나, 둘 이상의 관점이 방송되거나, 혹은 '제1의 주제'에 대해 상상할 수 있는 것으로 구성된다.원칙) 또는 '공통 이름'.이와는 대조적으로, 제안된 병합 페이지는 일반적이고 일반적인 위키백과 방식으로 이 용어를 사용한다.
  • 이동 페이지에는 태그가 지정된 페이지를 기준으로 봇에 의해 자동 업데이트되는 시간순으로 정렬된 목록이 들어 있다.제목이 바뀌어야 한다고 생각하는 페이지가 목록을 구성한다.A 페이지를 B로 옮기거나 삭제하는 데 몇 시간이 걸릴 리 없다.이와는 대조적으로, 병합은 직접적으로 내용을 포함한다.몇몇은 잘 수행하기가 극도로 까다롭다.효과적인 건설적 참여나 행동은 전형적으로 주체의 인식을 필요로 하며, 물론 때로는 힘든 일을 하는 방법을 결정한다.
• 많은 것들이 물론 논란이 되거나 복잡하지 않으며, 카테고리를 복제하고 이를 모니터링하거나 모든 태그를 나열하는 다양한 방법은 과도할 것이다.참여 부족은 모든 위키 프로세스가 현장에서 직면하는 어려움이라고 생각한다.하나의 통합된 병합-이동 페이지는 이러한 극과 극의 대립을 융합시킬 수 있지만, 위의 내용과 함께 플랫스캔의 논평은 그것이 진정으로 강화되지는 않을 것이라고 믿게 만든다.–Whitehors1 05:39, 2010년 12월 20일 (UTC)[응답]

나는 네가 무슨 말을 하는지 이해하지 못했거나, 아니면 위의 요점들이 말이 되지 않았거나; 이것들은 두 가지 내용이 제안된 것과 같은 페이지에 있지 않은 이유들이 아니다.두 가지를 모두 한 페이지에 담는 것은 주목을 받을 확률을 높일 뿐 아니라, 더 많은 참여를 이끌어 낼 수 있다.나는 그들을 같은 처지에 놓이게 되면 그 단점들이 생각나지 않는다...레흐만 11:09, 2010년 12월 22일 (UTC)[응답]

에러... 그 실들을 합치면 혼란스러울 거야.나는 움푹 들어간 곳을 복구했다.아래 공백으로 구분된 무의미한 코멘트는 페이지 결합과 관련이 없다. 그 의도는 병합 프로세스를 평가하고 참여를 유도하고 강화하는 방법에 대해 건설적인 피드백을 제공하는 것이었다.나는 그 제안이 효과가 없을 것이라고 느꼈고, 열정을 억제하는 것을 싫어한다고 표현했기 때문에, 나는 몇 가지 대안을 제시하려고 노력하고 있었다.–Whitehors1 11:39, 2010년 12월 22일 (UTC)[응답]

레만, 완전히 다른 거야?–Whitehors1 12:04, 2010년 12월 22일(UTC)

이것은 내가 이것을 개선할 수 있는 방법에 대해 생각하게 했다.나는 기사 알림 시스템에 새로운 병합 통지가 포함되어 있는지 궁금하기 시작했지만, 포함되지 않았다.나는 그것이 다시 살아날 수도 있고 다른 봇이 어떤 것들을 다룰 수도 있다고 생각했지만 여전히 활동적인지 확신할 수 없었다.한동안 활동이 뜸했다.

훌륭한 소식은 교체용 봇을 만들고 담당할 수 있도록 자원봉사를 제의한 것인데, 지난주부터 시범을 보이기 시작했다.사용자에게 스냅:H3llknn0wz로 올라간다.

나는 좋은 생각이 있었다: 통지에 새로운 병합들을 추가하자고 제안하는 것이다.나는 즉시 다른 누군가가 이미 그런 생각을 가지고 있다는 것을 알게 되었다.우연히 위키백과 제목/작업 그룹별 정리 목록은 병합 카운트를 포함하지만, 이 목록에 모든 정리 통계가 표시되고 간헐적이기 때문에 이 목록에 영향을 덜 준다.빈사 상태에 있지 않은 위키프로젝트가 경고를 받기 시작했다.현재 이전에 제안된 새 경보 기능에 대한 요청은 다시 제출할 필요가 없다.이게 정말 도움이 될 것 같아.재판이 잘 진행되어 봇의 부모가 곧 추가 사항들을 살펴보기 시작하기를 바랍시다.–Whitehors1 05:39, 2010년 12월 20일 (UTC)[응답]

르 "그것들은... 완전히 다른 것들인가?": 그래, 다르지만 크게 다르지 않다; 둘 다 기사(메르주/르네임)에 대한 논의와 관련이 있고, 별도의 장소에서 삭제만 할 뿐이다.말했듯이, 이렇게 하면 참여도가 크게 향상될 겁니다...레만 12:31, 2010년 12월 22일 (UTC)[응답]

레만, 그들은 비길 데 없어.편집 모드에서 내용 중 한 문자를 건드리지 않고 내용 없이 페이지를 이동할 수 있다.

아날로그는 내 강한 옷은 아니지만, 한 번 시도해 보자.마치 그림 액자와 그림 같다.이제 여러분은 그림을 감싸기 위해 액자를 만드는 목수나 조이너가 있을지도 모른다.그들은 하는 일을 잘한다.그림의 내용은 이와는 대조적으로 화가나 복원가가 다루고 있다.당신은 그들이 아무리 숙련된 기술자라 할지라도 그림 붓과 이젤을 액자에 재봉할 수 없으며, 그들이 그것을 잘 해나갈 수 있도록 터치업 복구가 필요하다고 주장할 수 없으며, 또한 그들에게 화학 약품을 찌르거나, 그림들과 관련이 있기 때문에 수년 간의 흙더미를 제거해야 한다고 주장한다.편집자는 두 영역에서 모두 작업할 수 있지만 서로 다른 기술 집합과 초점을 적용할 수 있다.페이지에 부착된 라벨은 사람들이 페이지를 더 잘 볼 수 있도록 도울 수 있다.제목이 중요하다; 그것은 여전히 같은 페이지다.

또한 Requested Movement의 캔트 또는 사투리도 있다.RM의 명명법은 RM 고유의 추가 또는 새로운 정의와 의미(동음이의어?)를 주어진, 현장의 다른 곳이나 일반적인 사용(예: "논란")에서 사용되는 기존 용어를 포함한다.페이지 위아래가 어느 정도냐에 따라 주요 용어/개념들이 엄청나게 다른 방식으로 사용되면서 서로 다른 두 가지를 함께 섞어야만 혼란으로 이어질 수 있다.

병합이 더 오래 지속될 수 있는 이유는 관련 대상의 논란이 많은 특성 때문에 많은 사람들이 관여로부터 거리를 두는 것을 선호하기 때문이다.Flatscan의 의견을 반복해서 강조하기 위해, 목록만 이미 감시 목록에 있는 페이지로 옮겨진다면 RM 단골들이 그러한 합병에 관심을 가질만한 징후는 없을 것이다.

나는 그 둘을 결합하는 것이 어떻게 이치에 맞는지 알 수 없고, 또한 그 변화로 인해 참여가 저조한 것이 하나의 효과로 다루어질 것이며, 그 결과는 필연적인 혼란이 될 것이라고 보지 않는다.–Whitehors1 17:18, 2010년 12월 28일 (UTC)[응답]

그렇다면, 그러한 장소에 대한 합의는?레만 14:43, 2010년 12월 28일 (UTC)[응답]

나는 없다고 말하고 싶다.–Whitehors1 17:18, 2010년 12월 28일(UTC)
아카이브 타임스탬프 00:13, 2011년 1월 4일(UTC)[답글]

요약: 이름 바꾸기, 병합 및 분할에 대한 단일 페이지

요약하자면.나의 원래 제안은 인기 있는 WP:Requested moves 페이지를 Mergers로 수정하는 것이다.이것은 Moves에 비해 합병에 대한 참여를 엄청나게 증가시킬 것이다.그리고 스플릿은 단지 반대 방향의 합병일 뿐이므로, 스플릿과 메그먼트를 동등한 의의와 관심을 가지고 하나로 식별하자는 제안도 나왔다.따라서, "요청된 움직임, 합병 및 분할"과 같은 제목이나, 간단히 말하면 "논의 대상 문서"와 같은 제목으로, WP의 별도 장소에 삭제장만 있는 경우:삭제용 기사.

현재, 합병과 관련된 다음과 같은 장소가 있다(스플릿에 대한 주요 논의 영역 없음).

1. WP:현재 인수합병을 상장할 주요 장소인 합병 제안
2. WP:합병을 WP처럼 취급하는 실패한 제안, 합병을 위한 의견:삭제조항, 제한시간 등
3. WP:논의를 위한 Mergers, WP와 같은 장소에 대한 제안 실패:합병 제안, 그러나 WP와 같은 논의의 요건은 다음과 같다.삭제조항
4. WP:논의 대상, 기사와 관련된 모든 논의를 위한 장소에 대한 실패한 제안:삭제, 이동, 병합, 분할.

현재, Movements, Deletions, Merges&Splits에 비해 Merges (및 Splits, 그 문제에 있어서, Merges, Splits)는 최소한의 관심거리인 것 같다.

Migration&Splits와의 Movements를 병합하기 위한 주요 수정사항은 다음과 같다.

1. 현재 WP 이름을 변경하십시오.요청된 내용은 WP와 같이 보다 광범위한 주제로 이동하십시오.토의사항
2. RM 봇을 프로그램하여 Mosis 및 Splits와 함께 Moves를 업데이트하십시오.이를 위해서는 다음이 필요하다.
3. 병합 및 분할 템플릿을 이동 템플릿과 같은 기능으로 수정하십시오.(Merge 및 Splittemplate도 병합 가능, 매개 변수와 함께 작동 가능)
4. 포인트 WP:새로운 타이틀에 대한 합병 및 기타 주요 관련 링크 제안.

이 제안은 (WP와 같이) 논의를 병합/분할하는 데 시간 제한을 가하기 때문이다.삭제 조항)이 영원히 표류하지 않도록 '합병·분할에 대한 합의가 이뤄지면 누가 수행할 것인가'라는 문제가 발생한다.지금까지 해결책에 가장 가까운 것은 다음과 같다.

• 7일간의 논의 끝에 합병/분할에 대한 합의가 이루어진 후, 만약 명명자가 다른 주 내에 합병/분할을 수행하지 않으면, "Merge/분할은 지원되었지만 수행되지 않음"에 따라 지명이 마감된다.전체 행사 기간이 2주가 되는 셈이다.

하지만 물론, 자원 봉사자는 항상 이 합병/분할을 수행할 수 있었다.그리고 모든 장을 한 장으로 통일했기 때문에 자원봉사자가 나설 가능성은 더 크다.동일한 주제에 대한 향후 합병/분할 제안도 신속하게 종결될 수 있다.

또 다른 이슈는?레만 06:14, 2010년 12월 31일 (UTC)[응답]

여기에는 "이는 합병 참여를 엄청나게 증가시킬 것이다/ "자원봉사자가 나설 가능성이 더 높다"는 이전의 말을 되풀이하면서 "주장에 의한 진실"이 아주 많이 존재하는 것 같다.몇 가지 요점이 불분명하거나 부정확하다.

1. 분열은 단지 반대 방향으로의 합병일 뿐이기 때문이다.나는 이것이 사실이라고 생각하지 않는다.
2. "논의 대상" -- 이것은 분명히 wp:peren에 명시적으로 나열되지 않았더라도, 영구히 거부된 것으로 보인다.
3. "우리는 합병과 관련하여 다음과 같은 장소를 가지고 있다." - 어떻게 실패한 제안이 장소일 수 있는가? - 첫번째 제안만이 모든 것을 위한 장소일 수 있다.합병에 대해 특별히 논란이 있거나 실행하기 어려운 부분만을 위해 현재 주요/주요 장소는 아니다.
4. 이 제안은 (WP와 같이) 논의를 병합/분할하는 데 시간 제한을 가하기 때문이다.삭제에 대한 기사)는 영원히 떠내려가지 않도록 하기 위해 일반적으로 영원히 떠내려가지 않고, 피터는 공식적으로 닫히지 않는다.
5. 자원 봉사자는 항상 [a] 병합/분할을 수행할 수 있다. 자유롭다고 생각하십니까?

앞서 진행된 토론에서 많은 요점이 언급되었다. --Whitehors1 00:13, 2011년 1월 4일 (UTC)[응답]