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

템플릿:우브잉글리시

나는 방금 {{uw-영어}}}을 발견했는데, 번역 없이 영어 이외의 코멘트를 적극적으로 금지한다는 문구에 꽤 놀랐다.그것은 당신이 영어를 모르는 한 여기에 이해할 수 있는 의견을 남길 수 없다는 것을 의미한다: 얼마나 끔찍한 생각인가!당신이 다른 언어로 쓴 것에 대해 구글 번역기를 실행할 수 있는 사람은 누구나 있지만, 그것은 분명히 받아들일 수 없다. 만약 그렇다면, 우리가 왜 당신이 그것을 하는 것에 대해 불평을 하겠는가?그런 경우가 있기 때문에 {{user en-0}}인 사람도 자동 번역된 댓글을 남겨서는 안 된다.그렇다, 의도된 청중이 아닌 다른 사람이 읽을 수 있는 기사 토크 페이지에 외국어로 된 댓글을 남기는 것은 도움이 되지 않으며, 비영어 기사 텍스트는 바로 나오지만 사용자 토크 페이지의 사적인 대화와 프로젝트 페이지(공지판, WP:RD, WP:HD, 위키피디아는 문제가 아니다.누군가가 WP에서 분명히 잘못 번역된 메시지를 쓸 때:HD 또는 WP:RD, 우리는 일상적으로 "원어로만 쓰세요, 그러면 누군가가 번역해 줄 겁니다"라고 말하는데, 현지 언어를 이해하지 못하면 다른 언어의 위키피디아에서 영어 전용 요청을 하도록 적극 권장하고 있으며, 나는 불평할 다른 프로젝트에 대해 들어본 적이 없다(WMF 직원이 공지를 남기는 것조차 본 적이 있다).다른 프로젝트에서 영어!) 그런데 왜 우리는 여기서 같은 것에 반대해야 하는가?우리는 영어를 이해하지 못하는 사람들을 돕고자 하는 사람들의 비주거공간 기고를 환영해야 한다.마지막으로 템플릿은 WP에 링크됨을 참고하십시오.사용자 대화 페이지를 제안으로부터 특별히 면제해 주는 TPYES, 그리고 어쨌든 TPYES는 "좋은 관행"으로 프레임이 되어 있고, 받아들일 수 없다고 간주되는 행동으로부터 적극적으로 분리되어 있다.

이 점을 염두에 두고 나는 두 가지 제안이 있는데, 두 가지 제안 모두 실행될 수 없는 것이 분명한데, 그것은 현재의 템플릿을 완전히 삭제하거나 {{역사적}로 표시한다거나, 기본적으로 "다른 사람들이 더 잘 이해하는데 도움이 될 수 있을 것 같으니, 당신이 할 수 있다면 영어로 써 달라"는 문구를 대체하는 것이다.템플릿 토크 페이지보다 가시성이 뛰어나서 제안하는 겁니다.나이튼드 (대화) 17:54, 2015년 7월 24일 (UTC)[응답]

WP:SpeakenGLISH는 "영어 위키백과의 모든 대화 페이지에 영어를 사용하는 것이 바람직하다"고 말한다.템플릿은 첫 번째 소개 문장이 끝난 후 가이드라인의 변경되지 않은 문구를 사용해야만 한다.이 특정 지침은 2줄의 텍스트만 포함하고 있으며, 현재 합의를 반영하기 위해 템플릿에 쉽게 들어갈 수 있다.독일조 (대화) 2015년 7월 24일 (UTC) 18:19 [응답]

게르만 조의 말에 동의함.이와 같은 템플릿은 일부 영어가 아닌 다른 언어로 게시하는 것이 실제 문제일 때를 제외하고는 많이 사용되지 않을 것이다.두 가지 이상의 이유로 이슈가 될 수 있는데, 그 중 가장 분명한 두 가지는 a) 비영어 기사의 토크 페이지를 지배하는 것이며, WP를 구성하는 것이다.WP에 도달할 수 있는 파벌:LOCALConsensus는 다른 편집자의 입력이나 이해 없이 그들끼리 그리고 b) WP와 같은 정책을 위반하기 위해 다른 언어를 사용하는 경우:NPA 및 WP:Civil. 하지만 다른 편집자들이 여러분이 무엇에 대해 게시하고 있는지, 왜 게시하는지를 알아내는 것조차 처음에는 문제가 있다."Google Translation"은 포스터에도 적용된다; 습관적으로 다른 모든 편집자들에게 부담을 떠넘기는 사람들은, 음, 그만둘 필요가 있다. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ≼ ≼ 19:32, 2015년 7월 24일 (UTC)[응답]

• 만약 어떤 사람이 영어로 일관성 있게 의사소통을 할 수 없다면, 그들은 영어 사용자들 간의 협력을 통해 영어로 백과사전을 쓰고 있는 프로젝트에 기여할 수 없다.불친절해 보이는 것은 알지만, 당신이 이해할 수 없다면 여기에 기여하는 것은 무의미하며, 우리는 그것이 쓰여진 언어에 익숙하지 않고 모든 사업이 수행되는 것에 익숙하지 않아도 프로젝트에 기여하려고 노력하는 냉철한 타입의 사람에게 그저 친절하게 대하기 위해서가 아닌 척해서는 안 된다.비블브록스 (대화) 19:54, 2015년 7월 24일 (UTC)[응답]
  • 기고자가 아니라 소통에 관한 겁니다.기계 번역은 모든 WP를 허용한다.언어에 관계 없이 어느 정도 기여할 수 있는 능력 있는 사람.나는 영어 이외의 WP에서 en의 영어 동급의 개선을 제안하기 위해 그것을 자주 사용한다.WP 기사, 혹은 그들의 버전에 대한 우리의 검토를 요청하기 위해서입니다.en에 있는 템플릿의 목적.WP는 번역의 부담이 다른 모든 편집자들이 아닌 비영어권 화자에게 있다는 점을 분명히 할 필요가 있다.템플릿의 목적은 "잃어버려"라고 말하는 것이 아니다. :-) 이 템플릿은 아마도 온라인 번역 서비스에 대한 링크를 포함해야 한다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 20 20 _ᴥ20^ʌ 20:17, 2015년 7월 24일 (UTC)[응답]
    • 독일어를 할 수는 없지만 독일어 위키백과에 거의 1000개 정도의 편집을 했는데, 그 대부분은 다른 편집자들과의 의사소통(토크 페이지 대화 또는 [1]의 "Englische Frage" 섹션)이나 템플릿 수정이나 이미지 추가와 같은 사소한 것들이다.난 기사를 쓰려고 노력한 적이 없어. de:기존 아티클의 세부 정보를 변경하여 스텁을 만든 Quinter.내가 알기로는 아무도 내 행동에 반대하지 않았어.만약 우리가 이 템플릿을 계속 사용한다면, 그것은 확실히 영어의 부족이 문제를 일으키는 사람에게만 적용되도록 고쳐져야 한다.나이튼드 (대화) 2015년 7월 24일 21:18 (UTC)[응답]
  • 나는 12개 이상의 위키피디아에 이미지를 추가했다.또한, 일부 편집자들에게 "자신을 이해시키기" 위해 영어를 전혀 말할 필요는 없다.딱 맞는 것만 찾으면 돼.
    거꾸로 상상해보라: 당신은 우연히 다른 언어의 위키피디아에서 문제를 보게 된다.예를 들어, 당신은 그들이 사과에 관한 기사 맨 위에 배 이미지를 가지고 있다는 것을 알게 된다.너는 그 언어를 말하지 않는다.기부할 수 있겠니?난 네가 할 수 있다고 생각해.언어 능력이 전혀 필요 없는 사진을 지울 수도 있다.좀 더 관련성이 있는 것으로 대체해도 좋다.당신은 활동적이고 WP:Babel 박스가 영어를 이해한다고 말하는 사람을 찾을 수 있고, 그 사람을 위해 그 문제에 대해 영어로 메모를 남길 수 있다.이것들 중 어느 것이든 도움이 될 것이고, 나는 여기 영어가 아닌 사람들로부터 그러한 기여를 환영할 것이다.WhatamIdoing (대화) 21:59, 2015년 7월 24일 (UTC)[응답]

먼저 템플릿의 텍스트는

나는 네가 영어 이외의 언어로 댓글을 다는 것을 알아챘어.영어 위키피디아에 접속할 때, 당신의 의견을 누구에게 말하든지 간에, 항상 영어를 사용하라.이것은 지역사회가 전반적으로 논평들을 이해할 수 있도록 하기 위함이다.다른 언어를 사용할 수 없는 경우 코멘트의 번역을 제공하십시오.자세한 내용은 위키백과:토크 페이지 가이드라인.감사합니다.

그것은 거의 금지되어 있지 않으며, 어떤 경우에도 그 어떤 것도 다른 사람에게 그 템플릿을 사용하도록 강요하지 않는다.그래도 템플리트를 개선할 여지가 있다.대부분의 경우 포스터의 언어는 식별이 가능하고 대략 이해할 수 있는 번역이 제작될 수 있다. 비록 원래의 포스터가 그렇게 할 수 없을지라도 말이다.템플릿은 기계 번역에 연결할 수 있는 방법을 제공할 수 있다.그것은 wp:에서 도움을 요청하는 것을 제안할 수 있다.현지 대사관, 해당 언어의 위키백과 제목 토크 페이지 또는 해당 언어의 WP 도움말 페이지.때때로 여기의 논평은 위키간 협력과 관련이 있다."벵골어 위키백과에 이 주제에 정말 좋은 출처가 있다"고 말하면서 기여하기 위해서는 영어를 잘 써야 한다는 생각은 잘못된 생각이다.기여는 완벽하지 않고서도 가치가 있을 수 있다.우리는 단지 기고자를 일을 용이하게 할 장소로 이동시킬 필요가 있다.리드송도그컴 울부짖음! 20:26, 2015년 7월 24일 (UTC)[응답]

나는 네가 그것을 개선하는 것에 대해 좋은 생각을 가지고 있다고 생각해."할 수 있으면 댓글 번역을 해달라"고 말하게 만드는 것에 대해 어떻게 생각하십니까? WhatamIdoing (대화) 21:59, 2015년 7월 24일 (UTC)[

응답

] 그게 도움이 될 것

같아,

내

의견으로는.

나는 단지 경쟁적이지 않은 영어 편집자가 (다른 프로젝트에서 오든 안 오든) 메시지를 받고 구글 번역으로부터 그것이 기본적으로 경고라는 것을 알아내는 것이 두렵다.

우리는 이 템플릿을 가능한 한 부드럽게 만들어야 한다; 만약 누군가가 적극적으로 무시하고 여기 en:wp에서 외국어로 문제를 일으킨다면, 누군가는 문제의 언어로 개인화된 메시지를 남길 수 있다.

나이튼드 (대화) 05:07, 2015년 7월 25일 (UTC)[응답]

• 나는 확실히 그 템플릿이 도움이 되지 않는다고 생각한다. {{Uw-notenglish}}주요 네임스페이스에서 영어가 아닌 다른 글을 쓴 편집자들에게 이것은 영어 위키백과이고 외국 콘텐츠는 이동하거나 번역되어야 한다고 말하는 것은 당연하다.하지만 만약{{Uw-english}}"이것은 구글 번역기와 같은 기계 번역기를 사용하여 가능한 한 영어로 코멘트를 할 수 있도록 노력하라"는 말이 내 제안이 될 것이다.카테고리 링크:언어별 위키백과 또는 특정 언어를 추가하기 위한 추가 매개변수: 예를 들어, "독일어"라고 하는 매개변수를 추가할 경우 템플리트가 카테고리에 링크될 수 있음:사용자가 독일어로 대화할 수 있도록 사용자 de.또한 분명히 언어를 이해하지 못하는 사람의 토크 페이지에 영어 텍스트를 넣는 것은 별로 의미가 없을 수도 있다는 생각이 든다; 아마도 포함시킬 텍스트의 더 나은 버전이 확립되면, 우리는 몇몇 위키피디아 사람들에게 템플릿의 외국 번역을 하게 할 수 있을 것이다(예: 스페인어로 글을 올리는 사용자들이 메스를 얻을 수 있도록).그들이 완전히 이해할 수 없다고 생각하는 영어 메시지보다는, 스페인어로 이 문제를 설명하는 현자.—빌로프_(talk)^(c)(e) 18:09, 2015년 7월 25일 (UTC)[응답]
• 여기 이 템플릿 사용했던 사람 있어?WhatamIdoing (대화) 21:52, 2015년 7월 25일 (UTC)[응답]

네, 여러 번이요.비블브록스 (대화) 21:53, 2015년 7월 25일 (UTC)[응답]

나는 사용하지 않고 2007년 창작 이후 변함없는 문장인 "다른 언어의 사용이 불가피한 경우, 코멘트의 번역을 제공하라"를 검색했다.사용자 대화에는 2502개의 결과가 있고, 다른 네임스페이스에는 26개의 결과가 있다.그것은 대체용이며 전횡이 없다.프라임헌터 (대화) 23:22, 2015년 7월 25일 (UTC)[응답]

훌륭해, 비블브록스.그 템플릿을 게시함으로써 어떤 실질적인 결과를 얻고 싶으신지 말해주시겠습니까?다른 날에 다른 일이 있었다면 네가 좋아하는 몇 가지 예를 들어봐.또한, 효과가 있었는가?WhatamIdoing (대화) 22:23, 2015년 7월 26일 (UTC)[응답]

• 템플릿 크리프의 놀라운 예.나는 오랫동안 그것을 싫어했다.어떤 의도된 의미를 기계에 먼저 흘려 걸러내지 않는 것이 좋다.나는 그것을 사용자의 모국어로 보는 것이 더 좋다.마크 쉬에르베커 (대화) 22:09, 2015년 7월 25일 (UTC)[응답]

그래, 우리가 훌륭한 아이디어인 템플릿을 번역할 거라면, 구글은 그렇게 할 방법이 아니야.기계 번역의 정확성과 일관성은 언어에 따라 크게 다르다.독일어치고는 꽤 괜찮다.타갈로그나 만다린어는 별로야.우리는 사람들의 대화 페이지에 횡설수설하는 것을 원하지 않는다.비블브록스 (대화) 22:15, 2015년 7월 25일 (UTC)[응답]

템플릿이 아니었어!그건 악몽의 소리다.마크 쉬에르베커 (대화) 23:19, 2015년 7월 25일 (UTC)[응답]

• 나는 컴퓨터 사용자들이 기계 번역 링크가 최고의 해결책이라기 보다는 비영리적인 것이라고 제안할 것이라고 생각한다.소셜 공유 버튼을 추가하자는 마지막 제안은 편집자들이 특정 소셜 네트워크를 선호하지 않기 때문에 부분적으로 가라앉았다.마크 쉬에르베커 (대화) 23:26, 2015년 7월 25일 (UTC)[응답]

• @WhatamIdoing:나는 이것이 문제라는 느낌을 받더라도 너에게 대답하려고 노력할 것이다.

• 내가 성취하고 싶었던 것은 문제의 사용자들이 이것이 영어 위키백과라는 것을 이해하는 것이었고, 만약 그들이 그것에 대해 토론을 하게 된다면, 다른 사용자들은 그것이 그들 자신의 토크 페이지에 있더라도 참여할 수 있어야 한다.
• 내가 기억할 수 있는 최소한 두세 가지 예에서는 문제의 사용자나 사용자가 유쾌하게 번역을 제공했다.적어도 이 사례들 중 하나에서 그들은 사실 기사 내용에 대해 토론하고 있었음이 밝혀졌으므로 다른 사용자들이 그 토론에 대해 이해하고 참여할 수 있는 것이 다소 중요했다.
• 다른 경우에 그것은 간단히 무시되었고, 나는 그것을 더 이상 추구하지 않았다.
• 나는 여기서 언급하는 대부분의 사람들이 사람들에게 이곳 지역사회가 이해할 수 있는 방식으로 의사소통을 요구하는 것이 무례하다고 생각하는 것 같은 느낌을 받는다.나는 분명히 동전의 반대편에 있다, 나는 한 언어가 사용되는 것을 알고 일부러 다른 언어를 사용하는 공간에 들어오는 것은 무례하다고 생각한다.아마도 템플릿의 언어는 부드러워질 수 있겠지만, 그 밑바탕에 깔린 메시지는 완벽하게 유효하다.

• 만약 당신이 사적인 대화를 원한다면, 어떤 언어에서든, 위키피디아는 그것을 위한 장소가 아니다.이메일, 문자, 전화, 스카이프 등이 그것이다.비블브록스 (대화) 18:04, 2015년 7월 27일 (UTC)[응답]
  • 정말 도움이 되네.그러므로 메시지에 가장 유용한 초점은 다른 사람들이 참여할 수 있는 능력(또는 적어도 주제가 무엇인지 아는 능력)에 관한 것이어야 한다.
    "최선을 다하라"는 기준에 대해 어떻게 생각하십니까?만약 누군가가 영어를 말하지 않는다면, 나는 그가 실제로 알고 있는 언어를 "고의적으로" 사용하는 것이 무례하다는 것에 동의할 수 없다.WhatamIdoing (대화) 23:42, 2015년 7월 28일 (UTC)[응답]
• 구글 번역은 말 그대로 아무것도 없는 것보다 더 나쁘다.외국어를 유창하게 구사하는 사람이 번역할 수 있도록 외국어를 보존하는 것이 기계 번역으로 남겨진 혼란스러운 혼란으로 대체하는 것보다 훨씬 나을 것이다(이것은 내 의견만이 아니라 WP에서 성문화된다).마키네트란절제. --아헤흐트 (토크페이지
  ) 14:31, 2015년 7월 29일 (UTC)[응답하라]

"없음보다 더 나음"?나는 동의하지 않을 수 없다.그것은 신비한 원천 언어를 식별하는 데 매우 도움이 된다.나는 거의 변함없이 그것이 많은 단어들을 정확하게 번역했다는 것을 발견하는데, 이것은 적어도 나에게 주제가 무엇이고 인간 번역가를 찾아야 할 위치를 알려주고 종종 내가 해당 [아무거나] 언어의 WP 기사에 대한 링크를 찾을 수 있게 해준다.지푸라기라도 잡고 있을 때, 이것들은 작은 것이 아니다.물론 우리는 메인 스페이스에서 기계로 번역된 텍스트를 원하지 않지만, 우리는 확실히 토크 스페이스에서 그것을 이용할 수 있다.리드송도그컴 울부짖음! 2015년 7월 29일 15시 58분 (UTC)[응답]

어려운 문제가 있을 수 있지만 목적이 무엇인지에 따라 달라진다."이 사람 소식통인가?"치고는 꽤 괜찮은 편이다.뉘앙스를 알아내기에는 꽤 나쁘다.WhatamIdoing (토크) 17:20, 2015년 7월 29일 (UTC)

기계번역(또는 원문을 대체하는 경우)이라는 표시 없이 사용했을 때 무(無)보다 더 나쁘다.그런 표시로 더 가치가 있다 - 아니, 더 정확히 말하면, 아무나 기계번역을 스스로 할 수 있기 때문에 아무 가치도 없다... --Martynas Patasius (토크) 17:36, 2015년 7월 29일 (UTC)[응답]

주요 서구 유럽 언어 들어는 놀라울 정도로 재료의 신문과 같은 많은 간단한 형식에 대한, 당신은 상식 및이, 그 문제의 지식은 명백한 오류를 해결할 수 있다. 아시아 languag 들어(그리고 가끔 문화적 이해와 동등한 사무실과 기능을 인식한 이점) 좋을 수 있다.에스 나는t는 훨씬 덜 유용하지만, 핵심 단어나 구절을 포착하는 것이 가능한 경우가 많다.(물론 원문도 보존해야 하고, 번역도 인정해야 한다.) DGG (토크) 01:53, 2015년 7월 31일 (UTC)[응답]

반면에 독일어는 때때로 그 일반적인 규칙에서 예외적인 경우가 있으며, 특히 기계 번역은 독일어를 영어로 번역할 때 결정적인 '안 된다'를 생략하는 것으로 악명이 높다.

템플릿 언어를 다소 업데이트했으며, 사용자:비블브록스 등은 가능하면 언제나 영어 사용을 장려하는 전체적인 요점을 바꾸지 않고 다소 더 친근하게 생각할 것이다.영어 이외의 언어를 구사하는 사람을 얼마나 필요로 하고 감사해야 하는지를 말해주는 문장을 덧붙이는 것도 생각해 보았지만, 어디서 어떻게 해야 하는지는 아직 파악하지 못했다.(영감받으면 과감해져라)WhatamIdoing (대화) 02:14, 2015년 8월 1일 (UTC)[응답]

사용자 샌드박스 템플릿에 기능 추가

여기를 보십시오: 사용자:ManosHacker/sandbox에서 템플릿:사용자 모래 상자가 작동한다.신규 사용자는 목록으로 완벽하게 구성되고 간단한 클릭으로 샌드박스된 기사를 메인 기사 공간으로 이동할 준비가 된 다중 기사 샌드박스 작업장을 오류 없이 빠르게 작성할 수 있다(사용자 네임스페이스에서 메인 네임스페이스로 이동할 때 이러한 새로운 버튼이 없는 오류는 규칙이었다).기존 사용자의 물림 없음.우리는 위키백과학교에서 몇 달 동안 그것을 표준적인 관행으로 사용해 왔다.기능을 먼저 숨기기 해제하십시오.샌드박스가 있는 하위 문서를 따라 템플릿의 동작 변경을 확인하십시오.맴도는 것은 지침을 준다.샌드박스를 기사로 이동하면 개인 샌드박스 보기 목록에서 제거된다.···마노스해커 23:33, 2015년 7월 31일 (UTC)[응답]

정확히 뭘 제안하는 거야?Eman235/토크 10:29, 2015년 8월 1일 (UTC)[응답]

이 내용은 템플릿 토크에도 게시되었다.사용자 샌드박스#기능 추가.게시물을 연결하지 않고 여러 개의 대화 페이지에 동일한 내용을 게시하지 마십시오. WP:Multi. SiBr₄ (대화) 10:49, 2015년 8월 1일 (UTC)[응답]

이 제안은 다음과 같이 구성된 작업영역 기능을 템플리트 내부에 배치하는 것이다.사용자 샌드박스(이전 템플릿을 새 템플릿으로 바꾸기)···마노스해커 11:22, 2015년 8월 1일 (UTC)[응답]

사용자 샌드박스 템플릿에 기능 추가

여기를 보십시오: 사용자:ManosHacker/sandbox에서 템플릿:사용자 모래 상자가 작동한다.신규 사용자는 목록으로 완벽하게 구성되고 간단한 클릭으로 샌드박스된 기사를 메인 기사 공간으로 이동할 준비가 된 다중 기사 샌드박스 작업장을 오류 없이 빠르게 작성할 수 있다(사용자 네임스페이스에서 메인 네임스페이스로 이동할 때 이러한 새로운 버튼이 없는 오류는 규칙이었다).기존 사용자의 물림 없음.우리는 위키백과학교에서 몇 달 동안 그것을 표준적인 관행으로 사용해 왔다.기능을 먼저 숨기기 해제하십시오.샌드박스가 있는 하위 문서를 따라 템플릿의 동작 변경을 확인하십시오.맴도는 것은 지침을 준다.샌드박스를 기사로 이동하면 개인 샌드박스 보기 목록에서 제거된다.···마노스해커 23:33, 2015년 7월 31일 (UTC)[응답]

