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

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

RfC: 권한 제어의 모양

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


템플릿의 새 스타일:이 목록의 기사에 설명된 바와 같이 권한 통제를 현재 스타일(이들에 사용됨) 대신 사용하시겠습니까?이는 재설계 배경의 일반 원칙에는 공감대가 있었지만 아직 합의해야 할 확정적 레이아웃이 없었던 본 RfC의 후속 조치다.프람 (토크) 07:36, 2021년 5월 7일 (UTC)[응답]

  • A: 제안된 새로운 스타일
  • B: 새로운 스타일이지만 자동 분석됨
  • C: 다른 것

토론(권한 컨트롤의 모양)

  • RfC 이니시에이터로 A, 두 번째 선택 B를 지원하십시오.RfC 이후, 템플릿 토크 페이지에서는 논의와 제안이 있어, RfC 결과와 (한 기관의 여러 ID를 수용하거나, 좀 더 불명확한 일부 아크로에 대한 설명 링크를 유지하는 것과 같은) 원하는 일부 추가 사항의 절충으로서 "Arts" 하위판에 현재 (임시) 구현된 버전을 가지고 있다.nyms). 파블로 피카소와 같은 기사들은 새로운 외모가 어떻게 될 것인가에 대한 아이디어를 준다: 많은 기사에서는 물론 더 작아질 것이다.새로운 버전이 지금 구현될 수 있는지 아니면 RfC가 먼저 필요한지에 대해서는 여전히 의견이 분분하여, 우리는 여기에 있다.새 레이아웃을 지원하지 않는 경우 이전 RfC의 결과를 존중하면서 개선 방법을 지정하십시오.가능하다면 이전 RfC를 다시 시도하지 마십시오.프람 (토크) 07:42, 2021년 5월 7일 (UTC)[응답]
  • 반대 – 메인 스페이스에서는 다소 기술적인 면에 너무 큰 중요성을 부여한다. 새로운 디자인은 이전 디자인보다 훨씬 더 많은 밴드감을 제공한다.제안사항:
    1. 위의 #권한 통제에서는 이 템플릿을 우리가 가지고 있어야 하는지에 대한 의문이 제기되었다.그것은 이미 이전 RfC에서 나온 요점 중 하나였다. 나는 설계에 관한 이 두 번째 RfC가 진행되기 전에 정식 RfC(현재 비공식적인 논의와는 다른 방향으로 갈 수도 있음)에서 그 질문을 할 것을 제안하고 싶다.
    2. 앤디 워홀#에서외부 링크(OP에서 제안된 목록의 첫 번째 예만 들어도), 두 개의 축소된 탐색 상자 아래에 새로운 디자인이 *공백되지 않음*으로 표시됨: 위키백과의 경우 이러한 (내부) 탐색 상자는 (WikiData가 처리할 수 있는) 외부 고유 식별보다 훨씬 중요하다.*최소한*으로 새 디자인은 축소되어야 하며, *최소한*는 어떤 종류의 내선박스가든 기사가 포함된 경우 항상 자동 콜랩을 실행해야 한다.
    3. 권한 제어 상자의 색 구성표(새 설계뿐만 아니라 기존 설계도)는 내부 탐색 상자의 표준 색 구성표를 따른다. 즉, 색 구성표는 *다름*(내부 탐색 상자에 일반적으로 사용되지 않는 색 구성표)와 * 덜 눈에 잘 띄지 않음*(관심을 끌지 않는 색상)으로, 따라서 회색 척도 배경 c만 사용할 것을 제안한다.템플릿의 올루어(지금 보라색 배경색이 표시됨).권위적인 통제는 다소 기술적인 측면이며(그런 백과사전 콘텐츠는 사실 아니다), 그렇게 덜 화려한 배경색이 그것에 대한 더 나은 지표가 될 것이다.
--프랜시스 숄켄 (대화) 08:49, 2021년 5월 7일 (UTC)[응답]
  • 반대 – 권한 제어의 지점이 AC 사이트로의 링크가 아니라 이 제안된 설계가 숨기는 고유 식별자 값이라는 점을 제쳐두고라도, 새로운 설계는 너무 많은 경우에 너무 많은 공간을 차지하여 현재 하나의 식별자가 사용되는 여러 개의 테이블 행(흔히 이 군더더더기 지지자)을 만든다.y의 변화는 그들이 얼마나 많은 그러한 사례가 존재하는지 연구하지 않았다는 것을 인정했다.또한 이러한 식별자의 기원과 사용을 설명하는 위키백과 기사에 대한 링크(예: 템플릿 토크 페이지)도 삭제한다.이전 RfC의 종료는 명시적으로 다음과 같이 명시되어 있다."개량 버전이 취할 수 있는 정확한 형태에 대한 어떠한 합의도 없다."새로운 설계를 승인하지 않는 사람은 반드시 대안을 제시해야 한다는 주장은 거짓이다. 더 나은 제안이 만들어지지 않고 지역사회의 승인을 충족시키지 않는 한, 현 상황은 관련된다.Andy Mabbett (Pigsonthewing); 앤디와 대화: 앤디의 편집은 10:24, 2021년 5월 7일 (UTC)[응답]
    • AC의 포인트가 링크가 아니라 가치라는 것에 동의하는 사람들을 많이 찾을 수 없을 것 같아.값이 없는 링크(즉, 이 제안서 및 RfC에서 승인된 링크)는 추가 정보를 얻는 데 유용하거나 유용할 수 있다. 링크 없는 값은 이 템플릿이 눈깜짝할 사이에 완전히 쓸모없는 잡동사니로 삭제(또는 과거의 개인 데이터처럼 보이지 않는 가장 좋은 방법으로)될 수 있다.당신이 주장하는 방식으로는 아무것도 "승인"되지 않았고, 당신은 "현재 사용되고 있는 것"이 현재의 템플릿을 제시하는 다소 일방적인 방법이라는 것을 언급하지 못하는데, 여기서는 어쨌든 여러 개의 "라인"에 걸쳐 표시되는 "행"이 한 개씩 있는 경우가 많다(분명히 입력된 숫자와 화면 너비와 글꼴 크기에 따라 다름).
    • 현재 제안된 것과 매우 유사한 새로운 레이아웃에 대한 합의와 지역사회의 승인이 있고, 현재 버전을 없애기 위한 지역사회의 승인이 있다.이전 RfC의 결과를 존중하는 대안을 제시하지 않은 채 새로운 레이아웃을 반대하는 것은 이미 거부된 상태 쿼터인 원하는 결과를 얻기 위해 그저 망설이는 것이다.프람 (대화) 10:40, 2021년 5월 7일 (UTC)[응답]
      • "AC의 포인트가 가치라는 것에 동의하는 많은 사람들을 찾을 수 없을 것 같다." 아마도 그렇지 않을 것이다.그러나 AC가 무엇인지 이해하는 시간을 가진 사람이라면 누구나 그것이 그렇다는 것을 알 것이고, 그것이 중요한 것이라는 것을 알게 될 것이다.
      • 불특정 신규 배치안에 대한 모호한 제안에 대한 공감대가 있었지만, 우리 모두가 알다시피 공감대는 바뀔 수 있으며, 이제는 구체적인 제안에 대한 공감대를 보여줘야 한다.사람들은 그것을 선택할 수도 있고, 만약 그 사람이 나타나면 대안을 선택할 수도 있고, 그것이 최선의 선택이라고 생각되면 현재 상태를 선택할 수도 있다.지금까지는 그렇다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집은 10:53, 2021년 5월 7일 (UTC)[응답]
  • 반대 토크 페이지에서 논의된 문제부터 해결해야 한다: 특히, 새로운 템플릿은 이전 템플릿보다 훨씬 더 공백이 많고 관련 기사에 대한 위키링크를 포함하지 않는다. (그리고 해당 토크 페이지에 대한 논의는 불필요하게 극적이어서, 이 다시 쓰기에 관련된 사람들을 고려할 때 놀라운 것은 아니다.)내가 선호하는 것은 이전 버전으로 돌아가 ID 값(유용한 것)도 보여주며, 단지 이전 RfC의 컨센서스를 충족하는 새 템플릿에서 사용하는 단어로 머리글자어를 변경하는 것이다.고마워요.마이크 필 (토크) 10:34, 2021년 5월 7일 (UTC)[응답]
    • 자동 압축은 내용이 숨겨지기 때문에 더 심할 것이다.예전 버전처럼 작게 만드는 것이 훨씬 더 나은 해결책이다.고마워요.마이크 필(토크) 10시 55분, 2021년 5월 7일 (UTC)[응답]
  • 참고: 위에 옵션을 추가했는데, "너무 크다"가 여기서 흔히 볼 수 있는 주제인 것 같기 때문이다.@피그손더윙, 마이크 필, 프란시스 숄켄:프람 (대화) 10:51, 2021년 5월 7일 (UTC)[응답]
    • 당신은 "D: no change"를 추가하는 것을 소홀히 한 것 같다.당신의 RfC는 더 이상 필요 이상으로 중립적이지 않다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집은 10시 55분, 2021년 5월 7일 (UTC)[응답]
  • 그리고 왜 이 새로운 디자인이 {{Authority control (arts)}}}}}을(를) 사용한 14K 기사에 대한 합의 없이 구현되었는가?"시험"으로 기술된 변경사항은 즉시 되돌려야 한다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집은 11:06, 2021년 5월 7일 (UTC)[응답]
  • 많은 이전 경험을 통해 배운 Pigsonthewing과 Mike Pel의 댓글에 응답하지 않을 것이라는 점에 유의하십시오. Pigsonthewing과 Mike Pel은 그들이 동의하지 않는 사람들에 대한 비방이나 노골적인 공격을 추가하지 않고 템플릿에 대해 게시할 능력이 없거나 원하지 않는 것 같기 때문이다(위의 댓글을 읽거나 관련 토론과 관련된 내용만 읽음).그들이 여기에 쓴 것은 무엇이든 큰 알갱이로 받아주십시오.프람 (대화) 11시 10분, 2021년 5월 7일 (UTC)[응답]
    • 그러나 Fram은 Wikidata에 대한 모든 토론에서 Andy와 나를 위해 그들이 주장하는 것을 정확히 해 온 오랜 역사를 가지고 있다.이 괴롭힘은 지금으로부터 몇 년째 계속되고 있다.드라마보다 사실에 집중하는 것이 대체로 좋지만 안타깝게도 어쩔 수 없다.마이크 필 (토크) 11:21, 2021년 5월 7일 (UTC)[응답]
    • 그리고 92분 후에 프람은 마이크 필에게 대답한다.Fram이 선택할 때 응답할 것이라는 점을 유의해야 하기 때문에 이 점을 언급한다. 즉, 다른 게시물에 대한 응답 부족(예: RfC가 더 이상 중립적이지 않다는 나의 지적 또는 그들이 현재 제안하고 있는 내용에 대한 합의가 구체적으로 입증되어야 한다는 점)은 선택적이며, 언급된 (보거스) 사유에 해당하지 않는다.바로 위에Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 13:01, 2021년 5월 7일 (UTC)[응답]
  • 프람, 맨 위에 AC RfC를 먼저 하는 게 좋았을 것 같아.만약 AC가 폐기되거나 완전히 다른 형태로 바뀐다면, AC를 재설계하는 데 시간을 낭비하는 것이다.나는 이 RfC가 다소 IDHT가 필요하다고 생각한다. 설계에 대한 이전 RfC의 의지가 매우 명확했기 때문에 왜 이것이 필요한지 잘 모르겠다.미루는 Reader (대화) 11:16, 2021년 5월 7일 (UTC)[응답]
  • 반대. 요청대로 아직 합의가 이루어지지 않았다. @템플릿토크:권한 관리, 그럼 왜 조기 RfC가 있는 거지?
~ 톰.레딩(토크 ⋅dgaf) 11시 52분, 2021년 5월 7일(UTC)[응답]
  • 여기에서 RfC를 시작하기 전에 템플릿 토크 페이지에서 합의가 이루어져야 하는 이유는 무엇인가?똑같은 몇 사람이 서로 다투는 등 그곳에서는 그런 합의는 불가능하다는 것이 분명했다.이전의 RfC(또한 합의 없이 시작되었고, 당신 세 사람에 의해 불평된 소년도)는 당신 세 사람의 의견이 다른 많은 편집자들의 의견과 일치하지 않는다는 것을 분명히 보여주었다.같은 이슈에 대해 몇 번이고 충돌하는 대신 더 폭넓은 의견을 수렴할 때가 왔다.프람 (대화) 12시 15분, 2021년 5월 7일 (UTC)[응답]
  • "같은 이슈에 대해 계속해서 충돌하는 대신 더 폭넓은 의견을 수렴할 때가 왔다." - AKA WP:- 포룸쇼핑 - 톰레딩(토크 ⋅dgaf) 12:52, 2021년 5월 7일 (UTC)[응답]
  • 그게 반대 1명과 하위 3명이야?그것과 함께 감자튀김을 드시겠습니까?— JohnFromPinckney (대화) 12:23, 2021년 5월 7일 (UTC)[응답]
  • 코멘트 - 이 RFC를 "잠금"에 올려야 할 것 같은데...현재 우리가 우리의 기사에 AC 템플릿이 있는지 여부에 대해 열린 RFC(위)를 가지고 있다는 것을 고려하면, 그것은 역효과를 낳는다.위의 RFC의 합의가 그것을 전혀 갖지 않는 것이라면 템플릿이 어떻게 생겼는지는 중요하지 않을 것이다.블루보어 (대화) 12시 49분, 2021년 5월 7일 (UTC)[응답]
    • 나는 RfC가 보이지 않지만, 분명히 이것을 1-point-million-million 페이지에서 삭제하자는 제안이 있다면, 그럴 필요가 있을 것이다. (CENT, Yada Yada)\\ 13:07, 2021년 5월 7일 (UTC)[응답]
      그것은 아직 RfC가 아니다.나는 '물 속을 시험해 보고 싶다'고 했는데, 왜냐하면 나는 그것이 가지고 있는 것에 침투할 것이라는 것을 알았기 때문이다. 하지만 덜 관여된 사람들이, 특히 실행 가능한 선택들에 대해 의견을 개진할 수 있는 시간을 갖고 싶었기 때문이다.정의상으로는 아이디어 랩이 더 적합할 것 같은데, 나는 그 곳이 많은 것을 성취하는데 성공할 수 있을지 잘 몰라서 이것을 시도해보고 싶었다.나는 정상적인 RfC(즉, 조사/토론 방식)가 결정적일 것이라고 생각하지 않는데, 이는 부분적으로 끈질긴 개인주의 때문에, 나는 그것이 어떤 형태를 취해야 하는지에 대해 아직도 생각하고 있다.또한 덜 관여된 정당들에 의해 브레인스토밍이 진행 중이고 아마도 그것은 이 템플릿에 대한 다른 견해들 사이의 간극을 메우는 데 도움이 될 것이다.어쨌든, 나는 RfC에 대한 제안의 어떤 측면을 취하고 싶었어...미루는 Reader (대화) 13:21, 2021년 5월 7일 (UTC)[응답]
      • 미안, 내 잘못...템플릿의 보유(또는 보유) 여부에 대해 (위) 논의가 진행 중인데, RFC라고 추측했다.그렇지 않다고 지적해줘서 고마워.
