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

실행 취소 버튼의 문제

당신은 반달들이 그들의 일을 분할해서 한다는 것을 알아챘을지도 모른다.; 그들은 기사를 한 번에 원하는 대로 편집하는 대신, 그들은 몇 번 연속으로 편집한다.이것은 그들이 엉성하기 때문일 수도 있고, 기사를 더럽히기 위해 다른 생각을 떠올리기 때문일 수도 있고, 섹션별로 편집하기 때문일 수도 있다.아니면 그들은 위키피디아가 어떻게 작동하는지 이해하지 못하기 때문일 수도 있다.혹은 그 반대일 수도 있다: 그들은 위키피디아가 어떻게 작동하는지 알기 때문에 그렇게 한다.

만약 반달족이 부분 편집한다면, 그것들은 거의 "undo" 버튼을 쓸모없게 만든다.가장 최근 편집을 취소하면 다른 손상된 페이지로 돌아가기만 하면 된다.그리고 가장 최근의 편집은 취소할 수 없다.유일한 옵션은 기록을 클릭한 다음 버전을 선택하고 편집을 클릭한 다음 저장을 클릭하는 더 서투른 방법뿐입니다.

반달족이 연달아 편집한 내용을 모두 되돌릴 수 있도록 만들면 어떨까?예를 들어, 반달 A가 B페이지를 파괴한다고 하자.담당 사용자 C는 편집한 내용을 되돌린다.그래서 반달은 또 하는데 이번에는 두 걸음으로 한다.힘든 길을 택하기 전에 C가 첫 번째 편집을 되돌린 후 A가 만든 첫 번째 편집에서 "undo"를 클릭하기만 하면 된다.

더 쉬웠지, 그렇지?-링크 (대화) 2008년 6월 6일 (UTC) 19:26 [응답]

이미 그렇게 하는 방법, 되돌리는 방법, 또는, 그렇게 할 권리가 있다면, 롤백하는 방법이 있는데, 둘 다 당신이 제안하는 대로 한다.--Jac16888 (대화) 19:32, 2008년 6월 6일 (UTC)[응답]

Twinkle . --—— Gadget850 (Ed) - 23:04, 2008년 6월 6일 (UTC)[응답]

일련의 반달리즘 편집이 시작된 이후 건설적인 편집이 없었으면 최신의 좋은 기사를 클릭해 전체 기사를 편집(변경하지는 않지만)한 후 저장할 수 있다.나는 이것이 권장 해결책이라고 믿는다. --A Knight Who Says Ni (토크) 17:38, 2008년 6월 7일 (UTC)[응답하라]

네비게이션 팝업은 또한 당신이 과거 개정판의 링크 위를 맴돌면서 되돌리기를 클릭함으로써 당신이 이것을 할 수 있게 해준다.╟-TreasuryTag (대화 talk 기여)-17:39, 2008년 6월 7일 (UTC)[응답]

특수 문제:접두사 색인

현재, Special:접두사 색인은 지정한 페이지의 하위 페이지인지 여부에 관계없이 입력하는 텍스트로 시작하는 페이지를 표시한다.예를 들어, Special(특수)으로 이동할 경우:접두사 색인/사용자:Anon, 이는 User를 지정하는 것과 동일하다.Anon(더 이상 존재하지 않음)으로 시작하는 사용자 페이지가 표시됨:"Anon"과 같은 사용자:아논! 그리고 내 것, 사용자:아논126번길이것은 지정된 페이지의 하위 페이지만 표시하도록 변경되어야 한다고 생각한다.Anon126 (토크 - commons - commons talk - commons talk - commons 기여) —2008년 6월 7일 05:41, (UTC)[reply]에 코멘트가 추가되었다.

그것은 항상 이런 일을 해 왔다.입력하는 텍스트로 시작하는 페이지를 표시하기만 하면 된다. 하위 페이지로 제한하면 특수:접두사 색인/목록: "List of"로 시작하는 모든 페이지를 보려면 -- Gurch (talk) 05:50, 2008년 6월 7일 (UTC)[reply]

하위 페이지만 원하는 경우 쿼리에 /를 추가하십시오.대수학자 10:01, 2008년 6월 7일 (UTC)[응답]

'다른 언어의 이 페이지'에 추가

이 사이트는 주제를 찾을 때 왼쪽 하단에 기사가 가능한 다른 언어가 있는 상자를 보여준다.만약 당신이 얻을 수 있는 모든 정보를 찾고 있고, 당신은 다국어를 읽을 수 있다(예를 들어, 나는 고등학교에서 영어, 독일어, 그리고 프랑스어를 배웠고, 따라서 대부분의 유럽 언어를 읽는 데 거의 어려움이 없다)라고 한다면, 만약 앞서 말한 박스가 기사의 크기를 보여준다면 유용할 것이다.간단한 예:나는 독일어 시셰히츠디엔스트에 대한 정보를 찾고 있다.나는 먼저 네덜란드 기사를 읽고 다른 언어의 기사가 더 많은 정보를 담고 있는지 궁금하다.상자에는 다음과 같은 기사가 나열되어 있다.네덜란드어 - 200단어, 독일어 - 300단어, 영어 - 100단어,

--Max, 81.69.110.161 (대화) 23:56, 2008년 6월 7일 (UTC)[응답]

단어 수는 위키텍스트와 템플릿의 복잡성 때문에 어려울 것이다. 그러나 WP와 같은 것:인터위키 링크용 POPUPS(인터위키에 대해 팝업이 아직 작동하지 않는 경우)는 사용자 스크립트에 대한 흥미로운 아이디어일 수 있다.Mr.Z-man 03:51, 2008년 6월 8일 (UTC)[응답]

새로운 조항 작성 "보유 지역".

그냥 모든 사람이 기사를 추가하게 하는 대신에, 사용자 공간에서 새로운 기사가 자동으로 만들어지는 과정이 존재하는 것은 어떨까?편집자는 그 후, 제한된 시간 동안 그들의 여가 시간에 창작 과정을 시작할 수 있다.새로운 기사가 원저 편집자들의 마음에 들도록 만들어진 후, 그는 그 기사를 그의 동료들이 볼 수 있는 "아기 기사" 로그로 보내도록 선택할 수 있다.이 시점에서 새로운 기사는 여전히 "발행"되지 않고 있지만, 불확실한 영역에서는 야생에 공개될 새로운 기사의 준비성에 대해 의견이 일치할 수 있다.검토자는 또한 현재 프로세스에 따라 변경사항을 제안할 수 있다(또는 직접 변경).

이 새로운 기사 작성 방법은 현재의 적대감과 관리자들의 "손상 통제"에 대한 필요를 상당 부분 제거하는 동시에 새로운 기사들을 성장시키고 대중들에게 유용하게 사용할 수 있는 기회를 줄 것이다.사전 결정되고 문서화된 시간이 끝날 때(모든 새로운 기사의 맨 위에 제공) 기사가 "유지"에 대한 긍정적인 합의를 얻지 못할 경우, 기사는 원본 작성자에게 자동으로 이메일로 전송되는 사본과 함께 데이터베이스에서 제거된다.모두가 이긴다!좋은 생각인 것 같은데, 너는 어때?Snottythetroll (talk) 07:28, 2008년 6월 2일 (UTC)[응답하라]

이론적으로는 좋지만, 실제론 효과가 없는 것 같아.이 계획은 위키피디아와 매우 흡사하다.창작물.내가 들은 대로, 그것은 여전히 자라고 있는 엄청난 밀림을 가지고 있다.이런 종류의 검토 메커니즘의 문제는 창작자의 수가 리뷰의 수를 훨씬 능가한다는 것이다.프리필터링 제도와는 달리 사후필터링 제도가 유일한 선택인 것 같다. -- 타쿠(토크) 09:41, 2008년 6월 2일 (UTC)[응답]

나는 대부분의 노련한 편집자들이 사용자 공간에서 기사를 개발하고 준비가 되면 기사공간으로 옮겼다고 생각한다.아마도 기사 마법사는 새로운 편집자들을 위해 개발되고 홍보되어야 할 것이다.완벽하지는 않지만, 아마도 많은 새로운 기사들보다 나을 것이다. ---- Gadget850 (Ed) - 2008년 6월 4일 (UTC)[응답]

게다가, 그것은 한 기사가 "알 수 없는" 것인지 아닌지에 대해 완전히 새로운 종류의 변호사들을 만들어 낼 것이다. 그 끝없는 논쟁의 각 당사자들은 죽이거나 방어하기 위해 매처럼 밖을 내다보고 있다.내 생각에 Wikipedia는 이미 토크 페이지 버저드가 기사를 콕콕 찌르고 불평하는 것에 충분히 큰 문제를 가지고 있는 것 같다.시베리오S (대화) 08:19, 2008년 6월 9일 (UTC)[응답]

diff 및 이전 버전의 페이지를 위한 새로운 네임스페이스/인터위키 링크.

이전에 이것을 제안한 사람이 있는지 모르겠다(그리고 그것이 좋은 제안이라면 모든 위키미디어 프로젝트에 적용되려면 메타에 가야 하는데, 사실 미디어위키에 통합하는 것은 어떨까?) 그러나 나는 이것이 모든 위키미디어 프로젝트에 훌륭한 아이디어가 될 것이라고 생각한다.

위키백과 관련 토론을 둘러보면, 위키백과 자체의 일부인 이전 버전의 페이지와 연결되는 일종의 외부 링크를 항상 볼 수 있다.제 개인적인 생각으로는 위키백과 그 자체로 연결하기 위해 외부 링크를 이용하는 것이훨씬 더 부드러워져야 한다.

그래서 나는 외부적인 연결 대신에 새로운 네임스페이스를 만들 것을 제안한다(또는 더 정확히 말하면, diff:, prev: 또는 편집:, 나는 까다롭지 않다) 그리고 diff로 링크할 때 우리는 그 네임스페이스와 페이지 ID를 대신 사용한다.지금 많은 사람들이 컴퓨터 머리를 긁고 있을지도 모르니까 어떻게 작동하는지 설명하려고 노력할 거야.

참고: 이 모든 과정에서 네임스페이스/리디렉트(redirect)를 사용할 것이며, 이는 여러분이 가장 좋다고 생각하는 것을 대신할 수 있다.

좋아, X가 자신이 만든 페이지의 이전 버전을 누군가에게 보여주고 싶다고 해, 그는

1. http://en.wikipedia.org/w/index.php?oldid=3432489을 타이핑하여 그 밖에 몇 개의 [와 ]를 밀어넣어 그의 친구에게 주거나
2. 간단히 (또는 복사/복사) [[192:3432489] 또는 [182:3432489 링크 이름]]을 입력하십시오.그렇게 되면 위키백과 주소를 모두 입력할 필요 없이 문제의 이전 페이지로 직접 연결될 수 있을 것이다.그것은 심지어 메타 프로젝트[m:diff:3432489]와 같은 교차 프로젝트도 할 수 있다.