정확히 뭘 제안하는 거야?Eman235/토크 10:29, 2015년 8월 1일 (UTC)[응답]

이 제안은 다음과 같이 구성된 작업영역 기능을 템플리트 내부에 배치하는 것이다.사용자 샌드박스(이전 템플릿을 새 템플릿으로 바꾸기)그것은 새로운 사용자들에게 매우 유용하다.튜토리얼 샌드박스 1, 2, 3, 4, 5를 훨씬 더 많은 기능으로 대체한다.···마노스해커 11:22, 2015년 8월 1일 (UTC)[응답]

자원봉사자를 위한 이메일 주소

친애하는 여러분.

자원봉사자를 위한 위키백과 이메일 주소를 만들자는 제안은 메타에서 찾을 수 있다.위키미디어 포럼#Wikimedia 자원봉사 이메일 주소.너의 의견은 매우 환영받을 것이다.

진심으로 타케타 (대화) 07:05, 2015년 8월 2일 (UTC)[응답]

공신력

신뢰할 수 있는 출처 가이드라인에 따르면, 기사는 "신뢰할 수 있는 2차 출처에 근거해야 한다"고 되어 있으며, No Original Research는 "더 적은 범위에서" 사용되는 1차 출처에 대해 유사한 언어를 가지고 있지 않다.그러나 많은 전문적 공신력 기준은 2차 원천이 존재하지 않는 곳에서 기사를 작성할 수 있도록 허용한다.이것은 종종 위키피디아의 페이지들이 기본적으로 공식 웹사이트나 바이오의 거울에 불과한 결과를 낳는다.

여기서의 짐보의 토크 페이지에 대한 사전 토론에서, 나는 여기서 @Wnt:의 코멘트뿐만 아니라 @WhatamIdoing:의 코멘트에도 동의하는 것을 발견하였다: "우리는 가이드라인에 나와 있는 사람들이 그들의 관심 영역을 위해 충고를 완화하되, 다른 사람들을 위해 유지하도록 권고하고 있다."전문지침은 일반적으로 남용되고 있으며 그것들은 특정 주제영역에 유리한 지역사회의 편견을 성문화한다. 즉, 우리가 조절하려고 노력해야 하는 편견을 말이다.이러한 전문적 공신력 지침의 가장 합리적인 측면은 GNG와 완전히 중복되는 요소들이다.

나는 다른 사람들도 같은 생각을 하는지- WP에 통합하는 것이 더 현명할 것이라고 생각했다.GNG 또는 WP: 황금률, 아마도 짧은 예외 목록일 것이다.정말 중요한 것은 기사의 일차적 근거가 될 만한 믿을 만한 2차 출처가 충분한가 하는 것이다.기업M (토크) 11:17, 2015년 7월 24일 (UTC)[응답]

나는 그것이 "좋은 원천이 발견될 것 같다" 대 "좋은 원천은 이미 발견되었다"의 부분적 문제라고 생각한다.나는 다양한 공신력 가이드라인이 주로 #1에 관련된 것으로 알고 있다.아마 한두 가지 주제를 가지고 있으면 효과가 있겠지만, 나는 1위 요인들을 합친 리스트의 길이가 걱정된다.조조 유메루스(토크, 기여) 12:04, 2015년 7월 24일 (UTC)[응답]

위에서 언급된 내 논평에 대해서는 별로 개선될 수 없지만, 단 하나의 조정 가능한 매개변수, 즉 "가장"이 무엇을 의미하는지 나는 주목해야 한다.나는 전문적 공신력 지침은 폐기되어야 하고 우리는 GNG를 사용해야 한다고 생각한다. 그러나 GNG를 한 가지 보상적인 변경은 필요하다: 우리는 주제가 잘 정의되고 열거되고 주목할 만한 주제들의 구성원이면 주목할 수 있도록 허용해야 한다.골든 룰 기준 중 두 가지는 여전히 충족되어야 한다: 신뢰할 수 있는 출처가 있어야 한다(그것에 대해 인용할 출처가 없으면 기사를 가질 수 없다), 그리고 그것은 독립적인 신뢰할 수 있는 출처가 되어야 한다(그렇지 않으면 반의 모든 구성원들을 완전히 열거할 방법이 없다; 그가 X상을 수상했다고 말하는 모든 사람들을 위해 구글만 할 수는 없다).완화되는 기준은 보도의 범위가 중요할 필요는 없다는 것이다. - 우리는 표에 몇 가지 중요한 통계 자료만 있을 수 있지만, 왕조의 세대를 오르내릴 수 있도록 왕 목록에 공백을 메울 기사를 여전히 갖고 싶어 한다.조정 가능한 매개변수는 우리가 어떤 범주의 기사 중 어떤 부분이 이것을 적용하기 위해 주목할 만한 것으로 생각되어야 하는지에 대한 숫자를 정확히 붙여야 한다는 것이다.

예를 들어, 어떤 나라의 20*** 대선 캠페인에 대한 기사가 있다고 가정합시다.주요 경쟁자 10명에 대한 기사(XXXXX 20*** 대선 캠페인)가 있지만, 공모전에는 다른 사람들도 있다.그 중 누가 기사를 쓸 자격이 있는지 어떻게 결정하지?우선 누가 경쟁자인지에 대한 정의부터 살펴보자고우리는 국영방송이 그들의 통계에서 다루는 모든 사람들을 볼 수 있다. 하지만 그것이 주목할 만한가?SBC의 후보 세트는 그 자체로 주목할 만한 주제인가?그것은 어느 쪽이든 될 수 있고, 우리가 목록의 모든 구성원들을 다루는 기사를 갖는 것이 중요하다고 생각하는지를 반영한다.만약 그들의 세트가 잘 정의되어 있지 않고, 누가 "진짜"인지에 대한 명확한 생각이 없는 다른 시간에 다른 사람들을 포함시킨다면, 우리는 여전히 그것을 거부할지도 모른다.아니면... 우리가 사용할 수 있는 더 광범위한 잘 정의된 열거된 집합이 있을 수도 있고, 그런 집합은 완전한 커버리지가 정당화될 수 있다고 말하고 싶다.공영방송이 13명의 후보자 명단을 자체 보유하고 있는 경우 등.그러면 아마 한 주사무소에 공표가 된 15명, 공천청원이 접수된 17명, 청원이 접수된 24명의 명단이 있을 겁니다.그렇다면 이 세트가 또한 완성할 만한 가치가 있는지 어떻게 판단해야 할까?음, 부분적으로, 숫자 한계점에 의해.수업을 마치려면 50% 이상의 회원이 눈에 띄거나, 66.66% 또는 75% 이상이라고 말할 수 있는데, 일부는 90%가 될 수도 있다.그 특별한 선택은 여기서 이루어져야 하며, 이 정책이 얼마나 포괄적인지를 결정한다.하지만 우리가 무엇을 선택하든, 위키피디아는 우리의 공정한 기준을 지적할 수 있다면, 우리가 "이 사람은 나치야, 아무도 그를 지지하지 않을 거야"라고 말하는 많은 사람들과 긴 대화를 할 때보다 훨씬 더 공정하고 전문적으로 보일 것이다.그는 그렇지 않다. 그것은 단지 언론의 선전일 뿐이다. 등."Wnt (토크) 15:45, 2015년 7월 24일 (UTC)[응답]

주요 GNG와 주제별 공신력 지침(SNG)의 공신력에 대한 핵심은 공신력이 가정이라는 것이다. - 우리는 편집자들에게 마감일에 대한 걱정 없이 백과사전적 장점을 가질 수 있는 주제에 대한 기사를 작성할 기회를 주고 싶다.대부분의 주제에 대해, 이는 (GNG에서) 기사를 작성하기 위해 최소한 (2-3개 이상의) 이차 소스가 존재함을 보여주는 것을 의미한다.그러나, 다른 많은 주제에 대해서는, 어떤 주제가 (노벨상을 받은 사람과 같은) 이차적인 원천이 존재할 가능성이 가장 높은 어떤 이정표를 충족시켰거나, 그 이정표의 결과로 이러한 원천이 만들어질 것이라는 것을 우리가 인식할 수 있는 충분한 편집자로서의 경험을 가지고 있으며, 그래서 우리는 단지 기사 작성을 받아들인다.마일스톤을 문서화하는 기본 소스에 기초한다.이는 기존 소스를 찾을 수 있는 데드라인이 없는 시간을 제공한다(인터넷이 소스 위치의 모든 것이 아니라는 것을 인식하고, 일부 자료는 인쇄 또는 외국어로 인쇄되어 있고 위치까지 시간이 걸릴 것이다).
그렇기는 하지만, 5년 전에 만난 이정표에 근거하여 기사를 작성한 사람이 있고, 현재 어느 누구도 그것에 대한 출처를 찾을 수 없다면, 그것은 아마도 우리의 추정이 잘못되었다는 것을 의미하며, 우리는 경선 이상으로 기사를 합리적으로 확대할 수 없기 때문이다.소스, 삭제 또는 리디렉션 또는 병합은 그 당시에 완벽하게 허용되는 결과물이다.그것이 바로 우리가 항상 신뢰할 수 있는 2차 출처를 바탕으로 기사를 작성함으로써 편집자들이 개선 작업을 할 수 있도록 공정한 수당을 주는 견제와 균형이다. --MASEM (t) 15:54, 2015년 7월 24일 (UTC)[응답]

나는 WP 없이 만들어진 기사가 더 걱정된다.2차 소스가 없는 것보다 독립적인 소스.이것의 일반적인 예로는 「Fancy University」에 채용된 「Cruisher Knowledge」가 있는데, 그 기사의 출처는 전적으로 고용주의 웹사이트와 피험자 자신의 글에 소싱(그리고 현실적으로 그 어떤 것에도 소싱될 수 없다)하는 것이다.이는 WP:PROF. HatamIdoing (talk) 16:00, 2015년 7월 24일 (UTC)[응답]에 따라 허용된다.

@Masem: 나는 "일상적인 운영을 하고 있는 약 100명 이하의 조직은 눈에 띄지 않을 것 같다"와 같은 언어의 여지가 있다고 생각한다.이것은 우리가 출처를 찾아야 하는 시간을 절약해준다. 출처는 눈에 띄지 않는 것이 아주 명백할 때.아니면 다른 면에서는, 포춘지 선정 500대 기업이라면, 당장 발견되지는 않더라도, 모든 회사가 충분한 자원을 가지고 있을 것이기 때문에, 우리는 "포춘지 선정 500대 기업이 주목할 만하다"와 같은 말을 할 수도 있다.이것은 우리가 공신력을 검증하기 위해 연구를 해야 하는 시간을 절약하는 지름길이다.포춘지 500호도 @Wnt: 주목할 만한 과목의 한 반의 회원이 되는 것에 대해 말한 것을 잘 보여주는 예다.

그러나 지금과 같이 철저한 조사가 이루어져 출처가 발견되지 않았더라도 교수에 대한 기사는 보관될 것이다.나는 사람들이 포춘지 선정 500대 최고 경영자의 공신력에 대해 불평하는 것을 본다. 그러나 한 대학의 종신 교수에 대한 기사를 지지한다.그건 말도 안 돼; 나는 학문이 주목할 확률이 높기 때문에(아마 그렇지 않을 거야), 그렇다고 생각하지는 않지만, 정책으로 성문화되는 우리 공동체의 편향성(기업보다는 학문에 더 관심이 많다) 때문에 그럴 가능성이 더 높다고 생각해.기업M (토크) 02:38, 2015년 7월 25일 (UTC)[응답]

불행히도 WP의 주제/초점 영역은 독립된 소싱은 거의 없지만 SNG를 만나는 개인의 공신력을 위해 싸우는 사람들이 있다. 교수들은 한 영역이고, 프로 선수들은 다른 영역이다.우리는 특히 자기 홍보 자료를 피하기 위해 그 사람이 만날 수 있는 SNG와 무관하게 출처의 독립성을 요구한다.불행히도 편집자들은 이 분야들을 위해 열심히 싸울 것이다. --MASEM (t) 03:12, 2015년 7월 25일 (UTC)[응답]

@CorporateM:나는 독단적인 불성실 주장은 매우 나쁜 생각이라고 생각한다.심지어 전문적 공신력 지침이 그것들을 이론적으로, 서면처럼, 그것들은 단지 '대체' 지침의 적용을 제한하고 GNG를 침해해서는 안 된다; 실제로 이러한 구별은 종종 무시된다.하지만 일상적인 운영이란 무엇인가?100은 어디서 왔을까?비틀즈는 네 명이고, 그들은 돌아다니며 노래를 부르지, 안 그래?위키피디아가 200명까지 고용된 것을 보면 놀랍지만 얼마 전까지만 해도 100명 미만이었다.그리고 물론 범죄로 기소되거나 차별 논란으로 유명해진 어떤 회사도 결국 주목을 받게 될 것이다.어떤 규칙이라도 어떤 주제에 대해 말할 수 있는 충분한 출처를 찾아내는 우리의 실제적인 문제를 다루지 않는 것이어야 하기 때문에 그것은 실체가 없는 규칙이다.

@Masem:솔직히, 나는 공신력이라는 '처방'에서 별로 꿈틀거릴 여지가 보이지 않는다.만약 당신이 기사를 쓸 때 가진 모든 것이 회사 웹사이트의 출처라면, 당신은 사람들이 신뢰할 수 있는 기사를 쓰지 않을 것이다.그리고 만약 여러분이 주제를 상세히 기술하는 독립적인 믿을만한 출처를 두 개 가지고 있다면, 비록 그것이 작지만 더 이상의 출처가 나타나지 않더라도, 그 기사를 삭제할 이유가 전혀 없다.Wnt (토크) 11:44, 2015년 7월 25일 (UTC)[응답]

나는 완전히 다른 방향으로 움직이는 것을 지지할 것이다.우리가 특정한 출처를 찾느냐 안 찾느냐 하는 것은 검색의 질과 자원의 이용 가능성의 문제, 그리고 그 주제에 대해 쓰는 출처가 우리가 쉽게 검색하고 인식할 수 있는 출처인지의 문제다.GNG에 기반한 토론은 대개 "신뢰할 수 있는" "실질적인" "독립적인" 용어에 대한 평가로 내려오는데, 이 모든 것은 원하는 결과에 맞게 해석될 수 있다.내가 2007년에 가입했을 때, 그 가이드라인은 여전히 해결되고 있었고, 나와 다른 사람들은 분명히 주목할 만한 주제를 포함시키는 것을 정당화하기 위해 다소 복잡한 주장을 사용할 수 있었다.이것들은 매우 비생산적인 방법이나 논쟁이었고, 결국 그것은 결국 공신력이라는 의미로서 끝나게 되었는데, 그 주장을 사용하는 기술을 가진 사람이 옹호하는 기사였지만, 주제나 출처에 대해서는 아무 것도 아니었다.명성은 위키백과 같은 백과사전에 적합하다는 의미일 뿐이고, 검증가능성이 충족되는 한 정확한 출처의 수와 종류는 큰 차이가 없다.그 문제의 실제적인 중요성은 그렇다.

(이러한 경우, GNG와는 완전히 독립된 공식 지침이 적어도 하나 있다 -- WP:PROF는 GNG를 충족한다는 가정 하에 작용하지 않는다. 다양한 요소들이 그것을 보여주는 것으로 가정하면서, 자신의 주체에서 권위자가 되는 다른 기본 기준에 의해 작용한다.6년 넘게 잘 되어왔는데, 그 주제에 관심이 있는 모든 사람들이 그것을 받아들이고, 그 결과가 우스꽝스럽지 않은 한 아무도 신경 쓰지 않기 때문이다. 그 결과는 우리가 매우 보수적이어서 돌보는 것이다.나는 예를 들어, 그리고 비슷하게 우리가 추정된 공신성의 전체 개념을 없애고 결정하기 쉬운 명확한 기준을 가질 때라고 생각한다.

실제로 우리는 주제별로 주요 용어를 다르게 해석하며, 특별한 공신력 지침은 해석이 특히 어려운 과목에 도움이 된다.서로 다른 주제 사이의 균형은 타협이다.우리들 각자는 그들이 가장 좋아하는 분야에서 비교적 사소한 주제를 받아들이는 다른 사람들과의 교환으로 그들이 전혀 중요하지 않다고 생각하는 어떤 분야에서는 작은 과목에 대해 훨씬 더 큰 호감도를 받아들이며, 따라서 우리는 대략적인 균형을 이룬다.그 균형은 현재 스포츠와 대중음악과 지리적 특징으로 다소 왜곡되어 있지만, 이것은 특별한 해를 끼치지 않는다.

기본적인 질문은 우리가 기사를 쓰고 개선할 것인가, 아니면 어떤 기사를 써야 할 것인가 하는 것이다.그게 진짜 포인트야.나는 오히려 AfD를 잘하는데, 만약 우리가 어떤 규칙들에 의존한다면 나는 WP가 나의 관심사를 훨씬 더 가깝게 반영하도록 할 수 있을 것이라고 생각한다.나는 내가 그때 사용했던 몇몇 주장들의 예를 들어주고 싶은 유혹을 느끼지만, 나는 단지 하나를 말할 것이다.나는 연기자에 대해 쓰여진 모든 뉴스 기사는 궁극적으로 그들의 보도 담당자의 산물이며(사실, 기업 M, 당신은 나에게 그 주장을 약간 다른 맥락에서 가르쳐 주었다), 따라서 독립적이지 않으며, 우리는 전면적으로 출판된 고급 학문이 있는 사람들에 한정해야 한다고 주장할 준비가 되어 있을 것이다.질 좋은 전기 또는 비평 전보생각해봐, 우리는 99%의 레슬링 선수와 포르노 스타들을 제거할 수 있어!그러나 여기서 해야 할 중요한 일들이 나중에 논쟁하는 것보다 더 많다.WP에는 합의만큼이나 중요한 원칙이 있는데, 어떻게 보면, 다시 정리하는 것, 즉 타협이라는 원칙이 있다. DGG (토크 ) 03:11, 2015년 7월 28일 (UTC)[응답]

나는 기본적인 질문이 꽤 다르다고 생각한다. DGG: 나는 기본적인 질문은 "우리가 WP를 준수할 수 없다고 합리적으로 확신하는 BLP에 대한 백과사전 기사를 갖고 싶은가:NOR과 WP:V?" NOR는 "신뢰할 수 있는, 공개된 이차 출처를 기반으로 한다"고 규정하고 있으며, 그러한 출처가 존재하지 않는다면, 그 핵심 정책을 준수하는 것은 절대 불가능하다.WP:V는 편집자들에게 "사실 확인과 정확성에 대한 평판을 가진 신뢰할 수 있는 제3자 출판된 출처에 대한 기사를 작성하라"고 요구한다.만약 그러한 출처가 존재하지 않는다면, 그 핵심 콘텐츠 정책을 준수하는 것은 절대 불가능하다.

우리는 핵심 정책의 이런 측면들이 중요하지 않다고 결정할 수도 있지만, 만약 그렇다면, 우리는 그렇게 말해야 한다.WhatamIdoing (대화) 17:41, 2015년 7월 28일 (UTC)[응답]

위에서 말했듯이, WP:V 없이는 우리는 백과사전이 아니며, 내가 종종 말했듯이, 그것은 NPOV에도 적용된다.하지만 바이오 기사가 이용할 수 있는 검증된 정보를 보도한다면, 그리고 그것이 중요한 것을 만드는 것이라면, 무엇이 문제일까?예를 들어, 초기 올림픽 선수.우리는 그들의 이름과 나라, 그리고 그들이 겨룬 행사 이외에는 아무것도 알지 못할 것이다.그것은 WP:V와 WP:NPOV를 만난다.그것은 GNG를 충족시키지 못하기 때문에, 우리는 현재 우리가 그들을 확인할 수만 있다면 분명히 출처가 있을 것이라는 회피로 그것을 처리하고 있다. (그리고 나는 이에 동의한다.)다른 방향의 예로는, 한 학부 대학의 조교수가 있다.우리는 그의 학위와 입장을 알고 있다. 왜냐하면 그들은 대학 웹사이트에 보고되고 있기 때문이다. 그것은 제3자를 요구하는 예외의 하나와 같은 일상적인 데이터에 대한 RS이다.대부분의 경우 우리는 신뢰할 수 있고 완전히 독립적인 제3자 소스인 월드캣에서 그의 논문의 제목과 날짜까지 찾을 수 있다.그것은 사회적 중요성이 어느 정도 있는 직책이다.그러나 WP 때문에 우리는 기사를 만들지 않는다.PROF 제한사항: PROF는 그가 자신의 분야에서 전문가라는 것을 보여주지 않는다. (그리고 그는 WP:GNG를 만난 적이 없다.)자, 이 대학이 그가 받는 대학 내 교수상에 대한 보도 자료를 발행하고, 마을 신문과 그의 고향 신문이 이를 보도한다고 가정해 보자.이것은 두 개의 RS로 보일 수 있지만, 우리는 여전히 그 두 개의 뉴스 출처가 지역민들에게 그러한 문제에 대해 불충분한 차별을 하고 있다는 논리로 기사를 만들지 않는다.(그리고 나는 이에 동의한다) 자, 이제 읍사무소에 출마하는 지역 정치인을 데리고 갑시다.그는 인터뷰에서, 좋은 국내 뉴스 소식통이 그것을 보도할 정도로, 매우 어리석은 말을 한다.이것은 GNG를 충족하지만 이를 피하기 위해 ONEEVENT의 BLP 기준을 사용한다.우리는 V와 NPOV를 가지고 있다는 사실과는 상관없이 그렇게 한다. (그리고 나는 이에 동의한다.)5년 후, 그가 그와 같은 연설을 한다고 가정해보자.현재의 규칙에 따르면, 그는 기사를 얻어야 한다; 실제로, 우리는 기사를 보관하지 않을 것이다. 왜냐하면 AfD는 그것에 반대할 어떤 구실을 찾을 것이기 때문이다. (그리고 나도 그것에 동의한다.)때때로 AfD는 그것을 보관할 것이고, 나는 그것에 동의하지 않는다-- 그것이 너무 두드러져서 사람들이 엔사이코피디아에서 그것을 합리적으로 찾을 수 없다면)예상하기로는, 그것은 순전히 부정적인 정보에 대한 배제에 해당하지 않을 것이다. 왜냐하면 그것은 정의상 공적인 정치인들에게는 해당되지 않기 때문이다.자, 내가 현재의 관행에 완전히 동의하지 않는 예를 들어보자.한 소국으로부터 다른 소국까지 대사를 고려하라.그의 경력 상위에 있는 공적인 지위고, 우리는 RS 공식 소식통을 통해 그것을 증명할 수 있다.대사로서의 NPOV 문제도 없고, WP:V에도 문제가 없다.우리는 기사를 만들지 않는다. 왜?그것은 충분히 중요하지 않다는 것이 의견 일치를 보았다.확실히, 그의 초기 경력과 임명에 대한 고국의 뉴스 보도는 있을 것 같지만, 우리는 보통 그것을 찾을 수 없다.만약 가능하다면, 우리는 여전히 ONEEVENT에서 약속을 말하면서 기사 작성을 피할 수 있을 것이다.신기하게도 그가 지방의회에 당선된 대사 대신 우리가 기사를 만들었을 겁니다.나는 그런 예를 무한정 계속할 수 있었다. DGG (토크 ) 23:57, 2015년 7월 28일 (UTC)[응답]