그래서, 내 의견을 "C"로 바꾸겠다. - 다른 것 - (내 선호도는 기사에서 직접 AC 자료를 호스팅하는 대신에 Wikidata와 간단한 링크를 제공하는 것 - 이미지 공유에 연결하는 방법과 유사) 블루보아 (토크) 14:20, 2021년 5월 7일 (UTC)[응답]
  • 다소 꺼림칙한 A인 것 같다.채무불이행으로 무너지는 것이 아니라, 그것이 기사별로 무너져야 하는지를 가지고 있다.C에게도 확실히 열려있어, 만약 누군가 다른 생각을 가지고 있다면.나는 지난 RfC의 폐막 선언에 전적으로 동의하지 않는다.이 템플릿을 사용자에게 친숙하게 만드는 것에 대한 RfC 진술에 대한 명확한 지지가 있었지만, 대부분의 사람들은 실제로 제공된 예에 대해 구체적으로 말하지 않았다(그리고 그러한 예시를 한 많은 사람들은 그것과 관련된 문제를 강조하고 있었다).하지만 그 RfC는 우리가 가지고 있는 것이고, 아무도 가까운 AFAIK에 도전하지 않았다.그래서 우리는 그것을 좀 더 사용자 친화적으로 만들어야 한다는 생각을 가지고 있고, 그것이 어떻게 보여야 하는지에 대한 논의의 대략적인 출발점으로 사용할 수 있는 예시를 가지고 있다.동시에, 나는 사용자 친화적인 아이디어는 좋아하지만 그것이 이러한 템플릿들 중 일부를 얼마나 크게 만들지는 생각하지 않은 사람들이 많다고 생각한다.만약 이전 버전의 템플릿의 디자인이 하나의 미덕을 가지고 있다면, 물론 그것은 콤팩트한 것이었다.그래서 나는 사용자 친화력이 궁극적으로 페이지에서 그것을 삭제하려는 사람들이 다른 사람들을 설득하는 것을 더 쉽게 만들 수도 있다고 의심한다. 아이러니컬하게도.두고 보자.\\ 13:07, 2021년 5월 7일 (UTC)[응답]
  • 지원 A 이 RfC는 첫 번째 RfC의 명확한 합의를 뒤엎기 위한 시도로 (원래 RfC의 반대자들에 의한) 포럼 쇼핑에 해당한다.템플릿 토크 페이지에 글을 썼듯이, [원래] RfC는 샌드박스가 현상보다 더 바람직하다는 분명한 공감대를 보이고 있다.그 합의는 토크 페이지에 있는 소수의 소리높은 반대자들에 의해 뒤집어져서는 안 된다.또한 템플릿 토크 페이지에서 다시 자신을 인용하면 표준 탐색 상자 동작에서 벗어날 이유가 없다는 이유로 B를 약하게 지지한다(둘 이상의 탐색 상자가 있을 때는 자동 폴링을 하고 한 개의 탐색 상자만 있을 때는 무너지지 않는다).* Papery it has begun...* 13:55, 2021년 5월 7일 (UTC)[응답]
    • RfC를 시작하는 Fram은 나나 다른 포럼 쇼핑이 아니다.당신이 그것을 토크 페이지에 썼을 때, 나는 [원래 강조]라고 대답했다.당신이 제안하는 변경에 대해 합의점을 보여야 하는 부담은 당신에게 있다(변화를 위해서만이 아니라.또한 RfC는 샌드박스에 현재 나와 있지 않은 버전에 대해 전혀 언급하지 않았으며, 실제로 "개선된 버전이 취할 수 있는 정확한 형태에 대해 어떠한 합의도 없다"고 명시적으로 명시했다.Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 15:54, 2021년 5월 7일 (UTC)[응답]
  • A, 아래의 예를 살펴본다.그것은 훨씬 더 사람이 읽을 수 있는 것이고, 나는 그것을 오래된 템플릿에 대한 점진적인 개선이라고 부르고 싶다.기본 자동 접힘 동작은 괜찮다고 생각한다(발바닥판 템플릿이 아닌 경우 접힘).또한, 위와 같은 이전의 논의에서 기초하여 RFC를 추진해야 한다고 생각하는데, 이는 AC 재설계 무자를 만들 수 있는 몇 가지 대안(예: 위키다타 또는 중간 엔위키 페이지 링크)이 있기 때문이다.레비비치harass/hound16:28, 2021년 5월 7일 (UTC)[응답]
    • 아래 B도 괜찮다.개인적으로 나는 그것이 항상 무너지는지 아니면 기본 행동을 하는지는 나에게 큰 문제가 되지 않는다고 생각한다.레비비치 hound/ 21:13, 2021년 5월 9일 (UTC)[응답]
  • A - 나는 권한 관리 템플릿을 좋아하지만, 나는 그것이 그렇게 비밀스럽다는 사실이 마음에 들지 않는다.이것은 페이지 하단에 "정크"가 더 많이 들어가는 비교적 적은 비용으로 사용 편의성이 크게 증가할 것이다.게타르다 (토크) 16:44, 2021년 5월 7일 (UTC)[응답]
  • B 우리 독자들은 실제로 이 템플릿을 별로 사용하지 않는 것 같아, 내가 마지막으로 권한 관리 템플릿을 사용한 것이 언제인지 기억이 안 나.이 템플릿은 눈에 띄지 않고 마음에 두지 말아야 한다. 만약 사람들이 정말로 그것을 원한다면 그들은 그것을 분해할 수 있다.솔직히, 권한 제어에 대한 전체 아이디어는 대부분 내부용인 것 같은데, 아마도 그런 템플릿을 대화 페이지에 넣는 것이 가장 좋을 것이다.선장이크 ek 21:30, 2021년 5월 8일 (UTC)[응답]
  • 우리가 이 RfC를 하는 정도까지, 캡틴Eek에 의해.두 번째 선택권 A, 왜냐하면 뭔가 좀 더 길고...영어...짧고 기계적인 것보다 낫다.미루는 Reader (대화) 12:24, 2021년 5월 9일 (UTC)[응답]
  • B 위의 코멘트에 따르면.Sea Ane (대화) 19:56, 2021년 5월 9일 (UTC)[응답]
  • B는 독자들에게 추가적이고 즉시 이용할 수 있는 정보를 그들의 면전에 밀어 넣지 않고 제공하는 이상적인 타협으로 보인다.물론 접근하기 쉬운 레이아웃은 그렇지 않으면 분명 혼란스러워할 우리 독자들에게는 분명 바람직한 것이다.Aza24 (대화) 20:12, 2021년 5월 9일 (UTC)[응답]
  • A를 근소한 차이로 2위로 하는 B.위의 DrawingReader에 따라.새 버전은 압도적으로 많은 사람들이 훨씬 더 이해할 수 있을 것이다.아즈폴리노 (대화) 15:55, 2021년 5월 14일 (UTC)[응답]
  • B 새로운 예들은 모두 옛날 예들보다 덜 당황스럽다.자동발광은 대부분의 시간을 공격적으로 크게 만들지 않고도 논리적인 그룹으로 포맷할 수 있다.정보는 여전히 이용 가능하지만 눈에 띄지 않는다.· · · 피터 사우스우드 : 08:22, 2021년 5월 15일 (UTC)[응답]
  • A(혹은 C일 수도 있지만 나 자신은 제안이 없어, 어려운 문제야!)나는 오토콜랩스에 반대한다: 많은 사람들이 지적했듯이, "권한 통제"라는 용어는 사서들 밖에서 잘 이해되지 않으며, 왜 그들이 템플릿을 확장하기를 원하는지에 대해 일반 사용자들에게 거의 설명하지 않는다.만약 그것이 확장되기 시작한다면 적어도 "아, 이것들은 다른 사이트들에 대한 링크/크로스 레퍼런스"가 확실하다.위키피디아는 종이가 아니며, 어떤 나무도 차지하는 여분의 공간으로 인해 죽지는 않을 것이며, 사람들은 단지 몇 밀리미터만 더 스크롤하면 그 범주를 볼 수 있을 것이다. 또는 바닥의 짜릿한 법적 흐릿함을 볼 수 있을 것이다.(모바일로 사이즈에 대한 문제가 많아진 것은 고맙지만, 템플릿이 거기에 표시되지 않고, 그렇게 만들 계획이 없는 것으로 내가 알 수 있는 한) ub "?!" 16:52, 2021년 5월 23일 (UTC)[응답]

예

템플릿 테스트 케이스 페이지:

기존:

새로 만들기:

오래된:

새로 만들기:

-- Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집은 16:21, 2021년 5월 7일 (UTC)[응답]

참고: 위의 예는 허구적이며, 실제 기사에는 나타나지 않는다.RfC는 구 템플릿의 100만 예 옆에 (기존 RfC 예시가 "체리 픽업"이라고 했듯이) 실제 기사에서 확인할 새 템플릿의 예시가 14000개라고 확인했지만, 이 모든 변경사항의 3대 반대자들은 "부패"를 주장하며 이를 위해 모든 노력을 되돌렸다(새로운 버전이 작동했다).그들이 복귀한 버전과 동일한 수의 AC를 보여주었다.기본적으로 현상유지 3명의 옹호자는 이를 교란시키기 위해 전력으로 모든 것을 하고 있다(그리고 이전 RfC, 템플릿 토크 페이지에서의 논의).위키피디아를 시작한 매우 피곤한 상황:관리자 게시판/사고자#피그손더윙 등아마도 이 RfC는 단순히 중단되고 다시 시작된 후 일부 중립적인 관리자의 감독 하에 추가 중단을 방지해야 할 것이다.현재 상태로는, 이런 혼란에 참여하는 데 관심이 있는 사람이 생길 가능성은 희박하다, 그것이 의도였을 것이다.

위의 예들은 또한 이전 RfC에 대해 사용된 용어를 사용하기 위해 체리피크된 것이다.시험 페이지에는 또한 다음과 같은 허구적인 예가 포함되어 있다.

대

그리고

대

프람 (대화) 16:35, 2021년 5월 7일 (UTC)[응답]

당신이 언급하는 큰 예는 허구가 아니라 더글러스 아담스에서 사용되는 실제 권한 제어 템플릿이라는 점에 유의하십시오.* Papery * 16:43, 2021년 5월 7일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

프로세스 요청: 부분적으로 차단된 편집기에 대해 요청된 편집 템플릿 및 대기열

나는 오늘 3년 동안의 비참조적 변경과 부적절한 BLP 분류의 이력을 위해 기사 영역의 편집자를 부분적으로 차단했다.사용자에 대한 조언에서, 나는 그들이 대화 페이지에서 편집을 요청하라고 제안하기 시작했고, 그리고 나서 우리는 이것에 대해 특별히 편집 요청 과정이 없다는 것을 깨달았다.COI 편집자는 {{request edit}, 보호되는 페이지는 {{edit protected} 시리즈가 있지만, 파블록된 편집자는 (내가 아는) 시리즈가 없다.나는 결국 완전히 보호된 {{편집}}}을(를) 사용하자고 제안했지만, 그건 반쪽짜리 해결책이고, 보호받지 못하는 글에 그런 템플릿이 있는 요청은 그 이유만으로 일상적으로 거부당한다.

{{edit 부분적으로 차단된}}} 요청 템플릿(검토자에게 요청자의 차단 로그를 확인하라는 지침과 함께, 검토자에게 보류 중인 변경 사항이 있는지 보호 로그를 확인하도록 권고하는 방법과 유사함)을 만들 것을 제안한다.위키피디아는 부분적으로 편집 요청을 차단하고 해당 카테고리의 페이지 하위 목록을 위키피디아에 추가:요청된 편집 섹션의 대시보드나 스스로도 이 일을 대담하게 할 수 있지만, 새로운 대기열을 만드는 것은 광범위한 함의가 있을 수 있기 때문에, 먼저 공감대를 가늠해 보고자 한다.이반벡터 (/)TalkEdits 11:27, 2021년 5월 29일 (UTC)[응답]

@Ivanvector:템플릿에 대해 모른다는 것이 놀랍다.부분적으로 차단된 편집.🐔 시크닷 12:34, 2021년 5월 29일 (UTC)[응답]
Chicdat의 다소 불필요한 톤은 제쳐두고, 그 템플릿이 좋은 해결책인 것 같다.그것은 특정 범주로 분류되지 않으며, 나는 그것이 쉬운 검토를 허용해야 한다는 이반벡터의 의견에 동의한다.다른 편집 요청 템플릿과 일치하도록 리디렉션으로 {{edit 부분적으로 차단된}}도 생성했다.반딧불 (t · c ) 14:28, 2021년 5월 29일 (UTC)[응답]
주어진 페이지를 편집할 수 없도록 차단된 편집자의 편집 요청에는 모든 편집 요청(따라서 잠재적으로 높은 우선순위 지정)과 별도의 대기열이 부여되어야 한다는 것은 분명하지 않다.아이작 (대화) 15:06, 2021년 5월 29일 (UTC)[응답]
개인적으로 나는 그것이 그들에게 더 높은 우선순위를 부여하고 그들이 의심의 여지 없이 필요로 하는 더 높은 정밀 검사를 받도록 하는 것에 대한 것이 아니라고 생각한다. 별도의 대기열로 그들은 더 주의 깊게 처리해야 하는 요청으로 쉽게 식별될 수 있다.반딧불 (t · c ) 15:15, 2021년 5월 29일 (UTC)[응답]
또한 COI 편집 요청을 처리하고자 하는 편집자가 있을 수 있지만 부분적으로 차단되지는 않으며, 그 반대로 처리하고자 하는 요청을 쉽게 찾을 수 있도록 하는 편집자가 있을 수 있다. --Trialpears (대화) 15:21, 2021년 5월 29일 (UTC)[응답]
페이지에서 차단된 편집자의 요청 편집이 더 논란이 될 수 있을 만큼 사실이며, 다른 요청보다 앞서 나갈 수 있는 별도의 스트림에 요청을 넣지 않고 플래그를 지정하는 것이 좋을 수 있다.통상적인 요청의 대기열(일반적으로 이해충돌 상황)을 처리하려고 하지 않는 관리자들이 많은지는 모르겠지만, 나는 확실히 알지 못한다.아이작 (대화) 15:44, 2021년 5월 29일 (UTC)[응답]
이러한 요청을 별도의 스트림에 넣는 것은 다른 요청보다 뒤처지는 결과를 초래할 수도 있다.그것은 그들이 다른 유형의 요청과는 다르다는 것을 인정하는 것에 불과하다.필 브리저 (대화) 17:45, 2021년 5월 29일 (UTC)[응답]
나는 그들이 본질적으로 얼마나 다른지 의심스럽다.템플릿을 사용한 편집 요청은 해당 페이지에 대한 추가 검토가 필요한 편집자의 요청이다.그것이 이해 상충 때문이든, 사전 분쟁 때문이든, 응답 편집자는 요청자의 과거 이력과 페이지를 검토하여 문맥과 최선책을 세워야 할 것이다.아이작 (대화) 23:28, 2021년 5월 29일 (UTC)[응답]
정밀도 수준을 암시하는 것에 대해서는, 일단 요청이 읽혀지면, 정확하게 사용된다고 가정하는 다른 템플릿은 무시해도, 요청 텍스트는 그것을 분명히 할 것이라고 생각한다. 이삭 (토크) 15:44, 2021년 5월 29일 (UTC)[응답]
부분 차단된 편집자의 편집 요청을 수행하기 위해 누가 자원할 것인가?나는 그들이 메인 스페이스에서 차단되어야 할 정도로 파괴적인 사람이 있다는 생각을 이해할 수 없지만, 우리는 여전히 그들이 편집 요청을 하기를 원한다.내 말은, 그냥 변명을 하는거야.이건 탁아소가 아니지?레비비치 17:00, 2021년 5월 29일 (UTC)[응답]
부분적으로만 차단된다면 부분차단된 관리자는 잠재적인 상환의 불씨를 보았다.확실히 편집 요청을 하는 것이 이것을 위한 방법인가?필 브리저 (대화) 17:45, 2021년 5월 29일 (UTC)[응답]
나는 이런 식으로 p-block을 사용했고 사용자 대화에서 그들의 편집 요청에 응답했다.어떤 사람들은 유용하고 지놈 같은 일을 하지만 어떤 이유로든 WP와 같은 특정 정책을 따르지 않을 것이다.생방송에 들어가기 전에 그들의 편집 내용을 검토하도록 요구하는 것은 유용한 자원 봉사자를 잃는 것과 그에 대한 보고가 ANI를 방해하게 하는 것 사이의 좋은 절충이다.블록이나 보호와 같은 기술적 제한은 우리가 붕괴를 방지하는 데 필요한 만큼만 절약되어야 한다(즉, 순긍정적인 결과를 만들어 내야 한다).블록은 WP를 처리하는 한 가지 방법이다.CIR 문제, 그러나 역량은 스펙트럼이며 편집의 완전한 금지가 항상 문제의 최선의 해결책은 아니다.나는 이러한 종류의 요청에 (하위)범주를 추가하는 것이 시범종목별로 분류하는데 유용할 것이라고 생각한다.— Wug·a·po·des 23:04, 2021년 5월 29일 (UTC)[응답]
정말 나는 {{부분 차단된}}}(아니면 애초에 이런 글을 올리지 않았을 것)에 대해 몰랐고, 치크다트가 지적해 준 것에 감사한다.그럼에도 불구하고, 나는 이러한 종류의 편집 요청은 COI와 보호 요청과는 별도로 분류되어야 한다고 생각한다. 그들은 다른 종류의 정밀 조사를 필요로 하기 때문이다.꼭 그 이상일 필요는 없어, 단지 다를 뿐이지.그리고 만약 그들이 전혀 분류되지 않는다면, 누가 그들에게 대답할 것인가?이반벡터 (/)TalkEdits 23:27, 2021년 5월 29일 (UTC)[응답]
템플릿은 {{Request edit} 템플릿의 래퍼이므로 편집 요청으로 분류된다.내가 보기에 정밀도가 실질적으로 다른 것은 분명하지 않다: 응답하는 편집자는 배경 상황을 숙지하고 편집자가 합의된 지지를 얻을 수 있는지 또는 이해 당사자들이 동의할 수 있는 편집의 출발점 역할을 할 수 있는지를 판단하기 위해 최선의 다음 단계를 결정해야 한다. 이삭(토크) 23:36, 5월 29일21 (UTC)[응답하라]
나도 동의해, 편집자 관심만큼 정밀조사도 다르지 않다고 생각해.COI 편집을 다루는 것은 나에게 흥미가 없고(일부적으로는 요청을 처리할 수 있을 정도로 정책 영역을 잘 모르기 때문) 그리고 나는 그들이 나보다 내용을 더 잘 검토할 수 있기 때문에 가능한 한 토크 페이지 감시자들이 보호된 편집 요청을 더 잘 대답하는 것이 좋다고 생각한다.그래서 나는 편집 요청에 많이 응답하지 않지만 카테고리가 있다면 p-block 요청에 응답하고 싶다.그것이 프로젝트 전체에 유용한 것인지, 아마도, 하지만 나는 그것을 좋아한다. — Wug·a·po·des 00:06, 2021년 5월 30일 (UTC)[응답]
분류에 대해 전적으로 동의하는지 아니면 동일한 정밀 조사를 요구하는지에 대해서는 잘 모르겠지만, Pblocked 편집자들이 편집을 요청할 수 있는 템플릿을 만들어 달라는 요청만 해도, 이것은 해결된 것으로 간주될 수 있다.모두에게 감사하다.이반벡터 (/)TalkEdits 18:19, 2021년 6월 2일 (UTC)[응답]

현재 UTC 시간으로 UTC 표시

나는 시간대를 "UTC"와 오프셋으로 표시하는 대신 새로 고침 링크 외에 현재 UTC(페이지 로드 시)로 표시해야 한다고 제안한다. 

- 전류: UTC+05:00 - 제안: 04:33, 2021년 6월 5일(UTC) + 05:00 [새로 고침]

이 포맷은 시청자가 현지의 현재 시간을 쉽게 계산할 수 있게 하는 동시에, 그 장소에서 정확한 현재 시간을 동적으로 표시하려는 복잡성을 피할 수 있게 한다.은바라크 (대화) 04:44, 2021년 6월 5일 (UTC)[응답]

제발 힌트를 받아라: 그것은 일어나지 않을 것이다.2021년 7월 1일자 페이지를 보는 사람은 2021년 6월 5일 04:33과 같은 캐시된 시간을 보면 완전히 혼란스러울 것이다.위키피디아는 역동적인 디스플레이를 지원하지 않으며 혼란스러운 텍스트를 표시하는 것은 좋은 대체가 아니다.조누니크 (대화) 04:54, 2021년 6월 5일 (UTC)[응답]

@요누니크:이미 모든 표준 시간대 페이지(예: UTC-08:00)에서 발생하며, 각 페이지에는 [새로 고침] 링크가 표시된다.왜 이것이 달라져야 하는가?— Nbardach (대화 • 기여) 06:08, 2021년 6월 5일 (UTC)[응답]에 의해 추가된 사전 서명되지 않은 논평

안녕, 미디어위키 개발자야.나는 현재의 시간을 보여주는 것이 위키피디아에 구현하기 위한 지극히 합리적이고 사소한 제안이라고 생각한다.
나는 지금까지 서버측 방식으로 이것을 위키텍스트와 함께 구현하는 것은 불합리할 것이라는 이 절과 이전 절에서 제시된 우려에 전적으로 동의한다.그러나 그러한 사고가 바로 아이디어와 기술적 구현이 서로 더 분리되어야 하는 이유다.이 서버측을 실행하려면 소프트웨어 변경을 통해 미세한 수준의 파서 캐시 만료(승인하지 않음) 또는 취약한 커뮤니티 실행 퍼지봇(차단할 가능성이 있음)이 허용되어야 한다.이런 형태와는 별도로, 서버가 페이지 전체를 구문 분석해야 하기 때문에 페이지 로드가 비정상적으로 느리게 1분마다 한 명 이상의 방문자를 처벌해야 하는 문제가 여전히 남아 있다.(나는 적어도 하나라고 말한다, 방문객들은 서로 뒤에 대기할 것이기 때문에, 그 후 최대 대기열 길이를 가지고, 숙청 전의 복사본이 부활되어 대신 제공될 것이다.)그리고 그 후에도 서버와 클라이언트의 시계 차이와 인터넷을 통해 데이터를 전송하는 데 걸리는 시간 때문에 결과가 몇 분 정도 꺼질 가능성이 높다.그 후 텍스트는 독자의 브라우저에 있는 동안 정적인 상태를 유지하며 업데이트되지 않는다.그래서 누군가가 실제로 그것을 보았을 때, 나는 그들이 페이지를 위아래로 스크롤하는 동안 매 초/분이 지날 때마다 더 퀴퀴하게 자라면서 그들 자신의 시계와 비교해 적어도 2분 정도 끌 수 있는 50%의 가능성을 주었을 것이다.따라서 인프라 관련 문제는 차치하고, 나는 이것이 독자들에게 느리고, 혼란스럽고, 전문적이지 못한 경험을 제공할 것이라고 생각한다; 비록 그것이 어떻게든 매 분마다 (그들은 그렇게 하지 않을 것이다.)
이와 같은 것을 구현하는 방법은 클라이언트 쪽 JavaScript의 몇 줄(MediaWiki를 통해:Common.js 또는 기본 실행 가젯).이러한 스크립트는 쓰기에는 매우 사소한 것이며, 현대적이거나 복잡한 API를 필요로 하지 않을 것이다(그렇다).Intl.DateTimeFormat위에서 언급되었지만, 이것은 필요하지 않다.시간 및 분(초 단위) 표시를 목표로 한다고 가정할 경우 브라우저에서 주목할 만한 성능 비용이 발생하지 않을 것이다.
내가 이것에 접근하는 방법은:

  • 인포박스는 시계를 위한 자리를 남겨둔다.선호하는 스타일링으로 인해 비어 있는 경우 스팟을 사용할 수 없는 경우, CSS에서 이 예약된 지점을.client-nojs즉, JavaScript가 제공되지 않거나 사용 가능/지원되지 않는 컨텍스트에 숨긴다.
  • infobox는 HTML 데이터 속성으로 스폿에 주석을 달아서, JavaScript가 특히 쉽게 픽업할 수 있는 방식으로 오프셋을 나타낸다. 예:<p data-tzoffset="-90">Offset: -01:30 <span class="tpl-place-currenttime"><!-- placeholder --></span></p>.
  • 자바스크립트는 이 요소를 찾고, 오프셋을 찾고, 현재 분에서 하위 추출한 다음, 시간과 분만 간단히 렌더링하기 위한 소수의 문장이 될 것이다.고대에 널리 지원되고 있는 Date#setMinute 브라우저 기능은 심지어 자동으로 시간 등에 걸쳐 롤링을 처리한다.

--크링클 (대화) 23:48, 2021년 6월 5일 (UTC)[응답]

  • 만약 누군가가 그들의 화면에 UTC 시계를 원한다면, 그들은 이미 가젯을 통해 그것을 사용할 수 있고, 그것은 항상 모든 화면에서 사용할 수 있을 것이고 토론 타임스탬프를 보는 것 같은 것에도 유용할 수 있다.— Xaosflux 03:19, 2021년 6월 6일 (UTC)[응답]
  • 이것은 또한 위에서 논의한 여름 문제를 해결하지 않는다. 왜냐하면 이것의 목적은 여전히 현지의 현재 시간을 계산하는 것이고, 그것을 달성하기 위해 현지의 여름 시간 상태와 오프셋도 필요할 것이기 때문이다.— Xaosflux 03:21, 2021년 6월 6일 (UTC)[응답]
  • 모든 사람들, 특히 데브 크링클이 현 시대의 전시에 더 깊이 잠수해 준 것에 감사한다.Xaosflux가 지역 여름철 주와 지역성의 불규칙한 시간대 구현에 대한 우려를 어떻게 해결해야 할지 확실하지 않지만, Krinkle과 다른 사람들이 좋은 아이디어를 얻기를 바란다.은바라크 (대화) 06:15, 2021년 6월 6일 (UTC)[응답]
  • @Krinkle: 당신의 제안은 정적 UTC 상쇄에 효과가 있을 것이지만, 원래의 논의는 장소에서의 시간에 관한 것이었다.많은 장소들은 정확한 시간 표시를 위해 일광 절약 시간이 필요하다.Anomie⚔ 11:55, 2021년 6월 6일 (UTC)[응답]
    • @Anomie:이해는 하지만, 그런 것들은 또한 인포박스가 라이브 타임 없이 오늘 전시될 상쇄에도 영향을 미친다.나는 이 일이 이미 어떤 식으로든 처리되고 있다고 생각했다.그 정보는, 내가 예상하는 바로는, JS 코드에 그것이 오늘날 인간에게 알리는 것과 같은 방식으로, JS 코드에 의해 사전 처리된다.나는 요즘 이 정보를 인코딩하는 선호되는 방법이 무엇인지 모르지만, 우리가 어디서 하든 간에, 나는 우리가 여기서도 똑같이 할 수 있다고 생각한다.예: 다음 스위치의 UTC 타임스탬프를 추가하고 이를 다른 속성으로 인코딩한다.다시 말하지만, 이것은 살아있는 시계가 없어도 정보가 제시되는 방식을 개선하고자 하는 의도에서 비롯되었다.네가 왜 선택했는지 이제 더 잘 알 것 같아Intl.DateTimeFormat그리고 아마도 그것은 목적지 상자를 숨기기 위한 폴백과 여전히 통할 수 있을 것이다.그러나 그 접근방식의 단점은 이 정보를 독자들에게 전반적으로 설명/제시할 수 있는 방법을 제대로 파악하지 못했다는 것을 내게 시사한다는 점인데, 아직 설명하지 않았다면 내게는 더 큰 영향을 미치는 문제인 것이다. --크링클 (대화) 15:53, 2021년 6월 6일 (UTC)[응답]
      • 너는 잘못 추측하고 있다.기사에는 현재의 시간대 오프셋이 무엇인지 말하려는 시도가 없고, 인포박스는 단지 정상과 여름 오프셋이 무엇인지 말하기만 한다.괜찮아, DST가 어떻게 작동하는지 모르는 사람들은 포함된 위키링크를 따라 그것에 대해 배울 수 있어.그러나 "현재 시간은 DST인지 아닌지에 따라 13시 20분이나 14시 20분"이라고 말하는 것은 별로 효과가 없을 것이다.Wikitext에서 스위치를 인코딩하는 방법(템플릿을 사용하는 경우처럼 템플릿 또는 모듈을 통해 가능):일부 휴일의 캘린더 날짜)는 작동할 수 있지만 반년마다 대량 제거해야 한다.Anomie⚔ 17:25, 2021년 6월 6일 (UTC)[응답]
    • 왜 클라이언트 쪽 JS가 작동하지 않는지 개발자가 설명해 주시겠습니까? 
          기능을 발휘하다 calc Time(도회, 상쇄하다) {         // 현재 위치에 대한 날짜 개체 생성         시합을 하다 d = 새로운 날짜();         // msec로 변환         // 로컬 시간대 오프셋 빼기         // UTC 시간(밀리초) 가져오기         시합을 하다 utc = d.gettime() + (d.getTimezoneOffset() * 60000);         // 다른 도시에 대한 새로운 날짜 객체 생성         // 제공된 오프셋 사용         시합을 하다 nd = 새로운 날짜(utc + (3600000*상쇄하다));         // 문자열로 반환 시간         돌아오다 "도시로 가는 현지 시간"+ 도회 +"는 "이다.+ nd.토로칼레스트링();     }     빈틈이 없는(calc Time('음바이', '+5.5'));     }
      은바라크 (대화) 18:02, 2021년 6월 6일 (UTC)[응답]
      • @Nbardach:그것이 크링클의 제안에 대한 일반적인 생각이다.하지만 무엇을 위해 지나갈지 알아내는 것은offset뉴욕 같은 곳은 문제가 있다.거기에 있을 것이다.-43월 중순부터 11월 초까지-5남은 한 해 동안Anomie⚔ 00:22, 2021년 6월 7일 (UTC)[응답]
        위에서 귀띔해 주었듯이new Intl.DateTimeFormat('en', { timeZone: 'America/New_York', hour: 'numeric', minute: 'numeric' }).format(new Date())DST를 고려하여 현재 뉴욕 시간을 제공한다.오래된 브라우저에서는 작동하지 않는다. 그것들은 비 JS행위로 되돌아갈 수 있다.– SD0001 (대화) 04:23, 2021년 6월 7일 (UTC)[응답]
      • 아마도 당신은 mw:에서 당신의 아이디어를 토론할 수 있을 것이다.MediaWiki_talk:Gadget-UTCLIveClock.js, 구현하기 좋은 장소일 수 있으므로. 아이작(토크) 04:49, 2021년 6월 7일(UTC)[응답]

2년 범위 생년월일 범주

논란의 여지가 있는 많은 범주를 만들기 위한 퀴즈토닉 탐구에 착수하기 전에, 나는 지역사회의 승인을 위해 이 범주를 여기에 버려야겠다고 생각했다.

이게 그 상황입니다.우리는 일반적으로 생년월일별로 전기적 주제를 분류한다(예: 카테고리:1965 출생).우리는 특정 날짜에 수천 개의 과목을 가지고 있는데, 이 과목들은 우리가 그들의 나이를 알고 있지만, 그들의 실제 출생 연도는 어느 2년인지 모른다.예를 들어, 셰리 벤슨 (1962/1963년 출생), 헬레나 브루너 (1957/1958년 출생), 맷 갤러웨이 (1970/1971년 출생)가 있다.현재 이러한 과목은 모두 10년 생년월일(예: 카테고리:1960년대 출생)에 따라 분류되지만 카테고리:1962–1963 출생과 같은 카테고리를 만들어 더 정확할 수 있다고 생각한다.이것은 또한 우리가 2년이라는 기간을 가진 과목들과 그들이 10년 안에 태어났지만, 그 10년 안에 태어날 수 있었다는 더 많은 지식을 가지고 있는 과목들을 구분할 것이다.BD2412 T 04:51, 2021년 5월 29일 (UTC)[응답]

그것은 내게 불필요해 보인다.그것은 단지 매우 짧은 범주들을 만들어낼 뿐이고, 매우 짧은 범주들(유지 관리되지 않는)은 대개 포기된다.시크다트(토크) 11:11, 2021년 5월 29일 (UTC)[응답]
왜 두 해 동안 그것들을 분류하지 않는 거지?정확하지 않고, 우리가 가진 최고의 정보를 바탕으로 우리가 할 수 있는 최선의 방법일 뿐이다.10년 단위로 분류하는 것은 1959-60년, 즉 1899-1900년에 태어난 사람을 다루지 않는 것처럼 보인다. 그리고 나는 이 모든 특이한 사건들에 대해 일련의 매우 짧은 범주를 만드는 것이 과도한 범주화처럼 보인다는 것에 동의한다.이반벡터 (/)TalkEdits 11:31, 2021년 5월 29일 (UTC)[응답]
그것들을 둘 다 넣는 것 역시 내 본능일 것이고, 비록 머리 위에서 예를 떠올릴 수는 없지만 역사적 인물들에게는 전에 본 적이 있다고 나는 확신한다.—니졸란(talk · c.) 22:33, 2021년 5월 29일 (UTC)[응답]
어느 정도 검색해 본 결과, 1980년대 두 가지 출생 범주에 있는 한 사람에 대한 기사는 앤드류 마커스가 유일하기 때문에, 기본적으로 현재 그런 일은 일어나지 않는다고 말할 수 있다. --Trialpears (talk) 22:37, 2021년 5월 29일 (UTC)[응답]
맞아, "역사적"이라는 말은 20세기 이전의 것을 의미했지만, 그렇다고 해서 지금 당장은 그 예들을 찾을 수도 없어.—니졸란(talk · c.) 22:46, 2021년 5월 29일 (UTC)[응답]
1850년대 같은 결과지만 여기서 맥스 허쉬(경제학자)가 유일한 기사. --트리얼피어스(토크) 22:49, 2021년 5월 29일(UTC)[응답]
나는 '그저 나이'라고 말하는 관습이 꽤 최근의 것이라고 생각하기 때문에 별로 오래된 기사 주제에 대해 생각하고 있지 않다.하지만, 나는 셰리 벤슨과 같은 1962년 출생과 1963년 출생 둘 다에 이름을 올리는 것이 문제가 있다고 생각하는데, 그 중 하나는 사실적으로 잘못되어 있고, 우리는 그것을 알고 있기 때문이다.나는 제안된 것과 같은 범위 범주를 가지는 것이 일부 편집자들이 그 범주의 피험자들을 위해 더 정확한 출생 날짜 정보를 찾아낼 수 있도록 어느 정도 이끌기를 바란다.BD2412T 00:34, 2021년 5월 30일 (UTC)[응답]
@Trialpears:나는 위키소스를 기억하고 있다는 것을 방금 깨달았다. 여기서 이중 범주는 위키피디아가 아닌 (자동) 관습이다. 예를 들어, s:Author:토마스 아 켐피스혼동이야, 미안해.—니졸란 14:23, 2021년 5월 30일 (UTC)[응답]
다른 옵션은 예를 들어 카테고리:1965년경 출생은 1965년경(또는 그 전후)에 태어난 사람들을 포함하지만, 우리가 그 특정 해에 태어난 사람을 알고 있다는 부정확한 주장을 제기하지는 않을 것이다.BD2412 T 04:40, 2021년 5월 30일 (UTC)[응답]
  • 분류의 목적은 피사체를 숨기기 위한 것이 아니라는 것을 기억하라.그것은 물건들 사이의 항해를 돕기 위함이다.
만약 우리가 어떤 것이 적용되는지 확실하지 않다면 나는 두 개의 "생년" 카테고리에 있는 누군가를 나열하는 데 문제가 없다.기사에 대한 탐색을 목적으로 한다면, 지나치게 포괄적으로 하는 것이 좋다.아마도 관련 바이오 기사는 처음 몇 문장에서 피험자의 생년월일에 대한 불확실성을 분명히 할 것이다.블루보아 (대화) 15:24, 2021년 5월 30일 (UTC)[응답]
나는 그러한 범주 추가가 특정 연도의 원천이 없었던 과거에 되돌아가고 있는 것을 본 적이 있다.BD2412 T 16:55, 2021년 5월 30일 (UTC)[응답]
  • 카테고리가 필요한 이유:이러한 경우 출생연도가 불확실한가? --Jayron32 15:25, 2021년 6월 1일(UTC)[응답]
    • 별개의 질문이다.불확실한 출생연도는 어느 해라도 될 수 있다.예를 들어 1964/1965 범위의 사람을 범주:1965 출생아 및 범주:출생연도가 불확실하고, 연구자들에게 맡겨 연관성을 만들어라.BD2412 T 23:26, 2021년 6월 2일 (UTC)[응답]
  • 틀린 것으로 알려진 범주를 사용하는 것에 반대한다.만약 누군가가 1964년 또는 1965년에 태어났다면, 당신은 그 범주들 중 하나가 적용되지 않는다는 것을 알고 있다.—쿠스마 (대화) 17:55, 2021년 6월 3일 (UTC)[응답]
  • 만약 두 범주로 분류하는 것이 표에서 벗어난다면(그리고 나는 이론에 동의한다) 두 범주 모두로 분류해야 할 것이다.카테고리 같은 것에 대한 유지 관리 카테고리는?생년월일은 확인된 연령에서 날짜로 추론하고 편집자에게 적절한 기존 날짜 범위 범주로 분류하도록 하는가?이반벡터 (/)TalkEdits 12:13, 2021년 6월 6일 (UTC)[응답]
  • 분류:1960년대 출생 속임수는 당연히 문제의 2년이 같은 10년에 속할 때만 효과가 있다.내 생각에 가장 좋은 것은 두 개의 연도 범주와 범주:출생연도가 불확실하다.완벽한 해결책은 아니지만, 완벽한 해결책은 존재하지 않고 이 정도면 충분하다.나는 이것을 자동화된 처리를 하기 위해 코드를 쓰기를 원하는 누군가의 관점에서 보고 있다.Person X가 태어난 지 5년 이내에 태어난 모든 사람들을 찾고 싶었다고 하자.내 계획으로 그들을 찾아내서 우리가 원하면 추가 필터링을 할 수 있을 거야연도 범주에서 꺼내서 2년 범주에 넣으면 가능한 모든 2년 범주를 검색해야 하는데, 대부분 존재하지도 않을 것이다.마찬가지로 "Person X보다 정확히 100년 전에 누가 태어났는가?"와 같은 질문도 있다.또 내 안의 코끝에 코끝이 찡한 발상인은 쌍둥이에 관한 기사 사건을 즉시 떠올렸는데, 그 중 한 쌍은 12월 31일 자정 직전에 태어났고, 다른 한 쌍은 불과 몇 분 후인 다음해 1월 1일에 태어났다.확실히 그것은 두 가지 범주에 속할 것인가? -- RoySmith (talk) 14:43, 2021년 6월 6일 (UTC)[응답]
    • 나는 20년 중 1년 안에 태어날 수 있는 사람들에 대해 생각해 본 적이 없었다.BD2412 T 02:31, 2021년 6월 9일 (UTC)[응답]
아니면 2세기.아니면 밀레니엄.그리고 출생지와 관련된 시간대 문제가 있다.IMO 이 논의는 1이나 0을 원하는 컴퓨터 건축의 공예품이며, 그라데이션과 뉘앙스에 문제가 있다.아마도 범주와 같은 흑백에 대한 진리의 (최상의) 버전을 하나 골라 기사의 본문에 있는 뉘앙스를 설명하라.카테고리 내 중복 생성은 breakage IMO. -- GreenC 03:20, 2021년 6월 9일 (UTC)[응답]
원래의 제안은 범주:1962–1963 출생과 같은 범주의 새로운 범주를 만들어 범주에서 중복을 피하자는 것이다.그것은 범주:1959–1960 출생아 또는 범주:1999–2000 출생아에도 똑같이 적용된다.그러한 범주의 기사는 다른 생년월일 범주에 포함되지 않을 것이다.대상자의 실제 생년월일이 결정되면 해당 연도로 재분류된다.BD2412 T 04:38, 2021년 6월 9일 (UTC)[응답]
형제자매들은 1년 안에 각자 소속될 것이다.나는 그것들이 결합되지 않는 한 왜 당신이 복합적인 기사를 가질 수 있는지 알 수 없었다.그리고 서로 다른 해에 태어난 결합 쌍둥이는 거의 불가능할 것이다.---카지다 (토크) 17:11, 2021년 6월 7일 (UTC)[응답]
Khajidha, 나는 당신이 결합되지 않는 한 왜 결합한 기사를 가질 수 있는지 알 수 없다, Dionne 5중주단을 보라. 그것은 모든 카테고리에 있다:1954년 사망, 카테고리:1970명 사망, 카테고리:2001년 사망, 카테고리:살아 있는 사람들. -- 로이스미스 (대화) 02:45, 2021년 6월 9일 (UTC)[응답하라]
그런 경우에 해야 할 일은 개별 이름에서 리디렉션을 만들고 사망년도의 범주를 리디렉션에 넣는 것이라고 생각한다.BD2412 T 03:09, 2021년 6월 9일 (UTC)[응답]
미안하지만, 우리가 정확한 생년월일을 모른다면, 우리는 그것들을 정확한 연도에 근거한 범주에 넣으려고 해서는 안 된다.나는 그것이 어떤 것들을 얼마나 "더 쉽게" 만드는지 신경 안 써.이것은 내가 우리 독자들에게 거짓말을 하고 있다는 생각이 든다."쉽고 틀리다"는 것은 말이 안 된다.2년이 같은 10년이라면 Category:1960년대 불확실한 연도의 출산과 같은 카테고리를 볼 수 있었다. --Khajidha (토크) 14:00, 2021년 6월 7일 (UTC)[응답]

내일(8일)부터 성장팀 피쳐 테스트 시작

안녕하십니까? 전 마샬 밀러입니다. WMF Growth 팀의 제품 매니저입니다.나는 이곳 영어 위키백과에서 성장팀의 특징을 테스트하는 것에 대해 4월 23일부터 @Nosebagbear의 글을 추적하고 있다.간단히 말해서, 성장 팀 기능은 새로운 계정 소유자에게 시작할 중요한 도구를 제공한다. 즉, 간단한 편집이 필요한 제안 기사(유지 관리 템플릿 기반)와 질문을 할 수 있는 멘토를 할당한다.

지난 몇 주 동안, 많은 영국 커뮤니티 회원들이 이 특징들을 시도해 보았고, 우리는 대체로 긍정적인 반응과 아이디어를 들었다.우리는 또한 16명의 멘토들이 등록되어 있다. (우리는 이번 시험을 위해 더 많은 것이 필요하지 않지만, 앞으로 더 필요할 것이다!)가장 관련성이 높은 커뮤니티 회원들과 상의한 후, 우리는 이 위키에서 특징 테스트를 시작할 날짜를 정했다.우리의 계획은 내일인 6월 8일부터 새로 온 2%의 사람들에게 성장 기능을 제공하기 시작할 것이다.이는 내일부터 새로 창출되는 모든 계정에 대해 2%가 성장 기능을 가지며 나머지는 그렇지 않다는 것을 의미한다.영어 위키피디아는 매달 약 13만 개의 새로운 계정을 얻기 때문에, 우리는 이 달 동안 이 기능을 가진 2,600명의 신입 회원들이 이 계정을 갖게 될 것으로 예상한다.제안된 편집을 완료하고 멘토에게 질문을 하면 대부분 최근 변경사항과 감시목록에서 볼 수 있다.이러한 편집은 #Newcommer 작업, #Mentority 모듈 질문, #Mentority 패널 질문으로 확인할 수 있다.

테스트가 진행되는 동안 성장 팀은 새로운 활동을 모니터링하여 (반달리즘의 증가와 같은) 부정적인 일이 발생하는지 확인할 것이다. 만약 뭔가 잘못되면, 우리는 신속하게 변화를 일으킬 수 있을 것이다.약 4주 후, 우리는 데이터를 반성하고 멘토들에게 어떻게 진행할지 결정할 수 있는 경험에 대해 물어볼 것이다.

여기 계신 모든 분들께 좋은 소식이었으면 좋겠는데 -- 우리는 지역사회의 의견을 가지고 신중하게 계획을 세웠다고 생각하지만, 누군가 질문이나 염려가 있는지 확실히 듣고 싶다.내일 다시 올려서 시험이 시작됐는지 확인할 계획이야.MMiller (WMF) (토크) 18:42, 2021년 6월 7일 (UTC)[응답]

그리고 멘토가 되지 말아줘, 벌써 15명이 넘었어.오 이런, 스트레이샌드 효과.성고템플 (대화) 22:10, 2021년 6월 8일 (UTC)[응답]
안녕하십니까? 오늘 테스트를 시작했는데, 신규 고객 중 2%에게 성장 기능을 제공하는 것이었습니다.프로젝트 토크 페이지의 진행 상황에 따라 진행하십시오!MMiller (WMF) (토크) 04:51, 2021년 6월 9일 (UTC)[응답]

자폐적 자부심의 날을 기념해야 하는 위키백과

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


다가오는 6월 18일은 자폐증적 자부심의 날이다.위키피디아는 1면에 무한 배지를 보여주면서 그 날을 기념할 수 있을까?이 제안을 논의할 적절한 포럼은 어디인가?안부 전해요RIT RAJARSHI (대화) 03:59, 2021년 6월 7일 (UTC)[응답]

@RIT RAJARSHI: 일반적으로 개별 행사를 축하하는 데 대한 지원이 많지 않았고, 커뮤니티가 메인 페이지에 무한 배지를 추가하는 것을 지지할 것이라고는 생각하지 않는다.당신이 할 수 있는 최선의 방법은 선별된 기념일에 대한 가이드라인을 읽고, 이벤트/기사가 6월 18일 페이지에 추가하는 기준을 충족한다면, 192.76.8.73 (토크) 11:25, 2021년 6월 7일 (UTC)[응답]을 하는 것이라고 생각한다.
나는 자폐증에 대한 인식을 높이는 연극을 무대에 올리는 것이 임무인 작은 자선단체의 수탁자인데, 나는 이것에 반대한다.나는 여기서 미끄러운 논쟁이 타당하다고 생각한다.내가 몇몇 편집자들의 마음에 소중하다고 확신하는 정신 건강 인식의 달, 즉 에이즈 인식 주간이나 국제 차날을 위해 우리가 무언가를 해야 하지 않을까?우리가 주목해야 할 유일한 날은, 만약 있다면, 누구나 편집할 수 있는 열린 백과사전에 대한 경각심을 일깨우는 날이다.필 브리저 (대화) 12시 50분, 2021년 6월 7일 (UTC)[응답]
우리는 공식적인 방법으로 개별적인 날을 기념하지 않지만, 우리의 엄청난 다른 규칙에 따른 관련 기사 제출은 주어진 날의 메인 페이지에서 강조될 수 있다.새로운 기사에 대한 특별한 날짜 요청을 허용한다는 것을 알고 있는가? 그리고 오늘의 특집 기사도 그렇다.규칙에 부합하고 자폐적 자부심의 날에 적합한 기사가 있다면 (공정하게) 두 팔을 벌려 환영을 받을 것이다.(올해 6월 18일은) 하지만 너무 가까울 수도 있다.—쿠스마 (대화) 13:09, 2021년 6월 7일 (UTC)[응답]
@필 브리저:한 가지 분명히 해야 할 것은 자폐증과 자폐증의 자부심은 같지 않다는 것이다.자폐증 자만은 자폐증 개인이 우리 자신이 될 권리가 있다는 것을 강조하고 우리는 우리 자신을 망가진 신경 전형으로 가려야 할 필요가 없다.우리는 무한한 잠재력을 가지고 있지만, 그러기 위해서는 우리가 접근할 수 있는 틈새가 필요하다.우리는 또한 세계가 우리를 더 필요로 한다고 말한다.우리는 유전적 다양성의 우생학적 제거에 반대한다.우리는 인지적 다양성을 장려한다.우리는 강점은 다양성에 있고 동일성에 있지 않다고 믿는다.우리는 "우리 없이는 우리에 대해 아무것도 없다. 우리는 숨겨진 장애와 어떻게 장애가 영향을 받은 사람의 것이 아니라 접근하기 어려운 세계에 속하는지에 대한 우리의 경험을 매일 공유한다. 스펙트럼에 있는 사람으로서, 나는 이러한 메시지들이 자폐증 인식 프로그램에서 누락되거나 누락되었다고 느낀다; 그리고 두 가지 모두 매우 다르다.
자폐증에 대한 자부심을 왜 퍼뜨릴까?왜냐하면 인식은 오해를 불러일으키기 때문이다.자각은 종종 자폐증에 대한 공포로 이어진다.우리에게 도움이 되는 것은 이해, 수용, 자신감이다.그러나 인식은 대부분 신경계 주도의 자선단체에 의해 지배되는, 신경계 전형적인 기관들에 의해 자금 지원을 받는 주요한 (일반적인) 관점이다.인식 프로그램은 우리가 없는 우리에 대한 것이다.이와는 대조적으로, 우리의 잠재력을 발전시키고 확장하는데 실제로 도움이 되는 것은 전형적인 신경 권위에 의해 촉진되지 않는다.그것은 우리의 작은 노력으로 촉진된다.
지금은 주로 백과사전에 동의하지만, 다양한 기념일을 공연하기 때문에, 1일 기념일은 큰 문제가 되지 않을 것이다.안부 전해요리트 라자르시 (토크) 13:22, 2021년 6월 7일 (UTC)[응답]
이 기사는 이 날 시리즈에 여러 번 실렸다.
그래서 그것은 정기적인 기념일이 되어야 한다.리트 라자르시 (토크) 13:30, 2021년 6월 7일 (UTC)[응답]
나는 인식과 자존심이 다른 것이라는 점에는 동의하지만 인식에 나쁜 점이 있다는 점, 또는 어떤 식으로든 자존심을 배제한다는 점에는 동의하지 않는다.정반대다.많은 두려움은 인식 부족에서 기인하며, 내가 말했듯이, 자폐증이 없는 자선의 수탁자는 나뿐이기 때문에, 그것은 신경계 일반인에 의해 운영되거나 "우리 없이" 조직이라고 비난할 수 없다.사실 그것은 이 제안이 합의된다면 위키피디아에서 더 평준화될 수 있는 비판이다.단어에 대한 내분에 몰두하기 보다는 무엇이 최선인지 생각해 봅시다. 그 이상으로 우리는 다양한 신경증 환자들 사이에서처럼 자폐증을 가진 다양한 사람들 사이에서 합의를 얻는 것이 어렵다는 것을 알게 될 것이다.필 브리저 (대화) 16:26, 2021년 6월 7일 (UTC)[답답하다]
@필 브리저:당신의 모든 조언에 감사한다."무엇이 최선인지 생각해 보자...그래, 모든 사람은 기껏해야 제 기능을 할 수 있는 틈새를 누릴 자격이 있어.주형을 만드는 대신에.우리는 (자폐증과 ASD뿐만 아니라) 신경전형을 포함하는 모든 다양성에 감사하며, 우리를 성형하는 대신 이해하려고 노력하는 소수의 신경전형들에게 감사한다.리트 라자르시 (토크) 02:06, 2021년 6월 8일 (UTC)[응답]
  • 반대 - 아무리 그 명분이 가치가 있다고 해도 자존심 행사를 조장하는 것은 우리의 일이 아니다.DYK를 게시하거나 관련 기사를 게재하는 것은 괜찮지만, 우리의 메인 페이지에 배너와 엠블럼을 게시하는 것은 좋지 않다.블루보어 (대화) 14:13, 2021년 6월 7일 (UTC)[응답]
  • 이러한 조건 인식일 중 어느 날이라도 MP에 특별한 로고를 추가하는 것을 반대한다. 그러나 기사가 양호한 상태라고 가정할 때 위키백과에서 편집 요청을 자유롭게 거절하십시오.OTD에 다시 등록하기 위해 선택된 기념일/6월 18일.— Xaosflux 14:36, 2021년 6월 7일 (UTC)[응답]
  • 상기의 다른 사람마다 반대한다.나는 자폐적인 자부심의 날이 존재한다는 것이 기쁘고, 그것은 오명/차별과 싸우는 데 도움이 되는 훌륭한 방법이지만, 그것은 단순히 우리의 역할이 아니며 이것은 벌레의 통조림을 열 것이다.{{u Sdkb}} 14:54, 2021년 6월 7일 (UTC)[응답]
  • 반대한다. 위에 언급된 다른 우려사항들과 함께 주요 NPOV 문제.성고템플 (대화) 15:27, 2021년 6월 7일 (UTC)[응답]
  • 반대한다. 우리는 이미 메인 페이지에 무엇이 실릴지 결정하는 과정과 일련의 지침을 가지고 있다; 우리는 단지 그것이 가치 있는 대의를 위한 것이라고 해서 표준 이하의 기사로 사건을 추가하기 위해 그 과정을 무시해서는 안 된다. 그것은 엄청난 지렁이를 열 것이다.메인 페이지에서 이벤트를 보려면 다른 모든 사람과 동일한 프로세스를 거쳐야 하며, 이 경우 애초에 제거된 참조 섹션에 태그가 지정된 정리 작업을 수정해야 한다. 192.76.8.73(토크) 16:01, 2021년 6월 7일(UTC)[응답]
  • 위의 모든 반대.타이론 마데라 (대화) 19:23, 2021년 6월 7일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

RFP 보고서 보관(again)

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


지난 4월, 나는 RFP 보고서를 보관할 것을 제안했다.그러나 이에 대한 어떠한 조치도 취해지지 않았고, 논의 자체가 보관되었다.그냥 이런 일이 생길지, 언제 일어날지 궁금했을 뿐이야.【例句】치크닷 11:41, 2021년 6월 7일(UTC)[응답]

치크다트 나는 그것이 왜 필요한지 아직 확실하지 않다.나는 종종 RFP를 검토하고 있지만 아카이브에 대해 조사할 필요성을 느끼지 못했다.나는 또한 WP를 사용한다.페이지가 보호되고 보호 페이지로 연결되었는지 여부를 알려주는 반짝임.봇은 일부 요청에 "Automated comment: 이 요청에서 하나 이상의 페이지에 대한 보호/비보호 요청이 최근에 수행되었으며 최근 8일 이내에 어느 시점에 거부됨"이라는 태그를 붙인다.그때도 나는 다시 보기 위해 기록 보관소에 들어가지 않는다.나는 지금 페이지에 가서 그것이 필요한지 알아본다.케임브리지베이날씨, 우카크투크(토크), 훌리바 00:51, 2021년 6월 11일(UTC)[응답]
케임브리지베이날씨 당신이 그것이 유용하다고 생각하지 않는다고 해서 다른 사람들이 유용하지 않다는 것을 의미하지는 않는다.🏳️🌈 Chicdat 10:11, 2021년 6월 11일 (UTC)[응답]

나는 지난 토론에 참여한 편집자들을 비난하고 있다.@ProcrastinatingReader, PEIsquirrel, Jayron32, Pppery, Xaosflux, Cyberpower678, GenQuest, Malcolmxl5, CaptainEek, Beeblebrox, Nosebagbear, Fastily, and ToBeFree: 🏳️🌈 Chicdat Bawk to me! 10:11, 11 June 2021 (UTC)[reply]

  • 제안이 아무런 조치도 취하지 않고 보관된다는 것은 제안서에 대한 관심이 거의 없다는 좋은 지표다.나는 그것에 매료되지 않았다.어떻게 사용할지, 어떤 혜택이 있을지 나로서는 알 수 없다. --말콤플렉스5 (대화) 10:28, 2021년 6월 11일 (UTC)[응답]
  • 왜 이것이 이루어져야 하는지, 그리고 이 행동의 이점은 무엇인가?나는 이것이 끝났다고 생각하고 잠자리에 들었다.지금 당장은, '저기' 위에 있는 더미에서 잡동사니를 꺼내서 '여기' 위에 새로운 더미를 만들고 싶은 것처럼 들린다.그러나, 당신의 추리는 무엇이며, 그것이 WP에 어떤 식으로든 이득이 되는 것은 무엇인가?GenQuest 12:31, 2021년 6월 11일 (UTC)[응답]
  • 나 또한 우리가 왜 이것을 귀찮게 해야 하는 지에 대해 고심하고 있다.아무도 보지 않을 수백 개의 쓸모없는 아카이브 페이지를 단순히 만들어 내는 변화인 것 같다.이는 삭제 토론이나 중재 집행 보고서와 같은 것이 아니라, 누군가가 관련 삭제 토론/arb 사례/RFC를 위해 10년 후에 다시 끌어 올려야 할 수도 있다. 기본적으로 이러한 모든 보고서는 관리자의 템플릿 응답과 함께 표준 템플릿과 한 줄 문장이 된다.만약 RFPP에서의 요청이 실행된다면, 그 페이지에 대한 보호 로그에 어떤 종류의 중단이 역사적으로 발생했는지에 대한 합리적인 기록으로 작용하는 항목이 있을 것이고, 만약 페이지 보호 요청이 거부된다면 나는 우리가 다시 그것에 접근해야 할 이유를 보지 못한다.한 페이지가 6개월 전에 보호되지 않았다는 사실은 새로운 보고서에 전혀 관련성이 없어야 한다 - 한 페이지를 보호해야 하는지에 대한 결정은 현재 어떤 혼란이 일어나고 있는지에 기초해야 한다. 192.76.8.73 (대화) 13:30, 2021년 6월 11일 (UTC)[응답]
  • 내 의견은 변하지 않았다; 나는 그런 과정이 완전히 쓸모없다고 생각하겠지만, 그것을 실현하기 위해 필요한 일을 하는 그 누구도 방해하지 않을 것이다.그것은 관리자로서, RFPP에서 나의 일을 하는 데 있어 나 자신에게 아무런 목적도 제공하지 않으며, 그 분야에서 어떠한 이익도 제공하지 않는다.나는 또한 어떤 행정관이라도 어떻게 그런 시스템에서 어떤 용도를 찾을 수 있는지 알 만큼 똑똑하지도 않고 상상력도 없지만, 그런 점에서 나는 상당히 낮은 바인데, 그래서 나는 아무도 막지 않을 것이다... --Jayron32 13:42, 2021년 6월 11일 (UTC)[응답]
  • 앞의 절에는 실제로 공감대가 형성되어 있었는데, 반대/유용하지 않은 7개, 지지 2개, 무관심한 1개였다.위의 독특한 반응과 합치면 반대 9명, 지지 2명, 중립 1명.늑장부리는 Reader (대화) 13:45, 2021년 6월 11일 (UTC)[응답]
  • 페이지를 보관하면 여기서 검색 및 Whatlinks에서 페이지를 사용할 수 있다.이것은 장단점이 있다: 때때로 무언가를 잊어버리는 것이 더 낫다.나는 아직 설득력 있는 사용 사례를 보지 못했다.—쿠스마 (대화) 13:47, 2021년 6월 11일 (UTC)[응답]
  • Meh, 하지만 나는 이것이 정말로 필요하다고 생각하지 않아.그들은 실제로 xFD처럼 선례를 남기지 않는다.보호 로그가 부여되면 보호 관리자가 연결하고자 하는 것과 연결될 수 있으며, 거부되는 경우 비극히 짧은 미래의 요청이 자체의 장점에 따라 검토되는 것을 막지 못할 수 있다.— Xaosflux 15:22, 2021년 6월 11일 (UTC)[응답]
  • 실행 중인 관리자가 작업을 수행하는 경우 RFP 개정 ID에 대한 영구적인 링크를 포함하는 요약을 추가하는 것을 자동화하는 것이 어떨까?이행된 WP는 다음과 같다.RM/TR 요청은 이제 아카이브 팽창을 생성하지 않고 추적된다. -2pou (대화) 15:49, 2021년 6월 11일 (UTC)[응답]
  • 다시 말하지만, 이것이 어떤 문제를 해결할지는 확실하지 않다.페이지에는 이미 꽤 유용한 보호 로그가 있다.선장Eek 18 18:58, 2021년 6월 11일 (UTC)[응답]
  • 나는 위의 모든 사람들의 의견에 동의한다.왜 이것이 필요한지에 대해 설득력 있는 이유(또는 솔직히 어떤 이유라도)가 명확하게 설명되지 않았다.Mz7 (대화) 19:03, 2021년 6월 11일 (UTC)[응답]
  • 누가 제발 이 토론을 철회해 주시겠습니까?분명히 아무 데도 못 갈 것 같지만, 나는 토론을 끝내는 것이 금지되어 있어서, 나 스스로는 이것을 할 수 없다.시크다트(토크) 12:38, 2021년 6월 12일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

WP를 상승시키기 위해 잘못 배치된 RfC:DOK를 지침 상태로 전환

– 다른 곳에서 관련 논의를 위한 포인터.

다음 위키백과 대화를 참조하십시오.오리 테스트#RfC는 이것을 가이드라인으로 만드는 것을 테스트한다.이것은 그 {{Essay}}} 상태를 {{Guideline}}(으)로 끌어올리는 일반 RfC이다.그것은 정말로 WP로서 속해 있다.이 페이지의 제안서.사실, 저기를 폐쇄하고 여기로 옮길 것을 제안한다.귀찮게 할 가치가 있다면.우리는 WP조차 만들지 않았다.BRD는 그렇게 하도록 많은 제안들을 한 후에 가이드라인을 제시하였다. — SMc캔들리쉬 lish 18:28, 2021년 6월 12일 (UTC)[응답]

모바일 버전 아티클 세그먼트를 아래에서 닫을 수 있도록 설정

20:50, 2021년 6월 14일 (UTC)

다른 언어로 된 여러 문서에 대한 링크 허용/기사 섹션

다른 언어의 기사들 사이의 하나의 링크만 허용하는 현재의 방법은 하나의 언어로 기사를 만들기에 충분한 개념은 항상 다른 언어의 하나의 기사가 될 것이며, 결코 여러 개의 기사가 될 수 없을 것이라고 가정한다.그러나 그렇지 않은 경우가 많다.예를 들어, 같은 글에서 칭킹으로서의 역사를 논하는 영국 창춘이 있다.그러나 일본 위키백과에서는 싱킹이 한 가지 기사를, 창춘도 한 가지 기사를 싣는다.두 일본 기사 모두 합치는 것이 비현실적으로 보일 정도로 길며, 일본 위키백과가 영어 위키백과를 바탕으로 기사를 바꾸도록 하는 것은 옳지 않아 보인다.

내가 제안하는 해결책은 일본의 싱킹 기사 같은 기사가 싱킹을 논하는 영국 창춘 기사 섹션과 연결되도록 하는 것이다.일본 창춘 기사의 상단에 일본 싱킹 기사로 갈 수 있도록 하는 해프닝이 있기 때문에 영어 기사는 여전히 일본 창춘 기사와 연결될 수 있다.에리남로드 (대화) 16:16, 2021년 6월 10일 (UTC)[응답]

@Erynamrod:사이드바에 나오는 상호언어 링크에 대해 말하는 거지요? (내가 같은 것에 대해 쓰고 있다는 것을 확실히 하기 위해서)이것들은 현재 1:1의 기사 링크만 지원하고 섹션으로의 연결은 지원하지 않는 위키다타를 사용하여 채워져 있지만 해결책이 있다 - 당신은 여전히 수동으로 입력된 이전 스타일의 링크를 사용할 수 있다.각 기사의 사이드바에서 각 언어에 대해 하나의 링크만 가질 수 있지만, 동일한 기사에 링크하는 다른 위키에서 여러 페이지를 가질 수 있다. 예를 들어, 일본 기사의 싱킹 기사에 링크를 추가하면 [[en:]과 같은 것을 추가하면 된다.창춘#만추오 및 제2차 세계 대전]] 페이지 어디에나 있다.영어 기사는 링크가 하나만 들어갈 수 있기 때문에, 당신이 주목하듯이 그것을 다루는 유일한 방법은 일본측에서 해산을 하는 것이다. 192.76.8.73 (대화) 18:03, 2021년 6월 10일 (UTC)[응답]
신싱은 창춘으로 가는 길목이다.원한다면 위키다타의 일본식 싱킹에 리디렉션 페이지를 링크하고 {{위키다타 리디렉션}}을(를) 추가할 수 있다.– 피누서톱 (토크 ⋅ 기여) 18:44, 2021년 6월 10일 (UTC)[응답]
@Erynamrod, 긴 설명을 원하면 d:를 참조하십시오.도움말: 여러 항목이 겹치는 시틀링크 처리Whatamidoing (WMF) (토크) 20:43, 2021년 6월 15일 (UTC)[응답]
모두 고마워.이미 이 이슈/토론을 인지하지 못한 것에 대해 사과한다.마지막 질문을 하나 할 수 있다면 어떤 솔루션을 사용하는지 선호하는가?리디렉션에 대한 링크 또는 수동으로 입력한 이전 스타일 링크?Erynamrod (대화) 09:06, 2021년 6월 16일 (UTC)[응답]

거부되거나 삭제된 초안의 이미지 자동 목록

초안이 삭제되면 Commons에 업로드된 이미지가 항상 확인되지는 않으며 나른해질 수 있다(잘못된 경우 수정).OgreBot이 더 이상 실행되지 않기 때문에 현재 신규 사용자의 업로드 확인은 더욱 어려워지고 있다.

이를 위해 봇이 거부(가능한 경우 삭제)된 이미지 목록을 자동으로 작성하도록 할 수 있는가?목록은 초안 작성자가 업로드한 이미지로 제한될 수 있으며, 신규 사용자만 가능하다.이미지가 허용 가능하더라도(복사본 등은 아님) 새로운 사용자가 커먼스 카테고리에 대해 알지 못하는 경우가 많아 이미지가 범주화되지 않은 상태로 방치된다.

이것은 물론 그러한 봇을 만들 수 있는 누군가의 도움을 필요로 할 것이다.MKFI (대화) 17:38, 2021년 6월 13일 (UTC)[응답]

봇을 부호화할 수 있는 사람을 찾는 가장 좋은 장소는 WP이다.BOTREQ. 내가 이해한 바와 같이 리스트는 논란의 여지가 없는 것으로 간주되므로 거부된 초안의 이미지 목록을 생성하기 위해 명시적인 합의가 필요하지 않아야 한다.삭제된 초안에 사용된 이미지들은 내가 추측하는 관리인봇을 필요로 하지만 방금 삭제된 초안에 사용된 이미지의 목록을 생성한 관리자에 대해 어떤 종류의 합의 수준이 요구될지는 모르겠지만, BOTREQ의 직원들은 알아야 한다.나는 그것이 제안된 것으로는 어떤 문제도 없다고 본다.Thryduulf (대화) 20:33, 2021년 6월 13일 (UTC)[응답하라]
Bot 요청이 생성됨:위키백과:Bot requests#거부되거나 삭제된 초안의 이미지 자동 목록.MKFI (대화) 19:55, 2021년 6월 16일 (UTC)[응답]

북 네임스페이스의 미래

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

책 네임스페이스를 더 이상 사용할 수 없으며, 더 이상 사용할 수 없는 내용은? --Trialpears (대화) 18:27, 2021년 5월 15일(UTC)[응답]

이 RfC에는 여러 가지 서로 다르지만 관련된 제안이 포함될 것이다.우선 많은 편집자들이 네임스페이스를 모를 가능성이 높기 때문에 책 네임스페이스에 대한 약간의 역사를 줄 것이다.나는 또한 현재 상황을 설명하고 이전의 몇몇 토론과 연계할 것이다. (어떤 수단을 동원해서도 읽을 필요가 없다.)그리고 나서 나는 각각의 섹션에서 가능한 몇 가지 행동의 개요를 설명할 것이다.RfC가 폐쇄되면 각 제안에 대한 합의를 평가하고, 이 좀비 네임스페이스를 어떻게 다룰지에 대한 합의가 있기를 바란다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

사용자:Trialpears - 이 토론을 특별한 위키백과 페이지로 전환하시겠습니까?위키백과처럼:의견 요청/책 네임스페이스의 미래?좀 길어지고 있다.아심(토크) 08:40, 2021년 6월 16일 (UTC)[응답]
Ashley Aasim 곧 닫을 것이다(WP에서 요청:CR)과 나는 그것이 있다면 일찍 보관하는 것에 문제가 없다고 본다.나는 페이지 길이를 주요 이슈로 보지 않는다.하지만 나는 여기서 강한 의견을 가지고 있지 않다. --trialpears (대화) 20:43, 2021년 6월 17일 (UTC)[응답]


기록(책 네임스페이스)

책 네임스페이스는 2009년 기사 모음집을 다운로드하거나 인쇄하는 방법으로 도입됐다.이렇게 하려면 Special을 사용하십시오.책에서 원하는 기사의 컬렉션을 선택하려면 책을 예약하십시오. 그것들을 장으로 나누고 렌더링 설정을 선택하십시오.표지 이미지를 주고, 책의 색을 바꾸고, 렌더링 설정을 선택하고, 기사를 장으로 나눌 수도 있다.

이 작업을 완료한 후에는 PediaPress에서 인쇄본을 구입하거나 Offline Content Generator를 사용하여 PDF를 비롯한 다양한 형식으로 다운로드할 수 있다.

결국 Offline Content Generator는 구식이 되어 유지 관리가 불가능해졌다.더 이상 버그와 보안 문제를 해결할 수 없어 위키미디어 재단은 2017년 10월 모든 위키미디어 위키에서 도서 렌더링 서비스를 중단했다.이후 위키백과 도서는 페디아프레스에서 물리적인 형태로나 미디어위키2LaTeX(de:b:Benutzer:Dirk Huenniger/wb2pdf/manual)를 통해서만 구할 수 있었다.여기서 문제는 만약 MediaWiki2LaTeX가 당신에게 제대로 작동한다면 우리는 독자들이 제3자 사이트를 방문하여 우리의 컨텐츠에 접근하고 그것을 구입하거나 상당한 시간을 기다려 책을 렌더링하도록 요구한다는 것이다.우리 책의 많은 부분이 렌더링하기에는 너무 길고 나머지 상당수는 렌더러를 깨는 항해사 같은 것들이 있고 이론상으로는 그것이 작동해야 한다고 해도 나는 그것이 무작위로 멈추거나 설명할 수 없는 이유로 그 책을 다운받을 수 없는 경우가 많았다.로컬에서(내가 듣기로는 훨씬 더 잘 작동한다고 들었는데) 실행하려면 Linux에서 실행하거나 가상 시스템을 설정해야 한다.이것을 하려고 몇 시간을 투자한 후 나는 포기했다. 그래서 나는 개인적으로 그것을 테스트하지 않았다.기사의 PDF를 원하신다면 몇 초 안에 PDF 버전을 안정적으로 제공할 수 있는 사이드 바의 "PDF로 다운로드" 옵션을 사용해 보십시오.

현재 네임스페이스에는 포털과 같은 인기 있는 포털의 순서에 따라 총 페이지뷰가 있다.남아공.이것은 6000페이지가 조금 넘게 펼쳐져 있다.중요한 편집자 활동이 없는 보통 한 달 동안 대부분의 책들은 단 한 권의 뷰도 얻지 못하고 단지 1.5%의 책만이 하루에 페이지뷰를 받는다.가장 인기 있는 책:기본 데이터 구조는 15개뿐입니다.이 수치들이 나와 다른 사람들의 최근 유지 보수 작업으로 인해 크게 부풀려졌다는 것도 주목할 필요가 있으며, 이 결과 수천 개의 관점을 갖게 되었다.

독자들에게 책을 숨기기 위한 이전 시책들이 여러 차례 있었는데, 가장 큰 세 가지는 2019년 책 제작자 사이드바 제거와 많은 링크 탄압, 2021년 잔여 링크 제거, 2021년 일부 책 관련 템플릿 삭제 등이다.후자의 두 가지는 기본적으로 만장일치 결정이었다.

책은 여전히 네임스페이스를 마주한 공동체로 여겨지고 있으며 종종 "커뮤니티 북"으로 언급되는 도움말 페이지에 있으며 커뮤니티가 유지되고 있는 것으로 추정된다.그것들은 검색 엔진에 의해 색인화된다.특수:를 사용하여 책 네임스페이스에 책을 만들 수 있다.책, 그러나 사용자 공간에서 카테고리(Category로 작성될 수도 있다.위키백과 책(사용자 책)네임스페이스는 WP:Namespace에서 사용되지 않는 것으로 나열된다.

PediaPress는 카탈로그에 있는 우리의 책들 중 몇 권과 연결되는데, 위키피디아에서 그 책들이 삭제될 경우 이 책들을 보관할 수도 있고 그렇지 않을 수도 있다.Special: PediaPress를 계속 사용할 수 있다.책은 지워지지 않는다.위키에 관한 책을 저장하지 않고 페디아프레스에서 저장하거나 사용자 공간을 저장하여 저장한다.

이제 문제는 앞으로 책을 어떻게 다뤄야 하느냐 하는 것이다.여기에는 그 안에 있는 모든 책을 포함한 네임스페이스의 삭제를 완료하는 것이 거의 보이지 않기 때문에 현상 유지에 대한 대안이 포함될 수 있다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

2019년에 PediaPress는 "PDF로 다운로드" 링크에 사용되는 새로운 PDF 렌더링을 구현했지만, Phab에서는 다음과 같이 명확하다.책 지원은 안 된다는 T186740.--스네바 (대화) 19:32, 2021년 5월 15일 (UTC)[응답하라]

  • 댓글을 달다.나는 그것에 몇 가지 더 발언하고 싶다.당초 합의는 위키미디어재단(WMF)과 페디아프레스 간이었다.그들은 우리의 원래 렌더링 엔진인 OCG(Offline Content Generator (Offline Content Generator, OCG)그들은 또한 그들 자신을 위해 한 권을 썼고, 만약 당신이 죽은 나무에 대한 돈을 지불하고 싶지 않다면, 처음에 당신은 그들의 포맷으로 무료 PDF 소프트 카피를 다운로드 받을 수 있었다.그들은 이어서 소프트카피 옵션을 철회했다.반면 OCG는 제대로 작동하지 않았다.그것을 고치려는 페디아프레스사의 시도는 소프트웨어와 사용자 공간 모두에서 템플리팅과 다른 게임의 변화에 따라 끊임없이 추월되었다.또한 Wikibooks는 기능성과 콘텐츠에서 이득을 얻었다.그래서 우리 책에 대한 초기의 관심은 희미해졌다.미디어위키2LaTeX는 두 차례나 교체에 도전했다가 실패했고, 페디아프레스에서 약속한 OCG 대체품인 컬렉터도 알파 테스트 사이트가 등장한 이후 침묵하고 있다.실행 가능한 사내 임대인이 실제로 사용자를 끌어들일 수 있을지 알 수 없게 되었다; 우리는 그런 일을 해본 적이 없고, 자원봉사의 노력이 그것을 전달하기에 부족하며, WMF는 계속해서 그것의 개발에 자원하는 것을 거부해왔다.나는 우리가 결정적인 결정을 내렸다고 제안하고 싶다: 위키백과:책과 위키북스를 둘 다 갖는 것에 무슨 의미가 있는가?하나면 충분하지 않아?죽어가는 우리의 네임스페이스를 만지작거리는 것은 단지 고통을 연장시키는 것일 뿐이다.우리는 그것을 부활시키거나 말뚝을 심장으로 몰아야 한다.비록 내가 선호하는 것은 전자에 있지만, 나는 대다수의 의견이 후자를 위한 것이라는 환상에 사로잡혀 있지 않다.나는 우리가 페디아프레스에게 그것을 계속하도록 빚졌다고 믿었지만, 곰곰이 생각해보니 그들은 분명히 상업적인 이유로 그들의 형식에 대한 무료 다운로드를 우리 발아래에서 끌어냈으며, 우리가 Collector에게 더 이상 빚진 것이 없다.내 사용자 공간에서 책 페이지를 항상 수동으로 관리할 수 있고 MediaWiki2LaTeX 등에 업로드할 수 있어 다른 것은 필요 없어.— 건배, 스틸필러 (토크) 14:04, 2021년 5월 16일 (UTC)[응답]

제안(책 네임스페이스)

북 네임스페이스를 공식적으로 사용하지 않음

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
책 네임스페이스를 공식적으로 폐지하고 그 안에 있는 페이지를 역사적 또는 유지되지 않은 것으로 설명해야 한다는 공감대가 있다.(비관리자 폐쇄) (t · c) 09:22, 2021년 5월 24일 (UTC)[응답]



여기에는 위키피디아와 같은 페이지에서 사용되는 언어의 변경이 포함된다.책, 도움말:책과 {{Saved book}}}.책 네임스페이스에 있는 책들은 더 이상 공동체가 유지되고 있다고 묘사되지 않을 것이다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

  • 최소한 이것을 해야 한다.네임스페이스는 커뮤니티 유지보수를 즐기지 않으며 우리는 그것을 분명히 해야 한다.'불용'이라고 하면 책이 실제로 지원되지 않는다는 것을 누구에게도 분명히 알 수 있을 것이다. --Trialpears (토크) 18:27, 2021년 5월 15일 (UTC)[응답]
  • 반대 책은 여전히 존재하며, 소프트웨어를 고치면 책이 다시 살아날 것이다.헤드폭탄 {t · c · p · b} 18:42, 2021년 5월 15일 (UTC)[응답]
  • 무엇에 반대하십니까?머리 폭탄 당.목욕물과 함께 아기를 내팽개친다.소프트웨어 수정!리틀리브 오일 (대화) 18:47, 2021년 5월 15일 (UTC)[응답하라]
  • 코멘트@헤드폭탄 및 리틀리브 오일:소프트웨어 고치는 상황은 2017년 이후 아무 일도 일어나지 않았고, 연장은 버그픽스만 유지되고 있다는 것이다.특히 PDF 기능으로 다운로드가 존재하는 경우, 개발자가 이를 다시 시작하기 위해 수 주 또는 수개월의 작업을 기꺼이 할 것이라고는 상상할 수 없다.페이지뷰의 양(많은 페이지뷰는 책을 다운받기를 원하지 않을 것이다)은 내가 말한 것과 같다. 나는 100개의 더 중요한 프로젝트로 그런 종류의 시간을 보내는 것을 정당화하는 개발자는 상상할 수 없는 하나의 인기 있는 포털에 필적할 수 없다.소프트웨어 사용이 고정된 경우 제거 전 수준으로 돌아갈 수 있다.2016년 12월 네임스페이스는 도그와 같은 페이지에 버금가는 일일 페이지뷰 6000개를 약간 넘었다.언젠가 고쳐지길 바란다면 그건 타당하지만 왜 그런 일이 일어나는지 최소한 설명해야겠다고 생각했다. --Trialpears (토크) 19:04, 2021년 5월 15일 (UTC)[응답]
    너의 상상력의 부족은 책을 삭제할 근거가 아니다.PDF 렌더러가 작동한다면, 사람들은 그것을 물품/책의 일괄 렌더링에 사용할 수 있고, 그것은 책 렌더링에 완벽하게 좋은 기반이 될 것이다.헤드폭탄 {t · c · p · b} 19:12, 2021년 5월 15일 (UTC)[응답]
    아니면... 우리가 지금 가지고 있는 PDF를 여러 장 인쇄할 수 있을까?아무도 책을 사용하지 않고, 실제로 사용한 적이 없는 것 같다.TP는 추측을 거의 하지 않는다. 만약 당신이 말하는 것처럼 쉽다면, 왜 아직 아무도 그것을 하지 않았을까?Aza24 (대화) 19:20, 2021년 5월 15일 (UTC)[응답]
    닭고기와 달걀 문제.소프트웨어가 고장 나서 아무도 책을 사용하지 않는다.소프트웨어를 고치면 사람들은 다시 책을 쓸 것이다.그들은 임대인이 일할 때 확실히 인기가 있었다.「왜 아직 아무도 하지 않았는가」에 대해서는, WMF에 문의. 헤드폭탄 {t · c · p · b} 12:56, 2021년 5월 16일(UTC)[응답]
    사용법에 대한 일부 데이터는 사용자:SD0001/책.이것은 이 네임스페이스의 대부분이 한 자릿수의 월간 페이지 뷰를 가지고 있다는 것을 보여준다.대부분의 책에는 편집자가 거의 없다.책을 편집한 개별 편집자의 최대 수는 36명이다.비틀즈.전체 책의 약 절반은 단지 2개의 뚜렷한 편집자가 있다. (2번째 편집자는 대부분 AWB/HotCat이다.이것은 그들이 확실히 인기가 있었다는 것을 나타내지 않는다.– SD0001 (대화) 19:46, 2021년 5월 16일 (UTC)[응답]
    그렇다, 그것은 2020년에 책과의 모든 연결이 메인 스페이스에서 제거된 이후 다소 정상적인 것이다.예는 [1], [2], [3]의 명확한 드롭을 참조하십시오.헤드폭탄 {t · c · p · b} 21:33, 2021년 5월 16일 (UTC)[응답]
  • 지원—외부 소프트 웨어 중 하나로 길버트 리니에 관한 책을 만들었는데 아무 쓸모가 없어.사실 PDF&인쇄 가능한 버전 다운로드에서 내가 보는 유일한 차이점은 공식적인 목차, 제목 페이지, 그리고 (어떤 이유에서인지) 모든 WP 링크가 노트의 해당 위키백과 페이지로 연결되는 URL로 바뀐 것이다.내 말은, 말도 안 되는 소리야!우리는 이것처럼 도움이 되지 않는 것을 지원해서는 안 된다, 특히 a)제3자 대안이 있을 때 b)우리는 문자 그대로 PDF와 인쇄 가능한 버전을 가지고 있다)이미 c)그것이 4년 동안 미포장 상태로 있어왔다 d)그것들이 작동하고 있을 때도 아무도 그것들을 사용하지 않았다!Aza24 (대화) 19:16, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 책은 포털과 같다: 독자들이 지역사회의 자원을 쓸만한 가치가 있을 만큼 충분히 요구하지 않는다.그리고 PDF를 만드는 기존 서비스도 있다.WikiBooks는 자체 위키 또는 인터 위키 도구여야 하며, 단순히 enwiki가 아니라 enwiki 네임스페이스 또는 enwiki 프로젝트로서 어떤 언어의 위키로부터도 책을 만들 수 있다.레비비치 hound/ 19:21, 2021년 5월 15일 (UTC)[응답]
  • 유목민, 아자24, 레비비히 1명당 지지한다.책은 우리가 시도했던 실험이었어, 괜찮아.그것은 실패했고, 그것 또한 괜찮다.실패를 인정하고 넘어가자, 그것을 유지하려는 노력을 계속 낭비하지 말자.{{u Sdkb}}} 20:18, 2021년 5월 15일 (UTC)[응답]
  • 아래 설명에 제시된 이유로 삭제하기 위한 보조 옵션으로 지원.ƒirefly (t · c ) 20:30, 2021년 5월 15일 (UTC)[응답]
  • 지원 더 이상 작동하지 않거나 비활성화된 것 등에 매달리는 진짜 트렌드가 WP에 있다.그것은 나쁜 경향이고 책 네임스페이스는 그것의 완벽한 예다.비블브록스 (대화) 20:50, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.오랜 독서와 온오프 IP 편집자로서 나는 수년 동안 책 네임스페이스를 사용하려고 몇 번 시도해 보았지만, 매번 그것은 보편적으로 끔찍한 사용자 경험이었다.NPOV, 무게, 디자인에 중대한 문제가 있는 책을 찾는 것은 흔한 일이며, 책 네임스페이스가 커뮤니티를 유지한다고 우리 스스로를 놀리지 말자 - 그렇지 않다.그것은 지나가는 위키그램에 의해 때때로 고쳐지는 사람들의 개인 책 프로젝트를 위한 쓰레기장이다.이를 설명하기 위해 어떤 백과사전이든 잘 다룰 수 있어야 하는 무작위 주제에 대한 책을 찾기 위한 사용자 경험을 살펴보자 - "유럽 역사"
