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

스티븐 콜버트에게 보내는 편지

나는 우리가 스티븐 콜버트에게 편지를 쓸까 생각중인데, 그 이유는 두 가지 때문이다. (1) 모든 반달들은 명령에 따랐을 뿐이기 때문에 완전히 책임이 있는 것은 아니다. 그래서 공식적인 정책에 따라 우리는 출처(Stephen Colbert)와 (2)가 위키백과를 홍보한 것에 대해 그에게 감사하도록 경고해야 한다.생각나는 거 있어?제프리클라이캄프 21:31, 2007년 6월 23일 (UTC)[응답]

우리한테서 온 편지로 만들려면 모두 편집을 허용해야 할 것이다.너한테서 온 편지 보관하는 게 좋을 것 같아.λυΔαcγγγ 23:01, 2007년 6월 23일 (UTC)[응답]

"문자"를 클릭하면 누구나 편집할 수 있는 실제 문자에 대한 링크 입니다.제프리Kleykamp 23:04, 2007년 6월 23일 (UTC)[응답]

누군가 이렇게 해야 한다면 위키미디어 재단이 되어야 한다고 생각한다.왜 그들에게 맡기지 않는가?나는 우리 반달파이터들도 콜버트 보고서를 보는 한 그것이 정말 문제가 되지 않는다고 생각한다.;) — 미치광이 범인과 천사 (대화 – 책상) 23:13, 2007년 6월 23일 (UTC)[응답]

(갈등 편집) 나는 네 편지의 내용에 전적으로 반대한다.만약 우리가 연예인에게 편지를 보내서 실제로 읽고 듣기를 원한다면, 우리는 그것이 매우 잘 고려되어야 하며, 아마도 그것은 지미 웨일즈 재단에서 온 것일 것이다.템플리트 된 {{Uw-vandalism1}메시지 같은 것은 아무 것도 이루지 못할 것이다.—METS501 (토크) 23:16, 2007년 6월 23일 (UTC)[응답]

나는 편지를 현재 형태로 보낸 것에 대해 긍정적인 결과를 상상할 수 없고, 어떻게 그것이 인양될 수 있는지 모르겠다.잠깐 생각해봐.강력한 행정가들은 스티븐 콜버트가 사람들에게 우리 웹사이트를 파괴하지 말라고 경고하고 있다.대답하는 게 좋을 거야 그렇지 않으면...우리가 막을 거야?화난 이메일을 더 보낸다고?아, 알아, 우리는 그의 기사에 "Stephen Colbert는 위키백과의 큰 비열한 존재야!"라는 항목을 넣을 거야.씨몬, 진짜야. - 체어보이 (인터뷰) 23:25, 2007년 6월 23일 (UTC)[응답하라]

사람들은 편지를 편집하고 서명할 수 있는데, 나는 50명 이상의 위키피디아인 (등록된 사용자의 0.001%)이 서명을 한다면, 그가 듣도록 하는 것으로 충분할 것이라고 확신한다.그리고 또, 연예인에게 편지를 쓰는 것은 정말 그렇게 어렵지 않다, 사람들은 힘들다고 생각하지만 연예인들은 그렇게 바쁘지 않다, 게다가 만약 신문이나 다른 형태의 뉴스가 보도된다면, 그는 결국 그 편지를 읽게 될 것이고, 그것이 우리가 쓴 것이기 때문에, (콜버트 씨와 인터뷰를 한) 지미 웨일즈 씨는 아마 콜버트 씨나 콜버트 씨에게 주는 것도 마다하지 않을 것이다.적어도 전화해서 봐야 한다고 말하고, 게다가 스티븐 콜버트가 지미 웨일즈와 인터뷰를 했을 때, 그는 위키피디아를 좋아하고 자주 사용했다고 말했다.그리고 마지막으로 스티븐 콜버트(사람)는 위키피디아를 좋아하고 스티븐 콜버트(캐릭터)는 사람들에게 위키피디아를 파괴하라고 말하는 것을 좋아하며, 이 편지는 스티븐 콜버트(캐릭터)에게 쓰이고, 그는 콜버트 보고서에만 존재하며, 우리가 답을 기대할 수 있는 곳에 그가 더 많이 파괴한다고 말할 수 있지만, 그것이 정말 문제야.Andalism은 위키피디아를 편집하는 더 많은 사람들을 의미한다.제프리Kleykamp 23:37, 2007년 6월 23일 (UTC)[응답]

존경심을 가지고 이 편지가 어떻게 접수될지에 대한 현실적인 분석을 수행했다고는 생각하지 않는다. - CHIERBOY (인터뷰) 23:44, 2007년 6월 23일 (UTC)[응답]

그럴 수도 있지.제프리Kleykamp 23:45, 2007년 6월 23일 (UTC)[응답]

그의 IP 주소를 알아내서 타인에게 반달리즘을 하라고 한 것에 대해 직접 경고하는 것은 어떨까(개인적으로 반달리즘을 하는 것과는 다르다).우리는 그가 어디에 살고 있는지 알고 있고 우리는 그가 지미 웨일즈와의 인터뷰 당시에 그가 인터뷰에서 그렇게 말했기 때문에 차단되었다는 것을 알고 있다.제프리Kleykamp 23:51, 2007년 6월 23일 (UTC)[응답]

콜버트 리포트의 에피소드가 생방송되지 않는 것을 보면 날짜/시간을 상관할 수 없을 것이다.게다가, 웨일즈나 위키미디어 재단도, 현재 상태로는, 당신이 편지를 보낼 수 없었던 것과 아무 관련이 없을 것이라고 장담할 수 있다.— 미친 범인과 천사 (대화 – 책상) 00:12, 2007년 6월 24일 (UTC)[응답]

다시 보면, 그 편지는 문법적이지 않을 뿐만 아니라 모순된다.보낼 거면 네가 대신 보내라.지역사회가 그 일에 관여하지 않도록 해.— 미친 범인과 천사 (대화 – 책상) 00:26, 2007년 6월 24일 (UTC)[응답]

내가 삭제를 요청했어, 멍청한 생각이었어. 시간을 낭비해서 미안해.제프리Kleykamp 13:21, 2007년 6월 24일 (UTC)[응답]

너네들은 미친 듯이 편지 한 통을 제안해서 집단으로 모였어! 그게 계획되어 있는 한 좋은 생각이었던 것 같아.존 콜버트(캐릭터)에 관한 페이지를 만들어 오늘의 기사로 특집하는 것은 어떨까.그렇게 하면 많은 ppl이 그것을 볼 수 있을 것이다.그걸 어떻게 생각해?왜 그렇게 빨리 아이디어를 죽이지?그것은 비현실적이라는 것 외에는 이성적인 논의조차 하지 않았다.나는 Jeff와 함께 있다.비탈리스멜킨 2007년 6월 27일 14:23 (UTC)[응답]

스티븐 콜버트(캐릭터)

그는 아무런 해를 끼치지 않았지, 그렇지?결국 그가 한 일은 그 사이트를 홍보하는 것뿐이다.문제가 뭐죠?— 오메가트론 01:50, 2007년 7월 2일 (UTC)[응답]

토크 헤더

{{talkheader}}}}은(는) 위키백과의 모든 단일 토크 페이지에 추가되는 훌륭한 코드처럼 보인다.왜 그것이 표준인가?왜 모든 위키 기사에 자동으로 토크 헤더를 추가하는 봇이 있는가? (이미 만들어진 모든 토크 페이지에 적어도 하나를 추가)이런 일이 전에도 논의된 적이 있다면 미안한가? 이런 사소한 일이 생겨서는 안 될 것 같은데?내 말은, 토크 헤더는 문제 기사만을 위한 것인가?왜냐하면 나는 위키피디아에 관한 기본사항을 알아내는 신입생이 그것과 그것의 링크에 대한 정보가 매우 적절하다고 생각하기 때문이다.나중.petze 07:24, 2007년 7월 6일 (UTC)[응답]

제발 안돼, 다른 템플릿이 자동으로 대화 페이지에 올라오지 마.:) 이미 위키백과 주제의 템플릿으로 가득 차 있다.당신이 토론 페이지와 링크 와아 블루를 클릭하곤 했을 때, 당신은 거의 확실히 토론 페이지에 실제 토론이 있다는 것을 알았다.이제 링크가 파란색일 때 그것은 자주 중요하지 않다. 그것은 보통 템플릿으로만 가득 차 있다.네가 말한 템플릿은 꼭 필요한 경우에만 토크 페이지에 올려야 한다.조지 W 부시에서는 템플릿이 타당하지만 펜실베니아 주 세실 타운쉽(랜덤 기사)에서는 예를 들어 그럴 필요가 없다.가리온96(토크) 07:56, 2007년 7월 6일 (UTC)[응답]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ어쨌든, 내가 말했듯이, 그것은 이미 내용이 있는 모든 토크 페이지에 추가될 수 있는가?하지만 네 오른쪽 반응이 말이 되는 것 같아.빠른 답장 고마워.petze 08:06, 2007년 7월 6일 (UTC)[응답]

나는 이 템플릿의 주요 용도가 토론이 주제에서 벗어난 토크 페이지라고 생각한다.만약 내가 틀렸다면, 나에게 알려주고, "is"를 "있어야 한다"로 편집해줘.— The Storm Surfer 09:39, 2007년 7월 6일 (UTC)[응답]

페체, 위키피디아는 WP:임의의 채팅 포럼이 아님.올바른 영어를 사용하십시오.레이와스92^Talk 14:29, 2007년 7월 6일 (UTC)[응답]

그러한 템플릿을 사용하는 것은 전적으로 사용자의 재량에 달려있다 - 만약 편집자가 새로운 위키백과 사용자들과 지속적으로 접촉한다면, 그 편집자의 대화 페이지에 글을 올릴 때 그들에게 유용한 참고 자료를 제공하는 것이 그들에게 매우 유익하다.모든 편집자가 새로운 사용자들과 접촉하는 것은 아니다. 또는 그러한 템플릿이 오직 새로운 사용자들만을 위해 존재한다는 것(때로는 숙련된 편집자들에게도 상기시키는 것이기도 하다)이 아니라, 사용자들의 토크 페이지가 레이아웃을 위해 얼마나 그들의 선택에 달렸는지(어느 정도는) 알 수 있다.그들은 그것과 비슷하지만 그들만의 깃털이나 기교로 그들만의 템플릿을 만들고 싶어할 것이다.그 자동태그를 그들의 토크 페이지에 붙이는 것은 그들을 위한 노력을 저해할 것이다. --Ozgod 00:50, 2007년 7월 8일 (UTC)[응답]

• 우리는 아마도 미디어위키 토크 페이지 헤더에 그런 것을 추가할 수 있을 것이다. (특히 사람들이 그것을 끌 수 있도록 css 클래스와 함께 하는 것이 좋다.나는 토크헤더 템플릿이 그렇게 유용하다는 것을 결코 발견하지 못했다. 그것은 단지 당연한 것을 다시 말해준다.>래디안트< 12:56, 2007년 7월 9일 (UTC)[응답]

끌어서 놓기

카테고리 실수를 어떻게 없애야 할지 고민할 필요 없이 카테고리와 하위 카테고리를 올바른 위치로 끌어낼 수 있다면 좋지 않을까?폴 벤터 2007년 7월 2일(UTC) 20:00[응답]

우리가 나이가 더 들면 좋지 않을까(그러면 그렇게 오래 기다릴 필요가 없을 텐데?) …나는 도움이 안 돼 ~ sublime514 • 대화 • 서명 2007년 7월 3일 02:23 (UTC)

기사입양도

나는 우리가 "기사 채택" 제도를 만들어야 한다고 생각한다.당신은 채택이 필요한 작은 물품이나 스텁의 채택을 신청할 수 있는데, 그것은 무작위로 할당될 것이다.이것은 사용자 채택과 비슷할 겁니다. 여러 개의 기사를 채택할 수 있고, 충분히 확장되었을 때 "졸업"할 수 있을 겁니다.확장이 필요한 스텁과 기사가 많아 유용할 것 같고, 당신이 시작한 기사가 커지면 기분이 좋을 것 같다.의견?~크라운스타~16:34, 2007년 7월 2일 (UTC)[응답]

Special을 사용하여 스텁을 찾으십시오.무작위인가 뭔가.모든 사람들이 기사를 확장하는 것을 알고 있고 이런 태스크 포스는 필요하지 않다.우리가 이미 알고 있는 어떤 일에는 너무 많은 일이 있는 것 같다; 기사는 당신에게 할당될 필요가 없고, 하나만 골라라.레이와스92^Talk 16:49, 2007년 7월 2일 (UTC)[응답]

그냥 재미로 하는 프로젝트처럼 내 사용자 페이지의 하위 페이지로 설정할 수 있을까?~크라운스타~17:45, 2007년 7월 2일 (UTC)[응답]

이 "입양"은 미세한 선을 긋고 있고 위험할 정도로 "소유"에 가까운 것처럼 보인다.......폴 벤터 20:26, 2007년 7월 2일 (UTC)[응답]

나는 Paul의 말에 동의한다; 그것은 많은 편집자들이 마치 그들이 "소유"하고 기사를 쓰는 것처럼 느끼도록 격려할 것이다. 그리고 그것에 대한 사전적 책임이 있다.좋은 발걸음은 아닐 것이다. --Storm Rider 06:33, 2007년 7월 3일 (UTC)[응답]

'종류의' 엔진.

나는 음악가인데 현재 음반사를 찾고 있다.나날이 많아지고, 아티스트에게 가장 적합한 것을 찾기가 정말 힘들기 때문에, 내 생각에는 "장르별로 레코드 레이블을 정렬"하는 솔루션이 있다면 음악가 여러분, 우리에게 큰 도움이 될 것 같다.

음, 이건 MY 케이스야. 영화, 책 등 어떤 분야에서도 큰 도움이 될 거야.스포츠(스포츠), 정치, ....동일한 모든 catgory에서 동일한 정보를 필터링하는 것으로 검색하는 것.이와 같이, 또한 나의 경우: XY1은 레코드 레이블이며, 오직 트랜스 음악에만 관련된 것이지만, XY2는 하우스도 발매한다...그래서 두 가지 모두 같은 장르의 "트랜스"가 있는데, 이 경우에는 "genere"의 주요 단어인 "sort label by [genere].

또한, 예를 들어, 원주민을 찾기 위해 나라들을 검색하면 원주민이 있었던 나라들만을 볼 수 있다.

그래, 이해할 수 있을 것 같아.

그게 바로 범주의 특징이다.예를 들어, Def Jam Records는 Category:힙합 레코드 레이블.기본적으로, 우리는 레코드 레이블 기사를 적절히 분류하기 위해 더 많은 편집자들이 필요하다. -- Kesh 03:51, 2007년 7월 4일 (UTC)[응답]

또한, 이 제안서를 참고하십시오. -- ☑ 사무엘완트만 04:17, 2007년 7월 4일 (UTC)[응답]

위키백과

이것이 위키백과 밖에서 새로운 위키 스타일의 프로젝트를 제안하는 것이지만, 그 제안은 위키백과 밀접하게 연관되어 있기 때문에 나는 여기에 게시했다.이것이 포럼을 불쾌하게 했다면 사과한다.

위키피디아의 관리자들은, 아주 당연하게도, 너무 많은 중요하지 않은 기사나 사소한 주제에 대한 많은 양의 정보로부터 그것을 자유롭게 하고 싶어한다.그러나 어떤 사람들에게는 중요하지 않은 이런 기사들이 중요하고 많은 양의 정보가 유용할 수도 있다.나는 삭제된 기사가 전송되는 자매 사이트(제안서는 위키피디아네x)를 개설할 것을 제안한다.이 사이트의 링크는 위키백과 문서가 존재하는 경우 위키백과 문서를 가리키지만, 없는 경우 기본적으로 위키백과를 가리킨다.이렇게 하면, 모든 정보가 잡히고, 연결은 온전하게 되지만, 위키피디아는 이런 작은 기사들의 부담과 관련될 수 있는 어떤 평판적 위험도 부담하지 않는다.

대부분의 삭제된 글은 아니지만 많은 글들이 구겨져 있다.그리고 만약 위키피디아(웹호스팅에 관한 현재의 정책과 관련)가 어떤 기사도 보지 않고, 단지 여기서 삭제하기로 결정되었을 때 자동적으로 다른 프로젝트로 옮겼다는 것이 알려지면 어떻게 될까?

분석 기사(읽기: 원본 연구)를 허용하는 위키소스(Wikisource)라는 프로젝트도 있다.다른 프로젝트는 (논의할 수 없이) 가치가 있지만 위키백과 표준을 충족하지 못하는 대부분의 내용을 다루어야 한다.위키백과:검증가능성 또는 위키백과:예를 들어, 공신력.

그래서 나는 이 새로운 프로젝트가 (여기서) 속히 삭제될 수 있는 종류의 기사들을 (신규 프로젝트에서) 허튼소리, 공격 페이지, 또는 이와 비슷한 종류의 기사들을 유지하지 못할 경우, 누가 (그리고 새로운 프로젝트에서) 그 프로젝트에 있어야 할 것과 해서는 안 될 것을 위해 그 기사들을 훑어보고 (그리고 사건을 만드는 데) 시간을 보낼 것인가, 그리고 (2) 어떻게 그 프로젝트에 대한 질문들이라고 생각한다.h 콘텐츠는 새로운 프로젝트 내에서 기사가 될 만큼 충분히 중요하지만 위키백과나 위키소스에 포함될 정도로 중요하지는 않다. -- John Brown은 13:10, 2007년 7월 2일 (UTC)[응답]

Everything2도 방문하고 싶을 것이다. --Ybbor^Talk 14:03, 2007년 7월 2일 (UTC)[응답]

이 정보의 많은 부분은 심슨스 위키, 페니 아케이드 위키, 또는 그 밖의 다른 것과 같은 특정 분야에 전용된 위키에 속한다.나는 (농담으로) 트리비아피아의 아이디어를 제안했는데, 트리비아피아는 아주 한정된 집단에게만 중요한 사소한 내용만을 받아들이게 될 것이며, 이 단체는 사람들의 애완견과 그들이 학교에서 지어낸 것들에 대한 기사들을 이동하기에 좋은 장소가 될 수 있을 것이다.이 위키는 진지한 연구 도구로서 오히려 쓸모없겠지만, 재미있을 것이다.호환 가능한 라이센스(GFDL)를 설정하는 한, 서버에 이러한 Wiki를 만드는 것을 막을 수 있는 것은 없다.Dcoetzee 09:19, 2007년 7월 3일 (UTC)[응답]

반달리즘은 무의미하다.

나는 드라마틱한 백과사전에 대한 에세이를 보았는데, 위키피디아에 있어서 그들의 내용은 일반적으로 부적절하지만, 이것은 단지 좋은 목적에 맞을지도 모른다.[1] 위키백과에서 [1]을(를)살라칸/반달리즘은 무의미하다.혹시 {{uw-v1}, {{uw-v2}}번과 같은 반달리즘 경고에서 이 페이지를 링크하는 것이 좋을까?새로운 기자들이 반달리즘을 부추기지 않도록 환영 템플릿에서 이 페이지에 연결하지 않는 것이 좋겠지만, 우리는 단지 몇몇 잠재적 반달들이 이 페이지를 건설적으로 편집하도록 설득할 수도 있다.분명히, 이 페이지가 개선되고 어느 정도 받아들여지면, 위키백과: 네임스페이스로 옮기겠다.좋은 생각 있어?살라스칸 00:31, 2007년 7월 1일 (UTC)[응답]

우리 정책에 영향을 미치지 않는 에세이에 대한 수락이 필요하다고?펑피카 01:26, 2007년 7월 1일 (UTC)[응답]

사용자 보기:페르시아 시인 갈/반달리즘이 왜 어리석은가! BTW, "실리"는 "윌리"와 운을 맞춘다.샬롬^Hello 09:29, 2007년 7월 1일 (UTC)[응답]

펑피카, 그렇진 않지만, 우리가 이 에세이를 반달 경고 템플릿으로 연결하려면 승인이 필요해서, 개선하면 될 것 같아서 여기에 나열한 겁니다.살라스칸 10:52, 2007년 7월 1일 (UTC)[응답]

당신의 에세이는 사람들이 파괴하는 이유를 완전히 설명하지 못하고 반달들이 그 기사에 화가 나거나 위키피디아를 망치고 싶어하기 때문에 일반적으로 악의가 있다는 생각에 골몰하는 것 같다.나는 판의 미로를 플란의 미로로 바꾼 반달 한 명이 있었는데, 편집 요약본 "yummy flan :"과 함께 그들을 스스로 되돌렸다.판의 미로와 문제가 있었나?그들은 위키피디아가 고통받는 것을 보고 싶었을까?아니, 그리고 에세이의 어조는 내가 기대했던 것만큼 전문적이지 않아. 우리가 반달패들과 대량 연계시키고 있는 어떤 것에 대해서 말이야. 자연적으로 아웃사이더인.아트로포스 02:06, 2007년 7월 3일 (UTC)[응답하라]

그래서 여기에 나열한 것인데, 완성도와는 거리가 멀고, 내가 백과사전 드라마틱아(그리고 편집한 것)에서 베꼈다고 말했듯이, 내용이 (ED에서 예상한 대로) 그리 친절하지 않은 것이 분명하다.살라스칸 13:47, 2007년 7월 3일 (UTC)[응답]

또 다른 수상쩍은 제안...

다른 아이디어: 어쩌면 위키프로젝트들은 그들만의 네임스페이스를 가질 수 있을까?이것, 저것 그리고 나머지 06:09, 2007년 6월 29일 (UTC)[응답]

그리고 이것의 장점은 프로젝트 제목에서 "위키프로젝트"를 지울 수 있다는 것 외에, 네임스페이스가 될 수 있다는 것 외에?(이점이 사소한 것이라면, 물건을 옮기는 것은 정말 모든 일의 가치가 없기 때문에, 그렇다?) -- 존 브레본 (차라리) 20:09, 2007년 6월 29일 (UTC)[응답]

나는 그 이점이 충분하다고 생각한다.게다가, 그것은 "Wiki Project:"로 시작하는 "Wiki Project:"와 "Wiki Project"로 시작하는 "Wiki Project"로 시작하는 "Wiki Project"와 다른 "Wiki Project"로 시작하는 "Wiki Project"와 그 밖의 다른 것을 아는 "Wi그리고 그 작업은 반자동화 방식으로 다소 빨리 이루어질 수 있었다.위키프로젝트 기사로 시작하는 위키백과 네임스페이스 기사의 99%는 (놀랍다!)라고 추측할 수 있다.위키프로젝트.그리고 이름에 "Wiki Project"가 없는 페이지의 99%는 Wiki Projects가 아니라고 추측할 수도 있다.— The Storm Surfer 03:09, 2007년 7월 4일 (UTC)[응답]

템플릿:높이

{{hight}}}로 변경하기를 제안하고 싶다 - 유닛의 연결을 제거한다.링크들은 불필요하며, 기사들에서 템플릿의 전이를 추하게 만든다.나는 사람들이 템플릿의 토크 페이지에서 토론할 수 있도록 여기서 인지도를 높이고 있다 - 템플릿 토크:높이#링크. 롭윙필드 22:42, 2007년 7월 4일 (UTC)[응답]

IP에서 식별할 수 있음을 강조

로그인하지 않은 사용자에게 표시되는 기본 텍스트에 대한 변경을 제안해, 자신의 IP와 시간 및 날짜가 영원히 공개 로그에 기록된다는 사실을 강조해, 본인 확인에 활용할 수 있도록 했다(Seigenthaler 논란#).익명의 편집자, Chris Benoit# 확인위키백과 논란 등)

MediaWiki_talk:를 참조하십시오.제안된 변경사항에 대한 어노니트 경고#Empress_logging.

나는 단지 변경을 진행하기 전에 문구에 대한 의견을 듣고 싶었다.— 오메가트론 18:42, 2007년 7월 7일 (UTC)[응답]

토크 헤더

{{talkheader}}}}은(는) 위키백과의 모든 단일 토크 페이지에 추가되는 훌륭한 코드처럼 보인다.왜 그것이 표준인가?왜 모든 위키 기사에 자동으로 토크 헤더를 추가하는 봇이 있는가? (이미 만들어진 모든 토크 페이지에 적어도 하나를 추가)이런 일이 전에도 논의된 적이 있다면 미안한가? 이런 사소한 일이 생겨서는 안 될 것 같은데?내 말은, 토크 헤더는 문제 기사만을 위한 것인가?왜냐하면 나는 위키피디아에 관한 기본사항을 알아내는 신입생이 그것과 그것의 링크에 대한 정보가 매우 적절하다고 생각하기 때문이다.나중.petze 07:24, 2007년 7월 6일 (UTC)[응답]

제발 안돼, 다른 템플릿이 자동으로 대화 페이지에 올라오지 마.:) 이미 위키백과 주제의 템플릿으로 가득 차 있다.당신이 토론 페이지와 링크 와아 블루를 클릭하곤 했을 때, 당신은 거의 확실히 토론 페이지에 실제 토론이 있다는 것을 알았다.이제 링크가 파란색일 때 그것은 자주 중요하지 않다. 그것은 보통 템플릿으로만 가득 차 있다.네가 말한 템플릿은 꼭 필요한 경우에만 토크 페이지에 올려야 한다.조지 W 부시에서는 템플릿이 타당하지만 펜실베니아 주 세실 타운쉽(랜덤 기사)에서는 예를 들어 그럴 필요가 없다.가리온96(토크) 07:56, 2007년 7월 6일 (UTC)[응답]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ어쨌든, 내가 말했듯이, 그것은 이미 내용이 있는 모든 토크 페이지에 추가될 수 있는가?하지만 네 오른쪽 반응이 말이 되는 것 같아.빠른 답장 고마워.petze 08:06, 2007년 7월 6일 (UTC)[응답]

나는 이 템플릿의 주요 용도가 토론이 주제에서 벗어난 토크 페이지라고 생각한다.만약 내가 틀렸다면, 나에게 알려주고, "is"를 "있어야 한다"로 편집해줘.— The Storm Surfer 09:39, 2007년 7월 6일 (UTC)[응답]

페체, 위키피디아는 WP:임의의 채팅 포럼이 아님.올바른 영어를 사용하십시오.레이와스92^Talk 14:29, 2007년 7월 6일 (UTC)[응답]