이 정도면 한 아이디로 충분하지만, 만약 당신이 (디프) 퓨즈를 비교하고 싶다면?글쎄, 나도 그것에 대한 생각을 해봤어.당신이 할 일은 [[diff:왼쪽 열 ID-오른쪽 열 ID] 같은 것, 나는 어떤 기호가 왼쪽 열 ID와 오른쪽 열 ID를 구분하는지 별로 신경쓰지 않는다.그리고 문제의 diff/oldid의 URL을 복사/붙여넣기만 하는 사용자를 돕기 위해 이전 페이지 제목(이 경우 "Math rock")에 "Math rock(diff:3432489)" 또는 "Math rock(diff:왼쪽 열 id-오른쪽 열 ID)"를 비교하는 경우.

이제 사람들이 왜 이런게 필요한가? 라고 말할 것 같은 느낌이 들어. 음, 몇 가지 이유를 생각해 봤는데,

1. 검색 엔진이 위키피디아에 와서 페이지를 색인화하려고 할 때, 만약 그들이 외부 링크를 발견하면 그들은 로봇과 부딪히게 된다.txt NOWARCH 태그(로봇이 해당 링크에 들어가 파일을 체크아웃하지 않는다는 의미) 및;
2. 내 생각에는, 우리가 내부적으로 사용하는 다른 어떤 것과 링크할 때 [페이지], [2] 태그가 디팩토 디프트 링크 시스템으로 채택되었을 때, 그들은 다른 모든 내부 링크가 따르는 규칙을 따라야 한다.
3. 그것은 같은 페이지에 많은 링크를 나열할 때 혼란을 줄인다.

adition To proposal: diff 액세스 링크를 index.php 파라멘터(예: /w/index.php?oldid=344&diff=45354)에서 위키 공간(예: /wiki/diff:344-45354)으로 이동 가능. Atndall93 talk 01:12, 2008년 6월 8일 (UTC)[응답]

네가 원하는 대로 얼마든지 변화시켜라. 나는 개선을 받아들일 용의가 있다.들어주셔서 감사합니다.행복한 편집! Atndall93 talk 05:38, 2008년 6월 7일 (UTC)[응답]

1. 디프와 노이드들은 링크에 로봇의 노 팔로우 속성이 있는지 여부에 관계없이 이미 의도적으로 검색 엔진 결과에서 제외되었다./w/ 및 페이지의 메타 태그로 모든 것을 차단하는 txt.
2. 링크의 형태와 상관없이 당신은 여전히 끔찍한 구식물이 들어 있는 것을 복사해서 붙여넣어야 할 것이다.나는 diff 페이지에 복사를 위해 표시될 수 있는 코드인 oldid 매개 변수를 작동하는 URL로 확장하는 템플릿에는 반대하지 않지만, 이 페이지의 추가 팽도는 편집상자 팽창을 줄일 가치가 없을 수도 있다.

그건 내 의견이야.빅블루피쉬 (토크) 15:47, 2008년 6월 7일 (UTC)[응답]

아이디어는 깔끔하지만, 구현에서는 이것이 까다로울 수 있다. 중요한 것은 디프 ID일 뿐만 아니라 구식이고, 항상 특별한 경우가 있기 때문이다.예를 들어,, 반면에diff=prev& oldid=5 개정 5및 수정 9시 사이에 차이점을 보여 주고 있고, oldid=5 그런데 우리가 어떻게 구문 considerin을 통합할지 확신이 없습니다 개정 5와 그 페이지(로 개정 아이디 같은 페이지에 연속적이지는 않)에 대한 이전 개정의 diff=next에 대해서도 비슷한 차이를 가지고 차이점을 보여 주고 있diff=9&.g들변수들 또한.니힐트레스^{t.l} 16:38, 2008년 6월 7일 (UTC)[응답]

내 아이디어 diff=9&oldid=5는 [diff:5-9]와 diff=prev&oldid=5는 [diff:prev-5]와 같은 것이 될 것이다. Atndall93 talk 01:12, 2008년 6월 8일 (UTC)[응답]

속기는 {{diff}}로 되어 있는 것으로 나타났다.검색 엔진 인덱싱이 구식인 경우 URL을 변경할 이유가 없으므로 diff 페이지의 diff 템플릿에 대해 미리 구성된 코드가 수요가 있을 경우 유용할 수 있다.BigBlueFish (대화) 17:41, 2008년 6월 7일 (UTC)[응답]

그 템플릿은 좀 엉뚱하긴 하지만 여전히 (플레인링크 클래스와의) 외부 링크를 사용하고 있다. Atndall93 talk 01:12, 2008년 6월 8일 (UTC)[응답]

나는 이것을 어떻게 해야 하는지에 대한 기술적인 세부사항에 대해 어떠한 조언도 가지고 있지 않지만, 나는 어떤 조치가 취해져야 한다는 것에 동의한다.현재 URL 전체를 입력하는 시스템은 어색하며, 위첨자 대신 인라인 인용문을 사용하여 디프피를 지적하고 싶다. --A Knight Who Say Ni (토크) 17:50, 2008년 6월 7일 (UTC)[응답]

• 이론상으로는 좋은 생각인 것 같지만, 네임스페이스 페이지는 결코 언급되지 않는 거대한 확산의 쓰레기통을 만들어낼 것이다.내 생각에 우리는 지금까지 총 편집 건수가 5천만에서 6천만 건 정도 될 것 같아.이 중 몇 개가 언급될 것 같으십니까? -- 익명의^Talk 반체제 인사 18:06, 2008년 6월 7일 (UTC)[응답하라]

  "namespace"라는 단어는 혼란스럽다 - 제안자는 우리가 구글 검색을 위한 특별한 인터위키를 가지고 있는 많은 방법으로 위키백과 디퓨즈와 연결될 전문 인터위키의 선상에서 더 많은 것을 제안하고 있다.{{Nihiltres talk log}}}{18:58, 2008년 6월 7일 (UTC)[응답]

  그래, 실제로 페이지를 만들지는 않겠지만 그렇게 보일 거야.

겉보기에는 좋지만 빅블루피쉬가 좋은 지적을 한다.어느 것이 더 쉬울까?URL을 복사하여 붙여넣거나 인터위키를 사용하면 oldid와 diff oldid를 별도로 복사하시겠습니까?diff URL은 또한 보통 페이지 제목의 컨텍스트를 가지고 있다.Mr.Z-man 03:49, 2008년 6월 8일 (UTC)[응답]

나는 제안서에서 제목쇼 "제목(diff/old 페이지용 Wikilink)"을 만들 것을 제안했다. 여기서 괄호 안의 텍스트는 해당 diff 또는 이전 버전의 페이지에 대한 관련 위키링크다.예: (diff:3493-3433)는 노화 3493과 3433을 비교하는 것을 의미한다.따라서 비교 페이지를 볼 때 둘 다 올바른 형식으로 나열되어 있으므로 구식을 별도로 복사/붙여넣을 필요가 없으므로 괄호 안에 나열된 내용을 복사/붙여넣기만 하면 된다(이것은 페이지의 어느 곳에나 배치될 수 있다).예: [1993-3433]을 입력하면 정확한 비교가 된다.그리고 링크의 컨텍스트에 대한 회신에서, 실제 페이지 이름은 관련이 없으며(링크에서 제거하면 링크가 여전히 작동한다), 링크의 이름을 나타내려면 [diff:3493-3433 oldid of random page]라고 말할 수 있는데, 보통 [ ] 타입 링크는 그냥 [3]으로 나타나기 때문에 일반 디프와 같은 수준의 컨텍스트를 가질 수 있다.링크 옆에 이름을 입력해야 한다.diff 링크 위를 맴돌 때 페이지 이름과 함께 툴팁이 나타나도록 할 수도 있다. Atndall93 talk 07:32, 2008년 6월 8일 (UTC)[응답]

내 말은, 정상적인 디프를 만들 때, 나는 브래킷을 입력하고 URL을 붙여넣고, 그리고 내가 나타낼 텍스트를 입력하고, 그 다음에 다른 브래킷을 입력한다는 것이다.인터위키형 링크로 하려면 괄호 2개를 입력한 다음 URL에 "diff:"를 붙여넣고 필요 없는 부분을 모두 삭제하고 하이픈을 추가한 다음 파이프와 텍스트를 표시해야 한다.그것은 최소한의 이익을 위해 많은 추가 작업으로 보인다.문맥상 페이지 제목이 의미하는 바는 링크 위를 맴돌 때 브라우저의 상태 표시줄에 대상의 전체 URL이 표시된다는 것이었습니다.이것이 구디드와 관련된 제목을 찾아 구문 분석할 때 링크에 추가하지 않는 한, 내가 볼 수 있는 것은 http://en.wikipedia.org/w/index.php?oldid=12345&diff=23456뿐이다.미스터 지맨 2008년 6월 8일 (UTC) 16:26 (응답)

내 제안으로는 URL을 전혀 복사하지 않고 제목에 "페이지 제목(diff:whatever)"이라고 쓰여있기 때문에 대괄호 안에 있는 텍스트를 복사하고 휙 둘러보는 대신 제목에 "페이지 제목([diff:whatever]"라고 표기할 수 있기 때문에 실제로 당신이 해야 할 일은 (첫 번째 프로와 함께) 파이프를 치는 것뿐입니다.그 주위에 양수를 더하다.나는 파서가 도구 설명에 "페이지 이름(diff:whything)"과 같은 것을 표시하도록 설정하여 문맥을 유지하도록 권고하고 싶다.그래서 내 제안으로 너는 단지 두 글자만 더 추가하면 된다 (추가 [와 ]) 그리고 그 URL을 붙이는 것에서 약 100자를 제거하면 된다. Atndall93 talk 03:16, 2008년 6월 9일 (UTC)[응답]

제목이 사실 내가 가지고 있는 주요 이슈는 아니다.넌 아직도 어딘가에서 두 늙은이를 데려와야 해.메모리에서 타이핑하거나, URL에서 복사해서 붙여넣거나, 전체 URL을 복사해서 붙여넣어야 하고, 구식만 빼고 모두 제거해야 하는데, 이 모든 것들이 URL을 복사하고 붙여넣기만 하면 된다. 단 한가지 이점이 있다면, 편집 페이지가 조금 더 깨끗해진다는 것 뿐이라면, 나는 이것이 얼마나 추가 작업이 필요한지 정말 모르겠다.d. Mr.Z-man 05:41, 2008년 6월 9일 (UTC)[응답]

음, 내가 말하려고 하는 것을 네가 이해하지 못하는 것 같은데, 괜찮아, 난 가끔 말을 잘못해.연결되기 위해 필요한 정확한 형식의 구식(예: diff:342094-3234234)이 페이지 제목에 나열되어 있으므로 URL 대신 해당 내용을 복사하여 붙여넣기만 하면 된다(그 주위에 더블[]만 두 번 넣음).시간이 있으면 애니메이션 같은 것을 본보기로 만들 수 있는지 알아볼게. Atndall93 talk 10:49, 2008년 6월 9일 (UTC)[응답]

따라서 복사/붙여넣는 문자열 길이를 변경하여 편집 상자의 공간을 절약하는 것이 목적인가?어떤 경우, 페이지의 {{diff 메인 페이지 204901573 202506579}} 양식에 코드를 넣는 것은 어떨까?BigBlueFish (대화) 2008년 6월 9일 (UTC) 12:04[응답]

(outdent)그 목적은 편집 상자의 동일한 공간, [[ ] 스타일 링크 사용, 내부 링크의 나머지 부분과 일치하도록 유지하며, 나(및 다른 사람)와 같이 ({diff}}처럼) 외부 링크 사용을 중지하는 것이다.만약 사람들이 변화에 찬성한다면, 내 생각에는 실행하기에 충분히 쉬울 것 같다. Atyndall93 talk 12:23, 2008년 6월 9일 (UTC) 나의 제안은 또한 이전 게시물들을 더 자세히 확인하기 위해 제목에 일종의 프리메이드 디프 링크를 괄호 안에 넣는 것을 포함한다. Atndall93 talk 12:25, 2008년 6월 9일 (UTC)[응답]

SIZE 지침

위키백과 대화에서 제안서를 확인하십시오.문서 크기 지침을 업데이트하기 위한 문서 크기, 특히 문자 수 대신 산업 표준 단어 수를 사용하기 위한 문서 크기.Oakwillow (대화) 18:27, 2008년 6월 8일 (UTC)[응답]

이노베이션

내 이름은 제이 샤이고 나는 위키백과에서 쉽게 할 수 있는 새로운 혁신적인 게임을 공유하고 싶다.나는 이것을 "wikiLINKIA 챌린지" 또는 "wikiLINKIA"라고 부른다.선수에게 특정 기사가 주어지고, 대상 기사가 주어지며, 기사에서 제공된 링크를 사용하여 대상 기사에 도달해야 한다.한 문장에서만 이해하기는 매우 어려워 보일 수 있으므로, 이 예를 들어, 사용자에게 RMS TYTANTYNATION의 기사가 주어지고 그의 목표가 WORLD TRAND CREATION이라고 가정해 보자.그래서 사용자는 RMS 타이타닉이 뉴욕시로 향하는 동안 뉴욕시를 경유하여 그의 목표물을 링크할 수 있으며, 월드 트레이드 센터가 뉴욕 시에 위치해 있기 때문에 마침내 그의 목표물과 연결시킬 수 있다.내가 내 게임의 컨셉을 이미지 위에 대충 붙였으면 좋겠다.이 예는 내 게임을 정당화하기 위한 기본적인 예일 뿐이다.이 게임은 우리가 목표물에 도달하기 위해 클릭하는 최소 링크와 목표물에 대한 최단 링크 경로를 제한할 수 있기 때문에 더 흥미진진할 수 있다.나는 혼자서 이 게임을 해왔고 심지어 내 여동생이 그것을 하도록 훈련시켰고, 그녀는 이 게임이 흥미롭고 흥미진진해서 그녀가 이 게임을 사랑한다고 말한다.나와 내 여동생은 특정한 위키에서 나란히 놀곤 했다.린키아 챌린지와 우리 게임은 5분에서 1주일에 한 번, 최소의 링크 경로를 가진 우승자는 위키일 것이다.린키아 챔피언.그리고 우리는 위키피디아나 BEY가 챔피언으로 불려지는 것에 대해 매우 자랑스러워 할 것이다.한 때 이 게임을 시도해 본 적이 있는 우리 아빠도 이 게임이 확실히 사람의 시야를 예측하는 데 도움이 될 수 있고, 자신의 재치와 연결력을 테스트해 다른 것과 연결시킬 수 있다고 말했다.아아, 나는 이것이 재미있고, 위키백과 기사의 잘 확립된 플랫폼에서 연주될 수 있는 높은 수준의 도전이라고 말하고 싶다.이 게임에 대해 논의할 것이 더 많다.최대한 빨리 비디오 데모를 제출할 수 있도록 노력하겠다.그래서 멤버들 기대 많이 해주시고.—EnSYS에 의해 추가된 서명되지 않은 코멘트 준비 (대화 • 기여) 17:02, 2008년 6월 9일 (UTC)[응답]

위키백과에 온 걸 환영해!위키백과에 관심이 있으시겠죠.위키백과의 6개 학위, 특히 그것이 링크하는 웹사이트 옴니펠라고스.BigBlueFish (대화) 2008년 6월 9일 21:14, (UTC)[응답하라]

??? - 캐리비안~HQ 21:17, 2008년 6월 9일 (UTC)[응답]

나는...싫어...수도...2008년 6월 9일(UTC) 21:43의 공작 월섬[응답]

WikiProject Musicers의 Discography 섹션에 대한 새로운 제안

이 제안을 보고 찬성 또는 반대 의견을 제시하십시오.현재 우리는 디스크그래피 섹션에 대한 가이드라인이 없기 때문에, 적어도 이것은 시작일 것이다.칼다리 (대화) 2008년 6월 9일 (UTC) 18:15 (답변)

리베라베디아

라이베라페디아에 있는 기사와 연결되는 외부 링크 템플릿의 제작을 제안해도 될까?Otolemur crassicaudatus (talk) 18:12, 2008년 6월 8일 (UTC)[응답하라]

그 사이트를 잠깐 살펴본 결과 링크 템플릿을 만들면 별로 이득이 없다고 본다.가리온96(토크) 18:16, 2008년 6월 8일 (UTC)[응답]

비록 그것이 도움이 되긴 하지만, 자유분방한 것은 언사이클로페디아처럼 꼭 장난치는 사이트는 아니다.그것은 실제 정보를 문서화하며, 많은 경우 참고자료로 문서화한다.Otolemur crassicaudatus (talk) 18:20, 2008년 6월 8일 (UTC)[응답하라]

그것은 어떤 기준으로도 믿을 만한 출처가 아니다.만약 편집자들이 적절한 출처를 찾기 위한 연구 도구로 그것을 사용할 수 있다면, 훌륭할 것이다. 하지만 위키피디아는 이 사이트와 연결할 대규모의 필요가 없다.BBC 뉴스와 같이 대규모로 참조된 사이트들도 링크 템플릿을 가지고 있지 않다.BigBlueFish (대화) 2008년 6월 9일 (UTC) 12:27 [응답]

다른 위키피디아 관련 사이트들을 위한 템플릿이 있는가?Corvus cornix_talk 17:01, 2008년 6월 9일 (UTC)[응답]

사실, 좋은 수 많은 수. 범주:외부 링크 템플릿(또는 적어도 주목해야 할 사항인 경우, 나는 기준 2가 일반적으로 우리가 따르는 것이고, 특히 RS가 일반적으로 적용되는 하위 자료의 출처로서 연결되는 사이트와 그러한 사이트를 구분하지 못하는 정도까지 알고 있지 않다.단지 그들의 저명한 사이트, 특히 특정 주제에 대해 언급하는 사이트들을 위해 링크된 사이트들은 우리가 따라야 하는 것이어야 한다) 여기에서 관련될 수 있는 것처럼 외부 링크가 템플릿에 적합한지 여부를 결정하기 위해 커뮤니티가 일반적으로 사용한 기준이다.조 06:45, 2008년 6월 10일 (UTC)[응답]

관리자로 "하위 페이지 이동" 기능 제한

촬영되지 않은 제한된 이미지

비저작권 제한 자료에 대한 토론을 비저작권 콘텐츠 토크 페이지에서 다시 열어보았다.과거에는 이 문제가 나를 심하게 짜증나게 했고, 나는 저작권 관련 자료들이 처리된 후에 우리가 처리하겠다고 들었다.음, 그건 이제 다 끝났고 그래서 나는 이 희귀성을 고칠 때가 왔다고 생각한다.현행 재단 방침에 따르면 이미지와 같은 자료는 '무료 사용'이 필요하지만, 저작권이 없는 자료(상표 로고, 군 휘장, 국기 등)는 많지 않다.이러한 자료에 대해 일반적인 '예외'가 있는 것 같지만, 재단 결의나 우리의 면제 독트린 정책에는 이에 대한 실질적인 근거가 없다.General Reglaimer는 상표에 대해 일반적(당사 기사에 텍스트 상표 포함)을 언급하지만, 나는 이것이 어떻게 재단이 채택한 "자유 문화 작품 정의"에서 정의한 자유 콘텐츠 라이센스에서 이미지를 면제하는지를 모르겠다.내 희망이야, 이번 토론은 우리가 이 문제를 완전히 정리하기 위한 시작일거야. --DJ (대화 • 기여) 11:20, 2008년 6월 10일 (UTC)[응답]

보다 쉬운 Special 액세스:리스트유저

그냥 이걸 놓치고 있는 것일 수도 있지만, 어떤 사용자의 권리도 쉽고 빠르게 확인할 수 있는 방법을 찾고 있다.나는 더 많은 사용자 그룹이 만들어짐에 따라 (Accountcreator, IPexempt...) 이것이 점점 더 필요하다는 것을 알게 되었다. 따라서 내가 상상하는 것은 사용자나 사용자 대화 페이지의 도구 상자에 있는 링크 또는 로그 페이지 상단에 있는 사용자의 목록 사용자 항목일 뿐이다.물론, 이미 쉽게 접근할 수 있는 방법이 있지 않다면 말이지알렉스 뮬러 2008년 6월 10일 (UTC) 11:33[응답]

이것은 모든 사람의 도구 상자에 있어야 한다고 생각하지 않는 한 자바스크립트로 쉽게 할 수 있다.대수학자 11:37, 2008년 6월 10일 (UTC)[응답]

오, 정말?그렇다면, 어떻게 하는지 다른 사람이 공유해도 될까... 내 자바스크립트 푸는 알렉스 뮬러 11:44, 2008년 6월 10일 (UTC) 답장이 아니야.

이것은 당신이 누군가의 사용자 또는 사용자 대화 페이지를 볼 때 그것을 도구 상자에 추가할 것이다.물론 그것을 다른 곳에 추가하는 것은 더 많은 코드를 필요로 할 것이다.

addOnloadHook(기능(){ if (wgCanonicalNamespace[0] != 'U') 반환, t = '사용자 권한'; url = wgScript + '?title=Special:Listusers&limit=1&username=' + wgTitle.replace(/\/)*$/infirment; r = document.createElement('li'); a = document.createElement('a'); a.setAttribute("title", t); a.setAttttribute("href", url); a.innerHTML = t; r.setAttribute('id'), 't-' + t; r.appendChild(a); u = document.getElementById('t-upload'); up.parentNode.insertBefore(r, u); };;

— CharlotteWebb 15:43, 2008년 6월 10일 (UTC)[응답]

샬롯, 정말 고마워. 완벽해. 내가 원하던 바로 그거야...적어도 내게는, 그리고 바라건대 다른 사람들에게도 엄청나게 유용할 겁니다.다시 한 번 알렉스 뮬러, 2008년 6월 10일(UTC) 17:08에 감사한다[응답]

글쎄, 나는 방금 이름에 "&"가 포함된 사용자들에게는 실패할 것이라는 것을 깨달았지만, 나는 그것이 다른 모든 허용 가능한 이름에는 효과가 있을 것이라고 생각한다.또한 나는 이 링크가 항상 존재하기 때문에 그것을 "업로드" 링크 앞에 놓는 것을 선택했다.이 링크를 "블록" 링크(또는 "공여" 링크 등) 위에 올리려고 하면 존재하지 않는 사용자의 페이지에 있는 경우 오류가 발생할 수 있다.이번 대본 이후 다른 대본에 의존해 제대로 로딩해야 눈에 띄는 문제가 될 것 같은데, 마지막 대본의 시작 부분에 추가하면 해결된다.— CharlotteWebb 17:52, 2008년 6월 10일 (UTC)[응답]

아, 하지만 "블록" 버튼이 없고 당신의 버전을 복사하려고 하는 사람은 여전히 실패할 것이다.— CharlotteWebb 17:58, 2008년 6월 10일 (UTC)[응답]

스파르카가 조금 전에 썼던 시솝 검출기가 있어.사용자가 sysop일 때 사용자 페이지 탭을 읽도록(sysop) 변경한다.(sysop에 사용자 페이지가 없는 경우에도)사용자:에서 가져올 수 있음:Splarka/sysopdector.js. --MZMcBride (대화) 18:22, 2008년 6월 10일 (UTC)[응답]

아마도 나는 페이지 역사, 최근 변화, 감시 목록 등에 나타나도록 그것을 크게 눈에 띄는 "반복하지 말라"는 경고로 수정해야 할 것이다.진지하게 한 번은 내 사이트에서 "XMLHttpRequest"로 무언가를 시도했지만 보안 문제로 계속 Firefox에 의해 거부당했다(실제 오류 메시지가 기억나지 않는다).— CharlotteWeb 18:50, 2008년 6월 10일 (UTC)[응답]

단순화(모든 사용자 이름에 사용 가능):

애드온로드 후크(기능을 발휘하다 () {     만일 (wgNamespaceNumber != 2 && wgNamespaceNumber != 3) 돌아오다;  // 사용자 또는 사용자 대화만     시합을 하다 사용자 = wgTitle.갈라지다("/")[0];     시합을 하다 url = wgscript + "?제목=특수:Listusers&limit=1&username=" + 인코드URIComentor(사용자);     addPortletLink("p-tb", url, "사용자 권한", "t-사용자 권한", "에 대한 사용자 그룹 목록 + 사용자); }); 

이 코드는 툴박스 하단에 링크를 추가한다.더 일찍 배치하려면 추가 매개 변수를 에 전달하십시오.addPortletLink() — wikibits.js에서 해당 기능에 대한 의견을 참조하십시오.—일마리 카로넨(토크) 18:29, 2008년 6월 10일 (UTC)[응답]

또는 훨씬 더 간단하다.

가져오기스크립트("사용자:Ilmari Karonen/userrights.js"); 

:-) —일마리 카로넨 (대화) 18:33, 2008년 6월 10일 (UTC)[응답]

아, 더 흔한 케이스에서 잘 될지는 확신할 수 없었네. 그렇게 해서 보기 흉한 레게스 말이야.— CharlotteWeb 18:50, 2008년 6월 10일 (UTC)[응답]

내가 사용하는 또 다른 좋은 스크립트는 사용자:이름이 나타나는 곳마다 sysop 이름을 가볍게 강조 표시하는 Ais523 비 admin/adminrights.js.이것은 당신이 버튼을 클릭해서 그들이 sysop인지 확인하는 단계를 절약해 주기 때문에 좋다.한 번이라도 시도해 볼 것을 권하고 싶다. -- 페누바그 (대화) 03:40, 2008년 6월 11일 (UTC)[응답]

좌표와 연관된 지오태그 아이콘 사용

위키피디아는 현재 GPS 좌표를 표시하기 위해 작은 지구본 아이콘을 사용한다. 예를 들어, 다음과 같다.

http://en.wikipedia.org/wiki/Empire_State_Building

지구본은 다양한 다른 맥락에서 사용되기 때문에 현재 사용되고 있는 지구본은 불분명하고 특정 위치에 있지 않다.지역사회에서 설계되고 무료 지오태그 아이콘은 지오다타를 더 잘 조명하기 위해 특별히 제작되었다.

http://www.geotagicons.com

어떤 형식(데이터, 마이크로포맷, EXIF-GPS 등)을 사용하든 지오태깅에 적합하며, microformats.org 아이콘 페이지에 추가되었다.

http://microformats.org/wiki/icons

프로젝트 웹사이트에 있는 정보는 포괄적이고 자기 설명이 가능하지만, 만약 내가 어떤 질문에 답할 수 있거나 다른 도움이 될 수 있다면 주저하지 말고 연락을 취하십시오.

프로젝트 코디네이터: Bruce McKenzie The Home of the Geotag Icon Project www.geotagicons.com — 85.155.18.18.18(대화) 14:00, 2008년 6월 11일(UTC)[응답]

위키백과로 무엇을 해야 하는가:1년 이상 요청된 물품?

위키백과로이동해야할 경우:2년 이상 요청된 물품?위키피디아와 함께 카테고리로 변환되는 경우:요청하신 물품?완전히 다른 거?모든 코멘트는 위키백과_talk에서 모든 코멘트를 환영한다.조항_requested_for_more_ban_a년#Requested_move.shoy 15:08, 2008년 6월 11일 (UTC)[응답하라]

en.wikipedia.mobi

휴대폰으로 위키피디아에 접속할 경우 로그인 버튼까지 스크롤 다운이 몇 분 정도 걸리고 영상 업로드가 거의 불가능(불가능하지 않다면)에 가깝다.사람들이 더 쉽게 이미지를 올리고 페이지를 편집하고 기사를 읽을 수 있도록 위키피디아의 모바일 버전이 있다면 좋지 않을까?이제 휴대전화 사용자가 단순히 철자 오류만 고친 것이 아니라면(최악의 경우 파괴를 한 것이 아니라면) 휴대폰의 페이지를 편집해야 할 이유가 별로 없을 것이라는 것을 깨달았지만, 아마도 기사에 포함시킬 수 있고, 물론 기사를 읽을 수 있는 이미지를 업로드하기 위한 모바일 버전의 위키피디아가 있다면 정말 좋을 것 같다.이미지를 업로드하는 한, 또 다른 가능한 장소는 짧은 코드를 만들어 핸드폰 사진이 기사에 사용될 수 있도록 사진 메시지로 이미지를 보낼 수 있도록 하는 것이다.나는 이 문제를 해결할 방법을 알고 있다.휴대폰 사진을 이메일 주소로 보낸 다음 컴퓨터에서 업로드하지만, 경험이 많고 선의의 위키피디아 기여자들을 포함한 많은 사람들이 어떻게 해야 할지 모르고 항상 편리한 것은 아니다.GO-PHS-NJROTC 17:37, 2008년 6월 11일 (UTC)[응답]

위키백과 참조:다양한 옵션에 대한 WAP 액세스 권한 및 현재 Talk:기본 페이지#WAP 버전.도움이 될까? -- 퀴디티 (대화) 2008년 6월 11일 (UTC) 19:28[응답]

URL에서 참조 정보의 자동 생성

참고문헌을 제공하는 것은 어떤 편집자의 가장 중요한 업무 중 하나이지만, 새로운 이용자에게도 가장 도전적인 것(내 생각에는) 중의 하나라고 생각한다.템플릿에 대한 기술적 지식이 필요하다.참고문헌 정보의 인용과 수동 입력.그러나 적어도 온라인 참조([대부분의 참조를 구성하고 있을 가능성이 있음])의 경우, 대부분의 주요 뉴스 사이트는 기사(저자, 제목 등)의 다른 섹션에 사용하는 태그와 형식에서 일관성이 있기 때문에 사이트의 URL을 확보한 후에 이 정보를 자동으로 생성하는 것이 가능해야 할 것으로 보인다.따라서 이러한 사이트의 어떤 종류의 데이터베이스를 만들고 URL을 방금 부여한 각주에 모든 올바른 참조 정보를 넣을 수 있는 스크립트를 작성하는 것이 가능해야 한다. 이것이 실제로 실현 가능한 일이며, 이를 달성하는 데 도움이 되는 사람이 있는가?Theshibboleth (talk) 01:48, 2008년 6월 11일 (UTC)[응답하라]

해결책은 아니지만, 오토비브는 ISBNs를 사용하여 멋진 템플릿을 만든다. 그리고 나는 copyurlplus firefox 확장자를 사용하여 url+제목을 클립보드에 복사한다. 이것은 개인 차원에서 부분적으로 적응할 수 있을 것이다.

당신의 제안은 훌륭하게 들리지만, 자동화된 어떤 것이든 작동하려면 좀 더 완전하게 개발된 의미론 웹(또는 수작업으로 만든 대규모 데이터베이스)이 필요할 것 같다.

인용문 템플릿을 뱉어내는 텍스트 입력 양식이 더 닿을 수 있을까? - 퀴디티(토크) 02:02, 2008년 6월 11일 (UTC)[응답]

생각만큼 생각이 안나는지는 모르겠지만...많은 사이트들이 의미론적으로 의미 있는 포맷을 사용하지 않지만, 그들은 여전히 특정한 방식으로 제목, byline 등을 스타일링하고, 스크립트는 그것들을 어떤 종류의 단서로 사용할 수 있다.스크립팅에 대해 거의 아는 바가 없지만 한두 사이트에 대해 이 작업을 수행하는 방법을 알아낼 수 있을 것 같다.적어도 그 단서가 뭔지 알아낼 수 있을 것 같은데...Theshibboleth (대화) 02:10, 2008년 6월 11일 (UTC)[응답하라]

야후를 위해서!뉴스, 제목은 HTML:BODY:DIV ynwrap:DIV yncont:DIV ynbody:DIV ynstory:저자는 지금 ...에 있다.DIV ynstory:DIV ynmain:DIV 스토리 본문:DIV storyhdr:p:SPAN 및 날짜는 ...p:EM이 최근 시간을 정했다.이것은 내가 이것을 기초로 삼고 있는 기사다 - http://news.yahoo.com/s/ap/sudan_plane_crash;_ylt=Ag5praSYT_HOHGzqB4ORgpus0NUE.Theshibboleth (대화) 02:23, 2008년 6월 11일 (UTC)[응답하라]

여러분은 아마 이런 것들을 알고 있을 겁니다. 저널 기사의 경우, 이것은 종종 행해질 수 있다.WP:CITE에서 Tools를 확인하십시오. 나는 Verisimilus의 Google Scholar 검색을 좋아하고, 그것을 꽤 사용한다.또한 Bibtex에서 Wikitext 컨버터로 이동하십시오. 대부분의 저널에서는 인용문을 Bibtext로 내보낼 수 있다.임핀 (t - c) 09:40, 2008년 6월 11일 (UTC)[응답]

나는 조테로를 사용한다.나는 또한 다른 편집자들과 공유하기 위해 내 사용자 공간에서 참고 문헌을 관리한다; 나는 내 라이브러리에서 요청된 사실 확인을 할 수 있다.참고 항목:위키백과:WikiProject 팩트와 참조 확인 및 위키백과:위키프로젝트 자원 교환. --—— Gadget850 (Ed) - 19:13, 2008년 6월 12일 (UTC)[응답]

되돌리기 요청

이것은 내가 WP:3RR로 인해 제기하는 아이디어다.배트맨 비긴스에서 한 IP는 인용 기사에서 추측에 근거한 허위 정보를 추가했고 중복 URL도 추가했다.이것을 삭제하고 편집 요약에서 아주 잘 설명했지만, 그는 그것을 되돌렸을 뿐이고 지금 그 허위 정보는 기사 속에 앉아 다른 정규 편집자가 그것을 취소하기를 기다리고 있다.그래서 나의 제안은 토론에서 누군가가 분명히 응답하지 않을 때 다른 편집자나 관리자에게 무언가를 취소하도록 요청하는 페이지를 제안하는 것이다.알리엔트라벨러 (대화) 2008년 6월 12일 (UTC) 19:27 [응답]

사람들에게 대리인으로 3RR을 우회하도록 권장하는 것은 좋은 생각이 아니다.만약 누군가가 그들의 편집에 대해 토론하기를 거부한다면, 그들은 파괴적인 편집을 위해 차단될 수 있다.전쟁을 되돌리는 것은 아무것도 해결하지 못한다.Mr.Z-man 19:54, 2008년 6월 12일 (UTC)[응답]

나는 네가 언급하는 특별한 논쟁은 어쨌든 해결될 수 있다고 생각한다; 나는 그런 점에서 편집을 했다.그렇지 않으면 나는 사용자:Z맨씨, 토론이 해결하지 못할 많은 반전이 정말로 필요한 경우를 생각할 수 있는 유일한 경우는 반반달리즘 절차로 다루어질 것이다.의견이 다른 편집자들이 이 문제를 논의하는 동안 기사가 잠시 잘못된 버전에 머물러도 괜찮다._{tiny plastic} -- 그레이 나이트 ⊖ 20:11, 2008년 6월 12일 (UTC)[응답]

사용자의 이전 레코드에 있는 데이터베이스: 이러한 항목을 볼 수 있는 페이지

적어도 어떤 사람들의 정신에서 파괴적인 행동에 대한 사람들의 기록을 쉽게 찾을 수 있게 함으로써 투명성을 향상시킬 수 있다고 생각한다.사용자 및 기타 관련 정보에 대한 의견 요청은 더 쉽게 찾을 수 있어야 한다.특별히 검색하는 것 말고도 쉽게 찾을 수 있고 내가 모르는 게 아니라면?이제 검색은 괜찮지만, 약간의 노력과 생각이 필요하며, 포괄적이지는 않다. -- Requests for User <user>에 대한 검색은 Arb 의사 결정 위키티켓 경고와 같은 다른 관련 결과를 내게 주지는 않는다.나는 많은 사람들이 이 생각에 불편해 할 것이라는 것을 알지만, 그것은 최선이다.임핀 (t - c) 10:56, 2008년 6월 7일 (UTC)[응답]

사용자의 토크 페이지와 최근 기고문을 한 번 훑어보는 것이 사용자에 대해 알아야 할 전부다.만약 그들이 방해적으로 행동한다면, 대화 페이지에서 그들의 방해 이력이 분명해질 것이다.그러나, 대부분의 사용자들은 좋고, 나쁜 사용자들은 변할 수 있다(특히 십대 사용자들의 많은 부분을 고려한다).전체적으로 볼 때, 고의적으로 사업을 훼손하려 하지 않는 한, 유저의 성격을 판단하는 데 아무런 장점이 없는데, 이 경우 과거에 어떤 주의를 기울인 적이 있다면 이미 금지해야 한다.빅블루피쉬 (토크) 2008년 6월 7일 (UTC) 15:35, 7 (응답)

사용자 대화 페이지는 이유 내에서 사용해야 한다.그것은 또한 랩 시트로서 읽혀져서는 안 된다.사실 악의적이거나 '나쁜' 사용자는 경고와 통지가 있는 토크 페이지를 가질 수 있지만, 또한 '착한' 또는 '무고한' 사용자도 봇에 의해 도청당하거나(Bob Sagot과 같은 이름의 페이지를 이동하거나 방향을 바꾸거나) 지나치게 활동적인 사용자들과 마주치는 사용자도 동일한 경고로 채워진 토크 페이지를 가질 수 있다.논란이 되는 주제를 가지고 작업하는 사용자들은 종종 의제를 가질 수 있는 사용자들로부터 경고나 통지를 받게 될 것이다.사람들은 항상 일정한 행동 패턴을 확립하기 위해 (주제 공간의 맥락 안에서뿐만 아니라) 구체적인 편집사항을 보아야 한다. --Samuel Pepys (토크) 22:06, 2008년 6월 7일 (UTC)[응답]

또, 신의성실 가정 지침 때문에, 우리는 이와 같은 것에 관해서는 「용서하고 잊어버리는」 시스템을 갖추는 경향이 있다.만약 우리가 모든 사용자들을 위해 "랩시트"를 보관한다면, 사람들은 과거의 사건들을 결코 줄일 수 없을지도 모른다.Mr.Z-man 21:00, 2008년 6월 7일 (UTC)[응답]

이런 반응이 나올 줄 알았는데, 물이 안 들어오는 것 같아.첫째, 사용자 토크 페이지를 보는 것은 사용자 레코드의 대리인으로 승인되어서는 안 된다.중단 통지는 대화 페이지에서 제거할 수 있으며, 이러한 통지는 흔히 언급된 바와 같이 오류로 만들어진다.예를 들어, 나는 최근에 '9/11에 경고'를 받았다. 단지 기사를 소유하고 있다고 생각하는 편집자들이 내 편집이나 그 참고문헌을 주의 깊게 읽지 않았기 때문이다. (그들은 음모론을 인용했다; 그런 것은 없었다.)토크 페이지에서 사용자의 성격을 판단하려는 사람들은 그 접근방법의 문제점을 강하게 상기할 필요가 있다.사용자의 과거 기여도를 보는 것은 끔찍할 정도로 시간이 많이 걸리고 부정확하다; 많은 사용자들은 봇을 이용해 수천 개의 사소한 편집으로 자신을 편집하는데, 이것은 대충 훑어보기가 어렵다.마지막으로, 나는 관리 요청과 코멘트 사용자 요청을 주의 깊게 지켜볼 시간이 없다. 만약 내가 이러한 페이지가 게시된 페이지를 감시할 수 있다면, 그것은 나에게 삶을 훨씬 더 편하게 해줄 것이다.나는 위키피디아가 특정한 기능을 수행하는 집단으로 분리되는 것을 걱정한다: 어떤 집단은 AfD, 어떤 집단은 RfA, ect. 하지만 그런 시스템을 가지고 있을 때는 반드시 가장 관련 있는 사람들로부터 정보를 얻는 것은 아니다.만약 '관리 요청'이나 '코멘트 요청'이 나온다면 즉시 알려주고 싶은 사용자들이 많지만, 현재 상태로는 이 사람들의 토크 페이지를 볼 수 없고, 투자 시간이 없기 때문에 RfA 목록을 보고 싶지도 않다.Igate and comment on. Igate and committee on.그리고 나는 "선의를 인정하라"는 것이 우리가 과거의 무분별한 행동을 잊어야 한다는 것을 의미한다고 생각하지 않는다.물론 그렇다고 가정해봐, 하지만 만약 그것이 테스트되었다면, 사람들은 그것을 쉽게 알아낼 수 있어야 해.책임감이 있어야 한다.지금 우리는 사람들을 줄을 서게 하기 위해 개인 사용자들의 기억력에 의존하는 것 같다. 그리고 나는 그것이 지속가능하다고 생각하지 않는다.임핀 (t - c) 23:57, 2008년 6월 7일 (UTC)[응답]

사용자의 대화 페이지에 사용자의 RFA 또는 RFCU에 대한 언급이 없을 것으로 예상하는 이유는?만약 사용자가 자신의 토크 페이지를 보면서 당신의 가치조차 없을 정도로 충분히 불안정하다면, 솔직히 그 사용자는 스토킹 당하지 않고 편집할 권리가 있다.해당 사용자가 문제에 직면할 경우, 해당 상황을 다루는 사용자는 과거의 RFA와 RFCU 및 사전 경고에 대한 정보를 완벽하게 찾을 수 있으며, 그들이 요청받은 심각성 및/또는 신념에 주의를 기울여야 한다.위키피디아는 이미 선의의 믿음이 더 이상 항상 가정되지 않는 사람들을 감시할 수 있는 통로를 가지고 있다.빅블루피쉬 (토크) 2008년 6월 9일 (UTC) 12:22 [응답]

대화 페이지에서 RfCU를 삭제하지 못하도록 하는 방법은?임핀 (t - c) 09:27, 2008년 6월 11일 (UTC)[응답]

"사용자 토크 페이지는 사용자 레코드의 대리인으로 승인되어서는 안 된다." - 나는 그것이 좋은 일이라고 말한다.최악의 사용자도 상당히 개혁할 수 있다(사용자:시인.대부분의 사용자들은 그들이 새것일 때 몇 번 망친다.왜 우리는 그것에 대한 영구적인 기록을 만들어야 하는가?만약 누군가가 2007년 3월에 편집 전쟁을 했는데, 그것에 대해 차단되지 않았다면, 그것은 지금 어떤 영향을 주어야 하는가?"지금 우리는 사람들이 줄을 서도록 하기 위해 개별 사용자들의 기억력에 의존하는 것 같다." - 당신은 WP를 꼭 읽어야 한다.모든 사용자가 "줄 서 있는" 상태가 되어야 한다고 생각하는 경우 AGFRFC/U 및 RFA를 모니터링할 수 있는 페이지를 원하지만 WP:RFC/U 또는 WP:RFA?그건 그냥 바보 같은 짓이야.Mr.Z-man 15:53, 2008년 6월 13일 (UTC)[응답]

대부분의 장기적 문제 사용자들은 단순히 경고문을 작성하지 않고, 정책은 그것을 수용하는 것처럼 보인다.그러나 나는 일부 사용자들이 과거에 17번이나 인신공격에 대해 경고를 받았다는 기록을 가지고 있다는 이점이 있다고 본다. 그리고 토크 페이지는 단지 그것처럼 기능을 제공하지 않는다. 2008년 6월 13일 (UTC)[응답하라]

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

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

합리적인 것 같지만...이것은 한 페이지에 할 수 있을까?2008년 6월 7일 (UTC) 20:13, 월텀 공작 (Walthaltham, The Duke of 20:13, The Duke of 2008 (UTC)

__NEWSectionLINK__이(가) 있는 모든 토크 페이지와 페이지에 대해 해보는 것은 어떨까?– FISDOF9 23:54, 2008년 6월 7일(UTC)[응답]

그거 좋은 생각인 것 같아.우리가 여기서 충분한 관심을 받지 못한 것 같아 안타깝다.난 거의 일주일 동안 이 일을 잊고 있었어...바보 펌프.2008년 6월 14일 00:30(UTC)의 공작 월텀(Walthaltham, The Duke of 00:30 (UTC)

마스코트

나는 위키피디아가 마스코트를 가져야 한다고 제안한다.Wikipe-tan.TookieGriffin! • Talk Sign 17:51, 2008년 6월 12일 (UTC)[응답]

위키백과:마스코트. 공식 마스코트는 없지만, 위키피-탄은 이미 비공식 마스코트야.EVULA// talk // talk // 18:14, 2008년 6월 12일 (UTC)[응답]

이것은 공식적인 위키백과의 마스코트여야 한다. -- 코스트토코아스트 (토크) 21:46, 2008년 6월 13일 (UTC)[응답]

숫자에 대한 명명 규칙 수정 제안

나는 위키백과:숫자와 연도에 대한 명칭 변경, 그리고 911을 911로 리디렉션(동음이의)하고 본문 이름을 911(년)으로 바꿀 것을 제안한다.(Talk:911에 대한 반대 의견은 압도적이기는 하지만 2년이라는 점에 유의하십시오.)여기서 토론하고 여기서 토론하십시오. 69.140.152.55 (대화) 13:22, 2008년 6월 9일 (UTC)[응답]

이것이 WP의 골칫거리가 될 것이라는 것을 무시하는 것:DATE 형식, 1년을 가리켜야 하는 독립 실행형 번호를 결정할 수 있는 객관적인 방법을 제안하는가, 아니면 이것이 "911"에 대한 고립된 직감인가? — CharlotteWebb 15:49, 2008년 6월 10일 (UTC)[응답]

Talk:911과 Wikipedia talk:naming convention에서 논의한 결과, 이 제안의 의도는 911에서 연도 기사를 이전할 수 있도록 특별히 허용한 것으로 보인다. 그리고 나서 비상 전화 번호 기사를 이 이름으로 이전할 수 있도록 하기 위해서였다.안드레와 (대화) 2008년 6월 14일 17:34 (UTC)[응답]

911을 옮기자는 제안이 두 번 있었는데 둘 다 거절당했다.

첫 번째는 최소한 부분적으로 이 움직임에 반대하는 정책 때문에 거부되었다.이에 비추어, 두 번째는 제안된 정책 변화를 예시했다.

그러므로 나는 우리가 이 정책 제안도 거절된 것으로 간주할 수 있다고 제안한다.안드레와 (대화) 2008년 6월 14일 17:34 (UTC)[응답]

위키-제네갈로그 프로젝트 제안서

안녕. 내 이름은 송 지앙이야, 내 친구 중 한 명이고 위키 백과사전을 더 만들 아이디어가 있어.우리는 오랫동안 멋진 모듈을 위키로 만들자는 생각을 가지고 있었다.이제 우리는 우리의 새로운 아이디어를 당신과 공유하고자 한다.

우리는 족보나 족보 모듈을 위키에 추가하기를 원한다. 위키에서 관계를 갖는 모든 것을 여기서 찾을 수 있다.소설 속 작가들이 만든 족보든, 우리 일상 속 실제 가계도든 위키-게네갈로그는 관계의 모든 것을 보여주는 강력한 도구가 될 것이다.우리는 그래프나 나무나 비슷한 것에 얽힌 것을 보여줌으로써 그것을 화려하게 만들 수 있다.

위키-genalogy는 서로 다른 역사에서 사람 관계를 연구하고 있는 학자들뿐만 아니라, 새로운 팬들이 유명한 소설을 읽을 때 개인적인 관계를 이해하기 쉽다는 것을 발견하는 데 기여할 것이다...

확실히 위키-게네롤로그는 무료 백과사전이고 전세계 사람들에 의해 유지될 수 있다.우리는 또한 프라이버시나 유사점을 나중에 논의할 수 있는 기술로 다룰 수 있다.

만약 우리가 이것을 하기 위해 위키에 가입하는 것이 가능하다고 생각한다면, 우리에게 알려주기 바란다.만약 그렇지 않다면, 어쨌든, 노트 비교는 우리가 새로운 것을 배울 수 있는 행복한 시간이고, 우리는 미래에 반드시 우리의 아이디어를 시도할 것이라는 것을 우리에게 알려주기 바란다.

감사합니다.

--지앙송 (토크) 02:22, 2008년 6월 14일 (UTC)[응답]

"음표를 비교하는 것은 우리가 새로운 것을 배울 수 있는 행복한 시간이다." - 그래, 나는 그것이 잘 요약된다고 믿는다. --Samuel Pepys (토크) 02:25, 2008년 6월 14일 (UTC)[응답]

족보에 기반을 둔 위키백과는 좋은 생각처럼 들리지만, 위키백과는 그것을 운영하기에 좋은 장소가 아니다.위키백과에서 실행되는 소프트웨어를 언제든지 다운로드하여 자신만의 위키백과를 시작할 수 있다.— 당신을 먹여 살리는 손:^Bite 2008년 6월 14일 (UTC) 13:33[응답]

우리는 현재 그러한 목적을 위해 특정한 템플릿을 사용하여 기사화 할 수 있다.더 공식적인 구조를 유지하려면 사용자:HandThatFeeds가 언급하거나, 위키팜을 유치하여 약간의 노력을 덜 할 수도 있다.미디어위키 기반의 위키피디아는 WMF가 채택하기로 결정할 정도로 대중적이고 유용한 위키피디아 가족(즉, 위키미디어 가족)을 포함하는 위키피디아의 "가족"(의도되지 않은 가족)에 통합하기 가장 쉬울 것이다.

새 프로젝트에 대한 아이디어를 나열하는 데 사용된 이 이전 페이지를 읽으십시오. 더 이상 사용되지 않지만(하지만 마음에 들 만한 힌트가 있음).아마도 당신은 시작하기 전에 프로젝트를 설정하는 가장 좋은 방법이 무엇인지에 대한 몇 가지 아이디어를 얻기 위해 메타 어딘가에 토론을 게시하고 싶을 것이다.

마지막으로, 이것은 흥미로운 프로젝트처럼 들리는데, 재미있게 즐기길 바라!

--_{tiny plastic} Grey Knight ⊖ 13:53, 2008년 6월 14일 (UTC)[응답]

누구 그것에 대해 아는 사람 있어?우리는 그것에 대해 어떤 제안을 듣기를 바란다 :)--장송 (토크) 03:39, 2008년 6월 23일 (UTC)[응답]

좌절된: 위키피디아 평판은 더럽고, 비웃고, 무례하고, 비웃고, 비웃고, 무시당하고, 경멸하고, 신뢰할 수 없다.

내가 30세 이상의 사람들에게 위키피디아를 언급할 때, 나는 같은 반응을 얻는다.

"시간 낭비.끔찍하고 신뢰할 수 없는 정보"

• (개인적으로, 나는 위키피디아 개념이 환상적이라고 생각한다!)

내가 좀 조사했을 때, 나는 그들의 무례, 경멸, 비웃음, 경멸의 근원을 발견한다.

첫 번째 인상 - 그들은 편집 버튼을 보고, 누구나 편집이 가능하고, 즉시 프로젝트를 신뢰할 수 없는 정보로 기록한다.(그들은 위키백과의 동료 리뷰를 이해하지 못한다.)

나도 알아...그것은 기초적인 문제고 수천 번 논의되어 왔다.내가 말하는 것은 이것이 내가 직접 만나는 대부분의 사람들의 반응이라는 것이다.위키피디아는 나쁜 평판을 가지고 있고 그것은 편집 버튼 때문이다.

"Submit"(편집 대신)과 같은 간단한 변화만으로도 큰 차이가 날 수 있다.—VgerNeeds에서 추가한 서명되지 않은 설명 준비TheInfo (talk • 기여) 2008년 5월 31일 (UTC) 17:36 [응답]

• "위키피디아: 누구나 제출할 수 있는 무료 백과사전."역시 작동하지 않는다. --jpgordon^∇∆∇∆ 17:38, 2008년 5월 31일 (UTC)[응답]

더 나은 프레젠테이션을 위해 버튼 이름이나 사용자 인터페이스를 변경할 수 있다고 생각한다면, 그것은 합리적인 제안이다.대다수가 모든 기능에 관심이 없다는 이론에 따라 로그인하지 않은 사용자를 위해 버튼을 단순화하거나 재정렬하자는 제안이 있었다.하지만, 나는 위키피디아의 평판에 대한 당신의 인식을 공유하지 않는다.그것은 단순히 언론의 편향되고 얕은 보도의 부산물일 뿐인데, 인터넷상의 사물을 취재할 때 내용보다는 공포 이야기와 재미있는 일화에 더 관심이 많다.그런 의견을 가진 사람은 그것에 대해 별로 생각해보지 않았고, Wikipeida가 도달해야 할 종류의 사용자도 아니다.재단은 상업적 운영과 심지어 학교와 자선단체가 언론 악화에 대처하기 위해 사용하는 수백만 달러의 홍보와 마케팅 예산이 부족하기 때문에, 우리는 그것을 감수해야 할지도 모른다. 2008년 5월 31일 (UTC)

그럼에도 불구하고 우리는 인터넷에서 가장 인기 있는 웹사이트 중 하나이다.우리는 진행 중인 작업이다._{1 != 2} 2008년 5월 31일 17:49 (UTC)[응답하라]

물론 "편집" 버튼의 이름을 "등록"으로 바꾸기만 하면 되지만, 등록하지 않은 사용자만 가능하다.그럼에도 불구하고 고려해야 할 사항이다. -- 아첨꾼알렉스: 2008년 5월 31일 17:51 (UTC)[응답하라]

그리고 편집버튼이 정보를 신뢰할 수 없게 만든다고 생각하는 모든 이들에 대한 나의 대답은, 교과서나 다른 출판물과 관련이 있는 것처럼 오류를 참고하거나 긴 에라타 시트를 참조하는 것보다 실제로 오류를 수정할 수 있다는 것이 얼마나 놀라운 만족감을 주는지를 지적하는 것이다."읽는 모든 것을 믿지 말라"는 속담은 오랫동안 위키백과보다 앞서 있었다.—ashanda (talk) 18:04, 2008년 5월 31일 (UTC)[응답]

위키피디아는 젊은이가 아닌 사람들에 의해 그렇게 보편적으로 비난받지 않는다.나이가 많은 적극적인 기고자들이 많이 있다.나는 위키백과의 아이디어를 좋아하는 여러 대학 교수들을 만나 보았다 - 책에서 다루기엔 너무 구체적인 주제에 대한 정보를 얻기 위해 학생들에게 위키백과를 참조하도록 한 교과서까지 본 적이 있다.위키백과 역시 보편적으로 좋아하지는 않지만, 편집 탭의 문구를 바꾸는 것은 정말로 어떤 마음에도 변화를 줄 것이라고는 생각하지 않는다.Mr.Z-man 18:08, 2008년 5월 31일 (UTC)[응답]

그리고 30세 이하의 많은 사람들이 우리를 해고한다.Therequiembellishere (대화) 04:24, 2008년 6월 1일 (UTC)[응답하라]

"편집"을 "제출"로 바꾸는 근본적인 문제는 그것이 부정확하다는 것이다.이것은 실제로 동료 평가 시스템이 아니다.편집 내용은 "저장 페이지"를 누르면 바로 실행되며, 다른 사람의 눈은 편집 내용을 보지 않는다.만약 당신의 나이든 친구들이 이것이 위키피디아를 신뢰할 수 없게 만든다고 생각한다면, 그것은 그들의 의견이다.만약 버튼에 "제출"이라고 적혀있다면, 새로운 편집자들은 위키피디아의 일부가 되기 전에 누군가가 "제출"을 볼 것이라고 가정하고 변경을 할 수 있다. 모낙토크 05:55, 2008년 6월 6일 (UTC)[응답]

위키피디아를 사용하는 사람들은 그들이 읽고 있는 페이지의 최악의 페이지를 기대해야 한다는 것이 실제로 중요하다.단지 지난 5분 동안, 누가, 무엇이 바뀌었는지 확신할 수 없다는 것이 진실이다.기사의 내용은 품질과 검증가능성을 통해 그 신뢰성을 입증해야 한다.이에 대한 비이성적인 두려움의 관점에서, 어떤 경험을 가진 누군가가 적어도 페이지를 이미 확인했다는 것을 알기 위해, 깃발 개정의 등장은 당신의 친구들이 필요로 하는 안전 담요가 될 수 있다.빅블루피쉬 (토크) 15:28, 2008년 6월 7일 (UTC)[응답]

제출 단추로 변경하는 대신 "수정/추가" 단추는?밥주카 (토크) 2008년 6월 9일 12시 55분 (UTC)[응답]

그것은 단순히 편집의 불완전한 정의일 뿐이다.BigBlueFish (대화) 2008년 6월 9일 16:11, (UTC)[응답하라]

좀 더 정직한 해결책은 어떨까..;) ...좀 더 진지하게 말하자면, 나는 여전히 당신이 편집만 할 수 있다는 것에 놀란 더 많은 사람들과 마주친다.의견이 낮은 대부분의 사람들은 단순히 WP가 누구를 편집할 수 있도록 허락하는 문턱이 낮다고 생각하지만, 문턱이 없다는 것은 아니다. --Gmaxwell (대화) 19:53, 2008년 6월 15일 (UTC)[응답]

우선 순위

내가 말할 수 있는 한 그들은 위키 정책의 우선 순위에 명시되어 있지 않다.나는 우리가 어떤 정책이 다른 정책보다 더 중요한지 결정할 때가 되었다고 느낀다.예를 들어 WP에서 다음과 같이 한다.RM 10명의 투표자는 반대하지만, 참고인이 있는 1명의 투표자는 WP:WP:V로 컨을 기각하시겠습니까?WP:C가 WP:V를 지배할 수 있지?그네빈 (대화) 12:38, 2008년 6월 3일 (UTC)[응답]

WP:IAR이 가장 먼저 올 겁니다. 만약 그게 도움이 된다면. --ocratic알렉스:. 2008년 6월 3일 12시 59분 (UTC)[응답하라]

나는 이런 일이 더 많은 위키리듬을 조장하고, 의견의 불일치 문제에 대해 합의와 타협을 시도하려는 지역사회를 퇴색시킬 뿐이라고 생각한다. - 메이슨 패트리엇 (대화) 15:51, 2008년 6월 3일 (UTC)[응답]

현재 WP:BASHING도 위키에게 적용될 많은 규칙이 있기 때문에 컨에 도달하는데 별로 도움이 되지 않는다. Gnevin (토크) 07:29, 2008년 6월 4일 (UTC)[응답하라]

그러나 그들은 각기 다른 상황에서 다른 방식으로 적용된다. 예를 들어, 10명의 사람들이 검증 불가능하다고 해서 기사를 삭제하기로 합의하고, 한 사람이 와서 마감 직전에 그 기사에 신뢰할 수 있는 참조를 덧붙인다면, 최종 관리자는 더 이상 해당하지 않기 때문에 이전의 의견을 무시할 수 있다.효과적으로 11번째 편집자는 WP:V를 사용해 WP를 지배했다.CON, 위에서 말한 것과는 정반대다.:-) 우선 순위 문제를 다루는 가장 쉽고 간단한 방법은 WP:주어진 상황에서 우선 순위가 낮다고 생각되는 정책 부분은 무시하십시오(상황 목록과 정책 준비 목록을 만들지 않고도 동일한 효과를 제공하므로, 결국 무진장 상태가 될 수 있음).User:autrumpative가 그런 것 같아.알렉스:. 말하려고 했어. --_{tiny plastic} 그레이 나이트⊖ 07:20, 2008년 6월 5일 (UTC)[응답]

WP:V에 근거하여 10:1의 Con이 오버 턴되는 단 하나의 사례가 있는가?그네빈 (대화) 07:32, 2008년 6월 5일 (UTC)[응답]

다른 논평자들이 제공한 유일한 근거가 "신뢰할 만한 출처가 없다"는 것이고 누군가가 AfD의 중간을 고친다면, 나는 그것이 유일한 타당한 결과라고 생각할 것이다.실제 예시는 잘 모르지만, 믿을 만한 출처가 없다는 이유로 믿을 수 있게 소싱된 기사를 삭제하는 것은 꽤 어리석은 일이라고 생각하므로, 바라건대 일부라도 있기를! --_{tiny plastic} 그레이 나이트 ⊖ 08:10, 2008년 6월 5일 (UTC) 포맷 오류 수정을 위해 당신의 코멘트를 살짝 수정했다[응답]

나는 미국법(예: WP:C) 준수에 필요한 모든 규칙이 우선되어야 한다고 제안하고, 그 다음에 WP:NPOV과"먼저 해를 끼치지 않"(저가 의무 사항으로"모든 규칙 무시한다면"기는 그"다음 과정의 중요성, 때때로, 필요에 의해 피해를 않은 혹은 부적절한 부정확한 콘텐츠로 인한 최소화하는 것에 대체될 수 있다고,"[1]) 다른 모든 정책 순 일반적인 원리, 합의에 이어가 뒤를 이었다.구날짜 표시즉, 지침이 무시되어야 한다는 것이 아니라, 목록에 있는 상위 항목이 그것과 모순된다면, 그 계층에서 가장 높은 것이 일반적으로 우세할 것이다.69.140.152.55 (대화) 14:44, 2008년 6월 9일 (UTC)[응답]

________________________________

69.140.152.55 (대화) 14:44, 2008년 6월 9일 (UTC)[응답]

미안해, 찰리 하지만 여긴 챔피언급 침대야그 정책은 입지가 같다.공동체가 우선이고 중복되는 경우 정책을 어떻게 적용할지를 결정할 것이다.제프 플로르드 (대화) 06:20, 2008년 6월 16일 (UTC)[응답]

제안 - 공정한 사용 위반/카피비오 업로드를 위한 경고 시스템

위키피디아의 결과:관리자 게시판/사고/사용자:켈리 블록 리뷰, 이미지에 관한 저작권 정책을 준수하지 않는 사용자를 위해 등급화된 경고 시스템(반달에 사용하는 것 등)을 제안하고 싶다.예를 들어 WP를 명백히 위반하는 비자유 이미지를 업로드하는 사용자:NFCC(합리성이 없음, 지나치게 고해상도, 저작권 소유자가 확인되지 않음 등) 및 제작자와 발행일시를 식별하지 않는 청구된 공공 도메인 이미지, 저작권 보유자의 허가를 받아 사용되었다고 주장하는 이미지 등, 무료 라이센스 청구에 필요한 데이터 없이 "무료" 콘텐츠를 업로드하는 사용자해당 OTRS 티켓이 없는 r.

경고는 사용자가 지적재산권법 및/또는 위키피디아의 무료 콘텐츠 정책을 위반하는 이전 업로드에 대한 업로드 로그를 검토해야 함을 명시해야 한다.이미지를 규정 준수 상태로 가져올 수 없는 경우 사용자 자신이 해당 이미지를 삭제하도록 플래그를 표시해야 한다.물론 사용자가 통제할 수 없는 조건(기사 편집으로 인해 고아가 된 공정 사용 이미지처럼)은 사용자에게 불리하게 작용해서는 안 된다.

이를 준수하지 않는 사용자는 동일한 종류의 규정을 더 이상 준수하지 않을 경우 이미지 업로드가 차단되거나 차단된다는 메시지를 받게 된다(이것은 개발자가 처리해야 할 기술적 문제임).

이 다섯 기둥 중 하나가 더 이상 악화되는 것을 막기 위해서는 이와 같은 것이 시급하다고 생각한다.켈리 19:48, 2008년 6월 14일 (UTC)[응답]

지지하다.이제 우리는 구제불능 업로더에 대해 뭔가를 할 때가 되었다. 그리고 그들을 다룰 방법을 찾을 때가 되었다.업로드 권한을 제한하는 것이 효과가 있을지 의문이다.그러면 단순히 "획득"하지 않는 사람들 또한 그들의 특권이 취소된 이유를 "획득"하지 않을 것이다. -- 풀스톱 (대화) 22:24, 2008년 6월 14일 (UTC)[응답]

나는 경고 시스템을 지지하지만, {{Uw-Upload4}}}의 시스템과 어떻게 다를까?MBisanz^talk 22:41, 2008년 6월 14일 (UTC)[응답]

우리는 한동안 있었던 사람들에게 경고를 줄 수 없다 - WP:DTTR. 나는 그것이 단지 에세이일 뿐이라는 것을 이해한다. 하지만 당신은 언젠가 기존의 사용자들에 의해 카피비오를 다루려 한다. 단테의 책에 속한다.게다가, 우리는 이 사람들에게 그들의 오래된 업로드를 고치도록 강요할 수 있는 방법이 필요하다.켈리^hi! 23:37, 2008년 6월 14일 (UTC)[응답]

흠, 그래, 나는 DTTR 문제를 볼 수 있어. WP는 너무 안됐지.TTR은 WP의 거의 다음과 같은 내용을 가지고 있지 않다.DTTR. MBisanz^talk 02:16, 2008년 6월 15일 (UTC)[응답하라]

그래서 일반인들을 본떠서 만들어라.만약 그들이 한 번 무언가를 하고 있고 그들이 일반 사용자라면, 그들은 아마 망쳤을 것이다. 그리고/또는 새로운 이미지일 것이다."야, 잘못하고 있구나.어떻게 하면 잘못하지 않을 수 있는지 알아보러 이리로 가시오."만약 그들이 일반 사용자가 아니라면, 그들은 아마 그것을 어떻게 하는지 모를 것이다."이봐, 잘못하고 있어.어떻게 하면 잘못하지 않을 수 있는지 알아보러 이리로 가시오."만약 그들이 계속 한다면, 그들에게 "야, 아직도 잘못하고 있구나..." 등을 주어라.나는 문제를 잘 모르겠다; 나의 첫 번째 편집 중 하나는 공정한 사용 근거 없이 업로드한 것이다; 나는 내가 무엇을 하고 있는지 몰랐고, 템플릿이 꽤 도움이 되었다.그때보다 편집이 몇 천 개가 더 많다고 해서 지금 내가 잘못했더라도 다른 일을 하리라고는 상상하지 않는다.셀라노르^{Talk to me} 03:57, 2008년 6월 15일 (UTC)[응답]

셀라노르, 제발 며칠 동안 이미지 태그를 붙이시오.너는 그 문제를 금방 이해할 것이다.정규 분포를 템플릿으로 만든 다음 블록이 만료되면 여기로 돌아와서 주석을 달으십시오.:) 켈리^hi! 04:07, 2008년 6월 15일 (UTC)[응답]

글쎄, 문제는 그 과정 자체보다는 방어적 편집자들이 있는 것 같다.그 과정 자체는 상당히 직설적으로 보인다.네가 망치면 누군가 널 망친다고 지적하고 다시는 그러지 마또 충분히 하면 막힌다.사실, 그렇게 복잡해 보이진 않아; 중요한 것을 놓칠 수도 있어. 그냥 뭐가 뭔지 모르겠어.국내에서 이슈가 되고 있는 편집자의 유형일 뿐인 것처럼 보이는 일반 편집자들은 프로세스가 중요하다는 것, 프로세스가 지켜지지 않는 통지가 후속 프로세스의 중요한 부분이라는 것, 그리고 그것을 하는 사람의 모든 경우를 위해 멋진 "야, 너는 잘못하고 있어" 메시지를 조작하는 것은 인간적으로 불가능하다는 것을 이해해야 한다.옹. "네가 잘못하고 있다"는 메시지는 관련 기사와 정책에 대한 링크가 있는 템플릿인지, 800개의 이미지 뒷로그가 쌓이는 동안 쓰는 데 10분이나 걸린 많은 플룻을 담은 이미지 태거가 사랑스럽게 만든 단락인지, 누군가 잘못 받아들여서 방어하게 되면, 글쎄,잘못하고 있어셀라노르^{Talk to me} 04:34, 2008년 6월 15일 (UTC)[응답]

나는 동의한다, 불행히도 그것은 그렇게 작동하지 않는다.저작권 위반은 위키백과에서 사용자가 할 수 있는 몇 안 되는 일들 중 하나임에도 불구하고 경미한 위반으로 간주된다.켈리 05:28, 2008년 6월 15일 (UTC)[응답하라]

반달에 대한 경고 시스템은 템플릿을 사용하므로 등급이 매겨진 경고 시스템(반달에 사용하는 것과 같은)도 템플릿을 사용할 것으로 예상한다.기존 템플릿 또는 새 집합으로 일반 템플릿을 템플릿으로 만드십시오.물론 일반인에게 무엇이 문제였는지 알려주는 맞춤형 메시지를 주는 것이 더 나은 선택이며, 그것이 DTTR의 의미인 것이다.DTTR은 단지 에세이일 뿐이고 많은 사람들은 에세이가 거기에 있는지조차 알지 못한다.그것은 그 ANI 실에서 전혀 문제가 되지 않는다.중요한 점은 정책을 잘 모르거나 의도적으로 위반하는 사람보다 XfDs, Pump, Project 또는 우리가 좋아하는 기사에서 매일 마주치는 사람, 아마도 정책을 알고 실수를 한 경험이 있는 편집자와 함께 통조림 메시지를 사용하는 것은 완전히 무례하다는 것이다.그들.---04:^{(talk • contribs)}10, 2008년 6월 16일 (UTC)[응답하라]

위키백과 포럼

나는 위키피디아에 회원들이 함께 대화할 수 있는 일종의 포럼이 있어야 한다고 생각한다.Y5nthon5a (대화) 05:38, 2008년 6월 15일 (UTC)[응답하라]

너 지금 한 명 아니니?5:15 06:42, 2008년 6월 15일 (UTC)[응답]

아니, 내 말은 우리가 스포츠, 텔레비전, 그리고 다른 것들에 대해 얘기할 수 있는 포럼 같은 것을 말하는 거야.Y5nthon5a (대화) 06:52, 2008년 6월 15일 (UTC)[응답하라]

그것은 일어나지 않을 것이다; 위키피디아는 토론 포럼이 아니다.IRC 채널이 몇 개 있긴 한데, 그게 네가 찾고 있는 것일 수도 있어.대수학자 08:52, 2008년 6월 15일 (UTC)[응답]

'참조' 링크에 추가할 수 있는 정보

때때로 나는 내가 읽고 있는 주제를 이해하는 것이 어렵다는 것을 알게 되는데, 이것은 다른 많은 사람들에게도 마찬가지일 수도 있다. 여기 다음과 같은 한 가지 제안이 있다.만약 그들이 이 주제를 읽기 전에 그들에게 도움이 될 수 있는 주제와 예를 들어, 그들이 그 주제를 읽은 후에 이해할 수 있어야 하는 주제에 대한 정보가 제공된다면, 그것은 나에게 더 편리할 것이다. 그리고 아마도 다른 많은 사람들에게도, 그들이 이해하려고 하기 전에 내가 먼저 읽어야 하는 수학의 정리를.그의 정리, 그리고 내가 이해할 수 있는 수학 정리는 이 정리에 대한 나의 지식을 바탕으로 한다.이러한 정보와 함께 '또한 보기' 링크를 추가하여 독자들이 이 주제를 이해하지 못할 경우 어떤 링크가 도움이 될 수 있는지, 그리고 다음에 어떤 주제를 읽고 싶은지에 대한 지침을 제공한다면 좋을 것이다.—202.40.137.197 (대화) 09:35, 2008년 6월 15일 (UTC)[응답]에 의한 서명되지 않은 논평 준비

"이 주제를 읽기 전에 그들에게 도움이 될 수 있는 주제와 그 주제를 읽은 후에 그들이 이해할 수 있어야 하는 주제에 대한 정보를 제공받는 것이 나에겐 더 편리할 것이다." 그렇다, 삼투에 의해 '읽는' 능력처럼 말이다.스크린 아이 위에 손을 올려라. --Samuel Pepys (토크) 09:37, 2008년 6월 15일 (UTC)[응답하라]

삼투압으로 '읽을 수 있으면 좋겠다.그것의 문제는 그것이 실행될 수 없다는 것이다. 반면에 편집자들에게 간단한 정보를 '또한 참조' 링크와 함께 추가하는 것은 독자들에게 매우 좋을 것이라고 상기시키는 것이다.영어를 못해서 미안해..—서명되지 않은 코멘트 202.40.137.197 (대화) 10:11, 2008년 6월 15일 (UTC)[응답]

참고 항목: "자세한 정보"는 주차 공간이 아니다.also는 기사의 본문에 아직 추가되지 않은 링크임을 참조하십시오.

기사의 첫 번째 문장은 이미 전제 조건 정보를 제공하는 기사와 연결되어야 한다.그 링크들은 당신이 필요로 하는 "참고"이다.

예를 들어, "Louville의 정리에는 모든 경계된 전체 기능이 일정해야 한다고 명시되어 있다"는 두 개의 "참조"도 있다.

-- 풀스톱 (대화) 2008년 6월 15일 (UTC) 10시 39분[응답]

여기에 심각한 문제가 있는데, 해결이 안 되는 것 같다.많은 기사들이 기술적으로 밀도가 높아져 그 분야에 정통한 독자들도 기사를 이해하기 어렵다는 것을 알게 되었다.현재의 예는 물리학자들조차 불평하고 있는 멤리스터다.나는 내가 꽤 잘 알고 있는 주제에 대해 기사를 쓰기 시작했는데, 1년 후에 다시 돌아와서 나는 그 주제에 대해 거의 이해하지 못했다.기사는 전문용어와 방정식 없이 시작되어야 한다.더 아래로 (아마도 더 아래로) 그 기사는 더 기술적인 것이 될 수 있다.기사의 시작은 그 주제에 대해 아무것도 모르는 사람을 위한 소개가 되어야 한다 - 평균 14세처럼.심리학자 제롬 브루너는 학습자(아주 어린 나이에도)는 적절한 지침이 마련되어 있는 한 어떤 자료도 배울 수 있다고 썼다. -- -- SamuelWantman 06:18, 2008년 6월 16일 (UTC)[응답]

특정 "목록"에서 "아웃라인"으로 주요 이름 변경 제안

인덱스

foo 주제로 색인하시겠습니까?다른 생각일 뿐이야.오스카 더캣3 (토크) 21:06, 2008년 6월 11일 (UTC)[응답하라]

네가 이 얘기를 꺼내다니 흥미롭군.위키피디아는 알파벳 인덱스를 가지고 있다.

• 환경 주제 목록
• 지리학적 주제 목록
• 역사 항목 목록
• 법률 주제 목록
• 수학 기사 목록
• 철학 주제 목록
• 정치 주제 목록
• 심리학 주제 목록
• 일본 관련 기사 목록

몇 가지 예를 들면."색인"은 구조화된 목록이나 작은 목록과 같은 대부분의 목록에는 맞지 않지만, 광범위한 알파벳 리스트의 이름을 "____ 기사 색인"으로 바꾸는 것이 적절할 것이다.트랜스휴머니스트 21:29, 2008년 6월 11일 (UTC)[응답]

필요한 인덱스는 반드시 알파벳순이어야 하는가?Skomorokh 00:59, 2008년 6월 12일 (UTC)[응답]

반드시 그렇지는 않지만(그러나 일반적으로 색인 및 wikt:index 참조) 그러나 현재 이 제도를 따르는 많은 기사 집합이 있다.범주:436개 모두에 대한 주제 인덱스. -- Quiddity(토크) 01:31, 2008년 6월 12일 (UTC)[응답]

(충돌 편집) 한때 나는 심지어 색인: 네임스페이스가 많은 foo 기사 목록에 적합한지까지 고려했다.그 접근방식의 단점은, 분명히, 그러한 기사에서 가장 유용한 위키링크가 상호간 네임스페이스 위키링크가 될 것이라는 점이다.

나는 스코모록이 훌륭한 포인트를 올렸다고 생각한다: 지표가 알파벳이 될 필요는 없다.사실, 대부분은, 인간이 순서가 없는 목록보다 순서 목록에서 특정 항목을 찾는 것이 더 쉬운 경향이 있고, 라틴 알파벳은 친숙한 순서 메커니즘을 제공하기 때문이다.그럼에도 불구하고, "분류된" 또는 "주제적인" 지표가 존재한다. (사실, 위키스페종의 전체는 생물들의 지표다.)

내가 여기서 또 다른 지렁이 통을 열 수도 있지만, 이러한 "foo 주제 목록"(기사 공간에서)을 중복해서 반복하지 않는 경우가 많지 않은가?AfD는 운동회를 할 수도 있다. --Oscar TheCat3 (토크) 20:44, 2008년 6월 12일 (UTC)[응답]

나의 문법을 고쳐줘서 고맙지만, "중복적으로 반복한다"는 것은 의도적이었다.물론 "반복"만으로도 충분할 것이다. --Oscar TheCat3 (토크) 19:36, 2008년 6월 13일 (UTC)[응답]

사소한 타이핑/문법 오류에 대해서는 다른 사람의 코멘트를 편집하지 마십시오.위키백과의 두 번째 문장을 참조하십시오.토크 페이지 가이드라인#코멘트 편집: "코멘트를 수정하고 있는 사용자를 자극하는 경향이 있다."아래에 표준 예외 목록이 있다. -- Quidity (대화) 21:18, 2008년 6월 13일 (UTC)[응답]

응, 전혀 다른 벌레 통조림이야.그것들은 대부분 위키백과 주제의 이익을 위한 것이기도 하지만, 가끔 읽는 사람들을 돕기도 한다(안도라 관련 주제 목록("분류된" 지수의 예)과 같은 많은 주제에서의 소개 문구 참조).WP 참조:자세한 내용은 TRIENSTA를 참조하십시오.-) (프로젝트 공간으로 이동하면 더 적게 사용됨(더 쉽게 찾을 수 있고, 업데이트해야 할 동기가 덜함) -- Quiddity (대화) 21:42, 2008년 6월 12일 (UTC)[응답]

WP:TRI -- 구체적으로 DBAD 원칙을 말하는 겁니까? :-) --OscarTheCat3 (대화) 19:36, 2008년 6월 13일 (UTC)[응답]