확장 콘텐츠
  • 책을 시작하려면:유럽 역사는 책으로도, 관련 있는 것으로의 방향 전환으로도 존재하지 않는다.2002년 이후 메인 스페이스 등가(유럽 역사)가 존재해 한 달에 평균 1000페이지가 넘는 페이지뷰를 기록했을 때 검색의 용이성 측면에서 좋은 출발은 아니다.내부 검색 엔진은 세 권의 책과 중첩된 초점을 맞추고 있다. 커뮤니티가 유지되는 네임스페이스에서 중복 페이지는 반드시 통합되어야 하는가?
    • 가장 먼저 등장한 책은 '책:책과 관련된 모든 최악의 문제들을 보여주는 유럽역사.2009 - 2011년에 한 명의 사용자가 만든, 그 이후 유일하게 편집된 것은 위키미디어의 일부분이었다.엄청난 중량 문제: 왜 로마 제국은 총 4개의 기사를 얻는 반면, 유럽 연합은 134개의 기사를 얻는가?왜 제2차 세계대전에 대한 언급이 없는가?유럽 연합에서 가장 높은 건물 목록, 갈릴레오(위성항법)와 유럽 연합의 두문자어, 전문용어, 그리고 역사책에서 하고 있는 작업 관행과 같은 순탄한 것은 무엇인가?유럽연합(EU)을 지나치게 상세히 보도했음에도 불구하고 브렉시트에 대한 언급이 전혀 없는 상황에서 사용자가 만든 이후 이 문제는 완전히 시대에 뒤떨어진 것이다.
    • 두 번째로 나타난 책은 '책:유럽의 역사.이것은 IMO에 초점을 더 잘 맞추지만, 그것은 단지 시간순의 기사 목록으로 구성되어 있고, 내용을 장으로 분류하려는 시도도 없다.2010년 한 명의 사용자가 만든 이 책은 위키그래피와 중단된 합병 시도가 그 이후 편집되었을 뿐이어서 지난 10년 동안 일어난 일은 모두 빠져 있다.
    • 마지막으로 나타난 책은 '책:유럽1.이것은 내 의견 중 가장 좋은 것이다 - 잘 정의된 챕터 구조와 적당한 양의 기사를 가지고 있고 비교적 최신이다. (그것이 더 최근에 만들어졌기 때문이지만, 다시 그것은 2017년에 한 명의 저자에 의해 만들어졌고 그 이후로 편집만 계속해왔다.)그 중 최고라고 해도, 나는 같은 기사를 같은 기본 시간으로 분류하고 훨씬 읽기 쉬운 유럽의 역사보다 더 나은 사용자 경험을 제공하는 방법을 여전히 보지 못하며, 이 제목에서 독자들이 쉽게 찾을 수 있는 것은 아니다.이 책의 마지막 두 부분은 아무도 눈치채지 못한 듯 중복된다.
  • 이제 읽을 수 있는 적당한 책을 찾은 후 - 요약 스타일 기사나 목록의 빈약한 대체물로 목록의 각 기사를 클릭하거나, Linux 가상 머신을 설정하여 페이지를 라텍스로 내보낸 후 PDF로 컴파일하거나, 제3자에게 지불하여 m을 인쇄할 수 있다.전자 백과사전의 종이 사본 몇 년 후에 구식이 될 것이다.이것은 누구를 겨냥한 것인가?웹사이트에 안정적으로 접속할 수는 없지만 엄청난 양의 pdf 파일을 정기적으로 다운받을 수 있는 사람들?인터넷 접속은 불가능하지만 주문서 인쇄에 $$을(를) 사용할 수 있는 사람들?사용하기 쉬운 책 만들기 마법사가 필요하지만 리눅스를 설치하고 라텍스를 사용하는 방법을 알고 있는 사람들?나는 단지 이것이 어떤 인구통계학적 대상을 목표로 하고 있는지 모르겠다.
  • 전반적으로 책 네임스페이스는 독자들에게 유익하거나 유용한 경험이 아닐 뿐이며, 어떤 커뮤니티에서도 이러한 책을 적극적으로 큐레이션한 흔적은 없다.커뮤니티 북 네임스페이스를 감가상각하고 모든 책을 원래 창작자의 사용자 공간으로 옮기는 것을 지지할 것이다. 95%의 경우 실제로 이 책에 콘텐츠를 추가한 유일한 사람이 될 것이기 때문이다. 192.76.8.91 (대화) 21:05, 2021년 5월 15일 (UTC)[응답]
  • 지지해주시고 밑에 있는 분들도 다.나는 "그냥 고쳐라"는 주장이 약하다고 생각한다.이렇게 오랫동안 고장이 났는데 아무도 고치고 싶어하지 않는다면, 아마도 고칠 가치가 없을 것이다.이 네임스페이스가 제대로 작동했음에도 불구하고 나는 이 네임스페이스의 가치를 보기 위해 애쓰고 있다.에어콘 (토크) 21:49, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.제발!고그 더 마일드 (대화) 21:59, 2021년 5월 15일 (UTC)[응답하라]
  • 그렇게 하는 데 아무런 이득이 없다고 반대한다.네모 22:00, 2021년 5월 15일 (UTC)[응답]
    장기적으로 중요한 기사들에 더 많은 편집 시간이 소비된다는 것이 장점이다.– SD0001 (대화) 10:12, 2021년 5월 16일 (UTC)[응답]
  • 지지 - 이것은 몇 년 동안 깨져 왔다.이 문제를 해결하려는 노력은 별로 없어 보이는데, 에어콘에 따르면, 이것은 많은 사람들이 원하는 것 처럼 보이지 않는다.소수의 사용자들이 이런 것을 원하면 사용자 공간에서 할 수 있지만 전체적으로 책 네임스페이스는 죽은 것 같다.호그팜 23:01, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.그다지 주목을 받지 못하고 지금은 쓸모없는 기능이다. --로이스미스 (토크) 00:20, 2021년 5월 16일 (UTC)[응답]
  • 지지하다.—¿philoserf?(토크) 02:09, 2021년 5월 16일 (UTC)[응답]
  • 지지하다.아무도 이것을 유지하는 것에 관심이 없는 것 같다.자원봉사자들이 지원하면 언젠가는 부활할 수도 있을 것이다.지금은 사용자 공간에서 계속 진행하십시오.— 알렉시스 재즈 (말하거나 핑)
  • IP192뿐만 아니라 제시된 증거별 지원. --Izno (대화) 03:27, 2021년 5월 16일 (UTC)[응답]
  • 한편으로 투표는 없다. 그것은 수년간 깨져 왔고 아무도 그것을 고치려 하지 않았다.또한 이 기능은 실제로 사용자 공간(개별 사용자 책자의 경우) 또는 프로젝트 공간(주제에 대한 협업 노력을 위한 경우)에 있어야 한다.좋은 생각이긴 하지만, 사람들이 "위키피디아 콘텐츠 책"을 자기 출판 플랫폼에서 출판하도록 장려하고 싶은지 모르겠다.내 스스로는 투표하지 않지만, 누군가가 네임스페이스의 사용을 개선할 아이디어를 내놓지 않는 한, 이것은 분명히 통과될 것이다.사용자::(power~enwiki, π, ν) 03:31, 2021년 5월 16일 (UTC)[응답]
  • 네임스페이스 사용 중지 지원.다른 사람들이 네임스페이스가 실패한 실험이라고 말했듯이, 나는 단지 이것들을 공동체로 유지하는 것의 효용성을 이해할 수 없다.일부 사용자들은 책을 만드는 데 여전히 관심이 있다. 물론, 그들은 사용자 공간에서 그렇게 할 수 있다 – 독자들이 신경 쓰지 않는 것에 대한 자원 낭비인 지역사회 유지보수를 할 필요가 없다.– SD0001 (대화) 07:07, 2021년 5월 16일 (UTC)[응답]
  • 지원 이것은 네임스페이스가 깨지고 엄청난 시간 낭비다.— Jackattack1597에 의해 추가된 이전의 서명되지 않은 논평 (토크 • 기여)
  • 반대 나는 "비호"라는 단어를 사용하는 모든 것에 반대한다 - 고스트인The Machine 14:07, 2021년 5월 16일 (UTC)[응답]
  • 지원하지만 내용을 보관하십시오.—쿠스마 (t·c) 14:13, 2021년 5월 16일 (UTC)[응답]
  • 반대 PediaPress와 WMF/MediaWiki가 제어하는 기술적인 문제인 것 같으니, 이 문제는 우리가 상관할 일이 아니다.편집자나 독자들이 그 설비가 유용하다고 생각하지 않으면, 그들은 그것을 사용할 필요가 없다.Andrew🐉 (대화) 17:27, 2021년 5월 16일 (UTC)[응답]
  • 지원 (1) 도서는 범위를 벗어났다.이 기능은 우리의 목적에 지엽적이며 기술적으로나 사설적으로 중요한 기반시설로서 유지되어서는 안 된다. (2) 리: "수정", 어떤 용맹한 자원봉사자나 기업도 네임스페이스 책 없이도 그렇게 할 수 있다. (3) 책은 위의 역사에서 이미 더 이상 사용되지 않고 있다.우리의 문서를 업데이트하는 것은 논란의 여지가 없어야 한다는 것. (4) 본 토론과는 별개로, 나는 이 토론이 존재하는 동안 북스에서 어떤 긍정적인 영향(독서 또는 더 넓은 청중)이 왔는지 궁금할 것이다.자르 18:18, 2021년 5월 16일 (UTC)[응답]
  • 지지: 내 추리를 한 번 정리해 이후의 각 논평에서 참고하겠다.나는 책의 특징에서 벗어나기 위한 모든 진행을 지지한다.아무도 아직 그 안에 들어가는 모든 자원 봉사 시간에 걸맞은 설득력 있는 사용 사례를 제시하지 않았다(이것은 현장에서 행해지는 일의 거의 큰 비율이지만 여전히 많은 수의 미사용 시간이다). 192.76.8.91은 어떻게 최소한 그 내용에서 설득력 있는 사용 사례가 없는지 훌륭하게 몇 가지 예를 제시한다.아주 적은 수의 평범한 독자들이 그것에 대해 들어 왔다.인터넷이 좋거나 인터넷이 좋지 않은 사람에게는 좋지 않다.그것은 사람들이 실제로 기사를 찾아보고 읽는 방식과는 관련이 없다.그리고 마지막으로, 법적으로 요구되는 CC-BY-SA 속성이 주어지는 한, 우리는 심지어 이익을 위해 이 기능을 제대로 구현하는 것을 누구도 막지 못하고 있다.— 빌로프 (대화) 22:10, 2021년 5월 16일 (UTC)[응답]
  • 지지 이것은 나에게 새로운 주제고 나는 너의 추론과 위의 모든 논평들을 주의 깊게 읽어 보았다.나는 꼭대기에 가까이 있는 "벌레니까 고쳐!"라는 말에 설득당하지 않는다.내가 보기에 그 사실들은 분명히 자기자신을 대변한다.책 형식이 작동하지 않지만, 그 위에 책 형식이 인기가 없거나 잘 쓰이지 않는다.공연이 끝났으니 이제 커튼을 내리고 오케스트라 구덩이를 비우고 포이어 라이트를 꺼야 할 때가 된 것 같아. 독토럽 22:18, 2021년 5월 16일(UTC)[응답하라]
  • 이것이 해야 할 최소한의 지원이다.얼마 동안 생각해 봤는데, 너의 추리는 확고해 보여.개인적으로 PDF는 책보다 훨씬 나은 해결책인 것 같고, 내가 보는 차이점은 목차뿐이다.페이지뷰를 보면 책도 거의 사용되지 않는 것 같다.에픽푸퍼 (대화) 04:14, 2021년 5월 17일 (UTC)[응답]
  • 192.76.8.91 당 지지.우선 소프트웨어가 작동하지 않는다.즉, 소프트웨어가 고장나서 작동하지 않는다.즉, 이 상황에서 일하는 것은 소프트웨어가 하지 않는 것이다.우리는 PDF 렌더링을 가지고 있는데, 그것은 기본적으로 "책"이 실제로 작동한다는 것을 제외하고 모든 것을 할 수 있다.그래서 "책 네임스페이스"가 남았는데, 그건...그냥 무작위로 기사 목록을 아주 엉망으로 만들어 놓은 거야?문제의 사실은 네임스페이스가 사실상 아무런 조회도 편집도 받지 않을 뿐만 아니라, 그 안의 콘텐츠는 우리가 위키피디아 품질이라고 생각하는 수준에도 거의 미치지 못한다는 것이다.그러면 그 질문은 왜 우리가 지역사회의 목소리로, 무작위적인 사람들이 동료 검토나 합의 절차 없이 무작위적인 기사를 함께 던지는 어떤 무작위 네임스페이스를 공식적으로 지지하는지, 그리고 그것을 존중의 베니어라고 하는 것이 된다.슬프다! jp×g 04:34, 2021년 5월 17일 (UTC)[응답]
    "우리는 기본적으로 "책"이 해야 할 모든 것을 하는 PDF 렌더링을 가지고 있다"고 제안하는 것은 전적으로 잘못된 것이다.그것은 구 OCG에 의해 구현된 책 기능에는 매우 부족하다.단일 기사만 처리한다(내 웹 브라우저의 표준 웹 페이지-PDF 인쇄 옵션이 위키백과 기사를 처리하는 것보다 더 나쁘지는 않다).도서대여자는 또한 목차목록에서 모든 기사를 끌어들이고 목차목록에 따라 장 제목을 조정할 필요가 있다.우리 면허의 법적 요건을 준수하기 위해서, 그것은 모든 기사의 전체 이력에서 사용자들을 하나의 거대한 저작권 섹션에 결합하고 덧붙여야 한다.한편, 하원에서의 이미지들을 위해.마지막으로 PDF에 렌더링하고 페이지수를 매긴 후 내용 목록에 페이지 번호를 추가해야 한다.어떤 이유에서인지 "PDF creator가 모든 것을 한다"는 거짓 밈은 상당히 널리 퍼져 있고 많은 이들이 그것의 완전한 거짓을 인정하지 않는다(사실, 그것을 다루지 못한 것이 우리 개발자 공동체가 지속적으로 실패해 온 주된 이유였지만, 그것은 또 다른 이야기였다).— 건배, 스틸필러 (토크) 10:31, 2021년 5월 17일 (UTC)[응답]
  • 위의 Levivich별 지원 및 아래의 BlueRaspberry 삭제 의견별 지원.생존이 잘 뒷받침되지 않는 사업에 귀중한 자원봉사 시간을 허비하지 않도록 움직여야 한다.아즈폴리노 (대화) 05:53, 2021년 5월 17일 (UTC)[응답]
  • 지원 - 나는 이곳에 6년 동안 머물렀고 행정상의 수도에서도 책 네임스페이스를 편집한 적이 없다.무정부상태 (대화) 10:45, 2021년 5월 17일 (UTC)[응답]
  • 성공하지 못한 흥미로운 실험을 지지하십시오.나는 현 단계에서 그것에 어떤 자원도 쓸 필요가 없다고 본다.오두막 8.5 19:50, 2021년 5월 17일 (UTC)[응답]
  • 지원 이것은 위키북스에 속하는 백과사전이다.그렇다면 책을 삭제하는 대신 위키북으로 옮기는 것은 어떨까? -킬라네(C•T•U) 17:22, 2021년 5월 18일(UTC)[응답]
  • 지원 우리는 백과사전이지 서점이 아니다.책은 우리의 사용자 기반에서 요구되는 편집자 시간 이상의 가치가 있을 만큼 충분히 수요가 많지 않다.EekThar she edits! 17:53, 2021년 5월 19일 (UTC)[응답]
    우리의 특대형 편집자가 요구하는 시간은?— 고스트인The Machine 18:10, 2021년 5월 19일 (UTC)[응답]
  • 지지하다.유지되지 않은 형상은 제거해야 한다. 샌드스타인 07:09, 2021년 5월 20일 (UTC)[응답]
  • '반대 반대'는 어설픈 헛소리다. 그것은 방문객들의 야유를 혼란스럽게 할 것이고, 책 애호가들은 어쨌든 그것에 책을 계속 추가할 것이다.우리는 정말로 아무도 읽을 수 있는 위키에 "숨겨진" 위키를 꿰매고 싶지 않다.— 건배, 스틸필러 (토크) 08:58, 2021년 5월 20일 (UTC)[응답]
  • 지지하다.이것은 단지 현재 상황을 공식화한 것이다: 이것들은 커뮤니티에 의해 유지되지 않고, 소프트웨어가 작동하지 않으며, 거의 아무도 책을 보지 않는다.현실적으로 이런 것들은 하나도 변하지 않을 것 같다.ub "?!" 13:56, 2021년 5월 23일 (UTC)[응답하라]
  • 지지 비록 이 말을 하는 것이 내게 큰 기쁨을 주지는 않지만, 우리는 포털을 더 이상 사용하지 말았어야 했고, 책들을 더 이상 사용하지 말아야 했다. 네임스페이스의 수를 줄이기 위해서 말이다.– John M Wolfson (대화 • 기여) 14:37, 2021년 5월 23일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