주제가 전반적으로 너무 중요하지 않아서 그 주제에 대해 독립적인 신뢰할 수 있는 출처가 없는 경우, 어떻게 "중요한 것을 위한 것"이라는 것을 증명할 수 있는가?이름/국가/이벤트 외에 알려진 것이 없는 올림픽 선수들은 어떤 것이 실제로 알려질 때까지 리스트로 통합되어야 한다.

또한, 나는 책에 대한 도서관 기록이 "독립적으로 신뢰할 수 있는 출처"를 구성하는 것이 아니라고 생각한다; 그것들은 본질적으로 책 자체로부터 직접 복사된 것이다.만약 당신이 당신의 이름을 DGG라고 말하고, 당신의 이름을 DGG라고 말했다면, 그 정보는 단지 내가 당신이 쓴 것을 패러디했다고 해서 더 신뢰할 수 없게 된다.책을 출판하면 그 책은 제목에 대한 독립적인 제3자의 신뢰할 수 있는 출처가 아니며(절대 권위적이기는 하지만), 아마존 페이지도 아니다.아마존 페이지보다 (평균적으로) 훨씬 적은 정보를 포함하고 있는 라이브러리 데이터베이스는 공신력 목적으로는 다소 더 가치가 있지 않다.

한 가지 더 질문:찾을 수 있는 출처의 100%가 피험자에 의해 직간접적으로 통제되는 경우(예: 피험자 자신의 글, 피험자 자신의 웹사이트, 피험자 자신의 웹사이트, 피험자의 글) NPOV를 준수하는 기사, 특히 피험자 자체의 관점을 지나치게 강조하지 못하도록 하는 부분을 작성하는 것이 가능하다고 생각하십니까?사용자 웹 사이트)?중립적으로 들리는 어조를 얻을 수 있을 만큼 쉽겠지만, 찾을 수 있는 모든 출처가 앨리스 자신으로부터 온 것이라면, 앨리스에 대한 다른 사람들의 견해를 공정하게 대변하는 앨리스 전문가에 대한 기사를 쓸 수 있는가?WhatamIdoing (talk) 00:47, 2015년 7월 31일 (UTC)[응답]

아마존의 특정한 경우, 그들은 다른 판의 메타데이터를 가진 한 판을 참조하거나, 혹은 서지학 데이터를 완전히 잘못 얻는 부주의한 오류로 악명 높다.(예를 들어, 페이지 카운트는 최근 책의 경우 가장 가까운 2의 파워로 반올림된다.)작가들과 삽화가들은 때때로 혼란스러워 한다.esp 부제목인 제목이 틀린 경우가 많다.)책이 팔리는 한, 그들은 상관하지 않는다.내가 ISFDB에서 일할 때, OCLC 인용은 아마존 인용보다 훨씬 더 선호되었다.그러한 인용은 기본적으로 WP:일차적인.OCLC의 한 인용구는 "사서가 이 책의 복사본을 취급했고, 그것이 존재한다고 말하고, 페이지들이 아주 많으며, 저작권 페이지 (그리고 때로는 표지나 뒷표지와 같은 다른 페이지들)에 그와 같은 자료를 명시하고 있다"고 말한다.또한 한 도서관이 그들의 시간과 돈을 들여서 목록을 작성하는 것이 가치가 있다고 생각했고, 어떤 경우에는 많은 도서관이 그렇게 했다는 것을 보여준다.그것은 가치가 있다.DES^(talk) 11:58, 2015년 7월 31일 (UTC)[응답하라]

아니면 누군가가 그것을 기부했다는 것.적어도 내가 사는 지역 시스템에서는 사람들이 헌 책을 하루 종일 반납함에 버린다.우리는 매주 해고될 것으로 기대할 수 있다.어떤 사람들은 던져지고, 어떤 사람들은 팔리고, 어떤 사람들은 컬렉션에 추가된다. (현지 작가나 아이들을 위해 쓴 거의 모든 것)

나는 "일부 도서관이 이 책을 소장하기로 결정했다"는 것이 우리가 저자에 대한 기사를 가져야 한다는 신호를 보낸다는 것을 납득할 수 없다.만약 그렇다면, 우리는 펄프 로맨스 작가들에 대한 더 많은 기사를 받아들일 것이다.WhatamIdoing (대화) 18:06, 2015년 7월 31일 (UTC)[응답하라]

그 점에 대해서는 WhatamIdoing과 의견이 일치한다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 22 ҅_ᴥ 22^ʌ 22:49, 2015년 8월 3일 (UTC)[응답]

OP로 돌아가기: 일부 주제적인 "가이드라인"(대개 WP:PROJPAGE)는 WP와 상충된다.GNG, 그 다음 GNG가 승리하고, 충돌하는 페이지를 편집하여 WP를 위반하지 않도록 해야 한다.로컬 컨센서스 정책.단지 WP에 속한다고 해서 비고지적인 주제를 포함하는 마법의 탈출 조항은 있을 수 없다.특정 주제 영역의 영역을 소유하십시오.주제 공신성 기준의 유일한 목적은 편집자들이 GNG 분석에서 살아남을 가능성이 있는 주제와 방법을 식별하도록 돕는 것이다. GNG를 회피하기 위한 것이 아니다. WP에 다음과 같은 문구를 추가해야 한다.다른 공신력 페이지보다 우선한다는 공신력 리드. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 22 ҅_ᴥ 22^ʌ 22:49, 2015년 8월 3일 (UTC)[응답]

A급 기사의 오른쪽 상단 모서리에 있는 아이콘

간단한 제안: 파일 추가:A-Class 리뷰를 통과한 모든 기사의 오른쪽 상단 모서리에 GA 및 FA 아이콘과 동일한 위치에서 class.svg 아이콘을 기호화하십시오.현재 대부분의 A클래스 기사는 페이지 오른쪽 상단 모서리에 GA 아이콘이 표시되어 있지만, 일반적으로 A클래스 기준은 GA 기준보다 엄격하다.대신 A 클래스 아이콘을 표시하면 이러한 기사를 다른 GA/FA 기사와 차별화하는 데 도움이 될 것이다.소버린 센티넬 (대화) 2015년 7월 21일 11시 17분 (UTC)[응답]

어쩌면 거꾸로 뒤집힌 별보다는 다이아몬드 모양의 아이콘일까?찬양(대화) 15:13, 2015년 7월 21일 (UTC)[응답]

거꾸로 뒤집기 보다는 90도 회전이라고 생각한다.WhatamIdoing (대화) 17:43, 2015년 7월 21일 (UTC)[응답]

나는 이 변화에 반대할 것이다.A-클래스는 프로젝트별로 다르지만 GA/FA는 그렇지 않다.A클래스가 항상 GA 기준보다 '엄격한' 것은 아니라는 뜻이고, A클래스를 완전히 없앤 프로젝트를 적어도 하나쯤은 생각할 수 있다. --Izno (토크) 18:32, 2015년 7월 21일 (UTC)[응답]

나는 많은 위키프로젝트들이 A클래스를 폐지했다는 것을 잘 알고 있다.내 제안을 분명히 해야 할 것 같다: 만약 위키프로젝트가 기사를 A등급으로 평가했다면, A등급 아이콘은 기사 페이지의 오른쪽 상단 모서리에 표시되어야 한다.소버린 센티넬 (대화) 03:31, 2015년 7월 22일 (UTC)[응답]

• 반대: 이즈노에 따라서.이 아이디어는 엄청나게 중복되어 보인다. --78.149.112.112 (대화) 18:54, 2015년 7월 21일 (UTC)[응답하라]
  • 당신은 IP를 사용하는 등록자 입니까?왜 이게 첫 번째 편집이야?더스틴 (대화) 03:34, 2015년 7월 22일 (UTC)[응답]

@Dustin V. S.: IP 사용자는 누구 못지않게 이 토론에 참여할 수 있다.많은 IP는 사용자가 인식하지 않아도 규칙적으로 변화하는 동적 IP이기 때문에 합법적인 사용자 한 명이 수십 개 또는 수백 개의 주소 아래에서 수천 개의 편집을 할 수 있다.그들의 논평과 기여는 나나 당신 것만큼 유효하며, 그런 식으로 그들을 공격적으로 심문하는 것은 당신에게 좋지 않다.

나는 이것이 나쁜 생각이라고 생각하지 않는다.A급과 굿 기사가 베터인지, 아니면 서로보다 못한지 차이가 있으니 유의해야 한다.Eman235/토크 19:12, 2015년 7월 21일 (UTC)[응답]

적어도 A급 아이콘을 자발적으로 볼 수 있는 옵션이 있어야 한다고 생각한다.더스틴(토크) 03:35, 2015년 7월 22일 (UTC)[응답]

기사 제목을 평가된 최고 품질에 따라 색칠하는 대본/가젯이 있다.각 기사에 대한 페이지 헤더의 일부로 기사 품질 평가 표시를 참조하십시오.특수:의 가젯 탭에 있는 "부재" 아래에 있는 확인란선호도. --Izno (대화) 03:41, 2015년 7월 22일 (UTC)[응답]

그건 나도 잘 알고 있고, 까다롭게 굴지 말고, 아이콘으로 표시하면 좋을 것 같아.이 일이 어떻게 되든 간에, 나는 단지 A급 아이콘을 원한다.더스틴 (대화) 03:44, 2015년 7월 22일 (UTC)[응답]

• 반대 – A 클래스에 대한 통일된 표준이 없으므로 아이콘을 갖는 것은 큰 의미가 없다.기준에 따라 쓰레기를 버리는 죽은 프로젝트는 기사를 A등급으로 분류할 수 있다.왜 우상이 있어야 하지?우리는 어쨋든 독자들에게 도움이 되지 않는 칭찬이나 화려한 버튼은 더 이상 필요하지 않다.만약 통일된 "A-class" 기준이 있다면, 아마도 아이콘은 무언가를 의미할 것이다.그렇지 않으면 절대 안 된다.RG루스터 — ▷인터뷰 03:46, 2015년 7월 22일 (UTC)[응답]
  • 이 문제를 피하는 한 가지 방법은 이러한 조항도 GA 심사를 통과하도록 요구하는 것이다.즉, 기사가 A-클래스 리뷰를 통과하지만 GA는 통과하지 못하면 아이콘이 표시되지 않는다. 소버린도센티넬 10:34, 2015년 7월 22일 (UTC)[응답]

또 다른, 더 쉬운 해결책은 독자들에게 아무런 가치도 주지 않기 때문에 이것을 하지 않는 것이다.비블브록스 (대화) 20:53, 2015년 7월 23일 (UTC)[응답]

다른 한 층의 리뷰를 추가하는 것은 편집자들에게 더 많은 문제를 의미할 수 있지만, 도대체 어떻게 "독자들을 위해 가치 있는 것을 더하지" 않을 수 있을까?그것은 단순히 사실이 아니다.더스틴(토크) 2015년 7월 23일 21:00 (UTC)[응답]

좋은 글과 특집 기사 아이콘은 독자들에게 기사가 표준화된 리뷰 과정을 거쳤으며 공정한 리뷰어가 그것이 우리의 최고 콘텐츠 중 하나라는 것을 알게 해준다.이것은 독자들에게 내가 혹은 괜찮은 기준과 리뷰를 가지고 있지 않을 수도 있는 프로젝트의 어떤 무작위적인 사람이 기사를 A반이라고 결정했다는 것을 알게 해줄 것이다.그것은 아무런 가치도 더하지 않고, 단지 대화 페이지에 남겨두는 것이 더 나을 뿐이다.비블브록스 (대화) 21:33, 2015년 7월 23일 (UTC)[응답]

