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

1월 1일부터 12월 31일까지의 영구 반보호 제안

나는 366개의 모든 기사를 영구적으로 반보호하는 것을 제안하고 싶다.이제 나는 그것이 어느 정도 반대를 불러올 것이라고 생각한다. 그래서 나는 가능한 한 광범위한 포럼에서 토론하는 것이 가장 좋을 것이라고 생각했다. 물론 이것을 하기 위해 서두를 필요는 없다.우선 조심스럽게 내 사건을 진술해 볼게.

• 이 페이지들은 모두 꽤 안정적이다.만약 어떤 사람이 공공 기물 파손과 그에 따른 반전을 간과한다면, 이 페이지에는 정말로 의미 있는 편집이 거의 없다.
• 이 페이지들은 심한 공공 기물 파손 대상이다.최근에 변화를 일으킨 적이 있는 사람이라면 누구나 알고 있듯이, "1989년 귀여운 남자 존 도아가 태어났다"는 것은 매우 흔한 일이다.
• 의미 있는 편집에 대한 반달리즘 관련 편집의 비율은 가능한 한 낮다.최근 Riana에게 이야기하면서, 나는 무작위로 1월 22일을 예로 들었다: 지난 50번의 편집 중 40건 이상이 공공 기물 파손과 관련된 것이었다.나머지 편집은 대부분 세미 프로텍션에 영향을 받지 않는 계정에서 구현한 미용 수정 작업이었다(이 편집은 유일한 예외라고 생각한다).
• 이 페이지들은 집중 감시되므로 IP나 새로운 사용자에 의한 편집 요청이 아마도 빨리 실행될 것이다.앞서 언급한 바와 같이 이 페이지들이 상당히 안정적이기 때문에 그것들은 매우 드물 것이다.

이제 반보호 정책은 "조지 W 부시와 같은 무겁고 지속적인 반달리즘의 대상"에 대해 무기한 반보호를 사용해야 한다고 말한다.달력의 날들이 계속되는 반달리즘의 주제라는 것은 의심의 여지가 없지만 사랑하는 GW 부시 기사에 영향을 미치는 강력한 우박과 비교한다면 무겁지 않다는 것을 인정하겠다.그러나 비용/효익 관점에서 보면 반보호가 타당해 보일 것이다.여기서 공감대를 얻을 수 있다면, 한두 주 동안 십여 명을 보호하면서 실험해 보고 싶다.우리는 그것이 어떻게 진행되는지 볼 수 있었고 그 후에 더 교육적인 결정을 내릴 수 있었다.파스칼.테손 04:49, 2007년 7월 3일 (UTC)[응답]

그들 위에 추한 꼬리표가 붙어 있지 않는 한, 나는 이 제안에 전적으로 찬성한다.그들은 정말 반달의 표적이다. --Steinnn 04:57, 2007년 7월 3일 (UTC)[응답]

그럴 필요 없어, 템플릿 {{Sprotected2}}개는 오른쪽 상단 모서리에 별도의 작은 자물쇠만 달면 돼.파스칼.테손 05:02, 2007년 7월 3일 (UTC)[응답하라]

(ec) 흥미로운 생각이야.이러한 페이지의 반보호는 WP가 아니다.메인 페이지 기사를 보호하는 방식에서 물리는 것.나는 시험을 지지할 것이다.교대일(예: 7월 5,7,9,11일)을 반보호하고 정해진 시간 후(예: 1주일을 말함)을 비교하는 것은 어떨까(예: 7월 6,8,10,12일)여기서의 생각은 현재의 어떤 날이든지 간에 상당한 양의 공공 기물 파손을 얻는 것처럼 보인다는 것이다.또한 12월 25일과 1월 1일과 같은 두 개의 더 무거운 트래픽 페이지를 사용해 보십시오.Flyguy649^talk_contribs 05:03, 2007년 7월 3일 (UTC)[응답]

내가 보기에는 합리적인 것 같아, 그것들은 기본적으로 색인 페이지들로만 되어 있어. --tjstrf talk 05:13, 2007년 7월 3일 (UTC)[응답]

"그 해의 기사"에 만들어진 대부분의 IP-edit는 사실 파괴 행위나 터무니없는 것이지만, 그것이 영구적인 반보호가 필요한 수준에 도달했는지 확신할 수 없다.각각의 기사 자체에는 크게 파손되지 않고, 366페이지의 모든 페이지를 쉽게 볼 수 있으며(이 링크는 당신에게 최근의 모든 편집을 제공한다), 왜 페이지가 계속 열려 있어야 하는지에 대한 표준 주장이 적용된다.하지만 나도 강하게 반대하지는 않아.나는 점점 더 이 페이지들이 끌어들이는 것처럼 장난 편집을 되돌리는 것에 싫증이 났고, 기사들은 점점 더 좋아지고, 우리는 계정을 등록하려는 사람들이 점점 더 많아지면서, 나는 이제 우리가 이 기사들을 편집하도록 내버려 두었던 예전보다 더 선별적으로 선택할 수 있는 여유가 있다고 생각한다.그래서, 나는 여기서 결정을 못 내리고 있는 것 같아.2007년 7월 3일 셰인스 05:15 (UTC)[응답하라]

나는 이 기사들을 반보호하는 것에 반대한다.위에서 지적한 바와 같이 거의 모든 공공 기물 파손 행위는 사람들이 자신의 이름이나 친구 이름을 추가하는 것이다.이것은 비교적 무해한 반달리즘이다 - 만약 누군가가 이 주에서 그 기사를 읽는다면, 그것은 위키피디아에 대한 그들의 경험을 크게 손상시키지 않는다.사실상, 이것들은 무해한 시험 편집이며, 우리는 사람들이 샌드박스를 사용하는 것을 선호하지만, 이러한 기사들을 반보호하는 것은 그들을 그런 방향으로 이동시키지 않을 것이다.생일기사를 편집할 수 없는 사람은 적게 보는 페이지에서 비슷한 편집을 하고, 다른 사람은 아예 편집을 시도하지 않는다.-가드피움 06:10, 2007년 7월 3일(UTC)[응답]

나는 그 입장을 존중하지만 나는 동의하지 않을 수 없다.반달은 대부분 무해한 아이들을 위한 것이다.그들은 생일 페이지에 가서 "헤헤헤, 웃기고 내 이름을 추가하겠다"고 생각하지만, 나는 그들 중 대다수가, 만약 그들이 편집을 할 수 없다면, 그냥 잊어버릴 것이라고 생각한다.반면에, "아, 나 이거 편집할 수 없으니까 코끼리 기사에 내 생일을 추가하게 해줘."라고 말할 것 같아.문제는 물론 우리 중 누가 이것에 대해 옳은지 결코 알 수 없다는 것이다.어쨌든, 나는 반달리즘이 위키피디아의 악의적인 성격 때문에가 아니라 반달 편집의 양이 너무 많아서라고 믿는다.어쨌든, 나는 어떤 페이지라도 반비례하는 것이 단점이 있다는 것을 확실히 알고 있지만, 이 경우 나는 이점이 관심사보다 크다고 생각한다.파스칼.테손 06:50, 2007년 7월 3일 (UTC)[응답]