검색 엔진에서 숨기기 위해 책 네임스페이스를 색인화하지 않음

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
페이브리케이터에서 추적됨
과제 T283522
책 네임스페이스를 검색에서 숨기기 위해 no-indexe하는 것에 대한 명확한 합의가 있다.(비관리자 폐쇄) (t · c) 09:23, 2021년 5월 24일 (UTC)[응답]



이는 미디어위키 구성을 변경하여 발생하며 위키백과 책이 검색 결과에 나타나지 않도록 한다.위키피디아의 내부 검색 기능으로 여전히 책에 접근할 수 있을 것이다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

  • 지원 만약 우리가 내부적으로 링크를 숨기려면 우리는 또한 같은 이유로 그들을 검색엔진으로부터 숨겨야 한다.이 콘텐츠는 독자들에게 도움이 되지 않으며 감독 없이 색인된 네임스페이스로 어떤 것을 게시할 수 있는 여지를 남겨둔다.이는 스팸 발송자나 COI 편집자에게 악용될 수 있다. --트리얼피어(토크) 18:27, 2021년 5월 15일(UTC)[응답]
  • 임시로 지원하다.PDF 렌더러가 고정된 경우 인덱싱을 다시 활성화하십시오.헤드폭탄 {t · c · p · b} 18:45, 2021년 5월 15일 (UTC)[응답]
  • 지지 - 최소한 내 의견에 따라 사용불능을 지지한다.레비비치 hound/ 19:22, 2021년 5월 15일 (UTC)[응답]
  • 명목당 지원; 이것은 부정과 함께 진행되어야 한다.{{u Sdkb}} 20:19, 2021년 5월 15일 (UTC)[응답]
  • 위의 모든 것에 대한 지원.비블브록스 (대화) 20:51, 2021년 5월 15일 (UTC)[응답]
  • 특별히 잘 유지되지 않는 철회된 서비스를 위해 네임스페이스를 독자들에게 네임스페이스로 안내하는 것은 의미가 없기 때문에 네임스페이스를 완전히 평가절하할 수 있는 합의가 없는 경우 명목당 지원. 192.76.8.91 (대화) 21:17, 2021년 5월 15일 (UTC)[응답]
  • 검색 엔진에서 그런 페이지에 착륙한 사람들이 다른 사람에게 해를 끼쳤다는 징후가 없기 때문에 반대하라.네모 22:00, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 솔직히, 나는 인터넷을 검색하는 사람들이 이것이 정말 유용하다고 생각하는 것을 보지 않는다.책 네임스페이스로 보낼 주제를 찾는 사람들에게는 도움이 되지 않는 것 같다.이것은 주로 검색 엔진에서 가려져야 한다.호그팜 22:55, 2021년 5월 15일 (UTC)[응답]
  • 지원 이 네임스페이스를 아무도 보지 않고 색인화되면 스팸 발송자 및 기타 SEO(서)를 위한 공개 초대일 뿐이다. -- RoySmith (토크) 00:22, 2021년 5월 16일 (UTC)[응답]
  • 지지하다.—¿philoserf?(토크) 02:10, 2021년 5월 16일 (UTC)[응답]
  • 서포트, 또한 책 네임스페이스를 없애라.아무도 이것을 유지하는 것에 관심이 없는 것 같다.자원봉사자들이 지원하면 언젠가는 부활할 수도 있을 것이다.지금은 사용자 공간에서 계속 진행하십시오.— 알렉시스 재즈 (말하거나 핑)
  • 제시된 증거별 지원. --Izno (대화) 03:27, 2021년 5월 16일 (UTC)[응답]
  • 위의 항목별 지원 - 검색 엔진 방문자가 고장 난 동안 여기에 착륙할 경우 아무런 이점도 없음.사용자::(power~enwiki, π, ν) 03:28, 2021년 5월 16일 (UTC)[응답]
  • 위와 같은 지원.더 나아가야 할 것 같은데(아래 삭제 섹션의 댓글 참조), 이것이 시작일 것이다.ƒirefly (t · c ) 06:49, 2021년 5월 16일 (UTC)[응답]
  • 반대 PediaPress와 WMF/MediaWiki가 제어하는 기술적인 문제인 것 같으니, 이 문제는 우리가 상관할 일이 아니다.편집자나 독자들이 그 설비가 유용하다고 생각하지 않으면, 그들은 그것을 사용할 필요가 없다.Andrew🐉 (대화) 17:29, 2021년 5월 16일 (UTC)[응답]
  • 지지: 위와 같은 나의 추론에 따르면.— 빌로프 (대화) 22:10, 2021년 5월 16일 (UTC)[응답]
  • 위와 같은 지원.에픽푸퍼 (대화) 04:15, 2021년 5월 17일 (UTC)[응답]
  • 위의 섹션에 대한 내 지지에서 내가 (그리고 인용한) 논거에 따라 지지한다.즉, 다양한 이유로 북 네임스페이스는 질 낮은 콘텐츠로 가득 차 있다(유감스럽고 피할 수도 있었다).그러나, 현재 상태로는, 책 네임스페이스를 모두에게 개방하고 여러 곳에 분산시켜 이익을 보고 있다고 생각할 이유가 없다. jpxg 06:20, 2021년 5월 17일 (UTC)[응답하라]
  • 지원의 의미가 있음 — GhostInThe Machine 11:54, 2021년 5월 17일 (UTC)[응답]
  • Dependit it Helse it is after borned nothing, 그것은 그들을 찾는 사용자들을 혼란스럽게 할 것이고 책 애호가들은 어쨌든 그것에 책을 계속 추가할 것이다.우리는 정말로 아무도 읽을 수 있는 위키에 "숨겨진" 위키를 꿰매고 싶지 않다.— 건배, 스틸필러 (토크) 08:58, 2021년 5월 20일 (UTC)[응답]
  • 초기 단계로 지원하십시오.이 페이지들은 유지되는 것이 아니라, 위키백과 이름을 가진 검색 엔진에 있는 그대로 보여주면 안 된다.ub "?!" 13:56, 2021년 5월 23일 (UTC)[응답하라]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

