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

위키백과의 공개 검정 배경 버전

안녕! 난 오랫동안 편집도 안 했고, 지역 사회 문제에 별로 관여도 안 했으니까, 여기서 내 질문이 이상하게 느껴진다면 사과할게.

로그인할 필요 없이 검은 바탕이 있는 위키피디아에 접속할 수 있는 방법이 있을까? (거의 모바일로 갈 수 있는 방법처럼)iPods나 Blackberry를 사용하는 경우 wikipedia.org)선호도에 검은색 배경과 녹색 텍스트 설정을 사용하지만 로그인하지 않고 사용할 수 있는지 궁금할 뿐이다.(항상 에너지 절약에 집착하는 경향이 있다...)=)

구글도 내 말뜻을 이해하지 못하면 블랙레에 비슷한 형식을 취하고 있다.--Dem393 (대화) 19:52, 2008년 11월 15일 (UTC)[응답]

Blackle은 CRT 모니터를 사용하는 사람들에게만 전력을 절약한다.LCD 모니터를 사용하는 사람들의 경우 전력 사용 측면에서 흑백의 차이가 없다: 백라이트는 항상 켜져 있다. --Carnildo (토크) 00:52, 2008년 11월 16일 (UTC)[응답]

CRT 모니터는 일반적으로 상자 모양이지?--Dem393 (대화) 03:13, 2008년 11월 16일 (UTC)[응답하라]

어떤 종류의 모니터에도 검정색 배경을 사용해도 상당한 양의 에너지를 절약할 수 없다. 난방이나 A/C를 1도 낮추면 훨씬 더 많은 에너지를 절약할 수 있다.사용성과 눈의 피로에 대해 걱정한다.Dcoetzee 08:49, 2008년 11월 16일 (UTC)[응답]

나는 동의하지 않는다.만약 많은 사람들이 검은 배경을 사용하기 시작한다면, 우리는 상당한 양의 에너지를 절약할 수 있을 것이다, 그렇지 않은가?블랙클과 같은 검은 배경의 공공 웹사이트를 보유하는 것은 또한 모든 사람들에게 전력 절약에 큰 변화를 주기 위해 작은 조치를 취해야 한다는 것을 상기시킬 것이다. --Dem393 (대화) 15:08, 2008년 11월 16일 (UTC)[응답]

작은 발걸음, 긴 의료비.난 눈 하나 깜짝 안하지, 그렇지?NVO (대화) 17:33, 2008년 11월 18일 (UTC)[응답]

당연하지, 나는 검은 배경 기기를 사용하는데, 왜냐하면 평범한 디스플레이가 내 눈을 아프게 하기 때문이야.던컨힐 (대화) 2008년 11월 18일 (UTC) 17:46[응답]

안녕!sourceforge:projects/poxy/에서 PHProxy 복사본을 가져와서 추가하는 경우

$Blackurl = complete_message("/w/index.php?title=미디어위키:가젯-블랙스킨.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400"); preg_match("/[link el=]\"스타일시트\".*모노북\.css.*\/>/i", $_response_body, $matcher); $_response_body = str_them($matcher[0], "[link el="\"스타일시트\"href=\"$blackurl\" 타자를 치다=\"텍스트/css\"/>", $_response_body); 

방금 전에

$_response_body;

index.php에서 해당 프록시를 탐색하면 로그인 여부에 관계없이 즉시 블랙/녹색 버전을 사용하도록 CSS 파일을 자동으로 수정한다.어떻게 해야 할지 모르겠으면 내 토크 페이지에 한 줄 적어줘.폭스리 록시 11:19, 2008년 11월 16일 (UTC)[응답]

또는 Firefox를 사용하면...도구 -> 옵션 -> 내용 탭 -> 색 -> 배경은 검정, 텍스트는 흰색 또는 녹색으로 변경하고, "페이지가 자신의 색을 선택할 수 있도록 허용"의 선택을 취소하십시오.그런 다음 위키백과뿐만 아니라 인터넷의 모든 페이지에서 작동한다(메인 페이지나 인포박스처럼 기기가 놓치는 것에 대한 배경색도 변경한다).만약 당신이 여전히 그 가젯을 사용하고 그것이 위키피디아에만 적용되도록 원한다면 당신은 Greasemonkey 스크립트를 사용하여 CSS를 추가할 수도 있다.Mr.Z-man 04:04, 2008년 11월 17일 (UTC)[응답]

롤백자에 대한 새 권한

제목 블랙리스트 재정의

제안: 롤백자가 제목 블랙리스트의 방해 없이 페이지를 작성하고 이동할 수 있도록 허용.이는 개발자가 '롤백커' 그룹에 '트보버라이드' 허가를 추가하도록 버그 요청을 하면 된다(물론 여기서 이의 제기가 없는 경우).나는 이것이 정확히 널리 보급된 효용성에 관한 것이 아니라는 것을 인정하지만, 다른 한편으로 나는 이러한 제목들로 페이지를 만드는 최소한의 신뢰 받는 사용자들을 막을 좋은 이유를 생각해내는데 어려움을 겪고 있다.일부 사용자들은 Talk:(+-cis-2-Aminomethylcylopropane 카르복실산)와 같은 이름의 페이지를 만들 만한 충분한 이유가 있는 것으로 밝혀졌다.왜 그들이 그렇게 하도록 허락하지 않는가?생각?HiDrNick! 2008년 11월 17일 (UTC) 20:10[응답]

• 반대: 롤백 권한이 있는 사용자에게 이것이 어떻게 유용할지 잘 모르겠다. - Rjd0060 (대화) 04:06, 2008년 11월 18일 (UTC)[응답]
• 반대: 롤백러는 "신뢰할 수 있는 사용자" 그룹이 아니며 이것은 공공 기물 파괴 행위를 되돌리는 데 전혀 도움이 되지 않을 것 같다.Mr.Z-man 00:09, 2008년 11월 19일 (UTC)[응답]

감시되지 않은 페이지

제안됨: 롤백자에게 특수 사용 허용:사용자가 보지 않은 페이지 목록인 미보딩 페이지는 공공 기물 파손과 싸우는 데 유용하다.마찬가지로, 개발자가 롤백자 그룹에 "보이지 않은 페이지" 권한을 추가함으로써 이 문제가 발생할 수 있다.이의는 없으십니까?HiDrNick! 2008년 11월 17일 (UTC) 20:10[응답]

• 반대: 롤백을 하는 사용자를 포함한 모든 사용자에게 유용한지 잘 모르겠다.나는 sysop이고 그 특별한 페이지에 많이 쓰이는 것을 본 적이 없다. - Rjd0060 (대화) 04:06, 2008년 11월 18일 (UTC)[응답]
• 반대 - 이렇게 하면 사용자는 이 페이지에 액세스할 수 있을 정도로 신뢰할 수 있는 계정을 가질 수 있으며, 이 계정을 자신의 Sockpuppet에 사용할 수 있다.עוד מישהו Od Mishehu 07:03, 18 November 2008 (UTC)[reply]
• 반대 - 너무 문제를 일으키는 것 같다.Phyomonas_(talk) 00:12, 2008년 11월 19일 (UTC)[응답]

일반 의견

롤백을 자유자재로 허용하고 최소한의 소란을 피우는 것에 찬성하는 주요 주장들 중 하나는 그것이 정기적인 자동 확인 사용자에게 없는 어떠한 특권이나 능력도 부여하지 않는다는 것이다. (모든 편집자는 편집을 되돌릴 수 있고, 사용자측 자동화된 도구를 사용함으로써, 편집자는 심지어 원클릭 되돌릴 수도 있다.)이 두 제안 모두 새로운 능력이나 접근 권한을 부여할 것이다.결과적으로, 롤백은 더 '빅딜'이 될 것이고, 관리자들은 롤백 요청을 지금보다 훨씬 더 철저하게 조사해야 할 것이다.그 프로젝트에 대한 최소한의 잠재적 이익으로 보이는 것 때문에 절충은 가치가 없다.심지어 제안자들조차 제목 블랙리스트를 무시할 수 있는 것은 거의 사용되지 않는 도구일 뿐이고, 보기 힘든 페이지 목록에 쉽게 접근할 수 있는 것은 우리의 명성을 손상시키고 싶어하는 반달족에게는 즐거운 선물처럼 보인다.TenOfAllTraes(대화) 04:28, 2008년 11월 18일 (UTC)[응답]

가상 참조 목록을 자동 업데이트하는 가능한 방법

인라인 인용을 위해 새로운 참조가 추가될 때마다 나는 기사 전체를 편집하거나 페이지를 편집하고 기사를 확인하여 오류가 있는지 확인해야 한다.전자는 편집된 내용이 항상 명확하지 않은 역사 기록으로 이어지고 후자는 연속적으로 많은 편집으로 이어질 수 있으며, 특히 대문자나 공백, 누락된 글자 등과 같은 작은 것들이 꺼졌을 때 인용문이 여러 개 추가될 경우 더욱 그렇다.어느 것도 쉽게 읽을 수 있는 역사 일지를 보관하는 데는 좋지 않다.

내가 생각하기에 해야 할 일은 참조 코드가 사용될 때마다 미리보기가 참조만 나열한 가상 참조 시트를 뱉어내는 것이다.여러 번 사용되어 공간 참조가 짧아진 경우, 메인 기사에서 해당 참조를 검색하거나 이름이 최소한 작동 중임을 표시할 수 있다(그래서 실수로 "/"를 삽입하는 것을 잊어버렸는지 확인할 수 있다.진나이 (토크) 22:27, 2008년 11월 17일 (UTC)[응답]

편집 중인 섹션 하단에 항상 {{reflist}}을(를) 넣고 Preview(미리보기) 버튼을 누르면 된다.그것은 당신이 있는 구역에 대한 인용구를 만들 것이다.참조가 올바르게 보이면 {{reflist}}을(를) 제거하고 섹션을 저장하십시오.카라낙스 (대화) 22:43, 2008년 11월 17일 (UTC)[응답]

얼마나 많은 새로운 편집자들이 그걸 알까?아니면 나이든 편집자들이 인라인 인용문을 추가하는 데 익숙하지 않은가?또한, 그것은 당신이 매번 그것을 기억해야 한다는 것을 의미한다.진나이 (토크) 22:46, 2008년 11월 17일 (UTC)[응답]

[E/C] 좋은 생각이야.같은 문제에 반복적으로 부딪쳤다.해결책으로 편집 중인 섹션 하단에 {{reflist}}을(를) 추가하기도 한다.저장하기 전에 지워야 한다는 것을 기억해야 하기 때문에 완벽하지 않고, 다른 섹션에 이름이 붙은 ref가 표시되지 않는다. ·:······· 22:47, 2008년 11월 17일 (UTC)[응답]

좋은 생각인 것 같네, 만약 할 수 있다면 지원하겠네. 전에도 같은 문제가 있었어.Temp reflist를 사용할 생각은 없었지만, 팁 덕분에 Jac16888 (토크) 23:06, 2008년 11월 17일 (UTC)[응답]

이것이 도움이 될 수 있음:

//편집 상자 맨 아래에 "Refs(Refs Refs)" 링크 추가 만일 (wgAction == "편집"    wgAction == "submit") { 애드온로드 후크(기능을 발휘하다() {     시합을 하다 refPreview = 문서화하다.createElement("div");     시합을 하다 regPreview = 문서화하다.GetElementBy아이디("wikiPreview").넥시블링;     regPreview.parentNode.삽입 전(refPreview, regPreview);     시합을 하다 선구적인 = getElementsByClassName(문서화하다.GetElementBy아이디("편집 양식"), "스팬", "도움말 편집")[0], 얼링크를 달다 = 문서화하다.createElement("a"), 리큐;     얼링크를 달다.href = "javascript:void(0)";     얼링크를 달다.부록차일드(문서화하다.CreateTextNode("사전 검토 참조"));     선구적인.parentNode.삽입 전(얼링크를 달다, 선구적인);     선구적인.parentNode.삽입 전(문서화하다.CreateTextNode("   "), 선구적인);     얼링크를 달다.클릭을 하다 = 기능을 발휘하다() {         만일 (리큐) { 빈틈이 없는("리뷰 준비 완료...."); 돌아오다; }         리큐 = 새로운 XMLHttpRequest();         리큐.개방된("포스트", wg서버 + wgScript 경로 + "/api.php", 진실의);         리큐.온프레미스 체인지 = 기능을 발휘하다() { 만일 (리큐.readyState == 4 && 리큐.지위 == 200) {             시합을 하다 칸막이하다 = 문서화하다.createElement("div");             칸막이하다.innerHTML = 평가하다("("+리큐.반응하다텍스트+")")["파스"]["텍스트"]["*"];             리큐 = 무효의;             시합을 하다 리프스 = getElementsByClassName(칸막이하다, "div", "작음-작음)[0];             만일 (!리프스    !리프스.hasChildNodes())                 리프스 = 문서화하다.CreateTextNode("참고인을 찾을 수 없었다!");             만일 (refPreview.hasChildNodes())                 refPreview.대체 차일드(리프스, refPreview.첫째 아이);             다른                 refPreview.부록차일드(리프스);         }}         리큐.setRequest헤더("콘텐츠 유형", "응용 프로그램/x-백업-폼-인코딩);         리큐.보내다("action=parse&format=json&filency="+wgPageName+"&text="             +인코드URIComentor(문서화하다.GetElementBy아이디("wpTextbox1").가치를 매기다+"\n{{reflist}}"))         돌아오다 거짓의;     } }} 

거친 가장자리도 양해하십시오 :) 스크립트는 {{reflist}}이(가) 부착된 전체 섹션의 미리보기를 검색한 다음 미리보기 섹션의 하단에 reflist만 추가한다.다른 섹션(예: <ref name="foo" />)에서 명명된 ref에 오류가 발생한다는 점에서 섹션 끝에 {{reflist}를 추가하는 동작과 동일하다.

이것은 결코 내장된 리프 프리뷰를 대체하는 것이 아니며, 아마도 위키와 같은 더 큰 스크립트로 통합될 수 있을 것이다.Gracenotes^T § 00:01, 2008년 11월 18일 (UTC)[응답]

wiked에 "을 첨부하여 이 재미있는 내용을 추가하겠다.<references />섹션 편집을 위해 "을 Ajax 미리 보기로 이동하십시오.인라인 참조가 없으면 보이지 않으며 다른 섹션에서 정의된 참조에 대해 빨간색 오류 텍스트를 던진다.Cacycle (대화) 04:04, 2008년 11월 19일 (UTC)[응답]

나는 그것을 위키에 추가했다.Cacycle (대화) 04:31, 2008년 11월 20일 (UTC)[응답]

일시적으로 {{reflist}}을(를) 추가하는 방법은 위키백과에서 설명한다.각주#단일 섹션 편집 미리 보기더 나은 방법은 User:Anomie/ajaxpreview.js—이것은 ref를 포함할 또 다른 미리보기 버튼을 추가한다.또한 refTools를 활성화할 것을 권장한다. ---- - Gadget850 (Ed) - 00:09, 2008년 11월 18일 (UTC)[응답]

다른 미리 보기 스크립트 사용자:js/ajaxPreview도 자동으로 추가<references />. 단, 아노미 미리보기 스크립트는 현재 단원에서 정의되지 않은 ref도 리터 리터링할 수 있기 때문에 이 특정 영역에서 가장 고급이라는 점을 지적하고 싶다(알고자 하는 것은, 에나미에의 미리보기 스크립트가 현재 단원에서만 정의되어 있지 않은 ref도 리터러시할 수 있기 때문이다.name=) —AlexSm 05:08, 2008년 11월 20일 (UTC)[응답]

문제는 우선 정상적으로 미리 보고 나서 대본으로 미리 봐야 한다는 거야.그렇게 하지 않고 미리보기를 하면 마지막 미리보기(또는 미리보기를 전혀 하지 않은 경우 실제 내용)를 사용한다.진나이 (대화) 05:30, 2008년 11월 21일 (UTC)[응답]

비디오 인터뷰

안녕.

나는 t5m의 마케팅 책임자 타비타야, 나는 위키백과 커뮤니티에 우리가 생산한 콘텐츠가 위키백과와 관련이 있다고 느끼는지 여부를 논의하자고 제안하기 위해 글을 쓴다.

t5m은 온라인 TV 네트워크로, 영감을 주고 즐길 수 있는 콘텐츠를 제작하는 것이 임무다.기존 콘텐츠를 집계하거나 사용자에게 의존하는 대부분의 비디오 네트워크와는 달리, t5m은 유명인사와의 독창적인 독점 인터뷰를 제작, 제작, 결합한다.

t5m는 우리가 인터뷰하는 재능과 큰 관계를 가지며, 이것은 우리가 솔직하고, 재미있고, 신뢰할 수 있는 정보 제공 인터뷰의 본질을 보장한다.연예인들은 모두 그 내용에 만족하고 있으며, 우리가 기자나 광고가가 아니라 그저 그들에게 입만 열면 된다고 굳게 믿고 있기 때문에 그들의 팬들이 그것을 볼 수 있도록 우리를 격려한다.

나는 우리가 가진 많은 인터뷰가 특정한 재능에 대한 위키피디아 페이지와 관련이 있다고 느낀다.나는 우리의 콘텐츠가 관련된 모든 페이지의 t5m에 링크하는 것은 비윤리적이라는 것을 이해한다. 그래서 나는 위키백과 커뮤니티에 우리의 사이트를 강조하고 사람들이 우리 사이트를 외부 링크를 가질 수 있는 가치 있는 장소로 보는지를 보고 싶었다.

나는 위키피디아가 어떻게 비디오 분야로 더 많이 옮겨가고 있는지에 대해 읽고 있었고 나는 우리의 인터뷰 중 일부가 시작하기에 좋은 장소일 것이라고 생각했다.그래서 이것 또한 내가 정말 기꺼이 토론할 수 있는 것이다.

콘텐츠를 확인하려면 www.t5m.com [1] 리차드 도킨스 인터뷰[2] 또는 레이 윈스톤 인터뷰[3]를 방문하십시오. 이러한 인터뷰는 보기 좋은 장소들이기 때문이다.

아래는 모든 성격 인터뷰 내용들의 목록이다...

시간을 내주셔서 대단히 감사하다.

타비타

안녕 타비타 (그리고 괜찮으시다면 좋겠지만, 나는 추가적인 사람들의 명단을 삭제했는데, 그 이유는 그것이 포맷이 잘 되지 않았기 때문이고, 내 생각에 사람들이 그 아이디어를 얻을 것이라고 생각한다:- - 나는 정말 도킨스 인터뷰가 즐거웠어, 그래서 우리에게 그것에 대해 알려줘서 고마워 - 이 비디오들 중 몇몇은 일부 페이지에서 참고하기에 적합할 지도 몰라, 이것은 바의 문제일 것이다.예를 들어, 기사를 쓰는 훌륭한 자원 봉사자들 - 여러분은 리차드 도킨스를 찾아가 여러분이 누구인지, 그리고 동영상에 대한 링크를 제공하는 대화 페이지에 정중하게(그리고 아마도 잠깐:-) 언급하는 것을 시도해볼 수 있다.비디오 콘텐츠가 실제로 위키백과 페이지에 포함되려면, 우리는 그것을 복사기프트 라이센스에 있어야 한다(더 많은 정보를 보려면 클릭). 즉, 기본적으로 당신은 당신의 '지적 재산' 권리 대부분을 포기한다는 것을 의미한다(예를 들어, 다른 사람들이 콘텐츠를 상업적으로 사용할 수 있도록 허용).당신이 비디오 몇 편을 공개한다면 정말 환상적일 것이고, 그렇게 함으로써 당신에게 무수한 혜택을 이야기해줄 많은 사람들이 이 주변에서:-) 다시 한번 도킨스가 고개를 들어줘서 고마워 - 나는 최근에 '조상의 이야기'를 다시 읽었기 때문에 그가 조금 더 채팅하는 것을 보는 것은 멋졌어 :-) 환호, 프라이빗 무싱스 (대화) 05:39, 2008년 11월 20일 (화)UTC)[응답하라]

WP에도 게시:VPM#비디오 인터뷰; 아마도 이 토론은 이 페이지나 저 페이지에서만 계속되어야 할 것이다, 둘 다가 아니라. -- John Brown (식별) 21:00, 2008년 11월 20일 (UTC)[응답]

빨간색 링크 클릭

무슨 일이 일어났는가?빨간색 링크를 클릭하면 기사를 만들 수 있는 편집 페이지로 이동된다.항상 이렇진 않았지?어떻게 해야 할지 모르는 새로운 사용자를 초대해 기사를 만드는 것이기 때문에 위험하다고 생각한다.WP에 대한 링크가 있다.YFA, 하지만 잘 눈에 띄지는 않는다.빨간색 링크를 클릭하면 페이지를 시작할 수 있는 이 페이지가 존재하지 않음 페이지로 이동하십시오.편집 페이지로 직접 이동하면 신규 사용자로부터 잘못 작성되고 비절제적인 기사를 더 많이 볼 수 있다.레이와스92^Talk 17:33, 2008년 11월 12일 (UTC)[응답]

내가 알기로는 항상 이렇다고 알고 있다(익명 IP의 기사 개시를 더 이상 허용하지 않는다고 믿지만 내가 생각할 수 있는 한 가지 변화). - Jmabel Talk 18:27, 2008년 11월 12일 (UTC)[응답]

그것은 그들이 할 줄 모르는 기사를 만들기 위해 새로운 사용자들을 초대하는 것이다 - 내가 메모를 놓쳤는가?언제 새로운 사용자들에게 편집을 권장하지 않았는가?나는 WP가 다음과 같은 인상을 받았다.볼드(BOLD)는 하나의 지침이었다.만약 그 기사가 비임시적이라면, 우리는 마치 비임시적 기사인 것처럼 그것과 연계되어서는 안 된다, 그것은 또한 주제일 가능성이 있다."나쁜 글"에 대해서는 - 우리는 마감일에 있지 않다(그리고 MoS의 불응은 나쁜 글과 같지 않다), 우리는 사람들이 첫 편집부터 완벽함을 요구하지 않고 경험으로 배우도록 격려해야 한다.Mr.Z-man 19:11, 2008년 11월 12일 (UTC)[응답]

Jmabel이 지적했듯이, 당신은 등록되어 있고, 다른 사람들은 페이지를 작성할 수 없기 때문에 확증되어 있기 때문에 편집 페이지로 직접 가는 것뿐입니다.로그아웃한 다음 링크를 클릭하십시오. -- 자오(대화) 21:18, 2008년 11월 12일(UTC)[응답]

그렇구나, 하지만 그건 미등록이잖아.오토콘 확증만 보이나?등록되었지만 자동 확증되지 않은 것은 여전히 기사를 작성할 수 있다.응답해 주셔서 감사합니다, Z-Man씨.처음부터 우리가 링크하는 페이지는 이미 백과사전적이어야 한다는 생각은 하지 않았다.나는 가끔 덜 비판적이 되도록 노력해야 한다.나의 반응은 기존의 기사를 편집하는 데서 경험을 얻을 수 있다는 것이지, 반드시 훨씬 더 많은 관심을 필요로 하는 새로운 기사를 만드는 데 있어 반드시 필요한 것은 아니라는 것이다.

그래, 내가 먼저 확인했어야지; 새로운 계정은 기사를 만들 수 있고 IP만 만들 수 없어. -- 자오 (토크) 22:04, 2008년 11월 12일 (UTC)[응답]

언제 우리는 새로운 사용자들이 새로운 기사를 쓰는 것을 원하지 않는다고 결정했는가?셀라노르 01:55, 2008년 11월 13일 (UTC)[응답]

어떻게 해야 할지 모르는 새로운 사용자를 초대해 기사를 만드는 것이기 때문에 위험하다고 생각한다.

이것은 위키 입니다.위키들은 급진적인 개방성에 관한 것이다.새로운 기사를 만들기 위해 특별한 권한이나 허가나 기술이 필요치 않고 그냥 하면 되고, 만약 당신이 뭔가를 망치면 누군가가 당신을 위해 그것을 고칠 것이다.그게 위키백과의 요점이야!이 개념이 불편하다면 다른 편집 장소를 자유롭게 찾을 수 있다.— Werdna • talk 13:29, 2008년 11월 14일 (UTC)[응답]

베르드나의 "위키스는 급진적인 개방성에 관한 것"이라는 지적에 공감하지만, 실제로 위키백과는 그렇게 작동하지 않는다.인용문이 없는 서투른 기사는 WP:AfD에서 끝날 것 같고, 신입 편집자는 "이 기사는 AfD에 있다" 배너를 놓칠 것 같고, 워치리스트 사용법 등을 알 것 같지 않다.흔히 볼 수 있는 결과는 신인 기사가 삭제된다는 것이다.나의 이상적인 해결책은 WP:AfD를 "WP:개선이 필요한 조항" 및 변경 WP:DELETE는 "지원 WP를 찾기 위해 합리적인 노력을 기울였다는 증거를 제시하지 않는 한 삭제는 생각도 하지 말라"고 말한다.RS와 기사 개선"이라고 말했다. 하지만 난 숨을 참을 수가 없다.위키피디아를 통해 새로운 사람들을 사귀게 하는 것이 실제로 더 친절할 수 있다.요청된 기사, 그러나 User 하위 페이지 작성 방법에 대한 명확한 지침을 제공하여 우선 그곳에서 초안을 작성할 수 있도록 하십시오. --Philcha (토크) 18:24, 2008년 11월 21일 (UTC)[응답]

링크 편집

섹션 편집 링크가 페이지 오른쪽에 있는 이유가 있는가?종종 여러 개의 이미지나 테이블이 있을 때 링크를 강제로 아래로 내리거나 옆으로 떼게 하여 a) 단면 헤더를 붙이지 않고 b) 백과사전 텍스트 자체 위에 줄을 서게 하는 경우가 있다.

독일어, 프랑스어, 이탈리아어, 그리고 나는 많은 다른 판들이 섹션 헤더 바로 오른쪽에 편집 링크를 가지고 있을 것이고, 완전히 옆으로 가는 것은 아닐 것이라고 확신한다.내 생각에 이것은 우월하다. - 전통을 떠나서 지금 우리가 가지고 있는 그대로를 가질 이유가 있을까? 자피로블루05 Talk 06:30, 2008년 11월 20일 (UTC)[응답하라]

섹션 머리글 바로 뒤에 편집 링크를 가지고 있는 내가 생각할 수 있는 한 가지 단점은 모든 섹션에 대해 같은 위치에 있지 않다는 것이다.현재 위치로는 마우스를 페이지 오른쪽 끝으로 이동하면 편집 링크가 그 근처 어딘가에 있을 것이다.당신의 제안은 편집 링크를 빨리 클릭하는 것을 더 어렵게 만들 것이다. -- 임페라이터3733 (대화) 08:16, 2008년 11월 20일 (UTC)[응답]

WP를 살펴보십시오.BUACK. 편집 링크의 잘못된 배열에 대한 토론에서 무슨 일이 일어났는지 잘 모르겠어.누군가 해결책을 제안하는 것 같더니 모든 것이 조용해졌다.나는 아직도 (IE는 아니지만) Firefox에서 이 문제를 보고 있기 때문에 솔루션이 구현되지 않았거나 작동하지 않았다고 추측한다.(실제로 버질라 토론을 보면 아직 개발자들이 이 문제를 어떻게 해결해야 할지 해결이 안 된 것 같아.)--코트니스키 (토크) 12:09, 2008년 11월 20일 (UTC)[응답]

WP:BUNCH는 관련 섹션 제목 바로 오른쪽에 배치될 편집 링크를 이동하기 위한 강력한 주장이다.마우스를 화면 오른쪽 끝으로 이동한다는 개념에 대해서는-편집자는 마우스를 머리글 레벨까지 이동해야 하기 때문에 섹션 제목을 가이드로 사용하는 것만큼 직관적으로 보인다-마우스 포인터를 단면 머리글 끝으로 이동하기만 하면 된다.

내게 있어 링크 이동에 대한 가장 강력한 논쟁은 편집을 장려하는 것이다 - 편집 링크는 화면 중앙(섹션 제목 끝)에서 맨 오른쪽에 있는 것보다 훨씬 더 두드러진다. - 존 브로턴(가급적) 20:50, 2008년 11월 20일 (UTC)[응답]

섹션 편집 링크에 대한 접근성 문제도 현재와 같다.버그 11270 및 버그 11555를 참조하십시오.Graham87 08:12, 2008년 11월 21일 (UTC)[응답]

그래, 나도 동의해.그것은 사용성을 향상시키고 고장난 접근성을 고칠 것이다.

링크는 페이지의 오른쪽에서 분리되는 것보다, 독자의 눈 바로 아래에 있는 제목 바로 오른쪽에 있는 것이 더 편리할 것이다.몇몇 새로운 독자들이 눈치채지 못한 채 기사를 통째로 읽을 수 있다고 해도 나는 놀라지 않을 것이다.이 위치에서 그것들은 시각적으로 덜 거슬리게 만들 수 있지만 놓치기 더 어려울 것이다.이러한 방식으로 배치하는 것도 기술적으로 더 쉽고 정확할 것이다. 내 브라우저에서는 H1과 H2 머리글이 너무 높으며 H4–6이 너무 낮다.이것은 또한 접근성 문제를 해결할 수 있는데, 이것은 이것들 중 어느 것보다도 중요하다.—마이클 Z. 2008-11-21 23:46 z

크리스마스를 테마로 한 DYK

