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

Wikipedia:
마을 펌프(제안) 아카이브

이 페이지에는 빌리지 펌프(제안)에서 보관된 토론이 수록되어 있다.이 페이지의 내용을 편집하지 마십시오.이러한 토론 중 하나를 다시 시작하려면 새 스레드를 시작하거나 해당 주제와 관련된 대화 페이지를 사용하십시오.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125,126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188

MediaWiki 소프트웨어를 특수(예: 블랙리스트/화이트리스트) 블록에 대한 옵션을 포함하도록 수정해야 하는가?

다음의 논의는 종결되었다.수정하지 마십시오.후속 코멘트는 새로운 섹션으로 작성되어야 한다.

이 아이디어에 대한 약간의 지지는 있지만 명확한 합의는 없다. 참여자들이 이 기능이 어떻게 작동할지 상상해야 하기 때문이기도 하고 몇몇은 그러한 기능을 만드는 데 필요한 작업이 잠재적인 이익을 능가할지에 대한 우려를 제기하기 때문이다.서포터즈가 이 제안을 추진할 가치가 있다고 생각한다면, 나는 개발자들과의 토론이 아이디어를 진전시키는 가장 좋은 방법이 될 수 있다고 제안한다.HJ Mitchell Penny, 네 생각은 어때? 2014년 9월 6일 19시 49분(UTC)[응답하라]

전문화된 블록의 시스템이 도움이 될까?더스틴 (토크) 02:41, 2014년 7월 24일 (UTC)[응답]

참고: 이것은 위키백과에서 사전에 부분적으로 논의되었다.마을 펌프(아이디어 연구소)/아카이브 14#전문블럭, 그리고 나는 나의 제안을 이곳으로 가져오기로 했다.그래도 그 페이지를 먼저 읽어줘.나는 이것을 RfC로 시작했는데, 그것이 매우 중요하다고 생각하기 때문이다.

(다음은 아이디어 랩에서 복사한 것임)

다음은 MediaWiki 소프트웨어 변경 제안사항이다.

이런 것이 이미 제안이 되었는지는 모르겠지만, 내 부분에 대한 짧은 탐색으로 이런 것이 나오지 않았으니 내 생각을 내놓겠다.내가 제안할 수 있는 건 여기 있지만, 우선 여기서 먼저 제안할 거야. 그래야 우리가 그것에 대해 토론하고 미리 아이디어를 다듬을 수 있으니까.나는 우리가 MediaWiki 소프트웨어를 전문화된 블록을 허용하도록 수정하는 것을 제안한다.블록은 현재 사용자 자신의 토크 페이지를 제외한 모든 페이지의 편집 블록 또는 사용자 자신의 토크 페이지를 포함한 모든 페이지의 블록의 두 가지 옵션만 있다.나의 새로운 "전문" 블록 시스템에는 더 많은 선택사항이 있을 것이다.

  1. 관리자는 사용자가 특정 개별 페이지를 편집하지 못하도록 차단하거나 블록을 선택한 페이지에 적용할 수 있다.사용자가 주제반을 따를 수 없거나 자신의 제한사항을 따를 수 있다고 느끼지 못하는 경우, 관리자는 단순히 사용자가 수동으로 선택한 페이지 목록을 "위험"으로 편집하지 못하도록 차단할 수 있다.
  2. 관리자는 특정 접두사가 있는 모든 페이지(수동으로 선택한 예외 제외)의 편집을 차단할 수 있다.예를 들어, 한 명의 사용자가 SPI 페이지에서 지나치게 파괴적인 경우(그리고 나는 반달리즘에 대해 말하는 것이 아님), 관리자는 "Wikipedia:"로 시작하는 모든 페이지를 편집하는 것을 차단할 수 있다.Sockpuppet 조사/."
  3. 이 최근 사례와 유사한 대화 페이지(그러나 사용자가 자신의 대화 페이지와 하나의 예외 페이지에만 머무르도록 아직 신뢰할 수 없는 경우)에서 차단 해제를 요청하는 편집자가 자신의 대화 페이지와 별도로 한 페이지를 편집해야 하는 상황이 발생하면 해당 한 페이지를 무시하도록 블록을 수정할 수 있다.

누군가 이 기능을 개발할 필요가 있기 때문에 어떻게 구현할지 모르지만, 그것은 나중에 고려해야 할 사항이다.나는 단지 편집자의 의견이나 아이디어를 알고 싶을 뿐이다.더스틴 (토크) 02:42, 2014년 7월 24일 (UTC)[응답]

  • 나는 우리가 원하는 세부사항들이 무엇인지에 대한 세부사항들이 있지만, 일반적인 생각을 지지한다.특히, 내가 확실히 유용하다고 생각하는 한 가지는 특정 페이지에서 IP 범위(아마도 /8 정도)를 차단하는 능력이다.현재 이를 위한 유일한 방법은 편집필터(편집필터)로 성능을 저해하는 것이다. -- 킹 오브 of ♥ 02:50, 2014년 7월 24일 (UTC)[응답]
    사실, Graeme Bartlett가 한 말은 정말 일리가 있다.그리고 필터에 의해 제한될 사용자로서 IP 범위를 선택할 수 있어야 한다. -- 킹 오브 ♦ ♦ 03:43, 2014년 7월 26일 (UTC)[응답]
  • WMF의 개발 지원이 필요하기 때문에 반대한다.이것들은 본질적으로 지원 블록이 있는 토픽 밴이다.로버트 맥클레논 (대화) 02:52, 2014년 7월 24일 (UTC)[응답]
  • 강력한 반대 블록에 대한 논의는 광범위하고 지역사회는 매우 명확했다... 더 이상의 선택권이 필요하거나 필요하지 않다.내 도움은 안 돼미안.--마크 밀러 (대화) 02:59, 2014년 7월 24일 (UTC)[응답]
    • 너는 분명히 내가 제안한 것처럼 이전의 토론도, 그 토론의 링크도 보지 않았다.9년 전인 2005년만 해도 이런 제안이 또 있었는데 80%가 넘는 찬성을 받았다.그게 오래 전 일이라는 건 알지만, 왜 우리는 재고해선 안 되는 거야?더스틴(토크) 03:04, 2014년 7월 24일 (UTC)[응답]
      • 다른 토론에 신경 쓰지 않으니 신경 안 써. 그러니 이제 그만 불평하고 이 일을 지역사회에 내놔.넌 네 말을 했어.그것만으로 충분치 않다면 실패.--Mark Miller (talk) 03:08, 2014년 7월 24일 (UTC)[응답]
  • 여기서 이 토론을 하는 것은 토론의 목적을 다소 흐리게 한다.단순히 그러한 시스템이 어떻게 보일지 기술 명세서를 작성하는 것이 목표라면, mediawiki.org이 더 나은 위치가 될 것이다.여기서의 논의는 필연적으로 지역적 정책적 함의를 수반할 것이며 우리는 그러한 논의가 합리적으로 진행되기 전에 특성의 역량이 무엇인지에 대한 구체적인 아이디어를 가질 필요가 있다.미스터 지만 04:20, 2014년 7월 24일 (UTC)[응답]
