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

MediaWiki 템플릿에서 이진 접두사 명확화

MediaWiki 템플릿 MediaWiki:searchsize, MediaWiki:size-gigabytes, MediaWiki:size-kilobytes, MediaWiki:longpageerror를 편집하여 Wikipedia:스타일 매뉴얼(날짜 및 숫자)#이진 접두사?이 메시지들은 기사가 사용하는 저장량을 가리키는 데 사용되며 디스크 저장소는 이러한 접두사가 가장 큰 혼란을 일으키는 영역이다.크림펫 (토크) 2007년 5월 4일 (UTC) 18:17[응답]

이의 제기가 없었으므로, 나는 먼저 가서 변경했다.크림펫 (대화) 04:31, 2007년 5월 7일 (UTC)[응답]

T't's revertion, revertion에 대해 나는 공식적으로 동의한다.카차롯 23:28, 2007년 5월 9일 (UTC)[응답]

나는 템플릿이 정확한 약어를 사용해야 한다고 생각한다.나는 또한 템플릿이 이진 양을 사용해야 한다고 생각해.— The Storm Surfer 01:25, 2007년 5월 14일 (UTC)[응답]

킬로바이트, 메가바이트 등은 정확하고 표준적이며 항상 그래왔듯이 2진수량을 가리킨다.—Centrx→talk • 21:03, 2007년 5월 16일 (UTC)[응답]

그것은 사실이 아니다.킬로바이트, 메가바이트 등은 표준에서 십진법으로 정의하기 때문에 이진 용량을 표현할 때 모호하고 부정확하다.그들은 항상 이진수 양을 언급하지는 않았다.모호하지 않은 사용보다는 일반적인 사용을 선호하는 경우를 제외하고(이것은 유효한 주장이지만 나는 "공통적인 사용"을 반영하는 것이 백과사전의 모호하지 않은 사용보다 더 중요하다고 생각하지 않는다) 이진 접두사가 여기에서 적절하다.WT에서도 동일한 논의가 이루어지고 있다.MOSNUM. 물론 나는 그 반전에 동의하지 않는다.새렌 22:01, 2007년 5월 16일 (UTC)[응답]

아니, 킬로바이트, 메가바이트 등은 하드웨어 판매업자들이 사람들을 오도하여 돈을 벌려고 하는 특정 상황을 제외하고는 어디에서나 1024를 의미한다."Bytes"는 SI 단위가 아니다.대다수의 독자들에게 "키비바이트"에 대해 분명한 것은 없다; 대신에 그것은 더 혼란스럽거나 오자로 간주된다.—Centrx→talk • 03:27, 2007년 5월 17일 (UTC)[응답]

여기는 이진 접두사가 적당하다고 생각해.사람들이 자신이 무엇인지 모르는 경우, 적절한 설명 기사에 위키링크를 넣으세요.KiB는 불분명한 2^10을 의미하고 KB는 전혀 같은 숫자가 아닌 2^10 또는 10^3을 의미할 수 있기 때문에 가능한 한 정확하게 하기 위해 노력해야 한다. --Cyde Weys 01:36, 2007년 5월 14일 (UTC)[응답]

단어의 오타가 아니라는 것을 이해하기 위해 전문 기술자라도 찾아봐야 할 정도로 참신하다면, 그 단어는 적절하지 않다.위키피디아는 신조어를 위한 곳이 아니며, 위키피디아는 발명된 표준을 공표하는 곳이 아니다.—Centrx→talk • 21:03, 2007년 5월 16일 (UTC)[응답]

"인벤트"?제발 IEEE 1541이야.미터법도 그냥 "발견되지 않았다"고 해서 쓰지 말아야 할까?또는 더 관련성이 높은 위키백과에서 흔히 사용하는 ISO 8601은 어떠한가?표준은 이유가 있다. --Cyde Weys 21:40, 2007년 5월 16일 (UTC)[응답]

미터법은 200년도 더 전에 발명되었고 오늘날에는 압도적으로 보편적으로 사용되고 있다.만약 이것이 1800이었다면, 우리는 미터법을 사용하지 말았어야 했다.오늘날에도 위키피디아는 기사에서 "표준" 미터법을 독점적으로 요구하지는 않는다.ISO 8601과 관련하여, 위키피디아의 모든 곳에서 기본 데이트는 '시간, 1년-월-일-시간이 아닌 1일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일-일'이라는 것이 아니라, 익명으로 되어 있는 대부분의 독자들을 방해하기 때문에, ISO 8601을 사용하는 것이 필자는 문장의 매뉴얼에 관한 설명서에 수록된일반적으로 표준과 관련하여 위키피디아는 새로운 표준을 공표하는 수단이 아니며, 특히 위키피디아가 만들어진 분야의 전문가들에게조차 받아들여지지 않는 것이 특징이다.이러한 용어를 요구하는 것은 위키피디아의 유일한 출판사가 아니다; 위키피디아가 독자들에게 너무 생소한 용어를 사용하는 것은 위키피디아의 일이 아니며, 전문가들에 의해서도 사용되지 않으며, 모든 용어는 궁극적으로 매우 기본적인 용어에 대한 해명이 반드시 포함되어야 한다; 위키피디아가 선봉자가 되는 것은 위키피디아의 사업이 아니다.다른 사람들보다 훨씬 앞서 있는 표준, 심지어 그 분야의 산업 잡지와 학술지들까지도.—Centrx→talk • 03:27, 2007년 5월 17일 (UTC)[응답]

그러나 여기서 중요한 문제는 이진법으로 SI 접두사를 사용하는 것이 모호하다는 것이다.1800년 경에 비해 더 나은 비교는 단순히 "인치"라는 용어를 사용한다면 될 것이다; 그 당시에는 영어 인치, 프랑스 인치 등이 모두 공통적으로 사용되었을 것이다.단순히 그들 모두의 "인치"라는 용어는 모호할 것이다. 특히 우리가 서로 다른 글에서 다른 인치를 사용한다면; 정확하고 모호하지 않기 위해서 우리는 우리가 어떤 단위에 대해 말하고 있는지 분명히 말할 것이다.크림펫 (대화) 04:24, 2007년 5월 17일 (UTC)[응답]

WP를 살펴보려면:MOSNUM은 "편집자는 한 스타일에서 다른 스타일로 접두사를 바꾸는 것을 자제해야 한다"고 말하고 있으며 WT를 보면 다음과 같다.MOSNUM은 해당 용어의 일반적인 다수 용어와 일치하는 KB를 작성하기로 합의했음을 알 수 있다.또한 IEEE 컴퓨터 소사이어티 스타일 가이드를 보면 KB를 사용하라고 적혀 있다.Fnagaton 22:05, 2007년 5월 18일 (UTC)[응답]

그런 합의는 없다.

Mediawiki 템플릿에서 사용할 유닛은 MoS에서 결정된 사항을 따라야 한다.여기 있는 모든 것을 다시 설명하지 마라.그것은 이미 WT에서 수억억번 논의되고 다시 발행되었다.MOSNUM. 어떤 결정을 내리든 미디어위키 메시지에도 적용될 겁니다.

WT의 여론 조사 결과에 의해 합의점이 입증되었다.MOSNUM 및 WP에 대한 후속 변경 사항:MOSNUM, 그것에 대한 의견 일치가 있다는 것을 부인하는 것은 어리석은 일이다.Fnagaton 10:55, 2007년 5월 19일 (UTC)[응답]

그리고 위키피디아에 그런 접두사의 사용에 신경을 쓰는 사람이라면 누구나 중재에 대한 관심을 표명하고 싶어할 것이다, 비록 의견을 가진 사람들이 너무 많기는 하지만, 나는 단순한 중재가 어떻게 이 문제를 해결할지는 잘 모르겠다.— 오메가트론 00:20, 2007년 5월 19일 (UTC)[응답]

아니, 스타일의 매뉴얼은 어떤 철칙이 아니며, 스타일을 크게 바꾸지 않는 것에 대한 스타일 매뉴얼의 다른 부분은 당신의 이진 접두사 실험보다 훨씬 더 적용가능하고 공감대가 넓다.—Centrx→talk • 04:48, 2007년 5월 19일 (UTC)[응답]

위키피디아는 진실성과 마찬가지로 콜버트 리포트에 보고될 때까지 키비바이트를 사용할 수 있는 더 많은 장소를 찾아야 한다. SWTPC6800 03:33, 2007년 5월 19일 (UTC)[응답]

헬프 데스크에 새 기고자의 도움말 페이지 및 편집기 지원 병합

위키백과를 합병할 것을 제안한다.새로운 기고자 도움말 페이지 및 위키백과:위키백과에 대한 편집자 지원:헬프 데스크.그 이유는 유사한 활동이 많거나 적기 때문이다.

• 세 사람 모두 헬프데스크가 가장 많이 구축돼 있지만 사용자가 위키 사용법에 대한 질문을 남길 수 있는 가능성이 있는 헬프데스크가 있다.
• 세 가지 모두 "방법" 유형의 질문을 다루고 있으며, 사실에 입각한 자료를 요청하는 사람은 누구나 참조 데스크로 향한다.
• 또한, 신규 기고자 페이지와 헬프 데스크에서도 {{helpme}과 IRC 클라이언트에 대해 언급/연계한다.

(내가 보기에) 주로 새로운 사용자를 대상으로 하는 지원을 다루는 유사한 페이지 3개를 다루는 것은 정말 의미가 없고, 3페이지가 아닌 1페이지가 있다면 아마도 위키피디아에 더 좋을 것이다.또한 다른 사용자를 도와줌으로써 기여하는 데 관심이 있는 사람들에게 더 좋을 수 있다.

또한 이는 #위키피디아-부트캠프에서 이미 일부 사용자들이 제안한 바와 같이, IRC에서 현재 #위키피디아-부트캠프를 사용하는 대신 #위키피디아-도움말과 #위키피디아-엔도움말 채널을 만드는 것을 의미한다.현재의 부트캠프 채널은 새로운 채널 중 하나로 전달될 것이다.Bjelleklang - talk Bug Me 00:30, 2007년 5월 4일 (UTC)[응답]

• BTW는 위키백과에 대한 참고사항뿐만 아니라 관련 세 페이지의 병합 태그에 이 토론을 나열했다.합병 제안.Bjelleklang - talk Bug Me 00:48, 2007년 5월 4일 (UTC)[응답]

• 5월 19일자로 추가: 지난 몇 주 동안 이 제안된 합병에 대한 찬반 양쪽에서 꽤 많은 논쟁이 있어왔고, 현재 상태로는 나는 그 중 어느 것도 합병할 수 있는 합의가 절대적으로 없다고 확신해 왔고, 그 결과 나는 이 제안을 철회하기로 결정했다.Bjelleklang - talk Bug Me 16:57, 2007년 5월 19일 (UTC)[응답]

• 나는 합병에 반대한다.강하게페이지 구분은 (내가 했던 것처럼 메인 도움말 페이지에 있는 페이지들을 다른 링크로 연결함으로써) 필요하다고 생각한다.신규 사용자: (1) 원래의 헬프 데스크의 기술 전문 용어에 의해 위협받을 수 있고, (2) 답변에 두문자어 및 약어를 극단적으로 사용하는 것을 감안할 때 이해하기 어려울 수 있는 답변을 수신하며, (3) 가장 독특한 질문으로 질문의 백로그를 읽는 사용자(특히 새로운 질문)는 거의 없다.나는 학교 선생님이 차별화된 수업을 보는 것처럼 두 페이지를 보는 것을 본다.같은 자원으로 모든 사람을 가르치는 것은 실용적이고 더 명확한 삭감일 수 있지만, 학생들은 다양한 요구와 기술을 가지고 있기 때문에 가르침은 달라져야 한다.여기에 문제가 있다면, 두 페이지를 더 차별화해서 다른 사용자들의 다양한 요구에 더 잘 대처해야 할 것 같다.스키퍼클립퍼 02:59, 2007년 5월 4일 (UTC)[응답]
• WP 병합:NCH는 이미 논의되었지만, 위키피디아가 어떻게 다음과 같은지 모르겠다.편집기 보조는 병합 가능.헬프 데스크보다 채택-a-사용자 프로그램과 더 공통점이 있으므로, 합병해야 할 경우에는 채택 프로그램과 대신 병합할 것을 제안한다. - 87.209.70.231 04:46, 2007년 5월 4일(UTC)[응답]

• 동의하지 않는다.스키퍼클립퍼(SkipperClipper)가 위에서 언급한 바와 같이, 이 세 페이지는 서로 다른 자원으로 같은 생각을 가르치는 두 선생님과 같다.게다가 프로젝트들 사이에는 다음과 같은 몇 가지 주요한 차이점이 있다.
  1. HD는 질문을 단판 Q-A 방식으로 처리한다.오래된 토론은 5일 후에 자동으로 보관된다.두 번째 후속 조치나 대응이 있을 것 같지 않다.반면 NUH와 EA는 모두 개인 후속 조치 형태로 작업한다.
  2. EA와 HD는 모든 사람을 위한 것이고 NUH는 새로운 사람들을 위한 것이다.
  3. HD와 NUH의 프로세스는 더 잘 정의되어 있는 반면 EA는 비교적 캐주얼하다.

  이러한 작업 원칙과 스타일의 차이 때문에 세 가지 프로젝트가 개별적으로 살아남아야 한다고 생각한다. --Dereck C. 04:56, 2007년 5월 4일 (UTC)[응답]

• 논평: 내가 볼 때, WP:EA는 언급된 다른 두 페이지와 전혀 다르지 않다; 요청 페이지에는 질문을 남기는 반면, 다른 사용자들은 답변을 하는 반면, 후속 조치도 같은 페이지에 유지한다.그것은 HD나 NUH와 거의 똑같다.도움을 구하는 사용자의 전문지식 수준에 대해서는 HD와 비교했을 때 EA와 큰 차이가 보이지 않는다!두 페이지 모두 새롭고 경험 없는 사용자부터 더 많은 경험과 더 진보된 질문을 가진 사용자까지 다양한 질문을 가지고 있다.

EA의 본래 취지가 기존 Q&A보다 코칭이 많았다면, 이는 Q&A에 집중하기보다는 훨씬 더 공감해야 한다.Q&A의 대안으로, NUH와 HD 모두 온라인 IRC 클라이언트와 {{helpme} 템플릿에 연결되며, 후자는 주로 사용자가 경험 많은 편집자의 도움을 직접 받기 위해 사용자 페이지에 글을 올리는 것을 목적으로 한다.EA는 그런 대안이 없고 질의응답에만 집중한다.나는 또한 경험이 부족한 사용자들의 질문과 다소 경험이 많은 사용자들의 다른 질문을 섞는 문제를 이해할 수 없다; 이것은 일반적으로 NUH에 대한 질문에 답하기 위해 요구되는 낮은 수준의 전문지식이 있지만 세 페이지 모두에서 이루어졌다.차이가 정말 작다는 것이 밝혀진다면, 세 가지 다른 것을 가지지 말고 한 가지 사업을 확장해 보는 것은 어떨까?Bjelleklang - talkBug Me 10:24, 2007년 5월 4일 (UTC)[응답]

답변: 위키백과 프로젝트 페이지가 문제를 해결할 수 있다면, 왜 IRC로 오프사이트로 가져와 일을 복잡하게 만드는가?게다가, EA는 단순히 Q&A가 아니다; 그것은 또한 사람들이 무언가를 토론하도록 한다.좀 더 복잡한 사건들을 살펴봐그냥 Q&A처럼 보이는 단순한 케이스들. --Deryck C. 14:40, 2007년 5월 4일 (UTC)[응답]

• 반대하며, 한 달 전에 실패한 (그리고 내 말은, 실패한, 오직 한 사람만을 지지하는) 합병 제안이 일어났다는 것에 주목해야 한다.EA는 별개의 프로젝트로서 잘 해오고 있어, 그냥 내버려 두자.세라핌블레이드 11:46, 2007년 5월 4일 (UTC)[응답]
• 나는 WP사이에 충분한 차이가 있다고 확신할 수 없다.NCH 및 WP:HD는 그들을 분리시키기 위한 것이지만, 합병을 막기 위해 들은 주장은 타당해 보인다.문제는 WP:NCH는 잘 알려져 있지 않다. 새로운 사용자들이 헬프 데스크를 대신 찾는 경우가 많고 NCH는 응답하는 사용자 수가 많지 않다.그래서 합병보다는 더 좋은 광고가 해결책일 수도 있다. --ais523 12:53, 2007년 5월 4일 (UTC)
• 동의하지 않음AIDS는 현재 상태 그대로 잘 작동하고 있으며, 신입 사원의 정책 방향을 파악하는데 추가적인 역할을 수행하고 있다. 그래서 그들은 AMA를 그들을 위해 위키리더로 데려가는 것이 아니라 그들이 의도한 대로 실제로 행동하도록 하기 위함이다.모레스치 14:20, 2007년 5월 4일 (UTC)[응답]
• 합병과, 그러나 아마도 새로운 기여자들의 도움 페이지의 구조 조정의 일종았는데 NCHP의 문제는 매우 음, 아마도 그것에 대해 다양한 플랜 카드와 페이지 머리 글 새로운 사용자를 위한에 몇개 더 연결--VectorPotentialTalk 14:25, 45월을 추가하도록 도와 줄 꺼야 공개하지 않고 있는 것 같아 둘 다watchlisted 계속 Disagree. 2007년(UTC)[응답하라]
• 부분적으로 동의한다 - 나는 WP의 홍보 필요성에 대한 ais523의 의견에 동의한다.NCH 페이지는 적절하지만, 중복 정도가 심각하므로 병합해야 한다.나는 그것의 존재조차 몰랐기 때문에 최근에야 그것을 감시하기 시작했는데, 그것은 교통량이 매우 적어서 고생한다.나와 적어도 한 명의 편집자는 이전의 합병 논의에서 같은 점을 제기했다.그러나 WP:EA는 통합되어서는 안 되지만, 의도된 용도를 강조하거나 제공되는 지원의 다른 특성을 반영하여 위치를 변경할 필요가 있다.나는 종종 새로운 편집자들과 특정한 질의/이슈에 대해 일대일 작업을 한다. 그리고 WP:EA는 그들의 요청에 이상적인 포럼이다.그런 만큼 제대로 홍보하고, 명쾌하게 기술하고, 위치 파악이 용이할 필요가 있다.아드리안 M. H. 16:13, 2007년 5월 4일 (UTC)[응답]

• 의견 - 또한 나는 너무 많은 합병이 바쁜 기간 동안 헬프 데스크에 과도한 부담을 줄 수 있으며, 만약 그렇게 된다면, 일부 질문들은 대답하지 않고 지나칠 것이고 질문자들은 그들의 질문을 찾기가 조금 더 어려워질 뿐이라는 것을 지적하고 싶다.아드리안 M. H. 16:17, 2007년 5월 4일 (UTC)[응답]

• 부분적으로 동의한다 - 나는 WP가 다음과 같이 생각한다.HD 및 WP:NUH는 WP:EA는 남아야 한다.WP:HD 및 WP:NUH는 동일한 설정이며 동일한 목적으로 사용된다.나는 이 두 개를 갖는 것은 불필요하다고 생각한다.만약 누군가가 쇼핑몰에 있고 도움이 필요하다면, 그들은 헬프 키오스크로 간다; 우리는 이제 새로운 쇼핑객들과 기존의 쇼핑객들을 다른 곳으로 보낸다.나는 WP가 그렇게 생각하지 않는다.EA는 단지 질문에 대답하는 것 이상을 하기 때문에 합병에 포함되어야 한다.WP:EA는 분쟁 해결을 위해 사용되며 더 개인적인 도움을 준다.요약하면, 나는 WP가 다음과 같은 것에 동의한다.HD 및 WP:NUH는 한 페이지로 통합되며(모든 새로운 사용자가 항상 도움말 페이지에 오고 난 후) WP는 다음과 같이 느낀다.EA는 자신의 페이지로 남아있다.스코티ude 17:07, 2007년 5월 4일 (UTC)[응답]
• 일부 동의 - WP:HD 및 WP:NUH는 WP:EA는 위와 같은 상태를 유지해야 한다.WP:NUH는 트래픽이 적기 때문에 우리의 절차를 간소화하기 위해 통합될 수 있다. WP:EA는 정상적으로 작동하고 있으며 합병은 WP를 오버로드할 수 있다.HD. Addhoc 23:18, 2007년 5월 4일 (UTC)[응답]

• 나는 분명히 NUH와 HD의 합병을 지지한다. EA는 본질적으로 Attract a 사용자 프로그램(또는 어쩌면 덜 "귀여운" 타이틀을 가진 동일한 것)의 불필요한 포크다.아마도 그들은 합병되어야 할 것이다.—앞서 서명되지 않은 코멘트는 존 리브스(토크 • 기여) 23:24, 2007년 5월 4일(UTC)에 의해 추가되었다.[답답하다]

• 참고: (앞에서 설명한 바와 같이) 도움말에 별도의 링크를 추가했다.목차 페이지.나는 이것이 교통량을 증가시킬 수 있다고 생각한다.만약 다른 장소들이 보증된다면, 그것은 벌금이다.스키퍼클립퍼 03:57, 2007년 5월 5일 (UTC)[응답]

신입 사원과 오래된 사원의 도움 채널이 혼동되지 않을수록 좋다.86.31.103.208 13:02, 2007년 5월 6일 (UTC)[응답]

추가 설명:HD에 비해 EA의 현재 장점 중 하나는 EA의 트래픽이 너무 높지 않기 때문에 논의가 비교적 일관되고 따라 하기 쉽다는 것이다.도움말에 대한 프로모션:내용은 좋지만, 과도한 광고가 EA 과밀화로 이어질 수 있으므로 주의하십시오. --Deryck C. 15:30, 2007년 5월 7일 (UTC)[응답]

• 반대 - 나는 다소 새로운 기여자인데, NCHP에 관한 모든 것을 읽으며, 때로는 위키백과에 관한 새로운 것들을 작은 단계로 학습한다.나도 HD를 읽으려고 노력했지만 대부분의 문제는 너무 어려웠다.새로운 위키피디아가 당신의 질문이 너무 어리석다고 두려워할 필요가 없는 안전한 장소를 갖는 것은 좋은 일이다.
  NCHP의 시작 방법을 읽어 보십시오: "Wikipedia를 편집하고 검색하는 데 도움을 받을 수 있는 장소" HD와 비교해 보십시오. "이것을 먼저 읽어 보십시오!...여기에서 질문을 하기 전에 매우 자주 묻는 질문 페이지를 확인하십시오!"어조의 차이를 알아챘어?
  안돼, 새로 온 사람들을 위해 NCHP를 지켜줘!로바 포크 13:49, 2007년 5월 8일 (UTC)[응답]

입증된 바와 같이, 새로 온 사람들은 헬프 데스크만큼 복잡하고 심각한 것을 기대하지 않는다.그들을 위해 뭔가 특별한 것을 설계해야 한다. --Deryck C. 07:17, 2007년 5월 9일 (UTC)[응답하라]

• 동의하지 않는다.만약 내가 그들 중 하나를 다른 곳에 합병하라고 말한다면, 그것은 WP일 것이다.EA, 하지만 그것조차도 실질적인 이득이 되지 않기 위해 상당한 간접비를 부담한다, 그래서 메흐.헬프 데스크와 뉴 기고자의 헬프 데스크는 서로 다른 방법론 목표를 가지고 있으므로 별도의 실체로 남아 있어야 한다.Titoxd^{(?!? - cool stuff)} 00:01, 2007년 5월 12일 (UTC)[응답]
• 부분적으로 동의하다.이것은 이름 차이의 문제다.헬프 데스크와 새 기고자의 도움말 페이지는 실제와 동일한 목적으로 사용된다.헬프 데스크의 질문 중 절반 이상이 신입 사원에서 나온다는 점을 감안하면 이 페이지는 그리 복잡하지 않다고 본다.따라서 WP:HD 및 WP:NUH는 WP:EA는 남아야 한다.PeaceNT 12:24, 2007년 5월 13일 (UTC)[응답]
• 병합, 같은 것.같은 차이."Dare to diff"는, 그들은...하지만 이제 그들은 "diff를 마주해야 한다." --CyclePat2 01:23, 2007년 5월 17일 (UTC)[응답하라]
• 의견/불합격 – 이전 의견과 투표 이후, 나는 정기적으로 NCH에 기여하고 헬프 데스크에 훨씬 덜 기여한다는 것을 알게 되었다. 이것은 부분적으로 공유되는 제한된 위키 시간 때문이기도 하지만, 또한 NCH가 그렇게 하기 위한 더 많은 시간을 가지고 더 세부적으로 들어가기에 좋은 장소라는 것을 스스로 보여 주었기 때문이다.일반적으로 질문자들은 더 많은 관심을 받고, 나와 다른 응답자들은 그들이 필요로 하는 경우 일대일 도움을 통해 요청을 추적하는 경우가 많으며, 그들은 종종 그렇게 한다.NCH는 평소 (테라토리스를 제외하고) 질문이 더 정반대로 다루어지는, 번번히 바쁜 헬프 데스크보다 신참들이 그들의 질문에 대답하고, 더 느긋하고 덜 서두르는 방법으로 대답을 얻을 수 있는 곳인 것 같다.NCH의 약점으로 볼 수 있는 것은 사실 그 강점이다.나는 점점 더 합병에 반대한다.아드리안 M. H. 21:22, 2007년 5월 17일 (UTC)[응답]
• 강력한 반대: NCH는 새로운 위키백과 사람들을 위한 것이다.헬프 데스크는 고급 위키피디아 사용자를 위한 것이다.그리고 나는 둘 사이의 차이점에 대해 Adrian M. H.와 동의해야 한다.합병은 상황을 더 악화시킬 뿐이다. 그러므로 나는 NCH가 합병되는 것을 원하지 않는다.끝. --Adam Hillman 06:14, 2007년 5월 19일 (UTC)[응답]
• 동의하지 않음 HD와 NCH는 모두 본질적으로 비대해 있다; EA는 상대적으로 관리가 가능하다.만약 내가 다른 사람들에게서 나오는 모든 서신을 헤쳐나가야 한다면, 나의 참여는 극적으로 축소될 것이다. --Aarktica 16:34, 2007년 5월 19일 (UTC)[응답하라]
• 이 제안은 이제 철회되었다. 더 이상의 논의는 우리에게 아무런 도움이 되지 않을 것이기 때문이다.참여해주신 모든 분들 덕분에 여기서 제시된 주장들이 왜 합병을 하지 말아야 하는지에 대해 실제로 어떤 이슈도 보지 못했던 (나를 배척한) 이들에게 도움이 되었으면 한다.Bjelleklang - talk Bug Me 17:12, 2007년 5월 19일 (UTC)[응답]

"템플릿:"로 변경 제안참조되지 않음"

{{비참조}}}은 현재 수천 개의 다른 기사에 사용되고 있는 하이패널 템플릿이다.나는 사람들이 적극적으로 출처를 찾도록 유도할 수도 있다고 생각되는 편집을 하기 위해 토크 페이지에서 토론을 시작하려고 노력했다.다만 광고에 해당할 수 있다는 우려와 편집의 가시성이 높아 논의를 이곳으로 끌어오자는 제안이 나왔다.

여기 나의 원래 제안이 있다.

템플릿에 세 개의 큰 검색엔진(야후, MSN, 구글)에 링크를 넣어 사람들에게 출처 검색을 시작하도록 유도할 수 있는지 궁금했다.나는 이 세 개의 검색엔진을 선택했다. 왜냐하면 그것들은 이미 위키피디아가 검색 시스템의 일부로 사용하기로 선택한 검색엔진이기 때문이다: http://en.wikipedia.org/wiki/Special:Search?search=googleblat 참조.

나는 사람들이 내가 무엇을 실행하기 전에 무슨 뜻인지 알 수 있도록 제안서를 작성했다.템플릿:참조되지 않음/제안

템플릿은 기본적으로 검색어로 검색 엔진에 기사 이름을 연결한다.유용한 결과를 가져오거나 적어도 사용된 검색어를 구체화하기 위한 시작점을 나타낼 수 있음...

나는 템플릿 토크 페이지에 토의를 올리기보다는 여기서 토론하는 것을 추천한다.댓글 기대하고 있어.GDallimore (Talk) 13:07, 2007년 5월 2일 (UTC)[응답하라]

신중하게 말을 한다면, 이것은 유용한 변화일 것이다.하지만 광고를 피하려면 매우 신중하게 말을 해야 할 것이다.어떤 종류의 언어를 생각하고 있었니?~ ONUnicorn^{(Talk Contribs)} 문제 해결 2007년 5월 2일 (UTC)[응답]

오, 네가 제안한 문구에 대한 링크를 봤어.나는 그 언어는 신경 쓰지 않는다 - 그것은 광고처럼 들리고 인터넷 소스만 필요한 것처럼 보이게 만든다."넌 도와줄 수 있어!"라는 대사를 따라 뭔가 더 하는 게 어때?구글, 야후, MSN 등이 좋은 출발점이 될 수 있다고 말했다.그래도 난 그게 좀 멋지다고 생각해.~ ONUnicorn^{(Talk Contribs)} 문제 해결 18:03, 2007년 5월 2일 (UTC)[응답]

나는 그것을 좋아하지 않는다.그것은 잘못된 메시지를 보낸다 - 인터넷 공급원은 독점적으로 사용되어서는 안 되며, 실제로 일반적으로 다소 신뢰할 수 없다.니힐트레스^(t.c.s) 18:22, 2007년 5월 2일 (UTC)[응답하라]

템플릿을 생성하여 http://www.worldcat.org/을 검색한 후 템플릿에 추가할 수 있음:인터넷 검색 엔진과 함께 참조되지 않음. --Iamunnknown 18:29, 2007년 5월 2일(UTC)[응답]

대부분의 독자들은 일반 검색엔진을 사용하는 방법을 알고 있기 때문에 이 검색엔진과 연결하는 것은 별로 도움이 되지 않는다.구글 뉴스나 구글 스콜라처럼 친숙하지 않을 수 있는 좀 더 구체적인 것들은 신뢰할 수 있는 출처를 찾는데 훨씬 더 유용해야 한다.현재 위키피디아를 연결하는 템플리트:WikiProject 팩트 및 참조 확인.하나의 특정한 위키프로젝트를 연결하는 대신에, 위키백과 같은 다른 페이지와의 편리한 연결을 참조하는 중앙 페이지가 있어야 한다.신문과 잡지가 서비스와 위키피디아 요청:Wiki프로젝트 리소스 교환.–폼테 19:53, 2007년 5월 2일 (UTC)[응답]

나는 사실 구글 스콜라지가 신문의 전문이 아닌 추상적인 내용만 얻게 되기 때문에 그렇게 도움이 될 것이라고는 생각하지 않는다.그러나 나는 잠재적인 출처를 찾는 데 사용될 수 있는 자원을 지적하고, 어쩌면 위키백과 같은 자료들을 인용하는 방법을 알아내는 데 도움을 줄 수 있는 자원을 지적하는 것이 좋다.인용 템플릿).우리는 템플릿이 너무 복잡해지는 것을 원하지 않는다.출처를 찾고 그 페이지로 연결되는 데 도움이 되는 링크 한 장을 함께 만들어야 할 것 같다.그것은 "빅3" 검색엔진, 구글 스콜라, 그리고 미국 만성화와 같은 좀 더 구체적인 것들과 인용 템플릿과 같은 내부 링크에 연결될 수 있다.그러나, 그렇게 하면 포스터의 원래 아이디어의 유용성이 없어질 것이다. 그것은 클릭이 자동으로 관련 검색 결과를 가져올 수 있는 방식으로 링크를 포맷하는 것이었다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 2007년 5월 2일 (UTC)[응답]