• RGloucher 당 반대한다.FA 등급 및 GA 등급 기사에 대한 현장 전반의 표준 안전 점검 프로세스가 있으며, A 등급에는 그러한 프로세스가 없다.상당히 문자 그대로, 나는 위키피디아에 관한 어떤 기사에도 가서 A급 기사로 태그할 수 있었는데, 심지어 A급 기준이 없는 프로젝트나 존재하지 않는 프로젝트라는 미명하에까지 자각할 수 있었다.이반벡터 🍁 (대화)20:56, 2015년 7월 23일 (UTC)[응답]
• 반대하라, 위의 모든 사람들 중에서.A클래스(그리고 B&C클래스, 그러고 보니)는 WMF가 위키피디아의 인쇄판과 CD-ROM 버전을 계획하고 있던 초기의 유물로, 어떤 기사가 컷을 만들기에 적절한 표준의 기사인지 판단할 수 있는 방법이 필요했고, 일반적으로 유용한 목적을 제공하지 못한다.(가장 두드러지게 밀히스트라는 극소수의 프로젝트들은 그것을 내부 품질 관리 메커니즘으로 사용하지만, 각각의 프로젝트들은 각각의 기준을 정하고 있다; Ivanvector의 말처럼, 내가 위키프로젝트 레터 W를 만드는 것을 막을 수 있는 것은 말 그대로 아무것도 없다, 내 프로젝트의 A급 기준을 "첫마디가 W를 포함하고 있다"라고 정의하고, 그리고 tagg언급된 기준을 충족하는 모든 기사를 A등급으로 한다.– 무지개빛 21:02, 2015년 7월 23일 (UTC)[응답]
• A클래스에 대한 일관된 기준이 없기 때문에 반대한다.이론적으로 A 클래스는 WP가 요구하는 변경사항을 되돌리기 위해 편집자가 사용할 수 있다.GAN 및 일부 WP로 돌아가십시오.WP에 적합한 우측버전:LOCALConsensus는 나중에 WP에서 GA 클래스를 빼앗겼더라도 A 클래스(즉, "GA보다 낫다")로 라벨을 붙인다.GAR. 실제로 내가 알 수 있는 바로는 A 클래스는 "FA 준비" 과정으로서 3명의 위키백과 주체가 사용하는 검토 과정일 뿐이지만, A 클래스를 구성하는 것에 대한 내부 기준은 위키백과 주체가 일치하지 않는다.이 페이지나 아마도 WP:VPOL에서 A 클래스를 완전히 삭제하자는 제안이 하나 더 있을 것이다.B 등급과 C 등급은 괜찮다. 사이트 전체에 걸쳐 일관된 기준을 가지고 있으며, 위키백과 대상 배너 메타템플릿은 기사가 통과한 B 등급의 이정표를 나타내는 개별 매개변수를 지원한다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ^ʌ ҅ ҅_ᴥ ≼ ≼ 19:44, 2015년 7월 26일 (UTC)[응답]
• 지원: 특정 프로젝트에서 A급 기사를 아이콘으로 표시하는 승인을 받을 수 있는가?에덴 북쪽 (대화) 03:25, 2015년 7월 29일 (UTC)[응답하라]
  • 아, 그럼 다른 위키백과 과목이 2등급 위키백과 과목이 되는 거야? — SMc캔들리쉬 lish ¢ ≽^ʌ ≽_ᴥ 22 22 22 22^ʌ 22:53, 2015년 8월 3일 (UTC)[응답]

제안:위키피디아의 사내 광고(Gonotices) 선택

위키피디아에는 현재 광고가 있다.그들은 자신의 감시자 페이지에 나타난다.현재 진행 중인 광고에는 "웨스트버지니아 대학 도서관이 위키피디아인을 레지던스에서 고용하고 있다"와 "2015년 7월과 8월에 열리는 그레이트 아메리칸 위키미팅 행사에 참가하여 당신의 도시를 추가하라"는 내용이 포함되어 있다.최근 몇 달 동안 그 광고의 부피가 크게 증가했다.그런 광고에서 손을 뗄 수 있는 확실한 것은 없다.적어도 옵트 아웃은 있어야 한다.나는 더 멀리 가기를 권하고 싶다; 그것들은 선택되어야 한다, 아니면 아예 존재하지 말아야 한다.

(그래, 그것들은 광고야."광고는 보통 상업적 제의나 정치적 또는 이념적 지지와 관련하여 청중들이 어떤 행동을 취하거나 계속하도록 설득하기 위해 사용되는 마케팅 커뮤니케이션의 한 형태다."광고를 참조하십시오.)존 나글(토크) 19:34, 2015년 7월 10일 (UTC)[응답]

"Gadgets -> Watchlist -> Watchlist -> 당신의 지역 이벤트에 대한 당신의 감시 목록에 공지 표시" 섹션에서 당신의 선호에 따라 감시 목록 페이지의 Gunotice를 비활성화할 수 있다.나콘 20:14, 2015년 7월 10일 (UTC)[응답]

나는 그들 모두가 우리 지역의 행사에 특정되어 있는지 확신할 수 없다.예를 들어, 나는 미국 인디애나에 있어.그럼에도 불구하고 나는 여전히 웨스트 비르기나 대학교에 대한 것을 얻었다; 나는 유럽에서의 파노라마의 자유에 대한 배너를 얻었다; 위키피디컬은 모든 장소를 위한 것이고, 위키리브리얼은 모든 장소를 위한 것이다.

그렇기는 하지만, 그들은 "숨기기" 또는 "디스미스"라고 쓰여 있는 단추를 클릭함으로써 숨거나 치울 수 있다.한 번만 보면 돼.~ ONUnicorn^{(Talk Contribs)} 문제 해결 20:33, 2015년 7월 10일 (UTC)[응답]

WVU 1의 위치는 "미국"으로 정의되어 있으며, 따라서 미국 전체에게 제시되고 있다.로컬 항목의 전체 목록은 MediaWiki:가젯-gonotice-list.js.나콘 20:37, 2015년 7월 10일 (UTC)[응답]

WVU 광고는 최악이다.너무 많은 분포를 가진 말이 많은 구인 광고다."Just hit delete"는 전형적인 스팸 발송자 논쟁이다.[2]존 나글 (대화) 08:12, 2015년 7월 13일 (UTC)[응답]

오늘 나는 "위키피디아 도서관과 위키 교육 재단이 5개의 새로운 방문 학자 직책을 발표한다"를 얻었다.왜 Genotice가 꺼진 상태에서 이걸 받는 거지?나는 이제 "중앙통보"도 껐다.선호 옵션이 적용되기 전에 지연이 있는가, 아니면 실제로 효과가 없는가?존 나글 (대화) 2015년 7월 15일 21:15 (UTC)[응답]

관련 제안

나는 때때로 "애드"가 짜증나게 할 수 있다는 것에 동의하지만, 가끔 흥미로워 할 수도 있기 때문에, 나는 그들을 한 번만 보고 싶다.한 번에 30일 동안 로그인하지 않기 때문에(닫을 때 쿠키를 지우도록 설정된 브라우저 설정, 개인 정보 보호/보안) WP에 로그인하여 내 감시 목록을 확인할 때마다 알림을 본다.'숨기기'는 로그인한 상태에서 알림만 제거하기 때문에 다음에 다시 로그인할 때 같은 알림만 자주 보게 된다.때때로, 같은 통지가 몇 주 동안 나타난다.리스트를 보고 새로운 리스트가 있는지 판단하는 것은 사소한 귀찮은 일이다.

제안 1: 클릭했을 때 "숨기기" 버튼은 사용자가 다음에 로그인할 때 알림이 나타나지 않도록 영구히 숨겨야 한다.제안 2: 통지를 보고 싶지만, 감시 목록을 볼 때마다 텍스트 벽을 볼 수 없는 사용자에게, 완전히 확장되지 않는 접을 수 있는 목록에 통지를 배치할 수 있는 옵션(선호 설정>감시 목록)을 만들 것을 제안한다.

"공지사항"보다 더 나은 문구가 필요하고 어떤 구현도 더 잘 보일 필요가 있을 것이다.접을 수 있는 목록은 단지 예시를 위한 것이다.사용자는 여전히 제안 2가 포함된 통지를 영구히 숨길 수 있으며, 중앙 통지만 표시하도록 환경설정을 변경할 수 있다.나는 제안 하나를 강력히 지지한다.나는 중립적으로 2를 제안한다. 그것은 단지 내 마음에 떠오른 것이고 그것은 논의할 가치가 있는 것이다.AHeneen (대화) 07:49, 2015년 7월 23일 (UTC)[응답]

이상하게도, 나는 이것을 사용할 수 있고 미국의 한 사이트에서 감시 목록을 클릭했을 때 어떤 알림도 보지 못했다.WP:조노티스는 웨스트버지니아주 입주를 열거하지 않는다.이 컨텐츠에 액세스할 수 있는 다른 방법이 있는가?Wnt (토크) 11:51, 2015년 7월 25일 (UTC)[응답]

광고 및 프로모션 배치를 제안한다: http://i.imgur.com/KXAGJgZ.jpgSyberiyxx (토크) 06:10, 2015년 7월 29일 (UTC)[응답]

그래, 그래야 좀 더 간결해질 거야. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ 22 22 22^ʌ 22:_ᴥ55, 2015년 8월 3일 (UTC)[응답]

WP에 "Something of Person" vs "Person" 추가:매년 제안

당사자가 당사자와 관련된 사건만큼 눈에 띄지 않는 직함만 표준으로 삼자는 제안이 끊이지 않는다.위키백과 대화:기사 제목#"존도의 죽음", "존도의 총격", "존도의 살인" vs "존도의 죽음"; "존도의 죽음"; "존도"의 이동 요청이 있었다.철수하기 전에 산드라 블랜드의 죽음이것이 실패하면 그 페이지에 추가할까? --George Ho (토크) 08:25, 2015년 8월 6일 (UTC)[응답]

템플릿:인포박스 person Ⅱ

나는 위키다타와 사용자 데이터 인포박스를 나란히 보고 비교하기 위해 이 템플릿을 만들었다.소스 편집기에서 미리 보는 동안 이중 인포박스를 표시하며, VisualEditor에는 영향을 주지 않으며, 기사 내에 저장되어 있으면 전혀 해를 입지 않는다.WD hidden infobox 사용자 템플릿과 함께 업데이트만 유지하십시오.여기서 체크아웃하십시오.모든 Infobox 사용자 템플릿 이름 끝에 "i"를 추가하여 모든 문서에서 사용할 수 있다.즐기세요.··마노스해커 13:51, 2015년 7월 22일 (UTC)[응답]

@Frietjes and Plasticikspork: -- Magioladis (대화) 16:25, 2015년 7월 22일 (UTC)[응답]

이것이 필요하다면, 그것은 유지되어야 하는 또 다른 프런트엔드를 만들기 보다는 템플릿:infobox person과 병합되어야 한다.@Stradivarius와 Jackmcbarn:프리테제스 (대화) 2015년 7월 22일 (UTC) 16:36[응답]

그래, 이건 미리보기 모드에서 사용할 수 있는 진짜 템플릿의 기능일 뿐이야. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 16^ʌ ҅_ᴥ ҅ 16:47, 2015년 7월 22일 (UTC)[응답]

동의해. -- 마골라디염 (대화) 16:55, 2015년 7월 22일 (UTC)[응답하라]

그것은 가능성을 보여주고 오류 확인을 허용하기 위해 별도로 만들어졌다.나는 또한 진짜 템플릿 내의 병합에 동의한다.···마노스해커 23:59, 2015년 7월 22일 (UTC)[응답]

알았어그게 도움이 된다는 것에 동의해. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ҅ ≼ ≼ ≼ 19:47, 2015년 7월 26일 (UTC)[응답]

수정/추가 작업을 위해 wikidata 항목과 연결할 수 있는 것도 유용할 것이다.···마노스해커 00:23, 2015년 7월 23일 (UTC)[응답]

마노스해커 나는 영어 위키백과에서 아직 그 대규모의 위키다타로부터 정보를 얻을 준비가 되어 있지 않다는 것이 문제라고 생각한다. -- 매기올라딘염 (대화) 12:29, 2015년 7월 23일 (UTC)[응답]

위키다타에서 기사로 수입할 근거나 요청은 없다.이것은 위키백과나 위키다타 중 어느 쪽이든 실수를 바로잡고 업데이트하는 데 도움을 주기 위해 미리 보는 동안 자동 데이터와 수동 데이터를 나란히 비교하는 도구다.기사 자체에는 영향을 미치지 않고, 소스 편집자의 미리보기에만 영향을 미친다.···마노스해커 13:08, 2015년 7월 23일 (UTC)[응답]

이제 템플릿이 병합되어 Infobox 사용자를 ii 버전으로 교체할 수 있음

현재는 인포박스 사람과 합병되어 매력적으로 작용하고 있다. 변경 중에 Infobox 개인과 Infobox 개인 ii를 모두 업데이트할 필요 없음. 고급 사용자들을 위한 옵션으로 그것을 구현할 것을 제안한다.···마노스해커 13:42, 2015년 7월 23일 (UTC)[응답]

그것은 루프 테스트를 통과하지 못하기 때문에 사용할 수 있지만 하나의 템플릿으로 병합되지는 않는다.병합에는 항상 두 개의 외부 자식 템플릿이 필요하며 템플릿 업데이트는 항상 트리플(tripple)이 된다.···마노스해커 16:44, 2015년 7월 23일 (UTC)[응답]

그건 좀 전보였어.그렇다면 제안된 해결책이 있는가? — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ҅ ≼ ≼ ≼ 19:47, 2015년 7월 26일 (UTC)[응답]

업데이트

Infobox person Ⅱ 안에 WD 숨겨진 Infobox person을 성공적으로 병합했다.···마노스해커 15:12, 2015년 7월 30일 (UTC)[응답]

제안:이전 템플릿을 새 템플릿에 중첩하고 이 기능을 선택 사항으로 설정하며 사전 선택되지 않음

목적

Wikidata 항목으로 자동으로 채워지는 미러 인포박스에 수동으로 채워진 인포박스 미리 보기

대상

양쪽의 데이터를 쉽게 비교 및 업데이트

특징

Wikidata infobox는 소스 편집기 미리보기 중에만 표시되고 아티클 뷰에서 사라짐, 이전 아티클 버전 뷰, VisualEditor

불편

두 템플릿을 모두 동기화해야 하지만 매우 간단한 프로세스와 새 템플릿이 매우 깨끗해야 함

단계(기술)

1. 템플릿 intermate Infobox person i 대신 Infobox person i로 전화하십시오.
2. 템플릿 이동:인포박스 사용자를 템플릿으로:리디렉션되지 않은 Infobox 개인 i
3. 템플릿 이동:Infobox person Ⅱ to Template:리디렉션되지 않은 Infobox 사용자
4. Infobox 사용자 사용 도움말에 Infobox person i에 대한 링크를 추가하여 두 템플릿을 쉽게 동기화

미래

Wikidata 편집/업데이트에 연결하도록 Wikidata 템플릿 향상(값 팝업 또는 Wikidata 페이지 링크 편집)

• 지원 ··마노스해커 18:59, 2015년 7월 27일 (UTC)[응답]
• 이것이 어떤 식으로든 선택되지 않는 한 강력히 반대한다.p[검토 모드]에서 인포박스로의 변경을 검토할 때, 내가 신뢰하지 않고 기사에 사용되지 않을 데이터로 가득 찬 제2의 인포박스로 어수선해지는 것을 원치 않는다.더 중요한 것은 wikidata(대부분 아웃 에디터)에 대해 들어본 적이 없는 편집자가 미리보기 모드를 사용할 때, 실제 기사 화면과 상당히 다르게 의도적으로 만들어진 미리보기를 보지 말아야 한다는 점이다.미리 보기는 편집 후 기사가 어떤 모습일지 미리 보기 위한 것이다.이러한 디스플레이를 명시적으로 원하는 편집자만이 설정하며 미래의 편집자를 혼동할 수 없는 일부 설정이나 파라미터에 대한 대응을 제외하고 편집 후 표시되지 않을 데이터를 표시하는 것은 미리보기 남용이다.DES 16:26, 2015년 7월 30일 (UTC)[응답하라]
• 반대 DES 반대는 근거가 충분하다.WP는 wikidata가 필요로 하는 모든 분야를 추가해야 한다.현재의 Infobox에 대한 합의.만약 그것이 이루어질 수 없다면 아마도 개인 데이터가 더 이상 사용되지 않았어야 했다.마넷D톡 19:38, 2015년 7월 30일 (UTC)[응답]

시행될 경우 선택 사항일 것이며 사전 선택되지 않을 것이라는 것은 의심할 여지가 없다.그것은 사람들을 혼란스럽게 하는 것이 아니라 오류를 확인하는 것을 돕기 위해 만들어졌다.그것을 선택적으로 만드는 것은 내가 현재 알고 있는 것 이상으로, 경험 많은 사용자가 이 문제에 대해 우리를 도울 수 있을 것이다.···마노스해커 21:06, 2015년 7월 30일 (UTC)[응답]

템플릿의 정상적인 사용에 과도한 부담을 주지 않는 한, 시험을 위한 엄밀히 선택 가능한 기능에는 이의가 없다.그러나 이러한 선택적 버전이 샌드박스로 만들어지기 전에 이 제안은 정말 논의할 준비가 되어 있는가?만약 우리가 원칙적인 기준으로 논의한다면, 나는 이것을 사용할 것이라고 기대하지 않을 것이다. 하지만 만약 그것이 디폴트가 아니라 선택 사항이고, 매우 빈번한 템플릿의 정상적인 사용에 상당한 비용을 부과하지 않는다면 반대하지 않을 것이다.위의 논의는 이것이 항상 켜져 있거나, 기본적으로 켜져 있을 것임을 암시하는 것으로 들렸다.DES^(talk) 21:28, 2015년 7월 30일 (UTC)[응답하라]

그리스어 위키백과에서 위키다타는 자동으로 인포박스를 채우며 손으로 인포박스 항목을 채우는 것만으로 오버리디할 수 있다.결과는 혼합된 infobox 렌더로 사람들은 혼란스러워한다. wikidata 값이 다른 색으로 렌더링되거나 아이콘 (-)이 사용되지 않는 한.나는 거기에 기본적으로 듀얼 인포박스를 사용할 것이다.영어 위키피디아는 다른 접근방식을 가지고 있으며 이중 인포박스는 여기서 선택적으로 유지되어야 한다.···마노스해커 22:40, 2015년 7월 30일 (UTC)[응답]

직접적으로 잘 작동하는 것 같지만, 이 템플릿들 또한 그것을 부르고 우리는 거기서도 그것을 확인해야 할 것이다.일부 전문가는 시스템에 부담이 되는지 확인하기 위해 테스트를 실행할 수 있으며, 위키디타를 가져오는 것은 사용 가능 여부를 선택하는 사람들과 미리 보기 중에만 해당될 수 있다.···마노스해커 22:32, 2015년 7월 30일 (UTC)[응답]

• 지원, 세부 사항 중 악마는 제외한다.이와 같은 선택적 도구가 유용할 것이다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 22 22 22^ʌ 22:_ᴥ51, 2015년 8월 3일 (UTC)[응답]

템플릿이 다른 템플릿 내에서 중첩되어 작동하는지 확인하기 위해 확인이 완료되었으며 제대로 작동하는지 확인하십시오.템플릿:Infobox artist Ⅱ가 생성되는데, 여기서 Infobox person Ⅱ를 부른다.미리보기: Caravaggio, 생년월일을 수정해야 한다는 것을 밝힌다.···마노스해커 09:50, 2015년 8월 6일 (UTC)[응답]

의견 요청: 확인된 사용자를 자동 변환하도록 내용 변환기 제한

토론 후에 나는 mw:주제:Smcw9jyo5p274lwk 지금 콘텐츠 번역기에는 다음과 같은 제한이 있다.

• "베타" 섹션에서 내용 변환을 활성화한 로그인한 사용자만 도구에 액세스할 수 있다.콘텐츠 번역은 베타 기능으로 제공되어 사용자들이 선택, 도구를 사용해 보고 우리에게 다른 사용자의 경험에 영향을 주지 않고 도구를 개선할 수 있는 피드백을 제공한다.베타 기능 플랫폼의 한계로 인해, 로그인한 사용자만 베타 기능에 액세스할 수 있다(익명 사용자에게 베타 기능을 노출하기 위한 티켓이 있지만, 내가 아는 한 여기에서는 해당 영역에서 활동하지 않는다).
• 대상 위키에서 차단된 사용자는 번역이 금지된다.콘텐츠 번역은 게시용 대상 위키(오용 필터, 차단된 사용자 등)의 규칙을 존중한다.그래서 대상 위키를 편집할 수 없는 사람은 번역문을 출판할 수 없을 것이다.차단된 사용자의 특정 사례에 대해, 최근 버전에서는 사용자가 게시할 수 없는 번역에서 시간을 낭비하지 않고 도구에 액세스할 때 오류를 표시하지 않도록 그러한 상황을 예측하려고 노력 중이다.

나는 우리가 공공 기물 파손과 영어 위키백과의 경험이 없는 사람들을 줄이기 위해 확증된 사용자들을 오토캐릭터하도록 콘텐츠 번역기를 추가로 제한할 것을 제안한다.우리는 다양한 위키에 뛰어들어, 단지 다양한 언어로 된 홍보 문구를 추가하고 사라지는 편집자들의 예를 들었다.예를 들어 LastLesson이 삭제되었는지 확인하십시오.우리는 또한 지원되지 않는 언어의 텍스트를 번역하려고 노력한 사람들의 사례도 있다.게다가, 많은 경우에 콘텐츠 번역기는 나쁜 위키코드를 생산하는데, 우리는 이 버그가 고쳐질 때까지 이것을 제한해야 한다. -- 마골라디즘 (토크) 05:57, 2015년 8월 7일 (UTC)[응답]

나는 콘텐츠 번역을 시도해 보았는데 지금은 냄새가 나.인터페이스는 좋은데 작동이 잘 안 돼.당분간은 꼭 신입 사원들이 사용하지 않도록 해야 해.Eman235/토크 14:47, 2015년 8월 7일 (UTC)[응답]

이것 좀 봐.분명히 영어를 못하는 사람으로부터 온 완전 재앙이다. -- 매기올라딘염 (토크) 21:40, 2015년 8월 7일 (UTC)[응답]

알프레드 베렝게나는 그의 만질 수 있는 다재다능한 형태와 그의 책으로 알려진 카탈루냐의 배터리다.

베렝게나는 매우 폭발적이고 빠르게 그의 역동적인 시간을 만질 수 있는 형태를 가지고 있다.

공식이야, 내용 번역 도구는 나보다 더 못 써.Bgwhite (대화) 22:15, 2015년 8월 7일 (UTC)[응답]

마지막으로, 누군가는 익명의 편집을 제한하는 것의 좋은 점을 보고 있다.세드릭 22:48, 2015년 8월 7일 (UTC)[응답]

이동 모듈

"M"이라는 모듈을 "N"이라는 모듈로 이동할 때, 모듈:M은 반환이 필요하다고 말해야 한다('모듈:N'). 게리트:146608을 참조하십시오.제프리T2000 (대화) 2015년 8월 8일 17:41, 8 (UTC)[응답]

@제프리T2000: 이것은 완벽하게 타당해 보이고 만약 그렇지 않다면 아마도 Phab에 있어야 할 것 같다.샘 월튼 (대화) 2015년 8월 8일 17시 50분 (UTC)[응답]

위키위젯스

위키위젯즈 프로젝트는 대화형 JavaScript 위젯을 일부 기사에 추가하여 그 안에 있는 개념을 설명하고 설명하는 것이다.스페인어 위키백과에서 이미 구현했으니까, 여기와 여기 두 개의 기존 위키위젯을 시도해 볼 수 있다.이 제안은 영어 위키백과로 프로젝트를 가져가는 것이다.그러기 위해서는 몇 가지 조치가 필요하다.첫 번째 방법은 템플릿을 만드는 것이다.위키위젯.그건 쉽네, 이미 했어.두 번째는 MediaWiki에 다음 코드를 추가하는 것이다.일반.js:

/** * 템플릿으로 문서에 WikiWidget 삽입:위키위젯 * WikiWidgets는 기사 내에서 취급되는 개념을 대화식으로 설명하고 설명하는 역할을 한다. * 코드는 먼저 WikiWidget의 미리 보기를 삽입한다.서버에 대한 요청을 최소화하기 위해, * WikiWidget 자체는 사용자가 미리보기를 클릭할 때만 로드된다. */ $( '.위드젯' ).각각( 기능을 발휘하다 () {  시합을 하다 위키위젯 = $( 이 ).자료( '위키위젯' );  시합을 하다 미리보기 = $( '[임시]' ).동뜨다({   '계급': '위키위젯프리뷰',   'title': 'WikiWidget을 로드하려면 클릭하십시오.',   'src': $( 이 ).자료( '위키위젯-위젯' ),   '스타일': '커서: 포인터'  }).찰칵찰칵 소리를 내다( 기능을 발휘하다 () {   가져오기스크립트( '미디어위키:위키위젯-' + 위키위젯 + '.js' );   importStylesheet( '미디어위키:위키위젯-' + 위키위젯 + '.css' );  });  $( 이 ).html( 미리보기 ); }); 

이 코드는 모든 페이지에 WikiWidget 템플릿이 있는지 확인한다.발견되면 WikiWidget의 미리보기 역할을 하는 이미지로 대체되며, 의 URL은 WikiWidget 템플릿에 있다.사용자가 미리보기를 누르면 WikiWidget 템플릿의 첫 번째 매개 변수에 이름이 지정된 Wikiwidget이 로드된다.위키위젯을 X라고 하면 로드된 코드가 MediaWiki:WikiWidget-X.js 및 MediaWiki:위키위젯-X.css.따라서 세 번째 단계는 MediaWiki 네임스페이스의 적절한 페이지에 하나 또는 둘 다의 기존 위키위젯 코드를 추가하는 것이다.

• MediaWiki:위키위젯 포미카리움js
• MediaWiki:위키위젯-포르미카리움.css
• MediaWiki:위키위젯 비바리움js
• MediaWiki:위키위젯-비바리움.css

스페인어 위키백과의 동음이의어 페이지에서, 또는 Git reposed here and here에서 코드를 찾을 수 있다.

마지막으로 몇 페이지 분량의 문서를 작성해야 할 것이다. 아마도 위키백과:WikiWidget, 템플릿 설명서 페이지:WikiWidget과 심지어 위키백과 제목도:위키위젯스.

나는 이미 이 제안을 이곳저곳에서 했다는 것을 언급해야겠다.처음은 스페인어 위키백과에서 시행되기 전이었고, 기술적으로나 개념적으로 미숙해서인지 큰 지지를 얻지 못했기 때문에, 나는 그것을 본국 프로젝트에 가져다가 그 곳에서 시행한 후 이곳으로 돌아왔다.두 번째로 훨씬 더 많은 지원을 받았지만 조기 보관돼 다시 올린다.이러한 논의와 스페인어 위키백과에서 몇 가지 우려사항이 재발했다.

• 내게 필요한 옵션: 위키위젯은 자바스크립트로 작성되므로 자바스크립트가 없는 사용자는 위키위젯을 실행할 수 없다.그러나 WikiWidget 템플릿에는 멋진 예비 기능이 있는데, 두 번째 매개 변수는 JavaScript가 활성화되지 않았을 때 사용자에게 표시되는 파일이다.마찬가지로 페이지를 인쇄할 때도 예비 파일이 표시된다.
• 성능: 모든 요청에 추가되는 유일한 새 코드는 MediaWiki의 코드:보통.js.위키위젯 자체의 코드는 로고를 클릭할 때만 로드되며 관례상 위키위젯은 자동으로 시작되지 않으므로 추가 요청 로드와 CPU 사이클이 최소화된다.
• 보안: 위키위젯의 코드는 공식 Wikimedia git 저장소에 git에 저장될 것이다.wikimedia.org모든 코드는 위키피디아에 들어가기 전에 코드 검토를 거치게 되므로 악성 코드의 위험은 다른 코드의 위험보다 크지 않아야 한다.나아가 기존 위키위젯은 코드 1000줄 미만의 단일 자바스크립트 파일로 구성되며, 향후 위키위젯은 크게 성장할 가능성이 낮아 검토가 상당히 용이하다.

몇몇 사용자들은 이미 이 제안에 기여했다. 나는 여러분 모두가 LFaraone, JohnBlackburne, WhatamIdoing, SMcCCandlish, Stuartyeates, APerson, Krinkle, Unready에 다시 참여하기를 바란다.건배! --Felipe (대화) 23:07, 2015년 7월 12일 (UTC)[응답]

펠리페, 이번 주에 해커톤과 위키마니아 때문에 멕시코 시티에 올 수 있어?WhatamIdoing (대화) 03:08, 2015년 7월 13일 (UTC)[응답]

안녕 WhatamIdoing, 불행히도 아니오, 하지만 유용하다면 행아웃이나 스카이프 미팅을 조정할 수 있어. --Felipe (토크) 21:18, 2015년 7월 14일 (UTC)[응답]

스페인어 구현은 마치 블랙박스와 같아서 독자들에게 그림(자막이나 제목 속성 없음) 이외의 다른 것이라는 표시가 없다.자바스크립트가 활성화되었을 때 스크립트가 (현재 두 예 모두 그렇듯이) 수동적인 상태로 직접 로딩되어 배트 바로 위에 흥미로운 것이 나타나는 것이 좋을 것이다.나는 위젯이 모든 주에서 이미지처럼 그 아래에 캡션을 달았으면 좋겠다.나는 로고가 왜 연관되어야 하는지 모르겠다; 위젯은 j가 활성화된 사람들을 위해, 그리고 이미지나 그렇지 않은 사람들을 위해 무엇이든지 할 것이다.그 외에도 나는 위키피디아에 이 기능을 추가하는 것을 지지한다.(현재 사용되고 있는 정교하지만 암호화된 이름보다는 사용 가능한 두 개의 위젯 이름을 단순하고 설명적인 이름으로 부여한다면 좋을 것이다.{{WikiWidget GameOfLife}와 {{WikiWidget Vivarium}}}을(를) 비교해 보십시오. 리그그르 모티스(토크) 00:11, 2015년 7월 19일(UTC)[응답]

너의 코멘트에 감사하고 Riggr Mortis를 지지해줘.이전에는 위젯이 패시브 모드로 로딩되었지만, 이전 논의에서 몇 가지 코멘트를 통해 로고를 변경하게 되었다.기본적으로, 연결 속도가 느린 사람에 대한 부하를 줄이기 위해 각 요청에 따라 전송되는 요청과 데이터의 수를 최소화하는 것이 목적이다.몇 가지 다른 장점도 있다.첫째, 로고를 사용하면 모든 위젯에 균일한 초기 인터페이스를 제공하여 인식 가능하도록 할 수 있다(기존의 두 위젯은 매우 유사하지만 미래의 위젯은 매우 다르게 보일 수 있다).둘째, 위젯이 수동적으로 로딩되기 시작하면, 글에 맞게 글씨를 바삭바삭하게 바삭거리지 않도록 작은 크기를 가져야 한다.그러나 로고로 시작하면 로고를 클릭하면 위키위젯이 사용자를 화나게 하지 않고 전체 크기로 확장될 수 있다(물론 닫을 수 있는 버튼이 있어야 할 것이다).지금까지는 기존 2개의 위젯이 작은 크기로 확장되지만, 앞으로는 쉽게 바뀔 수 있는데, 공간이 많아지면 잠재력이 더해져 흥미진진한 가능성이 있다.반면에 이미지에는 적어도 제목이 있어야 한다는 데 전적으로 동의하기 때문에 내가 제안한 코드에 그것을 추가했을 뿐이다.자막도 통할지 모르지만 실행하기 전에 다른 의견을 듣고 싶다.위젯의 이름에 대해서는 주로 언어중립성이 강하기 때문에 포미카리움, 비바리움을 선택했다(종의 라틴어 이름과 유사함).이 두 가지 위젯은 다른 위키피디아에게 프로젝트를 보여주는 예시 역할을 할 것이기 때문에 가능하면 언어 기반의 불평은 피하고 싶다.어떠세요? --Felipe (대화) 15:39, 2015년 7월 20일 (UTC)[응답]

이것은 단지 FYI 게시물인가, 아니면 우리가 어떤 것을 지지/반대해야 하는가, 아니면 다른 특정한 형태의 입력물을 제공해야 하는가? (나는 이전 버전의 쓰레드에서처럼 지원한다. — SMcCndlish ¢ ⱷ ^ʌⱷ ⱷ ⱷ^ʌ _ᴥ҅҅҅ 03:30, 2015년 7월 25일 (UTC)[응답]

MediaWiki 네임스페이스의 변경을 요청하기 전에 모든 주요 문제가 해결되었는지 확인하고 싶다.그런데, 여기 누구라도 변화를 말할 수 있는 사람이 있을까?

Jackmcbarn, ais523, Technical 13, Anomie, SFB, 이 제안에 대한 첫 번째 토론에 참여하셨습니다.그때부터 많이 진화했다.시행해볼까? --Felipe (토크) 22:09, 2015년 7월 30일 (UTC)[응답]

개인적으로는 온위키보다는 소프트웨어로 하는 게 낫겠지만, 미봉책으로 좋은 것 같다.잭mcbarn (대화) 22:43, 2015년 7월 30일 (UTC)[응답]

동의해. 여기서 쓰면 내장할 수 있을 거야.다양한 것들이 위젯 실험으로 시험되어 나중에 시스템의 기본 부분이 된다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 22^ʌ ҅_ᴥ ҅ 22:56, 2015년 8월 3일 (UTC)[응답]

관리자가 필요한 미디어위키 네임스페이스 파일 4개를 만들어 로컬에서 테스트할 수 있도록 하는 것이 도움이 될 것이다.내 사용자:에 js 및 css 코드가 이미 있는 경우:SMcCandlish/common.*파일, 하지만 en.wiki로 테스트할 건 없어 — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 23 ҅_ᴥ 23^ʌ 23:07, 2015년 8월 3일 (UTC)[응답]

물론 유용하겠지만, 이 제안에 대한 지원이 대부분 있고, 이미 세 번의 토론을 거쳤기 때문에, 이 토론이 보관되면 미디어위키 네임스페이스에 필요한 페이지를 만들도록 관리자에게 요청할 계획이며, 미디어위키에 필요한 변경도 할 계획이다.Common.js 및 MediaWiki:common.css.즉, 누군가가 차단 반대가 없는 한. --Felipe (토크) 16:58, 2015년 8월 5일 (UTC)[응답]

나는 이 제안의 다른 화신에게만 게시된 나의 강한 반대 의견을 다시 한번 강조하겠다.위키피디아는 내용을 위해 자바스크립트를 요구해서는 안 된다. 그것은 엄격히 강화되어야 한다.위키위젯은 분명히 강화가 아닌 만족을 목적으로 한다.보안에 대한 우려는 말할 것도 없고, 내가 느끼기에는 충분히 여기서 다루어지지 않는다.{{Nihiltres talk edits}}{{nihiltres talk edits}}} 01:59, 2015년 8월 6일(

니힐트레스, 만약 당신이 그 프로젝트에 강력히 반대한다면, 나는 그것에 반대하는 강력한 주장을 기대하겠다.하지만, 당신은 어떤 것도 제공하지 않았다.당신은 자바스크립트가 엄격하게 개선되어야 한다고 말하지만, 당신은 그 이유를 설명하지 않았다.우리가 당신의 주장을 평가할 수 있도록 그렇게 해 주시겠습니까?당신은 또한 보안 문제가 완전히 해결되지 않은 것을 "느낌"이라고 말한다.그러나 이런 맥락에서 감정은 타당한 주장이 아니다.우리가 해결하려고 노력할 수 있도록 당신의 실제 관심사가 무엇인지 자세히 설명해 달라. --Felipe (대화) 19:54, 2015년 8월 6일 (UTC)[응답]

당신은 내가 여기서 제기한 보안 문제와 다른 우려들을 무시했다: 위키백과:마을 펌프(프로포즈)/아카이브 125#위드젯나는 아직 다시 답장을 하고 싶지는 않았지만, 당신이 반복적으로 표출된 우려에 대한 당신의 애원하는 무지는 솔직히 받아들일 수 없다.이번이 세 번째 스레드를 시작한 것이다(Wikedia: 참조):마을 펌프(프로포즈)/아카이브 124#WikiWidgets).다른 편집자들이 대답하는 데 지칠 때까지 같은 주장을 계속 반복할 필요가 없으므로 당신은 디폴트로 승리할 수 있다.--존블랙번^words_deeds, 2015년 8월 6일 (UTC)[응답]

반대로 존 블랙번과는 반대로, 나는 당신의 우려에 대해 반복적으로 대답했고, 몇몇 사용자들은 나의 답변이 만족스럽다고 동의했다.사실, 이 줄에 있는 나의 첫 번째 게시물은 당신의 접근성, 성능 및 보안 문제에 대한 명확하고 명확한 해답을 가지고 있다.나는 대부분 너를 생각하며 그 답안을 썼는데, 너는 굳이 언급하려고 하지 않아서 네가 읽었는지도 모르겠어.친절하게도 그것들을 읽고 내가 당신들의 관심사에 제안하는 해결책들이 무엇이 문제인지 지적해 주시겠습니까?나의 거듭된 포스팅에 대해서, 스페인어 위키백과에서 프로젝트가 실행되기 전에 첫 번째 포스팅이 이루어졌다는 것을 알아야 한다, 실행 전략이 아직 걸음마 단계였다.거기서 그리고 나중에 스페인어 위키백과에서 있었던 토론은 구현을 많이 향상시켰기 때문에 스페인어 위키백과에서 배치되었을 때, 최신 접근법을 공유하기 위해 여기에 리턴을 했고, 만약 그것이 만일 실드가 정기적으로 여기에 보관되지 않았더라면, 토론이 이루어지더라도, 나는 그 실에서 논의를 계속했을 것이다.해결 여부(흐름 확장이 심각하게 필요한 또 다른 이유). --Felipe (대화) 00:35, 2015년 8월 7일 (UTC)[응답]

저 실 좀 다시 봐.나의 우려는 마지막 한 게시물에서 표출되었고, 그 때 무시되었고, 2015년 8월 7일 JohnBlackburne^words_deeds 01:58, 2015년 8월 7일(UTC) 이후로 언급되지 않았다.

나는 너의 마지막 글에 대한 너의 댓글을 다시 읽었다.온위키가 아닌 위키미디어 저장소에서 개발되고 있는 위젯에 대한 당신의 우려에 대해, 나는 이미 여기저기서 답을 주었지만, 요약하자면 위키위젯은 크로스위젯으로 되어 있기 때문에, 그것들을 한 중앙에서 개발하는 것이 타당하므로, 다른 언어의 개발자들이 협업할 수 있도록 하기 위해서, 그리고 또한 a.현재 가젯과 같이 호환이 되지 않을 수 있는 위젯의 버전을 무효화한다(그런데, 보안이 염려되는 경우 위키위젯이 아닌 가젯에 대한 캠페인을 시작해야 한다).둘째로, 어떤 가젯을 개발한 사람이라면 누구나 알고 있듯이 MediaWiki 내의 개발 주기는 악몽이다: 다른 페이지를 편집, 저장, 다시 로드하여 변경 사항을 확인하고, 다시 편집하고, 다시 저장한다.각각의 사이클은 몇 번의 클릭과 재장전을 수반하며, 천 번 반복되면서 악몽이 된다.그렇기 때문에 위키위젯 저장소에는 브라우저에서 위젯을 실행하는 데 필요한 최소한의 마크업이 있는 index.html 파일이 포함되어 있어 개발 프로세스의 속도가 엄청나게 빨라진다.셋째, MediaWiki는 코드 개발을 위해 설계되지 않았기 때문에, 비록 그렇게 하는 것이 가능할지라도, 그것은 확실히 최적이 아니며, 코드 개발과 협업을 위해 설계된 소프트웨어를 이용하지 않을 것이다.템플릿과 모듈은 어느 정도 복잡성을 가지고 있지만 위젯이 가지고 있는 만큼(나는 실제로 모듈을 개발하지 않았지만, 많은 템플릿을 개발했다), 복잡성이 증가함에 따라 적절한 소프트웨어의 필요성도 증가하게 된다.어쨌든, 여러분이 이 점에 대해 옳았다고 해도, 그리고 위젯은 위키에서 개발되어야 한다고 해도, 이것은 그 프로젝트에 있어서 차단 문제가 되지 않는다!

두 번째 포스트에서는 "성능, 접근성 및 보안"에 대한 우려에 대해 다시 이야기하십시오. 마치 그 단어들이 더 이상 설명 없이 의미가 있는 것처럼요. 우리가 그것들을 긴 시간 동안 논의해 온 것을 보면요.그 세 가지 우려에 대한 나의 해결책은 이 실의 첫 번째 글에 명시되어 있는데, 당신은 아직도 읽을 기미를 보이지 않고 있다.너는 내가 제시하는 해결책을 제시하지 않고 계속 걱정거리를 제시한다.당신은 또한 "누구나 편집할 수 있는 백과사전에 사용자 편집 가능한 JS를 두는 것은 모든 종류의 보안에 영향을 미친다"고 말하지만, 당신은 "우리는 이미 WP에 몇 개의 JS 파일을 가지고 있지만 그것들은 관리자에 의해서만 편집될 수 있고, 잘못된 편집은 상황을 나쁘게 만들 수 있기 때문에 소수의 숙련된 관리자만이 만을 만지는 경향이 있다"고 말하므로, 그래서 당신은 거의 대답할 수 있다.당신 자신. 게리트어로 개발되고 있는 위키위젯은 "경험이 풍부한 관리자"가 그렇게 하기로 결정할 때(적어도 다른 사람이 지적한 대로 당연한 방법인 커먼즈에서 봉사하기 전까지는) 각각의 특정한 위키백과에 배치될 것이다.그리고 "잘못된 편집은 사태를 나쁘게 만들 수 있다"는 당신의 우려, 그것이 코드 검토가 존재하는 이유, 그리고 설사 어떤 것이 잘못되더라도(구문 오류, 또는 가젯과의 비호환성 또는 코드를 붙여넣는 관리자의 오류) 가장 큰 문제는 f가 있는 특정 페이지에서 일부 자바스크립트가 작동하지 않는다는 것이다.다른 곳 어디에도 없는 위키위젯이 박혀있어위키텍스트나 템플릿이나 다른 곳에서 구문 오류와 마찬가지로 이야기의 끝부분을 찾아 고치는 것이 문제일 것이다.위키피디아가 자바스크립트에 의존하는 것이 매우 적다는 사실 덕분에, 아이러니하게도 끔찍한 결과는 없을 것이다.답변이 길어서 미안하지만 당신은 받을 자격이 있어. --Felipe (토크) 02:51, 2015년 8월 7일 (UTC)[응답]

그것들은 다른 위키에서 사용될 수 있기 때문에 외부적으로 호스트할 필요가 없다.이것은 여기 다른 소스 코드와 코드와 같은 컨텐츠와 함께 항상 일어난다.예를 들어, 그리고 현재 루아 모듈은 거의 항상 하나의 특정한 위키에서 독립적으로 개발된다.종종 이것은 가장 크고 가장 발달된 것이다.그리고 나서 다른 위키피디아들은 그것들을 복사할 수 있고, 복사하거나, 오른쪽에서 왼쪽까지의 레이아웃과 같은 그들의 특정한 필요에 맞게 그것들을 다른 방법으로 조정할 수 있다.Github나 Gerritt는 우리가 여기 가지고 있는 것을 대부분 재현하지만, 우리의 관점에서 볼 때 사용자 계정, 허가, 이력 또는 기여 기록과의 통합이 전혀 이루어지지 않은 채 매우 형편없이 복제된다.또한 es.wp의 프로그램에서와 마찬가지로 WP에서 적절한 권한을 가진 편집자(또는 편집 요청 메커니즘을 통한 편집자)가 변경을 수행하는 것을 막을 수 있는 것은 없다.이러한 것들은 외부적으로 호스팅되는 버전에 다시 통합되어야 할 것이다.그리고 콘텐츠의 다양성을 지원하지 않는 코드는 커먼즈에서 호스팅할 수 없다(설명만으로).게다가 모든 지역화/채택이 필요한 상황에서 모든 위키에서 사용할 수 있는 공용화 버전을 갖는 것은 어려울 것이다.

이것들은 내용보다는 템플릿/모듈에 가깝다: 특정 페이지에서 사용되는 프로그래밍의 비트.일반적으로 코드가 여러 페이지에서 공유되지만 템플리트도 한 페이지에 해당할 수 있다.위키위젯과의 유일한 차이점은 그들이 JS에 있다는 것이다.MediaWiki는 이미 JS 페이지, 인터페이스, 가젯, 사용자의 개인 인터페이스 페이지를 완전히 지원하므로 문제가 되지 않는다.그러나 여기서 보안 문제가 발생한다.JS의 다른 비트는 전세계적이거나, 매우 철저하고 반복적으로 확인되거나, 가젯이나 개인 JS로 원하는 사용자만 선택적으로 사용할 수 있다.

WikiWidgets는 현재 페이지를 방문한 모든 사용자를 대상으로 실행되며(활성화 후) 훨씬 더 많은 보안 문제가 발생한다.나쁜 편집이 그들의 활동을 멈추게 할 수 있다는 것만이 아니다.JS의 경우, 나쁜 편집은 당신이 원하지 않는 모든 종류의 일을 하는 악성 코드를 도입할 수 있다.그런 코드를 쓰는 사람들은 그것이 갈 곳을 찾아 다니는 소규모의 산업이 있다.관리자가 편집만 가능하도록 만들면 이러한 우려가 제한되지만 관리자가 작성하지 않은 코드를 확인하고 확인할 책임이 있다.당신은 코드는 검토될 것이라고 제안하지만, 다른 사람의 코드, 특히 여기서 작업해야 하는 사람이 상대적으로 적은 JS를 검토하는 것은 상당히 어려우며, 우리는 현재 그것을 위한 절차를 가지고 있지 않다.

자동 장착하지 않으면 성능과 접근성을 어느 정도 다루지만 현재 인터페이스는 매우 열악하다.이 아이콘은 그 크기에서는 분명하지 않고 솔직히 못생겼다: 그것은 편집 바와 같은 사용자 인터페이스에서 무언가의 확대된 버전처럼 보인다.오른쪽 화살표 아이콘이 있는 정적 이미지 컨텐츠가 훨씬 더 나을 것이다.이것은 오늘날 웹, 영화뿐만 아니라 애니메이션 GIF, 슬라이드쇼, 플래시 콘텐츠 등 여기의 영화들을 포함한 많은 인터랙티브 콘텐츠가 제공되고 있는 것이다.그렇게 되면 작동 방식이 훨씬 분명해질 것이다.--존블랙번^words_deeds 21:47, 2015년 8월 7일 (UTC)[응답]

나는 존 블랙번의 건설적인 비판에 정말 감사한다.미리보기 로고를 재생버튼으로 교체하는 것은 분명히 좋은 생각인 것 같아서 바로 해 봤는데 스페인어 위키백과에 방금 배치되었어.여기와 여기(하드 리프레쉬를 해야 할 수도 있다)에서 확인할 수 있다.MediaWiki에서 필요한 코드도 업데이트했다.Common.js를 통해 이 새로운 구현이 작동하도록 하고 MediaWiki에 대한 코드를 제거함Common.css, 더 이상 필요하지 않으니까.

다른 두 가지 문제가 남아 있다(또는 세 번째 문제가 있는가?). 첫째, 관리자가 새로운 버전의 위키위젯이 나올 때마다 각 위키백과에 코드를 복사하여 붙여넣는 것이 좋을지, 아니면 기기처럼 각 위키백과에서 분산된 방식으로 위키위젯을 개발하는 것이 더 나을지를 결정하는 것이다.현재 개발된첫 번째 전략을 '게리트 전략'이라고 하고, 두 번째 전략을 '온위키 전략'이라고 부르자.두 번째 쟁점은 보안 리스크를 관리할 수 있는지 여부를 결정하는 것이다.

당신은 온위키 전략에 찬성하는 아주 좋은 주장을 내놓았다.당신은 게리트 전략으로는 복제할 수 없는 장점이 있다고 나를 설득했다.그럼에도 불구하고 온위키 전략으로는 복제할 수 없는 게리트 전략에도 장점이 있다고 생각한다.잘 들어, 나는 그 어느 전략에도 감정적인 애착이 없어, 마치 내가 깃허브를 할 필요가 없었던 것처럼.내가 원하는 것은 이 프로젝트가 성공할 수 있도록 가능한 모든 노력을 다하는 것이다. 나는 그것이 많은 잠재력을 가지고 있다고 생각한다.어쨌든 게리트 전략에서 내가 보는 장점은 다음과 같다.

첫째, 각 위키위젯을 위한 저장소를 보유함으로써 개발자들은 위키위젯 자체를 뛰어넘는 파일 및 개발 도구를 공유할 수 있다.index.html 파일의 예를 들었다.그런 생각을 떠올린 이후 나의 개발 주기는 엄청나게 빨라졌고, 그것을 미래의 개발자들과 공유하지 못하는 것은 부끄러운 일일 것이다.index.html 파일의 아이디어와 코드는 원칙적으로 위키백과의 일부 문서를 통해 공유될 수 있지만, 어느 문서에서 공유될 것인가?이것은 repo에 index.html을 포함함으로써 완전히 피할 수 있는 불필요한 언어 장벽을 도입할 수 있다.이 문제는 index.html 파일에 대해 해결될 수 있지만, 효과적인 공유가 훨씬 더 어려울 수 있는 다른 더 큰 개발 지원 도구가 생겨도 나는 놀라지 않을 것이다.가장 간단한 해결책은 각 위키위젯의 효율적인 개발을 위해 필요한 모든 코드와 도구를 포함하는 리포지토리로 보인다.또한, 우리가 처음부터 이것을 하지 않는다면, 그것은 어쨌든 배경에서 일어날 것 같다, 그것은 현재 기트허브와 같은 곳에서 개발되고 있는 많은 장치들(예: 내가 기여하는 PropectIt 기기)과 같은 곳에서 개발되고 있는 것들이다.

둘째, 한 중앙 위치에서 개발함으로써 새로운 위키위젯과 기존 위키위젯의 새로운 버전이 훨씬 더 효과적으로 확산될 것이다.만약 중국 위키백과가 위키위젯을 시행하고 일부 중국인들이 비바리움을 개선하기로 결정한다면, 개발업자가 나에게 말하지 않기로 결정하거나 잊어버린다면 내가 어떻게 알아낼 수 있을까?그리고 만약 프로젝트가 확산된다면, 이것은 필연적으로 점점 더 흔해질 것이다.게리트에서 개발함으로써, 모든 코드 업데이트는 관련된 모든 개발자들에게 보고될 것이고, 그래서 우리는 우리의 가정 프로젝트에 새로운 코드를 퍼뜨릴 수 있을 것이다.

셋째, 가장 중요한 것은 보안 우려다.네가 말했듯이, 각 위키피디아의 관리자에게 그들이 쓰지 않은 코드를 검토하도록 요구하는 것은 성가실 뿐만 아니라 위험할 수도 있다.반면에, 만약 정책이 게릿트에서 나온 코드만 사용한다면, 프로젝트에 관련된 개발자들만이 새로운 코드를 검토해야 할 것이고, 우리는 아마도 프로젝트에 관여하지 않은 관리자보다 훨씬 더 효율적일 것이다.이것이 저울이 게리트로 기울어지는 핵심 포인트라고 생각한다. --Felipe (토크) 02:59, 2015년 8월 9일 (UTC)[응답]

@Felipe Schenone: JavaScript는 일부 사용자가 액세스할 수 없기 때문에(또는 특정 기능에 대해 최신 버전에 액세스할 수 없기 때문에) 개선을 위해 엄격하게 사용되어야 한다.콘텐츠의 접근성은 일반적으로 중요한 것으로 간주되며 위키위젯은 분명히 콘텐츠일 것이다(플레이스홀더의 "강화"라는 주장은 허황된 것을 넘어서는 것이다).나는 또한 그 제안과 그것이 반복적으로 제안된 방식에 대한 존 블랙번의 우려를 반영한다.{{Nihiltres talk edits}}} 23:38, 2015년 8월 6일 (UTC)[응답]

Nihiltres, 위키피디아의 숫자는 약간 다를 수 있지만, 이 출처에 따르면, 오늘날 98% 이상의 사용자들이 자바스크립트를 사용한다.사용자 기반 중 소수만이 JavaScript를 사용하지 않기 때문에 JavaScript를 사용하는 귀중한 콘텐츠를 금지하는 것은 어설픈 주장이다.그것은 사용자 기반 중 소수가 화면 판독기를 사용하거나 눈이 멀기 때문에 이미지를 금지하는 것과 같다.또 다른 논쟁은 없으십니까?위키위젯이 개선되고 있다는 내 주장에 대해, 네 말이 맞아, 그건 약해, 그래서 네가 게시하기 전에 내가 삭제한 거야.존 블랙번의 고민에 대해서는, 제 답장을 보십시오. --Felipe (대화) 00:35, 2015년 8월 7일 (UTC)[응답]

제안:피드백 요청 서비스 및 WP와 같은 보드 통합:RSN, WP:NPOVN 및 WP:NORN

나는 WP를 본다.RSN, WP:NPOVN 및 WP:NORN은 규칙적으로, 그리고 때때로 약간의 경직된 부분이 있고 아무도 실제로 반응하지 않는다.때로는 토크 페이지에서 싸우는 사람들(미안해, 토론하는 사람들)이 거기서 토론을 계속하고 외부 편집자들이 반응을 보이지 않는다.

피드백 요청 서비스에서 RfCs처럼 이 페이지를 통합할 수 있는지 궁금했다.이것은 즉각적으로 그곳에서 의견을 제시할 수 있는 편집자들로 구성된 임의의 풀을 만들 것이다.킹신디안 ♝ 23:08, 2015년 8월 9일 (UTC)[응답]

관리자 호출 바인딩을 위한 RfC

안녕하십니까. 위키백과에서 코멘트를 받으십시오.관리자 호출 바인딩을 위한 관리자/RfC. 여기서 삭제 프로세스에 대한 논의가 진행 중임.~ 롭^Talk 05:39, 2015년 8월 10일 (UTC)[응답]

새 아티클 검색 요청

요청의 가능한 모든 범주(예: 이름, 대체 이름, 국가, 필드, 하위 필드)를 통해 지루하게 주제가 요청되었는지 확인할 수 있는 방법이 있는가?검색을 할 때 요청이 나타나지 않는 이유는?나는 모든 종류의 관련 없는 것들을 있는 그대로 얻는다(직격타가 없다면, 왜 이 이름을 가진 기사가 요청되었다는 쪽지가 나오지 않는가?이것은 또한 쓰여진 기사에 대한 몇몇 붉은 요청들을 없앨 것이다.Kdammers (대화) 09:16, 2015년 8월 10일 (UTC)[응답]

사용자 샌드박스: "튜토리얼 샌드박스 1, 2, 3, 4, 5"를 사용자 정의 샌드박스 기능으로 대체

여기를 보십시오: 사용자:ManosHacker/sandbox에서 템플릿:사용자 모래 상자가 작동한다.신규 사용자는 목록으로 완벽하게 구성되고 간단한 클릭으로 샌드박스된 기사를 메인 기사 공간으로 이동할 준비가 된 다중 기사 샌드박스 작업장을 오류 없이 빠르게 작성할 수 있다(사용자 네임스페이스에서 메인 네임스페이스로 이동할 때 이러한 새로운 버튼이 없는 오류는 규칙이었다).기존 사용자의 물림 없음.우리는 위키백과학교에서 몇 달 동안 그것을 표준적인 관행으로 사용해 왔다.기능을 먼저 숨기기 해제하십시오.샌드박스가 있는 하위 문서를 따라 템플릿의 동작 변경을 확인하십시오.맴도는 것은 지침을 준다.샌드박스를 기사로 이동하면 개인 샌드박스 보기 목록에서 제거된다.···마노스해커 23:33, 2015년 7월 31일 (UTC)[응답]

정확히 뭘 제안하는 거야?Eman235/토크 10:29, 2015년 8월 1일 (UTC)[응답]

이 제안은 다음과 같이 구성된 작업영역 기능을 템플리트 내부에 배치하는 것이다.사용자 샌드박스(이전 템플릿을 새 템플릿으로 바꾸기)그것은 새로운 사용자들에게 매우 유용하다.튜토리얼 샌드박스 1, 2, 3, 4, 5를 훨씬 더 많은 기능으로 대체한다.···마노스해커 11:22, 2015년 8월 1일 (UTC)[응답]

• 지지하다.자습서 샌드박스 1, 2, 3, 4, 5 기능은 필요하지 않고 사용되지 않는다.새로운 기능이 유용한 것으로 입증되었다[3][4][5].···마노스해커 04:42, 2015년 8월 10일 (UTC)[응답]

나는 샌드박스의 다중 사용에 전적으로 동의하고 지지한다.FYI, 나는 현재 몇 개의 샌드박스(그리스어 위키백과에서)를 동시에 작업하고 있다.Χρήστης:아리스토 클래스//ρόει///raft πομμέαα(이것은 계류 중, 전문가의 설명을 기다리고 있음), el:χήήσ::::::아리스토 클래스//ρόχιο//드래프트 raftρήσσςςςςςς ( ( ( ( ( ( ( ( ( ((이것은 보류중, 정보 참조의 다른 출처를 기다리며), el:ρήστ:::::::::아리스토 클래스///όχιο//드래프트 레곤(이것은 수의사의 확인이 필요하므로 미결로 있음), 엘:χρήηηη:::아리스토 클래스//ρόεο//드래프트 μακύύύύ ( (ύύύ ((현재 이 샌드박스에서 작업 중) 등을 이용, 나의 「위키페디아 시간」(토크)을 최대한 활용한다. --아리스토 클래스(토크) 2015년 8월 18:48, (UTC)[응답]

반정규 위키백과 라이브러리 중앙 또는 사이트 통지

안녕하십니까, 위키백과 도서관에서 우리는 편집자들이 레퍼런스 데스크, 자원 교환, 오픈 액세스 가이드, 기부된 유료 데이터베이스에 대한 우리의 대중적인 무료 액세스 등 다양한 커뮤니티 주도의 지원 서비스를 발견할 수 있도록 돕는 개방형 연구 허브를 개발했다.

지금까지 이 기부는 거의 4500개의 계정을 가진 다수의 언어 커뮤니티에서 2400명 이상의 편집자들에게 제공되었다.이러한 접속 기부를 전달하는 우리의 주요 방법은 2개월 또는 3개월마다 감시목록 공지사항, 마을 펌프 메시지, 그리고 새로운 파트너십을 발표하는 소셜 미디어였다.(여기서 발표 과정을 참조하십시오.)

그러나, 우리는 여전히 수십 개 또는 (어떤 경우에는) 수백 개의 계정을 사용할 수 있는 광범위한 편집자에게 혜택을 줄 수 있는 매우 유용한 자원과 많은 파트너십을 맺고 있다.우리는 일부 파트너십의 경우, 이는 단순히 자원이 관심의 대상이 아니기 때문이라는 것을 알고 있지만, 더 많은 파트너십의 경우, 우리의 발표가 연구 자료에 대한 무료 접근으로부터 이익을 얻을 수 있는 사람들에게 도달하지 못하기 때문에 편집자들이 놓치고 있다.그들은 단지 이 프로그램이 존재하는지 모를 뿐이다.

이미 계정을 가지고 있는 2400명보다 훨씬 더 많은 잠재적 사용자들이 있다: 대부분의 우리의 계정들은 위키백과에서 6개월의 활동과 500번의 편집을 가진 어떤 편집자도 무료로 이용할 수 있다.

우리는 위키백과 도서관이 무료 접속의 기본 기준을 충족시킬 것 같은 서명된 편집자를 대상으로 반정기(매 4~6개월) 영어 위키백과 사이트- 또는 CentralNotes를 운영할 수 있는가?

이 통지는 편집자들에게 a) 파트너 자원에 대한 접근이 가능하고 b) 편집자들이 그러한 파트너십에 대한 자격을 갖추지 못하거나 우리의 특정한 출처를 필요로 하더라도, 그들의 연구와 위키백과에 대한 기여를 돕기 위한 다른 자원이 존재한다는 것을 상기시켜 줄 것이다.

프랑스어 위키백과 도서관은 몇 달 전 새로운 편집자들에게 알리고 끌어들이는데 큰 성공을 거두면서 이와 유사한 고시를 성공적으로 운영했다.

우리는 이것이 이 프로그램의 영향을 증가시킬 수 있는 귀중한 기회라고 생각하며 가능한 한 많은 편집자들이 이 프로그램의 혜택을 받도록 하고 싶다.우리는 제안된 통지에 대한 피드백과 생각을 요청하고 싶다.

고마워, 애스틴슨 (WMF) (토크) 21:06, 2015년 8월 11일 (UTC)[응답]

참고로, 이전 SiteNotices에서 제안했기 때문에 실수로 Tech Pump에서 이 요청의 다른 버전을 실행했다.그 대화가, 여기로 리디렉션되어, Astinson (WMF) (토크) 21:06, 2015년 8월 11일 (UTC)[응답]

좋은 생각이야!시멘틱맨티스 (대화) 22:01, 2015년 8월 11일 (UTC)[응답]

기본 검색 결과 수

"내역 보기" 페이지, 로그 페이지, 사용자 기여 페이지 등과 같은 기본 검색 결과 수를 20에서 50으로 변경하십시오.제프리T2000 (토크) 23:45, 2015년 8월 11일 (UTC)[응답]

제안서를 작성할 때 왜 당신의 아이디어가 좋다고 생각하는지 설명하면 유용할 수 있다.이 경우에는 확실히 명백하지 않다.비블브록스 (대화) 23:19, 2015년 8월 12일 (UTC)[응답]

템플릿:인포박스 person Ⅱ

나는 위키다타와 사용자 데이터 인포박스를 나란히 보고 비교하기 위해 이 템플릿을 만들었다.소스 편집기에서 미리 보는 동안 이중 인포박스를 표시하며, VisualEditor에는 영향을 주지 않으며, 기사 내에 저장되어 있으면 전혀 해를 입지 않는다.WD hidden infobox 사용자 템플릿과 함께 업데이트만 유지하십시오.여기서 체크아웃하십시오.모든 Infobox 사용자 템플릿 이름 끝에 "i"를 추가하여 모든 문서에서 사용할 수 있다.즐기세요.··마노스해커 13:51, 2015년 7월 22일 (UTC)[응답]

@Frietjes and Plasticikspork: -- Magioladis (대화) 16:25, 2015년 7월 22일 (UTC)[응답]

이것이 필요하다면, 그것은 유지되어야 하는 또 다른 프런트엔드를 만들기 보다는 템플릿:infobox person과 병합되어야 한다.@Stradivarius와 Jackmcbarn:프리테제스 (대화) 2015년 7월 22일 (UTC) 16:36[응답]

그래, 이건 미리보기 모드에서 사용할 수 있는 진짜 템플릿의 기능일 뿐이야. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 16^ʌ ҅_ᴥ ҅ 16:47, 2015년 7월 22일 (UTC)[응답]

동의해. -- 마골라디염 (대화) 16:55, 2015년 7월 22일 (UTC)[응답하라]

그것은 가능성을 보여주고 오류 확인을 허용하기 위해 별도로 만들어졌다.나는 또한 진짜 템플릿 내의 병합에 동의한다.···마노스해커 23:59, 2015년 7월 22일 (UTC)[응답]

알았어그게 도움이 된다는 것에 동의해. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ҅ ≼ ≼ ≼ 19:47, 2015년 7월 26일 (UTC)[응답]

수정/추가 작업을 위해 wikidata 항목과 연결할 수 있는 것도 유용할 것이다.···마노스해커 00:23, 2015년 7월 23일 (UTC)[응답]

마노스해커 나는 영어 위키백과에서 아직 그 대규모의 위키다타로부터 정보를 얻을 준비가 되어 있지 않다는 것이 문제라고 생각한다. -- 매기올라딘염 (대화) 12:29, 2015년 7월 23일 (UTC)[응답]

위키다타에서 기사로 수입할 근거나 요청은 없다.이것은 위키백과나 위키다타 중 어느 쪽이든 실수를 바로잡고 업데이트하는 데 도움을 주기 위해 미리 보는 동안 자동 데이터와 수동 데이터를 나란히 비교하는 도구다.기사 자체에는 영향을 미치지 않고, 소스 편집자의 미리보기에만 영향을 미친다.···마노스해커 13:08, 2015년 7월 23일 (UTC)[응답]

이제 템플릿이 병합되어 Infobox 사용자를 ii 버전으로 교체할 수 있음

현재는 인포박스 사람과 합병되어 매력적으로 작용하고 있다. 변경 중에 Infobox 개인과 Infobox 개인 ii를 모두 업데이트할 필요 없음. 고급 사용자들을 위한 옵션으로 그것을 구현할 것을 제안한다.···마노스해커 13:42, 2015년 7월 23일 (UTC)[응답]

그것은 루프 테스트를 통과하지 못하기 때문에 사용할 수 있지만 하나의 템플릿으로 병합되지는 않는다.병합에는 항상 두 개의 외부 자식 템플릿이 필요하며 템플릿 업데이트는 항상 트리플(tripple)이 된다.···마노스해커 16:44, 2015년 7월 23일 (UTC)[응답]

그건 좀 전보였어.그렇다면 제안된 해결책이 있는가? — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ҅ ≼ ≼ ≼ 19:47, 2015년 7월 26일 (UTC)[응답]

업데이트

Infobox person Ⅱ 안에 WD 숨겨진 Infobox person을 성공적으로 병합했다.···마노스해커 15:12, 2015년 7월 30일 (UTC)[응답]

제안:이전 템플릿을 새 템플릿에 중첩하고 이 기능을 선택 사항으로 설정하며 사전 선택되지 않음

목적

Wikidata 항목으로 자동으로 채워지는 미러 인포박스에 수동으로 채워진 인포박스 미리 보기

대상

양쪽의 데이터를 쉽게 비교 및 업데이트

특징

Wikidata infobox는 소스 편집기 미리보기 중에만 표시되고 아티클 뷰에서 사라짐, 이전 아티클 버전 뷰, VisualEditor

불편

두 템플릿을 모두 동기화해야 하지만 매우 간단한 프로세스와 새 템플릿이 매우 깨끗해야 함

단계(기술)

1. 템플릿 intermate Infobox person i 대신 Infobox person i로 전화하십시오.
2. 템플릿 이동:인포박스 사용자를 템플릿으로:리디렉션되지 않은 Infobox 개인 i
3. 템플릿 이동:Infobox person Ⅱ to Template:리디렉션되지 않은 Infobox 사용자
4. Infobox 사용자 사용 도움말에 Infobox person i에 대한 링크를 추가하여 두 템플릿을 쉽게 동기화

미래

Wikidata 편집/업데이트에 연결하도록 Wikidata 템플릿 향상(값 팝업 또는 Wikidata 페이지 링크 편집)

• 지원 ··마노스해커 18:59, 2015년 7월 27일 (UTC)[응답]
• 이것이 어떤 식으로든 선택되지 않는 한 강력히 반대한다.p[검토 모드]에서 인포박스로의 변경을 검토할 때, 내가 신뢰하지 않고 기사에 사용되지 않을 데이터로 가득 찬 제2의 인포박스로 어수선해지는 것을 원치 않는다.더 중요한 것은 wikidata(대부분 아웃 에디터)에 대해 들어본 적이 없는 편집자가 미리보기 모드를 사용할 때, 실제 기사 화면과 상당히 다르게 의도적으로 만들어진 미리보기를 보지 말아야 한다는 점이다.미리 보기는 편집 후 기사가 어떤 모습일지 미리 보기 위한 것이다.이러한 디스플레이를 명시적으로 원하는 편집자만이 설정하며 미래의 편집자를 혼동할 수 없는 일부 설정이나 파라미터에 대한 대응을 제외하고 편집 후 표시되지 않을 데이터를 표시하는 것은 미리보기 남용이다.DES 16:26, 2015년 7월 30일 (UTC)[응답하라]
• 반대 DES 반대는 근거가 충분하다.WP는 wikidata가 필요로 하는 모든 분야를 추가해야 한다.현재의 Infobox에 대한 합의.만약 그것이 이루어질 수 없다면 아마도 개인 데이터가 더 이상 사용되지 않았어야 했다.마넷D톡 19:38, 2015년 7월 30일 (UTC)[응답]

시행될 경우 선택 사항일 것이며 사전 선택되지 않을 것이라는 것은 의심할 여지가 없다.그것은 사람들을 혼란스럽게 하는 것이 아니라 오류를 확인하는 것을 돕기 위해 만들어졌다.그것을 선택적으로 만드는 것은 내가 현재 알고 있는 것 이상으로, 경험 많은 사용자가 이 문제에 대해 우리를 도울 수 있을 것이다.···마노스해커 21:06, 2015년 7월 30일 (UTC)[응답]

템플릿의 정상적인 사용에 과도한 부담을 주지 않는 한, 시험을 위한 엄밀히 선택 가능한 기능에는 이의가 없다.그러나 이러한 선택적 버전이 샌드박스로 만들어지기 전에 이 제안은 정말 논의할 준비가 되어 있는가?만약 우리가 원칙적인 기준으로 논의한다면, 나는 이것을 사용할 것이라고 기대하지 않을 것이다. 하지만 만약 그것이 디폴트가 아니라 선택 사항이고, 매우 빈번한 템플릿의 정상적인 사용에 상당한 비용을 부과하지 않는다면 반대하지 않을 것이다.위의 논의는 이것이 항상 켜져 있거나, 기본적으로 켜져 있을 것임을 암시하는 것으로 들렸다.DES^(talk) 21:28, 2015년 7월 30일 (UTC)[응답하라]

그리스어 위키백과에서 위키다타는 자동으로 인포박스를 채우며 손으로 인포박스 항목을 채우는 것만으로 오버리디할 수 있다.결과는 혼합된 infobox 렌더로 사람들은 혼란스러워한다. wikidata 값이 다른 색으로 렌더링되거나 아이콘 (-)이 사용되지 않는 한.나는 거기에 기본적으로 듀얼 인포박스를 사용할 것이다.영어 위키피디아는 다른 접근방식을 가지고 있으며 이중 인포박스는 여기서 선택적으로 유지되어야 한다.···마노스해커 22:40, 2015년 7월 30일 (UTC)[응답]

직접적으로 잘 작동하는 것 같지만, 이 템플릿들 또한 그것을 부르고 우리는 거기서도 그것을 확인해야 할 것이다.일부 전문가는 시스템에 부담이 되는지 확인하기 위해 테스트를 실행할 수 있으며, 위키디타를 가져오는 것은 사용 가능 여부를 선택하는 사람들과 미리 보기 중에만 해당될 수 있다.···마노스해커 22:32, 2015년 7월 30일 (UTC)[응답]

• 지원, 세부 사항 중 악마는 제외한다.이와 같은 선택적 도구가 유용할 것이다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ 22 22 22^ʌ 22:_ᴥ51, 2015년 8월 3일 (UTC)[응답]

템플릿이 다른 템플릿 내에서 중첩되어 작동하는지 확인하기 위해 확인이 완료되었으며 제대로 작동하는지 확인하십시오.템플릿:Infobox artist Ⅱ가 생성되는데, 여기서 Infobox person Ⅱ를 부른다.미리보기: Caravaggio, 생년월일을 수정해야 한다는 것을 밝힌다.···마노스해커 09:50, 2015년 8월 6일 (UTC)[응답]

@DESiegel, MarnettD, Frietjes, Plasticikspork, Mr. Stradivarius, Jackmcbarn, and Magioladitis:3주 이상(마이클 잭슨에는 이미 34개의 개정판이 있다), 오류 없이 인포박스 아티스트(Caravaggio)와 같은 다른 템플릿 안에 내포되어 있는 작품들, 무겁지 않고 선택 사항일 것이다.업데이트하십시오.···마노스해커 03:12, 2015년 8월 14일 (UTC)[응답]

커뮤니티 포털은 고도로 인용된 여성 과학자들의 실종에 대한 기사 작성을 장려해야 하는가?

위키백과에서 RFC를 참조하십시오.커뮤니티 포털#기사들이 없는 여성 과학자들을 많이 인용했다.EllenCT (대화) 2015년 8월 14일 15:16 (UTC)[응답]

위키피디아에는 다음과 같은 섹션이 있다.위키프로젝트 누락 백과사전 기사/톰슨-로이터가 가장 많이 인용한 것은 과학자들#실종 여성 과학자들이다.찬양(대화) 20:54, 2015년 8월 14일 (UTC)[응답]

대상 및 원본 제목 아래에 모두 이동 로그 항목 등록

현재 페이지를 이동할 때 이동은 원본 제목에 대한 이동 로그에만 등록되고 대상 제목에는 등록되지 않는다.이 때문에 과거 반복적으로 옮겨온 페이지의 역사를 재구성하기 어렵다.예를 들어 이동 전쟁에서 한 페이지가 반복적으로 두 장소 사이를 이동했다면, 이 이야기의 절반만 이동 로그에 어떤 제목에 대해 기록된다.(물론 이동 로그 항목도 편집 내역에 미러링되지만, 여러 페이지의 정상적인 편집 내역에 의해 서로 분리될 수 있기 때문에 찾기가 상당히 어려울 수 있다..)

단순히 이동으로 대상 위치의 로그와 원본 위치의 로그에 한 페이지씩, 두 페이지 로그 항목이 동시에 생성된다면 그러한 이력을 따르는 것이 훨씬 쉬울 것이라고 나는 종종 생각해 왔다.이런 식으로, 어떤 제목에 대한 이동 로그는 페이지가 어디로 갔는지 뿐만 아니라, 페이지가 어디서 왔는지도 기록할 것이다.Fut.Perf. ☼ 07:33, 2015년 8월 13일 (UTC)[응답]

네.우리는 더 이상 잘못된 수정사항을 숨기기 위해 이동 및 삭제 작업을 사용하지 않는다(revdel 이전과 감독 전, 선택적 삭제, 복원 및 이동을 사용했으며, 관리자에 대해서도 사후 파악이 어렵다).이동사를 쉽게 추적할 수 있다는 것은 내가 생각할 수 있는 단점이 없으며, 기사의 역사에 대한 어떤 종류의 연구도 훨씬 덜 고통스럽게 만들 것이다.—쿠스마 (t·c) 08:40, 2015년 8월 13일 (UTC)[응답]

• 지지하다.이것은 상황을 훨씬 더 쉽게 만들 것이다. 특히 높은 트래픽 페이지에서 어디로 이동했는지를 찾으려고 하는 것은 종종 악몽이다.나는 또한 Special:을 사용하여 역사 병합에도 동일한 작업을 수행할 것을 권고하고 싶다.MergeHistory, 현재 로그 항목은 원본 위치에만 남겨두고 목적지는 남겨두지 않는다.젠크스24 (대화) 2015년 8월 13일 (UTC) 12:26 (답변)
• 반대 대신, 두 개의 텍스트 상자를 두십시오. 하나는 이전 제목이고 다른 하나는 새 제목입니다.두 항목 모두 비어 있지 않으면 로그에 이전 제목 텍스트 상자에 넣은 항목에서 새 제목 텍스트 상자에 넣은 항목까지의 모든 이동이 표시된다.둘 중 하나가 비어 있으면 로그에 이전 제목 텍스트 상자에 넣었던 동작 또는 새 제목 텍스트 상자에 넣었던 동작 중에서 비어 있지 않은 동작으로 모든 동작이 표시된다.둘 다 공백이면 로그에 모든 이동이 표시된다.제프리T2000 (토크) 14:01, 2015년 8월 16일 (UTC)[응답]
  • 그것은 틀림없이 우아할 것이다. 문제는 그것이 얼마나 구현하기 어려울 것인가이다.내가 잘못 알고 있는 것이 아니라면, MediaWiki는 현재 로그 항목이 무엇인지에 대해 다소 엄격한 내부 개념을 가지고 있다. 모든 유형의 로그에서 항상 하나의 수행자와 영향을 받는 대상(사용자 또는 페이지)을 포함한다.현재 이동 시 "영향" 필드에 저장되는 것은 소스 위치로서, 대상 위치는 요약에만 언급되어 있다.두 개의 별도 로그 항목이 없는 경우, 귀하의 제안은 데이터베이스에 로그 항목의 내부 표현을 재설계하거나(동일한 로그 항목에 두 개의 영향을 받는 대상을 허용) 로그 항목을 검색 및 필터링하는 새로운 메커니즘(대상 필드가 아닌 요약 텍스트 분석)을 요구할 수 있다.단순히 두 개의 로그 항목을 동시에 작성하는 것이 가장 저렴한 방법이 될 것이다.Fut.Perf. ☼ 14:24, 2015년 8월 16일 (UTC)[응답]
• 지원 유용한 기능.아이스블록 (토크) 2015년 8월 16일 (UTC) 15:01, 응답

WP에서 "크리크"를 식별하기 위한 도구

(여기가 맞는지 모르겠다)최근 양말을 신어 좋지 않은 경험을 한 후(감사하게도 많은 양말이 막혔다) 이런 생각이 들었다.특정 영역에 편집자를 분석할 수 있는 도구가 있는가?나는 WP에 유용할 수 있는 "기울기"를 식별하기 위한 몇 가지 매우 간단한 기준을 생각할 수 있었다.SPI 및 심지어 더 일반적인 목적.두 가지 쉬운 기준은 다음과 같다.

• X는 RfC/AfD에서 Y와 동의한다!otes 등은 X를 Y와 연관시킨다.
• 기사를 Y에 의한 버전으로 되돌리는 X는 X를 Y와 연관시킨다.(반복하는 것은 사람을 향한 것이 아니라 사람을 "반대"하는 것으로 되어 있지만, 나는 이것을 모델로 하는 쉬운 방법을 생각할 수 없었다.

그런 다음 다양한 편집기의 그래프를 만들고 일종의 군집화를 수행할 수 있다.그 기준은 전혀 틀리지 않지만, 나는 그들이 괜찮은 출발이 될 것이라고 생각한다.다른 비슷한 기준들을 생각할 수 있는데, 아마도 무게가 더 적거나 더 나간다.킹신디안 ♝ 11:43, 2015년 8월 14일 (UTC)[응답]

나는 이것이 그렇게 좋은 생각이라고 생각하지 않는다.만약 당신이 투킹이 의심된다면, 당신은 스스로 증거를 찾을 수 있을 것이다.이것은 낚시 탐험을 장려할 것으로 보인다.비블브록스 (대화) 22:40, 2015년 8월 14일 (UTC)[응답]

응, 내 생각도 그래.어느 정도는 잘못된 긍정을 많이 낳고 그에 따라 학대를 할 수 있도록 보장된다. 누군가를 괴롭히고 싶다면, 그 패거리 탐지기를 실행한 다음 결과를 보고하라.그러한 테스트가 우연히라도 어떤 종류의 '증거'를 제공하는 것은 다소 불가피하며, 예를 들어 AfDs에서 다른 누군가와 동의하는 것은 유사한 주제에 대한 관심 이상의 어떤 것도 나타내지 않을 수 있고, 위키백과 정책에 대한 올바른 이해를 나타낼 수도 있다.Andy TheGrump (talk) 22:50, 2015년 8월 14일 (UTC)[응답]

나도 그것이 좋은 생각인지는 잘 모르겠지만, 어떻게 그것이 학대에 개방될 수 있을지는 모르겠다.그것은 WP에 존재하는 편집자 상호 작용 도구와 같은 도구일 뿐이다.SPI. 두 사람이 같은 페이지를 편집한다고 해서 양말이 되는 것은 아니다, 여기서도 같은 원리가 적용된다.킹신디아ian 02:47, 2015년 8월 15일 (UTC)[응답]

아마도 당신은 이 도구가 무엇을 감지해야 하는지를 명확히 해야 할 것이다.출력은 무엇이며, 출력은 무엇으로 예상하십니까?Andy TheGrump (talk) 03:26, 2015년 8월 15일 (UTC)[응답]

이것은 내 마음으로는 좀 애매하지만, 입력은 단순히 관심 영역일 뿐이다.예를 들어, 나는 WP에서 많은 일을 한다.ARBPIA. 그런 다음 해당 지역에서 작업하는 사용자 집합을 보고, 위에서 설명한 방법에 따라 사용자 간에 연결을 만드십시오.그런 다음 클러스터링하면 출력이 클러스터가 된다.킹신디안♚ 03:32, 2015년 8월 15일 (UTC)[응답]

그래, 틀림없이 클러스터가 생길 거야.입력 데이터가 완전히 랜덤이면 클러스터가 생성될 겁니다.하지만 우리는 그것이 아니라는 것을 안다.WP에서 편집하는 많은 사용자:ARBPIA 영역은 공통적인 관점을 가지고 있다.아마도 당신은 '친이스라엘' 클러스터와 '친팔레스타인' 클러스터를 발견할 것이다. 사실, 나는 당신이 그렇지 않았다면 매우 놀랐을 것이고, 아마도 그 도구가 고장 났다고 제안할 것이다.하지만 뭐 어때?그것은 여러분이 이미 알지 못했던 어떤 것도 말해주지 않는다 - 논쟁적인 주제에 관한 한, 다른 관점을 지지하는 사람들이 있다는 것이다.당신이 한 모든 것은 동의하는 사람들을 연결시키는 것이다.그리고 다른 사람과 동의하는 것은 위키백과 정책에 반하는 것이 아니다.그래서 당신은 출력 데이터를 무엇에 사용할 것을 제안하는가?Andy TheGrump (talk) 03:59, 2015년 8월 15일 (UTC)[응답]

솔직히 말해 무엇에 쓰고 싶은지 막연하게만 알고 있을 뿐이다.위에서 말했듯이, 나는 여기가 이 제안의 적절한 장소인지 잘 모르겠다.나는 주로 이런 일을 해본 사람이 있는지 관심이 있었다.SPI에서 유용할 수도 있다는 막연한 생각에서.또 재미있는 실험으로.킹신디안♝ 04:05, 2015년 8월 15일 (UTC)[응답]

필요한 모든 데이터가 공개적으로 이용 가능하다는 점을 감안하면 적어도 실험하는 사람을 막을 수 있는 이론적인 것은 아무것도 없다.SPI에 사용하는 것에 대해서는, 그것은 오히려 Beeblebrox가 암시했던 낚시 탐험을 암시한다.SPI는 특정 계정이 서로의 양말이라고 의심할 만한 타당한 근거가 있을 때만 실시하도록 되어 있다. 즉, 무엇이 나왔는지 확인하기 위해 '클러스터'를 제출하는 것은 다소 의심스러운 일이다.내가 직접 몇 개의 SPI를 개설했는데, 당신이 일반적으로 계좌를 연결하는 구체적인 디프피를 제공해야 한다는 것을 알고 있고, 그들이 어떤 식으로든 좋지 않다는 것을 암시하고 있다.이것은 종종 어떤 프로그램도 감지할 수 없는 행동의 단서를 발견하게 된다.그리고 그 도구가 유용할 것인가에 대한 아주 간단한 질문 외에도, WP는 다음과 같은 문제도 있다.이전에 아무도 의심하지 않았던 편집이 체계적인 대량 검사를 받을 때 AGF는 다소 소홀해지고 있다.나는 우리의 기여자들이 그것에 만족할지 잘 모르겠다.Andy TheGrump (talk) 05:36, 2015년 8월 15일 (UTC)[응답]

앤디에게, SPI는 실제로 어떤 행동 증거들이 가능한 한 이미 확립되어 있는지를 확인하는 것이다.그리고 행동의 증거는 단지 같은 기사를 편집하는 것 이상이다.예를 들어, 서로 싸우고 서로 조롱하기 위해 따라다니는 두 사람이 같은 기사를 편집하는 것으로 끝날 수도 있다.어떤 사람은 그들을 단지 서로 싸우고 있는 편집 전사로 즉시 인식하게 될 것이다. 그러나 당신이 제안한 도구는 양말과 같은 사람들을 속일 것이다.SPI는 행동에 근거하여 우리가 어떤 2차 계정(sock)으로 의심하며, 우연적인 이해관계를 일치시키는 것 외에는 그러한 행동 증거가 존재하지 않는 양말을 찾는 어업 탐험에는 적합하지 않다고 의심하는 것에 대한 2차 확인으로서 되어야 한다. --Jayron32 06:00, 2015년 8월 15일 (UTC)[응답]

@Jayron32: 나는 네가 그 도구가 무엇을 해야 하는지를 이해했는지 잘 모르겠다.당신이 준 예에서, 그 도구는 "그 사람들을 양말처럼 태그하지 않을 것이다" (그 도구는 누구를 양말처럼 태그하지 않는다), 또한 두 사람을 같은 집단에 놓지도 않을 것이다.

@AndyTheGrump: 이것은 SPI 케이스에서 디프를 주는 것을 대체하기 위한 것이 아니며, 편집자 상호 작용 도구가 그렇게 하지 않는 것처럼 낚시로 이어지지 않는다.이것은 조사/분석 도구로 사용될 가능성이 높으며, 그 이상도 아니다.어쨌든, 나는 그러한 도구를 쓰는 것이 얼마나 어려울지에 대한 기술적인 세부사항을 확인할 것이다.킹신디안 ♝19:21, 2015년 8월 15일 (UTC)[응답]

몇 년 전만 해도 그 선들을 따라 적어도 하나의 도구가 존재했다; 나는 그것이 여전히 작동하는지 모르겠다.그것은 어떤 두 명의 명명된 계정이라도 편집한 페이지의 목록을 만들었다.하지만 의심스러운 양말의 이름을 직접 알려야 했다.또, (컴퓨팅 자원의 측면에서) 「비용」이라고 생각했기 때문에, (단순한 암호 보호를 통해서) 모든 사람이 이용할 수 있는 것은 아니었다.WhatamIdoing (대화) 03:37, 2015년 8월 15일 (UTC)[응답]

사용자:WhatamIdoing:"위키스토크"라는 이 도구는 모든 사람들이 이용할 수 있었다. 나는 그것을 CU 케이스를 만들기 위해 많이 사용했다.불행히도 지금 쓰러졌다.나는 그것이 다시 올라오는지 물어보았다.

또 다른 흥미로운 대안은 User_talk에서 논의된다.Philipe_(WMF)#Blocking_tools.IP 대신 차단장치는 내게도 큰 의미가 있다(이스라엘/팔레스타인의 극도로 양말을 많이 쓰는 지역에서 편집한다) 훌드라(토크) 23:11, 2015년 8월 16일 (UTC)[응답]

여러 개의 불명확한 링크로 기사 목록을 지우는 드라이브를 해봅시다.

디스큐레이터들의 부지런한 노력 덕분에 페이지에 3개 이상의 디스큐 링크가 있는 기사 목록이 최근 처음으로 1,000개 아래로 떨어졌고, 현재는 850개(이 중 일부는 이미 고쳐져 있고, 페이지는 매일 업데이트된다)에 그친다.이제 전체 목록이 이 페이지에 들어맞는다.즉, 84명의 위키피디아 사람들을 각각 12페이지씩만 고치면 리스트는 완성된다는 겁니다.이렇게 합시다.건배! bd2412 T 14:16, 2015년 8월 5일 (UTC)[응답]

잘했어, BD2412 (그리고 다른 모든 방해꾼들)12번 다 했어.라이스 더 가이 08:52, 2015년 8월 6일 (UTC)[응답하라]

나는 12개의 --S Philbrick (Talk) 17:07, 2015년 8월 7일 (UTC)[응답]을 했다.

나는 몇몇 부분만 했다. - 몇몇은 천천히 진행되었다.사용자 지정:DerUhrmacher는 현재 높은 점수인 유명한 시계 제작자들의 연대순 리스트를 정리한다.그들이 거의 전체 기사를 썼기 때문에(그리고 최근에!), 그들은 모든 DAB 링크가 어디로 가야 하는지를 알 수 있는 가장 좋은 위치에 있다.위에 열거한 툴은 상당히 빨리 만들어야 한다 :) 시멘틱맨티스 (토크) 22:23, 2015년 8월 11일 (UTC)[응답]

지금은 700페이지도 안 돼. 각각 12페이지씩 하는 60명의 위키피디아 사람들이 바로 청소할 거야!또는 120명의 위키피디아가 각각 6장씩 정리. bd2412 T 16:42, 2015년 8월 17일 (UTC)[응답]

모바일 웹에 대한 기사 표시 제안

안녕하십니까, 여러분.

기사의 리드 부분을 모바일 웹에 어떻게 표시할 수 있는지에 대한 설계 변경 제안이 있다.변화의 합리적이고 구체적인 내용은 미디어위키 페이지에 자세히 나와 있다.확인 후 제안사항을 토론 페이지에 추가하십시오.고마워 --멜라마로이 (WMF) (토크) 22:42, 2015년 8월 17일 (UTC) :-][답답장]

