위키백과:Templates for deletion/TOCright삭제/TOCRight 템플릿

Wikipedia:

템플릿:토크라이트


절대적으로 필요하지 않다. 이것은 템플릿의 목적이 아니다. 사용자가 화면 오른쪽에 TOC를 사용하려면 CSS 파일을 편집해야 한다. 삭제 - W. Mark Felt 페이지를 망쳐버렸고 끔찍해 보였다! 이것이 내가 그것을 제거하기를 원하는 실제 주된 이유는 아니다. TOC의 배치가 사용자 선호도가 되어야 한다는 것이다. 기본 스타일은 제정신이여야 한다 - 사용하는 방식은 분명히 그렇지 않다. 그렇기는 하지만, 만약 어떤 사람들이 그것을 모든 수단을 동원해서 사용하게 한다면, 위키피디아의 기본 디폴트를 바꾸기로 결정하지 않는 한 기본 스타일을 바꾸지 마라. 즉, 우회하지 말 것. - 2005년 7월 4일 05:57 (UTC)

이제 이것이 (화산 목록)에 유용할 수 있는 몇 가지 기사를 볼 수 있다. 다른 사용자가 삭제하기를 원할 수 있지만, 이것을 철회하고 싶다. 그러나 거의 모든 경우에 정상적인 기사에 사용하는 것은 부적절하다는 것을 완전히 분명히 하고 싶다. - 2005년 7월 5일 03:54 (UTC)
  • 삭제. TBSDY와 동의하라. 템플릿은 어쨌든 인터넷 공격기에서만 제대로 작동하는 것처럼 보인다. 나는 아이스 에이지 기사를 체크해 보았다. 파이어폭스의 경우, 템플릿은 아무 것도 하지 않는다. IE에서는 TOC를 광고한 대로 오른쪽으로 이동시킨다.иDя01DTOKEMAIL 2005년 7월 4일 06:06 (UTC)
    • 템플릿은 Firefox 1.0.4, IE6.0 및 Opera8에서 광고한 대로 작동하는 것 같다. 그것이 생산하는 HTML도 유효한 것 같다. 혹시 TBSDY가 블랭킹한 기간에 그 페이지를 보셨나요?HorsPunchKid2005년 7월 4일 07:14 (UTC)
      • 이것은 사실입니다. 그랬지, 왜냐하면 기본 TOC 스타일이 바뀌었기 때문이지. 스타일시트로 설정되어야 해. 만약 이것이 틀렸다면 미안해. 누군가가 되돌아갔어. 내 생각엔 공평한 것 같아. TFD 태그를 다시 넣었어. - 2005년 7월 4일 08:13(UTC)
        • 음, 이상하네. 파이어폭스에서 작동하나 봐. 누군가가 다른 브라우저로 내 수표 사이에 템플릿을 되돌린 게 틀림없어. 타이밍이 안 좋았어 :-) 그러나 나의 투표는 남아있다; 레이아웃은 일관되어야 한다. иDя01DTOKEMAIL 2005년 7월 4일 18:01 (UTC)
  • 사용자가 "템플릿의 목적이 아니다" 또는 "W. 마크 펠트 페이지를 망쳐버렸고 끔찍해 보였다"고 믿는다면, 단순히 사용자 스스로 그것을 사용하지 말아야 한다.~ 신경과학자 2005년 7월 4일 06:52 (UTC) Edit - 또한 템플릿이 삭제 기준을 충족하지 못한다는 점을 추가하고자 한다: (특히 CSS가 무엇인지 모르는 사용자에게는 영주권과 달리 편집하는 방법보다 훨씬 덜 유용하며) 사용된다는 점을 추가하고자 한다./ 신경과학자
    • 어 - 만약 내가 페이지를 보는 방식에 영향을 미친다면(와 같이, 기본 보기를 망친다면), 삭제해야 한다. 이 템플릿이 그들에게 가해지는 것을 원하지 않는 사람들은 그것을 참을 필요가 없어야 한다. 그리고 우리의 기본 사이트 모양은 이러한 바보 같은 속임수에 의해 손상되어서는 안 된다. - 2005년 7월 4일 07:58 (UTC)
      • 페이지를 편집하는 사람은 내용뿐만 아니라 형식도 편집할 수 있다. 특정 페이지 형식이 마음에 들지 않을 경우 yopu는 해당 대화 페이지에서 변경하거나 합의를 시도할 수 있다. 대부분의 사용자는 CSS 변경으로 이 작업을 수행할 수 없으며, 이 변경사항이 제공하는 형식 변경은 사용자, IMO. DES 4 2005년 7월 23:07(UTC)
        • 즉, 페이지 레이아웃을 수정하기 위해 CSS를 사용하는 대신 현재의 디폴트를 좋아하지 않는 소수의 편집자들이 합의로 지원되지 않는 변경을 통해 강제로 실행한다는 것이다. 그리고 그들에게 스타일 변화를 강요하고 있다고? 마음은 엉망이군! - 2005년 7월 5일 02:09 (UTC)
  • 삭제, Tabu와 동의한다. 복사_> 2005년 7월 4일 < 08:12 (UTC)
  • Tabu에 따라 삭제하십시오. 이것은 "끔찍해 보인다"의 문제가 아니므로 나는 그것을 사용해서는 안 된다; 이것은 모든 사용자의 기본 레이아웃을 바꾸는 것이다. 만약 개인이 TOC가 반대편에 있기를 바란다면, CSS를 사용하고 다른 모든 사람들을 위해 그것을 내버려 두도록 하라. --khaosworks 2005년 7월 4일 08:30 (UTC)
    • 아주 약한 상태로 유지한다. 곰곰이 생각해 보면, 이것은 몇몇 기사에서는 유용할 수도 있지만, 편집증적인 나 자신이기에, 나는 가능한 학대를 면치 못한다. 나는 TOC가 오른쪽에 있는 반면 그렇지 않다면 어느 쪽이 레이아웃을 더 낫다고 결정할 때 편집 전쟁이 올까 두렵다. MoS --khaosworks 2005년 7월 5일 03:49 (UTC)에서 이 문제를 해결해야 한다.
  • 리미티드 킵. 소프트웨어는 우리에게 TOC가 배치되는 방법과 위치를 제어할 수 있도록 하기 위해 _TOC__ 태그를 주었다. 올바른 정렬이 그 기술적 능력의 부적절한 사용이라는 것을 나는 스타일 매뉴얼에서 찾을 수 없다. 따라서 템플릿이 허용될 수 있고 적어도 일부 사람들은 템플릿이 유용하다고 생각한다. 나는 그것이 7개월 동안 존재해왔다는 사실을 TOCright의 많은 장소들이 발생하지만, 그러한 지역사회가 적극적으로 반대하지 않는다는 것을 암시하는 것으로 받아들인다. 그렇긴 하지만, 나는 표준 외모와 결별하는 것이 문제가 된다는 TBSDY의 의견에 동의한다. 만약 이것이 스타일 토론의 매뉴얼이라면 나는 TOC의 정렬에 반대할 것이다. 드래곤즈 2005년 7월 4일 09:05 (UTC)
  • DeleteWeak Delete. TOC가 왼쪽 정렬인지 오른쪽 정렬인지 여부는 Monobook.css 파일에서 결정해야 한다. 일부 페이지가 왼쪽 정렬되고 오른쪽 정렬되면 전체 스타일시트를 사용하는 전체 포인트인 사이트의 일반적인 모양과 최소한 스타일 매뉴얼의 일부가 손상된다. --cesarb 2005년 7월 4일 09:29(UTC)
    • 화산 목록을 보고 난 후에, 나는 그것이 유용할 수 있다는 것을 알 수 있다. 하지만 나는 그것을 언제 먼저 사용할지에 대한 토론을 보고 싶다. 항상 우측 플로트로 포지셔닝하기로 결정되면 CSS에서 간단히 변경될 수 있다. 약한 삭제로 변경. --cesarb 2005년 7월 5일 12:16(UTC)
  • 삭제, 기사 본문과 리드 섹션 사이에 공간이 필요해, 고마워 프레드릭 토크 2005년 7월 4일 09:39 (UTC)
  • 강력유지화면 오른쪽에 TOC를 사용하려면 CSS 파일을 편집해야 한다. 그것은 여기서 중요한 것이 아니다. 어떤 기사들은 다른 기사들보다 더 잘 흐르기도 하고, 내용 목록이 한 쪽에 있는 것이 더 보기 좋다. 모든 개별 기사에 대한 CSS 설정을 변경해야 하는가? 일부 기사의 맨 위에 "경고:이 페이지를 읽기 전에 CSS 설정을 변경하시겠습니까?" 아니면 단순히 템플릿을 사용하여 작업을 수행하는가? 다른 소프트웨어로 렌더링하는 문제에 관해서는, 위키피디아의 맨트라스 중 하나인 IIRC가 바로 그것을 고치는 것이다. 그래서... 그루티니스...뭐라고? 2005년 7월 4일 09:57 (UTC)
    • TBSDY가 지적한 몇 가지 예를 살펴본 후 "지키기"에서 "강력한 유지"로 바뀌었다. 3번 중 2번은 멀쩡해 보였고, 3번 째는 그저 인포박스의 위치가 바뀌기만 하면 되었다. 그렇다면 화면 오른쪽 아래 1에이커의 하얀 공간이 있는 것보다 훨씬 더 좋았을 것이다. 그루티니스...뭐? 2005년 7월 5일 02:40 (UTC)
  • 삭제 - 어느 정도 일관성을 갖자. 2005년 7월 4일 10:24(UTC)
    • 계속. 내 마음이 바뀌면 - 좋은 효과에 익숙해질 수 있지만, 너무 많이 쓰이지 않았으면 좋겠어. 바이올렛/리거 (t) 2005년 7월 4일 19:37 (UTC)
  • Keep - TOC 배치를 선택할 수 있도록 결정되었으므로 각 페이지에 표를 추가하는 것보다 템플릿(CSS를 호출하는 템플릿도 포함)으로 이 작업을 수행하는 것이 바람직하다.
    분명히 템플릿의 존재는 페이지마다 그것을 사용할 필요가 없고 W. 마크 펠트 기사에 그것을 사용해야 한다는 것을 의미하지도 않는다. 개인적으로, 나는 그것이 일반적으로, 특히 암살된 사람들의 목록과 같은 긴 리스트에 적절하다고 생각하지만, 는 W. 마크 펠트 기사의 레이아웃에 대해 토론하고 싶지 않다. -- 사용자:도큐
  • 절대 아니다. 이 템플릿은 표준 위키백과 포맷의 목적을 완전히 무너뜨린다. →Raul654 2005년 7월 4일 11:16 (UTC)
  • Strong Keep TOC 오른쪽은 많은 기사에 적합하다. 일관성은 신경 안 써, 그 글에 맞는 게 중요한 거야. 만약 여러분이 TOCright가 있는 기사를 보고 그 존재가 여러분을 뼈까지 아프게 하고, 그것이 여러분이 생각하는 것과 같은 장소에 있지 않기 때문에 불 같은 분노의 눈물을 흘리게 만든다면, 대담하게 그리고 그것을 움직이게 하기 위해 시도하지 말고 템플릿을 삭제하십시오. 예. 프로토 t c 2005년 7월 4일 12:10 (UTC)
  • 재난에 대한 처방. 삭제하다. JFW T@lk 2005년 7월 4일 12:41(UTC)
  • 삭제. 기본 TOC 레이아웃은 하나만 있어야 한다(기본 TOC 레이아웃을 축소하는 옵션과는 별개). 사용자들이 TOC를 이동시키기로 결심했다면, 그렇게 하는 방법을 배우기를 기대하는 것은 불합리하지 않다. -2005년 7월 4일 15:01 (UTC)
  • 삭제. TBSDY를 완전히 신뢰하라. 준퉁우 4 2005년 7월 15:42 (UTC)
  • 계속, 이 템플릿이 왜 삭제되어야 하는지 모르겠네, 많은 기사에 유용하거든. Flag of the United States.svg 피닉스2 7월 4일! 16:17 (UTC)
  • 삭제. 사용자 선호 사항이어야 하며, 나는 오히려 왼쪽의 TOC와 일치하는 기사를 가지고 있다. Chris 73 Talk, 2005년 7월 4일 16:31(UTC)
  • 프로토그루트니스에 동의한다. TOC가 차지하는 흰 공간이 많은 것보다는 TOC가 긴 TOC를 가지고 있지만 지나치게 넓은 TOC가 아닌 텍스트가 흐르는 것이 더 보기 좋다. 현재 이것을 처리하는 데 선호되는 설정은 없으며, CSS를 편집하는 것은 일반 사용자에게 요청하기에 합리적인 것이 아니다. 그리고 이 템플릿은 사용자들의 읽기 경험을 향상시키기 위한 것이다. DES 4 2005년 7월 17:17 (UTC)
  • 의견 - TOC 배치가 표준이 되도록 여기의 표를 삭제하거나 특정 기사에서 TOC 배치를 편집자가 제어할 수 있도록 유지하려는 것으로 보인다. IMO, 위키백과에 명확한 지침이 없는 한:TOC가 오른쪽에 있어야 하는 시기에 대한 스타일 매뉴얼은 TOC를 오른쪽에 배치하기 위해 개별 문서 내에서 사용되는 모든 메커니즘과 기본값을 비교하여 의심스럽다. 이 템플릿을 삭제하더라도 편집자가 다른 수단을 사용하여 TOC를 오른쪽에 강제로 배치하는 것을 막을 수 있는 것은 없다. 내 제안은 일단 이 템플릿을 보관하고, 스타일 이슈로 TOCs가 오른쪽에 배치되도록 허용해야 하는지를 해결하자는 것이다. 만약 우리가 언제 권리 TOC가 허용되는지(그리고 그러한 TOC가 허용되지 않는 경우보다 더 자주 허용됨)에 대한 가이드라인을 얻게 된다면, 우리는 이 템플릿을 영구히 보관해야 한다. TOCs만 남겨두면 템플릿은 쓸모가 없어 삭제할 수 있다. -- Rick Block (대화) 2005년 7월 4일 17:47 (UTC)
  • 보관해. 이 템플릿을 최근에야 발견했는데, TOC를 어디에 둘지 선택할 수 있어서 좋아. 일부 기사는 상단 사진의 위치에 따라 오른쪽에 템플릿이 삽입되어 더 보기 좋다. 외관의 비정함이 항상 좋은 것은 아니다. 예를 들어, 사진이 본문을 향하도록 되어 있기 때문에(독자의 눈은 사진 속의 사람들의 지시를 따르는 것으로 알려져 있기 때문에) 왼쪽 위에 사진이 있는 것이 좋은 경우도 있다. 왼쪽에 있는 사진은 오른쪽에 있는 템플리트가 더 잘 어울리고 특히 내장되어 있다. 소개서와 기사의 큰 차이점이 항상 좋게 보이는 것은 아니다: 출판사들은 대개 백지를 피하기 위해 많은 노력을 기울인다. 그리고 어쨌든 편집자들이 레이아웃에 있어서 작은 변화를 허용하지 않을 이유가 없다. 파이어폭스, 사파리, 넷스케이프 등과 함께 이 템플릿을 살펴봤지만 아무런 문제가 없었다. SlimVirgin 2005년 7월 4일 18:01(UTC)