그러한 템플릿을 사용하는 것은 전적으로 사용자의 재량에 달려있다 - 만약 편집자가 새로운 위키백과 사용자들과 지속적으로 접촉한다면, 그 편집자의 대화 페이지에 글을 올릴 때 그들에게 유용한 참고 자료를 제공하는 것이 그들에게 매우 유익하다.모든 편집자가 새로운 사용자들과 접촉하는 것은 아니다. 또는 그러한 템플릿이 오직 새로운 사용자들만을 위해 존재한다는 것(때로는 숙련된 편집자들에게도 상기시키는 것이기도 하다)이 아니라, 사용자들의 토크 페이지가 레이아웃을 위해 얼마나 그들의 선택에 달렸는지(어느 정도는) 알 수 있다.그들은 그것과 비슷하지만 그들만의 깃털이나 기교로 그들만의 템플릿을 만들고 싶어할 것이다.그 자동태그를 그들의 토크 페이지에 붙이는 것은 그들을 위한 노력을 저해할 것이다. --Ozgod 00:50, 2007년 7월 8일 (UTC)[응답]

• 우리는 아마도 미디어위키 토크 페이지 헤더에 그런 것을 추가할 수 있을 것이다. (특히 사람들이 그것을 끌 수 있도록 css 클래스와 함께 하는 것이 좋다.나는 토크헤더 템플릿이 그렇게 유용하다는 것을 결코 발견하지 못했다. 그것은 단지 당연한 것을 다시 말해준다.>래디안트< 12:56, 2007년 7월 9일 (UTC)[응답]

새로운 위키 프로젝트 제안 "정의적 논쟁"

나는 이 제안을 어디서 해야 할지 잘 모르겠다. 위키피디아의 새로운 장소에서 위키피디아에 속할 수도 있고, 프로그래밍이 필요할 수도 있다.

나는 FAQ와 여러해살이 제안서를 다 읽어봤고, 내게는 분명해 보이지만 이런 제안은 전혀 보이지 않는다.

나는 위키피디아의 기사들을 편향되지 않게 유지하려는 노력에 박수를 보내지만, 일부 사람들이 편향되었다고 생각할 수 있는 관점이 있어야 한다.주류 언론과 유스넷, 그리고 다양한 인터넷 토론 그룹에서는 타당하고 잘못된 주장이 끝없이 반복되고 있는 거대하고 지속적인 토론이 많다.나는 위키 재단이 토론의 수준을 높이고 그릇된 사실과 논쟁의 끝없는 반복을 줄이려는 궁극적인 희망으로 이러한 토론들을 요약하고 명확히 하기 위한 참조 사이트를 구축할 것을 제안한다.나는 또한 이것이 위키피디아에 대한 부적절하게 편향된 편집들을 그들을 위한 확실하고 적절한 포럼으로 줄이기를 바란다.그것은 다음과 같은 경우에 바쳐질 것이다.

기본 표준:

캘리포니아 주 이니셔티브 유권자 정보 시스템과 유사한 5부 토론 시스템으로서, 다음과 같이 구성된다.

프로 논증
사기 논쟁
프로 논거에 대한 반박
사기 논쟁에 대한 반박
해당하는 경우 화해 보기

이러한 각각의 주장은 다른 관점과 반박에 적절히 상호 참조되고 계층적으로 배열되는 주제와 하위 주제들로 세분될 것이다.

그러나 하위섹션의 길이는 제한되지 않는다.높은 수준의 구체성과 명료성이 유지되어야 한다.

논쟁에서의 중복성의 결여 또한 가장 중요한 원칙이어야 한다.

형식논리와 수사학의 원칙을 따르지 않는 것도 주장을 편집하거나 제거하기 위한 근거가 된다.저자에게 의전성사를 통보해야 하고, 의도가 악의적이지 않더라도 반복적인 범법자는 금지해야 한다.

사실의 뒷받침, 허위 정보의 제조 또는 사실과의 의견 교체를 위한 인용문을 제공하지 않는 것 또한 편집, 제거 또는 최종적인 비난(사전 경고 포함)이다.

선택적 원칙:

이 프로젝트는 위키피디아의 공공 기물 파괴를 줄이기 위한 많은 영구적인 제안들 중 어떤 부분집합을 포함한 더 높은 수준의 기물 파괴 보호가 필요할 수 있다.

사용자는 논쟁의 한쪽 또는 다른 쪽에 등록해야 할 수 있다.

토론 내용에 대한 덜 공식적인 토론을 위한 게시판이 포함될 수 있다.

왜 특정한 잘못된 주장이 제거되었는지 설명하는 FAQ.

화해 관점 외에도, 우리는 양쪽 모두에 동의하지 않는 네 번째 관점을 위한 공간을 포함할 수 있다.그러나 나는 이 포럼의 구체성을 훼손함으로써 그 효용성을 희석시키는 관점이 지나치게 확산되는 것을 경계한다.

--Michalchik 22:05, 2007년 7월 17일 (UTC)[응답]

위키프로젝트를 만들려면 위키백과에서 제안하십시오.위키프로젝트 협의회/제안.그러나, 내가 보기에 당신은 또한 위키피디아의 중립적인 관점 정책의 변화를 제안하려고 할지도 모른다 - 만약 그렇다면, 당신은 위키피디아 토크에서 그것을 제기하고 싶을지도 모른다.중립적인 관점. --Tim4christ17 00:33, 2007년 7월 18일 (UTC)[응답]

만약 디베이트페디아를 복제하고 싶다면, 내 대답은 "왜?"일 것이다.-- John Briton (삼겹살) 21:13, 2007년 7월 18일 (UTC)[응답]

나는 디베이트페디아에 대해 몰랐다.

위키백과:소개

관련 스레드를 템플릿 대화로 이동:도입, 장기적인 관점에서 단순/일관성을 유지한다.그래서 우리는 계속해서 도입부 자체가 시험적으로 출제되는 것을 보지 않고도 토론을 지켜볼 수 있다. --Quiddity 23:44, 2007년 7월 13일 (UTC)[답글]

전에 이런 얘기가 나왔으면 미안한데 난 못 봤어.몇몇 편집자들은 위키백과의 토크 페이지에 다음과 같이 논평했다.새로운 편집자들이 그 페이지를 편집할 수 있게 하는 것은 이상하고 잘못된 생각이라는 소개.새로운 편집자들은 종종 도입부 헤더를 제거한다(대개 실수로). 그래서 때때로 우리는 이렇게 생긴 소개 페이지를 얻기도 한다.이것은 나에게 매우 바람직하지 않은 것 같다. (그것은 위키피디아가 쉽게 파괴된다는 인상을 준다--나는 페이지가 한동안 그렇게 앉아있었다고 생각한다), 소개가 위키피디아를 처음 접하는 사람들이 가는 곳 중 하나일 수 있기 때문이다(일반적으로 위키피디아를 어떻게 끝내는지는 잘 모르겠지만).우리는 이미 샌드박스를 가지고 있고, 소개 페이지는 소개 페이지 자체보다는 새로운 편집자들이 그 곳에서 실험을 하도록 지시해야 한다.소개 페이지는 공공 기물 파손을 피하기 위해 반이나 완전하게 보호되어야 할 것이다. (우리가 그것을 그렇게 자주 편집할 필요가 있을 것이라고는 상상도 할 수 없다.)이 문제를 제기한 사용자는 나뿐만이 아니다. 위키피디아 토크:다른 코멘트에 대한 소개.나는 새로운 편집자들이 그 페이지를 편집하도록 격려받는 것을 보고 충격을 받았으나, 내가 뭔가를 놓치고 있는 것 같다.그렇지 않다면, 새로운 사람들을 샌드박스로 돌리고 위키피디아를 보호하자.소개.--빅타임피스 토크는 09:00, 2007년 7월 13일 (UTC)[응답]

나는 이 아이디어가 마음에 든다.사용자가 페이지 자체를 손상시키지 않고 여전히 해당 페이지에서 편집을 시도할 수 있도록 샌드박스를 편집 링크로 변환(한 번 보호됨)니힐트레스^(t.l) 15:29, 2007년 7월 13일 (UTC)[응답]

나는 샌드박스 편집과 도입부를 분리할 필요성에 대해 확실히 동의한다.s-protection에 대해 확신할 수 없음:나는 전혀 개의치 않지만 많은 편집자들은 그것이 부정적인 신호를 줄 수도 있다고 느낄 것이다.우리는 가끔 새로운 편집자들로부터 "이봐, 왜 페이지 X를 편집할 수 없는 거지?위키피디아는 거지같다."아드리안 M. H. 15:33, 2007년 7월 13일 (UTC)[응답]

"이 줄을 그대로 두십시오" 템플릿을 복구하기 위해 정기적으로 페이지를 체크하는 봇이 있다면 그리 큰 문제는 아니라고 생각한다.이미 있는 경우, 검사 빈도를 높이고 필요할 경우 템플릿 복원과 테스트-편집-삭제 기능을 분리하십시오.샌드박스 페이지를 따로 추가하면 소개 페이지에 샌드박스 공간을 두려는 취지가 퇴색되고 그 오도하는 성격이 새 편집자에게 나쁜 첫인상을 줄 수 있다.모건 윅 17:33, 2007년 7월 13일 (UTC)[응답]

샌드박스가 이미 있다는 것만 빼면.아트로포스 20:11, 2007년 7월 13일 (UTC)[응답]

맞아, 왜 우리가 새로운 사용자들을 위키피디아의 이미 존재하는 샌드박스에 단순히 지시할 수 없는 지 모르겠다.소개 페이지의 샌드박스--가장 쉬운 해결책인 것 같다.--빅타임피스 토크는 21:13, 2007년 7월 13일 (UTC)[응답하라]

도입부는 이전에 User:AntiVandalBot 4월까지, 사용자:마틴봇IV가 그 임무를 인계받았으나(이 실 참조), Martinp23도 지금 활동하지 않는 것으로 보인다.(템플릿/헤더 텍스트가 변경될 때마다, 그리고 30분마다 샌드박스를 재설정하는 것이 그 동작이었다.6월 26일에 멈췄다.)

사용자:MartinBot은 아직 활성화되어 있지만, 현재 누가 실행/관리하고 있는지 알 수 없는지요?지금 이런 것들을 파악하려고 노력하고 있다. --Quiddity 21:31, 2007년 7월 14일 (UTC)[응답]

업데이트: Martinp23의 등, 곧 고쳐질 예정 :) --Quiddity 01:51, 2007년 7월 15일 (UTC)[응답]

나는 그 제안에 동의하고, 나를 대신하여 제안해줘서 고마워 :) 크리스치^Talk 16:11, 2007년 7월 15일 (UTC)[응답]

"History" 탭을 "Past Revisions"로 변경

나는 역사 탭이 무엇을 하는지 새로운 것을 만드는 것이 명확하지 않다고 생각한다.폴란드 페이지를 검색하는 소수의 새로운 사용자들이 역사 탭이 폴란드 역사에 그들을 가져다 줄 것이라고 생각했다고 나는 확신한다.나는 이것이 위키백과 학습 곡선을 약간 완화시키는 데 도움이 되는 간단하고 논란의 여지가 없는 변화라고 생각한다(그리고 역사 탭으로 쉽게 접근할 수 있는 것은 새로운 사용자들에게 위키백과 편집에 대한 책임감이 있다는 것을 강조할 것이기 때문에 그들이 읽고 있는 기사들은 완전히 신뢰할 수 없는 것이 아닐 수 있다).

독일어 위키백과는 'Version/Authoren'(논문/저술자)을 사용하기도 하는데, 특히 이곳이 작가를 기록하는 곳이라는 점을 강조하기 때문에 더욱 좋다.보리스블루 09:41, 2007년 7월 5일 (UTC)[응답]

탭 이름으로 인해 혼동될 새로운 사용자가 있을 것 같은데...하지만 그들이 처음으로 그것을 클릭한 후에 그들은 그것이 무엇을 의미하는지 빠르게 알아낼 것이다.그것은 "하는 것으로 배우는 것"이라고 불린다.블루보어 15:12, 2007년 7월 5일 (UTC)[응답]

그들이 돌아온다면 그것은 사실일 것이다.아논이 변화를 추적할 방법이 없어 WP가 신뢰할 수 없다고 선언하는 블로그 글이나 기사를 쓰기 전에 '발견의 순간'이 일어나기를 바란다.어쨌든 이 변화를 시행하는 것이 거의 완전히 고통스럽지 않을 것이라는 점을 감안할 때, 나는 이것으로부터 얻을 수 있는 많은 이득이 있다고 생각한다.16:21, 2007년 7월 5일 (UTC)

고통 없이, 하하! 역사 버튼과 달리 실제로 혼란스러울 수 있는 버튼인 + 버튼의 토론을 찾아봐라.아니, 역사는 얻을 수 있는 한 짧고, 달콤하고, 유용하다고 생각해.GDallimore (Talk) 16:31, 2007년 7월 5일 (UTC)[응답하라]

반대: 그렇게 하면 계산이 너무 길어질 것이고, 난 그게 정말 혼란스럽다고 생각하지 않아.~ sublime514 • talk • sign 18:59, 2007년 7월 5일(UTC)

나는 여기서 그런 변화를 원하지 않지만, 나는 이것이 Simple English Wikipedia에서 제안되어야 한다고 생각한다.펑피카 22:01, 2007년 7월 5일 (UTC)[응답]

나는 이 문제를 우연히 발견했는데, '역사'는 분명히 우리에게 과거 버전을 모두 보여줄 것이라는 것을 의미할 수도 있지만, 지나가는 사람들에게는 대체로 혼란스럽다고 생각한다.이름 변경은 다소 극적인 변화가 되겠지만, 때로는 변화가 좋다. --W.marsh 17:50, 2007년 7월 6일 (UTC)[응답]

나는 "개정" (또는 "개정")이 명료성과 숙명성 사이에서 최상의 균형을 맞출 것이라고 믿는다.호기심 많은 이들은 결국 '역사' 탭을 클릭해 그것이 무엇인지 알아낼 것이지만, 모든 사람이 탐구하지는 않을 것이며, 특히 당장 탐구하지는 않을 것이다."페이지이력"이나 "문서이력"이나 "개정이력"도 탭의 기능을 더 선명하게 할 수 있지만, 그렇게 간단히 할 수는 없다. --Groggggy Days T C 01:37, 2007년 7월 7일 (UTC)[응답]

나는 위에서 제안된 어떤 변화도 강력히 지지한다.나는 항상 탭 제목에 대해 약간 유보적인 태도를 취했는데, 누군가가 제안을 앞당겨서 기쁘다. --best, kevin [kjollman][talk] 04:48, 2007년 7월 7일 (UTC)[응답]

중요한 고려사항은 작은 화면과 큰 글꼴을 가진 사용자들이 탭 바의 룸에서 이미 바닥이 난다는 것이다.따라서 새 텍스트는 현재 텍스트보다 현저히 길지 않아야 한다.— 칼 (CBM · talk) 13:58, 2007년 7월 7일 (UTC)[응답]

“

고장나지 않았다면 고치지 마라.

”

~위키허밋 02:51, 2007년 7월 14일 (UTC)[응답]

공유 파일처럼 "업로드 파일" 만들기

파일을 업로드할 때 en에 대해 제안하고 싶은 몇 가지 사항이 있다.이것들의 대부분은 독창적인 생각이 아니다.나는 그들이 처음 제안된 곳으로의 링크를 제공할 수 있지만 나는 그것이 그렇게 중요하다고 생각하지 않는다.나는 그들이 어떤 종류의 js로 끝낼 수 있다고 생각한다.

1. "도구 상자"에서 "업로드 파일" 링크를 제거하고 "파일 업로드 마법사"를 "도구 상자"로 이동하십시오.나는 이것이 zh:에서 이루어졌고 아마도 여기서 js로 이루어질 수 있다고 믿는다.
2. {{information}}을(를) 편집 상자에 사전 로드하여 커먼스(commons)와 마찬가지로 많은 정보를 작성하십시오.필요하다면 채워줄 연결고리를 갖자는 제안이 있었지만, 개인적으로는 나중의 생각이 마음에 들지 않는다.그것을 자동으로 편집 상자에 넣으면 사람들에게 필요한 정보가 무엇인지 더 잘 알 수 있을 것이다.나는 그것이 어떻게 공용어로 행해졌는지 알아냈어, 여기서는 간단한 js야.
3. 작은 것은 편집 상자가 50% 더 크거나 그 이상이라는 것이다.

이 같은 메시지는 아무도 눈치채지 못한 채 빌리지 펌프(Commons에 있는 "Upload file"을 더 많이 만들자)에서 또 다시 미디어위키에서 다음과 같이 말했다.커먼즈.js.일치단결에서 합의를 요구받아서 표결을 위해 다시 상정하고 있다.스타인닌 20:33, 2007년 7월 6일 (UTC)[응답]

'업로드 중인 파일이 무료 콘텐츠로 표시됨 - 대신 커먼스에서 업로드하는 것을 고려하십시오(커먼스/무시).리차드001 05:20, 2007년 7월 9일 (UTC)[응답]

전적으로 동의한다.나는 더 많은 사람들이 이 아이디어를 좋아하든 싫어하든 간에 그들이 더 많이 언급하는 것을 보고 싶다.사람들이 좋다고 말하지 않는 한, 어떤 관리자도 이런 변화를 하고 싶어하지 않는다. --Steinninn 02:08, 2007년 7월 12일 (UTC)[응답]

이미지를 공유 이미지로 마이그레이션

제안할 게 있다.나는 {{Wikimedia Commons}}}을(를) 모든 무료 이미지 라이선스 템플릿으로 옮겨야 한다고 생각한다."Wikipedia는 사진이나 미디어 파일의 모음이 아니기 때문에" - — 잭 · 토크 · 16:53, 화요일, 2007년 7월 10일

우리는 영어 백과사전이다. 그것들은 다국어 이미지 저장고다.이미지 설명, 분류 및 모니터링에 대한 우리의 요구가 반드시 그들의 요구와 같지는 않다.따라서 동일한 이미지(그러나 잠재적으로 다른 설명)가 커먼스에 나타나더라도 일부 이미지의 로컬 복사본을 유지하는 것이 항상 타당할 것이다.2007년 7월 10일(UTC) 17시 55분 드래곤즈 항공편[응답]

동의한다. 영어 위키피디아는 우리의 특정한 요구에 맞게 많은 이미지들을 제공한다.예를 들어, 나는 이전에 불타는 소녀(여기서 곰과 함께)의 정교하게 세밀한 그림을 지역적으로 저장해 놓았는데, 비록 그것이 그 전체에서 볼 수 있는 이미지의 일부에 불과하지만 말이다.이 소녀는 어린이용 주의 설화집 '더 슈트루웰페터' 출신이며, 전체 이미지는 화재 교육을 일러스트하는 데 전혀 필요 없는 19세기 독일어가 많은 스캔 페이지다. --Kizor 21:46, 2007년 7월 11일 (UTC)[응답]

삭제 시 AfD 기사 "여기 링크" 사본 보관

간단히 말할게.대부분 내가 직장에 있기 때문이다.내가 이 아이디어로 개발자들을 성가시게 하기 전에 제정신 점검이 필요하다. 삭제된 기사에 대한 링크는 종종 삭제된다.만약 그 기사가 DRV'd, 다시 쓰이거나 아니면 다른 방법으로 업무에 복귀한다면, 그 링크의 웹을 예전 수준으로 복원하는 것은 힘들 수 있고 종종 실행 불가능한 일이 될 수 있다. 왜냐하면, 기사와 연결된 *한 번*을 구별할 방법이 없기 때문이다.이로 인해 사용적합성이 일부 손상되어 WP가 다음과 같이 된다.BTW, DRV가 더 흔해짐에 따라 더욱 그렇다.인바운드 링크 목록을 저장하면 복원자가 현재 방법 대신 작은 소동 없이 웹을 구축할 수 있으며, 이는 "니들-인-헤이 스택"으로 빠져들 수 있다. --10:40, 2007년 7월 10일(UTC)

• 나는 이것이 작은 이익을 위해 데이터베이스 히트작이 될 것이라고 의심한다.정말 중요한 경우 브라우저의 "이 페이지 저장" 단추를 사용하여 로컬 복사본을 저장하십시오.>래디안< 10:44, 2007년 7월 10일 (UTC)[응답]
  • 나는 그것이 어떻게 그렇게 중요한 데이터베이스 히트인지 잘 모르겠다 - 그것은 아마도 다른 모든 것들과 함께 삭제 로그에 목록으로 저장될 수 있을 것이다.유용성 면에서 훌륭한 발상이든 아니든, 서술된 상황에 관여해 본 적이 없기 때문에 나는 정말로 말할 수 없다.SamBC 13:01, 2007년 7월 10일 (UTC)[응답]
    • 나는 반대편에서 아이디어를 지지할 것이다.기사가 삭제될 때(이 경우, 우리는 그것이 DRVed 또는 재창조될 가능성이 없다고 가정할 것이다), 편집자들이 쉽게 레드 링크를 정리할 수 있도록 "여기 링크할 때 사용한 것" 목록을 갖는 것이 도움이 될 것이다.블루보아르 14:45, 2007년 7월 10일 (UTC)[응답]

하지만 당신은 빨간 링크를 청소해야 하는가?삭제된 기사 주제가 실제로 다른 기사에 유용한 맥락을 제공했다면, 레드 링크는 기사를 삭제하기 위한 충분한 공신력이나 다른 이유가 극복된 미래 시점에 기사를 작성해야 한다는 것을 상기시켜주는 것으로 남아야 한다.만약 기사 주제가 기사의 맥락에 유용하지 않다면, 그 레드 링크는 한 사람이 할 필요 없이 일반 편집자들에 의해 어쨌든 제거되어야 한다.만약 누군가가 위키피디아 주변에 그들의 새로운 기사에 반달-에스케 링크를 뿌렸다면, 그들은 다른 반달리즘처럼 제거될 것이다.다시 한 번 말하지만, 한 사람이 모든 것에 대해 책임을 질 필요는 없다(보통 그럴 수 없다).

전기도 아마 좋은 예일 것이다.Person X에 대한 기사는 Person X를 언급하는 다른 기사에서 연결될 수 있다.X가 공신력을 얻지 못하거나 WP를 위반하여 해당 기사가 삭제된 경우:BLP는 레드 링크가 제거되어야 한다는 것을 의미하지 않는다.그 사람은 나중에 공신력을 얻을 수도 있고, 또는 더 많은 출처를 얻을 수 있게 되면 더 균형 잡힌 기사가 가능할 수도 있다.

아니, 여기 무슨 링크야? GDallimore (토크) 15:55, 2007년 7월 10일 (UTC)[응답하라]의 사본을 저장해야 할 이유를 모르겠다.

합리적이고 유용한 아이디어."여기에 링크된 사항" 목록은 왼쪽, 모든 페이지마다 정기적으로 제공되며, 해당 기능이 얼마나 자주 사용되는지 볼 때, 각 삭제에 대한 저장은 큰 부담이 되지 않을 수 있다."삭제 시점에 여기 링크했던 것"이 좋을 것이다.아직 내가 직접 필요한 것은 아니지만(아직 그런 상황에 부딪히지 않았다) 이것이 쉽게 재현되지 않고 이전 상태를 찾아볼 수 없는 단 하나인데, 기사가 삭제되면 아마 도움이 될 것이다.

관련 아이디어를 하나 더 추가하겠다.존재하지 않는 페이지에 대한 링크에 접근하려고 할 때, 소프트웨어는 그것이 예전에도 존재했는지를 확인하고, 만약 존재한다면 완전히 새로운 페이지로 취급하기 보다는 삭제 정보를 그 페이지에 표시해야 한다.

"당신이 (페이지)에 접속하려고 했잖습니까.이 페이지는 관리자가 (날짜) 코멘트와 함께 삭제했다.삭제된 페이지에 대해 자세히 알려면 (info)로 문의하십시오.삭제된 페이지를 다시 만들거나 액세스하는 방법은 (정책 페이지)를 참조하십시오.그렇지 않은 경우 오류로 이 페이지에 온 경우(상술 메시지 등)"

FT2 21:55, 2007년 7월 10일 (UTC)[응답]

그렇다.이러한 페이지로 이동하면 페이지에 대한 삭제 로그가 표시된다.해리보일스 07:42, 2007년 7월 11일 (UTC)[응답]

그렇다, 이것은 삭제되지 않을 페이지와 삭제되지 않을 페이지 모두에 대해 좋은 생각처럼 들린다.때로는 레드링크를 남기는 것이 좋고, 때로는 그렇지 않지만, 우리가 필요할 때는 이것이 있을 것이다. — The Storm Surfer 22:56, 2007년 7월 10일 (UTC)[응답하라]

별도의 로그인 이름 및 화면 이름