위키피디아_토크에서의 토론에 대해 여기서 미리 알려야겠다고 생각했다.did_you_know#Christmas_DYK. DYK는 12월 25일 크리스마스 테마를 갖고, 크리스마스 관련 기사의 제작/확장 시기에 관한 규정을 완화하여 이 주제에 관한 더 많은 기사가 자격을 갖도록 할 것을 제안했다.이것은 올해 초 최근의 할로윈 테마와 만우절 테마와 비슷하다.다른 사용자들은 한누카, 콴자, 이슬람 설이 모두 12월 25일 주중에 하락(한누카가 실제로 겹친다)하는 등 이것이 편향적이라는 의견을 제시했지만, 해당 주제에 대한 기사는 25일 DYK 포함 대상에서 제외되거나 같은 완화 규정을 적용받지 않을 것으로 보인다.그 토론에서 더 많은 목소리가 공감대를 결정하는데 환영받을 것이다.카라낙스 (대화) 2008년 11월 20일 (UTC) 18:27 [응답]

할로윈 테마는 모르지만 만우절 테마는 규칙을 완화시키지 못했다.리틀 레드 라이딩 후드토크 01:10, 2008년 11월 21일 (UTC)[응답]

만약 이 네 개의 축제가 동시에 일어난다면, 그들 모두를 위해 DKY를 혼합해 보는 것은 어떨까?재치 있는 라마 12:44, 2008년 11월 21일 (UTC)[응답]

위키백과의 성문화된 내용

나는 성적 콘텐츠로 광범위하게 정의되는 그림들에 대한 '부정적 유용성'의 기준을 높이는 것을 목표로 하는 제안서 초안을 작성하고자 한다(예를 들어, 나는 이 모든 이미지들을 삭제하는 것을 지지할 것 같으며, 거의 모든 이미지를 위키백과에 적합하지 않다고 정의한다).이런 이미지에서 사람들의 인격권 또한 내 책에서 삭제될 가능성이 있다.

아마도 실용적으로 이것은 '프로젝트에 도움이 되는 오직 이미지만 여기에 있어야 한다'는 이론적인 바를 좀 더 강하게 적용하는 것과 동의어일 것이다.나도 그랬으면 좋겠는데, 다른 사람들이 어떻게 생각할까 궁금했어.건배, 사설 음악 (대화) 05:33, 2008년 11월 20일 (UTC)[응답]

대부분의 경우 문제의 모든 이미지가 커먼스에 있는 것은 아닐지라도 위키백과 문제라기 보다는 커먼즈 문제에 더 가깝다고 생각한다.Mr.Z-man 06:38, 2008년 11월 20일 (UTC)[응답]

'WikiPr0n' 페이지가 WP에 적합한가?사용자 페이지?나는 검열을 믿지 않지만, 위키피디아는 누군가의 포르노 컬렉션을 주최하기 위해 여기 있는 것이 아니며, 이 이미지들 중 몇 개는 제거된다면 고아가 될 것이다. --Nate1481 16:40, 2008년 11월 20일 (UTC)[응답]

다시, 그 이미지들은 Commons에 있고 무료다.그들이 고아가 될 것이라는 사실.위키피디아가 그 페이지에서 삭제되었다면, 그것들은 보관될 것인가 말 것인가와 대부분 관련이 없다.Mr.Z-man 17:16, 2008년 11월 20일 (UTC)[응답]

좋아 간단히 말해서, 위키Pr0n을 MfD에 올려야 한다고 생각하는 사람이 또 있을까? --Nate1481 17:44, 2008년 11월 20일 (UTC)[응답하라]

페이지가 예로 제시된 문제는 유용하지 않다. 왜냐하면 그것은 정말로 기사(또는 그래야만 한다)와 관련이 있고 이미지가 하원에 있기 때문에 호스트하는 것도 아니기 때문이다.오히려 편집자가 사용자 공간에 대해 수행하는 작업과 관련이 있다. 이 경우 사용자:에울랴호우컴/위키프르0n.이 내용은 위키백과에서 다룬다.사용자 페이지: 지침이 이 문제를 다루지 않는 경우(찾아보지 않은 경우), 위키백과에서 이 문제를 논의하는 것이 적절할 것이다.사용자 페이지. -- John Briton (리클립) 20:57, 2008년 11월 20일 (UTC)[응답]

위키백과를 읽으십시오.끊임없는 제안#Censor 공격적 이미지.Cacycle (대화) 2008년 11월 21일 00:46 (UTC)[응답]

Cacylce는 이미 해냈다. 그리고 나는 아직 조사할 문제가 남아있다고 느낀다.나는 이러한 이미지의 거의 대부분이 공유지에 있다는 Z의 주장을 받아들이지만, 나는 '우리'(엔위키 공동체)가 자유롭게 이야기 할 수 있고, 여기서 그러한 이미지 사용에 대한 어떤 종류의 실천/정책/지침을 확립할 수 있다고 추측한다.위키백과 같은 것을 생각하고 있다.'복사기' 미디어 저장소가 되려는 하먼스의 임무와 어떤 합리적인 표준을 제정하는 것 등과는 전혀 상관없는 성문화 콘텐츠.여기..뭐라도 시작하고, 환영 멘트 :-) 환호, 프라이빗무싱스 (토크) 02:32, 2008년 11월 21일 (UTC)[응답]

그러니까 당신이 하는 말은 "있긴 하지만, 하지만..." 기본적으로, 당신의 입장에 대해 이성적인 주장을 제시하기 보다는.당신은 단지 인격권 문제를 고수하는 것이 좋았을 것이다. 왜냐하면 그것은 당신의 개인적 혐오보다 다루기가 더 어렵기 때문이다.대부분의 경우, 현행 정책은 성적인 내용의 부적절한 사용을 방지하는데 효과적이며, 성적인 내용의 사용이 적절한 기사만 남겨두고 있으며, 따라서 포함 시 당연히 혜택을 받아야 한다.도덕적인 문제에 대해서는, 영원한 명제 입력이 전적으로 옳다, 성-확증주의 같은 것을 보아라.리나미시마(토크) 02:43, 2008년 11월 21일 (UTC)[응답]

위키백과에서 입력한 내용:성적인 콘텐츠는 굉장할 거야, 리나 - 나는 단지 노골적인 이미지가 그 프로젝트에 실제로 효과가 있는지 없는지를 조사하는 데 다소 엄격함을 적용하는 것이 타당하다고 말하는 거야.나는 당신의 주장을 전적으로 따르지는 않는다. 그 제안서들은 도덕적으로 옳다고 보장될 수 있다.(그게 네가 제안하는 거야?) - 하지만 분명히 생각하고 있어... :-) 개인 음악 (대화) 02:47, 2008년 11월 21일 (UTC)[응답]

나는 당신이 이 개인에게 공평하게 지적한다고 생각한다. 이 이미지들은 백과사전의 이익을 위해 사용되지 않고 있다. 그리고 실제로 위키피디아0rn과 같은 페이지를 가지고 있는 것은 대단히 수용적이지 않은 것 같다.그러나, 위에서 말한 바와 같이, 우리는 무엇을 할 수 있을까?이미지는 공유 기반이며, 우리가 할 수 있는 것은 아무것도 없다--Jac16888 (대화) 02:55, 2008년 11월 21일 (UTC)[응답하라]

엄밀히 말하면, 아마..그러나 우리는 커뮤니티로서 이 사진의 일부분을 다루는 최선의 방법에 대한 가이드라인이나 정책을 마련할 수 있는 권한을 부여받았다(예: 강하게 낙담하거나 사용자 공간에서조차 허용되지 않는다고 말한다). .... 위키피디아에 대해 어떻게 생각하는지 보라:성적 내용 :-) 베스트, 프라이빗뮤지션 (대화) 02:59, 2008년 11월 21일 (UTC)[응답]

"사용자 공간에서 허용되지 않음"이라고 말하는 것의 문제는 사용자 공간에서 발생할 수 있는 이러한 이미지의 유효한 학술적/편집적 사용이 있다는 것이다.'강력하게 낙담'과 같은 예선전을 추가하기 시작하면, 그러한 이미지를 싫어하는 사람들(그래서 모든 사용을 부적절하게 본다)과 이를 사용해야 하는 사람들(적절한 기사를 편집할 때) 사이에 무의미한 논쟁이 나타날 것이다.단일 사용자 페이지에 문제가 있거나 해당 사용자 페이지에 문제가 있을 경우 실제 문제를 해결하십시오.리나미시마(토크) 03:10, 2008년 11월 21일 (UTC)[응답]

영원한 명제 입력에 관한 당신의 선택에 흥미롭다 - 나는 그것이 도덕적인 문제를 다루는 반면, 당신은 그 영원한 명제 입력 자체가 도덕적으로 옳지 않을 수도 있다고 말했다.이로 인해 나는 당신이 순수하게 이성적인 이미지보다는 이런 유형의 이미지에 대해 개인적인 도덕적 반감을 가지고 있다고 의심하게 된다.나는 이미 거기에 의견을 주었고, 현재의 합의는 WP와 편향된다고 믿는다.이미지 및 WP:IUP는 당신에게 처음이라고 강력하게 의심하고 있다(WP 이후:IUP는 인격권 문제를 다룬다).리나미시마(토크) 03:10, 2008년 11월 21일 (UTC)[응답]

내 생각엔 '전혀 따라오지 마' 비트가 더 정확했을 것 같아! 미안해!아마도 내가 특정 페이지나 당신의 '더 큰 그림'을 강조하기 보다는 위키백과의 의견 불일치를 통해 이야기함으로써 우리는 타협점을 찾을 수 있을 것이다.성적 콘텐츠 제안?건배, 사설 음악 (대화) 03:14, 2008년 11월 21일 (UTC)[응답]

나는 이미 거기에 내 입장문을 남겼다.합의는 모든 정당들 사이의 중간 지점을 찾는 것이 아니라 가장 강력한 근거 세트에 합의하는 것이라는 것을 기억하기 바란다.지금까지 당신은 그 제안에 반대하는 어떠한 근거도 반박하지 못했는데, 다만 당신의 사회는 이미지에 반대하며, 당신은 합의를 이용해야 한다고 믿는다고 진술하는 것 외에는 말이다.리나미시마 (대화) 03:21, 2008년 11월 21일 (UTC)[응답]

나는 왜 '성별화된 내용'에 대한 별도의 기준이 있어야 하는지 알 수 없다.
—Apis (대화) 03:17, 2008년 11월 21일 (UTC)[응답]

글쎄, 만약 그것이 다른 정책들의 종합이나 그 어떤것이라면, 그것은 여전히 지역사회의 합의를 통해 대화하고 발전시킬 수 있는 좋은 장소로서 유용한 기능을 할 수 있을 것이다.너는 지금 그것들 중 어느 것에 반대하니?사설 음악 (대화) 03:18, 2008년 11월 21일 (UTC)[응답]

WP:CREIPLinaMishima (대화) 03:22, 2008년 11월 21일 (UTC)[응답]

그래 - 우리가 조심해야 한다는 네 말이 맞는 것 같아, 리나 - 하지만 WP:CREP의 위험성을 명심하는 게 최선책일 거야:-) 사설 음악 (토크) 03:25, 2008년 11월 21일 (UTC) 회신

당신은 WP가 다음과 같은 사실을 명심해야 한다.이미지 및 WP:IUP는 이미 이 이슈뿐만 아니라 보다 일반적인 사례도 충분히 커버하고 있는가? (즉, 이 제안은 WP에 불과하다:정의상 CREF는 WP를 침해할 심각한 위험을 안고 있다.NOT) 리나미시마 (대화) 03:29, 2008년 11월 21일 (UTC)[응답]

리나 - 네가 이 모든 것에 대해 완전히 결심이 섰다는 건 확실해! - 난 내가 WP라고 믿고 싶어.WP:CREP는 아니지만, 내가 도대체 여기서 가끔 뭘 하고 있는지 궁금하긴 하지만;-) - 어쩌면 너와 나는 잠시 다른 몇 사람에게 물건에 대해 이야기해야 할지도 몰라, '우리가 서로 지나쳐 이야기하는 위험이 있다고 생각하기 때문에...best, Privatemusings (talk) 03:33, 2008년 11월 21일 (UTC)[응답]

나는 너에 대해 잘 모르지만, 나는 댓글을 읽고 나서 그들의 주장을 합리적으로 다루고 있어. 그리고 단순히 불편한 것들을 무시하는 게 아니야.그게 도움이 되는 것 같아.리나미시마(토크) 03:39, 2008년 11월 21일 (UTC)[응답]

글쎄, 나는 왜 '성별화된 콘텐츠'에 대한 특별한 기준이 필요한지 이해할 수 없어.만약 인격권에 문제가 있다면, 그것은 단지 '성별화'된 것이 아니라 모든 이미지에 적용될 것이다.이 제안은 '성별화된 이미지'를 포함하는 것에 대한 '법률 제고'에 더 관심이 있는 것 같은데, 나는 그렇게 하는 어떠한 이유도 없다고 본다.
—Apis (대화) 03:46, 2008년 11월 21일 (UTC)[응답]

나는 성적인 내용(성적인 성적인 것이 아니라, 내 뜻에 전혀 맞지 않는다는 지적을 받아왔다! 미안해..)은 우리가 (프로젝트로서) 많은 물질보다 (좋은 웹 시민으로서) 책임지고 있다는 것을 확실히 하는 것에 있어서 더 엄격함을 보증한다.또한 특정 커뮤니티 토론/지침/정책 등을 옹호하는 것이 타당하다고 생각하는 특정 이미지 부분집합이다(예를 들어, 토론할 가치가 있는 또 다른 부분집합으로서 그래픽 폭력적인 이미지를 지적한다).폭력적인 이미지와 같은 민감성의 영역이나 이 경우, '포함할 현재의 합의'가 조금 도움이 될 수 있는 기사 공간에 그러한 이미지의 사용을 제한함으로써 '바를 높이겠다'고 말하는 발상에 대해 어떻게 생각하십니까?건배, 사설 음악 (대화) 05:18, 2008년 11월 21일 (UTC)[응답]

위키피디아에 병든 것들이 있다고 생각하는데, 우리는 다음 세대의 보수주의자들이 포르노 때문에 위키피디아 황금지식을 포기하도록 몰아가야 한다. 우리는 그 기준에 대한 기준을 높여야 한다.포르노 기사가 그림 참고문헌을 가지고 있지 않다면 누가 신경이나 쓰겠어? 위키피디아는 일반 참고문헌과 사람들을 멍청하지 않게 하기 위해 여기서 섹스하는 법을 보여주기 위해 여기 있는 게 아니야.내 책에서 이 사진들은 어떤 기사에도 실려서는 안 된다. --자하루어 (토크) 05:29, 2008년 11월 21일 (UTC)[응답하라]

<- 내가 보기에 몇몇 이미지는 기사에 유용하지만, 위의 컬렉션은 백과사전이 아니다.그래서 여기서 삭제할 페이지(이미지 제외)를 지정했다.위키백과:삭제/사용자:Ellyahoocom/WikiPr0n --Nate1481 11:54, 2008년 11월 21일 (UTC)[응답]

사설 음악, 당신은 이 '좋은 웹 시민' 줄을 10번 정도 반복했지만, 왜 성적인 콘텐츠가 우리를 '나쁜 웹 시민'으로 만드는지는 설명하지 않았다.자세히 설명해 주시겠습니까?— Werdna • talk 23:23, 2008년 11월 22일 (UTC)[응답]

물론 :-) - 하지만 토론의 초점을 더 좋은 곳에 맞추려면, 이것을 토크 페이지로 가져가겠다. (내가 너의 게시물을 복사해서 응답하겠다) :-) 사설 음악 (대화) 23:30, 2008년 11월 22일 (UTC)[응답하라]

구글 애널리틱스

위키피디아는 각 페이지 등에서 조회 수를 셀 수 있는 서버 자원이 없다는 말이 자주 나왔다.그렇다면 왜 구글이 그것을 하도록 내버려 두지 않는가?만약 위키피디아가 구글 애널리틱스에 등록되었다면, 우리는 모든 기사와 많은 다른 유용한 통계에 대해 히트 수를 얻게 될 것이다.모바일 장치로부터 얼마나 많은 트래픽이 전달되었는지).나는 구글이 보통 월 500만 페이지뷰 이상의 사이트에 적용되는 AdWords의 하루당 US$1의 요구사항을 기꺼이 포기할 것이라고 확신한다.네온머린 00:56, 2008년 11월 22일 (UTC)[응답]

그렇다면 http://stats.grok.se/은 어떻게 작동하는가?씨릴랜드 (대화) 01:07, 2008년 11월 22일 (UTC)[응답]

WMF 개인 정보 보호 정책은 구글과 같은 제3자에게 IP 데이터를 제공하는 것을 금지한다.드래곤즈 비행 (토크) 08:01, 2008년 11월 22일 (UTC)[응답]

우리는 서버 자원이 부족하지 않다.현재 작업 중인 위키백과에 통합된 뺑소니 시스템이 부족하다. — Werdna • talk 07:41, 2008년 11월 22일 (UTC)[응답]

물품의 점성술 기호

기사의 점성술 표지를 그들의 생일 옆에 나열하는 것은 어떨까?어느 표지에서 태어났는지 궁금할 독자들이 많을 것 같다.이 제안이 이미 이루어진 것이라면, 자료집 더미를 뒤지는 것은 시간이 많이 걸리는 일이므로 용서하십시오. --Crackthewhip775 (대화) 01:25, 2008년 11월 22일 (UTC)[응답]

첫째, 점성술의 부호를 추가하는 것은 그러한 어리석음에는 어떤 장점이 있다는 암묵적인 제안을 뒷받침해 줄 것이기 때문이다.

(내가 어리석다고 말할 때, 그렇다, 나는 과학의 역사에서뿐만 아니라 전근대 사회에서 점성술의 역할을 알고 있다.그러나 나는 대신에 컴퓨터를 이용하여 이 백과사전에 접근하는 사람들의 세계관에서의 점성술의 평균적인 역할에 대해 논하고 있다.위키피디아가 믿을 만한 출처가 아니라는 것을 깨닫는 동안, 나는 점성술에 관한 기사를 인용한다.점성술은 수많은 통제된 연구에서 그 효과를 반복적으로 입증하지 못했다. 점성술의 효과 크기 연구는 점성술 예측의 평균 정확도가 우연히 예상되는 정확도보다 크지 않으며, 중요한 검사에서 점성술의 인지된 성능이 사라졌다고 결론짓는다.)

둘째로, 그런 헛소리를 신빙성 있게 소비하는 저 불쌍한 착각하는 영혼들은 쉽게 이런 비정보를 스스로 찾아낼 수 있기 때문이다.

나는 일본 별자리에 관한 위키피디아 기사 무더기가 그들의 혈액형을 제공한다는 것을 알고 있다. 물론 이것은 비슷한 두발이지만 아마도 일본 별자리에 관한 기사 편집자와 독자들의 불균형한 수는 매우 젊을 것이다. (그 대신에 그들이 "도전당했다"고 생각하기는 싫다.)타마1988 (대화) 08:32, 2008년 11월 22일 (UTC)[응답]

끔찍한 생각인 것 같아.나 역시 혈액형이 기사에 들어가서는 안 된다고 생각하고, 확실히 믿을 만한 출처에 대한 언급이 없으면 안 된다고 생각한다. 더그웰러(토크) 18:52, 2008년 11월 22일 (UTC)[응답]

나는 이것이 그렇게 나이 문제가 아니라 오히려 일본의 문화라고 믿는다.내가 이해한 바와 같이, 현재 혈액형이 의미 있는 것이라는 믿음이 있고, 따라서 일본 독자들은 세부적인 것을 발견하기를 합리적으로 기대할 수 있다(물론, WP:V는 다른 문제다).생년월일이 이미 이 사실을 알려주고 있는 별표지와 달리, 누군가의 혈액형을 익히는 유일한 방법은 그것을 듣는 것이다.그리고 혹시 위키피디아가 언젠가 구급대원을 도와줄지도 몰라! :P 리나미시마 (토크) 00:40, 2008년 11월 23일 (UTC)[응답]

사람들이 실제로 신경 쓴다면, 그들은 생일을 기준으로 그것을 알아낼 수 있다.그렇지 않으면 그것은 그저 관계없는 잡동사니일 뿐이다.Mr.Z-man 20:34, 2008년 11월 22일 (UTC)[응답]

제안된 변경사항: {{}POV} / {{NPOV}}

• 템플릿:시점 (토크 내역 링크 감시 로그 편집)

템플릿 토크에 적합한 위치:POV는 많은 사람들이 그 페이지를 보지 않는 것 같아서 내가 이걸 가지고 올게.

위키백과에서 널리 사용되는 템플리트는 현재 다음과 같이 읽는다.

이 글의 중립성은 논쟁의 여지가 있다.

의 배치.{{NPOV}}술래잡기는 편집 전쟁과 원한을 품은 분쟁의 가장 빈번한 원인 중 하나이다.그 이유는, 내 생각에, 매우 명백하다.의 추가.{{NPOV}}단순히 기사에 대한 코멘트가 아니라 간접적으로 기사 내용에 영향을 미친다.기사의 중립성을 "분산"이라고 표시함으로써, 그것은 독자들에게 그 기사에 편견이 포함되어 있음을 시사한다. - 이것이 우리가 이 태그를 둘러싼 많은 편집 전쟁을 가지고 있는 이유인데 - 그것을 대체로 중립적인 기사에 추가하는 것은 기사를 중립성에서 멀어지게 하는 역할을 한다.

더 논쟁적으로, 나는 토론을 통해 선호하는 버전에 대한 합의를 이루지 못한 편집자들이 의 사용에 의존하는 경우를 여러 번 보았다.{{NPOV}}최악의 경우, 기사를 왜곡하거나 기껏해야 지구를 태우기 위해.둘 다 용납할 수 없다.

요컨대, 그 방법이{{NPOV}}종종 사용되는 것은 중립적인 관점 정책과 상충된다.

따라서, 나는 템플릿의 표현을 바꾸거나 템플릿의 사용을 줄이고 싶다.나는 다음과 같은 문구를 제안한다.

이 글의 중립성이 논의되고 있다

나는 다른 단어들에 대한 어떤 논평이나 어떤 제안에도 매우 흥미가 있을 것이다.

씨릴랜드 (대화) 00:44, 2008년 11월 22일 (UTC)[응답]

"중립성"은 특정한 기술적 의미를 가진 위키피디아 용어의 ar이다.이런 구체적인 내용에 익숙하지 않은 이들이 주로 읽는 기사 페이지에 이런 메시지가 나타나기 때문에 이 글의 공정성에 대한 논의가 진행 중임을 시사한다.DGG (대화) 23:52, 2008년 11월 23일 (UTC)[응답]

좋은 지적이야!당신이 제안한 문구는 또한 WP를 강화하는 데 도움이 될 것이다.내 경험상 '중립성'은 종종 편집자들이 잊게 하는 것처럼 보이는 FRY.리나미시마(토크) 01:15, 2008년 11월 24일 (UTC)[응답]

나는 "중립성"을 가진 문제에 대해 DGG에 동의한다.내가 좋아하는지 아닌지는 잘 모르겠지만, 또 다른 아이디어는 "이 기사의 공정성과 균형에 대해 논의 중"이고 "[토크 페이지]에"를 추가할 수도 있다.씨릴랜드 (대화) 02:59, 2008년 11월 24일 (UTC)[응답]

사람에 관한 새 페이지 제출

지방 공무원인 경찰청장의 전기(및 관련 이야기/현안)에 대한 페이지를 제출할 수 있는지 알고 싶다.이것이 가능하다면 나에게 알려줘.나는 사이트를 돌아다녔는데 이것이 괜찮은지 그리고 만약 괜찮은지, 제안된 기사/페이지를 어디에 제출해야 할지 결정하지 못했다.

데이브 더피

위키피디아는 누구나 기고할 수 있다 - 관계자에 대한 기사를 작성하고 지역사회가 그것에 대해 어떻게 생각하는지 봐봐!그러나 우리의 정책과 가이드라인을 명심하고, 만약 그 기사가 그 가이드라인을 충족하지 못한다고 생각될 경우 삭제될 수도 있다는 점을 이해해 주기 바란다.가장 중요한 것은, 당신이 열거한 모든 세부사항들이 검증가능하고 신뢰할 수 있는 출처에서 나왔는지 확인해야 한다는 것이다.살아 있는 사람에 대해 글을 쓸 때 써야 할 구체적인 규칙도 있고, 사람에 대한 공신력 가이드라인도 있는데, 이 가이드라인은 사람이 눈에 띄면 질 좋고 오래 지속되는 기사가 될 수 있을 정도로 판단하는 방법을 조언한다.행운을 빈다!리나미시마(토크) 00:36, 2008년 11월 23일 (UTC)[응답]

안녕 데이브.리나미시마의 말처럼, 그래, 누군가에 관한 기사를 만들어도 괜찮아.내 생각에, 가장 생각해야 할 것은 공신력 가이드라인이다.간략한 개요를 보려면 "기본 기준" 섹션을 참조하십시오.사람에 대한 새로운 기사는 믿을 만한 출처를 인용함으로써 그들이 주목할 만하다는 것을 보여주어야 한다.솔직히 말해서, 만약 충분한 편집자들이 기사의 주제가 눈에 띄지 않는다고 생각한다면, 그 기사는 아마 삭제될 것이다.포맷의 세부 사항들에 대해 너무 걱정하지 마, 다른 편집자들은 나중에 그것을 고칠 수 있어.제안된 기사를 어떻게 제출할 것인가에 대해서는 그냥 진행해서 기사를 작성하는 것이 절차다.계좌가 있어서 가입해야 할 텐데, 그 부분은 쉬워.위키피디아를 읽기를 추천한다:자습서, 그것은 매우 짧고 모든 중요한 기본을 다룬다.즐겁게 보내세요— 2008년 ^(Talk) 11월 23일 (UTC) 13:06 [응답]

아티클 툴팁

내가 관심 있는 주제(특히 내가 전문가가 아닌 주제)를 읽을 때마다 나는 단지 사물이 무엇인지 알기 위해 기사 안의 파란색 링크를 많이 클릭하는 나 자신을 발견한다.이것은 내가 트릴리언으로 알려진 채팅 클라이언트의 특정한 특징을 생각나게 했다.트릴리언에서, 대화에 등장하는 특정 단어들은 위키피디아에 있는 그 페이지의 짧은 미리보기와 함께 툴팁을 얻기 위해 섞일 수 있다.나는 이것이 위키피디아의 파란색 링크에 적용하기 위해 매우 유용한 기능이 될 것이라고 생각한다.이렇게 하면, 독자는 링크 위로 마우스를 가져가서 빠른 정의나 설명을 할 수 있고, 더 읽고 싶으면 클릭해서 기사를 열 수 있다.독자는 단지 단어가 무엇을 의미하는지 알기 위해 다른 기사를 전부 열 필요는 없을 것이다.나는 위키피디아가 어떻게 작동하는지 깊이 이해하지 못하지만, 가능하다면 기사 툴팁이 위키피디아에서 매우 유용한 기능이 될 것이라고 생각한다.DE5933 (대화) 2008년 11월 23일 (UTC) 16:47 [응답]

팝업이랑 비슷한 것 같은데대수학자 16:50, 2008년 11월 23일 (UTC)[응답]

이전의 이름, 제목, 좌우명, 슬로건, 그리고 화친을 한 곳에 두어라.