북 작성기에서 북 네임스페이스에 저장하는 옵션 제거

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
페이브리케이터에서 추적됨
과제 T283523
책 네임스페이스에서 책을 만들기 위해 이 도구를 사용하는 옵션을 제거해야 한다는 의견이 일치한다.(비관리자 폐쇄) (t · c) 09:31, 2021년 5월 24일 (UTC)[응답]


이는 mw:에서 문서화한 간단한 MediaWiki 구성 설정을 변경하여 구현된다.확장:컬렉션#책 저장에 대한 사용자 권한.책 네임스페이스는 여전히 편집할 수 있고, 거기서 사용자 공간에서 책을 이동시키거나 위키 텍스트를 사용하여 수동으로 책을 만든 다음 책 크리에이터를 사용할 수 있을 것이다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

  • 지원 이것은 사용자 서적 작성이나 기존 서적 편집에 영향을 미치지 않으면서 새로운 커뮤니티 유지 서적의 창조를 크게 저해하는 좋은 방법이 될 것이다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]
  • 임시로 지원하다.PDF 렌더러가 고정된 경우 다시 활성화하십시오.헤드폭탄 {t · c · p · b} 18:44, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 내 의견에 따라 사용불가능을 지지한다.레비비치 hound/ 19:23, 2021년 5월 15일 (UTC)[응답]
  • 지지, 부정과 함께 해야 할 일로서.{{u Sdkb}} 20:21, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.—¿philoserf?(토크) 02:14, 2021년 5월 16일 (UTC)[응답]
  • 서포트, 또한 책 네임스페이스를 없애라.아무도 이것을 유지하는 것에 관심이 없는 것 같다.자원봉사자들이 지원하면 언젠가는 부활할 수도 있을 것이다.지금은 사용자 공간에서 계속 진행하십시오.— 알렉시스 재즈 (말하거나 핑)
  • 제시된 증거별 지원. --Izno (대화) 03:26, 2021년 5월 16일 (UTC)[응답]
  • 위와 같은 지원.더 나아가야 할 것 같은데(아래 삭제 섹션의 댓글 참조), 이것이 시작일 것이다.ƒirefly (t · c ) 06:50, 2021년 5월 16일 (UTC)[응답]
  • 위의 네임스페이스 사용 중지 제안과 함께 에 대한 지원.– SD0001 (대화) 07:11, 2021년 5월 16일 (UTC)[응답]
  • 지원 책을 사용자 공간으로 제한하는 것이 타당함 - GhostInTheMachine 14:02, 2021년 5월 16일 (UTC)[응답]
  • 반대 PediaPress와 WMF/MediaWiki가 제어하는 기술적인 문제인 것 같으니, 이 문제는 우리가 상관할 일이 아니다.편집자나 독자들이 그 설비가 유용하다고 생각하지 않으면, 그들은 그것을 사용할 필요가 없다.Andrew🐉 (대화) 17:29, 2021년 5월 16일 (UTC)[응답]
  • 지지: 위와 같은 나의 추론에 따르면.— 빌로프 (대화) 22:10, 2021년 5월 16일 (UTC)[응답]
  • 지지하다.감가상각과 함께 말이 된다.에픽푸퍼 (대화) 04:16, 2021년 5월 17일 (UTC)[응답]
  • 네임스페이스를 완전히 제거하기 위한 단계로 지원하십시오.아즈폴리노 (대화) 05:53, 2021년 5월 17일 (UTC)[응답]
  • 책이 도움이 되는 드문 경우에서 유용하다고 증명될 수 있는 도구(대부분 사용되지 않을 가능성이 높지만, 문제를 일으킨다면, 그것이 한 가지가 될 것임)를 제거하면 여전히 창조할 수 있다면 반대한다.— Godsy (TALKCONT) 07:06, 2021년 5월 17일 (UTC)[응답]
  • 다른 사람들을 "방탕"하는 것에 반대하는 것은 혐오스러울 정도로 자기 중심적인 사회 공학이다. 만약 어떤 특징이 바람직하지 않다면, 그것을 없애기 위해 정직해야 한다.그리고 만약 그렇게 하는 것에 대한 합의가 없다면, 당신은 다른 사람들의 눈을 찌르는 것에 대해 전혀 변명의 여지가 없다.— 건배, 스틸필러 (토크) 09:03, 2021년 5월 20일 (UTC)[응답]
  • 지지하다.ub "?!" 13:56, 2021년 5월 23일 (UTC)[응답하라]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