내가 방문한 포럼에서 이런 아이디어를 얻었다.100% 확신할 수는 없지만, 이것은 (더 많은 타협을 막기 위해) 계정을 더 안전하게 만드는 데 도움이 될 수 있다.누군가가 로그인하기 위해서는 최근 변경사항이나 페이지 기록(화면명)과 같은 장소에 나타나는 이름을 입력하는 것이 아니라 로그인 이름과 화면 이름을 다르게 입력해야 한다.만약 어떤 사람이 계정을 절충하고자 한다면, 그들은 대상의 로그인 이름이 무엇인지 전혀 알지 못할 것이기 때문에, 만약 그들이 누군가의 계정에 들어갈 수 있었다고 해도, 그들이 올바른 로그인 이름을 얻었다는 보장은 없다(사실 그들은 0의 편집이나 차단된 계좌로 끝날 가능성이 더 높아 보인다).Special을 통해 로그인 이름을 변경할 수 있음:BCrat 지원이 없는 기본 설정(단, 화면 이름(예: "FunPika")은 WP:CHU를 통해 변경해야 한다.펑피카 23:29, 2007년 7월 8일 (UTC)[응답]

그러나 새로운 편집자들에게 혼란스러운 것은 백과사전보다 게임에 더 적합한 것 같다.프로데고 05:22, 2007년 7월 9일 (UTC)[응답]

• 그것은 실제로 도움이 되지 않을 것이다; 그것이 암호의 목적이다.>Radiant< 12:55, 2007년 7월 9일 (UTC)[응답]
• 사실상, 이것은 하나의 암호보다는 두 개의 암호를 갖는 것처럼 들린다.Gracenotes § 04:21^T, 2007년 7월 12일 (UTC)[응답]

• 신참을 헷갈리게 하기 위해. --Tλε RαnΔom Διor (ταlκ) 22:52, 2007년 7월 12일 (UTC)[응답]

• 그래, 그라세노테스가 옳다(비밀번호가 두 개 있는 것과 같다)."갈등" 우려에 대해서는, 그렇게 할 필요가 없다!우리는 기본적으로 화면 이름을 로그인 이름과 동일하게 설정할 수 있다.추가 보안을 원하는 사용자는 프리fs에서 로그인 이름을 변경하는 지침을 따를 수 있다.이렇게 하면 해킹된 계정(즉, 사용자가 기본 동일한 로그인 이름을 변경할 수 있는 경험을 이미 획득한 경우)이 더 위험해진 오래된 계정의 보안을 강화하는데 도움이 될 것이다.나쁘지 않은 아이디어지만, 보안이 코드 수정이나 내가 아직 발견하지 못한 특정한 문제를 해결할 가치가 있는지 확신할 수 없다.생각?니코실버 23:23, 2007년 7월 12일 (UTC)[응답]

  '비밀' 로그인 이름은 (공용 사용자명과 개인 비밀번호를 갖는다는 생각에 익숙하기 때문에) 사람들이 이를 공개할 가능성이 높기 때문에 사실상 별도의 비밀번호보다 보안성이 떨어질 수 있다.e HTML 양식 필드는 암호 필드가 아닐 것이며(사람들이 어깨너머로 볼 수 있도록 허용) 두 개의 중복 로그인 이름을 가질 수 없기 때문에 로그인 이름을 설정할 때, 사람들은 자신의 이름 선택이 이미 이루어졌음을 발견할 수 있으며, 따라서 계정에 액세스하는 데 필요한 비밀 정보의 절반을 발견할 수 있다.나는 제안된 것만큼 계정을 안전하게 만들려면 사람들은 비밀번호 길이를 두 배로 늘려야 한다고 생각한다.Tra (Talk) 23:54, 2007년 7월 12일 (UTC)[응답]

웹 참조

이것은 제안이 아니다. 제안서를 찾는 것에 더 가깝다.50년 안에 위키피디아가 "완전"하게 될 때, 웹페이지에 연결되는 모든 (극히 많은) 참고문헌의 95%가 죽어서 검증할 수 없게 될 것이라는 문제를 다룬 사람이 있는가?우리 지금 이 일을 어떻게 해야 할까?맷 01:33, 2007년 7월 3일 (UTC)

줄 필요가 없어.우리는 언제나 archive.org --Steinnin 01:56, 2007년 7월 3일 (UTC)에 갈 수 있다.

archive.org이 죽었을 때?아! ~ sublime514 • talk • sign 02:24, 2007년 7월 3일 (UTC)

어쩌면 위키피디아는 우리가 인용하는 웹 페이지의 복사본을 보관하기 시작해야 할까?나는 아마존닷컴이 어떻게 명백한 저작권 문제를 해결하는지 모르겠다.— The Storm Surfer 03:17, 2007년 7월 4일 (UTC)[응답]

확실히 우리가 하는 일이 있다.각 소스에 대한 전체 설명을 제공하십시오.제목, 저자, 출판사 등WP 참조:CITE. (SEWilco 02:58, 2007년 7월 3일 (UTC)][응답하라]

만약 웹 페이지가 원본 텍스트가 기록된 유일한 장소였다면, 그리고 웹 페이지는 이제 사라졌다면, 그것은 도움이 되지 않을 것이다!Matt 20:48, 2007년 7월 5일 (UTC)

Archive.org은 수십억 페이지를 포함하고 있지만 완벽하지는 않다. 인터넷 아카이브에서 더 많은 정보를 읽을 수 있다. Archive.org은 위키백과:웨이백 머신 사용.페이지 복사본 - 사용자 지정 복사본 -의 대체 장소는 WebCite이다. - John Brown (식별) 14:38, 2007년 7월 4일 (UTC)[응답]

나는 가끔 AP와 로이터 기사의 기사를 contracostatimes.org, boston.com, abcnews.com, 또는 내가 만료되지 않은 다른 사이트로 업데이트한다.누구라도 이것들과 연락해서 다음 100년 동안 혹은 적어도 나노 로봇이 작동하고 손목시계 업링크를 통해 사람들의 개인 위성 업링크에 보관소를 전달할 준비가 될 때까지 그들의 사이트를 계속 유지할 계획을 알아낼 수 있는가?정말로, 어떤 사이트들이 의도적으로 장기간 링크를 활성화하기를 바라고 있는지 알 수 있는 사람이 있는가?

archive.org과 관련하여, 만약 내가 언급했듯이 AP나 로이터와 같은 적어도 중요한 출처의 자료실에 링크를 가지고 있다면, 우리는 아마도 편집자들이 이것을 더 자주 사용하도록 해야 할 것이다. --Sm8900 16:23, 2007년 7월 12일 (UTC)[응답]

토크 페이지 전폐의 사용?

나는 대부분의 사람들과 같은 단편적인 대화 페이지 문제를 우연히 발견했다.이것은 보통 다음과 같은 것으로 해결된다.

이어 "내 토크페이지에서 토론을 시작한다면 내 토크페이지에 회신하겠지만, 짧은 성명(ex)을 통해 당신의 토크페이지에 회신하겠다.

임의 페이지

나는 이것이 존재하는지 확실하지 않지만, 그것이 존재하는지 나는 그것을 찾지 못했다.나는 "랜덤 기사" 링크의 팬이고, 내가 다른 어떤 것에 대해 읽어야 할지에 대한 영감이 없을 때 그것을 사용한다.그러나 나는 계속 떠오르는 주제(예: 스포츠)는 나에게 전혀 흥미가 없다는 것을 발견한다.나는 각 포털에 있는 임의의 기사가, 말하자면 임의의 과학 기사를 내게 지시할 것이기 때문에 좋을 것이라고 제안한다.위키백과 카드의 답변.—앞서 서명되지 않은 의견은 195.92.40.49 (대화) 17:26, 2007년 7월 12일에 추가되었다.

포털에서 사용할 수 있는 방법이 있다 – 포털:예를 들어, 모터스포츠 - 독자가 페이지를 새로 고치고 새로운 피처링 콘텐츠를 볼 수 있도록 한다.Adrian M. H. 16:43, 2007년 7월 12일 (UTC)

포털:중간지구는 페이지 측면에 임의의 기사 링크를 가지고 있다.세비 23:06, 2007년 7월 13일 (UTC)

도구 상자의 로그 링크

나는 항상 '이 페이지에 대한 로그' 링크가 없어서 답답하다.사용자 기여 링크 아래 사용자(대화) 공간에 있는 로그 버튼 또는 모든 공간에 있는 '여기에 있는 링크' 링크 아래에 있는 로그 버튼은 차단된 반달들을 신속하게 식별하거나 페이지가 이전에 삭제되었는지 여부를 확인하는 데 매우 유용할 수 있다.ck lostsword•T•C 23:37, 2007년 7월 10일 (UTC)

그것은 유용할 것이다.한편 파이어폭스의 해결책은 http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=%s에 대한 빠른 검색 "log"를 추가하는 것이다.λυΔαcγγ 20:08, 2007년 7월 11일 (UTC)

그것이 사용자 스크립트의 목적이다.체크아웃 위키백과:WikiProject 사용자 스크립트/스크립트/로그 링크— 신한 <토크 > 09:18, 2007년 7월 13일 (UTC)

링크 :)에 감사한다.그러나, 나는 이것이 저금리 링크가 아니라고 생각한다. - 아마도 사용자 스크립트 설치를 원하는 사람들만이 아니라 모든 사용자들에게 유용한 시스템이 될 수 있을 것이다.ck lostsword•T•C 17:59, 2007년 7월 13일 (UTC)

범주:미국의 지역 번호

이 페이지에 트래픽이 가장 많이 걸려서 여기에 올린다.위의 범주는 어처구니없다.여기에 있는 일부 기사를 보고 범주:주별 미국의 지역 번호 및 북미 지역 번호 목록.그러한 기사들 중 유용하거나 독특한 정보를 가지고 있는 것은 거의 없다.나는 그들을 오하이오 주의 지역 코드와 같은 주 기사로 통합할 것을 제안한다.오, 더 자세히 보니 텍사스 지역 번호 목록과 다른 두 개가 있어.이것들은 사실 매우 짧은 목록이고 나는 지역 번호 기사에 있는 정보가 여분의 여분으로 쉽게 병합될 수 있다고 확신한다.모든 북미 지역 코드는 확실히 그들만의 기사가 필요하지 않다; 리스트는 반드시 만들어져야 한다.

비록 매우 작지만, 기사를 재배할 것 같지 않은, 다소 눈에 띄는 대량의 확산이 큰 문제가 되고 있다.겉보기에는 모든 기차역과 지하철역에 대한 기사도 있다.최근에 합의된 스레드를 보려면 여기를 참조하십시오. 이 스레드는 스롤 방지 가이드라인 초안 작성 중 입니다.더 많은 정보를 찾고 있어레이와스92^Talk 22:08, 2007년 7월 7일 (UTC)

당신이 그 기사들을 불필요하게 생각할 수도 있지만, 나는 최근에 직장에서 그것들을 매우 규칙적으로 사용하고 있다.한 사람에게 쓸데없는 잡담은 많은 경우에 다른 사람에게 귀중한 정보를 제공하는 것이다. - SimonP 13:43, 2007년 7월 12일 (UTC)

그것들은 아마 삭제될 것이다.— The Storm Surfer 00:47, 2007년 7월 13일 (UTC)

자세히 설명해 주시겠습니까? --골베즈 02:21, 2007년 7월 13일 (UTC)

위키피디아의 우편번호 목록은 다음과 같다.주별 미국 ZIP 코드 삭제/목록 관련 조항— The Storm Surfer 03:17, 2007년 7월 13일 (UTC)

페이지가 불필요하다고 생각되면/삭제해야 한다고 생각되면 AfD로 가져가라고 권하고 싶다. --Tim4christ17 14:09, 2007년 7월 13일(UTC)

"큰 문제를 야기한다"고?말해봐. 어떻게?위키피디아는 종이도 아니고, 크기 제약도 없기 때문에 우리는 걱정할 필요가 없다.게다가, 어떤 경우에는 지역 번호의 이력이나 다가오는 오버레이 등에 관한 흥미로운 정보들이 있다 --Ybbor^Talk 14:37, 2007년 7월 13일 (UTC)

"History" 탭을 "Past Revisions"로 변경

나는 역사 탭이 무엇을 하는지 새로운 것을 만드는 것이 명확하지 않다고 생각한다.폴란드 페이지를 검색하는 소수의 새로운 사용자들이 역사 탭이 폴란드 역사에 그들을 가져다 줄 것이라고 생각했다고 나는 확신한다.나는 이것이 위키백과 학습 곡선을 약간 완화시키는 데 도움이 되는 간단하고 논란의 여지가 없는 변화라고 생각한다(그리고 역사 탭으로 쉽게 접근할 수 있는 것은 새로운 사용자들에게 위키백과 편집에 대한 책임감이 있다는 것을 강조할 것이기 때문에 그들이 읽고 있는 기사들은 완전히 신뢰할 수 없는 것이 아닐 수 있다).

독일어 위키백과는 'Version/Authoren'(논문/저술자)을 사용하기도 하는데, 특히 이곳이 작가를 기록하는 곳이라는 점을 강조하기 때문에 더욱 좋다.보리스블루 09:41, 2007년 7월 5일 (UTC)

탭 이름으로 인해 혼동될 새로운 사용자가 있을 것 같은데...하지만 그들이 처음으로 그것을 클릭한 후에 그들은 그것이 무엇을 의미하는지 빠르게 알아낼 것이다.그것은 "하는 것으로 배우는 것"이라고 불린다.블루보어 15:12, 2007년 7월 5일 (UTC)

그들이 돌아온다면 그것은 사실일 것이다.아논이 변화를 추적할 방법이 없어 WP가 신뢰할 수 없다고 선언하는 블로그 글이나 기사를 쓰기 전에 '발견의 순간'이 일어나기를 바란다.어쨌든 이 변화를 시행하는 것이 거의 완전히 고통스럽지 않을 것이라는 점을 감안할 때, 나는 이것으로부터 얻을 수 있는 많은 이득이 있다고 생각한다.16:21, 2007년 7월 5일 (UTC)

고통 없이, 하하! 역사 버튼과 달리 실제로 혼란스러울 수 있는 버튼인 + 버튼의 토론을 찾아봐라.아니, 역사는 얻을 수 있는 한 짧고, 달콤하고, 유용하다고 생각해.GDallimore (Talk) 16:31, 2007년 7월 5일 (UTC)

반대: 그렇게 하면 계산이 너무 길어질 것이고, 난 그게 정말 혼란스럽다고 생각하지 않아.~ sublime514 • talk • sign 18:59, 2007년 7월 5일(UTC)

나는 여기서 그런 변화를 원하지 않지만, 나는 이것이 Simple English Wikipedia에서 제안되어야 한다고 생각한다.펑피카 22:01, 2007년 7월 5일 (UTC)

나는 이 문제를 우연히 발견했는데, '역사'는 분명히 우리에게 과거 버전을 모두 보여줄 것이라는 것을 의미할 수도 있지만, 지나가는 사람들에게는 대체로 혼란스럽다고 생각한다.이름 변경은 다소 극적인 변화가 되겠지만 때로는 변화가 좋다. --W.marsh 17:50, 2007년 7월 6일 (UTC)

나는 "개정" (또는 "개정")이 명료성과 숙명성 사이에서 최상의 균형을 맞출 것이라고 믿는다.호기심 많은 이들은 결국 '역사' 탭을 클릭해 그것이 무엇인지 알아낼 것이지만, 모든 사람이 탐구하지는 않을 것이며, 특히 당장 탐구하지는 않을 것이다."페이지이력" 또는 "문서이력" 또는 "개정이력"도 탭의 기능을 더 선명하게 만들 수 있지만 간략하게는 할 수 없다. --Grogggy Dais T C 01:37, 2007년 7월 7일 (UTC)

나는 위에서 제안된 어떤 변화도 강력히 지지한다.나는 항상 탭의 제목에 대해 약간의 예약을 해왔는데, 누군가가 그 제안을 앞당겨서 기쁘다. --best, kevin [kjollman][talk] 04:48, 2007년 7월 7일 (UTC)

중요한 고려사항은 작은 화면과 큰 글꼴을 가진 사용자들이 탭 바의 룸에서 이미 바닥이 난다는 것이다.따라서 새 텍스트는 현재 텍스트보다 현저히 길지 않아야 한다.— 칼 (CBM · talk) 13:58, 2007년 7월 7일 (UTC)

“

고장나지 않았다면 고치지 마라.

”

~ 위키허밋 02:51, 2007년 7월 14일 (UTC)

스튜디오 레슬링 페이지

내 제안을 여기에 넣으라는 통보를 받았으니, 여기...

나는 위키피디아가 스튜디오 레슬링과 관련된 페이지들이 너무 많다고 느꼈고, 스타워즈에는 자신만의 "후키페디아"가 있다고 들었으니 스튜디오 레슬링의 모든 것들은 아마도 그것 자체의 "WWEpedia"나 그런 성격의 것으로 옮겨져야 할 것이다.헐크 호건이나 제시 "몸" 벤투라와 같은 유효한 문화적 아이콘은 허용되어야 하지만, 스튜디오 레슬링의 모든 사소한 "감정"과 Pay-Per-View 이벤트의 세부 목록은 너무 지나치고, 유효한 역사적 목적이 없다.

http://prowrestling.wikia.com을 사용해 보십시오.모건 위크 02:41, 2007년 7월 16일 (UTC)

위키백과:소개

관련 스레드를 템플릿 대화로 이동:도입, 장기적인 관점에서 단순/일관성을 유지한다.그래서 우리는 계속해서 도입부 자체가 시험적으로 출제되는 것을 보지 않고도 토론을 지켜볼 수 있다. --Quiddity 23:44, 2007년 7월 13일 (UTC)

전에 이런 얘기가 나왔으면 미안한데 난 못 봤어.몇몇 편집자들은 위키백과의 토크 페이지에 다음과 같이 논평했다.새로운 편집자들이 그 페이지를 편집할 수 있게 하는 것은 이상하고 잘못된 생각이라는 소개.새로운 편집자들은 종종 도입부 헤더를 제거한다(대개 실수로). 그래서 때때로 우리는 이렇게 생긴 소개 페이지를 얻기도 한다.이것은 나에게 매우 바람직하지 않은 것 같다. (그것은 위키피디아가 쉽게 파괴된다는 인상을 준다--나는 페이지가 한동안 그렇게 앉아있었다고 생각한다), 소개가 위키피디아를 처음 접하는 사람들이 가는 곳 중 하나일 수 있기 때문이다(일반적으로 위키피디아를 어떻게 끝내는지는 잘 모르겠지만).우리는 이미 샌드박스를 가지고 있고, 소개 페이지는 소개 페이지 자체보다는 새로운 편집자들이 그 곳에서 실험을 하도록 지시해야 한다.소개 페이지는 공공 기물 파손을 피하기 위해 반이나 완전하게 보호되어야 할 것이다. (우리가 그것을 그렇게 자주 편집할 필요가 있을 것이라고는 상상도 할 수 없다.)이 문제를 제기한 사용자는 나뿐만이 아니다. 위키피디아 토크:다른 코멘트에 대한 소개.나는 새로운 편집자들이 그 페이지를 편집하도록 격려받는 것을 보고 충격을 받았으나, 내가 뭔가를 놓치고 있는 것 같다.그렇지 않다면, 새로운 사람들을 샌드박스로 돌리고 위키피디아를 보호하자.소개.--빅타임피스 토크는 09:00, 2007년 7월 13일 (UTC)

나는 이 아이디어가 마음에 든다.사용자가 페이지 자체를 손상시키지 않고 여전히 해당 페이지에서 편집을 시도할 수 있도록 샌드박스를 편집 링크로 변환(한 번 보호됨)니힐트레스^(t.l) 15:29, 2007년 7월 13일 (UTC)

나는 샌드박스 편집과 도입부를 분리할 필요성에 대해 확실히 동의한다.s-protection에 대해 확신할 수 없음:나는 전혀 개의치 않지만 많은 편집자들은 그것이 부정적인 신호를 줄 수도 있다고 느낄 것이다.우리는 가끔 새로운 편집자들로부터 "이봐, 왜 페이지 X를 편집할 수 없는 거지?위키피디아는 거지같다."Adrian M. H. 15:33, 2007년 7월 13일 (UTC)

"이 줄을 그대로 두십시오" 템플릿을 복구하기 위해 정기적으로 페이지를 체크하는 봇이 있다면 그리 큰 문제는 아니라고 생각한다.이미 있는 경우, 검사 빈도를 높이고 필요할 경우 템플릿 복원과 테스트-편집-삭제 기능을 분리하십시오.샌드박스 페이지를 따로 추가하면 소개 페이지에 샌드박스 공간을 두려는 취지가 퇴색되고 그 오도하는 성격이 새 편집자에게 나쁜 첫인상을 줄 수 있다.모건 위크 17:33, 2007년 7월 13일 (UTC)

샌드박스가 이미 있다는 것만 빼면.아트로포스 20:11, 2007년 7월 13일 (UTC)

맞아, 왜 우리가 새로운 사용자들을 위키피디아의 이미 존재하는 샌드박스에 단순히 지시할 수 없는 지 모르겠다.소개 페이지의 샌드박스--가장 쉬운 해결책인 것 같다.--빅타임피스 토크는 2007년 7월 13일(UTC) 21:13에 기여한다.

도입부는 이전에 User:AntiVandalBot 4월까지, 사용자:마틴봇IV가 그 임무를 인계받았으나(이 실 참조), Martinp23도 지금 활동하지 않는 것으로 보인다.(템플릿/헤더 텍스트가 변경될 때마다, 그리고 30분마다 샌드박스를 재설정하는 것이 그 동작이었다.6월 26일에 멈췄다.)

사용자:MartinBot은 아직 활성화되어 있지만, 현재 누가 실행/관리하고 있는지 알 수 없는지요?지금 이런 것들을 파악하려고 노력하고 있다. --Quiddity 21:31, 2007년 7월 14일 (UTC)

업데이트: Martinp23의 등, 곧 고쳐질 예정 :) --Quiddity 01:51, 2007년 7월 15일 (UTC)

나는 그 제안에 동의하고, 나를 대신하여 제안해줘서 고마워 :) 크리스치^Talk 16:11, 2007년 7월 15일 (UTC)

일반적으로 기사 내용을 개선하기 위한 간단한 아이디어

나는 추가 정보를 독자에게 제공할 때 내부 링크와 함께 위키백과 페이지 구조에 수축할 수 있는 텍스트 기능을 할 것을 제안한다.

위키피디아의 대부분의 기사는 독자가 잠재적으로 목적적합한 정보에 접근하는 것을 용이하게 하기 위해 다른 기사에 대한 내부 연결에 의존한다.나의 제안은 편집자들이 기사의 주요 초점에서 독자의 주의를 흐트러뜨리지 않고 기사에 제시된 정보를 확장하는 또 다른 방법을 제공할 것이다."더 많은 것을 보려면 여기를 클릭" 또는 "글을 확장하려면 클릭"과 같은 링크가 활성화된 경우에만 읽을 수 있거나 다시 숨길 수 있는 텍스트의 숨겨진 영역을 만드는 것이 아이디어일 것이다.이러한 "사이드"는 대체되지 않고 오히려 독자의 이익을 위해 이미 사용되고 있는 내부 링크를 수반할 것이다.

접을 수 있는 콘텐츠의 사용으로 해결될 내부 링크에만 의존하는 것에는 몇 가지 문제가 있다.가장 쉽게 알아차릴 수 있는 문제는 끊어진 링크의 수입니다.일부 페이지의 편집자들은 호기심 많은 독자들에게 더 많은 정보를 제공하려고 시도하고 있는 것으로 보이지만, 그가 링크하려고 하는 기사는 어떤 이유에서든 존재하지 않는다.좀 더 미묘하게, 링크된 기사가 존재할 때, 그 안에 있는 정보는 실제로 독자가 지시했던 이전 기사의 맥락에 맞는 어떤 정보도 포함하지 않을 수 있다.이런 현상은 구체적인 날짜를 언급할 때 종종 발생한다.이 경우 독자들은 그 날짜에 무슨 일이 일어났는지 정확히 알고 싶어할 수도 있지만, 대신에 그 날짜에 일어났다고 기록된 모든 것을 나열하는 일반 기사로 옮겨진다.한편, 기사가 만들어지고 관련 정보와 연계된다고 가정할 경우, 다른 기사의 맥락에서 만들어진 것을 깨닫지 못한 채 다른 사람에 의해 편집되어 의도된 의미를 상실할 수도 있다.다른 경우에는 기사에 특정 사건이나 상황이 언급될 수 있지만, 이와 관련된 특정 기사가 작성되지 않았거나 편집자가 링크 제공에 시간을 들이지 않았기 때문이든, 이 사건에 대한 추가 조사를 위한 링크는 제공되지 않는다.이러한 모든 문제는 위에서 설명한 기능을 추가함으로써 해결될 수 있다. 여기서 편집자는 소량의 메타데이터만큼 간단한 추가 정보를 한 단락 또는 두 개의 표시된 이벤트 요약에 제공할 수 있다.이러한 텍스트를 확장될 때까지 숨겨두면 기사의 단순함과 집중력을 유지하는데 도움이 될 뿐만 아니라, 기사에 대해 이미 잘 알고 있는 일부 독자들이 읽는데 시간을 낭비하지 않으려는 정보로 인해 기사가 어수선해지는 것을 막을 수 있다.

철회할 수 있는 텍스트의 주요 이점은 별도의 기사를 작성할 필요가 없다는 사실이며, 이것은 아마도 장기간 "거품"으로 남아 있을 것이다.게다가, 그것은 독자가 관련 정보를 위해 다른 기사를 통해 검색할 필요가 없도록 기사의 편집자가 원본 기사의 맥락에 맞는 정보를 포함시킬 수 있게 한다.만약 날짜와 같은 참고문헌에 의해 더욱 확대되는 별도의 기사가 존재한다면, 그 글에서도 (빈칸)의 맥락에서 (빈칸) 또는 (빈칸)과 관련된 (빈칸)과 같은 제목 아래 해당 글에서도 텍스트를 사용할 수 있게 될 수 있다.그리고 나서, 다른 편집자가 기사의 내용을 변경할 때, 그는 그가 다른 기사의 맥락에 영향을 미치고 있다는 것을 알 수 있고, 그 기사들을 적절하게 다룰 수 있다.

나는 웹사이트 디자인이나 프로그래밍에 대한 경험이 없어서 내 아이디어가 쉽게 추가될지 모르겠어.나 또한 그러한 아이디어가 이전에 제시된 적이 있는지 모르지만, 나는 그것을 실행할 수 있는 경험이 있는 위키백과 편집자들에게 내 아이디어를 제시하고 있다.나는 이 아이디어가 읽고 고려되었다는 것을 알기 위해 어떤 반응이라도 매우 고맙게 생각하겠지만, 특히 이 아이디어가 위키피디아의 특징에 통합될 가능성이 있는지 알고 싶다.

제이콥 T.마틴 199.221.7.30 19:51, 2007년 7월 16일 (UTC)

어떤 텍스트와 관련된 정보를 문서화하는 아이디어는, 훨씬 더 상세하게, 제안된 m에서 논의된다.위키사이트 페이지.나쁜 외부 링크에 대해서는, 편집자들이 인용문보다는 외부 링크를 삽입하고 있다는 것이 문제인데, 인용문들이 있으면, 나쁜 외부 링크를 더 쉽게 복구할 수 있다(또는 필요하다면 무시한다).당신은 또한 다른 편집자들과의 의사소통이 절대적으로 필요한 편집자들에게 보이지 않는 논평들이 이용 가능하다는 것을 언급하는 것을 하지 않는다.마지막으로, 위키백과:요약 스타일은 독자들에게 더 많은 정보를 제공하는 문제를 다룬다.편집자가 16단계를 2단락으로 압축하기 보다는 6단계를 2단락으로 압축(말)하고자 하는 중간 케이스가 스핀오프 기사에 도움이 되지 않는 것은 사실이지만, 현실은 섹션 제목만 있으면 독자들이 자유롭게 두어 단락을 읽고 계속 읽기를 원하는지 아니면 다른 섹션으로 갈지 결정하는 것이다.

요컨대, 위키피디아는 당신이 지적하는 문제들에 대한 대부분의 해결책을 이미 가지고 있고, 편집 마크업과 과정을 지금보다 훨씬 더 복잡하게 만드는 것은 일반적으로 좋은 생각이 아니다: 그렇게 많은 편집자들이 예를 들어 소스를 제공할 때 각주/참고 형식을 사용하지 않는 것을 고려하면, 왜 우리가 그렇게 기대하지 않는가?좀 더 복잡한 것을 배우고 사용하기 위한 옷자락? - 존 브레튼 (차단) 20:28, 2007년 7월 16일 (UTC)

참조 데스크 및 헬프 데스크 검색

