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

로그인을 잊어버린 경우 수정 및 편집 제출

등록한 사용자가 편집 시 로그인을 잊어버리는 경우가 있다.그 결과 등록된 사용자의 IP 주소가 사용자 이름 대신 기록에 표시된다.등록된 사용자가 돌아가서 IP 주소를 사용자 이름으로 변경할 수 있도록 제안한다.이러한 변경으로 인해 변경 당시 사용자가 실수로 표시되었던 IP 주소와 동일한 IP 주소를 보유해야 할 경우 가능한 보안 문제를 피할 수 있다. --Bob K31416 (대화) 17:34, 2008년 7월 17일 (UTC)[응답]

"기본 x 주제 목록"이라는 페이지의 이름을 "x의 주제 개요"로 바꾸자는 제안

이것은 후속 제안이다.초기 제안은 충분한 논의를 얻지 못했다(지지표 3표와 다수의 아이디어가 떠돌았다). WP에서는 다음과 같이 제안되었다.ANI는 새로운 제안서를 게시하고 더 많은 페이지에 발표한다.(다음 날이나 이틀에 걸쳐 공지를 올릴 것이다.)

이 제안은 다음 세트의 이름을 바꾸는 것이다.기본 x 항목 목록에 페이지를 매기다.x의 주제 개요.

이전의 논의는 여기와 여기에 있다.

왜 이름을 바꾸는가?"기본 x 주제 목록"은 "목록"이 모호하기 때문에 어색하다. 왜냐하면 위키피디아는 둘 이상의 목록 형식을 가지고 있고, 제목에는 독자들이 어떤 종류의 목록을 보고 있을 것인지 알 수 없기 때문이다.위키피디아는 알파벳 목록, 정렬되지 않은 목록, "구조화된 목록"을 가지고 있다."주제 개요"는 이러한 페이지의 형식을 훨씬 더 잘 묘사하고 있으며, 따라서 보다 정확한 제목이다."x의 주제 개요"도 현재의 5개 단어 대신 4개의 단어가 있을 정도로 더욱 간결하다.

이 페이지 세트는 전체적으로 인간 지식의 개요가 되도록 설계되었다.위키백과의 목차 시스템으로도 두 배가 된다.각 페이지는 그 주제에 관한 필수적인 주제를 제시하며, 각 페이지는 표준 형식을 공유한다.이 세트는 위키백과에서 개발 중인 더 많은 기본 주제 목록에서 찾을 수 있다.위키프로젝트 세계 각 나라(200개 이상)에 대한 기본 주제 목록.

초기 제안은 페이지의 이름을 x의 개요로 바꾸는 것이었지만, 문장의 개요와 주제 개요의 두 가지 종류의 개요가 있기 때문에 모호하다.이 세트에는 후자의 품종이 포함되어 있다."outline"의 또 다른 모호성은 국가들과 관련이 있다.어떤 사람들에게는 "이탈리아의 아웃라인"이 오래된 하이힐 부츠의 이미지를 떠올렸다.

'주제적 윤곽'이 좋다고 생각하는 사람도 있었지만, '주제적'이 모호하고 그 1차적 의미가 '현제 주제'와 관련이 있다는 지적도 있었고, 우리는 초기 제안 논의에서 '주제적 윤곽'을 생각하지 않았다.

누군가 페이지 이름을 "x 주제 목록"으로 바꾸자고 제안했지만, 그것은 완전히 다른 페이지 집합이다(항목 목록 참조).이러한 항목은 (지수의 범위와 같이) 포괄적인 범위를 가지기 위한 것이며, 각 페이지에는 주어진 주제에 대한 모든 주제가 포함된다.현재 저 세트에는 포맷 표준이 없고, 이 세트에 비해 품질이 상당히 낮다.그리고 많은 주제들이 이미 "x 토픽 리스트"를 가지고 있어서 이 페이지들을 그 세트로 옮기는 것은 어렵거나 불가능하게 만든다.여기서 다루는 페이지 집합은 주제의 본질적인 주제들로 범위가 제한된다."주제의 개요"는 이러한 맥락을 잘 포착한다.이들을 다른 주제 목록으로 통합하면 사실상 이 세트가 해체되고 그 목적이 거부되며, 이 페이지들을 훨씬 더 거친 형태의 목록들 사이에 분산시킬 수 있다.그것은 이 제안의 의도가 아니다.

시간 내 주셔서 감사합니다나는 너의 논평, 제안, 의견, 아이디어를 기대한다.트랜스휴머니스트 06:18, 2008년 7월 4일 (UTC)[응답]

• 지원 - 제안자로서.트랜스휴머니스트 06:18, 2008년 7월 4일 (UTC)[응답]

• 반대 조항은 목록이고 그렇게 불러야 한다. xxx Gnangarra 10:19, 2008년 7월 4일 (UTC)[응답]

• 그것은 사실이야, 그들은 리스트야.그러나 각 페이지를 보면 각 페이지에 여러 개의 목록이 있음을 알 수 있다(각 페이지는 정말로 목록이다).왜냐하면 이것들은 개요, 특정한 종류의 목록이기 때문이다.보다 정확한 제목이 유용하며, 새로운 제목이 이 페이지들의 목적을 더 잘 전달할 수 있을 것이다.그들은 함께 인간 지식의 개요다.그냥 여러 개의 리스트들이 뭉쳐진 것이 아니다.트랜스휴머니스트 20:31, 2008년 7월 4일 (UTC)[응답]

• 그렇다. 그러나 "x의 주제 개요"는 기본 xx 주제 목록으로 메시지가 어디에 있는지 전달하지 않는다. 예: "식물 주제 개요"는 "주요 식물 주제 목록"이 분명한 공장 기사에서 기대할 수 있는 것이다.문제는 나에게 있어 단어 선택에 있어서 기본적인 것이다. 개요는 정보가 어떻게 표시되는지에 대한 식별의 부족과 마찬가지로 모호한 용어들이다.Gnangarra 02:56, 2008년 7월 5일 (UTC)[응답]

• 지원은 두 이름 모두 어색하지만, VA 프로젝트와 관련하여 새 이름이 덜 모호하다.모더니스트 (토크) 10:47, 2008년 7월 4일 (UTC)[응답]

• Modernist에 따르면, 새로운 이름은 덜 모호하고 따라서 선호된다. -- Alexf⁴² 11:35, 2008년 7월 4일 (UTC)[응답]

• 지원 전반적으로 더 나은 이름이다.더 정확하고 매력적이다.헤드폭탄 {τακ – WP 물리학: PotW} 12:14, 2008년 7월 4일 (UTC)[응답]

• '제힐드처럼 X의 주제 개요를 선호한다.

• "x에서 주제의 아웃라인" 또는 "x에서 기본 주제의 아웃라인"을 선호하십시오. - 더 자연스럽고 자기 설명이 필요하며, 헤드온 명사 충돌보다는.제힐드 (대화) 2008년 7월 4일 12시 20분 (UTC)[응답하라]

• 정말이야?:) 아르헨티나의 주제 개요는?요즘 아르헨티나에서 많은 주제가 논의되고 있다고 들었어.;) 트랜스휴머니스트 20:55, 2008년 7월 4일 (UTC)[응답]

• 직접 이주를 반대한다.그러나 우리는 근본적인 것에 대한 "기본 주제"와 제목이 다루는 모든 범위의 사물을 표시하기 위한 "주제목록"이 모두 필요하다.멜콤베 (대화) 2008년 7월 4일 (UTC) 12:36 [응답]

• 누군가가 이미 목록 중 하나를 직접 마이그레이트했다.오페라 주제 목록을 참조하십시오.아래 이 세트를 함께 보관하는 것에 관한 새로운 제안을 했다.트랜스휴머니스트 19:56, 2008년 7월 4일 (UTC)[응답]

• "주제적인 윤곽"은 제힐드가 지적한 대로 추악하고 심지어 야만적이기까지 하며, 이와 같이 합리적인 이름이 아니다.현재 이름은 똑같이 불친절하다.나는 "토픽[al] 개요"와 그낭가라의 제안보다 제알드와 멜컴베의 대안을 선호하지만 "토픽 개요"가 더 나을 것이다.Angus McLellan (Talk) 13:48, 2008년 7월 4일 (UTC)[응답]

• '주제적 개요'는 구글에서 62,300번 올라오는 반면 '주제적 개요'는 39만3,000건의 조회수를 기록하고 있다.후기는 훨씬 더 보편적으로 사용되는 것 같다.트랜스휴머니스트 21:33, 2008년 7월 4일 (UTC)[응답]

• 주제란 '피부에 적용', '현재 관심의 대상', '주제에 따라 또는 배열됨'을 의미한다.그것은 많은 사람들에게 "시사에서의 x의 외줄"을 제안할지도 모른다.트랜스휴머니스트 18:32, 2008년 7월 4일 (UTC)[응답]

• 내가 할 수 있는 말은 내 파서가 "토픽 아웃라인"을 좋아하지 않는다는 것이다.나는 이름 바꾸기에 문제가 없어, 같은 의미의 다른 단어들이 더 잘 어울릴 거야.나는 명사가 다른 명사가 아닌 형용사가 선행되기를 기대한다.형용사 명사는 verbing이 하는 것보다 훨씬 더 많이 그들을 속인다.Angus McLellan (Talk) 22:30, 2008년 7월 4일 (UTC)[응답]

• 제안서를 보고 나도 같은 생각을 했지만, 트랜스휴머니스트의 '주제적 윤곽'에 대한 증거를 살펴본 결과, 이번 사건에서 더 정확한 구절이라고 확신하고 있다.이 논의의 요점은 가장 재미있게 말할 수 있는 구절을 찾는 것이 아니라, 페이지의 의미를 분명하고 간결하게 전달하는 구절을 찾는 것이다.「주제의 윤곽」이 정확히 그 역할을 한다. --Cryptic C62 · Talk 11:16, 2008년 7월 6일 (UTC)[응답]

암호, 주제는 명사, 주제어는 형용사, 이야기의 끝.그 구절에서 첫 번째 단어는 형용사 역할을 하고 있다.해결책이 필요하십니까? 아래 내 의견을 참조하십시오.Pdbailey (대화) 2008년 7월 6일 (UTC) 17:24 [응답]

• 지지하다.이 시리즈의 목차 타입의 성격을 더 잘 전달한다."Basic"은 카테고리처럼 들린다.다른 소개.나는 문구("x의 주제 범위" 또는 "주제 개요" 등)의 일부 변형에는 반대하지 않는다.킹돈 (토크) 2008년 7월 4일 (UTC) 14:06[응답]

• 주요 X 주제의 개요를 선호하여 독자와 편집자 모두에게 개요가 포괄적이지 않으며, 앞으로도 포괄적이지 않을 것임을 명확히 한다.그렇지 않으면 개요의 목적을 깨닫지 못하는 선의의 편집자들이 계속해서 개요에 부단한 주제를 추가하게 될 것이다.물론, 처음에는 진술이 가능하지만, 제목이 페이지를 얼마나 잘 묘사하는지에 있어서 한 단어가 중요한 향상을 이룰 수 있다면, 나는 그것을 따르라고 말한다.ike98 98 (대화) 14:39, 2008년 7월 4일 (UTC)[응답]

• 규모에 대해 "전공"을 해봅시다: 대지진, 주요 산업, 주요 발전, 주요 종교, 주요 결정, 주요 화산, 주요 기술, 주요 강, 주요 오페라, 주요 빅 사이언스, 주요 스포츠, 메이저 야구, 주요 건설, 주요 경기, 주요 예술, 주요 아시아 메이저, 주요 경력, 주요 문학, 주요 공예,전공 장학금, 전공 운동, 전공 관계, 주요 정치, 주요 재정주요 영화 주제들의 개요는 무엇에 관한 것인가?스타워즈 같은 주요 영화?트랜스휴머니스트 22:08, 2008년 7월 4일 (UTC)[응답]

• 안 돼.'list'라는 단어가 모호하다고 하셨는데, 어떤 내용이 담길지 알려주지 않아 'topic'이 더 모호하다고 본다.나는 또한 당신이 사실상 모든 위키프로젝트의 토크 페이지를 스팸메일로 보내서 그것이 캐바싱처럼 보이기 시작하는 것이 싫다.확실히 당신은 AWB를 사용하는 시간을 줄이고 더 많은 의견을 끌어모으는 커뮤니티 포털에 그것을 게시할 수 있었는가?오하나유나이티드^{Talk page} 2008년 7월 4일 (UTC)[응답]

• 도대체 위키프로젝트와 접촉하는 것이 어떻게 나쁜 일인가?많은 사람들이 커뮤니티 포털에서 놀지 않고(예를 들어 나) 어떤 일에 대해 발언권을 가질 기회를 놓쳤을 것이다.위키피디아 주제에 어울리는 사람들은 일반적으로 그러한 개요/목록을 관리하는 사람들인데, 이러한 결정들이 위키피디아에 해가 될 때 그들에게 연락하지 않는 사람들이다.헤드폭탄 {τακ – WP 물리학: PotW} 16:20, 2008년 7월 4일 (UTC)[응답]

• 지난번에는 ANI에서 관련 위키프로젝트들과 연락을 하지 않아 취조받았어.그래서 네가 한다면 저주받을 것이고, 그렇지 않으면 저주받을 것이다.항상 모든 사람들을 기쁘게 할 수는 없다.이들 400여 페이지 모두의 이전 이름 변경에서, 한 페이지의 편집자들은 불평했다.즉, 이름이 바뀐 400쪽 이상의 페이지 중 단 한 장만이 불만을 일으켰다.내 의견으로는 나쁘지 않지만, 그것이 이 제안이 다시 시작되어야 했던 전체 이유다.그게 우리가 지금 여기 있는 이유야!트랜스휴머니스트 19:09, 2008년 7월 4일 (UTC)[응답]

• 원칙적으로 지원하되, Jheald와 ike989898이 제시한 수정사항을 선호한다. --Itub (대화) 16:07, 2008년 7월 4일 (UTC)[응답]

• 반대 - 일관성을 위해 목록인 것처럼 목록으로 불러야 한다.또한, 이것의 이점은 무엇인가?독자들이 현재의 이름으로 인해 혼란스러워하고 있는가?그것이 어떻게든 목록을 더 좋게 만들 수 있을까?가시적인 이익을 볼 수 있을 때까지, 나는 이것을 지지할 수 없다.Mr.Z-man 17:05, 2008년 7월 4일 (UTC)[응답]

• 그들의 목적을 분명히 하는 것이 이득일 것이다.이 페이지 세트는 위키피디아 목차 시스템의 주요 구성요소, 또는 더 정확히 말하면 사이트 맵 시스템의 주요 구성요소다.동시에, 그들은 인간의 지식 그 자체의 구조를 계획하기 위한 노력이다."목록"은 이런 함축적 의미를 전달하지 않는다.트랜스휴머니스트 20:11, 2008년 7월 4일 (UTC)[응답]

• 코멘트 "주제의 개요...단지 틀릴 뿐이다 - "주제의 개요.."가 낫다.던컨힐 (대화) 17:11, 2008년 7월 4일 (UTC)[응답]

• 페르 그낭가라를 반대하십시오.5년 17:43, 2008년 7월 4일 (UTC)[응답]

• 그들은 리스트이기 때문에 반대하며 리스트에 포함되어야 한다.그러나 나는 주요 x 관련 주제 목록과 같은 것을 지지할 것이다.····日本語^{? · Talk to Nihonjoe} 17:50, 2008년 7월 4일 (UTC)[응답]

• 이러한 "목록"들은 하위 주제들의 계층 구조로 되어 있기 때문에 단순한 목록으로 접하지 않는다.계층 구조는 계층화된 하위 제목에 표시되며 포함된 글머리표 목록과 그 들여쓰기에서 더 깊은 수준으로 계속된다.전반적으로, 이 페이지들은 시간이 지남에 따라 더욱 정교해지고 있다.일부 주요 예는 기본 역사 주제 목록, 기본 지리 주제 목록, 기본 알바니아 주제 목록 • 기본 아르헨티나 주제 목록 • 기본 호주 주제 목록 • 기본 캐나다 주제 목록 • 기본 에콰도르 주제 목록 • 기본 프랑스 주제 목록 • 기본 독일 주제 목록 • 목록을 참조하십시오.기본 아이슬란드 주제 목록 • 기본 인도 주제 목록 • 기본 인도네시아 주제 목록 • 기본 이라크 주제 목록 • 기본 아일랜드 주제 목록 • 기본 이탈리아 주제 목록 • 기본 섬 목록 • 기본 이스라엘 주제 목록 • 기본 마카오 주제 목록 • 기본 멕시코 주제 목록 • 목록 기본 러시아 주제 • 기본 대만 주제 목록 • 기본 영국 주제 목록 • 기본 미국 주제 목록"목록"은 더 이상 이 페이지들의 본질을 포착하지 못한다.우리가 말하고 있는 바로는 이런 페이지들이 200페이지가 넘게 더 개발되고 있다. 그리고 그것들은 빠르게 발전하고 있다.그것은 현재 세트에 있는 것보다 더 많은 페이지다."목록"은 더 이상 이 페이지들이 무엇인지, 또는 그것들이 되어가고 있는 것을 전달하지 않는다: 각 주제에 대한 정제된 사이트 지도는 계층적으로 배열되어 있다.트랜스휴머니스트 18:42, 2008년 7월 4일 (UTC)[응답]

• 나는 당신이 목록을 구성하는 것에 대한 당신의 관점이 너무 좁다고 생각한다.대략적인 형태로 정리된다 하더라도, 이것들은 여전히 주제들의 목록일 뿐이다.구조화된 주제 계층 구조는 비록 구조화된 목록일지라도 여전히 목록일 뿐이다.····日本語^{? · Talk to Nihonjoe} 20:25, 2008년 7월 4일 (UTC)[응답]

• 우리 둘 다 동의해.그것들은 단순한 목록이 아니라 특정한 종류의 목록이다.개요는 목록이고, 이 목록들은 개략이다.그러니 그들을 그렇게 부름으로써 제목을 더 정확하게 하는 것은 어떨까?귀와 꼬리가 뾰족한 작은 길들여진 포유류에 대해 말한다면, 그것을 그저 포유류라고 계속 언급하는 것은 특별히 도움이 되지 않는다."너희 포유류 귀엽다"는 말은 어떤 포유류인지도 모르는 것처럼 보이게 한다.다른 사람에게 책의 개요를 건네주고 "여기 그 책이 다루는 기본적인 주제 목록이 있어?"라고 말해줄래?이 페이지들의 현재 제목은 그저 어색할 뿐이고, 일반적인 용법에 맞지 않는 것 같다.트랜스휴머니스트 20:37, 2008년 7월 4일 (UTC)[응답]

• Jheald의 대안 지원: X의 주제 개요(그 때 확인)
  • 영국의 주제 개요를 포함해서?:) 트랜스휴머니스트 21:23, 2008년 7월 4일 (UTC)[응답]
• 또한 카테고리의 페이지 이름을 대부분 변경할 것을 제안한다."X의 항목 색인"에 대한 주제 색인.이러한 명칭은 이 두 가지 유형의 기사 유형의 구조와 의도를 명확히 하고, 일반적인 목록 형식의 기사들과 구별하는 데 도움이 될 것이다. -- Quidity (토크) 18:51, 2008년 7월 4일 (UTC)[응답]
  • 좋은 지적이야.그러면 위키피디아는 색인과 개요를 가지게 될 것이다.잘 어울린다.그러나 그렇게 하려면 또 다른 제안이 필요할 것이고, 여기서 그 논의를 하는 것은 이 페이지 세트의 이름을 바꾸자는 이전 제안에서 그랬던 것처럼 이 토론에 혼란을 줄 것이다.트랜스휴머니스트 18:56, 2008년 7월 4일 (UTC)[응답]
    • 때로는 사물을 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람 한 사람그리고 그 반대의 경우도 마찬가지 입니다. -- 퀴디티 (대화) 18:08, 2008년 7월 6일 (UTC)[응답]
• 반대 - 이 조항들이 "주제의 개요"가 아니라는 분명한 이유 때문에.그것들은 목록이고, 그들을 다른 무엇이라고 부르는 것은 더 많은 혼란을 야기할 뿐이다.가토클라스 (대화) 03:52, 2008년 7월 5일 (UTC)[응답]

• 그것들은 번호를 매기지 않고 계층적으로 구조화된 주제 개요이다.트랜스휴머니스트 08:15, 2008년 7월 5일 (UTC)[응답]

• 반대한다. 이것들은 목록이고 제목들은 그것을 전달할 필요가 있다.주제 개요는 나에게 뭔가 다른 것을 전달한다.2008년 7월 5일 04:14 (UTC)[응답]

• 윤곽선의 번호 매기는 선택 사항이다.트랜스휴머니스트 08:15, 2008년 7월 5일 (UTC)[응답]

• 지원 - 개요는 특별한 종류의 목록이다.나는 또한 (그 주제에 관한 프로젝트가 존재하는) 프로젝트 입증을 지지할 것이다.대부분의 프로젝트는 이미 간단한 주제 개요를 가지고 있으며, 프로젝트 하위 페이지로 이 중 하나에 연결할 수 있다. --Latebird (토크) 17:36, 2008년 7월 5일 (UTC)[응답]

• 지지 위의 반대자들 중 많은 사람들은 윤곽이 무엇인지에 대한 근본적인 오해를 가지고 있는 것 같다; 그들은 "이것들은 윤곽이 아니라 목록"이라고 말한다.그것은 사실적으로 옳지 않으며, 이 표들은 그들이 설명하기 전까지 할인되어야 하는데, 그것은 사실과 일치하지 않는다.학문적으로 "주제의 윤곽"을 보십시오. 1, 2, 3, ect.트랜스휴머니스트(Transhumanist)가 자신의 강점을 부각시키지 않은 것은 실망스러운 일이다. 즉, 학계는 우리가 "기본 주제 목록"이라고 부르는 것을 가지고 있고, 그들은 이를 주제적인 개요라고 부른다.II 23:32, 2008년 7월 5일 (UTC)[응답하라]
  • 이 사람들이 '학계' 출신이 아니기 때문에 사람들이 '아웃라인'이라는 용어에 대한 근본적인 오해를 갖도록 코멘트를 하라. 따라서 이 사람들의 의견은 무시되어야 한다.그낭가라 03:49, 2008년 7월 7일 (UTC)[응답]

• 프러포즈 이전에 제안된 것일 수도 있지만, 어쨌든.「이탈리아 관련 기본 주제」나 「이탈리아 관련 핵심 주제」는 「목록」이 들어 있지 않다."outline"을 가진 어떤 이름과는 달리, 페이지의 내용이 매우 명확하다.(그런데, 「기본」은, 의도된 함축이 아닌, 초등 덜 발달한 것처럼 들리기 때문에, 「기본」보다는 「핵심」을 선호한다.) -- 다쿠(토크) 02:03, 2008년 7월 6일 (UTC)[응답]

• 반대. 절대 반대.중립성^talk 02:49, 2008년 7월 6일 (UTC)[응답]
• "X의 기본 주제 목록"은 귀에 어색하게 들리므로 나는 다른 이름이 더 좋을 것이라고 생각한다.나는 "X의 주제 개요"가 훨씬 더 나은지 확신할 수 없다.나는 "핵심"이 그것을 설명자로 칭찬할 만한 것이 많다고 생각한다.이게 정말 길다는 건 알지만, "X와 관련된 핵심 주제들의 구조화된 목록"?"구조화된" 것은 그것이 임의의 목록이 아니라는 것과, 그것이 개요 형태로 되어 있다는 것, 그리고 "관계된" 것이 내 생각에 "in"보다 더 명확하다고..."X에 대한 핵심 주제의 체계화된 목록"도 효과가 있을 것 같다.++Lar: t/c 03:59, 2008년 7월 6일 (UTC)[응답]
• 이 제안에 반대하십시오. 이는 기본적 감각을 상실하기 때문에, 즉 이 영역을 탐색하려면 여기서부터 시작해야 합니다(구조화된 목록의 목적에 대한 내가 이해함).나도 라르의 제안이 별로 마음에 안 들어, 말이 좀 많아.위의 Taku에게 확장하여 제안:core/basic xx 주제/article의 개요, 예시로는 핵심 오페라 기사의 개요가 있다.프라나맥스 (대화) 04:34, 2008년 7월 6일 (UTC)[응답]
  • "기본"이 수반되는 함축성 때문에 많은 사람들이 "기본"에 반대하는 것 같다.코어가 더 나은 것 같다.나는 "핵심 X 토픽의 아웃라인"에서 벗어날 수 있었다. 나는 이것이 여전히 리스트라고 느끼는 사람들을 달래기 위해 "구조화된 리스트"를 제안했지만, 그들이 단지 리스트가 아니라는 생각을 다루었다.대부분 나는 아이디어를 내던지고 있었고, 내 생각에는 현재와 거의 다른 변화는 개선될 것 같다.++Lar: t/c 12:32, 2008년 7월 6일 (UTC)[응답]
• 지지하다.이것들은 근본적으로 목록과 개요 둘 다지만, 나는 "리스트" 모니커를 잃는 것이 그들의 목적을 분명히 하고, 적절한 조항에서 더 나은 조직을 장려한다고 생각한다.어떤 전치사를 쓰느냐에 매달릴 필요는 없다고 생각하지만, 특정 전치사에 의존하지 않는 이름을 선택하는 것이 좋을지도 모른다.나는 이 글들이 귀중한 것이라고 생각하며, 그들에게 그들 자신의 이름을 지어주는 것이 그것들을 더 잘 보이게 하는 데 도움이 될 수 있을 것이다.이들을 다루는 스타일 섹션 매뉴얼도 개발하면 좋을 것 같다. --다르퉁 토크 04:39, 2008년 7월 6일 (UTC)[응답]
• 기존 형식과 제안된 형식 모두 반대한다.이 페이지는 위키백과 페이지로 연결되는 링크의 구조화된 목록이다.그것들은 책의 색인 같다.단어 목록이 마음에 들지 않으면 색인을 사용하는 것이 좋다.주제가 애매해서 페이지나 기사로 바꾸자고 제안한다.내 제안은 이 'X 기사 색인'이나 'X 관련 페이지 색인'이나 'X 지수'나 'X 지수'나 'X 지수'(영국 역사 지수, 화학 지수 등)의 이름을 바꾸는 것이다.우리가 토픽을 위키백과 기사를 의미하기 위해 사용하는 모든 곳에서 나는 토픽이 바뀐 것을 보고 싶다.주제 목록을 위키백과 색인으로 변경하십시오.Filceolaire (대화) 11:01, 2008년 7월 6일 (UTC)[응답]

• 그것들은 책의 색인 같지 않다.뭐라도 주석을 단 목차 같다. --Itub (대화) 12:04, 2008년 7월 6일 (UTC)[응답하라]

음, 그들은 목차가 아닌 것 같아.나는 책의 색인이 기계에서 생성된 알파벳 리스트인 카테고리에 더 가깝다고 생각한다.그래서 만약 색인이 아니라면, 나는 그것이 X 기사나 X 메이저 기사 또는 아마도 X 기사 리스트가 되어야 한다고 생각한다.AnOutline이라고 하는 것은 주제를 요약하거나 소개해야 한다 - 머리글이나 페이지 목록에 개요를 사용해서는 안 된다.마찬가지로 우리가 의미하는 것이 WP 페이지나 기사일 때는 Topic을 말하지 말아야 한다.Filceolaire (대화) 23:15, 2008년 7월 6일 (UTC)[응답]