설명: SlimVirgin, 좋은 예인데, 또 다른 사용자인 Neuro Scientist가 "이 템플릿을 원하지 않는 사람들은 강요하지 말아야 한다"고 제안했기 때문에, TOCright가 필요한 예를 들어 좋은 사례를 들자면, 나는 당신의 주장을 나의 일부로 채택할 것이다. 감사합니다. 아래를 참조하십시오.--GordonWattsDotCom 2005년 7월 6일 06:58(UTC)
  • 삭제, 기존 포메이션은 잘 작동하고 더 멋져 보인다. 이에 대한 원래의 주장은 백색 공간을 줄인다는 것이었다. 문제 없는 해결책. 조 D (t) 2005년 7월 4일 19:45 (UTC)
  • 계속. 몇 번 사용한 걸 보니 기사 읽기 편하더라. Jayjg 4 2005년 7월 19:47 (UTC)
  • 몇 줄의 텍스트와 함께 빈 백색 공간의 덩어리로 독자를 환영할 때 기사 보관은 인상적이지 않다. --Ian Pitchford 4 2005년 7월 19:58 (UTC)
  • 보관하라. TOCs가 긴 기사는 납과 나머지 텍스트 사이에 화면이나 3개의 공백이 없을 때 더 잘 흐른다. 이것은 현명하게 사용할 때 유용한 템플릿이다. --Alen3 2005년 7월 4일 20:00 (UTC)
  • 보관. - 2005년 7월 4일 유령 21:21 (UTC) - Tabu는 이 템플릿이 이전에 검토, 투표, 보관되었다는 것을 무시하기로 선택했다. 가 토크에 올린 사용 이유는 다음과 같다.Intelligent Design 페이지:
수정: 무시되지 않음 - 인식되지 않음! - 2005년 7월 5일 01:47(UTC)
나는 그 의견이 꽤 잘 나뉘었다고 생각한다. TOC의 표준 형식에 대한 나의 문제점은 세가지다.
1) Talk를 파고들면:지능적인 디자인#기물 파손에 대한 거짓 주장 우리가 어디에서 성공적으로 아논 사용자의 POV 문제를 해결하기 위해 TOC 형성을 사용했는지 볼 수 있을 것이다. 그의 의견은 ID에 대한 일부 반박이 반드시 "접지 위"로 나타나야 한다는 것이었다. TOC 포맷 없이 이것을 하려면 ID 서포터즈와 이미 싸운 인트로의 재작성이 필요하다. 우리는 원래 TOCembed를 사용했지만 포맷된 상태로 방치되어 있어서 많은 사용자들이 이를 견디지 못했다.
2) 항법 시 TOC의 길이가 정상보다 길어야 한다. 모든 사람이 10페이지 이상을 읽기를 원하는 것은 아니다. 그래서 TOC를 너무 짧게 하는 것은 독자들에게 해로울 수 있다.
3) 정말 3/4의 공백을 더 좋아하나? 지금은 모든 신문이 존재해 보이는데, 무슨 번거로움이 있을까?
TOCright를 견딜 수 없다면 우리에게 실행 가능한 대안을 제시하라. 나는 우리가 TOC의 크기를 너무 많이 줄이면 안 된다고 생각한다. 2005년 7월 4일 20:06(CoordinatedUniversalTime)에서 _TOC_를사용하여 폴드 아래로 이동해야 하는가?--2005년 7월 4일 20:06(CoordinatedUniversalTime)-고스트.
보시다시피, 이것은 단순히 표준화된 유화 문제가 아니다. 이는 POV 우려를 통제하기 위해 시행되고 있더라도 TOC를 아예 포함시켜야 하는지에 관한 것이기도 하다. 만약 우리가 이 TOC 제어를 제거하기로 선택했다면, 우리는 그것들을 모두 제거해야 한다. 이때 템플릿에 CSS 자습서를 제공해야 한다.신입들에게 이런 선택지를 설정하는 방법을 부드럽게 가르쳐 준 것을 환영한다. 내가 한번도 해본 적이 없는 것처럼 말이다. 그렇지 않으면 신참들에게 부드럽게 대하기 위해 그대로 두어라.--유령 2005년 7월 4일 21:21 (UTC)
  • 코멘트(위의 내 의견은 보관하는 것이다): "이 템플릿을 원하지 않는 사람들은 강요하지 않아도 된다"는 주장은 분명히 약하다. 사실상 다른 어떤 것에 대해서도 마찬가지일 수 있다. (좌측 TsOC 포함). 이는 위키백과(예: 스타일 매뉴얼을 통해)에서 우측 TsOC가 금지된다는 널리 알려진 규칙이 있다면 방어할 수 있을 것이다. 그러나 이것은 사실이 아니다.
그것은 좋은 지적이야, 신경과학자. 그래서, 나는 내 주장을 뒷받침할 거야. 아래를 참조하십시오.--GordonWattsDotCom 2005년 7월 6일 06:58(UTC)
중요한 점은 우측 TOC가 일부 기사에 유용하다는 것에 대해서는 거의 의심의 여지가 없으며, TOCright 템플릿은 단순히 편집자들 특히 기술적 전문성이 부족한 초보자들이 자신의 기사에 우측 TOC를 붙이기 쉽게 만든다는 점이다. 기사에 대해 오른쪽 TOC를 선호하는 사용자들은 CSS 편집을 배우고 페이지마다 편집하면 되는데, "기본값"이 아니기 때문에 간단한 템플리트를 사용하지 않는 것은 애플링과 같다. 이것이 의미하는 바는 다음과 같다: "그래, 위키백과 스타일 매뉴얼에 우파 TsOC를 금지하는 것이 없다는 것을 알고 있고, 어떤 기사에서는 그것이 더 낫다는 것을 알고 있지만, 나와 많은 다른 기사들은 (여러 가지 이유로, 다른 기사들보다 더 나은) 그 모습이 마음에 들지 않기 때문에, 우리는 당신이 그것을 만드는 것을 더 어렵게 만들려고 한다. 정말 기사에 더 좋다." 나는 이것이 매우 칭찬할 만한 입장이라고 생각하지 않으며, 그것이 위키 정신에 부합하는지 확신할 수 없다.
사용자가 잘못 적용되었다고 생각하는 TOC를 가진 기사를 우연히 발견하면, 간단하고 널리 고용된 치료법이 있다. 그것은 기사를 편집하고 합의에 도달하려고 시도한다고 불린다.
마지막으로, 템플릿을 삭제하려는 움직임은 요구사항을 만족시켜야 한다. 이것은 적어도 130개의 기사에서 현재 사용되고 있는 이 특정 템플릿의 경우 나의 대략적인 계산에 의해 특히 중요할 수 있다. 다음과 같은 경우 템플릿을 삭제할 수 있다.
  • 그것들은 도움이 되지 않고 주목할만하지 않다.
  • 그것들은 중복된다.
  • 그것들은 사용되지 않는다.