User:에서 테스트 템플릿을 만들었다.JSH-alive/Sandbox/Testground(또는 특정 개정판의 경우 http://en.wikipedia.org/w/index.php?title=User:JSH-alive/Sandbox/Testground&oldid=253731034).어떤 종류의 인포박스도 넣을 수 있다.코멘트 환영 - JSH-alive 04:29, 2008년 11월 24일 (UTC)[응답]

WP:DASH

Wikipedia_talk에서 토론 내용을 읽어 보십시오.Manual_of_Style#Categories.

• WP:DASH

이는 WP의 섹션과 관련이 있다.MOS는 "대시"와 범주 공간에 적용되어야 하는지에 대해 언급한다.

이 섹션은 자동 리디렉션이 이루어질 수 있다고 가정한다(주공 공간 및 기타 공간에 일반적인 경우).

그러나 카테고리 스페이스에서는 그렇지 않다.우리는 그곳의 소프트 리디렉션에 한정되어 있다.(그리고 어떤 봇에 대한 염려가 있는 것 같다.자세한 내용은 토론을 참조하십시오.)

그래서 현실적으로, 만약 이 섹션이 적용된다면, 우리는 그것의 이름에 "대시"가 있는 모든 카테고리를 복제할 것이다.

또한 범주가 방향을 바꾼다는 것은 그들이 실수라는 것을 의미한다.그것은 그들이 그들 스스로 분류될 가능성이 있다는 것을 의미하며, 이것은 문제를 일으킬 수 있고, 그것은 무심코 보는 사람이 알아차리지 못할 수도 있다.

또한 범주의 전체 요점은 항법(WP:CAT에서 언급된 바와 같이)이다.따라서 키보드에 "엔 대시"가 없는 사람들이 카테고리 이름을 더 어렵게 만들도록 강요하는 것은 네비게이션을 방해하는 것처럼 보일 것이다.

그러므로 나는 범주가 WP:DASH의 예외일 것을 제안하고 싶다. 따라서 범주의 경우 하이픈이 선호되는 구두점이 되어야 한다.- jc37 07:20, 2008년 11월 4일 (UTC)[응답]

• 위의 인수에 대한 응답:

1. 리디렉션은 봇이 처리한다. 사용자:러스봇.이 봇이 어떻게 작동하는지에 대한 특별한 우려는 아직 제시되지 않았다. - 그것은 그 일을 잘 하는 것 같다.
2. 기사처럼 중복이 실제로 일어날 것이다.그러나 만약 제안이 받아들여진다면, 우리는 아마도 거기에서 대시를 기대하는 사람들을 위해 어쨌든 범주를 복제해야 할 것이다.
3. 리디렉션 자체가 분류될 가능성은 모든 리디렉션에 적용되며, 어쨌든 중요한 문제는 아니다.
4. 내비게이션 문제는 리디렉션자들에 의해 해결된다. - 이미 내장된 검색 상자 기능으로 해결되지 않았다면, 내 생각엔.--Kotniski (토크) 16:57, 2008년 11월 4일 (UTC)[응답]

코트니스키: 미안하지만 너는 범주가 어떻게 리디렉션되는지 이해하지 못하는 것 같아. (아니면, 얼마나 나쁜지.)

--David Göthberg (대화) 2008년 11월 4일 (UTC) 18:19[응답]

그게 누구 잘못이지?나는 계속 설명을 요구하는데, 아무 말도 듣지 않는다.그러므로 나는 자연스럽게 이 "문제"들이 단순히 누군가의 발명품이라고 결론짓는다.그들이 무엇인지 말해주면 아마 내 의견을 바꿀 거야.--코트니스키 (토크) 15:58, 2008년 11월 5일 (UTC)[응답]

카테고리 리디렉션 같은 것은 정말 없다.범주 A를 클릭한 사람들이 범주 B를 더 클릭한다는 것을 암시하는 텍스트를 읽을 수 있도록 허용하는 템플릿 {{Category redirect}만 존재한다.이것은 진정한 리디렉션보다 훨씬 더 약하고 덜 유용하며, 개발자들이 고칠 수 있었지만 그러지 못한 또 다른 사례다.2008년 11월 5일(UTC) 19:26, Septionrionis PMaenderson (UTC)[응답

짚 폴

반대(엔/엠 대시 선호)

• 스타일에 필요할 때 대시를 사용해야 한다는 적절한 지침에 명시적으로 언급하는 것에 반대 및 지지.범주 이름에 대시가 있다고 주장되는 문제는 가상으로 나타난다.대신 하이픈을 사용하면 기사 이름 및 기타 기사 텍스트와 불일치하여 독자의 출력이 저하될 뿐만 아니라 보다 문학적 또는 직관적인 편집자의 입장에서 과장(또는 잘못된 붙여넣기)이 발생할 수 있다. --Kotniski (토크) 09:34, 2008년 11월 4일 (UTC) 응답 [응답]

  토론에서 다른 사람들의 우려를 고려할 때, 어떻게 그 문제들이 "상상적"이라고 주장할 수 있을지 모르겠다. - jc37 10:16, 2008년 11월 4일 (UTC)[응답]

  글쎄, 내가 알고 있는 모든 우려는 해결되었다.진짜 문제가 있다면 들어보자.--코트니스키 (대화) 13:29, 2008년 11월 4일 (UTC)[응답하라]

• 반대 RussBot 수명의 부족이 우려되는 정도라면 하이픈으로 연결된 타이틀에서 부드러운 리디렉션이 충분하므로 범주 이름에 대해 MOS:DASH를 예외로 둘 필요는 없다.하지만, 만약 러스봇에게 무슨 일이 일어났다면, 다른 누군가의 봇이 그 일을 맡는 것은 그리 큰 문제가 되지 않을 것이다.봇 소스는 심지어 이용가능하기 때문에 필요한 것은 누군가 피위키피디피디아를 설치하고 그것을 실행하기 시작하는 것이다.Anomie⚔ 21:55, 2008년 11월 4일 (UTC)[응답]
• 반대한다. 범주는 어떤 명명 지침의 예외가 되어서는 안 된다. 그것들은 백과사전의 일부분이며 기사와 동일한 명명 지침을 준수해야 한다.또한 특정 사용자의 키보드에 특정 문자가 없는 것은 어떤 이름 지정 지침에서 고려해서는 안 되며, 이름 지정 지침은 특정 사용자가 키보드를 입력할 수 있는지 여부와 상관없이 올바른 이름을 사용하는 것이어야 한다.MTC (토크) 16:59, 2008년 11월 5일 (UTC)[응답]
• 반대—문제를 해결할 수 있고, 우리는 현재 수용 가능한 이상적인 해결책을 가지고 있다.우선 범주 공간에 선호되는 전자파/엔 대시(em/en dash)를 허용하면 나중에 더 나은 범주 리디렉션 시스템으로의 전환을 용이하게 할 수 있으며, 범주 페이지에 대한 기사 이름 또는 둔감한 예외사항과의 충돌을 피할 수 있다.{{Nihiltres talk log}}} 2008년 11월 5일(UTC) 17:21[응답]
• 반대. WP를 읽은 편집자:DASH 또는 en-dash로 기사의 이름을 딴 범주를 만들고 있는 DASH는 어차피 en-dash로 명명된 범주를 만들게 되므로, 범주 리디렉션의 실효성은 뒷받침할 이유가 되지 않는다.그것은 스타일에 일관성을 유지하도록 하는 주된 이유로 남긴다.— Arthur Rubin (talk) 18:58, 2008년 11월 6일 (UTC)[응답하라]

  만약 이 제안이 합의를 이룬다면, WP:DASH는 이를 반영하도록 업데이트될 것이다.그리고 그것은 또한 그 범주들의 이름을 바꾸는 것이 더 빠를 것이라는 것을 의미할 것이다.따라서 범주는 일관성이 있을 것이다. - jc37 19:11, 2008년 11월 6일 (UTC)[응답]

  그래, 서로(적어도 현 상황에 대한 개선책이 될 것이다.)그러나 기사 공간과 일치하면 더욱 좋을 것이다(외모용 뿐만 아니라 사람들이 이 두 공간 사이를 '복사'하고 붙일 가능성이 높기 때문이다).--코트니스키 (토크) 09:52, 2008년 11월 7일 (UTC)[응답]

지원(하이픈 선호)

• 지원 - 범주가 (대상 범주로 자동 분류) 필요한 대로 작동하도록 리디렉션될 때까지, 범주는 확산되지 않고 피할 수 있는 것이어야 한다.Mr.Z-man 17:51, 2008년 11월 4일 (UTC)[응답]
• 지원 봇에 의존하는 제안된 시스템은 내 취향에 맞지 않게 배심원제가 너무 까다롭다.미디어위키에서 이것을 할 수 있는 내장 기능을 얻을 수 있다면, 나는 카테고리의 en/em 대시에도 괜찮을 것이다.MBisanz 17:59, 2008년 11월 4일 (UTC)[응답]
• 지원 - 항상 키보드에서 카테고리 이름을 입력하는데 키보드에 En 대시 기능이 없어.그리고 그것은 카테고리 이름을 복사하고 붙여넣는 것을 더 어렵게 만든다.(그래, 우리 중 일부는 운영체제가 불량한 낡은 컴퓨터에 갇혀 있어, 새 컴퓨터를 살 여유가 없었던 것을 용서해 줘.)그러나 가장 중요한 것은 RussBot이 작동을 중지할 경우 범주 리디렉션 시스템이 어느 정도 파손된 상태에서 매우 손상된 상태로 전환되므로 범주 리디렉션에 의존할 수 없다는 것이다.그러나 봇이 실행 중일 때에도 카테고리 리디렉션에 일부 문제가 있으므로 리디렉션에 의존하지 않는 것이 좋다. --David Göthberg (토크) 18:19, 2008년 11월 4일 (UTC)[응답]
• 범주가 작업을 리디렉션할 때까지 지원Dendodge Talk^Contribs 22:03, 2008년 11월 4일 (UTC)[응답]
• 지원 나는 애초에 Em dash나 En dash에 대한 진정한 필요성을 느끼지 못한다.레이와스92^Talk 22:10, 2008년 11월 4일 (UTC)[응답]
• 지원 사물은 주위에 쉬운 방법이 존재하지 않는 한 인간형이어야 한다.리디렉션이 고정되면 대시를 사용할 수 있다.제화공휴일 (토크) 07:03, 2008년 11월 5일 (UTC)[응답]
• 지원 범주가 리디렉션되는 방식을 고려할 때 범주를 할당할 때 En/em 대시를 사용할 수 없는(또는 원하지 않는) 경우 WP:DASH. Alanson (talk) 15:40, 2008년 11월 5일(UTC)[응답]
• 범주가 리디렉션될 때까지 하이픈을 지원하여 문서를 올바른 범주로 자동 분류하십시오.봇에 의존하는 것은 문제가 되고, 하이픈을 사용하는 것은 그것을 없앤다. --Kbdank71 16:10, 2008년 11월 5일 (UTC)[응답]
• 설명:이미 반박된 주장을 되풀이하는 대신 왜 반박이 잘못됐다고 생각하는지 그 이유를 표결에 부칠 수 있다면 더 도움이 될 것이다.그러면 우리가 실제로 어딘가에 도착할지도 몰라.이것은 표를 세는 것으로 해결될 문제가 아니다; 그것은 우리가 서로 협력하여 식별하고 (가능한 경우) 해결해야만 하는 실제 기술적 문제들을 포함한다.지지부진한 주장을 믿는 사람이 몇이나 되는지만 세어봐도 별로 건설적인 진행방식은 아닌 것 같다.--코트니스키 (토크) 16:13, 2008년 11월 5일 (UTC)[응답]
  • "분명히"가 그 곳의 핵심 단어다.나는 네가 어떤 논쟁도 반박하지 않았다고 생각한다.당신은 계속해서 우리가 어떤 문제에 대한 기술적인 해결책, 편집자, 독자, 러스, 그리고 이제 훨씬 더 간단한 해결책이 범주 이름에 타이핑 가능한 하이픈을 사용하는 것일 때 더 많은 작업을 필요로 하는 기술적 해결책에 의존해야 한다고 말한다.미안하지만, 나는 여전히 모든 사람들이 이 모든 후프를 통과하도록 강요하는 "스타일" 주장을 믿지 않는다. --Kbdank71 16:39, 2008년 11월 5일 (UTC)[응답]
    • 일 더?후프? 누구를 위해서?편집자들은 그렇게 게으른 경우에도 여전히 하이픈을 칠 수 있다. (이 같은 편집자들이 쓰고 있는 기사에 대시가 필요할 때 어떻게 하는지 궁금하다.); 독자들은 분명히 범주 이름을 입력할 수 있는 (매우 드문) 경우에 하이픈을 입력할 수 있다; 그리고 범주 리디렉션의 문제가 훨씬 더 광범위하기 때문에 봇 소유자와 개발자는 하이픈과 대시 때문에 추가 작업을 하지 않을 것이다.나는 어떤 사람들은 "스타일"을 중요하게 여기지 않거나 WP 전체가 ASCII로 되어 있는 것을 선호한다는 것을 알고 있지만, 공동체는 백과사전이 이용 가능한 모든 범위의 문자를 사용하여 훌륭하고 일관된 영어 스타일을 따르기를 원하며, 우리는 그 va를 유지하기 위해 (적어도 아주 사소한) 희생을 할 준비가 되어 있어야 한다고 오랫동안 결정했다.루아블 목표. (그리고 우리는 이 특정 범주 문제를 지역사회 합의에 반하는 것으로 알고 있다면 일반적으로 구두점에 대한 우리의 견해의 분출구로 사용해서는 안 된다.) --코트니스키 (토크) 17:40, 2008년 11월 5일 (UTC)[응답]
• 지지하다.애초에 왜 대시가 필요한지 모르겠어.나는 "스타일"에 대한 주장에 납득할 수 없다; 나는 대시들이 추악하고 그것들이 구체적으로 논의되지 않는 한 전혀 사용되어서는 안 된다고 생각한다; 우리는 가능한 한 유용성을 위해 ASCII 세트의 "실제" 문자를 사용하는 것을 목표로 삼아야 한다. 프로젝트 전체에 이런 종류의 번식을 뿌리지 말아야 한다.셀라노르 17:33, 2008년 11월 5일 (UTC)[응답]

• ASCII = 실제?맞춰볼게 - 너 컴퓨터 과학자 맞지? --Kotniski (토크) 17:47, 2008년 11월 5일 (UTC)[응답하라]

• 긍정하다.UTF-8에 있지만, 완벽하게 좋은 ASCII 동급이 있을 때는 사용할 필요가 없다고 본다.나는 그것이 어떤 이점을 더한다고 생각하지 않는다; 사실, 나는 그것이 하이픈보다 더 못생겼다고 생각하기 때문에 나는 이것을 해야 할 어떤 이유도 없다고 본다.2008년 11월 5일(UTC) 17시 52분 셀라노르(Celarnor)[응답]

• 지지하다.대시를 요구하면 "범주 리디렉션"이 실제 리디렉션보다 심각하고 하이픈에서 엔다쉬로 리디렉션되지 않는 범위 내에서 독자가 범주를 사용하고 자문하는 것이 더 어려워질 것이다.[[카테고리:] 입력푸[하이픈]바 [범주:Foo[Dash]Bar]가 존재하며 이 규칙이 없었다면 하이픈으로 제목이 붙여졌을 가능성이 있는 최악의 결과물이다.논쟁의 여지가 있는 활자를 위해 이 모든 것을 하는 것은 부적절하다.2008년 11월 5일(UTC) 19:32, Sentrionalis PMAnderson (19:32,

카테고리 리디렉션이 존재하며 지속적으로 설명되고 있는 것처럼 작업을 수행한다.그들은 심지어 봇에 의지하지도 않는다.봇은 리디렉션된 범주의 페이지를 대상 범주로 옮기기만 하면 된다(편집자가 범주를 잘못된 이름으로 선언하는 경우는 드물다).--코트니스키(토크) 11:57, 2008년 11월 6일(UTC)[응답]

그들의 "일하는 것"의 예를 보여 주시오. 내가 본 것은 별로 효과가 없다.패혈성PMANDerson 18:32, 2008년 11월 6일 (UTC)[응답]

음, 리디렉션에는 두 가지 유형이 있다. 딱딱함과 부드러움직임.딱딱한 것은 정상적으로 작동하고, 부드러운 것은 추가적인 클릭이 필요하다.범주:폴란드 토픽은 부드러운 것의 한 예다; 폴란드 토픽의 이전 화신(봇이 그것을 바꾸기 전의 역사를 보라)은 딱딱한 토픽의 한 예였다.봇이 다루는 방향 전환은 부드러운 것이어야 한다는 믿음(아마도 우리가 이 토론에서 보았던 것과 같은 종류의 미신에 기초했을 것이다, 그러나 아마도 그것에는 진정한 이유가 있을 것이다)이 있는 것 같다.이것은 매우 드문 경우에 독자들이 카테고리 이름을 검색 상자에 입력하고 해당 카테고리가 리디렉션되는 추가 클릭을 의미한다.일을 안 한다는 게 이런 뜻이야?아니면 기사가 "잘못된" 범주에 추가되는 것과 올바른 범주로 옮겨지는 것 사이에 시간 지연이 있다는 사실일까?드문 추가 클릭이 문제가 된다고 생각되면, 가장 좋은 해결책은 하드 리디렉션을 추진하는 것이다(대상 페이지에 메시지가 있음 - 어쨌든 여기에 있어야 함 - 임시로 [ 리디렉션된 고양이에 대한 하드 링크]로 분류된 추가 페이지가 있을 수 있음).또 다른 문제인 시간 지연은 물론 이미 제기되었고, 우선 편집자들이 올바른 범주에 기사를 넣는 것으로 (중요하다고 느껴지면) 가장 잘 해결된다.대시 입력은 사실 큰 문제가 아니다(지금쯤이면 영어로 글을 쓰는 진지한 편집자들이 모두 익숙해졌다고 생각한다). 실제로 기사 텍스트의 구절을 복사하고 붙여넣을 때는 대시(대시)가 더 그럴듯하고 자연스럽다.---코트니스키(토크) 10:12, 2008년 11월 7일(UTC)[응답]

"대시를 하는 것은 정말로 큰 문제가 아니다." - 그렇다.당신이 잊고 있는 것처럼 보이는 것은 범주가 콘텐츠 공간이 아니라는 것이다.그것들은 단지 항법 목적으로 사용되도록 의도되었다.그래서 내비게이션 스타일로는 사용이 편리하다. - jc37 20:02, 2008년 11월 7일 (UTC)[응답]

그것은 "독자를 대면하는" 것이기 때문에, 스타일은 중요하다.편집자를 위한 유지보수 범주를 가지고, 나는 그렇게 신경 쓰지 않지만, 독자들이 사용하는 사람들을 위해, 우리는 노력을 해야 한다(그리고 그것은 정말로 작은 노력일 뿐이다- 실제로 많은 편집자들에게는 우리가 다른 것들과 다른 범주에 대한 다른 규칙을 가지고 있다는 것을 기억하거나 알아내고, 대시를 하이픈으로 바꾸는 것이 더 어려울 것이다.카피 앤 페이스트(copy-and-paste)를 한다.--코트니스키(talk) 09:59, 2008년 11월 8일 (UTC)[응답]

• 지지하다.유용성, 탐색 및 편집 용이성을 위해 거의 모든 컨텍스트에서 대시보다 하이픈을 선호한다.나는 몇몇 사람들이 중요하다고 느끼는 인쇄상의 구별이 있다는 것을 알지만, 솔직히 나는 그것이 편집을 방해하는 그 구분에서 거의 가치가 없다고 본다.대부분의 맥락에서, 나는 진실한 리디렉션 없이 범주의 문제점이 있는 것처럼 보이기는 하지만, 더 높은 수준의 구별성을 제공하는 전자파를 사용하는 것이 더 편하다.드래곤즈 비행 (토크) 2008년 11월 5일 (UTC) 19시 59분[응답]
• 지원; 하이픈의 사용은 편집자와 독자의 사용 편의성을 향상시키면서 동시에 명확하고 모호하지 않으며 미적으로 매력적이다.엔대시 사용으로 인한 추가적인 문제를 고려할 때 하이픈 대신 사용할 수 있는 실질적인 이유가 있을 것으로 예상되지만 아직 제시된 것은 없다.크리스토퍼 파럼 (토크) 2008년 11월 9일 (UTC) 00:40[응답]

사람들은 실제로 투표하기 전에 이전의 토론을 읽는가?그 이유는 좋은 영어 스타일과 기사 이름과 기사 텍스트와의 일관성 때문이다.그리고 "추가적인 문제"는 주로 착시(적어도 약간의 불편은 있을 수 있지만, 많은 편집자들이 대시를 기대하는 하이픈의 사용에도 똑같이 적용된다.)-코트니스키 (토크) 08:27, 2008년 11월 9일 (UTC)[응답]

스타일적인 관점에서 나는 하이픈이 괜찮다.그것은 똑같이 명확하고, 똑같이 매력적이며, 완전히 모호하지 않다.그것의 사용에 반대할 실질적인 이유는 없다.기사 제목을 옮겨서 일관성을 보장하고 싶다.모든 사람들이 이런 상황에서 하이픈을 자연스럽게 사용하는 것에 매우 익숙하기 때문에, 어떤 편집자도 내 관점에서는 대시를 "기대"하지 않을 것이다. 그래서 나는 그것을 논제로 본다.크리스토퍼 파럼(토크) 2008년 11월 9일(UTC) 23:07[응답]

'아니오' 편집자들이 '스타일 매뉴얼'에 나와 있는 내용을 알고 있거나 주의를 기울이지 않는다고 생각하는가?그렇지 않을지도 모르지만, 내 생각에 대부분의 진지한 편집자들은 - 적어도 우리가 권장하고 싶은 유형의 편집자들은 - 그 편집자가 거기서 무슨 말을 하는지 알고 그것을 따르려고 노력하며, 그것을 따르기를 기대한다고 생각한다.--코트니스키 (토크) 17:30, 2008년 11월 10일 (UTC)[응답]

나는 의도적으로 현재의 MOS 지침을 고려하지 않고 있다; 현재의 결정은 과거의 잘못된 결정에 얽매여서는 안 된다.오히려 과거의 결정은 대개 오늘날의 새롭고 개선된 판단을 반영하도록 수정되어야 한다.만약 MOS가 없다면, 편집자들은 하이픈을 보는 것이 놀랍지 않을 것이다. 왜냐하면 그것은 영어 텍스트를 제시하는 평범하고 명확하며 매력적인 방법이기 때문이다.크리스토퍼 파럼 (토크) 2008년 11월 10일 (UTC) 23:19[응답]

• 지지하다.범주 리디렉션은 작동하지 않고, 그것들에 대한 환상을 구현하는 것은 하이픈의 예상된 외관 문제보다 훨씬 더 큰 문제를 만들어낸다.나이 든 wiser 더 현명한 2008년 11월 9일 (UTC)[응답]

  그렇다면 왜 범주가 작업을 리디렉션하는 것이 "일루션"이 되는가?아마 이 토론의 나머지 부분을 읽었을 것으로 추측하는데, 그것은 그들이 거의 일을 한다는 것을 입증한 것 같다.--코트니스키 (토크) 17:30, 2008년 11월 10일 (UTC)[응답하라]

  그것이 당신의 해석이라는 것은 고맙지만, 지금까지 코딩한 코딩자들(및 다른 사람들)의 답변/코멘트에서는 그렇게 보이지 않는다.그리고 "그들이 일하는 것"과 꼭 같은 것은 아니다. - jc37 17:33, 2008년 11월 10일 (UTC)[응답하라]

  그럼 어떤 면에서 당신은 그들이 작동하지 않는다고 생각하는가?그리고 우리가 대쉬 대신 하이픈을 사용하면 그들이 필요 없을 정도로 자신만만한 이유가 뭐야?아마도 이 문제를 두 가지 질문으로 나눠야 할 것 같은데 1) 대쉬나 하이픈? 2) 리디렉션이나 레드링크?(많은 이들이 추측하는 것 같음에도 불구하고) 이 두 질문은 독립적이며, 각각의 경우에서 양측의 주장이 무엇인지를 규명하는 데 상당히 근접해 있다고 생각한다.--코트니스키 (토크) 17:41, 2008년 11월 10일 (UTC)[응답]

  코틴스키, 아니, 나는 이 토론이 그 범주가 어떤 유용한 방법으로 "업무"를 리디렉션하는 것을 확립한 것을 본 적이 없다.나이 든 wiser 더 현명한 18:32, 2008년 11월 10일 (UTC)[응답]

  글쎄, 지금까지 그들이 주장하지 않았던 모든 주장들은 거절당했다.그들이 일을 하지 못한다고 생각하는 다른 방법을 알고 있다면, 그들에 대해 들어봅시다. --Kotniski (토크) 13:15, 2008년 11월 12일 (UTC)[응답

  "재버피드"는 훌륭한 말이다.하지만, 여러분의 의견을 정확하게 표현하는 또 다른 방법은 "나는 다른 사람들의 선의에 대한 우려를 무시하고 있고, 단지 내가 원하는 것을 원한다."일 것이다.만약 내가 너의 코멘트를 잘못 쓰고 있다고 느낀다면, 얼마든지 명확히 해주길 바란다. - jc37 01:00, 2008년 11월 13일 (UTC)[응답]

  당연하게도, 나는 네가 내 코멘트를 잘못 쓰고 있는 것 같아.이렇게 표현하고 싶다.나는 다른 사람들의 선의의 우려들을 그들이 표현되는 곳마다 해결하기 위해 최선을 다하고 있지만, 다른 사람들은 단지 우리가 시작했던 것과 같은 일반적인 "그들은 작동하지 않는다"라는 만트라를 반복하기 위해 나와 대화를 하는 대신에 보인다.나는 그것이 그들이 분석에 들어가는 것을 귀찮게 할 수 없기 때문이거나 처음부터 좋은 구두점에 어떠한 가치도 부가하지 않기 때문에 재연결되는 것을 원하지 않기 때문이라고 추측한다.혹은 (어떤 경우에는) 단순히 내 말에 납득하고 더 이상 대응할 이유가 없다고 보는 경우도 있다.--코트니스키 (토크) 13:35, 2008년 11월 17일 (UTC)[응답하라]

  Jc37 아주 좋은 지적이야.범주의 리디렉션은 분별 있는 사용자가 예상하는 방식으로 작동하지 않기 때문에 깨지고, 슬러지 잘못된 행동을 교정하기 위해 봇을 필요로 한다.그것은 나에게 권장되는 표준으로 만드는 것은 용납될 수 없다.나이 든 wiser 2008년 11월 14일 12시 43분 (UTC)[응답]

• 지지하다.카테고리 리디렉션은 깨지기 때문에, 장려하거나 요구하는 것은 고사하고, 대시(dash)로 카테고리를 만드는 것은 좋지 않다고 생각한다. - Mgm 10:53, 2008년 11월 17일 (UTC)[응답]

기타의견

• 어디에나 "하이픈"을 쓰세요.영어는 수평선 형태의 문장 부호 하나만 있으면 된다.왜 낭비하는 두뇌 순환이 어느 선 길이가 맞는지 기억하려고 애쓰거나, 거의 똑같이 보이는 문자 사이를 바꿔서 "오류"를 고치려고 애쓰는가?우리 모두 키보드에 이미 있는 단추를 사용하고, 모든 것에 "-"를 사용합시다. -- Beland (토크) 17:51, 2008년 11월 6일 (UTC)[응답]

• 나는 이것에 얼마나 동의하는지 표현할 수 없다.셀라노르 00:20, 2008년 11월 10일 (UTC)[응답]
• 응, 나도 잘 해. --Kbdank71 14:25, 2008년 11월 10일 (UTC)[응답]

• 그러나 여기서 논의되고 있는 문제는 그것이 아니다.WP는 존경받는 영국식 가이드의 꽤 만장일치 권고에 기초하여 일반적으로 하이픈과 대시를 사용하는 것에 대해 매우 확립된 의견을 가지고 있다.개인적으로 나는 우리가 적용하는 몇 가지 규칙(예를 들어 '해체'를 위해 대시를 주장하지 않음)을 변경하고 싶지만, 세부사항보다 중요한 것은 일단 이러한 규칙을 갖게 되면 일관되게 적용해야 한다는 것이다. --코트니스키 (토크) 17:35, 2008년 11월 10일 (UTC)[응답]

• 이것이 초기 제안이 아니었다는 점에서 당신이 옳지만, 누구나 분명히 그들 자신의 제안을 토론에 내놓을 수 있다.밀짚 여론조사는 '목표'가 아니므로 토론을 마무리하는 데 있어서 어떤 의견이나 어떤 의견이든 저울질해야 한다. - jc37 17:42, 2008년 11월 10일 (UTC)[응답]
• 일단 이러한 룰을 가지고 있으면, 일관성 있게 적용해야 한다. 또는 합의가 바뀔 수 있기 때문에, 우리가 적합하다고 보는 대로 룰을 논의하고 변경할 수 있다. --Kbdank71 17:52, 2008년 11월 10일 (UTC)[응답]

• 나는 여기 있는 벨랜드의 의견에 대부분 동의해.즉, 나는 ASC를 사용해야 한다고 생각한다.II 하이픈은 범주 및 기사 제목 모두에 있으므로 전자 메일 및 순수 텍스트 파일과 같은 다른 매체에 입력 및 복사하여 붙여넣기가 쉽다.따라서 위키백과 내용을 훨씬 쉽게 찾아 재사용할 수 있다.그러나 나는 기사 텍스트에 엔 대시를 사용할 수 있다고 생각한다.예를 들어, 이메일 프로그램이 그것을 처리할 수 없을 때, 엔 대시가 기사 텍스트에서 정크 캐릭터가 된다면, 그것은 그렇게 많이 아프지 않다.하지만 기사 제목에 정크 캐릭터가 더 많이 나오면. --David Göthberg (토크) 03:47, 2008년 11월 25일 (UTC)[응답]

지금까지의 여론조사에 대한 논평

내가 보기에 대부분의 투표는 무효인 것 같다. 왜냐하면 그들은 리디렉션은 작동하지 않는다고 가정하기 때문이다. 그들이 실제로 그렇게 했을 때.하지만 우리가 봇이 그것을 할 수 있다고 믿지 않는다면, 개발자들에게 그것을 시스템에 구축해 달라고 요청하자(그렇게 어려운 일이 될 수는 없다.(그런 아이디어가 이미 제안/거부되었다는 것을 누군가가 알고 있지 않는 한) 개발자들로부터 얼마나 걸릴지 회신이 올 때까지 투표를 중지할 것을 제안한다.--코트니스키 (토크) 08:14, 2008년 11월 5일 (UTC)[응답]

이 문제는 이전에 제기되었던 문제인 것 같다 - Bugzilla 3311을 참조하라. (그리고 그것이 효과가 있다고 믿는다면, 그것에 투표하라.)그 문제는 해결 가능한 것 같지만, 그것을 하기 위해 서두르는 개발자는 없다.하지만 여전히, 우리는 완벽하게 효율적인 봇을 가지고 있고, 아노미(Amonie)가 지적하듯이, 러스가 그것을 실행하는 것을 멈추면 다른 누군가가 그것을 대신할 수 있다. (그리고 리디렉션은 봇이 없어도 계속 일한다 - 봇은 우연히 다른 범주에 넣어지는 어떤 기사들을 옮기는 데만 필요하다.)따라서 이러한 주장된 "문제"는 단 한 가지로 요약되는 것처럼 보인다 - 언제 대시가 필요한지 모르는 편집자에 의해 이러한 범주 중 하나에 기사가 배치되는 경우 또는 너무 급하게 대시를 붙이거나/자바-아이즈를 끼우는 경우, 다음 번 봇이 실행될 때까지(일반적으로 최대 24시간)에는 그것이 목표 페이지에 나타나지 않는다.하지만 이것이 중대한 논쟁으로 여겨지더라도, 그 반대 방향으로도 작용한다는 것을 기억하자 - 만약 하이픈 전용 정책에 대해 알지 못하는 편집자에 의해 기사가 추가되거나 다른 곳에서 그 문구를 붙여 범주 선언을 한다면, 우리는 같은 상황에 다시 처하게 된다.-코트니스키 (토크) 13:42, 2008년 11월 5일 (U)TC)[응답하라]

이런 말을 반복해서 하셨군요.하지만 위의 사람들은 여전히 네 말에 동의하지 않아.

허? 그들 스스로 말하게 내버려 둬. 그들 중 아무도 아직 나에게 응답하지 않았어.k

이 문제로 이어진 토론에서 사용자:데이비드 고트버그가 논평했다.그는 지금 가지고 있다. (다른 여러 명의 코더가 있는 것처럼)

또 하나?봇과의 '진짜 문제'를 설명하며 그들이 논평하기를 기다리고 있었다.아직까진 없는 것 같다(작동이 중단될 수도 있지만, 그러면 다른 사람이 인수할 수도 있다).k

그리고 아니, 그것은 "그 반대 방향"으로 작용하지 않는다.편집자가 하이픈 대신 대시를 사용하면 카테고리 이름이 변경된다.범주 리디렉션을 사용하여 범주의 산물을 복제할 필요 없음. - jc37 14:09, 2008년 11월 5일(UTC)[응답]

세 번째야?누가 그 범주의 이름을 바꿀 것인가? (좋아, 어쩌면 빨간 링크가 편집자에게 경고 신호일지도 모르지만, 누가 그가 하이픈으로 연결된 범주를 검색하는 대신에 레드링크 범주를 만들거나 고양이 선언을 포기하고 삭제하는 것으로 반응하지 않을 것이라고 말할 것인가?)그리고 우리는 여기서 어떤 것에 대해서도 "산"이라고 말하는 것이 아니다. 관련된 리디렉션의 수는 WP가 이미 가지고 있는 숫자에 비해 매우 적을 것이고, 리디렉션은 어쨌든 거의 비용이 들지 않을 것이다.--- Kotniski (talk) 14:48, 2008년 11월 5일 (UTC)[응답]

코티스키:아니, 봇이 소프트 리디렉션 범주에서 올바른 범주로 페이지를 이동하는 데 24시간밖에 걸리지 않는다.우선 봇은 카테고리 리디렉션이 잘못 변경될 경우 대량 편집 페이지를 차단하기 위한 '스탠드오프 기간'이 있다.즉, 봇이 모든 페이지를 편집하기 전에 인간에게 리디렉션을 수정할 수 있는 기회를 주는 것이다.내가 아는 바로는 "대기 기간"은 일주일이다.그런 다음 위키백과 서버는 낮은 우선순위 작업으로 카테고리 목록 업데이트를 실행하는데, 이것은 서버 로드가 높은 기간 동안 페이지가 올바른 카테고리에 보이기까지 최대 일주일이 걸릴 수 있다는 것을 의미한다.그리고 이것은 대부분의 사람들이 생각하는 것보다 더 자주 일어난다.이는 봇이 가동되어 실행 중이라면, 한 페이지가 올바른 범주에 나타나기 전까지 총 2주까지가 된다.템플릿 때문에 분류가 잘못되었다면 대부분의 페이지가 올바른 범주에 표시되기까지 3주 이상이 걸리는 경우가 많다.그리고 템플릿의 경우, 방문자가 없는 페이지의 경우, "영원히" 걸릴 수 있다.그러나 지금으로서는 그것이 왜 그런지 길고 복잡한 설명은 생략하겠다.

유효하지 않은 표에 대해:당신이 동의하지 않는 표가 무효라고 주장하는 것은 매우 비민주적이다.우리는 이미 여기서 몇 가지 기술적인 문제에 대해 설명했으며, 우리는 이미 당신을 템플릿 토크에서 발생한 문제에 대한 보다 심도 있는 토론에 연결했다.카테고리 리디렉션.당신이 당면한 기술적 문제를 이해하지 못하는 것은 당신의 문제지, 우리의 문제가 아니다.하지만 이건 까다로운 일이라서 이해하지 못한 걸 탓하진 않아.대신에 나는 네가 이해하지 못하는 것을 받아들이지 않은 것을 비난한다.

범주화는 기술적 도구라는 점을 기억하십시오.그것은 예쁜 기사 텍스트가 아니다.하지만 다음 목표는 템플릿과 자바스크립트 프로그래밍에서 ASCII 대신 유니코드 기호를 사용하도록 요구하는 것이겠죠?즉!=, <=, >=, >=, -, * 대신 *, ×, ×. 긴 등호를 나타내는 유니코드 기호가 있는지 궁금하다.동일한 비교를 위해 사용하는 기호, ASCII에서 우리가 "a == b"로 쓰는 기호.아마도 "em equal?"이라고 불릴까? :)

그런데, 대부분의 기술적인 문제를 피하기 위해서, 우리는 아마도 개발자들에게 그것을 만들어달라고 요청해서 범주 시스템이 하이픈, 엔 대시, 엠 대시 등을 동일한 기호로 해석하도록 해야 할까?그래서 우리가 어떤 것을 사용하는지는 중요하지 않다.그리고 이는 범주 리디렉션 시스템의 다른 문제를 해결했더라도 도움이 될 것이다.

--David Göthberg (대화) 2008년 11월 5일 (UTC) 19:57[응답]

음, {{#expr}}은(는) 최근에 인식하도록 변경되었다. - 이외에도 -. Anomie⚔ 22:17, 2008년 11월 5일(UTC)[응답]

U+2263은 "엄격한 등가물"의 상징이다. 내 생각에 당신은 그것을 긴 등가물로 사용할 수 있을 것 같다.:) 셀라르노르 22:12, 2008년 11월 5일 (UTC)[응답]

OK David, 마침내 그 문제들이 무엇이라고 생각하는지 설명해줘서 고마워. (우리들 중 가장 똑똑한 사람도 우리가 듣지 못한 것들을 이해할 수 없어.) (그리고 프로그래밍에서 유니코드로 무슨 일을 하고 있는지 모르겠어 - 분명히 아무도 그걸 제안하지 않고 있어.)그러나 나는 아직도 당신이 인용하는 문제인 교착상태의 문제가 이 경우에 적용될 수 있다고 보지 않는다.어떤 범주 이름을 바꿀 때 한 번 발생하는 문제다.예를 들어 제안서에 따라 대쉬에서 하이픈으로 범주가 변경될 경우 발생할 수 있다.(내가 보기에) 리디렉션된 범주의 후기 유지에 영향을 미치는 것은 문제가 되지 않기 때문에, 나는 이 토론과 관련이 있다고 보지 않는다.내가 페이지의 카테고리를 변경할 때, 나는 항상 새로운 카테고리에서 그것을 바로 볼 수 있는 것 같다. 그래서 나는 실제로 업데이트가 많이 지연되는 것을 보지 못한다(그리고 만약 그들의 기사를 분류하기 위해 그렇게 서두르는 사람이 있다면, 그들은 대시 기호를 입력하는 데 걸리는 5초를 더 할애할 수 있다.내가 이해한 템플릿의 문제(나는 나타날 수 있는 것처럼 완전히 무지하지는 않지만), 그러나 다시 말하지만, 나는 대시 범주에 하이픈을 부과하는 기존 템플릿의 수가 거의 0에 가깝다고 생각하기 때문에(유지 관리 범주의 경우 하이픈은 독자들에게 숨겨져 있으므로), 그리고 새로운 템플릿은 cr.eated는 대시가 이미 설치된 상태에서 만들 수 있다. --Kotniski (토크) 11:48, 2008년 11월 6일 (UTC)[응답]

WP:DASH – 지금까지의 요약

카테고리 리디렉션은 다음과 같이 동작한다.

1. 리디렉션된 카테고리 페이지로 이동하면 다른 리디렉션과 마찬가지로 대상 페이지로 이동한다.
2. 리디렉션이 다음으로 포맷된 경우#REDIRECT [[Category:foo]]리디렉션된 카테고리는 카테고리:foo의 하위 카테고리로 나타난다.
3. 리디렉션이 다음으로 포맷된 경우#REDIRECT [[:Category:foo]]리디렉션된 카테고리는 카테고리:foo의 하위 카테고리로 표시되지 않는다.
4. 리디렉션된 범주에 배치된 페이지는 자동으로 대상 범주에 배치되지 않는다.
5. 위의 #4를 수정하려면, 사용자:RussBot은 정기적으로 이러한 페이지를 대상 범주로 이동시킨다.만약 RussBot이 일을 그만둔다면, 다른 누군가도 같은 일을 하는 새로운 봇을 운영하는 것은 아주 쉬운 일일 것이다.

WP에 예외를 두자는 제안에 찬성하는 사람들:DASH는 다음과 같은 이유를 든다.

1. 위의 항목 #5는 보정이 즉시 이루어지지 않기 때문에 #4가 야기하는 문제에 대처하기에 충분하지 않다.
2. RussBot은 마지막 편집 후 7일이 지나야 새로 리디렉션된 범주를 비운다.이로 인해 병리학적 사례에서 페이지 업데이트가 몇 주 지연될 수 있다.
3. 표준 키보드에 하이픈을 입력하는 것이 더 쉽다.
4. WP:DASH는 범주에 관한 것만이 아니라 완전히 뒤집어져야 한다.

지지자들은 또한 다음과 같은 터무니없는 주장을 한다.

1. "범주 리디렉션은 깨졌어."너무 막연하다.이것은 뒷받침하는 이유 #1을 언급할 수도 있지만, 또한 사람들이 #1 행동이 해당되지 않는다고 믿거나 #3 행동을 알지 못한다고 믿는 것일 수도 있다.
2. "그 결과 리디렉션이 불필요하게 중복된다."이는 WP가 다음과 같은 모든 비범주 페이지에서 발생한다.DASH도 적용된다.
3. "재연결된 범주는 레드링크가 아니다."이는 모든 비범주 리디렉션에서도 발생한다.
4. "사람들은 검색 상자나 URL에 하이픈으로 된 버전을 입력할 수 있다.그것이 리디렉션의 목적이다.
5. 카테고리 리디렉션은 없다"고 말했다.이것은 거짓이다.
6. "모든 카테고리 리디렉션은 소프트 리디렉션이어야 한다."이것은 기술적 견지에서 보면 거짓이다.
7. "난 러스봇을 믿지 않아."그것을 믿지 않을 이유가 없다.봇 가동 중단이 그 정도 문제라면 중복 봇을 동시에 실행할 수 있다.
8. "카테고리들은 만족스럽지 않다.몇몇은 그렇지 않지만, 많은 사람들은 그렇지 않다.

이 제안에 반대하는 사람들은 다음과 같은 이유를 든다.

1. 항목 #5는 #4에 대응하기에 충분하다.
2. (유지관리 범주와 반대로) 백과사전의 일부인 범주는 백과사전의 나머지 부분과 동일한 스타일의 지침을 따라야 한다.
3. 제안된 예외조항은 서신이 있을 때 범주명이 해당 물품명과 일치하지 않게 된다.
4. 대시는 페이지 하단의 단추를 사용하거나 카테고리 이름을 복사하여 붙여넣으면 쉽게 입력할 수 있다.
5. 러스봇의 7일간의 재사용은 무관하다.새 리디렉션을 만드는 사용자는 리디렉션하기 전에 이전 카테고리를 비워야 한다.

반대론자들은 또한 다음과 같은 터무니없는 주장을 한다.

1. "범주 리디렉션은 깨지지 않는다."너무 막연하다.이것은 반대되는 이유 #1을 언급할 수도 있지만, 또한 행동 #4를 완전히 무시하는 것일 수도 있다.

솔직히, 나는 이전의 많은 토론이 혼란스럽다고 생각한다.위에서 논의되고 있는 세 가지 옵션이 있는데, "모든 것은 대시를 사용한다", "범주를 제외한 모든 것은 대시를 사용한다", "대시를 사용하는 것은 없다" 입니다.투표 "반대"는 첫 번째 선택지를 선택하는 것이지만, "지지"는 두 번째 또는 세 번째 선택일 수 있고, 어떤 것을 결정하는 것은 종종 불가능하다.Anomie⚔ 21:17, 2008년 11월 12일 (UTC)[응답]

카테고리 리디렉션을 잘못 하셨습니다.범주가 다음으로 리디렉션되지 않음#REDIRECT [[:Category:foo]]. Category에서 사용되는 소프트 리디렉션을 사용한다.만주족.자동으로 대상 범주로 넘어가는 것은 아니다. --Kbdank71 21:39, 2008년 11월 12일(UTC)[응답]

정말 먹어본 적 있어?그것은 잘 작동한다.이 때 일반적으로 사용되는 형상의 여부는 무관하다.Anomie⚔ 23:58, 2008년 11월 12일 (UTC)[응답]

기술적 견지에서 보면 그렇다.그러나 사용적합성 측면에서는 전혀 효과가 없다.Say Category:만추 사람들은 강경하게 방향을 바꾸었다.거기 가면 자동으로 카테고리:만쿠스.잘 되겠지?이제 문서를 편집하여 카테고리에 추가하십시오.만주족.구하라카테고리를 클릭하는 경우:이 기사에서 만추 사람들은 즉시 카테고리로 이동한다.만쿠스, 하지만 그 기사는 거기 없어. 왜냐하면 그 기사는 카테고리에 있기 때문이야.만주족.너의 무심코 읽는 사람은 무슨 일이 일어났는지 이해하지 못할 것이다.그래서, 부드러운 리디렉션.하드 카테고리 리디렉션을 사용하지 않는 이유는 매우 관련이 있다. --Kbdank71 00:10, 2008년 11월 13일(UTC)[응답]

그래서 러스봇.아노미슈 01:28, 2008년 11월 13일 (UTC)[응답]

그리고 위에서 요약한 바와 같이 RussBot은 마지막 편집 후 7일이 지나서야 새로 리디렉션된 범주를 비운다.그리고 요약본에 대해 말하자면, 덧붙일 것이 있었거나, 아니면 아직도 혼란스러운가? --Kbdank71 01:39, 2008년 11월 13일 (UTC)[응답]

그리고 위에서 요약했듯이 러스봇의 7일간의 재사용은 무관하다. 새 리디렉션을 만드는 사용자는 리디렉션하기 전에 이전 카테고리를 비워야 한다.나는 그것이 토론이 계속 동그라미를 치지 않고 앞으로 나아가는 데 도움이 되기를 바라고 있었다.아노미에 02:40, 2008년 11월 13일 (UTC)[응답]

사용자 공간에서 미성년자 보호

감독 요청은 종종 {{User infobox}}을(를) 사용하는 미성년자 또는 어떤 다른 사람의 infobox를 사용하여 정확한 생년월일 및 기타 식별 정보를 기입하는 것과 관련이 있다.

이것은 가장 최근의 사례다.

위키백과:관리자_공지판/사고 #위치_상세_of_Minor

{{Birthday 및 enge}}}~{break}}와 같은 템플릿이 사용자 공간에서 사용되며 매개변수가 미성년자임을 나타내는 것이 합리적인가?우리는 그들 자신으로부터 그들을 보호해야 할까?이것을 하지 않는 좋은 이유가 있는가?존 반덴버그 2008년 11월 23일(UTC) 21:16[응답]

위키백과:요청_arbitration/Protecting_children's_privacy#자체 식별된_children은 그렇다고 대답하는 것 같다. 우리는 미성년자를 위해 그 템플릿을 비활성화해야 한다.MBisanz^talk 21:21, 2008년 11월 23일 (UTC)[응답]

어떻게?위키백과:중재/아동 사생활 보호 요청#자체 정체된 아동들은 그저 아이라고 주장하는 사람이 거짓말을 하고 있을 수도 있다고 지적할 뿐이다.또한 제안된 구제책들 중 어떤 것도 템플릿을 깨는 것을 제안하지는 않는다.아노미야 23:11, 2008년 11월 23일 (UTC)[응답]

IMO, 그건 완전히 쓸모없을거야.우선, 어린이의 정보는 현재 버전의 페이지에서 호출되는 부서진 템플리트 호출에 없을 경우 페이지 기록에 남아 있을 것이다.아이가 파서 기능을 알아낼 만큼 똑똑하다면, "블록 마이너" 섹션 없이 단지 나이 계산 코드를 템플릿에서 복사하고, 그렇지 않다면 자동으로 나이를 계산하여 쉬운 Wikitext에 넣는 것을 포기한다.그것은 또한 아이들이 그들의 전체 이름, 사진, 학교 위치와 일정, 그리고 모든 종류의 정보를 비밀로 유지하는 것에 대해 아무 것도 하지 않는다.

더 나은 기술적 해결책은 위키피디아가 RFC 3514 "악마의 비트"가 설정된 모든 페이지뷰를 거부하는 것이 될 것이다. 그래서 이용하려는 어린이를 찾으려는 사용자 페이지를 보는 사람들은 자동으로 차단될 것이다.;;) 하지만, 진지하게 나는 언급된 Arbcom 사례에서 제안된 두 번째와 세 번째 해결책이 가장 좋은 방법이라고 생각한다: 어린이를 가장한 트롤을 차단하고, 실제 아이들의 개인정보를 감독하는 것이다.아노미야 23:11, 2008년 11월 23일 (UTC)[응답]

여기서의 제안에 전적으로 동의하지만, 섹션 제목은 공평하지 않다 - 자신에게 위험을 가하는 것은 미성년자가 아니다. 그리고 이상적인 세계에서는 위험이 존재하지 않을 것이다:P 더 간단한 "미성년 프라이버시 보호"는 미래에 충분할 것이다. 나는 2008년 11월 23일 (UTC) 22:35, LinaMishima[응답]를 느낀다.

위키백과 참조:아이들의 프라이버시를 보호.또한 사용자들을 10대, 학생 등으로 식별할 수 있는 사용자 박스가 무수히 많다는 점에 유의하십시오. --— Gadget850 (Ed) - 2008년 11월 18일, 24일 (UTC)[응답]

범주별 합의:프로듀서별 앨범

Category에 대한 찬반 의견이 분분한 것 같다.리처드 랜디스가 제작한 앨범은 리차드 랜디스가 기사가 없고, 기사가 없을 가능성이 매우 낮기 때문에 존재해야 한다.a.) 몇 장의 앨범의 단독 프로듀서, b.) WP:N을 만나는 프로듀서가 아니라면 프로듀서들이 개별적인 하위 카테고리를 갖지 말아야 한다는 일종의 제안을 하고 싶다.나는 자신이 프로듀싱한 아티스트들과 직접 연결되지 않는 랜디스의 출처를 전혀 찾지 못했고, 왜 이 카테고리가 유지되기를 원하는지 상상할 수도 없다(어쨌든 그는 10장 정도밖에 앨범을 제작하지 못했는데, 뭐가 대수야).그래도 먼저 다른 사람의 의견을 수렴하고 싶다.10파운드 해머와 그의 수달 • 2008년 11월 24일 (UTC) 19:58[응답]