특별히 그렇지는 않다.IAR, 구체적으로 말하면.나는 페이지 전체를 의미했다. (비교적, 문맥적, 궁극적, 성인 전용, 모호함).이 곳은 엉망진창이 많으니, 적어도 몇 년 동안은 좀 엉망진창일 것이다.M:임시주의는 대부분의 경우 우리 공동체에 가장 큰 위해요인이다. (임호, 그리고 전혀 다른 주제).--Quiddity (대화) 21:18, 2008년 6월 13일 (UTC)[응답]

위키백과: 지침을 참조하십시오.이중화 문제를 해결하는 범주, 목록 및 탐색 템플릿.목록은 우수한 프리젠테이션 형식, 주석 및 이미지 지원, 비링크 데이터, 스크롤의 편리성, 검색성, 레드링크 지원 등 범주에 걸쳐 업그레이드의 역할을 하기 시작하고 있다(기본 주제 목록은 이러한 모든 기능을 활용하기 때문에 좋은 예다).한 시스템이 다른 시스템을 교체해야 하는가?카테고리 시스템은 링크를 수집하고 상위 목록을 작성하는 데 유용하기 때문에 위키피디아에서 삭제되어서는 안 된다.차례로 목록은 범주를 업데이트하는 데 유용한 출처다.목록은 작업하기가 훨씬 쉽다(섹션을 조합, 분할 또는 복사하여 그것으로부터 복사하여 붙여넣기 쉽기 때문에 카테고리를 직접 편집할 수 없음). 목록들은 범주를 작업하기 쉽게 만든다: 목록은 AWB에 연결하여 카테고리를 업데이트할 수 있으며, 이는 이러한 카테고리를 손으로 업데이트하는 것보다 훨씬 빠를 수작업으로 업데이트하는 것보다 훨씬 빠르다.두 시스템(목록과 범주)이 시너지 효과를 내고, 서로 보완한다.트랜스휴머니스트 22:42, 2008년 6월 12일 (UTC)[응답]