나는 템플릿의 문구를 몇 번 수정했다.이것은 최종적인 것으로 의도된 것이 아니라, 단지 문구를 부드럽게 하기 위한 첫 번째 시도일 뿐이다.아마도 네 번째 링크가 제안되고 있는 다른 자원 목록에 추가될 수 있을 것이다.GDallimore (Talk) 21:47, 2007년 5월 2일 (UTC)[응답하라]

{{NonReferenced/Proposal}}}에 대해 생각하고 몇 가지 더 수정했다.현재 위키백과 검색 화면과 정확히 같은 표현을 사용하고 있으며, 다른 자원을 제안하는 기사에 연결할 수 있는 가능한 방법을 포함하고 있다.그 기사는 맨 위에 "당신의 지역 도서관" 같은 것을 포함해야 한다.:) GDallimore (Talk) 21:59, 2007년 5월 2일 (UTC)[응답하라]

나에게 구글, MSN 또는 야후!에서 "기사 제목 검색"은 그 검색이 사건과는 거리가 먼 신뢰할 수 있는 출처를 찾는 결과를 가져올 것임을 암시한다.만약 편집자가 믿을 만한 출처가 무엇인지 안다면 그들은 그것을 어디서 찾아야 하는지 알게 될 것이다.만약 그들이 알지 못한다면 그들을 믿을 수 없는 수백만의 근원으로 지목할 이유가 없다.지프데이 (토크) 02:54, 2007년 5월 3일 (UTC)[응답]

템플릿에는 신뢰할 수 있는 출처가 무엇인지 설명하는 링크가 이미 포함되어 있다.만약 사람들이 신뢰할 수 없는 출처를 찾으면, 그것들은 제거될 것이고, 그것이 위키피디아가 작동하는 방식이지만, 적어도 사람들이 찾기 시작하도록 자극할 것이다.GDallimore (Talk) 08:57, 2007년 5월 3일 (UTC)[응답하라]

오늘의 특집 기사인 윌리엄 모나한(William Monhan.그 안에 있는 거의 모든 참고문헌은 인터넷 참고문헌으로, 보스턴 글로브와 다른 믿을 만한 출처가 온라인 기사와 함께 있다.인터넷은 비교적 최근의 일, 사람, 사건에 관한 기사에 있어서 귀중한 것이므로 제인 운터마이어 여사와 그녀의 유별나게 큰 고양이에 관한 기사를 게재한 것이 보스턴 글로브인지 뉴욕 타임즈인지 알 수 있도록 검색 엔진에 대한 링크를 포함시키는 것은 쓸데없는 일이 아니다.GDallimore (Talk) 09:59, 2007년 5월 3일 (UTC)[응답하라]

현명하지 못한인터넷 공급원은 믿을 수 없다고 악명 높다.또한, 이것은 온라인 소스가 오프라인 소스보다 더 중요하며(대개 그 반대는 사실이며), 기사를 출처화하기 위해 인터넷을 사용하는 것만으로도 충분하다는 메시지를 전달한다.86.31.103.208 12:59, 2007년 5월 6일(UTC)[응답]

마지막 코멘트에 다소 동의하지 않는다.평판이 좋은 출처(신문 기사, 학자적 문서)의 인터넷 기록은 가능하면 항상 온라인에 있어야 한다.책을 참고로 하는 것은 매우 좋지만, 모든 위키피디아 사람들의 99.9퍼센트(그리고 심지어 그 기사를 보는 모든 위키피디아 사람들의 99%)는 그 책을 긍정할 것 같지 않다.온라인 출처는 확인하기 어려운 다른 참고 문헌에 추가할 수 있는 좋은 방법이다.

원래의 제안과 관련하여, 아마도 의견은 다음과 같다: 직접적인 연계를 제공하지 말 것, 그러나 위키피디아의 주요 검색 도움말 페이지로 연결하는 아이디어는 좋은 것이다.템플릿을 너무 복잡하게 만들지 마.매드맥스독 10:14, 2007년 5월 7일 (UTC)[응답]

나는 이것이 사람들이 출처가 없는 기사에 나쁜 출처(특히 위키백과 거울!)를 더하는 결과를 가져올 것이라고 생각한다. 그러면 참조되지 않은 템플릿이 제거될 것이고, 기사를 식별할 수 있는 방법은 없을 것이다.— 128.119.127.137 21:17, 2007년 5월 11일 (UTC)[응답]

끔찍한 생각이야.우리는 사람들에게 출처를 찾는 방법을 말할 필요가 없다.검색엔진 링크 중 하나를 보고 "오 와우! 전에는 이런 생각을 해본 적이 없어!"라고 생각한다면, 위키피디아를 편집하고 싶은 타입이 아니다. ---- RockMFR 19:18, 2007년 5월 13일 (UTC)[응답하라]

{{find}}, {{search}} 템플릿이 있지만 토크 페이지에 더 잘 배치되어 있는 것을 제안한다.Addhoc 12:21, 2007년 5월 19일 (UTC)[응답]

전기 반스타상

내가 보기엔 아마도 가장 큰 프로젝트들 중 하나인 위키프로젝트 전기에는 아직 프로젝트 특유의 헛별이 없는 것 같다.다른 것이 없다면, 그러한 프로젝트를 계속 진행하는데 필요한 작업량은 적어도 그런 상이 받을 수 있는 잠재력을 내게는 부여할 가치가 있는 것으로 보인다.불행히도, 이미지를 만드는 것은 고사하고 올바른 키를 치는 데 어려움을 겪고 있는 나는 아마도 그것을 만들려고 노력하는 가장 좋은 사람은 아닐 것이다.그러나 여기서 분명한 접근 방식을 취하면 다음과 같은 파일:크리스탈 퍼스널.png가 헛간 별의 중앙 위에 겹쳐질 수 있을까?존 카터 18:25, 2007년 5월 19일 (UTC)[응답]

이미지 방법:전기 스타.png look?2007년 5월 19일 Mr.Z-망토크 18:48 (UTC)[응답]

프러포즈에서 존속까지 23분?!?나는 깜짝 놀랐고 반응 속도에 매우 감사하며, 멋져 보인다고 생각한다.이 문제가 승인되기 위해 어떤 추가 조치를 취해야 하는지 아는 사람이 있는가?존 카터 18:57, 2007년 5월 19일 (UTC)[응답]

(나는 더 좋은 할 일이 없었다) 나는 지금 그것에 대한 프로젝트 토크 페이지에 메시지를 남기고 있다.오래된 헛별 승인 페이지는 최근에 역사학으로 표시되어 있어서 이제 프로젝트는 이미지로 무엇을 해야 할지 결정하기만 하면 된다.대부분은 사용자 대화 페이지에서 쉽게 변위될 수 있도록 템플릿에 넣는다.2007년 5월 19일(UTC) 19:04(Mr.Z-Mantalk¢)[응답]

개별 만화책 페이지

만화책의 개별적인 이슈를 논하는 페이지가 필요한지 모르겠다.나 자신의 개인적인 참고로, 나는 많은 만화책의 요약을 만들었고, 그것들을 게재하는 것을 고려하고 있었다.만화 시리즈 페이지, 즉.탐정 코믹스, 존재하지만 개별적인 이슈 페이지, 즉.27번 형사님, 그러지 마십시오.이것들은 수배된 것인가, 아닌가? --TheCoolestDude 16:11, 2007년 5월 7일 (UTC)[응답하라]

아마 불통일 거야위키백과에 물어봐:위키프로젝트 코믹스는 그러한 기사로 이전에 일어났던 일을 예로 드래곤볼 Z: 1권을 들 수 있다.너무 길지 않는 한 개별 요약을 주요 기사에 결합하는 것이 좋을 것이다.–Pomte 21:54, 2007년 5월 11일 (UTC)[응답]

나는 개별 TV 에피소드나 가상의 등장인물에 대한 기사가 의심스럽다. WP:내가 일반적으로 지지하는 PROFIC; 그리고 이것은 그것들보다 덜 바람직해 보인다.(특정 이슈가 매우 높은 금액에 팔렸거나, 다른 이슈들과 매우 달랐고, 상당한 주류 언론 보도들이 있었기 때문에) 어떤 특수한 상황을 제외하고는 이것은 좋지 않은 생각이라고 생각할 것이다.하지만 보통 나는 왜 그 시리즈에 대한 기사에서 언급이 충분하지 않은지 모르겠다.보다 상세한 취재를 할 수 있는 다른 위키도 있다.DES 22:02, 2007년 5월 11일 (UTC)[응답하라]

<탐정 코믹스 27>에 요약본과 판매가격으로 한 페이지를 시작하는 것은 위키피디아에 귀중한 부가물이 될 것이라고 생각하지만, 만화책의 대다수가 개별적으로 눈에 띄지 않고, 따라서 아마 추가되어서는 안 될 것이라고 생각한다. -할로 19:52, 2007년 5월 13일 (UTC)[응답]

개별적인 책에 관한 한, 나는 그것을 해 보라고 말했어!나는 "알 수 없는 문제" 섹션이나 비슷한 것을 시리즈 페이지에 만들 것을 제안하고, 요약이 바람직한 문제들에 대한 링크를 가지고 있다.그냥 내 2센트짜리지만, 뭔가 가치가 있었으면 좋겠어!타일러프메인 17:55, 2007년 5월 17일 (UTC)[응답]

IIRC, 위키피디아의 공신력 정책에 따르면, 어떤 출판물이 일정 수 이상의 복사본을 발행한다면, 그것은 주목할 만하다.그래서, 만약 만화책이 5천 부 이상 배포된다면, 그것은 주목할 만하다.그리고 그것이 주목할만하다면, 위키피디아에 자리를 잡고 있다.트랜스휴머니스트 20:18, 2007년 5월 19일 (UTC)[응답]

지원되지 않는 문자

이봐, 여기 새 사용자야.

알파벳의 숫자와 문자(라틴어 또는 기타)가 데이터베이스에 포함되어 있다.예를 들어 키워드에 대한 검색 결과(아마도 키 문자라고 할 수 있을 것이다!) 'D'가 있는 반면 ':'와 ';;'와 같은 문자는 지원되지 않으며 아무런 결과도 없다.왜 그걸 바꾸지 않는거지?특정 접두사로 시작하는 페이지에 대한 링크가 있지만, 문장 부호를 위해 사용된 문자 ':'에 대한 정보를 누군가가 실제로 원한다면?

하나의 구글 ':'가 어떤 결과도 없어 다소 놀랬지만, 구글 '구글'이 한 구글이 '구글 기호'를 붙이면 96만 7천 건(물론 첫 번째 구글은 위키백과 기사)이 된다.

토론하다제안이나 의견이 있으십니까?— Obsshedlinkfan (대화 • 기여) 18:13, 2007년 5월 20일 이전에 추가된 서명되지 않은 논평

꼭 그렇게 쉽게 바꿀 수 있는 것은 아니다.검색 상자에 콜론을 허용하려면 연결 방법에 대한 중대한 기술적 변화가 필요하며, 이는 '::'를 검색하지 못하는 것보다 훨씬 더 많은 문제를 일으킬 것이다. -아마코프 무! 18:20, 2007년 5월 20일 (UTC)[응답]

Copyvio의 계단식 보호

{{copyvio}}}}은(는) 관리자가 문제를 해결할 때까지 복사vio 템플릿이 있는 모든 페이지는 편집하지 말라고 하기 때문에 관리자만 편집할 수 있도록 계단식 보호된 페이지에 넣어야 하는가? --R 기여 (양키스로 가자!) 2007년_@ 21:30, 5월 20일(UTC)

계단식 보호는 다른 방식으로 작동하므로, 템플릿이 계단식 보호로 보호되면 템플릿 페이지로 넘어간 페이지만 보호된다.

또한 이것이 가능하다 하더라도, {{copyvio}}}}}을(를) 맨 위에 올려놓기만 하면 누구나 자신이 느끼는 어떤 페이지라도 보호하며 다닐 수 있다는 뜻이기 때문에, 여전히 실행되어서는 안 된다.트라(토크) 21:40, 2007년 5월 20일 (UTC)[응답]