사용자:비밀/추가 편집기 추가

나는 편집자들을 끌어들이기 위한 이 새로운 제안에 대한 기고문과 논평을 환영할 것이다.고마워 시크릿 21:36, 2008년 11월 24일 (UTC)[응답]

P: 및 T: 유사 공간

[4]와 [5]에 따라 T: 및 P:의 유사 공간은 모두 템플릿 및 포털로 리디렉션된다.나는 개발자들이 WP:와 WT:에서와 같이 이러한 유사 공간을 네임스페이스 시스템에 코딩하여 기사 공간에서 적절한 템플릿 및 포털 공간으로 이동할 것을 제안한다.어떤 기능도 손실되지 않으며, 검색이나 사용도 변경되지 않는다.MBisanz 03:09, 2008년 11월 16일 (UTC)[응답]

해를 끼치지 않았지만, 이것이 가져다 주는 이점은 무엇인가?— Werdna • talk 05:35, 2008년 11월 16일 (UTC)[응답]

입력 및 공간 저장(검색 상자 및 대화 페이지의 링크, 요약 편집 등)나는 이것에 대해 더 찬성한다(C: 카테고리도 찬성한다, 아직 그렇게 하지 않았다면).--코트니스키 (토크) 08:08, 2008년 11월 16일 (UTC)[응답]

너는 분명히 그 제안을 이해하지 못한다.바로가기는 이미 존재하며, 제안은 단지 포털 및 템플릿 네임스페이스의 별칭으로 ''P와 ''T를 공식화하는 것이다.— Werdna • talk 09:29, 2008년 11월 16일 (UTC)[응답]

그럼 내가 어떻게 이해하는지 말해줄게, 내가 틀렸으면 네가 말해도 돼.현재 그 지름길은 누군가가 만들어야 존재한다.유사 공간이 코딩되어 있으면 바로 가기가 자동으로 작동하게 된다.예를 들어, 현재 T:를 입력할 수 없는 경우:템플릿의 바로 가기 형식으로 보관:기록 보관소, 아무도 그 리디렉션을 만들 순 없으니까그러나 나는 WP를 입력할 수 있다.위키백과의 바로 가기 정책:정책, 리디렉션이라서가 아니라 개발자들이 WP 유사우주공간을 시스템에 코딩했기 때문이다. --Kotniski (토크) 09:37, 2008년 11월 16일 (UTC)[응답]

코트니스키와 같은 것으로 알고 있는데, 이것은 우리가 만든 6개의 페이지와 연결되지 않고 T:가 보편적으로 작동하기 때문에 어떤 템플릿에도 연결하기가 더 쉬울 것이다.또한, 현재 기사 공간에 있는 템플릿 링크의 중복을 제거할 것이다(T:DYK는 기사로 간주된다).MBisanz^talk 09:41, 2008년 11월 16일 (UTC)[응답]

또한 "T:"나 "P:"로 시작하는 기사를 만드는 것도 불가능할 것이다. --카닐도 (토크) 09:49, 2008년 11월 16일 (UTC)[응답]

지금까지 250만 건의 기사를 보유하고 있으며, 아무도 T:, WP, WT 또는 P: 접두사를 사용할 필요성을 느끼지 않으며, Help:와 같은 기존 구조와 상충되는 기사명을 가지고 있음을 알 수 있다.인생의 하루, 나는 이것을 중요한 문제로 보지 않는다.MBisanz^talk 09:59, 2008년 11월 16일 (UTC)[응답]

도움말:생명의 하루는 기사가 아니라 도움말로 리디렉션!: A Day in the Life.특수:WhatLinksHere/도움말:A Day in the Life는 현재 5개의 메인 스페이스 기사를 보여준다.이 연결은 메인 스페이스로 리디렉션되는 도움말 공간에 연결된다.그 5개의 링크는 아마도 많은 데이터 사용자들에게 영향을 미칠 것이다.그러한 리디렉션의 존재는 부적절한 연결의 작성을 장려한다.짧은 메시지와 위키링크로 대체해야 한다고 생각한다.5개의 링크는 당연히 고쳐야 하지만 다른 사람들이 보고 싶다면 일단 남겨두고 갈 거야.프라임헌터 (대화) 2008년 11월 17일 (UTC) 00:43[응답]

"이러한 연결고리는 아마 끊어질 거야..."라는 말이 무슨 뜻인지, 그리고 그것이 사람들로 하여금 어떤 부적절한 연결고리를 만들도록 부추길 수 있는지 설명해 주시겠습니까?Given that this redirect is (potentially, slightly) useful, we shouldn't get rid of it unless we can be specific about the harm it is alleged to do. (Anyway, we're going off topic here - Help: isn't a pseudospace; in fact I think pseudospaces are even more problematic in this regard.)--Kotniski (talk) 06:57, 17 November 2008 (UTC)[reply]

대부분의 재사용자는 문서, 템플릿 및 이미지 네임스페이스만 복사한다.기사->도움말->기사 링크가 있으면 위키피디아를 복사할 때 받지 않는다. --카르닐도(토크) 08:05, 2008년 11월 17일 (UTC)[응답]

그래, 나는 우리가 링크를 바꾸어야 한다고 주장하는 게 아니야.그러나 리디렉션 자체는 해를 끼치지 않는다(글쎄, 그것은 빨간색으로 보이지 않기 때문에 "잘못된" 링크가 필요한 것보다 더 오래 남아 있게 할 수도 있다; 하지만 빨간색이 아닌 것은 우리에게 좋으며, 우리는 그 복사보다 진짜 WP를 우선시해야 한다).--코트니스키 (토크) 13:07, 2008년 11월 17일 (UTC)[응답]

주요 네임스페이스가 "기사" 네임스페이스로 간주되는 것에 대한 이것은 무엇인가?— Werdna • talk 10:45, 2008년 11월 16일 (UTC)[응답]

위키백과 참조:네임스페이스#기본 네임스페이스 또는 아티클 네임스페이스는...MBisanz 13:08, 2008년 11월 16일 (UTC)[응답]

위키백과 네임스페이스의 페이지는 어떤 사람이 위키백과에 대해 쓴 것이다.그 부분이 실제로 논의/해체되지 않았는지 의심스럽기 때문에, 특히 이와 같은 사소한 세부 사항에 대해서는 '올바른' 정책으로 취급되어서는 안 된다.

내가 놓친 게 있는 건가, 아니면 이게 관련이 있는 건가?--코트니스키(토크) 16:31, 2008년 11월 17일 (UTC)[응답하라]

나도 같은 생각을 하고 있었다.이것은 토론과는 무관하다. -- 임페라이터3733 (대화) 16:50, 2008년 11월 17일 (UTC)[응답]

• 지지 - 이 제안은 좋은 일만 할 것 같다.It Is Me Here (대화) 09:54, 2008년 11월 16일 (UTC)[응답]
• 지원 - 이것은 좋은 생각이며, 게다가 기사에 연결하기가 더 쉬워질 것이다(예: ). -- 임페라토리3733 (대화) 16:50, 2008년 11월 17일 (UTC)[응답]

  그렇지 않을 거야, 그래도 써야 할 거야. 그래도 타자 치기 훨씬 쉬워.해피멜론 17:28, 2008년 11월 17일 (UTC)[응답]

흠, 나는 아까 이와 비슷한 토론에서 누군가가 그렇게 말했을 거라고 생각했다.아, 어쨌든 쉽네. -- 임페라이터3733 (대화) 19:49, 2008년 11월 17일 (UTC)[응답]

• 지지하다.이 제안은 일리가 있고, 나는 그것에 뚜렷한 문제가 없다고 본다.러슬릭 (대화) 2008년 11월 17일 (UTC) 20:23[응답]
• P: 및 T:; 실제적인 이유로 C: 반대 - 카테고리 페이지를 리디렉션으로 사용(예: C:CSD->카테고리:신속한 삭제) 후보자들은 문제가 있다.또한 기존의 모든 C: 페이지가 범주로 리디렉션되는 것은 아니다. 이 중 24개 페이지 중 6개가 기사로 리디렉션되고 3개가 기사다.2008년 11월 18일 (UTC) odישוווו Od Mishehu 07:09 (UTC)[응답]
• 나는 P:와 T: 유사 공간만을 위해 이 (T18452)을 위해 버그를 범했다.좋은 아이디어라고 생각되는 경우 계속 의견을 제시하고 지원을 표시하십시오. 개발자에게 제시할 수 있는 컨센서스가 강할수록 개발자가 더 많은 변화를 가져올 수 있다.해피멜론 22:38, 2008년 11월 24일 (UTC)[응답]
• 반대, (a) 별로 필요하지는 않지만, 나는 여전히 크로스 스페이스 리디렉션은 유해하다는 것을 믿지 않는다[재이용자 주장은 대부분 저혈압인 것 같다] (b) 이러한 모든 영역을 비고문용으로 예약하는 것은 과잉인 것 같다. 반면, Od Mishehu는 이러한 타이핑 보조기구는 우리가 기존의 기사들을 차등의 이름으로 바꾸어야 한다는 것을 의미한다고 지적한다.쿠스마 (토크) 09:55, 2008년 11월 25일 (UTC)[응답]
• 약한 지원 - 내 주된 관심사는 사용자가 T: for Talk: (더 직관적으로 보일 수 있음)를 혼동할 수 있는지에 대한 것이지만, 나는 이것을 좋아한다.사용자(예상)가 템플릿보다 네임스페이스를 연결하여 대화할 가능성이 더 높기 때문에(템플릿을 변환할 가능성이 더 높기 때문에, 템플릿의 선행자는 이미 추정), 템플릿 공간에 대해 TEMP: (또는 이와 유사한 것으로) Talk 네임스페이스를 연결해야 하는가?- jc37 17:09, 2008년 11월 25일 (UTC)[응답]

  내가 알기로는 그건 실제 연습과는 맞지 않아.이러한 링크가 더 일반적이고 직관적이어야 한다는 가설에는 동의하지만, 리디렉션 목록을 보면, 사실 모든 링크가 템플리트: 네임스페이스에 해당하지는 않지만 대부분의 링크가 네임스페이스라는 것을 알 수 있다.하드 코딩된 네임스페이스 별칭은 현재 관행을 반영해야 한다.해피멜론 19:13, 2008년 11월 25일 (UTC)[응답]

  • 가지고 있거나 로 리디렉션하는 것은?그 두 접두사 중 하나로 시작한 기사는 하나도 찾을 수가 없었다. -- 임페라이터3733 (대화) 19:25, 2008년 11월 25일 (UTC)[응답]
    • 2단계로 그렇게 할 수 있지만, 나는 P와 T에 초점을 맞추고 싶었어. 왜냐하면 그런 것들이 최소한의 미조회 상황을 만들어내기 때문이야.MBisanz 22:01, 2008년 11월 25일 (UTC)[응답]

mbox 유형 이름

현재 나열된 현재 유형 이름은:

• 빠른/삭제/내용/스타일/통지/이동/보호

이것들은 오랜 시간 동안 논의한 후에 결정되었다.

아마도 모든 템플릿을 직관적으로 포함시키고, 각 템플릿의 변형을 줄이고, 가독성을 높이기 위해 표준을 만드는 것이 목적이었을 것이다.칭찬할 만한 목표.

나는 결코 이 좋은 일이 취소될 것을 제안하지 않는다.

내가 제안하는 것은 그 종류들 중 두 개의 이름이 바뀌어야 한다는 것이다.

• 주황색 수준의 내용을 주의로 이름 바꾸기
• 빨간색 수준의 삭제 이름을 경고로 변경

왜?