좋은 점, 그리고 내가 고려하지 않은 점: 이것은 어느 쪽/또는 어느 쪽도 아닌, 그리고/또한 그럴 필요가 있다.솔직히, 나는 WP를 알지 못했다.CLN은 존재했다.나도 MoS 전체를 읽어본 적이 없는데, 나중에 퀴즈가 있을지도 모른다는 것을 몰랐기 때문이다. :-) 그 가치가 무엇인지는 다음과 같다.

* X 주제/기술 목록을 적절한 경우 X 주제/기술자 인덱스로 이동(물론, 해당 위치에 재질 작성) 지원--Oscar TheCat3 (대화) 19:36, 2008년 6월 13일 (UTC)[응답]

나는 또한 "Index of (기본) foo topic" (기사 이외의 주제, 범위를 제한하고 redlink를 허용)을 지지한다.이는 비알파벳 사용이 위키백과 전체의 "인덱스"라는 단어의 다른 용어와 상충하지 않으며, 독자들이 비알파벳 링크를 발견해도 놀라지 않을 것이라는 가정에 근거한다.트랜스휴머니스트, 퀴디티, 뭐라고 하지?스코모록 09:18, 2008년 6월 15일 (UTC)[응답]

(기본) 부분은 어느 곳에서도 요구되어서는 안 된다. 완전히 분리된 프로젝트들이다. (지표는 전체성을 목표로 하고, 기본목록은 핵심/기본만을 목표로 한다.

그러나 그렇다, 나는 카테고리에 있는 모든 "foo 주제 목록" 기사의 이동을 지지한다.주제 인덱스 "foo의 주제 인덱스" 또는 "foo 주제 색인"에 대한 주제 인덱스. (첫 번째 인덱스, 카테고리 이름과 일치하고 키워드가 항상 줄 끝에 있다는 것을 의미하므로 선호한다. -- Quidity (토크) 21:22, 2008년 6월 15일 (UTC)[응답]

나는 지수 프로젝트나 제안이 기본 리스트에는 적용되지 않는다는 Quiddity에 동의한다.아웃라인 구조, 리드 섹션 산문, 주석, 이미지, 차트, 지도, 외부 링크 지원, 기본 목록의 제한된 범위 등은 인덱스와 매우 구별된다.윤곽이 더 발전할수록, 그들의 구조는 훨씬 더 정교해질 것이고, 지수와 더 멀어지게 될 것이고, 이것은 국가의 윤곽에서 쉽게 볼 수 있다.예를 들어, 정부부처의 구조의 표시는 인덱스에 유지되지 않을 것이고, 이런 종류의 내용을 가진 페이지를 인덱스로 기술하는 것은 매우 오도될 것이다.다음은 일본의 기본 주제 목록 중 집행부 섹션:

일본 정부의 행정 구역

캉테이 현 총리 집무실 및 거주지

• 상태 기호:아키히토 일왕
  • 황제는 행정권은 없지만 외교의례에 따라 국가원수 대우를 받는다.
  • 일본 천황의 역할에 대한 논란
  • 역대 황제
• 국가 원수: 사실상의 일본 국가원수는 정부 수반, 총리(아래 참조)
• 정부 수반 : 후쿠다 야스오 일본 총리
  • 캉테이(총리실 및 관저)
  • 역대 총리
• 일본 내각
• 일본의 행정 구역
  • 국가공공안전위원회
  • 총무성
  • 법무부
  • 외무부
  • 재무성(일본)
  • 문부과학성
  • 후생노동성
  • 농림수산부
  • 경제통상산업부
  • 국토교통부
  • 환경부
  • 국방부

나는 명백한 색인이고 개요가 아닌 주제 목록은 "foo 기사 색인"으로 이름을 바꿔야 한다고 생각한다.색인은 특정 작품에서 다루는 과목들의 목록이다.책에서 다루지 않은 주제를 나열한 "색인"이 있는 책을 상상해 보라.그것의 지수는 더 이상 지수의 정의에 속하지 않을 것이다.책의 "주제의 색인"은 그 색인이 지원하는 작업에 포함된 주제를 제시하는 것으로 가정할 수 있으며, 함축적으로 "기사 색인"으로 기본 설정될 수 있으며, 위키백과에도 이와 동일한 원칙이 적용된다.그래서 레드링크에 대한 문제가 생겼어곰곰이 생각해 보면, 레드링크는 위키피디아의 핵심 특징이며, 심지어 색인에서도 제자리에 있지 않다.위키피디아의 모든 페이지와 마찬가지로, 색인은 진행 중인 작업이며, 레드링크는 단순히 계획된 기사를 지정한다.따라서 "foo 기사 색인"은 "foo 주제 색인"보다 적합하다.트랜스휴머니스트 22:14, 2008년 6월 15일 (UTC)[응답]

아마도 더 넓은 논의가 필요할 것이다.

나는 이 논의의 대부분이 매우 적절하다고 생각하며 목록, 포털, 범주 및 기타 항법 방법에 대한 광범위한 논의가 이루어져야 하는지 궁금하다.나는 범주 교차로제가 완전히 시행되면 범주를 곧 다시 정비해야 할 것을 우려해 왔다.검색을 이용하여 범주의 교차점을 찾는 것은 이미 가능하지만, 우리가 넓게 채워진 범주를 가지고 있지 않기 때문에(대부분 작은 범주로 분산되기 때문에), 그 특징은 그다지 유용하지 않다.나는 우리가 매우 광범위하게 정의될 "인덱스 카테고리"를 만들 수 있기를 바란다.우리가 어떻게 범주, 목록 등을 재편성하고 싶은지 다시 생각해보는 것이 도움이 될 것이다.위키백과 항해에 대한 전반적인 점검의 일환으로문제는 현상의 압도적 관성 때문에 어떤 형태의 정비에도 저항이 있어 보인다는 점이다.하지만 관심이 있다면 기꺼이 다른 사람들과 상의해서 우리가 새로운 정리 계획을 생각해 낼 수 있는지 알아보자.아마도 시험 프로젝트로서 그 계획에 따라 한두 과목은 재구성될 수 있을 것이다. -- 사무엘완트만 07:20, 2008년 6월 15일 (UTC)[응답]

두 가지.

• 당신은 위키피디아를 통해 읽는 것에 관심이 있을 것이다.포털 동료 검토/내용/보관1 및 포털 대화:내용.시간/에너지는 없었지만, V1.0 분들께 이 모든 것을 말씀드리고 싶구나. 그들이 어떻게 생각하는지 보자고.특히 포털 대화에서 목록을 참조하십시오.내용#고려해야 할 사항 및 포털 대화:컨텐츠/주제 시스템.
• 나는 우리의 4가지 내부 "See" 유형의 콘텐츠를 함께 배치하는 아이디어에 사로잡혀 있다(See 또한 링크, 카테고리, 바닥글 탐색 상자, 자매 프로젝트 링크 상자).그들이 참조/외부 링크 섹션에 의해 강제로 분리되지 않았다면 좋을 것이다.

그러면 잠시 정신이 없을 것이다;) -- 퀴디티 (대화) 21:33, 2008년 6월 15일 (UTC)[응답하라]

좀 더 폭넓은 토론?좋아. 아래를 봐...트랜스휴머니스트 07:13, 2008년 6월 16일 (UTC)[응답]

인덱스 빌더 봇

색인 카테고리 페이지의 작성은 이론상 흥미롭지만, 카테고리는 추적 기능이 없기 때문에 유지하기가 매우 어려울 것이다.그리고 직접 편집하지 못하는 것도 큰 장애물이다.레드링크 지원도 실종됐다.인덱스 페이지는 AWB가 인덱스 페이지 링크를 수집할 때 카테고리 시스템을 채굴할 수 있기 때문에 개발 및 유지관리가 훨씬 용이하다.아마도 봇은 채굴 카테고리에 대해 만들어질 수 있고, 그 범주에서 발견된 링크를 인덱스 페이지에 삽입한 다음, 인덱스 페이지를 자동으로 정렬할 수 있을 것이다.이것은 관련 범주의 모든 링크뿐만 아니라 편집자가 손으로 추가한 모든 링크를 포함하는 인덱스 페이지를 허용한다.레드링크 또한 지원될 것이다. 왜냐하면 봇은 인덱스에서 항목을 삭제하지 않고 인덱스에만 추가되기 때문이다.트랜스휴머니스트 22:49, 2008년 6월 15일 (UTC)[응답]

나는 이 논평이 매우 설득력이 있다고 생각한다.아마도, 4년 동안 카테고리를 연구한 후에, 우리는 아마도 리스트가 처음부터 더 낫다고 결론지을 수 있을 것이다.나는 추적의 부족과 범주 변경을 쉽게 되돌릴 수 없는 것이 범주 분류 시스템이 현재의 상태를 지나도록 개선되지 못하게 하는 결함이라고 생각한다.편집 가능한 목록(또는 색인 또는 우리가 그들을 부르는 모든 것)은 많은 장점이 있다.범주와 비교할 때 유일한 단점은 현재 작업 중인 기사의 목록에 항목을 추가하기 위해 더 많은 작업이 필요하며, 데이터베이스 검색을 위해 목록을 사용할 수 없다는 점인데, 이는 현재 범주를 통해 최소한으로 가능하며, 향후에 더 가능성이 높아지게 된다.아마도 전체 계획은 재고할 필요가 있을 것이다.카테고리는 데이터베이스로서 가장 유용한 것 같다.만약 우리가 상위 수준의 단일 속성 범주에만 기사를 포함시킨다면, 그것들은 교차로를 만드는 데 훨씬 더 유용할 것이다.만약 모든 범주를 봇에 의해 목록으로 옮겨서 당신이 설명한 대로 보관한다면, 그것은 훨씬 더 개선될 것이다.우리가 하는 동안, 그 과정은 양방향으로 작용해야 한다.현재 모집단과 보관 상태를 비교하여 범주를 이전 상태로 복원할 수 있는 봇이 있어야 한다.이는 목록(또는 목록이라고 부르는 인덱스)이 다시 한 번 기사를 탐색하는 주요 방법이 된다는 것을 의미한다.범주는 데이터 마이닝에 대한 데이터베이스 기능에 사용될 것이다.

이 모든 목록에 대해 "인덱스" 네임스페이스를 추가하는 것을 고려해 보십시오.당신은 기사에 "색인" 항목을 추가할 수 있고 그것은 그것이 지금 그것을 카테고리에 추가하는 것과 마찬가지로 색인에 기사를 추가할 것이다.색인 페이지는 기사처럼 편집될 수 있고, 그렇게 색인화된 모든 기사에 대한 링크를 포함할 것이다.링크를 구성하지 않을 경우, 링크는 "미구성 항목" 섹션의 페이지 하단에 자동으로 추가된다.소프트웨어는 인덱스에서 연결된 모든 페이지를 추적할 것이다.누군가가 인덱스에 링크를 추가하면 자동으로 기사에 추가된다.기사에 링크를 추가하면 자동으로 인덱스에 추가된다.같은 방법으로 제거했으면 좋았을 텐데이렇게 하면 그 변화는 어느 한쪽 끝에서나 되돌릴 수 있을 것이다.기사 하단의 카테고리 목록 바로 위에 인덱스를 나열하는 영역이 있을 수 있다.많은 네비게이션 상자처럼 "인덱스 표시"를 클릭하지 않는 한, 이것의 기본값은 그들이 보이지 않는 것이라고 추측할 수 있다.채굴 카테고리 교차로에 의해 많은 인덱스가 생성될 수 있다.이것은 가능성이 있다고 생각한다. -- 【사무엘완트맨 01:54】, 2008년 6월 16일 (UTC)[응답]

레드링크 포함을 제외하면 상당수는 카테고리 트리로 해결할 수 있을 것 같다.아래 예시.전체 주제는 새로운/별도의 실마리를 얻을 만 하다. -- 퀴디티 (토크) 18:42, 2008년 6월 16일 (UTC)[응답]

나중에 추가된 코멘트: 내게는 하위 페이지의 드물게 적절한 사용 중 하나처럼 들린다.위키백과 대화 참조:위키프로젝트 지식 개요#이 페이지 이름 +sj + 15:12, 2009년 3월 10일(UTC)[응답]

Useroval

안녕, 나는 wikiHow(여기 등록된 사용자)의 IP 사용자야. 템플릿이 있는 것을 봤어.사용자 상자와 마찬가지로 사용자 상자도 Firefox에서 타원형으로 표시되는 것을 제외한다.그것은 IE에서 아무런 차이가 없을 것이며, a는 일반 사용자 박스 템플릿과 같이 디스플레이 될 것이다.난 그냥 궁금했어, 고마워

♦ { Crimson } ♦ Talk • 기부금 14:47, 2008년 6월 14일 (UTC)[응답]

궁금했던 게 뭐였죠?난 이해가 안돼.만약 당신이 이것을 사용하는 사용자 박스를 만들고 싶다면, 나는 그렇게 할 수 있다고 생각한다 (그러나 나는 사용자: 네임스페이스를 만드는 것이 요즘 권장되는 최선의 방법이라고 생각한다.)뭘 물어보는 거야?_{tiny plastic} -- 그레이 나이트⊖ 15:07, 2008년 6월 14일 (UTC)[응답하라]

나는 그가 위키피디아에 수입된 템플릿을 여기서 사용하도록 요청하고 있다고 생각한다.— 당신을 먹여 살리는 손:^Bite 2008년 6월 14일 (UTC) 18:35[응답]

--_{tiny plastic} 그레이 나이트 knight 08:45, 2008년 6월 16일 (UTC)[응답]

비활성 사용자

가끔 목록이나 사용자 범주(예: 위키백과 제목, 일부 언어 사용 사용자 범주...)를 검색하여 연락할 때 대부분의 경우 비활성 사용자를 위해 포스팅을 한다.글을 올리기 전에 확인하는 습관, 각 사용자의 기여 페이지 등을 통해 여전히 기여하고 있는지 없는지 확인하는 습관을 들이기 시작했다.하지만 그것은 지루한 일이다.이 글을 올리기에는 여기가 맞지 않는 곳이라는 것을 알고 있지만(버질라라고 생각하지만, 어떻게 올려야 할지 모르겠다) 사용자의 활동 여부에 대한 표시를 좀 덧붙이는 것이 유용할 것 같다.사용자 페이지를 방문할 때 위, 아래 또는 사이드바에 나타나는 기호일 수 있다.기호는 활성/비활성 버튼이거나 마지막 편집이 언제였는지를 언급하는 것일 수 있다.그러나 내가 또한 선호하는 것은 비활성(또는 활성) 사용자에 대한 링크는 상태를 표시하기 위해 (손상된 링크나 스텁이 빨간색으로 표시되는 것처럼) 일부 색상으로 강조 표시된다는 것이다(활성화되어야 하는 것은 기본 설정 페이지의 설정에 따라 달라짐).당신은 어떻게 생각하나요?에클립스 (대화) 2008년 6월 15일 (UTC) 16:38 [응답]

마지막으로 편집한 지 얼마나 됐는지 모든 사람들의 기여도를 계속 확인받는 것은 서버 부하가 너무 클 것 같아.아마도 필요에 따라 실행할 수 있는 대본이 더 적절할 것이다.— 당신을 먹여 살리는 손:^Bite 2008년 6월 15일(UTC) 18:24[응답]

고마워위키피디아에 요청을 추가했다.WikiProject 사용자 스크립트/요청#활성 사용자 확인 중.에클립스 (대화) 03:42, 2008년 6월 17일 (UTC)[응답]

infobox에서 명명된 참조

처음에 infobox에서 사용되고 나중에 기사 공간에서 사용되는 명명된 참조가 인용 오류를 일으킬 것으로 보인다.[4] 카테고리와의 만남:잘못된 참조 서식을 가진 페이지들은 이것이 널리 퍼진 문제였음을 보여준다.나는 대부분의 문제를 기사에 베꼈지만 이 문제는 나중에 다시 나타날 것이다.명명된 참조가 infobox에서 기사 공간으로 전달될 수 있도록 기술적 수리가 필요하다. --Samuel Pepys (talk) 17:51, 2008년 6월 15일 (UTC)[응답]

예제의 ref가 infobox에서 사용되었다고 확신하십니까?사우스 다코타 기사에 있는 (인포박스에 전체 ref를 넣고 나중에 ref 이름을 붙여서) 이 지역을 위해 이 작업을 했는데, 잘 되었다.종종 'cite error'라는 것이 나타날 때, 그것은 ref의 이름에 문제가 있는데, 그것이 제대로 복사되지 않았거나 혹은 무엇인가가 되지 않았기 때문이다; 나는 그것이 infobox에 있는 것이 문제인지 모르겠다.알렉시우스호라티우스 (토크) 2008년 6월 15일 (UTC) 18:02[응답]

사용하다{{#tag:ref content name=foo}}대신에<ref name="foo">content</ref>버그를 우회할 수 있어또한 템플릿 또는 참조 자체가 적어도 변환된 기본 참조의 경우 다음 항목으로 포장되어 있는지 확인하십시오.<includeonly>그리고</includeonly> 템플릿 페이지에서.{{Nihiltrestalk log}}{{Nihiltrestalk log}} 2008년 6월 15일 (UTC)[응답]

오! 니프티.이제 템플릿 처리 단계에서 참조가 생성될 수 있다는 의미인가?또한, {{#tag:reference}}이(가) 필요한 것 아닌가? -- 풀스톱(토크) 19:02, 2008년 6월 16일 (UTC)[응답]

두 가지 문제가 있다.

• infobox에서, 당신은<ref name=NBA.com>그리고 몸속에서, 당신은<ref name=NBA.com />참조 이름은 따옴표로 작성되어야 한다.<ref name="NBA.com">.
• {{Infobox NBA Player}}를 사용하고 필드에 "닉네임" 참조를 입력하는 경우.문제는 이 인포박스에 닉네임 필드가 없기 때문에 첫 번째 참조가 초월되지 않고 있다는 점이다.

--—— Gadget850 (Ed) - 19:25, 2008년 6월 16일 (UTC)[응답]

풀스톱, 아니. {{#tag:foo}}기본 태그는 다른 태그와 정확히 같은 방식으로 작동하며, 컨텐츠만 다르게 구문 분석(즉, 리터럴로 전달되지 않고 구문 분석됨)된다.a{{#tag:ref}}에 참고가 될 것이다.<references/>마치 a인 것처럼<ref> . 멋지다; dev를 안아줘. :D {{Nihiltrestalk log} 21:05, 2008년 6월 16일 (UTC)[응답]

도이

모든 위키백과 기사에는 디지털 객체 식별자(DOI)가 있어야 하는가?아니면 모든 늙은이들도?JFW T@lk 10:13, 2008년 6월 16일 (UTC)[응답]

사실 oldid는 doi이다.이와 같이: http://en.wikipedia.org/w/index.php?oldid=219728437, 이전 버전은 http://en.wikipedia.org/w/index.php?oldid=199899596 등 입니다. -- 풀스톱 (토크) 18:52, 2008년 6월 16일 (UTC)[응답]

자동 확증 상태에 대한 공감대를 형성하기 위한 새로운 여론 조사

최초의 여론 조사의 결과가 개발자들에 의해 거절되었다, 새로운 여론 조사 때 계정 auto-confirmed 지위가 주어져야 한다에 대해" 분명한 합의"을 수립하도록 제작되었습니다.지금 당신의 의견을 표명하고 있다.고마워!Kaldari(이야기)16:41, 162008년 6월(CoordinatedUniversalTime)[답장].

직접 퍼즐 지구 밑에 있는 검색 상자를 옮겨.

위키 피디아에 이 것:.마을 펌프#,(퍼머 링크)은 검색 필드 입력 상자를 바꾸(기술).

현재 검색 상자, 우리의 사용자가 원한 첫번째 것은 약 3/4화면을 방법의,"항법"과"상호 작용" 있는 링크의 목록.이 힘들고 노인 새 사용자에 대한 찾을 수 있습니다.

나는 우리가 직접 퍼즐 지구 밑에 이렇게 검색 상자 넘어갑니다. 제안합니다.

당신은 당신만의 브라우저에 추가하여 시험해 볼 수 있다.

addOnloadHook(함수(){document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions"))})

당신의 monobook.js.또한 입력할 수 있

javascript:void(document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions")))

브라우저의 URL바와 기자" 가다" 어떻게 단지 하나의 페이지 새로운 디자인과 잘 어울릴 것 같 볼 속으로.

만약 합의가 이 변화를 일으킬 수 있다면 나는 개발자들은 단지 기본적으로 검색 상자의 위치 조정할 수 있고, 자바 스크립트의 필요성을 배제할 것이라고 확신합니다.

그래서, 당신 생각은 어때?(이야기)03:28, 212008년 5월(CoordinatedUniversalTime)[답장]는 정확히 —Remember.

• , 하지만 이 버전은 거의 로고에 나에게 어울리는 것 같아 더 높은 페이지를 검색 상자를 보낸다는 점이 참 마음.아마 더 두꺼운 라인은 검색 상자에서 지구를 가르는?Johntex\talk 04:01, 212008년 5월(CoordinatedUniversalTime)[답장].
• 이곳에서는 쉽게 Gadget은 마치 사람들 그것을 원한다면, 나는 코드를 구현하는 것이라 보긴 어렵군도 추가될 수 있다.아, 그래 나는 것을 좋아한다.RichardΩ612 Ɣ ɸ 06:02 5월 21일 2008년(CoordinatedUniversalTime).
• 위키 백과에 새로운 방문객들 여기서 일을 알아낼 것이다를 지원한다.제안된 제작으로 검색 상자를 가진 사람은 이것을 그들이 그렇게 하는 것이 훨씬 쉽다.DuncanHill(이야기)09:28, 212008년 5월(CoordinatedUniversalTime)[답장].
• 반대 - 나는 그것이 있는 그대로가 더 멋져 보인다고 생각한다; 그것은 여전히 어렵지 않으며, 구글은 어쨌든 대부분의 사람들을 올바른 페이지로 안내할 것이다! —TreasuryTag—t—c 09:38, 2008년 5월 21일 (UTC)[응답]
• 지지하다샘플보다 더 명백하게 만들어야 한다; 미학보다 사용의 용이성이 더 중요하다(Jakob Nielsen에게 물어봐, 그는 알고 있다).대부분의 사람들이 검색엔진을 통해 위키피디아에 들어가고 위키링크를 통해 관련 기사를 찾는 동안, 우리는 방문자들이 연결되지 않았거나 편집자들이 예상하지 못한 방식으로 연결된 다른 정보들을 검색하도록 장려해야 한다.필차 (대화) 2008년 5월 21일 (UTC) 10:08 [응답]
  • 요점은 미학과 사용성을 결합하는 것이지, 다른 하나를 희생하여 한 가지를 향해 너무 멀리 가지 말라는 것이다.그리고 검색엔진을 통해 들어가지 않는 사람들을 위해 우리는 메인페이지에 정말로 눈에 띄는 검색 상자를 가지고 있어야 한다.그 때부터, 그들이 길을 찾는 것은 어렵지 않을 것이다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
• "내비게이션" 링크와 "상호작용" 링크 사이에 연결하는 것은 어떠한가?나는 그것이 더 높아질 필요가 있다고 생각하지만, 그것은 지구 바로 아래에 조금 더 야위어 보인다.그걸 위한 자바스크립트가 뭐야?그리고 이와 같은 변화를 위해 개발자들을 도청할 필요는 없다. 만약 우리가 의견 일치를 얻는다면, 관련 코드를 Mediawiki에 추가하기만 하면 된다.보통.js.해피멜론 11:04, 2008년 5월 21일 (UTC)[응답]
  • 의견 - 개발자가 이러한 변경에 관여할 필요가 없다는 점을 명확히 하기 위해 제안서를 수정했다.—John Brownon이 추가한 서명되지 않은 논평 준비 (대화 • 기여) 2008년 5월 21일 (UTC)[응답]
    • JavaScript는 모든 작업에 적합한 툴은 아니다.효과가 있을 것이고, 좋은 첫 단계지만, 페이지 로딩은 직접 변경하면 더 매끄럽고 버그 발생이 덜할 것이다.—2008년 5월 21일(UTC) 14:29, 점 기억[응답]
  • 댓글을 달다.나는 그것을 "내비게이션"과 "상호작용" 사이에서 옮기자는 해피멜론의 제안이 마음에 든다 - 그것은 내가 매우 작은 화면을 가지고 있는 문제를 해결할 것이다. 왜냐하면 그것은 스크롤하지 않고 볼 수 있기 때문이다.하지만 이것에 대해 더 생각해 보면, 왜 "Featured content", "Current events" 그리고 "Random 기사"와 같은 링크들이 그렇게 높은 곳에 있는가?일반적으로 특정 사항에 대한 정보를 찾는 이 백과사전의 대부분의 소비자들에게는 이러한 것들이 중심이라고 생각하지 않는다.---82.148.54.183 (대화) 18:05, 2008년 5월 26일 (UTC)[응답]
• 지지하다.검색 상자의 위치는 독자를 위해 최적화되어야 한다. 편집이 끝날 때마다 (독자가) 1,000 페이지 이상의 페이지 뷰가 있다.독자가 구글을 통해 특정 기사에 온다면 그 위치는 그다지 중요하지 않을 수도 있지만, 독자가 메인 페이지에서 시작할 때 매우 중요하며, 수백만 명이 매일 그렇게 한다.브리태니커 백과사전이 어떻게 하는지 한 번 보십시오 - 바로 위쪽의 검색 상자.나는 편집자들이 적응하는데 아무런 문제가 없을 것이라고 생각한다 - 2년 전에 많은 불평 없이 대대적인 개편이 있었다.그러나 옛 위치를 좋아하는 체험형 편집자는 검색 상자를 원하는 곳에 다시 넣을 수 있도록 기기를 만들어라. -- 존 브레본(가제) 11:56, 2008년 5월 21일 (UTC)[응답]
  • 그 비유는 유감스럽지만 유감스럽다.검색창을 위쪽으로 옮기더라도 서식을 획기적으로 바꾸지 않는다는 점에서 지금보다 더 잘 보이지 않을 것이다.브리태니카의 검색 상자는 마스트헤드에 통합되어 있으며, 또는 그것이 무엇이라고 부르든 항상 맨 위에 있는 것이어야 한다. 우리는 화면의 왼쪽 가장자리를 차지하는 사이드바를 가지고 있다.중요한 링크를 표시하기 위해 완전히 다른 차량.게다가, 그것은 파란 바탕에 하얀색이다; 우리의 색깔은 훨씬 더 가라앉았다.다시 말해, 그것은 분명히 우리의 검색창보다 더 눈에 잘 띈다.그리고 아마도 그럴 필요가 있을 것이다. 왜냐하면 위키피디아보다 브리태니카를 검색하는 방법이 눈에 띄게 적기 때문이다.어떤 경우에도, 이것들은 매우 다른 두 예들이다.브리태니카의 형식과 유사한 것을 채택하는 것은 위키피디아의 레이아웃을 근본적으로 바꾸게 될 것이다.그리고 현재의 것은 그것이 충족시켜야 할 필요조건에 훨씬 더 잘 맞는다.2008년 5월 22일 (UTC) 23:02의 공작 월섬[응답]
    • CommentCitizendium은 검색 상자가 맨 위에 있다. 여기를 참조하십시오.참고로 Citizendium은 브리태니커와는 달리 위키백과와 유사한 특징을 가진 위키백과라는 점에 유의하십시오.---86.145.248.219 (대화) 14:39, 2008년 5월 25일 (UTC)[응답]
      • 그게 더 좋은 예야.그러나 두 사이트의 페이지 레이아웃, 특히 각 페이지 위에 있는 탭의 차이점을 고려할 때, 나는 이것이 여기서 잘 작동할지 잘 모르겠다.2008년 5월 26일 (UTC) 02:11의 공작 월섬[응답]
• 반대 나는 위키피디아가 제공하는 검색이 쓸모없다고 생각한다.검색창은 사용하지 않는다. -- 타쿠(토크) 12시 9분, 2008년 5월 21일 (UTC)[응답하라]
  • 설명:위키백과 검색창은 독자들이 찾고 사용할 가능성이 적도록 덜 명확해야 한다고 생각한다는 말씀이세요? - 존 브로턴(리듬) (리듬) 16:36, 2008년 5월 21일 (UTC)[응답]
  • 코멘트: 검색을 사용하지 않는다고 해서 반대할 수 있는 좋은 이유는 아니다.검색을 사용하지 않으면 이동에 영향을 주지 않는다.다른 많은 사람들은 그것을 사용한다.당신은 그들을 고려해야 한다.제이슨 퀸 (토크) 2008년 5월 31일 (UTC) 23시 30분[응답]
• 지원 검색 상자는 사이드바에서 가장 중요한 것이며, 검색 상자는 이 세상의 모든 것을 이해할 수 있게 해준다.John Brown의 주장은 명백하다.팍스:보비스쿰 (토크) 12:56, 2008년 5월 21일 (UTC)[응답하라]
• 지지해줘 난 위에서 하는 게 더 좋아 존의 제안은 좋은 제안이야.J.delanoy^gabs_adds 13:27, 2008년 5월 21일 (UTC)[응답]
• 지원 화면 판독기로 목록과 머리글을 통해 쉽게 탐색할 수 있기 때문에 위에서 하는 것이 더 좋다.페이지 카테고리로 이동하려면 검색 제목에서 화살표를 두 번 누르고 기사/토론/편집 탭으로 이동하려면 "l"을 눌러 검색 제목에서 다음 목록으로 이동하십시오.예전 위치 때문에 나는 가끔 길을 찾는데 어려움을 겪었다.나는 숨겨진 "보기" 제목에 대해 알고 있지만, 그것은 나의 JAWS 버전에서는 작동하지 않는다.Graham87 14:11, 2008년 5월 21일 (UTC)[응답]
  • 특히 모니터 크기의 현대적 다양성과 관련하여 모든 솔루션이 항상 문제를 안고 있다.일부 사람들은 검색 상자가 너무 낮다고 말한다. 검색 상자를 맨 위로 가져가면 다른 문제가 생길 것이다. 그러나 특히 화면이 더 큰 사람들에게 그렇다.확실히 메인 페이지를 다양한 기기에 적응시킬 수 있는 능력은 없는가?서로 다른 사용자들의 요구는 종종 타협할 수 없는 것처럼 보인다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
• 음... 난 User:해피멜론.'내비게이션' 상자와 '상호작용' 상자는?아니면 박스의 색상을 하얀색에서 약간의 패드텔로 바꾸거나 혹은 그것이 있는 곳에서 더 돋보이게 하기 위한 것으로 바꾸거나?마할로. --Ali'i 14:29, 2008년 5월 21일 (UTC)[응답]
• 반대 너무 많은 흰 공간이 뭉쳐져 있다.지금의 모습이 더 좋아 보인다. 2008년 5월 21일 14시 34분(UTC)[응답하라]
• 사이트 전체 JavaScript 해킹으로 반대. 변경하려면 MediaWiki에서 변경하십시오.Gracenotes^T § 14:57, 2008년 5월 21일 (UTC)[응답]

나는 그 제안이 바로 그것인 줄 알았다.Javascript 해결 방법을 피할 수 있도록 MediaWiki를 수정한다.내가 뭘 놓쳤나? --Ali'i 15:01, 2008년 5월 21일 (UTC)[응답하라]

아, 그 단락을 놓쳤나 보군 (아무것도 놓친 것 같지 않아, 아니);;;;;;;;;;;;;;;;;;;;;;;;GUI 변경에 대한 의견은 없지만 모노북 피부 변경으로 구현되면 문제가 없을 것이다.Gracenotes^T§ 15:18, 2008년 5월 21일 (UTC)[응답]

글쎄, 100% 자신이 없어서 완전히 틀렸을 수도 있다고 생각했어. :-) 마할로. --Ali'i 15:26, 2008년 5월 21일 (UTC)[응답]

• 지지하다.내가 보기엔 훨씬 직관적인 것 같아.칼다리 (대화) 2008년 5월 21일 (UTC) 16:02, 응답
• 반대 – 기본 페이지는 검색 페이지가 아니라 내용 페이지다.만약 우리가 그것을 검색 페이지로 만든다면, 우리는 인터페이스를 추악하게 바꾸기 보다는 아래 예시와 같은 코드를 포함할 것이다.니힐트레스^{t.l} 16:30, 2008년 5월 21일 (UTC)[응답하라]

• • 설명 - 검색 상자를 모든 페이지의 왼쪽 여백 맨 위로 이동하기 위한 제안이며, 위의 예는 단순히 예시일 뿐이다.검색 상자를 더 잘 보이는 곳으로 이동해도 기본 페이지의 특성이 바뀌지 않고 검색 페이지가 아니다.검색 상자는 어딘가로 가야 한다 - 이 질문은 단순히 어딘가에 있는 것에 관한 것이다. - 존 브레튼 (기침) 16:36, 2008년 5월 21일 (UTC)[응답]
    • 나는 위키피디아 사람들이 미학을 손상시키지 않고 가장 유용할 메인 페이지 상단의 검색 상자를 통합하는 방법을 찾을 수 있다고 믿는다; 그것은 확실히 몇 백만 페이지의 외관을 바꾸는 것보다 낫다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
• 댓글과 배경.위키백과 참조:마을 펌프(제안)/사이드바 재설계, "내비게이션"과 "상호작용" 상자 사이에 검색 상자를 두는 것(우리 모두가 좋아했지만 기술적으로 달성하기 어려워 보였다).가능하다면 나는 그것을 이상적인 것으로 지지할 것이다.
  그렇지 않다면, 나는 그것을 스택의 맨 위, 월텀과 에불라로 옮기자는 이 제안을 지지할 것이다. 게다가 우리의 검색 결과는 여전히 형편없다. -- 퀴디티 (대화) 18:13, 2008년 5월 21일 (UTC)[응답하라]
• 지지하다.나는 이런 방식이 더 좋다.위키피디아가 다른 무엇보다도 검색 가능한 백과사전임을 고려하면 더 말이 된다.셀라노르 22:21, 2008년 5월 21일 (UTC)[응답]
• 지지하다.그리고 덧붙여, 「검색」이라는 말을 더 크고 대담하게 할 수도 있다. --207.176.159.90 (대화) 23:54, 2008년 5월 21일 (UTC)[응답]
  • 코멘트 "검색"이라는 단어는 의미가 없다.그냥 없애버려.벌써 "검색"이라고 쓰여 있는 버튼이 있어.클러스터가 적으면 사실 신입 사원들이 일을 쉽게 할 수 있다.제이슨 퀸 (토크) 2008년 5월 31일 (UTC) 23시 30분[응답]
• 새로운 사용자가 알렉스 뮬러 06:00, 2008년 5월 22일(UTC)을 쉽게 찾을 수 있도록 이를 전적으로 지원하십시오.
• 다음과 같은 이유로 반대한다.
  • 기사 속 텍스트의 시작 부분 바로 옆에 놓이는 것은 오히려 산만할 것이다(위의 스크린샷이 그렇게 대표적이라고 생각하지 않는다, 이 변화가 모든 페이지에서 일어난다면).반면에, 그것의 현재 위치는 기사의 본문에 잘 들어가 있고, 따라서 페이지의 비 사이드바 부분보다 더 뚜렷하다.
  • 나는 검색창의 제안된 장소를 너무 높게 생각하여 검색 때마다 거의 맨 위로 시선을 보내게 한다.게다가, 스크롤을 통해 대부분의 페이지에서 쉽게 조정할 수 있는 현재의 위치와 대조적으로, 그것은 나에게 그것을 바꿀 수 있는 능력을 주지 않는다.또한, 현재 위치는 페이지 상단에서 상자에 도달하기 위해 스크롤을 필요로 하는 경우가 거의 없지만, 제안된 위치보다 하단에서 스크롤을 덜 필요로 한다는 점도 유념하고 싶다.
  • 검색창은 있는 그대로를 다소 구분하고 있으며, 나머지 사이드바는 긴 글머리표인 반면 검색창에는 긴 상자와 그 아래 두 개의 큰 단추가 있다.나는 그것이 눈에 보이는 것과 시청자의 주의를 흐트러뜨리지 않는 것 사이에서 완벽한 균형을 이룬다고 믿는다.사이드바는 신중해야 한다. 필요하면 그때 보면 된다.
  • 검색 상자가 사이드바의 처음 두 상자 위에 있으면 이 상자들의 링크보다 더 중요한 것처럼 보일 수 있는데, 이것이 꼭 사실인 것은 아니다.첫 번째 상자는 표준적인 검색 방법을 포함하고 있으며, 우리 독자층의 많은 부분을 위해 중요하고 유용하다.두 번째 페이지에는 "정보", 연락처 및 기부 페이지와 커뮤니티 포털을 비롯하여 매우 중요한 페이지가 포함되어 있다. 첫 번째 두 페이지는 비편집자에게 특히 중요하다.
  • 현재 검색 상자의 위치는 사이드바를 두 부분으로 나누는데, 거의 틀림없이 중요성과 용도가 다르다.처음 두 상자는 모든 위키백과 사용자들에게 중요하다; 도구 상자는 편집자들에 의해서만 사용되며 언어 상자는 다양한 요인이다.
  • 마지막으로 1!= 2. 제안서의 미적 측면이 마음에 들지 않는다. (그리고 감히 이 논쟁에 집중하지 마라... :-D) 월텀 공작 06:24, 2008년 5월 22일 (UTC)[응답하라]
• 지지하다.다른 웹 사이트에서 사용되는 탐색 원리와 일치하는 매우 합리적인 아이디어.그리고 니힐트레스에게 회신하면서 메인 페이지가 "검색" 페이지뿐만 아니라 "내용" 페이지가 아니라면 검색 페이지가 무엇인지 궁금하다.그것은 다소 과장된 진술이다. 분명히 둘 다다다. –외부조사 10:33, 2008년 5월 22일 (UTC)[응답]

  나는 특별함을 제안하고 싶다.좋은 예로 검색과 구글을 들 수 있다.니힐트레스^{t.l} 14:29, 2008년 5월 22일 (UTC)[응답]

• 지지하다.그 사이트에 익숙하지 않은 독자들의 삶이 더 편해질 것이라고 의심하고 있기 때문이다.케임브리지베이날씨 고릴라 2008년 5월 22일 14:25 (UTC)[응답하라]
• 반대 현재 위치는 괜찮다; 사용자가 너무 쉽게 헷갈려 알아낼 수 없다면 상자를 위로 옮기는 것은 도움이 되지 않는다(그리고 그것은 이미 문턱을 넘어섰기 때문에 작은 화면에서도 볼 수 있다).이동하면 다른 모든 섹션(내비게이션, 상호 작용, 도구 상자, 언어)이 함께 묶이고 검색 상자가 가운데에 있으면 사이드바가 시각적으로 더 뚜렷하게 표시되도록 하는 데 도움이 된다.하지만 나는 그것이 기계에 안성맞춤일 것이라고 생각한다.EVULA // talk // talk // 14:42, 2008년 5월 22일 (UTC)[응답]
• 반대하라. 나는 이 문제에 대해 반대자들과 함께 할 것이다. 그들은 나를 설득했다.탐색과 상호작용은 검색창만큼이나 중요하며, 현재 위치는 로고가 올라갈 때보다 더 눈에 띄고 특색 있는 곳이라고 생각한다.나에게 있어, 그것은 위키백과의 기본 피부를 위키백과처럼 보이게 하는 것의 일부분이다.파워스 18:27, 2008년 5월 22일 (UTC)[응답]
• 서포트는 내가 새로운 포맷을 시도해왔고, 그것은 모든 면에서 더 좋다.더 보기 좋고 더 논리적으로 배치되어 있어.그리고 다른 논평에서 언급했듯이, 모바일 기기가 그것을 더 높게 하는 것이 중요하다.제이슨 퀸 (토크) 2008년 5월 31일 (UTC) 23시 30분[응답]

• 토론 확장

개인적으로 나는 현재 위치가 특집 기사 사진 근처에 있기 때문에 선호하지만, 원한다면 다른 위치를 시도해봐.진짜 문제는 메인 페이지가 너무 길어서 아래로 편집해야 한다는 것이다.이것은 매우 까다로운 수술이다. 왜냐하면 모든 사람들이 그들이 가장 좋아하는 링크를 가질 것이기 때문이다!하지만 그 방법은 예를 들어, 나는 대부분 피처링 그림을 보는 것조차 기억하지 못한다.다른 언어에 대해서는 「로컬 대사관」 링크, 하단의 타 언어의 기사 수 목록, 타 언어의 사이드바 등 3개 섹션이 있다.(그런데 나는 볼라푸크처럼 미친 언어를 메인 리스트에서 다듬는 방법을 찾아야 한다고 생각한다; 10만개 이상의 기사가 열거되어 있는 것으로 알고 있지만, 기사 수와 실제 독자의 수를 바탕으로 목록을 다듬는 방법이 있어야 한다; 또한 중국어는 하위 리스트보다는 상위권에 있어야 한다.)

문제는 의미 있는 편집을 시작할 방법이 필요하다는 점이다.대체 메인 페이지 버전이 매우 광범위한 승인 시험에서 서로 경쟁할 수 있는 어떤 방법이 있어야 한다.예를 들어, 만약 사람들이 자신의 선호에 "위키피디아 홈 페이지"를 설정할 수 있다면, 일단 로그인한 다른 사람들은 다른 메인 페이지를 볼 수 있고, 때로는 포털이나 위키피디아 대상을 사용하고, 때로는 메인 페이지의 대체 개발 버전을 사용할 수도 있다.이 통계는 위키 전체에 걸친 승인 투표나 하루 동안 테스트를 받을 수 있는 특정 개발 버전을 선호하기 시작할 것이다.Wnt (토크) 15:51, 2008년 5월 22일 (UTC)[응답]

이 스레드는 기본 페이지가 아니라 사이드바에 대한 것이다.단, 위키백과 참조:메인 페이지 변형을 위한 메인 페이지 대체품, 그리고 디폴트로 만드는 js 코드. -- Quidity (대화) 18:26, 2008년 5월 22일 (UTC)[응답]

지적해줘서 고마워그래도 대부분의 사용자들이 ".js"를 보는 순간 더 이상 고려하지 않고 구제해 줄 것이라고 생각한다.또한, 각 버전을 얼마나 많이 사용하는지에 대한 통계를 수집할 수 있는 방법은 없을까?Wnt (토크) 16:44, 2008년 5월 23일 (UTC)[응답]

http://stats.grok.se/ 참조(예: [5]. -- Quiddity(대화) 17:52, 2008년 5월 23일(UTC)[응답]

이봐, 그건 편리한 도구야 - 고마워!사용자 간의 재로드 횟수의 차이가 다소 결과를 왜곡할 수 있지만, 통계 수집을 위한 특별한 방법은 필요하지 않을 것 같다.Wnt (토크) 14:09, 2008년 5월 26일 (UTC)[응답]

• 반대—오랜만에 가장 멋진 생각.그것의 현재 위치는 당신이 처음에 그리고 더 아래로 스크롤한 두 가지 모두에 접근할 수 있게 해준다.토니(토크) 02:18, 2008년 5월 23일 (UTC)[응답]
  • 몰라... 대부분 기사를 읽고 있을 때, 어쨌든 검색창으로 돌아가려면 스크롤을 올려야 해.
    • 그것은 기사의 길이에 따라 달라진다; 모든 기사가 한 페이지보다 길지는 않다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
  • 검색창도 하원이 하는 것처럼 메인 페이지에 추가해 더 두드러지게 만들 수도 있다(그들은 'Go' 버튼을 숨기고 그냥 'Search' 버튼만 남겨두지만).그게 더 나을까?—2008년 5월 23일 03:20, (UTC)[응답]이라는 점을 기억하십시오.
  • 코멘트 인수는 매우 구체적인 기사 크기에 대해서만 적용된다.사실, 스크롤 막대를 항상 위쪽으로 빠르게 끌어서 검색 상자가 보일 것이라는 것을 알 수 있기 때문에 긴 기사(수 많은 기사)에서는 실패하지만, 반면 저해상도 디스플레이의 가운데에는 스크롤 막대를 사용하여 한 페이지 아래로 내려가야 할 수도 있다.제이슨 퀸 (토크) 2008년 5월 31일 (UTC) 23시 30분[응답]
• 지원, 실제 현재 위치에 대한 불만이 제기되었으므로(실드 상단에 있는 링크 참조).당신은 사이드바를 평상시의 방문자가 하는 것처럼 보고 그들이 사이드바와 다른 사이트의 상황별 광고와 비슷하게 보이고 위치하기 때문에 그것과 많은 링크에 눈이 멀다는 것을 깨달아야 한다.나는 사람들이 정부 웹사이트에서 무언가를 찾도록 요청받았고 거의 모든 사람들이 정확히 무엇을 찾으라는 지에 대한 링크를 완전히 무시했던 연구를 본 기억이 있다. 왜냐하면 그것은 광고 논리가 들어가지도 않고 정부 사이트에 광고도 없는 것처럼 보이기 때문이다.그것을 퍼즐 지구본 바로 아래에 놓는 것은 새로운 방문객들을 위해 훨씬 더 쉽게 찾을 수 있게 해줄 것이다- 사람들은 로고를 보통 항해 보조 도구이기 때문에 로고를 본다.나는 또한 좀 더 두드러지게 만들기 위해 상자 위에 "검색"이라는 단어를 대담하게 써보라고 충고하고 싶다.나는 Common의 메인 페이지에 있는 검색 상자가 설치되는 방식이 마음에 들지 않는다. 그것은 나에게 끔찍하게 보인다.어쨌든 그건 내 두 푼이다.—ashanda (talk) 01:04, 2008년 5월 24일 (UTC)[응답]
  • 위키피디아 로고는 어쨌든 크고 굵은 글씨를 가지고 있기 때문에 과감한 검색은 도움이 되지 않을 것이다.기본적으로 사용자가 검색 상자가 어디에 있는지 아는 데 필요한 것은 한 번이고, 메인 페이지에 눈에 띄는 상자가 있으면 검색 기능이 있다는 것을 알게 되어 바로 찾을 수 없더라도 다른 페이지에서 검색하도록 할 것이다.그리고 그들은 사이드바를 제외하고 어디를 볼 것인가?그들이 사이드바를 볼 생각을 하는 한, 그들은 그것을 바로 볼 것이다. 사이드바 안에서 검색 상자는 다소 독특하다.나는 하원의 해결책이 다소 추악하다는 것에 동의하지만, 우리가 이런 식으로 할 필요는 없다.나는 맨 위 상자 아래에 페이지 너비의 좁은 막대를 생각하는데, 그것은 페이지의 레이아웃을 방해하거나 모양을 망치지 않고 유용할 것이다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
  • 코멘트 No 그냥 월드 검색 제거...버튼이 이미 말해주듯이 중복되어 있어제이슨 퀸 (토크) 2008년 5월 31일 (UTC) 23시 30분[응답]
• 지원 - 대부분의 사람들이 방문할 때 가장 먼저 하고 싶은 것은 검색이므로 검색 상자를 맨 위에 더 가까이 두는 것이 타당하다.– FISDOF9 04:40, 2008년 5월 24일(UTC)[응답]
• 댓글(사실 나는 이것을 지지하지만, 투표하는 것처럼 보이고 싶지 않다. 나는 반대자이기 때문에 거절당하지 않기 때문이다.)중요한 점은 나 같은 사용자가 소형 화면(내 Asus Eee PC에 800x480)을 사용하고 현재 스크롤 없이 검색창을 볼 수 없다는 것이다.---82.148.54.195 (대화) 12:43, 2008년 5월 24일 (UTC)[응답]
• 검색에 도움이 되는 모든 항목을 지원하십시오.포털 대신 "Welcome to Wikipedia"(Welcome to Wikipedia) 옆에 있는 검색 상자를 보고 싶어 죽겠다.예술, 전기 등) 레나타 (토크) 21:44, 2008년 5월 24일 (UTC)[응답]
  • 내가 지지해 주겠다(레나타가 죽은 것도 나쁘지 않을 것이다).그러나 포털이 교체되는 것을 보고 싶지는 않지만, 검색창을 포함시키는 것은 분명히 도움이 될 것이다; 맨 위 상자 아래에 굵은 문구를 가진 길고 좁은 막대가 메인 페이지의 레이아웃과 형식에 큰 영향을 미치지 않을 것이다.아래 몇 개의 글머리 기호를 참조하십시오.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
• 지원 - 위키피디아의 두 가지 주요 활동은 "검색과 검색"이다.그들이 가장 우호적인 곳에 올라가야 한다는 것은 이치에 맞는다.검색 후 탐색(찾아보기)해도 괜찮다.트랜스휴머니스트 22:37, 2008년 5월 24일 (UTC)[응답]
  • 내가 아래에 말하고 다시 말했듯이, 사이드바의 윗부분은 사이드바의 다른 어떤 장소와 크게 다르지 않으며, 검색 상자를 옮기는 것은 단순한 재조정보다 더 많은 결과를 가져온다; 그것은 그것의 전체적인 모양과 사람들이 보는 관점을 바꾼다.그러나 메인 페이지의 상단은 훨씬 더 두드러지고, 실제로 그 페이지에서 가장 먼저 보게 될 곳이며, 이것은 사이드바로서는 의심스럽다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
  • 나는 로고 아래 검색 상자가 더 눈에 띈다는 것에 동의하지 않는다.나는 사실 로고가 위쪽에 있는 것보다 지금 어디에 있는지가 더 눈에 띈다고 주장할 것이다.지금과 같이 사용자의 캐주얼한 눈초리는 왼쪽 사이드바를 따라 "원형 사물, 텍스트 블록, 텍스트 블록의 중단, 텍스트 블록"을 본다.편집 박스가 위로 이동하면, 무심코 보거나 주변 시야에서 로고와 잘 어울릴까 봐 두렵다.그것이 "문자 차단"을 방해하는 것은 그것을 더욱 돋보이게 한다.파워스^T 13:49, 2008년 5월 25일 (UTC)[응답]
    • 그러나 실제로는 새로운 사용자들이 사이드 바의 링크 테이블이 일련의 상황별 광고처럼 보이고 배너 실명 때문에 무시되기 때문에 실제로 "관심"조차 하지 않는다.나는 n00bs가 내게 이메일을 보내서 사이드바에서 링크된 것을 어떻게 할 것인지 물어보라고 했고, 나는 그들에게 랜드마크와 그들이 찾고 있는 것을 찾기 위해 얼마나 많은 링크를 세어야 하는지 등 구체적인 방향을 알려줘야 했다.검색 상자를 "흰색 상자"와 로고 사이에 놓는 것은 확실히 새로운 사람들에게 그것을 더 잘 보이게 할 것이다.—ashanda (talk) 14:20, 2008년 5월 25일 (UTC)[응답]
      • "확실히"에 대해서는 잘 모르지만 -- 현수막 맹목적인 것은 이해하지만, 그것을 깨는 역할을 하는 것이 바로 검색창의 현재 위치라고 생각한다.그것을 옮기는 것은 문제를 완화시키기보다는 악화시킬 수 있다.파워스 14:50, 2008년 5월 25일 (UTC)[응답]
      • 사실, 그것은 사이드바에 더 많은 관심을 끌 것이라고 전혀 확신하지 않는다.또한 사람들이 책 페이지와 같은 웹 페이지를 위에서 아래로 매우 합리적인 순서로 읽는 것도 확실하지 않다.그들은 깨지는 패턴과 같은 이미지, 큰 제목, 그리고 다른 독특한 특징에 초점을 맞춘다.로고는 바로 구석에 있다; 사람들이 그것을 보더라도, 그들은 검색 상자가 크고 대담한 위키백과 옆에 없어질 것이기 때문에 검색 상자가 바로 아래에 있더라도 무시하는 편이 나을 것이다.그리고 사이드바는 가장 눈에 띄지 않을 것이다. 왜냐하면 그것은 단지 길고 대부분 특징 없는 링크의 열일 것이기 때문이다.2008년 5월 26일 (UTC) 02:11의 공작 월섬[응답]
• 지원 이것은 사용자의 기대와 더욱 밀접하게 일치할 것이다.비록 오른쪽 상단 모서리가 아마도 가장 일반적인 것일지라도, 기본적으로 지구의 모든 사이트는 맨 위에서 그것을 한다.사실, 나는 페이지 탭 바로 위에서 그것을 하는 것이 가장 좋을 것이라고 생각한다.DGG (대화) 00:22, 2008년 5월 25일 (UTC)[응답]
  • 메인 페이지(어쨌든 가장 중요한 페이지)만을 위한 것이기는 하지만, 이것이 내가 제안하는 것이다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
• 의견 – 위키백과에서 검색하는 방법을 찾는 것이 그렇게 중요하다면, 위키백과 입구의 주요 포털인 메인 페이지에 검색 상자가 상단을 포함한 사이드바의 어느 곳보다 훨씬 두드러지는 이유는 무엇인가?레나타의 생각은 화려하고, 그렇지 않으면 전혀 무관한 커먼즈 메인 페이지의 레이아웃에 대한 언급과 일맥상통한다.사람들이 이 페이지를 찾기 위해 검색하는 방법을 알고 있거나 구글이나 다른 검색 엔진에서 검색하는 방법을 알고 있기 때문에, 다른 모든 페이지에서는 그렇게 큰 문제가 되지 않는다.개인적으로 나는 현상유지를 선호하지만, 만약 정말로 문제가 있다면, 이것은 사이드바 박스의 그룹화나 검색 상자의 잔고가 너무 높지도 낮지도 않은 것을 망치지 않고, 가는 길이다.2008년 5월 25일 (UTC) 01:37의 공작 월섬[응답]
  • 그렇다면 메인 페이지의 검색 상자는 어디에 두시겠습니까? — 2008년 5월 25일(UTC)이라는 점을^(talk) 기억하십시오[응답하라].
    • 맨 위 상자 바로 아래에 있는 한 줄짜리 페이지 크기의 상자("Welcome to Wikipedia", 포털 링크 등)를 생각하고 있다.페이지에 많은 영향을 주기에는 너무 좁지만, 그것은 여전히 눈에 띄는 위치, 그리고 아마도 약간 다른 색상으로 인해 주목을 받을 것이다.(상자가 "개요", "내용" 및 기타 링크 위나 아래 어느 쪽이 좋을지 아직 결정하지 못했지만, 아래가 좋을 것 같다.)왼쪽에는 "검색 위키백과"라고 쓰여 있고, 그 문구의 오른쪽에는 "검색" 버튼과 "검색" 버튼이 있고, 오른쪽 끝에는 "검색" 버튼이 있을 것이다. 그렇지 않으면 몇 가지 차이점이 있을 수 있다.세부적인 사항은 논의의 여지가 있지만, 이것이 일반적인 생각이다.페이지나 사이드바에 부정적인 영향을 주지 않고 가장 중요한 페이지의 눈에 띄는 상자.2008년 5월 25일 (UTC) 03:33의 공작 월섬[응답]
      • 자, 내가 검색 상자를 메인 페이지에 추가하기를 주저하는 이유 중 하나는, 검색 상자가 메인 페이지에 두 개 있다는 것을 의미하기 때문인데, 검색 상자는 눈에 띄는 검색 상자와 사이드바에는 일반 검색 상자는 검색 상단은 검색 상자는 검색 상자로 표시되고 사이드바에는 일반 검색 상자로 표시되기 때문이다.프로답지 못한 것 같은데...검색 상자가 모든 페이지에서 쉽게 찾을 수 있는 위치에 있다면 더욱 일관되고 쉽게 찾을 수 있지 않을까?—2008년 5월 25일 03:38, 점 기억^(talk)[응답]
        • 두 개의 검색 상자가 있을 것이다. 비록 나는 일반적으로 이중화를 좋아하지 않지만, 나는 이 정도의 문제를 발견하지 못한다. 특히 우리가 그것을 "특별하게" 만들 수 있는 상위 검색 상자에 어떤 종류의 추가 기능을 포함시킨다면 더욱 그렇다.요점은 두 가지다. 첫째, 사이드바에서 윗부분이 검색 상자를 훨씬 더 잘 보이게 할 수 있을지 의문이다. 둘째, 검색 상자가 사이드바에 더 많은 관심을 끌 수 있는 문제인 것이다. 현재 위치에서는 검색 상자가 사이드바를 고정하는 것과 같은 역할을 한다.그것을 잘 정의된 두 부분으로 나누면, 첫 번째 부분은 항상 동일하고 두 번째 부분은 변경될 수 있다.상자를 위쪽으로 옮기면 사이드바의 다른 모든 요소들이 뭉쳐져 있을 겁니다. 회색 질량이고 구별할 수 없는 것이었죠. 모든 것이 현재의 고체 형태 대신에 길고 희미하게 보이는 선처럼 보일 겁니다.그리고 물론 내가 주된 반대론(스크롤링, 의미론 등)에서 내세웠던 다른 주장들도 있다.2008년 5월 25일 (UTC) 05:15의 공작 월섬[응답]
        • 업데이트 – 기본 페이지에는 다른 부분이 중복되어 있다. 상단 상자 아래의 8개 링크 중 대부분은 일반 정보와 검색 방법에 연결되며, 4개는 이미 사이드바에 있다.메인 페이지에서는 중복성이 그렇게 심각하게 고려되어서는 안 된다고 생각한다.
          • 내가 이 아이디어에 대해 좋아하지 않는 것은 새로운 독자들의 탐색을 방해할 수 있다는 것이다. 왜냐하면 그들은 모든 페이지의 검색 상자를 결코 눈치채지 못할 것이고 그들이 검색하고 싶을 때마다 메인 페이지로 돌아가야 한다고 생각하기 때문이다.게다가 메인페이지의 작은 변화조차도 합의가 된 것처럼 보여도 많은 드라마가 수반되는 것 같다.—ashanda (talk) 14:20, 2008년 5월 25일 (UTC)[응답]
            • 그것이 바로 우리가 메인 페이지 재설계 동안에 이 제안을 실행하지 않은 이유야.구체적으로 위키백과 대화를 참조하십시오.WikiProject 사용성/메인 페이지/도면/검색 상자 폴링과 많은 토론 쓰레드.
              그러나 새로운 예제를 실험하고 싶다면, 위키백과를 수정해 보십시오.기본 페이지 대안(검색 상자) (아마도 위키백과의 요소 사용:WikiProject 사용성/메인 페이지/초안 추가 검색 상자2).그게 도움이 되길 바래. -- 퀴디티 (대화) 20:42, 2008년 5월 25일 (UTC)[응답]
              • 아사다, 우리는 그 바에서 모든 과정을 설명하면서 검색에 대한 도움말 페이지 링크를 줄 수 있다.많은 독자들은 비록 그 상자를 찾았다고 해도 위키피디아에서 검색이 어떻게 작용하는지에 대해 당황하는 것 같다.그건 그렇고, 꽤 어렵게 들리네사이드바는 페이지마다 변하지 않는 몇 안 되는 것들 중 하나이다. 사람들은 언젠가 그것을 알아차리기 마련이다.드라마에 대해서...만약 그 주장이 충분히 설득력이 있다면, 그들은 승리해야 한다.모든 페이지에 나타나는 요소보다 기본 페이지를 변경하기가 더 어려운 이유는 무엇인가?어쨌든, 나는 지금 여론조사를 보고, 주요 주장은 다음과 같다.
                1. "이것은 사이드바 박스에서 멀어진다." (이것은 사람들이 그것을 알아차린다는 것을 나타낼 것이다.)
                2. "검색 기능을 너무 중요하게 보이게 한다."(검색 상자를 더 눈에 띄게 만들려는 어떤 시도에도 사용할 수 있다).
                3. "메인 페이지의 레이아웃을 방해한다"(특정 제안에만 관련됨).
                4. "중복" "다른 상자보다 한 상자에 특별한 무언가가 있다고 생각하게 만들 것"
                5. "다음 페이지에서 사라지기 때문에 독자들을 혼란스럽게 한다."
              • 마지막 두 총알은 가장 설득력 있는 주장을 담고 있다고 나는 믿는다.단, 116개의 추가 박스 지원 중에서 1개의 사이드바를 위로 옮기는 것을 언급했을 뿐이고, 131개의 반대론자로부터 다시 한번 그러한 제안은 단 한 가지였다는 점을 유념해야 한다.그것과는 별개로, 그 논평은 그 상자를 더욱 돋보이게 만드는 쪽으로 방향을 잡은 것 같다.내가 기꺼이 (물론 수단에 따라) 지지할 용의가 있지만, 상자를 위로 옮기는 것은 단순히 사이드바를 망칠 뿐이다.2008년 5월 26일 (UTC) 02:11의 공작 월섬[응답]
• 지원, 가장 중요한 내비게이션 요소(또는 브라우징 요소라고 해야 할까...)는 새로운 사용자가 실제로 찾는 곳이어야 한다(현재, 작은 링크의 정글에서 놓치기 쉽다).나는 또한 검색 양식 위의 '검색' 제목을 삭제하기를 제안한다. 검색 버튼은 중복되어 있고, 검색 기능이 없는 것이 훨씬 더 보기 좋다.Cacycle (talk) 01:06, 2008년 5월 26일 (UTC)[응답하라]

검색창은 "작은 링크" (일단, 사이드바 너비가 넓고 파란색이 전혀 없다)와 완전히 다른데, 사이드바 패턴의 독특한 깨짐, 어떻게 놓칠 수 있을까?그리고 제안된 장소를 "새로운 사용자가 실제로 찾을 수 있는 곳"으로 만드는 것은 무엇인가?솔직히 말해서, 나는 그것이 어디에서 왔는지 알고 싶다.어떤 경우에도 "검색" 헤딩은 일관성을 보장하는 것과 별개로 검색 상자를 더 잘 분리하여 더 많은 공간을 제공하도록 돕는다.나는 위에서도 그것이 유용하지 않을지 잘 모르겠다; 제목이 전혀 없고 아래 버튼이 두 개만 있는 상자는 로고 아래에서도 완전히 이상하게 보일 것이다.2008년 5월 26일 (UTC) 02:11의 공작 월섬[응답]

정확히 "검색 상자는 "작은 링크"와 완전히 다르기 때문에 (새 사용자의 경우 또는 거의 무관한) 링크와 상자를 혼합해서는 안 된다.그리고 내게는 내가 사용성에 대해 읽은 것으로 보아 로고가 사용자의 주의를 끌 수 있는 가장 두드러진 장소인 반면 시각적으로 비약적인 장소의 작은 텍스트와 링크 목록에 숨겨진 요소는 거의 확실히 새로운 방문자에 의해 놓칠 것이다.Cacycle (대화) 03:14, 2008년 5월 27일 (UTC)[응답]

링크가 박스로 조직되어 서로 분리되어 있는데 어떻게 그것을 "상자화"라고 부를 수 있는가?그리고 반복 패턴을 깨는 상자가 로고의 그림자에서 잃어버린 다른 상자보다 더 눈길을 끄는 것이라고는 믿지 않더라도, 당신은 정말로 검색 상자의 움직임이 이 반복을 강조하고 사이드바를 더 적게 끌게 함으로써 나머지 사이드바의 모양에 해로운 영향을 미치지 않는다고 생각하는가?나는 비록 검색창에 작은 이득을 가져다 주기는 하지만, 이러한 움직임은 위키피디아에 있는 모든 페이지의 전체 사이드바의 레이아웃과 그것을 통해 부정적인 영향을 미칠 것이라고 주장한다.정말 그럴 만한 가치가 있을까?그리고 그 작은 이득은 아래 Quiddity가 제안한 것처럼 검색 상자에 색을 입힘으로써 훨씬 더 고통 없이 만들어질 수 있었다.시끄러운 소리 말고...눈치채기에 충분할 정도로, 의심스러울 정도로 유익한 움직임보다 더 나은 보장.2008년 5월 27일(UTC) 19:37의 공작 월섬[응답]

• 반대 또는 조건부 지원.나는 그것이 지금 있는 곳에 익숙하다.변경하지 않는 것이 좋겠지만, 만약 있다면 Preferences(기본 설정)에 다시 넣을 수 있는 옵션이 있어야 한다.레이와스92^Talk 16:33, 2008년 5월 26일 (UTC)[응답]
  • 기기는 이전 위치에 익숙한 숙련된 사용자를 위해 사용할 수 있게 될 것이다.—2008년 5월 26일 점^(talk) 기억[응답]
    • 그리고 만약 이것이 통과된다면 나는 그것을 사용할 작정이다.하지만, 나는 어딘가에서 다운로드가 지연될 거라고 들었어.진짜예요?2008년 5월 27일 (UTC) 00:26, 월텀 공작[응답]

사실이 아니다 :-) Cacycle (대화) 03:14, 2008년 5월 27일 (UTC)[응답하라]

• 반대 - 지금 이대로가 더 좋다. - • 자이언트 퍼핀 • 21:52, 2008년 5월 26일 (UTC)[응답]

내 생각에 요점은 우리 모두가 그것을 어떻게 더 좋아하느냐에 대한 것이 아니라, 우리가 새로운 방문객들을 위한 삶을 어떻게 더 쉽게 만들 수 있느냐에 대한 것이라고 생각한다.Cacycle (대화) 03:14, 2008년 5월 27일 (UTC)[응답]

• 중립 나는 검색 상자가 있는 곳에 만족하지만, 별로 신경 안 써.나는 검색 상자의 위치가 모든 위키미디어 위키에서 일관되도록 신경을 쓴다. 왜냐하면 나는 다른 곳에서 활동하고 있고 외국어로 된 인터페이스와 함께 편안한 수준에 의존하기 때문이다.나는 천가지 다른 위키에서 인터페이스를 바꾸는 것은 가치가 없다고 생각한다. 그래서 내가 제안하는 것은, 어떤 것도 굳이 바꾸지 말라는 것이다.샬롬 (Hello • Peace) 03:41, 2008년 5월 27일 (UTC)[응답]
• 약한 반대 - 일반적인 웹 상호작용 규약(유용성의 큰 부분을 차지하는 유사성)에 더 잘 부합하고 특정 주제에 대한 정보를 찾는 사용자에게 매우 도움이 되기 때문에, 나는 일반적으로 이 규칙을 강력히 지지한다.반면에, 현재의 검색은 여러분이 검색하기에 적합한 용어를 정확히 알지 않는 한 상당히 쓸모없는 것이다; 그리고 더 나쁜 것은, "검색" 대신에 "찾아가는" 것을 사용하는 사람들에게 매우 혼란스러울 수 있다.
• 서포트는 내게 좋은 것 같다.누가 그런 사소한 변화를 반대하겠는가 하는 것은 내 능력 밖이다...캐시 박사 (토크) 00:17, 2008년 5월 28일 (UTC)[응답]
  • 로고에서 "툴박스" 라벨에 이르기까지 화면의 왼쪽 상단 부분은 (아마도 "책" 배경과 함께) 위키백과의 수백만 페이지 중 어느 한 페이지에서도 조금도 변하지 않는 인터페이스의 유일한 부분이다.그것은 가장 다양한 페이지들 사이의 연결 쓰레드 역할을 하며, 모든 사람들이 인식하고 자주 사용하는 하나의 상수 요소다.그 부분에 대한 사소한 변화라도 논의의 대상이 될 것이고 또 그래야 한다.그렇긴 하지만, 내 생각에 이것은 독자와 편집자의 탐색적 경험뿐만 아니라 전체 사이드바의 모양에도 영향을 미칠 것이라는 점을 고려하면 분명 사소한 변화는 아니다.그 조치는 사소한 것이 아닌 결과를 수반할 것이다.2008년 5월 28일 (UTC) 20:27의 공작 월섬[응답]
• 지원 - 방문자와 편집자 모두에게 삶을 훨씬 더 쉽게 만들 수 있고, 구현하기도 쉽다.나는 "나는 그것이 있는 곳에 익숙하다"는 것이 반대할 좋은 이유라고 생각하지 않는다 - 우리는 곧 새로운 입장에 익숙해질 것이다.Waggers (대화) 09:55, 2008년 5월 29일 (UTC)[응답]
• 지지하다.훌륭한 아이디어다: 전체적인 레이아웃이 더욱 일관적으로 느껴지고, 검색창에 접근하기가 더 쉽다. -- 아노메(토크) 23:58, 2008년 5월 29일 (UTC)[응답]
  • 좀 더 자세히 설명해 주시겠습니까?나는 일관성에 대한 코멘트를 이해하지 못했다.2008년 5월 30일 (UTC) 15:41, 월텀 공작 (Waltham, The Duke of the Duke, 2008년 5월 30일 (UTC)
• 의견 – 미리 보기 없이 저장을 누르면 검색 페이지로 이동되는 이유를 아는 사람이 있는가? (기록상 Wiki의 미리 보기 도구를 사용한다.)그것은 오직 이 실에서만 일어난다.2008년 5월 30일 (UTC) 15:41, 월텀 공작 (Waltham, The Duke of the Duke, 2008년 5월 30일 (UTC)
• 지지하다.일반 사용자로서, 그리고 가끔씩만 기고하는 사람으로서, 나는 아주 오랫동안 현재의 배치에 짜증이 났다.제안자의 말처럼, 사람들이 가장 먼저 사용하고 싶지만 현재 숨겨져 있고 모바일 기기에서 위키피디아에 접속하고 있다면 정말 귀찮은 일이다.살루톤 (대화) 21:15, 2008년 5월 30일 (UTC)[응답]
• 지지하다.노트북으로 컨퍼런스와 일반 사용자들로부터 여러 번 들은 요청이다.그들은 검색을 할 때마다 위아래로 스크롤하는 것을 싫어한다.Anthere (대화) 10:09, 2008년 6월 1일 (UTC)[응답]
  • 나는 이 제안이 어떻게 그들에게 도움이 되는지 모르겠다; 검색창을 올리면 그들은 훨씬 더 자주 스크롤을 올려야 할 것이다.파워스^T 22:24, 2008년 6월 1일 (UTC)[응답]
    • 이것은 어떤 사람이 그 페이지와 함께 박스 이동을 제안하는 것으로 이어질 것이다.Rgodermote 00:54, 2008년 6월 2일 (UTC)[응답]
• 모든 것을 지지하라 그것은 간단한 움직임이다.술집을 찾는 데 문제가 있는 사람들을 도울 뿐만 아니라사람들이 술집을 찾으려고 애쓰는 걸 봤지Rgodermote 00:54, 2008년 6월 2일 (UTC)[응답]
  • 나는 이 제안이 어떻게 도움이 되는지 모르겠다.검색대가 로고 밑에 있으면 더 쉽게 찾을 수 있다는 증거가 있으십니까?주관적으로, 내가 보기엔 그곳이 덜 눈에 띄는 것 같다.파워스 12:13, 2008년 6월 2일 (UTC)[응답]
• Per Powers와 Waltham 공작에 반대하십시오.있는 그대로 유지해라.아니면 바꾸거나.그러나 어느 쪽이든 그것은 선택사항이 되어야 한다.펠리스레오^Talk! 11:48, 2008년 6월 3일 (UTC)[응답]
• 코멘트 나는 그것을 위쪽으로 옮기는 것이 지금 있는 곳보다 낫다고 생각하지만, 나는 제안서 15에서 훨씬 이전처럼 내비게이션의 아래쪽에 더 좋은 장소가 있다고 생각한다.이것이 가능한가?만약 그렇다면 누군가가 나에게 내 개인 모노북에 넣을 코드를 줄 수 있다면 나는 매우 감사할 것이다.js 페이지 Redekopmark (대화) 22:00, 2008년 6월 3일 (UTC)[응답]
• 약한 반대 나는 이것이 문제를 찾는 해결책이라고 생각한다.검색대가 너무 낮은 100픽셀은 문제될 게 없다.고장나지 않았다면 고치지 마.파라곤12321 (대화) 03:00, 2008년 6월 4일 (UTC)[응답]
• 중립 다시 움직일 수 있는 장치가 있는 한, 나는 어느 쪽이든 행복하다.shoy 13:17, 2008년 6월 4일 (UTC)[응답하라]
• 참조 데스크 모니터로서 지원, 위키피디아에서 사용자들이 질문에 대한 답을 검색하도록 격려할 필요가 있다는 것은 명백하다.많은 경우에 우리는 이미 그들의 질문에 직접 답하는 기사를 가지고 있다.ike9898 (대화) 14:44, 2008년 6월 4일 (UTC)[응답]
• 지지 - 좋고 논리적인 생각인 것 같다.스카리안^{Call me Pat!} 15:05, 2008년 6월 4일 (UTC)[응답]
• 반대하라. 나는 왜 그것이 움직여야 하는지 모르겠다.나는 이전에 그것을 찾을 수 없었다고 불평하는 사람은 실제로 들어본 적이 없어서 나는 변화를 줄 필요가 있는지 확신할 수 없다.또한, 내 눈에는 최상위 rb000의 위키백과 로고와 충돌하는 것처럼 보인다 —Rb000이 추가한 서명되지 않은 코멘트 작성 (대화 • 기여) 05:01, 2008년 6월 5일 (UTC)[응답]
• 참고: 네비게이션과 상호 작용 상자 사이에 있는 내용을 보려면 다음을 추가하십시오.

addOnloadHook(함수(){document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.GetElementById("p-interaction") }

당신의 monobook.js Redekopmark (대화) 05:39, 2008년 6월 5일 (UTC)[응답하라]

• 네비게이션과 인터랙션 상자 사이의 코멘트 나는 괜찮다.또한 굵은 선이나 로고와 검색창 사이에 어떤 다른 형태의 분리가 나의 걱정을 덜어줄 것이다.나는 현재 위치가 실제로 어떻게 누군가를 혼란스럽게 했는지 구체적인 예를 제공할 수 있다면 이사 건은 훨씬 더 강력할 것이라고 생각한다 —2008년 6월 5일 (UTC) 23:17에 코멘트가 추가되었다[응답].
• 지원 새 위치가 내게 더 좋아 보인다.또한, 새로운 사용자들로부터 검색 상자를 보지 못했기 때문에 위키백과를 검색하는 방법을 물었다.변화로 인해 더욱 가시성이 높아진다.--바나나 (토크) 00:15, 2008년 6월 6일 (UTC)[응답]
• 지원 - 검색 상자는 위키피디아에서 가장 많이 사용되는 기능이다.페이지 왼쪽에 있는 거의 모든 것은 비편집자들에게 게걸스러운 말들이다.현재 검색 상자 위에 있는 "current events"나 "community portal"보다 훨씬 더 많이 사용된다. 모낙토크 05:42, 2008년 6월 6일 (UTC)[응답]
  • 사실 처음 두 상자의 링크("내비게이션"과 "상호작용")의 절반은 독자들에게 꽤 중요하다.그리고 사용 빈도는 정말 중요한 요소가 아니다; 독자의 눈이 모니터 상단에서 가장 작은 거리를 덮는 것이 아니라 바로 상자까지 갈 수 있는 것이 중요하다.빛은 가장 직선적인 길이 아니라 가장 빠른 길로부터 흐른다; 이것은 비슷하다.2008년 6월 18일 (UTC) 01:22의 공작 월섬 (Walthaltham, The Duke of 01:22
• 지원. --Wikinaut (대화) 13:13, 2008년 6월 6일 (UTC)[응답]
• 위의 EVula와 LtPowers에 따라 반대하십시오.이들의 말처럼 검색창은 누구나 사용할 수 있는 탐색/인터랙트 박스와 편집자가 주로 사용하는 툴박스를 명확히 구분해 준다.검색 상자가 현재 위치에 있지 않으면 이러한 구분이 없어지고 특정 링크를 찾기가 더 어려워질 것이다.검색 상자는 현재 위치에 문제가 없으며, 낮은 해상도의 디스플레이를 사용하는 사용자를 제외하고 스크롤하여 찾을 필요가 없다.Kal 22:04, 2008년 6월 6일 (UTC)[응답]
• 지원- 상자를 탐색할 수 있고 자주 사용하는 검색 상자에 도달하기 위해 아래로 스크롤해야 하는 것이 짜증난다. -- SEEILCO (토크) 17:01, 2008년 6월 7일 (UTC)[응답]
• 나는 상자의 위치에 대해서는 중립적이지만, 그 중 두 개를 메인 페이지에 두자는 어떤 제안에도 반대할 것이다(현재 왼쪽 사이드바에 있는 것과 메인 페이지에만 새로운 것을 추가함).
• 지지 -내가 보는 방식, 내가 가끔 찾아봐야 하고, 내가 매일 여기 온다면, 다른 나이든 새것들은 어려움을 겪을 것이다.—레너드^블룸(토크 • 기여) 03:12, 2008년 6월 12일 (UTC)[응답]에 의해 서명되지 않은 코멘트 추가
• 지지 - 이것은 많은 사람들에게 상황을 훨씬 더 쉽게 만들 것이다; 나는 반대편에 있는 베테랑들이 정말로 그들을 새로운 사용자들의 입장이 되게 하고 있는지 잘 모르겠다.그들이 가장 먼저 보게 될 것은 로고이고, 바라건대, 새로운 포맷으로, 두 번째는 지구 바로 아래의 검색창일 것이다. -- Anonymous Dissident^Talk 13:38, 2008년 6월 14일 (UTC)[응답]
  • 넌 오래된 사용자야...위키피디아의 레이아웃에 관한 한 당신의 판단이 우리보다 더 정확하다고 생각하는가? :-) 어떤 경우든 나는 사람들이 책 페이지처럼, 한 줄씩, 위에서 아래로, 화면을 읽는다는 견해에 강하게 반대한다.신문이나 잡지 페이지는 더 정확한 비유일 것이다: 사람들은 가장 독특한 요소들을 먼저 본다.메인 페이지의 경우 사이드바의 링크 박스 패턴을 깨기 때문에 검색 상자는 현재 포맷으로 가능한 한 눈에 잘 띄고 있을 뿐만 아니라 바로 위에 있는 로고의 굵은 글씨로 가려져 있을 것이다.그 움직임은 실제로 검색창을 덜 눈에 띄게 만들 수 있다.2008년 6월 18일 (UTC) 01:22의 공작 월섬 (Walthaltham, The Duke of 01:22
• 지원 - 탁월한 심미적 개선제프 카 (토크) 2008년 6월 16일 16:22 (UTC)[응답]
• 강력한 지원 - 좋은 사용적합성은 모든 웹사이트의 주요 목표가 되어야 하며, 이는 설계 규약을 준수하고 방문자가 예상하는 곳에 검색을 배치하는 것을 의미한다.현재 위치는 검색이 화면 상단에 배치되어야 한다는 사용성 지침을 위반한다.나는 그것이 현재 있는 곳에 검색을 배치하는 어떤 운율이나 이유도 알지 못한다.이것은 머리를 쓰지 말아야 한다. --월보(토크) 21:11, 2008년 6월 16일 (UTC)[응답]
  • 하지만 그렇지 않다.그리고 나는 페이지 상단에 관한 한 동의한다. 그리고 실제로 많은 웹사이트들이 검색창을 바로 맨 위에 올려놓고 있다.그러나 사이드바의 맨 위는 페이지 맨 위가 아니다.우리는 매우 다른 레이아웃에 대해 이야기하고 있고, 여기서 비교하는 것은 다소 형편없다.2008년 6월 18일 (UTC) 01:22의 공작 월섬 (Walthaltham, The Duke of 01:22
• 지지하다.그것은 머리가 잘 돌지 않는다.독자들은 우리가 누구를 위해 이 일을 하는지이다.대다수의 사용자들이며, 우리는 그 사이트에 익숙하지 않은 많은 방문자들을 얻었다는 것을 인정해야 한다.우리는 독자들이 아마도 사이트의 가장 중요한 기능이 무엇인지를 찾을 수 있도록 가능한 한 쉽게 만들어야 한다.게다가 그것은 모바일 기기를 사용하는 사용자들에게 도움이 될 것이다.게다가 검색창은 모든 페이지에서 같은 위치에 있어야 한다(최소한의 놀라움의 원칙). --Dschwen 14:43, 2008년 7월 11일 (UTC)[응답]

무작위 기사에 즉흥적인 작업

친애하는 고객님, 이것은 메인 사이트의 위키 사이드 바에서 제공하는 매우 좋은 시설과 관련된 겁니다.랜덤 기사.앞서 언급한 내용을 사용하는 동안 나는 "랜도마이저"가 나 자신이 에 흥미가 없는 페이지에 오르는 경향을 주목했다.여기에는 장소 이름, 카운티 및 학교와 같은 과목이 포함된다.나는 등록되고 자주 사용하는 사용자가 특정 Person에 관심 있는 과목의 범위를 너무 특정하지 않고 선택할 수 있는 시설을 제안한다.이것은 "랜덤 기사" 태그 옆에 자바 비트로 기록될 수 있다.메모리 기능을 포함한 최대 6 ~ 7 (2개 이상 선택 옵션 포함) (즉, 다음 로그인에서 선택 사항을 유지하는 기능이 최적의 IMHO가 될 것이다.위키 <컴퓨터 교육을 받지 않은 내 자신>에서 기사가 어떻게 색인되는지 모르겠다.그러나 그러한 경우 특정 조항과 관련된 주요 지수들의 숫자는 그것이 보유하고 있는 TAG(역사, 자연과학, 정치, 심리학, 미술, 언어학 등)와 상관관계가 있을 것이며 가능하다면 여기서도 같은 것을 사용할 수 있다.

나는 이 생각을 충분히 고려하기를 바란다.

난 남았어

그럼 안녕히 계세요,

ChimesM --Chimesmonster (대화) 06:24, 2008년 6월 8일 (UTC)[응답]

우리는 아마도 "특별한 개선:"임의의"를 계속적인 제안으로 하거나 다른 방법을 찾아낸다(후자는 좋을 것이다, 나는 범주 내에서 임의의 기사를 찾아 볼 수 있다).나는 우리가 그것에 대한 범주 매개변수를 추가하고 일반 랜덤라이저 옆에 별도의 링크를 가지고 당신이 선택할 수 있는 일부 상위 범주의 목록을 제공할 수 있다고 생각한다.편집 가능한 페이지(그러나 보호되는 것으로 추정됨)는 적격 범주의 목록을 유지하기 위해 예약될 수 있다.

어쨌든 그건 무작위적인 생각이야, 아마 누군가는 더 나은 방법을 생각할 수 있을 거야! --_{tiny plastic} 그레이 나이트⊖ 07:53, 2008년 6월 10일 (UTC)[응답]

위키백과 확인:링크교차로 - 동일한 위키링크를 공유하는 이들을 기반으로 유사한 기사를 찾을 수 있는 도구를 만들자는 제안. ☑ SamuelWantman 07:02, 2008년 6월 15일 (UTC)[응답]

###얼마나 뻔한 일인가.스텁(stub) 및 디스컴비지 페이지에 게시하지 않도록 옵션을 선택해야 함!69.134.171.127 (대화) 22:57, 2008년 6월 17일 (대화) 22:56, 2008년 6월 17일(UTC)에 서명되지 않은 코멘트 추가 준비[응답]