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

시작/토크 페이지의 템플릿 편집 방법

새로운 사용자들을 돕기 위해 매우 밀도가 높은 페이지들에 새로운 사용자들을 환영하는 것에 대한 토론이 파운데이션-l 메일링 리스트에서 제기되었다.내가 간접적으로 꺼낸 요점은 우리가 대화 페이지와 편집에 도움을 주는 봇이나 AWB가 추가된 템플릿을 가지고 있지 않다는 것이다.대신, 우리는 프로젝트와 클래스, et.al 템플릿으로 페이지를 붙여넣는다.사용자 대화 페이지뿐만 아니라 시작 템플릿을 대화 페이지로 수정하고 다른 대화 페이지를 할 때 즉흥적으로 추가할 수 있는 사람이 있는가?키건 (토크) 06:29, 2011년 6월 7일 (UTC)[응답]

{{hello world}}}}을(를) 납치해 이런 목적으로 조금 개조했다.몇 년 전부터 존재해온 일반 {{토크 페이지} 템플릿도 있다.하지만 그다지 우호적이지 않다. --MZMcBride (대화) 06:39, 2011년 6월 7일 (UTC)[응답]

{{talk 페이지}}}은(는) 몇 개의 유용한 링크를 포함하고 있지만 압도적이지는 않은 토크 페이지들의 머리글이라고 생각한다.왜 당신이 그것보다 기본 {{hello world}}템플릿을 더 선호하는지 이해가 안 가.{{Welcomeg}}} 같은 혐오감을 더할 생각은 없었지?나는 그것에 대해 가능한 한 강력하게 반대할 것이다.요에닛 (대화) 08:36, 2011년 6월 7일 (UTC)[응답]

{{talk page}}} 템플릿은 여기서 필요성을 다루는 데 끔찍하다. 즉, 완전히 새로운 사용자에게 토크 페이지가 무엇을 위한 것인지 알려준다.그것이 무엇을 위한 것인지 알고 있는 우리들에게조차, 그것은 아직 또 다른 갈색 상자 대 무시로, 확실히 눈에 띄지 않는다.

나는, BTW, 이러한 제안된 변경사항들이 논의 없이 되돌아가고 있다는 것을 주목한다.매력적이다.

제임스 F. (토크) 09:09, 2011년 6월 7일 (UTC)[응답]

표준 환영 템플릿을 추가하는 것은 토크 페이지조차 언급하지 않기 때문에 더 나쁘다.그것이 새로운 사용자들에게 어떻게 도움이 될 수 있을까?나는 토크 페이지 위에 있는 대체 템플릿에 대해 열려있겠지만 {{헬로 월드}}는 그렇지 않다.요에닛(토크)09:17, 2011년 6월 7일 (UTC)[응답]

(부록)또, 왜 그 되돌리기에 대해 징징거리는 거야?이유는 편집 요약에 제시되어 있으며, 위키백과에 따른 표준 관행이다.볼드, 리턴, 사이클 토론.요에닛 (대화) 09:26, 2011년 6월 7일 (UTC)[응답]

{{토크헤더}}(그것을 위해 - {{토크 페이지는 리디렉션) 헤더가 있음. Foo 기사의 개선 사항을 논의하기 위한 토크 페이지다.그리고 정보 목록의 첫 번째 항목은 기사 주제에 대한 일반적인 토론을 위한 포럼이 아니다.그것은 주요 요구사항을 포괄하는 것 같다.눈길을 끄는 중요성에 대해 말하자면, 곧 우리는 새로운 사용자들을 위해 CSS를 추가할 수 있을 것이다. 그래서 우리는 이 모든 것을 더 크고 그들만을 위해 더 눈길을 끌 수 있을 것이다.그 사이 우리는 원하면 템플릿에 파라미터를 추가해 놓칠 수 없어. PS 숙련된 사용자들의 눈을 통해 그것을 보는 것은 아마도 그 내용을 찾기 위해 그 갈색 상자를 무시하는 데 익숙해졌기 때문에 그것의 가시성에 대한 최선의 판단은 아닐 것이다.Rd232 09:35, 2011년 6월 7일 (UTC)[응답]

나는 또한 어떤 종류의 대화 페이지의 템플릿을 추가하는 것이 사용자들에게 알리기 위해 이루어져야 한다고 생각한다. 그리고 만약 우리가 그것을 표준으로 했다면 우리는 그것을 메타에 구현하고 편집으로 페이지에 수동으로 추가할 필요 없이 정적이 되도록 할 수 있을 것이다.IMO 우리는 그들에게 싸우지 말라고 말하기 위해 무언가 잘못될 때까지 기다리지 말아야 한다.내 의견만. --쿠미오코(토크) 23:27, 2011년 6월 7일 (UTC)[응답]

나도 동의해.이 작업은 토크 페이지의 미디어위키 코드에 입력될 수 있는데, 이는 "편집"을 클릭할 때 나타나는 경고와 유사하지만, 대신 토크 페이지 자체에서 정적이 될 수 있다.키건 (토크) 04:58, 2011년 6월 8일 (UTC)[응답]

미디어위키:내가 생각하는 토크 페이지헤더는 모든 토크 페이지에 표시될 것이다.mw:확장:PageNotice(T6469에서 참조, 공간별 시트네이터)는 더 많은 제어 기능을 제공하지만 현재 설치되지 않았다.Rd232 10:14, 2011년 6월 9일 (UTC)[응답]

{{Talk 헤더}}}에 "Whew to Wikipedia?어서 오십시오!질문을 하고 답을 얻으시오."페이지마다 무엇이 더 필요한가?WhatamIdoing (대화) 01:46, 2011년 6월 10일 (UTC)[응답]

사용자 페이지

여기에 새로운 IM으로 누락된 것이 있으면 알려주십시오. 그러나 모든 사용자 페이지를 구성하여 사용자 페이지가 아니면 다른 사람이 수정할 수 없도록 해야 하는가?이게 잘 될까?헤이츠메22 (대화) 22:06, 2011년 6월 9일 (UTC)[응답]

그렇지는 않다.때때로 사람들은 그들의 사용자 페이지에 나쁜 카테고리를 남기거나, 삭제된 파일, 레드링크 등을 남긴다.그러한 경우 누군가가 유지관리 목적으로 편집하기를 원할 수 있다.누군가 공공 기물 파손/스팸으로 사용자 페이지를 만들 수도 있고, 삭제 태그를 지정해야 할 수도 있을 것이다(또는 어딘가에서 보고될 수도 있을 것이다).어쨌든, 만약 당신의 사용자 페이지가 파괴되고 있다면 당신은 한동안 편집으로부터 보호될 것을 요청할 수 있다.Ajraddatz (토크) 23:36, 2011년 6월 9일 (UTC)[응답]

기사 작성을 위한 샌드박스로도 사용하는 사람도 있고, 다른 사람을 초대해 도움을 주거나 페이지를 옮겨야 할 수도 있다.그건 정말 "네 것"이 아니야.WhatamIdoing (대화) 01:58, 2011년 6월 10일 (UTC)[응답]

위키프로젝트 창조의 제안

안녕하십니까, 현재 위키프로젝트 창간기사에 흥미가 있으실 겁니다.토론 주제는 기사 마법사의 Userspace 초안 옵션을 제거, 재배치 또는 교체할지 여부에 관한 것이다.토론은 여기에 있다.감사합니다, 알파 쿼드런트 23:08, 2011년 6월 9일 (UTC)[응답]

OTRS 알림판

위키미디어 커먼즈에는 OTRS 구성원들이 다른 사용자들이 묻는 질문에 대답할 수 있는 공지사항 게시판이 있다.(커먼즈:공용:OTRS/공지판)이것의 장점은 사용자가 티켓과 관련된 질문에 더 빨리 대답할 수 있다는 것이다.나는 위키피디아에서 같은 것을 가지고 있으면 그만큼 유용할 것이라고 생각한다.MorganKevinJ^(talk) 16:13, 2011년 5월 27일 (UTC)[응답]

• 강력히 지지하다.과거에도 다른 유저들과 그런 게시판의 필요성에 대해 논의한 적이 있는데, 누군가가 솔선수범하여 제안하는 것을 보게 되어 기쁘다. :) OTRS 티켓에 대한 피드백을 받는 것이 훨씬 간단한 문제일 것이다. --Moonedgirl 16:28, 2011년 5월 27일 (UTC)[응답]
• 강한 지지 - 나도 마찬가지야.템플릿에 추가되었는지도 확인해야 한다.게시판 링크. --쿠미오코(토크) 16:51, 2011년 5월 27일 (UTC)[응답]
• 강력한 지원 - 이것은 IRC에 뛰어드는 현재의 시스템을 능가한다. 누군가가 접근하기를 바라고, OTRS에 접속할 수 있는 사람을 구하지만, 내 질문에 대답할 수 없는 사람을 구한다. OTRS 채널에 가라는 말을 듣고, 거기서 그 방이 영구적인 침묵을 깨기 위해 30분을 기다린 후, 마지막으로 PMing을 한다.키건은 그 대답을 위해 (키건은 내가 다른 모든 단계를 시도한 후에만 나타난다, 나는 다크 마법을 탓한다.)스벤망구아르화?17:06,2011년 5월 27일 (UTC)[응답]
  • 주 게시판이 올라가기 전에 사용자가 해당 게시판을 사용하여 OTRS 액세스를 요청할 수 있는지 여부를 결정해야 한다.그 대답은 처음부터 비밀로 해야 한다.개인적으로, 나는 사용자들이 이 게시판에서 OTRS 접근을 요청할 수 있도록 허용하는 것에 찬성하지 않는다. 다른 유용한 자원을 방해할 수 있기 때문이다.스벤망구아르화?17:17, 2011년 5월 27일 (UTC)[응답]
    • 알림판에 링크를 추가해 메타:사용자가 액세스를 요청해야 하는 OTRS/자원봉사자.MorganKevinJ^(talk) 03:26, 2011년 5월 28일 (UTC)[응답]
    • OTRS가 '글로벌' 시스템이고 재단이 관리하는 시스템인 점을 감안하면 엔위키 커뮤니티가 이용자가 접근권을 요구할 수 있는 곳을 결정할 처지는 아니라고 본다.미스터 지만 03:33, 2011년 5월 28일 (UTC)[응답]
    • OTRS 액세스는 여기에서 요청할 수 없어야 한다.Z-man이 말했듯이, 그것은 세계적인 것이고, 그것을 지역적 차원으로 가져갈 필요는 없다.Ajraddatz (토크) 03:50, 2011년 5월 28일 (UTC)[응답]
      • 동의한다. 자원 봉사 OTRS 관리자들은 이미 제도가 마련되어 있고, 그것을 바꾸려는 결정은 중앙에서 이루어져야 한다. --Moonedgirl 22:53, 2011년 5월 28일 (UTC)[응답]
• 지원 - 좋은 생각, 좋은 생각이기 때문에 반드시 존재해야 한다고 생각하는 것 중 하나.밀본원 (대화) 2011년 5월 27일 (UTC) 17:21 [응답]
• 지지하다.이런 식으로 조직하는 게 훨씬 낫지Ajraddatz (토크) 20:52, 2011년 5월 27일 (UTC)[응답]
• 지원, 현행 제도보다 훨씬 효율적일 것, 좋은 생각. 둠가제(토크) 22:43, 2011년 5월 27일 (UTC)[응답]
• 지원이 더 잘 되다.또한 여기서 사용자 공간에서 시작하십시오.~~EBE123~13:19, 2011년 5월 28일 (UTC)[응답]
• 질문:OTRS는 그것에 대해 어떻게 생각하는가?— 아서 루빈 (대화) 22:40, 2011년 5월 28일 (UTC)[응답]

• 네가 누구를 말하는지에 달렸어.나는 OTRS 자원 봉사자인데, 정말 좋아. :) OTRS 관리자는 아니지만, 이미 Commons에 이사회가 있는 것을 보니, 왜 그들이 그것에 문제가 있는지 상상이 안 가. --Moonedgirl 22:53, 2011년 5월 28일 (UTC)[응답]

수많은 하원과 엔위키 허가증을 취급하는 OTRS 자원 봉사자로서, 나의 유일한 걱정은 내가 보통 하원에 있으면서 그곳에서 OTRS 안내판을 보는 것이다.여기 와서 변화를 확인해야겠어.또한 파일의 미러링으로 실제 Commons에서 파일에 대한 OTRS 질문을 받게 되는 혼동을 볼 수 있다.만약 그러한 파일에 태그를 붙인 OTRS 자원봉사자가 Commons에만 참여한다면, 글쎄, 그들은 그들의 관점에서 그것에 대한 어떤 정보도 제공하지 않을 것이다.– Adrignolatalk 14:48, 2011년 5월 30일 (UTC)[응답]

나는 너의 게시판으로 부드럽게 리디렉션하는 것이 완벽할 것이다;너희들은 정말 저기에 있다. :D 그러나 만약 게시판이 다른 이슈들도 다룬다면, 그것은 문제가 될 수 있다.:/ --Moonedgirl 00:41, 2011년 5월 31일 (UTC)[응답]

• 위키백과:OTRS 알림판은 위키피디아에서 삭제 대상으로 지정되었다.삭제/Wikipedia용 miscellany:OTRS 알림판.쿠나드 (대화) 00:26, 2011년 5월 30일 (UTC)[응답]
• 강한 반대 그 페이지는 공개적이고 ORT가 공개되지 않는 데는 그럴만한 이유가 있다!삭제 논의 내용만 보십시오.--Müdigkeit (대화) 19:00, 2011년 5월 30일 (UTC)[응답]

• 공용:공용:그럼에도 불구하고 OTRS/Noticeboard는 약 2년 동안 잘 관리되어 왔다.:) 삭제 토론에서도 다소 반대되는 부분이 있긴 하지만 상당히 많은 지지를 받고 있다. --Moonedgirl 00:34, 2011년 5월 31일 (UTC)[응답]

• 나는 또한 이것이 근본적으로 다를 것이라고 생각한다. 삭제하기 위한 주요 준비사항은 비편집자를 대상으로 하고 비공개 데이터를 처리하는 것이었다.하원 위원회를 보면 편집자를 대상으로 하는 것 같은데, 거기에 비공시적인 자료가 게시된 것은 보이지 않는다.^Avic_ennasis @ 18:12, 27 Iyar 5771 / 2011년 5월 31일 (UTC)

• 지원이 좋은 생각인 것 같다 - 일부 편집자들은 IRC 채널에서 사람들을 괴롭히는 번거로움을 덜 것이다. :-) @ 18:12, 27 Iyar 5771 / 2011년 5월 31일 (UTC)
• 지원 – 확실히 좋은 생각인 것 같다.—mc10 (t/c) 04:10, 2011년 6월 2일 (UTC)[응답]
• 그것이 일이 더 효율적으로 이루어질 수 있다는 것을 의미한다면 지원하라.—제임스 • 오후 10:14pm • 12:14, 2011년 6월 2일 (UTC)[응답]
• 지원 그러나 사람들이 그것을 더 잘 사용하기를 원한다면 옛 IRC를 유지해야 한다고 생각한다.
• 지지하다.돌보는 사람이 충분한 한 왜 나쁠지 모르겠다.르만 08:40, 2011년 6월 9일 (UTC)[응답]

참고. 삭제 논의에서 주요 쟁점은 원래 초안 문구라는 점을 명확히 하였는데, 이는 지지자들이 주로 구상했던 실제 사용 및 안전장치와 비교했을 때 극히 광범위하고 제한되지 않았다.나는 이사회의 머리글자를 바꿔서 이것들을 허용했는데, 지금은 아마 안전할 것이다.가능한 한 문구에 대해 세심한 검토를 거친 문구와 심각한 문제에 대한 가장 가능성이 높은 경로가 설명되어 있는지 확인하기 위해 문구를 요청하였다.FT2 09:11, 2011년 6월 10일 (UTC)[응답]

back to top

모든 섹션의 시작과 끝에 있는 bac to top 버튼은 특히 긴 기사를 항해하는 데 유용할 것이다.생각하나?헤이츠메22 (대화) 15:18, 2011년 6월 9일 (UTC)[응답]

이 페이지에서는 "홈" 버튼이 완벽하게 작동한다.캄발라체로 (대화) 15:25, 2011년 6월 9일 (UTC)[응답]