템플릿 보호는 아무 도움도 안 된다는 거 알아.템플릿은 계단식 보호 페이지에 두라고 했어. --RContribs^Parlate_@ (Let's go Yankees!) 00:03, 2007년 5월 21일 (UTC)[응답]

미안해, 내가 오해했나 봐.템플리트를 계단식 보호 페이지에 배치하면 템플리트 자체를 계단식 보호와 동일한 효과를 볼 수 있다.템플리트는 편집에서 잠겼지만, 그것을 초월한 다른 페이지는 영향을 받지 않을 것이다.

저작권 문제가 있는 페이지 자체가 추가되는 템플리트 외에 개별적으로 계단식 보호된다는 것을 제안하는 것이 아니라면.만약 그렇다면, 보호가 폭포화 될 필요는 없을 것이다. 단지 정상적인 보호만으로도 충분할 것이다.트라 (토크) 00:22, 2007년 5월 21일 (UTC)[응답]

정리하기: 템플릿 A가 B페이지에서 변환된 경우, 계단식 보호 페이지 B는 템플릿 A를 보호하지만, 계단식 보호 템플릿 A는 페이지 B의 보호 상태에 아무런 영향을 주지 않는다. (즉, Tra가 말한 것). --ais523 10:05, 2007년 5월 21일 (UTC)

반달리즘 경고 템플릿 구문

감시대상에 페이지수를 늘리면서 반달리즘을 더 자주 보고 되돌리고, 따라서 경고 템플릿을 더 자주 사용하고 있다.하지만 나는 가끔 경고에 내 서명을 추가하는 것을 잊어서, 하게르만봇이 돌아가지 않으면 오히려 이상하게 보이게 한다.경고 템플릿의 코딩에 ~~~~~를 추가하는 것이 효과가 있을까?2007년 5월 17일(UTC) 15시 45분(Nyttend 15시 45분)[응답하라]

효과가 있을 수도 있지만, 그 다음엔 경고가 두 번 반복될 수도 있어.또한 일부 사용자는 4틸드 약어로 서명하지 않고 대신 스크립트를 사용하거나, 복사하여 붙여넣거나, 수동으로 입력하는 경우도 있음을 명심하십시오. --ais523 15:50, 2007년 5월 17일(UTC)

분명히 많은 사용자들이 템플릿 안에 서명이 포함된 것을 반대했다.위키피디아 토크에서 질문하십시오.위키프로젝트 사용자 경고:특정 과거 토론에 대한 경고.–폼테 03:58, 2007년 5월 21일 (UTC)[응답]

포켓몬 기사에 관한 합병 제안

WP와 같은 사물의 존재로서:포켓몬 및 위키백과:포케프로살은 비록 많은 포켓몬들이 지금보다 훨씬 더 많은 정보를 결코 얻을 수 없을지라도 493개의 모든 개인 포켓몬들이 그들 자신의 기사를 가지고 있다는 사실에 약간의 저항이 있었다고 증명할 수 있다.수개월에 걸친 논의 끝에 관련 프로젝트의 많은 구성원(WP:PUC)는 많은 기사를 병합하는 방법에 동의했다.분할 토론을 방지하기 위해 모든 위키백과 전문가를 초청하여 WP에서 제안된 가이드라인을 검토하고 의견을 개진한다.POCK/레이아웃.-ζαπερααπρρρ 17:49, 2007년 5월 21일 (UTC)[응답]

중요한 대화 페이지 토론 제안으로 색인 작성

3년 전 500명의 사람들이 이미 이 문제를 철저히 논의했다는 것을 나중에 발견하기 위해 가이드라인, 정책 또는 위키백과 과정에 대해 어떤 생각을 가지고 있었던 적이 있는가?그곳에서 일어난 것으로 기억되는 토론을 찾기 위해 기록 보관소를 뒤지는 짜증나는 지루함에 좌절해 본 적이 있는가?

글쎄, 내 해결책은 간단해.위키백과를 만들자:중요한 역사적 논쟁(또는 어떤 이름이 더 좋든)에 대해 색인하십시오.주제와 설명에 따라 정리된 알파벳 목록이 될 것이다.예시 항목은 다음과 같다.

• 기본 페이지 - 무료가 아닌 이미지 켜짐, [링크 여기로 이동], 레이아웃[추가 링크], 콘텐츠 선택, [추가 링크]

이 지수는 처음에는 매우 불완전하겠지만, 전형적인 위키백과 패션에서는 특히 위키백과가 계속 발전하고 사람들이 오래된 토론을 잊어버리기 시작하면서, 나는 그것이 성장하고 매우 유용하게 될 것으로 기대한다.그것은 또한 (우리 모두가 친숙한) 문제를 해결할 수 있을 것이다. 많은 이슈에 대한 토론을 위한 정해진 토론 페이지가 없고, 위키백과 네임스페이스 전체에 토론이 펼쳐져 있다.사람들은 이것에 대해 어떻게 생각하는가?다른 제안은 없으세요?nadav 11:14, 2007년 5월 18일 (UTC)[응답하라]

좋은 생각인 것 같지만 프로젝트 토크 페이지에서 실행하는 게 좋을 것 같아.만약 내가 역사적인 AfD 토론을 찾고 있다면, 아마도 WT:AFD 먼저.하청 {chat} 20:51, 2007년 5월 18일 (UTC)[응답]

응, 대신 할 수 있어.어쨌든, 이것은 많은 일을 필요로 할 것이다.위키프로젝트 토론 지수(Wiki Project 토론 지수)는 이를 위해 공식적인 위키백과 제목을 작성하는 것이 가장 좋을 수 있다고 말한다.

이 지표가 필요하다는 추가적인 증거로서, 나는 방금 라디언이 그녀의 무한한 지혜 속에서 이미 오래 전에 이것을 생각하고 위키피디아를 만들었다는 것을 발견했다.중앙 집중식_토론/컨설팅.봐, 이제 지수에 좀 더 일찍 접근해서 이 문제에 대한 논의를 체크하고 바퀴를 다시 발명하지 않았으면 좋았을 텐데! 나다브 11:25, 2007년 5월 19일 (UTC)[응답하라]

• 왜 고마워!네가 찾는 건 정말 CAT:G인 것 같아.많은 중요한 토론이 지침으로 보존되고 있다(적어도 실질적인 결과가 있었다면).>래디안트< 13:42, 2007년 5월 21일 (UTC)[응답]

AIC Hazzard 2; 요청

AIC는 사용자들이 새로운 기사를 게시하기 위해 가는 것을 의미하기 때문에 다른 위키피디아의 사용자들이 기사 제작에 도움을 줄 수 있다.나는 그 기사에 대한 몇 가지 요청이 있다.

1- AIC에 게시된 기사에 대한 보호 커버. 기사들이 불완전하거나 다른 사람들이 따를 수 있는 구조보다 더 이상 아무것도 없어야 하며, 그렇지 않으면 다른 사람의 도움을 필요로 하지 않지만, 이렇게 되면 선택 태그가 나타날 수 있다.따라서 편향에 대한 보호 커버가 필요할 수 있다.

사람들이 AIC에 대해 알아낼 수 있도록 2- 복수의 링크.AIC는 사람들이 새로운 기사를 올릴 필요가 있고, AIC는 새로운 기사를 돕기 위해 반드시 위키피디아를 가지고 있어야 한다.

3- AIC는 {건설 조항}에 이름만 입력하면 찾을 수 있지만, AIC, AC를 비롯한 사람들이 찾을 수 있는 다른 이름들이 매우 도움이 될 것이다.

이러한 요청은 이 기사의 미래에 매우 중요하다.— Nikro가 추가한 사전 서명되지 않은 논평 (토크 • 기여) 2007년 5월 22일

아마도 그 제목이 있는 No 페이지의 옵션으로 AIC로의 항법편이 제공되어야 할 것이다. -- 보라카이 빌 01:27, 2007년 5월 22일 (UTC)[응답]

내부 기사 참조 자료

여보세요

나는 너의 기사가 다른 기사를 참조할 수 있다는 것을 알아챘다.그러나 다른 기사들은 참조 기사를 언급하지 않는다.

예를 들면.국민참여전략소송(SLAPP)에 관한 기사(http://en.wikipedia.org/wiki/SLAPP)는 오프라 윈프리 페이지(http://en.wikipedia.org/wiki/Oprah_Winfrey),를 참조하지만, 오프라 윈프리 페이지는 SLAPP 기사에서 참조되고 있다는 어떤 징후도 제공하지 않는다.

나는 규범을 연결하는 두 가지 방법을 만드는 지원서를 작성했다.하지만 위키피디아는 그것을 지원하지 않는 것 같다.

그냥 제안이다.

쿠르트 크리스텐슨

커트... 툴박스 패널에서 "What links here"를 클릭하면 당신이 있는 것을 참조하는 모든 기사가 표시된다.블루보어 2007년 5월 21일 (UTC) 19:35 [응답]

위키백과에서 잘못된 문법/말을 제거하기 위한 비공식 캠페인 시작

사람들이 위키피디아에서 자주 쓰는 문법과 철자 오류에 대해 가끔 자진해서 삭제하도록 하는 것은 좋은 생각일지도 모른다.예를 들어, 나는 단지 "포트레이"가 의미되었을 때 몇 페이지의 "프로트레이" 철자 실수를 고쳤다(아직 몇 페이지 남았어).나는 사람들이 몇 가지 일반적인 문법/오류 문제를 감시하기 위해 등록할 수 있는 장소를 상상한다.만약 각 2~3명이 자발적으로 제안된 각각의 실수를 감시한다면, 위키피디아의 질은 급격히 향상될 것이다.나는 사람이나 봇이 이미 많은 흔한 실수를 고쳐야 한다는 것을 알아챘지만, 분명히 검색된 적이 없는 오타를 찾는 것은 그리 어렵지 않다.사용자 상자는 자원봉사자를 식별하고 동일한 작업의 다른 사람을 찾기 위해 만들어질 수 있다.그들은 "이 사용자는 '포트레이'의 철자가 정확한지 확인한다" 등의 말을 할 수 있다.나는 한동안 문법/언어 지놈이었는데 내가 고친 페이지들 중 많은 수가 편집간 몇 달씩 이어지는 낮은 방문 페이지라는 것을 알게 되었다.방문 페이지가 높을수록 사람들이 그들의 철자를 자주 확인하게 된다.글로벌 스펠링 수정은 그렇지 않으면 오랫동안 남아있을 오타를 수정하는 경향이 있다.나는 "전형"을 맹목적으로 고치는 문제들에 대해 알고 있다. 그래서 나는 한 사람이 각각의 철자/문법 수정을 감시해야 한다고 생각한다.내 생각은 그것의 조직화된 버전이다.아마 다른 사람이 실행하도록 놔둘 겁니다.제이슨 퀸 03:02, 2007년 5월 15일 (UTC)[응답]

AutoWikiBrowser가 이 문제를 해결해 줄 수 있다.–폼테 03:08, 2007년 5월 15일 (UTC)[응답]

고마워. (빨리 했어!)나는 내 생각과 기능이 비슷한 것이 이미 존재하는지 궁금했다.제이슨 퀸 03:11, 2007년 5월 15일 (UTC)[응답]

공교롭게도 일전에 검색창에 "occurence"를 입력했는데, 위키피디아는 12만2808개의 놀라운 히트를 보고한다.그것은 엄청난 양의 작업이다.나는 이 모든 것을 고칠 수 있는 자동화된 방법이 있는지 궁금했다.문제는 '오큐렌스'가 맞는 경우(예: 문자 그대로 인용, 아마도 'sic'으로, 또는 오자가 논의되고 있는 경우)가 극히 적을 수 있다는 점이다.그 프로그램은 이것들을 식별할 수 있을 만큼 충분히 영리해야 할 것이다.Matt 11:15, 2007년 5월 15일 (UTC)

사실, 추가 조사 결과 이 수치는 틀린 것 같다.나는 위키피디아의 검색이 어떤 이유에서인지 또한 "curs"와 다른 합법적인 변종의 예를 들기도 한다고 생각한다.Matt 11:33, 2007년 5월 15일 (UTC)

우리 검색창도 엉망이라서 그래.^demon^{[omg plz]} 03:39, 2007년 5월 22일 (UTC)[응답하라]

자동 맞춤법 수정 프로그램은 잘못된 긍정의 위험이 너무 높기 때문에 허용되지 않는다.수동 지원 철자 수정 문제(즉, 각 'occurence'에 대해 인간에게 수정 여부를 묻는 문제)가 허용되며, 그 중 몇 가지가 사용되고 있다고 생각한다. --ais523 11:28, 2007년 5월 15일(UTC)

위키백과에도 관심이 있을 수 있다.타이포, 당신이 제안한 것과 다소 비슷하게 행동하는 부서. --ais523 17:11, 2007년 5월 15일 (UTC)

완전 자동화가 잘못된 한 가지 이유는 잘못된 정보가 인용문일 수 있기 때문이다.인용문에서 철자나 문법을 수정하는 것은 절대적으로 잘못될 것이다(인용이 부정확하지 않는 한, 출처를 자세히 읽어야 하는 것).(그러나 [sic]을 추가하는 것은 좋은 일일 수 있다.토크 페이지와 사용자 페이지에서는 그것은 틀렸을 것이다.08:35, 2007년 5월 16일 (UTC)

삭제됨

나의 두 기사인 AIC와 과학신앙은 나도 모르게 흥미진진했다.AIC는 한 번 치료받았지만, 기사를 삭제하려는 포포칼은 실패했고, AIC는 경찰에게 불리한 내용이 없었고, 그와 유사한 프로젝트/기사도 없었다.AIC의 위협이 중단되어 신속한 삭제를 실시하고 있으며, Scientific Brosures는 AIC에 있어 미완성이라는 뜻에서 아직 작업이 진행 중이며, 작업이 완료되기 전에 빠른 삭제를 했다.이에 대해 조치를 취하십시오. 가능하다면, 주로 AIC인 내 기사를 다시 가져오십시오. 그것은 어떤 식으로든 정책에 불복하는 것이 아니었습니다! — Nikro가 추가한 서명되지 않은 논평(대화 • 기여)

과학신앙은 과학으로 옮겨졌다.당신이 만든 기사를 보면 - [1] - 이 기사는 프라임 타임에 딱히 준비되지 않은 것 같다.기사 영역의 어떤 것이든 독자가 그것을 본다면 그것을 기사의 윤곽으로만 보지 않고 백과사전적 품질의 것으로 볼 수 있도록 해야 한다.또한, 독창적인 연구에 대한 우리의 정책을 보라.위키피디아는 당신 자신의 견해나 해석을 위한 장소가 아니다 - 기사의 아이디어는 신뢰할 수 있는 출처에 귀속될 필요가 있다.AIC에 대해서는 위에서 논의한 것으로 보인다.자기주조적인 주제나 "메타" 주제는 기사공간에서 제외된다.기사 작성이나 프로젝트 조정 주제에 대한 지침은 모두 위키피디아: 스페이스. --BigDT 13:31, 2007년 5월 22일 (UTC)[응답]

편집자가 실제로 과학 이론 목록과 같은 목록을 시작하고 싶어했던 것처럼 보인다.비록 많은 WP가 있었지만:원문 & 독해설명 인쇄("꼭 그렇게 해야 하는 경우가 아니라면 구조를 바꾸지 말라")는 WP가 아니었을 흥미로운 프로젝트일 수 있다.아니면. 개인적으로 그런 리스트를 만드는 것은 전혀 불가능한 작업이라고 보겠지만 다른 사람이 한번 해 보고 싶다면 백과사전적인 기사를 만들 수도 있을 것 같다.지달리모어 (토크) 13:40, 2007년 5월 22일 (UTC)[응답하라]

니크로...나는 위에서 언급했지만, 여기서 다시 언급할 것이다.기사에 대한 아이디어가 있으며 "완전하지 않은" 상태에서 삭제되지 않도록 "보호"하려면(즉, 아직 작업 중인 경우) 사용자 페이지에 첨부된 하위 페이지를 작성한 후 해당 문서에서 작업하십시오.완성됐다고 생각되면 메인 기사 공간으로 옮길 수 있다.또한, 일단 기사가 메인 스페이스에 놓이게 되면, 그것을 "나의" 기사라고 부르는 것은 부적절하다는 점에 유의하십시오...우리 모두의 것이야블루보아르 14:45, 2007년 5월 22일 (UTC)[응답]

위키백과 영상

안녕, 모두들. 누군가는 전에 이런 생각을 해 본 적이 있지만 위키피디아는 난자 부화나 다른 지진 종류와 같은 교육적인 주제에 대한 짧은 비디오를 가지고 있는 건 어때?만약 우리가 이렇게 한다면 그것은 마이크로소프트 엔카르타와 비교가 될 것이다.물론, 비현실적인 것들을 업로드하거나, 누가 정확한 비디오를 업로드할 수 있는 능력을 가져야 하는지를 알아내는 것과 같은 문제들이 있을 것이다. 하지만 만약 우리가 지나쳐 간다면, 그것이 실제로 어떻게 일어나는지를 보는 사람들과 단순히 읽는 것 보다는 보는 것으로 배우는 사람들을 위한 훨씬 더 좋은 백과사전이 될 것이다!위키.user 2007년 5월 21일(UTC) 19:47[응답]

당신은 메타위키에 관한 비디오 정책에 관심이 있을 것이다.니힐트레스^(t.c.s) 20:42, 2007년 5월 21일 (UTC)[응답하라]

동영상 업로드가 허용되고 권장된다.그래도 오그 테오라를 사용해야 해.Night Gyr (talk/Oy) 23:30, 2007년 5월 22일 (UTC)[응답하라]

위키 오토메이션.작성자 정의 변수를 사용하여 다른 페이지에서 소스 페이지의 사실을 자동으로 업데이트하십시오.

이것은 내가 위키피디아에 보낸 이메일이었다.나는 위키피디아가 어떻게 코드로 작동하는지 모르지만, 나는 다음과 같은 도움을 줄 수 있는 아이디어를 가지고 있었다.

오프라 윈프리 위키(Oprah Winfrey wiki)를 읽으면서 "흑인이 미국 인구의 12%에 달하지만 윈프리는 1995년 이후 거의 매년 미국의 400대 부호 중 1위를 차지할 정도로 부유한 유일한 흑인"이라고 읽었다.

나는 즉시 그 통계에 의문을 제기했고, 아마도 "12%"가 미국 인구 조사 위키에 의해 자동으로 업데이트되어야 한다는 생각을 갖게 되었다.

미국 인구 조사 위키에서 변수를 저자에 의해 정의하고 다른 위키에서 사용할 수 있다.그러므로 미국 인구조사 위키에서 당신은 전체 미국 시민과 전체 흑인 미국 시민을 위한 변수를 가지고 있다고 하자.오프라 윈프리 위키 작가들은 그들의 위키에 있는 변수들을 사용하여 자동으로 퍼센트를 얻을 수 있다.그렇게 해서 미국 인구 조사 위키도 업데이트되면 오프라 윈프리도 자동으로 업데이트된다.

이것은 좋지 않은 예일 수도 있지만, 그 아이디어는 많은 시간을 절약하고 더 많은 위키에 정확성을 가져다 줄 것이다.

진심으로 다니엘 매튜스"

내 우려는 데이터의 대규모 반출이 공공 기물 파괴를 크게 촉진할 것이라는 것이다. 즉, 하나의 변수를 변경하고 동시에 많은 페이지를 파괴할 수 있다는 것이다.위키피디아의 많은 중요한 템플릿에 대한 해결책은 그것들을 보호하는 것이었다. 예를 들어 {{!}}}}, 저명한 메타테엠플레이트.이와 유사한 시스템에서 그러한 숫자를 보호하는 것은 위키의 개방성을 약화시킬 수 있는데, 이것은 중요한 문제인데, 자유로운 편집은 다섯 가지 기둥 중 하나이다.니힐트레스^(t.c.s) 03:42, 2007년 5월 21일 (UTC)[응답]

그러나 이런 종류의 전폐는 어쨌든 가끔 행해진다. --ais523 10:08, 2007년 5월 21일 (UTC)

만약 당신의 글이 많은 곳에서 쉽게 연대를 할 수 있는 통계를 포함하고 있다면, 당신은 그것을 잘못하고 있는 것이다.그것은 그녀의 재산과 흑인 인구수 둘 다에 특정한 시점을 붙여서 표현하는 것이 더 나을 것이다.Night Gyr (talk/Oy) 2007년 5월 21일 (UTC) 14:53[응답]

그것은 사실이지만, 현재 상황을 디스하고 있는 기사는 전혀 언급하지 않는다.-ζαπερααπρρρ 18 18:08, 2007년 5월 21일 (UTC)[응답]

현재 상황에 대해 논의할 때, 당신은 여전히 날짜를 제시한다.오늘 데이트처럼.그런 다음 필요에 따라 업데이트할 수 있다.카차롯 01:54, 2007년 5월 23일 (UTC)[응답]

새로운 금화 용어

'정치적으로 옳다' '환경적으로 옳다' 등 세계 어휘에 진입한 용어 전통에 새로운 용어를 정립하고 싶다.이 용어는 탄소 배출을 줄이거나 상쇄하려는 노력과 의욕이 종종 많은 경쟁 변수와 함께 복잡한 문제라는 것을 암시하는 데 사용되는 "탄소 정확"이다.아니면 이런 상쇄가 탄소배출량을 줄이기 위한 대체 수단보다 효과적이거나 효율적이거나 선호되는지를 모른 채 탄소배출기를 구매했기 때문에 죄책감 없이 SUV를 운전할 수 있다는 이들의 주장을 폄하하는 데 이 용어를 비꼬아 사용할 수도 있다.

스카르만50에 의해 제출됨

이 페이지는 위키피디아와 관련된 제안을 위한 것이지 삶에 대한 일반적인 제안이 아니다.그러나, 나는 일반적으로 당신이 말하는 것과 같은 것들을 "친환경적" 또는 "친환경적"이라고 지칭한다고 생각한다. —METS501 (토크) 00:34, 2007년 5월 22일 (UTC)[응답]

위키피디아는 용어에 대한 새로운 용어나 사용법을 제정하는 곳이 아니다.탄소가 정확하다는 말을 우리 중 많은 이들이 좋아한다고 해도, 그것은 신학일 것이다......의 신조어.위키백과에서는 신어를 사용해서는 안 된다.우리가 여기서 그것을 사용하기 전에, 당신은 그것이 위키피디아를 넘어 세계에서 널리 사용되었다는 것을 증명할 필요가 있을 것이다.블루보어 14:33, 2007년 5월 22일 (UTC)[응답]

나는 이곳이 당신이 언어의 새로운 용어를 만들기에 적합한 장소라고 생각하지 않는다.Jmlk17 20:22, 2007년 5월 23일 (UTC)[응답]

미국, 영국 등의 사자성어 템플릿

영국 대 미국 철자 등에 대해 많은 논쟁이 있었던 것으로 보인다.이 토론을 최소화하기 위한 제안은 다음과 같다.

1. {{iioms American=color British=color}와 같은 템플릿 만들기
2. 사용자가 자신의 Monobook.js 파일을 기반으로 볼 버전을 제어할 수 있도록 허용
3. 새 계정이 생성되면 다음 시스템 중 하나를 사용하여 기본값을 설정하십시오.
   1. IP 블록이 결정되는 국가
   2. 미국식 영어를 기본값으로 설정하십시오. 'pedia' 사용자 사이에서 더 일반적일 수 있기 때문이다.
4. 예제 1, 하나의 현재 솔루션:색상(또는 색상, 철자 차이 참조)은 적색, 황색, 백색 등으로 불리는 범주에 해당하는 시각적 지각 특성이다.
5. 사용법은 다음과 같다: {{iiioms American=Color British=Colour}}는 시각적 지각 특성...
   1. 영국 영어 사용자들은 "색깔은 시각적 지각 특성이다.."
   2. 미국 영어 사용자들은 "색깔은 시각적 감각의 특성이다.."
   3. 다른 변형을 추가할 수 있다.허용된 숙어 목록은 아마도 '속담' 숙어를 추가하는 반달족을 피하기 위해 템플릿 페이지를 통해 통제되어야 할 것이다.

안톤로조 12장 51, 2007년 5월 17일 (UTC)[응답하라]

당신이 제시한 예제에서 이렇게 하지 않는 데는 그럴만한 이유가 있다. 템플릿 보기 위해 페이지를 편집할 필요 없이 사용되는 다양한 철자를 아는 것이 유용할 수 있다.

서버들이 위키피디아 와이드 롤아웃에 필요한 엄청난 수의 템플리트 호출을 처리할 수 있을까?이것에 대한 답을 모르나.

아이디어일 수 있는 것은 기사에 있는 특정 단어의 첫 번째 예에 이 줄들을 따라 템플릿을 사용하는 것이다. 그리고 템플릿이 작동하여 만약 어떤 사람이 단어 위로 마우스를 굴리면, 다른 철자가 튀어나올 수 있다.그렇게 하면 그 아이디어로 나의 두 가지 문제를 해결할 수 있을 것이다.그래도 다른 사람이 있는지 모르겠네.GDallimore (Talk) 15:08, 2007년 5월 17일 (UTC)[응답하라]

나는 그 문제들 중 어느 것도 고려하지 않았다.모든 숙어를 표시하는 '숙어 없음' 설정은 이것이 어떻게 보일지 모르지만 선택사항이 될 수 있다.서버 부하와 관련하여, 그래픽, 테이블 등을 생성하기 보다는 템플리트가 텍스트를 대체한다는 사실은 그러한 문제를 피할 수 있을 것이다.

또한 Talk의 사용자:요거트가 방금 비슷한 템플릿 {{sp}}을(를) 알려주었다.안톤로조 15:56, 2007년 5월 17일 (UTC)[응답하라]

나는 이것이 필요하지 않다고 생각한다.철자 차이는 경미하고 누구에게도 혼동되지 않는다.만약 사람들이 그들 자신의 철자와 다른 철자를 보고 그렇게 기분이 상했다면, 그들은 그것을 극복해야 한다.영어 버전에서 다른 의미를 가진 단어들/사용되지 않은 단어들에 대해서는, 대신 동의어가 사용될 수 있다.코웨자 15:59, 2007년 5월 17일 (UTC)[응답]

{{ADCE 년도}}(으)로 나타난다.{{ADCE year}}모노북.css를 사용자 지정하지 않은 경우, 두 가지 모두 표시됨) 전혀 제대로 파악되지 않음(단 한 번의 통과만 가능하며, 사용자 공간에 있음).이것도 기대하지 않아. --ais523 16:00, 2007년 5월 17일 (UTC)

나는 개인적으로 그것이 필요하다고 생각하지 않는다.{{sp}}템플릿은 인기있는 용도가 아닌 것 같아(이전에도 접해보지 못했는데) 어쩐지 이것도 쓰일 것 같지 않다.게다가 이런 철자법은 하찮은 것에 불과하다. -- 씨엘로모빌레 23:40, 2007년 5월 17일 (UTC)[응답하라]

가능한 해결책은 이전에 제시된 전복 아이디어일 것이다.만약 사용자가 정말로 철자에 관심이 있다면, 그들은 논쟁의 여지가 있는 단어 위에 구르고, 클릭하고, 철자 선호도를 선택할 수 있고, 반복적으로 접근하는 모든 위키 페이지들은 단어의 지역 철자에 의존하지 않는 한, 그 철자를 사용할 수 있다.예를 들어 기사에서 '가을'이라는 용어를 사용했다면 대체 '가을'을 제시할 수 있었다.노래 가사, 인용문, 기타 문학 작품 등이 인용되지 않는 한, 물론 원래의 단어는 대체 언어 선호가 제공되지 않고 그대로 남아 있을 것이다.

사용자가 자신의 모노북 환경설정을 설정하지 않는 한 단어의 모양을 변경하지 않는 템플릿을 만든다면, 이것은 괜찮다.하지만 미국 철자가 기본이 되어야 한다는 어떠한 제안도 거절할 것이다.Addhoc 12:25, 2007년 5월 19일 (UTC)[응답]

나는 미국인이고, 색깔도, 어떤 것의 중심도 정말로 중요하지 않다는 것을 믿지 않는다.우리는 같은 언어를 말하니까 결국 다 좋다. :) Jmlk17 20:15 (UTC) 2007년 5월 23일 (답)

새로운 링크 형식에 대한 아이디어

링크는 현재 두 가지 형태가 될 수 있다.

• [[xxxx]] = xxxx 페이지에 대한 링크, xxxxx 표시
• [[xxxx yyyy] = xxxx 페이지에 대한 링크, yyyy를 표시한다.

그러나 링크 형식[[xxxx yyyy zzz]] = "page xxxxyyy, display xxxxzzz"가 유용할 수 있다. 예: [incinnerat ion ed]는 긴 페이지 이름을 모두 반복할 필요 없이 소각 및 표시로 연결될 수 있다.앤서니 애플야드 20:19, 2007년 5월 14일 (UTC)[응답]

나쁘지 않은 아이디어지만, 왜 소각에서 소각으로 방향을 바꾸는 것만이 아니라(현재의 경우인 것 같다)?£N마jdan•talk 20:24, 2007년 5월 14일(UTC)[응답]

일부 편집자들은 리디렉션을 사용하는 링크를 싫어하며, 모호한 페이지로 연결되는 링크처럼 링크를 변경하는 것 같다.나는 그들을 전혀 개의치 않는다. (서버 부하가 증가할 가능성이 있더라도, 나는 전문가들에게 그것을 코멘트할 것이다.)아드리안M. H. 20:41, 2007년 5월 14일 (UTC)[응답하라]

나는 비록 이 제안이 어떤 장점이 있을지 모르지만, 그것은 매우 직관적인 시스템은 아니라고 생각한다 - 나는 그것이 실제로 별로 도움이 되지 않을 것이라고 생각한다.아, 그리고 또 다른 링크 형식이 있는데, [[zzz:xxxx (yyyy) ] = 페이지 zzz:xxx (yyyyy)로 링크하고, "zzz:"가 네임스페이스인 경우 xxxxx를 표시한다.(yyyy) 또는 "zzz:"도 없이 작동한다.니힐트레스^(t.c.s) 01:57, 2007년 5월 15일 (UTC)[응답하라]

지원 - 직관적이지는 않지만 사용하기도 어렵지 않다.만약 그것이 잘 기록된다면 사람들은 그것을 잘 알고 사용할 것이다.그럴 필요가 있다. --EMS Talk 02:58, 2007년 5월 15일 (UTC)[응답]

반대하라; 나는 우리가 이 구문을 좀 더 유용한 것으로 예약해야 한다고 생각한다.그게 뭔지 정말 잘 알고 있었는데, 깜빡 잊었어.— The Storm Surfer 04:38, 2007년 5월 15일 (UTC)[응답]

반대; 리디렉션 및 [xxxx yyy] 표기법으로 이미 다루어짐.니힐트레스^(t.c.s) 20:44, 2007년 5월 15일 (UTC)[응답하라]

반대하라. 아무 의미도 없다.^High_InBC^{(Need help? Ask me)} 2007년 5월 15일 (UTC) 22:43[응답]

반대하라. 스톰 서퍼와 같은, 비록 깔끔할지라도.미안해~에드보이^[c] 02:01, 2007년 5월 16일 (UTC)[응답]

반대하라; 이것은 몇 개의 키 스트로크를 절약하고, 그 과정에서 새로운 편집자들이 그것을 발견했을 때 이해하는 방법을 배우는 것을 여전히 자극하는 것을 제공한다.소수의 이익은 그 비용의 가치가 없어 보인다. (일반적으로, 복잡성의 추가 문제는 충분하지 않다고 간주된다.)Notinasnaid 08:39, 2007년 5월 16일 (UTC)[응답]

반대; 나는 [thi]s나 [even (이)]와 같은 링크도 좋아하지 않는다.나는 키 몇 자루와 시각적인 잡동사니들을 어느 날이나 일관되고 배우기 쉬운 하나의 규칙 구문과 교환하곤 했다.Dcoetzee 13:33, 2007년 5월 18일 (UTC)[응답]

강한 반대;익숙해지려면 시간이 좀 걸릴 것이고, 정말 별 효과가 없을 때는 다른 사람들이 그것을 바꾸는 것을 좋아하지 않을 것이라고 확신한다.Jmlk17 20:13, 2007년 5월 23일 (UTC)[응답]

명명 규칙(Indic)

위키백과:명명 규칙(Indic)은 "비활성"으로 태그가 지정되어서는 안 된다.가이드라인으로서 적극적으로 연계되고 있다."적극적인 토론"이 없었기 때문에 "역사적"이라는 꼬리표가 붙었다.나는 이것이 이상하다고 생각한다. 왜냐하면 토론의 부재라는 것이 반드시 페이지가 쓸모없다는 것을 의미하지는 않기 때문이다.또한, 믿을 수 없을 정도로, 공감대가 있고 페이지가 안정되어 있다는 뜻일 수 있다.dab (𒁳) 07:01, 2007년 5월 25일 (UTC)[응답]

네 말이 맞는 것 같다.굵게 표시하고 비활성 태그를 제거하십시오!2007년 5월 25일(UTC) 예치엘만 13:50[응답]

예치엘씨 좋은 조언이십니다...대담해야만 이 프로젝트는 계속해서 성장하고 변화할 수 있다.Jmlk17 20:49, 2007년 5월 25일 (UTC)[응답]

호러 컬래버레이션의 이번 달 결과를 가져오시겠습니까?

위키백과:호러_collaboration_of_the_month는 여러 기사를 크게 개선시키고, 특집 기사들을 불러오는 데 도움이 되는 귀중한 페이지였다.나는 왜 그것이 역사적으로 만들어졌는지 내가 어떻게 알 수 있을지 잘 모르겠다 - 공포 위키 프로젝트는 여전히 그것의 메인 페이지에 그것을 활동적인 것으로 나열하고 있다.다른 위키피디아 사람들이 와서 그것이 다시 돌아올 수 있는지 없는지 말할 수 있을까?고마워 데스디노바 2007년 5월 17일 (UTC)[응답]

만약 당신이 공포 기사를 위해 협력하는 것에 관심이 있는 다른 사람들을 찾을 수 있다면, 모든 수단을 동원해서 기사를 개선하라.그 페이지는 역사적으로 기록되었다고 나는 믿는다. 왜냐하면 협업에 대한 관심이 급격히 줄어들었기 때문이다.마치 WP를 본떠서 페이지를 모델링한 것처럼 보인다.AID 모델은 상당한 양의 트래픽을 기반으로 하기 때문에 AID는 그것의 감소를 야기했을 수 있다.사람들이 기사 작업에 관심이 있는 한 나는 협업을 부활시키는 데 아무런 문제가 없다.Gracenotes^T § 03:38, 2007년 5월 18일 (UTC)[응답]

고마워!내가 뭘 할 수 있는지 알아볼게!데스디노바 10:35, 2007년 5월 18일 (UTC)[응답하라]

행운을 빈다!Jmlk17 02:51, 2007년 5월 25일 (UTC)[응답하라]

위키피디아의 불명확한 상태:신뢰할 수 있는 출처/예시

이 유용한 페이지는 부분적으로 잊혀진 것 같고, 명확한 지위가 없다. 나는 그것을 '제안'이라고 라벨을 붙였다.WP의 측면과 어떻게 관련되는지에 대한 관련 토론 페이지의 의견을 참조하십시오.ATT/FAQ-- _{Piotr Konieczny aka Prokonsul Piotrus talk} 17:32, 2007년 5월 25일 (UTC)[응답]

안정성 공지 게시판 제안

Wikipedia_talk를 참조하십시오.신뢰할 수 있는_source#신뢰성_알림판, 특정 소스의 신뢰성에 대한 논의를 위한 RfC의 일종인 새로운 게시판에 대한 제안서.-- _{Piotr Konieczny aka Prokonsul Piotrus talk} 17:24, 2007년 5월 25일(UTC)[응답]

정보의 품질을 측정하는 능력

기사의 정보의 질을 측정하는 간단한 방법, 또는 정보가 수용되는 정도를 보다 정확하게 측정하는 방법은 방문자 수에 비례하여 편집 횟수를 측정하는 것이다.기사를 보는 사람이 많을수록 정정할 기회가 많아진다는 이론이다.따라서 많은 사람이 보지만 소수의 사람이 편집한 기사는 널리 받아들여지는 정보를 담고 있다.그러나 시청자 수에 비례하여 편집이 많은 기사가 수록된 기사에는 보다 역동적이고 받아들여지지 않는 정보가 수록되어 있다.좀 더 정적인 기사가 더 정확할 것으로 예상된다.

이 조치들은 일정 기간 동안 제약을 받을 필요가 있을 것이다.예를 들어, 시청자와 편집자의 수는 지난 날, 주 또는 월의 숫자일 수 있다.기존 기사의 편집 빈도를 분석해 보면 기사의 전체 수명을 기준으로 최적의 기간을 알 수 있을 것이다.예를 들어, 한 달밖에 안 된 글의 정보의 질은 지난 2주 동안의 활동으로 측정될 수 있는 반면, 1년 된 글은 지난 한 달 동안의 활동을 기준으로 측정된다.시간대를 결정하는 데는 많은 선택사항이 있다.

결과 메트릭스는 각 글의 제목 근처에 등급(낮음, 약품, 높음, 1-5 등)으로 표시하여 사용자에게 읽고 있는 정보의 신뢰성을 나타낼 수 있다.또한 블록이 서로 독립적으로 편집되기 때문에 더 세부적인 측정을 제공하기 위해 기사의 각 독립 블록에 대해 메트릭스를 생성할 수 있다.

아쉽게도 서버 자원 때문에 페이지마다 방문자 수를 추적하지 않는다.—METS501 (대화) 00:35, 2007년 5월 22일 (UTC)[응답]

서버 로그에는 각 페이지에 대한 요청 또는 번호가 포함되어야 한다.위키피디아가 이러한 로그 파일을 사용자 정의했다면, 이 정보를 추적하는 데 많은 리소스가 필요하지 않을 것이다 - 65.196.71.3 14:57, 2007년 5월 25일(UTC)[응답]

감시 목록 범주

나는 현재 115개의 아이템을 내 워치리스트에 가지고 있다.내가 생각하기에 유용할 것이라고 생각하는 것은 항목을 라디오, TV, 위키피디아(예를 들어 이와 같은 페이지), 교육, 컴퓨터 등과 같은 범주로 분류하는 방법이 될 것이다.

카테고리를 선택하고 변경 목록이 긴 것이 아니라 페이지를 설정하기 위해 변경되었는지 확인할 수 있다.pjb007 14:27, 2007년 5월 20일 (UTC)[응답]

여기에 그것을 하는 "저기술" 방법이 있다.사용자:와 같은 대체 계정 만들기:Pjb007a, 사용자:Pjb007b 등과 같이 사용자 페이지에 기본 계정에 대한 링크를 추가하십시오(WP에 의해 허용됨:SOCK). 그런 다음 각 사용자 계정에 대해 별도의 감시 목록을 만드십시오.예치엘맨 2007년 5월 20일 (UTC) 16:16[응답]

115개만?이 설문조사는 그때 당신에게 흥미로울 것이다.아드리안M. H. 17:17, 2007년 5월 20일 (UTC)[응답하라]

그것은 흥미로운 사용자 설명 프로젝트처럼 들린다.데이터 집합을 저장하고 검색하는 방법(특히 이것이 가장 유용할 수 있는 더 큰 감시 목록 포함)을 약간 더 효율적으로 설계하는 것이 주요 PITA가 될 것 같다. -- Seed 2.0 19:58, 2007년 5월 20일 (UTC)[응답]

당신이 말하는 것과 비슷한 효과를 얻으려면 관련 변화를 이용하라.사용자 하위 페이지에 그룹별로 원하는 모든 기사에 대한 링크를 배치하고, 해당 페이지를 보고 도구 상자에서 "관련 변경사항"을 클릭하면 해당 페이지만 감시 목록에 있는 것처럼 감시 목록 유형의 페이지가 나타난다.—METS501 (talk) 21:47, 2007년 5월 20일 (UTC)[응답]

사용자 스크립트에 있는 거라면 좋은 생각인 것 같고, 워치리스트에 디폴트된 것은 아닌 것 같아.나는 네임스페이스로 분류하는 것을 선호하지만, 그렇게 해도 그것은 당신의 감시 목록에 많은 양의 기사가 있을 때만 유용할 것이다.–세비 ~ 10:09, 2007년 5월 25일 (UTC)[응답]

각주/참고/참고 숨기기

여러분 모두가 알다시피, 대부분의 기사들은 그 기사 끝에 인용문, 주석 또는 각주를 가지고 있다.그러나 스파이더맨 3나 버지니아 공대 대학살과 같은 몇몇 기사들은 방대한 목록을 가지고 있다.그들이 자리를 많이 차지하기 때문에 아마도 우리가 은신처를 사용할 수 있을 것이다.

{{hidden 시작 헤더=header}}{{ end 끝}}}}}