• 반대하다. 주제는 명사이고 이 구절에서 형용사로 사용되고 있다. 이메일이나 친구들과 이야기할 때는 괜찮지만 공식적인 글쓰기에는 괜찮지 않다.주제의 형용사 형태는 주제어인데, 제대로 된 문법을 쓰려면 그렇게 써야 한다.당신은 위키피디아가 전통적인 문법 규칙을 사용하는 전통적인 백과사전처럼 당신에게 말하는 친구처럼 들려야 한다고 주장할 수 있지만, 나는 그것이 그 사이트를 우호적인 사이트라기 보다는 아마추어 사이트처럼 보이게 한다고 생각한다." x의 주제 목록"은 위에서 인용한 이유로 다소 서툴지만, 짧고 긴 버전이 유효한 "x와 관련된 기술"의 아웃라인이어야 하며, 페이지 헤더에서 긴 버전을 사용하되 짧은 버전은 링크에서 사용할 수 있음을 제안하고 싶다.이것은 "이탈리아의 지평선"이라는 바보 같은 문구를 둘러보고, 그 윤곽이 무엇인지를 훨씬 더 정확하게 말해준다.Pdbailey (대화) 2008년 7월 6일 (UTC) 17:24 [응답]
• 반대: 그것들은 개요가 아니다.그것들은 실제 텍스트가 거의 없는 구조화된 목록이다.나는 그것이 어떻게 개요를 구성하는지 모르겠다.— 오류 02:55, 2008년 7월 7일 (UTC)[응답]
• 다른 이름 - X 주제 목록은 유연할 뿐만 아니라 완전히 중립적이다.야구벅스 03:51, 2008년 7월 7일 (UTC)[응답]
• 반대 다른 모든 목록 페이지는 "List of"라는 접두사로 시작하며, 우리가 그 핵심 원칙을 변경하지 않는 한 목록 기사의 이 특정 분기를 예외로 해서는 안 된다. -- Anonymous Dissident^Talk 08:35, 2008년 7월 7일 (UTC)[응답]

• 사실이 아님--Category를 봐봐:위키피디아 특집 목록에는 제목에 "list of"가 없는 목록이 많이 있을 것이다. --Itub (talk) 13:26, 2008년 7월 7일 (UTC)[응답]
• 용어집이란 목록 기사의 전체 분기로서 "list of"를 사용하지 않는다(그 대신 "lossary of"를 사용한다).리스트를 형식별로 구분해 독자들이 열 때 무엇을 기대해야 하는지 알고, 특정 유형의 리스트를 찾아볼 수 있도록 하는 것이 이치에 맞다.예를 들어 용어집, 색인 및 주제 개요를 참조하십시오.트랜스휴머니스트 00:12, 2008년 7월 8일 (UTC)[응답]

• 나는 제안된 이름 변경이 목록의 초점을 넓히기 때문에 반대해야 할 것이다.그러나 '기본'이라는 말이 반드시 정확한 것은 아니며 일부에 의해 모욕적인 것으로 여겨질 수도 있다.예를 들어, "핵심 X 주제 목록"은 범위가 좁지만 더 정확하기 때문에 나는 훨씬 더 선호한다.—RJH (대화) 16:13, 2008년 7월 15일 (UTC)[응답]

• 지원:이것들은 관련 섹션으로 구분되는 고도로 구조화된 정보 목록이다.개요 정의에 대한 자세한 내용은 dictionary.reference.com를 참조하십시오.

일반적으로 제목과 부제목에서 분석되는 서면 작업 또는 연설의 요약. 

이게 왜 큰 일인지 이해가 안 돼.그 토론은 그 페이지의 목적이 무엇인지 좀 더 명확하게 표현하기 위해 제목을 바꾸는 것에 대한 것이다."목록" 네임스페이스는 없으며, 이 페이지들의 이름을 바꾸면 메인 스페이스에 느슨하게 되는 것처럼 취급해서는 안 된다.그들은 이미 거기에 있다.— OranL (대화) 16:56, 2008년 7월 17일 (UTC)[응답]

• 설명:이 페이지들 중 전부는 아니더라도 대부분은 트랜스휴머니스트에 의해 만들어졌고, 이 사용자가 만들지 않았다면 아마 거기 없었을 것이라는 것도 언급할 가치가 있다고 생각한다.— OranL (대화) 16:56, 2008년 7월 17일 (UTC)[응답]

• 지원 — 나는 이러한 변경을 지지하지만 Jheald당 "x의 주제 외부" 또는 "x의 기본 주제 외부"를 더 많이 지원한다.레너드^(Bloom) 04:03, 2008년 7월 18일 (UTC)[응답]

카운터 제안

분명히 위의 논의에서 우리는 구체적인 표현과 그것들이 무엇을 나타내려고 하는지에 대해 많은 문제를 가지고 있다.내가 제안하는 것은 우리가 위키피디아 주제와 포털의 행을 따라 만들어진 새로운 기사 공간을 가지고 있다는 것이다: 그러면 각 주제들은 자신만의 페이지를 가질 수 있을 것이다.아르헨티나의 주제 개요 예제가 주제:아르헨티나; 이집트 기본 토픽 리스트가 토픽이집트 토픽:이집트. 그낭가라 04:00 2008년 7월 7일 (UTC)[응답하라]

흥미롭군포털의 경우:모호하게 연관된 네임스페이스의 창조를 피하기 위한 이집트의 주제들?BigBlueFish (토크) 2008년 7월 7일 (UTC) 10:58[응답]

그거 좋은 생각인 것 같은데그것은 확실히 활용도가 낮은 포털 공간을 명확히 하는데 도움이 된다.그러나 이를 위해 어떤 종류의 가이드라인을 개발해야 하며 그렇지 않으면 이러한 새로운 "주제 포털"이 모르는 사람들에 의해 삭제될 수 있다.

그래, 나는 이 아이디어가 마음에 들어.사실, 나는 "포털:"이 "토픽 포털:"로 이름이 바뀔 수 있다고 생각하고 있다. 즉, 명명법을 더욱 명확히 한다. (그리고 나는 "아웃라인"이나 "인덱스"라는 단어보다 "포털"이라는 용어를 더 좋아한다.)이 점을 분명히 더 깊이 생각할 것이다. - jc37 00:01, 2008년 7월 10일 (UTC)[응답]

위키백과 참조:탐색 목록을 포털 네임스페이스로 이동하여 최근 실패한 페이지 및 다른 페이지를 포털 공간으로 이동하십시오.주요 문제는 포털 네임스페이스가 기본 사이트 검색에 포함되지 않는다는 점이었고, 포털은 검색 결과가 쓸모없는 서브 페이지로 구성되어 있기 때문에 변경할 수 없다는 점이었다(검색에서 하위 페이지를 제거할 수 없다면?).예를 들어 아프리카 관련 포털은 4개가 있지만 검색하면 수백 개의 결과를 얻을 수 있다.

위키백과를 참조하십시오.포털 동료 검토/내용/보관1 포털 개선과 관련된 매우 흥미로운 세미 관련 아이디어:일반적인 포털 영역뿐만 아니라 컨텐츠 페이지도 함께. --Quiddity (대화) 18:17, 2008년 7월 11일 (UTC)[응답]

퀴디티 말이 맞아포털 공간 검색은 하위 페이지 제목(일반적으로 포털 제목에 검색어가 있을 경우 포털의 모든 하위 페이지)에 검색어가 나타나는 경우가 많기 때문에 무용지물이다.트랜스휴머니스트 21:03, 2008년 7월 11일 (UTC)[응답]

반대한다, 이것은 완전히 불필요한 것으로 간주된다.Myheartinchile (talk) 00:17, 2008년 7월 12일 (UTC)[응답]

반대/지지 - 한편으로는 변화를 위해 필요하지 않다.대부분의 사람들은 이런 형식에 익숙하다.그러나 한편, 주제는 장점도 가질 수 있다.항목을 목록으로 리디렉션할 수 없는가?리하스 (대화) 22:46, 2008년 7월 18일 (UTC)[응답]

사용자 기여 및 페이지 기록에 대한 검색 기능

사용자들이 날짜, 시간, 기사 이름, 요약 편집에 있어 키워드를 기반으로 기여도를 검색하고 요약, 기여, 날짜 및 시간 편집에 있어 키워드를 페이지 이력을 통해 검색할 수 있도록 제안한다.나는 그러한 기능을 추가하는 것이 위키피디아의 이런 부분들을 좀 더 사용자 친화적으로 만드는 큰 단계가 될 것이라고 생각한다.이런 식으로 기부를 탐색하는 능력은 매우 도움이 될 것이다.우리는 이미 네임스페이스(그 자체로 매우 도움이 되는)에 근거한 기여를 통해 검색하는 능력과, 열거된 기여 날짜에 상한선을 두어 리스트를 다듬는 능력을 가지고 있다.이 제안은 이 점에서 한 걸음 더 나아가는 것일 뿐이다.— sceto (T C) 04:41, 2008년 7월 8일 (UTC)[응답]

나도 동의해.이것은 지속성 제안의 기록 옵션과 유사하다.Bugzilla 계정을 가져와서 Bugzilla:7988에 투표하십시오. 이 또한 이와 유사하다.이상적으로, 브라우징 엔드에서, 나는 사용자의 기여도를 보고, 그것들을 기사로 축소하고, 그 기사들을 날짜나 편집 횟수별로 분류한 다음, 개별 기사를 클릭해서 크기/날짜별로 정렬된, 그 기사의 모든 편집된 내용을 보고 싶다.또한 모든 되돌리는 편집과 되돌리는 편집들을 나열하는 것도 좋을 것이다.II 04:46, 2008년 7월 8일 (UTC)[응답하라]

접을 수 있는 {{reflist}}

접을 수 있는 버전의 {{reflist}}을(를) 만들고 구현하는 사용자의 의견은 무엇이며, United_States#Reference와 같은 페이지의 reflections는 페이지의 거의 1/3을 차지한다.지금은 일반적으로 나는 뭔가 의심스러운 것이 없는 한 그 참고문헌을 읽지 않는다.만약 우리가 {{Navboxes}}과 같은 것을 사용하거나 너무 {{reflist}}}을(를) 사용하여 이러한 것들을 숨길 수 있다면, 내가 읽는 외부 링크와 Navbox/Category에 훨씬 쉽게 접근할 수 있을 것이다.

두 번째 옵션은 외부 링크/내브박스 및 고양이를 지나 페이지 하단으로 리프를 이동하는 것이다.그네빈 (대화) 09:29, 2008년 7월 8일 (UTC)[응답]

반대: 기본적으로 참조 목록을 숨기는 것은 "클릭 가능성"을 잃게 된다는 것을 의미한다.헤드폭탄 {τακ – WP 물리학: PotW} 11:21, 2008년 7월 8일 (UTC)[응답]

지원: 동의한다.좋은 출처가 있는 기사를 갖는 것은 좋다.그러나 페이지의 99%가 참조 목록일 때는 그렇지 않다.그들을 돌보지 않는 사람들이 혼란을 줄일 수 있는 선택지가 있어야 한다.태평양연안고속도로 05:36, 2008년 7월 15일 (UTC)[응답]

축소된 섹션은 인쇄 전에 자동으로 확장되지 않으므로 반대한다.Refs는 KISS를 유지한 채 인쇄 및 별도의 조치를 취하지 않을 때 사용자에게 제공되어야 한다. --MASEM 05:48, 2008년 7월 15일 (UTC)[응답]

반대: 인쇄가 고정되더라도, 무너진 참조 목록은 여전히 기사 내 참조 링크를 깨뜨릴 것이며, 이는 애초에 기사 내 참조를 보유하려는 목적을 좌절시킨다.Anomie⚔ 11:44, 2008년 7월 15일 (UTC)[응답]

그러면 디폴트로 확장하도록 하십시오.그것을 붕괴시키고자 하는 사람들은 그렇게 할 수 있다.아니면 더 좋은 것은, 그것들을 모두 함께 숨길 방법이 있을까?태평양연안고속도로^{{talk • contribs}} 2008년 7월 15일 (UTC) 18:05[응답]

물론이지. 참고문헌은 CSS 클래스 '참고문헌'과 함께 올에 있으니 개인 CSS로 쉽게 숨길 수 있어.대수학자 18:21, 2008년 7월 15일 (UTC)[응답]

코멘트 나는 당신이 스크롤할 수 있는 브라우저 창과 같은 "상자"에 포함된 뉴욕시 기사의 참고문헌을 본 기억이 난다.만약 당신이 ref를 클릭한다면, 당신이 ref가 있는 "페이지"의 아래쪽에 있는 섹션으로 갈 것이다.디프피를 제공할 수 있으면 좋겠지만, 역사 속에서 찾을 수 없었던 것은, 이 글을 언제 봤는지 기억이 나지 않기 때문이지, 단지 그 글 속에 들어 있었다는 것뿐이야.그런 설정이라면 그동안 제기되었던 두 가지 문제를 모두 해결할 수 있을 것이다. --Pwnage8 (대화) 02:36, 2008년 7월 19일 (UTC)[응답]

반대 — 기본적으로 스크롤 박스는 사용자가 페이지를 인쇄할 때 표시되지 않은 모든 참조를 잘라낸다.자세한 내용은 이 토론을 참조하십시오.위키백과:삭제/로그/2007년 6월 11일 템플릿:Scrollref).- Twas Now (토크 • 기여 • 이메일 ) 03:00, 2008년 7월 19일 (UTC)[응답]

• 인쇄 가능한 버전으로 모든 ref를 표시하면 해결될 수 있다. --Pwnage8 (토크) 03:09, 2008년 7월 19일 (UTC)[응답]

자동 밴드 이름 리디렉션

상황이 이렇다.위키피디아에서 밴드를 찾아볼 때 (내가 원하는 기사로 바로 데려오기 위해) 밴드 이름 뒤에 (밴드)를 타이핑하는 습관이 생겼다. 예를 들어, "Nirvana" 대신 "Nirvana (밴드)"를 타이핑하겠다.문제는 제목 끝에 (밴드)가 없는 많은 기사(예:)의 경우다.롤링 스톤즈(The Rolling Stones), "롤링 스톤즈(밴드)"를 입력하면 제대로 된 기사로 리디렉션되지 않는다.그들이 "밴드 이름(밴드)"에서 "밴드 이름"으로 모든 밴드 기사에 대한 자동 리디렉션을 만드는 방법인가?요즘 그 위키봇들이 얼마나 강력한지 모르겠어...

브랑크론 (토크) 02:12, 2008년 7월 14일 (UTC)브랑크론[응답]

이 기능을 수행하도록 봇을 요청하려면 봇이 매우 쉽게 이 작업을 수행할 수 있다. WP:BOTREQ. 그러한 리디렉션들이 얼마나 유용할지는 잘 모르겠고, 검색하는 것만으로 충분히 쉽고, 그러한 봇 작업은 많은 사람들의 관심사인 수천 개의 편집/페이지 요청을 해야 할 것이다. -IcĕwedGё (ťalķ) 07:51, 2008년 7월 14일 (UTC)[응답]

매일 수천 개의 봇 편집이 있다. 여기서 필요한 볼륨은 아무 문제가 없다.봇 편집은 대부분의 특수 페이지 중에서 선별할 수 있다. -- 존 브로튼 (기침) 14:02, 2008년 7월 15일 (UTC)[응답]

한 명, 더 주목할 만한 밴드가 Name of Band라는 기사를 가지고 있을 때 문제가 발생하며, 덜 주목할 만한 밴드를 Name of Band(그리스 밴드)라고 부른다(예를 들면).이 봇은 이론적으로 Name of Band(밴드 이름)에서 Name of Band로 리디렉션할 수 있지만, 이 리디렉션은 덜 주목할 만한 그리스 밴드의 존재를 무시하게 될 것이다(밴드 이름 기사 맨 위에 분명히 다음과 같이 쓰여 있을 것이다: 그리스 밴드의 Name of Band (그리스 밴드)를 참조하라."

다음은 구체적이고 실제적인 예다.The Loved Ones (호주 60년대 그룹)와 The Loved Ones (미국 밴드) (2000년대 그룹)에 대한 기사가 있다.최근에 나는 이것을 다루기 위해 The Loved Ones (밴드)라는 불분명한 페이지를 만들었다.그러나, 내가 이것을 이해하지 못했다면, 봇은 분명히 '사랑하는 사람들'(밴드)을 '사랑하는 사람들'로 리디렉션하게 만들었을 것이고, 사용자가 그것을 알아차리기까지는 어느 정도 시간이 걸릴 것이다(그리고 아마도 사용자가 적절한 모호성 페이지를 만들고 신경을 쓰는 데는 더 오래 걸릴 것이다).분명히 다른 예들이 있다.이상적으로 이러한 상황에서 둘 중 더 눈에 띄는 것은 괄호 없는 것이어야 하고, (밴드) 태그는 모호한 페이지여야 하며, 덜 눈에 띄지 않는 밴드는 모호하게 해야 한다(푸아 밴드)가 있어야 한다.- Twas Now (토크 • 기여 • 이메일 ) 02:20, 2008년 7월 19일 (UTC)[응답]

검색창은 지금 입력하면서 검색결과가 좁아지기 때문에 검색현장을 어지럽힐 뿐이다. --Pwnage8 (토크) 02:40, 2008년 7월 19일 (UTC)[응답]

위키백과:Evernivery_proposals#Enforce_American_or_British_speaking

위의 여러 해 동안 지속되는 제안에 대해, 이것을 선호로 설정하는 것을 제안한 사람이 있는가?예를 들어 ("colo[u]r"라는 단어를 사용하여) 선호 설정이 인식할 수 있는 템플릿을 만든 다음, 봇이 WP를 거쳐 기사의 모든 "colo[u]r"에 템플릿을 추가하여 기사의 "{ English color}}"와 비슷한 모양으로 보이게 한다.그런 다음 사용자가 영어=미국어로 기본 설정을 지정하면 템플로 작성된 모든 "색상"이 "색상"으로 나타난다.그러나 템플릿 기능과 선호 기능이 그렇게 상호작용을 할 수 있을지 모르겠다.생각일 뿐이야.Rgrds. --Tombstone (talk) 2008년 7월 14일 (UTC) 12:41, 응답하라

그것이 가능한지는 모르겠지만, 만약 가능하다면 그것은 매우 좋은 생각이다.유일한 문제는 어떤 버전의 새 계정이 디폴트되는지일 것이다.또 하나의 거대한 논쟁이 될 것 같은 느낌이 든다. -- 임페라이터3733 (대화) 16:53 (UTC) 2008년 7월 14일 (UTC)[응답]

나는 그것이 환상적인 생각이라는 것에 동의하지만, 문제는 정말로 그것이 기술적으로 실현 가능한가 하는 것이다.가능한 "기본" 토론을 해결하기 위해, 환경설정은 기본적으로 전혀 활성화되지 않는다.만약 그런 일이 가능하다면, 나는 그것을 해 보라고 말하겠어! --oracrobat.알렉스: 2008년 7월 14일 17시 8분 (UTC)[응답하라]

그것은 좋은 생각이야 - 선호도를 활성화시키지 마.이제 우리는 그것이 가능한지 알아내야 한다... -- 임페라토리3733 (대화) 17:13, 2008년 7월 14일 (UTC)[응답하라]

좋게 들리는데, BUT - 인용구나 이름은?인용문이나 이름의 철자를 바꾸는 것은 잘못된 일일 것이다.던컨힐 (토크) 2008년 7월 14일 (UTC) 17:17[응답]

나는 원칙적으로 이 생각을 지지하지만 몇 가지 주의사항이 있다.

1. 철자가 공통 표준을 제안할 정도로 충분히 정의되어 있는가?심지어 일부 하위 유형에도 변화가 있다: 어떤 유형들은 접미사 -ise를 선호하고 다른 유형들은 -ize를 선호한다.
2. 변형 특정 단어 또는 단어 사용 또는 구문이 항상 "트랜잭션 가능"한가?나는 "번역"에 따라 특정한 의미를 가진 단어들이 그 의미를 바꾸는 경우를 볼 수 있다.
3. 그 프로젝트가 가치가 있는가?우리는 이미 합리적인 연관 체계(예: 캐나다는 캐나다 영어를 사용함)와 판례(한 번 기사가 디폴트로 사용할 수 있는 변형을 사용하기 시작함)를 가지고 있기 때문에 그러한 시스템을 만들고 배치하는 데 수반되는 막대한 양의 작업은 그 노력의 가치가 없을 수도 있다.

(특히 단위와 통화를 국산화할 수 있는 잠재력을 위해) 이런 것이 있으면 좋겠지만, 당분간은 실현가능성과 가치 둘 다 있을까?{{Nihiltres talk log}}}20:08, 2008년 7월 14일 (UTC)[응답]

나는 이것이 매우 나쁜 생각이라고 생각한다.우선, 1 대 1의 서신 왕래가 없기 때문에, 미국 프로그램은 텔레비전 쇼나 극장 일정을 언급할 때 영국 프로그램으로 전환되어야 하지만, 컴퓨터 대본은 아니다.면허증은 명사일 때는 면허가 되지만 동사일 때는 면허가 되지 않는다.인용문은 철자법을 논하는 기사와 마찬가지로 특별하게 작성되어야 할 것이다.대략적인 번역으로 뉘앙스를 잃게 될 것이다.어떤 단어들은 각 시스템에 의미를 가지거나 한 단어에는 다의어가 있지만 다른 단어에는 의미가 없기 때문에, 기존의 모든 텍스트는 현재 어떤 관습을 따르는지 검토해야 할 것이다.우리는 단지 단어들을 위키리크해서 링크된 기사들이 그 문제를 설명하도록 하는 것이 더 나을 것이다.Phyomonas_(talk) 22:03, 2008년 7월 14일 (UTC)[응답]

그것은 나에게 살인적인 반대처럼 보인다.철자 변환이 의미나 문법적 기능에 따라 달라지는 단어 목록은 크다. 예를 들어, "타이어"(미국) = 차량 바퀴의 고무를 지칭할 때는 "타이어"(영국)이지만, 피로(피로)를 지칭할 때는 = "타이어"(영국)이다.그러면 복합어가 문제를 복잡하게 만들 수 있다. 예를 들어, 한 대의 차량에 대해 하나의 레티어(영국)가 있지만, 업무에서 은퇴(영국, 미국)가 된다.더 복잡한 문제로서, 일부 미국 철자는 변환되어서는 안 된다. 예를 들어, "lite"는 덤다운 버전이 영국 영어로 "lite"로 표기될 것이라는 것을 의미한다.악몽이야. -- 필차 (대화) 22:46, 2008년 7월 14일 (UTC)[응답하라]

만약 내가 이것을 정확하게 읽고 있다면, 그 의도는 각 단어의 각 인스턴스를 템플릿에 넣는 것이라고 생각한다; 이것은 널리 사용되는 것을 제한하지만, 그것에 대한 약간의 편집 전쟁을 멈출 수도 있다.이를 구현하는 분명한 방법은 원하지 않는 변형을 숨기기 위해 일부 자바스크립트 해킹을 사용할 수 있기 때문에 자바스크립트를 사용하는 사용자는 선호하는 버전을 볼 수 있고, 그렇지 않은 사용자는 둘 다 볼 수 있다.파서(Parser)에서 수행하면 그렇게 심하게 저하되지는 않지만, 상당히 복잡하여 다른 사용자 선호도, 새로운 파서 함수, 그리고 다른 철자를 추적하기 위해 각 페이지의 캐시된 버전이 더 필요할 것이다. -Steve Sanbeg (talk) 22:29, 2008년 7월 14일 (UTC)[응답]

그리고 태블링의 부차적인 절차는 어떻게 처리하시겠습니까? --카르닐도 (대화) 22:40, 2008년 7월 14일 (UTC)[응답]

기술적으로 실현 가능하겠지좋은 생각이야, 아마도.수고할 가치가 있지, 확실히 없지.이를 사용자 기본 설정으로 만들기 위한 모든 백엔드 기술 변경 외에도(날짜 자동 포맷과 같은 일종의 마법 파서 구문이어야 하며, 일반 템플릿은 이를 수행할 수 없음) 봇은 위에서 언급된 명사/Verb 사용 및 인용문 때문에 코딩하는 데 상당한 시간이 걸릴 수 있으며, 아마도 많이 놓치거나 많은 문제가 있을 것이다.양성의기사 절반만 바꾸면 된다고 해도 편집/분 60개로(일반 봇보다 훨씬 빠른 속도) 2주 가까이 꾸준히 편집해야 한다.마지막으로, 페이지 캐싱은 등록되지 않은 사용자에게만 작동하기 때문에, 이것은 계정을 가진 사람들에게만 유용할 것이기 때문에, 대다수의 사용자(독서자)는 결코 알아차리지 못할 것이다.이것은 또한 위키 세금을 더 복잡하게 만들 것이며, 이것은 또한 가능한 한 피해야 할 것이다.Mr.Z-man 22:42, 2008년 7월 14일 (UTC)[응답]

정말 멍청한 질문이다:미등록 사용자에게는 마법처럼 'WHOIS' 링크를 읽고 자신이 어느 나라에 살고 있는지 판단해 그 언어의 변형을 사용할 수 있을지 궁금하다.그냥 바보 같은 생각. --톰브스톤 (대화) 01:39, 2008년 7월 15일 (UTC)[응답하라]

그렇다, IP 주소를 국가에 매핑하는 것은 기술적으로 비교적 쉽다.어쨌든 봇이 해야 할 자연어 처리량에 비하면 말이다.새로운 편집 사항을 따라잡는 일은 말할 것도 없다.Phyomonas_(talk) 10:54, 2008년 7월 15일 (UTC)[응답]

참고로 여기 내 IP 주소는 내가 마지막으로 확인했을 때 뉴욕으로 이동하는데, 그것은 아일랜드에 있는 나의 실제 위치와는 상당히 거리가 있기 때문에, 자동 감지를 무효로 하는 어떤 방법은 필수일 것이다! --_{tiny plastic} 그레이 나이트 knight 12:09, 2008년 7월 16일 (UTC)[응답]

1 대 1의 서신이 없다는 사실을 어떻게 처리해야 할지 막 생각이 났다.템플릿에는 두 가지 매개변수가 있어야 한다. 하나는 미국식 영어용이고 다른 하나는 영국식/공통식 영어용이다.결국 이렇게 보일 것이다:<tt>{{영어색깔}}</tt.템플릿은 미국식 영어에 대한 선호도라면 출력하고 영국식 영어에 대한 선호도라면 출력하도록 설계될 것이다.기본 설정 디폴트는 다른 사람들이 제안한 것처럼 IP의 위치에 따라 달라진다.어떻게 생각하십니까? -- 임페라토리3733 (대화) 20:40, 2008년 7월 16일 (UTC)[응답]

나는 그것이 불필요하게 복잡하다고 생각한다.미국에서 온 누군가가 '색깔'이라는 단어가 적힌 문장을 읽고 "도대체 그게 무슨 뜻이지?"라고 궁금해 하는 것은 정말 상상할 수 없다.이것은 위키텍스트 구문을 지나치게 복잡하게 만드는 또 다른 방법일 뿐이고, 만약 그것이 템플릿을 사용한 것이라면, 그것은 Javascript 해킹이 되어야 할 것이고, 그래서 그것은 페이지 로딩 시간을 늦출 수 있다, 특히 느린 연결을 가진 사람들의 경우.또한 IP 매핑을 사용하면 미국이나 영국에 없는 사람들은 어떻게 할까?아르헨티나 사람들은 무엇을 볼 것인가?아니면 한국?Mr.Z-man 21:14, 2008년 7월 16일 (UTC)[응답]

사실 얼마 전에 한 행정관이 2주 동안 누군가를 막았던 재미있는 사건이 있었다.다른 관리자 지구에서"보름"이 있었는지 의아해 하기 시작했다 그는 거의 즉시!(손에 만약곤 했지 온라인 사전이나 백과 사전, -o)제 얘기는 언어 차이의 복잡성 아마도 너무 많은 말썽을 피워, j.에 비해 충분하다는, 대서양 저편의 언어 차이의 정도 등을 알아냈다uwikilinking 또는 기타 혼동될 수 있는 명확한 용어.사용자:카르닐도의 태블링에 대한 언급은 볼만한 가치가 충분히 있다. 특히 치명적이다! --_{tiny plastic} 그레이 나이트 ⊖ 08:34, 2008년 7월 17일 (UTC)[응답]