우선, 템플릿의 과거(기존) 시스템을 보다 효과적으로 통합하려면:템플릿:통지 / 템플릿:주의 / 템플릿:경고 (파란색 / 오렌지색/빨간색)

그리고 또한 "빨간색"이 단순히 "삭제"보다 더 많은 템플릿에 사용되고 있기 때문이다.그리고 "오렌지"는 단순한 "내용" 이상의 의미를 갖는다.

이것은 의도된 "유형"의 용도를 훨씬 더 명확하게 할 것이다.

실행은 어렵지 않을 것 같다.코드에서 이름을 편집하기만 하면 봇은 템플릿의 유형 이름을 업데이트할 수 있다.- jc37 15:18, 2008년 11월 20일 (UTC)[응답]

임페라이터3733(직접 아래)은 이행을 더욱 명확히 했다.- jc37 18:43, 2008년 11월 20일 (UTC)[응답]

토론

• 위에서 언급한 이유로 나는 분명히 이 제안을 지지한다. - jc37 15:18, 2008년 11월 20일 (UTC)[응답]

• 이것은 좋은 생각인 것 같지만, 전환 계획을 약간 수정해야 할 부분이 있다.코드에서 이름을 변경한 다음 템플릿에서 이름을 변경하면 템플릿이 이전 이름을 가리키는 기간이 줄어들어 존재하지 않게 된다.우리도 같은 문제가 생길 것 같아서 템플릿을 먼저 바꿀 수 없었어.따라서 (1) 이름을 바꿀 스타일의 복사본 만들기, (2) 복사본의 이름 바꾸기, (3) 템플릿 변경, (4) 다른 모든 것이 변경되면 이전 스타일 이름을 제거해야 한다.이렇게 하면 전환 과정에서 어떤 문제도 없어질 것이다. -- 임페라이터3733 (대화) 17:57, 2008년 11월 20일 (UTC)[응답]

  좋은 생각이야.정리해주셔서 감사합니다. - jc37 18:41, 2008년 11월 20일 (UTC)[응답]

• 시스템에 맞지 않는 템플리트를 간단히 수정하는 것이 더 간단하지 않을까?우선, 나는 잘 정의된 색 구성표를 갖는 단순함에 크게 감사한다.모든 적색-배열 템플릿이 삭제 템플릿이라는 것을 알고 있으면, 모든 X-색 템플릿은 Y 템플릿 등 문제가 될 만한 가치가 있다.빨간색이나 다른 색상을 사용하지만 해당 범주에 속하지 않는 템플릿 본문이 특히 많은가?만약 그렇다면, 그들은 어디에 있는가?확실히 이것들을 고치는 것이 현재의 시스템을 다시 설계하는 것보다 더 간단할 것이다.{{Nihiltrestalk log}}{{Nihiltrestalk log}} 2008년 11월 20일 (UTC)[응답]

  예, 몇 개 이상 있다.(위에서 언급한 세 가지 템플릿의 역사적 용법 포함)그러나 그렇지 않았더라도, 나는 코더의 관점에서 '유형'이란 것이 단순히 라벨일 수도 있다는 것을 이해하지만(따라서 '코드가 예쁘다'고 해도 누가 신경 쓰겠는가) 편집자의 관점에서, 그 이름을 붙이는 것이 더 도움이 될 것 같다.이것은 최종 사용자에 대한 사용자 친화성에 관한 것이다. (물론 다른 것들도 마찬가지 입니다.) - jc37 19:20, 2008년 11월 20일 (UTC)[응답]

  나는 네가 내 의견을 잘못 이해했다고 믿는다.내 제안이 최종 사용자를 대신한다.통지의 색상은 통지의 범주를 반영해야 한다는 생각이다.나는 외관상 코드의 지정에 신경 쓰지 않는다.나는 그 지정이 우리가 생각해낸 분류 계획을 반영하고 있고, 어떤 분류 체계도 모호하게 만들면 그것의 이익을 파괴할 위험이 있기 때문에 걱정한다.

  내가 알기로는, 우리가 고안한 시스템은 빨간색이 삭제를 나타내고, 주황색은 심각한 이슈를 나타내고, 노란색은 스타일 이슈를 나타내고, 파란색은 통지에 대한 것이다.이점은 최종 사용자가 심각도에 따라 색상이 더 따뜻해지는 이러한 경고를 볼 수 있고 본문을 읽지도 않고도 문제를 약간 이해할 수 있다는 것이다.나의 목표는 템플릿 자체가 궁극적으로 미적일 뿐만 아니라 유용한 합리적인 색채 구성을 따르는 것이다.

  코드의 설명을 더 모호하게 만드는 것은 내가 보기에 범주 간의 구분을 더 모호하게 만들기 때문에 이 목표와 배치된다.따라서 나의 추리에 따르면 해결책은 사물을 맞추기 위해 패턴 자체를 손상시키기보다는 이 패턴을 따르지 않는 템플릿을 고치는 것이 될 것이다.이게 더 말이 돼?{{Nihiltrestalk log}}} 23:43, 2008년 11월 20일 (UTC)[응답]

  내가 기억하는 바로는, 그 색깔들은 "색깔이 뜨거울수록, 고시에 더 "영향"을 주기 위한 것이었다.

  그러나 기억은 차치하고라도 (색깔에 관계없이) 대부분의 통지가 '내용'에 관한 것이라는 점을 고려하면, 그것은 오히려 궁극적인 '비구(vague)' 용어다.

  반면에, 이런 간단한 변화를 함으로써, 우리는 현재의 시스템에 대한 모든 것을 유지하고, 과거를 포용한다.mbox 구현 변경은 업그레이드와 함께 과거의 의도를 "파괴"해서는 안 된다.또한 Template:경고는 내용 "경고" 이상의 용도로 사용되었다.템플릿과 동일:주의하다.그것은 사용자들에게 고시를 높이는 것에 관한 것이었다.그리고 그것은 또 다른 문제다.이 상자들은 사용자 행동 통보에도 사용되고 있다.분명히 그들은 "상기사항들 중 하나"가 아니다.하지만 이 간단한 이름 변경으로, 이 모든 상자들 역시 이 계획에 쉽게 동참할 수 있다.

  어떤 계획이라도 적응할 수 있어야 한다.그리고 현재 스타일은, 그러나 그 이름들은 그 적응력을 반영하지 못한다.

  반면에 과거 시스템은 그렇다.

  나는 적어도 코디네이터들에게 외모를 바꾸는 것에 대한 반대 의견에 놀란 것 같다.- jc37 00:21, 2008년 11월 21일 (UTC)[응답]

'삭제' 타입이 삭제 통지 이외의 어떤 것에 대해서도 올바르게 사용되는 경우는 아니다.그 type=delete형식은 단순한 스타일 이상을 나타내기 때문에 다른 용도로 사용되어서는 안 된다.타입은 예를 들어 스크린 리더를 사용하는 블라인드 편집자에게 매우 귀중한 메타데이터로서, 콘텐츠의 억양이 주변 계층(다른 것 중)에 의해 지배된다.올바른 것은 사용하는 것이다. type=content모든 심각한 경고에 대해 그리고 경고가 진정으로 중요한 경우 기본 스타일을 무시하십시오. 단, 이는 가볍게 수행되어서는 안 된다.예를 들어, Talk:무함마드.상단의 이미지에 대한 경고는 '삭제' 타입을 사용하는 것으로 보이는데, 이것은 이 제안의 유래인 오해다.실제로 위키코드를 보면, 첨부된 기사의 내용에 관한 메시지인 것처럼 메시지의 유형이 「내용」으로 정확하게 설정되어 있다.메시지의 극단적 중요성은 그것을 돋보이게 하기 위한 급진적인 조치들을 보증하는데, 이 경우 삭제 상자에서 빨간색 테두리를 사용하는 것은 합리적이고 받아들일 수 있다.그러나 이 상자는 삭제 템플릿이 아니기 때문에 "삭제" 유형을 사용하는 경우가 아니며, 이러한 사용을 묵인해서는 안 된다!우리는 현재 매우 중요한 메시지 범주가 하나의 클래스 이름, 귀중한 도구, 그리고 우리가 버리면 안 되는 것으로 구별되는 상황에 있다.mbox 시리즈는 한 페이지에 나오는 모습보다 훨씬 더 많은 것이 있다는 것을 기억하라.「콘텐츠」형 템플릿이 있는 상황은, 「콘텐츠」형과 「스타일」형의 명칭이 다른 것에 비해 분별력이 떨어진다는 것을 인정한다.그러나 일반적인 메시지에는 네 가지 유형이 있는데, "통지", "스타일", "내용"의 세 가지가 있다.삭제와 관련 없이 주황색으로 표시된 스타일보다 더 눈길을 끄는 경고를 표시할 필요가 있는 경우는 드물지만, 이러한 드문 경우 삭제 유형이 아닌 사용자 정의 스타일을 사용해야 한다.

그것은 차치하고라도, 당신은 절대적으로 눈에 보이는 이득이 없는 엄청난 양의 일을 만들어 내는 이 변화가 정말로 생산적인지 물어봐야 한다.나는 mbox 타입이 3가지 템플릿의 '구' 세트와 다르다는 것에 동의하지만, 지금 보면, 그들이 현재 적절한 mbox 스타일을 사용하고 있다는 것을 알 수 있고, 수개월 동안 그렇게 해왔다.나는 이러한 스타일의 변화에 대한 진정한 불만이 없다고 본다. 이것은 우리가 과거에 얽매이지 않고 자유롭게 앞으로 나아갈 수 있다는 것을 의미한다.이 경우, 어떻게 두 개의 이름을 바꾸면 통지/주의/경고 계층과 "더 잘 통합"할 수 있는지 잘 알 수 없다: 모든 유형 이름이 내부적인 것으로 볼 때, 이미 완전히 통합되어 있다.내가 위에서 상세히 설명했던 "삭제" 타입의 잘못된 사용을 장려하기만 하면 된다.전반적으로, 나는 이 변화가 필요하거나 유용하다고 생각하지 않으며, 말 그대로 수백만 페이지의 리카피를 강요할 수 있는 많은 다른 템플릿(수백 개가 보호되고, 손으로 만들어져야 하는 것)에 대해 많은 편집이 필요할 것이라는 점에 주목한다.우리가 우리의 변화에 대해 계속 분별 있게 생각하고, 이와 같은 포괄적이면서도 궁극적으로는 사소한 의미적 변화를 채택하지 않는 한, 수행은 문제가 아니다.그것이 어떤 식으로든 메인 스페이스에 영향을 미치는가?아니, 왜 이 모든 인프라가 여기 있지?메인 스페이스를 위해서.우리가 우리의 시간을 보낼 더 좋은 일이 있을까?그래. 그럼 가서 해피멜론 23:49, 2008년 11월 20일 (UTC)[응답하라]

위에서 말했듯이, 나는 코더들이 이것의 요점을 이해하지 못할 것이라고 추측했다.그리고 위의 논평은 그것을 보강하는 것처럼 보일 것이다.

그리고 우연히, 거의 모든 mbox는 어떤 식으로든 "내용"과 관련이 있다.그래서 그 이름만으로도 다소 끔찍한 오성어다.그리고 Template을 만드는 것은 제쳐두고: 경고는 "오렌지" 수준의 mbox가 역사적으로 사용되었던 것과 반대되는 것처럼 보일 것이고, 그것을 변경함으로써, 여러분(누가 변화를 만들었는지)은 이제 페이지 수에 상관없이 영향을 주었다.

그런데, 이름을 바꾸는 것은 "화면 판독기를 이용한 시각장애인 편집자"에게 영향을 미치지 않을 겁니다. 왜냐하면 우리는 스타일 자체를 바꿀 수 없기 때문이지요.

마지막으로, 당신이 하고 싶은 다른 일이 있다면 가서 즐겨라 : ) - jc37 23:57, 2008년 11월 20일 (UTC)[응답하라]

나는 템플릿 코더의 의견이 "그들은 요점을 이해하지 못할 것"이라고 일방적으로 선언하는 것은 이 논의와 무관하다고 생각하지 않는다.제안된 변경은 템플릿 코드 작성자 외에 위키백과의 어느 누구도 정확히 영향을 미치지 않기 때문에, 그들의 논평은 확실히 매우 중요할 것이다.단순히 자신의 의견에 동의하지 않는다는 이유만으로 누군가의 의견을 할인하는 것은 제안을 전달하는 방법이 아니다.

내가 위에서 말하는 요점은, 매우 명백한 의미적 의미를 지닌 "삭제"에서 덜 명백하게 삭제 전용의 "경고"로 클래스 이름을 변경함으로써, 당신은 단지 삭제 메시지 이상을 위해 그러한 유형을 사용하는 사람들을 격려하고 사실 적극적으로 지원한다는 것이다.즉, 내가 이미 제시한 이유로, 적극적으로 도움이 되지 않는 것이다.명칭 변경은 이름 변경 때문이 아니라 관련 의미 변경으로 '화면 판독기를 이용한 블라인드 에디터'에 영향을 미치고, 부정적인 영향을 준다.그래서 우리는 이 제안으로 인해 적극적으로 불이익을 받고 있는 위키백과 독자들 집단을 가지고 있는데, 과거에 얽매여 있어서 양식적 변화에 적응할 수 없는 사람들을 제외하고는 아직 그 누구도 혜택을 볼 수 있을 것이라는 증거는 없다.이러한 변화에 의해 혜택을 받을 수 있는 유일한 사람들은 편집해야 할 이유가 있는 사람들이다.{{caution}}그리고{{warning}}템플릿, 그리고 이점은 정말 사소한 것이다."와, 템플릿 이름과 같은 타입의 이름을 쓰면 되겠군...쾅쾅"그래서 우리는 지난 1년간 수백 명의 편집자들이 두 개의 템플릿의 의미적 개선을 위해 앰박스 유형 매개변수를 배우기 위해 소비한 시간을 버려야 하는가?다른 페이지는 고사하고 수천 개의 다른 템플릿(암박스에만 750개 이상)을 편집해야 하는가?정확히 어떤 페이지에도 눈에 띄는 변화가 없는 겁니까?내가 이 일의 요점을 모른다는 너의 말이 옳다.나를 놀라게 하는 것은 네가 어떻게든 그렇게 한다는 것이다.

내 입장을 분명히 하기 위해서, 위에서 잘못 전달된 것 같다.'삭제'에서 '경고'로 바뀐 것은 의미적 명확성의 상실을 상징하기 때문에 백과사전에 적극적으로 피해를 주고 있다.'매우 심각한' 경고를 처리하는 올바른 방법은 개별 인스턴스의 스타일을 수동으로 재정의하는 것이다.제안된 "내용"에서 "주의"로 바꾸는 것은 확실히 백과사전에 영구적인 피해를 주지는 않지만, 내 마음속에는 전혀 무의미하다.만약 우리가 다시 우리의 시간을 가졌다면, 아마도 우리가 그것들이 결국 메인 스페이스 밖에서 사용될 것이라는 것을 알았다면, 우리는 이러한 종류의 다른 이름들을 선택했을 것이다.그것은 역동적으로 진화하는 위키에서 흔치 않은 상황이 아니다.이전 명칭보다 훨씬 명확하지 않은 유형 명칭 집합으로 변경할 것을 제안한다. 이는 현행 시스템의 사용법 및 대폭적인 범위보다 OP와 완전히 다른 어느 누구도 변경에 반대하지 않은 구식 메시지 시스템의 준수를 더 중요시하는 것으로 보인다.-그 세 가지 템플릿보다 범위가 넓다.이러한 스키마 변경을 구현하는 데 필요한 무서운 양의 작업을 수행하는 것은 극단적으로 무의미해 보인다.그리고 당신의 다소 불필요하게 가시적인 최종적인 논평에 대답하기 위해, 나는 나중에 시간을 보내기 위해 여기 머무르고 있다. 그렇지 않으면 다른 많은 템플릿 코딩자들처럼, 이 제안이 남기고 간 깨진 유리 조각들을 줍는 일을 하고 싶다.해피멜론 15:53, 2008년 11월 21일 (UTC)[응답]

tl;dr. 그러나 요약하자면, "삭제"의 클래스 이름은 유용한 함축이 있기 때문에 "삭제"를 "경고"로 바꾸는 것에 반대하며, "내용"을 관련 작업을 넘어 "주의"로 바꾸는 것은 신경 쓰지 않는다는 것이다.중대 경고에 사용하기 위해 별도의 클래스 "경고"를 만드는 것과 유사하게 반대하십니까?결국, "콘텐츠+엑스트라 스타일"에 대한 "경고"도 유용한 의미적 가치를 가질 것이다; ;) Anomyie⚔ 18:01, 2008년 11월 21일 (UTC)[응답]

나는 여러분 다 너네 때문-그것은 그 요약이 무엇을 위한 것인지:D. 그렇게 말할 수 없잖아로, 문자 메시지의 eye-catching-ness 증가하는 'arms 경주'을 장려할 것이다. 나는 또한 'very 심각한 경고'이 새로운 형태를 만들 편집자들이 스타일을 재정의할 것을 요구하는 두번 그들을 만들고 있는 경고 메시지 정말 그렇구나에 대해서 골똘히 생각하도록 반대를 받을 것이다.그러한 특별한 대우를 요구하기 위해 끔찍할 정도로, 극소수의 경우 그것은 진정으로 그렇게 한다.물론 당신이 말하듯이 이것은 그러한 메시지를 구분하는 의미적 가치에 대해 저울질해야 한다...하지만 만약 우리가 "매우 심각한 메시지"를 위한 추가 유형을 만든다면, 사실, 특히 무시무시한 메시지들로 빠르게 채워질 것이고, 따라서 무기 레이스를 영구화시키고 의미적 구분을 무용지물로 만들 것이다.보시다시피 나는 이 제안에 근본적으로 반대하지는 않지만 전적으로 확신하지는 않는다.나는 "내용"을 "주의"로 바꾸는 것에 대해 "신경 쓰지 않는다"고 말하지 않을 것이다. 관련 작업은 매우 중요하며, 아마도 우리가 시간을 낭비하지 않는 것이 더 낫다고 생각할 것이다.누군가 봇을 쓰고 느슨하게 설정하는 것만큼 간단하다면, 비록 여전히 혼란과 통나무, 감시목록 등의 부피가 있을 것이다.그리고 나는 가시적인 이익 없이 그렇게 광범위한 변화를 완성하는 것이 이 프로젝트에 순손실이 되지 않을 것이라고 전적으로 확신하지 못한다.그러나 나의 요점은 확실히 "삭제"에서 다른 것으로의 변화는 적극적으로 해로울 것이라는 것이다.해피멜론 18:51, 2008년 11월 21일 (UTC)[응답]

"적극적으로 해롭다?"나는 mbox 컨벤션은 좋은 생각이라고 생각한다.위키피디아는 제정되지 않으면 가라앉지 않는다.그리고 그것은 어떤 기본 스타일에도 해당된다.그래서 나는 그것이 어떻게 지원될 수 있을지 잘 모르겠다.

"이름을 바꾸는 것은 "화면 판독기를 사용하는 맹인 편집자들" 특히, 다른 것들 중에서도, 이름 변경 때문이 아니라, 관련된 의미 변화 때문에 그들에게 부정적인 영향을 끼친다." - 나는 분명히 이것을 이해하지 못하는데, 당신은 분명히 말할 것인가?

템플릿은 고려해 보셨습니까?경고라는 스타일이 문제가 될 수 있다고 느끼는 방식으로 경고?왜냐하면 그게 우리가 기본적으로 해야 할 일이기 때문이다.mbox가 구현되었을 때 경고 템플릿의 하위 변환은 스타일 유형과 대신 mbox로 대체되었다.그래서 지금 우리가 하고 있는 일은 그것을 반영하기 위해 그 스타일 타입의 이름을 바꾸는 것이다.이것은 솔직히 앰박스 이행 단계에서 더 깊이 고려되고 충분히 논의되었어야 할 사항이지만, 당시에는 기사 박스에 대한 논의가 더 많았기 때문은 아니었다.그리고 이것들은 다른 네임스페이스에 더 많이 사용되었다.그러나 다른 네임스페이스의 실행이 이루어졌을 때, 모든 사람들은 앰박스 논의에 근거하여 합의를 보았고, 컨센서스가 바뀔 수 있다는 정책에도 불구하고 다른 논의를 강행했다고 주장했다.그리고 코더들이 단결하여 어떤 것을 고려하지도 않겠다고 말할 때 코더 이외의 편집자들이 해야 할 일은 무엇인가? (부당하게도, 내가 "코더"라고 말할 때, 나는 더 복잡한 템플릿을 설계하고 있는 사람들에 대해 말하고 있는 것이다.단지 전폐를 위한 템플릿에 파라멘터를 입력하는 사람들이 아니다.혼란스러웠던 점 사과)

그래서 지금 우리는 되돌아보고 있다. mbox와 its의 클론이 구현되었지만, 현재 템플릿의 사용량을 기준으로 문제가 나타나기 시작하고 있다.또한, 다른 과거 템플릿과 어떻게 mbox 컨벤션에 통합될 수 있는지에 대한 문제도 있다.

이 제안은 그 모든 것을 해결할 것이다.

내가 너의 요점을 모두 언급했는지는 모르겠지만, 만약 내가 놓쳤다면, 언제든지 나에게 말해줘. - jc37 20:03, 2008년 11월 21일 (UTC)[응답]

당신의 처음 두 인용구는 특히 "삭제"를 "경고"로 바꾸는 것을 언급한다. 우리는 최근에 위키백과의 "삭제"로 관련되는 모든 템플릿을 "xbox-delete" 스타일에 따라 CSS 수업을 사용하도록 표준화함으로써 큰 진전을 이루었다.즉, 이러한 사물을 삭제하기 때문에 특수 지침이 적용되어 이러한 사물을 다르게 취급할 수 있다는 것을 의미한다 - 시각장애인 편집자는 이러한 경고를 먼저 읽도록 화면 판독기를 구성할 수도 있고, 색맹 편집자는 구별할 수 있는 경고로 색상을 바꿀 수도 있고, 위키백과 프로세스를 분석하는 연구자들은 위키백과 과정을 적극적으로 분석할 수도 있다.이 템플릿들의 페이지를 장식하다.만약 우리가 "경고"로 이름을 바꾸면, 우리는 이러한 계급들이 다른 것에 사용되도록 적극적으로 권장하고, 그 의미적 명확성을 파괴한다.뒤로 물러서는 것이 매우 어려운 환경에서, 이것은 그들 중 하나일 것이다.따라서, 그것은 백과사전에 적극적으로 해로울 것이고, 이러한 방식으로 수업을 이용하는 독자들에게 부정적인 영향을 미칠 것이다.

변경되어서는 안 되는 "삭제" 타입을 제외하고, 나는 노란색과 오렌지색 박스에 대한 "스타일"과 "내용"이라는 명칭이 사용 가능한 가장 명확한 용어가 아니라는 것에 동의한다.실제로, 우리가 앰박스 개발에 있어서 그 유형이 결국 모든 네임스페이스에 전파될 것이라고 예상했다면, 우리는 다르게 선택했을지도 모른다.안 했어, 그래서 안 했어, 그리고 이제 우리가 가진 걸 얻었어.그러나, 다른 mbox들이 어떻게 해서든 합의를 이루지 못했다고 결론짓는 것은 공평하지 않다: 각 mbox들은 개별적으로 논의되고 배치되었고 앰box에 다른 타입의 이름을 사용하자는 제안은 어디에도 없었다.정말로 그렇게 하는 것은 우스꽝스러웠을 것이다.

당신은 "코더들이 단결하여 [당신의 제안]을 마치 그것이 일어났고 나쁜 일처럼 생각하지 않을 것"이라고 주장한다.위에서 볼 수 있듯이, 나는 당신의 제안을 많은 "고려"했고, 왜 그것이 전반적으로 나쁜 생각인지에 대해 세 개의 화면을 통해 썼다."더 복잡한 템플릿을 설계하고 있다"는 편집자들이 다른 편집자들보다 내부 작업(그리고 그들의 특색에 대한 이유)에 대해 더 많이 알 수밖에 없기 때문에, 토론에 대한 그들의 의견을 할인하는 것은 그리 현명하지 않을 것이다.물론 이 토론이 여기서 일어나는 이유는 우리가 가능한 한 광범위한 참여를 얻을 수 있기 때문에 템플릿에 깊이 관여하지 않는 편집자들의 논평과 제안을 무시하는 것은 삼촌이나 마찬가지겠지만, 토론의 목적은 유용한 콘텐트를 가진 모든 사람들의 전문지식과 경험을 끌어내는 것이다.제공할 늑골

나는 니힐트레스의 코멘트에서 이 토론을 계속할 것이다. 나는 그것이 이곳의 상황을 가장 정확하게 요약한다고 생각하기 때문이다.해피멜론 11시 57분, 2008년 11월 22일 (UTC)[응답]

내가 정리해야 할 점: 과거에 대해 이야기할 때, 나는 앰박스와 관련된 몇 가지 토론을 언급하고 있다.그 좋은 예가 "핑크" 속도에 대한 시행에 대한 격렬한 항의를 한 것인데, 그 결과 처음에는 "코더"들이 반대하던 "스피디" 스타일의 "가짜"가 되었다.그것들 보다 더 많은 예들이 있었지만, 대부분은 a.)를 논의하려고 하는 것이 전체를 탈선시킬 수도 있다는 제안에 의해 강행 처리되었고, 대부분은 "더 늦게" b.) 대부분의 토론에서 마지막 논쟁은 (패러프레이싱: "마음에 들지 않으면, 터프하게, 우리는 이것을 코딩하고 있기 때문에 우리는 이렇게 하고 있는 것이다.다른 것이 마음에 들면 직접 코드화하십시오."나는 이것이 베리론의 입장이라고 말하는 것이 아니라, 그것은 충분히 흔했다.그래서 어쨌든, 그것은 대략 내가 언급했던 것의 일부분이다.

당신은 정말로 이것을 고려했던 것 같고, 당신의 최초 게시물이 처음에 지적한 것보다 더 많이.그래서 만약 내 논평에서 어떤 것이라도 당신에게 부정적인 느낌으로 보인다면, 당신은 내가 사과해야 한다.- jc37 12:48, 2008년 11월 22일 (UTC)[응답]

나는 내가 지금 그 문제를 더 잘 이해하고 있다고 믿는다. 검토 중에.메인 스페이스 공지(고시 등급 분리가 양호함)를 위해 설계된 mbox 유형의 내부 설계와 범용 경고 메시지로 설계된(따라서 본질적으로 모호함) 당신이 언급한 일련의 템플릿 사이에 상당한 차이가 있다.나는 여전히 메인 스페이스의 기본 mbox 유형 이름을 현재 제안된 방식으로 바꾸는 것에 반대하지만(그러면 가치 있는 의미적 일관성을 잃게 되므로), 예를 들어, 대화 네임스페이스와 같은 일부 유형 이름이 일치하지 않는다는 점에서 좋은 점이 있다.나는 세 번째 해결책을 고려할 필요가 있다고 생각한다: 당신의 해결책은 메인 네임스페이스에 적용되는 시스템을 죽이는 반면, 우리의 현재 시스템은 너무 최적화되어 있어서 예를 들어 특정 "암박스"와 반대로 일반적인 "mbox"로 적용될 수 없다.이것에 대해(지금 이 시각은 ~2AM까지) 숙고하고 곧 좀 더 구체적인 앞으로 나아갈 방법을 생각해 낼 것이다.{{Nihiltres talk log}} 07:11, 2008년 11월 22일 (UTC)[응답]

네, 바로 그겁니다.

아마도 이것을 다루는 한 가지 방법은 또 다른 "빨간색" 타입을 갖는 것이 아닐까?우리는 이미 스피디(빨간색, 분홍색 음영이 있는 빨간색)를 가지고 있고, 삭제한다.삭제 템플릿에만 "삭제"를 유지하면서 "빨간색 유형"으로 사용할 "경고"를 추가한다면?

그것이 대부분의 문제를 해결할 수 있을까?

내용과 스타일에 대해서는 잘 모르겠다.우리는 아마도 대체 오렌지 타입으로 주의를 더할 수 있을 것이다(그리고 나는 그것을 받아들일 수 있다), 그러나 나는 또한 우리가 단지 더 많은 스타일 타입을 추가하는 모범을 보이는 것에 대해 아마도 주의해야 한다고 생각한다.특히 내용과 주의는 본질적으로 스타일리시하게 동일할 수 있기 때문에 더욱 그렇다.

단순히 "주의"와 "경고"를 추가하는 것이 할 수 있는 한 가지 일은 아이콘을 해결하는 것이다.삭제 스타일의 템플릿은 정말 아이콘이 필요하지 않고, 텍스트의 덩어리 입니다.그리고 삼각형 "!"는 "주의"(현재 삭제에 사용되고 있음)의 아이콘이었고, 스톱스ign은 "경고"의 아이콘이었다.이 두 가지를 추가하면 컨텐츠는 그것의 "원!"을 유지할 수 있고 (그 용도가 컨텐츠와 관련이 있는 것으로 보다 명확하게 정립됨) 삼각형 "!"을 가질 수 있다. (그 용도가 "내용"에서 명확해짐)

더 많은 생각들이 분명히 환영한다.- jc37 12:48, 2008년 11월 22일 (UTC)[응답]

당분간 아이콘 토론은 하지 마십시오.그것은 별개의 문제다만약 네가 여기에 그것을 섞으면 이 토론은 너무 혼란스러울 것이다.

어쨌든 mbox 유형 이름 관련:나는 mbox 프로젝트가 시작된 지 거의 다 되어가고 있어서 여기에 와서 코멘트를 해 달라는 요청을 받았다.

짧은 버전:나는 해피멜론과 니힐트레스에 동의한다.그리고 나는 Jc37에 동의하지 않는다.

긴 버전:이것은 상당히 복잡하고 큰 스타일의 체계로서, 이것을 읽을 많은 사람들은 세부사항을 모르기 때문에 세부사항을 살펴보자.

1: "템플릿"이라는 용어는 메시지 상자뿐만 아니라 모든 종류의 템플릿을 의미할 수 있다.

2: 여기서 우리는 "메시지 박스"와 같은 종류의 템플릿에 대해 이야기하고 있다.이러한 상자는 메인(기사) 공간에서는 쓰이지만, 토크 공간인 "위키피디아:" 공간, 이미지 공간 등 다른 공간에서도 사용된다.

3: 기사 메시지 상자가 만들어지고 텍스트가 들어 있을 때 우리는 이를 "알림"이라고도 부른다.예를 들어 경고 메시지 상자는"경고 통지"라고 불릴 수 있고"삭제 통지"등이 있으므로 mbox 유형 통지서와 혼동해서는 안 된다는 점에 유의하십시오.

4: 브라운 토크 페이지 메시지 박스 표준이 설계된 2005년 이후 메시지 박스 표준화가 진행되어 왔다. 위키백과:토크 페이지 템플릿.그리고 "위키피디아:" 공간의 메시지 상자는 그 이전부터 비공식적인 기준을 가지고 있었던 것 같다.

우리가 표준화하기 전에 메시지 박스가 어떤 모습이었는지.

5: 2007년 여름, 우리는 기사 메시지 박스를 표준화했다(주공간).그리고 편의를 위해 {{ambox}}메타템플릿과 "ambox-*" CSS 클래스를 만들었다.위키백과를 참조하십시오.기사 메시지 상자.그리고 그 때 우리는 유형 이름 통지, 스타일, 내용, 삭제 등을 선택했다.그래서 그 이름들은 주(기사)공간만을 염두에 두고 선택되었다.그래서 우리가 그것들을 다른 네임스페이스에 다시 사용할 때, 그러한 유형의 이름들 중 일부는 약간 이상하다.

6: 2008년 봄과 여름에 우리는 다른 모든 네임스페이스에 대한 메시지 박스를 표준화했다.그리고 우리는 오래된 브라운 토크 페이지 표준과 회색 "위키피디아:" 우주 표준을 다소 연장해서, 그들은 기사 메시지 상자와 같은 "색깔 사다리"를 얻게 되었다.이로써 '위키피디아:'와 '사용자 공간' 등 '기타' 공간은 모두 메타템플릿 {{tmbox}}, 이미지 공간 {{imbox}}, 카테고리 공간 {{cmbox}}}, {{ombox}}}}}의 메타템플릿이 탄생했다.