이것이 실제로 더스틴이 제안한 위키백과의 현지 이슈인지 궁금할 것이다.나는 9년 전 토론에서 이 토론으로 질질 끌고 가는 것이 오늘과는 관련이 없다고 생각할 수도 있지만, 이봐....이러한 과정을 놔두고 어떻게 되는지 보자.--Mark Miller (talk) 04:27, 2014년 7월 24일 (UTC)[응답]
  • 아이디어 랩에서 말했듯이, 이것은 한 명의 사용자(또는 IP)에게만 적용되는 편집 필터일 수 있다.필터가 1명의 사용자만 작동하도록 최적화되면 나머지 사용자에게는 성능에 영향이 없을 것이다.여기에는 업로드, 이동, 상호 작용 금지 사용자 대화 페이지 사용 등을 거부하는 훌륭한 곡물들이 많이 있을 것이다.Graeme Bartlett (대화) 07:28, 2014년 7월 24일 (UTC)[응답]
  • 그러나 Graeme Bartlett와 같이 개별 사용자나 IP 범위에 적용되는 필터 편집 방향으로 가자고 제안할 것이다. --AFBorchert (talk) 08:41, 2014년 7월 24일 (UTC)[응답]
  • 유용성이 노력과 복잡성을 능가한다는 것을 설득하지 못했다.로그인한 편집자들에게 이 아이디어는 나에게 별 볼일 없는 것이다.특정 사용자가 주제 또는 상호 작용 금지 대상인 경우, 편집 제한 조건을 고수하거나 완전히 차단된다.편집 제한을 준수할 성숙도나 구속력이 부족한 사용자(그리고, 애초에 그러한 제한을 받을 정도로 충분히 파괴적인 방식으로 편집한 사용자)는 추가적인 기술적 제약이 필요하지 않으며, 스스로 통제할 수 있을 때까지 편집을 중단할 필요가 있다.
    IP주소에 대해서는, 이것에 대해서, 부차적인 피해를 줄이기 위한 방법(특히 레인지 블록을 배치할 때)으로 어느 정도 주장해 볼 수 있지만, 가치보다 더 복잡할 것이라고 추측한다.세미 프로텍션은 기사의 모든 IP 편집자에게 영향을 미치지만 이미 해결책으로 존재한다.(수단으로서는 다소 무뚝뚝하지만, 이미 우리는 상황에 의해 보증된 기사의 장기 반보호까지도 용인하고 있다.)
    관리자 입장에서 볼 때, 나는 이것이 관리 및 추적하기가 다소 복잡해지는 것을 볼 수 있다.IP 범위가 특정 기사를 편집하지 못하도록 차단하는 경우, IP의 블록 로그에 표시되는가, 아니면 해당 글의 로그에 표시되는가, 아니면 둘 다 표시되거나 둘 다 표시되지 않는가?TenOfAllTraes(대화) 17:52, 2014년 7월 25일(UTC)[응답]
  • 반대 이것은 문제를 찾는 해결책이다.그것은 필요하지 않은 곳에 복잡성을 야기한다.사용자가 제한을 따르지 않을 경우 기존 블록이 작동한다.사용자는 지역사회의 기대를 기꺼이 따르거나 그렇지 않다.특화된 블록은 시스템의 게임을 유발할 수 있다.칠음 18:06, 2014년 7월 25일 (UTC)[응답]
  • 나는 선택적 화이트리스트가 누군가를 차단하는 데 사용될 수 있을지 궁금하다. 그러나 그들이 특정한 식별된 페이지에서 자신의 카피비오들을 청소하는 것을 가능하게 할 수 있을까?그것이 바람직할 수도 있다.WhatamIdoing (대화) 18:49, 2014년 7월 25일 (UTC)[응답]
    이것은 내가 위에서 말한 요점까지 간다.만약 우리가 편집의 주위에 기술적 벽을 쌓지 않고 편집의 제약에 따를 사람을 믿을 수 없다면, 나는 그들이 특히 저작권 위반이나 표절을 애초에 소개했던 곳인 카피비오들을 정리하는 것과 같은 신중한 판단이 필요한 작업을 수행하도록 믿을 수 없을 것이다.TenOfAllTraes(대화) 19:03, 2014년 7월 25일 (UTC)[응답]
    저작권 정리에 도움을 줄 수 있도록 차단된 것을 완전히 해제해 달라는 요청을 보는 것도 예사롭지 않다.그것은 특정 페이지에만 접근을 제공하는 것보다 훨씬 더 많은 아이를 필요로 한다.WhatamIdoing (대화) 23:16, 2014년 7월 25일 (UTC)[응답]
  • 기술적으로 가능하다고 가정하고 그 아이디어를 지지하십시오.이것은 많은 분야에서 기존의 관행보다 더 이치에 맞을 것이다.예를 들어, 3RR 위반의 경우, 만약 편집자가 기사의 전쟁을 편집하여 문제를 일으킨다면, 그것들을 막을 수 있는 유일한 방법은 그들이 단지 한 페이지에 문제를 야기하고 있음에도 불구하고, 그들이 모든 페이지를, 어디서나 편집하는 것을 막는 것이다.편집 전쟁이 벌어지고 있는 한 페이지를 편집하지 못하도록 하는 것이 더 이치에 맞을 것이다.Hut 8.5 10:54, 2014년 7월 26일 (UTC)[응답]
  • 지원 - 이를 통해 차단된 사용자와 관련하여 유용한 상황 목록(예: {{2차 기회, 사용자 자신의 토크 페이지 이외의 위치에서 토론 차단 해제)뿐만 아니라 금지가 보다 쉽게 시행될 수 있다.2014년 7월 27일(UTC) 오드 미셰후 19:56[응답]
  • 지원 관리 툴박스에 이 기능이 추가될 것으로 보인다.Toohool (토크) 01:18, 2014년 7월 31일 (UTC)[응답]
  • 내가 거의 알지 못하는 기술적 설계 요건을 무시한 채 지원하지만, 나는 구현할 가치가 있는 어떤 아이디어도 기술 작업을 할 가치가 있다고 생각한다.나는 이것을 "광범위하게 구성된" 주제 금지용으로 사용하는 것이 조금 어려울까 봐 걱정되지만, 특정 범주의 페이지를 사용자가 편집하는 것을 차단하는 방법을 구현할 수 있을 것이다.어쨌든 좋은 생각이야.그러나, 나는 만약 편집자가 공동체 규칙에 따라 연주할 수 없다면, 모든 블록과/또는 공동체 금지가 어쨌든 오고 있다는 위의 다른 사용자들의 말에 동의한다.이반벡터 (대화) 2014년 8월 5일 (UTC) 15:41, 응답하라
  • 지지하다.나는 원칙적으로 이면에 있는 아이디어가 좋다.캘리덤 01:31, 2014년 8월 18일 (UTC)[응답]
  • 강한 반대다.이것은 전혀 좋은 생각이 아니다.금지령은 지역사회의 혼란을 막기 위해 존재하며, 위반 편집자들에게 지역사회의 한 부분으로 남을 수 있는 기회를 주기 위해 존재한다.그들은 금지의 제약을 준수함으로써 이것을 한다.만약 그들이 이것을 할 수 없다면, 우리는 그들에게 다음과 같은 WP를 주었다.로프, 그리고 그들은 그들 스스로를 공동체 밖에 있는 것으로 설정하기 위해 그들의 행동에 의해 선택했다.블록은 공동체가 편집에 부과한 금지령을 경멸하거나 공공 기물 파괴 행위와 같은 명백한 규칙을 어기는 것에 의해 공동체의 일부가 되지 않기로 선택한 사람들을 위한 것이다.이 공동체의 일원이 되는 "부분적인" 것은 없다.규칙을 지키거나, 아니면 여기에 참여하지 않는 거야.선별적인 차단막은 단지 이 지역 사회 밖에서 스스로를 생각하는 사람들이 그들의 금지를 위반함으로써 우리에게 그들의 떨어져 나가기로 한 그들의 결정을 증명하는 것을 막을 뿐이다.선별적인 블록은 위키리듬링 가능성이 있는 거대한 판도라의 상자를 열며, 지역사회를 홍보하는 데 아무런 도움이 되지 않는다.이것은 명백한 나쁜 생각이다.반아이작WScont 01:46, 2014년 8월 18일 (UTC)[응답]
    • "강한"이라는 단어를 사용하는 것은 여러분의 투표에 더 이상의 무게를 주지 않는다. (나는 왜 "강한 지지"와 "강한 추측"이 사용되는지 모르겠다) 그러나 요점에서 벗어나서 제안 #3을 고려했다고 생각하지 않는다.더스틴(토크) 16:31, 2014년 8월 18일 (UTC)[응답]
      • "강력"이라는 말은, 사람의 입장 뒤에 있는 우선적 또는 물류적 고려라기보다는, 그 제안에 대한 단정적인 반대나 지지라는 것을 나타낸다.그리고 이것은 투표이기 때문에, 물론 모든 투표는 가중된다; 그것이 투표의 전체 포인트다.비록 나는 어떻게 #3 상황이 발생할 수 있는지 이해할 수 없지만 - 만약 우리가 기여 이력이 한 곳에 기록되어 있는 사람을 믿을 수 없다면(그래서 쉽게 되돌릴 수 있다면), 어떻게 한 페이지에 있는 그들의 행동이 그들이 그 프로젝트에 더 이상 접근할 수 있을 만큼 충분한 신뢰를 심어줄 수 있을까? - #3은 여전히 믿을 수 있다.기사 내용을 편집하여 삭제할 수 있는 대화 페이지로 복사하여 현재 권한 구성으로 컴파일.반아이작WScont 18:59, 2014년 8월 18일 (UTC)[응답]

대체 제안

이것이 RfC에 적합한 형식인지는 확실하지 않지만, 여기 있다.관리자(EFM이 아닌 것 같음)는 사용자가 다른 페이지를 편집할 수 있도록 허용하면서 특정 페이지를 편집할 수 없도록 차단할 수 있는 편집 필터를 만들 수 있다.이는 블록처럼 심각하게 취급되어야 한다(관리자는 사용자가 일반적으로 블록을 보증하는 TBAN 인클레이션을 만들지 않는 한 TBAN에 이러한 것을 사용하지 않도록 명시한다).예를 들어 사용자가 ANI에서 자신의 블록을 논의하도록 요청하는 경우, 해당 사용자는 차단 해제되고 필터가 수정되어 호소력 있는 사용자가 ANI를 제외한 어떤 페이지도 편집하지 못하도록 차단된다(그렇지 않을 경우 발생하는 혼동을 피하기 위해 관리자는 편집에 대한 전체 시스템을 포함하는 필터를 하나 또는 두 개 만들 것이다).다음과 같다:((user_name==appeallingeditor) & (article_prefixedtext !='Wikipedia:Administrator's noticeboard/Incidents')) ((user_name==TBANnededitor) & (article_prefixedtext =='ContentousArticle' ...)) 그런 다음 액션을 차단하여 달래는 사람이 위키백과를 제외한 다른 페이지를 편집할 수 없도록 한다.관리자 알림판/사고, TBANnediter의 내용 편집 방지기사(누군가 더 좋은 코드를 생각해낼 수 있을 것 같은데, 그냥 장난으로 둘러본 것)2014년 8월 8일(UTC) 21:31, 8에 회신할 때 Cheats and Thanks, L235-TalkPing [응답]

  • 내가 했던 것 보다 네가 더 많은 코드를 가지고 있구나...적어도 보이는 방식으로는, 나는 이 제안을 지지할 것이라고 생각한다. 왜냐하면 그것은 관리자에 의한 더 강력한 시행을 가능하게 할 것이고, 위와 같은 나의 주요 제안의 목표들 중 일부를 충족시킬 것이기 때문이다.더스틴 (토크) 21:44, 2014년 8월 8일 (UTC)[응답]
  • 이론적으로는 지지하지만 실제로는 EF 조건 한계에 부딪히는 편집 횟수가 너무 많을 경우(현재 0.77%이지만 때때로 5%를 상회하는 경우도 있다) 가치보다 더 많은 문제를 일으킬 수 있다.2014년 8월 13일(UTC) 오드 미셰후 08:19[응답]
  • EF 한계에 부딪힌 것이 내가 사용자별 또는 코드 내 IP별 편집 필터에 대한 특별 지원을 제안했던 이유다.이것은 영향을 받는 사용자에게만 실행되기 때문에 매우 효율적일 것이다.그래미 바틀렛(대화)
  • 이 봇은 이 토론을 계속 보관하고 있는데, 이것은 분명히 이슈가 되고 있다.이제 어떻게 할 거야?적어도 어느 정도 지원을 받은 것 같으니까 이걸 그냥 보관해서는 안 될 것 같아.더스틴(토크)
    버그질라에서 기능 요청을 제출하여 이 기능을 프로그래밍하려는 사람이 있는지 확인해 보십시오.그리고 또 다른 RFC가 프로그램되면 여기서 활성화할 수 있는지 알아볼 수 있을 겁니다.–xenotalk 03:12, 2014년 9월 3일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

개발자들과 연락하기 가장 좋은 장소가 어딘지는 모르겠지만, 제노의 제안대로 버그질라 계정을 등록해서 그 문제를 제기하려고 할지도 모른다.일단 이 논의는 여기까지인 것 같다.더스틴(토크) 23:02, 2014년 9월 11일 (UTC)[응답]

리딩제로

일반 영어는 선행영역(예: 2014년 9월 02일)을 사용하지 않기 때문에 비기술적인 장소에서는 사용하지 않았으면 좋겠다.나는 출판/생일/사망/시작/종료 날짜를 10 미만의 날짜와 1개월 및 연도의 날짜에 선행 영(0)이 있는 우측 상자에 기재하는 것을 반대한다.나는 이것을 여러해 동안 찾을 수 없었다.이 건에 대해 논의되었나?방침이 있는가?Kdammers (대화) 03:27, 2014년 9월 11일 (UTC)[응답]

위키백과:Style/Date 및 number의 매뉴얼은 이에 대해 아무런 언급도 하지 않는 것 같다. --NaBUru38 (토크) 03:42, 2014년 9월 11일 (UTC)[응답]
문제를 보여주는 기사를 링크하십시오.조누니크 (대화) 03:58, 2014년 9월 11일 (UTC)[응답]
네, MOS:BADDATEFORMAT의 표를 참조하십시오. 두 번째 열에 "09 6월"/"로 표시됨09년 6월 09일, 3번째 콜에서는 '제로패드 월이나 일'을 하지 말 것. --Redros64 (토크) 07:00, 2014년 9월 11일 (UTC)[응답]
알았어, 그럼 내가 불응하는 사이트부터 정리할게.Kdammers (대화) 07:13, 2014년 9월 11일 (UTC)[응답]
@Kdammers: BattyBot은 CS1 오류를 발생시키는 인용 날짜의 선행 0을 제거한다. (예: 이 편집)BattyBot이 수정하지 않는 곳이 있으면 내가 대본을 수정할 수 있도록 알려줘.고마워!GoingBatty (토크) 02:32, 2014년 9월 12일 (UTC)[응답]

작성 스크립트 업그레이드에 대한 문서

여러분 안녕하십니까?

AfC 제출을 검토하기 위해 가젯에서 사용할 수 있는 스크립트를 변경하는 것과 관련하여 이 논의에 관심이 있을 수 있다.고마워. --Mdann52 Talk to me! 2014년 9월 12일(UTC) 12시 50분 [응답]

더 많은 도움의 방향으로 출발할 수 있을까?

자주 발생하는 실수나 오해에 대한 문서화(인정적으로 정책에서 설 자리가 없음)를 포함하여 (개인 대화 페이지에서) 가장 자주 연결되는 정책의 수동 페이지를 작성하여 해당 정책은 시작되지 않고 에지 사례(삭제 기준 등을 가정하는 것)에만 사용할 것을 제안하고 싶다.

나 혼자서는 할 수 있을 것 같지만, 그건 협업적이지 않을 것이고, 나는 현재 긴 FAQ 페이지 형식이나 기여에 불편하다(개인적으로 각 FAQ나 별도의 네임스페이스 또는 작은 크기의 각 도움말 항목을 중심으로 사이트의 구조화된 도움말 섹션에 가까운 모든 것을 가지고 있다).단점. --릴리다(토크) 11:34, 2014년 9월 13일 (UTC)[응답]

범주:만료된 편집 알림

해결됨

범주:만료된 편집통지서에는 현재 두 가지 유형의 편집통지가 포함되어 있다.

  • 만료 시간이 설정되지 않은 편집통지서
  • 만료 시간이 지난 편집자

Wikipedia_talk:Editnotice#Category:만료_editnotice, 만료 시간이 경과한 편집자(아마도 더 이상 사용되지 않고 삭제할 가능성이 있는 편집자)를 더 잘 식별하기 위해 만료 시간이 설정되지 않은 편집자("영구적"일 가능성이 있는 편집자)를 이 범주에 포함하지 않도록 제안하였다.토론을 한 곳에서 유지하기 위해 위키백과_토크에서 이 문제에 대해 가질 수 있는 견해를 표현하십시오.Editnotice#Category:만료_edit notice.고마워요.DH85868993 (대화) 03:16, 2014년 9월 11일 (UTC)[응답]

템플릿 오류가 수정되었다.이제 카테고리의 이름이 Category:만료된 편집 메모와 "s". -- John of Reading(토크) 06:27, 2014년 9월 14일(UTC)[응답]

드래프트 클래스 사용 확대

배경

초안 네임스페이스는 2013년 12월에 사용 가능했다(Wipedia:초안)과 일부 위키프로젝트(현재 1,464명)는 초안급 평가를 사용하여 초안 기사를 그들의 범위 내에서 추적하는 것을 선택했다.프로젝트에서 편집자들이 지식과 관심사 내에서 초안 기사를 개선하여 메인 스페이스에 맞게 준비할 수 있도록 하는 것이 장점이다.

프로포즈

이 제안은 이 사용을 프로젝트에서 사용하는 기본 평가 등급 중 하나로 만들어 확대해야 하는지에 대한 것이다.다음 3가지 옵션이 있다.

  1. 현재 상태: 프로젝트들은 드래프트 클래스를 사용하는 것을 선택할 수 있다.
  2. FQS에 초안 등급 추가: 현재 "전체 품질 척도"(FA, A, GA, B, C, Start, Stub, FL, List, NA, Category, Disambig, File, Portal, Project, Template)를 사용하고 있는 모든 프로젝트에서 초안 등급이 자동으로 활성화됨(약 1300개)
  3. 모두에 드래프트 클래스 추가: 표준 품질 척도(FA, A, GA, B, C, Start, Stub, FL, List, NA)를 사용하는 모든 프로젝트(약 1900년)는 선택을 취소하지 않는 한 자동으로 드래프트 클래스가 활성화된다.

자세한 내용(수행 방법 포함)은 템플릿 대화를 참조하십시오.클래스 마스크#보호된 2014년 9월 1일 편집 요청

토론

  • 드래프트 네임스페이스는 여기에 머물 것이며, 기사를 개발하는 데 유용한 장소임이 증명되고 있다.현재 거의 모든 네임스페이스(예: 템플릿, 포털, 카테고리, 프로젝트 페이지)는 자체 평가 클래스를 가지고 있으며 전체 품질 척도에 포함된다.가장 최근에 추가된 것이 파일 클래스였다.따라서 FQS를 사용하기로 선택한 프로젝트들은 초안 등급 사용에 관심이 있을 수 있으므로 옵션 2가 아마도 가장 합리적일 것이라고 생각한다.— 마틴 (MSGJ · talk) 13:22, 2014년 9월 3일 (UTC)[응답]
  • 옵션 2를 선택한다(FQS에 드래프트 클래스 추가). --Redrose64 (토크) 13:58, 2014년 9월 3일 (UTC)[응답]
  • 좋은 생각이야, 마틴옵션 2. --122.109.102.172 (대화) 11:19, 2014년 9월 4일 (UTC)[응답]을 지원한다.
  • 글쎄, 한편으로는 이미 있는 그대로의 등급이 많지만, 다른 한편으로는 "Full"은 정말로 "Full"을 의미해야 하기 때문에, 나는 옵션 2를 약하게 지지할 것 같아...쿨제니우스 (대화) (출연) 16:01, 2014년 9월 4일 (UTC)[응답]
참고, Full도 Book을 포함하지 않는다. -- WOSlinker (대화) 11:46, 2014년 9월 5일 (UTC)[응답]
User, MediaWiki, Help, Education Program, TimedText, Module, Topic. --Redros64 (토크) 12:10, 2014년 9월 5일 (UTC)[응답]도 포함되어 있지 않다.
그 네임스페이스에는 기사, 초안 기사 또는 템플릿과 같은 글의 구성요소가 포함되어 있지 않기 때문에, 그것들은 실제로 관련이 없다.로저 (Dodger67) (대화) 09:24, 2014년 9월 9일 (UTC)[응답]
모듈은 템플릿의 구성 요소(예: 모듈 토크:AUshield); 및 TimedText 페이지는 파일의 구성 요소(예: TimedText talk:03 Pink Try.ogg.en.srt). --Redros64(토크) 11:32, 2014년 9월 9일(UTC)[응답]
  • 나는 옵션 2를 선호하지만 옵션 1 때문에 마음이 아프지는 않을 거야.프로톤크 (대화) 2014년 9월 5일 (UTC) 13:00[응답]
  • 일반 AfC 검토자로서 나는 옵션 3을 선호하지만 옵션 2도 허용될 것이다.위키프로젝트의 범위 내에서 초안의 존재에 대해 일상적으로 "통지"할 수 있는 메커니즘의 결여는 AfC에서 영구적인 문제가 되어왔다. 따라서 나는 이 제안의 완전한 실행을 지지한다.로저 (Dodger67) (대화) 09:24, 2014년 9월 9일 (UTC)[응답]
  • 나는 피드백 요청 서비스를 통해 여기에 소환되었고, 특히 드래프트 클래스가 네임스페이스 초안과 함께 사용되도록 의도된 것처럼 보이는, 스텁이 이미 제공하고 있지 않은 드래프트 클래스가 어떤 것을 제공하는지 정말 잘 모르겠다.어쩌면 누군가는 이것이 어떻게 모두에게 이익이 되는지 설명할 수 있을지도 모른다.삼사라(FA•)FP) 00:29, 2014년 9월 13일 (UTC)[응답]
    @삼사라:여러분이 추측하듯이, 많은 초안은 자신의 존재를 아는 사람 거의 없이 만들어진다 - 페이지 작성자와 일상적으로 초안을 체크하는 사람들: 새로운 창작물을 위한 공간.이것들을 더 넓은 관심에 끌어들이기 위해(그리고 바라건대 다른 사람들이 드래프트를 메인 스페이스에 적합한 표준으로 올리도록 돕도록 격려하기 위해), 초안 토크: 페이지에는 정규 기사의 토크 페이지와 같은 방법으로 위키프로젝트 배너로 태그가 붙을 수 있다.이미 드래프트 클래스에 가입한 Wiki Project 배너에 대해,{{WikiProject Albums}}, 배너가 제공된 경우 class=draft, 또는 만약 class=매개변수를 공백으로 두거나 생략한 후, 토크 페이지는 카테고리:드래프트 클래스 앨범 기사.아직 드래프트 클래스를 선택하지 않은 위키프로젝트 배너에 대해 다음과 같이 입력하십시오.{{WikiProject Jazz}}, 토크 페이지는 Category와 같은 카테고리에 배치된다.배너가 명시적으로 주어지더라도 NA-클래스 재즈 기사 class=draft. 이 글을 쓰면서 두 가지 드래프트 토크가 있는데, 위키프로젝트 재즈를 태그한 페이지들이지만, 카테고리:NA-클래스 재즈 기사는 81명의 회원이 있다.드래프트 토크를 구분: 페이지별로 분류 - 카테고리:드래프트-클래스 재즈 기사 - 이 두 사람이 더 빨리 찾을 수 있도록 도와줄 것이며, 이 두 글자로 표시된 70페이지 이상의 페이지 중 눈에 띄지 않게 되어서는 안 된다. class=redirect고양이의 대부분을 차지하는 것 같아이러한 분리 작업은 위키프로젝트 앨범과 유사한 방식으로 위키프로젝트 재즈가 선택할 수도 있고, 위키프로젝트의 대부분에 영향을 미치는 일반적인 변경에 의해 이루어질 수도 있다. --Redros64 (대화) 10:44, 2014년 9월 13일 (UTC) 응답 [응답]
    나는 초안 공간의 사용이 증가하는 검토 백로그와 연관되어 있다는 불평이 있다고 본다.그것의 사용을 더욱 장려하는 것이 정말 현명한가?다시 말해서, 평론 백로그가 위키피디아의 순이익인가, 일반 공간에서 기사를 스텁하게 할 수 있도록 허용하는 것에 비해?수년 동안 기사 작성률이 감소하고 있다는 우려가 있었다.여기에 드래프트 스페이스가 미친 영향은?관련 데이터를 수집하여 게시하는 것이 가능할 것 같다 - 이미 누군가가 가지고 있는 것 아닐까?더 많은 통찰력을 주셔서 감사하다.삼사라 (FA•FP) 15:13, 2014년 9월 13일 (UTC)[응답]
    위키프로젝트들이 초안을 좀 더 인지하게 된다면, 아마도 그들 멤버들 중 일부는 AFC의 검토를 맡게 될 것이고, 따라서 밀린 업무량을 줄일 것이다. --Redros64 (대화) 19:36, 2014년 9월 13일 (UTC)[응답]
  • 지원 옵션 2.컷다운 기준 리스트보다 전체 리스트에 더 잘 들어맞는다.위에서 언급한 바와 같이 초안 공간이 "여기에 머물 것"인 경우, 예쁜 위키프로젝트 기사 수 표에 정확히 포함되어야 한다. 여기서 나의 질의를 참조하십시오.The-Pope (대화) 2014년 9월 14일 (UTC) 10:47[응답]
  • 지원 3, 그러나 2는 첫 단계로 받아들일 수 있다. 나는 왜 그것이 단계를 밟아야 하는지 모르겠다. 그것은 거의 파괴적이지 않을 것이다.위키피디아 주제나 정보를 사용하고 싶지 않은 개인 편집자는 누구나 쉽게 무시할 수 있지만, 각 프로젝트에서 1명이라도 관심을 기울인다면 더 좋은 평가를 받는 데 도움이 될 것이다. DGG (토크 ) 09:06, 2014년 9월 23일 (UTC)[응답]

편집자 보존을 위키백과 이름 공간으로 옮겨야 할까?

토론의 주창자가 그 제안을 철회했다.—David Levy 02:05, 2014년 9월 15일 (UTC)

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

위키백과를 옮기자고 제안한다.프로젝트 공간에서 위키백과로 위키프로젝트 편집기 보존:네임스페이스.새로운 편집자와 구 편집자를 보다 체계적으로 보유하기 위한 가이드라인에 대한 공감대를 얻을 수 있기를 바라는 마음에서 이번 프로젝트를 단순한 또 다른 위키프로젝트 이상으로 정착시키기 위해서일 것이다.

  • 제안자로서의 지원 이 프로젝트는 찻집과 비슷하게 편집자 고정 문제를 다루기 위해 더 잘 알려진 백과사전이 되기 위해 몇 안 되는 편집자들의 단순한 협력 이상의 것으로 알려진 몇 안 되는 프로젝트 중 하나가 되었다.--마크 밀러 (talk) 08:25, 2014년 9월 14일 (UTC)[응답]
  • 주석 위키백과 네임스페이스는 프로젝트 네임스페이스입니다, WP:프로젝트 네임스페이스를 참조하십시오.당신이 의미하는 것은 페이지 제목에서 "Wiki Project" 부분을 삭제하는 것이다.하지만 새로운 제목은 무엇일까?그냥 "위키피디아:편집기 보존"?그것은 당신이 최종적인 합의 지침을 찾을 수 있는 곳처럼 들리는데, 그것들을 다루는 프로젝트가 아니다.위키프로젝트가 되는게 뭐가 문제야?단지 그것들이 엄청나게 다른 크기와 범위들로 나온다고 해서 그것들이 모두 중요하지 않다는 것을 의미하지는 않는다.— HHHIPO 08:51, 2014년 9월 14일 (UTC)[응답]
    • 위키프로젝트에 문제가 있는지 묻는 이유는?그 제안은 단순히 프로젝트 공간에서 위키나메 공간으로 옮겨가는 것이다.당신이 분명히 보여주듯이...차이가 있다(많지 않더라도).예, 위키백과:Editor Retention이 제안된 이름이 될 것이다.--Mark Miller (talk) 09:06, 2014년 9월 14일 (UTC)[응답]
    네가 쓰고 싶은 글을 쓰기 때문에 물어보는 거야.프로젝트를 또 하나의 위키프로젝트 이상으로 확립한다.그것은 마치 당신이 이 프로젝트가 위키프로젝트로 분류되는 단점을 보는 것처럼 들리지만, 나는 왜 그런지 모르겠다.나는 이유가 없다고 주장하는 것이 아니라 단지 그것을 보지 못할 뿐이다, 그래서 나는 묻는다.
    예를 들어보자: 접근성에 관한 위키프로젝트가 있다.그들의 프로젝트 페이지는 위키피디아에 있다.위키프로젝트 접근성 및 위키백과에서 수행한 지침:접근성(리디렉션 뒤의 경우)마찬가지로, 위키백과에 편집자 보유에 관한 지침을 두는 것이 좋을 것 같다.편집자 보존. 그러나 모든 하위 페이지가 포함된 전체 프로젝트 페이지를 해당 이름으로 이동해야 하는 이유를 모르겠다.
    이름공간이 무슨 뜻인지 잘 모르겠어.기술적으로 Project: 및 Wikipedia:는 동일한 네임스페이스에 대한 별칭이다.프로젝트 예시:마을 펌프, 위키피디아와 같은 페이지를 가리키고 있다.마을 펌프.프로젝트 공간에서 위키백과로 이동할 수 없는 경우:네임스페이스, "Wiki Project" 부분을 이 Wiki Project에 속하는 모든 페이지의 페이지 이름에 삭제하면 된다.그리고 내가 묻고 싶은 것은 왜 이런 일을 하고 싶은가 하는 것 뿐이다. 옛 이름들이 왜 잘못된 것인가, 그리고 새로운 장소가 프로젝트 페이지보다는 결과를 담아야 하지 않을까?이제 좀 더 명확하게 되었으면 좋겠는데 — HHHIPO 09:55, 2014년 9월 14일 (UTC)[응답하라]
    그렇지는 않다.나와 속단하는 것은 최선의 방법이 아니다.당신은 위키프로젝트에 대한 불신임을 비난하기 위해 비약하는 것 같은데 그것은 잘못된 것이다.그건 네 탓이야.그것은 사실이 아니며 단지 악의의 큰 도약을 할 뿐이다.네가 말하려는 건 이해하지만, 우리는 두 개의 공간이 따로 있어.위키프로젝트가 위키나메 공간에 있는 동안 그것은 프로젝트 공간이며, 나의 희망은 편집자 유지가 단순한 편집자의 지역적 합의 이상의 것으로 격상되어 일반 커뮤니티의 넓은 범위에 포함되기를 바란다.고마워.--마크 밀러 (대화) 2014년 9월 14일 (UTC) 10시 4분 (답변)
    나는 너를 비난하려고 하지 않아, 내가 충분히 명확하지 않았다면 미안해.난 단지 네가 실제로 제안하는 것이 무엇이고 왜 그런지를 묻는 거야.나는 과학자야, 내가 대답의 존재하지 않는 것을 암시하고 싶다는 뜻이 아닌 질문을 할 때, 그것은 단지 내가 답이 무엇인지에 관심이 있다는 것을 의미해!위키나메 공간은 무슨 뜻이고 프로젝트 공간은 어떤 의미인지 설명해 주시겠습니까?원래 게시물에서는 미디어위키 소프트웨어의 틀에서 "네임스페이스"라는 기술적 의미에 명시적으로 링크했지만, 그게 정말 의미인지 잘 모르겠다.
    나는 위키프로젝트의 문제점을 묻지 않았고, 편집자 리텐션을 위키프로젝트라고 부르는 것이 무엇이 문제인지 물었다.그것은 위키프로젝트에 대해 나쁜 것을 의미하지 않으며, 당신이 위키프로젝트에 반대하는 것을 의미하지도 않는다.그냥 네가 왜 지금의 상황을 바꾸려고 하는지 관심이 있다는 뜻이야.누군가가 무언가를 제안할 때 "왜?"라고 묻는 것이 정말 그렇게 비난받을 만 한 것일까?— HHHIPO 10:54, 2014년 9월 14일 (UTC)[응답]
    위와 같은 말씀에 대단히 감사드린다.위키피디아는 이러한 정의를 위한 두 페이지를 가지고 있다.그 표현은 사람들이 그들이 같은 것이라고 가정하는 반면, 함께, 함께라면...사실 그렇지 않다.위키백과:네임스페이스는 단순히 더 이상의 연장이 없는 위키백과 페이지일 뿐이며, 위키백과는 다음과 같이 일반 커뮤니티의 더 넓은 합의로 정의되었다.프로젝트 네임스페이스는 협력 편집자들로 구성된 소규모 밴드의 지역적 합의사항이다.지역적 합의가 더 넓은 지역사회의 합의를 무시할 수는 없다.만약 이 두 페이지가 실제로 똑같다면, 위키피디아는 공간을 정의하는 두 개의 분리된 페이지를 갖고 싶어하지 않을 것이다.나는 위키백과 프로젝트 전체를 개선하는 데 도움이 될 수 있는 가이드라인을 형성하기 위해 편집자 보존을 더 넓은 지역사회에 도입하고자 한다.그것이 어떻게 성취될 수 있는가는 더 넓은 공동체를 통해서만 가능하다."왜?"라고 묻는 것은 결코 비난할 수 없지만, 위키프로젝트가 되는 것에 "잘못된" 것이 있다고 가정하는 것뿐이다.하지만...위키프로젝트에는 한계가 있고, 나는 정말로 에디터 보존이 위키프로젝트 공간의 경계를 넘어섰으며, 여러 면에서 위키백과의 진정한 발전이 될 수 있다고 믿는다.단순히 제안된 지침을 발전시킴으로써가 아니라 실제로 편집자들에게 보다 능동적인 접근법을 취함으로써 백과사전이 어떻게 기능하는지 배우고 새로운 편집자와 구 편집자 모두에게 그들의 경험을 보다 긍정적이고 생산적으로 만드는 방향으로 안내하는 것을 돕는다.내가 화를 낸 것에 대해 진심으로 사과한다.그것은 단지 내가 그 프로젝트에 문제가 있다고 가정하는 표현에 있었다.나는 하지 않아.로마 프로젝트를 되살리려는 시도는 물론 다른 프로젝트 몇 개를 직접 설립하는 등 여러 방면에서 나는 그 프로젝트들에 매우 적극적이었다...편집자 유지는 데니스 브라운에 의해 설립되었지만, 그것은 내가 위키피디아에 기고하는 데 있어 중요한 부분을 차지하기 위해 취한 것이다.이 프로젝트에 기여하는 많은 편집자들이 있고 위키백과라고 부르는 전반적인 프로젝트의 선두에 그들의 작품을 올려놓는 것이 나의 희망이다.항상 그렇듯이 합의는 이것이 일어나야 하는지를 결정할 것이다.성공했으면 좋겠지만...만약 그것이 위키프로젝트로 남아 있다면, 그것은 단지 그것처럼 제한될 수도 있고 아닐 수도 있는 한 같은 노선을 따라 계속될 것이다.다시 한번 고마워!--마크 밀러 (대화) 11시 41분, 2014년 9월 14일 (UTC)[응답]
    @Mark Miller:나는 네가 페이지 제목을 잘못 해석하고 있다고 생각한다.
    이름이 "Wikipedia:"로 접두사인 페이지(예: 위키백과):위키프로젝트 편집자 보존 - 위키백과 네임스페이스에 있지만, 프로젝트: 네임스페이스에도 있다.두 사람은 뗄래야 뗄 수 없는 사이다.
    그래서, 당신의 원래의 제안을 받아들이기 위해, 위키피디아를 이동시키기 위해:프로젝트 공간에서 위키백과에 이르는 위키프로젝트 편집자 보존: 네임스페이스, 이것은 할 수 없다. 왜냐하면 이미 거기 있기 때문이다.내가 생각하기에 당신이 요청하는 것은 위키피디아의 기존 페이지: 위키피디아라고 불리는 네임스페이스:Wiki Project Editor Retention은 위키백과:편집기 보존.그것은 간단한 페이지 이름 변경이며 네임스페이스의 변경은 수반하지 않는다. --Redrose64 (대화) 16:26, 2014년 9월 14일 (UTC)[응답]
    고마워. 프로젝트 공간은 명실공간에 있지만 여전히 지역적 합의로 프로젝트 공간이 한정되어 있다는 것을 보니 나에게 있어 관점의 문제라고 생각한다.--마크 밀러 (토크) 22:14, 2014년 9월 14일 (UTC)[응답]
    프로젝트 공간 = 위키백과 공간.위키백과 공간 = 프로젝트 공간.차이도, 구별도 없다. --Redrose64 (대화) 23:29, 2014년 9월 14일 (UTC)[응답]
  • 더 설득력 있는 이유가 제시될 때까지/없이는 현재로서는 반대한다.위키프로젝트의 '워킹 그룹' 측면이 마음에 들고, 모든 편집자가 편집자 보존에 신경 쓰는 것은 아니기 때문에 참여자 명단이 도움이 된다.나는 평이한 WP: 현재 정보, 에세이, 정책 등에 더 많이 사용되고 있다는 것에 동의한다.찻집은 토론과 공감대를 형성하는 포럼이 아니라 정말 헬프 데스크라는 것을 보여준다.또한 일반적인 논의를 많이 끌어들이지만 위키프로젝트에 비해 초점을 덜 맞춘 '마을 펌프스'도 있다.그러나 나는 WP가 다음과 같은 점에 동의한다.WER은 중요한 역할을 가지고 있고 더 넓은 참여가 필요할 수 있다.—안네 들롱 (대화) 11:52, 2014년 9월 14일 (UTC)[응답]
  • Anne Delong과 같은 이유로 반대하라 - 그것은 하나의 프로젝트이고 좋은 것이고, 그 이름에 들어맞는다.더그웰러 (대화) 2014년 9월 14일 (UTC) 16:54 [응답]
  • 반대. 마크 밀러의 네임스페이스 설정에 대한 오해(위에서 설명한 것)를 제쳐두고, 나는 이 경우 "위키프로젝트" 지정을 철회하는 것이 도움이 될 것이라는 데 동의하지 않는다.위키프로젝트 편집기 보존은 위키프로젝트들이 보통 하는 것과 똑같이 기능하며, 나는 그것을 변경하거나 정확한 설명을 변경할 이유가 없다고 본다.—David Levy 16:57, 2014년 9월 14일 (UTC)[응답]
  • 위의 조언과 코멘트에 따라 철회되었고, 아이삭과 함께 내 토크 페이지에서 논의한 내용에 따라 나는 내가 추구하는 목표에 필요하지 않기 때문에 이 제안을 철회할 것이다.우리는 무언가를 허물 필요가 없다, 다른 것을 쌓기 위해서.입력해줘서 고마워!--Mark Miller (토크) 00:00, 2014년 9월 15일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.


원본 연구의 검증 가능 범위 및 정의에 관한 제안

검증가능성에 대한 지역적 해석에 대한 우리의 입장을 우려하는 제안이 있다.현재 이 제안에 대한 반응은 대부분 토론을 일으킨 위키프로젝트와 밀접한 관련이 있는 회원들의 반응이다.나는 그 제안이 좀 더 넓은 관점에서 도움이 될 수 있다고 믿는다.감사합니다.Samsara (FA • FP) 16:54, 2014년 9월 13일 (UTC)[응답]

이것은 샌프란시스코의 스카이라인과 똑같이 생긴 이 사진이 정말로 샌프란시스코의 스카이라인의 사진이라고 하는 믿을 만한 출처가 없다면 기사에 이미지를 사용할 수 있는지에 대한 논의다.WhatamIdoing (talk) 00:11, 2014년 9월 16일 (UTC)[응답]

새 네임스페이스: 태스크포스... 또는 클럽

나는 사람들이 사회 그룹이나 업무 지향적인 그룹과 같은 느슨한 그룹을 만들어, 그들이 관련 관심 분야의 특정 주제에 관한 항목을 편집하는 것을 돕기 위해 같은 생각을 가진 편집자들을 모을 수 있는 공간이 필요하다고 생각한다.나는 우리가 "태스크포스"라고 불리는 새로운 네임스페이스를 가질 것을 제안한다. 그것은 클럽이라고 불릴 수도 있지만, 그것은 내가 이 아이디어에 대한 두 번째 덜 선호하는 것이다.

나는 우리가 이미 이것과 위키피디아 주제를 위한 포털 공간을 가지고 있다는 것을 알지만, 그것은 같지 않다.이것은 더 비공식적이고, 사람들이 원하는 어떤 주제나 일련의 주제에 대해 그룹화 될 것이다.

여기서 더 많은 관심을 끌고 위키백과 편집에 더 많은 에너지와 활동을 창출하는 이점이 있을 것이다.

댓글? --Sm8900 (대화) 13:39, 2014년 9월 12일 (UTC)[응답]

이것과 위키프로젝트의 차이점은 무엇인가?샘 월튼 (대화) 14:09, 2014년 9월 12일 (UTC)[응답]
너의 코멘트에 감사한다.특정 주제에 대한 위키프로젝트는 하나만 있을 수 있다.이것은 어떤 사람이나 그룹의 사람들이 어떤 주제나 주제에 대해 정확하게 존재하는 위키피디아 주체가 있더라도, 어떤 주제나 주제에 대한 편집을 위해 그들만의 클럽을 만들 수 있게 한다. --Sm8900 (대화) 14:19, 2014년 9월 12일 (UTC)[응답]
차이점을 보지 못하는 것.프로젝트 멤버들은 지금 주기적으로 그것을 할 것이다.당신의 제안은 단지 위키피디아에 사회적 상호작용을 더하기 위한 것인가?GenQuest"Talk to Me" 14:24, 2014년 9월 12일 (UTC)[응답]
위키프로젝트들은 종종 중복되는 영역을 가지고 있다.특정 주제에 대해 하나 이상의 위키프로젝트가 있을 수 있으며, 태스크포스 시스템을 통해 관련되는 경우가 많다.예를 들어, 철도는 위키프로젝트 열차 아래에 있고, 영국의 철도는 위키프로젝트 영국 철도 아래에 있고, 스코틀랜드의 위키프로젝트 운송 아래에 있는 철도, 그리고 위키프로젝트 열차/로코모티브 태스크포스 아래에 있는 철도 기관차는 있다.Talk와 같은 토크 페이지:NBR 224 및 420 클래스에 Wiki Project 배너가 하나 있음 -{{WikiProject Trains}}- 하지만 다양한 매개 변수 포함 UK=yes Scotland=yes locos=yes다른 모든 프로젝트와 태스크포스(TF)를 도입하는 것.게다가 기사의 토크 페이지에는 하나 이상의 위키프로젝트 배너 템플릿이 있을 수 있다. --Redros64 (토크) 15:11, 2014년 9월 12일 (UTC)[응답]
나는 우리의 기존 태스크포스 구조는 이것들을 잘 처리한다고 생각한다. bd2412T 16:33, 2014년 9월 12일 (UTC)[응답]
나는 웹 상에 존재하는 상호작용을 위한 방대한 잠재력을 이용하려고 한다. 만약 우리가 사람들에게 흥미와 활동을 공유할 수 있는 그들 자신의 비공식적인 편집자 그룹을 훨씬 더 많이 이용할 수 있는 기회를 제공한다면 우리는 훨씬 더 많은 의견을 낼 수 있다.나는 예를 들어, 하나의 위키피디아 대상 미국만 있으면 안 된다는 것이다; 사람들이 그것을 원한다면 10개가 있어야 한다. 그래서 이것은 좀 더 비공식적이고 상호 작용적일 것이다. --Sm8900 (대화) 20:52, 2014년 9월 12일 (UTC)[응답]
혼돈처럼 들리네.10개 그룹이 서로 동의한다면 그것은 노력의 중복이다; 그들 중 5개 그룹이 나머지 5개 그룹에 동의하지 않으면, 그 다음엔 어떻게 되는가? --Redros64 (토크) 21:07, 2014년 9월 12일 (UTC)[응답]
글쎄, 어떤 의견 불일치는 기사 편집 자체에서만 일어날 수 있어.특히 단일 기사에 대한 편집이나 충돌이 훨씬 더 많이 일어날 것이라고 생각할 이유가 없다.이렇게 하면 서로 다른 이익집단에 각각 어필하는 다수의 개별 기사에 대해 훨씬 더 적은 양의 활동을 발생시킬 가능성이 훨씬 높다.
그러므로 예를 들어, 100명의 새로운 편집자들이 동시에 미국을 편집하려 할 것이라고는 기대하지 않을 것이다; 오히려 우리는 Civl War와 Old Western에 더 관심을 기울일 한 그룹, 그리고 Theodore Roosevelt와 Progressive 시대 등에 더 관심을 기울일 다른 그룹을 얻을 수도 있을 것이다. --Sm8900 (대화) 22:12, 2014년 9월 12일 (UTC)플라이]
기사토크 페이지가 그 특정 기사를 다루는 토론의 가장 적합한 장소가 아닌 이유, 위키프로젝트 토크 페이지가 하나 이상의 기사를 다루는 토론의 가장 적합한 장소가 아닌 이유를 아직도 모르겠다. --Redros64 (토크) 22:41, 2014년 9월 12일 (UTC)[응답]
나는 또한 그것이 POV를 지향하는 이익집단을 부추길지도 모른다는 경계심을 갖고 있다.알제 (대화) 02:41, 2014년 9월 13일 (UTC)[응답]
나도 회의적이다.우리는 이미 기사와 사용자 토크, 위키프로젝트, 태스크포스, 그리고 다양한 더 전문화된 토론 장소를 가지고 있다.이것으로는 다루지 않는 사용 사례가 보이지 않는다.그리고 설사 우리가 다른 종류의 토론 페이지를 만들고 싶어도, 왜 그것만의 네임스페이스가 필요할까?위키프로젝트도 그런 건 없어 — HHHIPO 11:03, 2014년 9월 13일 (UTC)[응답]
음, 좋아. 새로운 유형의 항목으로 구현하는 건 어때? 하지만 새로운 네임스페이스는 사용하지 않고?어떻게 생각하는지 알려줘. --Sm8900 (대화) 00:49, 2014년 9월 14일 (UTC)[응답]
나는 여전히 어제와 같은 생각을 한다.기존의 토론장 유형으로는 다루지 않는 사용 사례가 보이지 않는다.— HHHIPO 09:59, 2014년 9월 14일 (UTC)[응답]

흐음, 알았어. 다른 언급하고 싶은 사람? --Sm8900 (대화) 19:08, 2014년 9월 15일 (UTC)[응답]

위에서 "특정 주제에 대한 위키프로젝트는 하나만 있을 수 있다"고 쓰셨습니다.이것은 사실이 아니다.가이드라인에는 '두 개의 별도 편집인 그룹이 같은 기사에 관심을 갖는 것을 금지하는 규정은 없다'고 돼 있다.비효율적이기 때문에 권하지는 않지만, 우연히 기존의 위키프로젝트와 동일한 범위를 갖는 위키프로젝트를 설정하는 것은 완벽하게 "법적"이다.WhatamIdoing (talk) 00:08, 2014년 9월 16일 (UTC)[응답]

종료 호출

컨센서스는 (위의 HHHippo에 따르면) "필요하지 않은 것 같다"거나 너무 불분명/집중되지 않아 추후 정제 및 재제출이 필요하다.의견의 불일치로 이 제안을 종결시킬 것을 요청하라.GenQuest 18:56, 2014년 9월 16일 (UTC)[응답]

커뮤니티 포털

이 포털의 섹션 "도움말"에는 "이들 기사 만들기", "전 세계적인 관점을 나타냄" 및 "역사 정보 추가"도 포함되어야 한다. 영어 위키백과에는 세계화 또는 역사적 정보를 필요로 하는 처리되지 않은 주목할 만한 기사들과 기사들이 여전히 많이 존재하기 때문에, 이러한 문제들은 u를 요구하는 기사들보다 덜 중요한 것이 아니다.pdate. 그런데, 과거에는 이 섹션에 "Create"라는 블록이 있었다(정확한 이름을 잊어버렸다, 미처리 기사를 말한다).--RekishiEJ (토크) 15:39, 2014년 9월 16일 (UTC)[응답]

그리고 {{최근 변경 기사 요청}}}은 템플릿에 처리되지 않은 주목할 만한 기사가 포함되어 있으므로 "이 기사 만들기" 블록으로 옮겨야 한다.--RekishiEJ (토크) 15:41, 2014년 9월 16일 (UTC)[응답]

개인 이름

백과사전처럼 위키피디아는 교육을 위한 힘이지만, 개인 이름 분야에서는 너무 자주 실패한다.내가 생각하고 있는 특별한 이름은 동아시아 이름이다.중국, 일본, 한국의 모든 지역에서, 여러분이 원하는 대로 부를 성씨, 성씨, 성씨, 성씨, 성씨, 성씨, 성씨, 성씨, 성씨 등이 주어지거나 개인 이름 앞에 놓여진다.일부 기사는 이 관례를 따르지만 대부분은 따르지 않는다.

동아시아인들이 지미 웨일스를 "웨일즈 지미"라고 부르는 것이 예의일까, 아니면 에이브러햄 링컨을 "링컨 에이브러햄"이라고 부르는 것이 예의일까?그렇지 않다면 다른 사람들의 이름에 적절한 질서를 사용해야 하지 않을까?— 80.177.125.188 (대화) 10:56, 2014년 9월 18일(UTC)에 의해 추가된 이전의 부호 없는 의견

그것은 관련된 스타일 매뉴얼에 따라 달라진다.AFAIK는 MOS:JAPAN에 따른 서양의 기브네임-스루네임 오더에서 현대식 일본식 명칭을 제시해야 하며, 그 외 대부분의 동아시아식 명칭은 기브네임 오더네임 컨벤션에서 제시해야 한다.그 이유는 영어의 신뢰할 수 있는 출처가 거의 항상 서구의 일본식 이름을 사용하지만 동아시아식 이름에서는 다른 것과 일관되지 않기 때문이다.—패릭스 (t c) 11:45, 2014년 9월 18일 (UTC)[응답]
TheFarix가 말했듯이, 위키피디아의 규칙은 우리가 출처의 스타일을 따라야 한다고 명시한다.그래서 미국과 영국 언론이 K.J. Choi라고 쓰면 우리는 최경주를 쓰지 않아. --NaBUru38 (대화) 17:57, 2014년 9월 18일 (UTC)[응답]
내 코멘트는 기사 제목에 대한 것이 아니라 인용 템플릿이 이것을 가능하게 하는 메모에 관한 것이다.성씨가 먼저인 아시아식 이름을 가진 경우, "last="와 "first="를 사용하여 저자 이름을 지정하지 말고 "last="를 전체 이름에 사용하거나, "last="를 선호하기 때문에 "last="를 사용하십시오.예를 들어 템플릿:Cite_book#자세한 내용을 보려면 작성자.제이슨 퀸 (토크) 2014년 9월 18일 (UTC) 19:04 [응답]

일별 감시 목록을 구분하지 않는 옵션

낮까지 감시원이 고장나지 않았으면 좋겠다.아침에 로그인할 때 마지막 X시간 동안의 모든 변경 사항을 보고 싶다.자정 이후 모든 것이 바뀌는 것은 아니고, 다른 곳에서 자정까지 바뀐다.생각?가이진42 (대화) 14:38, 2014년 9월 4일 (UTC)[응답]

  • 지원 나도 이것을 보고 싶다.나는 내 워치리스트에 있는 기사에서 한 번에 여러 일분의 편집량을 체크하는 경향이 있다.며칠에 걸친 결별은 내가 그 기사를 마지막으로 본 이후로 모든 변화를 찾기 위해 내가 해야 할 많은 클릭을 추가했을 뿐이다.특히 "가장 최근의 변화뿐만 아니라 모든 변화를 보여주기 위해 감시목록을 확장"하는 선호도의 동작은 페이지가 여러 날 동안 변경될 때 이상적이지 않다.마지막으로 체크아웃한 시점부터 현재 버전까지 내 워치리스트에서 페이지를 한 번 클릭해 보고 싶다.그러나 마지막 방문 링크 이후의 변경 사항은 현재 날짜로 제한된다.PaleAqua (토크) 00:24, 2014년 9월 5일 (UTC)[응답]
@개진42와 팔레아콰 : 며칠을 한꺼번에 볼 수 있어서 여기서 문제를 해결하려고 한다.Preferences(기본 설정) → 최근 변경 내용:
  • 최근 변경사항 및 감시목록의 페이지별 변경사항 그룹화
  • 최근 변경 사항에서 Wikidata 편집 내용을 기본적으로 표시
및 Preferences → Watchlist for:
  • 감시 목록에 표시할 일 수:
  • 감시 목록에 표시할 최대 변경 수:
  • 최근 변경 사항뿐만 아니라 모든 변경 사항을 표시하도록 감시 목록 확장
  • 감시 목록에서 부분 편집 숨기기
  • 감시 목록에서 봇 편집 숨기기
  • 감시 목록에서 편집한 내용 숨기기
  • 감시 목록에서 익명 사용자의 편집 내용 숨기기
  • 감시 목록에서 로그인한 사용자가 편집한 내용 숨기기
  • 감시 목록에 Wikidata 편집 표시
이 모든 것이 이 문제와 직접적인 관련이 있는 것은 아니지만, 나는 당신의 설정이 내 것과 어떻게 다른지 보고 싶다. --Redros64 (토크) 08:46, 2014년 9월 5일 (UTC)[응답]
나는 가이진42와 팔레아콰와 같은 상황에 처해 있다: 나는 내 감시목록에서 며칠을 볼 수 있지만 그것들은 나날이 그룹화된다.어제 그룹과 오늘의 그룹에도 나타나는 바쁜 기사에 대한 "n changes" 링크는 그날의 변화만 보여준다.오늘 그룹 엔트리에 오늘뿐 아니라 내가 마지막으로 방문한 이후 어제까지 바뀐 기사에 대한 '마지막 방문 이후 변화' 링크가 없다.더 잘 어울리는 조합이 있으면 좋겠다.내 설정:
Preferences → 최근 변경 사항:
Y 그룹은 최근 변경 사항 및 감시 목록에서 페이지별로 변경됨(아래 "Wikidata 표시" 옵션에 대해 비활성화됨)
- 최근 변경 사항 및 감시 목록에서 Wikidata 편집 내용을 기본적으로 표시(향상된 변경 사항에서는 아직 작동하지 않음)
및 Preferences → Watchlist for:
3일 동안 감시 목록에 표시:
999 확장된 감시 목록에 표시할 최대 변경 횟수: (이유가 있었나 보군 - 뭔지 궁금하군)
Y 가장 최근의 변경 사항뿐만 아니라 모든 변경 사항을 표시하도록 감시 목록 확장
- 감시 목록에서 부분 편집 숨기기
- 감시 목록에서 봇 편집 숨기기
- 감시 목록에서 편집한 내용 숨기기
- 감시 목록에서 익명 사용자의 편집 내용 숨기기
- 감시 목록에서 로그인한 사용자의 편집 내용 숨기기
Watchlist NebY (talk) 11:44, 2014년 9월 5일 (UTC)에서 Y Show Wikidata 편집 [응답]
내 선호도는 NebY와 매우 유사하다. 10일, 1000 변경, 확장에 대해 확인됨, 편집한 내용 숨기기, 위키 데이터 표시, 그룹 변경사항(모두 꺼짐) 팔레아콰 (대화) 12:34, 2014년 9월 5일 (UTC)[응답]
  • 지지하다.@Redrose64:관련 설정은 "최근 변경사항 및 감시목록의 페이지별 변경사항"과 "최신 변경사항뿐만 아니라 모든 변경사항을 표시하도록 감시목록 확장"이라고 생각한다.이 두 개가 활성화되면 감시 목록에는 기본적으로 각 페이지에 대해 해당 날짜 내에 해당 페이지 기록의 일부가 수록된다.그러나, 며칠으로부터의 방문하지 않은 변화가 있을 때(이것은 자정을 전후한 지난 밤처럼 사소한 것일 수도 있다), 각 페이지의 역사 조각은 한 곳에 있는 것이 아니라, 매일 하나의 조각이 있다.원칙적으로는 두 가지 해결책이 있다: a) 일별로 그룹화 제거, b) 섹션 제목을 유지하되, 마지막 변경 날짜와 시간에 배치된 단일 확장 가능한 목록에서 특정 페이지에 대한 모든 변경사항을 표시한다.두 경우 모두 시간뿐만 아니라 각 개인의 변경 날짜도 표시해야 하는 단점이 있을 것이다.그러나 나는 그것이 한 페이지의 모든 변경을 한 리스트에 포함하는 것에 대해 지불할 가치가 있는 대가라고 생각하는데, 적어도 하나의 옵션으로서 (즉, 사용자 선호도)가 있다면 좋을 것이다.