숨기기 위해서, 공간을 절약하기 위해서?생각일 뿐이야.— ▲ 히피 ippi » 05:27, 2007년 5월 20일 (UTC)[응답]

난 네가 혜택을 받을 거라고 생각하지 않아, 어차피 모든 내용을 다 처리한 후에야 끝에는 숨겨져 있어.스파이더맨 3에 대해 말하자면, 그 기사는 너무 많은 참고문헌을 가지고 있는데, 그 중 많은 것은 아마도 다른 합리적으로 완전한 참고문헌에서 다루어진 작은 것들을 인용하는 데 한 번만 사용된다.나는 사람들을 덜 붐비게 하기 위해 통합과 가지치기 작업을 좀 하고 싶다.Night Gyr (talk/Oy) 05:40, 2007년 5월 20일 (UTC)[응답하라]

이것은 과거에 시도된 적이 있으며, 기본적으로 숨겨져 있으면 각주가 깨진다. 예를 들어 각주를 클릭할 때 참조로 받아들여지지 않는다.크리스토퍼 파럼(토크) 2007년 5월 20일(UTC) 20:56[응답]

오... 알았어.내 (원래답지 않은) 생각이 사라진다.그래 그럼, 난 살 거야.— ▲ 히피 ippi » 2007년 5월 21일 (UTC)[응답]

나이트의 의견에 동의한다.솔직히 말해서, 나는 많은 참고 문헌 목록을 보고 난 후 공백이 많은 기사를 보고 싶다.나이트가 말했듯이 그들은 바닥에 처박혀있기 때문에 나는 그들이 숨겨져야 할 정당한 이유가 없다고 본다.–세비 ~ 09:53, 2007년 5월 25일 (UTC)[응답]

샌드박스 이름?

모두가 샌드박스의 이름을 바꾸는 것에 대해 어떻게 생각할까?지금은 샌드박스가 반달리즘밖에 얻지 못하고 있다.이 기사가 놀 곳이 아니라는 경고는 많지만 어쨌든 사람들은 그렇게 한다.Edit test area(테스트 영역 편집)라는 이름으로 작성된 기사가 없으므로 샌드박스를 Wikipedia로 이름을 바꾼 경우:테스트 영역 편집 및 메인스페이스 테스트 편집 내용을 줄일 수 있는 테스트 영역 편집을 보호된 리디렉션으로 만드십시오. --BigDT 22:58, 2007년 5월 25일(UTC)[응답]

나는 개인적으로 동의하지 않는다.샌드박스는 멋진 이름이고, 어차피 시험장이라는 뜻인 것 같은데, 누가 잡동사니를 붙여도 무슨 상관이야?그것은 어쨌든 거의 즉시 되돌아온다.Jmlk17 23:21, 2007년 5월 25일 (UTC)[응답하라]

너는 오해하고 있다.Sandbox라는 기사는 사람들이 위키피디아를 찾기 위해 그곳에 가기 때문에 공공 기물 파괴 행위를 하게 된다.샌드박스.문제는 사람들이 위키피디아에서 페이지를 파손하는 것이 아니다: 공간 - 문제는 사람들이 기사를 파괴하는 것이다. --BigDT 23:25, 2007년 5월 25일 (UTC)[응답]