7: 다른 네임스페이스에 대한 mbox를 설계할 때 ambox 매개 변수 이름을 다시 사용했다.그 이유는 사람들이 이미 {{ambox}} 파라미터에 익숙해져 있었고, 어떤 페이지를 사용하느냐에 따라 자동으로 스타일이 바뀌는 {{mbox}를 만들고 싶었기 때문이다.(일부 메시지 상자는 두 개 이상의 네임스페이스에서 사용되므로 mbox가 필요하다.)mbox가 잘 작동하기 위해서는 동일한 기본 유형의 이름 집합을 지원하는 모든 mbox 템플릿이 필요하다.즉, 통지, 스타일, 내용, 삭제 및 기타.

8: 기술적으로 우리는 mboxes가 동일한 스타일에 대해 둘 이상의 유형 이름을 이해하도록 할 수 있어, 우리는 원활하게 전환을 할 수 있어.사실, 한동안 빨간 앰박스 타입은 "형=심각"이라고 불렸다.우리가 덜 혼란스러운 이름 "type=delete"로 바꾸었을 때, 우리는 암박스가 페이지의 수천 개의 사용 사례를 바꾸는 데 걸린 몇 달 동안 두 매개변수를 모두 이해하도록 만들었다.우리는 또한 CSS 클래스 이름을 "ambox-seest"에서 "ambox-delete"로 변경했다.이러한 변환은 여전히 100% 수행되지 않으므로 MediaWiki에서 CSS 클래스 이름을 모두 가져야 한다.common.css.그래서 그 개조를 한 우리는 그렇게 널리 사용되는 유형의 이름을 바꾸는 것은 엄청난 노력이고 1년 정도의 시간이 걸린다는 것을 알고 있다.원활한 전환을 위해 관련된 모든 단계를 설명하려면 몇 페이지 분량의 텍스트를...

9: 동일한 스타일에 여러 유형의 이름을 사용하는 것은 메타 템플릿 사용자들에게 매우 혼란스러울 수 있다.무엇보다도, 그것은 유형 이름이 더 이상 CSS 클래스 이름과 일치하지 않는다는 것을 의미한다.그리고 네임스페이스를 감지해 어떤 페이지 유형에 따라 자동으로 스타일이 바뀌는 {{mbox}를 사용하면 특히 지저분해진다.그리고 만약 우리가 어떤 타입에 두 번째 이름을 추가한다면, 우리는 그것을 영원히 지지하는데 갇히게 되고, 그것은 시간이 흐르면서 뒤에서 많은 일을 야기시킨다.아니면 우리가 완전히 새로운 타입의 이름으로 바꾸는 것을 선택한다면 그것은 엄청난 노력이 필요하다.그래서 나는 이름을 추가하거나 이름을 바꾸는 것은 꼭 필요한 경우에만 해야 한다고 생각한다.

여기서 논의 중인 스타일과 유형 이름은 다음과 같다.

10: 긴급하지 않은 일반적인 통지에 대해서는 "유형=통지"를 사용한다.이 스타일은 보통 파란색이나 회색 또는 각 네임스페이스의 중립 기본 메시지 상자 색상이다.그 타입의 이름은 모든 네임스페이스에 사용해도 괜찮을 것 같고 잘 받아들여지고 있다.

11: 사소한 경고의 경우 노란색 "유형=스타일"을 사용한다.그것은 주요 (기사) 공간에서 잘못된 표현이나 잘못된 철자 등과 같은 스타일 문제에 대한 통고를 의미하기 때문에 그러한 이름을 얻었다.다른 네임스페이스에서는 사소한 비긴급 경고에도 사용할 수 있다.

12: 주요 경고를 위해 우리는 오렌지색 "유형=내용"을 가지고 있다.그것은 주요 (기사) 공간에서 내용 문제에 대한 통지를 위한 것이기 때문에 그러한 이름을 얻었다.기사가 잘못된 사실을 가지고 있거나 중립적인 관점을 사용하지 않는 것, 그리고 우리가 기사에 심각한 문제를 고려하는 다른 문제들.다른 네임스페이스에서는 주요 경고에 사용할 수 있다.여기에는 어떤 종류의 긴급 경고도 포함된다.

13: 삭제 알림에는 빨간색 "유형=삭제"가 표시되며, 빠른 삭제를 위해서는 빨간색+핑크 "유형=속도"가 표시된다.붉은색 스타일은 적어도 삭제 통지가 엄격히 지정된 메인(기사) 공간에 있다.물품 공간에 있는 다른 긴급 경고는 오렌지색 "유형=내용" 스타일을 사용해야 한다.이것을 위해 우리는 폭넓은 공감대를 가지고 있다.

14: 빨간색은 사용자와 사용자 대화 페이지에 배치되는 최상위 블록 메시지에도 사용되어야 한다.대부분의 사용자들도 이에 동의하는 것 같다.그러나 내가 아는 한 그러한 블록 메시지의 스타일은 아직 제대로 표준화가 되지 않았기 때문에 우리는 블록 메시지의 경우 노란색, 주황색, 빨간색을 언제 사용해야 하는지 정확히 알지 못한다.

사용자가 영구적으로 차단되었다는 메시지를 나타내는 메시지처럼 매우 높은 수준의 차단 메시지에 대해서만 빨간색 색을 사용할 경우, 어떤 의미에서 "type=delete"라는 이름을 사용하는 것은 꽤 괜찮다고 생각한다.어쨌든 나는 그런 "영구적으로 금지된" 타입의 좋은 짧은 이름을 생각해 낼 수 없다.그래서 나는 적어도 당분간은 거기에 약간 이상한 "유형=삭제"라는 이름을 붙일 수 있다고 생각한다.그러나 개인적으로 나는 사용자 경고와 차단 메시지에 사용할 색상에 대한 관점이 그리 많지 않다.

15: 다른 네임스페이스의 경우, 우리들 대부분은 메인(기사) 스페이스와 같은 규칙을 적용하기를 원하는 것 같다.즉, 주요 경고의 경우 주황색, 삭제의 경우 빨간색이다.그러나 일부 사용자는 다른 네임스페이스의 긴급 메시지에 빨간색을 사용하기를 원한다.위에서 이 논의를 시작한 jc37도 그 중 한 명인 것 같다.그리고 나는 Jc37에게 더 중요한 것은, 그는 중간 단계의 경고 메시지를 사용자들의 대화 페이지에 올리기 위해 빨간 스타일을 사용하고 싶다고 생각한다.그리고 그것이 Jc37이 빨간 스타일이 "타입=경고"가 되기를 원하는 이유인 것 같다.(Jc37과 나는 이전 {{주의}}}, {{경고}}의 토크 페이지에서 이것에 대해 의논하고 있었기 때문에 이것을 알고 있다.)Jc37 등이 그런 사용자 경고 메시지에 빨간색을 사용한다는 것은 별로 개의치 않지만, 그것 때문에 빨간 스타일을 "유형=경고"라고 명명하는 것에 강력히 반대한다.하나의 네임스페이스는 다른 모든 네임스페이스에서 이상한 유형의 이름을 지시해서는 안 된다.(물론, 현재의 "스타일/내용/삭제" 명칭은 본공간에서 나오지만, 그것은 역사적 이유에서입니다.)그리고 특히 사용자 공간은 다른 네임스페이스에 대해 어떤 것도 지시해서는 안 된다.그리고 특히 사용자 대화 페이지의 경고 메시지에 대해 어떤 스타일을 사용해야 하는지가 아직 제대로 표준화되지 않았다.

16: 일부 유형의 이름을 추가하면 다음과 같이 명명하십시오.

• 사소한 비긴급 경고:노란색 "유형=유형"은 "유형=주의"라고도 할 수 있다. (그래서 나는 Jc37이 원하는 것보다 한 단계 낮은 레벨에 "주의"가 사용되기를 원한다.)
• 모든 주요 경고, 종종 긴급 경고:오렌지 "타입=내용"은 "타입=경고"라고도 불릴 수 있다.
• 삭제 통지 및 최상위 차단 메시지:빨간색 "type=delete"."유형=경고"라고 부르면 안 된다.따라서 변하지 않았다.아마도, 우리가 그것에 대해 정말로 필요성을 느낀다면, "type=block"이라는 이름을 추가해라.그러나 사용자 경고와 사용자 차단 메시지의 색상 수준이 적절히 표준화되기 전까지는 사용자 대화 공간에 새로운 이름을 추가해서는 안 된다고 생각한다.

그래서 나는 우리가 "주의"와 "경고"라는 유형명을 사용할 것을 제안한다. 그러나 Jc37이 제안하는 것보다 더 낮은 색상 수준에 대해서는 말이다.비록 나는 현재 우리가 그 이름들에 완전한 전환을 하지 않고, 그 이름들을 추가 이름으로 추가할 수도 있다고 제안하고 있다.하지만 두 가지 선택 모두 엄청난 양의 비용이 들 것이기 때문에 나는 매우 망설인다.

17: 그리고 Jc37에게 질문이 하나 있는데, 당신이 이름을 바꾸고 싶어하기 때문이다.새 이름으로 전환하는 데 수개월이 걸리는 작업을 넣을 준비가 되셨습니까?우리가 동의하지 않는 이름으로 바꾸고 싶다면, 우리가 당신을 위해 그 일을 하기를 기대할 수 없을 겁니다.

이 긴 메시지는 미안하지만, 이건 복잡한 문제야.

--David Göthberg (대화) 2008년 11월 22일 (UTC) 15:27[응답]

고장났어.더 명확하게 할 수 있도록 도와줘서 고마워.

몇 가지 사항:

이것에 대한 나의 이유(여러 번 추측된 바)는, 위에서 언급한 다른 사람들이 지적한 모든 상황에서, 적응할 수 있고 유용한, 일관된 것을 보고 싶기 때문이다.그리고 더 나아가 역사적 템플릿(특히 주의와 경고, 후자)을 퇴보하는 것은 다소 서툴렀으며, 이를 이행하는 최선의 방법은 아닐 것이라고 생각한다.

따라서 일관성의 아이디어에 기초하여, 경고 사용자에게 경고하거나, 삭제에 대한 경고 또는 기타 경고를 위한 최상위 레벨이든, 빨간색은 가장 높은 "경고"가 되어야 한다.그래서 레벨이 빨간데?Mbox가 나오기 훨씬 전, 그리고 앰박스 논의에서 고려하지 않았던 것이, 그것이 기사에 초점을 맞췄기 때문에.그 이후 대부분의 토론은 장황하지만 템플릿 토크로 진행되었다.(그래서 VP와 CENT 공지가 있었지만 앰박스 논의만큼 활발한 곳은 없었다.게다가, 대부분의 토론은 DavidGothberg가 위에서 했던 방식을 해결했다: "이것은 앰박스에서의 합의였고, 우리가 동의하지 않기 때문에, 우리는 대체 아이디어를 구현하는 것을 돕지 않을 것이고, 그래서 우리는 기정사실화함으로써 "이긴다" - "우리가 당신을 위해 그 일을 하기를 기대할 수 없다." - 위키피디아 사람들이 "도와줘서 기쁘다"는 것..) AFAIK, mboxes만이 내가 그에게 동의하지 않았던 유일한 장소라면 그 주제에 주목해야 하며, 솔직히 그를 편집자, 코더 등으로 존경해야 한다.그리고 그는 내가 기술적인 질문이 있다면 가장 먼저 가는 곳 중의 하나이다.)

그리고 "내용"이 "주의"와 같지 않고, "삭제"가 "경고"와 같지 않기 때문에, 특히 dg 노트처럼, 그는 "경고"가 역사적으로 그랬던 것처럼 붉은색이 아니라 이제 주황색으로 되어야 한다고 제안한다.그리고 그 실행의 가정은 무엇을 했는가?그것은 "경고"와 "주의" 템플릿을 동일(주황색)으로 만들었다.그리고 이것은 분명히 문제를 일으킨다.

따라서 지금까지 논의한 내용을 바탕으로 한 나의 수정 제안은 다음과 같다.

1.) 삭제 템플릿은 아이콘을 사용하지 않기 때문에, 특히 해피멜론이 위에 제시한 이유로 삭제 템플릿에만 "삭제"를 사용한다는 생각을 강행하고자 한다면, "스타일"의 일부로서 그마저도 가질 필요가 없다.

2. 따라서 삭제 템플릿의 기본값으로 현재 사용 중인 삼각형 "!" 아이콘을 지정할 수 있다(이러한 내용은 (새로 제안된) 오렌지 "주의" 스타일의 기본값을 대신 사용할 수 있다). (이러한 경우 "내용" 스타일은 앰박스에 사용할 수 있도록 그대로 두고, 다른 곳에서는 컨텐츠 관련 mbox가 사용될 수 있다는 점에 유의하십시오.)

3) (새로 제안) 경고 스타일을 만든다.빨간색 수준 및 중지 아이콘 사용(기존과 다름)이것은 또한 위의 다른 사람들이 제시한 몇 가지 문제를 해결하는 데 유용할 것이다.

이것의 "스타일" 부분의 코딩은 아마도 믿을 수 없을 정도로 어려우면 안 될까? (긍정적이지 않아서 물어보는 겁니다.)

그리고 일단 완성되면, 나는 정말로 기꺼이 도울 것이다.한 가지 내가 도울 수 있는 것은 일단 '스타일'이 만들어지고 나면 경고 템플릿의 복원이다.지금까지 구현된 내용은 여러 편집자에게 전파되었으므로, 템플릿:경고를 저하시킨 모든 분들의 단일 기여 이력이 있는지는 잘 모르겠지만, 그렇다면 (평가 및 구현을 위해) 그러한 목록이 도움이 될 것이라고 추측한다.

그렇다, 이것은 더 많은 일을 의미할지도 모른다.그러나 나는 이것이 장기적으로 볼 때, 특히 모든 mbox들 사이의 일관성을 위해 덜 일한다는 것을 의미한다고 생각한다.- jc37 16:26, 2008년 11월 22일 (UTC)[응답]

나는 여전히 노란색과 주황색 색 수준에 대해 생각하고 있지만, 빨간색은 확실히 "삭제"를 유지해야 한다: 이미 모든 네임스페이스에 걸쳐 일관성이 있다.David Göthberg에 의해 언급된 아이콘은 현재 무시되어야 한다. 아이콘은 별도로 정의되고, 지역별로 맞춤화되며, 이 논의의 관점에서 더 큰 골칫거리인 것이다.

각각의 다양한 mbox를 보면 (특수 사례 dmbox와 fmbox를 제외하고) 모두 같은 스타일 세트를 가지고 있으며, Image 네임스페이스 고유의 imbox에는 두어 가지 추가가 있다.이 중 대다수가 "내용"과 "스타일" 문제에 내용 및 스타일 이름을 사용하지 않는다는 점을 인정한다. 이들 대부분은 "내용"에 대해 "주요 이슈"를, "미소한 이슈"를 "스타일"에 대해 "주요 이슈"를 말하기도 한다.자, 가능하다면 네임스페이스에 대한 "내용"과 스타일을 구분하는 것을 선호하기 때문에, 비교적 간단한 몇 가지(그러나, 자연적으로 :), 구현이 복잡한 아이디어를 본다.

1. "내용" → "주요" 및 "스타일" → "소형" 또는 일부에 대해서는 형식 명칭을 보편적으로 조화시킨다.이로 인해 메인 스페이스에 대한 일부 의미가 손실되지만, 네임스페이스에 특정된 형식을 제외한 모든 유형이 모든 네임스페이스에 걸쳐 일치하게 된다.나는 개인적으로 이 해결책이 가장 모호하게 정의된 시스템이기 때문에 싫다.그것은 구현하는 데 시간이 좀 걸릴 완전한 스타일의 변화와 수많은 템플릿에 걸쳐 사소한 변화를 포괄하는 것을 포함한다.
2. 주공간 유형 이름을 보편적으로 선호하고 기존 템플리트 간의 사용을 조화시키십시오.이것이 원래의 해결책이었고, 비록 그것이 많은 템플릿에 대해 다소 어울리지 않는 유형의 이름 문제를 영구화하긴 하지만, 나는 여전히 그것이 타당하다고 생각한다.대부분의 템플릿은 이미 시스템에 만족해야 하지만, 의심할 여지 없이 고쳐야 할 것이 많다.우리는 이 논의에 따라 행동하지 않기로 결정하더라도, 우리의 템플릿이 우리가 선택한 시스템과 조화를 이루기를 원하기 때문에, 어쨌든 이 일을 할 것이다.
3. 메인 스페이스를 다른 네임스페이스에서 분리하십시오. 항상 특별한 경우였습니다."major"와 "minor" 또는 "meh"를 위한 새롭고 모호한 (meh) 클래스를 만들어 메인 스페이스 외부의 모든 곳에서 사용하십시오.다중 네임스페이스 mbox는 단순한 네임스페이스 스위치를 사용하여 사용할 클래스를 결정할 수 있으며, CSS에서는 주로 이름을 변경할 것이다.비록 이것이 다른 네임스페이스에 대한 의미 일치성의 궁극적인 문제를 해결하지는 못하지만, 이것은 아마도 공정한 타협일 것이다. 그리고 정확히 바람직한 것은 아닌 네임스페이스에 걸친 사용의 분열을 야기한다.그것은 대부분의 네임스페이스에 대한 완전한 스타일 변경과 많은 템플릿에 걸친 사소한 변경들을 포함할 것이다.

이것들은 단지 몇 가지 기본적인 제안일 뿐, 그 중 어느 것도 완전히 이상적인 것은 아니다.이상적으로는 두 가지 논쟁적 수준의 일반적 특성을 반영하는 모든 네임스페이스에 대한 명확한 구분을 정의하고, 우리 시스템에 맞지 않는 템플릿들을 조화시키는 일반적인 작업을 할 수 있을 것이며, 아마도 주체가 가지고 있는 대부분의 일관성을 유지하면서 다소 일반적인 성질을 반영하기 위해 이름을 약간 변경할 수 있을 것이다.네임스페이스는 현재 "내용"과 "스타일"과 함께 즐긴다.그 메시지들을 다른 네임스페이스로 구체적으로 나눌 수 있는 방법이 있는가? 그것은 메인 스페이스에서도 효과적으로 작용할 수 있다.나는 우리가 문제를 찾을 수 있을 정도로 잘 정의한다면 아마 우리 모두가 그러한 해결책에 동의할 수 있을 것이라고 생각한다.{{Nihiltrestalk log}}}{18:31, 2008년 11월 22일 (UTC)[응답]

나는 왜 "삭제"가 컬러 체인의 "톱"이 되어야 하는지 모르겠다.다른 종류의 통지("보호"와 유사함)이다.그리고 그와 같은 것으로 주목할 수 있었다.

그것은 우리가 단지 계승적 색채 계획을 제안할 때에만 그곳에 놓여 있었다.그 이후로 우리는 보호장치와 몇 가지 다른 것(특히 다른 mbox를 고려할 때)을 추가했다.그래서 이제 그것은 정말로 상속자가 아니다.ambox의 경우, 다른 색상보다 "중요한" 색상은 없다. 단지 "다름"이다. (예를 들어, "스타일"을 녹색으로, "내용"을 노란색으로 만들 수 있으며, 최종 사용자에게는 큰 변화가 없을 것이다.)

그러나 경고(특히 사용자 조치/전도)를 다룰 때, 실제로 "상위 수준"으로 주황색, 적색, 즉 주황색, 적색, 즉 색상의 계승권을 갖고 싶은 욕구가 있는 것 같다.그리고 "삭제"는 경고식 통지다.솔직히 기술적으로 따지면 '삭제'는 며칠이 지나도 (명확히) 토론으로 인해 페이지가 삭제된다는 '주의'가 더 크기 때문에 상속제도를 따른다면 빨강처럼 빨강색으로 쉽게 주황색이 될 수 있다.스피디드는 사용자에게 이 페이지가 언제든지 삭제될 수 있다는 경고를 할 필요가 있다고 제안한다.둘 다 임박한 가운데 분명히 차이가 있다.

그러므로 모든 "히르마제"는 아마도 우리가 결정해야 할 거의 모든 것이 될 수 있다. - jc37 22:51, 2008년 11월 22일 (UTC)[응답]

텍스트의 벽을 처리하는 데 도움이 되는 임의 섹션 구분:)

잠깐만, 내가 전에는 제대로 이해하지 못했던 것을 주워들은 것 같아.mbox 표준화에 앞서 jc를 말하는 것인가?{{warning}}그리고{{caution}}메타템플릿이 있었나?즉, 주로 다른 템플릿을 만드는 데 사용되었는가?그리고 그 사후 표준화, 그 시스템은 폐지되었고 이전에 경고와 주의를 사용했던 모든 템플릿은 사용되도록 편집되었다.{{mbox}}또는{{ombox}}직접?해피멜론 19:25, 2008년 11월 22일 (UTC)[응답]

예, 예, 예! : )

및 템플릿:알림(이전에는 "파란색"이었던)도 그랬다.

비록 그것들은 단지 두 개의 mbox 구현에 사용되지는 않았다.대화 페이지, 카테고리 페이지, 템플릿 페이지, 위키백과 공간 페이지 등그리고 나는 "전부"에 대해 확신할 수 없다.나는 다양한 mbox 구현 이후에도 이것들을 그들의 metatemplate로 사용하는 템플릿들이 여전히 존재한다고 생각한다.

(그리고 이행을 통해 둘 다 임의로 "주황색 수준"으로 설정되었다.) - jc37 22:51, 2008년 11월 22일 (UTC)[응답]

아, 그렇다면 {{주의}}과{경고}} 템플릿이 "비축"되었다는 것이 Jc37의 뜻이었군.내가 아는 한 그 템플릿들은 더 이상 사용되지 않는다.그것들은 여전히 사용 중이고, 여전히 유용하며, 그들의 문서에는 어떠한 부정도 나와 있지 않다.하지만, 그것들은 보통 더 이상 메타 템플릿으로 사용되지 않는다.

Jc37: "도움이 행복하다"에 대해: 맞아, 우리 위키피디아 사람들은 보통 기꺼이 돕지만, 왜 우리는 우리가 싫어하고 원하지 않는 것을 기꺼이 도와야 할까?

Jc37: 나는 네가 우리의 토론에서 노란색에 대해 언급한 적이 없다는 것을 방금 깨달았다.(jc37과 나는 이러한 문제를 여러 메시지 상자의 토크 페이지에서 지금 꽤 오랫동안 논의해 오고 있다.)템플릿 토크에서 다음 내용을 살펴보십시오.Mfd 귀하는 삭제 통지에 녹색을 사용하고자 하는 사용자 중 한 명 입니다.그리고 위의 당신의 댓글에서 {{주의}} 메시지 상자가 오렌지색이라고 생각하는 것을 이제 알겠다.하지만 이것 좀 봐, 지금은 노란색이야. 그리고 얼마 전부터 그랬어.전에는 평범한 회색이었지만, 오렌지색 아이콘과 함께였으므로, 어떤 의미에서는 그것이 "오렌지"였다고 말할 수 있다.그래서 Jc37, 나는 네가 생각하고 있는 전체 색 척도를 공개해야 한다고 생각해.다음과 같은 색상의 스케일을 원하는 것 같으므로:

• 파란색/회색/중립색 = 현재와 같이, 그것은 일반 비긴급 통지에 대한 것이다, "유형=통보".
• 너는 노란색을 전혀 사용하고 싶지 않아.
• 주황색 = 사소한 경고의 경우 "유형=주의"라고 부르십시오.
• 빨간색 = 주요 경고 및 가장 긴급하지 않은 삭제 통지에 대해 "type= warning"이라고 부르십시오.
• 녹색 = 대부분의 삭제 통지용.
• 레드+핑크=지금과 같이 신속한 삭제통지를 위해.

Jc37: 내가 너의 색 척도를 정확히 추측하고 있는 거니?

그리고 나는 그 색깔의 저울에 동의하지 않는다.나는 너의 저울이 매우 이상하다고 생각한다.특히 삭제에 그린을 사용하는 경우?녹색은 경고 색상이 아니라, 녹색은 보통 어떤 것이 좋다는 것을 의미하는 색상이다.비교를 위해, 여기 우리 대부분이 지금까지 동의한 색상 척도가 있다.

• 파란색/회색/중립 = 일반 비긴급 공지의 경우 "유형=통지"
• 노란색 = 사소한 경고의 경우 "유형=유형"으로, 아마도 "유형=주의"라는 추가 명칭을 붙일 수 있을 것 같다.
• 주황색 = 주요 경고의 경우 "유형=내용"으로, "유형=경고"라는 추가 명칭을 붙일 수 있을 것 같다.
• 빨간색 = 삭제 통지에 대해서는 "type=delete"를 입력하십시오.
• 레드+핑크=빠른 삭제 통지에 대해서는 "타입=스피디"라고 한다.

그리고 네, 2007년 여름 전에 사용했던 전통적인 경고 색상과 약간 어긋난다고 말할 수 있다.그 이후로 우리는 종종 작은 경고에는 오렌지를, 주요 경고에는 빨간색을 사용했다.하지만 사실, 그때는 대부분 혼란스러웠고 각 편집자들에게는 어떤 색이 사용되었는지가 달려있었다.그래서 우리가 메시지 박스를 표준화할 때 우리는 더 나은 색 척도를 선택한다.그리고 우리는 이제 메인 스페이스에서는 약 1.5년, 다른 네임스페이스에서는 약 0.5년 동안 이 색척도를 사용해 왔다.나는 덜 논리적인 색 척도로 "반복"할 이유가 없다고 본다.

이시하라 컬러 테스트 플레이트의 예.숫자 "74"는 정상적인 색 시야를 가진 시청자들이 분명하게 볼 수 있어야 한다.이분법이나 변칙적인 삼분법을 가진 시청자들은 그것을 "21"로 읽을 수도 있고 무채색증을 가진 시청자들은 숫자를 보지 못할 수도 있다.

Jc37:이걸 오해하지 마, 무례하게 굴려는 건 아니야.나는 단지 그것이 많은 것을 설명해 줄 것이기 때문에 확실히 하고 싶다: 나는 당신이 약간의 적녹색맹을 가지고 있을지도 모른다고 생각하기 시작했다.그 이후로, 노란색과 주황색 메시지 상자는 당신에게 똑같이 보일 것이다.그리고 대부분의 삭제 통지에 대해 제안하는 녹색은 다른 삭제 상자에 사용되는 빨간색과 다른 뉘앙스일 뿐이다.녹색은 뉘앙스가 아니라는 완전한 색채 비전을 가진 우리 나머지에게는, 그 대신 그것은 붉은 색의 반대 색이며 따라서 반대 의미를 갖는다.약간의 적녹색 시력 결핍은 남성들 사이에서 꽤 흔하다.그리고 완전한 적녹색 맹목성을 의미하는 것이 아니라 단지 약간의 결핍을 의미하는 것이다.

니힐트레스:위에서 설명했듯이 어떤 mbox에서도 '유형=스타일'과 '유형=내용'을 제거해서는 안 된다고 생각한다.대신에 나는 모든 mbox들이 그러한 스타일의 두 가지 이름, 즉 노란색은 "유형 = 스타일/주의", 주황색은 "유형 = 내용/경고"를 이해하도록 해야 한다고 생각한다.그것은 ambox/tmbox/imbox/cmbox/ombox 코드에 추가하는 것이 꽤 간단하다.그리고 그것은 {{mbox}}} 네임스페이스가 여전히 모든 네임스페이스에 대해 작동한다는 것을 의미한다.그리고 그것은 우리가 이미 그 메타템플릿으로 만들어진 어떤 템플릿도 바꿀 필요가 없다는 것을 의미한다.즉, 우리는 거꾸로 양립할 수 있다.