우선, 문제가 있다는 걸 분명히 하고 싶어사실 좀 조용히 해이따금씩, 나는 내 문제에 대해 도움을 요청하고 싶은 설명할 수 없는 충동을 느낀다.그래서 나는 내 컴퓨터로 걸어가서, 위키피디아에 로그인하고, 참조 데스크에 문의한다. 내가 그들의 도움을 사랑하는 만큼, 나는 그들이 내 질문에 이미 몇 억과 한 번 전에 대답했는지 궁금하지 않을 수 없다. 그래서 나는 오래된 답안의 기록들을 뒤지고 있는 나 자신을 발견한다.만약 누군가가 그 페이지를 통해서만 검색할 수 있는 대본을 쓸 수 있다면, 그 도움은 매우 감사할 것이다.참조 데스크 템플릿에 추가할 수 있다면 더욱 그러할 것이다.샤덴 14:48, 2007년 7월 15일 (UTC)

여기, 구글을 사용하여 사이트:http://en.wikipedia.org/wiki/Wikipedia:Reference_desk/Archives을 입력하십시오.스크립트 필요 없음. 68.231.151.161 00:34, 2007년 7월 16일(UTC)

보관소는 2세트(2006년 10월 이전과 이후)가 있어 서로 다른 검색이 필요하다.위키피디아에서 지시사항을 업데이트했다.참조 데스크/아카이브구글을 사용하여 검색하려면 2개의 링크를 사용하십시오.

헬프 데스크의 디토.다음 범주의 지침을 참조하십시오.헬프 데스크 아카이브(2006년 10월 이전) 및 위키백과:헬프 데스크/아카이브(2006년 10월 이후)에서 검색. --Quiddity 17:05, 2007년 7월 16일(UTC)

더블 프로포즈

두 가지를 제안한다.사용자의 기여도를 모니터할 수 있는 두 번째 '기여' 감시 목록.이것은 파괴적인 기여를 훨씬 더 쉽게 감시할 수 있게 해줄 것이다.나 또한 파이프에 대한 제안을 한다. 편집 도구 모음에 구현된다.파이프는 가장 많이 사용되는 Wikitext 중 하나임이 증명되었지만, 아래의 편집 도구 상자에만 나타난다.내 생각에 그것은 접근하기 쉽도록 편집 도구모음에서 가장 중요한 위키텍스트에 배치될 필요가 있다.사람들은 이것에 대해 어떻게 생각하는가? -- 익명의 반체제^Talk 인사 02:48, 2007년 7월 15일 (UTC)

나는 둘 다 좋아한다.2차 감시목록을 구현하는 것이 얼마나 어려울까?— sublime514 • 대화 • 2007년 7월 15일 03:04(UTC)

그 질문에 답하기 위해 개발부에 맡기겠다. -- 익명의 반체제^Talk 인사 14:52, 2007년 7월 15일 (UTC)

나는 우리가 파이프를 위해 스크린 버튼이 필요한지 확신할 수 없다.타이핑을 할 때, 한 글자에 대한 눈과 마우스에 손을 올리고 타이핑을 하는 것보다 Shift와 Backslash를 누르는 것이 항상 더 쉽다.특수 문자는 키보드에서 쉽게 사용할 수 없는 경우에만 화면에서 유용하다.Adrian M. H. 14:57, 2007년 7월 15일 (UTC)

쉽게 타이핑할 수 있다.==, 그러나 그것은 여전히 메뉴에 있다. -- Anonymous Dissident^Talk 15:02, 2007년 7월 15일 (UTC)

나는 2차 감시목록 아이디어에 강력히 동의한다 - 나는 종종 최근의 변화를 감시할 때 그와 같은 톨을 사용하고 싶었다.그러나, 그것은 공공 기물 파괴자들이 사용자들을 '표적'하거나 차별하는 것에 대한 그들의 주장을 증가시키도록 부추길 수 있다 - TINC, 그러나 당신의 일거수일투족을 감시하는 편집자들 그룹이 있다.각종 반반달 도구의 블랙리스트 기능도 떠오른다.파이프 기호의 필요성은 확실하지 않지만, 새로운 사용자를 격려할 수 있지만, 키보드 단축키와 Wikimarkup 기호 섹션으로 충분하다고 생각한다.ck lostsword•T•C 15:37, 2007년 7월 15일 (UTC)

솔직히 말할게.나는 사실 이 전에 파이프의 지름길을 알지 못했다.어쩐지 지름길을 놓친 모양이었다.그래서 그 아이디어는 쓰레기통에 버려질 수 있고, 그건 괜찮아.하지만 나는 2차 감시목록이 좋다고 생각한다. -- 익명의 반체제^Talk 인사 15:45, 2007년 7월 15일 (UTC)

Windows에서는 Alt+124를 사용하여 파이프(Windows Alt 키코드)를 만들며 기여도를 추적할 수 있는 방법이 이미 있다.복사 {{subst:js 사용자:트라/userwatchlist.js} 사용자:익명의 반체제 인사/모노북.js(사용자:Tra#User_watchlist).레이와스92^Talk 16:29, 2007년 7월 15일 (UTC)

1. 그것은 IE 2에만 해당된다. 그것은 맨 윗줄에 있는 것이 아니다; 그것에 대한 지식이 널리 퍼지지 않는다 3.일반 감시자 4명과 공유한다.내 IE에서는 작동조차 할 수 없다. -- 익명의 반체제^Talk 인사 16:34, 2007년 7월 15일 (UTC)

그것은 완벽하지 않고 종종 사람들에게 효과가 없다.MediaWiki 소스 코드나 확장자로 이와 같은 도구를 사용하는 것이 더 나을 수 있으므로 이는 일시적인 해결책일 수 있다.트라(토크) 16:52, 2007년 7월 15일(UTC)

• Bugzilla에 기능 요청을 게시하십시오.>Radiant< 13:01, 2007년 7월 16일 (UTC)

고급 시작 템플릿

기본은 이해하지만 위키백과의 더 발전된 측면에 관심이 있는 위키백과인들에게 정보를 제공하는 템플릿이 있는가?이런 종류의 것은 이미 존재하지 않는다면 유용할 것이다.나는 사람들이 이런 것에 대해 어떻게 생각하는지 보고 싶다.JavaScript 추가 기능, 고급 템플릿 구문, MediaWiki 버그 요청, 메타위키 등의 페이지에 링크를 제공할 수 있다.파이로스피릿 샤이니! 15:32, 2007년 7월 12일 (UTC)

위키백과 같은 페이지는 말할 것도 없고, 색인도 있다.부서 디렉토리 및 위키백과:빠른 디렉토리. -- John Brownon (ricticulative) 13:54, 2007년 7월 16일 (UTC)

단일 섹션 보기

확실히 모든 소음이 당신의 감시 목록을 막아버리지 않고 평소에 자주 다니지 않는 바쁜 페이지의 한 섹션을 보고 싶은 경우가 많았다.단 한 구획만 볼 수 있는 방법이 있다면 그 문제는 해결될 것이다.그건 분명히 가능하지, 그렇지?다른 데서도 언급했지만, 여기서 피드백을 좀 받아야겠다고 생각했다.Richard001 05:18, 2007년 7월 9일 (UTC)

그것은 가능하지도 않고, 쉽게 할 수도 없다.프로데고^talk 05:21, 2007년 7월 9일 (UTC)

그것이 가능한가, 어려운가, 불가능한가?Richard001 05:34, 2007년 7월 9일 (UTC)

지금 당장은 그럴 수 없으며, 그러한 기능을 추가하는 것은 아마도 서버들을 부하에서 떨어뜨릴 것이다.이 작업을 수행하려면 편집이 기록되고 페이지가 감시되는 방법을 완전히 다시 작성해야 한다.프로데고^talk 05:46, 2007년 7월 9일 (UTC)

그래, 어쨌든 알려줘서 고마워.Richard001 06:48, 2007년 7월 9일(UTC)

…그러니 해라.하지만, 나는 이 기능이 좋은 생각이라고 생각해, 그러한 변화를 만들면서 야기되는 문제들을 극복할 수 없을까?— The Storm Surfer 00:09, 2007년 7월 10일 (UTC)

적어도 토론 페이지의 경우, 이것은 제안된 리퀴드스레드와 같은 적절한 포럼/스레드 시스템을 구현함으로써 해결될 많은 이슈들 중 하나이다.Dcoetzee 08:19, 2007년 7월 9일 (UTC)

PHP를 통해 외부에서 할 수 있어, 몇 가지 방법을 생각해 볼 수 있어.실제로 보면, 한 섹션을 포함하지 않으려면 더 쉬울 텐데, 한 섹션을 제외한 모든 섹션은 코딩하는데 시간이 오래 걸릴 거야.++Aviper2k7++ 18:12, 2007년 7월 9일(UTC)

첫째, "섹션"은 취약하다. 제목이 바뀌고, 섹션이 병합되고, 하위섹션이 생성되며, 섹션이 이동된다(그래서 섹션 4는 섹션 3이었다).둘째, 전체 페이지를 편집하여 섹션을 편집할 수 있다. 새로운 기사는 항상 이 작업을 하기 때문에 이제 모든 전체 페이지 편집을 검사하고 어떤 섹션이 편집되었는지 확인해야 한다.디프 소프트웨어가 실제로 얼마나 나쁜 성능을 발휘하는지 볼 때, 많은 잘못된 긍정이 있을 수 있다.셋째, 하위섹션이 존재하는 경우, 섹션 이름이 아닌 하위섹션 이름이 편집 요약에 포함되기 때문에 전체 문서 편집 또는 특정 섹션 편집이 있었는지 확인하기 위해 요약 편집을 검토하는 명백한 전략조차 실패할 것이다. (그렇다, 이것은 모든 하위섹션 제목도 찾기 위해 코딩함으로써 얻을 수 있다. 그러나...). -- John Brownon (삼겹살) 02:18, 2007년 7월 10일 (UTC)

구현이 너무 어려운 것 같지만, 특히 AN과 AN/I와 같은 큰 페이지에는 유용할 것이다.다른 사람들에게는, 나는 우리가 그런 특징을 가졌으면 하는 경우를 거의 만나지 못했다.그 두 페이지 형식의 자동 변경이 도움이 될 수 있을까? (예를 들어, 사건/섹션당 RfA와 같은) 그래서 나는 항상 AfD와 FAS, RfA 등과 같은 페이지들이 새로운 사용자들에게 너무 복잡한 지시사항을 가지고 있다고 생각했고, 그리고 {{which의 편집 가능한 새로운 섹션 중 하나를 Liste에 삽입하는 절차가 매우 마음에 든다.d}} 봇 등을 통해 자동화한다.니코실버 23:31, 2007년 7월 12일 (UTC)

다른 접근 방식.X시간마다 외부 프로그램을 비교하고 우리가 관심 있는 섹션이 아닌 다른 섹션은 무시하도록 하라.watched 섹션이 더 이상 존재하지 않는 경우(섹션 제목 변경 또는 삭제) 또한 변경됨으로 표시하십시오(단면 ID에 대한 링크는 변경 가능하지 않음).개인적으로, 나는 이것이 만족스럽게 작동하도록 만들어질 수 있다고 생각하지 않는다.바쁜 페이지에서 특정 섹션을 추적하려면 섹션 제목(#Section_title이 있는 부분)을 북마크하고 해당 페이지를 자주 확인하십시오.— 신한 <토크 > 09:03, 2007년 7월 13일 (UTC)

기사의 한 부분에 대해서만 전횡을 특정할 수 없다는 것은 유감스러운 일이다.그럴 수 있다면 편집자는 자신이 감시하고 싶은 (말) 10개 또는 20개 섹션의 페이지를 설정할 수 있고, 하루에 한 번 (혹은 그 어떤 것이든) 섹션에 걸쳐서 기사를 직접 찾아가지 않고도 중요한 변화를 찾을 수 있을 것이다.(그렇다, 기사 일부의 전용은 태그 포함/무포함으로 할 수 있지만, 단순히 변경을 감시하기 위한 목적이라면 해당 조항은 안 된다; 하나의 기사에 같은 일을 하려는 여러 사람이 화해할 수 없는 갈등을 겪게 될 것이다.) -- 존 브로턴 (바운딩) 2007년 7월 16일 (UTC)

위키백과의 네임스페이스로 Wikinews 채택

위키네우스의 자원봉사자들의 고된 노력에도 불구하고, 턱을 후려치고 있는 것 같다.위키뉴스와 위키피디아를 동시에 도울 수 있는 것에 대해 토론을 제안하고 싶다.두 가지 큰 문제가 있는 것 같다.

1. Wikinews는 더 많은 사람들을 사용할 수 있다.
2. 위키피디아는 본질적으로 "뉴스 리포트"인 기사들로 넘쳐난다.

위키백과 for News에 새로운 네임스페이스를 만들고 뉴스를 이동하기 위한 간단한 절차를 수립하십시오. 기사들은 더 이상 "현재 사건"이 아닐 때 백과사전 네임스페이스로 이동하거나, 백과사전을 위한 것이 아닐 때를 위한 비활성 상태/아카이브로 이동하십시오.장점:그것은 뉴스 보도 엔진 뒤에 있는 "말의 힘"을 극적으로 증가시킬 것이고, 속보를 다루고 있는 비정부적 기사들을 위한 장소를 제공할 것이며, 위키뉴스 컨텐츠를 위키피디아에 채택하면서 현재 존재하는 라이선스 어려움을 해결할 것이다.이 제안은 바보같을 수도 있지만, 그렇지 않을 수도 있는 상황에서, 나는 더 많은 청중들에게 그것을 가져가기 전에 어떤 큰 결점이 있는지 알아보기 위해 여기에 제안하고 있다.PS야, 내가 이런 제안을 했으니 제발 내 가족과 애완동물을 죽이지 말아줘, 그냥 생각일 뿐이야. - 체어보이 (인터뷰) 04:05, 2007년 7월 1일 (UTC)

나는 이것을 가장 강력한 말로 반대한다.위키피디아는 백과사전이지 뉴스 서비스가 아니다.그것들이 종종 겹치는 것은 사실이다 - 위키피디아는 정기적으로 뉴스에 나오는 것들에 대한 기사를 가지고 있을 것이다.하지만, 글 쓰는 스타일은 완전히 다르다 - 우리는 현재 사건에 대한 백과사전 기사를 쓰고 있는 반면, 위키뉴스는 그들에 대한 뉴스 기사를 쓰고 있다.그 둘은 하나가 아니고 똑같다.레베카 04:09, 2007년 7월 1일 (UTC)

나는 이것이 참고할 가치가 있다고 생각한다.위키피디아는 더 큰 사용자 기반이 절실히 필요하며, 많은 위키피디아 사람들은 틀림없이 백과사전 스타일보다 신문 스타일을 쓸 수 있다.Wikinews는 하루에 3만 명 미만의 사용자들과 8-10개의 기사들과 함께 퍼터링하게 하기에는 너무 훌륭한 아이디어다.그리고 최근 뉴욕타임스 매거진 기사에서 알 수 있듯이, 위키피디아는 현재의 배치에서 위키피디아의 목을 조르고 있을지도 모른다.--ragesoss 04:34, 2007년 7월 1일 (UTC)

IRC에서 너희 둘에게 말했듯이, 이 제안은 기본적으로 위키네우스의 목적에 대한 체어보이의 명백한 오해로 인해 잘못된 것이다.위키백과에서 위키백과로 옮겨진 어떤 자료도 후자에겐 무용지물이 될 것이다; 뉴스 스타일보다는 백과사전으로 쓰여질 것이기 때문에, 위키백과 기사는 적어도 위키백과 편집자들에 의해 완전히 다시 쓰여져야 할 것이고, 여전히 쓸모가 없을 것이다, 왜냐하면 위키백과 기사는 여전히 콜보다는 하나의 사건에 대한 중요한 관점을 취하게 될 것이기 때문이다.Wikinews에 필요한 단일 뉴스 기사 접근법의 채택.이것은 이 제안의 주요 목표들 중 하나를 만든다: 위키피디아를 위키피디아에서 찾고 있는 현재 사건에 대한 내용을 버리는 장소로 사용하는 것은 관련된 모든 사람들에게 전혀 도움이 되지 않는다.

Wikinews를 홍보하기 위한 두 번째 언급된 의도에 대해서 - 이 문제에 대해 위키뉴스 사람들과 먼저 대화할 생각을 한 사람이 있는가?나는 위키뉴스 프로젝트의 독립성을 없애는 것이 편집자를 얻는 데 도움이 될 것이라는 것을 보지 못했다.더 유용한 접근방식은 위키프로젝트(특히 지리적 특성의 것)가 틈틈이 Wikiws에서 끼어들고 도움을 주도록 장려하는 것과 같은 두 프로젝트 사이에 실제로 약간의 유용한 조정을 하는 것이다.

위키피디아와 위키피디아는 모두 기사를 쓰는 방식이 매우 다르고 그에 따른 다른 편집 정책을 가진 심오하게 다른 프로젝트들이다.나는 이런 식으로 그들을 합병하는 것이 어느 프로젝트든 조금이라도 이득이 될 것이라는 증거를 보지 못했으며, 실제로 나는 그것이 위키네우스에 심각한 피해를 입힐 것이라고 주장할 것이다.레베카 04:47, 2007년 7월 1일 (UTC)

사실, 위키피디아 콘텐츠를 위키피디아로 옮기자는 게 아니라, 거기에 혼선이 있을 수도 있다고 생각해.또, 초기 게시물에서 언급했듯이, 더 많은 청중에게 전달하기 전에 먼저 여기에 깃대를 올리고 있다. - CHIERBOY (인터뷰) 04:51, 2007년 7월 1일 (UTC)

그리고 나서 같은 문제가 역방향으로 적용될 것이다.위키피디아는 백과사전 형식으로 완전히 다시 작성되어야 하기 때문에 위키피디아는 거의 쓸모가 없을 것이다.실질적인 효과는 체어보이가 위키백과에 관한 기사를 얻는데 그 주제가 주목할 만하다고 생각할 때마다 사람들은 처음부터 시작해야 할 것이다.둘 사이에 라이선스 호환성이라는 심각한 문제도 있다.레베카 04:54, 2007년 7월 1일 (UTC)

왜 이걸 사적인 것으로 만드는 거야?자, 그건 요구되지 않는다. - CHIERBOY (인터뷰) 04:56, 2007년 7월 1일 (UTC)

다른 방법이 없다면, 우리는 "뉴스는 위키뉴스에 즉시 보도된다.이후 위키피디아에서 이 사건이 지속적이고 역사적인 의미를 지닌다는 것이 명백해질 경우에만 나중에 취재를 하게 된다.백과사전에 적합하지 않은 "속보" 기사를 여기에 쓰지 마라.거기에 써라.만약 어떤 사람이 쓰여진다면, 적절한 백과사전 기사가 분명히 있을 때까지 위키뉴스에 그것을 소프트 리디렉션하라.그런 일이 언제 일어날지 예측하려 하지 말고, 분명히 있을 때까지 기다리시오."오늘 실제로 위키네우스를 볼 기회가 생겼고, 훌륭하게 작동하고 있어.위키피디아에 넣고 싶지는 않지만, 위키피디아가 그 공기를 막아버리는 것도 원하지 않는다. 이 경우 위키피디아의 공기와 사람들을 끌어들일 것은 속보를 보도하는 것이다.그리고 그들은 우리보다 훨씬 더 잘 할 수 있도록 준비되었다.그러니 그들에게 맡겨두자, 우리는 백과사전 기사를 하루나 일주일, 혹은 1년 후에 쓸 것이 확실해지면 쓸 것이 하나 있다.세라핌블레이드 05:04, 2007년 7월 1일 (UTC)

레이조스, 내가 위키네우스의 경선 실패를 어떻게 생각하는지 알고 싶니?"게시된" 기사는 더 이상 편집할 수 없다.그것 없이는, 너는 단지 또 다른 뉴스 출처일 뿐이다.일면에 나오는 모든 것을 잠그고 싶어하지 않고 뉴스 스타일로 글을 쓰고 시사 문제에 집중하지 못할 이유가 없다.이와는 대조적으로 위키피디아가 "뉴스에서" 항목을 다루기 때문에 보도는 지속적으로 개선된다.AP조차도 주요 행사 진행 중에 많은 최신 기사들을 제출할 것이고 다른 출판사들도 다양한 수정 과정을 거친다.옛날에 위키네우스의 누군가가 나 자신의 실생활 연구에 관한 기사를 썼지만, 그 기사에는 기초과학에 많은 재미난 오류가 들어 있었고, 나는 그것이 "출판"되었기 때문에 내가 할 수 있는 일이 없다고 들었다.만약 당신이 제3의 뉴스 서비스 이상이 되고 싶다면, 나는 당신이 출판의 개념을 완전히 없애도록 권하고 싶다.그동안 우리 위키피디아 사람들은 훨씬 더 우수하고 지속적으로 시사점을 갱신하여 당신을 격파하는 것을 즐기게 될 것이다.드래곤스 05:11, 2007년 7월 1일 (UTC)

위키피디아는 위키피디아와 양립할 수 없는 라이선스를 가지고 있다.Corvus cornix 04:39, 2007년 7월 1일 (UTC)

좋은 지적이야.자유 소프트웨어 재단은 크리에이티브 커먼스 귀속 라이선스 버전 2.0을 GFDL과 호환되지 않는 것으로 나열하고 있다. 반면 2.5의 호환성은 나열되지 않은 반면, 내가 정확히 기억한다면 호환성이 없는 것으로, 이 경우 전체 논의는 무효다.— 미친 범인과 천사 (대화 – 책상) 05:56, 2007년 7월 1일 (UTC)

Chairboy는 그의 제안이 "Wikinews 콘텐츠를 위키백과에 적용하면서 현재 존재하는 라이선스 어려움을 해결할 것"이라고 제안했다.그 진술 좀 더 명확히 해주시겠습니까, 의장님?나는 그 문제가 어떻게 해결되었는지 전혀 모르겠다.별도의 네임스페이스 아래에서도 위키백과에 대한 모든 기여는 GFDL에 따라 허가되어야 한다 — 미치광이 범인과 천사(talk – desk) 05:58, 2007년 7월 1일 (UTC)

미안! 내 말뜻을 분명히 했어야 했는데.위키백과 활동을 위키백과로 통합하는 것은 부작용으로서 위키백과가 사용하는 동일한 GFDL에 넣을 수 있을 것이다. 왜냐하면 위키백과는 동일한 프로젝트의 다른 네임스페이스가 될 것이기 때문이다.과거의 기사들은 영향을 받지 않을 것이고, 아마도 위키피디아의 네임스페이스와 같은 뉴스에서 새로운 이야기들이 만들어지는 깨끗한 돌파구가 필요할 것이다. 반면 위키피디아의 살아있는 이야기들은 완성되고 출판되어 결국 정적인 아카이브가 될 것이다.앞으로 위키뉴스: 또는 뉴스: 위키피디아의 네임스페이스는 프로젝트의 나머지 부분에 대한 라이센스 식별이 될 것이다.이것이 불쾌하다면 아마도 다른 실행 가능한 대안이 있을 것이다, 이것은 내가 처음에 생각했던 것이다. - 체어보이 (인터뷰) 06:22, 2007년 7월 1일 (UTC)

그 프로젝트들을 결합하는 것은 좋은 생각이다.네임스페이스가 따로 필요한지 잘 모르겠어.필요하다면 다른 기사와는 다른 '뉴스' 기사의 기준이 다를 수 있다는 것을 짐작할 수 있다.노력이 꽤 중복되는 것은 사실이다.위키피디아가 더 많은 청중을 보유하고 있기 때문에 속보 기사가 위키피디아를 더 잘 다루는 것 같다.나는 위키피디아에서 더 많은 것을 알기 때문에 위키뉴스 기사를 거의 보지 않는다.

위키피디아의 많은 사람들이 "백과사전처럼"을 뜻하는 "백과사전처럼"이라는 뜻으로 "완전하게"라는 단어를 사용하는 경향이 있다.다른 정의, "특히 정보나 지식의 포괄적 범위(일반적으로 또는 특정 주제에 관한 것)"[2]는 우리가 하고 있는 일에 훨씬 더 적합하다.왜 우리는 프로젝트의 범위에 이런 인위적인 제약을 두려고 하는가?위키피디아는 오래되고, 새롭고, 진지하고, 피상적이고, 언제나 정보와 지식의 포괄적인 원천이 되어야 한다.이렇게 서로 다른 포크를 결합하면 전체 포크가 강화될 것이다.뉴스 기사들은 그들만의 포털, 위키피디아, 카테고리 등을 가질 수 있다.솔직히 정책이나 가이드라인이 어떻게 많이 바뀌어야 할지 모르겠다.가장 큰 변화는 위키피디아가 소위 백과사전이라고 불리는 것을 느슨하게 해야 한다는 것이다.

우리가 그 주제에 대해 이야기 하는 동안, 다른 사업들도 통합되어야 할 것들이 있다.가장 먼저 떠오르는 것은 위키트리온이다.단어에 관한 백과사전이 아니라면 OED는 무엇인가?합치면, 논쟁할 AFD가 훨씬 적을 것이다.정의에 대한 네임스페이스를 만드십시오. "Word:" 그러면 단어를 찾는 것이 훨씬 쉬워질 것입니다(검색 상자에 "Word Search" 단추가 하나 더 있을 수도 있음).그러나 통합해야 할 또 다른 프로젝트는 위키스페다스로 분류된 리디렉션을 추가하면 전체 프로젝트를 대체할 수 있는 위키피디아에 카테고리 페이지를 만들 수 있다.어떻게 보일 수 있는지 예제는 범주:속주 판테라. -- ☑ SamuelWantman 07:08, 2007년 7월 1일 (UTC)

난 이 아이디어에 흥미가 있어, 체어보이.한편으로, 그것은 더 많은 사용자들을 끌어 모을 것이고, 다른 한편으로 두 프로젝트는 통합이 어려울 정도로 충분히 다르다.위키피디아와 달리 기사 발행에 관한 한 '출판 기사'는 현지 신문이 기자 기사를 게재하는 것과 같다.일단 인쇄하면 완성된다.나는 이 특징을 매우 좋아한다. 왜냐하면 나는 내 기사가 그 주제에 대해 뭔가 알고 있다고 생각하는 사람에 의해 완전히 엉망이 되는 것을 원하지 않을 것이기 때문이다. 비록 당신의 경우 당신이 그 주제에 연관되어 있다는 것이 명백하다면 나는 당신에게 연락하려고 했을 것이다.2007년 7월 1일 폭풍의^Aftermath 라이더 13:45(UTC)

음, 샘, 아마도 사람들은 "비키피디아는 백과사전이다"라고 말하는 곳이 너무 많고, 로고에 있는 "자유 백과사전" 슬로건도 없고, 성가신 작은 페이지 WP가 있기 때문에 "비키피디아는 백과사전이다"를 의미하는 것으로 정의하고 있을지도 모른다.위키피디아가 뉴스 사이트, 사전, 종의 디렉토리 또는 존재하거나 존재하는 모든 정보의 작은 조각들이 아니라고 말하는 것은 아니다.오, 그리고 그 페이지를 바꾸려고 노력하는 행운을 빌어, 그것은 위키피디아에서 가장 오래되고 가장 사랑 받는 페이지 중 하나야.모건 위크 17:53, 2007년 7월 13일 (UTC)

이것은 좋지 않은 생각이다.만약 우리가 백과사전을 만들기 위해 여기에 있다면, 우리는 백과사전을 만들기 위해 여기에 있는 것이다.만약 우리가 "일반 정보 허브" 또는 "정보와 지식의 종합 소스"라면, 우리는 조 밥이 그의 새 차에 대한 기사를 쓰고 맵퀘스트와 같은 운전 방향을 제시하도록 하는 편이 나을 것이다.WP !=구글, WP !=사전, WP !=뉴스 출처.나도 위키뉴스가 어떻게 운영되는지에 대해 의구심을 갖고 있지만 그것이 내 주된 관심사는 아니다.그것들이 모두 위키미디어 프로젝트라는 사실만으로도 충분하다. -위키 [부팅?] [스팸! 스팸! 멋진 스팸!] 05:27, 2007년 7월 11일 (UTC)

나는 드래곤즈 비행에 동의한다. Wikinews의 출판시스템에 있는 bi-i-i-ig의 유용성을 방해하는 문제가 있다.내 생각에는 1) 메인 페이지에 올려지는 것은 자동적으로 발행되어서는 안 되며 2) 출판은 사실을 알 때에만 이루어져야 하며 3) 나중에 잘못된 정보를 수정할 수 있는 여지를 가져야 한다.나는 단지 3점 만점에 올랐을 것이고 그것은 엄청난 발전이 될 것이다.