얼마 전에 비슷한 얘기를 꺼냈어(위키피디아 토크:헬프 데스크/아카이브 9#'위쪽으로 스킵' 버튼)과 나는 그러한 추가를 지지한다.야마구치 도시오(토크) 15:31, 2011년 6월 9일 (UTC)[응답]

스크립트로 구현하기 쉬우므로 이 기능을 사용하기로 선택한 사용자가 직접 설치할 수 있다.게리 킹 (토크 · 스크립트) 2011년 6월 9일 (UTC) 19:53[응답]

무엇보다도, 나는 영어에 몇 번의 실수가 있었다는 것을 알았던 것처럼, 이것의 시작자가 영어를 모국어로 말하는지 궁금하다 - 그것은 "Back to Top"으로 향했어야 했다. (혹은 그 사람이 단지 피곤했을 수도 있다.)그만한 것 - 모든 웹 브라우저가 아니더라도 대부분의 웹 브라우저를 사용하여 페이지 맨 위의 왼쪽 상단 모서리에 있는 두 개의 화살표 키로 이동할 수 있다는 점을 지적하고 싶다.뒤로 가리키는 화살표를 클릭하면 하고 싶은 일을 이룰 수 있을 것 같다.ACEOREVIVEED (토크) 20:21, 2011년 6월 9일 (UTC)[응답]

목차를 클릭하여 원하는 위치에 도달했다면 그럴 것이다. 그러나 아래로 스크롤했다면 다시 위로 스크롤해야 할 것이다.피터 잭슨 (토크) 2011년 6월 10일 (UTC) 10시 13분[응답]

• 반대 키보드에 "홈" 버튼이 있는 데는 이유가 있다.요에닛(토크) 11시 2분, 2011년 6월 10일 (UTC)[응답]
• 키보드의 "Home" 및 "End" 버튼을 사용하는 코멘트가 잘 작동한다.그러나, 일관성을 위해 "아래로 미끄러짐" 버튼을 제거해야 한다.버튼이 하나 있지만 다른 버튼이 아닌 버튼은 불완전한 구현으로 나타나며, 모두 함께 완료하거나 제거해야 한다.야마구치 도시오 (토크) 11시 13분, 2011년 6월 10일 (UTC)[응답]
  • "아래로 스킵" 버튼이 없다.일부 페이지(이 페이지와 같은 페이지)는 다음과 같이 구현한다.[[#footer Skip to bottom]]링크. 이것은 실제로 MediaWiki 인터페이스와 관련이 없다.—Tim Pierce (talk) 11:27, 2011년 6월 10일 (UTC)[응답]
    • 그리고 그것이 마을 펌프 페이지에 올라 있는 이유는 사람들이 전형적으로 최근의 토론이 무엇인지 보고 싶어하기 때문이다.게리 킹 (토크 · 대본) 17:27, 2011년 6월 10일 (UTC)[응답]

대화 페이지 메시지의 전자 메일 옵션에 대한 기본값을 전환하십시오.

나는 그 통지가 마음에 들지만, 몇몇 사람들은 그것을 원하지 않는 것에 대해 많은 논의를 해왔다.내가 보기에도 차단된 모든 계정에 그것이 필요하지 않을 것 같아서 나는 추천을 하고 싶다.나는 우리가 기본적으로 그것을 끄고 사용자들과 편집자들이 그들이 원하는 것을 더 많이 선택하도록 하는 것을 추천한다.

막혔다고 고백하지만 EME 알림을 끌 수 없어 이틀에 한 번씩 "쓸데없는" 메시지를 받고 있다는 위키피디아와 떨어진 곳에서 이 내용을 공개 토론하는 것을 듣고 제출하기로 했다. --쿠미오코(토크) 17:45, 2011년 6월 9일 (UTC)[응답]

나는 이것들이 결항했어야 한다는 것에 동의하지만, 그 배는 이미 출항했다.그런데 왜 이 사람은 이메일 알림을 끌 수 없는 걸까?스페셜에 있다.선호도.–xeno^talk 17:47, 2011년 6월 9일 (UTC)[응답]

음, 배는 항상 새로운 방향을 잡을 수 있고 항로를 바꿀 수 있지만 두 번째 지점에서는 진실이다.금지되거나 차단된 사람(예: 반달리즘이나 삭푸페트리)이 그렇게 할 수 있을까? --쿠미오코 (토크) 17:50, 2011년 6월 9일 (UTC)[응답]

차단된 사용자는 여전히 계정 기본 설정을 변경할 수 있다.암호를 '스캔'하면 알림 e-메일을 받으면 암호를 복구할 수 있다. --토스울프(토크) 17:55, 2011년 6월 9일(UTC)[응답]

차단된 사용자에게도 해당될 수 있음, 그렇다.그리고 금지된 것은 기술적 의미가 없다. - Jarry1250 18:21, 2011년 6월 9일 (UTC)[응답]

나는 Xeno에 동의한다...나는 그 메시지가 좀 짜증나고 '옵트인' 방식을 선호했을 텐데, 이미 실행이 되어 쉽게 탈퇴할 수 있게 되었으니 이 시점에서 바꾸면 더욱 짜증날지도 모른다.(나처럼) 탈퇴를 원하는 사람들은 이미 프리프(pref)를 바꿨는데, 이제는 알림(fref)을 좋아하는 사람들이 프리프(fref)도 바꿔야 할 것이다.28바이트 (대화) 18:04, 2011년 6월 9일 (UTC)[응답]

나는 옵트 아웃의 원래 입장에 동의하고, 이미 그 말이 도망갔다는 생각이 윤곽을 드러내고 있다.이제 와서 뭘 해도 소용없어. - Jarry1250^{[Weasel? Discuss.]} 18:21, 2011년 6월 9일 (UTC)[응답하라]

그래, 맞아. 그냥 밖에다 던져버릴까 생각했을 뿐이야.여러분 모두 하는 말이 일리가 있다. --쿠미오코(토크) 19:07, 2011년 6월 9일 (UTC)[응답]

이와 관련, 일부 위키에는 워치리스트에 대한 그러한 이메일 통지가 있지만 WP에는 그런 옵션이 없는 것 같다.피터 잭슨 (토크) 2011년 6월 10일 (UTC) 10시 15분[응답]

아마 하루에 수천 통의 메일을 보내는 것이기 때문일 것이다 :) 현재로써는 하루에 500통 정도의 메일을 받고 있을 것이다 :) --Errrant 13:10, 2011년 6월 10일 (UTC)[응답]

서명

WP에 몇 가지 텍스트를 추가했다.닉네임을 혼동하지 않도록 하는 것에 대한 시그니처. 단지 이것이 기본 설정에서 시그너처 필드의 기본 동작임을 발견하기 위해서입니다.이것은 MediaWiki에 의해 제어된다.서명, 내가 생각하기에 혼란스러웠고/그랬어야 할 닉네임(별명이 제공되면)을 정확히 하는 서명.이는 MediaWiki에서 변경될 수 있다.서명(예: 이름/닉네임 및 MediaWiki:Tog-fancysig는 일치하도록 수정했다.Rd232 16:20, 2011년 6월 11일 (UTC)[응답]

무슨 말인지 거의 알아들었어?타이핑이 너무 빨라서 3문장 정도 놓치셨나요?넌 보통 위키피디아에서 더 명료한 사람이지→ ROX₪ 16:28, 2011년 6월 11일 (UTC)[응답]

이것은 "만약 선택하지 않으면, 위의 상자의 내용이 당신의 별명으로 처리되고 당신의 사용자 페이지에 자동으로 연결될 것" 옵션에 관한 것으로, 이것은 높은 수준의 단순성으로 사용하기 위해 다른 이름을 입력하는 것을 가능하게 할 것이다.그랑디오스 (나, 말, 기여) 16:30, 2011년 6월 11일 (UTC)[응답]

나 또한 약간 혼란스럽지만, 아마도 내가 항상 "위키 마크업으로 처리하라"라는 상자를 체크했기 때문일 것이다.솔직히, 우리는 그런 닉네임 기능이 필요 없어. 그건 (특히 새로운 사용자에게) 혼란스럽고, 어쨌든 위키코드를 사용하여 닉네임이 있는 시그니처를 만들 수 있어.비록 나는 WP의 추가에 확실히 동의한다.시그니처에 실제 사용자 이름에 대한 언급이 없으면 닉네임이 혼란스럽다는 시그니처. /ƒETECOMMS/18:39, 2011년 6월 11일(UTC)[응답]

좋아, 내가 꽤 성급했던 것 같아. 분명히 말해두자.

1. 나는 WP에 추가했다.(실제 사용자 이름을 포함하지 않고) 서명에 닉네임을 제대로 사용하지 않는 것이 혼동하기 쉽다는 것을 명확히 하기 위해 여기에서 서명한다.나는 이것이 널리 이해되고 있다고 생각하지만, 나는 가끔 그것을 보아왔다.
2. 그러나 이러한 혼란스러운 관행은 사용자 선호 설정에서 강하게 권장되는 것으로 나타났다.순간 '원시서명' 박스를 누르지 않고 닉네임을 입력하면 그만큼 연습이 혼돈된다.
3. 이 문제는 MediaWiki를 편집하여 해결할 수 있다.서명.전류 [[사용자:예: 닉네임]이(가) [[사용자:예제]]/사용자가 "원시 서명" 상자를 확인하지 않고 환경설정에서 닉네임을 입력하는 경우

더 나은가? Rd232 19:24, 2011년 6월 11일 (UTC)[응답]

따라서 우리는 이와 같은 (대체 계정에서)와 이것(관리자로부터)과 같은 유사성의 주기적인 순간을 얻는다.이 계정으로 그것을 알아내는 데 몇 번의 시도가 필요했으므로 7월 중순경 나의 기여를 보면 내가 상자를 체크하기 전에 몇 번 똑같은 일이 일어났음을 알 수 있다.상자를 디폴트로 누르면 일이 더 쉬워질 것이다.북빛의 칼날 (話して下い) 19:33, 2011년 6월 11일 (UTC)[응답]

가이드라인 제안으로 에세이 격상

위키백과의 토론에 참여하십시오.위키프로젝트 군사역사/공지 가이드라인#지침서에 대한 설명RightCow LeftCoast (talk) 21:33, 2011년 6월 12일 (UTC) ({{pls} 사용)[응답]

이해충돌 에세이 아이디어

위키백과의 토론에 참여하십시오.이해의 충돌#정치적 제휴와 COI.RightCow LeftCoast (talk) 21:53, 2011년 6월 12일 (UTC) ({{pls} 사용)[응답]

1년 동안 사용하지 않은 후 sysop 권한 일시 중단

한 관리 계정이 백인우월주의 편집자들에 의해 납치된 후, 비활성 행정관 문제는 다시 추악한 머리를 들고 있다.Arbcom은 지역사회에 발생할 수 있는 피해를 막기 위해 2005년 마지막 편집을 한 Spencer195(토크 · 기여 · 블록 · 보호 · 삭제 · 페이지 이동 · 권리 · RfA)를 긴급 디소프로 만들었다.스펜서195가 위키피디아에서 6년 동안 탈퇴한 것을 보면 휴면계정은 가정만큼 안전하다는 확신이 없어 보인다.

이에 대한 마지막 주요 제안이 나온 지 3년 만이다.

긴 토론이 위키백과로 이동됨:마을 펌프(제안)/비활동 관리자의 시스템 운영 권한 중단

특권 계정 보안 강화에 대한 브레인스토밍

이 중 많은 부분이 관리자 계정 보안에 대한 우려로 인해 나는 최소한 이성의 범위 내에서 익명성, 개인 정보 보호 등을 유지하면서 수행될 수 있는 몇 가지 다른 방법/사안을 간단히 언급하고 싶다.내가 말하는 것은 방탄 보안이 아니라, 일반적(선택사항일 수 있음) 관행으로 신원을 확인하거나 로그인을 보안하는 데 사용될 수 있는 두 번째 인증 요인에 불과하다는 점을 명심하십시오.

• 공개 키 인프라 — 향상된 권한 세트를 가진 사용자에게 장기 키 공격을 부정할 수 있도록 실제 기간 내에 만료되는 강력한(>=4096비트) 공개 키 세트를 생성 및 게시하기 위해 GNUPG와 같은 무료 기본 PKI 패키지(예: GNUPG)를 사용하도록 요청하는 것이 좋을 수 있다.단지 문제는 하드 드라이브 충돌이나 사고로 키가 분실될 수 있다는 것이다.하지만 이성적으로 보면, 만약 누군가가 활동하다가 사적인 열쇠를 잃어버리면, 사람들은 아마도 그들이 자신이 주장하는 사람이 맞는지 아닌지를 그들의 행동으로 판단할 수 있을 것이다.
• 토큰 기반 인증 — 이를 가능하게 하는 몇 가지 기술이 존재한다.SecurID와 관련 기술은 비용이 들지만, 할인이나 비영리단체에 제공될 수도 있다.하드웨어 토큰의 소프트웨어 기반 버전도 있고, 다른 독점 구현의 무료 구현도 있다.eTokens 역시 꽤 싸지만, 여전히 무언가를 사야 한다.
• 계정 보안 질문 — 모든 사람이 이러한 질문을 다루어야 했지만, 우리는 여러분이 스스로 질문을 만들고(매우 중요) 답변을 제공할 수 있도록 하는 합리적인 방법을 만들 수 있다.

이러한 방법을 사용하면 정기적으로 인증할 필요는 없지만(완전한 고통일 수 있음) 툴 서버가 리뉴얼을 고려할 때 수행하는 것과 유사한 작업을 수행하는 것이 좋을 수 있다: 일정 기간(이 경우 1년 또는 일정 기간 동안 사용하지 않은 경우) 후에 연장된 권한을 가진 사람들에게 문의하십시오.o는 사이트를 방문하여 파일에 있는 몇 가지 고급 식별 방법 중 하나를 사용하여 해당 권한을 "취소"한다.그래야 개인 키를 잃어버리면 대신 보안 질문에 답할 수 있고, 계정 보안 질문을 잊어버리면 토큰이나 개인 키를 대신 사용할 수 있다 등....

이 모든 것들은 또한 누군가가 비밀번호를 잊어버리거나, 누군가가 악의적으로 비밀번호를 바꾸거나, 다른 시나리오가 발생할 수 있는 경우를 해결하는 데 도움이 될 것이다.

어쨌든, 그냥 브레인스토밍이었어

응원 =) --슬래커^{\ talk /} 22:22, 2011년 6월 9일 (UTC)[응답]

위키피디아에 더 많은 것이 있다.마을 펌프(제안)/계정 보안 구역아마도 너는 너의 생각을 그곳으로 옮길 수 있을 것이다. 이 실은 이미 꽤 길기 때문이다.Rd232 00:05, 2011년 6월 10일 (UTC)[응답]

토큰은 잘 작동하고, 이런 일이 일어나기 전까지는 (미안하지만, 너무 유혹적이었다.)--크리스 13:51, 2011년 6월 13일 (UTC)[응답]

차단된 삭스푸펫의 불쾌한 사용자 이름

개인이나 그룹을 공격하거나 일반적으로 파괴적이거나 공격적인 사용자 이름을 숨기는 것이 좋을까?특히 나는 만약 그러한 콘텐츠가 메인 스페이스나 사용자 공간에 있었다면 공격 페이지에서 우리의 정책에 따라 삭제될 것이기 때문에 이 삭푸펫의 이름을 숨기는 것이 적절한지 궁금하다."Blocked user" 또는 "Blocked sockpuppuppet of user x"와 같은 차단된 사용자 페이지에 일반적 제목을 부여하는 데 기술적인 문제가 있을까? 위키백과 템플릿을 찾을 수는 없지만 다른 Wikia 프로젝트(예: [1] 참조)에서 몇 가지 문제가 있다.나는 사용자 이름을 변경하자는 것이 아니라 단순히 템플릿으로 대체하자는 것이다.다른 곳에 두면 이런 내용을 삭제하겠다는 것은 위선적으로 보이지만, 사용자 이름의 일부분이기 때문에 선명하게 보이게 하는 것이다.애국가 19:57, 2011년 6월 6일 (UTC)[답글]

만약 제목이 BLP위반이나 누군가를 공격한다면 나는 이에 동의하고 지지할 것이다.비록 욕설이나 몇 사람의 기분을 상하게 하거나 일반적인 짜증이 난다면 거절할 것이라고 말하고 싶다. --쿠미오코 (토크) 20:25, 2011년 6월 6일 (UTC)[응답]

내 생각엔 사용자 이름에 욕설이 들어있다면 이름을 숨길 뚜렷한 이유가 없는 것 같아.BLP 위반/공격 사용자 이름(연계된 사용자 이름 등)이 있을 때 사용자 이름을 숨기는 경우가 있어야 하며, "혐오 발언"으로 간주될 수 있는 경우(즉, 극도로 여성혐오적이거나 인종차별적인 사용자 이름). --Anthe 20:53, 2011년 6월 6일(UTC)[답글]

사용자 이름은 페이지 기록에서 수정될 수 있으며 필요한 경우 사용자 생성 로그 등에서도 삭제할 수 있다.CAT를 통해 요청 가능:RDEL. Rd232^talk 21:29, 2011년 6월 6일(UTC)[응답]

문제는 사용자 페이지에 불쾌감을 주는 사용자 이름의 존재 여부. --Anthe 21:30, 2011년 6월 6일(UTC)[답글]

극단적인 상황에서는 사용자의 이름이 변경될 수 있다(WP:CHU).이러한 계정에는 종종 NOINDEX가 해당 계정을 표시하는 템플릿(예: {{sockpuppett})으로 태그가 지정된다는 점에 유의하십시오.Rd232^talk 21:52, 2011년 6월 6일 (UTC)[응답]

흠, 행정관이 신청할 수 있는 템플리트를 갖는 것이 더 간단할 것이라고 생각하고 있었다. --Anthe 03:20, 2011년 6월 7일 (UTC)[답글]

관료들이 행동할 수 있도록 (WP:Edit request system에 따라 모델링된) 이름을 바꾸는 템플릿이 있을 수 있지만, 그럴 만한 가치가 있는지 모르겠다.Rd232^talk 10:22, 2011년 6월 9일 (UTC)[응답]

이제 FYI 사용자 이름은 오버세이터(m:§4 "블래터 공격 사용자 이름") 또는 모든 프로젝트에서 전 세계에 걸쳐 모든 stewards의 감독을 받는다.안부, --m:dferg 21:23, 2011년 6월 10일 (UTC)[응답]

• 주 기쁨의 국가는 Claritas [2] --Tothwolf (토크) 04:19, 2011년 6월 15일 (UTC)[응답]의 소크푸펫으로 막혔다.

요약 편집을 사용하도록 IP 강제 설정

내가 페이지의 수정 내역을 볼 때마다, 대부분의 IP는 지속적으로 편집 요약을 사용하지 못하는데, 이것은 RCP가 편집이 얼마나 적절한지 결정하는 데 도움이 될 것이다.예를 들어, 편집 요약에 편집을 나타내는 "BLARGHFSUDFSHKGS"가 포함되어 있는 경우, 통계적으로 대부분의 경우, 이러한 편집 요약을 사용하는 편집자는 적절한 편집 요약을 삽입할 수 없다.생각?—제임스 • 9:38pm • 11:38, 2011년 6월 12일 (UTC)[응답]

IP에 대한 단기 테스트는 해볼만 하겠지만, 여기는 Evernury 제안 영역이다.새로운 기본 요약 편집 가젯이 기본적으로 (Commons.js를 통해) 제공되지 않아서 IP도 사용할 수 있는지 궁금하다.Rd232^talk 11:45, 2011년 6월 12일 (UTC)[응답]

등록한 사용자가 이력 목록에서 건설적인 IP 편집을 체크해 다른 사용자가 원하지 않을 경우 이중 체크에 시간을 낭비하지 않도록 한다면 좋을 것이다. --Squidonius (토크) 21:39, 2011년 6월 12일 (UTC)[응답]

최근에 요약 편집을 놓고 토론을 한 줄 알았는데, 그게 무슨 의미가 있는 거야?공통 편집 요약의 드롭다운 박스를 지지하는 사람도 있는 것으로 알고 있지만, 그것이 실행될 것인가? / /ETECCOMMS/ 00:58, 2011년 6월 13일 (UTC)[응답]

좋은 생각이 될 것 같아.편집 요약 편집의 변화가 감지되었다. - 이제 자동 드롭다운이 있지만, 표준 제안인지 아니면 내 es의 .js 버전을 저장했는지 알 수 없다. --쿠드풍 กดผผึง ( ( ( ( ((토크) 04:48, 2011년 6월 13일 (UTC)[응답]

글쎄, 나는 IP가 요약을 넣도록 강하게 장려되어야 한다고 생각한다.

나는 위의 다른 아이디어도 좋아한다.나는 그것이 훨씬 더 많은 작업이 필요할 것이라고 추측하지만, 사람들이 특정한 편집을 좋아한다고 서명하는 일반적인 생각은 그것이 유용한 것으로 이어질 수 있는 것처럼 들린다.점검만 줄이는 게 아니라 다른 것들도.학교 CD에 출판하기에 적합한 버전을 찾거나 분쟁이 있을 때 잠글 수 있도록 편집하는 지속적인 문제처럼.Dmcq (대화) 06:32, 2011년 6월 13일 (UTC)[응답]

이 아이디어는 위에 언급된 바와 같이 퍼니얼 프러포즈 영역에 있으며, 나는 이전에 이것에 대한 토론에 참여했다고 맹세할 수 있었다.편집 요약을 요구하는 것은 익명의 사용자들이 편집을 시도하지 못하게 할 수도 있다고 생각하는데, 만약 그들이 단지 무언가를 입력하도록 강요 받는다면 편집 요약을 얼마나 유용하게 사용할지 모르겠다.에어로빅폭스 (토크) 06:55, 2011년 6월 13일 (UTC)[응답]

우리는 이것에 대해 최근에 논의를 했고, 여기서 찾을 수 있다.

이것은 실제로 타이핑 당시 위키백과 마을 펌프 제안서 아카이브 70에 있다.왜 이것이 영원한 제안으로 여겨져야 하는지 알 수 있을 것 같다.보시다시피 토론은 타이핑 당시인 3월이었다.ACEOREVIVEED (토크) 21:20, 2011년 6월 14일 (UTC)[응답]

12K 텍스트로 붙여넣지 말고 보관된 제안 섹션에 위키링크를 하는 것이 어떨까? -- John of Reading (토크) 21:36, 2011년 6월 14일 (UTC)[응답]

나는 이 생각에 반대한다, 왜냐하면 만약 우리가 공공 기물 파손 행위를 식별하고 싶다면, 우리는 변화를 더 쉽게 순찰하기 위해 공공 기물 파손에 대한 드롭다운 선택권을 둘 것인가?난 그렇게 생각하지 않아. 그리고 그 순간 백지 편집 요약이 그 작품을 확인할 수 있는 좋은 단서가 될 거야.더 많은 등록된 사용자들이 편집 요약을 사용하거나 강제로 사용하도록 권장하는 아이디어는 장점이 있다.새로운 사람들이 그들이 무엇을 하고 있는지에 대한 설명을 떠올리게 하지 않고 여기서 편집하는 것은 이미 충분히 어려운 일이다.Graeme Bartlett (대화) 21:44, 2011년 6월 14일 (UTC)[응답]

임의품

그냥 지옥을 위해서, 오늘 나는 "난잡한 기사"를 클릭해서 무슨 일이 일어날지 보았다.나는 기사가 아니라 혼란스러운 페이지를 받아서 매우 실망했다.{{dab}} 템플릿이 있는 페이지를 가져오지 못하게 하여 무작위 기사를 단지 기사 -로 제한할 수 있는 방법이 있는가?그루티니스...뭐라고? 2011년 6월 14일 11시 44분 (UTC)[응답하라]

이것은 대본을 사용하여 가능하다. 위키백과:강화된 무작위 기사. -- John of Reading (대화) 12:08, 2011년 6월 14일 (UTC)[응답]

아 - 고마워!그루티니스...뭐라고? 2011년 6월 15일 02:00 (UTC)[응답하라]

WebCite 아카이빙 도구

편집자가 WebCite에 대한 참조를 신속하게 보관할 수 있도록 반자동화 도구를 만들 것을 요청한다.인용구가 많은 기사를 일일이 훑어보고 일일이 보관하는 것은 정말 짜증나고, 그렇지 않으면 기사 내용을 개선하는 데 소모될 수 있는 시간을 낭비한다.이 도구는 클릭 한 번만으로 모든 참조를 한 번에 보관할 수 있는 것이 이상적이어야 한다.다시, 수백 개의 참고문헌을 가지고 기사를 훑어보고 그것들을 모두 사례별로 보관하는 것은 극히 비효율적이고 시간이 많이 소요된다.그리고 링크로트는 그러한 도구의 창조를 정당화할 만큼 심각한 문제다.그리고 WebCite는 모든 종류의 콘텐츠를 보관하는 것이 이상적이지 않을 수도 있지만, 그러한 툴이 전혀 없는 것보다는 나을 것이다.야마구치 도시오 (토크) 11시 40분, 2011년 6월 1일 (UTC)[응답]

위키백과를 참조하십시오.Gadget/proposal MorganKevinJ^(talk) 21:01, 2011년 6월 1일(UTC)[응답]

위키미디어 재단의 Google Summer of Code 프로젝트 중 하나는 [15]를 참조하고 링크도 참조하십시오.안녕, HaeB (토크) 02:01, 2011년 6월 3일 (UTC)[응답]

안녕, 난 위의 GSOC 프로젝트의 개발자야.나는 단지 안부를 묻고 미디어위키의 외부 링크 아카이브 확장을 위해 커뮤니티가 어떤 특징을 갖고 싶어하는지 느끼고 싶었다.나는 현재 교착상태에 있는 RFC로부터 위키윅스 구현 여부에 대해 기사를 통해 외부 링크를 어떻게 수정해야 하는지에 대해 상당한 이견이 있는 것으로 보인다.내가 가고자 하는 길은 링크를 수정하고 모든 외부 링크의 페이지 캐시로 당신을 데려갈 수 있는 링크를 추가할 것이다.이행에 대한 공감대가 형성되기 어려워 보여 커뮤니티에서 이를 제한해 특정 카테고리를 즉석에서 말하는 능력을 원하는지 궁금했다. --케빈 브라운 (토크) 21:38, 2011년 6월 6일 (UTC)[응답]

"특정 카테고리"가 정확히 무슨 뜻이야?야마구치 도시오 (토크) 00:20, 2011년 6월 9일 (UTC)[응답]

예를 들어, 구성할 수 있는 특정 범주에서만 기능을 사용할 수 있는 경우.예를 들어 Category와 같은 것:자동 보관 기능을 사용하는 페이지. --Kevin Brown (talk) 00:29, 2011년 6월 9일 (UTC)[응답]

이 일을 하는 데 의견 일치가 있다면, 그것은 나에게 좋게 들린다.RfC를 초안하는 건 어때?하지만 나는 우리가 먼저 여기서 합의에 도달하도록 노력해야 한다고 생각한다.그래서 아마 여기서 윤곽을 그려야 할 것 같은데, 정확히 무엇을 생각하고 있는지, 아마 이 섹션의 하위 섹션으로?야마구치 도시오 (토크) 00:45, 2011년 6월 9일 (UTC)[응답]

내가 생각하고 있던 것은 기본적으로 다음과 같은 것이었다.

• 페이지 저장 아티클의 모든 링크가 파서에서 검색됨
  • 이미 보관되어 있다면 아무것도 하지 않는다.

• • 아직 보관되지 않은 경우 웹봇이 대기열에 추가되어 블랙리스트에 포함되지 않은 경우 웹봇이 보관된다.
• 얼마 후 웹봇이 와서 웹페이지를 검색하려고 한다.
  • 보관에 성공하면 저장되고 요청에 따라 표시됨
  • 웹 사이트가 다운된 경우, 나중에 확인하기 위해 페이지를 대기열로 읽거나, 일정 횟수의 시도 후에도 페이지가 다운된 경우 링크가 비활성화된 것으로 간주되어 시도를 중지한다.
  • 웹 사이트가 활성화되었지만 로봇 때문에 링크를 보관할 수 없는 경우.txt, nocache 또는 noarchive 태그는 특정 시간 동안 사이트를 자동으로 블랙리스트에 추가
  • 웹 사이트가 작동했지만 페이지가 다시 404로 나타나거나 리디렉션이 실패한 시도로 간주하고, 이를 메모하고, 링크하는 경우
• 파서에 후크를 추가하여 Wiki의 모든 외부 링크에 대한 페이지의 캐시된 버전에 액세스하기 위한 링크를 표시하거나 구성 가능한 옵션을 표시하십시오. 이 링크는 구문 분석으로 수행되므로 아직 보관되지 않았거나 보관에 실패한 항목에 연결할 수 있음

그것은 기본적으로 간단명료하다.실제로 해내는 틀은 정말 쉬운 부분이다.어려운 부분은 이 일이 보안상의 허점 없이 이루어질 수 있도록 모든 것을 소독하는 것이다.이 때문에 자바 스크립트나 플래시 오브젝트는 소화가 어렵기 때문에 저장하지 않을 것 같다.이미지는 대부분 보안이지만 보안 취약점도 있을 수 있다.물건을 바꾸고 존재하지 않을 수도 있는 물건과 연결하는 한 나는 지역사회의 몇몇 사람들이 이것에 대해 문제를 가지고 있다는 것을 안다. 그러나 이것은 무엇이 아직 보관되지 않았는지 알아내기 위해 질문하는 것보다 훨씬 덜 집중적이다.페이지가 상당 기간 캐시되기 때문에(여기서 일주일 정도인 것으로 알고 있음) 아카이브가 실제로 존재하는지 다시 확인하는 데 오랜 시간이 걸릴 수 있다는 것은 말할 것도 없다.존재하지 않을 수도 있는 것에 연결만 하는 것이 최선의 선택이라고 생각하는 것도 이 때문이다. --케빈 브라운 (토크) 00:39, 2011년 6월 10일 (UTC)[응답]

그거 좋은 생각이야.나는 아마도 다른 사람들이 이것에 대해 논평하고 이것에 대한 지지가 있다면 우리는 단순히 기다려야 한다고 생각한다.거의 모든 것이 현재 상황보다 낫다. 인용문을 보관할 수 있는 도구가 없기 때문에, 나는 일반적으로 우리가 작업 해결책에 가까워지는 모든 것을 지지한다.야마구치 도시오 (토크) 01:00, 2011년 6월 10일 (UTC)[응답]

이것은 영어 위키피디아에 그것을 구현하기 위한 지원이 있는지 여부에 상관없이 내가 작업할 것이다.그러나 나는 이것이 여기에 배치되는 것을 보고 싶다. 그래서 나는 지역사회가 소프트웨어에서 즉시 사용할 수 있는 기능이 있는지 알아보기 위해 의견을 구하고 싶다.모든 기능 요청을 다 이행할 수 있을지는 장담할 수 없지만, 만약 사람들이 정말 원하는 것이 있다면 나는 그것을 실행하도록 노력할 것이다.확실히 안전한 아카이빙을 하는 것이 나의 최우선 과제고 다른 모든 것은 그것에 뒷전이다. --Kevin Brown (토크) 01:49, 2011년 6월 10일 (UTC)[응답]

내가 WP에 제출한 최근 봇 요청을 살펴보십시오.BOTREQ#AntiLinkrotBot. 여기서 WebCite bot에서 기대할 수 있는 기능 중 일부를 나열했다.야마구치 도시오 (토크) 2011년 6월 10일 (UTC) 10:00[응답]

현재 시점에서 이것은 참조에 있는 것만이 아니라 모든 외부 링크에 대한 것일 것이다.나중에 이것을 참조로 제한하기 위해 무언가를 추가하고 싶지만 세 가지 문제가 있다.

• 예를 들어 외부 링크 테이블에는 링크가 참조인지 아닌지를 알려주는 데이터가 포함되지 않는 등 모든 외부 링크처럼 쉽게 얻을 수 있는 것은 아니다.
• Cite 확장은 미디어 위키 코어의 일부가 아니므로 불필요한 종속성을 야기할 수 있다.
• 일부 편집자는 <ref> 태그가 아닌 손으로 MLA 또는 APA 스타일의 괄호 참조를 사용하므로, 참조 태그에만 내용을 보관할 경우 해당 링크가 보관되지 않는다.

웹에 자동으로 자료를 제출하는 것은 그렇게 어렵지 않지만, 웹사이트의 현재 인프라를 고려할 때, 그들이 이메일 주소를 요구하고 모든 보관 요청에 대해 이메일을 보내기 때문에, 나는 그것이 실용적일지 잘 모르겠다.--케빈 브라운 (대화) 11시 58분, 2011년 6월 10일 (UTC)[응답]

작년 말에 나는 웹사이트에 많은 링크들을 보관했고, 그것을 할 수 밖에 없었지만, 내가 이메일을 처리하는 방법은 단지 구글 메일 주소를 제공하는 것이었습니다.그리고 단순히 "It worked" e-메일을 삭제하기 위한 필터를 설정. --Errrant^(chat!) 13:05, 2011년 6월 10일 (UTC)[응답]

그런 것은 효과가 있을 수 있지만, 마치 "우리들이 잘못하는 것 같다"는 식으로 들린다.네, 하지만 끔찍하게 비효율적이고 대규모로 보면 말이 안 되고 잠재적으로 확장성 문제로 이어질 수도 있다.정말로 웹 인용문은 이메일 주소보다는 API 키를 사용하기 위해 그들의 목적에 맞는 일을 할 필요가 있다. --Kevin Brown (토크) 02:35, 2011년 6월 11일 (UTC)[응답]

일부 국가에서는 장기간 보관으로 인해 해당 국가에서 이것이 합법적인지 여부를 해당 출처로부터 허가를 받아야 한다는 점에 유의하십시오.보관된 페이지를 일반 용도로 사용할 수 없는 경우, 검색 엔진이 페이지를 인덱싱하지 않고 페이지에 액세스하기 위한 요청만 구성할 수 없는 경우, 이 기능을 합법화하는 일종의 예비 전략을 만들 수 있다.만약 사용자로부터 요청이 나온다면, 나는 사용자가 책임을 질 것이라고 생각한다.편집 후 소프트웨어에서 요청이 나오면 WMF가 책임져야 한다고 생각한다.일부 관할구역에서는 첫 번째 관할구역이 골치 아픈 곳이고, 다른 관할구역에서는 마지막 관할구역이다.제블라드 (대화) 2011년 6월 10일 (UTC) 12시 30분[응답]

내가 아는 한 우리가 걱정해야 할 유일한 문제는 미국이다. 왜냐하면 그곳이 서버들이 호스팅되는 곳이기 때문이다.내가 재단 법률 고문에게 정식 의견을 구하는 중이라고 하는 것은, DMCA의 안전한 항만 제공으로 인해 DMCA 타케트다운 요청이 지켜지는 한 저작권 문제가 그리 심하지 않을 것이다. --케빈 브라운 (대화) 2011년 6월 10일 (UTC)[응답]

그것은 업로더로 출판되어 위험에 처하게 될 것이고, wmf가 다른 누군가를 대신하여 행동한다면 그들은 위험에 처하게 될 것이다.그것은 PirateBay와 비슷하고 그 사이트에서 저작권이 있는 자료와 연결된다.일부 국가에서는 합법적일 수 있지만 다른 국가에서는 그렇지 않다.제블라드 (대화) 2011년 6월 14일 (UTC) 18:00[응답]

구글과 인터넷 아카이브가 캐싱을 할 수 있다는 점을 감안하면 가능하다고 생각한다.하지만 나는 법적 사항의 세부 사항에 대해 완전히 확신할 수 없다.네 말이 맞을지도 모르지만, 재단의 변호사가 조사하고 있고 모든 법적 문제는 완전한 배치 전에 검토될 것이라고 말할 수 있다. --케빈 브라운 (대화) 22:34, 2011년 6월 15일 (UTC)[응답]

나는 인용문들의 죽은 연결고리가 위키피디아의 주요 이슈이기 때문에 이 아이디어를 진전시키는 것에 대한 나의 지지의 목소리를 내고 싶다.이 지역의 어떤 진보도 크게 환영할 것이다.나는 또한 WebCitation.org의 Gunther Eysenbach가 인용문을 보관하는 것을 돕기 위해 위키피디아와 협력하기를 원한다는 것을 언급해야 한다.그는 위키피디아의 화이트리스트를 만들어 그들이 고속 아카이브를 수행할 수 있도록 할 수 있다.그는 위키피디아와 관련된 특정 작업에 대한 이메일 요구 사항을 기꺼이 수정할 것이다.입력을 요청하겠다. - 하이드로xonium (T•C•V) 00:38, 2011년 6월 12일 (UTC)[응답]

내 마지막 정보 보기 [16]:우리는 어제 영어 위키백과 외부 링크의 내용을 캐싱하기 시작했고, 결정이 내려지기를 기다리는 동안 모든 정보 소싱 작업이 백업될 수 있도록 했다.

그러므로 어제부터 우리는 위키피디아에 소개된 모든 새로운 링크들을 보관하고 있다. 어제 이전에 소개된 분들에 대해서도 보관하고, 오류 404를 반환하는 분들에 대해서는 webarchive.org에서 받아보도록 하겠다.건배, 파마틴 (토크) 01:43, 2011년 6월 15일 (UTC)[응답]

역사로의 전환

우리는 검색창에 타이핑을 해서 역사의 페이지로 뛰어오를 수 있을 것이다.

예를 들어, 테이블의 토크 페이지를 가고자 한다면 wp talk:table을 타이핑할 수 있지만, 토크 페이지의 이력이나 "기사"의 이력으로는 이것을 할 수 없기 때문에, 나는 이것을 추가하기를 제안한다.연석 체인 (토크) 07:05, 2011년 6월 13일 (UTC)[응답]

반대하라. 독자들은 역사 페이지에 관심을 가져야 하지만 그렇지 않다.수백만의 방문자 중 99%가 클릭 한 번을 저장할 수 있도록 UI를 복잡하게 만드는 것은 가치가 없을 것 같다(그리고 이는 기술 POV에서 현실적으로 실현 가능하다고 가정함). 로그인한 사용자만 사용할 수 있는 경우에 더 유용할 수 있는가?아마도 가젯/사용자 대본이 좋을 것이다. - Jarry1250 11:26, 2011년 6월 13일 (UTC)[응답]

의견 - 제안서에 없는 주요 내용은 "왜"이다.너는 우리가 할 수 있어야 한다고 말하지만, 왜 우리가 할 수 있어야 하는가?검색창에서 페이지 기록으로 바로 이동할 수 있는 이점이 보이지 않는다.GB팬 (토크) 11:38, 2011년 6월 13일 (UTC)[응답]

• 강력한 지원 - 이것은 소싱에 대한 좋은 아이디어로, 기사 내역에 대한 연결을 직관적으로 만들고, 콘텐츠를 재사용하는 사이트가 라이선스를 쉽게 준수할 수 있도록 할 것이다.내가 생각할 수 있는 단 하나의 간단한 방법은 새로운 네임스페이스를 사용하는 것이다. 그리고 문제는 우리가 결국 "템플릿 토크 히스토리:"로 끝날 것이라는 것이다. 그것은 바로 입 자판기 입니다.기사만을 위한 사이비 네임스페이스를 만들 수 있지만, 그것은 URL에 나타나지 않아 혼동될 수 있고, 그 유용성은 최소화될 수 있다는 것을 의미할 수 있다.그래서, 나는 이것이 멋진 아이디어라고 생각하지만, 그것을 구현하는 현실적인 방법은 생각나지 않는다.누군가 방법을 생각한다면, 대단하다.◆ 조니미르닌자 22:17, 2011년 6월 14일 (UTC)[응답]

주석: 기술적으로 가능하다면 스크립트 또는 잠재적으로 가젯으로 가장 적합한 것 같다.대본이나 기기로 사용한 후, 주로 독자에게 배포하는 것을 보기 어렵다.그랑디오스 (나, 말, 기여) 20:46, 2011년 6월 15일 (UTC)[응답]

Wiki Project 일반 청중 재활성화 요청

나는 위키피디아가 다음과 같은 것을 발견했다.기술 기사를 이해할 수 있게끔 하는 것이 완전히 수정되었다(매우 인상적이었어!)수학에 관한 많은 기사들은 교육을 잘 받은 독자들조차 이해하기 어렵다.유사점을 추가하는 것뿐만 아니라, 그러한 기사의 선두에 더 많은 배경 정보를 제공하고자 하는 많은 이유가 있다(예: "기능의 한계"의 비행기 유사점)이 있다.

• 수학에 대한 지식은 과학을 이해하는 데 필수적이다.
• 많은 과학적 주제가 공공정책 토론과 관련이 있으며, 공공정책 토론에 일반 국민의 전폭적인 참여가 바람직하다.
• 일반 대중들의 구성원들이 무언가를 "구글"할 때, 위키피디아가 종종 첫 번째 "히트"가 된다.
• 일반 국민의 지식 수준이 높아짐에 따라 공공정책토론회에 완전국민 참여의 혜택이 커질 수 있다.
• 많은 사람들이 수학에 대해 혐오감이나 두려움을 느끼고 있으며, 위키백과 기사의 난이도는 이를 강화시키는 경향이 있다.
• 좋은 수준의 과학 지식은 많은 실제 문제들을 해결하는데 유용하다.
• 위키피디아는 고급 일반 백과사전이 되고자 한다.

그러나 이 제안서를 다시 게시하는 목적은 정책을 토론하기 위한 것이 아니라 과학과 수학에 정통한 사용자들에게 자신의 전문 분야에 대한 지식이 부족한 우리들에게 자신의 지식을 자발적으로 전수해 줄 것을 요청하는 것이다(여기서는 살펴봐야 할 기사의 몇 가지 구체적인 예시들이 있다.

가이드라인에 명시된 바와 같이, "태양은 천문학자들 이상의 관심사, 질병은 의사 이상의 관심사"라고 말했다.물론 본질적으로 많은 과목들이 일정한 사전 지식 수준을 요구한다는 것을 알고 있으며, 기존 콘텐츠가 '더블다운(dumbed-down)'되어야 한다고 생각하지는 않지만, '한 단계 아래로 쓰기'와 같은 원칙은 좋은 경험 법칙이다.

69.251.180.224 (대화) 13:13, 2011년 6월 13일 (UTC)[응답]

---

보관소에서^{[11][31][37][28]} 다시 등록됨. 이 통지 아래에 새 주석을 추가하십시오.
고마워, 69.251.180.224 (대화) 13:13, 2011년 6월 13일 (UTC)[답글]

지원, 하지만 기사들을 실제로 이해할 수 있는 사람들이 필요해...때로는 어려울 수 있다.범주:너무 전문성이 높은 위키피디아 기사는 2007년부터 밀리고 있는데, 이는 좋은 징조가 아니다.크리스코 1492 (토크) 02:21, 2011년 6월 14일 (UTC)[응답]

댓글을 달다.위키백과 기사를 일반 대중에게 좀 더 가까이 다가갈 수 있게 만드는 아이디어는 좋은 아이디어로 널리 합의되어 있고, 명분도 필요 없다고 생각하지만, 그렇게 하기 위해서는 좀 더 체계적인 진행방식이 필요하다.이와 같은 위키피디아 주체는 대상 기사를 나열하고 각 분야의 사람들을 모집하기 위해 노력해야 한다.Dcoetzee 20:25, 2011년 6월 14일 (UTC)[응답]

WP:REVVE를 참조하십시오.휴면 중인 위키프로젝트를 되살리기 위해서는 허가가 필요 없다.WhatamIdoing (대화) 16:41, 2011년 6월 15일 (UTC)[응답]

페이지 및 카테고리 이동

페이지 이동이 자동으로 문서 페이지를 카테고리:로 리디렉션하도록 하는 것이 유용할 것 같다.이동에서 리디렉션. 범주는 현재 수동으로 추가해야 하므로 인구가 상당히 적다.소프트웨어가 그것을 지원할 것인가?지역사회가 그럴까?크리스코 1492 (대화) 09:36, 2011년 6월 10일 (UTC)[답글]

제안 변경 소프트웨어가 자동으로 템플릿을 추가하는 경우:페이지를 이동할 때 R에서 이동(이동할 때 리디렉션이 생성되지 않은 경우 제외)크리스코 1492 (대화) 23:14, 2011년 6월 12일 (UTC)[응답]

소프트웨어는 어떤 JS나 확장자를 사용하여 실행될 수 있지만, 그렇지 않을 것이다.어차피 모든 고장/이중 리디렉션은 유지 관리 페이지에 나타나기 때문에 나는 개인적으로 별로 필요하지 않다고 본다.게다가, 당신은 정말 수천 개에 달하는 아이템이 있는 카테고리를 원하십니까?Ajraddatz (토크) 13:56, 2011년 6월 10일 (UTC)[응답]

이 소프트웨어는 페이지를 이동할 때 리디렉션을 만들 때 쉽게 수행할 수 있다.내 생각엔 크리스코가 한 말이 그 말인 것 같은데, 그게 가장 효율적인 방법일 거야.Rd232^talk 14:46, 2011년 6월 10일 (UTC)[응답]

응, 그랬어.감사합니다.크리스코 1492 (대화) 16:04, 2011년 6월 10일 (UTC)[응답]

그 범주의 요점은 무엇인가?아니면 간단한 메시지와 함께 단지 그 카테고리에 한 페이지를 넣는 {{R} 이동으로부터의 템플릿 중?이것의 이점은 나를 잊게 한다.Rd232^talk 14:44, 2011년 6월 10일 (UTC)4[응답]

나도 똑같이 말하려 했다.난 봇이 그걸 하는 데 아무런 문제가 없을 거야. 난 그저 사람들이 왜 그러길 원하는지 모르겠어.그랑디오스(나, 말, 기여) 14:45, 2011년 6월 10일 (UTC)[응답]

따옴표:

"추적 카테고리 입니다.그것은 주로 목록 자체를 위해 페이지 목록을 작성하고 유지한다.템플리트를 통한 추적 카테고리에 페이지가 추가된다.

그리고

편집자 또는 자동화된 도구에 의해 사용되도록 의도된 관리 범주, 현재 기사 상태의 특징에 기반하거나 비기사 페이지를 분류하는 데 사용된다.

나의 해석은 그것은 단지 존재하고 더 크게 성장하기 위한 것이며, 페이지를 색인화하고 아마도 이동된 페이지의 목록으로 기능하기 위한 것이다.그러나, 그것은 토론을 위해 리디렉션에서 일하고 쓸모없는 리디렉션을 찾고 있는 사람들에게도 유용할 수 있다.크리스코 1492 (대화) 16:13, 2011년 6월 10일 (UTC)[응답]

그래, 하지만, 추적 범주도 사실 유용할 거야.이동된 페이지의 추적 카테고리는 어떤 용도로 사용될 것인가?페이지 이동 및 리디렉션 페이지는 소프트웨어에 의해 추적되는데, 어떻게 범주가 중복되지 않는가?
— V = IR(Talk • 기여) 16:18, 2011년 6월 10일 (UTC)[응답]

그것은 CFD에 대한 질문이 될 것이다.나는 한가지, 즉, 모든 움직임이 카테고리에 리디렉션을 추가한다면, 쓸모없는 리디렉션을 정기적으로 찾는 사람들은 쉽게 찾을 수 있다는 점에 주목했다.예를 들어, 우리는 개가 유령을 볼 수 있는가? 내가 그 범주를 보면서 본 것이 있다.크리스코 1492 (대화) 16:34, 2011년 6월 10일 (UTC)[응답]

이게 어떻게 CFD에 대한 질문인가?그들에게는 어떤 범주가 사용 가능한가?카테고리 없이 모든 리디렉션을 이미 찾을 수 있다.
— V = IR(Talk • 기여) 16:50, 2011년 6월 10일(UTC)[응답]

이 논의는 아니다. 범주의 유용성은 다음과 같다.크리스코 1492 (대화) 16:59, 2011년 6월 10일 (UTC)[응답]

나는 한 가지 이유로 이것을 인정한다; 고양이가 없는 것은 사람들로 하여금 그러한 리디렉션에 고양이를 추가하도록 유혹한다. 그것은 사람이 WP를 거쳐야 한다는 것을 의미한다.RM이 이동을 반전시킨다.종종 한명이야 하지만 항상 그렇지는 않다.

한 가지 대안은 고양이를 삭제하는 것이다.그러나 그러한 결정은 WP에서도 취해져야 한다.CFD. 패혈증PMAnderson 04:57, 2011년 6월 11일 (UTC)[응답]

만약 아무도 실질적인 이유를 생각해 낼 수 없다면, 다음 며칠 안에, 왜 이 범주가 어떤 목적을 달성하는지, 누군가 그것을 CFD해야 한다.너는 그것이 존재해서는 안 되는 이유를 방금 말해 주었다.Rd232^talk 05:42, 2011년 6월 11일 (UTC)[응답]

템플릿을 인용하려면:이동 중 R: "카테고리:이동에서 리디렉션, ...은 리디렉션이 제대로 설치되지 않은 경우 내부 및 외부 링크의 중단을 초래할 수 있는 모든 이동을 추적하는 데 사용된다."다소 합리적인 것 같다.크리스코 1492 (대화) 23:17, 2011년 6월 12일 (UTC)[응답]

이 경우, {{R from move}} 템플릿은 사람들이 사용하지 않는 리디렉션을 삭제하는 것을 방지하는 데 도움이 된다(템플릿 토크 페이지 참조).그러나 만약 그 텍스트가 실제로 리디렉션 페이지에 나타난다면 더 나은 목적을 달성할 수 있을 것이다; 어떤 이유로든, 적어도 나에게는 그렇지 않고, 왜 그런지 알 수 없다.Rd232 15:16, 2011년 6월 12일 (UTC)[응답]

나는 그것이 소프트웨어의 기술적 한계라고 생각한다.나는 위키프로젝트 인도네시아에서 분류 백로그를 정리하고 있었고 꽤 많은 문제들이 위키프로젝트 상자를 제거하지 않고 리디렉션된 페이지에 있었다; 그것은 상자를 표시하지 않지만, 모든 것은 여전히 소프트웨어에 의해 읽혀진다.크리스코 1492 (대화) 23:22, 2011년 6월 12일 (UTC)[응답]

클래스를 클래스로 수정하는 위키프로젝트 템플릿 봇의 혜택을 받을 수 있다.MZMcBride가 얼마 전에 친절하게 그런 리스트를 만들어 줬어.나쁜 등급 평가는 WP:1.0 팀에 중요한 문제가 될 수 있다.WhatamIdoing (대화) 23:44, 2011년 6월 12일 (UTC)[응답]

동의해. 어디서 그런 제안을 할까?여기? 새로운 섹션에서는 물론 크라이스코 1492 (토크) 23:58, 2011년 6월 12일 (UTC)[응답]

WT:Council이 Wiki Projects의 중앙 회의장이기 때문에 좋은 선택일 수 있다.나는 WP가 다음과 같이 믿는다.BOTREQ는 당신을 위해 대본을 쓸 수 있는 봇 주인들을 찾는 일반적인 장소다.나는 위키프로젝트 위원회부터 시작하겠다. 너는 모든 요구 사항 목록을 얻을 수 있을 것이다.WhatamIdoing (대화) 16:39, 2011년 6월 15일 (UTC)[응답]

위키피디아에서 요청:BOTR#Project_template_fixes_and_assessment. WP에서 요청한다.Council 그러나 나는 앞으로 몇 주 동안 매우 활동적이지 않을 것이다. 그래서 나는 참여할 수 없을 것이다.크리스코 1492 (대화) 09:06, 2011년 6월 16일 (UTC)[응답]

사실, 이동할 때 자동으로 템플릿을 추가하는 것이 더 나을 거야.문서에 따라 카테고리를 채운다.이동에서 리디렉션하여 편집자에게 리디렉션의 목적을 알린다.나는 내 제안을 바꿀 것 같아.크리스코 1492 (대화) 23:14, 2011년 6월 12일 (UTC)[응답]

블랙리스트에 지정된 외부 링크에 대한 조언

최근에, 나는 편집을 저장하기 전에 변경해야 했다.외부 링크가 블랙리스트에 올랐다고 들었다.이것은 저속한 사이트가 아니었다. 단지 아스퍼거 증후군과 섭식장애 사이의 연관성에 관한 것 뿐이다.어떤 웹사이트가 블랙리스트에 올라갔는지, 특히 그것들이 무해해 보이는지에 대해 우리에게 더 많은 조언을 해줘야 한다고 생각하는가?15:59, 2011년 6월 15일 (UTC)

블랙리스트에 있는 페이지나 블랙리스트에 있는 사이트에 링크를 추가하려면 어떻게 해야 하는지 조언해 달라는 말씀이십니까?첫 번째는 wp당 나쁜 생각이다.DENNE(거부) 및 목록도 방대한 만큼 실용적이지 않음(자체 m:스팸 블랙리스트 및 MediaWiki:스팸-블랙리스트).두 번째를 의미했다면 상장폐지 요건이 매우 엄격하기 때문에 이미 어디서 찾아야 할지 모르면 상장폐지 신청도 할 수 없다.요에닛 (토크)

내가 진정으로 의미하는 것은 아마도 블랙리스트에 오른 외부 링크의 종류에 대한 기사 맨 위에 몇 마디를 올려놓을 수 있다는 것이다.이것은 나에게 매우 무해하고 꽤 학문적인 외부 연결고리가 블랙리스트 태그를 얻는 것처럼 보일 때 정말로 자극되었다.그러나 블랙리스트에 올라 있는 외부 링크의 목록이 매우 길기 때문에 블랙리스트에 올라 있는 외부 링크를 나열하는 것이 실용적이지 않을 것이라는 당신의 지적은 잘 받아들여지고 있다.ACEOREVIVEED (토크) 19:36, 2011년 6월 15일 (UTC)[응답]

특정 링크가 블랙리스트에 지정된 이유에 대한 자세한 내용을 보려면 MediaWiki 대화에서 해당 링크를 찾아보십시오.스팸-블랙리스트/로그(로컬 블랙리스트) 또는 m:스팸 블랙리스트/로그(글로벌 블랙리스트)99%의 경우 전용 스팸메일 발송자에 문제가 생기겠지만, 특별한 경우나 잘못된 긍정일 수 있다.요에닛 (대화) 07:58, 2011년 6월 16일 (UTC)[응답]

WP에서 논의:물리적 상수에 대한 MEASURE#A 템플릿?

WT 토론에 참여하십시오.물리적 상수에 대한 MEASURE#A 템플릿?- A. di M._plé 14:34, 2011년 6월 16일 (UTC)({{pls} 사용)[응답]

의미 있는 것을 위해 "자동 확인"이라는 용어를 사용하지 마십시오.

방금 "자동확증 사용자"라는 용어를 알게 되었다(WP 참조:오토콘펌) 그리고 새로운 눈을 통해 그것을 보고 WTF를 생각하는 나 자신을 발견했는가?신참자가 손에 넣어야 할 뚜렷한 의미가 없는 전문용어다.나는 위키피디아 전체에서 "설립된 사용자" 또는 유사하게 묘사되고 있는 것이 무엇을 의미하는지에 대한 풍미를 주는 것을 금지할 것을 제안한다.구식 단축키 등이 효과가 있을 것이라는 점에서 부정은 고통스럽지 않을 것이지만 도움말 페이지의 용어, 새로운 기사를 겨냥한 템플릿 등은 새로운 용어를 위해 신속하게 표준화될 것이다.Rd232 20:34, 2011년 6월 8일 (UTC)[응답]

나는 솔직히 이것이 좋은 생각이라고 생각하지 않는다."오토콘 확증"은 매우 객관적인 용어인 반면, "설립된 사용자"에게는 충족되어야 할 일련의 기준이 있다는 의미가 없다.어쨌든, 많은 자동 확인 사용자들은 전혀 "설립"되지 않았고, 용어는 주관적인 과부하 입니다. --Anthe 21:47, 2011년 6월 8일 (UTC)[답글]

주 기쁨의 국가는 Claritas의 소크푸펫으로서 지속적으로 차단되었다[17]. --토울프 (토크) 04:21, 2011년 6월 15일 (UTC)[답글]

4일 / 10일 편집한 사용자에게 정확히 "설치"라고 하지는 않을 것이다... --KFP (연락처 편집) 22:00, 2011년 6월 8일 (UTC)[응답]

나는 동의하는 경향이 있다."확증"은 확실히 전문용어지만, 지금은 너무 잘 확립되어 있어서 그것을 바꾸려고 하는 것은 나에게 필요 없는 노력처럼 보인다.하지만 그냥 재미로 말하자면, "검증된" 것이 "정립된" 것보다 더 나은 선택이 될 것이다.
— V = IR(Talk • 기여) 21:58, 2011년 6월 8일(UTC)[응답]

"잘 확립된"은 논쟁거리가 아니다. 아무도 늙은이가 그것을 사용하는 것을 막지 못한다. 문제는 문서화다."검증된" 것은 좋지 않다. 그것은 어떤 종류의 검증(=확인) 과정을 제안하는 데 있어서 적극적으로 오도하는 것이다.Rd232^talk 22:04, 2011년 6월 8일 (UTC)[응답]

"설립"에 대한 반대도 여기서 비롯되고 있다.사용자를 "설립"하게 만드는 자동 확증에는 아무 것도 없다.어쩌면 그냥 "자동"을 떨어뜨려서 그 용어가 "확인"되도록 하는 것일지도 모르지만, 다시 말하지만, 나는 지금 그렇게 하는 것의 요점을 잘 모르겠다.이 배는 이미 항해한 것 같아.
— V = IR(Talk • 기여) 22:53, 2011년 6월 8일(UTC)[응답]

• 오토콘 확증은 이상한 위키 용어 중 하나인데, 나는 개인적으로 그것을 바꿀 필요가 없다고 본다.우린 단순한 영어 위키백과가 아니에요, 여러분.나는 (나처럼) 새로 온 사람이면 오토콘 확증이라는 아이디어를 얻을 수 있다고 99% 확신한다.게다가, 우리는 그것의 이름을 "10개의 편집과 4일의 경험을 가진 사용자"로 바꿀 것인가?Ajraddatz (토크) 22:10, 2011년 6월 8일 (UTC)[응답]
• 나는 오토콘 확증 대신에 "편집자"라는 용어를 선호한다.다른 많은 위키에는 엔위키에 대한 오토콘이 확증된 것과 같은 편집자가 있다.—Croisés Magnific 22:16, 2011년 6월 8일 (UTC)[응답]

진심 어린 지원:글쎄, 내가 다른 편집자들과는 많이 다르겠지만, 위키피디아 어의 전체 내용은 내가 외국어 텍스트나 외계인 속어를 읽는 것처럼 취급한 것이다.나는 모든 정의를 검색해야 한다면 읽는 것이 불가능하기 때문에 모호한 용어들을 그냥 넘긴다; 나는 단지 내가 문맥과 문맥에서 어휘들을 찾아냈으면 좋겠다.그것은 내가 완전히 dab, Prod, autocon 확증, decretate, RefA, XfD, RFC, ANI, CSD, FAS, CC-BY-SA, GFDL 등이 무엇을 의미하는지 이해하기까지는 수개월, 심지어 수년이 걸렸다는 것을 의미했다.확실히 "자율 확증"보다 더 나은 용어가 있다: 질문은 차라리 무엇이 가장 좋은 대체물인가, 즉 명확하고, 정확하며, 합리적으로 모호하지 않은 것이어야 한다.And, no, "autoconfirmed" doesn't necessarily mean what it says, any more than "Prod" or "Dab" do; to me (instead of being, presumably, a contraction of "automatically confirmed") it means "self-confirmed", which fits the minimum time and edits requirement in only in the vaguest and most indirect way —— Shakescene (talk) 06:47, 9 June 2011 (UTC)[r충분히]

• 문제를 찾는 해결책.변화가 필요 없음 - '정립된' 위키백과 용어.쿠드풍 กุผึ ( ((대화) 17:16, 2011년 6월 9일 (UTC)[응답]
  • [하지만 위키피디아의 내부에서만] "설립이 잘 되어 있는" 것과 이해할 수 있는 것 사이에는 차이가 있는데, 특히 오토콘 확증된 사용자들에만 한정된 프로세스가 있다는 것을 우연히 알게 된 길거리의 신참자들에게는 더욱 그렇다.—— Shakescene (대화) 21:27, 2011년 6월 9일 (UTC)[응답]

기술자 임계값의 기술자 이름인, 기술자 이름을 생각해 보면 직관적으로 알 수 있다.그 대안들은 의미를 이해할 수 있도록 아무것도 하지 말라고 제안하였다. 왜냐하면 그 유일한 방법은 영어로 된 용어 자체가 없기 때문에 그 이름이 한계점 자체를 말하는 것이고, 설명을 배제하고, "4일, 10개의 편집 장벽"이라는 이름을 바꾸지 않을 것이기 때문이다.이에 따라 어떤 이름이라도 생소한 사용자인지 알기 위해서는 여전히 설명 페이지를 방문하거나 말해야 할 것이다.우리가 그것을 바꾸면, 그것은 또한 많은 다른 프로젝트에서 사용되는 동일한 용어와 상충될 것이다; 그것은 하원, 위키트리온, 위키뉴스 등에서 사용되는 동일한 이름이다--Fuhgettaboutit (대화) 22:33, 2011년 6월 9일 (UTC)[응답]

정중하게, 나는 그것이 "기술의 한계점"이라는 것에 동의하지 않으며 따라서 비기술자들에게 설명할 필요가 없다.자동 확인 상태는 새로운 사용자가 정기적으로 원하는 Wiki 권한 집합(파일 업로드, 페이지 이름 바꾸기, 반회전 페이지 편집)을 나타낸다.새로운 사용자들은 왜 이런 것들을 할 수 없냐고 #위키피디아-엔-도움으로 정기적으로 오는데, "당신의 계정은 아직 자동 확증되지 않았다"는 답변은 이해하는데 별로 도움이 되지 않는다.만약 우리가 이 기능을 처음으로 고안해 낸다면, 나는 새로운 계정의 경우 "편집자"를, 확증된 사용자의 경우 "전체 편집자"를 추천하겠다.—Tim Pierce (talk) 22:54, 2011년 6월 9일 (UTC)[응답]

좋은 생각 같아. -- 지우개헤드1 <토크> 23:37, 2011년 6월 9일 (UTC)[응답]

@Tim Pierce 그러나 나는 당신이 생각하는 이름 변경에 의해 제공되는 어떤 명료함도 보이지 않는다.구체화하자.새 사용자: "I want to move X but I don't see any move button!"도우미: "well, you're an editor but not a full editor." 새 사용자: "what does being a 'full editor,' as opposed to an 'editor,' mean?"도우미: "it means you can't do certain things until you're account is four days old and has made ten edits."무슨 말인지 알겠어?나는 그것이 "비기술자들에게 설명할 필요가 없다"는 기술자이기 때문에 그렇게 말하는 것이 아니다.내가 말하고자 하는 것은 "당신의 계정이 아직 자동 확증되지 않았다"는 것이 "당신은 아직 완전한 편집자가 아니다"만큼 정확히 불투명하다는 것이다.두 가지 모두 단어/문구의 의미를 알 수 있도록 동일한 설명(또는 좋은 링크)을 요구한다. 이름 변경으로 명확성이 제공되지 않는다.--Fuhgetaboutit (대화) 23:40, 2011년 6월 9일 (UTC)[응답]

너의 요점을 조금 더 설명해줘서 고마워.요점: 나는 어떤 용어를 사용하든, 그것이 정확히 무엇을 의미하는지 이해하기 위해 그들이 약간의 설명을 요구할 것이라는 것에 동의한다.그러나 나는 그 용어 자체가 무관하다는 것에 동의하지 않는다.사용자들은 여전히 "편집자"와 "완전한 편집자"를 구분하는 것이 무엇인지 정확히 이해하기 위해 설명이 필요하겠지만, 이 단어들의 본질적인 의미는 최소한 그것이 어떤 종류의 차이인지 단서를 준다.이 용어를 바꾸면 미묘한 변화가 있겠지만 중요한 변화가 될 것이라고 생각한다.—Tim Pierce (토크) 02:03, 2011년 6월 10일 (UTC)[응답]

오토콘 확증은 단서들을 제공한다: 그것은 일종의 접속 수준이고, 그것은 기술적인 것이고, 자동적이라는 것이다.대조적으로, 완전한/어른/확립된 모든 것은 어떤 과정을 통해 동료 편집자가 되는 것으로 판단됨으로써 한 단계 더 높은 수준을 얻어야 한다는 인상을 줄 수 있다.그건 별로 좋은 인상을 주지 않는 것 같아.그래서 어떤 이름이 필요할지라도 제목에 의해 단서가 제공될 정도까지는 물살이 제시된 것보다 우월하다고 생각한다.--Fuhgetaboutit (토크) 11:38, 2011년 6월 10일 (UTC)[응답]

나는 마지막 논평에 동의한다.나는 우리의 담화에서 위키 자르곤을 없애는 것에 전적으로 찬성하지만, 이 경우 우리가 생각하기에 다른 어떤 것도 더 잘 될 것 같지는 않다.--코트니스키 (토크) 11:42, 2011년 6월 10일 (UTC)[응답]

수습?임시? ---— Gadget850 (Ed) 17:06, 2011년 6월 10일 (UTC)[응답]

• 우리는 "자동 확증"이라는 단어를 바꿀 필요가 없다.관련 도움말/프로젝트 공간 페이지를 모두 "확인된 사용자"에서 "최소한 4일 이상 된 사용자 계정"으로 변경하면 된다.더 길고, 그래, 하지만 더 확실해.만약 누군가가 페이지를 어떻게 움직이는지를 묻는 위키피디아-엔헬프(wikipedia-en-help)에 들어가게 되면, "확증/기타 용어 자동 확인이 필요하다"고 말하고 나서 그 용어가 무엇을 의미하는지 설명하는 것은 의미가 없다."당신의 계정은 적어도 4일 이상이어야 하고, 10번 수정해야 하는데, 이제 어떤 페이지를 재표기하고 싶은지 말해주면 내가 대신 할 수 있다"고 말하는 것이 시간 절약이라는 것을 알았다.이렇게 하면 도움을 받으려는 신규 사용자들의 전문용어는 없앨 수 있지만, 기술적인 것에 대한 토론을 할 때는 기술적 명칭은 그대로 유지할 수 있다. /ƒETECCOMMS/18:32, 2011년 6월 10일 (UTC)[응답]

  이것은 좋은 생각이다.새로운 사용자가 실제로 이름을 변경할 필요 없이("전체 편집기"는 변경되지 않는다. 심지어 이 이름을 바꾸려면 비용을 지불해야 하는 것처럼 들릴 수도 있다.잘 했어요구구오12 (토크) 18:50, 2011년 6월 10일 (UTC)[응답]

  나도 동의해, 이것은 우리가 취할 수 있는 최선의 행동 방침이야. (적어도 지금까지 언급된 것 중에서)Ajraddatz (토크) 23:03, 2011년 6월 10일 (UTC)[응답]

  내 생각에 그것은 지금까지의 가장 좋은 해결책이며, 실제로 합의에 도달할 수 있는 어떤 것에 의해 두들겨 맞을 것 같지 않다.Rd232^talk 05:45, 2011년 6월 11일 (UTC)[응답]

  응, 하지만 난 여전히 "자율확증"을 괄호 안에 넣고 싶어. 개념이 가장 잘 설명되는 곳이라면 어디든 위키링크가 되어 있어 - 그렇게 하면 사람들은 그것에 당황하지 않고 전문용어를 배울 기회를 가질 수 있어. - 코트니스키 (토크) 10:11, 6월 2일.011 (UTC)[응답하라]

• 모든 포괄적인 용어는 설명이 필요하므로 이름을 바꾸는 것을 반대한다.지금까지의 모든 다른 선택사항에는 결함이 있다.예를 들어, "설립된 사용자"는 4일, 10일 편집과 같지 않으며, 등록되지 않은 사용자가 수년에 걸쳐 동일한 IP로 편집하는 경우, 가능한 경우보다, 등록한 사용자보다 더 많이 설정되게 된다. 82.131.238.34 (토크) 17:39, 2011년 6월 12일 (UTC)[응답]

• 지지하다.엄한 용어야...편집이 1만 건인데 아직도 무슨 뜻인지 모르겠다TCO(토크) 23:23, 2011년 6월 18일 (UTC)[응답]
• 반대한다, 적어도 새로운 사용자들과 IP들이 처음부터 새롭게 변화하고 있는 것처럼 보이게 하는 어떤 용어라도 말이다.더욱이 위의 IP는 하나의 제안에 대해 좋은 지적을 하고 있다.–MuZemike 09:29, 2011년 6월 20일 (UTC)[응답]
• 반대한다. 나는 항상 WP에 접속한다.AutoCONFILE은 새로운 사용자에게 Autocon이 확인되었다고 말할 때 많은 도움말 페이지도 확인된다.그렇지 않은 사람들은, 그래야 한다.어떤 용어도 실제로 "최소한 4일 10번의 편집"을 말하지 않고는 의미를 정확하게 전달할 수 없다(그리고 그 한계는 바뀔 수 있고 누구에게나 적용되지 않는다)."확증"은 많은 사람들에게 실마리를 주고, 그것이 연결되지 않으면 사람들이 물어보거나 찾을 수 있도록 기술적 용어라는 인상을 준다."설립"과 다른 일반적인 단어들은 기술적으로 들리지 않기 때문에 많은 사람들은 그것이 정확히 정의된 의미를 가지고 있다는 것을 깨닫지 못할 것이다."확증"은 다른 위키에서 많은 사람들에 의해서도 알려지고 소프트웨어에 의해 많은 곳에서 쓰여지기 때문에 우리는 우리 자신의 용어를 만들기 위해 강한 이유가 필요하다.프라임헌터 (대화) 22:35, 2011년 6월 20일 (UTC)[응답]

하위 페이지를 사용하도록 TfD 변경

현재 WP에서 구체적인 논의를 따르기는 정말 어렵다.TFD. AfD처럼 하위 페이지를 사용하도록 페이지를 수정해야 한다.이것은 특정 TfD를 따르는 것을 훨씬 더 쉽게 만들 것이다.야마구치 도시오 (토크) 18:35, 2011년 6월 20일 (UTC)[응답]

아니... TFD에서의 활동은 위축되고 흘러가고 있어, 보통은 지난 한 주 정도 지난 것 처럼 그렇게 활발하지 않아.게다가 하루치 공천도 한 번에 볼 수 있다는 것도 알고 계시죠?TFD 페이지 전체를 볼 필요는 없다.
— V = IR(Talk • 기여) 18:47, 2011년 6월 20일 (UTC)[응답]

꽤 짧은 페이지에 4개 섹션 중 하나로 스크롤하여 마지막으로 본 이후 댓글을 단 사람이 있는지 확인하는 것은 정말 어려운 일이다.그러한 시나리오에 있는 것이 매우 고통스럽다는 것은 인정하지만, Ω의 법칙에 따르면, 그러한 변화를 원격으로 가치 있게 만들 수 있는 TfDs(확실히 긴 TfDs는 충분하지 않음)가 충분하지 않다.╟-TreasuryTagesconsult-consults-18:50, 2011년 6월 20일 (UTC)[응답]

그래, 그건 "정말 어려운"게 아니야.그것은 단지 조금 불편하다.하지만 나는 위키피디아가 이것보다 더 심각한 문제들을 가지고 있다는 것에 동의한다.따라서 이를 WP에 따라 해결된 것으로 간주하십시오.돈픽스잇. :) 야마구치 도시오 (토크) 18:57, 2011년 6월 20일 (UTC)[응답]

파일 이름에 대한 몇 가지 변경 사항

나는 위키피디아에서 파일명칭과 관련된 몇 가지 문제들을 확인했고, 그것들이 고쳐지는 것이 우선되어야 한다고 믿는다.다음 구성 요소:

• 이미지 이름의 대소문자 구분:현재 상태로는 3명의 별도 사용자들이 파일이라고 불리는 3개의 개별 피사체의 3개의 별도 이미지를 업로드할 수 있다.TestImage.jpg, 파일:TeStimAgE.jpg 및 파일:추천장.jpg.파일 이름이 대소문자를 구분해야 할 이유는 없다.

• 동일한 파일 형식에 대한 다중 파일 형식 확장명:현재 상태로는 두 명의 별도 사용자가 두 개의 개별 피사체의 두 개의 별도 이미지를 File(파일)로 업로드할 수 있다.TestImage.jpg 및 파일:TestImage.jpeg.이럴 까닭이 없다.

• 파일 형식 확장명의 대소문자 구분:현재 상태와 최근 두 번 이상 보았듯이 두 개의 별도 영상을 File(파일)로 업로드할 수 있다.TestImage.jpg 및 파일:테스트이미지.JPG. 이것은 위의 상황에서 훨씬 더 많은 문제를 일으킬 수 있는 잠재력을 가지고 있다.파일 형식 확장이 대소문자를 구분해야 할 이유는 없다.

이게 왜 중요한가?이것은 혼란스러운 상황을 계속 야기시켰다 할 것이다.사람들은 동일한 이미지를 찾고 있고 본질적으로 거의 동일한 이름에서 찾을 수 없기 때문에 동일한 이미지의 복사본을 여러 개 업로드한다.파일을 업로드한 사용자의 직관에 반하는 경우:TestImage.jpg에서 이미지를 찾지 못하였을 때 파일:테스트이미지.JPG. 대신, 매번 사용자들, 특히 새로운 사용자들은 업로드가 고착되지 않았다고 가정하고 같은 이미지를 다시 업로드한다.그들은 이미 그 이미지가 거기 있다는 통보를 받는데, 이미 찾아봤고 찾지 못했기 때문에 혼란스럽다.나는 또한 누군가가 기사에 이미지를 넣으려 하고, 어딘가에서 사건을 잘못 이해한 다음 이미지가 나타나지 않아 당황하는 경우를 보아왔다.

실현 가능한지는 모르겠지만 커뮤니티가 할 만하다고 판단하고 코디네이터가 실현 가능하다고 판단한다면 이미지 이름과 파일 형식 확장명 모두에서 케이스 감도를 없애고 싶다.또한 일정한 파일형 확장자(JPG, jpg, Jpg, Jpg 등)의 모든 반복이 상호 교환적으로 기능할 수 있도록 어떤 종류의 패치를 넣었으면 한다.

생각?스벤망구아르드화?08:24, 2011년 5월 31일 (UTC)[응답]

부록:여기서 실행된다면, 이것은 하원의 파일에 영향을 미치지 않을 것이다.따라서 이 논의의 결론에서, 만약 그것이 성공적이라면, 나는 개발자들에게 WMF를 넓게 구현할 수 있는지 물어보거나, 그들이 원한다면, 하원에서 동일한 스레드를 시작할 것이다.나는 지금까지 그런 생각을 하지 못했어.미안하지만 Sven Manguard Wha? 19:05, 2011년 5월 31일 (UTC)[답글]

나는 이 모든 점, 특히 2번에는 많은 혼란을 야기할 가능성이 있다는 점에 동의한다.Oddbodz (대화) 08:35, 2011년 5월 31일 (UTC)[응답]

전적으로 동의한다.기사 기능을 파일로 강제할 이유가 없고, 파일 이동이 가능해진 지금, 프로젝트를 광범위하게 수정하는 것은 간단할 것이다.▫ 조니미르닌자 09:20, 2011년 5월 31일 (UTC)[응답]

나는 봇이 이름 충돌을 확인하고 백엔드 코드를 처리하면 나머지는 봇이 할 수 있기를 바란다.파일 확인:예.jpg 및 이미지:예.jpg는 문서공간의 상호작용을 하기 때문에, 적어도 여기서 세 가지 사항 중 두 번째에 대해서는, 동일한 상황(모든 형태의 파일 형식은 상호작용이 가능함)이 완성될 수 있기를 바라고 있었다.스벤망구아르드화?18:54, 2011년 5월 31일 (UTC)[응답]

• 서포트 2,3.대소문자를 구분하고 "동기식"을 확장하는 것은 혼란만 일으킬 수 있고 실질적인 이점은 없다.대/소문자를 구분하지 않는 파일 이름을 사용하는 것이 이 시점에서 실현 가능한지 확신할 수 없다.파일:AIR.jpg 및 파일:Air.jpg는 일부 조직 AIR을 의미하고 다른 조직 AIR은 공기 구성요소 차트 등을 의미한다.그것이 만들어낼 혼란과 업무량은 실제 이익을 과중하게 할 수도 있다.하지만 난 추측하는 법을 배웠어. 이미지로 많이 일하고 움직이는 사람이 코멘트를 해야 해.— HELLKOWNZ ▎TALK 09:41, 2011년 5월 31일 (UTC)[응답]
  • 충돌이 너무 많은 경우 하나의 해결책은 현재 파일이 영향을 받지 않도록 하는 반면, 동일한 이름이 다른 사례 구성에 존재하는 경우(사용자가 File과 같은 이름으로 더 이상 이미지를 업로드할 수 없는 방법과 유사함) 향후 파일을 업로드할 수 없는 경우,IMG0002.jpg, 그러나 이미 이렇게 이름이 붙여진 파일들은 변함이 없다.여기서 구현하려면 다른 솔루션이 필요하다는 것을 알지만, 개념은 같다.)스벤망구아르드화?18:59, 2011년 5월 31일 (UTC)[응답]

• H3llkn0wz당 2,3을 지지한다.나는 소급해서 파일명 사건 불감증을 추가하는 것은 너무 골치 아픈 일이라고 생각한다.[부록:새로운 업로드에만 적용하도록 하는 Sven의 제안은 괜찮을 것이다.]Rd232 09:52, 2011년 5월 31일 (UTC)[응답]
• 지원 - 나도 같은 생각을 해봤어. --쿠미오코(토크) 11:14, 2011년 5월 31일 (UTC)[응답]
• 업로드 시 이러한 파일이 있는 경우 사용자는 최소한 기존 파일을 인식할 수 있도록 중요한 경고를 받아야 한다.Graeme Bartlett (대화) 23:38, 2011년 5월 31일 (UTC)[응답]
• 이 논의는 메타에 관한 것이어야 하지 않을까, 아니면 커먼스에 관한 것이어야 하지 않을까?영어 위키백과만을 위해 이것을 바꾸는 것은 대부분 무의미하고 일관성이 없다.미스터 지맨 00:11, 2011년 6월 1일 (UTC)[응답]
  • 응, 얼마 전에 생각났어.하지만 개발자들은 어떤 것을 바꾸기 전에 합의를 보는 경향이 있기 때문에, 우리가 그들에게 더 많은 합의를 보여줄수록, 그들은 더 많은 해결책을 실행할 가능성이 높기 때문에, 여기서 지원을 받기로 하자.스벤망구아르 Wha? 00:40, 2011년 6월 1일 (UTC)[응답]

FYY: BugZilla bug 4421에 게시하라는 말을 듣고 그렇게 했다.스벤망구아르드화?05:39, 2011년 6월 1일 (UTC)[응답]

• 지정된 3가지 사례 모두에 대한 지원 수정H3llkn0wz는 vs에 AIR.jpg 대해 합리적인 우려를 가지고 있다. Air.jpg 그러나 스벤이 그러한 성격의 기존 갈등에서 그들을 해결할 수 있을 때까지 할아버지에게 제안한 것은 그것에 대한 나의 걱정을 덜어준다.두통과 혼동을 요구하는 두안디 Disney Logo.png Disney logo.png 모두로 (예를 들어 구성하기 위해) 별도의 이미지를 업로드할 수 있도록 허용한다.28바이트 (대화) 05:49, 2011년 6월 1일 (UTC)[응답]

  내가 알기로는 우리 역시 하원과 충돌하는 파일을 업로드하는 비슷한 블록을 가지고 있지만, 기존의 갈등은 수정될 때까지 남아 있다.▫ 조니미르닌자 06:07, 2011년 6월 1일 (UTC)[응답]

  나는 나쁜 이미지 이름을 고치는 것을 끝마치는 대로, 공유 충돌 문제를 해결할 작정이다(그 중 3000개가 있다, 지금 내가 다루고 있는 것의 샘플은 사용자:Chz/dsc0511을 참조하라).만약 이것이 승인되고, 갈등의 수가 합리적으로 결정된다면, 나도 공동의 갈등에 도달하기 전에 그것에 대해 연구할 것이다.파일오버의 좋은 점은 이전에 비관리자들이 접근할 수 없었던 업무인 대규모 백로그를 정리하는데 적극적으로 도움을 주고 있는 사람들이 6명이라는 점이다.나는 명명 충돌이 장기간의 골칫거리라고 생각하지 않아, 만약 이것이 통과된다면 그것들은 꽤 빨리 치워질 수 있어.스벤망가드 화? 23:45, 2011년 6월 1일 (UTC)[응답]

• 위의 3가지 모두를 지지하십시오.해당 파일인 경우:미란다 커.jpg vs 파일:미란다 커.JPG. 현재 우리가 파일을 가지고 있지 않은 것은 행운일 뿐이다.미란다 커.jpeg 및 파일:미란다 커.JPEG도 ;-) 비논리적! --Ohconfucius 08:00, 2011년 6월 2일 (UTC)[응답]
• 지원 2&3 일부 파일에는 이름을 구분해야 한다.—제임스 • 오후 10:08 • 12:08, 2011년 6월 2일 (UTC)[응답]
• 지지 나는 비슷한 실수의 희생자가 되어 왔으며, 그것을 정리하는 데 얼마나 오랜 시간이 걸리는지 답답하다. 왜냐하면 나는 근본적으로 사건이 중요하지 않을 것이라고 가정했기 때문에, 그것을 추적하는 일은 전혀 떠오르지 않았기 때문이다.--SPHILbrickT 22:29, 2011년 6월 2일 (UTC)[응답]
• 논평 - 위의 링크드 버그는 2005년에 처음 제기되었다.구현되는 것을 보고 싶다면 여기서만 지지하지 말고 bugzilla:4421에 로그인하여 투표하십시오.이것은 개발자들이 그것이 얼마나 많은 지지를 받고 있는지 볼 수 있게 해줄 것이다.〇 조니미르닌자 08:04, 2011년 6월 3일 (UTC)[응답]
• 지원, 이미지 추가하기 싫고, 여러 번 윗글자 찾아봐야 해. mabdul 08:52, 2011년 6월 4일 (UTC)[응답]
• 지원 2와 3은 상당히 논리적이기 때문에 다른 케이스에 다른 파일을 업로드해야 하는 정당한 이유가 있을 수 있다는 점에서 1에 대해서는 잘 모르겠다.—mc10 (t/c) 00:56, 2011년 6월 7일 (UTC)[응답]
• 모든 프로젝트, 특히 하원에서 이러한 변경이 이루어지면 지원한다.우리는 다른 프로젝트에서 다른 기능을 필요로 하지 않는다.또한, 대량 이름 변경은 어떻게 처리될 것인지에 대해 논의해야 한다; 확장명 전에 새로운 파일 이름 끝에 "1"을 추가하라.르만 08:37, 2011년 6월 9일 (UTC)[응답]
• 반대 2,3 - 파일 이름 확장명은 복음이 아니다.MIME 연결은 파일 형식을 결정한다.사용자들은 그들이 하는 방식으로 파일 이름을 짓기 위한 좋은 이유가 있을 수 있다.제이슨 퀸 (토크) 07:49, 2011년 6월 16일 (UTC)[응답]
  • 넌 날 잃었어.위키피디아는 푸를 다룬다.JPG와 Foo.jpg, Foo.jpeg는 모두 파일 형식이 같기 때문에 동일하다.다른 것들보다 하나를 선택하는 좋은 이유, 만약 저 세 명의 Foo가 완전히 다른 세 가지라면, 그리고 그들 사이에서 구별할 수 있는 유일한 방법은 파일 형식 확장자뿐이라면, 음, 그건 말도 안 되는 소리야.스벤망구아르화?08:31, 2011년 6월 16일 (UTC)[응답]
    • 그렇구나. 내가 의도를 잘못 이해했구나.내선형 하나만 사용하는 줄 알았는데.나는 반대 입장을 철회한다.제이슨 퀸 (대화) 05:53, 2011년 6월 17일 (UTC)[응답]
• 모든 프로젝트 - 이 프로젝트만 반대하면 지원 - 포인트 1과 3은 이름이 이미 존재하는지 확인하기 전에 이름을 소문자 또는 대문자로 변환하는 문제일 뿐이다.2번 포인트는 더 이상 일하지 않을 겁니다.알렌22 (대화) 18:32, 2011년 6월 22일 (UTC)[응답]

폐쇄된 AfD 논의를 영구적으로 보호

폐쇄적인 AfD 토론은 위에 다음과 같은 메시지를 전달한다.

다음의 논의는 아래 기사의 삭제 제안에 대한 보관 토론이다.수정하지 마십시오.후속 코멘트는 해당 토론 페이지(기사의 토크 페이지 또는 삭제 검토 등)에서 작성해야 한다.이 페이지를 더 이상 편집하지 마십시오.

마무리하는 행정관이 단순히 토론을 다시 잠그는 것이 낫지 않을까?야마구치 도시오 (토크) 2011년 6월 9일 (UTC) 14시 11분[응답]

나는 그것이 필요하다고 생각하지 않는다.폐쇄 후 일부 의견이 추가돼 아무도 눈치채지 못하고 다른 공감대가 있는 것처럼 행동하려 해도 페이지 히스토리가 캄발라체로(토크) 15:09, 2011년 6월 9일(UTC)의 꼼수를 드러낼 것이다[응답].

때때로 보관된 토론은 링크를 변경하기 위해 이름을 바꾼 편집자 또는 이동된 기사에 대해 변경되어야 한다.프람 (대화) 15:14, 2011년 6월 9일 (UTC)[응답]

또 다른 유력한 사례는 사람들이 토론 중에 카테고리를 인용할 때 있다.때때로 그들은 [[카테고리:Foo]] 대신 [[:카테고리:Foo]]("Category" 이전 포함)따라서 토론은 거기서 분류되며, 카테고리를 확인하는 누군가가 원하지 않는 항목에서 해당 카테고리를 삭제해야 할 것이다.캄발라체로 (대화) 15:23, 2011년 6월 9일 (UTC)[응답]

아니, 가끔 마무리하는 사람들이 기술적인 실수를 하기도 해때때로, "더 이상 코멘트 없음" 선에 따라, 색상 섹션 밖에서 만들어진 폐쇄 후 코멘트가 적절하다.때로는 후속 XfD 또는 DRV가 존재하며, 이를 주목하는 것이 매우 유용할 수 있다. 다만, 아래 트랙의 기록 검토자와 바로 이러한 이유로 XfD 페이지 감시 목록을 보관하는 참가자들에게는 매우 유용하다.

닫힌 XfD 페이지를 편집하는 데 문제가 있는가?그런 감시 목록을 수천 장이나 가지고 있는 것 같고, 정기적으로 감시 목록을 체크하는데, 옛날 페이지 편집에는 문제가 없다고 본다.대신 믿으면 믿을 수 있을 것 같아. --스모키조(토크) 13:19, 2011년 6월 12일 (UTC)[응답]

굳이 그럴 필요는 없을 것 같다.만약 폐쇄적인 AfDs가 문제적인 방법으로 편집되는 것에 심각한 문제가 있고 그러한 편집이 이러한 페이지들에 대한 좋은 편집보다 훨씬 더 빈번하다면, 그것은 필요할 것이다. 하지만, 나는 이러한 문제들이 사실 있다고 생각하지 않는다.2011년 6월 13일 (UTC) עושוווו Od Mishehu 07:36, odreplyreply[[응답]

실제로 AfDs용 MediaWiki 플러그인이 있어야만 그들의 페이지가 바닐라 위키백과만이 아니라 적절한 사용자 정의 워크플로우를 가질 수 있다.군단 미디어위키 중 한 명. --사이버코브라 (대화) 22:22, 2011년 6월 19일 (UTC)[응답]

"기사가 삭제 대상으로 지목됐다"고 했다가 결과가 유지됐다고 했을 때 논의에 나서는 것이 상당히 흥미롭다는 이유만으로 비공개 삭제 논의의 재잠금을 반대한다.오직 나의 보잘것없는 견해만 - 내가 여기서 오해한 것이 있으면 나에게 알려라.ACEOREVIVEED (토크) 20:08, 2011년 6월 22일 (UTC)[응답]

특수 편집 제한에 대한 경고

나는 최근에 무심코 한 번 되돌리는 제한을 어겼어.문제는 편집 페이지의 맨 위에 경고가 올라오지만 편집 디프피를 볼 때 롤백 버튼만 누르면 안 뜨는다는 점이다.되돌리기 버튼이 표시되는 페이지나, 그런 버튼을 누른 후에 다른 페이지에 제한을 두는 것이 합리적인가?고마워요.Dmcq (대화) 22:45, 2011년 6월 18일 (UTC)[응답]

여기서 바보처럼 굴려는 건 아니지만...만약 당신이 어떤 종류의 편집 제한을 받는다면, 당신은 도대체 롤백을 어떻게 사용하는가?O_o
— V = IR(Talk • 기여) 23:30, 2011년 6월 18일 (UTC)[응답]

나는 그 지역의 일반적인 제재/arb com 판결이 (기후 변화 등) 언급되고 있다고 생각한다.토크 페이지의 경고, 편집 화면의 경고, 명확한 경고 없이 블록을 먼저 분리하지 않는 정책 등이 그렇듯이, 아마도 나에게는 충분할 것 같다.안녕하십니까, 밥 하우스 884 (대화) 23:32, 2011년 6월 18일 (UTC)[응답]

알았어, 이해할 수 있어.하지만, 나는 그것이 그 질문을 더욱 구걸한다고 생각한다.어떤 종류의 제약이 있는 페이지를 작업하고 있다면, 도대체 롤백으로 무엇을 하고 있는 것이다.그리고, 나는 어떤 관리자나 중재자가 페이지가 제한되어 있든 없든 간에, 노골적인 일련의 반달 편집들을 철회하는 것에 반대할 것이라고 의심한다.
— V = IR(Talk • 기여) 23:38, 2011년 6월 18일 (UTC)[응답]

사람이 글에 바보 같은 것을 끼워넣는다면 무엇을 사용해야 할까?토크 페이지에는 1rr라고 적혀 있지 않고, 토크 페이지의 링크는 1r에 대해 말하는 그 어디에도 가리키지 않는다.롤백을 사용하면 경고가 나타나지 않는다.내가 말하는 것은 롤백을 사용할 경우 경고하는 것이다.그리고 사실 그런 기사들에 대한 포괄적 1rr 제약이 있는 것 같지는 않은데, 그것은 단지 어떤 이유에서인지 그 특정 기사에 붙어서 내가 아는 어느 곳에서도 주목받지 못했다.그나저나 네 질문은 내가 제안했던 것과 무슨 상관이 있니?지뢰 같은 것들을 숨기고 싶으세요?Dmcq (대화) 11:34, 2011년 6월 20일 (UTC)[응답]

그러나 그것들은 숨겨지지 않고, 편집 화면에 경고가 나타나고, 토크 페이지에서는 기사에 대한 제재가 있다는 것을 분명히 한다(그리고 롤백자는 기사에 대한 어떠한 제재도 롤백과 함께 극도의 주의를 요한다는 것을 알아야 한다).그렇다고 해도 경고 그 자체가 제재가 아니라 1RR을 알고 있다는 것을 분명히 하기 위해 경고 그 자체를 위반했다고 해서 차단될 수는 없다.제재에 대해 알고 있었거나 알고 있었어야 하는 것이 아니라면 누구도 1RR 위반으로 막을 수 없다는 것이다.이 경우 편집 화면과 토크 페이지 메모를 생략했음에도 기사의 특별 규칙을 분명히 알게 되었고 행정 조치가 취해지지 않았다.너는 동의하지 않을 수도 있지만 나는 그게 꽤 타이트하게 느껴져.안녕하십니까, 밥 하우스 884 (대화) 2011년 6월 20일 (UTC) 14:33[응답]

롤백을 하기 전에 정확히 어떻게 알아냈어야 했을까?Dmcq (대화) 18:18, 2011년 6월 20일 (UTC)[응답]

먼저 보고?어디가 혼동인지 이해가 안 돼, 여기.기사 전체에 경고가 도배된 것은 아닐지 몰라도...내 말은, 토크 페이지를 보는 데 10초가 걸릴 수도 있다는 거야.왜 모두들 롤백, 취소, 그리고 비슷한 것들을 사용하기 위해 항상 그렇게 서두르는 것일까?
— V = IR(Talk • 기여) 17:48, 2011년 6월 22일 (UTC)[응답]

"I LOVE CHEZEBURS!!!!!!!"와 같은 노골적인 반달리즘이 되돌아가야 하는지를 알기 위해 반드시 토크 페이지를 볼 필요는 없다.만약 여러분이 최근의 변화들을 순찰하고 있다면, 여러분의 목표는 몇 명의 독자들이 그것을 더 본 후에가 아니라, 지금 공공 기사에 특이한 상황이 있는지 주의 깊게 연구하기 전에 공공 기물을 제거하는 것을 의미한다고 할지라도, 공공 기물을 파괴하는 것을 제거하는 것이다.WhatamIdoing (대화) 22:00, 2011년 6월 22일 (UTC)[응답]

하지만 위에 덮혀 있다.아니야?
— V = IR(Talk • 기여) 22:57, 2011년 6월 22일 (UTC)[응답]

(충돌 편집)그것이 노골적인 공공 기물 파손이라면, 나는 누가 1RR 당 반대할지 의심스럽다.그게 아니라면...편집과 토크 페이지를 조사해야지 편집 내용을 자동으로 롤백하지 말아야 한다.— 당신을 먹여 살리는 손:^Bite 22:59, 2011년 6월 22일 (UTC)[응답]

사진에 태그가 지정된 핫링크

http://en.wikipedia.org/wiki/Riviera_Maya 태그가 지정된 개체의 항목(예: 리비에라 마야 지도에 있는 도시)에 연결하기 위해 지도/그림/사진의 요소를 클릭할 수 있는 것이 유용할 수 있다.Doc Martian (대화) 09:52, 2011년 6월 22일 (UTC)[응답]

WP:이미지 맵을 생성하면 비슷한 효과가 있다. - Jarry1250 15:56, 2011년 6월 22일 (UTC)[응답]

메인 페이지 흐림을 위한 최소 준비 시간에 대한 RfC

편집자들은 여기서 이 제안에 대해 토론하는 것을 환영한다.토니 (토크) 11시 7분, 2011년 6월 22일 (UTC)[응답]

영어로 번역된 방정식

[18]에 있는 마을 펌프 아이디어 연구소에서 이 아이디어를 보았다.그것은 위키피디아로부터 수학을 배우려고 노력하는 나와 적어도 다른 한 사람에게 정말 유용할 것이다.Σ

수학 연산자를 선택했을 때 수학 연산자의 의미를 설명하는 사용자/브라우저 플러그인이 있을 수 있지만, 수학을 영어로 일반 번역할 수 있는가?물론 1+1=2는 "1+1은 2"로 쓸 수 있지만, 구면 좌표에서 Navier-Stokes 방정식을 사용해 보십시오.당신의 "번역"은 너무 길어져서 이해할 수 없을 것이고, 그래서 아마 사람들이 애초에 수학을 발명했던 것일 것이다.요에닛(토크) 07:41, 2011년 6월 20일 (UTC)[응답]

당신은 그것을 사용할 수 있다.alt속성:<math alt="the divergence of B equals zero">\nabla \cdot \mathbf{B} = 0</math>$\nabla {\displaystyle \mathrm{}}$ ${\displaystyle \cdot }$ ${\displaystyle B\mathbf{}}$= ${\displaystyle 0}$ ${\displaystyle \nabla \cdot \mathbf {B} =0}$을(를) 부여한다$.$사실, 그것은 인라인 이미지를 지원하지 않는 화면 리더와 다른 브라우저들에게 권장된다.- A. di M._plé 20:38, 2011년 6월 23일 (UTC)[응답]

자동화된 도구를 사용하여 자동차의 모든 성능 정보 개선

나는 대부분의 기사가 성과에 대한 매우 자신 있는 정보를 제공하지 않는다는 것을 알게 되었고, 나는 심지어 이 성과 정보에 대해 정의된 쓰기 스타일이 없다는 것을 알게 되었다.

나는 모든 자동차의 성능 섹션이나 적어도 스포츠카에 포함되어야 할 약간의 사실 정보를 제안하고 싶다. 나는 그것이 많은 자동차 애호가들에게 유용한 정보를 제공할 수 있다고 생각한다. 당신은 한 장소에서 모든 정보를 찾을 수 있다.

성능 정보:

• 환경 조건:온도: Xc, 습도:Y%, 고도: Z 미터

속도 도달 시간(mph 또는 km/h는 중요하지 않음)

• 시속 0-30마일의 속도
• 시속 0~60마일의 속도
• 시속 0-100마일의 속도
• 0-200kmh

거리까지의 시간(또는 미터 단위의 거리, 상관 없음)

• 0-100m
• 0-1/8마일
• 0-1/4마일
• 0-1km

최고 속도: Wmph(또는 km/h)

내가 일하고 있는 (www.nxgtrsim.com) 같은 자동차 성능 시뮬레이터나 프리(Free)에 사용될 수 있는 다른 시뮬레이터로 아주 쉽게 할 수 있을 것이다. 내 생각에 그것은 매우 실제적인 결과를 제공하며 인터넷 전체에서 Free + Online + Advanced의 유일한 옵션이며 위키카들에게 많은 도움을 줄 수 있을 것이다.

왜 당신은 이러한 시뮬레이터를 신뢰할 수 있는 출처로 생각하는가?그리고 만약 그들이 신뢰할 수 있는 출처가 아니라면, 그들의 정보는 위키피디아에 포함되어서는 안 된다.프람 (대화) 09:28, 2011년 6월 23일 (UTC)[응답]

나는 이것이 하나의 영역 표준화가 필요하지 않다고 생각한다.우리는 우리가 적절하다고 생각하는 것을 인용할 수 있다.자동차의 성능을 정확하게(그리고 유용하게) 묘사하는 것은 분명히 가능한 일이며, 위키피디아는 모든 기사가 똑같다고 해서 별로 득이 되지 않는다고 생각한다.그러나 인포박스의 사용과 사용된 데이터는 표준화가 더 실현가능할 것이다.그랑디오스 (나, 말, 기여) 2011년 6월 23일 19:19, (UTC)[응답]

그런 식으로 하면 자동차 리뷰 프로그램/매거진을 위한 훌륭한 도구가 될 수 있을 겁니다. WP로서 잠재적으로 인용할 수 있을 겁니다.R.S. 시뮬레이터가 괜찮다면 그런 그룹들과 얘기해 보는 게 좋을 거야.만약 우리가 그것을 사용한다면, 그것은 거의 확실히 WP가 될 것이다.OR. 와보트9 (대화) 00:21, 2011년 6월 24일 (UTC)[응답]

위키 내부 연결 목록

여보세요

나는 종종 예술품을 대충 훑어본다.종종 나는 흥미로운 위키 링크들을 발견하곤 한다. 그러나 나는 그것들을 열지 않고, 그것들이 어디에 있는지 잊어버리거나, 단지 내가 열고 싶었던 예술적인 것을 잊어버린다.:) 그래서 나는 더 많은 이유로 (추적을 유지하는 것 또한) 그 아티펠 안에 있는 모든 링크의 알파벳 목록을 보는 것이 좋을 것이라고 생각했다.

예를 들어, http://en.wikipedia.org/wiki/Computer에서 나는 모든 링크의 목록을 원한다. 예를 들어, 관련 아티펠들

프로그램 가능한 기계 메모리 데이터

등등

194.9.246.48 (대화) 13:18, 2011년 6월 24일 (UTC)[응답]

여기에 있는 컴퓨터에 연결되는 모든 기사를 찾는 경우, 특수:WhatLinksHere/Computer.이 목록은 "여기에 링크된 내용"에서 도구 상자의 왼쪽에서 찾을 수 있다.만약 당신이 컴퓨터가 링크하는 모든 기사들의 알파벳 리스트를 찾고 있다면, 나는 그것이 어디에서도 행해지지 않는다고 생각한다.GB팬 (토크) 13:31, 2011년 6월 24일 (UTC)[응답]

여보세요

친절한 답변 고마워.대단히 고맙다.

나는 실제로 두 번째를 찾고 있었다. 왜냐하면 이것은 당신에게 멋진 마인드맵/관련 주제/예술의 네트워크 같은 것을 줄 것이기 때문이다.확실히 그것을 실행할 수 있는 방법이 있을 것이다.

하지만 덧붙여야 할 것은 "연락"으로 당신의 조언에 감사하다는 것이다.

좋은 시간 보내세요.

194.9.246.48 (대화) 14:48, 2011년 6월 24일 (UTC)[응답]

WP를 사용할 수 있다.AWB:컴퓨터가 링크하는 모든 페이지를 보기. @ 11:21, 14 Av 5771 / 2011년 8월 14일(UTC)

RFC: 스타일 구조 조정 매뉴얼 구현

편집자들은 RFC의 구현에 대한 논의가 있기 때문에 이 RFC를 다시 방문하는 데 관심이 있을 수 있다.

스타일 매뉴얼의 모든 부속 페이지를 WP:MOS의 하위 페이지로 만들어야 하는가?

그것은 크고, 엄청난 발전을 약속한다.모두가 참여할 수 있다면 좋겠지.노에티카^Tea? 00:58, 2011년 6월 25일 (UTC)[응답]

분쟁해결안게시판

사이드바에 새 페이지에 링크 추가

안녕, 나는 Special에 대한 링크를 제안한다.사이드바의 인터랙션 섹션에 새로운 페이지가 추가된다.우리는 최근 변경사항들이 연관되어 있고, 나는 그것을 페이지로 칭찬하는 것도 유용할 것 같아.AD 19:19, 2011년 6월 7일 (UTC)[응답]

나는 수개월 동안 그것을 원했다; 나는 그것이 NPP를 시작하도록 더 많은 사용자들을 끌어들이는데 도움이 될 것이라고 생각한다. 우리가 여전히 절실히 필요로 하는 변화를 구현하기 전까지는 말이다.북빛의 칼날 (話して下い) 21:44, 2011년 6월 7일 (UTC)[응답]

전적으로 동의한다. NPP를 할 때는 검색란에 매번 입력하는 것이 귀찮아서 사이드바에 새로운 페이지를 표시하는 가젯을 설치했다. / /ETECCOMMS/03:28, 2011년 6월 8일 (UTC)[응답]

그냥 감시 목록에 올려주면 안 될까?피터 잭슨 (토크) 2011년 6월 8일 (UTC) 14시 50분[응답]

특별관람객은 아무 것도 볼 수 없다.특수 페이지, 해당 문제에 대해 편집하지 마십시오.요에닛 (대화) 14:55, 2011년 6월 8일 (UTC)[응답]

그런 생각은 들지 않았다.내 리스트에는 프로젝트 공간에 있는 카테고리 & 페이지들이 포함되어 있어서, 나는 막연하게 당신이 무엇이든 가질 수 있을 거라고 생각했다.피터 잭슨 (토크) 15:21, 2011년 6월 9일 (UTC)[응답]

좋은 생각이야.나는 지금 WP를 묶는 것에 익숙하다.뉴(NEW)와 그 페이지의 첫 번째 링크를 두드리는 것은 별로 필요 없지만 몇 년 전이라면 고맙게 생각했을 것이다.--후게트 어바웃잇(토크) 22:41, 2011년 6월 8일 (UTC)[응답]

좋은 생각인 것 같군
— V = IR(Talk • 기여) 23:03, 2011년 6월 8일 (UTC)[응답]

그래, 이게 유용할 것 같아.Killiondude (대화) 23:07, 2011년 6월 8일 (UTC)[응답]

en.wp 방문자 중 특별함을 찾고 있는 사람 수:새 페이지 ?나는 결코 그곳을 방문하지 않는다.우리 엄마도 그럴까?사이드바는 소중한 공간이며, 모든 독자들에게 가장 필요하거나 가장 유용한 링크에 사용되어야 한다.나는 뉴 페이지가 그것에 적합한지 잘 모르겠다.—DJ (대화 • 기여) 2011년 6월 9일 (UTC) 16:47[응답]

사용자:위에서 언급한 대로, 새로운 페이지 등록자들은 그것에 광범위하게 의존한다.인터랙션 섹션에 있는 링크가 하나 더 있을 경우 사이드바에 방해가 되지 않으며 특수하지 않은 경우:새 페이지는 벽 페이지와 동떨어져 있다.
— V = IR(Talk • 기여) 16:55, 2011년 6월 9일 (UTC)[응답]

나는 사이드바의 라이브 피드가 완벽히 적절하다고 생각한다.사용자: 참조:The Josh/Scripts/NewPagePatrol.js.쿠드풍 กุผผ ( ((대화) 17:07, 2011년 6월 9일 (UTC)[응답]

@TheDJ: 만약 있다면 얼마나 많은 방문객들이 그곳에 영원히 있었던 최근 변화들을 찾고 있는가?AD 17:13, 2011년 6월 9일 (UTC)[응답]

나는 독자가 NewPage를 통한 최근 변화를 볼 것이라고 믿을 이유가 없다.둘 다 제시될 수 있다.위키피디아에 새로운 페이지가 만들어지는 것을 보는 것은 방문객들에게 흥미로울 것이라고 생각한다.그들이 지금 그것을 찾고 있지 않다고 해서 그들이 그것을 제시했을 때 링크를 클릭하지 않는다는 것을 의미하지는 않는다.Killiondude (대화) 17:25, 2011년 6월 9일 (UTC)[응답]

최근의 변화는 한 가지지만, 위키피디아를 편집하고 순찰하는 사람들보다 훨씬 더 많은 사람들이 위키피디아를 읽고 있다는 것을 잊지 말자.'새로운 페이지'라는 용어는 오해의 소지가 있다: '새로운 페이지'의 80%는 삭제될 수용되지 않는 페이지들이다. 우리는 정말로 일반 독자들의 관심을 그들에게 끌기를 원하는가?쿠드풍 กุผึ ( ((토크) 18:20, 2011년 6월 9일 (UTC)[응답]

80%? 어디서 났어?최근의 변화는 독자가 아닌 편집자를 위해 고안된 것이며, 우리가 주목하는 반달리즘과 같은 것들을 포함하고 있다.새로운 페이지는 정확한 이름이고, 그것이 무엇인지 정확히 말해준다.나는 우리가 거기에 최근 변화들을 가지고 있을 때 그것을 포함시키는 것에 대해 어떤 논쟁도 여전히 보지 않는다.AD 18:51, 2011년 6월 9일 (UTC)[응답]

"변화가 나쁘다는 것"이 여기서 좋은 주장이 아니라는 말씀이세요?아니라고 말해!;)
— V = IR(Talk • 기여) 20:09, 2011년 6월 9일(UTC)[응답]

에이킨, 우리는 페이지에 무슨 일이 일어나는지 알아보는 작업을 좀 해 보았는데, 새로운 편집자들이 쓴 메인 스페이스 페이지의 80%는 결국 6개월(대부분 일주일 안에) 안에 삭제된다.WhatamIdoing (대화) 01:52, 2011년 6월 10일 (UTC)[응답]

나를 전혀 놀라게 하지 않지만, 그 페이지들이 얼마나 좋은지는 그것이 유용한 연결고리를 만들 것인지 아닌지와 관련이 없다 - 의심할 여지 없이 그럴 것이다.AD 21:51, 2011년 6월 10일 (UTC)[응답]

나는 그것을 위해 .js 대본을 만들었다.사용자 공간에 있다.~~EBE123~20:01, 2011년 6월 14일 (UTC)[응답]

왜 디폴트가 안 되는지 아직도 모르겠어.AD 12:59, 2011년 6월 18일 (UTC)[응답]

사이드바에 새 페이지 링크를 추가했으면 한다.나는 이 제안에 동의한다.제임스500 (대화) 2011년 6월 23일 08:15 (UTC)[응답]

• 반대야, 아마 사이드바에 너무 많은 것들이 있을 거야.최근의 변화만으로도 충분하며(그리고 대부분의 위키에서 표준 링크), 맨 위에 새로운 페이지 링크가 있다.편집자의 경우 사용자 페이지에 새 페이지 링크를 추가하는 것이 쉽다.—쿠스마 (t·c) 08:28, 2011년 6월 23일 (UTC)[응답]

만약 당신의 컴퓨터가 내 것만큼 느렸다면, 당신은 내가 왜 나의 사용자 페이지에 있는 새로운 페이지로의 링크를 실용적으로 사용하지 않는지 깨닫게 될 것이다.제임스500 (대화) 06:13, 2011년 6월 26일 (UTC)[응답]

제안 - 사용자가 Special에 대한 링크를 활성화할 수 있도록 허용하는 방법:특수:의 가젯 섹션을 사용한 새 페이지:선호도.제임스500 (대화) 06:25, 2011년 6월 26일 (UTC)[응답]

블록 로그 주석

최근 Idea Lab 토론에 이어 "사용자 차단" 페이지(예: Special:블록/Rd232) 관련 사용자의 사용자 공간에 특정 이름의 페이지를 생성함.아이디어는 이 페이지가 완전히 보호되고 관리자가 향후 참조를 위해 명확한 링크와 노트를 제공하는 데 사용할 수 있다는 것이다.이것은 특히 경고, 편집 제한, 반복 및 관련될 수 있는 기타 사항에 유용할 수 있다.참고: 현재 코드(MediaWiki:Blockiptext)는 주석 페이지가 존재하는 경우에만 표시한다.접근방식이 바람직하다고 생각될 경우, 페이지를 작성하기 위한 링크를 제공하기 위해 변경될 수 있다.PS 내가 맞다면 관리자는 MediaWiki에 의해 보호되는 페이지를 만들 수 있다.비관리자에 의한 작성으로부터 이 유형의 페이지를 완전히 보호하는 데 사용될 수 있는 제목 블랙리스트.PPS 현재 하한은 사용자의 블록 로그에 주석 페이지를 표시하지 않을 수 있음(예: 특수:로그)는 덜 중요하며, JavaScript 또는 소프트웨어(cf T31324)에서 수정할 수 있다.Rd232 21:50, 2011년 6월 9일 (UTC)[응답]

유용한 아이디어일 수도 있지만, Monobook에서는 사이드바를 적어도 한 페이지 아래로 강제 이동한다(Special:블록/Rd232).Killiondude (대화) 21:59, 2011년 6월 9일 (UTC)[응답]

이는 템플릿 문제였다({{cot}/cob).템플릿을 제거해서 임시로 고쳤다.로그 항목을 페이지 아래로 너무 많이 밀어넣지 않도록 변환된 주석 페이지를 모자이크 처리해 주길 원했다.아마 좀 더 템플릿 기술을 가진 사람이 고칠 수 있을 것이다.Rd232^talk 22:21, 2011년 6월 9일 (UTC)[응답]

나는 이것이 좋은 생각이라고 생각한다.블록 로그(및 해당 사항에 대한 모든 로그)는 특정 버전의 페이지, 정자가 삭제한 페이지 또는 특정 사용자 또는 페이지의 로그 항목에 대한 링크를 가질 수 없다.2011년 6월 14일 (UTC) odododוווOd Mishehu 18:39, 2011년 6월 14일 (회신)

아니 그들은 할 수 있다.복사/붙여넣기는 놀라운 효과가 있다.문제는 캐릭터 제한이었다.Killiondude (대화) 18:45, 2011년 6월 14일 (UTC)[응답]

관리자가 아닌 사람이 페이지를 볼 수 있어야 하는가? -- 지우개헤드1 <토크> 19:09, 2011년 6월 20일 (UTC)[응답]

...아니다.
— V = IR(Talk • 기여) 22:01, 2011년 6월 20일 (UTC)[응답]

네, 투명성을 위해서.목표는 사용자의 블록 이력을 보다 명확하게 이해하는 것이다. 관리자만 이해하도록 제한할 이유는 없다. (어떠한 경우에도 AFAIK에서는 관리자가 페이지를 보기만 하도록 강제할 수 있는 현재 방법은 없다.)Rd232 공용^talk 00:13, 2011년 6월 26일 (UTC)[응답]

음... 이미 비관리자들에게 접근할 수 있어.특수 네임스페이스에 있는 페이지인데, 보기 또는 편집하기 위해 sysop 권한이 필요하다.
— V = IR(Talk • 기여) 01:39, 2011년 6월 26일 (UTC)[응답]

위에서 봤을 때 충분히 명확하지 않았던 것 같은데, 특집 기사:블록 비트는 편의를 위해 다른 곳에서 한 페이지를 로드하는 것뿐입니다.다른 곳에 관련 사용자의 사용자 공간에 있는 페이지 특수:Mypage/BlockLogannotation(이 때문에 사용자가 이러한 항목을 만들 수 없도록 제목 블랙리스트를 사용할 것을 제안했으며, 관리자가 페이지를 만들 때 페이지를 보호할 수 있음)Rd232 공개 02:15, 2011년 6월 26일 (UTC)[응답]

사용자 공간에서 페이지 이동

제안: 편집자는 페이지를 메인 스페이스(일반적으로 사용자 스페이스 초안 유형 페이지)로 이동할 때 리디렉션 생성을 억제하는 옵션을 허용한다.그것은 아마도 무해하고, 흔한 일이며, 쓸모없는 상호 공간 리디렉션을 방지한다.그것은 또한 많은 사용자들이 대신 사용자 공간 초안을 만들 것이기 때문에 비자동 확증 사용자들의 기사 작성에 대한 제한이 실행될 때 더 흔해질 것 같은 작업이다.Rd232 02:20, 2011년 6월 6일 (UTC)[응답]

• 나는 다른 페이지 이동으로 리디렉션을 억제하는 것을 여전히 허용하지 않으면서 이것의 기술적 특성에 대해 아무것도 모른다.만약 그것이 기술적으로 타당하다면, 나는 그것을 지지할 것이다.사람들이 애초에 원하지 않았던 교차 네임스페이스 리디렉션의 삭제를 요청해야 한다는 것은 꽤 어리석은 일인 것 같다.라디오프샬롯 03:38, 2011년 6월 6일 (UTC)[응답]
  • 좋은 생각이지만 허점을 넓힌다.사용자 공간에서 페이지를 이동한다는 것은 어떤 편집자도 쉽게 기사를 작성하고 WP를 둘러볼 수 있다는 것을 의미한다.NPP. 리디렉션을 억제하는 것은 관리자가 그것을 접할 가능성을 낮출 것이다.그게 투표에 부쳐야 할 이유인지 모르겠는데, 그냥 지적하는 겁니다.▫ 조니미르닌자 04:38, 2011년 6월 6일 (UTC)[응답]
    • "사용자 공간에서 페이지 이동"은 NPP 훨씬 이전인 수 세기 동안 존재했다.나의 과거 경험에서 사용자 대 메인 스페이스 리디렉션의 존재나 삭제는 어떤 식으로든 기사의 가시성에 영향을 미치지 않았다.그러나 두 가지 단점이 있었다: (a) NPP가 없음 = 노출이 적음 (b) 메인 스페이스 기사를 자신의 사용자 공간 초안이라고 생각하고 편집하면 망치기 쉽다.리디렉트를 삭제하면 후자는 없어지지만 실제로 큰 문제는 아니며, 그렇다면 리디렉션과 관련된 문제에 부딪힌 사람은 곧 {{db-user}}}을(를) 배우게 되지 않을까?NVO (대화) 05:03, 2011년 6월 6일 (UTC)[응답]
    • NPP의 명백한 결함을 지적하는군!사용자 공간에서 메인 스페이스로의 이동은 NPP에 나타나야 한다.그거 따로 제안할까?Rd232^talk 12:04, 2011년 6월 6일 (UTC)[응답]
      • 버그질라 벌레인데 지금 부넘버가 없어.어쨌든, 만약 그것을 발견한다면, 버질라에서 투표해라!프람 (토크) 2011년 6월 6일 (UTC) 12:14 [응답]
        • 아 예: T14363.나는 그것에 투표했다.Rd232 13:06, 2011년 6월 6일 (UTC)[응답]
        • 그리고 나는 방금 리디렉션을 취재하기 위해 T31286을 만들었는데 - 비슷한 NPP 허점이다.Rd232 16:28, 2011년 6월 6일 (UTC)[응답]
      • (갈등 편집) 며칠 전 내가 아이디어 연구실(여기)에서 그 정확한 문제를 꺼냈지만 지금까지 아무도 응답하지 않았다.리디렉션에서 확장된 기사에도 동일한 이슈가 존재한다. 둠가제 (토크) 12:15, 2011년 6월 6일 (UTC)[응답]

질문으로 돌아가자: 사용자 공간에서 이동하기 위한 NPP 허점이 고정된 경우(T14363) 우리는 이것이 일어나기를 원하는가?Rd232 10:26, 2011년 6월 9일 (UTC)[응답]

우리는 페이지 오버 그룹에 대한 제안이 있다.쓸모가 있을지도 모른다.~~EBE123~19:59, 2011년 6월 14일 (UTC)[응답]

사용자에서 메인 스페이스로 이동하는 새로운 페이지가 NPP에 입력되지 않는지 몰랐어.나는 그들이 그렇게 하는 것이 절대적으로 중요하다고 생각한다. 왜냐하면 이 허점이 더 널리 알려지면, 그것은 대량으로 이용될 것이기 때문이다.더 자발적인 반달, 사기꾼, 공격 페이지에 의해서가 아니라 하드코어 SEO 요원, 기업 스팸 발송자, 축구 팬, 차고 밴드, 자서전 작가들이 그들의 첫 번째 책이나 마을 의회에 입후보하는 것을 홍보한다.쿠드풍 กุผผ ( ((토크) 07:40, 2011년 6월 19일 (UTC)[응답]

나는 그것이 쓸모없는 교차 도메인 리디렉션인지 아닌지 의심한다.콘텐츠가 사용자 공간에 존재했고 현재 메인 스페이스에 존재한다면, 누군가는 사용자 스페이스 버전에 연결되었을 수 있으므로, 해당 링크는 메인 스페이스로 리디렉션되어야 한다.—톰 모리스 (대화) 2011년 6월 27일 (UTC) 19:13[응답]

유지되어야 할 유일한 링크는 메인 스페이스에 있는 링크들 뿐이며, 사용자 스페이스 기사와 연결되는 메인 스페이스 기사는 없으며, 추가된 링크는 매주 제거된다(Whichedia:데이터베이스 보고서/사용자 공간에 대한 링크가 포함된 문서)--Jac16888^Talk 19:19, 2011년 6월 27일(UTC)[응답]

너는 오해하고 있다.외부 위키백과에서 사용자 버전으로 링크.—톰 모리스 (대화) 21:34, 2011년 6월 27일 (UTC)[응답]

드롭다운의 "다른 모든 네임스페이스" 탭

현재 "사용자 기여" 페이지에 있는 것과 같은 드롭다운 메뉴를 사용하면 전체 네임스페이스별로 개별 네임스페이스별로 검색할 수 있다.사용자가 많은 경우, 사용자 기여의 절반 이상이 기사 네임스페이스에 있다.드롭다운 메뉴에 항목을 추가하여 기사 공간에 있는 기여를 제외한 모든 기여도를 한 번에 검색할 수 있는가?이러한 종류의 추가는 "새 페이지", "여기에 링크할 내용", "관련 변경사항" 등의 유사한 드롭다운 메뉴에서도 유용할 것이다.그루티니스...뭐라고? 02:13, 2011년 6월 26일 (UTC)[응답하라]

나는 이것이 좋은 생각이라고 생각한다; 그것은 꽤 오랜만이다.관련 버그는 2008년 6월부터 T16485로 복제된 4개가 있다.그것에 투표하는 것은 아무런 해가 될 수 없다.Rd232 공개 11:17, 2011년 6월 26일 (UTC)[응답]

카테고리 →'는 기사 하단에 있다.

나는 세탁물 리스트를 가장 싫어한다.오, 이런 내가 그들을 싫어해!왜 이렇게 많은 기사가 분류되는가 하면, 그 기사도 분류되는가?수행해야 할 작업을 보려면 다음 예제를 참조하십시오. 카테고리:강이요. 그럼 어떻게 하면 사람들이 너무 분류하지 않게 할 수 있을까?분류된 각 페이지의 하단에 다음과 같은 방법이 있다고 상상해 보십시오.

---

카테고리:

• 내용 → 기사 → 주요 주제 분류 → 지리 → 장소 → 유적지형 → 강 → 대륙별 강 → 유럽의 강 → 알바니아의 강
• 내용 → 기사 → 주요 주제 분류 → 지리 → 지리 관련 목록 → 대륙별 목록 → 유럽 관련 목록 → 알바니아 관련 목록

---

이상적으로는 상위 카테고리 사이의 최단 경로:내용 및 선택한 범주를 선택해야 한다.

그리고 물론, 실제로, 첫 번째 부모 수준만이 보여져야 한다.예:

---

카테고리: Rivers of Europe → Rivers of Albania Europe 관련 목록 → Albania 관련 목록

---

일반적으로 부모 수준은 하나만 보여줄 필요가 있다.

이것은 사람들이 기사를 지나치게 분류하는 것을 막을 것이다.이것은 또한 훨씬 더 멋지고 기능적인 윤곽이 만연된 표준이 되도록 만들 것이다.

서명됨, 세탁목록 hater, siNkarma86—Wipedia
^{86 = 19+9+14 + karma = 19+9+14 + talk} 03:24, 2011년 6월 27일 (UTC)[응답]

• 코멘트 이것은 기술적으로 비현실적일 수 있다: 그래프 통과는 일반적으로 올바르게 하기 어려운 일이고 구현하기 위해 MediaWiki 개발자들의 중요한 작업과 중요한 시스템 자원을 필요로 할 것이다.이것을 실행하는데 필요한 기술과 인적 자원을 정당화하기 위해서는 "오, 내가 그들을 싫어해!"보다 더 상세한 추리가 필요하다.—톰 모리스 (대화) 2011년 6월 27일 10시 20분 (UTC)[응답]
• 논평: 문제를 더 직접적으로 다루는 것이 더 실용적이지 않을까?문제는 페이지나 범주 A가 두 범주 X뿐만 아니라 X의 부모인 범주 Y에도 나타난다(때로는 이러한 행동이 바람직하지만, 대개는 그렇지 않다).아마도 위키백과:HotCat은 HotCat 사용자가 A를 방문할 때 이러한 경우에 플래그를 표시할 수 있다.Rd232 공개^talk 10:59, 2011년 6월 27일 (UTC)[응답]
  • 사용자들이 그러한 행동이 바람직한 경우(예: 많이 논의되고 가끔 이해되는 eponymous category 질문)에 대해 잘 알고 있는 한,--Kotniski (talk) 11:14, 2011년 6월 27일 (UTC)[응답]
    • 그들은 HotCat이 실제로 그렇게 할 수 있다는 것을 어떤 식으로든 확인되었는가?Rd232 공개 21:49, 2011년 6월 28일 (UTC)[응답]

샌드박스에서 편집 충돌 통지 제거

이것을 할 수 있는 기술이 있는지 확실하지 않지만, 여기 있다.오늘 밤(2011년 6월 28일) 나는 위키피디아에서 인용 방법을 시험해 보았다. 샌드박스는 "당신이 시작한 이후 다른 누군가가 이 편집 작업을 시작했으며 편집 충돌이 발생했다"는 메시지를 받았다.필자는 확실히 샌드박스에서 편집 충돌 태그가 기술적으로 가능하다면 제거해 줄 것을 간청한다.ACEOREVIVEED (토크) 19:18, 2011년 6월 28일 (UTC)[응답]

사실, 나는 어떤 사람이 올해 초(2011년)에 편집 분쟁에 대한 문제를 제기했던 것을 기억한다. - 무슨 일이 일어났는가?ACEOREVIVEED (토크) 2011년 6월 28일 (UTC) 19:19[응답]

나는 그것에 대해 잘 모르겠다, 나는 합리적으로 경험이 많은 사용자들이 메인 WP 샌드박스를 사용할 필요가 없다는 것을 알고 있다.유저박스 {{Mysandbox}}을(를) 두드려서 유저 서브 페이지 샌드박스를 쉽게 만들 수 있다.(이것은 아마도 어떤 관련 도움말 페이지 등에서 링크될 수 있을 것이다.얼마 전 PS I는 Javascript를 사용하여 모든 사용자가 자신의 하위 페이지 샌드박스에 쉽게 접근할 수 있도록 사용자 및 사용자 토크 페이지에 탭을 추가할 것을 제안했다.Rd232 공개 21:38, 2011년 6월 28일 (UTC)[응답]

그것에 대해 감사하다 - 사람들에게 그들 자신의 사용자 페이지에 그들 자신의 개인 샌드박스를 사용할 권리를 주는 것은 놀라운 생각인 것 같다.ACEOREVIVEED (토크) 23:08, 2011년 6월 28일 (UTC)[응답]

페이지 이동기

확장자 Pchart4mw 설치 - 차트 도면의 경우

단순(바만 해당) 차트 도면을 위한 <시간선> 확장자만 있으므로 Pchart4mw 확장자를 설치하여 다양한 유형의 실제 차트/그래프를 만들 수 있는 능력을 갖출 것을 제안한다.응원해줘서 고마워!--코주흐(토크) 11시 53분, 2011년 6월 19일 (UTC)[응답]

• 지원 나는 시험 위키 중 하나에서 먼저 그것을 시험해 보겠지만, 이 확장은 기사의 비주얼에 순긍정적인 것 같다.로건 07^{Contributions}:06, 2011년 6월 20일 (UTC)[응답]
• 지원 널리 사용되기 전에 일련의 테스트를 거치는 한 매우 유용한 기능인 것 같다(지원, 효율성, 출력...).그랜디오스 (나, 말, 기여) 2011년 6월 22일 12시 51분 (UTC)[응답하라]

나는 여기 EN 위키피디아에서 "확장 설치"가 얼마나 정확한지 모르지만, 나는 공동체 합의가 생식에 있어서 매우 중요한 부분이라고 생각한다.따라서, 우리가 합의를 이룬 후에 기술적 부분이 시작될 것이다. (아마도 코드 검토에서 확장되어 제대로 작동하는지 확인 등)누군가가 프로세스의 올바른 단계에 대한 정보를 제공할 수 있다면 이는 환영할 일이다.나도 작은 위키(예: 체코어 위키백과)에서 먼저 가능하게 할 생각이었으나, 아직 거기서 합의를 구하지 않았다.--코주흐(토크) 07:44, 2011년 6월 23일 (UTC)[응답]

• 강력한 지원 사용자가 외부에서 생성한 차트와 달리 데이터를 편집할 수 있게 한다.이것은 또한 시각적인 일관성을 가져올 것이다.그리고 마지막으로 이것은 파이처럼 쉽게 만드는 새로운 차트를 만들 것이다.— HELLKOWNZ ▎TALK 14:58, 2011년 6월 22일 (UTC)[응답]
• WP:Graphs에 열거된 (많은) 옵션과 어떻게 비교되는가?WhatamIdoing (대화) 22:07, 2011년 6월 22일 (UTC)[응답]

나는 "템플릿:시각화기" 또는 "템플릿:파이 차트" - 내가 보는 차이점 중 하나 - 이러한 차이점들은 툴서버에서 실행된다(어떤 경우 안정성과 가용성이 큰가?).훨씬 더 좋은 성적을 낼 수 있는 지역 연장이 될 것 같아. --Kozuch (토크) 07:44, 2011년 6월 23일 (UTC)[응답]

Pchart4mw는 차트 유형이 더 많은 것 같다.내 생각에 그것들은 또한 더 좋아 보이고 사용자 정의가 더 잘 되어 있다.InverseHypercube 00:57, 2011년 7월 1일 (UTC)[응답]

• 지원이 일리가 있다.그러나 우리는 아마도 연장의 사용을 설명하는 포괄적인 가이드를 가져야 할 것이다.—제임스 • 오후 3시 11분 • 05:11, 2011년 6월 26일 (UTC)[응답]
• 강력한 지원 그것은 매우 유용할 것이고 커먼스에 업로드되는 차트의 수를 줄일 것이다.또한, 채팅은 쉽게 편집될 수 있고 일관된 모습을 제공할 수 있다.InverseHypercube 00:49, 2011년 7월 1일 (UTC)[응답]

8월 7일 용서의 날

나는 "용서하는 날"을 생각하고 있었는데, 알고 보니 8월 7일[20일]이 하나 있다.그래서 나는 우리가 위키피디아에 이것을 채택할 것을 제안한다. 편집자들 사이에 평화와 선의의 확산을 돕고 그들이 과거의 갈등을 제쳐놓도록 격려하기 위해서.그 아이디어는 "국제 용서의 날을 기념하여 과거 분쟁에 기여한 것에 대해 유감스럽게 생각한다. 나는 우리가 이것을 뒤로 미루고 미래에 더 나은 협업을 이룰 수 있기를 바란다."(가장 중요한 것은, 훨씬 더 개선된 것은; 사용자들이 p를 추가하도록 장려하는 것을 잊지 않고)라는 일반적인 노선을 따라 사용자 템플릿을 만들겠다는 것이다.비인격적 부록.{{쿠키}}s 등이 원하는 사람들을 위한 옵션일 것이다.사용자들은 이 템플릿들을 그들이 약간의 의견 불일치를 겪은 사용자들을 위해 하루 중 또는 그 즈음에 남겨두도록 권장될 것이다.이것은 매년 감시목록 고시를 통해 가장 효과적인 광고가 될 것이다. 그러나 이 시점에서는 (아마도 미래에는) 약간 야심적일 것이다.그게 다야.Rd232 공개 23:35, 2011년 6월 25일 (UTC)[응답]

인간의 마음만이 누군가에게 기분에 따라 원한을 풀 수 있도록 해준다면, 그것은 아주 재미있을 것이다.그렇지 않기 때문에 결과는 (a) 완전히 무의미한 것이거나 (b) 객관식 시험보다 게임하기 쉬운 것이 될 것이다.아이언홀드 (대화) 23:55, 2011년 6월 25일 (UTC)[응답]

"만약 인간의 마음만이 누군가에게 즉흥적으로 원한을 풀 수 있도록 허락한다면..." - 용서가 무슨 뜻인지 다시 생각해 봐야 할 것 같아."게다가, 공공의 헌신은 사람들이 행동을 지속하도록 도와주기 때문에, 비록 그것이 모든 경우에 잘 풀리지 않더라도, 공공의 선언이 무의미하지는 않다.나는 게임이 어떻게 될지 모르겠다.Rd232 공개^talk 02:12, 2011년 6월 26일 (UTC)[응답]

나는 어느 정도 아이언홀드스에 동의한다.나는 더 이상 내가 싸운 많은 사람들에게 악의를 품지 않지만, 용서할 수 없는 것들이 있다.나는 우리가 이 문제를 좀 더 차분하게 논의하고 분쟁을 좀 더 원만하게 해결하기로 약속하는 날에도 적용할 수 있다고 생각한다. 하지만 그것은, 말하자면, NFCC 전쟁이나 그 어떤 종류의 분쟁도 막을 수 없을 것이다.스벤망구아르화?05:30, 2011년 6월 26일 (UTC)[응답]

"나는 우리가 이견을 드러내고 분쟁을 보다 우호적으로 해결하기로 약속하는 날에도 그것을 적응시킬 수 있을 것이라고 생각한다." - 그게 일반적인 생각이야.용서는 종종 필요하기 때문에 그것을 위한 좋은 출발점처럼 보이지만, 만약 누군가 다른 접근법을 제안하고 싶다면, 나는 제안을 받아들일 수 있다.근본적으로는 매년 "이러한 일을 뒤로 하고 정말 협력적으로 지내도록 다시 노력하자"는 날이 좋을 것 같다.Rd232 공개 11:26, 2011년 6월 26일 (UTC)[응답]

수술실 포스트에 있는 링크를 따라갔어"세계 용서 동맹은 비영리 501(c)3 세금 공제 기관이다."(나의 대담함)세계 인구의 95%에 대한 공제를 주선하지 않은 그들을 용서해야 할까?— HiLo48 (대화 • 기여) 05:47, 2011년 6월 26일 (UTC)[응답]에 의해 추가된 이전의 서명되지 않은 논평

나는 네가 호들갑을 떨며 네 목소리를 듣기 위해 좋은 생각을 해친 것을 용서한다.스벤망구아르화?06:19, 2011년 6월 26일 (UTC)[응답]

아첨꾼?맙소사.너의 편집증을 용서해 주겠다.HiLo48 (대화) 06:22, 2011년 6월 26일 (UTC)[응답]

조직이 어떤 식으로든 그 제안에 관여하지 않기 때문에 그것은 재미있지도 않고 관련성도 없다.내가 가지고 있던 아이디어인 '용서하는 날'을 찾다가 조직을 우연히 발견하게 되었는데, 이 아이디어가 떠올랐고, 누군가가 이미 홍보하고 있는 기존의 날짜를 사용하는 것이 이치에 맞는다(최소 처음부터 날짜를 고를 필요가 없도록 하기 위해서)이미 추진 중인 8월 7일에 대한 대안이 있다면 들어보시죠.Rd232 공개^talk 11:26, 2011년 6월 26일 (UTC)[응답]

내 생일에 넘어지는 장점이 있다.(그 점을 지적한 것에 대해 나를 포기하라!) :---짐보 웨일즈 (토크) 01:33, 2011년 6월 27일 (UTC)[응답]

저주! 사람들은 음모라고 생각할 것이다! :) rd232 공개 02:27, 2011년 6월 27일 (UTC)[응답]

모든 날이 예언의 날이어야 하지 않을까?용서한다는 것은 크나큰 기독교 덕목 중의 하나인데, 이 이상을 일 년의 삼백육십오 일 중 하나에 국한시킨다면 참으로 부끄러운 일이 아닐 수 없다.ACEOREVIVEED (토크) 2011년 6월 29일 18:21 (UTC)[응답]

반면에 우리 이교도들은.... --누진(대화) 19:27, 2011년 6월 30일 (UTC)[응답하라]

만약 사람의 행동을 관철하려고 노력한 후에도 여전히 만족스럽지 않다면, 나는 상당한 양의 응징이 요구된다고 생각한다. 그것이 없다면, 당신은 세상 돌아가는 것을 돕는다.그 후에는 현재 상황이 만족스러운지 확인해 봐야 한다.그렇다면 용서를 위한 특별한 날짜를 갖는 것이 정확히 무슨 의미가 있을까?언제 응징을 멈추어야 할지 모르는 사람들을 위한 것인지, 아니면 어떻게 해서든 자기 삶을 꾸려나갈 수 있도록 하는 것인지.Dmcq (대화) 21:06, 2011년 6월 30일 (UTC)[응답]

나는 용서에 찬성한다; 속임수는 아니다.나는 이것이 아무리 의도가 아닐지라도 속임수로 받아들여질까 봐 두렵다.

꼭 반대하지는 않는다.누가 알겠는가, 그것이 도움이 될지도 모른다.하지만 그것은 분명 몇몇 사람들이 눈을 굴리게 만들 것이다. --트로바토어 (대화) 00:34, 2011년 7월 1일 (UTC)[응답]

3RR의 편집 및 절단을 위한 템플릿 경고 분리 제안

몇 주 전 위키백과 강연에서 이런 제안을 했다.템플릿 메시지/사용자 대화 네임스페이스/아카이브 12#전쟁 및 파괴 3RR: 항상 같은 것은 아니며, 거부되지는 않았지만 큰 반응이 없었다.그래서 내가 느끼는 것을 매우 유용한 변화로 내버려두는 것이 부끄러운 일이라고 생각하면서, 나는 그것을 이곳으로 가져오기로 결정했다.내가 왜 이것이 유익하다고 생각하는지 자세한 내용은 링크를 참조하십시오.U-Mos (대화) 16:50, 2011년 6월 27일 (UTC)[응답]

템플릿:uw-3rr의 표현은 편집 전쟁이라는 비난을 함축하고 있기 때문에 별도의 템플릿이 필요하다는 것에 동의한다.당신이 지적했듯이, 항상 그렇지는 않으며 24시간 내에 복수 회전의 모든 경우에 자동적으로 가정되어서는 안 된다.--JayJasper (토크) 22:50, 2011년 6월 30일 (UTC)[응답]

보이콧

나는 리스트를 만들 것을 제안한다. 아마도 WP:의도적으로 그리고 반복적으로 위키피디아를 마케팅 자원으로 전환함으로써 위키피디아의 신뢰성과 유용성을 훼손하려는 기업들에 대한 보이콧.위키백과 독자들은 목록에 있는 어떤 사업과도 사업을 하는 것을 거절해야 할 것이다.현재 광고와 스팸메일은 되돌리고, 삭제되고, 블랙리스트에 올라가고, 편집자들은 차단되지만, 스팸메일이 잡히면 스팸메일 발송자들이 정확히 이전 위치에 있고, 그렇지 않으면 큰 보상을 받게 된다.대신에, 이러한 행동에는 심각한 현실적 결과가 있어야 하며, 스팸메일을 들키기 위해 위키피디아에 피해를 주는 것을 그들의 기업 정책의 일부로 만든 것에 대해 이 회사들을 보이콧하는 위키피디아 독자들이 충분히 있을 수 있다.제안된 포함 기준은 WP:G11을 만들거나 링크스팸에 참여하거나 중립적인 백과사전 콘텐츠를 보도 자료로 대체하거나 또는 이들을 대신하여 누구든 고용할 수 있는 자신에 대한 기사를 작성하는 회사일 것이다. 99.164.32.24 (대화) 09:48, 2011년 6월 29일 (UTC)[응답]

그러한 리스트는 아마도 경쟁사들을 대신해서 회사들이 스팸메일을 보내는 결과를 낳을 것이다. --에어랜드 (대화) 09:52, 2011년 6월 29일 (UTC)[응답]

맞아, 맞아.그것이 제대로 된 보안 컨설턴트의 진정한 정신이다.Dmcq (대화) 2011년 6월 29일 11시 14분 (UTC)[응답]

사실, 이런 종류의 일은 말하자면 "오프위키"가 더 잘 구현될 것이다.스팸 메일을 보내는 회사들의 목록을 모아서, 관심 있는 사람들과 공유하고, 위키피디아와 연결되지 않은 일을 할 수 있다. (블로그나 게시자를 통제할 수 있는 곳에서)당신이 왜 그들을 보이콧하는지 그 회사들에게 확실히 알려 줘.워보트9그것에 대해 말해봐....02:07, 2011년 6월 30일 (UTC)[응답하라]

Yair Land가 설명했듯이 이것은 악용될 것이다.정말 그럴 거야, 이건 농담이 아니야.그리고 그것은 용서받지 못한 결과도 아니었을 것이다.나는 이런 무고한 기업들에 대한 피해와 연관되고 싶지 않다.우리는 현재와 같이 스팸 발송자를 차단함으로써 문제를 직설적으로 처리하는 것이 더 낫다.

이렇게 되면 법적인 문제가 생기지 않을까?우리가 인지하고 되돌리고 차단해도 기업들은 스팸 발송자와의 관계를 쉽게 부인한 다음, 위키피디아가 자신들에 대해 음모를 꾸미고 있다고 비난할 수 있다.스팸메일 발송자를 "생활의 팩트"로 받아들이는 것이 더 나을 수 있는데, 이 스팸메일 발송자는 접근하지 못하게 해야 하지만, 캠발라체로 (대화) 14:27, 2011년 6월 30일 (UTC)[응답]을 완전히 지울 수는 없다.

정말 짧은 위키백과 URL

나는 위키피디아가 그들만의 기사 URL 단축 서비스를 받아야 한다고 생각한다.<250년판>에는 2천만 개의 기사가 실려 있다.따라서 6개의 영숫자 문자는 모두 나열할 수 있을 정도로 충분해야 한다(52^6 = 200억, 또는 언어당 7천만 기사).en.wikipedia.org/wiki/History_of_the_universe을 wkpshrt.org/5egF4w으로 변경하고 쉽게 공유하기 위해 방문하는 각 기사 페이지에 나타나는 자동 시스템은 어떠세요?그것은 다른 위키미디어 프로젝트에도 적용될 수 있다.어떻게 만들까? --NaBUru38 (대화) 22:52, 2011년 6월 21일 (UTC)[응답]

• 하지만, 위키미디어/미디어위키 소프트웨어가 이를 쉽게 수행할 수 있는 좋은 타사 도구가 있을 때 이를 구현해야 하는 충분한 이유가 있는가(TinyURL.com, bit.ly 등)?
  — V = IR(Talk • 기여) 23:11, 2011년 6월 21일 (UTC)[응답]

• • 일부 프로젝트에는 이미 URL이 약간 단축되어 있다는 점에 주목할 필요가 있다(http://enwp.org, 영어 위키백과 다른 것들도 있다.- Jarry1250^{[Weasel? Discuss.]} 14:10, 2011년 6월 22일 (UTC)[응답]
    • 예, enwp.org은 모든 WP 페이지(예: http://enwp.org/Barack_Obama)에서 사용할 수 있다.그리고 Wikinews 1은 enwn.net으로, 다르게 작동한다(더 bit.ly 서비스에 가깝다).그러나 나는 위와 같은 의견이다.제3자 서비스가 너무 많다.그리고 우리는 위키피디아를 덜 사회화 시키고 싶다.짧은 링크를 공유하고자 하는 사람은 누구나 이미 방법을 알고 있어야 한다. /ƒETCOMMS/16:10, 2011년 6월 22일 (UTC)[응답]

      ...왜 우리는 위키피디아를 덜 사회화시키고 싶어 하는가?아마 그게 네가 원하는 것일지도 몰라, 그건 괜찮아, 하지만 난 우리가 이미 우리보다 더 반사회적이 되는 것을 확실히 원하지 않아. :(
      — V = IR(Talk • 기여) 17:44, 2011년 6월 22일 (UTC)[응답]

우리 빅 브라더한테 모든 걸 해달라고 부탁하고 싶지 않은 것 같아.버스정류장 (토크) 17:55, 2011년 6월 22일 (UTC)[응답]

...아무도 그렇지가 않아, 너의 요점을 모르겠다.— 당신을 먹여 살리는 손:^Bite 2011년 6월 22일 23:00[응답]

나는 bit.ly의 접근법이 더 타당하다고 생각한다 - 링크는 누군가가 무언가를 연결하기를 원할 때만 주어진다.이와는 대조적으로, 당신의 접근방식은 연결되거나 연결되지 않은 모든 기사를 포함하며, 오직 기사만을 다룬다.예를 들어, 테스트로서 bit.ly/lNbS69은 이제 이 페이지의 특정 섹션을 편집하기 위한 링크를 제공한다.나는 등록하라는 요청을 받지 않았다.언제까지 지속될지는 모르겠지만 다재다능한 해결책처럼 보인다.하지만 이런 식으로 새로운 맞춤 링크를 만들고 보관하는 것이 위키피디아의 임무에 속할지는 잘 모르겠다.사실, 빅 브라더도 아마 듣고 있을 것이다. 하지만 안타깝게도, 위키백과나 다른 사이트에서도 마찬가지일 것이다.버지니아 레스턴을 통해 얼마나 많은 추적자들이 달리는지 봐, 그렇게 표현해봐.Wnt (토크) 05:18, 2011년 6월 27일 (UTC)[응답]

응. 우리 닐 아인(대화) 12시 35분, 2011년 7월 1일 (UTC)[응답하라]

그래, 난 enwp.org을 몰랐어.멋있는 기능이다.하지만, 당신이 언급했듯이, 그것은 비공식적으로 운영된다.공식적인 단축 서비스가 훨씬 더 안전할 것이다.또한, enwp.org은 실제로 주소를 줄이지 않는다.예를 들어, 당신은 제83회 아카데미 외국어 영화상 출품 목록을 트위터에서 공유하지 않을 것이다.Fetchoms, Wnt, 이 공식 서비스는 프로젝트를 더 쉽게 확산시키는데 도움이 될 것이다.경험이 없는 사용자는 기사 페이지에서 단축 링크를 복사하여 다른 사용자와 공유할 수 있다.모든 사람이 bit.ly을 알고 있는 것은 아니며, 많은 사람들이 그 단계를 따르려고 하지 않는 반면, 이 옵션은 훨씬 더 쉽게 접근할 수 있을 것이다. --NaBUru38 (대화) 23:58, 2011년 7월 2일 (UTC)[응답]

2월에 위키미디어 재단은 그들에게 도메인을 주겠다는 enwp.org의 소유주의 제안을 환영했다[21].5월에는 이 문제를 재단의 기술부[22]에서 롭 할셀에게 의뢰했다고 한다.일부 기술자들은 이에 대해 다소 회의적일 수 있다는 지적이 있었다[23].

URL 단축기는 단축된 링크를 클릭하는 사용자를 추적할 수 있기 때문에 개인 정보 보호 문제를 나타낼 수 있다.그들은 종종 이 추적 데이터의 일부를 발표한다.예를 들어, bit.ly에는 국가별, 레퍼러별 클릭 수(bit.ly 링크에 "+" 추가)가 나열되어 있다.이것은 위키백과 사용자의 국가를 알아내기 위해 꽤 쉽게 이용될 수 있다.WMF가 소유한 단락제는 그러한 데이터가 WMF 개인 정보 보호 정책의 적용을 받는다는 이점을 제공할 것이다.

안녕, HaeB (대화) 17:51, 2011년 7월 3일 (UTC)[응답]

Regiowikis 템플릿

이 영역에 대한 regiowiki 사용 가능: 톰스크위키

안녕, 모두들. Regiowikis는 지리적 영역에 초점을 맞춘 위키야.도시에 관한 기사에서 이러한 백과사전을 링크하기 위해 새로운 템플릿 {{Regiowiki}}을 만들 것을 제안한다.톰스크의 오른쪽 예."외부 링크" 섹션의 링크만 있으면 좋겠지만, 이것이 자유로운 지식 창조를 촉진하는 방법이다.

그런데, 나는 세계의 모든 레지오위키들의 목록/지도 작업을 하고 있다(사용자:에미jrp/Regiowikis) 그러니 빠진 레지오위키에 대해 알고 있다면, 그것을 추가하십시오!안부 전해요emijrp (talk) 08:56, 2011년 6월 30일 (UTC)[응답하라]

말조심해!나는 몇 가지 반대 의견을 가지고 있다.

• 당신이 만든 것과 같은 템플릿은 현재 Wiktionary나 Wikicommon과 같은 다른 위키미디어 프로젝트에만 사용된다.독자들은 "regiowiki"가 위키백과의 일부라고 생각할 것이다. 위키백과는 그렇지 않고 우리는 위키백과의 내용을 전혀 통제하지 않는다.
• 레지오위키는 외국어로 쓰여져 있지만, 우리는 영어 위키백과다.영어가 아닌 언어로 된 웹 사이트에 대한 외부 링크는 강력하게 금지된다(WP:NONEGENENGEL)
• "실제 안정의 역사와 편집자의 수가 상당하지 않는 한 우리는 위키를 정상적으로 개설하는 것에 연결하지 않는다."wp:ELNO#12
• 우리는 "자유로운 지식 창조를 촉진한다"는 외부 링크를 추가하는 것이 아니라, 외부 링크가 기사를 향상시키기 때문에 그렇게 한다.요에닛 (대화) 09:57, 2011년 6월 30일 (UTC)[응답]

안녕. 1) 좋아, 새로운 디자인이 필요해. 2) 좋아, 영어 위키 링크만.3) 난 괜찮아4) 어서!그것은 부작용이다; ) 안부 전한다.emijrp (talk) 10:38, 2011년 6월 30일 (UTC)[응답하라]

나는 이것이 좋은 생각이라고 생각하지 않는다.외부 링크에 대한 특수 템플릿은 다른 링크에 대한 과도한 가중치를 부여하며, 확실히 지역의 공식 웹 사이트(있는 경우)가 위키보다 더 중요해야 한다.캄발라체로 (대화) 14:22, 2011년 6월 30일 (UTC)[응답]

이러한 링크는 WP를 거의 충족하지 못할 것이기 때문에:EL, 즉 기사에는 거의 등장하지 않는데, 왜 우리는 특별한 템플릿을 원하거나 필요로 하는가?Qwyrxian (대화) 10:43, 2011년 7월 2일 (UTC)[응답]

{{Facebook}}을(를) 이러한 링크의 정확한 스타일에 대한 모델로 사용할 수 있지만, Qwyrxian이 옳다.합법적인 용도가 거의 없는 템플릿을 만드는 이유는?WhatamIdoing (대화) 14:21, 2011년 7월 2일 (UTC)[응답]

삭제 토론을 위해 빨간색 대화 페이지 링크 숨기기

삭제 논의를 위해 Redlinked Talk 페이지 탭을 숨기는 공통 JS 또는 CSS 파일에 무언가를 추가하자고 제안한다.나는 이것 때문에 혼란스러운 편집자를 한 명밖에 본 적이 없지만, 확실히 이 탭을 사용하는 경우는 드물다.토론에 대한 메타토론이 있어서는 안 되며, 그 페이지에서 할 말은 다 해야 한다.만약 어떤 이상한 상황에 의해, 토크 페이지가 만들어져야 한다면, 그 탭은 파란색으로 표시될 것이다.토크 페이지가 생성되어야 한다는 것을 알 만큼 충분히 알고 있는 편집자는 URL에 "talk"를 입력하는 방법도 알아야 한다.토론에 가서 빈 토론 탭이 있다는 것을 발견하는 것은 조금 직관에 반하는 것이다.이렇게 하면 순간적인 혼란도 일어나지 않는다.▫ 조니미르닌자 07:54, 2011년 7월 2일 (UTC)[응답]

그것들은 보통 사용되지 않지만, 가끔 쓰일 때도 있다.때때로 출처의 확장된 분석이나 긴 접선적 논의를 이동하는 것이 도움이 된다.나는 이런 일이 일어난 소수의 AfDs에 참여했었다.이것은 관리자 공지사항 게시판과 유사하다: WP에서 "말하기":A 또는 WP:ANI, 그러나 "meta-talk"는 WT:AN 또는 WT:ANI. 28바이트 (대화) 08:09, 2011년 7월 2일 (UTC)[응답]

그래, 가끔 이런 일이 일어나긴 하지만, 차이점은 WP:A는 결코 빨간 토크 페이지 탭이 없는 반면, AfDs는 거의 항상 그런 성격이다.마을 펌프 토크 페이지를 만들면 그 탭은 영원히 파란색이다.또한 삭제해야 할 페이지를 가장 많이 만드는 사용자들이기 때문에 새로운 사용자들은 종종 AfD로 갈 필요가 있다.그리고 다시 말해, 탭이 파란색이면 숨겨져서는 안 된다.◆ 조니미르닌자 08:46, 2011년 7월 2일 (UTC)[응답]

이것은 합리적인 것 같다. -- 지우개헤드1 <토크> 09:09, 2011년 7월 2일 (UTC)[응답]

나는 우리가 사람들에게 URL을 손으로 코딩하도록 요구하기를 원하지 않는다고 생각한다.우리는 그 페이지에 관심이 있는 모든 사람들이 영어 위키피디아에서 단골이라고 가정하거나, 모든 사람들이 클릭하는 것만큼 타이핑이 쉽다고 생각해서는 안 된다(특히 모바일 기기에서).또한, 레드 링크는 확실히 단골들에게 토크 페이지에는 관심거리가 없다는 것을 보여준다.WhatamIdoing (대화) 14:56, 2011년 7월 2일 (UTC)[응답]

나는 그들이 보통사람이라고 생각하지 않는다, 정반대다.아프간에 가는 대부분의 사람들은 어디에 게시해야 할지 모를 것 같아.AFD에 대해 충분히 알고 있는 사람들은 토론에 대한 별도의 논의가 필요하다는 것을 알 정도로, 내가 추측하는 이 사람들은 단골들이다.어떻게 작동하는지 모르는 사람도 토론 대신 토크 페이지에 글을 올려야 하는 상황은 없다.그래, 어떤 명사를 보더라도 그것이 그 명사라는 것을 알 수 있듯이 레드링크를 보는 것은 사람들이 레드링크라는 것을 아는 방법이다.빨간 링크만 숨겨져 있다면(파란 링크가 아닌 다른 링크) 토크 페이지 탭을 보는 것은 거기에서 대화가 있었음을 보여주는 지표일 것이다.이것은 누구에게나 문제를 일으킬 것 같지 않다.토크 페이지 탭을 보지 않는 것은 빨간 페이지를 보는 것만큼 믿을 수 있을 것이다. 그것은 그것을 숨기는 동일한 위키 소프트웨어가 될 것이기 때문이다.〇 조니미르닌자 21:39, 2011년 7월 2일 (UTC)[응답]

총 숫자는 잘 모르겠지만, 여기 모든 AfD 토크 페이지 목록이 있어.나는 개인적으로 토론 중에 오직 한 명의 편집자가 토크 페이지 탭으로 혼란스러워하는 것을 보았다고 말했다. 음, 그 목록에는 수백 개가 들어 있다.나는 이 제안에 관심이 있는 모든 사람들에게 이 페이지들을 무작위로 선택해서 얼마나 많은 논평이 토론 페이지에 올라왔는지, 그리고 얼마나 많은 의견이 AfD에 올라올 수 있었는지를 볼 것을 부탁한다.그 토크 페이지에 대한 대부분의 논평은 그들이 토론의 일부가 될 것이라고 생각하는 사람들의 것이다."메타" 코멘트의 대부분은 SPA 통지, 재등록, 삭제 구분 등 토론에서 이루어져야 한다.사람들은 그 토크 페이지에 메타 코멘트가 있을 것이라고 기대하지 않을 것이고 그것은 눈에 띄지 않게 될 것이다.토론에서 꺼낸 코멘트는 이제 접을 수 있는 템플릿으로 간단히 숨겨져 있기 때문에 사람들은 항상 대화의 모든 부분을 쉽게 볼 수 있다.〇 조니미르닌자 21:39, 2011년 7월 2일 (UTC)[응답]

나는 WT와 같은 토크 페이지를 몇 번 사용한 적이 있다.삭제/Thou Shalt Not....나는 또한 우연히 거기에 배치된 몇 개의 코멘트를 본 적이 있다.플랫스캔 (토크) 04:31, 2011년 7월 4일 (UTC)[응답]

Facebook에 연결

나는 점점 더 많은 사이트들이 페이스북 트위터 아이콘을 가지고 있고, 클릭했을 때 당신의 관련 프로필에 링크를 걸거나 트윗을 만드는 것을 알아챘다.위키피디아 페이지마다 그런 버튼이 있으면 유용할까?예를 들어, 사용자가 댓글을 쓸 때 리버풀 에코를 보면, 페이스북에 댓글을 올릴 때까지 시스템을 설정할 수 있으며, 기사에 대한 링크가 포함된 트윗을 만들 수 있다.PR도 좋고 유용할 것 같다.--Kitchen Needle (토크) 15:21, 2011년 6월 3일 (UTC)[응답]

나도 같은 생각을 했다.또한, 사용자들이 페이스북 계정을 사용하여 로그인하게 할 수도 있다.위키피디아는 여성 편집자가 부족하고 여성들이 소셜 네트워킹을 지배하기 때문에 몇몇 새로운 편집자들을 끌어들이는 좋은 방법이 될 수 있다.지식탐구 (대화) 19:14, 2011년 6월 3일 (UTC)[응답]

이것은 최근에 꽤 자주 제안되었다. 예를 들어, 이것 또는 이 토론과 거기에 있는 링크를 참조하라.로그인한 사용자로 User:DJ/Sharebox는 사용자가 직접 사용할 수 있지만 이러한 아이콘 블록이 너무 침입적이어서 기본적으로 켜지지 않는 것 같다.Signpost 스토리의 경우 조금 전에 눈에 띄지 않는 "Share this" 드롭다운 메뉴를 추가했다(예: 오른쪽 상단 참조).

안녕, HaeB (토크) 19:21, 2011년 6월 3일 (UTC)[응답]

당신의 편집 내용을 트위터와 페이스북에 반향하는 목적은 선거운동 목적 외에 무엇이겠습니까?The Mark of the Beast (talk) 20:41, 2011년 6월 3일 (UTC)[응답하라]

편집한 내용을 반추하는 것이 아니라 선택한 기사만 친구들의 흥미를 끌 수 있다.--Kitchen Needle (토크) 20:50, 2011년 6월 3일 (UTC)[응답]

Sharebox는 도구 상자의 순서를 변경하는 스크립트 입니다.페이스북이나 다른 링크 공유 서비스에서 기사를 쉽게 우편으로 보내거나 인쇄하거나 공유할 수 있는 새로운 버튼을 추가했다.사이드바에 Sharebox를 추가하려면 계정이 있어야 한다.사용자: 참조:자세한 내용은 TheDJ/Sharebox. -- - - Gadget850(Ed) 23:23, 2011년 6월 3일(UTC)[응답]

사용자:DJ/Sharebox가 좋긴 한데 작동이 안 돼?--Kitchen Needle (토크) 10:55, 2011년 6월 4일 (UTC)[응답]

어떤 브라우저를 사용하십니까? ---— Gadget850 (Ed) 19:26, 2011년 6월 5일 (UTC)[응답]

파이어폭스.---키친 나이프 (대화) 16:13, 2011년 6월 12일 (UTC)[응답]

페이스북 통합은 이미 미디어위키에 존재하며 Wikia에서 사용되고 있다.최근 짐보의 토크 페이지에 어떤 사람이 그것을 올렸고 그는 위키피디아를 위한 페이스북을 지지한다.그냥 지적하는 거야.우리가 소셜 사이트가 되어서는 안 된다고 생각하는데, 나는 소셜 사이트를 싫어하지만, 소셜 사이트로 연결하면 독자성과 편집력이 높아질 것이다.사람들은 왜 우리가 새로운 편집자를 구하지 않는지 궁금해하는데, 아마도 그것은 웹 2.0이 현재 대부분의 사람들에게 구식이고 위키피디아가 웹.7 ▫ JonnyMrNinja 20:57, 2011년 6월 4일 (UTC)[응답]을 맴돌고 있는 것일 것이다.

어떤 조치를 취하기 전에 페이스북을 통합함으로써 위키피디아가 어떤 종류의 편집을 얻게 될 것인가에 대해 고려할 필요가 있다.내 추측으로는 페이스북은 백과사전을 쓰는 것과 같은 "극적으로" 활동을 위한 것이 아니라 사회화와 유사한 활동을 위한 것이기 때문에 편집의 대다수는 기껏해야 아무런 도움이 되지 않을 것이다.최악의 경우(그리고 그럴 가능성이 있는) 시나리오는 그러한 링크가 페이스북 트롤, 팬, POV 푸셔들을 위키피디아로 끌어들일 것이라는 것이다.그것은 공공 기물 파손을 다루는 편집자들이 필요로 하지 않는 것이다.리락 (대화) 02:12, 2011년 6월 5일 (UTC)[응답]

전적으로 동의한다.The Mark of the Beast (talk) 03:21, 2011년 6월 5일 (UTC)[응답하라]

어... 그리고 학교에서 위키피디아 사용...우리는 아이들이 학교 페이지를 편집하고 친구들과 선생님들을 학대하도록 할 것이다어떡해! 벌써 일어났어!…지금 위키피디아 사람들이 그렇게 "중립적인" 집단인 것도 아니고(ANI, ARBCOm, 블록 로그, AIV 등 참조), 그리고 이미 FB에서 WP로 연결되는 링크가 많지 않은 것도 아니다.나는 Fb와 트위터 링크를 WP에 올리는 것에 대해 큰 거리낌이 있지만(그리고 구글 링크를 내가 직접 ref를 필요로 하는 페이지에 올려서 충분히 선전받았다) 나는 FBers를 "대단히 씻지 않은 사람"으로 생각하는 것이 프로젝트의 정신에 도움이 되거나 정확하거나 진실하다고 생각하지 않는다.Rich Farmbrough, 19:08, 2011년 6월 5일 (UTC)
[답글]

현재 학교 아이들이 서로 다른 기사와 관련된 연구 기법과 자료를 공부하고 있다는 점만 빼면, (우리들과 그들에게) 잠재적인 이득이 있다.학대는 누구에게나 편집을 허용하는 문제(우리가 그것을 없애버리라고 제안하지 않음)이기 때문에, 그곳에서는 실제로 순손실이 있는 것은 아니다.FB는 아무에게도 물건을 연구하는 법을 가르치지 않기 때문에(많은 피라미드 계획과 트로이 목마들이 친구들에게 지적해야 하는 만큼, 정반대의) 잠재적인 이득은 없다.Ian.thomson (대화) 20:08, 2011년 6월 8일 (UTC)[응답]

페이스북은 위키피디아를 반영한다는 점에 유의하십시오.Rich Farmbrough, 19:08, 2011년 6월 5일 (UTC)
[답글]

당신이 Rose Heilbron에서처럼 페이스북이 위키피디아를 먹여살린다고 말하듯이 나와 나와 나와 연결된 사람들이 페이스 북에 하는 것은 기사, 비디오 등, 많은 외부 콘텐츠에 대한 링크를 게시하는 것이다.---키친 나이프 (대화) 19:27, 2011년 6월 5일 (UTC)[응답]

• 내가 지난 두 번 반대했던 것과 같은 이유로 반대하라.또한 페이스북은 신뢰성의 반대고, 내 생각에는 지능적인 담론의 반대다.내 생각에 거기에 아이콘들을 가지고 있는 것은 피해를 줄 것이고, 내가 그것을 원하는 사람들을 생각할 수 있는 유일한 이유는 그것이 약 7분의 1초 동안 그들을 구하고 '다른 모든 사람들이 그것을 하고 있다'는 것이다.정말로, 만약 당신이 위키피디아 기사에 링크하고, URL을 복사하고 싶다면, 그것은 전혀 어렵지 않다.스벤망구아르드화?07:50, 2011년 6월 6일 (UTC)[응답]

• 이런 게 멋질 수도 있어.Killiondude (대화) 08:30, 2011년 6월 6일 (UTC)[응답]

대부분의 사람들이 페이스북에서 실명을 사용하는 것을 볼 때, 나는 이것이 공공 기물 파손을 증가시킬 수 있을지 진심으로 의심한다.오히려 실명을 사용하는 것이 오히려 낙담할 가능성이 높다.지식탐구 (대화) 12:57, 2011년 6월 7일 (UTC)[응답]

위키피디아에서 편집할 때 실명을 사용했을 때만.하지만 페이스북과 위키피디아는 연결되어 있지 않기 때문에, 우리는 그들의 IP주소로만 그들을 식별할 수 있다.게리 킹 (토크 · 대본) 18:34, 2011년 6월 7일 (UTC)[응답]

음, 제안들 중 하나는 사용자들이 페이스북 계정을 사용하여 로그인하도록 하는 것이다.많은 웹사이트들이 그것을 하기 시작하고 있다.지식탐구 (대화) 18:43, 2011년 6월 7일 (UTC)[응답]

그게 정확히 어떻게 될까?예를 들어 유튜브에서 구글 메일 계정으로 로그인할 수 있다는 겁니다.그럴 경우, 두 계정 모두 아마도 같은 서비스(즉, 구글 서버)에 호스팅되어 있을 것이다(내 추측일 뿐, 틀릴 수도 있다).위키피디아와 페이스북의 경우 그것이 정확히 어떻게 작동할까?야마구치 도시오 (토크) 18:52, 2011년 6월 7일 (UTC)[응답]

페이스북에 로그인하면, 위키피디아에 당신의 계정에 로그인되어 있고 당신의 이름은 "존 스미스"라고 말하게 된다. 물론, 그들은 당신이 다른 "존 스미스"와 충돌하지 않도록 독특한 아이디를 제공할 것이다.게리 킹 (토크 · 대본) 18:56, 2011년 6월 7일 (UTC)[응답]

• 결정하지 않음 이것은 새로운 편집자들을 끌어들이는데 좋을지도 모른다.그러나 나는 결정하기 전에 더 발전되고 더 자세한 제안서를 보고 싶다.이것 또한 부정적인 이슈를 많이 가질 수 있다고 생각한다.야마구치 도시오(토크) 19:12, 2011년 6월 7일 (UTC)[응답]

• 다음과 같은 이유(당분간 내가 상당히 추상적으로 유지한 이유)로 인해 'Like this!' 박스 버라이어티의 모든 종류의 비선택적 형식적 통합에 반대한다.

a) 신뢰도 - 어떤 공공연한 방법으로든 페이스북 등에 연결하는 것은 특히 Sven 당 학계나 전문계에서의 신용을 떨어뜨린다.

b) 편집자 수신 - 관찰된 바와 같이, FB는 이미 위키백과 및 기사 링크를 미러링한다.그것은 사람들이 이미 FB에서 우리 사이트로 점프할 수 있다는 것을 의미하며, 그들이 뒤로 점프할 수 있게 해주는 기능을 도입하는 것은 편집자를 유지하는 면에서 현저히 이롭지 않아 보인다.

c) 전문가 보존 - 만약 내가 불분명한 주제에 대한 전문가로서 비전문가에게는 별로 관심이 없는 것에 대한 기사를 작성하고, 한 달 후에 돌아와서 윌 멜러에 관한 다른 기사에는 여전히 "0 like"가 있고, 반면에 윌 멜러에 대한 다른 기사에는 수천 개의 like가 있다는 것을 알게 된다면, 나는 아마도 다른 기사를 만들 필요가 없을 것이다.

d) 상업적 이유는 적용되지 않는다 - 신문, 블로그 등 대부분의 사이트FB 링크와 '달콤한 이' 버튼 뒤에 상업적인 동기가 있다 - 그들은 더 많은 돈을 벌기 위해 더 많은 관점을 끌어들이기를 원한다 - 이러한 이유들은 우리에게 실제로 적용되지 않는다.

e) 필요한 기술 지식의 부족 - 자, 위키백과를 편집할 수 있는 사람은 누구나 URL을 복사하여 붙여넣을 수 있다. 우리는 그들이 그렇게 하도록 돕기 위해 인터페이스에 도구 모음을 구축할 필요가 없다.

f) 독립성 - 개인적으로 나는 당시의 '악의 제국'과 연관되지 않은 주요 사이트를 갖는다는 생각이 꽤 마음에 든다.

어쨌든 그것들은 내 (아마도 반신반의) 생각들이야 - 만약 이것이 브레인스토밍이 아닌 진지한 제안이 된다면 확장하려고 노력할지도 몰라. (나는 사람들이 대체 피부/JS 기능/어떠한 것에도 이런 것을 포함하도록 하는 것에 완전히 반대하지 않는다는 것에 주목한다.)안녕하십니까, 밥 하우스 884 (토크) 2011년 6월 8일 (UTC) 19:32[응답]

• Per Bob House를 반대하십시오.또한, 내가 반박하는 방식으로: day b nuf spelinn n shit 4 weddout people @fb write discuse 우리는 Ian.thomson (talk) 19:44, 2011년 6월 8일 (UTC)[응답하라]에 필요하다.

나사의 웹 사이트[24]는 페이스북, 트위터, 디그 및 다른 많은 소셜 네트워킹 사이트와 통합된다.누군가 나에게 이것이 나사가 학계나 전문가 사회에서 신뢰를 잃게 했다는 증거를 보여줄 수 있을까?지식 탐색 (대화) 19:49, 2011년 6월 8일 (UTC)[응답]

밥: 위키피디아에 "이것처럼" 버튼을 추가하자고 제안하는 사람은 아무도 없을 것 같아.대신 두 가지 제안이 보인다: 1) 독자들이 페이스북, 트위터 등에 공유함으로써 흥미롭게 여기는 기사를 공유하게 한다.2) 페이스북 계정을 사용하여 로그인하게 한다.지식탐구 (대화) 2011년 6월 8일 (UTC) 19:52 [응답]

나사에 대해서는 전혀 다른 상황이다.나사는 우리처럼 신뢰를 위해 싸울 필요도 없고(그들은 신뢰를 잃기 위해 노력해야 할 것이고, 우리는 그것을 얻고 있고, 우리가 얻고 있는 지반을 잃지 않기 위해 노력해야 할 것이다), 또한 그들이 그들의 사이트를 편집하는 것도 허락하지 않는다.이안.thomson (대화) 19:56, 2011년 6월 8일 (UTC)[응답]

당신은 어떻게 독자들이 그들의 친구들과 흥미롭게 생각하는 기사를 공유하게 하는 것이 위키피디아의 신뢰성을 떨어뜨리는 원인이 되는지 정확히 설명할 수 있는가?이해가 안 돼지식탐구 (대화)20:21, 2011년 6월 8일 (UTC)[응답]

• 논평 - 우선, 일부 논평의 엘리트주의적 태도를 보는 것은 실망스럽다.단순히 그들이 그들의 삶에 그들의 친구를 포함시키고, 우리는 익명으로 하이픈 사용에 대해 말다툼을 한다고 해서 우리가 다른 사람들보다 더 똑똑하다고 생각하는 것은 불공평하다.위에서 말했듯이, 나는 소셜 사이트를 싫어하지만, 그렇다고 내가 그들의 사용자들을 싫어하는 것은 아니다.나는 미디어위키 사이트가 페이스북 API를 어떻게 사용하는지를 보여주는 예로서 http://help.wikia.com/wiki/Help:Facebook_Connect을 지적하고 싶었다.또한 "좋다"는 버튼이나 소셜 북마킹 링크로 어떤 일이 일어나더라도 통합 가젯을 통해 처리할 수 있으므로, 이 버튼은 로그인한 사용자만 볼 수 있다.이것은 우리가 "거리 신용"을 유지하는 데 도움이 될 것이다.▫ 조니미르닌자 20:35, 2011년 6월 8일 (UTC)[응답]
• 나는 팬이 아니라고 말해야 해. --게릴레로 My Talk 21:04, 2011년 6월 8일 (UTC)[응답]
• 어떻게 관리해야 하는지에 반대하십니까?또한, 사람들은 단지 sn(소셜 네트워킹) 계정 때문에 그것을 사용할 수 있다고 해서 여기에 가지 않을 것이다.~~EBE123~20:07, 2011년 6월 14일 (UTC)[응답]
• 반대하라 우리는 페이스북이 위키피디아에서 사람들을 추적하는 것을 원하지 않는다. 그래서 우리는 그것을 분리할 필요가 있다.그러나 나는 외부 링크에서 공식 페이스북 페이지나 팬 페이스북 페이지에 연결하는 것에 반대하지 않는다.Graeme Bartlett (talk) 05:26, 2011년 6월 19일 (UTC)[응답]

나는 다음과 같은 이유로 위키피디아를 페이스북과 연계하는 것을 반대한다.위키백과와 페이스북을 모두 좋아하고, 위키백과의 사용자 페이지와 페이스북의 프로필을 모두 가지고 있는 사람(내 자신도 포함됨)이 많을 것이지만, 만약 한 사람이 WP: 위키백과가 아닌 것, 그리고 서브헤딩 2.5 아래에 있는 것을 읽는다면, 우리는 위키백과가 소셜 네트워킹 웹사이트가 아니라는 것을 명확히 할 수 있다는 것을 기억해야 한다.우리는 소셜 네트워킹 웹사이트를 온라인 백과사전으로 혼동해서는 안 된다-페이스북과 위키피디아는 둘 다 각기 다른 이유를 가지고 있다.위키피디아에서 사람들이 실명을 사용하기 때문에 반달들을 끌어들이지 않을 것이라는 위의 제안처럼, 사람들은 시티즌디움에서 실명을 사용하지만 이 온라인 백과사전은 여전히 위키피디아보다 훨씬 열등하다는 것을 기억하십시오.ACEOREVIVEED (토크) 20:04, 2011년 6월 22일 (UTC)[응답]

• 위에 열거한 많은 다른 이유들과 함께 반대한다(그리고 어쩌면 이것도 마찬가지일 것이다) 나는 ...의 일부가 걱정될 것이다.음... 문제(바이러스, 피싱, 스캠 등)는 여기서 어떤 것을 손상시킬 수 있다.그리고 WP에서 계정/이름/암호가 훼손되는 것은 거의 항상 매우 바람직하지 않은 결과를 초래한다.둘째, 'WP: WP:많은 사용자들이 가명으로 편집하기 때문에 "OUNGOT"가 발생한다.나도 가끔은 '좋다'는 버튼을 갖고 싶지만, 링크만 복사해서 붙여넣는 것도 그렇게 어렵지 않아.— 체드 : ? 02:50, 2011년 6월 27일 (UTC)[응답]

• 반대 - 페이스북 광고에 반대 - 하지만 가젯 Bulwersator (토크) 09:17, 2011년 7월 4일 (UTC)[응답]로 추가될 수 있다.

소셜 미디어

모든 위키피디아 기사와 사진에는 소셜 미디어 공유 기능이 필요하지만, 아마도 FB와 트위터만 필요하지만, 우리가 공정해야 한다면 "Share This" 드롭다운이 필요하다는 것이 점점 분명해지고 있다.읽어주고 응원해줘서 고마워.~J — 젠고드가 추가한 선행 미서명 논평 (대화 • 기여) 19:46, 2011년 6월 6일 (UTC)[응답]

나는 다소 동의하지 않는다.반달리즘을 유인하는 더 쉬운 방법인 것 같아.만약 사람들이 진정으로 무언가를 읽고 싶다면, 그들은 그것을 검색할 것이고 위키피디아는 보통 최고의 검색결과가 된다.방문은 유기적이어야 한다.백과사전적 정보는 일반적으로 사회적으로 공유하는 것이 아니다.게리 킹 (토크 · 대본)20:02, 2011년 6월 6일 (UTC)[응답]

나는 이것과 어느 정도 관계가 있다.나는 이런 유형의 기능성을 허용하는 것이 기사에 어느 정도 관심을 끌 수 있다는 것을 인정한다. 나는 또한 공공 기물 파손이 그것들 중 하나가 될 것이라고 믿는다.나는 볼 만한 사람들을 시험해 보는 것이 흥미로울 수도 있다고 생각한다.투자 수익률이 어떻게 되는지 자문해봐야 할 것 같아.이렇게 함으로써 무엇을 얻고 잃을 것이며 시간과 에너지를 투자할 가치가 있는가?재단은 더 많은 편집자를 끌어들이기 위한 방법을 찾아 수풀을 두들겨 댔고, 이것이 그 방법이 될 수도 있다. --쿠미오코 (토크) 20:23, 2011년 6월 6일 (UTC)[응답]

대부분의 사람들이 페이스북에서 실명을 사용하기 때문에, 나는 매우 많은 사람들이 기사를 파괴할 것이라고 생각하지 않는다.지식탐구 (대화) 20:31, 2011년 6월 6일 (UTC)[응답]

만약 "대부분" 사람들이 그들의 실명을 사용한다면, 이것은 사람들이 실명을 사용하도록 보장하는 메커니즘이 없다는 것을 의미하지 않는가?리락 (대화) 08:45, 2011년 6월 7일 (UTC)[응답]

페이스북에서 실명을 사용하는 것과 여기서 기사를 파괴하는 것은 두 가지 다른 것이다.페이스북 친구를 통해 위키피디아 기사를 발견한 뒤 기사를 찾아 파괴할 수 있다.우리는 사용자의 페이스북 이름을 절대 모를 것이다.다소 관련이 있는 노트에서, 페이스북은 현재 약 1년 동안 위키피디아의 데이터를 사용하여 모든 주제에 대한 정보 페이지를 만들어 왔다.예를 들어, 만약 어떤 사람의 프로필에 "요리하기"를 흥미로 나열하고, 당신이 "요리하기"를 클릭했다면, 당신은 facebook.com/topics/cooking과 같은 위키피디아 기사를 볼 수 있을 겁니다.우리가 어떻게 그걸 이용해서 편집자들을 여기에 끌어들일 수 있을지는 모르겠지만, 그건 생각이야.게리 킹 (토크 · 스크립트) 18:29, 2011년 6월 7일 (UTC)[응답]

나는 원래 포스터에 전적으로 동의해.그래서 위키피디아를 만들었다.애초에 공유함.그러나 이를 어디서나 구현하기 위해서는 여러 소셜 공유 툴을 지원하는 개방적이고 자유로운 공유 시스템이 필요하다.우리는 한두 가지 서비스만 홍보할 수 없고, 그 위에 소셜 공유 서비스는 여전히 인기 면에서 당신의 원산지/언어에 매우 의존하고 있다.그것은 꽤 발전적인 노력이다.불가능하지는 않지만 그래도 상당한 시간이 걸릴 것이다.—DJ (대화 • 기여) 2011년 6월 6일 (UTC) 20:36[응답]

@AQFK: 특히 BLP 기사는, 내 말뜻을 이해한다면.=p 윌리엄 매튜 플린더스 페트리 세이 샬롬 경!20:33, 2011년 6월 6일 (UTC)[응답하라]

보아하니 위키 소프트웨어는 이미 이 기능을 지원하고 있다.예를 들어 위키뉴스 기사 하단으로 스크롤하십시오.[25] 페이스북, 트위터, 링크드인, 디그, 그 외 여러 곳에 대한 링크가 있다.지식 탐색 (대화) 20:39, 2011년 6월 6일 (UTC)[응답]

이건 그냥 템플릿이야, 여기서 찾을 수 있어.우리는 모든 기사를 편집하고 각 기사에 템플릿을 추가해야 하기 때문에 여기서 그것들을 구현하기 위해 같은 정확한 방법을 사용할 수 없다.게리 킹 (토크 · 스크립트) 18:29, 2011년 6월 7일 (UTC)[응답]

mw:확장:PageNotice가 설치되었다면 그것을 없앨 수 있을 것이다.Rd232 10:23, 2011년 6월 9일 (UTC)[응답]

• 반대 - 이 게시물에서 5개의 게시물을 보시오. 이 게시물에서는 정확히 같은 것을 다루고 있는데, 내 추론을 위해 이 게시물을 보시오.스벤망구아르드화?08:36, 2011년 6월 16일 (UTC)[응답]

나는 이것들 둘 다 봤고, 다른 많은 것들도 봤어.그들은 결코 진정한 합의를 보지 못하는 것 같다.리스트에 추가할 다른 서포넌트 제안이 있나?워보트9 (대화) 00:05, 2011년 6월 23일 (UTC)[응답]

• 반대 위키피디아의 가장 좋은 점 중 하나는 위키피디아가 페이스북의 '소셜 미디어' 헛소리를 많이 가지고 있지 않고, 지구상의 다른 모든 웹사이트들처럼, 나에게 "이것처럼" 혹은 "이것을 공유"하거나 또는 그 밖의 것을 요구하지 않는다는 것이다.만약 내가 위키피디아에서 보는 것을 소셜 미디어 사이트에 올리고 싶다면, 나는 마우스를 URL 바로 옮기고, URL을 복사하여 페이스북이나 트위터 등에 붙여넣는다.그것은 누구나 필요로 하는 소셜 미디어 통합의 전부다: 지속적인 URL로 그것을 웹에 게시하고 다른 사람들이 그것에 연결하도록 허용한다.그 너머엔 마케팅이 있어거기 가지 말자, 알았지?—톰 모리스 (대화) 10:03, 2011년 6월 27일 (UTC)[응답]

여기 있는 모든 사람들은 그들이 원하는 것, 또는 좋아하는 것에 대해 이야기하고 있다.우리는 우리의 사용자들이 무엇을 원하는지, 그리고 무엇이 '페디아'의 더 큰 사용과 참여를 장려할 것인지 고려해야 한다.그리고 그것이 연구를 하는 것을 의미하지만, 일화적으로 우리는 사람들이 그러한 특징들을 좋아하고 사용한다는 것을 알 수 있다. (기록적으로, 제 개인적인 견해는 그러한 것들이 페이지보다는 책갈피나 추가 기능으로서 브라우저에 속해 있다는 것이다.그러나 나는 그것이 아마도 나를 소수에 속하게 한다는 것을 인정한다.)Andy Mabbett(사용자:Pigsonthewing); 앤디의 토크, 앤디의 2011년 6월 27일 편집[응답]

+1 플러그인을 통한 구현과 관련하여 이 문제에 대한 사용자 참여 필요성과 선호도에 대한 메타 포인트 두 가지 모두에 대해 설명하십시오.피부 일부분으로도 볼 수 있었지만, 사용자가 합리적인 선택으로 선택할 수 있다.곤조(토크) 10:32, 2011년 6월 27일 (UTC)[응답]

첫째로, 나는 위의 페이스북 실의 하위섹션을 만들었는데, 둘 다 같은 것에 대해 꽤 잘 알고 있기 때문이다.둘째로, 다음과 같이 합시다.왜 누군가가 소셜 북마킹 기능이 있는 WP 기기를 사용하지 않는지, 그리고 우리는 그것을 측정기로 사용할 수 있다.우리는 그것을 얼마나 많은 사람들이 사용하는지 쉽게 추적할 수 있다.만약 그것이 압도적으로 많은 지원을 받는다면, 우리는 mw와 같은 실제 MediaWiki 확장을 구현하는 것을 더 자세히 살펴볼 수 있다.확장:페이스북.만약 그것이 인기가 없거나 문제를 일으킨다면, 우리는 우리의 해답을 가지고 있다.나는 이 가젯이 메인 스페이스와 파일: 스페이스에서만 기능할 것을 추천한다.▫ 조니미르닌자 11:12, 2011년 6월 27일 (UTC)[응답]

• 댓글이 여기 n:에서 댓글 달랬는데.Wikinews:Water_cooler/기술#Facebook.나는 단지 페이스북 통합과 관련하여 사생활에 대한 중요한 고려사항이 있을 수 있다는 것을 언급하고 싶었다.Facebook에서 공유하기 위해 여기를 클릭하는 것은 괜찮지만(이것은 수동적이기 때문에, 사용자는 Facebook으로 정보를 보내기 위해 클릭해야 한다), 그러나 Facebook은 버튼을 좋아하거나 Facebook 계정으로 로그인한다. 그리고 거의 모든 mw:extension:Facebook은 Facebook이 기본적으로 그들의 허락없이 우리의 사용자들에 대한 정보를 수집할 수 있게 해준다. (그리고 아마도 vi에 있을 것이다.개인 정보 보호 정책의 개선, 비록 내가 개인 정보 보호 정책을 읽어본 적이 없다고 생각하지만, 확실히 말할 수 없다.)이전에 이것은 메일링 리스트에 올려져 있었다. 그것은 사생활에 관한 우려 때문에 삭제된 최근의 예시인데, 이것은 챕터에 관한 것이기 때문에 전혀 같지 않다.바월프 (대화)20:16, 2011년 6월 29일 (UTC)[응답]
  • 이러한 문제는 기술 커뮤니티와 재단 내에서 잘 알려져 있다.물론 그렇다고 해서 지금보다 더 많은 일을 할 수 없다는 뜻은 아니며, 다만 우리가 할 수 없는 몇 가지 구체적인 일이 있을 뿐이다.—DJ (대화 • 기여) 21:16, 2011년 6월 29일 (UTC)[응답]

10대 편집자

나는 우리가 10대 편집자들에게 정책을 설명하는 위키피디아 페이지/이슈가 필요하다고 생각한다.위키피디아가 이미 있다는 거 알아:젊은 편집자들을 위한 지침이지만 이것은 10대 편집자들을 화나게 할 수 있는 유치한 방법으로 쓰여지고 있다.만약 충분한 지지가 있었다면 나는 그 페이지를 다시 썼을 것이다.Oddbodz (대화) 21:28, 2011년 6월 18일 (UTC)[응답]

젊은 편집자들을 위한 단순한 어조에 모욕당할 만큼 나이가 많은 사람이 아직 정책 자체의 '성인' 어조를 이해할 수 없을지...?╟-TreasuryTagmost 평온한 21:31, 2011년 6월 18일 (UTC)[응답]

어떤 십대들은 그들의 성숙도가 의심받고 있다고 느낄지도 모른다.그러나 그들은 완전한 성인 버전을 읽고 싶어하지 않을 수도 있다.그것은 단지 가장 중요한 것이다.Oddbodz (대화) 21:38, 2011년 6월 18일 (UTC)[응답]

아니면 아예 읽고 싶어하지 않을 수도 있다. 그러나 나는 그들이 그렇게 하기를 기대하는 것이 지극히 타당하다고 생각한다.╟-TreasuryTag ►condominium-╢ 21:39, 2011년 6월 18일 (UTC)[응답]

위키피디아는 "성인" 장소다. 나는 다양한 연령대와 인구 통계학자들의 기여에 전적으로 찬성한다. 하지만 만약 당신이 우리의 전문적 스타일의 지침을 해독할 시간을 가질 수 없기 때문에/그것이 싫어서 스푼푸드의 정책을 필요로 한다면...그건 좋은 일이 아니야줄리안콜튼 (대화) 21:46, 2011년 6월 18일 (UTC)[응답]

그 정책들은 일반적으로 13세 이상이면 충분히 읽을 수 있다.AD 21:32, 2011년 6월 18일 (UTC)[응답]

바, TT나 줄리안콜튼의 말은 듣지 마.그냥 무슨 이유에선지 널 겁주려는 거야그냥 에세이를 말하는 거잖아, 그러니 그냥 클릭해: 위키백과:10대 편집자를 위한 안내와 쓰기 시작.나는 너의 충고가 유용하다고 생각하는 사람들이 있을 거라고 확신해.
— V = IR(Talk • 기여) 21:50, 2011년 6월 18일 (UTC)[응답]

흠—당신이 나에게 위키백과라고 불리는 에세이를 쓰도록 영감을 준 것 같아.나쁜 믿음을 가지다.어떡해, 벌써 하나 있어.좋아. ╟-TreasuryTag►ship-╢ 08:18, 2011년 6월 19일 (UTC)[응답]

나는 아무것도 추정할 필요가 없다.넌 혼자서 탄약을 공급했어
— V = IR(Talk • 기여) 23:14, 2011년 6월 21일 (UTC)[응답]

좋은 생각인 것 같아.나는 내가 처음 가입했을 때 모든 정책을 읽는 것에 열의가 없었다는 것을 안다.좀 더 접근하기 쉬운 방법으로 쓰여진 페이지를 갖는 것은 도움이 될 것이다.무스카토 22:17, 2011년 6월 18일 (UTC)[응답]

괜찮다. 하지만 십대들에게 그것을 겨누는 것은 정말 바보같고, 후견인처럼 들리지 않는 것은 매우 어려울 것이다.정책 페이지 맨 위에 있는 "넛 껍질" 상자는 보통 그것들을 꽤 잘 요약한다.AD 13:06, 2011년 6월 19일 (UTC)[응답]

이 페이지는 모든 정책을 간략하게 요약한 것처럼 보인다.AD 13:09, 2011년 6월 19일 (UTC)[응답]

FWIW, 우리의 정책과 지침의 대부분은 산문을 개선하기 위해 다시 쓰는 것과 관련이 있다.협업 편집은 많은 장점이 있지만 명확한 산문은 그 중 하나가 아니다.나는 꼭 필요한 경우가 아니면 그 중 어느 것도 굳이 읽으려고 하지 않는 경향이 있다.내가 편집을 시작하기 전에 그것들을 읽었더라면, 나는 편집을 시작하지 않았을 것이다.던컨힐 (대화) 13:53, 2011년 6월 19일 (UTC)[응답]

우리의 현 정책이 (부분)고교 교육을 받은 사람이 읽는데 어려움을 겪을 정도로 작성됐다면 그건 고쳐야 할 문제다.만약 사람들이 그것들을 읽는 것을 귀찮게 할 수 없다는 것이 문제라면, 별도의 페이지를 만드는 것은 아마도 큰 도움이 되지 않을 것이다.미스터 지맨 15:08, 2011년 6월 19일 (UTC)[응답]

사실 학부 수준의 교육.나는 책 읽는 것을 좋아하는 사람이다.정책의 문제는 산문이 그저 너무 무미건조하고 평평하다는 것이다.던컨힐 (토크) 2011년 6월 27일 (UTC) 10:21[응답]

하지만 그것들은 흥미롭고, 단지 유익하고 이해할 수 있어야만 하는 것이 아니다.그들은 여가 목적으로 그것들을 읽는 사람들을 목표로 하는 것이 아니라, 위키피디아를 효과적으로 편집하기 위해 그것들을 읽어야 하는 사람들을 목표로 한다.비교해 보면, 플랫 팩 가구들에 대한 지침은 대개 꽤 건조하다.이런 종류의 글은 읽고 싶은 사람이 아니라 읽어야 할 사람을 위해 만들어진 것이다.╟-TreasuryTag►ship-16, 2011년 6월 27일 (UTC)[응답]

뭔가 흥미롭지 않으면, 사람들은 세부적인 것을 잊어버리고 가끔 그냥 대충 훑어보는 경향이 있다.만약 여러분이 사물을 흥미롭게, 심지어 웃기게 만든다면, 사람들은 어떤 말을 했는지 기억하고 그것을 읽고 싶어 할 것이다.가구 시공 일러스트레이션과 비교하는 것은 별로 생각할 필요가 없는 간단하고 간단한 것이기 때문에 여기서는 그다지 유용하지 않다.사람들이 많은 위키백과 가이드라인을 준수할 것으로 기대되는 많은 위키백과 가이드라인은 사람들이 그 중 많은 것을 따를 것으로 기대되며, 당신은 사람들이 그들이 결코 읽지 않은 가이드라인을 따르도록 할 수 없다.어떤 것들은 상식적이지만, 어떤 것들은 그렇지 않다.윌리엄 매튜 플린더스 페트리 세이 샬롬 경! 2011년 6월 27일 12시 36분 (UTC)[응답하라]

난 동의해야 해.대부분의 정책들은 우리의 많은 기사들보다 꽤 명확하고 명확하다.개별 사례는 정책 페이지 자체에서 보다 명확한 표현에 대한 합의를 이끌어내도록 토크 페이지 상의 토론을 통해 처리되어야 한다.문제가 있다면, 그것은 종종 우리의 기준으로는 눈에 띄지 않지만, 새로운 편집자에게서는 눈에 띄는 것처럼 보이기 때문이다.심지어 그것조차도 우리 정책에 문제가 되지 않는다. 새 편집자는 우리가 정책에서 사용하는 방식보다는 그냥 공통적으로 "알림할 수 있는" 방식으로 사용했을 뿐이다.워보트9 (대화) 23:08, 2011년 6월 21일 (UTC)[응답]

우리는 개선 작업을 하고 있어!이제 막 시작했을 뿐이다. 그러나 WP:V에서 우리가 만들고 있는 방향을 확인하십시오.나는 10대 편집자를 목표로 한다는 말이 좋은 방법이 아닐 수도 있다고 생각한다. - 10대가 아닌 사람(또는 심지어 10대로 인식되고 싶지 않은 십대들)은 그저 "거기에 가지 않는다"는 것일 가능성이 높다. (자극적으로 그것을 짜증나게 잘난 체한다.)우리에게 필요한 것은 십중팔구 비트겐슈타인의 사다리 접근법이다. 페스키 (토크 …스토크!) 04:36, 2011년 6월 23일 (UTC)[응답]

우리가 기억해야 할 것은 위키피디아가 누구나 편집할 수 있는 백과사전이라는 것이다.편집자의 나이를 파악할 수 있는 소프트웨어도 없으며 위키백과는 다음과 같다.젊은 편집자들을 위한 조언은 의도적으로 10-14세 연령층을 위한 설득력 있는 언어 수준을 목표로 했다.쿠드풍 กุผึ ( ((대화) 06:15, 2011년 6월 23일 (UTC)[응답]

위키백과 정책은 매우 명확해야 한다:

1. 십대들은 인간이다.
2. 금지되지 않은 인간들은 위키피디아 편집을 환영한다.
3. 그러므로 금지되지 않은 십대들은 위키피디아 편집을 환영한다.

그게 다야—톰 모리스 (대화) 2011년 6월 27일 (UTC) 10시 7분[응답]

그게 어떻게 관련이 있지?╟-TreasuryTag►Odelsting-╢ 10:17, 2011년 6월 27일 (UTC)[응답]

요점은 우리가 위키피디아를 재작업하는데 시간을 보내야 할지 완전히 확신할 수 없다는 것이다.젊은 편집자를 위한 지침.나는 우리가 좋은 이유를 찾을 수 없다면, 특히 젊은 사용자들에게서, 왜 특정한 의견수렴이 필요한지, 그리고 왜 젊은 사용자들은 그것이 잘난 체하지 않는지 확실히 하기 위해 일을 할 수 있을 것이라고 생각하지 않는다.—톰 모리스 (대화) 10:22, 2011년 6월 27일 (UTC)[응답]

위키백과의 유일한 재작업:젊은 편집자들이 필요로 하는 지침은 위키미디어 홍보 프로젝트에서 개발되고 있는 것과 같이 보다 매력적인 HTML 피부에 그것을 떨어뜨리는 것이다.청소년들을 위한 물건들은 청소년들을 위한 물건들이며, 선생님들이 아는 것처럼 그들에게서 후견인으로 인식되지 않을 것이다.14/15를 훨씬 넘는 사람은 우리의 다른 지시 페이지에서 핵심을 파악하거나 도움을 요청하는 방법을 이해할 수 있어야 하며, 도움을 받을 때 조언을 받을 수 있어야 한다.쿠드풍 กุผึ ( ((토크) 14:29, 2011년 7월 4일 (UTC)[응답]

나는 Oddbodz의 원래 제안 이면에 있는 의도에 감사하며, "젊은이들을 위한 노력이 그들에게서 (언제나) 후견인으로 인식되지 않을 것"이라는 포괄적 진술을 지지하는 데까지는 이르지 않을 것이다.하지만, 이 에세이는 9살과 10살, 그리고 위키피디아를 편집하는 11살과 12살이라는 많은 수의 사람들이 그것을 즉각적으로 분명히 해야 하기 때문에, 나는 이미 에세이에 대한 피드백을 찾고 있었고, 에세이가 목표 연령층에 어떻게 인식되고 있는지를 알고 있었다.그 피드백의 일부는 에세이의 토크 페이지에 있고, 일부는 다른 곳에 있고 일부는 아직 추가되어야 한다.피드백은 다양한 연령대(피플을 제공한 가장 어린 사람은 10세, 가장 나이가 많은 사람은 15세)와 다양한 유형의 편집자(생산적으로 기여하는 데 수개월을 소비했지만 어려움이 없었던 사람 사이의 범위)에서 현재 무기한 차단되어 있고 일부 사람들에게도 그렇게 남아 있을 것 같은 사람들에게까지 해당된다.시간이다

이 실의 주제와 관련하여 피드백에서 나온 것은 그 중 현재 쓰여진 에세이가 잘난 체하고 있다는 것을 시사한 것이 하나도 없다는 것이다.가장 가까운 것은 피드백을 준 최고령 아동 편집자가 그것을 "상식"으로 간주했다는 것이다. 즉, 나는 15세의 누군가가 이미 다른 장소에서 인터넷 안전에 대해 광범위하게 배웠을 것이라고 생각한다. 그러나 그 편집자는 또한 이 에세이가 다른 곳에서는 찾을 수 없었던 정보를 제공하는데 있어서 그들에게 매우 유용했다고 말했다.여기, 그리고 심지어 그들이 실제에 유용하다고 생각하는 부분까지 인용했다.교육자들에게도 친숙할 것 같은 한 가지 주목해야 할 점은 피드백을 준 나이든 청소년들조차 에세이가 있다는 이유만으로 에세이가 권위를 가지는 것으로 보았고 그것은 공식적인 것처럼 보인다는 점이다. 예를 들어, 그들은 위키피디아에서 에세이가 정한 "규칙"을 얼마나 잘 충족시켰는지에 대해 그들 자신의 과거 행동을 판단하고 있었다.

따라서 에세이가 목표 청중들에게 잘난 체하는 것으로 간주되는 것은 문제가 되지 않는다.나는 또한 에세이에 제시된 조언의 유형을 뛰어넘어 (또는 그들이 넘어섰다고 느끼는) 젊은 편집자들이 위키피디아의 다른 문서들을 대신 읽을 수 있다는 것, 그리고 만약 우리의 문서가 지능적인 10대들에게 사용하기 어렵다면, 우리는 우리의 문서를 개선해야 한다는 것, 즉, Rathe.r 여러 연령 그룹에 대해 여러 개의 축소판을 만드는 것보다.(WP를 가지고 있는 그 연령층의 일부를 겨냥한 "노인 편집자 가이드라인" 에세이를 쓰는 것은 재미있을 것이다.IDNTHEAR 및 이와 유사한 문제)그렇기는 하지만, 누군가가 그것을 쓰고 싶다면, "청소년들을 위한 위키피디아" 가이드의 창설을 금지할 이유는 없지만, 그것이 우리의 노력의 초점이 되어서는 안 된다. --Demiurge1000 (대화) 18:28, 2011년 7월 4일 (UTC)[응답]

그것이 잘난 체하는 것인지 아니면 학부생을 포함해야 하는 것인지에 대한 문제는, 나는 도대체 어떻게 십대들에게 유용한 지침이 될 것인지 이해하려고 애쓴다. 새로운 편집자들은 천천히 시작하고 마치 시험을 보는 것처럼 정책서를 꼼꼼하게 공부하지 않는다. 그리고 몇 년 전 내가 환영받았을 때, 나는 그곳에서 너무 쉽게 끝나지 않을 것이다.박사 논문보다 더 많은 텍스트가 있는 각 페이지에 대한 20개의 링크가 있는 경우:나는 그것들을 하나도 읽지 않고 계속하면서 사실을 배웠다.대신에 이 가이드가 "나는 WP에 따라 당신의 흥미롭고 도움이 되는 모든 작업을 삭제했다:위키백과의 아이들을 위해 패러프레이션을 한 셀프쿼티:젊은 편집자들을 위한 조언" 좋지 않은 생각일 것 같아. --스퀴도니우스 (대화) 20:42, 2011년 7월 4일 (UTC)[응답]

그래, 맞아, 나는 링크의 보다 상세한 메뉴 중 하나에서 환영을 받은 것 같아. 그리고 그 메뉴 중 어떤 것도 읽어 본 적이 없어.단순화된 그래픽의 일부에도 몇 십 개의 링크가 달려 있는데, 사실 나는 링크 중량이 적지만 여전히 도움이 될 만한 링크가 있다는 이유만으로 W-스크린을 사용하기 시작할 수도 있다.나는 대개 환영 템플릿을 남기고 나서 지침 에세이를 보라고 하는 아주 간략하고 개인화된 별도의 메시지를 남긴다.

어떻게 하면 사람들이 실제로 그것을 읽도록 격려할 수 있을까?음, 별개의 짧은 메시지는 링크의 큰 메뉴보다 그들을 더 끌어당길 것이다.게다가 만약 여러분이 피드백을 요청한다면, 이것은 힘을 실어주는 것에 관한 것이다; 그것은 단지 그들이 화가 난 사람들이 항상 그들을 되돌리는 것을 참을 수 있다면 그들이 때때로 편집할 수 있는 큰 숙제 자원이 아니라, 그들의 의견 또한 요구되고 있는 협동적인 공동체라는 생각을 그들에게 소개한다.그게 그들을 끌어들인단 말인가?그래, 가끔은 그렇지

어떻게 하면 더 많은 사람들(청소년 포함)이 이러한 종류의 자료를 조기에 학습할 수 있는 시간을 갖도록 할 것이다.좀 더 몰입하게 만들어라.

그것이 젊은 편집자들을 비판하기 위한 빠른 방법이 될 위험에 대한 당신의 요점은 좋은 것이다.WP:경쟁력은 이런 방식으로 너무 자주 사용되며, 사용되어서는 안 된다.그러나 나는 아직 WP를 본 적이 없다.YOUNG은 그런 식으로.사실, (더 나이가 많은 젊은 편집자 중 한 명으로부터) 일부 피드백은 그들이 WP를 가지고 있었다는 것이다.역량이 부적절하게 그들의 얼굴을 찌르고, 따라서 WP를 읽는 것:영은 그들의 기여가 실제로 가치가 있다고 말해주었기 때문에 많은 도움을 주었다. --Demiurge1000 (토크) 21:23, 2011년 7월 4일 (UTC)[응답]

위키백과 이름 바꾸기:관리자 알림판/Wikipedia 관련 사건:커뮤니티 포럼

WP로부터 관리자의 주의가 필요하지 않은 토론을 시도하고 얻을 수 있는 또 다른 방법이 실패한 후:ANI(이름: 위키백과:분쟁해결 게시판), 모든 의미에서 기본적으로 "커뮤니티 포럼"인 ANI의 기능에 대한 BS를 중단해야 할 때다.ANI는 기본적으로 사용하기 쉽기 때문에 커뮤니티가 어떤 이슈든 토론에 임하기 위해 가는 포럼임이 분명해졌다.그것을 현재의 이름으로 부르는 것은 많은 사람들에게 지나치게 혼란스럽고 말이 되지 않는다.따라서, 나는 (좀 더 공식적으로) 위키피디아를 다음과 같이 제안한다.관리자 게시판/사건 이름은 위키백과로 변경:커뮤니티 포럼.–MuZemike 20:37, 2011년 7월 3일 (UTC)[응답]

설명:나는 그것이 비교적 좋은 생각이라고 생각하지만, 나는 그것을 움직이는 이유를 전혀 모르겠다.내가 보기에 ANI는 커뮤니티 포럼처럼 보이지만 편집자들이 그곳에 오는 이유는 관리자만이 할 수 있는 행동을 요청하기 위해서입니다.관리자가 모든 아카이브를 이동하는 것이 얼마나 골치 아픈 일인지는 말할 것도 없다(알고 있음).move-subpages해당되지 않음).세라돈 21:08, 2011년 7월 3일 (UTC)[응답]

코멘트 나는 분쟁 해결 안내판이 꽤 잘 작동하고 있다고 생각한다.거기서 분쟁이 해결되는 것 같다.나는 당신이 실제로 관리자 잘못과 관련된 문제들을 다루기 위해 ANI가 필요하다고 생각하지만, 내 경험에 비추어 볼 때 ANI는 그렇게 하지 못하기 때문에 그것을 없애는 것은 괜찮다고 생각한다.그래도 분쟁해결 안내판은 유지하고 싶다. -- 지우개헤드1 <토크> 21:18, 2011년 7월 3일 (UTC)[응답]

Comment Part of the that why still going to the why still going to the why doesn't going to the anI which that what are not there to take the another place for the ANI and b) ANI에 속하지 않는 문제들은 어쨌든 거기서 논의되고 있다. 왜냐하면 아무도 이 실들에 대해 아무것도 하지 않기 때문이다.ANI에 속하지 않는 스레드를 닫고 DRN과 같은 다른 포럼을 가리키도록 하는 관리 시행이 필요하다.그렇지 않으면 아무것도 변하지 않을 것이다.스티븐 장 21:51, 2011년 7월 3일 (UTC)[응답]

그냥 실타래만 닫는 게 아니라 관리자들이 대화를 적절한 포럼으로 옮기고, 포스터에 그렇게 했다는 것을 알려야 한다고 말하고 싶다.하지만 그렇지 않으면, 나도 네 말에 동의해.문제가 해결되는 유일한 방법은 a) 대안을 제시하고 b) 사람들이 그것을 사용하도록 하는 것이다.~ 메소더름 (대화) 22:06, 2011년 7월 3일 (UTC)[응답]

마을 펌프스가 실제 커뮤니티 포럼이기 때문에 반대한다.'WP:커뮤니티 포럼'은 WP로 리디렉션되어야 한다.VP. ANI는 관리자(모든 사용자가 아님)의 주의를 요하는 사고(대화, 질문 또는 토론이 아님)를 대상으로 한다.이름을 바꾸는 것은 사람들이 그 페이지의 목적을 알아내는 것을 더 어렵게 만들 뿐이다.WhatamIdoing (대화) 23:48, 2011년 7월 3일 (UTC)[응답]

WhatamIdoing과 같은 이유로 반대한다 - 우리는 보드의 효율화와 조직화가 더 필요하고, 그들의 기능이 무엇인지 명확히 하고 묘사할 필요가 있다.이것은 반대 방향으로 간다.미안하지만 이사진 몇 개를 합병하는 게 좋겠는데캐스리버 (토크 · 기여) 00:06, 2011년 7월 4일 (UTC)[응답]

또한 WhatamIdoing에 따라 반대하십시오.우리는 ANI가 관리자 코멘트와 개입을 필요로 하는 이슈에 대한 것이라는 것을 사이트 전체에 걸쳐 좀 더 명확하게 강조할 필요가 있다.현 게시판의 이름이 가장 적합하다.우리는 좀 더 과감하게 처량한 사람들을 보다 적절한 게시판으로 안내해야 한다.쿠드풍 กุผึ ( ((대화) 13:54, 2011년 7월 4일 (UTC)[응답]

특정 사용자 그룹으로 Wikilove 기능 제한

나는 위키피디아가 소셜 네트워킹 사이트가 아니기 때문에 비관리자 확증 사용자에게는 허용되지 않아야 하고 비관리자에게만 선택적으로 허용되어야 한다고 확신한다.재스퍼 덩 (대화) 22:02, 2011년 6월 30일 (UTC)[응답]

오, 진정해...그 다음엔 우리가 더 이상 '안녕'이라고 말할 수 없다는 걸 너도 알잖아. — Edokter (대화) — 22:25, 2011년 6월 30일 (UTC)[응답]

사실 난 재스퍼가 옳다고 생각해. 그리고 왜 그런지 보는 건 시간 문제야.말레우스 파투오름 22:28, 2011년 6월 30일 (UTC)[응답]

우리는 소셜 네트워크는 아닐지 모르지만, 우리는 공동체다.나는 초창기 편집자들, 특히 협업을 촉진하는 편집자들을 위한 기능을 차단하는 것을 믿지 않는다. — Edokter (대화) — 22:35, 2011년 6월 30일 (UTC)[응답]

에덕터를 차단하는 것은 그렇게 되지 않을 것이다. "나만의 것을 만드는" 옵션을 살펴보았는가?MalleusFatuorum 22:48, 2011년 6월 30일 (UTC)[응답]

응, 그거 후회하게 될 것 같아.--SPHILbrickT 01:49, 2011년 7월 1일 (UTC)[응답]

그건 정말 말도 안 되는 캘리포니아 생각이었어.하지만 난 그게 꽤 좋아, 모든 끈적끈적한 "사랑"에 비하면 말이야.MalleusFatuorum 01:58, 2011년 7월 1일 (UTC)[응답]

분명히 캘리포니아 MF가 질투하는 거야?세계 7위의 경제대국.의료기기, 통신, 소셜 네트워킹(내가 부정적이라고 생각할 수도 있지만), 위키백과(OK, 또 다른 부정), 자동차 디자인, 벤처 캐피털, 컴퓨터 장치, 화려하고 지적인 여성에 있어서 중요한 것은 거의 모든 개발과 제조가 이루어지고 있다.다시 말해, 캘리포니아가 없다면, 미국은 거꾸로 공화당이 운영하는 반과학 파시스트 종교 국가가 될 것이고, 캘리포니아 사람들은 거의 비웃었다.그리고 우리는 당신에게 우리의 훌륭한 냄비를 허락하지 않을 것이다.OrangeMarlin^{Talk• Contributions} 03:09, 2011년 7월 1일 (UTC)[응답]

왜 캘리포니아를 질투하는 거지?평방 마일당 변호사 수가 지구상의 다른 어떤 곳보다 많은 것으로 보이는 주?MalleusFatuorum 03:14, 2011년 7월 1일 (UTC)[응답]

사실, 그것은 뉴저지, 매사추세츠, 코네티컷, 뉴욕, 로드아일랜드, 메릴랜드, 델라웨어, 일리노이, 펜실베이니아, 플로리다가 앞서는 (순서에 따라) 제곱 마일당 활동 중인 변호사들을 위한 미국의 주 리스트에서 12위에 올랐다.게다가, 콜롬비아 구역과 푸에르토리코 구역은 둘 다 캘리포니아보다 평방 마일 당 훨씬 더 많은 변호사를 보유하고 있다.WhatamIdoing (대화) 14:51, 2011년 7월 2일 (UTC)[응답]

내가 이 실을 연 이유는 위키로브(이 IP와 같은 것)와 관련된 것들로 최근 몇 차례 트롤링한 사건 때문이었다.게다가, 많은 비자동 확인 사용자들은 헛간 스타 등의 의미를 알지 못한다.따라서 비자율 확증 사용자가 컨펌된 상태를 신청하여 Wikilove에 가입할 수 있다면 타당하다고 생각한다.IP가 개입하는 것을 허용하기에는 너무 위험하다.

"...우리 모두 잘 지낼 수 있을까?"버스정류장 (토크) 04:17, 2011년 7월 1일 (UTC)[응답]

Orangemarlin은 캘리포니아와 관련된 모든 것에 대해 틀렸다는 것을 지적하고 싶다.캘리포니아에서 온 위키피디아 NOT뿐만 아니라, 더 나쁜 것은- 플로리다에서 온 것이다; 뉴욕 주에서는 캘리포니아보다 더 많은 의료기기(특히 뉴욕 글렌스 폭포)를 개발했다. 미국에서 가장 큰 민간 부문 건설 프로젝트는 AMD에 의해 개발되고 있는 미국 내 최신 칩 팹인 뉴욕 몰타에 있다.컴퓨터 칩 회사들의 대체 컨소시엄은 뉴욕 주 올버니에 있고, 물론 월 스트리트, 매디슨 에이브, 그리고 모든 주요 네트워크의 뉴스 본부는 뉴욕시에 있다(캘리포니아에서 가장 큰 도시의 두 배인 동시에 더 작은 지리적 경계에 있다).뉴욕주 업스테이트의 테크밸리는 실리콘밸리보다 더 건강한 경제 상태에 있다.오, 그래 그리고 캘리포니아는 다른 어떤 주보다 더 큰 예산 문제를 가지고 있어.캘리포니아를 제 갈 길을 가게 내버려 두어라.카멜빈키 (대화) 01:04, 2011년 7월 6일 (UTC)[응답]

탈퇴?

이러한 원치 않는 진보를 받지 않는 방법은 어떠한가?분명히 이런 바보 같은 통고를 하기 위해 버튼에서 손을 떼는 방법이 있지만, 받는 사람들은 그런 선택권이 없다.쇼트여단 하베스터 보리스 (토크) 02:14, 2011년 7월 1일 (UTC)[응답]

IMO 옵트 아웃 확인란은 송신과 수신을 모두 차단해야 한다. 누군가가 송신을 거부하지만 받기를 원할 가능성은 거의 없다.그것을 비활성화한 사용자들을 위해, 우리는 눈에 띄게 다른 사용자들에게 심장 기호를 비활성화하여 무슨 일이 일어나고 있는지 분명히 할 수 있다.

작지만 목소리가 큰 사용자 파벌이 이 기능을 싫어할 수밖에 없을 것 같고, 이것은 그에 대한 갈등을 완화시키는 간단한 방법이다.--Elocence* 02:54, 2011년 7월 1일 (UTC)[응답]

음, 만약 위키피디아가 페이스북과 같은 것이라면, 자동적으로 우리를 선택하게 될 것이고, 어떻게 선택을 해야 하는지 알아낼 수 없게 만들 것이다! :) OrangeMarlin 03:10, 2011년 7월 1일 (UTC)[응답]

진정으로 탈퇴하는 것은 불가능하다.버튼을 선택한 사용자에게 나타나지 않게 하는 것은 가능하다; 나는 작동될 아주 간단한 방법 하나를 생각할 수 있다.하지만 그들이 원하는 메시지를 수동으로 입력할 수 있기 때문에 나는 메시지를 받지 않기로 선택할 이유가 없다고 본다.반면에 보내기 위해 버튼을 제거하는 것은 유용할 수 있고, 실제로 나는 나 자신을 위해 그렇게 했다.프로데고 03:26, 2011년 7월 1일 (UTC)[응답]

대부분의 Wikilove 자료는 자신이 무엇인지 잘 모르는 사용자들에게는 찾기 어렵기 때문에 선택되지 않은 사용자들을 위한 버튼 제거만으로도 충분하다고 생각한다.재스퍼 덩 (대화) 04:09, 2011년 7월 1일 (UTC)[응답]

사람들은 또한 자동화된 회신을 원하는 것처럼 들린다.내 생각에 적절한 것은 할 수 있을 것 같다.

• 토끼 아이콘 'ikilove 주면 토끼처럼 얼어버린다'
• 삶은 토끼 아이콘 'ikilove 주면 집착해, 조심해'
• 토끼파이 '밥도 같이 먹고 친구도 될 수 있다'

위키백과 소프트웨어는 사용자와 관련된 자동화된 응답 목록을 찾고 사용자 페이지에 편집하려는 편집에 적합한 응답 목록을 선택하여 미리보기에 표시할 수 있을 것이라고 확신한다.흠 만약 그들이 그들의 편집을 그에 상응하여 변경한다면, 다른 메시지가 나올지도 모른다 - 여기에서 한 사람은 Eliza 타입의 대화에서 거의 통할 수 있다;-) Dmcq (대화) 07:58, 2011년 7월 1일 (UTC)[응답]

프로젝트 마감 제안/구 영어 위키백과 폐쇄

새로운 메타에 따라:폐업 프로젝트 정책, 나는 앵그 위키백과, 구 영어 위키백과를 삭제하자고 제안했다.나의 이유는 많지만 주요 이슈는 죽은 언어에 대한 정보가 이치에 맞는다는 것, 죽은 언어로 된 정보는 그렇지 않다는 것이다.Meta에서 의견을 제시하십시오.프로젝트 마감/구 영어 위키백과 폐쇄에 대한 제안▫ 조니미르닌자 06:10, 2011년 7월 4일 (UTC)[응답]

왜 여기에 게시하는 거야?츄우우우히:2011년 7월 4일 (UTC) 9:29, 세브 아즈86556^{> haneʼ} [응답]

아마도 이 프로젝트와 그 프로젝트의 언어 모두 그 안에 "영어"라는 단어가 포함되어 있기 때문일 것이다.그냥 어둠 속에서 한 방이면 돼.킬리움두드 (대화) 06:37, 2011년 7월 5일 (UTC)[응답]

그렇다면 라틴어, 산스크리트어 또는 올드 처치 슬라브어 위키피디아들을 폐쇄하고 싶으십니까?나는 너의 관점을 존중하지만, 나는 동의하지 않는다 - 나는 이 위키피디아들을 유지하는 것이 흥미롭다고 생각한다.ACEOREVIVEED (토크) 14:30, 2011년 7월 5일 (UTC)[응답]

"위키피디아는 폐차장이 아니라 다른 언어에 도달하기 위해서는 실제로 그 언어를 찾아야 하기 때문에(즉, 방해가 되지 않는다), 그것을 지키는 데 해가 없고, 위에서 말한 것과 달리 실제로 언어를 배우는데 유용하다.미쓰비시, 도요타, 기타 자동차 회사들이 라틴어를 도살하는 데 거리낌이 없다고 해서, 데드 언어가 테라바이트에서 12메가바이트의 쓸모없는 낭비라는 뜻은 아니다. --스퀴도니우스 (토크) 18:54, 2011년 7월 5일 (UTC)[응답]

위키피디아 목록에 있는 이 위키피디아에 주어진 이름인 "앵글로 색슨 위키피디아"를 왜 말하지 않는 겁니까?ACEOREVIVEED (토크) 19:54, 2011년 7월 5일 (UTC)[응답]

이 제안에 대해 논의하려면 위의 링크를 따르십시오.여기에 글을 쓰면 아무도 당신의 의견을 보지 못하게 할 것이다.자펠루브 (대화)20:12, 2011년 7월 5일 (UTC)[응답]

관료에게 관리 비트를 제거할 수 있는 기술적 능력을 제공하기 위한 제안서 재방문

"재방문 위키백과:adminship/Bureaucrat 선택 취소

위키백과에서 RFC를 성공적으로 수행한 후:마을 펌프(제안)/비활동적인 관리자들의 시스템 운영권 중단, 일부 편집자들(나 포함)은 우리가 위키백과를 다시 방문해야 하는지에 대해 궁금해하고 있다.관리/Bureaucrat에 대한 요청 상기 RFC가 요구하는 대로 관료들에게 비활성 관리자의 도구 제거를 수행할 수 있는 기술적 능력을 부여하기 위한 제안 선택 취소.그런 만큼 나는 이 제안에 대해 새로운 RFC를 시작할 것인지에 대해 여기에 의견을 묻고 싶었다.SoWhy 21:23, 2011년 7월 4일 (UTC)[응답]

나는 한 사람으로서 이것을 지지할 수긍할 것이다.모든 다른 사용자 권리 부여는 그것을 한 사람에 의해 되돌릴 수 있다.사실, 관리인/부레오크래트가 하는 모든 일은 되돌릴 수 있고 이것이 유일한 예외다.관료들이 이런 능력이 없는 것은 단지 우연일 뿐이다.AD 21:29, 2011년 7월 4일 (UTC)[응답]

나는 과거에 이 제안을 지지했고 그것을 다시 지지할 것이다.아칼라마리 21:31, 2011년 7월 4일 (UTC)[응답]

응, 물론 크래트는 이런 능력을 가져야 해.→ ROX ₪ 21:35, 2011년 7월 4일 (UTC)[응답]

괜찮은 것 같아. -- 지우개헤드1 <토크> 21:42, 2011년 7월 4일 (UTC)[응답]

나는 전에도 이것을 지지했지만, 지금도 그렇다.이제 비활동적인 관리자 제거 과정으로 더 자주 탈소화가 시작되기 때문에, 매번 스테어워즈로 가는 대신 신뢰할 수 있는 현지 사용자들이 탈소화 작업을 하게 된 것은 훨씬 더 이치에 맞는다.우리는 관료들이 정책과 표준 절차에 대해 알고 있다고 가정할 수 있는데, 그 중 많은 사람들이 모르고 있을 수 있는 것이다.많은 위키미디어 프로젝트들은 이미 관료적 패키지에 이 권리를 추가했다: 메타, 단순.위키백과, en.csinews, hi.pi.pi.fi.pi.pi 등관료들이 이 일에 정확히 선발된 것은 아니지만, 나는 그들이 현재 하고 있는 일과 밀접한 관련이 있는 추가적인 책임감을 가지고 그들을 신뢰하는 데 문제가 없다.자펠루브 (대화) 23:38, 2011년 7월 4일 (UTC)[응답]

• 우리가 앞서 나가지 않도록, 그 아이디어 자체에 대한 지지를 표명하기보다는, 어쩌면 RfC가 어떻게 진행될지 의논해야 할지도 모른다.과거의 토론은 그 아이디어에 상당한 지지를 보여주었지만, 공감대가 불충분하고, 제기된 질문이 충분히 명확하지 않으며, 또는 참여가 충분히 광범위하지 않다는 주장에 근거해 왔다.따라서 나는 다음과 같은 구체적인 단계를 권하고 싶다: 1) 뚜렷한 질문에 대해 명확한 RfC를 시작한다.예를 들어, "관료들에게 관리비트를 제거할 수 있는 기술적 능력을 주어야 하는가?"추가 옵션(예: 관료적 비트 제거 능력)이나 과거 토론(예: 커뮤니티 de-adminship)을 혼동한 기타 주제에 대한 언급이 없음.2) RfC를 널리 광고한다.관련 마을 펌프 페이지, T:CENT, WT:RFA, WP:BN, WP:AN, WT:ADMIN 및 기타 페이지(적절한 경우).표지판에 언급해 달라고 요청하십시오.가능하면 그것에 대한 감시목록 공지를 받아라.3) 가능한 한 명확한 합의를 바란다. --RL0919 (대화) 23:56, 2011년 7월 4일 (UTC)[응답]

새로운 '12개월' 결의안에 따라 절차적 탈지(description dissoaping)로 한정되고, 성공하기 위해서는 RfC 제안이 가능한 짧고 간결해야 하며, 무엇을 위한 제안인지 명시할 뿐만 아니라, 무엇을 위한 제안이 아닌지를 명확히 명시해야 한다. 그렇지 않으면 '사용자:X'의 의견 더미가 쌓일 것이다.그리고 대안적 제안 및 추가 도구 사용 상황에 대한 요청.RfC는 널리 광고되어야 한다.쿠드풍 กุผึ ( ((대화) 01:12, 2011년 7월 5일 (UTC)[응답]

자청서와 중재위원회 구제안은 어떤가, 둘 다 m:현재 SRP?–xeno^talk 01:41, 2011년 7월 5일 (UTC)[응답]

@쿠드풍:나는 그것이 바로 RL0919가 언급한 문제라고 생각한다.임호야, RFC는 그렇게 할 수 있는 기술적 능력에 관한 것이어야 해.크래트가 능력을 가져야 한다는 공감대가 형성되면 우리는 절차적 탈소나 제노가 언급하는 사례와 같은 구체적인 사례를 논의할 수 있다.다른 사용자 권리와 마찬가지로, 그룹이 (관리자에 대한 삭제 플래그와 같은) 그것을 가져야 하는지에 대한 질문은 그들이 그것을 사용할 수 있는 상황에서의 질문과는 별개다(예: WP:삭제 플래그에 대한 DEL).SoWhy 07:33, 2011년 7월 5일 (UTC)[응답]

RFC 2개를 설정하십시오.진지하게, 그것은 기술 능력에 대한 논의를 오염시키는 정책 문제를 막을 수 있는 유일한 방법이다.위키백과:sysop 비트 및 Wikipedia를 제거하는 comment/Bureaucrat 기술 능력 요청:관리직 제거에 대한 의견/정책 요청.후자의 경우, 자기 요구, 새로운 "비활성적 관리자" 접근법에 따른 일시적 중단, 그리고 Arbcom 구제안은 논란의 여지가 없어야 하지만, 그럼에도 불구하고, 논의는 별도로 유지되어야 한다.Rd232 공개 09:44, 2011년 7월 5일 (UTC)[응답]

맞아. 하지만 나는 어떻게 그것들을 동시에 열 수 있는 지에 대해서는 확신이 없어. 왜냐하면 두 번째 RFC는 어떤 의미가 있는지 알기 위해서는 첫 번째 RFC가 성공해야 하기 때문이야.그리고 동시에 개방할 수 없다면, 어떻게 하면 사람들이 첫번째 RFC를 오염시키는 것을 막을 수 있을까? 두번째 RFC에서 열어야 할 논의로?한 가지 아이디어는 ArbCom에서 온 한 명 이상의 존경 받는 중립 편집자에게 RFC를 조정하고 RFC의 범위 밖의 모든 논의를 삭제하도록 요청하는 것이지만 모든 편집자들이 그러한 중용을 받아들일지는 확실치 않다...SoWhy 10:34, 2011년 7월 5일 (UTC)[응답]

우리는 첫번째와 동시에 두번째를 열 수 있다. 그것은 단연코 가장 간단한 해결책이다.두 번째 RFC가 할 일은 맨 위에 언급하는 것이다. 이 RFC는 위키백과가 다음과 같은 경우에 요구되는 정책에 관한 것이다.sysop 비트 제거를 위한 comment/Bureaucrat 기술력 요청이 성공한다.그리고 첫 번째는 이 RFC가 순전히 관료들에게 sysop 비트를 제거할 수 있는 기술적 능력을 주는 것이라고 말할 것이다. 이 능력의 사용은 지역사회가 결정하는 어떤 정책에 의해 지배될 것이다. 위키백과에서 잠재적인 정책이 논의되고 있다.관리직 제거에 대한 의견/정책 요청. 기술 능력은 활성화될 경우 특정 정책이 지역사회에 의해 승인되지 않는 한 또는 승인될 때까지 사용되지 않을 수 있다.그런 식으로, 어떤 편집자에 의한 절제는 허용되어야 한다. 왜냐하면 잘못된 의견을 옮길 수 있는 좋은 장소가 있기 때문이다(그러나 어쨌든 그 장소가 있으면 문제가 최소화되어야 한다).Rd232 공개^talk 12:06, 2011년 7월 5일 (UTC)[응답]

실제로, 최근 병렬 논의는 관리권이 그러한 역할의 전제조건이 되어야 하는지에 대한 보다 일반적인 정책 논의와 동시에 행정권 없이 CU/OS가 기능할 수 있는 기술적 능력을 추가하는 것에 대해 동시에 진행되었다.–xeno^talk 12:23, 2011년 7월 5일 (UTC)[응답]

좋은 지적이야, 난 확신해.이와 같이 나는 RFC 2개를 다음과 같이 시작했다.

• 위키백과:관리자 플래그를 제거할 수 있는 기술적 능력에 대한 의견/권장 요청
• 위키백과:관리자 권한 정책의 주석/부레오크라트 제거 요청

나는 RFC를 만드는 데 경험이 없기 때문에, 나는 여기 있는 모든 사람들을 초대해서 제안서와 구조로 그 페이지를 확장하는 것을 도울 것이다. 그래서 우리는 RFC를 곧 시작할 수 있다.SoWhy 13:43, 2011년 7월 5일 (UTC)[응답]

나는 기술적인 것에 약간의 배경과 구조적인 수정을 추가했다.아주 간단한 예/아니요 상황이기 때문에 둘 중에 그게 더 쉬울 것 같아.잠재적으로 사람들은 다른 경우에서 행동하는 관료들에 대해 다른 의견을 가질 수 있기 때문에 정책 하나는 좀 더 복잡할 수 있다.ArbCom 판결 vs 무효).우리는 서로 다른 상황에 따라 서로 다른 경우에 합의점을 결정하기 쉽게 하기 위해 서로 다른 섹션으로 토론하기를 원할 수 있다. --RL0919 (대화) 21:16, 2011년 7월 5일 (UTC)[응답]

나는 사람들이 다른 상황에 반대하면서 한 상황을 지지할 수 있도록 각 상황에 대해 별도의 섹션을 만들었다.이어 RFC가 폐쇄되면 자신에게 유리한 합의점을 가진 모든 상황이 정책에 추가될 수 있다.SoWhy 21:25, 2011년 7월 5일 (UTC)[응답]