다음에 읽게 될 글이 '코끼리'라면 생일보다는 언니와 비교를 더하는 경향이 더 크다고 생각하지만, 어떤 경우든 생산적인 편집이 아니라 아주 빨리 되돌아가더라도 어떤 페이지에든 첫 편집을 하는 사람이 중요하다고 생각한다.이것은 항상 위키백과 철학의 일부였다. 그래서 우리는 부적절한 편집에 대해 열심히 단속하기 보다는 {{uw-test1}과 같은 템플릿을 사용하는 것이다.시험 편집은 대부분 10대들이 하고 있는데, 일단 그들이 정말로 편집할 수 있다는 것을 깨닫고 일반 대중에게 그러한 편집이 나타나도록 하면, 그들 중 어느 정도는 생산적으로 편집을 결정할 수 있다.-가드피움 23:43, 2007년 7월 3일 (UTC)[응답]

하지만 그것은 너무 이상주의적이지 않은가?나는 항상 WP의 철학이 다음과 같이 느껴왔다.BURT는 '반달들이 편집자가 되니 반달들에게 친절하게 대하자'는 것이 아니라 '무능한 신참들이 편집자가 된다'는 것이니 여동생이 코끼리처럼 생겼다고 생각하는 사람들까지 신참들에게 인내심을 보여줍시다.그러나 전체적으로 IP 편집에 대한 어느 정도의 합리적인 제한은 (새로운 페이지를 만들 수 없는 것과 같은) 반달 파이터에 대한 부담을 가볍게 해주며 나는 그것이 잠재적 기여자들을 그렇게 극적으로 두렵게 할 것이라고 확신할 수 없다.파스칼.Tesson 23:58, 2007년 7월 3일 (UTC)[응답]

그렇다, 위키피디아는 이상적인 프로젝트다.지금까지는 그런 식으로 잘 작동했다.

코끼리는 사실 좋은 예가 아니다. 왜냐하면 코끼리는 이미 반보호를 받고 있기 때문이기도 하고, 아마도 상당한 수의 사람들이 관찰하고 있기 때문일 것이다.내 생각에 누군가가 그들의 생일 페이지에서 다른 이름을 클릭할 가능성이 더 높으며, 90년 후에 토미 스미스가 그들의 일을 계속하기 위해 태어났다는 그 모호한 기사를 덧붙일 가능성이 더 높다.

만약 이 페이지들이 반보호적인 것이라면, 1985년부터 2000년까지의 다양한 연도 페이지들도 같은 이유로 반보호되어야 한다.-가드피움 00:10, 2007년 7월 4일 (UTC)

그렇다, 위키피디아는 대부분 이상주의를 고수했지만 또한 이상주의를 위해 실용적인 선택을 하고 이상주의를 외면할 수 있었기 때문에 잘 해냈다.파스칼.테손 03:43, 2007년 7월 4일 (UTC)[응답]

이것은 어려운 선택이다.내가 보는 갈등은 익명의 편집을 통해 달성 가능한 잠재적 이익과 시험 편집이 성공적인 채용으로 이어질 수 있는 두 번째 순서 효과에 대해 쓸모없는 끊임없는 반전에 관련된 노동력을 저울질하고 있다는 것이다.이 페이지들은 자연적으로 매우 천천히 진화하기 때문에, 유용한 익명의 편집본을 찾기가 어렵다.나에게 그것은 의심스러울 정도로 과거의 주장과 유사하게 어떤 사람들이 "완성된" 혹은 "안정적인" 기사를 반제어로 만들도록 부추기는데, 나는 분명히 지지하지 않는다(우리는 결코 "이것은 끝났어. 망치지 마."라는 메시지를 보내서는 안 된다.내가 반대쪽으로 기울어지는 것은 마지막 이유 때문이다: 우리는 그 메시지를 보내고 싶지 않다.Dcoetzee 09:16, 2007년 7월 3일 (UTC)[응답]

나는 반보호를 지지한다.내 생일인 10월 4일을 보는데, 거의 모든 편집이 이런 종류야.좋은 편집은 거의 항상 기존의 사용자들에 의해 이루어진다.내가 제일 먼저 보는 경우가 많기 때문에 시간을 들여 기사를 확인해서 레드링크인지 확인한 다음 되돌리는 사람이 되겠다.나는 또한 이 기사들이 매우 정적이란 것에 동의한다.내 생각에는 이런 시험 편집이 채용으로 귀결되는 경우는 거의 없을 것 같다.위에서 말했듯이, 대부분은 지루한 학교 아이들이 자신을 더하는 것에 의해 만들어지며, 건설적인 편집을 할 것 같지 않다.나는 내가 짜증나는 테스트를 하지 않았다는 것을 안다.Dcoetzee의 마지막 진술에 대해서는, 전에는 그렇게 생각하지 않았지만, 일년 중 며칠 동안, 그들은 끝난 것 같다. 그리고 우리는 그들이 그것을 망치는 것을 원하지 않는다. 우리가 그것을 되돌려야 하는 곳에서.어쨌든, 만약 그 사람이 건설적인 편집을 할 수 있다면, 토크 페이지의 요청은 권장된다.레이와스92^Talk 14:26, 2007년 7월 3일 (UTC)[응답]

난 이 일로 갈등하고 있어...나는 보통 선제적인 페이지 보호에 열광하는 편은 아니며, 확실히 그것들 중 몇 명이 한 장씩 보고 있는지 확인하기 위한 일치된 노력이 아마도 그것들을 깨끗하게 유지하기에 충분할 것이다.그러나 RC 순찰에서 내가 보고/보고 있는 것 중, 변화의 대부분은 그들 자신이나 다른 레드링크들을 추가하는 새로운 사용자나 IP들이다.위키피디아 표준에 의해 왜 그들의 생일을 알 수 없는지를 환영하고 설명하는 개인적인 메시지를 시도해 보았지만, 내가 이것에 대해 경고했던 사람들이 나중에 심각한 기여자로 변모한 흔적은 본 적이 없다.그래서 나는 내 입장을 약간 약한 지지라고 표현하고 싶다. 나는 보호하지 않아도 괜찮다고 생각하지만, 그렇게 하면 큰 피해를 주지 않고 보호할 수 있는 시간을 절약할 수 있을 것이다.핀볼22 16:14, 2007년 7월 3일 (UTC)[응답]

나는 또한 위의 레이와스92의 논평에 따른 반보호에 찬성한다.~ sublime514 • talk • sign 18:25, 2007년 7월 3일(UTC)

나 또한 지지한다.거의 어떤 IP 편집도 되돌리지 않으며, 날짜에 자신을 추가할 수 없는 것은 유용한 기여자를 외면하지 않을 것이다.아트로포스 22:41, 2007년 7월 3일 (UTC)[응답]

나는 또한 이 제안을 지지한다.여기에서의 비용/편익 분석은 이 페이지들에 대한 반보호를 강력하게 지지하고 있다. -춘기 라이스 22:49, 2007년 7월 3일 (UTC)[응답]

나도 이 제안을 지지한다.— The Storm Surfer 03:14, 2007년 7월 4일 (UTC)[응답]

너의 의견은 파스칼에 대해 잘 알고 있으며, 내가 반대할까 두렵다.나는 모든 경우에 익명 편집에 찬성한다. 단, 스프로토피가 전적으로 필요한 경우는 제외한다.요점은, 나는 스프로테스트가 전혀 필요하지 않다고 생각한다는 것이다.한편으로, 나는 이 페이지들 하나하나를 내 감시목록에 추가해서, 만약 이것이 도움이 된다면, 그들의 시야를 증가시킬 용의가 있다. --ɐuʞssəp (ʞʞɿɐʇ) 04:33, 2007년 7월 4일 (UTC)[응답]

오, 다들 집중 감시하고 있을 거야.그리고 나는 그것에 대해 그렇게 강하게 생각하지는 않는다: 그것은 나에게 합리적인 생각처럼 보이지만 나는 이것을 하기 위한 어떠한 합의도 없다는 것을 받아들일 준비가 완전히 되어 있다.나는 단지 그것에 대한 지지를 측정하기 위해 충분한 사람들이 토론에 참여하기를 바란다.파스칼.테손 04:58, 2007년 7월 4일 (UTC)[응답]

왜 ppl이 게시할 수 있는 생일만을 위해 1면에 옵션을 만들지 않는가? 아마도 노란색 또는 연한 파란색 액자 같은 것으로 별도의 칼럼을 만들지도 모른다.이것은 문제의 일부를 해결할 것이다.그럼에도 불구하고 반 보호는 타당해 보인다.그러나 생일이라는 것이 만들어지면 반보호를 할 필요가 없다.:DVitalyshmelkin 10:50, 2007년 7월 4일 (UTC)[응답]

지지하다.이러한 글에서 공공 기물 파손과 건설적인 편집인 애논 편집의 비율은 설득력이 있다.아직 언급되지 않은 반보호에 대한 한 가지 이점은 RC 패트롤러들이 위키백과의 다른 필요를 해결하는 데 더 좋은 시간을 할애한다는 것이다.어큐라이저 11:43, 2007년 7월 4일 (UTC)[응답]

또는 의미 있는 데이터를 사용하여 366개의 템플릿을 생성하십시오.각 날짜의 주요 기사에 있는 템플리트를 필사하십시오.캐주얼한 반달들은 단지 하루 페이지를 편집하려고 할 뿐이고, 템플릿 변경 방법에 대해서는 알지 못한다.그러나 매일의 주요 기사는 보호되어야 한다(템플릿은 보호되지 않은 채로 남아 있다).문제의 끝?Neier 11:48, 2007년 7월 4일 (UTC)[응답]

지원 - 이 페이지에 신규/등록되지 않은 사용자가 편집한 내용의 99.99%는 공공 기물 파손이다.WATP • 2007년 7월 4일 12:18, 4 (UTC)[응답]

강한 지지 - 나는 많은 애논을 돌려왔다.이러한 페이지의 IP 편집은 대부분 몇 주 이상 동안 - 전혀 눈치채지 못한 - 에 머물러 있었다.나도 이 페이지들에 대해 일반적 반보호를 제안할 생각을 해 본 적이 있다. 그래서 파스칼이 다행이다.테슨은 마침내 이 문제에 대한 초기화를 취했다.고마워!Cingold 14:04, 2007년 7월 4일 (UTC)[응답]

강력한 지원 - 일반적인 RC 패트롤러로서, 나는 이것이 시험 편집/반달리즘 자석이라는 사실을 보증할 수 있다.세미프로트는 em에게 해를 끼치지 않을 것이고, 정말로 그것들을 개선하고자 하는 사람은 누구나 쉽게 할 수 있다.훌륭한 제안.xC 인터뷰 14:27, 2007년 7월 4일 (UTC)[응답]

든든한 지지.그룹으로 보면, 이러한 365개 기사는 건설적인 IP 편집에 대한 IP 반달 편집의 비율이 매우 높다(전혀?).편집자들이 이 기사들의 반달리즘을 되돌리는 것 말고 다른 일들을 하도록 자유롭게 합시다. (그런데, 내가 한 기사를 잠깐 본 것은 그것이 이동방지가 되지 않았다는 것을 보여주는 것 같았다 - 도대체 왜?) - 존 브레본 (비틀링) (비틀링) 2007년 7월 4일 (UTC) 14:30, 7월 4일 (UTC)[응답]

나는 어쨌든 크게 감시되고 있는 어떤 것을 반보존할 필요가 있다고는 생각하지 않지만, 나는 그것이 여러분이 고수하고 있는 위키백과 문학으로 귀결된다고 생각한다.이렇게 말하자:반절제를 정당화할 만한 반달리즘은 현재 충분하지 않다; 단지 목록을 작성하고 되돌아가기만 하면 된다.그리고 약간 주의할 점은, 기사의 편집이 90% 이상의 반독재이기 때문에 반독재 처리를 시작한다면, 반독재해야 할 기사가 더 많아질 것이라는 겁니다.렉토나르 15:36, 2007년 7월 4일 (UTC)[응답]

반대 나는 공공 기물 파손 수준이 보호를 보장할 만큼 충분히 무겁다고 생각하지 않는다.이러한 페이지에 나타나는 반달리즘도 가장 악의가 적은 종류인 경향이 있다.나는 이 제안으로 얻은 이익이 오픈 편집이라는 우리의 원칙을 더 이상 훼손하기에 충분하다고 생각하지 않는다.보리스블루 09:46, 2007년 7월 5일 (UTC)[응답]

강한 반대 철학적 접근, 나는 WP에 동의한다.익명 사용자에 의한 편집을 금지하는 유일한 목적으로 PPOL 세미 프로텍션을 사용해서는 안 된다. 보호는 지속적인 중단을 방지하기 위해서만 사용해야 한다.궁극적으로 우리는 Gnangarra 11:51, 2007년 7월 5일 (UTC)[응답하라]의 교장을 유지하기 위해 노력해야 한다.

반대, 영구적으로 반보호가 이루어지는 것은 아니다.Corvus cornix 18:18, 2007년 7월 5일 (UTC)[응답]

사실, 그렇다.예를 들어, 아우슈비츠와 같은 페이지는 무기한으로 보호되고 있으며, 지난 번에 누군가가 조지 W. 부시를 보호하지 않으려고 했을 때는 "너 미쳤니?"라는 요약과 함께 즉시 다시 보호되었다.무기한 반보호를 반대하는 좋은 주장들이 있지만 "그것은 결코 이루어지지 않는다"는 것은 그 중 하나가 아니다.파스칼.테손 18:24, 2007년 7월 5일 (UTC)[응답]

나는 그 제안의 지지자로서, 이것의 결과를 보고 싶다.어떻게 된 거야? --사용자:Krator (t c) 23:52, 2007년 7월 7일 (UTC)[응답하라]

시험을 지지하다.Flyguy649가 제안했듯이, 이것에 대한 테스트는 흥미로울 것이며, 대부분의 사람들에게 동의해야 한다.아마도 7월에서 12월까지는 우리가 입학하는 기간이고, 시험 종료일이 명확하기 때문에. --Quidity 00:06, 2007년 7월 8일 (UTC)[응답]

나는 이것에 전적으로 반대한다.우리는 반달리즘을 되돌릴 수 있고, 그 페이지들은 "반달"로 시작해서 결국에는 도움이 되는 편집자가 될 수 있는 새로운 편집자들을 끌어 모을 수 있는 잠재력을 가지고 있다.A.Z. 00:33, 2007년 7월 9일 (UTC)[응답]

반대. 그래, 골칫거리지만 적어도 한 두 명의 '신뢰할 수 있는' 편집자들이 일일이 날짜를 볼 수 없다면 나는 놀랄 것이다.사실 지금 내 생일파티리스트에 내 생일파티를 추가할 거야.2007년 7월 9일(UTC) 03:14(Cmprince 03:14

약한 지지 - 그 개념은 원론적으로는 좋지만, 만약 여러분이 특정한 날짜에 다른 날짜보다 더 많은 공공 기물 파손을 일으키는 경향이 있다는 것을 알게 될 것이다.모든 날짜를 반보호하는 대신에 잘 알려진 날짜만 반보호하는 게 어때?7월 4일, 12월 25일, 2월 29일 등.그냥 생각. --Tλε RαnΔom Διor (ταlκ) 22:40, 2007년 7월 12일 (UTC)[응답]

나는 한동안 이 페이지들 중 많은 부분을 내 감시 목록에 올려놓았는데, 그것들은 반달들의 표적이 되고 "내 딸은 이 날에 태어났다"는 뉴 b 편집자들의 표적이 된다.일상적으로 편집내용을 유지하고 반달과 허영심을 유지한 편집자들의 고통이다(나는 4개월을 보았다). --DJ (대화 • 기여) 22:51, 2007년 7월 12일 (UTC)[응답]

지지 - RC 패트롤러가 다른 요구에 집중할 수 있다는 이전 진술에 동의한다.나 또한 매일 템플릿을 만드는 아이디어가 좋아.반달들은 템플릿을 편집하는 방법을 알아내는 데 시간을 할애할 만큼 신경 쓰지 않을 것이다.비록 어떤 사람들은 여전히 헛소리를 올릴지 모르지만, 그것은 많은 사람들을 단념시킬지도 모른다.라라러브^T/_C04:13, 2007년 7월 13일 (UTC)[응답]

약한 반대 - 나는 여기서 완전히 찢어졌다.위키피디아를 시작한 이후부터 나는 RC패트롤러로 일해왔고, 이 기사들이 얼마나 많은 반달리심(반달리심)을 얻었는지 본 후, 나는 지금 약 5페이지(내 생일, 하원의원 생일, 그리고 몇 명의 친구 생일)를 본다. 이 또한 어떤 이유로 누군가가 내 신원을 뿌리 뽑으려 한다면 내 생일을 그렇게 명백하게 만들지 않는 이점이 있다.반달리심이 많은가?기필요하게반보호로 막을 수 있을까?내 마음에는 의심의 여지가 거의 없다.그러나 동시에 반보호만이 이 문제를 해결할 수 있는 유일한 방법은 아니다.이 페이지들은 면밀히 관찰될 수 있다.반보호라는 것은 썰매로 못을 박으려는 것 같다.과잉 살상이긴 하지만 많이는 아니에요.나는 그냥 일반 해머를 사용하는 것이 지금 이대로는 괜찮다고 생각한다.그들이 s로 보호받는다면(나에게는 덜 일) 나는 실망하지 않겠지만, 동시에 그럴 필요는 없다고 생각한다. (우리가 아직도 무언가를 하고 싶다면 아마도 봇이 레드링크를 위해 매일 "출산"을 체크할 수 있을까?) --Ybbor^Talk 01:22 (UTC) 2007년 7월 14일 (UTC)[응답]

전혀 불필요하다.이것이 위키피디아에서 가장 많이 보는 페이지들 중 하나가 아니라면 놀랄 것이다; 내 자신의 생일 (5월 21일은 하루에 한두 번 정도 치는데, 이것은 내가 보는 다른 많은 페이지들과 비교해도 그리 대단한 것은 아니다.--jpgordon^∇∆∇∆ 16:06, 2007년 7월 22일 (UTC)[응답]

반대 - 과잉 살상.—앞서 서명되지 않은 코멘트는 2007년 7월 26일(UTC) 11:33에 의해 추가되었다.

불필요 - 지난 한 주 동안 10페이지 정도 보고 의견을 바꿨어.일부 페이지는 공공 기물 파손을 받았으나 비교적 빨리 되돌아왔다.나는 충분한 정규 편집자들이 각각 10페이지를 본다면, 아주 적은 반달리즘이 아주 오래 머물 것이라고 확신한다.Flyguy649 14_contribs:28, 2007년 7월 26일 (UTC)[응답]

약한 반대 - 이것은 나에게 있어 실용성 때문에 내가 공감하는 매우 유혹적인 생각이지만, 영구적으로 반보호적인 기사들을 만든 것은 선례다.사용자:Dcoetzee는 앞서 좋은 지적을 한다.더 나아가, 위키피디아는 대중에게 두 가지 서비스, 즉 정보에 대한 접근과 그 정보를 바꿀 수 있는 능력을 제공한다.이것은 편의상 논쟁에서 그 생각을 절충한다.어떤 제안들은 다른 제안들을 개선한다. 우리는 은퇴를 준비하는 위키백과의 유일한 편집자가 아니다.우리 뒤에 항상 다른 사람들이 있을 것이다. 하지만 지금으로서는, 우리는 소수의, 자랑스러운, 등록된 사용자들이다.위키피디아를 개선할 뿐만 아니라 처음 발견했을 때 우리에게 있었던 그대로 유지하려는 노력이었습니다.개방성은 항상 언어 언어의 가장 큰 강점과 가장 존경받는 덕목이다.2007년 7월 29일 05:04 (UTC)[응답하라]

필수 위키백과?

"필수적인" 위키백과에 대한 데이터베이스나 필터, 오버레이 같은 것이 지금 존재하는가?

예를 들어 콩고 시골에서 인터넷 접속이 안 되는 학교를 운영하고 있다면, 모든 잡동사니들과 대중문화들이 다 벗겨진 채 꼭 필요한 교육용 기사들만 가지고 있는 CDR(또는 어떤 크기의 미디어가 필요한지)을 한 장만 있으면 좋을 것이다.

나는 그것이 흥미로운 아이디어가 될 것이라고 생각했다 - 필수적인 기사들만 읽거나 다운로드 할 수 있는 방법.

나는 그 기사들을 식별하는 것은 단지 꼬리표를 붙이는 것만으로 충분하다고 생각한다.하지만, 다운로드를 위해 업데이트된 필수 기사들을 조립하는 대본에 대해서는, 그것은 내 능력 밖이다.올글로리토더하이프노토드 19:51, 2007년 8월 3일(UTC)[응답]

여러분은 위키피디아의 선을 따라 생각하고 있을지도 모른다.버전 1.0 편집팀의 릴리스 버전주제별보다 더 '일반적인 관심사'인 그들의 출시가 정확히 당신이 찾고 있는 것이라고는 생각하지 않지만, 내가 생각할 수 있는 가장 가까운 근사치인 것이다.존 카터(19:54, 2007년 8월 3일 (UTC)[응답]

SOS Children과 협력하는 위키백과 CD Selection은 여러분이 생각하고 있는 것과 같은 종류의 것 같다.2007년 선정이 가능한 것 같다.2006년 위키백과 메인 스페이스에 대한 위키백과 CD Selection에 관한 정보도 있다.--Boson 17:17, 2007년 8월 5일 (UTC)[응답]

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

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

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

위키백과 검색을 위한 철자 검사!!!!!!!!!!!!!!!!

여기 많은 어린 학생들이 위키피디아를 사용하는 철자 점검에 대한 나의 요점이 있다.그리고 때때로 그것은 단순한 실수일 수도 있고 누군가가 철자를 모를 수도 있다.그리고 이것들은 모두 구글 검색으로 해결될 수 있다. 그러나 많은 어린 학생들이 그 검색에 어떻게 접근해야 하는지 항상 알지 못한다.나는 백과사전을 위한 철자 점검이 다소 약해 보일 수 있다는 것을 알고 있다. 그러나 그것은 2007년 7월 19일 00:56에 서명이 없는 (출연)에 의해 추가된 큰 특징이다.

활자는 사람들을 화나게 하는 것이 아니라 단지 그들을 자극할 뿐이며, 작가가 화가 났다는 것을 암시한다.

아마도 당신은 특히 누군가가 요구하는 페이지가 존재하지 않는다면 여기 소프트웨어가 이미 제안을 하는 방식을 고려하여 당신의 제안을 더 자세히 설명할 수 있을 것이다.

코멘트에 서명하는 것을 잊지 마십시오(물론 서명을 하지 않는 것이 요점이 아니라면). -- 2007년 7월 19일(UTC) 회신[응답]

많은 기사의 제목이 어떤 특정한 이유로 의도적으로 잘못 표기되어 있기 때문에 이것은 작동하지 않을 것이다. -- 익명의 반체제^Talk 인사 06:34, 2007년 7월 19일 (UTC)[응답]

아니, 그건 대단한 특징이 아니야.검색 엔진들이 당신이 찾으려고 하는 것을 당신보다 더 잘 안다고 생각할 때 짜증난다.어쨌든 이것은 진지한 제안이라기보다는 불꽃놀이에 가까운 것 같다.이미 가장 흔한 오타를 해결할 수 있는 해결책이 있다.dab (𒁳) 07:28, 2007년 7월 19일 (UTC)[응답]

나의 활자적 활자성에 대한 코멘트는 아씨가 여기 있는 많은 사람들을 화나게 하는 느낌표와 같은 느낌표를 사용하여 내가 그것을 사용하는 것에 대한 대답이었다고 덧붙일 수 있다; OP는 이후 이것을 삭제했다. -- Hoary 13:44, 2007년 7월 19일 (UTC)[응답]

나는 이것이 통제 불능이 되어가고 있다고 생각한다. 나는 "익명 반체제인"으로부터 위키에 엘리트주의가 없다는 혐오 메일을 받고 내가 어리석고 내가 무엇을 하고 있는지 모른다고 말한다.나는 어리석지만 누군가에게 위키백과의 검색에 대한 주문을 외우라고 말한 것에 대해 비판할 수 있다. "여러 가지 일로 위키백과를 비난할 수는 있지만, 확실히 엘리트주의적인 것은 아니다.WP는 단도직입적으로 말하자면, 바보같은" 그래, 그리고 위키피디아의 각 구성원은 위키피디아의 일부분이고 당신의 논평은 위키피디아의 좋은 공동체를 망친다.나의 게시물은 주로 검색에 대한 제안들을 제공하는 철자 점검에 관한 것이었다. 구글에서처럼 그것은 기본적인 제안이고 별로 많지 않다. 그래서 내가 그것을 제안했던 이유는 그것이 아마도 좋고 실행하기 쉽다고 생각했기 때문이다.나는 위키피디아에 있는 모든 사람들이 완벽하고 잘못할 수 없다는 것을 첫 게시물에서 배웠지만, 어떤 사람들은 나처럼 철자법을 잘 쓰지 않아. 나는 항상 오픈오피스에서 철자 검사를 하는데 쉽고 편리해.나는 이 반응이 너무 멋지고 예의 바르게 "아니오, 별로 좋은 특징이 아니야.검색 엔진들이 당신이 찾으려고 하는 것을 당신보다 더 잘 안다고 생각할 때 짜증난다.어쨌든 이것은 진지한 제안이라기보다는 불꽃놀이에 가까운 것 같다.이미 가장 흔한 오자를 해결할 방법이 있다" 이것은 불꽃 미끼다"라고 말했다. 이것은 당신이 왜 그렇게 짜증을 내는지, 그래서 당신이 공격하는 것은 불꽃 미끼 붐이다. 이것은 정확한 철자의 제안이 왜 그렇게 위협적인지 나는 모르겠다.내가 공격한 사람들을 찾아내려는 시도는 많은 대화 페이지에 있는 사람들이 비열하고 고약하며, 단지 당신이 10000Km 떨어진 곳에 타이핑을 하고 있다는 이유만으로 그만둬야 한다는 것이었다.내 사용자 이름은 Unsignments이다. 나는 그것이 약간 웃기다고 생각했다. 그러나 나는 더 게으르고 별 관심이 없다. 그러나 Anonymous Dissident에게 사용자 이름은 어리석다고 생각할지도 모른다. 그러나 Anonymous Dissident는 이렇게 말했다. "Anonymous Dissident는 "사용자 계정 Unsignated commention을 만든 다음 당신의 게시물에 서명하지 않는 것을 지적하는 것은 단지 pueri에 불과하다.나는 내가 나의 게시물에 어떤 포럼 같은 것에 서명해야 한다는 것을 깨닫지 못했다. 나는 그것이 당신을 위해 그 게시물에 서명했다고 생각했다.만약 내가 충분한 점수를 얻는다면 나는 스키트 볼 티켓과 같은 BB 총을 얻을 수 있을까? (당신이 그것을 얻지 못하여 Anonymous Dissident의 지경에 화가 날 경우를 대비해서 ) . FAQ를 읽지 않은 것은 미안하지만 그것은 위의 천재들 중 누구도 FAQ를 읽지 않았거나 그들이 이것이 왜 이런 것인지에 대한 답을 알고 있을 것이다.가능하지도 않고, 그들이거나, 까다롭고 엘리트주의자일 수도 있다.그리고 나의 다음 제안은 위키에게 협박과 B를 없애자는 제안이 될 것이다!@#$ing 위.아마도 당신은 몇몇의 아이디어들이 멍청하다고 생각할지도 모르지만 만약 누군가가 새로운 사용자들이 싫어하지 않는 것을 돕는다면, 당신에게 비열한 거절의 권리를 준다.어쩌면 너희들과 의사들만이 백과사전을 써야 할지도 몰라. 누피디아에게 무슨 일이 일어났는지? - 사용자: 미서명 13:50, 2007년 7월 19일 (UTC)[응답]

어떤 '증오 메일'에 반박하는 겁니까?나는 이 전에 단 한 번도 당신과 얘기한 적이 없고, 누구에게도 원격으로 혐오감을 주는 말을 한 적이 없다. -- 익명의 반체제^Talk 인사 21:26, 2007년 7월 19일 (UTC)[응답하라]

그는 자신이 바보라고 비난하지 않았던 자신의 토크 페이지에 달린 dab의 발언이 당신으로부터 나온 것이라는 오해를 받고 있는 것 같다.나는 그 "stupid"가 어디서 왔는지 잘 모르겠다.아드리안 M. H. 21:39, 2007년 7월 19일 (UTC)[응답]

이 게시물은 내가 말하기에 슬픈 농담거리가 되었다.사용자들은 내가 말하기가 두려운 어떤 것에 대한 명백한 시민적 논의에서 모든 사람들이 자신에게 '미치고 고약하다'고 느낀다.죄송합니다. -- Anonymous^Talk Dissident 21:41, 2007년 7월 19일 (UTC)[응답]

나는 이것을 읽으면서 매우 혼란스럽다.dab이 왜 이 제안을 불꽃놀이라고 생각하는지 설명하는 다른 대화가 있는가?아트로포스 00:15, 2007년 7월 20일 (UTC)[응답]

좋아, 내가 모든 것을 지울 수는 있지만, 내가 업보를 할 수 없다는 규칙이 있을 거야. 바보 같은 스크린 이름이 불미스러운 것처럼, 어쩌면 불타는 당신의 사용자도 아닐지도 모르기 때문에, 친절함과 존중이 계속 될 수도 있기 때문에, 친절함을 아이라고 불릴 수도 있다. 앞의 서명되지 않은 코멘트는 Unsigned commentation에 의해 추가되었다.갈비) 03:04, 2007년 7월 20일 (UTC)[답답하다]

아트로포스, 몇 가지 요소들은 나중에 분명히 Unsignments에 의해 삭제되었다. 호아리가 2007년 7월 21일 (UTC) 13:44 Nil Einne 14:00에 한 말을 보라[응답하라].

아, 이제 말이 되네.내 독해력이 떨어질 때 네가 곁에 있어줘서 기뻐. :D 아트로포스 00:51, 2007년 7월 22일 (UTC)[응답하라]

다시 시작

나는 이것이 흥미로운 주제라고 생각해서 이전의 광기를 차단하고, 새롭게 시작하려고 노력 중이야.우선 이 문제는 주로 여기서 해결이 가능하거나 불가능할 수 있는 소프트웨어 문제지만 적어도 대화를 시작한다.나는 프로그램/프로그램이 자동으로 당신의 철자를 고쳐줄 때 짜증난다는 것에 동의한다. 그리고 당신이 검색한 후에 사물의 철자를 "수정"하는 것을 제안하는 것이 항상 도움이 되는 것은 아니다.그러나, 나는 구글이 검색을 한 후에 당신의 검색이 원하는 결과를 가져오지 않았을 경우에 대비하여 대안들의 목록을 당신에게 제공한다고 생각한다. 그리고 나는 구글이 사전에서 이러한 결과를 가져온다고 생각하지 않는다.그것은 더 흔하게 검색되고 성공적으로 클릭되는 유사한 단어들을 제공한다. 위키피디아는 잠재적으로 당신의 검색에서 정확한 일치하는 것이 없는 경우에 유사하게 철자가 된 기사 이름이나 단어의 짧은 목록을 제공할 수 있다. 이것은 당신의 검색에 필요한 것보다 훨씬 편리할 것이다.색인을 자세히 살펴보거나 새로운 탭을 열어 구글에서 검색하여 다른 위키백과 검색에 복사하여 연결할 수 있는 대체 철자를 제공하는지 확인하십시오(이것은 자주 하는 것을 겸허히 인정함).그래서 여기 질문이 있다.이것이 바람직한가?뭐가 더 좋은가?어떻게 가능했을까?2007년 7월 29일 05:36 (UTC)[응답하라]

모든 것이 평등하다는 것은, 철자를 잘못 쓴 사람들을 돕는 선택이 좋은 일일 것이다.그러나 이것은 오해의 소지가 있을 수 있고(위에서 지적한 바와 같이), 구현하기 어려운 잡무가 될 수 있으며, (말하듯이) 목적을 위해 단순히 두 번째 창을 열면 구글에서 직접 같은 기능을 이용할 수 있다. -- Hoary 05:48, 2007년 7월 29일 (UTC)[응답]

당신의 카운터포인트 중 하나인 "이것은 오해의 소지가 있다(위에서 지적한 바와 같이)"- 그것은 사전의 대안이 아니라, 항상 목적적으로 철자가 틀린 기사 제목 단어들을 제공함으로써 기존의 기사들의 위키피디아 색인으로부터 대안을 제공할 것이다.또한 보다 효율적인 위키백과(즉, 위키백과)를 만드는 것을 덧붙일 것이다.구글과 같은 외부 영리 서비스에 덜 의존하는 것)은 잡무 IMO의 가치가 있는 사회에 대한 혜택이다. 어떤 것은 06:06, 2007년 7월 29일 (UTC)[응답]

철자 검사를 받지 않는 것은 사람들이 철자에 주의를 기울이도록 하고 철자 검사 없이 올바른 철자를 배우도록 장려한다.또한 철자는 같지만 의미는 다른 단어 또는 철자는 다르지만 발음은 같은 단어들을 구별하도록 장려한다.정확한 철자를 쓰려고 노력하지 않는 편집자들에게, 이것은 다른 편집자들에게 분명하고 우리에게 첫 번째 편집기에 대해 유용한 것을 말해준다.확실히 이 모든 것이 좋은 것인가? --Eriastrum 16:10, 2007년 7월 29일 (UTC)[응답]

위키백과 참조:마을 펌프(매년 제안)#이것이 미디어질라:974로 요약된 더 나은 검색 기능.기능성은 존재하지만 성능상의 이유로 비활성화된다."

위키백과를 참조하십시오.현재 검색의 작동 방식에 대한 설명을 보려면 이동 버튼을 클릭하십시오. --Quiddity 17:51, 2007년 7월 29일(UTC)[응답]

Talk 페이지 탭

"+" 탭을 "주석 남기기"로 변경

난 친구들의 위키백과 경험에 대해 비공식적으로 인터뷰를 해왔는데, 우리가 좀 더 똑똑하고 평범한 사람들이 기여하길 원한다면 할 일이 많은가?

한 신인은 토크 페이지에 어떻게 댓글을 남길지도 몰랐기 때문에 '+' 탭을 '댓글 남기기'로 바꿀 것을 제안한다.그녀는 그 생각을 좋아했다.

나는 이것이 MediaWiki:를 편집함으로써 달성된다고 믿는다.추가 섹션.대담하게 하고 싶지만, 그건 좀 너무 대담해...

다른 사람들은 어떻게 생각하는가?— 오메가트론 16:18, 2007년 6월 16일 (UTC)[응답]

그럴 필요 없어.플러스 탭은 나에게 즉각적인 의미가 있었다. 왜냐하면 그것은 무언가를 추가하는 것을 나타냈기 때문이다.하지만 그것은 단지 나 자신의 경험에 근거한 것이다. 왜냐하면 나는 다른 위키백과 편집자나 진지한 사용자들을 알지 못하기 때문이다.좁은 뷰포트에서는 긴 탭이 개인 링크와 매우 가깝기 때문에 번거롭다.아드리안 M. H. 20:59, 2007년 6월 16일 (UTC)[응답]

플러스 아이콘을 800x600으로 변경하면 화면이 깨질까 봐 걱정이다.x4206 Talk Mess 21:16, 2007년 6월 16일 (UTC)[응답]

눈치채지도 못했다.+오랫동안, 하지만 그건 나뿐이야토크 페이지에서는edit this page보다 덜 강조되어야 한다(언어화되지 않음+때문에+아마도 더 자주 쓰일 것이다.edit this page사람들은 단지 클릭만 하면 된다.edit this page맨 위에 있는 배너를 변경하거나 페이지 전체를 리팩터링하고 싶을 때개별 섹션에 응답하려면 섹션 자체 사용[edit]링크하다. 만약discussion로 단축되다talk그리고edit this page로 단축되다edit또는 보다 직관적으로 이름을 바꾸었다.edit entire page그때+로 이름을 바꿀 수 있다.add section뭐 그런 거.800x600은 처리할 수 있어야 한다. –Pomte 21:27, 2007년 6월 16일 (UTC)[응답]

나는 토크 페이지에서 "편집"을 강조하지 않고 "새로운 섹션"과 섹션 편집 링크를 강조하는 것에 전적으로 동의한다.— 2007년 6월 23일 01:00 (UTC)[응답]

나는 800x600을 달리는데 "댓글 남기"가 잘 맞을 것이다.이것과 저것 그리고 나머지 07:22, 2007년 6월 17일 (UTC)[응답]

이것은 800x600으로 다양한 브라우저와 글꼴 크기로 많은 테스트를 필요로 할 것이다.탭이 넘치면 사라지는 경향이 있는데, 아주 나쁜 것이다.— 칼 (CBM · talk) 08:04, 2007년 6월 17일 (UTC)[응답]

토크 페이지가 포럼 구조로 되어 있을 때, "새로운 게시물" 버튼이 있을 것이고 모든 것이 이치에 맞을 것이다.그들은 섹션 헤더를 만들거나 그들의 게시물에 서명하는 방법을 알 필요가 없을 것이다.Dcoetzee 08:05, 2007년 6월 17일 (UTC)[응답]

응, 내 폰트 크기를 40으로 설정하면 탭이 넘치니까 그냥 한 글자로 바꿔야 할 것 같아. :-) — 오메가트론 15:05, 2007년 6월 17일 (UTC)[응답하라]

나는 위에 있는 가장 짧은 버튼 라벨을 좋아한다. 2007년 6월 17일 16:16, 2007년 6월 17일 (UTC)[응답하라]

고급 사용자들을 위해 Javascript와 CSS로 모든 것을 커스터마이징하는 방법이 있고 15개의 탭이 있는 sysops가 있지만, 기본 사용자 인터페이스는 최신 신인을 대상으로 해야 한다.이런 맥락에서 '+'는 거의 의미가 없다.— 오메가트론 19:01, 2007년 6월 17일 (UTC)[응답]

나는 이 제안이 역사상의 이유나 그런 이유로 거부된 적이 있었던 것을 기억한다. 하지만 만약 통과된다면, Special:에 다른 메시지가 있다.또한 변경해야 할 수 있는 모든 메시지.–폼테 23:55, 2007년 6월 17일 (UTC)[응답]

"역사적 이유"?바. :-) — 오메가트론 00:35, 2007년 6월 23일 (UTC)[응답]

만약 우리가 "토론"을 "토크"로 바꾼다면(아래 제안 #39 참조), "+"를 "새로운 게시물"로 바꿀 여지가 있을 것이다.덤불 속의 두 마리 새나 뭐 그런 것... 비엘 01:31, 2007년 6월 19일 (UTC)[응답하라]

공간을 절약하려고 하면 '논의'가 더 나을 것 같다.— 오메가트론 00:35, 2007년 6월 23일 (UTC)[응답]

'이 페이지 편집'은 볼 수 있는 페이지에 적용되는 작업이다.'토론'과 '기사'는 우리가 가는 곳이다.'이 페이지 편집'에서 회색 줄을 제거하면 탭이 적용되는 대상이 무엇인지 알 수 있는지 궁금하다.그러면 '이 페이지 편집'을 '편집'으로 바꿀 수 있을 겁니다.그렇게 되면 우리에게 '+'를 어떤 친근한 동사로 바꿀 수 있는 여지가 생기게 될 것이다.톰 해리슨 2007년 6월 23일(UTC) 17:50[응답]

나는 지금까지 계산에 대해 알지 못했다.나는 그 변화에 전적으로 동의한다.그것은 유용한 탭이고 편집자들이 그것이 존재한다는 것을 알기 위해 1년 이상 기다려야 할 이유가 없다.A.Z. 02:26, 2007년 6월 25일 (UTC)[응답]

만약 그것이 "댓글 남겨두기"로 바뀌게 되면, 그것이 매우 길다는 것을 고려하여, 나는 대화 페이지의 "이 페이지를 편집"으로 바꿀 것을 제안한다.기사에 "이 페이지를 편집한다"고 하는 것은 좋지만, 토크 페이지에서는 좋은 생각이 아니다. --Steinninn 09:21, 2007년 6월 28일 (UTC)[응답]

내가 위키피디아에게 존경받는 "고전적인" 피부를 선호하는 이유 중 하나이다.왼쪽에는 "이 페이지 편집", "페이지 토론" 등이 있는데, 나 같은 단순한 남자치고는 충분히 간단하다.나는 단지 CSS를 배우고 피부를 최신 상태로 유지하는데 도움을 줄 수 있는 끈끈이 있었으면 좋겠다. -- 2007년 6월 28일 (UTC)

내가 바꿨어.내가 편집 요약에서 말했듯이, 이 제안은 거의 한 달 동안 약간의 복수 지원으로 여기에 있어왔다.

이것이 반드시 최종적인 것은 아니지만, 지역적인 합의보다는 훨씬 더 많은 논의와 세계적인 합의를 이끌어내야 한다.탭이 아닌 다른 페이지에서 이 메시지를 전달하는 문제가 발생하는 경우 언제든지 되돌리십시오.그렇지 않으면 사람들이 그것을 볼 수 있도록 내버려두고, 그들이 변화를 좋아하는지 아닌지를 결정하고, 그것을 유지해야 하는지에 대해 좋은 합의에 도달할 수 있도록 해달라.— 오메가트론 06:09, 2007년 7월 13일 (UTC)[응답]

너무 길다, IMO. 이해하기 쉽게 하려면 추가라고 불러라. 하지만 인터페이스에 다른 탭을 추가하는 사람들처럼 탭이 너무 길어지고 있다.이제 마지막 탭을 보려면 전체 화면으로 이동해야 한다. 루카스브talk 10:53, 2007년 7월 13일(CoordinatedUniversalTime)[응답하라].

나도 동의해, 유용하기엔 너무 길어."이 페이지 편집"이 "편집"이 되거나 이 "설명 남겨두기"를 "+"로 축소해야 한다.어느 쪽이든 상관없지만 지금은 너무 길다. --Tim4christ17 13:51, 2007년 7월 13일 (UTC)[응답]

나는 "+"가 아무 의미 없다는 것에 동의한다.내 제안은 "추가" 또는 (우선) "코멘트 추가" 입니다. --에덕터(토크) 13:29, 2007년 7월 20일 (UTC)[응답]

좋은 생각이야; 아마도 이것은 (메타 기사 자료를 그룹화하고 사람들이 이미 존재하는 댓글을 읽을 수 있도록 하는) 토크 페이지에서만 도달할 수 있을 거야?라가소스 03:32, 2007년 7월 27일 (UTC)[응답]

토크 페이지

요약: 탭 제목 변경(MediaWiki:talk label)에서 'talk'까지.

(이 실의 처음 몇 개의 게시물은 위키백과의 대화에서 옮겨졌다.참조 데스크#대화 페이지)

내가 처음 위키피디아를 발견했을 때, 나는 "대화" 페이지를 찾는데 많은 시간을 보냈다.나는 영어 원어민이고 '토크'와 '토론'이 같은 의미라는 것을 알지만, '토크 페이지'의 전능성으로 인해 덜 격식을 차리지 않은 것이 의미 있다고 믿게 되었다.나는 그 때나 지금이나 "토론 페이지"에 대한 참조를 어디서도 찾지 못했다.왜 우리는 "토론"에서 "토크"로 탭을 변경하지 않고 모든 신입 사원을 약간의 혼란스럽게 하지 않는가?우리는 편집자들의 텍스트 습관을 바꿀 것 같지 않다.비엘 15:07, 2007년 6월 17일 (UTC)[응답하라]

더 이상 말이 되지 않았다.나는 그 변화에 동의한다.A.Z. 18:04, 2007년 6월 17일 (UTC)[응답]

위키백과 대화를 참조하십시오.토크 페이지 가이드라인#토론 페이지 가이드라인토론 페이지를 "대화 페이지"라고 부르는 것은 영어 위키백과에 특화된 전문용어인데, 예를 들어, 프랑스어 위키백과에서 말하는 대화 페이지는 토론의 데스페이지인 반면, 독일어를 사용하는 위키백과에서는 디스쿠션세이텐이 있다.제안이 효과를 거두려면 위키피디아에 게시하십시오.마을 펌프 (제안). --람밤^Talk 19:17, 2007년 6월 17일 (UTC)[응답]

이것은 아마도 다른 언어들이 "대화 페이지"와 동등한 것을 가지고 있지 않기 때문에 일어날 것이다.A.Z. 19:28, 2007년 6월 17일 (UTC)[응답]

뭐? 물론 대화 페이지도 있지 다른 언어 위키피디아도 보고 목록도 보고금요일 (토크) 2007년 6월 17일 (UTC) 19:34[응답]

금요일, 나는 다른 언어 위키피디아들이 대화 페이지와 동등한 것을 가지고 있지 않다는 것을 의미하지는 않았다.다른 언어에는 토크 페이지와 같은 표현이 없기 때문에 토론 페이지와 동등한 표현을 사용하는 것이 유일한 방법이라는 뜻이었다.로맨스 언어와 독일어는 모두 같은 의미인 토론이라는 단어에 대한 인식을 가지고 있기 때문에 가장 분명한 번역이 된다.A.Z. 19:45, 2007년 6월 17일 (UTC)[응답]

다른 언어가 '토론'보다 덜 격식을 갖춘 말을 하지 않는다는 생각은 터무니없다.아트로포스 21:28, 2007년 7월 13일 (UTC)[응답]

나는 단지 변화를 제안하는 데 있어서 영어 위키피디아를 언급했을 뿐이다.나는 다른 위키피디아(-pediae?)의 태그가 무엇이든, 언어와 언어의 사용에 적합하다고 생각했다."disc(k)uss"의 루트 맞춤법으로 표현되는 것처럼 태그에 어느 정도 일치할 필요가 있는가?예를 들어 중국어와 시각적인 연관성은 없을 것이기 때문에, 내가 지금 그것을 보고 있는 지금, 그것은 어리석은 질문일 수도 있다.그런 문제들이 논의되는 페이지들에 대한 조언에 감사드리며, 람비암, 그리고 그 논의의 더 좋은 장소로.효과를 볼 수 있는 기회를 갖는 것에 대해, 나는 그 제안이나 그 수용에 아무런 투자도 하지 않았다.그것은 단지 (a) 사용의 용이성과 (b) 일관성에 대한 편집자의 관심을 반영한다.2007년 6월 17일(UTC) 비엘레 19:40[응답]

그대로, 그 태그들은 모든 위키피디아 사람들이 이 페이지들을 부르는 방식과 일치하지 않고, 그것과 다른 것들로 인해 사용하기 더 어렵다.A.Z. 19:48, 2007년 6월 17일 (UTC)[응답]

나는 위의 람비암의 첫 번째 링크를 살펴본 적이 있다.똑같은 질문을 던지지만 내가 볼 수 있었던 논의나 결정은 없다.어쩌면 후속 조치를 어떻게 찾아야 할지 모르겠어.나는 또한 빌리지 펌프의 FAQ, 페레니얼 제안 및 현재 제안사항을 살펴봤고, 이전의 유사한 제안은 볼 수 없었다.위키백과의 경우:마을 펌프(제안), #33, "+" 탭의 논의가 있다.그리고 나서, 이곳은 "Talk" 페이지에 디스커버리지를 보관하는 장소로 나타날 것이다.이 줄기를 따르는 사람이 관련 부분을 위키백과로 옮기는 방법을 알고 있다면:마을 펌프(제안), 대담하게 하십시오.비엘 20:44, 2007년 6월 17일 (UTC)[응답하라]

분명히 보호된 페이지를 편집할 수 있는 권한을 가진 사용자는 이 페이지를 변경해야 한다.변화는 논란의 여지가 없으며, 만약 내가 그런 특권을 가진 사용자였다면, 나는 지금 당장 그것을 만들 것이다.A.Z. 21:52, 2007년 6월 17일 (UTC)[응답]

우리가 고려할 시간을 주기 전까지는 그 제안이 논란의 여지가 없다고 말할 수 있을지 모르겠다.변화는 거의 항상 누군가에게 논란이 되고 있으며, 누군가(또는 그 "어떤" 사람들)는 대응할 수 있는 시간이 필요하다는 것이다.결국 토크(토론) 페이지가 나오는 이유다.따라서 내게 특권이 있다고 해도 며칠을 기다릴 것이다.여기서는 급한 일이 없다.비엘 22:56, 2007년 6월 17일 (UTC)[응답하라]

이해한다.그럼 나도 며칠 기다리겠지만 이건 좀 논란의 여지가 없는 것 같아.A.Z. 23:10, 2007년 6월 17일 (UTC)[응답]

나는 왜 우리가 이 페이지를 모두 Talk page라고 부르는지 궁금하다. 본문은 항상 논의되었던 것 같다.어쨌든, 나는 Talk가 더 좋은 생각이라고 생각한다. 나머지 인터페이스들은 이 페이지들을 Talk page (My talk page 링크까지) -- Lucasbfrer 13:16, 2007년 6월 18일 (UTC)[응답]

문제는 두 단어의 미묘한 문맥적 차이다."대화"는 그들이 원하는 것이 아닌 "대화"를 지지하는 것으로 해석될 수 있다. 반면에 "토론"은 더 공식적인 의미와 동의어다.그러나 "토크페이지"는 주로 타이핑이 빠르고, "토론페이지"보다 혀/눈을 더 잘 굴리기 때문에 일반적으로 사용된다.만약 우리가 모든 사람들에게 그들을 "토론 페이지"라고 부르도록 강요한다면, 그들은 그저 이해할 수 없는 약자를 만들었을 것이다!이러한 이유들로 인해 나는 현 상태에 대한 어떠한 변화도 있을 것 같지 않다(어떤 것이든 가능할지라도).--Quiddity 18:09, 2007년 6월 18일 (UTC)[응답]

퀴디티는 '직접 상황차이'에 대한 설명으로 정곡을 찔렀기 때문에, 나는 그의 진술을 승인하는 것 이외에는 아무 말도 하지 않을 것이다.TenOfAllTraes(대화) 2007년 6월 18일(UTC) 18:30[응답]

사실, "직접 상황적 차이"가 있다.영어는 그런 것들로 가득 차 있다.그러나 아무도 내가 알 수 있는 한 이견에 주의를 기울이지 않고 있는데, 그것은 어쩌면 "너무 멀리까지"라는 뜻일 수도 있다."토론"도 마찬가지로 "대화"가 될 수 있다. 그 차이는 대화의 내용보다는 대화의 언어의 설정과 형식에 더 많이 달려 있다.모든 사람은 토론 탭과 연결된 것을 "대화 페이지" 또는 단순한 "대화"라고 말하며, 우리가 그것을 장려하고 싶든 원하지 않든, 토론, 협상, 논쟁, 통지, 비난, 항의, 광고, 애원, 요구, 그리고 화면에서 가능한 거의 모든 다른 행위들과 함께 대화와 채팅을 그곳에서 한다."대화"와 "대화"의 차이는 "직접 상황 차이"의 또 다른 예다.하지만 '챗'은 온라인에서 특정한 의미를 지니고 있으며, 실제로 우리가 권장하고 싶은 것은 아니다.그러나 영어 위키에서 "토크 페이지"는 "토론 페이지와 거기서 실제로 일어나는 일"을 의미한다.단지 대화가 채팅이 아니라는 점을 강조하기 위해 탭이 "토론" 라벨을 유지하도록 주장하는 것은 불필요하게 혼란스러워 보인다. (WP:포인트가 만들어지는 것은 파괴적이지 않으며, 특히 신인에게 도움이 되지 않는다.)비엘 19:58, 2007년 6월 18일 (UTC)[응답하라]

나는 의견을 달리하지 않으면 위키피디아와 같은 페이지가 필요하지 않을 것이다.위키로위어링.해석의 한계를 넘어설 사용자들이 있다고 생각한다.이러한 이유로 채팅으로 오해될 수 있는 것은 피해야 한다.데이비드 D. (토크) 2007년 6월 18일 (UTC) 20:56[응답]

정의에 관한 한 가지 예로, 말은 입으로 말하는 것처럼 말하는 것을 의미한다.토론은 여전히 그것을 쓰는 것을 의미할 수 있다.페이지 제목이 짧아서 그렇다.나는 개인적으로 탭을 위해 '토론'을 계속 사용하는 것에 찬성한다.레이와스92^{TalkReview me} 22:33, 2007년 6월 18일 (UTC)[응답]

어떤 것도 "대화"로 오해될 필요는 없다, 데이비드 D.지금 곳곳에서 일어나고 있다.(백 명 이상의 수다쟁이들이 당황할 수도 있다는 점만 빼면 구체적인 대화 페이지로 연결하겠다.대부분의 경우, 사용자 대화로 제한된다.)나 또한 레이와스92에 동의하지 않는다.온라인 상에서, "대화"는 음성 시스템이 구체적으로 언급되지 않는 한 "쓰기"를 의미하는 것으로 이해된다.처음에 탭으로 "토론"을 선택한 이유는 의심할 여지가 없으며, 위키백과는 다음과 같다.위키리거링은 가장 미세한 포인트로 현실이다.그럼에도 불구하고 탭으로서의 '토론'은 여전히 혼란스러우며, 혼란을 없애는 간단한 방법이 있다.아직 아무도 이 문제를 거론하지 않았는데, 이것이 그 변화를 제안하는 유일한 이유다.그리고, 신입 사원의 보살핌과 보관을 위해, 위의 33의 오프닝 코멘트와 "+" 표지에 대한 다음의 모든 평판을 보아주십시오.비엘 23:14, 2007년 6월 18일 (UTC)[응답]

나는 혼란스러움을 이해할 수 없다.그 페이지들은 기사 내용에 대한 토론을 위한 것인데, 꽤 분명한 것 같다.동의하는 사람은 그것을 대화라고 부를 수도 있지만, 그 페이지가 제공하는 서비스는 분명히 꽤 설명적이다.적어도 나는 그것이 부적절한 이름이라고 생각해 본 적이 없다.대부분의 신입들은 정말 그렇게 혼란스러운가?데이비드 D. (토크) 02:19, 2007년 6월 19일 (UTC)[응답하라]

나는 대부분의 신입 사원들은 말할 수 없다.나는 "토크 페이지"를 찾는데 상당한 시간을 보냈다고 말할 수 있다.나는 '토론' 탭을 찾아 무엇을 위한 것인지, 거기서 무슨 일이 벌어지고 있는지 알고 있었지만, '토크 페이지'라는 이름이 도처에 널려 있어 '토론'과는 사뭇 다른 것이라고 추측했다.만약 당신이 대화 페이지를 내부 검색한다면 당신은 모든 표현에서 "대화 페이지"에 대해 읽을 수 있다."논의"와 "논의"는 부차적인 의미다.그 기사는 심지어 페이지의 상단이나 측면에 "대화"(또는 "논의")라는 라벨이 붙은 것을 찾아야 한다고 언급하고 있다.내가 제안하는 것은 우리가 실제의 사용과 "토크 페이지" 기사가 이미 그렇다고 믿는 것을 탭 시스템에 반영하여 신입 사원에게 하나의 장애물이 줄어들도록 하자는 것이다.분명히 우리 모두 다 알아냈을 거야, 결국. (아마도 신입이 정말로 위키 편집자 자료인지 확인하기 위한 비밀 시험일 거야.아마도 나는 배우는 속도가 느릴 것이다.)우리가 변화를 만들지 않으면 세상은 무너지지 않을 것이다.여기서 언급된 재출발부터 사소한 문제라고 생각한 것까지, 모든 편집자들이 좀 더 새로운 친화력을 갖추기 위해 같은 목적을 가진 "토크 페이지" 대신에 "토론 페이지"를 참조하도록 하는 것이 더 쉬울 것이다.어디서 그런 제안을 할지 궁금하다. :-)Bielle 02:46, 2007년 6월 19일 (UTC)[응답하라]

나는 "대화"가 특히 온라인에서 "쓰기"를 의미하는 데 사용될 수 있다는 것에 완전히 동의한다.그것은 "커뮤니케이션" 또는 "커뮤니케이션"이라는 것을 의미한다.그래서 거의 모든 위키피디아 사람들이 자신들을 대화 페이지라고 부르는데 편안함을 느끼는 것이다.Reywas92, 당신은 일반적으로 이 페이지를 "토론 페이지"라고 부르십니까?A.Z. 19:50, 2007년 6월 24일 (UTC)[응답]

오해하지 마십시오. 탭의 "토론"이라는 레이블을 붙이는 것은 매우 혼란스럽다는 데 동의하지만, 모든 사람(도움말 페이지 포함)이 지속적으로 해당 탭을 대화 페이지로 언급하도록 하십시오.특히 신인, 젊은 편집자, 그리고 ESL 편집자들에게 그렇다.

위키피디아에서는 볼 수 없지만, 나는 이것이 영원한 제안이라고 추측하고 있다.지속적인 제안 또는 위키백과:마을 펌프(매년 제안)#Talk 네임스페이스(및 기타 토론) 관련 제안하지만, 여기에 그것을 논의해야 할 정확한 장소가 있다(!). 그리고 나는 개인적으로 미디어위키의 변화에 반대하지는 않을 것이다.현 상태가 유지되어야 한다는 새로운 설득력 있는 증거를 배제하고 "대화"라고 말하도록 하라.

이 아이디어의 과거사에 대해 아는 늙은이가 있나?(그것들은 정확히 검색 포드로 사용할 "독특한 용어"가 아니에요..! --Quiddity 18:20, 2007년 6월 19일 (UTC)[응답]

나 역시 네가 말한 모든 곳에서 역사를 찾아 다녔고, 그런 변화에 대해 일찍이 아무것도 발견하지 못한 것은 너무나 단순한 생각인 것 같았다.나는 이 모든 것을 첫 단락에서 말했고, 다른 사람들의 노력을 덜어주었어야 했다.뭐 찾은 사람 있어?2007년 6월 19일(UTC) 비엘 23:00[응답]

1. 우리는 무엇보다도 신참에 대한 접근성을 강조해야 한다.우리는 새로 온 사람들이 그 사이트를 아주 쉽게 만들 필요가 있다.
2. "논의" (verb)가 "논의" (noun)보다 더 나은 선택이 될 것인가?— 오메가트론 01:03, 2007년 6월 23일 (UTC)[응답]

'토론'은 '토론'보다 적극적인 참여를 제안하지만, '토크 페이지'에 대한 혼란은 그 변화로 해소되지 않는다.우리가 "대화"나 "대화 페이지"라고 이름 붙여진 것을 가지고 있지 않는 한, 혼란은 여전하다.비엘 01:25, 2007년 6월 23일 (UTC)[응답하라]

나는 우리가 무엇보다도 신인들에 대한 접근성을 강조해야 한다는 것에 동의한다.개방성은 위키피디아에 숨겨진 모든 생각이야!우리가 10년 전에 "모든 사람들이 온라인 백과사전을 편집하도록 하자"고 제안했다고 상상해 보라.누군가는 분명히 "아니, 사람들은 수다를 떨기 시작할 것이고, 그것은 소셜 네트워크가 될 것이고, 그것은 결코 작동하지 않을 것이다"와 같은 것들을 생각해 낼 것이다.위키피디아가 만들어졌고 누군가가 "누구나 편집할 수 있는 메인 페이지에 글을 쓰자"고 제안했다고 상상해보자.확실히 누군가는 "아니오, 백과사전이 거대한 대화방으로 변할 것이기 때문"이라고 말할 것이다.그냥 두려움일 뿐이야.태그의 이름을 바꾸면 사람들이 위키피디아의 핵심 측면인, 즉 토크 페이지를 더 빨리 이해할 수 있기 때문에 새로운 사용자가 웹사이트에 더 쉽게 접근할 수 있게 됨으로써 위키피디아가 개선될 것이며, 이것은 위키피디아가 선택된 소수만이 이해할 수 있는 매우 신비로운 곳이라는 느낌을 약간 감소시킬 것이다.토크 페이지의 링크를 계속 "토론"이라고 불리게 하는 것은 사람들을 혼란스럽게 하고 좋은 편집자들이 프로젝트에 참여하지 못하게 할 뿐이다.A.Z. 02:30, 2007년 6월 24일 (UTC)[응답]

이에 대한 사람들의 입장을 (정확히!) 요약하자면 다음과 같다.

찬성:

• 비엘 : "왜 우리는 탭을 '토론'에서 '토크'로 바꾸지 않고 모든 신참들을 어느 정도 혼란스럽게 하지 않는 겁니까?"

• A.Z.:비엘의 말에 동의한다.

• 루카스bfr: "나는 Talk가 더 나은 생각이라고 생각한다. 나머지 인터페이스들은 이 페이지들을 Talk page라고 부른다."

• 오메가트론:."무엇보다 신인에 대한 접근성을 강조해야 한다"고 말했다.

• 퀴디티(MediaWiki) : "나는 개인적으로 미디어위키의 변화에 반대하지 않을 것이다.현상 유지가 필요하다는 새로운 설득력 있는 증거를 배제하고 '말하기'라고 말하도록 하라."

반대:

• 데이비드 D.:"대화라고 오해될 수 있는 것은 피해야 한다."

• 레이와스92:"말하는 것은 입으로 말하는 것처럼 말하는 것을 의미한다.토론은 여전히 그것을 쓰는 것을 의미할 수 있다."

A.Z. 17:36, 2007년 6월 24일 (UTC)[응답]

그것은 내 입장을 형편없이 요약한 것이다!나는 특별히 변화에 반대하지 않겠다고 말했다.나는 단지 토론이 왜 현재 사용되는 단어인지, 그리고 왜 정식 명칭과 비공식 용어의 차이가 있는지 지적하고 있었다.내가 보기에는 아마 변경되어야 할 것 같아. --Quiddity 17:56, 2007년 6월 24일 (UTC)[답글]

내가 게시글을 바꿨기 때문에 너는 변화를 지지하는 그룹에 속해 있어.A.Z. 18:02, 2007년 6월 24일 (UTC)[응답]

고마워;) --Quiddity 19:17, 2007년 6월 24일 (UTC)[응답]

나도 이 변화에 찬성한다고 말하지 않았다.자신의 지위에 대한 인식에 따라 사람들을 그룹으로 묶는 것은 대개 좋지 않은 생각이다.우리가 실제로 어떻게 생각하는지 보고 싶으면 여론 조사나 뭐 그런 거...

원하는 옵션으로 서명하십시오.다른 옵션을 얼마든지 추가하십시오.— 오메가트론 01:20, 2007년 6월 26일 (UTC)[응답]

여론조사는 뭔가 도움이 될지 모르지만 선거가 되지 않았으면 좋겠다.위에서 토론하고 그런 토론이 더 유용하고, 여론조사가 토론의 일부였다면 유용할 것이라고 생각한다.누가 납득할 수 있도록 남겨졌는지 쉽게 알 수 있기 때문에 내 자리가 유용하다고 생각했다.A.Z. 02:55, 2007년 6월 26일 (UTC)[응답]

이제 열흘이 지났다.계속 논의할 수는 있지만, 이제는 관리자가 변화를 줄 때가 된 것 같아.A.Z. 03:20, 2007년 6월 27일 (UTC)[응답]

이제 20일이 지났다.A.Z. 22:34, 2007년 7월 8일 (UTC)[응답]

레이워스92는 "병행주의(문법) 때문에 '논의'가 통하지 않을 것"이라고 썼지만, "이 페이지를 편집하라"(아마 "페이지판"이어야 할까?)라는 버튼이 있다.탭을 "대화"로 바꾸지 않는 것에 대한 그들의 주장은 여전히 "대화"는 입으로 말하는 것을 의미하지만, 토론은 여전히 그것을 쓰는 것을 의미할 수 있다.이것은 단순히 사실이 아니다: 사람들은 입으로 말하는 것이 아닌 다른 방식으로 의사소통을 하기 위해 항상 대화를 한다.그들은 또한 "나는 정말로 무언가를 초대할 필요가 없다고 생각한다"고 썼다.프로젝트의 개방성 때문에 모든 것이 초대되어야 한다: 사람들이 많을수록 좋다.A.Z. 22:34, 2007년 7월 8일 (UTC)[응답]

tjstrf와 Gnangarra는 "토론"을 "대화"로 바꾸는 것에 반대한다는 같은 주장을 가지고 있다: 그들은 "토론"이라는 단어는 "대화"라는 단어보다 대화 페이지에서 일어나는 일을 더 잘 묘사한다고 말한다: 그들의 말에서 "탭들은 있는 그대로의 단어들이 상당히 명료하게 표현되어 있고, 따라서 "대화"는 덜 혼란스럽고 덜 복잡하며," 그리고 "나는 '토론'을 선호한다.s 타인의 의견을 실제로 들어야 한다는 암묵적인 맥락이 있다.'토크'가 타인의 의견을 들어야 한다는 기대와 관련되지 않는 곳이라면 말이다."토크 페이지가 '챗방'인 '토크'라는 단어에 대한 특별한 해석에 대해 우려를 강조하지만 데이비드 D.의 주장도 비슷하다.

그럼에도 불구하고 탭 변경에 대한 원래 주장은 페이지 이름이 "토크 페이지"라는 것이지, "토크"라는 단어가 토크 페이지에서 일어나는 활동에 대한 더 나은 설명이 된다는 것은 아니다.비엘의 말에서, "이제 나는 '토론 페이지'에 대한 참조를 찾았어, 그때도 아니고 지금도 아니야.왜 우리는 탭을 '토론'에서 '토크'로 바꾸지 않고 모든 신참들을 좀 혼란스럽게 하지 않는가?"나는 같은 문제를 겪어왔다.나는 사람들이 "대화 페이지"라고 말할 때 언급하는 것을 즉시 이해하지 못했다.만약 탭이 "말하기"라고 쓰여있다면, 나는 즉시 그것을 이해했을 것이다.

다른 탭의 이름은 그들이 링크하는 페이지의 내용을 정확하게 설명하려는 시도가 아니다."역사"라는 탭이 무엇을 의미하는지 추측하기는 어렵지만, 사람들은 그 페이지들을 "역사"라고 부른다."시계"를 가진 중소기업들: 여러분은 그것이 다른 곳에서 무엇을 의미하는지, 아마도 그것을 클릭하거나, 또는 그것에 대해 읽음으로써 배워야 한다.그럼에도 불구하고, 사람들은 "워치리스트"를 언급하고 "나는 그 페이지를 보고 있다"고 말한다.

아무도 어느 곳에서든 토크 페이지 토론 페이지에 전화를 걸지 않고, 그것은 몇몇 새로운 사람들에게 문제를 일으키는데, 그것이 비엘과 나를 걱정하는 주된 이유야.다른 사람들은 새로 온 사람들에 대해 그다지 걱정하지 않는 것 같지만, 다른 곳에 언급이 없을 때, 그 단어가 그곳에 있다는 것은 좀 우스꽝스러운 일이기 때문에 그 변화를 지지하고 있다.A.Z. 22:51, 2007년 7월 8일 (UTC)[응답]

나는 이것이 아직 바뀌지 않았다는 것에 놀랐다.위키백과 사용성은 끔찍하다. 129.120.159.176 13:58, 2007년 7월 12일 (UTC)[응답]

내가 미디어위키에 변화를 줬어:내가 편집 요약에서 말했듯이, 이 제안서는 거의 한 달 동안 약간의 다원적 지지를 받으며 이곳에 있었다.

이것이 반드시 최종적인 것은 아니지만, 지역적인 합의보다는 훨씬 더 많은 논의와 세계적인 합의를 이끌어내야 한다.탭이 아닌 다른 페이지에서 이 메시지를 전달하는 문제가 발생하는 경우 언제든지 되돌리십시오.그렇지 않으면 사람들이 그것을 볼 수 있도록 내버려두고, 그들이 변화를 좋아하는지 아닌지를 결정하고, 그것을 유지해야 하는지에 대해 좋은 합의에 도달할 수 있도록 해달라.— 오메가트론 05:50, 2007년 7월 13일 (UTC)[응답]

또 다른 이용자는 마을 펌프에 대해 아무런 설명도 하지 않고 오메가트론의 변화를 되돌렸다...이제 안드레의 결정은 여기서도, 여기서도 논의되고 있다.마을 펌프에 대한 논의를 집중화해서 모두가 참여할 수 있고 모든 것이 한 곳에 머물 수 있도록 하자는 제안이다.내 의견은 변화를 되돌리자는 안드레의 주장이 틀렸다는 것이다: 그는 그 탭이 "토크"로 명명될 수 있도록 합의가 있어야 한다고 말하지만, 나는 그것이 "토론"으로 명명되어야 한다는 합의가 없을 때 "토론"으로 명명되는 것이 왜 더 좋을지 모르겠다.하지만 나는 해결책이 무엇인지 모른다.A.Z. 18:20, 2007년 7월 14일 (UTC)[응답]

2점 1점.나는 모든 사람들이 그것이 너무 간단하다고 생각하는 것을 좋아한다. 그리고 그것이 실제로 그들에게 지적되고 나면, 그것은 전에 제안된 것이 틀림없다는 것을 너무나도 명백해 보인다! 2.나는 또한 아무도 그들이 토크 페이지라고 불리는 이유가 그들이 토크 네임스페이스에 있기 때문이라고 제안하지 않은 것이 놀랍다.모건 윅 06:56, 2007년 7월 13일 (UTC)[응답]

의견조사: 토론 탭

"토론" → "대화"

1. "Talk:"와 "Wikipedia Talk:"와 같은 제목 접두사 때문에 나는 이해가 된다.— 오메가트론 01:20, 2007년 6월 26일 (UTC)[응답]
2. 이것은 전체적으로 사용되는 언어를 반영한다.wiki 그리고 새로운 사람들이 이해하기 가장 쉬울 것이다.이러한 이득은, 내 생각에, 그 변화가 "대화"를 위한 초대장으로 비춰질 가능성보다 더 크다고 생각한다.비엘 01:38, 2007년 6월 26일 (UTC)[응답]
3. 신입, ESL 편집자, 젊은 편집자에게 가장 분명한 것.도움말 페이지 전체에서 거의 일관적으로 사용되며, 정상적인 사용에서도 일관적으로 사용됨. --Quiddity 01:53, 2007년 6월 26일 (UTC)[응답]
4. 나는 그 변화에 찬성한다.나는 위의 실에 그 이유를 설명했다.A.Z. 03:03, 2007년 6월 26일 (UTC)[응답]
5. — 미친 범인과 천사 (대화 – 책상) 03:52, 2007년 6월 26일 (UTC)[응답]
6. 네임스페이스에 맞춰 정렬할 수 있도록만 하십시오.그리고 적어도 그것은 짧다.아드리안 M. H. 15:46, 2007년 6월 26일 (UTC)[응답]
7. 강력한 지원 - 이것은 네임스페이스 이름과 일치한다; 내가 보기에 의미는 분명하고, 더 짧다.오드 미셰후 08:47, 2007년 6월 27일 (UTC)[응답]
8. 강력한 지원 - 새로운 사용자(및 원어민)로서, 토크 페이지와 토론 페이지가 같다는 것을 깨닫는데 몇 분이 걸렸다.게다가, 그것은 미셰후가 말한 것처럼 더 짧다.스파즈어 05:26, 2007년 7월 14일 (UTC)[응답]
9. 누구나 그렇게 부른다.왜 신참들을 혼란스럽게 하는가. --Apoc2400 08:25, 2007년 6월 28일 (UTC)[응답하라]
10. 또는 "talk" -> "토론" 그러나 네임스페이스는 제쳐두고, 모든 사람이 대화 페이지라고 부르지 않도록 행운을 빈다. --Random832 19:42, 2007년 7월 4일 (UTC)[응답]
11. 토크: 네임스페이스(Talk: 네임스페이스)에 있기 때문에, 사람들은 그들이 실제로 뭐라고 부르든 간에 계속해서 "대화 페이지"라고 부를 것이고, 만약 그들이 포럼이 될 것을 걱정한다면, "이것은 기사 Blah를 토론하기 위한 페이지"라는 표준의 하나를 머리글에 추가하기만 하면 된다. 그리고 위키피디아가 무엇인지 사람들에게 경고하면 된다.NOT. 헷갈리는 표현 03:48, 2007년 7월 5일 (UTC)[응답]
12. 짧을수록 좋다.이 두 가지 의미는 "컴퓨터 작업에 충분히 가까운" 것이다.스투랫 23:45, 2007년 7월 9일 (UTC)[응답]
13. 나는 그것이 전체적인 사이트 일관성을 위해 만들어진다는 것에 동의한다.라라러브^T/_C2007년 7월 13일 03:18 (UTC)[응답]
14. 우리는 이미 그때의 대화 페이지에 전화를 걸었기 때문에... -- 루카스브르 11:46, 2007년 7월 13일 (UTC)[응답하라]
15. 짧고 단순함 - 또한 내부 일관성과도 작동함. --Tim4christ17 14:02, 2007년 7월 13일 (UTC)[응답]
16. 새로운 기여자들이 배울 수 있는 전문용어 한 마디 줄임. --Ybbor^Talk 15:03, 2007년 7월 13일 (UTC)[응답]
17. 우리는 모두 그것들을 대화 페이지라고 부른다.현재의 연계 체계는 [[사용자 대화:NAME]]] 프로젝트 전체에 걸쳐 분산되어 있으며, WP 페이지 내 많은 부분을 포함하여, 대화 페이지에 대한 참조가 매우 많다.혼란을 피하려면 탭이 "talk"라고 말해야 하는가? --Anthony.bradbury^"talk" 12:37, 2007년 7월 14일(UTC)[응답]
18. Djmckee1 강력 지원 - Talk 06:27, 2007년 7월 18일 (UTC)[응답]
19. 어쨌든 토크 네임스페이스에 있다. -- 네드 스콧 06:38, 2007년 7월 20일 (UTC)[응답하라]
20. 말이 된다.사용자 인터페이스는 사용적합성을 극대화하고 혼란을 최소화해야 한다.이러한 변화는 확실히 혼란을 최소화할 것이다. --WPholic (대화) 12:49, 2007년 7월 20일 (UTC)[응답]
21. 그것은 더 짧고 네임스페이스라고 불리는 것이다.아마도 "대화 페이지"가 더 나을 것이다.쿠스마 (토크) 2007년 7월 20일 12시 54분 (UTC)[응답]
22. Talk 페이지라고 하는데 --Edokter (Talk) 13:32, 2007년 7월 20일 (UTC)[응답]
23. 다들 벌써 '토크 페이지'라고 하지 않나?user_토론 아닌 user_talk도 입니다. --Eivind Kjørstad 08:32, 2007년 7월 27일 (UTC)[응답]
24. 퍼 오메갓론 - 대통령
25. 말이 된다. Tcrow777 talk 23:54, 2007년 7월 29일 (UTC)[응답]

"토론" → "논의"

1. "토론"보다 더 많은 초대 공간을 절약한다.— 오메가트론 01:20, 2007년 6월 26일 (UTC)[응답]
2. 나쁘지 않은 대안이다.그러한 변화에 찬성하는 위의 많은 주장들을 읽었음에도 불구하고, 나는 여전히 "대화"라는 생각이 마음에 들지 않는다.탭의 제목은 페이지를 토론하거나 토론하기 위한 초대장으로 보아야 한다.편집자들의 마음속에 토크 초대가 떠오르는 것은 무엇인가?독백?IRC 채널?대화?토론은 이것보다 훨씬 더 중요하다.데이비드 D.(토크) 03:42, 2007년 6월 27일 (UTC)[응답]

   그래, 데이비드 D. 하지만 "논의"는 그 제안의 초기 이유에 대해 말하지 않는다. 그것은 어디에나 있는 것이다.위키에는 "대화" 페이지가 언급되어 있지만, "대화" 페이지는 없다.영어 위키백과에서 어떤 것도 읽을 수 없고 "Talk" 페이지에 대한 참조를 발견하지 못하지만, 그것들은 존재하지 않는다.2007년 6월 27일(UTC) 비엘레 18:03[응답]

3. 나는 오메가트론에 동의한다.~ sublime514 • talk • sign 23:08, 2007년 7월 4일(UTC)

"토론" 탭을 변경하지 않음

1. --Steinnin 01:45, 2007년 6월 26일 (UTC)[응답]
2. 그러나 나는 사람들이 정말로 토론이 너무 애매모호하다고 생각한다면 어떤 것이 실행 가능한 대안이 될 수 있는 토론에 대한 견해를 바꿀 이유가 없다고 본다.데이비드 D. (토크) 03:43, 2007년 6월 27일 (UTC)[응답]
3. 지금 이대로는 괜찮아. +스피비 ~ 07:35, 2007년 6월 27일 (UTC)[응답]
4. 반대 '토론'은 '말하기'로 바뀔 수 있지만, 평행주의(문법) 때문에 '논의'는 통하지 않는다.그러면 '기사' 탭을 '읽기'로 바꿀 필요가 있을 것이다.왜 초대하지?+ (나에게는 아니지만) 혼란스러울 수 있지만, '토론'은 그렇게 말한다. 나는 정말로 무언가를 초대할 필요가 없다고 생각한다.레이와스92^Talk 14:19, 2007년 6월 27일 (UTC)[응답]

   나는 어떤 종류의 문법 문제가 있다는 것에 동의하지 않는다; "토론", "기사" 그리고 "대화"는 모두 명사가 될 수 있다.비엘 17:49, 2007년 6월 27일 (UTC)[응답하라]

   하지만 '논의'는 할 수 없다.나는 내 의견이 옳다고 믿는다.레이와스92^Talk 13:01, 2007년 6월 28일 (UTC)[응답]

   미안; 내가 너의 원문을 잘못 읽었어.실제로 "논의"는 명사가 아니다;그러나 "기사"는 법대생이라면 동사가 될 수 있다. :-) 비엘 17:34, 2007년 6월 28일 (UTC)[응답]

   "이 페이지 편집"이라는 탭이 있어. A.Z. 03:45, 2007년 7월 27일 (UTC)[응답하라]

5. 무의미하다.탭은 있는 그대로의 단어들이 꽤 명확하게 쓰여져 있고 "대화"는 덜 서술적이기 때문에 더 혼란스럽고 덜 혼란스럽지 않다. --tjstrf talk 17:56, 2007년 6월 27일 (UTC)[응답]
6. — 데킬러 18:01, 2007년 6월 27일 (UTC)[응답]
7. '토론'은 타인의 의견을 실제로 들어야 한다는 묵시적인 맥락이 담겨 있어 선호한다."대화"는 다른 사람의 의견을 들어야 한다는 기대와 관련이 없다.Gnangarra 13:24, 2007년 7월 6일 (UTC)[응답]
8. 충분히 좋게 내버려 둬. --T --ε RαnΔom Διor (ταlκ) 22:34, 2007년 7월 12일 (UTC)[응답]
9. 아니, 괜찮으니까 바꾸기 전에 광고 좀 더 잘 해줘.안드레 (토크) 06:39, 2007년 7월 13일 (UTC)[응답]
10. "토크"는 사실 낯선 방문객에게 더 혼란스러울 것 같은 인상을 준다.동사는 참여를 의미하기 때문에 동사보다 명사를 선호한다.이와는 대조적으로, "토론"은 방문객들이 선택할 경우 수동적으로 볼 수 있는 것이다.2007년 7월 13일(UTC) 18시 18분 비행기[응답]
11. 변화는 필요 없다."토크"는 농담에 대한 초대장처럼 읽힌다.그러나, 토크 페이지 지침은 토크 페이지(아마도 사용자 토크 페이지 제외)가 헛된 수다와 무작위 토크에 사용되지 않는다는 것은 분명하다.그들의 목적은 토론이다. -- 검은 팔콘 02:32, 2007년 7월 14일 (UTC)[응답하라]
12. 어떻게 된 건지 괜찮아.— Xaosflux 03:05, 2007년 7월 14일 (UTC)[응답]
13. 68.39.174.238 16:20, 2007년 7월 21일 (UTC)[응답]

폴링: + 탭

"+" → "댓글 남기기"

1. 새로 온 사람치고는 더 선명하다.— 오메가트론 01:20, 2007년 6월 26일 (UTC)[응답]
2. 새로운 사용자 이해도 측면에서 최고일 가능성이 높지만, 너무 많은 공간을 차지할 수 있다.그렇다면 전반적으로 최고는 2007년 6월 26일(UTC) '뉴포스트' 비엘 01:43[응답]이다.
3. --Steinnin 01:45, 2007년 6월 26일 (UTC)[응답]
4. 약한 지지.나는 단지 "댓글"이나 "댓글 추가"를 선호한다 — 미치광이 범인과 천사 (대화 – 책상) 03:52, 2007년 6월 26일 (UTC)[응답]
5. 네. 이, 저, 그리고 나머지 07:26, 2007년 6월 27일 (UTC)[응답]
6. 좋은 생각이야.모든 사람이 암호 UI를 잘 알아내는 것은 아니다. --Apoc2400 08:30, 2007년 6월 28일 (UTC)[응답]
7. 우리는 평범한 사람들이 기여하기를 원하기 때문에 모든 것을 기술할 필요가 있다.A.Z. 18:06, 2007년 7월 1일 (UTC)[응답하라]
8. 아마도 여기서 내가 가장 좋아하는 옵션은 '+'(비 위키피디아 편집자들과의 나의 리얼 라이프 상호작용에서 사용적합성은 많은 작업을 필요로 한다는 것은 분명하다; 예를 들어, 이미지의 저작권 상태를 클릭해서 결정할 수 있다는 것은 전혀 명확하지 않다.이것은 일화적인 증거고 따라서 아마도 틀릴 것이다)는 모든 위키백과 이미지가 공공 영역이라는 것 같다.라벨을 더 선명하게 하는 것이 이 목표를 더 나아가는 한 가지 방법이다.) --ais523 12:41, 2007년 7월 6일 (UTC)
9. 오래 걸리긴 하지만 좋은 생각인 것 같아.위키피디아를 사용하기 시작한 후 몇 달 동안 이 탭을 사용하지 않은 것은 그것이 무엇인지 전혀 몰랐기 때문이며, 단지 클릭을 하지 않았기 때문이다.이제야 그게 뭔지 알게 되었으니 자주 쓰네.라라러브^T/_C2007년 7월 13일 03:25 (UTC)[응답]
10. 나 또한 좋은 생각이라고 생각해.대부분의 사람들은 그것이 무엇을 하는지 몰랐기 때문에 + 탭을 클릭하지 않고 모든 사람들이 모든 버튼을 사용하여 실험할 수 있을 만큼 충분히 "귀여운" 것은 아니기 때문에 그것이 무엇을 하는지 분명히 하는 것은 좋은 일이다. --_Hdt83 18:37, 2007년 7월 13일 (UTC)[응답]
11. 나는 이 변화를 보는 것이 너무 좋았고 다시 바뀌어서 속상해.이것은 내가 혼자서 어리둥절했던 기억이 나는 암호화된 "+"보다 신참자들에게 훨씬 더 선명하다.하우쿠르 00:23, 2007년 7월 15일 (UTC)[응답]
12. 강력한 지원 새로 온 사람들을 위한 클리어 그리고 그것이 바뀌었을 때 멋져 보였다.Djmckee1 - Talk 06:29, 2007년 7월 18일 (UTC)[응답]