내 사용자 공간에서 뉴스거리가 너무 많아지는 기사에 붙기 위해 잠재적인 템플릿을 사용하고 있다. 사용자:모건 윅/뉴스기사모건 위크 07:37, 2007년 7월 13일 (UTC)

위키피디아에 네임스페이스로 채택되어야 하는 것이 있다면 위키피디아여야 한다고 생각한다.— sublime514 • 대화 • 2007년 7월 13일, 20:19 (UTC)

나는 Thesublime514에 동의한다.왜 위키피디아와 위키피디아에 대한 다른 기사들은 같은 종에 대해 가지고 있고, 왜 그것들을 제시할 다른 형식을 가지고 있는가, 그 목적은 본질적으로 그대로 남아 있는데?위키피아의 훌륭한 가이드라인은 두 위키의 합병과 함께 여기서 높이 평가되어야 한다.아 디트야 카비르 17:09, 2007년 7월 16일 (UTC)

위키버스

위키미디어 재단은 모두 훌륭하고 같은 협업 모델(Wikipedia, Wiktionary 등)에 위키 사이트 인구가 급증하고 있다.

웹 링을 설정하는 것은 어떨까? 즉, 모든 위키미디어 프로젝트 사이트(및 승인된 제휴 사이트)를 연결하는 탐색 가능한 스레드.Wikibus, Wikiworld, Wikispace, Wikinet, WikIQ라고 부를 수 있다(이 도메인 이름의 사용 가능 여부는 확인하지 않았다).

그냥 제안이다.

--Laurence white 17:30, 2007년 7월 17일 (UTC)

나는 네가 그것이 무슨 소용이 있을 거라고 생각하는지 잘 모르겠다 - 나는 이미 메인 페이지 하단에 적어도 대부분의 자매 사이트로 연결되는 링크가 있다고 믿는다.모건 윅 18:48, 2007년 7월 17일 (UTC)

내 환경설정을 통해 기본 글꼴 설정

위키피디아의 모든 페이지에 사용되는 표준 Arial 글꼴은 모든 사람이 쉽게 읽을 수 있는 것은 아니다.따라서 글꼴, 글꼴 크기, 글꼴 및 배경색 등을 설정하기 위한 새로운 기능이 내 기본 설정 페이지에 추가되어야 한다.글꼴을 선택하면 다양한 OS 간에 불일치가 발생할 수 있지만, 적어도 브라우저의 기본 글꼴은 읽기 위한 문서에서 사용할 수 있어야 한다.

이미 Monobook.css 파일에 사용할 글꼴을 설정할 수 있다.이것 좀 넣어줘.— 칼 (CBM · talk) 14:12, 2007년 7월 17일 (UTC)

body { font-family: Futura; }

목록 대 범주: 매우 특별한 경우

위키백과 대화로 이동:위키프로젝트 목록 § 목록 대 범주: 매우 특별한 경우

나는 다음 사항을 지켜보았다.

• 위키백과:방글라데시 기업 삭제/목록
• 위키백과:그리스 기업 삭제/목록
• 위키백과:일본 기업 삭제/목록
• 위키백과:삭제/기업명부(2차 지명)
• 위키백과:삭제/회사목록
• 위키백과:영국 기업 삭제/목록
• 위키백과:싱가포르 기업 삭제/목록

세 사람 모두 카테고리 아래에 나열된 기사의 대량 삭제를 제안했다.국가별 기업 목록.그 논쟁은 아무 진전이 없다 - 한 번의 평결이 또 다른 삭제 제안으로 이어지고 있다.나는 두 번째 지명자가 아니라 이것을 가지고 DRV에 가 달라는 요청을 받았다.하지만 단순한 DRV보다 더 큰 이슈인 것 같아 우선 여기서 논의해야 할 것 같아.정책에 대한 충분한 이해와 근면성을 갖춘 편집자가 적절한 과정을 통해 삭제되도록 기사화 할 가능성이 크다.하지만, 많은 편집자들의 지능을 계속해서 괴롭히는 기사들의 종류에 대해 폭넓은 합의를 하는 것이 항상 더 낫다.

기사를 삭제하는 것뿐만 아니라 이 범주에 기사를 보관하는 적절한 이유는 내가 링크를 제공한 페이지에서 이미 논의되었다.따라서, 나는 그것들을 다시 반복하지 않을 것이다. (WP는 무한한 서버 공간을 가지고 있지 않고 우리는 링크된 페이지로 이동하는 데 걸리는 몇 초의 시간을 만들 수 있다.)내 제안은 간단하다. 포함 기준에 대한 정책을 갖거나 모두 삭제한다.위키피디아가 노란 페이지로 변하는 것을 돕는다.아 디트야 카비르 09:47, 2007년 7월 15일 (UTC)

현재 형식은 범주와 큰 차이가 없는데, 문제는 IMHO 목록에 이름, 소유권, 전환/수익/이익, 1차/핵심 사업, 본사 등과 같은 기본 정보를 어떻게 표시해야 하는가에 관한 것이다.빨간 링크라도 목록에 남으려면 이 기본이 있어야 한다.Gnangarra 10:01, 2007년 7월 15일 (UTC)

• 이 경우에 나는 특히 이 결과와 이 결과의 차이에 따라 DRV로 가져가자는 제안에 동의한다.>Radiant< 13:01, 2007년 7월 16일 (UTC)
  • 그렇게 쉽게 빠져나갈 수 있는 방법이야.그러나 DRV는 특히 백과사전을 유지하기 위한 가이드라인(예: "적색 링크 없음")과 "기존 비즈니스 범주에 의한 조직" 및 "참조"와 같은 조직 방법을 만들 수 있는 경우 전체 등급의 기사의 전멸을 논하는 데 적합하지 않을 수 있다."편향되지 않은 주목할 만한 타사 참조 자료"와 같은 책임.DRV는 단지 삭제/삭제되지 않은 평결을 의미하며, 다른 전망에 대한 추가 논의를 위한 어떤 범위도 없다.아 디트야 카비르 15:21, 2007년 7월 16일 (UTC)
    • 한 가지 더 질문 - WP의 측정 방법:NOT#INFO 및 WP:NOT#DIR.나는 또한 흥미로운 에세이를 발견했다.아 디트야 카비르 15:34, 2007년 7월 17일 (UTC)

음, 회사 목록과 그에 대한 기본적인 사실들은 정말 유용할 것이다. 하지만 가능하면 컴파일하고 유지하는 것이 매우 어렵다.목록이 회사 이름의 디렉토리만 되어야 하는 경우, 목록을 모두 삭제하고 카테고리를 사용하십시오. --이전에는 JackLumber 19:25, 2007년 7월 17일(UTC)

특수 시 리디렉션 숨기기:모든 페이지

특수:모든 페이지에서 리디렉션을 숨길 수 있는 옵션을 주시겠습니까?— 잭 · 토크 · 19:12, 화요일, 2007년 7월 17일

• 페이지 편집 사용자:Jrockley/monobook.css를 추가하고 다음 줄을 추가하십시오.

  .모든 페이지 리디렉션 {display: none;}

• 그런 다음 전체 다시 로드(예: Shift+control+R)를 수행하십시오.>Radiant< 09:36, 2007년 7월 18일 (UTC)

  사용하는 브라우저에 따라 전체 새로 고침을 위한 지침은 다를 수 있다(CSS 코드가 동일하더라도). 위키백과:브라우저에 대한 지침을 보려면 캐시를 바이패스하십시오. --ais523 14:23, 2007년 7월 20일(UTC)

혹시...에 대해 코멘트해 주시겠습니까?

나는 위키프로젝트 코믹스가 제공한 지침을 다시 쓰자고 제안하고 있으며, 더 넓은 지역사회에서 의견을 보내주면 고맙겠다.고마워요.스티브 블록 토크 15:53, 2007년 7월 18일 (UTC)

새로운 위키 프로젝트 제안 "정의적 논쟁"

나는 이 제안을 어디서 해야 할지 잘 모르겠다. 위키피디아의 새로운 장소에서 위키피디아에 속할 수도 있고, 프로그래밍이 필요할 수도 있다.

나는 FAQ와 여러해살이 제안서를 다 읽어봤고, 내게는 분명해 보이지만 이런 제안은 전혀 보이지 않는다.

나는 위키피디아의 기사들을 편향되지 않게 유지하려는 노력에 박수를 보내지만, 일부 사람들이 편향되었다고 생각할 수 있는 관점이 있어야 한다.주류 언론과 유스넷, 그리고 다양한 인터넷 토론 그룹에서는 타당하고 잘못된 주장이 끝없이 반복되고 있는 거대하고 지속적인 토론이 많다.나는 위키 재단이 토론의 수준을 높이고 그릇된 사실과 논쟁의 끝없는 반복을 줄이려는 궁극적인 희망으로 이러한 토론들을 요약하고 명확히 하기 위한 참조 사이트를 구축할 것을 제안한다.나는 또한 이것이 위키피디아에 대한 부적절하게 편향된 편집들을 그들을 위한 확실하고 적절한 포럼으로 줄이기를 바란다.그것은 다음과 같은 경우에 바쳐질 것이다.

기본 표준:

캘리포니아 주 이니셔티브 유권자 정보 시스템과 유사한 5부 토론 시스템으로서, 다음과 같이 구성된다.

프로 논증
사기 논쟁
프로 논거에 대한 반박
사기 논쟁에 대한 반박
해당하는 경우 화해 보기

이러한 각각의 주장은 다른 관점과 반박에 적절히 상호 참조되고 계층적으로 배열되는 주제와 하위 주제들로 세분될 것이다.

그러나 하위섹션의 길이는 제한되지 않는다.높은 수준의 구체성과 명료성이 유지되어야 한다.

논쟁에서의 중복성의 결여 또한 가장 중요한 원칙이어야 한다.

형식논리와 수사학의 원칙을 따르지 않는 것도 주장을 편집하거나 제거하기 위한 근거가 된다.저자에게 의전성사를 통보해야 하고, 의도가 악의적이지 않더라도 반복적인 범법자는 금지해야 한다.

사실의 뒷받침, 허위 정보의 제조 또는 사실과의 의견 교체를 위한 인용문을 제공하지 않는 것 또한 편집, 제거 또는 최종적인 비난(사전 경고 포함)이다.

선택적 원칙:

이 프로젝트는 위키피디아의 공공 기물 파괴를 줄이기 위한 많은 영구적인 제안들 중 어떤 부분집합을 포함한 더 높은 수준의 기물 파괴 보호가 필요할 수 있다.

사용자는 논쟁의 한쪽 또는 다른 쪽에 등록해야 할 수 있다.

토론 내용에 대한 덜 공식적인 토론을 위한 게시판이 포함될 수 있다.

왜 특정한 잘못된 주장이 제거되었는지 설명하는 FAQ.

화해 관점 외에도, 우리는 양쪽 모두에 동의하지 않는 네 번째 관점을 위한 공간을 포함할 수 있다.그러나 나는 이 포럼의 구체성을 훼손함으로써 그 효용성을 희석시키는 관점이 지나치게 확산되는 것을 경계한다.

--Michalchik 22:05, 2007년 7월 17일 (UTC)

위키프로젝트를 만들려면 위키백과에서 제안하십시오.위키프로젝트 협의회/제안.그러나, 내가 보기에 당신은 또한 위키피디아의 중립적인 관점 정책의 변화를 제안하려고 할지도 모른다 - 만약 그렇다면, 당신은 위키피디아 토크에서 그것을 제기하고 싶을지도 모른다.중립적 관점. --Tim4christ17 00:33, 2007년 7월 18일(UTC)

만약 디베이트페디아를 복제하고 싶다면, 내 대답은 "왜?"일 것이다.-- John Briton (삼겹살) 21:13, 2007년 7월 18일 (UTC)

나는 디베이트페디아에 대해 몰랐다.

Nn-wann에서 "hangon"이라는 말이 정확한가?

글에 '행곤'을 붙일 기회가 없을 정도로 빠른 삭제가 이뤄지고 있는 것으로 보인다.나는 이것이 사실이라고 불평하는 것이 아니라 (결국, 그 사건이 명백하기 때문에 신속하게 처리되어야 한다)고 불평하고 있다. 그러나 나는 템플릿:Nn-wann은 그 기사를 사용함으로써 보관될 수 있다고 말하는데, 실제로는 그것이 실제로 가능할 가능성이 전혀 없는 것처럼 보일 때 대다수의 시간들이 그러하다.

제안:템플릿에서 "hangon" 언급 제거:Nn-warn 및 빠른 삭제와 관련하여 사용될 수 있는 다른 템플릿.Mrand 12:08, 2007년 7월 17일 (UTC)

• 행곤은 예의로, 증설비용은 거의 들지 않지만 제거하면 부피를 발생시킨다.기본적으로 문제의 삭제 기준을 위반하지 않을 수 있는 기사가 작업되고 있을 수 있다는 선의를 표하고 있다.빠른 삭제 기준을 충족하지 못하는 기사는 이전의 빠른 삭제와 상관없이 작성될 수 있기 때문에, 우리는 단지 정책을 철회하고 선의의 확장을 하는 것이다.경고 없이, 우리는 선의로 기사를 쓰고 있는 사람들을 화나게 하는 위험을 무릅쓴다.당신의 제안은 이것이 거의 보이지 않기 때문에 가치가 없다는 것이다.그것은 그것이 보이는 몇 번과 그것이 받아들일 수 있는 행동이라는 사실을 무시한다.그것은 정확한 제안이므로 제거되어서는 안 된다.아무도 행곤에 반응하지 않으면 정확하지 않을 것이다.우리의 빠른 기준이 명백한지 아닌지에 대해서는, WP의 토크 페이지를 통한 트롤로서, 단순히 그렇지 않다.CSD가 말해줄 거야WP를 통한 트롤링 경험이 있는 관리자로서 연설:푸른 달 위의 CSD, 약 50에서 100분의 1이 잘못 적용되었다는 것을 알았다.이렇게 삭제된 글의 수를 감안하면, 행곤을 상당히 늘릴 수 있는 글들이 꽤 많은 것이다.위키피디아는 백과사전을 만드는 것과 옳은 일을 하는 것 사이의 균형을 유지하는 행위다.Steve BlockTalk 12:52, 2007년 7월 17일 (UTC)
  • 나는 너의 요점을 이해한다.그러나, 내가 언급하고 있던 사례들은 기사가 표시된 지 몇 분 안에 즉, 모든 실제적인 목적을 위해, 어떤 인간도 기사가 이미 사라지기 전에 "행건"을 적용하기를 바랄 수 없을 것이다.그래서 나는 행곤의 선의의 의도를 높이 평가하지만, 내 요점은 거짓된 신의의식을 제외한 모든 것을 제공한다고 우리 자신을 속이고 있다고 믿는 곳에 일련의 삭제들이 있다는 것이다.아마도 그 일련의 사건들은 너무 작아서 별도의 템플릿을 만드는 것에 대해 걱정할 수 없을 것이다 - 이 경우 나는 그것을 받아들이게 되어 더할 나위 없이 기쁘다.미스터^T-C 14:15, 2007년 7월 17일 (UTC)
    • 음, 한 가지 제안은 경고가 있는 것과 없는 것 중 두 가지 버전을 갖는 것일 수도 있지만, 그것은 사소한 쓸모없는 것이다.템플릿을 적용하는 사용자는 관리자가 태그에 얼마나 빨리 동의하는지 알지 못한다.아마도 당신은 잘못된 기대를 하지 않고 사람들에게 행곤에 대해 알려주는 대체적인 표현을 제안할 수 있을 것이다.SamBC 14:28, 2007년 7월 17일 (UTC)
    • 나는 지금 내가 너의 요점을 이해했는지 확신할 수 없다.누군가 빠른 공지를 보게 되겠지만, 그것을 읽는 것과 행건 공지를 추가하는 것 사이에 기사가 삭제될 수도 있다는 말씀이세요?얼마나 빠른 삭제가 빠른지 잘 모르겠고, 종종 밀린 일이 있었고, 그리고 이것은 정말 모든 만일의 사태를 다루기 위한 일련의 과정들을 만들려는 것 같은 느낌인데, 나도 정말로 구독할 수 없는 것이다.나는 최선의 의도를 가지고 가능한 최선의 방법을 헤쳐나가고 모든 것이 잘못되었을 때 가능한 한 침착하고 도움이 되는 대로 모든 것을 정리하는 것을 훨씬 더 좋아한다.네가 말하는 요점은 고맙지만, 답이 있을지는 잘 모르겠어.Steve BlockTalk 15:15, 2007년 7월 17일 (UTC)
      • 어쩌면 "(지금부터 태그를 추가한 시점 사이에 관리자가 기사를 삭제하지 않는 한)" 또는 {{n-warn}의 경우, "(관리자가 이미 이 글을 본 시점까지 삭제하지 않은 경우)" (섹션 제목이 암시하듯이, 그는 {{db}}}} 사용자 토크 페이지에 추가된 템플릿에 대해 이야기 하고 있는데, 이 템플릿은 de dev에서 살아남는다.페이지를 넘김)모건 윅 18:46, 2007년 7월 17일 (UTC)
      • 정확해, MW. 스티브의 반응으로, 좋은 지적이야.모든 경우를 망라하는 규칙이나 과정을 갖는 것은 확실히 나의 욕망은 아니다.하지만 큰 노력 없이 일을 좀 더 깨끗하게 할 수 있는 방법이 있다면...미스터^T-C 20:39, 2007년 7월 17일 (UTC)
        • 이것은 확실히 좋은 추가가 될 것이다.나는 두 번째 단락을 다음과 같이 바꾸겠다.

          주제의 공신력을 주장할 수 있다고 생각되면, 추가함으로써 삭제에 이의를 제기할 수 있다.{{hangon}}페이지 상단(기존의 신속 삭제 또는 "db" 태그 바로 아래)에 [[Talk:{{1}} 기사의 대화 페이지]에 자신의 입장을 설명하는 메모를 추가하는 것과 함께, 그러나 일단 신속한 삭제를 위해 태그를 지정하면 언제든지 해당 기사가 삭제될 수 있다는 점에 유의하십시오.

        • 추가 세부사항에도 불구하고 동일한 대략적인 길이를 유지하도록 정보를 삭제하지 않고 언어를 약간 간소화했다.--Fuhgetteaboutit 23:09, 2007년 7월 17일(UTC)
          • 찬성도 반대도 듣지 못한 채 위와 같은 제안어를 올렸다.--Fuhgett about 21:35, 2007년 7월 18일 (UTC)

'카테고리:주목할 만한 위키백과 사용자들

대화 페이지 대신 기사 페이지로 이동 가능

토크 페이지를 통해 이 범주를 추가하면 이 범주를 덜 볼 수 있게 하기 위해 어떤 조치가 취해질 수 있다.Vjdchauhan 21:00, 2007년 7월 21일 (UTC)

그것은 보여서는 안 되기 때문에 정확히 대화 페이지에 올려져 있다; 그것은 자기 참조다.크리스토퍼 파럼(토크) 06:12, 2007년 7월 22일 (UTC)

우리는 (정상적인 위키피디아인들에게) 숨길까? 왜냐하면 자기 참조가 있기 때문일까, 아니면 혹시 있을 수 있는 반달 공격에 대해 숨길까?Vjdchauhan 13:00, 2007년 7월 22일 (UTC)

위키백과 참조:설명에 대한 자기 참조를 피하십시오.(그리고 Special:에서 서명을 수정하십시오.클릭할 수 있도록 설정.고마워 :) --Quiddity 01:32, 2007년 7월 25일 (UTC)

우리도 하위 카테고리를 가질 수 있을까?

약 900명의 유명한 위키피디아 사람들이 우리가 직업/국가성에 기초하여 이 범주의 몇 가지 하위 범주를 가질 수 있다.Vjdchauhan 21:00, 2007년 7월 21일 (UTC)

WP 조직:AN, WP:ANI 및 이와 유사한 공지사항 게시판(이 공지사항 포함)

이것은 아마도 이전 어딘가에서 메스꺼움으로 논의되었을 것으로 충분히 명백해 보이지만 (만약 그렇다면, 토론으로 연결되는 링크는 감사할 것이다) 하지만...

예를 들어, WP와 같은 새로운 주제의 추가 방식을 변경하는 것이 타당할까?AN/I, 그러면 각 새로운 주제가 기본 페이지로 변환되는 하위 페이지?WP:RfA에서처럼.이렇게 하면 관심의 실만 감시하고 그 실로 쉽게 이동할 수 있다.지금과 같이 ANI의 특정 스레드에 관심이 있는 사람은 페이지 전체를 다시 로드하고 아래로 스크롤해야 한다.TOC는 너무 길어서 그마저도 사용하기 힘들며, 특히 관심의 실이 중간에 있다면 더욱 그렇다.

내가 생각할 수 있는 유일한 단점은, 어떤 실에라도 변화가 있을 때마다 깃발을 볼 수 있는 방법이 있는지(즉, 지금 당장 ANI를 복제할 수 있는 방법은 없는지) 잘 모른다는 것이다.하지만 지금 당장은, ANI를 감시하는 것이 어쨌든 별로 도움이 되지 않는데, 왜냐하면 너무나 많은 편집자들이 한꺼번에 너무 많은 다른 주제들에 많은 변화를 주고 있기 때문이다.그리고 나는 메인 페이지에 워치리스트를 작성하면 새로운 주제가 추가될 때마다 당신에게 여전히 통지할 것이라고 생각한다.

내 생각에 RfA에서의 전폐는 템플릿 마술을 통해 이루어지기 때문에, 그들이 무엇을 하고 있는지 아는 누군가가 새로운 사용자들이 주제를 추가하는 것을 상당히 고통스럽지 않게 만들 수 있을 것이다.템플릿이 하위 페이지 이름에 어떤 종류의 시간/날짜 스탬프를 추가하도록 할 수도 있을 것이다. 그래서 WP와 같은 "인기적인" 주제 제목을 다시 사용하려고 하는 문제:다른 사용자로부터 모욕당한 ANI/I는 제거될 것이다.대신 곧 WP:ANI/I는 다른 사용자로부터 모욕을 당했다(2007년 7월 19일 13:26). WP:ANI/I는 다른 사용자로부터 모욕을 당했다(2007년 7월 21일 14:26), WP:ANI/I는 다른 사용자로부터 모욕을 당했다(2007년 7월 24일 15:26).

저장하기 전에 생각했던 또 다른 이점: 특정 스레드에 대한 다른 링크는 스레드가 보관될 때 더 이상 사용되지 않으며, 특정 시간이 지나면 전용 내용이 메인 페이지에서 제거되며, 보관된 토크 템플릿이 추가될 것이다.전폐를 보관 페이지로 옮기기만 하면 되는 겁니다.

나는 그러한 변화를 실제로 일으키는데 필요한 0.01%의 지식을 가지고 있기 때문에, 그것이 이루어졌으면 누군가는 그것을 떠맡아야 할 것이다. --barneca (대화) 19:02, 2007년 7월 19일 (UTC)

나는 이 제안을 전에 한 번 본 적이 있다. 비록 그것이 곧 영구적인 목록을 만들 것 같지는 않지만 말이다.당시 제기된 이의는 당신이 예상한 것 즉, "블록 검토"라는 제목만 있을 수 있고, 다른 모든 과목은 다른 이름이 필요할 것이다.당신이 지적한 바와 같이, 이것은 헤딩에 데이터 스탬프를 추가함으로써 해결될 수 있다.

그때도 지적되지 않았던 또 다른 문제는 감시자의 장점이 페이지의 포스터에 대한 불이익으로 상쇄될 수 있다는 점이었다.물론, 나는 편견을 가지고 있다 - 당신이 믿을 수 있다면, 나는 단순히 내 감시 목록을 사용하지 않는다 - 하지만 새로운 사용자들에게 하위 페이지를 만드는 것은 조금 복잡하고, 섹션 모델에 비해 서버 부하가 증가한다.하위 페이지 대 섹션의 선택은 임의로 보일 수 있다. 다양한 XFD를 메모한다. 그러나 익명 IP 사용자가 보고서를 제출할 수 있도록 하려면 새 페이지를 작성할 수 없다.또한 하위 페이지가 많으면 일부 정해진 아카이빙 봇의 작업 부하가 커진다.마지막으로, ANI에 게시된 대부분의 게시물은 상당히 낮은 트래픽(한 세 개의 응답)을 수신하므로 하위 페이지에서 제공하는 분리는 대개 필요하지 않다.샬롬 06:04, 2007년 7월 20일 (UTC)

나는 당신이 제기하는 많은 요점들과 성공적으로 논쟁할 수 있을 것이라고 생각한다. 그러나 이것은 "하지만 새로운 사용자들에게는 하위 페이지를 만드는 것은 조금 복잡하다. <클립> ... 익명의 IP 사용자들이 보고서를 제출할 수 있게 하려면 새로운 페이지를 만드는 것이 그들에게는 불가능할 것"이라고 말한 것이 아마도 내 계획의 치명적인 결점일 것이다.그 주위에 기술적인 방법이 있다면 구할 수 있을지도 모르지만, IP가 보고서 개시에서 차단되는 과정은 비스타터(non starter)라는 것에 동의한다. --barneca (talk) 12:37, 2007년 7월 20일 (UTC)

워치리스트 문제는 우리의 특별하고 관리하기 어려운 위키리드 시스템에 의해 야기된 또 다른 불필요한 문제인데, 그것은 실제 포럼 시스템에 의해 고쳐질 것이다.사용자: 참조:Dcoetzee/wikithreads가 나쁜 이유.Dcoetzee 01:59, 2007년 7월 21일 (UTC)

위키백과:가상 기사 게시판으로서의 텔레비전 기사 검토 프로세스

나는 텔레비전 위키피디아 주제의 검토 과정을 가상의 기사 게시판으로 확대하고, 스타일 매뉴얼에 따른 기사 정리 등을 논의하자는 제안을 했다.나는 우리가 소설에 관한 기사 내의 이슈들을 더 넓은 지역사회의 주목을 끌 수 있는 영역이 필요하다고 생각한다. 그리고 이것은 유용한 방법으로 보인다.위키백과에서 구현된 게시판을 미러링할 수 있다.프린지 이론/공지판, 위키백과:살아있는 사람들의 전기/공지판 및 위키백과:이해 충돌/알림판.위키백과 토크에서 의견을 제시하십시오.텔레비전 기사 검토 프로세스#확장.스티브 블록 토크 15:40, 2007년 7월 20일 (UTC)

소스 및 메뉴 모음의 개선 사항

나는 <노와키>가 시행되지 않는 한, 그 주위에 괄호가 있는 출처([]])의 단어들은 출처 바깥과 마찬가지로 연결될 수 있다고 제안한다.나는 이것이 접근성을 훨씬 더 쉽게 만들 것이라고 생각한다.나는 또한 소스를 몇 가지 미적으로 변화시킬 필요가 있다고 생각한다. 즉, 소스 상단의 전체 범위를 충분히 커버할 수 있을 만큼 메뉴바에 더 유용한 아이템이다.구체적으로 템플릿 탭({})을 메뉴 바에 추가해야 한다고 생각한다.사람들은 어떻게 생각할까? -- 익명의 반체제^Talk 인사 06:27, 2007년 7월 20일 (UTC)