이 요건들 중 어느 것도 권리에 대해 충족되지 않는다.TOC 템플릿.~ 신경과학자 2005년 7월 4일 21:12 (UTC)
템플릿 삭제 기준을 따르지 않고 TfD에 이것을 추가했다는 너의 암시가 싫어. 나는 그 템플릿이 도움이 되지 않아서 기준들 중 하나를 만족시킨다고 주장한다. 분명히 나만 이것을 믿는 것은 아니다. 다른 사람들은 동의하지 않는데, 내가 보기에는 공평하다. 그러나 만약 이 템플릿이 내가 윈도우 2000과 같이 많이 작업한 기사들 중 어느 것에도 붙여진다면, 나는 내가 이 사이트에 계속 기고할 것인지 검토할 필요가 있을 것이다. "스타일" 템플릿 같은 것을 가지고 이런 일을 할 필요가 없었으면 좋겠지만, 만약 내가 사이트를 편집하는 것이 불필요하게 어려워진다면, 내가 기여할 수 있는 더 나은 포럼이 있다면, 나는 해결해야만 한다. - 2005년 7월 5일 01:52 (UTC)
친애하는 친구여, 위키 기사를 쓰는 것이 우리의 시간적 가치가 있는지를 결정하는 것은 우리가 기사를 편집할 때마다 우리 모두가 내리는 결정이다. 만약 당신이 위키피디아보다 당신의 기여에 더 좋은 이유가 있다고 생각한다면 당신은 떠나는 것을 완벽하게 환영한다. 만약 당신이 기사에 "대단한" 일을 했지만, 목차가 페이지 왼쪽이 아닌 오른쪽에 있기 때문에 어쩔 수 없이 떠나야 한다면, 글쎄, 그 결정은 당신의 것이다. 떠나거나, 머물거나, 편집하거나, 읽거나, 다른 작업을 수행하든 템플릿 삭제의 옳고 그름과는 거의 관련이 없다. 그것은 그 사안의 장점에만 의존해야 하는 결정이다.
그리고 사안의 장점을 결정함에 있어서 삭제 기준을 불가피하게 참조해야 한다. 네가 그 기준에 대해 얼마나 생각했는지 나는 상관없어. 이 문제에 관심이 있는 편집자로서, 나는 그 기준을 직접 참고할 것이다. 그리고 만약 내가 그것들이 충족되지 않았다고 생각한다면, 나는 그것을 지적할 것이다. 나는 확실히 그들이 전혀 만나지 않았다고 생각한다. 그 템플릿이 사용되고 있다는 것은 의견의 문제가 아니라 경험적인 사실이다. 템플릿이 중복되지 않고, 의견의 문제가 아니라 경험적 사실이다. 즉, 하나의 권리만이 있다.TOC 템플릿, 그리고 그것이 하는 일을 하는 유일한 것이다. 템플릿이 도움이 된다는 은 모두에게 명백하다: 그것은 당신에게 도움이 되지 않을 수도 있지만, 그것이 다른 위키 사용자들에게 도움이 되지 않는다는 것을 의미하지는 않는다 - 그것은 명백하게 그들 중 많은 사람들이 그것을 사용하고 있기 때문이다./ 신경과학자TC 2005년 7월 5일 02:56 (UTC)
얘야, 네가 그 정책을 오해하고 있는 것 같아.리스트에는 없고 단지 또는가 있다. 내가 그것을 읽었을 때, 모든 기준이 충족되어야 하는 것은 아니다. 만약 하나의 기준이 반대된다면, 템플릿은 여기에 나열될 수 있다. 템플릿:Substub은 한때 유효하게 나열되었다. 그것은 문자 그대로 수천 개의 기사에 관한 것이었다! 내가 떠나는 것에 대해: 나는 단지 TOC의 디폴트 배치를 변경하려는 그러한 일방적 결정이 아무런 논의도 없이 나의 편집 결정에 어떤 영향을 미칠지 내 의견을 알려주고 있을 뿐이다!
나는 Grutness가 화산 목록을 지적한 것에 주목할지 모른다. 그리고 나는 이것이 그 페이지에 있는 좋은 생각이라는 것에 동의한다. 단, 이것은 하나의 예에 불과하며, 주요 기사에는 적용해서는 안 된다. - 2005년 7월 5일 03:40 (UTC)
그와는 반대로, 너는 꽤 틀렸다. 섹션을 읽어 보십시오. "템플릿이 다음 사항부합하지 않는 경우 템플릿 삭제가 적절할있다"라고 명시되어 있으며, 이에 기준이 명시되어 있다. 어디에도 "혹은" 보이지 않는다. 템플릿다음어느 하나에 부합하지 않을 경우 "... 적절할있다"고 명시되어 있지 않다. "...다음일치하지 않는다"라고 쓰여 있고, 그 다음에 목록이 뒤따른다. "그리고"는 암묵적인 연산자다.
그러나 "및" 또는 "또는"이 연산자인지 여부에 관계없이 문장의 구문 때문에 여기에 템플릿을 나열하는 것은 금지되지 않는다는 점에 유의하십시오. 나는 네가 그것을 삭제하라고 나열하는 것에 반대하지 않는다.삭제 기준에 어긋나기 때문에 삭제해서는 안 된다고 말씀드리는 겁니다. 그것은 사용되고 있고, 중복되지 않으며, 적어도 일부 편집자와 기사에 도움이 된다. 화산이 특히 유용한 유일한 기사는 아니다. 같은 내용이 적용되는 광범위한 "학교 목록" 시리즈가 있다. 귀신이 위에서 지적한 문제들은 말할 것도 없고, 나는 당신이 제시한 해결책이 전혀 보이지 않는다.~ 신경과학자 T C 2005년 7월 5일 05:32 (UTC)
  • 보관하라. 템플릿이 어떻게 사용되는지 살펴본 결과, 더 많은 기사에 보관되고 사용되어야 하는 것이 명백해 보인다. BlankVers 2005년 7월 4일 22:12 (UTC)
  • 삭제. 절대적으로 필요없고, 형편없다는 것은 말할 것도 없다. --밍훙 2005년 7월 5일 02:33 (UTC)
  • Keep - 화면 크기에 관계없이 작동하는 글과 작성이 유용하다. 게타르다 2005년 7월 5일 03:47 (UTC)
  • 일리노이 고등학교 목록을 만들었는데 나중에 다른 사람이 이 템플릿을 적용했어 내가 가졌던 것보다 훨씬 좋아 보인다. 그들이 원하지 않는 한 아무도 템플릿을 사용할 필요가 없다. DS1953 5 2005년 7월 04:04(UTC)
  • 'Comment On my talk page Ta bu si da yu는 다음과 같이 썼다. 나는 사람들이 리드 섹션 아래에서 그것을 사용하도록 하는 스타일 가이드라인이 만들어지면 그 점을 전적으로 인정하겠다. 그러나 지금은 헤딩 언더라인이 TOC를 절단하여 프로페셔널하지 못한 것처럼 보이게 하는 문제가 있다. 만약 이러한 것들이 정리될 수 있다면, 나는 템플릿에 대한 나의 모든 반대 의견을 철회할 것이고, 전체 이슈에 대한 관점을 잃은 것에 대해 사과할 것이다. 이것은 내게 합리적인 것으로 들리지만, 아주 긴 리드 섹션의 경우, TOCright가 기사의 시작 부분에서 더 나을 수 있다. DES 5 2005년 7월 04:19 (UTC)
    그것이 어디서 발생하는지 지적해 줄 수 있니? 내가 보는 모든 기사에는 TOC를 자르는 줄이 하나도 없다. 어떤 브라우저를 사용 중인지 설명해 주시겠습니까? 고칠 수 있을 것 같은 생각이 있는데, 혹시 당신만의 CSS로만 들어오는 것이 아닐까 하는 생각이 든다 —Mike 2005년 7월 5일 06:53 (UTC)
    그것은 인텔리전트 디자인 기사에 있었다. 나는 IE 6.0 1280 x 1024 픽셀을 사용하고 있다. 나는 TBDY가 무엇을 고소하고 있는지 모르겠고, 그도 그것을 보았다. DES 5 2005년 7월 16:07(UTC)
    스타일 문장에 백그라운드:인헤리트(inherit)를 추가해 수정하기를 희망했다. 그게 안 되는 걸 발견하는 사람이 있으면 알려줘. —2005년 7월 5일 18:03(UTC)
  • 더 좋은 예가 테리 시아보 기사다. 상단/오른쪽 그림, 긴 소개, 왼쪽(TOCright) 관련 주제 가이드, 접기 아래 2005년 7월 5일 05:54(UTC)