Wiki Project 평가에서 북 클래스에 대한 지원 중단

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
위키프로젝트 평가에서 북 클래스에 대한 지원을 없애고, 관련 카테고리를 삭제하자는 의견이 일치한다.미루는 Reader (대화) 16:57, 2021년 6월 18일 (UTC)[응답]

여기에는 범주에서 범주를 비우고 삭제하는 작업이 포함된다.북클래스 기사 및 관련 템플릿 편집으로 북 네임스페이스를 지원하지 않음. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

  • 지원 현시점에서는 이러한 것들이 목적에 부합하지 않고 이미 역사적으로 표기되어 있다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]
  • 반대 서적은 여전히 존재하며, 이것은 카테고리 클래스를 가지는 것과 다를 바 없다.헤드폭탄 {t · c · p · b} 18:42, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 내 의견에 따라 사용불가능을 지지한다.레비비치 hound/ 19:23, 2021년 5월 15일 (UTC)[응답]
  • 이것들을 뒷받침하는 것은 기사가 아니고, 결코 아니었다.이미 1년 동안 역사로 기록되어 있다.분명히 우리는 이미 이것을 하고 있지 않다. 아마도 그것을 인정하는 편이 나을 것이다.비블브록스 (대화) 20:54, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 더 이상 기능이 없다.호그팜 21:01, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.—¿philoserf?(토크) 02:15, 2021년 5월 16일 (UTC)[응답]
  • 서포트, 또한 책 네임스페이스를 없애라.아무도 이것을 유지하는 것에 관심이 없는 것 같다.자원봉사자들이 지원하면 언젠가는 부활할 수도 있을 것이다.지금은 사용자 공간에서 계속 진행하십시오.— 알렉시스 재즈 (말하거나 핑)
  • 제시된 증거별 지원. --Izno (대화) 03:25, 2021년 5월 16일 (UTC)[응답]
  • 서포트 북은 기존 기사의 모음일 뿐이다.그 기사들은 평가해야 할 것들 — GhostIn.The Machine 14:03, 2021년 5월 16일 (UTC)[응답]
  • 반대 PediaPress와 WMF/MediaWiki가 제어하는 기술적인 문제인 것 같으니, 이 문제는 우리가 상관할 일이 아니다.편집자나 독자들이 그 설비가 유용하다고 생각하지 않으면, 그들은 그것을 사용할 필요가 없다.Andrew🐉 (대화) 17:30, 2021년 5월 16일 (UTC)[응답]
  • 책 네임스페이스가 유지되는 것을 조건으로 반대:만약 우리가 책을 완전히 없애지 않는다면, 이것이 어떤 실질적인 이익을 가져다 줄지는 잘 모르겠다.이 북클래스 전횡을 유지하는 데 많은 시간이 소요되고 있는가?그리고 왜 위키프로젝트 개개인이 어떻게 사물을 유지하는지를 통제하는 것이 우리의 관할권인가?내가 이해한 바로는, 더 넓은 커뮤니티가 정말로 우리를 저지하기 위한 전세계적인 합의를 확립하지 않는 한, 위키프로젝트 I는 (네임스페이스와 무관하게) 각 페이지가 얼마나 "잘 소싱", "잘 쓰여", "잘 설명되어 있는지"를 측정하는 3개의 독립된 4개의 평가 척도에서 64개의 다른 등급으로 평가 척도를 시작할 수 있다.— 빌로프 (대화) 22:10, 2021년 5월 16일 (UTC)[응답]
  • 위와 같은 경우.에픽푸퍼 (대화) 04:16, 2021년 5월 17일 (UTC)[응답]
  • 책 네임스페이스를 제거한 결과 지원.다른 방법으로는 의미가 없어.아즈폴리노 (대화) 05:53, 2021년 5월 17일 (UTC)[응답]
  • 반대 이것들은 주어진 주제에 있는 기사의 총 점수를 평가하는 데 유용하다.Dobbyelf62 (대화) 23:25 (UTC) 2021년 5월 18일 (화)[응답]
  • 반대한다. 많은 책들은 순탄하고, 몇몇 책들은 다른 것들에 대해 가치가 있다.어느 것이 어느 것인지 아는 것은 실제로 유용하다.— 건배, 스틸필러 (토크) 09:11, 2021년 5월 20일 (UTC)[응답]
    스틸필로, 이 "평가"는 책을 질적으로 분류하는 것이 아니라 주제별로 분류하는 것이다.도서 품질 평가(사용자:사이버봇 I/Book Reports)는 위키프로젝트 평가와 무관해 보인다.—쿠스마 (t·c) 10:26, 2021년 5월 20일 (UTC)[응답]
    알았어, 자세한 건 업데이트했지만 원칙은 바뀌지 않았어.— 건배, 스틸필러 (토크) 12시 5분, 2021년 5월 20일 (UTC)[응답]
  • 이 일에 중립을 두어라.나는 책이 가야 한다고 생각하지만, 만약 책이 보관되어 있다면 위키프로젝트가 다르게 느끼지 않는 한 평가를 유지하는 것이 타당하다.도서를 모두 삭제하면 C1에 따른 신속한 삭제를 받을 수 있으며, 템플릿에 필요한 조정이 가능하다.어느 쪽이든 지금은 아무런 조치가 필요하지 않다.ub "?!" 13:56, 2021년 5월 23일 (UTC)[응답하라]
  • 헤드밤당, 도비엘프62, 스틸필로우에 반대한다.아래 섹션의 내 !투표 및 의견을 참조하십시오.충심으로, 역사 DMZ 16:17, 2021년 5월 28일 (UTC)[응답]
  • 위와 같은 지원.–Freddie™ 19:05, 2021년 5월 30일(UTC)[응답]
  • 위의 모든 것에 대한 지원.UnitedStatesian (대화) 01:30, 2021년 6월 1일 (UTC)[응답]
  • 위와 같이 지원한다.마이클 매그스 (대화) 09:04, 2021년 6월 1일 (UTC)[응답]
  • 지원 모든 위키피디아 대상자가 감가상각된 네임스페이스를 추적하는 데는 실질적인 포인트가 없다.Terasail[✉] 10:59, 2021년 6월 1일 (UTC)[응답]
  • 질문: 당신은 그들이 N/A급이어야 한다는 것을 의미하는가, 아니면 책에 있는 위키프로젝트 배너를 완전히 제거해야 한다는 것인가?-조크 판 히스 (대화) 12시 12분, 2021년 6월 4일 (UTC)[응답하라]
  • 책으로서의 지원은 더 이상 기능하거나 유용하지 않다. --SilverTiger12 (대화) 22:15, 2021년 6월 5일 (UTC)[응답]
  • 이거 받쳐줘.나는 대부분의 경우 이 클래스가 2010년 개별 위키프로젝트에 협의 없이 강제적으로 적용되었다는 것을 유의할 것이다. Book=yes각 프로젝트의 사용자 지정 클래스 마스크.기술적으로, 이것은 제거하기 위해 봇이 필요하다. Book=yes각 클래스 하위 플레이트에서.나는 위키프로젝트가 이 (또는 다른) 클래스를 계속 지원하도록 현지 결정을 지지할 것이지만, 그것은 프로젝트에 의한 현지 논의가 필요할 것이라고 덧붙인다.— 마틴 (MSGJ · 토크) 10:29, 2021년 6월 10일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

책 네임스페이스 내의 모든 책 삭제

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
책 네임스페이스를 삭제하는 데 의견이 일치한다.책을 사용자 공간에 저장하는 것은 여전히 가능할 것이다.전반적으로 참여 편집자들의 정서는 이 개념은 실패한 실험이며 이제는 손을 놓아야 할 때라는 것이었다.일부 편집자들은 기능성을 제거하기보다는 수정해야 한다고 반대했고, 다른 편집자들은 기능성에 개발자원이 할당될 현실적인 전망이 없으며, 다른 문제들도 개발자 시간을 더 잘 활용할 수 있을 것이라고 생각했다.
편집자들은 현재 이 네임스페이스에 있는 책에 접근하는 것이 여전히 가능해야 한다고 생각했다.이를 달성하기 위해 두 가지 옵션이 제시되었다: WP 기능:요청 시 환불 페이지 및 북 네임스페이스의 페이지를 다른 네임스페이스로 이동하여 보관하십시오.이견이 있을 경우 추가 논의에 부칠 수 있지만 첫 번째 접근법은 만족스럽다는 대략적인 공감대가 있는 것으로 보인다.삭제 경로를 취할 경우 관리자가 WP에 대응하여 삭제된 페이지의 복사본을 제공할 수 있도록 네임스페이스와 해당 페이지를 삭제하기 전에 조치를 취해야 한다.환불 요청.미루는 Reader (대화) 16:57, 2021년 6월 18일 (UTC)[응답]