내 워치리스트에서 현재 버전으로 마지막으로 체크아웃한 시점 사이의 페이지 디프까지 클릭 한 번으로, 그것은 정확히 동일하지 않다. 즉, 낮별로 그룹화 여부와 관계없이, 마지막으로 방문한 페이지가 워치리스트에서 선택한 시간 범위 내에 있는 경우에만 이러한 링크를 사용할 수 있다.이 경우 마지막으로 방문한 변경사항의 "커브" 링크는 설명(그리고 매우 유용함) 기능을 가진다.마지막으로 방문한 변경이 선택된 시간 범위 내에 있지 않더라도 이러한 직접 링크를 이용할 수 있다면 좋을 것이다.예를 들어 "마지막 방문 이후 xx" 링크는 "감시 목록 시간 범위 내 모든 방문되지 않은 변경" 또는 현재 "당일 방문되지 않은 모든 변경사항"이 아닌 "방문되지 않은 모든 변경사항"을 가리킬 수 있다.— HHHIPO 22:01, 2014년 9월 7일 (UTC)[응답]
  • 지원:이게 다시 살아날 수 있는 방법이라도?밤샘 휴식 후 꺼내는 워치리스트에 자주 바뀌는 당신의 모든 워치리스트 항목이 두 번 나타나는 것은 늘 나를 짜증나게 했다.이 마을 펌프 페이지에 너무 흔하게 나타나는데, 누군가 분명히 좋은 아이디어를 생각해 내고, 두어 명의 사람들이 지지해 주고, 문제가 마무리되고, 얼마 지나지 않아 두 개의 기록 보관소를 뒤에 묻어버린다!개발자들은 가능한 모든 개선사항을 이해할 수 없다는 것을 알지만, 누가 무엇을 어떻게 선택할 것인가?: 노이스터(토크), 10:33, 2014년 9월 22일 (UTC)[응답]
    • 위의 코멘트를 바탕으로 Special:에서 "가장 최근의 변화뿐만 아니라 모든 변화를 보여주는 감시 목록 확장"을 해제하면 이 문제를 해결할 수 있다.기본 설정#mw-prefection-watchlist 또는 최근 변경사항에 대한 "최근 변경사항 및 감시 목록의 페이지별 변경사항(아래 "Wikidata 표시" 선택사항에 대해 비활성화")을 해제하여 설정한다.
      절차상의 질문에 대해, 사람들은 소프트웨어 변경에 대한 좋은 아이디어를 가지고 있을 때, 그것을 bugzilla에 제출한다: 대부분의 자원 봉사자들과 직원들이 소프트웨어 아이디어를 추적하는 곳이다.RedRose64는 다른 많은 사람들이 이 게시판을 읽는 것처럼 거기에 계정을 가지고 있다.(계정은 무료지만 [a] 스팸 발송자에게 당신의 이메일 주소를 표시하고 [b] Bugzilla는 곧 Phabricator로 대체될 예정인데, 이 결함은 없다.)Whatamidoing (WMF) (토크) 15:10, 2014년 9월 22일 (UTC)[응답]
      • 고마워, 너의 첫 번째 제안은 "모든 변화를 보여주기 위해 감시목록을 확장하지 말아라...''는 원하는 결과를 얻은 것 같다. 즉, 어제와 오늘 모두 바뀐 페이지는 양일간 지속된다면 오늘날의 감시 목록에만 표시된다.(두 번째 제안은 사태를 더 악화시켰다.문제는 해결됐습니다.
        다른 문제라면 여기 빌리지 펌프에서 20명의 사용자가 Change A를 지원할 수 있고, 외로운 늑대는 Bugzilla에서 Change B를 요청할 수 있는데, 다른 사람들은 모두 동의하지 않을 수 있고, Change B가 만들어지는 것은 Change B라는 것을 이해하겠는가?의심의 여지가 없는 논의는 다른 곳에서 이루어지지만, 어디에서 이루어지는가?: 노이스터(토크), 2014년 9월 22일(UTC) 16:36[응답]
        • 그건 복잡해.사상은 사방에서 논의되는 경향이 있다.메타에서 토론을 중앙집중화하려는 시도가 있었지만, 단일 프로젝트 편집자(및 영어 및/또는 독일어를 잘 하지 못하는 사람)는 다른 곳에서 일어나는 토론을 추적하기가 어렵기 때문에 모든 것을 자신의 프로젝트, 자신의 언어로 토론하는 것을 이상적으로 선호할 것이다(우리는 글로벌 감시 목록이 필요하며, 우리는 M.몇 년 안에...SUL 최종화가 내년에 성공한다고 가정할 때)하지만, 800개 이상의 WMF wkis가 있고 250개 이상의 언어를 다룬다.위치 Y에서 아이디어 X에 대해 이야기하도록 강요할 수는 없다. 만약 그들이 다른 페이지에서 이야기한다면 말이다.("다른 페이지에서 토론해 주십시요!"라고 쓰여진 메모를 얼마나 자주 볼 수 있는지 생각해 보십시오.)좋은 소식은, 더 큰 규모의 프로젝트에는 적어도 좋은 기술 홍보대사들이 있다는 것이다. 그들은 정보를 서로 연결하는 데 많은 시간을 소비한다.운 좋게도 그들 중 한 명은 당신의 체인지 B 요청을 알아차리고 이야기의 다른 면을 제공할 것이다.또한, 개발자(스태프와 자원 봉사자)는 그들의 경험이 논쟁이 될 가능성이 있는 것이라면 지역사회의 합의의 증거를 요구하는 버그 티켓을 차단할 것이다.
          이 일에 대한 완벽한 해결책이 있다면, 내 상사가 당신에게서 소식을 듣고 싶어 한다.Whatamidoing (WMF) (토크) 23:11, 2014년 9월 22일 (UTC)[응답]
      • @Whatamidoing (WMF): 아니, 그렇다고 해서 내가 고칠 수 있는 것은 아니다.나는 마지막 변화뿐만 아니라 최근의 모든 변화를 보고 싶기 때문에 "가장 최근의 변화뿐만 아니라 모든 변화를 보여주기 위해 감시목록을 확장"하는 것은 나에게 실행 가능한 선택이 아니다.그러나 나는 주로 페이지별로, 그리고 날짜/시간별로 정렬된 각 그룹 내에서 이러한 변경을 원한다.지금 "최근 변경사항 및 감시목록의 페이지별 변경사항"은 ⑴ 그룹화하지 않고, 날짜/시간별로만 정렬하고, ⑵ 페이지별로 그룹화, 시간별로 선택권을 준다.따라서 "페이지당 그룹"을 사용하더라도 기본 그룹화는 항상 매일 수행된다.하루에 이 그룹화를 볼 수 있는 유일한 이유는 개별 항목의 타임스탬프를 단순화하기 때문이다.그러나 그 다음 역사 페이지는 이것을 하지 않고 잘 작동하는 것처럼 보인다.— HHHIPO 18:45, 2014년 9월 22일 (UTC)[응답]
        • 그래서 내가 이걸 정확히 이해한다면, 네가 얻는 것은 다음과 같다.
2014년 9월 22일
12:04 VisualEditor/상태(2개의 변경 이력) . . . . . [하지구루; Pcoombe (WMF)]
2014년 9월 20일
00:15 VisualEditor/상태(2개의 변경 이력) . . . . . [186.218.110.176; Jdforrester (WMF)]
네가 원하는 건 이것이다:
2014년 9월 22일
12:04 VisualEditor/상태 (4개의 변경 이력) . . . . . [하지구루; Pcoombe (WMF), 186.218.110.176; Jdforrester (WMF)]
그렇지? 아니면 이걸 원해?
2014년 9월 22일
2014년 9월 22일 12:04 VisualEditor/상태(2개 변경 이력) . . . . [Pcoombe (WMF)]
2014년 9월 22일 7:41 VisualEditor/상태(2개 변경 이력) . . (0) . [하지구루]
2014년 9월 20일 00:15 VisualEditor/상태(2개 변경 이력) . . . . . [Jdforrester (WMF)]
2014년 9월 20일 00:07 VisualEditor/상태(2개 변경 이력) . . . . . [186.218.110.176]
Whatamidoing (WMF) (토크) 23:11, 2014년 9월 22일 (UTC)[응답]
뭐, 둘 다, 뭐랄까.당신의 '내가 얻는 것' 예제는 실제 편집 목록이 축소된 요약 줄이며, 첫 번째 '원하는 것' 예도 그렇다.마지막 예는 내가 원하는 것의 소멸되지 않은 버전과 비슷하지만, 실제로는 이렇게 보일 것이다.
2014년 9월 22일 12:04 (cur priv) . . (-433) . Pcoombe (WMF) (토크 기여) (언도 개정 1177949 by 하지구루 (토크))
2014년 9월 22일 07:41 (cur priv) . (+433) . 하지구루 (토크 기여) (새로운 상태 업데이트)
2014년 9월 20일 00:15 (cur previve) . (-23) . Jdforrester (WMF) (토크 기여) (Undo revision 1173489 by 186.218.110.176 (talk) – test edit.) (Tag: HHVM)
2014년 9월 20일 00:07 (cur previous) . (+23) . 186.218.110.176 (talk) (새로운 상태 업데이트) (Tag: 익명 업데이트 프로젝트 상태)
그게 더 쉽다면 역사 페이지처럼 말이야— HHHIPO 20:03, 2014년 9월 23일 (UTC)[응답]
  • 이 섹션은 약간 TL이다.몸이 아프고 몸이 안 좋기 때문에 DR을 하는데 가장 최근의 500개 변화를 표시하도록 설정하고 날짜를 3일이나 7일로 설정하면 항상 500개 이하(내겐 약 24시간 가치, 리스트에 몇 페이지와 어떤 페이지가 있는지 등에 따라 번호가 다를 수 있다)로 표시되기 때문에 하루가 다르게 깨지지 않는다.— {{U 기술 13}} 17:52, 2014년 9월 22일 (UTC)[응답]