최소한의 이익을 위해 시스템 자원의 낭비일 수 있다.— Werdna • talk 04:26, 2008년 7월 17일 (UTC)[응답]

참으로 훌륭하게 건설적인 논평이다.너 같은 사람들은 브레인스토밍과 열린 마음을 조장한다! --톰브스톤 (토크) 04:34, 2008년 7월 17일 (UTC)[응답]

그리고 그 답변이 토론에 무엇을 더했는가?그 사람을 공격하는 대신에, 왜 그 논평에 대해 언급하려고 하지 않는지, 그렇지 않으면 당신은 신경 쓰지 않거나 대답을 하지 않는 것처럼 보인다.Werdna는 자원 봉사자인 MediaWiki 개발자 중 한 명인데, 만약 그가 어떤 것이 시스템 자원의 낭비라고 말한다면(서버들은 전적으로 기부금과 보조금에 의해 지불되기 때문에 매우 중요하다), 그것은 아마도 그럴 것이다.Mr.Z-man 22:54, 2008년 7월 17일 (UTC)[응답]

그리고 그가 거물급이 되는 것이 그가 바보 같은 말을 하는 것을 변명한다고?내 잘못이야.뺑소니 "쓰레기...개발자의 "자원"은 정말로 창의적인 사고를 차단한다. IMO. 나는 WP 개발자들로부터 많은 것을 본다. 선의의 논평은 시스템 지식이 많지 않은 사람에 의해 만들어지고, 그것에 대해 모든 것을 아는 비웃음들이 있다.아마도 베르드나의 말은 상당한 영향력을 가지고 있고, 효과적으로 이 논의를 끝냈을 수도 있지만, 아마도 베르드나(그리고 모든 개발자) 또한 그들의 "소비티" 끝에 진짜 사람들이 있다는 것을 깨달아야 할 필요가 있으며, 그는 (개발자/프로그래머들이 흔히 하는 것처럼) 바보 같은 발언을 하는 것을 중단해야 한다.하지만 네 말이 맞아.그것이 시스템 자원의 낭비라는 것을 알게 된 후(그가 그것을 낭비라고 생각한 이유를 전혀 제시하지 못했다), 나는 펌프에 대한 믿음을 잃고 WP의 실제 부분에서 더 나은 할 일을 하게 되었다.(당신에게 불리한 것은 아무것도 없어, Z-man씨, 나는 당신과 긍정적인 (적어도 적은) 상호작용을 한 것뿐입니다.)Rgrds. --Tombstone (토크) 11:39, 2008년 7월 18일 (UTC)[응답하라]

철자 차이는 다른 언어의 다양성 차이와 비교했을 때 미미하며, 인간의 뇌에는 쉽다.내가 8살때 스코틀랜드에서 영어수업은 미국문학을 포함했고 번역되지 않았다.그래서 우리는 여름 다음에 오는 계절에 대해 우리 스스로에게 그 단어를 가르쳤다.다행히도, 8살 아이들은 토론에서 표로 된 동작에 관심이 없다.하지만 우리에게 2주 동안 일상적인 단어와 혼동할 수 있었던 미국 펜 친구들이 있었으면 좋았을 텐데. --Hroroulf (또는 Hrothulf) (토크) 21:28, 2008년 7월 17일 (UTC)[응답]

비도반달리즘

임호, 우리는 선의의 개조를 언급하기 위해 속기 표현이 절실히 필요하다.실망한 편집자들은 종종 그러한 편집 반달리즘을 부르는데, 물론 그러한 편집은 해칠 의도가 없기 때문에 그런 편집은 아니다.나의 첫 번째 아이디어는 의도치 않은 반달리즘에 대한 "비도덕주의" 였는데, 그것은 물론 진부한 것이다.나는 이것에 대한 제안과 의견을 들을 수 있으면 좋겠어, 미리 고마워.사용자:매 15:45, 2008년 7월 15일 (UTC)[응답]

나는 그러한 편집을 비생산적이거나 도움이 되지 않는다고 부르고 싶다.심지어 공공 기물 파손에 대한 물타기식 언급조차 여전히 그들을 기물 파손자라고 부르고 있는데, 그렇지 않다.2008년 7월 15일 15:52(UTC)[응답]

나는 "rv - needs source"의 편집 요약이 오히려 나에게 무해하게 작용한다는 것을 알았다.Rgrds. --Tombstone (토크) 15:57, 2008년 7월 15일 (UTC)[응답하라]

차선이지만 정책적으로 적합한 편집은 어떻게 하시겠습니까?사용자:매 16:52, 2008년 7월 15일 (UTC)[응답]

만약 그들이 정책에 따르지만 여전히 차선책이라면, 우리는 그것들을 되돌리는 것이 아니라 고치고 있어야 한다.Mr.Z-man 00:07, 2008년 7월 17일 (UTC)[응답]

나는 편집자의 의도에 대해 선의의 판단을 하고 있지만 여전히 정책에 부합하지 않는다고 믿기 위해 "신의성 수정"이라고만 말하는 경향이 있다.헷갈리는 표현 (Say hi!) 04:26, 2008년 7월 16일 (UTC)[응답]

나는 선의로 편집하는 경험이 없는 편집자들의 이름이 좋은 생각일 수도 있다고 생각하지만, 나는 그것이 정말로 WP:Bitte와 일치해야 한다고 생각한다. 그러나 그것은 사용자들이 정책을 잘 모르고 의도적으로 이런 것들을 하지 않는다는 사실을 반영해야 한다.아마도 우리는 그들을 단순히 InEx 편집자(미숙한 경우?)%-SYKKO-% (나에게 말함) 04:36, 2008년 7월 16일 (UTC)[응답하라]라고 부를 수 있을 것이다.

왜 그들 또는 그들의 편집에 대해 "특별한" 이름을 생각해 냈는가?불필요해 보인다.2008년 7월 16일 셰어 17:03 (UTC)[응답]

주로 내부 대화, 용어가 유용할 수 있는 대화

• 롤백에 대해 논의할 때 요약으로 실행 취소를 하지 않고 만든 롤백
• 이러한 유형의 편집기를 지원하는 방법에 대한 논의
• 편집자가 실제로 반달족이 아니라고 주장하는 것

그것은 단지 내 머리 위에 몇 가지 이름을 붙이는 것이다.빠른 용어가 도움이 되는 이유는 복잡한 정의를 빨리 사용하기 쉽게 하기 때문이다."이 구성원이 선의로 행동하지만 지금까지 해온 일에 역효과를 냈다고 생각한다"고 설명하는 대신 "이 편집자가 (여기에 용어 삽입)"고 말할 수 있다. 나는 그것이 정책적 수준의 것이 되어야 한다고 확신하지는 않지만, 아마도 어떤 종류의 정의를 내리는 무심코 하는 용어가 도움이 될 것이다.대화를 더 효율적으로 만들 수 있을 겁니다이 아이디어에 대한 나의 가장 큰 동의서는 WP 이후 더 많은 것이다.AGF는 모든 위키피디아 사람들이 이미 중복된다고 가정하는 용어를 사용하는 것으로 받아들여지는 지침이다.어쨌든, 나는 주로 내 의견을 거기에 던지고 있어.이런 유형의 편집자용어가 widley 사용됐다면 내가 직접 사용할 가능성이 높다고 생각한다.%-SYKKO-%(말씀) 17:36, 2008년 7월 16일 (UTC)[응답]

그건 말이 안 돼.이미 이것에 대한 완벽한 묘사가 있는데 왜 우리는 새로운 단어를 만들어 내야 하는가?우리는 새로운 사용자들을 위해 위키피디아를 더 어렵게 만들려고 노력하고 있는가?Mr.Z-man 00:07, 2008년 7월 17일 (UTC)[응답]

좋은 지적이야, 그런 식으로 생각해 본 적이 없어. %%-SYKKO-% (말씀) 00:22, 2008년 7월 17일 (UTC)[응답]

그 단어는 존재하며 "선량한 믿음의 편집"이다.반달은 정의상 신의가 없는 편집자; WP:AGF는 항상 선의를 지키라고 말하는 것이 아니다; 그것은 "반대에 설득력 있는 증거를 주지 않는 한, 선의를 인정하라"거나 "반달리즘이 증명될 때까지 선의"라고 말한다.Dcoetzee 06:40, 2008년 7월 19일 (UTC)[응답]

다른 종에 대한 기사의 이름을 과학적인 이름으로 바꾸자는 제안.

이 사자에 따르면 판테라 레오가 될 것이다.프리토킬메스 (대화) 18:38, 2008년 7월 17일 (UTC)[응답]

왜? 대수학자 18:46, 2008년 7월 17일 (UTC)[응답]

이것은 기사의 이름에 대한 편집 전쟁이 있을 때 유용할 수 있지만 나는 어떠한 예도 알지 못한다.그래서, 이것은 어떤 "모양"이 더 좋은지, 그리고 내가 그것을 예언한 이유는 스타일에 관한 것이야...프리토킬메스 (대화) 2008년 7월 17일 (UTC) 18:56 [응답]

나는 편집 전쟁이 일어날 때 이 전략을 사용해도 괜찮다.일반적으로, 나는 큐레이팅을 하고, 물건을 찾기 어렵게 만들고, 불필요한 리디렉션을 많이 수반하는 것은 어려울 것이라고 생각한다.많은 일반적 이름(일반적으로 사람들이 찾고자 하는 이름)은 여러 종을 포괄한다.위키피디아는 별개의 문제로서, 애초에 분류학 연습에 더 가깝다.Phyomonas_(talk) 19:08, 2008년 7월 17일 (UTC)[응답]

위키피디아 토크에서 이것을 제기할 수 있다.명명 규칙, 그러나 나는 그것이 따뜻한 반응을 얻지는 못할 것이라고 예상한다.우리의 기존 규칙은 기사 주제에 대해 "가장 쉽게 인정받는 이름"을 사용하는 것이다.우리는 일반 독자들에게 친숙할 것 같은 용어를 선호하는 경향이 있다.

언급했듯이, 내가 이것이 유용하다고 볼 수 있는 유일한 장소는 타이틀 분쟁을 다루는 데 있다. 하지만 그때도 타이틀 분쟁이 희귀하고 전문화된 유기체를 다루는 전문가들 사이에 있고, 제안된 타이틀의 전부 또는 일부의 타당성에 대한 의문이 있는 경우에만 좋은 해결책이 될 것이다.유기체에 유효한 이름이 여러 개 존재하며, 다른 이름보다 한 이름을 선호할 명확하고 분명한 이유가 없는 경우, 미국/영국식 영어 명명 분쟁에서 우리가 하는 일을 하지 않을 이유가 없다. 즉, 그 기사가 만들어진 제목을 유지하고, 다른 명칭을 리디렉션한다.또한, 많은 주제들은 공통적인 이름과 '과학적인' 이항적인 이름 양쪽의 기사들을 가지고 있고, 후자는 종종 분류학 관련 정보를 포함하고 있다.주키니, 쿠르제트(영국식 영어 리디렉션) 및 쿠쿠르비타 페포(이항식 이름)에 대한 우리의 기사를 한 예로 보십시오.TenOfAllTraes(대화) 19:27, 2008년 7월 17일 (UTC)[응답하라]

사실 이탈리아어와 스페인어 위키백과는 내가 말하는 대로여서, 나는 "이것은 이미 여기서 논의된 바 있다 당신은 링크를 가지고 있다"와 같은 대답을 기대하고 있었다.어쨌든, 이것은 유용해 보이지 않는다.프리토킬메스 (대화) 2008년 7월 17일 19:51 (UTC)[응답]

마지막으로 "나는 큐레이팅을 하고, 물건을 찾기 어렵게 만들고, 불필요한 리디렉션을 많이 수반하는 것이 어려울 것이라고 생각한다."리디렉션의 양은 증가하지 않을 것이다.예를 들어, 팬테라 레오는 이미 리디렉션된 것이다.