그렇다면 그 네임스페이스에서 보다 명확하기 때문에 메인(기사) 공간에 대한 구식 명명법, 그리고 다른 네임스페이스에 대한 새로운 명칭의 사용을 촉진해야 하는지에 대해 생각해 보아야 한다.또는 모든 네임스페이스에서 새 이름을 승격해야 하는지 여부.

그리고 물론, 일부 스타일에 대해 두 개의 이름을 갖는 것은 사용자들에게 혼란을 줄 것이고, 그것은 문서와 코드의 추가적인 유지 보수 작업을 의미하며, CSS 클래스의 명칭을 상당히 혼란스럽게 만든다.그리고 시간이 지나면서 그것은 꽤 많은 추가 작업을 할 것이다.그래서 문제는 추가 이름을 추가하면 지금보다 더 많은 혼란과 효과가 있을지 여부다. (이제 대신 사용자들에게 왜 우리가 약간 이상한 이름을 가지고 있는지 설명하는데 추가 작업이 필요하다.)

--David Göthberg (대화) 2008년 11월 23일 (UTC) 00:49[응답]

나는 노란색(또는 다른 색깔)에 대해 이야기하지 않았다. 왜냐하면 나는 그것들에 대해 이야기하지 않았기 때문이다.나는 현재 주의와 경고의 주황색과 적색에 집중하고 있다(et al.

아니, MfD 템플릿은 초록색을 좋아하지 않아적어도 그 토론에서 나는 모든 삭제 템플릿이 "월-오-정리"에서 더 돋보여야 한다는 것을 선호했다. (나는 cmbox의 "모양"을 선택해야만 한다면 더 선호한다.)특히 PROD가 XfD 템플릿의 편집자와 그 반대로 혼동되고 있다는 점에서 문제가 있다.그리고 PROD는 제거될 수 있고 XfD 템플릿은 논의 중에 남아 있어야 하는 공지 사항이기 때문에, 이는 문제가 될 수 있다.(주요 토론/제안으로부터 다소 접선된 내용임을 언급함)

당신과 내가 (적어도 여기서) 동의하지 않는 요점은 (지금까지) '주의'가 '노란색'이 아니고 '경고'가 '주황색'이 되어서는 안 된다는 점이라고 생각한다.그것들은 각각 주황색과 빨간색이어야 한다.그것은 역사적으로 그들이 무엇이었는지, 그리고 그것은 "심각함의 히스테리"를 직접적으로 반영한다.

그리고 아니, 나는 색맹은 아니지만, 내 모니터는 확실히 더 좋은 (더 나쁜) 날들을 가지고 있다.

색상 척도가 어떻게 되어야 하는지에 대한 나의 선호에 대해서는, 어떤 변화도 상당한 양의 작업을 필요로 할 것이라는 것이 확립된 것 같기 때문에, 본질적으로, 필요한 만큼 적은 변화를 찬성한다.

"스타일"과 "내용"은 어떤 색도 될 수 있으며, 그것은 중요하지 않다.특히 "스타일"은 스타일 가이드를 위반한다고 해서 페이지가 삭제되는 것은 아니다.한편, 컨텐츠에 관한 우려는 한 페이지를 토론 후보(삭제될 가능성이 있음)로 이끌 수도 있다.그런 만큼 황색일 수도 있고, 아무것도 해치지 않을 것이다.(노란색/주황색/빨간색이 '심각한 히스테리'인 것 같기 때문에)하지만 그것이 노란색이든 오렌지색이든 정말 문제가 되지 않을 것이다.(솔직히, 컨텐츠 관련 문제의 심각도에 따라 다른 컨텐츠 관련 우려는 노란색 또는 주황색일 수 있다.)이 모든 것은, 이것을 공식화하는 것이 조금 이상의 작업인 것처럼 들리기 때문에, 나는 (물론, 오렌지 수준의 '주의'가 만들어질 수 있다고 표현하면) 내용을 그대로 두는 것에 반대하지 않을 것이다.그러나 "더 쉽게" 또는 "더 선명하게" 만든다면, 우리는 녹색, 내용 노란색, 주의 오렌지색, 경고 빨간색으로 스타일을 만들 수 있다. (삭제하고, 또한 빨갛게 빠르게, 매우 특정한 유형의 "경고"인 것처럼)

그렇지 않으면 우리는 "내용"을 "특정" 유형의 "주의"로 간주할 수 있을 뿐이다.그래서 오렌지 레벨에서 공동 출시를 하는 겁니다.그리고 그것은 우리가 "스타일"을 노란색으로 남겨두면 된다는 것을 의미할 것이다.

그래서 위에 말한 것으로 되돌아간다: a.) "삭제"-레벨에서 아이콘을 제거한다. b.)주황색 수준 "주의" c.에 대해 해당 아이콘(해당되는 경우 해당 아이콘)을 사용하여 빨간색 수준 "경고"를 만드십시오.

만약 제정된다면, 다음과 같은 결과를 초래할 것이다.

• 중립 통보용 "쿨" 색상(파란색, 회색, 중성)
• 주의/경고용 "따뜻한" 색상(노란색, 특히 주황색과 빨간색)"내용"은 "경고"의 보다 구체적인 유형인 "경고"와 "삭제"에 불과하다.노란색은 "중립"은 아니지만 "위험 구역"도 아닌 통지에 대한 것이다.예를 들어, 스타일 정리와 프리젠테이션과 관련된 모든 것.

이 프레임워크는 내가 처음에 주의하도록 내용 이름을 바꾸고 경고로 삭제하라고 제안했을 때 대략적으로 시각화했던 것이지만, 그것은 분명히 문제가 있다. 단지 삭제와 관련된 템플릿만을 특별히 언급하기 위해 "삭제"를 원했기 때문이다.

이것이 더 명확하게 하는 것이 좋을까? - jc37 06:59, 2008년 11월 23일 (UTC)[응답하라]

Jc37: 그래, 네가 생각하고 있는 색 척도를 정확히 밝혀줘서 고마워.그리고 그것은 너와 내가 색깔의 크기, 그것의 용법, 그리고 그것의 이름에 대해 의견이 많이 다르다는 것을 보여준다.그래서 이제 너와 나는 가만히 앉아서 다른 사람들이 어떻게 생각하는지 들어봐야 할 것 같아.

--David Göthberg (대화) 2008년 11월 23일 08:00 (UTC)[응답]

내 생각에 당신 주장의 약점은 "그들은 각각 주황색과 빨강색이 되어야 한다"는 문구인 것 같아.왜 그들은 그렇게 되어야 하는가?단지 '그들은 항상 그래왔다'는 이유 때문일까?그러한 추론은 우리가 녹색 삭제 템플릿과 수많은 쓸모없는 기기들을 가지고 있는 이유인데, 그것은 단지 화장품의 변화를 되돌리는 역할을 한다.우리는 과거에 얽매이지 않는다; 우리는 과거의 것들이 현재에 유용하게 남아 있으면 계속해서 사용하고, 미래에 문제를 일으키지 않을 것이다.이 경우 변화가 좋은 데는 그럴 만한 이유가 있다.당신은 3단계 계층구조를 형성하는 오래된 템플릿 시스템을 주목한다.우리는 이제 3단계 계층 구조를 형성하는 일련의 스타일을 가지고 있는데, 4단계로 확장하기를 원하십니까?mbox 시스템을 변경하려는 방법은 더 이상 사용할 것이 아니라 내부적으로 이전 템플릿과의 호환성이 떨어지게 한다.고대의 색을 유지하기 위해서?주황색과 빨간색의 매력은 무엇인가?다른 메시지에 대해 "삭제" 유형을 사용하는 것이 나쁜^TM 생각이라는 것을 받아들인 후, "삭제..."로부터 모든 것을 말하며 새로운 빨간색 경고 유형을 위한 "공간 만들기"를 위해 계층 구조에서 인위적으로 제거하려고 시도한다. 다른 종류의 공지야... "삭제는 경고형 통지"라고 "삭제하는 것이 더 주의"라고 말하는 것은 정말로 상속자가 아니다.어느 쪽인가?삭제는 삭제하는 것이다. 삭제하는 것은 당신이 말한 모든 것을 하나로 만드는 것이다. 그래서 삭제하는 것은 그것의 위치에서 그것을 제거하는 것이 불가능하다는 것이다. 그것은 의심할 여지없이 우리가 대부분의 페이지에 대해 가지고 있는 가장 중요한 메시지다.그것은 정말로 그것 자체의 전체 클래스에 속해있다. 그래서 그것은 빨간 스타일을 충분히 받을만하다.거의 모든 다른 메시지들은 삭제 메시지와 비교했을 때 창백하기 때문에, 그들이 다소 덜 강력한 색상을 사용하는 것이 전적으로 적절하다.삭제 경고만큼 중요한 템플리트화된 메시지의 예를 들어줄 수 있니?나는 그러한 재사용 가능한 메시지가 존재한다고 믿지 않는다; 단지 토크와 같은 맞춤형 경고만 있을 뿐이다.모하메드우리는 "왜 빨간 경고 타입이 필요한가?"라고 물어봐야 한다.그것은 어떤 효용성을 가질 것인가?그리고 "옛날에는 한 가지가 있었으므로 한 개가 필요하다"는 대답은 무답인데, 그것은 낡은 적색 경고 메시지의 '필요성'이 어떤 물음에도 들어 있지 않았다는 가정을 하기 때문이다.만약{{warning}}만약 첫날부터 주황색 테두리와 이미지를 사용했다면, 세계는 끝났을까?나는 그것이 매우 의심스럽다.반대의 증거가 없다면, 이 논의의 대부분은 단지 변화에 관한 것 같다; 그리고 나는 변화가 어떤 식으로든 나쁘다는 어떤 실질적인 증거도 보지 못했다.

하지만 내가 '나쁜 일'이라고 언급할 한 가지는, 사용한 모든 템플릿을 변환하는 것이었습니다.{{caution}},{{warning}}, 등등 독립하기 위해서.그럴 필요가 없었고, 전혀 불필요했고, 대체로 이 문제의 근원이었던 것 같다.만약 우리가 세 개의 오래된 템플릿에 기초하고 사용되었던 템플릿에 대한 데이터를 가지고 있다면, 우리는 이 상황을 평가하기에 훨씬 더 나은 위치에 있을 것이다.해피멜론 20:40, 2008년 11월 23일 (UTC)[응답]

너의 논평은 나를 다소 당황하게 한다.지금 내 말이 분명히 이해되지 않고 있는 것이 분명하다.

첫째로, 분명히 내 실수의 일부는 상속인의 "감각"이 전달될 수 있는 여러 가지 방법을 제시한 것이었다.그것은 분명히 위에서 당신의 혼란을 야기시켰고, 내 생각의 인용구들이 맥락에서 벗어난 것을 가리킨다.내 요점은 본질적으로, 단지 우리가 색깔의 계승권을 가졌다고 가정할 수 있기 때문에, 어떤 주제가 어떤 색깔에 할당되어야 하는지 반드시 추측할 필요는 없다는 것이었다.즉, A가 B보다 상속권에 대해 "높은" 가치가 있다고 판단되면 A는 오렌지색, B 노란색, A 빨간색, B 오렌지색, 또는 자홍색, B 청록색, 또는 A 금, B 은색, 또는 우리가 사용하는 모든 상속 시스템에 해당될 수 있다.나는 본질적으로 A가 B보다 높은 이유에 대해 생각해보고, A가 B보다 "높음"이어야 하는지(즉, 개념들 사이에 정말로 "희극"이 존재한다면)에 대한 고민에 집중하기 보다는, A가 왜 B보다 "높음"이어야 하는지에 대한 판단을 내릴 것을 제안하고 있었다.

"삭제"는 우리가 시행하는 어떤 계승권의 꼭대기에 있어야 하는가?물론이지. 다른 모든 공지사항과 다른건가?네!

내가 말하는 것은 몇 가지 이유로 '빨간 레벨'을 넘어서는 '삭제' 템플릿이 한 단계 더 높은 단계여야 하며, 아니면 적어도 벽-오-청소/공지판의 나머지 계승권과는 '다름'이 되어야 한다는 것이다.보호는 "다양한" 것으로 간주되며, 나는 대부분의 사람들이 그것이 한 페이지에 스타일 이슈가 있는지 아닌지에 대해 오히려 더 중요한 상황이라고 주장할 것이라고 생각한다.(그리고 사실 나는 그들이 이행에 관한 논의 중에 그렇게 말했다고 믿는다.)

그리고 누군가가 "합의를 과장한다"는 주장을 내놓기 전에, 나는 그들이 돌아가서 적어도 위키백과 대화의 처음 몇 개의 기록들을 읽어보기를 제안한다.기사 메시지 상자.특히 3번 하면.이것은 소수의 편집자 그룹이었는데, 그들은 그 후 우려를 표명할 수 있는 다른 누구와도 반대하여 연합하게 되었다.

이 토론의 차이점은 솔직히 당신이 듣고 있다고 느낀다는 겁니다. 하지만 아마도 이해하지는 못 할 겁니다. 왜냐하면 나는 내가 전달하지 못한 경험에 근거하고 있기 때문이거나, 아니면 전반적으로 충분히 전달하지 못했기 때문이지요.

그런 것을 염두에 두고 나는 돌아가서 기록물을 새로 고침으로 다시 읽었다.(일단 흐릿한 기억을 바탕으로 과거를 오인하고 싶지 않다)

특히 처음 3개의 기록물은, 내 생각에, 그들을 위해 곁에 있지 않은 모든 사람들에게 다소 놀라운 것이다.

위키백과 대화:기사 메시지 상자/아카이브 2#색상 부호화 - 색상에 대한 초기 제안이것은 분명히 상속계통이다.이제 얼마나 많은 사람들이 그 실에서 그것을 "승인"하기 위해 의견을 냈는지 주목하라...우리가 계속 듣고 있는 "과잉 컨센서스"가 아니다.그 후 일어난 일은 바이올렛리가(그리고 다른 커플)가 그들의 체제에 반대하는 사람들을 꽤 많이 폭행했다는 것이다.그들이 그러한 철도를 "탈피"할 수 있도록 도운 것은 사용자:티레니우스도 반대편에서 (그 이상은 아니더라도) 그만큼 문제가 있다는 것이었다.그래서 그의 행동들이 추정된 추악한 행동에 근거하여 "정당화"된 것으로 여겨졌다. (내가 어쨌든 잘못된 문자에 빠져 있다고 느낀다면, 다음 몇 개의 기록 보관소에 대해 자유롭게 읽어주십시오, 나는 그 진술이 정당하게 뒷받침된다고 믿는다.사용자:스플래쉬는 그런 것들을 어느 순간 분해했다.내 생각에, 이러한 "논의"에서, 우리의 동료 위키백과 사람들은 WP에 대해 최선을 다하지 않는 것 같다.AGF 또는 심지어 WP:소유.)

자, 위에서 언급했듯이 오믈렛을 만들기 위해서는 달걀이 깨져야 할지도 모르지만, (비유를 섞기 위해서는) 이것은 목욕물과 함께 아기가 버려진 경우였다고 나는 강하게 생각한다.

이제 그 모든 것이, 위의 제 초기 제안이 실제로 그 초기 제안서를 따른다는 것이 좀 아이러니하다는 것을 알게 되었다.색상 레벨은 각각 특정 "유형"의 그룹인 일반 이름을 가져야 한다.나중에 일어난 일은, 이름들에 관한 한, 참석자들이 그들 자신들 사이에서 어떤 "심각한 수준"에서의 사용의 "대부분"이 (예를 들어) "내용 관련"이라고 결정했기 때문에, 그 수준을 "내용"이라고 불러야 한다는 것이었다.

그게 내 주된 불만/의심이다.

위에서 언급했듯이, ambox는 대부분 기사 네임스페이스에 집중되어 있었고, 더 나아가, 이러한 임의적인 선택을 하는 사람들은 분명히 얼마나 많은 템플릿이 영향을 받을 것인지, 그리고 어떤 방식으로 영향을 받을 것인지에 대해 전혀 알지 못한다는 것이 매우 명백했다.(이것은 여러 편집자가 여러 번 제기한 것이다.)

모박스 같은 토네이도가 시행돼야 한다는 공감대가 압도적으로 높았는가?응. 대부분의 편집자들은 상속제도에 대한 아이디어를 좋아했니?네. (특히 이미 꽤 많은 q 템플릿에서 어느 정도 준비가 되어 있었기 때문에)이것을 실행하기 위해 "선거운동"한 모든 사람들이 관련된 모든 다양한 뉘앙스를 정말로 알고 있었다고 믿는 사람이 있는가?게다가, 대부분의 사람들은 프리젠테이션을 만드는 데 관여하는 사람들이 "가장 좋은" 것이 무엇이든 생각해 냈다고 믿지 않을까?

그렇다. 사실, 그것은 실행과 동시에 빠른 삭제 템플릿에 대한 항의가 있었다는 사실에서 비롯된다.분명히 토론에 참가한 사람들은 그들이 야기하고 있는 영향이나 문제를 깨닫지 못했다.

나는 우리가 빨간색과 주황색 레벨을 가져야 한다는 것에 동의한다.그러나 그들은 다른 이름을 가져야 한다. 왜냐하면 그것들은 단지 내용과 삭제보다 훨씬 더 광범위하기 때문이다.그리고 이것은 해피멜론이 언급했듯이, "삭제"는 다양한 사용상의 이유로 삭제 템플릿으로만 제한되어야 한다는 점에서 실제로 단순화된다.만약 그렇게 한다면, 우리는 여전히 '적색 수준'의 템플릿 세트를 위한 빈칸을 남겨둔다.그리고 역사적으로 "최상위/적색 템플릿과 오렌지 수준 템플릿을 모두 합치는 것은 정말 나쁜 생각이다.그리고 더 나쁜 것은, 지적했듯이, 이것은 이미 어느 정도 행해진 것이다.그리고 사용자들이 삭제하지 않는 "빨간색 수준"이 필요하다는 문제도 있다.여기서 해결해야 할 분명한 필요성이 있다.그리고 고정할 수 있다고 생각하지만, 그렇게 하기 위해서는 우리는 약간의 소유권을 "놓아야 한다"고 할 필요가 있을 것이고, 템플릿이 편집자의 바람으로 쓰이도록 할 필요가 있을 것이다, 반드시 우리가 그들에게 그것을 사용하도록 강요하고 싶은 것은 아니다. (참고 나는 이 토론에서 누구에 대한 경우를 말하는 것은 아니지만, 특히 당신이 이 토론에 빠지기 쉬운 함정이라는 것에 동의할 수도 있다고 생각한다.이 구현에 많은 노력을 기울였다.)

그리고 "그들은 특정한 용도에 맞게 스타일을 맞춤화할 수 있다"고 제안하는 것은, 표준이 있는 목적을 좌절시킨다.이 '표준'이 먹히려면 니즈가 커지고 바뀔 가능성이 있는 만큼 적응할 필요가 있다.우리는 과거와 현재, 그리고 잠재적으로 미래 둘 다 포용적이어야 한다.앰박스 논의 역시 "과거"라는 점에 유의한다.그러므로 단순히 "과거"라고 해서 "과거"를 해체하는 것은 오히려 적폐다.

그래서 이 제안에서, 나는 우리가 이러한 메시지 박스 템플릿을 "조직화"하는 색상에 기초한 반히어적 시스템을 사용하고 있다는 가정을 하고 있다.따라서 HM이 위에서 이해하지 못한 "주황색-적색" 상속권.

그래서 제 제안은 이러한 "성장"이 최소한의 변화로 일반적인 관행(우리 지침이 반영해야 하는 것)을 포함하도록 돕는 것이었고, 따라서 바라건대, 최소한의 작업/부여를 하는 것이었습니다.

또한 "스타일" 코멘트(지금은 다소 부차적인 주제임)를 명확히 하기 위해 스타일 박스가 "심각하지 않다"를 참조하십시오.또한 "내용"이라는 단어를 사용하는 것은 기술적으로 내용 표시의 "스타일"이 페이지 "내용"이기 때문에 문제가 된다는 점에 유의한다.

어쨌든, 이것이 길어졌으므로, 나는 그 제안들을 다시 설명할 것이다. 아마도 그들은 더 이치에 맞을 것이다. (어쨌든, 나는 희망한다.

긴 형식:

(1) 삭제 템플릿은 상속권에 있는 대부분의 다른 통지와는 달리 페이지 전체("내용" 또는 "스타일" 또는 페이지의 표시에 대한 수정 제안)에 관한 토론을 말한다.그러므로 그것들이 "가장 중요한" 메시지 상자로 여겨질 수도 있지만, 그것이 그들이 반드시 상속인 정리 시스템에 제한되어야 한다는 것을 의미하지는 않는다.그리고 그들의 존재는 다른 "적색 수준"의 심각성 통지가 있어서는 안 된다는 것을 의미하지도 말아야 한다.어떤 것이든 '삭제'는 상속권 너머에 있다.

게다가 삭제 템플릿은 아이콘을 사용하지 않기 때문에, 특히 해피멜론이 위에 제시한 이유로 삭제 템플릿에만 "삭제"가 사용된다는 생각을 강행하고자 한다면, "스타일"의 일부로서 기본 아이콘조차 가질 필요가 없다.

2. 따라서 현재 삭제 템플릿의 기본값으로 사용되고 있는 삼각형 "!" 아이콘(아마도 음영/틴트 모양)을 (역사적으로 그랬던 것처럼) 주황색 "주의" 스타일의 기본값으로 지정할 수 있다.위키백과의 상위 템플리트 보기:템플릿 메시지/분산 및 템플릿:예를 들어 주의하십시오.

이렇게 함으로써, 우리는 "콘텐츠" 스타일을 단순히 그것을 부정하는 것이 아니라 앰박스에서 사용하기 위해 그대로 둘 수도 있다.또는 "내용"을 다른 색상(예: 노란색)으로 설정할 수도 있다.a.)가 더 쉽고 b.) 다른 곳처럼 유용하지 않을 수 있지만, 기사 띄어쓰기에는 분명히 유용하지만, 나는 어느 쪽이든 강한 의견을 가지고 있지 않다.

3) (새로 제안) 경고 스타일을 만든다.빨간색 수준과 중지 아이콘 사용(역대 사용)이는 또한 "공통 관행"의 반영을 포함하여 위에서 다른 사람들이 제시한 몇 가지 문제를 해결하는 데 유용할 것이다.(Template의 현재 버전 참조:경고, 그리고 나서 이전에 어떤 모습이었는지 보라.)

짧은 형식: "경고"(빨간색)와 "주의"(주황색)의 두 가지 새로운 스타일을 추가하십시오.

나는 이것을 분명히 하고 싶다 : ) - jc37 16:17, 2008년 11월 24일 (UTC)[응답]

이해해, 그리고 네가 시간을 내어 설명해줘서 고마워.용서할 수 없이, 나는 여전히 너에게 실질적으로 동의하지 않아.초기 앰박스 시행 논의가 공정하게 제시될 수 있도록 노력한 당신의 노력에 박수를 보내지만, 나는 사실 그런 것에 대해서는 신경 쓰지 않는다.여러분이 주목하듯이, 그들은 기껏해야 체계화되지 않았고 최악의 경우 학대를 당했으며, 위키백과에 대한 공감대를 형성하는 모델로 간주되어서는 안 된다.나는 이 논의들이 궁극적으로 무관하기 때문에 단 한 번도 "합의"를 언급한 적이 없다.유일하게 관련된 전체적인 요점은 그것들이 현재 엔위키에서 대부분의 페이지를 아우르고 있는 템플릿과 스타일의 매우 성공적인 시스템을 만들어냈다는 것이다.mbox 시스템의 지속적 사용에 대한 '합치'는 위키백과 편집자들이 새로운 메시지와 오래된 메시지를 위해 이를 전파하고 실행하려는 기관으로서의 의지에서 뚜렷이 드러난다.지적한 바와 같이, 그 시스템의 특징과 목표의 대부분은 그러한 초기 제안에서는 전혀 고려되지 않았다. 템플릿 자체와 마찬가지로 시간이 지남에 따라 유기적으로 성장해 왔다.그래서 우리가 현재 위치에 있다는 걸 알게 된 거지이전의 일은 오늘날에도 여전히 관련성이 있는 경우에만 중요하며, 새로운 구현보다 더 우수한 이전 시스템들은 여전히 유용하다.

그래서 현재 이슈에 대해서.내 생각에 우리는 삭제 템플릿이 어떤 이유에서든 그들만의 형태로 남아 있어야 한다는 것에 동의한 것 같다.따라서 우리는 현재 일반 통지에 대해 '사용 가능한' 세 가지 유형을 가지고 있다.나는 위에서 동의했고 "알림" "스타일"과 "내용"은 이러한 유형의 비독점적인 이름이며 앰박스 개발 과정에서 명백한 포기라는 것에 다시 동의할 것이다.내가 말했듯이, 나는 이 이름들을 바꾸는 데 필요한 엄청난 양의 일을 제외하고는 근본적으로 반대하지 않는다.이것은 IMO가 "필요한 만큼 변화가 적은" 해결책이 될 것이다.그러나 빨간색 서식을 가진 일반적 유형이 절대적으로 필수적이며, "여기에서 해결해야 할 분명한 필요성"을 가정하여 계속 논쟁한다.왜 꼭 필요한가?왜 우리는 '빨간색 수준' 템플릿 세트를 위한 빈칸을 남겨두고 있는가?내가 지금까지 본 적색 테두리를 사용한 삭제 통지가 아닌 메시지의 유일한 예는 Talk와 같은 맞춤형 메시지들이다.무함마드 및 템플릿:제거 섹션(위에서 설명한 대로 "삭제" 유형을 잘못 사용했기 때문에 최근에 변경했다. 연결이 보이기는 하지만 XfD 알림은 유효하지 않다.)경고 메시지가 실제로 빨간색 스타일링을 필요로 할 정도로 심각하고 맞춤형 메시지가 아니며 삭제 경고가 아닌 경고 메시지의 예를 제시할 수 있는가?그리고 나는 "이 템플릿이 변화하기 전에 빨간 스타일을 사용했던 것"에 대해 말하는 것이 아니다. '예시' 왜냐하면 그러한 과거로의 후퇴는 무관하기 때문이다.과거에 우리는 3단계의 템플릿 시스템을 가지고 있었는데, 그중에서 가장 심각한 것은 빨간색 스타일을 사용했다.현재, 우리는 3단계로 된 경고 시스템을 가지고 있는데, 그 중 가장 심각한 것은 오렌지 스타일을 사용한다.나는 여전히 파란색/노란색/주황색/주황색이라는 현재의 시스템이 청색/주황색/빨간색이라는 낡은 시스템에 '불순하다'는 것에 대한 증거(그리고 나는 매우 흥미가 있다)를 보지 못한다.

그런 증거도 없이, 그리고 그것을 입히는 스타일과 규모 자체를 분리하라는 당신의 충고를 충분히 받아들여, 나는 당신의 제안이 실제로 현재의 3점 척도를 4점 척도로 확대하는 것이라고 결론을 내리고, 왜 그렇게 하는 것이 필요하다고 여겨지는지 궁금하다.역사적 전례를 고려한다고 해도 이런 연장선상에서 볼 수 있는 것은 없다.한편, 눈에 보이는 겉모양에 근거한 (비슷하게 비슷한 스타일의) '삭제' 유형과의 혼동, 사실 매우 심각하지 않은 메시지와 함께 '매우 심각한 경고' 범주의 불가피한 남용, 그리고 이제 어느 '상자' 메시지에 대한 의견 불일치 가능성이 높아지는 등 여러 가지 불이익들을 볼 수 있다.에 이르다궁극적으로, 이 논의는 매우 단순한 두 가지 스타일 변화인 것 같다: 새로운 mbox 스타일이 오래된 주황색 템플릿을 새로운 노란색 템플릿으로 대체했고, 오래된 빨간색 템플릿은 새로운 주황색 템플릿으로 대체했다는 것이다.다시 말해, 이것은 왜 백과사전 전체에 걸친 일련의 광범위한 재조립을 요구할 정도로 큰 문제인가?해피멜론 20:18, 2008년 11월 24일 (UTC)[응답]

우선, 내가 이렇게 말할게: whw.

이제 네가 이해한 것 같아.

내가 위에서 언급했듯이, 나는 노랑이가 후계자의 일부가 될 것이라는 생각조차 하지 않았다. 왜냐하면 그것은 "위험한 사람, 윌 로빈슨"이라고 여겨져서는 안 되기 때문이다.그래서 내가 "스타일"은 어떤 색도 될 수 있다고 말한 것이다.

나는 실제로 "삭제"가 "다른 것"인 2계층 상속권을 보고 있었다.

내 생각에 당신은 투티어를 황색-오렌지(삭제가 "유일한" 레드 레벨이 될 수 있도록)라고 제안하고 있는 것 같다.

또한, 나는 우리가 "스타일" 통지가 "위험" 통지가 아니라는 것을 확인했다고 생각한다. 그래서, 만약 노란색이 직관적으로 "위험"을 암시하는 색상 중 하나라고 가정한다면, 그리고 노란/오렌지/빨간색이 우리가 찾고 있는 계승권이라고 가정한다면, "스타일"은 "노란색"이 아니라 "다른 것"이어야 한다고 가정한다면, (그리고 아마도)모자는 구현이 "더 쉬울 것"이겠죠, 나도 모르겠다.)

그러나 후자의 실행과 관련된 문제는 사용자 행동/조치 경고인 통지를 분류할 때 발생한다.가장 높은 수준의 "경고"는 직관적으로 "빨간색"으로 보일 수 있다(참조:위키백과:템플릿 메시지/사용자 대화 네임스페이스)