아니, 그건 나한테는 소용없어. 난 아직 낮에는 그룹화가 있어.500개의 편집한도가 당신의 감시목록을 현재로 제한한다면 효과가 있을 것 같은데, 나는 하루에 100개 정도 밖에 변화가 없고, 며칠을 보고 싶다.
추신: 빨리 나으렴! — HHHIPO 18:45, 2014년 9월 22일 (UTC)[응답하라]
그래서, 나는 확실하지 않았다.하루에 약 100개의 변화를 받고 72시간 정도의 가치를 보고자 하는 겁니다.지난 5일 동안 300개의 변경사항을 표시하도록 설정하면 최대 300개의 변경사항이 항상 표시되며(반올림 약 72시간)만약 당신이 단지 그 날의 헤더 라인을 없애고 싶다면, 그것은 당신이 그것을 숨기는 사용자 스크립트(조금 파헤치지 않고서 나는 그것이 당신을 위해 그것을 숨기는 css나 js 스크립트인지 말할 수 없다)로 하는 것이 쉬워야 한다.— {{U 기술 13} 13:37, 2014년 9월 23일 (UTC)[응답]
watchlisted 페이지는 예측할 수 없는 빈도로 편집되며, 100개의 변경사항이 24시간 또는 다른 기간에 해당하는 경우가 항상 있는 것은 아니다.최근 3일 또는 5일 내에 모든 변경 사항을 표시하려면 감시 목록에 표시할 일 수: 3(또는 5) 및 감시 목록에 표시할 최대 변경 수: 0으로 설정하십시오.CSS를 사용하여 감시 목록 날짜 표제를 숨길 수 있으며, Javascript가 필요하지 않음:
칸막이하다.mw-mblist 목록 h4 { 전시하다: 없는; }
그것은 스페셜로 될 것이다.MyPage/common.css. --Redrose64 (대화) 16:49, 2014년 9월 23일 (UTC)[응답]
나는 내가 보고 싶은 편집을 정의하는 것에 문제가 없다. 그것은 단지 내가 별로 좋아하지 않는 그룹일 뿐이다.날짜 표제를 숨기면 페이지마다 받는 히스토리 조각이 매일 하나씩, 몇 개의 연속되지 않은 조각으로 나뉘기 때문에, 날짜 표제를 숨기면 그렇게 고쳐지지 않는다.자바스크립트에 의해 재주문될 수 있을 것 같은데, 잘 모르겠네.API에서 watchlist를 뽑아 내가 원하는 대로 포맷하는 perl 스크립트를 쓰는 편이 더 나을 것 같아.하지만, 그렇게 급하지는 않다.나는 그저 누군가가 내가 같은 생각이라고 생각하는 것을 게시하는 것을 보고 기뻤다.내가 제안하는 내용과 이유를 그럭저럭 분명히 해두면 좋겠지만, 실행되지 않는다면 그렇게 하시오 — HHHIPO 20:03, 2014년 9월 23일 (UTC)[응답하라]
  • 좋은 생각이야, 하지만 노력한 보람이 없어.생산적인 일을 방해하는 거대한 벌레가 있는 반면, 이것은 향상이다.고장 난 디프 뷰어를 고치는 등 더 좋은 방법이 있다.그릴리다 (대화) 2014년 9월 23일 04:16 (UTC)[응답]

웹 사이트의 바탕 화면 버전에 탐색 메뉴 추가

보시다시피 모바일 위키피디아 애플리케이션에는 특정 섹션을 찾기 위해 스크롤할 필요 없이 페이지의 다른 부분으로 이동할 수 있는 네비게이션 메뉴가 있다.

위키피디아의 데스크탑 버전에 유사한 네비게이션 메뉴를 추가하여 사용자가 목차까지 거슬러 올라갈 필요 없이 페이지의 다른 부분으로 이동할 수 있도록 하는 것을 제안하고 싶다.Sam.gov (토크) 2014년 9월 23일 (UTC) 21:36 [응답]

링크 특수성 개선

안녕! 나는 봇 운영자인데, 내가 하고 있는 새로운 작업에 대한 너의 의견을 듣고 싶어.그것은 모두 위키링크의 특수성과 명확성을 향상시키는 것이다.내 말뜻을 정확히 이해하기 위해서, 나는 한번 살펴보는 것을 제안한다.

이러한 지침들은 언뜻 보기에 다소 과장되게 들릴 수 있지만 독자들에게 유용한 링크가 있는 페이지를 얻기 위해서는 매우 중요하다.예를 들면 다음과 같다.

  • Flatline is an [[independent record label]].

보다 낫다

  • Flatline is an [[Independent music independent]] [[Record (music) record]] [[Record label label]].

독립된 레코드 라벨은 그 주제에 대한 훨씬 더 구체적인 링크이기 때문이다.세 개의 다른 일반 기사를 연결하는 것은 "더 많은 정보"가 아니라 단지 오버링일 뿐이다.너무 많은 다른 링크는 PC에서는 선택을 어렵게 만들 수 있고, 모바일 기기에서는 운의 문제일 수 있다.또한 보다 낫다는 점에 유의하십시오.

  • Flatline is an [[independent record label independent]] [[record label]].

"독립적"이라는 링크에는 명확성이 결여되어 있기 때문이다.판독기가 wikitxt(최소 경악의 원리)를 보지 못하기 때문에 배관은 가능한 한 직관적이어야 한다.더욱이 좁은 주제(독립적인 레코드 라벨)를 클릭하면 독자는 "레코드 라벨"에 대한 링크나 의미 설명을 찾을 수 있기 때문에 [레코드 라벨]도 연결할 필요가 없다.구체성이 낮고 명확성/직관성이 부족한 위키링크가 주변에 많지만, 실제로 봇으로 안전하게 개선될 수 있는 위키링크가 있다는 것을 알게 됐다.몇 가지 예:

  • 필요 없는 배관이 있는 단일 특정 링크
    • attack on [[Attack on Pearl Harbor Pearl Harbor]] --> [[attack on Pearl Harbor]] (그 고리가 항구를 가리킬 것인가, 아니면 일본군을 공격할 것인가.명확성 결여.)
    • canton of [[Canton of Bern Bern]] --> [[canton of Bern]] (그 링크가 도시 '베른'을 가리킬 것인가, '베른의 캔톤'을 가리킬 것인가.명확성 결여.)
    • [[Canton of Bern canton]] of Bern --> [[canton of Bern]]
  • 일반+특정 쌍
    • [[golf]] [[Golf club (equipment) club]] --> [[golf club (equipment) golf club]] (두 번째 링크는 명확성이 부족하여 구체적이고 직관적인 단일 링크가 더 좋으며, 골프 클럽(장비) 내부에는 골프와 관련된 링크가 있을 것이다.)
    • [[Bible]] [[Bible translation translation]]s --> [[Bible translation]]s (두 번째 링크에 명확성이 부족하여, 구체적이고 직관적인 하나의 링크가 더 좋으며, 성경 번역 안에는 성경과 연결되는 링크가 있을 것이다)
    • [[Central Intelligence Agency CIA]] [[CIA World Factbook World Factbook]] --> [[CIA World Factbook]]
    • [[Bristol Aeroplane Company Bristol]] [[Bristol Blenheim Blenheim]] --> [[Bristol Blenheim]]
    • [[Lake County, Ohio Lake County]] [[Lake County Courthouse (Ohio) Courthouse]] --> [[Lake County Courthouse (Ohio) Lake County Courthouse]]
  • 특정+일반 쌍
    • [[weak base weak]] [[basic (chemistry) base]] --> [[weak base]] (독자는 약한 베이스 안에서 기본(기본) 또는 설명으로 연결되는 링크를 찾을 것이다)
    • [[Newark, New Jersey Newark]], [[New Jersey]] --> [[Newark, New Jersey]] (독자는 뉴저지 주 뉴어크에 있는 뉴저지와의 링크를 찾을 것이며, 여기서 주제는 뉴어크)
    • [[Hesychius of Alexandria Hesychius]] of [[Alexandria]] --> [[Hesychius of Alexandria]] (위 내용)
    • [[open architecture open]] [[computer architecture architecture]] --> [[open architecture]] (위 내용)

나는 편지 케이스에도 어느 정도 주의를 기울일 것이다. 예를 들어 나는 실수를 피하기 위해 편집자의 대문자 선택을 변경하지 않을 것이다.

  • [[Aurès Mountains Aurès]] and [[Atlas Mountains Atlas]] mountains --> [[Aurès Mountains Aurès]] and [[Atlas Mountains Atlas mountains]]
  • the [[The Exodus Exodus]] --> [[the Exodus]]

현재로서는 다음과 같은 링크를 수정하지 않을 것이다.

  • [[aqueous]] [[solution]] --> [[aqueous solution]] (전체 표현에 대한 기사는 제외하지만, 텍스트가 수용액에 대해 말하는 것인지 아니면 다른 호모그래프 주제에 대해 말하는 것인지 누가 알겠는가?)
  • [[Sand]] [[Casting (metalworking) casting]] --> [[Sand casting]] (위 내용)
  • [[web]] [[page]] --> [[web page]] (위 내용)

이런 종류의 흔한 "오류 링크"에 대한 대체품 컬렉션을 만드는 것은 유용할 수 있지만, 그것은 바다에 한 방울이 될 것이다.

나중에 다음과 같은 링크도 고칠 수 있을 것이다.

  • [[chemical]] [[base (chemistry) base]] --> [[chemical base]] (화학적 기반이라는 전체 표현은 링크된 기사 중 하나인 베이스(기본)로 리디렉션됨)

보다시피, 나는 정확한 목표 기사를 확신할 수 있는 링크 가이드라인을 시행하고 있을 뿐이지만, 그럼에도 불구하고 전체적인 링크 품질은 향상될 것이다.며칠 전 위키피디아 토크에서 토론을 시작했다.Style/Linking#Link Specificity 향상, 그러나 보다 광범위하고 심도 있는 논의가 필요했다.그래서 그 아이디어에 대해 어떻게 생각하십니까? -- 바실리코프레스코 (msg) 01:12, 2014년 9월 24일 (UTC)[응답하라]

나는 네가 하려는 일이 마음에 들어.내 생각에 당신은 다음과 같은 연결고리를 찾을 가능성이 더 높다.
  • [[Attack on Pearl Harbor attack]] on [[Pearl Harbor]] (및의 경우
  • [[Cantons of Switzerland canton]] of [[Canton of Bern Bern]] (의 설명).
이런 것들이 쉽게 당신의 regexes에서 그 논리에 내장될 수 있다.
그리고, 다음과 같은 다른 공통적인 조합이 있다.
  • [[List of Prime Ministers of India 15th]] [[Prime Minister of India Prime Minister]] of [[India]]( 또는 );
  • [[President of the United States President]] [[Barack Obama]] (또는 );
  • [[Secretary-General of the United Nations Secretary General]] of the [[United Nations]], [[Kofi Annan]] (또는 ) 합리화 될 수 있다.
-- Ohc 01:46, 2014년 9월 24일 (UTC)[응답하라]
고마워당신의 제안 1과 2는 이미 regex 계획에 포함되어 있다.4번 뭐 하자는 거야?[[버락 오바마 대통령 버락 오바마]?-- 바실리코프레스코 (msg) 06:09, 2014년 9월 24일 (UTC)[응답하라]
  • 당신의 제안은 괜찮지만, 간단한 링크(대통령 [[바락 오바마]])가 가능할 때 piped 링크를 만들 수 있는 효용성은 없을 것이다. -- Ohc 08:54, 2014년 9월 24일 (UTC)[응답]
나는 뉴어크, 뉴저지 주의 사례(즉, 장소의 계층 구조)를 제외하고, 특히 infobox에서 당신의 제안에 동의한다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디가 편집한 2014년 9월 24일 (UTC)[응답]
나도 동의해, 하지만 뉴어크, 뉴저지 사건도 포함해서.지난 5년 동안 다른 곳에서는 - 비록 정확히 어디에 있는지 기억하기는 어렵지만 - 하지만, 그 느낌은 뉴저지와의 별도의 연결고리가 불필요하다는 것이었다. 왜냐하면 그들이 뉴저지가 어디에 있는지 모르면, 그들은 뉴어크도 어디에 있는지 알 가능성이 거의 없기 때문이다; 그리고 그들이 정말로 NJ가 어디에 있는지 알아야 한다면 그것은 단지 하나의 클리닉이다.k 엑스트라나는 종종 사람들이 변화하고 있는 것을 보았다.[[Newark, New Jersey]]을 형성하다[[Newark, New Jersey Newark]], [[New Jersey]]형식 - 그리고 나는 다른 사람이 먼저 하면 되돌아가려고 한다. --Redrose64 (대화) 11:57, 2014년 9월 24일 (UTC)[응답]

대화 페이지에서 참조 목록 자동 생성 해제

여기서 논의한 내용과 관련하여, 나는 대화 페이지에서 참조 목록의 자동 생성을 해제할 것을 제안하고 싶다.토크 페이지 끝에서 참조 리스트를 원하는 경우는 거의 없다.대화 페이지의 끝을 혼동하고, 사실상 관계없는 마지막 줄기에 붙어 있는 것 같다.대부분의 경우, 참고문헌은 기사로부터 복사되고 붙여진 내용 때문에 우연히만 토크 페이지에 나타난다.일반적으로 이것들이 확장될 필요가 없다.요건이 있는 경우 사용자는 해당 스레드에 목록을 명시적으로 포함할 수 있다.86.190.50.118 (대화) 13:51, 2014년 9월 23일 (UTC)[응답]

T70324를 통해 이미 요청됨 - Cite:자동으로 생성된 참조 목록에 대한 네임스페이스 탐지 추가.투표하면 일부 개발자가 작업할 수 있다. -- Gadget850 talk 14:49, 2014년 9월 23일 (UTC)[응답]
그것은 "해결된 WONTFIX"로 표시된다.나는 그것에 대해 투표할 어떤 메커니즘도 보이지 않는다.우리가 그것이 유용하다고 생각한다고 언급해야 한다는 말씀이세요?나는 여기서 토론하는 것이 부적절하다고 생각할 것이다.개인적으로, 나는 그 아이디어를 매우 좋아한다.나는 주 네임스페이스와 "위키피디아" 네임스페이스를 제외한 어떤 곳에서도 자동 참조 생성에 대한 사용 사례는 생각할 수 없다.확실히 그것은 토크에서 꺼져야 한다.
내가 이 구현에 대해 가지고 있는 유일한 질문은 <ref> 태그를 어떻게 처리하느냐 하는 것이다. 위첨자 번호는 여전히 생성되어야 하는가?참조를 인라인에 배치해야 하는가, 아니면 내용을 효과적으로 무시해야 하는가?나는 콘텐츠가 없는 것이 가장 좋은 방법이라고 생각해.0x0077BE [/]talkcontrib 15:02, 2014년 9월 23일 (UTC)[응답]
나는 이런 변화에 반대할 것이다.다른 스레드에서 말했듯이, 참조 목록을 원하지 않으면 참조 태그를 사용하지 마십시오.잭mcbarn (대화) 15:03, 2014년 9월 23일 (UTC)[응답]
나는 그것이 사물을 보는 나쁜 방법이라고 생각한다.사용자가 사물에 대해 "똑똑하게" 행동하도록 요구하는 것은 설계상의 결함이다.사람들은 종종 많은 사람들의 대화 줄에 있는 토크 페이지에 ref 태그를 사용한다. 그리고 종종 그렇게 하는 사람들은 섹션 끝에 reference 태그를 붙이는 것을 알지 못하는 사람들이다.그것이 의미하는 것은 다른 모든 사람들에게 페이지 끝에 (아무도 원하지 않았던) 무의미한 인용구들이 있다는 것이고, 다른 누군가가 관련 섹션을 찾아서 그것에 섹션 참조 태그를 추가해야 한다는 것이다.사람들이 "그런 실수를 할 정도로 멍청해서는 안 된다"고 생각하더라도, 그들은 실수를 하고 있고 그것은 사람들을 짜증나게 한다.따라서 문제는 이 기능을 추가하지 않을 이유가 있는가 하는 것이다(즉, Talk 페이지의 자동 참조 생성을 실제로 활용하고 있는 사람이 있는가).나는 그들이 아니라고 주장할 수 있다. 그래서 당신이 상대적으로 우선순위가 낮다고 느끼더라도 이것을 해야 할 일 목록에 넣는 것은 현명하지 못한 일이다.0x0077BE [/]talkcontrib 15:10, 2014년 9월 23일 (UTC)[응답]
사람들은 특별히 ref를 원하지 않고 많은 기사들을 복사한다. 단지 그것들을 제거하는 것을 거치는 것이 귀찮다는 것이다.이러한 변화가 현재 소급 적용되고 있는 많은 기존 토크 페이지들이 있다.사람들이 원래 내용을 베꼈을 때는 리플리스트가 등장하지 않았을 것이기 때문에 더 이상 할 필요가 없어 보였을 것이다.이제 레이아웃이 갑자기 엉망이 되었다.새로운 경우, 새 스레드가 처음으로 자동 참조 목록을 트리거하는 경우, 새 스레드가 마지막 스레드가 되므로 편집기에 올바르게 배치되었을 것으로 추정된다.나중에야 새 스레드가 추가되면서 레이아웃이 깨질 것이다.어떤 경우든 많은 사람들이 reflist를 억제하는 방법을 모를 것이다(나는 그것을 기사에 넣는 메커니즘을 어느 정도 알고 있지만, 나는 토크 페이지 중간에 적절한 지시를 삽입하는 것이 마지막에 자동 생성된 목록을 억제한다는 것을 깨닫지 못했다).이것의 디자인은 대화 페이지에 대한 잘못된 방법이다.리플리스트를 포함시키고자 하는 사람들은 그것을 보이게 하기 위해 어떤 일을 할 의무가 있어야지, 반대로 해서는 안 된다.86.190.50.118 (대화) 17:07, 2014년 9월 23일 (UTC)[응답]
  • 86.190과 합의.나는 그 자동 생성된 참조 목록이 불쾌하고, 거슬리고, 전혀 쓸모없다는 것을 알았다.결연한 17:28, 2014년 9월 23일 (UTC)[응답]
  • 대화 페이지의 실제 참조 목록이 자동으로 생성되는 것을 피할 수 있는가? 그러나 여전히 작동하는 참조 툴팁이 있는가?— HHHIPO 20:14, 2014년 9월 23일 (UTC)[응답]
    만약 이것이 가능하다면 나는 그것에 매우 찬성한다. 하지만 나는 툴팁을 제자리에 두는 것이 많은 추가 작업일 경우 자동 발생을 끄는 것이 아마도 우선되어야 한다고 말하고 싶다.0x0077BE [/]talkcontrib 20:19, 2014년 9월 23일 (UTC)[응답]
    아니오, 참조 툴팁은 당신이 맴돌고 있는 링크를 조사하고, 그것이 가리키는 곳을 찾고, 페이지의 뾰족한 부분에 대한 HTML을 검색한 다음, 그것을 상자에 동봉하는 방식으로 작동한다.reflist가 없으면 가리키는 HTML이 없어 박스에 넣을 것이 없다. --Redros64 (토크) 21:41, 2014년 9월 23일 (UTC)[응답]
    reflist에 대한 HTML이 실제로 존재하지만 css 스타일에 의해 숨겨져 표시되지 않는 경우, 전체 목록을 포함하는 태그에서 호출되므로 툴팁으로 승격되지 않는 경우?— HHHIPO 22:01, 2014년 9월 23일 (UTC)[응답]
    기기의 저자인 야어랜드에게 질문할 필요가 있을 수 있다.이 기기 자체는 미디어위키:Gadget-ReferenceTooltips.js. --Redrose64 (대화) 22:13, 2014년 9월 23일 (UTC)[응답]
reflist는 숨길 수 있다. {{reflist hid}}을(를) 참조하지만, 그것이 어디에 도움이 되는지 모르겠다. -- Gadget850 talk 23:43, 2014년 9월 23일(UTC)[응답]

이상적인 것은 관련 최상위 섹션의 끝에 토크 페이지(그리고 아마도 다른 일부 비기사 페이지)의 자동 참조 목록이 작성되는 것이다.PamD 07:56, 2014년 9월 25일 (UTC)[응답]

그것은 아주 명백한 생각이다!지원. — HHHIPO 20:21, 2014년 9월 25일 (UTC)[응답]
이것은 현재의 상황을 개선시킬 것이지만, 여전히 이상적이지는 않다.일반적으로 가장 최근의 토론은 주어진 섹션의 맨 아래에 있고, 많은 참고문헌을 가지고 있는 것이 항상 좋은 것은 아닐 것이다 - 아마도 여러분이 6이나 7에 도달한다면 대화에서 서술해야 할 중요한 텍스트 덩어리가 될 것이다.
나는 당신이 명시적으로 요청하지 않는 한 대화 페이지에 참조 목록이 생성되지 않는 것이 기본이 되어야 한다고 생각한다.나는 사람들이 <참고/> 태그를 섹션 끝에 붙여야 하는 것보다 특정 섹션의 하단에 있는 원치 않는 언급에 의해 짜증이 날 가능성이 훨씬 더 높다고 생각한다.나는 또한 사람들이 리플리스트를 생성하기 위해 섹션 끝에 <참조 />를 넣는 것을 아는 것이 {{reflist 숨겨진}}}을(를) 넣는 것을 아는 것보다 훨씬 더 많다고 생각하므로, 토크 페이지의 디폴트는 여전히 생성된 레퍼런스 리스트가 되어서는 안 되는 것 같다.0x0077BE [/]talkcontrib 15:20, 2014년 9월 26일 (UTC)[응답]
T32763 (Cite: 만약 없다면)<references />페이지 차단, 올바른 위치에 자동으로 하나의 Wikitext를 삽입) -- Gadget850 talk 19:24, 2014년 9월 26일(UTC)[응답]

이름 바꾸기 프로세스를 m:SRUC로 전환해야 하는가?

위키백과를 참조하십시오.관료들의 게시판#이름 변경 과정을 m:SRUC로 전환해 논의해야 할까.–xenotalk 18:42, 2014년 9월 29일 (UTC)[응답]

새 페이지 순찰 후기와 AfC 후기 구분

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

아이디어 랩에서 논의한 후, 사용자 알림에 뉴 페이지 순찰을 리뷰가 아닌 순찰이라고 명시하는 것을 제안하고 싶다.찻집, 헬프 데스크, IRC 도움말 채널에서 흔히 볼 수 있는 질문은 기사 초안/사용자 페이지/샌드박스가 왜 '검토'되었는 지에 대해 혼란스러워하는 사용자들에게서 나오는 질문인데, 아직 아무런 변화도 보이지 않는다.이것은 특히 창조에 관한 기사를 제출한 신규 사용자들에게 혼란을 준다 - 검토 중인 그들의 기사는 수락 또는 거절 결정이 내려졌음을 시사하는 것 같다. 그리고 그러한 결정이 명백하지 않을 때 그들은 혼란스러워 한다.이는 뉴 페이지 순찰과 AfC 리뷰가 모두 '검토'로 설명되는 데서 비롯된다. 페이지를 순찰할 때 사용자는 실제로 순찰되었을 때 "검토되었다"는 이메일과 통지를 받는다.다음 인터페이스 메시지(찾은 Jackmcbarn 덕분에)를 변경하여 페이지가 "검토"되지 않고 "등록"되었음을 명시할 것을 제안한다.

또한 NPP가 무엇인지에 대한 간략한 설명이나 WP에 대한 링크를 포함하는 것이 유익할 수 있다.알림 또는 전자 메일의 NPP.샘 월튼 (대화) 22:40, 2014년 9월 2일 (UTC)[응답]

들어봐, "검토/검토/검토"라는 단어는 위키피디아에서 너무 많은 의미를 가지고 있는데, 이는 사용자 권리 명칭에 대한 최근 토론에서도 볼 수 있다. 노이스터(토크), 09:37, 2014년 9월 3일 (UTC)[응답]
지원, 이것은 또한 자동 조종 권리와 일치하게 만든다.베스넛 (대화) 10:05, 2014년 9월 3일 (UTC)[응답]
  • 나는 확실히 용어를 바르게 하는 것을 지지할 것이다.수년 동안 NPP에 대해 극도로 염려해 온 한 사용자로서 나는 NPP를 'Patrolling' 이외의 다른 것으로 언급한 적이 없다.나는 새로운 사용자로서 페이지를 결코 만들지 않기 때문에, 나는 그것이 새로운 사람들 사이에서 야기하는 혼란을 망각했다.쿠드풍 กุผึ ( ((대화) 10:54, 2014년 9월 4일 (UTC)[응답]
  • '입국'보다 '체크아웃'에 대해 어떻게 생각하십니까?WhatamIdoing (대화) 22:29, 2014년 9월 4일 (UTC)[응답]
    • 현재의 사용법과 그 용어가 현장 주변과 템플릿 등에 채용된 수천 번과 조화를 이루면서, OP의 원래 제안 외에 고쳐야 할 것은 없다고 생각한다.그 외에도, 순찰하는 동안 '체크된' 것은 다소 더 많은 조치를 필요로 하며 유능한 사용자들에 의해 수행된다.쿠드풍 กุผผ ((대화) 05:49, 2014년 9월 5일 (UTC)[응답]
      • "등록된"은 새로운 사용자들에게 아무 의미도 없는 위키자르곤이다.순찰을 하는 것은 페이지를 넘나드는 행동이지, 이것을 괜찮다고 표시하는 행동이 아니기 때문에 문법적으로도 이치에 맞지 않는다."지나가는 사용자가 당신의 페이지는 아마도 즉시 삭제될 자격이 없다고 말했을 것이다."라고 가장 정확할 것이다. 하지만 그것은 매우 말이 많다."좋아", "받아들였다" 또는 "체크된"은 새로운 사람에게 이치에 맞을지도 모른다.'체크티드'는 대부분의 NPP 가입자가 이를 따르지 않더라도 체크리스트를 해제할 수 있는 장점이 있다.메인 스페이스 밖에서는 페이지를 대충 훑어본 후에 순찰하는 것으로 표시하는 경우가 많은데, 모든 사람이 순찰에 태그 폭격이 필요하다고 믿는 것은 아니기 때문에 그것이 정확한 함축이 될 것이다.WhatamIdoing (talk) 18:56, 2014년 9월 8일 (UTC)
뭐야, '애국'은 우리가 가진 최고의 용어고, 깨지지 않았는데 왜 고친 거야?제안은 혼란스러운 용어를 'patroll/edded'로 바꾸고 다른 용어를 찾지 않는 것이다."체크된"은 "합격"/"승인된" 만큼이나 "합격된"/"승인된"을 환기시킨다. NPP에서는 대개 그렇지 않은 경우가 대부분이다. 거의 모든 새로운 페이지는 삭제 여부를 위해 한 종류 또는 다른 종류의 주의를 필요로 한다.우리는 NPP가 피상적인 시선이라는 어떤 제안도 피해야 한다. 그렇지 않거나 아니면 매일 그렇게 되어서는 안 되는 것이다.나는 NPP에 회의론자들이 있다는 것을 알고 있다. 하지만 NPP는 원치 않는/적합하지 못한/부적절한 콘텐츠에 대한 우리의 유일한 방화벽일 뿐만 아니라, 만약 올바르게 사용된다면, 태그 폭격은 생산성에 전혀 반하는 것이 아니라, 기사가 그저 스쳐 지나가는 사람들에게 더 잘하도록 격려해야 한다.쿠드풍모바일 (대화) 08:59, 2014년 9월 9일 (UTC)[응답]
나는 그것이 "우리가 가진 최고의 용어"라는 것에 동의하지 않으며, "깨지지 않았다"는 것에 동의하지 않는다.새로운 사용자들은 순찰을 돌지 않는다.그러므로 그것은 "파탄"이다.'최고'나 '깨지지 않는' 것과 같은 위키자르곤에 익숙한 사람들 사이에서 가장 흔한 용어에 불과하다.WhatamIdoing (talk) 16:02, 2014년 9월 9일 (UTC)[응답]
  • 지원 - 어떤 종류의 피드백 프로세스가 수반된다는 것을 강조하기 때문에 검토된 것은 좋지 않은 선택이다.순찰, 이상적이지는 않지만 '새 페이지 순찰자'와 '자동탐색'이라는 용어와 일치한다.--Ykraps (대화) 12:46, 2014년 9월 6일 (UTC)[응답]
통지문에는 "당신의 페이지가 승인되었다"고 되어 있지 않은가? 이는 "이 초안이나 메인 네임스페이스 기사가 메인 네임스페이스에 대해 승인되었다"는 적절한 설명이다.그릴리다 (대화) 2014년 9월 11일 22시 15분 (UTC)[응답]
나는 이것이 위와 무슨 관계가 있는지 혼란스럽다 - "당신의 페이지는 승인되었다"는 초안이 받아들여지고 있는 것에 대한 훌륭한 설명이다.이러한 혼란은 WP로부터 온다.NPP를 '검토'라고 한다.샘 월튼 (대화) 22:21, 2014년 9월 11일 (UTC)[응답]
에코는 사용하지 않지만 NPP에도 '당신의 페이지는 승인되었다'고 적혀 있는 줄 알았는데… --그리이다(토크) 23:09, 2014년 9월 11일 (UTC)[응답]
음, 아니, 확실히 검토가 끝났어.방금 알림 확인했어.--Ykraps (대화) 04:56, 2014년 9월 12일 (UTC)[응답]
  • 지지 이것은 오랫동안 혼란의 원인이 되어 왔고, 나는 그것이 해결되어 기쁘다. DGG (토크 ) 09:03, 2014년 9월 23일 (UTC)[응답]
  • 보관소에서 검색됨: 여기에서 더 나은 용어가 확인 또는 순찰인지에 대해 어느 정도 공감대를 얻을 수 있는가?그리고 나서 나는 실행하겠다.— 마틴 (MSGJ · talk) 11:57, 2014년 9월 26일 (UTC)[응답]
  • "Patroned"라는 용어를 지원하십시오. --Redrose64 (대화) 12:16, 2014년 9월 26일 (UTC)[응답]
  • 이상적인 것이 아니라 개선된 것으로서 순찰을 한다. 노이스터(토크), 2014년 9월 30일(UTC) 10:31[응답]
  • 됐어, 내가 놓친 게 있으면 알려줘.— 마틴 (MSGJ · talk) 11:39, 2014년 9월 30일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

21세기의 기구주의 갱신

지침요청: 21세기의 기구주의.나는 존 듀이와 칼 포퍼가 어떻게 재해석되어, 계기 공학을 귀납적 추리, 기술, 실용주의와 관련된 과학 프로젝트 철학의 적극적인 한 부분으로 만들었는지를 설명하기 위해 "계측주의"에 관한 기사를 갱신할 것을 제안한다.토크에서 내 제안을 평가하십시오.기구주의, 출품작 20번과 21번.TBR-qed (대화) 19:44, 2014년 10월 6일 (UTC)[응답]

이 토론은 기사의 토크로 옮겨져야 한다.이곳은 너의 제안을 위한 장소가 아니다.행운을 빈다.GenQuest 21:45, 2014년 10월 6일 (UTC)[응답]

충돌 인포박스 - 4개 측면 필요

시리아 내전 인포박스는 오랫동안 지속된 콘텐츠 논쟁의 대상이 되어 왔다(토크:시리아 내전#인포박스 매우 오해의 소지가 크다.)관련자들 중 거의 모든 사람들이 이 복잡한 갈등을 표출하는 적절한 방법은 (명백히 정부나 반군과 연합하지 않는) 민족주의 쿠르드인들이 분쟁 내내 양쪽과 충돌했는지를 놓고 머리를 갈라놓으려 하기보다는, 인포박스에 네 가지의 뚜렷한 전투원 '사이드'를 두는 것이 될 것이라는 데 동의한다.일부 지역에서는 양쪽 그룹에 협력했다.) 정부나 반군 칼럼에 들어가야 한다.분명히 우리는 최근 뉴스에 많이 보도되고 있는 이슬람 국가가 그들이 전쟁을 벌이고 있는 쿠르드족과 훨씬 더 적게, 그들이 전쟁을 하고 있는 반군과 같은 칼럼에 믿을 수 있는 지점은 지났다.우리가 사용해온 시리아 전쟁 그래픽(맵스 등)은 거의 모두 4면을 보여준다.infobox 코딩의 한계로 인해 갈등을 적절하게 제시할 수 없으며, 그 때문에 콘텐츠 분쟁이 계속될 것이며, 4면이 있는 infobox를 구축하지 않는 한, 그리고 우리가 할 수 있을 때까지 독자들은 계속 혼란스럽고 부정확한 상황을 보게 될 것이라고 믿는다. -쿠즈1 (토크) 17:43, 2014년 10월 5일 (UTC))[답장]

그래, 이것을 좀 더 일반적으로 설명하기 위해서(이 제안된 변경은 문제의 기사에만 영향을 미칠 것이 아니기 때문에), 전쟁 인포박스에서 3개의 칼럼만 허용하는 기술적 한계가 있고, 우리는 기본적으로 4번째 칼럼을 가능하게 하고 싶다.복잡한 전쟁에 대한 다른 기사에서도 유용할 수 있다.펑크몽크 (토크) 17:57, 2014년 10월 5일 (UTC)[응답]
나는 또한 우리가 인포박스에서 4개의 뚜렷한 전투원 "사이드"를 만들 필요가 있다고 생각한다.그리고 그것은 우리의 문제에 대한 훌륭한 해결책이 될 것이다.하니발911 (대화) 2014년 10월 5일 18:01, (UTC)[응답]
전폭적으로 지지하다.그냥 요청을 쉽게 찾을 수 있도록 "- 4면 필요"를 추가하여 제목을 편집했어.레거시pac (대화) 18:03, 2014년 10월 5일 (UTC)[응답]

나는 4면을 위한 인포박스가 필요하다.알하누티 (대화) 2014년 10월 5일 18:04 (UTC)[응답]

템플릿 재작업:이를 뒷받침하기 위한 인포박스 군사 충돌.완료되면 템플릿 수정:시리아 내전 인포박스를 이용하기 위해.잭mcbarn (대화) 2014년 10월 5일 (UTC) 18:13 [응답]
정말 고마워, 잭맥바인! -쿠즈1 (토크) 18:24, 2014년 10월 5일 (UTC)[응답하라]
  • 내 생각에 더 좋은 해결책은 단지 "전투" 부분을 아예 갖지 않는 것이라고 생각한다.시리아의 상황이 너무 복잡해서 인포박스에 적절히 요약될 수 없다는 것은 꽤 분명하다.이 문제에 관한 가이드라인에 의해 제시된 바와 같이, infobox의 목적은 정보의 끝없는 수렁이 되는 것이 아니라 요점을 요약하는 것이라는 것을 기억하라.인포박스는 산문의 대용품이 아니다.네 번째 칼럼을 추가하면 읽기 어려운 거대한 난장판만 만들어낼 뿐 페이지의 레이아웃을 침해하게 된다.이 상황이 너무나 복잡하고, 인포박스가 도저히 정의를 내릴 수 없다는 점을 감안할 때, 산문을 그대로 놔두는 것이 최선이다.전투원 섹션을 제거하십시오.RGlucester — 인터뷰 18:15, 2014년 10월 5일 (UTC)[응답]
대부분의 사람들이 기사를 읽지 않을 것이기 때문에, 인포박스는 간략하게 개요를 제공한다.어쨌든 나중에 이 문제를 더 논의할 수 있는데, 지금 당장은 네 번째 칼럼을 가능케 하는 것만으로도 나쁘지 않았다.펑크몽크 (토크) 2014년 10월 5일 (UTC) 18:20 [응답]
현재의 infobox나, 네 번째 칼럼을 추가하는 아이디어에 대해서는 「빨리」나 「개요」가 없다.그것은 인포박스에 관한 지침과 그들의 타고난 목적 앞에서 날아간다.RG루스터 — 인터뷰 19:22, 2014년 10월 5일 (UTC)[응답]

아, 전투원 인포박스는 상황을 빨리 파악하는데 정말 도움이 된다.

  • A B C D 또는
  • AB

여기에 줄을 서라(이것을 보여주기가 어렵다!)

  • CD

너비를 너무 많이 먹지 않기 위해서레거시pac (대화) 2014년 10월 5일 18:18, (UTC)[응답]

갈등의 4번째 측면을 만드는 것을 지지한다.엄밀히 말해 쿠르드족은 사실 아사드 정권 파벌에 공식적으로 반대하고 있다("시리아 쿠르드족은 자신들이 제공하는 뒷통로에 대한 호소력을 더했을 수도 있다. 아사드 전 대통령의 정권에 반대한다고 주장했음에도 불구하고 이들과 맞서 싸우는 과정에서 그의 세력들과 조율을 하고 있는 것 아니냐는 보도가 나오고 있다.) 또한 분쟁이 시작된 이후 시리아 반대파와 공식적인 악어만 형성하고 있어, 이것은 바뀔 수 있는 복잡한 상황이다.Nulla Taciti (대화) 18:20, 2014년 10월 5일 (UTC)[응답]
  • 나는 개념적으로는 이것에 동의하지만, 그 결과는 특히 우리가 가지고 있는 참고자료의 양과 함께 약간 불쾌하게 될 수 있다.지금 나는 쿠르드족 문제를 임시로 다루었고([1] 참조) 처음 두 열의 칸막이들이 오르내리지 않도록 그들과 접했다.나는 이것이 일단 문제를 해결한다고 믿는다.생각?피츠카말란 (대화) 2014년 10월 5일 (UTC) 18:23 [응답]
혁신적인 해결책이지만 쿠르드족 '사령관과 지도자' 구간과 쿠르드족 '강도' 구간도 쿠르드족과 같은 방식으로 접해 혼란을 피할 수 있을까.Nulla Taciti (토크) 18:35, 2014년 10월 5일 (UTC)[응답]
나는 네 번째 칼럼이 해결책이 될 수 있다는 것에 동의한다.너무 꽉 차 보이지 않았으면 좋겠는데...그러나 그것이 바로 이 갈등의 본질일 뿐이다.Jushyosah604 (대화) 18:44, 2014년 10월 5일 (UTC)[응답]
나는 피츠카르말란의 레이아웃을 좋아한다(쿠쯔의 이전 레이아웃과 유사).분명한 것은 쿠르드족이 상황과 장소에 따라 아사드군과 IS에 대항하는 반대 세력(YPG가 반군들과만 함께 싸워왔다는 이전의 진술과 대조된다) 양쪽 옆에 서서 싸워왔다는 것을 보여준다.그러나 나는 쿠르드족을 위한 네 번째 칼럼도 지지할 것이다(너무 비좁지 않다면 말이다.EkoGraf (대화) 20:01, 2014년 10월 5일 (UTC)[응답]
얘들아, 이 섹션은 우리가 이미 만들 수 있는 구성에 대해 토론하는 자리가 아니라, 우리가 구현하기 위해 외부 도움이 필요한 것에 대해 토론하기 위한 것이다.펑크몽크 (토크) 05:42, 2014년 10월 6일 (UTC)[응답]
나란히 있는 4개의 기둥은 터무니없이 비좁을 것이다.만약 정말로 4면 인포박스가 절실히 필요하다면 실용적인 해결책은 2+2 컬럼이 될 것이다.그러나 현재 시리아 내전 기사의 배열은 상당히 견고하기 때문에 어차피 4번째 칼럼은 필요 없을 것 같다.-스타베린데 (대화) 18:14, 2014년 10월 6일 (UTC)[응답]
실제로 어떻게 보이는지 보고, 어떻게 보이는지에 대해 불평하지 말자.4개의 기둥이 있는 전쟁광은 전에 본 사람이 없다.또한 이것은 '극도로 비좁은' 전쟁이기 때문에 이를 반영하는 인포박스는 우리가 어떤 자의적인 타협안을 내놓아도 진실에 가까울 것이다.펑크몽크 (대화)20:53, 2014년 10월 6일 (UTC)[응답]

사용 준비 완료

@Kudzu1: @FunkMonk: @Hanival911: @Legacypac: @Alhanuty: @Nulla Taciti: @Jushyosaha604: @EkoGraf:방금 템플릿 업데이트를 완료한 경우:4번째 전투원을 지원하기 위한 Infobox 군사 충돌 (아직 문서를 수정하지는 않았지만, 이전에 1/2/3을 지원했던 모든 분야는 이제 4도 지원한다.)템플릿 변환을 시도하지 않을 경우:시리아 내전 Infobox 나 자신(누군가가 내가 무언가를 하는 방식을 좋아하지 않을 것이라고 확신하기 때문) 하지만, 이제 여러분 중 누구라도 그것을 할 수 있어야 한다.새로운 기능이 어떻게 작동하는지 궁금한 점이 있으면 알려줘.잭mcbarn (대화) 15:08, 2014년 10월 7일 (UTC)[응답]

감사합니다, 정말 수고하셨습니다!단 한 가지 메모: 착시현상인가, 아니면 다른 세 개의 칼럼보다 세 번째 칼럼이 약간 넓은가? -쿠즈1 (토크) 16:13, 2014년 10월 7일 (UTC)[응답]
고마워! 펑크몽크 (토크) 17:09, 2014년 10월 7일 (UTC)[응답]
대박 :) 레거시pac (대화) 17:26, 2014년 10월 7일 (UTC)[응답]

아우터넷이 도움이 필요한 것 같아

나는 위키피디아 재단이 Outernet 프로젝트를 서버 용량으로 지원하거나 시작 단계에서 그들의 웹사이트의 대역폭 제한을 다루기 위해 필요한 최소한의 자금만 지원한다면 고귀한 조치가 될 것이라고 믿는다.그들은 시너지 효과를 내는 목표를 공유한다.

https://en.wikipedia.org/wiki/Outernet

https://www.outernet.is/ 할당량 초과 이 신청서는 일시적으로 서비스 할당량을 초과한다.나중에 다시 시도해 주십시오.

아마도 그런 것들이 어떻게 정리되어 있는지 아는 사람이 이 제안을 올바른 사무실로 전달해 줄 만큼 친절할 것이다.

일렉트릭 프레스 (대화) 06:34, 2014년 10월 2일 (UTC)[응답]

안녕, 일드릭 프레스.나는 그들이 보조금을 받을 자격이 있을지 모르지만, 그것은 신청되어야 할 필요가 있다고 들었다. 메타:보조금:시작이 귀하에게 필요한 정보를 제공하거나, 귀하가 조직과 관련된 사람을 알고 있다면 진행해야 할 정보를 제공하기를 희망한다. --Maggie Dennis (WMF) (토크) 12:25, 2014년 10월 7일 (UTC)[응답]
Maggie Dennis (WMF) 안녕 나는 여기에 링크를 걸고 이것을 제안하는 이메일을 보냈는데, 아마도 그들이 지원할 것이다.나는 그저 구경꾼일 뿐인데, 요즘 서구 세계에서는 좀처럼 찾아볼 수 없는 쿼타 한계에 부딪혀 연결 사람들이 도움이 될 수 있을지 생각해 보았다. -- 일드릭 프레스 (대화) 17:34, 2014년 10월 7일 (UTC)[응답]

월간 기부 대신 연간 기부금

위키피디아를 구독하고 매년 기부를 하고 싶다.나는 https://wikimediafoundation.org/wiki/Ways_to_Give에는 "월간 선물" 옵션이 있지만 "연간 선물"은 없다는 것을 알게 되었다.예를 들어 매년 30유로를 기부하기로 결정한다면 매달 2.5유로를 지불하는 대신 매년 30유로를 지불하는 것이 더 편리하다.매달 그렇게 소액결제를 하는 것은 정말 짜증나는 일이다.PayPal로 연간 결제를 이행할 수 있는가?— Arc25 (대화) 14:08, 2014년 10월 2일 (UTC)[응답]

안녕, 사용자:Ac25. :) 당신의 최선의 선택은 아마도 그 질문을 donatewikimedia.org@에 전달하는 것이다.위키백과를 지원해줘서 고마워! --Maggie Dennis (WMF) (토크) 12:21, 2014년 10월 7일 (UTC)[응답]
Hi User:Arc25, 후속 조치로서 기금모금팀에서 가끔 이런 질문을 받는다고 말할 수 있다.불행히도, 현재 우리는 매년 기부를 재개할 수 있는 기술적 능력을 가지고 있지 않다.우리는 이메일과 배너를 통해 1년에 한 번 과거의 기부자들에게 연락하려고 노력하지만, 우리는 항상 더 많은 선택권을 제공할 방법을 찾고 있으며, 매년 반복되는 기부금은 우리의 잠재적 미래 개선 목록에 올라 있다.지금은 더 도움이 되지 못해 아쉽지만 후한 지원 제의에 진심으로 감사드린다! --CCogdill (WMF) (토크) 18:12, 2014년 10월 7일 (UTC)[응답]
대답해줘서 고마워.나는 네가 언젠가 이것을 고쳐주길 바란다.그때까지는 5년에 한 번 5×30유로로 결제를 할 예정이어서 매년 결제를 확실히 할 수 있다(매년 기부를 잊어버리는 경우도 있고, 스피드에 비해 너무 빈번한 것 같다).다시한번 감사합니다.— Arc25 (대화) 16:48, 2014년 10월 8일 (UTC)[응답]

"공백 편집 요약을 입력할 때 알림" - "미리 편집"을 선택할 때 표시 안 함 옵션

안녕, "공백 편집 요약을 입력할 때 약속해줘" - 가끔 입력하는 것을 잊어버리거나 완료하기 전에 실수로 편집 내용을 저장하는 일이 거의 없을 때 상기시켜줘.그러나 나는 사소한 변경만 하고 "이것은 사소한 편집이다" 확인란을 체크했을 때 약간 짜증난다.옵션(우선 "Prompt me...(프롬프팅 미)" 바로 아래)을 선택하십시오."단순 편집을 할 때 확인하지 않음"과 같은 옵션) - 기본값으로 설정하시겠습니까?여러분, 계속 수고하십시오!사실 707 (대화) 13:33, 2014년 9월 24일 (UTC)[응답]

나는 편집 요약을 입력하는 "불편함"을 다루기 보다는 편집자들이 편집 내용을 부적절하게 사소한 것으로 표시하도록 부추길 수 있다는 우려가 있다.어떤 경우든, 나는 옵션의 포함에 동의할 수 있지만, 나는 디폴트로 켜는 것에 반대한다. 특히 이 옵션을 켜는 것을 원하는 편집자들에게 최소한의 노력이 필요할 때 그렇다.도니아고 (토크) 13:40, 2014년 9월 24일 (UTC)[응답]
기존 시스템에서는 편집 요약에 공백을 추가하기만 하면 된다. 그러면 프롬프트가 나타나지 않는다. 이 정도면 충분하지 않은가?—Quondum 16:34, 2014년 9월 24일 (UTC)[응답]
주석, 또는 '최소 편집' 상자를 확인하여 공백이나 단일 문자 "m"을 편집 상자에 강제로 넣을 수도 있다.들어오거나 나갈 필요 없이 자동 입력만 하면 된다.@도니아고:'의 우려'에 대해서는, 지금 일부 편집자들이 그렇게 하고 있다.GenQuest"Talk to Me" 19:12, 2014년 9월 24일 (UTC)[응답]
사소한 편집이라고 해도 모든 편집에는 요약이 있어야 하지 않을까?개인적으로, RC가 순찰할 때, 내가 요약 없이 사소한 편집을 본다면, 나는 잠재적 공공 기물 파손에 대해 편집자에게 추가적인 정밀 조사를 한다.이반벡터 (토크) 2014년 9월 24일 (UTC) 19:48 [응답]
사람들이 요약을 그대로 두도록 하는 것은 충분히 어려운 일이다.제발 그들에게 하지 말라고 권하지 마라. 특히 사소한 편집이 될 수 있는 것은 아니다.브릿맥스 (토크) 2014년 9월 24일 (UTC) 19:50[응답]
여기도 마찬가지야.나는 우리가 더 많은 편집 요약을 가져야 한다고 생각한다.도니아고 (대화)20:17, 2014년 9월 24일 (UTC)[응답]
말도 안 되는 소리.편집 요약을 떠나는 사람들은 계속 그렇게 할 것이고, 보통 편집 요약을 떠나지 않는 사람들은 계속해서 편집 요약을 남기지 않을 것이다.그 제안은 위키홈즈와 백과사전을 더 잘 만들기 위해 끊임없이 유지와 다른 사소한 편집을 하는 편집자들에게 시간 절약적인 문제를 다루며 즉석에서 무시되어서는 안 된다.젠퀘스트"Talk to Me" 02:27, 2014년 9월 29일 (UTC)[응답]
어떤 종류의 "유지관리 편집"이 빈 편집 요약을 보장하는가?나는 변덕스럽지 않고 무엇이 변했는지 아는 것이 좋다.이반벡터 (대화) 03:03, 2014년 9월 29일 (UTC)[응답]
나는 사소한 편집도 많이 하고 항상 요약을 사용하려고 노력한다.WP에 의존하지 않는 한 요약을 생략할 타당한 이유가 없다고 본다.AES. --NYKevin 14:15, 2014년 10월 2일 (UTC)[응답]

FWIW, OP가 무슨 말을 하는지 이해한다.위키피디아 기사를 통해 무심코 읽다 보면, 그 순간의 서버 지연 시간에 따라, 나는 종종 오자, 오자, 사소한 문법적 오류 등을 발견하게 될 것이다.그런 경우 대부분 편집 요약이 편집보다 훨씬 길다는 것을 알게 되고, &#8211; 나의 변화를 지능적으로 설명하기 위해 여러 문장을 쓰도록 요구할 것이다.(예를 들어, "이전의 편집자는 큰따옴표를 한 쌍의 단일 따옴표로 혼동했다. 이는 문단의 마지막 절반이 기울임꼴로 표시된다.그래서 나는 이 실수를 고치기 위해 외부적인 큰따옴표를 한 쌍의 단일따옴표로 바꿨다."어떤 사건들은 훨씬 더 연루되어 있고, 내가 아무리 말하려고 해도 긴 설명이 나올지도 모른다.)결과적으로, 누구든 내 기여 이력을 열람하는 사람은 내가 마이너라고 표시한 편집들 중 많은 부분이 암호화된 편집 요약을 가지고 있다는 것을 발견할 것이다.감히 말하지만, 편집이 간단할수록 요약은 더 암호화 될 것이다; 때때로 나는 변경 사항을 문서화해야 하는 요구에도 불구하고 내 편집 요약을 더욱 더 암호화 할 것이다.

이제 나는 편집 요약을 절대 남겨서는 안 된다고 주장하는 것이 아니라, 어떤 베테랑 편집자는 요약이 한 문자를 추가/제거하는 데 무려 100개의 단어를 필요로 할 때 그녀/그 자신이 좌절감을 느낄 것이다. 따라서 우리는 모두 OP의 제안에 약간 동조해야 한다.설사 장기적으로 볼 때 좋은 생각이 아니라고 해도. (그리고 내가 정말 얼간이 되고 싶었다면 별 힘들이지 않고 쓸데없는 편집 요약을 남길 수 있었다.흠. 내가 시범을 보일지도 몰라.) -- (대화) 20:56, 2014년 10월 8일 (UTC)[응답하라]

그가 한 말. ;-) 젠퀘스트"Talk to Me" 11:43, 2014년 10월 9일 (UTC)[응답하라]
"포맷", "오타 수정", "fmt", "WP:톤, "미스. 사소한 수정", "정리"...돈이야고 (토크) 2014년 10월 9일 (UTC) 14:04 [응답]

발음, 기타 이름 및 기타 언어 이름을 리드선에서 노트 또는 사이드 박스로 이동

이 예를 들어보자.이것이 헤브론의 리드다.

헤브론(아랍어:الخليل(help·info)al-Khalīl, 히브리어:.mw-parser-output.script-hebrew,.mw-parser-output .script-Hebr{font-family:"라고.남방 한계선 Hebrew","SBL BibLit","Taamey Ashkenaz","Taamey 프랭크 CLM","Frank 룰 CLM","Ezra SIL","Ezra SILSR","Keter 아람 Tsova","Taamey 데이비드 CLM","Keter YG","Shofar","David CLM","Hadasim CLM","Simple CLM","Nachlieli",Cardo,Alef,"Noto 세리프 Hebrew","Noto 썽 Hebrew","David Libre",David,".TimesNewRoman",Gisha,Arial,FreeSerif,FreeSans}חֶבְרוֹן‎(help·info), 표준 히브리어:[Ḥevron]오류:{{Transl}}:인식할 수 없는 음역 표준:( 도와 주), 타이베리안:Ḥeḇrôn ISO259-3:Ḥebron, 오스만 터키 Halilürrahman, 고대 그리스어 Hebrṓn, Χεβρών)은 Palestinian[1][2][3][4][5]도시는 남부 요르단 강 서안 지구에 위치한 30km(19mi).거제의 uth루살렘

일반 독자들이 보고 싶어하는 것은 다음과 같다.

헤브론은 예루살렘에서 남쪽으로 30km(19mi) 떨어진 남부 요르단강 서안에 위치한 팔레스타인[1][2][3][4][5] 도시다.

여기서 문제는 발음과 다른 언어 이름들이 단순히 납의 시작을 엉망으로 만들어 가독성을 떨어뜨린다는 것이다.이것은 기사 제목에 대한 다른 이름들이 있는 몇몇 다른 기사들에서는 더 심각하다. 각 기사들의 의미는 인라인으로 설명된다.

왜 우리는 그러한 아이템을 노트나 사이드박스에 넣어야 한다는 정책을 세워서는 안 되는가? --프린세스마테우 (토크) 07:59, 2014년 10월 2일 (UTC)[응답]

나는 위키피디아의 이름 정보를 문장에 과부하하는 것은 나쁜 습관이며, 당신이 인용하는 헤브론 사례는 특히 바꿔야 할 끔찍한 예라는 것에 꽤 동의한다.사이드박스가 그것에 가장 적합한 장소인지 아닌지는 잘 모르겠지만(그러나 나는 그것이 선택적으로 인포박스 템플릿에 통합될 수 있다고 추측하지만, 사실상 모든 지리적 기사들은 요즘에 인포박스를 가지고 있다.내가 가장 좋아하는 해결책은, 지역 언어로 된 두세 개의 이름만 나열한 단순한 목록이라면, 첫 번째 선도 단락의 끝 부분에 있는 추가 문장이다("도시는 A에서는 "X", B에서는 "Y", C에서는 "Z"로 불린다.)그것보다 더 복잡한 것은 아래의 별도의 "이름" 섹션에 들어가야 한다.현 상태를 더욱 악화시키는 것 중 하나는 순전히 정치적/역사적 이유로 온갖 종류의 이름을 주입하는 것에 대한 현학적인 강박관념이다. 예를 들어, 어떤 장소에 살고 있는 모든 언어 공동체에 그들의 이름 변형을 열거함으로써, 혹은 한때 그것을 지배했던 모든 역사적 상태들에 대해, 또는 여기 l에 의해서 여기처럼, 모든 종류의 이름을 주입시키는 것이다.완전히 무관한 오스만 이름 사용.일반적으로, 리드 문장의 시작 부분에 있는 슬롯은 영어로 사용되었거나 사용된 이름에만 국한되어야 한다(공식 지역 언어에서 현재 하나의 공식 명칭을 포함, 영어 지도, 아틀라스 등에서도 사용될 수 있다).Fut.Perf.2014년 10월 2일 08:16 (UTC)[응답]
나는 위 예에서 살아있는 "ref" 태그를 제거하고 가짜 태그로 대체할 자유를 얻었어. 단지 우리가 이 토크 페이지에 가짜 참조 목록을 가지고 다닐 필요가 없도록 말이야.Fut.Perf. ☼ 08:19, 2014년 10월 2일 (UTC)[답글]
모든 곳에 "현재의 공식 명칭" 또는 "공식 지역 언어"가 하나 있다고 가정하면, 부당한 것으로 보인다.예를 들어 헤브론의 일부는 팔레스타인 국가(공식어 아랍어)에 의해 통제되고, 다른 일부는 이스라엘(공식어인 히브리어와 아랍어)에 의해 통제되는 것으로 보인다.또 다른 예로 스위스는 다음과 같은 4개의 공용어를 가지고 있다.독일어, 프랑스어, 이탈리아어, 로마어.Anomie⚔ 11:28, 2014년 10월 2일 (UTC)[응답]
중요한 점은 우리가 명칭을 포함하거나 포함하지 않는 것을 이것 또는 그 주/민족성/역사적 기간 등에 대한 우리의 역할을 인정하는 상징적인 표시로 사용하려는 이 전체적인 생각을 강조하지 말아야 한다는 것이다.우리는 이 지역 주민들 또는 저 집단을 기쁘게 하기 위해 기사를 쓰는 것이 아니다.우리는 영어권 독자에게 봉사하기 위해 그것들을 쓰고 있는데, 그 자리에 이름을 포함시켜야 하는 유일한 이유는 영어권 독자들이 영어권 환경에서 그 이름으로 언급된 장소를 보고 기사로 이끌었을지도 모르기 때문이다.내가 지방의 공식 명칭을 언급한 것은, 아틀라스와 같은 다른 영어권 출판물들은, 영어 산문이 달리 영어식 이름(예: 뮌헨)을 강하게 선호하는 곳에서도, 지역 이름(München 등)을 사용하는 정책을 가지고 있을 수 있다는 사실 때문이었다.그게 뮌헨이 거기에 있어야 하는 유일한 이유야.그러므로, 우리는 스스로에게 물어봐야 한다: "뮌헨"과 "아테냐"를 사용하는 영어 지도책에도 "ḥevron"이나 "al-Khalīl"이 포함되어 있을까, 아니면 둘 다 들어 있을까?만약 그렇다면, 그들은 안으로 들어가고, 그렇지 않다면, 그들은 들어가지 않는다.역사적 명칭의 경우, (현재의) 영어로 된 역사책들이 (현대의 이름으로 즉시 얼버무리지 않고) 그 장소를 XYZ 이름으로 지칭할 것인가 하는 의문도 비슷하다.만약 그렇다면, 역사적 명칭은 들어가지만, 그렇지 않다면 들어가지 않는다.다른 모든 것은 좀 더 아래쪽에 있는 곳에서 다루어져야 하는데, 그 곳에서 그것은 덜 거슬린다(아마도 아직 도입부에서는 그렇지만 납문장에서는 그렇지 않다).Fut.Perf. ☼ 11:50, 2014년 10월 2일 (UTC)[응답]
우리는 분명히 납을 더 시각적으로 매력적이고 읽기 쉽게 만드는 방법이 필요하다.사이드바가 최선의 해결책일 수도 있다.하지만 다른 선택사항들은 무엇이 있을까?모자이크 오버 팝업, 각주, 이중창?Kdammers (대화) 09:15, 2014년 10월 2일 (UTC)[응답]
나는 이것을 지지한다 - 레드에 대체 이름과 발음을 과부하하는 것은 가독성을 방해한다. 그리고 나는 우리가 영어 독자들을 위한 백과사전을 만들고 있다는 것에 동의한다. 따라서 우리가 기사 제목을 선택하는 방법과 마찬가지로 가장 흔한 영어 이름만이 레드에 있어야 한다.솔직히, 이것은 페이지의 가독성을 실제로 상당히 증가시키는 점점 더 적은 수의 제안 중 하나이고, 그것이 우리가 추구해야 할 것이다.나는 "대체 이름"이나 "로컬 이름" 또는 그런 부분을 인포박스에 추가하는 것이 우아한 해결책이 될 것이라고 생각한다.실제로 헤브론을 보면 이미 인포박스 바로 위쪽에 '기타 녹취록' 코너가 있다.거기는 왜 안 돼?이반벡터 (대화) 14:46, 2014년 10월 2일 (UTC)[응답]
든든한 지지.리드 문장의 정사각형은 완전히 통제 불능이다.다시 읽기 쉬운 기사를 쓰기로 하자.칼다리 (토크) 2014년 10월 5일 (UTC) 19:59 [응답]
이것이 독자에게 확실히 영향을 미치고 사이드바로 이동하는 것이 매우 유용할 것이다.위키프로젝트 중국도 이미 그런 시스템을 이용해 번역과 단순화/전통화를 관리하는 것으로 알고 있는데, 이는 상당히 유사하다. --Tom (LT) 23:01, 2014년 10월 5일 (UTC)[응답]
든든한 지지.내가 몇 년 동안 말했듯이, 우리의 리드 문장은 망가졌어.리드 문장은 피험자의 이름과 관련된 모든 상상할 수 있는 기록이 기계가 읽을 수 있도록 저장되어 있는 데이터베이스 테이블이 아니다.리드 문장은 우리가 어떤 주제가 중립적이고 단순하며 평범한 영어, 적절한 가중치, 접근 가능한 형식으로 인간 독자들에게 말하는 것이다.발음, 번역, 모호한 역사 및 지리적 대안 등 추가 정보는 환영할 만하지만, 그것들은 첫 번째 문장의 바깥쪽에 절대적으로 속한다.각주, 기사 본문, 사이드박스 등등.리드 문장은 데이터베이스가 아니다.
나는 누군가가 "야, 만약 특정한 리드 문장이 너무 꽉 차게 되면, 우리는 새로운 규칙을 만들지 않고도 사례별로 그 항목들을 제거하기 시작할 수 있다."라고 말할 것이라는 것을 안다.나는 단지 이것에 전혀 동의하지 않는다.우리의 표준은 누군가가 강한 독특한 경우를 만들지 않는 한 발음이나 번역을 하지 않고 오직 한 명의 이름만이 선두에 서야 한다.다른 길이 아니다.—지정 (대화) 23:39, 2014년 10월 5일 (UTC)[응답]
별칭 섹션 기사에 별개의 이름 섹션이 있어야 하는 고전적인 경우다.이런 식으로 우리는 왜 이렇게 많은 이름들이 있고, 그 이름들이 모두 어디에서 왔는지, 왜 모두 같지 않은지 설명할 수 있다.오이야르밥시 (대화) 02:26, 2014년 10월 6일 (UTC)[응답하라]

내가 이 생각에 찬성하는 만큼, 몇 년 전에 독일과 폴란드 이름을 놓고 우리가 벌였던 명명 분쟁을 모두에게 상기시켜도 될까?나는 많은 경우에 이 문제가 수많은 민족과 문화 분쟁을 해결한 결과라고 의심한다.이러한 분쟁의 재도발(이러한 문제가 합리적으로 해결될 것으로 의심되는 경우)을 처리하려고 하지 않는 한, (1) 이러한 분쟁을 피하기 위해 사용할 장소 이름에 사용할 수 있는 신뢰할 수 있는 출처에 동의하거나, (2) 이러한 분쟁의 규모를 확인하기 위해 이름이 심각한 분쟁에 처한 장소를 신속하게 조사하도록 제안하고 싶다.논쟁은 그럴지도 모른다.우리가 모르는 악마보다 우리가 알고 있는 악마(나쁜 외모의 리드 단락)가 더 낫다(우리 중 소수만이 들어본 장소의 이름을 둘러싼 끝없는 문화 민족 갈등). -- llywratch (대화) 22:21, 2014년 10월 8일 (UTC)[응답]

리드에 대체 이름을 입력하더라도 아티클은 모든 대체 이름을 리디렉션해야 하는 하나의 네임스페이스에만 있을 수 있다.따라서 위에서 언급한 이익집단에 굴복할 경우, X를 그 반대보다는 Y로 리디렉션해야 한다는 추가 갈등이 발생할 수 있다.여기서 경험하는 법칙은 이것이 영어 위키백과고 여기 독일, 폴스카 & 외스테르레이히는 항상 독일, 폴란드, 오스트리아로 리디렉션되며, 그 반대의 경우도 아니다.내 말 알아 들었으면 좋겠다. --프린스마테우(토크) 11시 20분, 2014년 10월 10일 (UTC)[응답하라]
발트해 항구도시인 그단스크/단치히의 이름을 둘러싼 잘 알려진 분쟁을 언급한다.그 이후로 적어도 한 명의 폴란드 원어민이 폴란드어 이름인 Odra로 어떤 강을 알 수 있다고 주장했는데, 분명히 Oder가 독일어 이름과 동일하기 때문이다.그리고 나서, 대부분의 영어 사용자들에게 친숙한 이름을 가진 장소의 이름이 바뀐 경우가 있다(예: 콜카타 & 캘커타).중요한 누군가의 의도성은 이러한 분쟁이 많지만, 왜냐하면 대부분의 Wikipedians 갈등 사실 및 관계가 있다는 않다 튀어 나오게 하지 않고 결과 오해 종종으로 물드(한쪽은 레이블"트롤들"&cranks", 다른"bigots"&"Wiki-Nazis")냉각기 및 전에 이름을 적어도 한번의 주기를 호출하고 있다. 더 공감마음이 어떤 형태로든 타협을 통해 우세하다.

만약 내가 여기서 지나치게 조심하고 있다면, 글쎄, 나는 틀렸다는 것이 입증되어 기뻐할 것이다; 나는 첫 문장에 이러한 대체적인 이름들을 삽입함으로써 리드가 혼란스러워지고 있다는 OP에 동의한다.그리고 나는 만약 어떤 민감성과 지혜로 다루어진다면, 이 변화를 만드는 것은 비사건일 수 있다고 생각한다.하지만, 전에 말했듯이, 나는 지난 12년 동안 내가 목격한 것을 쓰고 있다.이런 종류의 사전 작업을 먼저 하지 않고 이러한 변화를 만들면 필연적으로 멍든 자아, 고약한 편집 전쟁, ArbCom의 작업, & 소중한 편집자들이 그만둘 것이다. --llywrch (대화) 15:57, 2014년 10월 10일 (UTC)[응답]

이 제안은 우리가 이미 모든 명함 기사에 대해 하나의 제목을 선택해야 한다는 사실을 바꾸지는 않으며, 대체 이름에서 리디렉션을 제공한다.그것은 (라틴어가 아닌 모든 대본과 발음 링크와 함께) 대체 이름이 표시되는 페이지의 위치만을 가리킨다.그리고 나는 첫 번째 문장이 비록 인쇄된 참고 문헌에서 전통적으로 이런 식으로 행해졌다고 해도 이상적인 위치가 아니라는 것에 동의한다.몇 가지 제안된 레이아웃에 대해 설명해 주시겠습니까? 노이스터(토크), 2014년 10월 10일(UTC) 16:51[응답]
나는 위키백과 강연에서 만들어진 게시물에서 이 토론으로 향했다.위키프로젝트 인포박스.테니스 선수 팡타른 플리푸에흐가 예시처럼 태국어 철자를 선두에 세워야 하는지 아니면 인포박스 위에 올려야 하는지에 관한 것이었다.그 페이지는 두 군데에 걸쳐 있었고, 나에게는 그것이 과잉 살상인 것처럼 보였지만, 나는 위키백과에서 어떤 지침이나 합의가 여기 쪽으로 기울고 있는지 확신할 수 없었다.새로운 편집에서 편집자는 그것을 선두에 놓아두었지만 그것을 infobox 위에서 제거하고 "native_name =" 헤더가 있는 infobox 안에 두었다.이제 이 특별한 사례는 위의 우스꽝스러운 헤브론 사례와는 달리 선두에 한 가지 추가만 있을 뿐이다.철자가 하나 더 있고 어쩌면 발음이 하나라도 더 있으면 별일 아닌 것 같다.그 후에는 읽기가 매우 어려워지고 별도의 "이름" 섹션을 가져야 한다.하지만 여러분 모두가 이 문제에 대해 더 잘 알고 있는 것 같기 때문에, 나는 납과 인포박스에서 철자를 더 많이 쓰는 것에 대한 일반적인 합의가 무엇인지 묻고 싶었다.나는 상자 위의 두 개의 철자보다 infobox 안에 있는 것이 더 좋지만, 납과 상자 둘 다에 있어야 한다. 아니면 한 곳이 충분한가?Fyunck(클릭) (토크) 18:46, 2014년 10월 10일 (UTC)[응답]

Llywrch, 물론 당신의 걱정은 꽤 타당하지만, 나는 이것이 합리적으로 처리될 수 있다고 생각한다.우리는 궁극적으로 어떤 기사의 제목을 붙여야 할지 결정해야 하고, 우리는 논쟁을 유도하기 위한 지리적 장소 이름 규약을 가지고 있다.나는 이 제안이 그 부분을 약간 바꿀 것이라고 생각한다. 그리고 그 토론 페이지에서 이 토론과 연계하는 것이 가치있을지도 모른다.본질적으로, 대부분의 장소들은 영어 출처에서 널리 주어지는 하나의 이름, 또는 영어 독자들에게 훨씬 더 일반적으로 알려진 이름을 가지고 있다.그러한 기사는 다음과 같이 읽힐 것이다.

런던은 영국과 영국의 수도다.[4]

서로 다른 이름을 가진 장소들이 실질적으로 영어 독자에 의해 인식될 수 있고 (다른 일반 이름에서 리디렉션된) 경우:

단치히로도 알려진 그다이스크는 발트 해안에 있는 폴란드 도시로서, 폴란드의 주요 항구도시인 포메라니아 보이보데스의 수도로 폴란드 제4의 대도시권의 중심지다.[1]그 도시는 몇 가지 다른 이름으로 알려져 있다.

한 때 일반적으로 사용되는 이름이 있는 장소의 경우, 여전히 사용되지만 다른 이름은 영어에서 더 일반적으로 사용되게 되었다.

역사적으로 캘커타로 알려진 콜카타는 인도 서벵골 주의 수도다.

오데르 강에 대해서는 폴란드 토착 독자에 대해서는 폴란드 이름을 제목으로 사용하자는 주장은 서투르다.이것은 폴란드어 위키피디아가 아니며, 일반적인 영어 이름이 다른 언어와 비슷한지 아니면 모국어와 다른지는 중요하지 않다.우리는 영어 이름을 사용한다.다른 이름(기사에 제시된 여러 이름 중 하나일 뿐)은 사이드바 또는 어떤 대체 위치가 결정되는지에 표시된다.

오더는 중부 유럽에 있는 강이다.체코 공화국에서 솟아오르며(일반적으로 북쪽과 북서쪽으로) 폴란드 서부를 통과해 흐르며, 이후 폴란드와 독일 사이의 국경에서 187km(116mi)를 형성하며, 오데르-네이세 선의 일부다.

한 가지 더 예를 들어보자. 내 고향과 고향에서 본 말이다.

세인트로렌스 강은 북아메리카의 중간 위도에서 남서쪽에서 북동쪽으로 대략 흘러가는 큰 강으로, 대서양과 대서양을 연결한다.

현 협약은 지역 이름을 납골당에 포함시키는 것을 요구하고 있는데, 그 이유는 알 수 있지만 나는 그 조언이 잘못되었다고 생각한다.그것은 요약되어야 할 것의 흐름을 방해한다.헤브론 사례에서와 마찬가지로, 기사의 요약을 찾는 일반 영국 독자들은 모하크 이름의 의미와 함께 프랑스어, 투스카로라, 모하크 이름이 첫 문장 바로 중간에 어색하게 붙어 있는 것을 보는 데 관심이 없을 것 같다.이 세부 사항은 중요하지만 다른 곳으로 옮겨야 한다.우리는 영어 독자들을 위한 백과사전을 만들고 있으니, 이 정보를 다른 곳에 포함시켜야 해.이반벡터 (대화) 2014년 10월 10일 (UTC) 18:34 [응답]

나는 이반벡터의 발언을 지지한다.WP의 지침:READCLUTER는 약하며, 나는 READCLUTER의 예를 이반벡터의 제안으로 대체하고 싶다.배리조이스 (대화) 07:22, 2014년 10월 12일 (UTC)[응답]
  • 나는 영어에 없는 모든 것을 꺼내서 리드선을 해독하는 아이디어를 지지한다.헤브론의 경우, 그 긴 각주 번호의 끈도 함께 가야 한다.앤드류 (대화) 2014년 10월 10일 (UTC) 19:24 [응답]
    내가 말하려던 건, 중간 문장의 각주 5개가 다른 잡동사니들과 거의 비슷하다는 거야.Fyunck(클릭) (토크) 19:39, 2014년 10월 10일 (UTC)[응답]
그것도 좋은 지적이야.WP별:CITELD, 레드는 체내에 나타나는 것을 요약한 것이어야 하므로, 많은 경우 레드에 인라인 인용문을 제공할 필요가 없어야 한다.그러나 WP와 같이 그것이 필요할 수 있는 경우도 있다.MINREF. Ivanvector (대화) 13:31, 2014년 10월 12일 (UTC)[응답]
  • 헤브론의 예는 그저 형편없을 뿐이다. 그것은 상자 안에 넣지 말고 몸 어딘가에 넣어야 할 도움이 되지 않는 정보다.컬리 터키 turkey'gobble!! 04:48, 2014년 10월 12일 (UTC)[응답]
  • 반대측 사이드박스 - 아니, 자비를 베풀어라(인포박스에 대한 분쟁 참조).납 문장을 해독하는 것을 지지하지만, 가장 좋은 해결책은 사례별로 찾아야 한다.숙련된 편집자의 몇 가지 권장 사항을 지침에 추가하되 이에 대한 "규칙"을 수정하지 마십시오.게르만조 (대화) 2014년 10월 12일 (UTC) 14:35 [응답]
합리적인 것 같다.'대체성적' 인포박스는 헤브론에서 통할 것으로 보이지만 그단스크는 대신 '대체성명' 섹션을 사용한다.내 생각에 이 제안은 단지 "그들에게 아부하지 말라"에 국한되어 있는 것 같다.이반벡터 (대화) 15:05, 2014년 10월 12일 (UTC)[응답]

AfC 재제출

내가 AfC에서 주목한 한 가지는 아무런 변화 없이 또는 분 단위로 재제출되는 재제출이 많다는 것이다.우리는 현재 검토가 필요한 2,500개가 넘는 AFC를 보유하고 있으며, 그것은 시간이 오래 걸린다.따라서, 나는 거절된 AfC는 변경사항 없이 재제출될 수 없으며/또는 AfCs가 재제출될 때까지 1주일을 기다려야 한다고 제안한다.이번 주는 저자들이 기사를 철저히 수정할 수 있는 시간을 줄 것이다.Origamiteⓣⓒ 17:50, 2014년 9월 28일 (UTC)[응답]

만약 당신이 모든 거절된 AFC들이 유효하게 거절당했다고 보장할 수 있다면, 그리고 예를 들어, AFC 검토자가 출처의 형식이나 다른 마찬가지로 사소한 사항들에 대해 반대했기 때문에, 더 기꺼이 지지할 것이다.WhatamIdoing (대화) 23:29, 2014년 9월 28일 (UTC)[응답]
(AfC가 목표로 하는) 새로운 편집자들은 하락이 유효한지 알 것 같지 않기 때문에, 이것이 IMO에 초점을 맞춰서는 안 된다. 어쨌든, 나는 이것을 지지하며, 기술적인 관점에서 할 수 있다.잭mcbarn (대화) 14:23, 2014년 10월 2일 (UTC)[응답]
그리고 그것은 멋진 제안이다.이 제출물들을 감시하는 일을 비트태스크로 만들자는 것인가? --Tito☸Dutta 21:22, 2014년 10월 12일 (UTC)[응답]

관리 교육: 좋은 생각?

나는 누군가가 관리자가 된 후, 훈련 프로그램에서 일정 시간(얼마나 걸릴지는 모르겠지만, 그것은 관리 행동의 수에서 정의될 것이다)을 소비하도록 요구되어야 한다고 제안한다.내 제안에 따르면 이 프로그램은 (정상적인 편집을 하는 것 외에) 실제 관리자들이 하는 것과 같은 (차단 및 보호와 같은) 결정을 내리는 것을 포함하지만 아무런 효과도 없을 것이다.기존 관리자들은 관리자들이 자주 겪는 어려운 상황에서 어떻게 행동해야 하는지 알고 있는지 판단하기 위한 목적일 것이다.나는 이것이 새로운 관리자가 새로운 책임을 지기 전에 최소한 약간의 경험을 쌓도록 도와줄 것이기 때문에 좋은 생각이라고 생각한다.생각을 해 주면 고맙겠다.진킨슨이 2014년 10월 8일 01:35, 8(UTC)과 통화[응답]

BTW, 나는 이것을 WP에서 보았다.다년간 지속되는 제안이지만 이에 대한 대부분의 부분은 사실 일부 사람들에게 전부는 아니지만 일부 사람들에게 관리자 권한을 부여하는데 관한 것인데, 이것은 내가 제안하는 것과는 전혀 다른 문제다.진킨슨은 2014년 10월 8일 01:37, 나에게 말[응답]
범주:관리자 지시사항.—파장 (대화) 03:25, 2014년 10월 8일 (UTC)[응답]
중요한 건...관리자들이 스스로 느끼는 대부분의 상황은 "상황이 좋지 않은 상황"이 아니다.관리 도구의 대다수는 완전히 논란의 여지가 없고 전혀 어렵지 않다.원시 블록 로그를 보십시오.원시 삭제 로그를 보십시오.뭘 찾았지?선명하고 눈에 띄는 반달리즘과 반달리즘.그로스 편집 전쟁.분명한 하우스키핑.주어진 하루 동안 수 천 건의 관리 조치 중에서 대개 한 손에 AN/I에서 제기되는 수를 셀 수 있다. 그 극히 일부만 뒤집힐 뿐이다.
주어진 행정관이라면 누구나 논란의 여지가 있는 상황의 '최초'가 될 것이다.어떤 관리자도 어떤 경우에도 어떤 조치를 취하도록 강요 받지 않는다. 우리는 언제나 상황을 더 잘 다룰 수 있다고 느끼는 사람에게 맡길 수 있다.설상가상으로, 이 제안은 위키백과 정책을 해석하거나 적용하는 방법에 대한 진정한 의견 불일치가 아니라, 주어진 "힘든 상황"이 실제로 '정확한' 반응을 가질 것임을 시사한다.
어떤 경우에도, 이것이 더 진전되기 전에 진킨슨(또는 그 누구라도)은 (아주 적은 수의) 새 행정가들이 실제로 그러한 엉뚱하고 관료적인 과정을 구현하는 것을 정당화할 수 있는 문제를 나타낸다는 암묵적인 주장을 실제로 입증하기 위해 어느 정도 노력을 기울여야 한다.TenOfAllTraes(대화) 04:02, 2014년 10월 8일(UTC)[응답]
그들은 행실이 나쁜 행정관을 차단하는 방법을 배울 것인가?대부분은 그것을 할 수 없을 것 같다.HiLo48 (대화) 05:38, 2014년 10월 8일 (UTC)[응답]
그러니까...WP:ADCO.레고크tm (대화) 07:56, 2014년 10월 14일 (UTC)[응답]

배아 프로젝트 백과사전과의 간단한 파트너십

나는 배아 프로젝트 백과사전의 편집장으로 있다. 온라인 오픈 액세스 출판물은 포괄적인 청중을 대상으로 한다.우리는 우리의 내용을 위키피디아 페이지에 통합할 것을 제안한다.

먼저 백과사전을 설명하고, 왜 우리가 여기에 글을 올렸는지, 그리고 마지막으로 위키피디아와 파트너십을 맺자는 우리의 제안을 설명하겠다.

배아 프로젝트 백과사전에는 태아학, 발달 생물학, 생식 의학에 관한 기사가 실려 있다.이 기사의 대상 청중은 대략 9년에서 16년 사이의 교육을 받은 사람들을 포함한다.이 백과사전의 목적은 위에 열거된 과학 분야에 대한 독자들의 과학적 읽고 쓰는 능력을 향상시키는 것이다.그 목적을 달성하기 위해 백과사전의 기사들은 역사적 방법을 사용하여 과학적 결과를 사회적 맥락에 배치한다.

이 백과사전은 미국 국립과학재단이 후원하고 있으며 애리조나 주립대 생물사회센터와 해양생물연구소가 협업한 산물이다.모든 기사는 엄격한 동료와 편집 리뷰를 받아 사실적이고 비평가적이며, 내용 확인을 위해 독자들을 온라인 자원에 연결시킨다.이 출판물은 ISSN이 1940-5030이며, 모든 콘텐츠는 크리에이티브 커먼즈 라이선스(CC BY-NC-SA 3.0)이며, 기사는 구글 스콜라처럼 학술적인 데이터베이스에 색인되어 있다.

우리는 우리의 컨텐츠를 위키피디아와 제휴하고 싶다.다양한 채널을 통해 이 포럼이 위키백과에서 우리의 콘텐츠를 공유하는 계획을 제안하기에 가장 적절한 장소를 제공한다는 것을 알게 되었지만, 대신 다른 방법을 사용해야 한다면 우리에게 알려주기 바란다.

다음 계획은 초기 제안을 설명한다.

배경 우리 백과사전에는 600개 미만의 기사가 있지만, 우리는 일주일에 3개의 새로운 기사를 발행한다.

목표 우리는 '외부 링크' 헤더 아래에 있는 관련 위키백과 페이지에 우리의 기사를 연결하기 위한 몇 가지 단계를 편집 과정에 포함시키고자 한다.예를 들어, 프랑수아 제이콥에 관한 기사를 방금 발표했듯이, 프랑수아 제이콥 위키피디아 페이지의 '외부 링크' 아래에 그것에 대한 링크를 포함시키고자 한다.

문제 그러한 관행을 시험적으로 실행하면서 위키미디안들은 우리의 링크들 중 많은 부분을 당연히 삭제했다.그들은 그러한 링크는 스팸이고, 자기 홍보적이며, 따라서 위키피디아의 편집과 게시 원칙을 위반한다고 주장한다.우리는 스파이웨어 방지 원칙의 필요성에 감사하며 위키미디안들이 우리의 관행을 잠재적으로 스팸메일로 어떻게 제약할 수 있는지 본다.그러나 우리는 배아 프로젝트 백과사전 기사와의 연관성을 배제해서는 안 된다고 생각한다.우리는 어떤 것도 팔지 않고, 위키피디아와 관련된 허가 결과물도 없으며, 가능한 한 평가에서 자유롭고, 검증 가능한 한 그들의 주제에 대해 정확하다는 것을 확인하는 것 외에는 우리의 기사를 편향하지 않는다.

프로포즈

1) 위키백과에서 위키백과 기사에 링크를 게시할 수 있는 단일 위키백과 계정을 지정하고자 한다.내가 지금 사용하고 있는 것은 그 기능에 효과가 있다.

2) 배아프로젝트 백과사전 기사와 연결될 수 있지만 다른 웹사이트는 없다는 점에서 그 계정은 반스파이밍 원칙에 대한 면역이 제한되어 있기를 바란다.게다가, 이 계정은 관련 위키백과 페이지의 배아 프로젝트 백과사전 기사와 연결하는데 사용될 수 있다.그렇게 하면 위키피디아의 제이콥 페이지와 파스퇴르 연구소 시대에 대한 우리의 제이콥 기사와 연결될 수 있지만, 예를 들어 게이지 물리학 페이지에는 연결되지 않는다.

3) 다른 위키미디안들이 우리의 페이지 편집 내용을 확인할 때 우리 계정의 제한된 면책특권 상태를 어떻게든 볼 수 있기를 바란다.

4) 우리는 그러한 한정된 불특정 계정을 강제할 수 없다고 제안하지 않으며, 위키미디안들은 부적절한 것으로 판단될 경우 여전히 우리의 연계를 삭제할 수 있다.우리는 단지 반스팸 원칙의 포괄적 적용에 근거한 삭제를 피하려고 한다.

5) 다음의 표준 링크 구문을 제안한다.

예:

최종 의견 우리의 제안을 초기 단계로 간주하십시오.우리 편집팀의 어느 누구도 위키피디아의 정책과 실천에 대한 경험이 많지 않으며, 우리의 제안이 위키피디아의 역량과 정책에 부합하는지 확신할 수 없다.어떤 의미에서, 우리는 무엇을 요청해야 할지 잘 모르지만, 우리의 명시적인 목표와 우리가 그것에 도달하지 못하게 하는 문제를 고려할 때, 우리는 당신이 어떻게 앞으로 나아갈 것인지에 대한 생각을 가지고 있을 것으로 기대한다.— Embreoproject (대화 • 기여) 20:38, 2014년 10월 10일 (UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평

관련 위키백과 제목(WT:BIOG) 그리고 거기 있는 누군가에게 제안서를 평가하도록 요청하십시오.첫 번째 단계는 그 지역에서 편집하는 사람들이 어떤 이득이 있을 것이라고 믿는지를 보는 것이다.조누니크 (대화) 23:12, 2014년 10월 10일 (UTC)[응답]

•괜찮아.우리는 당신의 조언에 감사한다.엠브리오프로젝트 (대화) 17:29, 2014년 10월 11일 (UTC)[응답]

이건 불가능하진 않지만:
귀하의 계정은 역할 계정으로 WP 규칙을 위반하는 것으로 보인다(WP: 참조):ROLE. 어떤 계정을 사용하든 자신이 누구인지, 무엇을 하고 있는지 완전히 설명하는 사용자 페이지가 있어야 한다.너의 것은 아직 설정되지 않았다.
사용자:WilliamDigiCol/Working 페이지 2014에서 COI(이 경우 나 자신) 없이 설립된 위키피디아가 제안한 링크의 "검토"를 관리하는 좋은 방법을 찾고 있다.잘 들어라, 내가 너의 기사들 중 몇 가지를 보았고 그것들을 연결할 가치가 있다고 생각하지만, 그것들은 메트로폴리탄 박물관의 PDF 책과 같은 등급은 아니다.칸 아카데미는 또한 매우 많은 외부 연계를 가지고 있지만, COI 문제가 없는 위키백과들에 의해 배치된다.당신의 기사는 WP:RS, 그러나 나는 WP가 아니라고 생각한다.의료용 물품에 대한 MEDRS.존보드 (대화)20:27, 2014년 10월 11일 (UTC)[응답]
  • "우리는 그 계정이 스팸 차단 원칙에 대한 제한적인 면책특권을 갖기를 원한다"고 반대한다. 다시 말해서, 당신은 스팸에 대한 공식적인 허가를 원한다.절대로 그렇지 않아요.Andrew Lenahan - Starblind 13:03, 2014년 10월 12일 (UTC)[응답]
  • 5개의 제안 중 오직 (#5)만이 합리적인 것처럼 보인다.우리는 아마도 이것을 위한 템플릿을 가질 수 있을 것이다.그러나 면허증이 호환되기 때문에 배아 백과사전의 자료를 여기서 사용할 수 있을 것이다.그러나 대상 청중은 다를 수 있으므로 편집이 필요할 수 있다.또한 사용자:엠브리오프로젝트 이름을 사용자:와 같이 사람을 나타내도록 변경하십시오.엠브리오프로젝트에서 프랑수아 제이콥을 만났어Graeme Bartlett (대화) 22:33, 2014년 10월 12일 (UTC)[응답]
  • 한 예는 http://embryo.asu.edu/pages/neurocristopathies에서 확장될 수 있는 신경병증이다.그러나 불행히도 발 쪽지는 없고, 단지 왜곡되지 않은 출처만 있기 때문에, 소싱에 대한 위키백과 표준에 도달하는 것은 상당한 작업이 될 것이다.관심 있는 프로젝트는 사용할 가치가 있는 배아 페이지를 보아야 한다.배아 백과사전은 위키피디아로부터 좋은 생각의 일부를 더 가져갈 수 있다.Graeme Bartlett (대화) 23:12, 2014년 10월 12일 (UTC)[응답]
The licence isn't actually compatible if it is CC-BY-NC-SA , as Wikipedia uses just CC-BY-SA. ie, any reuse by us would violate the -NC-SA (non-commercial share-alike) provisions, as we would be publishing under a different licence that allows commercial reuse. - Evad37[talk] 11:55, 13 October 2014 (UTC)[reply]
네 말이 맞아, 내 코멘트의 그 부분을 삭제했어!Graeme Bartlett (대화) 21:55, 2014년 10월 13일 (UTC)[응답]
  • 위키피디아는 외부 링크를 걸기를 원하지만 이해관계가 상충되는 사람들이 기사의 토크 페이지에 해당 링크를 올릴 수 있도록 한다(WP:ADV). 그렇게 해서 두 번째 중립적인 편집자는 링크의 유용성을 확인하여 기사에 올릴 수 있다.이를 위해 특별한 허가가 필요 없으며, 원할 때 언제든지 시작할 수 있다.아마도 링크를 설명하는 텍스트와 함께 가장 최근에 작성된 외부 링크에 접근할 수 있다.이것의 표준 텍스트를 만들 수도 있다.진심으로 타케타(토크) 12:11, 2014년 10월 13일 (UTC)[응답]
  • 세 번째 항목에 문제가 있음:우리는 다른 위키미디안들이 우리의 페이지 편집을 확인할 때 우리 계정의 제한된 면책특권 상태를 어떻게든 볼 수 있기를 바란다.의심스러운 고리를 보는 편집자들은 특히 많은 중간 편집이 있거나 편집자가 한 기사에서 의심스러운 고리의 축적을 삭제하는 경우, 누가 그것을 배치했는지 이력을 확인하지 않고 그것을 삭제하는 경우가 많다.기술적 해결책은 {{}}와 유사한 템플릿을 설정하는 것일 수 있다.IMDb title}}(예: 배아(영화)에서 사용된 것과 같다.편집자들은 그러한 템플릿의 존재가 그러한 링크에 대한 지역사회의 승인을 함축한다는 것을 이해하면서 그러한 링크를 그냥 둘 가능성이 더 높을 수 있다.물론, 당신은 여전히 사전 승인을 받아야 한다.네비 (대화) 2014년 10월 13일 (UTC) 12시 30분[응답]
  • 감사합니다, 여러분.그것은 나를 위해 모든 것을 분명히 했다.우리는 최소한 다음과 같은 과제를 추구할 것이다.
o) 이미 내 계정에 대한 사용자 이름 변경을 요청하였다.
i) 특정 위키백과 페이지에 있는 토크 기능을 이용하여 편집자에게 우리의 기사를 검토하고 링크하도록 요청할 것이다.
ii) User와 유사한 사용자 페이지를 개발한다.2014년 WilliamDigiCol/Working page 2014는 COI가 없는 기존 위키백과들에게 우리 페이지에 대한 외부 링크를 승인하도록 체계적으로 요청하는 수단이다.
iii) IMDB의 형태를 따라 외부 링크에 대한 템플릿을 구축하고자 한다.
그 모든 것을 고려해 볼 때, 그리고 간단한 질문을 해서 미안하지만, 넓은 주제 분야에서 확립된 위키미디안을 어떻게 찾을 수 있을까?일단 발견되면, 나는 그들에게 외부 링크를 위한 템플릿을 제안하는가, 아니면 다른 방법을 추구해야 하는가?엠브리오프로젝트 (대화) 22:39, 2014년 10월 13일 (UTC)[응답]
어서 오십시오, 엠브리오프로젝트.당신은 WP에서 몇몇 관심있는 사람들을 찾을 수 있다.위키프로젝트 해부학, WP:WikiProject Medicine 및 WP:위키프로젝트 생리학.이러한 그룹의 토크 페이지에 메모를 남긴 후 나중에 응답한 사람이 있는지 확인하십시오.WhatamIdoing (대화) 17:09, 2014년 10월 14일 (UTC)[응답]
  • 범주:발생학, 바퀴를 재발명한다.국립과학재단, 애리조나 주립대, 생물사회센터, 베를린의 막스 플랑크 과학사연구소, 엠비엘 WHOI 도서관이 위키백과에 기금을 기부할 것을 제안한다.그렇게 되면 윈윈(Win Win) 상황이 될 것이다. --Aspro(토크) 17:34, 2014년 10월 14일 (UTC)[응답]