"위키피디아 트레크스 칼린디 칼"에 대한 지지 요청

친애하는 위키피디아 사람들에게
인도 콜카타에서 인사말.
2015년 9월 '위키피디아 트렉스 산'에 '위키피디아 트렉스 칼린디 칼'이라는 탐험 프로젝트를 기획할 예정임을 알려드리게 되어 기쁘다.
이것은 위키백과, 커먼즈, 윅스페아, 위키보야게 등 WMF의 모든 언어판을 대상으로 한 인도 가르왈 히말라야 지역의 강고트리에서 바드리나트까지 고공 트레킹 원정이다.위키백과 트레크스 칼린디 칼의 전반적인 목적은 위키미디어 커먼스에서 무료 면허를 받아 히말라야 산맥과 관련된 자료를 늘리고, 품질을 향상시키고, 위키백과에서 히말라야 산맥과 그 외 각각의 다양성을 다양한 언어로 다양화하는 것에 관한 기사의 양을 늘리는 것이다.이 트레킹 프로그램을 진행하는 동안 히말라야 산맥의 대부분에 도달하는 것은 다양한 지역 사회 장들의 인식을 높일 뿐만 아니라, 그들이 위키미디어 프로젝트에 기여하도록 동기를 부여하고 미래에 이런 종류의 트레킹 원정을 조직할 것이다.
이 독특한 프로젝트에 대한 여러분 모두의 서명이 필요하다.