내가 말하려던 요점이 바로 그거야.누가 만들었지?2008년 7월 17일(UTC) 23시 32분 더 공작 월텀(Walthaltham, The Duke of 23:32

OP. 대수학자 23:37, 2008년 7월 17일 (UTC)[답글]

데이터베이스에 더 많은 리디렉션이 있을 거라는 뜻이 아니라, 더 많은 방문자들이 예상한 페이지로 가는 대신 리디렉션을 따를 것이라는 뜻이었다.Phyomonas_(talk) 09:58, 2008년 7월 18일 (UTC)[응답]

WikiLink- Ready-made bookmark side frame - 보다 효율적인 웹 정보 사용 방법 제안

위키링크는 내가 위키피디아에 부과하고 싶은 소셜 북마크 서비스다.

위키피디아가 모든 주제에 대해 공통적으로 접근 가능하고 편집 가능한 책갈피를 가지고 있다고 상상해 보십시오.

잘 정리된 책갈피는 사람들이 더 쉽고 빠르게 주제에 관련된 중요한 사이트들을 접할 수 있게 해준다!

예를 들어, 나는 Damicy와 Firefox로 아이팟에 관한 기사를 샘플로 만들었다.

비록 내가 만든 사진은 완전한 버전은 아니지만, 위키링크가 어떻게 작동하는지 볼 수 있었으면 좋겠어.

위키백과가 위키링크를 부과하고 몇 가지 제안을 한다면 기술적인 논의가 있어야 할 것 같다.첫째, 왼쪽 프레임으로 부과할 수 있다.둘째로, 필요하다면 위키백과는 위키링크 프로그램을 개발하거나 소셜 북마크 제공자들과 협력할 수 있다.

- "아브라스퍼"

Hello: IPod#를 참조하십시오.이미 관련 사이트에 대한 문서 내 링크를 제공하는 외부 링크.만약 사용자가 기사 자체에 포함되어 있지 않은 "웹 2.0"-y 링크를 조정하고 싶다면, 당신은 아마도 위키피디아의 조합으로 무언가를 만들 수 있을 것이다.위키프로젝트 사용자 스크립트/스크립트 및/또는 그리스몽키. --_{tiny plastic} 그레이 나이트 -- 08:52, 2008년 7월 18일 (UTC)[응답]

코멘트와 유용한 추천에 감사한다.나는 편집자들이 외부 링크를 기사 안에 넣을 수 있다는 것을 알지만 위키링크는 관련 웹사이트들의 모음과는 다르다.간단하지만 주제에 대해 심도 있는 연구를 하고 싶어하는 사용자들에게 큰 도움이 될 것이라고 믿는다.

내 코멘트의 다른 부분은 다음과 같은 글을 써서 위키피디아에 추가할 수 있다는 것이었습니다.WikiProject 사용자 스크립트/스크립트.이 스크립트는 이를 채택하기로 선택한 사용자에게 모호하지 않은 인터페이스 요소를 추가할 수 있으며, 이를 통해 현재 기사에 대한 링크를 제안하거나 다른 사용자가 제안한 링크를 볼 수 있다.나는 그것이 (예를 들어, Foo에 대한 링크는 Talk에 보관될 것이다:Foo/LinkSurist Links(여기서 도구를 "LinkSurist"라고 부를 줄 알았는데)편집자에게 유용하지만 어떤 이유로든 기사에 언급할 가치가 없는 링크(예: 소싱에 유용하지만 현재 소싱되는 것이 없는 사이트)가 있는 경우 유용할 수 있다.외부 토론 사이트로의 링크는 또 다른 예일 수 있다. 대부분의 경우 외부 링크나 출처로는 사용할 수 없지만 여전히 연구에 유용한 도약 지점이 될 수 있다.이 아이디어에 어느 정도 쓸모가 있는 것 같아._{tiny plastic} -- 그레이 나이트 ⊖ 12:35, 2008년 7월 18일 (UTC)[응답]

기본 페이지를 위키백과 네임스페이스로 이동

위키백과의 토론에서 코멘트는 환영한다.마을 펌프(기술)#제안: 기본 페이지를 위키백과 네임스페이스로 이동하십시오.—2008년 7월 19일 03:37, 점 기억[응답]

"비판" 섹션.'억지' 코너도 있어야 하지 않을까?

내가 관심 있는 대중문화의 여러 과목을 알아보았다.토치우드는 비판 섹션을 개발하는 데 있어 매우 쉽다.하지만 '억지' 코너도 있다면 공평하지 않을까?논리적이고 공정할 뿐이다.비평가 섹션은 애초에 홍보하지 않는 것이 위키피디아 지침일 것이라는 것을 알지만, 나는 이 문제에 대한 인식을 조성하고자 이 글을 올린다.기사에 대한 비판 섹션과의 부정성은 공정한 평가를 위해 평가 섹션과 상충될 수 있다는 것을 잊지 마십시오.꽤 많은 양의 트롤링이 여러 구역으로 나뉘고 있다.사람들은 "비판" 섹션에서 찾을 수 있는 부정적인 면으로 그들의 증오하는 주제를 스팸으로 보낸다.반대로 하고 칭찬 섹션을 좀 줘라.하하. --Leradax (대화) 2008년 7월 14일 (UTC) 20:13[응답]

많은 위키백과 기사의 비판 섹션은 종종 비판을 주최하는 것이 아니라, 비판적인 리셉션을 언급하는 데 사용된다.예를 들어 할로윈을 보면 (1978년 영화)#비판하라, 그 섹션은 영화가 호불호불호하게 누린 비판적 리셉션에 관한 것이다.하지만 당신의 게시물은 이것이 좋은 단어가 아닐 수도 있다는 것을 강조한다.그럼에도 불구하고, 여러분은 비판만을 포함하는 "비판"이라는 섹션이 균형을 이루어야 한다는 것이 옳다. (WP: 참조).이와 관련된 일부 정책 고려사항에 대한 가중치).물론 주제를 고려해야 한다. 일반적으로 공포로 바라보는 것에 대한 기사(제3제국, 린칭 등)에서의 비판은 토치우드에 관한 기사가 할 수 있는 것과 같은 방식으로 균형을 맞출 필요는 없다!나는 우리가 일반적으로 "혐오" 섹션과 "유사한" 섹션이 있어야 한다고 생각하지 않는다. 통합된 비판적 리셉션 섹션은 종종 충분해야 한다.마찬가지로, 우리는 일반적으로 논의되었던 주제에 대해 부정적인 반응과 그 반대의 반응을 거의 상쇄할 정도의 찬사를 기대해서는 안 된다.--Fuhgettaboutit (대화) 20:28, 2008년 7월 14일 (UTC)[응답]

사용자:Leradax도 그 섹션 이름에 혼동된 첫 번째 사람이 아니다."비판"이 특히 사용되는 이유를 아는 사람이 있는가?이 문제가 나올 때마다 편집자들이 "저 부분은 사실 비판적인 리셉션을 위한 것"이라고 말하는 것을 본다.아마도 "Critical Receivency" 그 자체가 이 섹션들에 더 나은 제목이 될 것이다.아니면 훨씬 더 좋은 제목이 있을까?「비판」은 언제까지나 혼란의 원인인 것 같다.--_{tiny plastic}그레이 나이트 ⊖ 11:40, 2008년 7월 15일 (UTC)[응답]

많은 영화 기사들은 "비판적인 리셉션"(You Don't Matched with the Zohan)이나 "리셉션"(Iron Man (동음이의))을 사용한다.---- Gadget850 (Ed) - 16:16, 2008년 7월 15일 (UTC)[응답]

그것은 일반적인 위키백과 지침이 되어야 한다.그 혼란은 부당하지 않다.비판이라는 단어만 사용하는 것은 달리 정의되지 않는 한 대개 부정적인 비판을 가리킨다. --Leradax (대화) 12:34, 2008년 7월 16일 (UTC)[응답]

기본적으로, 1을 덧붙이자.http://www.thefreedictionary.com/criticism?p --Leladax (대화) 12:40, 2008년 7월 16일 (UTC)[응답하라]

비판 섹션 위의 섹션은 보통 칭찬 섹션이다. --Lister 12:55, 2008년 7월 16일 (UTC)[응답]

비판 섹션은 종종 비판에 대한 반응을 포함하고 있다: 하지만 당신이 옳다, 그것들은 스팸과 말도 안 되는 자석이다, 섹션이 'prop and consident' 섹션이 그렇듯이.Leradax와 Grey Knight의 질문에 답하려면:

관련 스타일 가이드라인이 있다(Wikipedia:Words_to_avoid#문서_구조), 정책 페이지(Wikipedia:중립적 관점#아티클 구조) 및 템플릿({critism-섹션}}).

도움이 되길 바라. --Hroroulf (또는 Hrothulf) (토크) 14:02, 2008년 7월 17일 (UTC)[응답하라]

고마워. 위키피디아를 찾았어.비판 및 위키백과:프로와 콘은 유용한 읽을거리도 나열한다._{tiny plastic} --그레이 나이트 ⊖ 15:39, 2008년 7월 17일 (UTC)[응답]

여기 이 행정관이 TV시리즈의 암매장이 이미 시작됐다는 이유로 합법화 된 것을 확인해 보십시오!Talk:Crit_of_토치우드 --Leradax (대화) 2008년 7월 20일 (UTC) 19:42, 응답

모든 코드 샘플은 변환되어야 함

수년 동안 많은 기사에서 선의의 기여자들에 의해 이전에 수정된 코드 샘플에 오류가 체계적으로 도입되어 왔다.어구의 사소한 오류는 큰 문제가 되지 않지만, 소스 코드의 사소한 오류는 작동 코드와 손상된 코드 사이의 차이점이다.사용자들이 소스 코드를 편집하지 못하도록 하는 것은 사실상 무의미할 것이다. 결국 그들이 실제 오류를 발견했을 수도 있다. 하지만 현재, 소스 코드에 대한 변경을 효과적으로 면밀히 조사하기는 어렵다. 왜냐하면 그들은 기사에 대한 다른 모든 변경 사항들과 섞여 있기 때문이다.잘못된 변화를 추적하는 것조차 세금을 부과할 수 있다.최근 퀵소트에서 튀어나온 미묘한 예시는 두 달째 서있었고, 퀵소트가 내 감시대상에 있는데도 슬그머니 내 옆을 스쳐갔다.

나는 위키피디아의 모든 소스 코드나 가성 코드의 샘플은 그것이 사용되는 기사로 변환된 템플릿 페이지에 포함되어야 한다고 제안하고 있다.이것의 목적은 편집을 더 어렵게 하기 위해서가 아니라 - 심지어 편집을 용이하게 하기 위한 링크를 포함할 수도 있다 - 이 높은 우선순위 컨텐츠를 별도로 보고 추적하기 훨씬 쉽게 하기 위해서입니다.이렇게 개선된 정밀검사는 코드에서 더 적은 미묘한 오류로 이어질 것이다.

수학적인 증명이나 화려한 기사 마크업과 같이 선의의 편집자들에 의해 깨지기 쉽고 종종 교묘히 방해되는 어떤 콘텐츠에도 동일한 개념을 적용할 수 있다.의견이 일치한다면 모든 코드 블록을 템플리트로 만드는 힘든 일은 내가 책임질 것이다.당신은 어떻게 생각하나요?Dcoetzee 00:10, 2008년 7월 18일 (UTC)[응답]

너도 켐박스 코드 말하는 거니?나는 심박스를 만들어서 티오머살에서 그것을 망쳐 놓았고, 즉시 되돌아갔다.이쪽에서 그 문제에 대한 논의가 있다.단점이 있다면, 더 적은 사람들이 이 켐박스를 보고 있기 때문에, 그들은 더 쉽게 파괴될 수 있다는 점인 것 같다.게다가, 새로운 편집자들이 정보를 편집하는 것은 더 어렵다.II (t - c) 00:24, 2008년 7월 18일 (UTC)[응답]

중요한 것은 템플릿이 쉽게 파손된다는 것이다. 왜냐하면 주요 기사를 보는 사람들은 템플릿도 볼 것을 권장하고, 이 중 하나가 감시 목록에 올라오면 변화를 주의 깊게 관찰하는 빨간 깃발이 되기 때문이다.편집하기 어려운 새로운 편집자 문제는 모든 템플릿에 적용되며, 많은 인포박스는 편집 링크를 내장하여 이를 처리한다.심박스에 대해서는, 그것은 코드가 아닌 인포박스에 불과하고, 사람들이 끓는점에서 무작위로 소수점을 이동하지 않는 한, 미묘한 오류에 특별히 취약하지 않기 때문에, 나는 다른 상황이라고 생각한다.2008년 7월 18일 (UTC) 0:31, Dcoetze 00:31[응답]

어떻게 격려해?—David Eppstein (대화) 01:16, 2008년 7월 18일 (UTC)[응답]

나는 예제 코드의 끊임없는 변화를 지켜보는 것은 짜증나는 일이고 만지작거리는 것은 금물이라는 것에 동의하지만, 어떻게 그럴 수 있을까?일부 변경은 다양한 부분이 일관성이 있는 합법적인 변형이다(그리고 이것은 미묘할 수 있다).퀵소트는 여러 곳에서 <, <=, >, <=>로 악명이 높으며, 단순한 알고리즘이라도 꼼꼼한 검사가 필요하기 때문에 정확한 변종을 혼동과 구별하기란 참으로 어려운 일이다.어떤 프로토콜을 상상할 수 있을 것이다: 제안된 바이올린들은 지식이 있는 사람들 사이에 어느 정도 합의가 이루어질 때까지 궁지에 몰릴 수 있다. 하지만 어떻게 이것이 정리될 수 있을까?그것은 "누구나 편집할 수 있다"와 직접적으로 반대된다.코드를 먼저 테스트해 달라는 애처로운 요청을 할 수 있지만 테스트 자체가 큰 주제고 전문가뿐 아니라 피들앤런 타입도 교정이 정확해 테스트가 필요 없다는 것을 알고 있다.(나 자신도 그런 실수를 저질렀다, ahem) 반대로, 가능한 모든 변형이 분류되고 상호 참조되는 대규모 토론은 곧 파탄날 것 같다(노출 지점이 더 많다), 또한 단순한 알고리즘에 대해 불필요하게 장황한 것이라고 공격한다.예제 코드 조각을 분리하는 것은 코드 조각과 관련된 설명이 분리될 수 있다는 것을 의미하지만 도움이 될 것이다.NickyMcLean (talk) 05:38, 2008년 7월 18일 (UTC)[응답]

테스트는 테스트하기 위해 반드시 실제 언어로 번역되어야 하는 유사문제의 경우 훨씬 더 큰 문제로, 테스트가 모든 버그를 감지하지는 않는다.이 간단한 코드는 수동 검사로 확인할 수 있지만, 드라이브 바이 에디터들이 하지 않는 것은 세심한 조사가 필요하다.'조심해, 이 코드는 이미 맞는 것 같아!' '토크페이지에서 어떤 변화라도 먼저 논의해 달라'는 댓글을 달기만 하는 구태의연한 접근법이 있지만 별 차이가 없어 보인다.논의되지 않은 코드 변경 사항을 되돌리는 스탠딩 관행이 있을 수 있지만, 그것은 그다지 위키적이지 않고 다른 정책과 모순될 수도 있다.

내가 템플릿 접근법으로 볼 수 있는 유일한 문제는 편집자들이 주요 기사를 추가할 수 있지만 그들의 감시 목록에 템플릿을 추가할 수는 없다는 것이다; 기술적 해결책이 최선일 것이다. 그러나 지금 나는 이것이 전도에 적절하게 다뤄질 수 있다고 생각한다. (누가 기사를 편집하고 대화를 나누는지를 보고 그들에게 통지서를 보내는 것을 보는 것.

다양성의 경우, 각 템플릿이 하나의 기사에만 사용되며 적어도 한 명의 관심 있는 편집자가 설명 변경에 맞춰 템플릿을 업데이트하는 방법을 알고 있는 한, 나는 거기에 문제가 있을 것으로 예상하지 않는다.

적은 수의 기사로 이 문제를 시험해 보고 어떻게 되는지 보는 것이 도움이 될 수도 있지 않을까?2008년 7월 18일 (UTC) 08:17 (답)

이것이 문제라면, 나는 그것들을 템플릿으로 옮기고 그것들을 보호하는 것을 지지할 것이다. (그것들이 정확하다면, 그것들을 편집해야 할 많은 이유가 있을 수 없다.)주요 문제는 템플리트 변경사항이 아티클 변경사항보다 훨씬 덜 모니터링되고 변조된 템플리트는 새로운 사용자/리더들이 찾고 수정하기가 훨씬 더 어렵다는 것이다.Mr.Z-man 17:22, 2008년 7월 19일 (UTC)[응답]

보호는 잘 될 수 있지만, 나는 선제적인 보호는 보호 정책에 위배된다고 믿는다.추가적인 숙고 끝에 템플릿이 면밀히 모니터링되도록 하기 위한 나의 새로운 계획이 있다.코드 샘플이 템플릿으로 옮겨지는 퀵소트 기사부터 시작하겠다.이 템플릿을 시청할 수 있는 링크가 Talk의 맨 위에 추가된다.Quicksort, 그리고 이 모든 템플릿들은 범주로 들어갈 것이다; 관련된 변경 링크를 사용하여 코드 템플릿의 변경사항을 구체적으로 볼 수 있다.이 템플릿에는 워치리스트에 눈에 띄도록 하기 위해 이름에 모든 CAPS가 포함될 것이다.우리는 이 실험이 어떻게 되는지 볼 것이다.Dcoetzee 01:25, 2008년 7월 20일 (UTC)[응답]

설명 페이지 경고에 연결

기사의 링크를 클릭해 디스큐 페이지로 끌려가는 것은 상당히 성가신 일이며, 특히 연계를 의도한 기사가 특히 불명확하여 디스큐에 포함되지 않는 경우(이는 일반적으로 디스큐 페이지에 (해제) 라벨이 붙어 있지 않을 때 문제가 된다.나는 누군가가 기사에 설명 페이지에 링크를 추가하려고 할 때마다 변경을 마무리하기 전에 설명 페이지에 추가된 링크가 있다는 경고가 나와야 한다고 제안한다.-링크 (대화) 2008년 7월 19일 (UTC) 12:56 [응답]

당신은 소프트웨어 변화가 필요할 것이고, 기사가 저장될 때마다 문제가 생기게 될 것인데, 이것은 당신이 종종 디컴백 페이지가 서브스크립스를 보관하는 장소로 사용된다고 생각할 때 골칫거리가 될 것이다.Geni 14:26, 2008년 7월 19일 (UTC)[응답]

무엇이 될 것(를) 있게 IRC로봇을 돌며[동음 이의 링크] 같은 각 해당( 잘못된)wikilink면서, 그리고/혹은 편집자들은 동음 이의 페이지로 모든 관계를 노란 색 같은 다른 색깔-또는 아마도 노란 배경을 추가할 가능성이 선택할 수 있(b) 용품에 있는 태그를 갈(그때 편집자들 기사에 wikilinks을 적절히 끓여라을 수 있을까 도움이 될 것이다시사회에 Ee은 월.ey는 기사가 아닌 설명 페이지로 연결된다.-- 존 브로턴 (리틀링) 2008년 7월 20일 (UTC) 13:05 [응답]

그것은 아마 잘 먹히겠지만, 경고 시스템은 그것과 함께 작동될 것이다.그러나 지니가 제안한 대로 편집을 할 때마다 경고가 나오는 것이 아니라 링크가 추가될 때만 경고가 나온다.그리고 물론 템플릿과 함께 추가된 DAB 링크는 제외될 것이다. 경고를 유발하지는 않을 것이다.-링크 (대화) 2008년 7월 20일 (UTC) 13:31, 응답 [응답]

노란색 배경을 추가하는 사용자 스크립트가 이미 있어. DAB를 나타내는 범주가 누락된 경우 스크립트의 토크 페이지 또는 내 토크 페이지에 알려줘.나는 그것이 어떻게 기계로 바뀔 수 있는지 모르겠다.그러한 봇의 경우, 누군가가 명시적으로 설명 페이지(예: 해트노트, "See another" 섹션, 기사가 DAB에 연결하고자 하는 드문 경우)를 무시하도록 프로그래밍되어야 할 것이다.Anomie⚔ 14:20, 2008년 7월 20일 (UTC)[응답]

위키백과(동음이의)와 같이 불분명한 단어를 포함하는 DAB 링크는 무시하도록 프로그래밍될 수 있다. 의도치 않게 연결될 가능성은 낮다.문제는 코버스와 같이 라벨이 없는 DAB 페이지다.-링크 (대화) 15:09, 2008년 7월 20일 (UTC)[응답]

그것이 바로 그 이유(WP에서 논의된 바와 같이:VPP#ALL disabigation 페이지를 종료(disabigation)하려면 disabigation 페이지 Corvus가 정말로 Corvus로 리디렉션되어야 한다(disbigation).그렇다면 위키링크 오류를 알아내는 것은 거의 사소한 일이다 - 그것들은 단순히 제목에 "(해체)"가 있는 페이지로 리디렉션되는 페이지를 가리키는 위키링크일 뿐이다.

기존 자바스크립트를 가젯으로 바꾸는 것에 대해서는 단점이 보이지 않는다.(가젯에 대한 전체 정보는 WP:EIW#Gadget.) -- John Brown (바닷컴) 16:15, 2008년 7월 20일 (UTC)[응답하라]

유전자, 해부학, 생리학 위키의 형식에 대한 토론 그룹 구성 제안

친애하는 독자 분께:

나는 신경조영술과 신경생리학에 종사하고 있는 다른 WIKI 사용자들을 찾고 싶었는데, 그들은 유전자 기사뿐만 아니라 신경조영학적 구조와 신경생리학적 메커니즘(세포와 세포군 수준에서)에 대한 토론 그룹이나 포럼을 구성하기를 원했다.

내 이메일을 보내거나 이 토론 스레드에 추가하십시오.얼마든지 나를 속일 수 있어라.내 이메일 주소를 여기에 적어야 할지 모르겠어.위키 진행자/편집자가 제안하면 다음 직책에 오를 수 있다.

PS 유전자 데이터베이스, 돌연변이 데이터베이스(OAMI 등), 과학 기사 형식 사이의 브리지 형식에 대해 다른 사람과 함께 작업하기를 희망한다.사용자:메넬라우스2 (토크 · 기여) 17:10, 2008년 7월 19일 (UTC)[응답]

우선, 이메일 주소를 절대 올리지 마라.코멘트 뒤에 ~~~(4~연속)만 넣으면, 사용자 페이지가 연동되어 사람들이 연락할 수 있다.기사 형식은 일반적으로 "위키프로젝트"의 관할권에 맡겨지는데, 이 프로젝트에서 공통의 이해관계를 가진 사용자들이 그들의 노력을 조정할 수 있다.위키프로젝트 신경학이나 위키프로젝트 유전학 중 어느 것이 도움이 될 수도 있다."신경생리학"이나 "신경생리학"이 무슨 뜻인지 설명해 주시겠습니까?- Twas Now (토크 • 기여 • 이메일 ) 03:37, 2008년 7월 20일 (UTC)[응답]

고마워 - 내가 맞춤법을 고쳤어.위키프로젝트와 기사 형식에 대해 검토해 볼게.링크를 지적해줘서 고마워.My User Name is Menlaus2.

나는 그 프로젝트들을 미리 살펴봤지만 언급된 기사 형식을 발견하지 못했다.아마도 그들은 어딘가에 숨어 있거나 혹은 아직 프로젝트들이 그것에 대해 논의하지 않았는지도 모른다. (신경계 프로젝트는 꽤 젊기 때문에, 그들이 너무 많은 것을 확립하지 않은 것은 이해할 수 있다.)프로젝트 토크 페이지에서 기사 형식에 대한 토론을 제안하면 회원들은 아마 그것에 대해 이야기하기 시작할 것이다. - Twas Now (토크 • 기여 • 이메일 ) 11:51, 2008년 7월 20일 (UTC)[응답]

위키프로젝트(Wiki Project) 기사의 위치와 형식에 대한 내 질문을 위키백과의 대화로 임시로 옮겨 놓았다.위키프로젝트 신경과학.인용문이나 인용문 형식에 대해서도 몇 가지 자기 강의를 할 겁니다.

위키피디아 상단에 다음과 같이 적혀 있다.위키프로젝트 신경과학 "이 위키프로젝트는 비활동적인 것으로 생각된다." 하지만 그것은 실수일 수 있다.- Twas Now (토크 • 기여 • 이메일 ) 22:53, 2008년 7월 20일 (UTC)[응답]

서브아르티클

위키피디아 토크에서의 제안:"하위 기사" 시스템이 만들어지는 것은 "부모" 기사가 핵심 기준을 충족하면 모든 "자위" 기사는 독립적인 2차 출처를 갖는 기준에서 면제된다.예) 텔레비전 시리즈 Foo가 눈에 띄면, Foo의 모든 에피소드는 2차 출처가 없어도 자신의 기사를 가질 수 있다는 것이 인정된다.(그리고 잠재적으로 모든 문자, 플롯 장치, 몬스터, 위치, 캐치프레이즈...)

잘못된 지점에 게시된 경우, 거기에 대해 논의하십시오. 브레너맨 03:35, 2008년 7월 9일(UTC)[응답]

대개 하위 고문이 본문의 일부분이었을 테지만 길이로 인해 분리되었을 경우에 이런 일이 발생한다.다른 방식으로 말하면:기사가 40KB인 TV 프로그램이 있고, 매 회 20회 8시즌에 5KB의 독특한 내용을 담고 있다면, 각 + 템플릿에 5KB씩 160개, 각 100KB씩의 "시즌" 8개, 또는 360KB 1개의 메가 기사를 원하십니까?그것은 심지어 주요 등장인물들과 다른 주요 세계 아이템들을 다루는 기사들도 포함하지 않는다.개별 에피소드마다 각각 15, 50KB의 고유한 콘텐츠가 있다면 답변이 달라지겠는가?이것은 WP의 특별한 경우다.IAR, 그리고 대부분의 편집자들은 이러한 기사들이 AfD로 가서 조직 개편에 대한 토론을 강요할 경우 어떤 일이 일어날 것으로 생각하느냐에 따라 결정된다.잘 팔린 기사들에게, "군중의 재앙"은 받아들일 만한 합의 해결책을 만들어낸다.가볍게 넘어간 기사의 경우, 이것은 "내가 좋아하는 TV 쇼는 500개의 기사를 받을 자격이 있다"는 핑계가 될 수 있고, 수십 쌍의 사람들이 기사를 보고 재편성을 제안함으로써 문제가 재점화될 수 있다.기술 참고 사항:하위 조항에서 나는 당신이 이름이 아닌 내용에서 서브를 의미한다고 가정한다. 예를 들어, "시리즈NAME/에피소드네임"이 "시리즈NAME/에피소드네임"이 아닌 "에피소드네임 에피소드.후자는 본문 공간에서 전혀 사용되지 않는다. davidwr/(대화)/(기여)/(이메일) 14:20, 2008년 7월 9일 (UTC)[응답]

반대 하위 섹션은 별도의 항목으로 나누기 전에 신뢰할 수 있는 출처를 인용했어야 하며, 따라서 하위 섹션의 인용문은 새로운 조항으로 이어질 것이다.인용문이 없으면 부기문의 본문은 쉽게 검증할 수 없다.독창적인 연구를 둘러싼 음식 싸움 초대장. - 옐로데스크(토크) 02:07, 2008년 7월 12일 (UTC)[응답]

반대. WP:요약, 요약 대 주요 기사 상황을 설명하는 경우.출처를 정해야 하는 것은 본조(하조문이라고 하는 것)이지, 반대로 출처를 정해서는 안 된다.에마뉘엘름 (토크) 15:02, 2008년 7월 16일 (UTC)[응답]

반대한다. 많은 경우에 에마누엘렘의 논평이 적용된다.다른 분야에서는 "부분의 총합보다 큰 총합" 상황이 종종 발생한다. 예를 들어, TV 시리즈 "요약" 기사는 시리즈가 어떻게 구상되었고 왜 종결이 되었는지를 설명할 수 있으며, 관련 유기체 그룹에 관한 생물학 기사는 시리즈와 관련된 것으로 간주하는 것이 얼마나 타당한지를 논의해야 한다.어느 쪽이든 나는 어떤 종류의 자동이체/횡단/어느 쪽이든 어느 쪽이든 출처에 대한 사례를 보지 못한다.어떤 종류의 텍스트 상자에 자동으로 추출하는 시설, 즉 단순히 ref name="..."를 참조하는 것이 아니라 인용 세부사항을 모두 포함하는 기사에 사용되는 주요 인용구를 모두 포함하는 것을 고려할 가치가 있을 것이다.그렇게 되면, 특히 기사가 각각 몇 번씩 출처를 음프틴으로 사용한다면, 많은 시간을 절약할 수 있을 것이다. -- 필차 (토크) 13:05, 2008년 7월 21일 (UTC)[응답]

비활성 Wiki Project 재시작 요청

나보다 수학 교육을 잘 받은 일부 편집자와 전문 과학자(시간이 있다면, 그렇지 않다는 것을 깨닫는다)가 위키프로젝트 일반청중의 재활성화를 고려해 주었으면 한다. 69.140.152.55 (토크) 01:49, 2008년 6월 28일 (UTC)[응답]

---

합의에 도달할 수 있도록 보다 철저한 토론을 생성하기 위해 보관되지 않음.
이 통지 아래에 새 의견을 추가하십시오.고마워, 69.140.152.55 (토크) 00:59, 2008년 7월 22일 (UTC)[답글]

로그 및 이미지 감독

우리에게 정말 필요한 것은 오버사이터들이 이미지와 로그를 감시하는 능력이다.현재, 오버사이터는 로그나 이미지를 감독할 수 없고, 그것은 중대한 문제를 야기시킨다 - 사물의 이미지 측면에서, 개인 정보가 이미지에 추가되었을 때, 우리는 정말로 관리자가 그것들을 보지 않을 수 있는 능력이 필요하다.아동 포르노의 문제 또한 있다. 과거에 몇몇 관리자들이 그러한 이미지들을 봐야 했던 것은 그 이미지들이 지나치게 시력이 강하지 않았기 때문이며, 그것은 전혀 좋지 않다는 것을 알고 있다.로그 관점에서, Grawp은 현재 우리가 그것을 제거할 방법이 없다는 의미에 개인 정보를 로그에 넣는 것을 배웠다.분명히, revsdel은 오버사이터들이 이미지와 로그를 감독할 수 있게 만들 수도 있다 - 나는 그녀의 동의를 얻고 싶다. 그래야 개발자들이 revsdel을 가능한 한 빨리 구현하여 이미지와 로그가 지나치게 시야가 확보될 수 있도록 할 것이다.Ryan Postlethwaite 00:35, 2008년 7월 22일 (UTC)[응답]

좋아.그것이 가능하다면, 나는 이것을 전적으로 지지한다; 그것은 많은 문제를 끝낼 것이다.PeterSymonds (토크) 2008년 7월 22일 00:42 (UTC)[응답]

이미지 감독 요청은 bugzilla:8196을 참조하십시오.작업하고 있다.2008년 7월 22일 (UTC) Al Toli^talk 00:58[응답]

글쎄, 의견 일치가 그렇게 중요한 문제에 대한 합의를 서두를 수도 있을 거야.Ryan Postlethwaite 01:01, 2008년 7월 22일 (UTC)[응답]

오버사이터에게 더 이상 힘을 주고 싶지 않아.2008년 7월 22일(UTC) Beam 00:53[응답]

하지만 그들은 법적으로 문제가 있는 개정을 감독할 수 있는 신뢰의 위치에 놓여 있다.게다가, 그것들은 재단에 확인된다.만약 우리가 그들에게 그것을 주지 않는다면, 우리는 그것을 다른 사람에게 줄 것인가?특정한 이미지와 로그는 때때로 지나친 시력을 필요로 하기 때문에, 누군가 더 나은 제안을 하지 않는 한, 오버래이터들은 완벽한 선택처럼 보인다.PeterSymonds (토크) 2008년 7월 22일 00:59 (UTC)[응답]

미국 내에서 단지 소유하는 것이 불법인 이미지는 과시를 해야 한다. 69.140.152.55 (대화) 00:55, 2008년 7월 22일 (UTC)[응답]

참 이상한 말이군.그럼 로그에 있는 개인 정보와 불법 이미지를 더 오랫동안 볼 수 있게 하자는 건가?2008년 7월 22일 (UTC) Al Toli 00:58[응답]

이것은 좋은 생각인 것 같다.그것은 오버사이터들에게 더 많은 힘을 주지 않고, 단지 그들이 그들의 기능을 제대로 수행하도록 허용한다. 즉, 관리자들조차 볼 수 없는 것들을 제거한다.케빈 (토크) 01:33, 2008년 7월 22일 (UTC)[응답]

이것은 정말 좋은 생각이고 나는 그것이 어떻게 더 많은 힘을 주는지 모르겠다.—Giggy 03:46, 2008년 7월 22일 (UTC)[응답]

나는 로그 엔트리를 바꾸는 것을 약간 경계하고 있다는 것을 인정한다(아마도 이 엔트리가 삭제되었다는 메모를 남길 수 있을까?) 다른 방법으로는 이러한 것들이 어떻게 유용한 도구가 될 수 있는지 직접 본 적이 있다.– 루나 산틴 (대화) 03:58, 2008년 7월 22일 (UTC)[응답]

지옥 같은 소리.일부 편집자들이 잘못된 행동을 은폐하기 위해 감독하는 것에 비추어 볼 때, 로그는 기간 동안 변조되어서는 안 된다.이름을 말하진 않겠지만, 여기 오래 있었던 사람들은 내가 누구를 말하는지 정확히 알고 있어.비통해, 정말 끔찍한 생각이야. --Dragon695 (대화) 04:34, 2008년 7월 22일 (UTC)[응답]

• 그것이 걱정스러운 문제지만, 나는 감독 일지가 그렇게 크지 않다고 믿는다.따라서 오버사이터는 툴의 사용을 꽤 쉽게 감시할 수 있을 것이다.어떤 학대가 일어나더라도 금방 들통이 날 것이다.남용될 가능성은 낮지만 시스템 관리자는 여전히 이를 뒤집을 수 있다; 지나치게 통찰력 있는 자료는 돌이킬 수 없을 정도로 손실되지 않는다.피터시몬드 (토크) 2008년 7월 22일 (UTC) 10:24 [응답]

Well Revision Delete는 enwiki에 꽤 유용할 것이다. 그러나 나는 이 권리를 가질 사람들에 의해 어떻게 사용될지 확실하지 않다. 즉, CU와 Oversatersater, 이전에 그것에 기록된 버그는 실제로 재고가 주어지지 않았지만 Revdel을 소개하는 것은 실제로 그것이 실행되기 전에 완전한 공동체 지원이 필요할 것이다. [rollback과 비슷한 것이다.] 기능과 로그 문제는 부분적으로 수정되었지만, Grawp이 입증한 바와 같이 여전히 잘 작동하지 않기 때문에 현재로선 revdel이 유일한 옵션이다...---Cometstyles 04:52, 2008년 7월 22일 (UTC)[응답]

나는 감시에 대한 책임감이 완전히 결여되어 있는 것에 대해 결코 편하지 않았다."이 사용자의 로그에서 두 개의 로그 항목이 제거되었다" 또는 "이 페이지의 삭제된 세 개의 수정본이 숨겨져 있다"는 간단한 내용만으로도 충분할 것이다.현재 상태로는, 감시는 기억 구멍과 매우 유사하다. --카르닐도 (토크) 08:31, 2008년 7월 22일 (UTC)[응답]

카르닐도에 동의하는 경향이 있다.또한 과대분열 로그는 재단의 유급 직원이 감사하는 방식으로 수행한다는 아이디어를 탐구하고자 한다.이 직책에 대한 대가를 지불하기 위해서 나는 누군가가 더 나은 생각을 하지 않는 한 검색 페이지에 광고를 허용하도록 제안할 것이다.분명히 그 제안은 그 생각을 없앨 것이다. 하지만 어느 시점에서는 우리는 수익 선택권과 높은 법적 책임을 가진 작업에 대한 유급 노동력의 소싱을 탐구해야 할 것이다.HiddingT 10:59, 2008년 7월 22일 (UTC)[응답]

브리온 바이버는 이미 이 일을 할 수 있는 능력을 가진 유급 직원이기 때문에 그것은 인기가 없을 뿐만 아니라 중복될 것이다.— CharlotteWebb 19:12, 2008년 7월 22일 (UTC)[응답]

체크유저와 같은 모든 오버래이터는 18세 이상의 재단에 의해 확인되며 그들의 행동에 대해 전적으로 책임을 진다.감시에 대한 책임감이 부족함이 없다.남용되면 제거된다.모든 과시 편집은 검색이 가능하며, 로그는 짧기 때문에 다른 사람이 쉽게 모니터링할 수 있다.재단에 부여된 모든 자격증들을 면밀히 조사하여 위키피디아에 대한 광고는 좋은 생각이 아니라는 점을 감안할 때 유급직은 그다지 필요하지 않다.아동 포르노와 같은 이미지로, 관리자가 그것을 가로지르지 않기를 바랄 뿐이다.비관리자에게 DeletedEdits의 도입이 제안됨에 따라, 이것은 더욱 위험하다.게다가, 성적 요약이나 개인 정보가 포함된 로그는 삭제되어야 할 것이며, 위키피디아가 빠른 속도로 성장함에 따라, 그 필요성은 증가할 것이다.PeterSymonds(대화) 11:37, 2008년 7월 22일 (UTC)[응답하라]

카르닐리도와 마찬가지로 로그의 감독에도 최소한 약간의 가시성과 투명성(아이론적으로 충분히)이 있어야 한다.그것은 잠재적으로 남용될 수 있지만, 대부분의 책임이 위의 PeterSymonds에 의해 설명되는, 책임적인 조치로는, 이것은 큰 문제가 아닐 수도 있다.첫 번째 요점을 언급한다면, 그것은 상당히 좋은 생각일 것이다. 그러나 나는 대부분의 감독 위원들이 그러한 조치의 성격으로 인해 전적으로 과소평가 로그에 만족하게 될 것이라고 생각해서는 안 된다.루젯 (logs) 13:28, 2008년 7월 22일 (UTC)[응답]

이미지, 삭제 로그, 보호 로그 또는 페이지 이동 로그에 대한 문제는 없지만, 블록 로그가 남용될 가능성이 높고 개인 정보에 대한 일반적인 위험성이 낮기 때문에 블록 로그를 지나치게 주의해서는 안 된다고 생각한다.MBisanz 13:44, 2008년 7월 22일 (UTC)[응답]

만약 오버세이터가 그들의 권리를 남용하고 있다면, RfA를 시작해야 한다.드래곤695가 학대의 증거를 제시하지 않는 한, 그들은 밀짚맨의 주장을 사용하고 있는 겁니다.Corvus cornix_talk 18:05, 2008년 7월 22일 (UTC)[응답]

나는 네가 RFAR을 말하는 것을 믿는다.감독 기록이 공개되지 않기 때문에 "/증거" 페이지에 대한 자료를 얻기가 매우 어려울 것이다.신은 미지의 정당에 대해 중재를 요청하는 바보를 효과적으로 들어주는 것을 돕는다.감시의 감독 부족이 실수인지 아닌지 스스로 결정할 수 있다.— CharlotteWebb 19:31, 2008년 7월 22일 (UTC)[응답]

나의 불만사항은 (아마도) 다른 시점의 완전한 데이터베이스 덤프를 비교함으로써 (아마도) 제외하고 일반 사용자가 자신의 권리를 남용하고 있는지 알 수 없다는 것이다.오버세이터는 사용자를 "무인"으로 선언하고 차단하고 블록 로그를 감독하고 편집 내용을 감독할 수 있으며, 일반 사용자가 계정을 만들었지만 사용하지 않은 사람에게 이 사실을 알 수 있는 방법은 없을 것이다. --카닐도(토크) 19:51, 2008년 7월 22일 (UTC)[응답]

이 실 전체는 좀 바보같다.그 소프트웨어는 이미 작성되었다. 그것은 단순히 활성화되어 있지 않다.어느 시점에서는 드래곤695나 다른 누군가가 그것을 불쾌하게 여기든 말든 그것은 될 것이다.Corvus:RfA가 아닌 RfAr를 말하는 거지? : - ) --MZMcBrid (대화) 18:29, 2008년 7월 22일 (UTC)[응답]

어, 그래, 그거.:) Corvus cornix_talk 18:56, 2008년 7월 22일 (UTC)[응답]

아티클 및 템플릿 네임스페이스의 요약 필수 편집

문서 네임스페이스와 템플릿 네임스페이스의 모든 편집에 대해 요약 편집이 필수적일 것을 제안한다.기술적 장애물을 무시한 채, 커뮤니티는 이것에 대해 어떻게 생각하는가? - RockMFR 02:23, 2008년 7월 19일 (UTC)[응답]

나는 그것이 정말 그렇게 유용한지 의심스럽다.요약을 쓰고 싶지 않은 사람들은 의미 없는 것을 쓰기 시작할 것이다.예, 유용한 요약도 어느 정도 증가하겠지만, 단점은 많은 사람들의 반감을 사게 된다는 것이다. --트로바토어 (토크) 03:59, 2008년 7월 19일 (UTC)[응답]

요약 편집은 편집이 설명해야 할 때를 위한 것으로, 항상은 아니다.칠음 04:52, 2008년 7월 19일 (UTC)[응답]

나는 종종 어떤 것을 반복적으로, 또는 일상적으로 (샌드박스처럼) 편집할 때 요약을 100%로 유지하기 위해 .를 사용한다.별 차이가 없을 것 같고, 요약이 좋기는 하지만, 사람들이 그들의 작품이나 기사의 질을 실제로 바꾸지는 않기 때문에, 그것들을 추가하도록 강요당해서는 안 된다고 생각한다.~ JohnnyMrNinja 06:38, 2008년 7월 19일 (UTC)[응답]

하지만 나는 우리가 자동 요약의 양을 늘릴 수 있는지 궁금하다. 좀 더 쉽게 하기 위해서 말이다."추가된 이미지" 또는 "제거된 섹션"/"추가 섹션" ect와 같은 항목.단지 히스토리를 볼 때 도움을 주기 위해, 많은 IP가 편집하는 기사의 일부로서, 어떤 일이 일어났는지 전혀 알 수 없기 때문에 매우 어려울 수 있다. --acrocuse알렉스: 2008년 7월 19일 08:31 (UTC)[응답하라]

난 알렉스의 아이디어가 더 좋아.소프트웨어 캠이 자동으로 "its -> it is"와 같은 요약을 넣는다면 매우 좋을 것이다.때로는 너무 게을러서 그런 요약을 쓸 수 없을 때가 있는데, 특히 같은 종류의 편집을 일괄적으로 하고 있을 때는. -- 다쿠(토크) 01:45, 2008년 7월 20일 (UTC)[응답]

타쿠, 만약 당신이 대량으로 같은 종류의 편집을 한다면, 당신은 그러한 대량 편집을 용이하게 하는 AutoWikiBrowser에 가입하는 것을 고려할 수 있고, 편집 요약을 자동으로 채울 것이다.- Twas Now (토크 • 기여 • 이메일 ) 22:57, 2008년 7월 20일 (UTC)[응답]

더 자동 생성되는 메시지라는 생각은 훌륭한 것이지만, 어떻게 위키 소프트웨어로 그렇게 할 수 있을지 모르겠다.혹시 브라우저 플러그인 같은 거?~ 2008년 7월 23일 (UTC) 조니미르닌자 20:35 [응답]

파이어폭스는 내가 입력한 편집 요약을 기억한다는 것을 알게 되었다. --Pwnage8 (대화) 23:19, 2008년 7월 20일 (UTC)[응답]

나는 누군가에게 어떤 것을 하도록 강요하는 생각은 싫지만, 아마도 나는 Special의 기본값을 만드는 것에 동의할 것이다.Preferences>editing>blank edit summary>true를 입력하면 도움이 될 수 있다.프리프(pref)를 가지고 있지 않은 IP를 위해, 아마도 그들에게 물어보는 것 또한 디폴트(default)될 수 있다.편집을 시작할 때는 선호 설정이 존재하는지조차 몰랐지만, 일단 그것에 대해 알게 되면 나는 즉시 그것을 true로 설정했다.생각해봐, %%-SYKKO-% (나에게 말 걸기) 01:56, 2008년 7월 22일 (UTC)[응답하라]

모든 사람에게 디폴트로 설정하는 것은 좋은 생각이다.그것은 아무에게도 어떤 것도 강요하지 않고, 무겁게 암시할 것이다.내가 처음 편집을 시작했을 때 나는 그의 옵션이 짜증났다고 느꼈지만, 지금은 그것을 결코 보지 못한다. (나는 항상 요약을 편집하기 때문에)~ 2008년 7월 23일 (UTC) 조니미르닌자 20:35 [응답]

나는 그 기능이 잘 작동하지 않는다고 생각한다.칠음 20:38, 2008년 7월 23일 (UTC)[응답]

구체적? -- 존 브로튼 (식용차) 2008년 7월 23일 (UTC) 23:05, 응답

편집 요약을 입력하지 않으면 대개 자동 편집 요약을 입력하지 않는다.칠음 23:53, 2008년 7월 23일 (UTC)[응답]

메인 페이지 FA 트윗을 위한 트위터 계정

오늘의 메인 페이지 FA를 방송하기 위해 트위터 계정을 만들었다.왜 참여해야 하는지, 그리고 어떻게 참여해야 하는지에 대해 자세히 알아보십시오.스티븐 월링 (토크) 01:21, 2008년 7월 24일 (UTC)[응답]

오버링 보고서 봇

기사를 스캔하고, 중복 링크를 확인한 다음, 해당 기사의 토크 페이지(필요한 경우)에 오버링킹 보고서를 추가할 수 있는 봇을 사용하고 싶다.이것은 페이지의 유지 관리자들이 불필요한 중복 링크를 도태할 수 있게 하는 동시에, 그 과정에서 인간의 판단도 가능하게 할 것이다.이런 도구를 조립하는 데 관심 있는 사람 있어?혹시 홍보과정의 일부가 될 수도 있지 않을까?감사합니다.—RJH (대화) 21:42, 2008년 7월 17일 (UTC)[응답]

좋은 생각일 것 같은데, 아마도 봇 대신에 FAS 도구와 같은 툴서버 스크립트로 하는 것이 가장 좋을 것 같아.나는 그것이 그렇게 어렵지 않을 것이라고 생각한다: 사람들은 페이지에 위키링크의 목록을 생성하고, 각 섹션에 대해 개별적인 확인을 하고, 그리고 나서 각각의 인접한 섹션 쌍에 대해 각 섹션에 대해 발견된 세트들의 조합을 통해 같은 섹션이나 인접 섹션에 있는 것을 메모하고 강조할 수 있다.그것은 아마도 자바스크립트로도 이루어질 수 있을 것이다.주요 요령은 리디렉션이 이미 강조되어 있는 것에 의해 약간 더 쉬워지겠지만 리디렉션을 확인하는 것이다.class="mw-redirect" 그래서 그 링크들만이 확인될 필요가 있을 것이다.나는 아마도 애플스크립트에서 프로토타입을 쉽게 만들 수 있을 것이다. 하지만 그것은 대부분의 사람들에게 유용하지 않을 것이다.내가 아직 자바스크립트를 충분히 이해하지 못하는 것이 유감스럽거나 혹은 언어가 팝업과 같은 것을 만들기에 충분한 기능을 가지고 있다는 것을 고려하면 이것은 아마도 창조하기에 미풍일 것이다.{{Nihiltrestalk log}}{{Nihiltrestalk log}} 23:12, 2008년 7월 17일 (UTC)[응답]

조심해서 밟으십시오...한 항목의 한 예가 설명이 필요할 수 있고 이전 사례와 거리가 먼 긴 기사에서는 이중 링크가 금지되지 않는다.또한 선행 리디렉션 섹션으로 연결되는 기사에서는 이전 섹션을 읽지 않기 때문에 많은 링크가 반복되어야 한다.나는 제안된 과정(인간이 점검할 보고서)에 동의하며, 비록 너무 많은 자동화가 잘못 처리될 경우 대규모 삼림 벌채의 원인이 될 수 있지만, 나는 공동체에 대한 믿음이 있다.나는 더 자세한 내용을 볼 때까지 판단을 유보한다.

그래, 이게 내가 위키링크를 제거하기 위한 대본보다는 그냥 보고서를 요청했던 이유야.나는 어떤 연결고리를 제거해야 할지를 결정할 때 인간의 판단력이 중요하다는 것을 알고 있고, 보고서는 그것을 설명할 수 있다.반면에, 소프트웨어로 쉽게 할 수 있는 것, 즉 긴 글에서 중복된 링크를 찾아내려고 하는 것은 왕실의 고통이다.(이 시점에서 페이지 소스의 다운로드된 복사본에서 실행할 수 있는 나만의 perl 스크립트를 작성하는 것만으로 매우 유혹적이다.)고마워요.—RJH (대화) 15:33, 2008년 7월 18일 (UTC)[응답]

링크 취급에 대한 내 작은 아이디어는 더 이상 논쟁의 여지가 없는...(내가 너무 노골적으로 파고들지 않았으면 좋겠다; 나는 이것이 관련된 주제라고 생각한다.)"런던"은 런던을 전시하고 런던으로 리디렉션되는 영국 런던으로 연결된다.다시 말해 쓸모없는 합병증이다. 나는 그것들 중 많은 것을 보아왔다. 대개는 움직임의 결과였다.나는 그것이 자동적으로 "런던"으로 변환될 수 있을지 궁금하다.2008년 7월 17일 (UTC) 23:50의 공작 월섬[응답]

위키백과를 읽으십시오.도구/내비게이션 팝업/수정 리디렉션에 대해(기본적으로 이중 리디렉션인 경우가 아니면 안 함) - 존 브레본(리듬링) 22:59, 2008년 7월 23일(UTC)[응답]

즉, 다른 이유(예: 내용 추가)로 페이지를 편집하는 경우가 아니면 이러한 리디렉션을 수정하지 마십시오.리디렉션은 서버에서 효율적으로 처리하며, 이를 사전에 수정할 이유가 없다.— 칼 (CBM · talk) 23:05, 2008년 7월 23일 (UTC)[응답]

아, 그 얘기 들었어...그리고 나는 편집이 실제로 유용할 수 있지 않는 한 해서는 안 되는 몇 가지 종류의 변경이 있다는 것에 동의한다. (내용은 추가하지 않지만 복사 편집은 한다; 때때로 나는 엠 대시 주위의 공간을 제거하기 위해 내가 고칠 수 있는 어떤 실수에 대한 기사를 꼼꼼하게 점검한다.그것은 사실 철저한 카피 편집의 주요한 동기부여가 된다. :-D) 이런 종류의 연결고리가 대단히 어리석다고 생각할 뿐이다.

아, 음, 그건 수동 편집이 있는 것 같은데...링크를 확인할 수 있는 팝업이 있어서 다행이야.조언해 주셔서 감사합니다, 신사 여러분.2008년 7월 26일 (UTC) 00:12의 공작 월섬[응답]

'새 섹션'을 굵게 표시하고 '이 페이지 편집'을 정기적으로 수행

자주 사용하는 대규모 토론 페이지를 편집하는 현명한 방법은 관심 섹션 옆에 있는 '새 섹션' 또는 '편집' 링크를 클릭하는 것이다.그렇지 않으면 편집 창 내에서 관련 섹션을 검색하여 편집 충돌의 공포를 다루어야 한다.현재 Science Reference Desk 등 페이지에서는 '이 페이지 편집' 링크가 굵고 '새 섹션' 링크가 규칙적이어서, 내가 일반 링크를 원할 때 우연히 굵은 링크에 끌리게 된다.실제로, 나는 참조 데스크의 '이 페이지 편집' 버튼을 필요로 하는 사람은 거의 없을 것이라고 생각한다.나는 '새로운 섹션' 링크는 대담하게 만들고 '이 페이지 편집' 링크는 정기적으로 만들어 사람들이 둘 중 아마도 올바른 링크에 끌리도록 제안한다. ---- 감자 사업

합리적인 것 같지만...이것은 한 페이지에 할 수 있을까?월텀, 더 듀크

__NEWSectionLINK__이(가) 있는 모든 토크 페이지와 페이지에 대해 해보는 것은 어떨까?- FISDOF9

그거 좋은 생각인 것 같아.우리가 여기서 충분한 관심을 받지 못한 것 같아 안타깝다.난 거의 일주일 동안 이 일을 잊고 있었어...바보 펌프.월텀, 더 듀크

이것은 진정한 단점이 없는 훌륭한 생각이다.아무도 타임스탬프를 가지고 있지 않아서 이 주제가 여기에 얼마나 오래 있었는지 모르겠다...이상해~ 조니미르닌자(나도 안 쓸게)

내가 타임 스탬프를 추가한 것을 분명히 기억한다면 이상하다.누군가 이 실이 보관되는 것을 막기 위해 그것들을 제거했을 것이다.2008년 7월 23일(UTC) 19:52의 공작 월섬[응답]

__NEWSectionLINK__이(가) 있는 페이지를 대상으로 지정하려면 MediaWiki 소프트웨어를 변경해야 한다.나는 버그 리포트를 제출하고 이것을 특징으로 요청하는 것을 제안한다.—2008년 7월 19일 06:48, 점 기억[응답]

이것은 개별 미디어위키 메시지, 즉 자바스크립트로 할 수 있다.미디어위키를 변경할 필요가 없다.Soxred 93 12:05, 2008년 7월 20일 (UTC)[응답]

MediaWiki 메시지(내 생각대로라면)가 가장 좋은 해결책이 될 것이다. 모든 사람에게 유용한 기능은 개별 스크립트에 의존해서는 안 된다.2008년 7월 23일(UTC) 19:52의 공작 월섬[응답]

새로운 섹션을 볼드체로 만드는 것은 CSS - 새로운 섹션의 존재 여부에 따라 편집이 아닌 편집은 할 수 없다. --Random832 (contracts) 20:19, 2008년 7월 23일 (UTC)[응답]

자, 누군가가 모든 대화 페이지에서 "새로운 섹션" 탭(그리고 "이 페이지 편집"을 풀어서 이에 대한 합의가 있는지 확인할 수 있도록)에 대한 여론조사를 시작하길 원한다는군. -- 존 브로튼 (식별자) 23:03, 2008년 7월 23일 (UTC)[응답]

모든 대화 페이지?봇이 할 수 없을까? --Seans Potter Business 17:45, 2008년 7월 25일 (UTC)[응답]

절전 모드 자동 확인

오늘 최근 페이지 이동 반달리즘의 일부를 눈치채고 있는 동안, 나는 자동 확인 상태를 얻기 위해 첫 10번의 편집에서 그들이 무엇을 했는지를 보기로 결심했다.이 계정은 페이지 이동 기능을 사용하기 전에 두 번의 편집만 있을 뿐이며, 첫 번째 편집은 7월 4일에 이루어졌다.자동 확인 설정이 변경되기 전에 계정이 존재했고, 4일 이상 존재했을 때 플래그를 받은 것 같아.

가능한 경우라면 자동 확인 설정이 변경되기 전에 편집하지 않은 모든 계정에는 자동 확인 플래그가 제거되도록 제안한다.이것이 가능하다고 가정하면, 그것을 하기 위해 개발자가 필요하겠지만, 나는 버그 리포트를 작성하기 전에 커뮤니티에 다시 확인해보자는 제안을 여기에 게시할 것이라고 생각했다. -- 네드 스콧 02:58, 2008년 7월 22일 (UTC)[답글]

페이지는 움직이지 않았다.편집 요약을 움직임처럼 보이게 꾸며 놓았다.자동 확증되는 것은 현행 규칙에 의해 결정되기 때문에, 많은 기존 계정들이 규칙을 변경할 때 그들의 지위를 잃었다.프라임헌터 (대화) 03:32, 2008년 7월 22일 (UTC)[응답]

적어도 일부는 실제 페이지 이동이었기 때문에, 프라임, 당신은 착각한 것 같다.8개의 삭제된 기여가 보이지 않는 한, 이 계정은 이전 설정에 따라 자동 확인 상태가 된다. -- 네드 스콧 03:45, 2008년 7월 22일 (UTC)[응답]

나는 두 번 편집한 후에 그 주장된 움직임을 언급하고 있었다.첫 번째 실제 움직임은 7개의 가시적, 3개의 삭제된 후에 이루어졌다.프라임헌터 (대화) 03:54, 2008년 7월 22일 (UTC)[응답]

눈에 보이는 편집의 3번부터 7번은 움직임을 모방한 편집 요약으로 더미 편집이었다.7월 4일 3건의 편집이 삭제되었다.프라임헌터 (대화) 04:00, 2008년 7월 22일 (UTC)[응답]

아아. -- 네드 스콧 04:45, 2008년 7월 22일 (UTC)[응답]

지지하다.네가 애초에 언급했던 것이 아니라면, 흥정/그로우프 헛소리에도 조금 도움이 될 거야.Tan 39 39 03:33, 2008년 7월 22일 (UTC)[응답]

로그에 2008년 7월 4일에 계정이 생성되었다는 것을 알 수 있기 때문에 지금 나는 더욱 혼란스럽다.관련된 기여는 삭제해야 한다. -- 네드 스콧 03:48, 2008년 7월 22일 (UTC)[응답]

《건포도》는 7월 3일 3건의 기고문 삭제, 7월 3일 2건의 비삭제 댓글 삭제, 7월 21일 5건의 '가짜이브' 편집이 있었는데, 첫 번째 리얼 이삿짐 이전 총 10건의 편집이 있었다. --B (토크) 04:07, 2008년 7월 22일 (UTC)[응답]

그래도 네가 데이트에 대해 무슨 말을 하는지 알겠어.차이점은 타임존이다.이 계좌는 7월 3일 동부 표준시로 21시 42분에 만들어졌다.삭제된 편집은 22:21과 22:22, 22:25이었다.모든 시간은 동양(UTC-5)이다. --B (대화) 04:09, 2008년 7월 22일 (UTC)[응답하라]

사실 7월 4일(UTC) 창설을 놓고 네드 스콧이 혼란에 빠진 이유는 시간대와 무관하지 않았다고 생각한다.오히려 그는 훨씬 이른 날짜에 자기 확인 요건이 제기되기 전에 계정을 만들었다고 당초 추측했기 때문이었다.프라임헌터 (대화) 04:15, 2008년 7월 22일 (UTC)[응답]

글쎄, 그 정도면 다 설명이 되는 것 같아. -- 네드 스콧 04:43, 2008년 7월 22일 (UTC)[응답하라]

사실, 위조된 것이 아니라 페이지를 옮겼지만 오토콘펌 설정은 4일 10 편집이며, 7월 4일에 계정이 생성되었지만, 그는 4일 후에 반달리즘을 시작하지는 않았다. 왜냐하면 그는 이전에 이것을 해왔고 계속해서 관리자들에게 "차단" 당했기 때문이다. 이제 그가 하는 일은 최소한 10일 이상 기다린 것이고, 이 경우, 18d가 된다.이상하게도 10개의 편집요건은 삭제된 편집요건들을 포함한다. 이런 식으로 그는 가짜 페이지를 만들고 그것에 대해 여러 개의 더미 편집을 함으로써 누구든지 자신이 새로운 사람이라고 생각하도록 쉽게 속일 수 있고, 관리자가 그것을 삭제하기를 자신 있게 기다릴 수 있다. 따라서 그의 기여는 편집한 것을 보여주지 않지만, 삭제된 편집은 10개의 편집요건만을 보여줄 것이다.그리고 아무도 그 계좌에 더 이상 관심을 갖지 않을 때, 그는... 간단하고...그러나 내가 본 새로운 경향은 그가 이제 CAPTCHAS를 사용하여 계정 이름을 만들고 대부분의 CAPTCHAS가 반복되기 때문에 계정 생성을 돕는 관리자가 이러한 추세를 쉽게 볼 수 있다는 것이다.--Cometstyles 05:03, 2008년 7월 22일 (UTC)[응답]

삭제된 편집 내용을 계산하지 않도록 오토콘펌을 변경해야 하는가? -- 임페라이터3733 (대화) 15:01, 2008년 7월 22일 (UTC)[응답]

나는 하지 말 것을 제안한다.이렇게 영리한 사람은 샌드박스나 사용자 페이지를 간단히 편집할 수 있다.단순성에는 이점이 있다 - "모든 편집"이라고 말하는 것이 더 쉬우며, 편집이 삭제될 때 자동 확증 및 자동 확증 사이를 왔다 갔다 하지 않으면 더 쉽다.그리고 그렇다, 현재의 시스템은 (삭제된 편집 내용을 볼 수 없는) 비관리 반달 파이터들을 혼동시킬 수 있지만, 우리의 자동 확인 과정에 또 다른 복잡성을 더하기 보다는 (필요에 따라) 반달 파이터들에게 알리는 것이 더 낫다고 생각한다. -- 존 브로턴 (비록한) 2008년 7월 15:15, (UTC) 24 (응답)

"이것은 블로그가 아니다" 태그를 사용하여 블로그 홍보

나는 "이것은 포럼이 아니다"는 것이 대부분의 경우에 그렇게 설득력이 있거나 관련이 없다고 생각한다.예를 들어, 사람들은 쉽게 규칙을 가로채지만 "Blah blah personal opposition blah blah POV blah, 여기 출처가 있고, 어떻게 기사를 개선할 것인가"라고 말한다. 즉, 그것을 부정적으로 보이게 하는 것은 어렵지 않지만 최소한 80%의 블로그가 되는 것이다.그래서 '이것은 블로그가 아니다'라는 블로그와 태그를 홍보하는 것이 더 목적적합하다. --Leradax (대화) 06:53, 2008년 7월 25일 (UTC)[응답]

음... 실제로 어떻게 하자고 제안하시는 겁니까? (그리고 '촉진'을 정의해 주시겠습니까, 그 단어를 사용하고 있는데, 내가 이해하는데 어려움을 겪고 있는 겁니까?) -- 존 브로튼 (리콜리제이션) (리콜리제이션) 22:33, 2008년 7월 25일 (UTC)[응답]

"리소스 포크"

종종 내가 기사를 연구할 때, 나는 즉시 필요하지 않지만 그 기사를 더 확장하는데 유용할 수 있는 관련 신뢰할 수 있는 자료들을 접하게 될 것이다.마찬가지로, WP별로 섹션을 제거하기 위해 기사를 다듬는 경우도 있다.중량 또는 WP:SUMENT 및 유용한 소스는 편집과 함께 삭제된다.

기사의 미래 작가들을 위한 자료의 목록일 뿐인 하위 페이지(토크 페이지와 유사)를 두는 것이 합리적일까?SDY (토크) 2008년 7월 20일 18:10 (UTC)[응답]

당신은 이것들을 "추가 읽기"라고 불리는 하단에 가까운 섹션에 포함할 수 있다.- Twas Now (토크 • 기여 • 이메일 ) 22:51, 2008년 7월 20일 (UTC)[응답]

종종 나는 그것들 중 꽤 많은 것들이 있는 사례들을 우연히 만나곤 한다. (예를 들어, PubMed 저널 검색) 그리고 긴 "추가 읽기" 섹션은 다소 번거로울 수 있다.나는 그것이 항상 대화 페이지에 올라갈 수 있다고 생각한다.SDY (토크) 23:55, 2008년 7월 20일 (UTC)[응답]

대화 페이지 또는 적절한 섹션에 다음과 같이 주석을 달 수 있다.

<!- 야다 야다, 여기 다른 유용한 자원이 있다: --> - Twas Now (토크 • 기여 • 이메일 ) 00:45, 2008년 7월 21일 (UTC)[응답]

또한 위의 하위 대화 페이지(예: Talk:Foo/LinkSubstance Links)를 사용하고 "LinkSubstance" 사용자 스크립트를 사용하여 해당 문서에 대한 액세스를 편리하게 조정하십시오.시간만 주어진다면 나는 그것을 쓰는 데 큰 어려움을 겪었을 것이다.:-) 예를 들어, 스크립트는 항목 목록을 표시하고 항목을 직접 추가하거나 제거하는 제어 기능을 제공하는 도구 상자에 "제안된 링크" 옵션을 추가할 수 있다. --_{tiny plastic} Grey Knight knight 07:57, 2008년 7월 21일 (UTC)[응답]

이것을 토크 페이지에 게시하는 것은 전혀 잘못된 것이 아니다; 대부분의 토크 페이지 논평은 훨씬 덜 실질적이다.나는 최근에 "페이지와 관련된 자원"이라는 제목의 섹션을 토크 페이지에 만들기 시작했다.II (t - c) 21:08, 2008년 7월 21일 (UTC)[응답]

SDY, 나는 이것이 좋은 생각이라고 생각해.그래, 물론이지, 이론적으로 이건 토크 페이지에 올려질 수 있어.물론, 그것을 토크 페이지에 올리는 것은 전혀 문제가 되지 않는다.하지만 그런 일은 일어나지 않는다.공통적이거나 보편적인 관행으로 자원 포크의 존재는 자원 리스트의 게시와 수집을 장려할 것이며, 이것은 기사 소싱에 엄청난 도움이 될 것이다!내가 생각할 수 있는 이 생각에 반대할 확실한 이유는 없다.Mr. IP (대화) 08:52, 2008년 7월 26일 (UTC)[응답]

위키백과 비밀번호 제한

계정을 만들거나 로그인하기 위한 위키피디아의 페이지는 "암호 강도" 기사와 연결된다.나는 다음과 같은 질문이 있다.

• 위키백과 비밀번호에 사용할 수 있는 모든 문자의 집합은 무엇인가? (그것은 문장 부호를 포함하고 있는가?그리스 문자?러시아 문자?아르메니아 문자?데바나가리 캐릭터?일본 문자?한국 문자? 수학 기호? 웹딩?윙딩?)
• 위키백과 비밀번호의 최대 허용 길이는 얼마인가? (한자가 라틴 문자만큼 세는가?)
• 위키피디아는 특정 문자 수 뒤에 비밀번호를 자르고 나머지는 무시하는가?
• 계정을 만들거나 로그인할 때 페이지에 이러한 질문에 대한 답변이 표시되지 않는 이유는?

-- 파장 (대화) 02:16, 2008년 7월 22일 (UTC)[응답]

이것은 실제로 제안 마을 펌프에는 속하지 않는다 - 아마도 헬프 데스크나 기술 마을 펌프에는 속하지 않는다. 하지만 어쨌든, 위키피디아에서는 이것에 대해 아무것도 찾을 수 없고, 미디어위키 사이트에서도 찾는데 어려움을 겪고 있다. 메타:파리채 열어놓지 말고 몇 가지 질문에 답하는 데 도움이 되겠지만 완전히는 안 된다.그러나 나는 몇 가지 질문에 대답할 수 있다: Mediawiki 소프트웨어는 너무 긴 비밀번호를 잘리지 않는다 - 만약 그렇다면 이것은 너무 긴 비밀번호를 입력하는 사람들에게 로그인을 매우 어렵게 만들 수 있기 때문에 시스템에 끔찍한 버그가 될 것이다.소프트웨어 또는 사이트 제한을 초과하는 항목을 입력하면 새 항목을 입력하라는 메시지가 표시되어야 한다.하지만 나는 한계가 무엇인지 잘 모르겠다.또한, 그 해답은 아무도 그것을 Mediawiki 인터페이스에 추가하지 않았기 때문에 계정 생성 페이지에 있지 않다. 아마도 다른 모든 사람들이 나만큼 해답을 찾는데 어려움을 겪고 있기 때문일 것이다.일단 그들이 그곳에 있게 되면, 아마도 누군가가 정확히 어떤 Mediawiki 페이지인지 알아내는 즉시 추가될 것이다. - 그들 중 극히 소수의 페이지들이 직관적으로 이름지어진다.허스폴드논^(t/a/c) 관리 02:57, 2008년 7월 22일 (UTC)[응답]

아마도 그것은 미디어위키에서 실행될 것이다.Signupend 또는 MediaWiki:팬시캡차-계정을 만드세요.소스를 조금 확인해보니 User:isValidPassword()는 최소 사이즈로만 체크한다.데이터베이스의 암호 필드는 "실제" 암호의 MD5 해시에 불과하므로, PHP의 최대 문자열 크기만이 실제 최대값이며, 기본값은 약 800만 문자로 되어 있다고 생각한다.그것은 매우 안전한 비밀번호가 될 것이다! --_{tiny plastic} 그레이 나이트⊖ 11:21, 2008년 7월 22일 (UTC)[응답]

최소 크기는$wgMinimalPasswordLength위키피디아에서는 8로 설정되어 있다고 생각한다.최소 사용량 확인strlen()하지만 나는 위키피디아가 UTF8 문자열을 사용하고 있다고 생각한다.mbstring.func_overload 중국어 대본이 있는 "fancy" 비밀번호조차도 각 문자만 1로 계산한다는 것을 의미한다._{tiny plastic} -- Grey Knight, 11:39, 2008년 7월 22일 (UTC)

가치에 대한 자세한 내용은 다음을 참조하십시오.슬라크는 토크에 다음과 같은 메시지(07:39, 2008년 3월 20일)[2]를 올렸다.암호 강도#위키백과 비밀번호 제한.

암호 강도가 최대인 키패스X 0.2.2(AutoType!이 포함된 새 버전 0.3.1!)를 사용하여 위키백과 암호를 변경했는데, 이 암호는 다음과 같은 옵션이 있다.

1000자 길이

대문자

소문자

숫자

특수 문자

화이트 스페이스

빼기

밑줄

상위 ANSI 문자

KeyPassX는 이러한 옵션으로 생성된 암호를 8,000비트 또는 12816비트 품질로 보고하며, 위키피디아가 이를 기쁘게 받아들였다.[슬라크의 메시지 끝]

-- 파장 (대화) 16:08, 2008년 7월 22일 (UTC)[응답]

MediaWiki가 그러한 패스워드를 수용하는 것은 사실이지만, 내부적으로 128비트(MD5)의 비트 값으로 해시되어 있다는 점은 주목할 필요가 있다.128비트보다 강력한 암호를 사용하면 해시 충돌이 발생하기 때문에 실제적인 요점은 없다.물론 인간이 외우고 타이핑할 수 있는 암호는 문자당 엔트로피가 상당히 낮은 경향이 있기 때문에 긴 암호를 허용하는 것은 여전히 유용하다.—일마리 카로넨 (대화) 07:52, 2008년 7월 23일 (UTC)[응답]

이 게시물을 읽은 후, 새로운 계정 양식에 비밀번호 강도 미터를 추가하는 스크립트를 만들기로 결정했다.비트 강도를 계산하는 대신 대부분의 미터와 같은 체크리스트를 사용하지 않는다.Common.js에서 집중 토론하고 있어— 디스펜서 00:32, 2008년 7월 27일 (UTC)[응답]

제안:전체 템플리트: 네임스페이스 보호

우리는 최근 템플릿에 대한 파괴 행위를 많이 겪고 있다. (WP의 실만 확인해 보십시오.A/I 등).우리가 가장 흔히 사용하는 템플릿 중 많은 것이 이미 영구적으로 보호되거나 "고위험 템플릿"으로 반자동화되었지만 여전히 많은 템플릿이 균열로 빠져나갔다.따라서, 나는 토론의 제안을 하고 싶다: 전체 템플릿 네임스페이스를 보호하는 것이 어떨까?

우리가 이것을 실행할 수 있는 두 가지 방법이 있다.

1. MediaWiki는 구성 변수 $wgNamespaceProtection을 가지고 있으며, 지정된 네임스페이스의 모든 페이지에 대한 최소 보호 수준을 설정하는 데 사용할 수 있다.기본적으로 비관리자가 MediaWiki: 네임스페이스를 편집하지 못하도록 하는 데만 사용되지만 Wikimedia sysadmins는 이를 사용하여 템플릿: 네임스페이스를 반비보호할 수 있다.
2. 위키피디아는 제목 블랙리스트의 연장선도 가지고 있는데, 이 연장선은 ''''라는 행을 추가함으로써 비슷한 효과를 얻을 수 있다.Template:.* <noedit autoconfirmed>미디어위키에게:제목 블랙리스트.이것은 해킹에 가깝겠지만, 시스템 관리자 도움 없이 지역 관리자에 의해 구현될 수 있고, 또한 더 세밀한 통제를 허용할 수도 있다.(특히 템플릿의 하위 페이지를 보호하기 위해 이 메커니즘을 사용할 것을 다른 곳에서 제안했었습니다.변환).

분명히, 이것은 신규 사용자나 등록되지 않은 사용자들이 템플릿을 합법적으로 변경하는 것을 막을 것이다. 그러나, 유용하게 템플릿을 편집할 수 있는 충분한 위키 경험을 가진 대부분의 사용자들은 아마도 자동 확인 요건을 통과해야 할 것이다.반대로, 나는 결심한 반달은 쉽게 계정을 미리 등록하고 반달리즘에 앞서 필요한 10개의 수정사항을 긁어모을 수 있다는 것을 알고 있다; 그러나 반절제술은 여전히 속도 위반의 역할을 할 것이고, 우리는 이미 우리가 하고 있는 것처럼 여전히 최고 위험의 템플릿을 완전히 보호할 수 있다.댓글로.또한 이 제안에 대해 다른 관련 포럼에 언제든지 알리십시오.—일마리 카로넨 (대화) 03:08, 2008년 7월 21일 (UTC)[응답]

TI는 지난 며칠 동안 스스로 이것에 대해 생각해 왔다.가장 큰 단점은 내가 강력히 주장하는 개방형 편집의 기본 원칙이다.나는 이 경우에 타협할 용의가 있을지 모르지만, 현재의 자기확증기준이 반제약에 큰 영향을 미칠 정도로 엄격하다고는 생각하지 않는다.그러나 모든 템플릿에 대한 완전한 보호가 실행 가능한 옵션은 아니라고 생각한다.— 칼 (CBM · talk) 03:20, 2008년 7월 21일 (UTC)[응답]

나는 이 아이디어가 장점이 있다고 생각하고 지지하지만, 단지 생각해 볼 것은 이것이 공공 기물 파괴 행위를 발견하기 어렵게 만들 것이라는 것이다. 그러나 지금 당장 IP는 편집하는 것을 쉽게 찾아낼 수 있지만, 만약 그 요건이 확증된 상태를 자동화하는 것으로 변경된다면, 더 확립된 사용자들로부터 그 기부를 걸러낼 방법은 없을 것이다. - 아이스웨지 (대화) 03:46, 2008년 7월 21일 (UTC)[응답하라]

최근 편집 능력이 지나치게 제한되어 왔다. 모든 것은 자동 확증을 더 어렵게 만드는 것에서부터 시작되었고, 통제 불능이 되었다. 우리는 원칙들을 가지고 있다. 그리고 그것들은 감시목록이 되어 되돌릴 수 있는 템플릿보다 더 중요하다.셀라노르 04:08, 2008년^{Talk to me} 7월 21일 (UTC)[응답]

나는 요전 날 이것을 익살스러운 논평으로 언급했는데, 나는 이것이 왜 고려되어야 하는지를 알고 있지만, 나는 이것이 우리가 실행해야 할 것이라고 생각하지 않는다.언급했듯이, 그것은 건설적인 편집을 너무 제한한다.템플릿에 유용한 편집을 시도하는 사람은 로그인하지 않으면 편집할 수 없다.전체 템플리트: 네임스페이스는 템플리트 문서에 대한 추가 또는 수정도 방지한다.우리는 이것을 돕기 위해 이미 사용할 수 있는 몇 가지 도구를 가지고 있다. 미리보기 화면에는 한 페이지에 사용된 모든 템플릿이 나열되어 있다. 최근 변경사항은 템플릿: 편집만으로 제한될 수 있으며, 익명 사용자만 표시된다. 고위험 템플릿은 이미 있는 만큼 보호될 수 있다.자신이 포함된 여러 관리자는 다양한 템플릿을 계단식 보호 기능을 갖춘 사용자 하위 페이지로 옮겨간다(사용자: 참조):Hersfold/Lockbox - 내가 나열한 것은 더 복잡한 템플릿을 코딩하는 데 일반적으로 사용되며 심각한 손상을 일으킬 수 있다.대부분 자신의 장점을 보호받고 있지만, 일부는 다음과 같거나 그렇지 않다: {{(}){{(})는 내가 수동으로 잠궈서 이중 보안을 위해 위 페이지에 추가하기 전까지 모든 편집에 열려 있었다.)템플릿 파괴 행위를 추적하는 데는 약간의 시간과 노력이 들지만, 불가능한 것은 아니며, 보통 짧은 시간 안에 찾아내어 고칠 수 있다.인정하건대, 그것은 당신의 평범한 공공 기물 파괴 행위보다 더 심각하지만, 내 의견으로는 그렇게 엄중한 보호 조치를 받을 만한 가치가 있는 것은 아니다.허스폴드 비관리자^(t/a/c) 04:26, 2008년 7월 21일 (UTC)[응답]

나는 오늘 이 일을 깊이 생각해 보았다.내가 생각한 것은 다음과 같다.

• 템플릿 네임스페이스에 플래그 지정된 리비전을 켜십시오.
  • 좋아: 거의 전적으로 공공 기물 파손을 막아야 해.
  • Bad: 플래그 지정된 수정사항과 함께 발생하는 모든 문제.
• XXX가 넘는 페이지 수에 따라 자동으로 전체 페이지를 보호하도록 소프트웨어를 변경하십시오.
  • 좋아: 유명한 템플릿 파괴 행위 금지.
  • Bad: 소프트웨어의 변경 필요; 템플릿 편집은 여전히 주의 깊게 관찰해야 하며, 좋은 XXX를 만드는 것은 어려울 것이다.
• 모든 템플릿을 완벽하게 보호하십시오.
  • 좋아: 더 이상 공공 기물 파손은 안 돼!
  • Bad: 더 이상 편집하지 마십시오!
• 모든 템플릿을 반보호하십시오.
  • 좋아, 반달족 속도를 늦출 수도 있어
  • Bad: 아마 안 그럴 거야.그리고 애논은 편집이 잘 된다.
• 비관리자에 의한 템플릿 변경 지연(즉, X분 동안 전횡에 영향을 미치지 않음, 되돌린 경우 작업 대기열에 들어가지 않음)
  • 좋아: 최근의 변화들은 패트롤러들이 어떤 반달리즘도 막을 수 있어.
  • 불량: 소프트웨어 변경.
• 필터 확장자를 사용하십시오.
  • 좋아: 반달리즘을 일시적으로 중단하라.
  • Bad: 군비경쟁.
• 우리가 이미 하고 있는 일을 계속하라.
  • 좋아: ??
  • Bad: ???

---- RockMFR 04:52, 2008년 7월 21일 (UTC)[응답]

원래 포스터의 제안은 좋지 않은 생각이다.템플릿 파괴 행위를 사용할 수 있을 정도로 정교한 파괴 행위는 일반적으로 계정을 만들기에 충분할 정도로 결정된다.나는 얼마나 많은 유용한 익명 편집이 템플릿에 만들어지는지 모른다 - 익명 편집은 대개 세련되지 않은 사용자들에 의해 이루어지기 때문에 - 하지만 이것은 여전히 가끔 일어나는데, 예를 들어, 변환된 인포박스에 대한 링크를 "편집"하기 때문이다.이 작은 숫자라도 아무 목적 없이 배제해서는 안 된다.Dcoetzee 05:51, 2008년 7월 21일 (UTC)[응답]

사용자:제이스윗은 위키백과에서 이 문제를 해결하는 데 도움이 되는 아이디어를 생각해냈다.관리자 알림판/IncidentArchive450#Fog; 기본적으로 사용자가 쉽게 이러한 문제의 주범인 템플릿을 찾아 되돌릴 수 있는 "이 페이지에 표시된 페이지의 최근 변경 보기" 도구였다(AWB가 그렇게 할 수 있는가, 아니면 누군가가 툴서버에 균열을 일으키기를 원하는가).유용할 것 같나?_{tiny plastic} -- 그레이 나이트⊖ 10:12, 2008년 7월 21일 (UTC)[응답]

사실 그렇다.나는 또한 템플릿이 특정의 높은 페이지 수에서 변환될 때 자동으로 보호되는 것을 좋아한다. --acrocuse알렉스: 2008년 7월 21일 12시 10분 (UTC)[응답하라]

솔직히 우리가 해야 할 일은 가장 최근에 편집된 (지난 3시간 이내) 편집 페이지에 변환된 템플릿 리스트에 태그를 붙이는 것뿐일 텐데, 이미 보호된 템플릿이 거기에 (보호됨)으로 태그가 붙여진 방식과 유사하다.보통 가장 최근에 편집된 템플릿은 파손된 템플릿이 될 것이다.— 가비아 임머 (대화) 2008년 7월 21일 (UTC) 18:47[응답]

"툴서버 툴에 대한 제안"을 열거할 수 있는 곳이 있는가, 아니면 이것이 정말 {{sofixit}} 상황인가?:-)_{tiny plastic} -- 그레이 나이트 ⊖ 15:17, 2008년 7월 21일 (UTC)[응답]

야, 그거 좋은 생각이야.나는 그것을 하기 위해 사용자 대본을 썼다.아노미슈 01:34, 2008년 7월 22일 (UTC)[응답]

나는 이것을 지지하지만, 기본 보호 수준이 완전하게 보호되지 않고 반보호가 되어 있는 경우에만, 나는 (내 자신이 포함된) 건설적인 방법으로 템플릿을 편집하는 비관리자가 많을 것이라고 확신한다.It Is Me Here (토크) 2008년 7월 21일 12시 38분 (UTC)[응답하라]

It Is Me Is Me 여기에 기본 보호 수준이 반보호되어야 한다는 점을 강력히 제기된다.WP:CEX는 회원들에 의해 생성/수정된 여러 템플릿을 사용한다. -- Philcha (토크) 13:14, 2008년 7월 21일 (UTC)[응답]

필터 확장자 사용 관련 항목: Good: 반달리즘을 일시적으로 중단하라. Bad: 군비 경쟁, 나는 "Bad" 분석에 동의하지 않는다.필터 익스텐션에서 설정을 회피하는 방법을 알아내는 것은 ⑴ 많은 일이 될 것이고 ⑵ 이러한 종류의 공공 기물 파괴 행위를 발견하여 고치는 것과 관련하여 반달에게 결코 유리하지 않을 것이다.더 좋은 비유는 공항의 감시 카메라나 엑스레이 기계와 같은 것으로 - 여러분이 그들이 할 가치가 있다고 생각하든 말든 간에, 그것들은 결코 "팔씨름"으로 이어지지 않는다. - 존 브로든 (바보트) 2008년 13:10, 2008년 7월 21일 (UTC) 응답하라.

그 연장은 이와 같은 반달리즘을 다루기 위한 것이 아니다; 그것은 매우 구체적이고 쉽게 식별할 수 있는 반달리즘(즉, HAGARA 페이지모브)만을 다루기 위해 필터를 사용하는 것이다; 그것은 ConverseBot 등에 의해 되돌아오는 반달리즘을 다루기 위한 것이 결코 아니다.2008년 7월 21일 (UTC) 14:12 (응답)

또한 구조적으로 편집하는 익명의 편집자들도 많이 있다; 당신은 계정을 가지고 있기 때문에 그들보다 더 나은가?그룹 중에 패자가 몇 명 있는데 정말 막아야 할까?만약 당신이 그렇게 생각한다면, 당신은 정말로 완전한 보호를 지지해야 한다. 왜냐하면 자동 확증된 사용자도 반달일 수 있기 때문이다.당신은 심지어 조금 더 나아가서 우리가 RFA를 위반하기 위해 계정을 만들 수 있기 때문에 템플릿이 전혀 있어서는 안 된다고 말할 수도 있다.몇 명의 패배자 때문에 디폴트로 편집을 금지하는 것이 정말 좋은 생각인가?2008년 7월 21일 (UTC) 14:12 (응답)

이것은 위키 입니다.전체 템플리트 반보호: 네임스페이스는 득보다 실이 훨씬 더 많을 나쁜 생각이다.자동 확증한 한계는 무시할 수 없는 사소한 것이며 템플릿: 네임스페이스에 합법적인 페이지 콘텐츠가 많이 저장되어 있다. --MZMcBride (토크) 14:27, 2008년 7월 21일 (UTC)[응답]

아무것도 하지 않는 것은 여기의 지침에 의해 요약된 현재 상황보다 더 나쁠 것이다 [3].현재 우리는 템플릿별로 되돌리고, 보호하고, 숙청하고, 경고하며, 우리는 서서히 비효율적이고, 시간이 많이 걸리고, 단편적인 방법으로 대부분의 일반적인 변환된 템플릿의 보호를 향해 나아가고 있다.작은 노력으로 큰 혼란을 일으키려는 드라이브 바이 템플릿 반달에게 전체적으로 덜 편리해진 경우가 있다.

나는 전체 공간을 반비례하는 것은 너무 엄격한 것이라고 생각하지만, 나는 "이 페이지에 쓰여진 페이지의 최근 변경사항 보기"라는 생각이 마음에 든다. - 팝업을 위해 그것이 만들어질 수 있다면, 죽은 것처럼 말이다.「X페이지로 넘어갔을 때의 세이프티」 아이디어에 대해서는, X가 무엇인가에 대해 공감대를 얻을 수 없을 것이기 때문에 실행할 수 없다는 주장은 믿지 않는다.우리는 이미 매우 중요한 템플릿에 대한 완전한 보호에 대한 의견 일치를 본 것으로 보이며, 보호 여부에 대한 판단은 개별 관리자에 의해 즉각적으로 이루어진다.만약 제안이 이루어진다면 X에 대한 수치는 논의로 얻을 수 있을 것이라고 확신한다.마지막으로 [4]에서 관리자가 아닌 사용자가 템플릿 파괴 행위를 탐지하고 되돌릴 수 있는 방법에 대해 훨씬 더 나은 단계별 설명을 할 수 있는 범위가 있으며, 사용자가 먼저 안내를 받을 수 있는 곳이기도 하고, 약간 희박하다.나는 위 허스폴드의 제안이 나 자신의 향후 참고에 특히 도움이 된다는 것을 알았다.숙련된 모형 반달 파이터들이 이 구역을 좀 더 다듬는 걸 볼 수 있을까?카렌jc 18:11, 2008년 7월 21일 (UTC)[응답]

우리는 이 일에 대해 뭔가 조치를 취해야 할 것이다.이 반달은 수백 개의 유명한 페이지를 한 번에 치는 방법을 알아냈고 결과적으로 영향을 받은 사람들(그리고 불평한 사람들)의 수가 엄청나다.500개 이상의 전횡이 있는 템플릿이 몇 개인지 알아보는 프로그램을 작성했는데 2000년에 걸쳐 돌아왔다.일정 수의 전횡이 넘는 반보호 템플릿이 가장 좋은 방법처럼 보인다.Hut 8.5 18:51, 2008년 7월 21일 (UTC)[응답]

음-흠. 당연하지.나는 우리 모두가 500페이지 이상에 걸쳐 있는 템플릿이 확실히 "위험이 높고" 최소한 반보호되어야 한다는 것에 동의할 수 있다고 생각한다.물론 그것보다 덜 착각되고 위험성이 높은 템플릿은 특별한 경우로서 자동 개입 없이 보호될 수 있을 만큼 충분한 주의를 받을 수 있을 것이다(예: AN 템플릿).그러나 일부 템플릿은 "잊혀져" 간과되고, 따라서 사람들은 대규모 반달리즘을 놓칠 수 있다.다른 아이디어들 중 일부를 추구해야 할지 말아야 할지 모르겠지만, 나는 이 특별한 아이디어가 템플릿 네임스페이스에 적용되어야 한다고 강하게 생각한다. --acrocuse알렉스: 2008년 7월 21일 19시 5분 (UTC)[응답하라]

아니, 적어도 모든 템플릿은 아니야고위험 템플릿을 보호하는 것은 이성에 부합하고 확립된 실천요강이지만 모두 선제적으로 이루어지는 것은 아니다.모든 직렬 반달은 반절제를 우회하기 위해 계정을 등록하는 방법을 알고 있다. 즉, 이 솔루션이 할 일은 정직한 IP 편집자를 기고에서 배제하는 것이다.나는 최근 IP 편집자와 협업하고 있는데, 그는 수십 개의 기사와 관련 템플릿을 건설적으로 편집했다.우리가 작업해 온 기사들 중 하나는 음모론적인 반물질에 대한 대응으로 반자동화되었고, 그 결과 현재 모든 IP가 차단되었다.기고자를 잃느니 차라리 반달이라도 계속 되돌리는 게 낫겠어.--아버지 구스 (토크) 19:13, 2008년 7월 21일 (UTC)[응답]

그러나 우리는 반보호 기사에 대해 말하는 것이 아니다: 이것은 반보호 템플릿에 관한 것인데, 이것은 (대부분의) 신인들에게는 상당히 불가사의한 것이다.어쨌든, 기사의 반달리즘은 템플릿에 있는 것보다 훨씬 빠르고 쉽게 되돌릴 수 있다. - 제레드몬드 (토크) 20:40, 2008년 7월 21일 (UTC)[응답]

나는 극도로 강한 반대 의견을 등록하고 싶다.Dcoetzee가 위에서 말했듯이, 템플리트를 칠 수 있을 만큼 충분히 정교한 반달은 일부 계정을 숙성시킬 만큼 충분히 정교하다.이 모든 것은 IP 편집자에게 백과사전의 다른 영역을 차단하는 것이다.나는 과거에 템플릿을 만들었고, 곧 내가 선호하는 편집 방식으로는 다시는 그것을 할 수 없을 것이라고 생각하니 소름이 끼친다.IP 편집기를 템플릿 공간에서 완전히 차단해서는 안 된다.절대로. 미안하지만, 여기서의 의도는 이해하지만 IP 편집자에 대한 극단적이고 총체적이며 영구적인 단속은 도를 넘고 있다.이것은 익명의 사용자들을 완전히 제거하기 위한 또 하나의 단계일 뿐이다. 오픈 편집의 Defender인 IP씨, 2008년 7월 27일(UTC) 16:40[응답]

좋아. 반달리즘에 비해 요즘 IP 사용자의 유용한 편집 비율이 너무 낮아서 익명의 사용자들은 완전히 제거되어야 해.이 프로젝트의 시작에 대한 좋은 아이디어지만, 현재 거의 모든 구글 검색에서 처음 한두 번 발견되는 등 전세계적으로 매우 높은 가시성으로 인해, 이 개념은 시대에 뒤떨어져 있고 "익명 사용자의 권리" 보호는 기껏해야 시대착오적이다.누구나 계정을 등록할 수 있으며, 공공 기물 파손의 감소에 미치는 긍정적인 영향은 IP로부터 건설적인 편집의 손실을 훨씬 능가한다.Tanǀ39 16:50, 2008년 7월 27일 (UTC)[응답]

한 가지만 더 말씀드리면 편집자 전원을 제거합시다.그들은 정말 성가시다!관리자들은 그들의 뒤를 청소할 필요가 없어야 한다. 오픈 편집의 Defender인 IP씨 09:00 (UTC) 2008년 7월 28일 (회신)

• Hut 8.5에 동의하고 500개 이상의 링크로 모든 템플릿을 보호하십시오.그럼 적어도 반달족들은 느려질 거야.나울린위키 (대화) 2008년 7월 21일 19:15 (UTC)[응답]

• 그것은 아이디어다.- 그것은 공공 기물을 파괴하는 것을 막지는 못하지만, 속도 위반이다. 그리고 템플릿 공간은 충분히 난해해서 기고하는 대부분의 사람들이 잘 자리를 잡고 있는 편집자들이기 때문에, 우리는 이런 식으로 기사를 보호하는 것보다 부수적인 피해를 덜 받는다.아마도 더 유용하게, 누군가 수백번 이상 망각된 모든 템플릿의 목록을 만들 수 있을 겁니다. 그리고 우리가 그것들을 완전히 보호하도록 합시다...심그레이토크 20:25, 2008년 7월 21일 (UTC)[응답]

그런 리스트는 만들 수 있지만, 그것을 위키에 올리는 것은 반달에게 목표물의 리스트를 주는 것이기 때문에 좋지 않은 생각이다.Hut 8.5 20:57, 2008년 7월 21일 (UTC)[응답]

• 나는 이곳의 일반적인 생각이 마음에 든다.템플릿 편집에 관한 한, 누구나 토크 페이지에 코멘트를 할 수 있으며, 등록된 사용자라면 누구나 자신의 변경사항 모형으로 /Temp 하위 페이지를 만들 수 있다.여기서 나의 유일한 주요 관심사는 반 보호가 일회성 확증 계좌에 대해 얼마나 효과적인가 하는 것이다. - 제레드먼드 (대화) 20:40, 2008년 7월 21일 (UTC)[응답]

• 나는 개인적으로 모든 훌륭한 위키피디아가 설명을 해야 한다고 생각한다.500페이지 이상의 페이지에 존재하는 반보호 템플릿에 대한 아이디어는 공정하고 정당해 보인다.그것은 순찰하는 짐을 다소 줄일 것이다.또한 건설적인 일을 하고 싶어하는 훌륭한 위키피디아 사람들은 기본 시험을 쉽게 통과할 것이다.이 아이디어는 그들에게 계정을 만들도록 자극할 것이다.어쨌든 반달들은 상영보다 숨겨진 자동 설정 템플릿보다 더 많은 가시성을 가진 기사 더티플링에 더 관심이 있다. --gppande «talk » 20:50, 2008년 7월 21일 (UTC)[응답]

• 반보호가 합법적인 편집자 외에는 누구에게나 억제책이 될 것이라는 증거는 거의 보지 못했다. --MZMcBride (대화) 20:55, 2008년 7월 21일 (UTC)[응답]

• #500번 전치 후 자동 반보호를 시행하면, 사람들이 단지 카운트와 강제 보호에만 더 많은 전치료를 추가하기 시작할 때까지 얼마나 걸릴까?목록을 사용하여 표시되는 템플릿을 전환하면 템플릿 파괴에 대한 더 나은 접근 방식이 될 수 있다는 미리보기 IMHO는 "파손하기 쉽고, 고치기 쉽다"는 설명에 더 부합한다. -Steve Sanbeg (대화) 21:11, 2008년 7월 21일 (UTC)[응답]

• 적극 지지하다.위키피디아가 익명으로 편집이 가능한 '스타트업'을 지나 사용자들이 계정을 가져야 하는 영역으로 옮겨갔다고 믿는 사람으로서, 그리고 최근의 모든 그루프 헛소리에 대처하는 것은 좋은 생각이다.Tan ǀ 39 01:35, 2008년 7월 22일 (UTC)[응답]
• 나쁜 생각이야, MZMcBride에 동의해, 이것은 좋은 편집자들에게만 상처를 줄 것이고, 익명의 편집자들에 대한 또 다른 단계로 사용되는 것처럼 보여.데이브윌드 (대화) 07:02, 2008년 7월 22일 (UTC)[응답]
• 나는 어떤 네임스페이스에서든 페이지를 무차별적으로 보호하는 것에 전적으로 반대한다.보호는 반달리즘의 위험성이 높고 취약하다는 특정 기준을 충족하는 페이지를 잠재적 예외로 하여 사례별로 적용해야 한다.자동 확인 기준이 상향된 덕분에 반보호가 예전보다 더 의미가 있으며, 예외 없이 그러한 조치의 사용에 주의와 좋은 판단이 수반되어야 한다.2008년 7월 23일 (UTC) 19:43의 공작 월섬 (Walthaltham, The Duke of 19:43, The Duke of 2008 (UTC)
• 나는 (a) 새로 등록한 사용자들이 (반보호에 의해 "판단된" 경우, 그것은 틀림없이 이득이지 문제가 아니다), 그리고 (b) 템플리트에 유용한 변경을 해 온 경험 많은 편집자들이 있을 때까지 템플릿으로 어슬렁거릴 필요가 있다고 믿기 어렵다.es. 그러나 등록된 계정을 갖는 것의 가치를 알아내지 못했다. (기존, 더 나은 익명성, 자신의 편집 내용을 추적하는 능력, 더 나은 평판 등)수십 페이지 이상의 페이지에 영향을 미치는 템플릿은 *고위험*이라는 것을 인정해 보십시오. 즉, 대부분의 템플릿은 최소한 반비보호되어야 한다는 것을 의미하므로 네임스페이스를 반비보호하고 작업을 완료하는 편이 낫다는 것을 의미함.

'누구나 편집할 수 있는' 것을 허용하는 목적은 관점을 억압하고 기사에 대한 기여를 장려하는 것을 피하기 위함이다.반면에 위키피디아는 "누구나 소프트웨어를 수정할 수 있는 백과사전"이 아니다.우리는 개발자들이 소프트웨어를 망치도록 내버려 둘 뿐이고 아무도 그것을 검열이나 문제로 여기지 않는다.템플릿은 코드다.위험 보상 계산에서, 공공 기물 파손의 위험은 초보자와 IP 편집자가 템플릿에 기여한 이익보다 훨씬 더 커 보인다.아니면 위키백과의 개념에 대한 어떤 "손해"도. -- 존 브로튼 (바둑바둑) 23:20, 2008년 7월 23일 (UTC)[응답]

아주 좋은 지적이야.게다가 대부분의 고위험 템플릿은 등록한 사용자도 조작할 수 없는 것으로 간주되며, 따라서 그러한 템플릿은 완전히 보호된다.반보호가 어떻게 비합리적인지 모르겠다.실제로 IP에 의한 유익한 템플릿 편집의 양은 매우 미미하기 때문에 공공 기물 파손을 방지하는 이득은 실제로 훨씬 더 크다. --acropatic알렉스:. 2008년 7월 24일 14시 20분 (UTC)[응답하라]

존: 미안하지만, 넌 완전히 틀렸고 아무런 지원도 없이 진술을 하고 있어.템플리트: 네임스페이스(여기)만 표시하는 로그인한 사용자가 숨겨져 있는 최근 변경사항 피드를 보십시오.익명의 편집자들은 매일 수백 개의 템플릿을 편집한다.그리고 단지 코드만이 템플릿에서 발견된다고 말하는 것은 단지 쓰레기일 뿐이다.예를 들어 템플릿:로스앤젤레스 다저스의 선수 명단해당 템플리트(그리고 많은 다른)는 합법적인 페이지 내용을 포함하고 있다.만약 우리가 사람들이 페이지 텍스트를 자유롭고 익명으로 편집할 수 있도록 허용한다면, 편집자들이 템플리트 내의 페이지 내용을 자유롭고 익명으로 편집하는 것을 막을 이유가 없다.템플릿: 템플릿:로스앤젤레스 다저스 선수 명단 navbox 사용(템플릿:Navbox)는 완전하게 보호되어야 하며, 반 또는 완전하게 보호되어야 하며, 그러한 템플릿은 불합리하고 반위키적이어야 한다.우리의 지침 원칙 중 하나는 누구나 편집할 수 있는 능력인데, 우리는 그러한 능력을 다양한 이유(대규모 피해, 서버 자원 낭비, 콘텐츠 분쟁 등)로 제한한다.본 토론에서 템플릿: 익명의 사용자로부터 네임스페이스(네임스페이스)를 단호하게 제한해야 하는 설득력 있는 이유나 증거를 본 적이 없다. --MZMcBride (talk) 00:30, 2008년 7월 25일 (UTC)[응답]

나는 동의한다; 게다가 많은 템플릿들은 텍스트나 표를 반복하는 것 이상도 이하도 아니다.그들은 복잡할 필요가 없다.그들은 결점 없이 누구나 쉽게 편집할 수 있고, 실수할 경우 쉽게 수정할 수 있다.명예로운 동료들에게, 비록 템플릿의 공공 기물 파손은 여러 페이지에서 동시에 볼 수 있지만, 그것은 또한 누군가가 그것을 발견하고 수정하여 균형을 되찾는 변화를 증가시킨다는 것을 상기시킨다.그리고 또 다른 것이 있다...

템플릿은 템플릿 네임스페이스로 제한되지 않는다.사용자 및 프로젝트 네임스페이스에는 템플릿이 있으며, 이러한 템플릿이 메인 스페이스에서 변환되지는 않지만, 반달리즘에는 경우에 따라 균등하거나 훨씬 더 많은 교란이 발생할 수 있다.이러한 것들은 템플릿에 대한 포괄적인 반보호, 이중 표준을 만들고 템플릿 생성 및 편집 경향에서 예측할 수 없는 변화를 촉발하는 것에 의해 제외된다.사례별 보호의 장점이 뭐가 문제야?많은 경우 20페이지로 구분된 템플리트를 보호하기 위해 로그에 얼마나 많은 양을 쏟아 붓는 이유는 무엇인가?이 대포는 군인보다 훨씬 더 많은 파리들을 죽일 것이다.2008년 7월 26일 (UTC) 00:29의 공작 월섬[응답]

다른 측면에서 당신의 논평의 장점을 다루지 않고, 나는 사소한 기술적 수정으로서 템플리트 네임스페이스를 보호하기 위해 제안된 방법들 중 어느 것도 로그 항목을 만들지 않는다는 것을 지적하고 싶다.—일마리 카로넨 (대화) 01:27, 2008년 7월 26일 (UTC)[응답]

당연히 주목했다.말 그대로라기 보다는 시적인 이미지로 더 뜻깊었다. :-) 월텀, 23:06, 2008년 7월 27일 (UTC)[응답하라]

아모니의 사용자 설명 솔루션

방금 사용자:Anomie의 사용자:Anomie/previewtemplatelastmod.js 스크립트, 꽤 잘 작동하는 것 같다; "여기서 사용하는 템플릿 목록" 목록을 수정하여 각각의 이름 대신 가장 최근의 변화를 보여준다._{tiny plastic} --그레이 나이트 ⊖ 06:58, 2008년 7월 22일 (UTC)[응답]

공교롭게도 현재 rev:37927이 라이브로 진행 중이므로 Special:최근 ChangesLinked(왼쪽 도구 상자에 "관련 변경사항"으로 나열됨)는 이제 변환된 템플릿에 대한 변경사항을 포함한다.—일마리 카로넨 (대화) 01:30, 2008년 7월 25일 (UTC)[응답]

사용자 상자 확산됨

약 1년 반 전만 해도 노력이 있었다(위키피디아:사용자 상자 마이그레이션) 사용자 특성을 표시하는 템플릿을 공간 밖으로 이동(일반적으로 사용자 상자라고 하며 사용자 페이지에 자주 표시됨)그 결과, 우리는 이제 아마도 수천 개의 사용자 상자(또는 사용자 상자)를 다양한 사용자 페이지 아래 공간에 흩어지게 되었다.

전에 이런 제안이 있었는지 모르겠지만, 그들을 찾기 쉬운 한 곳으로 옮기는 것이 말이 될까?사용자 사용을 제안한다:내가 확인한 박스(토크 · 기여)는 창작에 사용할 수 없고, 기여가 없으며, 이미 위키백과로 리디렉션되는 "시스템"으로 사용되고 있다.사용자 상자.내 사용자 페이지는 userboxen의 풍부한 예지만, 무작위로 몇 개를 가져간다.

1. {{User:The Raven's Apprentice/Userboxes/User Firefox}}
2. {{User wikipedia:No personal attacks}}
3. {{User:Menasim/Userboxes/User Google}}
4. {{User:UBX/Scuba Diver}}
5. {{User time zone UTC-8 (UTC-7 summer, UTC-8 winter)}}
6. {{User:Lucasbfr/Admin open to trout slapping}}

높은 평가를 받는 {{Babel} 사용법에서도 사용자 공간 박스는 다음과 같은 것들이 있다는 것을 알 수 있다.

• {{Babel :Feureau/UserBox/AmericanEnglish :ZeroOne/Userboxes/php-3}}

나의 6가지 더 또는 덜 무작위적인 예에서, 4개는 다양한 사용자 페이지 아래에 있고 2개는 템플릿 공간에 있다. 비록 두 개 모두 사용자 공간에 있는 것처럼 "예쁘다"고 말했다.아주 혼란스럽군사용자 박스의 상당 부분(20%)이 UBX(토크 · 기여) 아래에 있는 것처럼 보이는데, 좋은 출발은 메츠501(토크 · 기여)이 멋진 디렉토리를 거기에 넣었다.하지만 잘 알아들을 수 없었던 것은 놀랍지 않다. 못생겼고UBX, 마음에 잘 흐르지 않는다. (그래도 키보드 느낌이 좋다.)

모든 사용자 상자를 User:Box 아래에 두도록 마이그레이션하시겠습니까?예: —{{user:Box/No personal attacks}}, {{user:Box/time zone UTC-8}}, {{user:Box/Admin open to trout slapping}}EncMstr (talk) 01:23, 2008년 7월 24일 (UTC)[응답]

나는 이것이 좋은 생각이라고 생각한다.- Twas Now (토크 • 기여 • 이메일 ) 05:22, 2008년 7월 24일 (UTC)[응답]

나는 그 아이디어가 마음에 든다.셀라노르 05:52, 2008년 7월 24일 (UTC)[응답]

수십 개의 템플릿을 제거할 수 있는 모든 항목:사용자 X 스타일 박스는 좋은 것이다.MBisanz 06:23, 2008년 7월 24일 (UTC)[응답]

과거에 제안되었지만 반유저박스 폭도들은 강하게 반대했다.Geni 19:53, 2008년 7월 24일 (UTC)[응답]

왜? 2008년 7월 24일(UTC) 19시 55분 셀러너[응답]

그들이 반유저박스 폭도였기 때문에?나는 걱정하지 않을 것이다. 대부분은 위키피디아를 그만두거나 그 주제에 흥미를 잃었다.Geni 22:57, 2008년 7월 24일 (UTC)[응답]

위키백과:사용자 상자#어떤 네임스페이스?이미 다음 계정을 권장함:이거 UBX.나는 요즘, Babel 템플릿이나 {{User time zone}}과 같이 협업을 명확하게 촉진하는 "공식" 사용자 박스 템플릿만이 템플릿: 네임스페이스에서 허용되고 있는 반면, "이 사용자는 실라이프로 얻어맞기를 좋아한다"와 같은 임의의 "개인" 템플릿은 사용자: 공간에 머물러야 한다는 인상을 받아왔다.그들은 위키피디아(프로젝트)의 일부가 아니다.그러나, 명백하게 그것은 그렇지 않다: 가이드라인은 단지 "템플릿과 프로젝트 네임스페이스의 사용자 상자는 정책과 가이드라인을 더 엄격하게 준수할 것으로 예상된다"고 모호하게만 말한다.—일마리 카로넨(토크) 01:26, 2008년 7월 25일 (UTC)[응답]

현재 사용자 상자의 상태는 불안한 휴전 상태에 있다.내 생각엔 네가 그들과 함께 있는 것이 덜 할수록 더 좋은 것 같아.숨막힐 (대화) 2008년 7월 27일 (UTC) 10:06[응답]

그냥 (그리고 아마도 끔찍하게 순진한) 질문으로, 이 "상자" 복수형은 어디에서 왔을까?--코트니스키 (토크) 15:19, 2008년 7월 27일 (UTC)[응답하라]

wikt:boxen을 참조하십시오.대수학자 16:31, 2008년 7월 27일 (UTC)[응답]

그 절반은 그것에 대답한다. 하지만 이 버릇이 다른 몇몇의 꽤 정상적인 위키백과인들 사이에서 특정한 용어 "userboxen"을 사용하는 것에 대해?---코트니스키 (대화) 2008년 7월 17:12, 27 (UTC)[응답하라]

나는 몇 년 동안 벡스 컴퓨터에서 일했다.어떻게 '백스'를 복수화할 수 있을까?팍센! (좋아하면 팍스, 무관심하면 팍스.) —EncMstr (대화) 21:31, 2008년 7월 27일 (UTC)[응답]

그래서 우리는 "userboxen"이 주로 사용자 박스가 꽤 깔끔한 아이디어라고 생각하는 컴퓨터 괴짜들에 의해 사용된다고 결론짓는가?--- Kotniski (talk) 22:57, 2008년 7월 27일 (UTC)[응답]

설명: 사용자 이후:UBX는 이미 존재하며, 많은 사용자 상자를 사용자:로 이동하는 데 큰 이점이 없다고 본다.상자. 하지만 다른 편집자들이 이것이 좋은 생각이라고 생각한다면 나는 반대하지 않을 것이다.나는 Ilmari와 같은 인상을 가지고 있다 – 템플릿 네임스페이스는 더 많은 공식 사용자 박스에 사용되는 반면, 사용자 네임스페이스는 다른 사람들을 위한 것이다.User box를 User에 배치하는 경우:UBX 또는 편집자 자신의 사용자 페이지, 주목해야 할 사항은 "Wikipedia:사용자 페이지": "[B]y convention your user page는 일반적으로 다른 사용자가 편집하지 않는다. ...일반적으로 허락 없이 다른 사람의 사용자 페이지를 실질적으로 편집하지 않는 것은 예의 바른 것으로 간주된다."따라서 사용자 페이지에 사용자 상자를 배치하는 것은 다른 편집자에게 사용자 상자 수정을 자제해야 한다는 신호인 반면 사용자:UBX. — 건배, 잭리 19:46, 2008년 7월 27일 (UTC)[응답]

COI 문제가 있는 사용자를 위한 템플릿

이미 환영이 있음NPOV 템플릿.하지만 자서전을 만드는 사람들과는 맞지 않는 것 같다.나루톨로베히나타5 09:47, 2008년 7월 27일 (UTC)[응답]

{{-auto}}이(가) 하는데도 :) 숨막히는 (대화) 10:03, 2008년 7월 27일 (UTC)[응답]

난 몰랐어!Welcomeusername과 함께 Friendly로 배치되어야 한다.나루톨로베히나타5^tccsdnew 10:07, 2008년 7월 27일 (UTC)[응답]

그건 정말 좋은 환영 템플릿이야, 스틱나는 그것을 기억해야 할 것이다.~ mazca 10:09, 2008년 7월 27일 (UTC)[응답]

하위 카테고리 정렬

최근 범주 내 하위 범주 배치에 대한 논의(알파벳어/초기)는 사실은 개방적이고 정말 오래된 버그라는 점을 지적한 바 있다.나는 내 표를 거기에 두었고, 여전히 관심이 있는 사람들도 똑같이 할 수 있었다.~ JonnyMr Ninja 08:30, 2008년 7월 28일 (UTC)[응답]

롤백 제한

롤백 제한을 처음 만들었을 때는 모든 자동 확인 사용자에게 플래그가 주어질 때였다.이제 관리자(administrator)가 수동으로 허가해야 하고, 사용자가 허가서를 받기 전에 어느 정도 단서를 보여야 하기 때문에, 롤백기에 설정된 제한을 없앨 것을 제안한다. 우리는 이미 오용할 경우 허가를 제거하는 데 효과적이라는 것을 보여주었다.Ryan Postlethwaite 22:37, 2008년 7월 14일 (UTC)[응답]

난 이 일에는 아무런 문제가 없다.많은 사용자들이 이 제한 때문에 공공 기물 파손 행위를 따라잡는데 어려움을 겪고 있다.라이언의 말대로 남용될 때 제거해도 괜찮다고 생각하니까 이건 문제가 되지 않을 것 같아. - Rjd0060 (대화) 22:55, 2008년 7월 14일 (UTC)[응답]

내가 틀릴 수도 있지만 몇 주 전에 한도가 100으로 올라간 것 같아.그렇다 하더라도, 나는 여전히 한도를 완전히 없애는 것을 지지할 것이다: 그것은 필요하지 않다.롤백을 남용하는 사람은 롤백을 제거하고, 올바르게 사용하는 사람은 권리를 유지하지만 한계에 의해 방해를 받는다.한도를 없애자.아칼라마리 02:18, 2008년 7월 15일 (UTC)[응답]

한계가 있다는 것조차 몰랐어(어디서 문서화 된 건가?)그러나 위에서 듣기로는 폐지하거나 최소한 크게 올리는 것이 유리할 것으로 보인다.--코트니스키(토크) 09:07, 2008년 7월 16일 (UTC)[응답]

그것을 없애라. 그것은 아무에게도 도움이 되지 않는다.Hut 8.5 18:55, 2008년 7월 21일 (UTC)[응답]

나는 동의한다, 행정적 판단은 충분하다.앞으로 나아갈 수 있을까?스코모록 11:50, 2008년 7월 22일 (UTC)[응답]

여기까지 의견이 일치한 것 같다.데브에 가져가는 것에 반대하십니까?--코트니스키 (토크) 18:56, 2008년 7월 26일 (UTC)[응답하라]

• 나는 그 도구를 1톤도 사용하지 않지만, 한도가 아무런 소용이 없다면, 그것을 잃어버려라.우리는 있는 그대로의 불필요한 과정을 충분히 가지고 있다.S. Dean Jameson 20:36, 2008년 7월 26일 (UTC)[응답]

소프트웨어에 대한 실제 개발 작업 없이는 한도를 실제로 제거할 수 없다.그러나 임의로 높은 수로 올릴 수 있다.현재는 10분/분으로 설정되어 있다(믿는다).비 sysops는 API(여기)를 통해 요금 제한을 확인할 수 있다.정기적으로 한계점에 도달하면 이를 올리지 않을 실질적인 이유가 없다. --MZMcBride (토크) 02:12, 2008년 7월 27일 (UTC)[응답]

그러니까, 1분에 60으로 맞춰달라고 하는 건 어때?초당 1초 한도가 누구의 방해가 되어서는 안 된다.--코트니스키(토크) 08:27, 2008년 7월 27일 (UTC)[응답]

침묵이 동의를 나타낸다고 가정하고(위의 논의에 근거해) 버질라(Bugzilla, 14967).--코트니스키(토크) 08:55, 2008년 7월 29일 (UTC)[응답]

요청:감시 목록의 감시 해제 버튼

나는 워치리스트에 "워치 해제" 버튼 추가를 요청하고 싶다.기사를 열거나 "감시 목록 관리" 페이지를 보면 접근할 수 있다는 것을 알고 있지만, 어느 경우든 이 작업은 추가 단계를 거쳐야 한다.SharkD (대화) 22:32, 2008년 7월 26일 (UTC)[응답]

나는 네가 무엇을 원하고 이것이 어떻게 더 편리해지는지 완전히 이해하지 못하겠다.또한 "un"이라는 접두사를 사용하는 이유..."dewatch"를 사용할 수 없었나? --CyclePat (토크) 05:21, 2008년 7월 27일 (UTC)[응답]

unwatch는 이미 인터페이스에 있다.이것의 요점은 당신이 보고 싶은 페이지를 보지 않고도 감시 목록에서 직접 페이지를 해제할 수 있는 것으로 보인다; 이것은 어느 정도 일리가 있다, 왜냐하면 감시 목록 편집 보기의 순서가 메인 보기의 순서와 매우 다르기 때문에, 최근에 수정된 여러 페이지 quu를 해제하는 것이 어려울 수 있기 때문이다.ickly. Dcoetzee 08:56, 2008년 7월 27일 (UTC)[응답하라]

이 아이디어를 확실히 지지하십시오.빠른 연결고리를 가진 여러분에게는 큰 문제가 되지 않을지 모르지만, 느린 연결고리에서 특히 모든 추가 스텝에 드는 시간은 09:14, 2008년 7월 27일 (UTC)[응답]

동의해, 아주 유용해.숨막혀 (대화) 2008년 7월 27일 (UTC) 10:03 [응답]

사용자 스크립트 user:js/watchlist 설치는 작동한다.그러나 이것은 소프트웨어의 영구적인 특징일 수는 없다.Bugzilla에서 요청 424번으로 나와있어.패치로 제출할 의향이 있는 사람?--신부 구스(토크) 10:17, 2008년 7월 27일 (UTC)[응답]

WP:내비게이션 팝업 가젯을 활성화하면 감시 목록 {또는 다른 곳) DGG(토크) 11:49, 2008년 7월 27일(UTC)[응답]의 페이지 제목을 마우스로 가리키면 이미 이 기능이 제공된다.

네가 말했듯이, 이것은 단지 감시자 명단에만 있는 것이 아니라 모든 곳에 나타난다.결과적으로, 그것은 페이지에 더 많은 비대함을 더하고 다운로드하는 데 더 많은 시간이 걸리도록 한다.또한, 모든 사람들이 팝업의 거슬리는 성격을 좋아하는 것은 아니다.샤크D (대화) 2008년 7월 27일 18:00 (UTC)[응답]

피처 크리프 입니다. --Pwnage8 (토크) 15:36, 2008년 7월 28일 (UTC)[응답]

"이것은 피쳐 크리프"가 "이것은 새로운 피쳐에 대한 요청이다" 이상의 의미를 가지는가?만약 그렇다면, 최소한 어떤 종류의 논쟁이라도 해줄 수 있겠니?--코트니스키 (토크) 16:42, 2008년 7월 28일 (UTC)[응답하라]

음, 그래, 그것보다 더 큰 의미가 있어.링크를 클릭하셨나요?피쳐 크리프라는 건 잘 모르겠지만, 그 용어를 이해할 수 없어서 비유를 해야 하는 건 시간 낭비야.Tanǀ39 16:45, 2008년 7월 28일 (UTC)[응답]

내가 그 용어를 이해하지 못했다는 뜻이 아니라, 나는 단지 어떻게 "이것이 특징적인 크리프"가 정당성을 위한 어떠한 시도도 없이 스스로 논쟁으로 설 수 있는지 모르겠다.마치 "이건 나쁜 생각이야"라고 쓰는 것과 같다. ("왜냐하면..「그 후」---코트니스키 (토크) 16:52, 2008년 7월 28일 (UTC)[응답]

단추가 너무 많아.javascript 애드온 Chillum 16:45, 2008년 7월 28일 (UTC)[응답]으로 남겨두자.

너무 어수선하다고 생각하시는 분들을 위해 사용자 선호를 통해 탈부착 가능한 옵션으로 구현될 수 있다.--코트니스키(토크) 16:54, 2008년 7월 28일 (UTC)[응답]

만약 내가 위에서 퉁명스럽게 굴었다면 미안해.어젯밤에 너무 많이 먹었어.Tan ǀ 39 16:55, 2008년 7월 28일 (UTC)[응답]

이건 아주 좋은 생각이고 이런 일이 일어나지 않도록 막을 만한 것은 아무것도 보이지 않는다. -- 임페라토르3733 (대화) 16:48, 2008년 7월 29일 (UTC)[응답]

도움말 요청

질문 몇 개.

기사가 취소되거나 제목이 리디렉션되면 어떻게 하시겠습니까?

또한, 참고문제의 문제에 대해서, 대부분의 사람들이 접근할 수 없는 서면 자료에 대한 참고문헌을 가지고 있는 것의 이점은 무엇인가(즉, 소유권이다).사람들은 출처의 진실성을 어떻게 확인할 것인가?나는 사람들이 웹에서 접속할 수 있거나 최소한 공공 영역인 소스(그리고 콘텐츠에 대한 비용을 지불하지 않기 때문에 대부분의 경우 웹에서 접속할 수 없는)를 우선시한다고 주장할 것이다.

메놀라우스2 —메넬라우스2가 추가한 서명되지 않은 코멘트 준비 (토크 • 기여) 20:56, 2008년 7월 27일 (UTC)[응답]

첫 번째 질문에 대한 답은 AfD를 통한 삭제는 리디렉션과 매우 다르다; 좋은 편집 요약을 제공하는 숙련된 편집자에 의한 리디렉션은 편집 요약이 없는 경험이 없는 편집자에 의해 시행된 리디렉션과 매우 다르다; 그리고 이 문제가 싸울 가치가 있는지 아닌지에 대한 것이 로에 달려있다.얼마나 많은 토론이 있었는 지의 t.WP를 살펴보십시오.EIW#Delete, 특히 하위 주제 WP:EIW#사후.

온라인에 있지 않은 출처에 대한 언급의 이점은 (1) 세계의 많은 정보가 온라인에 있지 않거나, 공개적으로 온라인에 접속할 수 없으며, (2) 위키피디아가 이 정보를 사용하지 않았다면, 많은 기사에 장애가 될 수 있다는 것이다.위키피디아는 최근의 사건들과 문화적인 문제들만을 다루는 것이 아니다.물론 모든 사람이 이용할 수 있는 온라인 소스는 최소한 제한된 소스나 오프라인 소스와 동일한 품질의 소스가 선호되어야 하지만, 종종 그것은 선택사항이 아니다.편집자가 인용한 오프라인 또는 제한된 출처를 확인하는 것에 대해서는, 편집자가 (a) 논란의 여지가 있거나 의문스러운 정보를 게재하고 있는지, (b) 위키백과에서 (사전 편집으로부터) 신뢰성이 부족한지에 달려 있다.두 조건이 모두 사실이라면 다른 편집자가 출처(다른 편집자가 이용할 수 없는 것은 정의상 믿을 만한 출처가 아니다)를 추적해 검증할 가능성이 크다. -- 존 브로튼(리듬) 19:57, 2008년 7월 27일(UTC)[응답]

안녕, 메놀라우스2

• 만약 당신이 만든 기사가 관리자에 의해 삭제되었다면, 아마도 이 일이 일어나기 전에 그 글에 경고문이 붙어 있었을 것이다.이 통지문에는 왜 기사를 삭제해야 한다고 생각했는지, '위키피디아:삭제 조항"을 참조하십시오.그러므로, 그 문제에 대한 당신의 견해를 제시할 기회가 있었어야 했다.혹시 기사를 보고 있지 않아서 공지를 놓친 건 아닐까?
• 기사가 다른 기사 이름으로 옮겨지거나 리디렉션된 내용으로 바뀌었을 때, 당신이 한 일에 동의하지 않는다면, 당신은 새로운 기사의 토크 페이지에 글을 올리고 그 문제가 논의될 수 있도록 당신의 반대 의견을 설명해야 한다.여러분은 또한 자신의 토크 페이지를 통해 변화를 준 편집자에게 연락하여 기사의 토크 페이지에 그 문제에 대한 토론을 시작했다고 언급하는 것이 좋을 것이다.
• 기사가 제대로 참조되려면 온라인에서 자유롭게 이용할 수 있는 자료뿐만 아니라 구독 전용 자료와 인쇄 자료도 인용해야 하는 경우가 많다.사실, 대부분의 좋은 기사들과 특집 기사들은 그러한 언급들을 많이 인용한다.이것은 최상의 자원이 자문되었는지 확인하기 위한 것이다; 중요한 모든 것을 인터넷에서 구할 수 있는 것은 아니다!만약 당신이 특정 기사의 주제에 특히 관심이 있고 약간의 참고 문헌을 확인하고자 한다면, 당신은 그것들을 찾기 위해 도서관을 방문해야 할 것이다.또는 기사의 일반 편집자에게 연락하여 참조서 사본을 전자우편으로 보낼 수 있는지 물어보십시오.

그런데, 메세지 뒤에 4개의 틸트(~~~)를 타이핑하여 서명과 날짜를 기입한다.— 건배, 잭리 20:04, 2008년 7월 27일 (UTC)[응답]

하위 페이지 "위키피디아:삭제 조항".

또한, 나의 매우 특별한 관심사는 독점적인 정보다.나는 참고문헌이 그 주제를 더 철저히 검토할 수 있는 독자의 능력을 증폭시켜야 한다는 생각이 마음에 든다.그러나 그러한 관점에서 보면, 정보자원은 기사를 얻기 위해 주요 학술센터로 여행할 필요가 없는 자원이어야 한다.메넬라오스2 22:11, 2008년 7월 27일 (UTC)

다시 시도해보겠다:정보자원이 기사를 얻기 위해 주요 학회로의 여행을 필요로 하지 않는 자원이어야 한다고 말할 때, "해야 한다"고 말하는 것이 "해야 한다"는 뜻이라면 틀렸다."해야 한다"는 말이 "해야 한다"는 뜻이라면 맞는 말이다.위키피디아는 단지 쉽게 이용할 수 없다는 이유만으로 현재 중요한 정보를 배제하지 않는다.만약 여러분이 이 두 가지 중 첫 번째 것을 정말로 의미한다면, 여러분은 정책 WP:V의 토크 페이지에 글을 올려야 한다. 왜냐하면 여러분이 제안하고 있는 것은 위키피디아의 작동 방식에 있어서 중대한 변화이기 때문이다.

그리고 기사의 삭제(또는 리디렉션)에 관해서는, 당신이 염려하고 있는 특정 기사를 언급한다면, 정말로 도움이 될 것이다. -- 존 브레본 (리듬) 01:17, 2008년 7월 28일 (UTC)[응답]

나도 동의해 - 유료 접속 전용 학술지는 저주지만, 우리는 그들에 포함된 정보를 무시할 수 없어.적어도 추상적인 것들은 모두 자유롭게 구할 수 있고, 점점 더 많은 작가들이 자신의 논문을 자신의 웹사이트에 올리고 있다(최소한 온라인 복사본이 존재하는지 알아보기 위해 개별적인 논문을 웹 검색하는 것이 가치 있게 만든다) Phyomonas_(talk) 08:27, 2008년 7월 28일 (UTC)[응답]

실제 오픈 액세스를 향한 진전도 있다.미국의 NIH, 영국의 RCUK, 그리고 다른 여러 기관이 후원한 작업에 기초한 모든 기사는 이제 출판된 지 6개월 후 어떤 형태로든 대중에게 공개되어야 한다. 최종 출판판 또는 저자가 최종 수락한 원고.이것은 기본적으로 08년 중반 이후부터 출판된 자료들에 적용되지만, 특히 바이오의학 분야에서 우리의 저자들에게 많은 도움을 줄 것이다.(대학의 연구자들은 즉시 자료를 필요로 하기 때문에, 6개월은 출판사에 큰 피해를 주지 않을 것이라는 개념이다.이에 대한 일반적인 정보를 위해서는 새로운 오픈 액세스 디렉터리 위키(COI--나는 거기서 편집 그룹 중 한 명이다) DGG (토크) 22:18, 2008년 7월 28일 (UTC)[응답]가 가장 좋은 출처다.

메놀라우스는 자신이 정신질환에 대해 편집한 것에 대해 이야기하고 있는 것 같다.Corvus cornix_talk 18:29, 2008년 7월 28일 (UTC)[응답]

그 부분이 바로 비소싱 분석을 기사로 특징짓고자 한다면 기사로의 리디렉션을 바꾼 부분이 될 것이다.어떤 경우, 기사로 리디렉션을 변경하고 변경 내용을 되돌리면 어떻게 하는가?라는 질문이 제기되었어야 하는가?그 대답은 "정말로 리디렉션은 별개의 기사여야 한다고 생각한다면, 리디렉션되는 기사의 토크 페이지에 자신의 주장을 펴서, 실제로 별개의 기사가 있어야 한다는 공감대를 얻을 수 있는지 알아봐야 한다." 입니다. -- 존 브레턴(UTC) 17:11, 2008년 7월 29일 (UTC)[응답]

서명에 "등록" 링크 다시 추가

IIRC, 사용자 서명은 기본적으로 "대화" 링크 외에 "공모" 링크를 가지고 있었다.나는 이 고리를 추적하기가 어렵기 때문에 복권할 것을 제안한다.현재 내가 아는 유일한 방법은 사용자가 편집한 기사의 이력을 보고 편집 일지에서 링크를 얻는 것이다.샤크D (대화) 21:22, 2008년 7월 27일 (UTC)[응답]

링크는 기본 서명의 링크 중 하나를 클릭한 다음 사이드바에서 "사용자 기여"를 검색하여 액세스할 수 있다.해피멜론 21:38, 2008년 7월 27일 (UTC)[응답]

과거에 어떻게 일이 진행되었는지 100% 확신할 수는 없지만, 미디어위키의 역사 탭은 다음과 같다.서명은 사용자 기여의 링크가 등록된 편집자의 기본 서명의 일부였다는 증거를 보여주지 않는 것 같다. -- John Brown (식별) 01:21, 2008년 7월 28일 (UTC)[응답]

링크는 사용자의 대화 페이지의 도구 상자에 있다.프로데고 01:22, 2008년 7월 28일 (UTC)[응답]

내 기억은 내게 장난을 치고 있는 게 틀림없어, 왜냐하면 나는 그것이 거기에 있었다고 거의 확신하기 때문이야.그리고 당신이 제공한 사용자 도구 상자 링크는 꽤 쉽다.샤크D (대화) 23:40, 2008년 7월 28일 (UTC)[응답]

사실, 미디어위키:서명은 상당히 새롭다.기본 서명에 토크 링크를 추가할 수 있도록 추가되었다.미디어위키 페이지가 소개되기 전, 나는 서명이 단지 사용자 페이지에 대한 링크였다고 믿는다.애논의 서명은 항상 콘티브에 연결된다.Mr.Z-man 23:57, 2008년 7월 28일 (UTC)[응답]

거의.많은 사람들이 기여를 위해 링크를 추가했지만 우리 중 일부는 대화 페이지로 연결되는 링크가 과도하다고 생각한다.Geni 15:46, 2008년 7월 29일 (UTC)[응답]

아티클 히스토리의 컷오프 날짜 입력 필드

기사의 History 페이지에 시작 날짜와 종료 날짜 필드가 추가되도록 요청하고 싶다.자주 편집되는 페이지(예: 토크 페이지)의 오래된 차이점을 찾는 것은 현재 매우 지루한 작업이다.브라우저의 주소 표시줄에 날짜를 입력할 수 있지만, 먼저 "구 100" 링크를 클릭하는 추가 단계가 필요하다.또한 내 브라우저(Avant+)에서IE7) 브라우저가 포커스를 해제할 때 주소 표시줄이 재설정되므로 텍스트 편집기에서 복사/붙여넣을 때 문제가 발생할 수 있다.샤크D (대화) 03:00, 2008년 7월 30일 (UTC)[응답]

분기품

User에서 제안서를 작성 중:Phil Sandifer/Branching은 우리가 일반적으로 하나의 주제로 간주되는 것을 다루기 위해 여러 페이지와 기사를 사용하는 영역을 더 잘 다룬다.아직 기술적 구현이 좀 남아 있고, 기존의 하위조항 기능성을 활용할 것인지, 아니면 이를 다룰 템플릿 기반 시스템을 만들 것인지 등 결정해야 할 사항들이 있지만, 기본 제안이 거기에 있고, 이에 대한 의견과 이행 진행 방안에 대한 생각을 환영한다.

서브 아티클을 사용하여 실행 중인 제안의 예는 User:Phil Sandifer/Heroes, 내가 TV에서 보도한 많은 (전부는 아니지만) Heroes를 분기 형식으로 방송한 곳.모든 라이브 링크는 분기 구조 내에 있으므로 자유롭게 둘러보십시오.필 샌디퍼 (대화) 2008년 7월 16일 (UTC) 20:44[응답]

여기서 보여지듯이 위키백과 소프트웨어는 기사 공간에 하위 페이지를 허용하지 않는다 - 당신이 제안하는 것처럼 보인다.그래서 그걸 바꾸기 위해서는 공감대가 존재한다는 것을 증명해야 할 것이다. -- 존 브레튼 (식용차) 00:47, 2008년 7월 17일 (UTC)[응답]

사실, 나는 그것을 템플릿으로 하는 것을 제안한다.그러나 내가 알 수 있는 한, 기사 공간에서 하위 페이지를 비활성화하는 이유는 합의된 내용에 기반한 것이 아니라 기술적인 것이다. 아무도 기사 공간 하위 페이지를 사용하지 않았고 OS/2와 같은 기사에 문제를 일으켰다.그래서 그들은 아무도 그들을 그리워하지 않을 것으로 예상되었기 때문에 장애인이 되었다.나는 그것들을 사용하지 않기로 한 적극적인 결정의 기록을 찾을 수 없다 - 내가 말할 수 있는 한, 그것은 부수적인 것이었다.그리고 어떤 경우든, 내가 말했듯이, 템플릿은 OS/2 문제에 있어서, 부분적으로 이것들을 위한 인터페이스가 우리의 기본 하위 페이지 인터페이스보다 더 잘 보여야 하기 때문에 더 나은 기능을 제공한다고 생각한다.필 샌디퍼 (대화) 01:08, 2008년 7월 17일 (UTC)[응답]

크리켓 사람들은 몇 년 전에 비슷한 것을 시도했다.인기가 없었다.우리는 항상 템플리트를 가지고 장난치는 것보다 더 잘 작동하기 위한 일련의 독립된 기사들을 찾아냈다.Geni 12:13, 2008년 7월 17일 (UTC)[응답]

나는 크리켓이 실험 대상 지역이라고 생각했을 것이라고 말할 수 없다. 하지만 나는 그들의 노력을 보고 싶다.하지만 내가 제시하는 세 가지 구체적인 예를 보십시오. 예를 들어 조지 W. 부시가 지사를 통해 조직화되면 훨씬 더 깨끗해질 것이고, 자크 데리다와 같은 기사가 더 잘 정리된다면 훨씬 더 잘 읽을 수 있을 겁니다.허구적인 주제에 대한 명백한 이익은 말할 것도 없다.위키프로젝트 한 곳에서 그것이 시도되고 부족한 것으로 발견되었다는 것이 나에게는 그렇게 중요한 장벽으로 보이지 않는다.내 말은, 특히 시티즌디움에 꽤 잘 작동하는 버전을 가지고 있다는 거야. 그리고 그것이 우리가 하는 것보다 확실히 더 낫다고 생각하는 몇 안 되는 특징 중 하나야.그래서 분명히 분기/하부 골격 구조가 작동할 수 있다.필 샌디퍼 (대화) 2008년 7월 17일 (UTC) 15:28[응답]

실제로 하위 페이지를 제거하는 것은 소프트웨어 업그레이드의 일부분이지 미사용 기능만이 아니었다.초기의 소프트웨어는 뚜렷한 네임스페이스가 없었고, 예를 들어, 모든 대화 페이지가 기사 하단에 /Talk 링크를 추가하도록 만들어졌다.위키백과의 토론:하위 페이지/아카이브에서는 기사 제목이 허용되지 않은 이유에 대해 몇 가지 설명을 제공한다.Rmhermen (대화) 2008년 7월 17일 (UTC) 17:21[응답]

그러나 분명히 하위 페이지는 여전히 문서 네임스페이스 외부에서 활성화되어 있다.대부분의 경우 서브페이지는 괄호를 통해 더 잘 해결된 문제에서 잘못된 해결책이었고, 네임스페이스의 확산과, 지금은 매우 다른 시기라는 것을 알 수 있다. 서브페이지는 시티즌디움에서 기본적으로 구현한 래리에게 주목할 필요가 있다.즉, 나는 그들을 비난하려는 이른 결정이 강한 구속력을 가지고 있다고 생각하지 않는다.필 샌디퍼 (대화) 21:57, 2008년 7월 17일 (UTC)[응답]

필의 요점으로 돌아가면, 이것은 (특히 소설의 영역에서) 공신력에 대한 논의에서 나온 것이기 때문에, 페이지 주제에 무엇인가를 추가하는 것이 (디르식 하위 기사 접근법인지, 아니면 분기 본질을 설명하는 템플릿인지) 의도된 기사를 즉시 식별하는 데 유용할 것이라는 의견이 제시되어 왔다.큰 화제의 취재로 간주되다이 중 일부는 그 페이지에 대한 문제인 자신의 불신성을 입증해야 하는지 아닌지를 뒷받침하는 기사에 의해 제기된다. 그러나 만약 당신이 그것을 주목할 만한 하위 페이지가 많은 제2차 세계 대전과 같은 더 큰 주제로 생각한다면, 사용자들을 돕기 위해 페이지 맨 위에 그러한 표시를 두는 것이 말이 되는가?더 큰 주제를 탐색하시겠습니까? --MASEM 17:40, 2008년 7월 17일 (UTC)[응답]

그리고 적어도 어떤 경우에는 그렇다라고 답할 수 있다고 생각한다.분명히 드와이트 아이젠하워는 어떤 종류의 하위 조항이 되어서는 안 되지만, 나는 제2차 세계대전의 모조 기사 아래 제2차 세계대전에 관한 우리의 기사들을 붕괴시키는 것이 유용한 조직 도구가 될 수 있다고 생각한다.필 샌디퍼 (대화) 21:36, 2008년 7월 17일 (UTC)[응답]

나는 WP를 너무 좋아하게 된 것 같다.시리즈 및 WP:이 제안을 객관적으로 판단하기 위한 요약.그러나, 나는 그러한 접근방법의 가치가 시간이 지남에 따라 입증되었다고 생각한다. 예를 들어 위키백과 1.0 프로젝트나 One Laptop Per Child에서 기사가 오프라인으로 사용될 수 있도록 허용하기 때문이다. --Hroðulf (또는 Hrothulf) (Talk) 06:33, 2008년 7월 18일 (UTC)[응답]

나도 동의해 - 하지만 독립형 기사들은 너무 길어지기 때문에 잘 작동하지 않는 주제가 있어.조지 W. 부시는 많은 기사의 대상이며, 그래야 한다.이것은 그 기사들을 더 잘 정리하기 위한 제안이다. 단 한 장으로 잘 작동하는 것들을 나누기 시작하는 것이 아니라.필 샌디퍼 (대화) 2008년 7월 18일 (UTC) 14:51, 응답

그러나 아이젠하워는 분명히 미국 대통령들의 하위 페이지가 되지 않을까?누가 이러한 결정을 내리고 얼마나 자주 그리고 어떻게 일관성 있게 수행될 것인가?기사 시리즈 상자는 일부 기사(내가 추가한 일부 기사 포함)에서 여전히 사용된다.사실, 나는 그것들이 2차 세계 대전 기사에 사용되었다고 믿는다. 그것은 현재 대부분의 링크를 내가 그들이 눈치채지 못하는 페이지의 맨 아래에 접을 수 있는 상자에 숨기고 있다.Rmhermen (대화) 2008년 7월 18일 (UTC) 14:29 [응답]

아니. 한 가지 여러분이 그 제안을 본다면, 나는 어떤 기사가 그럴듯하게 다수의 부모를 가질 수 있는 곳에 가지를 쳐서는 안 된다는 것에 주목함으로써 이 문제를 아주 분명하고 조심스럽게 차단하려고 노력했다는 것을 알게 될 것이다.그래서 아이젠하워는 2차 세계대전이나 미국 대통령들로부터 분기되어서는 안 된다. 왜냐하면 그는 두 가지 모두에서 분기할 수 있기 때문이다.그러나 나는 일반적인 반대를 보았고, 그것을 막으려고 노력해왔다.중요한 것은 나는 이것을 어디에서나 해야 하는 것으로 보지 않는다는 것이다 – 그것은 특정 유형의 기사에 좋은 특정 도구, 즉 이미 사실상의 하위 페이지인 많은 페이지를 생성해 놓은 것이다.그 제안은 기사를 하위 페이지로 분할하기 시작하는 것이 아니라, 우리가 이미 가지고 있는 것은 분명하지만 분별 있게 정리하지 않고 있는 하위 페이지들을 정리하기 시작하는 것이다.필 샌디퍼 (대화) 2008년 7월 18일 (UTC) 14:51, 응답

부모가 여러 명이라고 주장할 수 없는 것은 없다.Geni 21:46, 2008년 7월 18일 (UTC)[응답]

하지만, 아마도 훨씬 더 제한적인 것들이 있을 것이고, 사람들은 실제로 그것이 여러 부모를 가지고 있다는 것에 동의하게 될 것이다.나는 사람들이 칸트의 작품을 임마누엘 칸트 밑에 보금자리하는 것보다 훨씬 더 쉬운 시간을 가질 것이라고 생각한다.내 말은, 난 이게 실제적으로 중요한 문제라는 걸 전혀 믿지 못하겠어.조지 W 부시 대신 '조기생활'이 유년기의 하위조항이라고 생각하는 사람들과 마주칠 것 같지는 않다.특히 어린 시절의 특정 지점에서 기인해야 한다는 점을 감안할 때 말이다.여기서 그 아이디어의 일부는 갈겨진 기사가 이론적으로 선형 전체로 재조립될 수 있다는 것을 기억하라.이것은 범주보다 훨씬 더 경직된 계층 구조다.필 샌디퍼 (대화) 22:13, 2008년 7월 18일 (UTC)[응답]

칸트는 훌륭한 작가다.그의 작품들은 18세기 철학이 아니다?조지 W. 부시의 어린 시절은 미국 대통령들의 형성기에 속한다.사물을 개인과 결부시키는 편향적인 성향이 나타나고 있다.나는 당신이 롤 운하를 제임스 그린(엔지니어)의 하위 기사로 만들 것이라고 생각한다.Geni 22:30, 2008년 7월 18일 (UTC)[응답]

지니, 너 지금 진심이야?당신이 여기서 제안하는 것 중 어느 것도 아닌, 미국 대통령들의 형성기(Formative years of US Presidents) 아래에서의 어린 시절(그것조차 기사인가?)을 읽어보십시오. 개인주의 문제 때문이 아니라, 그런 기사를 결코 해체하지 않기 때문에. 18세기 철학(아마도, 나는 말할 수 없지만, 기사일 것이다.)'빨간 고리가 되었다면 놀랄 것이다'라고 하면 - 어쩌면 일 때문에 무너질지도 모르지만, 나는 꽤 의심스럽다 - 일반적으로 철학자들은 논리 정연한 체계를 가지고 있는 것으로 취급되기 때문에, 칸트는 그러한 기사에서 독자적으로 다루어질 것이다.내 말은, 어서.필 샌디퍼 (대화) 22:39, 2008년 7월 18일 (UTC)[응답]

그래서 당신은 우리가 개인에 의한 것이 아닌 미국 대통령들의 형성기사를 어떻게 분류할 것을 제안할 것인가?Geni 22:50, 2008년 7월 18일 (UTC)[응답]

나는 우리가 어떻게 그리고 왜 그것에 관한 기사를 가지고 있는지 상상하려고 애쓰고 있다. 하지만 만약 우리가 그것을 가지고 있다면 그것은 주제별로 정리되어 전체적인 주제에 대한 포인트가 명확해졌고 그것이 단지 전기의 목록이 아니었다는 것을 상상할 것이다.만약 우리가 실제로 미국 대통령들의 형성 연도에 관한 기사를 쓴다면, 아마도, 그것은 주로 이러한 형성 연도에서 어떤 경향과 유사성을 발견할 수 있는지에 관한 것이 될 것이다.필 샌디퍼 (대화) 23:07, 2008년 7월 18일 (UTC)[응답]

왜? 일련의 짧은 바이오스를 통해 균등하게 조합할 수 있고 대조군을 끝까지 저장할 수 있다.범주 시스템은 무규모로 나타나는데, 이것은 부모 자식 관계를 관절에 강제하려는 시도가 자금적으로 결함이 있다는 것을 암시한다.Geni 23:43, 2008년 7월 18일 (UTC)[응답]

지니, 당신은 존재하지 않는 기사가 어떻게 조직될 수 있는지 때문에 조직적인 계획에 반대하시는 겁니다. 비록 그것이 이 가상의 기사를 조직하는 완전히 바보 같은 방법이 될 수도 있지만, 그것은, 내가 다시 말하지만, 그것은 존재하지 않는다.현장 현실과 유사한 어떤 것에 근거한 것 같지 않기 때문에 어떻게 당신의 반대를 충족시킬 수 있을지 모르겠다.Phil Sandifer (토크) 00:38, 2008년 7월 19일 (UTC)[응답]

이게 범주가 하는 짓이야, 확실히?90:11 22:03, 2008년 7월 18일 (UTC)[응답]

범주 또는 적절한 탐색 상자는 이를 수행할 수 있다.문제는 그것을 발견하려면 페이지 하단으로 스크롤해야 한다는 것이다.같은 대목에서 잘 쓴 리드(lead)는 한두 문장 안에 더 큰 글의 아들로 보아야 하지만 모든 리드가 잘 쓰여져 있는 것은 아니라는 점을 분명히 명시해야 한다. --MASEM 22:09, 2008년 7월 18일 (UTC)[응답]

그래서 그것들을 맨 위에 올려놓은 피부를 사용하라.Geni 22:50, 2008년 7월 18일 (UTC)[응답]

카테고리 시스템은 주제 요소들 간의 관계에 대한 감각을 제공하지 않는다.상부에 있든 하부에 있든 상관없다, 당면한 업무에는 전혀 불충분하기 때문이다.Phil Sandifer (토크) 00:38, 2008년 7월 19일 (UTC)[응답]

기사들은 하나의 주제 영역에 속한다.Geni 00:48, 2008년 7월 19일 (UTC)[응답]

아니. 하지만 몇몇 기사는 분명히 부모 기사의 하위 주제야.아무도 진지하게 조지 W. 부시의 초기 어린 시절이 조지 W. 부시의 하위 주제가 아니며, 아버지의 이름이 주로 자크 라칸의 하위 주제가 아니라고 제안하지는 않을 것이다.이것은 여전히 우리 기사의 대다수는 아니지만, 심지어 우리 기사의 "feew"조차도 많은 기사들이다.Phil Sandifer (대화) 2008년 7월 19일 (UTC) 00:54[응답]

범주는 여러 기사에 걸쳐 실을 추적하는 좋은 도구로 보인다.하지만 그들은 서로에 대한 기사를 실제로 정리하지 않는다.필 샌디퍼 (대화) 22:13, 2008년 7월 18일 (UTC)[응답]

왜냐하면 우리가 배운 기사들이 서로 당신이 제안하는 방식과 관련이 없기 때문이다.Geni 22:50, 2008년 7월 18일 (UTC)[응답]

발로니.조지 W. 부시는 기본적으로 이미 이런 식으로 쓰여져 있다.많은 다른 주제들이 그렇다.우리는 페이지 길이로만 해야 하는 이유로 기사를 일상적으로 나누었다.이것은 우리가 주제의 전체적인 일관성을 잃지 않고 그렇게 하도록 한다.Phil Sandifer (토크) 00:38, 2008년 7월 19일 (UTC)[응답]

음, 만약 이미 그런 식으로 쓰는 것이 가능하다면, 바꿀 필요가 없을까?그리고 당신은 당신의 방법에 대한 일관성을 잃는다.내가 GWB의 어린 시절을 세 번째 기사에서 언급했다고 가정하자.이제 컨텍스트 문제가 있는 하위 기사나 여름에만 해당되는 주요 기사를 링크하시겠습니까?Geni 00:48, 2008년 7월 19일 (UTC)[응답]

그렇게 쓰는 것이 위키피디아와 같은 가이드라인에 문제를 일으키는 추악한 해킹이라는 것만 빼면:명성.그리고 GWB의 어린 시절이 언급되었을 때 다른 곳에서 우리가 하이퍼링크를 하는 것을 막는 것은 아무것도 없다.이 모든 것은 GWB에 대한 전반적인 취재 조직에서 어린 시절의 기사가 분명히 분기되는 시점이 올 것이라는 것이다.다른 점들은 어려움 없이 그 점에 하이퍼링크를 할 수 있다 - 우리는 다른 기사에서 문제없이 단면간 위키링크를 한다.그리고 나는 왜 우리가 GWB에 대한 우리의 보도를 우리가 그의 어린 시절을 요약하고 싶은 두 개의 별도 포인트를 가지고 있지 않고서는 정리할 수 없을지 잘 모르겠다.사실, 만약 우리의 보장이 우리가 그 문제를 가지고 있을 정도로 조직화된다면, 우리는 아마도 그것을 나쁘게 조직했을 것이라고까지 말하고 싶다.Phil Sandifer (대화) 2008년 7월 19일 (UTC) 00:54[응답]

그래서 내가 링크하고 싶은 내용을 이해하려면 분리된 기사를 통해 링크해야 한다?지니 02:02, 2008년 7월 19일 (UTC)[응답]

그게... 지금이랑 다른거야?필 샌디퍼 (대화) 03:13, 2008년 7월 19일 (UTC)[응답]

이런 식으로 관련되는 기사가 있다.문제는 그들이 누구인지를 결정하고 그것에 동의하는 것이다.WP:시리즈는 이미 이와 같은 일을 하고 있다고 생각한다.Rmhermen (대화) 23:33, 2008년 7월 18일 (UTC)[응답]

나는 이 운동에 강력히 동의한다.단일 개념을 다루고 있지만 정보가 너무 방대해져서 한 페이지에 올릴 수 없을 때, 분기된 페이지들은 반드시 중요한 개념의 일부분일 수밖에 없는 공식적인 구조를 갖는 것이 훨씬 낫다.주의사항: 이 구현은 단순하고 우아하며 자동적일 필요가 있다.II (t - c) 00:10, 2008년 7월 19일 (UTC)[응답]

기존의 하위 페이지 아키텍처를 사용하거나 하위 페이지와 유사한 기사 이름을 사용하지만 Mediawiki 대신 템플릿을 통해 이름을 처리함으로써 OS/2가 자동으로 "OS"라는 하위 조항 "2"로 처리되지 않도록 하는 두 가지 좋은 방법을 볼 수 있다.어느 쪽이든 무거운 리프팅은 기사 제목과 일부 템플릿 코드로 해야 한다.Phil Sandifer (talk) 00:40, 2008년 7월 19일 (UTC)[답답하다]

• 필, 나는 우리가 어떻게든 하위 주제들의 백과사전적 포함을 보호한다는 개념이 마음에 드는데, 상위 기사는 다루기 어려워지지만 하위 주제들은 개별적으로 GNC를 충족시키지 못한다.하지만 나는 특별한 템플릿과 소프트웨어가 필요하다고 생각하지 않는다.그냥 프로젝트와 비슷한 내용의 태그를 토크 페이지 상단에 붙이면 되지 않을까, 하위 페이지로서의 글의 성격과 합리적인 면을 설명하면 어떨까.남용에 허점을 만들지 않으면서 서브 페이지 삭제를 피하려는 것이다.우리는 AfD에서 살아남는 기사로 이것을 하며, 이전의 AfD 논의와 연결고리를 제공함으로써 지속적인 포용의 합리적이다.우리의 태그를 (AfD 형식의) 포함에 대한 합의가 선행적으로 입증되는 RfC에 연결하여 AfD를 선점할 수 있을까? --Kevin Murray (토크) 23:49, 2008년 7월 25일 (UTC)[응답]
  • 만약 당신이 제안하는 것처럼, 그러한 하위 페이지를 보관하는 것에 대한 합의가 있다면, 그들이 AfD로 간다면 왜 문제가 되겠는가?그 다음엔 그들을 유지하는 것이 합의점이 될 것이다.만약 그들이 AfD에서 삭제된다면, 음, 그렇다면, 그들을 주변에 두거나, 태그를 달거나, 태그를 달거나, 하위 조항이나, 하위 조항이 없는 것에 대한 합의는 없다.세라핌블레이드^{Talk to me} 08:10, 2008년 7월 26일 (UTC)[응답]
    • 왜냐하면 나는 AfD가 잘 작동하지 않는다고 생각하기 때문이다.만약 괜찮은 기사가 AfD에 도착한다면 그것은 즉시 편견에 직면하게 되고 (예를 들어 무죄가 입증될 때까지 유죄) 삭제-잘로트, "드라이브 바이" 참가자, 그리고 세계에서 가장 친환경적인 관리자가 되려고 하는 무지한 신입들로부터 자동적으로 반대하게 된다.나는 AfD를 통해 많은 기사가 개선되는 것을 보았지만, 모든 것은 그날 누가 거기에 있고 그들이 기사나 작가를 "멘토"하기 위해 얼마나 많은 에너지를 소비하느냐에 달려 있다.나는 연구를 하고 다시 쓰는 힘이 있다면 전형적으로 하루에 약 2개의 기사를 저장할 수 있다.나는 "객관적인" 포함 기준을 "입법"하는 시도는 결함이 있다고 본다. --우리는 포함 선택에 논리적이나 주관적인 지침을 적용하기 위해 더 나은 과정이 필요하다. --케빈 머레이 (대화) 2008년 7월 26일 (UTC)[응답]
      • 나는 그것에 동의하지 않는 경향이 있다고 생각한다.나는 AfD가 잘 작동하지 않는다는 것에 동의하지만, 아마도 당신이 말하는 의미로는 아닐 것이다. 나는 개선 불가능한 쓰레기가 너무 많이 남아 있고 품질 관리에 대한 강조가 너무 적다고 본다.나는 "이 주제에 대해 상당한 범위를 제공하기 위해 독립적이고 신뢰할 수 있는 출처를 선택하였는가, 그렇지 않은가?"라는 객관적 포함 표준에 문제가 없다고 본다.어느 쪽이든 우리는 그들의 선례를 따른다.만약 그들이 그것에 상당한 독립적 커버리지를 제공했다면, 그리고 그것이 우리의 포함 정책에 부합한다면, 우리는 기사를 쓴다.만약 그들이 부모 주제의 맥락에서 간략하게 다루었다면, 우리는 부모 주제의 맥락에서 간략하게 다루었다.그들이 전혀 취재를 거부했다면 우리는 아예 취재를 거부한다.우리는 우리 글의 다른 어떤 분야에서도 출처를 추측하지 않는다. 무엇을 포함시킬지, 그리고 어떻게 포함시킬지를 결정할 때 왜 그렇게 해야 하는가?세라핌블레이드 20:11, 2008년 7월 27일 (UTC)[응답]
• 필의 진취성은 좋은 것 같다.현재 AFD 후보 중 관련성이 있는 것으로 보이는 몇 가지 사항을 참고하십시오.

• 매거진 이슈 목록
• 매드의 영화 스푸프 목록

이것들은 분명히 매드 매거진에 대한 우리의 보도에 좋은 부록이고 우리는 AFD에서 시간 낭비를 피하기 위해 더 나은 공식적인 구조가 필요하다. AFD는 둘 다 유지될 것 같다.워든 대령 (대화) 11시 55분, 2008년 7월 28일 (UTC)[응답하라]

• 마을 펌프를 둘러보던 중, 나는 조금 전에 같은 방향으로 몇 가지 생각을 적어 놓았음을 알아차렸다. 사용자:B를 참조하십시오. 월터딩/신규 하위조항 개념생각의 음식으로서 좋을 수도 있고, 기사 공간 등에서 이전에 사용했던 하위 페이지들과 연결될 수도 있다 --B.B. 월터딩 (대화) 17:42, 2008년 7월 30일 (UTC)[응답]