그 기사는 끔찍한 조직의 한 예다. 때문에 세밀한 표현은 더에 만약 기사는 적절한 요약 문장으로 쓰여 있었기 때문에 전술 작전 본부 직접 같은 페이지(별도의 페이지까지 독자를을 보내는 것보다 낫다)과 전술 작전 본부에 관련 요약이 독자들에게 걸릴 것,"관련 기사 문서 &"목록은 불필요할 것 크게 작을 것이다. spe시시콜콜한 물건 불가피하게 긴 리스트에 TOCright가 사용되는 것을 받아들일 수 있지만, 여기서 문제는 기사 구조에 있고, TOCright의 사용은 진짜 문제를 놓치고 있다. Fredriktalk 2005년 7월 5일 06:19 (UTC)
그렇다면 우리가 그것을 고치는 것을 돕는 것은 환영할 일이다. 분리된 페이지가 만들어진 이유는 기사의 압도적인 크기와 팜 선데이 타협과 같은 일부 주제들의 독립적 관련성 때문이다. 공정한 경고:테리 시아보는 논란의 대상이다. 당신이 제기하는 우려는 타당하지만 수십 명의 편집자들이 타협하고 토론한 결과물이다. 그리고 모든 편집자들이 다른 사람들과 잘 어울리는 것도 아니다.--고스트 2005년 7월 5일 15:43 (UTC)
그리고 모든 편집자들이 다른 사람들과 잘 어울리는 것은 아니다.헤헤~~ 신경과학자 T C 2005년 7월 5일 16:28 (UTC)
  • 삭제. — Dan Talk 2005년 7월 5일 04:41(UTC)
  • 기사를 더 잘 읽고 읽을 수 있게 만드는 것이 적어도 한 번은 유용하다는 것을 알게 해 줘. 위의 monobook.css에 대한 모든 언급은 두 가지 계정으로 부족하다. 1. 막대한 양의 아논 독자. 2. 왓 더 헬 유 왓 어 왓 어 왓 어 왓 어 왓 어 !!는 아마도 모노북.css에 대해 이야기할 때 꽤 많은 사람들이 생각하고 있는 것일 것이다. 나는 그것을 실제로 사용하지 않는다. 그리고 많은 다른 사람들이 그것이 무엇인지 가장 잘 알지 못한다면 나는 놀라지 않을 것이다! 3. 일관성에 대한 반박: 위키피디아에서 일관된 철자가 없다면, 더 나은 기사 가독성을 위해 일관성이 없는 TOC를 갖는 것은 괜찮다고 생각한다. 하지만 그건 나뿐일지도 몰라.---쯔나카이 2005년 7월 5일 06:24 (UTC)
  • 강하게 유지하되, 내가 그것을 만들었음을 유의해야 한다. 아마 여기에 이름을 올리면 적어도 한 가지 이점이 있다면, 앞으로 더 많은 사람들이 이 이름을 사용할 수 있다는 것을 의미할 것이다! 낙관적인 것은 차치하고라도, 개발자들이 이 기능을 미래의 소프트웨어 버전에 포함시킬 수 있다면 좋을 것이고, 그 이 템플릿이 제거될 수 있을 것이다. 나는 누군가가 CSS를 이러한 이유로 이 템플릿을 사용하지 않는 이유로 사용하는 능력을 주장하는 것은 다소 어리석은 일이라고 생각한다. 이 사이트를 검색하는 대다수의 사용자는 로그인하지 않고 기본 스킨만 사용할 것이다. 이 템플릿은 특히 이러한 사용자를 염두에 두고 설계되었다. 2. 이 웹사이트의 스킨에 대한 기본 CSS를 수정하거나 추가하도록 하는 것은 매우 어렵다. 지난번에는 "불만하지 말고, 그냥 개인 CSS를 바꾸라"는 식의 답변만 받았다. 3. 이 템플릿은 CSS가 완전히 구동되도록 변경될 수 있지만, 모든 스킨에서 CSS에 필요한 변경을 수행하는 데 권한이 있는 사람이 동의하는 경우에만 변경될 수 있다. 분명히 CSS를 직접 작성하고 MySkin을 사용하는 개별 사용자는 올바른 부동 TOC를 보려면 필요에 따라 변경해야 할 것이다.—Mike 2005년 7월 5일 06:53(UTC)
  • 코멘트 위키백과에 기여하는 모든 사람이 'CSS 파일 편집' 방법을 알고 있거나 신경 쓰는 것은 아니다. 나는 누가 그렇게 하는지 상상할 수 있다; 그러나 보통 템플릿 만드는 법을 아는 사람들은 그렇게 한다. 그래서 이런 페이지에서 그들의 존재가 더 눈에 띈다. 나는 이것이 더 일찍 언급되었다고 생각한다. '그들은 그들의 CSS 파일을 편집해야 한다'는 것이 유용한 템플릿을 버리는 가장 적은 이유다. 프로토 t c 2005년 7월 5일 08:47 (UTC)
  • 사용 지침서를 준수한다(즉, 타당한 이유가 없으면 안 된다). TOC를 왼쪽으로 띄워서, 그 오른쪽에 있는 빈 공간을 그만큼 규약을 어기지 않고 피하는 템플릿이 있는가? Rd232 5 2005년 7월 11:13(UTC)
  • 매우 약한 상태 유지 --AI 2005년 7월 5일 11:58(UTC)
  • Rick Block --MarSch 5 2005년 7월 15:34 (UTC)에 따라 보관한다.
  • Ta bu si da yu가 이 대화를 위키백과_talk로 넘겼다는 것만 언급하면:Manual_of_Style#Template:토크라이트. —2005년 7월 5일 18:20(UTC)
  • 삭제 이 템플릿은 대부분의 다른 템플릿보다 사용자가 기사 조직에 대한 자신의 주관적 선호도를 대다수의 사용자에게 강요하는 방법으로 보인다. 때로는 기사에 적합한지 여부에 관계 없이? 일부 사용자들은 모든 기사에 대해 TOCright를 선호하는 것으로 보이며, 위의 독서 토론은 그것이 특정 기사에 도움이 된다고 생각하는 것으로 보인다. Ian Pitchford는 위의 코멘트를 통해 기사를 개선한다고 말하지만, 나는 이것이 주관적이고 따라서 최종 사용자 CSS 파일이 일반적으로 "더 나은" 것에 대해 강하게 느낀다면 더 잘 처리할 수 있다고 주장한다. 물론 내가 여기 있는 몇몇 사용자들보다 더 새롭긴 하지만 내가 업데이트하고 세심하게 조직한 페이지에 이 템플릿을 임의로 삽입한 것은 마을 펌프에 대한 나의 생각에 그저 어리둥절할 뿐이었다. 개인적으로는 나 자신이 개선이라고 생각하지는 않았지만 되돌릴 수 있을 만큼 강하게 느껴지지는 않았다. 일부 사용자에 의해 기사 전체에 걸쳐 템플리트를 건전하게 삽입하는 것은 확실히 명확한 선호도를 가리킨다. 그 근거로 CSS 파일이 유일한 옵션으로 더 나은 것 같다. 참고: 개인적인 예의로 나는 또한 그에 대한 나의 언급이 있을 때 곧 이안의 Talk 페이지에 코멘트를 할 것이다. 화이트호스1 2021년 10월 4일 00:07(UTC)
    • 기사의 모든 편집자는 후속 독자에 대한 편집자의 견해를 "포이스트"로 수정하고, 모든 형식 선택사항은 독자에게 형식을 "포이스트"로 지정한다. 왜 이 선택지가 다른 선택보다 평범할까? 또한 나는 이 스타일이 모든 기사 또는 심지어 대부분의 기사에 사용되어야 한다고 말하는 사람을 본 적이 없다. 이안 피치포드는 글들이 몇 줄의 텍스트에 이어 백색 공간의 덩어리로 독자를 환영할 인상적이지 않은 처럼 보인다고 썼다. 이것은 마치 짧은 리드 섹션과 길고 좁은 TOC를 가진 기사들에 특별히 적용된 것처럼 들린다. 만약 그렇다면, 나는 그러한 기사가 떠다니는 TOCs의 좋은 후보라는 것에 동의한다. OTOH, 짧거나 넓은 TOCs를 가진 기사는 IMO로 좋지 않은 후보들이다. 그리고 특정한 경우, 떠다니는 TOC가 제대로 작동하지 않게 만들 수 있는 다른 특징들이 있다. 어떤 스타일이나 편집 도구도 모든 기사에 적합한 것은 아니다. 다른 사람이 광범위하게 작업한 기사를 편집하는 것(분명히 Be Bold 표준에 따라 적절함)은 다른 편집자에게 "임의적"이고 "참견적"으로 보일 수 있다. 그것은 아무도 물건을 소유하지 않는 협력 프로젝트의 위험이다.DES 5 2005년 7월 20:26 (UTC)
      • 그런 다음 리드 부분을 분류하고 TOC를 줄여야 한다. 그게 진짜 문제야 - 2005년 7월 5일 23:38 (UTC)
      • DES, 나는 그가 "모든 또는 심지어 대부분의 기사에 스타일이 사용되어야 한다"고 말했다는 말은 하지 않았다. 하지만, 나는 그의 기여 페이지 - 그를 더 예증하는 것으로서, 적어도 그가 그것을 많은 기사에 대한 유일한 변화로 삽입한 것에서부터, 그것이 대부분의 기사에 대한 그의 선호인가 아니면 모든 기사에 대한 그의 선호인가에 대한 분명한 증거를 확실히 제공한다고 믿는다. 나는 이견의 원칙도 없고, 우연히 내가 작업할 수 있는 어떤 기사도 크게 수정해서는 안 된다. 바로 위에서 마이크가 연결한 토론도 흥미롭다. 화이트호스1 2021년 10월 4일 00:07(UTC)
        • 방금 스페셜을 봤는데기여/이안_피치포드, 당신이 위의 글을 쓸 무렵(2005년 6월 28일) 나는 {{}}를 삽입한 편집 몇 가지를 발견했다.TOCright}이(가) 각종 기사에 실렸다. 나는 TOCright를 사용하지 않는 기사를 전후로 훨씬 더 많이 편집했다. 나는 그의 역사에서 모든 편집을 보지 않았다. 너무 많다. 그러나 나는 그 증거가 이 사용자가 효과적으로 모든 기사를 TOCright 스타일로 바꾸기를 원한다는 제안이나, 그가 다른 반론 없이 그 템플릿을 넓게 삽입하는 것 외에는 거의 또는 전혀 하지 않는다는 제안을 뒷받침하지 않는다고 생각한다. 아마도 나는 증거를 잘못 읽고 있는 것 같다. 아마도 당신은 TOC 권리가 이상하거나 단지 삽입되었다고 느끼는 기사들의 목록을 제공하기를 원하십니까? 어떤 경우든 한 편집자의 행동은 템플릿의 장점인 IMO. DES 6 2005년 7월 06:44 (UTC)
  • 삭제 — 매우 제한된 수의 경우에 유용할 수 있기 때문에 보관할 것을 주장한다. 그러나 나는 그 제한된 건수는 기사에서 수작업으로 할 수 있기 때문에 삭제를 주장한다. 삭제는 지역사회가 왼쪽 정렬의 토씨(TOC) --메타, 선본(The Sunborn) 2005년 7월 5일 18:52(UTC)로 과도한 제조 사용을 제한하는 데 도움이 될 것이다.
  • 이것이 몇몇 기사의 발표에 유용하므로 보관하라. 또한 이미지, 표 및 기타 세부사항의 표시를 조정하는 도구도 있다. 때로는 기사에 2000픽셀의 넓은 이미지들을 원하지 않을 때도 있고, 때로는 20개의 짧은 TOC 라인이 기사를 방해하는 것을 원하지 않을 때도 있다.(SEWilco 5 2005년 7월 19:02 (UTC))
  • 정보 떠다니는 TOC의 사용은 현재 위키백과에서 논의되고 있다.스타일#템플릿 설명서:TOCright 이 논의는 결국 포맷 도구를 사용하는 방법과 시기에 대한 합의로 이어질 수 있다. DES 5 2005년 7월 19:25(UTC)
    • Mike는 이미 그 페이지를 연결했다. :P 그가 부동 TOCs에 대한 더 넓은 논의를 연결하였다는 것을 명확히 하기 위해, 그러나 그것은 {{}에 연결된다.TOCright}}토크 페이지도 링크하셨습니다. 그는 위에서 자신이 원래 이 템플릿을 만든 위키피디아 사람이라는 것을 반복했다. 화이트호스1 2021년 10월 4일 00:07(UTC)
  • ALVAL! —Exvar Arnfjörð Bjarmason 2005년 7월 5일 23:30 (UTC)
  • 보관 - 이 템플릿은 유용한 것으로 판명될 수 있으며, 일부 편집자가 마음에 들지 않을 경우, 그 또는 그녀는 그것을 사용하지 않을 수도 있다. 이것이 포용주의자의 철학, 즉 내가 그렇다. 업데이트: "이 템플릿을 원하지 않는 사람들은 강요하지 않아도 된다는 주장은 터무니없이 약하다. 사실상 다른 어떤 것에 대해서도 마찬가지일 수 있다."고 나는 Neuro Scientists의 의견을 읽었다." ~ 그의 주장은 좋으며, 나는 위의 SlimVirgin의 설명을 읽었는데, 사진이 왼쪽이 가장 좋을 때 오른쪽의 목차가 필요할 수도 있다는 것을 알게 되었다. 존재는 알고 있었지만 생각지도 못했던 예다. 그러므로, KEEP에 대한 나의 투표는 위의 편집자들에 대한 이들의 주장에 의해 지지된다.--GordonWattsDotCom 2005년 7월 6일 02:04 (UTC)
  • 코멘트(위의 내 의견은 보관하는 것이다): 나는 신경과학자의 글을 잘못 읽었고, 여기 있는 모든 독자들에게 사과하고 싶다. 그가 "이 템플릿을 원하지 않는 사람들은 강요하지 말아야 한다"고 도전하는 것은 사실 "삭제" 측이 사용할 수 있는 주장이었다. 하지만, "유지" 쪽에서는 "이 템플릿을 유지하기를 원하는 사람들은 삭제하지 않아도 되기 때문에 삭제하지 않아도 된다"고 말할지도 모른다는 의미로 읽게 되었다.아무거나 무장하는 것." 그래, 내가 바보처럼 보인다는 건 알아, 하지만 우리 모두 실수를 해. 그리고 난 내 말을 계속해야겠어. 왜냐하면, 결국, 내 편집 능력을 향상시키도록 자극했기 때문이야. 좀 늦었고, 집중하기에는 너무 오랫동안 깨어있었거든. 뭐, 그게 다야. 잘 지내세요, 그리고 행복한 투표! (토크라이트; 굴러다니고; 토크라이트 룰!)---고든와트닷컴 2005년 7월 6일 07:07 (UTC)
  • 코멘트(Already populated keep) 기억하라, 설정 처리를 하지 않거나 하지 않거나 하지 않는 애논 독자들이/할 수 있는/의지에 정통한 위키백과보다 더 많다는 것을.---Tznkai 2005년 7월 6일 18:19 (UTC)
  • Strong Keep 나는 이것에 대한 Grutness의 추론에 동의한다.2005년 7월 6일 22:05(UTC)
  • 보관하라. 템플릿에는 유효한 용도가 있다. 그것은 따분한 학술지를 읽는 것과 다른 위키피디아의 시각적 친근감을 향상시키는 것이다. 그렇기는 하지만, 신중하게 실행되어야 하며, 나는 이것이 Style Manual Talk 페이지를 통해 해결되기를 제안한다. --Titoxd 2005년 7월 7일 03:14 (UTC)
  • 유지 - 유용한 레이아웃 옵션 - David Gerard 2005년 7월 7일 09:58(UTC)
  • 보관 - 일부 기사는 깔끔하게 프레젠테이션을 할 수 있기 때문에 꼭 필요한 경우도 있다. - 2005년 7월 7일 16:35(UTC)
  • 분명히 보관해 두어라. 어쨌든 7월 8일 현재 그것이 일치하지만, 내 추리는 이렇다. {{의 포인트TOCright}}은 특정 페이지에 잘 어울리는 효과를 쉽게 얻을 수 있도록 하기 위함이다. 이것은 어디에서나 사용되어서는 안되며, -- 이미지 플로팅 마크업, --- 마크업, 그리고 위키백과 레이아웃의 나머지 단축키처럼, 말이 되는 곳에서만 사용되어진다. VfDing은 말이 되지 않는다. --Quuxplusone 2005년 7월 8일 18:26 (UTC)
  • 보관 - 기존의 TOC 기본 위치는 물품 흐름을 방해할 수 있다. TOC를 한쪽에 배치하면 독자는 읽기 전에 모든 섹션 이름을 볼 필요 없이 텍스트를 선형적으로 읽거나 특정 섹션을 신속하게 찾을 수 있다. 기본 설정은 첫 페이지에 도달하기도 전에 책 읽는 사람의 면에 챕터 목록을 강요하는 것과 같다. McPhail 2005년 7월 8일 22:41(UTC)