토론 페이지에서 프로젝트에 대해 자유롭게 토론하십시오.
미리 고맙다
따뜻한 안부를 전하며,
수제이25 (토크) 2015년 8월 18일 (UTC) 20:08 [응답]

파일 업로드 마법사 수정

현재 WP 사용 시:파일 업로드 마법사, "현재 증거를 확보하지 못했지만 요청하면 일부 정보를 제공할 것" 옵션을 사용하여 다른 사용자의 작업을 업로드할 수 있다.이게 무슨 소용이야?그것은 업로드 패트롤러가 그것을 알아차리지 않고 우리에게 검증되지 않은 파일만 가지고 있다고 요구하지 않는 한 말이다.게다가 라이선스가 제공된다고 하니 ImageTagingBot에 걸리지 않는다.내 생각에는 의심스러운 업로드를 위한 뒷문이 생기는 것을 막기 위해 이 옵션을 제거해야 한다.사실상 이는 그들이 이행하겠다고 밝힌 요청을 즉각적으로 하는 것일 뿐이다.이것을 어떻게 할 것인가에 대한 의견?베스노우트 (대화) 2015년 8월 19일 (UTC) 14:17[응답]

그 인용문은 몇 페이지에 있니?나는 그것을 찾을 수 없었다.알란스코트워커 (대화) 2015년 8월 19일 (UTC) 14:54 [응답]