워치리스트 관련

페이브리케이터에서 추적됨
과제 T242424
  1. 각 항목의 시작 부분에 있는 "diff hists" 링크에 토글링 "unwatch"/"watch"/"watch" 링크를 추가하십시오(파이프가 아닌 점/간격자를 그들 사이의 구분 기호로 사용하시겠습니까?);
  2. 리스트의 페이지를 변경하지 않고 유지한 기간에 따라 리스트를 역순으로 보거나 재정렬하는 수단.

나는 이것이 지속적이고/영구적이거나 이미 가능하다고 생각하지 않지만, 둘 중 하나 또는 둘 다거나 둘 다라면 사과한다(그리고 내가 어떻게 봐야 하는지/어디로 봐야 하는지 표시해 줘).사르다나팔루스 (대화) 11:54, 2014년 10월 8일 (UTC)[응답하라]

  1. 사용자 보기:Js/워치리스트.
  2. 그것은 사소한 것이 아니다, 왜냐하면 감시목록은 지난 30일 동안만 있었던 최근의 변화표로부터 데이터를 얻고 있기 때문이다.그래서 이것보다 더 오래된 것을 보여주기 위해서는 단지 정렬 순서의 변경이 아니라, 데이터베이스에서 이러한 데이터를 추출하는 다른 방법이 필요하다.아마 가능하겠지만, 효율성은 떨어질 겁니다.— HHHIPO 21:41, 2014년 10월 8일 (UTC)[응답]
  • 답장은 고맙고, 이번 회신 전엔 미안했어.방금 사용자 설치:Js/워치리스트 – 재미있어 보이는 – 그리고, 그렇다, 나는 "역/역방향 워치리스트"가 상대적으로 까다로울 수 있는지 궁금했다.한편, 소프트웨어가 감시 목록을 통해 지난 N시간/일 동안 어떤 항목이 변경되었는지 확인해야 한다면, 각 항목이 마지막으로 변경되었을 때를 조회하는 것이 아닐 것이며, 따라서 소프트웨어가 그 후 역순으로 표시할 수 있는 목록을 생성하는 것 보다 한두 단계 밖에 남지 않을 것이다.