2005년 7월 5일 현재 TOCright 투표 21:27 (UTC)
유지 = 24
삭제 = 14
우리가 해결한 것이 있나?--유령 2005년 7월 5일 21:29 (UTC)
아직, 너무 빨리. --cesarb 2005년 7월 5일 21:32 (UTC)
동의하는 것은 너무 이르다. 내가 비관리자가 될 수 있다면. 화이트호스1 2005년 7월 6일 01:36 (UTC)
앞서 귀신이 지적한 것처럼 템플릿이 이미 검토되고, 투표하고, 근래에 보관되지 않았다면 "너무 이르다"는 것을 더 받아들이고 싶은 마음이 들 것이다. 이 TFD에 전보를 친 편집자는 귀신이 지적하기 전에 이전의 결정을 몰랐다고 말한다. 그럴 만도 하다. 그런데 왜 이전의 결정이 우리의 관심을 끌게 되었는지, 이제 와서 이 재투표가 계속되고 있는 것일까? 그리고 특히 많은 다수가 원래 투표와 정확히 같은 방향으로 추세를 보이고 있기 때문에? 이번 역시 '지키기' 결정으로 끝난다면 다음 주에도 비슷한 서커스를 기대해 봐야 할까. 아니면 우리의 결정이 전혀 의미를 가지기 위한 것인가?
만약 이것이 (모든 이성을 넘어서) 계속된다면 적어도 "너무 이르다"고 외치는 소리가 이해충돌의 기미가 보이지 않도록 사전에 제한(일시적 또는 그 밖의 것)을 설정할 수 있을까?/ 신경과학자TC 2005년 7월 6일 01:47(UTC) 편집: 화이트호스, 당신의 타임 스탬프 템플릿이 작동하지 않는다. 그것들은 당신의 모든 게시물에 동일한 시간을 등록하고 있고, 또한 당신의 뒤를 따르는 사용자들에게 영향을 주고 있다. 네가 정리할 때까지 내가 그것들을 제거해도 될까?/ 신경과학자TC 2005년 7월 6일 01:47(UTC)
아까 내 토크 페이지에서 누군가가 이것을 지적했어 - 분명히 내가 해결하지 못했지만, 나는 그것을 해결했다고 생각했어. 신경과학자, 이 페이지를 '제거'하면 내가 만들고 서명한 코멘트에서 타임 스탬프 텍스트를 삭제하거나 모든 타임스탬프를 대량으로 제거하기 위한 관리 마법인지 잘 모르겠다. 주머니쥐라면. 내 Talk 페이지에서 잠시 동안 온라인 상태가 될 것임을 분명히 하십시오.
믿었던 것이 해결되었다. 작업 후 업데이트하지 않고 내 Talk 페이지 및 날짜 설명에 링크해야 하는 경우 네 개의 tild로 서명한다. 필요한 경우 내 Talk 페이지를 참조하십시오. 화이트호스1 2005년 7월 6일 03:20 (UTC)
이전 차이점을 가리켜 보십시오. 또한, 토크 페이지에 이 사실을 언급할 가치가 있을 수도 있고, 다른 사람들은 전혀 모를 것이다. - 2005년 7월 6일 02:47 (UTC)
우리는 삭제에 찬성하는 대다수가 없다고 결의했다. 사용자의 거의 3분의 2가 이 템플릿이 적어도 특정한 제한된 방법으로 유용하다고 느낀다. 개인적으로 나는 MoS가 언제 그것이 받아들여질 수 있는지 명시하도록 업데이트 되어 있고, 나는 이것이 행해지고 있다고 본다. 다른 사용자들도 비슷한 생각을 가진 것 같다. 또한 대부분의 사용자들은 이 템플릿이 널리 사용되어야 한다고 생각하지 않으며 기본 템플릿이 되어서는 안 된다고 생각하는 것 같다. —Morven 2005년 7월 8일 06:16 (UTC)