텍스트 영역(bowers limit)에서 어떤 것을 "클릭할 수 있는" 것으로 만드는 것은 불가능하다고 생각한다."메뉴바에 더 유용한 아이템"은 너무 광범위해서 진정한 제안이 될 수 없다.어쨌든 WikWi 스크립트(약간 무거운, Firefox 전용), 추가 편집 버튼 스크립트, 다른 스크립트를 확인하십시오.중요한 것은 어쨌든 사이트 전체에서 받아들여질 것 같지 않다 ∴ 알렉스 스모트로프 13:38, 2007년 7월 20일 (UTC)

감시 목록 및 다중 편집

감시목록은 관심 페이지의 변경사항을 추적하는 데 유용한 도구지만, 여러 편집사항을 나침반으로 처리하면 크게 개선될 수 있다.현재, 그 시계는 가장 최근에 본 페이지의 편집만 보여주는 것 같다.

나는 사용자가 감시 목록의 각 페이지를 가지고 구식별 특정한 개정판을 시계의 "BASE"로 지명할 것을 제안한다.현재 내게는 최근 이슈의 차이만을 클릭하거나, 역사 목록을 볼 수 있는 옵션이 제시되어 있다.나는 또한 내가 지정한 "BASE" 개정판으로부터 현재 버전까지 단 하나의 차이점을 볼 수 있는 옵션을 원한다.현재의 "워치" 버튼은 (기본적으로) 수정본을 베이스로 설정해야 하며, 디프트를 볼 때 클릭 한 번으로 시계를 업데이트하여 새로운 디프트의 마지막 버전으로 설정할 수 있는 옵션도 있어야 한다.

나는 이것이 현재 감시 목록의 페이지 이름에 "&oldid=##########"를 추가하여 작동하는 것으로 상상한다.이는 선택 사항일 수 있으므로 특정 기준점을 고려하지 않고 계속 사용할 수 있다.구식 정보가 있는 경우, 감시 목록에는 (diff) 및 (history)의 현재 링크를 따라 이동하기 위해 클릭할 수 있는 단어 "base"가 한 개 포함되어 있을 것이다.

여기 (작업 링크 없이) 내 현재 감시 목록의 한 줄을 보여주는 구체적인 예가 있고, 내 제안이 채택되어야 할 다른 한 줄이 있다.

• (diff) (역사적) . 프란 나트; 10:06 . (+370) . 두애쿼툰세 (토크 기여)
• (base) (diff) (역사) . 프란 나트; 10:06 . (+370) . 두애쿼툰세 (토크 기여)

추가 베이스는 베이스 올디드에서 큐렌트 버전으로 디프를 주는 링크일 것이다.이것이 얼마나 힘들지는 모르지만, 선택적으로 봇과 미성년자를 제외한 기본 버전 이후의 변화 횟수를 주는 것도 가능할지도 모른다.제안서 제출 (t c) 00:02, 2007년 7월 20일 (UTC)

제안서 자체에 대한 코멘트 없이, 단지 당신이 인지하고 있는지 확인하고 싶을 뿐 1)선호도에 "해당되는 모든 변경 사항을 표시하도록 감시 목록 확장"이라고 표시된 버튼이 있다.2)팝업과 같은 응용 프로그램은 페이지를 마지막으로 편집한 이후 수정사항을 비교할 수 있는 기능을 가지고 있다. --Ybbbor^Talk 00:45, 2007년 7월 20일 (UTC)

고마워!그것은 정말로 내 걱정의 일부를 진정시킨다.내 제안의 주요한 새로운 효과는 감시 목록을 구성할 수 있는 더 나은 방법을 허용하는 것이다.그 팝업은 편리하긴 하지만 좀 짜증나.나는 이 모든 것에 익숙하지 않기 때문에 당분간 팝업을 시도해 볼 것이다.나는 이 제안을 남긴다, 왜냐하면 나는 편집자가 검토한 것보다 몇몇 지명된 베이스 버전으로부터의 차이점에 대한 간단한 링크로부터 아직 약간의 이점이 있다고 생각하기 때문이다. 그리고 그 이후에 일어난 일을 고려하는 근거로 사용하고 싶다.하지만 당신의 제안은 확실히 나에게 귀중한 즉각적인 도움을 주었다. -- 두아에 쿼탄세 (t c) 01:13, 2007년 7월 20일 (UTC)

내게 완벽히 작용하는 이미 존재하는 솔루션: 당신의 선호도에 워치리스트 → '워치리스트 확장'(위에서 언급된 바와 같이), '최근 변경사항' → '향상된 최근 변경사항'(따라서 함께 그룹화)을 배치한다.스크립트 이후 매우 유용한 감시 목록을 얻으십시오.그런 다음 별도의 브라우저 창을 사용자의 감시 목록에 지정하여 열어두고 "마지막 로드 이후 변경 사항" 링크만 클릭하십시오(새 창에서 디프/고리를 열어야 함).매번 이런 식으로 당신은 당신의 감시목록 항목의 새로운 변화만을 보게 될 것이다 ∴ Alex Smotrov 13:38, 2007년 7월 20일 (UTC)

너도 고마워!위키피디아에서 막후에서 얼마나 많은 일들이 벌어지고 있는지 놀라워.난 전혀 몰랐어...내가 제시한 제안서에 대한 마지막 작은 혜택은 다른 페이지에서 독립적인 체크 타임을 가질 수 있는 방법이 가능하다는 것이다.하지만 내가 보고 있는 대본의 종류로, 만약 누군가가 정말로 그것을 원했다면, 나는 그것이 추가될 수 있을 것이라고 확신한다.나는 만족한다. -- 두애쿼툰세 (t c) 13:56, 2007년 7월 20일 (UTC)

파업 코멘트 지침

파업적 논평을 위한 어떤 지침도 존재하지 않는 것으로 보인다.나는 매우 무책임한 방법으로 사용된 인상적인 특징을 본 적이 있다(적어도 나는 그렇게 생각한다).이것에 대해 다른 의견이 있으십니까?이것이 지역 사회 전체에 도움이 될까?2007년 7월 16일 Jmfangio f Talk 16:56 (UTC)이 될 것 같다.

네가 본 것의 예를 들어 줄 수 있니?Adrian M. H. 17:09, 2007년 7월 16일 (UTC)

사람들이 '무엇'에서 벗어나 '누구'로 관심을 옮겨가는 경향이 있다고 생각하기 때문에 나는 단순히 그렇게 하기를 주저할 것이다.간단히 말해, 한 사용자가 현재 돌아다니면서 다른 사용자가 게시한 대화 페이지의 댓글을 두드리고 있다.이 포스터의 원본은 현재 금지되어 있으며 양말인 것으로 보도되었다.댓글 중 상당수는 1년 전으로 '스트라이커'와는 아무런 관련이 없다.그는 그들의 내용에 상관없이 일방적으로 논평을 공격하고 있다.토론을 재검토하려고 할 때 어렵지는 않더라도 답답하게 만든다.Jmfangio talk Talk 17:30, 2007년 7월 16일 (UTC)

나는 우리가 토크 페이지 가이드라인에서 명확한 해결책을 가지고 있지 않아야 할 이유를 알 수 있다고 생각한다.다음[3]--Kevin Murray 21:45, 2007년 7월 16일(UTC)(이전 게시물 서명)에서 제안된 솔루션을 참조하십시오.

WP:TPG는 "다른 사람의 말을 편집해서 의미를 바꾸지는 말라.다른 사람의 댓글을 편집하는 것은 허용되지 않는다고 말했다.취소선을 추가하는 것은 분명히 대화 페이지에서 다른 사람의 말을 편집하는 것이다.그래서 이것에 대한 지침이 이미 있다.이에 대한 설명이 필요한 경우, 그 지침을 따르거나 위키백과에서 논의하십시오.토크 페이지 가이드라인. -- John Brown (식별) 20:33, 2007년 7월 16일 (UTC)

나는 위키백과 강연에서 동의하고 그것을 명확히 하려고 노력했다.Talk page 가이드라인을 제시했다가 즉시 되돌렸다.다른 사람의 댓글을 편집하는 것을 금지하는 것은 분명히 스트라이크ut을 포함하고 있다고 생각하지만 분명히 문제가 있고 새로운 편집자가 도움을 요청해 왔다.자세한 설명을 추가해도 문제가 없을 것 같다. --Kevin Murray 21:45, 2007년 7월 16일 (UTC)

문제는, 인식된 삭스푸펫에서 AfD!votes와 같이 취소해야 할 타당한 이유가 있거나 있다고 믿는 사람들이 많다는 것이다.적어도, 나는 그것을 보았고 아무도 불평하지 않는 것 같았다.그것은 명백히 파괴적인 투표였고, 양말 퍼피티를 악의적으로 이용했다. 하지만 만약 그것이 괜찮다면 정책의 전면적인 금지보다 적절하지 않다.SamBC 21:58, 2007년 7월 16일 (UTC)

• 나는 투표 상황을 벗어난 파업은 매우 나쁘다고 생각한다.이것이 내 질문을 자극한 것이다.나는 투표 그 자체가 (대담한 부분) 유죄판결을 받은 양말에 의해 사용되는 상황에서 통과되어야 한다고 말하고 싶다.만약 누군가가 거짓으로 유죄 판결을 받는다면 이것은 문제가 될 수 있지만, 위키의 유동성 때문에, 그리고 그것이 예외이기 때문에, 나는 그것이 우리가 가이드라인을 만드는 것을 막을 수 있다고 생각하지 않는다.다시 말하지만, 투표 상황에서, 나는 설명을 남기지만 투표를 통해 투표할 것이다.그 밖에서는, 사용자의 코멘트가 금지된다 하더라도, 이를 통해 공격해 나가는 것은 적절치 않다고 생각한다.TPG 페이지에 대한 간단한 코멘트가 있지만, 외부로 플러시하거나 위키의 다른 섹션으로 옮겨야 한다.Jmfangio ( Talk 22:05, 2007년 7월 16일 (UTC)

• 나는 양말 퍼펫을 포함한 부적절한 코멘트를 삭제하는 것을 스트라이크나 삭제의 예외로 보고 있으며, 나는 후자를 선호한다.단, 제거 또는 삼진은 정당한 사유가 있는 관리자가 수행해야 한다. --Kevin Murray 22:15, 2007년 7월 16일(UTC)

이것은 해결해야 할 문제다.가이드라인은 지금 적절한 사람들에 의해 쓰여질 필요가 있다.위키백과 커뮤니티의 논평, 그리고 WP와 관련된 이슈들이다.물린. 파업이 제대로 쓰이려면 뭔가 단단한 것이 있어야 한다. -- 익명의 반체제^Talk 인사 22:11, 2007년 7월 16일 (UTC)

(EC) AFD와 관련된 진술과 관련하여, 만약 그것들이 관통된다면, 그것은 그 진술을 덮어야 한다. 왜냐하면 굵은 단어는 단순한 요약일 뿐이고 주의의 초점을 받아서는 안 되기 때문이다.따라서 "!투표".당신의 편집자에 관해서라면, 나는 그가 매우 열성적이고 도움이 되지 않는다고 생각하는데, 그것은 마치 그가 차단된/금지된 편집자와 무슨 문제가 있었던 것처럼 보이게 한다.Adrian M. H. 22:12, 2007년 7월 16일 (UTC)

• 파업에 대한 너의 요점을 알 수 있다.내게는 그것이 문제의 일부분이 아니지만, 내 생각은 다음과 같다.한 사람이 한 표에 세 개의 양말을 사용하여 투표를 한다고 가정해 보자.세 가지 주장이 모두 독특하고 잘 숙고되어 있을 가능성이 있다.그러므로, 투표 자체는 고려되어서는 안 되지만, 사람은 그것을 읽는 것으로 이익을 얻을 수도 있다.아마도 각각의 선택에 대한 이유를 제시하는 것이 좋을 것이다.어느 쪽이든 간에, 나는 그 문제에 대해 너무 허심탄회해서 다른 사람들이 결정하도록 내버려두고 그것에 대해 "투표"하지 않을 것이다.상황이 이렇다 보니 위키불리스라고 생각하는 사람들이 일단 넘어가면 수리할 수 없는 일이 아니다.나는 이것을 자신의 페이지를 가지고 있어야 할 주요 이슈로 본다.그것은 WP에 적용된다.TPG 및 WP:CIV와 다른 모든 것들도 엉망진창이다.Jmfangio ( Talk 22:19, 2007년 7월 16일 (UTC)

• 파업 코멘트에 대한 짧은 지침은 '하지 마'이다.약간 더 긴 버전은 삭제 토론과 RFA 등에 관한 스트라이크 보트와 명백한 삭푸펫이나 미트푸펫에 의해 만들어진 것에 대한 예외를 추가했다.>Radiant< 10:47, 2007년 7월 17일 (UTC)
  • 금지령을 회피하기 위해 양말 인형들이 기부한 것이 삭제되거나 번복될 수 있는 허용은 되지만 제재되지 않는 사상의 학교가 있다. 하지만 나는 그것이 대화 공간에 적용되는 것을 기억하지 못한다.Steve block Talk 12:54, 2007년 7월 17일 (UTC)

• Radiant - 이 긴 가이드라인은 어디에 있는가? 아니면 WP에 대해 말하는 것인가?TALK 페이지?Steve Block - 이것이 문서화되는 곳이 있는가?나는 이 가이드라인을 정식으로 제정하는 것이 좋을 것 같아.Jmfangio ► Talk 21:58, 2007년 7월 17일 (UTC)

• 금지에 반하여 편집한 모든 내용을 수정한다는 금지 정책은 편집 자체의 장점과 상관없이 금지를 강제하는 것으로 되돌릴 수 있다. 금지된 사용자는 그러한 편집을 할 권한이 없기 때문에, 되돌리기 전에 그것들을 논의할 필요가 없다. 사용자는 일반적으로 금지된 사용자의 편집 내용을 다시 설치하는 것을 자제할 것으로 예상된다. 그럼에도 불구하고 그러한 편집을 복원하는 사용자는 그렇게 함으로써 자신의 내용에 대한 책임을 진다.이제 나는 당신이 금지된 양말에 의한 코멘트를 제거할 수 있는 허가를 내주는 것을 주장할 수 있다고 주장할 수 있지만, 나는 그것이 100% 그렇게 한다고 주장하지는 않을 것이다.:) Steve block Talk 14:41, 2007년 7월 20일 (UTC)

• 이제 WP:TOK 페이지는 "다른 편집자들의 허락 없이 다른 편집자들의 의견을 무시하지 말라"고 말한다.이것은 어제 되돌렸으나, 다시 갖다 놓았고 그것을 되돌린 편집장은 내가 덧셈에 대해 좀 더 자세한 설명을 한 후 그의 오피스를 풀어준 것 같다.이것으로 문제가 종결될 것으로 보인다. --케빈 머레이 22:06, 2007년 7월 17일 (UTC)

구글 페이지 순위

• http://blog.ericgoldman.org/archives/2005/12/wikipedia_will.htm

2005년 12월 05일

5년 안에 위키피디아가 실패할 것

에릭 골드만

주말에 나는 마이크 고드윈과 저녁을 먹었다. 하나는...

나는 그가 옳을 수 있다고 생각한다.구글 페이지 랭크는 우리에게 두 가지 문제를 준다.

• 사람들은 주목받기 위해 위키피디아에 있기를 원한다.
• 편집자들은 위키피디아의 납치를 피하기 위해 외부 링크와 기사들 모두와 똑같이 지나치게 교묘하게 싸우고 있다.

구글이 페이지 랭크를 설정하는 알고리즘에 우리를 더 이상 포함시키지 않도록 요청하자.

— 슈트웰(대화) 11:16, 2007년 7월 12일(UTC)

그 기사가 쓰여진 이후, 위키피디아는 외부 링크에 rel="nofollow"를 사용했기 때문에, 그들이 위키피디아를 스팸으로 보내면 더 이상 사이트의 PageLrank에 대한 어떠한 가치도 없다.그러나 사람들은 여전히 다른 이유로 스팸 메일을 보낸다.그들은 인간이 그들의 링크를 클릭하기를 바랄 수도 있고 혹은 그들은 rel="nofollow" 속성이 사용되는 것을 모를 수도 있다.Tra(Talk) 12:01, 2007년 7월 12일(UTC)

좀 더 목소리를 높여봐, 예를 들어 편집 메뉴에서?&#151; 슈트웰(대화) 12:11, 2007년 7월 12일(UTC)

(이것이 구글의 알고리즘에도 영향을 미치는 것이 확실한가?링크를 로드하고 카운터에 추가하는 것이 반드시 연결된 동작은 아니다. &#151; Xiutwel(대화) 12:13, 2007년 7월 12일(UTC)

마이크 고드윈은 현재 위키미디어 재단에 근무하고 있기 때문에, 그 평가에 동의하지 않는 것으로 보인다. :) 코버스 코닉스 20:22, 2007년 7월 12일 (UTC)

이 페이지가 "마이크가 내 주장에 동의하지 않았을 때 놀랐다.마이크의 견해는 위키피디아가 지금까지 공격에 놀랄만한 복원력을 보여주었고, 이것은 내가 생각하는 것보다 시스템이 더 안정적이라는 증거라고 말했다.아트로포스 05:34, 2007년 7월 13일 (UTC)

마케터들은 노 팔로우 태그에도 불구하고 위키피디아에 링크를 삽입할 것이다.http://www.searchengineguide.com/searchbrief/senews/010298.html을 참조하십시오.에릭. 2007년 7월 13일

Thx, 가장 흥미로운 것! &#151; 슈트웰 ♫☺♪ (토크) 20:32, 2007년 7월 20일 (UTC)

위키피디아의 링크 추가는 마케터들에도 불구하고 사용자와 관리자에 의해 되돌릴 것이다.우리는 여전히 이런 쓰레기들을 제거하는 거대한 사용자 기반을 가지고 있다. 하루 종일 수천 명의 마케터들이 링크를 삽입하지 않는 한, 스팸메일을 통과시킬 것 같지 않다.몇 년 안에 위키피디아가 실패할 것이라는 논문은 결국 우리의 사용자 기반이 저하될 것이라는 것을 가정한다. 그것은 내 생각에 중대한 결함이다.니힐트레스^(t.l) 13:14, 2007년 7월 15일 (UTC)

==RE: 제목==내 토크 페이지에 회신 참조) 그리고 회신을 올릴 때마다 이렇게 할 것이다.이렇게 하면 대화가 파편화되지 않을 뿐만 아니라 내가 당신의 의견을 인정했는지를 알게 될 것이다."

'페이지 저장' 버튼 바로 위에 '이것은 마이너 편집이다' '이 페이지 보기' 옆에 '이 페이지 보기' 같은 것이 있으면 좋을 것 같다.예를 들어, "이 스레드 변환" 옵션을 선택하고 "페이지 저장"을 누르면, 이 스레드가 내 토크 페이지에도 트랜스클로저를 통해 나타나며, 그 스레드에 대해 내 토크 페이지의 "편집" 링크를 누르면 내가 다시 여기에 게시할 수 있을 것이다.물론 여기에 게시된 모든 응답은 여기와 내 토크 페이지에 나타날 것이다.이렇게 하면 사용자 토크 페이지 단편적인 대화 문제가 해결될 것 같아.누군가가 이러한 "Transcluse this srad" 옵션을 만들 수 있는가? -- Jreferee 19:23, 2007년 7월 6일(UTC)[응답]

교폐는 많은 자원을 소모할 수 있다.스레드 포스트를 파편화된 토론으로 대체하기 위해 명령을 사용하여 두 개의 토크 페이지를 왔다 갔다 하는 봇은 어떨까? -- Jreferee 19:41, 2007년 7월 6일 (UTC)[응답하라]

왜 편집자들은 그들이 의견을 남기는 어떤 대화 페이지도 감시할 수 없는가?Adrian M. H. 19:42, 2007년 7월 6일 (UTC)[응답]

그 접근법에는 몇 가지 문제가 있다.한 사람의 감시자가 그 안에 많은 활동적인 페이지를 가지고 있다면, 섞어서 말하는 페이지를 잃어버리기 쉬울 수 있다.더 중요한 것은, 토크 페이지는 최근의 변화만을 보여주기 때문에, 가장 최근의 변화가 아닌 한 누군가가 여러분의 의견에 응답했다면 감시 목록에서 알 방법이 없다. 누군가가 그것을 바꿨다는 것을 볼 수 있을 뿐이다.다시 한번, 바쁜 토크 페이지에서는 당신의 답변이 끝난 후 다른 사람들이 많이 올리면 당신은 답변을 놓칠 수 있다.기술적인 해결책이 여기서 나쁜 생각인지는 잘 모르겠다.단순한 섹션이 아니라 + 버튼이 새로운 변환된 하위 페이지를 만들도록 하는 것이 쉬운 일일 것이다. 하지만 나는 그것이 인기 없는 생각이 될 것이라고 추측한다.— The Storm Surfer 22:24, 2007년 7월 6일 (UTC)[응답]

그러나 당신이 놓친 다른 개정판이 있다면 페이지를 확인하는 데 잠깐의 시간을 들이는 것은 그리 어렵지 않다.제안대로 나쁜 제안은 아니지만, 나는 정말로 이것이 문제를 찾는 해결책이라고 생각한다.아드리안 M. H. 14:33, 2007년 7월 7일 (UTC)[응답]

나는 이 아이디어가 장점이 있다고 생각한다.내가 참여하고 있는 프로젝트들 때문에, 나는 토크 페이지를 자주 이용한다.나는 종종 시계 탭을 확인하는 것을 잊어버리고 무언가가 "오, 예!"를 촉발할 때까지 내 메시지에 대해 잊어버리곤 한다.그러면, 때로는 너무 늦을 때도 있다.나는 두 페이지에 걸친 포스팅에 지쳤다; 완전한 답변과 "여기서 답장했어"라는 게시글.그건 아까워 보여서, 그때 나는 "여기 올리면 여기서 답장할게.만약 내가 거기에 글을 올리면, 거기에 답장해줘.그것은 나에게 효과가 없었다.지금은 내 기분에 따라 다르겠지위키피디아의 자원이 얼마나 필요할지는 고려하지 않고, 나는 이 아이디어를 지지한다.하지만, 만약 그것이 WP에 세금을 부과한다면, 나는 반대할 것이다.라라러브^T/_C2007년 7월 13일 04:31 (UTC)[응답]