안녕하십니까, 사르다나팔루스 (대화) 23:02, 2014년 10월 15일 (UTC)[응답]

TWL 자원봉사자 필요

위키백과 도서관은 새롭고 지속적인 파트너십을 관리하는 데 도움이 되는 자원 봉사 계정 코디네이터를 찾고 있다.우리는 현지의 자원 봉사자들과 위키 교차 경험을 가진 사람들(특히 영어 이외의 위키피디아에서)을 둘 다 갖는 것에 관심이 있다.그것은 평균적으로 일주일에 두어 시간씩의 약속이 필요하다.신청하려면 다음 웹 사이트를 방문하십시오.TWL/코디네이터/가입.니키마리아 (대화) 16:53, 2014년 10월 16일 (UTC)[응답]

새로운 봇 제안

나는 이것이 그러한 제안에 대한 올바른 토론인지 확신할 수 없다.그러나 나는 중복 참조를 결합한 봇이 만들어지는 것을 제안하고 싶다. 그러한 봇은 새로운 기사를 작성하거나 전체적으로 참조를 결합하는 것을 어려워하는 편집자들에게 유용하게 쓰일 것이다.현재 그러한 봇 중 하나는 작동하지 않는다.--BabbaQ (talk) 15:20, 2014년 10월 19일 (UTC)[응답하라]

@BabbaQ:찾으시는 장소는 WP:BOTREQ. Andy Mabbett (Pigsonthewing); 앤디와 대화: 앤디의 편집작 15:29, 2014년 10월 19일 (UTC)[응답]
응, 여기 포스팅하고 바로 찾아서 미안해.지금 거기서 의뢰를 했는데 --BabbaQ (대화) 15:30, 2014년 10월 19일 (UTC)[응답]

IEG 제안에 대한 커뮤니티 입력 요청: 편집자 상호 작용 데이터 세트 및 시각화

들으셨겠지만, 에디터 인터랙션 데이터 추출 및 시각화는 개별 계약 보조금 제안이다.나는 아론 하프메이커(WMF), 하이담 샴마아(WMF), 파비안 플뢰크(칼스루헤 공과대)의 자원봉사와 조언으로 이 제안을 하고 있다.

우리는 당신이 이 프로젝트의 일반적인 개념을 지지하는지 반대하는지 여부에 대한 당신의 의견과 제안서를 어떻게 개선할 것인지에 대한 어떠한 제안도 매우 감사하게 생각한다.

또한 어떤 편집자 상호 작용 데이터 집합과 편집자 상호 작용 데이터의 시각화가 귀하의 관심사와 가장 관련이 있는지에 대해 귀하로부터 듣고자 한다.우리는 당신의 의견을 염두에 두고 우리의 생산에 우선순위를 두려고 한다.

제안 토크 페이지에 코멘트를 하십시오.긍정적이고 비판적인 질문과 피드백은 제안자로서 우리에게 도움이 되며, 또한 개별 참여 보조금 위원회[1]가 제안서를 평가하는 데에도 도움이 된다.

안녕하십니까 --Pine✉ 18:29, 2014년 10월 19일 (UTC)[응답]

[1] 나는 개별계약보조금 위원회의 일원이다.나는 이 자금조달 라운드에서 제안서를 검토하는 것을 반복하고 있다.

다음 사용자 대화 페이지 빈칸 또는 삭제: 무기한 금지된 사용자, 대화 페이지 액세스가 무기한 취소된 사용자, 위키백과를 자주 공격하는 사용자 관련 계정

나는 만약 누군가가 사용하지 않거나 사용할 수 없는 사용자 대화 페이지를 비우도록 봇을 설계했다면(예: 헤드라인에서 언급된 일부) 그것은 장기적으로 위키백과 서버의 공간을 절약할 수 있을 것이라고 생각하고 있었다(페이지의 내용이 합산될 수도 있고 트롤들이 매우 크거나 자원 집약적인 사용자 대화 p를 만들어 위키 자원을 낭비할 수 있다는 것을 깨닫게 될 수도 있다).이러한 콘텐츠가 삭제될 가능성을 줄이기 위해 의도적으로 금지된다.생각?— 67.164.188.243 (대화) 03:02, 2014년 10월 16일 사전 서명되지 않은 의견 추가

사실, 그렇게 되면 스토리지 사용량이 약간 늘어날 겁니다.빈 페이지와 삭제된 페이지는 여전히 기록으로 저장된다(일반 사용자가 해당 기록을 볼 수 없는 경우에도).제안된 편집은 단지 페이지 기록에 추가될 것이다.알제 (대화) 2014년 10월 16일 (UTC) 10:41, 응답하라
공백은 링크 테이블 및 검색 인덱스 항목과 같은 다른 항목을 제거할 수 있다.순효과는 모르지만 위키피디아:성능은 걱정하지 마십시오.그들의 행동 중 일부는 나중에 검토된다면 토크 페이지 내용을 유지하는 것이 가장 좋다.프라임헌터 (대화) 11시 7분, 2014년 10월 16일 (UTC)[응답]
또한, 무한 블록이 반드시 영구적인 것은 아니다; 그것들은 자동적으로 만료되는 것은 아니다.편집자가 무기한 블록에 호소하여 귀중한 기여를 하는 것으로 되돌아가는 것은 드문 일이 아니다.그들은 그들의 대화 페이지를 온전히 가지고 그렇게 할 수 있어야 한다.게다가, 일부 편집자들은 엄살을 부리며 돌아온다; 오래된 토크 페이지는 우리가 그것을 다루는 것을 돕는다.NebY (토크) 11:12, 2014년 10월 16일 (UTC)[응답]
@67, 원하면 이 문제를 논의할 수도 있지만, 일방적으로 제안서를 이행하는 것은 허용되지 않는다.방금 네가 변경한 내용을 차단(금지되지 않은) 사용자로 바꿨어.--Bbb23 (대화) 14:00, 2014년 10월 16일 (UTC)[응답]
우리는 이것을 하곤 했지만, 그것은 다소 무의미했기 때문에 그만두었다.미스터 지맨 2014년 10월 16일 (UTC) 15:08[응답]
나쁜 생각이야.차단된 사용자와 차단된 이유를 지적할 수 없다면 로그인하지 않은 편집자와 삭스푸퍼트에 의한 장기 남용을 취급(및 보고서 처리)하는 것이 더욱 어려워진다.— 아서 루빈 (대화) 16:27, 2014년 10월 16일 (UTC)[응답]
나는 아무것도 하지 않는 것을 지지한다.그냥 존재하게 내버려두고, 그들에 대해 아무것도 하지 말자. --Jayron32 23:18, 2014년 10월 16일 (UTC)[응답하라]
이것은 고전적인 "문제를 찾는 해결책"의 한 예처럼 보이므로 무의미하다.무기한 ≠ 영구.로저 (Dodger67) (토크) 10:51, 2014년 10월 18일 (UTC)[응답]

아마 WP 같은 걸 생각하고 있을 겁니다.OldIP. 이 사용자 페이지 삭제는 빠른 삭제 기준에 따라 거부됨 - 위키백과 대화:신속한 삭제/보관 33#U4 기준.이것들은 다양한 이유, 가장 중요한 스팸 추적에 절대적으로 필요하다. 스팸 링크를 추가하는 스팸 발송자는 사용자가 이전에 스팸 링크를 추가했는지 여부를 확인할 것이고, 만약 다른 계정에 정확히 동일한 스팸에 대해 경고가 있다면, 그들은 경고를 무시하고 즉시 차단할 수 있다.이것은 페이지가 삭제된 경우 가능하지 않다.IP 주소의 미래 소유자가 있는 경우 혜택을 위해 IP 페이지를 비워 두려면 삭제하지 마십시오.오이야르밥시 (대화) 00:54, 2014년 10월 23일 (UTC)[응답]

위키백과 삭제:스팸

지금 이 순간 위키백과:스팸은 AfD-프로세스에 의해 심각하게 훼손된다.아무리 기사 스팸을 많이 보내도 그런 이유로 거의 지워지지 않는다.그것과 공통된 추리는 스팸과 광고는 정상적인 편집으로 해결할 수 있지만, 실제 편집은 아무도 하지 않는다는 것이다.효과는 위키피디아가 스팸 발송자와 말하기는 하지만 행동하지는 않는 선의의 편집자에 의해 서서히 훼손된다는 것이다.내 경험의 가장 최근의 예는 위키백과다.삭제/Mydala용 문서.

이를 통해 WP:공허한 구절을 스팸메일로 보내는 것이 가장 좋을 것이다.배너톡 05:17 2014년 10월 18일 (UTC)[응답]

나는 내가 최근에 편집한 작품을 통해 그 기사에 대한 당신의 걱정을 대부분 해결했기를 바란다.목욕물과 함께 아기를 버릴 필요는 없다.2014년 10월 18일(UTC) GenQuest"Talk to Me" 08:38 [응답]
편집해줘서 고맙지만 너무 자주 일어나.배너톡 09:55, 2014년 10월 18일 (UTC)[응답]
절대 반대 이 제안은 모든 강도들이 범죄 현장에서 현행범으로 체포되지 않기 때문에, 강도 행위가 더 이상 범죄가 되어서는 안 된다는 제안과 같다.WP:SOFIXIT는 토론의 결과에 따라 행동하는 실패에 대한 일반적인 치료법이다.로저 (Dodger67) (토크) 11:12, 2014년 10월 18일 (UTC)[응답]
가장 강한 사람들은 분명히 반대한다.AFD는 정리가 되지 않는다.정중하게, 배너는 마이달라를 편집했는데, 그것은 빠른 삭제를 위해 플래그 지정("닫지도 않은" 노트로 거부), AfD에 플래그 지정(단 한 명의 편집자도 삭제하지 않았을 때 명백한 보관으로 눈 덮인)이었다.우리는 명백한 스팸인 기사에 대한 빠른 기준을 가지고 있고, AfD에서의 당신의 지명이 거듭되는 실패에 대해서는, 당신이 경솔한 지명의 명백한 패턴을 가지고 그 과정을 스팸 발송하는 것 자체가 AfD를 훼손하는 것이라는 지역 사회의 공감대를 나타내는 지표로 받아들여야 할 것이다.이반벡터 (대화) 2014년 10월 18일 (UTC) 14:30 (답변)
당신은 스팸성 기사를 유지하기 위해 AfD가 광고로 지명하는 데 사용되는 모든 가짜 주장을 정확히 사용하고 있다.배너톡 15:46, 2014년 10월 18일 (UTC)[응답]
하지만 내가 삭제 기사를 광고로 지명할 때, 나는 정리를 요구하지 않는다.나는 삭제를 요청한다.하지만 거의 항상 "AfD는 치우는 것이 아니다"라는 대답을 듣는데, 이것은 내가 요구하지 않는 것이다.배너톡 20:01, 2014년 10월 18일 (UTC)[응답]
맞다. "AFD는 정리가 안 된다"는 말은 "기사를 정리할 수 있다면 삭제 대상으로 지정하지 말라"는 뜻이다. AFD는 주로 위키백과 기사를 쓸 자격이 없는 기사에 사용된다.주제가 기사를 쓸 만하지만 기사 본문이 표준 이하라면(즉, "스팸") AFD는 부적절하다. --Jayron32 01:11, 2014년 10월 19일(UTC)[응답]
가장 큰 문제는 대부분의 경우 그러한 AfD를 폐쇄한 후에도 전혀 아무 일도 일어나지 않고 기피 및/또는 스팸 메일 기사가 제자리에 유지된다는 것이다.WP와 상충되는 모든 광고 문제:스팸, 아직 거기 있어.사실상 "AfD는 청소용이 아니다"는 홍보와 광고를 보호하는 역할을 한다.지금쯤 WP를 집행할 수 있는 유일한 방법은 다음과 같다.스팸은 AfD 또는 CSD를 통해 WP를 시행하기 위한 편집 부분으로서 기사를 삭제한다.스팸은 거의 안 된다.그것을 집행할 수단이 없는 정책은 무용지물이다.배너톡 15:12, 2014년 10월 19일 (UTC)[응답]
대부분의 경우 아무 일도 일어나지 않는다.WP:SOFIXIT 적용.Andy Mabbett (Pigsonthewing); 앤디와 대화: 앤디의 편집작 15:32, 2014년 10월 19일 (UTC)[응답]
AfD가 스팸 메일을 수정하는 방법이라는 것을 깨달았는가? 하지만 스팸 메일을 삭제하는 방법으로?2014년 10월 23일, 배너톡 03:04 (UTC)[응답]
만약 "거의 항상" 사람들이 당신이 그것을 잘못 이해하고 있다고 말한다면, 다시는 같은 일을 하지 않도록 노력하라.Andy Mabbett (Pigsonthewing); 앤디와 대화: 앤디의 편집작 15:32, 2014년 10월 19일 (UTC)[응답]
인신공격

