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

메인 페이지 레이아웃—오래되고 지루해짐

우리의 현재 메인 페이지 레이아웃은 평범하고 지루하다.그것은 몇 년 동안 업데이트되지 않았다.메인페이지에 대해 일종의 '고객만족도' 설문조사를 해야 할 것 같다.2008년 재설계 제안이 무산됐는데, 다시 시도할 때인가?좀 더 현대적으로 보이도록 리도우를 할 수 있을 것 같아. iMatthew 2009년 8월 13일 (UTC) 19시 48분 (답)

위키백과를 본 적이 있는가?메인_페이지_FAQ#Is_Is_there_way_to_make_Main_Page_look_better.3F? 그럼 신사는 누구였지?(토크) 2009년 8월 13일 21:37 (UTC)[응답하라]

정말 그랬어.그러나 내가 메인 페이지를 어떻게 보는가에 대한 나의 개인적인 선택은 방문객들에게 초기인상을 발산하는 수백만명의 사람들이 매일 보는 디자인과 아무 상관이 없다. iMatthew는 2009년 8월 14일 02:53, (UTC)[응답]

나는 메인 페이지를 완전히 다시 디자인하는 것에 다소 반대한다; 수백만 명의 독자와 편집자들이 이미 그것에 익숙해 있고, 그것은 아무런 문제 없이 몇 년 동안 효과적으로 제공되고 있다.–줄리안콜튼^Talk 03:08, 2009년 8월 14일 (UTC)[응답]

나도 그런 생각을 해봤지만, 오늘날 사람들은 물론 새로운 모습의 현대화된 웹사이트를 찾고 있다.나는 오늘 이것에 대해 생각하고 있었는데, 나는 야후의 메인 페이지가 다시 작성되고 있는 것을 보았다.만약 우리가 메인 페이지에 새로운 것들을 올리고, 사람들이 사용하지 않는 것들을 제거할 수 있다면, 위키피디아는 더 많은 방문객들과 더 많은 기여자들을 얻을 가능성이 높다.새롭고, 신선하고, 현대적인 외모가 사람들을 유혹한다.우리가 이 메인 페이지를 3년 정도 가지고 있었기 때문에, 사람들은 그것에 싫증을 내고 있다.말 한 마디에 "이슈"는 없지만, 페이지의 외관을 새로 고치기 위한 업데이트는 위키피디아에 정말 도움이 될 수 있다.이것은 단지 내 의견일 뿐, 나는 많은 사람들과 공유한다고 믿는다. iMatthew 2009년 8월 14일 03:19 (UTC)[응답]

나는 개인적으로 우리가 지루하고 변하지 않는 메인 페이지 레이아웃을 유지해야 한다고 생각한다.어쨌든, 이것은 수백 명의 사용자들에 의해 작년에 디자인 경연대회와 수많은 다른 실제 디자인들이 만들어지고 어떤 것도 바꿀 수 있는 합의 없이 끝이 났다.위키백과 대화 참조:WikiProject 사용성/메인 페이지/최종 보관(2006);위키백과:2008 메인 페이지 재설계 제안, 위키백과 토크:2008 메인 페이지 재설계 제안/조사, 위키백과:2008 메인 페이지 재설계 제안/차이, 위키백과:2008 메인 페이지 재설계 제안/조사 2008-10-18.---Fuhgetaboutit (대화) 03:18, 2009년 8월 14일 (UTC)[응답]

첫 번째 코멘트에서 그 점을 언급했다.2008년 제안은 다소 실패했지만, 나는 우리가 그것을 발끝에서 떼어내고 계속 노력해야 한다고 생각한다. iMatthew는 2009년 8월 14일 03:21 (UTC)[응답하라]

내년에 디폴트 스킨이 크게 바뀔 것이라는 것은 알고 있지만 그 최종 결과가 어떻게 될지는 정확히 알 수 없기 때문에 이 시기에 변화를 하는 것은 무의미하다고 생각한다.이와 같이, 메인 페이지의 "New look"을 디자인하는 것은 어려울 것이다. 왜냐하면 주변의 많은 면들이 바뀔 것이기 때문이다.피부 변화가 결국 어떤 형태로 나타날지 더 잘 파악할 때까지, 재설계하는 것은 아마도 시간 낭비일 것이다.—DJ (대화 • 기여) 2009년 8월 15일 (UTC) 11:17[응답]

나는 새로운 피부를 시도해 보았다.추악했다.국수 간식 (토크) 2009년 8월 15일 13:28 (UTC)[응답]

들어봐, 들어봐.그 당시 신사는 누구였습니까?(토크) 03:18, 2009년 8월 16일 (UTC)[응답]

제안:인포박스 변경

최근의 사용적합성 연구에서, infobox는 일관되게 새로운 편집자를 트립으로 고정시켰다.

우리가 해결할 수 있을 것 같아.현재 우리의 기사를 지배하고 있는 길고 긴 Infobox 코드 대신에, 단순히 기사/Infobox를 초월하는 것은 어떨까? 그것은 현재 기사에 보관되어 있는 복잡한 코드를 포함하고 있다.적은 양의 추가 코딩으로 기사/인포박스는 토크와 같이 기사/인포박스와 함께 자동으로 감시될 수 있다.기사는.

생각?슈메이커 홀리데이 2009년 8월 9일(UTC) 12시 15분[응답]

그렇지 않을 기술적 이유가 없는 한, 나는 이것이 훌륭하다고 생각한다.킬러치후아어드바이즈^?!? 13:06, 2009년 8월 9일 (UTC)[응답]

분명히 기술적인 이유가 있다: 하위 페이지가 기사 네임스페이스에서 활성화되지 않는다.물론 실제 타이틀 충돌 가능성은 상당히 작다. 차라리 우리가 "Something/Infobox" 또는 그런 종류의 이름을 가진 밴드를 볼 수 있을지는 의문이지만, 나는 일반적으로 하위 페이지를 활성화하지 않고는 Infobox 하위 페이지를 활성화할 수 없을지 의심스럽다.

그 외에도, 어떤 기사들은 여러 가지 이유로 둘 이상의 infobox를 포함하고 있으며, 이러한 infobox들이 반드시 기사 내에서 연속되는 것은 아니다; 하위 페이지 구조는 그 사건을 어떻게 처리할 것인가?Kirill^{[talk] [pf]} 13:11, 2009년 8월 9일 (UTC)[응답]

Kirill은 내가 하려던 말을 두 마디 했다.또한, 이것은 무료가 아닌 콘텐츠가 보여지는 페이지를 훨씬 더 많이 만든다.택사옥스가 포함되겠는가?테이블은 어때?다른 "상자"는 어때, 이런 거?J 밀번 (토크) 2009년 8월 9일 (UTC) 13:15 [응답]

사용적합성 연구는 주요 문제가 본문의 첫 단락 이전에 무작위적인 쓰레기였음을 보여주었다.나중에 추가하면 정상적으로 넣을 수 있다.기본적으로, 이것은 새로운 섹션에 삽입되는 편집 상자 상단에 있는 두 줄 이상의 모든 것을 포괄할 것이다. 따라서 새로운 편집자는 편집 버튼을 클릭할 때 최소한 복잡한 템플릿에 직면할 수 있다. 예를 들어, 새로운 네임스페이스:기사도 가능성이 있다.슈메이커 홀리데이^{Over 184 FCs served} 13:22, 2009년 8월 9일 (UTC)[응답]

그렇다면 다양한 헤더 배너({{unreferenced} 등)와 일반 인포박스가 포함되겠는가?나는 임시 배너와 영구 템플릿 사이에 어느 정도 분리를 유지하는 것이 유익할 것이라고 생각한다. 예를 들면 다음과 같다.
{{Banners/Article}}
{{Infobox/Article}}
Article text starts here...
Kirill^{[talk] [pf]} 13:33, 2009년 8월 9일 (UTC)[응답]

좋은 생각이야.기술적인 문제가 있을 수 있지만 어떻게든 해결할 수 있을 거야.기사 맨 위에 나오는 인포박스로 제한해서 신입이 '이 페이지 편집'을 클릭할 때 실제 기사 텍스트를 볼 수 있도록 할 수 있고, 이런 것이 아니다. --Conti ✉ 13:23, 2009년 8월 9일 (UTC)[응답]

대체 솔루션은 {{Infobox/Shark}}과 같이 "Infobox/"로 시작하는 템플릿을 사용하는 것이다.이것은 이름 짓는 면에서 더 유연하다.무료가 아닌 이미지는 포함만으로 포장해야 하지만, 그것은 큰 문제가 되지 않는다.— 칼 (CBM · talk) 2009년 8월 9일 (UTC) 13:24 [응답]

우리는 그것들을 토크 스페이스에 넣고 하나 이상이 존재할 때 /1, /2 등을 추가할 수 있다.나는 또한 하위 페이지를 직접 편집할 수 있도록 "v.d.e" 링크를 추가하는 것을 제안한다.덴도지_T\^C 13:25, 2009년 8월 9일 (UTC)[응답]

기사/인포박스가 다중 인포박스를 포함하지 못할 이유는 없다.편집 창 시작 부분에 5개 또는 6개의 번호가 매겨진 줄을 찾는 것이 현재 시스템만큼 혼란스럽기 때문에 하위 페이지 번호를 매기는 것은 이 점을 배제한다.슈메이커 홀리데이^{Over 184 FCs served} 13:27, 2009년 8월 9일 (UTC)[응답]

그것은 Infobox가 연속적인 경우에만 해당된다(하위 페이지 [예: ]에서 선택 가능한 전폐를 허용하지 않는 한).우리는 기사 내의 서로 다른 위치에 각각 여러 개의 인포박스를 보유할 수 있는 능력을 유지하고 싶다; 이상적으로는 모든 인포박스에 대해 동일한 트랜지런스 방법을 사용하여 인포박스를 재배치하거나 새로운 인포박스를 만들 때 수반되는 추가 작업을 최소화하고자 한다.Kirill^{[talk] [pf]} 13:36, 2009년 8월 9일 (UTC)[응답]

어떤 시스템이든 편집자들이 쉽게 인포박스에 접근하고 편집할 수 있도록 해야 한다.신생 편집자들은 템플릿과 참조 생성을 이해하는 데 충분한 어려움을 겪고 있다. -- - Gadget850 (Ed) 13:41, 2009년 8월 9일 (UTC)[응답]

이것에 대한 실질적인 경고가 하나 있는데, 그것은 참고가 되는 상황이다.infobox의 참조는 참조의 고유 용도가 아닌 경우가 많으므로, infobox와 기사 본문이 분리될 경우 이를 조정하기 위해서는 훨씬 더 많은 작업이 필요하다. --MASEM (t) 13:57, 2009년 8월 9일 (UTC)[응답]

내가 보기에 이 제안의 장점은 다음과 같다.

• 기사 텍스트를 편집하려는 신입 편집자에게 혼란을 줄임.

그리고 단점:

• 템플릿을 제대로 이해하지 못하지만 infobox(vde 링크 포함)를 편집하려는 편집자가 더 혼란스러워함
• 특수 인포박스 템플릿 페이지는 시청률이 낮다.
• 기사의 다른 곳에 있는 Infobox로 무엇을 해야 하는지에 대한 혼란.
• 페이지 상단의 비인포박스 템플릿 처리 방법에 대한 혼란.
• 기사와 인포박스 간의 참조를 현명하게 공유하기 어려움.
• 비자유 영상은 특수 infobox 템플릿 페이지에 표시할 수 없으며, 특수 infobox 템플릿 페이지에는 포함만 필요함.

IMO, 이것은 우리가 지금 여기서 할 수 있는 모든 것이 시기상조일 가능성이 높고 특별히 성공할 가능성이 없는 사용적합성 기반 제안 중 하나이다.실제로 사용할 수 있을 가능성이 가장 높은 솔루션은 MediaWiki를 크게 변경해야 하며, 기본적으로 하나의 큰 텍스트 필드에서 여러 텍스트 필드(예: "헤더", "본문", "참조", "메타데이터(카테고리)" 등으로 편집 내용을 변경해야 한다.아노미야 14:40, 2009년 8월 9일 (UTC)[응답]

동의해; 나는 이것이 실제로 일을 덜 혼란스럽게 하기보다는 더 혼란스럽게 만들까 봐 걱정이야.기사 텍스트를 보고 싶어 하는 신입 편집자들을 위해서라면 물론이지. 아주 좋아.그러나 비신사들, 즉 며칠간의 경험을 가진 사람이라면 더욱 혼란스러워진다.또한 사용적합성 프로젝트가 끝날 때부터 작동하는 동안 이와 같은 광범위한 변화를 만드는 것이 불편하다. 앞으로 몇 달 후에 다가올 많은 변화들이 이 문제를 무질서하게 만들 수도 있다.파워스 14:48, 2009년 8월 9일 (UTC)[응답]

아마도 인포박스를 "데이터"라고 불리는 부분에 넣고, 그리고 나서 우측 상단에 올릴 수 있는 방법을 찾을 수 있을 것이다.나는 종종 우리가 html과 그 모든 것(예: 스타일시트가 제거된 상태)의 관점에서 기사 레이아웃에 대해 정확하고 싶다면, 그곳은 infobox에게는 끔찍한 장소라고 생각해왔다.만약 당신이 CSS를 끄신다면, 우리의 기사는 "인포박스는 특정 주제에 대한 데이터의 표"로 시작해야 하는 것이 분명하고, 무작위 데이터 뭉치가 아니다. M 20:33, 2009년 8월 9일 (UTC)[응답하라]

그것도 내 생각이었다(그러나 infobox는 Javascript가 아닌 CSS에 의해 페이지 상단에 배치되어야 한다).Andy Mabbett(사용자:Pigsonthewing);앤디의 토크 2009년 8월 9일(UTC) 20시 45분 편집[응답]

CSS는 작동하지 않을 것이고, 이것을 깨끗하게 할 수 있는 능력이 없다. M 02:02, 2009년 8월 10일 (UTC)[응답하라]

JS는 접근성 때문에 작동하지 않을 것이다. --Izno (토크) 19:09, 2009년 8월 10일 (UTC)[응답]

음, 현재 레이아웃은 접근성(블라인드 사용자가 인포박스를 먼저 맞는 것) 때문에 작동하지 않을 것이다.js장애를 가진 매우 희귀한 사람들은 여전히 같은 기사의 다른 위치에서 infobox를 볼 수 있을 것이다.여기에는 모바일 기기 사용자도 포함되며, 이 사용자들은 어차피 위에 편집 상자를 보면 안 된다. 2009년 8월 10일 M 20:00 (UTC)[응답하라]

• 인내심을 조언하다.사용적합성은 편집박스 개선을 위한 검색에서 WYSIWYG(또는 적어도 WikEd와 가까운 것)를 생각해낼 가능성이 높다.이상적으로는 별도의 양식 기반 레이아웃에서 편집할 템플릿과 참조를 접는 Wikia WYSIWYG 편집기에서 찾을 수 있는 것과 같은 것을 볼 수 있을 것이다. --Izno (talk) 19:09, 2009년 8월 10일 (UTC)[응답]
  • 편집 상자 향상?편집 상자에 아니오라고 말하십시오. 2009년 8월 10일 M 20:00 (UTC)[응답하라]
    • 나는 이즈노의 말에 동의한다.왜 이걸 지금 당장 다시 끌어 올렸지?우리 모두는 그것이 차선책이라는 것을 알고 있다. 우리가 파서 기능을 가지고 있다는 사실은 "경험이 없는 사용자"에게는 차선책이다.그렇다고 해서 그것이 나쁘다는 것도 아니고 몇 년 동안 문제를 해결하지 못했는데 지금 당장 해결해야 한다는 것도 아니다.사용적합성 팀은 그들이 무엇을 할 수 있는지 보고 있다. 그리고 나는 여기서 제안된 아이디어들 중 하나도 하지 않았다.자바스크립트 포지셔닝, 별개의 네임스페이스, 이 모든 것은 이전에 제안된 적이 있고 결코 합의점을 찾지 못했다.누군가가 냉철한 NEW 아이디어를 내놓지 않는 한 사용적합성 팀이 어떤 아이디어를 내놓을지 지켜봐야 할 것 같다.—DJ (대화 • 기여) 2009년 8월 11일 (UTC) 15:31, 11[응답]

네임스페이스?

별도의 Infobox: 네임스페이스를 만드는 것은 어떨까?—루우드 18:51, 2009년 8월 10일 (UTC)[응답]

가능하면 일부 MediaWiki 지원을 사용하면 템플릿: 네임스페이스보다는 토크: 네임스페이스와 더 비슷하게 작동하도록 할 수 있다.예를 들어, Infobox talk가 없음: (선택적으로) infobox 탭을 자동으로 추가하거나, infobox가 있으면 편집하거나, {{Infobox가 없어도 기사에 자동으로 표시할 수 있음:기사 맨 위에 PAGENAME}.—루우드 19:06, 2009년 8월 10일 (UTC)[응답]

찾기가 너무 어렵고, 연결하기에 너무 복잡하다.그것을 자신의 머리글에 넣은 다음 js로 옮기는 것은 훨씬, 훨씬 더 쉽다. 2009년 8월 10일 M 20:00 (UTC)[응답하라]

JS로 그런 일을 하는 것 또한 매우 사악하다(접근성, 페이지를 다시 렌더링해야 하기 때문에 로딩 시간 증가).MediaWiki 소프트웨어의 변경이 문제가 되지 않을 것이라는 가정 하에 바람직한 해결책은 무엇인가?—루우드 20:11, 2009년 8월 10일 (UTC)[응답]

음, JS와 함께 하는 건 "악"이 아니야접근성이 향상될 것이다(블라인드 사용자 및 html의 정확한 순서를 준수하는 다른 사용자들은 위에 임의의 infobox를 보지 않을 것이다).나는 브라우저가 작동하는 방식에 대한 오해가 있다고 생각한다 - 서버에서 페이지와 이미지를 로드하는 것은 느리다.페이지 렌더링이 빠르게 진행되고 있음 - 렌더링이 트리거되기 전에 지연될 수 있음.나는 우리가 그것을 꽤 잘 좁혔다고 생각한다: 선도에서 텍스트를 빼내거나(kill infobox, 템플릿을 사용하여 가져오기, js를 사용하여 아래 머리글에서 가져오기) 또는 표시 방법을 바꾸거나(색상 코딩 또는 숨기기(숨기기 위한 스크립트가 있음)내 생각엔 우리가 베이스가 있는 것 같아.누군가 인포박스를 찾아 몸 앞에 붙이는 사용자 criptic j를 조금 써보는 것도 고려해봐야 우리가 한번 해볼 수 있다. M 22:36, 2009년 8월 10일 (UTC)[응답하라]

음, 만약 내가 당신의 토크 페이지와 같은 긴 페이지를 찾아본다면, 그 페이지는 즉각적으로 나타나지 않는다.렌더링을 즉시 시작하지만, 마지막 헤더가 나타나기까지 시간이 좀 걸린다(초보다 짧지만 눈에 띄기엔 충분하다).이 스크립트는 인포박스를 그 시간 전에는 상단으로 이동할 수 없을 것이며, 짜증나는 팝업 효과를 일으킬 가능성이 있다(실제로 경험적으로 테스트해야 하지만).그러나 사용자 관점에서 기술적 장벽을 무시하는 것이 바람직한 해결책이 될 것인지에 대한 제 질문에 대해서는 자세히 설명하지 않으셨습니다.—uud 22:57, 2009년 8월 10일 (UTC)[응답]

wikitxt의 시작보다는 infobox 코드를 끝까지 옮길 수 있다면 좋을 것이다.하지만 나는 인포박스를 별도의 페이지에 넣고 그것을 초월한 어떤 계획도 반대할 것이다.그렇게 되면 사용자 혼란이 가중되고, 편집이 방해되며, 1페이지 대신 2페이지 시청을 강요하고, 추가 검색 합병증이 생기며, 일반적으로는 어쨌든 정확히 큰 문제가 아닌 것을 "해결"하는 것만으로 많은 문제가 발생하게 된다...---코트니스키 (토크) 09:19, 2009년 8월 11일 (UTC)[응답]

마법의 단어 - ToC와 같은 단어

나는 ToC와 같은 특정 템플릿을 다루고, 특정 템플릿을 오른쪽 상단(또는 상단 중앙 또는 다른 곳)에 위치시킬 수 있는 기본 텍스트에 넣을 수 있는 마법의 단어를 만드는 것만이 실질적인 해결책이라고 생각한다.아마도 이것은 Navbox나 다른 템플릿들을 다루기 위해 더 확장될 수 있을 것이다: 페이지 하단, 섹션 3의 상단 오른쪽 (New Super Mario Brots와 같은 검토 템플릿의 경우)#감정).그러면 우리는 사람들이 신경쓰지 않는 기사 하단에 전부 또는 많은 양의 infobox/템플릿 코드를 넣을 수 있다.〇 조니미르닌자 02:05, 2009년 8월 12일 (UTC)[응답]

나는 이것이 VPT에서 실현 가능한가에 대한 질문을 꺼냈다. ▫ 조니MrNinja 17:09, 2009년 8월 17일 (UTC)[응답]

WP:Notify

나는 이것이 존재한다고 확신했지만, 그것을 인용하러 갔을 때, 그렇지 않다는 것을 깨달았다.나는 다양한 게시판(AN, ANI, WQA, SPA 등)에 더 깊은 정책이나 최소한 커뮤니티 규범에 대한 통지의 표시로 보고되는 편집자에게 통지해야 한다는 특정 경고를 이해했었다.비즈. 다른 어떤 것도 아닌 위키티켓의 문제로서, 만약 당신이 누군가를 뜨거운 물에 빠뜨리려고 한다면, 당신은 그 사람에게 그들이 기본적인 정당한 절차(알림과 들을 수 있는 기회)를 갖도록 알려야 한다.당신이 ANI에서 누군가에게 제재를 요청하든, 관리자의 토크 페이지 또는 다른 곳에서 제재를 요청하든, 당신은 그 사람에게 알려야 한다.

통지의 광범위한 커뮤니티 규범이 있다는 나의 이해가 옳은가?이것이 기존 정책에 반영되었는가?1에 대한 대답이 예스, 2에 대한 대답이 아니오라면, 어떻게 하면 그런 정책을 제안할 수 있을까?WP만 만들면 되는 겁니까?"제안된" 태그를 통지하고 그 태그를 슬랩하시겠습니까?- Simon Dodd { U/T/C/WP:법률 } { 20:52, 2009년 8월 15일 (UTC)[응답]

개인적으로, 나는 가능한 한 사람들에게 그런 것들을 통지한다.나는 항상 이것이 정상이라고 생각해 왔다.나는 적어도 왜 그들과 그들의 행동에 관한 논의를 편집자에게 알리는 것이 중요한지, 그리고 이것이 어떻게 달성될 수 있는지를 설명하는 에세이의 창설을 지지한다(관련 템플릿에 대한 링크와 함께.내가 최근에 위키피디아에서 발견한 한 가지 문제는 토론 사이의 명확성의 결여인데, 이것은 문제를 해결하는 데 중요한 부분이 될 것이다 - 사람들은 모든 대화에 열려있도록 격려받을 필요가 있다.

그렇긴 하지만, 나는 사람들에게 알리는 정책을 만드는 것은 지시사항의 소름끼치므로 피해야 한다고 생각한다.그러나, 분별 있는 곳이라면 어디든 알려야 한다는 내용의 에세이는 좋은 추가 사항이며, 어떤 편집자들이 지적할 만한 가치가 있다.

나는 당신이 그것을 만들 것을 제안한다. (Webedia에서는 그렇지 않다:WP를 통한 통지:지름길로 알림) 및 에세이 스탬프를 제공하십시오.그것은 나중에 정책으로 갈지 모르지만 나는 아직도 크리피처럼 보이는 것을 추진하는 것이 두렵다.네가 그것을 쓰는 데 도움이 필요하면 기꺼이 도와주겠다.그레그 타일러 23:13, 2009년 8월 15일 (UTC)[응답]

또한, 위키백과:새로운 정책 제안의 진행방법에 대한 정책 및 가이드라인. œ^™ 23:36, 2009년 8월 15일 (UTC)[응답]

그것은 에세이와 별로 관련이 없다.누구나 에세이를 쓸 수 있다. 에세이는 가이드라인을 개발하기 위한 논리적인 첫 단계로서, 합의가 이루어졌을 때에만 채택될 것이다.Jclemens (대화) 2009년 8월 16일 (UTC) 20:14 [응답]

그들이 미래에 결정을 내릴 경우를 대비해서 정책을 제안하는 포스터의 질문에 대답하고 싶었다.그리고 글을 읽고 있는 다른 사람들을 위해, 에세이를 쓴 후에 "제안된 태그를 그냥 두드려라!"라는 생각을 떨쳐버리길 바란다.:) -- œ^™ 00:47, 2009년 8월 17일 (UTC)[응답]

사용자가 새 사용자 이름을 요청할 때 자동 리디렉션

나는 7의 RFA를 읽고 있다.논의의 요점 중 하나는 누군가가 이전 계정을 사용한 사건이다.

이런 일이 다시는 일어나지 않도록 하기 위한 정책이 마련되어 있는 것인지도 모르지만, 나는 토론에서 그런 인상을 받지 못한다.내가 알기로는, 만약 당신이 새로운 사용자 이름을 원한다고 결정하면, 당신은 당신의 예전 이름을 버리게 되고, 그것은 다른 누군가에게 인수될 수 있다.이를 방지하려면 이전 이름을 다시 등록한 후 새 이름으로 리디렉션하는 것이 좋다(그러나 필요하지 않음).사실 7은 이것을 하려고 했지만 이해할 수 있는 규칙에 걸려서 실질적으로 옛날 것과 유사한 새로운 이름의 창조를 금지했다.

이제 나는 투기로 넘어간다 - 나는 평범한 편집자가 이런 상황에서 이름을 지을 수 없다고 추측하지만, 더 많은 권한을 가진 사람, 아마도 행정관이 그 계정을 만들 수 있을 것이다.이번 사건에서 그런 일이 있었는지 모르겠지만 언젠가 일어날 수 있을 것 같다.

제안된 정책을 의무화하여 소프트웨어로 구현하는 것은 어떠한가?사용자가 새 사용자 이름을 원하고 요청이 허가된 경우, 새 이름 생성(이력을 이동하기 위해 편집자 권한 이상의 것이 요구됨)을 동시에 재등록하거나 새 이름으로 자동 재직접하는 방식으로 이전 이름 등록을 유지하여 새 이름을 확실히 하기 위한 무언가를 추가하면 안 된다.오메온은 다른 일을 하기 위해 옛 이름을 사용할 수 없었다(즉, 옛 이름은 어떠한 권리도 허용되지 않는다).

소프트웨어의 우여곡절을 더 배우면서, 쉽게 들리지만 그들이 말하는 것보다 더 어려운 것이 있다는 것을 깨달았지만, 나는 이것이 가능하다고 생각할 것이다.나는 사용자가 새로운 이름을 요청할 때, 새로운 사용자(이전 소유자와 혼동될 사용자)나 여러 개의 계정을 가진 이전 사용자에게는 이전 이름이 다시는 사용되지 않기를 바랄 것이라고 생각한다.(여러 개의 계정이 허용된다는 것은 알고 있지만, 이것은 그렇게 하는 방법이 아니다.)

나는 이것을 공식적인 제안으로 만들지 않았는데, 왜냐하면 나는 이미 이런 식으로 작동하고 있고, 나는 단지 발표를 놓쳤거나, 내가 따르지 않는 이유로 말한 대로 불가능하다고 말할 수 있는, 좀 더 경험 많은 사용자들로부터 듣고 싶기 때문이다.피드백 후, 이 아이디어에 대한 것이 있다면, 정식 제안으로 작성해 보겠다.--SPHILbrickT 23:06, 2009년 8월 15일 (UTC)[응답]

이 능력은 이미 존재한다.–xeno^talk 11:52, 2009년 8월 17일 (UTC)[응답]

반갑습니다, 응답에 감사 드립니다만.--SPHILbrickT 17:04, 2009년 8월 17일 (UTC)[응답]

Rotative Wikipedia 및 Meta에서 Wikipedia로 편집 가져오기 가능

향수 위키백과와 메타에서 편집한 내용을 영어 위키백과로 가져올 수 있도록 하고 싶다.향수 위키피디아는 2001년 12월 20일에 만들어진 위키피디아 데이터베이스의 복사본으로, 우리 데이터베이스에는 없지만 아마도 그럴 것이다.예를 들어, 영어 위키백과에 있는 성인 기사의 첫 번째 편집을 향토 위키백과의 성인 기사의 역사와 비교해보자.메타(Meta)는 원래 위키백과 정책을 논의하는 장소였고, 일부 페이지는 우리의 차단 정책처럼 잘라 붙여넣어 메타(Meta)에서 이곳으로 옮겨졌다.

나는 오래된 편집 내용을 통합하여 역사를 전문으로 다루며(페이지 내역에 대한 내 사용자 하위 페이지 참조), Rotative wiki와 Meta에서 오래된 편집본을 가져올 수 있는 것이 유용하다는 것을 알게 될 것이다.관리자 또는 *모든* 관리자에게 이 기능을 제공해야 하는가?

만약 이 토론으로 페이지 가져오기 기능이 생긴다면 메타에 있는 이 페이지를 참고하겠다.내가 하고 싶은 일(즉 페이지 이력을 채우기 위한 수입 편집)은 전혀 논란의 여지가 없다고 생각하지만, 편집 내용을 수입하는 능력은 잘못된 손에 위험할 수 있기 때문에 어떤 식으로든 제한을 받아야 한다고 생각한다.Graham87 15:10, 2009년 8월 14일 (UTC)[응답]

모든 위키백과에서 편집본을 가져올 수 있는 능력을 원해그래서 메인 스페이스에서는 {{iw-ref}}}와 같은 가리쉬 템플릿을 사용할 필요가 없다.–xeno^talk 15:12, 2009년 8월 14일 (UTC)[응답]

특별한 이유:en.wp에서 가져오기가 비활성화되었는가?–Drilnoth (T • C • L) 15:43, 2009년 8월 14일 (UTC)[응답]

위키백과 참조:마을 펌프(기술)/아카이브 59#특수:가져오기. 참고 항목:위키백과:마을 펌프(정책)/Archive 63#Attribution/GDFL 및 번역(및 소싱)따라온 적은 없지만, 합의를 모아 개발자들에게 켜달라고 해야 할 것 같아...–xeno^talk 18:33, 2009년 8월 14일 (UTC)[응답]

이것은 매우 좋은 생각이다.나는 개인적으로 수입 권리를 원하는 사람들과 어떤 문제도 볼 수 없다 - 그리고 나는 전에 Graham87이 복잡한 역사를 병합하는 것을 본 적이 있다. 그래서 나는 그가 그 권리를 적절하게 사용할 것이라는 것을 안다.가져오기를 허가할 수 있는가, 아니면 특정 장소에서 가져오려면 설정을 변경해야 하는가?주요토크 18:26, 2009년 8월 14일 (UTC)[응답]

사실 두 가지 수입권이 있다: 그리고 . 모든 관리자는 첫번째가 있다.그것은 어떤 WMF 위키로부터도 수입을 허용한다.유일한 문제는 수입원을 정의하는 것이다.그러나 Graham은 실제로 WMF 위키가 아닌 Rotative wiki에서 수입할 수 있는 능력을 요구한다.이를 위해서는 현재 '임포터' 사용자 그룹에만 사용할 수 있는 두 번째 사용자 권한이 필요하다.게다가 이 권리는 거의 모든 것을 수입할 수 있고 현재 WMF 위키에서 비활성화되어 있기 때문에 다소 위험하다.두 번째 사용자 권한을 활성화하는 것은 더 어려울 것이다.Ruslik_Zero 19:06, 2009년 8월 14일 (UTC)[응답]

향수는 WMF 위키다.Majorlytalk 21:18, 2009년 8월 14일 (UTC)[응답]

그렇다면 nost를 수입 리스트에 추가하는 것이 꽤 간단해야 한다. 그래서 어떤 관리자도 transwiki nost:saint를 할 수 있다. 다른 위키백과와의 유일한 차이점은 기본 피부다. -Steve Sanbeg (talk) 22:24, 2009년 8월 14일 (UTC)[응답]

WMF 위키지만 미디어위키는 아니다.대신 UseModWiki를 사용한다.따라서 수입은 어떤 마크업 번역 도구와 기능을 사용할 수 있는지에 따라 달라진다.–Whitehors1 03:02, 2009년 8월 15일 (UTC)[응답]

이 사이트와 동일한 버전의 MediaWiki를 사용하며, Rotative 스킨만 사용한다.특별 참조:향수 위키백과의 버전.Graham87 07:47, 2009년 8월 15일 (UTC)[응답]

아, 2007년 10월 기술 마을 펌프에서 이 문제에 대한 나의 횡설수설도 보았는데, 큰 호응을 얻지 못했다.그 이후로, 나는 오래된 위키백과 편집에 대해 훨씬 더 많은 탐구를 해왔고, 향수 위키백과의 역사가 영어 위키백과 데이터베이스에 있어서 편리할 수 있는 많은 사례들을 더 찾아냈다.나는 우선 거의 모든 페이지 내 역사들이 편집이 빈번하게 이루어졌다고 생각한다.위키는 여기서 수입되어야 한다.Graham87 08:18, 2009년 8월 15일 (UTC)[응답]

나는 지금 도청장치를 해야 한다고 생각한다.Ruslik_Zero 18:35, 2009년 8월 16일 (UTC)[응답]

bugzilla:80.–xeno^talk 18:57, 2009년 8월 16일 (UTC)[응답]

좋은 생각이야!정말 고마워. :-) 나는 수입자 사용자 권리와 원시 XML 덤프에서 페이지를 가져오려는 개인에게 주어지는 수입자 사용자 권리와 특수:모든 관리자가 특정 원본에서 페이지를 가져올 수 있는 가져오기.Graham87 06:27, 2009년 8월 17일 (UTC)[응답]

이 주제와 관련된 또 다른 버그가 있다.Ruslik_Zero 19:05, 2009년 8월 18일 (UTC)[응답]

그렇다, 나는 좀 더 구체적인 보고서를 제출하기 전에 그것을 알아차렸다.14264가 언제 고쳐질지 알 길이 없기 때문에 20280이 임시 반창고로 접수된다.–xeno^talk 19:07, 2009년 8월 18일 (UTC)[응답]

마이크로 포마츠

현재 Template_talk에 대한 논의가 진행 중이다.Asbox#Microformats_in_stubs, wether or not about stub 템플릿에 마이크로포맷을 추가하는 것이 바람직하다.이를 통해 예를 들어 {{Ghana-stub}}}에 특별한 마크를 추가하여 마이크로포맷 이해 시스템이 예를 들어 "Gana"가 가나라는 곳을 의미한다는 것을 감지할 수 있게 된다.논거는 다음과 같다: 해를 끼치지 않고 기계 판독 가능한 컨텍스트를 추가한다.스텁 템플릿에 복잡성을 가중시키고 스텁은 "적절한" 기사 컨텐츠의 일부가 아니며 "이 모든 위치들은 미래에 마이크로포맷 트루 인포박스를 얻게 될 것이며, 왜 작업을 두 번 하는가"라는 주장도 이에 반대한다.새로운 통찰력을 환영한다.—DJ (대화 • 기여) 2009년 8월 17일 (UTC) 19:58[응답]

나는 이것이 불필요하고 이득이 거의 없다는 것에 동의한다.짧은 템플릿은 일시적인 것으로, 기사가 확장될 때까지만 지속된다.— 마틴 (MSGJ · talk) 21:17, 2009년 8월 17일 (UTC)[응답]

고전적인 비순서.그러나 링크된 페이지로 계속 토론하십시오.Andy Mabbett(사용자:Pigsonthewing);앤디의 토크 2009년 8월 18일(UTC) 21시 55분 편집[응답]

새 사용자에 대한 사용자 하위 페이지 자동 생성

볼드의 원리를 이해하고 지지하지만, 그 가이드라인은 기존 기사 편집을 강조하고, 경험 없는 새로운 기사를 처음부터 만드는 것이 아니다.첫 번째 기사를 쓰라는 우리의 지침은 사용자 공간에서 시작하는 것을 언급하지만, 종종 무시된다.새로운 사용자들이 메인 스페이스에 새로운 기사를 만들어내고 그것이 살아남는 것을 볼 수 있다고 생각하면서 위키피디아를 찾아오고 있다.나는 선의로 기사에 시간과 노력을 쏟아 붓고, CSD나 AfD를 통해 그것이 사라지는 것을 보는 경험은 그렇지 않으면 훌륭한 편집자가 될지도 모르는 사람들에게 좌절감을 주는 것이 틀림없다고 생각한다.우리는 스크래치 형태로 기사를 쓰는 가장 좋은 방법에 대해 더 명확하게 하지 않음으로써 잠재적인 새로운 편집자들에게 해를 끼친다.

내게 간단한 해결책이 있다.

새로운 사용자가 계정을 만들 때마다 사용자 하위 페이지로 미리 채워진 계정을 보고 싶다. 사용자:새 이름/내 첫 번째 문서

유용한 조언(예: "이것이 준비되었다고 생각할 때, 편집자 리뷰를 요청하는 방법" 및 "메인스페이스로 이동하는 방법")으로 작성하십시오.

참조 작성 시 많은 새로운 편집자가 검색될 때 {{reflist}}이(가) 포함된 Notes 섹션을 자동으로 포함하십시오.나는 다른 사람들이 좋은 새로운 기사 템플릿에 추가할 수 있다고 확신한다.

내 추측으로는 사용자 공간에서 기사를 만들고, 이동하기 전에 편집자 검토를 요청한 다음 메인 스페이스로 이동하는 새로운 편집자가 CSD나 Afd를 훨씬 더 피할 가능성이 높을 것이다. 아마도 10배 정도일 것이다.

나는 이것을 비교적 적은 비용으로 주요한 이득으로 본다.--SPHILbrickT 16:59, 2009년 8월 18일 (UTC)[응답]

수많은 사용자 계정이 등록되고 사용되지 않으며, 이러한 모든 인스턴스는 편집되지 않는 페이지를 생성할 수 있다.나는 이것에 대한 일반적인 개념이 타당하다고 생각하지만, 구현은 사용자에게 "첫 번째 기사를 작성하는 데 사용할 수 있는 사용자 하위 페이지를 생성하려면 여기를 클릭하십시오"라는 선택사항을 제공해야 한다.그런 다음 당신이 설명하는 공통 요소와 유용한 노트를 미리 로드할 수 있다.–xeno^talk 17:02, 2009년 8월 18일 (UTC)[응답]

xeno, 나는 너의 아이디어가 정말 마음에 들어.음, 2009년 8월 18일 17:05 (UTC)[응답하라]

나는 또한 덜 극단적인 선택사항으로서, 만약 누군가가 요소와 메모로 페이지를 만드는 첫번째 기사 페이지를 클릭할 수 있는 링크가 있는지 궁금하다.음, 2009년 8월 18일 17:08 (UTC)[응답하라]

제노, 디스크 공간의 99%가 이미지라고 최근에 읽은 것 같은데, 공간보다는 잡동사니에 더 신경을 쓰는 게 맞나?만약 그렇다면, 페이지에는 90일 만료 날짜가 있을 수 있다.그때까지 사용하지 않는다면, 그들은 아마도 그것을 사용하지 않을 것이고, 또한 그들 스스로 어떻게 창조할 것인지 알지 못할 것이다.나는 또한 "여기에 클릭 옵션"을 좋아한다.우리는 어디에나 도움을 주기 위해 열심히 일하지만, 매일 거의 누군가가 압도당하고 어디서부터 시작해야 할지 모른다."여기를 클릭" 옵션은 내가 원하는 대부분의 것을 성취할 것이다.흐무드, 만약 내가 당신의 제안을 이해한다면, 그것은 사용자가 클릭할 수 있는 "첫 번째 기사" 조언의 링크일 것이고, 그것은 사용자 페이지를 생성할 것이다.나도 그거 좋아해.그것은 많은 사람들이 헬프 데스크에서 수행하는 일반적인 수동 작업으로, 반자동으로 만드는 것이 도움이 될 것이다.--SPHILbrickT 17:50, 2009년 8월 18일 (UTC)[응답]

잡동사니, 로그 항목 등나는 그 페이지를 사용자의 어떤 행동을 통해서만 만드는 것이 훨씬 더 좋다.–xeno^talk 17:52, 2009년 8월 18일 (UTC)[응답]

이것은 결코 끝나지 않았지만 나는 항상 위키피디아가 다음과 같이 생각하고 있다.기사 마법사는 이 문제들과 다른 문제들을 다루는 최고의 아이디어들 중 하나이다.위 서브페이지에 대해 Xeno가 제안한 링크를 통해, 환영 템플릿에서, 그리고 사용자 인터페이스의 다른 부분과 같이, 새로운 사용자들에게 보여질 수 있도록 잘 계산된 방법으로 위키피디아가 완성되어 새로운 사용자에게 제공된다면, 위키피디아에 널리 긍정적인 영향을 미칠 수 있을 것이라고 생각한다.목걸이가 만들어졌다.조만간 두 번째 시도만 하면 될 것 같다--Fuhgettaboutit (대화) 04:03, 2009년 8월 19일 (UTC)[응답]

나는 그 컨셉을 많이 좋아하지만, 몇 가지 제안이 있어.여기는 세세한 부분까지 다 쓸만한 장소가 아닌 것 같은데--너의 토크 페이지에 글을 올려야 할까?--SPHILBRIKT 22:51, 2009년 8월 19일 (UTC)[응답]

나는 오랫동안 AFC의 마법사를 바탕으로 무언가를 할 작정이었다(Wikipedia:크리에이티브/위저드-소개서)에 대한 기사들은 훌륭하고 사소한 수정만 필요할 것 같다(적어도 새로운 페이지 템플릿에 대해 이야기하기 시작하는 단계까지, 자연스럽게 확장될 것이다).나는 위키피디아에 대해 알지 못했다.기사 마법사(혹은 내가 잊어버렸는지도 모른다)는 말이지만, 그 곳이 이것을 보관할 장소인 것 같다.그리고 위키피디아는 다음과 같이 이야기한다.기사 마법사는 그것에 대해 다른 것만큼 토론하기에 좋은 장소인 것 같다.Rd232 23:09, 2009년 8월 19일 (UTC)[응답]

새로운 사용자가 하위 페이지가 존재하는지 여부를 알거나 신경 쓸 수 있을지는 잘 모르겠다. 일반적인 시작 페이지에는 적절한 텍스트가 미리 로드되어 있는 상태에서 해당 페이지를 만들 수 있는 옵션이 있을 수 있다.

-스티브 산베그 (대화) 2009년 8월 20일 19:11 (UTC)[응답]

이것은 바보 같은 질문일지 모르지만, 어쨌든 여기 다음과 같은 질문이 있다.새 사용자가 자동으로 작성된 사용자 페이지를 가져야 하는 이유(또는 사용자 페이지를 작성하라는 프롬프트가 표시되어야 하는 이유)-- 풀스톱 (대화) 2009년 8월 20일 (UTC) 19시 39분[응답]

아, 수많은 신규 사용자들이 새로운 페이지를 생성하기 때문에 컨텍스트가 부족하여 즉시 삭제될 수 있다(WP:CSD#A1), 콘텐츠 없음(WP:CSD#A3), 중요성 또는 중요성을 주장하지 못함(WP:CSD#A7) 등.게다가, 어떤 기사 마법사와 같이 통제된 과정으로, 우리는 카테고리가 포함된 새로운 기사들을 얻을 수 있고, 적절한 포맷을 장려하고, 적어도 스타일 매뉴얼을 어느 정도 준수하도록 가르칠 수 있을 것이다; 우리는 소싱이 필요한 우리의 정책, 카피비오, 공격 페이지, 그리고 모든 것이 아닌 일부 사용자들을 사용자에게 알릴 수 있을 것이다.그러나 몇몇은 이런 문제 있는 기사들을 만들어내지 못할 것이다.많은 혜택이 내재되어 있다.Special을 한 번 둘러보십시오.때때로 "노래하는 불바다"라고 불리는 새로운 페이지들은 잠시 동안 숙독된다.또는 CAT에서 Gander를 받으십시오.CSD, 저작권 침해, 모욕적인 공격 페이지, 이력서, 허영 페이지, 수정되지 않은 스팸, 여자친구에게 메시지를 스크래핑하는 사람들 등이기 때문에 매일 약 1,000개의 기사를 삭제하러 가는 CSD--Fuhgetabit (토크) 00:16, 2009년 8월 21일 (UTC)[응답]

일주일 전쯤 여기서 꺼냈던 기사 작위 발상처럼 들리는데 무시당했어내가 충분히 설명하지 못한 것 같아.지원. :)----occono (대화) 00:20, 2009년 8월 21일 (UTC)[응답]

무료 이미지/Wikimedia Commons에 대한 사이트 공지

영문 위키피디아에 300만 건에 가까운 기사가 실리면서 기고자/대중에게 무료 사용권을 가지고 사진을 올려달라는 사이트 공지가 있었으면 좋겠다.현재 우리가 가지고 있는 사이트 공지보다 나은 것 같아. 미란다 02:48, 2009년 8월 21일 (UTC)[응답]

새 메시지가 있을 때 큰 주황색 막대 대체

단지 생각일 뿐이지만, "기본 설정"이나 기기에서 선택해서 새로운 대화 페이지 메시지를 편집자에게 알리는 덜 거슬리는 방법을 선택할 수 있는 옵션이 있어야 한다.(적어도 모노북 피부에 대한) 나의 제안은 "나의 이야기"가 강조되어야 할 것이다.생각? --Ron Ritzman (토크) 2009년 8월 15일 (UTC) 22:15[응답]

그냥 직접 와서 변경을 제안했지만, 새로운 사용자에게는 "1개의 새로운 메시지가 있다!" 스팸 배너 광고로 오인될 수 있다고 생각하기 때문에.----Occono (토크) 23:40, 2009년 8월 15일 (UTC)[응답]

자바스크립트 해결책이지만 원하는 방식으로 페이지의 어떤 부분과도 유연하게 통합할 수 있는 이걸 방금 모아놨어.스크립트/설명 페이지를 개선하는 방법에 대한 피드백은 매우 감사할 것이다!그레그 타일러 23:53, 2009년 8월 15일 (UTC)[응답하라]

나는 선택적인 대안들을 지지하지만, 기본 행동에 대한 변화는 없다; 내가 "나의 이야기" 링크가 대담하다는 것을 알아차릴 수 있는 방법은 없다.거대한 오렌지 상자?놓치기 꽤 힘든데, 그게 요점이야EVULA// talk // talk // 17:20, 2009년 8월 18일 (UTC)[응답]

에볼라, 전적으로 동의해.나는 눈에 덜 띄는 것은 무엇이든 놓칠 것이다.예전에 큰 오렌지 바를 놓친 적이 있는 것 같아음, 2009년 8월 18일 17:22 (UTC)[응답하라]

나는 EVULA에 동의한다.선택적 계층화는 괜찮지만, 기본 통지는 오렌지 막대로 유지되어야 한다. --[자정 혜성] [토크] 17:27, 2009년 8월 18일 (UTC)[응답]

내 문제는 "당신에게 새로운 메시지가 있다"는 것이다.그런 사기배너 광고와 너무 비슷한 것 같아.----오코노(토크) 21:06, 2009년 8월 18일 (UTC)[응답]

좋아, 이게 얼마나 어려운 일인지 모르겠지만, 여기 *하고 싶은 것이 있다:"최신 변경" 링크 대신 최신 변경 사항이 발생한 섹션으로 안내하는 버튼이 있어야 한다.나는 "새로운 메시지"를 클릭하는 것이 싫고, 그 다음엔 그것을 찾아야 하는 것이 싫고, diff 출력은 느릴 뿐만 아니라 읽기 어려울 때도 있다. --Trovatore (대화) 21:37, 2009년 8월 18일 (UTC)[응답]

왜 "I'd"를 강조하셨죠?모든 제안 환영...----오코노(토크) 21:46, 2009년 8월 18일 (UTC)[응답]

(EC) 그렇게 하려면 상당히 비판적인 파싱이 필요할 것이다.일부 메시지에는 다음과 같은 내용이 있다./* This section */ 다른 사람들은 눈치채지 못했어몇몇 사람들은 여러 부분을 편집하고, 다른 사람들은 그들의 의견을 선두에 덧붙인다.그래, 심각한 영리한 구문 분석이나 약간의 PHP 재작성.그러나 특히 긴 사용자 대화 페이지에는 유용할 것이다.그레그 타일러21^{(t • c)}:47, 2009년 8월 18일 (UTC)[응답]

나도 구현을 설계해야 한다고? :-) 좋아, 이건 어때: 편집 요약에서 앵커 꺼내서 링크에 사용해.항상 정확한 것은 아니지만 90%는 효과가 있어야 한다.(당연 관련 프로젝트:이러한 앵커를 생성하는 코드를 수정하여 사람들이 섹션 제목에 마크가 표시되었을 때에도 작동하도록 하십시오.보통 부문별 제목에 마크업을 하면 안 되는 건 알지만 피하기 어려운 경우가 몇 가지 있다.) --트로바토어(토크) 21:50, 2009년 8월 18일 (UTC)[응답]

그래, 그럴 수도 있겠지.나는 며칠 안에 자바스크립트 코드에 대해 그것을 구현하는 것을 검토할 것이다.그레그 타일러22^{(t • c)}:02, 2009년 8월 18일 (UTC)[응답하라]

단순히 (이력) 버튼만 추가하면(이미 이렇게 하는 스크립트가 있음) 팝업을 사용하여 페이지 기록을 볼 수 있고, 거기서 섹션 앵커를 클릭할 수 있다.–xeno^talk 22:06, 2009년 8월 18일 (UTC)[응답]

그렇게 하면 현재의 작업 방식보다 한 번의 클릭이 절약될 수 있고, 여전히 역사 속 섹션 닻을 찾아야만 한다.바에서 바로 섹션으로 연결되는 링크는 클릭 두 번과 마우스 검색 시간을 절약할 수 있는 것이 정말 좋다. --Trovatore (토크) 22:50, 2009년 8월 18일 (UTC)[응답]

물론이지, 좋을 거야.–xeno^talk 22:52, 2009년 8월 18일 (UTC)[응답]

변경하려는 경우 이를 연동하십시오. 읽지 않은 메시지가 있는 동안 저장되는 것을 방지하십시오.편집하기 전에 메시지를 무시했는지 아니면 아직 읽지 않은 것인지에 대한 불확실성을 제거한다.—Kww(대화) 16:45, 2009년 8월 22일 (UTC)[응답]

모든 편집 내용을 잠그시겠습니까?당신이 단지 무언가를 바꾸기 위해 팝업을 하고 싶을 때 보다 구체적으로 로그온할 때 알림을 제자리에 두고 싶을 때는 어떨까?그레그 타일러 19:35, 2009년 8월 22일 (UTC)[응답]

그래, 편집도 없고 디저트도 없고 거위 스텝도 3시간이나 걸렸어BNW 사방에서.NVO (대화) 2009년 8월 22일 19:55 (UTC)[응답]

내가 다른 페이지를 편집하는 동안 누군가가 내 토크 페이지에 메시지를 남기고 내가 "저장 페이지"를 누르면 WP는 머리글을 포함하지 않고 새로운 섹션을 만들려고 할 때, 즉 위쪽에 캡션이 있는 페이지의 미리보기를 보여주어야 한다.당신의 토크 페이지에 남겨져 있다.다시 "저장 페이지"를 누르면 편집 내용이 저장되거나, 또는 여기를 클릭하여 메시지를 새 창에서 여십시오.(즉, 사람들의 편집 내용이 손실되는 것을 원치 않기 때문에 새 창) Andrew Gradman _WP:Hornbook/ 15:03, 2009년 8월 23일 (UTC)[응답]

인터위키 동기화

내 제안은 템플릿을 사용하는 것이다.템플릿:인터위키 분쟁에 관련된 모든 페이지의 이와키 분쟁.m페이지에서 찾을 수 있는 자세한 정보:인터위키 동기화 및 템플릿 설명서또한 위키피디아의 다른 언어 섹션에서 기여하는 사용자들은 그러한 언어에서 템플릿의 번역된 유사점을 만들 수 있다.만약 우리가 모든 언어에서 유사한 템플릿을 갖게 된다면 우리는 봇을 사용하여 관련된 모든 페이지에 템플릿을 자동으로 추가할 수 있을 것이다.이 아이디어에 대해 어떻게 생각하십니까?딕슨D (대화) 2009년 8월 16일 (UTC) 20:41, 응답하라

좋은 생각처럼 들리지만, 나는 기사 자체에 메시지 박스를 보증하는 것이 충분히 중요하다고 생각하지 않는다.그러나 나는 대화 페이지에 있는 메시지에 문제가 없을 것이고 나는 이러한 목적을 위해 Template:iwiki-conflict를 과감하게 변환했다.안부 — Martin (MSGJ · talk) 07:59, 2009년 8월 17일 (UTC)[응답]

오, 난 이미 이것에 대한 답을 받았어: 위키백과:요청된_템플릿이지만 이 페이지가 토론에 더 적합하다고 생각한다.거기에 대한 나의 코멘트:

나는 그것이 예를 들어 "이 기사는 고아다", "이 기사는 위키백과가 필요할지도 모른다"와 같은 중요성을 가지고 있다고 생각한다. 인터위키 동기화는 대부분 위키피디아의 존재조차 모르기 때문에 위키피디아 사람들의 관심이 거의 없다. 만약 우리가 기사에 템플릿을 설정한다면, 문제는 매우 빨리 해결될 수 있지만, 토크 페이지에서는 그렇지 않다.딕슨D (대화) 11:29, 2009년 8월 17일 (UTC)[응답]

나는 "인터위키가 충돌하는 예술품"과 같은 카테고리를 추가하는 템플릿을 만드는 것은 나쁘지 않을 것이라고 생각하지만, 크고 빛나는 상자들을 어디에나 놓는 것은 반대한다.이미 너무 많이 가지고 있어.혹시 분쟁에 대한 정보를 인터위키 박스에 직접 넣는 것이 가능할까?예를 들어 언어 이름 옆에 있는 물음표?그 언어의 사용자들은 그것을 알아차릴 것이고 아마도 그것을 고칠 것이다.램팍 (토크) 2009년 8월 17일 (UTC) 16:41, P.S. 그러나 기술적으로는 가능할지 의문이다.램팍 (토크) 2009년 8월 17일 (UTC) 16:45[응답]

나도 기술적으로 가능한지 의심스럽지만, 이 경우라면 모든 언어에 물음표를 붙이는 것이 타당하다. 왜냐하면 우리는 정확히 무엇이 갈등을 야기시켰는지 그것이 해결될 때까지 모르기 때문이다.하지만 어쨌든 나는 대화 페이지로 정보를 이동시키는 것이 기사들의 거의 독자들이 심지어 위키간 갈등이 존재한다는 것을 알아차리지 못하게 할 것이라고 생각한다.예를 들어, Talk를 보십시오.오픈 소스 및 토크:오픈 소스 소프트웨어.나는 네가 처음부터 인터위키에 문제가 있다는 것을 알아차린 것이 정말 의심스럽다:) 딕슨D (토크) 17:04, 2009년 8월 17일 (UTC)[응답하라]

템플릿 보기:인터위키콘플릭트?— 마틴 (MSGJ · talk) 2009년 8월 23일 (UTC) 14:04[응답]

플래그 지정된 리비전에 대한 질문

제안서를 작성 중이었는데, 위키피디아의 변형인 것을 알 수 있다.지연된 수정사항 및 위키백과:수정 지연.두 가지 질문:

1. 영어 위키백과의 버그 리포트를 보긴 하는데 언제 고쳐질지 모르겠어.대략적인 추측(주)이 있는가?몇 달?몇 년?)
2. 다른 언어용으로 설치된 것으로 알고 있다. Tagalog에 작동하지 않을 것이라고 생각하는 이유가 있는가?--SPHILbrickT 13:02, 2009년 8월 21일 (UTC)[응답하라]

이중 리디렉션

위키백과의 후속 조치:빌리지_pump_(proposals)/Archive_44#Double_redirects, 나는 위키백과 토크에 다음과 같은 메모를 올렸다.이중 리디렉션#많은 이중 리디렉션이 좋다.— 세바스찬 00:47, 2009년 8월 24일 (UTC)[응답]

제안

2009년 8월 24일

좋은 날 위키피디아에 있는 모든 사람들,

나는 당신이 지금쯤 지구 전역과 여러 언어로 된 사람들로부터 축하를 받는 데 익숙할 것이라고 확신한다.내 것은 당신의 수집품에 또 다른 것을 추가하는 것인데, 그것은 매우 잘 되어 있고 모든 인류의 이익을 위해 계속 성장하고 있다.그런 점에서 지미 웨일즈와 위키백과의 팀 전체에게 나의 행운을 빈다.

나 또한 고려해야 할 한두 가지 제안이 있다.

첫 번째 방법은 목록에 다른 포털을 추가하는 것이다.비즈니스와 경제라는 이름의 포털을 가져보는 것은 어떨까?포털에는 회계, 장부 기록, 채무불이행/연기 및 파산을 포함한 신용, 경제, 금융, 보험, 투자, 담보 및 개인 대출(신용의 일부를 형성하거나 단순히 별도로 취급할 수 있음), 프로젝트 관리, 정성 분석, 정량 분석, 위험 관리, 통계, 통계 등의 주제가 포함될 것이다.기타 관련 주제.

포털이 별도로 요청하면 어떻게 시작하시겠습니까?우선 현재 영어로 되어 있는 300만 플러스 기사에 열거된 각 기사를 분류하고, 기사 이름 옆에 있는 분류를 상호 참조로 표시하겠다.예: Cat - Portal: 자연 및 물리 과학, 하위 범주 생물 과학.모든 기사를 영어로 분류함으로써, 비즈니스 및 경제 포털의 일부로 분류되는 모든 기사들과 연결 하위 카테고리를 적절히 식별하고 색인화하며 새로운 포털에 포함시킬 것이다.예: 대 –대 – : 비즈니스 & 비즈니스 & 경제, 하위 카테고리 회계.

따라서, 그리고 머지않아, 새로운 비즈니스 및 경제 포털은 참조를 위한 포괄적인 정보 출처일 뿐만 아니라, 학교, 대학 및 물론 실제 생활 환경에서 적용될 수 있는 모든 주제에 대한 자체 학습 도구와 지침이 될 것이다.나는 별도의 포털 접근법이 학습 증가를 촉진할 수 있다고 믿는다.예를 들어, 비즈니스 및 경제 포털에 직접 액세스하는 사람은 주요 사이트에서 알 수 없었던 흥미롭고 유용한 정보를 배울 수 있다.

모든 사람들이 쉽게 참조할 수 있도록 인쇄된 형태로 인간 지식의 총합을 포착하려는 웨일즈씨의 철학과 함께, 나는 이 정보를 효과적으로 사용하는 것이 사람들이 스스로에게 알릴 수 있을 뿐만 아니라(수동적 접근법) 개인적인 이익을 위해 이 정보를 사용할 수 있도록 자기 학습 및 자습서 가이드로 묘사하는 것이라고 믿는다.d 인간의 진보(창의적, 진보적, 건설적 접근)를 촉진한다.

당신들 진실로

찰스 로이

• 안녕 찰스Portal에서 당신이 관심을 가질 것 같이 들리는데 (그리고, 나는, 환영할 것이라고 확신한다.사업과 경제.위키백과에 온 걸 환영해!
  — Ω (토크) 02:59, 2009년 8월 25일 (UTC)[응답]

링크 위에서 맴돌 때 단어의 축약된 항목/정의 표시

안녕, 나는 오랫동안 위키피디아 사용자야. 비록 오늘 이 메시지를 올리기 위해 계정을 등록했지만.기사를 읽을 때 페이지 링크를 하나 이상 클릭해 관련 주제에 대해 읽거나, 관련 개념 등에 대해 더 자세히 알아보곤 한다는 것을 알게 되었다.그러나 자주 나는 내가 읽고 있는 개념에 대한 설명이나 이해를 위해 링크를 클릭하거나 또는 특정 단어의 정의를 위해 링크를 클릭하고 연결된 기사를 간략히 읽은 다음 다시 가서 계속 읽을 것이다.

제 제안은 기사의 링크를 가리키면 커서가 해당 기사의 요약/요약 항목을 표시하거나 단어의 짧은 정의(적절한 경우)를 표시하는 겁니다.이제 나는 이것이 실행되려면 시간이 좀 걸릴 것이라는 것을 이해한다. 왜냐하면 거의 모든 기사에 대해 요약 항목이 만들어져야 하기 때문이다. 그러나 나는 정말로 글의 읽기 능력과 이해에 이점이 있다고 생각한다.실제로 요약본은 관련 기사의 개념이나 주요 아이디어, 또는 단어의 짧은 정의를 누군가에게 대략적인 정보를 제공하기에 충분할 것이다.

이것이 위키에서 실행하기에 유용한 변화라고 생각하는 사람?

피드백을 줘서 고마워.

벌써 잡았어!네비게이션 팝업이라고 하며, "내 기본 설정"(로그인 중에 페이지 맨 위에 있는 경우)을 클릭한 다음 "게젯"에서 네비게이션 팝업을 확인하여 해당 팝업을 켤 수 있다.던컨힐 (대화) 2009년 8월 15일 16:59 (UTC)[응답]

나도 팝업을 지지할 거야때때로 팝업은 내가 방문하지 않아도 될 만큼 충분한 정보를 담고 있다(예를 들어 정의), 팝업이 내가 보고 싶은 곳이 아닐 것이라는 것을 알려준다.요컨대, 나는 그들을 사랑한다.--SPHILbrickT 23:10, 2009년 8월 15일 (UTC)[응답하라]

야, 잘했어! 조심해줘서 고마워.

디폴트(채무불이행)로 하는 동작을 시작하겠다.----오코노(토크) 03:47, 2009년 8월 17일 (UTC)[응답]

나는 그것을 지지할 수 있다.원하지 않는 사용자도 있을 수 있으니 끌 수 있는 옵션이 있었으면 좋겠다.옵션을 그대로 두고 기본 설정을 "on"으로 변경하면 된다.--SPHILbrickT 11:10, 2009년 8월 17일 (UTC)[응답]

많은 사람들이 당장 끄고 싶어 할 것 같아.나는 매우 빨리 그들에게 질렸다(마우스를 움직일 때마다 실수로 새로운 팝업을 촉발하고 있었다).그럼에도 불구하고, 나는, 예를 들어 팝업 자체 내에서 그것들을 끄는 옵션이 매우 투명하다면, 이 아이디어를 지지할 수 있다.앤드루 그래드먼^talk/_WP:Hornbook 2009년 8월 23일 (UTC) 14:53[응답]

나는 그것을 시도해 보았지만 참을 수가 없었다.모든 사용자들이 그것을 켤 수 있는 선택권을 가지고 있기 때문에, 더 나은 제안은 사용자들이 그것을 알게 하기 위해 때때로 배너 광고를 하는 것이라고 생각한다.노이즈알트 (대화) 2009년 8월 25일 (UTC) 11시 38분 (답변)

제안: AIV에서 어리석은 관료주의 제거

내가 가끔 마주친 것은 AIV에서 관료주의를 위한 것으로 보이는 것이다.어느 관리자가 보고서를 보느냐에 따라(필수적으로 내 것은 아니지만) 노골적인 반달 전용 계정이 차단되거나 "충분히 경고받지 못했거나 잘못 경고받았기 때문에 블록 요청이 거절될 수 있다.보아하니 테스트1부터 테스트4까지 순서대로 가야 차단할 수 있다.

나는 분명히 게임을 하러 온 사람들에게 그들의 밴드에 대해 새로운 특허 난센스나 스팸 기사를 만들어내고 그들이 여러 번 속도를 낸 후에 계속해서 그것들을 재생산하는 것에 대해 4가지 경고를 하는 것은 그 가치를 이해할 수 없다.그들 중 90%는 자신이 무엇을 하고 있는지 정확히 아는 지루한 아이들이다.나머지 10%는 완전한 블록헤드가 아닌 누구에게나 꽤 명백하며, 따라서 도움을 받을 수 있다.

AGF와 새로운 편집자들을 환영하는 것이 자살 협정이 되어서는 안 된다.AIV에서 보고된 명백한 트롤들은 누군가가 차단하기 전에 4개의 경고를 하고 더 많은 반달리즘을 되돌리고 더 많은 쓰레기 페이지를 신속하게 태그하는 과정을 거치지 않고도 차단되어야 한다.어서, 우린 보곤이 아냐!<<멀티엑스퍼> (토크) 00:46, 2009년 8월 19일 (UTC)[응답]

당신이 생각하는 것만큼 어리석은 관료주의는 정말로 많지 않다.진짜 핵심은, 누군가가 단지 실험을 하고 있거나, 그들의 편집이 얼마나 성가신지 깨닫지 못한다면, 우리는 선의로 가정하는 것이다(누군가 그런 말을 할 줄 알았지, 그렇지? 적어도 나는 그들을 어두운 쪽에서 돌릴 수 있다는 것을 연결하지 않았다.명백한 반달사과를 4번 물리고 싶지는 않지만, 실험자들에게 몇 번 물리고 싶은 것은 사실이다.예를 들어, 그들의 밴드에 관한 기사를 작성하는 사람은 실제로 반달패가 아니다. 그들은 새롭고, 규칙을 이해하지 못한다. 그리고 (만약 그들의 기사가 빠르게 삭제된다면) 교차할 가능성이 있다.경고는 이것을 설명하려고 한다.그들이 경고를 무시하고 반복적으로 재창조해야만 우리는 그것을 차단하고 싶다.

몇 가지 포인터가 있다.첫째, 4가지 경고 단계를 모두 사용할 필요는 없다. 나는 종종 레벨 1, 레벨 3, 레벨 4, 리포트 경로를 가거나 레벨 1, 2, 3 리포트 가기도 한다.'하이맘' 편집으로 레벨4로 출발하면 손목을 때리지만, 차단을 언급하는 경고, 엄중한 경고, 경고 등을 준 뒤 계속하면 손목이 막힌다.모든 관리자들은 자신의 판단력을 사용하고 있기 때문에, 아직 적절하다고 생각되지 않으면 실제로 누군가에게 차단을 강요할 수는 없다.때로는 세 가지 경고라도 요구하는 것이 분명히 필요하지 않다는 데 동의하지만(예: "하하 나는 파괴하고 있는데 당신은 나를 막을 수 없다") 시간을 내서 왜 당신이 보도하는 편집자가 일반 규칙의 예외여야 하는지를 명확하게 설명한다면 행정관이 이를 차단할 것이라는 것이 나의 경험이었다.거긴 빨리 움직이는 곳이니까, 그 사람들이 네 마음을 읽기를 기대할 수 없을 거야.보고서에는 "IP가 차단될 때까지 지난달 같은 기사가 파손됐다"(혹은 그)는 추가 문장이 나와 차이를 만든다. --Floquenbeam (토크) 01:27, 2009년 8월 19일 (UTC)[응답]

플로크는 여기서 정곡을 찔렀다.AIV는 다소 미묘한 장소인 만큼 신인을 물지 않는 것과 백과사전의 피해를 막는 것 사이에서 균형을 맞춰야 한다.어떤 반달리즘은 경고 없이 한 블록을 보증하는 반면, 어떤 반달리즘은 그것을 제거하기 위해 단지 부드럽게 구슬릴 필요가 있다.그리고 이 사용자가 이제 긍정적인 기여자(지금쯤 사람들은 내가 그것을 지적하는 것에 질려 있을 것이다 =)라는 것을 잊지 마십시오.

내 목적을 위해 나는 보통 명명된 계정의 경우 {{welcome-vandal}}부터 시작하고, IP의 경우 L3(이것은 가벼운 테스트 편집 유형 파괴 행위를 제외한 모든 것의 시작점이기도 하다)를 따라 거기서 출발한다.내가 말하고자 하는 요점은, 문맥이 중요하다는 거야.

어쨌든 AIV는 다음 주에 하이퍼 스페이스 바이패스로 대체될 예정이므로 이 중 어느 것도 문제가 되지 않을 것이다.–xeno^talk 01:33, 2009년 8월 19일 (UTC)[응답]

나 자신은 거의 항상 1,2,4단계를 간다 - 레벨 3 경고를 거의 사용하지 않는다.대부분의 경우, 두 번의 편집 후(그리고 거의 확실히 3번 이후) 누군가가 계속해서 나쁜 편집을 지속할 가능성이 있는지 알고 있다; 나는 오랫동안 우리가 단지 세 단계의 경고만을 가져야 한다고 느꼈고, 아마도 한 번의 "우리가 당신을 차단할 것" 경고는 네 번째 레벨에 상당할 것이다.여기에 공감대가 있다면, 그것이 내가 가장 보고 싶은 단순화다.— 가비아 임머 (대화) 2009년 8월 19일 01:59 (UTC)[응답]

또 다른 중요한 측면은 타이밍이다.트윙클과 허글 덕분에 레벨 1 경고를 받은 사용자들은 레벨 1 경고 이전에 발생한 공공 기물 파손으로 레벨 2를 받은 경우가 종종 있다.예를 들어, 나는 그 경우에 4로 밀고 갈 것 같지 않다.Floquenbeam과 Xeno가 말했듯이 각각의 상황을 개별적으로 판단해야 한다.~ 아모리(사용자 • 대화 • 기여) 02:25, 2009년 8월 19일 (UTC)[응답]

제 질문은, 만약 어떤 관리자들이 세 가지 경고만 하면 되는 패턴이 있다면...왜 우리가 4개를 가지고 있지?나는 OP가 만드는 요점이 어떤 면에서는 옳다고 생각한다; 그는 "우리는 4개가 필요하다, 왜냐하면 그만큼 경고가 많기 때문이다"라고 말하는 것이 관료주의적이라고 지적한다. --Izno (대화) 03:03, 2009년 8월 19일 (UTC)
PS: 하이퍼스페이스 바이패스?=d[답글]

나는 4가지 경고를 모두 받아야 한다고 요구하는 어떤 관리자도 알지 못하지만, 그들은 마지막 경고가 4단계 경고라고 강요하는 경향이 있다.나는 일반적으로 편집이 우연한 사고였을 수도 있다고 스스로 확신할 수 없는 한 레벨 1을 건너뛰고, 보고가 거부되지는 않는다.마지막 경고는 다음 편집으로 인해 차단될 것이며, 차단되어야 할 편집은 해당 경고가 주어진 후에 발생한다고 명시적으로 말하는 것이 중요하다.나는 그것이 지나치게 까다롭다고 생각하지 않는다.—Kww(대화) 03:16, 2009년 8월 19일 (UTC)[응답]

그것이 균형잡힌 행동이라는 것에 모두 동의하라.대부분의 관리자는 로봇적으로 4가지 경고를 요구하지 않는다.단 한 종류의 페이지가 있는데, 내 책에는 두 가지 이상의 경고까지 하는 것은 매우 나쁜 생각이다: 명백한 BLP에 대한 악의적인 공격 페이지(경고 없이 내가 차단하는 페이지)-후게트 어바웃트 (토크) 03:52, 2009년 8월 19일 (UTC)[응답]

내가 그것을 꺼낸 이유는 내가 전에 한 보고서 때문이라고 추측한다.나는 항상 새로운 페이지를 순찰한다.누군가 헛소문을 만들고 다시 만들어 왔었는데 그들이 뭘 하고 있는지 알고 있는 게 분명했다...그들은 여러 개의 삭제 통지를 무시하고 경고를 받았었다. 처음에는 시험1로 그리고 나서 그들이 기사를 몇 번 더 재현한 후에 나는 시험4를 떠났다.AIV에 보고되었고, 그들이 불충분하거나 잘못 경고했다는 말을 들었다. 그리고 그들이 그것을 계속하면 다시 보고하러 오라는 말을 들었다.그들은 같은 터무니없는 기사를 계속 재작성하다가 결국 다른 관리자에 의해 저지당했다.나는 n00bs와 그것을 제대로 이해하지 못하는 누군가에게 여유를 주어야 한다고 생각하지만, 대부분의 사람들이 "나의 데스 메탈 밴드가 세계에서 가장 위대하다" 등 몇 문장만 쓴 글이 세 번째가 되면, 그것이 계속 삭제된다는 것을 우연히 알아차릴 것이라고 생각하는 경향이 있다.그리고 내가 그 때 그들의 페이지에 남긴 관련 경고들(보통 그들의 공공연한 공공 기물 파괴 행위들이 얼마나 노골적인지에 따라 test1 또는 test3)은 아마도 어떤 의미가 있을 것이다.관리자마다 다르게 반응하는 경향이 있다는 것을 알게 되었다...어떤 사람은 내가 하는 대로 생각하고 (적어도 내가 보는 대로) 명백한 반달족인 사람들에게 블록을 발행하는 것처럼 보이는 반면, 다른 사람들은 중간에 있고, 다른 사람들은 시험1-4의 완전한 게킷이 아마도 몇 번, 그리고 심지어 그들은 6시간 블록만 주지 않는 한 거의 모든 사람을 차단하는 것을 주저하는 것 같다.많은 것이 개인의 해석에 달려 있는데, 나는 단지 몇 번의 경고 없이 명백한 반달 계좌를 즉시 차단하는 것이 더 쉬웠으면 좋겠는데, 어쨌든 그들은 웃고 있을 것이다.편집: 여러분 모두 좋은 점을 가지고 있다.플로크 말이 맞아<<멀티엑스퍼> (토크) 04:48, 2009년 8월 19일 (UTC)[응답]

명백한 반달 IP는 패턴이 있으면 바로 차단해야 한다(단일화라면 잊어버려라).명백한 반달 계정은 어쨌든 차단되어야 한다(자동 확증을 막기 위해).만약 그것이 명백하지 않다면(그들은 단지 실험일 수도 있다), 차단하기 전에 경고가 적절할 수도 있다(나는 경고가 1, 또는 절대 최대 2라고 생각했을 것이다, 경고는 항상 경고가 충분할 것이라고 생각했다.우리는 우리의 진정한 편집자와 독자들에게 우리의 백과사전에 예방할 수 있는 손상을 허용하는 것보다 더 많은 존경을 보여야 한다; 우리는 확실히 그들이 그들의 시간을 허비하게 만드는 것보다 더 많은 존경을 보여야 한다. (만약 반달족이 개혁하려고 한다면, 그들은 블록이 만료된 후에 그렇게 할 수도 있고, 사과하고 그것을 개정하도록 요청할 수도 있다.OKed - 만약 그들이 정말로 긍정적인 기여에 관심이 있다면, 그들은 블록이 배치된 이유를 이해할 것이고, 그들의 기여를 피해로부터 보호하기 위한 조치가 취해진다는 것을 알도록 격려될 것이다.) --Kotniski (대화) 09:13, 2009년 8월 19일 (UTC)[응답]

이봐, 아무도 이 문제에 대해 동의하지 않는다면, 아마 지금이 정책으로 삼을 때일지도 몰라...아니면 반론이 있는가?--코트니스키 (토크) 2009년 8월 22일 (UTC) 14:09[응답]

그 과정은 꽤 잘 되어가고 있는데, 나는 상황을 바꿀만한 설득력 있는 이유를 모르겠다.몇 번의 경고 후에 그들 자신의 동의서를 파기하는 것을 중단하는 사람은 바로 대문 밖으로 막히는 사람보다 유용한 기여자가 될 가능성이 훨씬 높다.RxS (대화) 2009년 8월 22일 14:24 (UTC)[응답]

그것에 대한 어떤 증거라도 있니?"막히는 것"은 그것이 우리에게 가지고 있는 일상적인 반달과 같은 의미를 가지고 있지 않다는 것을 기억하라.그리고 그 과정은 꽤 잘 될 수도 있지만, 여전히 많은 노력이 예방 가능한 반달리즘을 되돌리고 무의미한 경고를 하는 데 낭비되고 있고, 많은 반달리즘이 통과되어 우리의 백과사전을 손상시키고, 어쩌면 더 많은 사람들(비반달인)이 기여하는 것을 단념하고 있다(당신이 쓴 글이 어떤 것이든 파괴될 것 같다고 생각한다면).y, 왜 시간을 낭비하는가?)나는 이 "vandals may reform"의 주장은 상당히 가냘프다고 생각한다(feel은 길을 개혁할 것 같고, 막히는 것은 개혁을 멈추게 해서는 안 된다).---코트니스키 (talk) 14:39, 2009년 8월 22일 (UTC)[응답]

이것을 읽는 것은 특히 명백한 반달과 관련하여 우리가 주는 충고를 바꿔야 한다는 것이다.나는 코티스키의 의견에 동의한다.더그웰러 (대화) 2009년 8월 22일 14:51 (UTC)[응답]

공공 기물 파손이 새로운 편집자들을 편집하지 못하게 하고 있다는 증거가 있는가?나는 여기서 많은 일반성을 볼 수 있지만 별로 구체적인 것은 없다.현재 과정은 관리자가 뉘앙스를 가질 필요가 있는 유연성을 제공한다.나는 단 하나의 경고(또는 어떤 경우에는 전혀 경고하지 않음)로 반달들을 차단했기 때문에 이 중 어떤 것도 돌로 쓰여 있지 않다.일부(전부는 아님) 반달 투사들은 지나치게 열성적일 수 있고 우리는 새로운 사용자를 쉽게 물게 해서는 안 된다.내가 말했듯이, 그 과정은 이제 잘 되어가고 있어, 그것을 바꿀만한 설득력 있는 이유는 없어.기물을 물어뜯지 않는 것이 반달 전사의 시간을 절약하는 것보다 더 중요하다.RxS (대화) 15:08, 2009년 8월 22일 (UTC)[응답]

당신은 아무것도 돌로 쓰여 있지 않다고 말하지만, 그때 우리는 그들이 적절한 수의 경고를 받지 못했다는 이유로 반달들을 막는 것을 거부하는 관리자들의 이야기를 듣는다.만약 그 지침이 경고가 차단을 위한 전제조건이 아니라는 것을 분명히 한다면(지금보다 훨씬 더 명확하게), 관리자들은 적절한 곳에서 차단을 훨씬 더 융통성 있게 느낄 것이라고 생각한다.하지만, 우리는 이것이 명백한 공공 기물 파괴 행위에만 적용된다는 것을 분명히 해야 한다.부적절한 경고는 부적절한 블록만큼 새로운 사람들을 물어뜯는 것이다. 그것은 다소 다른 문제다.우리는 여기서 전혀 신입이 아닌 분명히 우리를 해치기 위해 온 사람들에 대해 이야기하고 있는데, 그들에게 여전히 예의 바르게 대할 수는 있지만(그들이 조만간 신입이 되고 싶어 할 경우에 대비해서) 더 많은 해악을 저지할 수는 있다.--코트니스키 (토크) 15:44, 2009년 8월 22일 (UTC)[응답]

나는 AIV에서 4개의 경고가 없었기 때문에 보고가 거절된 증거를 보고 싶다.최종적인 경고가 주어지지 않았기 때문에 거절당하는 것을 많이 보지만, 그것은 완전한 1,2,3,4 시퀀스를 고집하는 것과는 실질적으로 다른 문제다.—Kww(대화) 16:47, 2009년 8월 22일 (UTC)[응답]

OP가 말하는 것처럼 여전히 어리석은 관료주의다.사실 AIV에 대한 나 자신의 경험은 꽤 긍정적이었다. - 만약 공공 기물 파손자가 있다면, 누군가가 경고를 주장하지 않고 막을 것이다. - 하지만 우리가 하는 지시사항들이 그렇게 보이게 하지는 않는다.따라서 많은 사람들은 백과사전이 언제 그렇게 하는 것이 그들에게 이로울지 확실히 보고하는 것을 주저하고 있다.-코트니스키 (토크) 17:04, 2009년 8월 22일 (UTC)[응답하라]

(outdent)법정에서 '합리적인 의심을 넘어' 기준 이면의 이상은 종종 우리가 10명의 죄 없는 사람들이 감옥에 갇힌 후 석방되는 것을 보는 것이 낫다는 생각의 표현으로 시민학 수업으로 요약된다.프로젝트의 핵심 원칙으로서 우리는 반달 나사를 몇 개 쉽게 되돌릴 수 있도록 하는 것이 우리가 밝은 눈을 가진 잠재적 기여자들을 겁주지 않도록 확실히 하기 위해 지불하는 대가라고 생각해 왔다.어떤 사람들은 크리넥스 기사를 "젠장 꺼!!"라고 부를 수도 있지만, 공공 기물 파손 행위는 의도적인 것이거나, 조잡하더라도, 시험일 가능성이 높다.사람들은 이 접근법에 대해 찬성하거나 반대할 수도 있지만, 언급된 유죄판결기준과 같이, 이 시점에서 그것은 대부분 올바른 이유로 결정된다. --M^ask? 09:15, 2009년 8월 25일 (UTC)[응답]

뭐? 아무것도 정해진 게 없어. 아무도 감옥에 갇히지 않을 거야.눈이 밝은 새내기들은 그런 종류의 일을 하지 않는다. (아니면 그렇게 한다면, 왜 그들이 그것에 대해 차단당하는지 이해할 것이다.); 진짜 밝은 새내기들은 상주 관료들이 진짜 편집자들보다 반달의 편을 드는 것을 볼 때 기고를 단념할 가능성이 몇 배 더 높다.---코트니스키 (토크) 09:46, 2009년 8월 25일 (UTC)[응답]

정책 및 가이드라인 개선 추진

Wiki Project 정책 및 가이드라인에 참여하십시오!

지름길 WP:PROJPOL

"정책 및 가이드라인 개선 드라이브"를 실시하기 위해 지역사회 자원을 따로 마련해야 할 때인가?생각해 보면, 위키피디아가 최근(지난해에서 18개월 사이) 어느 정도 티핑포인트에 도달했을 가능성이 있다.현재 300만 건이 넘는 기사가 있으며, 위키피디아가 구글에 정기적으로 소개되고 있으며, 사용자 기반은 크기와 성격 면에서 모두 바뀌었으며, 지배구조 자체가 상당히 발전했다.나는 어떤 정책과 지침이 그들의 나이를 보여주고 있다는 무정형적인 느낌을 다른 어떤 특정한 것을 염두에 두고 있지 않다.아직도 갈등이 많이 발생하는 것 같고, 그 중 일부는 내 생각으로는 (낙하산) 정책 때문이기도 하다.그다음에 삭제 정책 같은 현실적인 문제들이...어쨌든 나는 무슨 이유에선지 이 일을 생각하고 있었고, 그 얘기를 꺼내고 싶었다.
— Ω (토크) 2009년 8월 23일 11:16, (UTC)[응답]

그래. 우리 정책은 너무 읽기 어려워.나는 이것을 지지할 뿐만 아니라, 자발적으로 범퍼 스티커를 인쇄한다.앤드루 그래드먼 _WP:Hornbook/ 2009년 8월 23일 (UTC) 15:07 (응답)

PS 나의 개인적인 관심사는 정책을 명확히 하는 것보다 변화와 덜 관련이 있다.그러나 최근의 경험에서, 내가 정책을 명확히 하려고 할 때마다, 불분명한 언어의 "목적"은 사람들이 결코 그 점에 동의하지 않았다는 사실을 모호하게 하는 것이었다는 것을 밝혀냈다; 그 언어는 의도적으로 모호해서 양쪽이 모두 이긴 것처럼 느끼게 한다!앤드루 그래드먼^talk/_WP:Hornbook 2009년 8월 23일 (UTC) 15시 10분[응답]

그것은 실제로 우리가 논의해야 할 근본적인 문제를 제기한다.전통적으로 위키피디아의 정책과 지침은 의도적으로 더 서술적이고 규범적이었다.나는 그것이 완전히 포기되어서는 안 된다고 생각하지만, 아마도 그것은 이제 규범적인 쪽으로 조금 더 구부러지기 시작해야 할 것이다.결국, 우리를 미래로 인도할 수 있고 또 그래야 할 꽤 괜찮은 양의 역사가 지금 전개되고 있다.
— Ω (토크) 22:24, 2009년 8월 23일 (UTC)[응답]

참고: 이 글을 쓴 후, 나는 비슷한 생각을 가진 유일한 사람이 아니라는 것을 알게 되었다.특히 Wikipedia를 참조하십시오.개혁을 위한 영역#잘못 쓴 정책들.나는 사실 여기서 더 넓고, 더 목적 있는 노력을 생각하고 있었지만, 기존의 노력에 연결해서 그것을 추진하려고 하는 것은 문제가 없다.
— Ω (토크) 05:13, 2009년 8월 24일 (UTC)[응답]

WP도 있다.위키프로젝트 정책 및 지침 및 WP:유사한 목적을 가진 위키프로젝트 스타일 매뉴얼우리들 중 몇몇은 정책과 지침을 개선하기 위해 꽤 많은 시간을 소비하지만, 그것은 여러분이 금방 질리게 되는 과제인데, 왜냐하면 그들은 그것이 논쟁을 이기는데 도움을 준다고 생각하거나 위키피디아가 그것 없이 무너질 것이라고 생각하기 때문이다.--- 코트니스키 (토크) 08:01, 24 아우구.st 2009년 (UTC)[응답하라]

그렇다, 나는 단지 몇 개의 토크 페이지와 위키피디아에서 무슨 일이 일어나고 있는지 읽는 것만으로 당신이 언급하고 있는 것을 이해하게 된다.개혁을 위한 영역.하지만 내가 생각하고 있던 것은 실제로 그런 종류의 잡음을 깨기 위한 수단이 되어야 한다.결국 '신선한 피'의 주사를 통해 당신이 말하는 일종의 내적 싸움을 해체하는 가장 좋은 방법이지."만약 우리가 일반적으로 실제 정책/지침 형성에 참여하지 않는 일부 사람들(예: 나 자신)을 최소한 살펴보고 편집하도록 장려할 수 있는 일반적인 개선 노력을 광고한다면"라고 문서들은 말했다.
— Ω (토크) 09:22, 2009년 8월 24일 (UTC)[응답]

이것을 읽으면서 처음 생각한 것은, "왜?지금 너한테 화내는 사람이 충분하지 않아?대신 창조론이나 만성피로증후군을 편집하러 가지 않겠는가?"

진지하게 말하자면, 거의 모든 정책이나 가이드라인의 일부를 개선할 수는 있겠지만, 정책을 읽는 데 있어 완벽해 보이지 않는 것을 단순히 "수정"하는 것보다 좀 더 복잡하다는 것을 알게 될 것이다.불분명하고 불손한 언어는 이유가 있어서 자주 등장한다.근거가 명확하고 문서화할 수 있는 실제 합의의 결여에서부터 편집자 혼란, 합의 내용이 무엇인지에 대한 명백한 불확실성까지 다양하다.한 페이지, 또는 관련 페이지의 클러스터를 채택하고, 그 페이지가 다루려고 하는 실제 문제를 파악하기 위해 한 달 동안 시간을 보내는 것이 좋을 것이다.

예를 들어, 한 가이드라인은 동일한 문구를 4번 반복한다("WP가 아니다:RS! 성명서), 토크 페이지 상단에 있는 큰 오렌지색 배너를 세지 않고, 여전히 편집자들이 신뢰할 수 있는 출처에 대해 불평하는 것이 적절한 페이지인지에 대해 질문하게 한다.문학적인 관점에서 보면, 이 정도의 중복성은 형편없지만, 나는 정기적으로 이런 메시지들을 좀 더 공격적으로 만드는 것에 대해 생각한다.아마도 컨텐츠에 대한 클릭-스루 스크린이 도움이 될 것이다. "만약 당신의 질문이 기사의 믿을 만한 출처와 전혀 관련이 없다면, 당신은 잘못된 장소에 있는 것이다.신뢰할 수 있는 소스에 대한 정보를 보려면 여기를 클릭하십시오.신뢰할 수 있는 출처에 대한 인용문 형식 지정에 대한 질문을 보려면 여기를 클릭하십시오.신뢰할 수 있는 출처와는 전혀 상관없는 이 페이지로 진행하다가 어쨌든 신뢰할 수 있는 출처에 대해 묻는다면, 공개적으로 비웃음을 받고 다음 주 동안 사용자 페이지 상단에 수치심의 반스타를 표시하는 데 동의한다는 것을 나타내려면 여기를 클릭하십시오."

(그것은 결코 날지 않을 것이다: 그 페이지에는 친절한 편집자들이 너무 많다.)

다시 : 제발 도와줘.이 페이지들은 정기적으로 사람들이 나타나서 그들의 의견을 내놓아야 한다.하지만 가장 빈번한 질문이 무엇인지 알게 된 후에는 "지금 모든 것을 해결해서 우리가 할 수 있게" 밀어붙이는 것이 아니라 신중하게 해야 한다.WhatamIdoing (대화) 2009년 8월 24일 (UTC) 19:09 [응답]

너는 사실 그 문제를 완벽하게 설명하고 있어.'위키피디아 와이드 개선 드라이브'가 좋은 아이디어가 될 수 있는 이유는 위에서 만지고 있는 문제점을 바로잡기 위해서다.이러한 문제들이 존재하는 이유는 대체로 정책과 지침이 시간이 지나면서 발전해 온 일관되지 않고 특별하기 때문이다.여기 위키백과에서 전혀 특이한 일은 일어나지 않는다. 우리는 단지 공동체로서 우리가 예외적이지 않다는 사실을 받아들이고, 따라서 기존의 관리 및 지역사회 구축 자원으로부터 배우려고 노력할 필요가 있다.그것 말고도, 나는 개선 운동이 처음에 그것을 하는 것에 대한 설득력 있는 주장으로서 논란을 일으킬 수 있다는 사실을 발견하지 못했다.그건 그냥 경찰이야.
— Ω (토크) 02:52, 2009년 8월 25일 (UTC)[응답]

WhatamIdoing의 말에 동의함.정책이 어렵다.존경은 얻어진다.만약 당신이 엉덩이에 깊이 뛰어들어 많은 변화를 만들고 싶다면, 먼저 가라... 만약 당신이 역행한다면 사람들이 하는 말을 들을 준비를 하라.어떤 이상하게 생긴 언어는 그 곳에 이유가 있고, 어떤 언어는 해치지 않고 대체될 수 있다. - 당크 (밀어서 말하기) 03:03, 2009년 8월 25일 (UTC)[응답]

이게 내 입장에서 일종의 개인적인 십자군원정이라는 인식은 도대체 어디서 오는 것일까?나나 내 의견을 말하는 게 아니야.또한 나는 (그것이 어디서 왔을까) 존중을 말하는 것도 아니다.나는 에고 문제의 어떤 기미를 감지한다, 여기).나는 여기서 사이트 전체 행사에 대한 제안을 꺼낼 것이다. 나는 어떤 특정한 변화를 옹호하는 것이 아니다.온라인 커뮤니티에서의 오랜 개인적인 경험에 기초하여도 이것은 변하고 있다.이상해 초현실적이긴 하지만
— Ω (토크) 04:49, 2009년 8월 25일 (UTC)[응답]

• 몇 가지 의견 --

1) WhatamIdoing, 바로 그 자리에서 매우 통찰력 있는 게시물이었다.나는 지난 몇 달 동안 정책 페이지에서 (내 생각대로) 외적인 편집을 하려고 너무 많이 화상을 입었다.; 그들의 대화 페이지에서 날씨를 통제하는 힘은 도저히 헤아릴 수 없다.

2) 옴스법, 이것은 단지 인터넷이 사람들의 평을 의도한 것보다 건조해 보이게 만든 예라고 생각한다(단크가 급하게 글을 쓰고 있었다고 생각하고 싶다?) …많은 (나처럼) 이미 네가 하는 일을 존중하는 사람들이 많아; 우리는 네가 부러워하지 않을 뿐이야!

3) 가장 효과적인 방법은 "페이지 채택"이 될 것이라는 WhatamIdoing에 동의한다.WP에서 소개:위키프로젝트 정책과 가이드라인, 회원 목록에 내 이름을 추가했을 때, 나는 사람들이 스스로 모험을 하도록 장려하는 보이지 않는 텍스트가 있다는 것을 알았다; 나는 그것이 바뀌어야 한다고 생각한다.

• 이 감사하지 않은 일을 해줘서 정말 고마워...앤드류 그래드먼 _WP:Hornbook/ 2009년 8월 25일 05:23 (UTC)[응답]

나는 특정 정책을 지지하고 그것을 개선하기 위해 일하는 몇 명의 사람들과 합류할 것을 제안하는 많은 편집자들의 의견에 동의한다.그러나 WP를 위해 작은 맥락을 제공하겠다.개혁을 위한 영역.ArbCom의 개혁이 필요했기 때문에 ArbCom이 정책 위원회를 만들려는 시도가 있었다.100명에 가까운 많은 사람들이 참여한 RfC가 있었다.대부분은 개혁의 필요성이 있다는 데 동의했고, 일부는 ArbCom의 진행 방식에 동의했고, 일부는 특정한 개혁 방향에 동의했다.다른 이들은 개혁의 필요성이 있다는 데는 동의했지만 ArbCom이 추진하는 방식에는 반대했고, 다른 방향에는 반대했다.비록 RfC에서 껄끄러운 입장을 표명했지만, 위키피디아는 어떤 개혁 방향도 옹호하는 사람들이 제안을 개발할 수 있는 공간을 사용할 수 있을 것 같았다.내가 "개혁의 영역"을 만들었을 때 나는 RfC 사방의 사람들이 제기했던 구체적인 질문으로 시작해서 사람들이 새로운 질문을 추가할 수 있는 수단을 남겼다.그 이후로 그곳에서는 논의가 계속되고 있다.나는 여기에 있는 사람들을 초대해서 논의되고 있는 다른 질문들을 살펴보았다.나는 그러한 페이지의 가치에 대한 한 가지 간청으로 마무리한다(옴이 여기서 그의 행동을 볼 때: 정책을 연구하는 사람들은 위키백과에서 더 일반적인 경향과 논쟁을 분리하여 그렇게 하고 있으며 종종 그 정책과 관련된 매우 구체적인 문제에 초점을 맞추고 있다.ArbCom이 정책 위원회를 만들려고 했을 때, 나는 그들이 긴급한 문제를 해결하라는 요구에서 조금 벗어나서, 위키피디아가 어디로 가고 있는지, 무엇을 할 수 있는지, 무엇을 해야 하는지에 대한 "큰 그림"에 대해서도 생각하고 있었다고 생각한다.나는 이런 종류의 논의가 필요하다고 생각하는데, 나는 단지 그것이 독점적인 집단으로 제한되어서는 안 된다고 생각한다.위키백과가 어떻게 기능하고 있는지에 대한 "큰 그림"을 생각하고 있는 다른 편집자들이 WP에서 현재 논의되고 있는 질문들 중 어떤 것이 다음과 같은 것인지 알 수 있기를 바란다.개혁을 위한 영역들은 중요한 것을 얻는다. 만약 그렇다면, 나는 그들이 그 공간을 즉각적인 결과에 대해 걱정할 필요 없이 브레인스토밍을 할 수 있는 장소로 이용하고, 그리고 나서 새로운 정책이나 기존 정책들을 바꾸기 위한 제안들을 만들어내는 장소로 이용하기를 바란다.그러면 적절한 정책 토크 페이지로 이동될 수 있다.나는 이 과정이 새로운 아이디어를 창출하는 데 도움이 될 수 있다고 생각한다.슬루벤슈타인 토크 08:51, 2009년 8월 25일 (UTC)[응답]

위에서 언급했듯이, 나는 WP를 발견했다.Village pump(misc.)에서 시작한 후 여기로 옮기기 전(proposal) Reformation 프로젝트 페이지.나는 이것을 없애거나 그것을 단지 그것을 가리키도록 수정하는 것을 고려했지만, 나는 결국 그렇게 하는 것을 반대하기로 결정했다.나는 이것을 개혁을 위한 영역과 경쟁하기 위한 노력이 아닌, 개혁을 위한 영역을 보완하는 것으로 본다.언급했듯이, 최근 우리 정책과 가이드라인의 전반적인 상태에 대해 우려를 표하는 것은 나뿐만이 아닌 것 같다.개혁 분야도 전략적인 차원에서 착수해야 할 중요한 과제라고 생각하지만, 전술적인 차원에서 '현재 존재하는 것을 개선하기 위해 추진하자'는 일반적인 노력도 중요하다고 느낀다.위와 같은 WhatamIdoing(대화·논문)의 진술을 다시 읽어보면, 그는 표현된 "정책 채택"의 선에 근거하여 이러한 일반적인 생각에도 동의한다고 생각한다.사람들이 어떤 정책 페이지를 보고 편집하도록 하는 좀 더 격식을 차리지 말고 과감한 스타일 작업을 하는 것은 내가 보기에 도움이 되는 동시에 "위키피디아 방식"을 준수하는 것으로 보인다.나는 대부분의 정책과 지침이 그들의 어떤 식으로든 "특별하다"는 인식과 "나는 그것들을 편집할 만큼 중요하지 않다"는 느낌이 있다는 하나의 큰 이유가 있다는 이론을 가지고 있다.그것이 내가 말하고자 하는 것이다.
— Ω (토크) 09:19, 2009년 8월 25일 (UTC)[응답]

외부 링크 알림판

왜 외부 링크 게시판이 없는 거지?스몰맨12q (대화) 2009년 8월 19일 14:54 (UTC)[응답]

그런 게시판에서 무슨 일이 일어나길 바라십니까?WP:AIV는 이미 지속적인 스팸 발송자들을 다루고 있다.WP:RSN은 외부 링크와 WP에 대한 참조의 신뢰성을 다룬다.스팸은 대부분의 스팸 관련 문제를 다룬다.쿨3 (토크) 15:08, 2009년 8월 19일 (UTC)[응답]

쿨하게 동의했다.그런 게시판은 중복되어 포럼 쇼핑객들을 격려할 뿐이다.--유니온호크 15^E-mail:52, 2009년 8월 19일 (UTC)[응답]

전에도 그것에 대한 논의가 있었고, 나는 한 사람을 위해 (그들이 부적절하다고 해도 항상 스팸을 보내는 것은 아니기 때문에) 그것을 갖고 싶어할 것이다. 하지만 그것은 다시 그렇게 보이는 것처럼 격추되었다.♫ 멜로디아 샤콘네 ♫ (토크) 2009년 8월 19일 (UTC)[응답]

얼마 전에 펌프의 외부 링크 게시판에 대한 논의를 꺼냈는데, 흥미가 좀 떨어졌어.WT 보기:EL, 그 어느 때보다 절박한 요구가 있을 것 같다.그런 이사회의 승인을 어떻게 받을까?스팸이나 공공 기물 파손이 아닌 외부 링크를 다룰 때 발생하는 문제들이 많고 외부 링크는 소싱에 관한 우리의 정책에 해당되지 않기 때문에 나는 그러한 게시판이 중복된다는 것에 전적으로 반대한다.관련 문제에는 링크가 적절할 수도 있고 적절하지 않을 수도 있는 개별 사례에 대한 의견 수렴이 포함될 수 있으며, 이는 EL 가이드라인 전체와 관련이 없다(따라서 WT:EL. ThemesFromSpace 16:20, 2009년 8월 19일 (UTC)[응답]

링크 포함 여부, 어떤 링크 포함 여부에 대한 공감대를 모으는 자리가 될 것이다.스팸 발송을 제외하고...WP에 따르면 다른 모든 기물 파손 문제는 다음과 같다.EL, 링크는 최소한으로 유지해야 한다.그리고 어떤 링크가 적절하고 주제를 가장 잘 나타내는지에 대한 논쟁은 드물지만, 그것들은 발생한다.현재 토크 페이지 외에는 갈 곳이 없어 다른 사람의 의견을 얻기 어렵다.스몰맨12q (대화) 2009년 8월 19일 18:39 (UTC)[응답]

아마도 새로운 WP:콘텐츠 게시판이 이러한 문제들을 다룰 수 있을 것이다.Rd232^talk 23:04, 2009년 8월 19일 (UTC)[응답]

그것은 별로 타당해 보이지 않는다. (외부 연결은 "내용"이지만, 그들은 실제 내용에 대한 종류의 합병이다.'재판 진행'은 안 되는 겁니까?스몰맨12q (대화) 00:43, 2009년 8월 20일 (UTC)[응답]

내가 그런 판자를 세우러 간다면 어떻게 해야 할까?나는 내 사용자 공간에 초안 버전을 설정하고 그것에 대한 입력/피드백을 얻기 위해 이리저리 폴링한 다음, 아마도 그것을 메인 스페이스로 옮겨 몇 가지 토론을 해볼 생각이다.이것을 하기 위해 내가 거쳐야 할 어떤 공식적인 장애물들이 있을까?ThemFromSpace 03:38, 2009년 8월 24일 (UTC)[응답]

기본적으로 그게 다야.사용자 공간에 초안 작성...피드백을 받다.전반적인 긍정적 반응(합의)을 받는다면, 주요 기사 영역으로 가져가세요...즐겨라=D.게시판이 많이 만들어지지 않아 다소 비공식적인 과정이다.외부 링크 게시판 작성 ^.^. (위키피디아:공지사항 게시판에는 "창작" 섹션이 없으며, 아마도 한 섹션이 추가되어야 할 것이다.)건배. (초안 게시판에 링크를 포함시켜줘. 게시판을 만드는 데 도움이 되고 싶어.)스몰맨12q (대화) 2009년 8월 24일 (UTC) 14:29 [응답]

사용자:에서 초안을 설정했다.다른 몇 개의 알림판(대부분 CONE)을 기반으로 하는 스페이스/외부 링크 알림판이사회의 범위를 결정하고 관심도와 참여가능성을 측정하기 위해 피드백을 요청한다.ThemFromSpace 23:32, 2009년 8월 24일 (UTC)[응답]

왜냐하면 모든 외부 링크가 스팸이라고 생각하는 사람들로 가득할 것이기 때문이다. --Apoc2400 (대화) 15:45, 2009년 8월 26일 (UTC)[응답]

정책 및 지침에는 인용문 - 토크 페이지 보관소에 포함되어야 함

우리는 "arch"가 아카이브의 약자인 <ref group="arch">를 사용할 것이다.이러한 각주는 사용자가 자신의 기본 설정에서 볼 수 있게 하기 전까지는 기본적으로 보이지 않을 것이다.

변호사들이 법정에서 논쟁을 벌이기 전에 입법 이력과 판례를 상담하듯이, 우리의 편집자들은 (여기서 내가 한 것처럼) 정책 및 가이드라인에 대한 제안된 변경사항이 잘 합리화된 합의와 일치하는지를 검토하기 위해 자료실을 탐색한다.그러나 변호사들은 '통보되지 않은' 코드와 인용자의 장점을 가지고 있다.나는 우리 자신의 정책을 위해 그와 같은 것을 제안하고 있다.

몇 분은 처음부터 여기 계셨지만, 나는 겨우 한 살이다.나는 몇 년 전에 숙고되고 거부되었던 우리의 정책들에 대한 변화를 끊임없이 제안하고 있다.나는 이 제안이 나 같은 사람들에 의한 그릇된 생각의 동요를 줄일 수 있을 것이라고 생각한다.

PS 만약 이 제안이 이미 고려되었다가 거절되었다면... 내 주장을 뒷받침하는;) 앤드류 그랜드먼 _WP:Hornbook/ 2009년 8월 22일 (UTC)[응답]

재미있는 아이디어 같지만, 실행하기도 힘들 것 같아.그러나 나는 그것이 똑같은 낡은 토론들이 다시 올라오고 반복해서 다시 제기되는 것을 막는 데 큰 도움이 될 것이라는 데 동의한다.BTW는 WP를 통해 다음 내용을 읽어보십시오.다년제 제안? -- œ^™ 04:31, 2009년 8월 22일 (UTC)[응답]

그래, "기본값 보이지 않는 것"은 단지 추가된 프릴이었다.선택적그게 아킬레스건이라면, 그것을 제거해라...앤드루 그래드먼 _WP:Hornbook/ 2009년 8월 22일 04시 52분 (UTC)[응답]

비록 예쁘지는 않더라도 정기적인 리프는 효과가 있을 것이다. 킴 브루닝 (토크) 08:29, 2009년 8월 22일 (UTC)[응답]

불행히도 정책과 지침은 매우 지저분하게 발전해 왔다.가장 나쁜 것은 어떤 것에 대한 합의가 있는지 없는지를 규명할 수 있는 절차가 없다는 것이다 – 기본적으로 Ps&G는 편집 전쟁을 통해서 혹은 누군가가 눈치채지 못하게 몰래 어떤 것을 통해 형성된다.단지 소수의 사람들만이 주어진 페이지의 내용에 관심을 가지며, 따라서 그들의 견해는 공동체의 관점이 아니라 그 페이지에 반영된다.결과적으로 다른 페이지들은 종종 서로 모순되게 된다.그것들을 더 읽기 쉽고 이해할 수 있도록 정리하는 것 조차 종종 특정한 텍스트 부분을 불변의 경전처럼 취급하는 개인들의 저항에 부딪친다.나는 이 페이지들이 WP에서 실제로 일어나는 일에 큰 영향을 끼친다고는 생각하지 않지만(그들의 말이 의도하지 않은 것을 의미하는 것으로 해석되는 경우는 제외), 그 미안한 조건(그리고 과도한 숫자)은 분명히 새로운 기고자들을 혼란스럽게 하고 심지어 저지할 것이다.

내 비전은 위키피디아가 사람들이 그들이 필요로 하는 정보를 쉽게 찾을 수 있도록 하는 멋지고 깔끔하고 체계적인 문서를 가지고 있어야 한다는 것이다. - 프로젝트, 소프트웨어 사용 방법, 또는 WP에서 좋은 관행으로 간주되는 것 등. (이 모든 것을 도움말: 네임스페이스에 넣고 위키피디아: 과정을 위한 네임스페이스와 과정을 위한 네임스페이스를 남긴다.)토론, 그러나 그것은 세부사항이다.실제 모범 사례에 대한 의견 불일치는 RfC를 통해 해결되지만 명확한 결과(필요한 경우 이해관계가 없는 당사자들에 의한 종결)로 해결된다.그래서 본론으로 돌아가자면, 그렇다, 우리는 그것이 도움이 될 만한 곳으로서 논의와 연결고리를 가지고 있어야 한다, 그러나 그러한 논의들은 권고된 관행이 뒷받침되는 이유를 보여주는 명확한 결론을 가지고 있어야 한다.--코트니스키 (토크) 09:21, 2009년 8월 22일 (UTC)[응답]

문제는 시간이 지남에 따라 가장 관련성이 높은 페이지에 대한 아카이브가 엄청나게 커졌다는 것이다.Manual of Style, Village Pump, Reference Desk, Help Desk 및 그 하위 페이지들의 많은 기록물들은 세 자리 숫자로 되어 있다.질문이 다시 살아나거나 약간 다른 방식으로 나올 때, 그것들은 불온한 기록 보관소에 나타날 겁니다.나는 최근에 베른하르트 웨이가 영어 위키백과의 기사 제목에 대해 받아들일 수 있는 형태인지 알아보려고 할 때 이것을 접했다.검색 기능은 "Es-zett" 질문에 대한 네다섯 개의 서로 다른 기록들을 산출하는데, 이것은 주요 위키백과 토크에서 한 두 개 입니다.좀 더 전문화된 MoS 하위 페이지의 토크 페이지에 수록된 스타일 매뉴얼 및 기타 사항.아카이브 링크가 질문의 원론적 논의와 가장 최근의 논의 둘 다로 직접 데려다 줄 수 있다면 말로 표현할 수 없을 정도로 훌륭할 텐데, 어떻게 해야 할지 생각해 보기가 어렵다.—— 셰익스피어 (토크) 2009년 8월 22일 (UTC) 20:26[응답]

나의 WT 참여의 상당 부분은 추가 논평이 있거나 없는 유사한 주제에 대한 이전의 논의를 지적하는 것이다.플랫스캔 (토크) 05:03, 2009년 8월 23일 (UTC)[응답]

또 다른 문제는 정책과 지침, 에세이는 기본적으로 위키 전체에 대한 합의의 요약에 불과하기 때문에 지적할 만한 명확한 논의가 없다는 점이다.

WP를 통해 합의가 가능한지 여부 확인:사일런스, 그건 분명히 지저분해.

선거권을 박탈하는 대가로 명확성이 나올 수도 있다.

어쩌면 그 문건이 구속력이 없다는 이해와 함께 정치의 대상이 아닌 일부 외부문서에 명확한 절차가 기재될 수 있지 않을까.

그렇긴 하지만, 어떤 언급은 없는 것보다 낫다.우리는 미트볼을 언급할 수 있다: 토론, 결과, 그리고 기사들의 토크 페이지 등에서 나온 해결책, 특히 기록 보관소에서 나온 현명한 것들 등등...

--Kim Browning (대화) 2009년 8월 23일 (UTC) 00:31[응답]

다음 단계는 내 사용자 공간에서 에세이를 쓰는 것이 될 것 같다(그리고 나중에 WP에서:WP 정책에도 인용구가 필요하다), 이에 대한 이유, 그리고 이의에 대한 일부 답변이 필요하다. 그런 다음, 여러 정책/지침의 토크 페이지에서 사람들에게 그것에 대해 알리고 더 많은 피드백을 받을 것이다. (물론, 내가 그 에세이를 만들기 전까지는 여기에 계속 피드백을 넣는다.)앤드루 그래드먼^talk/_WP:Hornbook 2009년 8월 23일 (UTC) 15:21[응답]

가장 좋은 방법은 몇몇 고위층 정책에 참고 자료를 추가하는 것이다.유행할 수도 있고 아닐 수도 있다. - Peregrine Fisher (talk) (contracts) 16:22, 2009년 8월 26일 (UTC)[응답]

보이지 않게 만들 필요 없어이미 하고 있는 일인데...뭐였죠, WP:OFFICE? 하단에 약간의 ref 컨텐츠가 있다.유일한 문제는 어떤 사람들은 이것을 공감대가 바뀔 수 없다는 의미로 받아들일 수도 있지만, 그것은 다른 곳에서 가장 잘 다루어지는 문제다. M 23:18, 2009년 8월 26일 (UTC)[응답하라]

새 옵션

자동으로 페이지를 볼 수 있는 새로운 옵션이 있다면 멋질 것이다.Acdude92 (대화) (사인) 17:09, 2009년 8월 26일 (UTC)[응답]

당신의 선호도에 몇 가지 선택사항이 있다고 생각한다. - Peregrine Fisher (talks) (contracts) 17:11, 2009년 8월 26일 (UTC)[응답하라]

그래. 기본 설정의 "감시 목록" 섹션에는 이 확인란을 선택하면 편집하고 이동하고 작성한 페이지를 감시 목록에 자동으로 추가할 수 있다.~ 아모리 (사용자 • 대화 • 기여) 2009년 8월 26일 17:31, (UTC)[응답]

ITN 변경

단지 FYI, 메인 페이지의 ITN 섹션에 대한 변경 가능 여부에 대한 논의가 진행 중이라는 것.템플릿 토크:뉴스에서 #Wikinews의 사용.자유롭게 대화에 끼어들어!
— Ω (토크) 09:42, 2009년 8월 27일 (UTC)[응답]

독립 검토

위키피디아의 회원이 아닌 분야의 전문가들에 의해 피어 리뷰를 갖는다는 아이디어를 생각해 본 사람이 있는가?즉, 원예에 관한 웹사이트를 운영하는 사람들이 원예에 기반한 기사를 리뷰하도록 하는가?----occono (토크) 2009년 8월 27일 (UTC)[응답]

위키백과:외부 안전 점검?나노닉 (토크) 04:27, 2009년 8월 28일 (UTC)[응답]

그렇구나, 고마워 :)----occono (대화) 09:11, 2009년 8월 28일 (UTC)[응답]

이것은 부 편집 옵션은 불필요하다.

킬로바이트 카운터가 있기 때문에 사소한 편집 옵션을 가질 필요가 없다.만약 판본이 500 k보다 작다면, 시스템은 그것을 자동으로 m. --Janezdrilc (talk) 14:42, 2009년 8월 28일 (UTC)[reply]로 저장해야 한다.

나는 네가 사소한 편집의 의미를 오해하고 있는 것 같아.바이트 크기와는 상관이 없다.0바이트 편집은 "정규 편집"(사소한 것으로 표시해서는 안 되는 논란의 여지가 있는 변경일 수 있음)으로 간주할 수 있고, 500kb 편집은 마이너 편집(롤백 반달리즘)으로 간주할 수 있다.WP를 참조하십시오.마이너 –xeno^talk 14:47, 2009년 8월 28일 (UTC)[응답]

단락 전체를 다시 쓰면 어떨까?그것은 확실히 사소한 것은 아니지만, 단지 몇 바이트의 차이만을 초래할 수도 있다.현재 시스템이 가장 잘 작동하고 있어, IMO. Dendodge \^C 15:09, 2009년 8월 28일 (UTC)[응답]

소개 페이지에서 샌드박스 기능 제거

{{unanswered}}}

나는 위키피디아에 대해 말하고 있다:소개, 새로운 사용자를 환영하는 페이지.그 페이지는 샌드박스 기능을 가지고 있다. 다시 말해, 사용자는 인트로 템플릿이 그대로 유지되는 한 그곳에서 자유롭게 시험 편집을 할 수 있다.유감스럽게도 그렇지 않다. 그리고 새로운 편집자들은 "이러한 위키백과는 sux0rz haxd" 또는 "Get that works online www.fakesite.com"의 줄에 따라 어떤 것으로 환영 받을지도 모른다.이것은 대부분 무능하고 실제 반달리즘이 아닌 페이지의 목적을 오해하는 것이지만, 새로운 사용자가 볼 때 페이지가 보이는 것처럼 보이도록 하기 위해 이 페이지에서 샌드박스 기능을 완전히 제거할 것을 제안한다.물론 새로 온 사람들을 위한 샌드박스 페이지가 있는 것이 좋으니 현재의 샌드박스 템플릿을 위키피디아를 가리키도록 편집하는 것이 좋다.소개_2 ("편집 자세히 알아보기"라는 제목이 붙어서) 새로운 편집자는 소개의 다음 페이지를 찾을 필요가 없거나 첫 번째 소개 페이지와 두 번째 소개 페이지 사이에 새 샌드박스 페이지를 작성할 필요가 없다.지지, 의견, 제안은?코티왈로 (토크) 2009년 8월 19일 (UTC) 19:03 [응답]

나는 그러한 변화에 격렬히 반대할 것이다.내 생각에, 그들이 위키피디아에 도달했을 때 독자와 편집자 모두에게 가능한 한 격려하고 솔직하게 말하는 것은 정말 도움이 된다.WP에 대한 링크:소개는 메인 페이지에서 더 두드러져야 한다.누군가 더 많은 연결고리를 따라야 할수록, 그녀나 그는 실제로 연결고리를 따라갈 가능성이 더 적다.그래, 거기엔 공공 기물 파손이 있지만, 대부분은 실제로 사람들이 위키피디아를 구부리고 그들의 경계를 시험하는 것에 불과해.게다가, 대부분의 다른 지역들과는 달리, 그것은 실제로 누군가를 크게 해치지 않는다.샌드박스로 망치는 건 다음 남자에겐 더 안 좋아지지만 그렇다고 명예훼손이 되는 건 아니야.~ 아모리(사용자 • 대화 • 기여) 01:43, 2009년 8월 20일 (UTC)[응답]

그렇다, 샌드박스를 가지고 장난치는 것은 큰 문제가 되지 않을 것이다. 하지만 그것은 또한 우리의 소개 페이지이기도 하다. 그리고 많은 새로운 편집자들이 우연히든 의도적으로든 환영 템플릿을 지웠기 때문에, 우리의 새로운 편집자들이 불경스럽거나 특별히 환영받지 못하는 내용들로 환영받을 가능성이 크다.환영 템플릿이 실수로, 또는 불신임으로 삭제되지 않도록 하는 방법이 있다면 그 만큼은 문제가 되지 않을 것이다.코티왈로 (토크) 09:53, 2009년 8월 20일 (UTC)[응답]

12시간마다 적절한 내용으로 페이지가 새로 고쳐지도록 샌드박스 헤더와 같은 것을 추가해 보는 것은 어떨까?워리어4321 22:00 2009년 8월 20일 (UTC)[응답]

인트로 페이지에 있는 것 같은데, 템플릿이 온전하게 유지되도록 매번 편집한 후에 청소해야 하고, 그렇게 하면 샌드박스의 전체 포인트가 없어질 것이다.페이지 분리하는 게 좋을 것 같아.코티왈로 (토크) 05:41, 2009년 8월 21일 (UTC)[응답]

페이지를 분할하여 한 부분(또는 섹션)이 반보호되고 다른 부분은 12시간마다 지워지도록 할 수 있는 방법이 있는가?워리어4321 17:47, 2009년 8월 21일 (UTC)[응답]

나는 방법이 있다고 확신하지만 그것이 너무 빨리 끝나지는 않을 것이라고 확신한다.코티왈로 (토크) 2009년 8월 21일 18:23 (UTC)[응답]

다른 페이지(샌드박스 헤더와 같은)에 소개가 있는 페이지를 만든 다음, 그 페이지 안에 그것을 섞은 것을 초월하는 것이 아닐까?망사 바로 옆에 눈에 보이지 않는 댓글을 달아서 그냥 두라고?그렇게 되면 훨씬 더 많은 공간을 어디서 편집해야 할지 모르는 새로운 사용자들을 제공할 수 있을 것이다.워리어4321 19:22, 2009년 8월 21일 (UTC)[응답]

실제로 소개 페이지에는 다음이 있다.
{{이 선은 그냥 두십시오}}
<!-- 이 줄 아래의 텍스트를 얼마든지 바꿔라.불경스러운 짓은 하지 말아 주시오. -->
안타깝게도, 이것이 항상 효과가 있는 것은 아니다.코티왈로 (토크) 08:11, 2009년 8월 22일 (UTC)[응답]

(outdent)나는 최근에 소개 페이지를 보고 있어.그것이 어떻게 시작되었는지 모르지만, 나는 정기적으로 새로운 사용자들의 기여를 확인하고 불쾌하거나 미숙한 편집을 되돌린다.우리가 새로 온 사람들에게 인사하기 위해 사용하는 메시지가 일상적으로 완전히 터무니없는 것으로 파괴된다는 것이 나를 화나게 하기 시작했다.위키피디아는 케첩 방귀에 대해 읽을 곳이 아니며, 적어도 메인 페이지는 그렇지 않다.

WP 편집 페이지:소개는 WP:Sandbox 편집을 위한 페이지로 리디렉션된다.이렇게 하면 새 사용자가 방금 읽은 메시지를 무시하는 대신 소개문을 읽고, 여전히 편집을 클릭하고, 샌드박스를 편집할 수 있다.WP:그 후 도입부는 편집으로부터 보호될 수 있다. - oooʏiaɲ 14_¢:01, 2009년 8월 22일 (UTC)[응답]

나는 그 아이디어가 정말 마음에 들어! 혹시 우리가 어떻게 편집 버튼을 편집할 수 있을까?워리어4321 19:11, 2009년 8월 22일 (UTC)[응답]

그렇게 하는 게 어때?{{doc}}보호 템플릿에 대한 작업(이 경우 샌드박스를 보호된 소개 페이지로 대체하여).이렇게 하면 메시지는 그대로 유지되며, "이 페이지 편집" 탭이 제대로 작동하지 않지만, 바로 옆에 특별한 편집 링크를 가질 수 있다.아마도 Levelbot과/또는 그의 친구들이 그것을 멈추기 위해 불경스러운 행동을 하도록 샌드박스를 가볍게 순찰하게 할 것이다. --Thinboy00 @117, 즉 01:48, 2009년 8월 29일 (UTC)[응답]

바스크어 위키백과

Basque Country에서 안녕!
이것은 영어로 된 위키백과 관리자 또는 이 문제에 대해 나를 도와줄 수 있는 누군가에게 보내는 메시지 입니다.

나는 바스크어 위키백과의 사용자 겸 기고자로, 바스크어는 유럽과 세계에서 가장 오래된 언어 중 하나이며, 수천 년의 역사를 가지고 있으며, 인도-유럽인들이 유럽에 도착한 후에도 살아남은 몇 안 되는 언어 중 하나이다.아마도 세계에서 가장 오래된 국가나 국가 중 하나가 되는 것은 그들만의 국가도 없겠지만, 우리의 언어는 우리의 조국과 자부심이다.그것은 우리를 지도에 올려놓았고, 국제적으로 유명한 산 페르민 축제를 기념하는 바스크의 국가인 팜플로나(바스크어로 이루냐)라는 영어 사용자들에게 인식 가능한 참고자료를 주었다.

이 간단한 소개가 끝난 후, 나는 당신에게 다음과 같은 요청을 하고 싶다.

2009년 7월 15일 바스크어 위키백과에서 우리는 4만 개의 항목 수를 초과했고, 오늘날(2009년 8월 8일) 4만 2천 개의 항목을 가지고 있는데, 그 성과는 바스크어 사용자 수(약 100만 명)를 한 개 이상의 주 또는 국가에서 다른 구어 위키백과와 비례적으로 비교한다면 매우 자랑스럽다.수백만의 연사와 함께 하는 것은 자랑스러워하는 것과 같다.

왜냐하면 위키피디아의 목표 중 하나는 전세계적으로 인간의 지식을 확장하는 것 외에 인류의 모든 언어에 대한 지식을 확장하는 것이기도 하기 때문이다.바스크어 위키백과에서 우리는 사용자들에게 그리고 특히 영어 위키백과 관리자에게 요청하기를 원했다. 만약 당신이 당신의 주요 표지에 있는 모든 사람들의 영어 위키백과 언어 목록에 바스크어 위키백과 링크를 넣으면 ("언어" 섹션: 현재 사례 갈리시아어 또는 카탈로니아어)와 위키백과어 위키백과가 가능하다.당신의 메인 입구 페이지 아래에 있는 40,000개 이상의 항목 목록("위키피디아 언어" 섹션)영어는 현재 세계에서 가장 강력하고 영향력이 있으며 널리 퍼져있기 때문에(당신의 위키백과에는 이미 300만개의 기사가 실려있기 때문에, 바스크 위키백과가 당신의 세계 목록에 있는 것은 우리 언어와 그들의 지식을 세계에 감독하는데 큰 도움이 될 것이다.

답장 기다리고 있어.

바스크어 위키백과의 인사말.
. --Euskalduna(텔미) 15:05, 2009년 8월 26일 (UTC)

템플릿을 참조하십시오.메인 페이지Interwikis —TheDJ (대화 • 기여) 2009년 8월 26일 (UTC) 16:33[응답]

바스크어 위키백과는 위키백과의 목록에 언급되어 있으며, 바스크어 위키백과의 기사에서 상당한 입력을 사용한 영어 위키백과의 기사에서 언급될 수 있다.ACEOREVIVEED (토크) 21:26, 2009년 8월 26일 (UTC)[응답]

당신의 글을 다시 읽으면서, 나는 당신이 바스크 위키백과가 메인 페이지에서 언급되기를 원한다는 것을 이해한다. 이 페이지 하단에 위키백과가 존재하는 위키백과 이외의 언어 목록이 있다.나는 당신이 그곳에 있는 위키백과 관리자에게 연락하는 것이 좋다고 생각한다. 그들은 메인 페이지의 제안된 변경에 도움을 줄 수 있을 것이다.ACEOREVIVEED (토크) 2009년 8월 28일 (UTC) 19:47 [응답]

I WANT TO POST

저명한 아티스트인 아론 버크먼에 대한 정보를 게시하고 싶은데 이미지 외에도 정보를 게시하는 방법을 알려주시겠습니까?고마워, 제넷 헨들러 —제넷 헨들러가 추가한 서명되지 않은 논평 준비 (대화 • 기여)

Caps Lock을 입력하지 마십시오.위키피디아에서 이와 같은 도움을 요청하십시오.헬프 데스크.고마워.--------occono (대화) 2009년 8월 23일 (UTC) 17:51, [응답]

그곳에 가면 다음과 같은 충고를 받을 가능성이 높다.위키피디아를 위해 기사를 쓰는 것은 많은 사람들이 인식하는 것보다 어렵다.심지어 전문 작가들도 좋은 백과사전 기사에 필요한 형식과 스타일이 다른 장소에 적합한 것과 다르다는 것을 발견한다.다음 작업을 수행할 수 있음:

• 다른 사람에게 그것을 하도록 해—만약 당신의 유일한 목표가 위키피디아에 기사가 추가되도록 하는 것이라면, 당신은 누군가에게 그 주제에 대한 기사를 쓰도록 요청할 수 있다.
• 다른 기사 편집부터 시작 -위키백과에서 편집자가 되고 싶다면, 우리의 경험은 기존의 기사를 개선하는 것부터 시작하는 것이 더 낫다는 것을 보여주는데, 이것은 여러분이 이 곳이 어떻게 돌아가는지 이해하는 데 도움이 될 것이고, 그러면 여러분은 첫 번째 기사를 처음부터 쓸 준비가 될 것이다.방문하기에 좋은 장소는 위키백과 백로그인데, 그곳에는 말 그대로 편집자들의 도움을 필요로 하는 수십만 개의 기사가 있다.알고 있는 주제 영역에서 기사를 찾아 출처나 참고자료를 추가하거나 단순히 더 잘 쓰도록 도와준다.
• 계속하여 시도하십시오. 만약 즉시 기사를 쓰기로 결정했다면 이해 충돌에 대한 당사의 정책을 읽어보십시오. 그런 다음 위의 몇 가지 좋은 조언을 반복할 수 있는 첫 번째 기사 작성 가이드를 읽어 보십시오.그런 다음 문서 마법사를 사용하여 단계를 진행하십시오.사용자 하위 페이지에 첫 번째 초안을 저장하는 옵션을 수락하십시오. 이 옵션을 사용하면 작업이 준비되기 전에 삭제될 가능성이 줄어듭니다.

--SPHILbrickT 18:15, 2009년 8월 23일 (UTC)[응답]

흠, 그 템플릿은 기여자들에게 얼마나 고무적인가.Rich Farmbrough, 04:14, 2009년 8월 30일 (UTC)[답답하다]

그래, 최근 상승세가 있는 것 같은데...부정성?근래에여름의 끝인가?몰라.
— V = I * R (Ω과 대화) 04:32, 2009년 8월 30일 (UTC)[응답]

@Jeanette, 여기를 클릭: Aaron Berkman을 편집하고 내용을 추가하기 시작한다.
— V = I * R (Ω과 대화) 04:32, 2009년 8월 30일 (UTC)[응답]

위키백과 포럼

나는 위키피디아를 위한 포럼이 있어야 한다고 생각한다.Acdude92 (대화) (사인) 2009년 8월 27일 (UTC) 14:14 (응답)

나는 위키피디아가 백과사전이고 우리는 포럼이 필요하지 않다고 생각한다. 현재의 토론 페이지는 충분하다.코티왈로 (토크) 2009년 8월 27일 14:17 (UTC)[응답]

나는 문제를 일으키는 사람이기 때문에 코티왈로와 포럼에 대한 유사한 질문이 제기될 때마다 같은 내용을 바로 말하는 다른 많은 사용자들에게 대답하고 싶다- 만약 토론/대화 페이지(사용자든 기사든)가 당신이 말하는 것처럼 충분했다면 우리는 결코 빌리지 펌프나 위키피디아 주체가 필요하지 않았을 것이다.포럼은 비슷한 관심사를 가진 사람들이 서로를 찾고, 유용한 팁과 출처와 정보를 교환할 수 있는 또 하나의 유용한 도구일 뿐이다.나는 내가 작업하는 기사를 보고 그들에게서 "이봐, 내가 이 출처를 찾은 x 기사를 작업하는 것이 네가 작업하고 있는 기사에 도움이 될 것 같아"라는 말을 즐겨 듣는 "친구"가 있다는 것을 알고 있다.위키피디아는 가족이고, 우리가 항상 동의하는 것은 아닐지 모르지만, 우리는 결국 모두 좋은 뜻을 가지고 있고, 이 곳을 더 나은 곳으로 만들기 위해 공동의 목표를 위해 함께 일하고 싶어한다.새로운 친구를 사귀기 위한 포럼이 몇몇 편집자의 기고를 향상시킬 수 있다면, 그것은 유용한 도구다.이러한 포럼이 주의를 산만하게 하거나 개인의 기여도를 증가시키지 않는 경우에만, 나는 포럼/액정 스레드를 소셜 네트워킹 사이트로만 사용하고 편집은 전혀 하지 않는 사람들에게 좌절하거나 차단할 것을 권고하고 싶다.이 사이트를 소셜 네트워킹 사이트로 사용하면 차단될 수 있다.아마도 그것은 그들의 시행에 동의하지 않는 몇몇 사람들을 만족시킬 것이다.코티왈로처럼 "이것은 백과사전이고 포럼은 위키피디아의 것이 아니다"라고 말하고 싶은 사람들은 포럼에 참여할 필요는 없지만, 그들은 물러서서 목소리를 내는 방식으로 반사회적인 행동을 중단할 필요가 있다.반사회적이지만 조용히 해라.카멜빈키 (대화) 01:12, 2009년 8월 30일 (UTC)[응답]

그러나 위키피디아를 오프사이트에서 토론하는 포럼이 있다.음, 2009년 8월 27일 14:18 (UTC)[응답하라]

일반적인 토론을 위한 웹 포럼이 좋겠지만 지금은 없다.메일링 리스트가 있다. --Apoc2400 (대화) 17:15, 2009년 8월 27일 (UTC)[응답]

정말?워리어4321 17:41, 2009년 8월 27일 (UTC)[응답]

예전에는 있었는데 지금은 다운된 것 같아처음 생방송될 때 자주 들렀지만 결국 발길을 끊었다.그냥 다시 해 봤는데 아무 것도 없어.무슨 일이 일어났는지 확실하지 않다.아마도 많은 사람들도 결국 가지 않게 되었을 것이다.£N마jdan•talk 17:42, 2009년 8월 27일 (UTC)[응답]

공식적인 것은 없지만 그들은 존재한다.hmwitht 01:24, 2009년 8월 28일 (UTC)[응답하라]

놀랍게도, 위키피디아 반대 게시판도 있다.£N마jdan•토크 02:00 (UTC)

액체 나사산이...결국 (그리고 개인적으로, 나는 기다릴 수 없어!)그것은 여기서 표현되고 있는 기본적인 우려를 다루어야 한다.
— V = I * R (토크) 04:16, 2009년 8월 28일 (UTC)[응답]

위키백과 검토는 상당히 활발하다.추티아 (대화) 2009년 8월 28일 (UTC) 11시 59분 [응답]

그것은 내가 언급했던 것에 대한 것이다.:) hmwitht 00:01, 2009년 8월 30일 (UTC)[응답]

어원 및/또는 대명사의 납 파라 내 접을 수 있는 범위

나는 어원학에 대해 아는 것을 정말 좋아하지만, 그들은 많은 기사에서 주요 단락을 매끄럽게 읽는 것을 방해할 수 있다.나는 이것들이 일정 길이를 초과했을 때 접을 수 있는 범위(이것은 약간의 기술적 구현이 필요할 것 같다.

베이징(北京, /beɪdʒɪŋ/또는 /beɪʒʒɪ// 영어로 발음); 중국어: 北京; pinyin:Běijngng, IPA: [péɪ (] (듣기); Wade-Giles: Pei3ching1 또는 Pei3-ching1) (/piɪk (/ (듣기) 또는 /peeɪkɪ/라고도 함)은 중국 북부에 있는 대도시로 중화인민공화국의 수도다.

그래서 약간 닮은 것으로 대체될 것이다.

베이징(北京) [논어·어원]은 중국 북부의 대도시로 중화인민공화국의 수도다.

클릭했을 때 전자로 확장.접을 수 있는 칸과 마찬가지로, 이러한 칸은 항상 볼 수 있기를 원하는 사용자를 위해 사용자 정의 CSS-ed가 될 수 있다.단점은 스팬 내부의 텍스트가 읽히고, 확장되고, 체크되는 경우가 적을 수 있다는 점일 것이고, 기사를 보고 나서 주로 그런 경우 또 다른 클릭일 것이다.OED 웹사이트는 발음과 어원을 기본적으로 숨기는 비슷한 일을 한다.Phyomonas 13_(talk):48, 2009년 8월 25일 (UTC)[응답]

나는 이 제안이 마음에 든다.그 대명사는 때때로 너무 길어서 앞부분을 읽기가 매우 귀찮아질 수 있다.원하는 경우 대명사를 여는 옵션이 훨씬 좋아 보인다.워리어4321 16:57, 2009년 8월 25일 (UTC)[응답]

나도 동의해...우리가 사용할 수 있는 템플릿을 개발하는 것은 어떨까? 어떤 것은{{Lead sentence Beijing pron-en beɪˈdʒɪŋ IPA-en beɪˈʒɪŋ (etc...)}}
— Ω (토크) 18:22, 2009년 8월 25일 (UTC)[응답]

나는 지금 이런 종류의 템플릿을 만드는 것에 그다지 익숙하지 않다.템플릿 요청 등의 장소가 있는가?하나도 못 찾았어.Warrior4321 18:54, 2009년 8월 25일 (UTC)[응답]

이것에 대해 너무 멀리 가기 전에, 기사의 주요 부분에 접을 수 있는 요소들에 대한 합의가 있을 수 있다.
재빨리 뒤져 보았지만, 한 번은 큰 테이블을 쓰러뜨리는 것을 생각하고 경고하고 있었다.기사 하단에 있는 붕괴된 탐색 템플릿은 특별히 면제되었다, IIRC.
너무 많은 어원으로 기사의 시작을 어수선하게 하는 것에 대한 우려를 공유한다. --S필브릭T 22:03, 2009년 8월 25일 (UTC)[응답]

다음의 지침: MOS:SC롤--SPHILbrickT 22:09, 2009년 8월 25일 (UTC)[응답하라]

나는 이러한 목적을 위해 특별히 선두에 접을 수 있는 스팬을 사용하는 특정한 면제는, 그것이 정말로 필요하다면 달성할 수 있다고 생각한다.단지 여기 있는 우리 중에, 그것을 어떻게 실행해야 하는지에 대한 의문이 있지만, 모든 사람들이 그것이 좋은 생각이라는 것에 동의하는 것 같다.분명히, 이 토론에는 지금까지 4명 밖에 참여하지 않았지만, 나는 의무적인 반대 의견을 덧붙이지 않은 토론은 광범위한 합의를 달성할 수 있다는 것을 분명히 암시한다고 생각한다.
— Ω (토크) 22:11, 2009년 8월 25일 (UTC)[응답]

나한테 기대지 마.어쨌든 베이징의 예는 무엇이 잘못되었는가?NVO (대화) 22:13, 2009년 8월 25일 (UTC)[응답]

(언젠트) 이전의 질문에 답하기 위해 위키피디아는 다음과 같다.요청된 템플릿은 새 템플릿에 대한 도움을 요청하는 곳이다.그리고, 그 가치에 대해서는, 발음과 어원에 관심이 없는 일반 독자들에게 도움이 되는, 그런 템플릿을 지지하고 싶다. -- 존 브레본 (리듬) 22:20, 2009년 8월 25일 (UTC)[응답]

사물을 앞설 위험을 무릅쓰고, 나는 새로운 템플릿으로 발음 및 어원 부분을 지나치게 표준화하고 싶지 않다. 단지 너무 긴 경우에 임의의 텍스트 블록을 깔끔하게 접는다.Phyomonas 00_(talk):07, 2009년 8월 26일 (UTC)[응답]

나는 이 생각을 많이 좋아하지만, 반드시 원어는 반드시 번역을 하는 것은 아니지만, 붕괴의 바깥에 포함시켜야 한다.하지만 아카데믹한 발음안내서와 정교한 언어노트는 숨기는 게 좋을 것 같아. --골베즈 (토크) 22:35, 2009년 8월 25일 (UTC)[응답]

나는 본래의 언어가 일반적으로 그 단어에 대한 세부사항이라기보다는 그 단어에 대한 세부사항이며, 특히 그 답이 흔히 중영어를 경유하여 노르만 불어를 경유하여 라틴어를 경유하는 그리스어일 경우에는 그 컷 아래에 속한다고 생각한다.하지만 예외는 있다는 것을 인정하겠다; 항상 있다.Phyomonas 23_(talk):57, 2009년 8월 25일 (UTC)[응답]

나는 접근성에 대한 MOS:SC롤의 요점을 이해한다.현재 접을 수 있는 스팬은 불가능하다; 나는 이것이 관리자에 의해 변경 가능한지 아니면 니즈 데브에 의해 변경 가능한지 모르겠다.나는 이 제안이 지역사회에서 인기가 있다면 스크린리더 등에 대해 더 잘 아는 사람들이 그것을 실행하는 데 불쾌한 방법이 있는지 결정해야 한다고 생각한다.Phyomonas 23_(talk):57, 2009년 8월 25일 (UTC)[응답]

모스:스크롤은 백과사전을 개선할 필요가 명백하다면 쉽게 우회할 수 있다.위에서 말했듯이, 필요하다면 우리는 이것에 대한 추가적인 예외를 쉽게 개척할 수 있다.발음과 어원은 포함하기에 좋은 정보지만, 그 정보들이 (보통) 주제를 이해하는 데 중심이 되지 않기 때문에, 이 (때로는 지나치게 긴) 정보를 접는 템플릿이 완벽하게 적절해 보인다.이에 대한 상당한 지원이 있는 것 같기 때문에 적어도 임무를 완수하기 위해 템플릿을 만드는 것은 분명한 다음 단계인 것 같다.구체적인 실행이 이 문제에 대한 움직임을 촉진할 것이다.
— Ω (토크) 00:27, 2009년 8월 26일 (UTC)[응답]

훌륭해. 여기 누가 템플릿 좀 만들 수 있어?워리어4321 05:04, 2009년 8월 26일 (UTC)[응답]

그럴 수 있을 것 같긴 한데, 시간을 좀 찾아야겠어.위키피디아에 메모 남기기:요청된 템플릿이 있으면 다른 사람이 사용할 수 있을 겁니다.
— Ω (토크) 05:15, 2009년 8월 26일 (UTC)[응답]

IRC에서 물어볼게.워리어4321 15:31, 2009년 8월 26일 (UTC)[응답]

그 스팬이 디폴트로 볼 수 있고 그 다음에 자바스크립트로 숨겨져 있는 시스템이 접근성 &c의 문제를 피할 수 있을지 궁금하다.아니면 어차피 다른 접을 수 있는 일이 그렇게 되어 있는 것일까?Phyomonas 22_(talk):21, 2009년 8월 30일 (UTC)[응답]

CC 배지?

페이지 하단에 크리에이티브 커먼즈 배지가 없는 이유가 있는가?옛날에 GFDL 배지가 있었던 기억이 나는 것 같아. --사이버코브라 (토크) 11:04, 2009년 8월 26일 (UTC)[응답]

아마존닷컴은 이 이미지들이 충분히 자유롭지 못할 수도 있다고 제안한다. 그들은 다소 상표권이다.나는 이것이 공용 면허증을 의미할 수 있다고 생각한다.범주:크리에이티브_Commons_icons는 다소 수정될 필요가 있다.Phyomonas 12_(talk):08, 2009년 8월 26일 (UTC)[응답]

나는 Wikinews가 그들 중 한 명을 발판에 올려놓고 있다는 것을 알아차렸기 때문에 그것을 꺼낸다: [1] --Cybercobra(토크) 12:24, 2009년 8월 26일 (UTC)[응답]

흠, 좋아. 본문 주위에 있는 것들에 대한 기준이 뭔지 모르겠어.AFAIK는 위키피디아 로고가 상표로 되어있기 때문에 아마 괜찮다.Phyomonas 12_(talk):52, 2009년 8월 26일 (UTC)[응답]

Wikinews는 다음과 같은 인터페이스 메시지 n:MediaWiki를 사용한다.저작권, 이 버튼을 추가하기 위해.나는 우리가 적어도 CC 라이선스 마이크로포맷 중 하나를 추가해야 한다는 것에 동의한다.—DJ (대화 • 기여) 2009년 8월 26일 (UTC) 16:36[응답]

그래, 구글 검색 필터링은 무료로 사용할 수 있는 결과만 있으면 위키피디아는 제외되기 때문에, 적어도 CC 메타데이터 같은 것이 필요해서 검색에 무료로 사용할 수 있도록 플래그를 표시해야 한다.--Unionhawk^TalkE-mail 16:45, 2009년 8월 26일 (UTC)[응답]

(Off topic, 그리고 순전히 개인적인 관심의 문제) Google 검색 필터링은 어떻게 무료로 사용할 수 있는 결과만 필터링할 수 있는가?그것은 매우 유용하겠지만, 나는 그 기능을 제공하는 구글 기능을 찾을 수 없었다.Dendodge \^C 16:56, 2009년 8월 26일 (UTC)[응답]

(iii)advanced search'에는 "날짜, 사용권, 숫자 범위 등"이라는 링크가 있다.클릭하면 적절한 라이센스를 선택할 수 있는 드롭다운 상자가 나타난다.크리에이티브 커먼즈(Creative Commons)에서만 작동하는 것 같아.-유니온호크(UTC) 2009년^E-mail 8월 26일 (답)

마이크로포맷 예제에서 첫 번째 시도

나는 다음과 같은 것이 어떻게 보일 수 있는지에 대한 예비 예를 만들었다.

이미지를 사용하든 사용하지 않든 간에, 정확한 문구와 형식은 여전히 꽤 많은 논의를 필요로 한다.우린 그걸 오해하고 싶지 않을 거야.—DJ (대화 • 기여) 17:08, 2009년 8월 26일 (UTC)[응답]

테스트 위키에는 데모가 보인다.Vector/Beta를 사용할 때만 점잖게 보인다는 점에 유의하십시오. Monobook에서는 하나의 큰 혼란입니다(NOWN 라이센스 페이지와 크리에이티브 커먼즈 버전에 대한 라이센스 링크가 두 개 있는데, 이는 검색 엔진에 픽업되도록 하기 위함입니다.—DJ (대화 • 기여) 2009년 8월 26일 (UTC) 17:41, 26 (응답)

멋지다! 이렇게 줄 바꿈을 꽂으면 모노북이 더 잘 어울릴 것 같다: "추가 용어가 적용될 수도 있다.<br/> 보시오."버튼이 쌓이는 것을 좋아하는지는 모르겠지만 벡터에서는 이미 괜찮아 보인다는 것에 동의한다. --사이버코브라(토크) 23:17, 2009년 8월 26일 (UTC)[응답]

페이지별 내용은 포함이 되긴 하는데, 이렇게 하면 우선 도마나 브리온에 확인을 해봐야겠다.필요하다면 메타데이터를 제거할 수 있어기본적으로 "검색 가능한 탐지"의 유일한 중요한 부분은 이 링크를 렐=라이센스로 갖는 것이다.우리는 현재 우리만의 링크를 가지고 있지만, CC 링크를 숨겨서 둘 다 가져야 할 것 같다.—DJ (대화 • 기여) 2009년 8월 27일 (UTC) 00:09[응답]

내가 여기서 제안하는 것처럼 최소한 마이크로포맷을 추가해야 한다고 생각한다: MediaWiki_talk:Wikimedia-copyright —TheDJ (대화 • 기여) 00:47, 2009년 8월 27일 (UTC)[응답]

도마에 물어봤는데, 이런 바닥글에는 페이지별 기능을 사용하지 말자.—DJ (대화 • 기여) 2009년 8월 27일 (UTC) 17:42, [응답]

내 생각엔 버그리포트를 열어서 RDFA의 핵심을 만들 수 있을 것 같은데, 그것은 훨씬 덜 비쌀 것이다.면허 마이크로포맷은 전혀 문제가 되지 않아야 한다. 배지는 실제로 훨씬 더 많은 커뮤니티의 입력을 필요로 하는 것이다.—DJ (대화 • 기여) 2009년 8월 27일 18:30 (UTC)[응답]

솔직히 말해서, 나는 배지에 더 집중했다; 나는 네가 그 얘기를 꺼내기 전에는 RDF 태그에 대해 몰랐다.태깅은 여전히 훌륭한 아이디어지만--사이버코브라 (토크) 20:39, 2009년 8월 27일 (UTC)[응답]

이미지 배지

자, 이제 마이크로포맷이 추가되었으니, 이미지 배지의 원래 질문에 대한 사람들의 생각은?가능성: [2], [3], [4] --Cybercobra (대화) 05:31, 2009년 8월 30일 (UTC)[응답]

나는 이것에 반대한다. 그것은 전혀 이유가 없다.우리는 그래픽 정보에만 그래픽을 사용해야 한다.단지 시각적 오염일 뿐이다.—Noisalt (대화) 2009년 8월 31일 01:00 (UTC)[응답]

질의 : 그렇다면 왜 우리는 "Powered by MediaWiki"와 "A Wiki Media 프로젝트" 배지를 가지고 있는가? --사이버코브라(토크) 01:12, 2009년 8월 31일 (UTC)[응답]

네가 말해봐.나는 그들에 대해 정확히 같은 의견을 가지고 있다.—Noisalt (대화) 01:47, 2009년 8월 31일 (UTC)[응답]

정책변경제안

위키피디아가 공개되기 전에 변경 사항을 승인하기 위해 편집자를 선택한 기사에 사용하기로 결정한 것에 대한 CNN 기사에 대한 답변으로 이 글을 올린다.위키피디아가 공개되기 전에 페이지의 변경 승인을 받아야 하는 선택된 기사에 대해 "커뮤니티 기반 편집 승인" 제도를 제정할 것을 제안하고 싶다.수정사항은 영향을 미치기 전에 사용자에 의해 투표로 결정된다.이러한 방식으로 사용자가 기사를 변경할 때 해당 글의 메인 페이지에 바로 표시되지 않는다.대신 기사 편집 페이지에 로그인해 검토를 하고 일정 시간 안에 일정 양의 부정표를 받으면 편집이 취소되고 기사 변경은 안 된다.이것은 공공 기물 파손을 방지하고 나쁜 변화가 일어나는 것을 막는 좋은 방법이 될 것이다. 74.131.111.224 (대화) 23:19, 2009년 8월 27일 (UTC)[응답]

위키피디아의 요지는 다음과 같다.플래그 수정. -- Taku (토크) 21:02, 2009년 8월 29일 (UTC)[응답]

투표는 결코 효과가 없을 것이다. 대부분의 기사들은 충분한 교통량을 얻지 못한다.Mr.Z-man 21:11, 2009년 8월 29일 (UTC)[응답]

독자가 특정 버전에 대해 어떻게 평가하여 투표하도록 하는 것은 이치에 맞는다.즉, 가장 많은 표를 가진 기사가 눈에 보이는 기사가 될 것이다.(이것이 위에서 제안된 것이 아니라는 것을 알고 있다.) -- 타쿠 (토크) 21:37, 2009년 8월 29일 (UTC)[응답]

그런 투표를 일반 대중에게 공개하면 콘텐츠 조작이 가능하다.당신이 친위대 멤버라고 하면, 당신 편을 들어주기 위해 기사를 기울일 수 있고, 다른 모든 그룹 멤버들에게 그 개정안에 대해 투표할 것을 요청할 수 있기 때문에, 그것이 되돌아가더라도, 그것은 여전히 가장 인기 있는 버전이 될 것이다.투표는 일반 국민이 하기 때문에 책임질 일이 없다.2009년 8월 31일 Mr.Z-man 01:57 (UTC)[응답]

기록에서 봇 숨기기

역사 페이지에 봇 숨기기 버튼이 있었으면 좋겠다.역사 페이지마다 봇 편집량이 너무 많아서 다른 "진짜" 편집 내용을 확인하기가 정말 짜증난다. --Janezdrilc (talk) 14:42, 2009년 8월 28일 (UTC)[응답]

나는 이것이 상황을 매우 혼란스럽게 만들 것이고 아마도 우아하게 실행될 수 없을 것이라고 생각한다.–xeno^talk 14:49, 2009년 8월 28일 (UTC)[응답]

제노가 말했듯이, 이것은 너무 혼란스러워질 것이다.봇 편집은 다른 사용자의 편집과 병합되어 비봇 사용자에게 잘못 귀속될 수 있다.사용자가 봇의 편집 내용을 되돌리면 어떻게 하시겠습니까?그러면 아무것도 변하지 않는 역사 항목이 나올 겁니다.–Drilnoth (T • C • L) 15:10, 2009년 8월 28일 (UTC)[응답]

역사에서 봇 편집은 <tr>의 수업을 통해 그렇게 표시되는가?그렇다면 편집 내용을 숨길 수 있는 가젯/자바스크립트를 개발하는 것이 가능할 것이라고 추측할 용의가 있다(아니, 나는 직접 확인하지 않았다).예를 들어, 사소한 편집도 숨기려고 할 경우.이상적으로는 링크/버튼으로 켜고 끌 수 있을 것이다. --Izno (토크) 17:11, 2009년 8월 28일 (UTC)[응답]

문제는 역사 페이지에 그것들을 숨기는 어려움에서 오는 것이 아니라, 페이지에서 항목을 삭제함으로써 야기될 혼란스러운 차이에서 오는 것이다.2009년 8월 28일 (UTC) 17시 19분 미스터 지맨[응답]

(없음) 그러한 기기는 기록 목록의 항목만 숨길 뿐 편집 자체는 숨길 수 없다.그래서 만약 원래의 역사가 이렇게 생겼다면:

• (cur)(prev) 0:10 1월, 2000년 1월 1일 사용자:예(foo)
• (cur)(prev) 0:05 2000년 1월 1일 사용자:예제봇(막대)
• (cur)(prev) 2000년 1월 1일 0:00 1일 사용자:예제2(바즈)

등

그렇다면 "잘린 역사"는 다음과 같을 것이다.

• (cur)(prev) 0:10 1월, 2000년 1월 1일 사용자:예(foo)
• (cur)(prev) 2000년 1월 1일 0:00 1일 사용자:예제2(바즈)

등

그러나 첫 번째 "prev" 링크를 클릭하면 (가젯 부분에 대한 주요한 구조조정이 없다고 가정하면) 0:00과 0:10의 편집이 아닌 0:05와 0:10의 편집 사이에 차이가 나타나며, 이전 버전의 작성자는 사용자:예제봇(즉, 모든 것이 "그냥 작동"할 수 있음).기기가 어떻게든 0:00과 0:10 사이의 차이를 나타내도록 설계되었다면, 사용자가 원래의 기록의 라디오 버튼을 통해 이 차이를 선택한 것처럼 보일 것이다(간헐적 편집 등에 관한 메시지와 함께 완성).그러나 이것은 훨씬 더 복잡한 장치를 수반할 것이다.한마디로 미디어위키 소프트웨어는 멍청하지 않고 위에서 언급한 것과 같은 모순된 일을 당신에게 경고하지 않고 하지 않을 것이다.--Thinboy00 @144, 즉 02:27, 2009년 8월 29일 (UTC)[응답]

난 봇 편집하는 거 보는 거 좋아하는데...그렇다, 대부분의 경우 그들은 무시될 수 있다. 하지만 때때로 봇은 지나치게 편집해야 하는 편집을 할 것이다.봇이 하는 일을 점검해, 그들의 변화가 특정 기사에 적합한지 확인하는 것이 중요하다.블루보어 (토크) 2009년 8월 29일 16:51 (UTC)[응답]

나는 단순히 "그들을 괴롭히는" 것이 의도된 기능이라고 확신해, 씽보이. 그리고 나는 실제로 그 기능이 유용하다고 생각해.「diff」버튼을 더 사용하기 어렵게 만들지만(「봇 편집 포함」과 같은 기능이 구현되지 않는 한), 방해는 안 된다. --Izno (토크) 18:22, 2009년 8월 29일 (UTC)[응답]

여기 한가지 해결책이 있다.이 옵션을 [환경설정] -> 가젯 -> 사용자 인터페이스 가젯에 넣으십시오.따라서 이 옵션을 선택하면 봇이 나열되어야 하는 표시/숨기기 버튼이 포함될 수 있는 모든 기록 페이지를 선택할 수 있다.미리 보기나 실행을 취소하려면 표시를 클릭하기만 하면 된다.그게 다야. --Janezdrilc (대화) 22:42, 2009년 8월 30일 (UTC)[응답]

아하, 내 이유를 설명해야겠어.문제는 소규모 위키피디아가 역사목록(인터위키스)에 봇을 연재하고 있는 반면, en: 또는 de:아마도 그 문제를 그렇게 엄격하게 알지 못할 것이다. --Janezdrilc (대화) 22:46, 2009년 8월 30일 (UTC)[응답]

내 일 좀 봐?

내가 생각하고 있는 것이 이미 존재하고 있을 가능성이 있고 단순히 그것을 모르고 있을 뿐이지만, 최근에는 어느 정도 '사지로 나간다'는 느낌이 드는 상황들을 마주하고 있다.그냥 뭔가를 남기고 싶지 않은 기분도 알고 있고, 방금 한 변화에도 별로 마음이 편치 않은 그런 기분도 알고 있지?이 문제를 다루는 피드백 시스템에 대한 논의가 있었는가?가장 먼저 떠오르는 것은 일종의 템플릿이다.{{체크미}}}이나...뭔가가 있어
— V = I * R (Ω과 대화) 07:13, 2009년 8월 30일 (UTC)[응답]

{{}}}}}. --사이버코브라(토크) 07:20, 2009년 8월 30일 (UTC)[응답]

아니... 내 말은, 템플릿(또는 비슷한 템플릿의 전체 범위)은 어떻게든 리팩터링될 수 있을 것 같아.내가 생각하고 있던 것은 좀더 즉각적이고 일시적인 것이다.예를 들어, "좋아, 분명히 틀렸어/잘못됐어/필요해서 바꾸려고 하는데, 내 변화가 정확히 맞는지 잘 모르겠어. 그러니 내 일을 좀 확인해 줄래?" 기본적으로..."마지막으로 변경한 내용을 확인해야 한다"는 메시지가 포함된 메시지 상자이 템플릿을 선택한 후 제거하십시오."그런 거.
— V = I * R (Ω과 대화) 07:33, 2009년 8월 30일 (UTC)[응답]

제안:X개월 내에 편집하지 않을 경우 250바이트 미만의 스텁 기사를 자동 삭제하도록 봇 보유

Per WP:REDLINK 및 WP:스텁, 나는 한두 문장의 기사를 만드는 것과 개선되지 않은 마이크로 스텁이 무한정 존재할 수 있도록 하는 것 사이에 균형이 있어야 한다고 생각한다.나의 견해는 레드 링크는 확장하기 위한 그루터기만큼이나 연구와 기사 작성에 대한 동기부여가 되지만, 최소한의 그루터기는 백과사전의 인상을 심각한 기업으로서 떨어뜨린다는 것이다.내가 아는 바로는 많은 편집자들이 자리 표시자의 한 종류로서 아주 짧은 스텁을 만들고 나서 그 스텁을 확장하기 시작한다는 것이다. 그리고 나서 나는 그들을 기사 지위에 올려놓기 위해 그들이 혹은 다른 사람들에게 작업할 수 있는 넉넉한 용돈이 있어야 한다고 생각한다.
Per WP:Stub Wikipedia는 디렉토리가 아니며 한 두 문장 페이지가 그러한 정의에 속하지 않을 것이라고 주장하기는 어려울 것이다. 장소 이름을 제외하고; "X"는 Y 도/국가 Z의 작은 마을이다. 그리고 논의는 도태에서 면제될 수 있는 특정한 스터브 유형을 제안할 수 있다.또한 특히 생성 후 시간에 따른 스터브 팽창 가능성에 대한 분석을 제공할 수 있는 사람들의 입력에 있어 시간 프레임에 관한 제안이 도움이 될 수 있다.
댓글 기대하고 있어.LessEverned vanU (talk) 2009년 8월 21일 (UTC) 14:01, 응답하라

나는 당신이 제안한 면제에 반대한다: 내 생각에는 고아들을 거쳐 자동으로 삭제한 봇은 특별히 위키백과를 지도책으로 바꾸려는 노력을 목표로 삼아야 한다.야크허딩 마을이 생긴 이래 봇들이 편집만 해놓은 외딴 야크허딩 마을에 대한 봇 제작 스텁이 완벽한 삭제 대상이다.만약 누군가가 그러한 스터브들의 지리적 좌표를 바탕으로 자동적으로 "소안소에서의 정착 목록"을 만들어 내는 좀 더 맞춤화된 봇을 쓰고 싶다면, 나는 그것을 완전히 삭제하는 대안으로 반대하지 않을 것이다.—Kww(대화) 14:06, 2009년 8월 21일 (UTC)[응답]

이것은 사람들이 스텁을 만들기 위해 봇(스크립트)을 사용하는 것과 같은 문제를 가지고 있다. 즉, 어떤 일이 일어나고 있는지에 대한 인간의 감시는 없다.250바이트는 합리적으로 들릴지 모르지만 임의적인 컷오프(tut off off)이며, 불행히도 컷오프(cut off off)는 다소 임의적인 컷오프일 것이다.삭제 중인 콘텐츠를 삭제해야 한다는 것을 확인할 방법이 없다.데이터 추가를 장려하기 위해 데이터를 삭제한다는 생각은 나에게 다소 낙후된 생각이라는 인상을 준다.이 정도 크기의 개별 하위 스텁은 대부분 삭제하는 것을 (아마도) 지지한다고 해도 무방하지만, 스스로 일을 하기 위해 봇을 느슨하게 만드는 것은 불편하다.2009년 8월 21일 14시 8분 (UTC)[응답]

적어도 사람이 보기 전에는 기사를 삭제해서는 안 된다.기사가 짧고 자주 편집되지 않는 것은 삭제 기준이 아니다.칠음 14:09, 2009년 8월 21일 (UTC)[응답]

뷰 카운터 파라미터에 추가하시겠습니까?나는 250바이트(그러나 경험에 근거한 분산이 가능함)를 디렉토리 타입 스터브 이상일 것 같지 않은 정말 작은 사이즈로 제안하고 있지만, 만약 그것이 정기적으로 보여지고 있다면, 가치의 증거가 있다.지금까지의 코멘트에 대한 일반적인 대응으로, 삭제는 판단이나 영구적인 것이 아니다. 삭제되어야 할 것이 제거된다면, 그것은 다시 만들어질 것이고 더 나은 것을 바랄 것이다.LessEverned vanU (talk) 2009년 8월 21일 (UTC) 14:28 (talk)[응답]

수많은 "변수들"을 이용해 봇이 계속할 수 있도록 할 수 있을 것 같다.편집하지 않은 편집이 1개 이상 있었는가?조회수 X개야?X 이후 편집은 안 돼?봇만 편집?X바이트만?인바운드 링크?이것들 중 많은 것들이 내 걱정을 덜어주는데 도움이 되겠지만, 나에게 가장 큰 걸림돌은 이 모든 것이 봇에 의해 운영된다는 것이다.나는 봇이 기사 작성이나 삭제에 관여하는 것에 대해 극도로 망설인다. 왜냐하면 궁극적으로 포함 기준은 기계가 아닌 인간에 의해서만 판단될 수 있기 때문이다.CSD와 같은 "삭제할 수 있는 스텁" 범주에 봇이 배치되는 것을 볼 수 있었는데, 실제 인간들이 그것을 삭제해야 하는지에 대한 최종 결정을 내릴 수 있었지만, 우리는 엄청난 양의 작업을 만들고 있다.2009년 8월 21일 14시 35분 (UTC)[응답]

삭제 전 기사 작성자에게 2주간의 통지를 추가하면, 좋은 것 같다(이것은 옵트아웃으로 잘 광고되도록 하라-몇몇 봇 작업에서 동일한 메시지 1000을 보고 싶어하지 않을 것 같다).--MASEM (t) 14:10, 2009년 8월 21일 (UTC)[응답]

셰레스라면 반대하겠소임의 컷오프는 나쁘다.예를 들면 다음과 같다.

[[파일:존 스미스.jpg 엄지손가락 존 스미스] ''존 스미스''는 16세기 영국 작가였다.그는 [[Collection1]을 포함한 여러 시집의 시를 썼지만, 주로 [그의 유명한 희극]으로 유명하다.{{author-proper-properties}}}

247바이트에 불과하지만, 그것은 이미지를 포함하고, 다른 관련 기사에 대한 링크, 그리고 주요 배경 정보를 포함하고 있다.그러나 잘 채워진 인포박스와 스텁 태그만으로 구성된 기사를 쓸 수 있고, 250바이트를 훨씬 넘도록 할 수 있었다.어떤 기사가 편집 없이 몇 달씩 진행된다면, 나는 잘 다듬어진 전체 기사가 곧 나올 것 같지는 않고, 그것을 막는 유일한 것은 그루터기뿐이라고 생각한다.내 추측으로는 우리는 결국 몇 달 혹은 몇 년 동안 레드 링크로 연결될 것이고, 우리가 할 수 있는 작은 정보를 제공하는 것보다, 우리는 아무것도 제공하지 않을 것이다.2009년 8월 21일 (UTC) 14시 33분 미스터 지맨[응답]

• 아마도 누군가가 우리에게 LHvU의 제안된 네트에 의해 잡힐 기사들의 몇몇 예를 제공하기 위해 데이터-젠더들을 할 수 있을까?–xeno^talk 14:36, 2009년 8월 21일 (UTC)[응답]

• 나는 이것에 반대할 것이다.키가 작고 안정적이라는 것은 어떤 종류의 삭제 기준이 아니다.던컨힐 (토크) 2009년 8월 21일 (UTC) 14:48 [응답]

• 왜 봇은 지우기보다 모든 기사들을 자극하지 않는가?물론 이렇게 하면 한꺼번에 엄청난 뒷북이 생길 수 있기 때문에 아마도 제한적인 속도로, 또는 그런 식으로 운영될 수 있을 것이다.Cool3 (토크) 2009년 8월 21일 14:57 (UTC)[응답]

나도 그 생각을 했고, 밀린 일 때문에 걱정했었어 - 나는 보고봇을 단속할 생각은 안 했어.2009년 8월 21일 셰어 15:01 (UTC)[응답]

• 반대한다. 우리는 백과사전을 끝낼 시간표가 아니다.스텁이 눈에 띄면 관심 있는 편집자가 함께 와서 기사를 개선해야 하는 만큼 스텁이 남아 있을 수 있다.백과사전의 현재 "완벽함"으로 스터브가 발달하려면 점점 더 오랜 시간이 걸릴 것이지만, 그렇다고 그것들을 삭제할 이유는 없다.Duncan Hill의 코멘트를 참조하십시오.—DJ (대화 • 기여) 2009년 8월 21일 (UTC) 15:04[응답]

  나는 그러한 봇이 인간 검토를 위해 카테고리에 기사를 추가하는 것을 지지할 것이다.칠음 15:07, 2009년 8월 21일 (UTC)[응답]

• 주요 의문은 주제가 WP:N & friends를 통과하더라도 어떤 종류의 하위 ub도 삭제하자는 공감대가 있는가 하는 것이다.만약 그렇다면, 어떤 종류의?나는 특히 우리가 이미 "바 리스트" 기사를 가지고 있다면, "푸는 술집이다" 타입의 변전소들이 모두 사라지는 것을 보는 것을 꺼리지 않을 것이다.
  My biggest problem with stubs is when they are so short that they have to be considered wrong, which can usually only happen with (quasi-)bot-created stubs (e.g. Philipp von Bismarck, Otto Fürst von Bismarck (CDU), Karl-Heinz Daehre, Mario Czaja, Karl Eduard Claussen, Christine Clauß, Paul de Chapeaurouge, Rudolf Böhmler, which all omit the most de그 사람들의 가장 중요한 점들).WP의 현재 제안서:새로 생성된 스텁에 대해 덜 자주 발생해야 하는 VPP.개선이나 삭제를 위해 그러한 범주에 속하는 기존의 모든 하위 ubs를 어떻게 식별하는가에 대한 의문이 남는다.기본적으로 나는 그들이 항상 사람의 눈을 필요로 할 것이라고 생각하지만, 세노가 말했듯이, 어떤 필터에 의해서 생성되는 시험적인 하위 ubs의 선택이 계몽이 될 것이다.아말테아 15:36, 2009년 8월 21일 (UTC)[응답]
• 네, 사이즈는 삭제 기준이 아니에요.영구히 짧은 기사의 가장 좋은 처리는 그것을 병합하여 위키리거 등으로 옮기는 것일지도 모르지만, 이것들은 인간을 위한 작전이다.비록 봇이 사람들이 유용하다고 생각하는 어떤 기준에 근거하여 기사 목록을 생성하는 것에 해를 끼치지는 않지만(그러나 물론 실제 기사에 태그나 카테고리를 추가할 필요는 없다 - 불필요하게 변경 목록을 범람시킬 뿐이다.)---코트니스키 (토크) 2009년 8월 21일 (UTC)[응답]
• 나는 또한 이 제안에 동의하지 않는다. 이 제안은 내용물이 있는 곳에서만 이것과 같은 기사를 잡을 수 있는 잠재력을 가지고 있을 것이다. 그러나 그것은 단지 템플릿으로 기사를 실제 크기보다 더 짧게 만들 것이다.기사가 적당한 시간 내에 편집되기 때문에 괜찮다는 것을 알지만 다른 비슷한 기사들도 잡힐 것 같아 걱정이다.보다 기본적으로 나는 매우 짧은 기사는 누구나 확장할 수 있는 반면, 새로운 기사는 등록된 사용자만이 만들 수 있기 때문에 그 전제에는 동의하지 않는다.기사가 신속한 기준을 충족하지 못할 정도로 충분한 맥락을 가지고 있고 확장될 가능성이 있는 경우에는 삭제되거나 존재하지 않는 것으로 병합되어서는 안 된다.어떤 검증된 정보는 정보가 없는 것보다 낫다.데이브윌드 (대화) 2009년 8월 21일 18:53 (UTC)[응답]
  • 글쎄, 난 마지막 부분이 사실이라고 생각하지 않아.내가 전에 언급한 바울 드 샤파우루주를 예로 들어보자.우리가 그에게 가지고 있는 유일한 검증 가능한 (검증되지 않은) 정보는 그가 "CDU의 대표자"라는 것 뿐인데, 그것은 기본적으로 그의 전기의 각주이고, 그는 70세 때 그들과 합류했고, 그가 다른 당의 창립 멤버였던 모든 시간 동안이다.리스트에서 생성되는 이와 같은 하위 ubs는 중요한 부분을 생략하는 경우가 많지만, 고점을 제시한 것처럼 보이게 한다.우리가 가지고 있는 유일한 검증 가능한 정보는 어쨌든 리스트를 통해서 검색에 나타났을 것이기 때문에, 여기에 기사가 없는 것이 더 나을 것이다.아말테아 19:41, 2009년 8월 21일 (UTC)[응답]
    • 당신이 제기한 경우에 그 기사를 가지는 것은 좋은 목적을 가지고 있다. 그것은 그 글의 확장에 사용될 수 있는 독일어 위키백과 기사에 대한 쉬운 링크를 제공해주기 때문이다. 그것은 리스트에서 오는 것보다 링크가 있는 지금 일어날 가능성이 더 높다.그 기사의 편집자는 물론 독자를 다른 언어로 된 보다 실질적인 기사를 향해 가리키는 것은 나쁜 일이 아니다.그것은 또한 500바이트가 넘기 때문에 어쨌든 이 제안서에 거의 도달하지 못할 것이다. 그래서 나는 이 제안이 지지자들이 원하는 목표를 달성할지 의문이다.데이브윌드 (대화) 2009년 8월 21일 19:57 (UTC)[응답]
      • 그 기준은 물론 유동적인 상태에 있다.:)
        나는 우리의 전형적인 독자들이 인터위키 링크를 알아차릴지 확신할 수 없다. 그리고 다시 말하지만, 이 하위탑은 그 사람에 대한 잘못된 그림을 전달한다.만약 독자가 그의 가장 주목할 만한 특징이 기사에 실린 내용이라는 인상을 가지고 떠난다면, 우리는 그에게 폐를 끼친 것이다.물론, 사빈 크리스천 같은 경우도 있는데, 인터위키 링크가 완전히 가짜라고 확신해.아말테아 20:22, 2009년 8월 21일 (UTC)[응답]
• 반대 그 단조로운 글의 나이는 관련이 없다.언젠가는 더 좋은 것으로 발전할 수도 있을 것이다.그리고 위키피디아에 적합한 주제를 다루기 위한 짧은 글자도 아예 없는 것보다는 낫다. 드림 포커스 2009년 8월 21일 (UTC) 19:48 [응답]
  • 음, 내가 방금 위에서 제시한 (랜덤!) 예시를 참고하도록 하겠다.아말테아 19:52, 2009년 8월 21일 (UTC)[응답]
    • 그것은 내가 위에서 지적한 바와 같이 어쨌든 이 제안에도 해당되지 않을 것이다.데이브윌드 (대화) 2009년 8월 21일 19시 59분 (UTC)[응답]
• 이미 언급된 이유로 반대한다.--큐브 루머 (토크) 20:01, 2009년 8월 21일 (UTC)[응답]
• 아무도 빨간 고리에 의해 더 격려받지 못하기 때문에 반대하라.반대로 절대적으로 처음부터 기사를 시작하는 것은 비전문적 편집자가 위키백과(뉴 페이지 순찰)의 삭제주의자를 이미 통과한 기사를 편집하는 것보다 더 벅찬 작업이다.여기에 더해 이들 기사를 삭제해도 얻는 것이 없다.정보의 손실만 있을 뿐이다.누군가가 이 정보가 무관하다는 것을 주관적으로 마음속에 가지고 있다고 해서 그것이 무관하다는 뜻은 아니다. - -oooo 15 15_¢:10, 2009년 8월 22일 (UTC)[응답]
• 단조로운 것을 갖는 것에 반대하는 것이 아예 없는 것보다 낫고, 그림의 절반을 갖는 것이 사람이 누구인지 전혀 모르는 것보다 낫다.정보/그림/인터위키 링크가 잘못되었다면, 그것은 기사가 스터브인 것과 아무 상관이 없다.틀린 것은 고쳐야 한다.음, 2009년 8월 23일 14:37 (UTC)[응답]
• 반대하라 종이 백과사전을 보면 250자보다 짧은 많은 기사들을 발견할 수 있을 것이다.스텁은 괜찮다.가끔 나는 단지 무언가가 무엇인지 알고 싶을 뿐이야.나는 또한 레드링크가 확장될 가능성이 더 높다는 전제에 의문을 제기한다.스텁은 IP 사용자의 확장을 허용한다. --Apoc2400 (대화) 15:41, 2009년 8월 26일 (UTC)[응답]
  • 아치우스가 좋은 예다.그것은 300바이트지만, 그것은 많은 마크업 때문이다.존 반덴버그 2009년 9월 1일 12시 57분 (UTC)[응답하라]

검토용 스터브와 가능한 프로딩/삭제/머거 등을 봇 목록에 포함시키십시오.

WP가 WP를 촉발한다고 해도 "무(無)보다 나은 것이 있다"는 감정은 큰 것으로 보인다.NOTDIR, 따라서 아마도 초기 실행 봇은 이러한 스텁을 나열하고 태스크포스가 실제 정크푸드를 통과하여 제거할 수 있는 것이 가장 좋을 것이다( 일단 봇에 태그가 지정되면 삭제되지 않은 스텁은 화이트리스트가 된다).이후의 봇 런은 그 기준에 따라 기사를 PROD할 수 있으며, 다시 한번 육혈 운영자가 결정을 내릴 수 있도록 허용한다.나는 이것이 "백과사전을 완성"하려는 것이 아니라, 더 이상 표준에 맞지 않는 내용들을 제거하기 위한 것이라고 언급하고 싶다 - 마치 몇몇 오래된 FA들이 지위를 잃는 것처럼 - 그리고 프로젝트의 전반적인 질을 향상시키기 위한 것이다.물론 나는 그러한 검토기구에 우선 가입할 것이다.LessEnard vanU (대화) 2009년 8월 21일 (UTC) 20:11 [응답]

^^^ 이것의 첫 부분은 "Just do it" 해결책이며, 아무도 누군가가 그런 목록을 작성하는 것을 막을 수 없다.나는 MZMcBride에게 매우 도움이 되는 것을 제안하고 싶다. 그는 이런 종류의 일에 아주 능숙하다.WT에서 물어보면:DBR. –xeno^talk 20:14, 2009년 8월 21일 (UTC)[응답]

이것은 대단히 좋은 생각인 것 같다.최근 양국 관계 기사(한 무리의 사람들이 모두 잡동사니를 제거하기 위해 그 목록을 훑어보았다)와 막연히 비슷한 일이 벌어졌는데, 대부분의 사람들에게는 상당히 좋은 결과인 것 같았다.아마도 이 과정을 수행하는 데 도움이 되는 일종의 프로젝트/그룹/태스크포스/등등을 구성하는 것도 나쁘지 않을 것이며, 물론 시간이 지남에 따라 새로운 기사들이 리스트에 진입할 것이기 때문에 스탠딩 그룹이 될 수도 있기 때문이다.쿨3 (토크) 2009년 8월 21일 20:29 (UTC)[응답]

우리는 이미 스텁(stub)을 표시하여, {{stub}}개의 템플릿을 사용해 검토한다.문제는 채점 부족이 아니라 수만 건의 기사를 검토하는 자원 봉사 시간이 부족하다는 것이다.— 칼 (CBM · talk) 2009년 8월 21일 (UTC) 20:32[응답]

이 도구는 이러한 노력에 도움이 될 수 있다. -- œ^™ 04:28, 2009년 8월 22일 (UTC)[응답]

• 나는 12개월 동안 편집되지 않은 250바이트 이하의 기사 목록, 도구: ~mzmcbrid/lesswear.txt - 1500개 이상이 있다.간단한 리뷰는 "List of"와 같은 몇몇 사람들이 유용할 가능성이 있다는 것을 나타낸다. 그러나 제목에서 밑줄("_")을 사용하는 숫자는 그것이 검색 항목으로 발견될 가능성이 낮다는 것을 나타낸다. 즉, 주제에 대한 다른 더 좋은 제목의 기사가 있을 수도 있다.BLP 심사의 후보자들 또한 명백하다.난 봇 리스트도 있고 드라마 게시판에서 침을 흘리는 것도 아닌데...리뷰/프로듀싱/디렉팅/리디렉션/머그링에 펀트를 하고 싶은 사람은 누구나 환영한다.만약 커플 이상이 있다면 우리는 작은 프로젝트를 조직해야 할지도 모른다.LessEverned vanU (talk) 2009년 8월 22일 16:45 (UTC)[응답]
  • 밑줄과 공간은 등가: Life_Will_Be_Death_of_Me = Life Will Be the Death of Me. Amalthea 17:10, 2009년 8월 22일 (UTC)[응답]

**이러한 기사들 중 일부를 확장하려고 노력하게 되어 기쁘다.위키피디아로 목록을 옮기는 것이 좋을 것이다. 위키피디아에는 조치를 취하거나 목록의 모호한 페이지와 같이 짧게 유지하기에 적절한 항목에 대해 메모를 할 수 있다.Davewild (대화) 2009년 8월 22일 18:01, (UTC)[답글]

• • • 목록이 사용자:에 이미 wiki에 있는 것으로 확인됨:LessEneward vanU/mini 스텁.Davewild (대화) 2009년 8월 22일 18:23 (UTC)[답글]
      • 나는 무자비하게 굴고 있다. 그래서 만약 누군가가 레드링크를 보고 그것을 작은 글이나 좋은 스텁으로 바꿀 수 있는 충분한 정보를 찾을 수 있다고 생각한다면 나에게 알려주면 나는 완전히 지울 것이다.LesEverned vanU (talk) 2009년 8월 22일 19:26 (UTC)[응답]
        • 왜 완전히 의견 일치를 거스르는 겁니까?실패하지 않는 한 삭제하지 않는 게 어때?여기서 프로딩은 무의미하다. 왜냐하면 아주 적은 수의 사람들만이 그 짧은 손목시계를 가지고 있을 것이기 때문이다.또한 밑줄이 있는 제목은 공백이 있는 제목이므로 검색에서 쉽게 찾을 수 있다.나는 네가 그것을 알지 못하지만 백과사전에 맞지 않는 기사들을 결정하면서 돌아다니는 것이 불안하다고 생각한다.- 2009년 8월 23일 (UTC) 15_¢:33, 응답

한 번 보면 LessEnvard가 이미 이 목록에서 다소 형편없는 빠른 삭제를 수행하고 있다는 것을 알 수 있다.낮은 볼륨에서의 높은 실패율은 볼륨을 높이기 위해 봇을 도입하는 것이 나쁜 생각이라는 좋은 지표다.크리스토퍼 파럼(토크) 2009년 8월 26일 15시 30분 (UTC)[응답하라]

삭제는 현재 여기에 있다.Rich Farmbrough, 04:13, 2009년 8월 30일 (UTC)[답답하다]

날짜 매개 변수

나는 {{Asbox}}에 날짜 파라미터를 포함시켰는데, 사물이 스텁(stub)으로 얼마나 오래 남아 있는지 알아보는 것이 유용하다고 생각될 경우에 대비해서, 아마도 그것들을 트리밍(triage)할 것이다.그것은 스코프 크리프로서 제거되었다.그러나 그것이 덜 뭉치는 결과를 가져온다면, 좋은 방법으로, 그것은 다시 넣을 수 있다.Rich Farmbrough, 04:03, 2009년 8월 30일 (UTC)[답답하다]

일반 회화 페이지?

이제 위키피디아가 "대화"를 위한 장소가 아니라는 것을 알지만, 나는 단지 대화를 위한 페이지와 모든 편집자와 다른 회원들을 알기 위한 페이지가 있으면 좋을 것이라고 생각한다.지금으로선 모두가 뱃멀미를 하고 있다.나는 또한 irc가 있다는 것을 알지만, 모든 사람이 irc를 사용할 수 있는 것은 아니다.Accdude92 (토크) (사인) 2009년 8월 25일 (UTC) 14:19, 25 (응답)

위키피디아는 소셜네트워크 사이트가 아니다.우리는 백과사전을 만들러 왔다.그러나 협업은 권장된다.편집자의 대화 페이지에 있는 편집자에게 연락해 보십시오.음, 2009년 8월 25일 17:30 (UTC)[응답하라]

• mw:LiquidThreads는 언제 그리고 언제 그것이 배치되었는지에 대해 도움을 주어야 한다(개발에 대한 자세한 내용은 Andrew Garrett의 블로그 참조).현재의 토크 페이지 시스템의 엉성함은 위키피디아가 현재 옹호하고 있는 오랜 기간 제도화된 반사회적인 행동을 부추기는 요인이다(위의 답변에 나타난 바와 같다).나는 네가 무슨 말을 하는지 정확히 알고 있고, 개인적으로도 정서에 동의하지만, 기술적인 제약이 해결될 때까지는 어떤 것도 크게 변하지 않을 것이다.
  — Ω (토크) 18:34, 2009년 8월 25일 (UTC)[응답]
• 재미로, 당신은 WP에 있는 사람들과 항상 대화를 나눌 수 있다.샌드박스.WP가 소셜 네트워킹이나 포럼이 아닌 동안, 나는 가끔 사소한 덜 스트림이 적은 대화가 분위기에 큰 도움이 될 것이라고 느낀다.일반적으로 내가 유머러스한 일을 하려고 할 때 사람들은 나를 여기서 그냥 놀리는데, 그건 부끄러운 일이다.그것을 치료하고 사람들에게 숨쉴 공간을 주는 것은 분명 멋질 것이다.반격당해도 괜찮지만, 괜찮은 새 편집장들을 쫓아낼 수 있을 거야.그렉 타일러 2009년 8월 25일 (UTC) 20:58[응답]

나는 우리가 일반적인 "대화방"이 필요하다는 것에 동의하지만, 단지 사람들이 있는 곳에서 다른 AOL/Yahoo!/Myspace/Facebook을 만드는 대신에 비슷한 관심사를 가진 편집자들을 찾고 사람들과 협력하는 것을 위해 그것을 보관할 수도 있다.사람들이 종종 비슷한 주제 안에서 기사 작업을 하고 있고 서로에 대해 전혀 알지 못하며 상대방이 찾고 있었을지도 모르는 통찰력과 정보를 가지고 있을지도 모르기 때문에, "이봐, 내가 작업해 온 거야, 누구라도 비슷한 관심사를 가지고 있는 사람?"이라고 말할 수 있는 일반적인 대화 포럼이 있다면 좋을 것이다.또한 갑자기 많은 사람들이 그들이 더 잘 짜고 조직하고 싶은 많은 기사들을 가지고 있다는 것을 깨닫기 때문에 잠재적인 위키백과 주제가 형성될 수 있는 좋은 장소다.위에서 대답한 것과 같은 반사회적인 사람들이 다른 사람들을 알고 싶어하지 않는다면 그것은 그들의 선택이지만, 그들은 위키백과의 나머지 부분에 그들의 개인적인 신념을 강요할 수는 없다.카멜빈키 (토크) 22:21, 2009년 8월 25일 (UTC)[응답]

대량 편집 충돌을 야기하지 않을까?워리어4321 22:26, 2009년 8월 25일 (UTC)[응답]

형편없이 설계되었을 때만.만약 당신이 정말로 걱정한다면, 당신은 Werdna (대화 · 기여)와 함께 당신의 우려를 제기할 수 있을 것이다, 왜냐하면 그는 현재 LiquidThreads의 개발을 이끌고 있기 때문이다.22:41, 2009년 8월 25일 (UTC)[응답]

IRC는 사회적으로 상호작용하는 가장 좋은 방법이다(일반적으로, 인터넷에서도, 내 생각에는).나는 왜 누군가가 IRC를 사용할 수 없을지 잘 모르겠다. 어떤 튜토리얼로 쉽게 배울 수 있고, 연결 문제가 있으면 언제든지 애플릿을 사용할 수 있다. -- 멘티피스토 15:17, 2009년 8월 26일 (UTC)[응답]

나는 IRC에 대한 정서에 동의하지만, 심지어 공식적인 위키백과 IRC 채널은 실제로 위키백과에 있지 않다.대부분의 사람들은 다양한 이유로 "오프사이트"를 사용하지 않을 것이다.
— V = I * R (Ω과 대화) 03:50, 2009년 8월 30일 (UTC)[응답]

사실, IRC는 오프사이트에 있어야 하지만, 위키피디아는 그것을 지원하고 있고, 대화할 수 있는 많은 것을 가지고 있다.Webchat.freenode.net은 또한 쉽게 접근할 수 있게 해준다.위키피디아에 대해 채팅하고 싶다면 IRC를 가볼 수 있는 곳으로 지원하겠다.게다가, 그것을 현장에 보관하는 것은 서버들이 많은 무의미한 스팸성 대화들을 보유해야 한다는 것을 의미할 것이다.거기에도 그런 귀중한 정보가 있을 때 그것은 낭비처럼 보인다.그레그 타일러^{(t • c)} 16:34, 2009년 8월 31일 (UTC)[응답하라]

그러나 IRC의 다른 문제는 채팅이라는 것이다.개인적으로, 난 그냥 채팅을 좋아하지 않아...서버 로드 질문에 대해서는, 그건 정말 신경 쓸 일이 아니다.
— V = I * R (Ω과 대화) 13:37, 2009년 9월 1일 (UTC)[응답]

토크노티체

때때로 우리는 중요한 지역사회 발표가 있지만, 그것들을 광고할 수 있는 최적의 방법은 없다.우리는 워치리스트 공지사항을 사용할 수 있지만 IP는 볼 수 없고 로그인한 사용자들은 항상 워치리스트를 자주 확인하지 않기 때문에 그다지 효율적이지 않다.또한 모든 페이지의 모든 사용자가 메시지를 볼 수 있도록 하는 시트노티스가 있다.그러나 일부 발표는 모든 독자를 위한 것이 아니거나 시테노티스에 올릴 만큼 중요하지는 않기 때문에, 우리는 시테노티스와 같이 작업하고 오직 토크 페이지에만 표시되는 토크 노티스를 사용할 수 있고, 또한 거절할 수 있다.그런 것이 바람직하다는 데 동의하면 개발자들에게 요청할 겁니다.세나리움 (대화) 2009년 8월 26일 00:26 (UTC)[응답]

나는 이 제안에 찬성한다; 다가오는 개정판 재판의 마지막에 무엇을 할 것인가의 결정은 (다른 곳에서 세나리움 노트처럼) 감시자들이 충분한 사용자에게는 도달하지 못하지만 시테노티스가 너무 많은 그러한 발표중의 하나이다.-레이조스 (대화) 2009년 8월 30일 (UTC)

좋은 생각이야. - Peregrine Fisher (talk) (contracts) 21:24, 2009년 8월 31일 (UTC)[응답]

네임스페이스 확인 코드를 시테노티스에 넣으면 안 될까?뭐랄까{{#ifeq:{{NAMESPACE}} {{TALKSPACE}} ...}}해야 하는가?— 디스펜서 21:38, 2009년 8월 31일 (UTC)[응답]

나는 테스트위키를 시도했는데 시테노티스가 그것을 처리할 수 없었다. 만약 당신이 체크코드를 입력한다면, 미디어위키: 페이지에 파싱된 것처럼 보일 것이다.시테노티스 그 자체.성능상의 이유로 그런 것 같아.세나리움 (대화) 2009년 8월 31일 (UTC) 22:51, 응답하라

만약 우리가 지금 그것이 필요하다면 우리는 CSS나 JS를 사용하여 기사에 숨길 수 있다.— 디스펜서 07:07, 2009년 9월 1일 (UTC)[응답]

나는 이것을 요청하여 T22458을 채웠다.세나륨 (대화) 00:22, 2009년 9월 1일 (UTC)[응답]

난 이 아이디어가 너무 좋아.나는 모든 보조 네임스페이스에 공지사항이 표시되고, 아마도 편집하는 동안 더 잘 될 것이라고 생각한다.그렇게 하면, 그저 평범한 독자가 아닌 누구나 그것을 보게 될 것이다.— Jake Bartenberg 04:14, 2009년 9월 1일 (UTC)[응답]

Wikia는 이미 이 기능을 개발했기 때문에 좋은 출발점이 될 수 있다. 여기에서는 https://wikia-code.com/wikia/trunk/extensions/wikia/SiteWideMessages/ ...을 이용할 수 있다. 특별한 페이지를 통해 당신은 사용자 토크 페이지에 나타나는 무시 가능한 메시지를 보낼 수 있다.사용자 대화 페이지에 있기 때문에 새로운 메시지 알림을 트리거하므로 사용자는 해당 메시지가 존재한다는 것을 알 수 있다.사용자 그룹(예: 관리자), 개별 사용자 또는 모든 사용자만 대상으로 할 수 있다.필요하다면 메시지를 보낸 후 철회할 수도 있다.메시지에는 특정 날짜/시간이 지나면 저절로 사라지도록 만료 날짜가 있을 수 있으며, 이벤트 후 1개월이 지나면 아무도 신경 쓰지 않는 유지보수 알림 등에 유용하다.또한 사용자 대화 페이지, 빈 사용자 대화 페이지, 차이프 등을 처리한다.이것은 우리가 이메일 주소가 없는 사람들과 집단적으로 의사소통을 할 수 있게 해주었기 때문에 특히 유용한 연장선이었다.무시해도 되는 부분이 사용자들에게 어필하게 만든 것이다.Jqsjqs (대화) 22:50, 2009년 10월 16일 (UTC) 더 여기: http://help.wikia.com/wiki/Help:Talk_Page_Messaging Jqsjqs (대화) 00:06, 2009년 10월 17일 (UTC)[응답]

목차

Maglev(운송)을 확인하십시오.그것의 목차는 본문의 나머지 부분 위가 아니라 본문 바로 옆에 있는 오른쪽에 떠 있다.TOC를 통과하기 위해 스크롤하고 스크롤하고 스크롤하고 스크롤해야 하는 것이 귀찮은 것은 나뿐만이 아닐 것이다.아마도 모든 기사의 "Maglev (운송)"에서 발견되는 방법을, 또는 적어도 모든 긴 기사의 방법을 사용하면 위키피디아가 전반적으로 더 유용하게 사용될 수 있을 것이다.목차가 있는 이중 곱슬 브래킷에 TOCright 또는 TOC만 있으면 된다.-(사용자:스타트랙 마니아 (토크) 2009년 8월 27일 (UTC) 23:21[응답]

TOC의 맨 아래로 이동하려면 목차에서 첫 번째 "항목"을 클릭하십시오.TOC 바닥까지 직진하며, 스크롤이 필요 없는 Warrior4321 00:35, 2009년 8월 28일 (UTC)[응답]

기사 오른쪽 상단에 인포박스나 그림(Maglev 기사에 TOC가 나타나는 곳)이 많이 포함되어 있기 때문에 모든 기사에서 효과가 있는 것은 아니다.{{}}{{{}}}를 배치하여 우측에 목차를 표시하도록 개별 물품을 변경할 수 있다.페이지의 TOCright} 템플릿
— V = I * R (토크) 04:25, 2009년 8월 28일 (UTC)[응답]

그것은 작은 스크린을 위한 형편없는 시스템이다.섹션 1의 (편집) 링크는 TOC의 상단에 걸려 있는 반면 섹션 1은 실제로 TOC 아래에서 시작한다.NotAnIP83:149:66:11 (대화)10:00, 2009년 8월 31일 (UTC)[응답]

"Wipedia 검색"을 위한 더 나은 동사

나는 매일 "Donno, 그것을 위키피디아에서 확인하라" 또는 " 심지어 위키피디아에서 구글 검색하라"라고 말하거나 듣는다.위키피디아에 대해 더 나은 동사가 만들어져야 한다.만약 그렇다면, 그것은 무엇인가? 단지 이상한 생각일 뿐이지만, 이것은 먼 길을 갈 수 있기 때문에 나는 글을 올린다. --Qquidonius (토크) 11:31, 2009년 8월 24일 (UTC)[응답]

나는 '모르겠어, 네가 위키피디아에게 물어봐'에서처럼 가끔 '와이피디아에게 물어봐'를 사용한다.개인적으로 나는 '구글 it'과 같은 어색한 신조어를 좋아하는 사람이 아니기 때문에 만약 당신이 새로운 동사를 동사로 한다면, 나는 그것을 채택하는데 서두르지 않을 것이다.Mike1024 (t/c) 12:29, 2009년 8월 24일 (UTC)[응답]

"위쿠글"!Dendodge \^C 12:50, 2009년 8월 24일 (UTC)[응답]

(ec) "Wikipedia 확인" 또는 다른 변형이라고만 말하십시오."구글"을 동사로 사용하면서 엔진의 거의 고유함으로부터 발전했고, 그 독특하고 짧은 이름(위키피디아처럼 5음절이 아닌 2음절)이 되었다.만약 그들이 처음부터 "구글"을 동사로 만들기 위해 노력했다면, 그것은 효과가 없었을 것이다 - 이런 것들은 자연스럽게 일어날 필요가 있다.동사로서 사용하는 용어는 사실 회사에 좋지 않은데, 그 용어가 일상 어휘에서 더 흔해질수록 그들의 상표권이 희석되어 쉽게 그 지위를 잃게 될 수 있다.그 모든 말이, 나는 "Wiki it"이라고 말하는 많은 사람들을 알고 있다. 기술적으로 정확하지는 않지만, 당신이 원하는 방식으로 잘 해결되는 경향이 있다.~ 아모리 (사용자 • 대화 • 기여) 2009년 8월 24일 (UTC) 12:54 [응답]

나는 당신이 어떤 웹사이트에서 말하는 것처럼 "위키피디아에서 찾아봐"라고 말하는 것이 그렇게 어렵지 않다고 생각한다.나는 우리가 "위키피디아 잇"이라고만 말할 필요는 없다고 생각하지만, 만약 사람들이 당신이 무슨 말을 하는지 안다면, 그렇게 해.음, 2009년 8월 24일 15:00 (UTC)[응답하라]

"위키피디아 잇"은 둘 이상의 의미를 가질 수 있기 때문에 문제가 된다.그것은 "기사를 읽는다" 또는 "기사를 다시 쓴다" 또는 "단 한 문장에 대한 합의를 결정하기 위해 남은 한 주를 소비한다"를 의미하는가?WhatamIdoing (talk) 2009년 8월 24일 (UTC) 19:12[응답]

우글우글.위키.위키팩트 체크.(Bing it에서) 날개짓을 하라.아, 이거 다 형편없어.어쩌면 우리는 "위키세어치 바"를 만들어 현실에서 어느 정도 근거를 두고 위키세어치라는 말을 퍼뜨릴 수 있어야 할지도 모른다.("우리"라는 말은, "나와 마이크1024를 제외한 우리 모두"라는 뜻이다.신조어를 구성하는 사람들의 눈썹은 그것을 사용하는 사람들의 눈썹보다 확실히 높다.)앤드루 그래드먼 _WP:Hornbook/ 2009년 8월 25일 05:53 (UTC)[응답]

아마도 여기에 새로운 동사가 생겨날 수 있을 것이다 - 그 후에, 구글은 매우 인기 있는 검색 엔진이 되어서 사람들은 "웹을 서핑"하는 것이 아니라 "웹을 구글"이라고 말한다.혹시 위키피디아에 대해 한 학기 동안 이야기 할 수 있을까?그러나 위키백과 외에 다른 위키 웹사이트(Wikinews 등)가 많기 때문에 나는 "위키화"라고 말하는 것에 반대할 것이다.

ACEOREVIVEED (토크) 06:23, 2009년 8월 26일 (UTC)[응답]

이 용어가 인기를 끌기 위해서는 검색 도구 모음과 연결해야 하는데, 예를 들어 검색 버튼에서 "Go"라는 단어의 대체 용어로 사용하십시오.하지만 우리의 현재 어떤 생각이 그런 위치에 놓이는 걸 상상하면

• 위키!
• 위키트!
• 위키리셔스!
• 위키백과!
• WP!
• 위키백화!
• 위키피디아!
• 우글우글!
• 제기랄!
• 왈타비스타!
• 와우!

입맛이 없어진다.미안해 짐보.앤드루 그래드먼 _WP:Hornbook/ 06:59, 2009년 8월 26일 (UTC)[응답]

"윅". 노이즈알트(토크) 11:33, 2009년 8월 26일 (UTC)[응답하라]

오랫동안 금지된 사용자의 이름을 따서 이름을 지을 필요는 없다.'그루프!'라고 말하는 것과 같은 말인데, 생각해 보면, 음, 재미있는 암시를 빼고는 좋게 들릴 것이다. :-) 그라함87 16:11, 2009년 8월 26일 (UTC)[응답하라]

나는 "wiki it"을 좋아한다. - Peregrine Fisher (talk) (contracts) 16:16, 2009년 8월 26일 (UTC)[응답하라]

이 용어를 좋아하는 것은 고맙지만, 위에서 말한 것을 고수한다. 위키백과 말고도 다른 위키 웹사이트가 있기 때문에, 나는 "위키 잇"에 대해 약간 확신이 없다.AGradman이 위에서 제안한 것처럼 위키피디아는 어떠세요?ACEOREVIVEED (토크) 2009년 8월 26일 (UTC) 19:54 [응답]

여러분, 이 모든 토론은 이 페이지에서는 적절치 못하며, 어쨌든 거의 쓸모없는 것이다.진짜 고를 수 있는 건 아니에요.만약 어떤 단어가 생긴다면, 그것은 언어 진화의 일상적인 자연적인 진화에 의해 이루어질 것이다. 누군가가 그것을 말하고 그것을 이해하게 된다.그 과정을 지시하는 것은 효과적일 것 같지 않다; 그것은 단지 사람들을 짜증나게 할 것이다. --트로바토어 (대화) 20:05, 2009년 8월 26일 (UTC)[응답]

과제는 「___ it」에 들어맞고 구두(문자뿐 아니라)가 짧은 위키백과(5음절)의 약자를 찾는 것이다.그리고 나서 우리는 그것을 사용하기 시작한다."Wiki it"은 쐐기풀로 흐른다."Double Yeah-peed it"은 제대로 작동하지 않는다.TFE? WiP? WP, 'wip'으로 발음되는 것을 점검하십시오.채찍질해.하하. 이제부터 내 머릿속에서는 Wip라고 WP를 발음하고, 위키피디아를 WiP라고 지칭하고 있을 것이다.나와 함께 해! 그리고 곧 우리도 멋진 명사를 갖게 될 거야. M

나는 그런 동사를 개인적으로 사용하지 않을 것이지만, 나는 ask.com을 선호하기 때문에 "구글 it"을 사용하지 않는다. 나는 이 실이 지속되고 더 많은 차임벨이 들어가기를 희망한다고 말하고 싶다.그것은 재미있고, 흥미로우며, 그것은 마을 펌프에 관한 것이다.Trevatore와 같은 편집자들이 여러분을 낙담시키거나 괴롭히거나 게시하지 않고 계속하도록 하지 않도록 협업하십시오.습식 빈칸은 많고 무시될 필요가 있다. 왜냐하면 그나 다른 누군가가 이 실을 좋아하지 않으면 읽을 필요가 없기 때문이다. 우리는 위키피디아를 검열하지 않는다.계속 즐겁게 지내세요.당신은 위키피디아의 심장부고 여기에서의 유쾌한 교환은 종종 여기서 발견되는 우울한 논쟁과 사소한 말다툼으로부터 큰 방해가 된다.협업이 장려되어야지, 경직되어서는 안 된다.이건 토론하기에 완벽한 포럼이야, 떠나지 마. 내가 마지막으로 키 스트로크를 할 때까지 너를 지켜줄게.카멜빈키 (대화) 01:29, 2009년 8월 30일 (UTC)[응답]

위키백과!그랜드마스터카 03:26, 2009년 8월 30일 (UTC)[응답]

(결국 누군가가 어쨌든 그들에 대한 기사를 쓸 것이기 때문에) 만약 그들이 주목할 것이라고 생각한다면 편집자들이 자신에 대한 기사를 결코 만들 필요가 없다는 것과 같은 관점에서, 나는 사람들이 사용할 수 있는 문구를 만들어내려고 하는 것은 어리석은 게임이라고 생각한다.'익잇잇(wik it)'이나 '윙잇(wing it)'을 즐겨 쓴다는 것이 사회의 공감대라면, 그 말은 신학으로 받아들여질 수 있다.그렇지 않으면 그냥 기다려야 할 것 같아.그것을 추진하는 것은 거의 우리가 "힙"하고 "사회와 조화롭게" 되기를 간절히 바라는 것처럼 보인다.현실을 직시하자, 우리는 다른 어떤 것과도 조화되지 않고 우리만의 생각이야.(그러니까, 위키피디아의 고유 주파수는 미들C와 비슷하다고 들었는데...) 그렉 타일러 21:58, 2009년 9월 1일 (UTC)[응답]

나는 트로바토레도 위에서 같은 주장을 한 것을 눈치챘고 내 직책의 후반부는 전혀 무관하고 근거도 없고 허황된 허튼소리라는 것을 분명히 하고 싶다.그레그 타일러 22:00, 2009년 9월 1일 (UTC)[응답]

위키피디아는 지구에 평화를 유지해야 한다...

여보세요!

영어에 대한 나의 제한적인 지식은 미안하지만, 나는 다음과 같은 이미지가 있다고 생각한다.

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:Anti_Armenia.png

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_France.svg

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_Israel.svg

위키백과 또는 위키백과인의 사용자 페이지에 있어서는 안 된다.

위키피디아는 일부 사용자의 난폭한 표현을 위한 것이 아니라 지식을 위한 장소여야 한다.

Skrabbit (대화) 2009년 8월 31일 (UTC) 16:45 [응답]

그 이미지들은 아즈위키피디아에 있어 우리가 할 수 있는 건 아무것도 없어미안. 2009년 8월 31일 Majorlytalk 16:47 (UTC)[응답하라]

사실, 그들은 모두 하원에서 주최한다.그 문제를 하원에서 다루면 된다.공용:삭제 요청이나 이와 비슷한 것, 비록 내가 하원의 정책을 지지하고 있다고는 말할 수 없지만.Cool3 (토크) 2009년 8월 31일 (UTC) 17:12 (응답)

{{db-attack}}}에 해당하는 것이 무엇이든 간에 나는 기꺼이 그 이미지들을 양쪽 모두에 태그할 것이다.그 이미지들은 내가 상상하는 어떤 긍정적인 것에도 쓰일 수 없다.- 2009년 8월 31일 (UTC) 17_¢:14, 8월 31일 (회신)

첫 번째 이미지만 빼고.주요토크 2009년 8월 31일 (UTC) 17:15 (응답)

중요한 것은, 인생의 모든 것이, 특히 모든 것에 대한 백과사전에서 긍정적이지 않다는 것이다.Majorlytalk 17:15, 2009년 8월 31일 (UTC)[응답]

그래, 하지만 일어났거나 존재하는 부정적인 것을 보여주는 것과 증오심을 조장하는 것 사이에는 차이가 있어.반이스라엘 국기는 그것이 켜져 있는 사용자 페이지에 의해 상당히 부정적으로 사용되고 있다. - -ooʏiaɲ^τ_¢ 17:42, 2009년 8월 31일 (UTC)[응답]

사실 세 가지 모두 사용자 페이지에서 사용하는 것 같은데, 그 이상은 말씀드릴 수 없지만...~ Amory (사용자 • 대화 • 기여) 2009년 8월 31일 (UTC) 20:02, 응답

(od) 이 나사산과 다소 관련이 있는 경우: 공통:공용:Deletion_requests/Image:공통점을 논하는 Anti_Poland.png:범주:Anti_logos 및 그 >220 멤버 파일.토론을 어떻게 해야 할지 모르겠지만, 어떤 경우에도 이 프로젝트의 범위 내에서 할 일이 없다.누군가 프랑스인이 아닌 이미지의 속도를 높이려 했고 그 빠른 태그는 저자에 의해 빠르게 제거되었다.Sswongk (대화) 2009년 8월 31일 21:35 (UTC)[응답하라]

나는 이스라엘을 지명했다.그것은 명백히 정치적 의제의 일부로서, 그것이 상주하는 페이지에서 수집될 수 있다.반프랑스나 반일 이미지와는 달리 현재 진행 중인 대립을 고려하고 있으며, 정부 정책에 대한 단순한 반감이 아니다. - ʄooʏiaɲ 19_¢:16, 2009년 9월 1일 (UTC)[응답]

최근 변경 페이지 표

최근 변경사항 페이지의 내용이 매우 잘못 정렬되어 있다.테이블에서 데이터를 정렬할 수 있는가? --Janezdrilc (대화) 14:42, 2009년 8월 28일 (UTC)[응답]

어떻게 보고 싶으세요?그 당시 신사는 누구였습니까?(토크) 2009년 8월 28일 19:27 (UTC)[응답하라]

테이블에는 약 6개의 열이 있을 수 있다.Column1은 N 또는 m, Column2 Title, 다음 시간, 바이트 카운터, 작성자 및 최종 노트. --Janezdrilc (토크) 22:28, 2009년 8월 30일 (UTC)[응답]

이해가 안 돼벌써 7개의 컬럼이 있다.더 많은 정보를 원하십니까, 아니면 더 적은 정보를 원하십니까?그 당시 신사는 누구였습니까?(토크) 2009년 8월 31일 21:03, (UTC)[응답하라]

OP는 Special의 "최근 변경사항" 탭에서 전환할 수 있는 "향상된 최근 변경사항"에 관심이 있을 수 있다.선호도.Dendodge \^C 21:05, 2009년 8월 31일 (UTC)[응답]

내 말은 이런 격자가 있는 테이블(현재로서는 그냥 글머리표 리스트가 있을 뿐이다)을 의미했다.

(diff) (역사)	m	하이데라바디 헤일렘	01:58	(+3)	사라브제트 (토크 기여)	→준비 : 문법
(diff) (역사)	N	사용자:Darrenhusted/sandbox22	01:58	(-25)	훌리건브 (토크 기여)	→칼
(diff) (역사)		위키백과:위키프로젝트 마카오/인기 페이지	01:58	(+57)	Baxtersmalls (대화 기여)	위키프로젝트 마카오의 인기 통계
(diff) (역사)		덱실라	01:58	(+456)	Mr.Z-bot (대화 기여)	→링크: 하위 범주로 이동, 대체:카테고리 :타치니대 → 타치니대-스텁, 제거: 플라이 스텁, AWB 사용

나는 당신이 위키피디아 "최근의 변화" 기능이 더 잘 분류되는 것을 보고 싶다는 뜻인지 궁금하다.현재, 나는 만약 당신이 "최근의 변화"를 클릭한다면, 유일한 순서는 마지막 x개의 변화들의 순전히 일시적 순서인 것처럼 보인다는 것에 동의한다. (어떤 위키피디아 사람들이 충분히 공정하다고 생각할 수 있는 순서 - 결국, 이것은 이 특성의 이름이다.)그러나, 아마도 이 특징을 분류하는 방법이 있을 것이고, 그래서 사람들은 이 특징에서 보고 싶은 것을 더 쉽게 찾을 수 있을 것이다.ACEOREVIVEED (토크) 2009년 9월 2일 (UTC) 20:02, 회신

기사 마법사 2.0

맞아, 이건 오랫동안 내 발목을 잡았는데, 드디어 해냈어. 창작 마법사의 기사를 바탕으로 위키피디아를 만들었어.제2조 마법사 2.0(도움이 적고 예쁘고 활용도가 낮은 WP를 감독한다):문서 마법사) 마지막에 간단한 템플리트를 포함하여 등록된 사용자가 문서를 작성할 수 있는 일반 마법사.아이디어와 실행, 그리고 그것이 준비되었을 때 우리가 그것을 어떻게 홍보할 수 있는지에 대한 코멘트를 부탁한다.나는 이전에 검색 결과 페이지를 생성하는 미디어위키 페이지와 같은 것들을 고려해 본 적이 있다.NB 이전 기사 마법사가 취할 만한 한 가지 일은 대체 철자 검색 등의 필요성을 강조하는 것이다.기사 마법사/기타).하지만 난 지금 피곤하고 배고파...Rd232 14:13, 2009년 8월 30일 (UTC)[응답]

나는 그것을 좋아한다.위키피디아 토크에 피드백을 올렸다.기사 마법사2.0. hmwitht 14:34, 2009년 8월 30일 (UTC)[응답]

훌륭한 출발이다.몇 가지 코멘트가 있지만 생각을 정리해야 한다.토크페이지에서 더 많은 소매로 대응할 것이다.--SPHILbrickT 17:53, 2009년 8월 30일 (UTC)[응답]

전혀 작동하지 않음, 재시도 없이 중단됨...그리고 "시간 내줘서 고마워, 다음 주에 와"라는 말도 하지 않았다. 그래, 난 솔직히 아직 FA 준비가 안 된 줄 알았고, 너무 늦지 않았고 대담하고...오, 그래.정말로, 나는 도움이 필요한 사용자가 실제로 이 모든 장애물을 겪게 될지 의심스럽다.마치 은행의 콜센터 컴퓨터가 전화기 배터리를 소모시킨 것 같아. 필요한 것이면 더 가까이 다가가기도 전에 말이야.아니, 그들은 좋은 옛날 방식으로 규칙을 배우는 게 좋을 거야.NVO (대화) 2009년 8월 30일 19:50 (UTC)[응답]

그리고 지금까지 이 주제에 대한 가장 건설적이지 않은 논평에 대한 상은...정말이지 어떤 종류의 정말 훌륭한 마법사는 대단한 자산이 될 것이다.하나를 만드는 것을 돕는 것은 어떨까?아니면 이 일이 그렇게 나쁜 출발점이라고 생각한다면 스스로 시작하라.Rd232 22:46, 2009년 8월 30일 (UTC)[응답]

위키백과:기사_wizard2.0/하위 페이지가 깨짐(이용자 공간 프로토 기사 작성에 사용됨) (시청자의 이름을 표시하는 대신 페이지를 마지막으로 편집한 사람의 이름을 표시함).교체 권장{{REVISIONUSER}}와 함께Special:Mypage. --Thinboy00 @276, 즉 05:37, 2009년 8월 31일 (UTC)[응답]

됐어, 고마워Rd232 18:57, 2009년 9월 1일 (UTC)[응답]

현재 위키백과에서 미해결 이슈에 대한 개요를 확인할 수 있다.기사 마법사2.0#우수한 이슈들.고마워요.Rd232 18:57, 2009년 9월 1일 (UTC)[응답]

수고 많으셨습니다, 그런 것도 생각해 봤는데, 새로운 사용자들에게 도움이 될 수 있을 것 같아.세나리움 (대화) 2009년 9월 2일 (UTC) 17:11, 답신

페이지 하단의 검색 상자

모든 페이지 하단에 검색 상자를 추가할 수 있는 방법이 있는가?페이지 맨 아래에 있는 Firefox를 사용하려면 스크롤 막대를 잡고 페이지 맨 위까지 스크롤해야 검색 상자에 도달할 수 있다.스크롤 막대를 마우스 오른쪽 버튼으로 클릭하고 페이지 상단으로 가도록 요청할 수 있는 IE에서는 문제가 되지 않지만, 파이어폭스에서는 그럴 수 없다.또는 "페이지 맨 위로 이동"이라고 적힌 링크만 사용할 수도 있다.그 당시 신사는 누구였습니까?(토크) 2009년 9월 2일 20:57 (UTC)[응답하라]

키보드에 홈 또는 엔드 버튼이 없는 경우 —DJ(토크 • 기여) 21:11, 2009년 9월 2일(UTC)[응답]

위키백과를 참조하십시오.바로 가기 키.Alt-Shift-f는 윈도우즈 또는 Linux에서 Firefox의 검색 상자로 바로 이동한다.프라임헌터 (토크) 2009년 9월 2일 21:16 (UTC)[응답]

나는 저것들이 그렇게 할 줄은 몰랐다.고마워요.그 당시 신사는 누구였습니까?(토크) 2009년 9월 2일 21:19 (UTC)[응답하라]

내 Mac에서는 Tab을 눌러서 검색 필드에 직접 초점을 맞출 수도 있다(Watchlist 또는 Incidents 페이지의 옵션과 같은 다른 양식 요소에 의해 버림 받기는 하지만).EVULA // talk // talk // 22:08, 2009년 9월 2일 (UTC)[응답]

감사소위원회를 독립위원회로 전환하고 새로운 책임을 부여하자는 제안

이 제안 및 예비 토론에 대한 자세한 내용은 여기를 참조하십시오.감사 소위원회를 중재 위원회와 독립된 법인으로 전환하고 검수자와 감독 권한의 감독에 관한 몇 가지 추가 책임을 부여하자는 제안이다.세나륨 (대화) 22:40, 2009년 9월 1일 (UTC)[응답]

독립성에 대한 문제는 나중에 검토하기 위해 보고되었으며, 현재 감사 소위원회에 새로운 책임을 추가하고 정기적으로 CU/OS 선거를 조직하자는 제안이 있으며, CENT. Cenarium (대화) 03:45, 2009년 9월 3일 (UTC)[응답]에도 추가되었다.

비소싱 테이블

테이블/차트/그래프를 비소싱으로 표시하는 템플릿이 있는가(예: 이미지 아래에 넣을 수 있는 템플릿){{bar box}} "이 표/차트/그래프의 출처가 불분명하다"는 말을 할 수 있는가?나는 아무것도 찾을 수 없었어요.그리고 만약 없다면, 하나를 추가하는 것이 유용할 것이라고 생각하는 사람이 있는가?꽤 쉽게 만들 수 있었다. rʨanaɢ^talk/_contribs21:02, 2009년 9월 2일 (UTC)[응답]

필요한 표준 {{citation}}을(를) 사용하는 것이 무슨 문제인가?흐흐무트 21:20, 2009년 9월 2일 (UTC)[응답하라]

구체적인 사실보다는 테이블 전체, 즉 이미지를 표시하려고 생각하고 있었다.(이것을 생각하게 한 것은 한국#종교도의 바차트였다.) rʨanaɢ^talk/_contribs 05:20, 2009년 9월 3일 (UTC)[응답]

음, 난 네가 테이블의 끝이나 그 바로 위에 있는 테이블 안에 있는 것을 설명하는 문장 뒤에 그것을 추가할 수 있다고 생각했어.음, 13:43, 2009년 9월 3일 (UTC)[응답]

장기수집 여론조사

중국 팔룬궁 개업자들의 장기수확 보고서가 독립된 주제인지, 아니면 중화인민공화국의 장기수확에 통합되어야 하는지에 대한 여론조사가 만들어졌다.대화로 이동하십시오.중화인민공화국/FG 투표에서 장기 채취.Ohconfucius (대화) 14:04, 2009년 9월 3일 (UTC)[응답하라]

내가 그 링크를 고쳤어.UltraExactZZ ~ 증거 18:05, 2009년 9월 3일 (UTC)[답글]

이동토론 요청 {{otherus4} → {{about}}

공통 해트노트 템플릿 {{otherus4}} → {{about}(또는 {{otheruss}) : 현재 이름(임의 4)은 기억하기 어렵고 난해하기 때문에 이동에 대한 논의를 요청한다.Template_talk에서 토론을 시작했다.기타이용4#Request_move_토론.관심 있으시면 템플릿 이동 여부, 있다면 어디로 옮겨야 하는지에 대해 상의하기 위해 오십시오.고마워, -슬리고키 (대화) 20:43, 2009년 9월 3일 (UTC)[응답]

사이드바에서 커뮤니티 포털 대신 소개로 연결

이 제안에 대해 여기서 보고 의견을 제시하십시오.고마워, 세나리움 (대화) 23:03, 2009년 9월 3일 (UTC)[응답]

편집 인터페이스를 보다 명확하고 유용하게 만들기

모두 안녕!여러분은 아마도 위키피디아가 현재 편집 인터페이스를 검토하고 있다는 것을 알고 계실 겁니다. 그 목적은 위키피디아를 사용하기 쉽게 하기 위함입니다.많은 시간과 돈이 소비되고 있고, 이것은 분명히 좋은 생각이다.하지만 아직 개발자들이 일하고 있는 동안, 나는 비교적 쉽게 대대적인 개선이 이루어질 수 있다고 생각한다.편집 상자를 둘러싸고 있는 텍스트는 혼란스럽고 볼품없으며 전혀 도움이 되지 않는다.그것은 조각조각 나있으며, 분명 많은 다른 사람들이 수년간 땜질한 산물이다.나는 우리가 한 걸음 물러서서 이 중요한 텍스트를 훨씬 더 제시 가능하고 유익한 방법으로 정리해야 한다고 생각한다.아래는 인터페이스의 두 가지 이미지로, 내 제안 이전과 이후의 것이다.

보다시피 나의 제안은 현재 상황보다 간단하고 명확하며 아름답다.또한 로그인한 사용자를 위해 세 번째 '계정 만들기' 라인의 제거를 제외하고 동일한 유사한 라인이 생성되었으면 한다.사용자 선호도에 따라 디스플레이가 꺼지길 바란다.불안첼로 (대화) 2009년 8월 30일 (UTC) 15:48, 응답

화면 크기가 적당한 사용자는 전체 화면을 아래로 스크롤하여 편집 창으로 이동해야 한다. 왜?NVO(토크)19:32, 2009년 8월 30일(CoordinatedUniversalTime)[응답].

경험이 많은 사용자가 끌 수 있기 때문에 영향을 받지 않을 수 있다.주로 신규·미등록 사용자를 대상으로 한다.불안첼로 (대화) 2009년 8월 30일 21시 12분 (UTC)[응답]

처음 사용자는 편집 창이 화면의 3분의 1 아래에 있거나 더 나쁜 경우 편집 창을 찾을 수 없다.그냥 가버리곤 했어사용성 기본 사항.화면에 나올 법한 것들 중에서 가장 중요한 것을 빠뜨렸다.창 편집.NVO (대화) 2009년 8월 31일 18:19, (UTC)[응답]

그것은 사용적합성 기본이 아니라 매우 추측성 있는 의견이다.나의 매우 추측적인 의견에서, 나는 애논 사용자들이 현재 직면하고 있는 것 보다 "에팅 인터페이스에 온 것을 환영한다"는 문장으로 더 환영을 받을 것으로 기대한다; "당신은 로그인하지 않았다"는 경고.상자가 수직 공간을 덜 차지하는 아래 두 번째 초안 이미지를 참조하십시오.불안첼로 (대화) 2009년 8월 31일 19:53 (UTC)[응답]

같은 양의 공간을 차지하는 현재 텍스트로 할 수 있는 것보다 더 많은 양이다.불안첼로 (토크) 2009년 8월 30일 (UTC) 23:33[응답]

하지만 현재 설정으로 쉽게 숨길 수 있다.또한 CC-BY-SA 및 GFDL에 대한 필수 텍스트가 누락됨. Anomie⚔ 00:54, 2009년 8월 31일(UTC)[응답]

아마도 저 고도의 기술 텍스트는 그대로 남겨둘 수 있지만, 저장 버튼 바로 뒤에 (여기 편집/여기 요약 텍스트가 사용될 수 있도록) 있을 것이다.불안첼로 (토크) 2009년 8월 31일 (UTC) 12시 52분[응답]

나는 이 제안이 마음에 드는데, 현재 인터페이스의 잡동사니에 대해 네가 전적으로 옳다.그것은 발전이 필요하지만 좋은 출발이다.분명히 그것은 쉽게 비활성화할 필요가 있을 것이다(그리고 출처가 필요하다는 것을 불확실한 용어로 언급해야 한다).—Noisalt (대화) 01:05, 2009년 8월 31일 (UTC)[응답]

아마도 그 옆에 [숨기기]/[표시] 기호가 있을 수 있고, 사용자 선호도에서 그것을 완전히 숨기기 위한 옵션이 있을 수 있는가?나는 아노미의 '쉽게'라는 생각이 나와 같다고는 말하지 않을 것이다.불안첼로 (토크) 2009년 8월 31일 (UTC) 12시 52분[응답]

모든 것을 한 곳에 두면 얼마나 더 선명하게 보이는지 알 수 있다.하지만 그게 더 도움이 될지 모르겠어.이것은 모든 것을 옷장의 선반 하나에 놓아 당신의 침실을 청소하는 것처럼 보인다.그래, 방이 덜 어수선하고, 모든 것이 어디에 있는지 알겠지만, 그렇다고 그것이 더 사용 가능한 시스템을 의미하지는 않아.미스터Z맨 02:02, 2009년 8월 31일 (UTC)[응답]

내 아이디어의 주요 USP는 우리가 지금까지 완전히 외면해왔던 그 시장 내 사람들을 위해 어떻게 편집해야 하는지에 대한 지침을 가지고 있다는 것이다.불안첼로 (토크) 2009년 8월 31일 (UTC) 12시 52분[응답]

하지만, 실제로는 그렇지 않다.이미 있는 것을 가져다가 다 없애고 나머지는 다 한 곳에 두는 것뿐이다.2009년 8월 31일 Mr.Z-man 13:49 (UTC)[응답]

단지 시각적으로, 어쨌든 그 페이지에는 너무 많은 공백이 있다.— V = I * R (Ω과 대화) 14:03, 2009년 8월 31일 (UTC)[응답]

그게 나한테 답장이어야 하는 거였어?공백 제거는 편집 방법에 대한 지시사항을 추가하지 않는다.제안된 설계에는 현재 인터페이스가 가지고 있지 않은 것이 없으며, 현재 인터페이스가 가지고 있는 것이 누락되어 있다고 생각한다.2009년 8월 31일 Mr.Z-man 18:35 (UTC)[응답]

하지만 그것은 그렇다!간단한 편집 지침이 있다 - 상단 상자의 네 번째, 다섯 번째, 여섯 번째 글머리 기호 참조.내가 2차 초안을 제출했으니까, 저것 좀 봐, 네가 더 만족해 할 거야.나의 제안은 명료한 설명에 간단한 언어를 사용한다.경험 많은 사용자인 당신에게는 이 모든 것이 엉뚱하게 보일지 모르지만, 나는 비디오에서 그 평균적인 조 타입이 말한 것에 대해 정말로 느낀다. (파일:위키는 바보 같은 v2.ogv)를 느낀다.시간을 내어 최근 사용적합성 및 경험 연구를 읽어 보십시오.나의 제안은 이제 이것이다; 맨 위 상자는 IP 사용자들(아마도 새로 등록된 상자들)에게만 보일 것이고, 맨 아래 상자는 모든 사람들에게 영구적으로 보일 것이다.단순히 "한 개의 선반에 던져넣기"가 아니라, 새로운 사용자에게 가르쳐야 하는 몇 가지 매우 중요한 - 심지어 -의 메시지를 명확하고 공동의 조직이다.불안첼로 (토크) 2009년 8월 31일 (UTC) 19:33[응답]

나는 우리가 더 나은 지침이 필요하다는 것에 동의하지만, "문자로 가득찬 큰 경적 상자에 타이핑"은 거의 "컴퓨터 101 사용"이다.일반적으로 몇 단어 이상을 타이핑하는 것은 텍스트 상자에 타이핑하는 것을 포함하며 인터넷의 거의 모든 형태에는 버튼이 있다.만약 있다면, "변화를 보여줘"는 설명이 필요한 것이다.문제는 위키텍스트의 복잡한 성격이지 편집함이나 "저장" 버튼을 찾을 수 없는 사람들이 아니다.계속 접속하고 있는 영상을 실제로 본 적이 있는가?Mr.Z-man 21:38, 2009년 8월 31일 (UTC)[응답]

그래, 그리고 내가 잊어버린 생각은 편집 페이지에 도달하는 정보의 과부하로 사람들이 당황했다는 것이다.좋아, 편집 상자 앞에 있는 지시 상자가 모든 사람을 열정으로 가득 채우는 것은 아니라는 것을 알겠다.편집 상자 다음에 나오는 텍스트 순서 섞기를 지원하시겠습니까?좀 더 조직화되면, 아마도 사람들이 기본적인 규칙 등을 이해하는 것이 더 쉬워질까?불안첼로 (대화) 2009년 8월 31일 (UTC) 23:03, 응답

사용적합성 이니셔티브로 가져가십시오. 현재 사용적합성 이니셔티브에서 작업 중인 작업이 바로 이것이기 때문에...— V = I * R(Ω과 대화)

주어진 제안을 추가하여 새로운 초안을 작성한다.헤더는 상자를 축소하고 공백을 제거하기 위해 측면으로 이동했다.텍스트와 상자를 만드는 데 사용한 코드는 User:불안세포/인터페이스불안첼로 (대화) 2009년 8월 31일 (UTC) 14시 15분 (화)[응답]

만약 당신이 텍스트의 양을 줄이고 있다면, 나는 그것을 지지할 것이다.하지만 넌 아니니까 난 아니야.나는 "편집 인터페이스에 온 것을 환영한다!"를 없애서 시작할 것이다.아마 처음에만 전시되었다면 괜찮을지도 모르지만(아마 그렇지 않을 것이다) 빨리 짜증나게 될 것이다.그것을 무시해야 하는 것 또한 짜증날 것이다.어쨌든 6문장이 2문장으로 줄어든 것을 보고 싶다. - 페레그린 피셔 (토크) 21:32, 2009년 8월 31일 (UTC)[응답]

맨 위 상자는 익명 사용자 및 새로 등록된 계정에만 표시된다.로그인을 하지 않는 경우를 제외하고는 윗부분이 보이지 않을 것이다.불안첼로 (토크) 2009년 8월 31일 (UTC) 22:16 [응답]

그럼 더 짧은 하단 상자는 어때? - 페레그린 피셔 (토크) 22:24, 2009년 8월 31일 (UTC)[응답하라]

유감스럽게도 그렇지 않다; 웹사이트가 운영되기 위해서는 마지막 네 개의 총알이 법에 의해 요구되고, 처음 두 개의 총알은 우리 백과사전 운영에 필수적인 우리 고유의 규칙이다.이런 것들은 말할 필요가 있다.어쨌든 지금 상태로는 내 상자는 현재 상황보다 공간을 적게 차지(약 20% 적게)하고 여전히 똑같은 말을 한다.불안첼로 (대화) 2009년 8월 31일 (UTC) 23:03, 응답

사이드 박스에 '환영한다'고 써있는 게 뭐야?그것들을 없애라.—Noisalt (대화) 00:21, 2009년 9월 1일 (UTC)[응답]

아래로 잘라낸 변경

좋아, 나는 내가 시작한 박스에 대한 아이디어가 미적, 그리고 실용적인 이유 때문에 행복하게 받아들여지지 않고 있다는 것을 알 수 있어.어쩌면 더 간단한 개혁이 받아들여지는 것이 좋을까?일단 상단 상자는 잊어버리고, 편집 상자 아래의 텍스트에 초점을 맞추자.내가 전에 말했듯이, 그것은 조각조각 나있고, 분명 많은 다른 사람들에 의해 수년간 땜질한 산물이다.그것은 또한 사람들이 쉽게 읽고 이해할 수 있어야 하는 정보의 매우 중요한 부분이다.그러므로 나는 위의 재조정을 제안한다.생각나는 거 있어?불안첼로 (대화) 00:56, 2009년 9월 1일 (UTC)[응답]

나는 텍스트는 적게 지원할 수 있지만 다른 사람들은 더 좋아할지도 모른다. - 페레그린 피셔 (토크) 01:00, 2009년 9월 1일 (UTC)[응답]

현재 상황보다 수직적인 공간을 덜 차지하며, 현재 183자 대비 168단어에 불과하다.나는 그것이 가능한 한 짧아야 한다는 것에 동의하지만, 내 제안서의 모든 텍스트가 필요하다고 느낀다.지나가기가 그렇게 힘드니?정말 자주 할 필요는 없겠지?불안첼로 (대화) 01:23, 2009년 9월 1일 (UTC)[응답]

무슨 일인지 알겠다.'글씨를 편집하지 않으려면' 내용이 작은 글씨체여서 원본에서 보지도 못했다.배치는 좋은 것 같지만, 비록 짧아도 그렇게 길게 보이는 게 마음에 들지 않는다. - 페레그린 피셔 (토크) 01:30, 2009년 9월 1일 (UTC)[응답]

봐, 그래, 마치 어떤 텍스트가 <작다>고 어떤 텍스트는 <크다>고, 어떤 것은 대담하고 어떤 것은 사물을 덜 보이게 하고, 어떤 것은 얼버무리기 쉽게 한다.다 중요해!그게 지금 더 길어 보인다는 뜻이야?무시하기가 그렇게 쉽지 않아?불안첼로 (토크) 01:42, 2009년 9월 1일 (UTC)[응답]

글쎄, 모든 것이 중요하다고 확신할 수는 없지만, 그래, 그게 내 뜻이야. - 페레그린 피셔 (토크) 02:21, 2009년 9월 1일 (UTC)[응답]

또한, 2만 번의 편집이 있은 후, 오늘은 내가 그 중 어떤 것도 읽으려고 애쓰지 않은 첫 번째 날이다.구글 검색의 측면에 있는 광고와 비슷해.나는 그것을 보지도 않는다.그냥 설명 페이지로 링크하면 될까? - Peregrine Fisher (토크) 02:27, 2009년 9월 1일 (UTC)[응답]

불행히도, 아니, 우리는 할 수 없다.위키피디아를 발행하는 기관이 지정한 대로 라이센스 권한을 가지고 그 페이지에 있어야 한다.위의 아노미 게시물을 참조하십시오. 212.183.134.64 (토크) 02:38, 2009년 9월 1일 (UTC)[응답]

그건 사실이 아니에요.많은 사이트에는 전용 페이지에 모든 정보가 수록된 "사용 약관" 링크가 있다. - Peregrine Fisher(토크) 03:12, 2009년 9월 1일(UTC)[응답]

많은 사이트들이 그들의 텍스트를 복사해서 이익을 위해 운영한다.우리는 매우 특별한 규칙을 가진 매우 특별한 무료 면허증을 가지고 있다.여기를 참조하십시오. 불안첼로 (대화) 14:48, 2009년 9월 1일 (UTC)[응답]

나는 솔직히 여기서 진흙탕의 막대가 되려고 하는 것은 아니지만, 사용적합성 연구 페이지에서 왜 이 논의가 여기서 일어나는지 정말 궁금하다.이것이 바로 그들이 연구하고 개선하는 임무를 맡고 있는 것이고, 그들은 실제로 변화를 실행할 수 있는 WMF의 자금, 자원, 시간, 그리고 지원을 가지고 있다.그들은 또한 이것이 무엇을 다루고자 하는지를 정확히 평가하는 도중에 살짝 부딪혔기 때문에, 당신의 제안과 논평은 거기에 상관없이 훨씬 더 영향을 미칠 것이다.
— V = I * R (Ω과 대화) 06:02, 2009년 9월 1일 (UTC)[응답]

좋아, 여기 위키백과 사용적합성 이니셔티브에 게시했어. -- 불안첼로 (대화) 17:45, 2009년 9월 2일 (UTC)[응답]

그 메타 페이지를 못 봤어우리가 그것을 다듬을 수 있을 것 같지만, 나는 위키 사이의 논의를 따르지 않을 것이다.행운을 빈다. - 페레그린 피셔 (토크) (기증) 17:50, 2009년 9월 2일 (UTC)[응답하라]

강력한 지원, 현 상태는 정말 어수선하다.기호 상자는 제출 상자 바로 아래에 있어야 한다(BTW, wiked aledy는 그런 방식으로 페이지를 재배열한다).제안된 본문은 실제로 더 간결하고 읽기 쉽도록 수정되어야 한다.Cacycle (대화) 21:20, 2009년 9월 4일 (UTC)[응답]

편집 가능한 기록

우리는 위에서 이것에 대해 조금 얘기했다.보조 플래그를 편집하는 방법과 적어도 자신의 편집 요약을 편집하는 방법이 있어야 한다.내가 생각할 수 있는 가장 쉬운 방법은 페이지의 이전 수정 보기에 편집 가능한 필드로 추가하는 것이다.어차피 그 페이지에는 편집 요약을 놓쳤으니 기술적으로 두 가지 향상된 기능이다.버그 20511
— V = I * R (Ω과 대화) 05:31, 2009년 9월 5일 (UTC)[응답]

그런 것은 이미 제안되었다(위키피디아:마을 펌프(제안)/아카이브 30#편집 요약을 편집할 수 있는 위키백과:마을 펌프_(기술)/아카이브 44#요약 유예 기간 편집?, bugzilla:13937).요컨대, 그러한 것은 다소 드문 경우에 어느 정도 유용할 것이고, 다른 드문 경우에서는 매우 혼란스러울 것이다(예를 들어, 누군가가 이미 이전의 편집 요약을 본 경우).따라서 몇 가지 예방책이 필요할 것이다...반면에 편집자가 실수로 페이지를 저장하는 것을 방지하기 위해 편집 요약을 확인할 수 있는 스크립트 또는 가젯(Wipedia에서 제안:빌리지 펌프(proposals)/아카이브 30#Rjd0060에 의해 편집 요약을 편집할 수 있다는 것은 때때로 도움이 될 수 있는 것처럼 보인다... --Martynas Patasius (talk) 15:24, 2009년 9월 5일 (UTC)[응답]

아, 다른 제안들을 지적해줘서 고마워.그것들을 찾아 상하좌우로 검색해봤지만 잘못된 키워드를 사용하고 있었을 것이다('편집' 등이 검색엔진의 진짜 이슈인 것 같다, 여기).어쨌든, 나는 반대 의견을 많이 보지만, 그 아이디어/제안에 대한 진정한 비판은 전혀 보이지 않는다. (나는 분명히 그 아이디어에 찬성하지만...)가젯 구현/기능은 이미 존재하지만, 그것은 완전한 해결책에 가깝지도 않다.
— V = I * R (Ω과 대화) 17:03, 2009년 9월 5일 (UTC)[응답]

HTML 태그 추가...특히 두문자어.

위키피디아는 코드를 가지고 있지만 다음과 같은 매우 유용한 태그가 누락되어 있다.CSS또는 <이름 제목="북대서양조약기구>>나토(NATO)는 기사의 가독성에 정말 도움이 될 것이다.이것은 사용자들이 약어가 무엇을 의미하는지 기억하기 위해 페이지 맨 위로 스크롤할 필요가 없도록 할 것이다.개인적으로, 나는 모든 두문자어/약어들이 이 태그를 사용해야 한다고 생각한다.우리는 단지 기능을 활성화하는 것으로 시작할 수 있다.드래곤쉐도우 (대화) 2009년 9월 4일 16:08, (UTC)[응답]

글쎄, 나는 결코 이것에 반대하지는 않지만, 전우에게 상기시키기 위해, 모든 초기설들은 처음 사용되었을 때 철자를 써야 하는데, 이것은 그 제안을 평가절하할 수도 있다. - Jarry1250^{[ In the UK? Sign the petition! ]} 16:10, 2009년 9월 4일 (UTC)[응답]

개인적으로 한 구획에 한 번 이상 철자를 쓰는 편이야.물론 정말 잘 알려진 약어(NATO, NASA, 미국 등)는 보통 철자가 전혀 필요 없지만, 전혀 다른 이야기다.

어쨌든, 리디렉션이 있는 한, 당신은 여기서 연결로 목표를 달성할 수 있다.예를 들어: 링크 위에 마우스를 놓으면 CSS에 "캐스캐딩 스타일 시트"가 표시됨.
— V = I * R (Ω과 대화) 16:27, 2009년 9월 4일 (UTC)[응답]

현재의 HTML 5 제안은, 그리고 둘 다 부정하는 쪽으로 기울고 있다는 것을 지적할 필요가 있다. 왜냐하면 제안된 용도는, 즉 전문화된 도구들이 HTML 모델과 어떻게 동일한 문자열 엘스를 취급하는지에 대한 힌트를 얻을 수 있도록, 문자열을 한 번 표시하기 때문이다.앞으로 대부분의 고객이 무시해야 할 태그를 추가하는 것은 아마도 좋은 생각이 아닐 것이다.— 가비아 임머 (대화) 18:34, 2009년 9월 4일 (UTC)[응답]

<acronym>HTML 5에서는 더 이상 사용되지 않지만<abbr>그 자리에^[5] 사용되어야 하는 것으로 나열되어 있고 그것은 그들도 똑같이^[6] 취급되어야 한다고 말한다.미스터 지맨 16:34, 2009년 9월 5일 (UTC)[응답]

• 다음과 같은 템플릿이 관심 대상일 수 있다.
  • {{tooltip}}제목 속성을 사용하는 경우, 대부분(X)에서 사용 가능HTML 요소:CSS 2
  • {{abbr}}, Abbr 속성을 사용하는 , 및{{abbrlink}}wikilink라는 용어는 다음과 같다.
    –Whitehors1 16:55, 2009년 9월 5일 (UTC)[응답]

기사의 "역사"에 기사가 언제 작성되었는지 확인

현재 기사의 「역사」에 가면, 기사의 역사가 길다면, 언제 처음 만들어진 기사를 찾기가 쉽지 않다. 예를 들면, 위키백과에 대한 비판은 적어도 2005년 8월부터 존재해 왔다(그 후 역추적을 포기했다).나보다 위키백과의 역학에 대해 더 많이 알고 있다면 용서하십시오. 이미 이 역학에는 안쓰러움이 있을지도 모르기 때문에 - 기사가 처음 만들어진 날짜를 알아낼 수 있는 간단한 방법이 있는가?내가 여기서 제안을 한다면, 그것은 기사의 '역사'에 기사가 처음 만들어졌을 때 적은 쪽지 같은 것을 쓰는 것이다.ACEOREVIVEED (토크) 2009년 9월 5일 (UTC) 20:42, 답변

분명히 있다.기록을 누르고 아래로 스크롤한 후 "최초"를 누르십시오.'Compare selected revisions(선택한 수정본 비교)' 버튼 아래에 있다.작성 날짜는 해당 페이지의 맨 아래에 있는 첫 번째 항목이다.–Whitehors1 21:01, 2009년 9월 5일 (UTC)[응답]

^ 저것. 그런데, 나는 그곳 어딘가에서 다시 올다프풀업 ^^라고 대답했다. - Jarry1250 21:13, 2009년 9월 5일 (UTC)[응답]

'최초' 버튼을 클릭하기 위해 스크롤 할 필요도 없고, 위에도 있다. -- œ^™ 02:18, 2009년 9월 6일 (UTC)[응답]

제안:항상 블록 길이 표시

(이 제안이 적절한 장소인지 잘 모르겠다.주위를 둘러보았지만 더 좋은 곳을 찾지 못했다...)

차단된 사용자의 대화 페이지에 관리자가 추가하는 일부 "차단된 사용자" 메시지에는 차단 기간이 포함되지 않는다는 것을 알게 되었다.블록의 길이는 다른 곳에서 찾을 수 있지만 블록의 근본적인 특징으로 보이며 차단된 사용자의 토크 페이지 항목에 포함되어야 한다.그게 포함되지 않은 이유가 있어?그렇지 않다면 블록의 길이를 항상 그러한 메시지에 포함시키고, 블록 템플리트를 조정(문서 등)하여 요구사항을 나타낼 것을 제안한다.또는 Wiki 소프트웨어가 현재 블록의 길이를 감지하고 템플릿을 수정하여 관리자가 수동으로 정보를 지정할 필요가 없도록 하는 방법이 있을 수 있다.

FYI, 여기 최근의 한 예가 있다. (나는 그 편집에 관련된 관리자를 비난하는 것이 아니다.)템플릿의 일부가 아닌 텍스트를 추가하여 블록 길이를 추가한 다른 관리자의 또 다른 예가 여기에 있다.— John Cardinal (대화) 15:49, 2009년 9월 4일 (UTC)[응답하라]

나는 당신이 당신의 차이점들과 약간 혼동하고 있다고 생각한다 - 당신이 첫번째로 주는 것은 길이가 포함된 두번째 블록 고지를 위한 것이다.두 번째는 블록 길이를 다른 관리자의 통지에 추가하는 관리자가 아니라 블록 길이에 대한 메모가 있는 블록 통지를 한 명의 관리자가 배치하는 것이다.어떤 경우에도 당신의 핵심 지점이 남아있다 - 블록 통지는 만들어지는 블록의 길이를 절대적으로 명시해야 한다.이것은 아마도 WP에서 언급되어야 할 것이다.블락. 2009년 9월 4일 16:00 (UTC)[응답]

음... 내가 첫 블록에 URL을 잘못 올렸네. 미안해.두 번째로, 나는 그것을 잘 설명하지 않았다.관리자가 첫 번째 URL과 다르다는 것을 표시하고 있었다.내 요점은 관리자가 사용하는 블록 템플릿 외부에 블록 길이가 추가되는 것 같다는 것이었다.즉, 행정관은 다음과 같은 것을 키로 했다.

{{someblocktemplate}} Blocked for 1 week

... 블록의 길이를 템플릿의 매개 변수로 지정하는 것과 대조적으로.— John Cardinal (대화) 18:17, 2009년 9월 4일 (UTC)[응답하라]

일부 관리자가 템플릿을 전혀 사용하지 않는 경우...–xeno^talk 18:19, 2009년 9월 4일 (UTC)[응답]

때때로 나는 반달자가 그들이 얼마나 오랫동안 차단되어 왔는지 알기를 원하지 않는다.난 그들이 돌아오길 원하지 않아.EVULA // talk // talk // 19:30, 2009년 9월 4일 (UTC)[응답]

차단된 사람이 편집을 시도할 때 보는 메시지는 블록의 길이를 이미 보여주고, 토크 페이지 노트는 블록을 보는 다른 사람들을 위한 것으로 블록 로그도 볼 수 있다.MBisanz^talk 20:05, 2009년 9월 4일 (UTC)[응답]

동의해, 난 이것이 큰 문제가 아니라고 생각해.–Juliancolton 01:41, 2009년 9월 5일 (UTC)[응답]

나는 블록키에 대해 신경쓰지 않았다; 이것은 다른 이해당사자들에 관한 것이다.만약 그 메시지가 아예 거기에 있을 거라면, 왜 그것을 완성하지 않았는가?— John Cardinal (대화) 02:50, 2009년 9월 5일 (UTC)[응답하라]

나는 종종 IP가 달력만 표시하지 않도록 특별히 길이를 빼놓곤 한다.칠음 02:57, 2009년 9월 5일 (UTC)[응답하라]

그것은 나에게 좋은 논리로 보이지 않는다.그들이 돌아오지 않기를 바란다면 블록을 더 길게 또는 영구적으로 만들어야 한다.또한, 그들이 편집을 시도하면 블록의 길이를 알게 된다. (나는 이것을 본 적이 없다. 차단된 적이 없다. 그러나 누군가가 위에서 설명한 것이다.)길이가 비밀이 아니면 비밀이 아니다.— John Cardinal (대화) 03:14, 2009년 9월 5일 (UTC)[응답]

단지 무언가가 비밀이 아니라고 해서 우리가 그것을 방송하기 위해 우리의 방식에서 벗어나야 한다는 것을 의미하는 것은 아니다.그리고 IP의 경우 블록을 연장하는 것은 때때로 옵션이 아니다.블록 지속시간은 그들이 편집을 시도할 때 보여질 수 있지만, 그들이 그것을 알아차리지 못하고, 재미를 망쳐놓음으로써 낙담하게 되고, 그냥 사라질 수도 있는 아주 현실적인 가능성도 있다.EVula // talk // talk // 04:14, 2009년 9월 5일 (UTC)[응답]

IP는 때때로 소유자를 바꾸지만, 때로는 그렇지 않다.나는 부수적인 피해를 피하기 위해 더 오래 혹은 무기한 블록을 하지 않는다.칠음 03:19, 2009년 9월 5일 (UTC)[응답]

나는 "때때로 나는 그들이 알기를 원하지 않는다"는 이면의 생각이 나를 불편하게 만든다는 것을 인정해야 한다.그게 어디서 오는 건지 완전히 이해하고 있고, 나도 거기 가봤고, 실제로 비밀로 할 수 있는 방법은 없지만...어쨌든, 이건 개인적으로 별로 신경 쓰이지 않지만, 거기서 내 생각을 말하고 싶었어.
— V = I * R (Ω과 대화) 04:37, 2009년 9월 5일 (UTC)[응답]

나는 누군가를 차단할 때마다 템플릿과 메시지에 블록 길이를 추가한다.예의상 하는 일이다.차단된 사람은 차단 기간을 알 권리가 있다.조잔(토크) 14:34, 2009년 9월 5일 (UTC)[응답]

(outdent)현재 상황은 내게 합리적이지 않아 보인다: 편집을 시도하는 차단된 사용자는 차단되었다는 말을 듣고 얼마나 오랫동안, 그러나 일부 관리자는 다른 편집자에게 유용한 토크 페이지 항목에 블록 길이를 넣지 않는다.우연히 같은 IP를 사용하고 편집을 시도하는 비사용 편집자가 블록 정보를 보게 되므로 블록 길이를 생략하는 것이 부수적인 피해를 피하는 데 도움이 된다는 것은 말이 안 된다.게다가, 그들이 베테랑들이 아닌 한 그들은 토크 페이지 항목을 볼 것 같지 않다. 이 경우 그들은 블록 정보를 찾는 방법을 알게 될 것이다.나는 다른 사용 사례들을 통해 생각했고 블록의 길이를 숨기는 것이 실질적인 이점이 있다고 생각하지 않는다.

나는 우리가 의도적으로 메시지에 넣은 정보를 알아차리지 못하는 사용자들에 근거한 주장을 받아들일 수 없다.비합리적인데, 만약 우리가 메시지에 정보를 담으면, 우리는 사용자가 그것을 보도록 의도한다.그들이 보지 않기를 바란다면, 우리는 그것을 빼야 한다.만약 우리가 몇몇 사용자들이 그것을 보게 하고, 다른 사용자들은 그렇지 않으면...원하는 기분이 어때?일단 메시지를 표시하면 어떤 독자가 눈치채고 어떤 독자가 눈치채지 못하는지를 통제할 수 없다.

반면에, 그 정보는 이용할 수 있고, 나의 제안은 그것을 보는 것을 더 편리하게 하기 위한 의도였을 뿐이다.분명히 의견 일치가 없고 내가 동의하는 것은 아니지만, 그것은 큰 문제가 아니다.이 제안을 고려해줘서 고마워.— John Cardinal (대화) 2009년 9월 5일 (UTC) 15:06[응답]

현재 상황이 터무니없게 보일지 모르지만, 나는 당신이 토크 페이지에 블록 기간을 포함하지 않는 것이 어떤 실제적인 문제라는 당신의 주장에 어리둥절할 뿐이다.누가 블록의 지속시간을 가장 많이 볼 필요가 있을까?관리자(재범 차단 기간을 측정하는 데 유용함).Sysops는 Special에서 그것을 볼 수 있다.BlockIP 페이지, 그들은 토크 페이지를 참조할 필요가 없다(적어도 그들은 그렇게 해야 한다).일반 편집자는 거의 신경 쓰지 않을 가능성이 높으며, 편집자가 관리한다면 Special:에서 매우 쉽게 눈에 띄는 Block Log 링크를 클릭할 수 있다.기부금.사용자의 기여가 자신의 토크 페이지(경고 및 차단 통지가 쉽게 제거될 수 있는 곳)보다 자신의 행동에 대한 더 나은 척도라는 주장이 나올 수 있다. 실제로 반달(계정 또는 IP) 의심자를 대할 때 기여도나 블록 로그 등을 확인하지 않고 토크 페이지만 보고 있는 사용자는 조사를 제대로 못하고 있다.ng. 이미 지적된 바와 같이 차단된 사용자도 자신의 토크 페이지에서는 필요하지 않다.
블록의 기간을 참조할 수 있는 3개 당사자를 생각할 수 있을 뿐이고, 어떻게 3개 당사자가 모두 비이슈적인지를 설명했기 때문에, 정확한 문제가 무엇인지 궁금하다.EVULA// talk // talk // 19:51, 2009년 9월 5일 (UTC)[응답]

나는 EVULA에 동의해, 사람들이 블록 로그를 언급해야 하기 때문에 블록 타임을 두지 않아.관리자는 토크 페이지 메시지에서 실수를 할 수 있고, 반달은 메시지를 변경할 수 있으며, 관리자 두 명이 동시에 차단하여 블록 길이 메시지를 부정확하게 만들 수 있다.현재 사용자가 차단된 경우, 대화 페이지 하단에 있는 블록 로그를 확인하시겠습니까?아마도 좋은 생각일 것이다.---케인(대화) 11:11, 2009년 9월 6일 (UTC)[응답]

사진 태그

위키피디아는 포토 태그로부터 큰 혜택을 받을 것이다.특정인의 사진을 찾을 때, 사람, 장소 또는 사물에 관한 모든 기사는 특정 사진에 꼬리표를 붙일 수 있다.그런 것처럼 '바락 오바마'의 사진을 찾을 때 그의 이름이 적힌 모든 사진이 뜬다.이렇게 하면 편집이 훨씬 편리해질 것이다.피드백 03:07, 2009년 9월 6일 (UTC)[응답]

Commons를 검색하십시오.유사한 효과에 사용되는 카테고리(예: 카테고리:버락 오바마 --사이버코브라 (대화) 03:37, 2009년 9월 6일 (UTC)[응답]

범주는 같지 않다.그리고 모든 사진이 위키미디어 커먼스에 있는 것은 아니다.피드백 12:31, 2009년 9월 6일 (UTC)[응답]

하지만 범주는 당신이 찾고 있는 것이어야 한다.
— V = I * R (Ω과 대화) 13:27, 2009년 9월 6일 (UTC)[응답]

결과적으로 "합의 없음"과의 토론 삭제

삭제 대상으로 지목된 글도 있고, 리울트는 '합의 없음'이다.그렇다면 우리에게 기사를 보관하는 기본 위치에 대한 정보를 제공해야 하는가?ACEOREVIVEED (토크) 21:28, 2009년 9월 3일 (UTC)[응답]

어떤 정보를 찾으십니까?— 당신을 먹여 살리는 손:^Bite 22:51, 2009년 9월 3일 (UTC)[응답]

예를 들어, 밥 태거트에 관한 기사를 보고 토크 페이지로 가면 2009년 8월에 삭제 후보로 지명되었다는 것을 알 수 있다; 토크 페이지의 태그에는 "토론의 결과는 합의되지 않았다"라고만 쓰여 있다.필자는 정말로 이 태그가 수정되어야 한다고 말하는 것 같은데, 그래서 "논의 결과는 합의되지 않았고, 따라서 그것이 기본 입장이기 때문에 기사가 유지되고 있다"는 취지의 말을 해야 한다.ACEOREVIVEED (토크) 23:09, 2009년 9월 3일 (UTC)[응답]

그건 기사가 삭제되지 않은 것에 의해 암시된 것이 아닌가?미스터 지만 23:32, 2009년 9월 3일 (UTC)[응답]

[분쟁의 편집] 나는 일반적으로 (-fD 논의뿐만 아니라) 구체적이고 명확한 변화에 대한 명확한 합의가 모일 수 없을 때 편향은 안정에 유리하여 아무런 조치도 취하지 않는다고 생각한다.[한 가지, 유진 5세에게 반향하는 것. 뎁스가 노동자들을 약속된 땅으로 인도하기를 거부하는 것은, 확실한 합의 없이 어떤 것이 한 방향으로 쉽게 변화할 수 있다면, 그것은 탁구나 편집 전쟁의 확대된 합법적인 변동을 초래하는 것처럼 쉽게 다른 방향으로 되돌아갈 수 있다.]내가 다른 편집자와 마찬가지로 바꾸고 싶은 것이 많지만, 현재 상태를 유지하기를 원하는 사람들에게 책임이 있는 것은 (WP:소유권에도 불구하고) 보다는 혁신자들에게 있다.그러나 그것은 좀 더 실용적인 것을 묻고 있을 때 아마 철학적인 지적일 것이다.—— Shakescene (대화) 23:46, 2009년 9월 3일 (UTC)[응답]

템플릿({{oldafdfull}})은 "결과=" 매개변수를 사용하며, 결과는 우리가 원하는 것이기에 대대적인 편집 없이는 기존 매개변수를 변경할 수 없었다.그들은 양식으로 연결되어 있다.{{oldafdfull page=<pagename> date=<date of nom> result='''keep'''}}대화 페이지에 쉽게 복사/붙여넣기 위한 뒷면 태그 아래그래서 그것은 우리가 어떤 식으로 진행하든 약간의 이익에는 너무 많은 비용이 들 것이다.세나륨 (대화) 00:01, 2009년 9월 4일 (UTC)[응답]

(만약 내가 정확하게 이해한다면, 보장되지 않는다면) 템플릿에 약간의 조작-포커리를 추가하여 입력 매개 변수와는 다른 것을 표시할 수 있을 것이다.{{#ifeq:{{{result}}} '''No consensus''' '''No consensus[1]''' {{{result }}}}} ?) 오버헤드를 약간 추가할 수 있지만 최종적으로는 한 번의 편집이 될 수 있다. - Jarry1250^{[ In the UK? Sign the petition! ]} 19:06, 2009년 9월 4일(UTC)[응답]

고마워 재리 1250, 그게 바로 내가 염두에 둔 거야."합의 없음 - 결과 = 기사 유지(기본 위치)"와 같은 템플릿은 현재 존재하는 것보다 더 유용한 정보가 될 것이며, 중요한 편집 변경을 요구하지 않을 것이다.ACEOREVIVEED (토크) 23:13, 2009년 9월 4일 (UTC)[응답]

템플릿에서 이론이 작동하는지 테스트하기 위해 간단한 모의실험을 했다.Oldafdfull/sandbox - 하지만 그것에 대한 모든 것은 바뀔 수 있다.도움이 되길 바라며, - Jarry1250^{[ In the UK? Sign the petition! ]} 18:12, 2009년 9월 5일 (UTC)[응답]

나는 이것이 명료함에 어떻게 도움이 될 수 있는지 알 수 있다.그러나 나는 그 표현이 옳다고 생각하지 않는다.우리의 기본 입장이 '지키기'라고 말하는 것은 공식적인 입장과 너무 흡사하다.위에서 말한 것처럼 "합의가 없다"는 것은 그냥 내버려 두라는 뜻이다."유지"로서의 폐쇄는 기사가 가치가 있다는 미래의 증거로 보유될 수 있는 반면, "합의가 없다"는 것은 합의가 이루어지지 않았다는 것을 의미하며, 여전히 합리적으로 기사를 삭제하거나 보관할 수 있다.아마도 본문은 '* 이것은 기술적으로는 "지속" 합의와 동일하지만, 그렇게 간주되어서는 안 된다'와 같은 것을 서술해야 할 것이다.따라서 그것은 그 결과가 기사를 보관하는 것이 아니라, 물리적으로 그 기사는 "지킨" 결과가 나타날 때와 같은 상태에 있다고 말한다.

나는 그것이 훌륭하게 설명되지 않았다는 것을 알고 있다.하지만 사람들은 내가 무슨 말을 하는지 알까?그레그 타일러22^{(t • c)}:17, 2009년 9월 7일 (UTC)[응답하라]

나는 어떤 합의도 아무것도 하지 않거나 아마 삭제하지 않는 것을 의미하지 않는다는 것에 동의한다.나는 WP를 가리키며 본문에 대한 설명 링크를 지지할 것이다.삭제 조항#어떻게 AfD 토론이 종결되었는가.WP:삭제 지침#합의가 없다는 설명이 추가될 경우 권고사항 및 결과가 대안이다.플랫스캔 (토크) 04:11, 2009년 9월 8일 (UTC)[응답]

마인드 맵

마인드 맵을 만들 때 "여기서 어떤 링크"와 "여기서 어떤 링크" 정보를 사용하면 좋을 것 같아.독자는 자신이 얼마나 많은 "연결 수준"에 관심이 있는지 명시하기만 하면 될 것이다.예를 들어, 나는 모든 "여기 링크된 것"과 현재 페이지에서 링크된 최대 두 단계의 기사, 즉 미들레에 현재 페이지가 있는 지도, 현재 페이지에 링크된 페이지, 현재 페이지에서 연결된 페이지("수준 1"에서 링크된 페이지) 및 이들로부터 연결된 페이지("수준 2"에서 링크된 페이지)를 보고 싶다.안샤 (토크) 2009년 9월 6일 (UTC) 12:22 [응답]

오, 오!이 프로포즈를 이용해서 케빈 베이컨의 기사로 7도 게임 할 수 있을까?!"케빈 베이컨과 중력을 연결하기 위해 몇 개의 기사를 사용할 수 있는가?"그것은 나에게 재미있는 게임처럼 들린다.카멜빈키 (대화) 2009년 9월 6일 (UTC) 17:58 [응답]

뭔가 기억나는 것 같은데, 아마 오프사이트 도구일 거야. 네가 그걸 할 수 있게 해주는.♫ 멜로디아 샤콘네 ♫ (토크) 18:08, 2009년 9월 6일 (UTC)[응답하라]

위키백과 게임의 6도(구글 it)가 있지만, 약간 시대에 뒤떨어지고, 이것과는 다른 AFAIK. - Jarry1250 18:09, 2009년 9월 6일 (UTC)[응답]

좋아, 난 위키백과 6학위 프로젝트가 좋아.하지만, 나의 동기는 "마인드 맵" 즉, 개념들 간의 연관성을 보여주는 그림을 얻는 것이다.링크 구조는 한 기사에서 다른 기사로의 평균 거리 약 4.5(2008년 3월 기준)로 이것이 처음 몇 단계에서만 작동한다는 것을 분명히 하지만, 이것을 큰 정도로 반영해야 한다.그럼에도 불구하고, 그것은 자연과학의 특별한 주제에 관한 기사들 사이의 링크와 같은 좀 더 전문화된 분야에서 잘 작동할 수 있을 것이다.아마도, 마인드맵은 카테고리로 나누는 것과 같은 위키 기사의 좀 더 정교한 목록으로부터 만들어질 수 있을 것이다.안샤 (대화) 09:44, 2009년 9월 7일 (UTC)[응답]

이것이 WP:Ophans ?—— Shakescene (대화) 10:19, 2009년 9월 7일 (UTC)[응답]을 식별하는 데 도움이 될까?

체크 사용 중인 사용자에 대한 추가 개인 정보 및 권한

검사 대상이며, 삭푸펫 계정을 가지고 있다는 비난을 받고 있는 사용자는 금지/차단되었을 때 더 많은 사생활과 자신들을 방어할 권리를 가져야 한다.그 순간 그러한 사용자들은 아무런 경고 없이 차단되고 금지되며 모든 사람들이 볼 수 있도록 그들의 개인 정보를 표시하게 된다.그들은 그들 자신을 편집하거나 방어할 수도 없다.

제 제안은 다음과 같다.

1. 관련 IP-info 등 개인정보에 대해 더욱 신중(편집용으로도 사용)

2.) 그들 자신을 방어할 수 있도록 그들의 토크 페이지를 편집할 권리.—서명되지 않은 의견을 7853hgh (대화 • 기여) 2009년 9월 7일 14:12, 14:7

나는 우리가 행동 문제를 해결하는 것과 관련이 없는 한 사적인 정보를 주지 않는다고 생각한다.그리고 일반적으로 사람들은 그들의 토크 페이지를 남용한 이력이 없는 한 편집할 수 있다.만약 이 일이 당신에게 일어났다면, 당신은 이 일이 일어난 곳을 링크할 수 있는가?칠음 14:16, 2009년 9월 7일 (UTC)[응답]

그들의 사적인 정보는 모든 사람들이 볼 수 있도록 표시되지 않으며, 극단적인 경우를 제외하고, 차단된 편집자들은 자신의 토크 페이지에서 자신을 방어할 수 있다.즉, Checkuser 정보는 그들의 IP 이상의 것을 포함한다; CU는 약한 증거에 근거하여 조치를 취하지 않을 것이다.EVULA // talk // talk // 16:14, 2009년 9월 7일 (UTC)[응답]

• 공개:나는 checkuser 권한이 있지만 en.wp에서는 없다.

WMF 개인 정보 보호 정책은 기록된 사용자 정보에 대한 매우 강력한 보호를 제공한다.익숙해?그게 뚫렸다고 믿을 만한 이유가 있어?그렇지 않다면, 당신은 그것이 '조용한' 것과 관련하여 부족하다고 어떻게 특성화할 것인가?

내가 알기로는, 대부분의 사용자별 블록은 사용자가 자신의 토크 페이지를 계속 편집할 수 있도록 허용한다.이러한 예의는 토크 페이지가 남용에 사용되는 곳에서는 연장되지 않으며, 또는 남용에 사용될 것이라고 가정할 만한 충분한 이유가 있다.

체크 사용자 도구가 제공한 데이터의 도움을 받아 삭푸펫을 탐지하는 것은 꼭두각시 인형사가 흔적을 감추기 위해 상당한 노력을 기울이지 않는 한 특별히 어렵지 않다.사용자 기여 이력과 같은 공개 가능한 정보와 결합되어 있음을 기억하십시오. --Brian ^talkMcNeil / 17:58, 2009년 9월 7일 (UTC)[응답]

템플릿의 Wikinews에 링크를 추가하기 위한 제안:최근 죽음

{{Recent death}}}}의 Wikinews 기사에 링크를 추가하자는 제안.Template_talk를 참조하십시오.Last_death#Option_link_to_a_Wikinews_obitury.시간 내주셔서 감사합니다, Cirt (대화) 17:25, 2009년 9월 7일 (UTC)[응답]

wikipedia 위키백과 편집자의 동기와 특징에 관한 설문지

안녕하십니까.

정부 산하기관인 한국정보화진흥원(KISDI)이 위키백과, 야후답스 등 집단정보 사이트 참여자들의 문화적 특성과 기여 동기에 대한 연구를 실시한다(우리 연구소에 대한 자세한 정보는 www.kisdi.re.kr 참조).

이 조사는 위키백과 사용자의 사용과 참여에 영향을 미치는 요인을 식별하는 것을 목표로 한다.당신의 답변은 절대적으로 기밀이며 집단 지성에 대한 우리의 이해를 넓히는 데에만 사용될 것이다.우리는 집단지성을 장려하기 위한 정책을 만드는 데 도움이 될 당신의 응답을 믿는다.

설문조사를 완료한 사람에게는 소형 아마존 상품권이 제공된다.

전적으로 협조해주셔서 감사하다.

진심으로

황주성 수석연구위원 융합미래전략연구부

전자우편 수정됨

→클릭

문의 사항에 연락처 세부 정보를 포함하지 마십시오.우리는 어떤 오프위키 매체로도 답을 제공할 수 없으며, 이 페이지는 인터넷을 통해 매우 잘 보인다.자세한 내용은 삭제되었지만 페이지 기록에서 영구히 삭제하려면 이 주소를 이메일로 보내십시오.--Unionhawk 01^E-mailReview:19, 2009년 9월 8일(UTC)[응답]

순수 반달리즘 편집

나는 단지 순수한 반달리즘 편집들을 페이지 편집 역사에서 그렇게 표시할 수 있다면 좋을 것이라고 생각하고 있었다.그에 대한 이점은 시청자가 원할 경우 그러한 편집 내용을 숨길 수 있는 능력일 수 있다(단순 편집이나 봇 편집과 같은 방식으로 "숨길 수 있다").
— V = I * R (Ω과 대화) 07:31, 2009년 9월 3일 (UTC)[응답]

누가 편집한 내용을 공공 기물 파손으로 표시하겠어?시솝은 너무 적지만 모두가 할 수 있다면 남용될 것이다.롤백 능력을 바탕으로?쉽게 악용될 수 있는 그런 것 같다.~ 아모리(사용자 • 대화 • 기여) 13:57, 2009년 9월 3일 (UTC)[응답]

관리자가 이 편집 버튼을 볼 수 있도록 편집 페이지에 플래그를 표시하십시오.Acdude92 (대화) (사인) 14:03, 2009년 9월 3일 (UTC)[응답]

(충돌 편집)그것은 단지 관리자들에게는 더 많은 일이고, 그럴 가치도 없다.또한, 만약 그것이 롤백에 기초한다면, 당신은 그것을 음습하게 사용하는 것을 놓칠 것이다.음, 2009년 9월 3일 (UTC) 14:05 (응답)

사용자 권한만 등록하고 반달 처리 능력만 가진 새로운 집단일 수도 있어Accdude92 (토크) (사인) 14:10, 2009년 9월 3일 (UTC)[응답]

여기 전에 이런 사고 과정을 본 적이 있어나는 이것이 어떻게 악용될 수 있는지 잘 모르겠다. 그러면 더 이상 "최소 편집" 깃발이 남용될 수도 있고 남용될 수도 있다.모든 사람들은 항상 새로운 기능들을 어떤 선택된 그룹이나 다른 그룹으로 제한하기를 원하는 것 같은데, 나도 이해할 수 없다.아, 그렇구나.
— V = I * R (Ω과 대화) 14:13, 2009년 9월 3일 (UTC)[응답]

사소한 편집 논쟁은, 더 나은 단어가 부족하기 때문에, 사소한 것이다.그러나 이 경우 편집한 내용을 반달리즘, 특히 반달리즘으로 표시함으로써 달성될 t3h ePIC LULZ를 쉽게 예측할 수 있다.~ 아모리 (사용자 • 대화 • 기여) 2009년 9월 3일 (UTC) 17:24 [응답]

솔직히 왜 그런지 모르겠어...내가 상상하는 걸 제대로 설명하지 않는 건 아닐까?그것이 할 수 있는 모든 것은 지금 소조기가 하는 일인데, 그것은 기본적으로 아무것도 아니다.특정 편집이 표시되든 아니든, 아니면 전체 편집이 표시되든 간에, 실제로 그 깃발을 무의미하게 만드는 것 외에 실질적인 영향은 없을 것이다.

우리가 주제를 다루는 동안, 작은 깃발을 편집할 수 있는 것도 좋을 거야.나는 내가 그것을 클릭하는 것을 잊었거나 실수로 여러 번 클릭했다는 것을 알고 있고, 어떤 사람들은 항상 또는 절대 사용하지 않을 것이라는 것을 알고 있기 때문에, 그들을 편집할 수 있다는 것은 대부분의 경우 그들의 효용성을 증가시킬 것이다.나만의 편집 요약을 편집할 수 있다는 것도 정말 좋을 거야.
— V = I * R (Ω과 대화) 17:34, 2009년 9월 3일 (UTC)[응답]

차이점은 사람들은 자신의 편집 내용을 사소한 것으로만 표시할 수 있다는 것이다.우리가 공공 기물 파손자들이 그들 자신의 편집 내용을 공공 기물 파손으로 표시하기를 기대하지 않는다면, 이것은 사람들이 다른 사람들의 편집 내용을 공공 기물 파손으로 표시할 수 있다는 것을 의미할 것이다.Mr.Z-man 17:38, 2009년 9월 3일 (UTC)[응답]

이 경우 그것은 전혀 불필요한 작업이며 일관성 없이 적용될 것이다.–xeno^talk 17:40, 2009년 9월 3일 (UTC)[응답]

그 문제에는 쉬운 "수정"이 있다(위 사항을 이슈로 보지 않기 때문에 인용문에 인용하지만, 많은 사람들이 그렇게 한다는 것을 인정하기 때문이다).실행 취소 기능에 "반달리즘 플래그" 사용을 연결하십시오.순수한 반달리즘 편집은 거의 항상 취소되기 때문에, 이것은 나에게 분명한 선택인 것 같다.
— V = I * R (Ω과 대화) 17:59, 2009년 9월 3일 (UTC)[응답]

우리가 해야 할 일은 모든 사람들에게 되돌릴 수 있는 능력을 주는 것이다. (글쎄, 모든 확증된 사용자나 그것을 요구하는 모든 사람들 - 그리고 사람들이 그것을 요구하도록 강하게 격려하지만 그것을 남용하는 소수자들로부터 그것을 빼앗는 것이다.)그러면 우리는 공공 기물 파손에 대처하는 표준적인 방법을 롤백할 수 있고, 기물 파손에 대한 편집으로 롤백할 수 있다.이 기능은 여기서 제안된 대로 감시 목록 및 편집 기록 필터링, 반달 자동 추적/경고/차단 차단 등 모든 용도로 사용될 수 있다. 단, 편집 내용이 많이 롤백되었다는 이유만으로 자동 블록은 분명히 없다.분명히 당신은 모든 WP 기능에서 그렇듯이 가끔 오용을 당하겠지만, 그것이 그러한 혜택을 제공할 수 있을 때 그것을 하지 않을 이유가 될 수는 없다.-코트니스키 (토크) 17:48, 2009년 9월 3일 (UTC)[응답]

이 솔루션이 해결하고자 하는 문제가 있는가?–xeno^talk 17:55, 2009년 9월 3일 (UTC)[응답]

응, 그런 것 같아.롤백이 무엇인지 정확히 알 수 없다. 쉽게 여러 번 되돌리는 것이 내가 가진 최고의 감각이다.나의 유일한 진짜 걱정은 그것이 투명하지 않다는 것이다.누구나 역사 속에서 반전을 볼 수 있고, 나는 그것이 그래야 한다고 생각한다.난 그저 그들이 방해하는 것이 전부일 때 그들을 역사 속에 숨길 수 있는 방법을 원할 뿐이다.
— V = I * R (Ω과 대화) 17:59, 2009년 9월 3일 (UTC)[응답]

코티스키의 제안은 통하지 않았다.네이티브 롤백은 반달리즘(bandalism)을 제외한 다른 많은 것에 사용된다(예를 들어, 로봇이 잘못되고, 일부 사람들은 다양한 편집 요약을 바꾸는 스크립트를 사용하여 실행 취소 대신 롤백을 사용한다).하고 싶은 일을 하기에는 너무 복잡한 것 같아.롤백에 묶였더라도 롤백 편집도 숨길 수 있어야 하지 않을까?–xeno^talk 18:06, 2009년 9월 3일 (UTC)[응답]

(갈등 편집) 응, 그런 것 같아.분명히 내가 원하는 것은, 그리고 내가 항상 필요하다고 생각하는 것은, 멍청한 깃발뿐이다.누가 다른 사람의 게시글의 깃발을 편집할 수 있다고 해도 정말 해롭지는 않을 것이다.그것은 그 페이지의 편집 이력에 깃발을 사용하는 것을 다소 무의미하게 만들 수도 있지만, 그것은 사실 큰 문제가 아니다.그것이 내가 정직하게 보지 않는 이유이기도 하다.반달과 트롤이 항상 원하는 노출이 없을 뿐이지
— V = I * R (Ω과 대화) 18:18, 2009년 9월 3일 (UTC)[응답]

(1) 롤백은 역사상 언도스 만큼이나 볼 수 있다. (2) 롤백 편집 내용을 숨기는 옵션이 있었다면, 아마도 롤백 편집 내용을 숨기는 것을 포함할 것이다(이것은 분명히 개발자들이 우리보다 생각할 만한 것이다).(3) 분명히 소프트웨어는 롤백된 편집이 봇에 의해 만들어졌는지 여부를 감지하고 그에 따라 조정할 수 있다. (4) 누군가가 편집 요약을 변경하면 소프트웨어가 그것을 쉽게 감지할 수 있다. (5) 복잡하지 않다. - 훨씬 더 간단해질 것이다(글쎄, 그것은 개발자들에게 편집자에게 훨씬 더 간단한 작업을 할 수 있는 수단을 제공할 것이다. - 반달스 콜d 자동으로 경고/경고되므로, 우리는 더 이상 그것에 대해 걱정할 필요가 없다.(6) 몇 가지 사소한 우려는 처음부터 "이 제안이 통하지 않을 것"이라고 바로 말할 이유가 없다.--코트니스키 (토크) 18:15, 2009년 9월 3일 (UTC)[응답]

이크..."vandals는 자동으로 경고/보고될 수 있다." 지금 나는 우리가 실제 잠재적인 학대 영역에 들어가고 있다고 생각한다.어떤 얼간이들이 막히기 전에 100명을 태그하고 소란을 피우는 것을 상상할 수 있었다.
— V = I * R (Ω과 대화) 18:21, 2009년 9월 3일 (UTC)[응답]

이것은 매우 사소한 이익만을 가지고 복잡한 상호작용의 많은 층을 도입한다.–xeno^talk 18:23, 2009년 9월 3일 (UTC)[응답]

나는 잠재적 이득이 복잡성이라는 주장보다 훨씬 더 크다고 생각한다. (어쨌든 그것은 복잡성이 아니라 충격, 공포, "우리가 익숙하지 않은 것"이다.)그리고 묘사된 사건의 "업포"는 경미할 것이다. - 그렇게 하도록 내버려두어라. 50개의 기사를 파기하도록 하는 것보다 낫다. (그리고 우리는 여기서 무작위 IP가 아닌 확증된 계정을 자동화하는 것에 대해 이야기하고 있기 때문에, 매일 그렇게 되지 않을 것이다.)---코트니스키 (토크) 12:55, 2009년 9월 4일 (UTC)[응답]

나는 미디어위키 개발자들에게 우리가 요구해야 할 변화의 복잡성에 대해 이야기하고 있었다.–xeno^talk 14:39, 2009년 9월 5일 (UTC)[응답]

이 생각도 내 마음에 스쳤다는 것을 인정해야겠다.그것이 사실 내가 여기서 제안하고 있는 이점에 대한 이점 중 하나이지만, 국기 발상을 구현하는 것은 꽤 간단해야 한다.데이터베이스 테이블에서 비트 필드를 추가하는 것과 함께, 기본적으로 마이너 플래그에 대한 기존 기능의 복사본일 뿐이다.그렇게 하는 데 근본적인 문제가 있을 가능성이 있고, 만약 그것이 사실로 밝혀진다면 기꺼이 받아들이겠지만, 어쩐지 의심스럽다.반면에 롤백은...그건 완전히 다른 밀랍 인형이야
— V = I * R (Ω과 대화) 15:05, 2009년 9월 5일 (UTC)[응답]

하지만 실제로는 그렇지 않다. 단지 기존 기능을 사용하여 당신의 제안을 실행하는 것이다. (롤백 버튼은 반달리즘 깃발일 수 있다.)유일한 문제는 롤백은 지켜야 할 중요한 특권이라는 WP 미신을 극복하는 것이다.어쨌든, 당신의 버그 리포트에 투표할 겁니다.--코트니스키 (토크) 16:28, 2009년 9월 5일 (UTC)[응답]

롤백 도구는 이미 태그를 사용하여 일부 롤백을 "반달리즘"으로 표시하지 않는가?개인적으로, 롤백과 관리 도구에 대한 접근은 상당히 자동적이어야 한다고 생각하지만, 그것은 전혀 다른 문제다.이 문제를 제기하는 데 있어서 나의 주된 생각은 단지 비교적 단순하고 논란의 여지가 없는, 그러한 편집에 표시를 하고 "히딩"하는 수단("사소한 편집이나 봇 편집이 현재 있을 수 있는 것처럼 그것들을 가리는 능력에서")을 추가하는 것이었다.나는 네가 어디로 가는지 알 수 있고, 나는 별로 동의하지 않지만, 나는 단지 그런 종류의 제안이 "정치적으로" 어디로 가는지 볼 수 없을 뿐이다.나는 이것이 적어도 기회가 있고, 심지어 앞으로 통계적으로 유용하다는 것을 증명할 수도 있다고 생각한다.
— V = I * R (Ω과 대화) 16:56, 2009년 9월 5일 (UTC)[응답]

개선 요청 작성

어쨌든, 그 제안은 우리가 게시물에 추가할 수 있는 작은 깃발처럼 단순한 깃발을 추가하는 것이다.간단한 구현은 실행 취소 기능을 사용할 때 사용할 수 있도록 하는 것이다(편집 실행 취소 표시).구현이 더 많이 개입될수록 편집 페이지에 체크박스를 갖도록 요청하는 것이 될 것이다(이러한 이름은 무엇일지 모르겠지만, 페이지 기록에서 편집 날짜 링크를 클릭할 때 표시되는 버전).그 페이지에는 실제로 "소규모"와 "반달리즘" 둘 다에 대한 확인란이 포함될 수 있고, 만약 그것이 당신 자신의 편집이라면, 요약도 편집할 수 있을 것이다.
— V = I * R (Ω과 대화) 18:33, 2009년 9월 3일 (UTC)[응답]

응, 롤백 대중화를 바탕으로 한 위의 좀 더 광범위한 아이디어와는 별개로, 좋은 생각인 것 같아. --Kotniski (토크) 12:55, 2009년 9월 4일 (UTC)[응답]

버그#: 20510은 특히 "반달리즘 깃발"을 신청했다.어쩌면 어딘가로 갈 수도 있고, 아닐 수도 있고...작은 일이지만 좋을 것 같아.
— V = I * R (Ω과 대화) 05:25, 2009년 9월 5일 (UTC)[응답]

또 다른 가능한 합병증

나는 많은 편집 요약에서 "RVVV"나 "반달리즘"을 본 적이 있는데, 사실 그것은 되돌린 항목이 아니었다.때로는 순전히 의견의 불일치나 차이, 때로는 되돌린 편집자가 다른 단위나 철자법을 사용하기도 하고, 때로는 그 편집자가 다른 사실의 출처를 가지고 있기도 했다(때로는 더 최근에, 때로는 더 나이 들어, 때로는 그냥 다른).흔히 일반 독자(그리고 따라서 가장 최근의 편집자-but-one)에게 명백하게 보이는 것이 토크 페이지의 확대된 토론에 걸쳐 부정확하거나 부정확하게 보여지지만, 그렇다고 해서 되돌린 편집이 선의로 이루어지지 않았다는 뜻은 아니다.그 반전은 당연히 정당화될 수 있지만, 되돌린 것이 반드시 반달리즘은 아니었다.—— Shakescene (대화) 20:03, 2009년 9월 3일 (UTC)[응답]

맞아, 나도 같은 문제를 본 적이 있어.나는 단지 어떻게 그것이 이 제안이 다루어야 할 중요한 문제인지 모르겠다.나는 사람들이 부 편집 깃발을 끊임없이 "오용"하는 것을 보지만, 그것은 (적어도 나에게) 그것을 제거할 이유는 아니다.
— V = I * R (Ω과 대화) 03:23, 2009년 9월 4일 (UTC)[응답]

그렇군. 언젠가 누군가가 그것을 남용하거나 오용할 수도 있다고 해서 새로운 기능을 위한 모든 제안을 버려서는 안 돼.-코트니스키 (토크) 12:55, 2009년 9월 4일 (UTC)[응답하라]

"최소 편집" 깃발과 유사한 "반달리즘 역전" 깃발을 구현하는 것이 좋을 수 있다.한편, 학대의 위험은 (불신임 가정과 큰 분쟁으로 이어질 수밖에 없는)...–Juliancolton 01:44, 2009년 9월 5일 (UTC)[응답]

그것은 아주 미세하고 흥미로운 점이다.아마도 V기가 있었다면 편집자들은 "RVV"를 "반전"의 만능 약어로 사용하면서 게으르거나 부주의하게 사용하는 것을 멈추고 그것이 정말로 반달리즘인 것처럼 보일 때 "반달리즘" 깃발을 두드렸을 것이다.반면에, 간단한 체크박스가 어떻게 문제를 악화시킬 수 있는지 보는 것은 똑같이 쉽다.—— Shakescene (대화) 04:04, 2009년 9월 7일 (UTC)[응답]

롤백은 또한 이론적으로 이것을 촉발시켜야 한다- 그것은 단지 노골적인 파괴 행위(또는 당신 자신의 토픽 페이지에 편집 내용을 되돌리는 것과 같은 다른 논란의 여지가 없는 작업)를 되돌리는 데만 사용되어야 한다. 정상적인 상황에서는 편집 요약을 추가할 수 없기 때문이다. --Euomie 19:44, 2009년 9월 8일 (UTC) 응답하라.

소개 페이지에서 샌드박스 기능 제거

{{unanswered}}}

나는 위키피디아에 대해 말하고 있다:소개, 새로운 사용자를 환영하는 페이지.그 페이지는 샌드박스 기능을 가지고 있다. 다시 말해, 사용자는 인트로 템플릿이 그대로 유지되는 한 그곳에서 자유롭게 시험 편집을 할 수 있다.유감스럽게도 그렇지 않다. 그리고 새로운 편집자들은 "이러한 위키백과는 sux0rz haxd" 또는 "Get that works online www.fakesite.com"의 줄에 따라 어떤 것으로 환영 받을지도 모른다.이것은 대부분 무능하고 실제 반달리즘이 아닌 페이지의 목적을 오해하는 것이지만, 새로운 사용자가 볼 때 페이지가 보이는 것처럼 보이도록 하기 위해 이 페이지에서 샌드박스 기능을 완전히 제거할 것을 제안한다.물론 새로 온 사람들을 위한 샌드박스 페이지가 있는 것이 좋으니 현재의 샌드박스 템플릿을 위키피디아를 가리키도록 편집하는 것이 좋다.소개_2 ("편집 자세히 알아보기"라는 제목이 붙어서) 새로운 편집자는 소개의 다음 페이지를 찾을 필요가 없거나 첫 번째 소개 페이지와 두 번째 소개 페이지 사이에 새 샌드박스 페이지를 작성할 필요가 없다.지지, 의견, 제안은?코티왈로 (토크) 2009년 8월 19일 (UTC) 19:03 [응답]

나는 그러한 변화에 격렬히 반대할 것이다.내 생각에, 그들이 위키피디아에 도달했을 때 독자와 편집자 모두에게 가능한 한 격려하고 솔직하게 말하는 것은 정말 도움이 된다.WP에 대한 링크:소개는 메인 페이지에서 더 두드러져야 한다.누군가 더 많은 연결고리를 따라야 할수록, 그녀나 그는 실제로 연결고리를 따라갈 가능성이 더 적다.그래, 거기엔 공공 기물 파손이 있지만, 대부분은 실제로 사람들이 위키피디아를 구부리고 그들의 경계를 시험하는 것에 불과해.게다가, 대부분의 다른 지역들과는 달리, 그것은 실제로 누군가를 크게 해치지 않는다.샌드박스로 망치는 건 다음 남자에겐 더 안 좋아지지만 그렇다고 명예훼손이 되는 건 아니야.~ 아모리(사용자 • 대화 • 기여) 01:43, 2009년 8월 20일 (UTC)[응답]

그렇다, 샌드박스를 가지고 장난치는 것은 큰 문제가 되지 않을 것이다. 하지만 그것은 또한 우리의 소개 페이지이기도 하다. 그리고 많은 새로운 편집자들이 우연히든 의도적으로든 환영 템플릿을 지웠기 때문에, 우리의 새로운 편집자들이 불경스럽거나 특별히 환영받지 못하는 내용들로 환영받을 가능성이 크다.환영 템플릿이 실수로, 또는 불신임으로 삭제되지 않도록 하는 방법이 있다면 그 만큼은 문제가 되지 않을 것이다.코티왈로 (토크) 09:53, 2009년 8월 20일 (UTC)[응답]

12시간마다 적절한 내용으로 페이지가 새로 고쳐지도록 샌드박스 헤더와 같은 것을 추가해 보는 것은 어떨까?워리어4321 22:00 2009년 8월 20일 (UTC)[응답]

인트로 페이지에 있는 것 같은데, 템플릿이 온전하게 유지되도록 매번 편집한 후에 청소해야 하고, 그렇게 하면 샌드박스의 전체 포인트가 없어질 것이다.페이지 분리하는 게 좋을 것 같아.코티왈로 (토크) 05:41, 2009년 8월 21일 (UTC)[응답]

페이지를 분할하여 한 부분(또는 섹션)이 반보호되고 다른 부분은 12시간마다 지워지도록 할 수 있는 방법이 있는가?워리어4321 17:47, 2009년 8월 21일 (UTC)[응답]

나는 방법이 있다고 확신하지만 그것이 너무 빨리 끝나지는 않을 것이라고 확신한다.코티왈로 (토크) 2009년 8월 21일 18:23 (UTC)[응답]

다른 페이지(샌드박스 헤더와 같은)에 소개가 있는 페이지를 만든 다음, 그 페이지 안에 그것을 섞은 것을 초월하는 것이 아닐까?망사 바로 옆에 눈에 보이지 않는 댓글을 달아서 그냥 두라고?그렇게 되면 훨씬 더 많은 공간을 어디서 편집해야 할지 모르는 새로운 사용자들을 제공할 수 있을 것이다.워리어4321 19:22, 2009년 8월 21일 (UTC)[응답]

실제로 소개 페이지에는 다음이 있다.
{{이 선은 그냥 두십시오}}
<!-- 이 줄 아래의 텍스트를 얼마든지 바꿔라.불경스러운 짓은 하지 말아 주시오. -->
안타깝게도, 이것이 항상 효과가 있는 것은 아니다.코티왈로 (토크) 08:11, 2009년 8월 22일 (UTC)[응답]

(outdent)나는 최근에 소개 페이지를 보고 있어.그것이 어떻게 시작되었는지 모르지만, 나는 정기적으로 새로운 사용자들의 기여를 확인하고 불쾌하거나 미숙한 편집을 되돌린다.우리가 새로 온 사람들에게 인사하기 위해 사용하는 메시지가 일상적으로 완전히 터무니없는 것으로 파괴된다는 것이 나를 화나게 하기 시작했다.위키피디아는 케첩 방귀에 대해 읽을 곳이 아니며, 적어도 메인 페이지는 그렇지 않다.

WP 편집 페이지:소개는 WP:Sandbox 편집을 위한 페이지로 리디렉션된다.이렇게 하면 새 사용자가 방금 읽은 메시지를 무시하는 대신 소개문을 읽고, 여전히 편집을 클릭하고, 샌드박스를 편집할 수 있다.WP:그 후 도입부는 편집으로부터 보호될 수 있다. - oooʏiaɲ 14_¢:01, 2009년 8월 22일 (UTC)[응답]

나는 그 아이디어가 정말 마음에 들어! 혹시 우리가 어떻게 편집 버튼을 편집할 수 있을까?워리어4321 19:11, 2009년 8월 22일 (UTC)[응답]

그렇게 하는 게 어때?{{doc}}보호 템플릿에 대한 작업(이 경우 샌드박스를 보호된 소개 페이지로 대체하여).이렇게 하면 메시지는 그대로 유지되며, "이 페이지 편집" 탭이 제대로 작동하지 않지만, 바로 옆에 특별한 편집 링크를 가질 수 있다.아마도 Levelbot과/또는 그의 친구들이 그것을 멈추기 위해 불경스러운 행동을 하도록 샌드박스를 가볍게 순찰하게 할 것이다. --Thinboy00 @117, 즉 01:48, 2009년 8월 29일 (UTC)[응답]

이것이 무시되고 보관된 이후, 그리고 새로운 사용자의 첫인상을 실제로 개선할 수 있는 매우 논리적이고 실행하기 쉬운 아이디어이기 때문에 재등록. - -oooʏiaɲ 01_¢:59, 2009년 9월 7일 (UTC)[답글]

나는 샌드박스를 보호된 페이지로 통합하는 것이 어떻게 도움이 될지 모르겠다 - 내가 볼 수 있는 한 사용자들은 여전히 편집/저장할 수 없을 것이다.우리는 편집 고지와 청소 봇을 사용할 수 있다; 우리는 또한 소개 페이지가 사람들이 저축하도록 해야 한다는 생각을 다시 할 수 있다; 사람들에게 샌드박스에 더 많은 테스트를 받으라고 말하지 않아도 된다, 충분할까?Rd232^talk 08:20, 2009년 9월 7일 (UTC)[응답]

내가 볼 수 있는 한 템플릿 설명서는 링크를 보호된 페이지로 변환하여 편집 모드의 샌드박스로 이동한다.WP:소개에는 이미 그러한 연결고리가 있기 때문에, 그것을 보호하는 것만이 필요할 것이다.그러나 그것은 "이 페이지 편집" 예제 기능을 위반한다."이 페이지 편집" 단추를 다른 페이지를 편집하도록 할 수 있는 방법은 없으십니까?물론 아니지.한 페이지에 버그를 넣을 만한 가치가 있는가?확실하진 않다.Rd232^talk 15:01, 2009년 9월 7일 (UTC)[응답]

그것이 내가 WP 편집을 위한 페이지를 위와 같이 제안한 이유다.소개는 WP:Sandbox 편집 페이지로 리디렉션. - ʄooʏiaɲ^τ_¢ 16:48, 2009년 9월 7일 (UTC)[응답]

이해가 안 돼위키백과의 경우:소개 담당자는 [7]과 같은 링크를 클릭하지 않고 [이 페이지 편집] 단추를 클릭하여 페이지를 편집하십시오.Rd232^talk 17:08, 2009년 9월 7일 (UTC)[응답]

(이 페이지의 "Click here to edit the sandbox"(샌드박스를 편집하려면 여기를 클릭) 링크가 이미 WP:Sandbox로 이동하기 때문에)Rd232^talk 17:09, 2009년 9월 7일 (UTC)[응답]

그러면 페이지 상단에 있는 편집 버튼도 그렇게 해야 한다.왜 이 제안이 더 잘 받아들여지지 않는지 정말 모르겠어...기능성은 유지하되 도입부에서는 반달리즘을 종료한다.- 2009년^τ_¢ 9월 7일 (UTC) 17:25 (UTC)[응답]

이 페이지 편집 단추가 이 페이지 편집 이외의 작업을 수행하도록 설정한다는 말씀이십니까?내가 모르는 걸 네가 모르면, 그건 현재 불가능해.Rd232 21:05, 2009년 9월 7일 (UTC)[응답]

응... 니프티 프로그래머들이 그것을 작동시키기 위해 간단한 코드를 생각해 낼 수 있을 거라고 확신해. - ʄooʏiaɲ^τ_¢ 06:31, 2009년 9월 8일 (UTC)[응답]

음, 버그를 신고하고 싶으면 괜찮아.과중한 업무에 시달리는 프로그래머들에게 우선순위가 될 줄은 상상도 못하지만...Rd232 10:09, 2009년 9월 8일 (UTC)[응답]

"카테고리" 시스템 업그레이드

"카테고리화는 위키피디아 소프트웨어의 특징으로, 페이지를 카테고리에 배치할 수 있게 하고, 독자들이 관련 주제에 대한 기사 집합을 찾는 데 사용할 수 있다.범주는 다른 범주의 하위 범주로 정의될 수 있으며, 트리 같은 구조를 통해 연결된 주제 영역 간에 쉽게 탐색할 수 있다.이는 독자들이 어떤 기사가 존재하는지, 어떤 기사가 무엇으로 불렸는지 모르더라도 특정 주제에 관한 기사를 찾을 수 있도록 돕는다."

그러나 현재 시스템은 직관적이지 않고 페이지 하단에 숨겨져 있으며, 탐색 잠재력을 최대한 활용하지 못하며, 카테고리 페이지는 매력적으로 보이지 않는다.최소한의 변경으로 동일한 정보를 훨씬 더 효과적으로 표시할 수 있어야 한다.다음 사항을 제안한다.

• 현재 정보가 고정 크기 상자에 표시됨
• 상자는 드롭다운 도구 또는 오른쪽 모서리의 영구 상자로 접근할 수 있다.
• 범주 목록은 현재와 동일하지만 스크롤 가능하므로 큰 상자가 필요하지 않음
• 목록은 단일 열이며 클릭 가능
• 카테고리 레벨에서 "상향" 및 "하향"으로 이동할 수 있는 기능이 있다.
• 입력 내용이 때때로 꽤 길어서 작지만 선명한 글꼴을 사용하는 것이 도움이 된다 – 작은 검은색 글꼴이 이 작업을 수행할 수 있다.

나는 기꺼이 그것을 시도해 볼 수 있는 프로그래머들과 더 토론하고 싶다.동시에 달성될 수 있는 많은 다른 범주 기반 개선사항들이 있을 것이다. 예를 들어 범주를 편집하고 관리하는 도구.그래니테시 (대화) 10:32, 2009년 9월 7일 (UTC)[응답하라]

기능 요청:범주를 "평면"으로 보는 기능, 즉 범주의 모든 페이지와 하위 범주를 하나의 논리 페이지에서 반복적으로 볼 수 있는 기능. --Cybercobra (talk) 11:34, 2009년 9월 7일 (UTC)[응답]

"범주를 편집하고 관리하는 도구" WP를 알고 있는가?핫캣? --사이버코브라 (대화) 11:34, 2009년 9월 7일 (UTC)[응답]

이 제안이 어떻게 보일지 완전히 확신할 수는 없지만, 확실히 카테고리는 현재 그들의 업무를 잘 수행하지 못하고 있으며, 주로 개발자 지원이 필요한 문제다(Bugzilla의 다양한 개선 요청은 거의 효과를 거두지 못했지만).사실 나는 훨씬 더 자연스럽고 강력한 시스템을 위해 버려진 범주들을 보고 싶다 - 기사 제목들의 특성을 말하기 위한 구문({profession=singer;sexual=남성;birthdate=...);such=...}}}. 그런 것) 그러면 사용자는 편집자들이 어떤 수준의 분류가 도움이 될 것인지 또는 방해물이 될 것인지 끊임없이 판단할 필요 없이 정확히 어떤 특성을 선택한 것인지에 따라 검색할 수 있었다.---코트니스키 (토크) 11:47, 2009년 9월 7일 (UTC)[응답]

위키백과의 제안:범주 교차점 및 위키백과:링크 교차로에 관심이 있을 수 있다. ---- Gadget850 (Ed) 12:53, 2009년 9월 7일 (UTC)[응답]

거기에 시멘틱 미디어위키와 다이나믹 페이지리스트를 추가하겠다.두 가지 모두 상당히 집중적인 연장선상에서 SMW가 가까운 장래에 추가될 인기 있는 것 같지만. --Izno (토크) 14:23, 2009년 9월 8일 (UTC)[응답]

나는 카테고리가 다소 혼란스럽다고 생각한다.그들은 평상시의 사용자에게는 ...의 리스트와 같은 기능을 수행하는 것처럼 보인다.작은 활자로 된 페이지와 (B) "...목록" 기사로 되어 있다.사실 "목록" 기사보다 기능적인 이점은 무엇인가?

또한 카테고리 페이지는 맨 위에 나타나는 "하위 카테고리가 하나 있다"와 그 아래에 134개의 정규 항목이 있을 때 혼동된다.위에서 말했듯이, 그 페이지들은 더 매력적이지 않고 위키백과 페이지의 "집 스타일"을 채택하지 않는 것 같다.Sussexonian (talk) 21:40, 2009년 9월 7일 (UTC) 목록보다 카테고리(category over list)의 이점이 무엇인가라는 질문에 대한 답변으로, 답은 한 단어로 요약할 수 있다 - 계층 구조.범주를 클릭한 다음 해당 범주의 맨 아래로 이동하면 범주가 보다 광범위한 범주의 구성원이 되는 경우가 많다는 것을 알 수 있다.나는 개인적으로 위키피디아의 카테고리 시스템을 좋아한다 - 분류론 위키피디아인 협회에서 증명하듯이 다른 많은 위키피디아 사람들이 그렇다.결국, 세계의 린네아 분단에 대해 배우고 싶다면, 이것은 매우 유용한 도구가 될 수 있다.길본은 영장류, 포유류, 척추동물, 즉 화음류 등을 발견할 수 있을 것이다.ACEOREVIVEED (토크) 22:55, 2009년 9월 7일 (UTC)[응답]

배경색을 변경할 때 전경색을 지정한다.

사람들이 테이블과 mbox 같은 것들을 만들고 배경색을 바꿀 때 왜 그들은 자동으로 전경색이 검정색이 될 것이라고 생각하는가?나는 화이트 포그라운드(white forground)를 사용하고, 실제로 사용하는 대부분의 페이지에는 충분히 효과가 있지만, 몇 페이지(중요한 페이지 포함)는 거의 읽을 수 없다.사람들이 배경색을 바꿀 때, 그들은 또한 정확히 어떤 전경색을 사용해야 하는지 명시해야 한다. 이것이 정책으로 만들어질 것을 요청하는 것이 합리적일까?Lemmiwinks2 (대화) 00:15, 2009년 9월 8일 (UTC)[응답]

구체적인 예시가 있으십니까?대부분의 박스 등은 기본값을 설정하는 CSS를 연결했다. -- - - Gadget850 (Ed) 01:37, 2009년 9월 8일 (UTC)[응답]

사실상 내가 본 모든 것.그러나 구체적인 예를 원한다면 다음과 같이 하자.

포르탈탈탈 }}}}}}}}}}}}}}}}}

사용자 대화 페이지에 있는 헛간 스타 추가(변경하기 전)

내 사용자 css 페이지의 mbox.

사실상 전체 '내 선호도' 페이지

더 찾아봐야지.Lemmiwinks2 (대화) 23:31, 2009년 9월 8일 (UTC)[응답]

그럼 어디선가 네 구성에 뭔가 문제가 있는 게 분명해.만약 당신의 묘사가 평범한 사람들이 소리지르고 그 장소를 갈기갈기 찢는 것이라면...당신은 어떤 맞춤형 CSS/js를 사용하고 있는가? 어떤 피부를 사용하고 있는가?
— V = I * R (Ω과 대화) 00:16, 2009년 9월 9일 (UTC)[응답]

Lemmiwinks2가 분명히 말했듯이, 그는 흰색 텍스트를 사용하고 있다.대수학자 00:18, 2009년 9월 9일 (UTC)[응답]

아, 방금 그의 첫 번째 글을 다시 읽었는데 이제야 알겠어.내가 할 수 있는 말은, 만약 당신이 비표준적인 일을 한다면, 당신은 그것이 어떤 문제를 일으킬 것이라고 예상해야 한다는 것이다.무례하게 들리기는 싫지만, 왜 당신은 개인적인 스타일의 선택이 우리 모두가 일을 해야 하는 기본이 되어야 하는가?당신은 할 수 있어야 하고, 그리고 실제로 (이 실에서 증명된 바와 같이) 당신이 원하는 것을 할 수 있어야 하지만, 우리가 개별 맞춤화의 선택에 순응하기를 기대하는 것은...자기중심적인가?하지만, 내가 뭘 알아?만약 누군가가 돌아다니면서 전경색 값을 스타일 태그에 추가하고 싶다면, 나는 누가 그것들을 멈출지 심각하게 의심한다.
— V = I * R (Ω과 대화) 00:44, 2009년 9월 9일 (UTC)[응답]

사용자:에 있는 모든 규칙을 알아내려고도 하지 않을 거야.Lemmiwinks2/monobook.css 및 사용자:Lemmiwinks2/vector.css, 그러나 상자와 관련된 묶음이 있는 것으로 보인다.사용 중인 항목을 지우고 정리하십시오.만약 그것이 그것을 해결한다면, 한번에 조금씩 다시 물건을 추가해라.또한 나는 왜 당신이 당신의 유저에 박스를 가지고 있고 그 파란 배경의 토크 페이지를 가지고 있는지 모르겠다. ---— Gadget850 (Ed) 00:26, 2009년 9월 9일 (UTC)[응답]

주황색과 녹색 위키링크를 도입하자는 제안에 대해 아래 토론에서 말했듯이, 우리는 색맹과 사람들을 혼동하지 않도록 주의해야 한다(검은색 텍스트와 흰색 텍스트는 이렇게 해서는 안 된다).

위키백과 본문을 색칠하는 것은 나쁜 생각이다.

나는 몇 분 전에 이 기사를 읽었다.

http://http:///www.wired.com/wiredscience/2009/08/wikitrust/

제발, 제발 이것을 실행하지 말아줘.이것이 켜져 있으면 글 읽기가 어려울 뿐만 아니라, 나는 이것이 '진실성'에 많은 문제를 야기하는 것을 볼 수 있을 뿐이다.편집자들은 토론에 참여하며, 의견 일치를 보기 보다는 편집 색상이 스스로 표현하도록 할 것이다.

위키피디아 재단의 위키피디아 재단이 일반과 과학 공동체의 눈에는 위키피디아 재단이 더 정확한 것처럼 보이도록 하는 관심을 이해한다(이미 존재하는 위키피디아가 가장 광범위하고 정확한 일반 자료임에도 불구하고). 그러나 무지개 색칠 페이지는 이렇게 하는 방법처럼 보이지 않는다.그것은 주의를 산만하게 하고, 실제로 정확성을 떨어뜨릴 수 있으며, 페이지가 분리되어 있는 것처럼 보이게 한다.대신, 페이지 제목과 색상 코드 페이지 제목에 따라 페이지 순위를 표시하는 확장자는 기사의 '연구 금고' 버전에 대한 링크뿐만 아니라, 기본적으로 사용되는 위치로 확장하자. (최근의 페이지 내역이 같거나 그 이상인 페이지)

이 방법은 정확성을 보장할 뿐만 아니라 전문적이거나 학문적인 맥락에서 안정적으로 사용될 수 있는 표준의 정적 스타일의 백과사전을 제공할 것이다.8비트 (토크) 05:41, 2009년 9월 1일 (UTC)[응답]

실제로 일어나고 있는 일은 Wikitrust에서 다룬다.그것은 기본 소프트웨어에 의해 모든 사용자에게 강요된 것이 아니라 가젯으로 보인다.
— V = I * R (Ω과 대화) 05:48, 2009년 9월 1일 (UTC)[응답]

기기로서도, 나는 여전히 그것에 반대한다. 왜냐하면 그것이 진실성을 이끌어 낼 수 있는 것으로 보이기 때문이다. 하지만 어느 쪽이든, 나의 대체 제안은 기본 설정으로 무엇이 있을까?여기 내가 상상하는 것의 대략적인 이미지가 있다.

8비트 (토크) 06:04, 2009년 9월 1일 (UTC)[응답]

나는 우리가 정규 독자들에게 우리의 평가를 보여주길 바란다.기사를 얼마나 신뢰해야 할지 고민할 때 귀중한 정보다. - 페레그린 피셔 (토크) 06:09, 2009년 9월 1일 (UTC)[응답]

@Peregrine Fisher:참고 항목:Wikisource:텍스트 품질.이런 시스템은 여기서도 통할 수 있겠지만, 한편으로는 가능하면 독자층과 편집물을 분리해서 유지하도록 노력해야 한다고 생각한다.메, 그냥 생각...–Juliancolton 01:50, 2009년 9월 5일 (UTC)[응답]

위키백과 메일링 리스트에 대해 비교적 광범위한 논의가 있어 왔으며, 원하신다면 얼마든지 읽어보십시오.이 일은 여기 오는데 시간이 좀 걸릴 겁니다. 그리고 선정주의적인 기사 작가가 말하는 것 처럼 정확하게는 아닐 겁니다.주요 측면은 텍스트의 한 섹션이 얼마나 광범위하게 편집되었는지, 그리고 텍스트가 추가된 디프트에 링크할 수 있는 능력인데, 정말 멋지다.~ 아모리(사용자 • 대화 • 기여) 2009년 9월 1일 12시 31분(UTC)[응답]

고마워, 아모리이 경우, 이것은 편집 도구로서 꽤 멋있게 들리는데, 말하자면, 이 기사가 암시하는 것처럼 나이든 사용자나 사용자에게 더 높은 색상의 우선 순위 같은 것을 주지 않는 한. 8비트 (토크) 18:09, 2009년 9월 1일 (UTC)[응답]

8비트, 색상은 기본적으로 나타나지 않으며 도구를 사용하려는 사용자를 위해 탭에서 액세스할 수 있다([8]로 시도하십시오).혁신적인 아이디어라고 생각하지만, 이 위키피디아에 대한 데모를 보고 싶다.에클립스 (대화) 2009년 9월 1일 (UTC) 20:16 [응답]

내가 보는 한 가지 문제는 몇몇 훌륭한 편집자들이 단지 스타일에 대한 전쟁을 편집하는 데 관여하는 것만으로, 또는 그들이 버락 오바마나 사라 페일린과 같은 널리 퍼진 페이지를 청소하고 무력화시키려 하기 때문에 "안정되지 않은" 등급을 획득할 수 있다는 것이다. 반면에 보통 편집자들은 단지 대부분의 일을 하는 우연에 의해서 보다 더 건전한 것처럼 보일 수 있다.스타일과 형식이 이슈로 떠오르지 않는 빈약하지만 논란의 여지가 없는 페이지에 대한 그들의 저작물.—— Shakescene (대화) 20:43, 2009년 9월 1일 (UTC)[응답]

몇 년 전에 어떤 랜덤 유저에 의해 제안되었던 아이디어가 기억나는데...그는 고소해야 한다! :) ----occono (대화) 00:31, 2009년 9월 4일 (UTC)[응답하라]

셰익스피어, 나는 연구원들이 다른 편집자들이 그들의 기사 버전으로 되돌아갔을 때 평판 등급을 되돌려줌으로써 그런 종류의 것에 대해 보상해 주었다는 말을 들은 기억이 나는 것 같다.나는 최고 등급의 편집자들은 여전히 논란의 여지가 없는 많은 변화를 일으키는 "조용한" 편집자들일 것이라고 확신하지만, 그것은 자동 평가의 과정과 같은 것이다.{{Nihiltres talk edits}}}01:35, 2009년 9월 8일 (UTC)[응답]

요컨대, 아무도 다음 회계연도를 되돌리지 않을 정도로 국수주의자들이 조용하다면, 그들은 신뢰할 수 있는 편집자가 될 것이고, 그들의 POV는 신뢰할 수 있게 될 것이다.하느님은 이것을 보존하시고, 우리에게서 멀리 떨어지십시오!Septentrionis PMAnderson 15:47, 2009년 9월 9일 (UTC)[응답하라]

그래, 어디서 시행하는지 보고 있었는데, 그게 얼마나 효과가 있을지 모르겠어.신뢰는 날씨에 근거해야 하는 것이 아니라 인용되어야 하는 것인가?-유니온호크 16^E-mailReview:01, 2009년 9월 9일 (UTC)[응답]

• 이것은 아마 카피 에딩에 대해 고려하지 않을 것이다. 그렇지 않은가?그 말은 기사 편집본을 사실 수정과 같은 방식으로 취급한다는 뜻이지누군가 내 작품을 편집하게 하거나, 내 작품을 편집하게 하는 것은 사실상 나의 "품질 등급"을 낮추는 것이 될 것이다.내가 보기엔 이게 복사하는 걸 방해할 것 같아.—Charles Edward 18:55, 2009년 9월 9일 (UTC)[응답]

대체 제안

대신에 FA를 메인 페이지에서 빼자. 다른 사람들은 남을 수 있고, 피해를 덜 입힌다.이것은 즉시 민족주의적인 POV-pushing의 양을 줄일 수 있을 것인데, 불가리아의 사무엘처럼 각각의 민족주의 갱단이 그들의 국가적 영광을 메인 페이지에 올리려고 애쓰는 것이다. 이는 1912년 불가리아의 민족주의 교과서에서 쓰여진 것이다.그 출처와 그 기사는 사무엘과 그의 동맹국들에게 모든 긍정적인 형용사를 준다; 사무엘의 동생을 포함한 그의 적들은 부정적인 형용사를 얻는다.다행히 카라낙스는 이 사실을 알아차리고 별을 사양했지만, 그런 일은 어디서도 자주 일어나지 않는다.

FA와 GA의 유용한 측면은 계속될 것이다; 자만심에 대한 스타들이 계속 있을 것이고, 평론가들은 기사를 계속 볼 것이다.지금과 같이 3번 중 1번 정도 복습하면 기사가 개선될 것이고, 지금처럼 실질적인 해악은 드물 것이다.Septentrionis PMaenderson 16:10, 2009년 9월 8일 (UTC)[응답하라]

나는 POV 푸셔들이 메인 페이지에서 직접 나오는 것이 의심스럽다; 그들은 다른 편집자와 마찬가지로 그들에게 흥미가 있는 기사를 찾고 있을 것이다.EVULA// talk // talk // 16:14, 2009년 9월 8일 (UTC)[응답]

하지만 여기처럼 더 세련된 사람들은 그들에게 맞는 기사를 쓰고 있다; 나는 FA 지명자와 그의 친구들에 대해 이야기하고 있다.패혈성PMAnderson 16:33, 2009년 9월 8일 (UTC)[응답]

그렇다면 FA를 메인 페이지에서 빼는 이유가 뭘까.EVULA// talk // talk // 20:05, 2009년 9월 8일 (UTC)[응답]

나는 충분히 자주 말해왔다. 메인페이지에서 어떤 것이 삭제되려면 DYK와 ITN이 되어야 한다.이것들은 위키피디아가 가장 못하는 것을 강조한다; 새롭게 만들어진 미완성 스텁과 편집하기 쉬운 빠르게 변화하는 주제에 대한 기사들.적어도 FAS는 누군가가 기사를 보는 것을 의미한다. (그리고 샌디, 라울, 카라낙스는 일반적으로 노골적인 복근을 발견하는 데 상당히 능숙하다.)– 무지개빛 20:38, 2009년 9월 8일 (UTC)[응답]

하지만 메인 페이지에 있는 것들이 좋기 때문에 사람들은 그것들을 찾아가서 개선한다.ITN과 DYK를 통해 작업할 수 있는 페이지를 많이 찾았다.OrangeDog (토크 • 편집) 02:39, 2009년 9월 10일 (UTC)[응답]

색상 제안 링크

편집할 초대:오렌지 링크

읽을 초대장: 녹색 위키링크

스텁 편집 탭: 강조 표시 및 초대

Stub edit tab: new proposal

Changing the stub template

Watched counter

The proposal in this box is shelved/withdrawn until the proposal in the next sub-section is resolved. (May be worth reading for background on that proposal, though)
The following discussion has been closed. Please do not modify it.
Wikipedia:PEREN#Create_a_counter_of_people_watching_a_page There are more good editors than vandals. Even if making the counter visible and the 'unwatched pages' page public resulted in massive abuse, editors would quickly remedy the problem by adding unwatched pages to their watchlist. Can an admin tell us how many pages there are on the unwatched list? Reasons for doing this, or why the 'vandalism' objection is invalid: Good editors would overwhelm vandals. Displaying "<5" for 0-4 would make this useless for vandals.[11] If there are still vandal concerns, an adminbot could be set up to ask recently-active editors to "adopt" articles. This would allow editors to find pages that needed "adoption". This would relieve the admins who are taking care of the unwatched list. What other reasons were given against this proposal? It might help if the PEREN page linked to the discussions. Without knowing what was said, the reasoning sounds like "the vandals would make this impossible", which is often a poor objection. –MT 03:50, 19 April 2009 (UTC)[reply] The list of unwatched pages is limited to 1000 entries, sorted alphabetically. It is rare that it extends beyond the letter A. Every time it is refreshed, there are a number of editors who dutifully watch hundreds of pages from it, yet every time it is refreshed with a new list. It really is like emptying the Atlantic with a teacup. I think the problem is hugely more widespread than you anticipate. Happy‑melon 09:36, 19 April 2009 (UTC)[reply] Not that they don't need watching, but how many of the first 1000 are redirects? Mark Hurd (talk) 11:26, 19 April 2009 (UTC)[reply] Given that points 1 and 2 would address the vandal problem, doesn't what you're saying just give us all the more reason to support this proposal based on points 4 and 5? –MT 13:51, 19 April 2009 (UTC)[reply] Another possibly 'simple' short-term solution is to provide another special page that lists unwatched pages by order of most recent edit and that can also still be limited to the first 1000. If that overlaps between runs, we'd be clearing the backlog from the more 'important' first. Otherwise we're no worse off. Mark Hurd (talk) 00:12, 20 April 2009 (UTC)[reply] Great idea. This would not only eliminate vandalism worries, but would also be extremely useful. This feature is a frequent request, is useful and informative, and aside from vandalism I don't think there are objections. We have the following options: Modify wgAllowPageInfo to display "<5 watchers" Change the list to order by last-edited rather than alphabetical, reduce displayed entries to 100, allow all to see it Change the list to order by least watched, then last-edited, reduce to 100, rename it to "least watched articles", allow all. I would support going directly to 3, but we can do a more gradual roll-out by implementing 1 and 3 (I think these are trivial changes, but perhaps a dev could comment) and then removing 1 when the list starts to shrink. Were there any lurking objections? –MT 00:53, 20 April 2009 (UTC)[reply] In the flagged protection and patrolled revisions trial implementation, special:Unreviewedpages, which lists pages that have never been patrolled, will indicate the number of active users watching the page. It's only accessible to reviewers. Cenarium (talk) 01:00, 20 April 2009 (UTC)[reply] This seems like its a lot more trouble than its worth. If you really want to help with vandalism, just get rollback and download huggle. I disagree that "Good editors would overwhelm vandals." really deals with the vandalism problem. This sounds like how wars used be fought, where each army would just stand in a line and shoot at the other one, and the bigger one would usually win. It worked, but not particularly well. Saying that fewer than 5 people watch a page still makes it nicer target for vandals, it just doesn't narrow it down quite as much. Since the people watching it might have left the project ages ago, it could still have 3-5 watchers but effectively be 0. Mr.Z-man 01:02, 20 April 2009 (UTC)[reply] Countervandalism activity is more than just RC patrol. Somebody needs to watchlist articles to catch the vandalism that the RC patrollers miss -- the majority of my vandalism reverts take place hours to days after the fact. --Carnildo (talk) 01:19, 20 April 2009 (UTC)[reply] I wouldn't like vandalism patrol, but I would like to make things much easier for editors and much more demoralizing for vandals. Your objection seems against the weakest part of the proposal. The implementation of #3 is a trivial change to an SQL "ORDER BY". The strongest part is editors being able to adopt unwatched pages. This is strengthened by the possibility of a "least watched last edited" page. Vandalism already targets unwatched pages (just click random and mess up an obscure article), this proposal would allow editors to target this already-vulnerable class of pages. –MT 08:07, 20 April 2009 (UTC)[reply] When your database contains several million rows, changes are rarely "trivial." The code for Unwatchedpages doesn't count the number of people watching the page at all right now nor does it use an explicit order, so you would need to add the "ORDER BY" and would also need a "GROUP BY." The other issue is that the list is only updated once every week or so. Given that we get about 11,000 edits per hour on around 6000 distinct pages, "most recently edited" might as well be random as it would be out of date within a few minutes. Based on a quick and dirty estimate using the number of pages in the list right now and how far it gets alphabetically, I would estimate that there's easily 60,000 unwatched pages. At 100 at a time, with updates once a week, it'll take 11 years just to work through all the pages with 0 people watching them, ignoring all the ones that are added in that time. Mr.Z-man 18:41, 21 April 2009 (UTC)[reply] I didn't and don't endorse a broken version of a recently-edited page. Given that wgAllowPageInfo doesn't use a field in the page table, I agree that it isn't trivial. It would require adding a field and index to the page table (cf. page_random, page_len, page_touched) that kept track of watchers. What sort of disruption would the addition of this field cause? Consider where unnoticed vandalism mostly occurs. The proposal would put into view these pages (which are highly vulnerable, seldom altered, and recently altered). This would allow editors to have a central place to patrol for vandalism (see Wikipedia_talk:Special:UnwatchedPages#Purpose. It would also allow editors to find pages to watch. There's a great reason Jimbo requested the unwatched pages, and given that that method is too overwhelming, there remains a great reason to implement recent least-watched pages. –MT 23:39, 21 April 2009 (UTC)[reply] Adding new tables to the database is relatively simple. Altering existing ones is generally avoided. I believe it requires stopping replication on, altering, then re-enabling each slave server one by one, then switching the master to update that. After updating all the databases, a script would have to be run to populate the new field. The page table on enwiki currently has 16,575,280 rows, and grows constantly. I've no idea how big the watchlist table is. If this is done, it might make such a special page possible (and able to be updated dynamically). The index would also probably have to be on page_latest as well if you want to be able to sort by most recently edited. Mr.Z-man 00:08, 22 April 2009 (UTC)[reply] Not forgetting, of course, that while the database master is being updated, the whole wiki goes read-only (unless they do something wierd like setting one of the slaves to be a temporary master, which could work I guess). This is the schema update script, yes? Happy‑melon 17:05, 24 April 2009 (UTC)[reply] \ Ah, pages isn't indexed by date. How does recent changes work then? (schema, large image). Perhaps it would be more appropriate to add this sort of field there. This would also involve adding a field, but might be less dramatic. The field would list the number of people watching the page at the time the edit was made, and could be used to generate our desired list. –MT 02:40, 22 April 2009 (UTC)[reply] Since RecentChanges would otherwise need to read from about five different tables every time it was requested, it actually stores all its data in its own separate table. Every new elegible edit or action puts a copy of its log into the recentchanges table as well as whichever permanent table it uses, and ever hundredth edit calls a function to clean out rows from the table that are older than the limit (currently 30 days). Happy‑melon 17:08, 24 April 2009 (UTC)[reply] Perhaps I should amend the proposal.–MT 19:38, 25 April 2009 (UTC)[reply]

A recent changes page for unwatched articles

Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Wikipedia_talk:Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult to 'clean out'. Another solution, advocated here, is to modify the recent-changes table in MediaWiki to grab the watcher-count from the watchlist table. We would then be able to create a "recent changes in unwatched articles" page. This page would let editors catch vandalism that would usually have gone unnoticed for long periods of time. It would also encourage editors to expand their watch-lists, and urge editors to contribute to fringe/stub articles that are seeing some recent activity. It would also allow us to finally address one of the WP:PERENs. To get this proposal off the ground, we would need:

1. Interest from editors. Other potential benefits. Perhaps a straw-poll.
2. Critical comments, including reasons why this might not be as useful as stated.
3. Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
4. Input from a developer. Should one be contacted to check feasibility?

Comments addressing any of these four points are especially welcome. –M^T 19:38, 25 April 2009 (UTC)[reply]

Now this is an interesting, and probably feasible, idea. Technically, it could probably be done without a schema-change, and it could be useful to do so; the code in FlaggedRevs, for instance, uses the fact that it has to do a database lookup to be more clever in what it shows: it only 'counts' users who have logged in in the past 60 days, for instance, which is pretty neat. If the servers can take the strain, having that feature available on Recent Changes would be very useful, and avoids the issue of pages apparently being watched because they're on the watchlists of users who last logged in three years ago. Performance-wise, having a rc_watched column in the recentchanges table would massively reduce database load when viewing RecentChanges. Or we could define a few more types in the rc_type field (only ~3 actions defined out of a possible 16 million!), and avoid an explicit schema change, but the devs might find that a bit hackish (I remember there being hiccups over the RevDeleted bitfields). On the other hand, that field then has to be populated on every action.

Procedurally, it sounds like a godsend. Unwatched articles are only dangerous if they're edited; unwatched but untouched articles are no harm to anyone. Happy‑melon 14:39, 27 April 2009 (UTC)[reply]

I think 7 days would be the best last-login time, unless someone can give a better figure. Given the rate of revisions vs the rate of access, and the many other fields in recent changes, I don't think that this would do too much damage to performance. And the benefits, as you say, are a godsend. Should we get dev feedback, or try to get a few more comments? –M^T 02:36, 28 April 2009 (UTC)[reply]

I guess it should be the latter... –M^T 04:28, 5 May 2009 (UTC)[reply]

How might the column increase performance? M 20:37, 13 May 2009 (UTC)[reply]

I have to agree that this is an interesting proposal. During my vandalism patrols i cross infrequently visited articles every now and then which blatant vandalism on them for periods up to (And in some cases over!) a year. While I encounter them irregularly it won't automatically mean there are not a lot of pages vandalised this way - they simply don't show up on anti-vandalism tools often. I also see possibilities for using this page for new page patrol as pages listed might very well be missed non notable or vandalism pages that slipped into forgetfullness.

On a more critical note: How would these articles be patrolled? I can imagine that this category will end up having at least 100.000 articles in them. Even if they are only infrequently edited it will still mean a lot of edits in a day - and how will double / triple / n* checks of the same page be prevented? Likewise, not every actively edited article has to be on a watchlist. Also, some active editors have massive watchlist from new page patrols (I had to remove 600 entries from three weeks patrolling). How can we prevent pages from going unnoticed due to unclean watchlists? Might it be better to filter on pages that have not been edited in say, two months? Excirial ^{(Contact me,Contribs)} 19:51, 15 May 2009 (UTC)[reply]

Another way to look at it is as filtering out all 'watched' pages from recent changes - if someone's watching, you don't need to. So right away we're preventing many multi-checks. Overflowing watchlists are a problem, but this new page will catch further edits to infrequently-edited articles. So if you can't track every page on your watchlist, then you shouldn't, and now you wouldn't have to. The other problems you bring up - inevitable double checks, thousands of edits per day - are ones we already face. This proposal can't solve them, but it does reduce them. M 22:13, 15 May 2009 (UTC)[reply]

You could just use variables, like

"Recent Changes on Village pump (proposals)/Archive 51: MalnadachBot, on 03/18/2022"

But it would be a good idea for rollback

Would there be some way of combining it with the recent "whitelist" list of autreviewers? That is, for there to be a list of recent changes to unwatched pages excluding those pages where the last change is by an autoreviewer? That way it would be easy to look for vandalism without checking pages where someone else has already reverted vandalism. That might well solve some of Excirial's concerns about multiple checks of the same recent edit. Grutness...wha? 02:09, 23 June 2009 (UTC)[reply]

The list would essentially be a filtered version of the current recent-changes list, so if this idea is possible there, then it is possible with this list. I don't think that this should be handled by the server itself, though I do think that it should expose the autoreviewer or admin status of the last editor, so that scripts could use that information to do what you describe. M 21:57, 2 July 2009 (UTC)[reply]

Would it be a good idea to move this proposal into its own page, and if so, where should it be located? M 22:10, 6 September 2009 (UTC)[reply]

Recent unwatched changes straw poll

The proposal is to create a recent changes page for unwatched articles to prevent vandalism by modifying the recent-changes table in MediaWiki. (I'd really prefer not to see this one archived, since it would open up several useful features. It would permit Watched counters. A now-ignored bugfix in the watchlist code and the addition of a 'checked' watchlist row would then let you patrol your own watchlist. Adding a public-watchlist preference would then give us a passive form of Flagged revisions.) Though this is a software feature request, support from editors would help.

• Support. –M^T 04:28, 5 May 2009 (UTC)[reply]
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)[reply]
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232^talk 18:34, 9 May 2009 (UTC)[reply]
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)[reply]
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)[reply]
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)[reply]
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)[reply]
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)[reply]
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)[reply]
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages M 20:29, 13 May 2009 (UTC)[reply]
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)[reply]
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)[reply]
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)[reply]
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists). M 22:31, 13 May 2009 (UTC)[reply]
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)[reply]
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)[reply]
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC) See my comment below. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Support per my original comment. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)[reply]
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)[reply]
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)[reply]
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)[reply]
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only. M 01:14, 6 June 2009 (UTC)[reply]
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)[reply]
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance. M 00:27, 11 June 2009 (UTC)[reply]
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)[reply]
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature. M 18:29, 16 June 2009 (UTC)[reply]
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)[reply]
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases. M 00:23, 22 June 2009 (UTC)[reply]
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)[reply]
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort. M 08:11, 26 June 2009 (UTC)[reply]
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)[reply]
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)[reply]
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)[reply]
• Yep, definitely a good idea. –Juliancolton ^Talk 22:07, 2 July 2009 (UTC)[reply]
• Support Very useful idea. It will increase the efficiency of the list. In my opinion, I would not mind if I had a list of pages to watch on top of my current list. It is all going for the same cause in the end anyways. -- Dspradau → talk 14:45, 6 July 2009 (UTC)[reply]
• Support, a very good idea. 'Nuff said. Jamie^☆S93 21:41, 9 July 2009 (UTC)[reply]
• Support, with considerations. It should only go ahead if it is known with certainty to not cause added strain to the servers, as well, I think one of the suggestions above should be seconded: make it admin only for a test period, before opening it up for everyone to use, just as a precaution. (I know, I'm hardly here, but, at least I'm hardly here over a long period of time *grin*, which should let me have some say). kaVri 19:28, 12 July 2009 (UTC)[reply]
• Support - This feature would increase average article quality on Wikipedia by combating vandalism on unwatched pages. One could see it as a complement to Flagged Revisions. EconomistBR 20:56, 15 July 2009 (UTC)[reply]
  • I've heard stories about something called "flagged revisions", but I think those are just ghost tales that old editors tell each other around the campfire. They'll be implemented soon is the punchline to all the jokes. There was something about them appearing when Brion Vibber got back from his honeymoon, but he seems to be back now... Delicious carbuncle (talk) 21:54, 15 July 2009 (UTC)[reply]
  • Though I don't think that flagged revisions are as useful as they seem (I'd prefer a per-person way of tracking articles and not revisions, which is somewhat easy to implement using the watchlist), I agree that the two would work well together. Similarly, if we turned on the 'how many people are watching this page' feature, those interested in watching the unwatched pages would be able to tell if they are already watched. M 21:05, 20 July 2009 (UTC)[reply]
• Oppose, this will just make things worse, giving the vandals a potential hit list they can use. ViperSnake151 Talk 13:33, 24 July 2009 (UTC)[reply]
  • You might be misunderstanding the proposal. While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. It's safe to leave cheese out when there's a lethal spring-loaded bar attached - which is exactly what this list is. M 17:44, 31 July 2009 (UTC)[reply]
• Support – definitely. This is a good way to revert vandalism. —MC10 Sign here! 02:34, 25 July 2009 (UTC)[reply]
• Nuclear support. This is a brilliant idea. In the past I've randomly picked some unwatched pages to put on my watchlist, but they were never edited that I saw, and I removed them as a futile addition. One caveat, though. Are we only looking at pages that show up on zero watchlists, or will this include, for example, pages only watched by people who are long gone? Come to think of it, where we have permablocked vandals and the like, can we strip them of their watchlists and prevent them from watching articles (given that they would only have nefarious reasons to be watching anything)? Cheers! bd2412T 19:28, 31 July 2009 (UTC)[reply]
  • It marks the recent-changes entry with how many recently-active & autoconfirmed editors were watching at the time of the edit. This ignores long-gone editors, and the 'watch pages to hide them' vandal tactic is painfully time-consuming (so watchlist-stripping is not needed). Yes, we would be able to filter recent-changes to pages with 0, <5, or >500 watchers. M 19:52, 31 July 2009 (UTC)[reply]
• Support Ben MacDui 15:42, 1 August 2009 (UTC)[reply]
• Support Far better to match the system to the content, not vice versa: there have been calls to raise the BLP notability bar to cut down on content needing to be watched. Esowteric+Talk
• Support - great idea. --[midnight comet] [talk] 18:24, 3 August 2009 (UTC)[reply]
• Support - makes life easier. Kayau Wuthering Heights VANITY FAIR paradise lost 08:17, 4 August 2009 (UTC)[reply]
• Support-It seems like a great idea. However, there must be hundreds of thousands of unwatched articles. Perhaps we should start off with admin's first. In addition, there really should be a limit as to how many a person could see.(I see no reason to have a public list of 150,000+ unwatched articles as this invites vandalism).Smallman12q (talk) 19:28, 4 August 2009 (UTC)[reply]
  • The list pretty much only displays recently-edited unwatched pages, rather than all unwatched pages. It would slowly grow until pages started falling off the end. You're probably right about the title - we shouldn't have a page called 'here are our unwatched pages' (which isn't true anyway, since we'd watch them using this list). It should probably be just another option in the recent changes list. M 02:05, 5 August 2009 (UTC)[reply]
• Support. What a great idea. To the editor who said it should only be admins, I can understand, but suspect that more help will be needed than just sysops. What about making it availible to those who have had rollback without incident for six months or a year? Unschool 02:17, 10 August 2009 (UTC)[reply]
• Support Couldn't hurt anything, and might wind up being useful. causa sui× 04:43, 13 August 2009 (UTC)[reply]
• Support I can't see it doing any harm to try this, at the very least. Sophus Bie ^(talk) 03:13, 14 August 2009 (UTC)[reply]
• Neutral. Would certainly be useful but... vandals can watch pages to. A vandal who is smart enough to use that list to find pages which aren't watched would probably be smart enough to watch the page after vandalising it. :/ I know, WP:BEANS, but I think that it needs to be mentioned. One option would be to limit it to a trusted group like rollbackers. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Switched back to support, above. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)[reply]
• Support. I do not quite understand this technical jargon (please do not waste time trying to explain to me), but if the only way the server load can be tested, is to be implemented, I support. All critics seem to have been silenced by M's rebuttals. Lumenos (talk) 04:44, 15 August 2009 (UTC)[reply]
• Support. Sounds like a good idea. I just hope it doesn't backfire because of unforeseen circumstances. Maybe it should be tested first in a trial run for admins only. -- œ^™ 20:18, 15 August 2009 (UTC)[reply]
  • I like the idea of testing in a safe way first, before making it live for all. That unfortunately might mean restricting it to admins, unless someone has a better idea. (One possibility would be to force the list to be definitely small enough to process, eg show only the first 100 unwatched-change pages per day. Or show those 100, but only create a new batch when all those 100 have been watched...) Rd232 ^talk 08:45, 7 September 2009 (UTC)[reply]
• Comment This seems to have broad support, and a bug was filed. Should the poll be closed? --Cybercobra(talk) 03:45, 18 August 2009 (UTC)[reply]
  • 34 support, 1 Oppose as of your comment, so the support is strong, yes :) It's still not clear though if this is something the community sees as not just a good idea, but something that's really needed (per my 13 May comment above). Many editors are also giving a lot of informative feedback (eg the 'rollbackers only' points) and ideas, without this generating 'drama'. I think it will die down soon enough anyway... M 02:21, 19 August 2009 (UTC)[reply]
• String support provided access to it is limited to trusted users (perhaps admins and rollbackers?). עוד מישהו Od Mishehu 08:38, 18 August 2009 (UTC)[reply]
• Support Brilliant idea ! Mr.TrustWorthy----Talk to Me! 17:19, 18 August 2009 (UTC)[reply]
• Support GeometryGirl (talk) 11:01, 19 August 2009 (UTC)[reply]
• Support ----occono (talk) 17:06, 23 August 2009 (UTC)[reply]
• Yep, would be good. I suggest that only rollbackers and sysops be able to see it. Pmlineditor Talk 12:10, 30 August 2009 (UTC)[reply]
• opppose Until we know exactly how many unwatched articles/pages there are. If there are more than 10,000, I can't imagine a watchlist which would do much good unattached to some external tool. Protonk (talk) 08:27, 7 September 2009 (UTC)[reply]
  • My feeling is that the number is far north of 10,000 Protonk (talk) 08:34, 7 September 2009 (UTC)[reply]
  • Please read the proposal before commenting. I've replied to this objection 3 or 4 (or more) times now. The list would not expose all unwatched pages. Why would we need an external tool? M 06:38, 12 September 2009 (UTC)[reply]
• Neutral To be honest, I just don't care much about the underlying issue here. It certainly wouldn't bother me if this were implemented, but since I would be unlikely to ever use it I can't support it.
  — V = I * R (talk to Ω) 08:52, 7 September 2009 (UTC)[reply]
• Oppose: Of course, it's always tempting to say "I want something", but we have to look at the cost. As Protonk points out, it is not trivial to implement and may require even an additional tool. That's not worth our developer's time. There are more important bug requests, and the watch problem can be better addressed with flagged revisions. — Sebastian 01:09, 12 September 2009 (UTC)[reply]
  • Nothing is trivial to implement, but this is certainly not on the difficult end of the spectrum. Could you give more details on what exactly you think makes this non-trivial, or what aspect may require an additional tool? M 06:38, 12 September 2009 (UTC)[reply]
  • Now that I read it, this reply makes we want to support the proposal here based on "it would be better to use flagged revisions", which I think is a terrible idea.
    — V = I * R (talk to Ω) 09:34, 12 September 2009 (UTC)[reply]
• Support, even strong support. I would use this daily at least. Gosox5555 (talk) 01:31, 14 September 2009 (UTC)[reply]
• Support I've seen some unwatched pages (like schools, for instance) get vandalized and stay vandalized for a while until someone comes back and vandalizes it again. This proposal will certainly help counteract this, or, at least help cut down the number of edits people have to look out for. Hardtofindaname 08:35, 14 September 2009 (UTC)[reply]
• Mindblowing support- and in response to suggestions that vandals can watch pages- IP vandals can't. Suggest only listing a page as 'unwatched' if it's not watched by autoconfirmed users. --King Öomie 19:52, 18 September 2009 (UTC)[reply]