(끝)최근에 이 템플릿({{Talkback}):

(예? 68.4.3.164 01:10, 2007년 7월 20일 (UTC)[응답하라]

여기 데려와서 웃기네...나는 이 토론에 대해 전혀 몰랐지만, 단지 위에 언급된 문제들을 극복하기 위해 며칠 전에 이 템플릿을 만들었다.위키피디아에서 발표했는데:Billage pump (기술)/Archive 142#New template. --Edokter (Talk) 11:26, 2007년 7월 20일 (UTC)[응답]

토크 페이지 전폐의 사용?

나는 대부분의 사람들과 같은 단편적인 대화 페이지 문제를 우연히 발견했다.이것은 보통 다음과 같은 것으로 해결된다.

이어 "내 토크페이지에서 토론을 시작한다면 내 토크페이지에 회신하겠지만, 짧은 성명(ex)을 통해 당신의 토크페이지에 회신하겠다.

이 태그는 합법적인 겁니까?

{{PD-구텐베르크}}에 대해서는 몇 가지 이유로 잘 모르겠는데, 그 대부분은 지금 이름이 바뀐 {{PD-NARA}}과 공유된다.

• 구텐베르크에 관한 모든 작품이 저작권을 벗어난 것은 아니다(에코 NARA의 "...대부분의 작품이 공공영역에 있다").
  • 이것은 어떤 경고도 주지 않으며 쉽게 (NARA의 오래된 템플릿처럼) 저작권이 있는 무언가를 "PD"하는데 사용될 수 있다.
• 그들이 저작권을 상실할 이유가 없다(Gutenberg 메인, 그들이 확인하는 모든 것은 미국 저작권이다), 따라서 그것은 잠재적으로 PD-US일 뿐이며 다른 곳에서 저작권을 획득할 수 있다고 명시하지 않는다(모든 Gutenberg 다운로드 페이지에는 미국 저작권만 확인한다고 명시되어 있다).
• 주로 IS가 PD를 맡고 있는 원본부터 저작권(!)을 주장하는 독일어, 라이프+70개국에서 저작권에 있는 라이프+50을 위한 호주어까지 구텐베르크가 여러 개 있다.

이와 같이 {{PD-US}}로 리디렉션하거나 소스 태그로 변경하거나 완전히 삭제하는 것이 좋다. 68.39.174.238 16:17, 2007년 7월 21일(UTC)

나는 이것이 WP에서 가장 잘 논의될 것이라고 제안한다.TAG. --Tim4christ17 16:31, 2007년 7월 21일 (UTC)

Tanx, 그렇게 할 것이다.또한, 이것에 회신하고 싶은 사람은, 거기서 새로운 토론을 확인한다. 68.39.174.238 01:02, 2007년 7월 22일 (UTC)

여러 확인란 정보

MediaWiki 편집 제안:watchlistit-normal-explain(사용자가 watchlist를 편집할 때 표시됨)을 클릭하여 한 번에 여러 개의 확인란을 선택할 수 있는 정보를 포함하도록 표시됨.미디어위키 내장 자바스크립트 기능 입니다.이 정보는 이전 MediaWiki에서 액세스할 수 있다는 점에 유의하십시오.Watchitlist (그런데 더 이상 시스템 메시지가 아니며 삭제하거나 "역사적 번데기"를 위해 어딘가로 이동할 수 있는) ∴ 알렉스 스모트로프 22:32, 2007년 7월 19일 (UTC)

상자보다 더 많은 상자가 체크될 수 있다는 것을 언급하는 것은 해가 되지 않지만, 대부분의 적당히 인터넷에 능통한 사람들은 양식을 사용하는 것으로부터 (디폴트 체크박스 행동 때문에) 그것을 알아야 한다.시프트 키를 들고 있을 필요는 없다고 생각해.Adrian M. H. 22:45, 2007년 7월 19일 (UTC)

좀 더 구체적으로 말해야 할 것 같다: 이 Javascript 기능을 사용하면 마우스 클릭 두 번만으로 원하는 수의 확인란을 선택하거나 선택 취소할 수 있다.한 확인란을 클릭한 다음 Shift 키를 누른 상태에서 다른 확인란을 클릭하면 중간에 모든 확인란이 변경된다.

특정 페이지(예: Special:삭제 취소(관리자가 어떤 편집을 복원할지 선택해야 하는 경우)는 본 공지뿐만 아니라 2007년 7월 19일(UTC) Alex Smotrov 23:10, Alex Smotrov 23:10도 이 통지로부터 혜택을 받을 것이다.

음... 스페셜에 관해서:삭제 취소, 아주 유용한 정보군. 지난번에 44번 클릭해서 수정본을 몇 개 선택적으로 삭제했는데...매우 귀찮은앞으로 42클릭 :)을 절약할 것이다.그런 점을 감안할 때 이런 통지문을 추가하는 것이 유용할 수도 있다.그 MediaWiki 페이지의 토크 페이지에서 {{editprotected}}을(를) 추가할 것을 제안한다.니힐트레스^(t.l) 01:48, 2007년 7월 22일 (UTC)

서명 및 사용자 이름에 허용된 길이 감소

서명의 현재 길이는 255자 입니다.그러나 서명이 긴 것은 서명이 원본 페이지에서 많은 공간을 차지하며, 탐색하기에 혼동될 수 있기 때문에 나쁜 형태로 간주된다.또한, 많은 사용자들은 단순화할 수 있는 매우 긴 서명을 가지고 있다는 경고를 받았다.왜 서명이 될 수 있는 총 길이를 제한하지 않는가?

사용자명도 마찬가지다.나는 그것의 최대 길이가 정확히 얼마인지 잘 모르지만, 그것은 너무 길다.사용자 이름이 매우 길고 반복적이며/또는 혼동되는 것은 이미 허용되지 않았다.사용자들은 심지어 이름이 길다는 이유로 차단되었다.한도를 줄여야 한다.댓글 있어?고마워!레이와스92^Talk 15:50, 2007년 7월 4일 (UTC)

만약 우리가 더 많은 규칙을 만들기 시작한다면, 나는 앞의 제안에 오버사이즈(즉, 보통 텍스트 크기보다 큰 글꼴 크기)와 컬러 사용자 서명을 제거하기 위한 관련 제안을 추가하겠다.창의성은 경이로운 것이지만, 현재 주어진 기사 이외의 공간은 편집자에 관한 것이 아니라 당면한 주제에 관한 것이 더 많은 것 같다.사용자 이름 또는 대화 페이지에 표시되는 사항에 대해서는 예외를 둘 수 있다.비엘 16:42, 2007년 7월 4일 (UTC)

위키백과:논란이 되는 일반 정책을 마련하려고 시도하지 말고 사례 발생 시 커뮤니티에서 허용 가능한 사용자 이름을 결정할 수 있도록 허용함으로써 지침이 왜곡되는 것을 피하십시오.λυΔαcγγγ 16:55, 2007년 7월 4일 (UTC)

내가 아는 것은 일부 사용자 이름은 실제 편집 요약을 위해 편집 요약에 거의 공간이 없기 때문에 실행 취소 기능을 사용할 때 문제가 된다는 것이다. - Kesh 16:57, 2007년 7월 4일(UTC)

이런. λυΔαcιγγγ 덕분에 위키백과에서는 다음과 같이 본다.서명, 섹션 4.1, 서명 색상과 크기에 대한 지침이 있다.그렇다면 나를 괴롭히는 사람들은 다른 사람을 괴롭히지 않는 것처럼 보일 것이다.비엘레 19:35, 2007년 7월 4일 (UTC)

사용자: 참조:아타에나라/갤러리 가장 노골적으로 짜증나는 것.그들은 정말 나를 짜증나게 한다.

색상, 크기 및 서체 변경이 기술적으로 불가능하게 되었으면 좋겠다(하위/위첨자 포함).사용자 페이지는 서명이 아닌 개인의 창의성에 적합하다. --Quiddity 20:39, 2007년 7월 4일(UTC)

그들도 정말 나를 짜증나게 한다. -- Hoary 21:43, 2007년 7월 4일 (UTC)

동의한다, 다른 글씨체를 사용하는 경박한 서명보다 더 나쁜 것은 없다.심각한 문서가 다른 글꼴로 서명되었다는 것을 들어본 사람? --AnonEMouse 13:46, 2007년 7월 5일(UTC)

현재의 기술 제한을 바꾸면 서명 문제를 해결하는 데 아무런 도움이 되지 않을 것이라고 생각한다.— The Storm Surfer 20:59, 2007년 7월 4일 (UTC)

[머리 자르기, 깊이 생각하기] 문제 서명을 불가능하게 만들어 도움을 주십니까(복사 및 붙여넣기 등 제외)? -- Hoary 21:43, 2007년 7월 4일(UTC)

서명할 때, 나는 그것들의 사용자 정의를 멈추고 싶지 않다. 단지 그것들이 길지 않도록 줄이기만 할 뿐이다.레이와스92^Talk 13:50, 2007년 7월 5일 (UTC)

나는 재미있는 서명을 좋아한다고 말할 수 있는 사람이야.나는 그들에게 아무런 문제가 없다고 본다.너희 모두 내가 너무 크고 혐오스러운 서명을 했다고 비난할 거라는 걸 알지만, 난 괜찮아.백과사전을 쓸 수 있는 것은 심각한 일이지만, 어떤 사람들은 재미와 즐거움을 방해하지 않는다면 떠나기 시작할 것이다.그런데 내 서명은 두 줄밖에 안 돼.레이와스92보다 긴 기호는 몇 개 안 된다.그냥 생각. --Tλε RαnΔom EΔδor (ταlκ) 22:50, 2007년 7월 12일 (UTC)

이 문제에 대해 더 이상 가이드라인을 제시할 이유가 없다...현재 가지고 있는 것으로 충분하다. (또한 - 하위/위첨자에 관해서, 더 많은 사람들이 그것들을 사용해야 한다 - 그것은 사용자의 대화 페이지를 더 쉽게 찾을 수 있게 한다.) --Tim4christ17^talk 14:05, 2007년 7월 13일 (UTC)

나는 우리가 가진 것으로 충분하다고 생각한다 - 나는 내가 몇 개의 유용한 연결고리로 단순하고 눈에 띄지 않도록 내 서명을 디자인했다는 것을 알고 있다.하지만 최근에 그것을 변경했을 때, 시스템이 나에게 포맷을 위한 충분한 문자를 허용하지 않기 때문에, 내 기여 페이지 링크를 삭제하지 않을 수 없었다. (이것은 당신이 볼 수 있는 것처럼 우스꽝스러운 것이 아니다.)또한, 많은 사용자들은 자신들과 다른 사용자들이 붐비는 토크 페이지에서 그들의 의견을 쉽게 찾을 수 있도록 독특한 서명을 디자인한다.내가 생각하기에 어떤 서명은 다른 사람들보다 조금 더 화려할 수도 있다(그래, 랜덤 에디터, 너의 서명은 약간 큰 편이야; ) 그것은 무엇이 합리적인가의 문제다.사용자들에게 커뮤니티로부터 서명을 변경해 달라는 요청을 받으면 어느 정도 강제되는 경우가 많다.서명이 번뜩이지 않는 한, 터무니없는 공간을 사용하는 한, 나는 어느 정도의 독창성을 허용하는 것에 문제가 있다고 보지 않는다.니힐트레스^(t.l) 14:43, 2007년 7월 13일 (UTC)

눈길을 끄는 서명의 문제점은 '대중 토크페이지에서 자신의 의견을 쉽게 찾을 수 있다'는 발언의 대척점이다.

그것들은 불필요한 텍스트 형식이 하는 것처럼 시각적으로 실을 흐리게 하거나 압도한다.그들은 붐비는 대화 페이지를 스캔할 때 신호(관련 링크)를 고르는 것을 더 어렵게 만든다.

그들은 또한 밝은 사용자 지정 서명의 혼란에서 기본 스타일의 서명을 선택하기가 더 어렵게 만든다.

그것들은 위키프로젝트 스타게이트 배너와 같다(토크:스타게이트) 표준 색상표 채택을 거부하여, 토크 페이지 배너 시스템의 의도된 단순성 일부를 어디에 배치하든 망쳐버린다.

그들은 감정이입이 부족하다.

대신, 사적으로 자바시프트를 이용해서 자신의 시그니처를 강조할 것을 제안하고 싶다.(이 코드를 monobook.js 페이지에 추가하고 "ais523"의 두 인스턴스를 사용자 이름으로 대체하십시오.)

그런 다음 자신의 사용자 페이지에서 원하는 만큼 창의적으로 작업하십시오. --Quiddity 19:43, 2007년 7월 15일(UTC)

요점을 정확히 설명하자면, 보통 문제가 되는 것은 미학이 아니다(나는 편지/팬트 대담성, 랜덤 에디터가 사용하고 있는 것, 그리고 Radiant!와 같은 편집자의 색상 선택 등이 꽤 마음에 든다). 시각적, 정신적으로 모두 산만하다는 것이다. --Quidity 20:15, 2007년 7월 15일 (UTC)

"날 봐!날 봐!" 대부분의 편집자들이 사용하는 기본 표준보다 더 크고, 밝고, 더 복잡한 서명에 대한 품질.나는 만약 짐보 웨일스가 소리치지 않는다면, 아마도 우리 모두 똑같이 말수가 적어야 한다고 결론짓고 싶다.비엘 21:22, 2007년 7월 15일 (UTC)

최근에 처음으로 매우 긴 서명(코드-wise)을 사용하는 사람과 토론을 해 본 적이 있는 나는 그들의 서명이 편집창의 5줄로 채워지기 때문에 토론을 읽는 것이 혼란스럽다는 것을 인정해야 한다.나는 다른 사람들이 맞춤 서명을 하는 것은 괜찮지만, 왜 그렇게 무의미한 일에 그렇게 오랜 시간을 소비하는지 궁금해 하는 경우가 많다.아트로포스 00:41, 2007년 7월 22일 (UTC)

더 간단한 홈 페이지?

홈 페이지 http://www.wikipedia.org/은 때때로 광대역 연결에도 불구하고 많은 수의 링크 때문에 매우 느리게 로딩된다.검색 필드 아래의 링크를 "자신의 언어를 찾아라"와 같은 하나의 링크로 줄이는 것은 어떨까?

위키피디아에서 무언가를 찾아보는 매크로가 있기 때문에 그것을 알아차리고, 내가 추가한 몇 초의 지연에도 불구하고, 내가 찾고자 하는 단어에 매크로가 붙여지기 전에 페이지 로딩이 이루어지지 않는 경우가 종종 있다. 그리고 실패한다.

당신의, Eolake — 앞의 서명되지 않은 논평은 Eolake에 의해 추가되었다(토크 • 기여).

대신 검색 페이지를 가리키도록 매크로를 변경하시겠습니까?pw 15:35, 2007년 7월 21일 (UTC)

정보 리포스토리

얘들아, 내가 제출한 이 기능 요청서를 확인해보고 네가 어떻게 생각하는지 봐(내 의견을 읽으면 내 아이디어를 볼 수 있다. 왜냐하면 내 의견은 회신자에 의해 쉽게 바뀌었기 때문이다.[4]
페르디아 오브라이언2007년 7월 20일(UTC) 19:23(토크)

이것은 버그질라 요청에 적절한 주제가 아니었다. 왜냐하면 그것은 중대한 정책 변화를 수반하기 때문이다.소프트웨어 변경도 필요하지만, 개발자들은 대규모 커뮤니티 지원이 없는 한 요청을 무시하겠다는 것이다.

그 제안은 (간단히) 다음과 같다.

위키백과 내의 기사는 "기사"와 "대화"를 보완하기 위해 세 번째 페이지를 가져야 한다.이 세 번째 페이지는 "Repository"와 같은 이름을 가져야 하며, 레이아웃 등과 같이 기사의 사양에 맞지 않는 주제에 대해 알려진 모든 정보를 조직화된 방식으로 저장해야 한다.장점은 기사가 해당 주제에 대해 사용 가능한 모든 정보(여전히 참조되는 경우)를 보유하는 동시에 기사를 혼란스럽게 하지 않는다는 것이다.주요 기사의 정보의 타당성에 대해 변형이 있는 문제가 발생하는 경우, 단순히 저장소에 보관할 수 있다.

(1) "후회"는 대규모 저작권 위반이 일어나는 장소처럼 들리는데, 대부분의 "모든 것"이 다른 사람에 의해 소유된다면 어떻게 정확히 "모든 것"을 수집할 수 있을까? (2) 적어도 "외부 링크"나 "참고자료"에서 언급될 만한 가치가 없는 중요한 (백과사전 목적상) 정보는 상상하기 어렵다.es" 또는 "expective reading" 섹션으로, 그렇다면 이 리포지토리가 백과사전에 대한 후속 작업에 정말로 유용하게 사용할 수 있는 정확히 어떤 것을 보관할 것인가? (매우 구체적인 예는 정말로, 정말로 감사할 것이다)마지막으로, (3) 위키피디아의 목적은 WP에 따라 유익한 기사를 쓰는 것이 아니라,무차별적으로 정보를 수집하는 것이 아니다.이것이 위키피디아를 거대한 정보 수집가로 만들기 위한 제안이라면, 위키피디아 토크에서 그것을 논의한다.위키피디아가 아닌 것은 여기보다는 시작하기에 더 좋은 곳일 수도 있다. -- 존 브로튼 (식용차) 23:16, 2007년 7월 21일 (UTC)

아니면 새로운 프로젝트인 위키리포지토리(Wikirepository)의 창설을 제안한다.A.Z. 23:48, 2007년 7월 21일 (UTC)

제안된 가이드라인: 표절

며칠 전 나는 WP에 다음과 같은 글을 올렸다.VPP는 공공 도메인 출처 인용과 표절에 관한 것이다.지금 나는 그것에 대한 정책이나 가이드라인을 제안하고 있다.다음 위키백과 대화를 참조하십시오.스타일#제안 가이드라인: 표절 & 토론 참여고마워. --Yksin 00:55, 2007년 7월 24일 (UTC)

나는 추천서를 추가하는 것에 찬성한다!

문제:입증 자료를 제공하는 것이 비교적 쉽고 유용하며 적절할 때에도 많은 사람들이 WP 기사에 참조되지 않은 내용을 추가하는 것을 즐긴다.특히 '팬 베이스'를 끌어들이는 '대중문화' 주제와 기사에 대해서는 더욱 그렇다.

원인: 한 가지 가능한 원인: 인용문은 추가하기가 좀 번거롭다.

해결책:사용자가 다음을 입력할 수 있는 드롭 데드 단순 검색 상자: 1) 쿼리를 입력하거나 2) "구글 북스"에 쿼리를 발급하거나 3) 이미 입력된 필드를 사용하여 미리 포맷된 "ref" 태그를 얻거나 인라인 인용을 위해 문서 텍스트에 잘라 붙여넣을 준비가 된 경우.

근거:출판된 작품에 적절한 형식의 인라인 인용문을 추가하는 것이 쉬울수록 좋다.이것은 기사에 걸쳐 통일성과 일관성을 증가시킬 것이다.

함정:한 가지 잠재적인 함정이 있는데, 이것은 사람들로 하여금 그들이 실제로 읽지 않은 참고문헌을 추가하도록 부추길 수 있고, 기사에 제시된 요점을 실제로 입증하지 못한다.반박: 그렇게 하는 사람들은 아마도 참고자료를 추가하는 것이 얼마나 쉬운지에 상관없이 그것을 할 것이다. 이것은 위키코드를 배울 시간이 많지 않은 사람들에게 "입문 장벽"을 낮출 뿐이다.

나 혼자만 이런 생각을 할 수는 없지만, 지금까지 아무것도 보지 못했다.다른 사람이 이미 이것에 대해 생각해 봤다면 나는 내 코드로 해킹을 시작하고 싶지 않다.의견 및 피드백을 제공하십시오.고마워. 2007년 7월 23일 닥터ef.tymac 20:07 (UTC)

또 다른 잠재적 함정:검색과 코드가 뱉어낸 것은 그들이 쓰고 있는 내용과 아무 관련이 없을 수도 있어 참고인을 강제 수용하지 못하게 한다.
"그것을 하는 사람들은 아마도 참고자료를 추가하는 것이 얼마나 쉬운지에 상관없이 그것을 할 것이다, 이것은 단지 위키코드를 배울 시간이 많지 않은 사람들에게 "입문 장벽"을 낮출 뿐이다."
그리고 올바른 소싱을 사용하는 구성원은 이 기능을 사용하는 경향이 있어 부주의한 스팸 발송자가 될 수 있다.
그럼에도 불구하고, 나는 당신의 아이디어가 마음에 들어, 나는 출처를 찾는 것을 싫어해.
Gbenemy 20:15, 2007년 7월 23일 (UTC)

나는 비참조 자료는 당신만큼 –아마도 – 싫어하지만, 위의 인용된 반박문구를 반영해야 하며, 자신의 자료를 적절하게 연구하고 통상적인 방법으로 각주를 만드는 것이 글쓰기 과정의 중요한 두 가지 부분이라는 것을 지적해야 한다.ref는 실행이 간단하고 연구가 주체에 대한 이해와 공감을 발전시키기 위해 필수적이다, 심지어 광범위한 수준에서 이미 알고 있는 경우에도 말이다.연구와 독서는 기사를 만드는 즐거움(또는 실질적으로 기여)의 일부다.아드리안 M. H. 20:47, 2007년 7월 23일 (UTC)

나는 100% 동의한다.사실 내 제안의 어떤 측면이 연구와 주제 친숙함을 위한 잠재적인 "대체"로 해석될 수 있다면, 내가 추구하는 것이 아니라고 분명히 말하겠다.다시 한 번 말하지만, 합리적으로 알고 있는 기고자들이 잘 찾아낸 내용을 대신할 수는 없다.

그럼에도 불구하고 무뚝뚝하게 말하자.누가 내 제안을 인용할 것 같지 않아 보이는군, 말하자면, '선택의 악시오'에 인용구를 붙이는 데.만약 누군가가 그 주제에 익숙하지 않고, 시트를 위해 "구글"을 필요로 한다면, 그들은 아마도 그 기사를 처음부터 편집하지 말아야 할 것이다.나는 그 기사의 기고자들 대부분이 내가 제안하는 것을 사용하는 것을 고려조차 하지 않을 것이라고 감히 추측할 수 있다.

그러나 단순히 그 주제에 대한 학문적 친숙성이 보통 이런 종류의 과목의 전제조건으로 간주되지 않기 때문에 누군가가 '선택의 공리' (밴드)에 대해 근거 없는 편집을 할 가능성이 매우 높다.아마도, 그것은 ...여야 할 것이다. 하지만 현실을 직시하자.너무 많은 사람들이 WP를 그들이 가장 좋아하는 밴드/팝스타/무엇이든 간에 경의를 표하는 좋은 방법이라고 생각한다.

