위키백과:날짜 형식 및 연결 여론조사

Wikipedia

다음 토론은 종료됩니다. 수정하지 말아주세요. 후속 의견은 해당 토론 페이지에서 작성해야 합니다. 이 토론에 대해 더 이상 편집해서는 안 됩니다.


이 여론조사는 날짜 연결/연결 해제 및 자동 서식(로그온한 편집자의 설정된 선호도에 표시되는 날짜 형식을 자동으로 변경하는 소프트웨어) 사용과 관련된 문제를 다룹니다. 여론조사는 2009년 3월 30일 00:00(UTC)부터 진행되며, 2009년 4월 13일(UTC) 23:59(UTC)에 종료됩니다.

분쟁의 연혁

MOSNUM talk 등에서 오랜 토론 끝에, 2008년 8월에 실시된 여론 조사와 이후의 토론을 통해 자동 포맷 목적으로 링크하는 날짜가 감소(즉, 중단)되었습니다. 그런 다음 여러 편집자가 대규모 매뉴얼, 자동화 및 반자동화된 날짜 연결 해제를 진행했습니다. 그러나 몇몇 편집자들은 WT에서 이 변경에 반대한다고 밝혔습니다.MOSNUM과 연결 해제된 편집자들의 토크 페이지. 토론은 WT에서 계속되었습니다.MOSNUM은 커뮤니티 합의를 정확하게 대표할 수 있는 충분한 편집자가 이전에 이 문제에 대한 의견을 제공했는지 여부에 대해 설명합니다. 11월 말경, 날짜 연결/연결 해제 및 자동 포맷에 관한 두 개의 병렬 RFC가 출시되어 수백 명의 편집자들로부터 의견을 받았습니다.

이러한 RFC는 몇 가지 사항에 대한 지침을 제공했지만, 그 지침이 토론의 모든 측면을 해결했는지에 대해서는 의견이 분분합니다. 질문의 표현과 구조에 내재된 편향성에 대한 주장도 있었습니다. 이 RfC는 (i) 날짜 자동 포맷이 필요한지 여부 및 (ii) 날짜 조각의 연결이 사용되어야 하는지 여부 및 사용된다면 어떤 조건에서 사용되는지 여부를 명확히 하고자 합니다.

여론조사

여론조사는 2009년 3월 30일에 시작하여 2주 동안 진행될 예정입니다. 사용자는 제안서를 검토하고 세 섹션 모두에서 투표할 것을 권장합니다. 자동 포맷, 월-일 연결, 연도 연결. 여론 조사가 끝나면 2주 동안 논의할 수 있습니다. 1차 여론조사 결과가 어떻게 구현될지를 보기 위해 필요하다면 4월 말에 있을 2차 여론조사가 검토될 것입니다. 개별 당사자의 의견은 매우 환영되지만, 모든 스레드 토론은 대화 페이지로 이동됩니다.

자동포맷

배경문

위키피디아 커뮤니티는 날짜 자동 서식이라는 개념을 지지합니까?

스코프 자동 포맷은 등록된 사용자가 원하는 디스플레이 형식을 선택할 수 있도록 업데이트를 표시하는 방법입니다. 이를 구현할 수 있는 다양한 방법이 제안되었습니다. 여기서 제기되는 질문은 커뮤니티가 자동 포맷의 기본적이고 공통적인 요소를 원하는지 여부입니다.

날짜 형식이 무엇입니까? 영어 사용자들은 주로 2009년 3월 11일(MDY, 주로 북미)과 2009년 3월 11일(DMY, 주로 다른 곳)의 두 가지 주요 날짜 형식을 사용합니다. 다른 날짜 형식은 실행 중인 텍스트에서는 덜 일반적으로 사용되지만 템플릿에 대한 입력 매개 변수로 자주 사용됩니다. 2009-03-11(YMD는 ISO 스타일 형식).

날짜 자동 포맷이란 무엇입니까? 기사에 표시된 날짜가 "특별:"에 따라 등록된 사용자의 설정을 반영하여 자동으로 변경될 수 있도록 하는 시스템입니다.환경설정/일시", 등록되지 않은 사용자(IP)는 환경설정에 액세스할 수 없습니다. 2003년에 도입된 기존의 자동 포맷 시스템(Dynamic Dates, 여기에 개요)은 자동 포맷 날짜를 식별하기 위해 이중 괄호 링크 구문을 사용해야 합니다.

위키백과의 소프트웨어에 대한 최근의 업데이트는 링크 기반 마크업([[[[3]]] [[2009]]) 대신 함수({{#formatdate}})를 사용하여 날짜를 자동으로 포맷할 수 있게 해줍니다. 기능은 링크("2009년 3월 30일") 없이 등록된 사용자의 기본 설정에 따라 자동 형식화된 일반 텍스트 날짜를 표시합니다. 등록되지 않은 사용자와 환경설정을 하지 않은 사용자를 위해 기본 날짜 형식을 정의하는 옵션을 추가합니다. 원래 시스템과 마찬가지로 기사의 모든 날짜는 일관성을 보장하기 위해 마크업이 필요합니다.

자동 포맷이 허용되면 어떻게 됩니까? 개발자와 편집자가 기존 소프트웨어의 수정된 버전 또는 새로운 마크업 또는 템플릿 체계를 기반으로 시스템을 구축하는 데 사용할 사양에 대한 합의를 구합니다. 날짜는 그에 따라 표시됩니다.

자동 포맷이 거부되면 어떻게 됩니까? 이전 시스템에서 사용한 마크업은 계속 제거되며, 기사의 전체 형식과 일치하지 않는 날짜는 수동 또는 자동 수단을 사용하여 수정됩니다.

에 대한 설명문

날짜 자동 형식사용자에게 더 많은 옵션제공하는 입니다. 날짜가 제시되는 방식에 대해 사용자가 개인적인 통제를 행사할 수 있습니다. 이것은 새로운 개념이 아닙니다. 위키백과의 기존 시스템은 2003년부터 사용되어 왔으며, 개인화된 날짜 형식은 운영 체제에서 수십 년 동안 선택 사항이었습니다. 이는 컴퓨터, 아이팟, 휴대전화 및 기타 모든 유형의 개인 기술과 인터페이스하는 방식에서 사용자 선택권이 증가하는 추세를 자연스럽게 확장한 것입니다.

이 목표를 넘어 자동 포맷은 일관된 날짜 형식을 제공하는 기능을 향상시킵니다. 현재 스타일 매뉴얼에서는 지역별 사용법 및 편집 합의에 따라 DMY 또는 MDY 스타일로 날짜를 포맷할 수 있습니다. 표준 형식이 없기 때문에 페이지가 개별적으로 일치하지만 기사 모음으로 간주될 때 스타일적으로 상충되는 상황이 발생합니다. 이것은 전체 출판물에서 일관된 형식을 사용하는 다른 백과사전과 다릅니다.

많은 부분이 자동 포맷의 복잡성으로 이루어져 왔지만, 현실은 위키피디아의 편집자들이 거의 6년 동안 날짜 마크업을 사용해왔다는 것입니다. 예, 날짜는 기능을 활성화하기 위해 특별한 형식이 필요합니다. 하지만 이는 위키피디아의 거의 모든 디스플레이 옵션에 필요한 것과 다르지 않습니다. 마크업을 통해 볼드 및 이탤릭체 텍스트 또는 섹션 헤더와 같은 가장 기본적인 옵션에서 템플릿 및 테이블과 같은 더 복잡한 기능에 이르기까지 기사 표시를 향상시킬 수 있습니다. 기존 편집 도구를 사용하여 모든 대규모 변경 사항을 자동화할 수 있습니다. 초보 편집자들에게 미치는 영향에 관해서는 위키피디아는 그들이 인터페이스의 모든 면을 마스터할 것이라고는 전혀 예상하지 못했습니다. 사실, 새로운 사용자들은 항상 철자법, 문법 또는 포맷 옵션에 대해 걱정하지 않고 기여하도록 권장되어 왔습니다.

현재 편집자들과 위키피디아의 개발자들 간의 지속적인 논의는 기존 시스템에 대한 우려를 해결하기 위한 방법에 초점을 맞추고 있습니다. 그 중 가장 중요한 것은 링크와 등록되지 않은 사용자들이 보는 것입니다. 이러한 문제들은 개선된 시스템의 적극적인 개발을 통해 해결되고 있으며, 그 요소들은 이미 시스템 소프트웨어에 통합되어 있습니다. 검토 중인 다른 옵션은 사이트 전체 표준에 대한 제어를 향상시키는 동시에 원하는 경우 개별 기사에 페이지별 기본 날짜 형식을 태그 지정할 수 있는 향상된 기능을 추가할 수 있습니다. 또한 데이터 마크업은 자동화된 타임라인, 자동화된 "역사상 오늘" 페이지, 데이터베이스 덤프를 통한 효율성 향상과 같은 새로운 기능을 개발하는 데 중심적인 역할을 하는 것으로 확인되었습니다. 또한 자동 포맷은 템플릿의 "날짜 형식" 매개변수에 대한 현재의 필요성을 대체합니다.

독자와 편집자 모두에게 이점은 분명합니다. 날짜 자동 형식을 사용하면 모든 독자에게 기사가 제공되는 방식에 일관성이 향상되고 편집자가 균일하고 전문적인 모습을 보여주는 데 도움이 되며 등록된 사용자에게 인터페이스를 개인화할 수 있는 옵션을 제공합니다. 간단히 말해서, 이 토론은 위키백과의 모든 사용자에게 선택의 폭을 넓히는 것입니다.

반대 성명

해결할 문제는 없습니다. 날이 먼저 오든, 달이 먼저 오든 (1월 3일, 1월 3일)이 먼저 오든, 모든 영어권 사람들은 두 가지를 모두 인식합니다; 미군은 많은 캐나다인들과 마찬가지로 DMY를 사용합니다; 반면에 신문을 포함한 북미 이외의 많은 출판물들은 MDY를 사용합니다. 이처럼 혼재된 환경을 고려할 때, 독자들이 신경쓰기는커녕, 심지어 알아채지도 못할 것입니다. 기사에 사용되는 형식입니다. 당사의 최고 전문성 기준을 대표하는 특집 기사는 지난 9월 자동 포맷을 포기하고 현재는 단순한 고정 텍스트 날짜만 사용하고 있습니다. 특집 기사 후보에서 거의 언급되지 않았습니다. 한 사용자가 7,000개 이상의 기사에서 연결 해제 및 수정 날짜를 가지고 있지만 소수의 반대 의견만 접수했습니다.
두 클래스의 사용자가 있어서는 안 된다는 기본 원칙. 일부 등록된 편집자들은 다른 사람들과 다른 날짜 형식을 볼 수 있기 때문입니다(위키백과 참조:DONOTLINKDATE), 날짜 형식이 일관되지 않을 수밖에 없습니다.
복잡하고 힘들죠. 수천만 개의 날짜를 다음과 같은 마커로 태그하고(키 입력 횟수를 두 배로 늘린다 – 추가되더라도), 거의 300만 개의 기사를 특별히 태그하여 기본 날짜 형식을 설정하는 것은 특정 형식으로 날짜를 보는 데 드는 매우 작은 이점을 지불하는 엄청난 비용이 될 것입니다. 그리고 새로운 편집자와 일상적인 편집자의 문제를 복잡하게 만들 것입니다. MOSNUM에는 마크업이 필요 없는 날짜 형식에 대한 단순하고 잘 받아들여지는 규칙이 이미 있습니다. Wiki Media의 최고 기술 책임자인 Brion Vibber는 "모든 날짜 자동 형식을 삭제하는 것이 제 개인적인 권장 사항입니다."라고 말했습니다.
메타데이터 오류입니다. 메타데이터를 생산하기 위해서는 마크업이 필요하지 않습니다. 우리는 이미 많이 사용되지 않는 위키피디아 제한 구글 검색(site:en.wikipedia.org )과 카테고리 검색을 포함한 강력한 검색 도구를 보유하고 있습니다. 마크업이 유용하려면 편집자가 모든 마크업 날짜를 링크된 것처럼 볼 수 있는 옵션이 필요합니다. 또 다른 복잡성 레이어입니다. 여기서 링크되는 날짜 또는 연도 페이지는 해당 주제와 어떤 식으로든 관련된 이벤트가 있다는 것만 공통 요소인 수천 개의 기사 목록을 생성합니다. 해당 날짜 또는 연도에 발생했습니다. 이러한 낮은 품질의 메타데이터는 향후 시간 기반 프로젝트의 편집자에게는 사실상 아무런 가치가 없습니다.
개발 위험. 원래 자동 포맷의 실패는 주로 커뮤니티에서 합의된 사양(명확한 목표) 없이 행동하는 프로그래머가 설계를 임시로 부과한 것 때문입니다. 제안된 소위 수정 사항은 범위와 기능이 제한적이며 커뮤니티에서 동의하지 않았습니다. 우리는 향후 몇 년 동안 솔루션을 한 단계 한 단계씩 고정하는 위험을 감수해서는 안 되며, 일반 편집기와 훨씬 더 멀리 떨어져 있는 점점 더 복잡한 구문을 요구합니다. 이러한 문제 중에는 깨지지 않는 공간, AD/BC, 삭감된 날짜, ISO그레고리안/줄리안 날짜가 포함됩니다. 날짜 범위(원 시스템이 관련된 엉성함과 강제적인 반복을 피하는 것)는 상당한 도전이 될 것입니다.

응답 자동 형식 지정

선택에 대한 간결한 설명과 함께 ONE 옵션으로 투표를 표시해 주시기 바랍니다. 당신의 설명은 공동체의 합의를 결정하는 데 중요합니다.
저는 자동 포맷의 일반적인 개념을 지지합니다.
  1. 서포트. 모든 날짜를 하나의 형식으로 만들기 위한 사용자 선호도를 갖는 것에는 크게 관심이 없지만, {{#formatdate}}와 같이 {{defaultDATEFORMAT} 마법어와 결합하여 전체 페이지의 기본값을 설정하려면 모든 사용에 대해 모든 날짜 처리 템플릿에 "dateformat" 매개 변수를 사용하도록 강제하거나 모든 날짜 처리 템플릿에 "date" 매개 변수에 임의의 가비지를 허용하고 모든 날짜 처리 템플릿을 포기하도록 강제하는 것을 방지해야 합니다. 날짜 조작의 가능성. 저는 또한 기능을 원하는 사람들이 기능을 가질 수 있도록 허용하지 않는 과 솔직히 FUD의 냄새와 실제 실체가 없는 논리적 오류에 대한 위의 "반대" 주장은 의미가 없다고 봅니다. 아노미⚔ 2009년 3월 29일 (UTC) 23:14 답변[답변]
  2. 서포트. 저는 독자로서 날짜를 단일 스타일로 자동 형식화하는 것이 훨씬 더 멋지고 쉽다고 생각합니다. 저는 -또는 -v.-our 또는 -ize v.ise와 같은 철자 변형보다 형식을 바꾸는 것이 훨씬 더 주의를 산만하게 한다고 생각합니다. Eluchil404 (talk) 2009년 3월 30일 00:01 (UTC)답장[답장]
  3. 서포트. 저는 부분적으로 아노미를 지지하지만 메타데이터로 업데이트를 표시하면 다른 방법으로는 할 수 없는 흥미로운 일을 할 수 있기 때문입니다. 자동 서식에 반대하는 주장 중 실제로 날짜 연결에 반대하는 주장이 너무 많습니다. dm (talk) 2009년 3월 30일 (UTC) 00:02 (답변)
  4. 서포트. 날짜 선호도를 미국 형식으로 표시하도록 설정했기 때문에 날짜가 표시될 것으로 예상합니다. 또한 자동 포맷은 편집 왜곡을 방지하는 데 도움이 됩니다.-Jeff 00:04, 2009년 3월 30일 (UTC)답장[답장]
  5. 에 따라 지지합니다. 저는 항상 미국 형식을 선호합니다. 다른 문화적 차이(예: 영국 대 미국 철자법)와 달리, 이것은 쉽게 구현될 수 있는 것이며, 그렇게 실행되었습니다. 지난 달, 저는 한 형식을 사용해야 할지 다른 형식을 사용해야 할지에 대한 다소 어리석은 불화에 부분적으로 참여했습니다. 일부 사람들이 더 이상 기여하고 싶어하지 않게 했다고 생각합니다. 그건 전혀 불필요한 IMO입니다. --♬♩ Hurricane think (talk) 00:51, 2009년 3월 30일 (UTC)응답하라[답변]
  6. 서포트. 아노미의 의견에 동의합니다. 아노미와 새로운 사용자가 볼 수 있는 다른 기본값(현재 기본값은 모두 포맷하지 않음)을 설정하는 것만으로 문제의 대부분이 해결될 것이라고 생각합니다. 저는 그것이 간단한 구성 변경이 될 것이라고 믿습니다. 미스터 지맨 2009년 3월 30일 (UTC) 00:59 답변[답변]
  7. 지원 자동 형식은 템플릿 인용문을 한 기사에서 다른 기사로 이동할 때 유용할 수 있습니다. 다른 기사는 날짜 형식을 변경할 필요 없이 인용문을 복사하거나 공유할 수 있습니다. 본문에서는 덜 유용해 보이지만 인용문에서는 그럴 가치가 있어 보입니다. Eubulides (talk) 2009년 3월 30일 01:27 (UTC)답장[답장]
  8. 자동 연결 없이 자동 포맷을 지원합니다. (이로 인해 대부분의 "반대" 표가 무효화됩니다.) 기사 내에서 일관된 날짜 형식을 유지하기 쉽고 메타데이터 수집을 쉽게 할 수 있습니다.Arthur Rubin (talk) 2009년 3월 30일 02:05 (UTC)답장[답장]
  9. 지원 - 저에게는 큰 문제가 되지 않지만, 아픈 경험에 의하면 우리가 이렇게 하지 않으면 불만이 쇄도할 것이라고 합니다. 그러나 자동 형식화 솔루션은 자동 연결을 초래해서는 안 되며, 의도적으로 연결을 허용해야 하며, 일상적인 독자가 보기 기본 설정을 설정할 수 있어야 합니다(는 특별한 의미가 아닙니다).특히 쿠키를 설정할 수 있는 방법이며, 날짜 표시에 대해 페이지별로 "올바른"(주제별/위치별) 기본값을 설정할 수 있어야 합니다. 이 모든 것을 하지 않으면 다시 전체 추악한 싸움으로 돌아올 것입니다. Gavia immer (talk) 2009년 3월 30일 02:46 (UTC)답장[답장]
  10. 지원, 아노미가비아 이머.-gadfium 2009년 3월 30일 03:20 (UTC)응답하라[답변]
  11. 지원은 반드시 자동 연결이 필요한 것은 아니지만, 메타데이터를 적절하게 처리할 수 있지만, 이를 통해 프로세스를 용이하게 할 수 있습니다. 재사용 가능한 데이터로 포맷된 기사로 이동하는 것은 일반적으로 필요한 개발입니다. 위키놈의 수와 봇 프로그래머의 독창성을 고려할 때 구현에 큰 어려움이 없어야 합니다. DGG (talk) 2009년 3월 30일 03:31 (UTC)답장[답장]
  12. 특히 개발자들이 시스템에 링크가 없는 자동 포맷 기능을 이미 추가했다는 점을 감안하면 지원이 가능합니다. DA에 대해 표현된 다른 많은 우려 사항은 쉽게 해결할 수 있습니다. 예를 들어, "#formatate" 표현은 "{{D}}"와 같이 훨씬 짧은 이름을 가진 템플릿을 사용하여 쉽게 호출할 수 있습니다. 또한 현재 우리가 제공하는 형식의 혼합과는 대조적으로, 보다 전문적인 모습을 보여주기 위한 수단이기도 합니다. (다중 날짜 형식의 가이드라인은 대부분의 다른 전문 출판물과 상충되며, 둘 중 하나를 선택합니다.) 우리의 기사는 모음으로 볼 때 일관성이 없어 보입니다. Britannica나 Times가 DMY와 MDY를 혼합하여 사용하는 것을 마지막으로 본 것이 언제입니까?) --Ckatzchatspy 04:33, 2009년 3월 30일 (UTC)답장
  13. 지원은 엘루칠 404에 따라. 또한 철자 지역화 자동 서식을 지원합니다. AKAF (talk) 2009년 3월 30일 06:58 (UTC)답장[답장]
  14. 서포트. 자동 포맷이 도입되기 전에는 날짜를 어떻게 포맷해야 하는지에 대한 긴 줄이 있었습니다. 일부에서 날짜 연결 해제를 시작한 것과 마찬가지로 최근에 다시 표시된 것 같습니다. -- 사용자:문서
  15. 서포트. 자동 포맷은 독자에게 의미가 있습니다. 그러나 링크 프리 옵션을 사용할 수 없다면 반대표를 던졌을 것입니다. YLee (talk) 2009년 3월 30일 09:17 (UTC)답장[답장]
  16. 서포트. 그대로 두십시오(혹은 그대로 두십시오). 이것과 저것 그리고 나머지 2009년 3월 30일 09:31 (UTC)답장[답장]
  17. 서포트. 자동 형식 기능으로 날짜 형식을 둘러싼 논쟁과 잠재적 충돌을 방지할 수 있었다는 점을 이해하고 말입니다. --Born2flie (talk) 2009년 3월 30일 (UTC) 09:36 (답변)
  18. 지원 날짜의 메타데이터 가능성. 조이. 특별한 포맷 날짜에 대한 강요는 여전히 없을 것이며 봇이 하지 않은 것도 분명 다시 할 수 있습니다. 거짓 주장은 씻기지 않습니다. -- billinghurst (talk) 2009년 3월 30일 (UTC)10:23 (답변)
  19. 이점에 주어진 모든 이유를 지원하는 것은 반대하는 사람들이 우리가 생각하기를 바라는 것처럼 "복잡하다"고 간주하기에는 너무 간단합니다.Lock Coletc 10:53, 2009년 3월 30일 (UTC)답장[답장]
  20. 서포트. 이 기능을 사용하는 것은 편집자에게 거의 부담이 되지 않으며(추가한 날짜에는 항상 사용합니다), 영구적인 미국 대 영국 날짜 형식 편집 충돌을 해결하는 데 유용한 방법입니다. 봇과 다른 편집자들의 일방적인 링크 해제 운동에 강하게 반대합니다. --DAJF (talk) 2009년 3월 30일 (UTC)11:44 (답변)
  21. 서포트. 환경이 혼재되어 있을 수 있지만 위키백과는 하나의 통합된 프로젝트입니다. 같은 글이라도 날짜 형식이 맞지 않는 글을 읽으며 살 수 있지만, 위키백과 모두가 표준을 준수하면 더 좋을 것 같습니다. æron 전화 집으로 2009년 3월 30일 12:42 (UTC)답장[답장]
  22. 서포트. 날짜 형식은 사소한 것이지만 전체 프로젝트에서 표준 형식을 갖는 것이 매우 중요합니다. --Unionhawk (talk) 2009년 3월 30일 (UTC)12:58 (답장)
  23. 서포트. DAF당. 저는 "봇과 다른 편집자들의 일방적인 링크 해제 캠페인"에 반대하는 사용자 중 한 명이었고, 다른 쪽에서 "엘리트주의"라는 이상한 비난이 쏟아지는 등 상당히 무례한 대우를 받았습니다. 오토포맷 자체와는 무관한 오토포맷에 대한 뿌리 깊은 이유가 있는 것 같습니다. 저는 마침내 이것에 대한 프로젝트 전반의 여론조사를 보게 되어 기쁩니다. 비록 이것이 왜 먼저 이루어지지 않았는지 완전히 혼란스럽습니다! 미등록 사용자에게 날짜가 일관되게 표시되도록 하는 조치도 지지합니다. - BillCJ (talk) 2009년 3월 30일 (UTC) 13:03 (답변)
  24. 서포트. 모든 날짜의 일반적인 형식은 모든 기사에 대해 일관된 출력을 제공합니다. 자동 포맷 시 날짜를 연결할 수 있도록 소프트웨어에 제안된 개선 사항은 사람들이 원하는 방식으로 기사 텍스트에 실제로 있는 내용에 대해 걱정하지 않도록 훨씬 더 매력적인 솔루션입니다. Keith D (talk) 2009년 3월 30일 (UTC) 13:26 답변[답변]
  25. 지지 - 기사 전반에 걸쳐 일관성을 유지함으로써 얻을 수 있는 이점이 잠재적인 문제보다 더 많다고 생각합니다. Camw (talk) 2009년 3월 30일 13:36 (UTC)답장[답장]
  26. 지원 - 최종적으로 모든 기사에서 일관성 있게 제공되는 날짜를 훨씬 쉽게 읽을 수 있습니다. 사람들이 개인 취향으로 날짜를 변경하기 위해 기사를 편집하는 것을 멈출 것입니다. 가장 중요한 것은 위키피디아는 독자들에게 기사를 제공하는 것이지, 편집자들에게 취미를 제공하는 것이 아닙니다. 추가적인 키 스트로크와 기술적인 이유에 대한 이러한 주장들은 다소 침묵하기 때문입니다. Martin451 (talk) 2009년 3월 30일 14:02 (UTC)답장[답장]
  27. 페이지에서 일관된 날짜 형식을 쉽게 적용하기 위해서만 지원합니다(날짜 환경설정이 직접 설정되어 있지 않습니다). 포맷 함수가 {{#date:...}와 같이 구문이 짧다면.}} 사용하기 쉽고, 이해하기 쉬우며, 날짜가 들어간 템플릿을 제외하는 것이 더 쉬워질 것이고, 날짜를 추가하는 모든 편집자 대신 주어진 기사의 적절한 날짜 형식에 대해 한 번만 걱정하면 됩니다. --Amalthea 14:17, 2009년 3월 30일 (UTC)답장[답장]
  28. 서포트. 저는 ISO 날짜를 사용하는 사용자입니다. 저는 ISO 날짜를 사용해 주세요. 만약 그것이 진행된다면 저는 그것을 놓칠 것입니다. 반대 성명서는 제가 다르게 생각하게 만드는 데 아무런 도움이 되지 않습니다.The Sidhekin (talk) 2009년 3월 30일 14:51 (UTC)답장[답장]
  29. 지원, 날짜 자동 포맷은 기본 설정 또는 기본 설정으로 사용자의 기사를 일관되게 볼 수 있습니다. 이 기능은 불행하게도 이전에 연결된 날짜와 관련이 있지만 주변에 있고 사용되었습니다. 기능으로 합의되고 커뮤니티가 정확한 동작과 마크업을 결정하면 기술 문제를 극복할 수 있습니다. 또한 기능을 통해 인용 템플릿을 쉽게 사용할 수 있습니다.Ost (talk) 2009년 3월 30일 (UTC) 14:56 답변[답변]
  30. 원하는 대로 날짜와 시간을 표시했으면 합니다. --Morten (talk) 2009년 3월 30일 (UTC) 14:59 (답장)
  31. 지원Bellhalla (talk) 2009년 3월 30일 (UTC) 15:05 답변[답변]
  32. 지지 - 저는 여러 가지 이유로 지지합니다. 1) 날짜를 모두 동일하게 보지 않는 사용자의 경우 2) 외부 코드를 저장하기 때문에 (많지는 않지만 합산될 수 있습니다. 저를 믿으세요. 또한 자동 포맷이 삭제되었을 때, 우리는 다음과 같은 형태의 기사(2007-02-03 또는 2007-30-11)에 날짜를 남겨두었습니다. 처음에 제거할 때는 계획이 잘 안 된 것 같습니다. BIGNOLE (연락처) 2009년 3월 30일 15:15 (UTC)답장[답장]
  33. 지원 - 위키링크 없이 자동 포맷하는 것이 저에게 좋은 해결책인 것 같습니다. --TreyGeek (talk) 2009년 3월 30일 (UTC) 15:44 (답변)
  34. 일반적인 개념을 지원하지만 구현 방식은 지원하지 않습니다. 저는 위키링크 없이 자동 포맷을 하고, 0.5%의 독자가 설정을 변경하고, 나머지 독자들이 설정을 변경한다고 가정하는 것보다 어떻게든 사용자 날짜 선호도 또는 지역 선호도를 가져온다고 생각합니다. Ordinchaos 2009년 3월 30일 15:59 (UTC)답장[답장]
  35. 메타데이터에 주로 사용하기 위해 자동 연결 없이 자동 포맷을 지원합니다. 그러나 기본 형식이 마음에 들지 않더라도 페이지를 IP로 볼 수 있도록 날짜 기본 설정을 제거하는 것을 고려할 것입니다. Certes (talk) 2009년 3월 30일 16:02 (UTC)답장[답장]
  36. 자동 포맷을 지원하는 것은 일관성이 필요하기 때문입니다. 왜냐하면 혼합하면 혼동되기도 하고, 3/03/2009은 2009년 3월 3일을 의미하기도 하며, 가끔 혼동되기도 합니다. DeMoN2009 16:14, 2009년 3월 30일 (UTC)답장[답장]
  37. 지원 - 거의 모든 영어권 사용자들이 공통된 형식의 날짜를 인식한다는 것은 알고 있지만 날짜 형식은 편집자들에게 거의 발생하지 않는 문제이며, 한 기사에 다양한 형식을 포함하는 것은 허술해 보입니다. --Seezix1000 (토크) 2009년 3월 30일 (UTC) 16:26 (답변)
  38. 서포트. 이 기능을 링크에 오버로드하는 것보다 #format date 구현이 먼저였다면 문제가 되지도 않았을 것이라는 느낌을 지울 수 없습니다. 솔직히 이 여론조사를 보기 전까지는 #format date가 존재하는지 몰랐지만, 항상 이런 것이 최선의 방법이라고 생각했습니다. 저는 일반적으로 기사에 대한 다른 편집 과정에서 날짜를 삭제했습니다. 이제 대신 다시 포맷할 수 있습니다. 이게 진전입니다. Rklear (talk) 2009년 3월 30일 16:48 (UTC)답장[답장]
  39. 서포트. 독자들은 "2009년 2월 3일"과 "2009년 2월 3일"(그리고 저는 두 형식 중 어느 것도 강력하게 선호하지 않습니다)에 대해 잘 알고 있겠지만, 자동 포맷은 "DDMMM YYYY" 또는 "MMM DD YYYYY"로 포맷함으로써 "3/2/09"와 "2/3/09"의 혐오를 피할 수 있습니다. "DD/MM/YY" 또는 "MM/DD/YY"가 아니라 편집자가 템플릿을 사용하여 날짜를 지정하도록 권장합니다. 기사 전반에 걸쳐 일관성을 유지하는 것은 큰 이점이며, 독자들이 브라우저 또는 OS 로케일에 따라 날짜 형식을 볼 수 있는 옵션은 보너스입니다. 앞으로 자동 포맷은 몇 달, 몇 년을 위키백과에 사용할 수도 있어 아래 두 논의의 결과를 다루는 것은 비교적 사소한 일이 될 것입니다. 건배, 이 깃발은 한때 빨간색이었습니다propagandadeeds. 2009년 3월 30일 17:14 (UTC)응답하라.
  40. 서포트. 나는 위의 깃발의 요점에 동의합니다. 제가 매일 보고 알아볼 수 있는 방식으로 날짜를 보는 것이 훨씬 빠릅니다. Grk1011/Stephen (talk) 2009년 3월 30일 17:20 (UTC)답장[답장]
  41. 날짜를 클릭하고 그 때 다른 이벤트가 발생했는지 확인할 수 있다는 것이 매우 유용하고 흥미롭기 때문에 지원합니다. 네, 특정 날짜와 관련된 기사들이 많았는데(역사가 오래된 세계에서 일어나는 일), 그 주장은 무관하다고 생각합니다. 기사에 링크가 너무 많은 것에 대한 이 모든 걱정은 백과사전이 성장함에 따라 서로 링크된 기사가 점점 더 많아질 것이기 때문에 무의미한 걱정입니다. 500만 또는 1000만 건의 기사에 도달하면 기사에 넣을 수 있는 링크 수를 제한하여 주어진 기사에 "너무 많은 링크"를 갖지 않도록 할 것입니까? 그건 그냥 황당해요. 우리는 주요 주제에 대한 많은 기사가 수백, 수천, 그리고 아마도 수만 개의 링크를 가질 것이라는 것을 받아들여야 할 것입니다. 데이트의 경우, 그것들은 아마도 고급에 있을 것이지만, 온라인 백과사전이 성장하면 그렇게 됩니다. 그리고 누군가가 누군가가 제거한 링크를 다시 돌려놓아야 할 것이라는 주장은 터무니 없습니다. 동일한 봇을 다시 실행하고 역방향으로만 실행합니다. 그것들을 모두 제거하는 것보다 더 어렵지는 않을 것입니다. 저도 날짜 형식 부분이 큰 도움이 된다고 생각하고, 익명 사용자(그리고 변경하지 않은 사용자)의 기본값을 "1934년 6월 3일"과 같은 것으로 설정하는 것은 어렵지 않을 것입니다. *** 日本穣 17:37, 2009년 3월 30일 (UTC) 회신[답변]
    1. SILLYFolkBoy로 추가 코멘트를 하는 것은 위의 제 코멘트가 충분히 집중되어 있지 않다고 생각하는 것 같습니다. 날짜에 대한 일관된 형식을 만들려면 자동 형식을 지정하는 것이 매우 유용할 것이며, 기본 형식을 모든 사용자에게 유용한 형식으로 설정하는 것이 어렵지 않습니다(예: 위에서 설명한 예). 이를 구현하기 위한 가장 쉬운 방법은 이미 존재하는 대괄호를 사용한 연결 날짜라고 생각하기 때문에 "하지만 기사에 대한 너무 많은 들어오는 연결을 생성한다"는 주장의 불합리성에 대한 의견과 함께 유용성에 대한 의견을 포함했습니다. *** 日本穣 19:13, 2009년 3월 30일 (UTC) 회신[답변]
  42. 서포트. 일관된 날짜 형식을 제공하면 기사와 위키피디아 보기에 도움이 될 것입니다. IP 추적은 등록된 사용자가 아니더라도 북미 독자에게는 MDY를, 다른 사용자에게는 DMY를 제공하는 데도 사용될 수 있습니다. 또한 위키링크를 희석하고 일반적으로 거의 사용되지 않는 자동 포맷 방법으로 날짜 링크를 사용할 필요가 없습니다. 적어도 코드를 구현하여 개별 기사에 대한 합의에 따라 참조 스타일과 같이 자동 형식을 결정할 수 있는 옵션이 있습니다.2009년 3월 30일 (GMT) 18:07 †
  43. 지원 저는 주로 미국 기사를 읽고 편집하는 미국 사용자이지만 날짜 형식에 대한 미국 표준을 싫어하고 유럽 표준을 훨씬 선호합니다. 위키피디아는 모든 사람에게 원하는 대로 날짜를 포맷할 수 있는 옵션을 제공할 수 있어서 좋습니다. 누군가가 "불필요한" 연결에 대해 그의 보닛에 관심을 갖기 전까지는 시스템이 제대로 작동하고 있었다고 생각합니다. Ntsimp (talk) 2009년 3월 30일 18:27 (UTC)답장[답장]
  44. 사용자에게 선택권을 주는 지원. davidwr/(talk)/(기여)/(이메일) 2009년 3월 30일 18:31 (UTC)답장[답장]
  45. 지원은 옵션으로 사용할 가치가 있습니다. 저는 기능 기사에서 자동 서식을 제거하는 것은 논의되지 않았습니다. 그것은 단순히 이루어졌습니다. 그때는 상황이 나아지지 않았다는 이유로 반대의 목소리를 냈지만, 추진할 가치가 없다는 느낌을 받았습니다. 그 이후로, 그것은 _단일_사용자가 그것을 밀고 있습니다. 그렇기는 하지만, 특히 날짜 형식보다 훨씬 더 큰 문제인 시간대도 처리할 수 있다면 완전 자동 시스템이 훨씬 더 나을 것입니다. Mike Peel (talk) 2009년 3월 30일 (UTC) 18:54 답변[답변]
  46. 자동 포맷을 지원합니다. 저는 DMY가 더 좋아요, MDY는 별로 상관없지만 YMD 형식은 정말 싫어요. 제 눈에는 너무 못생기고 전문가답지 않게 보입니다. Mjroots (talk) 2009년 3월 30일 19:10 (UTC)답장[답장]
  47. 사용자별 지원:이 깃발은 한때 빨간색이었습니다.--사이버코브라 (talk) 2009년 3월 30일 (UTC)응답하라[응답하라]
  48. 서포트. 그냥 더 낫습니다. (우선순위 순으로) (i) 사용자 옵션 (ii) 기사 옵션 (iii) 사이트 전체 디폴트 등을 통해 이상적으로 선택 가능합니다. Mr Stephen (talk) 2009년 3월 30일 19:51 (UTC)응답하라[답변]
  49. 서포트. 자동 포맷은 좋다고 생각합니다만, 사용자가 원하는 날짜를 선택할 수 있는 소프트웨어에 문제가 있다면 개발자가 수정하여 투표를 중단할 수 있도록 해야 합니다. Kumioko (talk) 2009년 3월 30일 (UTC) 20:07 (답변)
  50. 지원 - 나중에 스타일을 통일하여 모든 날짜가 균일해지도록 하는 잠재적인 복잡성을 제거합니다. 사용자 선호도로 만들 수 있는데 왜 기사마다 다르게 나타나거나 한 가지 방법(절대 발생하지 않는 방법)에 대해 합의하려고 합니까? Jeremy McCracken (talk) (기여) 2009년 3월 30일 20:18 (UTC)답장[답장]
  51. 지원 - 날짜 표시 방법을 사용자가 선택하지 못하게 하는 이유는 무엇입니까? --Jackieboy87 (talk * contributes) 2009년 3월 30일 (UTC) 20:25 (답변)
  52. 지원합니다. 미디어위키는 추가 마크업 날짜를 자동으로 포맷하는 것이 더 좋을 것입니다. 예외를 제외하고는 위키가 없습니다. -- Jeandré, 2009-03-30t21:23z
  53. 자동화된 타임라인의 이점을 지원할 수 있습니다./이날 역사 페이지에서 큰 효과를 볼 수 있습니다. Brandon rush Woo pig suie! 2009년 3월 30일 21:26 (UTC)답장[답장]
  54. OCD일 수도 있지만 사용성의 필수 요소로 사용자 정의 가능성을 강조했습니다. 새로운 소프트웨어 업데이트는 훌륭한 중간 지점을 제공합니다.Sarregouset (talk) 2009년 3월 30일 (UTC) 21:27 답변[답변]
  55. 일은 아닌 것 같은데 지지해주세요. 큰 부담이 되지 않을 정도로 자동화가 가능해야 합니다. 반대 성명서의 핸드웨이브에도 불구하고 현재는 가능하지 않은 것으로 보이는 특정 날짜를 참조하는 모든 기사를 검색할 수 있는 범위를 제공합니다. 독자를 위한 일관성은 좋습니다. Gareth McCaughan (talk) 2009년 3월 30일 21:32 (UTC)응답하라[응답하라]
  56. 서포트. 위키백과는 독자들을 위해 작성되어야 하며, 로그인한 사용자들에게 날짜를 일관되게 표시해 주는 것은 로그인하지 않은 사용자에게 제공된 정보를 훼손하지 않으면서 사용자들의 경험을 향상시킵니다. -- Whpq (talk) 2009년 3월 30일 (UTC) 21:44 (답변)
  57. 서포트. 자동 연결 없이 자동 포맷을 하고 싶지만 어느 쪽이든 선택하겠습니다. Ross Patterson (talk) 2009년 3월 30일 22:08 (UTC)답장[답장]
  58. 서포트. 일관성과 독자 커스터마이징성은 여기서 중요한 요소입니다. 줄리안홀 (talk) 2009년 3월 30일 (UTC) 22:16 답변[답변]
  59. 서포트. 많은 i18n 토론에 직접 참여하는 웹 프로그래머로서, 사용자(편집자보다 독자)에게 표시된 데이터의 일관성을 제공하는 모든 방법이 도움이 됩니다. --MikeVitale 2009년 3월 30일 (UTC)응답하라[답변]
  60. 강력한 지지 새로운 파서 기능과 디폴트 가능성으로 반대의 주요 이유가 해결됩니다. 또한 Alexfusco5 23:59, 2009년 3월 30일 (UTC)응답하라 [답변] 가능한 가장 편리한 시청 경험보다 더 적은 것을 제공해야 할 이유는 없습니다.
  61. 서포트. 차라리 제가 가장 익숙한 날짜 형식을 선택하는 편이 낫겠습니다. --Le Petit Modifierur Rabiux (talk) 2009년 3월 31일 (UTC) 01:12 (답변)
  62. 편의성을 지원합니다. 또한 이전과 같은 스타일을 유지하고 있습니다.자동 포맷이 도움이 됩니다. Daniel Benfield (talk) 2009년 3월 31일 01:15 (UTC)답장[답장]
  63. 자동 포맷을 지원하고, 기사 모음이 날짜 포맷에서 일관성을 유지하는 것이 중요하며, 현재 방법은 기사 간의 어색한 불일치를 허용합니다. 또한 자동 포맷을 사용하면 사용자가 선호할 수 있기 때문에 Wiki는 더 보편적이고 기사 편집자의 문화에 덜 집중할 수 있습니다. Chuckiesdad/Talk/Contribs 2009년 3월 31일 01:56 (UTC)답장[답장]
  64. 강력한 지원 일관성 기사와 사용자의 선택권 내에서 강력한 지원이 많은 사람들에게 중요합니다. 당신에게 중요하지 않다면 왜 투표를 합니까? hulmem (talk) 2009년 3월 31일 03:13 (UTC)답장[답장]
  65. 또한 자동 연결 없이 자동 포맷을 지원합니다. shoy(응답) 2009년 3월 31일 03:33 (UTC)답장[답장]
  66. 신뢰할 수 있는 의미 데이터 검색을 위해 필요한 지원 Nicolas 1981 (talk) 2009년 3월 31일 06:10 (UTC)응답하라[답변]
  67. 지원: 시스템 구현을 위한 노력에 대한 두려움에도 불구하고, 저는 독자들을 돕기 위한 방법으로 자동 포맷 제안을 좋아합니다. 제가 아는 한, 인쇄된 백과사전은 날짜 형식 사이에서 뒤떨어지지 않는데, 왜 위키백과가 있어야 합니까? (여러 종류의 백과사전을 하나의 카테고리로 묶는 것에 대한 사과) 궁금한 점은 제 토크 페이지로 연락주시기 바랍니다. 이안 망카 2009년 3월 31일 (UTC) 06:13 답변[답변]
  68. 지원: 지역화 및 개인화가 미래입니다. 위키백과에 가입해야 합니다. -- D. Wo. 06:38, 2009년 3월 31일 (UTC)답장[답장]
  69. 지원 무엇보다 적합성과 통일성 주장에 근거한 지원 2009년 3월 31일 (UTC) 답변[답변wordsdeeds]
  70. 서포트. 대부분의 편집자가 해독하기 가장 쉬운 형식으로 날짜를 작성하는 것을 거부하기 때문에 자동 형식을 지정하는 것은 좋은 일입니다. 자동 포맷을 사용하면 모든 사람이 동시에 행복해질 수 있습니다. 정말, 누가 반대할 수 있습니까? 대부분의 "반대" 표들은 날짜 연계에 반대하는 것으로 보이는데, 이는 정말로 불안한 일이지만, 이 여론조사가 묻는 것도 아닙니다.Henning Makholm (talk) 2009년 3월 31일 11:00 (UTC)응답하라[응답하라]
  71. iridesent 13:03, 2009년 3월 31일 (UTC)답장[답장]
  72. 서포트. 자동 포맷은 외관상 중립적인 반면, 날짜 스타일을 선호하는 사용자에게 적합합니다.Gramem Legget (talk) 2009년 3월 31일 15:39 (UTC)응답하라[답변]
  73. supoet Bubba73 (talk), 15:52, 2009년 3월 31일 (UTC)답장[답장]
  74. 지원: 로그인한 사용자가 원하는 날짜를 선택할 수 있도록 투명하고 효과적으로 작업하는 데 사용됩니다. --Old Moonraker (토크) 2009년 3월 31일 (UTC) 16:18 (답변)
  75. 지원 저는 날짜 연결/메타데이터가 가장 흥미로운 측면이라고 생각합니다. 획일적인 날짜 형식을 얻는 것은 좋은 보너스가 될 것이며 불교도를 지원합시다! Luddite 프로파간다와 같이 읽기를 반대하는 주장은 당연히 템플릿이 가능한 한 사용자 친화적이어야 합니다. 20090331에 대해 ISO에 반대하는 주장이 무엇이 그렇게 어려운지 잘 모르겠습니다. >아니, 진짜. 우노미 (talk) 2009년 3월 31일 16:31 (UTC)답장[답장]
  76. 서포트. 특정 기사에 사용할 형식에 대한 논쟁을 피합니다. 블루웨이브 (토크) 2009년 3월 31일 16:54 (UTC)응답하라[응답하라]
  77. 서포트. 날짜는 데이터, 정보 및 지식을 기록하고 보관하는 데 필수적인 요소입니다. 형식은 시간 및 날짜 스탬프의 중요한 측면입니다. 형식은 커뮤니티 전체에서 일관되어야 합니다. 결국, 우리는 공동체가 아닌가요? 불행하게도, 반대하는 많은 주장들은 설득력이 없습니다; 이것들은 아나키스트 선전 대 건설적인 논평 또는 논의 중인 주제에 대한 의견에 더 가깝습니다. 만약 우리가 공동체로서 데이트 기록에 대한 기본적인 기대를 할 수 없다면, 왜 우리는 다른 모든 규칙과 지침을 가지고 있을까요? 환자안전구루 (talk) 2009년 3월 31일 17:31 (UTC)응답하라[답변]
  78. 서포트. 1-2-2009/2-1-2009와 같이 애매모호한 것을 피하기 위해서는 우리가 이 일관성을 갖는 것이 필수적입니다. 표준화가 부족하면 기사가 신뢰성이 떨어지는 것처럼 보일 뿐입니다. 위키봇의 힘을 생각할 때, 모든 것을 자동으로 포맷하는 것은 지나치게 어려운 일이 되어서는 안 됩니다. --아날로그 키드 (토크) 2009년 3월 31일 (UTC) 17:54 (답변)
  79. 서포트. 이것이 그것을 하는 방법입니다, 왜냐하면 그것은 매우 효과적이기 때문입니다. Showtime 2009 (talk) 2009년 3월 31일 18:09 (UTC)응답하라[답변]
  80. 서포트. 템플릿이나 파서 기능을 사용하여 페이지를 재구성하는 것이 고통스러울 수 있다는 것을 이해하지만, 그것이 사용자 선택을 제한하는 이유는 아니라고 생각합니다. 어쨌든 봇은 이것을 하기 위해 작성될 수 없습니까(또는 AWB에 작성될 수도 있습니다)? 그리고 10-20자를 추가로 입력하는 것이 정말 그렇게 큰 문제입니까? Daniel J Simanek (talk) 2009년 3월 31일 18:40 (UTC)답장[답장]
  81. 서포트. 날짜 자동 형식을 허용하는 것은 사람의 재치를 넘어서서는 안 됩니다. 또한 날짜 연결에 반대하는 근거가 있는 반대는 무시해야 합니다. 제안을 이해하지 못한다는 것을 분명히 보여준 사람들의 표를 세어 보면 안 됩니다. 해결해야 할 문제가 없다는 주장은 비순차적인 것이기도 합니다. 개인적으로 다른 날짜 형식을 바꾸는 데 불편함이 없다면 다른 사람의 선택을 차단할 이유가 되지 않습니다. 당신이 정말로 추가 키 입력으로 할 수 없다고 생각한다면, 그것이 당신에게 더 많은 일을 야기한다는 것을 근거로 한 이의 제기는 아마도 유효할 것입니다. 저는 개인적으로 {{#formatdate 2009년 3월 31일}}와 같이 다른 사람들이 제안한 것처럼 {{d 2009-03-31}}와 같은 것이 효과가 있을 수 있습니다. --SallyScot (talk) 2009년 3월 31일 (UTC)응답하라[답변]
  82. 서포트. 날짜를 기준으로 4개의 괄호([ ]])의 가격과 숙련된 PHP 개발자의 프로그래밍 시간이 10시간을 넘지 않는 경우(코드를 이미 한 번 작성했기 때문에 알고 있습니다), 프로젝트 전반에 걸쳐 일관된 날짜 형식, 사이트 전체의 기본값을 무시하는 기사별 기본값 기능, 날짜 범위 지원, 그리고 등록된 사용자가 서로 독립적으로 선호도를 연결하는 날짜 형식과 날짜를 지정할 수 있는 기능을 제공합니다. 이렇게 하면 날짜 형식이나 날짜 연결에 대해 다시 논의할 필요가 완전히 없어지고 거의 모든 사람이 원하는 것을 가질 수 있습니다. --UC_Bill (talk) 2009년 3월 31일 (UTC)20:34 (답변)
  83. 든든한 지원군. 날짜 형식 지정은 위키피디아 독자들에게 개인 독자들이 가장 유용하다고 생각하는 방식으로 제공되는 기사 내용을 보여주는 보다 일반적인 목표를 향한 명백한 첫 단계라고 보아야 합니다. 우리는 지금 날짜 형식만큼 작은 것을 위해 이것을 해야 합니다. 우리는 영어 철자 변형과 같은 큰 것을 위해 이것을 할 수 있습니다. 우리는 언젠가 그것보다 훨씬 더 많은 것을 할 수 있기를 희망해야 합니다. (sds - talk) 2009년 3월 31일 20:36 (UTC)응답하라.
  84. 지원 표준은 훌륭한 것입니다 - 문제는 선택할 수 있는 것이 너무 많다는 것입니다 - 이제 해당 문제의 한 가지 사례에 대한 해결책이 생겼습니다 - 날짜 자동 형성;) ClemMcGann (대화) 2009년 3월 31일 (UTC) 21:44 (답변)
  85. 지원 한 형식으로 기사를 편집하는 경우 다른 형식의 네시 (토크) 2009년 3월 31일 21:55 (UTC)응답하라[답변]
  86. 지지해주세요. 하지만 우리가 결정하는 것은 무엇이든 지지하고, 그렇게 내버려 두자. 이것은 기념비적으로 지루한 주제입니다. 우리 모두 다시 글을 쓰고 연구해야 합니다. ----Charles Gillingham (토크) 2009년 3월 31일 (UTC) 22:51.회답[회답]
  87. 지원 사용자가 원하는 대로 날짜를 볼 수 있도록 하여 위키백과의 사용자 친화성을 높입니다. 저는 또한 반대표들 중 많은 사람들이 링크와 "푸른 바다"에 대해 불평하고 있는데, 이것은 제안된 해결책과 무관하므로 할인되어야 합니다. - Arwel Parry (talk) 2009년 3월 31일 (UTC) 22:57 (답변)
  88. 지원 사용자(즉, 독자) 환경설정은 편집 결정보다 우선해야 합니다. 날짜 형식(및 연결)은 MOSNUM의 소규모 그룹이 지정하는 것보다 기본 설정에서 지정했으면 합니다. --Sapphic (talk) 00:02, 2009년 4월 1일 (UTC)답변[답변]
  89. 지원 노브레인러. (독자에게) 오드볼과 같은 속도 돌기 형식의 기사 스캔을 방해하지 마십시오. --Kbh3talkrd 2009년 4월 1일 (UTC)응답하라[답변]
  90. 지원, 생각 끝에 스스로를 놀라게 합니다. 처음에는 "KISS"와 "해결해야 할 문제가 없다"는 주장이 설득력이 있고 기존 애플리케이션(해당 연도 또는 해당 날짜에 대한 페이지에 자동 링크하여 등록된 사용자가 날짜 표시 형식을 선택할 수 있도록 허용)이 불확실한 장점이 있기 때문에 기존 마크업의 삭제에만 신경이 쓰였습니다. 그러나 이 메타데이터가 미래에 사용될 수도 있다는 생각은 다음과 같습니다.
    • 파싱 알고리즘을 사용한 검색(즉, 데이터 자체를 패턴 매칭하여 데이터를 인식하려는 검색)과 메타데이터를 사용한 검색은 성능과 품질 모두에서 차이가 있습니다. 인간 편집자가 날짜로 표시한 것은 날짜가 무엇일지에 대한 자신의 추측보다 기계적으로 더 많은 정보를 제공합니다. 이렇게 플래그가 지정된 텍스트가 날짜로 사람이 읽을 수 있는 것 이상으로 표준 규칙을 따르지 않더라도 이는 사실입니다. <tag> 1845년 10월 18일 </tag> 뿐만 아니라 <tag> 1945년 10월 18일 </tag> 그리고 그 해 10월 <tag>까지 허용된다면, 태그의 존재는 제시된 데이터를 손상시키지 않으며, 사용자에게 유용한 데이터를 제공할 수 있는 미래의 응용 프로그램의 개발을 허용합니다. 예를 들어, 문서 컨텍스트에서 마지막 예를 해결할 수 있는 파서를 첫 번째 두 개와 동시에 날짜로 지정하여 유용한 검색 기능이 될 수 있으며 날짜 태그를 지정해야만 작동을 지원할 수 있는 파서를 고려해 보십시오. 또는 저자가 사건의 순서를 연관시키기 위해 초기의 지역 달력을 사용하는 것이 유용하다고 생각하는 역사적인 기사를 상상해 보세요. 각 날짜에 태그가 지정되면 응용프로그램은 각 날짜를 다른 관련 달력으로 자동 팝업 변환할 수 있습니다.
    • 대부분의 현재 사용자들이 차이를 보지 못한다는 주장은 기존의 애플리케이션과 관련이 있을 뿐, 아무도 유용하다고 생각하지 않는 것 같습니다. 향후 애플리케이션이 이 메타데이터를 유용한 용도로 활용할 수 있다면, 이러한 애플리케이션은 선택적으로 사용자 단위로 구성되는 것이 아니라 표준 인터페이스의 일부가 될 수 있습니다.
    • 위에서 설명한 날짜 태그는 대부분 사용자 중립적인 상태에서 잠재적으로 기계적으로 유용할 수 있지만, 훨씬 더 기계적으로 유용한 것은 태그에 날짜를 표준 형식으로 지정하는 필드를 추가하는 것이며, 동봉된 텍스트는 작성된 대로 계속 표시됩니다. 이를 통해 주요 콘텐츠(예: 견적)에 영향을 주지 않고 봇 태그를 지정할 수 있으며, 선택적인 자동 포맷터의 기존 프로포머가 이를 계속 사용할 수 있습니다.
    • 기사에 모든 또는 실제로 날짜가 태그될 필요는 없으며, 편집자가 태그된 날짜를 원하는 "킬러 앱"이 나타나지 않는 한 대부분의 기사에는 봇 태그에 의해 삽입되지 않은 날짜가 없을 수 있습니다. 이러한 앱의 등장으로 소급 날짜 태그가 급증할 가능성이 있습니다.
    • 물론 태그에 날짜가 중복되는 것은 두 날짜가 다를 수 있다는 위험을 수반하지만, 저는 위키피디아 편집자들에게 전혀 새로운 것이 아니라는 생각이 듭니다. 백과사전의 거의 모든 사실은 한 곳 이상에서 찾아볼 수 있고, 많은 경우 수백 개의 다른 기사에서 찾아볼 수 있습니다. 불일치 가능성을 피하는 것은 현실적이지도 않고 필요한 목적도 아닙니다.
    • 날짜 태그의 가치를 확신하지 못하는 편집자들이 날짜 태그를 단순히 생략할 수 있기 때문에 페이지를 만드는 데 필요한 추가 작업은 문제가 되지 않습니다. 그들의 형식 선택이 너무 모호하지 않다면("Michaelmas 다음 세 번째 달, 긴 겨울"), 후속 편집자와 봇이 원하는 경우 추가하는 것이 너무 어렵지는 않습니다.
    Nyelvmark (talk) 2009년 4월 1일 01:30 (UTC)답장[답장]
  91. 지원 - 저는 호주에서 왔고 DMY 형식으로 날짜를 보는 것을 선호합니다. 각 사용자의 선호에 따라 모든 날짜를 자동으로 포맷하는 방법이 있다면 좋은 생각이라고 생각합니다. Wcp07 (talk) 2009년 4월 1일 05:23 (UTC)답장[답장]
  92. 지원 이것은 위키백과 내에서 여러 사용자들에게 이미 ArbCom으로 연결된 실제 문제입니다. 저는 날짜가 일관된 방식으로 나타나도록 규칙을 만드는 것이, 때로는 A 형식을, 때로는 B 형식을 허용하는 것보다 훨씬 쉽다고 생각합니다. 왜냐하면 항상 회색 영역이 존재하기 때문입니다. 우리 모두가 사용할 표준 형식에 동의한다면 구체적인 지침은 문제를 줄일 것입니다. 저는 특별한 방법으로 선호하는 것이 없습니다. 즉, 개인 설정에서 자료 표시를 결정할 수 있도록 하는 것이 다음으로 가장 좋은 단계입니다. 제가 답변을 드리는 가장 큰 이유는 문제가 반대로 제기되었기 때문입니다. 또한 반대 알림의 각 의견을 처리하는 데 몇 초가 소요됩니다.
    "해결할 문제는 없습니다." ArbCom의 현재 사례는 그렇지 않다고 말합니다.
    "날이나 달이 먼저 오든 (1월 3일, 1월 3일)이 먼저 오든 모든 영어 사용자들은 두 가지를 모두 인식합니다. 미군은 많은 캐나다인들과 마찬가지로 DMY를 사용합니다. 반면 신문을 포함한 북미 이외의 많은 출판물들은 MDY를 사용합니다." 다른 형식이 있다는 것을 인식하는 것은 특별한 것이 아닙니다. 문제는 각각 서로 다른 기준을 사용한다는 것입니다. 위키피디아는 이러한 모든 국가적 선호의 집합체입니다.
    "이러한 혼재된 환경을 고려할 때, 독자들은 기사에서 어떤 형식이 사용되는지 신경 쓰기는커녕 주목조차 하지 않을 것입니다. 당사의 최고 전문성 기준을 대표하는 특집 기사는 지난 9월 자동 포맷을 포기하고 현재는 단순한 고정 텍스트 날짜만 사용하고 있습니다. 특집 기사 후보에서 거의 언급되지 않았습니다." 어떤 형식을 사용하는지에 대한 관심은 거의 없지만, 위키백과의 목표인 양질의 백과사전은 일관된 날짜를 사용합니다. 독자들은 "2008년 12월 21일부터 2009년 1월 3일까지 로스앤젤레스 주변의 공기가 스모그 상태였다"는 이런 종류의 문제에 주목해야 합니다. 그래서 사람들은 그러한 불일치에 주목합니다. 특집 기사의 기준은 이러한 문제에 대해 WP:MoS를 기반으로 하기 때문에 어쨌든 그러한 논의를 하기에 적합한 장소는 아닙니다. 12개 이상의 FA에 기여한 사람으로서, 저는 기사에 걸쳐 수백 개의 날짜를 포맷하는 것(주로 참고문헌에서 발생)은 왕실의 고통이라고 확신할 수 있습니다!!! "간단한" 작업은 아니지만, FA에게는 날짜 일관성이 요구됩니다. 이렇게 하면 프로세스가 크게 간소화됩니다.
    "더 넓게 보면, 한 사용자가 7,000개 이상의 기사에서 연결 해제 및 수정 날짜를 가지고 있지만 소수의 반대 의견만 접수했습니다." 또 다른 사람은 그보다 훨씬 더 많은 기사를 위해 그렇게 했고 이제 그의 행동은 그를 ArbCom에 배치했습니다.
    "두 부류의 사용자가 있어서는 안 된다는 기본 원칙. 일부 등록된 편집자들은 다른 사람들과 다른 날짜 형식을 볼 수 있기 때문입니다(위키백과 참조:DONOTLINKDATES), 날짜 형식이 일관성 없이 엉망이 될 수밖에 없습니다." 모든 논쟁은 적반하장입니다. 이미 등록된 사용자와 익명(즉, 이미지 업로드, 페이지 이동, 반보호 페이지 등) 간에 상당한 차이가 있습니다. 하나 더 추가하는 것은 큰 문제가 아닙니다. 기본 날짜 형식을 선택하는 한 등록되지 않은 사용자와의 불일치가 없어야 합니다.
    "복잡하고 힘들죠. 수천만 개의 날짜를 {{#format date 2009년 3월 11일}}와 같은 마커로 태그를 지정하고(dmy/md를 추가해도 키 입력 횟수가 두 배로 늘어남), 기본 날짜 형식을 설정하기 위해 거의 300만 개의 기사를 특별히 태그하는 것은 특정 형식으로 날짜를 보는 데 드는 매우 작은 이점을 지불하는 엄청난 비용이 될 것입니다. 그리고 새로운 편집자와 일상적인 편집자의 문제를 복잡하게 만들 것입니다. MOSNUM에는 마크업이 필요 없는 날짜 형식에 대한 단순하고 잘 받아들여지는 규칙이 이미 있습니다. Wiki Media의 최고 기술 책임자인 Brion Vibber는 "모든 날짜 자동 형식을 삭제하는 것이 제 개인적인 권장 사항입니다."라고 말했습니다. 이것은 너무 복잡하지 않으며 봇은 큰 문제 없이 구현할 수 있으며 더 이상의 문제를 방지할 수 있습니다. 최고 기술 책임자인 Brion Vibber의 의견은 그 자신의 의견이며, 이것은 쓰기 일관성 문제보다 기술적인 문제가 덜합니다. 모든 글쓰기 가이드에는 표준이 있고 모든 주요 백과사전은 정해진 날짜를 사용합니다. 왜 우리는 달라져야 합니까?
    "메타데이터 오류..."모든 것이 표준이었던 텍스트의 연결 능력에 관심이 있는 것 같습니다. 이것은 여기에 해당되지 않으며 완전히 주제에서 벗어났습니다.
    "원래 자동 포맷이 실패한 것은 커뮤니티에서 합의된 사양(명확한 목표) 없이 행동하는 프로그래머들이 설계를 임시로 부과한 것이 원인이었습니다. 제안된 소위 수정 사항은 범위와 기능이 제한적이며 커뮤니티에서 동의하지 않았습니다. 우리는 향후 몇 년 동안 솔루션을 한 단계 한 단계씩 고정하는 위험을 감수해서는 안 되며, 일반 편집기와 훨씬 더 멀리 떨어져 있는 점점 더 복잡한 구문을 요구합니다. 이러한 문제 중에는 깨지지 않는 공간, AD/BC, 삭감된 날짜, ISO 및 그레고리안/줄리안 날짜가 포함됩니다. 날짜 범위(원 시스템이 포함하고 있는 엉성함과 강제적인 반복을 피하는)는 상당한 도전이 될 것입니다." 오케이...그래서 어쩌라고 이미 이러한 문제가 있지만 날짜를 표준화함으로써 위키백과 전체의 대량 변경을 수백만 개의 변경 대신 단일 템플릿으로 한 번의 변경으로 구현할 수 있습니다.
    BQZip01 — 05:39, 2009년 4월 1일 (UTC)답장[답장]
  93. 지원 - 평가절하되기 전에 날짜를 개인 취향에 맞게 설정할 수 있는 기능이 마음에 들었고, 제가 작성한 모든 내용을 그렇게 설정했습니다. 게다가, 물론, 기사 자체를 변경할 수 없다면 변경할 수 있는 선호 옵션을 갖는 것이 무슨 의미가 있나요? Colds7ream (talk) 2009년 4월 1일 07:25 (UTC)답장[답장]
  94. 지원 - 이것은 쉬운 방법입니다. 물론 독자들은 일반적으로 자신이 좋아하는 형식으로 날짜를 봐야 합니다. --guyzero talk 2009년 4월 1일 (UTC)답장
  95. 01-02-03 또는 04-05-2006 또는 2009-08-07 의 진정한 의미를 해독하려는 시도를 능가합니다. -- Twas Now (talkcontributes • e-mail ) 2009년 4월 1일 (UTC)응답하라[답변]
  96. 지원 저는 특히 어떤 사람들은 이런 종류의 사용 편의성이 필요하기 때문에 정말 좋은 생각이라고 생각합니다. XxReikoxX - The Visual Asia Geek (talk) 2009년 4월 1일 (UTC) 09:38 답변[답변]
  97. 지원 – 이것은 정말로 두 가지 다른 것에 관한 것입니다: 날짜로 어떤 것을 식별하기 위한 일종의 마크업이 있어야 하고, 마크업을 사용하여 포맷에서 개인적인 선호를 허용해야 합니다. 일반적인 원칙에서 마크업은 일반적으로 좋은 아이디어입니다. 지금 당장은 마크업의 좋은 용도를 생각할 수 없습니다. 저는 날짜 형식에 대한 개인적 선호도를 지정하는 기능을 즐기고 있으며, 미래에 훨씬 더 많은 것(메트릭 대 비메트릭 단위, "컬러" 대 "컬러" 등)에 대한 개인적 선호도를 지정하는 기능을 원합니다. 이러한 것들은 마크업 없이는 불가능합니다. 로그인한 사용자가 즐기는 기능에서 익명 사용자를 배제해서는 안 된다는 반대 의견에 동의하며, 원칙적으로 익명 사용자가 쿠키에 기본 설정을 저장할 수 있도록 소프트웨어를 수정하는 것이 가능하다고 반박합니다. {{#format date 2009년 3월 11일}}가 복잡하고 힘들 것이라는 반론에는 동의하지만, 실제 마크업 구문이 아직 결정되지 않았다고 반박하며, 그렇게 복잡하고 힘들지 않기를 바랍니다. 반대 성명서의 "메타데이터 오류"에 따른 반대 의견에 동의하지 않습니다. 검색 도구가 재포맷 후보인 날짜와 그렇지 않은 날짜를 구분하는 것은 거의 불가능합니다(예를 들어 인용문의 날짜는 재포맷해서는 안 됩니다). 반대 성명서의 "개발 위험"에 따른 우려 사항에 동의하며 구문 세부 사항이 해결될 때 그러한 우려 사항이 고려되기를 바랍니다. 오버링크에 대해 불평하는 사람들은 요점을 놓치고 있습니다. 포맷과 링크는 마크업이 필요하지만 독립적인 개념입니다. —Alan Barrett (talk) 15:44, 2009년 4월 1일 (UTC)응답하라[답변]
  98. 정말 잘 요약한 앨런 배럿이 지지합니다.나이트스톨 16:26, 2009년 4월 1일 (UTC)답장[답장]
  99. 지원 자동 포맷을 허용함으로써 특정 날짜가 날짜라는 사실을 명시적으로 표시합니다. 그 양식의 의미론적 마크업은 (이유 내에서) 어떻게 사용되든 상관없이 제 지지를 받습니다. {{#formatdate}} 구문이 장황하다는 다른 의견에 동의합니다. 아마도 더 나은 것을 찾을 수 있을 것입니다. 하지만 그건 부수적인 것입니다. 구문 간 변환을 위해 봇을 작성하는 것은 쉽고 구문을 제거하기 위해 봇을 작성하는 것도 쉽습니다. (마크업을 추가하기 위해 봇을 작성하는 것은 반드시 오류가 발생하기 쉽기 때문에 사람들을 짜증나게 할 수 있지만 그렇게 할 필요가 없기를 바랍니다. Lightbot의 과거 편집을 검토하고 모든 날짜 마크업 제거 편집을 되돌린 봇이 도움이 될 수 있습니다.) 이것으로 얻는 것은 무엇입니까? 로그인한 사용자가 잘 숨겨둔 설정을 만지작거리게 하고 '4월 1일'과 '4월 1일' 사이를 전환하는 현재의 의미에서 자동 포맷은 빙산의 일각에 불과합니다. 아마도 미래에는 RDF/A를 사용하여 브라우저에 날짜임을 알려줄 수 있으며 미래의 브라우저는 자동 포맷을 지원할 수 있습니다. (사실, 저는 그들이 그렇게 하지 않는다면 놀랄 것입니다.) 이를 통해 소프트웨어(예: 웹크롤러)는 Google 지도가 지리적 좌표를 사용하는 것과 거의 동일한 방식으로 기사에서 날짜를 추출할 수 있습니다. 5년 안에 누가 무엇이 가능한지, 그리고 사람들이 위키피디아가 무엇을 할 수 있기를 원하는지 알 수 있을 것입니다. 하지만 저는 가능한 한 많은 의미론적 마크업(날짜를 날짜로, 이름을 이름으로 표시하는 등)을 유지하는 것이 이를 달성하는 데 도움이 될 수밖에 없다고 확신합니다. 정보를 잃는 것은 거의 항상 역행하는 단계입니다. 따라서 오늘날 미디어위키 소프트웨어로 자동 포맷을 사용하지 않기로 결정하더라도 일종의 날짜 마크업을 해봅시다.ras52 (talk) 2009년 4월 1일 17:23 (UTC)답장[답장]
  100. 지원하지만 자동 포맷 자체가 가장 해결해야 할 문제라고 생각하기 때문이 아니라 적절한 메타데이터와 마이크로포맷에 날짜를 캡처해야 한다고 생각하기 때문입니다. 관련이 없는 한 날짜 연결은 피해야 하지만, 날짜 표시를 위해 일반 산문 텍스트가 남아 있을 정도로 링크가 제거되면 너무 많은 가치 있는 정보가 손실됩니다.Andrwsc (talk·기여) 2009년 4월 1일 (UTC) 18:31 답변[답변]
  101. 지원, 구현을 제대로 하는 것이 중요하지만 메타 데이터가 더 많고 맞춤형 콘텐츠를 포맷하는 것에 대한 단점은 거의 없습니다. 반대 의견은 1개의 KISS 주장과 2개의 시간 낭비 주장으로 향하는 것 같습니다. 첫 번째는 두 번째를 더 이상 일반화하지 않고 일반화하는 것이고, 두 번째는 특히 애당초 링크 해제로 인해 생성된 엄청난 편집 수를 고려할 때 잘못된 것으로 보입니다. 3 캐주얼 사용자에게 미치는 영향은 0이고, 파워 사용자에게 미치는 영향은 설정을 무시하는 선택을 하는 경우에만 관련이 있습니다. 유일한 단점은 시간을 "낭비"하기로 선택한 사용자와 이미 시간을 "wasted"하여 프로그래밍하는 개발자들입니다(제안서에 따르면 기능이 이미 존재합니다). 4 나머지 불만 사항은 (다른 사람들이 명확하게 말하는 자동 형성 = 자동 연결은 제안이 아니라는 것) 또는 5명 모두가 "이를 극복해야 한다" 또는 좋은 교육 경험이라는 오해에 근거한 것으로 보입니다. 이 마지막 주장은 거의 언급할 가치가 없습니다. 사용자는 (대부분의 다른 영역에서 그러하듯이) 성인으로 취급되어야 하며, 선택할 경우 최신 형식으로 교육할 수 있습니다. 온정주의적 편집자는 그들을 위해 그러한 선택을 할 필요가 없습니다. Shadowjams (talk) 2009년 4월 1일 19:47 (UTC)응답하라[응답하라]
  102. 서포트. 저는 특정 방식으로 날짜를 보는 것을 선호합니다. 파워 23:41, 2009년 4월 1일 (UTC)답장[답장]
  103. 서포트. 독자를 위한 혜택이며 유지 관리는 대부분 봇이 할 수 있습니다. 초낙(talk) 2009년 4월 2일 (UTC) 00:23 답변[답변]
  104. 서포트. 저는 통일된 날짜 형식을 선호하며 메타 데이터도 유용할 수 있습니다. Mark Hurd (talk) 2009년 4월 2일 (UTC) 02:37 답변[답변]
  105. 지원자 여러분, 저는 날짜가 MDY인지 DMY인지 걱정하지 않고 기사를 편집하고 읽을 수 있는 것이 더 쉽다고 생각합니다. 제 생각에는 선택할 수 있는 옵션이 있는 것이 좋은 생각이며, 선택할 수 있는 옵션이 있다고 하더라도 반드시 올바르게 포맷되어야 하는 것은 아닙니다. 위키피디아는 사용자 편집에 관한 것입니다. 따라서 사용자가 잘못된 형식의 날짜를 발견하면 변경할 수 있고, 사용자가 굳이 변경할 필요가 없다고 생각한다면 모두가 이깁니다. -- GoldMan60 ¤ Talk 04:39, 2009년 4월 2일 (UTC)응답하라[답변]
  106. 지원 6년 전에 참여한 편집 전쟁에 대한 훌륭한 솔루션이었고, 일부 사람들이 날짜에 대한 POV를 부과하는 것을 어렵게 만드는 것은 가치가 있습니다. 생태학(talk) 2009년 4월 2일 (UTC) 08:25 답변[답변]
  107. 지원 개인 설정에 의한 자동 포맷 허용은 링크 연결 해제 편집 전쟁 전체를 중지시키고 다른 사용자에게 강요하지 않고 사용자 자신의 설정을 허용합니다. 많은 문제를 한 번에 해결합니다. 개발자들이 단순히 날짜에 대한 자동 형식을 만든다면, 우리는 처음부터 이 토론을 하지 않을 것입니다. 날짜 형식의 제한된 양은 개발자들이 노력했다면 추가 포맷 없이도 가능하다는 것을 의미합니다. - Mgm 09:52, 2009년 4월 2일 (UTC)답장
  108. 지원 위키백과가 백과사전이기 때문에 일관성은 필수적입니다. 사용자가 날짜를 입력하는 방식에 대해 특별히 주의를 기울여야 하는 것에 대해 정말로 반대한다면, 저는 봇이 작업을 수행하고 사용자를 지원할 수 있다고 확신합니다. -m-i-k-e-y-talk 2009년 4월 2일 (UTC)10:53 답변[답변]
  109. 미등록 사용자의 불일치 문제로 "약함" 지원이 약합니다. Ed Fitzgerald 2009년 4월 2일 (UTC) 13:08 답변[답변]
  110. 지원, Jeff에 따라(날짜가 일치하지 않고, 편집상의 경고가 적음) --Esprit15d • talk기여 13:29, 2009년 4월 2일 (UTC)응답하라[답변]
  111. 지원님, 내용에 집중해 보겠습니다. 포맷은 시스템에 맡깁니다. --NullSpace (talk) 2009년 4월 2일 (UTC)응답하라[답변]
  112. 강력한 지원 개인적으로, 저는 날짜 형식을 갖추는 것이 약간의 추가 노력의 가치가 있다고 생각합니다. 하지만, 그 노력을 하고 싶지 않은 사람들은 단순히 다른 사람에게 맡길 수 있습니다. 무식한 사람이어야 합니다. 포맷을 원하는 사람들은 그것을 가질 수 있도록; 그것을 무시하지 않는 사람들은 그것을 무시하지 않도록 하세요. --ThaddeusB (talk) 2009년 4월 2일 (UTC) 16:23 (답변)
  113. 지지는 주로 무의미하고 성가신 편집 전쟁을 줄일 것이기 때문입니다. Davidelit (talk) 2009년 4월 2일 17:13 (UTC)답장[답장]
  114. 강력한 지원 사람들은 왜 기술을 두려워할까요? 마음에 들지 않으면 기본 설정에서 끄되 옵션을 제거하지 마십시오. 이것은 등록의 장점 중 하나였고, 저에게 원래 그렇게 하도록 격려해 준 것입니다.--Patrick «» 2009년 4월 2일 (UTC)답장
  115. 메타데이터 인수 때문에 지원됩니다. 날짜를 표시하지 않으면 정보가 손실됩니다. regexp 검색 등을 통해 정보를 복구하는 것은 종종 가능할 수 있지만, 왜 우리 자신에게 번거로움을 주는 것일까요? --Northernhenge (talk) 2009년 4월 2일 (UTC) 17:48 (답변)
  116. 두 번째로 작은 자릿수가 필요한 WYSIWYG 주제에 관한 한 Wikimedia를 리더의 측면에 유지하기 위한 가장 간단한 방법이라는 단순한 이유로 날짜 자동 포맷을 강력히 지지합니다. 날짜 형식의 자릿수를 단순한 7자리 코드로 줄이는 형식은 4자리 연도를 사용하고, 그 다음에 3자리 데이를 사용하는 형식이지만 대괄호 내에서는 내부 대시가 없습니다. 이 방법은 서버가 코드를 해석하고 판독기에 의해 지시된 형식을 생성하는 것에 의존합니다. 이 방법을 사용하려면 윤년에 366일이 있다는 점을 기억하고 문제의 날짜 수를 계산해야 합니다. 이 방법이 일부 사람들에게는 어려울 수 있다는 점을 감안할 때, 저는 4자리 연도, 2자리 월 및 2자리 데이와 2개의 내부 대시를 사용하여 총 자릿수를 10자리 + 괄호로 늘리는 현재 방법으로 돌아갑니다. 모든 관점에서 가장 합리적인 타협안입니다. 메타데이터 문제도 맞습니다. Unregistered Users 문제의 경우, 간단한 해결책은 입력 내용을 편집하여 데이터 형식을 수정하는 것입니다.-SSG Cornelius Seon (은퇴) (talk) 2009년 4월 2일 (UTC) 17:53 답변[답변]
  117. 서포트. 날짜는 텍스트가 아닙니다. 휴리스틱(혹은 인간)들에게 "의미 없는" 날짜를 알아내는 것은 나쁜 일입니다. --Alvestrand (talk) 2009년 4월 2일 (UTC) 18:42 (답변)
  118. 지원, 다양한 날짜 형식을 더 포괄적으로 사용하도록 노력해야 한다고 생각합니다. 또한 연결된 날짜 또는 연결되지 않은 날짜를 쉽게 전환할 수 있습니다. AutoWiki Browser/bots를 사용하면 많은 부분을 변경할 수 있습니다. -Zeus-u c 19:43, 2009년 4월 2일 (UTC)답장[답장]
  119. 서포트. 다른 사람들이 쉽게 읽을 수 있는 형식을 얻는 것을 막을 이유가 없다고 봅니다. 어떤 형식을 받든 상관없는 저와 같은 사람들에게 불편함을 주지 않기 때문입니다. 기사 작성자는 몇 개의 키 입력을 더 입력해야 하지만 표준 형식을 입력하고 있으므로 기사 주제에 적합한 형식을 선택하는 것에 대해 생각할 필요가 없습니다. 부수적인 문제로, 자동 서식은 숫자 날짜가 혼동되는 현상(3/2/09 vs 2/3/09 등)을 방지하는 데 유용한 사회적 도구가 될 것이라고 생각합니다. Esobocinski (talk) 2009년 4월 2일 20:05 (UTC)답장[답장]
  120. 서포트. 이것은 (대부분 사용되는) 북미 데이트 스타일에 익숙하지 않은 사용자에게 유용한 기능이라고 생각합니다. 자동 포맷을 허용하는 것은 모든 사람들에게 편리한 해결책이 될 것입니다(상관없는 사람들은 다른 기사에 적힌 대로 '정상' 날짜를 표시할 수 있는 반면, 상관있는 사람들은 각자의 선호사항을 선택할 수 있습니다). 저는 이것이 작가가 그의 글에서 사용하기로 선택한 날짜 형식을 강요하는 것보다 더 '위키페디안'의 행동 방식이라고 생각합니다. 노사망 (talk) 2009년 4월 2일 21:29 (UTC)응답하라[응답하라]
  121. 지원 - "이것은 쉬운 일입니다. 물론 독자들은 일반적으로 자신이 좋아하는 형식으로 날짜를 봐야 합니다." -Arb. (talk) 2009년 4월 2일 (UTC) 21:51 답변[답변]
  122. 지원 - 너무 많은 기사가 가장 사소한 이유로 이미 글로벌화 유지관리 템플릿으로 표시되어 있으며, 일부 기사는 날짜 형식보다 더 사소한 것도 있습니다. 날짜 형식 현지화/현지화를 위한 기사의 "전체 형식"에 의존하여 자동 형식을 대체하는 방법이 제시된 해결책은 이러한 상황을 완화하기 보다는 악화시킬 가능성이 높습니다. -- Jeff Billman (talk) 2009년 4월 2일 (UTC) 23:11 (답변)
  123. 지원 – 저는 옵션의 팬이지만 위키 사이트에서 확인하기가 매우 어려운(불가능에 가깝습니다) 일관성의 팬입니다. momoricks (make my day) 2009년 4월 3일 (UTC)응답하라
  124. 지원 - 자동 서식 시스템 구현의 어려움을 기준으로 "아니오"를 투표하려고 했는데, 생각해보니 위키백과는 이러한 기술 시스템이 해결되어야 할 플랫폼에 불과하다는 생각이 듭니다. 그리고 사용자를 위한 모든 기사에 일관성을 갖는 것은 매우 좋은 일입니다. "문제가 없다"는 주장에 대한 답으로 - 저는 문제가 있느냐 없느냐를 기준으로 그 변화가 반드시 부정되어야 한다고 생각하지 않습니다. "고장나지 않았다면 고치지 마세요."라는 주장은 더 나은 경험을 제공할 수도 있고 제공하지 않을 수도 있는 새로운 도구의 가능성을 무시합니다. 노력하지 않으면 절대 알 수 없습니다. 호주 매트 (talk) 2009년 4월 3일 02:03 (UTC)답장[답장]
  125. 강력한 지원 사용자별로 날짜를 자동 형식으로 지정할 수 있는 것은 훌륭한 아이디어입니다. 이것은 위키백과의 중립 정신을 구현한 것입니다. 자동 형식 태그는 위키피디아 전체의 날짜를 태그로 지정하는 이점을 추가하므로 나중에 더 나은 형식이 논의되면 새 형식으로 쉽게 롤오버할 수 있습니다. 그렇기는 하지만, 더 쉬운 구문은 새로운 사용자가 더 이해하기 쉽게 만들 수 있다고 생각합니다.
    일부 사람들은 현재 형식에 감정적인 "구매"를 하고 있으며, 수천 시간의 날짜를 수동으로 편집하는 데 사용하고 있다는 것을 알고 있습니다. 그들의 기여에 대해 감사를 표하지만, 몇 시간 동안 코딩 작업을 통해 비슷한 규모의 작업을 완료한 코더와 마찬가지로 수천 시간의 작업에 대해 감사를 표합니다. (코더가 발가락을 많이 밟지 않은 경우) 우리는 여러분의 여정이 아니라 지역사회에 전파되는 것이 여러분의 노동의 결실이라는 것을 잊어서는 안 됩니다.Gsonnenf (talk) 2009년 4월 3일 (UTC) 04:39 답변[답변]
  126. 조건부 지원 - 날짜는 뷰어에 맞게 페이지를 조립할 때 서버에서 자동으로 포맷해야 합니다. 편집자는 이 작업을 수행하기 위해 아무것도 할 필요가 없습니다. 기사 전체에 날짜를 일관되게 입력하면 완료됩니다. Binksternet (talk) 05:52, 2009년 4월 3일 (UTC)답장[답장]
  127. 미래를 내다보는 지원 기능을 통해 단순 구문 날짜를 자동으로 포맷하면 현재 많은 사용자가 이해하는 수준 이상의 미래를 증명할 수 있습니다. (음, 대부분) 모든 BOT는 달성 가능하며 대부분 불일치와 지속적인 편집 및 반환으로 인해 현재 달성할 수 없는 일관성을 제공합니다. IP 사용자를 위한 기본 프레젠테이션, 심지어 인식된 위치에 따라 대상이 될 수도 있습니다. 선호도는 구글 및 수많은 다른 사람들이 사용하는 쿠키 시스템에 의해 IP에 대해 개별적으로 제공될 수도 있습니다. 여기서 개선에 대한 저항은 무엇입니까? 원하지 않는 사람들을 위한 어떤 일도 하지 않을 것입니다. BOT와 위키놈들은 현재의 혼란을 훨씬 더 잘 실현시킬 수 있습니다. 또한 자동 포맷을 사용하면 링크와 링크 해제 사이를 즉시 전환할 수 있습니다. 예, 링크가 포맷과 관련되어 있지 않다는 것을 알고 있습니다. --ClubOranjeT 2009년 4월 3일 (UTC)07:29 (UTC)답장[답장]
  128. 서포트. 자동 포맷의 장점은 분명합니다. 기존 페이지를 업데이트하면 봇이 기꺼이 처리합니다. Dampinograaf (talk) 2009년 4월 3일 (UTC) 21:03 답변[답변]
  129. 지원. --IanOsgood (talk) 2009년 4월 3일 (UTC) 22:39 답변[답변]
  130. 서포트. 구문을 통한 의미론은 좋은 것입니다. 또한 많은 사람들이 검색합니다.wikipedia.org 누가 - IMHO - ISO 스타일을 더 좋아합니까? 또한 날짜에 대해 더 자세한 정보를 제공할 수 있고 위키링크와 같이 약간의 정보만 표시하면 더 읽기 쉽고 여전히 정보가 가득 찬 기사를 볼 수 있습니다. PAStheLoD (talk) 2009년 4월 3일 (UTC) 23:09 답변[답변]
  131. 서포트. 좋든 나쁘든 유연하지 못한 메인프레임 시스템의 시대는 이미 지났고, 이 시스템이 허용하는 복잡성은 아마도 더 심할 것입니다. 최근의 개별 검색 기록과 관련된 배너 광고와 수백만 명의 사용자에게 서비스를 제공하더라도 이름으로 인사하고 선호도를 기억하는 웹 사이트를 경험하는 것은 이제 일상입니다. 브라우저 쿠키를 준수하여 원하는 형식으로 날짜를 표시하고 인용 날짜를 다시 포맷하지 않는 기능을 추가하는 것은 기술적으로 어려운 일이 아닙니다. 위키 기능에 대해 말하자면, 그것은 아주 일상적인 엔지니어링입니다. 사용자 친화성 외에도, 이러한 인코딩의 큰 이점은 날짜 수확을 단순화하고 촉진한다는 것인데, 이것은 "북태평양에서 가장 많은 난파선이 있는 달은 언제인가?"와 같은 질문에 답하기 위한 이벤트 데이터베이스를 만드는 데 사용될 수 있습니다. "1894년 오리건 주의 하니 카운티에서 무슨 일이 일어났을까요?" "아브라함 링컨이 죽은 후에 일어난 주목할 만한 사건은 무엇이었습니까?" -EncMstr (talk) 05:55, 2009년 4월 4일 (UTC)응답하라[답변]
  132. 가지 주의 사항이 있는 지원: (a) 등록되지 않은 독자는 가능한 모든 수단을 사용하여 하나의 기사 내에서 일관된 형식의 날짜 집합을 보아야 합니다(미국/영국 다양한 영어에 대해 각 기사에 자동으로 태그를 지정하고 봇을 식별할 수 있는 단서가 없는 곳에 무작위로 할당합니까? 아니면 사용자의 IP 주소를 기반으로 하는 대륙별? 아니면...?) 저는 모든 편집자들이 아마도 우리의 데이트 선호도를 설정했기 때문에, 대부분의 독자들이 볼 수 있는 혼란스러운 상황을 보지 못할 위험이 있다고 생각합니다. (b) (약간의 부수적인 문제) 가장 우선적인 것은 3-4-2009나 3/4/2009 (어제 또는 지난 달)처럼 모호한 날짜를 사용하는 것을 피하고 올바르게 하는 것이어야 합니다.(c) 편집자에게 필요한 입력은 키 입력을 최소화하고 기억하기 쉬워야 하며, 봇이 형식을 위한 날짜를 선택할 수 있어야 합니다(인용 또는 작품 제목에 언급된 날짜에 대한 "형식을 지정하지 않음" 태그가 도움이 될 것임을 시사합니다). 그러나 두 날짜 형식이 명예/명예 등 철자만큼 많은 지지를 받고 있다는 점을 감안할 때, 저는 위의 내용을 만족시킬 수 있다면 날짜 형식을 지지합니다. PamD (talk) 2009년 4월 4일 10:33 (UTC)답장[답장]
  133. 지원; 이것은 온라인 백과사전이 지원해야 할 상식적인 기능이며, 처음부터 복잡성이 우려되었다면 WP가 만들어지지 않았을 것입니다. Time3000 (talk) 2009년 4월 4일 10:48 (UTC)응답하라[답변]
  134. 지지; 통일성의 아이디어를 선호합니다. tsjackso (talk) 2009년 4월 4일 14:52 (UTC)응답하라[답변]
  135. 지원; 논쟁을 찾을 수 있으면 논쟁이 발생합니다. 그들이 선호하는 것을 주지 않으면 모든 사람을 행복하게 할 수 없습니다. 사소한 논쟁일 수도 있지만, 그보다 더 적게 발생했습니다. 자동 포맷이 사람들에게 자신이 선호하는 날짜 형식을 제공할 수 있다면 모든 것이 좋습니다. 현재의 시스템은 작동하고 있으며 잘못된 점을 발견하고 이에 대해 논쟁하려는 편집자들에 의해 평가절하되고 있을 뿐입니다. 인간의 본성은 최상의 것입니다. 그래서 제가 보기에는 자동 포맷이 현재 시스템을 사용하는 방법입니다. 달성하기 쉽고 기억하기 어려운 템플릿 포맷 없이도 쉽게 실행할 수 있습니다. 쉬운 것은 좋은 것이고, 쉬운 것은 실수하기 쉽고, 무엇보다도 쉬운 것은 단지 그것을 위해서 삶을 어렵게 만들고자 하는 사람들을 화나게 하는 좋은 방법입니다. --WebHamster 2009년 4월 15:56 (UTC)응답하라[답변]
  136. 지원; 이러한 방식으로 글로벌화와 현지화가 모두 쉬워집니다. DMY 또는 YMD에는 내 생일 12/04/72와 같은 진정한 모호성이 있습니다. 협업이 많은 기사, 특히 참고 문헌에서 날짜는 일반적으로 기사 내에서 일관되지 않습니다. 기계가 바보 같은 일을 하도록 내버려 두십시오. 또한 시설이 있다고 해서 의무적으로 해야 하는 것은 아니며, 무언가를 연결하거나 섹션에 넣는 것 이상이 의무적입니다. 사이먼트루 (talk) 2009년 4월 4일 (UTC) 19:56 답변[답변]
  137. 오늘 05/02/09 또는 02/05/09일에 지원합니다. 주로 모든 영어 사용자들이 두 가지 모두가 명백하게 거짓이라는 것을 인식하기 때문입니다. 만약 이 경우 MOS 날짜 문제와 날짜 반환 전쟁이 절반도 발생하지 않을 것입니다. Khukri 2009년 4월 4일 (UTC) 23:32 회신[답변]
  138. 서포트. 이 시설을 이용할 수 있으면 좋을 것 같습니다. 마음에 안 드시면 그냥 쓰지 마세요. --catslash (talk) 2009년 4월 4일 (UTC) 23:43 (답변)
  139. 서포트. 특히 기사 내에서 일관성은 가독성에 큰 이점이 될 것이며, 날짜가 기존 기사의 나머지 부분과 내부적으로 일치하는지 확인하는 성가신 작업을 줄일 수 있습니다. 여러 기사에 걸쳐 날짜 형식이 일치하지 않는 것은 분명히 성가신 일이지만 쇼 스톱퍼는 아닙니다. 기사에 나오는 모든 기존 날짜에 대해 걱정하는 것은 위험한 일입니다. 나가서 모두 고칠 필요는 없지만, 로봇이 그렇게 쓸 수 있다고 생각합니다. --bthelp 2009년 4월 5일 (UTC) 01:17 (답장)
  140. 서포트. 날짜를 연결하지 않고도 날짜를 식별할 수 있는 것은 당연하며, 사용자별로 형식을 변경할 수 있는 기능은 보너스입니다. Igenlode (talk) 2009년 4월 5일 02:17 (UTC)답장[답장]
  141. 지원. a) 날짜 연결과는 별개로 독립적인 기능으로 자동 형식을 사용할 수 있어야 합니다. b) 모호하지 않을 때는 "모든 영어 사용자가 두 가지를 모두 인식"할 수 있지만, "두 가지를 모두 인식"하는 것은 문제도 문제도 아닙니다. 문제는 모호성입니다. c) 기계가 작업을 하도록 합니다. d) 사용 가능한 경우 사용은 선택 사항(의무 사항이 아님)입니다. 사용할 수 없는 경우... e) 가능한 한 간단하게 해주세요. f) 등 pdfdf (talk) 06:52, 2009년 4월 5일 (UTC)답장[답장]
  142. 지원 위와 같이 Brian (Talk) 2009년 4월 5일 08:01 (UTC)응답하라[답변]에 익숙한 형식으로 날짜를 보다 쉽고 빠르게 볼 수 있습니다.
  143. 메타데이터 목적으로 마크업을 지원하고, 특별히 요청한 독자를 위해 자동 포맷을 할 수도 있습니다. 구문 {{date}...}} 이해하는 것은 그리 어렵지 않을 것이며, Template에서 문서를 찾을 수 있습니다.날짜. 기사에서 해시나 대괄호를 사용하는 특수 구문은 더 미스터리에 가깝습니다. JonH (talk) 2009년 4월 5일 (UTC) 09:01 답변[답변]
  144. 서포트. 대부분 원칙적으로 지원하며 날짜 형식에 대한 새로운 방법이 잘 진행되고 있습니다. Nja247 21:11, 2009년 4월 5일 (UTC)답장[답장]
  145. 지원 - 사용자 선택권과 일관성을 제공합니다. --Boson (talk) 2009년 4월 5일 (UTC)응답하라[답변]
  146. 지원 - 위키 전체에 일관성을 제공합니다. Hohob (talk) 2009년 4월 6일 (UTC) 00:02 답변[답변]
  147. Support #90은 설득력 있는 의견을 제시합니다 Captndelta (talk) 2009년 4월 6일 00:57 (UTC)응답하라[답변]
  148. 지원 - 기사에 대한 여러 유형의 영어 간 불일치를 자동으로 해결합니다. 원하는 형식을 선택하기만 하면 위키피디아에 자동으로 표시됩니다. 저는 이 아이디어가 마음에 들고 영어의 다른 영역으로도 확장될 가능성이 있다고 생각합니다. Suicup (talk) 2009년 4월 6일 06:19 (UTC)답장[답장]
  149. 지원 여기에는 두 가지 별개의 문제가 있습니다. 독자에게 날짜는 어떻게 보이며, 기사에서 실제로 형식화된 날짜는 어떻게 다른 것입니다. 날짜가 실제로 포맷되는 방식에 일관성이 있는 한, 독자에게 날짜가 어떻게 보이는지에 대한 문제는 구현하기 쉽습니다. 비용이 저렴하다면 독자에게 추가 옵션을 제공하는 것에 모두 찬성합니다. Phil_burnstein (talk) 2009년 4월 6일 09:31 (UTC)답장[답장]
  150. 지원 -- ~~~ 구문이 자동 형식이 되지 않는 것은 항상 저를 짜증나게 합니다. 날짜와 시간을 기록과 시각적으로 일치시키는 것을 더 어렵게 하기 때문입니다. 그래서 제가 선호하는 UTC와 yyy-mm-dd 형식을 항상 사용했습니다. --윌리엄 앨런 심슨 (토크) 2009년 4월 6일 (UTC) 14:17 (답변)
  151. 약한 지원 -- 저는 날짜 자동 형식의 개념을 지지하는데, 이는 기사에서 "일관된 날짜 형식을 제시하는 능력이 향상되었다"는 이유 때문입니다.
    1. . 이 기능이 MOSNUM에 추가되어 날짜를 포맷하는 데 필요한 기능(예: {#formatdate})을 사용해야 하는 변경 사항과 결합된다면 제 지원은 더욱 강화될 것입니다.
    2. 저의 지지는 다음과 같은 주장에 영향을 받지 않았습니다.
      1. (찬성) benefits은 분명합니다. 이것은 단지 찬성하는 세 가지 점을 요약한 것일 뿐입니다; 게다가, 저는 결정하기 전에 그 개념이 생각할 가치가 있다는 것을 알았기 때문에, 제게 명백하지 않았습니다.
      2. (반대) "해결할 문제 없습니다." 이 주장에 열거된 문제인 "일이 먼저든 달이 먼저든"(1월 3일, 1월 3일)가 중요하지 않다는 것에는 동의하지만, 해결해야 할 문제가 없다는 것에는 동의하지 않습니다. 반대로 백과사전의 일관성 부족이 문제이며, 백과사전 전반에 걸친 날짜 형식의 일관성 부족이 전체 일관성 문제의 한 부분이라고 생각합니다.
      3. (against) ...두 부류의 사용자들. 설명한 대로, 개인 사용자가 로그인하든 하지 않든 일정한 날짜 스타일을 볼 수 있기 때문에 이 문제는 문제가 되지 않는다고 생각합니다.
      4. 메타데이터 오류입니다. 투표하는 사람들의 일부 의견에 언급되어 있기는 하지만, 이 주장이 개념에 찬성하는 진술에서 제시된 것은 아니라고 봅니다.
      5. (반대) 개발 위험, 다만 이 주장이 복잡하고 힘든 주장의 하위 집합이기 때문에, 아래에 동의합니다.
    3. 저의 지지는 이러한 주장들로 인해 약화되었습니다.
      1. (찬성) ...사용자에게 더 많은 옵션제공합니다. 제 생각에, (제가 알기로는) 기능을 추가하는 것뿐만 아니라, 데이터 포맷 측면에서 더 적은 옵션과 기사 전반에 걸친 날짜 스타일의 더 많은 일관성이 필요하다고 생각합니다(즉, 백과사전 전체에 걸쳐). MOSNUM을 변경하지 않고 기능을 추가하는 것은 반대하기 위한 약한 지원으로 인해 변경될 것입니다.
      2. (반대로) 복잡하고 힘이 듭니다. 저는 이 점에서 위키미디어 CTO의 언급된 성명에 가장 큰 영향을 받았습니다.
        --4wajzkd02 (talk) 18:38, 6 April 2009 (UTC)Reply[reply]
  152. 지원 사용자가 현지화된 선택을 할 수 있도록 합니다. 저는 위키피디아를 모국어인 영어와 최대한 가까운 방식으로 읽고, 미국식과 관행의 거슬리는 침입을 최대한 줄이고 싶습니다. Cyclopaedic (talk) 2009년 4월 6일 19:29 (UTC)응답하라[응답하라]
  153. (찬성으로) 이것은 미래의 상호 운용성을 위한 중요한 측면입니다. Cross bottle (talk) 2009년 4월 6일 22:48 (UTC)답장[답장]
  154. 서포트. 일관성과 사용자 선택 모두 중요합니다. 날짜 형식 환경설정 및 유사한 성격의 다른 사용자 환경설정을 등록된 사용자로 제한할 필요가 있는 기술적 이유는 없습니다. 간단한 JS 해킹을 통해 등록되지 않은 사용자도 세션 쿠키를 설정하여 원하는 날짜 형식을 선택할 수 있습니다. 121a0012 (talk) 02:58, 2009년 4월 7일 (UTC)답장[답장]
  155. 서포트. 자동 포맷은 많은 최신 기사를 괴롭히는 일관성 문제를 제거하는 데 도움이 될 것입니다. 또한 사용자가 편리하게 원하는 대로 포맷할 수 있도록 하면 좋을 것 같습니다. Brian Powell (talk) 2009년 4월 7일 03:35 (UTC)답장[답장]
  156. 지원 독자는 데이트 상대가 어떻게 보이기를 원하는지 확인할 수 있고 다른 스타일로 혼란스럽지 않은지 확인할 수 있습니다. 그리고 모든 사람들이 자신만의 스타일을 선택할 수 있기 때문에, 기사의 날짜에 대한 편집 경고를 줄여야 합니다. --Falcorian 05:50 (UTC)응답하라[답변]
  157. 지원 모든 사용자가 선호하는 형식을 볼 수 있기 때문에 일관성이 추가됩니다. 구현으로 인한 초기 고통은 장기적인 이점으로 인해 크게 완화될 것입니다. Scrxisi (talk) 2009년 4월 7일 12:31 (UTC)답장[답장]
  158. 일반적인 사용자 환경의 확실한 개선을 지원하며, 이를 구현하기 위해 JS나 MediaWiki 해킹이 필요하지 않습니다(비록 더 부드럽게 만들 수도 있음). 템플릿, 일부 CSS 클래스 및 이미 존재하는 #time 파서 기능으로 충분합니다. Carolina wren (talk) 2009년 4월 7일 16:38 (UTC)응답하라[답변]
  159. 지원 위키피디아는 풍부한 웹 애플리케이션입니다. 풍부한 웹 응용프로그램에서 사용자 정의 날짜 형식을 선택하는 것은 쉬운 일이 아닙니다. 2009년 4월 7일 19:48 (UTC)응답하라talk.
  160. #149 및 #90에 따라 지원합니다. (네, 저는 나름대로 생각했지만 다른 분들이 저보다 논변을 잘 쓰십니다.) ~user:orngjce 223 ☺ 타이핑은 어떻게 하나요? 2009년 4월 7일 20:06 (UTC)답장[답장]
  161. 지원 - 저는 이 토론에 크게 신경 쓰지 않지만, 자동 포맷이라는 일반적인 개념에는 문제가 없습니다. 이점은 꽤 분명해 보이고 비용은 훨씬 덜 듭니다. 로보피쉬 (talk) 2009년 4월 7일 (UTC) 23:47 답변[답변]
  162. 서포트. 자동 서식은 사용자가 가장 잘 알고 있는 형식으로 날짜를 현지화하는 효과적인 방법이며 여러 기사에 걸쳐 날짜 형식의 불일치를 방지합니다. NTP (talk) 2009년 4월 8일 04:23 (UTC)답장[답장]
  163. 서포트. 위키피디아에는 너무 많은 불일치가 있습니다. 저는 모든 기사의 일관성을 높이는 모든 조치를 지지합니다. Misty Willows 2009년 4월 8일 08:09 (UTC)답장[답장]
  164. 지원은 일관된 형식의 날짜를 보고 싶지만 사용자마다 선호하는 것이 다르기 때문에 어떤 형태로든 자동 형식이 필요합니다. -- MightyWarrior (대화) 2009년 4월 8일 (UTC) 11:44 (답변)
  165. 날짜에 대한 공통 형식에 동의하는 것보다 이 기능을 사용하는 것이 더 쉬울 것이기 때문에 지지합니다. 그리고 합의된 공통 형식이 없으면 기사가 지저분하고 일관성이 없어 보이기 시작합니다. Andrew Dalby 2009년 4월 8일 (UTC) 12:41 답변[답변]
  166. 지원 이것은 모든 합리적인 문제를 해결해야 합니다. 히포크라이트 (talk) 2009년 4월 8일 14:06 (UTC)답장[답장]
  167. 서포트. 각 사용자가 날짜 형식을 선택할 수 있는 것 외에도 날짜 연결 여부를 선택할 수 있습니다. 이는 등록된 시청자를 만족시켜야 하며, 실제 토론은 등록되지 않은 사용자의 경우 자동 링크에 대한 것이어야 합니다. (날짜 형식은 사용자의 출신 국가에 따라 선택될 것이므로 토론할 필요가 없다고 생각합니다.) -- Psbsub에서 추가서명되지 않은 이전 의견 (talk contributes)
  168. 서포트. 북미가 아닌 날짜 형식을 얻을 수 있습니다! 위키피터 프로젝트 (talk) 2009년 4월 8일 (UTC) 21:18 답변[답변]
  169. 지원; 편집자로서 어느 쪽이든 상관없지만, 독자로서 제가 익숙한 형식으로 날짜를 일관되게 표시하는 것이 더 쉽고 쉽게 접근할 수 있습니다. 아이세린talk 2009년 4월 9일 09:49 (UTC)답장[답장]
  170. 서포트. 비북미 날짜 형식(위키피터 프로젝트 등)을 선호하는 사람들이 있다는 사실만으로도 이런 방식으로 투표해야 합니다. 저에게 "2009년 4월 9일"이 아닌 다른 것은 이상하고 추해 보입니다. 그리고 저는 많은 미국인들이 그것을 똑같이 보고 있다고 확신합니다. 하지만 저는 우리가 모든 것을 지배해야 한다는 요구는 없다고 생각합니다. 그래서 자동 포맷을 사용하면 "2009년 4월 9일"을 볼 수 있고 다른 것들은 "2009년 4월 9일" 또는 "2009-04-09"를 볼 수 있습니다. 반대하는 사람은 왜 저를 피해요. -- BRG (talk) 2009년 4월 9일 (UTC) 13:45 (답변)
  171. 서포트. 제가 위키백과를 비교적 처음 접하는 편이지만(최근에 다시 가입하기 전에 여기서 논의한 것과 무관한 이유로 2006년에 탈퇴했습니다), 저는 이 부분에 대해 발언권이 필요하다고 생각합니다. 그것이 언급되었고, 찬성과 반대의 성명서를 모두 읽은 후에, 저는 성명서에 대한 것이 더 이치에 맞는다고 생각합니다. 첫째, 저는 우리가 여기에 존재하지 않는 문제를 해결하려고 한다는 것에 동의하지 않습니다. 포맷 일관성은 모든 출판물에서 중요하고 필수적인 부분이며, 일관성 없는 포맷과 이중 표준의 사용은 비전문성을 반영합니다. 네, 미등록 사용자가 사용하고 싶은 날짜 형식을 선택할 수 없게 되는 것은 약간 억울하지만, 적어도 모든 기사에서 일관된 날짜 형식을 볼 수 있을 것이라는 점에서 반박됩니다. 힘들고 복잡하다고요? 저는 이것이 봇을 위한 것이라고 생각했습니다! 그리고 위키피디아의 제약을 받는 구글 검색이 제대로 사용되지 않는 데는 상당한 이유가 있습니다. 바로 그것이 진흙탕이기 때문입니다. 외부 검색 엔진에 의존하지 않고 자체 검색 엔진을 사용할 수 없는 이유는 무엇입니까? 개발 위험은 현실적인 문제이지만, 저는 우리가 이 해결책을 시행하기 전에 이러한 문제들을 해결할 수 있는 통찰력이 부족하지 않다면, 이것은 큰 문제가 되지 않을 것이라고 믿습니다. --A.K.R. (talk) 2009년 4월 9일 (UTC) 16:14 (답변)
  172. 서포트. 많은 사람들이 다른 날짜 형식을 가지고 있으므로 정말 도움이 될 수 있습니다. 그 외에도 아래의 여론조사(위키피디아 페이지:날짜 형식 지정연결 여론조사)에는 필요한 날짜만 연결되어 있으며, 이를 통과하지 못하면 날짜가 자동으로 형식화되지 않습니다. 그래서 저는 이 자동 포맷의 통과를 지지합니다! MathCool 10 2009년 4월 9일 18:52 (UTC)답장[답장]
  173. 지원 - 사람의 선택권을 유지하면서 가치 있는 표준화. Finavon (talk) 2009년 4월 9일 18:55 (UTC)답장[답장]
  174. 전체적으로 지원 간소화된 날짜 형식은 크게 개선될 것입니다.2009년 4월 9일(UTC) 22:46 주취자 승인
  175. 지원 위키백과 전체 날짜의 통일성은 작지만 필요한 웹사이트 Sean118 (토크) 00:03, 2009년 4월 10일 (UTC)응답하라
  176. 지원 자동 포맷은 작은 마음 사이의 편집 전쟁을 방지합니다. 현재 링크 형식의 날짜가 신의 선물이며 모든 자동 형식을 제거하면 크게 짜증날 것이라고 생각하는 사용자가 있습니다. Cstaffa (talk) 2009년 4월 10일 00:06 (UTC)답장[답장]
  177. 지원 - 날짜를 표시하는 방법을 선택하는 옵션은 중요합니다. 물론 두 시스템의 사용자는 서로를 인식할 수 있지만 왜 그렇게 해야 합니까? 이를 통해 '전면적'이 쉬워지고 편집 전쟁을 방지할 수 있습니다. --Alinnisawest,Dalek Empress (여기서 퇴출 요청) 2009년 4월 10일 (UTC)응답하라[답변]
  178. 지원 --Michael (talk) 2009년 4월 10일 (UTC) 04:21 답변[답변]
  179. 지원 - 다른 형식으로 날짜를 잡는 것은 혼란스럽습니다. --Pot (talk) 2009년 4월 10일 (UTC)04:45 (답장)
  180. 지원 - 날짜 형식의 혼란이 현실 세계에 만연해 있습니다. 더 악화시키지 맙시다. Tarlneustater (talk) 2009년 4월 10일 05:03 (UTC)답장[답장]
  181. 서포트. 독자들에게 위키피디아는 기사 전반에 걸쳐, 그리고 종종 기사 내에서도 날짜 형식에 대한 현재의 불일치로 아마추어처럼 보입니다. 특히 인용 템플릿을 사용하여 지난 몇 달 동안 참고 문헌에서 관찰하는 "원" ISO 날짜("2008-05-12")(예: Pearl_Jam_discography#References, 심지어 기능 목록입니다!). 제 눈에는 날짜 자동 형식이 이 한계에서 벗어나는 유일한 방법입니다. IP 리더의 경우 북미 지역의 IP에 대해서는 "2006년 1월 14일"을, 다른 지역의 IP에 대해서는 "2006년 1월 14일"을 표시하는 기술적 해결책을 찾을 수 있다고 확신합니다. 편집자의 경우 시스템이 사용하기 쉽고 기존 예를 살펴서 신입을 쉽게 파악할 수 있어야 합니다. 제가 선호하는 것은 ISO 표준에 기반한 간단한 템플릿 시스템입니다. 예를 들어, 위 날짜의 경우 {{date:2006-01-14}}, 2006년 1월의 경우 {{date:2006-01}, 또는 2006년의 경우 단순히 {date:2006}입니다. 간격은 2006년 1월 14일부터 22일까지 {{date:2006-01-14/2006-01-22}}일 수 있습니다. 이 시스템이 다른 사람들을 위해 작동할 수 있다면(그리고 그럴 수 있다면, 그렇지 않다면 ISO가 아닐 것입니다), 우리를 위해 작동할 수도 있습니다! - IbLeo (talk) 2009년 4월 10일 (UTC) 05:09 (답변)
  182. 지원 - 일관성이 중요합니다. 이것은 (결국) 도움이 될 것입니다. Ingolfson (talk) 2009년 4월 10일 (UTC) 09:44 답변[답변]
  183. 지원 - 가장 중요한 것은 날짜를 독자가 쉽게 이해할 수 있고 모든 기사에서 일관성이 있다는 것입니다. 사용자의 로컬로 포맷하는 것이 올바른 결정인 것 같습니다. 어쨌든 날짜를 연결하고 연결을 해제하는 것은 어리석은 일이었습니다. 연결된 날짜를 지지하는 많은 사람들은 날짜가 표현되는 방식에 있어서 어느 정도의 일관성을 찾고 있었습니다. 그 날짜에 일어난 일들의 목록에 연결하는 것은 큰 가치를 제공하지 못했습니다. 이 작업을 수행하는 데 필요한 노력은 중요하지 않지만, 이 작업은 BOT에 이상적으로 적합한 작업으로 보입니다.--RadioFan (talk) 2009년 4월 10일 (UTC)응답하라[답변]
  184. 지원 - 위키백과는 진정으로 국제적이어야 합니다. 미국 이외의 국가가 다른 날짜 형식을 채택했다면 우리는 이 토론을 하지도 않았을 것입니다. 그러나 미국 편집자들의 우세를 감안할 때, 다른 세계가 이에 대처하는 동안 그들이 적합하다고 생각하는 대로 그들에게 뼈를 발라주고 날짜를 지정하도록 하는 것은 무리가 아닙니다. 앙고라 물고기 2009년 4월 10일 13:54 (UTC)답장[답장]
  185. 구문이 단순한 경우를 지원합니다. 또한 독자들이 자동 형식화된 날짜를 보고 있다는 것을 안심시키기 위해 (예: 십대 초첨자 점) 무언가를 고려해야 합니다. 오해를 불러일으킬 수 있는 문자 텍스트뿐만 아니라 말이죠. 하지만 그것이 어떤 식으로든 몇 년, 날짜 등의 끔찍한 오버링크로 이어진다면 제 지지는 사라집니다.ENG (talk) 2009년 4월 10일 (UTC) 19:03 답변[답변]
  186. 지원 관련 없는 링크는 독자에게 진정으로 가치 있는 링크를 방해할 뿐입니다. --doll [chat] 2009년 4월 10일 (UTC) 22:38 (답장)
  187. 지원 오버헤드는 미미해 보이며, 독자들이 날짜를 일관성 있게 볼 수 있습니다. 또한 "2009년 3월 11일"이라는 형식이 매우 유행에 뒤떨어지는 날이 올 수도 있으며, 이러한 개별 인스턴스를 모두 업데이트하기를 원합니다. 위키피디아는 아직 작지만 지금은 자동화하는 것이 좋습니다. Spiel496 (talk) 2009년 4월 11일 01:29 (UTC)답장[답장]
  188. 지원 이렇게 하면 일관성과 사용자 환경설정별 표시 날짜가 향상됩니다. 그러나 "1974"는 본질적으로 어느 한쪽에 쉼표로 시작해야 하는 긍정적인 단어인 "1974"에서 마지막 쉼표를 누락하는 것과 같은 수천 개의 구두점 오류를 없앨 수 있을까요?Martindelaware (talk) 2009년 4월 11일 06:29 (UTC)답장[답장]
  189. 독자들이 쉽게/일관성을 가질 수 있도록 지원합니다. --Auntof6 (talk) 2009년 4월 11일 (UTC) 07:08 (답변)
  190. 사용자별 지원 Ckatz와 메타데이터에 대한 논쟁(제가 보기에 가장 중요한 것). 또한 ISO 8601(proleptic) 그레고리안 날짜를 #format date의 입력 매개 변수로 사용하는 것이 의무화되어야 합니다. 이는 거의 모든 국가에서 채택된 국제 표준이기 때문입니다(심지어 미국과 EU에서도). Nsaa (talk) 2009년 4월 11일 10:27 (UTC)답장[답장]
  191. 날짜와 시간으로 지원하는 것은 모든 주제 분야에 공통적이며, 표준화는 이를 논리적으로 확장한 것입니다. --Gavin Collins (talk contributes) 2009년 4월 11일 (UTC)10:43 (답변)
  192. 서포트. 편집자가 프로필에 "날짜와 기본 설정"을 설정하고 이를 무시하도록 허용하는 이유는 무엇입니까? MeegsC Talk 2009년 4월 11일 (UTC) 11:58 답변[답변]
  193. 서포트. 누군가가 날짜를 삭제해야 한다고 결정한 날은 누군가가 WPTC에 엄청난 골칫거리를 만들어낸 날입니다. 우리의 기사는 육지가 아닌 바다를 다루고 있기 때문에 여전히 결정할 수 없습니다. Potapych (talk) 2009년 4월 11일 12:34 (UTC)답장[답장]
  194. 지원, 최소한의 문제로 개인적인 선택이 가능합니다. (아니요, "wikitext를 읽을 수 없습니다"는 인용 템플릿과 파서 기능의 광범위성 덕분에 이미 읽을 수 없기 때문에 유효한 불만 사항이 아닙니다.) Titoxd(?!? - cool stuff) 2009년 4월 11일 (UTC) 18:19 답변[답변]
  195. 지원 독자로서 마음에 듭니다. --Fabricramp talk me 2009년 4월 11일 (UTC) 23:17 (답장)
  196. 강력한 지원. Per IbLeo(#182)--EMU CPA (talk) 2009년 4월 12일 02:21 (UTC)응답하라[답변]
  197. 선택 사항인 한 지원하고 일반 텍스트 날짜를 형식화된 날짜로 변경하는 봇이 없습니다. 진정한 합의를 통해, 정상적인 인간 편집을 통해, 이것이 일반적으로 유용한지 아닌지 결정하도록 합시다. Dhoowell (talk) 2009년 4월 12일 04:11 (UTC)답장[답장]
  198. 국제 사용성 향상을 위한 유용한 기능 지원 JulesH (talk) 2009년 4월 12일 11:02 (UTC)응답하라[답변]
  199. 지원 {{ipa}}과 같이 점진적으로 선택적으로 수행할 수 있으며, 언급된 다른 두 가지 문제를 해결하는 데 도움이 됩니다.Jchthys 2009년 4월 12일 14:34 (UTC)답장[답장]
  200. 지원 봇 실행은 필요 없지만 위에서 언급한 대로 자연스럽게 개발할 수 있습니다. 올바른 방법으로 날짜를 포맷하는 것에 대해 걱정하고 싶지 않은 플라이 바이 에디터로서 이 옵션은 중요합니다(이것은 미국 기사입니까, 영어 기사입니까?) 자동 포맷이 잘 될 것입니다 아가토클레아 (talk) 2009년 4월 12일 14:38 (UTC)답장[답장]
  201. 지원 - 자동 포맷은 확실히 잠재력이 있습니다. 로그아웃한 사용자가 위키백과의 전자적 특성을 더욱 활용할 수 있도록 일종의 선호도를 설정할 수 있는 등 더 많은 옵션을 제공하고 싶습니다. 자동 포맷을 위해 링크가 더 이상 필요하지 않고, 사람의 편집을 통해 시간이 지남에 따라 느리게 발전할 수 있지만 봇이 대부분의 작업을 수행할 수 있는 잠재력은 여전히 열려 있습니다. 저는 기사 전반에 걸친 일관성이 다른 백과사전과 마찬가지로 도움이 될 것이라고 믿습니다. 그리고 아마도 사소한 것이어야 할 것이지만, 이것은 분명히 몇몇 사람들에게 중요합니다. Camaron Chris (talk) 2009년 4월 12일 14:40 (UTC)답장[답장]
  202. 강력한 지원 위키백과는 WP가 아닙니다.PAPER 백과사전, 그리고 날짜를 포맷하는 방법을 모르거나 귀찮은 편집자들은 가능한 편집자들에게 맡길 수 있습니다. 의미론적인 기사는 좋은 것일 뿐입니다. -- M2Ys4U 2009년 4월 12일 (UTC) 15:33 답변[답변]
  203. 강력한 지지 가장 대중적인 형식을 지지하는 것은 타당합니다 --The lost libertine (talk) 2009년 4월 12일 (UTC) 18:01 (답변)
  204. 서포트. 열대성 사이클론이 분지를 이송할 때 WPTC 회원들에게 두통을 일으키는 것처럼 충돌을 피하는 데 도움이 되는 Linked date가 좋을 것 같습니다. 또한 "관련 기사"에 링크해야 한다면 날짜 기사에 링크해야 하는 이유는 무엇입니까? Jason Rees (talk) 2009년 4월 12일 (UTC) 23:32 답변[답변]
  205. 서포트. 날짜 형식을 사용하면 독자가 날짜를 빠르게 이해할 수 있고 모든 사람이 선호하는 날짜를 가질 수 있습니다(나는 잠시 후에 내 날짜를 설정합니다). 등록되지 않은 사용자의 경우, 자동 포맷을 OS/브라우저 로케일 설정(웹 서버에서 액세스할 수 있는 경우)과 결합하거나 IP 주소 도메인이 시작되는 국가(GeoIP 데이터베이스의 일종을 사용)를 유추하는 것은 꿈같은 일입니다. +mt 00:56, 2009년 4월 13일 (UTC)답장[답장]
  206. 관련 기사 불일치에 대한 최상의 해결책으로 지원, 전쟁과 그로 인해 발생하는 정책 교착 상태를 편집합니다(예: 위 WP:WPTC 상황은 이러한 날짜 형식 제안으로 합의를 달성할 수 없는 역사적인 무능력은 말할 것도 없습니다). 자동 포맷은 글로벌 환경에서 위키피디아 콘텐츠를 조정하고 배포할 수 있는 탁월한 기능을 제공합니다. 날짜 형식의 차이는 시스템적 편향 문제를 수반합니다. 예를 들어 MDY는 많은 기사에 대해 시행될 경우 글로벌 프로젝트로서 위키피디아에 잘 반영되지 않는 특히 미국적인 시스템적 편향을 수반합니다(그리고 그것이 WP:NPOV입니다). 또한 실제로 사용되는 일부 날짜 형식(ISO 8601, YMD)은 정책에 따라 제외되지만 자동 형식을 사용하여 검색할 수 있습니다. 대부분의 기능은 이미 Wikimedia에 구현되어 있습니다. i18n과 L10n으로 볼 때, 날짜 범위와 등록되지 않은 사용자를 위해 정리해야 하는 저행열매입니다. 그러면 우리는 앞으로 나아가 다시 한번 이 기능을 잘 활용해야 합니다. Dl2000 (talk) 2009년 4월 13일 01:18 (UTC)답장[답장]
  207. 지원 - 저는 작가가 좋아하는 형식보다는 시스템 (최종적으로) 제가 선호하는 형식으로 날짜를 정한다는 생각이 확실히 마음에 듭니다. 개인적으로 컴퓨터 프로그래밍에 익숙하기 때문에 "YYY-MM-DD"를 선호합니다. 데이트를 보고 싶은 또 다른 방법은 "DDD, MMMMD, YYY"입니다. 그렇게 날짜를 바꿀 수 있다는 생각(컴퓨터가 그렇게 쉽게 할 수 있는 것)은 매우 좋습니다. 저는 항상 위키 마크업을 진흙탕으로 사용하는 것을 싫어했기 때문에 그렇게 하지 않는 경향이 있었습니다. 그러나 이것이 승인되고 자동으로 날짜를 포맷할 수 있게 되면 멋질 것입니다. 사용자에게 가능한 한 자동적이고 투명해야 합니다. 이상적으로 특별한 태그가 필요하지 않습니다. 날짜가 기사에 있고 날짜로 인식할 수 있는 경우 소프트웨어가 이를 조정해야 합니다. 날짜는 아니지만 하나로 인식되는 것이 있다면, 잘못된 긍정을 방지할 수 있는 간단한 태그(아마도 친숙하고 비슷한 용도로 사용되는 것?)가 있어야 합니다. --Willscrlt (→""WillsTalk?!") 2009년 4월 13일 14:06 (UTC)응답하라[답변]
  208. 지원 날짜 형식에 대한 선호도를 설정할 정도로 관심이 많은 독자는 날짜가 일관되게 표시되는 것을 볼 수 있어야 합니다. 선호도를 설정할 만큼 신경 쓰지 않는 독자들은 신경 쓰지 않을 뿐이며, 포맷 반대 편집자들도 신경 쓰지 말아야 합니다. 적어도 그 독자들은 그들이 전문적인 모습을 더해주는 일관된 포맷을 가지고 있다고 볼 것입니다. 철자자 크리스 (talk) 2009년 4월 13일 14:10 (UTC)답장[답장]
  209. 서포트. 이는 (등록된) 사용자가 자신의 요구에 가장 적합한 형식으로 콘텐츠를 볼 수 있는 옵션을 제공함으로써 백과사전의 외관과 느낌을 향상시킵니다. 등록되지 않은 사용자가 환경설정을 통해 이 작업을 수행할 수는 없지만 동일한 옵션을 제공하는 로컬라이제이션 쿠키 또는 이와 같은 것을 구현할 수 있습니다. 등록되지 않은 일반 사용자(많은 사용자)의 경우 자동 포맷을 통해 각 기사에 대한 기본 상태를 정의하여 편집 전쟁을 전체 기사에 대한 기본 날짜 포맷(및 다른 스타일 규칙)을 설정하는 로컬라이제이션 템플릿으로 제한할 수 있습니다. 따라서 일부 사용자만 자신이 선호하는 형식을 설정할 때 추가적인 이점을 인식할 수 있지만 형식 일관성 측면에서 모든 사용자에게 순혜택이 있습니다. 파싱 날짜로 인해 성능 저하가 발생할 수 있다는 점은 인정하지만, 다른 플랫폼에 날짜 파싱을 구현했기 때문에 계산적으로 이것이 불균형적인 단점이라고 볼 수는 없습니다. 또한, 미디어위키 구현에 익숙하지 않지만, 이러한 계산 결과를 페널티를 제한하는 방식으로 캐싱하는 것은 비교적 간단해 보입니다. 기본적으로 미디어위키의 백엔드가 엉망인 것이 아니라면, 페이지의 정기적인 로딩과 템플릿의 평가에 비해 상당한 성능 손실이 발생할지 의문입니다. 마지막으로, 모든 좋은 구현은 (여론조사 질문의 의도로 보이는) 날짜의 의무적인 연결을 피해야 합니다. 그러나 동일한 토큰에 의해 선택된 구문이 적절한 경우 날짜 연결을 방해하지 않아야 합니다. 연준 2009년 4월 13일 16:23 (UTC) 답변[답변]
일반적인 자동 포맷 개념에 반대합니다.
  1. 반대 브리온이 오토포맷을 제거해야 한다고 생각한다면 저는 그걸로 충분합니다. 저는 자동 포맷의 장점이 자동 포맷을 허용하기 위해 수백만 개의 날짜를 마커로 태그하는 것과 같이 그것을 구현하는 데 드는 어려움보다 크지 않다고 생각합니다. 스티브 크로신 24/ 2009년 3월 29일 (UTC) 23:12 답변[답변]
  2. 반대하는 모든 주장에 반대합니다. 더 이상의 옵션은 필요 없습니다. 수용된 날짜 스타일 중 어느 것도 이해하기 어렵습니다. 저는 우리가 ISO 스타일에서 계속 벗어나야 하고 일관성을 위해 자동 포맷에 의존해서는 안 된다고 생각합니다. 람보의 복수 (나는 어떻게 지내?) 2009년 3월 29일 23:16 (UTC)응답하라[응답하라]
  3. 반대: 이것은 복잡한 소프트웨어입니다. 아무도 당신을 설득하지 못하게 하세요. 만약 그들이 6년 동안 그것을 맞추지 못했다면, 그들이 곧 그것을 맞출 것이라고 생각하게 만드는 것은 아무것도 없습니다. 물론 브리온 비버는 그가 무슨 말을 하는지 알고 있습니다. 사람들이 '고통이 없고 이득이 없다'고 말하는 반면, 이것은 얻는 것이 거의 없기에는 너무 많은 고통입니다. 돼지에게 립스틱을 발라도 돼지라는 사실이 바뀌지 않습니다. 오공자(talk) 2009년 3월 29일 (UTC) 23:21 답변[답변]
  4. 약하게 반대합니다. 이 문제가 지금 발생한다면 WP에 따라 두 가지 형식을 모두 허용함으로써 해결할 수 있을 것입니다.ENGVAR. 자동 포맷은 행동 문제를 기술적으로 해결하기 위한 실패한 노력이었고, 쉼표가 날짜 뒤에 오는 지에 대한 해결할 수 없는 문법적 어려움에 직면해 있습니다. 2009년 3월 29일 23:23 (UTC) 답변[답변]
  5. 의장님께 반대합니다. --John (talk) 2009년 3월 29일 (UTC) 23:34 (답변)
  6. 반대. 버그질라 분석은 일반적으로 반대입니다. 대부분의 사용자는 두 가지 주요 형식(DMY 및 MDY)을 모두 이해할 수 있습니다. 저는 그것이 재장착되지 않을 것이라고 생각하지 않지만, 그것은 악몽이 될 가능성이 높습니다. 그리고 자동화는 매우 위험할 것입니다. 왜냐하면 버그질라 분석은 자동 재장착이 잘못된 경우의 유형을 식별하기 때문입니다. 마지막으로, 제대로 작동하려면 템플릿이나 기타 추가 마크업 타이핑이 필요하다면, 저는 전적으로 반대합니다. WP는 WP에 매우 취약합니다.아마도 몇 년 안에 이것이 MOS 요구사항이 될 것이며, 는 MOS가 절대로 요구해서는 안 되는 지금 우리가 입법화할 수 있는 어떤 메커니즘도 알지 못합니다. -Philcha (talk) 2009년 3월 29일 (UTC)23:45 (답변)
  7. 반대하다 해결해야 할 "문제"는 없습니다. 언급된 바와 같이 WP:ENGVAR은 영어 변형에 잘 작동하는데 날짜를 지정하는 것은 어떻습니까? Dabomb87 (talk) 2009년 3월 29일 23:47 (UTC)답장[답장]
  8. 반대. -- 도널드 앨버리 2009년 3월 29일 (UTC) 23:53 답변[답변]
  9. 반대: 우리는 이것으로 어떤 문제를 해결하려고 합니까? seecer talk 기고문 2009년 3월 29일 (UTC) 23:55 답변[답변]
  10. 특별 기고가로서, 저는 그것에 대한 이유를 찾지 못했습니다. --Der Wohltempierte Fuchs (talk) 2009년 3월 29일 (UTC)23:57 [답변]
  11. 반대. "프로" 주장은 전혀 설득력이 없지만, "콘트라" 주장은 매우 현실적인 문제를 설명합니다. 단지 몇 명의 사람들에게 미국 철자가 적힌 기사를 영국 날짜 형식으로 보여줄 수 있는 선택권을 주기 위한 모든 단점이 있습니까? 아니면 그 반대입니까? 명백한 기능 팽만감입니다. --Hans Adler (talk) 2009년 3월 30일 (UTC) 00:00 답변[답변]
  12. 반대 - 대부분의 위키백과 사용자는 편집자가 아닌 독자이므로 대부분의 기능은 편집자를 위해 설계되어야 합니다. 날짜 연결은 유용한 연결을 평가절하합니다. 또한 편집자에게 불필요한 추가 작업이 필요합니다. Awadewit (talk) 2009년 3월 30일 00:07 (UTC)답장[답장]
  13. 자동 포맷을 반대합니다. 저는 오버링크된 날짜의 무의미한 파란 혼란을 싫어합니다. 그리고 미국과 영국의 사람들이 서로 거의 동일한 날짜 형식에 혼란을 겪게 되는 것은 다소 이상하지 않습니까? 훨씬 더 광범위하게 날짜 형식이 가변적인 나머지 국가들이 두 가지 모두를 이해할 수 있는 능력이 있는 경우입니다. Bishonen talk 00:07, 2009년 3월 30일 (UTC)회답[회답]
  14. 반대합니다, 저는 이것이 실제로 필요하다고 생각하지 않습니다. 해결책으로 이것이 필요한 문제가 있다고 확신하지 못합니다. 레이븐 1977Talk to meMy edits:15, 2009년 3월 30일 (UTC)답장[답장]
  15. 반대 저는 이것이 1차, 2차, 3차에 걸쳐 해결되었다고 생각했을 것입니다. 이제 네 번째입니다. 아니요, 자동 포맷은 바람직하지 않습니다. 필요한 것도 아닙니다. 기사에 가장 적합한 형식(MOSNUM 가이드라인 기준)을 선택하여 고정된 텍스트로 작성한 후 작업을 완료합니다. 한 줌의 편집자들이 그들이 좋아하지 않는 날짜 형식을 보는 충격을 면할 수 있도록 이 모든 후프를 뛰어 넘는 것은 그들이 살아남을 것입니다. 저는 그것을 보장합니다. Greg L (talk) 2009년 3월 30일 (UTC) 00:26 답변[답변]
  16. 반대. 위키피디아 독자들이 "색" 대 "색", "알루미늄" 대 "알루미늄" 대 "알루미늄"을 다룰 만큼 똑똑하다면 "3월 30일" 대 "3월 30일"을 다룰 수 있습니다. 그 전제로, 저는 KISS 원칙을 적용하고 복잡성이 추가되는 것은 피하겠습니다. -- Tcncv (talk) 2009년 3월 30일 (UTC) 00:31 (답변)
  17. 반대: 자동 형식을 지정할 필요가 없습니다. 이미 언급했듯이 등록된 사용과 등록되지 않은 사용 간의 차이를 향상시켜 잠재적인 불일치를 숨깁니다. WP를 사용하여 모든 기사는 일관성이 있어야 합니다.MOSNUMWP:ENGVAR.MCollins (talk) 2009년 3월 30일 (UTC) 00:36 답변[답변]
  18. Tcncv당. 핵전쟁 00:46, 2009년 3월 30일 (UTC) 답변[답변]
  19. 반대. 독자와 다른 출력을 보는 편집자는 재앙의 레시피입니다. 오토포밍은 감사합니다, (국제 포맷 FTW)가 있어서 좋지만, 처음 단점을 알게 되었을 때 사용을 중단했습니다. 그 이후로 저는 이것 때문에 많은 기사가 일관되지 않는 것을 보았습니다. 기능을 껐기 때문에 수정된 기사. 제가 자동 포맷을 지원하는 유일한 방법은 모든 기사가 등록되지 않은 사용자, 가급적이면 국제 날짜(DDMMYYYY)에 대해 동일한 출력을 갖는 것입니다. 즉, 어떤 형식으로 날짜를 표시해야 하는지 지정하는 마법 단어로 개별 페이지를 태그하지 마십시오. 이는 시간이 끝날 때까지 끝없는 복귀 전쟁을 요구하는 것입니다. 머리폭탄 ταλκκοντριβς{ – WP Physics} 2009년 3월 30일 01:24 (UTC)응답하라[응답하라]
  20. 반대: 지적된 전문가는 로그인한 사람에게만 혜택을 줍니다. 기록되지 않았거나 등록된 사용자가 아닌 사용자의 경우 다양한 형식의 날짜를 볼 수 있습니다. 자동 형식은 일관성을 촉진하지 않습니다. 실제 텍스트는 여전히 일관성이 없습니다(그리고 지적된 바와 같이 로그인하지 않은 사람들에게는 분명합니다). 자동 형식이 없으면 편집자는 기사의 날짜 형식에서 일관성 오류를 쉽게 발견할 수 있습니다. Japalang (talk) 2009년 3월 30일 (UTC) 01:46 (추가 기능) : "익명 사용자를 위해 자동 포맷을 수정할 수 있다"는 이유로 반대해온 사용자들에게 Sapphic 방송에 대응하여 추가된 내용입니다.[1][2] 여전히 아무것도 해결되지 않고 있습니다. 첫째, 아직 실행 가능한 해결책을 제시한 사람이 없습니다(제안된 것에 불과합니다). 둘째, 편집자는 단순히 날짜를 입력하기 위해 더 많은 후프를 뛰어다닐 필요가 없습니다. 반대합니다. Japalang (talk) 2009년 4월 1일 01:19 (UTC)답장[답장]
  21. 반대 - 독자들은 로그인한 편집자가 보는 것과 동일한 것을 보아야 하며, 그렇게 하기 위해 우리는 100만 달러를 뛰어넘을 필요가 없습니다. Ealdgyth - Talk 01:47, 2009년 3월 30일 (UTC)답장[답장]
  22. 반대 자동 형식 시스템은 날짜를 해당 날짜에 대한 기사와 연결합니다. 원래 기사에서 식별된 세부 사항에 대해서는 그렇지 않습니다. 저는 또한 기사에서 파란색의 흐릿한 부분으로 봅니다. 이는 위키링크를 사용하는 신입에게 완전히 혼란을 주는 역할을 할 뿐입니다. 선호하는 날짜에 형식을 보는 것과 관련하여, 특히 기사가 요일-월-년 기준이 우세한 유럽 주제에 관한 것이거나 군사 기사에 관한 것인 경우 청중을 위해 기사를 작성하는 것이 좋습니다. 다시 말하지만, 이것은 해결해야 할 문제를 찾는 해결책입니다. FWiW Bzuk (talk) 01:59, 30 March 2009 (UTC).회답[회답]
  23. 반대: 소수의 편집자에게 유리하도록 수백만 개의 기사를 표시하는 것은 노력할 가치가 전혀 없습니다.SteveB67 (talk) 2009년 3월 30일 02:07 (UTC)답장[답장]
  24. 줄리안콜튼Talk 2009년 3월 30일 (UTC) 02:13 답변[답변]
  25. 반대: 많은 이유가 있습니다. 비용은 끔찍하고 혜택은 거의 없습니다. (솔직히 말해서, 아무것도 아닙니다.); 일이 엉망이 되거나 우리가 매우 냄새 나는 강아지를 안고 있게 될 위험이 높습니다. 단순함이 최선이라는 기본 원칙을 깨뜨렸습니다(가능하다면, 지금이 현실입니다.). 저는 WP 사람들이 조심스러운 행동을 해서 이것을 영원히 버리기를 바랍니다. Tony (talk) 2009년 3월 30일 03:31 (UTC)답장[답장]
  26. 반대: 너무 많은 원숭이 비즈니스. 날짜는 기사 전체에 일관된 형식으로 입력해야 하며, 로그인한 편집자는 로그인하지 않은 독자가 보는 것과 동일한 것을 보아야 합니다. (talk) 2009년 3월 30일 04:21 (UTC)답장[답장]
  27. 반대. 이것은 철자 자동 서식({{#formatword color}})보다 우선순위가 낮은 것 같고, 편집 상자를 읽기 어렵게 만듭니다. --Srleffler (talk) 04:42, 2009년 3월 30일 (UTC)답장[답장]
  28. 반대크리스! 2009년 3월 30일 (UTC) 05:01 답변[답변]
  29. 반대합니다, 피더슨은 오히려 잘 표현합니다. Fut.Perf. 2009년 3월 30일 05:58 (UTC)답장[답장]
  30. 반대 이 문제는 기술적인 문제가 아닌 MoS & 행동과 관련된 것입니다. --KrebMarkt 2009년 3월 30일 (UTC)답변[답변]
  31. 반대 반대 주장은 요점을 완벽하게 요약합니다. 이것은 매우 적은 이득으로 수 많은 편집자들에게 많은 일을 만들어 줄 것입니다. oren0 (talk) 2009년 3월 30일 07:12 (UTC)답장[답장]
  32. 별 실익도 없는 엑스트라 타이핑과 교정 반대 2009년 3월 30일 (UTC) 07:29 (답변)
  33. 반대 반대 주장에 동의합니다. Dougweller (talk) 2009년 3월 30일 08:04 (UTC)답장[답장]
  34. 반대. 몇몇 사람들이 재채기하는 것을 좋아하지 않기 때문에, 자동 포맷은 건강한 사람들의 목 아래로 대량 약물치료를 강요합니다. 라이트마우스 (talk) 2009년 3월 30일 08:09 (UTC)답장[답장]
  35. 사소하고 불필요한 대역폭 확장. 닥터 키어난 (talk) 2009년 3월 30일 (UTC) 08:09 (답장)
  36. 전혀 불필요하게 반대합니다. 다음은 "미국과 영국 사이의 자동 이동"일 수 있습니다. --HJensen, talk 09:03 (UTC)응답하라.
  37. 모든 기사에 모든 날짜를 표시하는 것에 반대합니다(수백만 개) - 단지 사람들이 요일과 월별 중 하나를 선택할 수 있도록? 미치광이! 식민지 크리스 (talk) 2009년 3월 30일 09:19 (UTC)답장[답장]
  38. 반대 솔직히 이것은 아주 적은 이득에 많은 일이라고 생각합니다. dottydot (talk) 2009년 3월 30일 (UTC) 10:03 (답변)
  39. 반대. Tcncv(talk·기여)는 좋게 표현합니다. TKD::{talk} 2009년 3월 30일 11:04 (UTC)답장[답장]
  40. 반대. 매번 같은 질문을 받았을 때와 같은 이유로. 편집자와 개발자에게 추가 작업과 복잡성을 제공하는 동시에 누구에게도 가치가 없는 기능입니다(특히 어쨌든 보지 못할 독자). 편집자들이 이 도구를 사용하면 독자들이 보는 날짜를 볼 수 없기 때문에 위키백과에도 피해가 갈 것입니다. 특정 오류(관문, 형식 일관성)가 수정되지 않은 채로 남겨집니다. --Kotniski (talk) 2009년 3월 30일 (UTC)11:18 (답변)
  41. 반대. 자동 포맷과 링크의 차이점을 이해합니다. 자동 포맷으로 인한 많은 문제를 볼 수 있습니다. MS Word(다른 사람의 기계를 사용할 때 하는 것처럼)에게 욕을 한 사람은 보모 연장에 반대해야 합니다. (Open Office를 사용합니다.) 페리돈 (talk) 2009년 3월 30일 12:34 (UTC)답장[답장]
  42. 반대. 그들은 우스꽝스러워 보이고, 종종 전혀 관련이 없는 페이지로 연결되며 "어려운" 기사의 중요한 링크를 평가절하합니다. 저는 3개의 FA를 기여했고 연결된 날짜를 갖는 것은 전혀 가치가 없다고 봅니다. 위키피디아를 처음 발견했을 때, 저는 문제의 주제에 대한 추가 정보를 찾을 수 있을 것이라고 생각하며 그 바보 같은 연결 날짜들을 클릭했습니다. 다른 분들도 그러셨을 겁니다. Graham Colm 2009년 3월 30일 (UTC) 13:01 답변[답변]
  43. 심각하지 않은 "문제"에 대한 "해결책"이라고 반대하며, 이를 구현하는 것은 위키백과에 또 다른 끝나지 않는 과제를 추가하는 것일 뿐입니다. (새로운 사용자는 날짜를 자동으로 포맷하는 방법을 반드시 알지는 못할 것이기 때문에 계속해서 날짜를 정리해야 할 것입니다.) rʨ나 ɢ / 2009년 3월 30일 (UTC)13:18 (답변)
  44. 최소한의 이익을 위한 추가 작업을 고려할 때 반대합니다. --NE213:37, 2009년 3월 30일 (UTC)답장[답장]
  45. 또 다른 여론조사에서 엄청난 시간 동안 추론을 반복하지 않고 반대합니다(그리고 대부분의 지지 추론이 잘못되었다는 점에 주목하십시오). Sandy Georgia (Talk) 2009년 3월 30일 13:38 (UTC)답장[답장]
  46. 반대. 이 문제에 대한 여론조사는 앞으로 얼마나 더 실시할 예정입니까?에밀 J. 13:40, 2009년 3월 30일 (UTC)답장[답장]
  47. 반대. 가장 중요한 것은 기사의 내부 일관성(언어 문제에서와 같이)이며, 이를 위해 자동 포맷이 필요하지 않습니다. Punkmorten (talk) 2009년 3월 30일 13:43 (UTC)답장[답장]
  48. 반대. 어느 쪽이든 강력하거나 정보에 입각한 의견을 가지고 있지는 않지만, 그 의견은 저를 좋은 의견으로 생각하지 않습니다. 필요 없는 곳에 복잡성을 더하며 문제를 만들고 해결하는 것처럼 보입니다. JBarta (talk) 2009년 3월 30일 13:51 (UTC)답장[답장]
  49. 반대 자동 포맷이 금지된 상태에서, 편집자들은 독자들이 보는 것을 볼 것이고, 따라서 독자들을 위한 콘텐츠를 만드는 것을 더 잘 할 것입니다. 일반 판독기는 로그인되어 있지 않으며 기본 설정이 없습니다. 또한 자동 포맷을 구현하기 위한 두 가지 옵션 모두 문제가 있습니다. 링크를 연결하면 독자의 부가 가치 링크를 숨기는 링크 크루프트가 생성됩니다. 템플릿을 사용하면 새 편집기를 얻는 것이 더 어려워집니다. 이는 단순해야 하는 변경을 위해 그들이 배울 수 있는 하나의 구문이 되기 때문입니다. GR베리 2009년 3월 30일 14:01 (UTC)답장[답장]
  50. 등록된 사용자와 등록되지 않은 사용자 간의 차이를 더욱 증가시키는 모든 것에 반대합니다 - Dumelow (talk) 2009년 3월 30일 (UTC) 14:15 (답변)
  51. 반대할 필요가 없습니다. 저는 두 날짜 형식을 모두 이해하고 영어를 읽을 수 있는 다른 모든 사람들도 이해합니다. 그리고 날짜 형식 중 하나에 익숙하지 않은 경우 파악하는 것은 그리 어렵지 않습니다. Rereagan007 (talk) 2009년 3월 30일 14:49 (UTC)답장[답장]
  52. 반대합니다. 이전에 반대한 적이 있는데 다시 하겠습니다. --SkyWalker (talk) 2009년 3월 30일 (UTC) 14:56 (답변)
  53. 약한 반대 나는 그 혜택이 어떻게 지출된 자원과 맞서는지 보지 못합니다. 위키백과의 내용이 싹트기 전에 어떤 종류의 표준이 있었다면 아마 그럴 것입니다만, 이를 개조하려는 것은 어리석은 일 같습니다. -- 더 레드 오브 둠 2009년 3월 30일 (UTC)14:58 (답변)
  54. 반대 질문의 핵심은 위키백과가 누구를 위한 것인가 하는 것인데, 등록된 편집자의 수가 상대적으로 적은 것인가 아니면 위키백과를 온라인 백과사전으로 사용하는 수백만의 미등록 독자들인가 하는 것입니다. 자동 서식 날짜를 찬성하는 모든 주장은 등록 없이 위키피디아 기사를 읽은 대다수에게는 무관합니다. 등록 및 등록되지 않은 것처럼 보이는 굵은 글씨 및 이탤릭체 텍스트 또는 섹션 헤더와 같은 옵션과 달리 특수 마크업은 등록되지 않은 독자에 대해 "기사 표시를 강화"하지 않으며 "전체 출판물에 걸쳐 일관된 형식"을 달성하는 데 전혀 도움이 되지 않습니다. 실제로 자동 포맷은 등록된 편집자에게만 혜택을 주며, 이를 제거하면 성가시고 혼란스러운 파란색 날짜 강조 표시의 방해를 제거하여 등록되지 않은 뷰어에게 기사를 표시하는 기능이 향상됩니다. JGHowes 2009년 3월talk 30일 15:06 (UTC)답장[답장]
  55. 반대 역사와 같은 일부 분야에서는 날짜 형식이 정보 내용의 중요한 요소가 될 수 있습니다. 확실히, 자동 포맷의 기회는 자동 포맷의 자동 사용과 같지 않습니다. 그러나 편집자의 신중한 결정이 아닌 다른 것에 의해 내용이 변경될 기회는 백과사전 정보의 정확성과 진정성에 본질적으로 위험해 보입니다. 예를 들어, 특정 플래그가 일부 기사의 위키텍스트에 모두 입력되어 실제로 '온' 상태가 된 경우, 날짜 형식이 이 기사에서 본질적으로 중요하지 않다는 편집자의 의식적인 결정을 반영하기 위해 자동 형식이 조건부로만 작동하는 경우에는 다를 수 있습니다. Terry0051 (talk) 2009년 3월 30일 15:09 (UTC)답장[답장]
  56. 반대합니다. 언급한 바와 같이 형식에 관계없이 이러한 날짜를 인식하고 이해하는 데 문제가 없기 때문에 이러한 노력은 가치가 없습니다. 단어가 - 또는 - 또는 -our로 일관되게 끝나거나, -iz 또는 -is로 일관되게 끝나거나(사용법이 다른 단어에서는!), 일련의 쉼표가 나타나거나 나타나지 않거나, 기본 인용문이 선호도에 따라 단일 또는 이중 따옴표로 구분되도록 특수 마크업이 필요하지 않습니다. —Largo Plazo (talk) 2009년 3월 30일 15:08 (UTC)답장[답장]
  57. 반대. 위키피디아는 독자와 편집자 중 누구를 위한 것입니까? 대다수의 사용자는 편집을 하지 않으며 등록되지 않습니다. 또한 등록되지 않은 사용자의 관점에서 자동 포맷은 편집자가 해당 기사에서 일반적으로 날짜가 포맷되는 방식에 관계없이 날짜를 포맷하도록 권장하기 때문에 기사를 더 나쁘게 만드는 것이 아니라 더 나쁘게 만듭니다. WP의 단순한 확장:ENGVAR가 문제를 해결합니다. Pfainuk talk 2009년 3월 30일 15:22 (UTC)답장[답장]
  58. 날짜(또는 페이지)에 특수 구문이 있어야 하는 자동 서식 유형에 반대합니다. 이는 신규/경험이 없는 편집자에게는 진입 장벽이며, 등록된 사용자에게 제공되는 무시할 수 있는 이점으로 인해 정당화되지 않는 것으로 보입니다. 3월 2일과 3월 2일이 같은 날짜라는 것을 이해하지 못한 편집자들이 많다면 놀랄 것입니다. 또한 페이지의 모든 날짜를 자동으로 자동으로 포맷하는 것에 반대합니다. 이는 인용문에 부정적인 영향을 미치므로 원본에서 사용된 형식의 날짜가 있어야 하기 때문입니다. Karanacs (talk) 2009년 3월 30일 15:23 (UTC)답장[답장]
  59. 반대 노력할 가치가 없습니다. Alan16 15:53, 2009년 3월 30일 (UTC)답장[답장]
  60. 반대 <사이> 라이언 P를 비롯한 모든 분들이 이 일을 계속해서 시민적인 방식으로 진행하려고 노력하신 것을 축하드립니다만, 이 주제는 정말 지겹습니다. 자동 포맷은 아무런 이점도 없고 단점도 있습니다. --Deller (talk) 2009년 3월 30일 (UTC) 15:57 (답변)
  61. 반대 --JBC3 (대화) 2009년 3월 30일 (UTC) 16:04 (답변)
  62. 반대 노력할 가치가 없으며 위키 소스의 가독성을 저하시킵니다. 플라스틱 포크 (talk) 2009년 3월 30일 16:20 (UTC)답장[답장]
  63. 반대, 대부분의 사용자들에게는 너무 복잡하며, 대다수의 독자들에게는 이득이 없습니다. --레이저 두뇌 (토크) 2009년 3월 30일 (UTC) 16:21 (답변)
  64. 반대합니다. 저는 솔직히 요점을 이해하지 못합니다. 날짜는 있는 그대로 읽을 수 있는 것 이상입니다. 최소한의 이익을 위해 추가 작업을 하는 것입니다. 포럼에 대한 관심을 볼 수 있지만, 위키백과는 그 스타일을 그대로 둬야 한다고 생각합니다. Greggers 2009년 3월 30일 (UTC) 16:23 답변[답변]
  65. 반대하는 맨더슨 의원은 제 견해를 정확하게 정리합니다. --RexxS (토크) 2009년 3월 30일 (UTC) 16:37 답변[답변]
  66. 반대로, 이것은 매우 적은 이익으로 더 많은 일과 문제를 만들고 있는 것 같습니다. 인지된 문제를 해결하는 데 도움을 줄 수 있는 놀라운 프로그래머가 있습니다. 독자들은 더 좋은 기사를 쓸 자격이 있고 우리는 이 문제에 대한 토론과 프로젝트 전반에 걸쳐 많은 에너지를 쏟아 부었습니다. -- 반제보이 2009년 3월 30일 (UTC) 16:50 답변[답변]
  67. 반대: 다른 사람들, 즉 Pfainuk, Greg L, Largo Plazo, GRBerry가 잘 말했습니다. WP의 확장판:ENGVAR는 날짜 형식의 문제에 적용할 수 있으며, 편집자가 로컬 형식만 준수하도록 권장하는 것이 훨씬 좋습니다. 우리는 다양한 변형을 인식하는 데 문제가 없으며 직렬 쉼표를 자동 형식으로 지정하거나 영어에 숨어 있는 다른 수많은 변형을 인식할 수 있습니다. 저는 콘텐츠를 완벽하게 만들고 내부적으로 일관된 기사를 갖는 데 집중하는 대신 편집자만의 선호도를 만들기 위해 많은 작업을 하는 것에 투표합니다. 어쨌든 절반은 절대 "켜지" 않을 것입니다. Maedin\talk 16:56, 2009년 3월 30일 (UTC)답장[답장]
  68. 반대는 KISS 원칙을 위반하고 또한 자동 포맷은 그러한 사소한 측면에서 과도한 접근 방식입니다. 모든 독자들이 MD와 DM을 완벽히 이해하고 있어요. 아이가 MD/DM 날짜를 보고 "그게 무슨 뜻이야"라고 말하는 것을 본 적이 있나요? 커뮤니티의 너무 많은 시간이 이미 이 문제에 사용되었습니다. 우리 모두는 위키백과에 기여/개선할 더 나은 것들을 가지고 있습니다. Sillyfolkboy (talk) 2009년 3월 30일 17:06 (UTC)답장[답장]
  69. 반대 기사 내에서 날짜가 일치하는 한 cf. 다른 국제적인 변형은 문제가 없습니다. Orange Dog (talk 편집) 2009년 3월 30일 17:19 (UTC)답장[답장]
  70. 아무것도 아닌 일로 화내는 사람들에게 불필요한 양보. --Scott Mac (Doc) 2009년 3월 30일 (UTC) 17:28 (답변)
  71. 자동 포맷에 반대합니다. 중요하지 않고 문제가 발생하기 쉽습니다. 저는 또한 이 문제의 더 이상의 반복-죽기를 거부하는 것에 반대합니다. "잃어버린" 편집자들은 어른처럼 행동하기 시작해야 하고, 공동체의 공감대가 자신들에게 불리하다는 사실을 받아들여야 합니다. What am I doing (talk) 2009년 3월 30일 17:30 (UTC)응답하라[답변]
  72. 상충되는 반대 편집 먼저 개발자의 모든 것을 알고 있는 속성을 지적합니다(링크 참조). 이는 이해할 수 있습니다. 저는 그렇게 할 필요가 없으며 우리가 WP에서 필요한 것보다 일을 더 어렵게 만드는 경향이 있다는 Brion의 의견에 동의합니다. 저는 장점을 보지만, 단점이 장점보다 확실히 더 많습니다. hmwith τ 17:33, 2009년 3월 30일 (UTC)답장[답장]
  73. 반대합니다. 오토포맷과 오토링크를 분리하는 것은 어렵다고 생각합니다. 현재 링크를 만들거나 파서 기능을 사용해야 합니다. 전자는 기사를 볼 때 주의를 산만하게 하고 후자는 기사를 편집할 때 주의를 산만하게 합니다. 그 기능은 번거로울 가치가 없다고 생각합니다. 결과적으로 단순한 위키텍스트 구문은 코드를 (약간) 덜 복잡하게 만들어서 새로운 편집자와 성능에 도움이 될 것입니다. Rupert Millard (Talk) 2009년 3월 30일 17:37 (UTC)답장[답장]
    분명히 이것은 사용자에게 충분히 명확하지 않았습니다.사픽이 맛. 다른 것 없이 하나를 갖는 것이 기술적으로 어렵다는 것을 의미하는 것은 아닙니다. 왜냐하면 그것은 터무니 없기 때문입니다. WP가 자동 포맷을 할 수 있는 유일한 방법이 [] 구문(자동 링크 여부) 또는 {{#formatdate}}인 경우, 결과적으로 보기 흉한/해키한 위키텍스트는 IMO가 너무 커서 아주 작은 이점을 누릴 수 없습니다. 이제 <<2009-04-01>>과 같은 새로운 구문으로 자동 포맷에 대해 묻고 싶은 사람이 있다면, 어디선가 본 것처럼 IP 사용자가 자신의 위치에 맞추든 맞추든 아니든 눈에 쉬운 것을 보는 한 저는 중립적일 것입니다. 루퍼트 밀라드 (Talk) 2009년 4월 2일 08:32 (UTC)답장[답장]
  74. 다른 사람과 반대합니다. AE talk/sign 2009년 3월 30일 18:44 (UTC)답장[답장]
  75. 반대. 국제적인 다양성을 수용하는 것이 사용자 선호도를 사용하여 다양성을 무시하는 것보다 낫습니다. 책장에서 보는 것처럼 차이점을 보는 것에 익숙해져야 합니다. 그것이 학습 경험의 일부입니다.
    ⋙–베레안Hunter (() 2009년 3월 30일 (UTC) 18:49 답변[답변]
  76. 반대. 자동 포맷은, 제대로 작동하도록 만들 수 있다고 하더라도, 매우 적은 이점을 제공하지만, 다른 사람들이 위에서 주목했듯이, 매우 중대한 단점을 가지고 있습니다. --Malleus Fatuorum 2009년 3월 30일 (UTC)응답하라[답변]
  77. 반대. 라이프피 (talk) 2009년 3월 30일 19:24 (UTC)답장[답장]
  78. 반대, 문제 없는 해결.육각형(!❞) 2009년 3월 30일 19:32 (UTC)답장[답장]
  79. 반대... 항상 그랬고 앞으로도 계속될 21세기 GREENSTUFF 2009년 3월 30일 20:01 (UTC)응답하라[답변]
  80. 반대. 소수를 위한 사소한 이익을 위해 모두를 위한 많은 추가 작업. 백과사전 개선으로 돌아가 보겠습니다.점을 기억하세요, 2009년 3월 30일 (UTC)응답하라[답변]
  81. 반대 알로하소이 (talk) 2009년 3월 30일 20:10 (UTC)응답하라[답변]
  82. 반대 날짜 형식에 문제가 있는 일부 사용자의 가독성이 약간 향상되는 것은 백과사전의 모든 곳에서 날짜를 형식화하는 노력을 기울일 가치가 없습니다. 미국인도 DD/MM/YYYY 읽는 법을 배울 수 있습니다. KellenT 2009년 3월 30일 20:14 (UTC)응답하라[답변]
    저는 분명히 위의 논평에서 농담을 하는 것입니다; 저는 미국인입니다. 켈렌T 2009년 4월 1일 09:25 (UTC)답글[답글]
  83. 반대합니다. 저는 정말로 이렇게 해야 할 명확한 이유를 알 수 없습니다. 그것은 단지 그렇게 큰 문제가 아닙니다. 모든 사람들에게 적용된다면, 아마도, 단지 로그인한 사용자들에게만... 아니요. Anaxial (talk) 2009년 3월 30일 20:38 (UTC)답장[답장]
    분명히 말씀드리지만, 이것이 모든 사람에게 적용될 수 있다는 사실은 제가 반대하는 것보다 덜 강력하게 반대한다는 것을 의미합니다. 하지만 그것이 제 실제 투표를 바꾸지는 않습니다. 왜냐하면 위에 제 첫 문장은 여전히 유효하기 때문입니다. Anaxial (talk) 2009년 4월 1일 17:32 (UTC)답장[답장]
  84. 반대 각 기사에 일관된 형식으로 날짜를 입력하는 한 실질적인 문제는 없습니다. WP:ENGVAR는 영어 버전에 잘 적용되며 날짜는 이를 확장해야 합니다. CS46 2009년 3월 30일 (UTC) 21:06 답변[답변]
  85. 자동 서식은 등록된 편집자인 소수의 독자에게만 적용되므로 반대합니다. 는 모든 독자를 위해 주어진 형식을 개별 기사(인용 날짜 등 제외)에 적용할 수 있는 기술적인 자동 형식화 솔루션을 지지하지만, 여기서 논의되는 것은 아닌 것 같습니다.Josiah Rowe (talk 기고) 2009년 3월 30일 21:12 (UTC)답장[답장]
  86. 형식의 차이 때문에 모든 사람을 만족시킬 수는 없습니다. 우리가 철자법과 마찬가지로 미국 기사도 1957년 5월 9일 형식을 유지할 수 있어야 한다고 생각합니다. 영국, 호주 및 기타 미국 외부 기사도 1957년 5월 9일 형식을 사용할 수 있어야 합니다. 기본 설정을 할 수 있거나 할 수 있다면 이 문제가 문제가 되지 않는 경우 지원하겠습니다.Ched ~ ©/ 2009년 3월 30일 (UTC) 21:18 답변[답변]
  87. 반대 여기서 해결할 문제는 없으며 이는 더 많은 문제를 발생시킬 것입니다 - Hunt (talk) 2009년 3월 30일 (UTC) 22:05 답변[답변]
  88. 반대할 이유가 없다고 봅니다. 불필요하게 복잡한 일은 차치하고, 이것이 어떤 결과를 가져올지 알 수가 없습니다. 믿음이 없습니다.speak ( ) 2009년 3월 30일 (UTC) 22:19 답변[답변]
  89. 반대. 큰 이익 없이 바쁜 일만. Wildhartlivie (talk) 2009년 3월 30일 (UTC) 22:33 답변[답변]
  90. 반대 - 어, 또 다른 RFC? 우리는 이 일을 몇 번이나 겪을 것인가요? --PresN 23:43, 2009년 3월 30일 (UTC)응답하라[답변]
  91. 반대. 허용되는 두 형식을 이해하는 데 모호함이 없습니다. 순수하게 미용적인 문제를 위해 많은 노력을 기울였습니다. 지역별 맞춤법 차이와 동일한 문제이므로 동일하게 취급해야 합니다. --NrDg 00:02, 2009년 3월 31일 (UTC)답장[답장]
  92. 반대 - 일반 독자들이 환경설정이 설정된 로그인 사용자 몇 명과 다른 것을 보아야 할 이유는 없습니다. Giants2008 (17-14) 00:12, 2009년 3월 31일 (UTC)답장[답장]
  93. 반대, 링크가 유용한 곳으로 가지 않으므로 목적에 맞는 링크를 제공하지 않으며, 모든 곳에 과도한 파란색 링크를 추가합니다(기본적으로 날짜가 여러 번 반복되므로 자동으로 "오버링크" 기사). 또한 기사에서 날짜를 포맷하는 목적을 부정하고, 기사에서 한 가지를 보고 편집하기로 결정하고 완전히 다른 것을 보는 IP 및 새로운 사용자에게 혼란을 줄 수 있습니다. 텍스트로 작성해서 남겨주세요. -- Collectonian (talk·기여) 2009년 3월 31일 (UTC) 01:55 (답변)
  94. 반대. 자동 포맷은 문제를 찾는 "해결책"입니다. 현재 WP에서 사용되는 모든 날짜 형식을 해결할 수 없기 때문에 좋은 해결책도 아니며, 토론 중에 제기된 모든 문제에 대해 기술적 해결책을 찾을 수 있다는 징후도 없습니다. 기술적인 해결책이 구현되면, 그 구문은 일반 편집자의 손이 닿지 않을 정도로 충분히 복잡해질 것을 약속합니다. 날짜 일관성 "문제"에 대한 진정한 해결책은 단순한 텍스트를 사용하여 일관된 방식으로 날짜를 입력하는 것입니다. "플레인 텍스트" 전략을 사용하면 다른 모든 중요한 문제가 사라집니다. HWV25802:07, 2009년 3월 31일 (UTC)답장[답장]
  95. 반대. 컴퓨터 소프트웨어는 가능한 한 단순해야 합니다. 일단 당신이 그것을 복잡하게 만들기 시작하면 당신은 항상 문제에 빠집니다. VikSol 02:32, 2009년 3월 31일 (UTC)답장[답장]
  96. 자동 서식 지정을 반대합니다. 굳이 이 문제를 해결해야 할 이유가 없습니다. Hmains (talk) 2009년 3월 31일 03:01 (UTC)답장[답장]
  97. 자동 포맷을 반대합니다. 이것은 해결해야 할 문제가 부족한 기술적인 해결책입니다. Tempshill (talk) 2009년 3월 31일 03:04 (UTC)답장[답장]
  98. 반대: 문제를 찾는 해결책처럼 보입니다. 마크업을 더 복잡하게 만들고 새로운 사용자를 위협한다는 측면에서 상당한 벌칙이 있습니다. 단순하게 받아들여라. Hawthorn (talk) 2009년 3월 31일 03:09 (UTC)답장[답장]
  99. 반대. 제 날짜가 어떤 식으로든 포맷되어 있어도 상관없습니다. 색깔 대 색깔 같은 거. 두 가지를 모두 읽고 이해할 수 있습니다. 레인보우 오브 라이트 2009년 3월 31일 03:22 (UTC)답장[답장]
  100. "누구나 편집할 수 있는 백과사전 위키피디아에 오신 것을 환영합니다." 제가 위키백과에서 항상 좋아했던 것은 여러분이 기여하기 위해 배워야 하는 가장 큰 것이 위키링크를 만드는 방법이라는 것입니다. 날짜와 같은 기본 정보는 그보다 더 복잡한 형식을 요구하지 않습니다. 위키백과는 새로운 사용자와 오래된 사용자 모두를 억제하는 문화를 발전시켰으며, 그러한 배제 문화와 일치하도록 사이트를 코드화할 필요가 없습니다. otherleftNo, really, other way . . . 03:33, 2009년 3월 31일 (UTC)답변[답변]
  101. 반대 자동 서식 날짜 연결은 합리적인 목적을 달성하지 못했고 작성자와 편집자의 시간을 낭비했습니다. 반품하고 싶지 않습니다. Finetooth (talk) 2009년 3월 31일 03:47 (UTC)답장[답장]
  102. 소위 자동 포맷에 반대합니다. 모든 기사 뒤에 있는 원본 텍스트를 편집하는 것은 정말 불필요하고 너무 복잡합니다. 너무 많은 마크업은 모든 사람을 위협합니다. 음, 를 위협합니다. 진심으로 모두에게 친구 George Louis (talk) 2009년 3월 31일 (UTC) 05:03 답변[답변]
  103. 단순히 너무 사소한 것에 반대하여 편집자나 개발자의 시간이나 키 스트로크를 사용할 가치가 없습니다. 어떤 형식이든 고정된 텍스트 날짜는 독자들에게도 똑같이 유용합니다. --Clay Collier (talk) 2009년 3월 31일 (UTC)05:05 (답변)
  104. 반대 계정을 등록하지 않는 모든 독자/편집자가 날짜 형식을 설정하지 않았다고 가정하는 것이 잘못된 경우 수정하십시오. 그 유용성은 너무나 피상적이어서 그것을 사용하는 소수를 고려할 때 실제로는 유용하지 않게 됩니다. 처음에 매스 디링크가 시작되었을 때는 다른 사람들처럼 변화를 싫어한다고 해서 굉장히 반대했는데, 조금만 생각해보니 지금은 좋은 생각인 것 같습니다. Lonely Marble (talk) 2009년 3월 31일 06:34 (UTC)답장[답장]
  105. 반대 위키텍스트 마크업에 복잡성이 더해지면 누구나 편집할 수 있는 백과사전인 척 하기가 더 어려워집니다. Ian Spackman (talk) 2009년 3월 31일 07:18 (UTC)답장[답장]
  106. 반대: 이것으로 해결되는 문제는 없습니다. 날짜가 특정 형식이어야 하는 경우 영국 대 영국과 유사하게 취급할 수 있습니다. 미국 영어: 합리적인 경우에는 주어진 형식을 사용해야 합니다. NJGW (talk) 2009년 3월 31일 07:54 (UTC)답장[답장]
  107. 약한 반대: 중요한 문제라고 생각한다면 더 강력하게 반대하겠지만, 백과사전의 모든 날짜(사인 포함)가 일치하지 않고, 애초에 모든 종류의 날짜를 허용할 수 있다면 자동 포맷을 제공해야 한다고 생각하지 않습니다. 하지만, 이것은 조금 문제가 되지 않습니다. 가능하다면 MOS에서 인정된 스타일에 동의하는 것이 좋을 것 같습니다. - 워먼 я로우 2009년 3월 31일 (UTC)응답하라[답변]
  108. 반대 우리는 페이지에 링크가 덜 필요합니다. 연결된 날짜는 파란색으로 페이지가 막혀 가독성이 떨어집니다. 또한 페이지를 덜 전문적으로 보이게 만듭니다. 우리는 미국과 영국의 철자를 '변환'할 수 있는 연결된 자동 서식 시스템을 가지고 있지 않은데, 왜 우리는 완전히 상호 이해할 수 있는 데이트 시스템을 가지고 있어야 합니까? 자동 포맷은 수년간 위키피디아의 제약 조건이었으며, 가능한 한 빨리 삭제되어야 합니다. Arsenikk 2009년 3월 31일 08:07 (UTC)답장[답장]
  109. 자동 서식 반대는 등록되지 않은 사용자에게는 보이지 않지만 날짜 링크는 볼 수 있으며, 오버링크의 전형적인 경우처럼 보입니다. 사실 저는 몇 년 동안 자동 포맷 기능에 대해 알지도 못했고 이러한 불필요한 링크에 계속 짜증이 났습니다. "버락 오바마하와이에서 태어났다"에서 "태어났다"는 말을 여러분이 연결시키지 않으시려는 것처럼, 그들은 아직도 제게 전문가답지 않은 처럼 보입니다. --즈비카 (토크) 08:54, 2009년 3월 31일 (UTC) 사픽의 논평에 대해 다음과 같이 덧붙였습니다. 저의 주된 반대는 링크에 대한 것이지만, 링크로 나타나지 않는 자동 포맷에 대해서도 반대합니다. 이는 주로 이런 종류의 접근 방식에서 불가피한 것으로 보이는 위키마크의 복잡성 때문입니다. 우리의 마크업은 그 반대가 아니라 단순화가 필요합니다. 어쩌면 언젠가 위지위그 편집자가 생겨날지도 모릅니다. --Zvika (talk) 2009년 4월 1일 (UTC) 13:36 답변[답변]
  110. 반대 글에 파란색 링크가 너무 많이 생성될 수 있습니다. --JD554 (토크) 2009년 3월 31일 (UTC)11:35 (답변)
  111. 오버링크 문제를 제외하고, 이것은 모두를 위한 하나의 버전의 기사를 생산하는 하나의 백과사전 프로젝트입니다. 다음으로 사용자가 미국/영국 영어를 전환할 수 있도록 허용하는 것은 무엇입니까? 비록 그러한 맞춤 제작이 바람직했다고 하더라도, 그것은 확실히 노력과 복잡함의 가치가 없습니다. Sandstein 2009년 3월 31일 11:44 (UTC)답장[답장]
  112. 예! 날짜 형식에 대한 옵션이 바로 제가 기사를 쓰는 데 주의를 산만하게 하는 것을 보고 싶습니다. 해결할 문제 없습니다, 그냥 두세요.Cyclonenim (talk·기여·이메일) 2009년 3월 31일 11:54 (UTC)답장[답장]
  113. 반대 날짜의 형식은 철자법이나 문법과 같은 ENGVAR 문제입니다. 기사는 이 모든 것을 자기 일관성 있게 작성해야 합니다. 콜린°Talk 12:33, 2009년 3월 31일 (UTC)답장[답장]
  114. 반대 2009년 3월 31일 (UTC) SpitfireTally-ho! 12:54, 31일 (UTC) 답변 [답변] 완벽하게 멀쩡한 것을 고치려고 노력함으로써 해결할 문제는 없습니다. 예를 들어 오버링크, 개발 문제 등 더 많은 문제를 발생시킬 것입니다.
  115. 반대 --Apoc2400 (대화) 2009년 3월 31일 (UTC) 15:00 (답변)
  116. 반대 지난 여름 자동 포맷이 중단되었을 때 크게 안도했습니다. 대부분의 사용자에게 이러한 링크는 과도하고 무의미한 링크이며 거의 이점이 없습니다. 사용된 형식이 "Day Month"인지 "Month Day"인지 모든 사람이 의미를 이해합니다. 개별 기사 내에서 일관성을 유지하기만 하면 해결할 문제가 없습니다. --Jackyd101 (talk) 2009년 3월 31일 (UTC)16:00 (답변)
  117. 반대. 우리가 무언가를 할 수 있다고 해서 해야 한다거나 해야 한다는 뜻은 아닙니다. 기사의 날짜 형식은 중요한 문제가 아닙니다. 위키백과:Manual_of_Style_(날짜_및_숫자)#날짜는 상황을 충분히 잘 커버합니다. 사람들은 1956년 11월 17일과 11월 17일을 보는 것에 꽤 익숙합니다. 그리고 이것들은 문제를 일으키지 않습니다. 두 가지 버전 모두 독자들이 이해할 수 있으며, 대부분의 사람들은 일상 생활에서 두 가지 버전을 접하며 두 가지 버전을 모두 사용할 것입니다. 존재하지도 않는 문제를 해결하기 위해 대부분의 편집자에게 작품을 만드는 것은 완전히 부적절해 보입니다. 이 문제에 대한 마지막 여론조사이기를 바랍니다. 6개월 안에 4번 여론조사를 하는 것은 다소 무리입니다. 그때마다 이것이 필요하지 않고 원하지 않는다는 합의가 이루어집니다. 투표는 이미 그만 하세요! 실크토크 YES!* 2009년 3월 31일 16:20 (UTC)답장[답장]
  118. 모든 기사에 모든 날짜를 표시하는 것에 반대합니다(수백만 개) - 단지 사람들이 요일과 월별 중 하나를 선택할 수 있도록? 미치광이! WAS 4.250 (talk) 2009년 3월 31일 16:26 (UTC)응답하라[답변]
  119. 에 반대하는 것은 문제를 찾는 해결책인 것 같습니다. 제가 생각하기에 사람들이 잊고 있는 것은 우리 독자의 대다수가 등록되지 않은 상태라는 것입니다. 이것이 가장 큰 혜택을 제공해야 하는 사람들은 그것이 일어나고 있는지조차 알지 못할 것입니다. 그대로 두고, WP:ENGVAR 타입의 솔루션이 알아서 처리해 줍니다. Parsecboy (talk) 2009년 3월 31일 16:30 (UTC)답장[답장]
  120. 반대. 나는 해결해야 할 문제가 없다는 말에 가장 설득됩니다. "메타데이터" 논쟁을 우려했는데, "반대 성명서"의 메타데이터 오류 부분에서 위에서 제대로 답하고 있다고 생각합니다.Dominus (talk) 2009년 3월 31일 (UTC) 16:32 답변[답변]
  121. 반대합니다. 해결할 문제는 없습니다. 로그인하지 않은 독자에게는 절대 효과가 없을 것으로 생각하기 때문에 그럴 가치가 없습니다. 모든 문법적 상황에서는 절대 통하지 않을 것입니다. --Jc3s5h (talk) 2009년 3월 31일 (UTC)응답하라[답변]
  122. 반대합니다. 고칠 문제는 없습니다. 날짜 메타 데이터를 처리하는 다른 방법도 있습니다. Gwen Gale (talk) 2009년 3월 31일 16:38 (UTC)응답하라[답변]
  123. 반대 이것은 문제가 없는 약한 해결책입니다. 어쨌든 대부분의 독자들은 로그인조차 하지 않습니다. Richard75 (talk) 2009년 3월 31일 17:22 (UTC)응답하라[답변]
  124. 반대합니다. 저는 Richard 75의 의견에 동의합니다. 저는 이것이 새로운 편집자들을 미루고 다른 편집자들로 하여금 아주 작은 효과로 작은 편집을 하도록 만드는 것 외에는 많은 것을 이룰 수 없다고 생각합니다. Ricardiana (talk) 2009년 3월 31일 17:29 (UTC)답장[답장]
  125. 반대. 대부분의 독자는 로그인되어 있지 않으며 다른 날짜 형식은 어쨌든 이해하기 쉽습니다. 또한 기사에서 푸른 바다를 줄이는 것은 무엇이든 환영합니다. 이것은 문제를 찾는 해결책입니다. SlimVirgin 2009년 3월 31일 17:30 (UTC)답장[답장]
  126. 반대. 반대 성명서가 말하는 것 - 특히 해결해야 할 문제는 없습니다. 게다가 이 솔루션은 새로운 편집자에게 매우 어렵고 오류가 발생할 가능성이 있습니다. David Brooks (talk) 2009년 3월 31일 17:40 (UTC)응답하라[답변]
  127. 반대좌파당 2009년 3월 31일 (UTC) 18:03 답변[답변]
  128. 반대 - 존재하지 않는 문제를 해결하는 것뿐입니다. 저희는 해결해야 할 실제 문제와 확장해야 할 기사가 많습니다. 횡설수설하는 남자 (talk) 2009년 3월 31일 18:10 (UTC)응답하라[응답하라]
  129. Steve Crossin에 따르면 --Nemobis (talk) 2009년 3월 31일 18:12 (UTC)응답하라[답변]
  130. 반대 - 문제를 찾는 해결책일 뿐만 아니라 두더지 언덕으로 산을 만드는 것 같습니다. 일반적으로 저는 단순 텍스트와 같은 기본적인 것에 추가적인 복잡성(코드) 계층을 추가하는 것에 반대합니다. 이는 새로운 사용자를 소외시키고 편집에 있어서 기술적인 실패로 이어집니다. "2009년 3월 31일"과 "2009년 3월 31일"은 동일한 의미로, 어느 형식에서도 동일한 의미를 도출하기 위해 자동 포맷이 필요하지 않습니다. --IllaZilla (talk) 2009년 3월 31일 (UTC)응답하라[답변]
  131. 몇 가지 코멘트: 템플릿:날짜는 이 토론에 흥미로운 추가 사항이며, 이에 대해 길고 열심히 생각하게 만들었습니다. 저는 이 스레드에서 수십 개의 댓글을 읽었고, 반대하는 많은 사람들이 이 하위 여론조사가 '연결'에 관한 것이라는 잘못된 생각을 가지고 있는 것 같다는데 동의합니다. 저는 블루 링크 없이 메타 데이터를 얻는 아이디어를 강력하게 지지합니다. 그러나 자동 포맷에 대해 갈등을 겪고 있습니다. 부분적으로는 mdy가 기본값인지 dmy가 기본값인지 누가 결정하기 때문이며, 부분적으로는 가능하면 더 많은 위키코드 복잡성을 피해야 하기 때문입니다. 저는 (현재) 우리 데이트의 스타일링/포맷이 (세계는 다양하고, 우리는 현재 이를 반영하고 있기 때문에) 우리의 FA들처럼 독일어-위키(데이트가 연결되지 않음)처럼, 그리고 독자나 편집자에게 전혀 영향을 주지 않는 메타데이터 추출을 위한 대안적인 기술적 해결책을 찾아야 한다고 생각합니다. 그래서, 약한 사람이 반대하는 것 같아요. 그러나 다른 해결책을 개발할 수 없다면 "자동화된 타임라인" 생성의 매력은 앞으로 저를 재고하게 만들기에 충분합니다. 거기에 사용 가능한 데모가 있습니까? -- Quiddity (talk) 2009년 3월 31일 (UTC) 19:05 답변[답변]
  132. 반대 - 메타데이터가 중요하지만, 이 방법은 아닙니다. 문제를 찾는 해결책.Quadell 2009년 3월 31일 (UTC) 19:39 답변[답변]
  133. 반대. 수천 명(수백만 명)의 인력과 서버 리소스를 희생시키면서 수천 명의 사용자에게 혜택을 주었습니다. 자동포맷은 간단히 말하면 coo banas입니다. --- RockMFR 2009년 3월 31일 (UTC)응답하라[답변]
  134. 반대. 그것은 우리에게 수천 개의 링크를 싣는 아주 작은 세부 사항입니다. 게다가, 저는 우리가 미국 맞춤법으로 작성할 것을 요구하고 날짜 자동 형식을 허용하는 것이 이상하다고 생각합니다. 날짜 형식은 철자와 함께 적용되어야 합니다. -- Magioladitis (talk) 2009년 3월 31일 (UTC) 19:52 답변[답변]
  135. 반대합니다. --Du Lithgo (talk) 2009년 3월 31일 (UTC) 21:01 (답변)
  136. 반대. 자동 형식을 위해 날짜 연결을 중지해야 합니다. 날짜를 자동으로 포맷하는 다른 덜 거슬리는 방법이 있을 수 있습니다.Xavier, 2009년 3월 31일 (UTC) 21:29 업데이트, 편집자의 요청에 따라 다음과 같이 설명합니다. 저는 날짜 자동 포맷만을 목적으로 하는 어떤 종류의 마크업에도 반대합니다.Xavier, 2009년 4월 3일 21:10 (UTC)답장[답장]
  137. 반대. 저는 여기서 진정한 선물은 자동 포맷이 "수십 년 동안 운영 체제에서 선택 사항이었다"는 진술이라고 생각합니다. 예, 이것은 사실입니다. 왜냐하면 수십 년 전 대부분의 운영 체제는 날짜를 숫자 형식으로 표시했기 때문입니다. 날짜가 해당 월의 첫 12일에 해당하는지 여부에 대해 진정한 의미가 모호했습니다. 이는 너덜트에서는 해당 달을 스펠링해도 모호성/가독성 문제도 있다는 가정을 하게 된 것으로 보입니다. 우리는 운영 체제를 따를 것이 아니라 실제 정보 소스를 따라야 합니다. 저는 독자들에게 날짜를 어떻게 표시할지에 대한 선택권을 줄 정도로 이에 대해 걱정하는 웹 정보원이나 뉴스 공급자를 본 적이 없습니다. 그래서 우리가 이 문제에 대해 걱정하는 것은 독창적인 연구에 참여하는 것입니다. 미국 밖의 영어권에서는 이런 저런 방식으로 포맷하는 것을 국가적으로 선호하는 것이 없습니다. 그것은 단지 개인적인 스타일이나 개별 출판물의 스타일 가이드의 문제일 뿐입니다. 타임즈는 MMM DD, YYYYY를 사용하지만 가디언은 DDMM YYYYY를 사용하기 때문에 영국의 영어 사용자들이 혼란스러워하고 있습니까? 아니면 인도에서는 힌두교도들이 MMM DD, YYYY, 하지만 타임스 오브 인디아에서 DD MMM YYYYY라고 말하기 때문에? 또는 The Age[7]가 MMM DD, YYYY, 그리고 호주 방송사[8] DD MMM YYYYYY를 사용하는 호주에서? 캐나다: 토론토 스타[9] MMM DD, YYYY, 하지만 캐나다 방송사[10] DD MMM YYYYY? 이러한 웹 사이트나 제가 찾을 수 있는 다른 웹 사이트는 독자들이 날짜를 다른 형식으로 표시할 수 있는 옵션을 제공하지 않지만, 저는 불만의 통곡을 보지 못합니다. 그리고 군대에 가는 미국인들이 어떻게 다른 형식의 날짜에 대해 혼란스러워하는지에 대해 논의하는 신뢰할 만한 자료들은 어디에 있습니까? 날짜 자동 형식은 문제를 기다리는 솔루션의 고전적인 경우입니다. 스타일에 대한 현재의 실용적인 기준을 유지하거나, 한 형식에 대한 선호도가 미국에서만 높은 것처럼 보이기 때문에, 그냥 MMM DD, YYYY라고 전체적으로 말하는 것은 어떨까요? Phil Bridger (talk) 2009년 3월 31일 (UTC) 23:02 답변[답변]
  138. 반대합니다. -- 부가가치가 거의 없고, 시간 낭비가 너무 심합니다. 그라운드 제로 2009년 3월 31일 (UTC) 23:36 답변[답변]
  139. 반대. 날짜 형식을 지정하면 기사에 아무것도 추가되지 않습니다. 우리는 위키링크 날짜를 금지해야 합니다. 이 제안은 다른 방향으로 나아갑니다. SMP0328. (talk) 2009년 4월 1일 00:25 (UTC)답장[답장]
  140. 반대 - 편집자에 관한 한 자동 서식 지정은 날짜 연결만큼 어렵습니다. 제 타이핑 기술을 사용하면 실수를 할 수 있는 또 다른 기회가 될 것입니다. PKLoppel (talk) 2009년 4월 1일 (UTC) 01:10 답변[답변]
  141. 그럴 필요가 없다고 반대하세요. Kablammo (talk) 2009년 4월 1일 01:23 (UTC)답장[답장]
  142. 반대 - 거슬리는, 무의미한. Ceoil (talk) 2009년 4월 1일 01:29 (UTC)답장[답장]
  143. 반대-참, 참. Lil Helpa (talk) 2009년 4월 1일 01:31 (UTC)답장[답장]
  144. 반대—링크는 사용자를 유용한 콘텐츠로 이끌어야 합니다. 날짜 링크는 해당되지 않습니다. -- Silvers (talk) 2009년 4월 1일 (UTC)05:29 답변[답변]
  145. 반대-자동 포맷을 할 필요가 없습니다. 문제는 여기서 보이지 않습니다. --Popiloll (talk) 2009년 4월 1일 (UTC)06:53 답변[답변]
  146. 반대WP 기준:OVERLINK. 관련 없는 링크로 페이지를 어지럽히는 것은 아무런 도움이 되지 않습니다. 제가 처음 사용자였을 때, 저는 종종 관련 정보를 기대하며 이러한 날짜 링크를 클릭했고, 항상 아무 것도 찾지 못해 실망했다는 것을 알고 있습니다. Gatoclass (talk) 2009년 4월 1일 07:28 (UTC)답장[답장]
  147. 반대-위의 앤더슨은 "해결 불가능한 문법적 어려움"을 언급하고 있습니다. 여기 또 다른 것이 있습니다. 8월 7일 결정 변경 형식이라는 문구를 사용하면 8월 7일 결정이 있어야 합니다. {{#형식 날짜:}} 아직 범위를 다룰 수도 없습니다. 우리가 그것이 이 일을 처리할 수 있기를 기대할 수 있습니까? 하지만 이 문제들이 해결되었다고 가정해 보겠습니다. 2187년...) 자동 포맷은 또 다른 병을 초래합니다. 사용자가 선호하는 형식으로 날짜를 표시함으로써 불일치를 방지할 수 있습니다. 그렇지 않으면 이러한 문제를 해결할 수 있는 바로 그 사람들로부터 불일치를 방지할 수 있습니다. 아마도 이를 방지하기 위해 페이지 단위의 기본 시스템을 구현할 수 있을 것입니다. 따라서 WikiMedia의 자동 포맷은 현실적으로 실행 가능한 해결책이 될 때까지 공정하게 진행해야 합니다. 수고할 가치가 있습니까? 스펠링을 보는 것과 반대쪽 날짜 형식을 보는 것 사이에 큰 차이가 있습니까? 날짜 형식은 방언의 한 측면일 뿐입니다. 따라서 ENGVAR 아래로 넘어가거나 적어도 누군가가 이에 대한 실행 가능한 해결책을 제시할 때까지 말입니다. JIMp talk·cont 08:07, 2009년 4월 1일 (UTC)답장[답장]
  148. Donald Knuth의 말에 따르면, "시기상조한 최적화는 모든 악의 근원입니다." 하지만 저는 파이어폭스 플러그인 모양의 스마트 클라이언트 측 날짜 자동 서식 도구에 전적으로 찬성합니다. --dab(𒁳) 08:34, 2009년 4월 1일 (UTC)답장
  149. 반대—편집자가 일반 독자가 보는 것과 다른 날짜 형식을 보는 것은 이점이 아닙니다. 우리 모두는 다양한 형식으로 날짜를 인식하고 이해할 수 있을 만큼 유연합니다.Mattisse (Talk) 2009년 4월 1일 (UTC) 11:43 답변[답변]
  150. 반대. 저는 이것이 문제라는 것도, 혹은 (아마도) 국가별 선호도가 있다는 것도 깨닫지 못한 채 행복하게 평생을 살아왔습니다. 저는 "4월 1일"과 "4월 1일"을 똑같이 쉽게 읽었습니다. 그 차이는 등록조차 되지 않습니다. 다른 많은 분들이 말씀하신 것처럼, 저는 해결할 문제가 없다고 생각하며, 단순히 편집을 더 번거롭고, 암호화되고, 오류가 발생하기 쉽고, 시간이 많이 걸리는 기능을 하는 마크업을 불필요하게 추가하는 것에 반대합니다. 매트 2009년 4월 1일 (UTC) 11:55
  151. 반대합니다. 이 VJ (토크) 2009년 4월 1일 (UTC) 12:42에서 요점 보이지 않습니다.
  152. 반대 - 이득이 별로 없고(이익이 전혀 없나요?), 엄청난 비용이 듭니다. 저는 편집자로서 더 많은 비밀 태그로 가득 찬 페이지 소스를 보고 싶지 않습니다. 저는 1994년부터 지금까지 가끔 데이터베이스의 날짜 처리를 프로그래밍해 온 소프트웨어 엔지니어입니다(유급 주간 업무로서), 저는 날짜 처리가 얼마나 복잡한지 알고 있습니다. 미디어위키 개발자들은 보다 생산적인 문제에 시간을 써야 합니다. 그들은 아직 #time parser 기능을 고칠 시간조차 없었습니다. 그것은 버그를 알고 있었습니다. 하지만 그들은 무엇이 그 벌레들을 유발하는지 모릅니다. 이제 미디어위키에 복잡한 날짜 처리를 추가하시겠습니까? --David Göthberg (talk) 2009년 4월 1일 (UTC) 17:20 답변[답변]
  153. 반대 - 날짜 형식을 지정하면 위키백과 편집이 어려워집니다 :^( Fightin' Phillie (토크) 17:58, 2009년 4월 1일 (UTC)응답하라[답변]
  154. 반대 - 자동 포맷은 복잡성을 더하며 중요한 문제를 해결하지 못합니다. Ed Johnston (talk) 2009년 4월 1일 (UTC) 19:39 답변[답변]
  155. 반대 – 저는 한 번만이라도 승리하는 편이 되고 싶습니다. 브라이언 불턴 (talk) 2009년 4월 1일 (UTC) 23:47 답변[답변]
  156. 반대 - 다음으로 사용자의 선호도에 따라 알루미늄을 알루미늄으로 변경하거나 리프트를 엘리베이터로 변경하는 "자동 스펠 확장"은 무엇입니까? 아무 것도 필요 없는 불필요한 관료주의. SFC9394 (talk) 2009년 4월 2일 00:03 (UTC)답장[답장]
  157. 반대 - 저는 기본적으로 정비를 하는 것이 인력 낭비라고 생각합니다. --Tony The Tiger (t/c/bio/WP:시카고/WP:LOTM) 2009년 4월 2일 00:12 (UTC)답장[답장]
  158. 반대 - 기존의 날짜 형식이 문제가 되지 않는다고 말하는 사람들의 의견에는 동의할 수 없지만, 이익을 위해 너무 많은 일을 합니다. ISO 날짜는 골치 아픈 문제이며 월 12일 이전 날짜의 문제는 실제이므로 편집자가 해결해야 합니다. 하지만 자동 포맷이 해결책이라는 것을 알 수 없습니다. 해밀턴스톤 (talk) 2009년 4월 2일 (UTC) 00:45 답변[답변]
  159. 반대 - 고쳐야 할 실질적인 문제는 없습니다. 대부분의 사람들은 두 가지 형태의 날짜를 모두 이해할 수 있습니다. 본질적으로 실질적인 이익이 거의 없는 것처럼 보입니다. 레전드게이머 2009년 4월 2일 (UTC) 02:11 답변[답변]
  160. 반대 - 정말 그럴 필요가 없어요. 4월 2일이나 4월 2일, 색깔과 색깔의 차이만큼 크게 다르지는 않습니다. 사투리에 따라 단순한 차이. 제가 보기에는 별 문제가 아닙니다. --sable232 (talk) 2009년 4월 2일 (UTC) 02:38 답변[답변]
  161. 날짜를 반대하는 형식은 복잡한 위키텍스트를 제공할 것이며, "4월 1일"에 민감한 사람들이 "1월 1일"을 절대 볼 수 없기를 바랄 수 있는 유일한 이점을 제공할 것입니다. 복잡한 위키텍스트는 기사의 중요한 내용에 집중하는 것을 더 어렵게 만듭니다. 날짜 포맷은 WP 서버에서 무의미한 오버헤드가 될 것이고, 편집자들에게는 하찮은 시간 낭비가 될 것입니다. Joonuniq (talk) 02:39, 2009년 4월 2일 (UTC)답장[답장]
  162. 반대 - 위키텍스트 구문은 새로운 사용자의 기여를 장려하기 위해 가능한 한 단순하게 유지되어야 합니다. 등록된 편집자의 유일한 이점을 위한 복잡한 구문은 주제입니다. Axel Boldt (talk) 2009년 4월 2일 (UTC) 02:41 답변[답변]
  163. 반대 - 어떤 형식으로든 날짜를 아주 쉽게 읽으며 날짜 형식은 불필요한 작업에 불과하다고 생각합니다 밥맨801 (토크) 2009년 4월 2일 (UTC) 04:28 (답변)
  164. 반대. 중립 투표를 하려고 했는데 마음이 바뀌었습니다. 원칙적으로 사용자가 원하는 방식으로 날짜를 표시할 수 있는 옵션을 사용자에게 제공하는 것이 좋습니다. 하지만, 저는 위키백과 사용자 중 극히 일부 이상이 이 기능을 이용해 본 적이 있는지(혹은 앞으로도 그렇게 할 것인지) 의문입니다. 날짜 형식을 사용하려면 사용자가 등록되고 로그인해야 하며 날짜 표시에 대한 기본 설정을 설정해야 합니다. 하지만 로그인한 상태에서 위키백과에 접속하는 사용자의 대다수는 주로 편집(기사 읽기)을 위해 로그인하고 날짜 표시는 신경 쓰지 않는 것으로 알고 있습니다(기사 읽기가 아니라 주로 편집을 위해 위키백과에 있기 때문입니다). 따라서 실제로 날짜 형식의 혜택을 받는 사용자는 거의 없다고 생각합니다. 자동 포맷의 작은 이점이 그것을 실행하는 데 드는 자원을 정당화하는 것은 아닙니다. (저는 자동 포맷이 기사를 통해 자원 봉사 시간과 공간을 소비하고, 특정 부분의 예비 자원 봉사자들을 위협하여 자원 봉사를 하지 못하게 할 것이라고 생각합니다.) --Orlady (talk) 2009년 4월 2일 (UTC) 04:40 답변[답변]
  165. 반대 사용자 환경설정을 통해 날짜를 자동으로 포맷할 수 있다는 것을 처음 발견했을 때 즉시 실행했습니다. 그런데 기사에서 보고 있는 내용이 페이지를 편집할 때 보고 있는 내용이 아니라는 것을 알게 되었습니다. 편집자로서, 대부분이 등록되지 않았기 때문에 자동 서식에 액세스할 수 없는 독자를 위해 백과사전을 최적화하는 것은 당사의 책임입니다. 자동 포맷은 편집자에게 장애물로 작용하여 독자들이 보고 있는 내용을 오해하게 하므로 바람직하지 않습니다. --Aervanath (talk) 2009년 4월 2일 (UTC) 05:14 (답변)
  166. 반대 (1) 여기서 해결할 문제는 없습니다. (2) 우리는 이미 새로운 사용자들이 감당하기에는 위협적인 마크업을 너무 많이 가지고 있고, {{#format date 2009. 3. 11}}는 그냥 용납할 수 없습니다. (3) 편집자들은 대다수의 독자들이 볼 것과 다른 무언가를 보고 있어서는 안 됩니다. Shreevatsa (talk) 2009년 4월 2일 (UTC) 05:28 답변[답변]
  167. 불필요한 것으로 반대합니다. 다른 날짜 형식은 철자법의 지역별 변형과 같습니다. 그것들은 매우 익숙하기 쉽습니다. 다음은 무엇입니까? "color"를 "color"로 변경하기 위한 자동 포맷입니까? Rivertorch (talk) 2009년 4월 2일 (UTC) 05:31 답변[답변]
  168. 반대 편집자들은 일반 독자들과 같은 견해를 가져야 합니다. Taemyr (talk) 2009년 4월 2일 (UTC) 05:55 답변[답변]
  169. 9월, 샌디, 카라낙스 등 반대합니다. --Yannismarou (talk) 2009년 4월 2일 (UTC) 08:03 (답변)
  170. 반대. 자동 포맷은 더 많은 작업이 필요하고 독자들에게 전혀 도움이 되지 않습니다. 모든 사람이 두 가지 공통 형식으로 날짜를 이해합니다. FA에 대한 MoS 요구 사항을 채우기 위해 이미 너무 많은 구문이 필요하며, 국가 날짜 형식만큼 사람들이 포맷의 제거/추가에 대해 논쟁하지 않을 것이라고 생각하는 사람은 편집자의 무의미한 전쟁에 대한 욕구를 과소평가합니다. Engvar와 같이 날짜에 대한 규칙만 있으면 됩니다.134.169.58.89 (토크) 09:12, 2009년 4월 2일 (UTC)답장[답장]
  171. 반대. 필요한 노력을 할 가치가 없습니다. 편집을 더 어렵게 만들고, 일반 독자들에게 가장 의심스러운 이점을 제공합니다. -Woodstone (talk) 2009년 4월 2일 (UTC) 11:20 답변[답변]
  172. 반대. 아니요. 저는 확실히 제 마크업이 자연어에서 더 멀리 나아가길 원하지 않으며 템플릿의 필연적인 제한된 배포는 자동화된 날짜 기반 도구가 템플릿이 아닌 날짜를 구문 분석하도록 강요할 것입니다. 그리고 자동화된 도구는 무엇을 합니까? 어떤 날짜가 기사 내용과 밀접하게 연결되어 있는지, 어떤 날짜가 기사 주제가 잘 이해되는 과정을 설명하는지는 알 수 없을 것 같습니다.아브람 (talk) 2009년 4월 2일 (UTC) 16:45 답변[답변]
  173. 피먼더슨, 카라낙스, 가토클래시에 따라 반대합니다. --Roise step (talk) 2009년 4월 2일 (UTC) 17:32 답변[답변]
  174. 반대 캐주얼 사용자와 등록 사용자 간에 차이가 없어야 합니다.--Shahab (talk) 2009년 4월 2일 (UTC) 18:57 (답변)
  175. ENGVAR에 반대하는 것이 이 문제에 대한 최선의 가장 간단한 해결책입니다. -- Mattinbgn\talk 20:46, 2009년 4월 2일 (UTC)응답하라[답변]
  176. 반대번호 130번은 더 잘 말하고 있고, 저는 미국의 계보학자들이 다른 계보학자들보다 일/전월/년을 훨씬 더 많이 사용하고 있다는 사실에 대해 아무도 언급하는 것을 보지 못합니다. FamilySearch에서도 이 기능을 전체적으로 사용합니다. 저는 유럽 데이트를 이용합니다. Samuelsenwd (talk) 2009년 4월 2일 (UTC) 21:49 답변[답변]
  177. 반대. 저는 대부분의 독자들이 기사가 4월 2일이든 4월 2일이든 상관하지 않는다고 생각합니다. 그 순서는 추가적인 코딩 복잡성을 보증하지 않을 만큼 사소합니다. Steve 22:02, 2009년 4월 2일 (UTC)답장[답장]
  178. 불필요하게 추가된 복잡성에 반대합니다.—S Marshall Cont/ 2009년 4월 2일 (UTC) 22:24 답변[답변]
  179. 반대 - 자체 최고 기술 책임자는 다음과 같이 말합니다. "개인적으로 모든 날짜 자동 서식을 삭제하는 것이 좋습니다." 이 모든 것은 복잡하고 힘들며 추가 혜택은 거의 또는 전혀 없습니다. 날짜가 주어진 이상 2009년 4월 2일, 2009년 4월 2일, 2009년 4월 2일, 또는 2009년 4월 2일 중 둘째 날이라고 적혀 있어도 상관없습니다. Jd027 (토크) 2009년 4월 2일 (UTC) 23:22 답변[답변]
  180. 반대. 논쟁을 반복해야 하나요? -- Taku (talk) 2009년 4월 3일 (UTC) 01:47 답변[답변]
  181. 반대 - 특정 사용자 그룹의 반감에 대한 기사 텍스트를 조작해서는 안 됩니다. 특히 날짜 변형을 이해하는 데 전혀 문제가 없을 때는 더욱 그렇습니다. Cycle (talk) 02:50, 2009년 4월 3일 (UTC)답장[답장]
  182. 반대. 저는 자동 포맷에서 어떤 이점도 실제로 본 적이 없으며, (지금까지의) 구현은 득보다 실이 더 많았습니다. Yilloslime 2009년 4월 3일 (UTC) 04:33 답변[답변]
  183. 등록되지 않은 사용자로서 제가 그렇게 할 수 있다면 반대합니다. 그것이 제가 반대하는 이유 중 하나입니다. 사람들은 이것이 저와 같은 사용자에게 이익이 되지 않을 때 이것에 시간을 낭비해서는 안 됩니다. 게다가 날짜만큼 짧은 것에 대한 추가 마크업의 양은 다루기 어렵습니다. 그리고 이것은 단순히 "2009년 4월 3일" 또는 "2009년 4월 3일"을 렌더링하는 문제가 아닙니다. 만약 이것이 문장 내에 나타난다면 두 번째 형식, 즉 "2009년 4월 3일"에 두 번째 쉼표가 필요할 수 있습니다. 이에 대한 옵션을 제공하더라도 다른 형식에 익숙한 많은 사람들이 잘못 이해할 것입니다. --208.76.104.133 (토크) 2009년 4월 3일 (UTC) 05:15 (답변)
  184. 반대. 몇 가지 이유를 들어보면, 특히 IP 사용자가 포맷된 날짜를 보지 못하는 문제가 합리적이라는 생각이 듭니다. Mike Christie (talk) 2009년 4월 3일 (UTC) 10:57 답변[답변]
  185. 반대. 저는 보통 비문제에 대한 복잡한 기술적 해결책(특히 생산적인 일을 해야 할 때)에 찬성하지만, 이 문제는 그 가치보다 더 큰 슬픔을 야기할 것입니다. 순수하게 숫자로만 날짜를 사용하지 않는 한, 모호함이 없고 순서(1월 4일 대 1월 4일)는 전혀 중요하지 않습니다. 하지만 주의할 점은 어디선가 숫자로 된 날짜(예: 정보 상자)를 사용하는 경우 YMD 또는 DMY와 같이 4자리 연도가 포함된 합리적인 날짜 형식이어야 한다는 것입니다. 이를 시행하기 위해 자동 형식을 지원하지만 대부분의 템플릿이 이미 적용되는 것으로 알고 있습니다. Orpheus (talk) 2009년 4월 3일 11:00 (UTC)답장[답장]
  186. 반대 - 저는 이것에 대해 별로 강하게 생각하지 않지만, 생각해 보면 그것은 꽤 명확한 결정입니다. 자동 포맷은 이론적으로 좋은 아이디어이지만 실제로는 소수의 헌신적이고 참여한 편집자(선호도를 설정할 수 있을 정도로 확실한 편집자)에게 경미한 이점을 제공하는 동시에 대다수의 독자들에게도 마찬가지로 경미한 단점을 제공합니다. 좋은 아이디어입니다. 하지만 구현이 우리가 원하는 것을 충족시키지 못했고, 우리는 우리에게 도움이 되지 않는 것들을 버릴 수 있을 만큼 충분히 성숙한 프로젝트이기를 바랍니다. Shimgray talk 2009년 4월 3일 (UTC) 15:17 답변[답변]
  187. 반대 -- 우리는 자동 영/미 영어 철자법을 가지고 있지도 않고 원하지도 않습니다. 이것은 비슷합니다. -- 켈리 쿡 (talk)
  188. 반대 - 스타일 매뉴얼은 03/04/2009과 같은 혼란스러운 형식을 허용하거나 권장하지 않으므로, 인간 독자에게는 혼란이 없어야 합니다. 환경설정이 설정된 로그인한 편집자들만이 지나가는 독자들이 하는 일을 보지 못해서 혼란을 일으키거나 혼란을 일으킬 가능성이 있습니다. 21 Bede (토크) 15:51, 2009년 4월 3일 (UTC)답변[답변]
  189. 반대. 주로 WP의 단순한 경우이기 때문입니다.ENGVAR. 위키백과가 날짜를 일관되게 제시해야 한다고 주장하는 지지자들은 우리가 백과사전 전체에서 색/색 또는 미터/미터의 철자를 일관되게 쓰지 않는다는 것을 잊었습니다. 브리태니커가 일관된 날짜 형식을 사용하는 예는 그들이 일관된 영국 영어 철자를 사용한다는 사실의 연장선에 있습니다. 우리가 해야 할 일은 각 기사 내에서 일관된 날짜 형식을 갖는 것이며, 일반 텍스트 날짜는 추가 마크업 없이 이를 해결할 수 있습니다. --seav (talk) 2009년 4월 3일 (UTC)응답하라[답변]
  190. 반대 - KISS 원칙과 위키백과 자원봉사자들이 직면하고 있는 모든 문제들 때문에, 이것은 우선순위가 매우 낮은 것으로 보입니다. 또한 이 문제에 참석하기 위해 편집자로부터 필요한 것이 있다면 그럴 가치가 없습니다. 다시 말해서, 저는 어떤 종류의 자원도 사용하지 않을 것입니다(이 여론조사조차도 시간이 많이 걸리는 것처럼 보입니다). 제 생각에 위키백과는 상당히 새로운 위키백과로서 이미 엄청난 수의 토론에 잠겨 있습니다. 현재의 시스템은 효과가 있고, 모든 편집자들은 그들이 기사 내에서 일관성을 유지해야 한다는 것을 알고 있고, 복사 편집 팀의 일원으로서 지금까지 저는 어떤 기사도 일관성이 없다는 것을 거의 발견하지 못했지만, 만약 그렇다면, 복사 편집을 위해 태그를 붙이고 그냥 두세요. 더 많은 사람들이 현재의 마크업에 익숙해질 때까지 추가 마크업을 필요로 하는 것은 없습니다.Levalley (talk) 2009년 4월 3일 18:20 (UTC)답장[답장]
  191. 반대Malik Shabazz (talk·기여) 2009년 4월 3일 (UTC) 19:41 답변[답변]
  192. 반대. Malinaccier (talk) 2009년 4월 3일 19:47 (UTC)답장[답장]
  193. 반대 일부 등록된 편집자들은 날짜 형식을 한 가지만 볼 수 있도록 자동 형식 지정 번거로움은 노력할 가치가 없습니다. 다른 모든 사람들은 어떤 기사에 실릴지에 따라 두 가지 형식을 보게 될 것입니다. 그것은 큰 문제가 아닙니다. Deegee375 (talk) 2009년 4월 3일 21:13 (UTC)답장[답장]
  194. 반대는 로그인한 사용자만 볼 수 있습니다. 만약 그렇다면, 그것은 단순히 소개되어서는 안 됩니다. Peanut4 (talk) 2009년 4월 3일 21:52 (UTC)답장[답장]
  195. 반대, 유용한 추가가 아닙니다. --Peta (talk) 2009년 4월 4일 (UTC) 08:15 (답변)
  196. 반대 --Alex Holcombe (talk) 2009년 4월 4일 (UTC) 08:43 답변[답변]
  197. 강력하게 반대합니다.자동 포맷은 마크업 애호가를 위한 것입니다. 제정신인 사람들은 (그리고 생산적인) 에너지를 훨씬 더 현명하게 소비합니다.-DCGeist (talk) 2009년 4월 4일 (UTC) 09:01 답변[답변]
  198. 반대 - 안돼, 안돼, 천번 안돼! 오토포타밍은 어떤 대가를 치르더라도 피해야 합니다. 또한 그것은 사악하고 반드시 죽습니다! Snappy에 의해 추가된 서명되지 않은 이전 주석(talkcontributes)
  199. 반대 자동 포맷은 일을 지나치게 복잡하게 만들 것이고, 그로 인해 얻을 수 있는 이점은 매우 사소한 IMO입니다. 마크업을 가능한 한 단순화하고 그 반대는 하지 맙시다! 로랑 (talk) 2009년 4월 4일 12:24 (UTC)답장[답장]
  200. 반대합니다. 큰 문제가 무엇인지 잘 모르겠습니다. 저는 영국에서 왔습니다(그리고 개인적으로 영국 날짜 형식을 선호합니다). 하지만 저는 미국식 형식(Month Day, Year - M-D-Y까지는 아닐 수도 있음)이나 ISO 형식(YYYYMMDD)을 쉽게 이해할 수 있습니다. ~~ [ジャム] 2009년 4월 14일 (UTC) 14:14 (답장)
  201. 반대: 자동 포맷은 대다수의 WP 독자들에게 아무런 도움이 되지 않으며, 여기서는 a)가 실제 계정에 로그인한 사람들만, b)가 자동 포맷 옵션을 설정하는 데 어려움을 겪었습니다. 자동 포맷 "기능"은 숙련된 편집자(즉, 기사 불일치를 수정할 가능성이 있는 편집자)가 대부분의 독자에게 일관성 없이 제공되는 ISO 포맷을 포함하여 기사 내의 일관성 없는 날짜를 거의 알아채지 못하게 합니다.에스엠씨캔들리 [talk] [cont] ‹(-¿-) › 18:22, 2009년 4월 4일 (UTC)응답하라[답변]
  202. 반대 MOS:NUM에 따라 적절한 형식을 선택하고 일관성 있게 작성합니다. WP에 대처할 수 있습니다.ENGVAR, 우리는 적절한 날짜 형식을 사용하는 것에 대처할 기술적인 해결책이 필요하지 않습니다. Struway2 (talk) 2009년 4월 4일 20:19 (UTC)답장[답장]
  203. 반대 - 진짜 요점이 없고, 문제를 일으키고, 노력과 논쟁을 할 가치가 없습니다. 오타바 리마 (talk) 2009년 4월 4일 20:21 (UTC)답장[답장]
  204. 반대. 결과가 얼마나 대가를 치르는지 모르겠네요. bibiomaniac 15 2009년 4월 4일 (UTC)응답하라[답변]
  205. 반대. 전혀 이해가 되지 않았습니다. --Moni3 (talk) 2009년 4월 5일 (UTC)응답하라[답변]
  206. 반대 - 선호 옵션을 탐색해야 하는 모든 것은 소수의 사용자만 사용할 수 있습니다. 또한 대다수의 사용자가 등록되지도 않았습니다. 일은 많고 이득은 적습니다. 구두장이의 휴일 (talk) 2009년 4월 5일 06:02 (UTC)답장[답장]
  207. 반대 이것은 문제를 찾는 해결책입니다. 각 기사 내에서 일관성을 유지하기만 하면 됩니다. Joshdboz (talk) 2009년 4월 5일 07:13 (UTC)답장[답장]
  208. 반대 기사 작성에 참여하는 편집자들이 일관된 형식에 합의할 수 있도록 합니다. 더 많은 문제를 발생시킬 수 있는 자동 프로세스가 필요하지 않습니다. Jezhotwells (talk) 2009년 4월 5일 (UTC) 12:11 답변[답변]
  209. 반대 필요하지 않고 오류와 오역이 발생하기 쉬운 곳에 복잡성을 추가하지 마십시오.--Avg (talk) 2009년 4월 5일 (UTC)응답하라[답변]
  210. 필요 없는 것을 무례하게 해결하는 에 반대합니다. --Thomas B talk 16:53, 2009년 4월 5일 (UTC)답변[답변]
  211. 반대. 반대하는 주장은 정말로 완전히 요약됩니다. — σ 명시적 2009년 4월 5일 19:02 (UTC)답장[답장]
  212. 반대: 날짜가 연결되어야 한다고 생각하지 마세요, 지저분해 보여요. Ryan4314 (talk) 2009년 4월 5일 (UTC) 19:11 답변[답변]
  213. 반대 - 처음에는 지지했고 처음에는 지지했지만 지금은 지지합니다. -- ThinkBlue (Hit BLUE) 2009년 4월 5일 (UTC) 22:32 (답변)
  214. 훌륭한 주장에 반대합니다. Tony가 말했듯이, 품질을 희생하지 않고 단순하게 만드는 것이 핵심입니다. 슬프게도, 자동 포맷은 두 가지를 모두 위반할 가능성이 있습니다.데킬러 2009년 4월 5일 (UTC) 23:43 답변[답변]
  215. 반대: 날짜뿐만 아니라 시간, 단위 등 모든 경우에 ISO 표준을 엄격하게 따라야 한다고 생각합니다. 이것을 자동 형식화하는 것은 간단한 패턴 인식 작업으로, 자바 스크립트를 사용하여 로컬로 수행할 수도 있지만, 형식을 로컬화해서는 안 되는 경우에 필요한 유일한 특수 태그입니다. 제가 이에 반대하는 이유는 모든 형태의 현지화는 일반적인 형식이어야 하고 날짜에 대한 특례를 시행하는 것은 혼란스러울 것이며 원텍스트 형식의 획일적인 기준에 어긋날 것이라고 생각하기 때문입니다. 모든 것을 ISO 표준으로 "수정"하는 것이 기념비적인 작업이라는 것을 이해하지만, 저는 그 이점이 비용보다 크다고 생각하고 그렇게 할 인력이 부족하지 않습니다. Brainz (talk) 2009년 4월 6일 (UTC) 04:22 답변[답변]
  216. 반대 - 위키백과 독자 중 극히 일부만이 자동 포맷의 혜택을 받을 것이며, 복잡한 구문이 새로운 편집자들을 저지합니다. -- SWTPC6800 (토크) 04:27, 2009년 4월 6일 (UTC) 매달 위키백과의 독자 수는 약 5,600만 명에 이릅니다. 데이터 선호도를 설정한 위키피디아 사람은 18만 명에 불과하므로 기껏해야 300명의 뷰어 중 1명(0.3%)이 날짜 자동 포맷의 혜택을 볼 수 있습니다. -- SWTPC6800 (토크) 02:41, 2009년 4월 12일 (UTC)답변[답변]
  217. 반대 - 등록된 v. 비등록된 v.에 대한 다른 형식에 반대합니다. WP:ENGVAR는 이 문제에 완벽하게 답합니다.--2008년chitchat 올림픽 04:57, 2009년 4월 6일 (UTC)답장[답장]
  218. 반대 - 시행해야 할 업무량에 비해 영향/수혜자가 부족합니다. 비용/편익을 기억하세요. 2009년 4월 6일 13:28 (UTC)응답하라[응답하라]
  219. 반대 - 날짜를 다시 포맷할 목적으로 연결하면 일반적인 사용자의 연결 개념이 깨지고 페이지 전체에 관련 없는 링크가 엄청나게 늘어납니다. 제안된 교체도 마찬가지로 좋지 않습니다. 날짜 재포맷이 꼭 필요한 사람은 개인용 자바스크립트나 브라우저 플러그인으로 해야 합니다. -- 오스틴 머피 (토크) 2009년 4월 6일 (UTC) 14:26 (답변)
  220. 반대 - 날짜 형식을 철자법 및 기타 지역적 차이와 동일한 방법으로 할 수 없는 이유는 없습니다. Richard New Forest (talk) 2009년 4월 6일 (UTC) 14:52 답변[답변]
  221. 1위에 반대하고 서버가 충돌할 경우마다... 미란다 2009년 4월 6일 (UTC) 16:33 답변[답변]
  222. 비용-편익 분석에서는 복잡성이 추가되는 작은 비용이 가능한 이점과 거의 구별할 수 없는 이점을 능가합니다. Knepflerle (talk) 2009년 4월 6일 (UTC) 16:37 답변[답변]
  223. 반대합니다. 이것은 자원 낭비입니다. R3ap3R.inc (talk) 2009년 4월 6일 17:03 (UTC)답장[답장]
  224. KISS 반대. Fredrik Johansson 2009년 4월 6일 17:28 (UTC)답장[답장]
  225. 반대 구성 옵션을 통해 작업할 만큼 지능적인 사람이라면 다양한 날짜 형식을 해석하는 데 문제가 없습니다.Danorton (talk) 2009년 4월 6일 (UTC) 18:10 답변[답변]
  226. 반대는 거의 도움이 되지 않습니다. 숙련된 편집자가 포맷 문제를 인식할 가능성이 낮아지므로 구문을 혼동하면 새로운 편집자가 편집하기가 더욱 어려워집니다. Calliopejen1 (talk) 2009년 4월 6일 18:25 (UTC)답장[답장]
  227. 극히 적은 혜택으로 럭셔리를 표준화하는 것에 반대합니다. 베드로 18:33, 2009년 4월 6일 (UTC)답장[답장]
  228. 모든 것이 표준화되어야 하는 이유, 필요하지 않은 이유에 반대합니다. Edmund Patrick – 2009년 4월 6일 19:01(UTC) 회신
  229. 반대합니다. 문제 없습니다. 날짜는 날짜입니다. 당신이 당신의 언어를 사용하지 않는 사람에게 더 큰 소리로 말하는 것이 그들을 이해하게 한다고 생각하는 사람들 중 한 명이 아니라면, 나나 ymd는 중요하지 않습니다:>--Mrboire (talk) 2009년 4월 6일 (UTC)19:47 답변[답변]
  230. 대부분의 독자들은 그것을 보지 않습니다. 많은/대부분의 경우 무의미합니다. --Karl Frei (talk) 2009년 4월 6일 (UTC) 20:18 (답변)
  231. (날짜 형식을 완벽하게 이해할 수 있고 대부분의 독자가 계정을 사용하지 않기 때문에) 매우 제한적인 개선과 가치 있는 블루 링크의 현저성을 크게 희석하는 것에 반대합니다. 날짜와 연도에 대한 기사는 어떤 목적에 도움이 될 수 있지만 기사의 맥락에서는 결코 유용한 링크가 아닙니다. 저는 이에 대한 공감대가 강하지만, 그 과정에서 특집 기사를 작성했거나 리뷰어로 활동한 사용자의 견해를 검토할 때는 더욱 강하다고 생각합니다. Savidan 20:58, 2009년 4월 6일 (UTC)답장[답장]
  232. 깨지지 않으면 반대하세요, 고치지 마세요. Dlabtot (talk) 00:19, 2009년 4월 7일 (UTC)답장[답장]
  233. 반대 — 부정적인 비용/편익(불편함, 노력 및 시간 측면에서 비용). 확실히 훌륭한 능력이지만, 질문할 필요가 없는 질문에 대한 답입니다. 마치 호주인이 미국 청중에게 연설을 번역하기 위해 번역가를 고용하거나 그 반대의 경우도 마찬가지입니다. 위키백과에 대한 접근은 이 형식과 다른 형식의 날짜를 접하는 것으로 인해 아무도 방해받지 않습니다. 이러한 확장이 실제로 필요한 곳에서 접근성을 확장하기 위한 기능을 구현하는 데 노력을 집중해 보겠습니다.샤이너페르C·00:35, 2009년 4월 7일 (UTC)답장[답장]
  234. 반대. 자동 포맷을 추진하는 것은 위키백과 고유의 복잡성과 위키백과 독자층의 다양성에 대한 이해는 되지만 부적절한 반응입니다. 이것은 일반 편집자의 대다수가 불이익을 받고 낙담하는 음험한 기술관료적이고 "고전적인" 접근법을 보여줍니다. 예상되는 혜택은 위키백과에 참여하는 인간적인 측면을 이해하지 못하는 소수의 목소리를 내는 사람들에게 요구되는 양보의 가치가 없습니다. 아마도 미래에 프로젝트는 보다 합리적인 기술적 기반에 의존하게 될 것입니다. 그 때까지 이러한 종류의 계획은 실행 불가능한 것으로 저항하게 될 것입니다. 사용자와 편집자 모두에게 간단하고 이해하기 쉬운 상태를 유지해야 합니다.¡ɐɔıʇǝo노에티카!T– 2009년 4월 7일 07:19 (UTC)답장[답장]
  235. 반대 - 상당히 불확실합니다. Pluni Almoni (talk) 2009년 4월 7일 09:43 (UTC)답장[답장]
  236. "반대"라고 생각합니다. 사실 저는 날짜 자동 포맷이라는 일반적인 개념에 전혀 반대하지 않습니다. 예를 들어 노에티카와 달리 그의 반응을 위에서 자세히 해석하기 때문입니다. 그러나 실제로 우리는 일반적인 개념에 대한 의견을 묻는 것이 아니라 우리가 얻을 수 있는 구현에 대한 의견을 묻습니다. 저는 146년경 짐핀이 지적한 이유로 인해 우리가 얻을 수 있는 함의에 반대합니다(혹은 당신이 "!투표"를 선호한다면). 물론 상황에 민감한 알고리즘을 완벽하게 만드는 데는 더 많은 작업이 필요할 수도 있고, 결국에는 이것이 효과가 있을지도 모릅니다. 하지만 위의 56번 정도의 투표에서 라르고 플라조가 설명한 바와 같이, 이것은 시간과 노력, 그리고 아마도 처리 능력의 기괴한 소모로 보일 것입니다. (NB 제 투표는 날짜 연결과는 아무런 관련이 없으며, 물론 (a) 이는 매우 불쾌합니다. 하지만 (b) 여기서 핵심을 벗어난 것입니다.) -- 호어리 (talk) 2009년 4월 7일 (UTC)응답하라[답변]
  237. 반대. 짐프를 지지합니다(147). "이유"는 매우 약합니다. Platia (talk) 2009년 4월 7일 14:06 (UTC)답장[답장]
  238. 반대 너무 사소한 일에 너무 많은 노력과 위험이 따르는 것 같습니다. 시행되면 영국 대 영국의 자동 포맷 제안이 뒤따를 수 있습니다. 미국 철자 등 재미없네요. 위키피디아의 한 가지 기쁨은 이질성입니다. 그것은 영어의 특성이기도 합니다. 왜 그 이질성을 균일한 상자에 짜 넣으려고 합니까? 핑크빌 (talk) 2009년 4월 7일 14:56 (UTC)답장[답장]
  239. 반대 고립된 상태에서 자동 포맷은 잠재적으로 깔끔합니다. 그러나 단점을 측정했을 때 부족합니다. 아주 사소한 일 때문에 그런 수고를 할 가치는 없습니다. --Cyde Weys 2009년 4월 7일 (UTC) 15:39 답변[답변]
  240. 반대합니다 사소한 문제를 해결하기 위한 많은 노력과 새로운 편집자들을 위한 학습 곡선의 또 다른 단계처럼 보입니다. 다음은, ENGVAR 정정자? Acrotion 18:31, 2009년 4월 7일 (UTC)답장[답장]
  241. 반대. 이것은 누구나 편집할 수 있는 백과사전이지 난해한 마크업 규칙을 배우려는 누구나 편집할 수 있는 백과사전이 아닙니다. 제 생각에 우리는 이미 이 미끄러운 비탈길에서 너무 멀리 떨어져 있습니다. Jgm (talk) 2009년 4월 7일 20:45 (UTC)답장[답장]
  242. 어웨이윗에 반대합니다. Nev1 (talk) 2009년 4월 7일 21:33 (UTC)답장[답장]
  243. 위의 Jgm으로 반대합니다. --Doug (talk) 2009년 4월 8일 (UTC) 09:05 (답변)
  244. 저의 입장은 일반적으로 날짜 자동 형식화에 반대합니다. 제안된 "링크리스" 시스템은 실제로 아무 것도 변하지 않았고, 제안된 시스템이 이러한 유형의 치료에 내재된 문제를 해결할 수 있을지 확신이 서지 않습니다.
    1. 자동 포맷을 찬성하는 주장 중 하나는 많은 편집자가 원하는 날짜의 통일된 스타일을 제공한다는 것입니다. 그러나 기사의 다른 많은 측면이 영어의 다른 방언의 관습을 분명히 따를 때 어떤 의미가 있는지 이해할 수 없습니다. 이 시스템은 기사 내에서 충돌을 일으킬 것이며, 우리가 모든 곳에서 단일 날짜 형식을 채택하는 것을 논의하지 않는 한, 이런 맥락에서 획일성을 말하는 것은 터널 비전을 암시합니다.
    2. 또 다른 주장은 DA가 사소한 논쟁을 막는다는 것입니다. 우리는 편집자만을 위한 백과사전을 작성하는 것이 아니라 일반적으로 세계를 위한 백과사전을 작성해야 합니다. 우리는 모두 하나의 프로젝트를 진행하고 있으므로 독자들이 보는 것과 동일한 것을 보아야 합니다. 토크 및 프로젝트 페이지에서 시간대와 같은 것을 사용자 지정하는 것은 한 가지이지만 메인 공간에서는 이것을 협상할 수 없는 원칙으로 생각합니다.
    DA에 대해 더 많은 것을 말씀드릴 수 있지만, 결론은 필요 없고, 필요 없는 것이 더 좋을 것이라는 것입니다. 월담 공작 2009년 4월 8일 14:41 (UTC) 답변[답변]
  245. 반대 케네디 2009년 4월 8일 15:08 (UTC)응답하라
  246. 반대합니다. 저는 편집자가 연못의 어느 쪽에 있는지 대략적으로 알기 위해 사용하는 날짜 형식을 보는 것이 유용하다고 생각합니다. 게다가, 자동 포팅 날짜는 정말로, 정말로 미미합니다. --Armchair info guy (talk) 2009년 4월 8일 (UTC) 15:11 (답장)
  247. 위키백과를 가능한 단순하고 단순하게 유지하는 에 반대합니다. 풀드라마 (talk) 2009년 4월 8일 17:32 (UTC)응답하라[응답하라]
  248. 반대 상자는 나를 위해 모든 것을 완벽하게 요약합니다. 저는 단지 그것이 필요하다고 생각하지 않고, 그것은 신입들에게 복잡하고 혼란스러울 수 있습니다. --GedUK 2009년 4월 8일 (UTC)응답하라
  249. 반대합니다. 저는 그것이 왜 필요한지 알 수 없고 그것이 신입들에게 어떤 상처를 주는지 알 수 있습니다. Zerter (talk) 2009년 4월 8일 19:19 (UTC)답장[답장]
  250. 이것투표하세요(반대하는 입장을 반대하는 것은 말도 안 되는 소리입니다). 그런 사소한 일로 끝없이 티격태격하며 투표하지 말아주세요. 브리온 바이브버의 솔루션은 제가 봐도 괜찮고, 다양한 변형도 괜찮습니다. 좋습니다만, 날짜를 자동으로 포맷할 필요는 없으며, 그렇게 하는 데 의견이 일치하지 않는 것 같습니다. 철자 자동 서식에 대한 합의는 분명히 없을 것입니다. 그 정도면 됐어요, 이야기 끝. 기하학 남자 2009년 4월 8일 20:57 (UTC)응답하라[응답하라]
  251. 혼란스럽고 불필요한 것에 반대합니다. 위키피디아는 그 자체로 하나의 것입니다. 완전히 일관된 백과사전을 원한다면, 일반 참고서가 하는 일을 하고, 모든 것을 편집하는 편집자 패널을 지정하고 누구나 편집할 수 있는 작품에 대한 아이디어를 포기합니다. 위키백과는 편집 규칙이 그대로 너무 많습니다. Fijagdh (talk) 2009년 4월 8일 21:10 (UTC)답장[답장]
  252. 반대 모두 YYY-mm-dd 형식을 사용해야 합니다. 파이썬 알 (talk) 2009년 4월 9일 04:39 (UTC)답장[답장]
  253. 반대 언급된 다른 많은 이유뿐만 아니라 가독성에 악영향을 미친다고 생각합니다. Hohenloh + 19:45, 2009년 4월 9일 (UTC)답장[답장]
  254. 반대합니다. 이것이 일부 사람들에게 도움이 될 수도 있다는 것을 인정하지만, 전체적으로는 아마도 선보다 악을 더 많이 가져올 것입니다. Hussönd 20:39, 2009년 4월 9일 (UTC)답장
  255. 반대합니다. 독자들의 관점에서 볼 때, 엄청난 노력과 많은 편집자들과 IT 부서의 지속적인 비용 부담이 있다면, 다른 모든 백과사전들은 동등하게 유지되고, 대부분 변하지 않을 것이라고 생각합니다. - 부정적인 경험과 지속적인 좌절감이 있는 편집자들만이 그 경험이 입증되지 않은 후 한 달 정도 지나면 그것을 알게 될 것입니다. --Karbinski (talk) 2009년 4월 9일 20:45 (UTC)응답하라[답변]
  256. 자동 형식화되지 않은 날짜에 익숙해진 반대, 날짜를 날짜 기사로 연결하는 것의 장점은 중요하지 않은 날짜에 대한 사소한 파란색 링크가 없는 더 깨끗한 외관보다 더 큽니다. 맞춤법과 마찬가지로 관련 국가의 선호도에 따라 날짜를 포맷하는 것이 항상 좋기 때문에 선호도를 설정한 적이 없습니다. 일반적으로 인식할 수 있는 두 가지 배열에서 날짜의 문제가 아닌 것을 고치기에는 너무 많은 노력과 해킹이 필요합니다. dave souza, talk 21:57, 2009년 4월 9일 (UTC)답변[답변]
  257. 강한 반대 사소한 세부 사항. 다음은 {{British color}}와 같은 템플릿이 있어야 하나요? --NiplesMeCool (talk) 2009년 4월 9일 (UTC)응답하라[답변]
  258. 불필요하고 사소한 에 반대합니다. 저는 관련된 노력에 아무런 이점이 없다고 봅니다. Hohum (talk) 2009년 4월 10일 17:19 (UTC)답장[답장]
  259. 반대해요 그 해결책들은 문제보다 더 귀찮습니다. 강력한 자동 포맷이 필요하지 않습니다. --GGG65 (토크) 2009년 4월 10일 (UTC) 18:34 답변[답변]
  260. 반대 다음 중 하나가 필요한 경우: 1밀리초의 추가 로딩 시간, 페이지에 추가적인 위키 링크를 추가하는 경우, 기존 또는 신규 또는 대체 브라우저에 문제를 추가하는 경우, 때로는 이미 초과 세금이 부과된 위키 서버에 대한 요구를 하는 경우, 1~2개 이상의 추가 기호를 추가하여 편집에 혼란을 주는 경우, 이 옵션은 제가 받아들일 수 없습니다. 문제가 없다고 생각하기 때문에, 저는 이것의 부정적인 영향을 받을 가능성이 10억분의 1밖에 없다고 생각합니다. 저는 이것이 보장될 수 있다고 생각하지 않으므로 반대합니다. Arnoutf (talk) 2009년 4월 10일 (UTC) 19:41 답변[답변]
  261. 반대 날짜 자동 형식은 편집자가 일반 텍스트로 이해하기 어려운 형식을 부과하는 핑계가 될 수 있으며, 이를 정당화하기 위해 "마음에 들지 않으면 날짜 자동 형식 환경설정만 설정하십시오."라고 말합니다. 위키백과 페이지는 정상적인 사람들이 이해할 수 있도록 작성되어야 합니다. 다양한 위키백과 전용 환경설정이 설정된 회원에 로그인할 필요는 없습니다. --Toddy1 (토크) 2009년 4월 10일 (UTC)21:07 (답변)
  262. 날짜를 연결하는 것에 반대하는 것은 잘못된 메시지를 전달하고 추악한 무의미한 어리석음입니다. 2005 (talk) 2009년 4월 10일 (UTC) 23:01 답변[답변]
  263. 반대...빅타임 우리는 여기서 너무 복잡한 것들을 좋아하지 않나요? 유(knome)? yes...or no 2009년 4월 11일 01:28 (UTC)답장[답장]
  264. 반대 누구에게도 이익이 거의 없는 편집자들에게는 시간 낭비를 반대합니다. McKay (talk) 2009년 4월 11일 01:57 (UTC)답장[답장]
  265. 반대만 해도 효과가 없고 필요도 거의 없습니다. --Itub (talk) 2009년 4월 11일 (UTC) 02:37 답변[답변]
  266. 반대 이것을 논하는 것조차 시간 낭비입니다. (1) 위키백과는 실제 사용법이 이렇게 다양할 때 절대적인 기준 없이 살 수 있습니다. (2) 사용자는 이를 스스로 관리할 수 있을 정도로 지능적입니다. (3) 또한 정확한 인용문에서 형식은 인용 자료의 내용과 정확히 일치해야 합니다. (4) 마지막으로 이 모든 노력은 의약품, 중국 전설에 관한 많은 것과 같이 전문가가 아닌 독자가 즉시 사라지는 수많은 기사를 개선하는 데 전념해야 합니다. 인도의 역사, 질병, 날씨 등. Zaslav (talk) 2009년 4월 11일 06:23 (UTC)답장[답장]
  267. 반대는 하지만 산문, 참고인 등에서 어떤 날짜 형식을 사용하는지에 대해서는 제대로 된 합의가 이루어져야 한다고 생각합니다. Corn.u.co .pia Disc.us .sion 07:32, 2009년 4월 11일 (UTC)답장[답장]
  268. 반대합니다. 저는 다른 날짜 형식이 우리가 살 수 있는 다른 철자 시스템보다 훨씬 덜 중요하다고 생각합니다. 일부 다양성에는 문제가 없습니다. 간단한 영어 위키가 아닙니다. --Charles (talk) 2009년 4월 11일 (UTC)10:28 (답변)
  269. 반대합니다. 아무런 차이가 없습니다. 단지 불필요한 포맷이나 성가신 링크를 곳곳에 추가하는 것 뿐입니다. - .Logan't 2009년 4월 11일 (UTC) 11:17 답변[답변]
  270. 반대하세요 사소한 일에 너무 많은 노력을 기울이는 것입니다. 제가 위키백과에 대해 들어본 모든 불만 중에서 "날짜가 잘못된 방법"이라는 MortimerCat (토크) 2009년 4월 11일 11:23 (UTC)응답하라
  271. 반대 - 지난 번에 언급한 것과 같은 이유로 날짜를 자동으로 포맷하면 날짜 기간의 필요성을 고려할 때 종종 엉성해 보이는 기사가 됩니다. 따라서 WP와 마찬가지로 주제에 따라 날짜를 포맷해야 합니다.ENGVAR. 상식적으로. ل나베시아 2009년 4월 11일 15:22 (UTC)답장[답장]
  272. "인터페이스 사용자 지정"에 반대하는 것은 오해의 소지가 있는 적반하장입니다. 운영 체제의 기본 설정은 웹 페이지와 기사를 다시 작성하지 않습니다. 편집자들이 글을 쓰고 독자들은 글을 읽습니다. 편집자는 출력을 제어하기 위해 위키텍스트를 사용하며, 기계는 희망사항을 기반으로 다시 작성하여 개선하려고 해서는 안 됩니다. 제가 서명한 GPL은 기계에게 제 기여를 수정할 권리를 조금도 주지 않습니다. 다음으로 해적-토크 필터를 내장하여 "사용자"에게 더 많은 "개인 제어" 기능을 제공할 수 있습니까? 마이클 Z. 2009-04-11 16:11 z
  273. 반대 이것은 더 복잡해질 것이고, 우리의 시간과 관심을 소모할 것이며, 아무런 이득도 없을 것입니다. 날짜 자동 형식으로 인한 날짜 범위를 "수정"하여 편집 전쟁이 발생하는 것을 보았습니다. 우리는 더 중요한 일들이 있습니다. --A D Monroe III (talk) 2009년 4월 11일 (UTC) 18:47 답변[답변]
  274. 반대 – 자동 포맷과 관련하여 제가 발견한 가장 큰 문제는 한 달 안에 날짜 범위를 포맷할 수 없다는 것입니다. 이는 기본 설정이 무엇이든 간에 날짜 범위를 쉽게 표시할 수 있도록 설정할 수 없다는 것입니다. 자동 포맷은 문제를 일으킬 뿐이며 아무런 이점이 없으므로 완전히 비활성화해야 합니다. MTC (talk) 2009년 4월 11일 19:43 (UTC)답장[답장]
  275. 반대 - 사용자에게 무시할 만한 가치를 부여하는 것에 대해 너무 많은 퍼지. GunnarHj (talk) 2009년 4월 11일 (UTC) 23:51 답변[답변]
  276. 위에서 언급한 많은 이유들로 반대하세요. Ti-30X (talk) 2009년 4월 12일 01:32 (UTC)답장[답장]
  277. 반대 --Julia altagracia (talk) 2009년 4월 12일 (UTC) 06:47 답변[답변]
  278. 반대 미국/영국 사용과 같은 문제를 자동 포맷하지 않는데, 왜 이런 문제가 발생합니까? 2009년 4월 11일과 2009년 4월 11일은 모두 모호하지 않으며, 내부적으로 일관성이 있는 글이라면 모든 위키백과가 그렇게 될 필요는 없습니다. 미국 사용자가 "color"를 입력하는 경우 영국 사용자가 "color"를 읽도록 자동 포맷하는 것과 같습니다. 그것은 다소 무의미해 보입니다. 소프트웨어를 수정하여 사용자로부터 아무런 조치 없이 날짜를 인식하고 자동 형식을 지정할 수 있다면(예: 위키링크, 템플릿 헤더 또는 마법 단어 또는 모든 것을 추가하는 것과 같은) 괜찮은 아이디어일 수 있습니다. 하지만 편집자들이 모든 날짜에 대괄호를 추가하거나 심지어는 전체 템플릿을 추가해야 한다는 생각은 무의미해 보입니다. --Jayron32.talk.contributes 14:54, 2009년 4월 12일 (UTC)답장
  279. 위의 논법에 따라 반대합니다. NSR77 2009년 4월 12일 (UTC) 15:52 답변[답변]
  280. 반대 그러한 기능에 무엇이 필요합니까? 이것은 수사적인 질문이 아닙니다. 답은 없습니다. 불필요하고 사소한 것들 – 기본적으로 위와 같습니다. Andre666 (talk) 2009년 4월 12일 17:15 (UTC)답장[답장]
  281. 샤인베르페르만(#233)과 월담(#244)에 따라 반대합니다. 또한, WP 편집자가 항상 익숙한 형식으로 날짜를 볼 수 있도록 돕는 것의 가치는 관련된 번거로움보다 크지 않습니다. 날짜에 혼란을 느끼는 사람은 없으며 편집자는 스타일에 관대해야 합니다. 재고(talk) 2009년 4월 12일 (UTC) 18:20 답변[답변]
  282. 반대; 너무 적은 답례를 위해 너무 많은 노력을 합니다. 진정으로 자동으로 만들거나(특별한 형식은 필요 없음) 잊어버리세요. --Spangineerws (hablame) 2009년 4월 12일 (UTC)응답하라[답변]
  283. 위의 모든 주장에 따라 결정이 필요하기 때문입니다. 숨김 T 2009년 4월 12일 (UTC) 21:11 답변[답변]
  284. — Jake Wartenberg 2009년 4월 12일 (UTC) 23:49 답변[답변]
  285. (공개 - 작년에 의견을 낸 후 사적으로 기여하겠다는 연락을 받았고, 그렇지 않았다면 이 토론을 보지 못했을 것입니다.) - 반대 - 기본 형식은 어떻게 되나요? 모든 기사를 동일한 형식으로 강제할 경우 좋지 않습니다. 영국 기사는 기본적으로 영국 기사를 사용하고 미국 기사는 기본적으로 미국 기사를 사용해야 합니다. 따라서 이 작업을 수행할 수 있는 유일한 방법은 두 개의 형식문(미국 형식문, 영국 형식문)을 갖는 것입니다. 그리고 그런 사소한 일에는 그럴 가치가 없습니다. 이유 없이 편집에 너무 많은 복잡성을 더합니다. Peter Ballard (talk) 2009년 4월 13일 (UTC) 11:10 답변[답변]
  286. 반대. 위키에는 아무런 이득이 없습니다. 게다가, 그 주장들은 설득력이 없습니다.
    #1 날짜 형식에 찬성하는 사람들은 메타 데이터를 추출하기 위해 날짜 형식이 필요하다고 주장합니다. 그건 거짓입니다.
    • 메타 데이터는 날짜 형식과 전혀 관련이 없습니다.
    • 메타 데이터는 마크업의 속성이 아닙니다. 마크업이 있는 날짜에 메타 데이터가 있고, 암시된 바와 같이 마크업이 없는 날짜에 메타 데이터가 없는 경우, 메타 데이터는 마크업의 속성이어야 합니다. 마크업에서 의미 있는 콘텐츠를 자동 생성할 수 있는 암시적인 능력은 꽤 기적적일 것입니다.
    • 날짜에 본질적인 메타 데이터는 날짜가 작성되거나 형식이 지정되는 방법과 관련이 없습니다. 날짜가 손으로 포맷되었는지, [ ], {{#formatdate}} 중 어느 것으로 포맷되었는지에 관계없이, 해당 날짜에서 잘라낼 수 있는 정보는 항상 동일하게 유지됩니다. 예를 들어, "2009년 4월 12일"이 일요일이고, 일년 중 102번째 날이라는 것 등입니다.
    #2 날짜 포맷에 대한 지지자들은 "날짜 마크업이 확인되었다"(?)고 주장합니다. "새로운 기능 개발의 중심입니다."
    • 그러한 "기능"은 아직 개발되지 않았습니다. 우리는 기화기에 투표하기를 기대할 수 없습니다.
    • 위키피디아는 거대한 샌드박스가 아닙니다. 지지자들이 새로운 기능을 개발하고 싶다면 다른 곳에서 먼저 하고 피드백을 위해 여기에 오는 것을 환영합니다.
    • 날짜 표시는 "이제 거의 6년 동안" 존재해 왔습니다. 그 동안 그것에 대해 아무것도 하지 않았습니다.
    #3 날짜 포맷에 대한 지지자들은 자동화는 날짜가 표시되는 것에 의존한다고 전제합니다. 이건 거짓입니다.
    • 특정 날짜의 모든 인스턴스를 찾는 것은 어렵지 않습니다. 그 중 극히 일부만이 표시되는 8천만 건의 히트 중에서, 그것에 대한 참조를 찾기 위해 날짜를 표시할 필요가 없다는 것은 명백해야 합니다.
    • 소프트웨어가 텍스트로 날짜를 "찾는 것"은 전혀 어렵지 않습니다. 특수 마크업은 필요하지도 않고 바람직하지도 않습니다. 합리적인 능력을 갖춘 모든 프로그래머는 날짜에 대한 텍스트를 구문 분석하는 루틴을 구성할 수 있습니다. 그러한 루틴은 다른 조합의 단어를 검색하는 루틴보다 크게 복잡하지 않습니다.
    #4 지지자들은 (서버측) "[d]ate autoformating이 더 큰 일관성을 허용한다"고 주장했습니다. 이건 거짓입니다.
    • ala[] 또는 {{#formatdate}}일을 자동으로 포맷하는 것은 편집자가 직접 날짜를 작성하는 경우에 달성할 수 있는 것보다 훨씬 더 일관성을 높이지 못합니다.
    • 기사에는 일관성 문제가 많이 있습니다. 일관성은 날짜 형식 지정 스타일에만 국한되지 않고 인용 스타일, ndash/mdash 스타일, era 스타일 및 ENGVAR 스타일도 포함됩니다.
      MOS는 이 모든 문제에 대한 지침을 가지고 있으며 날짜를 지정하는 것이 특별한 취급을 보장해야 할 이유가 없습니다.
    • 편집자는 협력적으로 일할 의무가 있습니다. 즉, 기사 편집을 시작하기 전에 추가하려는 내용이 어디로 가야 하는지 결정하는 데 시간을 할애할 수도 있습니다. 이것은 또한 기사에서 이미 사용되고 있는 스타일을 존중한다는 것을 의미합니다. 인용 스타일, 대시 스타일, 시대 스타일, ENGVAR 스타일 등 뿐만 아니라 날짜 스타일도 있습니다.
    • 기사 내에서 일관성을 보장하는 것은 서버의 작업이 아닙니다. 서버 측 날짜 형식 자동화는 편집자가 기존 날짜 형식 규칙을 무시하도록 허용하는 것입니다. 날짜 마크업 지지자들은 이것을 "더 많은 선택"을 위한 논거로 판매합니다. 하지만 그들이 진정으로 원하는 것은 "날짜 형식, engvar, 시대, 인용 스타일이 무엇이든 상관없습니까?"라고 말할 수 있는 면허증입니다. 제가 선호하는 것을 사용할 것이고, 기술이 이를 해결해야 합니다!" 말할 필요도 없이, 그것은 기술적인 관점에서 볼 때 터무니없이 사려 깊지 못한 것입니다.
    요약:. "문제"는 없습니다. 에르고, 또한 "해결책"이 필요한 것은 없습니다. 원래의 날짜 형식 솔루션(DateFormatter.php)은 날짜 형식에 대한 편집 경고를 완화하기 위해 구현되었습니다. 그동안 우리는 그와 다른 스타일의 문제와 DateFormatter에 대해 상당히 강력한 MOS 가이드라인을 받았습니다.pph는 더 이상 필요하지 않습니다. 첫 번째 해킹을 대체하기 위해 다른 해킹이 필요하지 않습니다. 이미 시행되고 있는 "현장 전체 표준"인 MOS를 준수하기 위한 편집기가 필요합니다. 만약 애논/신입자들이 그 "현장 전체의 표준"을 준수하지 못한다면, 우리는 그들의 뒤를 따라 로봇 청소를 할 수 있습니다. 기성 편집자들이 지속적으로 "현장 전체의 표준"을 준수하기를 거부한다면, 우리는 그들을 커뮤니티에서 차단해야 합니다(Arbcom의 스타일 워닝에 대한 결정은 선례입니다). MOS는 규칙이고, 공동체는 문제가 아닌 것들을 놓고 끝없는 드라마가 필요하지 않습니다. -- 풀스톱 (토크) 2009년 4월 13일 (UTC)응답하라[답변]
  287. 약자는 반대합니다. 저는 원래 더 많은 사용자 정의가 더 낫다고 생각하기 때문에 '지지'에 투표했고, 우세한 "MMM DD, YYY" 날짜 형식이 전 세계에 미국의 문화 표준이 부과되는 사례처럼 느껴지기 때문에 그것이 저를 불편하게 합니다.브리저(Phil Bridger, talk·contributes)와 다른 사람들은 실제로는 그렇지 않으며, 그렇다면 이러한 변화는 주로 대륙 데이트 협약에 대처할 수 없는 미국인들에게 매력적이라고 확신시켰습니다. 저는 또한 달력 날짜와 같은 기본적인 것을 꾸미기 위해 가벼운 마크업을 사용하는 것은 결국 새로운 편집자들에게 혼란스러운 일이며, 우리가 백과사전을 그런 식으로 받아들여서는 안 된다고 확신합니다. 이 시점에서 {{data 20090477}}과 같은 약간의 날짜 마크업은 정렬 가능한 테이블을 구축하는 작업에 여전히 유용할 수 있지만 백과사전 전체에서 날짜를 표현하는 표준 방식으로 만들어서는 안 된다고 생각합니다. 팀 피어스 (talk) 2009년 4월 13일 (UTC) 14:33 답변[답변]
나는 자동 포맷의 일반적인 개념에 대해 중립적입니다.
  1. 자동 포맷의 아이디어에 반대하지는 않지만(편집자가 소스에 입력된 날짜를 볼 수 있는 옵션이 있고, 간단한 구문을 사용한다면 다음과 같습니다.) [{30 March 2008}] 괜찮을 겁니다 {{#formatdate: 30 March 2008}} 그렇지 않을 것입니다), 저는 현재의 시스템에 반대하고, 위키백과에서 날짜 범위, M-Y-D에서 쉼표 등을 올바르게 처리하는 것이 나타날 때까지 시스템을 구현하는 것에 반대합니다. 저는 또한 단어의 자동 포맷 등으로 미끄러운 기울기를 시작하는 것을 원하지 않습니다(적어도 우리가 미국에서 영연방 영어로 기사를 번역할 때 어떤 의미의 "ass"가 사용되는지 결정할 수 있는 인공지능을 구현하기 전까지는). --A. di M. (talk) 2009년 3월 30일 (UTC) 06:18 (답변)
  2. 이 경우 메타데이터 추가를 지원하지 않습니다. 저는 단지 제 "지지하지 마세요"를 "반대"라고 부를 만큼 충분히 흥분할 수가 없어요. 제 생각에는 별로 문제가 되지 않습니다. Cnilep (talk) 2009년 3월 30일 14:28 (UTC)답장[답장]
  3. 자동 포맷의 장점은 있지만, 링크 태그를 페이지 전체에 보는 것은 미학적으로 반대합니다. 가볍게 두 의견이 충돌하는 것 외에는, 저는 그 문제에 대해 정말로 관심이 없습니다. --llywrch (talk) 2009년 3월 30일 (UTC) 16:22 (답변)
  4. 이것이 얼마나 많은 열과 빛을 끌어들였는지를 고려할 때, 저는 결과에 대해 정말로 신경 쓰지 않습니다. 결론적으로, 이것이 어떻게든 해결될 뿐입니다. Jclemens (talk) 2009년 3월 30일 (UTC) 16:26 답변[답변]
  5. 유용하게 들리지만, 우리 기사에는 이미 위키마크가 너무 많아서 경험이 부족한 사용자는 정보 상자와 참조 때문에 페이지를 편집할 수 없습니다. 내년에 새로운 GUI가 나오면 자동 포맷을 추가해도 괜찮을 것 같습니다. - Peregrine Fisher (talk) (기여) 2009년 3월 30일 (UTC) 18:08 (답변)
  6. 데이트에 대한 바보 같은 논쟁에 지쳤습니다. 다시 기사 작성과 내용의 내용 개선으로 돌아가 보겠습니다. 영화에 대하여 (토크) 2009년 3월 30일 21:28 (UTC)응답하라[응답하라]
  7. 뭐, 아직도 해결이 안 됐어요? 잠깐만요, 놀랄 일이 아닙니다. 이 문제에 필요한 것은 PHP에 능숙하고 MediaWiki에 매우 정통한 사람이 가능한 한 많은 케이스를 코드로 다루는 작업에 한 달 정도 시간을 할애하여 모델 + 테스트 케이스를 제시하는 것입니다. 그러는 동안, 저는 덜 신경 쓸 수 있었고, 그렇게 사소한 것에 대해 논쟁하는 것보다 제 시간을 훨씬 더 잘 사용할 수 있습니다. ダイノガイ!」(Dinoguy1000)2009년 3월 30일 22:16 (UTC(Dinoguy1000))답장[답장]
  8. 연결하지 마, 연결하지 마, 그게 무슨 상관이야? 예전에 저는 날짜가 꽤 파란색 링크에 있는 것을 좋아한다는 것을 알게 되었지만, 대부분의 경우 그것들은 실질적으로 도움이 되지 않습니다. 날짜를 반복해서 링크/삭제하지 않고 계속해서 기사를 쓸 수 있도록 이 토론을 끝내겠습니다. -- クラウド66807:24, 2009년 3월 31일 (UTC)답변[답변]
  9. 아무것도 아닌 것에 대한 많은 이야기 J04n (talk page) 2009년 4월 1일 (UTC)응답하라[답변]
  10. 위의 A. di M.에 따라. 루슬릭 (talk) 2009년 4월 1일 07:17 (UTC)답장[답장]
  11. 저는 사실 자동 포맷의 아이디어가 마음에 들고 그것이 앞으로 나아가는 좋은 방법이라는 것에 동의합니다. 그리고 저는 그것이 더 일관되고 전문적인 백과사전을 만들기 위해 결국 BC/BCE 및 기타 개인적인 포맷 취향에 영향을 미칠 수 있다고 생각합니다. "너무 많은 일"에 대한 우려는 말도 안 돼요. 분명히 누군가 이런 일을 하고 싶어하는 사람이 있고, 대부분의 날짜는 템플릿으로 포장되어 있고, 쉽게 AWB로 태그를 지정할 수 없는 것들도 있으니까요. 저는 오류가 거의 없는 여러 기사에 {{convert}}를 적용하여 유사한 편집을 여러 번 수행했는데, 이는 제 단점과 더 관련이 있습니다. 하지만 이것을 사용하는 것이 증명된 것 같지는 않으며, 이것을 사용하는 것에 동의하기 전에 위키랩이나 다른 곳에서 해킹하는 것을 먼저 보고 싶습니다. - ζ알파 ππερ알파 ππερν 08:08, 2009년 4월 1일 (UTC)답장[답장]
  12. 원칙적인 아이디어처럼 기사에 템플릿을 더 많이 추가할수록 위키 마크업이 편집 창을 부풀릴수록 단순 편집 위키피디아도 신입들에게 더 위협적이 됩니다. marginalia 교수님 (talk) 2009년 4월 1일 (UTC) 16:54 답변[답변]
  13. 날짜 연결에 의존하지 않는다면 날짜 자동 포맷 옵션이 있는지 여부는 어느 쪽이든 상관없습니다. --Phil Holmes (talk) 2009년 4월 2일 (UTC) 08:21 (답변)
  14. {{#formatdate}} 기능이 필수가 아닌 한 사용을 허용하는 것에 반대하지 않습니다. 등록되지 않은 사용자는 날짜가 전혀 형식화되지 않은 경우 동일한 것을 볼 수 있고 등록된 사용자는 원하는 경우 기본 설정을 사용할 수 있기 때문에 사용해도 해가 되지 않는 것 같습니다. 또한 적어도 일부 잘못된 형식의 날짜를 적절하게 포맷할 수 있는 작은 이점(예를 들어 "2009년 4월 2일"을 "2009년 4월 2일"로 변경하는 것)도 있습니다. 그냥 평범한 글로 날짜를 입력하는 편집자들을 나무라지 마세요! --R'n'B (Russ라고 불러주세요) 2009년 4월 2일 (UTC)답장[답장]
  15. 날짜가 7-3-97 또는 3-7-97이 아닌 1997년 3월 7일 또는 3월 7일로 지정되어 있다면 큰 문제가 없습니다. PRL42 (talk) 2009년 4월 2일 16:10 (UTC)답장[답장]
  16. 투표는 양말 인형을 낳습니다. Gsonnenf에 의해 추가된 서명되지 않은 이전 주석 (talkcontributes)
  17. 저는 중립적입니다. 궁극적으로 저는 별로 신경 쓰지 않습니다. 하지만 자동 서식은 일반 독자가 아닌 등록된 편집자에게만 유용하기 때문에 반대 쪽으로 기울고 있습니다. Bendono (talk) 2009년 4월 3일 18:09 (UTC)답장[답장]
  18. 저는 경쟁하는 유효한 이해관계의 균형을 보고 어떤 것이 우세하든 따라갈 수 있기 때문에 중립적입니다. 그러나 저는 날짜 형식을 삭제하면 일부 날짜에 대한 특별한 마크업이 필요하지 않다는 많은 응답의 하위 텍스트에 있는 증거의 개념에 강력하게 반대합니다. 정보 상자와 같은 좁은 맥락에서 사용되며, 현재 마이크로포맷 정보를 내보내는 것이 유일한 목적인 템플릿 제품군이 있습니다. 메타데이터라는 용어를 사용하여 이 정보를 검색 등과 연결하는 잘못된 발언이 많이 있었습니다. 위키피디아는 또한 좌표 마이크로포맷 데이터를 방출하며, 인터넷 지도 응용 프로그램과의 상호 작용을 허용하는 것과 같은 방식으로 날짜/시간 템플릿은 시간 데이터를 이해하는 인터넷 응용 프로그램과의 상호 작용을 허용합니다. 그런 의미에서 저는 위에서 표현한 한계리아 교수와 페레그린 피셔 교수의 의견에 동의하며 편집 텍스트가 템플릿이나 다른 복잡한 마크업으로 불필요하게 어수선해서는 안 된다고 믿습니다. 심지어 평범한 위키텍스트도 중요한 장벽이며 모든 사람이 편집자라는 핵심 원칙을 방해합니다.-JJMesserly (talk) 2009년 4월 4일 (UTC) 16:37 답변[답변]
    중립, 바로 위에서 훌륭한 포인트를 만드는 JJ Messerry에 따라. 어느 쪽이든 상관없지만, 위키백과 기사들이 편집란에서 볼 때 너무 복잡해지는 것에 동의합니다. 숨김 T 14:02, 2009년 4월 5일 (UTC)*부록 대화 페이지를 보고 합의가 무엇인지에 대한 모든 터무니없는 주장을 보았습니다. 이번 일을 해결하고 모든 정당이 기꺼이 받아들이기를 바라는 마음으로 어느 쪽이 가장 큰 더미를 차지하는지 제 투표를 추가해 주시기 바랍니다. 숨김 T 2009년 4월 6일 10:14 (UTC)답글[답글]
  19. 마이, 마이. 나를 상관없는 무리에 포함시키십시오. 저는 이 토론의 결과에 관계없이 다시는 다른 날짜를 링크하지 않을 것입니다. 저는 WP 내 검토 프로세스의 요구에 따라 자동 포맷을 위한 WP 날짜를 연결하는 데 많은 지루한 시간을 보냈습니다. 저는 그것이 정책으로 끝난다면, 다른 누군가가 그것을 하는 데 시간을 낭비하는 것을 기뻐할 것이라고 확신합니다. 나, 별로. 그래도 의견을 낼 수 있어서 기쁩니다.--IvoShandor (talk) 2009년 4월 6일 (UTC) 06:24 (답장)
    내 말은, 내가 아무것도 할 필요가 없는 한 나는 우리가 무엇을 하든 상관없다는 것입니다. 따라서 중립입니다.--IvoShandor (talk) 2009년 4월 6일 (UTC) 13:20 답변[답변]
  20. 중립 - 저는 그것이 어떻게 작동하는지 거의 이해하지 못합니다. Deb (talk) 2009년 4월 6일 (UTC) 18:05 답변[답변]
  21. 중립 - 제가 관여할 필요가 없다고 생각합니다. prashantns (talk) 2009년 4월 8일 (UTC) 06:00 답변[답변]
  22. 숫자로 축약되지 않고(어쨌든 자동 포맷은 분리할 수 없음), 월 단위로 철자가 표기되어 있는 한, 혼란을 초래할 실질적인 위험은 없습니다. 동시에 사이트에 과도한 부담을 주지 않는 한 사람들에게 디스플레이 옵션을 제공하는 것은 나쁜 일이 아닙니다. Ham Pastrami (talk) 05:57, 2009년 4월 10일 (UTC)답장[답장]
  23. 대부분의 독자들은 로그인하지 않을 것이기 때문에 날짜를 자동으로 포맷하는 것은 큰 의미가 없습니다. 그러나 많은 사람들이 2009년 1월 1일과 2009년 1월 1일의 차이를 제대로 인식하지 못할 것이며 일부 페이지에서 이 구문을 사용해도 상관없습니다. Tra(Talk) 2009년 4월 11일 10:37 (UTC)답장[답장]
  24. 저는 사용자의 선호에 따라 자동 포맷이 가능한 ISO 8601(yyy-mm-dd)을 채택하는 것을 선호하는 경향이 있습니다. 산문에서 널리 사용되지는 않지만(그리고 반대를 권장한다고 생각합니다), 직관적이고 타자 치기 쉽습니다. 저는 날짜를 쓰기 위해 편집자를 템플릿으로 만드는 것에 반대합니다. 저는 트리비아인 파란색 연결 날짜에 강력하게 반대합니다. 따라서, 제가 선호하는 것이 테이블에 있는지 확신할 수 없기 때문에 자동 포맷을 지지해야 할지 반대해야 할지 잘 모르겠습니다. 플레처 (talk) 2009년 4월 11일 14:21 (UTC)답장[답장]
  25. 원칙적으로 (지금까지와 같이) 자동 연결을 포함하지 않고 옵션이 모든 판독기로 확장된다면 자동 포맷을 지원하는 경향이 있습니다. 지난 여름 이 논쟁이 다시 시작된 이래로, 날짜 연결이 저하되는 두 가지 주요 이유는 "푸른 바다"와 특히, 등록된 사용자인 극소수의 독자만이 선호하는 형식으로 날짜를 볼 수 있다는 사실입니다. 게다가, 이 옵션을 사용하면 등록된 사용자(가장 활동적인 편집자의 상당 부분을 차지하는)가 특정 기사의 날짜 형식이 얼마나 엉망인지 인식하지 못했으며, 이는 대다수의 독자가 실제로 보고 있는 것입니다. 모든 독자들이 선호도를 설정할 수 있는 개발자 제작 솔루션에 대한 상당한 지지가 항상 존재했습니다. 물론, 이것은 혼합 형식의 혼란을 해결하지는 못하겠지만, 적어도 독자들이 이러한 문제를 볼 필요가 없도록 선택할 수 있게 해줄 것입니다. 모든 독자가 날짜 자동 서식을 사용할 수 없는 한, 편집자는 정리가 필요한 내용을 알기 위해 원시 텍스트 형식에 의존해야 합니다. 그렇다면 문제의 핵심은 그러한 자동 포맷 파서 또는 템플릿 함수의 코딩이 얼마나 해결 가능한지입니다. 저보다 더 지식이 많은 사람들이 그 문제에 대해 양쪽에서 빠져드는 것 같습니다. 그래서 그것을 어떻게 달성할 것인가에 대한 구체적인 제안이 있기 전까지는, 이 여론조사 전체가 무딘 상태입니다. 아스카리 마크 (Talk) 2009년 4월 12일 00:50 (UTC)답장[답장]
자동 서식 지정에 대한 설명
  • 이 섹션이 링크가 아니라 자동 포맷에 관한 것임을 사람들에게 확신시키기에 얼마나 크고 대담하며 번쩍이는 편집 알림이 충분합니까? 아니면 "링크"라는 단어에 OverseFilter 경고가 필요합니까? 아노미⚔ 2009년 3월 30일 (UTC) 00:12 답변[답변]
  • 위의 아무도 이 둘을 혼동하지 않은 것으로 보입니다. 오공자(talk) 2009년 3월 30일 (UTC) 01:56 답변[답변]
  • 제가 아는 사람의 말을 인용하자면, "누군가가 바보 같은 주장을 하지 않는저는 대답하지 않을 생각이었습니다. 축하드립니다." 오공자(talk) 2009년 3월 30일 (UTC) 03:21 답변[답변]
  • 와우. 저는 현재 이론적 근거에서 링크를 언급하는 3명(Awadewit, Bishonen, Bzuk), 이론적 근거를 제시하지 않는 3명(Donald Albury, Juliancolton, Chrisomingtang), 그리고 이에 대해 혼동하고 있음을 시사하지 않는 이론적 근거를 제시하는 29명(Awadewit, Bishoen, Bzuk)을 보고 있습니다. 언제부터 3시 29분이 다수인가요? 아마도 당신은 혼란스럽고 이것이 마크업 없이 자동 포맷에 관한 것이라고 생각합니까? 그런 다음 위의 "날짜 자동 포맷이란?"을 읽어 보십시오. 옵션으로 제시되지 않습니다. --Hans Adler (talk) 2009년 3월 30일 (UTC) 08:26 (답변)
  • 아서 루빈은 수학자이므로 "다수"가 무엇을 의미하는지 알고 있을 것입니다. --otherl leftNo, really, other way . . . 2009년 3월 31일 (UTC)03:38 (답변)
  • 그리고 이미 그렇게 많은 것들이 주어졌는데 왜 제가 또 다른 근거를 제시해야 합니까? 이것은 정책을 불러오는 주장의 무게가 결정적이어야 하는 AfD와 같은 것이 아니라, 선호도 여론조사입니다. -- 도널드 앨버리 2009년 3월 30일 (UTC)응답하라
  • 과거에도 여러 차례 의견을 밝혔기 때문에 굳이 근거를 제시할 필요가 없다고 생각합니다. 이것은 제목에서 알 수 있듯이 여론조사입니다.줄리안콜튼Talk 2009년 3월 30일 (UTC) 19:22 답변[답변]
  • 이것은 여론조사이며 이미 다른 사람들이 많은 이유를 제시했다는 것에 동의합니다.크리스! 2009년 3월 30일 (UTC) 20:24 답변[답변]
  • 죄송합니다, 악의는 없었고 물론 어떤 근거도 완벽하게 괜찮습니다. 유일한 문제는 일부 편집자들이 혼란스럽다는 것을 증명하는 합리적인 근거를 제시하는 상황에서("관련 없는 파란색 링크의 바다가 싫어서"), 그렇지 않았다면 어떻게 투표했을지 전혀 알 수 없는 근거 없는 모든 투표는 여론조사 결과를 좋아하지 않는 사람들에 의해 잠재적으로 폐기될 수 있다는 것입니다.
  • 저도 이것이 걱정됩니다. 제안서가 낙선이 되면 그렇게 되겠지만, 여전히 많은 수의 편집자들이 구현 내용에 대해 잘못된 인상을 받고 있었기 때문에 낙선이 된다면 정말 부끄러운 일입니다. 팀 피어스 (talk) 2009년 3월 30일 13:13 (UTC)답장[답장]
  • 많은 사람들이 수백만 개의 날짜를 표시하는 것이 많은 작업이 필요하다고 생각하는 것처럼 보이지만 해당 날짜에서 마크업을 제거하는 것은 전혀 작업이 되지 않는 이유는 무엇일까요?-Jeff(talk) 01:09, 2009년 3월 30일 (UTC)답장[답장]
  • 봇은 날짜를 전후하여 이중 사각형 괄호를 쉽게 인식하고 제거할 수 있습니다. 날짜 부호화(특히 복잡한 부호화)를 추가하려면 상황에 따라(인스턴스 단위) 수행해야 합니다. HWV2580 1:53, 2009년 3월 30일 (UTC)답장[답장]
사실, 저는 봇이 날짜를 인식하고 사소한 것에 포함시키기만 하면 기본적인 마크업의 대부분을 할 수 있다고 장담합니다. 어떤 형식을 사용할지에 대한 실제 선택은 인간의 개입이 필요하지만, 그것은 특정 날짜에 대한 마크업과 분리될 수 있습니다. Gavia immer (talk) 2009년 3월 30일 02:53 (UTC)답장[답장]
위의 내용에 동의합니다. 봇은 정규 표현식을 사용하여 표시 여부에 관계없이 날짜를 쉽게 인식할 수 있어야 합니다.-Jeff(talk) 03:13, 2009년 3월 30일 (UTC)답장[답장]
(위 두 게시물에 대하여) "대부분의 작업이 봇으로 이루어질있습니다"라는 편집 코멘트가 핵심입니다. 가장 정의된 것은? 또한 "어떤 형식을 사용할지에 대한 실제 선택은 인간의 개입이 필요하다"는 것은 프로세스의 속도를 늦춘다는 측면에서 와퍼입니다. 어쨌든, 날짜 형식의 봇 제거가 (원래 게시물로 돌아가기 위해) 사소한 것이라는 기본적인 점은 변경하지 않습니다. HWV25803:23, 2009년 3월 30일 (UTC)답장[답장]
포맷 컨트롤에서 포맷 가능한 날짜 인식을 분리하면 큰 문제가 되지 않습니다. {{DEFAULTEDATEFORMAT}}와 같이 작동하는 {DEFAULTEDATEFORMAT}(또는 이름은 무엇이든) 파라미터를 추가하면 기본 날짜 표시 형식을 제어할 수 있습니다. 그런 다음 해당 날짜의 기본 표시 형식을 설정하는 옵션을 사용하여 실제로 날짜를 설정하기 위해 별도의 마크업을 추가할 수 있습니다. 스틱 비트는 직접 인용문의 날짜를 자동 형식으로 지정해서는 안 되기 때문에 봇 솔루션은 해당 날짜를 생략해야 하는 시기를 인식해야 합니다. 이것을 90%라도 제대로 맞춘 봇은 인간 편집자가 해결해야 할 일을 거의 남기지 않을 것입니다. Gavia immer (talk) 2009년 3월 30일 04:20 (UTC)답장[답장]
위의 답변을 통해 원래 질문에 대한 제 최초 답변의 유효성을 확인했습니다(원래 질문을 기억하십니까?). 이것을 어디선가 대화 페이지에 올려주십시오. 우리는 이런 종류의 문제에 대해 몇 달 동안 논의해 왔습니다. 감사해요. HWV2580 06:10, 2009년 3월 30일 (UTC)답장[답장]
  • "미등록 사용자에게 날짜가 일치하지 않음"을 쉽게 수정할 수 있으므로 이를 근거로 반대하는 것은 오히려 잘못된 것입니다. 그리고 편집 전쟁은 자동 포맷과 함께 마법 단어가 없을 때만큼 자주 발생하지만 전사들이 기사 전체의 날짜를 엉망으로 만들기 때문에(그리고 매번 일부가 누락될 수도 있습니다) 더 심각할 것입니다. 아노미⚔ 2009년 3월 30일 (UTC) 02:48 답변[답변]
    • 편집-워링 방지? 위에서 한 두 명의 편집자가 기사에 대해 어떤 형식을 선택할지에 대한 편집 전쟁을 피하기 위해 자동 포맷이 필요하다고 제기한 생각은 잘못된 나무를 짖는 것이라고 생각합니다. 네, 원래 시스템은 이 문제에 대한 마찰에 대한 대응이었지만, 2003년은 커뮤니티에 초기 단계였고, 우리는 날짜 형식이나 ENGVAR 철자 모두에 대한 적절한 규칙을 세웠습니다. 우리는 이제 두 가지 모두(MOSNUM, MoS)에 대해 잘 확립된 관행을 가지고 있으며, 이는 모든 면에서 매우 성공적입니다. Tony(talk) 2009년 3월 30일 08:41 (UTC)답장[답장]
      • 그럼에도 불구하고 편집자가 원하는 형식으로 날짜를 입력하고 시스템에서 독자가 선호하는 형식으로 자동 포맷할 수 있도록 하는 것만큼 간단하지는 않습니다. 체인의 어느 시점(editing/읽기)에서 선호하지 않는 날짜 형식을 사용하거나 볼 수 있는 사람이 있을 것입니다.Lock Coletc 10:56, 2009년 3월 30일 (UTC)답장[답장]
      • 날짜 형식에 대한 이러한 "잘 확립된 관행"과 관련하여, 만약 정말로 "매우 성공적"이라면, 왜 위키피디아의 최고 기술 책임자는 사이트 전체에서 하나의 일관된 형식만을 사용하도록 지침의 개정을 요구한 것일까요? --Ckatzchatspy 2009년 3월 30일 (UTC)응답하라[답변]
        • 저는 날짜에 대한 모노 형식을 원하는 것으로 기록되어 있습니다. 안타깝게도 저는 소수입니다. 사람들이 WP를 믿고 있기 때문에 그런 일은 일어나지 않을 것입니다.ENGVAR은 작동하기 때문에 우리는 그것을 가지고 살아야 합니다. 날짜 자동 포맷을 하는 것은 방금 산 새 언더사이즈 신발에 맞게 발의 일부를 잘라내는 것에 비유될 수 있습니다(즉, 바보 같은 동작을 보상하는 실수를 하지 마십시오). 오공자(talk) 2009년 3월 30일 (UTC) 13:51 답변[답변]
      • 위의 언급 당시 편집 워링의 해결책으로 자동 포맷을 언급한 사람은 단 한 명뿐이었습니다(그리고 막연하게는 "이 사건에 도움이 되었을 것입니다"). 특히 기사의 기본 형식을 설정하기 위한 마법 단어로 자동 형식을 지정하면 기본 형식 설정에 대한 편집 경고가 직접적으로 발생한다고 주장하는 "oppose"가 있었습니다. 저는 편집 전쟁 방지를 위해 자동 포맷이 필요하지 않다는 것에 동의합니다. 비록 그렇게 하면 일부 편집 전사들이 WP 적용 방법을 무시하거나 싸우는 것을 막을 수 있습니다.ENGVAR, 저는 개인적으로 그것을 주요한 운전 이유라기보다는 부작용이라고 생각합니다. 아노미⚔ 2009년 3월 30일 (UTC) 12:05 답변[답변]
  • (위의 중립 1번에 대한 응답으로) "{d 30 2008년 3월}}의 행을 따라가는 것이 충분히 간단할까요? 이름이 훨씬 간단한 템플릿에서 "#formatdate" 기능을 쉽게 호출할 수 있다는 점을 염두에 두십시오. --Ckatzchatspy 06:26, 2009년 3월 30일 (UTC)답장[답장]
    수백만 번이나 그런 템플릿이 호출되는 것을 고려하면 서버 리소스가 엄청나게 낭비될 것입니다. 하지만 예를 들어 #formatdate 함수를 #d로 이름을 바꾸라고 요청할 수도 있습니다. --A. di M. (talk) 2009년 3월 30일 (UTC)08:48 (답장)
  • 내 이론에 근거한 확장. 자동 포맷의 논거 중 하나는 "일관된 날짜 형식을 제시하는 것"입니다. 일관성을 가져야 한다고 생각하지만, 자동 포맷이 앞으로 나아갈 길은 아니라고 생각합니다. 개인적으로, 저는 모든 기사가 상당히 국제적인 스타일을 사용하기를 바라지만, 저는 사람들이 그런 일이 일어나기에는 무의미한 것에 대해 너무 논쟁하는 것을 좋아하지 않을까 걱정됩니다. 람보의 복수 (How do I hell?) 2009년 3월 30일 (UTC) 13:36 답변[답변]
  • 그건 자동 포맷을 위한 논쟁이 아닌가요? 여기서 어떤 형식을 사용할지에 대해 논쟁할 필요가 없는 시스템이 있으며, 이는 간단한 소프트웨어 솔루션입니다.Lock Coletc 13:44, 2009년 3월 30일 (UTC)답장[답장]
  • 아니, 그건 아니야. 대부분의 위키피디아 독자가 선호하는 IP를 선택할 수 없는 경우 자동 포맷은 좋은 옵션이 아닙니다. IP가 다양한 형식으로 엉망이 되는 것을 방지하는 유일한 방법은 보이는 것을 선택하는 것입니다. 그렇게 하면 모든 사람을 위한 스타일을 선택하거나 모든 날짜를 하나의 형식으로 완전히 표준화할 수 있습니다. 람보의 복수 (How do I hell?) 2009년 3월 30일 14:23 (UTC)답장[답장]
  • 현재 제안의 일부는 IP 사용자를 포함하여 선호도를 설정하지 않은 모든 사용자를 위한 위키피디아 전체 기본 형식 설정(대부분 DMY)과 특정 기사가 WP에 따라 적절한 경우 기본값(예: MDY)을 변경할 수 있도록 마법 단어를 제공한다는 것입니다.ENGVAR. 그러면 사용자 환경설정은 해당 사용자의 기본값을 재정의합니다. 이것은 몇 번이고 반복된 말이기 때문에 반대자들이 IP 사용자들이 어떤 종류의 실수를 볼 것이라고 계속 주장하는 이유를 잘 이해할 수 없습니다. 또한 모든 IP 사용자가 날짜 선호도를 가짜로 설정할 수 있어야 한다는 주장을 발견했습니다. 계정을 등록하는 등 누구나 쉽게 설정할 수 있는 방법이 있기 때문입니다. 아노미⚔ 2009년 3월 30일 (UTC) 15:05 답변[답변]
  • 그러나 모든 사용자에게 일관성을 유지하려면 페이지의 모든 날짜를 코드화해야 합니다(다양한 기본 설정에 따라 적절하게 렌더링하려면). "모든 날짜"의 문제는 WP에서 찾을 수 있는 모든 유형의 날짜 형식을 탐지하기 위해 필요한 규칙을 정의하는 것이 매우 어렵다는 것입니다. 날짜 범위와 잘라낸 날짜는 두 가지 예에 불과하지만, 미국 날짜 형식에서 쉼표를 정확하게 감지하는 것도 어렵습니다. 이러한 문제들은 몇 달 동안의 논쟁에도 불구하고 여전히 해결되지 않고 있으며, 문제를 입증하는 많은 예를 쉽게 찾을 수 있습니다. "지지"에 투표하는 많은 사람들은 관련된 기술적 문제를 알지 못합니다. (우연히, 저는 그들을 비난하지 않습니다. 왜냐하면 이러한 문제들은 한동안 토론에 참여하지 않았던 사람들에 의해 쉽게 이해되지 않기 때문입니다.) HWV25800:46, 2009년 3월 31일 (UTC)답장[답장]
  • 안녕하세요, 저는 컴퓨터 프로그래머입니다. 너는? 제가 묻는 이유는 당신이 "WP에 있는 모든 다양한 유형의 날짜 형식을 탐지하기 위해 필요한 규칙을 정의하는 것이 매우 어렵다"고 주장하기 때문인데, 이는 실제로 무엇을 이야기하는지 모르는 사람이 할 말이라는 인상을 줍니다. 실질적인 "감지"가 필요한 것은 아닙니다. 날짜 범위, 잘라낸 날짜, 뒤에 따라오는 쉼표 등을 지정하기 위한 구문만 제시하면 됩니다. 예를 들어, {{#format date:2009년 1월 1일/2일}}는 잘라낸 날짜의 형식일 수 있으며, 활성 형식에 따라 {{#format date:2009년 1월 1일-10일} 또는 {{#format date:2009년 1월 1일-10일}} 또는 {{#format date:2009년 1월 1일-10일}}는 날짜 범위를 입력하는 형식일 수 있습니다. 그리고 적절한 출력(사람들이 원한다면 "2009년 1월 1일 - 1월 10일"과 "2009년 1월 10일" 스타일의 출력을 선호할 수도 있습니다.) 조금만 더 노력하면 (명확하지 않은) 출력 형식도 입력으로 받아들일 수 있습니다. 뒤에 오는 쉼표의 필요성은 {{#format date:2009년 1월 1일}} 또는 {{#format date:2009년 1월 1일}. 제가 개인적으로 보고 싶은 다른 것은 "{#formatabulardate}" 기능입니다. 따라서 표와 목록에서 날짜를 2009-01-01 대 2009년 1월 1일 대 2009년 1월 1일로 보고 싶은 사람들은 이 기능에 대한 선호도를 설정할 수 있습니다. 그 중 어떤 것도 하는 것은 특별히 어려운 일은 아니지만, WP의 지적을 받을 정도로 모든 것에 끝이 없이 반대할 사람들로 토론이 가득 차 있는데(꼭 당신은 아니지만, 이것을 개인적으로 받아들이지 마세요) 왜 누군가가 신경을 써야 합니까?POINT? 아노미 2009년 3월 31일 (UTC) 12:26 답변[답변]
  • 사실, 저는 프로그래머입니다(그리고 당신의 질문은 당신이 지난 몇 달 동안 토론을 따르지 않았다는 것을 모든 사람들에게 나타냅니다). (여기서) 자동 포맷 사양을 확보하기 위해 적극적으로 노력한 사람은 저뿐이었지만(위와 유사한), 아무런 제안도 받지 못했습니다. 당신은 위의 모든 예시들이 이미 비슷한 제안들로 넘쳐나는 화분, 그러나 지금까지 지역사회에 영양가 있는 것(또는 최소한의 먹을 수 있는 것)을 제공하지 못한 화분에 단순히 던져질 것이라는 것을 이해하고 있습니다. "페이지의 모든 날짜는 코드화되어야 합니다."라고 제 지적에 답하지 않으셨기 때문에, 저는 독자 분이 그것을 이해하셨고, 그것에 찬성한다고 생각합니다. 700개가 넘는 날짜(다양한 형식)를 가진 이 페이지와 같은 페이지를 고려하여 포맷을 모든 날짜({#format date:8 1705년 1월}과 유사)에 적용하는 것은 상당한 작업(실행 가능성에 대한 분석이 없는 작업)입니다. "끝없이 모든 것에 반대할 사람"이라고 말씀하시는 분들은 사실 이 모든 문제들을 고민하고 평문을 이용하여 날짜를 입력하는 것만으로도 모든 중요한 문제들이 해결되고, 더 넓은 편집 커뮤니티를 위한 구문적 복잡성이 없다는 생각에 도달한 분들입니다. 게다가, 저는 (적어도 기능적인) 사양 없이 코딩을 시작하는 것이 부적절하다고 생각하는 (그리고 전혀 전문적이지 않은) 프로그래머 그룹에 속해 있습니다. 우리가 현재 혼란에 빠진 이유의 상당 부분은 공동체의 합의는 고사하고 규격이 없는 (잘 의도된) 코드 도입 때문입니다. HWV258 23:19, 2009년 3월 31일 (UTC)답장[답장]
  • 물론 저는 그 논쟁을 따르지 않았지만, 어떤 사람들은 상황을 연못에서 진주를 찾아 다이빙하는 것과 유사하게 만들었습니다. 그러나 프로그래밍에 정통하다고 하니 위 문단에서 제기한 문제를 코드가 해결하는 것이 그렇게 어렵다고 주장할 수 있는지 이해할 수 없습니다. 조지 프리드리히 헨델의 작곡 목록에도 특별한 문제는 없습니다. 물론 모든 것을 표시하려면 인간의 주의가 필요할 수도 있습니다. 하지만 잘 작성된 포맷 작업에 문제를 일으킬 만한 것은 아무것도 보이지 않습니다. 아니면 누군가가 포맷 작업을 조금 해야 할 것을 걱정하고 있는 것일까요? "끝없이 모든 것에 반대할 사람들"에 대해서는, 우리가 다른 사람들에 대해 이야기하고 있거나 우리의 견해가 너무 반대하기 때문에 우리는 그 문제에 대해 결코 합의에 이르지 못할 것입니다. 아노미⚔ 02:10, 2009년 4월 1일 (UTC)답장[답장]
  • 는 "코드가 문제를 해결하는 것이 그렇게 어렵다"고 주장하지 않았습니다. 오히려 문제를 명시하는 것이 애초에 불가능해 보입니다. HWV2580 4:18, 2009년 4월 1일 (UTC)답장[답장]
  • 로봇이 무엇을 할 것인지 지정하는 것이 어떻게 불가능합니까? 봇은 기존에 있거나 새로운 사용자가 입력한 일반 날짜를 찾아 자동 형식 괄호 안의 표준 형식으로 변환합니다. 널리 사용되는 양식에서 날짜를 찾는 정규식이 이미 존재합니다. 07-03-02와 같이 날짜가 모호할 경우 위키: 페이지 또는 다른 방법을 통해 위키놈을 알릴 수 있으며, 이를 수동으로 수정할 수 있으므로 위키백과에서 모호성을 제거하는 기존 작업에 도움이 됩니다. 봇의 범위와 구현은 완전히 명확해 보입니다. 기존 프레임워크에서 5시간 코딩 상단일 수 있습니다.Gsonnenf (talk)
로봇은 꽤 보수적이어야 할 것 같습니다. 날짜 형식에 대한 구문을 고안하는 데 한 시간 정도 걸립니다. 그렇게 한 후, 모호한 날짜를 정하는 방법 또는 최소한 그 날짜가 모호하다는 것을 발견하고 그렇게 표시하는 방법. 그런 다음 "2009년 4월" 또는 "2009년"과 같은 부분 날짜. 2,009km(1,248마일)입니다. 그런 다음 남아야 하는 날짜를 인용했습니다. 그럼 아마도 프랑스 혁명 달력일 것입니다. 그것은 사소한 것이 아닙니다. 저는 지지하지만 봇보다는 인간의 마크업에 맡기는 것이 최선이라고 생각합니다. 확실히, 표시된 후 로봇에게 정보를 수집하도록 하세요, 저는 모두 그것에 찬성합니다. 하지만 날짜가 무엇인지 추측하지 마십시오. 사이먼트루 (talk) 2009년 4월 8일 03:41 (UTC)답장[답장]
저는 봇이 보수적이어야 한다는 것에 동의합니다. 일부 날짜는 날짜 자동 형식과 함께 사용되지 않는 것으로 알고 있으므로 틀린 경우 수정하십시오. "데이트 형식에 대한 구문을 고안하는 데 한 시간 정도 걸립니다."라고 말할 때, 파서가 이를 인식하도록 하는 방법을 생각하는 것을 의미합니까? 그렇다면 이 문제는 이미 공개된 해결책이 있습니다. 중첩 따옴표 인식도 파서 문제 해결입니다. 인식된 날짜에서 형식의 모호성을 결정하기 위한 논리 코드는 if/then/ and 문처럼 간단합니다. 이것은 여전히 단순한 작업처럼 보입니다. 과학 분야마다 의미가 다르기 때문에 "사소한"이 무엇을 의미하는지 확신할 수 없습니다. 최신 구문 분석 라이브러리나 구문 분석 노출이 없는 새로운 코더나 새로운 코더가 이 문제를 어떻게 복잡한 것으로 볼 수 있는지 알 수 있었습니다. 위키피디아의 많은 코더들이 알고 있는 적절한 지식만 있다면, 그 해결책은 구현하기 쉽습니다. 사람 확인이 있는 봇의 보수적인 날짜 변경을 선호합니다. 이것은 인간의 부담과 시간 제약을 완화할 것입니다. 페이지에서 날짜를 수동으로 확인하는 데는 아마도 5-10초가 걸릴 것이며, 변경 순서를 수행하는 데는 약 5-10배의 시간이 소요될 수 있습니다(서버 조건에 따라).Gsonnenf (talk)
  • "로봇이 무엇을 할 것인지 지정하는 것이 어떻게 불가능합니까?"—이것은 원래 지점에서 헤매는 것입니다(즉, 봇에 대해 언급하지 않았습니다). 제 요점을 다시 읽어보시기 바랍니다. HWV2580 2:00 2009년 4월 9일 (UTC)답장[답장]
  • 저는 당신의 요점을 다시 읽고 그것들을 찾아냅니다. 대다수의 날짜 양식은 쉽게 알아볼 수 있습니다. "페이지의 모든 날짜를 코드화해야 한다"는 귀하의 진술에 동의하지 않습니다. 의도적으로 모호하거나 잘 형성되지 않은 날짜 양식(예: 197x년도)은 수동으로 명확히 하거나 단독으로 남겨야 합니다. 자동 포맷은 잘 형성된 날짜에만 적용하면 됩니다. 명확하게 인식할 수 있는 날짜(1973년 1월 16일, 10/22/1001)는 사람과 파서 모두가 쉽게 인식할 수 있었습니다. 따라서 이 경우 "모든 유형을 탐지하는 데 필요한 규칙을 정의하는 것이 더 이상 어렵지 않습니다." "날짜 범위와 잘린 날짜는 두 가지 예에 불과하지만 미국 날짜 형식에서 쉼표를 정확하게 감지하는 것도 어렵습니다."라는 설명은 정확하지 않습니다. 구문 분석기와 정규 표현식을 사용하여 쉽게 식별할 수 있습니다. 위의 언급은 또한 봇에 대해 매우 암시적이며, 이는 "봇에 대해 언급하지 않았습니다"라는 귀하의 진술과 모순됩니다. 물론 인간이 "미국 날짜 형식의 쉼표를 감지하는 데 어려움을 겪을 것"이라는 뜻이 아니라면, 이것은 완전히 말도 안 되는 소리입니다. 따라서 위와 같은 제 주장은 원래의 요점을 벗어나지 않습니다. 물론 당신이 위의 진술에서 원래 지점에서 헤매지 않는 한. 그렇다면 자신의 원론적인 주장을 제시하고 '원론적인 주장에서 벗어나지 않는 주장'을 제시해 주시기 바랍니다.Gsonnenf (talk)
  • "페이지의 모든 날짜가 코드화되어야 한다는 당신의 말에 동의하지 않습니다."라고 하면, 저는 우리가 서로 다른 것에 대해 이야기하고 있다고 생각하게 됩니다(그리고 당신의 반대는 아마도 당신이 지난 몇 달 동안 토론을 따르지 않았다는 것을 의미할 것입니다). 모든 날짜를 코드화하는 것에 대한 요점은 적어도 하나의 코드화된 날짜가 포함된 기사에서 날짜 렌더링 일관성을 보장하는 것이 불가능하지만 기사에 모든 날짜가 코드화된 것은 아니라는 것입니다. 기사에 모든 날짜를 코드화하거나 아무 것도 코드화하지 않는 것은 모든 사람이 분명히 알고 있습니다. 페이지 전처리기가 모든 날짜를 실시간으로 구문 분석(및 재포맷)할 수 있기 때문에 코딩이 필요하지 않다고 제안하는 경우, 아마 코딩을 처음 하는 것일 것입니다. 이러한 현재의 RfC는 봇 활동과 관련이 없습니다(이러한 RfC가 완료된 후에 논의가 이루어질 것입니다). HWV25800:16, 2009년 4월 12일 (UTC)답장[답장]
  • (특별한 순서 없이) 월/일/년 및 월/일 및 기타 모든 양식을 포함하는 날짜는 자동 서식에 따라야 한다는 것을 "모든 사람이 명확하게 이해했다"고 제안하는 것처럼 들립니다. 이는 "날짜 형식이란?"이라는 정의 아래 MDY/DMY 형식만 다루는 자동 형식 배경문과 일치하지 않습니다. Summary and Pro의 전체 기본 설명문에는 "DMY/MDY" 형식만 언급되어 있습니다. 사기꾼의 섹션은 제안서의 가능한 확장으로 유형 MD의 불완전한 날짜 형식을 지정하여 "(dmy/md가 추가된 경우에도 키 입력 횟수를 두 배로 늘립니다)"라고 초기 범위에 속하지 않음을 보여줍니다. 따라서 "날짜를 코드화하는 것은 모든 사람이 명확하게 이해할 수 있다..."라고 말할 때, 날짜의 정의에 부분 날짜를 포함시킨다면 기본 배경 설명과 모순됩니다. 모든 사람들이 모든 날짜, 포함된 부분 날짜를 암호화하거나 아예 암호화하지 않아야 한다고 인식하고 있다고 주장함으로써 잘못된 딜레마를 통해 논쟁을 구성하고 있는 것 같습니다. 물론 이는 자동 포맷에 대한 기본 설명에서 알 수 있듯이 사실이 아닙니다.Gsonnenf (talk)
  • (지난 몇 달 동안의) 토론의 역사를 읽어보시기 바랍니다. 독자 분은 고립된 상태에서 "논쟁"하고 있으며, 분명히 모든 배경 정보를 손에 쥐고 있지 않습니다. 이 모든 것이 가려졌고, 저는 이전에 여러 번 (죽을 때까지) 가려졌던 것을 여기서 반복하고 싶은 욕심이 없습니다. 토론의 배경을 이해하기 위해 더 많은 도움이 필요하다면, 다른 포럼에서 논의하시기 바랍니다.중요한 사항에 대해 신속하게 알려드릴 수 있도록 기꺼이 노력하겠습니다. 건배. HWV258 22:56, 2009년 4월 13일 (UTC)답장[답장]
  • 기능이 표준 기본값을 제공하기 때문에 IP는 다양한 스타일을 얻지 못할 것입니다. 또한 개발자들은 IP가 선호도를 설정할 수 있도록 자바스크립트를 사용하는 것을 언급했지만, 아직 그 솔루션에 대해 연구한 개발자는 없습니다.Ost (talk) 2009년 3월 30일 (UTC) 15:06 답변[답변]
  • *sigh* 만약 당신이 내 마지막 게시물을 실제로 읽는다면, 나는 IP가 스타일의 엉망이 될 것이라고 주장한 적이 없습니다. 저는 그들이 그것을 얻는 것을 방지하는 유일한 방법은 그들을 선호하는 것을 선택하는 것이라고 말했습니다. 그런 다음 합의가 필요하기 때문에 표준 스타일을 선택하는 것은 의미가 없다고 말했습니다. 선택에 동의할 수 있다면 자동 포맷 없이 위키피디아 전체에서 날짜 형식으로 선택을 구현해야 합니다. 그렇게 하면 진정한 일관성을 얻을 수 있기 때문입니다. 저는 무슨 일이 일어나고 있는지 잘 알고 있고 다른 사용자들이 제 말을 그들의 투표로 돌리려는 것을 좋아하지 않습니다. 람보의 복수 (How do I hell?) 2009년 3월 30일 (UTC) 16:55 답변[답변]
  • 당신은 IP 사용자를 위한 모든 위키백과의 형식 중 하나를 선택해야 한다고 가정하면서 잘못된 이분법을 제시했습니다. WP:ENGVAR는 다른 형식을 요구합니다. 그래서 네, 당신은 그다지 주장하지 않고 있습니다.IP 사용자는 스타일이 엉망이 될 것입니다."라고 주장합니다.WP를 제거하지 않으면 IP 사용자는 스타일의 실수를 경험하게 됩니다.이 문제에 대한 ENGVAR"입니다. 아노미⚔ 2009년 3월 30일 (UTC) 22:19 답변[답변]


  • (위의 반대#89) 참고로, 우리는 그것에 대해 논의하고 있습니다. 최근의 시스템 변경으로 인해 등록되지 않은 사용자에게 기본 형식을 적용할 수 있게 되었고, 작업 중에 언급하신 "페이지 단위" 옵션을 추가할 수 있는 패치(Bugzilla 링크chatspy 최대한 빨리 가져오도록 하겠습니다)가 있습니다. --Ckatz 2009년 3월 30일 (UTC)21:26 (UTC)답변[답변]
    아니요, Josiah는 몇 명의 특권 편집자들이 한 달 또는 한 달 주문을 선택할 수 있다는 의미에서 자동 포맷에 대해 이야기하고 있습니다. IP 사용자를 위한 일관된 고정 텍스트 형식은 자동 형식을 제공하는 수천 개의 기사에 존재하는 현실입니다. Tony(talk) 2009년 3월 31일 08:23 (UTC)답장[답장]
    사실, 두 분 다 옳아요. 일부 편집자를 위한 특별 옵션으로 현재 존재하는 자동 포맷에 반대합니다. 그러나 적절한 지역적 변형과 함께 보편적으로 적용할 수 있는 자동 포맷을 지지합니다. 예를 들어, 추한 2009-04-05 형식을 사용한 인용문이 미국 기반 주제를 다루는 기사와 영국 기반 주제를 다루는 기사 두 개에 사용된 경우, 2009년 4월 5일자로 미국 기반 기사에 (모든 독자에게) 표시되고 영국 기반 기사에 2009년 4월 5일자로 표시됩니다. WP에 따라 기사가 적절한 형식을 사용할 수 있는 매개 변수가 있는 한, 저는 그런 방식으로 날짜를 자동으로 변환하는 자동 서식 시스템을 지지합니다.모스데이트. 즉, 기사 내에서 일관성을 확보하기 위한 방법으로 자동 포맷을 찬성하지만, 백과사전 전체에서 일관성을 유지하기 위한 방법으로 또는 소수의 독자에게 날짜가 일관되게 보이도록 하는 방법으로 자동 포맷을 반대합니다.Josiah Rowe (talk 기고) 2009년 4월 5일 (UTC)답장[답장]
  • 저는 자동 포맷 아이디어찬성하지만 편집기와 하드웨어에 대한 요구 사항에는 반대합니다. Debresser (talk) 2009년 3월 30일 (UTC) 16:50 답변[답변]
나는 당신과 함께 있습니다. 저는 서버가 모든 작업을 해야 한다고 생각합니다. 날짜를 인식하고 시청자가 선호하는 것과 일치하도록 다시 요청해야 합니다. 편집자는 기사 전체에서 날짜가 일치하는지 확인하기만 하면 됩니다. 템플릿이나 마커를 사용하거나 포맷하는 것에 반대합니다. Binksternet (talk) 2009년 4월 3일 06:01 (UTC)답장[답장]
그것은 불가능합니다. 그러면 기본적으로 날짜가 포함된 정확한 견적에서 날짜가 변경됩니다. 정확한 견적을 변경해서는 안 되지만, 조금 예상치 못한 방식으로 견적을 포맷하는 초보자가 입력하더라도 명확하게 견적을 파악할 수 있을 정도로 영리한 소프트웨어는 없습니다. 이를 우회하는 방법을 만드는 것은 해결책이 아닙니다. 왜냐하면 그렇게 하는 메커니즘은 모호할 것이고, 대부분의 편집자들은 그것을 알지 못할 것이기 때문입니다. 소수의 사람들이 두 개의 날짜 형식 중 원하는 형식을 선택할 수 있도록 하기 위해 편집자의 유용성을 손상시킵니다. 구두장이의 휴일 (talk) 2009년 4월 5일 06:57 (UTC)답장[답장]
  • 현재 시점에서 (지지 61, 반대 91), 지지 42, 반대 3, 12, 13, 22, 42, 73은 연결을 말하는 것이라고 생각합니다. 많은 추가 의견이 편집자와 IP에 대해 다르게 보이는 것에 대해 이야기하고 있다고 생각합니다. (1) 편집자가 가젯, 환경설정 및 자바스크립트를 사용하여 보기 형식을 조정할 수 있다는 것은 항상 사실이며 자동 포맷에 대해서는 반드시 사실이 아닙니다.Arthur Rubin (talk) 2009년 3월 31일 (UTC) 00:09 답변[답변]
왜 반대 3번과 73번을 "링크 연결에 대해 말하는 것이라고 생각한다"고 해석하는 건가요? 두 가지 문제를 혼동하는 것처럼 보이는 유권자들과 '차드!표 달기'라는 두 가지 문제를 혼동하는 것처럼 보이는 유권자들이 있다는 것에 동의하지만, 반대 3번과 반대 73번 둘 다 링크와 자동 포맷이 서로 다른 두 가지 문제라는 것을 인식하고 있는 것 같습니다.
어느 쪽이든, 혼란의 비율이 높은 것은 아닙니다. 그것은 좋은 일입니다! 그리고 "voters 채드! hanging"들은 원한다면 자신들의 견해를 분명히 할 시간이 있습니다.
한편, 일부 voters들은 로그인한 편집자가 로그인하지 않은 사용자와 다른 콘텐츠를 보는 것을 원하지 않는다고 말하는 것이 맞습니다. 당신은 그 관점에 동의하지 않지만, 그렇다고 그들의 votes이 "카운트하지 마세요"라는 뜻은 아닙니다. (talk) 2009년 3월 31일 07:21 (UTC)답장[답장]
죄송합니다; 제가 실수를 했거나, 그들이 !표를 바꾸거나, !표에 번호가 다시 붙었거나 둘 중 하나입니다. 그래도 이번 여론조사의 목적은 WP를 찾는 것입니다.공감대, 그리고 저는 반대에 대한 명확한 압도적 다수조차 보이지 않습니다(아직). 로그인한 편집자가 로그인하지 않은 사용자와 다른 콘텐츠를 보는 것을 원하지 않기 때문에 개발자가 정의한 정책에 반하는 이유라고 주장할 수 있습니다. 가젯과 자바스크립트 사용자 지정을 제거해야 합니다. 토크 페이지에 더 올리겠습니다.Arthur Rubin (talk) 2009년 4월 1일 (UTC) 16:06 답변[답변]
  • "편집자들만을 위한" 주장은 지난 1년 동안 이 토론 내내 반복되어 왔습니다. 단지 "딜링크" 캠페인을 실제로 추진하고 있는 서너 명의 핵심 편집자들에게 쉬운 구호이기 때문입니다. 문제는 (반복적인 요청에도 불구하고) 숫자 주장에 대한 어떤 증거도 없었고, 편집하지 않고 날짜 형식, 감시 목록 및 장치와 같은 기능에 액세스하기 위해 계정을 등록한 독자의 승인도 없었습니다. ("편집자 전용"이라는 문구에도 IP는 자동 포맷뿐만 아니라 특별한 특전에 접근할 수 없다는 점이 언급되어 있지 않습니다.) --Ckatzchatspy 2009년 3월 31일 (UTC)응답하라[답변]

세상에! 얼마나 힘들까요? 전체 포맷 작업은 쉬운 작업입니다. 간단한 사실은 자동 포맷 기능이 제공되면 쿠키 시스템이나 기타 수많은 방법을 통해 대부분의 IP 사용자에게도 간단한 기본 설정 옵션을 제공할 수 있습니다. 검색 엔진, 대부분의 뉴스 소스 및 수백만 개의 상업 사이트는 예수가 어린 소년이었을 때부터 해왔습니다. 결론적으로, 자동 포맷은 또한 사용자 기본 설정에 의해 제어될 수 있기 때문에 링크 인수를 완전히 제거할 수 있습니다. 날짜를 연결하시겠습니까? 기본 설정을 통해 전원을 켭니다. 그들이 연결되는 것을 원하지 않습니까? 꺼둔 채로 놔둬. 그리고 로그인되지 않은 사용자 쓰레기에 싫증을 내지 마세요. 대부분 a: 신경 쓰지 마세요, b: 쿠키를 켜놓았거나(또는 그 존재를 알지 못합니다), c: 사이트별로 쿠키를 허용하는 방법을 알고 있습니다. BOT는 간단한 구문(예: YYY-MM-DD 또는 #DYYY-MM-DD)으로 대량 변환하고 위키놈은 나머지 부분을 짧게 처리합니다. 설정하지 않은 사용자를 위한 기본 프레젠테이션(아마도 기본적으로 미국 또는 ISO 형식을 제공하기 위해 액세스하는 위치를 감지하는 약간의 화려한 발놀림). 무엇인가를 한다고 해서 현재보다 일관성이 없어지지는 않을 것 같습니다. --ClubOranjeT 2009년 4월 3일 (UTC)08:08 (답변)

  • 봇이 자동 포맷을 하도록 생각한 사람이 있습니까? 그것은 편집자 요구 사항을 거의 무력화하고 봇에 약간의 노력을 투자하고 앉아서 지켜볼 것입니다! Oldlaptop321 (talk) 2009년 4월 6일 (UTC) 23:58 답변[답변]
(그리고 파괴하지 않기를) 도울 봇과 템플릿이 있다는 것이 모든 면에서 인정된다고 생각합니다. 템플릿과 같이 비교적 여유가 있고 대부분의 경우 올바르게 설정할 수 있는 경우:좌표 또는 템플릿:전환하세요, 큰 문제는 아닌 것 같습니다. 하지만 그런 것들처럼, 당신은 그것들을 사용할 필요가 없습니다. 그래서 저는 그것들을 지지합니다. 그것들은 좋은 것들입니다. 사용자 기본 설정을 찾는 것 외에 템플릿에서 이 모든 것을 수행할 수 없는 이유를 크게 생각할 수 없기 때문에 이것이 투표까지 가는 이유를 알 수 없습니다. 사이먼트루 (talk) 2009년 4월 7일 01:46 (UTC)답장[답장]
사실 이것이 템플릿의 용도에 있는지 궁금합니다.전환. 날짜는 결국 측정일 뿐이고, 그 표현 수단은 측정 단위입니다. 하지만 그것은 아마도 이 투표의 범위 밖에 있을 것입니다. "반대" 캠프에 있는 사람들에게 질문하는 재미있는 질문입니다. 템플릿을 제거하시겠습니까?당신이 쓰는 모든 측정값에 그것을 사용하지 않더라도 변환? 사이먼트루 (talk) 2009년 4월 7일 01:50 (UTC)답장[답장]
사이먼 트류, 이건 투표로 넘어가지 않았습니다. 여기서는 투표 안 해요. 사람들이 사용하고 있는 "!vote" 용어를 보십니까? 그래서. 또한 이 현재 이슈를 Template:convert와 비교하는 것에 동의하지 않습니다. 유사점은 표면적이고 제가 보기에는 거의 없습니다.샤이너페르C· 2009년 4월 7일 (UTC)응답[응답]
네, 그래서 기사 맨 위에 'ONE(원)' 옵션 아래에 투표를 표시해주세요라고 적혀있는 것 같습니다. 저는 그것이 공식적이고 구속력 있는 투표라고 주장한 적이 없습니다.
시간은 변환 템플릿에 비교적 쉽게 통합될 수 있는 또 다른 차원일 뿐이므로 유사성은 피상적이며 거의 없습니다. 그렇지 않은 경우 다른 템플릿을 유사하게 만들 수 있습니다. 그리고 저는 매우 복잡한 단위의 측도 변환 시스템을 설계하고 구현하는 일을 해왔고, 그것들이 쉽지 않다는 것을 알고 있습니다. 사이먼트루 (talk) 2009년 4월 7일 02:51 (UTC)답장[답장]

본 RfC의 결과를 확정할 때는 독자의 선택에 따라 작성된 모든 지원 항목을 무시해야 합니다. 어떤 독자의 선택입니까? 독자는 사이트 기본값 또는 기여 편집자의 선택을 받습니다. 등록된 사용자 = 편집기의 하위 집합, 그리고 다시 편집기는 아주 작은 독자의 하위 집합임을 기억하십시오. 독자가 설정만 편집하면 된다고 떠드는 모든 지원 사용자들은 자동 포맷을 지원하는 모든 제안을 물리치는 데 걸리는 시간보다 더 짧은 기간 동안 커뮤니티의 다른 사용자들이 고의적으로 무시해야 합니다. --Karbinski (talk) 2009년 4월 9일 (UTC)21:38 (답변)

죄송합니다만, 그건 유효하지 않습니다. 등록할 경우 편집해야 하는 요구사항은 없습니다. 누구나 계정을 등록할 수 있으며, 해당 계정을 사용하여 읽기만 선택하면 됩니다. 계정은 기기, 시계 목록, 다른 스킨 등을 사용하고 싶은 독자들에게 유용할 수 있습니다. --Ckatzchatspy 2009년 4월 9일 (UTC)응답하라[답변]
죄송합니다만, 중간에 생략하면 맞습니다. 등록된 사용자는 아주 작은 독자의 하위 집합임을 기억하십시오. 베어링이 있는 것은 아니지만 등록된 사용자는 편집자의 하위 집합이기도 합니다. Karbinski (talk) 2009년 4월 9일 21:57 (UTC)답장[답장]

많은 대조적인 주장들은 대부분의 독자들이 논자라는 문제에 대해 이야기합니다. 저는 사람들이 계정을 등록하는 유일한 이유가 편집 때문이라고 생각한다는 것을 경험으로 알고 있습니다. 표준화된 날짜, 감시 목록 등과 같은 유형의 이점이 있고 이러한 이점이 독자에게 홍보된다면 더 많은 편집자를 확보할 수 있을 것입니다. 그리고 일단 계정이 있으면, 그들은 때때로 편집해야 할 의무가 더 많아질 수 있습니다. 그리고 그렇게 하면 편집이 취미가 될 수 있어요. 편집자들이 집단에 완전히 동화될 때까지 말이죠. (아이고! 스타트랙을 너무 많이 보고 있었나요?) 요점은 편집자들에게 좋은 것은 무엇이든 궁극적으로 독자들에게도 좋다는 것입니다. --Willscrlt(→""" ¿Talk?!"), 2009년 4월 14일 (UTC)응답하라[답변]

응답
  • 여러 사용자가 한 기사에서 자동 포맷만이 일관성을 달성할 수 있는 유일한 방법이라고 지적했지만, 이는 사실이 아닙니다. 편집: 이것은 사이트 전체의 일관성을 달성하기 위한 것일 수도 있지만, 이것은 왜 날짜의 모양이 그렇게 큰 문제인지에 대한 의문을 제기합니다. 우리 모두는 DMY나 MDY 또는 YMD(2000년 1월 1일)를 보고 날짜를 쉽게 결정할 수 있습니다.
  • 사용자:이 플래그는 빨간색이었던 적이 있습니다.어쨌든 모호한 3/2/03 형식을 사용하는 것은 선택 사항이 아닙니다.
  • 제 생각에는 날짜에 템플릿을 사용하면 날짜가 DD/MM 또는 MM/YY로 표시되지 않고 DD/MM 또는 MM/YY로 표시되는 것이 아니라 날짜가 DD/MM 또는 MM/Y로 표시되는 것입니다. 이 문제가 완전히 사라지지는 않을 것이라는 것에 동의합니다. 하지만 편집자들이 날짜를 {{...}로 지정하는 습관이 생기면서 이 문제는 완화되어야 합니다. day=2개월=3...}}, 그냥 "2/3/09"라고 입력하고, 청소하는 사람이 누구든 마법처럼 날짜가 DD/MM인지 MM/DD인지 알기를 바라는 대신 말입니다. 건배, 이 깃발은 빨간색이었던propagandadeeds 적이 있습니다. 2009년 3월 31일 (UTC)응답하라.
  • "자동 포맷이 도입되기 전에는 날짜를 어떻게 포맷해야 하는지에 대한 긴 줄이 있었습니다. 문서(talk·contribs)에서 일부가 날짜 연결을 해제하기 시작한 것처럼, 최근에 다시 돌아온 것 같습니다. 누가 날짜 형식에서 이 길이의 행을 가리킬 수 있습니까? 못 봤어요. 여기서 연결하는 것을 말하는 것이 아닙니다.
  • "또한 자동 포맷은 편집 왜곡을 방지하는 데 도움이 됩니다." 제공되는 증거가 거의 없는 과도한 주장입니다. 사실, 이러한 편집 전쟁은 거의 없습니다.
  • 메타데이터를 자동 포맷이 필요한 이유로 꼽은 사용자에게 이 메타데이터를 사용할 수 있는 예를 제공할 수 있습니까? Dabomb87 (talk) 2009년 3월 31일 02:16 (UTC)답장[답장]
개발자들이 제안한 대로 사이트 전체에 단일 형식을 적용하는 것 외에 모든 기사가 서로 일치하도록 하려면 어떻게 해야 합니까? 우리는 단일 표준으로 가거나, 아니면 "이것은 미국식이다, 국제적이다"라는 최초의 과거 게시물 방식을 고수합니다. 만약 후자의 경우라면, 획일적이고 일관된 모습을 보여주는 어떤 방법을 제공하는 것이 현명할 뿐입니다. --Ckatzchatspy 02:28, 2009년 3월 31일 (UTC)답변[답변]
죄송합니다, 좀 더 명확히 하겠습니다. 위에 올린 글을 편집했습니다. Dabomb87 (talk) 2009년 3월 31일 12:47 (UTC)답장[답장]


자동 포맷에 반대하는 대부분의 주장은 "이것은 많은 일이 될 것이고, 나에게는 이점이 없다"로 귀결되는 것 같습니다. 저는 이것이 일관성에 신경 쓰는 사람들이 그 일을 하는 것을 금지하는 주장이라는 것을 알지 못합니다. 왜 이것은 "모든 사람이 이 마크업을 사용해야 한다"거나 "누구도 이 마크업을 사용할 수 없다"는 관점에서 틀을 짜야 합니까? 그건 위키 방식이 아닙니다. 위키 전통은 사람들이 더 복잡한 마크업을 사용하는 것을 귀찮아하지 않더라도 기여하도록 장려하고, 원한다면 다른 사람들이 고급 마크업을 삽입하도록 하는 것입니다.

다른 사람이 자동 포맷을 추가하기 때문에 여러분 모두가 어떤 적극적인 피해를 입습니까? 어느 쪽이든 손가락을 들 필요가 없습니다.Henning Makholm (talk) 2009년 3월 31일 11:20 (UTC)응답하라[응답하라]

이것이 중요한 포인트입니다. 자동 포맷을 구현할 수 없고 나중에 MOS가 사용을 권장해야 하는지에 대한 논의를 할 수 없는 이유는 무엇입니까? 이 여론조사의 첫 번째 섹션은 사용자가 실제 관련된 내용을 확인할 수 있는 구현 후까지 남겨두었어야 합니다. 그 {{cite}를 기억하는 것 같습니다.}} 이런 식으로 왔고, 아마도 미등록 사용자들이 이 제안보다 훨씬 더 텍스트를 편집하고 해체하는 것이 더 어려울 것입니다.2009년 3월 31일 (GMT) 12:49 †
네, 그런데 {{cite...}} 는 백과사전의 중요한 기능을 제공합니다. 이는 마크업이 도입하는 사용의 어려움 등의 측면에서 비용을 정당화하는 것 이상입니다. 반면에 날짜 자동 포맷은 기껏해야 극히 사소한 미용상의 변경을 제공합니다. 대부분의 사람들은 날짜가 어떤 형식으로 작성되는지 신경 쓰지 않습니다. 그들은 심지어 다시 생각하지 않고 자신의 글이나 연설에서 다양한 형식을 사용할 것입니다. 실제로 마음에 들지 않는 형식으로 데이트를 읽음으로써 짜증을 내는 사람들의 수는 엄청나게 적을 것입니다. 불필요하게 복잡한 마크업을 성가시게 여기거나, 날짜 자동 포맷이 잘못 구현되어 과도한 링크 및 때로는 비정상적인 결과에 짜증을 내는 저와 같은 사람들은 이들보다 훨씬 많습니다. Hawthorn (talk) 2009년 3월 31일 23:38 (UTC)답장[답장]
다른 편집자들이 날짜 표시를 삽입하는 것에 대해 실제로 짜증을 내는 사람들의 수는 훨씬 더 적을 것입니다. 당신 자신이 그런 마크업에 들어가는 것을 성가시게 생각하더라도, 나는 다른 사람들이 그것을 하도록 내버려 두는 것이 어떻게 당신을 짜증나게 할 수 있는지 모르겠습니다. 아무도 당신이 그것을 원하지 않는다면 당신이 직접 포맷을 입력해야 한다고 제안하지 않지만, 다른 사람들이 그렇게 한다면 그것이 어떻게 당신을 방해할 수 있습니까? 다시 말하지만, 그 제안은 비링크 자동 포맷에 관한 것이므로, 당신을 짜증나게 하는 과도한 링크는 없을 것입니다.헤닝 막홀름 (talk) 2009년 4월 1일 (UTC) 14:35 답변[답변]
헤닝 막홀름은 기사를 편집하려는 사람은 누구나 다른 사람들이 삽입한 마크업을 처리해야 한다는 사실을 간과하는 것 같습니다. 비록 "처리"는 "어떻게 편집할 것인지"를 의미할 뿐이지만 말입니다. 매우 어려울 수 있습니다. 많은 사람들은 날짜 형식 선호도가 더 많은 마크업(백과의 모든 날짜에 {{format date 1981년 12월 12일}}를 추가하는 것은 물론 현재 사용되는 이중 괄호 마크업을 정당화할 만큼 중요하지 않다고 말합니다. Ssoul (talk) 2009년 4월 2일 (UTC) 07:08 답변[답변]
포맷이 완료되면 전혀 부담스럽지 않습니다. 반대로, 이것은 당신이 인용한 마크업이 어떻게 작동하는지를 스스로 문서화하는 것입니다. 저는 그 누구도 4분의 1초 이상을 사용하는 것을 상상할 수 없습니다. "음, 포맷 날짜라고 쓰여있는데, 그게 무슨 뜻인지 궁금해... 아, 눈부신 빛, 아마도 그 다음에 오는 날짜를 포맷하는 것에 대한 것일 것입니다." 마크업이 어떻게 작동하는지 기억하고 싶지 않다는 것을 이해할 수 있습니다. 그래서 처음부터 다시 입력하고 싶지 않다는 것을 이해할 수 있습니다. 하지만 정말로, 여러분이 보여주는 것처럼 명확하고 모호하지 않은 마크업에 대해 알아차리고 편집하는 데 어려움을 겪는 모든 사람들은 아마도 평범한 산문으로 백과사전의 일관된 문장을 꿰매지 못할 것입니다.
이중 제동은 문맥상 거의 관련이 없는 출력에 불필요한 파란색 링크를 생성하기 때문에 짜증이 납니다. 짜증나네요. 하지만 관심이 많은 (아마도 소수의) 사람들이 좀 더 쉽게 살 수 있도록 정말로, 쉽게, 스스로 문서화하는 마크업? 천만에요.Henning Makholm (talk) 2009년 4월 2일 (UTC) 11:32 답변[답변]
자, 따라서 불필요하다고 생각되는 마크업을 헤쳐나가야 하는 것이 쉽지 않거나 성가시지 않습니다. 다른 사람들은 그렇게 어렵고 성가시지요. 그것은 "다른 의견" 중 하나이고, "아니오"라고 말하는 것은 그것을 바꾸지 않습니다. peace Soul (talk) 2009년 4월 3일 07:37 (UTC)답장[답장]

(지지표 82번에 대한 응답) UC_Bill 죄송합니다만, 두 가지 모두를 가질 수는 없습니다. 커뮤니티에 날짜 범위(그리고 바라건대 날짜 슬래시)가 어떻게 작동했는지 보여줄 수 있는 데모 페이지를 제거하고 프로그래밍이 쉽다고 주장했습니다("10시간?"). 데모 페이지를 다시 설정하십시오. 그렇지 않으면 위의 주장을 건전한 양의 회의론으로 다룰 자격이 있는 이유를 이해해야 합니다. 다른 투표 당사자들에게, 제안된 것은 (UC_Bill의 앞 게시물에서도 알 수 있듯이) "날짜를 둘러싼 네 개의 괄호([ ])"를 훨씬 넘는 것임을 유의하시기 바랍니다. (돌아오셨나요?) 또는 다른 프로그래머들이 개별 사례를 처리할 수 있는 무언가를 얻지 못했을 수도 있다는 것을 제안하는 것은 아니지만, 3년 넘게 입증된 바와 같이, 자동 포맷의 기초를 제대로 갖추기가 점점 더 어려워지고 있습니다. 하지만 날짜가 WP에 표시되는 여러 가지 방법에 대해 자동 포맷이 어떻게 작동해야 하는지 지정하는 것은 불가능해 보입니다. HWV258 2009년 3월 31일 21:57 (UTC)답장[답장]

(투표 반대 응답 번호 138번) "저는 독자들에게 날짜를 어떻게 표시할지에 대한 선택권을 줄 정도로 이에 대해 걱정하는 정보원이나 뉴스 공급자를 본 적이 없습니다."(잘 포착되었습니다.) 아주 좋은 지적입니다. "MMM DD, YYY 모든 것"의 관점에서 보면, 기사가 "DDMM YYYYY"에 빌려주는 경우가 많기 때문에 그렇게 독재적일 필요는 없습니다. 이 경우 단순히 문제의 페이지를 선택하는 형식일 수 있습니다. 영국 기사에서 "DDMMM YYYY" 형식의 날짜를 보는 것과 동시에 미국 기사에서 "MMM DD, YYYY" 형식의 날짜를 보는 것이 그렇게 걱정스러운 일입니까? HWV258 23:33, 2009년 3월 31일 (UTC)답장[답장]

저는 두 형식을 서로 교환하여 사용하는 국가(영국) 출신이기 때문에 전혀 걱정하지 않습니다. 위의 제 글(반대 138)을 다시 읽으시면 (적어도 루퍼트 머독이 구매하기 전에) 오랫동안 영국의 기록 신문으로 여겨졌던 타임즈가 MMM DD, YYYY를 사용한다는 것을 알 수 있을 것입니다. 그런데 왜 영국에 관한 위키백과의 기사는 다른 기사들보다 그 형식을 덜 빌려주는 것일까요? 미국 밖에는 일관된 표준이 있다는 것은 미신입니다. 그래서 그곳의 민간 생활에서만 사용되는 표준을 따르고, 영어가 사용되는 다른 모든 곳에서 DDMM YYYY와 혼용하여 사용하는 것은 어떨까요? Phil Bridger (talk) 00:24, 2009년 4월 1일 (UTC)답장[답장]
저는 제가 더 이상 따르고 있는지 확신할 수 없습니다(위의 혼란은 "거기"라는 단어에서 시작되었으니, "거기"라는 단어는 민간 생활에서만 사용되는 표준을 따르지 않는 것이 어떨까요?"("거기"는 어디에 있습니까?). 영국 기사에 "MMM DD, YYY" 날짜 형식을 사용해야 한다고 제안하시는 건가요? 그렇다면 이 토론에서 다른 사람들이 감히 제안한 것보다 훨씬 더 급진적이라는 것을 알아야 합니까? 다른 한편으로, 글로벌 형식이 제안된다면, 저는 구문론적으로 덜 복잡한 "DDMM YYYY"(이 게시물들의 각 끝에 사용되는 형식)를 사용할 것입니다. HWV2580 1:04, 2009년 4월 1일 (UTC)답장[답장]
제가 잘 몰랐다면 죄송합니다. "거기"라는 단어는 미국을 의미했습니다. 그리고 다시 한 번 말하지만, 두 형식이 영국에서 혼용될 때, 영국 기사에 MMM DD, YYYY를 사용하는 것이 급진적인 이유는 무엇입니까? 모든 사람들이 미국 밖에서 DDMM YYYY에 대한 강한 선호가 있다고 가정하는 것처럼 보이지만, 위의 링크(반대 138)에서 증명했듯이, 이것은 사실이 아닙니다. Phil Bridger (talk) 2009년 4월 1일 (UTC) 08:54 답변[답변]
그것들이 상호 교환적으로 사용된다는 것은 사실이 아닙니다. 영국에서 양식을 작성해야 하는 경우 __/__/____와 같은 필드에 날짜를 입력해야 할 가능성이 높습니다. 제 경험상 그들은 항상 DMY 형식을 사용하기를 기대할 것입니다. 경우에 따라서는 말할 필요도 없이 DMY 형식을 언급하지 않을 수도 있습니다. DMY 형식은 철자가 적힌 달을 포함하여 일반적으로 훨씬 더 일반적이기 때문입니다. --Hans Adler (talk) 2009년 4월 15:13 (UTC)응답하라
양식의 경우 날짜가 일반적으로 모든 숫자 형식으로 입력되므로 분명히 표준이 있어야 하며, 예, 영국과 미국에서는 표준이 다르지만 월을 구분하는 다른 맥락에서는 두 형식이 모두 일반적입니다. 여러분은 사람들이 "2009년 4월 1일"이 아니라 "2009년 4월 1일"이라고 되어 있는 "2009년 4월 1일"이라고 되어 있는 "The Times"나 "The Financial Times"나 "12", "The Daily Mail", "The Sun", "Daily Star"에서 읽었을 때, 사람들이 날짜를 이해하는 데 어려움을 겪고 있다고 심각하게 생각하거나, 그것에 문제가 있다고 생각하십니까? 10개의 전국 일간지 중 5개지라 더 이상 쪼개질 수가 없었습니다. 그리고 두 형식 모두 영어가 널리 사용되는 다른 여러 국가에서 사용된다는 것을 보여주기 위해 위에서 유사한 참고 자료를 제공했습니다. 증거에 따르면 두 형식이 모두 사용된다는 것은 "단순히 사실이 아니다"라는 말이 아닙니다. 그리고 왜 우리가 이 백과사전을 신뢰할 만한 자료에 근거해야 하는데, 지금까지 여기서 투표한 248명의 사람들 중에 어떤 증거라도 제시하려고 애쓴 사람이 저뿐이라는 거죠? Phil Bridger (talk) 2009년 4월 1일 15:45 (UTC)응답하라[답변]
당신이 실제로 영국에서 온 것을 보지 못하고 터무니없이 강의해서 죄송합니다. MDY에 대한 표준화가 옵션이 될 것이라는 데 동의합니다. 그러나 이것은 영국 영어에서 동사에 대한 옥스포드 스타일의 "ize" 철자를 표준화하는 것과 매우 유사하며, 우리도 이것을 채택하지 않은 것 같습니다. 따라서 귀하의 주장이 이번 여론조사에서 많은 사람들을 설득할 것 같지는 않습니다. 저는 정말 따로 논의해야 한다고 생각합니다. --Hans Adler (talk) 2009년 4월 1일 (UTC) 16:05 답변[답변]
저는 이 점에 동의하고 싶습니다. 이 토론이 진행되는 것을 볼 때마다, 저는 솔직히 제가 어떤 변형을 선호해야 하는지 또는 어떤 변형에 반대해야 하는지 기억하기가 어렵습니다. 숫자로 쓰는 것은 기준이 있지만, 문자로 쓰는 것은 '2월 1일'이나 '2월 1일'은 영국 독자들과 거의 호환이 됩니다. 저는 종종 같은 글에 두 가지를 쓰거나, 하루는 다른 날을 쓰거나, 다음 날을 쓰곤 합니다. Shimgray talk 2009년 4월 3일 (UTC) 15:29 답변[답변]
위의 몇 가지 영국 신문 예는 뉴스 기사를 파헤칠 때 미국 날짜 형식을 일관되게 사용하지 않습니다. The Sun의 맨 위 배너에 MDY가 표시될 수도 있지만, "Published: 2009년 4월 4일"과 같은 DMY 기반 콘텐츠는 현재 날짜[16] 이전 기사에 표시됩니다. 여기에 The Daily Star의 "2009년 4월 13일"The Daily Mail의 "또 다른 13일"이 있습니다. 이러한 상업용 웹 사이트는 소프트웨어 기본값에 따라 왜곡될 수 있으므로 날짜 형식에 대한 신뢰할 수 있는 지표가 될 수 없습니다.
이 논의를 위해 정부 표준과 관행을 고려하는 것이 더 신뢰할 것으로 보입니다. 영국 정부의 사용 방식은 DMY를 지속적으로 사용하며 US/MDY 형식을 거부합니다. 요일 번호에 서수 문자(12번째 vs 12번째)가 사용되는지 여부에 대해서는 많은 차이가 있지만 공식적인 영국 수준에서는 주문의 상호 교환성이 없습니다. TDA, 내각, Hants, Mansfield 지방의회.
또한 DMY는 일반적으로 UN[17], OECD[18], ITU[19], ICRC[20]와 같은 국제 기구에서 사용됩니다. 그것은 국제적인 규모에서 어떤 날짜 형식이 표준으로 간주되고 WP와 같은 글로벌 프로젝트가 어디로 향해야 하는지에 대한 강력한 증거입니다. 하지만 단기적으로 성공할 수 없다면, 다양한 오디언스의 이익을 위해 이미 개발된 자동 포맷 기능을 잘 활용해야 합니다. Dl2000 (talk) 2009년 4월 13일 (UTC) 16:41 답변[답변]

바보 같은 자동 포맷: 유명하고 수상 경력이 있는 벨라루스 블로거이자 여러 벨라루스 웹사이트의 편집자이자 인터넷에서 벨라루스어 사용을 위한 활동가인 울라지미르 카트쿠스키. 그는 영어 위키백과에 1343개의 기여를 했고, 9개의 다른 위키미디어 프로젝트에 1286개의 기여를 했습니다.[1] 카트쿠스키는 주로 그의 나라의 언어에 관한 기사들을 편집했습니다. 그는 2006년에 소방차에 치였고, 약 1년 동안 혼수상태에 있다가 2007년 5월 25일에 사망했습니다.

링크의 컨텍스트 오개념

  • 혼란에 대한 몇 가지 맥락을 제공하기 위해 지금 저는 다음 표에 주어진 정당성으로 연결되는 논쟁을 계산합니다(#s는 이 글을 읽을 때까지 바뀌지 않는다고 가정합니다). 12, 13, 22, 41, 42, 49, 73, 93, 101, 108, 109, 110, 114, 116, 134, 135, 137, 140, 145, 147. 현재 159표 중 20표(~12%)입니다. 또한, 중립 댓글 3과 8은 이러한 오해를 공유합니다. 양쪽 모두 몇 표가 더 있는지 누가 알겠습니까? 이 오해를 공유하지만 명시적으로 언급하지는 않습니다.
이러한 의견 중 링크 이외의 문제를 근거로 반대 주장을 하는 것은 일부에 불과합니다. 제가 인용한 대다수의 사람들은 링크 제안에 대한 그들의 주어진 설명을 전적으로 기반으로 합니다. Shadowjams (talk) 2009년 4월 2일 01:20 (UTC)답장[답장]
(1) 유권자들은 그들의 내면의 모든 추론을 제공할 의무가 없습니다. 아무런 논평도 하지 않은 사람들에게 이의를 제기하는 건가요? (2) 많은 사람들이 여전히 날짜 자동 서식의 개념을 약 5년 동안 그 개념의 고유 용어인 "링크"에서 언급하는 것은 놀랄 일이 아닙니다. (2) 자동 서식의 개념에 대한 성명서에는 "링크"에 대한 언급이 있습니다. 그리고 "database 덤프"와 같은 "새로운 기능"에는 편집자가 링크로 자동 형식화된 날짜를 식별하는 기능이 필요합니다. 왜 일부 유권자들은 일반적인 동의어인 "링크"를 사용하여 자동 포맷의 개념을 언급하지 않았을까요? Tony (talk) 2009년 4월 2일 (UTC) 09:58 답변[답변]
투표가 아닌 여론조사이기 때문에 추론은 실제 제안의 지지에 도움이 됩니다. 가장 단호한 반대자라도 제안의 성격에 대해 사람들이 잘못 알려지는 것을 원하지 않아야 하며(만약 그렇게 했다면 절대로 목소리를 낼 수 없습니다), 많은 사용자가 혼란스러워하는 증거가 있을 때 방해를 받아야 합니다.
"linking"이라는 속기는 흥미롭고 이전에 들어본 적이 없는 것입니다. 당신이 맞을 수도 있고 일부 사용자들은 습관적으로 이전 용어를 사용하고 있습니다. 그러나 "블루 링크"를 언급하거나 설명하는 일부 사용자들은 이 제안이 다시 날짜 링크로 이어질 것이라고 믿고 있습니다.
제 원래 목록 중 13, 22, 42, 49, 73, 93, 101, 108, 109, 110, 116, 135, 137, 145, 147번은 스스로 구별하거나 링크의 특정 속성(파란색, 어디론가 등)을 참조하여 표시합니다.
당신의 요점은 아마도 링크는 언급하지 않고 사물을 자동 포맷이라고 부르는 일부 사용자들이 링크를 생각하고 있다는 것을 암시합니다. 아마도 제 원래 인구 조사는 잘못된 정보를 가진 편집자의 수를 과소평가했을 것입니다. Shadowjams (talk) 2009년 4월 2일 (UTC) 18:05 답변[답변]

사용자별 투표:신경분해: User:neuro가 반환되어 다음과 같이 추가되었습니다.

  • 이거 보고 자니까 제가 너무 빨리 한 것 같아요.

그것은 저에게 후퇴처럼 보입니다. 라이트마우스 (talk) 2009년 4월 1일 (UTC) 18:06 답변[답변]

그래, 그랬다. neuro(talk)(review) 23:48, 2009년 4월 1일 (UTC)답장[답장]

페이지를 조립하는 동안 서버가 수행하도록 합니다. 왜 인간 편집자들은 이 질문에 관심을 가지나요? 서버가 텍스트에서 날짜를 검색한 다음 선호도에 따라 뷰어에 맞게 다시 포맷할 수 없는 이유는 무엇입니까? 서버는 이미 아무도 모르게 <br>, </br> 및 <br/><br/>로 바꿉니다. 저는 날짜가 동일해야 한다고 생각합니다. 편집자가 날짜만 입력하면 서버에서 제공되는 방식을 처리할 수 있습니다. 봇이나 사람이 기사를 읽고 템플릿이나 포맷을 적용해야 할 이유는 없습니다. Binksternet (talk) 2009년 4월 3일 (UTC) 15:39 답변[답변]

여기서 문제는 우리가 많은 날짜를 다시 포맷하고 싶지 않다는 것입니다. 예를 들어 인용문이나 인용된 작품의 제목과 같은 것들은 우리가 고장난 철자조차 그대로 두는 곳들입니다. 우리가 이런 종류의 자동차 형식을 느슨하게 하려면, 우리는 그것들을 변경되지 않는 것으로 표시하는 간단한 방법이 필요합니다. Shimgray talk 2009년 4월 3일 (UTC) 19:53 답변[답변]
서버에 "이 특정 날짜를 건드리지 마세요"라고 말하는 간단한 방법이 있습니다. 노위키 태그를 사용하면 됩니다. Binksternet (talk) 2009년 4월 4일 13:12 (UTC)답장[답장]
또는 정의해야 할 다른 태그 또는 템플릿. 그러나 자동 서식을 지원하지만 태그/템플릿을 포함하는 데 사용하는 것이 제외하는 것보다 더 나은 것 같습니다(즉, 선택적인 추가). 그래야 변화가 없습니다. 물론 편집자나 특정 프로젝트를 관리하는 사람들은 봇을 실행하여 "업그레이드"를 자동화하여 새 자동화를 사용할 수 있지만, 서버의 기본 동작이 되어서는 안 됩니다.
아마도 제가 Binksternet의 코멘트를 잘못 이해했을 수도 있지만, 만약 그 제안이 서버가 텍스트를 해석하고 특정 텍스트가 날짜라는 것을 알아낼 수 있어야 한다는 것이라면, 그것은 매우 어려운 작업입니다. 는 어느 정도의 마크업은 불가피하다고 제안하고 싶습니다. 또한 서버가 다른 언어를 이해하는지 잘 모르겠습니다. 언어별 텍스트를 구문 분석하는 것은 서버 코어가 아닌 특정 위키 템플릿의 작업입니다. 사이먼트루 (talk) 2009년 4월 6일 16:14 (UTC)답장[답장]
아마도 저도 원래의 의견을 잘못 이해했을 수도 있지만, 만약 그 제안이 어떤 종류의 표시가 없는 날짜를 분석하는 것이라면, 다음의 예를 살펴보세요: "2000년 1월 1일에 위키피디아 사람들이 열광했습니다." 2000년 1월 1일에 모든 위키피디아 사람들이 미쳐가는 것일까요, 아니면 2000년 1월 1일에 미쳐가는 것일까요? HWV258 22:42, 2009년 4월 8일 (UTC)답장[답장]
만약 그 두 가지 의미 중 첫 번째가 의도된 의미라면, 그 해 이후에 특별한 쉼표를 추가하는 것은 어떨까요? --A. di M. (이전의 육군 1987) -- 아니라 행동입니다. 00:31, 2009년 4월 9일 (UTC)답장[답장]
WP에 잘못된 형식의 문장 목록을 작성하시겠습니까, 아니면 제가 작성할까요? :-) HWV2580 01:10, 2009년 4월 9일 (UTC)답장[답장]

ISO 날짜로 자동 포맷

반대자들 사이에서 반복되는 한 가지 의견은 자동 서식 작성이 미국/연방 철자를 자동으로 처리하는 것과 유사하며, 우리는 그것을 원하지 않는다는 것입니다. 우리가 그것을 원하는지는 차치하더라도, 이 주장은 날짜를 ISO 형식으로 자동 포맷할 수 있는 또 다른 가능성을 놓치고 있습니다. 인간 독자들 중에는 그것을 원하는 사람은 거의 없을 것입니다(그렇지만, 저는 기술적인 괴짜입니다). 하지만 자동화된 파서, 특히 인포박스에서 매우 유용할 수 있습니다. 건배, 이 깃발은 한때 빨간색이었습니다propagandadeeds. 2009년 4월 3일 (UTC)응답하라.

등록되지 않은 사용자에 대한 자동 서식 지정

성명서(위키피디아:날짜 형식 지정 및 연결 poll#Background문)은 자동 형식 지정이 등록된 편집자에게만 유용함을 시사합니다. "자동 형식 지정은 등록된 사용자가 선호하는 표시 형식을 선택할 수 있도록 업데이트를 표시하는 방법입니다." 그런데 비등록 사용자에 대해서는 자동포맷을 할 수 없었던 이유가 있나요? 사용자의 로케일은 HTTP 헤더("Accept-Language")와 사용된 적합한 날짜 형식에서 쉽게 유추할 수 있습니다. 건배, 이 깃발은 한때 빨간색이었습니다propagandadeeds. 2009년 4월 3일 (UTC)응답하라[응답하라]

그러나 독자가 선호하는 형식을 헤더에서 어떻게 추론할 수 있습니까? 저는 이 토론의 다른 곳에서 "2009년 4월 3일"과 "2009년 4월 3일"이 영국, 인도, 호주 및 캐나다의 영어로도 똑같이 허용되는 형식이라는 것을 보여주었습니다. 그리고 정말로 제가 당신을 파키스탄, 아일랜드, 뉴질랜드, 방글라데시, 남아프리카, 스리랑카의 주요 영어 미디어 소스와 연결시키겠다고 주장한다면, 나이지리아와 그 밖에 영어가 널리 사용되는 곳이라면 "2009년 4월 3일"이 국가적으로 선호되는 형식이라는 것을 보여줄 신화입니다. 선호하는 형식이 있는 유일한 나라는 미국입니다. 그러니 이 바보 같은 토론을 그냥 무시하고 영어가 널리 사용되는 모든 곳에서 허용되는 형식(2009년 4월 3일)을 사용하는 것은 어떨까요? Phil Bridger (talk) 2009년 4월 3일 (UTC) 19:18 답변[답변]
이와 관련하여, 두 형식이 모두 사용된다는 것을 다른 곳에서 보여 주셨지만, 두 형식 모두 동일하게 허용된다는 것은 아닙니다. Times는 MMM DD, YYYY를 사용할 수 있지만, Times의 선거구 내에서 동일하게 형식이 허용되는 것은 아닙니다.
그리고 물론 독자가 선호하는 헤더에서 추론할 수는 없습니다. "사용자의 로케일은 HTTP 헤더에서 쉽게 추론할 수 있고 (특히 "Accept-Language") 적절한 날짜 형식을 사용할 수 있습니다." 로케일을 추론할 수 있습니다. 그런 다음 사용되는 날짜 형식은 로케일의 일반적인 날짜 형식을 기반으로 합니다. 등록되지 않은 편집기가 Times 리더인지 일반적인 enGB DDMM YYY 사람인지 두 번째로 추측할 필요가 없습니다.
제 요점은 위의 제안과는 달리 자동 포맷이 등록되지 않은 편집자들에게 도움이 수 있다는 것이었습니다. 예를 들어, HTTP 헤더에 en-us가 있는 익명의 IP는 DDMM YYY 날짜를 얻지 못할 것이고, en-gb 헤더가 MMM DD, YYY 날짜를 피하는 결과를 초래할 때 타임즈 독자들만 실망할 것입니다.
건배, 이 깃발은 빨간색이었던propagandadeeds 적이 있습니다. 2009년 4월 3일 (UTC) 답변[답변]
하지만 타임즈만은 아닙니다. 여기 또 다른 게시물에서 저는 영국의 전국 일간지 10곳 중 5곳이 "2009년 4월 3일"이 아닌 "2009년 4월 3일"을 사용한다는 것을 보여주었습니다. 영국에서 한 형식이 다른 형식보다 선호된다는 증거는 어디에 있습니까? 그리고 미국을 제외하고 영어가 상당한 정도로 사용되는 다른 모든 나라들도 마찬가지입니다 - 저는 인도, 캐나다, 호주에 대한 예를 들어보았고, 만약 여러분이 영어를 상당한 정도로 사용하는 나라가 있다고 주장한다면, 여러분과 다른 누구에게도 그러한 증거를 제공하라고 촉구할 것입니다. "4월 3일," 2009"는 완전히 허용되는 형식이 아닙니다. 다시 한 번 말하지만, 왜 수백 명의 사람들 중에서 자신들의 입장에 대한 증거를 제시하기 위해 여기에 댓글을 다는 사람은 저뿐인가요? Phil Bridger (talk) 2009년 4월 3일 (UTC) 21:05 답변[답변]
  • 뉴질랜드(제가 있는 곳)에서도 선호하는 날짜 형식이 없습니다. 개별 출판물은 선택된 스타일을 가질 수 있지만 해당 출판물을 위해 글을 쓰는 사람만이 이를 인식할 수 있습니다. 날짜를 어떤 형식으로 쓰는지 아무도 알려주지 않습니다. 사실 저는 이것이 문제라는 것을 이해하기 어렵습니다. 날짜 약어에 대한 DD/MM/YYYY 규칙이 있는데, 이 규칙은 미국과 다르지만, 약어가 아닌 날짜는 어떤 형식으로든 작성되고 이해될 수 있습니다. 저는 날짜를 미국식으로 쓰는 것에 개의치 않습니다. 어쨌든 절반 정도는 그렇게 합니다. 하지만 저는 위키피디아가 날짜를 항상 미국식으로 작성하도록 요구하는 것에 반대할 것입니다. 데이트 나치에 대한 헌장처럼 들리네요. 많은 문화들이 서로 교류하는 큰 세상입니다. 위키피디아는 모든 종류의 배경을 가진 사람들이 기여하는 국제적인 협업입니다. 이 작품을 만들기 위해서는 차이점에 대한 내성과 이해가 필요합니다. 너무 내성적이어서 다른 사람들이 그들의 데이트 상대를 짜증나게 하는 스타일을 내버려 두는 사람은 긴장을 풀고 삶을 살라는 말을 들어야 합니다. Hawthorn (talk) 2009년 4월 4일 08:31 (UTC)답장[답장]
  • 제 원래 요점은 "위의 제안과는 달리 자동 포맷이 등록되지 않은 편집자들에게 도움이 수 있다"는 것이었습니다. 지금까지 어떤 말도 그것을 바꾸지 않았습니다. 아마도 우리는 공동체로서 등록되지 않은 독자들이 날짜를 형식화되지 않은 것으로 간주하기로 결정할 것입니다. 그러면 우리의 선택이 될 것입니다. 제 요점은 반대의 주장에도 불구하고 자동 포맷이 우리에게 그 선택권을 준다는 것입니다. 당신의 증거를 살펴보면, 스코틀랜드의 한 신문은 DDMM YYYY를 사용하고, 다른 신문은 DDMM YYY를 사용합니다(쉼표 없이). 저는 이것이, 혹은 독자 분이 제시한 증거가 신문 이외의 어떤 것도 다양한 스타일을 사용한다고 말하지 않는다고 믿습니다. 확실히 여기서 중요한 것은 사람들이 학교에서 배우고, 일상 생활에서 사용하며, 정부의 서신을 통해 인정받는 것입니다. 원하신다면, 저는 DDMM YYYY가 영국, 뉴질랜드, 싱가포르(제가 어느 정도 교육을 경험한 나라들)의 학교에서 가르치고 있다는 제 믿음을 뒷받침하는 참고 자료를 찾아보겠습니다. 이 형식은 해당 국가의 정부들이 사용하는 형식입니다. 그리고 결과적으로 사람들은 그 형식을 더 많이 사용하는 경향이 있습니다. 그리고 저는 감히 다른 편집자들이 다른 나라에 대한 참고 자료를 제공할 수 있다고 말합니다. 하지만 당신은 MMM DD, YYYY가 완벽하게 허용되는 형식이 아니라는 증거를 요구하고 있습니다. 제가 보기에는 아무도 제안하지 않습니다. 물론 DD MMM YYYY에 더 익숙한 사람들은 MMM DD, YYYY를 인식하고 이해하고 있으며, 그렇지 않다고 제안하는 것은 터무니없는 일입니다. 이것은 허용 가능성이 아니라 선호도에 관한 것입니다. 제가 선호하는 것은 YYY-MM-DD이고, 그 선호도를 충족시킬 수 있는 시스템을 원합니다. 저의 선호도는 MMM DD, YYYY, DD MMM YYYYY를 받아들이거나 이해하는 능력에 전혀 영향을 미치지 않습니다. 당신의 증거는 사람들이 DDMMMYYYYYY와 동시에 MMM DD, YYYYY를 받아들이거나 이해할 수 있다는 것을 보여주지만, 저는 그것이 그 이상의 것을 보여주지는 않는다고 믿습니다. 건배, 이 깃발은 빨간색이었던propagandadeeds 적이 있습니다. 2009년 4월 4일 (UTC)응답하라.

(중립 투표에 대한 응답으로) 사실, 중대한 문제가 하나 있습니다: 상당하지 않은 비율의 날짜들이 잘못 입력되고(예를 들어, 9월 4일의 예), 제안된 시스템은 각 개인의 가능성을 수정하도록 프로그래밍되어야 합니다. 또 다른 이유는 단순한 고정 텍스트 날짜에 대한 편집자의 통제를 방해해서는 안 된다고 생각합니다. Tony(talk) 2009년 4월 4일 (UTC) 06:43 답변[답변]

{{#형식 날짜:2007년 9월 4일 dmy}는 "2007년 9월 4일"을 제작합니다. 편집자가 자동 포맷 코드 없이 단순히 잘못 작성된 날짜를 입력하는 것보다 더 나쁜 상황을 만드는 방법은 없습니다. 저는 자동 서식 지정 질문에 두 가지 숨겨진 하위 질문이 포함되어 있다고 생각하기 때문에 "중립"이라고 투표했습니다. (1) #format date의 사용을 허용해야 하는지, (2) 그 사용을 요구(또는 권장 또는 권장 등)해야 하는지 여부입니다. 저는 첫 번째에는 "예", 두 번째에는 "아니오"로 투표할 것입니다. 따라서 합산된 질문에 대해서는 중립입니다. 편집할 때 추가 마크업 코드를 통과해야 한다고 불평하는 사람들이 있다는 것을 알고 있지만, 개인적으로 그것은 큰 문제라고 생각하지 않습니다. 그리고 한편으로는, 어떤 사람들은 모든 기사의 모든 날짜를 동일한 형식으로 볼 수 있는 것이 중요하다고 생각하는 것 같습니다. 하지만 저는 미국과 영국의 철자법이나 그 밖의 몇몇 용어들이 기사마다 다른 것들을 사용하는 것과 같은 불일치를 허용(그리고 확실하게 지지)할 때, 이것이 큰 문제라고 생각하지 않습니다. --R'nB (Russ라고 불러주세요) 2009년 4월 4일 (UTC)12:17 (답변)
  • R'n'B, 영국 철자법에 대한 미국인의 지적에 동의합니다. 미국인으로서, "나는…"를 만나는 것이 내 생각의 흐름을 방해하는 반면, "4월 4일"이나 "4월 4일"을 만나는 것은 내 생각의 흐름을 방해하지 않으며, 확실히 혼란스럽지 않습니다.

    문제는 "자동 포맷"이 우리 독자의 99.9%에게 전혀 해당되지 않는다는 것입니다. IP 사용자의 경우 특정 문서에서 수행하는 모든 작업은 기본 형식 또는 다른 형식으로 수행됩니다. 그리고 날짜를 고정된 텍스트로 쓰는 것보다 더 나은 것은 없습니다. 오토매팅(환경설정에 따라 날짜를 제시)의 실질적인 *편익*은 등록된 편집자에게만 적용됩니다. 혼란이 발생하지 않는 순수한 스타일 문제를 해결하기 위해 소수의 사용자에게 혜택을 주는 것은 그다지 큰 무리가 없습니다.

    일부 편집자들에게, 이것은 그들의 방식과 다른 데이트 스타일을 결코 보지 못하는 큰 소동일 뿐입니다. 사실, 저는 데이트 형식을 보는 것을 감당할 수 있고, 보는 즐거움을 위해 다른 사람들이 뛰어 넘어야 한다고 주장하는 사람들에게 인내심이 없기 때문에 "이해"하지 못합니다. 프로그래머에게는 멋진 코드에 관한 것입니다. 하지만 그들은 에스키모들에게 냉장고를 팔려고 합니다. Greg L (talk) 2009년 4월 5일 (UTC) 02:23 답변[답변]


솔직히, 모든 것이 제게는 어리석은 것처럼 보입니다. 자동 포맷은 불일치를 숨기고, "윌리엄 슈벵크 길버트 경(1836-11-181911-05-29)"과 같은 잔혹 행위를 보이지 않게 만드는 것입니다. (1836-11-18–1911-05-29)라고 쓰여 있는 것처럼, 표준 포맷이 아닌 포맷을 사용해야 할 충분한 이유가 있는 상황에서는, 각주의 "Accessed 2009-05-04"와 같이 컴팩트함이 유리한 경우, 덜 적합한 것으로 대체됩니다. 뭐가 중요해요? 다음은? 그리스의 독자들은 마케도니아를 그리스 지역으로 향하게 하고, 마케도니아 국가의 독자들은 그리스 지역으로 향하게 할 것인가요? 그럴만한 가치가 없습니다. 문제를 찾는 해결책입니다.

또한 정확한 견적의 날짜 문제 및 기타 문제 때문에 자동 형식화 날짜는 일종의 마크업이 필요합니다. 배의 일지에서 인용된 것은 "13-01-1897: 육지 발견"으로 시작할 수 있습니다. 코스를 조정했습니다.." 텍스트가 자동으로 변경되고 사용자가 날짜 형식을 해제하는 모호한 방법을 몰랐다면, 검색할 때 일관된 형식을 요구하는 소수의 환자들의 편의를 위해 우리는 사소한 방식으로 편집 인터페이스의 사용성을 손상시킬 수 있었습니다. 그래서 우리는 업데이트를 해야 합니다. 날짜를 자동으로 표시할 수 있습니까? 아니요, 직접적인 인용문도 발견하기 어렵습니다. 이제 수백만 개의 기사에 대한 수동 날짜 표시를 살펴봅니다. 젠장! 여러분은 때때로 무서운 "3월 3일"이나 "3월 3일"과 마주하면서 살아가는 법을 배우게 될 것입니다. 평범한 사람들처럼. 구두장이의 휴일 (talk) 2009년 4월 5일 06:31 (UTC)답장[답장]

이탈리아 독자들이 디저트로 바로 갈 수 있다면 마케도니아에 대한 이야기는 좋은 생각이 될 것입니다. :-) A. di M. (구 육군 1987) — 아니라 행동입니다. 2009년 4월 5일 19:03 (UTC)답장[답장]

에 대한 진술은 편향되고 거짓입니다. 창작 콘텐츠는 "사용자 인터페이스"가 아닙니다. # 독자와 편집자가 "사용자"라는 잘못된 태도를 배반하고, GPL GFDL에 의해 보호되는 저의 창작 기여는 "사용자 환경설정"을 지원하기 위해 기계에 의해 다시 작성되어야 하는 "사용자 인터페이스"라는 진술입니다. "운영 체제에서 개인화된 날짜 형식"은 읽고 있는 책을 다시 쓰거나 듣고 있는 음악의 언어를 수정하지 않습니다. 이 설명은 편향적이고 잘못된 것이며, 그것을 읽고 투표하는 편집자들을 오도하고 있습니다. 마이클 Z. 2009-04-11 16:41 z

"자신의 글이 남의 이익을 위해 무자비하게 편집되거나 재배포되는 것을 원하지 않는다면 제출하지 마십시오." 위의 편집에서 "기계"가 제외되었다는 언급은 없나요? --WebHamster 2009년 4월 17:11 (UTC)답장[답장]
또한 여기에 있는 내용은 GPL이 아닌 GFDL 아래에 있습니다. 플레처 (talk) 2009년 4월 11일 17:14 (UTC)답장[답장]
틀려요. GFDL은 내 텍스트를 변경하는 모든 사람에게 GFDL 아래에서 수행하도록 요구합니다. 페이지 내용을 다시 작성하는 환경설정에는 GFDL이 첨부되지 않으며, 기사의 편집 기록에 추가된 변경에 대한 크레딧도 없습니다. 이 사이트는 스킨을 사용하여 스타일을 변경할 수 있지만 내 GFDL 릴리스 조건에 따르면 내 텍스트를 편집하면 내 저작권을 침해합니다. 마이클 Z. 2009-04-11 17:45 z
WP 참조:GFDL#4._수정된 문서의 배포 의무에 대한 수정. 마이클 Z. 2009-04-11 17:54z
IANAL, 하지만 단순한 날짜 문자열의 변경은 최소일 가능성이 높습니다. "페이지 내용 다시 쓰기"라는 표현은 저작권이 있는 저작물이 아닌 날짜 문자열이라는 점을 염두에 둘 때 훨씬 약합니다. 또한 구현을 고려해야 합니다: 템플릿이나 다른 위키 마크업을 사용하는 경우 자동 포맷에 동의했습니다(그렇지 않았다면 해당 구문을 사용하지 않았을 것입니다). 또는 특별한 마크업을 사용하지 않는 경우 봇이나 사람이 편집 기록에 반영될 기사를 변경해야 할 가능성이 높습니다. 플레처 (talk) 2009년 4월 11일 (UTC) 19:58 답변[답변]
템플릿은 법문 라이선스 문제를 나타낼 수 있지만, 적어도 사용자가 배치하고 사용자가 변경합니다. 사용자의 작업은 모두 편집 요약에 나타나므로 GFDL이 관리합니다.
그러나 등록된 사용자 또는 등록되지 않은 사용자가 텍스트를 다시 쓰기 시작할 수 있도록 설정하면 다른 웜이 발생할 수 있습니다. 다음에는 블라인드 철자 검사, 해적 대화 필터, 그리고 다음에는 무엇이 필요한지 누가 알겠습니까? 크레딧에 로컬 편집기 없이 기계 번역 버전의 외국어 기사를 자동으로 로드해야 합니까? 중국어로 기계 번역된 기사 크레딧의 마지막 이름을 원하십니까? 사양하겠습니다.
드 미니무스는 법적인 개념이지만, 우리는 사람들의 글의 내용에 대해 이야기하고 있습니다; 먹는 것, 먹는 것, 먹는 것, 먹는 것, 잎과 먹는 의 내용은 낮은 쉼표라는 것을 기억하세요. 독자 분이 원하는 모든 인간 편집자와 교정자를 제 글에 넣을 수 있지만, 저는 그것을 GFDL 산하의 책임 있는 편집자가 감독하지 않는 기계에 맡기지는 않을 것입니다. 철자 검사를 하는 사람은 편집자를 교체하지 않을 것이고, 전문적인 수준의 문서를 만들기 위해서도, 제 작품을 수정하고 다시 출판하는 것에 대한 법적 책임을 지지 않을 것입니다. 마이클 Z. 2009-04-112 3:28 z
저는 당신이 WP에 기여하는 기사 또는 그 일부에 대한 소유권을 주장하는 것이 걱정됩니다. 당신과 다른 글꼴로 읽어도 괜찮을까요? 또는 음성 판독기를 사용하거나 기계 번역을 사용하여 프랑스어로 읽는 것을 선호합니다. 우리 중 한 명이 요점을 놓치고 있습니다. "당신의" 작품, 창의적 기여, 텍스트가 "재출간"되는 형식에 대한 궁극적인 통제권을 가지고 있다고 생각한다면, WP에 올리지 마십시오. 그렇지 않다면, 제가 예를 들어준 것과 (수동적이든 자동적이든) 날짜 형식을 변경하는 것의 차이점은 무엇일까요? 저는 독자 분이 생각하시는 것처럼, 아무도 "당신의" 텍스트를 절대로 건드려서는 안 된다는 것을 암시하는 투표 입장을 볼 수 없습니다. 제가 완전히 오해한 건가요? Simon Trew (talk) 2009년 4월 12일 04:26 (UTC)답장[답장]
그러시군요. WP:OWN은 편집 분쟁에 관한 것이며 이와 관련이 없습니다.
개인 용도로 원하는 방식으로 기사를 변형할 수 있습니다. 하지만 위키피디아가 기사를 웹사이트에 공개적으로 표시하여 배포할 때는 라이선스에 구속됩니다. WP 읽기:Copyright는 "위키백과의 텍스트는 위키백과 편집자와 기고자에 의해 저작권이 있으며 GNU 자유 문서 사용 허가서에 따라 공식적으로 대중에게 라이선스가 부여됩니다."라고 말합니다. GFDL에 따르면 편집자 버전에서 기사가 수정된 경우 위키백과는 수정에 대한 공로를 인정하지 않고 기사를 표시해서는 안 됩니다. 위키백과:GFDL:
  • “§ 0. PREAMBLE: ... 이 라이센스는 작성자와 게시자가 자신의 작업에 대해 신용을 얻을 수 있는 방법을 유지하는 반면, 다른 사람이 수정한 것에 대해서는 책임이 없다고 간주됩니다.
  • § "1. 적용 가능성 및 정의: ... 문서의 "수정된 버전"은 문서 또는 문서의 일부를 포함하는 모든 작업을 의미하며, 복사된 언어이거나 수정 및/또는 다른 언어로 번역된 작업을 의미합니다.
  • § "2. VERVATIM Copyring: ... 당신은 공개적으로 사본을 표시할 수 있습니다. ...
  • § "4. 수정: ... 수정된 버전에서 다음과 같은 작업을 수행해야 합니다.
    • "A. 제목 페이지(및 표지에 있는 경우)에 문서와 구별되는 제목과 이전 버전과 구별되는 제목을 사용합니다.
    • "B. 제목 페이지에 작성자로서 수정된 내용의 작성자를 한 명 이상의 개인 또는 주체로 나열합니다.
    • "E. 다른 저작권 고지에 인접한 수정 사항에 대한 적절한 저작권 고지를 추가합니다....
    • "I. "역사"라는 제목의 섹션을 보존하고 거기에 적어도 수정된 버전의 제목, 연도, 새 저자 및 게시자를 명시하는 항목을 추가합니다."
제가 꾸며낸 게 아닙니다. 당신과 저는 라이선스에 구속되어 있고, 위키미디어 재단도 마찬가지입니다. 라이선스에는 수정된 사항은 배포된 사본에서 확인해야 한다고 나와 있습니다. 마이클 Z. 2009-04-12 16:04 z
장과 구절을 인용할 필요가 없었습니다. 저는 참조를 찾을 수 있습니다. 어쨌든, 저는 이것이 정말로 이 특정한 논의의 막다른 골목이라고 생각합니다. 리퍼블리싱 에이전트가 자연인이어야 한다는 말은 없습니다. 위키피디아 페이지 렌더링 엔진은 페이지 하단에 "원문을 보러 가라"는 내용의 저작권 안내문을 ack 수 있습니다. 사실, 렌더링된 버전은 편집된 텍스트와 ipso facto이기 때문에(가장 작은 마크업도 가정할 때) 이미 그렇게 해야 한다고 주장할 수 있습니다. 예를 들어, 사진을 썸네일로 축소하는 경우. 이 조항들은 사람들이 위키백과 기여자들을 전체적으로 인정하지 않는 것을 막기 위한 것이지, 렌더링을 위한 사소한 변경을 멈추기 위한 것이 아닙니다. 저는 번역을 시작했고 GFDL에 따라 원본을 신용해야 하지만, 그것이 제가 기사를 바꿀 수 없다는 것을 의미하는 것은 아닙니다. 사실 적절한 곳에서 기사를 변경하는 것이 권장됩니다. GFDL의 목적은 커먼즈와 위키백과 등을 보호하고 공정한 사용을 보장하는 것입니다. 그렇다고 해서 페이지를 서버나 클라이언트, 또는 안경을 벗을 때 내 눈이 흐릿하게 보이는 등 다른 엔진에 의해 다른 방식으로 렌더링할 수 없다는 의미는 아닙니다. 여기서 모든 종류의 언급을 인용하지는 않겠지만, 80년대 초반의 전체 Look and Feel 주장(Lotus 1-2-3 vs Borlland Quattro)은 미국의 법률에서뿐만 아니라 모든 곳에서 실제로 그렇게 확립했습니다. 사이먼트루 (talk) 2009년 4월 12일 22:08 (UTC)답장[답장]
빨간 청새치 무리 (제가 가장 좋아하는 것은 "이제 논의가 끝났고, 여기 그 이유를 설명하는 200개의 단어가 있습니다.")
네, 편집은 권장되지만 GFDL에서는 허용되지 않습니다. 저는 제 "외모와 느낌"에 대해 저작권을 주장하는 것이 아니라 제가 쓴 글귀에 대해 저작권을 주장하는 것입니다. 당신의 흐릿한 눈이 면허증의 명시적인 조건을 존중하지 않고 이 단어들 중 일부를 다시 쓰는 것과 무슨 상관이 있습니까? 아무 것도 없어요.
GFDL은 개인이든 법인이든 재출판 대리인이 누구든 수정에 대한 공로를 인정해야 한다고 말합니다. 그리고 저작권 고지와 함께 필요한 제목 변경 및 신용 승인도 충분할 수 있지만 재단은 그렇지 않습니다. 모든 기사에서 연결된 저작권 공지에는 저작권은 재단이 아닌 편집자가 가지고 있다고 명시되어 있습니다. 마이클 Z. 2009-04-13 20:25z
따라서 저작권 고지를 해야 한다고 주장하세요. 그것은 논의와 무관합니다. 또한 제가 그런 종류의 말을 한 적이 없는데 그 인용문으로 시작하는 것은 당신이 약간 기발한 것입니다. 저는 당신이 둘 다 말하지 않았다고 말할 것이라는 것을 알고 있지만, 그렇게 대답을 하는 것은 그것을 암시합니다. 그러니까... 위키피디아에서 사용되는 모든 문구, 단어 또는 인용문에는 마크업 및 저작권 참조가 있어야 한다고 제안합니다. 그래서 처칠을 인용한다면 좋은 출처(아마도 영어를 사용하는 사람들의 역사)가 있는지 확인하고 그것이 저작권에 있는지 없는지 확인하는 것이 좋습니다. 말도 안 되는 소리. 저작권 문제는 전혀 관련이 없고, 어떤 빨간 청새치가 있었든 간에, 당신은 그것들을 지적하지 않았습니다. 200자도 안 되는 말로 토론이 끝났습니다. 사이먼트루 (talk) 2009년 4월 13일 (UTC) 23:14 답변[답변]
Martindelaware의 질문에 답하기(지원 189)

자동 포맷 시스템은 (찰스 다윈으로부터) 이 조각들을 다시 포맷하는 것을 처리할 수 없습니다." "1838년 9월 28일, 그는 이 통찰력에 주목했습니다." "1838년 9월 28일, 그는 이 통찰력에 주목했습니다." "그는 1882년 4월 19일에 사망했습니다." "그는 1882년 4월 19일에 사망했습니다."" 한 해가 마침표(또는 괄호 또는 대시와 같은 다른 구두점 문자)로 이어질 때 마크업의 구문을 복잡하게 하거나 실수를 하지 않습니다. 현재 사용되지 않는 DA 시스템은 배치를 생성하는 데 필요한 두 번째 쉼표를 제공하지 못합니다. 저는 어떤 "DA의 아들"이라도 더 잘 할 것이라는 제안을 본 적이 없습니다. 사실, 제안된 DA는 기본 설정을 가지고 있지 않은 많은 편집자들로부터 누락된 두 번째 쉼표를 숨겨서 오류를 증가시킬 것입니다. --RexS (토크) 2009년 4월 12일 (UTC)응답하라[답변]

월-일 연계

배경문

월-일 연결(month-day linking)은 일 및 월 조합(예: [[3월 24일]])에서 마크업(이중괄호)을 연결하는 것으로, 특정 날짜 기사([3월 24일])에 대한 링크를 만듭니다. 월-일 연결은 편집자들이 이러한 기사에 대한 링크를 작성하는 데 사용되었으며, (2003년부터 2008년까지) 자동 형식 날짜(위를 참조)에 사용되었습니다.

월-일 연계의 장점
  1. 날짜 기사에 쉽게 액세스할 수 있습니다.
  2. "여기서 링크되는 내용" 페이지를 관련성이 있는 데이터로 채웁니다.
  3. 편집자가 덜 정밀한 "검색" 기능과 비교하여 대상에 대한 직접 링크를 제공합니다.
  4. 논리적이고 쉽게 이해할 수 있으며 편집 커뮤니티에서 2003년부터 널리 사용되고 있는 구문을 사용합니다.
  5. 독자들이 출생일과 사망일, 축하일(세인트 패트릭 3월 17일, 가이 포크스 11월 5일) 또는 관례적인 이름(예: 1792년 8월 10일~18 브루마이어 링크)을 포함하여 날짜에 대한 기사를 합리적으로 보고 싶어하는 경우에 대한 링크를 제공합니다.
월-일 연계의 단점
  1. 기사 주제와 관련성이 거의 없거나 전혀 없습니다. 여기에는 거의 모든 경우에 다음 링크가 포함됩니다.
  2. 고부가 링크(오버링크)를 희석합니다. 월일 페이지에 대한 링크가 독자들에게 잠재적인 관심사가 될 수 있는 경우, 기사의 본문보다는 참조 섹션에 표시하는 것이 좋습니다.
  3. 월-일 링크는 독자가 링크를 따라야 하는 이유에 대한 설명을 제공하지 않습니다. 이러한 링크에 대한 참조 섹션을 사용하면 설명 텍스트를 제공할 수 있습니다.
  4. 날짜에 대한 "여기서 링크하는 것"은 일반적으로 유용성이나 관련성이 의심스러운 결과를 많이 생성합니다. 정확한 "검색" 기능을 포함하고 "site:wikipedia.en"을 구글 검색에 추가하여 날짜를 검색하는 강력한 도구가 이미 있습니다.
월 단위 마크업의 장점(링크를 수반하는지 여부)
  1. 봇/스크립트가 인식할 수 있는 날짜 문자열을 명확하게 표시하여 기사 텍스트의 자동 처리 및 메타데이터 수집을 단순화합니다.
월 단위 마크업의 단점
  1. 혼란스러운 구문과 추가 키 입력으로 편집 과정을 복잡하게 만듭니다.
  2. 가능한 "메타데이터"는 기존 도구의 것에 아무런 가치를 부여하지 않기 때문에 특별한 마크업의 사용을 보장하는지 여부/이유가 불분명합니다.
월-일 링크에 대한 지침 제거의 장점
  1. 모든 링크에 적용되지 않는 월-일 링크에 대한 특정 지침은 지침 크리프입니다.
월-일 링크에 대한 안내 제거의 단점
  1. 날짜 기사를 연결하는 것은 '정상적인' 기사와 같지 않기 때문에 스타일 가이드에서 특별한 지침이 필요합니다. 거의 모든 날짜 기사는 이벤트 목록이며 동일한 날짜에 발생하는 우연에 의해서만 관련됩니다. 이러한 목록은 자신에게 연결되는 기사를 이해하는 데 도움이 되는 컨텍스트를 제공하지 않으며, 따라서 연결되어서는 안 됩니다. 날짜 기사가 실제로 역사적 맥락을 제공할 정도로 개선된 경우 이 지침을 검토해야 할 수도 있습니다.


합의를 통해 지원될 경우, 다음 네 가지 제안 지침 중 하나(옵션 1, 2, 3 또는 4)가 위키백과에 추가됩니다.스타일 매뉴얼(날짜 및 숫자)#날짜위키피디아 링크자동 포맷:linking#시간순항목. 아래 네 가지 옵션에 대해 답변 부탁드립니다.

월-일: 옵션 #1 (관련 날짜만 링크)

월간 기사(2월 24일7월 10일)는 그 내용이 주제에 대한 세균성 및 화제성이 없는 한 연결되지 않아야 합니다. 이러한 링크는 이벤트가 동일한 날짜에 발생한 것 이외에 해당 주제와 중요한 연결을 공유해야 합니다. 를 들어, 편집자는 날짜(또는 연도)를 (Sydney Opera House에서) 다음과 같은 문장으로 연결해서는 안 됩니다. "시드니 오페라 하우스는 2007년 6월 28일 유네스코 세계문화유산으로 지정되었습니다."라고 한 이유는 6월 28일이나 2007년 6월 28일의 내용 중 유네스코 세계문화유산이나 시드니 오페라 하우스와 관련된 내용은 거의 없기 때문입니다.
기념일(성 패트릭의 날)에 대한 언급은 다른 링크와 같이 취급됩니다. 본질적으로 연대기적 기사(1789년, 1월, 1940년대) 자체에 연결된 연대기적 항목이 포함될 수 있습니다.

월-일: 옵션 #2(기념 링크만 해당)

월일 기사(2월 24일 및 7월 10일)는 해당 날짜에 보통 발생하는 기념에 관한 기사(또는 주요 기사로 포함)가 아닌 이상 연결되어서는 안 됩니다. 예를 들어, 크리스마스12월 25일로 연결될 수도 있고, 패트릭의 날은 3월 17일로 연결될 수도 있습니다 (사순절로 인해 때때로 다른 날에 기념되지만).

월-일: 옵션 #3 (최초 발생 시 모두 링크)

월일 기사는 기사의 첫 번째 발생에 따라 연결될 수 있습니다. 두 기사가 서로 얼마나 관련이 있는지에 관계없이 말입니다.

월일 : 옵션 #4 (안내 제거)

월-일 링크를 다루는 모든 특정 언어는 스타일 매뉴얼 및 관련 페이지에서 제거됩니다. 이것은 다른 잠재적인 링크와 마찬가지로 월-일 링크를 다루는 효과를 가질 것입니다. (이것은 자동 포맷의 맥락에서 링크에 대한 언급을 포함할 필요가 없습니다. 이것들이 현재 지침인지 역사적인 메모인지는 위의 자동 포맷에 대한 질문에 달려 있습니다.)


월일응답

선택에 대한 간결한 설명과 함께 ONE 옵션으로 지지 투표를 표시해 주시기 바랍니다. 당신의 설명은 공동체의 합의를 결정하는 데 중요합니다.
옵션 #1(관련 날짜만 링크)을 지원합니다.
  1. 네 가지 중 가장 좋은 선택인 것 같습니다. Steve Crossin / 2009년 3월 29일 23:15 (UTC)응답하라[24응답하라]
  2. 링크 밀도를 줄이기 위해서는 일반적으로 관련 정보만 링크되어야 하며, 이는 날짜에 있어서도 다르지 않아야 한다고 생각합니다. 람보의 복수 (How do I hell?) 2009년 3월 29일 (UTC) 23:20 답변[답변]
  3. 제발 상식이 우세하도록 해주세요. 링크는 거의 관련이 없으며 주제에 대한 이해를 깊게 하는 데 거의 도움이 되지 않습니다. 오공자(talk) 2009년 3월 29일 (UTC) 23:23 답변[답변]
  4. WP에 따르면:오버링크. --John (talk) 2009년 3월 29일 (UTC) 23:36 답변[답변]
  5. 지원, 링크는 거의 관련이 없습니다. 날짜는 관련이 있을 수 있지만 연결되어 있는 날짜 기사는 거의 항상 그렇지 않습니다. Dabomb87 (talk) 2009년 3월 29일 23:49 (UTC)답장[답장]
  6. 그렇고 말고요. 예를 들어 날짜가 자체적으로 눈에 띄는 경우에도 말입니다. 성탄절, 성탄절이 발생하는 대목과는 무관할 수도 있습니다. --필차(Philcha)
  7. 지원: 날짜 링크는 거의 관련이 없으므로 너무 자주 할 필요가 없습니다. seecer talk 기고문 2009년 3월 29일 (UTC) 23:56 답변[답변]
  8. 지지하다. 이 조항이 상당히 좁게 해석되기를 바랍니다. -- 도널드 앨버리 2009년 3월 29일 (UTC)응답하라
  9. 서포트, 상식. 날짜에 대한 링크를 포함한 모든 링크는 기사 제목에 대한 이해를 높일 때만 존재해야 합니다. 레이븐(RavenTalk to meMy edits)197700:01, 2009년 3월 30일 (UTC)답장[답장]
    지원 저는 관련성에 대해 상당히 높은 기준을 가지고 있지만요. 저는 옵션 1,4,2,3의 순위를 매길 것입니다. Eluchil404 (talk) 2009년 3월 30일 (UTC) 00:05답글[답글]
  10. 지지하다. 상식적으로 옵션 4는 거의 정확히 동일한 효과를 가져야 한다고 생각합니다. 하지만 모든 사람들이 동의하는 것은 아니기 때문에, 이것이 문제를 해결하기 때문에 훨씬 더 좋습니다. --Hans Adler (talk) 00:08, 2009년 3월 30일 (UTC) 사실, 옵션 4는 싸움을 끝낼 가능성이 없기 때문에 최악의 옵션입니다. --Hans Adler (talk) 2009년 3월 31일 (UTC)10:24, 31일 (UTC)응답하라.
  11. 지원 날짜는 다른 것과 마찬가지로 연결되어야 합니다. 지원 날짜는 기사의 주제에 대한 독자의 이해를 향상시켜야 합니다.Awadewit (talk) 2009년 3월 30일 (UTC) 00:09 답변[답변]
  12. 지원 날짜를 연결해야 하는 드문 상황을 거의 다룹니다. 제안된 문구에 따르면 날짜는 "내용이 주제에 대한 세균성 및 화제성이 없는 한 연결되지 않아야 합니다." 충분히 말했습니다. Greg L (talk) 2009년 3월 30일 (UTC) 00:30 답변[답변]
  13. 지원: 무의미한 링크를 줄이고, 엄격하게 유용한 이상한 경우를 허용합니다. 날짜 연결 및 자동 포맷과 관련된 논란이 많은 문제로 인해 날짜는 "일반 링크"와 별도로 취급해야 합니다.MCollins (talk) 00:40, 2009년 3월 30일 (UTC)응답[답변]
  14. 제거 안내 옵션을 지지하는 경향이 있지만, 저는 모든 날짜를 연결하려는 과거의 경향이 지속적인 오버링크로 이어질 것이라고 생각합니다. 역사적으로 중요한 것들에 대한 날짜 링크를 제한하기 위한 지침이 필요합니다. -- Tcncv (talk) 00:46, 2009년 3월 30일 (UTC)답변[답변]
  15. 거의 모든 지지자들이 위에 있습니다. 핵전쟁 00:48, 2009년 3월 30일 (UTC)응답하라[응답하라]
  16. 지원 저도 제거 지침 옵션에 대해 고민했지만, 저는 애초에 우리를 여기에 있게 한 것은 이 문제에 대한 불일치라고 생각합니다. Casliber (talk·기여) 2009년 3월 30일 01:03 (UTC)답장[답장]
  17. 지원 이것은 위키링크에 대한 일반적인 지침을 자세히 설명하는 데 도움이 됩니다. Eubulides (talk) 2009년 3월 30일 01:29 (UTC)답장[답장]
  18. 는 가능한 한 적은 링크를 선호하고, 날짜 링크는 거의 관련이 없습니다. Ealdgyth - Talk 01:48, 2009년 3월 30일 (UTC)응답하라[답변]
  19. 지지: 무분별한 날짜 연계는 독서 경험을 방해할 뿐입니다. 중세시대의 전투를 클릭한 날짜는 타이타닉이 기록적인 오스카상을 수상한 날을 보여주기 보다는 그 당시 관련된 세부사항을 가리켜야 합니다. Japalang (talk) 2009년 3월 30일 01:53 (UTC)답장[답장]
  20. 지지: 저는 제가 읽고 있는 것과 전혀 관련이 없는 최신 기사들을 소개하는 기사들에서 파란색 링크를 보는 것에 싫증이 납니다.SteveB67 (talk) 2009년 3월 30일 02:13 (UTC)답장[답장]
  21. 시어당.줄리안콜튼Talk 2009년 3월 30일 02:15 (UTC)답장[답장]
  22. 사실, 저는 옵션 4를 가장 지지합니다. 지침이 없다는 것은 전쟁을 수정하는 것을 의미하지 않으며, 실질적인 결과는 이 지침과 동일할 것입니다. 여론조사 형식은 표면적으로 여러 가지 옵션을 지원하는 것을 허용하지 않기 때문입니다. (왜요? 진지하게요, 왜요?) 저는 이미 언급한 바에 근거하여 이를 지지합니다. 실제로는 옵션 4와 동일하며, 실제로는 다른 사람들의 지지를 받을 가능성이 더 높습니다. 그러나 귀하의 여론조사 형식은 어떤 경우에도 깨집니다. Gavia immer (talk) 2009년 3월 30일 03:08 (UTC)답장[답장]
  23. Support.-gadfium 2009년 3월 30일 (UTC) 03:23 답변[답변]
  24. 지원월일 항목을 연결하는 시기(예: 매우 드물게)에 대한 이러한 보수적인 지침은 WP에서 이미 확립되어 있습니다. 이 프로젝트는 현재 위키링을 사용함에 있어 성숙 단계에 있습니다. 원래의 규율 없는 산포에서 보다 선택적인 접근 방식(원하는 경우 스마트 링크)으로, 고부가가치 링크를 희석하지 않습니다. 그럴 시기가 됐지요. 독자들의 마음을 끄는 것은 푸른 바다 이상이며, 그들은 아무것도 클릭하지 않는 경향이 있습니다. Tony (talk) 2009년 3월 30일 03:45 (UTC)답장[답장]
  25. 다른 사람들과 마찬가지로 날짜를 연결하는 것은 불필요하고 여분의 파란색을 싫어합니다. 2009년 3월 30일 (UTC) 04:39 (답장)
  26. 지원. 지금은 축소된 자동 포맷 시스템이 링크를 우연히 만들지 않았다면, 링크 날짜에 대한 추가 안내가 필요하지 않을 것입니다. 하지만 그렇게 했고, 그렇게 했습니다. 링크는 기사의 관련성에 기초하여 이루어져야 합니다. 수백만 개의 부당한 링크는 제거되어야 합니다. 또한 대부분의 월-일 페이지의 이름을 역사 전체 월-일 이벤트 목록과 같은 것으로 변경하는 것을 지지합니다. (talk) 2009년 3월 30일 (UTC) 04:46 답변[답변]
  27. 서포트. 가장 합리적인 텍스트인 것 같습니다. 취급이 다른 링크와 크게 다르지는 않지만(해당하는 경우에만 링크) 날짜 링크는 부적절한 경우가 너무 많기 때문에 특별한 지침이 필요합니다. --Srleffler (talk) 2009년 3월 30일 (UTC)04:51 (답변)
  28. 지원Chris! 2009년 3월 30일 (UTC) 05:03 회신[답변]
  29. 서포트. 희귀한 링크는 물론 괜찮습니다. 우리에게 필요한 것은 일상적인 연결입니다. Fut.Perf. 2009년 3월 30일 06:00 (UTC)답장[답장]
  30. 서포트. 날짜 연결은 문제를 찾는 엉성한 해결책입니다. Bishonen talk 06:44, 2009년 3월 30일 (UTC)회답[회답]
  31. 두 번째 옵션으로 지원(옵션 4 아래 주석 참조). 저는 옵션 4를 선호합니다. 이 여론조사가 단일 선택만 지원하는 것이 최선이라는 것을 받아들이지 않는 것과 거의 같은 이유로 :-) AKAF (토크) 07:01, 2009년 3월 30일 (UTC)응답하라[답변]
  32. 지원 날짜 링크가 포맷되지 않으면 관련 없는 날짜를 링크하는 것이 도대체 무슨 의미가 있습니까? oren0 (talk) 2009년 3월 30일 07:15 (UTC)답장[답장]
  33. 지원 링크는 관련성이 분명하고 맥락을 설명하는 데 필요한 예외적인 경우에만 날짜를 지정해야 합니다. Dougweller (talk) 2009년 3월 30일 08:06 (UTC)답장[답장]
  34. 서포트. 이 옵션은 각 날짜 링크가 관련이 있어야 함을 명시적으로 명시하는 유일한 옵션입니다. 그 이상도 이하도 아닌. 이는 날짜가 아닌 링크의 경우에도 마찬가지이지만 오랜 기간 동안 오버링크를 한 후 편집자는 명시적인 지침이 필요합니다. 라이트마우스 (talk) 2009년 3월 30일 08:23 (UTC)답장[답장]
  35. 지원, 해당 날짜는 결코 "관련성"이 없다는 주의 사항이 있습니다. Bongomatic 2009년 3월 30일 09:02 (UTC)답장[답장]
  36. 서포트. 지금 기사들을 혼란스럽게 하는 관련 없는 날짜 링크들을 모두 없애 버리면 복이 있을 것입니다.--HJensen, talk 09:06 (UTC)답변[답변]
  37. 서포트. 일관성을 위해 규칙이 필요합니다(옵션 4에는 없음). 날짜는 일반적인 링크가 아닙니다(따라서 옵션 3까지는 아닙니다). 날짜 기사가 발생할 위험이 없다고 봅니다(옵션 2에는 없음). 해당 기사가 특정 기사와 관련이 있을 경우 연결됩니다(옵션 1에는 있음). YLee (talk) 2009년 3월 30일 09:21 (UTC)답장[답장]
  38. 위의 의견에 따라 지원합니다. 익스트림 프로 (talk) 2009년 3월 30일 09:26 (UTC)답장[답장]
  39. 서포트. 더 이상 말할 필요가 없습니다. 이것과 저것 그리고 나머지 2009년 3월 30일 09:28 (UTC)답장[답장]
  40. 서포트. 링크는 항상 독자와의 관련성과 가치에 따라 판단해야 합니다. TKD::{talk} 2009년 3월 30일 (UTC) 11:09 답변[답변]
  41. 지원 (이것 또는 옵션 2; 실제로 어떤 차이가 있는지 잘 모르겠습니다. 두 경우 모두 문구를 더 조여야 할 것 같습니다.) --Kotniski (talk) 2009년 3월 30일 (UTC)11:21 (답변)
  42. 지원 링크는 거의 관련이 없습니다. 기사와 편집창은 위키링크와 마크업 없이도 더 깨끗해 보입니다. - kollision (talk) 2009년 3월 30일 (UTC) 11:45 (답변)
  43. 지지해주세요. 그냥 "일"(생일 등)로 끝나는 날들과 연결하고 싶지는 않지만, 휴일이나 세계 행사에 그 날 무슨 일이 일어나고 있는지 연결되지 않은 페이지가 있는 것은 오히려 이상할 것입니다. 방드럼 (talk) 2009년 3월 30일 (UTC) 11:55 답변[답변]
  44. TKD당 지원. 페리돈 (talk) 2009년 3월 30일 12:19 (UTC)답장[답장]
  45. 지원자 ɢʨ / 2009년 3월 30일 13:12 (UTC) 답변[답변]
  46. 지원 - 관련성이 있을 때만 제게 가장 의미가 있습니다. Camw (talk) 2009년 3월 30일 13:39 (UTC)답장[답장]
  47. 지원 - 지난 몇 달 동안 익숙해진 내용이며, 다른 링크와 마찬가지로 작동합니다. 이는 4번에 해당하지만, 이곳의 역사 때문에 특별한 지도가 필요합니다. --NE2 13:40, 2009년 3월 30일 (UTC)답장
  48. 서포트. WP는 다음과 같습니다.OVERLINK는 날짜가 다를 이유가 없다고 말합니다.에밀 J. 13:42, 2009년 3월 30일 (UTC)답장[답장]
  49. 마지못해 지원한다', 이게 최선의 선택이라고 생각하지만, 거의 관련이 없습니다. Sandy Georgia (Talk) 2009년 3월 30일 13:43 (UTC)답장[답장]
  50. 지지하지만 우리는 더 강력하고 그러한 연결은 지침과 거의 관련이 없다고 말해야 합니다. GR베리 2009년 3월 30일 14:04 (UTC)답장[답장]
  51. 가 읽고 있는 내용과 관련된 내용이 없는 기사 링크를 보는 것을 싫어합니다. 무의미합니다. - Dumelow (talk) 2009년 3월 30일 (UTC) 14:17 (답변)
  52. 든든한 지원군. 날짜 링크는 거의 관련이 없습니다. 날짜 링크가 있으면 언제든지 이 방법이 최선의 해결책인 것 같습니다. Cnilep (talk) 2009년 3월 30일 14:34 (UTC)답장[답장]
  53. 서포트. 제거 지침을 선택했을 수도 있지만 먼지가 몇 달 또는 몇 년 동안 가라앉지 않을 것입니다. 길에 불을 붙이면 도중에 약간의 돌기를 피할 수 있습니다.The Sidhekin (talk) 2009년 3월 30일 14:58 (UTC)답장[답장]
  54. 지원Bellhalla (talk) 2009년 3월 30일 (UTC) 15:08 답변[답변]
  55. 날짜가 연대순 기사에 연결되어 있지만 다른 목적으로는 연결되지 않는다는 을 지원합니다. 저는 다른 옵션에 강력하게 반대합니다. Karanacs (talk) 2009년 3월 30일 15:28 (UTC)답장[답장]
  56. 지원 특히 기사나 컨텍스트와 관련이 없는 한 날짜 링크는 거의 항상 비어 있는 링크입니다. 원래 기사에 거의 또는 전혀 표시되지 않는 위키링크의 대표적인 예입니다. 피그맨 /talk 15:35, 2009년 3월 30일 (UTC)답장[답장]
  57. 사용자별 지원을 꺼림:샌디 조지아. 저는 이러한 연결이 기사에 포함되어야 하는 어떤 상황도 생각하기 힘들어요. 그래서 저는 이것이 충분히 강력하다고 생각하지 않습니다. 하지만 그것은 네 가지 중에서 최선의 선택입니다. Pfainuk talk 15:37, 2009년 3월 30일 (UTC)답장[답장]
  58. 지원 아마도 앞으로 이 문제에 대한 공식적인 지침은 삭제될 수 있을 것입니다. 한동안 오락가락하는 문제였기 때문에 일단은 필요할 것 같습니다. --TreyGeek (talk) 2009년 3월 30일 (UTC) 15:48 (답변)
  59. 지지 대다수의 날짜 링크는 해당 기사와 관련이 없으며, 해당 기사에 고유한 의미가 있을 때만 사용해야 합니다. --캡틴터커 (토크) 2009년 3월 30일 (UTC) 15:52 (답변)
  60. 위 주장의 대부분강력하게 지지합니다. Johnny Au 15:55, 2009년 3월 30일 (UTC) 답변[답변]
  61. 강력한 지지 61명의 다른 사람들이 그것을 말했습니다. 위에서 읽으세요. Alan16 15:56, 2009년 3월 30일 (UTC)답장[답장]
  62. 지원은 과도하게 사용되어서는 안 되지만 날짜 자체에 대한 기사나 매우 구체적이고 잘 알려진 용도(예: 7월 4일)에 대한 링크에 사용되어야 합니다. Ordinchaos 2009년 3월 30일 16:02 (UTC)답장[답장]
  63. 지원아끼지 않음 --Deller (talk) 2009년 3월 30일 (UTC) 16:04 (답장)
  64. 지원, 주로 "여기서 링크"에 사용됩니다. 저는 옵션을 평가합니다: 1,2,4,3. 몇 년 후에 발생한 관련 없는 트리비아의 목록에 대한 쓸모없는 링크를 제거해 보겠습니다. Certes (talk) 2009년 3월 30일 16:06 (UTC)답장[답장]
  65. 지원, 불필요하게 기사를 오버링크할 필요가 없습니다. 플라스틱 포크 (talk) 2009년 3월 30일 16:23 (UTC)답장[답장]
  66. 서포트. 레트테타스트 (talk) 2009년 3월 30일 16:25 (UTC)답장[답장]
  67. 지지력이 약합니다. 가장 논리적인 것 같지만 실행하려면 신중한 작업이 필요합니다. Greggers 2009년 3월 30일 (UTC) 16:28 답변[답변]
  68. 서포트. 제가 선호하는 것은 모든 연결된 날짜를 제거하는 것이지만 이 옵션이 가장 좋습니다. 날짜와 특별한 관련이 없는 한 오버링크는 피합니다. --Skeeezix1000 (talk) 2009년 3월 30일 (UTC) 16:31 (답변)
  69. 서포트. 이는 관련 링크만 만들라는 일반적인 가이드라인과 일치합니다. Debresser (talk) 2009년 3월 30일 (UTC) 16:54 답변[답변]
  70. 서포트. 몇몇 드문 링크들이 있어서 이것이 그 링크들을 커버하는 것처럼 보입니다. -- Banjeboi 2009년 3월 30일 (UTC)응답하라[답변]
  71. 서포트. 이 토론의 역사를 보면 안내가 필요하므로 선택지 4가 충분하지 않습니다. 월요 기사 링크를 어떤 기사 링크와 다르게 취급할 이유가 거의 없으므로, 명백하게 관련된 기사만 링크해야 합니다. --RexxS (토크) 2009년 3월 30일 (UTC)응답하라[답변]
  72. 내용이 맥락과 관련이 없는 기사에 링크할 때, 우리는 독자들이 관련 기사에 링크되는 것을 방해함으로써 독자들에게 서비스를 제공합니다. 대부분의 경우 월-일 링크는 링크되는 기사의 컨텍스트와 무관합니다.Black Falcon(Talk) 2009년 3월 30일 (UTC) 17:21 답변[답변]
  73. 지원 링크는 의미론적 가치가 있는 링크가 아니라면 무의미하고 해롭습니다. Orange Dog (talk 편집) 2009년 3월 30일 17:24 (UTC)답장[답장]
  74. 지원 이것들은 무의미한 파란색 링크의 압도적인 다수를 구성해야 합니다! 이 기사들은 사건, 출생, 사망에 관한 크고 쓸모없는 목록일 뿐입니다. 누가 클릭합니까? Rupert Millard (Talk) 2009년 3월 30일 17:38 (UTC)답장[답장]
  75. 지지: 저는 루퍼트 밀라드가 제안한 것처럼 실제 월별 기사가 무의미하다고 생각하지는 않지만(저는 오히려 그것들을 좋아합니다!), 저는 그것들이 지금까지 해왔던 방식으로 연결되어서는 안 된다고 생각합니다. 저는 또한 옵션 #4가 무섭고 끊임없는 편집 경고로 이어질 것이라고 생각합니다(이미 발생하고 있으며 더 이상 필요하지 않습니다!). 저는 어딘가에 있는 어떤 가이드가 날짜 링크에 대해 승인된 인스턴스를 언급하고 (희귀한) 문제를 매우 단순하고 정의된 상태로 유지해야 한다고 생각합니다. Maedin\talk 2009년 3월 30일 (UTC) 18:16 답변[답변]
  76. 서포트. 이것은 "상식" 옵션이어야 합니다. 달리 그럴 이유가 없다고 생각하기 때문입니다. 날짜는 관련된 경우 다른 것과 동일한 규칙으로 연결되어야 합니다.2009년 3월 30일 (GMT) 18:19 †
  77. 서포트. 링크는 주로 기사에서 특정 용어를 정의하거나 추가로 설명하는 데 유용합니다. 아무도 3월 30일과 같은 날짜의 의미를 찾을 필요가 없습니다. Dirac66 (talk) 2009년 3월 30일 18:23 (UTC)답장[답장]
  78. 지원, 크리스마스 기사에서 12월 25일 링크 허용. 솔직히 이러한 링크들은 더 넓은 백과사전에서는 거의 도움이 되지 않지만 가끔 가치가 있습니다. --철학자 2009년 3월 30일 (UTC)응답하라[답변]
  79. Pro --Morten (talk) 2009년 3월 30일 (UTC) 18:26 답변[답변]
  80. 지원 옵션 1과 2. 참고: 명확성을 위해 두 목록에 모두 표시. davidwr/(talk)/(기여)/(이메일) 2009년 3월 30일 18:33 (UTC)답장[답장]
  81. 에 따라 지원하며 필요할 때만 링크합니다. AE talk/sign 2009년 3월 30일 18:38 (UTC)답장[답장]
  82. 위의 모든 것에 따라 지지합니다. Alarics (talk) 2009년 3월 30일 18:40 (UTC)답장[답장]
  83. 위의 Casliber 당 지원. 우리는 결정적인 것에 도달해야 하며 이 문제를 해결하기를 바랍니다.
    ⋙–베레안Hunter (() 2009년 3월 30일 (UTC) 18:59 답변[답변]
  84. 관련이 있는 경우 연결을 지원하지만 관련이 없는 경우 연결되지 않습니다. 사용자 선호 문제는 합의된 경우 다른 방식으로 처리할 수 있습니다. Mjroots (talk) 2009년 3월 30일 19:14 (UTC)답장[답장]
  85. 서포트. 제 생각에는 가장 유용한 옵션입니다. 라이프피 (talk) 2009년 3월 30일 19:26 (UTC)답장[답장]
  86. 지원 일반적으로 날짜에 대한 링크는 독자의 가치가 없습니다. Mr Stephen (talk) 2009년 3월 30일 19:54 (UTC)응답하라[답변]
  87. 가장 논리적으로 지원합니다. KellenT 2009년 3월 30일 (UTC) 20:19 답변[답변]
  88. 지원 오버링크에 대한 기존 정책과 가장 일치하는 가장 명확한 옵션입니다. Anaxial (talk) 2009년 3월 30일 20:48 (UTC)답장[답장]
  89. 지원 가장 논리적이고 실용적인 옵션입니다. ~EdGl 2009년 3월 30일 (UTC) 20:57 답변[답변]
  90. 지원 의견 2, 3, 5, 6 등에 동의합니다. CS46 2009년 3월 30일 (UTC) 21:11 답변[답변]
  91. 위키백과 기사의 지원 날짜 연결은 시작하기에 좋지 않은 아이디어였으며, 그보다 적을수록 좋습니다. JGHOWS 2009년 3월 30일 21talk:20 (UTC)응답하라[응답하라]
  92. 서포트. 가치가 있는 링크를 유지하면서 관련 없는 링크를 제거할 수 있습니다.Joe N 2009년 3월 30일 (UTC) 21:30 답변[답변]
  93. 서포트. 분명히 맞는 것 같습니다. Gareth McCaughan (talk) 2009년 3월 30일 21:34 (UTC)응답하라[응답하라]
  94. 서포트. 이상적인 세계에서는 옵션 4번이면 충분하겠지만, 실제로는 옵션 1번의 명확성이 가장 효과적일 것이라고 생각합니다.Josiah Rowe (talk 기고) 2009년 3월 30일 21:45 (UTC)답장[답장]
  95. 지원 이것은 말이 되는 유일한 선택입니다 - 새로운 독자들은 읽는 원래 주제와 관련이 없는 기사에 대한 날짜 링크로 계속 혼란스러워합니다. - Hunt (talk) 2009년 3월 30일 (UTC) 22:07 (답변)
  96. 서포트. 저는 오래 전부터 날짜 자동 포맷을 지지해 왔지만, 대부분의 날짜 링크는 관련이 없다고 믿었고, 별도의 자동 포맷과 링크를 가질 수 있기를 바랐습니다. Ross Patterson (talk) 2009년 3월 30일 22:13 (UTC)응답하라[답변]
  97. 서포트. 컨트리 마일의 네 가지 옵션 중 최고입니다. 위키피디아에는 이러한 월일 링크보다 덜 유용한 것이 거의 없습니다. Julianhall (talk) 2009년 3월 30일 22:22 (UTC)답장[답장]
  98. 지지 불성실 ( speak) 2009년 3월 30일 (UTC) 22:53 답변[답변]
  99. 상식에 맞는 지원: 관련 단어만 연결되므로 날짜가 있어야 합니다. -M.Nelson (talk) 2009년 3월 30일 (UTC) 23:08 답변[답변]
  100. 서포트. 관련이 있다면 독자에게 유용할 수 있으며 연결하면 독자의 관점에서 단순성을 높일 수 있습니다. Useight (talk) 2009년 3월 30일 (UTC) 23:52 답변[답변]
  101. 지원 - 날짜는 매번 연결하는 것이 아니라, 링크가 의미가 있을 때만 연결해야 합니다. --PresN 23:58, 2009년 3월 30일 (UTC)응답하라[답변]
  102. 지원 - 링크가 제거된 기사가 자주 있었습니다. 제가 그들을 놓치지 않았다고 말하는 것은 올해의 절제된 표현일 것입니다. Giants2008 (17-14) 00:18, 2009년 3월 31일 (UTC)답장[답장]
  103. 를 지지하는 것은 기존의 지침을 따르는 것이며, 단지 타당할 뿐입니다. 관련이 없다면 링크하지 마십시오. -- Collectonian (talk·기여) 2009년 3월 31일 (UTC) 01:58 (답변)
  104. 서포트. 해당 날짜에만 링크하는 것이 합리적인 판단. ddima.talk 2009년 3월 31일 (UTC) 02:07 답변[답변]
  105. 서포트. 위키피디아는 숫자학자들만을 위한 것이 아닙니다. VikSol 02:39, 2009년 3월 31일 (UTC)답장[답장]
  106. 지원, 옵션 1은 날짜 링크가 다른 링크처럼 취급된다는 것을 의미할 뿐만 아니라 전쟁을 되돌리는 데 종지부를 찍도록 하는 지침도 있을 것입니다. 연결은 이미 끝났고 연결 해제는 변화를 의미하기 때문에 가이드라인이 필요합니다. 만약 이매진이라는 단어가 매번 연결되어 있었다면 갑자기 연결되지 않았다고 상상해보세요. 가이드라인을 통해 단기적인 혼란을 방지할 수 있습니다. Sillyfolkboy (talk) 2009년 3월 31일 02:48 (UTC)답장[답장]
  107. 우리가 있어야 할 위치에 도달할 수 있는 모든 날짜의 대량 링크 삭제를 지원하고 또한 지원합니다. Hmains (talk) 2009년 3월 31일 (UTC) 03:06 (답변)
  108. 서포트. 날짜 링크의 99%는 기사 내용과 무관합니다. 레인보우 오브 라이트 2009년 3월 31일 03:26 (UTC)답장[답장]
  109. 첫 번째 선택. shoy(응답) 2009년 3월 31일 03:35 (UTC)답장[답장]
  110. 서포트 - 골디락 옵션입니다(너무 딱딱하지도 않고, 너무 부드럽지도 않지만, 딱 맞습니다). 날짜에 대한 링크는 거의 없을 것입니다만, 가끔 링크가 관련되어 있을 수도 있습니다. --Orlady (talk) 2009년 3월 31일 (UTC)03:53 (답장)
  111. 지원 - 저는 날짜를 다른 단어와 다르게 취급할 이유가 없다고 봅니다. 링크는 어떤 경우라도 관련이 있는 경우에만 사용해야 합니다. --Clay Collier (talk) 2009년 3월 31일 (UTC) 05:07 (답변)
  112. 지원 - 그러나 링크로 렌더링되지 않더라도 표시는 거기에 있어야 한다고 생각합니다. Nicolas 1981 (talk) 2009년 3월 31일 06:19 (UTC)답장[답장]
  113. 서포트. 완전히 이해가 됩니다. 제가 이 링크를 클릭했을 때 새로운 사용자로서 혼란스러웠던 것을 기억하고 관련된 다른 곳으로 갈 것으로 예상했지만 대부분의 경우 그렇지 않았습니다. 문의 사항이 있으시면 제 토크 페이지로 연락주시기 바랍니다. 이안 망카 2009년 3월 31일 (UTC) 06:21 답변[답변]
  114. 지원: 이 옵션은 위키백과의 기존 링크 정책과 가장 일치하는 것 같습니다. 옵션 4와 관련해서는 MoS에 기재해도 무리가 없다고 생각합니다. -- D. Wo. 06:46, 2009년 3월 31일 (UTC)답변[답변]
  115. 지원: 다른 링크와 마찬가지로 날짜 링크도 그럴만한 이유가 있어야 합니다. 대부분의 월간 기사는 유용한 맥락을 제공하지 않으며, 이는 단순히 기사 내의 외부 링크에 불과합니다. NJGW (talk) 2009년 3월 31일 07:46 (UTC)답장[답장]
  116. 지원: 제가 보기엔 분명해 보입니다. 링크가 말이 되는 경우에만 링크합니다. -- WORMM яOW 2009년 3월 31일 (UTC) 08:19 답변[답변]
  117. 지원 불필요한 링크를 줄이기 위한 최선의 방법입니다. --JD554 (토크) 2009년 3월 31일 (UTC)11:41 (답변)
  118. 상식적으로, 진짜. 무작위 날짜를 언급하는 무작위 기사에서 같은 무작위 날짜에 다른 일이 있었는지 알아야 하는 이유는 무엇입니까? Sandstein 2009년 3월 31일 11:48 (UTC)답장[답장]
  119. 서포트. 초보자는 관련 없는 링크가 있는 기사를 "개선"하지 않도록 지도가 필요합니다. 스파이크 프롬 NH (talk) 2009년 3월 31일 (UTC) 11:52 답변[답변]
  120. 지원하지만 옵션 #은 3월 24일과 같은 것에 대한 링크에 대한 예를 제공하지 않으며, 저는 스스로 또는 3월 24일을 읽을 이유를 생각할 수 없습니다. 그러한 기사는 100% 트리비아입니다. 콜린°Talk 12:43, 2009년 3월 31일 (UTC)답장[답장]
  121. 지원 - 날짜 연결은 기사에 거의 추가되지 않으며, 실제로는 기본적으로 WP입니다.오버링크. 프랭크 토크 2009년 3월 31일 13:49 (UTC)응답하라[답변]
  122. 지원 --Apoc2400 (대화) 2009년 3월 31일 (UTC) 15:06 (응답)
  123. 지원 - 1776년 7월 4일 및 1969년 7월 20일과 같은 몇 가지 관련 날짜만 링크합니다. Bubba73 (talk), 15:54, 2009년 3월 31일 (UTC)답장[답장]
  124. 지원 = 4가지 선택지 중 최선입니다. --Jc3s5h (talk) 2009년 3월 31일 (UTC)응답하라[답변]
  125. 대부분의 날짜 링크를 고려할 때, 지원은 도움이 되지 않는 사건이고 어수선할 것입니다. Gwen Gale (talk) 2009년 3월 31일 16:42 (UTC)응답하라[답변]
  126. 지원, 무분별한 날짜 연계는 무의미합니다. noq (talk) 2009년 3월 31일 17:03 (UTC)답장[답장]
  127. 서포트. 링크 밀도가 감소합니다. SlimVirgin 2009년 3월 31일 17:33 (UTC)답장[답장]
  128. 지원하지만, 저는 거의 옵션 2에 유혹당했습니다. "관련성"이라는 단어를 사용하면 전쟁을 편집할 수 있습니다. 그러나 새로운 점은 무엇입니까? David Brooks (talk) 2009년 3월 31일 17:45 (UTC)응답하라[답변]
  129. 그 제안을 지지하는 것은 직접적인 관련이 있는 기사만 연결하는 것이 아니라 관련성이 있는 기사만 연결하는 것에 대한 저의 기대를 충족합니다. 횡설수설하는 남자 (talk) 2009년 3월 31일 18:12 (UTC)응답하라[응답하라]
  130. 가장 논리적인 지원. 옵션 4가 모즈데이 가이드라인을 삭제한 후 다시 만드는 것을 배제하지는 않는 것 같습니다. -- Quiddity (talk) 2009년 3월 31일 (UTC) 18:14 (답변)
  131. 지지해주세요, 분명 못생겼으며, 분명 불필요해 보입니다. --Aqwis (talk) 2009년 3월 31일 (UTC) 18:36 답변[답변]
  132. 서포트. WP의 날짜 정책은 다음과 같습니다.OVERLINK는 스스로를 정당화합니다. Daniel J Simanek (talk) 2009년 3월 31일 18:44 (UTC)답장[답장]
  133. 지원 - 가장 합리적인 해결책으로 보입니다. 다른 모든 가능한 내부 링크와 마찬가지로 독자에게 추가 컨텍스트를 제공하는 관련 용어만 링크하는 것을 권장합니다. 그렇지 않으면 기사의 거의 모든 단어가 연결되어 아무에게도 도움이 되지 않습니다. 데이트도 마찬가지입니다. 어떤 식으로든 연관성이 없는데도, 왜 항상 날짜를 연결해야 한다는 강박관념은 저를 초월합니다. --IllaZilla (talk) 2009년 3월 31일 (UTC)19:09 (답변)
  134. 서포트. 이건 상식입니다. 또한, 반응을 유발할 수 있는 것을 제안하겠습니다. 봇이 실행되고 모든 월-일 링크를 제거한 다음 관련 링크를 다시 추가합니다. 제가 경험한 바로는, 관련된 것은 아주 적습니다. -- 마기올라염 (토크) 2009년 3월 31일 (UTC) 19:55 (답변)
  135. 강력한 지원: 거의 관련이 없고 관련이 없는 링크는 독자들에게 정신적 비용을 부과합니다. 또한 페이지가 어수선한 모양을 제공합니다. 링크를 덜 일반적으로 만드는 것은 남은 날짜를 더 돋보이게 할 것이며, 관련성이 있는 제한된 환경에서는 아마도 좋은 일일 것입니다. CRG Greathouse (tc) 2009년 3월 31일 19:57 (UTC)답장[답장]
  136. 지원, 월-일 연결은 거의 관련이 없습니다.Xavier, 2009년 3월 31일 21:17 (UTC)답장[답장]
  137. 지원, 월-일 연결은 거의 관련이 없습니다.Marky MarkD (talk) 2009년 3월 31일 21:47 (UTC)응답하라[답변]
  138. 지원, 월-일 연결은 거의 관련이 없으며 주로 시각적 혼란을 추가합니다. 그라운드 제로 2009년 3월 31일 (UTC) 23:39 답변[답변]
  139. 서포트. 거의 관련이 없고, 이런 방식이 좋을 것 같습니다. 현명한 친구321 (talk) 2009년 4월 1일 01:08 (UTC)답장[답장]
  140. 서포트. 과부하를 피하세요. --Kbh3talkrd 01:27, 2009년 4월 1일 (UTC)답장[답장]
  141. 서포트. 나도. Lil Helpa (talk) 2009년 4월 1일 01:42 (UTC)답장[답장]
  142. 서포트. 연결할 필요가 있는 날짜는 거의 없고 모든 날짜에 기사가 필요한 것은 아닙니다. --Budke (토론) 2009년 4월 1일 (UTC) 02:36 답변[답변]
  143. 서포트. 이러한 유형의 링크는 분명히 기사 내용에 추가되지 않는 정보의 과도한 링크에 해당합니다. 제가 가지고 있는 유일한 문제는 관련 날짜에 대한 해석이 향후 편집 전쟁의 원인이 될 수 있다는 것입니다. 따라서 이것이 통과되면 링크가 기사에 추가되고 정말로 필요한 것이 확실하지 않은 한 지침은 피해야 합니다. 베가스위키안 (talk) 2009년 4월 1일 03:50 (UTC)답장[답장]
  144. 확실히 최고의 선택입니다. BQZip01 talk— 05:11, 2009년 4월 1일 (UTC)답장[답장]
  145. 데이트 링크가 언제 누군가에게 도움이 되었는지는 잘 모르겠습니다.demonhogtalk 편집 06:52, 2009년 4월 1일 (UTC)답장[답장]
  146. 서포트. 상식!! --Popiloll (talk) 2009년 4월 1일 (UTC) 07:12 답변[답변]
  147. 서포트. 루슬릭 (talk) 2009년 4월 1일 07:20 (UTC)답장[답장]
  148. 지원 - 가장 합리적이고 효율적인 지원 방법으로 보입니다. Colds7ream (talk) 2009년 4월 1일 07:27 (UTC)응답하라[응답하라]
  149. 지원—일-월 연결은 다른 잠재적 연결과 마찬가지로 취급해야 하지만, 내용물이 세균성이고 주제에 대한 관심이 높은 경우가 아니라면 연결하지 말라는 명시적 지침을 단순히 삭제하는 대신(옵션 4) 명시적 지침은 조수를 되돌리고 손상을 복구하는 촉매제 역할을 해야 합니다. 아직도 날짜를 연결하는 데 상당한 관성이 있습니다. 감속기가 어긋나지 않도록 돕기 위해 추가적인 힘이 필요합니다. 그러나 옵션 4는 몇 년 안에 고려할 가치가 있습니다. JIMp talk·cont 08:32, 2009년 4월 1일 (UTC)답장[답장]
  150. 서포트. 데이트는 의미 있는 연결고리가 될 수 있습니다. 링크가 유용한 경우 링크를 수행하는 것이 합리적입니다. 실크토크 YES!* 2009년 4월 1일 (UTC) 11:06 답변[답변]
  151. 취약한 지원—적절하게 사용할 경우 이러한 사용은 드문 일이 될 것입니다. 일반적으로 날짜 페이지의 정보는 특정 유형의 이벤트에 대해 과도하게 가중치를 부여하고 전 세계적으로 균등하게 가중치를 부여하지 않습니다(서양의 싸움, 영문학 등). 편집자가 날짜 페이지의 정보가 기사와 관련이 있는지 신중하게 고려하는 한, 저는 이 옵션을 제한적으로 사용하는 것을 지지합니다. 저는 개인적으로 날짜 링크가 의미 있는 것을 발견한 적이 없고 실수로 날짜 페이지를 클릭하면 짜증이 납니다.Mattisse (Talk) 2009년 4월 1일 (UTC) 12:43 답변[답변]
  152. 지원 무의미한 데이트 링크는 짜증납니다. 위에 댓글을 달면 됩니다. 치즈 비스킷 (talk) 2009년 4월 1일 12:47 (UTC)답장[답장]
  153. 지원 VJ (talk) 2009년 4월 1일 12:59 (UTC)응답하라
  154. 서포트. 날짜 링크는 다른 것과 같이 취급되어야 한다는 것을 어느 정도 이해하지만(사소하게 관련되지 않을 때는 링크, 그렇지 않을 때는 링크), 저는 이 모든 소동 끝에 이에 대한 구체적인 지침이 필요하다고 생각하기 때문에 #4에 반대합니다. 아무 말도 하지 않는 것은 더 이상의 끝없는 논쟁의 문을 열어줄 뿐입니다. 매트 13:05, 2009년 4월 1일 (UTC)
  155. 지지해주세요. 저는 고민자님의 생일에 무슨 일이 있었는지 알아내는 호기심의 가치를 제외하고는 월일을 연결할 어떤 이유도 생각하지 못하고 있습니다. 그리고 그것이 백과사전의 목적이 아닙니다. 이러한 링크가 제공하는 메타데이터는 너무 모호해서 가치가 없습니다. 기사의 주제와 관련된 어떤 특정하지 않은 사건이 일년 중 그날에 일어났다는 것을 아는 것은 누구에게도 도움이 되지 않습니다. 식민지 크리스 (talk) 2009년 4월 1일 13:17 (UTC)답장[답장]
  156. 강력한 지원 관련 없는 날짜의 링크는 오버링크로 이어지고 기사의 품질 링크를 희석시킵니다. 루비스코 (토크) 2009년 4월 1일 (UTC) 답변[답변]
  157. 지지 이런 식의 링크는 분명히 오버링크입니다. --Phil Holmes (talk) 2009년 4월 1일 (UTC) 15:15 (답변)
  158. 지지합니다만, 저는 주어진 것보다 훨씬 더 기본적이고 초보자에게 쉬운 좋은 날짜 연결 후보와 나쁜 날짜 연결 후보의 예를 추천합니다. marginalia 교수님 (talk) 2009년 4월 1일 (UTC) 16:38 답변[답변]
  159. - 저는 하루와 한 달 내내 연결하는 것을 반대합니다. 하루와 한 달의 기사는 단지 탭 페이지를 미화하는 것에 지나지 않습니다. Fighting' Phillie (talk) 2009년 4월 1일 18:32 (UTC)응답하라[응답하라]
  160. 지원 - 독자의 시간이 너무 귀중해서 그들이 읽기로 선택한 주제와 무관한 주제로 전환할 수 없습니다. Ed Johnston (talk) 2009년 4월 1일 19:45 (UTC)응답하라[답변]
  161. 지원, 이러한 종류의 내부 위키 링크는 날짜가 종종 문맥과 무관하기 때문에 기사에 전혀 가치를 부여하지 않습니다. 필요 없는 역사적 정보를 제공하는 경우가 많습니다. 사람들이 원한다면 그 특정 날짜를 검색할 수 있습니다. (Lil-unique1 (talk)) 2009년 4월 1일 (UTC) 22:37회답[회답]
  162. 서포트. 관련 날짜만 연결합니다. 파워 23:43, 2009년 4월 1일 (UTC)답장[답장]
  163. 지원 - 현재로서는 안내가 필요하지만, 몇 년 후에는 옵션 #4가 괜찮을 수도 있습니다. 해밀턴스톤 (talk) 2009년 4월 2일 (UTC) 00:50 답변[답변]
  164. 지원: WP:팝업 또는 기타 스크립트를 통해 모든 날짜의 날짜 페이지로 이동할 수 있기를 원하지만(메타 데이터를 자동으로 포맷하는 경우 더 쉬울 것) 일반적으로 관련 없는 과도한 가시 링크는 좋지 않습니다. Mark Hurd (talk) 2009년 4월 2일 (UTC) 02:43 답변[답변]
  165. 지원 무의미한 링크는 유용한 링크의 가치를 희석시킵니다. 기사의 링크는 주제(또는 관련 주제)에 대한 추가 정보를 제공하는 데만 사용해야 합니다. 오버링크는 독자의 주의를 산만하게 합니다("그 링크를 클릭하지 않아서 제가 무엇을 놓치고 있습니까?"). Johnuniq (대화) 2009년 4월 2일 (UTC) 02:55 (답장)
  166. 지원 거의 모든 경우에 날짜 링크는 무관하고 주의를 산만하게 합니다. 그렇지 않은 소수에 대해서는 예외를 둘 수 있습니다. Rivertorch (talk) 2009년 4월 2일 (UTC) 05:34 답변[답변]
  167. Rivertorch에 따라 지원합니다.--Aervanath (talk) 2009년 4월 2일 (UTC) 05:35 답변[답변]
  168. 지원 관련 시 링크해야 합니다. Taemyr (talk) 05:59, 2009년 4월 2일 (UTC)답장[답장]
  169. 나는 더 나은 대안이 없다고 생각하기 때문에 지원을 매우 꺼립니다. 예전에는 옵션 4에 더 가까웠겠지만, 지금은 너무 애매해 보입니다.--Yannismarou (talk) 2009년 4월 2일 (UTC) 08:09 (답변)
  170. 서포트. 저는 데이트 링크를 팔로우한 적이 없고 관련성이나 관심 있는 것을 발견한 적이 없기 때문에, 그것들은 시간 낭비이고 높은 가치의 링크를 희석시킵니다. 몇 가지 관련 날짜가 연결되면 도움이 될 수 있습니다.YobMod 2009년 4월 2일 (UTC) 09:02 답변[답변]
  171. 지원 이 옵션은 관련 링크의 양을 개선합니다. (같은 링크의 반복 사례를 중복 연결하는 것은 기존 정책에 의해 이미 권장되지 않음을 이해하고) - Mgm 2009년 4월 2일 (UTC)응답하라[답변]
  172. 지원 관련성은 모든 링크에서 항상 작동 요소여야 합니다. Ed Fitzgerald 2009년 4월 2일 (UTC) 13:06 답변[답변]
  173. 이 제안이 링크에 대한 우리의 일반적인 접근 방식 및 오버링크 방지와 일치하므로 를 지지합니다. --R'n'B (Russ라고 불러주세요) 2009년 4월 2일 (UTC) 13:31 답변[답변]
  174. 서포트 오버링크는 주의를 산만하게 합니다. --NullSpace (토크) 2009년 4월 2일 (UTC)응답하라[답변]
  175. 서포트. 관련된 날짜만 링크하고, 월-일 링크는 거의 관련이 없습니다. --Roise step (talk) 2009년 4월 2일 (UTC)응답하라[답변]
  176. 서포트. 기념일은 분명히 링크가 필요한 날이지만, 링크를 제한하는 것은 너무 제한적입니다. --Alvestrand (talk) 2009년 4월 2일 (UTC) 18:46 (답변)
  177. 서포트. 날짜 링크는 일반적으로 무관하고 링크 과부하에 추가된 것일 뿐이며, 일반적으로 피해야 한다고 생각합니다. 그러나 작성자가 특정 날짜가 진정으로 관련이 있다고 생각하는 경우 링크를 허용해야 합니다. Esobocinski (talk) 2009년 4월 2일 (UTC) 19:58 답변[답변]
  178. 서포트. 날짜를 연결하는 것은 "푸른 바다" 문제를 더 가중시킬 뿐입니다. 다른 모든 기사와 마찬가지로 엄격하게 필요한 경우에만 날짜 기사를 연결해야 합니다. Steve 2009년 4월 2일 (UTC) 22:06 답변[답변]
  179. 지원 – 일부 편집자는 이 규칙을 다른 편집자보다 더 느슨하게 해석할 수 있지만(예: 기사의 모든 월/일 연결을 지원하기 위해 다양한 "합리적"을 사용하는 것), 링크 밀도와 관련성을 줄이기 위해 포맷 변경이 필요합니다. momoricks (make my day) 2009년 4월 3일 (UTC) 01:12 (답변)
  180. 서포트 - 오버링크는 피하는 것이 좋습니다 - 만약 데이트 링크가 있다면, 관련성을 위해 거기에 있어야 합니다. 그러나 규칙을 시행하는 데는 시간이 많이 걸리므로, 보안 네트워크가 존재하는 한, 저는 옵션 1 Australian Matt (talk) 02:10, 2009년 4월 3일 (UTC) 답변[답변]에 찬성합니다.
  181. 지원 - 날짜 링크는 일반적으로 독자에게는 무관합니다. Cycle (talk) 2009년 4월 3일 02:31 (UTC)답장[답장]
  182. 지원 이것은 네 가지 중에서 저에게 말이 되는 유일한 옵션입니다.Yilloslime 2009년 4월 3일 (UTC) 04:35 답변[답변]
  183. 사용자:MC10/S - 4가지 중 가장 좋은 옵션으로 보이며 오버링크를 방지합니다. MathCool 1004:36 2009년 4월 3일 (UTC)답장[답장]
  184. 지원 저는 사용자들이 개선된 날짜 자동 포맷/자동 연동 소프트웨어를 통해 연결된 모든 날짜를 볼 수 있는 옵션을 가져야 한다고 생각합니다. 하지만 기본값은 옵션 1의 행에 있는 것이어야 한다고 생각합니다. --Sappic (talk) 2009년 4월 3일 (UTC)06:11 (답변)
  185. Duh당 지지대에 쌓입니다. 위키링크는 이유가 있을 때, 이유가 있을 때, 위키링크도 이유가 있을 것입니다.머리폭탄 ταλκκοντριβς{ – WP Physics} 2009년 4월 3일 06:55 (UTC)응답하라[응답하라]
  186. 미투--Club OranjeT 2009년 4월 3일 (UTC) 07:37 답변[답변]
  187. Wikington Crescent에 대한 파괴적인 영향에도 불구하고 지원. Orpheus (talk) 2009년 4월 3일 (UTC) 10:53 답변[답변]
  188. 서포트. 저는 "안내 제거" 옵션에 대해 생각했지만, 그것은 더 많은 논쟁으로 이어질 것 같습니다. 안내는 단지 필요한 것입니다. Mike Christie (talk) 2009년 4월 3일 (UTC) 11:02 답변[답변]
  189. 사람들이 왜 이런 링크를 사용할까요? 아마도 4월 14일의 정의를 찾기 위해서가 아니라 날짜와 연도에 대한 많은 연결이 필요하지 않습니다. 사물릴리 (talk) 2009년 4월 3일 12:40 (UTC)답장[답장]
  190. 관련된 경우에만 링크를 지원합니다. 모든 날짜, 심지어 그들이 등장하는 기사와 먼 관련이 있는 모든 날짜에 링크하는 것은 무의미합니다. 이러한 날짜를 연결하는 것은 명백하게 관련된 경우에만 사용해야 합니다. The Seeker 4 Talk 2009년 4월 3일 (UTC) 16:00 답변[답변]
  191. 서포트. 이 옵션은 전통적으로 날짜가 너무 많이 오버링크된 오버링크에 반대하는 아이디어를 강조하는 것입니다. --seav (talk) 2009년 4월 3일 (UTC)응답하라[답변]
  192. 관련성에 따라 지원하고 여기에 링크를 작성합니다. 이 링크는 종종 꽤 유용합니다. Bendono (talk) 2009년 4월 3일 18:15 (UTC)답장[답장]
  193. 지원 저는 왜 그 기사들에 대한 링크가 있는지 전혀 이해하지 못했습니다. Deegee375 (talk) 2009년 4월 3일 21:16 (UTC)답장[답장]
  194. 서포트. 관련성은 날짜든 다른 날짜든 링크의 이유여야 합니다.AVID B 06:04, 2009년 4월 4일 (UTC)답장[답장]
  195. 지원 불필요하고 도움이 되지 않는 링크를 줄입니다. 날짜-월 연결은 거의 항상 무의미할 것입니다. PamD (talk) 2009년 4월 4일 10:19 (UTC)답장[답장]
  196. .Support Best 옵션. 불필요한 위키링을 방지합니다.Moseschurte (talk) 2009년 4월 4일 (UTC) 11:46 답변[답변]
  197. 지원을 하는 것이 가장 좋은 방법이며, (즉시) 언제 위키링크를 해야 하는지에 대한 기존 지침을 따릅니다. ~~ [ジャム] 2009년 4월 4일 14:18 (UTC)답장[답장]
  198. 4가지 옵션 중에서 최선을 지지합니다. --Patar knight - contributions/ 2009년 4월 4일 (UTC) 18:32 응답[답변]
  199. 다른 것과 마찬가지로 지원: 관련이 있는 경우에만 링크를 연결합니다. Struway2 (talk) 2009년 4월 4일 20:01 (UTC)답장[답장]
  200. 지원 모든 날짜를 링크하는 것은 성가신 일이며 정보 오염에 기여하여 기사에 아무런 기여도 하지 않는 날짜 링크에서 주제의 내용을 파악하고 관련되고 흥미로운 링크를 선별할 수 있는 독자의 능력을 흐리게 합니다. 또한 특정 날짜와 관련된 정보를 찾을 수 있는 모든 사람의 능력에도 기여하지 않습니다. 그러한 날짜 링크가 너무 많아서 유용하지 않습니다. 주제와 가장 관련성이 높은 것을 제외하고는 모두 핵으로 처리하세요. -- bthelp 2009년 4월 5일 (UTC) 01:25 (답장)
  201. Support, second choice (#2가 나의 첫번째 선택이다.) – Quadell 01:31, 2009년 4월 5일 (UTC)응답하라[답변]
  202. Support Shoemaker's Holiday (talk) 2009년 4월 5일 06:08 (UTC)답장[답장]
  203. 지원자, 날짜 연결의 필요성을 본 적이 없습니다. 실제로 필요한 경우는 생각할 수 없습니다. Jezhotwells (talk) 2009년 4월 5일 12:18 (UTC)답장[답장]
  204. 서포트. Per Btphelps. — σ명확2009년 4월 5일 (UTC)응답하라[답변]
  205. 지원 불필요한 링크를 제거하고 Hohob (talk) 2009년 4월 6일 01:17 (UTC)답장[답장]
  206. 지원은 맨데이트 링크가 필요 없다고 봅니다. Ever.--2008chitchat Olympian 05:03, 2009년 4월 6일 (UTC)답장[답장]
  207. 지원 - 모든 링크와 동일한 원리입니다. KISS! -- William Allen Simpson (talk) 2009년 4월 6일 14:25 (UTC)응답하라[응답하라]
  208. 지원 연결은 진정한 연결이 있는 경우 유용하지만 그렇지 않은 경우에는 유용하지 않습니다. 좀 더 일반적인 연결은 웹 페이지에 접속한 날짜와 같이 사소한 날짜가 연결되는 터무니없고 압도적인 상황으로 이어집니다(저는 이것을 두 번 이상 봤습니다!). Richard New Forest (talk) 2009년 4월 6일 (UTC) 14:58 답변[답변]
  209. 지원은 여기에 있는 링크, 관련 변경 사항 등의 유용성을 희석시키면서 실질적으로 건설적인 것을 추가하지 않습니다. 가장 드문 경우를 제외하고는 천문학 상수에 의해 제한된 목록에 링크할 필요가 없습니다. Knepfllerle (talk) 2009년 4월 6일 (UTC) 16:42 답변[답변]
  210. 지원 이 옵션은 명확하고 일관된 권장 사항을 제공하고 일관된 적절한 연결을 가능하게 하며 오버링크를 최소화하는 데 도움이 됩니다.Danorton (talk) 2009년 4월 6일 (UTC) 18:16 답변[답변]
  211. 최소한의 복잡하고 가장 상식적인 옵션을 지원합니다. 베드로 2009년 4월 6일 (UTC) 18:40 답변[답변]
  212. 지지, 왜 모든 것이 그런 논쟁으로 변할까요? 이것은 말이 됩니다. 다른 사람들은 그렇지 않습니다. --Mrboire (talk) 2009년 4월 6일 (UTC)응답하라[답변]
  213. 지원 — 일관되고 일관된 상식적인 링크 정책은 링크 가능성이 있는 다른 단어, 구 또는 숫자를 다루는 것과 동일하게 날짜를 처리해야 합니다. 즉, 현재 기사와 정말 관련이 있는 경우에만 링크합니다. 우리는 독자가 링크 대상을 흥미롭게 여기거나 링크 가능한 단어를 기사 텍스트의 일부로 사용하기 때문에 단순히 단어를 링크하지 않습니다.샤이너페르C·00:44, 2009년 4월 7일 (UTC)답장[답장]
  214. 지원 - 불필요한 링크를 많이 제거하는 동시에 링크가 실제로 관련된 경우에도 옵션을 사용할 수 있습니다. Brian Powell (talk) 2009년 4월 7일 03:37 (UTC)답장[답장]
  215. 지원 모든 링크는 관련된 경우에만 포함되어야 합니다. 날짜가 왜 달라야 합니까? The Grand Rans (talk) 2009년 4월 7일 03:51 (UTC)응답하라[응답하라]
  216. 서포트. 관련 없는 링크를 제공하는 것이 기본 관행의 특징인 정책을 채택하는 것은 비양심적입니다. 대부분의 상황에서 날짜는 타임라인의 단순한 마커이며, 풍부하고 관련된 배경으로 가는 게이트웨이가 아닙니다. 따라서 대부분의 경우 링크는 잘못된 약속을 하고 텍스트의 힘과 정확성을 방해합니다.¡ɐɔıʇǝo노에티카!T– 2009년 4월 7일 07:36 (UTC)답장[답장]
  217. 하지만 이것과 옵션 #2의 차이점을 이해할 수 있을지 모르겠습니다. (그런 엣지 케이스인 것 같습니다.) --Cyde Weys 2009년 4월 7일 (UTC)응답하라[답변]
  218. 지원 - 독자가 가치 있을 때만 다른 글로 안내합니다. --4wajzkd02 (토크) 2009년 4월 7일 (UTC) 17:58 답변[답변]
  219. 지원 다른 링크와 마찬가지로 취급합니다. 과도한 연결을 개탄하며, 무분별한 정책 주도의 월/일 연결은 오랫동안 말도 안 되는 사례였습니다. Acroterion 18:57, 2009년 4월 7일 (UTC)답장[답장]
  220. 지원 날짜 링크는 IMHO와 거의 관련이 없지만 특정 경우 또는 의견이 일치할 때 링크를 허용하는 언어가 있는 것에 반대하지는 않습니다. 해산talk 2009년 4월 7일 (UTC) 19:55 답변[답변]
  221. 지원 -- 아크로테리온이 최고라고 했는데...다른 링크처럼 취급하세요. 관련된 경우 연결합니다. Farmercarlos (talk) 2009년 4월 7일 20:14 (UTC)답장[답장]
  222. 지원...100여명의 사람들이 내 앞에서 한 말은 무엇이든 간에. 그러나 실제로, 이것은 두 가지 대안(링크 모두 또는 링크 없음: 사용성을 방해함) 중 하나보다 낫습니다. ~user:orgjce 223 ☺ 어떻게 입력합니까? 2009년 4월 7일 20:15 (UTC)답장[답장]
  223. 서포트 - 네. Xenus (talk) 2009년 4월 8일 (UTC) 09:56 답변[답변]
  224. 지원은 드문 경우를 제외하고는 날짜를 연결할 필요가 없습니다. 이를 둘러싼 편집 전쟁을 막기 위해서는 안내가 필요하며, 이것이 최선의 선택인 것 같습니다. Nick-D (talk) 2009년 4월 8일 11:19 (UTC)답장[답장]
  225. 지원 이 섹션에는 "공명적인 판단 사용"이라고 쓰여 있습니까? 저는 그것의 팬입니다! 히포크라이트 (talk) 2009년 4월 8일 14:12 (UTC)답장[답장]
  226. 지원 베스트 옵션 --Armchair info guy (talk) 2009년 4월 8일 15:00 (UTC)응답하라[답변]
  227. 지원 날짜 링크는 거의 항상 무관합니다. 관련이 있을 때만 링크를 걸어주세요. --GedUK 2009년 4월 8일 (UTC)답장[답장]
  228. 지원 글쓴이가 결정하고 다른 사람들이 관련된 내용을 편집할 수 있습니다. 이 길을 따라가면 완전히 파란 페이지가 나올 거예요! 위키피터 프로젝트 (talk) 2009년 4월 8일 21:23 (UTC)답장[답장]
  229. 서포트. 관련 날짜만 링크하는 것이 적절해 보입니다. 를 들어, WP:OVERLINK. Rehevkor ✉ 2009년 4월 9일 (UTC) 01:35 답변[답변]
  230. 서포트. 링크가 기사에 가치를 더하는 경우 이를 포함합니다. 안되면 안 돼요. 아이세린talk 2009년 4월 9일 09:55 (UTC)답장[답장]
  231. 서포트. 저는 이 문제를 관련성과 관련된 문제로 보고 있으며, 옵션 1은 이 문제를 완벽하게 해결하는 것 같습니다. --A.K.R. (talk) 2009년 4월 9일 (UTC) 16:21 (답변)
  232. 지원 기사와 관련된 링크만 보고 싶습니다. Finavon (talk) 2009년 4월 9일 (UTC) 19:03 답변[답변]
  233. 지원 관련 없는 링크가 가독성을 감소시킵니다. 모든 관련 날짜를 빌리 메이스가 읽어주는 것 같아요. Cstaffa (talk) 2009년 4월 9일 (UTC) 23:58 답변[답변]
  234. 지원 이벤트는 단순히 특정 월 단위 조합에서 발생한 이벤트를 백과사전적으로 그룹화하는 것이 아니라 단순한 트리비아에 불과합니다. 커뮤니티 내부에서 이를 인식하고 있기 때문에 카테고리가 없는 이유는 다음과 같습니다.3월 24일. 지구가 태양과 상대적으로 같은 위치에 있기 때문에 두 주제를 임의로 연결하는 것은 전혀 연결할 가치가 없는 것이 아니라 완전히 사소한 것입니다. 이러한 월-일 조합은 날짜 자체가 특정 이벤트를 대표하는 경우에만 백과사전적입니다. 7월 4일과 9월 11일은 각각 독립기념일과 쌍둥이 빌딩 파괴의 일반적인 이름입니다. 대조적으로, 12월 7일은 아무리 악명이 높지만 진주만 폭격의 동의어로 일반적으로 사용되지는 않습니다. Ham Pastrami (talk) 2009년 4월 10일 06:15 (UTC)답장[답장]
  235. 오버링크를 방지하기 위한 지지대입니다. 플레처 (talk) 2009년 4월 10일 19:25 (UTC)답장[답장]
  236. 지지 이 바보 같은 연결고리를 끝내세요.ENG (talk) 2009년 4월 10일 (UTC) 19:28 답변[답변]
  237. 지원, 연결 날짜는 대부분의 경우 관련 정보를 제공하지 않습니다. Corn.u.co .pia Disc.us .sion 00:14, 2009년 4월 11일 (UTC)답장[답장]
  238. 지원, 날짜에 연결하면 일반적으로 기사에 아무것도 추가되지 않습니다. 유(knome)? yes...or no 2009년 4월 11일 01:23 (UTC)답장[답장]
  239. 서포트. 이 원칙에 따라 다른 날짜를 연결하는 것은 성가신 시각적 소음일 뿐입니다. 가이던스를 아예 없애는 것이 미래 갈등의 레시피입니다. 가장 좋은 방법은 이와 같은 간단한 가이드라인입니다. McKay (talk) 2009년 4월 11일 02:04 (UTC)답장[답장]
  240. 지원 다른 용어와 마찬가지로 편집자의 판단에 따라 적절한 경우에만 날짜를 연결해야 합니다. 마이클 Z. 2009-04-11 16:15z
  241. 지원 저는 "관련성"이 자유롭게 정의되는 한 이것이 최선의 선택이라고 생각합니다. 링크가 너무 많은 것이 너무 적은 것보다 낫다고 생각합니다. 캡틴팬더 2009년 4월 11일 17:09 (UTC)답장[답장]
  242. 옵션 #3을 선호하지만, 이것은 적절한 절충안인 것 같습니다. Titoxd(?!? - cool stuff) 2009년 4월 11일 (UTC) 18:25 답변[답변]
  243. 서포트. 제 마음은 모든 지침을 없애라고 말하지만 편집장은 파란색 링크의 바다를 만드는 것을 좋아하는 많은 초보자가 있다고 말합니다. 그래서 아니라고 말하죠. Jim.henderson (talk) 2009년 4월 11일 20:49 (UTC)답장[답장]
  244. 지원, 링크하지 않는 쪽의 오류(다른 자동 포맷 옵션이 있는 경우). --Fabricramp talk to me 2009년 4월 11일 (UTC)응답하라[답변]
  245. 지원 - 옵션 1은 읽고 있는 주제에 대한 독자에게 도움이 될 경우에만 링크가 제공되어야 하므로 가장 합리적입니다. 모든 지침을 제거하는 것은 도움이 되지 않으며 미래의 갈등을 유발할 수 있습니다. Camaron Chris (talk) 2009년 4월 12일 14:01 (UTC)답장[답장]
  246. 지원 이것은 가장 합리적인 것으로 보입니다. 관련이 있는 링크와 관련이 있는 모든 링크만 해당됩니다. 날짜 및 기타 링크에 대한 정책을 가질 가치가 있습니다.Jchthys 2009년 4월 12일 14:36 (UTC)답장[답장]
  247. 지원 이것만이 합리적인 선택입니다. -- M2Ys4U 2009년 4월 12일 (UTC) 15:57 답변[답변]
  248. 지원 우리는 이에 대해 엄격해야 합니다. 이러한 링크는 "관련성"에 대한 엄격한 해석과 함께 해당 주제 관련성 규칙과 중요한 연결을 공유해야 합니다. 재고(talk) 2009년 4월 12일 (UTC) 18:27 답변[답변]
  249. 지원; 이러한 링크는 일반적으로 불필요합니다. 옵션 4도 괜찮을 것 같습니다. --Spangineerws (háblame) 2009년 4월 12일 (UTC)응답하라[답변]
  250. 지원 - 저는 이러한 링크들이 결코 적절치 않을 것이라고 예상합니다.Mattisse (Talk) 2009년 4월 12일 (UTC) 22:35 답변[답변]
  251. 지원 이것은 나에게 네 가지 중 최고의 선택이라고 생각합니다. 모든 날짜 연결을 제거하는 것은 너무 가혹하고, 어떤 지침도 제공하지 않으며, 첫 번째 날짜 참조를 연결하도록 허용하는 것은 몇 년 동안 유용하지만 전체 날짜는 아닙니다. --Perry Middlemiss (talk) 2009년 4월 13일 (UTC)응답하라[답변]
  252. 저는 이것이 가장 합리적인 선택이라고 생각합니다: 그것은 과도한 경직성을 피하면서도 동시에 확립된 연결 관행에 기초한 간단한 지침을 제공합니다. 월담 공작 2009년 4월 13일 01:07 (UTC)답장[답장]
  253. 서포트 절대 금지와 오버링크 사이의 가장 적절한 균형. Dl2000 (talk) 2009년 4월 13일 01:34 (UTC)답장[답장]
  254. 지원 링크는 항상 관련성이 있어야 하며 날짜도 예외가 아닙니다. 또한 자동 포맷 문제를 해결한 결과 커뮤니티에서 자동 포맷을 원하지 않거나 자동 포맷을 원하는 경우 연결된 날짜에 의존하지 않는 경우에만 자동 포맷을 목적으로 했던 링크를 제거해야 합니다. 그러나 이와 관련된 두 가지 중요한 점이 있습니다. 첫째, 자동 포맷 문제가 결정될 때까지 링크를 제거해서는 안 됩니다. 둘째, 이러한 링크를 제거하는 가장 효율적인 방법은 자동화 및 반자동화 방법을 통한 것입니다. 하지만 봇과 스크립트가 관련성을 판단하는 것은 불가능하기 때문입니다. 우선 편집자가 관련성이 있다고 판단하는 링크를 식별하고 보호할 수 있는 방법이 개발되어야 하는데, 이것이 현재 중재와 관련된 주요 이슈입니다. Mlaffs (talk) 2009년 4월 13일 12:20 (UTC)답장[답장]
  255. 모두 연결된 수십 개의 날짜가 있는 지원 기사는 그저 어수선해 보입니다. 이는 일부 편집자가 독자에게 도움이 되는 것에 대해 생각하지 않고 공식을 따르고 있음을 나타냅니다. 철자자 크리스 (talk) 2009년 4월 13일 14:14 (UTC)답장[답장]
  256. 서포트. 이 제안된 표준은 편집자의 재량에 의존하지만 MOS 항목에서는 특이하지 않습니다. 이 경우, 가능한 모든 사례를 다루는 간단한 알고리즘이 없다는 것을 의미하지만(관련성은 상황에 따라 다르다), 최종 결과는 백과사전 사용자들에게 널리 받아들여질 가능성이 높습니다. Feds 2009년 4월 13일 16:30 (UTC) 답변[답변]
옵션 #2를 지원합니다(기념 링크만 해당).
  1. 월간 기사가 고아가 되지 않도록 하는 합리적인 해결책인 것 같습니다. 제가 선호하는 옵션은 2,4,1,3 순입니다. - Arthur Rubin (talk) 2009년 3월 29일 (UTC) 23:44 답변[답변]
  2. 옵션 2의 "전용" 부분을 제외하고 옵션 1과 2를 지원합니다. 참고: 명확성을 위해 두 목록에 모두 표시. davidwr/(talk)/(기여)/(이메일) 2009년 3월 30일 18:33 (UTC)답장[답장]
  3. 비록 이것이 옵션 1과 매우 비슷하지만 - 기념일은 아마도 관련된 날짜로 간주될 것입니다 - 그래서 저는 둘 중 하나에 만족할 것입니다. 아마도 날짜 기사는 목록으로 취급되어야 하며 적절한 경우 "또한 참조"에서 연결되어야 할 것입니다. Mike Peel (talk) 2009년 3월 30일 (UTC) 18:58 답변[답변]
  4. 지원 옵션 2는 옵션 1보다 명확합니다. 왜냐하면 옵션 1의 목적상 "관련성"이 있는 것이 분명하지 않지만 옵션 2는 명확하게 정의되어 있기 때문입니다. 저는 우리가 날짜 기사를 고아내고 싶지 않다는 것에 동의하며, 이것이 그것을 피하는 방법인 것 같습니다. 옵션 4는 말도 안 돼요. Richard75 (talk) 2009년 3월 31일 17:19 (UTC)응답하라[답변]
  5. 지원 - 옵션 #1이 너무 넓습니다. --David Göthberg (talk) 2009년 4월 1일 (UTC) 16:39 답변[답변]
  6. 서포트. 옵션 2는 1보다 더 엄격합니다. 만약 option 2가 승리하지 못한다면, 제 투표를 집계하여 option 1을 지지합니다. -Woodstone (talk) 2009년 4월 2일 (UTC) 11:30 답변[답변]
  7. 서포트, 오버링크를 최대한 피하고 싶습니다. Tempshill (talk) 2009년 4월 2일 (UTC) 18:57 답변[답변]
  8. 지원은 옵션 1을 약간 상회할 뿐이지만 둘 다 타당합니다. Shimgray talk 2009년 4월 3일 (UTC) 13:57 답변[답변]
  9. 지원, 옵션 1은 무의미한 링크를 너무 많이 남깁니다. -- Kelly Cook (talk) 2009년 4월 3일 (UTC) 15:51 (답변)
  10. 지원Malik Shabazz (talk · 기고) 2009년 4월 3일 (UTC)응답하라[답변]
  11. 지원, 첫 번째 선택.Quadell 2009년 4월 5일 (UTC) 01:31 답변[답변]
  12. 지원 가능한 모든 날짜 연결을 간단히 제거하는 옵션이 없기 때문에 최소한의 파란색을 제공합니다. 날짜 링크는 기능이 없고 가독성이 크게 떨어집니다. 날짜는 최악입니다. 흉측해 보이고 독자에게 실질적인 기능을 제공하지 않습니다. Arsenikk 2009년 4월 6일 (UTC) 19:14 답변[답변]
  13. 지원 - 저는 일반적으로 월-일 연결은 피해야 한다고 생각하지만, 특정 날짜와 본질적으로 연결된 휴일이나 기타 행사를 언급하는 기사에서는 허용될 것이라고 생각합니다. 로보피쉬 (talk) 2009년 4월 7일 (UTC) 23:56 답변[답변]
  14. 지원 옵션 1은 무의미한 링크를 너무 많이 남깁니다. 케네디 2009년 4월 8일 (UTC) 15:10 답변[답변]
  15. 지원: 옵션 1보다 더 엄격하기 때문에 이를 선호하지만, 그렇지 않은 경우 옵션 1에 대한 보조 지원으로 간주합니다. 옵션 3은 뼈만 앙상합니다. 많은 것들의 첫 번째 발생("알비니즘", "약체 연합" 등)을 연결하지만, 매우 특별하고 독특한 맥락을 제외하고는 다른 것들("여성", "밤" 등)을 연결하지 않는 이유를 잘못 이해합니다. 연결 날짜에 대한 논쟁이 다시 일어나면서 MOS에 이 문제에 대한 지침을 추가해야 할 필요성도 자동적으로 다시 발생하기 때문에 옵션 4는 단순히 무의미합니다.에스엠씨캔들리 [talk] [cont] ‹(-¿-) › 02:57, 2009년 4월 9일 (UTC)응답하라[답변]
  16. 서포트. 옵션 1과 3은 오버링크입니다. 옵션 4는 불일치와 편집 전쟁의 길입니다. 이것은 좋은 타협입니다.IbLeo (talk) 2009년 4월 10일 (UTC) 05:22 답변[답변]
  17. 지원 두 번째 선택은 #1 아가토클레아(talk) 2009년 4월 12일 14:45 (UTC)응답하라[답변]
  18. 지원 - (순서대로) #1, #4, #3 순으로 이어집니다. 그러나 날짜를 자동으로 제거하거나 기본적으로 제거해서는 안 됩니다. 데이트 링크가 대부분 자연스럽게 죽는 것을 보고 싶지만 죽는 것을 보고 싶습니다. 날짜가 기사에 중요하다면, 그것은 한 가지입니다. 하지만 모든 날짜를 연결하는 것은 독자들의 시간 낭비입니다. --Willscrlt (→""""Talk?!") 2009년 4월 13일 13:21 (UTC)답장[답장]
옵션 #3을 지원합니다(첫 번째 발생 시 모두 링크).
  1. 다른 모든 것은 이렇게 연결되어 있습니다. 날짜가 왜 다르게 취급되어야 하는지 모르겠습니다.-Jeff(talk) 00:10, 2009년 3월 30일 (UTC)답장[답장]
    별로 신경 쓰이지는 않지만 날짜와 달이 연결될 때가 더 좋다고 생각합니다. 서명되지 않은 기여가 삼진, Sandstein 2009년 3월 31일 20:38 (UTC)답글[답글]
  2. 지지합니다. 하지만 특정 날짜(출생과 사망 등)에 한해서는 명백한 괴짜가 될 것이며 오버링크는 나쁘다고 생각하지만 날짜를 처음 연결하는 것은 문제가 없다고 말할 것입니다. 한 번은 인포박스이고 한 번은 기사 자체에 있어도 두 번은 연결할 수 있습니다. 우리는 WP가 종이 백과사전이 아니라 페이지를 다른 페이지와 "연결"할 수 있도록 하는 4차원 온라인 백과사전이라는 것을 기억해야 합니다. 저는 많은 사람들이 그것이 그들에게 가치를 거의 주지 않는다고 주장했지만, 제가 기사를 읽고 있고 날짜를 보고 싶다면 왜 제가 기사를 입력해야 그것을 보러 갈 수 있습니까? 또한 날짜에 대한 링크를 제거하려면 날짜 기사 자체를 삭제하는 것도 고려해야 합니다. 모든 링크를 제거하는 고아 날짜 기사도 꽤 확보할 것입니다. --Kumioko (talk) 2009년 3월 30일 (UTC)20:18 (답변)
  3. 지원, 개인적으로 링크를 좋아합니다. 그것이 WP > 종이 백과사전의 이유입니다. 데이터가 반드시 당면한 기사와 관련된 무언가를 가리킬까요? 그렇지 않을 수도 있지만, 독자들이 그것이 흥미롭다는 것을 발견하지 못할 것이라는 것을 의미하지는 않습니다. '랜덤 페이지'를 꺼낼 수도 있습니다. 저는 4개에 투표했을 것입니다. 그러나 더 이상 연결하지 않고 단순히 연결을 제거하는 데 사용되지 않을까 걱정됩니다. 우노미 (talk) 2009년 3월 31일 (UTC) 16:44 답변[답변]
  4. 저는 여기서 약자를 응원하고 있다고 생각하지만, 날짜를 연결하는 것은 다른 곳에서는 얻을 수 없는 위키피디아에 내재된 깊이를 더한다고 느낍니다. 저는 오버링크를 싫어하고, 기사에 나오는 모든 날짜가 연결되어야 한다고 생각하지 않습니다. 어쩌면 옵션 2 1/2일 수도 있습니다. 쿠미오코가 말한 것처럼, 출생/사망 날짜, 즉 상대적으로 중요한 발견일 뿐, 헨델의 모든 날짜가 작동하는 것은 아닙니다. -- ζ알파 ππερν알파 ππερ 08:26, 2009년 4월 1일 (UTC)답장
  5. 강력한 지원. 저는 이것이 위키피디아를 멋지게 만드는 일부라고 생각합니다. 기사 어딘가에 날짜가 들어 있으면, 무슨 일이 있었는지 동시에 알 수 있습니다(예를 들어 어떤 것을 조사하고 있다면 상당히 중요합니다...) 또한 개인적으로 기사에서 연결된 월일 페이지를 읽는 것을 좋아합니다. 그들은 제 프로가 다른 곳에서는 찾지 못했을 지식에 대한 링크를 제공하고 기사 간의 흥미로운 연결을 만듭니다. 그냥 멋있는 거예요. 또한 자신과 관련된 것은 다른 사람과 관련이 없을 수도 있습니다. 무엇이 관련이 있는지 또는 무엇이 관련이 없는지 어떻게 결정하시겠습니까? 저에게 이러한 링크는 다른 기능보다 다른 흥미로운 기사를 더 잘 찾고 발견할 수 있는 기회를 제공하기 때문에 관련이 있습니다. 노사망 (talk) 2009년 4월 2일 21:42 (UTC)답장[답장]
  6. 강력한 지원. 위에 덧붙여, 세렌디피티가 연구에 유용한 역할을 하기도 합니다.[21]데이트리비아(talk) 2009년 4월 5일 22:59 (UTC)답장[답장]
  7. 지지 - 저는 그것에 반대하는 설득력 있는 주장을 볼 수 없습니다. Deb (talk) 2009년 4월 6일 (UTC) 18:02 답변[답변]
  8. 저는 이 옵션을 지지합니다. 제 이유는 이 옵션을 지지하는 다른 모든 사람들이 설명한 것과 같습니다. 링크를!Simplebut powerful 00:12, 2009년 4월 9일 (UTC)답장[답장]
I support Option #4 (안내 제거)
  1. 든든한 지원군. 모든 링크는 독자에게 관련성이 있고 도움이 되어야 합니다. 이것들에 대해 우리가 무엇을 더 말할 필요가 있습니까? 칠십계PMandson 2009년 3월 29일 23:32 (UTC)답장[답장]
    • 이것이 날짜 링크가 다른 링크와 같이 취급되도록 하는 유일한 방법입니다. 저는 이 투표에서 이 목표를 제거하기 위한 성공적인 캠페인에도 불구하고, 이 평등이 모든 형태의 언어에 대한 지지를 받고 있다고 봅니다.
    • #3도 의견과 같이 다른 링크에 적용되지 않는 날짜 링크에 대한 제한을 적용하기 위해 읽혔습니다. #1과 #2는 극도의 제거와 스위핑 제거를 정당화하는 데 사용되었습니다.
    • 그러므로 저는 #1, (적어도 이 연결들의 주요한 사용을 인정하는) 반대 #2를 강하게 반대하고 #3을 약하게 반대합니다. 2009년 3월 30일 00:38(UTC) 답변서
  2. 네, 부탁드립니다. 애초에 이 클러스터를 바보로 만든 사람들의 손에서 가능한 한 많이 빼주세요. 미스터 지맨 2009년 3월 30일 (UTC) 01:10 답변[답변]
  3. 우선순위로 강력하게 지지합니다. MOS의 날짜 지침은 실제로 다른 사람이 하지 않았을 일을 하는 데 도움이 되는 것 같지는 않으며, 끊임없는 편집 전쟁은 스타일 매뉴얼의 전체 개념이 얼마나 공감대가 부족한지 보여줍니다. AKAF (talk) 2009년 3월 30일 07:04 (UTC)답장[답장]
  4. 옵션 #3은 터무니없는 것입니다. 현재 형식의 날짜 자동 포맷(즉, 동적 날짜) 외에는 인용문 끝에 "2009년 3월 30일 검색됨"이라는 문장에 링크를 추가할 이유가 전혀 없습니다. 옵션 #1은 너무 많은 단어를 사용하고, 일부 편집자들이 너무 좋아하는 "주제가 아닌 기사 내용의 관련성"을 강조합니다. (저는 그들이 샌타페 트레일(영화) 로널드 레이건에 대한 링크를 삭제할 것인지 궁금합니다.) 대부분의 이전 기사는 그가 수십 년 전에 연기했던 영화와 관련이 있을 수 없는 정치인으로서의 경력에 관한 것이기 때문입니다. 또한 월요 기사들이 목록에 올라 있다는 것을 인정하는 것처럼 보이는데, 이는 앞으로도 영원히 그렇게 해야 한다는 포고령으로 받아들여질 수 있습니다. (이렇게 되면 4월 23일 기사를 성 조지의 날과 연결하는 것이 아직도 그렇게 쓸모가 없을까요?) 옵션 #2는 제가 개인적으로 그러한 기사들을 연결할 때 사용할 기준과 어느 정도 일치합니다(제가 "기념"이 아니라 "사건"이라고 말하는 것을 제외하고는). 어떻게 하지에서 6월 21일을 연결하는 것이 성 패트릭의 날에서 3월 17일을 연결하는 것보다 더 나쁜가요?이상적으로 9월 11일은 그 문구가 어떻게 2001년 9월 11일의 공격과 동의어가 되었는지에 대한 부분을 포함할 수 있습니다. 그것은 후자에 대한 이미 매우 긴 기사의 범위 밖에 있지만, 그것에 의해 연결될 수 있습니다. 하지만 저는 우리가 동물 종들의 일반적인 이름들을 언제 연결할지에 대한 명백한 지시가 필요하다고 생각하지 않습니다. 위키피디아 가이드라인은 WP 없이도 이미 충분히 비대해졌습니다.성 패트릭의 날이 어떤 해에서는 3월 17일에 기념되지 않는다고 언급하는 것을 링크합니다. 따라서, WP의 세 번째 탄착점에 "... and days of a year"를 추가하는 것을 반대하지는 않겠지만, 저는 옵션 #4를 지지합니다.링크#일반적으로 링크해서는 안 되는 것. (FWIW, 제가 선호하는 것은 4-2-1-3 순으로 감소하는 것입니다.) --A. di M. (talk) 2009년 3월 30일 (UTC) 09:14 (답장)
  5. 서포트. 너무 많은 이벤트는 단순히 관련이 없으며 메타데이터를 사용하는 것이 좋습니다. 요일/월만 해도 무의미합니다. -- 2009년 3월 30일 (UTC) 10:32 (답장)
  6. 지원, MOS는 콘텐츠 가이드가 아닌 스타일 가이드이므로 링크 시기를 지시해서는 안 됩니다. MOS는 그들이 언제 연결할지 지시하려고 할 때 과도하게 도달했습니다.Lock Coletc 11:02, 2009년 3월 30일 (UTC)답장[답장]
  7. 지지합니다. 위키백과가 일률적인 기대를 가져야 하거나 2) 그러한 기대를 시행해야 할 근본적인 이유가 없다고 봅니다. Jclemens (talk) 2009년 3월 30일 (UTC) 16:29 답변[답변]
  8. 는 위에서 분명히 말한 것 이상의 것을 (강요하게는 아니더라도) 말할 수 있었으면 좋겠습니다. 기사에는 며칠, 몇 달, 몇 년과 상관없는 쓸모없는 링크들이 많이 있지만, 어떤 이유에서인지 위키피디아 사람들은 이런 도움이 되지 않는 링크들을 찾아서 없애는 대신 날짜와 관련된 링크들을 모두 없애는 데 집중하기로 결정했습니다. -- llywrch (talk) 2009년 3월 30일 (UTC) 17:03 (답변)
  9. 강력한 지원: 날짜를 클릭하여 다른 이벤트가 발생했는지 확인할 수 있는 것이 매우 유용하고 흥미롭다는 것을 알게 되었습니다. 네, 특정 날짜와 관련된 기사들이 많았는데(역사가 오래된 세계에서 일어나는 일), 그 주장은 무관하다고 생각합니다. 기사에 링크가 너무 많은 것에 대한 이 모든 걱정은 백과사전이 성장함에 따라 서로 링크된 기사가 점점 더 많아질 것이기 때문에 무의미한 걱정입니다. 500만 또는 1000만 건의 기사에 도달하면 기사에 넣을 수 있는 링크 수를 제한하여 주어진 기사에 "너무 많은 링크"를 갖지 않도록 할 것입니까? 그건 그냥 황당해요. 우리는 주요 주제에 대한 많은 기사가 수백, 수천, 그리고 아마도 수만 개의 링크를 가질 것이라는 것을 받아들여야 할 것입니다. 데이트의 경우, 그것들은 아마도 고급에 있을 것이지만, 온라인 백과사전이 성장하면 그렇게 됩니다. 그리고 누군가가 누군가가 제거한 링크를 다시 돌려놓아야 할 것이라는 주장은 터무니 없습니다. 동일한 봇을 다시 실행하고 역방향으로만 실행합니다. 그것들을 모두 제거하는 것보다 더 어렵지는 않을 것입니다. 저는 또한 #1과 #2에 강력하게 반대하고 #3은 너무 자의적입니다. ··· 日本穣 19:20, 2009년 3월 30일 (UTC)답장[답장]
  10. 니혼조에 따른 지원 --사이버코브라 (토크) 2009년 3월 30일 (UTC) 19:50 답변[답변]
  11. 서포트. 저는 이러한 논의를 한동안 알고 있었고 오늘 워치리스트 공지를 보고 이 주제에 대해 의견을 내기로 결정했습니다. 저는 이 제안들이 소름끼치다고 생각합니다. 이는 기사에서 이탤릭체 텍스트를 사용할 때나 글에서 총알 포인트를 사용해야 할 때보다 훨씬 더 많습니다. 이것은 웹의 기본적인 인프라인 링크와 위키피디아의 기사들 간의 연결에 관한 것입니다. 특정 날짜 기사에 링크가 필요한지 아닌지는 중요하지 않습니다. 그런 포괄적인 가이드라인은 무리가 있고 사안별로 처리하는 것이 좋을 것 같습니다. --Bill 20:41, 2009년 3월 30일 (UTC)답변서[답변서]
  12. 지원 편집자가 관련 없는 것과 그렇지 않은 것을 통제할 수 있도록 합니다. 봇들은 현재 상태로 충분히 합니다. Ched ~ ©/ 2009년 3월 30일 (UTC)21:27 (답변)
  13. 지원 날짜는 기사와 관련이 있는 경우 링크할 수 있는 다른 날짜와 마찬가지로 취급해야 합니다. TJ Spyke 2009년 3월 30일 (UTC) 21:36 답변[답변]
  14. 지원 링크를 사용하는 시기에 대해 정확히 하나의 규칙이 필요합니다. 날짜는 특별하지 않습니다. 링크를 클릭하면 제가 읽고 있는 내용의 맥락에서 유용한 정보를 기대합니다. 날짜 범주는 유사한 이벤트를 시간에 맞춰 연결하는 목적을 가지고 있으며, 기사 유형에 따라 특정할 수 있습니다. --NrDg 00:09, 2009년 3월 31일 (UTC)답장[답장]
  15. 서포트. 어쨌든 많은 날짜들은 연결이 필요합니다. 게다가 인포박스는 날짜가 강조되어 있을 때 훨씬 더 멋져 보입니다. 그래서 저는 4번을 지지합니다. Daniel Benfield (talk) 2009년 3월 31일 01:23 (UTC)답장[답장]
  16. 지지해줘요 그냥 상관없으니까 사람들이 원하는 대로 하게 해줘요. hulmem (talk) 2009년 3월 31일 03:18 (UTC)답장[답장]
  17. 옵션 1은 더 우아하고 공동체의 판단에 의존하는 이것의 축소된 버전일 뿐입니다. 어떻게든 다른 링크처럼 날짜를 처리하고 볼 MoS를 한 개라도 줄일 수 있을 것 같습니다. otherlleftNo, really, other way . . . 2009년 3월 31일 (UTC) 03:56 (답장)
  18. 수세기 동안 특정 날짜(월-수)에 일어난 사건들을 나열하는 기사를 쓰기가 어렵습니다. 피에르 코르네유가 6월 6일(율리우스력으로는 1606년, 그레고리안력으로는 1944년, D-day와 우연히 같은 달과 숫자의 조합으로 태어난 것이 어떤 차이가 있습니까? 그리고 서양 달력을 사용하지 않는 문명들은 어떻습니까? 그래서 저는 결코 데이트를 연결하는 것을 선택하지 않을 것이고, 저는 확실히 그렇게 강요받고 싶지 않습니다. 가치를 위해 일반적으로 편집하는 모든 기사에서 날짜 링크를 삭제합니다. 그래서 저는 옵션 4 또는 옵션 1을 지원합니다. 진심으로 George Louis (talk) 2009년 3월 31일 (UTC) 05:46 답변[답변]
  19. 일반적으로 날짜가 연결되든 아니든 상관없지만, 특정 기사의 개별 편집자가 이를 가장 잘 결정할 수 있습니다. 이 옵션은 "Births in YEAR" 등도 가능합니다. dm (talk) 2009년 3월 31일 (UTC) 06:01 (답장)
  20. 든든한 지원군. 고양이가 실제로 따라올 수 있는 가능성은 지옥에 있는 옵션 중 하나입니다. Physchim62 (talk) 2009년 3월 31일 (UTC) 18:59 답변[답변]
  21. 강력한 지원으로 규칙의 수를 줄이고 창의성을 높임 J04n (talk page) 2009년 4월 1일 01:19 (UTC)응답하라[답변]
  22. ✔ 네. 위키링크인데 왜 다른 위키링크로 취급하면 안 되나요?Twas Now (talk contributes e-mail ) 2009년 4월 1일 09:25 (UTC)답장[답장]
  23. J04n님의 의견에 진심으로 동의합니다. 많은 기여자들이 편집한 위키피디아에서, 적절함에 대한 다양한 아이디어를 가지고, 하나의 프로크루스테안 솔루션을 부과하는 것은 어리석은 일입니다. (연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연차연
  24. 지원 편집자가 기사나 프로젝트 수준에서 적절한 구현을 결정할 수 있습니다. 내용 토론은 MOS의 소관이 아닙니다. --guyzero talk 2009년 4월 1일 (UTC)응답하라[답변]
  25. 든든한 지원군. MOS에 있을 필요가 없는 모든 것이 MOS에 있어서는 안됩니다. 편집자들이 각 상황에서 가장 좋은 것이 무엇인지 알 수 있도록 신뢰하세요.iridsent 20:50, 2009년 4월 2일 (UTC)답장[답장]
  26. 규칙 위반을 최소화하는 이 제안을 지원합니다.—S Marshall Cont/ 2009년 4월 2일 (UTC) 22:27 답변[답변]
  27. 위에 있는 사람당 지지자 0.육각형(!❞) 2009년 4월 4일 15:28 (UTC)답장[답장]
  28. 서포트. 꼭 지시 크리프가 필요한가요? bibiomaniac 15 2009년 4월 4일 (UTC)응답하라[답변]
  29. 서포트. 이미 충분한 지침이 있습니다. --catslash (talk) 2009년 4월 4일 (UTC) 23:54 답변[답변]
  30. 서포트. 그러나 예전에는 모든 날짜를 연결하는 스타일이었고 많은 기사가 여전히 이렇게 하지만 이제는 일반적인 규칙을 따를 경우에만 날짜를 연결해야 한다는 의견을 남깁니다. JonH (talk) 2009년 4월 5일 (UTC) 09:08 답변[답변]
  31. 서포트. 날짜를 다른 링크처럼 취급하는 것은 제안된 솔루션과 크게 다르지 않은 것 같습니다. 그런데도 특정 가이드라인의 비용은 0이 아닙니다. --Thomas B ♘ talk 17:00, 2009년 4월 5일 (UTC)답변[답변]
  32. 강력한 지원 링크를 추가할 위치와 링크 대상은 현재 편집자의 재량에 따라 결정됩니다. 이를 변경하려면 강력한 이유가 필요합니다. Phil_burnstein (talk) 2009년 4월 6일 09:45 (UTC)답장[답장]
  33. 서포트. 제 입장을 재고하는 중입니다. Eluchil404 (talk) 2009년 4월 6일 22:29 (UTC)답장[답장]
  34. 서포트. 불필요한 정책은 모두 사라져야 합니다. --Pgallert (talk) 2009년 4월 7일 (UTC) 09:49 (답변)
  35. 서포트. 편집자는 스스로 결정할 수 있습니다. 규칙이 너무 많아서 지켜지지 않을 것 같습니다. 지맨 2009년 4월 7일 (UTC) 22:48 답변[답변]
  36. 서포트. 이것 아니면 옵션 3이지만 대부분 편집자가 결정해야 한다고 생각합니다. 저는 오버링크에 대해 고민하지 않습니다. 그리고 위키백과가 일관된 스타일을 따르도록 하려는 시도는 헛된 것이고 어리석은 것이라고 생각합니다. 규칙을 지배하는 편집자-호브고블린들이 신입들을 트롬핑하기에는 이미 너무 많은 핑계가 있습니다. Fijagdh (talk) 2009년 4월 8일 21:27 (UTC)답장[답장]
  37. 지지(또는 오히려, 다른 모든 것에 반대) - 세월은 한 가지이지만, 며칠은 보통 무의미합니다. 편집자의 재량에 맡기십시오. --Alinnisawest,Dalek Empress (여기서 퇴출 요청) 2009년 4월 10일 (UTC) 03:10 (답변)
  38. 지원 저는 이러한 링크의 필요성을 전혀 이해하지 못했습니다. --Auntof6 (talk) 2009년 4월 11일 (UTC)07:17 (답장)
  39. 지원 날짜 페이지는 이러한 기사에 아무런 영향을 미치지 않으며, 어수선한 내용을 끝내고 모든 기사를 제거합니다. 검색창에 입력하면 찾을 수 있습니다. - .Logan't : 2009년 4월 11일 11:23 (UTC)응답하라[답변]
  40. MOSNUM 또는 MOSLINK에 "날짜에 대한 링크는 다른 기사에 대한 링크와 전혀 다른 방식으로 취급되지 않습니다." 또는 일부와 같은 내용을 명시적으로 설명하는 작은 비지도 문을 추가해야 한다는 주의 사항을 지원할 수 있습니다. 꼭 필요하진 않지만 도움이 될 수도 있습니다. --Jayron32.talk.contributes 14:57, 2009년 4월 12일 (UTC)답장
  41. 서포트. 날짜는 특별하지 않습니다. 제이런32가 주의해야 할 사항을 제안한 것도 즉각적으로 합리적입니다. 이 사건의 역사를 고려할 때, "특별하지 않다"고 명시적으로 말하는 문장이 좋은 생각일 수도 있습니다. -- 2009년 4월 13일 (UTC) 12:08 (답변)
  42. 강력한 지원: 편집자들이 (다른 많은 것들과 마찬가지로) 무엇이 유용하거나 도움이 되는지, 무엇이 도움이 되지 않는지 결정하도록 하세요. 현재 특정 주제에 실제로 관심이 있는 편집자들은 때때로 동의하지 않지만 특정 문제를 기반으로 다른 부차적인 문제를 결정하는 방식으로 논쟁할 수 있습니다. —— Shakescene (talk) 2009년 4월 13일 20:24 (UTC)답장[답장]
기타의견
  • 셉텐트리알리스는 원래 여기서 처음 세 가지 옵션에 반대하는 이유를 제시했습니다. 라이언은 댓글란에 들어가야 하기 때문에 그것들을 제거했습니다. 저는 그들의 말을 반박하고 싶지 않기 때문에 셉텐트리오날리스의 원래 반대를 여기에 연결했지만 셉텐트리오날리스는 더 이상 논평하지 않습니다. 람보의 복수 (저는 어떻게 지내요?)
    • 정말로 감사합니다. 그러나 이것은 제 주장을 억제하는 데 성공했습니다. 저는 이것이 라이언의 의도가 아니라고 확신합니다. 하지만 일방적으로 이 형식을 강요한 사람들은 의심할 여지가 없는 동기를 가지고 있습니다. 2009년 3월 30일 00:24 (UTC) 답변[답변]
  • (9월의 의견을 확인하지 않은 상태에서). 옵션 4는 수용 가능해 보이지만 옵션 1에서 옵션 3까지의 스펙트럼에 어디에 적합한지 확인하려면 추가 해석이 필요합니다. 또한 옵션 1은 제목이 잘못 지정되어 있으므로 "(현재) 관련 날짜 기사에만 링크"라고 읽어야 합니다. 옵션 1에서 옵션 3까지의 스펙트럼에 "관련 날짜에만 링크"가 표시되는 경우도 논의의 대상이 될 것입니다. WP를 인용하고 싶은 사람들:OVERLINK, 이것은 또한 그 지침을 명시적으로 수정할 것입니다.Arthur Rubin (talk) 2009년 3월 29일 (UTC) 23:54 답변[답변]
  • 유권자들에게 한 가지 선택지를 정확히 선택하도록 요구하는 것은 깨졌습니다. 합리적인 사람은 일반적으로 허용 가능한 두 가지 옵션, 그리고 최소한 한 가지 옵션은 허용 불가능한 것을 발견할 수 있습니다. 이 형식은 기본적으로 유권자가 선호하는 옵션 중 하나를 무작위로 선택하고 동일한 속성을 가진 모든 사람이 중간을 분할하는 것이 아니라 정확히 동일한 방식으로 선택하기를 희망하도록 요구합니다. 각 선택에 대해 허용/허용 불가 투표를 하는 것이 훨씬 더 나을 것입니다. Gavia immer (talk) 2009년 3월 30일 03:13 (UTC)답장[답장]
  • 어드밴스드/디어드밴스드는 메타데이트에 대해 논의했지만 모든 옵션은 연결만 다루었고 메타데이트는 다루지 않았습니다. 그래서 그것이 감독인지, 추정인지 추론인지 불분명합니다. billinghurst (talk) 2009년 3월 30일 (UTC)10:36 (답변)
  • 옵션 4는 직관적입니다. 대부분의 사람들이 월/일 연결에 반대하는 이유는 다른 오버링크에 반대하는 이유와 동일하기 때문입니다. 하지만 월/일 연계는 (문제라면) 너무도 보편적인 "문제"이기 때문에, 저는 우리의 입장을 좀 더 분명히 하기 위해 정기적인 오버링크 지침을 벗어나서 스스로 언급할 가치가 있다고 생각합니다. 적어도 기사에 날짜 링크를 추가하거나 제거하는 근거를 제시해야 할 때는 도움이 될 것입니다. r ʨɢ / 2009년 3월 30일 13:13 (UTC)답장[답장]
  • 옵션 2는 관련이 있지만 비기념적인 모든 연결을 배제하기 때문에 옵션 1보다 더 제한적인 것 같습니다. 하지만 아서 루빈(당시 옵션 2의 유일한 지지자)이 일반적으로 날짜를 연결하는 것을 선호한다는 점을 염두에 두었기 때문에 제가 제대로 해석하고 있는지 의문이 듭니다. 저는 관련 없는 연결고리에 반대하며, 일년 중 항상 같은 날에 일어나는 주요 기념행사들은 일반적으로 관련이 있는 연결고리라고 믿습니다. 즉, 일반적으로 7월 4일로 알려진 미국 공휴일을 7월 4일로 연결하지만 시스템 관리자 감사의 날은 아닙니다(7월 마지막 금요일이 아니라 항상 7월 31일이라고 해도).
  • 1940년대는 왜 언급되었습니까? 한 달도 아니고 하루도 아닙니다. 1위를 지지할 수도 있었지만, 1940년대로 연결될 만한 많은 기사들을 충분히 상상할 수 있습니다. - Peregrine Fisher (토론) (기여) 2009년 3월 30일 (UTC) 18:17 (답변)
    • 왜냐하면 #1은 날짜 링크를 다른 링크들처럼 취급하게 될 것이라는 이유로 그것을 지지하는 편집자들의 수에도 불구하고, 소수의 극단주의자들이 모든 날짜 링크를 제거하는 것을 정당화하기 위해 사용하고 있기 때문입니다. 칠십계PMandson 2009년 3월 30일 18:26 (UTC)답장[답장]
      • 순수한 FUD입니다. 명백한 이유는 1940년대가 (이 여론조사에서는 다루지 않기 때문에) 연결된다는 이유로 예외가 필요한 기사로 언급되지 않았기 때문입니다. 기사들은 옵션 1에 따라 1940년, 1941년, ..., 1949년 (그리고 아마도 1937년과 1956년에도)으로 연결해도 무방할 것이라는 기사의 예로 언급되고 있습니다. --Hans Adler (talk) 2009년 3월 31일 (UTC)10:30 (답변)
  • 이 여론조사의 형식에 항의합니다. 자세한 내용은 이 섹션을 참조하십시오. {{discute tag}}가 적당할 것 같습니다. 칠십계PMandson 2009년 3월 30일 18:26 (UTC)답장[답장]
  • 제가 처음으로 사지에 나가서 이런 질문을 하는 것은 싫지만, 왜 모든 연결에 대해 조언하는 옵션이 없는 것일까요? 위의 논평으로 판단할 때, 그러한 옵션은 상당한 지지를 받을 것입니다. Giants2008 (17-14) 00:22, 2009년 3월 31일 (UTC)답장[답장]
    • 이것은 여러 편집자들에 의해 언급되었지만, 지금 돌아가서 언급하기에는 너무 늦었습니다. 어쨌든, 저는 날짜가 블루문에 한 번씩 연결되어야 한다고 보면 우리 모두 알 수 있다고 생각합니다. Dabomb87 (talk) 2009년 3월 31일 00:35 (UTC)답장[답장]
    • 1940년대 또는 1939년부터 1940년까지의 링크를 허용하지 않으려면 많은 지원을 받지 못할 것입니다. 만약 당신이 그들을 허락한다면, 그것은 정말로 옵션 1의 특별한 경우일 뿐입니다. 분명히 1번 옵션의 미세 조정은 여론 조사 후에 이루어져야 합니다. 그렇지 않았다면 우리는 다른 옵션들도 미세 조정해야 했을 것입니다. --Hans Adler (talk) 2009년 3월 31일 (UTC)10:35 (답변)
  • 추가 의견: 연결 봇이 작성될 수 있다고 생각하는 사람들을 위해. 가능하지만 날짜가 없는 한 달 옆에 가끔 숫자가 있기 때문에 문제가 됩니다.Arthur Rubin (talk) 2009년 3월 31일 14:20 (UTC)응답하라[답변]
  • 또한 4번에 투표하는 사람들은 대부분 1번이라고 생각하는 것으로 보이며(링크는 매우 드물게), 1번에 투표하는 많은 사람들은 자막 때문인지 4번이라고 생각하는 것으로 나타났습니다.Arthur Rubin (talk) 2009년 3월 31일 14:20 (UTC)응답하라[답변]
  • 옵션 번호 1과 관련하여 1개의 의견이 있습니다. "관련성"이 있는 날짜를 식별할 때 더 설명해야 합니다. 다른 사람들은 그렇지 않을 수도 있지만, 저는 출생일과 사망일이 관련이 있다고 생각합니다. --Kumioko (talk) 2009년 3월 31일 (UTC) 19:52 (답변)
  • 옵션 #1, #2, #4의 실제적인 차이를 이해하는 데 어려움을 겪고 있습니다. 한 달이 하나의 옵션으로 연결되지만 다른 옵션으로는 연결되지 않는 경우는 무엇입니까?Quadell(talk) 2009년 3월 31일 (UTC) 19:54 답변[답변]
    • 저는 선택지 간의 차이가 무엇인지에 대해 잘 알지 못하는 한, 양심적으로 투표할 수 없습니다. 한 계획에서는 연결되지만 다른 계획에서는 연결되지 않는 월의 예를 보여줄 수 있는 사람이 있습니까?Quadell(talk) 2009년 4월 1일 (UTC) 14:06 답변[답변]
      • 성 패트릭의 날은 성 패트릭의 날(아일랜드어: Lále Pádraig 또는 Lá Féile Pádraig)을 시작합니다. 구어체로 성 패디의 날 또는 간단히 패디의 날은 아일랜드의 수호 성인 한 명인 성 패트릭(Saint Patrick, 서기 385년경–461년)을 기념하는 연례 축제일이며 일반적으로 3월 17일에 기념됩니다.
        옵션 #1을 사용하면, "3월 17일"이라는 단어는 3월 17일 기사와 연결되지 않을 것입니다. 왜냐하면 그 기사는 성 패트릭의 날에 대한 이해를 돕거나 확장시키는 어떤 것도 포함하고 있지 않기 때문입니다.
        옵션 #2를 사용하면, "3월 17일"이라는 단어는 일반적으로 성 패트릭의 날 기념일이기 때문에 3월 17일 기사와 연결됩니다.
        3번 옵션을 사용하면 3월 17일이라는 단어가 기사에 처음 등장하기 때문에 3월 17일이라는 단어와 연결됩니다. 그러나 다른 일은 연결되지 않습니다.
        옵션 #4를 사용하면 "3월 17일"이라는 단어가 3월 17일 기사와 연결될 도 있고 연결되지 않을 도 있습니다. 왜냐하면 우리는 어떤 지침도 제공하지 않을 것이고 여러분의 추측은 저의 추측과 같습니다.
      • 도움이 되길 바랍니다. --RxxS (talk) 2009년 4월 3일 (UTC) 22:00 답변[답변]
        • 명확히 하기 위해: 반복되는 사건들이 #1에서 연결되는 것이 아니라 #2에서 연결되는 것이 #1과 #2 사이의 유일한 차이점입니까?
        • 또한, 옵션 #1에 대한 분석에는 문제가 있습니다. 3월 17일 기사에는 "1756 - 성 패트릭의 날은 (크라운 앤 시슬 선술집에서) 처음으로 뉴욕에서 기념됩니다."라고 쓰여 있습니다.아리마테아의 요셉과 같은 날이라는 것을 알게 될 것이고, 그 성도들이 어떻게 상호관계를 맺는지 궁금할 것입니다. 일반적으로, 사람들은 특정한 휴일의 기념식이 그 날 일어난 역사적인 사건들에 어떤 영향을 미쳤거나 혹은 영향을 받았는지 궁금해하지 않을까요? 그 문구에는 "그들의 내용이 세균성이고 주제에 관한 것이 아니라면", 저는 그 사건 동안 일어난 일이 세균성이 아니고 주제에 관한 것이 아니었던 재발하는 사건을 생각할 수 없습니다. (첫 번째 전국 형제 주간은 말콤 X가 암살된 날이었고, 이는 기사 자체에서 언급된 우연이었습니다. 어떤 다른 사건들이 있었는지 궁금해하는 것이 주제가 아니고 주제가 아닌 것일까요?)Quadell(talk) 22:42, 2009년 4월 3일 (UTC)답장[답장]
          • (1) 옵션 #1에는 기념일이 다른 링크와 같이 처리됩니다. 즉, 해당 기사가 이해에 도움이 되거나 확장되는 경우 날짜-기사에 링크합니다. (2) 뉴욕에서 열리는 첫 번째 성 패트릭의 날 기념 행사는 이미 성 패트릭의 날 기사에 실리고 있으므로, 옵션 #1에서는 해당 정보를 이미 가지고 있었기 때문에 링크되지 않을 것입니다. (3) 개인적으로, 저는 아리마테아의 요셉과 성 패트릭의 관계가 제가 성 패트릭의 날(성자가 아닌 기념일에 관한 것)에 대한 지식을 확장하는 데 어떻게 도움이 되는지 알 수 없습니다. 1년 중 365일밖에 안 되는데, 공교롭게도 성자의 날이 있을 수밖에 없습니다. (4) 생년월일과 생년월일을 연결하는 많은 지지자들과 같은 오류를 범하고 계십니다. 이 날짜들이 해당 인물과 매우 관련이 있지만, 위키백과 기사는 거의 항상 그렇지 않습니다. 출생연도의 연도별 기사에 해당 주제의 초기 생애와 관련된 내용이 실제로 포함되어 있는 경우에는, 어쨌든 그 정보는 전기의 "초기 생애" 부분에 있어야 합니다. (5) 위키피디아는 사소한 것들이나 우연들의 모임이 아닙니다. 그리고 저는 가능한 연결에 대해 궁금해하는 자연스러운 성향에 공감하지만, 저는 위키피디아가 신뢰할 수 있는 정보의 원천으로 남아 있기를 바랍니다. YMMV. --RexxS (talk) 2009년 4월 4일 (UTC) 23:54 답변[답변]
            • 설명 감사합니다. 문구가 잘 안 맞는 것 같아요. 저는 옵션 1번에 투표하는 대부분의 유권자들이 이 투표가 자신들의 월간 기사에 대한 사건의 연관성을 금지할 것이라는 사실을 알고 있는지 궁금합니다. (결국, 만약 조 블로우가 디트로이트에서 태어났다면, 디트로이트 기사에 블로우 씨에 대한 언급이 없더라도, 우리는 보통 디트로이트와 연결됩니다. 제가 보기에는 상당히 직접적인 평행선인 것 같습니다.) – Quadell(talk) 2009년 4월 5일 (UTC) 01:31 답변[답변]
              • 솔직히 말해서, 저는 디트로이트와의 연결고리를 만들지 않을 거에요. 하지만 누군가가 그것이 조 블로우에게 유용하다고 생각했다면, 왜 안될까요? 실제 사례가 없으면 어렵지만, 예를 들어, 저는 디트로이트로 연결되는 링크를 만들겠습니다. 예를 들어, 알 카포네에 언급되어 있습니다. 비록 디트로이트에서 태어나지는 않았지만 말입니다. 반면에, 대부분의 사람들이 미국이 어디에 있는지 알고 있기 때문에, 저는 미국을 전기로 연결하는 일은 거의 없을 것입니다. --RexxS (토크) 2009년 4월 5일 (UTC) 19:24 (답변)
  • 저는 이 여론조사를 전혀 이해할 수 없습니다. 누가 제가 모든 데이트 링크에 반대표를 던질 수 있는 방법을 알려주실 수 있나요? Loosmark(토크)
    • 옵션 1은 관련된 경우에만 링크에 투표할 수 있습니다. 그들이 결코 관련이 없다고 생각되면 옵션 1에 투표할 수 있지만 투표에 설명 댓글을 추가할 수 있습니다. 식민지 크리스 (talk) 2009년 4월 1일 10:03 (UTC)답장[답장]
      • 하지만 저는 관련이 있을 때만 링크하는 것을 지지하지 않습니다. 저는 날짜를 링크하는 것을 전혀 지지하지 않습니다. 왜 다른 사람들처럼 명확한 방법으로 투표함으로써 내 의견을 표현할 수 없는 것일까요? Loosmark (talk) 2009년 4월 1일 12:55 (UTC)답장[답장]
  • 저는 옵션 #1이 특히 바보 같다고 생각합니다. 관련된 것은 누가 결정하나요? -- BRG (talk) 2009년 4월 1일 (UTC) 14:51 답변[답변]
    • 아주 좋은 지적입니다. 그래서 우리는 모든 날짜 연결에 반대하는 투표 옵션이 필요합니다. Loosmark (talk) 2009년 4월 1일 (UTC) 22:34 답변[답변]
모든 내용과 마찬가지로 합의가 관련된 것을 결정하지 않습니까? 링크 없음에 투표한다는 것은 페이지에 대한 과도한 합의를 의미하며, 이는 날짜를 링크하는 것이 매우 유용합니다(언제인지는 생각할 수 없지만, 그럴 수도 있습니다!). 지침은 유연한 합의가 있어야 합니다.YobMod 2009년 4월 2일 (UTC)응답하라[답변]
너무 옳습니다. 그게 바로 협업의 전부입니다!위키피터 프로젝트 (talk) 2009년 4월 8일 21:25 (UTC)답장[답장]
  • 저는 옵션 1에 찬성할 수도 있다고 생각합니다. 그러나 이 옵션에 대해 제공되는 기록은 단순히 그 반대가 아니라 날짜를 연결해야 하는 경우의 예제를 포함하는 경우 훨씬 더 유용할 것입니다. Jgm (talk) 2009년 4월 7일 20:52 (UTC)답장[답장]
날짜에 위키링크를 표시하지 않는 방법

위키백과에서:빌리지_펌프(기술)#mw 형식의 날짜에 대한 CSS 링크 색상 설정. 몇 번의 테스트 후에, 다음과 같은 CSS가 하나 추가된 것이 발견되었습니다(특별:표준 스타일 시트를 사용하는 경우 Mypage/monobook.css)는 날짜를 기준으로 위키링크를 표시하지 않습니다.

기간.mw- formatted- 날짜 a {색.: 블랙입니다.;} 

도움이 되기를 바랍니다. -- 사용자:문서

고마워요, 문서... 제 위키링크가 마음에 든다는 것만 빼면요. 문제는 스마트한 연결, 즉 선택적 접근 방식이 독자와 우리 자신을 위해 연결의 유용성을 최적화하는 방법이라는 것입니다. (저는 밝은 파란색을 어두운 파란색으로 바꾸기는 하지만, 아마도 제 맥 모니터가 색상 표시에 꽤 강하기 때문일 것입니다. 내 사용자 페이지에는 사용 방법에 대한 지침이 있습니다.) Tony (talk) 2009년 4월 6일 (UTC) 14:56 답변[답변]
개인적으로, 저는 그런 인상을 받지 않았습니다. 자동 포맷된 날짜의 링크 색상만 변경하시면 더 좋을 것 같습니다. 기사는 다른 자주 연결되는 기사와 유사하게 링크되는 대부분의 기사의 맥락에서 항상 실망을 줄 것입니다. 미국. 구성 방법과 내용을 알지 못하는 경우를 제외하고는 이에 해당합니다. -- 사용자:문서

연도연동

배경문

연도 연결(Year linking)은 특정 연도가 기사(1987)에 연결되거나 특정 주제에 대한 연도 기사([1987 in sports 1987])에 대한 파이프 링크(pipe link)입니다.

연도 연결의 장점
  1. 연도 기사에 쉽게 액세스할 수 있습니다.
  2. "여기서 링크되는 내용" 페이지를 관련성이 있는 데이터로 채웁니다.
  3. 독자가 연도별로 글로벌 역사적 맥락을 자유롭게 탐색할 수 있습니다.
연도 연결의 단점
  1. 기사의 주제를 더 잘 이해하는 데 관련되거나 유용한 경우는 거의 없습니다.
  2. "What links here"는 종종 많은 잘못된 긍정을 생성하고 유용성이나 관련성이 의심스러운 출처를 생성합니다. 대신 검색 상자를 쉽게 사용할 수 있습니다.
  3. 무분별하게 추가될 경우 기사가 오버링크 되어 고부가가치 링크가 희석될 수 있습니다.
연도 마크업의 장점(링크를 수반하는지 여부)
  1. 기사 텍스트의 자동 처리(즉, 메타데이터 수집)를 단순화합니다.
연도 마크업의 단점
  1. 편집 과정을 복잡하게 하고 명령 크리프에 기여합니다.
  2. 검색 상자를 포함한 "metadata"를 수집하는 강력한 도구와 수년간 구글 검색에 "site:wikipedia.en"을 추가할 수 있는 강력한 도구가 이미 있습니다.
연도 링크에 대한 지침 제거의 장점
  1. 연도 링크는 다른 링크와 크게 다르지 않습니다. 연도 기사는 이 목적을 위해 다른 기사와 마찬가지로 취급되어야 합니다. 모든 링크에 적용되지 않는 연도 링크에 대한 특정 지침은 지침 크리프입니다.
연도 링크에 대한 지침 제거의 단점
  1. 연도의 연결 기사는 '정상적인' 기사와 같지 않기 때문에 특별한 지침이 필요합니다. 거의 모든 연도의 기사는 사건의 목록이며, 오직 같은 해에 발생한 우연에 의해서만 관련됩니다. 이러한 목록은 자신에게 연결되는 기사를 이해하는 데 도움이 되는 컨텍스트를 제공하지 않으며, 따라서 연결되어서는 안 됩니다. 연도 기사가 실제로 역사적 맥락을 제공할 정도로 개선된 경우 이 지침을 검토해야 할 수 있습니다.


합의를 통해 지원될 경우, 다음 네 가지 제안 지침 중 하나(옵션 1, 2, 3 또는 4)가 위키백과에 추가됩니다.스타일 매뉴얼(날짜 및 숫자)#날짜위키피디아 링크자동 포맷:linking#시간순항목. 네 가지 옵션 아래에 답변 부탁드립니다.

연도: 옵션 #1(관련 연도만 링크)

연도 기사(1795, 1955, 2007)는 주제에 대해 세균적이고 주제적인 정보를 포함하지 않는 한 연결되지 않아야 합니다. 즉, 연도 기사의 사건은 단순히 같은 해에 발생했다는 것 외에 중요한 연결을 공유해야 합니다. 예를 들어, 제2차 세계 대전의 연표(1942)는 제2차 세계 대전에 관한 다른 기사와 연결될 수 있으며, 그 해에 미터법에 대한 특정한 발전에 대해 쓸 때 과학에서도 1787년과 연결될 수 있습니다. 그러나 건축가 필립 C의 출생과 사망의 세월. 1906년2005년의 내용 중 존슨이나 건축과 관련된 내용은 거의 없기 때문에 존슨연결해서는 안 됩니다.

연식 : 옵션 #2 (옵션 #1 + 출생/사망 연식 등)

연도 기사(1795, 1955, 2007)는 해당 연도가 주제와 특별히 관련이 있는 경우를 제외하고는 연결되어서는 안 됩니다. 즉, 기사의 주제와 관련된 중요한 사건이 해당 연도에 발생했습니다. 한 사람의 출생과 사망, 조직의 설립과 해체 등이 그 예가 될 수 있습니다.

연도: 옵션 #3(최초 발생 시 모두 링크)

연도 기사는 두 기사가 서로 얼마나 관련성이 있는지에 관계없이 기사의 첫 번째 발생에 대해 연결될 수 있습니다.

연도: 옵션 #4(안내 제거)

연도 링크를 다루는 모든 특정 언어는 스타일 매뉴얼 및 관련 페이지에서 제거됩니다. 이것은 다른 잠재적인 링크와 마찬가지로 연도 링크를 다루는 효과를 가질 것입니다. (이것은 자동 포맷의 맥락에서 링크에 대한 언급을 포함할 필요가 없습니다. 이것들이 현재의 지침인지 아니면 역사적인 메모인지는 위의 자동 포맷에 대한 질문에 달려 있습니다.)

연도 연계 응답

선택에 대한 간결한 설명과 함께 ONE 옵션으로 지지 투표를 표시해 주시기 바랍니다. 당신의 설명은 공동체의 합의를 결정하는 데 중요합니다.
옵션 #1(관련 연도만 링크)을 지원합니다.
  1. 네 가지 중에서 가장 좋은 옵션입니다. 연도 링크가 기사와 관련이 있는 경우 링크합니다. 안되면 안 돼요. 스티브 크로신 24/ 2009년 3월 29일 (UTC) 23:16 답변[답변]
  2. 연관성이 거의 없고 주제에 대한 이해를 심화시키는 데 거의 도움이 되지 않기 때문에 링크가 전혀 없는 것이 좋습니다. 상식이 우세하도록 합시다. 링크는 몇 개만 부탁드립니다. 오공자(talk) 2009년 3월 29일 (UTC) 23:25 답변[답변]
  3. 다시 한 번 해당 주제와 매우 관련이 있는 경우에만 해당 연도에 링크합니다. 음악/영화 등에서 YYYY에 대한 링크는 괜찮지만, 그 중 일부라도 너무 많은 링크가 연결되어 있습니다. 람보의 복수 (How do I hell?) 2009년 3월 29일 (UTC) 23:25 (응답)
  4. WP에 따르면:OVERLINK. --John (talk) 2009년 3월 29일 (UTC) 23:37 답변[답변]
  5. 그렇고 말고요. 날짜가 그 자체로 주목할 만한 것(예: 1492년)이더라도, 날짜가 발생하는 경로와는 무관할 수 있습니다. --Philcha (talk) 2009년 3월 29일 (UTC)23:51 [답변]
  6. 지원: 우리는 현재로서 충분히 오버링크하고 있습니다. seecer talk 기고문 2009년 3월 29일 (UTC) 답변[답변]
  7. 지지하다. 이 조항이 상당히 좁게 해석되기를 바랍니다. -- 도널드 앨버리 2009년 3월 29일 (UTC)응답하라
  8. 지원, 이러한 링크의 가치는 너무 과장되어 있습니다. 연도별 기사는 여전히 (대부분) 트리비아의 목록입니다. 제가 이 기사들이 반드시 나쁘다고 말하는 것은 아니며, 단지 현재 형식의 다른 기사 독자들에게 도움이 되지 않을 것이라는 점에 유의하시기 바랍니다. Dabomb87 (talk) 2009년 3월 30일 00:01 (UTC)답장[답장]
  9. 지원, 기사와 관련된 경우에만 해당 연도를 연결합니다. 다시 말씀드리지만, 상식적이고 오버링크를 방지하는 가장 좋은 방법이라고 생각합니다. 레이븐Talk to meMy edits 197700:09, 2009년 3월 30일 (UTC)답장[답장]
  10. 지지하다. 더 적게 싸울 가능성이 있다는 것을 제외하고는, 옵션 4와 정확히 같은 효과입니다. --Hans Adler (talk) 2009년 3월 30일 (UTC) 00:11 (토론) 아무도 이것을 옵션 4로 읽지 않도록 하기 위해 제가 두 번째로 선택한 것입니다. 그것은 아니다. 문제를 해결하지 못하기 때문에 사실 최악의 선택입니다. --Hans Adler (talk) 2009년 3월 31일 (UTC)10:22 (답변)
  11. 지원 - 다른 모든 것과 마찬가지로 날짜 링크는 주제에 대한 독자의 이해를 향상시켜야 합니다. 이는 사례별로 결정할 수 있습니다. Awadewit (talk) 2009년 3월 30일 00:13 (UTC)답장[답장]
  12. 서포트. 마지막으로 "연도 기사에 대한 쉬운 접근"을 요구한 것은 언제입니까? 난 그런 적이 없다. 연도 기사는 숨이 막힐 정도로 쓸모가 없습니다. 그리고 내가 그 중 하나에 액세스하기를 원하는 날(즉각적으로 기다리는 날), 검색 상자는 내 요구에 맞게 충분히 쉽게 액세스할 수 있게 해줍니다. 또한 유명한 "메타데이터"는 "유용한 메타데이터"와 다릅니다. Bishonen talk 00:23, 2009년 3월 30일 (UTC)회답[회답]
  13. 지원 이것은 몇 년을 연결해야 하는 드문 상황을 거의 포함합니다. 제안된 문구는 모든 것을 말합니다: "주제에 대해 세균적이고 주제적인 정보를 포함하지 않는 한 몇 년이 연결되어서는 안 됩니다." 충분히 말했습니다. Greg L (talk) 2009년 3월 30일 (UTC) 00:36 답변[답변]
  14. Greg L에 따라 지지합니다.MCollins (talk) 00:45, 2009년 3월 30일 (UTC)답장[답장]
  15. 지원 (이유를 연결하는 내 날짜까지) 저는 제거 지침 옵션을 지지하는 경향이 있지만 모든 날짜를 연결하려는 과거 경향으로 인해 계속 오버링크가 발생할 수 있다고 생각합니다. 역사적으로 중요한 것들에 대한 날짜 링크를 제한하기 위한 지침이 필요합니다. -- Tcncv (talk) 00:48, 2009년 3월 30일 (UTC)답변[답변]
  16. 스티브, 비쇼넨 그리고 그렉. 핵전쟁 00:49, 2009년 3월 30일 (UTC) 답변[답변]
  17. 지원 추가 지침은 오버링크 연도를 방지하는 데 도움이 될 것입니다. Eubulides (talk) 2009년 3월 30일 01:38 (UTC)답장[답장]
  18. 이것이 날짜가 전혀 없는 링크라는 제가 선호하는 위치에 가장 가깝기 때문에 지원합니다. Ealdgyth - Talk 01:49, 2009년 3월 30일 (UTC)응답하라[답변]
  19. 지원: 옵션 중에서 "푸른 바다"를 가장 잘 줄일 수 있는 옵션이 될 것 같습니다. Japalang (talk) 2009년 3월 30일 01:59 (UTC)답장[답장]
  20. 스티브 크로신의 말입니다.줄리안콜튼Talk 2009년 3월 30일 (UTC) 02:16 답변[답변]
  21. 지원: 사용 가능한 모든 옵션 중에서 저는 이 옵션을 지지합니다. 제가 읽고 있는 주제와 무관한 장소로 저를 데려가는 파란 데이트 링크의 필드를 보는 것에 지쳤습니다.SteveB67 (talk) 2009년 3월 30일 02:19 (UTC)답장[답장]
  22. Support.-gadfium 2009년 3월 30일 (UTC) 03:24 답변[답변]
  23. 지지: 연도 기사는 거의 전적으로 우연한 일들입니다. 저는 당신이 원하는 주제에 대해 더 깊이 이해할 수 있는 1년짜리 기사를 찾을 수 없습니다(위의 Bishonen 참조). 푸른 바다는 기사에서 심각하게 비전문적으로 보이고, 좋은 연결고리를 희석시키고, 텍스트를 어수선하게 만듭니다. 하단의 "See so" 섹션은 편집자가 1~2년을 링크하고 싶은 억제되지 않은 충동을 느낀다면 더 나은 곳이지만, 저는 사람들이 재량적인 브라우징에 빠져들 수 있도록 하는 것뿐만 아니라 여전히 그 정당성을 보고 싶습니다(어쨌든 저는 독자들이 그런 링크를 친다고 생각합니다). Tony (talk) 2009년 3월 30일 (UTC) 03:59 답변[답변]
  24. 지원 나는 연도 링크가 불필요하고 여분의 파란색을 싫어합니다. Bridies (talk) 2009년 3월 30일 (UTC) 04:43 답변[답변]
  25. 서포트. 저는 출생일과 사망일의 경우 연도와 관련된 기사(대부분 트리비아를 포함)가 다소 더 관련이 있다는 #2의 가정에 강력하게 반대합니다. 만약 있다면, 그들은 관련성이 적습니다. 예를 들어, 어떤 해에 발생하는 임의의 사건들은 그 해에 태어난 사람의 삶과 거의 관련이 없습니다. --Srleffler (talk) 2009년 3월 30일 (UTC)05:00 (답변)
  26. 지원Chris! 2009년 3월 30일 (UTC) 05:03 회신[답변]
  27. 서포트. 링크는 그들이 이끌어내는 기사가 관련이 있을 때 이루어져야 합니다. 연도 페이지에 유용한 컨텍스트가 추가될 수 있는 드문 경우에는 "또한 참조" 섹션이 이 섹션에 완벽한 장소입니다. 또한 대부분의 연도 기사를 "[연도]의 이벤트 목록"과 같은 것으로 이름을 바꾸는 것을 지지합니다. (talk) 2009년 3월 30일 05:13 (UTC)답장[답장]
  28. 날짜 링크와 마찬가지로 지지합니다. (참고로, 완벽한 세상이라면 저는 피먼더슨의 편에 서서 완전한 제거에 투표할 것입니다만, 분명히 어떤 사람들은 더 분명하게 말할 필요가 있습니다.) Fut.Perf. 2009년 3월 30일 06:04 (UTC)답장[답장]
  29. 사실, 저는 옵션 4를 가장 지지합니다(월/일 섹션과 마찬가지로, 이것이 어디로 가는지 안다면 나머지는 생략). 지침이 없다는 것은 전쟁을 편집하는 것을 의미하지 않으며, 실제 결과는 이 지침과 동일할 것입니다. 여론조사 형식은 표면적으로 여러 가지 옵션을 지원하는 것을 허용하지 않기 때문입니다. (왜요? 진지하게요, 왜요?) 저는 이미 언급한 바에 근거하여 이를 지지합니다. 실제로는 옵션 4와 동일하며, 실제로는 다른 사람들의 지지를 받을 가능성이 더 높습니다. 그러나 귀하의 여론조사 형식은 어떤 경우에도 깨집니다. Gavia immer (talk) 2009년 3월 30일 06:17 (UTC)답장[답장]
  30. 지원 1년을 연결하려면 훌륭한 이유가 있어야 합니다. 이것들은 드물 것입니다. Dougweller (talk) 2009년 3월 30일 08:14 (UTC)답장[답장]
  31. 서포트. 이 옵션은 각 날짜 링크가 관련이 있어야 함을 명시적으로 명시하는 유일한 옵션입니다. 그 이상도 이하도 아닌. 이는 날짜가 아닌 링크의 경우에도 마찬가지이지만 오랜 기간 동안 오버링크를 한 후 편집자는 명시적인 지침이 필요합니다. 라이트마우스 (talk) 2009년 3월 30일 08:28 (UTC)답장[답장]
  32. 지지 왜 관련이 없는 한 출생 연도와 같은 관련 없는 연도와 연결됩니까? 따라서 관련성이 있는 경우에만 연도와 연결됩니다. 3년 전 프로젝트에 참여했을 때 왜 몇 년을 연결했는지 어리둥절했습니다. 그것은 과거에도 그랬고 또 시간 낭비이며, 기사에 아무 것도 추가하지 않습니다. --HJensen, talk 09:13 (UTC)답변[답변]
  33. 해들이 "관련성이 있는" 경우는 거의 없다는 점에서 주의해야 합니다. Bongomatic 2009년 3월 30일 09:14 (UTC)답장[답장]
  34. 서포트. 예전처럼 더 이상 말할 필요가 없습니다. 이것, 저것 그리고 나머지 2009년 3월 30일 09:29 (UTC)\답장[답장]
  35. 서포트. 관련이 없는 연도는 연결할 필요가 없으며 대부분입니다. 익스트림 프로 (talk) 2009년 3월 30일 09:30 (UTC)답장[답장]
  36. 지원 역사적인 해를 배경으로 한 많은 영화들이 링크할 가치가 있습니다. 그렇지 않으면 저는 날짜를 링크할 필요가 없다고 봅니다. Alientraveler (talk) 2009년 3월 30일 09:51 (UTC)답장[답장]
  37. 지원: 연도에 관련성이 있으면 유용하고, 연도에 관련성이 없으면 유용하지 않습니다. 여기에는 신중함이 필요합니다.익명의 반체제Talk 인사 2009년 3월 30일 (UTC) 10:09 답변[답변]
  38. 서포트. 링크는 항상 독자와의 관련성과 가치에 따라 판단해야 합니다. TKD::{talk} 2009년 3월 30일 11:11 (UTC)답장[답장]
  39. 서포트. 제가 정확하게 이해했다면, 이것이 지금 우리가 하는 일입니다. 저는 바꿀 이유가 없다고 봅니다. 기사에 도움이 되지 않는 링크를 추가하는 것은 독자들이 추가적인 관련 정보를 어디서 찾을지 착각하기 때문에 위키백과에 해를 끼칩니다. --Kotniski (talk) 2009년 3월 30일 (UTC)11:26 (답변)
  40. 서포트. 재치 있는 글을 쓰려고 했는데, 비쇼넨은 제가 가질 수 있는 것보다 훨씬 더 잘 요약했습니다(아니면 그럴 수도 있을까요?). Casliber (talk·기여) 2009년 3월 30일 (UTC) 11:32 답변[답변]
  41. 지원 옵션 2도 유혹적이었지만, 댓글 섹션에 있는 아더 루빈의 코멘트(해석하기에는 너무 열려 있다는 것)는 좋은 점이며, 신입들을 겁주기 위해 또 다른 세부 사항을 추가할 것이라는 문제도 있습니다. 그래서 옵션 2를 지원할 수 없습니다(예를 들어, 기사의 첫 문장에 연도만 연결하고, 여기서 X 사람이 태어났거나 X 책이 작성된 경우), 그리고 그 때에도 지원하지 않을 수 있습니다. 반면 옵션 1은 옵션 2와 동일한 종류의 연결 및 연결 해제를 효과적으로 허용할 수 있으며, 기억하기 쉬운 "경험의 법칙"입니다. r ʨana ɢ / 2009년 3월 30일 (UTC)응답하라[답변]
  42. 가장 합리적인 제안을 지지합니다. 기사가 사소한 링크로 오버링크되면 안 됩니다. - Darwinek (talk) 2009년 3월 30일 (UTC) 13:24 (답변)
  43. 지원 - 이것이 최선의 선택인 것 같습니다. Camw (talk) 2009년 3월 30일 13:40 (UTC)답장[답장]
  44. 지원 - 지난 몇 달 동안 익숙해진 내용이며, 다른 링크와 마찬가지로 작동합니다. 이는 4번에 해당하지만, 이곳의 역사 때문에 특별한 지도가 필요합니다. --NE2 13:42, 2009년 3월 30일 (UTC)답장[답장]
  45. 지원, 월-일 연결과 마찬가지로.에밀 J. 13:44, 2009년 3월 30일 (UTC)답장[답장]
  46. 최선의 선택이기 때문에 지원하지만 연도 연결은 거의 관련이 없습니다. Sandy Georgia (Talk) 2009년 3월 30일 13:45 (UTC)답장[답장]
  47. 지지 그러나 여기에는 중요한 산문이 있어야 하고 파이프 링크를 통해 연결될 수 있는 관련 기사가 있을 가능성이 있습니다(예: 유럽 정치의 경우 XXXX, 아시아 예술의 경우 YYYY, XXXX와 YYYY는 주제와 시간에 따라 몇 년, 수십 년 또는 몇 세기가 될 수 있음). 그러한 링크는 일반적으로 현재 가지고 있는 쓸모없는 연도 목록보다 관련이 있을 가능성이 더 높습니다. 지침서에서 이러한 piped context 링크를 독자에게 더 유용하게 사용할 가능성이 높은 것으로 제안하는 것도 괜찮을 것입니다. GR베리 2009년 3월 30일 14:08 (UTC)답장[답장]
  48. 월간 여론조사에 대한 나의 답변대로 지지 - Dumelow (talk) 2009년 3월 30일 14:19 (UTC)응답하라[답변]
  49. 월간 강력 지지 여론조사 Cnilep (talk) 2009년 3월 30일 14:37 (UTC)응답하라[응답하라]
  50. 연도는 주로 연대기적 기사에서 절대적으로 관련이 있을 때만 연결된다는 것을 지지합니다. 저는 다른 옵션에 반대합니다. Karanacs (talk) 2009년 3월 30일 15:30 (UTC)답장[답장]
  51. 비쇼넨의 지원. 하지만 다시 한 번 말하지만, 저는 이것이 조금 더 강력하기를 바랍니다. 연도 기사는 거의 항상 당면한 주제와 무관하며 거의 절대로 관련되어서는 안 됩니다. 특정 연도에 발생한 이벤트를 참조하고 싶다면 해당 이벤트를 연결하는 것이 훨씬 더 논리적입니다. Pfainuk talk 15:44, 2009년 3월 30일 (UTC)답장[답장]
  52. 아마도 앞으로 이 문제에 대한 공식적인 지침은 삭제될 수 있을 것입니다. 한동안 오락가락했던 사안이라 일단은 필요할 것 같습니다. --TreyGeek (talk) 2009년 3월 30일 (UTC) 15:49 (답변)
  53. 서포트 기본적으로 위와 같습니다. Alan16 15:54, 2009년 3월 30일 (UTC)답장[답장]
  54. 위의 대부분을 기반으로 한 강력한 지원. Johnny Au 2009년 3월 30일 (UTC) 15:58 답변[답변]
  55. 개인적으로 날짜 기사를 제외하고는 연도에 대한 링크가 의미가 없다고 생각하지만, 지지가 가장 합리적입니다. 저는 파이프 링크가 좋은 생각이고 낙담해서는 안 되며, 직접적인 링크를 억제하는 것이 더 잘 보이게 할 것이라고 생각합니다. Ordinchaos 2009년 3월 30일 16:04 (UTC)답장[답장]
  56. Sandy Georgia가 한 을 지지합니다. --Deller (talk) 2009년 3월 30일 (UTC) 16:05 답변[답변]
  57. 지원, 부분적으로 "여기서 링크"에 사용할 수 있습니다. 저는 옵션을 평가합니다: 1,2,4,3. 관련 없는 트리비아 목록에 대한 쓸데없는 링크를 제거합시다. 옵션 2도 유혹적이고 저도 기꺼이 받아들이겠습니다. Certes (talk) 2009년 3월 30일 16:10 (UTC)답장[답장]
  58. 지원 - Gran2 16:15, 2009년 3월 30일 (UTC) 회신[답변]
  59. 지원, 불필요하게 기사를 오버링크할 필요가 없습니다. 플라스틱 포크 (talk) 2009년 3월 30일 16:25 (UTC)답장[답장]
  60. 서포트. 레트테타스트 (talk) 2009년 3월 30일 (UTC) 16:28 답변[답변]
  61. 서포트. 개인적인 논리가 우세합니다. 어떤 지침이 있어야 할 것 같은데, 어떻게 시간을 소모할 수 있는지 궁금합니다. Greggers 2009년 3월 30일 (UTC) 16:31 답변[답변]
  62. 서포트. 우리가 할 수 있는 모든 것은 불필요한 몇 년의 오버링크를 최소화하기 위해서 입니다. --Skeeezix1000 (talk) 2009년 3월 30일 (UTC) 16:34 (답변)
  63. 서포트. 이는 관련 링크만 만들라는 일반적인 가이드라인과 일치합니다. Debresser (talk) 2009년 3월 30일 (UTC) 16:56 답변[답변]
  64. 서포트. 우리는 독자의 이익을 위해 양질의 링크를 지향해야 합니다. 좋은 조치입니다. -- Banjeboi 16:59, 2009년 3월 30일 (UTC)응답하라[답변]
  65. 서포트. 기사와 관련된 연도와 관련된 연도를 구별하는 것이 중요합니다. 종종 첫 번째 것은 사실이고, 매우 드물게는 후자입니다. 향후 분쟁을 피하기 위해서는 명확한 안내가 필수적입니다. 연도 기사가 1345, 1346 및 1347의 품질에 도달하면 이들에 대한 링크가 관련될 가능성이 높습니다. 이 옵션을 사용하면 연도별 기사가 개선될 때 관련 링크를 사전에 차단하지 않고 오버링크의 현재 상태를 제거할 수 있습니다. --RexxS (토크) 2009년 3월 30일 (UTC) 17:14 (답변)
  66. 내용이 맥락과 관련이 없는 기사에 링크할 때, 우리는 독자들이 관련 기사에 링크되는 것을 방해함으로써 독자들에게 서비스를 제공합니다. 대부분의 경우 연도 연결은 연결되는 기사의 맥락과 무관합니다.Black Falcon(Talk) 17:19, 2009년 3월 30일 (UTC)답장[답장]
  67. 다시 한번, 모든 링크는 의미론적 가치를 가져야 합니다. Orange Dog (talk 편집) 2009년 3월 30일 17:28 (UTC)답장[답장]
  68. 말이 되네요--Scott Mac (Doc) 2009년 3월 30일 (UTC) 17:32 답변[답변]
  69. 지원 다른 옵션에 대한 모든 단점은 저에게 강하게 공감됩니다. What am I doing (talk) 2009년 3월 30일 17:37 (UTC)응답하라[답변]
  70. 월별 링크를 지원합니다. Rupert Millard (Talk) 2009년 3월 30일 (UTC) 17:39 답변[답변]
  71. 서포트. 위와 같이: 이것은 "상식" 옵션이어야 합니다. 달리 그럴 이유가 없다고 생각하기 때문입니다. 날짜는 관련된 경우 다른 것과 동일한 규칙으로 연결되어야 합니다.2009년 3월 30일 (GMT) 18:20 †
  72. Pro --Morten (talk) 2009년 3월 30일 (UTC) 18:27 답변[답변]
  73. Sandy Georgia에 대한 지지. --철학자 2009년 3월 30일 (UTC)응답하라[답변]
  74. 지지: 그들을 연결하는 것의 요점을 알 수 없습니다. 이 섹션을 지원하는 다른 사람들은 훨씬 더 좋다고 말했습니다! Maedin\talk 2009년 3월 30일 (UTC) 18:39 답변[답변]
  75. 서포트. 몇 년을 연결하는 건 중요하지 않아요저는 그것들을 직접 사용하지 않기 때문에 그것은 저에게 코드 크루프로 점수를 매깁니다.
    ⋙–베레안Hunter (() 2009년 3월 30일 (UTC) 19:08 (답장)
  76. 이 옵션을 지원하는 것이 제시된 것 중 가장 좋은 것 같습니다. Mjroots (talk) 2009년 3월 30일 19:15 (UTC)답장[답장]
  77. 서포트. 날짜 연결과 마찬가지로 가끔만 유용합니다. Mr Stephen (talk) 2009년 3월 30일 (UTC) 19:56 답변[답변]
  78. 가장 논리적으로 지원합니다. KellenT 2009년 3월 30일 20:20 (UTC)답장[답장]
  79. 지원 가장 논리적이고 실용적인 옵션입니다. ~EdGl 2009년 3월 30일 (UTC) 20:59 답변[답변]
  80. 서포트. 날짜와 동일하게, 몇 년은 때때로 관련될 수 있지만, 매우 드물기 때문에 많은 경우 주의와 관련이 있습니다.Joe N 21:36, 2009년 3월 30일 (UTC)답장[답장]
  81. 한스 아들러가 지원합니다.Josiah Rowe (talk 기고) 2009년 3월 30일 21:50 (UTC)답장[답장]
  82. 지원 첫 번째 기사와 무관한 기사로 연결되는 것을 피하고, 말이 되는 유일한 옵션입니다. - Hunt (talk) 2009년 3월 30일 (UTC) 22:10 (답변)
  83. 서포트. 연결된 연도는 일반적으로 연결된 월+일보다 관련성이 훨씬 낮습니다. Ross Patterson (talk) 2009년 3월 30일 22:15 (UTC)응답하라[답변]
  84. 서포트. 월별 연결 여론조사와 마찬가지로 옵션 1이 거리상 가장 좋은 옵션입니다. 유용한 경우는 드물고, 대량으로 과다 사용됩니다. Julianhall (talk) 2009년 3월 30일 22:27 (UTC)답장[답장]
  85. 지지 불성실 speak( ) 2009년 3월 30일 (UTC) 22:55 답변[답변]
  86. 지원 - 저는 이러한 연결고리가 의미가 없다고 생각하며, 앞서 말했듯이, 저는 그것들이 제거된 경우를 놓치지 않았습니다. Giants2008 (17-14) 00:25, 2009년 3월 31일 (UTC)답장[답장]
  87. 지지자 여러분, 이것이 최선의 선택이며, 일반적인 연결 지침을 준수하는 한 해를 연결하는 것에 동의합니다. 다만 영화의 한 해, 스포츠의 한 해, 한 해 등을 연결하는 것만으로는 그렇지 않습니다. -- Collectonian (talk·기여) 2009년 3월 31일 02:00 (UTC)응답하라.
  88. 서포트. 밝은 파란색은 시각적 주의를 산만하게 하며 오직 수치학자들에게만 해당됩니다. VikSol 02:42, 2009년 3월 31일 (UTC)답장[답장]
  89. 지원, 옵션 1은 날짜 링크가 다른 링크처럼 취급된다는 것을 의미할 뿐만 아니라 전쟁을 되돌리는 데 종지부를 찍도록 하는 지침도 있을 것입니다. 연결은 이미 끝났고 연결 해제는 변화를 의미하기 때문에 가이드라인이 필요합니다. 만약 이매진이라는 단어가 매번 연결되어 있었다면 갑자기 연결되지 않았다고 상상해보세요. 가이드라인을 통해 단기적인 혼란을 방지할 수 있습니다. Sillyfolkboy (talk) 2009년 3월 31일 02:47 (UTC)답장[답장]
  90. 우리가 있어야 할 위치에 도달할 수 있는 모든 날짜의 대량 링크 삭제를 지원하고 또한 지원합니다. 일부 링크 Hmains (talk) 2009년 3월 31일 (UTC) 03:08 (답변)
  91. 서포트. 대부분의 연도는 과연결이 심하고 기사 내용과 무관합니다. 레인보우 오브 라이트 2009년 3월 31일 03:28 (UTC)답장[답장]
  92. 첫 번째 선택. shoy(응답) 2009년 3월 31일 03:36 (UTC)답장[답장]
  93. 서포트. 오버링크를 제한하고 기사의 가독성과 링크의 효용성을 높이기 위한 최선의 선택은 관련되거나 유용한 주제일 경우 다른 단어로만 링크하는 것입니다. --Clay Collier (talk) 2009년 3월 31일 (UTC)05:08 (답변)
    첫 번째 선택을 지지합니다. 연도와 날짜는 다른 링크와 같기 때문에 관련된 경우에만 연결해야 합니다. 더 나은 것은 날짜를 연결하는 것을 연결하고 날짜를 연결되지 않은 이벤트로 남겨두는 것입니다. SDY (talk) 2009년 3월 31일 05:26 (UTC)답글[답글]
  94. 사람이 태어난 해는 거의 관련이 없습니다. WP:mos는 그것을 지적해야 합니다. 이 옵션 또는 4번을 지원합니다. 귀하의 George Louis (talk) 2009년 3월 31일 05:55 (UTC)답장[답장]
  95. 서포트. 다시 말하지만, 위키피디아에 가입한 이후로 항상 저를 혼란스럽게 했던 또 다른 것입니다. 링크는 항상 관련이 있어야 합니다. 문의 사항이 있으시면 제 토크 페이지로 연락주시기 바랍니다. 이안 망카 2009년 3월 31일 (UTC) 06:23 답변[답변]
  96. 지원하지만 자동 포맷이 없는 것은 아닙니다. 특히 마이너스 연도(0년 이전)의 경우. 우리가 위키피디아 데이터를 흥미로운 방식으로 노출시키는 더 멋진 도구를 원한다면, 우리는 아주 노골적인 방식으로 몇 년을 써야 합니다. Nicolas 1981 (talk) 2009년 3월 31일 06:36 (UTC)답장[답장]
  97. 지원: 관련 정보가 있는 기사만 연결해야 하며, 그렇지 않은 경우 왜 연결됩니까? 다른 용도는 트리비아입니다. NJGW (talk) 2009년 3월 31일 07:48 (UTC)답장[답장]
  98. 지원: 저는 옵션 2에 기대어 있었지만, 실제로는 누군가가 태어난 지 1년 정도 되었을 때 그 사실을 알 수 있는 이점이 없다고 봅니다. - 워먼 я로우 2009년 3월 31일 (UTC) 08:21 (UTC)답장
  99. 다시 한번 지지 부탁드립니다. 불필요한 파란색 링크를 줄이기 위한 최선의 방법으로 보입니다. --JD554 (토크) 2009년 3월 31일 (UTC)11:43 (답변)
  100. 월/일과 마찬가지로 위. Sandstein 2009년 3월 31일 11:50 (UTC)답장[답장]
  101. 지원하지만 옵션 1은 1795년과 같은 일반 연도 기사와 연결해야 하는 이유에 대한 좋은 예를 제공하지 않습니다. 콜린°Talk 12:48, 2009년 3월 31일 (UTC)답장[답장]
  102. 서포트. 또한 스포츠에서 1964년과 같은 기사는 다소 쓸모가 없기 때문에 링크하는 것을 피하라고 제안하고 싶습니다. 제2차 세계 대전 (1942) 타임라인 괜찮습니다. --Apoc2400 (talk) 2009년 3월 31일 (UTC) 15:12 (답변)
  103. 서포트. Bubba73 (talk), 2009년 3월 31일 15:55 (UTC)답장[답장]
  104. 서포트. 최선의 선택입니다. --Jc3s5h (talk) 2009년 3월 31일 16:38 (UTC)답장[답장]
  105. 지지를 받지만, 1년을 의미 있게 연결해 주는 것이 무엇일지에 대한 전망은 다소 빠듯해야 합니다. Gwen Gale (talk) 2009년 3월 31일 16:47 (UTC)응답하라[답변]
  106. 서포트, 위와 같이. noq (talk) 2009년 3월 31일 17:07 (UTC)답장[답장]
  107. 지원 관련 없는 링크는 의미가 없습니다. 그들이 "흥미롭다"는 것은 요점이 아닙니다(그리고 어쨌든 다소 가능성이 없는 결과이기도 합니다: 그 기사들을 읽어본 적이 있습니까?). Richard75 (talk) 2009년 3월 31일 17:26 (UTC)응답하라[답변]
  108. 서포트. 해당 연도가 기사와 직접적인 관련이 있는 경우에만 링크합니다. 링크에 관한 한 더 적습니다. 링크가 많을수록 각 링크의 영향이 줄어듭니다. SlimVirgin 2009년 3월 31일 17:36 (UTC)답장[답장]
  109. 가장 논리적인 지원. 옵션 4는 제거된 후에 모스데이트 지침을 다시 만드는 것을 배제하지 않는 것 같습니다. 1을 제외한 모든 옵션은 너무 많은 상황에서 링크 밀도가 지나치게 높아지게 됩니다. -- Quiddity (talk) 2009년 3월 31일 (UTC) 18:05 (답변)
  110. 다시 한 번 관련 링크만 연결하고 독자들에게 관련 없는 링크를 많이 범람시키지 않도록 지원합니다. 횡설수설하는 남자 (talk) 2009년 3월 31일 18:14 (UTC)응답하라[응답하라]
  111. 서포트. WP의 날짜 정책은 다음과 같습니다.OVERLINK는 스스로를 정당화합니다. Daniel J Simanek (talk) 2009년 3월 31일 18:46 (UTC)답장[답장]
  112. 지원 - 모든 것은 맥락에 관한 것입니다. 1년에 대한 기사의 99%는 해당 연도를 포함하는 다른 기사의 주제와 관련이 없습니다. "Background" 문과 관련하여, 피핑된 링크는 항상 상황에 맞는 이어야 합니다. "Year in what" 링크는 거의 항상 "See seo" 섹션에 속합니다. --IllaZilla (talk) 2009년 3월 31일 (UTC)응답하라[답변]
  113. 지원: 직접적인 관련이 있을 때만, 독자들의 부담을 줄이기 위해. CRG Greathouse (tc) 2009년 3월 31일 20:00 (UTC)답장[답장]
  114. 지원, 두 번째 선택. 옵션 2번이 첫 번째 선택입니다.Quadell 2009년 3월 31일 (UTC) 20:04 회신[답변]
  115. 서포트. 문맥과 무관한 링크는 피할 가치가 있으며 날짜에 대해 예외를 둘 이유가 없습니다. ~ mazca 20:50, 2009년 3월 31일 (UTC)답장[답장]
  116. 지원, 시각적으로 어수선하고 매우 낮은 가치의 링크만 추가합니다. 지상 영점 23:40, 2009년 3월 31일 (UTC)회답[회답]
  117. 지원 - 정책을 설정하여 문제를 해결합니다. 정책은 엄격하게 시행될 필요가 없으며 정책에 대한 인식이 높을 필요가 없습니다. Hawthorn (talk) 2009년 3월 31일 (UTC) 23:55 해명: 연결 날짜가 아예 없는 것을 선호합니다. Hawthorn (talk) 2009년 4월 2일 (UTC) 09:53 답변[답변]
  118. 제공되는 유일한 합리적인 옵션을 지원하고 날짜를 기사 내용과 연결되는 관련 목록에 연결합니다. FWiW Bzuk (talk) 01:00, 1 April 2009 (UTC).회답[회답]
  119. 지원 - 관련성 좋음 - 관련성 없음 나쁨. --Kbh3talkrd 2009년 4월 1일 (UTC) 01:29 답변[답변]
  120. 요약마다 지지해 주세요. 출생연도와 사망연도를 연결할 필요가 없고, 이미 출생연도와 사망연도의 범주와 그 이후의 범주를 연결할 필요가 없으며, 수백만 년을 연결해도 실질적인 가치가 없습니다. --ClubOranjeT 01:54, 2009년 4월 1일 (UTC)응답하라[답변]
  121. 서포트. 대부분의 해는 연결이 필요하지 않습니다. 링크를 가지고 기사에 무엇이든 추가하는 사람은 소수에 불과합니다. --Budke (토론) 2009년 4월 1일 (UTC)응답하라[답변]
  122. 가장 논리적인 옵션으로 지원합니다. 편집 전쟁을 피하기 위해서는 링크를 추가하기 위한 강력한 사례를 만들 수 있는 경우에만 사용하라는 지침이 있어야 합니다. 베가스위키안 (talk) 2009년 4월 1일 03:57 (UTC)답장[답장]
  123. 다시 말하지만, 1년 링크가 언제 독자에게 도움이 될지 확신할 수 없습니다.demonhogtalk 편집 06:53, 2009년 4월 1일 (UTC)답장[답장]
  124. 서포트. 루슬릭 (talk) 2009년 4월 1일 07:23 (UTC)답장[답장]
  125. 서포트. 가장 관련성이 높은 옵션입니다. --Popiloll (talk) 2009년 4월 1일 (UTC)응답하라[답변]
  126. 지원—일월 링크와 마찬가지로 연도 링크도 다른 잠재적 링크와 마찬가지로 취급되어야 합니다. 그러나 아직 옵션 4에 대한 준비가 되지 않았습니다. 오버링크하지 않도록 명시적으로 안내하는 것이 지금까지의 피해를 되돌리는 데 있어서도 도움이 될 것입니다. JIMp talk·cont 08:44, 2009년 4월 1일 (UTC)답장[답장]
  127. 서포트. 실크토크 YES!* 2009년 4월 1일 11:15 (UTC)답장[답장]
  128. 지원 너무 많은 연도 링크는 성가시고 보통 가치가 없습니다. Cheesy Biscuit (talk) 2009년 4월 1일 12:50 (UTC)답장[답장]
  129. 지원 이것이 최선의 선택입니다. VJ (talk) 13:03, 2009년 4월 1일 (UTC)답장[답장]
  130. 서포트. day-month linking과 같은 주장입니다. 매트 13:09, 2009년 4월 1일 (UTC)
  131. 지원 사실상 연중 기사 중 링크할 가치가 있는 기사는 없으며 기존의 오버링크를 롤백하기 위한 구체적인 지침이 필요합니다. 이러한 링크가 제공하는 메타데이터는 너무 모호해서 가치가 없습니다. 그 해에 어떤 알 수 없는 방법으로 기사의 주제와 관련된 어떤 특정되지 않은 사건이 일어났다는 것을 아는 것은 누구에게도 도움이 되지 않습니다. 식민지 크리스 (talk) 2009년 4월 1일 13:13 (UTC)답장[답장]
  132. 지원 연도 링크는 오버링크입니다. --Phil Holmes (talk) 2009년 4월 1일 (UTC) 15:17 답변[답변]
  133. 지원 - 저는 1985년생입니다. 하지만 저는 제 생일을 1985년생으로 기재할 자격이 없다고 생각합니다. 그러나 1938년 기사에서 크리스털나흐트를 언급하는 것은 그 무렵에 무슨 일이 일어났는지 연대표를 보여주는 데 도움이 될 것입니다. Fighting' Phillie (talk) 2009년 4월 1일 18:05 (UTC)응답하라[응답하라]
  134. 서포트. 아주 예외적인 이유로만 연도를 연결합니다. 모든 링크는 기사에 충실해야 합니다. "해당 주제에 대해 더 많이 읽으십시오."와 같은 것은 혼란스럽지 않고 무관하지 않습니다. 출생일과 사망일이 연결되어서는 안 됩니다. 이것은 오버링크입니다. "도시", "천문학자", "독일어" 등과 같은 일반적인 용어에 대해 제가 따를 것과 같은 추론입니다. 마기올라디티스 (토크) 2009년 4월 1일 (UTC) 19:44 답변
  135. 지원 - WP별:OVERLINK. Ed Johnston (talk) 2009년 4월 1일 (UTC) 19:51 답변[답변]
  136. 서포트. 해당 연도는 링크만 가능합니다. 파워 23:44, 2009년 4월 1일 (UTC)답장[답장]
  137. 지원 - 일별 연결 기준. Hamiltonstone (talk) 00:51, 2009년 4월 2일 (UTC)답장[답장]
  138. 지원 무의미한 링크는 유용한 링크의 가치를 희석시키고 주의를 산만하게 합니다. Joonuniq (talk) 02:59, 2009년 4월 2일 (UTC)답장[답장]
  139. 지원 거의 모든 경우에 날짜 링크는 무관하고 주의를 산만하게 합니다. 그렇지 않은 소수에 대해서는 예외를 둘 수 있습니다. Rivertorch (talk) 2009년 4월 2일 (UTC) 05:35 답변[답변]
  140. 제 마음을 읽고 있는 것처럼 보이는 Rivertorch에게 다시 한번 지지를 부탁드립니다.--Aervanath (talk) 2009년 4월 2일 (UTC) 05:39 답변[답변]
  141. 서포트. 저는 1년 링크를 따라본 적이 없고 관련성이나 관심사를 찾은 적이 없기 때문에 링크를 넣기에는 시간이 낭비되고 가치가 높은 링크를 희석시킵니다. 관련된 몇 년은 연결로 인해 이익을 얻을 수 있지만 거의 없습니다.YobMod 2009년 4월 2일 (UTC) 09:06 답변[답변]
  142. 지지 일부 기사에서 볼 수 있는 푸른 바다는 관련 없는 날짜 링크가 있어 악화됩니다. 관련 링크만 유용하므로 이 링크만 파란색으로 강조 표시해야 합니다. WP 참조:OVERLINK -m-i-k-e-y-talk 2009년 4월 2일 (UTC) 11:05 답변[답변]
  143. 서포트. 연도 연결은 특정 주제에 대한 기사에서 최대 연도까지 이루어져야 합니다. -Woodstone (talk) 2009년 4월 2일 (UTC) 11:34 답변[답변]
  144. 지원, 월/일 링크에서 옵션 1위를 지원하는 것과 거의 같은 이유로 지원합니다. --R'n'B (Russ라고 불러주세요) 2009년 4월 2일 (UTC) 13:33 답변[답변]
  145. 특정 연도에 링크된 기사가 너무 많아서 "여기 링크" 링크가 무용지물이 됩니다.--NullSpace (토크) 2009년 4월 2일 (UTC) 15:12 (답변)
  146. WP에 따르면 지원:오버링크: "...명백하고 중복되고 쓸모없는 링크로 페이지를 어수선하게 만드는 것은 피하세요." --Roise step (talk) 2009년 4월 2일 (UTC)답장[답장]
  147. 지원, "Never link a year" 옵션이 없었기 때문입니다. "제2차 세계 대전(1942)"이나 "1942년의 미국 영화"는 연결될 수 있습니다. "1942"는 거의 없습니다. --Alvestrand (talk) 2009년 4월 2일 18:49 (UTC)답장
  148. 서포트. 가장 합리적인 옵션은 다음과 같습니다. 가장 일반적인 타임라인 마커에 불과한 연도를 연결하지 마십시오. 연도 기사가 관련 컨텍스트를 제공하는 경우 선택적으로 연도를 연결합니다. Esobocinski (talk) 2009년 4월 2일 20:04 (UTC)답장[답장]
  149. 서포트. 다른 모든 것과 마찬가지로 맥락이나 유용성을 위해 필요할 때만 연도를 연결합니다. 저는 이것이 왜 지금까지 논란이 되었는지 정말 궁금합니다. Steve 2009년 4월 2일 (UTC) 22:08 답변[답변]
  150. 지원 – 일부 편집자는 이 규칙을 다른 편집자보다 더 느슨하게 해석할 수 있지만(예를 들어 기사에서 모든 연도의 연결을 지원하기 위해 다양한 "합리적"을 사용하는 것), 링크 밀도와 관련성을 줄이기 위해 포맷 변경이 필요합니다. 게다가, [[2008 in film 2008]]과 같은 piped year 링크는 독자들에게 유용합니다. momoricks (make my day) 2009년 4월 3일 (UTC)응답하라.
  151. 지원 - 월 및 일 단위로 제공됩니다. 관련성은 몇 년 동안 결정하기 어려운 것이 아닙니다. Australian Matt (talk) 2009년 4월 3일 02:13 (UTC)답장[답장]
  152. 지원 - 모든 링크는 사용자와 관련이 있어야 합니다. Cycle (talk) 02:34, 2009년 4월 3일 (UTC)답장[답장]
  153. 서포트 - 관련 링크는 오버링크를 방지할 수 있습니다. MathCool 1004:39, 2009년 4월 3일 (UTC)답장[답장]
  154. 서포트. 그러나 지침은 과학의 1924와 같은 링크를 강력하게 권장해야 합니다. 이에 대한 대안으로 섹션도 참조하십시오.머리폭탄 ταλκκοντριβς{ – WP Physics} 2009년 4월 3일 06:57 (UTC)응답하라[응답하라]
  155. 서포트. 월-일 연결입니다. Mike Christie (talk) 2009년 4월 3일 (UTC) 11:05 답변[답변]
  156. 서포트. 오버링크에 대한 표준 정책을 따르기 때문에 명백한 선택입니다. 출생/사망 옵션은 이미 이런 항목들에 대한 분류가 있기 때문에 결정권이 없는 사람입니다. -- Kelly Cook (토크) 2009년 4월 3일 (UTC) 15:56 (답변)
  157. 기사에 언급된 임의의 연도에 연결하는 것은 무의미하므로 Support Best 옵션을 사용할 수 있습니다. 분명히 관련된 연도 이상이 연결되어 있다면 링크 밀도는 너무 높을 것입니다.
  158. 서포트. 월간 연계 여론조사에서 1위 옵션을 지지한 것과 유사합니다. --seav (talk) 2009년 4월 3일 (UTC) 16:54, 답변[답변]
  159. 지원Malik Shabazz (talk·기여) 2009년 4월 3일 (UTC) 19:47 답변[답변]
  160. 지원 저는 왜 그 기사들에 대한 링크가 있는지 전혀 이해하지 못했습니다. Deegee375 (talk) 2009년 4월 3일 21:17 (UTC)답장[답장]
  161. 지원 불필요하고 도움이 되지 않는 링크를 제거합니다. 거의 항상 해당 연도와 연결하는 것은 의미가 없습니다. PamD (talk) 2009년 4월 4일 10:18 (UTC)답장[답장]
  162. 지원 개인적으로, 저는 어떤 해에도 연결할 필요가 없다고 생각하지만, 저는 이것이 최선의 선택이라고 생각합니다. 그 중 하나를 선택해야 합니다. Giano (talk) 2009년 4월 4일 11:40 (UTC)답장[답장]
  163. .Support Best 옵션. 불필요한 위키링을 방지합니다.Moseschurte (talk) 2009년 4월 4일 11:45 (UTC)답장[답장]
  164. 다시 한번 지원합니다. 월-일 연결과 마찬가지로 이것이 가장 좋은 방법이며 기존의 위키링크 가이드라인과 일치합니다. ~~ [ジャム] 2009년 4월 4일 14:19 (UTC)답장[답장]
  165. 4가지 중에서 최선의 선택을 지지합니다. --Patar knight contributions- / 2009년 4월 4일 (UTC) 18:35 답변[답변]
  166. 지원 다른 것들과 마찬가지로, 그들이 거의 하지 않는, 관련이 있는 경우에만 링크합니다. Struway2 (talk) 2009년 4월 4일 20:03 (UTC)답장[답장]
  167. 지원 위에서 자주 언급한 것처럼 거의 모든 날짜 링크는 적극적으로 쓸모가 없습니다. 어떤 기능을 수행하지 않는 한 권장되지 않습니다. Igenlode (talk) 2009년 4월 5일 02:21 (UTC)답장[답장]
  168. 지원, 최소한 최악의 옵션으로 대부분의 연도 연결은 불필요합니다. 아직 보지 못한 사용이 있을 수 있습니다. 주요 잠재적 용도는 이미 1937년 출생 등과 같은 요리법으로 충당되고 있습니다. Jezhotwells (talk) 2009년 4월 5일 12:22 (UTC)답장[답장]
  169. 서포트. 최악의 선택지 중에 최선입니다. — σ 명시적 2009년 4월 5일 (UTC) 답변[답변]
  170. 지지하다. 제가 생각하는 가장 적합한 옵션입니다. Nja247 21:09, 2009년 4월 5일 (UTC)답장[답장]
  171. 지원 - 더 나은 옵션. -- ThinkBlue (Hit BLUE) 2009년 4월 5일 (UTC) 22:53 (답변)
  172. 관련성을 연결하는 월 단위 지원. Hohob (talk) 2009년 4월 6일 01:19 (UTC)답장[답장]
  173. 지원은 맨데이트 링크가 필요 없다고 봅니다. Ever.--2008chitchat Olympian 05:03, 2009년 4월 6일 (UTC)답장[답장]
  174. 다른 방법이 아닌 진정으로 관련된 경우 Support Link. Richard New Forest (talk) 2009년 4월 6일 15:01 (UTC)답장[답장]
  175. 지원합니다. 날짜가 연결되지 않았기를 바랍니다. Corn.u.co .pia Disc.us .sion 2009년 4월 6일 16:00 (UTC)답장[답장]
  176. 지원 - 사소한 공통 연결만으로 이러한 목록에 연결하는 것은 거의 이점이 없습니다. 어떤 사건이 (어떤 해에 상관없이) 다른 사람들과 국소적으로 연결되어 있다면, 그 사건에 직접 연결되는 예의를 갖춰라. 독자들이 그 사건 주변에서 거의 임의의 365.25일 대역에서 일어난 사건들의 사소한 목록을 뒤적이게 하는 것은 유용하지도 도움이 되지도 않습니다. Knepflerle (talk) 2009년 4월 6일 (UTC) 16:51 답변[답변]
  177. 옵션을 지원하면 연결 시기에 대한 지침과 오버링크를 방지하는 데 도움이 되는 지침이 제공되며 이러한 지침은 스타일 분쟁을 최소화하는 데 도움이 됩니다.Danorton (talk) 2009년 4월 6일 (UTC) 18:20 답변[답변]
  178. 적절한 지도를 지원합니다. 수년은 거의 유용하지 않으므로 일반적으로 연결되지 않아야 합니다. 때때로 그들은 도움이 될 수 있습니다(예: 1970년대 서양 화장품 기사에서 1970년대를 연결하여 독자들이 그 시대의 다른 문화적 변화를 볼 수 있도록 합니다). 오버링크 연도(Yore의 자동 형식화 유물)에 특별한 문제가 있기 때문에 연도에 특정한 지침을 추가하는 것이 타당합니다. Calliopejen1 (talk) 2009년 4월 6일 18:29 (UTC)답장[답장]
  179. 지원 합리적인 토론을 장려하는 지침은 합리적인 편집 선택으로 이어질 가능성이 더 높습니다. 피터 2009년 4월 6일 (UTC) 답변[답변]
  180. 지원 가능한 모든 날짜 연결을 간단히 제거하는 옵션이 없기 때문에 최소한의 파란색을 제공합니다. 날짜 및 연도 링크는 기능이 없고 가독성이 크게 떨어집니다. Arsenikk 2009년 4월 6일 (UTC) 19:14 답변[답변]
  181. 지원은 주목할 만한 내용을 포함하는 위키백과의 표준인 것 같습니다. --Mrboire (talk) 2009년 4월 6일 (UTC)답변[답변]
  182. 지원 — 일관되고 일관된 상식적인 링크 정책은 우리가 잠재적으로 링크될 수 있는 다른 단어, 구 또는 숫자를 다루는 것과 동일하게 취급할 것을 요구합니다. 우리는 그것들이 현재의 기사와 정말로 관련이 있는 경우에만 링크합니다. 우리는 독자가 링크 대상을 흥미롭게 여기거나 링크 가능한 단어를 기사 텍스트의 일부로 사용하기 때문에 단순히 단어를 링크하지 않습니다.샤이너페르C·00:44, 2009년 4월 7일 (UTC)답장[답장]
  183. 지원 나 자신과 다른 사람들에 의해 여러 번 반복되었듯이, 모든 링크는 관련이 있는 경우 포함되어야 하고 그렇지 않은 경우 포함되어야 합니다. 날짜 링크도 예외가 아닙니다.
  184. 서포트. 다른 날짜 링크를 제공한 것과 같은 이유로: 무관한 링크 제공을 기본으로 하는 정책을 채택하는 것은 비양심적입니다. 대부분의 상황에서 날짜는 타임라인의 단순한 마커이며, 풍부하고 관련된 배경으로 가는 게이트웨이가 아닙니다. 따라서 대부분의 경우 링크는 잘못된 약속을 하고 텍스트의 힘과 정확성을 방해합니다. 저는 그 해가 때때로 관련이 있을 것이라는 것을 인정합니다 – 종종 한 달 또는 정확한 날. 그런 경우에는 연결하는 것이 좋은 선택일 수 있습니다. 심플!¡ɐɔıʇǝo노에티카!T– 2009년 4월 7일 07:45 (UTC)답장[답장]
  185. 와우자, 이 옵션은 압도적인 지지를 받고 있습니다. 커뮤니티가 드디어 이 문제에 대해 합의점을 찾은 것 같습니다. --Cyde Weys 2009년 4월 7일 (UTC)응답하라
  186. 지원은, 쉽게, 매년 링크를 만드는 것은 쓸모가 없습니다. 위키백과로서:오버링크가 말해요. Xenus (talk) 2009년 4월 7일 16:16 (UTC)답장[답장]
  187. 지원 - 연도에 대한 링크는 일반적으로 도움이 되지 않으며, 이 옵션을 사용하면 대부분의 연도가 제거됩니다. 로보피쉬 (talk) 2009년 4월 8일 (UTC) 00:01 답변[답변]
  188. 지원 일반적으로 몇 년을 연결할 필요가 거의 없으며 권장되어서는 안 되지만 적절한 경우가 있습니다. Nick-D (talk) 2009년 4월 8일 11:21 (UTC)답장[답장]
  189. 지원 매년 링크를 걸 필요는 없지만 일부 링크는 유용할 것입니다. -- MightyWarrior (talk) 2009년 4월 8일 (UTC) 11:42 (응답)
  190. 지원 베스트 옵션 --Armchair info guy (talk) 2009년 4월 8일 (UTC) 14:58 답변[답변]
  191. 지원은 당일 제 지원과 일치합니다. 몇 년 동안 다른 지원은 혼란스러울 것입니다. --Ged UK 20:14, 2009년 4월 8일 (UTC)답장
  192. 지원: 옵션 2는 너무 모호하고, 오버링크의 부하와 오버링크에 대한 싸움으로 이어질 것입니다. 옵션 3은 전혀 의미가 없습니다. (비정상적인 맥락을 제외하고는 여성음식과 같은 일상적인 단어의 첫 번째 발생을 연결하지 않는 것과 같은 이유로). MOS가 존재하는 데는 이유가 있기 때문에 옵션 4는 무의미하며, 피할 수 없는 날짜 관련 분쟁은 자동으로 MOS 토론과 이 문제에 대한 궁극적인 지침을 다시 발생시킵니다.SMC캔들리쉬 [talk] [cont] ‹(-¿-) › 03:02, 2009년 4월 9일 (UTC)답장[답장]
  193. 서포트. 몇 년을 연결해야 하는 경우가 많이 생각나지 않지만, 그렇게 하면 기사에 대한 독자의 이해가 향상될 수 있다면 옵션을 사용할 수 있어야 합니다. 아이세린talk 2009년 4월 9일 09:59 (UTC)답장[답장]
  194. 지원 링크는 시각적으로 산만합니다. 관련 없는 링크는 가독성을 줄입니다. Cstaffa (talk) 2009년 4월 10일 00:01 (UTC)답장[답장]
  195. 지원 - 확실히 모든 것 중 최고의 선택입니다. 관련된 것들은 링크를 걸어주세요. 기사에 실제로 추가되니, 다른 것들은 링크를 걸지 마세요. --Alinnisawest,Dalek Empress (여기서 퇴출 요청) 2009년 4월 10일 (UTC) 03:07 (답변)
  196. 지지력이 약합니다. 평일을 연결하지 않는 것처럼, 저는 몇 년을 연결하지 않는 것을 선호합니다(저는 희망합니다). "관련 연도"는 제게 POV로 로딩된 것 같고 편집 전쟁으로 이어질 수 있습니다. 하지만 이것은 4.의 가장 최악의 선택사항입니다. – IbLeo (talk) 05:32, 2009년 4월 10일 (UTC)응답하라[답변]
  197. 배관에 대한 지원 저는 배관이 없는 해 동안 이 지침을 지원합니다. 1년 동안 많은 일들이 일어나고, 대부분은 서로 관련이 없으며, 그런 기사들로부터 한 해가 연결되어서는 안 됩니다. 그러나 관련 맥락을 정의하기 위해 1년이 적절하게 파이프로 연결된다면 이는 허용 가능한 타협이라고 생각합니다. 2000년은 쓸모없는 트리비아 페이지이지만, 영화에서 2000년은 의미가 있을 수 있습니다(예를 들어, 영화의 연도별 경향을 조사하는 경우). Ham Pastrami (talk) 2009년 4월 10일 06:25 (UTC)답장[답장]
  198. 제가 한 달 간의 링크를 위해 말한 것을 지지합니다. 이 바보 같은 연결을 끝내세요.ENG (talk) 2009년 4월 10일 (UTC) 19:31 답변[답변]
  199. 강력한 지원 영화가 개봉되거나 책이 출판되거나 노래가 작곡된 해를 연결하는 것은 같은 해 안에 비슷한 업적에 대한 기사로 이어지기 때문에 의미가 있습니다. 그런데 왜 생년월일과 생년월일을 연관지을까요? 누군가 전기 기사를 읽고 그 해에 누가 태어났는지 혹은 무슨 일이 있었는지 볼 필요를 얼마나 자주 느끼나요? 209.247.22.164 (토크) 13:51 (UTC)응답하라[답변]
  200. 지원 날짜나 기사의 다른 용어와 마찬가지로, 적절한 경우, 편집자의 판단에 따라 링크합니다. 마이클 Z. 2009-04-11 16:20z
  201. 지지합니다. 연도 기사는 거의 관련이 없음을 기억하세요. --Fabricramp talk me 2009년 4월 11일 (UTC) 23:21 (답변)
  202. 지원 - 링크를 연결하는 월과 마찬가지로 링크가 당면한 주제와 어느 정도 관련이 있는 경우에만 제공해야 합니다. 모든 지침을 삭제하면 다시 도움이 되지 않으며 향후 충돌이 발생할 수 있습니다. 저는 출생/사망이 특별히 필요하다고 생각하지 않습니다. Camaron Chris (talk) 2009년 4월 12일 14:08 (UTC)답장[답장]
  203. 지지 -- "관련성"은 좀 애매하지만, 그럴 수밖에 없다고 생각합니다. 저는 특히 시인 기사의 서지학 섹션과 국적 목록의 시인 기사를 통해 수년간의 시 기사에 링크하는 작업을 많이 하지만, 이 옵션을 사용하면 가능할 것 같습니다. Year-in-Music 및 Year-in-Film 링크는 예술 작품의 역사적 맥락을 고려할 때 누구에게나 분명히 관련이 있으며, 어쨌든 누군가 링크를 클릭하는 유일한 이유일 것입니다. 연도별 주제 링크도 마찬가지입니다. -- 재검토 (담화) 2009년 4월 12일 (UTC) 18:36 답변[답변]
  204. 서포트 - 오버링크와 완전한 불모지 사이의 최상의 균형을 제공합니다. 그러나, 2003년 스포츠 링크가 적절할 때 스포츠 프로젝트가 조언할 수 있는 것과 같은 연도 연결에 대한 지침을 개선하는 프로젝트가 허용될 수 있습니다. Dl2000 (talk) 2009년 4월 13일 01:39 (UTC)답장[답장]
  205. 특히 해당 주제에 대한 기사 내의 '과목별' 기사 링크와 관련하여, 피핑 여부에 관계없이 지원합니다. 링크는 항상 관련이 있어야 하며 날짜도 예외가 되어서는 안 됩니다. 또한 자동 포맷 문제를 해결한 결과 커뮤니티에서 자동 포맷을 원하지 않거나 자동 포맷을 원하는 경우 연결된 날짜에 의존하지 않는 경우에만 자동 포맷을 목적으로 했던 링크를 제거해야 합니다. 그러나 이와 관련된 두 가지 중요한 점이 있습니다. 첫째, 자동 포맷 문제가 결정될 때까지 링크를 제거해서는 안 됩니다. 둘째, 이러한 링크를 제거하는 가장 효율적인 방법은 자동화 및 반자동화 방법을 통한 것입니다. 하지만 봇과 스크립트가 관련성을 판단하는 것은 불가능하기 때문입니다. 우선 편집자가 관련성이 있다고 판단하는 링크를 식별하고 보호할 수 있는 방법이 개발되어야 하는데, 이것이 현재 중재와 관련된 주요 이슈입니다. 이는 월/일 링크보다 연도 링크에서 훨씬 더 중요합니다. Mlaffs (talk) 2009년 4월 13일 12:26 (UTC)답장[답장]
  206. 아마도 미래에는 특별한 지침이 필요하지 않을 것이지만, 우리가 연도 연결을 다른 것들과 다르게 취급하는 선례에 익숙해져 있는 한, 두 가지에 대해 동일한 지침을 가지고 동일한 결과를 기대하는 것은 단순히 그렇지 않을 것입니다. 단순 관련성 검사에 대한 이 옵션은 티켓일 뿐입니다. 월담 공작 2009년 4월 13일 13:55 (UTC)답장[답장]
  207. 서포트. 이전에 월-일 연결에 대해 언급했듯이 관련성은 상황에 따라 다르며 재량적이지만 균형적으로 볼 때 이 제안은 대체로 수용 가능한 결과를 얻을 것입니다. 연준 2009년 4월 13일 16:35 (UTC) 답변[답변]
  208. 지원 - 단년도는 이제 말도 안 되게 오버링크 되어 있습니다. 특정 연도 기사로 가고 싶은 1만 명 중 한 명의 독자는 4자리(또는 그 이하)를 입력하고 "시작" 버튼을 누를 수 있습니다. 단지 이 극소수의 독자들을 위해 4개의 키 스트로크를 저장하기 위해 모든 기사를 어수선하게 만드는 것은 의미가 없습니다. 철자자 크리스 (talk) 2009년 4월 13일 20:24 (UTC)답장[답장]
I support 옵션 #2 (옵션 #1 + 출생/사망 년도 등)
  1. 다시 말하지만, 이것은 이 기사의 독자들을 위한 최고의 해결책으로 보이며, 연도 연결이 허용되고/되거나 권장되어야 하는 정확한 상황을 결정하기 위해 아마도 더 많은 논의가 필요할 것입니다. 옵션의 순위를 2,4,1,3으로 정하겠습니다. - Arthur Rubin (talk) 2009년 3월 29일 (UTC) 23:47 답변[답변]
  2. 서포트. 연도는 월, 일 기사보다 훨씬 더 자주 관련이 있으며 일반적으로 관련이 있는 경우 시간별 맥락을 제공하도록 연결되어야 합니다. 옵션 순위는 2,4,1,3으로 정하겠습니다. Eluchil404 (talk) 2009년 3월 30일 (UTC) 00:09 (답변)
    지원, 출생년, 사망년은 어떤 식으로든 모두 묶어야 합니다. dm (talk) 2009년 3월 30일 00:15 (UTC) 옵션 4 dm (talk) 06:03 (UTC) 답변[답변]
    서포트. 글로벌 역사적 맥락에 대해 예라고 대답하세요.육각형(❝!) 2009년 3월 30일 08:30 (UTC) 옵션 4로 변경합니다. 그러나 이것은 유일하게 합리적인 비4 옵션입니다.육각형(!❞) 2009년 3월 31일 11:49 (UTC)답장[답장]
  3. 서포트. 날짜 링크와 마찬가지로 관련이 없는 한 연도가 연결되어서는 안 됩니다. 그러나 날짜 연결과는 달리, 누군가가 태어났거나 죽은 해에 또 무슨 일이 일어났는지를 빨리 알아낼 수 있는 것과 관련이 있습니다. YLee (talk) 2009년 3월 30일 09:23 (UTC)답장[답장]
  4. 지원 생년월일이 연계되기를 바랍니다. 레이Talk 92 14:25, 2009년 3월 30일 (UTC) 답변[답변]
  5. 서포트. 독자로서, 저는 차라리 생일 등을 연계하는 것을 좋아하고, 그것에 꽤 집착하는 사람들을 알고 있습니다. 모든 "이날.."은 이런 종류의 링크의 인기를 말해줍니다.The Sidhekin (talk) 2009년 3월 30일 15:01 (UTC)답장[답장]
  6. 서포트. 인쇄 연감의 오랜 팬으로서, 저는 이 옵션이 가장 마음에 듭니다.Bellhalla (talk) 2009년 3월 30일 15:09 (UTC)답장[답장]
  7. 지원 이것은 지난 여름 논란의 여지가 있는 MoS로의 변경 이전부터 위키피디아에서 행해 온 관행입니다. 그리고 Bellhalla가 언급한 바와 같이, 이것들은 우리의 많은 사용자들에게 명백한 관심사입니다. (그리고 위의 Eluchil404의 노트에 따르면, 만약 그것이 단순히 연도 연결을 완전히 제거하는 방법이라는 것이 연결을 정당화하는 관련 연도가 없다고 주장하는 것에 대한 믿음이 없다면 저는 옵션 #1로 투표할 의향이 있습니다. 그래서 저의 첫번째 대안은 #4 -- 그 부분을 완전히 없애는 것입니다.) -- llywrch (talk) 2009년 3월 30일 (UTC)응답하라[답변]
  8. 지원 davidwr/(talk)/(기여)/(이메일) 2009년 3월 30일 18:34 (UTC)답장[답장]
  9. 지지 의견 --Cybercobra (talk) 2009년 3월 30일 (UTC) 19:53 답변[답변]
  10. 별로 신경 쓰이지는 않지만 날짜와 달이 연결될 때가 더 좋다고 생각합니다.
  11. 지지합니다. 하지만 특정 날짜(출생과 사망 등)에 한해서는 명백한 괴짜가 될 것이며 오버링크는 나쁘다고 생각하지만 날짜를 처음 연결하는 것은 문제가 없다고 말할 것입니다. 한 번은 인포박스이고 한 번은 기사 자체에 있어도 두 번은 연결할 수 있습니다. 우리는 WP가 종이 백과사전이 아니라 페이지를 다른 페이지와 "연결"할 수 있도록 하는 4차원 온라인 백과사전이라는 것을 기억해야 합니다. 저는 많은 사람들이 그것이 그들에게 가치를 거의 주지 않는다고 주장했지만, 제가 기사를 읽고 있고 날짜를 보고 싶다면 왜 제가 기사를 입력해야 그것을 보러 갈 수 있습니까? 또한 날짜에 대한 링크를 제거하려면 날짜 기사 자체를 삭제하는 것도 고려해야 합니다. 모든 링크를 제거하는 고아 날짜 기사를 상당히 많이 얻을 것입니다. --Kumioko (talk) 2009년 3월 30일 (UTC)20:20 (답변)
  12. 서포트. 저는 옵션 1번으로 투표하고 싶지만, 저는 그것이 모든 연도 링크를 제거하는 데 너무 큰 비중을 둘 것이라고 생각합니다. 저는 모든 출생과 사망이 연도별로 연결되어야 한다고 생각하지는 않지만, 특정한 경우에 있어서 친연동 주장에 대해서는 그런 것들이 도움이 될 것이라고 생각합니다. CS46 20:55, 2009년 3월 30일 (UTC)답장[답장]
  13. 또한 위의 Gavia Immer의 코멘트에 대한 옵션 4. 1000% 지지합니다. AKAF (talk) 2009년 3월 30일 07:05 (UTC)답장[답장]
  14. 가 정말로 원하는 것은 "출생과 사망을 연관짓지 마세요"라는 언어가 없는 1위입니다. 가레스 매코언(talk)
  15. 지지: 위에 다른 의견자가 말씀하신 것처럼, 글로벌 역사 개념에 대해 찬성만 하세요. -- The Anome (talk) 2009년 3월 31일 (UTC) 01:34 (답변)
  16. 지원: 출생 및 사망 연도는 빠른 역사적 맥락을 제공하는 데 도움이 될 수 있습니다. -- D. Wo. 06:50, 2009년 3월 31일 (UTC)응답하라[답변]
  17. b/d에 비중이 큰 연도 자체 기사의 일반적인 내용을 참조하여 지원합니다. David Brooks (talk) 2009년 3월 31일 17:48 (UTC)응답하라[답변]
  18. 지원, 첫 번째 선택. 1위는 저에게 2번째 선택입니다.Quadell 2009년 3월 31일 (UTC) 20:03 답변[답변]
  19. 지원, 출생/사망 연도는 역사적 맥락과 관련이 있을 때 연계되어야 합니다.Xavier, 2009년 3월 31일 21:00 (UTC)답장[답장]
  20. 지지 - 다시 말하지만, 독자들이 따라 할 수 있는 관련 링크를 제공하는 가장 합리적인 방법인 것 같습니다. Colds7ream (talk) 2009년 4월 1일 07:29 (UTC)답장[답장]
  21. 월-일 링크와 관련하여 위 옵션의 중복이 없는 이유는 무엇입니까? 다시 말하지만, 종이가 아닌 백과사전에 큰 수준의 깊이를 제공하기 때문에 저는 이것을 지지합니다. 또한 "검색을 사용할 수 있습니다"라는 주장이 3월 2일과 같은 검색어(지역별 차이는 무시됨)와 같이 작동할 수 있지만, 만약 제가 105년에 일어난 사건을 찾고 싶다면, 저는 많은 잘못된 긍정을 얻을 것입니다. 다시 말하지만, 모든 연도가 연결되어야 하는 것은 아니지만, 이 주제와 관련하여 매우 중요한 모든 것은 잠재적으로 연결될 수 있습니다. -- ζα ππερνα ππερ 08:35, 2009년 4월 1일 (UTC)답장
  22. 지원: WP:팝업 또는 기타 스크립트를 통해 연간 페이지로 이동할 수 있기를 원하지만(메타 데이터를 자동 포맷하는 경우 더 쉬울 수 있음) 일반적으로 관련 없는 과도한 가시 링크는 좋지 않습니다. Mark Hurd (talk) 2009년 4월 2일 (UTC) 02:47 답변[답변]
  23. 지원 비록 10년, 시대 또는 유사한 것이 출생 연도에 대한 연도 기사보다 더 나을 수 있습니다. Taemyr (talk) 2009년 4월 2일 06:01 (UTC)답장[답장]
  24. 지원 출생일과 사망일은 관련이 있으며 처음부터 옵션 1에 포함되어야 합니다(특히 목록에 있는 사람들이 이미 연결된 연도 페이지에 있는 경우) - MGM 2009년 4월 2일 (UTC)응답하라[답변]
  25. 출생 및 사망 연도 지원은 어떤 경우에도 "관련성이 있는" 것처럼 보입니다. Ed Fitzgerald 2009년 4월 2일 (UTC) 13:04 답변[답변]
  26. 에게 출생/사망 연도는 관련된 연결고리입니다. --ThaddeusB (talk) 2009년 4월 2일 (UTC) 16:29 (응답)
  27. 사람, 단체 등의 출생/사망 연도 지원은 관련 링크입니다. -Arb. (talk) 2009년 4월 2일 (UTC) 22:05 답변[답변]
  28. 지원은 사용자가 날짜 자동 포맷/자동 링크 소프트웨어의 일부 개선된 버전을 통해 연도를 포함하여 링크된 모든 날짜를 볼 수 있는 옵션이 있기를 바랍니다. 그러나 옵션 2와 같은 것이 기본값이 되어야 한다고 생각합니다. 저는 날짜/생년은 항상 사람과 관련이 있다고 생각하기 때문에 이 옵션과 옵션 1을 실제로 구분하지 않습니다. --Sapphic (talk) 2009년 4월 3일 (UTC)06:16 (답변)
  29. 지지 - 1번보다는 약간(그러나 약간) 선호하며, 이것도 좋은 해결책입니다. Shimgray talk 2009년 4월 3일 (UTC) 15:34 답변[답변]
  30. 지원 -- 출생 연도와 사망 연도는 관련이 있고, 날짜 선호 서식이 링크에서 삭제되면 더 쉬워질 것입니다. -- William Allen Simpson (대화) 2009년 4월 6일 (UTC) 14:30 (답변)
  31. 이미 명시된 이유로 지원합니다. Deb (talk) 2009년 4월 6일 (UTC) 18:00 답변[답변]
  32. 최대한의 사용성을 지원합니다. 또한 위의 사픽의 주장을 도용하겠습니다. ~user:orgjce 223 ☺ 어떻게 입력합니까? 2009년 4월 7일 20:17 (UTC)답장[답장]
  33. 옵션은 설명된 이벤트 유형과 관련이 있으므로 옵션 1과 동일하다고 생각합니다.--4wajzkd02 (talk) 2009년 4월 7일 (UTC)21:21 (답장)
  34. 지원 - 광범위한 지원. '주제와 관련된 사건'의 의미는 해석의 여지가 있지만, 아마도 더 많은 논쟁으로 이어질 것입니다. 지맨
  35. 지원 - 첫 번째 선택, 선택 1 또한 허용됩니다. 출생 연도와 사망 연도는 관련이 있습니다. 히포크라이트 (talk) 2009년 4월 8일 14:14 (UTC)답장[답장]
  36. 서포트. 다시 말하지만, 여기서 문제는 관련성입니다. 그러나 여기서 저는 대신 옵션 2로 결정했습니다. 저는 출생연도와 사망연도에 관한 옵션 1의 부분에 동의하지 않습니다. 누군가 또는 무엇인가의 탄생과 죽음 등은 종종 영향력 있는 시대, 그리고/또는 그러한 시대의 표식으로 사용될 수 있습니다. 를 들어, 필립 C를 아는 것. 존슨은 2005년에 세상을 떠났는데, 그 후의 작품들을 제외하고는, 그 해 이후에 그가 직접적으로 또는 개인적으로 관여하게 될 작품들은 없다는 것을 알게 되었습니다. 왜냐하면 그는 이미 세상을 떠났기 때문입니다. 그 해 이후의 모든 작품들은, 기껏해야 그의 영향을 받지만, 그의 영향을 직접적으로 또는 개인적으로 받지는 않을 것입니다. -A.K.R. (토크) 16:34, 2009년 4월 9일 (UTC)답장[답장]
  37. 지원 월 섹션에서 말씀드린 것처럼, 저는 "관련성"을 자유롭게 정의해야 한다고 생각합니다. 링크가 너무 적은 대신 링크가 너무 많은 것이 좋습니다. 저는 또한 출생 연도와 사망 연도가 항상 관련이 있다고 생각합니다. 캡틴팬더 2009년 4월 11일 17:12 (UTC)답장[답장]
  38. 옵션 #1의 마지막 문장은 허용할 수 없습니다. Titoxd(?!? - cool stuff) 2009년 4월 11일 (UTC) 18:31 답변[답변]
  39. 저는 개인적으로 이 기념일에 대한 소란이 무엇인지 알 수 없지만 지지를 표합니다. 저는 그런 종류의 정보에 대한 많은 요구가 있다는 것을 알게 되었습니다. 아가토클레아 (talk) 2009년 4월 12일 14:47 (UTC)답장[답장]
  40. 지원 생년월일 등은 중요한 정보입니다. 옵션 1도 가능합니다. -- M2Ys4U 2009년 4월 12일 (UTC)응답하라[답변]
  41. 서포트 - 다시 한 번 말씀드리지만 제 순위는 2위, 1위, 4위, 마지막 3위입니다. 중요하고 관련성이 있는 날짜와 연도를 연결해야 합니다. 상관없는 것은 아닙니다. 그것은 저것만큼 간단합니다. 그러나 자동화된 시스템은 이러한 판단을 해서는 안되며, 위반 날짜를 추적하는 "마녀 사냥"도 있어서는 안 됩니다. 날짜 변경 사항이 자연스럽게 진화하도록 합니다. 더 안전합니다. 그렇지 않으면 기사에서 중요한 날짜가 누락될 수 있습니다. --Willscrlt (→""""Talk?!") 2009년 4월 13일 13:25 (UTC)답장[답장]
옵션 #3을 지원합니다(첫 번째 발생 시 모두 링크).
  1. 이것이 다른 모든 것이 연결된 방식입니다. 왜 몇 년이 다르게 취급되어야 하는지 모르겠습니다.-Jeff(talk) 00:11, 2009년 3월 30일 (UTC)답장[답장]
  2. 위와 같이 이렇게 되어야 한다고 생각합니다, 흥미로울 수 있습니다. Dottydot에 의해 추가된 이전 서명되지 않은 의견 (talkcontributes)
  3. 지원 독자들에게 가능한 한 많은 새로운 정보를 찾을 수 있는 기회를 제공하고, 관련성은 주관적이며 부차적입니다. 우노미 (talk) 2009년 3월 31일 (UTC) 16:51 답변[답변]
  4. 든든한 지원군. 연도 링크를 사용하면 특정 날짜에 발생한 일에 대한 개요를 볼 수 있습니다. 이것은 조사를 하는 동안 상대적으로 중요한데, 이것은 특정 시간에 일어난 일, 어떤 사건이 여론에 영향을 미쳤는지 등에 대해 더 많이 알고 싶은 사람들에게 (역사적인) 배경 정보를 추가할 수 있기 때문입니다. 또한 자신과 관련된 것은 다른 사람과 관련이 없을 수도 있습니다. 무엇이 관련이 있는지 또는 무엇이 관련이 없는지 어떻게 결정하시겠습니까? 저에게 이러한 링크는 다른 기능보다 다른 흥미로운 기사를 더 잘 찾고 발견할 수 있는 기회를 제공하기 때문에 관련이 있습니다. 노사망 (talk) 2009년 4월 2일 (UTC) 21:53 답변[답변]
  5. 지원자님, 제가 기사를 읽었을 때, 일반적으로 날짜/연도 링크가 역사적 관점을 얻는 데 도움이 된다는 것을 알았습니다. --Soman (talk) 2009년 4월 5일 (UTC)07:19 (답변)
  6. 강력한 지원. 위에 덧붙여, 세렌디피티가 연구에 유용한 역할을 하기도 합니다.[22]데이트리비아 (talk) 2009년 4월 5일 22:59 (UTC)답장[답장]
I support Option #4 (안내 제거)
  1. 든든한 지원군. 모든 링크는 독자에게 관련성이 있고 도움이 되어야 합니다. 이것들에 대해 우리가 무엇을 더 말할 필요가 있습니까? 칠십계PMandson 2009년 3월 29일 23:32 (UTC)답장[답장]
    • 이것이 날짜 링크가 다른 링크와 같이 취급되도록 하는 유일한 방법입니다. 저는 이 투표에서 이 목표를 제거하기 위한 성공적인 캠페인에도 불구하고, 이 평등이 모든 형태의 언어에 대한 지지를 받고 있다고 봅니다.
    • #3도 의견과 같이 다른 링크에 적용되지 않는 날짜 링크에 대한 제한을 적용하기 위해 읽혔습니다. #1과 #2는 극도의 제거와 스위핑 제거를 정당화하는 데 사용되었습니다.2009년 3월 30일 00:41에 PManderson.
  2. 네, 부탁드립니다. 애초에 이 클러스터를 바보로 만든 사람들의 손에서 가능한 한 많이 빼주세요. 미스터 지맨 2009년 3월 30일 (UTC) 01:19 답변[답변]
  3. 서포트. 몇 년이 너무 많이 연결되었다는 것에 동의합니다. 그러나 옵션 #1은 과도한 반응을 보이고 있습니다. 반면 옵션 #3은 바보같습니다("2009년 3월 30일 검색"에서 인용문 끝에 링크를 만들 사람이 있습니까?). 옵션 #2는 원칙적으로 제정신이지만 세미날이라는 단어는 하이퍼텍스트 연결과 관련된 어떤 것보다도 정자를 더 기억합니다. 중요한 것은, 어떤 일이 일어났을 때의 역사적 맥락이 관련이 있다면 링크를 만들겠다는 것입니다. 1824년에는 "그러나 일반적인 5차 방정식은 라디칼의 관점에서 유리수 위에 공식이 없습니다. 이것은 1824년에 처음 발표된 아벨-루피니 정리로 알려져 있는데, 이 정리는 대수학에서 군론을 처음으로 적용한 것 중 하나였습니다. 1624년에 발표되었을 수도 있고, 1924년에 발표되었을 수도 있습니다. 그리고 그것은 5차 방정식에 대한 요점에 아무런 차이가 없을 것입니다. 하지만 저는 1년에 대한 연결고리가 언제 관련이 있는지 결정하기 위해 사용할 모든 규칙을 말로 표현할 수 없을 것 같습니다. 보면 알아요. 이 문제는 규칙 목록을 맹목적으로 적용하는 것보다 편집자들의 상식에 맡기는 것이 최선입니다. (FWIW, 제가 선호하는 순서는 4-2-3-1입니다.) ---A. di M. (토크) 2009년 3월 30일 (UTC) 09:29 (답변)
  4. 지원 위와 같이 메타데이터 해설 및 옵션 포함. billinghurst (talk) 2009년 3월 30일 (UTC) 10:37 답변[답변]
  5. 지원 MOS는 편집자에게 내용 결정을 지시해서는 안 됩니다. (그리고 실제로 중재 요청/Juk에 따른 스타일 문제까지) 따라서 이러한 언어는 모두 제거되어야 합니다.Lock Coletc 11:05, 2009년 3월 30일 (UTC)답장[답장]
  6. 지원 이것보다 더 많은 것은 과도한 수정을 초래할 것입니다. Wrad (talk) 2009년 3월 30일 17:03 (UTC)답장[답장]
  7. 강력한 지원: 날짜를 클릭하여 다른 이벤트가 발생했는지 확인할 수 있는 것이 매우 유용하고 흥미롭다는 것을 알게 되었습니다. 네, 특정 날짜와 관련된 기사들이 많았는데(역사가 오래된 세계에서 일어나는 일), 그 주장은 무관하다고 생각합니다. 기사에 링크가 너무 많은 것에 대한 이 모든 걱정은 백과사전이 성장함에 따라 서로 링크된 기사가 점점 더 많아질 것이기 때문에 무의미한 걱정입니다. 500만 또는 1000만 건의 기사에 도달하면 기사에 넣을 수 있는 링크 수를 제한하여 주어진 기사에 "너무 많은 링크"를 갖지 않도록 할 것입니까? 그건 그냥 황당해요. 우리는 주요 주제에 대한 많은 기사가 수백, 수천, 그리고 아마도 수만 개의 링크를 가질 것이라는 것을 받아들여야 할 것입니다. 데이트의 경우, 그것들은 아마도 고급에 있을 것이지만, 온라인 백과사전이 성장하면 그렇게 됩니다. 그리고 누군가가 누군가가 제거한 링크를 다시 돌려놓아야 할 것이라는 주장은 터무니 없습니다. 동일한 봇을 다시 실행하고 역방향으로만 실행합니다. 그것들을 모두 제거하는 것보다 더 어렵지는 않을 것입니다. 저는 #1과 #2를 강력하게 반대하고 #3은 너무 자의적이라고 생각합니다. ···日本穣 19:25, 2009년 3월 30일 (UTC)답장[답장]
  8. 서포트. 저는 이 제안들이 소름끼치다고 생각합니다. 이는 기사에서 이탤릭체 텍스트를 사용할 때나 글에서 총알 포인트를 사용해야 할 때보다 훨씬 더 많습니다. 이것은 웹의 기본적인 인프라인 링크와 위키피디아의 기사들 간의 연결에 관한 것입니다. 특정 날짜 기사에 링크가 필요한지 아닌지는 중요하지 않습니다. 그런 포괄적인 가이드라인은 무리가 있고 사안별로 처리하는 것이 좋을 것 같습니다. --Bill 20:41, 2009년 3월 30일 (UTC)답변서[답변서]
  9. 저는 또한 위의 Gavia Immer의 코멘트에 대한 옵션 2.1000%를 지지합니다. AKAF (talk) 2009년 3월 30일 07:05 (UTC)답장[답장]
  10. 지원 편집자가 관련 없는 것과 그렇지 않은 것을 통제할 수 있도록 합니다. 봇들은 현재 상태로 충분히 합니다. Ched ~ ©/ 2009년 3월 30일 (UTC)21:28 (답변)
  11. 지원 링크를 사용하는 시기에 대해 정확히 하나의 규칙이 필요합니다. 날짜는 특별하지 않습니다. 링크를 클릭하면 제가 읽고 있는 내용의 맥락에서 유용한 정보를 기대합니다. 유사한 이벤트 시간에 링크하는 목적을 달성하기 위해 날짜가 지정된 카테고리를 사용합니다. --NrDg 00:11, 2009년 3월 31일 (UTC)답장[답장]
  12. 지원 많은 날짜는 상관없이 연결이 필요합니다. 인포박스는 날짜가 강조 표시될 때 훨씬 더 멋져 보입니다. 그래서 저는 4번을 지지합니다. Daniel Benfield (talk) 2009년 3월 31일 01:22 (UTC)답장[답장]
  13. 지지해줘요 그냥 상관없으니까 사람들이 원하는 대로 하게 해줘요. hulmem (talk) 2009년 3월 31일 03:19 (UTC)답장[답장]
  14. 지원은 피먼더슨에 따라 옵션 2에서 전환됩니다. sure.dm (talk) 2009년 3월 31일 06:06 (UTC)응답하라[답변]
  15. 서포트. 옵션 2에서도 전환되었습니다. 날짜 링크는 특별하지 않습니다.육각형(!❞) 2009년 3월 31일 11:49 (UTC)답장[답장]
  16. 모든 가이드의 서포트 제거(옵션 1부터 변경). 이 호 전체는 WP:CREEPWP:의 냄새가 납니다.바이크셰드. 편집자는 스스로 결정할 수 있습니다. 저는 항상 옵션 #1의 논리를 선택하고 싶지만, 이것이 그것에 대한 서면 가이드라인을 갖는 것을 정당화한다고 생각하지 않습니다. 찻주전자의 이 모든 폭풍은 사람들이 뜨거워지는 것을 연상시키고 사용하기에 올바른 대시에 대해 신경 쓰입니다. 우리가 WP를 강타했을 때:마감일, 프린터로 보내기 전에 작은 것들을 정리할 수 있습니다. SDY (talk) 2009년 3월 31일 15:35 (UTC)답장[답장]
  17. 든든한 지원군. 그런 쓸모없는 해군 방공호들을 없애버리자구요. Physchim62 (talk) 2009년 3월 31일 19:11 (UTC)답장[답장]
  18. 강력한 지원 규칙 수 감소= good J04n (talk page) 2009년 4월 1일 01:22 (UTC)답장[답장]
  19. BAM! 그 남자는 너무 많은 힘을 가지고 있습니다.Twas Now (talk contributes e-mail ) 2009년 4월 1일 09:23 (UTC)답장[답장]
  20. 강력한 지지를 보내드립니다. J04n의 규칙이 적어진다는 말에 정말 동의합니다.= 좋습니다. 위키백과가 많은 기여자들에 의해 편집되었고, 적절성에 대한 다양한 생각을 가지고 있는 상황에서 프로크루스테안 솔루션 하나를 부과하는 것은 어리석은 일입니다. -- BRG (토크) 2009년 4월 1일 (UTC) 14:42 (답변)
  21. 지원 편집자가 기사나 프로젝트 수준에서 적절한 구현을 결정할 수 있습니다. 내용 토론은 MOS의 소관이 아닙니다. --guyzero talk 2009년 4월 1일 (UTC)응답하라[답변]
  22. 지원 편집자는 현재 기사의 주제를 더 잘 이해하기 위해 독자들에게 해당 연도에 발생한 사건에 대한 배경 정보를 제공하기 위해 특히 중요한 연도를 연결할 수 있어야 합니다. 옵션 1은 이를 허용하지 않는 것으로 보입니다. 옵션 2는 한 사람의 삶에서 발생하는 사건에 대해 이야기할 때 가장 관련성이 낮은 출생일과 사망일에 초점을 맞추고 옵션 3은 연도 연결의 가치를 희석시킵니다. 이것은 저에게 옵션 4만 남았습니다. Axel Boldt (talk) 2009년 4월 2일 03:07 (UTC)답장[답장]
  23. 서포트. 저는 항상 이 문제를 개인의 선호도 선택으로 간주해 왔습니다. 여기는 크리프가 너무 많아요. bibiomaniac 15 2009년 4월 4일 (UTC)응답하라[답변]
  24. 서포트. 이미 충분한 지침이 있습니다. --catslash (talk) 2009년 4월 4일 (UTC) 23:57 답변[답변]
  25. 지원 - 어떤 대안보다 나은 것 같습니다. 구두장이의 휴일 (talk) 2009년 4월 5일 06:10 (UTC)답장[답장]
  26. 서포트. 하지만 예전에는 모든 날짜를 연결하는 스타일이었고, 지금도 많은 기사가 이렇게 하고 있지만, 이제는 일반적인 규칙을 따라야만 몇 년이 연결됩니다. JonH (talk) 2009년 4월 5일 (UTC) 09:09 답변[답변]
  27. 서포트. reg의 비용은 0이 아닙니다. --Thomas B ♘talk 17:01, 2009년 4월 5일 (UTC)답변[답변]
  28. 강력한 지원 변화해야 할 이유가 없다면, 왜 새로운 규칙을 만들까요? Phil_burnstein (talk) 2009년 4월 6일 09:55 (UTC)답장[답장]
  29. 서포트. 불필요한 정책은 모두 사라져야 합니다. --Pgallert (talk) 2009년 4월 7일 (UTC)10:05 답변[답변]
  30. 서포트. 내가 데이트할 때 댓글을 맞추는 거. 결정은 편집자에게 맡깁니다. 일관성을 얻고 싶다면 이런 성가신 자원봉사 편집자들을 모두 제거하고 모든 결정을 내리고 모든 규칙을 따르는 소수의 임명된 편집자 그룹을 두는 것이 가장 좋습니다. 누구나 편집할 수 있는 무료 형식을 계속하려면 무료 형식도 사용해야 합니다. 저는 수백만 개의 각주보다 파란 고리의 바다에 훨씬 덜 산만합니다. Fijagdh (talk) 2009년 4월 8일 (UTC) 21:38 답변[답변]
  31. 저는 옵션 3으로 거의 갈 것 같은데, 기사에서 1년 링크가 두 번 이상 관련이 있다면 두 번 링크하는 것이 좋을 것입니다. 월/일은 그렇지 않습니다. 따라서 이 옵션이 권장될 가능성이 가장 높은 방법이라고 생각하기 때문에 이 옵션을 지지합니다.Simplebut powerful 00:22, 2009년 4월 9일 (UTC)답장[답장]
  32. 에서 Guyzero가 표현한 바와 같이 "편집자가 기사나 프로젝트 수준에서 적절한 구현을 결정할 수 있도록 합니다. 내용 토론은 MOS의 소관이 아닙니다." Thanks, Lini (talk) 2009년 4월 9일 (UTC) 01:05 (답변)
  33. 지원 저는 이러한 링크의 필요성을 전혀 이해하지 못했습니다. --Auntof6 (talk) 2009년 4월 11일 (UTC)07:20 (답장)
  34. 지원 날짜 페이지는 이러한 기사에 아무런 영향을 미치지 않으며, 어수선한 내용을 끝내고 모든 기사를 제거합니다. 검색창에 입력하면 찾을 수 있습니다. - .Logan't : 2009년 4월 11일 11:21 (UTC)응답하라[답변]
  35. MOSNUM 또는 MOSLINK에서 "링크 가이드라인과 관련하여 다른 단어나 용어와 다르게 취급되지 않음"을 명시적으로 명시하는 문구를 사용하여 지원할 수 있습니다. 과거에 과도하게 날짜를 연결하는 것에 익숙했던 사용자들에게는 예전 가이드라인에서 말한 것처럼 더 명확해질 수 있습니다. --Jayron32.talk.contributes 2009년 4월 12일 (UTC) 15:00 (답변)
  36. 서포트. 날짜는 특별하지 않습니다. 하지만, 제이런 32세가 목격한 바와 같이, 이 사건의 역사를 고려할 때, "특별하지 않다"고 명시적으로 말하는 (집주인) 문장이 좋은 생각일 수도 있습니다. -- 2009년 4월 13일 (UTC) 12:15 (답변) 전체 중지 (대화)
  37. 지원: 연도 링크가 관련성이 높은 경우가 있으며, 단지 주의를 산만하게 하는 경우가 많지만, 특정 기사의 편집자가 해당 주제와 관련된 문제를 기준으로 주장해야 합니다. 그러나 링크별 자동 서식을 제거하면 더 이상 링크의 이유가 아님을 매뉴얼에 표시하는 것이 매우 유용합니다. 스타일 매뉴얼의 모든 스타일 지침은 결국 통일성을 지향하는 많은 편집자들의 눈에, 보편적이고 절대적인 의무가 되기 때문에, 유용하고 비의무적인 힌트와 다른 기사들과의 비교를 제공하기 위한 제안 모음과 같은 것이 있어야 합니다. (보통 거의 알려지지 않은) 성미가 나쁘고, 신비롭고, 괴물 같은 거대한 토론 후에, 그것은 곧 위키백과의 불경스러운 눈에 묻히게 됩니다. MOS 또는 위키백과 대화: MOSNUM 아카이브 23번 또는 37번. ---- Shakescene (토크) 2009년 4월 13일 (UTC) 20:41, 답변[답변]
기타의견
  • 옵션 1만으로 각 기사에 '파란의 바다'가 존재하지 않을 것이라는 확신이 있을 것입니다. 오공자(talk) 2009년 3월 29일 (UTC) 23:27 답변[답변]
    • 저는 옵션 4 또는 옵션 2 하에서 많은 기사들이 ("리스트" 유형의 기사를 제외하고) 연도에 대한 링크가 6십 개 이상일 것이라고 생각하지 않습니다. 그리고 단락에서 연도에 대한 링크가 하나 또는 두 개가 어떻게 하버드 인용의 이 예보다 훨씬 더 나쁘다는 것입니다( 파란색으로 표시된 AD 연도를 나타내는 네 자리 숫자도...).)는 제가 이해할 수 있는 능력 밖의 것입니다. 적어도, "라자레 폰티첼리"라는 글은 하버드 인용의 "아일랜드 음운론" 부분과는 달리, 출생 연도가 연결되어 있어도 쉽게 읽을 수 있습니다. --A. di M. (talk) 2009년 4월 3일 (UTC) 15:02 (답변)
  • 옵션 2와 옵션 4 모두 약간만 허용 가능한 형태라고 생각하지만, 그 의미를 결정하기 위해서는 추가적인 해석이 필요합니다. 또한 옵션 1은 제목이 잘못 지정되어 있으므로 "(현재) 관련 연도 기사에만 링크"라고 읽어야 합니다. 옵션 1에서 옵션 3까지의 스펙트럼에 "관련 연도에 대한 링크"가 표시되는 경우에도 논의의 대상이 될 것입니다. (이 모든 제안은 WP를 명시적으로 수정합니다.오버링크WP:MOSLINK, 그래서 WP를 언급하는 코멘트:OVERLINK는 무관할 수 있습니다.) — Arthur Rubin (talk) 2009년 3월 29일 (UTC) 23:54 (답변)
  • WP에 따라 제 말을 믿으셔도 됩니다.위의 OVERLINK" 코멘트는 제가 이 가이드라인의 현재 합의된 버전을 지지하며, 당사의 기사 전체에 가치가 없는 링크를 무작위로 추가하여 사용자에게 이익보다 훨씬 더 큰 피해를 입히는 희석 효과를 생각한다는 것을 의미합니다. 따라서 저는 기사가 확실히 있는 연도에 가치가 낮은 링크를 추가하는 것에 반대하는 지침을 유지하는 것에 찬성합니다. --John (talk) 2009년 3월 30일 (UTC) 00:01 (답변)
  • 제가 월/일 질문에서 말한 것을 반복하자면, 유권자들에게 한 가지 선택지를 정확히 선택하도록 요구하는 것은 잘못된 것입니다. 합리적인 사람은 일반적으로 허용 가능한 두 가지 옵션, 그리고 최소한 한 가지 옵션은 허용 불가능한 것을 발견할 수 있습니다. 이 형식은 기본적으로 유권자가 선호하는 옵션 중 하나를 무작위로 선택하고 동일한 속성을 가진 모든 사람이 중간을 분할하는 것이 아니라 정확히 동일한 방식으로 선택하기를 희망하도록 요구합니다. 각 선택에 대해 허용/허용 불가 투표를 하는 것이 훨씬 더 나을 것입니다. Gavia immer (talk) 2009년 3월 30일 06:19 (UTC)답장[답장]
    • 저는 이것을 여러 가지 선택이 가능한 질문자로 만드는 것이 결과를 해석하는 것을 매우 어렵게 만들 것이라고 생각합니다. 또한, 사람들이 이상적으로 그들의 투표에 무게를 두어야 한다는 비판이 열릴 것입니다. 이렇게 되면 과정이 분명히 매우 복잡해질 것입니다. 여론조사입니다. 거기서 한 가지 선택만 해야 한다고 생각합니다(민주주의 국가에서의 투표처럼). 여론조사가 충분히 잘 설계되었는지는 또 다른 문제이지만, 그것은 길고 몹시 가열된 과정의 결과라는 점에 주목하세요. 그래서 여론조사가 서로에 대해 상당히 무례하게 행동할 수 있는 정당들에 의해 고안되었다는 사실은 매우 주목할 만합니다. --HJensen, talk 09:22, 2009년 3월 30일 (UTC)답변[답변]
  • 사람들이 어떻게 어떤 일을 하기 위해 어떤 식으로든 연도 연결을 사용했는지 궁금합니다. 그것들이 당신에게 유용했습니까? 어떻게 지내셨어요? <<"site:wikipedia.en"에서 수년간 구글 검색하기>는 특별히 편리한 방법이라고 생각하지 않습니다. -- 사용자:Document
  • 1345년, 1346년, 1347년의 몇몇 연도의 기사들이 어떻게 개선되었는지에 대한 예들을 모두들 살펴보시기 바랍니다. 1929년은 현재 개선 중입니다. Wrad (talk) 2009년 3월 30일 15:06 (UTC)답장[답장]
  • 제 인생에서 한 해가 연결되지 않은 이유를 알 수 없는 경우를 발견했습니다. 여름이 없는 해. (그 해의 사건 목록은 독자들에게 이해할 만한 관심사일 것입니다. 호기심 많은 사람은 전 세계적으로 대규모의 농작물 실패에 직면했을 때 어떻게 삶이 지속되었는지 알고 싶어할 것입니다.) 연도 연결에 대한 위의 모든 주장이 소용 없음에도 불구하고, 제가 이해할 수 있는 유일한 이유는 예외 없이 연도 연결을 금지했기 때문입니다. -- llywrch (talk) 2009년 3월 30일 (UTC) 16:34 (답변)
    • 1816년을 보면 앞서 언급한 농작물 실패와 관련된 정보는 단 한 건도 없습니다. 그 링크는 추가되지 않았어야 합니다. Dabomb87 (talk) 2009년 3월 31일 02:25 (UTC)답장[답장]
        • 제가 위에서 말했듯이, "궁금한 사람은 누구나 전 세계적으로 대규모의 농작물 실패에 직면했을 때 어떻게 삶이 지속되었는지 알고 싶어할 것입니다." 그 경우, 1816년에 일어난 모든 일들이 관련이 있습니다. 그리고 활동의 수와 종류가 눈에 띄게 변하지 않았다면, 그것도 관련이 있습니다. 비슷한 상황이 '다이즈 더 파이어'에서 묘사된 것처럼 세상의 종말이 아니라 고난으로 판명되었습니다. -- llywrch (talk) 2009년 3월 31일 (UTC)응답하라[답변]
      • 제대로 된 한 해를 보낸 게 맞습니까? 여름이 없는 해가 머리말에 있습니다; 탐보라는 사건 목록의 첫 번째 항목입니다; 적어도 두 개의 다른 항목은 틀림없이 기근의 산물입니다. 칠십계PManderson 2009년 3월 31일 04:02 (UTC)답장[답장]
        • 여름 기사가 없는 에 이미 존재하는 두 가지 사실과 관련이 있을 수 있는 두 가지 사실(어떤 것을 말씀하시는지조차 알 수 없지만). 그것이 누군가의 이해를 어떻게 도울 수 있을까요? 식민지 크리스 (talk) 2009년 3월 31일 09:49 (UTC)답장[답장]
    • 이것이 제가 옵션 4를 선택한 이유입니다. 옵션 1은 연도 연결에 대해 과도한 반응을 보일 가능성이 너무 높다고 생각합니다. 다른 링크와 같은 방식으로 한 해 링크를 치료하세요! 어쨌든 그것이 옵션 1의 핵심입니다! Wrad (talk) 2009년 3월 30일 17:04 (UTC)답장[답장]
    • 그 기사에서 "여름"도 링크가 끊겼습니다. -- 사용자:문서
      • 연결하면 무슨 의미가 있을까요? 기사를 읽는 사람들은 '여름'이 무엇을 의미하는지 모를 것 같습니까? 식민지 크리스 (talk) 2009년 3월 31일 09:49 (UTC)답장[답장]
        • 제 생각에 독자 분은 독자 분이 알고 있는 어떤 것에 대해 불분명하고, 사실을 정확히 이해하기 위해 도움이 되는 자극제가 필요한 가끔의 (그리고 당혹스러운) 기억 상실을 경험할 만큼 나이가 되지 않은 것 같습니다. 독자들이 여름이 일년 중 가장 따뜻한 계절이라는 것을 모를 정도는 아니지만, 남반구의 여름은 북반구와 다른 달이라는 것을 (예를 들어) 잊어버릴지도 모릅니다; 오레곤 주 포틀랜드의 7월은 뉴질랜드 오클랜드의 7월보다 훨씬 따뜻합니다. - llywrch (talk) 17:16, 2009년 3월 31일 (UTC)답장[답장]
        • 눈치 채지 못하셨다면, "summer"라는 글에는 "summer"가 의미하는 바" 이상의 정보가 포함되어 있습니다. --A. di M. (구 Army 1987) -- 아닌 행동. 2009년 4월 4일 (UTC)12:38 (UTC)답변[답변]
  • 제안된 텍스트가 실제로 "관련성이 있을 때만 링크"라고 말하는 것이 아니라 "관련성이 있을 때만 링크하고, X와 Y는 관련이 없습니다"라고 말하기 때문에 옵션 1은 잘못된 제목입니다. 출생 연도와 사망 연도 같은 것들을 연결하지 않는 것에 대해 덜 독단적이라면 옵션 1을 지지할 것입니다. Gareth McCaughan (talk) 2009년 3월 30일 21:40 (UTC)응답하라[응답하라]
    • 좋은 지적이야. 저는 1번 옵션에 투표하는 사람들 중 출생/사망 날짜가 관련된 연결고리라고 암묵적으로 가정하는 사람들이 얼마나 되는지 궁금합니다. 이 문제에 대한 또 다른 여론조사가 필요하다는 Wrad의 의견이 맞는 것 같습니다. -- llywrch (talk) 2009년 4월 2일 (UTC) 18:15 (답변)

저는 다음 남자보다 오버링크를 더 좋아하지는 않지만, 옵션 4가 편집자들의 과민 반응을 이끌 것이라고 정말 생각합니다. 우리는 모든 연도 링크를 죽이고 싶지 않습니다. 만약 여러분이 X, Y, 또는 Z 상황에서만 링크할 수 있다는 연도 링크에 대한 특별한 지침을 가지고 있다면, 사람들은 "연도 링크에 특별한 섹션이 있다면, 그것은 다른 어떤 링크보다 더 엄격하게 판단해야 한다는 것을 의미합니다."라고 생각할 것입니다. 첫 번째 제안을 지지하는 대부분의 사람들이 그것을 지지하려고 하는 것은 아니라고 생각합니다. 저는 옵션을 훨씬 선호합니다. 연도 링크는 다른 모든 링크가 준수하는 규칙의 동일한 덩어리로 조용히 미끄러져 들어가야 합니다. 만약 우리가 과잉반응을 한다면, 몇 달 후에, 몇 번의 편집 전쟁 후에, 또 다른 여론조사를 할 것입니다. Wrad (talk) 2009년 3월 30일 17:11 (UTC)답장[답장]

  • 제가 4번에서 보는 유일한 문제는 1년이 언제 관련이 있는지에 대한 의견 차이가 있는 것 같습니다. 어떤 사람들은 출생/사망 연도가 관련이 있다고 생각하지만, 많은 사람들은 그렇지 않습니다. 어떤 사람들은 기사 주제가 연도 기사에 나열되어 있으면 연도 링크가 관련이 있다고 생각합니다. 다른 사람들은 그렇지 않습니다. 약간의 지침이 없다면, 우리는 계속해서 편집상의 논쟁과 대화 페이지로 인해 모든 사람들의 시간을 낭비하게 될 가능성이 높습니다. Karanacs (talk) 2009년 3월 30일 17:12 (UTC)답장[답장]
    • 그렇다면, 저는 우리가 편집이 이 모든 옵션과 충돌하는 것을 보게 될 운명인 것처럼 보입니다. 그리고 우리는 또한 가까운 미래에 이 여론조사를 다시 할 운명입니다. Wrad (talk) 2009년 3월 30일 17:37 (UTC)답장[답장]
  • 저는 어떤 연도 링크에도 반대하지만 여론 조사에는 그러한 옵션이 없습니다. Loosmark (talk) 04:42, 2009년 4월 1일 (UTC)답장[답장]
  • 옵션 0의 삽입 가능성이 대화 페이지로 이동했습니다. 이 단계에서 해당 옵션을 추가해야 하는지 여부에 대해 논의하십시오. Karanacs (talk) 2009년 4월 1일 19:24 (UTC)답장[답장]
카라낙스: 당신은 먼저 제 투표를 다른 옵션으로 변경했습니다. 그리고 나서 당신이 내 투표를 삭제했다고 되돌렸을 때. 당신은 내 투표를 삭제하지 않습니다. 여기 또 있습니다. 그리고 감히 삭제하거나 변경하거나 이동하지 마십시오.
옵션 #0을 지원합니다(년을 연결하지 않음).
1: 지원 - 연도 번호를 전혀 연결하지 않는 것을 선호합니다. 한 해를 연결하고 싶다면 연결이 무엇인지 더 명확하게 말해주는 적절한 연결을 수행합니다.
--David Göthberg (talk) 2009년 4월 1일 (UTC) 19:45 답변[답변]
  • 평문 자동 구문 분석 기능이 있는 자동 형식 기능을 지원합니다. 날짜는 2009-04-02와 같이 입력됩니다(괄호, 함수, 형식 문자열 없음). myyy-mm-ddd의 모든 것은 명시적으로 탈출하지 않는 한 날짜로 해석됩니다. 선호도 또는 환경 변수에 따라 특정 형식이 적용됩니다. -Woodstone (talk) 2009년 4월 2일 (UTC) 11:41 답변[답변]
  • 기사 편집자들의 손에 맡기려면 재량이 허용될 필요가 있다고 생각합니다. 하지만 저는 자동 구문 분석 옵션을 사용하고 편집자가 날짜를 링크하고 싶다면 날짜를 링크 상자에 넣는 것에 대한 우드스톤의 의견에 동의합니다. awb(또는 이와 유사한 것)를 사용하여 다른 경험이 있는 편집자가 입력한 날짜를 변경하려면 덤프를 주기적으로 당겨야 합니다. 하지만 기본적으로 데이트는 기사의 첫 번째 경우에만 필요하며, 기사를 더 잘 이해할 수 있고 링크가 있는 기사가 해당 날짜의 자체 기사에 언급된 경우에만 필요하다고 생각합니다(: "12월 25일은 크리스마스를 기념하기 위해 사용되는 날이고, 예수 그리스도탄생을 경축하는 것으로, 이 세 가지 글이 서로 교차하여 언급되는 것입니다. 날짜 기사에 그러한 언급이 없지만 다른 날짜 지향 기사에 해당 항목이 있다면("U22000년 1월 1일 앨범을 발매했습니다.")라고 인정하는 것이 적절할 것입니다. 2000년 음악 참조."). --rm 'wavu 10:56, 2009년 4월 3일 (UTC)답장[답장]
  • 옵션 1이 정말 해결되는 것이 있습니까? 제가 보기에 '그들의 내용이 주제에 대해 세균적이고 주제적이지 않는 한 연결되어서는 안 된다'는 것은 우리의 현재 '정책'만큼 해석에 대해 폭넓게 열려 있으며 아마도 더 많은 편집 전쟁으로 이어질 것입니다. 지맨? 2009년 4월 7일 (UTC) 23:13 답변[답변]
    • 그러니까. 옵션 1은 폭발적인 것을 바꾸지 않습니다. 옵션 4는 말이 되는 유일한 것입니다. Wrad (talk) 2009년 4월 10일 (UTC) 06:02 답변[답변]

위의 논의는 종료되었습니다. 수정하지 말아주세요. 후속 의견은 해당 토론 페이지에서 작성해야 합니다. 이 토론에 대해 더 이상 편집해서는 안 됩니다.