"+" → "신규직"

1. 이것은 인터넷에서 일반적으로 인식되는 언어로서, "+" Bielle 01:41, 2007년 6월 26일 (UTC)[응답하라]의 단순한 "+" Bielle 01:41, 새로운 사람들에게 더 명확하다.
2. 그 탭은 유용하고 무슨 뜻인지 알아내기가 어렵다.심지어 보기조차 어렵다.A.Z. 18:08, 2007년 7월 1일 (UTC)[응답]
3. "코멘트 추가"는 그것이 *새로운* 코멘트라는 것을 의미하지 않기 때문에, 두 시스템 모두 경험이 없는 사용자가 회신을 추가하고 싶을 때마다 섹션을 추가하게 되는데, 이는 비효율적이고 성가신 일이다.모든 +가 새로운 게시물임을 암시하는 것은 그것을 정리하는데 도움이 될 것이다. -Wooty [Woot?] [스팸! 스팸! 멋진 스팸!] 2007년 7월 13일(UTC) 18:08, 18:08[응답]
4. +가 가야 할 경우, 각 코멘트를 게시물이라고 하는 경우가 많기 때문에 "새로운 섹션"이 더 명확해질 것이다.아드리안 M. H. 18:14, 2007년 7월 13일 (UTC)[응답]