미리 보기 성능 저하 유지: 말을 못 믿겠다면 없는 차세대 캐릭터들. 예상치 못한 일이라는 데는 동의하지만 실제 텍스트로 가기 위해 독자들에게 1.5페이지를 아래로 스크롤하도록 강요하는 것보다는 낫다.--Max E C 05:23, 2006년 1월 7일 (UTC)[]

2005년 7월 8일 현재 TOCRight 투표(UTC)
유지 = 32
삭제 = 14
이것은 cesarb의 "취약 삭제"를 삭제로 간주하고, Tabu si da yu는 삭제 동의를 철회하고자 하는 것을 유지 투표로 간주한다.투표 업데이트~ 신경과학자 T C 2005년 7월 7일 19:45 (UTC)Update~ 신경과학자 T C 2005년 7월 8일 19:50 (UTC)

나는 제안자의 삭제 동의 철회가 투표를 효과적으로 중단시킬 수 있다고 생각한다; 규칙집을 통해 문제를 해결할 수 있는 (또는 축제의 새로운 라운드로 이어질 수 있는) 토론이 Style Manual Talk 페이지에서 진행되고 있다.~ 신경과학자 T C 2005년 7월 6일 16:32(UTC)

꼭 그렇다고 할 수는 없죠. 다른 사람들은 이것을 삭제하기를 원할지도 모른다. 지금 생각해 보면, 이것이 그 진로를 걷게 하는 것이 가장 좋을 것이다. - 2005년 7월 7일 04:11 (UTC)
정말 무의미한 운동이라니... 나는 내가 삭제하려는 더 무모한 움직임을 본 적이 없다고 생각한다. 이 투표는 이전 판례를 무시한 채 실행되고 있으며 삭제 기준을 충족하지 못했으며, MOS 규칙에 근거가 없으며, 사전 결정된 정지 시간이 없으며, 철회되었다가 "무시"되었다. 이번 연습에서 분명한 것은 삭제(28~14명)보다 100% 더 많은 유권자가 이를 지키길 원한다는 점이다./ 신경과학자TC 2005년 7월 7일 04:51(UTC)
나의 우둔함은 기본적으로 TfD 토론이 7일 동안 지속된다는 것이다. 나는 그것이 정상적인 "예상적으로 결정된 정지 시간"이라고 추측한다. 나는 TBDY가 그의 개인 투표를 바꿨다고 생각하지만 그가 그 지명을 '기권'한 것은 확실하지 않다. 여기서 삭제해야 할 어떠한 합의도 일어날 것 같지 않다는 데 동의하며, 이 토론을 따라온 사람이라면 누구나 스타일 매뉴얼 토크 페이지에서 토론을 읽고 코멘트를 할 것을 촉구한다. DES 2005년 7월 7일 14:43(UTC)
내가 말했듯이, 이걸 본 적이 없어. 만약 투표가 유지된다면, 무엇이 문제인가? 이 하위조항 때문에 다시는 이런 일이 일어나지 않을 것이며, 기사의 토크 페이지에도 메모할 수 있기 때문이다. - 타부시 다 유 7월 7일 2005년 7월 15:34 (UTC)
DES & Tau Shi da yu, 나의 관심사는 공정성이다. 이건 정말 작은 문제라서, 우리 중 누구도 정말로 화가 나거나 그런 것은 아니라고 생각한다; 나는 단지 일을 올바르게 하는데 있어서 최소한 토큰 제스처가 있다는 것을 확실히 하기 위해 노력하고 있다. 7일째 되는 날, 나는 이것이 표준적인 규칙이라는 것을 알지 못했다. 만약 그렇다면, 훌륭하다. Re recurl, TBSDY가 이 페이지 상단에 쓴 쪽지 입니다.
이제 이것이 (화산 목록)에 유용할 수 있는 몇 가지 기사를 볼 수 있다. 다른 사용자가 삭제하기를 원할 수 있지만, 이것을 철회하고 싶다.
그것은 그가 삭제 동의를 철회하고 있다는 것을 의미한다. 삭제하기를 원하는 사람들과 그것을 유지하기를 원하는 사람들이 항상 있을 것이지만, 그 동의가 진행되려면 투표에 참여해야 한다. 마지막으로, 내가 전에 지적했듯이, 그 기준은 움직임을 표로 표시하는 것을 금지하지는 않지만, 그들은 그것이 모든 삭제 기준을 무효화시키기 때문에 템플릿을 삭제할 근거가 없다는 것을 나타낸다. 어떤 이유로든 템플릿이 삭제된다면, 그 템플릿은 기준에 어긋나는 방식으로 수행될 것이다. 새로운 것은 아니지만, 여기 있다.~ 신경과학자 T C 2005년 7월 7일 16:30 (UTC)
템플리트는 페이지의 모양과 구성을 개선할 수 있는 한 가지 더 많은 방법과 유연성을 제공한다. 물론 그것을 포함시킬지 말지 궁극적으로 결정하는 것은 좋아 보이는 것에 대한 각 기고자의 주관적인 감각에 달려 있을 것이다. 일반적으로, 사용자가 더 많은 제어권을 가지고 있고 더 많은 옵션을 가질수록 설계의 전반적인 품질이 더 좋다는 것이 나의 견해다. 우리는 또한 페이지의 오른쪽에 있는 부동소자(그림, 표 등)가 HTML 사양에 포함된 것도 고려해야 한다. 그 이유는 다른 출판 도구에도 있다. 그 이유는 레이아웃을 완성하기 위해 이 옵션이 필요할 때가 있기 때문이다. 사용자들에게 제한된 도구 세트를 제공하는 것은 그들을 좌절시키고 멋진 페이지를 표시하는 우리의 능력을 약화시킬 뿐이다. -asx- 18:17, 2005년 7월 11일 (UTC)[]
계속, 학교 상담사를 좋은 예로 보아라. 나는 사진을 제대로 찍는데 어려움을 겪었고, TOC를 옮기는 것이 많은 도움이 되었다.whicky1978 18:55, 2006년 6월 17일 (UTC)[]
프로포즈