그 말은, 어떤 면에서는, 삭제하기 위해 빨간색을 가졌지만, 다른 면에서는 "경고"에 빨간색을 가졌다는 것이다. (이것은 사물의 현재 "상태"인 것 같다.)즉, 이러한 경고가 다른 XfD 템플릿과 충돌하거나 혼동될 수 있다는 것을 의미한다.

이 모든 것은 "사실상 심각하지 않은 메시지와 함께 '매우 심각한 경고' 범주의 불가피한 남용"에 관한 좋은 논점이 있다.

문제는 우리가 그것을 "오용"으로 봐야 하는가, 아니면 그들이 "템플리트 그 자체처럼, 시간이 지남에 따라 유기적으로 성장하고 있다"는 신호로 보아야 하는가이다.어떤 mbox 스타일을 선택할 것인가에 대한 주관적인 의사결정을 어떻게든 제거하는 것이 관건이라고 생각한다.

어쨌든, 만약 우리가 이것을 (노란색/오렌지색/빨간색의) "위험한" 후계자로 간주한다면, 나는 약하게 지지할 수 있을 것 같다.

• 노란색 = 내용(현재 상태의 페이지 "내용"의 "위험"을 포함하는 통지용).더 좋은 이름이 나올지라도)
• 주황색 = 주의(삭제를 제외한 모든 "경고"에 대해)
• 빨간색 = 삭제(삭제 템플릿의 경우 기본적으로)

그리고 우리는 "스타일"을 위한 새로운 색상(녹색?)을 생각해 낼 수 있다. (그리고 아마도 더 나은 이름)

하지만 나는 다음을 선호한다.

• 노란색 - 스타일
• 주황색 - 내용물
• 빨간색 - 주의

그리고 삭제 템플릿에 대한 새로운 스타일을 제안할 수 있다(대담한 만능 테두리를 사용하고 스택이 불가능하도록 사용하는 것은 좋은 시작일 수 있다).

나는 후자가 더 직관적이고, mbox "스타일"의 주관적이거나 임의적인 배치의 경향이 덜하다고 생각한다.

어떻게 생각해? - jc37 15:37, 2008년 11월 25일 (UTC)[응답]

내 생각에 너는 네 충고를 받아들이지 않는 것 같아.만약 당신이 스타일과 당신이 개인적으로 그들에게 부여할 수 있는 어떤 암시든 제거한다면, 당신은 7가지 가능한 타입의 템플릿이 남게 될 것이다.그 중 4개("보호", "이동", "삭제" 및 "속도")는 '제한적"이며 좁은 경고 그룹에서만 사용할 수 있다.그것은 일반적인 "메시지"에 세 가지 유형을 사용할 수 있게 한다."스타일" 타입의 "위험" 통지서를 사용하는 메시지에서 당신이 옳지만, 두 가지 모두 "내용" 메시지가 아닌 정도까지만 그렇다.종말이 임박했음을 정말로 경고하는 메시지는 "삭제"뿐이다.그러나, 그것과는 별도로, '노란색'과 '오렌지' 메시지는 모두 쉽게 '경고 메시지'로 간주된다. 실제로 우리 모두는 위에서 이 용어를 서로 바꾸어 사용했다.우리는 필연적으로 '주황색' 경고보다 '주황색' 경고가 더 심각한 '주황색' 경고의 존재를 결론짓는데, 두 경고 모두 '파란색' 메시지보다 더 비관적인데, 우리는 보통 단순한 '공지'로 간주된다.그러니까, "경고"가 들어 있는 두 가지 유형 중에서, 나는 아래쪽 것은 자연적으로 노랗고 위쪽은 자연적으로 오렌지색인 것으로 본다.당신은 "스타일"이라는 이름의 함축성을 유지함으로써 이 문제를 혼란스럽게 하고 있다. 나는 우리 모두가 기껏해야 이 이름들이 불행하다는 것에 동의했다고 믿는다.나는 오렌지 타입에 대한 "경고"와 같이 "주의"라는 용어가 사실 더 바람직하다는 결론에 도달하고 있다.이 새로운 이름들로, 우리는 다른 네임스페이스에 잘 어울리는 보다 자연스럽고 일반적인 계층 구조를 가지고 있다.메인 스페이스의 '스타일' 경고가 다른 곳에서 적당한 경고와 다른 스타일을 필요로 할 필요는 없다. 예를 들어보자.{{intricate template}}. 이 템플릿은 분명히 '스타일'과는 아무 관계가 없지만, 더 '내용'이긴 하지만, '모더레이트 경고'이기 때문에 노란색 스타일은 적당하다.이런 노란 스타일을 주의라고 한다면 그 의도는 훨씬 더 분명할 것이다.

"가장 높은 수준의 '경고'는 직관적으로 '빨간색'인 것 같은데... 왜?사용자 네임스페이스의 "삭제"에 가장 가까운 것처럼 보이는, 인디펜드 블록 템플릿조차 빨간색이 아니라 베이지색이라는 것을 나는 알아차렸다.빨간색은 아무리 심한 경우라도 당신이 링크하는 경고에서 두드러진 색상은 아닌 것 같다.

그래서 나는 내가 점점 더 나아가고 있는 입장은 사용적합성 개선과 노력 감소 사이의 최상의 균형은 파란색/노란색/주황색에 대한 "알림"/"주의"/"경고"를 갖는 것이라고 말한다.정밀한 이행내용은 물론 사소한 일이다.해피멜론 20:05, 2008년 11월 25일 (UTC)[응답]

뉴아이디어

나는 위키피디아가 IRC보다 더 나은 채팅 어플리케이션이 필요하다고 생각한다. 왜냐하면 위키피디아는 나를 위해 작동하지 않을 것이기 때문이다. 위키피디아는 당신이 페이스북의 채팅 어플리케이션에 익숙한 사람들을 위해 webiste www.facebook.com과 같은 대화를 나눈 것이 더 효율적일 것이라고 생각한다. 당신은 페이스북의 채팅 어플리케이션에 얼마나 쉬운지를 알고 있고, 말대답하는 대신 4번째가 더 좋을 것이다.f 이런 것이 있었다.시간 내 주셔서 감사합니다DellLaptop (대화) 23:48, 2008년 11월 20일 (UTC)[응답]

AIM 같은 것을 항상 사용할 수 있다.Petero9 (대화) 2008년 11월 21일 00:10 (UTC)[응답]

IRC가 어떻게 당신을 위해 "일"하지 않을 수 있을까?IRC는 개방형 프로토콜이다.무료 IRC 클라이언트는 물론 자바와 자바스크립트 인터넷 기반 클라이언트도 거의 모든 운영 체제에서 사용할 수 있다.Mr.Z-man 05:11, 2008년 11월 21일 (UTC)[응답]

이 생각은 생각만큼 어리석지 않다.미디어-위키에 IM-챗을 구현하는 것은 불가능하지만, 온-위키 통신 방법을 개선할 수 있는 방법은 확실히 행해지고 있다.우선 그들은 나사산 메시지를 개선하는 방법을 찾고 있다.나는 개인적으로 어떤 실시간 의사소통의 통합을 보고 싶다 - 아마도 최근의 변경 로그에 있는 사람의 이름 옆에 있는 작은 상징으로 그들이 현재 온라인 상태임을 나타내고 있다.어쨌든, 기술 추가 요청은 메타에 있는 bugzilla에서 하는 것이 더 나을 것이다.재치 있는 라마 12:43, 2008년 11월 21일 (UTC)[응답]

"current online"을 어떻게 정의하시겠습니까? --Carnildo (talk) 23:07, 2008년 11월 21일 (UTC)[reply]

현재 로그인되어 있는 것으로 정의하겠다. 사용자 이름이 로그인되어 있는 브라우저 창(시간 초과되지 않은 창)이 활성화되어 있다.나는 이것이 어떤 채팅 포럼에서 작은 상징이 있는 것처럼 보일 것이라고 생각한다.예를 들어 맥루머스 포럼 사이트에서는 각 개인이 올린 글의 왼쪽 하단 모서리에 작은 회색 원이 있다.그 사용자가 아직 온라인 상태일 때 그 작은 원은 녹색으로 변한다.예를 들어, 여기.그냥 생각일 뿐이야...재치 있는 라마 07:24 (UTC) 2008년 11월 23일 (화)[응답]

위트 라마의 말처럼 구현될 가능성은 낮지만 2008년 11월 23일 (UTC) 00:59, 2008년 11월 23일 (회신)

특히 mibbit.com에 쉽게 갈 수 있기 때문에."현재 온라인" 기능에 대해서는, 사람들이 사용자:스플라카/사용자 상태, 현재 개발 중Mr.Z-man 19:40, 2008년 11월 25일 (UTC)[응답]

기사의 리드 섹션에는 기본적으로 자체 편집 링크가 있어야 한다.그것을 끄려면 선호를 수정해야 한다.

선호도를 설정하여 어떤 기사의 리드 섹션에 대한 편집 링크를 볼 수 있다는 것을 알게 되어 기뻤지만, 그것을 켜는 법을 배울 때까지 그것을 갖지 않는 것이 귀찮았고, 이 제안서에 그들의 동의를 추가하기 위해 이곳에 오는 것을 포함한 다른 새로운 편집자들이 귀찮다고 생각한다.등록하지 않은 편집자는 기본 설정이 없기 때문에 편집 링크를 볼 수 없다."이 페이지 편집" 링크를 사용하여 리드 섹션을 편집하는 것은 전체 기사를 편집기에 로드할 때 귀찮고 번거롭고 느리다.그것은 또한 실수가 불필요하게 기사의 더 큰 부분을 손상시키는 것을 더 쉽게 만든다.편집자, 특히 새로운 편집자의 일반적인 편의를 위해, 기본 상태를 링크가 나타나지 않는 현재의 기본 상태가 아니라 링크가 나타나는 상태로 만들어 각 섹션에 자체 편집 링크를 가질 수 있도록 하는 인터페이스 철학을 개방 섹션을 포함하도록 확장할 것을 제안한다. -- 또 다른 스틱러(토크) 01:2008년 11월 22일 (UTC) 44, 22 [응답]

이건 다년생...— Werdna • talk 07:40, 2008년 11월 22일 (UTC)[응답]

위키피디아에는 나와 있지 않다.영원한 제안.그것을 거부하는 이유는 무엇인가?대수학자 12:51, 2008년 11월 22일 (UTC)[응답]

몇 개인지는 정확히 말할 수 없지만, "이 페이지 편집" 링크를 모르는 새로운 사용자들이 리드 부분을 어떻게 편집하느냐고 묻는 다양한 도움말 페이지에 수년간 수많은 게시물이 올라왔다.헬프 데스크/NCHD/VPA 단골이라는 나의 인상은 이런 질문을 수백 번 받았다는 것이다.Another Stickler의 제안대로 이것을 디폴트로 활성화하지 못할 이유가 없다고 본다.--Fuhgettaboutit (토크) 14:33, 2008년 11월 22일 (UTC)[응답]

위키피디아에서 몇 가지 정보를 찾았다.위키백과 표지판/2007-08-13/버그 리뷰#섹션 0에 대한 섹션 편집 링크그 선례에 따르면, 그 주제가 논의되었고 링크를 어디에 둘 것인지에 대해 의견이 달랐다.또한, 페이지 내용이 오른쪽으로 치우쳐 문제가 되는 것 같다.자세한 내용은 버그 리포트를 참조하십시오.---Fuhgettaboutit (대화) 14:39, 2008년 11월 22일 (UTC)[응답]

링크 고마워.나는 논평 #6에 동의한다. 페이지 전체에 걸쳐 우파 내용이 문제가 되기 때문에, 그것은 한 섹션의 편집 링크를 부정하는 강력한 주장이 아니다. -- 또 다른 스틱러 (토크) 09:22, 2008년 11월 23일 (UTC)[응답]

나는 그것이 좋은 시행이 될 것이라는 것에 동의한다.선호도는 최근인 것 같다.이전에 임의 섹션의 편집을 클릭한 다음 URL의 끝을 변경하여 "섹션=0"으로 표시했다.이를 통해 리드가 스스로 편집될 수 있다.Ty 13:15, 2008년 11월 23일 (UTC)[응답]

내 선호도를 봤는데 섹션 0을 편집할 수 있는 항목을 찾지 못했어.그게 어디에 있지요?고마워. 더그웰러 (대화) 15:29, 2008년 11월 23일 (UTC)[응답하라]

가젯/사용자 인터페이스 가젯대수학자 15:30, 2008년 11월 23일 (UTC)[응답]

여기서 가장 관련성이 높은 기고자의 푸그제트 관련 발언(14:33, 2008년 11월 22일)은 결정적이다. 기본적으로 가능하게 한다. --필차(토크) 15:53, 2008년 11월 23일 (UTC)[응답]

모든 사용자가 이 기능을 사용할 수 있는 단점을 찾을 수 없다. MediaWiki에서 코드를 옮기는 것만큼 간단하다.미디어위키에 대한 Gadget-edittop.js:공통.js. 및 가젯으로 제거.해피멜론 18:11, 2008년 11월 23일 (UTC)[응답]

어, JS가 해킹했어— Werdna • talk 04:26, 2008년 11월 24일 (UTC)[응답]

맘에 안 들어?트렁크에 가서 고쳐주고 해피멜론 09:38, 2008년 11월 24일 (UTC)[응답]

이곳의 대다수의 응답은 긍정적인 것 같다.그럼 이제 어떻게 되는 겁니까? -- 또 다른 스틱러 (토크) 00:23, 2008년 11월 25일 (UTC)[응답하라]

고대 벌레.레이아웃에 대한 우려는 여전하지 않으세요?피처링된 콘텐츠 스타, 오디오 녹음 표시기 및 좌표 사용.확실히 그 중 하나가 겹치는 것은 아닌가? (아, 그리고 만약 당신이 그것을 사이트 전체에서 가능하게 하고 싶다면 MediaWiki talk에서 합의를 구하라.Common.j.) --MZMcBride (대화) 00:30, 2008년 11월 25일 (UTC)[응답]

MZMcBride 고마워, 나도 MediaWiki talk에서 실타래를 시작했다.링크: [6] -- Another Stickler (토크) 03:30, 2008년 11월 26일 (UTC)[응답]

마을 펌프는 독자층이 넓어지기 때문에 아마 이곳에서도 방영되는 것이 좋을 것이다. --타임시프터 (토크) 04:59, 2008년 11월 25일 (UTC)[응답]

나 역시 기본값이 섹션 0의 [편집] 링크가 되어야 한다고 생각한다.리드 섹션을 편집할 때 연결 속도가 느리거나 컴퓨터가 느려서 로드 및 렌더링 시간이 많이 절약된다.그리고 전체 페이지의 미리보기를 지나 스크롤할 필요가 없기 때문에 편집 창의 코드와 미리보기의 렌더링된 출력을 비교하는 것이 더 쉽다.그리고 피처링한 기사 스타 등 다른 아이템은 우리가 쉽게 옮길 수 있기 때문에 실질적인 문제가 없다.그리고 나는 수년 동안 그러한 [편집] 스크립트를 여러 번 사용했으며 내 브라우저 중 어느 브라우저에서도 오른쪽 부동 인포박스와 같은 페이지 컨텐츠에 대한 간섭을 보지 못했다.그래서 나도 미디어위키의 암호는 다음과 같이 생각한다.가젯-edittop.js는 MediaWiki로 이동해야 한다.Common.js. (그 대신 이를 싫어하는 사람에 대해 편집 링크를 끄기 위한 가젯이 있을 수 있음)

--David Göthberg (대화) 04:41, 2008년 11월 25일 (UTC)[응답]

• 지지하다.나는 이것에 대해 오랫동안 알지 못했다.이 설정을 모든 독서자(등록 여부에 관계없이)의 기본 설정으로 사용하지 않는 것은 너무 많은 시간과 대역폭을 낭비한다.그것에 대해 생각해 보렴.이러한 변화만으로도 서버 부하가 크게 감소하고, 편집 생산성이 크게 향상될 것이다. --타임시프터(토크) 04:55, 2008년 11월 25일 (UTC)[응답]

newb와 anon에 대해 이 작업을 수행하는 데는 한 가지 잠재적인 문제가 있다 - 편집 링크("might"를 강조함)가 기사 상단에 있는 "Edit This Page" 링크와 혼동될 수 있다.이 작업을 수행하기 전에 섹션 편집 텍스트를 "이 섹션 편집"으로 확장하거나, 적어도 "소개 편집"의 줄에 따라 LED를 위한 텍스트를 변경하는 것이 좋을 수 있다.그렇기는 하지만, 나는 이것을 여기와 트렁크에 모두 환영할 것이다- 나는 이 기능이 여기 제공되기 전에 이것을 강제하기 위해 편집 링크에 "섹션=0"을 추가하는 것이 정말 지겨웠지만, 나는 내가 관여하고 있는 다른 모든 위키에서 그것 때문에 훨씬 더 짜증나고 있다.Mr Zaius^talk 2008년 11월 25일 (UTC) 10:00[응답]

나는 이 (마지막으로) 미디어위키 트렁크에 추가되는 것을 지지하지만, 기본적으로 가젯이 켜지는 것에 만족한다(또는 common.js).리드 편집 링크가 오른쪽 편향 콘텐츠를 방해한다는 주장은 최근 해당 영역에서 수행되고 있는 작업에 비추어 볼 때 모호한 점이다. MediaWiki talk에서 논의 내용 참조:Common.js#Topbar 콘텐츠 및 MediaWiki 토크:Common.js#topicon part dux 및 MediaWiki talk에서 가젯 업데이트 요청:Gadget-edittop.js#Topicon을 알고 있는 새로운 버전.—Dinoguy1000 21:59, 2008년 11월 25일 (UTC)[응답]

RFC를 연결하는 날짜: 위키백과 변경에 대한 세 가지 제안:스타일 매뉴얼(날짜 및 숫자)

위키백과의 변경에 대한 제안은 다음과 같이 세 가지가 있다.스타일 매뉴얼(날짜 및 숫자)요약하면 다음과 같다.

• 날짜를 연결하기 위한 현재의 낙제를 삭제하고 날짜를 연결하기 위한 격려로 대체한다.
• 현재 자동 포맷에 대한 낙제를 삭제하고 자동 포맷을 권장하는 것으로 교체하십시오.
• 스타일 매뉴얼 가이드라인을 구현하기 전에 모든 봇/스크립트에 대해 스타일 설명서에서 추가적인 합의가 필요한 추가 요구 사항을 작성한다.

투표는 이미 진행 중이다.자유롭게 투표 내용을 추가하십시오. 위키백과 대화:스타일 매뉴얼(날짜 및 숫자)#RfC: MOSNUM Award Lightmouse (대화) 21:12, 2008년 11월 23일 (UTC)[응답]

위에서 언급한 RFC를 연결한 날짜가 (Tony1)와 단락 회로(Tony1)를 연결하는 선의의 적수에 의한 잘못된 시도라고 불평하는 경우, 이 논의를 참고하십시오.테니스 전문가 (토크) 21:48, 2008년 11월 23일 (UTC)[응답]

정말 그렇다.토니는 데이트를 연계하는 목소리의 적수로서, 이 RFC가 자기 방식대로 토론의 틀을 짜려고 노력하도록 이 RFC를 지원했다(다른 RFC에서 언급된 것처럼 합의된 방식이 아님).—Locke Cole • t • c 00:41, 2008년 11월 25일 (UTC)[응답]

위키피디아 토크에서 코멘트에 대한 새로운 요청이 진행되고 있다.스타일 매뉴얼(날짜 및 숫자)#기사의 적절한 날짜 연계에 관한 날짜 RFC 연결.이것은 오랜 협력 과정의 결과물인 RfC이다.또 다른 Rfc는 중립성 논란으로 인해 관리자에 의해 RFCstyle 명단에서 삭제되었다.코멘트를 하거나 이전 RfC에 대해 코멘트를 한 경우, 논란이 덜한 RfC에 대해 다시 한 번 더 자세히 설명하십시오.--사용자:2008올림픽_chitchat^seemywork 08:09, 2008년 11월 25일(UTC)[응답]

위키백과 신뢰성

위키피디아는 점점 더 많은 사용자들이 위키피디아의 내용에 기여함에 따라 신뢰성이 높아지고 있다(s. "Wisdom_of_the crowd").기사가 더 자주 수정되고 더 많은 사람들이 그것에 대해 작업할수록, 최소한 통계적으로 더 정확한 정보가 된다.따라서, 페이지의 "역사"를 한 번 보면 신뢰도에 대한 좋은 지표가 나온다."이력"을 클릭하는 대신, 나는 모든 페이지 위에 나이, (허용된) 변경 횟수, 그리고 그것을 변경한 사용자 수 등의 지표를 붙이는 것을 제안한다.
그 이상으로, 등급제도는 신뢰성을 향상시킬 수 있다.로그인한 사용자는 기사를 평가할 수 있어야 한다.평균 등급을 표시하거나 각 등급 수준에 대한 투표 수에 대한 통계를 보여주는 간단한 등급 시스템일 수 있다.더 좋은 통계는 "이 기사가 어떻게 사용자들이 내 평가 기사를 비슷하게 평가해 왔는가?"와 같은 정교한 통계일 것이다. --Asolymosi (토크) 12:03, 2008년 11월 24일 (UTC)[응답]

아니, 페이지의 역사를 한 번 보면 그 신뢰도에 대한 힌트만 얻을 수 있다.

당신이 제시한 세 가지 지표는 나쁘지 않을 것이다. 하지만 그것들은 단지 그 기사를 적절히 둘러싼 애매모호함을 더해줄 뿐이다.나는 WP 기사(적어도 여기서 볼 때, 상업적인 스크랩을 통해서가 아니라 여기서 볼 때)가 "구글에서 온 애드"나 다른 곳에서 흔히 볼 수 있는 그런 소음과 같은 것에 부담을 느끼지 않는다는 것이 그렇게 유별난 일이라고 생각하지 않는다.

로그인한 사용자들이 기사의 신뢰도를 평가한 이유가 무엇인지 모르겠다.사람들은 내가 주로 쓴 기사의 신뢰도를 평가하는 좋은 근거가 있을 수도 있고, 매우 불안한 근거가 있을 수도 있고, 전혀 근거가 없을 수도 있다.우리는 모를 것이다.

만약 여러분이 이런 것을 원한다면, 베로피디아도 있는데, 그 시스템은 이치에 맞기 시작한다(혹은 내가 마지막으로 그것에 대해 읽었을 때인 것 같다). -- 후아리(말씀)

아직: 검색 버튼을 누르고 "Firefox가 search.veropedia.com에서 서버를 찾을 수 없음." 아마도 내년.NVO (대화) 2008년 11월 24일 (UTC) 18:13[응답]

이런 식으로 기사를 보증하게 된 후, 새로운 버전의 기사를 읽지 않았기 때문에, 나는 어떤 것이 바뀌자마자 바우처 자격을 철회하고 싶을 것이기 때문에 좋은 생각이 아닌 것 같다.따라서 등급은 특정 오래된 개정판과 가장 논리적으로 관련될 것이다.시티즌디움은 당신이 제안하는 것을 하고 있을지도 모른다 - 어떤 시점에서 기사는 동료들의 리뷰를 받고 그렇게 표시될 수 있다.하지만 한번도 써 본 적이 없어.Tempshill (talk) 2008년 11월 24일 (UTC) 20:17[응답

아솔리모시, 어쩌면 당신이 링크한 기사의 이 부분을 읽지 않았는지도 모른다, " 위키백과에 관한 많은 기사들은 질이 높고 여러 사람에 의해 편집될 수 있지만(따라서 군중들의 집단적 지혜를 이용하면서), 다른 기사들은 하나의 편집자에 의해 유지될 수 있는데, 그들의 윤리와 의견이 의심스러울 수도 있다. 인터넷의 익명 영역에서는 두 기사의 차이를 탐지하는 것이 어려울 수 있지만, 두 기사의 신뢰성과 정확성이 동일하다고 잘못 예상할 수 있다."군중들은 통계적으로 정확할 수 있지만 신뢰할 수 있는 참고자료가 완벽할 것으로 예상된다.위키피디아는 신뢰할 수 있는 참고자료가 아니며 그것의 열린 디자인 때문에 될 수 없다.위키피디아를 권위자로 인용한 학생의 보고서를 받아들이는 교사는 그 인식이 지속되도록 허용함으로써 학생에게 해를 끼치고 있다.위키피디아는 어떤 주제에 대한 개요와 가능한 실제 참조 작업에 대한 몇 가지 조언을 얻을 수 있는 좋은 장소일 수 있다.비판적인 독해와 작문/편집 기술을 연습하기에 확실히 좋은 곳이야. -- 또 다른 스틱러 (토크) 01:05, 2008년 11월 25일 (UTC)[응답]

Asolymosi는 "history"를 클릭할 때 "Revision history statistics"를 클릭할 수 있다.나는 이것이 당신에게 페이지의 첫 번째 편집, 편집 횟수, 그리고 독특한 편집자의 수를 보여주는 아카 도구에 사용되었던 것을 안다."리비전 역사 통계"는 이제 독일어 위키피디아에 듀센트리브가 쓴 도구 서버의 도구를 가리키고 있는 것처럼 보이는데, 이 도구는 페이지를 가장 많이 편집한 사용자를 보여준다.aka의 도구에 대한 링크가 MediaWiki에 추가된 것 같다.지난 8월 말 히스테젠드(Histlegend)가 구글 광고를 표시하는 툴 결과에 대한 AN 스레드로 인해 11월 초 삭제됐다.새로운 편집이 있을 때마다 페이지를 분석하고 그 정보를 제공하는 것이 실현 가능한지 모르겠다.

최근 11월 초의 조사는 등급제(체크/엔딩)와 관련된 질문이 있었기 때문에, 당신은 그 결과를 보기 위해 1월 초까지 기다리는 것이 좋을 것이다.당신은 또한 위키피디아를 보고 싶을지도 모른다:플래그가 표시된 수정사항과 해당 대화 페이지(자신이 대부분 혼란스럽다는 점은 인정하지만). --픽셀페이스(대화) 11:39, 2008년 11월 25일(UTC)[응답]

터치 더 클라우드

내일 TFA가 될 구름 터치!그렇지 않다면 피에르 제로프 도니아]가 하기를 제안한다.J.B. (토크) 14:36, 2008년 11월 24일 (UTC)[응답]

그런 다음 WP로 이동하십시오.오늘의 특집기사/요청사항, 유일한 GA후보자여서 의심스럽지만, 나머지 한 명은 GA를 만나지 못했다-Jac16888 (토크) 14:50, 2008년 11월 24일 (UTC)[응답]

다른 하나는 지금 요건을 충족시킬 것이다. 삐에로 게로프 도니아 기사를 현재 상태로 읽고 나서 어떻게 생각하는지 내게 말해라.나는 개인적으로 그것이 잘 쓰여지고, 소스가 잘 되어 있고, 긴 글이라고 생각한다.잘 발현되어 문법적인 오류가 없다.J.B. (토크) 14:53, 2008년 11월 24일 (UTC)[응답]

넌 듣고 있지 않아.TFA가 되려면 기사는 세 가지를 해야 한다.1) 동위 검토 후 WP로 확인되어야 한다.GA. 2) WP에 가져가야 한다.FA 그리고 FA가 되기 위해서는 컨센서스가 있어야 한다.3) 피처링 기사 디렉터가 승인하고, TFA로 만들어야 한다.위의 두 기사 중 어느 것도 하지 않았으니, 만약 tfa's로 만들고 싶다면, Jac16888 (토크) 15:06, 2008년 11월 24일 (UTC)[응답하라]

첫 번째 단계는 바람직하지만 필요하지 않다.나는 그것을 쳤다.러슬릭 (대화) 2008년 11월 24일 (UTC) 17:14 (응답)

이해한다.이제 내 말 좀 들어봐:피에르 제로프 도니아는 내 눈에 GA급에 적합하다.만약 내가 그것을 다시 기억한다면, 위에서 말한 것을 내가 할 수 있도록 너나 다른 누군가가 그것을 현재의 상태로 넘겨줄 것인가?J.B. (대화) 2008년 11월 24일 15:15 (UTC)[응답]

안 그럴 거야, 난 GA 복습 경험도 없고 뭘 찾아야 할지 모르겠어.만약 기준에 부합한다면 GA의 남자들과 여자들-Jac16888 (토크) 15:26, 2008년 11월 24일 (UTC)[응답하라]

마지막으로 내가 확인해본 것은, (그럴 때, 조금 전이었는데), GA가 되는 것이 FA가 되기 위한 전제조건이 아니라는 것이다.GA와 FA 과정은 매우 느릴 수 있다.나는 왜 사람들이 그들 둘 다 겪어야 하는지 모르겠다.내가 더 많은 내용을 썼을 때, 나는 WP를 하는 것이 더 쉽다는 것을 알았다.FAS 우선, 통과하지 못하더라도 WP를 쉽게 통과할 수 있는 충분한 피드백과 개선사항을 얻을 수 있을 것이다.GAC. Mr.Z-man 17:04, 2008년 11월 24일 (UTC)[응답]

나는 몰랐는데, 주로 어느 과정이든 경험이 거의 없기 때문이다.그러나 GA 평가에 불합격한 기사는 FA 평가를 통과하지 못할 것이라고 가정해도 무방할 것 같다-Jac16888 (토크) 22:49, 2008년 11월 24일 (UTC)[응답]

나는 Pier Gerlofs Donia가 GA에 실패하는 것을 거의 상상할 수 없다: 지금 그것을 보라!하지만, 나는 '구름에 닿다'를 향한 질문이 있을 수 있다는 것을 이해한다.{{subst:사용자:Jouke Bersma/sig} 11:06, 2008년 11월 25일(UTC)