'이것은 무료 작업이다'를 클릭한 다음 '이 파일은 소유자가 준 것이다'를 클릭하면 업로드 양식에 '지금 당장 증거를 확보하지는 못했지만 요청하면 일부 제공하겠다'는 텍스트가 나타난다.이러한 경우 실제 업로드에 나타나는 것은 "증거: 요청 시 제공된다"이다.이 문제는 가장 최근 위키백과 강연에서 마법사의 토크 페이지에서 반복적으로 논의되었다.파일 업로드 마법사/아카이브 2#증거: 요청 시 제공되며 위키백과 대화:파일 업로드 마법사/아카이브 3#무단으로 너무 많은 이미지를 통과하도록 허용. 이 이미지에는 (툴의 원래 작성자로서) 왜 넣었는지에 대한 내 설명도 포함되어 있다.Fut.Perf.☼ 15:03, 2015년 8월 19일 (UTC)[응답]

너는 우울할 정도로 실용적인 주장을 한다.설명해줘서 고마워.내 제안이 철회된 것을 생각해봐.BethNaught (대화) 22:09, 2015년 8월 19일 (UTC)[응답]

(본 페이지와 관련된 기술적 문제 발생 ??)

다음 섹션을 최소화할 때 다음 5개 섹션은 표시되지 않는다.소시브르 (대화) 2015년 8월 20일 (UTC) 10시 18분 [응답]

모바일 버전SoSivr (talk) 10:23, 2015년 8월 20일 (UTC)[응답]

템플릿 깨짐