"+" → "새로운 논평"

1. 코멘트를 남기는 것만큼 명확하지는 않지만, 공간을 절약한다.— 오메가트론 01:20, 2007년 6월 26일 (UTC)[응답]
2. 위에서 제시한 토론 합리성에 따라 나의 두 번째 선택. --Quiddity 01:57, 2007년 6월 26일 (UTC)[응답]

"+" → "기분"

1. 장황한 것만큼 좋지는 않지만, 받아들일 수 있다.— 오메가트론 23:25, 2007년 6월 28일 (UTC)[응답]
2. "코멘트"는 제안된 다른 모든 대안들에 비해 분명한 이점을 가지고 있다."+"는 혼란스럽다 - 내가 처음 그것을 접했을 때 무슨 뜻인지 전혀 몰랐고, 그것을 클릭해서 알아내야 했는데, 많은 편집자들이 "충돌하는 위키백과"를 두려워해서 하지 않을 것이다.불필요한 단어가 포함된 "코멘트 추가", "코멘트 남겨" 및 "새로운 코멘트" 낭비 공간 - "코멘트"는 인터넷 언어의 일부로서 위키백과만의 것이 아니다. --WPholic (대화) 12:54, 2007년 7월 20일 (UTC)[응답]

"+" → "코멘트 추가"

1. 아주 선명하고 짧다.— 오메가트론 23:25, 2007년 6월 28일 (UTC)[응답]
2. 나는 이것이 가장 좋다.짧고 간결하다.라라러브^T/_C2007년 7월 13일 03:25 (UTC)[응답]
3. 내가 좋아하는. 간결하고 어색해 보이지 않아.09:25, 2007년 7월 13일 (UTC)[응답]
4. --Kaypoh 15:38, 2007년 7월 13일 (UTC)[응답]
5. 나는 이것을 가장 좋아한다; 무언가를 추가하는 것은 중요하다.+가 무슨 뜻인지 깨닫기 3개월 전에 이곳에 왔었다. --Thespian 22:38, 2007년 7월 13일 (UTC)[응답하라]
6. 그것이 하는 일을 오해할 여지가 없다. --Edokter (Talk) 13:34, 2007년 7월 20일 (UTC)[응답하라]
7. 나는 이 제안을 보기 전까지는 +가 무엇을 하는지 몰랐다."코멘트 추가"는 에독터당 작고 명확하다.라가소스 03:37, 2007년 7월 27일 (UTC)[응답]

"+" → "새로운 주제"

1. 더 명확하고, 더 정확하고, 더 짧다.— 오메가트론 12:25, 2007년 7월 14일 (UTC)[응답]
2. 디토. --Quiddity 17:04, 2007년 7월 14일 (UTC)[응답]
3. 나는 여전히 "+"를 선호하지만, 이 선택사항도 분명하기 때문에 받아들일 수 있을 것이다.(상대적으로) 간결하고 가장 중요한 것은 정확하다. --Tim4christ17 20:31, 2007년 7월 14일 (UTC)[응답]
4. 내가 개인적으로 "+"를 선호하지만, 나는 이 옵션들 중 하나가 아마도 새로 온 사람들에게 더 간단하다는 것을 알고 있다.이는 (특히 다른 제안과 비교했을 때) 기존 논의에 새로운 의견을 추가하는 발상으로 최소한 모호하다는 장점이 있다.니힐트레스^(t.l) 01:08, 2007년 7월 15일 (UTC)[응답하라]
5. 나는 +만 있으면 괜찮지만, 이 옵션도 마찬가지로 괜찮다. -- 네드 스콧 06:41, 2007년 7월 20일 (UTC)[응답]
6. 확실히 가장 확실해. 나도 잔돈은 없어도 괜찮아.아트로포스 00:35, 2007년 7월 22일 (UTC)[응답]
7. 그래, 이게 유일하게 모호하지 않은 것 같아.새로운 코멘트를 남기기 위해 새로운 헤더를 시작할 필요는 없고, 새로운 헤더 아래에 새로운 코멘트와 기존 헤더 아래에 코멘트가 다른 것에 대해 사람들이 혼란스러워 할 수도 있을 것이다. - Zeibura 15:37, 2007년 7월 29일 (UTC)[응답]
8. {{Talkheader}}이(가) "새 코멘트를 시작하려면 여기를 클릭하십시오"가 아니라 "새로운 주제를 시작하려면 여기를 클릭하십시오"를 사용하기 때문에 다른 항목보다 더 의미가 있다. Tcrow777 talk 00:04, 2007년 7월 30일 (UTC)[응답]

"+" 탭 변경 안 함

1. 나는 그것을 단지 경험 많은 편집자들을 위한 지름길이라고 생각하는데, 게다가 전체 페이지나 단지 이전 부분을 편집하는 것은 새로운 사람들이 훑어볼 수 있는 위키코드의 예를 제공한다.게다가 스스로 설명하는 툴팁이 있다. --Quiddity 01:53, 2007년 6월 26일 (UTC)[응답]
2. 최근 '+탭' 문제가 불거졌을 때 썼던 것처럼 WP를 중심으로 길을 찾은 나만의 경험을 바탕으로 문제가 없다고 본다.그것은 논리적으로 새로운 것을 추가하는 것과 같다.아드리안 M. H. 15:44, 2007년 6월 26일 (UTC)[응답]
   • + 기호를 복원하십시오.모든 탭이 보이면 탭 폭이 너무 넓어 감시 목록 링크 바로 아래에 SD용 Twinkle 탭이 남아 있다.급하게 클릭하지 않도록 해야 하는 것.아드리안 M. H. 15:36, 2007년 7월 13일 (UTC)[응답]
3. 내버려 두거나 제거해라.어쨌든 그 계산은 정말 필요없을 것 같다.사람들이 궁금하다면 클릭해서 뭔지 알아낼 수 있다.정말 모든 것이 철자가 필요한가?데이비드 D. (토크) 03:46, 2007년 6월 27일 (UTC)[응답]
4. David와 동의하라 – 버튼에 대해 사람들이 헷갈린다면 버튼 클릭만으로 쉽게 찾을 수 있다. +스피치 ~ 07:35, 2007년 6월 27일 (UTC)[응답]
5. 더 자동 편집 요약을 허용하고 페이지 하단으로 직접 이동하므로 제거하지 마십시오."댓글 남겨라"는 말이 너무 길다.무례하게 굴지 말고, +가 무엇을 의미하는지 깨닫는 것은 매우 간단하다.내가 선택해야 한다면, 그것은 가장 짧은 "신규직"이다.레이와스92^Talk 14:26, 2007년 6월 27일 (UTC)[응답]
6. 단순성 유지 +는 적절히 사용되는 추가에 대한 인식된 기호다.Gnangarra 13:27, 2007년 7월 6일 (UTC)[응답]
7. 다시 한 번 충분히 좋은 것을 내버려두었다. --Tλε RαnΔom Διor (ταlκ) 22:35, 2007년 7월 12일 (UTC)[응답]
8. 네, 그냥 두십시오.안드레 (토크) 06:40, 2007년 7월 13일 (UTC)[응답]
9. 복원 +.필요한 경우 툴팁을 만드십시오.잠깐, 이미 하나 있어.그것은 '이 토론에 코멘트를 추가하라'라고 쓰여 있다.그것이 충분히 명확하지 않다면 바꾸되, 메시지를 남기는 것은 공간을 차지할 뿐이다. --ST47Talk 11:37, 2007년 7월 13일 (UTC)[응답]
10. 또는 "추가"로서 매우 짧은 것, 그러나 개인적으로 나는 "+"가 이미 꽤 명확했다고 생각한다 -- 루카스bfr 11:46, 2007년 7월 13일 (UTC)[응답]
11. +를 복원하십시오.그것은 충분히 간단하고 간결하며 간단해서 알아낼 수 있다.또한, 새 버전은 실제로 코멘트를 남기기 위해서는 코멘트를 사용해야 한다는 것을 의미하기 때문에 더 혼란스럽다. --Tim4christ17 13:59, 2007년 7월 13일 (UTC)[응답]
12. 복원 + 이것은 추가를 의미하는 잘 알려진 수학 기호다.더 명확한 것은? --Anthony.bradbury^"talk" 14:09, 2007년 7월 13일 (UTC)[응답하라]
13. + - 관리자로서 나는 많은 탭을 가지고 있다. 나는 붐비는 것을 좋아하지 않고, "+"는 매우 직관적으로 보인다 - 나는 첫눈에 그것을 이해했다. 또한 대다수의 사용자들이 원본과 다른 어떤 변화에도 반대하는 것 같아 답답하다 - 우리는 여기서 합의가 필요하며, 이와 같이 사이트 전체에서 매우 눈에 띄는 변화에 대해, 이렇게 짧은 토론이 많은 사람들의 바람과 반대로 인터페이스를 바꾸는 것을 보는 것은 좌절감을 준다.니힐트레스^(t.l) 14:50, 2007년 7월 13일 (UTC)[응답]

    오메갓론은 내 토크 페이지에 이 게시물에 댓글을 달았고, 곰곰이 생각해 보니, 이 댓글이 문제에 대한 최선의 접근법이었다고 생각하거나, 그 근거가 타당하다고 생각하지는 않는다. "NOOO CHANGE IT BACK!"라고 잘 쓰여진 글에 해당한다.나는 개인적으로 "+"를 선호하고 직관적이긴 하지만, 새로운 사용자나 경험 없는 사용자에게는 좀 더 설명적인 탭이 있는 것이 유용할 것이다. 게다가, 나는 이미 설정해 놓은 솔루션인 개인용 모노북.js 페이지를 사용하여 탭 텍스트를 사용자 정의할 수 있다.니힐트레스^(t.l) 00:43, 2007년 7월 15일 (UTC)[응답]

14. +를 복원하십시오.단순히 그 제안이 무산될 것으로 예상했기 때문에 지금까지 (나처럼) 많은 사람들이 이 토론에 참여하지 않았을 것이다 ∴ 알렉스 스모트로프 17:25 (UTC) 2007년 7월 13일 (UTC)[응답]

    통과될 것으로 예상했기 때문에 참가하지 않았을 수도 있다.의견을 제시하지 않으면 누군가의 의견이 무엇인지 정말 짐작할 수 없다.트라(토크) 17:50, 2007년 7월 13일 (UTC)[응답]

    흠… 나는 선택할 수 있는 새로운 옵션이 몇 개 있는데 무언가가 지나갈 것을 조용히 기대하는 것은 비현실적이라고 생각해.어쨌든, 내 요점은 대부분의 제안들이 그 반대 방식보다는 실패하는 것처럼 보인다는 것이다. 2007년 7월 13일(UTC) , 2007년 7월 13일 (UTC)[응답]

    아니면, 내 경우와 마찬가지로, 그들은 탭이 바뀐 것을 보기 전까지는 토론이 진행되는 것을 몰랐을 수도 있다. --Tim4christ17^talk 17:59, 2007년 7월 13일 (UTC)[응답]

    그것이 토론이 끝나기 전에 그것을 바꾸는 요점이었다.하지만 사람들이 토론이나 대체 제안을 실제로 읽지 않고 "NOOO CHANGE IT BACKE"라고 말할 것이기 때문에 그의 생각은 바보 같은 생각이었음을 이제 알겠다.— 오메가트론 12:38, 2007년 7월 14일 (UTC)[응답]

    사실, 나는 모든 것을 다 읽었어. 그리고 나는 다른 사람들도 역시 그랬을 거라고 생각해. 대부분의 논평들은 충분히 이치에 맞는 진술들을 가지고 있어.단순히 이전 토론에 동의하지 않는다고 해서 읽지 않았다는 뜻은 아니다. --Tim4christ17 20:04, 2007년 7월 14일 (UTC)[응답]

15. 지름길이다.그것은 목록에서 가장 큰 탭 중 하나를 가질 필요가 없다.2007년 7월 13일(UTC) 18:06 드래곤즈 비행편[응답]
16. 공간을 너무 많이 차지해프로데고 18:45, 2007년 7월 13일 (UTC)[응답]
17. Quiddity가 말한 것처럼, 그것은 새로운 사용자보다 외부 사용자들에게 더 지름길이며, 그들에게 위키코드를 볼 기회를 준다.또한, 다른 기술에서 언급했듯이, 탭이 정말로 새로운 논의를 위한 것일 때, 기존 섹션에 회신하는 경우에도 "댓글 남겨두기"가 적용될 것이다. --Ybbor^Talk 01:33, 2007년 7월 14일 (UTC)[응답]
18. 변화가 필요하지 않다(또는 만족스러운 대안이 제시되지 않았다).더 길어질 뿐 아니라, "코멘트 남겨라", "새로운 글", "뉴 코멘트", "코멘트" 그리고 "코멘트 추가"는 모두 스레드 내에서 각각의 개별 들여쓰기 편집이 구별되는 코멘트로 간주될 수 있기 때문에 혼동의 가능성이 있다. -- 블랙 팔콘 02:35, 2007년 7월 14일 (UTC)[응답]
19. 나는 꽤 많은 탭을 가지고 있는데, 이 변경 후에 그들은 나를 위해 화면을 벗어나게 된다.그리고, 또한, 나는 변화가 필요하다고 생각하지 않는다.나는 +탭에 대해 혼란스러워한 적이 없다; 어차피 완전히 필요한 것은 아니므로, 그것을 대규모로 만들 필요는 없다.— sublime514 • talk • 02:46, 2007년 7월 14일 (UTC)

    "토론" 대신 "토크"를 사용하면 +를 "새로운 게시물"로 바꿀 수 있는 여지가 충분히 있다.사용자 css/javascript(자세한 내용은 명확하지 않지만)를 사용하여 사용자만 다시 변경 가능...

20. +1 혼자 남겨두면.— Xaosflux 03:05, 2007년 7월 14일 (UTC)[응답]
21. 68.39.174.238 16:20, 2007년 7월 21일 (UTC)[응답]
22. 나는 + 꽤 자기주장을 한다.나는 그것을 바꿀 필요가 없다고 본다. ZOUAVMAN LE ZOUAVE 17:20, 2007년 7월 26일 (UTC)[응답]

모든 것에 투표하지 마라.

아, 그리고 이 변화는 멍청한 생각이야.고장나지 않은 것은 고치지 말 것 – 구르흐 09:55, 2007년 6월 27일 (UTC)[응답]

나는 강력히 동의한다.그들은 항상 이렇지 않았는가?레이와스92^Talk 14:26, 2007년 6월 27일 (UTC)[응답]