WP:사용자 공간에 대한 리펀드가 가능할 것이다.모든 책을 삭제할 경우 개발자가 적절하다고 판단될 경우 네임스페이스를 제거해야 한다.이렇게 하면 Special(특수)과 같은 위치)의 네임스페이스 목록에서 제거된다.검색 및 특수:최근 - 책 - 소설과 같은 페이지를 올바른 제목으로 변경 및 허용특수:책은 정상적으로 계속 작동할 것이고 사용자 공간에 책을 저장하는 것은 여전히 가능하다.PediaPress는 그들의 구현에 따라 가능한 카탈로그를 제외하고 계속 작업할 것이다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]

  • 중립 네임스페이스에 대해 다시는 걱정하지 않아도 되고, 반달리즘이 몇 달 동안 머무르거나 부적절한 페이지를 위한 안전한 항구를 포함하는 네임스페이스의 가능성을 제거하면 좋을 것이다.그러나 소수의 사용자에게는 이러한 페이지 중 일부에서 0이 아닌 값이 있다.이전의 링크가 여기의 제안과 결합되어 숨어 있는 것은 (대부분의 noindexing) 사람들이 우연히 네임스페이스에 오는 것을 막을 수 있기 때문에 나는 이렇게 놔두어도 괜찮다고 생각한다.우리는 수개월 동안 적은 양의 공공 기물 파손 행위가 여전히 행해지고 있지만, 소수의 견해만으로 한 페이지에 있는 기물 파손 행위는 그렇게 나쁘지 않다. --Trialpears (대화) 18:27, 2021년 5월 15일 (UTC)[응답]
  • 지원 이러한 제안 각각은 네임스페이스를 제2의 사용자 네임스페이스처럼 점점 더 많이 만들고 있으며 작동 중인 네임스페이스를 점점 더 적게 만들고 있다.이들 각각이 시행되면 책 네임스페이스에 있는 책과 사용자 네임스페이스에 있는 책 사이에는 의미 있는 차이가 없으므로 따로 둘 이유가 없다.그러나 나는 책을 삭제하는 것보다 아직 창작자가 활동적인 책을 사용자들에게 추천하고 싶다.이것은 위의 모든 제안들을 무효로 만들기 때문에, 나는 다른 어떤 섹션에서도 논평하지 않는다 * Papery * 18:36, 15 2021년 5월 15일 (UTC)[응답]
  • 반대 이것은 소프트웨어 문제에 대한 과잉 반응이다.해결책은 아기를 버리는 것이 아니라 소프트웨어를 고치는 것이다.헤드폭탄 {t · c · p · b} 18:41, 2021년 5월 15일 (UTC)[응답]
  • 반대한다. 제거하기 보다는 고친다.리틀리브 오일 (대화) 18:50, 2021년 5월 15일 (UTC)[응답]
  • 명목당 지원.나는 우리 독자의 99.99%가 책에 대해 모르거나 사용한 적이 있다고 확신한다.아마 우연히 클릭했을지도 모르는 사람들 대부분이...우리는 정말로 절박한 0.01%를 위해 이미 옵션(PDF & 인쇄 가능 버전)과 타사 옵션을 내장하고 있다.아자24 (대화) 19:24, 2021년 5월 15일 (UTC)[응답]
  • 지원 - 내 의견에 따라 사용불가능을 지지한다.사용자 정의(Userfication)는, 현실적으로, 삭제의 대안으로 타당하다.레비비치 hound/ 19:25, 2021년 5월 15일 (UTC)[응답]
  • 유목민, Aza24, Ppery당 지원.— 체드 (대화) 20:06, 2021년 5월 15일 (UTC)[응답]
  • 사용자화 지원, PPERY당.{{u Sdkb}} 20:25, 2021년 5월 15일 (UTC)[응답]
  • 첫 번째 옵션으로서의 지원 - 나는 소프트웨어가 곧 기능할 것으로 보지 않으며 개인적으로 개발자 시간을 다른 곳에서 보내는 것이 더 나을 수 있다고 생각한다.이와 같이 네임스페이스를 주위에 유지하는 것은 의미가 없다.ƒirefly (t · c ) 20:28, 2021년 5월 15일 (UTC)[응답]
  • 이 프로젝트의 역사를 뒷받침하는 것은 공정한 기회가 주어졌고 결국 잘 풀리지 않은 아이디어들로 가득 차 있다.아무도 도움이 되지 않는다고 생각되는 소외되고 버려진 프로젝트의 모든 소프트웨어 문제를 마법처럼 고치려 하지 않을 것이다.지역사회와 직원 모두에게 훨씬 더 중요하고 실제로 유용한 일들이 있다.분명한 건 인정하자, 이건 끝났어.정말 원하는 사람들은 여전히 사용자 공간에 그것들을 가질 수 있다.비블브록스 (대화) 21:01, 2021년 5월 15일 (UTC)[응답]
  • 반대 - 위키백과:피쳐링되고 좋은 주제 후보/공천 절차는 피쳐링된 주제와 좋은 주제를 선정하는 과정의 일부로 책을 만들도록 지시한다.일부 책들은 특집과 좋은 주제를 통해 역사적 가치를 지니게 될 것이다.많은 것들이 쓸모없지만, 나는 모든 것을 포괄적으로 삭제하는 것이 특별히 좋은 단계는 아니라고 생각한다.호그팜 21:04, 2021년 5월 15일 (UTC)[응답]
  • 일종의 지원 - 책을 완전히 삭제하는 것보다는 원작자의 사용자 공간으로 옮기는 것이 좋을 것 같지만, 백과사전이 있다면 '커뮤니티 유지' 섹션에 직면해 있는 대중으로부터 삭제하는 것에 동의한다. 192.76.8.91 (토크) 21:23, 2021년 5월 15일 (UTC)[응답]
  • "책"은 적절한 소프트웨어와 완벽하게 작동하는 링크 모음일 뿐이기 때문에 반대한다.사용자들은 키위닉스나 페디아프레스와 같은 그들만의 파생상품을 생산하기 위해 여전히 그것들을 사용할 수 있다.네모 22:00, 2021년 5월 15일 (UTC)[응답]
  • 명목과 반딧불이를 지지하십시오.고그 더 마일드 (대화) 22:02, 2021년 5월 15일 (UTC)[응답하라]
  • 반대하라, 역사를 숨기지 말라.최소한 봇이 위키백과의 하위 페이지로 모든 것을 옮기도록 하십시오.주요 주제에 대한 연결을 계속 이해할 수 있도록 책/기존/또는 기타 정보.—쿠스마 (t·c) 22:32, 2021년 5월 15일 (UTC)[응답]
    • ? 피처링되고 좋은 주제는 책과 거의 연결되지 않는다. 그것들은 주제 상자 자체보다 더 많은 연결점을 제공하지 않는다.그것들은 심지어 주제상자에도 표시되지 않는다.Aza24 (대화) 22:44, 2021년 5월 15일 (UTC)[응답]
      • 나는 아직도 이것들 중 몇몇은 역사적 가치가 있을지도 모른다고 생각한다.과반수가 아니라 일부다.나는 네임스페이스 전체를 무차별적으로 누크하는 것이 여기서 도움이 될 것이라고 생각하지 않는다.나는 이것들의 대부분을 삭제하는 것을 지지하지만, 이러한 방법들 중 일부는 역사적으로 유용할 수 있고 삭제하기 전에 더 많은 주의가 필요하기 때문에 포괄적 접근법이 최선의 방법이라고 확신할 수 없다.호그팜 22:58, 2021년 5월 15일 (UTC)[응답]
      • 아자24, 그들은 그리 멀지 않은 과거에 있었다. [4] 모든 수단을 동원해서 해를 끼치는 사람들을 삭제하되, 더 이상 "유용하지 않다"고 해서 모든 것을 삭제하지는 말라.—쿠스마 (t·c) 23:03, 2021년 5월 15일 (UTC)[응답]
    • 나는 모든 주제들이 관련 책을 가지고 있는 것은 아니라는 것을 주목할 필요가 있다고 생각한다.~20개 랜덤 토픽을 반 이상만 확인해도 1개가 있었다. --Trialpears (토크) 23:30, 2021년 5월 15일 (UTC)[응답]
  • 위와 같은 지원.~ HAL333 23:56, 2021년 5월 15일 (UTC)[응답]
  • 지지하다.그 특색은 이미 죽어서 오래 전부터 있어 왔다.파운데이션 개발은 그들이 고치지 않고 있는 다른 버그들의 엄청난 밀수를 가지고 있고, 그들이 곧 이것을 시작할 것이라고 믿을 이유가 없다.개발 시간은 어쨌든 다른 곳에서 제공하는 것이 좋다. --곤니름(토크) 00:00, 2021년 5월 16일 (UTC)[응답]
  • 지원 삭제 기능은 지원되지 않으며, 지원이 제대로 된 적이 없으며, 소프트웨어와 자원봉사 커뮤니티 조직 둘 다 지원할 계획이 없다.나는 과거에 책을 만들었고 나중에 그 과정이 실망스럽다고 느꼈다.위키피디아의 선택사항이었기 때문에, 나는 그것이 유용하다고 생각했다. 사실, 그 과정은 아무런 지원을 받지 못하고, 다른 유용한 기능들의 도구 모음의 일부가 아니며, 내가 기대했던 이익을 주지 않는다.누군가가 현존하는 활발한 도서 개발 및 유지 관리 커뮤니티의 증거를 보여주지 않는 한, 그리고 이 도구의 개발에 위키미디어 재단의 재정 투자를 위해 진지한 위키미디어 커뮤니티의 요청을 할 계획이 없다면, 나는 존재하는 것을 삭제하고 그 옵션을 없애라고 말함으로써 다른 누군가를 더 많은 우리로부터 주의를 돌리지 않도록 해야 한다.유용하고 지원되는 도구지원되지 않는 도구를 주변에 보관하는 것은 이점이 아니다.책은 위키다타에서 기사의 목록을 공유하여 보고서를 실행하거나, 책으로 인쇄하거나, 언어에 걸쳐 중요한 기사의 번역을 조정하는 일종의 도구로 재탄생될 수 있는 것으로 알고 있다.위키다타 대신 위키피디아에 이것을 넣음으로써 기계 가독성 혜택은 없다. 블루 라스베리 (토크) 00:06, 2021년 5월 16일 (UTC)[응답]
  • Meh와 일종의 기대는 반대하지만, 대량 사용자화는 괜찮다.이것들은 이미 우연히 발견하기 매우 어려우며, 만약 현재 추세대로 위의 제안들이 이루어진다면 그것은 근본적으로 불가능해질 것이다.기본적으로 이것들은 어디에도 마주할 수 없지만, 역사를 숨기면 얻을 필요도 없고 얻을 것도 없다.만약 사람들이 여분의 네임스페이스가 없다면 사물이 더 깔끔해질 것이라고 느낀다면, 사용자들을 확실히 이용하게 할 것이다. 하지만 일단 이것들이 더 이상 흔들릴 수 없는 단계들이 되면, 그들이 삭제하거나, 사용자들을 이용하는 것 등은 구별할 수 없는 이익을 위한 추가 작업처럼 들린다.관련, 31.41.45.190 (대화) 01:38, 2021년 5월 16일 (UTC)[응답]
  • 메, 또한 책 네임스페이스를 없애라.아무도 이것을 유지하는 것에 관심이 없는 것 같다.자원봉사자들이 지원하면 언젠가는 부활할 수도 있을 것이다.지금은 사용자 공간에서 계속 진행하십시오.대량 사용자 정의가작동해야 한다.명백한 쓰레기인 어떤 "책"도 삭제될 수 있다.— 알렉시스 재즈 (말하거나 핑)
  • 현재로서는 반대 - 네임스페이스가 더 이상 사용되지 않는 경우 내년에 하는 것이 좋을 수 있다.지금 당장 하는 것은 너무 이르다.사용자::(power~enwiki, π, ν) 03:21, 2021년 5월 16일 (UTC)[응답]
  • 제시된 증거가 있는 경우 네임스페이스를 제거하는 최종 목표를 지지하십시오.책을 삭제해야 한다고 생각하지만, 아마도 환불은 실제로 이루어질 수 있도록 네임스페이스 밖으로 옮겨진 후에만 가능할 것이다. --Izno (대화) 03:23, 2021년 5월 16일 (UTC)[응답]
  • 지원 – 이 기능은 지원되지 않으며, 작동에 필요한 시간을 할애하는 타당한 이유가 없다.버려진 폐허처럼 이런 난장판을 방치해서는 안 된다.나는 'Book' 네임스페이스가 매우 오랫동안 존재하며 죽어온 현실을 단순히 대변할 수 있는 삭제를 지지한다.RGlucester — 인터뷰 04:10, 2021년 5월 16일 (UTC)[응답]
  • 네임스페이스 제거의 최종 목표를 지원하십시오.그러나 호그팜과 쿠스마당 역사를 보존하기 위해서는 이것들을 '아카이빙'해 '위키피디아:'의 서브 페이지와 같은 곳으로 옮기는 것이 좋다.책/구/" 또는 기타.– SD0001 (대화) 07:44, 2021년 5월 16일 (UTC)[응답]
  • 참고: 실제 삭제되기 전에, 모든 이해당사자에게 통지할 수 있도록 모든 페이지에 태그를 올바르게 부착해야 한다.삭제 통지는 문짝에 표범 조심하라는 팻말이 붙은 불용화장실에 갇힌 잠긴 서류 캐비닛 바닥에 있어서는 안 된다.(WP를 써야 할지 고민 중)레오파드 에세이).—쿠스마 (t·c) 08:40, 2021년 5월 16일 (UTC)[응답]
    쿠스마 물론이지거의 천 개의 카테고리를 원하시겠죠?Book-Class 기사에도 태그가 붙었는가?WP:CENT와 마을 펌프는 대부분 한 달도 볼 수 없는 책들이 있는 동안 사용하지 않는 화장실 안에 갇혀 있는 파일 캐비닛의 바닥에 있지 않다. --Trialpears (토크) 09:23, 2021년 5월 16일 (UTC)[응답]
    네임스페이스 감지 기능이 있는 {{Saved book}에 추가하면 충분할까?그렇게 하면 불필요한 편집이 12k 정도 절약된다. --Trialpears (토크) 09:33, 2021년 5월 16일 (UTC)[응답]
    시험관, 이상적으로는 책 네임스페이스를 원래 있던 곳으로 다시 이동시킬 뿐이다(Wikipedia 하위 페이지:책), 그러면 사람들에게 알리는 것을 피할 수 있을 것이다. (캐주얼 유저들에게는 그들의 토크 페이지와 워치리스트 이외의 어떤 것도 알파 센타우리에 있을 수 있다고 생각한다.)—쿠스마 (t·c) 09:56, 2021년 5월 16일 (UTC)[응답]
    이제 템플릿 {{Saved book}}, {{Category class}}을(를) 통해 사용자 정의 삭제 알림을 추가했다. --Trialpears(토크) 19:48, 2021년 5월 16일(UTC)[응답]
  • 이해관계자(예: 책의 창안자)에 대한 적절한 경고와 함께 지원.이 실패한 실험은 그냥 끝냅시다.리마고서 (대화) 11시 45분, 2021년 5월 16일 (UTC)[응답]
  • 반대 이것은 약간 극단적이다. 나는 네임스페이스를 삭제하는 것을 지지하지만, 네임스페이스를 삭제하는 것은 아니다.Jackattack1597 (대화) 13:04, 2021년 5월 16일 (UTC)[응답]
  • 서적을 개별적으로 WP를 거치지 않고 네임스페이스를 삭제하기 전에 일반 사용자가 액세스할 수 있는 위치에 모두 능동적으로 보관할 수 있는 경우:삭제 후 환불 처리.나는 그것들을 보존하는 데 있어서 많은 가치를 보지 못하지만, 다른 모든 것들은 평등하기 때문에 역사를 지우지 않는 것이 좋다.콜린 M (토크) 13:50, 2021년 5월 16일 (UTC)[응답]
  • 코멘트 이것은 이 RfC에서 유일하게 중요한 결정이며, 그것은 다른 사람들이 영구히 저지르고 있는 천 컷의 죽음의 종말점이다.어떻게 해서든 그냥 해나가자.어느 쪽으로 가든지 간에 우리는 이니셔티브를 부활시킬 것인지 아니면 죽일 것인지에 대해 투표하고 있다는 것을 받아들여야 한다.— 건배, 스틸필러 (토크) 14:20, 2021년 5월 16일 (UTC)[응답]
    그 후에 당신은 그것이 효과가 없더라도 "유용하다"는 이유로 반대한다."그걸 계속하자" 정말이지.이즈노 (대화) 15:47, 2021년 5월 16일 (UTC)[응답]
    @Izno:왜 그렇게 으르렁거리지?내가 널 화나게 했니?달, 필요할 때 차 템플릿은 어디 있어?— 건배, 스틸필러 (토크) 15:13, 2021년 5월 18일 (UTC)[응답]
    "그냥 시작하자"고 말하는 것이 스나큰 소리가 아니란 말인가? :) 이즈노 (대화) 19:52, 2021년 5월 18일 (UTC)[응답]
  • 반대 나는 책의 특징이 유용하다고 생각한다; 나는 그것이 예전처럼 잘 작동한다면 그것을 더 많이 사용할 것이다.나는 그것을 잃어버리면 슬플 것이다.— 건배, 스틸필러 (토크) 14:20, 2021년 5월 16일 (UTC)[응답]
  • 지금은 너무 많이 반대하라.기술의 미래가 확실할 때 다시 방문하십시오.우리는 현재 사용자 공간에 5만1,546권의 책을 보유하고 있고 북 스페이스에는 6,198권밖에 없기 때문에 북 스페이스에 있는 모든 책을 "그냥"으로 만든 사용자의 하위 페이지로 옮긴다.— GhostIn에서 추가한 서명되지 않은 이전 설명TheMachine (대화 • 기여)
    미래는 분명하다: 기술은 죽었고 현 시점에서 부활하지 않을 것이다. --Izno (대화) 15:46, 2021년 5월 16일 (UTC)[응답]
    우리는 아마 다른 것들에 대해 이야기하고 있을 것이다.기사를 수집하는 기계는 내가 시도했을 때 작동했다.이 기사 목록을 PDF로 변환하는 기기는 내가 시도했을 때 작동했다.여기서 문제는 책 네임스페이스 안에 있는 모든 책을 삭제해야 하고, 나는 우리가 그것들을 옮겨야 한다고 생각한다.일단 네임스페이스가 비어있으면, 우리는 네임스페이스를 끌 수 있는 옵션을 가지고 있다 - GhostInThe Machine 11:52, 2021년 5월 17일 (UTC)[응답]
  • 반대 PediaPress와 WMF/MediaWiki가 제어하는 기술적인 문제인 것 같으니, 이 문제는 우리가 상관할 일이 아니다.편집자나 독자들이 그 설비가 유용하다고 생각하지 않으면, 그들은 그것을 사용할 필요가 없다.Andrew🐉 (대화) 17:30, 2021년 5월 16일 (UTC)[응답]
    나는 어떠한 법적 계약도 없었다고 생각하지 않는다-양쪽 모두 그것에 대해너무 즉석에서 행동해왔다.게다가, WMF가 우리에게 말하지 않고 서명하거나 하지 않은 것은 우리와 아무 상관이 없다 - 행동 강령 등에 그런 것에 대한 언급은 없다.만약 WMF가 갑자기 "오, 쉬!"를 깨우고 그들의 곡조를 바꾼다면, 그것은 우리의 문제가 아닐 것이다.— 건배, 스틸필러 (토크) 17:43, 2021년 5월 16일 (UTC)[응답]
    내가 무언가 크게 오해하고 있는 것이 아니라면, WMF와 페디아프레스 사이의 어떤 계약도 우리가 엔위키에 특정한 네임스페이스를 가지고 있는지 여부와는 전혀 관계가 없으며, 그것이 몇 년 동안 제대로 작동하지 않았다는 점을 감안할 때 우리가 그 기능을 비난하기로 선택했는지에도 전혀 관계가 없다.ƒirefly (t · c ) 17:44, 2021년 5월 16일 (UTC)[응답]
  • 서두르지 않고 지원—컨텐츠의 용도를 변경하고자 하는 모든 사용자에게 충분한 창구를 제공하고, 그 후한 기간이 끝날 때 삭제할 수 있도록 한다.자르 18:27, 2021년 5월 16일(UTC)[응답]
  • 위의 Iznos 논평에 자극받아 나는 교육 프로그램 네임스페이스를 일시적으로 제거했을 때 무슨 일이 일어났는지 알아보았다.네임스페이스가 제거된 동안 페이지에 액세스하거나 삭제 취소하는 것은 불가능했다(관리자조차도).이를 피하려면 모든 책을 위키백과로 옮겨야 한다.이번에는 이러한 기술적 문제를 피하기 위해 삭제 전 책 네임스페이스. --Trialpears (대화) 21:41, 16 2021년 5월 16일 (UTC)[응답]
  • 강력한 지지: 위와 같은 나의 추리에 따르면.우리는 그 문제를 근원적으로 해결해야 한다.환불 프로세스 또는 네임스페이스 보관 파일(다른 Wiki에 저장하시겠습니까?가이드라인 페이지에 있는 위키피디아의 일부 포크를 향한 고개만 끄덕여도?) 개인적으로 도움이 되는 활동을 위해 네임스페이스를 사용해 온 개인들을 위해 이루어져야 한다.—당신이 작업한 내용을 삭제하고 싶지는 않지만, 독자를 대면하는 콘텐츠로 방송하고 싶지는 않다.— 빌로프 (대화) 22:10, 2021년 5월 16일 (UTC)[응답]
  • 영국 위키백과 m:역사를 유지하라.이것들 중 많은 것들이 유용하고 우리는 그것들을 쉽게 수용할 수 있는 WMF 프로젝트를 가지고 있다.우리는 그것들을 삭제하지 말아야 하며 누군가가 새로운 노력을 시작하기 전에 우리의 죽은 이름자리를 파기로 결정하기를 바란다.대신 다음과 같이 콘텐츠를 적절한 위치로 이동해야 한다.위키북스.— Wug·a·po·des 23:03, 2021년 5월 16일(UTC)[답글]
    워가포드는 정말 먹히지 않을거야책 네임스페이스에 있는 책들은 위키북과 같은 종류의 책들이 아니다.Wikibooks는 Wikibooks에서도 이러한 종류의 책을 포함하고 있다.Wikibooks:위키북스는 이 책들로 구성된 위키백과 기사를 포함하지 않기 때문에 그들은 작동하지 않을 것이다.만약 이것이 이루어진다면 그들은 문자 그대로 쓸모없는 레드 링크의 리스트가 될 것이다.Wikibooks가 그것을 원할 것이라고는 상상할 수 없다. --Trialpears (대화) 23:13, 2021년 5월 16일 (UTC)[응답]
    아 그래서 나는 소프트웨어가 어떻게 작동하는지 혼란스러웠다.책 네임스페이스가 프로그램의 출력을 가지고 있다고 생각했는데(내가 네임스페이스를 얼마나 사용하는지 알 수 있다) 그래, 그 책들을 훑어보면 우리가 모든 기사들을 복사하지 않는 한 위키북에게는 대부분 쓸모없을 것이다. 이것은 좋지 않은 생각이다.내 코멘트를 받았다.나는 그 내용이 미래에 복구될 수 있는 한 무엇이든지 상관없다.— Wug·a·po·des 23:44, 2021년 5월 16일 (UTC)[응답]
    나는 ns라는 책이 항상 무의미할 것이라고 생각한다.그런데 왜 관련 기사들은 여기에 머물지 못하고 연계는 쉽게 바꿀 수 있을까? -킬라네 (C•T•U) 17:35, 2021년 5월 18일 (UTC)[응답]
    북 크리에이터는 모두 같은 위키 안에 있는 페이지에서 작업하도록 설계되었으며, 책을 만들거나 편집할 때 페이지 상단에 배너를 추가하여 사용자가 탐색할 때 책에 기사를 추가하는 데 사용할 수 있다.크로스 위키 링크와 잘 어울릴지는 모르겠지만, 정말로 그런 식으로 사용되도록 의도된 것은 아니다.또한, 책 네임스페이스는 쓰레기 투성이고, 나는 그들이 그것을 보존하고 우리를 위해 그것을 유지하거나 가치 있는 것으로 만들어야 한다는 기대감으로 우리의 쓰레기를 다른 위키에 버리는 것을 강력히 반대한다.위키북이 책을 원할 것인가?블락팩트: 제4.5권, "키 작은 흑인"에 관한 섹션으로 시작하는 것은?'동행서'는 어때?블락팩스 12권, 말 그대로 누가 꼽은 아프리카인의 명단인가?책을 읽을 사람?미국 홀로코스트는 미국 들소의 멸종에 대한 50%, 원주민의 식민화와 억압에 대한 50%인가?위키북이 책을 원할 것인가?해적1 우주론/해적/sci-fi 장르의 세계 최초?Book은 어때?"현재의 정치체제에 대한 유효한 대안"을 나열하는 "정치적 대안"은 사회주의에 관한 기사들과 연관되어 있다.책을 읽을 사람이 있는가?보석류 및 보석류(Gemology and Georney)는 보석류 관련 모호한 모든 것을 포함한 500여 편의 기사를 수록한 책이다.영국의 고대 기념물 영국의 고대 기념물에 관한 350개의 긴 글이다.Book의 기사를 선택하기 위해 사용된 포함 기준:핵심 전기(A-D)들, 그것은 단지 몇몇 독자들이 좋아하는 기사들의 목록인가?2012년에 특집 기사가 실린 나라들을 담은 책을 원하십니까?걱정하지마 책:주요 국가 기사를 다루십시오.위에서 역사책을 찾아본 경험을 통해 이미 이야기했지만, 네임스페이스의 대다수는 '사회가 유지된다'고 독자들에게 제시해서는 안 될 버려진 개인 프로젝트들이다.만약 그들이 계속 유지된다면, 그들을 원래 제작자의 사용자 공간으로 사용하는 것이 아마도 그들을 다루는 가장 좋은 방법일 것이다. 192.76.8.73 (대화) 22:00, 2021년 5월 18일 (UTC)[응답]
  • 명목별 지원 및 위의 확대 토론.에픽푸퍼 (대화) 04:17, 2021년 5월 17일 (UTC)[응답]
  • 요청한 자료를 환불할 수 있는 경로가 있다면 지원하십시오.아즈폴리노 (대화) 05:53, 2021년 5월 17일 (UTC)[응답]
  • 반대한다. 책 네임스페이스가 쓰레기로 가득 찬 이유는 책이 나쁜 생각이기 때문이 아니라, 역사적 요인의 유물이기 때문이다.더 이상 형편없는 책들이 쏟아져 들어오지 않는다면(즉, 쉽게 만들 수 있도록 기능을 무력화시키는 것) 정리해서 좋은 책들을 쓰기가 쉬울 것 같다.jpxg 06:30, 2021년 5월 17일 (UTC)[응답]
  • 반대 - 그들을 공공장소에서 가려낼 이유가 없다.특정 형태의 검색엔진에서 색인화 및 제거는 적절하다.— Godsy (TALKCONT) 07:02, 2021년 5월 17일 (UTC)[응답]
  • 지원 또는 페이지를 모두 삭제하는 대신 Wikibooks로 이동하는 것은? -Killarne(C•T•U) 17:25, 2021년 5월 18일(UTC)[응답]
    몇 가지 의견을 제시한 동일한 제안을 한 Wugapodes에 대한 응답을 참조하십시오.* 삐삐 * 17:28, 2021년 5월 18일 (UTC)[응답]
  • 반대 나는 종종 특정 주제에 대한 변경사항을 추적하기 위해 책 탭을 사용한다.난 워치리스트보다 이걸 훨씬 더 많이 쓰거든Dobbyelf62 (대화) 23:27 (UTC) 2021년 5월 18일 (화)[응답]
    사용자 공간 책자(이 제안서의 영향을 받지 않을 것) 또는 특수:같은 목적으로 최근 ChangesLinked.* Papery * 02:43, 2021년 5월 19일 (UTC)[응답]
  • 네임스페이스 클러터를 제거할 목적으로 지원하십시오.소수의 제안처럼 다른 네임스페이스의 아카이브 위치로 이동하는 것도 괜찮다.위키백과:책/구. 굼벵이 "?!" 13:56, 2021년 5월 23일 (UTC)[응답]
  • WikiBooks – John M Wolfson (대화 • 기여) 14:42, 2021년 5월 23일 (UTC)[응답]
  • 지원 이 네임스페이스를 사용하는 다른 wiki는?우리만 사용하고 있고, 현재는 더 이상 사용되지 않고 있다.우리는 PDF로 페이지를 다운받을 수 있고, 이미 다른 책 위키도 있다.사용되지 않는 네임스페이스를 유지하는 이유나는 책 네임스페이스의 모든 페이지를 삭제하고 네임스페이스를 블랙리스트에 올리는 것이 한 가지 가능성이라고 생각한다.네임스페이스를 삭제하는 것보다 훨씬 쉬울 겁니다.이 네임스페이스의 모든 페이지가 삭제되면 북 ns에서 편집한 페이지를 모두 환불하고, 북토크 ns에서도 삭제된 페이지를 환불하십시오. 54nd60x(토크) 03:03, 2021년 5월 25일(UTC)[응답]
  • 반대 위키백과:책은 매우 유용하며, 백과사전의 다른 곳에서는 할 수 없는 능률적이고 *접근 가능한* 방식으로 기사와 정보를 논리적으로 분류하고 통합한다.PDF 버전으로 다운로드하는 기능과 같은 중요한 서비스에 대한 빠른 링크를 독자들에게 제공한다(책: 참고:예를 들면 제인 오스틴이다.또한 Book_talk 페이지에는 Template과 같은 중요한 추적 도구가 함께 제공된다.각 책에 수록된 각 기사의 모든 현황(정리, 비자유 매체 등)을 한눈에 볼 수 있는 북리포트.템플릿에서 "표시"를 클릭하여 전체 기능을 확인하고 "책상"를 참조하십시오.제인 오스틴을 예로 들 수 있다.당신이 적용하기 위해 어떤 기술적 조치나 해결책을 선택하든, 우리의 멋진 위키백과 책들을 *삭제하지 마십시오*.WP를 기억하십시오.독자. 고마워, 역사 DMZ 15:53, 2021년 5월 28일 (UTC)[응답]
역사적 이유로 반대하다.책들은 대신에 더 이상 사용되지 않고 그대로 놔둬야 한다.타이론 마데라 (대화) 20:13, 2021년 5월 28일 (UTC)[응답]
  • Support deletion 이 실패한 실험을 놓치기 위한 시간.옥나제바드 (대화) 22:20, 2021년 5월 28일 (UTC)[응답하라]
  • 책 창작자들에게 그들의 책을 다운로드 할 수 있는 기회를 준 후 지원하라.–Freddie™ 19:07, 2021년 5월 30일(UTC)[응답]
  • 지지 - 훨씬 더 나은 해결책은 미래에 명백해질 것이다.그때까지 삭제한다.쉬에르베커 (대화) 07:26, 2021년 6월 1일 (UTC)[응답]
  • 지원 - 거의 완전히 사용되지 않고, 결코 사용할 수 없는 것들을 유지하는 것은 무의미하다.마이클 매그스 (대화)
  • 위와 같은 지원. --SilverTiger12 (대화) 22:15, 2021년 6월 5일 (UTC)[응답]
  • 지원 - Favre1fan93 (대화) 13:54, 2021년 6월 8일 (UTC)[응답]
  • 지원 - —¿필로세르프?(토크) 00:34, 2021년 6월 10일 (UTC)[응답]
  • 지원 북 네임스페이스에서 항목을 마주칠 때마다 메인 스페이스의 동일한 항목보다 낫지도 나쁘지도 않다.놀랍게도, 나는 잘 실행되지 않은 템플리트와 실수로 인해 분명히 만들어진 책들을 본다. 그리고 분명히 그들의 창조자를 포함한 그 누구도 사용하지 않는다.주공간에서 내용이 업데이트되면 변경사항이 반드시 책공간으로 전파되지 않아 중복된 풋타임 콘텐츠가 생성된다.책들은 이제 얼마 동안 더 이상 사용되지 않았기 때문에, 논리적인 후속 조치는 아직 북스를 사용하고 있는 모든 사람들을 위해 향후 삭제에 대한 경고를 게시한 다음, 남은 모든 책을 삭제하는 것이다.또한, 오프라인 위키 리더나 위키 수출과 같은 다른 동등한 제품들이 존재하는데, 이것은 북스와 같은 목적을 제공할 수 있다.안톤.버쉬 (대화) 18:33, 2021년 6월 10일 (UTC)[응답]
  • 많은 "지지" 표들이 "나는 나를 위해 아무것도 볼 수 없다"라는 주장에 기초하고 있다.많은 다른 사용자들이 그렇게 하고 있고, 그것을 계속할 수 있도록 허용되어야 한다.만약 주어진 책이 당신을 불쾌하게 한다면, WP:MfD는 당신의 친구라면, 목욕물과 함께 아기를 버릴 필요가 없다.— 건배, 스틸필러 (토크) 20:51, 2021년 6월 12일 (UTC)[응답]
    그건 사실이 아니야.우리는 그것이 정확히 무엇이며 그것은 제시된 데이터에 의해 증명된 실패한 실험의 난장판이다.중요한 편집자 활동이 없는 보통 한 달 동안 대부분의 책들은 단 한 권의 뷰도 얻지 못하고 단지 1.5%의 책만이 하루에 페이지뷰를 받는다.곤니름 (대화) 14:50, 2021년 6월 16일 (UTC)[응답]
  • 반대: 네임스페이스를 삭제하는 대신 보관하는 것이 좋다.SportingFlyer T/C 21:01, 2021년 6월 12일 (UTC)[응답]
  • 지원 네임스페이스가 실패함.더 이상 도움이 되지 않는 많은 비행선 주위에 머물 필요가 없다.캘리오페젠1 (대화) 07:19, 2021년 6월 16일 (UTC)[응답]
  • 지원 - 하지만 나는 모든 책을 적절한 사용자 공간으로 옮길 것이다.아심(토크) 08:40, 2021년 6월 16일 (UTC)[응답]
  • 아무도 신경 안 써.네임스페이스도 사용할 필요가 있다.파이어스타464 (대화) 11시 45분, 2021년 6월 17일 (UTC)[응답]
  • 지원 다시 생각해 보면, 만약 우리가 이미 그것들을 완전히 쓸모없게 만들었다면, 그것들을 삭제하는 것이 나을지도 모른다.하지만 사용자 공간에 대한 환불을 위한 충분한 시간이 있었으면 좋겠다.Jackattack1597 (대화) 18:58, 2021년 6월 17일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

포스트 클로즈

위키백과에서 이것을 어떻게 구현할 것인가에 대한 나의 구체적인 제안으로 작은 후속 논의를 시작했다.마을 펌프(기술)#책 네임스페이스 삭제 시행. --Trialpears (토크) 07:51, 2021년 6월 19일 (UTC)[응답]

참고: 의견 불일치를 어디에 등록해야 할지 잘 모르겠지만, 여기에 넣어야겠어.북 네임스페이스북은 공동체의 노력이었고 다수의 편집자가 있었기 때문에 이것을 위한 사용자 공간은 문제가 있다.책 네임스페이스가 존재하기 전에, 커뮤니티 북은 위키피디아에서 주최되었다.책/후바.이곳이 그들의 휴식처도 있어야 할 곳이다.헤드폭탄 {t · c · p · b} 16:05, 2021년 6월 19일 (UTC)[응답]

@머리폭탄 당신이 동의하지 않는 것이 무엇인지 확실하지 않다.그 폐쇄는 어느 곳에서도 책이 사용자 공간으로 옮겨질 것이라고 말하지 않는다.– SD0001 (대화) 19:51, 2021년 6월 19일 (UTC)[응답]

좋은 기사 및 특집 기사

– 명확한 제안이 없음. 성고템플 (대화) 13:22, 2021년 6월 21일 (UTC)[응답]

부분 블록 메시지를 빨간색 대신 주황색 또는 노란색으로 변경

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.
기술 노트: 이것은 어린이용 디브 박스를 스타일링하는 것에 관한 것이다..mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt특수:사용자가 부분적으로 차단되었을 때 이 텍스트를 표시하는 기여.

가능하면 부분 블록 알림 박스를 빨간색에서 주황색 또는 노란색으로 변경하여 부분 블록과 부분 블록을 구분해야 한다고 생각한다.이것은 혼란을 줄이는 데 도움이 될 것이다. 가장 분명한 것은, 메시지가 "차단된" 것이 아니라 "부분적으로 차단된" 것으로 되어 있다는 것을 알아차리지 못하고 파괴적인 편집자에 대해 조치를 취하지 않는 시스템 운영자들뿐만 아니라, 처음에 문제가 있는 편집자의 보고를 이미 차단된 것처럼 보이면 자제할 수 있는 다른 순찰자들에게도 도움이 될 것이다.이것은 몇 달 전에 제기되었지만, 기술적으로 이런 일을 하는 것이 가능할지도 모른다는 것을 결정하는 것을 넘어서는 실질적인 논의는 없었다.질식 (대화) 03:02, 2021년 6월 1일 (UTC)[응답]

나는 동의해 - 현재 통지는 사이트 차단과 너무 많이 닮았어.이는 특히 범위에서 부분적 차단이 발생할 경우 혼란스럽다.아크로테리온 (대화) 03:10, 2021년 6월 1일 (UTC)[응답]
  • 나도 동의해, 전체 블록과 부분 블록은 더 빠르고 쉽게 구별할 수 있어야 해.—엘 밀로 (대화) 03:39, 2021년 6월 1일 (UTC)[응답]
  • 이것도 지지해줘.— 체드 (대화) 09:18, 2021년 6월 1일 (UTC)[응답]
  • 물론. 꾸물꾸물 읽어주는 사람 (대화) 09:25, 2021년 6월 1일 (UTC)[응답하라]
  • 좋은 생각이야.사실 우리가 알아차리는데 너무 오랜 시간이 걸렸어!——9:44, 2021년 6월 1일 (UTC)[응답]
  • 전적으로 타당해 보이고, 그렇게 하지 않을 실질적인 이유도 없고, 그렇게 하는 많은 좋은 이유들이 있다.반딧불 (t · c ) 10:13, 2021년 6월 1일 (UTC)[응답]
  • 나는 오렌지를 지지한다; 노란색은 보통 더 주의깊게 여겨진다. 331닷 (토크) 10:15, 2021년 6월 1일 (UTC)[응답]
  • {{uw-pblock}}} 또는 그 이상의 것을 말하는 것인가? --Trialpears (토크) 10:18, 2021년 6월 1일 (UTC)[응답]
    별로 안 빨개졌어.당신이 편집하기 위해 사용자 페이지를 열 때 로그 통지가 있다고 가정했다.([5])——10:37, 2021년 6월 1일 (UTC)[응답]