사용자:배너는 그에게 같은 말을 계속 하는 수많은 편집자들의 말을 듣지 않는다(내 샌드박스에 내가 기록한 목록과 그가 삭제한 목록, 그의 유일한 성공적인 최근 AfD.거의 매일 그는 새로운 기사를 AfD에 제출하며, 각각은 WP를 사용하지 않는다.전에는 <배너>의 편집 기고가 없는 (그가 관찰하는 문제를 해결하기 위해) 각자는 내가 지켜봐 온 이후로 각각 뒤집혔다."정신병의 정의는 같은 일을 반복해서 하고 다른 결과를 기대하는 것이다."나는 그가 자신의 세계에서 미쳐도 괜찮다고 생각하지만, 그는 이 모든 경박한 AfDs의 과정에서 많은 다른 사람들의 시간과 노력을 빼앗는다.그의 행동은 연쇄적인 반달 행위와 다름없고 나는 그에 따라 그의 활동을 감시해 왔다.나는 우리가 이 문제를 징계로 해결해야 할지도 모른다고 예상했지만, 정말로 그에게 필요한 것은 구글을 어떻게 사용하는지에 대한 약간의 지시뿐이다.그는 편집하는 법을 확실히 알고 있다.만약 그가 AfD 항목을 만들고, 태그를 붙이고, 인용구가 필요한 발언을 하고, 논쟁을 하는 데 시간을 할애한다면, 대신 그는 정책을 바꾸려고 투덜거리지 않을 것이고, 우리는 여기서 그가 틀렸다고 말하지 않을 것이다.진짜, 어떻게 하면 그가 말을 듣게 할 수 있을까?Trackinfo (토크) 2014년 10월 20일 (UTC) 17:15 [응답]

그리고 너는 나를 괴롭히지 말고 인신공격을 중단하라는 말을 들었다.너는 나를 공격하고 흠집을 내는 데만 정신이 팔려 있어서, 굳이 사실을 제대로 알아내려고도 하지 않는다.내 마지막 50개 후보 중 21개는 삭제되고 2개는 병합되고 9개는 유지되고 15개는 공개된다.그래서 네가 여기서 하는 말은 순전히 허튼소리와 거짓말이다.배너토크 18:01, 2014년 10월 20일 (UTC)[응답]

DYK/Stats에 대한 제안사항에 대한 커뮤니티 입력 요청

안녕, 나는 일주일 전에 여기에 제안서들을 올렸고, 단지 사람들에게 ping을 하는 것만으로 답장을 받을 수 있었어.기본적으로 다음과 같이 요약된다.

  1. - 토크 페이지에는 아카이브가 있어야 한다고 생각한다.
  2. - 나는 DYK 경보 템플릿이 사용자 공간에 있는 오래된 규칙 버전 대신 프로젝트 공간에 있는 규칙의 공식 버전에 연결되어야 한다고 생각한다.
  3. - 구태의연한 규칙에 입각한 잘못된 계산에 대해 정정하고 싶다.

허락만 해준다면 이 모든 것을 내가 직접 할 수 있어 기쁘다.내 제안을 검토하고 참고하십시오.미리 고마워. -Thibbs (대화) 14:25, 2014년 10월 23일 (UTC)[응답하라]

책갈피

위키피디아에 내 책갈피를 나열할 수 있는 곳을 찾고 있었다.나는 그것을 찾을 수 없었으므로, 페이지 상단을 따라 책갈피 바를 만들 것을 제안한다.그것은 컴팩트한 개인용 바와 함께 가야 하며, 그래서 그것은 스크린을 한 사람이 가질 수 있는 모든 책갈피들로 덜 어수선하게 만들 것이다.

--maximum_capacity12

기사나 다른 위키백과 페이지는 사용자 페이지에서 연결할 수 있다.또한, 그것들은 변경될 때 플래그를 표시하기 위해 당신의 감시 목록에 올려질 수 있다.그건 그렇고, 네 개의 틸트로 대화할 수 있도록 게시물에 서명해줘(~~~~): 노이스터(토크), 09:40, 2014년 10월 25일 (UTC)[응답]

접을 수 있는 열이 있는 테이블

나는 가끔 테이블의 특정 열을 접을 수 있기를 바란다.예를 들어, 다음 표의 세 번째 열("모터 차량")을 더블 클릭할 때 세 번째 열은 네 번째 열과 다섯 번째 열을 숨기기 위해 네 번째 열과 다섯 번째 열을 모두 합하기 때문이다.그리고 나서, 만약 내가 그것을 다시 클릭한다면, 그들에게 보여 주기 위해서.때때로 테이블에는 너무 많은 열이 있을 수 있고, 그 다음, 당신이 테이블을 처음 볼 때, 독자들이 본질적인 것을 볼 수 있도록 어떤 컬럼은 숨겨지는 것이 더 나을 것이다.그렇다면 독자가 원한다면 그다지 중요하지 않은 칼럼을 쓸 수 있어야 한다.

그러한 기능을 구현할 생각을 한 사람이 있는가?

SouthVulcania의 차량 생산량(밀리언):

연도 자전거 자동차 트럭 자동차
2010 30 100 80 20
2009 29 90 70 20
2008 28 80 65 15

— Arc25 (대화) 22:23, 2014년 10월 17일 (UTC)[응답]

MediaWiki로 판단:Common.js, 섹션 접을 수 있는 표는 작은 자바스크립트로 가능해야 하지만 구현에는 상당한 테스트가 필요할 것이다.애덤 쿠어든 10:35, 2014년 10월 18일 (UTC)[응답]

나는 그것이 유용하다고 생각할 것이다.MOS에 따르면, 그 칼럼은 처음에 열어야 하지만, 나는 독자에게 몇몇 칼럼을 닫을 수 있는 선택권을 주는 가치를 알 수 있었다.또한 정렬 가능한 테이블의 경우 열 제목을 클릭하면 간단히 정렬되므로 테이블은 정렬이 가능하고 열 숨김이 허용되므로 각 옵션을 개별적으로 수행하는 방법을 생각해 보아야 한다는 점에 유의하십시오.--S Philbrick(Talk) 21:56, 2014년 10월 19일(UTC) [응답]
종종 나는 디폴트로 인해 붕괴된 내용을 불쾌하게 생각한다.기사의 주제와 관련된 정보는 공개적으로 제시되어야 한다.숨바꼭질하지 말고 클릭할 마법의 버튼을 찾도록 해 줘.-------------<>kmk(>--- (토크) 03:44, 2014년 10월 26일 (UTC)[응답]

검은색(또는 어두운) 위키백과 템플릿

나는 한동안 위키피디아의 검은색이나 어두운 디자인이 제안된 적이 있는지 찾고 있었다.그것을 찾을 수 없었던 것처럼, 나는 프로포즈를 시작한다.

이건 내가 생각한 것 만이 아닌 것 같아.백인으로 고생하는 사람이 많다.내가 사용하는 웹서비스는 대부분 검은색 배경(DuckDuckGo, Gmail, Google 등)으로 구성할 수 있다.게다가 어두운 배경은 에너지를 절약하는데 도움을 주는데, 이것은 모두에게 더 좋다.

위키피디아를 어두운 템플릿으로 설정할 수 있는지 궁금했다.Cerilet (대화) 12:33, 2014년 10월 24일 (UTC)[답답하다]

(주: 이것은 위키피디아에 대한 나의 첫 번째 편집이다.이것을 좀 더 편리한 곳으로 옮기거나 수정해야 할 부분이 있으면 편집해 주면 고맙겠다.)

Preferences → Outture → Skin = MonoBook을 선택하고 저장한 다음 Preferences → Gadgets → Gadgets → Monobook 스킨에 녹색 텍스트가 있는 검정 배경 사용 -- Gadget850 talk 12:42, 2014년 10월 24일 (UTC)[응답]
하지만 에너지 절약은 도시 전설이다, 구글 검색으로 확인할 수 있을 것이다.--S 필브릭(Talk) 12:56, 2014년 10월 24일 (UTC)[응답]
네. 검은 화면이 실제로 꺼진 결과인 음극선관 모니터를 사용하지 않는 한, 그리고 녹색은 읽을 에너지가 거의 필요하지 않은 유형이다. (같은 이유로 야간 시력 고글은 보통 녹색이다.)만약 당신의 모니터가 금세기(음, 세기 표시의 이쪽)에 만들어진 것이라면, 검은 화면을 표시하는 것은 흰색 화면만큼의 에너지를 사용하며, 빛을 분산시켜 검은색으로 보이게 하는 추가적인 작업을 할 가능성이 있다.이제, 나는 LCD 모니터의 전체 밝기를 낮추면 에너지를 덜 흡수할 수 있다는 것을 기억한다.
여전히 내가 검정 바탕에 흰색이나 초록색을 더 쉽게 읽을 수 있는 조명 조건들이 있고, 어떤 사람들은 흰색 바탕에 검정색이 있는 것에 대해 어떻게 어려움을 겪는지 이해할 수 있다.이안.톰슨 (대화) 13:06, 2014년 10월 24일 (UTC)[응답]
LCD 디스플레이는 백라이트를 차단/차단 해제하여 작동한다.그들의 에너지 소비는 기본적으로 그들이 보여주는 패턴과 무관하다.이론적으로 이미지를 전환할 때 적은 에너지 비용이 들지만, 그것은 매우 한계적이다.OLED 디스플레이의 경우 사용되는 에너지는 이미지의 밝기에 따라 달라지며, 그 효과는 휴대용 기기의 배터리 수명에 영향을 미칠 정도로 크다. --Stephan Schulz (talk) 13:14, 2014년 10월 24일 (UTC)[응답]
(아마존 킨들 같은) 구식 LCD 화면은 반대로 작동하고 있지? --NaBUru38 (대화) 22:12, 2014년 10월 25일 (UTC)[응답]
구식 LCD는 백라이트 없이 작동한다. 즉, 액정표시장치 뒤에서 반사되는 빛만 볼 수 있다.대부분의 킨들은 매우 다른 시스템에서 작동하는 화려한 전자잉크 디스플레이를 사용한다 - 거기서 디스플레이 자체는 빛을 반사하거나 흡수한다.그러나 둘 다 정적인 그림(실제 시스템에서 항상 그렇듯이 사소한 기술적 손실)을 유지하기 위해서만 에너지가 필요한 것은 아니다.--Stephan Schulz (대화) 07:29, 2014년 10월 26일 (UTC)[응답]

제안 신뢰할 수 있는 테스터 사용자 그룹

20:39, 2013년 5월 14일 (UTC) 나는 WMF에 "신뢰할 수 있는 테스터" 사용자 그룹을 만들 것을 제안했다.WMF의 누군가가 그것을 좋은 제안이라고 불렀다.그 후, 무슨 일이 일어났는지 모르겠다.

나는 미디어뷰어의 이 페이지에서 누군가가 RFC를 시작한 것을 볼 수 있다.나는 분명히 RFC를 지지하지만, 나는 거기에 쓰는 것을 너무 꺼려한다.WMF가 신경써?

어쨌든 현재 WMF가 변경(VisualEditor, MediaViewer 등)하면 편집자의 전체/수천명에게 강제적으로 적용되며, 이후 수 주 동안 수백 명의 편집자가 수십 개의 오류를 보고하고, WMF는 이를 수정/개선하고 있다.

구글이나 마이크로소프트 같은 '신뢰할 수 있는 테스터'(TT) 사용자 그룹을 만들 수 없을까.신뢰할 수 있는 테스터(TT)는 첫 번째 편집자가 기능을 테스트하여 좋은 기능이나 나쁜 기능, 나쁜 기능 등을 테스트할 것이다. --Tito☸Dutta 17:41, 2014년 10월 13일(UTC)[응답]

나는 MediaViewer를 테스트하는 사람들이 부족했다고 생각하지 않는다 - 미디어 뷰어에 대한 불만은 그것이 베타 버전일 때 시작되어 오늘날까지 멈추지 않고 있다.미디어뷰어의 가장 큰 문제 중 하나는 그것이 지역 사회와의 협의 없이 부과된 것이 아니라 지역사회의 격렬한 항의를 통해 부과된 것이라는 점이다.사람들이 항상 WMF 실험실의 베타 기능을 선택할 수 있는데 왜 우리가 별도의 "신뢰할 수 있는 테스터" 사용자 클래스가 필요한지 모르겠다.0x0077BE [/]talkcontrib 17:53, 2014년 10월 13일(UTC)[응답]
opt-in으로 처리할 수 있는 강제 기능을 제공하는 사용자 그룹이 필요하지 않다는 점에 동의하십시오.나는 "무허가" 테스터들이 해를 끼친 베타 기능을 사용했던 문제가 없다고 본다.— xaosflux 18:11, 2014년 10월 13일 (UTC)[응답]
답장은 다음과 같이 말했다.
"좋은 제안이군 :)나는 에릭(엘로쿠스)이 다른 곳에서 테스트하기보다는 미래에 엔위키에서 베타 형태로 물건을 배치하는 것에 매우 관심이 있다는 것을 안다; 이것이 많은 사용자들에게 문제가 되기 전에 '자연스럽게' 문제를 발견하도록 해줄 수 있기를 바란다.오케예스(WMF) (토크) 20:49, 2013년 5월 14일 (UTC)."
베타는 6개월 후에 왔다.위키백과:마을 펌프(기술)/아카이브 120#베타 기능 소개 및 미디어 뷰어프라임헌터(토크) 00:31, 2014년 10월 17일 (UTC)[응답]
여기 사용자로부터 아무런 이득도 볼 수 없다.이미 소프트웨어 강제 계층이 너무 많다.'모든 것에서 흠을 찾고자 하는 사람들'이 무시될 수 있도록 '중립' 테스터 집단을 파악해야 한다면 사회적으로 그렇게 할 수 있다.무작위 사용자에게 베타 기능을 의무화하기 전에 테스트하고 코멘트를 제공할 기회를 거부하는 것은 커뮤니티 입력의 측면에서 또 다른 중요한 퇴보일 것이다.Wnt (토크) 21:36, 2014년 10월 17일 (UTC)[응답]
이것은 사용자 권한이 아니다.이것은 사용자 기본 설정이다.기본 설정 패널 "항상 새로운 실험 기능 사용"에 확인란을 추가하십시오.오이야르밥시 (대화) 00:48, 2014년 10월 23일 (UTC)[응답]
신뢰할 수 있는 테스터 사용자 그룹이라는 용어는 혼란스럽다."항상 새로운 실험 기능을 사용할 수 있는 옵션"을 갖는 것에 동의하며, 새로운 MediaWiki 사용자 권한 그룹을 추가하는 것에 동의하지 않는다. --NaBUru38 (talk) 22:03, 2014년 10월 25일 (UTC)[응답]
"모든 새로운 베타 기능을 자동으로 활성화" 확인란이 이미 존재한다는 것을 알고 있으십니까?베타 기능 탭 맨 위에 있어. — HHHIPO 15:19, 2014년 10월 26일 (UTC)[응답]

템플릿 네임스페이스의 바로 가기 T

이전 RFC에서 T: for Template: 네임스페이스와 같은 "pseudo-namespace 단축키"를 사용하는 것에 대한 거부감이 있었음을 알 수 있다.RFC 전체를 읽지는 않았지만 템플릿을 찾고 싶을 때마다 검색 상자에 "템플릿:"를 입력하는 것이 지겹다는 것을 알고 있다.T라는 네임 스페이스가 미사용인데 왜 이걸 구현할 수 있는 곳에 변화가 없을까.댓글?~테크노팬트 (대화) 03:35, 2014년 10월 20일 (UTC)[응답]

추가 읽기 자료: 위키백과:다년생 제안#다양한 네임스페이스에 대한 바로 가기 네임스페이스 별칭 만들기이미 반복적으로 거부된 것에 대해 재제안을 할 때, 당신은 정말로 이전에 거부된 이유를 다루어야 한다.아노미야 10:38, 2014년 10월 20일 (UTC)[응답]

더 좋은 생각

검색 상자를 변경하여 {{infobox}}을(를) 입력하면 검색 상자가 Template을 제안할 수 있을 만큼 충분히 스마트하도록 변경하는 방법:인포박스?그것은 @Technophant:'의 문제를 다룰 것이다. 그들은 위키코드에서 복사해서 붙여넣기만 하면 된다.오이야르밥시 (대화) 01:03, 2014년 10월 23일 (UTC)[응답]

매개변수로 포함/전송할 페이지를 줄이는 것은 어떨까?없는 경우 추가 컴퓨팅 없이 렌더링할 수 있다. --NaBUru38 (대화) 22:09, 2014년 10월 25일 (UTC)[응답]
그게 어떻게 도움이 될지 잘 모르겠어.오이야르밥시 (대화) 21:05, 2014년 10월 28일 (UTC)[응답]

RfA 종료와 관련이 없는 것

이 문제를 제기하기에 더 좋은 장소는 위키백과일 것이다.위키프로젝트 풋볼. --Jayron32 01:14, 2014년 10월 30일 (UTC)[응답]

그리고 난 방금 그걸 그쪽으로 옮겼어 - 위키백과 대화:위키프로젝트 풋볼#플레이어 페이지의 팀 분할.오이야르밥시 (대화) 06:20, 2014년 10월 30일 (UTC)[응답하라]

워치/무시 토크 페이지 스레드가 있는 워치리스트

IEG 제안으로, 나는 당신이 대화 페이지의 스레드를 보거나 무시할 수 있는 사용자 스크립트를 만들 것을 제안했다.이 스크립트로, 토크 페이지의 경우, 당신의 워치리스트는 당신이 보기로 선택한 스레드만 보여줄 것이다.또는 무시하고자 하는 것을 제외한 모든 스레드가 표시된다.또한, 이 스크립트는 다른 위키백과 프로젝트와 언어에 대한 감시 목록의 항목을 표시할 수 있도록 허용한다.이 기능이 실행되도록 하려면 IEG 페이지로 이동하여 지원을 표시하십시오(말).— 마킨 (대화) 23:52, 2014년 10월 30일 (UTC)[응답]

삭제된 파일에 대한 공용 관리자/OTRS 액세스 권한?옵트 아웃?

안녕. VPT에서는 대부분 무시되는 것 같은데, RfC에 있는 사람이 놓기에 좋지 않다고 하니까, 나도 여기에 링크를 걸어놓을게: m:Requests/Global file deletion review.πr2 (t • c) 00:51, 2014년 10월 31일 (UTC)[응답]

"특수 대화:" 네임스페이스 만들기

스페셜 페이지를 어디서 논의해야 할지 분명하지 않지만, 이 페이지를 위한 전형적인 장소는 위키백과인 것 같다.대화:특수:반면에, 때때로 그들은 도움의 손길을 받는다.대화:특수:Foo, 그래서 일관성이 없어.내가 보기에, 이것은 대신에 특별한 대화여야 한다.Foo, and Special:Foo는 다른 페이지와 마찬가지로 토론 탭이 있어야 한다.이것은 사람들이 실제로 찾을 수 있는 특별한 페이지를 토론할 수 있는 자리를 제공할 것이다.오이야르밥시(토크) 18:48, 2014년 10월 18일 (UTC)[응답]

참고: 위키백과 대화를 참조하십시오.신속한 삭제 기준#"특수 대화:"R2" 기준을 업데이트하기 위한 제안은 이를 촉발한 논의를 위해 리디렉션된다.스틸1943 (토크) 18:52, 2014년 10월 18일 (UTC)[답글]
  • Steel과 관련된 다른 토론에서 제 코멘트는 "특별한 대화:"를 위한 NSA를 만들어 "위키피디아 토크:특수:"는 꽤 쉽다.특수 페이지에서 "토론 탭"을 얻는 것은 내가 이해하기로는, (항상 그렇지 않은) 특수 페이지가 일반 네임스페이스의 일반 페이지가 아니기 때문에(NS 번호 -1) 대부분의 특수 페이지에 "토론 탭"을 시뮬레이션하는 가젯이 만들어질 수 있다고(몇 개의 w가 있다) 핵심에서 하기가 더 어려울 것이다.여기서 .js는 보안상의 이유로 실행되지 않을 것이다.— {{U 기술 13} 21:41, 2014년 10월 18일 (UTC)[응답]
현재 논의와 더 이상 관련이 없지만 역사적 목적을 위해 여기에 보관된 삼진 텍스트.스틸1943 (토크) 15:31, 2014년 10월 22일 (UTC)[답글]
매우 오래된 이 버그 보고서[2]의 Special_talk.php가 여전히 진행 중인 문제일까?이것은 위키피디아에서 언급되었다.마을 펌프(기술)/Archive_61#특수 대화 활성화.php.jni 20:33, 2014년 10월 20일(UTC)[응답]
  • 이것이 RfC가 되기 전에 아래 논의에서 말했듯이: "Special:"은 기술적 네임스페이스로, 기술 솔루션을 만드는 것이 (이 RfC가 시작되지 않았더라면 1주일 내에 구현될 수 있었을 것이기 때문에 나는 확신하지만, 이제 이 예외를 추가한 다음 그것을 시행하는 것보다 더 쉬울 것이다.)따라서, 나는 NSA가[disambiguation needed] 훨씬 더 좋은 일을 할 수 있는 CNR을 만드는 것에 반대한다.대체 제안이 정확히 무엇인지 명확하지 않을 수 있는 경우:실제 네임스페이스 별칭을 만들어 "프로젝트 토크:특별:" "특별한 대화:"가 "위키피디아 토크:"와 "WT:"와 같은 네임스페이스에 주어질 때, 두 사람 모두 우리를 "프로젝트 토크:"로 데려간다.이렇게 하는 것은 리디렉션은 전혀 개입되지 않을 것이며, 이와 함께 오는 어떤 번거로움이나 문제들도 없을 것이라는 것을 의미한다.

"특수 대화:" 네임스페이스 생성 지원

  1. 제안자로서.— {{U 기술 13} 14:56, 2014년 10월 22일 (UTC)[응답]
    위와 같이 지원하라. 스틸1943 (토크) 15:22, 2014년 10월 22일 (UTC) 나는 이것을 가명보다는 실제 기능적 네임스페이스로 보고 싶다.나는 왜 이 토론이 그렇게 재구성되어야만 했는지 모르겠다.이제 실제 기능적 네임스페이스와 가명 사이의 미세한 선이 완전히 흐려졌다.스틸1943 (토크) 2014년 10월 22일 (UTC) 19:51 [응답]
    • @기술 13: 어떻게 작동하는지 알게 되고, 여전히 실제 네임스페이스에 대한 선호도가 있다.'NSA'는 할 수 없는 경우에 내 선택이지만, 확실히 내 첫 번째 선택은 아니다.스틸1943 (토크) 21:23, 2014년 10월 22일 (UTC)[응답]
  2. SupportOiyarbepsy (talk) 00:45, 2014년 10월 23일 (UTC)[응답]
  3. 지원 --Fauzan✆ talk✉ mail 05:11, 2014년 10월 23일 (UTC)[응답]
  4. 지원 2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (대화) 13:38, 2014년 11월 1일 (UTC)[응답]

"특수 대화:" 네임스페이스 생성 반대

  • 기본적으로 쓸모없는 것으로 반대하라.감시 목록에 특수 페이지를 추가할 수 없으므로, 다른 사람이 사용자의 의견을 볼 가능성을 심각하게 줄인다.특별한 페이지에 대한 코멘트는 VPT나 이와 비슷한 것으로 갈 수 있는데, 그들은 보통 훨씬 더 많은 관심을 받게 될 것이다.프람 (대화) 09:32, 2014년 10월 28일 (UTC)[응답]

"특수 대화:" 네임스페이스 생성에 대한 토론

  • 이 토론이 마무리될수록 이러한 변화에 대한 합의가 이루어진다면, 2005년 이후로 이 문제에 대해 존재해 온 연장을 가능하게 하는 데 필요한 새 티켓을 기꺼이 열 것이다(Phabricator:T6078. 고마워.— {{U 기술 13}} 17:43, 2014년 12월 9일 (UTC)[응답]

대체 제안 1: "특수 대화:" 리디렉션에 대한 빠른 삭제 R2 기준을 예외로 업데이트

R2 기준의 문구를 해당 기준의 예외로서 마지막에 이 문구를 포함하도록 업데이트할 것을 제안한다.

...그리고 "특별한 대화:"위키피디아 토크:" 또는 "헬프 토크:" 네임스페이스를 대상으로 하는 Foo".

'특별한 대화:' 네임스페이스는 존재하지 않으며, '특별한 대화:' 네임스페이스에서 도구 뒤에 숨겨진 기능에 대해 토론하고 싶었지만 토론 페이지를 찾을 수 없는 상황을 여러 번 발견했기 때문에 제안하는 것이다.나는 최근에 이 토크 페이지의 명명 규칙이 "위키피디아 토크:특수:Foo". 토크 페이지는 존재하지 않는 "특수 대화:" 네임스페이스에 있는 것이 타당하지만, 네임스페이스가 존재하지 않기 때문에 네임스페이스에 페이지를 만들면 기본 네임스페이스로 기본 설정되므로 "특수 대화:" 제목이 리디렉션되면 현재 이 기준에 따라 신속하게 삭제할 수 있다.스틸1943 (토크) 16:49, 2014년 10월 18일 (UTC)[응답]

R2 기준의 문구를 업데이트하여 CNR에 대한 예외를 "특수 대화:"에서 "위키피디아 대화:특수:"

스틸1943을 제안자로 가정하면 위 절에서 설명한 대로 네임스페이스가 전체적으로 생성되는 것을 보고 싶다.스틸1943 (토크) 15:22, 2014년 10월 22일 (UTC)[응답]
  1. 아래 토의에 따르면, Thryduulf라고 가정한다.

"특수 대화:"에서 "위키피디아 대화:"로 CNR에 대한 예외를 추가하기 위해 R2 기준의 문구를 업데이트하는 것에 반대한다.특수:"

  1. CNR로 만드는 것을 반대한다.다른 제안을 참조하십시오.— {{U 기술 13} 14:56, 2014년 10월 22일 (UTC)[응답]
  2. Jni라고 가정하면, 아래 토의에 따르면.
  3. 아래 토의에 따르면 Oiyarbepsy로 가정한다.

R2 기준의 문구에 대한 논의는 "특수 대화:"에서 "위키피디아 대화:"로 CNR에 대한 예외를 추가한다.특수:"

  • 맞아, 그래서 예외로 하자고 제안하는 거야그리고 이것이 사이비 네임스페이스인 것에 대해서는, 만약 그렇다면, 본질적으로 "위키피디아 토크:Special:"는 실제 네임스페이스의 유사 네임스페이스다.이러한 리디렉션들이 현재 존재하지 않는다는 사실은 본질적으로 해롭다.내가 보는 다른 유일한 옵션은 "특별한 대화:" 네임스페이스를 실제로 만들자는 제안이다. (영어 위키백과에 구축된 Wikimedia 소프트웨어의 실제 기능에 대한 업데이트가 필요하지 않기 때문에 나는 먼저 이 루트를 시도하고 있다.스틸1943 (토크) 2014년 10월 18일 (UTC) 18:11, 응답
    • 차라리 NSA로 이행하는 게 낫겠어이것은 네임스페이스를 만들 필요가 없는 기술 솔루션이다(내가 이해하기로는 실제로 존재할 수 없다).모든 드라마를 방지한다.@Steven (WMF): 개발자들로부터 입력을 좀 받을 수 있을까?나는 잭맥반이 이것을 게릿(혹은 우리가 지금 그것을 사용하고 있다면 phab)에 병합하기 위해 올릴 수 있을 것이라고 확신한다.:) — {{U 기술 13} 19:59, 2014년 10월 18일 (UTC)[응답]

나는 일시적으로 괜찮지만, 장기적으로 반대한다. 왜냐하면 이 예외는 해킹이기 때문이다.진정한 해결책은 아마도 존재해야 할 특별 토크 네임스페이스다.내가 빌리지 펌프 테크니컬에서 얘기하지.오이야르밥시(토크) 18:43, 2014년 10월 18일 (UTC)[응답]

위키백과:마을 펌프(기술)#특별한 대화 네임스페이스.오이야르밥시(토크) 18:48, 2014년 10월 18일 (UTC)[응답]
@Oiyarbepsy: 본질적으로, 나는 당신의 추리에 동의한다.고마워!스틸1943 (토크) 18:50, 2014년 10월 18일 (UTC)[응답]
나는 R2에 대한 예외는 "승인된 사이비 네임스페이스 이외의 것"의 선에 따른 것이어야 하며, 진정한 네임스페이스는 언급하지 말아야 한다고 생각한다. 동시에, 우리는 CAT:, H:, MOS:, 특별 토크: 등을 승인한다.이와 같은 주제에 대한 후속 논의는 WT로 넘어가게 된다.지름길.עוד מישהו Od Mishehu 19:46, 18 October 2014 (UTC)[reply]
  • 이 예외를 지원하십시오.그러한 리디렉션은 여전히 RfD에서 지명될 수 있으며, 그것이 하는(또는 하지 않는) 어떤 위해와 균형을 이루며 그들의 개별적인 장점(또는 장점 부족)에 대해 논의할 수 있다.많은 CNR이 해롭다고 해서 모든 CNR이 다 해롭거나 CNR이 되는 것 자체가 해롭다는 뜻은 아니다(애초에 예외를 둘 필요가 있다는 것을 강조함).Thryduulf (대화) 2014년 10월 19일 01:15 (UTC)[응답하라]
  • 이 예외에 반대하십시오.이것은 단지 WP일 뿐이다.BURO 룰 크리프.실전에 필요 없다.우리가 네임스페이스(정확한 해결책)라는 특별한 대화를 기다린다면 아무런 해가 되지 않는다.모든 관리자는 이미 "위키피디아 토크:특수:Foo" 토크 페이지 때문에 리디렉션 포인터를 신속하게 삭제할 필요가 있는 경우 즉석에서 현명한 결정을 내릴 수 있다.최근 Template_talk:Db-r2에서 R2 경고 템플릿은 CSD 정책 자체와 비교했을 때 네임스페이스 적용성 지침이 일관되지 않았으며, 아무도 눈치채거나 신경 쓰지 않는다는 사실이 언급되었다.wiki 편집 도구의 모든 한계 사용 사례에 대한 세부 규칙과 예외를 발명하기 시작하면 그와 같은 불일치가 더 많아질 것이다.jni 10:45, 2014년 10월 19일 (UTC)[응답]
  • 이 가르침은 어떤가?이 제안의 기본은 "특수:" 네임스페이스의 페이지 토론을 위한 토크 페이지를 목표로 하는 리디렉션의 작성의 유용성이다.현재, "특별한 대화:(확실히 공천에서 내 진술로 볼 때) 존재하는 Foo".또한, 관리자들이 실제로 "위키피디아 토크:Special:" 제목(여러 관리자가 표준 이름 지정 관행에 대해 알지 못한다고 확신함), "Special:" 네임스페이스에서 페이지를 토론해야 할 모든 편집자가 이러한 페이지를 쉽게 찾을 수 있어야 한다.하지만, 나는 "특별한 대화:" 네임스페이스의 창조를 보는 것이 낫다는 것에 동의한다. 그러나 위에서 언급했듯이, "특별한 대화:" 네임스페이스가 영어 위키피디아에 어떻게 프로그램되어 있기 때문에 기술적으로 불가능할 가능성이 있다.스틸1943 (토크) 16:40, 2014년 10월 20일 (UTC)[응답]
  • 나는 그것이 사실 명령의 소름끼치는 것이라는 것에 동의한다.훨씬 간단한 기술적 접근이 있을 때 위키에서 일어나는 일과 그렇지 않은 일을 절제하는 사회적 방법에 표현을 도입하려는 시도다.나는 NSA를 여기에 추가하는 것에 반대하지 않는다고 보고, 만약 그것이 단순한 기술적 해결책의 반대 없이 남아 있다면 내일 오후 (이 게시물로부터 약 28시간)에 그것을 추가하도록 요청할 것이다.기술적인 해결책은 그것을 정책에 추가하는 것을 불필요하고 무질서하게 만든다.— {{U 기술 13}} 17:01, 2014년 10월 20일 (UTC)[응답]
  • 기술적 해결이 불가능하다면 반드시 명령 크리프가 아니다.스틸1943 (대화) 2014년 10월 20일 (UTC) 17:12, 응답
  • 기술적 해결이 불가능한 경우, 기술적 해결이 가능할 뿐만 아니라 기존의 사회적 제재에 변화를 주려는 것보다 더 쉽다고 확신한다.당신의 if 조항이 거짓이기 때문에, 그 조항이 정말로 명령 크리프라고 보는 것이 타당하다.나는 "특별한 대화:"가 사용자를 "특별한 대화:" 페이지에 대해 이야기할 수 있는 대화 공간으로 데려가서는 안 되는 사용 사례를 볼 수 없다("위키피디아 대화:특수:"Special:Foo" 여기서 "위키피디아:특수:Foo"는 아직 존재하지 않는다.생각지도 못했던 사건들을 환영해 만약 있다면 말이야:) — {{U 기술 13} 18:45, 2014년 10월 20일 (UTC)[응답]
  • 정확히 7페이지가 존재했기 때문에 명령 소름끼치는 것이다. (적어도 마지막으로 삭제된 개정판이 데이터베이스에서 삭제된 후 - 그리고 마지막으로 일어난 일은 거의 10년 전에 여기서 관리자로 임명되기 전이었다!)도움말 대화 네임스페이스를 대상으로 하는 접두사 "특수 대화:"가 있는 리디렉션은 존재하지 않는다.삭제된 페이지 중 3개는 전혀 리디렉션되지 않았으며 G2(또는 그것에 가까운) 사유에 따라 삭제되었다.자세한 내용은 사용자:Jni/Special talk는 이 토론에 참여하는 비관리자의 이익을 위해 검토를 리디렉션한다.4개의 리디렉션 중 일부는 여러 번 삭제됐으며, 2개의 삭제는 특정 기준을 언급하지 않은 채 진행됐으며, R2는 2번, G6는 3번 이유로 제시됐다.G6의 중요성에 주목하십시오. R2 대신 R2를 사용하여 의사 네임스페이스와 관련된 이런 종류의 이상한 유물을 직접 삭제하십시오.당신의 제안은 G6의 적용 가능성을 조용히 제한하는 것 같아, 이미 복잡하고 다소 자의적인 CSD 규칙 집합을 기억하거나 정확하게 적용하기가 더욱 어려워진다.이 문제에 대해 정말로 약간의 오해가 있었다 - 특별 대화를 위한 로그를 보라:Rossami가 순환논론을 하는 곳인 Cite는 관리자의 복원도구의 잘못된 사용(2007년 현재와 동일하다고 가정)도 이후의 G6 CSD도 무효화한다고 주장한다.전반적으로, 지난 10년 동안 단 4개만 만들어졌기 때문에 이러한 종류의 리디렉션은 필요하지 않았다.거의 존재하지 않는 것이 있다면, 삭제하기 위해 특별한 규칙을 만들 필요가 없다!jni 19:04, 2014년 10월 20일 (UTC)[응답]
  • Rossami의 주장은 순환적이지 않고 실제로 신속한 삭제의 핵심이다. 만약 그것이 논란이 된다면, 그것은 빨리 삭제되어서는 안 된다.오이야르밥시(토크) 19:34, 2014년 10월 20일 (UTC)[응답하라]
  • Oiyarbepsy, 나는 그의 주장을 순환("거짓말"이 더 좋았을 것"이라고 말했다. 왜냐하면 두 삭제자 사이에는 5년의 공백이 있었기 때문이다.만약 있다면, 그 논쟁은 그렇게 길고 늦은 날 동안 지속될 수 없으며, 행정가들은 새로운 시각을 가질 수 있고 그들의 동료들의 아주 오래된 행동들에 얽매이지 않는다.게다가, 정말로 상세한 분석은 삭제 정책, CSD 규칙, 그리고 기록되지 않은 규약을 로그의 각 이벤트에서와 마찬가지로 이해해야 할 것이다.jni 19:53, 2014년 10월 20일 (UTC)[응답]
  • 로사미가 ~ 7년 전에 했던 여러 가지 신속한 복원(우리 모두는 이와 같은 중요한 조사를 수시로 하고 있다, 그렇지?)을 자세히 살펴본 결과, 당시 논란이 됐던 문제가 결국 RfD에 안착되어 "특별한 대화:Foo" 리디렉션은 필요하지 않다.이제 이 이전의 합의를 무시하는 것이 제안되었지만, CSD R2에 대한 이 토크 페이지나 예외는 과연 이것을 위한 적절한 포럼이나 메커니즘일까?jni 19:50, 2014년 10월 20일 (UTC)[응답하라]
  • (편집 갈등) @Jni: 위에서 보지 못했으니, "특수 대화:" 타이틀의 유용성(또는 그 결여)을 간주하는 (어떠한 방법으로) 합의가 성립된 RfD 토론에 연계를 제공할 수 있겠는가?(과거에 바로 이 문제에 대해 어떤 형태의 합의도 성립되지 않았다는 것을 전혀 몰랐다는 점에서, 나는, 다소나마 그것을 보는 것이 상당히 궁금하다.지금 이 일로 내 의견이 바뀐다는 말은 결코 아니다.)스틸1943 (토크)20:10, 2014년 10월 20일 (UTC)[응답]
그런데, 이것이 이 토론에 적합한 포럼인가에 대한 당신의 질문은, 이 토론이 단순히 R2 기준에 예외를 추가하려는 것 이상의 것으로 변했다는 점에서, 이 토론은 "특별한 대화" 네임스페이스(또는 사이비 네임스페이스)에 대한 논의로 바뀌고 있다는 사실 또한 궁금하다.기술 13이 위에서 배제한 것처럼 네임스페이스 별칭이 존재해야 한다.만약 이 토론이 예전처럼 계속된다면, 나는 전체 토론은 옮겨져야 할 필요가 있다고 생각하고, 만약 그것이 지난 하루 동안 했던 것만큼 계속해서 탄력을 받는다면 RFC로 전환될 수도 있다고 생각한다.스틸1943 (토크)20:24, 2014년 10월 20일 (UTC)[답글]
  • 나는 그것이 PNR이 되어야 한다고 말한 적이 없으며, PNR이 되는 것에 반대할 것이다.내가 여러 번 말한 것은 NSA가 되어야 한다는 것이다.사이비 페이지 이름은 크로스 네임스페이스 리디렉션과 바로 가기의 대소문자를 구분하는 조합이다. 네임스페이스 별칭은 WP, WT 또는 이미지와 마찬가지로 실제 대소문자를 구분하지 않는 가상 네임스페이스다.— {{U 기술 13} 21:01, 2014년 10월 20일 (UTC)[응답]

그 7페이지에 대한 삭제 로그를 보면, 우리가 특별한 대화가 필요하다는 생각에 상당히 힘을 보태고 있다.거의 모든 것이 해당 위키백과 대화 페이지로 리디렉션되거나 대화 페이지에서 볼 수 있을 것으로 예상되는 자료 유형이었습니다.이 페이지들이 매우 드물다는 것은 특별한 페이지들이 어떤 토크 페이지도 연결하지 않기 때문에 대다수의 사용자들이 그냥 길을 잃고 토론하는 것을 포기하기 때문이다.다른 이들은 특별한 대화를 추측하고 댓글을 달거나 리디렉션을 한다.오이야르밥시 (대화)20:02, 2014년 10월 20일 (UTC)[응답]

기록 보기 이름 바꾸기

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

위키피디아는 성별에 치우친 것으로 비난을 받아왔다.모든 글의 맨 위에 있는 "역사 보기"의 이름을 "과거 편집"과 같은 다른 것으로 바꾸면, 위키피디아는 더 성중립적이고 여성들을 환영할 수 있을 것이다.이 작은 변화는 내 생각에 큰 긍정적인 영향을 미칠 것이다.감사합니다.브라이언 에버레스팅 (토크)20:13, 2014년 11월 1일 (UTC)[응답]

@Brian Everstance:그게 성 편견과 무슨 상관이야?잭mcbarn (대화)20:15, 2014년 11월 1일 (UTC)[응답]
어떤 사람들은 "역사"와 "그의 이야기"를 혼동한다.브라이언 에버레스팅 (토크)20:17, 2014년 11월 1일 (UTC)[응답]
진짜야?--BabbaQ (대화)20:22, 2014년 11월 1일 (UTC)[응답]
응, 나 진지해.브라이언 에버레스팅 (토크)20:23, 2014년 11월 1일 (UTC)[응답]
"역사"가 "그의 이야기"와 혼동된다고 불평할 수 있는 사람들은 직업을 가질 필요가 있다.아니면 취미. --BabbaQ (토크) 20:24, 2014년 11월 1일 (UTC)[응답]
"역사" = "그의 이야기" ㅋㅋㅋㅋ! 그런 말은 처음 들어봤어. --Obsidi (토크) 20:32, 2014년 11월 1일 (UTC)[응답]
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 20:38, 2014년 11월 1일 (UTC)[응답]
Brian Everstasting 또한 많은 "History" 섹션 제목을 "Background"로 바꾸고 있다.나는 지금 시간이 없지만 누군가가 이 말도 안 되는 것을 보고 싶어 할지도 모른다.프라임헌터 (대화)20:39, 2014년 11월 1일 (UTC)[응답]
Brian Everlasting, 제발 합의 없이 이런 종류의 것들을 바꾸지 말아줘.좀 우스꽝스러워진다.--BabbaQ (대화) 20:41, 2014년 11월 1일 (UTC)[응답]
완전히 주제에서 벗어난, 한마디로 성차별을 보는 사람들을 위한 해결책은 그것을 우리의 이야기로 대체하는 것이다.오이야르밥시 (대화) 20:37, 2014년 11월 1일 (UTC)[응답]

과거 편집으로 바꾸는 것은 단순히 그것이 무엇인지 더 명확하기 때문에 좋을 것이다.미국과 같은 기사에서, 어떤 사람들은 그 버튼이 미국의 역사로 이어진다고 생각할지도 모른다. 왜냐하면 그것이 그렇게 들리기 때문이다.과거의 편집은 그것이 진짜 무엇인지 더 명확하게 설명해준다.오이야르밥시 (대화)20:42, 2014년 11월 1일 (UTC)[응답]

실제로 이런 일이 일어난 것일까, 아니면 누군가 생각할 수 있는 것을 추측하고 있는 것일까?위키피디아가 그렇게 항해한다고 생각하는 사람은 없을 것 같다.0x0077BE [/]talkcontrib 21:29, 2014년 11월 1일(UTC)[응답]

뭐라고? 나는 완전히 무뚝뚝한 표현을 자주 쓰지는 않지만, 이것은 완전히 터무니없는 제안이다. (그리고, 그렇다, 나는 "역사"와 "그의 이야기" 농담을 들은 적이 있다.)그러나 진지하게, 언제부터 사람들이 실제로 "역사"와 "그의 이야기"를 혼동하는 것일까? --비블리오름 21:21, 2014년 11월 1일 (UTC)[응답]

아니면 그것을 '역사'와 '허스토리'로 구분할 수도 있다.그리고 나서 다른 성 정체성의 이름을 알아내라.그런 다음 인종/민족/민족 분열을 연구하십시오.이게 11월의 만우절인가?(6개월 휴무). -- Gadget850 talk 21:25, 2014년 11월 1일 (UTC)[응답]
성별에 구애되지 않는 것은 무엇인가?우리는 이미 누군가가 그들의 공공적인 성 정체성을 바꾸고 싶다고 결정할 때, 우리는 즉시 기사의 이름을 바꾸고 모든 대명사를 바꾸어야 한다고 주장하는 편집자들이 있다. 심지어 과거 몇 년간에 대한 부분에서도, "그녀는 올보이스 스쿨을 다녔다"거나 "그가 첫 아이를 낳았다"고 말할 정도로 말이다.하지만 최근에 나는 이 편집자들 중 한 명이 우리가 누군가의 옛 이름에서 그들의 새 이름을 사용하여 기사로의 방향을 바꾸었다고 불평하는 것을 보았다.아노미슈 01:16, 2014년 11월 2일 (UTC)[응답]
  • 음...정말 재미있군...나는 "역사관"이 형편없는 레이블이라는 것에 동의한다.위키백과의 페이지 역사를 의미하고 주제의 역사를 보지 않는 것을 의미하는 것이 분명한 "페이지 역사"를 선호한다(나는 이것과 저 부분에 대해 많은 "비 위키피디아인"과 이야기를 나누었다).성별에 치우친 헛소리는, 그냥, 헛소리는...— {{U 기술 13}} 01:44, 2014년 11월 2일 (UTC)[응답]
나는 분명히 "역사 보기"가 오이야르 엡시 당 너무 모호하다고 생각한다; 우리는 이것이 그 페이지의 역사 또는 오래된 버전이라는 어떤 암시를 가지고 갈 수 있다.하지만 나는 여기서 성별에 대한 클레임을 믿지 않는다.עוד מישהו Od Mishehu 04:30, 2 November 2014 (UTC)[reply]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

"공지 거주자"

나는 어떤 기사에서든 "공지할 수 있는 거주자"(또는 이와 비슷한 사람)로 등재된 사람은 그 사람이 자신의 이름을 딴 기사를 가지고 있지 않는 한 그 기사에서 삭제해야 한다고 제안한다.명분도 없이 많은 기사에서 거론되는 이런 '명성 있는 주민'이 너무 많다.만약 그들에게 이름을 붙인 기사가 없다면, 그들은 눈에 띄지 않고 따라서 "유명 거주자"가 아니다.조도스마 (대화) 2014년 10월 14일 (UTC) 19:27 [응답]

나는 제3자 정보원이 개인을 공신력 지표로 논하는 것은 순응할 수 있지만, 기사나 소싱이 없다면 왜 그들이 상장될지는 상상할 수 없다.돈이야고 (대화) 2014년 10월 14일 (UTC) 19:36 [응답]
위키백과 전체 개인은 마치 "알 수 없는" 것처럼 언급되는데, 예를 들어, 대학이나 학교나 소기관(의회 등)에 관한 기사에서는, 종종 그 글에 "알 수 없는" 것으로 기재된 많은 경우에서, 마치 그들이 주목할 만한 사람이라는 진술이 그들을 알 수 없게 만드는 것처럼, 그 기사에서는 "알 수 없는 사람"으로 언급된다.blee. 만약 그들이 이름을 붙인 기사가 없다면 나는 이것들을 모두 제거하고 싶다.이 사람들의 이름이 정해지면, 이름을 짓는 사람이 먼저 그들에 대한 기사를 작성해야 한다.이런 일은 기업이나 기업에 관한 많은 기사에서도 일어나는데, 명분도 없다.조도스마(토크) 19:57, 2014년 10월 14일 (UTC)[응답]
제3자 추천서와 함께 눈에 띄는 거주자가 없는 경우라도 괜찮다고 생각한다.이러한 종류의 진입은 WP와 일치한다.REDLINK, 백과사전의 확대.브링크스터넷 (대화) 22:13, 2014년 10월 14일 (UTC)[응답]
나는 Binksternet의 의견에 동의한다.우리는 WP에게 다음과 같이 말하지 않는다.다른 기사를 약간 개선할 수 있도록 허용될 기사를 먼저 작성해야 하는 자원 봉사자들.WP에 대한 정의:주목할 만한 것은 틀렸다: 어떤 사람이 영어 위키백과에 대한 별도의 기사의 자격을 얻을 때 주목할 만하다.누군가가 실제로 기사를 쓰기 시작하기 전에 당신은 수십 년 동안 주목할 수 있다.
이러한 항목에 대한 출처가 없으면 직접 찾으십시오.그렇게 많은 노력을 할 의향이 없다면 {{fact}} 태그를 추가하고, 몇 달 후(예, 며칠이 아니라 몇 달 후) 다시 확인하여 누군가가 그렇게 했는지 확인한다.마음에 들지 않고 그 안의 가치를 볼 수 없다고 해서 그냥 비워두지 마라.WhatamIdoing (대화) 22:19, 2014년 10월 14일 (UTC)[응답]
만약 빨간 고리가 분명히 기사를 쓸 만한 가치가 있다면 그들을 떠난다.대부분의 경우 그들은 그곳에서 제거되지 않고 그리고 나서 제거되어야 한다.찰스 (토크) 22:26, 2014년 10월 14일 (UTC)[응답]
설명: 글의 빨간색 링크는 링크 목록에 있는 링크와 다르다.기사 속의 것들은 아마도 언젠가 확장될 기회를 가질 것이다, 아마도 처음에 그것을 거기에 놓아둔 사람에 의해.그러나 목록은 다르다.어떤 이름이라도 결코 눈에 띄지 않거나, 실제로 태그/반달리즘에 해당되지 않는 목록에 추가될 수 있다(그리고 반복적으로 추가된다).목록에 있는 경우, 이름, 항목 또는 최소한 위키피디아에 기존 기사가 없는 경우 신뢰할 수 있는 출처 인용 부호가 필요하다.위키리스트의 빨간색 링크는 무의미하다.PS: "알 수 없는 주민" 섹션은, 이미, 목록 섹션이다.GenQuest"Talk to Me" 23:30, 2014년 10월 14일 (UTC)[응답]
Notability 표준은 기사 작성에만 적용된다.기사에 정보를 포함시키는 기준은 훨씬 낮다.알제 (대화) 2014년 10월 16일 (UTC) 10시 32분 답변
반면에, 이러한 부가물들 중 많은 것들이 아마도 살아 있는 사람들일 것이다.내 생각엔 그들은 누군가의 남자친구, 개, 최악의 적이 될 수도 있기 때문에 나는 말한다.출처가 없는 경우, 우리는 단지 알 수 없으며, 그러한 항목은 WP일 수 있다.단순히 홍보만 하는 것이 아니라면 BLP 위반.사실 태그는 BLP 위반을 방지하기에 충분하지 않다.더그웰러(대화) 2014년 10월 16일(UTC) 16시 10분 [응답]
나는 그것들이 본질적으로 목록이라는 것에 동의한다. 위키피디아에서는 그들이 무분별하게 되지 않도록 포함 기준을 갖도록 권하고, 위키피디아의 모든 콘텐츠는 검증가능해야 한다.종종 리스트의 내용은 블러블링크를 통해 증명될 수 있기 때문에, 만약 이런 종류의 리스트의 항목이 재연결되거나 전혀 연결되지 않는다면, 그것은 아마도 검증할 수 없고 플래그가 붙어야 한다. 그러나 더그웰러는 그러한 리스트의 항목이 (확정된 사망자가 아닌 한 살아 있는) 살아있는 사람들에 대한 정보일 가능성이 충분하다는 것이 옳다.검증할 수 없는 경우 즉시 제거해야 한다.당신은 또한 그러한 리스트를 정리하기 위한 위키프로젝트 빨래방에 관심이 있을 것이다.이반벡터 (대화) 16:28, 2014년 10월 16일 (UTC)[응답]
만약 누군가가 목록에 연결되지 않은 이름을 넣고 싶다면, 왜 그 이름이 목록에 속하는지 보여주는 것이 그들에게 의무적이다.그렇지 않으면 OR이므로 즉시 제거해야 한다.리스트 포함은 위의 논평에 따라 기사의 포함과 다르다.GenQuest"Talk to Me" 01:20, 2014년 10월 17일 (UTC)[응답]
아니, 그건 OR이 아니야. "원래 연구"는 지구상의 어느 곳에서도, 언제 어디서든 출판된 적이 없는 자료를 포함한다."미등록"은 우리가 그 이름이 왜 목록에 속하는지 보여주지 않고 누군가가 추가한 자료라고 부르는 것이다.WhatamIdoing (talk) 19:31, 2014년 10월 17일 (UTC)[응답]
둘 다 적용되는 것처럼 위에 "미등록"도 포함했어야 했어.어느 경우든, 그러한 항목은 BLP에 따라 태그 지정이 필요 없이 즉시 제거될 수 있다.GenQuest 22:41, 2014년 10월 17일 (UTC)[응답]
위의 논의는 참조된 좋은 소스 문서에 "블로그, 스미스, 존스가 매우 중요한 일을 했다(X)"라고 되어 있지만, 블로그와 스미스만이 WP 기사를 가지고 있고, 그 외에는 그를 위한 WP 기사가 없을 정도로 유명하지 않았던 상황을 고려하지 않는 것으로 보인다.IMHO 그의 이름(레드링크 없이)은 Bloggs와 Smith(및 X가 있는 경우)의 기사에 속하며, 또한 X와 관련된 사람 또는 X와 관련된 직업군 등의 리스트에 (레퍼런스 없이) 속해 있다.다운사이즈43 (대화) 10:37, 2014년 10월 19일 (UTC)[응답]
나는 이런 경우에 그것은 기사에 속한다고 생각한다; 그것은 그 주제와 관련된 사람들의 목록에 속하지 않는다.기사 내용은 주목할 필요가 없다.그러한 목록에 있는 사람들을 위한 가장 좋은 규칙은 그들이 기사를 가지고 있어야 하거나 또는 명백히 그 기사에 대한 자격이 있어야 한다는 것이다. DGG (토크 ) 2014년 10월 20일 18:31 (UTC)[응답]
나는 "알리샤와 밥이 포함된 도시/마을 주민"이라는 용어를 삭제하고 그냥 쓰기를 제안한다. --NaBUru38 (대화) 22:05, 2014년 10월 25일 (UTC)[응답]
아니, 아니, 아니.그렇게 되면 위키피디아에 대해 들어본 적이 있는 자기 홍보 담당자들의 무작위 목록이 나오게 될 것이다.그것은 우리의 독자들에게 유용하지 않을 것이다.DGG가 옳다 - 목록에 있는 사람들은 현존하는 기사를 가지고 있거나 위키피디아의 의미에 있어서 그것을 증명할 수 있는 참고자료와 함께 명백하게 주목할 수 있어야 한다.존CD (토크) 11:14, 2014년 10월 30일 (UTC)[응답]
출연자 명단이 이런 것에 영향을 받을까?그리스 노예는 문제가 되지 않을 만큼 나이가 들었어야 하는 목록을 가지고 있다.좀 더 현대적인 연극은 주목할 만한 것과 그렇지 않은 것이 혼합되어 있을 것이다.이게 주제에서 벗어난 거라면 미안해.소발발토스 (토크) 2014년 10월 31일 (UTC) 19:10 [응답]
어떤 특징을 가진 사람들의 목록에 포함되려면, 그 사람이 그들 자신의 기사를 가지고 있는 것만으로는 충분하지 않다: 그들이 이런 특성을 가지고 있다는 것을 믿을 수 있게 구해야 한다.우리는 화성에서 온 사람들의 목록을 만들고 많은 유명한 이름들을 위해 파란색 링크를 추가할 수 있지만, 그렇다고 해서 그들이 이 목록에 오를 자격이 있다는 것을 의미하지는 않을 것이고, 그들 중 몇몇은 심지어 반대할 수도 있다. 노이스터(토크), 09:50, 2014년 11월 3일(UTC)[응답]
훌륭한 제안.그리고 동창회 리스트는 디토.알라하바드 대학은 현재 블루 링크가 있는데, 그 중 상당수는 실제로 참고자료와 함께 제공된다.페니실린(밴드)과 카다피스를 모두 좋아하는 사람이 페니실린과 싯다르스 법대와 함께 펌프질한 토카이대를 무연고 상태로 비교해 보라.그래, 레드 링크는 괜찮아.그러나 이 사람들이 눈에 띄면, 그들의 호감을 나타내는 문맥으로 그들을 다시 연결시켜라.거주지, 출생지 및 대학(졸업 또는 중퇴)은 지명도를 부여하지 않는다.물론 이 목록에 레드 링크를 추가하면 누군가에게 기사를 작성하도록 유도할 수 있다.그러나 만약 그렇다면, 더 적절하고 설득력 있는 것은 관련 토크 페이지 내의 단락일 것이다. -- 호리 (대화) 12:01, 2014년 11월 3일 (UTC)[응답]
WP의 지침:NLIST는 특히 유용하다. 예를 들어, 학교에 관한 기사는 종종 주목할 만한 동문/추천문 목록을 포함하거나 링크하지만, 그러한 목록에는 학교에 참석한 모든 사람들이 포함되도록 의도된 것은 아니다. 검증 가능한 유명인사와 많이 소외된 사람들만이 포함되도록 되어 있다. 더욱이, 그러한 목록의 모든 항목에는 다음 사항을 증명하는 신뢰할 수 있는 출처가 필요하다.그는 지명된 사람이 목록에 있는 그룹의 멤버라는 사실을 알고 있다.NebY (대화) 14:03, 2014년 11월 3일 (UTC)[응답]
사용자:NebY가 절대적으로 옳다 - 나는 모든 곳에 파란색 링크된 사람들의 이름, 믿을 만한 출처가 없는 특정 민족 등의 리스트나 섹션이 보인다.그리고 파란색 링크된 기사가 출처가 있는 것만으로는 충분하지 않으며, 출처가 목록이나 섹션에 있어야 한다.더그웰러 (대화) 15:32, 2014년 11월 3일 (UTC)[응답]

우리는 RfA를 교체해야 하는가?

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

현재의 RfC가 실패할 것이라는 예측이 다소 타당하기 때문에, 커뮤니티 구성원 대다수가 RfA를 교체할 필요가 있다고 생각하는지 아닌지를 결정하기 위해 별도의 논의를 하는 것이 좋을 것 같다.이 논의는 행정 선거 개혁을 위한 새로운 아이디어를 모으기 위한 것이 아니다.그것은 미래의 토론에서 일어날 수 있다.

만약 우리가 RfA를 대체할 새로운 시스템이 필요하다고 생각한다면,#'''Yes''' - (Your rationale here). RfA를 교체할 필요가 없다고 생각되는 경우,#'''No''' - (Your rationale here).입력해줘서 고마워. --Biblioworm 22:10, 2014년 11월 3일 (UTC)[응답하라]

언제부터 우리가 물건을 교체하는 거야?더 나아질 때까지 편집만 하면 돼.칠음 22:57, 2014년 11월 3일 (UTC)[응답]
RfC가 통과하지 못하면 지금 당장 다른 걸 갖는 거야?— xaosflux 23:04, 2014년 11월 3일(UTC)[응답]
이것은 페이지 위 RfC가 묻고 있는 것과 정확히 같은 질문이 아닌가?내 말은, 투표 옵션에는 "유지/해독" RfA가 있는데, 당신은 RfA를 "대체/대체하지 않는" RfA를 묻는 겁니다.뭐가 다르지?C628 (대화) 23:05, 2014년 11월 3일 (UTC)[응답]
그것은 같은 질문이 될 의도가 아니었다.위의 RfC는 지금 당장 RfA를 과거로 표시하고 즉시 새로운 시스템에 대한 작업을 시작할 것을 제안하고 있다.나는 지역사회가 RfA를 새로운 시스템으로 교체할 필요가 있다고 생각하는지 묻고 있다.내 생각에는 이것은 별개의 주제인데, 위에서 투표한 일부 사람들은 RfA를 교체해야 한다는 생각을 지지하지만, RfA를 즉시 없애야 한다는 의견과 새로운 시스템을 마련할 수 있는 방법을 찾기를 희망한다는 의견에는 찬성하지 않기 때문이다. --Biblioworm 23:13, 2014년 11월 3일 (UTC)
위에서 투표를 한 몇몇 사람들은 우리가 RfA를 대체해야 한다는 생각을 지지하기 때문에—이 RfC가 문제를 더 명확하게 해줄 수 있다는 것은 이해하지만, 나는 이 RfC가 엄격히 필요한지 확신할 수 없다.위의 RfC에서는 이미 이 정보를 이용할 수 있고, 새로운 아이디어에 대해 논의하려는 것이 아니기 때문에, 나는 궁극적으로 이것을 다시 반복해서 설명할 필요가 없다고 생각한다.많은 편집자들이 RfA에 대한 개선이 이미 충분히 입증되었다고 보고 싶어한다.I, JethroBT 23:21, 2014년 11월 3일 (UTC)[응답]
이것이 어떻게 별개지만 관련된 토론인지 알 수 있다.우리는 RfA가 고장 났다는 컨센서스를 전제로 마지막 (위) !RfC에 들어갔지만, 여러 편집자들이 여러 가지 이유로 고장 난 것이 아니라고 응답했다.하지만 당신이 제안하는 RfC는 WT에서 이미 일어나고 있다.RFA는 왜 새로운 논의를 여는 대신 논의를 통합하지 않는가?이반벡터 (대화) 23:24, 2014년 11월 3일 (UTC)[응답]
나는 WT에서의 토론에 대해 알지 못했다.RFA(내 감시자 명단에는 없다.)어쨌든 이건 중복토론이라는 것에 모두가 동의하는 것 같고, 그런 얘기를 반복해서 듣는 것은 목적이 없으니 그냥 닫아버리겠다. --Biblioworm 23:33, 2014년 11월 3일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

파일 클릭 결과

먼저, 미디어 뷰어 문제와는 완전히 별개라는 점에 유의하십시오. 미디어 뷰어가 사용되지 않을 때 발생하는 현상만 미디어 뷰어를 사용하지 않도록 설정했기 때문에 또는 새 탭에서 파일을 꺼냈기 때문에 해결한다는 점에 유의하십시오.

en 이외의 수많은 위키백과:무료 및 비무료 자료를 허용하며, 다른 많은 위키백과(예: es:)는 사람들이 로컬로 이미지를 업로드할 수 있도록 허용한다.예를 들어, fr:와 같이 두 가지 작업을 모두 수행하는 일부 작업자는 Commons 호스트 이미지를 클릭할 때 Commons 페이지로 직접 연결된다.예를 들어 fr:로 이동하십시오.오늘의 주요 기사의 주요 이미지를 클릭하면 https://fr.wikipedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg이 아닌 https://commons.wikimedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg에 접속할 수 있다.이것도 우리에게는 바람직하지 않을까?내 제안은 현지에서 호스팅되는 이미지에 영향을 미치지 않아야 한다.다시 fr: — fr:로 돌아가면:Liste des emissions de francais depuis 1960, 10프랑 마티외 바로 위에 있는 이미지를 선택하면, 당신은 https://fr.wikipedia.org/wiki/Fichier:10_francs_Mathieu_1987_F365-28_revers.jpg으로 바로 갈 것이다. 왜냐하면 https://fr.wikipedia.org/wiki/Fichier:10_francs_Mathieu_1987_F365-28_revers.jpg은 현지에서 주최하기 때문이다.

대부분의 경우 이미지 설명 및 이미지 토크 페이지 편집은 하원에서 진행해야 하며, 소수의 예외(예: 설명에 FP 및 표시-DYK 참고 사항 추가)는 파일 이름 앞에 en을 추가하는 등의 URL 변경으로 항상 할 수 있다.경험이 부족한 사용자들은 FP 통지 같은 것들을 어떻게 하는지 모를 것이다; 그들은 실제 설명을 편집하고 대화 페이지 코멘트를 하는 방법만 알게 될 것이기 때문에, 우리는 그들이 잘못된 코멘트를 추가하고 잘못된 파일 설명 페이지를 만드는 것을 더 어렵게 만들어야 한다.대부분의 파일 공지사항은 봇에 의해 이루어지기 때문에, 아마도 메모를 남기기 위해 봇에게 약간 다른 길을 따르라고 말하는 것은 그리 어렵지 않을 것이다.이렇게 함으로써, 우리는 경험이 풍부한 편집자들 조차도 훨씬 더 간단하게 만들 수 있다. (우리가 커먼즈 파일을 열 때마다 추가 링크를 클릭할 필요가 없을 것이다.) 그리고 경험이 없는 편집자들 조차도 훨씬 더 간단하게 만들 수 있다.나이튼드 (대화) 15:45, 2014년 11월 3일 (UTC)[응답]

  • 미안해, 니튼, 네가 항상 같은 일을 하기 때문에 (그것은 내가 항상 같은 일을 하기 때문에 더 쉽게 할 수 있도록) 어떤 생각을 빙빙 돌고 있는 것처럼 보여서 네가 하는 말을 따라가는 데 어려움을 겪고 있어.이미지가 en과 commons 모두에서 호스트되는 경우 소프트웨어가 로컬 복사본으로 기본 설정되어야 한다는 말씀이십니까?이 경우(왜 그렇지 않을지 알 수 없음), 파일: 페이지에는 공용 버전/페이지에도 링크가 있어야 한다.이 요약이 정확한가?— {{U 기술 13} 16:28, 2014년 11월 3일 (UTC)[응답]
  • 난 사실 그 아이디어에 대해 말하고 있지 않았다.이미지가 로컬에만 있는 경우 이미지를 클릭하면 로컬 이미지로 이동(지금처럼)이미지가 로컬 이미지와 Commons 둘 다인 경우 이미지를 클릭하면 로컬 이미지로 이동(지금처럼)된다.이미지가 Commons에만 있는 경우, 이미지를 클릭하면 fr:에서처럼 Commons로 직접 이동하지만, 지금 여기서 하는 것과는 다르다.나는 이것이 개발자들에게는 간단하지만 다른 모든 사람들에게는 불가능한 것이라고 믿는데, 이는 위키로 하여금 커먼스의 이미지를 사용하게끔 하는 설정에 비견된다.나이튼 (대화) 16:34, 2014년 11월 3일 (UTC)[응답]
    우리는 이미 "거기서 호스팅되는 파일에 대한 Commons에 대한 Redirect 이미지 링크"라는 가젯을 가지고 있는데, 이 가젯은 당신이 원하는 것을 하는 것처럼 보인다.잭mcbarn (대화) 16:59, 2014년 11월 3일 (UTC)[응답]
  • 그건 몰랐어.그러한 경우, 우리의 논의는 그러한 기기가 디폴트되어야 하는지에 초점을 맞추기만 하면 된다.나이튼드 (대화) 17:22, 2014년 11월 3일 (UTC)[응답]
  • 나도 그걸 몰랐어. 그리고 분명히 난 이미 그걸 할 수 있어.나는 아직 정확히 무엇을 해야 하는지 혹은 목표가 무엇인지 확실하지 않다.아마도 그 기계 작성자가 나를 위해 그것을 명확히 하는데 도움을 줄 수 있을 것이다.— {{U 기술 13}} 18:12, 2014년 11월 3일(UTC)[응답]
  • 기술 13, 현재 이미지가 Commons에서 호스팅되고 영어 위키백과 기사에 있는 경우 이미지를 클릭하면 en-wiki의 페이지로 이동하며, 여기서부터 Commons의 페이지를 클릭할 수 있다.이것은 실수로 하원에 도착하기를 원하지 않는 독자들의 혼란을 줄이기 위한 것으로 추측된다.니텐드는 이미 존재하는 것으로 보이는 커먼스의 페이지로 직접 갈 수 있는 옵션을 제안하고 있었다.샘 월튼 (대화) 2014년 11월 3일 (UTC) 18:21 [응답]
내가 가정된 이론에 동의하는지는 잘 모르겠지만 만약 우리가 (논쟁을 위해) 그것을 받아들인다면, 내가 최근에 발견한 그 기기는 로그인한 모든 편집자에게 디폴트 사용이 가능해야 한다.WhatamIdoing (대화) 22:08, 2014년 11월 3일 (UTC)[응답]

니튼드(Nyttend)에 동의하기 때문에 기본적으로 옵션을 활성화해야 한다고 생각한다. --NaBUru38(대화) 19:19, 2014년 11월 4일(UTC)[응답]

  • 동의해, 비록 내가 "사용 불가능"을 기본값으로 둔 이유를 존중하긴 하지만.최상의 선택:Rich Farmbrough, 23:57, 2014년 11월 11일 (UTC)