• 사람들의 생각을 "거친"이라고 부르지 않도록 해라.특히 토론 뒤에 분명하고 논리적이며 지적인 이유들이 있을 때 무례한 행동이다('talk:' talk:' 네임스페이스, 많은 새로운 사람들이 지난 몇 년 동안 혼란을 표현해 왔다).
• 우리는 "모든 것에 투표"하는 것이 아니다; 이것은 내가 VPP에서 오랜만에 본 첫 번째 투표다.그것들은 때때로 유용하다.한 관리자가 이걸 시작했어
• 전통에 호소하는 것은 하나의 관점이지만 논쟁의 종착역은 아니다. --Quiddity 18:19, 2007년 6월 27일 (UTC)[응답]
• 새로운 사람이 머물 기회를 줄이고 여기에 편안해질 수 있는 어떤 것이든 더 환영받거나 사용하기 쉬운 것으로 바꾸어야 한다.경험이 풍부한 편집자는 "+" 또는 "토론" 탭으로 인해 방해받지 않는다.우리는 의견이나 안내를 추가하기 위한 방법을 찾는 데 아무런 성과도 없는 잠재적 편집자들이 얼마나 많은 '대화' 페이지를 몰아냈는지 모른다.우리는 일부 새로운, 그러나 완전히 경험이 없는 것은 아니지만 편집자들이 초기에는 이러한 문제들에 대해 약간의 문제를 가지고 있었고 그것들에 의해 혼란스러워 했다고 언급했다는 것을 알고 있다.왜 모든 것을 가능한 한 간단하게만 만들지 않는가?비엘레 18:38, 2007년 6월 27일 (UTC)[응답]

모든 것에 투표하지 마라.

이것은 투표가 아니라 투표다.여론조사와 투표 모두 낙담하지만 특정 상황에서 유용할 수 있으며, 특히 이와 같은 결정(UI 변경은 기사에 대한 편집 결정과 현저히 다르다는 점에 동의해야 한다)나는 사람들이 단지 "지지"라고 말하는 대신 다른 선택지를 지지하기 위한 그들의 합리성을 쓰고, 새로운 제안이 추가되어 다른 합리성을 고려하며 더 많은 사람들이 동의할 것이라는 생각에 동의할 수 있도록 의도적으로 여론조사를 구성했다.투표라기보다는 구조적인 토론에 가깝다.나는 이 스타일이 다른 곳에서 성공적으로 사용되는 것을 보았고, 이곳이 적절하다고 생각했다.

고장나지 않은 것은 고치지 마라.

몇몇 사람들이 동의하지 않는다.변경할 필요가 없다고 생각될 경우 "변경 금지" 섹션에 서명해야 한다.

그들은 항상 이렇지 않았는가?

옛날에는 "이 페이지에 대해 토론하라"고 되어 있었는데, 사실은 (http://nostalgia.wikipedia.org 참조) 왜 그것이 중요한가?전통은 전혀 무관하다.사용자 인터페이스는 가능한 한 사용할 수 있어야 한다.

또한, 모든 사람들은 이 여론조사가 사물의 웅대한 계획에서 별로 의미가 없다는 것을 깨달을 필요가 있다.인터페이스가 바뀌어야 한다는 공감대가 형성돼 있는 것 같아 아마 그럴 것이다.그러나 우리가 그 변화를 만드는 순간, 모든 사람들이 그 문제를 알게 될 것이고, 그 주제에 대한 의견을 가진 많은 사람들이 갑자기 몰려들 것이다.변화가 이루어진 후에는 훨씬 더 많은 논의가 있을 것이고, 훨씬 더 나은 해결책이 나올 것이다.진정해. — 오메가트론 23:23, 2007년 6월 28일 (UTC)[응답하라]

합의 없이 변하지 마십시오. 다수가 불충분합니다.안드레 (토크) 06:40, 2007년 7월 13일 (UTC)[응답]

이 모든 것이 몰골을 산산조각 내는 것이지만, "댓글 남기"가 가능한 최악의 변화여야 한다.그것은 너무 길고, 매우 명확하지 않다.내가 지금 하고 있는 것처럼 이전 부분에 코멘트를 남기는 것은 매우 쉽다.새로운 논평은 훨씬 더 명확하고 미적이다.아트로포스 21:19, 2007년 7월 13일 (UTC)[응답]

그리고 신의 말씀은 다시 토론으로 바뀌었고, 나는 그것을 클릭하는 프로답지 못한 기분이었다.토론이라는 단어가 '자르곤'이라는 생각이 좀 무섭다.아트로포스 21:22, 2007년 7월 13일 (UTC)[응답]

여기서 '말하기'와 '댓글 남기기'에 대한 공감대가 형성되지 않은 것 같아 두 사람 다 다시 바꿨다.안드레 (토크) 22:10, 2007년 7월 13일 (UTC)[응답]

동의한다. "코멘트 추가"는 너무 길 뿐만 아니라 부정확하다. 버튼의 동작은 새로운 섹션을 시작하고 코멘트를 추가하는 것이기 때문이다. 대부분의 코멘트는 해당 버튼을 사용할 수 없다.— 칼 (CBM · talk) 22:49, 2007년 7월 13일 (UTC)[응답]

그 밖에 몇 가지 제안이 있다.그들 중 누구와도 행복하지 않을 거야?'새로운 주제' 같은 다른 것에 만족하지 않을 거야?— 오메가트론 11:36, 2007년 7월 14일 (UTC)[응답]

더 많은 토론을 하기 위해 그것을 바꾸는 것은 좋지 않은 생각이었음을 이제 알겠다.사람들은 그저 "다시 바꿔줘, 이건 너무 많은 공간을 차지해!"와 같은 말을 하면서, 토론과 많은 공간을 차지하지 않는 몇 가지 다른 제안들을 완전히 무시하고 있다.— 오메가트론 12:28, 2007년 7월 14일 (UTC)[응답]

그래서. 이걸 보관하고 다른 해에 다시 해볼까? --Quiddity 03:08, 2007년 7월 29일 (UTC)[응답]

나는 공감대가 형성되기 시작했다고 생각한다.우리는 그들의 대화 페이지에 있는 반대자들과 대화를 시도해야 한다.사람들은 종종 어떤 것에 투표하고 나서, 그 문제에 대한 더 이상의 토론은 읽지 않는다.그렇게 많은 사람들이 "말하기"를 선호한다는 것을 알게 된다면, 그들은 지금 마음을 바꿀지도 모른다.이 경우, 얼마나 많은 사람들이 한 버전을 선호하는지가 달라지는데, 그 의도는 일을 쉽게 하기 위한 것이기 때문에, 개인적으로 "토론"을 선호하는 사람들 조차도 더 많은 사람들에게 덜 혼란스럽기 때문에 "대화"를 지지할 수 있다.A.Z. 03:12, 2007년 7월 29일 (UTC)[응답]

이동 보호

움직일 필요가 없는 기성 기사의 이동을 보호하는 것은 고려할 만한 것일 수 있다.예를 들어 조지 W. 부시 랫이나 제리 팔웰이라는 기사가 옮겨져야 할 이유가 전혀 없기 때문에, 그러한 기사들을 보호하지 않는 유일한 "이익"은 페이지 이동 반달리즘의 가능성을 열어두는 것이다.멜사란 (구 살라스카바스) 2007년 8월 6일 (UTC) 19:13[응답]

첫 번째 예는 이동 보호됨입니다.둘째는 그렇지 않다.구체적으로 어떤 제안을 하셨습니까?기사의 이름이 "올바른" 경우, 누가 정확히 결정해야 하며, 따라서 이동 보호를 받아야 하는가?덜 중요한 기사에도 이렇게 해야 할까?만약 그렇지 않다면, "덜 중요한 것"과 "더 중요한 것"을 누가 결정하겠는가? -- 존 브레튼 (식용차) 20:18, 2007년 8월 6일 (UTC)[응답하라]

이 제안은 몇 달 전에 제기되었으니 가능하면 기록 보관소를 한번 살펴보십시오.반응이 좀 엇갈린 것 같다.아드리안 M. H. 20:57, 2007년 8월 6일 (UTC)[응답]

WP에 등록하십시오.PEREN :) 멜사란 (이전 살라스카바누스) 21:12, 2007년 8월 6일 (UTC)[응답]

그럼 안 좋은 예.그럼에도 불구하고, 이것은 이름이 안정적이고 결코 바꿀 필요가 없는 많은 기사들에 적용된다.멜사란(옛 살라스카바스) 21:12, 2007년 8월 6일 (UTC)[응답하라]

개인적으로, 나는 그것이 나쁜 생각은 아니라고 생각한다.그러나 존이 지적한 바와 같이, 그것의 실행에는 의사결정 기반의 어려움이 있다.아드리안 M. H. 21:25, 2007년 8월 6일 (UTC)[응답]

다른 사람들이 지적한 바와 같이 이것은 소유권 문제를 야기한다.나는 당신이 그 이름이 영구적이어야 한다고 생각하지만 어느 정도는 의문을 제기할 수 있는 기사를 생각해낼 수 있다. 예를 들어, 루이스 캐롤은 실제 삶인 찰스 러트위지 도그슨(리디렉트)의 유명한 필명인데, 이 필명은 아마도 움직이는 것이 타당할 것이다.Dcoetzee 22:20, 2007년 8월 6일 (UTC)[응답]

특수:새 페이지

감시 목록에 있는 것처럼 새 페이지에 "봇 편집 숨기기" 옵션을 추가할 수 있을까?현재 봇이 한 종족 기사를 마구 만들고 있는데, 그것은 단지 읽기 어렵게 만든다.나는 이 흥행이 결국 끝날 것이라는 것을 알지만 만약 이 봇 기사의 창조가 규칙적인 발상이 된다면, 가능하다면 이것은 좋은 생각일 것이다.관련 MediaWiki 파일을 찾을 수 없어서 여기에 글을 올렸나? - Zeibura 00:34, 2007년 7월 27일 (UTC)[응답]

하하 폴봇.나도 그를 본 적이 있다.좋은 생각이에요.등록 편집도 숨기는 게 좋을 것 같아. -- 익명의 반체제^Talk 인사 02:35, 2007년 7월 27일 (UTC)[응답하라]

User:Lupin/Anti-Vandal 툴은 IP 편집 목록을 업데이트할 수 있다.나는 이 특색을 자주 이용한다.라벤4x4x10:44, 2007년 7월27일 (UTC)[응답]

잘했어, 폴봇난 그게 아주 좋은 아이디어라고 생각한다.하지만 등록 편집된 가죽은 Special에서 제대로 작동하지 않을 것이다.IP가 새로운 기사를 만들 수 없기 때문에 새로운 페이지 (맞으십니까?) — Bob• (대화) • 2007년 7월 30일 05:54 (UTC)

나도 그 제안에 동의해, 얼마 전에 버그질라 검색을 해봤는데 미디어위키 특집으로 제안된 적이 몇 번 있었어.헷갈리는 선언 01:22, 2007년 7월 31일 (UTC)[응답]

위키백과의 IT 문제

먼저 나 역시 세인트피트에 살고 있으며, 우리가 인디 500의 모나코라는 것을 자랑스럽게 생각하는 만큼 위키피디아가 우리 도시에 있다는 것이 자랑스럽다.

어쨌든 요점은 새 범주를 만들 방법이 있는가 아니면 Syslog(Unix, Linux, Cisco) 및 Event Log(Windows)와 같은 시스템 메시지의 문제에 응답하는 방법이 있는가? 이 모든 범주는 코드 유형을 가지며 때때로 다음과 같은 섹션이 있다.

Cisco 예제: 188 CRYPLO IKMP_NO_SA - XX의 IKE 메시지.XX.XX.XX에는 SA가 없으며 초기화 서비스가 아님

Windows 예: 3019 System MRxSmb[경고] - 리디렉터가 연결 유형을 확인하지 못함

Linux 예제: 83 N/A sshd - 0.0.0의 포트 22에 오류 바인딩 실패 주소가 이미 사용 중임.

모든 트리 예제에 공통 4개 필드가 있음 - %Code% %Section% %Type% %Message%

제 아이디어는 http://en.wikipedia.org/wiki-admin/Cisco~188~CryptO~IKMP_NO_SA와 같은 분야를 통합하고 링크를 만들어서 IT 전문가나 IT 신인이 운영체제의 종류에 상관없이 어떻게 그런 종류의 문제를 해결할 수 있는지 알아보는 겁니다.

문제는 수천 개의 문제가 있고 항상 문제를 해결한 사람이 있지만, 문제를 찾는 사람들은 웹 공간에서 그것을 찾기가 너무 어렵다는 것이다.그리고 위키피디아를 사용하면 아주 깔끔하게 할 수 있다.

추신. 나는 내 포럼을 위한 그런 종류의 링크를 만드는 대본을 해봤다.하지만 위키피디아처럼 모든 사람들이 알고 있는 곳에서 하는 것이 더 낫다.

시간 내줘서 고맙고 내가 도울 일이 있으면 편지해줘.

이반

— 72.186.95.161 (대화 • 기여) 20:42, 2007년 7월 30일 이전에 서명되지 않은 논평

이반, 위키피디아에는 지금 이런 게 없어.하지만, 당신이 제안한 아이디어에는 몇 가지 문제가 있다.위키피디아는 백과사전이고 매뉴얼, 가이드북, 교재가 아니기 때문에, 이런 종류의 디렉토리는 위키피디아에 정말 적합하지 않다.또 다른 문제는 모든 기사 내용이 검증가능해야 하고 따라서 적절히 소싱되어야 한다는 것이다; 오직 주목할 만한 주제만이 백과사전에 포함될 수 있는 충분한 2차 소스 커버리지를 제공받는다.여기에는 존재하는 대부분의 IT 문제는 포함되지 않는다.IT 문제를 위해 특별히 만들어진 다른 Wiki가 여러분이 생각하고 있는 것에는 분명히 효과가 있을 것이고, 심지어 Wikimedia 재단이 이러한 목적을 위해 자매 프로젝트를 기꺼이 시작할 가능성도 있다.위키백과 참조:About#Sister 프로젝트들은 재단이 가지고 있는 자매 프로젝트들의 리스트를 위한 프로젝트들이다.BigNate37_(T) 21:28, 2007년 7월 30일 (UTC)[응답]

컴퓨팅 데스크 이름 바꾸기

⑴ 일부 사용자는 비디오 게임 하드웨어에 대한 질문을 가지고 있고 반드시 게임 콘솔을 컴퓨터라고 생각하지 않으며, ⑵ 컴퓨터에 대해 잘 아는 사람들은 아마도 다른 가전제품에 대해서도 잘 알고 있을 것이기 때문에 컴퓨터 참조 데스크의 이름을 컴퓨팅 및 가전제품으로 바꿀 것을 제안한다.네온머린 17:07, 2007년 7월 30일 (UTC)[응답]

비디오 게임은 엔터테인먼트 레퍼런스 데스크에 문의하는 것이 더 적절하다.많은 사람들이 컴퓨팅과 게임 모두에 관심이 있지만, 전자 디자인(사이언스 레퍼런스 데스크의 기술에 해당)으로 내려가지 않는 한 이 두 분야는 거의 겹치지 않는다.BigNate37_(T) 17:11, 2007년 7월 30일 (UTC)[응답]

상품 개발

어쩌면 우리가 기사를 개발할 수 있는 장소를 만들 수도 있고, 그 다음에 그것들이 적절한 기사가 될 수 있을 때, 또는 리스트의 경우, 완성되어 기사 제목으로 옮겨갈 수도 있을 것이다. - 2007년 7월 29일 (UTC) - 프레지던트맨 22:47, (UTC)[응답]

우리는 이미 그러한 장소, 즉 사용자 공간을 가지고 있다.사용자 공간에 페이지를 작성하려면 "특수:검색 줄에 "Myspace/name"을 입력하고 페이지를 작성하십시오.예를 들어, 나는 처음에 위키프로젝트 아이오와 at User:에 대한 페이지를 개발했다.Tim4christ17/Wikipedia:위키프로젝트 아이오와 주(州)에서 위키프로젝트를 마지막으로 휴식을 취한 후 위키피디아:나중에 아이오와주 위키프로젝트.

내가 한 가지 언급하고 싶은 것은 위키피디아의 모든 기사들은 현재 진행 중인 작업물이며, 심지어 단 한 개의 스텁도 메인 스페이스에 자리를 잡고 있다는 것이다.사용자 공간 아이디어는 무언가를 좀 더 "공용" 메인 공간으로 옮기기 전에 개인적으로 작업하고 싶은 경우에 대한 것이다.안녕하십니까, Tim4christ17 23:01, 2007년 7월 29일 (UTC)[응답]

그래, 나도 알아, 하지만 더 많은 경험 많은 사용자들이 새로운 사람들을 도울 수 있는 곳일 수도 있어. - 2007년 7월 29일 프레지던트맨 23:21, (UTC)[응답]

나는 그것을 위해 메인 스페이스와 사용자 스페이스를 사용할 수 있다고 생각한다.A.Z. 23:41, 2007년 7월 29일 (UTC)[응답]

나는 전에 이 문제에 부딪힌 적이 있다.사용자 공간에서 기사를 시작할 때 가장 중요한 이점은 문서가 처음에 해당 기준 중 하나에 적합한 경우 해당 문서가 신속하게 삭제되지 않도록 한 후 초기 실행 가능한 버전을 완료하는 것이다.예를 들어, 나의 샌드박스는 현재 내가 존재하는 것으로 알고 있는 참고문헌을 손에 넣지 못했지만 실생활에서 누군가가 나에게 준 것이 아니기 때문에 만약 그것이 메인 스페이스에 있다면, 내가 가지고 있는 것은 빠르게 삭제될 것이다-사실, 내가 그것을 우연히 발견하게 된다면, 나는 그것을 스스로 빨리 삭제할 것이다.내 샌드박스에 놔두면 내가 그것을 가지고 있고 위험 없이 편집할 수 있어.우리가 사용자 공간을 가지고 있기 때문에, 나는 다른 공간이 필요하지 않다고 본다.니힐트레스^(t.l) 15:22, 2007년 7월 30일 (UTC)[응답하라]

사용자 하위 페이지에서 어떤 것에 대한 도움이 필요한 사람은 누구나 여러 가지 방법으로 자유롭게 요청할 수 있는 반면, 모니터링하고 관리해야 하는 또 다른 프로젝트 페이지(예를 들어 고아 자료를 흘리는 경우)는 이미 상당히 많은 작업량에 불필요한 추가물이다.우리는 EA 외에도 도면도 가지고 있다.아드리안 M. H. 16:59, 2007년 7월 30일 (UTC)[응답]

탭 검색

이제 탭 검색에 중독된 나는 왼쪽 열의 위키백과 검색 항목이 이것을 지원하지 않는다는 것이 답답함을 느낀다.내가 이 점을 먼저 제기한 것은 아닌지 의심스럽다.중복해서 정말 미안해. --CloudSurfer 21:19, 2007년 7월 26일 (UTC)[응답]

그냥 위키백과가 아니라, 비슷한 것은 정확히 똑같고, 나는 위키백과를 넘어서는 해결책이 필요할 것 같은 느낌이 든다.탭 검색은 위키백과, SqueakBox 21:25, 2007년 7월 26일 (UTC)[응답]에 적합하다.

MS Internet Explorer ver 7이 마침내 탭 검색을 따라잡았다.다른 사람들은 몇 년 동안 그것을 가지고 있었다.물론 브라우저가 탭을 지원하는지 여부를 감지할 수 있고, 새 탭에서 검색을 열 수 있도록 버튼을 표시할 수 있다. --CloudSurfer 02:24, 2007년 7월 27일(UTC)[응답]

제출버튼을 클릭할 때 일종의 수식어 키를 누르고 있는 것이 요령이라고 본다.추가 버튼은 확실히 필요하지 않다.— The Storm Surfer 02:50, 2007년 7월 27일 (UTC)[응답]

아마도 당신의 모노북의 자바스크립트 모드는 도움이 될 것이다, 2007년 7월 30일 박스 밖에서 생각하라[응답하라]

파이어폭스는 있어?주소 표시줄 옆에 있는 검색 줄에 추가할 수 있다.항상 새 탭을 열도록 설정할 수 있다.IE7에 대해서는 잘 모르겠다. MER-C 13:40, 2007년 7월 30일 (UTC)[응답]

템플릿 샌드박스({X1}, {{X2}}개 등) 헤더

템플릿 샌드박스({X1}, {{X2}}개 등) 헤더는 템플릿이 사용되는 페이지의 <noinclude> 블록 안에 있지 않다(이러한 헤더를 변환한다).이는 테스트 템플릿의 사용을 억제한다.(사용자가 지시사항을 따르고 주석 아래의 줄만 터치하거나 지시사항을 따르지 않았기 때문에 페이지를 빨리 되돌리는 경우)
나는 모든 보일러 판 헤더를 (대략 코멘트를 제외) <노인클루프> 블록으로 포장할 것을 제안한다.
BTW, 이걸 물어볼만한 더 좋은 곳이 있는지 모르겠어.나는 보통 토크페이지에서 물어보겠지만 그것도 샌드박스야.(내 생각에 이것은 공식적인 승인이 필요하지는 않지만 페이지를 적절히 재설정하기 위해 봇이 필요할 수도 있는 변경인 것 같다) --Jermyb 06:46, 2007년 7월 31일 (UTC) 참고: WP에서 이식했는데VPM --Jeremyb 07:15, 2007년 7월 31일 (UTC)[응답]

대화형 멀티미디어 콘텐츠: 위키피디아에서 스크래치?

위키피디아에 Interactiv Media Content가 없다.그것을 포함한 방법이 있었다면 더 쉽게 설명하고 배울 수 있는 것이 많다.일부 다른 백과사전에는 위키백과(예: 엔카르타)에 대한 가장 큰 장점 중 하나로 Interactiv Media Content가 포함되어 있다.그러나 다른 위키백과 매체의 데이터 유형이 분명해 보이는 곳에서는 인터랙티브 매체가 문제를 가지고 있다.

• 강력한 "모래박스"여야 한다(위키피아의 사용자에게 해를 끼치지 않도록)
• 인쇄 가능한 방식과 선명한 프레임(그림처럼)으로 표시해야 한다.
• 오픈 소스 및 공통 기술에 기반해야 함
• 프로그래머가 아니더라도 쉽게 만들 수 있어야 한다.
• 그것은 학력이 있어야 한다.

이 목록을 자유롭게 확대하십시오.예를 들어 Java, Flash와 같은 대화형 데이터를 생성하는 가장 잘 알려진 방법은 이러한 요구를 충족하지 못할 것이다.

새로운 시각 프로그래밍 언어 Scratch가 그것을 충족시킬 수 있을 것이라고 생각한다.

스크래치는 MIT 미디어랩의 평생유치원 단체가 교육 목적으로 만든 것으로 교사와 학생들로 구성된 커뮤니티가 튼튼하게 성장하고 있다.샌드박스, 액자, 오픈소스, 매우 배우기 쉽고, 교육적 배경(원래 학교 아이들을 위해 발명되었다)을 가지고 있다.스크래치 플레이어가 자바를 기반으로 한다고 해도, 스크래치 코드는 이 플레이어에 의해 해석되고 샌드박스가 훨씬 더 강하기 때문에, 필요한 유일한 자바 프로그램이다.

Scratch Project는 그렇게 하도록 만들어지지 않았고 어린이에 의해 만들어지더라도 반드시 그렇게 하지 않아도 다음과 같은 몇 가지 Scratch Project가 있다.

• 유럽을 아십니까?
• 심장 시뮬레이션
• 진공 청소기
• 단순 전기 회로
• 광합성
• 작곡가
• 레고 모델 크리에이터
• 건축 스탬프

스크래치 포룸에서 우리는 위키피디아와 스크래치를 연결하는 것에 대해 토론했고 나는 여기서 그것을 제안하도록 격려받았다.Scratch의 집을 볼 때 가끔 유치한 프로젝트에 대해 웃지 마십시오.아이들은 우리의 미래고 그들이 사랑하는 기술의 잠재력은 크다.

미리 피드백해주셔서 감사하다.Mtwoll 19:08, 2007년 8월 7일 (UTC)[응답]

이렇게 하는 한 가지 방법은 스크래치 파일을 업로드할 수 있게 한 다음 이미지 설명 페이지나 다른 페이지의 인라인으로 표시하기 위해 자바 스크래치 플레이어를 사용할 수 있게 하는 것이다.이것은 이것을 가능하게 하기 위해 연장이 필요할 것이다.트라 (토크) 2007년 8월 7일 21:51 (UTC)[응답]

나는 Scratch 온라인 커뮤니티의 발전을 이끌고 있다.이것이 필요하다면 Scratch 웹사이트에서 주최하는 프로젝트들을 위키피디아로 쉽게 밀어넣을 수 있도록 기꺼이 도울 것이다.나는 위키피디아에서 플리커의 사진을 본 적이 있다.수동으로 하는 겁니까, 아니면 자동화된 시스템이 있는 겁니까?어쨌든, 스크래치 팀이 비전문 프로그래머들이 위키백과에 프로그램 가능한 미디어를 제공하도록 할 수 있는 일이 있다면 우리에게 알려달라.안드레스미

과거에 위키피디아는 다른 웹사이트의 미디어 핫링크를 피했다(Wikimedia Commons 및 자매 프로젝트인 일부 Toolserver 스크립트 별도).이것은 주로 미디어가 다른 웹사이트에 있을 경우, 위키백과 사용자 이름으로 연결하여 전체 개정 내역을 볼 수 없고, 제3자 서버가 고장날 위험이 있거나, 미디어가 위키백과에서 사용하기에 부적합한 방식으로 삭제되거나 수정될 수 있기 때문이다.또한 누군가가 누군가의 저작권을 침해할 수 있는 어떤 것에도 연결시키는 것이 매우 쉽다는 문제도 있다.

이것은 단지 일반적인 의미일 뿐이다.Scratch 사이트 설계 방법에 따라 이러한 문제의 일부 또는 대부분은 적용되지 않을 수 있지만, 타사 사이트의 핫링크 미디어가 아닌 안전한 쪽에 있는 것이 가장 좋다.Flickr 사진은 Flickr에서 다운로드한 후 Wikimedia Commons에 별도로 업로드되었다.

핫링크가 없어도, 위키백과 페이지에 Scratch 프로젝트를 내장하는 것은 여전히 개발자의 참여가 필요할 것이다. 왜냐하면 위키 코드의 Scratch 파일에 대한 참조를 입력할 수 있고 애플릿에 대한 링크를 생성할 수 있도록 MediaWiki 소프트웨어에 대한 확장이 코딩되어야 하기 때문이다.Scratch 업로드를 활성화하려면 개발자 참여도 필요하지만, 화이트리스트에 파일 확장자를 추가하기만 하면 되기 때문에 비교했을 때 훨씬 간단하다.

현재 당신이 할 수 있는 것에 대해, 현재 가능한 유일한 방법은 기본적인 하이퍼링크로 Scratch 웹사이트에 있는 페이지로 링크하는 것이다.트라 (토크) 03:24, 2007년 8월 8일 (UTC)[응답]

"슈퍼" 감시 목록

사용자가 빨리 보고 싶은 높은 우선순위의 글과 페이지에 태그를 붙일 수 있는 다른 필드를 감시 목록에 추가할 수 있을까?이것은 많은 페이지를 편집하고 매우 큰 워치리스트를 가지고 있는 사람들에게 도움이 될 것이지만, 때때로 전체 리스트를 보고 싶을 뿐이다.Tvoz talk 16:23, 2007년 8월 2일 (UTC)[응답]

m:를 통해 대체 워치리스트 사용:워치리스트#관련 변경 기능 ∴ 알렉스 스모트로프 16:42, 2007년 8월 2일 (UTC)[응답]

단일 편집자에 의해 전적으로 작성된 기사

단일 편집자에 의해 전적으로 작성된 기사는 다음과 같은 가능성이 높다.

• POV이다,
• 동료가 아닌
• 위키와 철자 점검이 필요하다.

나는 그러한 기사들을 모두 나열한 대본을 썼다.
목록을 찾아보고, 기사를 확인하고, 개선할 항목을 편집한 다음, 다시 돌아와서 이 도구를 개선하는 방법에 대해 알려줘:-)

유용한 것으로 판명될 경우, 이 도구는 위키피디아의 "Fix-up 프로젝트" 섹션에 추가될 수 있다.커뮤니티_포탈.하지만 우선 네 피드백을 받아야 해. 그리고 대본이나 프로젝트에 대해 물어봐.기고자도 환영 :-)

니콜라스1981 11:13, 2007년 8월 2일 (UTC)[응답]

편집자 한 명이 전체적으로(또는 거의 전적으로) 쓴 기사도 특집 기사가 될 가능성이 훨씬 크다. -- 카노스 11:36, 2007년 8월 2일 (UTC)[응답]