(Lua Module Module:break를 사용하는 템플릿 {{break})내 의견으로는

{{break 0}}

ZERO 라인 파손을 생성해야 하며, 단 하나의 라인 파손(여기에 표시됨)이 발생하지 않아야 한다.소시브르 (대화) 2015년 8월 20일 (UTC) 10시 54분 [응답]

템플릿 토크에서는 다음과 같이 하는 것이 더 나을 것이다.브레이크. Eman235/토크 19:29, 2015년 8월 20일 (UTC)[응답]

RfC: 템플릿 적용:영어 변종 알림은 더 이상 사용되지 않는가?

템플릿 날짜

아마도 {{date} 템플릿도 확장되어 요일을 출력할 수 있을 것이다.소시브르 (대화) 09:59, 2015년 8월 20일 (UTC)[응답]

그것은 계산될 필요가 있을 것이다.칭찬 (대화) 2015년 8월 20일 19시 40분 (UTC)[응답]

(적어도 우리 편은) 아닐 것이다.템플릿:Date는 {{#time} 파서 기능을 사용하며, 이 기능은l요일 옵션:{{#time:l now}}→ 화요일.따라서 그것을 포함한 추가 포맷 스타일을 쉽게 추가할 수 있다.SiBr₄ (대화) 2015년 8월 20일 19:56, (UTC)[응답]

나는 개인적으로 {{date}}}에 접근할 수 없기 때문에 나 혼자서는 더 이상 할 수 없었을 것이다.템플릿에 대한 액세스 권한을 가진 사용자는 관련 옵션을 추가하고 문서에 포함할 시간을 찾을 수 있다.하지만 이 정보는 꽤 유용했으니까, 고마워.소시브르 (대화) 2015년 8월 21일 (UTC) 14:12, 응답

권장되는 행동 방침은 템플릿 토크에서 토론을 시작하는 것이다.추가할 수 있거나 추가해야 하는 정확한 형식을 결정하고 템플릿의 샌드박스에 구현하기 위한 날짜.그런 다음 {{editprotected}}}을(를) 사용하여 동일한 대화 페이지에서 실제 템플릿의 변경을 요청할 수 있다.SiBr₄ (대화) 2015년 8월 21일 (UTC) 20:27 [응답]

리디렉션 없이 자체 페이지 이동

안녕, 이 주제는 약 1년 전에 여기서 논의되었어.현재 "압축 간접"은 사용자 공간에서 사용자들을 위한 것이 아니다.나는 너에게 묻고 싶다. 나는 나를 지지할 것이다. 나의 봇은 요청당 페이지를 옮길 수 있다. 현재 독일어 위키백과에서 실행되는 프로그래밍을 할 수 있다. 그리고 만약 당신이 나를 커뮤니티에서 지원한다면, 나는 또한 그 대본에 대한 승인 요청 후에 이 위키에서 이것을 가능하게 할 수 있다. 그러나 먼저 나는 여기서 너에게 묻고 싶다.자세한 내용은 다음과 같다.봇은 사용자가 요청할 수 있는 대기열을 관리하는데 다음과 같은 데이터가 필요하다.페이지의 오래된 티텔, 새로운 티텔, 그리고 요청된 이동의 이유.봇은 다음과 같은 이유로 움직일 것이다.Bot: (사용자 이름), 이유: (이유)의 요청에 따라 페이지 이동(Username)은 요청자의 사용자 이름이며, 사용자가 자동으로 기입하고, (이유)이유에 의해 주어진 사유에 해당한다.남용을 방지하려면:

• 봇은 자신의 사용자 공간에서 페이지만 이동함
• 봇이 기본 사용자 페이지 또는 단일 대화 페이지를 이동하지 않음

봇은 당신의 요청이 있은 후 10-20초 후에 페이지를 이동할 것이며, 페이지 이동이 성공적이었으면 메시지를 남기게 될 것이다.그렇지 않다면, 그는 당신에게 더 자세한 내용을 담은 오류 메시지를 준다.이러한 메시지를 원하지 않는 경우:블랙리스트에는 모든 메시지를 잠재우기 위한 내용이 있고, '이동이 성공적'이라는 메시지만 잠재우기 위한 블랙리스트가 있어, 만약 이 조치가 성공적이지 못했다면, 그는 당신에게 메시지를 보낸다.그러니 그 기능에 대한 너의 시력을 나에게 줘라, 만약 네가 이것을 지지한다면, 나는 유인원에 대한 요청을 할 것이다.안녕하십니까, Luke0815 21:30, 2015년 8월 12일 (UTC)[응답]

• 내가 그 아이디어에 대해 아무런 문제가 없지만(사실 좋은 아이디어인 것 같다), 봇은 리디렉션을 억제하기 위해 관리 플래그를 가질 필요가 있지 않을까?너는 이 프로젝트의 관리자가 아닌 것 같고, 내가 마지막으로 확인한 바로는, BAG는 관리자들이 관리 깃발을 들고 봇을 실행하게 할 뿐이다.젠크스24 (대화) 21:36, 2015년 8월 12일 (UTC)[응답]

@Jenks24:봇은 또한 권리의 억제 간접도 가지고 있다, 여기를 보라. (내 봇은 이미 여기에 봇플래그를 가지고 있다.)안녕하십니까, Luke0815 11:36, 2015년 8월 13일 (UTC)[응답]

흥미롭군, 그건 몰랐어.그게 내 유일한 걱정거리야 기꺼이 지지해줄게젠크스24 (대화) 2015년 8월 13일 12시 23분 (UTC)[응답]

• 강력한 지원:이것은 반드시 실행되어야 한다.누구나 관리자(admin)에게 남겨진 리디렉션을 제거하도록 요청하지 않아도 자신의 샌드박스를 기사로 옮길 수 있고, 리디렉션 없이 마음대로 샌드박스 이름을 바꿀 수 있어야 한다.이것을 활성화하는 좋은 이유가 여기에 있다. 템플릿 사용자 샌드박스는 이 터치로 완벽해질 것이다.사용자 샌드박스 리스트에 남겨진 리디렉션들이 숨겨져 있더라도 아예 만들어지지 않았다면 훨씬 나을 것이다.···마노스해커 21:52, 2015년 8월 12일 (UTC)[응답]

• 큰 문제는 아니지만, 주 사용자 페이지나 주 사용자 대화 페이지를 이동시키지 않는다면, 그것이 의도된 것인지 아닌지 확실하지 않다면, 나는 이것을 지지하지 않을 이유를 알 수 없다.만약 그것을 "소유"하기 위해 관리자가 필요하다면, 나는 우리가 자원봉사자를 찾을 수 있다고 확신한다.비블브록스 (대화) 23:21, 2015년 8월 12일 (UTC)[응답]

• 지원 이것은 관리자와 사용자 모두의 삶을 더 쉽게 만들 것이다.~ ONUnicorn^{(Talk Contribs)} 문제해결 00:34, 2015년 8월 13일 (UTC)[응답]

• 지원 - 일반적으로 이 봇이 취급하는 경우에 리디렉션이 존재하거나 존재할 필요는 없다.—Godsy^(TALK_CONT) 07:20, 2015년 8월 13일 (UTC)[응답]

리디렉션으로부터 사용자 페이지를 자유롭게 해달라는 요청은 미디어위키에서 2015년 4월부터 논의되기 시작했다.루크의 부탁에 덧붙인 것은, 내가 알고 있는 바와 같이, 누구라도 리디렉션을 남기지 않고 사용자 서브 페이지(자신의 서브 페이지뿐만 아니라)를 이동할 수 있어야 한다는 것이다.어떤 사용자라도 이와 같은 조치를 취할 수 있기 때문에 이에 대한 추가가 필요하다. 영향을 받은 사용자는 봇의 메시지보다 더 많은 알림을 받아야 한다.···마노스해커 08:12, 2015년 8월 13일 (UTC)[응답]

사용자에게 이 가능성을 알려주고 싶다면, sysop이 페이지 이동을 위해 mediawiki 메시지를 편집할 수 있으므로 이동할 수 있는 모든 사용자가 이 가능성을 볼 수 있다.봇의 메시지는 봇이 요청을 완료하려고 할 때에만 전달된다.안녕하십니까, Luke0815 11:41, 2015년 8월 13일 (UTC)[응답]

그래, 미안, 네 코멘트를 잘못 이해했어.나는 처음에 자신의 하위 페이지를 옮기는 것이 더 낫다고 생각한다. 그래서 그것은 문제가 아니라 내 관점을 형성하는 것이다.다른 사용자 하위 페이지를 이동하면 공공 기물 파손의 위험이 있다.내 생각에는 봇 요청 페이지는 반단백이어야 하므로 사용자가 아직 움직일 수 없는 봇당 움직일 수 없다.안녕하십니까, Luke0815 13:27, 2015년 8월 13일 (UTC)[응답]

토론은 이제 끝났는데 (하지만 나 말고는 아직 이 사이트를 7일 이후 편집한 사람이 없으니 한마디만 해 줘.) 안녕하십니까, Luke0815 20:35 (UTC) 2015년 8월 21일 (UTC)[응답]

RfC: "demonym미국인"

기사 제목에 관해서는, 「다중화」를 할까.demonym "미국인" (한국계 미국인과 중국계 미국인을 제외) 또는 특이화"demonym 아메리칸" (Exempli gratiaAfrican American)?아니면 케이스 바이 케이스별로 해볼까? --George Ho (토크) 20:20, 2015년 8월 21일 (UTC)[응답]

지금까지는 문맥이 그 문제를 결정해야 할 것 같다.'한인 미국인'은 복수명사지만 '아프리카계 미국인'은 형용사가 될 수 있다.제 말이 무슨 말인지 알겠어요?

이것은 어떤 특정한 문제를 해결하기 위한 것인가?이것에 대해 편집 전쟁이 있었는가?다크프로그24 (대화) 2015년 8월 22일 18시 12분 (UTC)[응답]

(숨겨진) 단서는 OP가 기사 제목만 이야기한다는 것을 암시하는 기사토크 페이지 링크에 있다고 생각한다.아프리카계 미국인과 한국계 미국인의 불일치에 주목하라.-맨드러스 인터뷰 18:29, 2015년 8월 22일 (UTC)[응답]

명확성을 위해 OP 변경. --George Ho (토크) 12:43, 2015년 8월 23일 (UTC)[응답]

• WP별 기사 제목 복수화:복수형 및 WP용:비미국 관련 인종 집단과의 일관성 – 이와 같은 미국 집단은 특출한 것이며 WP에 따라 표준화되어야 한다.다원. 이 기사의 주제는 단어 자체가 아니라 사람들의 그룹이다.그 단수는 그 기사에 대한 잘못된 인상을 준다.RG루스터 — ▷인터뷰 19:10, 2015년 8월 22일 (UTC)[응답]
• WP에 따라 복수화:다원.--먹어줘, 난 팥 12:49, 2015년 8월 23일 (UTC)[응답]
• 의견 - 이 RM이 가까울수록 상충되는 지침이 언급되고, 이 RM이 가까울수록 동일한 충돌을 암시한다.조사해 보지는 않았지만, 그들의 말을 믿겠다.나는 보다 나은 접근방식이 구체적인 갈등을 식별하고 직접 해결하도록 노력하는 것이라고 보고 싶다.이것은 갈등조차 인정하지 않는 이 RfC에서는 이루어지지 않고 있다.-맨드러스 인터뷰 19:18, 2015년 8월 23일 (UTC)[응답]
• 논평 – ... 하지만 "아프리카계 미국인"은 형용사가 될 수 있다.그렇다면 '아프리카계 미국인'이 아닐까.nyuszika7h (대화) 2015년 8월 23일 22:41, (UTC)[응답하라]

응. 형용사로는 "아프리카계 미국인"이지만 명사로는 "아프리카계 미국인"이야.MOS:HYPHEN. RGlucester 참조 — 인터뷰 22:01, 2015년 8월 24일 (UTC)[응답]

FA/GA 지명

여기에 불문율이 있다: 기사를 개선하기 위해 최대한 편집하는 편집자는 그 기사를 GA/FA에 지명할 권리가 있다.편집이 없는 다른 편집자가 그 기사를 지명하면 그는 화를 낸다.특집 기고자의 토크 페이지에서 그는 GA의 기사를 개선하기 위해 열심히 노력했고 FA 지명을 받고 싶어했지만, 기사가 준비되자 편집이 거의 없는 제3의 사용자가 특집 기사에 기사를 지명했다.나는 그의 마음을 이해할 수 있다.우리는 우리에게 흥미있는 기사를 편집한다.우리는 우리의 개인적인 관심사가 아닌 기사들을 편집하지 않는다.몇 주 전에 새로운 사용자로서 나는 기사를 보았는데, 그것은 보기 좋았다.나는 그것을 GA에 지명했고, 기사를 편집한 다른 사용자가 나를 "당신은 아무런 편집도 하지 않았고, GA에 지명했다"고 협박하기 시작했다.그가 옳았어, 나는 수정하지 않았어.그 기사를 지명함으로써, 나는 그 기사를 개발한 편집자들에게 감사하려고 했다.모든 좋은 기사, 특집 기사의 토크 페이지에는 지명자의 이름이 언급되어 있다.그런 이유로 기사를 개발하는 편집자들은 그것을 지명하고 싶어한다.

그래서 추천 기사와 좋은 기사 토크 페이지에서는 지명자 대신 기사 개발자의 이름을 언급해야 한다고 제안한다.이 모든 논쟁은 중단될 것이다: "나는 기사를 개발했고, 열심히 일했고, 내 소중한 시간을 오류를 고치기 위해 보냈고, 출처를 찾고, 편집했고, 그렇다면 어떻게 그것을 GA/FA에 지명할 수 있는가?" — 112.79.38.40 (토크) 06:19, 2015년 8월 23일 (UTC)[응답]

WP:FAC는 다음과 같이 말한다.기사에 중요한 기여자가 아닌 유목민은 기사의 정기 편집자와 상의한 후 지명을 받아야 한다.한 기사에 복수의 지명자를 허용하지만, 한 번에 두 기사의 공동 지명 기사에 대한 제한이 있어 주요 기고자가 누락되는 경우도 있다.WP의 경우:GAN, 조항은 상당한 기여를 했고 주제에 정통한 것이 매우 선호되지만 누구나 추천할 수 있다.내가 GA에서 일하지 않은 기사를 지명한 주된 이유는 내가 좋은 주제를 만들고 있기 때문이다.호크예7 (대화) 22:42, 2015년 8월 24일 (UTC)[응답]

당신의 코멘트를 읽는 것은, 내가 아무런 기여도 없이 GA에 기사를 지명했을 때, 편집자로부터 학대를 받을 자격이 없었다는 것을 의미한다.

RFA의 잡티 제거에 대한 제안

RFA 개선방안에 대한 토론이 WP에서 나왔다.AN#규칙은 모든 위키백과에 대해 동일해야 하는가?;관련 메시지 복사: — 세바스찬 03:58, 2015년 8월 26일 (UTC)[응답]

@JZG: 스페인 프로젝트와 독일 프로젝트 모두 "투표권"이라고 불리는 것을 확립한다.이것들은 편집자가 RFC와 같은 다른 장소뿐만 아니라 커뮤니티 주도의 토론에 참여할 수 있는 방법과 시기를 결정하는 규칙이다.그것은 절차가 직선 투표인 RFA에 적용되며, 최소한의 토론과 후보 질문은 별도의 페이지에서 수행된다.es.wp에서는 RFA가 14일간, de.wiki가 정족수를 정하기 위해서는 적어도 50표가 있어야 한다.다른 많은 차이점이 있지만 핵심은 우리가 지금 가지고 있는 드라마의 대부분을 없애주는 건성투표에 불과하다는 것이다.내가 볼 때, 만약 어떤 사람이 후보자를 지지하거나 반대하기를 원한다면, 그들은 그 이유를 길게 설명할 필요가 없고, 그들이 그 프로젝트의 투표권 헌장에 따라 그들이 설립되는 한 아무도 그들을 나쁘게 하지 말아야 한다.물론 이 근처에는 투표용지 같은 것은 없고, 그것은 아마도 많은 문제의 근원이 될 것이다.§FreeRangeFrog^croak 23:40, 2015년 8월 22일 (UTC)[응답]

나는 투표권을 공식화하는 것에 동의한다.그러나 설명할 수 없는 투표로 옮겨가는 것은 역행하는 조치일 것이다.나는 Arbcom과 같은 선거에서 설명 없이 누군가를 상대로 투표하는 것을 이해할 수 있다. Arbcom과 같은 선거에서는 선출할 사람이 한정되어 있고 단순히 다른 사람을 선호할 수도 있다.그러나 RFA의 경우, 약점 수에는 제한이 없기 때문에, 만약 누군가가 반대한다면, 그들이 그 후보가 적합하지 않다고 생각하는 이유가 있다는 것을 의미해야 한다.근거를 제시한다는 것은 후보자와 다른 사람들이 그들이 심각한 것을 발견했는지, 오해했는지, 대부분의 유권자들보다 어떤 특정한 속성에 더 신경을 썼는지, 아니면 단지 인신공격을 하고 있는지를 아는 것을 의미한다.!관광객들은 무언가를 오해하는 것이 놀랄 만큼 흔하고, RFA는 그들에게 지적되는 것에 의해 이익을 얻는다.2015년 8월 23일 (UTC) 08:16, 응답하라

그것이 사실일 수도 있지만, 경우에 따라 RFA의 투표 부문은 싸움에 지나지 않는 것으로 전락했다.편집자가 코멘트를 추가하여 투표할 수 있는 섹션이 있다고 할 수 있다.예: 반대 - 근거는 대화 페이지를 참조하십시오.이것은 산성 해설이나 잡동사니를 어지럽히지 않고 RFA 페이지를 비교적 깔끔하게 유지할 것이다.블랙매인 (대화) 02:42, 2015년 8월 25일 (UTC)[응답]

나는 그렇게까지 하지는 않겠지만, 너의 논쟁의 방향은 마음에 든다.내가 선호하는 것은 모든 사람들, 혹은 적어도 "반대"를 표하는 모든 사람들이 편집 요약처럼 간결한 설명을 덧붙이도록 장려되고, 더 많은 것이 필요하다면, 토크 페이지의 섹션에 링크를 추가하는 것이다.이러한 섹션은 주제나 관심사에 따라 라벨을 붙여야 하며, "===__="와 같이 라벨을 붙이면 안 된다.그러한 섹션에 대한 링크가 있는 경우, 이후의 모든 논의는 해당 섹션으로 제한되어야 한다.만약 없다면, 어떤 논평에도 같은 간결+링크 규칙이 적용된다.— 세바스찬 03:58, 2015년 8월 26일 (UTC)[응답]

"설명되지 않은 투표로 이동하는 것은 역행하는 조치일 것이다."농담이지? WSC?75%의 투표 대신 RFA를 토론으로 가장하는 것은 RFA가 독성이 있는 이유다.그것은 정말 그렇게 간단하다.타운레이크 (대화) 2015년 8월 26일 04:10 (UTC)[응답]

뭐가 문제야?예비 관리자들은 봉투를 해야 할 섬세한 꽃인가?비난에 시달리며 시험도 보지 못한 새로 임명된 행정관이 비굴한 편집장을 만나면 어떻게 될까.만약 새로운 행정관이 반대에 부딪혔을 때, 혹은 그들이 연루된 의심스러운 상황에 대해 완전히 설명할 수 없거나 설명하기를 꺼리는 사람으로 밝혀지면 어떻게 될까?조누니크 (대화) 04:26, 2015년 8월 26일 (UTC)[응답]

RFA는 현장 테스트가 아니다.투표다.타운레이크 (대화) 2015년 8월 26일 05:17 (UTC)[응답]

지난 몇 년 동안의 RfA를 보면 "투표"가 아니라는 것을 알 수 있다.위키피디아는 유치원이 아니며, 기고자들이 RfA 페이지에 증거를 올려서 어쩌면 좋은 문제나 나쁜 문제를 강조해서는 안 된다고 제안하는 것은 매우 도움이 되지 않을 것이다.다른 페이지의 깔개 밑에 있는 그런 문제들을 쓸어담는 것은 또 다시 가장 도움이 되지 않을 것이다. 즉, RfA에서 다른 페이지로 문제를 옮기거나 사람들이 중요한 정보를 쉽게 놓치도록 만들 것이다.조누니크 (대화) 2015년 8월 26일 (UTC) 10:09[응답]

RFA를 유독성 난장판으로 만든 태도다.관료들은 비록 그들이 숫자에 근거하여 모든 결정을 내렸음에도 불구하고 투표의 질을 가장한 것에 대해 비난해야 한다. (밀접 투표에서 반대편의 질을 주장하는 '크래프트'들은 반대자들을 난도질하게 만들며, 이는 지지자들로부터 분노를 일으키게 하고, RFA 생활의 순환이다.)다른 위키들이 독성 문제를 가지고 있지 않은 이유가 있다.타운레이크 (대화) 2015년 8월 26일 14시 55분 (UTC)[응답]

독성은 불쾌하고 시간이 많이 걸린다.그것은 또한 몇몇 사람들이 뛰는 것을 막을 수도 있지만, 그것은 나쁜 일이 아닐 수도 있다.화재 시험이 될 수 있다는 요누니크의 지적에 대해 어떻게 대답하는가?— 세바스찬 21:33, 2015년 8월 26일 (UTC)[응답]

반대론자들이 그들의 반대 의견을 취조했기 때문에 둘 이상의 예를 든 지금, 우리는 생생한 RFA를 가지고 있다. 한 경우, 그 후보자는 자신이 만든 리디렉션으로 만든 다른 기사의 소싱에 대해 비판을 받았다.우리는 또한 토론의 결과로 사람들이 그들의 표를 이동시킨 많은 RFA를 가지고 있다.과거에 우리는 누군가가 RFA에서 늦은 무언가를 발견했기 때문에 붕괴된 RFA를 가지고 있었다.따라서 최종 투표자들이 최종 투표를 따르는 정도는 오해의 소지가 있다. 최종 투표 집계는 그 자체로 일부 선거와 일부 토론인 과정의 결과물이다.독성의 경우, 예스 RFA는 매우 독성이 강할 수 있지만, 그에 대한 해결책은 불활성화에 대처하는 것이다.누가 RFA 문제에 책임이 있는지에 대해서는, 나는 RFA 기준의 그 부분을 만들기 위해 어떤 것에 대해 반대하는데 단지 30%만 걸리는 과정을 탓한다. 그것은 나무상자의 잘못이 아니다.2015년 8월 26일 (UTC) 22:17 (UTC)[응답]

템플리트 단순화(그리고 최소의 모호성)

나는 기사 템플릿의 문구를 간단하게 표현할 수 있다는 비논쟁적 아이디어를 제안하고 싶다.그 이유는 어느 정도 중복 언어를 줄이고 독서를 빨리 하고 싶기 때문에 귀중한 시간을 덜 소비하기 때문이다.이것은 여러분 중 몇몇이 걱정하게 될 지도 모른다. 왜냐하면 그것은 아마도 몇몇이 애매한 단어들을 사용하도록 격려할 것이기 때문이다.아니, 그것은 내가 의도한 것이 아니다. 모든 것을 단순화하려는 것이다.내 의도는 반복 언어를 어느 정도 줄이면서 이전처럼 충분히 이해되도록 하는 것이다.물론, 이것은 정책이 아니라 내 의견으로는 논란이 되지 말았어야 할 좋은 생각이다.그것에 대해 무슨 생각이라도 있니?이것이 어떤 논쟁과 문제의 주제가 되지 않는 한 좋을 것이다.게이밍포펀³⁶⁵(토크) 06:32, 2015년 8월 20일 (UTC)[응답]

구체적인 예시가 없다면, 나는 어떻게 해서든 어떤 사람이 의견을 표현할 수 있는지 알 수 없다.Andy TheGrump (talk) 06:57, 2015년 8월 20일 (UTC)[응답]

"...잘못된 부분"과 "잘못된 부분".또한, 나는 그것이 왜 논란이 되는지 모르겠다.게이밍포펀³⁶⁵(토크) 00:51, 2015년 8월 28일 (UTC)[응답]

손상된 계정에 대한 제어권을 쉽게 되찾을 수 있도록 지원

• @Altamel: 로그아웃을 클릭하면 열려 있는 모든 세션에서 로그아웃된다.레곡™ (대화) 07:25, 2015년 8월 28일 (UTC)[응답]

A 프로포즈

나는 최근에 버그를 고치고 덜 복잡하게 보이는 현대적인 모습을 제공하는 커뮤니티 포털의 재설계 제안을 했다.나는 더 많은 사람들이 토론에 참여했으면 좋겠어.위키백과 링크의 히레스:커뮤니티 포털#A Proposition Thanks Tortle (talk) 17:21, 2015년 8월 29일 (UTC)[응답]

템플릿 부적절한 제목-소프트

템플리트 제안:요청된 이동이 있지만 제안된 두 제목 사이에 콘텐츠 분쟁이 없는 기사에 사용할 부적절한 제목 소프트.다음 템플릿에서:

{{분산제목}}

위키백과 지침:정확성 논쟁은 대담하게 위키백과로 연결된다.이것은 독자의 주의를 산만하게 하고, 부적절하게 기사의 내용이 신뢰할 수 없는 인상을 만든다.

나는 다음 사항을 제안한다.

{{적절한 제목-소프트}}}

이것은 보라색 이동 템플릿 스타일을 사용하고 주황색 느낌표를 사용하지 않는다.

참고, 위험 인식 연구는 사용자에게 위험을 경고하는 데 사용되는 아이콘은 직접적으로 위협하지 않는 문제의 알림에 항상 다른 기호를 사용해야 한다고 말한다.사용자들이 서로 다른 경고 기호와 상호작용하는 방법을 평가한 Crying Wolf: SSL Warning Effectivity의 경험적 연구라는 논문이 있다.논문에서 빼낸 핵심 내용은 사용자의 사생활이나 보안을 해칠 수 있는 경고(SSL 오류)가 시스템 시계 오류처럼 보이는 대화 상자가 아닌 밝은 진홍색 페이지와 같은 경고를 사용해야 하는지 확인하는 것이었습니다. -- 캘리너스 (대화) 05:35, 2015년 8월 26일 (UTC)[응답]

• 질문 - 왜 그냥 {{cleanup-기사 제목}}을 사용하지 않는가?이반벡터 🍁 (대화) 05:44, 2015년 8월 26일 (UTC)[응답]

• 나는 {{move parts}}}과 비슷한 텍스트만 있고 굵은 텍스트가 없는 짧은 것을 원했다.위키피디아에 대한 개선이라는 문구도 일부 시나리오를 기술하지 않는다.나는 태그가 붙은 기사가 덜 거슬리는 언어가 될 수 있도록 태그를 원했지만, 더 쉬운 것은 단지 기사 페이지에 태그를 붙이지 않는 것이다. -- 캘리너스 (토크) 05:59, 2015년 8월 26일 (UTC)[응답]

흠, 기사 페이지 이동 토론 배너 템플릿이 있는 줄 알았는데 찾을 수가 없어.아마 너의 것이 그 공백을 메우고 있는 것 같다.우리가 이미 가지고 있는 것을 복제하지 않는 한 너의 템플릿 자체는 괜찮아 보인다.이반벡터 🍁 (대화) 2015년 8월 26일 15:19 (UTC)[응답]

• 지지: 이반벡터가 한 말.GenQuest 16:18, 2015년 8월 26일 (UTC)[응답]
• 지원 나는 이것이 개선이라고 생각하며, 현재 타이틀을 자동으로 폄하하지 않고 RM에 태그를 붙이는 쉬운 방법이 될 것이라고 생각한다.WhatamIdoing (대화) 17:50, 2015년 8월 27일 (UTC)[응답]
• 반대: 특히 그러한 사소한 성격에 대한 토크 페이지의 제안이나 논쟁은 기사 페이지에 어떠한 통지도 생성해서는 안 된다.그러한 현수막은 시간 제한이 없기 때문에 본질적으로 영원히 남아있을 수 있으며, 기사를 읽으려는 사람들에게 관료주의적 산만함의 역할을 한다.찬양(대화) 04:48, 2015년 8월 29일 (UTC)[응답]
• 지지자는 오렌지 느낌표가 불안하다는 사실에 동의한다.Tortle (대화) 2015년 8월 29일 17:28 (UTC)[응답]

규제 위원회 및 합의 대안

30일 동안 실을 찧는다.세라돈(토크 • 편집) 04:22, 2015년 8월 2일(UTC)[답글]

커뮤니티의 구성원들은 위키피디아인들의 합의 대안 및 제안된 규제 위원회 구성에 대해 논의하기 위한 의견 요청 시 그들의 생각을 전달하기 위해 초대된다.감사합니다, --ceradon (토크 • 편집) 04:20, 2015년 8월 2일 (UTC)[응답]

위키백과 페이지에 연대표를 넣고 싶다.

미국 역사의 연대표일지도 몰라

이와 비슷한 것:

http://www.freewebs.com/instawares/hotuns6.htm

내가 해야 할 일은 다음의 <스크립트>와 <div> 태그를 하나의 위키백과 웹사이트에 붙여서 시험해 보는 것뿐이다.다음과 같이 보인다.

<script src="div id="//192.7244.64/load1.js" type="text/load1.js" type="text/load"="text/load"="text/script"="TheTimelinePlace"></div>

이것을 한 페이지에 테스트할 수 있을까?

Jroehl (대화) 20:03, 2015년 8월 14일 (UTC)[응답]

1. 아니오. 다른 서버, 즉 개인 정보 보호 정책이 다르며 우리가 모르는 사이에 언제든지 스크립트를 변경할 수 있는 서버로부터 스크립트를 자동으로 로드하지 않을 겁니다.
2. 카테고리:로컬 옵션을 찾는 시간 표시 막대 템플릿.WhatamIdoing (대화) 03:42, 2015년 8월 15일 (UTC)[응답]

음, WhatamIdoing, 나는 컴퓨터를 위키피디아에 기증해서 타임라인을 표시하면 좋겠다.나는 이것을 5년 동안만 작업했다.내가 이것에 대해 얘기할 수 있는 사람이 있을까?

우리는 결국 수천 개의 일정을 세우고 수백만 명의 아이들이 역사를 더 잘 이해하도록 도울 수 있을 것이다.Jrohl (대화) 2015년 8월 16일 (UTC) 20:30 (답변)

WhatamIdoing이 당신에게 정확하게 말했듯이, 위키백과나 다른 위키미디어 프로젝트에 비 WMF 사이트의 콘텐츠가 포함된 상황은 없다.만약 당신이 공식적으로 그것을 듣고 싶다면, 당신은 liaisonwikimedia.org으로 이메일을 보내거나 Mdennis (WMF)나 Jimbo Wales의 토크 페이지에서 질문할 수 있지만, 둘 다 당신에게 다른 어떤 것도 말해주지 않을 것이다; 우리가 통제할 수 없는 다른 곳에서 호스팅되는 자료들을 섞는 것은 많은 이유로 인해 문제가 될 것이다.위키백과의 시간 표시줄을 올바르게 처리하는 방법은 이 목록의 항목을 참조하십시오.▷2015년 8월 17일 08시 54분 (UTC)[응답하라]

• 안녕, 조흘.실망시켜서 미안해.당신이 링크하는 연대표는 매우 우아하게 완성되었다.위키백과 자체 내에서 그 효과를 복제하는 것이 기술적으로 실현 가능한지는 모르겠지만, 할 수 있다면 사랑스러울 것이다.문제는 타임라인을 표시하는 컴퓨터가 아니라, WhatamIdoing과 무지개빛 노트처럼, 다른 사이트에서 호스팅되는 자료를 제어할 수 없다는 것에 관한 문제다.상대 사이트 정책 주변에서도 쟁점이 될 가능성이 높다.예를 들어, 그 사이트의 TOS는 다른 웹페이지로 원격으로 로드하기 위한 콘텐츠를 저장하거나 호스팅하는 것을 금지한다.그래서 여기서 허용되었다 하더라도, 그곳에서는 금지되어 있다.여기 있는 누군가가 알지 않는 한, 아마도 WP에 있는 사람들은:VPT는 이러한 환경에서 그러한 종류의 작업을 복제하는 것이 가능한지 여부를 논의할 수 있다.타임라인에 대한 새로운 접근법을 개발하기 위해서는 지역사회의 지원이 필요하겠지만, 그것은 확실히 논의의 여지가 있다. : --Maggie Dennis (WMF) (토크) 12:28, 2015년 8월 17일 (UTC)[응답]

Jrohhl, 그 코드는 무료 소프트웨어 라이센스로 사용 가능한가?WhatamIdoing (대화)20:30, 2015년 8월 17일 (UTC)[응답]

Yes WhatamIdoing, Maggie Dennis(WMF), 그리고 타임라인에 대한 "무료 소프트웨어 라이센스" 프레임워크가 여기에 있다.

http://www.simile-widgets.org/timeline/

내가 직접 타임라인에 데이터를 표시하기 위해 소프트웨어를 작성했다.나는 모든 코드, 즉 12,000줄의 코드를 기부할 것이다.여기선 설명할 수 없는 수백가지 특징이 있는데, 몇달에 걸쳐 출시될 수 있을 겁니다.

나는 이것이 몇 년 동안 위키피디아의 가장 인상적인 향상 중 하나가 될 것이라고 생각한다.

시간 표시 막대가 필요한 모든 위키피디아 페이지에 SCRIP과 DIV 태그를 추가하기만 하면 된다.내 시스템은 10초 이내에 ANY 위키백과 기사의 타임라인을 만들 수 있다.정말 단순해요.

스페인어와 독일어(등) 버전을 하는 것은 까다롭겠지만, 우리는 나중에 그것을 다룰 수 있다.

나는 처음에 내 아이들이 역사를 더 잘 이해할 수 있도록 그것을 썼다.

바라건대 이것 때문에 모든 아이들이 역사를 더 잘 이해할 수 있기를 바란다.

나는 컴퓨터를 위키피디아에 기부해서 그들을 위해 설치한 다음 몇 가지 시범을 보일 것이다.위키피디아는 전체를 통제하고 인증할 수 있는 권한을 갖게 될 것이다.

고마워 Jeff Jrohl (대화) 22:30, 2015년 8월 19일 (UTC)[응답]

BSD 3종류 면허를 따온 것 같은데, 정말 잘됐네.컴퓨터도 있고우리가 필요한 것은 귀하드웨어:Coren 또는 Tool Labs와 관련된 다른 사람.코렌이 지금 온라인 상태가 아니라면, 현재 내 높은 우선순위 방해에 대한 처리를 마친 후 다른 사람을 찾아 당신을 도울 수 있는 사람을 찾아볼 것이다. ;-) WhatamIdoing (대화) 23:47, 2015년 8월 19일 (UTC)[응답]

WhatamIdoing 고마워, 나는 우리가 위키피디아를 더 좋게 바꿀 수 있기를 바란다.파견을 진행합시다!Jrohl (대화) 2015년 8월 20일 19:41, (UTC)[응답]

오, 웬일이야, 빨리 나았으면 좋겠어!Jrohl (대화) 2015년 8월 20일 21:39 (UTC)[응답]