여기 괴짜들을 위한 노트가 있어.특정 상자가 해제되는 내용은 위의 미니 해트를 참조하십시오.
  • @Aspening: 정확히 어떤 템플릿/메시지/etc를 변경하시겠습니까?(부분 블록 알림 상자가 무엇을 가리키는지 전혀 모르겠다.)예를 들어, 최근에 부분적으로 차단된 사용자가 있는데 구체적으로 어떤 항목을 변경하시겠습니까?이것은 컬러 트윗을 만들기 위해 완전한 VPPR 논의를 필요로 하지 않을 수도 있다.— XaosfluxTalk 14:51, 2021년 6월 1일 (UTC)[응답]
    Xaosflux: 질식하는 것은 아마도 이 페이지 상단에 있는 빨간색 상자를 가리키는 것일 것이다.특수:기부금/아이오안네스코 선고드템플 (토크) 14:53, 2021년 6월 1일 (UTC)[응답]
    @Xaosflux: "이 사용자는 현재 부분적으로 차단되어 있다"는 사용자 스페셜:공헌 페이지에 나타나는 상자를 말하는 것이다.위와 같은 나 자신과 다른 사용자들이 나열한 이유에 따라 혼동을 줄이기 위해 부분 블록의 경우 주황색이나 노란색으로 해야 한다고 제안한다. 또한 331닷은 노란색이 더 주의깊다는 좋은 점을 제기하기 때문에 나는 이 상자를 오렌지색으로 하는 쪽으로 더 기울고 있다.질식 (대화) 14:57, 2021년 6월 1일 (UTC)[응답]
    @Aspening: OK, 그래서 그 상자는 클래스로 포장되지만, 그 자체가 "warning box mw-warning-warning-with-loexcerpt mw-content-ltr" 클래스로 구분되어 있다.두 번째 클래스는 common.css의 스타일링을 위해 사용되고 있다.메시지 자체는 MediaWiki:sp-contractions-blocked-notice-partial에서 왔다.따라서 색상 스타일을 조정하는 것이 매우 쉽지는 않지만, 마크업을 메시지에 매우 쉽게 추가할 수 있다(테스트위키 예시 참조).특수:기여/예~테스트위키).그런 식으로 마크업하면 네 걱정을 덜어줄 수 있겠니?— XaosfluxTalk 15:11, 2021년 6월 1일 (UTC)[응답]
    @Xaosflux: 아마도 - 나는 색의 변화가 더 바람직하다고 생각하지만, 그것이 어렵거나 불가능하다면 나는 그런 식으로 부분적인 블록을 강조하는 것이 만족스러울 수 있다고 생각한다.질식 (대화) 15:17, 2021년 6월 1일 (UTC)[응답]
    @Aspening: 나는 적어도 지금은 본문에 강조점을 추가했다.클래스 충돌이 발생하여 기술적 난제에 따라 색칠이 차단될 수 있음mw-warning-with-logexcerpt 아마 다른 누군가가 추악한 해킹이 아닌 기술적인 아이디어를 가지고 있을지도 몰라— XaosfluxTalk 15:29, 2021년 6월 1일 (UTC)[응답]
    어, 그냥 덮어쓰는게 보기 흉한 해킹인가?.mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt {border-color:#fc3;background-color:#fef6e7;} CSS 연습에서는 그게 버보텐이라고 생각하진 않았지만, 난 전문가가 아니야...Writ Keeper 1 15:36, 2021년 6월 1일 (UTC)[응답]
    @Writer 키퍼:나는 단지 "may" :) 그런 것이 통할 수 있다고 말했을 뿐이다.css는 보통에 초특화 스타일을 넣는 것은 이상적이지 않지만, 우리는 이 메시지에 대해 더 할 일이 많지 않기 때문에 아마도 방법이 될 것이다.— XaosfluxTalk 15:47, 2021년 6월 1일 (UTC)[응답]
    이 상자는 MediaWiki 기본값별로 노란색이다.우리의 공통 css 코드는 그것을 빨간색으로 만드는 것이다.그래서 그것을 다시 노란색으로 바꾸는 또 다른 규칙이 있는 것은 불합리하지 않을 수도 있다.– SD0001 (대화) 15:52, 2021년 6월 1일 (UTC)[응답]
    @SD0001:나는 색상 선택에 동의하지 않는다. css를 겹치는 css의 레이어를 common.css를 통해 레이어 다음에 적용하는 것은 이상적이지 않다(단일 기술 옵션인 경우에도), 특정 구현이 하드 차단기가 아니다.우리가 현재 "경고-연애-연애-위장"에 스타일링하고 있다는 것 역시 이상적이지는 않지만, 그것이 바로 그것이다.만약 이 제안이 계속 지원 쪽으로 흘러간다면 우리는 몇몇 기술적 해결책을 조롱할 수 있을 것이다.— Xaosflux 16:04, 2021년 6월 1일 (UTC)[응답]
  • 지지가 합리적인 것 같다. --Jayron32 15:22, 2021년 6월 1일 (UTC)[응답]
  • 관리자 참고 사항 MediaWiki에 강조 사항 추가:이 문제가 논의되는 동안 sp-contractions-blocked-note-partial.만약 이 제안이 이상적으로 실행된다면, 메시지는 디폴트로 삭제될 수 있다.— XaosfluxTalk 18:12, 2021년 6월 1일 (UTC)[응답]
  • 말이 되네.~ HAL333 01:04, 2021년 6월 2일 (UTC)[응답]
  • 나는 오렌지가 일반적으로 노란색보다 읽기 쉽기 때문에 오렌지를 지지한다.—피톤코더(토크 기여) 20:16, 2021년 6월 2일 (UTC)[응답]
  • 지원 부분 블록과 전체 블록 간의 혼동을 줄이십시오.— Jackattack1597 (대화 • 기여) 01:26, 2021년 6월 4일 (UTC)[응답]에 의해 추가된 이전의 서명되지 않은 논평
  • 어느 색이든 지지하십시오.전체 블록과 부분 블록을 구분하면 혼동을 줄이고 불행한 오해의 가능성을 줄일 수 있다.Thryduulf (대화) 20:34, 2021년 6월 4일 (UTC)[응답하라]
  • 지지하다.현재 디스플레이는 혼란스럽다.– SD0001 (대화) 07:01, 2021년 6월 6일 (UTC)[응답]
  • 모든 사람당 지원.부분 블록과 사이트 블록을 구분하는 것이 개선이다.색상 선호 없음.이반벡터 (/)TalkEdits 12:08, 2021년 6월 6일 (UTC)[응답]
  • WP별 지원:주황색을 선호하는 스노우프로.Huggums537 (대화) 17:46, 2021년 6월 6일 (UTC)[응답]
  • 지원 보다 직관적이어서 '피디아'를 돕는다.타이론 마데라 (대화) 19:22, 2021년 6월 7일 (UTC)[응답]


기술 구현

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


@Xaosflux, Aspening, Writ Keeper 및 SD0001:나는 너의 무너진 대화에서 잠재적인 미디어위키라는 것을 볼 수 있다.이 작업을 수행할 수 있는 common.css 해킹(예: 빨간색을 다시 기본 황색으로 변경하기 위해)은 기술 구현에 대한 더 많은 논의가 필요해 보인다.이 제안을 실행하기 위해 무엇이 필요하겠는가?Mz7 (대화) 19:12, 2021년 6월 11일 (UTC)[응답]

testwiki(testwiki:MediaWiki:Common.css) - 업데이트를 채울 때까지 기다리십시오.— XaosfluxTalk 21:07, 2021년 6월 11일 (UTC)[응답]
테스트 사례:
  1. 일반 블록: testwiki:특수:기여/Xaosflux2
  2. 부분 블록: testwiki:특수:기여/Xaosflux2a
@Mz7: 그게 네가 찾고 있는 거야?— XaosfluxTalk 21:12, 2021년 6월 11일 (UTC)[응답]
@Xaosflux: 아, 그래.그거 정말 멋져 보인다.Mz7 (대화) 21:27, 2021년 6월 11일 (UTC)[응답]
하는 중...— XaosfluxTalk 21:49, 2021년 6월 11일 (UTC)[응답]
완료 @Mz7: Special의 라이브 예시 참조:기여/예시.문제가 있는 경우 MediaWiki_talk에 게시하십시오.Common.css#pblock 스타일.— Xaosflux 21:58, 2021년 6월 11일 (UTC)[응답]
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.
위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

제안:확장 확인된 사용자를 의 Implicit 멤버에 구현: 자동 확인 사용자처럼

— Xaosflux 13:38, 2021년 6월 23일 (UTC)[응답]