그렇게 많은 공공 기물 파손은 아닌 것 같다.높아지면 반보호만 하면 된다.보통 사용하는 사람들이 계정을 만들었기 때문에 반보호가 효과가 있을 것이다. 반보호를 받은 페이지를 편집하려면 편집자가 자동확인을 받아야 하고, 내 기억이 맞다면 자동 확인은 4일이 걸린다.편집 테스트를 하는 다른 사람들은 아마도 그들이 잘못된 페이지에 있다는 것을 알고 있을 것이다. --R 기여_@ (Let's Go Yankees!) 23:56, 2007년 5월 25일 (UTC)[응답하라]

"시험 편집을 하는 경우, 위키백과를 사용하십시오:샌드박스" 또는 이와 유사함.–세비 ~ 00:05, 2007년 5월 26일 (UTC)[응답]

또한, 우리는 시험 편집자들이 잘못된 페이지에 있다는 통지를 받지 않고 기사의 시험 편집을 계속 되돌릴 수 없다.기사 상단에 있는 작은 이탤릭체로 된 메모는 충분하지 않은 것 같다.–세비 ~ 00:10, 2007년 5월 26일 (UTC)[응답]

글로벌 관점 태스크 포스를 위한 새로운 템플릿

나는 이 프로젝트의 글로벌 관점 태스크포스가 시스템 편향에 대처하기 위해 사용하고 있는 새로운 템플릿의 작성에 대해 지역사회에 알리기 위해 여기에 글을 올린다.이 템플릿은 편집자들에게 기사의 글로벌 관점을 개선하기 위해 태스크 포스가 적극적으로 노력하고 있다는 것을 알리기 위해 토크 페이지에 배치될 것이다.그런 의미에서 템플릿은 일반적으로 기사 페이지에 게재되는 기존의 정리 템플릿과 함께 작동하게 된다.나는 이곳이 이 새로운 템플릿을 발표하기에 적절한 장소인지 100% 확신할 수 없다. 그래서 나는 이 정보를 게시해야 할 다른 장소들의 제안을 환영한다.나는 또한 템플릿이나 글로벌 관점 태스크 포스에 대한 질문이나 의견을 환영한다.고마워! --Makabean 20:21, 2007년 5월 25일 (UTC)[응답]

여러 태그

나는 최근에 여러 개의 정리 태그가 있고 페이지를 많이 막히는 기사를 몇 개 보았다.여러 정리 태그를 하나의 정리 태그로 병합할 수 있는 새 템플릿에 대해 논의해 보십시오.정리 태그의 조합(예: {{unreferenced-or}, {{unreferenced-npov} 등)의 모든 가능성에 대해 조합 템플릿을 만들자고 제안하는 것은 아니지만, 이 글과 마찬가지로 {{1}}}도 아니고 {{{2}}}도 아니다. 또는 이와 유사하다.이 아이디어의 장단점을 논의하십시오.–세비 ~ 10:01, 2007년 5월 25일 (UTC)[응답]

나는 찬성하지 않는다.각각의 문제를 따로 나열해 보면 읽기가 편하고, 다른 문제를 보관하면서 하나의 태그를 제거하거나 새로운 태그를 추가하는 것이 도움이 된다고 생각한다.시각적 잡음이 우려되는 경우(그리고 그것이 타당한 문제) 템플릿에서처럼 일부 템플릿을 축소할 수 있는 방법이 있는지 궁금하다.범주화되지 않음.예치엘맨 2007년 5월 25일 (UTC) 13:48 [응답]

나도 반대야.모든 기사가 여러 개의 태그를 가질 필요는 없다.어떤 사람들은 참고인이 될 필요는 없지만 약간의 위키백과만 있으면 된다.페이지 스포츠를 여러 가지 태그로 만드는 것은 큰 걸음이고, 그렇게 하기 위해서는 완전히 엉망진창이 되어야 한다.Jmlk17 20:51, 2007년 5월 25일 (UTC)[응답하라]

TfD에서 보관하고 있던 {{기사}을(를) 참조. –Pomte 21:13, 2007년 5월 25일(UTC)[응답]

명명 규칙(Indic)

위키백과:명명 규칙(Indic)은 "비활성"으로 태그가 지정되어서는 안 된다.가이드라인으로서 적극적으로 연계되고 있다."적극적인 토론"이 없었기 때문에 "역사적"이라는 꼬리표가 붙었다.나는 이것이 이상하다고 생각한다. 왜냐하면 토론의 부재라는 것이 반드시 페이지가 쓸모없다는 것을 의미하지는 않기 때문이다.또한, 믿을 수 없을 정도로, 공감대가 있고 페이지가 안정되어 있다는 뜻일 수 있다.dab (𒁳) 07:01, 2007년 5월 25일 (UTC)[응답]

네 말이 맞는 것 같다.굵게 표시하고 비활성 태그를 제거하십시오!2007년 5월 25일(UTC) 예치엘만 13:50[응답]

예치엘씨 좋은 조언이십니다...대담해야만 이 프로젝트는 계속해서 성장하고 변화할 수 있다.Jmlk17 20:49, 2007년 5월 25일 (UTC)[응답]

다른 사용자와 최근 편집한 내용을 보다 편리하게 논의할 수 있는 방법

현재 사용자가 기사에서 최근 편집된 내용을 확인하고 토론하는 것은 그리 편리하지 않다.나는 더 많은 독자들이 최근의 기고문을 읽고 논평할 수 있도록 "독서 검토" 과정을 더 쉽게 만들 몇 가지 제안이 있다.

• 최근 편집된 내용을 찾으려면 현재 기록 페이지로 이동하여 이전 버전과 비교하십시오.이는 "지난 7일"과 "지난 30일"의 변경사항을 보여주는 직접적인 링크를 통해 촉진될 수 있다.일부 편집은 7일 후 비교에서 다시 나타나지 않도록 반달리즘으로 플래그가 표시되어야 한다.
• 토론이 필요한 편집을 발견한 후에는 현재 토크 페이지의 섹션을 시작하고 어떤 편집에 대해 말하는지 설명해야 한다.History 페이지에서 링크를 사용하면 자동으로 토론을 만들 수 있으며(또는 기존 토론으로 안내할 수 있음) 훨씬 쉬워질 수 있다.토론의 독자들은 표준화된 링크를 클릭하여 해당 편집에 대한 "전/후" 비교를 볼 수 있으므로, 모든 사람들이 자신이 토론하는 내용을 정확히 알 수 있다.
• 기사에 대한 편집을 제출할 때 사용자는 해당 토론 스레드를 작성할 수 있는 선택사항이 있어야 한다.사용자가 새로운 콘텐츠에 대해 어느 정도 개선될 수 있다고 느끼거나 논란이 될 가능성이 있는 경우 이 방법이 도움이 될 것이다.또한 글에서 원하지 않는 내용을 삭제한 후 다른 사용자에게 의견을 제시할 수 있는 기회를 주는 것이 예의일 것이다.
• 토론에 게시된 코멘트는 해당 편집을 한 사용자의 주의를 자동으로 끌어야 한다.

Mtford 02:00, 2007년 5월 27일 (UTC)[응답하라]

이미지

내가 만든 기사와 위키피디드 기사에 대한 좋은 이미지를 찾아줄 수 있는 사람이 있으면 좋겠다.기사는 다음과 같다.

내가 만든 기사 골드 코스트 아트 센터야

편집된 기사-골드 코스트 시티 미술관.

이 두 가지 기사에 모두 매우 적합하고 좋은 이미지를 찾으십시오.이 요청에 응답한 경우 내 Talk 페이지로 연락하십시오.

§→Nikro 15:29, 2007년 5월 26일 (UTC)[응답]

각 대화 페이지에 {{req사진}}을(를) 배치하거나 위키백과의 각 기사에 대한 요청을 추가하십시오.요청한 사진.아드리안M. H. 19:49, 2007년 5월 26일 (UTC)[응답하라]

행운을 빈다...또한, 아드리안이 당신에게 템플릿과 링크를 줄 만큼 친절했기 때문에, 아마도 이곳은 이미지 요청들을 찾기 위한 적절한 영역이 아니었을 것이다.Jmlk17 21:31, 2007년 5월 26일 (UTC)[응답]

이미지 크기 조정

위키백과에서 상당한 논의가 있었다.스타일 설명서#기사로부터 봇 크기 태그 제거에 관한 이미지현재 3개의 폭넓은 의견 학교가 있는 것으로 보인다.

1. 썸네일 크기는 접근성 문제(예: 시각 장애)를 가진 사용자의 선호도를 무시하기 때문에 본질적으로 악하다.디폴트 180px에서 변경하고자 하는 사람은 계정을 얻고 그에 따라 자신의 선호도를 설정해야 한다.
2. 썸네일 크기를 없애는 것은 나쁜 것이다.심지어 계정을 얻는 것을 고려하는 독자는 거의 없다(독자의 극소수만이 편집자가 되고, 상대적으로 편집자가 계정 소유자가 되는 것을 기억한다).우리는 대부분의 방문객들이 쉽게 읽을 수 있도록 이미지 크기를 조정해야 한다.이것은 종종 그것들이 180px보다 더 커야 한다는 것을 의미한다.
3. 미디어위키 180px 기본 크기가 평균 디스플레이에 비해 너무 작기 때문에 썸네일 크기는 현재 필요한 악이다.1024x768+화면(대부분 현대식 PC)에서는 180px 이미지가 우표보다 거의 낫지 않고 텍스트에 압도된다.소규모(또는 매우 큰) 이미지를 요구하는 소수의 사용자들은 쉽게 계정을 등록하도록 권장될 수 있다; 우리는 단지 시각 장애인 등을 만족시키기 위해 백과사전을 훼손해서는 안 된다. 이들 중 다수는 아마도 인터넷 사용 중에 접근성 조정을 하는 데 이미 익숙할 것이다.기본 썸네일 크기는 현대 컴퓨터의 더 큰 평균 디스플레이 크기를 반영하기 위해 220px로 증가시켜야 한다.

나는 3번과 거의 일치한다.이상적으로 두 가지 변화가 여기 있는 대부분의 사람들을 기쁘게 할 것이라는 생각이 든다.

1. 기본 이미지 크기를 약간 늘리십시오.
2. 사용자 기본 설정이 기사 이미지 크기보다 우선하도록(이미 어디에 설정이 있는가?) 홀수 예상 비율 이미지에 대한 축소 이미지 크기를 허용하고 소프트웨어를 변경하십시오.

더 많은 청중의 의견은 환영받을 것이다.건배, --YFB ¿ 23:25, 2007년 5월 22일 (UTC)[응답]

• 내 의견은 소프트웨어 솔루션이 있어야 한다는 것이다.편집자는 엄지손가락을 더 크게(맵, 세부사항이 작은 그림), 더 작게(단순도 등) 만드는 능력이 있어야 한다.사용자는 엄지손가락을 더 크게(모니터와 인터넷 연결이 좋은 경우) 또는 더 작게 볼 수 있는 선호도를 설정할 수 있는 능력이 있어야 한다.[[이미지:..]와 같은 구문을 제안하고 싶다.썸 150% ...] 여기서 크기가 사용자 기본 설정에 설정된 기본 이미지 크기에 대한 비율로 설정된다.사용자가 기본값을 300px로 설정하면 이미지는 450px로, 사용자가 기본값을 100px로 설정하면 이미지는 150px로 표시된다.일단, 나는 고정된 크기를 사용하는 것을 추천한다. 그것이 중요하다: 이미지는 180px 이상의 크기로 또는 180px 아래의 크기로 분명하게 보여져야 한다.그렇지 않으면 기본값인 알렉스 바하레프 07:07, 2007년 5월 23일 (UTC)[reply]를 사용해야 한다.

내가 보기에 가장 좋은 해결책은 화소를 설정하기보다는 편집자가 모니터 크기에 상관없이 균일하게 이미지가 차지하는 기사 공간의 너비 비율(5% 10% 20% 등)을 설정할 수 있도록 하는 것 같다.이렇게 하면 편집자는 보기 장치에 관계없이 일정하게 페이지 레이아웃을 설정할 수 있다.비록 나는 기술자는 아니지만, 그래서 이것이 유료인지 아닌지 전혀 모른다.G-Man * 2007년 5월 23일 (UTC)[응답]

네, CSS로 가능하십니다.그런데 동적 페이지 레이아웃은 결코 진정으로 일관성이 있을 수 없다.아드리안M. H. 20:52, 2007년 5월 23일 (UTC)분명히 하자면: 픽셀 이외의 것을 받아들이려면 위키 이미지 구문의 변화가 필요할 것이다. 그것은 다른 어떤 측정으로도 주위의 div를 존중하지 못한다.[답답하다]

나는 백분율의 개념을 좋아한다.정말 바꾸기가 얼마나 어려울지 궁금하다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 2007년 5월 25일 (UTC)[응답]

나는 알렉스 바하레프의 아이디어와 비슷한 기능을 이미 실행한 것에 대해 언급할 가치가 있다고 생각한다(바로 며칠 전).[[이미지:...엄지손가락 직립 ...]은 엄지손가락 폭의 75%로 엄지손가락을 표시하며, 이것은 비정상적으로 높은 영상에 사용되어야 한다.이 요인은 변경될 수 있다(예: [[이미지:...]).엄지손가락 직립=0.6 ...]은 60%를 사용하며 폭은 10의 가장 가까운 배수로 반올림한다.(이것이 en 어디에 기록되어 있는지는 잘 모르겠다.아직 WP--찾을 수 없었다.) --다페테か 22:33, 2007년 5월 26일 (UTC)[응답]

교차 범주

두 범주를 상호 참조할 수 있는 쉬운 방법을 아는 사람?나는 생화학 관련 정리가 필요한 모든 기사를 찾고 있어.게다가 물론 실제 범주를 대충 훑어보는 것도 그렇다.Someguy1221 00:15, 2007년 5월 22일 (UTC)[응답]

예, 이 기능은 AutoWikiBrowser에서 "List comparer"로 사용할 수 있다.—METS501 (대화) 00:31, 2007년 5월 22일 (UTC)[응답]

카테고리 교차로(Category Intersection)는 생성될 서버 로드를 관리하는 방법을 누군가 파악할 수 있는 경우 실제로 구현될 수 있는 지속적인 기능 요청이다. -- ☑ SamuelWantman 23:08, 2007년 5월 26일(UTC)[응답]

위키에 있는 모든 기사에 대해 카운터를 방문하십시오.

나는 히트 카운터가 많은 장점을 가지고 있다고 생각한다.

1. 기사의 '인기'의 척도가 될 수 있다.
2. 기사의 인기가 있다는 것을 알면 기고자에게 더 많은 일을 하도록 동기를 부여한다.
3. 다수가 접속할 경우, '신뢰할 수 있는 콘텐츠'의 척도가 될 수 있다.
4. 너무 많은 사람들이 그의 글을 읽었기 때문에 저자에게 보상으로 작용한다.
5. 그리고 이 빠른 게시물에는 지금 당장 생각할 수 없는 많은 것들이 더 있다.

나는 그것이 위키에게 적합한지 모르지만 예를 들어 'planetMath'는 그것을 가지고 있다.
또한 기사가 자주 다르기 때문에 '메인 페이지'에는 히트 카운터가 적합하지 않을 것이다.
단지 다른 것을 추가하기 위해, 시간 진화를 평가하기 위해 각 기사에 대한 히트 카운터를 매년 하나씩 사용할 수 있다.에디irdaw 14:20, 2007년 5월 17일 (UTC)[답답하다]

이것은 위키피디아에서 발생할 수 있는 서버 부하 때문에 가능하지 않다.Special의 몇 가지 측면에 관심이 있을 수 있다.통계. --내블리스 14:27, 2007년 5월 17일 (UTC)[응답]

근데 이거 있잖아.£N마jdan•talk 14:28, 2007년 5월 17일 (UTC)[응답]

게다가, 만약 그것이 모든 기사에서 보인다면, 반달들이 가장 인기 있는 페이지 또는 가장 적게 본 페이지 중 하나를 노출을 목표로 하는 것이 더 쉬워질 것이다.나쁜 생각이야.하지만 당신의 요점에 답하기 위해:

1. 그것은 대회가 아니다.
2. 나는 주류 기사나 인기 있는 기사들에 집중하고 싶지 않다.정반대다.
3. 나는 매우 많은 "내" 창작물들이 (흔히 꽤 불명확한) 교통량이 많은지는 의문이지만, 그것들은 여전히 믿을만하다.100% 희망한다.
4. 1번과 2번과 같은 대답이다.영광 때문에 그런 건 아니에요.

아드리안 M. H. 21:04, 2007년 5월 17일 (UTC)[응답]

나는 그것이 너무 많은 사용자들에게 인기 경연대회나 허영심 문제가 될 것이라고 생각한다.Jmlk17 20:14, 2007년 5월 23일 (UTC)[응답]

서버 로그에 필요한 데이터가 이미 있지 않은가?그렇지 않다면, 이 자료를 추적하는 것은 많은 자원을 요구하지 않을 것이고 위키피디아에 대한 주요 비판을 다룰 것이다.

그리고 업데이트를 조회수(뷰)의 비율로 측정하면 인기 경연대회는 피할 수 있고 신뢰도 측정도 제공할 수 있다.기사의 신뢰성 측정에 대한 내용은 아래 게시물을 참조하십시오.

나도 네 말에 동의해, 위키도 이 제안을 받아들여야 해.좋은 생각이에요.

SunnyIndia 09:35, 2007년 5월 26일 (UTC)[응답]

강한 반대다.꽤 많은 이유들 때문에:

1. 위키피디아는 백과사전이고, 백과사전적인 내용은 인기로 판단할 수도 없고 평가해서는 안 된다.
2. 린다 러브레이스가 언제나 <노인과 바다>보다 더 많은 히트를 기록하게 되는 것은 당연하다(여기서 최신 영화와 인간 장기가 거의 어떤 피처링된 콘텐츠보다 훨씬 더 많은 히트를 기록한다는 것을 확인하라).
3. 정확성이나 진정성이 인간의 허영심과 잘 유통된 행동 패턴보다 더 많은 히트를 칠 이유가 없다.
4. 이것은 실제로 위키피디아를 홍보할 것이다.위키프로젝트 포르노 위키백과:위키프로젝트 체계적 편향에 대처하는 것은 매우 강하게 (일반적인 빅맥이 10억 중국인들보다 더 각인되는 것으로 대략 해석된다, 단지 중국인들이 평균적인 미국인들보다 훨씬 덜 영어를 방문한다는 이유만으로)
5. 마이스페이스가 BBC보다 훨씬 더 인기가 많은 세상에서, 어떻게 우리는 "인기"가 "신뢰성"의 척도라고 생각할 수 있을까?(히틀러는 선거에서 승리했을 때 매우 인기가 있었지만, 믿을 만한 인물이었습니까?)
6. 1차 비판론자인 위키피디아를 다루는 대신에, 백과사전을 인기 퍼레이드로 바꿀 수 있는 가능성으로, 그것은 비판을 깊게 악화시킬 것이다.
7. 그리고 물론 위에서 이미 언급된 모든 이유들 때문에

아주, 아주 나쁜 생각이야.2007년 5월 26일(UTC) 아 디트카 까비르 20:18[응답]

영국/영어

내 생각에 영어와 영어는 과목에 따라 두 가지 다른 것 같아.영어법과 영어는 별개고 쉽게 구별되는 두 가지 사항이다.나는 아마도 많은 위키피디아 예들 중 하나로 소환 기사는 여기에 괄호 안에 붙여진 것을 인용한다(영국의 관습법에서 소환장이 출처를 가지고 있으며, 현재는 영미 공동법계 전반에 걸쳐 거의 보편적으로 적용하여 사용되고 있다).그러나 잉글랜드와 웨일스의 민사소송의 경우 라틴어 용어를 이해하기 쉬운 영어 용어를 대체하기 위한 개혁의 일환으로 증인 소환으로 용어가 대체되었다.문제의 링크는 굵게 표시된다.무경험자나 평신도에게 이것은 혼란스러울 수 있다.그러므로 나는 '영어'라는 단어가 포함된 모든 링크에 (법률, 문화 등, 그러나 명백하게 NOT 언어는 아닌) 영국을 지칭하는 (GB) 접미사를 부착할 수 있으므로, 앞에서 강조했던 링크는 '영어(GB) 공통법'을 읽을 수 있으므로, '영어'는 가능한 사기보다는 '잉글랜드에서 유래'를 의미한다는 것을 구별할 것을 제안한다.영어와 융합된, 그것은 분명히 전세계적으로 사용되고 있다.

대체적인 제안은 '미국 영어'는 '미국 영어'라는 용어로, '영국 영어'는 '영어'라는 용어로 설명해야 한다는 것이다.어느 제안도 현실적이지 않다.Addhoc 12:28, 2007년 5월 19일 (UTC)[응답]

또한, 이 일은 꽤 오랫동안 이 근처에서 이슈가 되지 않았는가?맞춤법(색상 대 색상, 중앙 대 중앙 등)까지.나는 그것이 읽기 쉽고 문법적으로 정확하다면, 그 기사가 어느 버전에 있는지는 중요하지 않다고 생각한다.Jmlk17 20:05, 2007년 5월 23일 (UTC)[응답하라]

어떻게 영어 관습법이 영어와 혼동될 수 있을까?물론, 영국과 영어는 다른 두 가지다. 하나는 영국을 가리키고 하나는 영국을 가리키는 것이다! -- 네크로테스프 14:10, 2007년 5월 27일 (UTC)[응답하라]

요약 편집

현재 요약 편집의 한계는 200단어다.아마도 그것은 300개의 단어로 확장될 수 있을 것이다.그 이유는 때때로 사람들은 더 상세한 요약을 제공하기를 원하기 때문이다; 그들은 짧은 제한 때문에 약어를 사용해야 한다.Universe=atom^{•Talk•Contributions•} 18:28, 2007년 5월 25일 (UTC)[응답]

글쎄, 난 그게 말이 아니라 캐릭터라고 믿어.레이와스92^{TalkHow's my editing?} 19:24, 2007년 5월 25일 (UTC)[응답]

아마도 250으로 확장하는 것이 순서일 것 같다.그러나 내 의견으로는 편집 요약을 위해 꽤 많은 양의 글에서 400개의 단어가 쓰여져 있다.Jmlk17 20:52, 2007년 5월 25일 (UTC)[응답]

사실, 250은 MediaWiki가 허용하는 최대 편집 요약 길이다.어떤 이유에서인지 편집 양식의 텍스트 상자는 최대 길이가 200으로 설정되어 있다.그 숫자는 소프트웨어 자체에서 자바스크립트로 쉽게 변경될 수 있다.Gracenotes^T § 03:07, 2007년 5월 26일 (UTC)[응답]

사실 현재 최대치는 단어가 아니라 200자 입니다.최소는 없다.나는 단지 최대 한도를 연장할 생각이었다.유니버스=atom^{•Talk•Contributions•} 17:55, 2007년 5월 26일 (UTC)[응답]

기술적으로 실현 가능하다면 현재보다 최대한 높게 하고 싶다(250은 255 바로 밑이기 때문에 선택한 이유가 있을 수 있다).편집-요약 상자 최대값을 늘리는 것이 도움이 될 것이다. 나는 편집 요약을 더 짧게 만들기 위해 편집 요약을 편집해야 하는 것에 진절머리가 난다.

아, 내 말은 "차르터"도 마찬가지야.다음 js 코드가 유용할 것 같아

AddOnload Hook(function() { var sumBox; if (sumBox = document.GetElementById('wpSummary') sumBox.setAtttribute("maxLength", "250"; });

Gracenotes^T § 13:03, 2007년 5월 28일 (UTC)[응답]

위키백과:신뢰할 수 있는 소스/공지판

이 페이지는 Wikipedia_talk에서 토론별로 작성되었다.신뢰할 수 있는_source#신뢰성_noticeboard.--- _{Piotr Konieczny aka Prokonsul Piotrus talk} 18:21, 2007년 5월 29일 (UTC)[응답]

바이트 수량에 대한 템플릿

현재 WP:MOSNUM은 2진수 접두사와 관련해 "기사에 대한 기존 사용법을 유지하고 1등 기고자의 선례를 따르라"면서 "2진수 접두사에 대한 괄호 사용 "예: 256KB (KiB)"를 권고한다.WP:MOSNUM이 기술한 바와 같이, "현재 위키백과 기사에서 공통의 이진 접두사 또는 IEC가 권장하는 접두사를 사용해야 하는지에 대해서는 합의가 이루어지지 않고 있다.그것은 만성적인 편집 전쟁과 장시간의 논쟁으로 이어진다.IEC 표기법의 수용은 업계와 일반 대중 모두에서 더디게 이루어졌으며, 사용법이 정착되기까지는 여전히 수십 년이 아닌 상당한 시간이 걸릴 것이라고 생각하는 것이 타당하다.

이 제안은 이 주제에 대해 토론하는 동안 제기되는 가장 일반적인 반대 의견들 중 몇 가지를 제거하려는 시도다.이것들은 특별한 순서가 아니다.

• 위키피디아는 백과사전이고 따라서 정확성과 정확한 표준 준수가 가장 중요하다.
• 위키피디아는 '해야 할 것'이 아닌 세계의 반영이다.
• 레거시 하드웨어는 일반적인 표기법을 사용하여 모든 참조 자료를 작성하므로 IEC 표기법은 혼동된다.
• 비전문가 사용자는 S를 볼 때 혼동한다.I 접두사는 예상된 의미와 다른 값으로 사용된다.

그리고 물론, 결국 많은 논쟁은 매우 강한 힘에 의해 동기부여가 된다. 바로 개인적 취향이다.

다음 템플릿:KiB 템플릿:MiB 템플릿:GiB 템플릿:TiB를 제안한다.위치변수 2개를 취한다.첫 번째는 크기 그 자체, 숫자다.두 번째는 선택적인 단위다.

예를 들어: 편집자가 선호도가 없는 경우 템플릿으로 연기할 것이며, 이는 당시의 현재 합의를 반영해야 한다.이 템팔트 버전의 현재 버전에서 다음 중 {{KiB 16} -> 16KB(KiB)

만약 편집자가 전통적인 표기법을 사용한다면, 그는 {{KiB 16KB} -> 16KB를 사용할 것이다.

몇 개의 추가 문자의 이점은 편집자가 KB가 이 문맥에서 이진 접두사라는 것을 알고 있었고, 여전히 전통적인 표기법으로 표현되어야 한다고 믿는다는 것을 다른 편집자들에게 분명히 보여준다는 것이다.

그러나 이러한 템플릿의 주요 특징은 사용자가 자신의 환경을 사용자 정의하여 자신이 가장 좋아하는 표현에서 이러한 단위를 볼 수 있도록 한다는 것이다.실제로, 사용자의 훌륭한 작업에 감사:마이크 딜런, 작은 자바스크립트 조각은 그가 좋아하는 표기법만 보고 싶은 사용자라면 누구나 사용할 수 있다.

예를 들면 다음과 같다.

var byteSuffixes = { "kib": "KiB", "mib": "MiB", "gib": "GiB", "tib": "TiB" }; importScript('사용자:Mike Dillon/Scripts/byteQuantities.js';

IEC 장치만 표시하거나

var byteSuffixes = { "kib": "KB", "mib": "MB", "gib": "GB", "tib": "TB" }; importScript('사용자:Mike Dillon/Scripts/byteQuantities.js';

전통적인 단위 전시만 할 수 있다.

예를 들어 이진 접두사처럼 글에서 감성을 유발하는 것은 템플릿 사용 텍스트에만 영향을 미치기 때문에 단위가 HAS가 한 쪽 또는 다른 쪽이어야 하는 장소에는 영향을 미치지 않는다는 점에 유의하십시오.

제안서는 다음과 같다.

• 이 템플릿이 WP에 언급되어야 한다.모스넘
• 레거시 하드웨어/소프트웨어와 관련된 페이지에서 메인 편집자는 페이지에 합의점을 표시하고 다른 편집자에게 단위의 선택이 목적적합하며 과실이 아님을 명확히 하기 위해 그것들을 사용하도록 권장한다.
• 일반적으로 편집자들은 그러한 템플릿의 사용에 저항하지 않는다. 그들의 소개가 페이지의 정상적인 모양을 바꾸지 않는 한(즉, Javascript 도우미가 없는 경우)
• Javascript에 근거한 기법의 존재를 언급하여, 그 문제에 대해 강한 의견을 가진 사용자가 자신의 선호도를 만족시킬 수 있도록 한다.

이 템플릿의 현재 형태는 이 제안서의 일부분일 필요는 없다.제안서의 일부인 템플릿의 유일한 특징은 Javascript 대체 기법을 깨끗하게 작동시키기 위해 클래스 속성을 사용하는 것이다. --Shmget 03:52, 2007년 5월 26일 (UTC)[응답]

• 별로 얻는 것도 없이 너무 복잡해 보인다.>래디안트< 12:06, 2007년 5월 29일 (UTC)[응답]

페이지 이동 방지

어제의 사진, 이미지:번역적 동작.gif는 극도로 주의를 산만하게 했다; 그것은 인지 장애를 가진 사용자들에게 문제를 일으킬 수 있다.WAI-WCAG 웹 콘텐츠 접근성 가이드라인 7.3호 "사용자 에이전트가 이동 콘텐츠를 동결할 수 있을 때까지 페이지 이동을 피하라"를 위반한 것으로 보인다.이러한 모든 이미지는 애니메이션 버전에 연결하기 위해 사전 경고와 함께 스틸 이미지 또는 텍스트를 사용해야 한다는 정책을 제안한다.(자세한 논의:위키백과 대화:오늘의 그림#애니메이션, 위키백과 대화:접근성#오늘의 애니메이션 그림) 앤디 맵베트 21:34, 2007년 5월 15일 (UTC)[응답]

나는 이것에 동의한다.나는 특별히 원하지 않는 한 페이지의 애니메이션을 좋아하지 않는다.이것은 애니메이션을 보고자 하는 사람과 보지 못하는 사람이 그것을 볼 수 있게 해준다.아마도 우리는 기사 페이지에 기본적으로 애니메이션 또는 정지 버전의 이미지가 로드되도록 사용자 설정을 할 수 있을 것이다.코웨자 21:42, 2007년 5월 15일 (UTC)[응답]

100% 네 편이야.하지만, 내가 일하는 과정에서 종종 발견하듯이, 사람들에게 접근 가능한 웹 표준의 중요성을 설득하는 것은 어려울 수 있다.아드리안M. H. 21:43, 2007년 5월 15일 (UTC)[응답하라]

나는 일반 원칙에는 동의하지만 때로는 애니메이션이 필수적이다.예를 들어, 말 탄창에 관한 기사에서는, 일련의 정지된 이미지들이 단지 주제 정의를 따르지 않는다.루핑된 vid나 애니메이션은 그와 같은 경우 페이지에서 가장 강력한 정보 제공 도구다.만약 당신이 링크를 필요로 한다면, 나는 그것이 놓칠 것이라고 장담한다.그래서 나는 그것을 정책화하는 것에 동의하지만, 그것은 전반적인 애니메이션 금지가 아니라 움직임을 피하는 것이라는 것을 분명히 할 필요가 있다.반터키 22:22, 2007년 5월 15일 (UTC)[응답]

물론 전면 금지는 나쁠 것이다, 나는 우리가 애니메이션을 볼 때 선택하기를 원한다.애니메이션을 기본적으로 표시하도록 할 수도 있고 사용자가 설정에서 무언가를 확인해야 애니메이션에 대한 링크가 있는 스틸을 볼 수 있다.우리가 애니메이션을 기본 설정으로 만들면 사람들이 그것을 놓치는 것을 막을 수 있을 거야.애니메이션이 있고 사용자가 애니메이션을 사용할 수 없는 경우 페이지 상단에 있는 막대도 사용할 수 있다.코웨자 22:35, 2007년 5월 15일 (UTC)[응답]

좋아.반터키 22:37, 2007년 5월 15일 (UTC)[응답]

사람들에게 움직이는 사진에 대해 경고하지만, 어떤 사람들은 그것을 즐기기 때문에 그것을 가지고 있고, 움직임으로 인해 발작을 일으키는 사람들은 그 움직이는 그림이 그곳에 있을 것이라는 것을 알기 때문에 볼 필요가 없다.adambar88 19:13, 2007년 5월 24일 (UTC)[응답]

나는 어떤 어플리케이션은 움직이는 이미지를 보증할 수 있다고 생각한다.이것은 편집상의 통제에 맡겨야 한다.^High_InBC^{(Need help? Ask me)} 2007년 5월 15일 22시 42분(UTC)[응답하라]

장애 사용자의 미드를 존중하는 것보다 움직이는 이미지를 보여주는 것이 더 중요한 페이지의 예를 들 수 있는가?앤디 맵베트 11:58, 2007년 5월 16일 (UTC)[응답]

2개의 이미지가 미리 로드되어 있는 JS/CSS 시스템을 만들면 애니메이션 이미지가 나타나기 전에 "재생" 이미지처럼 클릭하면 되지 않을까?나는 우리가 단지 .js Sounds를 단순하고 실행 가능한 위치에 놓을 수 있는 적절한 장소를 찾으면 된다고 생각한다.우리가 지금 가지고 있는 다른 애니메이션 GIF와 마찬가지로 여전히 가장 많은 적립금이나 물건으로 사용되어야 하지만, 위에서 언급된 몇 가지 우려를 해소할 수 있을 것이라고 생각한다. --TheDJ (대화 • 기여) 2007년 5월 16일 (UTC) 12:59, 16 (답변)

그것은 항상 이미지 전송과 대역폭 소모를 수반할 것이다.어쨌든 JS를 사용하고 있으니, DOM 조작을 사용하여 이미지를 교체하는 것이 더 말이 되겠는가? --ais523 13:03, 2007년 5월 16일(UTC)

방금 몇 가지 테스트를 해봤어.테이블 축소 스크립팅의 특별한 버전만 있으면 된다.내 테스트에 따르면 숨겨진 요소는 Safari와 Firefox에서 페이지 로딩이 아닌 필요할 때 로드된다."재생" 이미지와 "애니메이션" 이미지 사이에서 전환될 어떤 코드에서는 테이블 붕괴 코드를 비교적 쉽게 변경할 수 있을 것이라고 생각한다. --TheDJ (토크 • 기여) 13:53, 2007년 5월 16일 (UTC)[응답]

유용하지만 잠재적으로 주의를 분산시킬 수 있는 두 개의 애니메이션이 있는 GIF 페이지에서 테스트를 실행해 보십시오.효과를 볼 수 있다는 것은 사람들이 이 기능을 구현하는 것이 좋은지 여부를 가늠할 수 있게 해주고 GIF 애니메이션에 심혈을 기울이는 페이지에서 그렇게 하는 것은 더 많은 지식을 가진 사람들을 토론에 끌어들일 수 있다.GDallimore (Talk) 14:07, 2007년 5월 16일 (UTC)[응답하라]

(충돌 편집)디스플레이 사용의 다른 문제:없음 코드는 접근성 가이드라인 자체를 위반한다는 것이다. 위키백과:숨겨진 구조 참조.DOM 조작 코드를 사용하면 고대 브라우저에서 보다 우아한 방식으로 성능 저하가 가능함(예: '재생' 링크를 통해 사용자가 애니메이션 버전의 이미지 설명 페이지로 이동함). --ais523 14:09, 2007년 5월 16일(UTC)

위키백과 강연에서 요약한 바와 같이:미디어위키에는 이미 [[이미지:애니메이션.gif 엄지손가락=still frame.png].하청 {chat} 21:08, 2007년 5월 18일 (UTC)[응답]

위키백과에서 베낀 3가지 의견:접근성#오늘날의 애니메이션 그림

한 두 가지 예를 들어 문제를 분명히 해 주시겠습니까?애니메이션 이미지의 영향을 받는 장애는 무엇인가?Earth#Orbit 및 회전 및 Engine#Modern의 이미지를 제거/정적화해야 하며 경고가 추가되어야 하는가?이 사이트에 있는 다른 모든 애니메이션 이미지들은?

내가 생각할 수 있는 단 하나의 예는 정전기/전쟁을 하는 명백한 이치에 맞는 것은 스트로브 빛인데, 이것은 물론 광감응성 간질로부터 연결되어 있다.비록 그것의 작은 크기가 심지어 그 무식한 것을 만들기는 하지만.

우리는 단지 "매우 산만하다"와 "문제를 일으킬 수 있다"보다 더 많은 것을 계속할 필요가 있다.

드디어 '그날의 그림'이야, 산만함을 의미해! --Quiddity 23:22, 2007년 5월 15일 (UTC)[응답]

"우리는 단지 "매우 주의를 산만하게 한다"거나 "문제를 일으킬 수 있다"는 것 보다 더 많은 것을 계속할 필요가 있다. "정말, 그것이 내가 WCAG를 인용한 이유다.

"Earth#Orbit 및 회전과 엔진#Modern의 이미지를 제거/정전기화하여 경고가 추가되어야 하는가?" - 네.앤디 맵베트 12:04, 2007년 5월 16일 (UTC)[응답]

그들은 JAWS를 더 느리게 행동하게 만든다(모든 현대판 JAWS I가 최신판을 포함하여).JAWS 렌더링 엔진이 페이지의 변화를 보면 새로운 페이지라고 생각하고 다시 그리려고 하기 때문이다.이 기술 지원 게시판은 작성 이후 상황이 개선되었지만 약간 관련이 있다.무슨 의미인지, 나는 단지 도구 메뉴를 통해 쉽게 할 수 있는 Internet Explorer의 애니메이션을 꺼버렸고, 기사 지구에서의 부진은 사라졌다.나는 이 대화를 읽기 전에는 그런 생각을 해본 적이 없었고, JAWS 문서에서는 비플래시 애니메이션에 대해 아무것도 찾지 못했다.나는 메인 페이지에 있는 낮 섹션의 사진이 작동하는 방식이 마음에 들고, 애니메이션 이미지가 거기에 직접 전시되지 않는 한 나는 아무런 이의도 없다.다만 실제 기사에서는 정적 영상만 직접 표시해야 한다고 생각한다.Graham87 12:43, 2007년 5월 16일 (UTC)[응답]

사본의 끝

당신이 인용한 WCAG 1.0 지침은 1999년부터이며, 2.0에 대한 초안은 일반적인 애니메이션 이미지에 대한 조언의 특정 요소를 제거한 것으로 보인다.아마도 이제 모든 주요 브라우저(불꽃, IE, 오페라) 내에서 그것들을 비활성화하는 것이 실제로 가능하기 때문이다.

Strobe 문제는 WCAG 2.0 지침 #2.3 - 압류(작성 초안)에서 다룬다.그것은 정말로 정전기적이어야 한다.

그것 말고도, 나는 누가 정확히 이것에 의해 영향을 받고 있는지 확신할 수 없다.가장 유용한 콘텐츠인 quidity 18:04, 2007년 5월 16일 (UTC)[응답]을 삭제하여 누구를 도울 것인가?

WCAG 지침 v1.0은 여전히 최신이다. 버전 2.0은 더 넓은 지역사회에서 받아들여지지 않았기 때문에 다시 작성되고 있다.앤디 맵베트 21:56, 2007년 5월 16일 (UTC)[응답]

그러나 1.0 지침은 깜박이는 회전이 가능한 인터페이스, 지구와 섬광의 괴리성, 플래시 터빈의 전성기 동안에 개발되었다.그 의도의 정신은 백과사전 페이지에서 유용한 애니메이션 한 편을 삭제하는 것을 목적으로 한 것이 아니었다.

당신은 추상적인 점과 접선적인 우려에 대해 계속 논쟁하고 있고, 나는 구체적인 예를 계속 요구한다.가장 유용한 콘텐츠인 것을 제거함으로써 우리는 누구를 도울 것인가?Horse gaet#Gallop에서 이미지에 심각한 영향을 받는 단 하나의 장애가 있는가? --Quidity 01:25, 2007년 5월 17일 (UTC)[응답]

"그러나 1.0 지침은 깜빡임-회전-애니메이션 인터페이스, 지구와 섬광의 괴리성, 플래시 터빈의 전성기에 개발되었다. 그 의도는 백과사전 페이지에서 유용한 애니메이션 하나를 삭제하기 위한 것이 아니었다." - 그 주장을 뒷받침할 증거를 인용할 수 있는가, 아니면 단지 개인적인 의견을 표명하고 있는 것인가?앤디 맵베트

상식이라 부르고, 개인적인 의견이라 한다.웹은 지난 8년 동안 약간만 바뀌었다. 그것을 무시하는 것, 그리고 원래의 맥락을 무시하는 것은 어리석은 짓이다. --Quidity 19:00, 2007년 5월 22일 (UTC)[응답하라]

논쟁의 방법으로서의 상식은 논리적 오류다.그 기간 동안 움직임이나 섬광에 의해 영향을 받는 장애의 종류는 변하지 않았다.앤디 맵베트 2007년 5월 23일 12시 15분 (UTC)[응답]

"우리가 가장 유용한 내용인 것을 제거함으로써 누구를 도울 것인가?" - 밀짚맨.아무도 유용한 콘텐츠를 제거해 달라고 하지 않는다. 나는 콘텐츠가 애니메이션화 되어 WCAG 1.90 지침을 위반하는 경우, 간단하지만 분명한 경고가 선행된다. 인지 장애, 주의력 문제 또는 난독증 유형과 같은 이미지로 인해 방해를 받거나 병에 걸린 모든 사람을 돕는 것이다.나는 그 문제들에 대해 전문가가 아니지만, WCAG 1.0을 초안한 사람들은 그랬다.너는?앤디 맵베트 22:21, 2007년 5월 21일 (UTC)[응답]

뭐, 주의력 문제가 말이 되긴 하지만그러나 다른 모든 사람들을 위한 '페디아'의 효용을 줄이는 것은 엄청난 욕구를 필요로 하며, 솔직히 나는 먼저 문제를 겪고 있는 누군가의 실제적인 불평을 보고 싶다.스포일러 태그 논란과 유사하게 - 아마도 아무도 스포일러 태그의 부족에 대한 유효한 불만을 찾을 수 없었을 것이다.

독자가 애니메이션 이미지를 클릭하지 않을 가능성은 상당히 높다.반대로, 나는 애니메이션 이미지가 내가 페이지를 스크롤할 때 나의 관심을 끌기 때문에 유용하다는 것을 발견한다. 애니메이션 이미지는 종종 내가 그 부분을 읽을 수 있을 만큼 호기심을 유발하는 항목이 될 것이다.

내가 제안하는 유일한 제안은 당신이 애니메이션 이미지를 위한 적절한 정책/제도 세트로 구상하는 것을 초안하는 것이다. 그래서 우리는 당신이 원하는 것을 예시할 수 있다.그것과는 별개로, 나는 위의 하청의 답변이 그 문제를 적절히 다루고 있다고 생각한다.

위키백과의 마지막 줄:이미지 사용 정책#표시된 이미지 크기는 이미 "인라인 애니메이션을 적게 사용해야 한다"고 제안하고 있다.그것이 어떤 변화가든 일어날 수 있는 부분이고, 이 토론을 가리키는 쪽지를 그 토크 페이지에 남겨두어야 한다(또는 모든 것을 그곳으로 옮겨 놓아야 한다).--Quiddity 19:00, 2007년 5월 22일 (UTC)[응답]

그 가이드라인은 무시되거나 우회되고 있다; 아마도 "소요하게"는 족제비 단어일 것이다.앤디 맵베트 2007년 5월 23일 12시 15분 (UTC)[응답]

이미지:Ruodlicht.g 만약 내가 이 제안을 지지한다면.이미지:Dainsyng.gif Krimpet (토크) 01:56, 2007년 5월 17일 (UTC) 이미지:로들리히트(역전 타이밍).gif[응답]

움직이는 영상을 강제적으로 보는 것을 금지해야 한다.그것들은 주의를 산만하게 한다.팬암 103편 비행기의 이동 제거를 위해 산만함이 언급되기도 했다.논스톱 영상이 최악이다.직장 동료들의 주의를 분산시키거나 직장에서 위키피디아 사용에 주의를 환기시키는 것도 나쁜 일이 될 수 있다.현재 불필요한 이동 이미지를 피하기 위한 유일한 옵션은 페이지를 스크롤하거나 닫는 것이다.어느 쪽도 좋지 않다.나는 불필요한 이미지 움직임만으로 이미지를 움직이는 것을 전면적으로 금지할 이유가 없다고 본다.이 얘기를 꺼내줘서 고마워.Editore99 12:44, 2007년 5월 17일 (UTC)[응답]

직장에서 위키피디아를 로드하지 말아야 하는 사용자들은 우리의 관심사가 아니다.불필요하게 움직이는 이미지는 성적으로 노골적인 이미지보다 더 큰 관심사는 아니다. 그리고 우리는 이미 그 논의가 어떻게 진행되는지 알고 있다.발생해야 할 손해에 대한 구체적인 설명 없이, 이는 애니메이션이 보증되는지 여부에 대한 페이지별 합의가 되어야 한다.기껏해야 그러한 이유들 중 일부에 대한 가이드라인이 더 글로벌하게 적용될 수 있다(이미 한 가지, 어딘가에 있는 것 같다). --내블리스 14:33, 2007년 5월 17일 (UTC)[응답하라]

"요청되지 않은 움직이는 이미지는 성적으로 노골적인 이미지보다 더 큰 관심사는 아니다." - 나는 도덕적 분노를 유발하는 성적 노골적인 이미지에 대해 들어본 적이 있지만 간질은 결코 아니다.앤디 맵베트 09:52, 2007년 5월 18일 (UTC)[응답]

모든 움직이는 이미지가 간질을 유발한다는 증거를 보여주거나, 모든 움직이는 이미지가 나쁜 것은 아니라는 것을 인정해야 한다.--내블리스 14:41, 2007년 5월 18일 (UTC)[응답]

나는 "모든 움직이는 이미지들이 간질을 유발한다"고 주장한 적이 없다; 아니, 나는 그렇지 않다.2007년 5월 18일 (UTC) 14:52, Andy Mabbett [응답]

지구#Orbit과 회전, 엔진#모던을 정적으로 만들 필요가 있다고 생각하는 것을 보면, 그때의 기준을 좀 더 명확하게 볼 필요가 있다고 생각한다.--내블리스 15:00, 2007년 5월 18일 (UTC)[응답]

나의 "기준"은 WAI-WCAG Web Content Accessibility Guideline No 7.3: "사용자 에이전트가 이동 콘텐츠를 동결할 수 있도록 허용할 때까지, 페이지의 이동을 피할 것"을 준수하는 것이다.앤디 맵베트 15:15, 2007년 5월 18일 (UTC)[응답]

질문/설명 8개 코멘트에 대한 답변이 있으십니까(시작: "하지만 1.0 지침은..."? --Quiddity 16:57, 2007년 5월 18일 (UTC)[응답]

"업무에서 위키피디아를 로드하지 말아야 하는 사용자들은 우리의 관심사가 아니다."너는 나를 대신해서 말을 하지 않으니, 우리의 말은 적절하지 않다.Editore99 12:04, 2007년 5월 18일 (UTC)[응답]

그렇다면 다시 한 번 말하겠다: "직장에서 백과사전을 싣지 말아야 하는 사용자들의 우려를 염두에 두고 위키피디아를 편집해야 한다는 공감대는 결코 없었다."개인적으로 그런 것에 대한 고민이 있든 없든 그것은 백과사전의 목표나 정책이 아니다.--내블리스 14:41, 2007년 5월 18일 (UTC)[응답]

다시 고쳐줘서 고마워.나는 너의 요점을 이해하고 그 문제가 이전에 발생한 적이 없다는 것에 동의한다.Editore99 18:20, 2007년 5월 18일 (UTC)[응답]

나는 이 제안에 강력히 반대한다.위키피디아의 가장 강력한 특징 중 하나는 움직이는 그림을 기사에 삽입하는 능력이다.그러한 감동적인 그림들은 종종 1000단어보다 훨씬 이해하기 쉬운 원리의 설명을 만들어낸다.

오용될 수 있을까?물론이야.그리고 나는 우리가 그것을 보게 될 것이라고 확신한다.하지만 적절하게 사용되면, 그것은 우리 백과사전에서 정보의 접근성을 크게 향상시킨다.예를 들어, 우리의 호랑이 기사가 단지 몇 개의 정적인 이미지만이 아니라 호랑이가 움직이는 영상을 보여주는 날을 기대해 본다.

아틀란트 17:11, 2007년 5월 21일 (UTC)[응답]

나도 위키피디아에 호랑이 영상이 나올 날을 기대해.그러나 나는 이 페이지의 저자가 아니라 *내가 그렇게 말할 때 이 연극이 주연을 맡았으면 한다.이는 모든 사용적합성 연구의 소급적 가치가 있는 발견과 일치한다.앤디 맵베트 22:23, 2007년 5월 21일 (UTC)[응답]

위에서는 영상을 움직이거나 깜빡이는 것이 실제 문제를 일으키는지에 대한 문의가 있었다.나는 컴퓨터 이미지를 깜빡이는 것이 다른 사람에게 심각한 간질성 세지를 야기시켰을 때 이미 알고 있었다. 그리고 여러분에게 심각한 해를 입혔다고 말할 것이다.누가 원하면 자세히 설명하겠다.이제 대부분의 움직이는 이미지들은 발작을 일으킬 가능성이 가장 적지는 않지만, 그것들에 대한 어떤 정책도 다른 이유로 쉬어야 한다. 그러나 Image:status.gif와 같이 정기적으로 중요한 영역이 깜박이거나 색이 변하는 이미지는 실제로 문제를 일으킬 수 있다.DES 21:16, 2007년 5월 22일 (UTC)[응답하라]

난 여기서 무신경하게 말하고 싶진 않지만, 다음에 무슨 상상을 할까?경찰, 구급차 신호등 금지?정치적으론 결코 충분히 옳을 수 없겠지?멀미는 간질 발작보다 더 규칙적인 현상이지만 그렇다고 해서 여객기 비행을 금지하고 싶지는 않을 것이다.나는 개인적으로 음극선관에 문제가 있어서 위키피디아 세션이 끝날 때마다 눈이 심하게 아프다.나는 비슷한 문제를 가진 다른 수백만 명의 사람들이 있다고 확신한다.그렇다면 우리는 음극선관이나 위키피디아나 둘 다 금지하는 것은 무엇인가?제발, 어떤 것을 금지하는 것은 심각한 조치야, 그것을 제안하기 전에 오랫동안 그리고 열심히 생각해봐.흡연, 낙태, 타박상 농업, 안락사, 일부다처제, 종교간 결혼 등 좋은 의도로 모든 것을 금지하기 시작하는 것은 쉬운 일이다.하지만, 우리가 스트레칭을 시작할 때, 우리는 어디에서 멈출까?우리 모두가 가서 깜빡이는 이미지만큼 작은 것을 금지하기 전에, 우리는 결국 관료주의나 권위주의 정권이 될 지도 모른다. 둘 다 우리의 기본 원칙에 크게 반한다.제발, 다시 생각해봐.나는 이 토론이 발작, 움직이는 이미지나 대역폭에 관한 것이 되어서는 안 된다고 생각한다.오히려 원칙과 이념에 더 충실해야 한다.2007년 5월 23일(UTC) 아 디트카 까비르 16:13[응답]

토론의 방법으로 미끄러운 경사를 피하십시오.2007년 5월 24일 (UTC) 14:46, Andy Mabbett[응답]

그러나 그것은 당신이 의지하고 있는 논쟁의 필수적인 부분이다.간질 발작을 일으킬 만한 드문 이미지지만, 그것 때문에 (대부분의) 모든 움직임을 금지하기로 되어 있다.분명히, 불쾌한 이미지는 개별적인 기준으로 처리될 수 있다.

아틀란트 16:39, 2007년 5월 29일 (UTC)[응답]

실제 생활에서 소화를 금지하는 정부와 어떤 이미지를 사용할 것인지에 대한 정책을 채택하는 웹사이트 사이에는 차이가 있다. 위키백과의 정책을 좋아하지 않는 사람은 누구나 다른 이미지를 가진 위키백과를 자유롭게 찾을 수 있다.또한 발작과 멀미에 의한 해악 사이에는 상당한 차이가 있으며, 또한 문제를 예측하고 피하기 위한 잠재적 피해자의 위험성에도 차이가 있다. 사람들은 일반적으로 멀미를 일으킬 수 있는 차량에 언제 타려고 하는지 알고 있다.많은 국가에서 긴급 차량에 대한 점멸등 설계는 발작의 가능성을 줄이기 위해 변경되었으며, 그러한 점등에서 제공되는 긍정적 편익은 링크 뒤에 있는 것이 아니라 위키피디아에서 점멸하는 이미지를 통해 제공되는 것보다 오히려 더 높다.DES^(talk) 17:10, 2007년 5월 24일 (UTC)[응답하라]

거시경제, 형법, 역학, 공중보건 등 다양한 분야에서 꽤 인기 있는 논쟁 방식을 중단하려는 의도는 피하십시오.그리고, 제발, 만약 정책이 적절하지 않다면, 누군가에게 위키피디아를 떠나라고 충고하고 싶다면, 그들에 대한 논의를 중단하고 사람들을 지역사회에서 쫓아내기 시작하라.좋거나 싫거나 하는 정책을 논의하고, (가능성이 있는 존재하지 않는 정책이 포함된) 공감대를 형성하려고 노력한다.위키피디아의 운영 방식이 마음에 들지 않는다면, 그냥 놔두고 혼자서 Wiki 하나를 시작하면, 사람들을 쫓아낼 수 있는 자유가 있다.이제 미끄러운 비탈길을 위해, 나는 간단한 질문을 하고 싶다. - 우리는 좌우를 금지하고 엄격한 관료주의처럼 행동할까?아니면 우리는 위대한 백과사전을 위해 일하기 위해 편집자들에게 의존하는가? 그리고 사람들에게 점멸하는 이미지를 주의 깊게 사용하라고 정중하게 요청하는 시스템을 시도해 보는가?나는 두 번째 루트를 지지한다(사용하고 있던 깜박이는 이미지 하나를 이미 제거했고, 그것은 금지 정책이 필요하지 않았다).건배.2007년 5월 25일(UTC) 아 디트카 까비르 17:19[응답]

증거

• 웹페이지에 나타난 이동의 폐해를 기록한 만성피로에 관한 발표.앤디 맵베트 18:55, 2007년 5월 25일 (UTC)[응답]

• 더. 감광성 간질에 대해 위의 내용을 뒷받침하기 위해 다음과 같은 연구 결과(하딩, 그레이엄; 감광성: 전치성 메아리?),첫 번째 그레이 월터의 강의; 국제 심리학 저널, 1994, 16권, 273-279페이지:

• 4000명 중 1명은 감광성 간질을 가지고 있다.반복적으로 점멸하는 빛은 이 개인들에게 발작을 일으킬 수 있다.관심의 플래시 주파수는 5Hz ~ 70Hz이며, 대부분의 개인은 15Hz ~ 20Hz 범위에서만 취약하다.
• 깜박이는 스트로보(또는 함께 시퀀싱된 여러 스트로보의 근접 조합)는 5Hz ~ 70Hz 주파수 범위에서 깜박이도록 프로그래밍해서는 안 된다.
• 플래시 속도가 느리고, 무작위로 깜박이는 빛이 감광성 간질의 원인이 되지 않는 것으로 알려져 있다.
• 빛의 포인트 소스는 사람의 시야의 많은 부분을 덮고 있는 분산된 빛의 소스보다 발작을 유발할 가능성이 훨씬 적다.
• 발작을 유발하려면 주변부와 반대로 시야의 중심에 빛이 있어야 한다.
• 감광성 시청자와 광원 사이의 밝기를 줄이거나 거리를 늘리면 감광성 간질 발작을 예방하는 데 효과적이다.
• 멀리서 번쩍이는 불빛은, 심지어 관심의 빈도 범위에서도, 보다 자연적이거나 혼란스러운 성질의 다른 조명들이 있을 때 발작을 일으키는 것으로 알려져 있지 않다.
• 래스터 스캔 영상과 같이 광원을 일정한 패턴으로 배열하면 발작을 유도할 확률은 (최대 10배) 크게 증가한다.(DMX Multi-Strobe Brik로 달성하는 것이 텔레비전 이미지보다 훨씬 어려울 것이다.)또 다른 방법으로, 시간 대비에 공간 대비(패턴)를 추가하지 마십시오(슬릭터링.

또한 감광성 개인에서의 발작은 다음과 같은 사건에 의해 유발될 수 있다는 것은 널리 알려져 있다.

• 텔레비전 이미지 깜박임 또는 롤링
• 특정 비디오 게임
• 컴퓨터 모니터
• 서로 다른 색상의 패턴 교대

Web Content Accessibility Guideline 1.0은 위협에 대해 다음과 같은 구제책을 제안한다.

• 사용자가 깜박임을 제어할 수 있도록 허용, 화면이 깜박이지 않도록 방지
• 사용자가 깜박임을 제어하도록 허용, 콘텐츠 깜박임 방지
• 사용자가 이동 콘텐츠를 일시 중지하고 페이지 이동 방지
• 새로 고침을 중지할 수 있는 기능을 제공하고 정기적으로 자동 새로 고침 페이지를 만들지 않음
• 자동 리디렉션을 중지할 수 있는 기능을 제공하고 페이지 자동 리디렉션에 마크업을 사용하지 마십시오.대신 리디렉션을 수행하도록 서버를 구성하십시오.

간질 발작이 태양을 보고 빠르게 깜박이는 것처럼 스스로 유발될 수 있다는 증거도 있었다.전면 금지가 너무 단순한 해결책이 될 것이라는 것은 당연한 결과일 것이다.나는 우리가 영상을 이동/깜빡/깜박일 수 있는 시작 버튼을 개발하여 그러한 이미지의 코딩에 포함시킬 것을 제안한다.봇이 도움이 될 수도 있다.교육적 가치가 큰 그러한 이미지를 제공할 수 있는 사람들은 또한 "시작" 버튼을 포함하는 코드 작성에 능숙하다는 것을 우리에게 말해줄 증거가 없다.아 디트야 카비르 04:34, 2007년 5월 26일 (UTC)[응답]

• Post Script As 겉보기에는 귀엽지만 실제로는 꽤 바보같은 이미지들에 대한 Post Script As:Status.gif(바보 같은 것에 신경 쓰지 않고, 내가 직접 이미지를 사용했다)는 교육적인 가치가 전혀 없는, 그들은 언제나 갈 수 있다.이미 삭제 논쟁이 진행 중이고, 그것은 고압적인 정책/지침을 보증하지 않는다.

이미지를 애니메이션화하라는 지시가 있을 때까지 애니메이션화해서는 안 된다는 점에 절대적으로 동의하십시오.제안된 인라인 플래시 비디오 플레이어는 이를 처리할 수 있다, 아닌가? — 2007년 5월 29일(UTC) 오메가트론(Omegatron)[응답]

가중 랜덤 문서 링크

왼쪽 네비게이션 메뉴에 있는 "랜덤 기사" 링크가 마음에 드는데, 클릭이 좀 걸려야 흥미 있는 기사가 떠오른다.대부분 작은 그루터기를 뽑아내는 것 같다.나는 인기에 의해 선택된 임의의 페이지를 끌어 올리는 "가중 무작위" 링크를 보고 싶다. 즉, 방문 횟수가 100배나 많은 페이지는 창시자가 본 적이 없는 페이지보다 100배 더 많은 페이지가 선택될 것이다.

위키 소프트웨어는 어딘가에 페이지 히트 카운터가 있을 거라고 생각해.

하지만 성능상의 이유로 비활성화되어 있다.x4206 Talk Mess 22:24 (UTC)[응답]

그렇다고 무작위로 되는 건 아니잖아?게다가, 스텁은 확장될 예정이고, 만약 우리가 가중치를 가진 시스템을 가지고 있다면, 결국 같은 페이지를 반복해서 정리하기 시작할 것이다.Jmlk17 23:04, 2007년 5월 27일 (UTC)[응답]

나는 "랜덤 기사" 버튼의 진정한 본질은 그것이 "랜덤"이라는 것이라고 믿는다.나는 메뉴에 가장 많이 본 페이지 버튼이 있다고는 생각하지 않을 것이다.내 서명은 WP가 아니다.COI :) --랜덤 03:36, 2007년 5월 28일 (UTC)[응답]

내 생각에 상위 100페이지가 있는 오프위키 페이지가 어딘가에 있는 것 같아.그리고 그래, 임의의 기사는 더 짧은 페이지를 보여주기 위해 만들어졌다. --R concious_@ (Let's Go Yankees!) 03:39, 2007년 5월 28일 (UTC)[응답하라]

위치가 여기야.하지만 좀 더 접근성이 좋아지면 좀 멋질 것 같지 않아? --Random 03:43, 2007년 5월 28일 (UTC)[응답]

만약 여러분이 100개의 가장 인기 있는 페이지를 본다면, 우리의 히트곡의 많은 부분을 다루고 있는 것을 본다면, 여러분은 그것들 대부분이 메인페이지에서 링크된 것, 인기 있는 웹사이트에서 링크된 것, 또는 섹스와 관련된 것을 볼 수 있을 것이다.나는 대부분의 시간 동안 이것들 중 하나를 돌려준 임의의 기사가 그렇게 유용하지는 않을 것이라고 생각한다.Dcoetzee 05:05, 2007년 5월 28일 (UTC)[응답]

또한 이 달의 인기 영화가 무엇이든지 간에, 그리고 나루토에 관한 수많은 페이지. --tjstrf talk 18:45, 2007년 5월 29일 (UTC)[응답]

WP에서 제안된 변경사항:NOT#DIR 규칙

위키백과로 이동:마을_펌프_(정책)#proposed_change_in_the_WP:NOT.23DIR_규칙, 제안된 정책 변경이기 때문에.2007년 6월 7일(UTC) 7시 14분 론체스터의 퍼스프론[응답]

위키다타

누구 어디 있는지 아는 사람 있어?위키다타는 현재 논의되고 있는가?이 모든 링크들은 2006년 6월 이후 손대지 않은 것으로 보이며, 위키다타-l 메일링 리스트는 완전히 침묵하고 있다.오메가위키는 공식적인 위키미디어 프로젝트가 아니다(?). 그런데 왜 오메가위키는 우리의 모든 자매 프로젝트를 메인 페이지 하단에 나열하는가?) 하지만 위키다타는 재단 사이트에서도 언급되지 않는다... --Quidity 19:52, 2007년 6월 4일 (UTC)[응답]

인형들에 대한 규칙의 종식을 제안하다

Sockpuppet에 대한 내 에세이의 논리에 기초한다(사용자:쿨3/퍼펫), 나는 "각각의 기여도에 따라 각 계정을 판단"하는 정책에 찬성하는 삭스푸펫 금지를 끝낼 것을 제안한다.나는 너의 의견을 환영한다.쿨3 22:12, 2007년 6월 1일 (UTC)[응답]

Sockpuppet은 허용되지만, 권장되지 않는다.위키백과 참조:자세한 정보를 보려면 꼭두각시 인형뽑기.Clearly, if you cause no harm, then no harm should come to you or your friendly little puppets of sock. --Bossi (talk • gallery • contrib) 22:21, 1 June 2007 (UTC)[reply]

당신이 제안한 많은 경우에서, 그것은 이미 사실적으로 일어날 수 있다.만약 Willy on Wheels가 어딘가에서 훌륭하고 건설적인 편집을 하고 있다면, 아무도 그 계정이 그의 것인지 의심하지 않을 것이다.그러나, 양말 퍼펫은 컨센서스를 위조하는 것(그리고 한 자리를 지지하는 편집자의 수는 비록 그것이 유일한 요인이 아닐지라도 컨센서스를 결정하는 요소임)과 같은 해롭고 폭력적인 용도를 많이 가지고 있다.양말 장부를 찾는 것도 가능하다.Checkuser는 마법은 아니지만, 확실히 뒷받침되는 증거를 찾을 수 있다. (또한, 남편/아내 팀은 아마도 미트푸펫으로 여겨질 것이고, 그들은 거의 같은 대우를 받고 있다는 것을 주목하라.)나 자신도 삭푸펫이 하나 있는데, 여기서 찾을 수 있지만, 그것은 분명히 내 것으로 표시되어 합법적인 목적으로 사용되고 있다(공용 단말기에서 편집하면서 관리자 계정의 절충 방지).하지만 우리는 확실히 "네가 좋아하는 것을 위해 양말을 사용"이라고 말해서는 안 된다.그리고 만약 우리가 새로운 계정을 만들어서 사람들에게 금지를 회피하도록 허용한다면, 금지는 무의미할 것이다.금지란 그 사람이 편집하는 것이 금지된 것이지, 그들의 계정이 금지된 것이 아니라는 것을 의미한다.만약 그들이 금지를 해제하기를 원한다면, 그들은 적당한 시간을 기다렸다가 다시 돌아와서 그들이 한 일에 대해 사과하고 우리가 그들에게 다시 기회를 줄 의향이 있는지 물어볼 수 있다.세라핌블레이드 22:41, 2007년 6월 1일 (UTC)[응답]

나는 어떤 상황에서 양말푸펫이 허용되는지 완벽하게 알고 있다. 나는 양말푸펫이 항상 허용되어야 한다고 말하고 있다.남편/아내 팀에 대해 말하자면, 둘 다 그들 자신의 권리에 있는 편집자일 경우, 그리고 어쩌면 서로의 지식조차 없다면, 미트푸펫이라는 용어는 거의 적용되지 않는다.나는 우리가 계좌가 아닌 사람들을 금지한다는 것을 이해한다. 그리고 그것이 본질적으로 내가 바꾸고 싶은 것이다.의견 일치를 보기 위해, 나는 당신에게 내 에세이에서 "사람들이 그들의 기여에 대해 회계판단을 한다"라는 제목의 부분을 가르칠 것이다.쿨3 00:07, 2007년 6월 2일 (UTC)[응답]

때때로, 사람들은 사회공학적인 토론의 악의적인 수단으로 양말 인형을 사용한다.말하는 사람의 수보다 논쟁의 논리가 더 중요하다고 해도 위키피디아는 '로직'보다 '합의'에 더 기반을 둘 수 있다.의도(어떤 경우에는 원하는 것을 얻기 위해 사회적 계약을 무시하는 것)와 결과(어떤 경우에는 붕괴)는 특정 편집자가 커뮤니티와 백과사전 모두에게 전반적으로 좋은지 나쁜지를 분석하는 데 중요한 역할을 할 수 있다.당신의 생각은 나쁘지 않지만, 위키피디아조차도 그렇게 유토피아적인 사회구조를 가지고 있지 않다.Gracenotes § 01:17, 2007년^T 6월 2일 (UTC)[응답하라]

ㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇㅇ.나는 이것이 결국 통제 불능의 소용돌이를 일으켜서 꽤 나쁜 양말 퍼피로 이어질 것이라고 생각한다. 그리고 나는 개인적으로 그것에 동의하지 않는다.Jmlk17 07:04, 2007년 6월 2일 (UTC)[응답]

• 그래야 할지 말아야 할지, 위키피디아는 '협치'의 프로토콜을 사용한다.양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말을 무제한 허용하면 가장많은 경우에, 독신자들이 단지 시간적 여유와 꼭두각시 놀이에 대한 의지로 지역을 지배할 것이다.
• 양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-양말-
• Checkuser에 대해 더 많은 겸손함이 있어야 한다.특히 편집자는 확인을 확정적인 증거로 취급해서는 안 되며, 일반적으로 발음을 피해야 한다.
• 팥죽에 대한 규칙은 케이크를 먹고 그것을 먹으려는 시도를 의미한다.특히나 못생긴 전환기가 있었는데, 고기 조각이 장려된 것에서 불법화 된 것으로 바뀌었기 때문이다.

2007SlamDiego 10:06_←T, 2007년 6월 2일 (UTC)[응답하라]

검색엔진 추가

JavaScript 사용 브라우저의 경우 Special:검색 엔진을 선택할 수 있도록 검색하십시오.누군가가 나에게 엑살라드를 추가해야 한다고 제안했다; 대본의 저자로서, 지역사회가 그것에 동의한다면 코드를 써도 괜찮다. (User talk에서 요청 참조:Gracenotes#검색 엔진 추가).Gracenotes § 17:04, 2007년^T 6월 1일 (UTC)[응답]

이런 얘기를 꺼낼 적절한 장소는 모르겠지만 파이어폭스는 낙하산 검색대에서 연간 5000만 달러를 번다.검색 사이트는 어떻게 선택해야 할까?--Keaner Keaner 09:28, 2007년 6월 2일 (UTC)[응답]

그럼 그들이 우리에게 기부한 금액만큼!음, 우리의 경우, 아마도 그것이 검색에 얼마나 효과적인가.내 토크 페이지에 있는 메모를 봐, 데이빗.모노(토크 · 기여)는 아마도 세부사항을 제공할 수 있을 것이다.Gracenotes § 17:03, 2007년^T 6월 2일 (UTC)[응답]

위키백과:플래그 지정된 리비전

얼마 전에 이 제안된 정책 페이지를 시작했어.2007년 5월 31일(UTC) 23:32, 전체 목소리[응답]

아티클 중복 옵션

유사한 여러 기사를 작성할 때, Talk 페이지의 wikiProjects를 포함한 초기 기사의 형식을 마무리 한 후에 기사와 Talk 페이지를 복제할 수 있는 것이 유용할 것이다.이것은 이동 옆에 있는 다른 탭일 수도 있고 편집자가 복제하기를 원하는 것에 대한 확인란이 있을 수도 있다.

기사

토크

내가 생각해보지 못한 다른 일

그것은 또한 새로운 기사 이름에 대한 필드를 가지거나 저장 시 편집자에게 새 제목을 선택하라고 경고할 수 있다.그리카 ≠21:17, 2007년 5월 31일 (UTC)[응답]

이 작업을 수행할 수 있음 - "&preload="를 추가하십시오.기사" 새로운 페이지를 편집하기 위해 URL 끝부분까지, 모든 위키텍스트를 원본(기사)에서 새 페이지의 편집 창으로 복사한다.토크 페이지는 따로 해야 하는데 매우 편리하다.니힐트레스^(t.c.s) 23:14, 2007년 5월 31일 (UTC)[응답하라]

나는 그것이 다소 편리하다고 말하고 싶다.그것은 매우 흥미롭고 나는 그것을 사용할 것이 확실하지만, 나는 여전히 기사와 토크 페이지를 동시에 하는 해결책을 원한다.그리카 â 1 05:56, 2007년 6월 1일 (UTC)[응답]

은퇴한 위키백과 기념관

나는 어제 생각하고 있었다."추모문을 만들어 가면서 넘어간 위키백과인들을 감상하는 것도 좋은 방법이 아닐까?"그 문제에 대한 다른 사람들의 생각이 무엇인지 모르지만, 나는 그것이 좋은 생각이라고 생각했다.그래서 얘기를 꺼내고 있어. --Tî »îµ Rµ±Nî'´mm Eî'´'´´'´´rrr 19:50, 2007년 5월 31일 (UTC)[응답]

• 사용자 공간에서 시작하고, 사용량이 많을 경우 WP-공간으로 이동하십시오.좋은 생각 같지만 릭크와 엘라라걸레가 들어오려면 매개 변수가 있어야 하는데 로브두르바르와 에스제이가 빠지고 말았다.또한, 기념비적인 위키피디아가 죽은 사람들로부터 부활하기로 결정한다면 이상할 수도 있다.예치엘만 20:06, 2007년 5월 31일 (UTC)[응답]

• 만약 그것이 너의 의견이라면, 나는 내 사용자 공간의 한 페이지를 시작할지도 몰라.일단 페이지가 WP 스페이스에 도달하면 사용자가 참여할 자격이 있는지 결정하는 가장 좋은 방법은 컨센서스를 갖는 것이라고 생각한다.만약 한 명이 돌아온다면, 당신은 목록에서 개인을 제거하기만 하면 된다.다른 생각은 없으십니까? --Tî »µµµî´nî´´m´´´´´´´´rrrrr 01:07, 2007년 6월 1일 (UTC)[응답]
  • 우리는 이미 위키피디아를 가지고 있다.위키백과 누락.Raven4x4x12:28, 2007년 6월 2일 (UTC)[응답]

다른 온라인 무료 백과사전 링크

위키백과는 위키북스나 위키코테와 같은 다른 위키프로젝트와 연결되기 때문에 컨버터레이피아와 같은 다른 온라인 백과사전들과 연결되어야 한다.이렇게 하면 위키피디아는 중립성과 의견의 다양성을 보여주고 보장할 수 있다. --draq

아니, 여기서는 중립적이고 다양한 기사를 써야 해.우리는 우리가 제공하지 않는 서비스를 제공하는 다른 위키에만 링크한다. --tjstrf talk 19:32, 2007년 5월 31일 (UTC)[응답]

나는 tjstrf에 동의해야 한다.위키미디어 네트워크는 "위키" 네트워크다.외부 백과사전에 연결할 실질적인 이유는 없다. --TH »»µ µ±Nî"´m"´m"´´"´´" 19" 19´"19:41, 2007년 5월 31일 (UTC)[응답]

우리보다 더 깊이 있는 커버리지를 제공하기 때문에 링크하는 것을 보증할 수 있는 주제별 위키도 있지만, --tjstrf talk 20:00, 2007년 5월 31일 (UTC)[응답]

당신은 확실히 당신이 원하는 어떤 사이트에든 기사에 링크를 추가하고 그것의 관련성을 결정하기 위해 커뮤니티에 맡길 수 있다.그리카 â 31 20:56, 2007년 5월 31일 (UTC)[응답]

동의한다. 만약 다른 무료 엔클로페디아에서 우리보다 커버리지가 더 좋다면, 우리는 그것에 연결해야 한다. --T» »µs Rî±Nî'´m Eî'´'´¹„rr 01:04, 2007년 6월 1일 (UTC)[응답]

아니, 아니, 아니.위키들은 모두 믿을 수 없다.코버스 코닉스 03:14, 2007년 6월 1일 (UTC)[응답]

그래서 우리가 그들을 언급하지 않는 거야.그들은 우리가 제공하지 않는 어떤 종류의 기능을 제공하는 경우에도 여전히 좋은 외부 연결을 만들 수 있다.예를 들어 위키리크레이션 위키보다 더 나은 스캔 기술 자원을 찾을 수 없을 것이고, 위키리크스에 포함시키거나 포함시키지 않는 지시를 제공하기 때문에 관련 페이지에서 훌륭한 외부 링크를 만들 수 있다. --tjstrf talk 03:20, 2007년 6월 1일 (UTC)[응답]

새로운 포럼 기반 대화 페이지 형식

이 제안은 편집에 대한 논의에 관한 나의 이전 제안과 관련이 있다.

위키피디아는 현재 기사와 토크 페이지를 모두 편집하기 위해 동일한 유형의 인터페이스를 사용하고 있다.이것은 비논리적인 것처럼 보인다. 왜냐하면 토크 페이지는 백과사전 기사가 아니라 포럼이기 때문이다.웹 상의 다른 대부분의 포럼(예: 구글 그룹)은 기고문이 자동으로 서명되고 사용자는 자신의 게시물을 편집만 할 수 있는 스레드 기반 형식을 사용한다.위키피디아 토크 페이지에서는 한 사용자의 코멘트가 어디에서 끝나 다른 사용자의 코멘트가 시작되는지를 보는 것이 종종 어렵다.이전 게시물 사이에 코멘트를 삽입하거나 삽입하는 작업은 수동으로 수행해야 하며, 이에 대한 표준 스타일이 없다. 복잡한 다중 사용자 토론에서는 사용자가 어떤 코멘트에 응답하고 있는지 구분하기가 어렵다.구글 그룹과 비슷한 것을 구현해보는 것은 어떨까?

Mtford 02:29, 2007년 5월 27일 (UTC)[응답하라]

나는 모든 사람들이 이것이 좋은 생각이라는 것에 동의하고 개발이 진행 중이라고 생각한다.시행되려면 시간이 좀 걸릴지도 모른다.---Keaner Keane 08:51, 2007년 5월 27일 (UTC)[응답]

나 혼자일 수도 있지만, 나는 사실 현재의 토크 페이지 시스템이 이상적이라고 생각해.기사 체계와 동일하기 때문에, "스레드"라고 기술하는 것이 아니라 "누구나 편집할 수 있다"라는 백지 슬레이트에서 벗어나, 토크 페이지는 기사 워크샵으로 기능할 수 있다.

나는 어떻게 포럼과 같은 시스템으로의 전환이 (대화보다는) 대화 페이지에서 작업할 수 있는 우리의 능력을 많이 잃거나 배너, 초안, 기사 상태 정보, 그리고 현재 하고 있는 모든 대화 페이지에 대한 또 다른 메타 기사 네임스페이스를 만들지 않고 구현될 수 있는지 모르겠다.나는 또한 포럼 시스템의 별로 중요하지 않은 레이아웃이 어쨌든 나를 짜증나게 할 것이라고 예상하며, 그것은 단지 위키피디아의 대화 페이지를 작업공간이 아닌 주제에 대해 무작위로 수다를 떨 수 있는 포럼으로 만드는 데 도움이 될 것이라고 믿는다.한마디로 반대. --tjstrf talk 09:10, 2007년 5월 27일 (UTC)[응답하라]

다들 누구야?자칭 보호자 모임인가?나는 tjstrf에 동의한다 - 이것은 완전히 불필요하고 변화를 위한 변화의 완벽한 예다.그 토크 페이지는, 말하자면, 수다를 위한 것이 아니라, 기사에 대한 토론을 위한 것이다.위키피디아는 다른 채팅방으로 변질되어서는 안 된다.이미 웹에는 충분히 있다. -- 네크로테스프 13:54, 2007년 5월 27일 (UTC)[응답]

아주 센스 있는 두 편집장이야나는 이 어리석은 생각에 강력히 반대한다.현재 우리가 가지고 있는 것은 매우 복잡하지 않고, 매우 유연하며, 사용하기 쉽다. (대부분의 fora는 특별히 사용자 친화적이지 않다.)아드리안 M. H. 16:57, 2007년 5월 27일 (UTC)[응답]

내 에세이 사용자 보기:Dcoetzee/ wikithreads가 왜 나쁜지 우리가 왜 대화 페이지에 wiki를 사용하고 싶지 않은 많은 이유들 때문에.어떻게 세부사항을 분석해야 하는가에 대한 실제적인 질문에 답하기 위해, 그것은 임시 페이지에서 할 수 있거나 개별 게시물을 위키 구문을 사용하여 작성할 수 있다.단순히 위키 서식을 그 안에 넣는 것 보다 위키 서식을 사용하여 우리의 실을 포맷하는 비실비실적인 문제로 갈 이유가 없다.Dcoetzee 17:09, 2007년 5월 27일 (UTC)[응답]

• 나도 모두가 아닌 것 같아.나는 tjstrf에 동의한다. 현재의 토크 페이지 시스템은 포럼 위키백과가 아니다.Talk 페이지 가이드라인 위키백과 대화 페이지의 목적은 편집자들이 관련 기사 또는 프로젝트 페이지의 변경사항을 논의할 수 있는 공간을 제공하는 것이다.인터넷 포럼에 따라 인터넷 포럼은 토론을 개최하고 사용자 생성 콘텐츠를 게시하기 위한 웹 애플리케이션이며, 사용자 생성 콘텐츠는 WP를 위반할 수 있다.OR. 당시 세대 백과사전 콘텐츠보다는 포럼에 기반한 토론을 장려하는 전환은 위키백과와 상충될 것이다.정책 및 지침.지프데이 (토크) 17:20, 2007년 5월 27일 (UTC)[응답]

WP:OR는 특히 토크 페이지가 아닌 기사에 적용된다.토크 페이지의 주요 목적은 기사를 토론하는 것이지만, 여전히 토론 형식을 취하고, 대화의 실마리를 가지고 있으며, 글과 외관이나 진화가 뚜렷이 다르다.어떤 것을 "포름"이라고 말하는 것은 대화 주제에 대해 아무 말도 하지 않는다 - 그것은 단지 형식이 바뀐다고 해서 사람들이 그 곳에 사회적 것들을 게시하기 시작하는 것은 아니다.목적과 내용은 동일하고, 소프트웨어 지원만 다를 것이다.Dcoetzee 05:02, 2007년 5월 28일 (UTC)[응답]

• 강한 반대 - 나는 이것이 또 하나의 영원한 제안이 되기를 정말 희망한다.나는 위와 같은 논평에 전적으로 동의한다; 위키는 기사 주제에 대한 내용으로 스팸을 보내는 포럼이나 그 토론 페이지가 되어서는 안 된다.2007년 5월 28일 08:30 (UTC)[응답]

나는 아직도 토론을 더 잘 뒷받침하는 다른 방법으로 기사 개발에 관한 정확히 같은 논의를 단순히 제시하는 것이 마술처럼 모든 사람들이 주제 밖의 것들에 대해 토론하도록 만드는지를 보지 못하고 있다.내가 간과했던 이것을 설명하는 심리학 연구가 있는가?아니면 사람들은 단지 다른 포럼에서 그들의 이전 경험을 지나치게 일반화하고 있는가?Dcoetzee 08:35, 2007년 5월 28일 (UTC)[응답]

여기도 마찬가지야.우리의 토크 페이지에 더 좋은 것을 갖는 것은 우리의 협업 효율성을 크게 향상시킬 것이다.뭐라도, 주제 밖의 잡담을 제거하고 방지하는 것이 더 쉬울 것이다. -- 네드 스콧 08:57, 2007년 5월 28일 (UTC)[응답하라]

잘 말했다.매일 많은 시간이 추가 코멘트로 업데이트 된 스레드를 찾는 것만으로 낭비되고, 너무 자주 우리는 토론과 게시물을 섞지 못했다. -- 네드 스콧 07:15, 2007년 5월 31일 (UTC)[응답]

포럼 기반 형식은 빠른 코멘트에 사용할 수 있음...그러나 기사의 단편적인 작업(토크 페이지의 주요 이유 중 하나)에 대해서는 그렇지 않다.나는 있는 그대로의 것을 더 좋아한다.블루보어 18:29, 2007년 5월 31일 (UTC)[응답]

다시 한 번, 스니펫은 개별 게시물 내에서 편집될 수 있다(아직 위키 구문으로 작성될 수 있음). 또는 임시 기사로 편집될 수 있다.Dcoetzee 19:36, 2007년 5월 31일 (UTC)[응답]

많은 사람들이 포럼이 기사의 단편적인 작업을 하기에 적합하지 않다고 말하지만, 나는 현재 토크 페이지에서는 그러한 "작업"의 많은 예를 보지 못한다.작품이 프리 스타일 토크 페이지에 의존하거나, 포럼(위키 구문 포함)과 사용자 샌드박스의 조합이 덜 편리할 수 있는 경우는 확실히 보지 못했다.아마도 누군가가 토크 페이지의 역사에서 그러한 작업의 예를 발견함으로써 이 논의를 진전시킬 수 있을 것이다.그러면 우리는 "위키피디아도 자기 방식대로 일을 하는 것"에 대한 이상화만 하는 것이 아니라 포럼에서 같은 작품이 어떻게 보일지에 대해 구체적으로 논의할 수 있다.Mtford 20:12, 2007년 5월 31일 (UTC)[응답하라]

페이지 맨 위에 있는 GA 아이콘?

단지 궁금했을 뿐인데, FA가 오른쪽 상단에 있기 때문에 왜 거기에 GA 아이콘도 열거할 수 없는가? :-) )âââââ 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 1919:31^{slurp me!}, 2007년 5월 30일 (UTC)[응답]

GA는 FA 대체가 되어서는 안 되며, 이미 FA와 너무 닮았다.이건 꽤 괜찮은 기사들을 위한거야.CMUmmert â·토크 19:38, 2007년 5월 30일 (UTC)[응답]

과거에도 이에 대한 논의가 있었는데, 코너에 아이콘을 두지 않는 것에 대한 주된 반대는 GA를 통과하거나 낙제할 수 있는 편집자 한 명만 기사를 검토한다는 것이다.반면 FA들은 복수의 편집자가 참여하는 보다 엄격하고 발전된 검토 과정을 거친다.이를 통해 FA는 품질을 보장하기 위해 기사를 훑어보는 인원의 양에 대해 오른쪽 상단에 있는 것으로 지정할 수 있다. --Nehrams2020 19:38, 2007년 5월 30일(UTC)[응답]

(충돌 편집)이 생각은 과거에 제안되었다가 거절당했다.다양한 관련 토론은 {{good 기사}에 대한 "여기에 링크된 내용"을 참조하십시오.이것 또한 흥미로울 수 있다.크리스토퍼 파럼(talk) 2007년 5월 30일 19:43 (UTC)[응답하라]

나는 그것이 있는 곳에 머물러야 한다고 생각한다.기사에서 FA의 지위를 얻는 것은 성과인데 반해, GA는 대단한 성과인 반면, FA는 당연히 한 계급 더 높다...Jmlk17 21:20, 2007년 5월 30일 (UTC)[응답]

난 동의해야 해.FA 아이콘은 지역사회가 찾아낸 우수성의 상징이다.반면에 GA는 한 사람의 리뷰다.FA 기호를 보면 커뮤니티 의견에서 최고 수준의 기사를 읽고 있다는 것을 알 수 있다.
--Tî »µµ Rî±Nî'´m Eî'´'´'´'´'´'´' 19' 19r 19r 19:45, 2007년 5월 31일 (UTC)[응답]

목록 맨 위에 새 게시물

• 왜 새 게시물은 맨 아래가 아니라 맨 위에 올려놓지 않는가.이렇게 하면 나이가 들수록 대부분의 사람들은 그들이 원하거나 흥미를 잃었던 것을 말하게 된다.이렇게 하면 가장 엄격한 게시물을 위해 바닥까지 내려갈 필요가 없다; 그것은 자동으로 목록의 맨 위에 가까이 있다.가장 오래된 것들은 노령으로 인해 자동적으로 목록에서 제외될 것이다.
• 내가 만든 게시물에 워치를 달 수 있을까?그러면 페로손은 자신의 게시물에 대한 응답이 있는 경우에만 다시 확인하게 된다.그렇지 않으면, 아직 응답이 없음에도 불구하고(아마 시간낭비일 것이다) 지금 다시 확인해야 한다.그렇지 않다면, 이러한 기능이 가능하도록 소프트웨어를 설계할 수 있는가?--Doug 13:35, 2007년 5월 30일 (UTC)[응답하라]

메시지 보드 형식을 원하는 것 같은데.위키는 그런 식으로 작동하지 않는다.어쨌든, 당신의 질문에 대한 직접적인 답변으로:

• 첫 번째 제안은 나쁜 생각처럼 들린다.위에서 아래로 읽으니, 토론을 위에서 아래로 따르는 것이 훨씬 더 좋고 쉽다.어떤 경우에도 긴 대화 페이지에는 내용 목록이 있어 관련 섹션으로 쉽게 이동할 수 있다.
• 두 번째 제안은 어떤 의미에서 이미 받아들여졌다.제목을 사용하여 주제를 작성할 경우, 편집자가 해당 섹션만 편집했거나 편집 요약을 삭제하지 않은 경우, 해당 제목 아래의 추가사항은 제목 제목을 편집 요약의 일부로 갖는다.히스토리 탭에서 각 섹션에 추가된 내용을 볼 수 있다.GDallimore (Talk) 14:39, 2007년 5월 30일 (UTC)[응답하라]

나는 여전히 우리가 늘 그래왔던 것처럼 그것을 더 좋아한다.스크롤 다운은 1초밖에 걸리지 않지만 훨씬 더 체계적으로 유지된다.Jmlk17 21:19, 2007년 5월 30일 (UTC)[응답하라]

• 첫 번째 제안:내가 여기서 제안하는 것은 예를 들어 인문 참조 데스크에서 5월 30일(가장 최근 날짜)이 상위에 있고 5월 27일이 하위에 있는 것이다.5월 27일 과목이 답안되어 더 이상 대부분의 과목에는 흥미가 없다.5월 30일 자료는 여전히 답하고 있다.이 날들 중 가장 최근의 내용은 맨 위에 있고 가장 오래된 것은 맨 아래에 있다.나는 네가 위에서 아래로 읽는 것을 이해한다. 따라서 토론이 위에서 아래로 읽히는 각각의 "내용" 안에서 (지금과 같은) 모든 것을 읽는다.내가 제안하는 유일한 것은 가장 최근의 "콘텐츠"가 가장 위에 있고 가장 최근의 "콘텐츠"가 가장 위에 있다는 것이다.그렇지 않으면, 각 내용 내에서 위에서 아래로 읽힐 것이다."My Watch List"가 설정되는 방식은 내가 말하는 바로 이런 방식으로, 가장 최신의 최신 정보를 상위권에 두고 있다.최고령자는 결국 명단에서 제외된다; 훨씬 더 논리적인 접근.이 설정을 하는 방법은 5월 30일이 가장 최신 워치를 맨 위에 올려놓고 맨 위에 있다는 것이다.5월 23일은 최하위권이고 내일까지 떨어지고 5월 24일은 최하위권일 것이다.5월 31일은 내일 아침 최고의 자리에 오를 것이고 내가 보고 있는 어떤 페이지에도 새로운 변화가 있을 것이다.내 감시 목록에 레퍼런스 데스크의 "내용"을 넣을 수 없다는 것만 빼면 말이다.
• 두 번째 제안:그러나 당신은 당신의 워치리스트에 있는 것처럼 기사에 대해 당신이 하는 것처럼 이것에 "워치"를 붙일 수 없다.나는 누군가가 인문학적 참조 데스크에 어떤 것을 올려놓기만 하면 그것은 내 워치리스트에 나타나지만, 내가 시작한 "컨텐츠"(즉, "페트라르치가 언제 태어났는가")가 대답될 때만 그것이 내 워치리스트에 나타나게 된다는 것을 원하지 않는다. 그렇지 않으면 나는 종종 답이 있는지 확인하기 위해 다시 확인하는 것을 무시할 수 있다.처음 더 명확하게 말하지 못해서 미안해.--Doug 21:50, 2007년 5월 30일 (UTC)[응답]

일반 항목에 대한 템플릿

나는 특정 주제 안에서 나오는 많은 항목들이 매우 일관성이 없다는 것을 알아챘다.예를 들어, 만약 내가 두 개의 다른 영화를 찾아본다면, 가장 보편적이고 중요한 정보들 중 몇몇은 그 기사를 쓴 사람에 따라 매우 찾기 쉬운 것에서부터 매우 어려운 것까지 다양할 수 있다.만약 우리가 가장 일반적이고 중요한 정보를 먼저 전달하는 공통 주제 템플릿을 만든다면, 이후에 추가되는 정보는 위키백과에게 더 일관된 느낌, 더 사용하기 쉽고 더 유용할 것이다.주제 템플릿은 약리학, 동물 분류, 식물 분류, 영화, 사람, 음악 앨범에 이르기까지 모든 분야에 걸쳐 있다.

동의해, 아무것도 해칠 수 없어, 사실 내 관점에서만 좋을 수 있어.2007년 5월 30일 (UTC) 12:00 (UTC)[응답하라]

인포박스 템플릿을 사용하면 필수 정보를 쉽게 찾을 수 있다.기사 텍스트가 엄격하게 표준화될 필요는 없다고 생각한다.정보를 찾기가 어렵다면 해당 기사에 맞는 더 나은 방법으로 섹션을 정리해 보십시오.위키피디아와 같은 일반적인 지침이 있다.위키프로젝트 필름/스타일 지침.2007년 5월 31일 (UTC) 09:03, 응답

추가 옵션이 있는 상단 표시줄

현재 상위 바(이름이 있는지 알 수 없음)에는 사용자 페이지, 토크 페이지, 선호도, 감시 목록, 기여도, 로그아웃 옵션이 포함되어 있다.사용자가 다른 페이지를 이 상단 표시줄에 추가할 수 있는 선택사항이 있는지 궁금했다.추가될 수 있는 최소 4~5페이지/옵션에 대한 여지가 있는 것으로 보인다.사용자는 자신이 가지고 있는 하위 페이지(이미지 갤러리, 샌드박스, 사용자박스, 항상 사용하는 템플릿 등), 항상 입력하지 않으려는 순간에 작업 중인 특정 기사 또는 다른 사용자의 페이지나 대화 페이지를 추가하도록 선택할 수 있다.이것이 실현 가능한가?만약 그렇다면, 선호도에 따라 허용함으로써, 사용자들은 원하는 방식이나 선택한다면 전혀 수정하지 않고 수정할 수 있었다. --Nehrams20 06:33, 2007년 5월 30일 (UTC)[응답]

혹시라도 가능하다면 사용자들의 CSS 파일을 통해서라도 가능할 것 같은데, 최근에 궁금했어.아드리안M. H. 14:57, 2007년 5월 30일 (UTC)[응답하라]

비슷한 건 아니지만 위키피디아를 찾았어링크 창에 항목을 추가할 수 있는 도구/내비게이션 바로 가기입니다.아드리안M. H. 18:20, 2007년 5월 30일 (UTC)[응답하라]

좋아! 고마워.사실 이번 주 초에 같은 일이 있었는지 궁금했어.Jmlk17 21:17, 2007년 5월 30일 (UTC)[응답]

멋진 연결고리네, 고마워.이것이 제안될 수 있는 유일한 장소인가 아니면 다른 사람이 알 수 있는 다른 장소가 있는가? --Nehrams20 00:14, 2007년 6월 2일 (UTC)[응답]

위키백과의 뱀

상태 뱀(State Snaks) {또는 당신이 원하는 것은 무엇이든 상관없어}라는 제목의 기사가 만들어져야 하며, 이 기사는 모든 50개의 상태를 나열하고, 이 목록에는 각 뱀에 대해 명확하고 매우 잘 보이는 사진과 뱀에 대한 훌륭한 설명이 포함되어 있다(예: 미주리를 클릭하면 미주리의 모든 뱀들의 목록이 나온다.) 그리고 만약 내가 맞다면, 나는 이런 기사들을 찾지 못했기 때문에 이 모든 기사들을 만들어야 할지도 모른다.이것은 사람들이 뱀이 어떤 상태에 있는지, 그리고 그들이 어떻게 생겼는지 확인하는 데 도움이 될 겁니다. 뱀과 그들의 정원이나 마당이 있는지, 그리고 그것이 무엇인지 볼 필요가 있습니다, 그리고 사진 한 장이 매우 도움이 될 겁니다. 그래서 모든 뱀에 대한 사진과 사진 지도는 그들이 매 순간 살아가고 있는 것처럼요.목록에 있는 nake가 매우 도움이 될 수 있다.그래서 이 모든 것이 좋은 생각이 될 수 있다. 결국 위키피디아는 사람들이 그들이 필요로 하는 형태를 찾을 수 있도록 되어 있다.2007년 5월 29일 (UTC) 20:46 (UTC)[응답하라]

확실하지는 않지만, 그 기사와 동봉된 기사들이 꽤 길지 않을까?그러니까, 각 주마다 뱀의 종은 몇 종이나 될까?틀림없이 많은 숫자일 것이다.그냥 생각하고 논평할 뿐이다.Jmlk17 04:17, 2007년 5월 30일 (UTC)[응답]

리스트나 카테고리? (SEWilco 01:13, 2007년 5월 31일 (UTC))[응답하라]

그래, 하지만 그게 할 수 있는 좋은 점을 생각해봐 내 정원에 구리 머리가 있는데 다른 뱀들이 눈에 띄면 이런 생각이 들어그리고 내가 주 밖으로 나가고 싶다면, 이것은 도움이 될 것이고, 만약 알려지지 않은 뱀이 보인다면, 이것은 그것을 확인할 수 있을 것이다.이것은 매우 유용하고 꽤 도움이 될 것이다.2007년 5월 30일 (UTC) 11:57 (UTC)[응답하라]

오, 날 믿어, 나는 그것이 잠재적으로 꽤 유용할 수 있다고 생각해.그러나 실제로 각 주의 뱀 목록을 가지고 있는 온라인(또는 오프)의 출처가 있는가?Jmlk17 21:15, 2007년 5월 30일 (UTC)[응답하라]

네... 음...안녕하십니까, 온라인 {and off}에는 자료를 찾아내고 더 많은 것을 배울 수 있는 자료들이 있지 않습니까, 그런데 왜 위키피디아가 필요한가, 게다가 위키피디아는 어떤 사람들이 물건을 찾는 거의 첫 번째 장소인데, 사람들이 정보를 찾는 것을 돕기 위한 위키피디아, {그것은 온라인과 오프라인에서 찾을 수 있다.이 제안이 수락될 경우 제공할 수 있는 형태.2007년 5월 30일 (UTC) 23:12 (UTC)[응답하라]

물론, 아무도 당신이 당신의 (또는 다른) 상태에 대해 그런 목록을 만드는 것을 막지 못한다.나 자신이 미네소타 파충류 목록을 만들었는데, 그 지역사회가 예상대로 확대되었다.그리카 â 31 20:53, 2007년 5월 31일 (UTC)[응답]

미국의 파충류 목록 같은 걸 말하겠어. 성경책 15 오래된 질문...01:49, 2007년 6월 2일 (UTC)[응답하라]

"TEAT" - 아프리카계 미국인 중 유일하게 "Custser' Last Stand"에서 제7기갑대와 싸운 이사야 도르만에 관한 역사 소설이다.

누구에게 할 수 있는 일:

나는 연구에 많은 시간을 보냈고 그것을 쓰는데 5년을 보냈다.나는 문학 에이전트와 이 주제를 전문으로 하는 출판사에 그 이야기를 제출할 친구가 있었다.내 에이전트인 마크 브레트가 지난 달에 죽었다고 생각해.모든 통신이 끊겼다.나는 "아침별의 아들"의 출판사와 접촉할 생각을 했을 때 당신의 멋진 웹사이트를 발견했다. "배틀"의 마지막 히트작인 "아침별의 아들"과 그것에 이르게 된 사람들과 사건들을 알게 되었다.

원고는 268쪽이다.나는 그것이 "진짜 페이지 터너"라고 들었다.소설의 끝에서 독자는 천국이 무엇인지 발견한다.커스터 웹 사이트에 접속했어너도 알다시피, 그에 대한 역사책이 백 권이 넘겠지만, 소설이 한 권도 아닐 거야!역사책은 무슨 일이 일어났는지 말해주고, 내 역사 소설은 어떤 기분이었는지 말해준다.나는 그것이 처음이고, 아침 별의 아들처럼 "슈퍼히트"가 될 뿐만 아니라 "늑대와 함께 하는 늑대들"과 같은 대서사 영화도 "Wolves"와 달리 훌륭한 텔레비전 시리즈가 될 것이라고 믿는다.

빠른 시일 내에 회신을 기다리겠다.

정중히, 당신의.

O.C. 젠킨스 주니어

선생님, 이 웹사이트가 당신이 책을 홍보하기 위한 정확한 사이트인지 잘 모르겠습니다만.흥미롭지는 않지만, 다른 방법을 계속 시도해 보는 것을 추천한다.또한, 나는 네가 무엇에 대한 답장을 받기를 원하는지 정확히 모르겠다.그러나 행운을 빌며, 행운을 빈다.Jmlk17 20:51, 2007년 5월 28일 (UTC)[응답하라]

그러나 이사야 도만에는 확장, 개선, 지원 시트를 사용할 수 있을 것 같은 위키피디아 페이지가 있다. -- 보라카이 빌 23:01, 2007년 5월 28일 (UTC)[응답]

좋은 제안이야!그 글은 네가 아는 지식으로 크게 도움이 될 수 있을 수 있다.Jmlk17 05:23, 2007년 5월 29일 (UTC)[응답]

혹시 아직도 헷갈릴지 모르니 이 웹사이트는 일반 관심사 백과사전이고, 어떤 식으로든 도서출판업계와 제휴하고 있지 않다는 점을 지적해야겠다.--Pharos 05:33, 2007년 5월 29일 (UTC)[응답]

당신의 소설은 커스터와 리틀비혼 전투에 관한 것이 확실히 처음은 아니다.커스터의 '마지막 스탠드'가 가장 중요하고 초점을 맞춘 소설이자 영화인 '리틀 빅맨'을 보라.에디슨 15:11, 2007년 5월 30일 (UTC)[응답하라]

애논 편집 강제 폐지

현재 익명의 편집에 반대하는 모든 사람들은 그들의 노력이 서서히 악화되는 것을 막기 위해 현상유지를 계속할 수밖에 없다.주의 깊게 관찰하지 않는 많은 작업은 악화된다.여러 해 동안 지속되는 제안서 페이지를 읽으면서, 나는 우리가 대다수는 아니더라도 상당한 부분을 구성하고 있다고 믿는다.만약 제대로 조직된다면, 우리와 모든 동조자들은 지금까지 무시당한 이 위키피디아 인구에 대해 우리를 심각하게 받아들이고 우리의 시간과 노력을 낭비하는 것을 멈추도록 강요할 수 있다.날짜가 정해지고 위키백과 내외에 널리 광고된다면, 이 입장을 지지한 모든 사람들은 일주일 동안 위키백과를 보이콧하고 나머지는 공공 기물 파손에 대처하기 위해 남겨둘 수 있다.우리가 더 나아가면, 우리는 로그아웃해서 우리 스스로 페이지를 파괴할 수 있을 것이다. (화내지 말고, 계속 읽어라), 위키백과 거물들이 우리를 더 이상 무시할 수 없다는 생각에서, 그리고 우리가 없으면, 편집자들은 계속해서 위키백과는 아무것도 아니라는 것을 깨닫게 될 것이다.우리는 그들이 우리의 시간을 존중하도록 강요하고, 익명의 편집자들이 우리의 시간을 그렇게 많이 차지하지 못하게 할 것이다.일주일이 지난 후, 가장 현명한 방법은 모든 기사를 일주일 전에 그들의 지위로 되돌리는 것이다.물론 불매운동 이전에 필요한 변화가 일어났다면 그렇게 될 필요는 없을 것이다.위키피디아는 그것을 만든 사람들보다 더 크다.

그런 것을 조직하는 데 도움을 줄 사람이 있을까?나는 이것이 얼마나 급진적으로 들리는지 충분히 알고 있지만, 나는 단지 장기적으로 위키피디아와 그 편집자들을 도우려는 것이다. --Seans Potter Business 16:12, 2007년 5월 12일 (UTC)[응답]

이것은 끊임없는 제안이며, 거절할 만한 충분한 이유가 있다.니힐트레스^(t.c.s) 16:41, 2007년 5월 12일 (UTC)[응답하라]

독서 m:재단 문제, 등록하지 않고 기사를 편집할 수 있는 모든 사람의 능력은 논쟁의 여지가 없으며, 재단이 위임한다.나도 이 명령에 동의해.^High_InBC^{(Need help? Ask me)} 2007년 5월 12일 16:46 (UTC)[응답하라]

만약 우리가 쓰레기를 줄이기 위해 어떤 일을 한다면, 나는 대신 메인 스페이스 페이지 작성을 확증된 사용자들에게만 자동화하는 경향이 있다.익명의 편집이 많은 것은 형편없거나 공공 기물 파손이지만, 나는 특히 총체적으로 도움이 되는 것도 많이 보았다.나는 익명 편집을 계속 허용하는 것을 전적으로 지지한다.세라핌블레이드 16:50, 2007년 5월 12일 (UTC)[응답]

방금 세 분 모두 500여 건의 최근 기고문을 살펴봤더니, 이 편집의 대부분이 템플릿, 토크 공간, 사용자 페이지라는 것을 알 수 있었다.I think you're want to work on GIRMS 에서 일하고 싶은 사람들을 bandals와 영원한 투쟁으로 매도하는 것은 공평하지 않다고 생각한다, 당신들 스스로가 그 폐해를 겪지 않을 때. --SensPotato Business 17:22, 2007년 5월 12일 (UTC)[응답]

만약 당신이 나의 최근의 기여를 정말로 본다면, 당신은 아마도 "n-warn"과 같은 요약과 함께 사용자 대화에서 많은 편집들을 볼 수 있을 것이다 - 새롭게 만들어진 사용자들은 다양한 이유로 부적절한 기사를 만든다.나도 반달리즘과 싸우고 있어. 네가 말한 기사 편집의 대부분은 삭제된 부적절한 기사들을 태그하는 데서 나온 거야. 삭제된 기고문은 나타나지 않아.그것은 또한 애논 편집을 폐지하는 것이 달성하는 것보다 더 많은 것을 파괴할 수 있다는 점을 강조한다. 이는 모든 긍정적인 기여를 파괴하는 동시에 반달들이 수백 개의 버림받은 계정을 사용하는 것을 허용한다.내 비난이 가혹하게 느껴진다면 미안하지만, 나는 부적절한 기사를 태그하기 위해 기사 네임스페이스에서 많은 일을 하는데, 당신의 비난은 내게 특히 모욕적인 느낌이 든다.니힐트레스^(t.c.s) 17:31, 2007년 5월 12일 (UTC)[응답하라]

나는 최근 변경사항의 상위 20개 애논 수정사항을 살펴보았다.나는 그들 중 5명을 죽였다; 나머지 15명은 괜찮아 보였고, 대부분은 실제로 건설적이었다.If you block all anons, the vandals are likely to continue by registering usernames (making them even harder to stop), and the constructive edits are more likely to stop. (For reference: [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21]). --ais523 17:38, 12 May 2007 (UTC)

그에 비해 최근 변경에서 비아논이 편집한 상위 20개 중 절반 정도만이 기사 공간에 대한 것이었으며, 스팸링크를 추가하는 것이 단 하나였지만 비교했을 때(동일한 종류의 변화였다) 아논의 편집 내용만큼 유용했다.그 사이에 aon은 공공 기물 파손을 내 사용자 토크 페이지로 되돌렸다.모든 애논이 금지되었다면 지금쯤 백과사전은 별로 없을 것 같다.(그런데, 애논 편집을 금지한 또 다른 위키백과인 시티즌디움을 위키백과와 비교하는 것이 좋을 것 같다.) --ais523 17:45, 2007년 5월 12일 (UTC)

시티즌디움의 문제: 1) 그들은 처음부터 시작하기를 원한다 - 6년 전 2) 위키피디아는 이미 100%에 가까운 "시장 점유율" 3) 그들의 콘텐츠에 대한 저작권을 어떻게 할 것인가에 대해 의심스러운 생각을 가지고 있는 것 같다.내가 원하는 것은 2007년 위키피디아에서 반달리즘(확정된 이메일 주소의 등록)과 그것에 수반되는 모든 것(눈을 맞추는 것 이상의 것)을 뺀 것이다.M:에 따르면, 나는 이 문제를 논할 이유가 없다고 생각한다.재단 문제, 이 정책은 논쟁의 여지가 없다.내가 말하는 편집자의 동의는 다음과 같다. - 우리는 토론을 수반하지 않는 방법을 사용할 것이다. --SeansPotato Business 18:05, 2007년 5월 12일 (UTC)[응답]

그러면 완벽하게 자격이 주어지는 포크 위키백과 프로젝트에서 데이터베이스 덤프를 제공하여 그렇게 할 수 있도록 한다. -할로 01:47, 2007년 5월 23일 (UTC)[응답]

우리의 핵심 목표는 누구나 편집할 수 있는 무료 백과사전이 되는 것이다.무슨 말인가 하면 기본적으로 모든 기사에 반제어를 강제한다는 것, 즉 '누구나'가 편집하는 것을 막는 사실이다.우리의 강점은 어디서든 오타를 고치거나 사실을 몇 초 안에 고칠 수 있다는 것이다.그 사실이 우리의 약점이 되는 것을 막는 것은 모두에게 달려있다.

조직화에 대해 이야기하므로, 위키피디아를 만드십시오.의무 등록 또는 유사한 에세이, 그리고 찾을 수 있는 한 많은 페이지(마을 펌프, 게시판, 헬프 데스크, 위키피디아 제목 등)에서 링크하여 커뮤니티의 동의 여부를 확인한다.(항상 반달들에게 제2의 기회를 주는 것에 대해 문제를 가져온) 판을 제한하자는 생각에 반대하기 때문에, 만약 내가 그러한 에세이를 만든다면, 그것은 하나의 논점으로 여겨질 것이다.하지만, 그것이 우리의 많은 문제들에 대한 해결책이라고 믿는다면, 우리가 당신이 그 토론을 시작하는 것을 막지 못하게 하라. -- 레이브루조 18:00, 2007년 5월 12일 (UTC)[응답하라]

Seans Potter Business, 만약 당신이 나의 기여를 조금 더 자세히 본다면 당신은 내가 그 파괴적인 문제에 직접적으로 영향을 받는다는 것을 알게 될 것이다.나 또한 기사 공간에서 많은 일을 했고, 비록 내가 하지 않았더라도 내 의견은 그대로 타당하다.^High_InBC^{(Need help? Ask me)} 2007년 5월 12일 17:59 (UTC)[응답하라]

익명의 편집이 모든 위키미디어 프로젝트의 기초가 되는 것 외에도, 보다 현실적인 문제를 고려하라: 등록이 필요했다면, 모든 반달인들은 단지 반달리즘을 위한 계정 등록을 시작할 것이다.크림펫 (토크) 2007년 5월 12일 (UTC) 18:10 [응답]

나는 또한 애논 편집의 폐지에 반대한다.기사 작가로서는 오타를 수정하고 편집본을 복사하는 데 있어서 애논 편집의 장점을 직접 본다.물론 나는 스팸 EL과 반달리즘도 보지만, 그들이 IP에서 왔을 때 그것들은 고르고 되돌리는 것이 더 쉽다는 것을 인정한다.나의 감시목록에는 IP 기고가 눈에 띄고 그것을 살펴보는 것을 요점으로 삼는다.만약 모든 사람들이 등록을 해야 한다면, 더 면밀한 조사를 위해 이러한 잠재적 공공 기물 파손 편집물을 분리하는 것은 더 어려울 것이다.Agne^Cheese/^Wine18:14, 2007년 5월 12일 (UTC)[응답]

아논은 위키백과 편집자의 가장 큰 그룹이며, IIRC는 대부분의 위키백과 콘텐츠를 생산한다.부득이하게 선택한다면, 나는 먼저 등록된 모든 사용자를 금지할 것이다. ;;-) --김브루닝 18:25, 2007년 5월 12일 (UTC) (Anons도 대부분의 위키백과 혼란을 생산하지만, 그것이 당신이 가장 큰 편집자 그룹이라는 이유로 얻는 것이다.)[응답하라]

지지자들을 모아 더 많은 토론에 박차를 가하라: 물론, 계속하라.로그아웃하여 의도적으로 기사에 기물 파손을 유발하여 요점을 입증하십시오.과거 이용자의 유익한 기여에 관계없이, IP가 되든 등록되든 간에, 내가 다른 모든 반달들을 추구하듯이, 나는 당신을 추구할 것이다.훌륭한 편집자들은 그들의 우려를 제기하는 방법을 알고 있고, 의도적인 반달리즘은 방법이 아니다. --보시 (토크;; 기여) 19:26, 2007년 5월 12일 (UTC)[응답]

이 논의는 오랫동안 진행되어 왔다.하지만, 공공 기물 파손에 대한 또 다른 대안이 있다: 반보호.반보호에 관한 가이드라인을 조금 느슨하게 하면 확실히 많은 반달리즘을 막을 수 있을 것이다.확실히 완성된 것만큼 좋은 모든 기사들은 반비례로 보호될 수 있다.사실상 그 기사들의 모든 변화는 공공 기물 파손으로 이루어져 있다.매일 한 번 이상 파손된 몇 가지 기사(애플, 로즈, 피사의 사탑 등)에 대해 이를 시도해 보았는데 많은 도움이 된다.조잔 08:36, 2007년 5월 13일 (UTC)[응답]

애논에 의한 선의의 편집(필수적으로 가장 좋은 편집의 질은 아니지만)이 많이 있으며, 나는 내용이 매우 구하기 어렵다고 생각하므로 어떤 종류의 선의의 편집도 작업할 수 있고 환영받아야 한다고 생각한다.x4206 Talk Mess 17:57, 2007년 5월 13일 (UTC)[응답]

공공 기물 파손의 이유는 간단하다.누구나 편집할 수 있고 그들의 변화가 즉각적으로 진행되는 것을 볼 수 있다.일시적으로라도 세상에 영향을 미칠 수 있다는 것을 보고 싶은 사람에게 이보다 더 매력적인 것은 없다."누구나 편집할 수 있는"은 "사무실 정책"으로, 짐보 웨일스가 이것에 대해 그의 생각을 바꿀 필요가 있다는 것을 의미한다.나는 그것이 곧 일어날 것이라고 정말로 보지 않는다.

다른 옵션은 편집된 "실시간"을 즉시 실행하지 않는 것이다.한 가지 가능성은 독일어 위키백과에서 시도되고 있는 "승인된 버전"의 이 사업이지만, 나는 그 상황을 확신할 수 없다.기본적으로 "승인된 버전"이 표시되지만 편집자는 여전히 기사에 들어가 현재 버전을 마음대로 편집할 수 있다.반달들이 편집한 내용이 위키피디아에 "들어오기" 때문에 반달들을 낙담시키는 데 큰 효과가 있을지 잘 모르겠다.나는 또한 애논과 새로운 사용자들의 편집에 대한 검토를 요청했지만 소용이 없었다.또 다른 아이디어는 편집을 확인하기 위해 이메일 교환을 요구하는 것이다.이것은 반달에게 그들의 편집에 "서명"하도록 강요할 수 있지만, 사람들은 다시 한번 아논을 불편하게 하는 것에 대한 우려를 표명했다.개인적으로 나는 합법적인 편집을 하는 애논이 그들이 앞에서 무슨 일이 일어나고 있는지, 왜 일어나고 있는지를 말해주는 한, 검토나 확인을 참아내는 것이 행복할 것이라고 생각한다.그 과정이 너무 부담스러울 수는 없지만, 반달족이 위키피디아의 가치를 찾을 수 없도록 어떤 바는 필요하다.

BTW - 다른 제안이 있다.즉각적으로 편집자가 노골적인 공공 기물 파손 행위를 최소 2주 동안 금지한다.봇이 탐지할 수 있을 정도로 노골적이라면, 반달족이 활동할 때 아마 잡고 있을 것이다. --EMS Talk 01:56, 2007년 5월 14일 (UTC)[응답]

나는 IP주소가 위키백과를 편집하는 것을 막는 어떠한 제안에도 강하게 반대한다.왜? 음:

• 아논을 금지하고자 하는 대다수의 사람들은 반달 싸움을 하거나 정기적으로 감시 목록을 체크하는 사람들이며, 일반적으로 IP 기부의 가장 나쁜 면을 보는 사람들이다.그들은 선천적으로 편향되어 있다.
• IP에 의한 편집의 대부분은 정품이며, 위키피디아의 정품 컨텐츠의 대부분은 IP 주소를 이용하여 편집하는 사람들에 의한 것이었다.
• 그것은 본질적으로 언와키와 유사하며, 누가 편집을 할 수 있는지에 대한 인위적인 제한을 만든다.
• 진정한 내용보다는 반달리즘의 결실을 '보기' 쉽기 때문에 문제가 지금보다 더 심각해 보인다.

나는 또한 본질적으로 "징벌 강화"에 대해 말하는 누구와도 동의하지 않는다.이 작업은 작동하지 않음:

• 많은 진정한 편집자들이 십자포화를 맞을 것이다.
• 이미 지나치게 가혹한 금지를 조장하고 확대하는 것은 좋은 생각이 아니다.
• '사형'으로는 실생활에서 통하지 않는데, 위키백과에 왜 효과가 있을 것이라는 가정은? -할로 02:02, 2007년 5월 23일 (UTC)[응답]

또한 위키피디아의 호소와 초기 그림의 일부는 누구나 편집할 수 있다는 사실이다.계정을 등록하기 훨씬 전인 4년 전쯤 그 프로젝트를 다 읽고, 복사 등을 만지작거렸던 기억이 난다.단지 몇몇 익명의 IP가 파괴된다고 해서 모두가 그렇게 되는 것은 아니다.이 사이트에는 파괴하는 사용자 이름들도 많이 있다.Jmlk17 20:08, 2007년 5월 23일 (UTC)[응답]

애논에 의한 기물 파손에 대한 내성 감소

애논의 기사 편집을 막는 문제는 애논 편집의 대다수가 건설적이라는 점이다.그래서 그것은 잘 행동하는 다수에게 공평하지 않을 것이다.따라서 익명 IP에 대한 허용 오차를 낮추는 것이 또 다른 발상일 것이다.최종 경고가 아닌 1회 경고 후 차단할 수 있도록 한다.IP 주소가 공유되면 무고한 사람에게 계정을 만들도록 하십시오.한편, 관리자가 편집이 50개 미만인 사용자의 IP 주소를 적극적으로 추적할 수 있도록 허용한다.그렇다면 IP가 차단된 후 단지 문제를 일으키기 위해 계정을 만드는 사람이 맞는지 즉시 알 수 있다.--Kylohk 19:40, 2007년 5월 14일 (UTC)[응답]

• 강력한 지원 - 내성을 낮추는 것이 매우 필요하다.네가 거의 시작하자마자 멈추면 난 훨씬 덜 재미있을 거야.나는 또한 공공 기물 파손 방지 깃발을 편집 페이지에 추가하여 사람들이 관리자들에게 공공 기물 파손을 지적할 수 있도록 할 것을 요구해왔다.두 사람이 결합하면 반달리즘을 상당히 줄일 수 있을 것이다. --EMS Talk 20:11, 2007년 5월 14일 (UTC)[응답]
• 지원 – 주의사항 포함.확실히, 그렇게 되면 그들의 활동을 제한하고 지루한 아이들과 가벼운 장난을 치는 사람들을 멈추는 것이 더 쉬워질 것이다.나는 이것이 더 많은 블록이 수행되어 관리자의 업무량을 증가시킬 수 있다는 약간의 우려를 가지고 있다.그것은 악성 계정이 증가할 수 있는 것과 자신의 감시 목록에서 IP를 발견하는 것에 대한 아그네의 지적에 더해서이다.아드리안 M. H. 20:33, 2007년 5월 14일 (UTC)[응답]
• 지지 나도 동의한다.4개의 경고와 종종 더 많은 경고는 그 파괴자에게 너무 많은 관대함을 준다.더 빠른 블록은 재미를 더 잘 막을 수 있고, 여러 IP 사용자들도 더 빨리 할 수 있다.나는 극단적으로 노골적인 공공 기물 파손이 유용하게 될 것이며 더 빨리 중단되어야 한다고 생각하지 않는다.테스터들은 아마도 더 많은 경고를 받아야 할 것이다.레이와스92^Talk 20:30, 2007년 5월 14일 (UTC)[응답]
  • 코멘트 나는 내가 악의가 없는 테스터들에게 더 짧은 블록을 주는 것 외에 테스터와 반달족을 구별하는 것에 관심이 있는지 잘 모르겠다.두 경우 모두 사람들은 그들이 무엇을 할 수 있는지 보려고 하고 있으며, 당신이 붐을 빨리 낮출수록 더 좋다.(그러나 테스터가 신속하게 자신의 편집을 되돌리는 경우와 같이 일부 경우에는 경고 이상의 것으로 용서할 수 있으며, 또한 용서해야 한다.)워크로드에 대한 Adrian의 우려에 대해서는:이렇게 하면 파워의식을 갖기 전에 반달족을 스타일링하여 작업량을 줄이고 위키백과의 반달리즘을 게임으로 취급하기 시작할 것으로 추측된다. --EMS Talk 02:55, 2007년 5월 15일 (UTC)[응답]

코멘트 우리가 합의에 가까워지고 있는 것 같다.만약 그것이 도달된다면, 우리는 그것을 WP의 토크 페이지에 넣을 수 있을 것 같다.반달.--Kylohk 18:16, 2007년 5월 15일 (UTC)[응답]

완료. Wikipedia_talk 참조:반달리즘#레싱_the_tolerance_for_vandalism. --EMS Talk 02:37, 2007년 5월 16일 (UTC)[응답]

• 강한 반대 - 미끄러운 비탈길처럼 보이고 학대하기 쉬운 것처럼 보이며, 진실한 것을 제출하려고 애쓰는 많은 사람들이 십자포화를 맞을 것이다. 특히 "잘 먹고" 있는 사람들은 더욱 그렇다.나는 또한 익명의 진짜 편집을 하는 사람들이 공공 기물 파괴 행위를 저지르는 것과 같은 IP에서 그것을 하지 않을 것이라는 암시를 싫어한다.게다가, 그것은 24시간 동안 받을 자격이 있는 Halo 01:44, 2007년 5월 23일 (UTC)[응답]보다는 사소한 공공 기물 파손에 대해 "무정확한" 중압적인 애논-IP 블록의 지속적인 실행을 장려할 수도 있다.

당장 블록을 사용해도 별 소용이 없을 것이다.대부분의 IP 파괴는 한두 번만 하고, 차단할 때쯤이면 끝장날 것이다.Night Gyr (talk/Oy) 05:39, 2007년 5월 23일 (UTC)[응답하라]

이 정책은 내 생각으로는 결코 효과가 없을 것이다.여러 명의 사용자를 가진 익명 IP가 너무 많다.싱가포르에서 30만 명 이상의 사용자들이 어떻게 같은 IP를 공유하는지 누군가 알아채지 못했고, 누군가가 그것을 파괴하기 위해 사용하고 있었는지를 기억한다.Jmlk17 20:10, 2007년 5월 23일 (UTC)[응답하라]

지원 반달 패트롤러로서 나는 IP가 단기간 반달리즘에 매우 활발해질 것이라는 것을 알아챘다.나는 이것이 IP가 중학교에서 온 위치 때문일 수 있다고 믿는다.자, 이것은 가상적인 상황이지만, 만약 한 무리의 학생들이 영어 수업 시간에 무언가를 연구하기 위해 컴퓨터에 있다면, 셰익스피어, 자주, 구글에서 WP 페이지가 첫 번째라고 말한다.자, 이제 여러분들은 한 그룹의 학생들이 같은 페이지와 주제에 접근하게 되고, 한 학생은 여러분이 페이지를 편집할 수 있다는 것을 알게 되고, 그래서 그들은 페이지를 비우고, 제니가 바비를 이 페이지에 사랑한다고 덧붙인다.모든 학생들이 수업에서 이것을 보고 미친 듯이 편집하고 있기 때문에, 반달 공격이 우발적으로 시작된다.이 경우 IP를 감시해 같은 기사에 접속해 기물 파손을 일으킨다면 IP를 신속하게 차단하고 기물 파손 행위를 끝낼 수 있다.이것은 또 다른 질문으로 이어진다. 즉, 1시간 블록이 학교나 유사한 기관과 식별된 IP에 대해 1시간 블록이 표준이 되어야 하는가?Plm209 (토크 talk€ 기여 â count 계수) 19:04, 2007년 5월 30일 (UTC)[응답]

친구 목록 또는 활동 그룹

한 명의 사용자는 같은 관심사를 가진 친구를 가질 수 있는 자유가 주어져야 하며, 이는 궁극적으로 점점 더 많은 정보가 모일수록 위키의 폭을 넓혀줄 것이다.

친구 목록은 사용자 그룹이 공유 중인 기사/주제에 대한 정보를 공유할 때 도움이 될 수 있을 것으로 보인다.친구의 코너를 시작하는 것에 대한 나의 큰 우려는 사용자들이 위키피디아를 무수한 주제에 대한 정보를 수집하는 전용 사이트가 아니라 마이스페이스나 페이스북과 같은 소셜 네트워킹 사이트로 사용하기 시작할 것이라는 것이다.이론상으로는 좋은 생각이지만 실제론 나쁠 것 같다.Plm209 (토크 talk€ 기여 â count 카운트) 18:53, 2007년 5월 30일 (UTC)[응답]

위키피디아 제목을 사용해 보십시오.킬러치와와^?!? 11:08, 2007년 5월 31일 (UTC)[응답]

주제 토크라는 제목이 붙은 또 다른 탭일 수도 있다.그러면 당신은 기사 정확성이나 중립성 보다는 기사 주제에 대해 일반적인 논쟁을 할 수 있다.워드호그 22:51, 2007년 6월 6일 (UTC)[응답하라]

이미지 줌

나는 이미지 페이지와 관련된 두 가지 문제가 있다. 캡션과 체커보드 배경.이미지 설명을 제공하려는 시도가 있었지만 최종 사용자에게 잘 제공되지 않음(일반적으로 유지 관리 자료에 묻혀 있음)은 좋지 않음.

이미지 페이지가 이미지 편집기인 것처럼 체커보드가 표시된다.편집자들은 투명한 배경을 나타내기 위해 체커보드를 보여준다.최종 사용자는 편집자의 이미지 보기를 원하지 않는다.

사람들은 이미지를 확대해야 하는데, 특히 작은 텍스트 레이블이 있는 플롯을 확대해야 한다.그것이 html의 약점이며, 기술 콘텐츠가 pdf로 게재되는 경향이 있는 한 가지 이유다.이 html의 한계를 극복하고 최종 사용자에게 일반적인 높은 품질의 위키백과에 버금가는 자막과 ane을 포함한 고품질 이미지 줌 기능을 제공하자.2007년 6월 2일(UTC) 19:42, 응답하라

웹 정책

편집자들이 "사용자 대화"로 쓴 글이 웹에 뜬다는 글을 놓쳤을까?거기에 내 댓글이 올라와서 깜짝 놀랐어.알레테 02:12, 2007년 6월 3일 (UTC)[응답]

음... 위키피디아는 웹 상에 있고, 여기에 쓰는 모든 것이 온라인에 접속되어 있어, 아마도 영원히, 삭제하더라도 말이야.지프데이 (토크) 02:35, 2007년 6월 3일 (UTC)[응답]

템플릿 병합:백로그, 템플릿:관리백로그 및 템플릿:Noadminbacklog

템플릿 병합 제안:백로그, 템플릿:관리백로그, 템플릿:Noadminbacklog.템플릿:위의 3가지 템플릿의 기능을 하나의 템플릿으로 결합할 수 있도록 파서 함수를 사용하도록 백로그를 개정할 것이다.템플릿의 "경험이 풍부한 편집자"도 바꿀 수 있을 것이다.다른 일에 밀리다.이에 대한 초안은 User:펑피카/드래프트/백로그.펑피카 17:47, 2007년 6월 2일 (UTC)[응답]

나는 이 제안을 받아들이는 것으로 침묵을 받아들이고 있다.나는 지금 합병을 시작할 것이다.펑피카 21:07, 2007년 6월 3일 (UTC)[응답]

페이지에서 편집자를 제외하는 규칙을 설정하십시오.

문제 편집자를 상대하기 위한 정책과 절차가 많지만 각 편집자는 다소 시간이 많이 걸린다는 단점이 있다.현재, 일반 상대성 기사에 실린 우리 중 몇몇은 매우 POV와 파괴적인 편집자를 다루고 있다.이 편집자는 GR이 "거품"이며 그 기사가 "사실"을 반영해야 한다고 생각한다.현재 그는 업무방해로 막히는 길을 걷고 있지만, 기사 토크페이지에 그 사람에 대한 동의가 올라올 수 있다면 좋겠다는 생각이 든다.

나는 그것을 뭐라고 불러야 할지, 어쩌면 "배제하려는 움직임"이나 "편집장 부인에 대한 거부"라고 불러야 할지 모르겠지만, 그 생각은 기사의 편집자들이 특별히 나쁜 편집자가 기사를 편집하지 못하도록 요청할 수 있다는 것이다.만약 성립한다면, 그것은 무엇인가가 되어야 한다.

• 관리자가 로그오프해야 함.
• 기사 편집자의 강력한 의견 일치를 요구하여 (예를 들어 기사를 작업하거나 시청하는 기성 편집자의 75% 또는 80% 등)
• 쿼럼 요구사항(예: 10명 이상의 편집자가 발의에 대한 의견을 표명함)

움직임/요청이 승인되면 편집자의 추가 편집은 즉시 차단되며, 두 개 이상의 기사에서 제외될 경우 RfAr의 근거가 될 수 있다.

내가 열거한 요건의 목적은 상투적인 사람이 이 메커니즘을 통해 기사를 통제하는 것을 어렵게 만드는 것이다.다수의 편집자의 광범위한 합의는 IMO 조치의 명확한 원인이 없는 한 도출하기 힘들어야 하지만, 관리자 승인은 그러한 조치에 대한 추가적인 건전성 점검이다.그렇다고 해서 (검토 절차 등) 다른 견제와 균형이 성립될 수 없다는 것은 아니다. --EMS Talk 02:35, 2007년 6월 4일 (UTC)[응답]

이것을 기사 금지라고 하며, 경우에 따라서는 이미 제정되어 있다.그러나 기사 배부 결정은 관련 기사를 편집하는 사람들에게 쉬어서는 안 된다.일당이 이걸로 기사를 통제하기는 어려울 겁니다, 네.그러나 기사의 편집자 대부분이 X에 대해 어느 정도 견해를 갖고 있다면, 기사가 다른 견해에 치우친다고 불평하는 편집자가 정당한 이유 없이 기사에서 제외되는 경우를 상상하기 쉬울 것이다.또한, 기사 금지 조항은 마지막 수단이 되어야 하며, 블록이 비효과적인 것으로 판명된 후에 생겨나야 한다. -아마코프 무! 02:56, 2007년 6월 4일 (UTC)[응답하라.

커뮤니티 기사 금지는 경우에 따라서는 합리적인 생각처럼 보인다(일반 상대성 이론은 매우 좋은 본보기가 된다).문제의 편집자를 커뮤니티 게시판에서 금지하도록 제안하는 것은 어떨까?2007루드 07:45, 2007년 6월 4일 (UTC)[응답]

아마르코프와 동의하라 - 이것은 이미 선택사항이며, 권한이 없는 편집자들이 결정하는 것에 중점을 두고 있다.그러나 나는 문제의 편집자가 프로젝트를 그만두지 않고 이 제재가 시행된 사례(커뮤니티나 행정고시판의 승인 여부)는 전혀 알지 못한다.Addhoc 10:41, 2007년 6월 4일 (UTC)[응답]

페이지 기록 "이전" 및 "다음"

페이지 기록의 앞뒤 페이징 링크는 이전 편집의 경우 이전 편집의 경우, 이전 편집의 경우 다음 편집의 경우 등 혼란스러울 정도로 뒤로 이동한다.이러한 항목을 사용자 기여도와 같이 최신 및 이전 항목으로 변경하지 않을 이유가 있는가?--Fyrlander 16:51, 2007년 6월 4일 (UTC)[응답]

비록 내가 이것을 정말로 도울 수 있는 사람은 아니지만, 나는 강력하게 동의한다.레이와스92^{TalkReview me} 20:21, 2007년 6월 4일 (UTC)[응답]

미디어위키 대화 참조:그 다음, 그들은 이 문제를 정확하게 다룬다.Night Gyr (talk/Oy) 20:29, 2007년 6월 4일 (UTC)[응답하라]

4777 Night Gyr (토크/Oy) 20:30, 2007년 6월 4일 (UTC)[응답하라]

문제:섹션 이름 바꾸기 브레이크 링크 - 해결 방법?

그냥 생각 좀 해 봐...WP:GTL은 "섹션 이름을 변경하면 링크가 끊기므로(퍼멀링크의 효용성을 강조함) 이미 설정된 섹션 이름은 변경하지 않는 것이 가장 좋다"고 말한다.그러나, 기사에 이름이 좋지 않은 섹션이 포함된 경우는 존재한다.이 문제에 대한 해결책은 <<p><a name="{1}{1}}}" id="{{1}}"{{1}}" 같은 것으로 코딩될 수 있는 {{대체 이름 Old_name}}} 같은 것으로 하면 어떨까?{{{1 ))<p><<a name="{{1}}}" id="{{1}}}"{{1}}"{{1}}}}}(여기서는 위키백과 기사 페이지에서 생성되는 것으로 관찰되는 HTML 앵커 코딩을 사용했다) -- 보라카이 빌 03:58, 2007년 6월 4일 (UTC)[응답]

섹션 이름이 제대로 지정되지 않은 경우 수신 링크를 그에 따라 업데이트해야 한다.불행히도, 한 구역으로 연결되는 모든 링크를 찾는데 시간이 걸린다.편집자들은 수신되는 링크를 기록하기 위해 HTML 코멘트를 사용하는 것으로 알려져 있지만, 나는 그것이 이루어지는 것을 본 적이 없다.하지만 우리는 기사 섹션에 있는 템플릿을 사용해서는 안 될 것이다.구간 이름이 다시 바뀌면 어떻게 되는 겁니까?2007년 6월 4일 (UTC) 23:27 (응답)

1. 마치 내가 WP로부터 인용한 지침에 대해 이의를 제기하는 것처럼 들린다.GTL. 2. 섹션 이름을 7번 더 바꾸면 "{대체 이름 Old_name}"의 인스턴스 7개를 더 추가하거나 추가하지 않을 수 있다. 3.나는 "우리는 아마도 기사 섹션에 템플릿을 사용해서는 안 될 것이다." -- 보라카이 빌 23:40, 2007년 6월 4일 (UTC)[답답답]

위키다타

누구 어디 있는지 아는 사람 있어?위키다타는 현재 논의되고 있는가?이 모든 링크들은 2006년 6월 이후 손대지 않은 것으로 보이며, 위키다타-l 메일링 리스트는 완전히 침묵하고 있다.오메가위키는 공식적인 위키미디어 프로젝트가 아니다(?). 그런데 왜 오메가위키는 우리의 모든 자매 프로젝트를 메인 페이지 하단에 나열하는가?) 하지만 위키다타는 재단 사이트에서도 언급되지 않는다... --Quidity 19:52, 2007년 6월 4일 (UTC)[응답]