이 곳에서는 이 템플릿이 사용되거나 널리 사용되어서는 안 되며, 오히려 다양한 특별한 경우에 사용할 수 있어야 한다고 믿는 사람들이 거의 없는 것 같다. 만약 이 템플릿이 기사에 사용되기 전에 토크 페이지에서 제안되고 정당화되어야 하고 사람들이 그것이 정당하다고 동의할 때에만 기사에 추가되어야 한다면 사람들은 여전히 이 템플릿에 문제가 있을까? (알고 있어, 알아, 더 관료주의적인 건 알지만, 복잡한 시스템이 될 필요는 없고, 장기적으로 봤을 때 내가 재점검하는 데 많은 어려움을 줄일 수 있을 거야.) Joe D (t) 2005년 7월 9일 00:02 (UTC)

  • 나는 위의 아이디어에 동의하지 않는다. 내용과 형식 모두에 대한 주요 편집이 될 수 있고 논의 없이 만들어지는 한 말이다. 만약 누군가가 확실하지 않다면, 그들은 대화 페이지에서 토론하는 것을 선택할 수 있다. 만약 누군가가 그 용법에 반대한다면, 적절한 대화 페이지에서 합의를 구해야 한다. 이것은 다른 편집 분쟁과 똑같다. 어떤 경우든, 이러한 종류의 제안은 현재 진행 중인 MOS 논의의 일부로서 위에서 연계되어 더 잘 논의될 것이다. 적어도 그곳의 한 사람은 우리가 어떤 상황에서 떠다니는 TOCs의 소송을 지지하는 MOS에서 실제적인 변화를 일으킬 준비가 되어 있다고 생각한다. DES 04:20, 2005년 7월 10일 (UTC)[]
오른쪽 정렬 TOC의 좋은 예

여기에 오른쪽 정렬 TOC의 좋은 예가 있다. 이 페이지를 기본 TOC로 미리 보면 얼마나 더 나쁜지 알 수 있다. 이것은 사용자가 TOC의 배치를 통제할 수 있도록 하는 것의 중요성을 잘 보여준다.

-asx- 19:50, 2005년 7월 11일 (UTC)[]