사실, 이 기사들 중 몇몇은 정말 좋다.그러나 어떤 특집기사가 전적으로 한 명의 편집자에 의해 쓰여진 것인지는 의문이다(그렇지만 나는 확인하지 않았다.나는 어느 누구도 완전히 편견을 가질 수 없다고 생각한다.니콜라스1981 13:51, 2007년 8월 2일 (UTC)[응답]

리스트를 보면 숫자로 시작하는 기사를 삭제하는 것이 현명할지도 모른다.많은 것들이 템플리트나 자리 표시자 형식에 따른 기사로 보이며, 특정 연도에 일어난 특정 날짜나 사건에 대한 정보: 104 AH, 1622 예술, 1856 영국 크리켓 시즌, 1770년대 고고학 등이다.그들의 자동화된 혹은 템플릿 중심의 생성 때문에, 이 페이지들은 적절히 포맷되고 위키링크가 잘 되어 있는 경향이 있다; 나는 많은 것들이 다양한 위키백과 주제의 산물이라고 생각한다.TenOfAllTraes(대화) 2007년 8월 2일(UTC) 12:06[응답]

편지로 시작하는 기사들 가운데서도 많은 비율이 자동으로 만들어졌고, 내용이 너무 작고, 주제가 너무 구체적이어서 개선하기가 어렵다.그러나 어쨌든 사람이 만든 기사보다 더 지루한 경우가 대부분이지만 자동 제작 기사를 확인하는 것이 좋다고 생각한다.니콜라스1981 16:03, 2007년 8월 2일 (UTC)[응답]

워치리스트 섹션

이름에서 알 수 있듯이 개별 섹션의 감시 목록을 활성화할 것을 제안한다. 여기서 섹션의 작은 '[편집]' 옆에 '[시계]'가 있을 것이다.이것은 특정 섹션 아래에서 많은 논의가 이루어지는 장소에서는 유용하지만 페이지 전체는 매우 바쁘다.WP:ANI는 이것의 예일 것이다.생각? -- 익명의 반체제^Talk 인사 16:59, 2007년 8월 1일 (UTC)[응답]

그것은 전에 제안된 적이 있고, 매우 좋은 아이디어지만, 기술적 한계로 인해 그것을 허용하지 않을 것이라고 나는 믿는다.레이와스92^Talk 17:00, 2007년 8월 1일 (UTC)[응답]

글쎄, 만약 내가 이 페이지의 한 섹션만 볼 수 있다면, 나는 이 제안에 응답하지도 않았을 거야.하지만 나는 페이지 전체를 보았고, 여기서 다른 사람들의 제안에 대해 토론하는 것을 돕고 있다.시계 섹션 특집기사는 여러 페이지에 이런 부수적인 관여를 제거해 줄 것이고, 내 생각에 그것은 나쁜 것이다.BigNate37_(T) 17:19, 2007년 8월 1일 (UTC)[응답]

음, 정말로, 당신이 그것을 고려할 때, 꽤 많은 이득을 얻는 것은 비교적 적은 손실이다. -- 익명의 반체제^Talk 인사 17:21, 2007년 8월 1일 (UTC)[응답]

둘 이상의 활성 토론이 있는 페이지의 토론을 따를 수 없다는 말씀이십니까?편리함 이외에 당신이 언급하고 있는 좋은 이득은 무엇인가? 그것이 실제로 토론 참가자들의 손실을 피할 것인가?BigNate37_(T) 17:47, 2007년 8월 1일 (UTC)[응답]

그럴 수도 있지그것은 보다 구체적인 텍스트의 추적을 더 쉽게 할 수 있게 해 줄 것이며, 당신이 말한 바와 같이, 내 생각에, 최소한의 손실이라는 단점을 가지고, 편리할 것이다(내가 그것에 대해 잘못 볼 수 있는 것은 아니다). -- 익명의 반체제^Talk 인사 17:54, 2007년 8월 1일 (UTC)[응답]

빅네이트37, 참여에 대한 너의 요점을 이해한다.하지만, 나는 이것이 높은 트래픽의 페이지에서 매우 유용하다는 것을 알 수 있다.우선, 그것은 특정한 문제에 집중하는 것을 더 쉽게 만들 것이다.둘째로, 기술적인 관점에서 볼 때, 우리들 중 몇몇은 감시 목록 페이지를 많이 가지고 있지만, 감시 목록에는 최대 1000개의 변경 사항만 표시된다.매일 수백 건씩 편집되는 고트래픽 페이지를 감시하고 있다면, 워치리스트의 「리치」에 큰 영향을 미칠 수 있다. --Ckatz^chat_spy 00:29, 2007년 8월 2일 (UTC)[응답]

다시 한 번 말하지만, 이것은 적절한 포럼 시스템에 의해 고쳐질 문제다.사용자:Dcoetzee/wikithreads가 나쁜 이유.Dcoetzee 19:03, 2007년 8월 1일 (UTC)[응답]

이 기능 요청은 섹션의 번호를 다시 매기는 것이 너무 쉽기 때문에 작성된 대로 작동하지 않는다(위에서 섹션을 추가하거나 제거하면 번호가 변경됨).>래디안트< 12:10, 2007년 8월 2일 (UTC)[응답]

내 생각엔 그게 가장 작은 문제인 것 같아,내가 그것에 찬성하지 않는다는 것은 아니다!

예, 앞서 논의된 바 있다: 자동 삭제 전 마지막 변경 사항(관찰 목록 섹션이 있다면 훨씬 쉽게 찾을 수 있었을 텐데) — The Storm Surfer 13:43, 2007년 8월 2일 (UTC)[응답]

중앙 집중식 위키백과 지리적 데이터베이스?

최근 구글 어스에서 위키피디아 지리 좌표의 가시성을 바탕으로, 나는 600개 이상의 상당히 부정확한 지리 참조 자료를 수집했다.예를 들어, 300개 이상의 것들은 프랑스의 칼바도스 부에 있는 코뮌인데, 그 중 서쪽이 아닌, 프라임메르디앙의 동쪽에 위치해 있다.

나는 종합 헬프 데스크에서 그러한 정보에 대한 중앙 데이터베이스가 없다고 들었다.그것은 내가 영어 페이지를 수동으로 수정하더라도 구글 어스 프레젠테이션이 다른 언어에서 틀릴 수 있다는 것을 의미한다.

확실히, 각 언어 번역과 다른 지리 참조를 위해 템플릿에 의해 자동으로 참조될 수 있는 중앙집중화된 지리 데이터베이스를 도입하는 방법이 있어야 한다.

마찬가지로, 나는 각 페이지의 왼쪽에 있는 다국어 링크는 각 페이지마다 링크 데이터베이스 fopr에서 파생되어야 한다고 예상한다. 그래서 만약 새로운 언어 번역이 만들어지면, 기존의 다양한 번역에 대한 모든 페이지들은 새로운 링크를 얻게 될 것이고, 링크는 항상 같은 사이비 알파벳에 있을 것이다.순서. 페어팩스 지리학자 05:37, 2007년 7월 31일 (UTC)[응답]

mw:위키다타 및 m:위키맵이 해답을 줄 수도 있다. (내 생각에는 그 문서 페이지가 시사하는 것보다 프로젝트가 더 활발하다고 생각한다.좀 파봐.찾은 내용 알려줘 :) --Quiddity 17:30, 2007년 8월 1일 (UTC)[응답]

조언해줘서 고마워.그들은 상당한 복잡성과 불확실하거나 가능성이 없는 행동의 영역을 지적한다.우리는 모두 이러한 노력에 자원봉사를 하고 있다. 즉, 특정한 질문, 아이디어 또는 관심사를 가진 새로운 사람들은 위키 용어, 다양한 포럼 등을 통해 며칠 또는 몇 주를 보내야 한다.나는 이곳에 오기 전에 이 질문을 여러 곳에 올렸었다.위키 구루가 되기 위해 연구를 계속할 개인적인 시간도 없고, 다른 전문가들과 이야기를 나누기 위해 8월 대만 컨벤션에 갈 돈도 없다.그래서 당분간은 영어로 된 600개 이상의 수작업 편집(및 매일 성장)을 위해 봉사활동을 하고, 나머지 언어는 미래의 날에게 맡길 것이다.페어팩스 지리학자 09:20, 2007년 8월 2일 (UTC)[응답]

사용자:아노메는 기사에 좌표를 자동으로 추가하는 봇을 실행하고 있다.그는 이것을 위해 다른 위키피디아의 좌표를 사용한다.당신은 그에게 연락하기를 원할지도 모른다; 그는 아마도 문제가 있는 좌표를 가진 목록을 매우 빨리 만들 수 있을 것이다.위키백과 대화를 이미 찾으셨습니까?위키프로젝트 지리 좌표?만약 당신이 자원 봉사자들이 좌표를 수정하기를 원한다면, 그것은 당신이 그들을 찾을 수 있는 한 곳이다.외젠 반 데르 피엘(Eugene van der Pijll, 2007년 8월 2일 (UTC)[응답]

웰컴봇

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

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

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

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

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

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

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

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

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

전적으로 우주에 없는 기사들을 다루는 것

나는 해리포터 전투와 관련된 두 번의 afd 토론을 통해 고통받고 있다.계속 주장하던 많은 사람들이 스타워즈와 로트R 전투를 자주 인용하면서 X?의 주장을 사용하고 있다.왜 우리가 카테고리 같은 걸 가지고 있는지 궁금하다.스타워즈 전투 및 카테고리:중간 지구 전투- 그 안에 포함된 기사들은 실제 세계의 중요성이 전혀 없고, 순탄하며, 전적으로 주요 출처로부터 구성되며, 기본적으로 확장된 줄거리 요약이 있다.-Wafulz 22:09, 2007년 7월 26일 (UTC)[응답]

위키피디아에서 마지막 두 가지 예를 참조하십시오.알림성(픽션)#예시 --Tim4christ17 22:22, 2007년 7월 26일 (UTC)[응답]

• 기본적으로 그들은 중립을 지키고 검증하기 쉽기 때문에, 그리고 많은 사람들이 그들에게 관심을 가지고 관심을 가지기 때문이다.>래디안트< 12:12, 2007년 8월 2일 (UTC)[응답]

임의 아티클 기능

우선 첫째로, 나는 단지 여러분 모두가 놀라운 도구를 만들어 준 것에 대해 감사하고 싶다.

그 웹사이트에 대한 아이디어를 빨리 언급하고 싶었다.

나는 항상 임의의 기사 특징을 사용한다.만약 내가 밤에 야구 경기를 보고 있다면, 나는 다른 아이템들에 대해 다른 것들을 배우기 위해 무작위 기사를 클릭할 것이다.내가 보고 싶은 것은 무작위 기사를 통해 어떤 것을 걸러내는 방법의 선택이다.(즉, 역사, 스포츠, 미국, 오락, 고대사 등)이것은 단지 일부 사용자들에게 유용할 것이라고 생각했던 아이디어일 뿐이다.

나는 네가 한 모든 것에 대해 다시 한 번 너희 모두에게 감사하고 싶어.

위키피디아에서 검색 가능:범주형 인덱스 페이지(또는 이 페이지 [1])를 선택하고 특정 카테리(cateogry)에서 임의의 기사를 선택하십시오.그건 네가 찾고 있는 것과 거의 비슷해, 내 생각 같아.2007년 7월 29일(UTC) 12:00 되풀이 꿈 꾼다[응답하라]

임의의 피처링 기사 도구를 만드는 것이 가능할 것이라고 확신한다 – 포털에서 사용되는 이 도구를 살펴보십시오.중간 지구.–세비 11:02, 2007년 8월 2일 (UTC)[응답]

반달리즘 가석방

사용자를 차단 해제하고 가석방하는 방법에 대한 제안은 여기를 참조하십시오.자유롭게 논평/추가. --(Review Me) R concernations_@ (Let's Go Yankees!) 03:06, 2007년 8월 5일 (UTC)[응답]

필수 위키백과?

"필수적인" 위키백과에 대한 데이터베이스나 필터, 오버레이 같은 것이 지금 존재하는가?

예를 들어 콩고 시골에서 인터넷 접속이 안 되는 학교를 운영하고 있다면, 모든 잡동사니들과 대중문화들이 다 벗겨진 채 꼭 필요한 교육용 기사들만 가지고 있는 CDR(또는 어떤 크기의 미디어가 필요한지)을 한 장만 있으면 좋을 것이다.

나는 그것이 흥미로운 아이디어가 될 것이라고 생각했다 - 필수적인 기사들만 읽거나 다운로드 할 수 있는 방법.

나는 그 기사들을 식별하는 것은 단지 꼬리표를 붙이는 것만으로 충분하다고 생각한다.하지만, 다운로드를 위해 업데이트된 필수 기사들을 조립하는 대본에 대해서는, 그것은 내 능력 밖이다.올글로리토더하이프노토드 19:51, 2007년 8월 3일(UTC)[응답]

여러분은 위키피디아의 선을 따라 생각하고 있을지도 모른다.버전 1.0 편집팀의 릴리스 버전주제별보다 더 '일반적인 관심사'인 그들의 출시가 정확히 당신이 찾고 있는 것이라고는 생각하지 않지만, 내가 생각할 수 있는 가장 가까운 근사치인 것이다.존 카터(19:54, 2007년 8월 3일 (UTC)[응답]

SOS Children과 협력하는 위키백과 CD Selection은 여러분이 생각하고 있는 것과 같은 종류의 것 같다.2007년 선정이 가능한 것 같다.2006년 위키백과 메인 스페이스에 대한 위키백과 CD Selection에 관한 정보도 있다.--Boson 17:17, 2007년 8월 5일 (UTC)[응답]

기사 페이지의 프로젝트별 혼잡

예를 들어, 여기와 같이 거대한 경적 프로젝트 특정 태그를 기사에 배치하는 관행에 대한 다른 의견들을 궁금하게 여긴다.IMO, 많은 토크 페이지의 상단이 여러 프로젝트 배너에 의해 점유되는 것은 충분히 좋지 않지만, 이제 잡동사니를 기사 공간으로 확장하는 것은 좀 지나친 것 같다.제 말은, 이 경우, 일반적인 의미에서 그 기사가 끔찍하게 나쁜 것 같지는 않다는 겁니다. 위키피디아 주제의 어떤 기준으로 볼 때, 그것은 단지 속임수에 달할 수 있는 것이 아닌 것 같습니다만.나는 일종의 태깅이 토크 페이지에 있는 프로젝트 배너에 대한 것 중 하나라고 말했다.나이 든 wiser 더 현명한 02:15, 2007년 8월 3일 (UTC)[응답

나도 동의해 - 간단한 청소 태그만 있으면 돼.그리고 실제 위키백과 가이드라인 등을 위반하는 경우에만.페이지의 표준 '형식'에 관한 프로젝트가 있다면 기사 자체가 아니라 토크 페이지에 올려야 한다. --Tim4christ17^talk 12:18, 2007년 8월 3일 (UTC)[응답]

위키프로젝트 로드크루프트는 자신을 있는 그대로의 독립된 실체라고 생각하기에 충분했다.나는 이런 것을 볼 때마다 점점 MfD를 쓰고 싶어진다.세라핌블레이드 12:29, 2007년 8월 3일 (UTC)[응답]

나는 기사 페이지에 올라갈 수 있는 태그가 (향상/향상되는 것을 보는 사람들이) 예를 들어 (1911년 (백과사전 브리타니아) 참조) 토크 페이지에 올려지는 것이 흥미롭고 매우 좌절스럽다고 생각한다.이런 것들이 기사 페이지에 올라가야 '캐주얼 연구자'가 그 주제에 대해 쉽게 접근할 수 있는 정보를 얻을 수 있다.그러나 그 대신 그것은 토크 페이지에 올려진다 - 그들이 심지어 방문은 고사하고 존재조차 모를 수 있는 어딘가에.위키피디아는 지식의 플랫폼이다 - 우리는 동시에 개발 요구로 기사 페이지를 어수선하게 하지 말아야 한다.-에드문트 패트릭 14:41, 2007년 8월 3일 (UTC)[응답]

템플릿:1911을 말하는 겁니까?거기서 말하는 것처럼 기사 페이지에 배치해야 하며, 동시에 Template:1911 토크를 관련 토크 페이지(분류하기 위해)에 배치해야 한다.(나중에 참조할 경우:문제를 설명할 때, 예시 기사에 연결하는 것은 항상 상황을 더 명확하게 만들 것이다;) --Quidity 17:21, 2007년 8월 3일 (UTC)[응답]

네가 발표하는 템플릿 예제가 토크 페이지에 올려졌어야 하는 게 분명해 보인다.— The Storm Surfer 17:24, 2007년 8월 3일 (UTC)[응답]

순교자 에드먼드는 완벽한 경우다.캐주얼한 연구원이 도착하여 자리를 뜨는데, 왜 그들이 탭으로 가겠는가 - 토론 - 역사 - 시계 등.그리고 토론 페이지에 나와 있는 브리태니아 백과사전 이외에는 이런 정보들이 어디서 나온 것일까.그리고 실제로 그러한 템플릿:1911을 기사 페이지에서 토크 페이지로 옮기는 봇이 있다.(한때 있었다.지식의 출처는 캐주얼 리서치에 쉽게 접근할 수 있어야만 그렇게 원한다면 다른 곳에서 검증할 수 있다. --에드문트 패트릭 07:06, 2007년 8월 4일 (UTC)[응답]

어디선가 찾을 수 있을 줄 알았던 유감스러운 사람들; 위키피디아 참조:템플릿_for_deletion/Log/2007_7월_18일 이전 토론용 --Edmund Patrick 07:23, 2007년 8월 4일(UTC)[응답]

나는 혼란스럽다 -- 1911년 백과사전에 대한 언급이 그 기사의 전체 존재에 대해 일부에서 또는 다른 일부에서 나왔다.그리고 내가 알 수 있는 바로는, 2007년 6월 7일(UNC) 09:21에 PbBot(토크 · 기여)의 토크 페이지에 {{1911 토크}가 추가되었다.더 나이가 많은 ≠ 11:32, 2007년 8월 4일(UTC)[응답]

내가 기사 페이지 하단의 진술을 놓쳤기 때문에 입증된 사례라고 말할 수 있을 것 같다. 그러나 토크 페이지 상단의 큰 태그는 아니다.아마 나만 그럴 수도 있고, 아니면 다른 사람들도 그 진술을 놓칠 수도 있다.포인터 고마워. --Edmund Patrick 12:04, 2007년 8월 4일 (UTC)[응답하라]

WP에 따르면 순교자 에드먼드의 코너를 정리했다.레이아웃 - 이제 좀 더 명확해져야 할 것 :) --Quiddity 16:34, 2007년 8월 5일 (UTC)[응답]

기사가 아닌 모든 항목의 색인 작성을 차단하는 제안

나는 위키피디아가 모든 검색엔진을 기사가 아닌 어떤 것이라도 색인화하는 것을 차단할 것을 제안하고 싶다.여기에는 다음과 같은 이유로 사용자 페이지, 사용자 토크 페이지, 카테고리 토크 페이지 등이 포함된다.

1. 많은 경우 사람들은 자신의 사용자 페이지에 정보를 올리거나 나중에 표시하기를 원하지 않는 대화 페이지에 정보를 올린다. 왜냐하면 그것은 그들을 괴롭히기 위해 사용되기 때문이다.이 페이지들의 색인을 차단하는 것은 검색 엔진에서 발견되는 것을 막을 것이다.오래된 정보를 여전히 가지고 있는 스크레이퍼 때문에 내용물을 제거하는 것이 항상 선택사항인 것은 아니다.모든 스크래퍼들이 로봇을 따르는 것은 아니지만.txt, 이것은 대다수의 사람들에게 도움이 될 것이다.이것은 또한 구글과 다른 사람들이 그들의 캐시를 때때로 한 번만 업데이트하기 때문에 페이지를 캐시하는 다른 사람들이 원하지 않는 정보로 결과를 반환하는 것을 막을 것이다.
2. 그렇게 함으로써, 일반 기사 페이지만큼 자주 그리고 세심하게 감시되지 않는 무작위 대화 페이지에 사람들에 대한 허위 정보를 게시하는 사람들로 인한 괴롭힘을 예방하는 데 도움이 될 것이다.
3. 이것은 위키피디아가 토크 페이지와 사용자 페이지를 색인화하는 동안 검색 엔진에 가해지는 추가 부하를 가지지 않기 때문에 위키피디아의 속도를 엄청나게 높일 것이다.
4. 위키피디아는 백과사전의 역할을 하도록 되어 있지만, 사용자 페이지와 토크 페이지는 그것을 쓰는 사람들에게 도움이 되지만, 정보를 찾는 사람들에게는 도움이 되지 않는다.검색 엔진 결과를 클릭하고 사용자 페이지나 대화 페이지에 오르는 것은 방문자에게 매우 혼란스러운 일이다.
5. 이것은 위키피디아의 더 많은 페이지들이 제대로 색인화되도록 만들 것이다. 왜냐하면 위키피디아는 정규 페이지에 사용될 수 있는 더 많은 밴드와 서버 로드를 가질 것이기 때문이다.

--PinchasC £V€ € € € € € € € € 22:56, 2007년 7월 17일(UTC)[응답]

너는 한 번 이상 잘못된 가정을 했다.구글, 야후, 그리고 다른 주요 검색 엔진들은 위키피디아의 독립적인 전용 피드를 제공할 준비가 되어 있기 때문에 위키피디아에 어떠한 수화물 부하도 부과하지 않는다.그 대가로 그들은 그들의 데이터 센터의 서버와 공간의 형태로 물질적 지원을 제공했다.보다 일반적인 요점에 대해서는, 편집자로서 나는 다른 네임스페이스에서 내용을 찾기 위해 제3자 검색 엔진을 사용할 수 있는 것이 유용하다고 생각한다. 그리고 내 생각에 당신의 나머지 주장은 그것을 막을 수 있는 아주 설득력 있는 이유를 제공하지 못한다.드래곤즈 항공 2007년 7월 17일(UTC) 23:16편[응답]

나는 구글이 여전히 거울 사이트를 검색한다는 것에 주목한다 - 나는 이것이 인덱싱과 관련이 있는지 확실하지 않지만, 내 사용자 페이지를 구글에서 빠르게 검색한 결과 거울 세 개가 나왔다. 그 중 하나는 이미 몇 시간 전에 편집한 것을 포착했다.[2][3][4] --Tim4christ17 00:41, 2007년 7월 18일 (UTC)[응답]

나는 템플릿을 찾기 위해 구글을 자주 이용하는데, 이건 좋은 생각이 아닌 것 같아.팀 비커스 01:23, 2007년 7월 22일 (UTC)[응답]

나는 이 제안을 지지하지만 나는 이 제안에 대한 합의가 없는 것이 분명하다고 생각한다.우리가 구글 인덱싱에 접근하는 방법은 편집자가 아니라 독자에 관한 것이어야 한다.그럼에도 불구하고 나는 리디렉션 페이지는 인덱싱에서 제외되어야 한다고 생각한다.색인 작성은 검색 엔진 스팸 발송 이외에는 다른 목적이 없다!그 동안 시간이 좀 있는 사람이라면 누구나 맞춤형 구글 검색을 만들 수 있을 것이다(자세한 내용은 [5] 참조).이것은 구글에서 비아티클과 미러 사이트를 제외하는 데 사용될 수 있다. (사용할 것이다.)또는 위키 기사만 검색할 수 있고 위키백과의 내부 검색에 보다 유용한 대안으로 사용될 수 있다.2007년 7월 27일(UTC) 15:06, 주의바트 렉터[응답]

• 제안은 엉터리인 것으로 보이며, 미러 사이트는 색인화될 것이므로 제안자가 의도한 결과에 따라 성공적으로 이행될 수 없으며, 미러들은 그러한 차단 템플릿이나 명령을 그들이 획득한 페이지에 보관할 의무가 없다.검색엔진은 빅3, 4보다 훨씬 많다.또한, 사용자 페이지는 그들이 만든 라이센스로 인해 자유롭게 다운로드 받을 수 있다: 기본적으로 누구나 GFDL에 따른 모든 데이터를 얻을 수 있다. 만약 페이지들이 여기서 색인화되지 않았다면, 당신은 다른 여러 장소에서 색인화되거나 개인적으로 그렇게 될 것이라고 기대할 수 있다.로컬 인덱싱을 방지하면 편집자/사용자에게 얻을 수 없는 잘못된 프라이버시 및 보안의식을 제공할 수 있다. -- Yellowdesk 13:39, 2007년 8월 4일(UTC)[응답]

사용자 네임스페이스 전용?

나는 검색 엔진에서 사용자 네임스페이스를 제거하는 것이 합리적이라고 생각한다.그것은 편집자들의 사생활을 돕고 사용자 공간 허영심 기사를 방해한다.— 칼 (CBM · talk) 23:20, 2007년 7월 17일 (UTC)[응답]

하지만 그게 우리가 그들을 찾는 방법이기도 해.그리고 스팸 메일 사용자 페이지.MER-C 03:21, 2007년 7월 18일 (UTC)[응답]

맞아. 우리 내부 검색 엔진 상태가 좋아지면 이 얘기를 시작할 수 있을 거야.현재 구글은 유지 보수 작업에 너무 유용해서 그것을 무력화시킬 수 없다.쿠스마 (토크) 09:21, 2007년 7월 18일 (UTC)[응답]

나는 이 생각이 전혀 마음에 들지 않는다.만약 구글이 없었다면, 수많은 것들(토론, 사용자 페이지 등)은 쉽게 잃어버리고 필요할 때 접근할 수 없을 것이다.물건을 찾는 것은 이미 골칫거리야, 더 어렵게 만들지 말자.만약 여러분이 인터넷이 무언가를 알기를 원하지 않는다면, 여기 좋은 생각이 있다. 위키피디아처럼 공공성이 높고 눈에 잘 띄는 곳에서 그것에 대해 말하는 것을 그만둬라.사생활에 대해 걱정하는 사람이 있다면 위키피디아 페이지에 민감한 정보를 올려서는 안 된다. -- 네드 스콧 03:38, 2007년 7월 18일 (UTC)[응답]

기사 공간뿐만 아니라 이미지 공간도 검색해야 한다.(SEWilco 04:11, 2007년 7월 18일 (UTC)[응답]

우리에게 정말 필요한 것은 구글에 대한 의존도를 줄이기 위해 스팸이나 "나쁜" 사용자 페이지를 찾을 수 있는 봇이다.Nathanww 14:44, 2007년 7월 18일 (UTC)[응답]

나는 개인적으로 내 도구모음에 있는 사이트만을 대상으로 한 구글을 사용하여 위키피디아를 검색하고, 사용자들을 포함한 비아티클을 검색하는 경우가 많다.이것은 사생활 보호를 위해 나를 심각하게 불편하게 할 것이다.그 정보를 인터넷에 게재한 사람들에게.사용자 페이지를 가진 모든 사람들은 사생활에 대한 기대가 없다는 것을 안다.

나는 또한 백과사전에서 주제를 찾는 사람들이 그들의 구글 결과에서 매우 높은 사용자 페이지를 얻을 수 있을지 의심스럽다.아트로포스 00:20, 2007년 7월 20일 (UTC)[응답]

그 생각은 이론적으로는 훌륭하지만, 실제로 보면 나는 이것이 유용하다고 생각하지 않는다.모든 네임스페이스에 대한 구글 검색은 미디어위키 검색 엔진에 몇 가지 주의사항이 있다는 점을 고려하면 매우 도움이 된다.만약 사람들이 Userspace의 정보를 정보의 원천으로 사용하고 있다면 그것은 그들이 출처의 품질을 조사하지 않았다는 것을 보여준다.예를 들어, 만약 내가 기사에 어떤 정보를 사용하려고 한다면, 나는 내가 그것을 어디서 얻는지 모든 적절한 기준에 맞는지 확인한다.만약 내가 위키백과 기사를 다른 것의 출처로 사용한다면, 나는 먼저 위키백과에 약간의 연구를 할 것이고 Userspace가 신뢰할 수 있는 정보의 출처가 아니라는 것을 깨달을 것이다.Nicko(Talk•Contribs)나의 진행 상황을 검토하라! 2007년 7월 21일 03:23 (UTC)[응답하라]

첫 번째 두 문장에 동의하십시오.미디어위키의 내부 검색 시스템은 끔찍해!종종 효과가 없고 대신...Google 및/또는 Yahoo를 가리키십시오.그런 일이 계속 일어난다면, 우리는 사람들이 무엇을 지시받고 있는가가 내부 시스템 v.를 인위적으로 마비시키지 않도록 해야 한다.68.39.174.238 16:24, 2007년 7월 21일 (UTC)[응답]

모든 네임스페이스를 검색할 수 있다는 것은 매우 유용하다.우리가 타협안으로 가질 수 있는 것은 페이지의 색인화를 막는 템플릿이다...내 사용자 페이지 아래의 템플릿은 인덱싱되지만 내 사용자 페이지에서는 인덱싱되지 않는다(예를 들어).BigNate37_(T) 2007년 7월 23일 19:56 (UTC)[응답]

그것을 달성하려면 단순한 템플릿 이상이 필요할 것이다 - 미디어위키 소프트웨어를 변경해야 하거나 색인화해서는 안 되는 페이지 테이블을 만들어야 할 것이다.그렇게 하면 공감대가 형성될까?— 칼 (CBM · talk) 2007년 7월 24일 (UTC) 14:43[응답]

나는 이것을 지지할 것이다; 비록 그것이 어떻게 구현될지는 정확히 알 수 없지만.그리고 내장된 위키 검색도 별로 좋지 않다는 느낌이 든다.--HereToHelp 01:32, 2007년 8월 2일 (UTC)[응답]

• 위에 언급된 이유들로 인해, 그 제안은 엉터리인 것 같고, 편집자가 제안하는 방식으로는 성공적으로 이행될 수 없다. -- Yellowdesk 13:39, 2007년 8월 4일 (UTC)[응답]

제안: 사용자 페이지에 대한 선택사항 없음 색인

단순히 (사용자 공간에) 페이지를 나열하는 테이블을 만들 것을 제안한다.테이블의 페이지는 색인화를 방지하기 위해 헤더와 함께 제공될 것이다.이를 원하는 사용자는 자신의 페이지를 목록에 추가하도록 요청할 수 있다.이를 위해서는 미디어위키 코드에서 구현이 필요하다.요점은 자신의 WP 페이지가 구글에 나타나기를 원하지 않는 사용자들에게 더 큰 프라이버시를 허용하는 것이다.— 칼 (CBM · talk) 2007년 7월 24일 (UTC) 14:43[응답]

나는 그것이 사용자와 사용자 대화 페이지로 제한되는 한 그것에 동의할 것이다.2007년 7월 30일(UTC) 12:47, 박스 밖에서 생각하라[응답하라]

• 그래, 물론 소프트웨어 변경이 필요할 거야.하지만, 나는 왜 소프트웨어 변경으로 템플릿에 사용할 수 있는 마법의 단어를 구현할 수 없었는지 모르겠다.현장에서 누군가로서 말한다면, 개발자들이 우리가 원하는 것을 할 수 없을 것이라고 기대할 이유가 없다.만약 우리가 원하는 대로 정확히 가지고 있는 것에 문제가 있다면, 그들은 우리에게 차선책이 무엇인지 알려줄 것이고, 그 때까지 제안된 기능을 선제적으로 서약하는 것은 현명하지 못하다.이것은 꼬리표 대신 테이블 뒤에 있는 근거인 것 같다; 내 눈에는 템플릿이나 마법 같은 단어가 가장 좋을 것이다.BigNate37_(T) 16:36, 2007년 7월 30일 (UTC)[응답]

• 사이드 노트:이는 r23166의 페이지 보호 양식을 통해 가능했으나, r23226의 향후 호환성에 대한 우려로 브리온에 의해 삭제되었다.프로데고 16:46, 2007년 7월 30일 (UTC)[응답]

만약 이것이 비교적 쉽게 이루어질 수 있다면, 나는 그것을 지지하고 이용할 것이다.Adrian M. H. 16:51, 2007년 7월 30일 (UTC)[응답]

• 위에 언급된 이유들로 인해, 그 제안은 엉터리인 것 같고, 편집자가 제안하는 방식으로는 성공적으로 이행될 수 없다. -- Yellowdesk 13:39, 2007년 8월 4일 (UTC)[응답]

나는 수동 서버 구성(AFD)을 통해 우리가 이미 인덱스하지 않은 몇 가지를 제외하고 옵트인 노 인덱싱은 모든 세계에서 최악이라고 생각한다.정책 및 대화 네임스페이스에 대한 외부 검색은 너무 유용하다.그리고 몇 가지 예외를 제외하고는 그들은 별로 해를 끼치지 않는다.그러나 나는 일부 WP가 다음과 같은 사실을 알아챘다.FOO 스타일은 구글에서 하이라이트 히트로 올라온다 :(

나는 특히 사용자 NS가 특별한 경우라고 생각한다.사용자 NS를 인덱싱하면 안 되는 이유에 대한 자세한 내용은 아래를 참조하십시오. --Gmaxwell 17:50, 2007년 8월 5일(UTC)[응답]

제안: 사용자에 대한 필수 noindex/nofollow: ns

이것은 위키백과에서 옮겨졌다.빌리지_펌프_(제안)#사용자_pages_in_search_engines.3F

구글과 같은 것으로 사용자 페이지를 색인화해야 하는 이유가 있는가?나는 우리가 위키피디아의 로봇을 수정해야 한다고 생각해.사용자 네임스페이스의 페이지를 제외하는 txt(noindex, nofollow)그렇게 하면 사람들은 개인 정보를 사용자 페이지에 나열하는 것에 대해 더 편안함을 느낄 수 있다.게다가 사용자 네임스페이스를 검색하는 데 이점이 있는가?안드레 (토크) 2007년 8월 4일 (UTC) 23:00[응답]

나도 동의해.현재 많은 사람들이 다른 사람들의 사용자 공간에서 무언가를 삭제하는 것을 주저하는 우리의 행동을 남용하고, 사용자 페이지에 변절제와 POV 기사 포크를 주입한 사례가 꽤 있다.인터넷상의 무작위적인 사람들은 이 페이지들을 찾아내고 일반적인 기사 페이지로부터 그것들을 구분할 수 없다.물론 크러드를 찾으면 지워야지...하지만 이득을 부정하는 것도 생산적이다.또한 모든 사용자 페이지에 "이것은 사용자 페이지" 공지사항이 자동으로 표시되는 것을 보고 싶다.널리 사랑받진 않을 것 같아;;) 적어도 안드레의 제안을 받아들일 수 있도록. --Gmaxwell 23:04, 2007년 8월 4일 (UTC)[응답]

나는 이것을 하지 말아야 할 어떤 주요한 이유를 보지 못하며, 나는 Gmaxwell이 말했듯이, 그것은 일종의 "그들"이기 때문에 사람들이 페이지에 올릴 수 있는 모든 쓰레기를 무작위로 보는 것을 멈추는 것이 장점이라고 생각한다.나는 그것을 색인화에서 삭제하는 것은 사용자들이 그것을 개인 웹사이트로 만드는 것을 단념시킬 수도 있고, 아마도 위키피디아에 더 초점을 맞출 수도 있다고 생각한다."이것은 사용자 페이지"는 대부분의 사람들에게 효과가 있는 것을 볼 수 없다. 마치 사람들이 "사용자:xxxxx" 제목을 알아차리지 못하면 작은 배너를 알아차리지 못할 것처럼 말이다.그리고 큰 현수막은 모두를 짜증나게 할 것이다.그래서 전반적으로 나는 안드레의 제안을 지지한다.앤드루제이DTAK -- 2007년 8월 4일 (UTC) 23:46[응답]

사용자 공간은 정확히 스팸에 대한 우려 때문에 엔위키에서 오랫동안 따라오지 않았다.사용자 공간(또는 위키피디아의 다른 곳)에서는 노인덱스를 보지 않는 것이 낫겠다. 왜냐하면 우리의 내부 검색은 그다지 좋지 않기 때문이다.기사에 협력하든 중재 사건을 합치든, 사용자: 및 사용자 대화: 외부 엔진을 통한 네임스페이스(좋다, Google)를 검색할 수 있어야 할 많은 유익하고 유용한 이유가 있다.

Gmaxwell's and Andrew's에서위의 JD의 코멘트, 이 '랜덤 피플'들은 누구인가, 그리고 구글 검색에서 사용자 페이지들을 어떻게 접하고 있는가?우리의 기사들은 나머지 웹으로부터 너무 많이 연관되어 있기 때문에, 검색에서 엄청나게 빨리 올라오는 경향이 있다.기사 앞에 사용자 페이지를 접하기 위해서는 누군가가 검색 질의에서 다소 구체적이고 표적화된 키워드를 사용해야 한다고 생각했을 것이다...?TenOfAllTraes(토크) 2007년 8월 5일(UTC) 18:00[응답]

애초에 내가 엔에 대한 그 제안을 밀어붙인 사람이었기 때문에, 나는 메인 ns 이외의 외부 연결에 대해 어떠한 추종도 하지 않는다는 것을 잘 알고 있다.스팸 발송자들은 이제 그들이 메인 ns에서 보지 않은 기사를 스팸 발송하고 위키피디아에 모든 링크를 링크할 수 있다는 것을 발견했으므로, 만약 우리가 인덱싱이 그곳에서 일어나도록 허용한다면, 사용자 공간의 모든 링크도 따르지 말아야 한다고 생각한다.

어떤 경우에는 스팸으로 삭제되었기 때문에 우리는 기사가 없다.나는 몇몇 주식회사들이 위키피디아 사용자 페이지를 이런 식으로 사용하는 것을 본 적이 있다.허영심 때문에 사용자공간의 마이스페이스 페이지는 분명히 기사가 없을 것이다.

POV 기사 포크의 경우 사용자 페이지는 기본 기사 다음에 구글에서 세 번째 또는 네 번째 히트지만 여전히 상위 위치에 있는 것으로 볼 수 있다.

사용자: 네임스페이스에 대한 검색의 필요성을 누군가 증명할 수 있다면, 입장을 바꾸겠지만, 현재 상태로는 우리가 인덱스를 사용하지 말아야 할 이유를 모르겠다. --Gmaxwell 18:19, 2007년 8월 5일 (UTC)[응답]

적어도 사용자 페이지에 대해 선택적으로 noindex를 활성화할 수 있을까?나는 내 많은 사람들을 그것에 맞추었을 것이다.안드레 (토크) 2007년 8월 5일 21:35 (UTC)[응답하라]

대화형 멀티미디어 콘텐츠: 위키피디아에서 스크래치?

위키피디아에 Interactiv Media Content가 없다.그것을 포함한 방법이 있었다면 더 쉽게 설명하고 배울 수 있는 것이 많다.일부 다른 백과사전에는 위키백과(예: 엔카르타)에 대한 가장 큰 장점 중 하나로 Interactiv Media Content가 포함되어 있다.그러나 다른 위키백과 매체의 데이터 유형이 분명해 보이는 곳에서는 인터랙티브 매체가 문제를 가지고 있다.

• 강력한 "모래박스"여야 한다(위키피아의 사용자에게 해를 끼치지 않도록)
• 인쇄 가능한 방식과 선명한 프레임(그림처럼)으로 표시해야 한다.
• 오픈 소스 및 공통 기술에 기반해야 함
• 프로그래머가 아니더라도 쉽게 만들 수 있어야 한다.
• 그것은 학력이 있어야 한다.

이 목록을 자유롭게 확대하십시오.예를 들어 Java, Flash와 같은 대화형 데이터를 생성하는 가장 잘 알려진 방법은 이러한 요구를 충족하지 못할 것이다.

새로운 시각 프로그래밍 언어 Scratch가 그것을 충족시킬 수 있을 것이라고 생각한다.

스크래치는 MIT 미디어랩의 평생유치원 단체가 교육 목적으로 만든 것으로 교사와 학생들로 구성된 커뮤니티가 튼튼하게 성장하고 있다.샌드박스, 액자, 오픈소스, 매우 배우기 쉽고, 교육적 배경(원래 학교 아이들을 위해 발명되었다)을 가지고 있다.스크래치 플레이어가 자바를 기반으로 한다고 해도, 스크래치 코드는 이 플레이어에 의해 해석되고 샌드박스가 훨씬 더 강하기 때문에, 필요한 유일한 자바 프로그램이다.

Scratch Project는 그렇게 하도록 만들어지지 않았고 어린이에 의해 만들어지더라도 반드시 그렇게 하지 않아도 다음과 같은 몇 가지 Scratch Project가 있다.

• 유럽을 아십니까?
• 심장 시뮬레이션
• 진공 청소기
• 단순 전기 회로
• 광합성
• 작곡가
• 레고 모델 크리에이터
• 건축 스탬프

스크래치 포룸에서 우리는 위키피디아와 스크래치를 연결하는 것에 대해 토론했고 나는 여기서 그것을 제안하도록 격려받았다.Scratch의 집을 볼 때 가끔 유치한 프로젝트에 대해 웃지 마십시오.아이들은 우리의 미래고 그들이 사랑하는 기술의 잠재력은 크다.

미리 피드백해주셔서 감사하다.Mtwoll 19:08, 2007년 8월 7일 (UTC)[응답]

이렇게 하는 한 가지 방법은 스크래치 파일을 업로드할 수 있게 한 다음 이미지 설명 페이지나 다른 페이지의 인라인으로 표시하기 위해 자바 스크래치 플레이어를 사용할 수 있게 하는 것이다.이것은 이것을 가능하게 하기 위해 연장이 필요할 것이다.트라 (토크) 2007년 8월 7일 21:51 (UTC)[응답]

나는 Scratch 온라인 커뮤니티의 발전을 이끌고 있다.이것이 필요하다면 Scratch 웹사이트에서 주최하는 프로젝트들을 위키피디아로 쉽게 밀어넣을 수 있도록 기꺼이 도울 것이다.나는 위키피디아에서 플리커의 사진을 본 적이 있다.수동으로 하는 겁니까, 아니면 자동화된 시스템이 있는 겁니까?어쨌든, 스크래치 팀이 비전문 프로그래머들이 위키백과에 프로그램 가능한 미디어를 제공하도록 할 수 있는 일이 있다면 우리에게 알려달라.안드레스미

과거에 위키피디아는 다른 웹사이트의 미디어 핫링크를 피했다(Wikimedia Commons 및 자매 프로젝트인 일부 Toolserver 스크립트 별도).이것은 주로 미디어가 다른 웹사이트에 있을 경우, 위키백과 사용자 이름으로 연결하여 전체 개정 내역을 볼 수 없고, 제3자 서버가 고장날 위험이 있거나, 미디어가 위키백과에서 사용하기에 부적합한 방식으로 삭제되거나 수정될 수 있기 때문이다.또한 누군가가 누군가의 저작권을 침해할 수 있는 어떤 것에도 연결시키는 것이 매우 쉽다는 문제도 있다.

이것은 단지 일반적인 의미일 뿐이다.Scratch 사이트 설계 방법에 따라 이러한 문제의 일부 또는 대부분은 적용되지 않을 수 있지만, 타사 사이트의 핫링크 미디어가 아닌 안전한 쪽에 있는 것이 가장 좋다.Flickr 사진은 Flickr에서 다운로드한 후 Wikimedia Commons에 별도로 업로드되었다.

핫링크가 없어도, 위키백과 페이지에 Scratch 프로젝트를 내장하는 것은 여전히 개발자의 참여가 필요할 것이다. 왜냐하면 위키 코드의 Scratch 파일에 대한 참조를 입력할 수 있고 애플릿에 대한 링크를 생성할 수 있도록 MediaWiki 소프트웨어에 대한 확장이 코딩되어야 하기 때문이다.Scratch 업로드를 활성화하려면 개발자 참여도 필요하지만, 화이트리스트에 파일 확장자를 추가하기만 하면 되기 때문에 비교했을 때 훨씬 간단하다.

현재 당신이 할 수 있는 것에 대해, 현재 가능한 유일한 방법은 기본적인 하이퍼링크로 Scratch 웹사이트에 있는 페이지로 링크하는 것이다.트라 (토크) 03:24, 2007년 8월 8일 (UTC)[응답]

이동 보호

움직일 필요가 없는 기성 기사의 이동을 보호하는 것은 고려할 만한 것일 수 있다.예를 들어 조지 W. 부시 랫이나 제리 팔웰이라는 기사가 옮겨져야 할 이유가 전혀 없기 때문에, 그러한 기사들을 보호하지 않는 유일한 "이익"은 페이지 이동 반달리즘의 가능성을 열어두는 것이다.멜사란 (구 살라스카바스) 2007년 8월 6일 (UTC) 19:13[응답]

첫 번째 예는 이동 보호됨입니다.둘째는 그렇지 않다.구체적으로 어떤 제안을 하셨습니까?기사의 이름이 "올바른" 경우, 누가 정확히 결정해야 하며, 따라서 이동 보호를 받아야 하는가?덜 중요한 기사에도 이렇게 해야 할까?만약 그렇지 않다면, "덜 중요한 것"과 "더 중요한 것"을 누가 결정하겠는가? -- 존 브레튼 (식용차) 20:18, 2007년 8월 6일 (UTC)[응답하라]

이 제안은 몇 달 전에 제기되었으니 가능하면 기록 보관소를 한번 살펴보십시오.반응이 좀 엇갈린 것 같다.아드리안 M. H. 20:57, 2007년 8월 6일 (UTC)[응답]

WP에 등록하십시오.PEREN :) 멜사란 (이전 살라스카바누스) 21:12, 2007년 8월 6일 (UTC)[응답]

그럼 안 좋은 예.그럼에도 불구하고, 이것은 이름이 안정적이고 결코 바꿀 필요가 없는 많은 기사들에 적용된다.멜사란(옛 살라스카바스) 21:12, 2007년 8월 6일 (UTC)[응답하라]

개인적으로, 나는 그것이 나쁜 생각은 아니라고 생각한다.그러나 존이 지적한 바와 같이, 그것의 실행에는 의사결정 기반의 어려움이 있다.아드리안 M. H. 21:25, 2007년 8월 6일 (UTC)[응답]

다른 사람들이 지적한 바와 같이 이것은 소유권 문제를 야기한다.나는 당신이 그 이름이 영구적이어야 한다고 생각하지만 어느 정도는 의문을 제기할 수 있는 기사를 생각해낼 수 있다. 예를 들어, 루이스 캐롤은 실제 삶인 찰스 러트위지 도그슨(리디렉트)의 유명한 필명인데, 이 필명은 아마도 움직이는 것이 타당할 것이다.Dcoetzee 22:20, 2007년 8월 6일 (UTC)[응답]

이달의 위키백과

나는 이달의 위키피디아를 시작하는 것이 좋을 것 같아.우리는 후보자들이 한 달 동안 그들의 주장을 밝히도록 할 것이고 편집자들은 그들이 그 달의 위키백과가 되어야 한다고 생각하는 사람들에게 투표할 것이다.이달 말에 개표가 되고 가장 많은 표를 가진 사람은 이달의 위키백과가 된다.--텍사스 남부 18:00, 2007년 8월 6일 (UTC)[응답]

그리고 "이 달의 위키페디안"은 어디에 등장할까?커뮤니티 포털에서?멜사란 (구 살라스카바스) 2007년 8월 6일 (UTC) 19:13[응답]

어떡해, 백슬래핑 더 해?이런 종류의 일은 아무런 긍정적인 효과도 없다.기껏해야 몇 개의 자아를 마사지하고, 최악의 경우에는 패거리 투표를 보게 될 것이다.아드리안 M. H. 20:54, 2007년 8월 6일 (UTC)[응답]

위키백과 대화에서 이전 제안을 참조하십시오.피처링된 콘텐츠/아카이브 1#피처링된 프로젝트요약하면:아니다. "기능적" 상태는 사용자, 템플릿, 범주 또는 기타가 아닌 백과사전적 내용을 강조하기 위한 것이다.

이와 같은 것들은 현재 위키피디아에 있는 불경함으로 빠르게 침투한다.최상의 사용자 페이지 콘테스트.(누군가가 정말로 MfD에게 해야 할 일) --Quiddity 21:08, 2007년 8월 6일 (UTC)[응답하라]

나는 그것이 편집자들을 더욱 건설적이게 만들 것이라고 생각한다. 왜냐하면 그들은 그 달의 위키피디어가 되고 싶어하고 더 열심히 일할 것이기 때문이다.백과사전 확장에 유리할 것이다.--텍사스 남부 21:31, 2007년 8월 6일 (UTC)[응답하라]

이론상으로는 좋지만 실제로 이 모든 것은 감정을 상하게 하고 사람들을 배제하는 것이다.편집을 위해 위키백과를 편집하는 것을 즐기지 않는다면, 아마도 --L-- 21:33, 2007년 8월 6일 (UTC)[응답]을 거치지 말아야 할 것이다.

L. ElinorD (대화) 21:36, 2007년 8월 6일 (UTC)[응답]에 동의할 마음이 있다.

사람들은 그들이 좋은 일을 하고 있는지를 알기 위해 확언할 필요가 없어야 한다.아드리안 M. H. 21:38, 2007년 8월 6일 (UTC)[응답]

만약 누군가가 그것을 얻지 못한다면, 그것은 그들에게 더 열심히 일하는 동기가 될 것이고 백과사전에 플러스가 될 것이다.누군가에게만 반대표를 던질 수는 없을 것이고, 사람에 대한 모욕적인 논평은 없을 것이기 때문에, 그 누구도 감정을 상하게 할 수는 없을 것이다.만약 당신이 누군가에게 투표하지 않는다면 당신은 코멘트를 남기지 않을 것이고 그들이 어떤 표를 받든 그들은 기분이 좋아질 것이다.만약 그들이 표를 얻지 못하면 그들은 더 열심히 일할 것이다.-- 텍사스 남부 21:40, 2007년 8월 6일 (UTC)[응답하라]

아니, 표를 못 받으면 굉장히 낙심할 것 같아.아드리안 M. H. 21:42, 2007년 8월 6일 (UTC)[응답]

사실은 어떤 사람들은 그들이 하고 있는 일이 선하다는 확신이 필요하다는 것이다.나는 개인적으로 그렇지 않지만 나는 이런 사람들이 배제되어서는 안 된다고 생각한다.이것은 그 달의 종업원을 사용하는 사업에서와 마찬가지로 생산성에 대한 관심을 증가시킬 것이다.경쟁적인 성격이 생산성을 높인다.나는 관리자가 제외되어야 하고 편집 제한이 있어야 한다고 생각한다.이것은 사용자들을 더 생산적으로 만들고 기사를 더 좋게 만들 것이다.편집자들은 적어도 한 표는 얻도록 자신을 지명할 수 없어야 한다.--텍사스 남부 21:47, 2007년 8월 6일 (UTC)[응답]

왜 편집자가 헛별이나 다른 형태의 인정을 받는 것만으로는 충분하지 않을까?존 카터 2007년 8월 6일 (UTC) 22:11 (응답)

500 또는 심지어 1000개 미만의 편집자가 편집하는 경우는 드물기 때문이다.--텍사스 남부 22:21, 2007년 8월 6일 (UTC)[응답]

그래서 아마도 당신은 편집이 거의 없는 편집자들조차 지명될 수 있다고 생각할 것이다.아마도 그 당시 그 이름을 주목한 사람은 거의 없었을 것이다.그 근거로, 나는 당신이 말하는 것이 단지 한두달의 경험을 가진 사람들을 위한 "이 달의 뉴코머"와 비슷한 것일 수도 있다고 추측한다.나는 그러한 과정이 사람들을 떠나게 할 가능성이 훨씬 더 높다고 생각하는데, 이 비교적 새로운 사람들은 그들의 새로운 기여가 이기기에는 충분하지 않을 경우 부정적인 반응을 보일 가능성이 훨씬 더 높기 때문이다.존 카터 22:25, 2007년 8월 6일 (UTC)[응답]

에스텍스, 왜 이렇게 하면 생산성이 높아진다고 생각하십니까?그것은 많은 시간 낭비, 투표, 인기 경쟁, 소셜 네트워킹, 노력, 그리고 드라마를 유발할 것이다. 이 모든 것이 위키피디아를 더 나은 곳으로 만드는 데 들어갈 수 있다.그리고 우리가 얼마나 많은 편집자들이 있는지 생각해봐- 당신은 정말로 연간 12명의 위키피디아를 선택하는 것이 그들이 결코, 인기있거나 충분히 알려져 있지 않을 것이라는 것을 아는 다른 사람들을 좌절시키지 않을 것이라고 생각하는가?또한, 당신이 말하는 것은 나를--- 왜 위키피디아가 서로 경쟁하도록 해야 한다고 생각하는가?우리는 모두 협력에 관한 것이고, 만약 우리가 스스로를 고립시킨다면 우리는 그 프로젝트에 해를 끼칠 뿐일 뿐이다.우리는 이미 GA, FA, DYK 기사를 만든 것에 대한 보상이 있고, 우리는 이미 헛스타도 있지만, 사람들이 백과사전에 더 많은 노력을 기울일 것이라고 생각하는가? 아니면 단지 TIME에서 인기 경연대회에 더 많은 노력을 기울일 것이라고 생각하는가? --L-- 22:26, 2007년 8월 6일 (UTC)[응답]

생산성을 높이고 생산적인 사용자를 추가하려는 아이디어에 불과했다.모두의 시간을 낭비해서 미안해 텍사스 남부 22:41, 2007년 8월 6일 (UTC)[응답]

좋은 평가를 받지 못한 한 가지 아이디어 때문에 미루지 마십시오.아드리안 M. H. 23:18, 2007년 8월 6일 (UTC)[응답]

동의한다. 그 생각은 나쁘지 않다; 불행히도, 이미 많은 역사가 있어, 사형 집행이 종종 아쉬움을 남기곤 하는데, 이것은 별개의 문제다.그리고 그것은 당신이 생각하기에 효과가 있다고 생각하는 아이디어를 제안하는 데 낭비되는 시간이 아니다.개인적으로, 나 자신도 개의치 않겠지만, 역사는 그것이 용서받지 못하고 원치 않는 결과를 초래할 가능성이 있다는 것을 말해주는 것 같다.아쉽게도.존 카터 2007년 8월 6일(UTC) 23:30[응답]

이를테면, 주어진 달에 가장 건설적인 편집을 하는 새로운 편집자는 그 달의 위키백과라고 할 수 있다.--텍사스 남부 00:59, 2007년 8월 7일 (UTC)[응답]

헛간 별을 써라.위키백과에 문의:위키프로젝트 상은 "뉴코머 헛스타" 같은 것을 만드는 것에 관한 상입니다.새로운 공정을 발명하는 대신에, 항상 이미 제자리에 있는 공정을 사용하려고 노력하라. 그렇게 하면 당신은 읽을 수 있는 추가 페이지의 지시를 피할 수 있고, 이 경우에는 매달 많은 편집자들에게 헛간스타를 줄 수 있다. --Quidity 04:15, 2007년 8월 7일 (UTC)[응답]

Quiddity에 동의하며, 당신의 가장 최근의 논평에 관해서 Excellence New User Award에 대한 것 입니다. --Tλε RαnΔomor (tαlk) 00:24, 2007년 8월 12일 (UTC)[응답]

그것은 좋지 않은 생각이고 너의 반응은 왜 완벽한지를 보여주었다.누군가 잘했다고 느끼면 직접 가서 토크페이지에 나와 감사 인사를 전한다.--Svetovid 15:59, 2007년 8월 16일 (UTC)[응답]

위키백과:인용구

위키백과의 {{proposed} 배너를 복원했다.인용구(WP:인용) {{역사적}}}}로 교체된 것 같기 때문에 논의도 없이 잠시 후.공식적으로 이 제안을 거절하거나 다른 방법으로 검토에서 제외하는 것에 대해 논의한 어떤 토론을 지적할 수 있는 사람이 있다면, 해당 토론 페이지에 유의하십시오.

이전 제안에 대한 통지를 받을 수 있는 시간이 조금 지난 후, 현재 관행을 반영하거나 새로운 제안을 제정할 수 있도록 검토 및 편집했으면 한다.나는 특히 GFDL이 요구하는 편집 이력이나 다른 신용과 관계 없이 위키피디아 기사에서 위키피디아 기사로 인용문을 대량으로 전송하는 편집자들의 문제가 증가하는 것에 대해 우려한다. (q: 참조)WQ:VP#Probable GFDL 문제는 이 문제에 대한 열띤 토론의 최근 결과에만 부적절한 트랜스위키에 대한 문제임.)위키피디아에서는 방대한 문제를 해결하는 것이 합리적으로 할 수 있는 것보다 훨씬 더 많은 작업이기 때문에 이러한 기여를 간단히 삭제하기 시작하고 있다. (결국, 모든 활동적인 위키피디아에는 적어도 150명의 적극적인 위키피디아 사람들이 있다.)단순 삭제는 위키미디아의 이익에 거의 도움이 되지 않기 때문에 어디서, 언제, 어떻게 할 것인가에 대한 형식적이고 실용적인 정책을 수립해야 하는데, 이 제안 페이지는 그 논리적인 본거지인 것 같다.

나는 이 잠재적인 가이드라인을 개발하는 데 도움을 주었으면 한다.위키피디아인들도 도움을 요청할 예정인데, 위키피디아인들도 많이 위키피디아인이며, 2007년 8월 5일(UTC) 제프 Q (토크) 22:18, 2007년 8월 5일(답)

어, 다시 생각해 보니, 역사 태그 문제는 건너뛰어도 될 것 같아.나는 이것이 민감한 주제가 될 수 있다는 것을 이해하게 되었고, 여기서 우리가 그것에 대해 논의할 필요가 없다고 생각한다.역사와 관계없이, 이제 우리는 위키피디아에서 인용문에 언제 포함시켜야 하는지, 언제 위키피디아로 옮겨야 하는지에 대해서만 언급하더라도 인용문에 대한 일부 지침을 가질 수 있는 설득력 있는 이유를 갖게 되었다.(그 이상의 것이 있을 것이라고 확신하지만, 이 문제만으로도 한 페이지에 대한 긴급한 명분이다.)그러니 기대해보자.~ 제프 Q (토크) 01:58, 2007년 8월 6일 (UTC)[응답]

• 응, 공격해줘서 고마워."역사학"은 비활동적인 것을 의미하므로, 만약 어떤 것에 대한 토론이 없다면, 그것은 정의상 역사적이다.이게 무슨 관료적 절차라고 생각하셨나요?>래디안< 10:50, 2007년 8월 6일 (UTC)[응답]

빛나, 내가 널 공격하고 있다고 느낀 건 미안해.위키백과 정책/가이드라인 제안 승인 및 거부의 공식 프로세스에 익숙하지 않다는 것이 나의 우려였다.몇 분 동안 위키피디아를 복습했다.정책 및 지침, 카테고리:위키백과 제안서, 카테고리:위키피디아는 제안서, 이 페이지, 그리고 위키피디아의 대화를 거절했다.인용문, 그리고 이 제안을 종결시키기 위한 논쟁이 있다는 것을 시사하는 것은 아무것도 발견하지 못했는데, 단지 그 제안이 힘을 잃었다는 한 편집자의 결정일 뿐이었다.그러나 나의 빠른 리뷰는 처음 보는 정책 제안자에게 분명하지 않은 어떤 것을 쉽게 놓칠 수 있었으므로(정말 관료적일 수 있고 대부분의 다른 위키미디어 프로젝트보다 형식적인 것을 많이 가지고 있는 위키백과 내의 그렇게 많은 과정에 대한 사실처럼) 나는 뭔가 빠뜨리지 않았는지 확인하고 싶었다.

나는 철저히 하려고 노력하면서 지금까지 발견한 사실을 진술하고 내가 놓친 정보를 요구했다.내가 발표한지 몇 분도 지나지 않아, 나는 몇몇이 나의 암묵적인 비판에 예외를 둘지도 모른다는 경고를 받았다. 따라서 나의 그 이후의 주의는 위에 있었다.비판은 나의 의도가 아니었다.Wikiquote에서 WP로부터 인용문을 전송하려는 좋은 의도를 가지고 있지만 기고 증명 요건을 모르는 위키피디아에 있는 우리 중 많은 사람들이 거대한 GFDL 위반을 수정하거나 삭제하는 것에 싫증이 나기 때문에, 위키피디아는 위키피디아와 위키피디아가 어떻게 상호작용하는지를 확립할 수 있는 장소를 확보하는 것이 나의 주된 목표다.

나는 너의 역사적 꼬리표와 싸우지 않는다.나는 그 이유를 이해한다고 믿으며, 그 당시에는 아무도 그것에 동의하지 않았다.하지만 우리는 지금 분명히 무언가가 필요하다.이 무심코 저지른 범죄에 대한 나의 사과를 받아주시고, 이 제안서를 다시 부활시키고 갱신하는 노력으로 나아갈 수 있기를 바란다.~ 제프 Q (대화) 13:42, 2007년 8월 6일 (UTC)[응답]

그런데, 나는 지난 며칠 동안 컴퓨터 오프로 인해 대부분 오프라인 상태였어.주말이 끝나기 전에 위키피디아의 인용구를 중심으로 내가 보는 이슈들의 목록을 제시했으면 한다.이미 WPt에서 개별 질문에 대한 일부 활동이 진행되고 있다.인용, 그리고 나는 내 세탁물 리스트가 추가되면 거기에 어떤 조치가 취해지길 바란다.~ 제프 Q (토크) 01:10, 2007년 8월 10일 (UTC)[응답]

자원

이봐, 나는 오직 다른 사람들이 기사 출처를 찾는 것을 돕는 것에만 전념하는 위키백과 사람들이 있는지 알고 싶어.나는 꽤 많은 데이터베이스에 접근할 수 있고 가능한 많은 사람들을 돕고 싶기 때문에, 그러한 요청에 대한 중앙 위치가 도움이 될 것이다. --Cronholm¹⁴⁴ 06:08, 2007년 8월 8일 (UTC)[응답]

네. (이들 중 일부는 비활성 상태여서 아마도 합병되어야 할 것 같다.)참조:

• 위키백과:WikiProject 팩트 및 참조 확인(주)
• 위키백과:WikiProject 리소스 Exchange(신규, 활성)
• 위키백과:연구 리소스(가장 오래된 자료, 비활성 자료로 태그 지정됨) (오른쪽 상단 탐색 상자의 링크 참조)
• 위키백과:라이브러리(오프라인 리소스)

도움이 되었으면 좋겠다. --Quiddity 17:12, 2007년 8월 8일 (UTC)[응답]

와우, 도서관 목록을 만들려는 노력이 있었나?나로서는 놀라운 일이네, 특히 내가 독립적으로 비슷한 아이디어를 생각해 내고 User:BigNate37/도서관...BigNate37_(T) 17:18, 2007년 8월 8일 (UTC)[응답]

이것은 도움이 된다 :) 나는 몇 가지 제안을 가지고 돌아올지도 모른다.건배--크론홀름¹⁴⁴ 11:08, 2007년 8월 9일 (UTC)[응답]

다음 사항도 고려하십시오.

• 위키백과:신문과 잡지가 서비스를 요청하다.
• 도서관의 위키백과 그룹Thing.com

그리고 위키백과 네임스페이스에는 단순히 자원을 나열하는 페이지들이 많이 있는데, 다른 사람들을 돕는 위키백과 사람들에 대해서만 물어보셨기 때문에 여기에 생략하고 있는 겁니다. -- 존 브로턴 (리위스) 18:25, 2007년 8월 9일 (UTC)[응답]

통화

전에도 이런 일이 고려됐을지 모른다는 의심이 들지만, 만약 그렇다면 그 결과를 알 수 없다.

통화금액이 템플릿으로 인용될 수 있는 통일된 방식을 갖는 것이 독자에게 유용한 연결고리가 될 수 있다고 생각한다.

내가 예상하는 것({{currency}})은 이미 {{currency}이(가) 여러 링크로 리디렉션되어 존재한다는 사실을 잠시 제쳐두고) 다음과 같은 것을 입력할 수 있는 설정이다.

{{환율 GBP 20}}

또는

{{환율 CHF 30}}}

그리고 이것은 기사에서 "20파운드" 또는 "30 Fr"(기호와 순서를 고려함)과 같은 것으로 제공되지만, 관련 기사에 대한 링크(예: 파운드화 또는 스위스 프랑)가 있는 페이지로 이동하며, 또한 이 금액의 현재 동등한 가치를 보여주는 제3자 웹 사이트로 연결되는 링크로서 제공된다.어 통화(서적 출처와 모호하게 유사한 것).

이는 질의 정보를 적절히 포함시키는 일부 URL 형식을 지원하는 제3자 사이트에 다소 의존하지만, 그렇지 않다면 위키백과에서 생성된 트래픽의 전망은 사이트 유지 관리자들이 이를 이행하도록 설득하기에 충분할 것이다.

표시장치 기호를 재정의하거나 과거 변환 날짜를 지정하는 것과 같은 다른 템플릿 옵션이 있을 수 있다는 것은 의심의 여지가 없지만, 이것이 그것의 요지다.

이것이 바람직하게 들리는가?실현 가능한가?

나는 아마도 내가 이것을 실제로 도울 시간이나 지식이 없다는 것을 인정해야만 한다. 그래서 그것은 다른 누군가가 그 성향을 가지고 있느냐에 달려 있을 것이다.

대단히 고맙습니다— 앨런^✉ 11시 42분, 2007년 8월 7일 (UTC)[응답]

통화에 관한 위키백과 지침은 위키백과에 명시되어 있다.스타일 매뉴얼(날짜 및 숫자)#커론즈.제안을 하고 싶다면, 그 가이드라인의 토크 페이지는 아마도 가장 좋은 장소일 것이다.

그 말을 한 이상, 나는 여기에 근본적인 오해가 있을지도 모른다고 생각한다.첫째, 유로 대 달러 배율이 1:1.37인지, 아니면 .95:1인지에 대해서는 별로 중요하지 않다.위키피디아 기사에 역사적 정보가 담겨 있기 때문이다. "X가 2002년 10만 달러에 Y를 매입했다"는 기사가 나온다면 현재의 환율은 거의 무관하다.둘째, MoS 페이지에 언급된 바와 같이, ₮에서와 같이, piped 링크를 사용하는 것이 항상 가능하다; 관심 있는 독자는 기사에 대한 링크를 따를 수 있다. (나의 1개 통화에 대한 나의 비랜덤 샘플링에 근거) 독자가 그렇게 관심이 있다면, 환전 사이트로의 링크를 포함할 것이다. -- John Brownon (UTC) 18:43, 2007년 8월 9일 (UTC)[응답)

전기 정보 상자 넌센스

음, 어쩌면 말도 안 되는 말이지만, 왜 전기에는 그 사람의 나이와 생년월일이 함께 포함되어 있는지 말해줄 수 있을까?시대가 바뀔 것이기 때문에, 그 후에 매년 업데이트를 해야 한다는 것을 느낄 뿐만 아니라, 나는 그것이 어떤 독자들에게도 간접적으로 모욕적이라고 느낀다.우리는 독자가 생년월일로부터 현재의 연도를 뺄 수 없다고 가정하고 있는가?

어쨌든 백과사전을 열어라.당신은 생년월일(해당되는 경우 사망일)을 찾을 수 있지만, 기입사항의 작성 현재 나이를 포함시키는 것은 어리석은 일일 것이다.내가 생각할 수 있는 유일한 시간은 죽음을 위한 것이다.

살아 있는 사람의 전기에 그 사람의 현재 나이를 포함시키는 추리를 알고 싶을 뿐인 것 같다.

디켄 15:59, 2007년 7월 31일 (UTC)[응답]

인포박스에 있는 템플릿은 자동으로 나이를 계산하여 연간 업데이트가 필요하지 않다.나는 그것이 예의라고 생각한다.그렇다, 누구나 간단한 계산을 하는 것은 매우 간단하지만, 그것에 대해 생각하지 않아도 몇 초를 절약할 수 있다.나는 정말 그것에 대해 불평할 이유가 없다고 생각한다.레이와스92^Talk 16:13, 2007년 7월 31일 (UTC)[응답]

나는 너의 마지막 진술이 무례하기도 하고 미끼가 되기도 한다고 생각한다.나는 우려를 게시했다.만약 고민거리가 당신에게 "불만"이라면, 왜 여기서 귀찮게 굴까?

다음 단계로 넘어가면, 나는 그것이 불필요하고 비위생적이라는 것을 알게 된다.위키피디아의 "동적" 형식과 상관없이, 나는 정보가 중복된다고 생각한다.디켄 16:23, 2007년 7월 31일 (UTC)[응답]

인쇄 백과사전이 이렇게 하지 않는 주된 이유는 정보가 시대에 뒤떨어지기 때문이다.위키피디아는 종이가 아니다.나는 나이가 자동으로 생성된다는 것을 스스로 확인하지는 않았지만, 그 대신에 나이를 수동으로 입력했다면 나는 그것이 헛되지 않을 것이라는 것에 동의한다.어쨌든 템플릿의 예에 나와 있는 나이는 보이지 않는다.인포박스 전기.이게 네가 말한 템플릿이니?BigNate37_(T) 16:17, 2007년 7월 31일 (UTC)[응답]

그 템플릿은 어떻게 생겼어야 하는지를 보여주는 좋은 예다, IMO. 그러나 실제 전기의 일부를 보면 자동으로 연령을 계산하는 마크업(mark up이 있다.나는 그것을 몰랐고, 나에게 그것은 더 말이 되지 않는다.디켄 16:25, 2007년 7월 31일 (UTC)[응답]

나이는 별로 상관없어.나를 더 괴롭히는 것은 저 빌어먹을 깃발들이다.사람들이 깃발을 보는 대신에 미국이라는 단어를 그냥 읽을 수는 없을까?:) 가리온96 (대화) 2007년 7월 31일 16:31 (UTC)[응답]

모든 사람들이 알도록 디켄은 생년월일에 인포박스 분야에서 {{생년월일과 1931년 03년 22}}을 사용하는 것을 언급하고 있는데, 그 결과는 다음과 같다: (1931-03-22) 3월 22일 (1931년 3월 22일.

나를 최악의 경우, 해롭지 않고, 기껏해야 유용하다고 생각하는 사람들의 리스트에 추가해 주시오.그것은 컴퓨터로 하여금 계산을 하게 하므로 사용자는 그럴 필요가 없다.나는 그 문제를 이해할 수 없다. --barneca (대화) 16:36, 2007년 7월 31일 (UTC)[응답하라]

무해하다고?아마도.유용한가?내 생각으로는 그렇지 않다.사실 위에서 언급했듯이 간접적으로 모욕감을 느낀다.게다가, 그것은 불필요하다.디켄 16:59, 2007년 7월 31일 (UTC)[응답]

나는 그것이 매우 유용하다고 생각한다.전 수학 실력이 좋아요.아트로포스 19:35, 2007년 7월 31일 (UTC)[응답]

괴상하지만 유용한 디켄 20:20, 2007년 7월 31일 (UTC)[응답]과는 거리가 멀다.

나는 이것이 내가 찾을 수 있는 진기한 것에 대한 어떤 정의와도 맞지 않는다고 생각한다.다시 말하지만, 나는 그것이 매우 유용하다는 것을 안다; 너는 나보다 나에게 유용한 것에 대해 더 많이 알고 있다고 제안하고 있지 않니?아트로포스 02:46, 2007년 8월 9일 (UTC)[응답]

아, 템플릿:생년월일과 나이.이것에는 문제가 있어. 다른 페이지에 걸쳐 일관성이 없어.이와 같은 기능은 전혀 사용하지 않거나 Infobox에 통합해야 한다.infobox의 페이지 자체는 그것을 사용하는 방법을 설명하고 있고 생년월일 필드에 나이를 추가하는 것에 대해 언급하고 있지 않기 때문에, 나는 infobox에서 나이 생성 템플릿을 사용하는 것은 부적절하다고 제안하고 싶다.그러므로, 만약 우리가 진정으로 이 나이대의 행동 발생을 원한다면, 그것은 infobox 템플릿에 내장되어야 하고, 그렇지 않으면 그것은 전혀 일어나지 말아야 한다.BigNate37_(T) 16:45, 2007년 7월 31일 (UTC)[응답]

나도 동의해.적어도 일률적으로 적용해야 한다.디켄 16:59, 2007년 7월 31일 (UTC)[응답]

위키백과에 중복성과 불균일성이 꽤 있는데, 이것이 하나의 예다.중복은 종종 좋은 것이다.infobox에 있는 대부분의 정보는 또한 기사에 있다; 그것은 중복적이다.infobox에 정보를 가지고 있는 것은 여전히 편리하다.예를 들어, 불균일성에 대해서는 유사한 템플릿이 있다.생년월일 필드의 옵션으로 명시적으로 {{생년월일 및 연령}을 제안하는 Infobox Person.템플릿 토크에서 (분명히, 내가 합의판사라면, 성공적) 토론이 있다.Infobox Person#Merge를 모두 결합한다.디킨, 나는 네가 이것에 의해 모욕당한 것에 대해 화를 내는 것에 대해 어리둥절해 한다. 아무도 사용자들이 뺄 수 없다고 말하지 않는다.이 작은 상자는 그들이 하지 않아도 되도록 간단하게 만든다.나는 그것을 유지하는 것에 전적으로 찬성한다. Benefit:small / cost:zero. --barneca (토크) 17:22, 2007년 7월 31일 (UTC)[응답]

나는 중복이 좋은 것이라는 너의 의견에 반대한다."좋은 것은 짧을 때 두 배나 좋다." - 그라시안많은 위키피디아 기사들은 그러한 중복으로 지나치게 과장되어 있다.디켄 17:37, 2007년 7월 31일 (UTC)[응답]

다른 사람들 모두, 그냥 이 일을 끝내라.한 해가 옳아도 사람이 몇 살인지 말해주는 간단한 편리함에는 비록 중복되고 이론적으로 모욕적일 수 있지만, 완벽히 괜찮고, 어떤 사람에게는 유용하며, 머무르는 것이 있다.사용자 읽기:디켄의 사용자 페이지, 그는 고민이 많을 것이고 우리는 그의 발언을 너무 심각하게 받아들이지 말아야 한다.자, 내가 말했다.레이와스92^Talk 18:13, 2007년 7월 31일 (UTC)[응답]

이것은 개인적인 차원으로 끌어내려서는 안 되며, 이것은 나에 대한 당신의 두 번째 무례한 게시물이라는 것을 알아두어도 좋다.

소여, 내가 위키백과에 전반적으로 만족하지 않는다고 해서 내가 어떤 유효한 제안/공헌을 제공할 수 없다는 것을 의미하지는 않는다.반대를 허용하지 않는다면 어떻게 진전을 기대할 수 있겠는가?디켄 18:28, 2007년 7월 31일 (UTC)[응답]

미안하지만, 네 말뜻을 알겠어. 처음엔 반대만 했었지만 말이야.어떤 사람들은 단순히 사람의 나이를 읽는 것이, 특히 수학보다는 스캔만 할 때, 꽤 도움이 된다고 생각한다.그것은 확실히 누군가의 지능을 모욕하려는 의도는 아니었다.레이와스92^Talk 18:47, 2007년 7월 31일 (UTC)[응답]

특히 생년월일이 상식이라면 나이를 표시하는 것이 어떻게 문제가 될 수 있는지 모르겠다.그것은 또한, 어떤 사람들에게는 유용할 수도 있다.카운터가 계속 그 대상을 쫓아가면 문제가 보일 수 있었는데, 뭐, 죽어서도 그런 경우 어떻게 되는지, 아니면 사람들이 죽은 후에 '카운터'가 제거되는지는 알 수 없다.존 카터 2007년 7월 31일(UTC) 18:57(응답)

잠깐, 그럼 베토벤이 237살이 아니라는 거야?

템플릿 설명서에 따라:Infobox Person, 나는 그들이 죽은 후에 당신이 {{birthday}}로 바꾼다는 이론이 있다고 믿는다.자, 이제 우리에게 필요한 것은 {{생년월일과 나이도 함께 만들어 주는 사람으로서, 사망 시 사망자의 나이가 자동으로 표시되도록... --barneca (토크) 19:07, 2007년 7월 31일 (UTC)[응답]

만약 그 행동이 생년월일 대신 수동으로 추가되는 대신에 인포박스에 내장되었다면, 인포박스는 단순히 사망일이 제공되는 나이(또는 사망시 표시 나이)를 표시하지 않을 수 있다.일관성과 단순성 외에도, 모든 infobox의 매개변수에 대한 접근성 때문에 별도의 템플릿으로 구현하기 보다는 infobox와 통합될 경우 시대별 행동이 더 강력해질 수 있다.BigNate37_(T) 19:21, 2007년 7월 31일 (UTC)[응답]

나 또한 나이 계산이 유용하다고 생각한다.컴퓨터를 앞에 두고 있을 때 산수를 하는 것(월, 일 비교 포함!)은 개를 기르고 짖는 것과 같다.물론 살아 있는 사람들에 대한 모든 기사에서 일관되게 사용된다면 더 좋을 것이다.이를 돕기 위해, 사망일이 명시되지 않은 경우, infobox 매개변수는 (죽었는지 살았는지, 사망일을 알 수 없거나 또는 저자에게만 알 수 없는) 그 이유(정확히)그런 다음 Infobox 매개변수를 사용하여 관련 범주를 올바르게 생성할 수 있다.infobox를 원하지 않는 경우를 수용하기 위해, 템플릿에는 infobox를 숨기고 범주 및 형식화된 데이터를 생성하는 매개 변수가 있을 수 있다.--Boson 19:42, 2007년 7월 31일(UTC)[응답]

접을 수 있는 문서 발행 템플릿

분리발행형 템플리트를 하나로 병합하기 위해 {{ternissions} 템플릿이 템플리트를 작성했다.이것은 템플릿이 사용하는 스크린 공간을 줄이고 더 조직적이다.템플릿은 현재 접을 수 있지만 처음에 접을 것인지 페이지 로드에 표시할 것인지에 대해서는 의견이 일치하지 않는다.이에 대한 논의는 좀 더 많은 의견들이 수렴에 이르는데 도움이 될 것이라고 생각한다. --Android Mouse 19:20, 2007년 8월 10일 (UTC)[응답]

템플릿:잘못된 제목

나는 주로 Uncyclopedia 사용자지만, 최근의 변화들을 잘 보고 그것에 관련된 일들을 하기 때문에 여기에 왔다.나는 미디어위키에서 렌더링할 수 없는 제목을 가진 특정 기사들을 발견했다.언사이클로페디아에 있는 우리한테 해결책이 있어나는 그것을 쓰지 않았고, 내 물건에 내가 개인적으로 사용한 것 외에 어떤 이해 관계도 없다(그것이 무엇을 하는지를 보려면 클릭).아마도 당신은 이것을 당신의 고민을 해결하는 데 사용할 수 있을 것이다(참고:나는 단지 그들이 시험적인 경향이 있다는 이유만으로, 내가 스포크를 하기 전에 그곳의 포럼에서 물어볼 것이다.)건배.-Ljlego 01:26, 2007년 8월 4일 (UTC)[응답]

고마워, 하지만 난 사실 우리의 문제가 {{DISPLAYTLE:}}} —METS501 (토크) 01:34, 2007년 8월 4일 (UTC)[응답]으로 해결되었다고 생각해.

영어 위키백과는 유사한 템플릿 {{wrongtitle}}과(와) 유사한 코드가 Mediawiki에 있다.공통.js 비록 그것이 훨씬 더 보수적이긴 하지만: 같은 페이지로 연결되지 않는다면 제목이 바뀌지 않는다.(사실, 이제 우리는 아마도 그것을 없애고 디스플레이티틀을 사용할 수 있을 것이다.)Uncyclopedia에서 작동하는 방식 - 임의의 제목으로 변경하고 사용자에게 경고조차 하지 않는 방식 - 이 곳에서는 용납할 수 없을 것이다.

그런데 디스플레이틀이 언사이클로페디아에서 일한다면, {{Title}} ∴ 알렉스 스모트로프 02:25, 2007년 8월 4일 (UTC)[응답] 대신 가능하면 사용하기를 권한다.

헉! 고마워.-Ljlego 19:30, 2007년 8월 10일 (UTC)[응답]

조금 전에 {{lowercase}}}을(를) 바꿔서 디스플레이틀을 사용하지만, 다른 용도는 소프트웨어에 의해 거부된다(이전 명칭과 동일하게 위키링하는 새로운 제목만 허용하기 때문에).위키백과의 {{title} 템플릿(현재 {{wrongtitle}로 리디렉션됨)에 대한 내역은 사용자:One/Title 및 해당 Talk 페이지(사용자 정의 버전 MfD(결과 보관), 원본 템플릿 TfD(결과 사용자 편의)ais523

검색 엔진의 사용자 페이지?

위키백과로 이동:빌리지_펌프_(제안)#제안:_필수_noindex.2Fnofollow_for_User:_ns

WP:COI 재초안/리팩터

최근 WT에 대해 많은 언급이 있었다.현재 COI 가이드라인의 다루기 힘들고 말수가 적고 구조가 허술한 COI.따라서 (분명히 이해충돌에서가 아니라) 일부 이해당사자들이 더 유용한 방법으로 동일한 지침을 작성하는 더 나은 방법을 찾기 위해 모일 것을 제안하였다.가이드라인의 의미를 바꾸려는 의도가 있는 것은 아니다. 다만 가이드라인의 활용도를 높이기 위한 것이다.

위키백과 토크에서 이 재조명/대외자에 대한 논의를 초청한다.이해 충돌/재작성: 정확한 행동 계획을 취합하기 전에 참여자를 초기에 '채용'하고 재작성 목표를 논의하려는 현재의 의도와 함께.샘BC(토크) 20:27, 2007년 8월 12일 (UTC)[응답]

Autocon 확증 프로펠

이것은 더 많은 청중의 관점을 필요로 한다.부디 거기에 가서 의견을 말해 주시오.안녕, 나보 19:49, 2007년 8월 12일 (UTC)[응답]

WP 치료:자매 프로젝트를 수행하는 동안 SELEF 참조 자료

우리는 현재 WP에 의한 위키피디아 역학에 대한 언급을 피하고 있다.SELEF. Wikipitionary, WikiQuote 등과 유사한 사이드 박스를 사용함으로써 적절한 경우 그렇게 하는 방법을 만들 수 있을 것 같다.즉, Manual of style은 "Wikipedia에는 Manual of Style"이라는 사이드 박스가 있을 수 있다고 하자.이것은 {{selfref}}을(를) 대체한다.Andy Mabbett Talk to Andy Mabbett 17:21, 2007년 8월 10일 (UTC)[응답]

그러나 자매 프로젝트와 포털 사이드박스는 백과사전 관련 자료와 연결되고 있다.반면 셀프레프는 메타물질로 이어지고 있다.그들은 서로 연결되어 있지 않기 때문에 이것은 모두에게 매우 혼란스러울 것이다.

당신이 해결하고자 하는 {{selfref}}의 구체적인 문제는? --Quiddity 18:20, 2007년 8월 10일 (UTC)[응답]

템플릿의 실제 문제점에 동의함:Selfref? --TλεRαnΔα eor (tαlk) 00:27, 2007년 8월 12일 (UTC)[응답]

나는 퀴디티에 동의한다.넬슨 만델라의 인용문이나 미국 헌법의 본문과의 연결과 위키백과의 작업 방법에 관한 정보와의 연결은 큰 차이가 있다.특히 후자는 독자에게 무용지물이 될 것이다.아트로포스 05:25, 2007년 8월 14일 (UTC)[응답]

템플릿:팝업

위키백과에서 다음과 같은 논의가 있다.삭제/로그/2007년 8월 12일 템플릿:마우스가 항목 위에 있을 때 팝업이 나타날 수 있는 템플릿과 관련된 팝업.그것은 용어를 번역하는 데 사용될 수 있다.거기에서의 논쟁은 삭제 쪽으로 가고 있다. 내가 동의하는 것은 많은 무게를 가지고 있다. 각주는 덜 귀찮고 더 일반적이다.하지만, 나는 그 토론이 좀 더 넓은 토대가 되어야 한다고 생각해, 그래서 나는 여기에 너의 관심을 끌어.앞으로 핵심 사용으로 판명되거나 그냥 사라질 수도 있다. --Bduke 22:53, 2007년 8월 13일 (UTC)[응답]

ATC 비행대 정보 포함 제안

헤이 나는 누군가가 뉴질랜드 주변의 개별 항공 훈련대대에 대한 정보를 추가해야 하는지 궁금했다.나는 그들이 그것을 고마워할 것이라고 확신한다.Wes45 21:48, 2007년 8월 13일 (UTC)[응답]

고맙게 생각할 수도 있겠지만 개별 정찰병, 소년여단 기업 등과 함께 개별 항공훈련단 편대가 평소에는 눈에 띄지 않는 것이 분명하며, 1개 편대에 대한 기사를 써서는 안 된다.가장 나이가 많을 수도 있다.뉴질랜드의 항공훈련대대대에 대한 폭넓은 기사가 있는가? --Bduke 22:47, 2007년 8월 13일 (UTC)[응답]

BJAODN 제거

BJAODN은 최근 빠르게 삭제, 복구, MFD에서 벗어나고 있으며 현재 위키백과에서 DRV를 하고 있다.삭제 검토/로그/2007년 8월 14일/BJAODN이 페이지에 관심이 있는 경우 DRV에 기여하십시오.감사합니다, — xaosflux 05:39, 2007년 8월 15일 (UTC)[응답]

사진 및 라이센스 요청(방법 제안)

위키백과에서 토론:이미지 업로드#사진 및 라이센스 요청(메서드 제안)01:08, 2007년 8월 15일 (UTC)