내가 말하고 싶은 것은, 아마도 이 후자의 기고자를 도울 수 있는 몇 가지 도구만 더 있으면, 더 적은 논쟁과 변명의 여지가 있을 것이고, 참고 자료를 추가해야 하는 더 "더 많은 압박"이 있을 것이라는 것이다.그럼에도 불구하고, 나는 여기에 균형잡힌 고려가 있다는 것을 알고 있다. 그래서 나는 처음에 "폭락"을 인정했다.나는 그들이 언제 그렇게 쉽게 얻을 수 있을지에 대해 그렇게 많은 반복적인 언급 거부 요청을 하는 것을 보는 것이 조금 슬프다고 생각한다.M.H.고마워 2007년 7월 23일 (UTC.ef.tymac 21:13, Dr.ef.tymac 21:13

내 의견을 말하자면, 위키피디아:인용문 템플릿은 인용문 작성을 위한 나의 원스톱 샵이다. 나는 단지 새로운 줄의 글자를 복사/붙여넣고, 작성하고, 지운다.실제로 인용문을 추가하는 것은 일의 1% 정도인 반면(공정하게 말하면 소프트웨어는 나의 생활이고, 다른 사람들에게는 10%까지일 수 있다) 참고문헌을 찾는 것은 그 나머지다.자신의 라이브러리(예: mine)와 Google Books/CiteSeer/에서 수동으로 소스를 검색하는 것은 제안된 검색 상자를 사용하는 것만큼 쉬울 것이다.BigNate37_(T) 20:58, 2007년 7월 23일 (UTC)

네이트의 말 들려나는 당신의 '원스톱' 접근법과 비슷한 일을 한다(예: 여기 참조).하지만 만약 당신이 실제로 ISBN, 타이틀, 연도 등을 다시 수정할 필요가 없다면, 당신의 1%가 더 줄어들 수 있다고 장담한다.자르고 붙일 때마다."위키 코드"가 실제로 무엇인지 거의 이해하지 못하는 사용자들을 상상해 보십시오. (비프로그래머는 말할 것도 없고) 음울한 상황이지만, 왜 참조를 추가하는 사용자들이 그렇게 많은지 알 수 있다. 비록 그것이 De 리고르여야 하지만...그 기사에는 참고자료가 없다!D'OH!!). dr.ef.tymac 21:22, 2007년 7월 23일 (UTC)

어떤 템플리트에서도 연결되지 않은 참조 생성기와 템플리트에서 찾은 위키백과 템플리트 채우기가 있다.PMID. Graham87 00:58, 2007년 7월 24일 (UTC)

제안과 프로젝트가 있다.모든 WP 읽기:특히 하단에 가까운 발. (SEWilco 04:06, 2007년 7월 24일(UTC))

위키백과를 편집할 수 있는 사람들에 대한 합리적인 제한

2007년 7월 20일

To; 모든 위키백과 사용자,

위키백과의 편집 방침이 위키백과의 편집이 허용된 개인을 공명정대하게 제한하도록 변경해 줄 것을 제안하고 싶다.또 다른 권고사항은 이 무료 온라인 백과사전의 편집이 허용되기 위해서는 반드시 신청해야 하는 심각한 선별 절차를 갖추는 것이다.내가 이 제안을 하는 이유는 매우 명백하다고 생각한다; 위키피디아에 있는 웹 페이지의 심각한 파괴는 종종 발생한다."무드 링스"에 관한 E-기사는 다른 많은 것들 중 하나의 예일 뿐이다.비록 어떤 사람들에게는 무드 링의 주제가 아무리 일상적인 것일지라도- 나는 여전히 이 중편한 물건들에 관한 정보가 합리적으로 정확하기를 원한다.나는 가끔 무드 링에 관한 E-기사들을 확인하는 것에 매우 싫증이 나지만, 그것들에 관한 웹기사들에는 잘못된 정보, 잘못된 정보, 미친 정보, 심지어 외설적인 항목들이 포함되어 있는, 다시 심각하게 훼손된 것을 발견하게 된다."무드 컬러 차트"는 이 반달들이 가장 좋아하는 타겟으로 보인다.Mood Rings의 항목을 Mood Color Chart로 수정하여 편집했으며, 편집이 정확하도록 모든 노력을 기울였다.

(인터넷이 기본적으로 전세계적으로 어떻게 보여지는가를 고려한다면) 이 무료 온라인 백과사전을 이용하는 모든 사람들이 전자방사선 도전에 의해 저질러진 잘못된 정보로 폭격을 받는 것은 심각한 실례라고 생각한다!

시간 내 주셔서 감사합니다

Dawnofrabbits 19:58, 2007년 7월 20일 (UTC)

짐보에 따르면, "누구나 편집할 수 있다"는 것은 협상할 수 없는 공리라고 한다.시티즌디움을 보고 싶을지도 모른다.그렇기는 하지만, 우리는 그들이 바보라는 것을 증명하는 사람들을 쫓아낼 더 효율적인 방법이 필요하다.4개월과 2건의 중재 사건 이후 사람들을 금지하지 마라.그들이 건설적으로 기여할 수 없거나 원하지 않는 것이 명백해짐에 따라 반 장관은 반 총장이 된다.그것은 우리의 공리를 위반하는 것이 아니라, 단지 우리의 차단 관행을 합리적으로 조이는 것이다.dab (iii) 20:10, 2007년 7월 20일 (UTC)

(충돌 편집)그래, 좋은 편집자만 있으면 (이론적으로) 좋을 텐데, 잠깐 현실을 주입해도 될까?첫째로, 이것은 재단의 원칙이다; 누구나 편집할 수 있고 그것은 변하지 않을 것이다.둘째로, 좋은(또는 나쁜) 기고가 많은 일부는 정규 편집자도 아닌 애논 IP 사용자들로부터 나온다.그렇기 때문에 균형적으로 현재의 제도가 더 좋고, 이 기간 동안 변하지 않았고, 가까운 미래에도 계속 시행될 것이다.아드리안 M. H. 20:12, 2007년 7월 20일 (UTC)

(편집 후 갈등) 문제가 있다고 판명된 기존 편집자에 대한 통제를 강화할 필요성에 대해 디바흐만과 의견이 일치해야 한다.아드리안 M. H. 20:14, 2007년 7월 20일 (UTC)

모든 IP가 파괴적인 것은 아니지만, 더 나쁜 범죄자들보다 더 많은 것이 등록된 계정이다.기회가 있을 때마다 우리는 그것들을 제한하지 않고 편집을 장려해야 한다.그낭가라 03:40, 2007년 7월 21일 (UTC)

매우 책임감 있고 중요한 몇몇 사람들은 IP 주소로부터 위키피디아를 편집한다는 것을 명심하라.내가 가장 잘 아는 예는 워드 커닝햄에게 있는데, 그는 나에게 "내가 할 수 있기 때문에 - & 나는 그것이 멋있다고 생각하기 때문에" 그렇게 한다고 말했다. (그는 최근에 위키피디아에 사용자 계정을 만들었지만, 아직 그것을 편집한 것은 아닌지 의심스럽다.) -- 2007년 7월 23일 (UTC) 19:20, 7월 23일 (UTC)

스텁 카테고리만 있는 분류되지 않은 페이지를 가져오는 방법

모든 페이지에 스텁 범주가 있고 일반 범주가 아닌 범주가 있는 페이지가 있는지 알 수 있는 방법이 있는가?Vjdchauhan 16:38, 2007년 7월 27일 (UTC)

나는 분류 태스크포스가 알라이의 봇으로 뭔가를 하고 있었다고 생각한다.갈 곳은 아마 태스크포스(TF)의 토크 페이지일 것이다.--Boson 06:14, 2007년 7월 30일 (UTC)

'카테고리:주목할 만한 위키백과 사용자들

대화 페이지 대신 기사 페이지로 이동 가능

토크 페이지를 통해 이 범주를 추가하면 이 범주를 덜 볼 수 있게 하기 위해 어떤 조치가 취해질 수 있다.Vjdchauhan 21:00, 2007년 7월 21일 (UTC)

그것은 보여서는 안 되기 때문에 정확히 대화 페이지에 올려져 있다; 그것은 자기 참조다.크리스토퍼 파럼(토크) 06:12, 2007년 7월 22일 (UTC)

우리는 (정상적인 위키피디아인들에게) 숨길까? 왜냐하면 자기 참조가 있기 때문일까, 아니면 혹시 있을 수 있는 반달 공격에 대해 숨길까?Vjdchauhan 13:00, 2007년 7월 22일 (UTC)

위키백과 참조:설명에 대한 자기 참조를 피하십시오.(그리고 Special:에서 서명을 수정하십시오.클릭할 수 있도록 설정.고마워 :) --Quiddity 01:32, 2007년 7월 25일 (UTC)

우리도 하위 카테고리를 가질 수 있을까?

약 900명의 유명한 위키피디아 사람들이 우리가 직업/국가성에 기초하여 이 범주의 몇 가지 하위 범주를 가질 수 있다.Vjdchauhan 21:00, 2007년 7월 21일 (UTC)

위키백과:위키백과의 선

나는 그것이 더 많이 연결되어야 하고 더 많은 항목이 있어야 한다고 생각하기 때문에 위키피디아를 언급하고 있다.여기 위키백과의 젠.그게 다야. 2007년 7월 24일 13시_{Luc "Somethingorother" French} 59분 (UTC)

아니, 스팸이 아니라 위키 공간에서 기사를 삭제하는 과정을 배울 수 있는 좋은 기회일 뿐이야.위키백과 과정에 대한 지식을 향상시킬 수 있는 기회를 줘서 고마워!GDallimore (Talk) 16:56, 2007년 7월 24일 (UTC)

[5] ([6]에 응답한)에 대한 응답으로, 그렇다.이것은 제안서가 아니므로 이 페이지에 주제와 맞지 않으므로 부적절한 광고다(wikt:스팸 디펜. N1 참조).BigNate37_(T) 16:58, 2007년 7월 24일 (UTC)

내 잘못이다.나는 사과한다.^Thanks, _{Luc "Somethingorother" French} 2007년 7월 24일 17:12 (UTC)

중립성, 사실상의 논쟁 등에 관한 논의에 대한 언급

종종 "중립성 논쟁", "사실적 정확성 논쟁" 등과 같은 배너에 제공된 링크는 당신을 오랜 시간에 걸쳐 논의된 무수한 주제를 다루는 장문의 토크 페이지의 맨 위로 데려간다.어떤 특정한 우려가 현수막을 추가하게 했는지, 그것에 대해 어떤 조치가 취해진 것인지, 그리고 문제가 여전히 존재한다고 인식되는지 여부를 발견하는 것은 종종 어렵거나 불가능하다.이런 일이 일어나지 않도록 나는 이 모든 배너들이 특정 토크 페이지 섹션에 대한 참조를 요구해야 하며, 사람들에게 이를 따르도록 강요하기 위해 배너 하나가 제공되지 않으면 작동하지 말아야 한다고 제안한다.맷 20:55, 2007년 7월 23일 (UTC)

문제는 때때로 중립성에 의문이 제기될 때, 태그의 존재만으로도 다른 행인들이 그 기사가 사실인지 자세히 살펴보기에 충분할 수 있다는 것이다.토크 페이지 코멘트는 문제를 식별하는 데 도움이 될 수 있지만 항상 필요한 것은 아니다.--Kylohk 05:44, 2007년 7월 24일 (UTC)

그것은 전혀 변하지 않을 것이다.사람들은 여전히 그 꼬리표를 볼 것이고, 그것은 여전히 그들에게 경고하기에 충분할 것이고, 그들은 그들이 원한다면 더 자세히 볼 수 있을 것이다.요점은 그들이 기사를 읽으면서 태그가 왜 거기에 있는지 이해하지 못할 수도 있다는 것이다.토크 페이지로 자동 연결되는 것은 도움이 되지 않는 경우가 많다.토크 페이지에는 설명이 전혀 없거나, 아니면 태그가 수개월을 거슬러 올라가는 방대한 토론의 어느 부분을 언급하는지가 불분명하다.나의 제안은 사람들이 태그에 대해 토론하기 위해 특정 섹션을 만들도록 강요할 것이다. 그래서 모든 사람들에게 인식된 문제가 무엇인지, 다른 사람들이 어떻게 생각하는지, 그리고 자신의 의견을 어디에 추가해야 하는지가 명확해질 것이다.이 태그들이 그렇게 오랫동안 돌아다니는 이유의 일부는 인식된 문제가 오래 전에 고쳐졌을지도 모르는 상황에서도 아무도 태그들을 제거하는데 자신감을 갖지 않기 때문이다. 왜냐하면 어떤 일이 일어났는지의 토크 페이지에는 명확한 역사가 없기 때문이다.만약 누군가가 왜 태그를 추가했는지에 대한 짧은 설명을 토크 페이지에 올리지 못한다면, 그들은 태그를 추가하지 말아야 한다.그 설명은 결국 문제를 해결하고 태그를 제거하게 되는 후속 논의의 출발점이 된다.맷 13:14, 2007년 7월 25일 (UTC)

사실, 방금 그 모든 것을 썼으니, 당신이 특정한 링크를 가지고 있지 않은 이미 제자리에 있는 태그의 문제를 언급하고 있을지도 모른다는 생각이 들었다.아마도 나의 "일해서는 안 된다"는 말은 오해를 불러일으켰을 것이다.나는 단지 새로 추가된 태그에 대해서만 언급하고 있었다.즉, 이행 후, 그러한 태그를 추가하는 사람은 누구나 토크 페이지 섹션을 만들어 링크하도록 해야 한다.나는 존재하는 모든 비연계 태그가 갑자기 사라져야 한다고 제안한 것이 아니었다.Matt 13:23, 2007년 7월 25일 (UTC)

웰컴봇

새로운 사용자 대화 페이지에 자동으로 환영 템플릿을 남기는 봇이 있는가?그렇지 않다면, 하나를 만들 수 있을까?그냥 생각 - Phenix15 17:14, 2007년 7월 27일 (UTC)

이는 봇에게 환영받는 사용자가 인간에게 환영받는 것처럼 '개인적'이 아니라는 우려 때문에 과거에도 반대해 왔다.Tra(Talk) 18:02, 2007년 7월 27일(UTC)

하지만 몇몇 환영객들은 새로운 사용자들을 환영한다. 그것은 마치 봇이 메시지를 남기는 것과 같다.신규 등록된 계정만 WP로 자동 리디렉션되는 이유:Welcome? Flyguy649^talk_contribs 18:05, 2007년 7월 27일(UTC)

개인적인 일이 아닐 것이기 때문이다.A.Z. 01:05, 2007년 7월 28일 (UTC)

개인적인 일이 아닐 거라는 건 알지만, 봇이 남긴 환영 메시지조차도 사람의 출입처럼 보이게 만들어질 수 있어.위키피디아의 대부분의 새로운 편집자들은 정말로 차이점을 말할 수 없을 것이고, 그것은 새로운 내용을 쓰는 것과 같은 더 나은 일을 할 수 있는 많은 사람들의 시간을 절약할 수 있을 것이다.봇의 사용자 이름에 '봇'이라는 단어가 없는 한, 우리는 설정될 것이다.크리스치^Talk 14:21, 2007년 7월 28일 (UTC)

또한, 새로운 사용자가 질문이 있다면 봇은 대답하지 않을 것이다.— The Storm Surfer 14:36, 2007년 7월 28일 (UTC)

비인격적이긴 하지만, 그런 봇은 아주 유용할 것 같아...표준 환영 메시지를 보면 두 가지 목표를 달성한다...첫 번째는 새로운 사용자에게 그들이 계정을 만들고 프로젝트에 참여했다는 것을 다른 사람이 알아챘다는 것을 알리는 것이다.새로운 사용자가 프로젝트에 참여하는 것을 기분 좋게 하고 기여하고 싶어하도록 하기 위해서입니다.두 번째는 그들에게 핵심 정책과 가이드라인에 대한 링크를 제공하여 위키피디아들이 어떻게 작동하는지 배울 수 있도록 하는 것이다.두번째로 초점을 맞추고 싶은 부분은...우리의 환영 위원회 자원봉사자들은 훌륭한 (그리고 종종 감사하지 않는) 일을 하지만, 그들은 모든 새로운 사용자들에게 다가가지 못한다.따라서, 우리는 환영받지 못하는 새로운 사용자들이 있다.즉, 핵심 정책에 대한 링크가 제공되지 않는다는 것을 의미한다.봇이 알아서 할 거야환영회를 포기하면 안 될 것 같은데...우리는 봇과 인간 자원 봉사자를 둘 다 가져야 한다.블루보어 15:20, 2007년 7월 28일 (UTC)

나는 핵심 정책과의 연계가 신참자들에게는 중요하지 않다고 생각한다.환영이 가장 중요한 것 같아서 "야, 알아들었어!어서 오십시오!"라고 말하면 충분할 것이다.A.Z. 19:49, 2007년 7월 28일 (UTC)

대부분의 이슈와 마찬가지로, 나는 이 이슈의 양쪽 측면을 모두 본다는 것을 알게 되었다. 그리고 봇을 갖는 것이 어떤 경우에는 도움이 될 수 있다는 것에 동의하지만, 내가 환영 위원회를 유지하기 위해 투표할 이유는 다음과 같다.

나는 개인적으로 어떤 새로운 사용자도 환영하지 않는다.먼저, 나는 그들의 기여를 확인하고, 대화 페이지를 살펴본다.만약 그들이 많은 경고나 CSD 또는 이미지 삭제와 관련된 메모를 받았다면, 나는 그들이 이전에 도움말 정보를 검토하도록 시도했던 것을 무시했다는 것을 보여주기 때문에 내 개인화된 환영을 거절하지 않는 경향이 있다.

나는 이것을 하면서 이러한 많은 새로운 계정들이 페이지 모독/확산만을 목적으로 만들어진다는 것을 알게 되었다(오늘 모튼 페이지에 게시된 정보 참조). 그 구체적인 경우, 온라인에서 기사 하나가 발표되었는데, 특히 이 회원과 밴을 대상으로 하는 명시적인 의도를 가지고 계정을 만들도록 사람들에게 지시하였다.그의 페이지를 장식하는 것.자, 미안하지만 나는 피해를 입히려는 고독한 의도를 가지고 이곳에 오는 사람들을 환영하지 않을 것이다.;)

또한 RC/VP를 하는 동안 새로운 사용자들이 토크 페이지에서 어떠한 활동도 하지 않았다는 것을 알게 되면 나는 새로운 사용자 페이지에 환영의 말을 전할 것이다.특히 그들이 건설적으로 기여하고 있을 때, 그리고 특히 형식화에 약간의 도움이 필요할 것 같은 경우(예: '표현' 단락 lol).

아마도 가장 중요한 이유일 것이다, 만약 봇이 환영하는 사람들이 질문이 있다면, 그들은 물어볼 사람이 없다.응, 많은 도움말 페이지가 있지만, 개인적인 경험으로 볼 때, 가끔 필요한 한 가지 답을 찾기 위해 헤쳐나가야 할 많은 정보라고 말할 수 있어.

나는 새로운 사용자들의 질문에 환영한 후 빠르게 대답했고, 나는 그것에 대해 큰 자부심을 느낀다.만약 봇이 모든 개인들을 환영하며 돌아다닌다면, 지역사회에서 많은 것을 필요로 할 것이다.환영 위원회의 사람들은 그것을 하는 것을 매우 기뻐하는 것 같다. 그리고 나는 모든 사람들 사이에 그들이 기여하는 새 회원들의 좋은 과반수를 얻기를 바란다.개인적으로 나는 꽤 고독한 삶을 살고 있고, 적어도 대리적으로는 새로운 사용자들을 맞이하는 것이 현실에서는 할 수 없는 웃음을 퍼뜨리고 있다는 것을 느낀다.그리고 나에게 새로운 메시지가 있다고 말하는 오렌지 박스를 받는 것보다 더 즐거운 것은 없어! 2007년 7월 28일 (UTC) 15:34

이 제안의 또 다른 단점은 디폴트 템플릿이 솔직히 불충분하다는 것이다.그것은 너무 적은 수의 유용한 링크를 제공하며 새로운 사용자에게 충분히 시각적으로 흥미롭지 않다.나는 나만의 템플릿을 사용한다. 왜냐하면 어떤 출판된 사용자 정의 디자인도 나에게 적합하지 않기 때문이다. 하지만 만약 당신이 봇이 사용할 더 좋은 템플릿을 원한다면, 나는 누구의 템플릿을 선택해야 하는지에 대한 논쟁을 예상할 수 있다.그러나 ArielGold에 의해 언급된 또 다른 단점은 봇은 초기 편집 내용을 보고 새로운 편집자의 본질을 추정할 수 없다는 것이다; 인간은 할 수 있다. 그리고 나는 그들에게 더 많은 정보를 주는 것은 실제로 역효과를 낼 수 있기 때문에 분명히 비파괴적인 편집만 한 사람을 환영하지 않는 것을 선호한다.스팸 발송, 공공 기물 파손, 또는 기타 나쁜 행동만을 목적으로 가입하는 사람들은 사람의 눈에 아주 빨리 명백해지는 경향이 있다.Adrian M. H. 21:33, 2007년 7월 28일 (UTC)

비인격적이기 때문에 반대하지 않을 것이다(대부분의 사용자들은 템플릿을 사용하는 사람들을 환영하기 때문에 실질적인 차이는 없다).도움말을 사용하면 도움말 페이지에 대한 링크만으로도 충분하다.그러나 나는 공공 기물 파손자들에게 경고를 해서는 안 된다는 위의 지적에 동의한다.그러므로 나는 지금으로서는 봇을 반대할 것이다.반복 꿈 2007년 7월 29일 11시 56분 (UTC)

다소 불쾌하기는 하지만, 각 봇 포스트가 "웰컴봇"으로 서명하기 보다는 새로운 사용자가 도움이 필요하면 도움을 줄 수 있는 유용한 사용자(즉, 환영자가 자신을 추가할 수 있는 목록에서 무작위로)를 반환하는 것이 가치 있을 수 있다.환영회 자체는 다소 건조하다 - 내 생각에, 많은 신입생들이 실제로 그것을 다 읽지는 않는 것 같다.니힐트레스^(t.l) 14:05, 2007년 7월 29일 (UTC)

좋은 생각이야, 니힐트레스, 만약 환영하는 봇의 메시지에 질문을 위해 그들을 참조하기 위해 라이브 유저(자원봉사자 명단에서 뽑은)와의 링크가 포함된다면, 그것은 큰 차이를 만들 것이다.하지만, 나는 개인적으로 환영 위원회를 여전히 좋아하고, 만약 그것이 봇 환영으로 해결되었다면 나는 슬플 것이다.^Ariel♥Gold 2007년 7월 29일 14:23 (UTC)

• 사실 대부분의 새로운 사용자들은 그렇지 않기 때문에 봇은 그들에게 꽤 무의미할 것이라는 것을 기억하라.>Radiant< 12:11, 2007년 8월 2일 (UTC)

외부 링크

이 마을 펌프는 지금 내게는 다소 생소하니, 이 문제가 길게 논의되었다면, 내 가는 길에 얼마든지 나를 보내주시오!외부 링크를 새 브라우저/탭에서 열 수 있는가?어떤 이유에서인지, 기사를 숙독하고, AfD의 기사를 위한 내용을 보고, 일반적인 편집 목적을 할 때, 나는 이것이 가치가 있다고 생각한다.'우클릭' 기법은 개의치 않지만, 모든 유형의 사용자(단순히 읽고 편집하고 있든)를 당면한 업무에서 유지하는 것에 따라, 위키백과 고유의 영역 내에 유지하는 것만큼 유리하다고 생각할 것이다.내가 그냥 게으른가? (답답하지 마.) 07:06, 2007년 7월 22일 (UTC)

방금 쓴 사용자 스크립트를 사용해 보십시오.

addOnloadHook(function() {     var alinks = document.getElementsByTagName("a");     var tablink;     for (var i = 0, leng = alinks.length; i < leng; i++) {         tablink = alinks[i];         if (/\bexternal\b/.test(tablink.className) && tablink.href.indexOf("http://en.wikipedia.org") != 0)             tablink.target = "_tab";     } });

"외부" 링크가 en으로 향하지 않는 한, 외부 링크를 새 탭에서 여십시오.wikipedia.org.그것은 파이어폭스에서 작동된다.Gracenotes^T § 07:45, 2007년 7월 22일 (UTC)

Firefox에서는 마우스 가운데 버튼을 사용하여 새 탭의 링크를 열 수 있다.해리보일스 08:34, 2007년 7월 22일 (UTC)

멋진 제안이야, 대본을 써봐야 하니까.나는 중간 버튼을 그렇게 사용하고 싶지만, 윈도우 익스플로러를 열도록 배정받았다. 말하자면, 나는 C 드라이브 나치이기 때문이다.2007년 7월 22일 08:58(UTC) 이하^talk

Firefox에서 컨트롤 클릭으로 새 탭을 열고 shift 클릭으로 새 창을 여십시오.λυΔαcγ 02: 02:11, 2007년 7월 23일 (UTC)

Gracenotes에게 감사드리며, 여러분의 대본은 안정적이고 일관성 있게 작동하며, 이것은 내가 얼마 전에 다른 사람에게 빌린 것과 동등한 것에 비해 상당히 향상된다.Adrian M. H. 19:40, 2007년 7월 23일 (UTC)

훌륭해 - 이 스크립트를 만들어 준 Gracenotes 덕분에. --Ckatz^chat_spy 20:02, 2007년 7월 23일 (UTC)

천만에요.(그런데, 레게센을 싫어하는 사람이 있다면,/\bexternal\b/.test(tablink.className)으로 대체될 수 있다.tablink.className.indexOf("external") != -1 .) Gracenotes§ 01^T:49, 2007년 7월 25일 (UTC)

이미 많은 사람들이 지적했듯이, Firefox와 IE에서 컨트롤+클릭 또는 마우스 가운데 버튼을 누르면 새로운 탭으로 링크가 열린다.GBeneme 04:25, 2007년 7월 27일(UTC)

사용자 페이지 반달리즘

나는 새로운 위키피디아 전문가로, 내 사용자 페이지를 파괴한 적이 없지만, 동료 기고자의 몇몇은 "이 사용자 페이지는 X번 파괴되었다."

전에도 여러 번 제안받았지만, FAQ에서 찾을 수 없었어.사용자 페이지를 소유하는 사용자만이 페이지를 편집할 수 있도록 만들 것을 제안한다(물론 관리자도).

이렇게 하면, 사용자 페이지의 소유자만 편집할 수 있고, 물론 다른 구성원은 자신의 토크 페이지를 편집할 수 있지만, 이것은 사용자 페이지 vadalism을 막을 수 있다.

이것은 데이터베이스를 다시 만들고, 모든 페이지에 새로운 코드를 추가하는 거대한 작업처럼 보일지 모르지만, 나는 그것이 꽤 간단하게 이루어질 수 있다고 믿는다.

위키피디아가 페이지를 어떻게 코드화할지는 잘 모르지만, 맨 위 프레임에 있는 이와 같은 것이 다음과 같은 요령을 할 것이라고 믿는다.

<?php

if page.title = "'User:', +, 'current.user'"

then

display.true "Edit This Page" link (<- not sure about this but because I don't know the workings of this particular section)

else;

display.false "Edit This Page" link (<- once again not sure about this but because I don't know the workings of this particular section)

?>

분명히 이것은 정확한 코드는 아닐 것이다. 왜냐하면 나는 php에 "전문가"가 아니기 때문이다. 그리고 나는 이것이 단지 "이 페이지 편집" 버튼만 숨길 뿐이고, 여전히 (알려진 경우) 공격에 사용할 수 있는 편집 링크를 남길 것이라는 것을 알고 있다. 그러나 나는 여전히 이것이 사용자 페이지 반달리즘의 수를 현저히 줄일 것이고, 그리고 미래 코드로 이어질 수 있다.현재 사용자로 로그인하지 않은 경우 액세스되지 않도록 연결하십시오.

나는 위키피디아에 이 (또는 이와 비슷한) 코드를 위키피디아 자체의 코드로 사용할 수 있는 사용자들이 여럿 있다고 확신한다.

내 아이디어에 대해 코멘트를 하고, 이것이 좋은 제안인지 아닌지, 그리고 전에 제안된 적이 있는지 말해줘.만약 (그것이 가지고 있다고 확신한다) 있다면, 나는 과거에 거부된 것을 제안하고 싶지 않으니까, 그것을 삭제해 주시오.
2007년 7월 23일 Gbenem 19:52 (UTC)

사실상, 당신이 묻고 있는 것은 전체 사용자: 네임스페이스에 반보호(소유자 제외)를 적용해야 하는지 여부다.거의 모든 경우에, 보호는 위키백과가 누구나 편집할 수 있는 백과사전이라는 이상을 퇴색시키기 때문에, 보호는 페이지 단위로 이루어져야 하고 적용되어야 한다.보드에 적용되는 유일한 경우는 미디어위키 네임스페이스(인터페이스의 일부)와 모든 사용자의 모노북.css 및 모노북.js(그리고 다른 스킨의 페이지도 마찬가지)이다.나는 그러한 페이지들이 파손되는 사례가 극히 적다고 확신한다.기술 노트에서 제안하는 솔루션은 편집 링크만 숨긴다.누구든지 페이지를 편집하기 위해 주소 표시줄에 "?action=edit"를 추가할 수 있다.해리보일스 2007년 7월 24일 (UTC)

이것은 이미 사용자의 피부 페이지에 적용되고 있다. 예를 들어, 관리자와 나만이 나의 monobook.js 사용자 하위 페이지를 편집할 수 있고, 나는 관리자로서 다른 사람의 피부 페이지(대개 자신의 피부 페이지를 실수로 카테고리에 삽입한 특정 빠른 삭제 스크립트를 가진 사람에 대해)를 아주 적은 수의 편집 작업을 했다.신속한 삭제를 위한 후보자들은 코멘트 <노위키> 태그를 삽입해야 했다.한편, 실제 사용자 공간의 경우 공공 기물 파손 비율이 충분히 높지 않기 때문에 모든 기물을 자동으로 보호하거나 반보호하는 것이 필요하거나 적절하지 않아 보인다.그나저나, 보호 정책에 따라 누구나 자신의 사용자 페이지를 무한정 반비보호할 수 있으므로, 자신의 사용자 공간에 공공 기물을 파손할 염려가 있는 사람은 누구나 요청만 하면 된다.또한 sysops만이 다른 사용자의 사용자 페이지를 편집할 수 있도록 허용되었다. 사용자 페이지 사이에 스팸 페이지의 발생률이 현저히 높으며, 페이지에 태그를 지정하지 않는 것은 이 스팸의 삭제를 방해하고 실제로 더 많은 관리 백로그를 만들 수 있다.동기부여는 이해하지만, 그런 제도는 실전에 유용하거나 이론상으로는 바람직하지 않을 것 같다.니힐트레스^(t.l) 14:08, 2007년 7월 24일 (UTC)

Harryboyles와 Nihiltres를 생각해줘서 고마워.Harryboyles, 나는 내 제안서에서 이것은 편집 태그만 숨길 것이라고 지적했고, 나는 또한 이것이 /w/index.php?title=xxx&action=edit에 대한 접근을 거부하도록 더 발전될 수 있다고 제안했다.하지만 대부분의 스팸 발송자들은 빠른 해결책을 찾을 것이고, 그 모든 것을 겪는데 방해받지 않을 것이다.당신(해리보일스)도 "보호라는 것은 위키백과가 누구나 편집할 수 있는 백과사전이라는 이상을 퇴색시킨다"고 말했고, 이것이 사실이지만(그리고 위키백과 창간 정책의 근본적인 부분이기도 하지만, 나는 "위키피디아는 누구나 편집할 수 있는 백과사전"이라고 지적하고 싶다.따라서 {{userpage}}의 템플릿 "이 페이지는 백과사전 기사가 아니므로 누구나 정책을 편집할 수 있는 것이 면제된다.요청 페이지 보호에 관한 한, 이것은 더 길어질 것이고, 당신이 말했듯이, 사용자 네임스페이스의 시스템 전체 페이지 보호가 아니라 페이지 단위로 수행되는 더 많은 백로그를 만들 것이다.물론 단순한 php 코드보다 mroe가 필요하겠지만, 나는 여전히 어떤 형태의 보편적 보호가 필요하다고 생각한다.또한, 보호 페이지 요청은 보호가 필요하다는 증거를 요구해야 한다고 생각하는데, 이전에 파손된 적이 없지만, 경험을 갖고 싶지 않다면 페이지 보호를 요청할 수 없다.GBenemy 21:45, 2007년 7월 26일 (UTC)