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

제안:새 문서 작성 제한/자동 확인 변경

나는 BS 허영심/공격/논센스/논문 페이지의 미친 흐름을 줄이려는 생각이 들었다.그것은 두 갈래로 접근하는 것이다.

1) Autoconfirm 임계값을 10일/100일 편집으로 올린다.2) WP를 통해 비자동확증 사용자에 의한 페이지 작성 요구:WAVERS 또는 그와 동등한 것 중 하나(더 나은 것이 있는데 내가 링크를 잘못 표시했다).

여기에는 다음과 같은 이점이 많다.

• 즉시 Gr*wP 스타일의 Get-ten-edits-en-to-on-WP 페이지 이동 반달리즘을 줄인다. 그것과 관련된 사람, 또는 /b/는 단지 물건에 똥을 싸기 위해 100개의 생산적인 편집에 골머리를 앓을지 의심스럽다.그들이 그렇게 한다고 해도, 그것은 그 프로젝트에 대한 순이익이다.
• 손에 너무 많은 시간을 가진 사람들이 차를 몰고 다니며 인스타 덤프 페이지를 만드는 것을 줄이는데 도움이 될 것이다; 몇 개의 필드를 채우는 2-3분은 캐주얼 두피에 들어가는 데 충분한 장벽이라고 생각한다.전기 충격에 못 미치는 일에도 불구하고 덜 바쁜 사람들은 만류하지 않을 것이다. 그래서 우리는 거기서 일종의 솔(SOL)을 하고 있다.
• IP에 대한 CAPTCHA보다 진입 장벽을 훨씬 더 많이 제공하지 않는다.
• 새로운 사용자를 MOS, 포맷 등의 기초에서 교육할 수 있도록 지원

생각?[ rox ] [x] 05:37, 2008년 10월 26일 (UTC)[응답]

나는 오토콘펌 문턱을 높인다는 생각에 절대 반대한다.몇 달 전에 4일에서 10일 수정으로 늘렸어.나는 그 당시에 새로운 사용자들이 기사를 작성할 수 있는 능력을 갖기 전에 편집 요건에 의해 쫓겨나는 것에 대한 약간의 우려가 있었던 것을 기억한다.요구 사항을 100 편집으로 올리면 IMO는 너무 많은 잠재적 사용자를 수용할 수 없게 만들 것이다.그러나 나는 임계값이 4일/10일/삭제되지 않은/반복되지 않은 편집을 선호한다.그러한 사소한 변화는 백과사전에 긍정적인 기여를 하는 사용자들에게 영향을 주지 않을 것이고, 반달들이 페이지를 옮기는 능력을 얻는 것을 더 어렵게 만들 것이다.그러나 이를 위해서는 소프트웨어의 변경이 필요할 수 있다.

WP와 같은 것을 통해 새로운 페이지를 실행하도록 요구하는 한:WAGER, 나는 그것이 새로운 사용자들을 쫓아낼 수 있는 잠재력을 가지고 있다고 생각한다.편집 영역에서 MOS에 더 눈에 띄는 링크를 만들 것을 제안한다(특히 더 경험이 많은 사용자를 위해 해당 알림을 끄는 기능으로). -- 임페라이터3733 (대화) 06:28, 2008년 10월 26일 (UTC)[응답]

나는 그러한 높은 오토콘펌 한계에는 강력하게 반대하지만, 어떤 종류의 제한, 어쩌면 세 번의 편집만으로 시간 요구사항이 없는 것을 강력히 지지한다.하지만 이것은 심각하다.나는 새로운 기사들 중 60%가 처음이자 유일한 편집물로 사용자들에 의해 만들어지고 있고, 그 중 90%는 스팸, 공격, 비협조, 비통보 및/또는 OR이 되는 것에 신물이 난다.새로운 기사를 만들려면 더 높은 한계가 있어야 하고, 그것이 제안된 것만큼 클 필요는 없지만, 뭔가 있을 것이다.레이와스92^Talk 15:39, 2008년 10월 26일 (UTC)[응답]

오토콘펌프 한도가 3개만 편집하면 된다고 생각한다는 말씀이세요?만약 그렇다면, 그것은 한도를 올리고자 하는 당신의 의견과 상충되는 현재 한도보다 낮을 것이다.아직 모르는 경우, 새로운 페이지를 작성하거나 페이지를 이동하거나 반보호된 페이지를 편집하려면 사용자가 자동확증(현재 4일/10일 편집)해야 한다. -- 임페라이터3733(토크) 17:29, 2008년 10월 26일(UTC)[응답]

아니, 현재 오토콘은 그대로 있어야 해.나는 그 제안이 실제로 완전히 다른 두 제안이라는 것을 잘 깨닫지 못했다.1) 나는 반대한다. 보호된 페이지 등을 편집하는 현재의 오토콘펌프는 괜찮다.2) 나도 반대한다. 왜냐하면 우리는 이미 경험에 의해 강제 마법사가 항상 작동하지 않는다는 것을 알고 있기 때문이다. 비록 선택적인 마법사는 가능하지만 말이다.나는 기사 작성에만 적용되는 두 번째 오토콘 회사를 지지한다.길지 않아도 되지만, WP에서 어떤 일을 어떻게 해야 할지 제로인 등록된 사용자가 우리 나머지가 다뤄야 할 기사를 만들 수 있도록 허용하는 것 이상의 것이 있어야 한다.레이와스92^Talk 18:02, 2008년 10월 26일 (UTC)[응답]

나는 그 생각을 지지한다.100 편집은 무리일 수 있지만 20-50 편집 같은 것이 좋다.또한 새로운 사용자가 30분 이내에 한 페이지에 10개 이상의 편집을 하지 못하도록 하는 메커니즘이 있어야 한다.이것은 그것이 페이지를 바꾸기 때문에 자동 확증 요건을 달성하려고 노력하는 반달 계정인지 완전히 명백하게 만들 것이다.새로운 일련의 경고 메시지가 개발될 수 있고, 이것은 차단 가능한 공격일 수 있다.결과는 페이지 이동 반달리즘과 더 나은 기사가 될 것이다. --Pwnage8 (대화) 23:49, 2008년 10월 26일 (UTC)[응답]

5월에는 오토콘펌 문턱을 높이는 것에 대해 폭넓은 논의가 있었다.그 결과 4일/0 편집에서 4일/10 편집으로 변경되었으며, 편집자의 과반수(그러나 대략적인 합의를 위해서는 충분하지 않음)가 7일/20 편집에 찬성하였다.따라서 10일/100일 편집은 절대적으로 비주류적인 것이므로 제안서의 그 부분은 삭제하십시오.

자동 확증되지 않은 편집자가 메인 스페이스/아티클스페이스에 새 페이지를 작성할 수 있어야 하는지에 대해서는, 데이터를 가지고 있는 것이 정말로 도움이 될 것이다.예를 들어, 특정 날짜에 작성된 x,000개의 새로운 기사 중에서, 자동 확증되지 않은 편집자가 생성하는 비율은 몇 퍼센트인가, 그리고 그 중 몇 퍼센트가 삭제되거나 기존 기사로의 리디렉션으로 전환되는가(예: (예:) 일주일 내에?

마지막으로, 관리자가 모든 페이지 이동(확실히 원하지 않는)을 하도록 요구하는 것 외에, 이동 반달리즘을 절대적으로 방지할 수 있는 어떤 요구사항도 생각해 내는 것은 불가능하다.자동 확증 임계값을 증가시키는 목적은 단순히 반달인이 새로운 계정을 얻어 확증 상태를 자동화하는 데 더 많은 비용이 들도록 하고, 반달리즘을 행하는 계정이 오직 그 목적으로만 만들어졌다는 것을 더 명확하게 하는 것이었다.다른 많은 편집자들이 지적했듯이, 편집자들이 어떤 일을 할 자격을 갖기 어렵게 만드는 것은 공공 기물을 파괴하는 것을 감소시키지만, 비용은 훌륭한 편집자들이 유용한 일을 할 수 없고(적어도 당분간은), 단순히 편집을 중단할 정도로 충분히 낙담할 수 있다는 것이다.요컨대, 비용-효익 트레이드오프가 있다; 가장 많은 이익이 비용을 초과하는 지점을 찾는 것이 목표다. -- John Brown은 2008년 10월 27일 (UTC)[응답]

나는 비용-효익의 절충을 알고 있다.나는 그것이 순이익이 될 것이라고 생각하기 때문에 오토콘 확증 요건을 높이는 아이디어를 지지한다.이 백과사전에 기고하는 데 관심이 있는 편집자들은 그것들을 얻을 수 있을 만큼 충분히 오래 머물 것이고, 그들의 편집 패턴을 통해 반달계정이 유출될 것이다.만약 누군가가 자신이나 그들이 좋아하는 악단에 대한 기사를 만드는 유일한 목적으로 새로운 계정을 만든다면, 아마도 낙담하는 것이 방법일 것이다! --Pwnage8 (토크) 16:44, 2008년 10월 27일 (UTC)[응답]

나는 첫 번째 새 페이지에 대한 x 비반복 편집 규칙과 마법사를 지지한다.It Is Me Here (토크) 2008년 10월 27일 (UTC) 14:25[응답]

제안서 2에만 해당 - 후자를 시도해 볼 수 있다.우리가 Special:에서 밀린 업무량을 줄일 수 있다는 것은 다행스러운 일이다.새 페이지.가끔 수십 명이 필요한 직업을 위해 그곳에 있는 우리 중 몇 명만 있는 것 같다.나는 3/4페이지가 절대 순찰되지 않을 것으로 예상한다.3분의 1만 줄여도 좋을 것 같아.핵전쟁료 02:52, 2008년 10월 28일 (UTC)[응답]

맙소사, 안돼.오토콘펌은 이미 거의 권력에 가까운 요구 사항을 가지고 있다; 현 시점과 더 높은 수준의 요구 사항들은 합법적인 사용자들을 쫓아낼 뿐이다.지난번 오토콘확인을 위한 토론에서 말했듯이, 펄/루비/피톤에 문법 봇을 쓰고 이런 종류의 한계가 중요하지 않을 정도로 높은 비율로 사소한 수정을 하도록 하는 것은 사소한 일이다.그들이 하는 일이라곤 왜 의미 있게 기고할 만큼 '잘못된'지 이해하지 못하는 새 편집자들에게 상처를 주는 것뿐이다(즉, 점점 증가하는 기사의 일부분인 반보호 기사를 편집하고, 일반적으로 가장 관심을 끄는 기사이기도 하다).셀라노르 18:58, 2008년 11월 1일 (UTC)[응답]

최악의 반달리즘은 페이지 이동이기 때문에 이동 제한을 두 번째 자동 확인에 더 오래 두고 나중에 말이 되겠지만, 대부분의 신입 사원들은 페이지를 이동하지 않기 때문에, 특히 이동 탭이 숨겨져 있거나 WP:요청된 이동에 연결되어 있다면, 아무도 겁을 주지 않을 것이다. --Nate1481 15:26, 2008년 11월 6일 (UTC) 응답하라.

왼쪽 사이드바에 Wiktionary 링크 추가

모든 위키백과 페이지의 왼쪽 사이드바에 우리 자매 프로젝트 위키트리노리에 링크를 추가하자고 제안하고 싶다.현재 위키트리노에 대한 유일한 링크는 메인 페이지 하단에 있다.위키피디아는 풍부한 어휘를 사용한다.파란색으로 연결되지 않은 낯선 용어들을 더 쉽게 찾을 수 있게 하는 것은 우리의 독자들에게 도움이 될 것이다.나는 도구 상자에 Wiktionary를 추가하는 것을 제안할 것이다.탐색 영역도 적절할 수 있지만, 거기에 선을 추가하면 검색 상자가 더 낮게 이동하게 되고, 그것은 우리의 전체적인 모습에 너무 큰 변화가 될 수 있다.다른 자매 프로젝트에 연결하지 않고 위키트리노에 링크를 추가하는 것에 의문을 제기할 수 있는 사람들에게, 나는 우리가 자매 프로젝트에 관련된 내용이 있는 기사에서 다른 프로젝트에 연결한다고 지적하고 싶지만, 위키트리노리는 어떤 기사의 독자에게도 잠재적으로 유용하다. --agr (토크) 20:23, 2008년 10월 28일 (UTC)[응답]

반대한다; 사이드바의 다른 모든 링크는 당연히 내부 링크다.프로젝트의 모든 외부 링크는 외부 링크 아이콘 또는 "위키에 관한", "위키스페이에 있는" 등의 명시적인 문구를 통해 독자들을 다른 곳으로 데려가고 있다는 것을 나타내기 위해 조심스럽다.독자들이 무심코 엔위키를 떠날 수 있는 혼란스러운 '구멍'을 추가할 필요는 없다.어디든 위키에 대한 가치 있는 연결이 만들어질 수 있는 곳이라면, 물론, 당신이 그렇게 하는 것을 막을 수 있는 것은, 이성 안에서, 아무것도 없다.해피멜론 20:33, 2008년 10월 28일 (UTC)[응답]

비신뢰성 링크에 대해 방해하지 마십시오.샌디조지아 (토크) 20:35, 2008년 10월 28일 (UTC)[응답]

우리 링크의 대부분은 위키피디아와 연결되어 있는데, 위키피디아보다 믿을 만한 것이 없다.우리의 단일 목적 계정들 중 많은 수가 위키트리노에서 할 일을 찾지 못할 것이다.나는 이 반대론의 힘이 보이지 않는다.패혈성PMANDerson 22:10, 2008년 10월 28일 (UTC)[응답]

SandyGeorgia의 코멘트의 요점은 웹 디자인에서 독자들이 사이트를 떠날 때 약간의 경고를 받아야 한다는 것이 좋은 일반 원칙이라고 생각된다는 것이다.만약 그들이 내부적인 연결고리를 기대한다면, 그리고 외부적인 연결고리를 얻는다면 그들은 방향을 잃을 수 있다.2008년 10월 29일 04:13 (UTC)[응답]

"다른 프로젝트" 사이드바 링크를 관련 있는 위키트리노에 추가하는 템플릿을 추가할 수 있는 기능을 지원하겠지만, 그 외에는 당신이 생각하는 것만큼 관련이 없을 것 같다.EVula // talk // talk // 20:41, 2008년 10월 28일 (UTC)[응답]

더 이상 사이드바 잡동사니 하지 마십시오.우연한 경우, "익숙하지 않은 용어"는 파란색으로 연결되어야 한다. 만약 Wiktionary가 [wikt:term]을 사용하는 경우.-- 풀스톱 (대화) 23:50, 2008년 10월 28일 (UTC)[응답]

나는 위키피디아에서 4년 동안 편집해왔고 기사에서는 위키트리올과의 링크를 본 적이 없다.그런 내용을 담은 정책이나 가이드라인을 지적할 수 있는가.우리는 사전적 정의에 지나지 않는다고 여겨지는 기사들을 위키트리온리로 일상적으로 옮겨다닌다.이렇게 되면 내가 본 바로는 트랜스위키드 페이지로 연결되는 링크가 삭제된다. --agr (대화) 19:31, 2008년 10월 29일 (UTC)[응답]

보통 리드 섹션 내에 있지만 많은 부분이 있다.700개 이상의 인스턴스를 찾으려면 wikt를 검색하십시오.(하지만, 그 이상을 찾을 것으로 기대했다.나는 이것들이 유용하다고 생각한다. 그리고 그것들은 공식적으로 장려되어야 한다고 생각한다.)

하지만, 나는 그것들이 언제 사용되어야 하는지/사용되어서는 안 되는지에 대한 어떤 종류의 지침도 찾을 수 없다.아마도 위키백과에서 논의되어야 한다(또는 관련 토론:Wikimedia 자매 프로젝트 및/또는 위키백과 대화:InterWikimedia 링크. -- Quidity (대화) 22:20, 2008년 11월 6일 (UTC)[응답]

그 예들을 찾아줘서 고마워.260만 건의 기사에 7억 건 이상의 사례가 있다는 것은 그러한 링크가 드물다는 나의 주장을 뒷받침한다.그리고 "락시미 또는 마할락시미(Pronoration: [ləkʂ.miː]; 산스크리트어: लक्ष्lllakṣmī)"에서와 같이 외래어에 대한 링크와 같은 전문 용도가 많다.그러나 위키트 링크가 천 배 확장되었다고 해도, 우리는 여전히 독자들에게 낯선 것이 무엇일지 예상해 보는 입장이 될 것이다.나는 이것이 잘못된 접근법이라고 제안할 것이다.위키피디아의 모든 단어는 위키트리올과 연결될 것이다.독자가 단어를 강조 표시한 다음 보풀을 클릭하여 위키트리노에서 그 단어를 찾을 수 있는 메커니즘이 가장 좋을 것이다.내가 제안하는 것은 Wiktionary에 대한 사이드바 링크는 이상적이지는 않지만 간단하며 즉시 구현될 수 있다.-농업 (토크) 00:06, 2008년 11월 7일 (UTC)[응답]

또한 {{Wiktionary}(트랜스클로저 1만개 이상), {{Wiktionary-inline}(약 50회 사용), {{Wiktionarycat}(약 200회 사용), {{Wiktionarylang}(약 100회 사용), {{Wi}(약 500회 사용), 소수의 사용만 사용하는 템플릿이 있다.Mr.Z-man 01:41, 2008년 11월 7일 (UTC)[응답]

bugzilla:708. — Werdna • talk 14:08, 2008년 10월 29일 (UTC)[응답]

나도 이걸 지지해.

"언어" 아래의 인터위키 링크는 다른 위키에 대한 사이드바 링크의 선례다.사실 언어 위에 "프로젝트" 상자를 추가하고 사이드바 프로젝트 링크를 포함하기 위한 형식을 갖추는 것은 자매결연 박스의 끔찍한 혼란을 줄일 수 있을 것이다.콜론을 추가하면 사이드바에 링크(예: [[:wikt:entry])를 넣을 수 있다.

표준 외부 링크 아이콘은 [[wikt:] 링크와는 달리 링크가 외부임을 명확하게 보여줄 수 있지만 그렇지 않다.어쨌든 이건 꼭 필요한 건 아닐 거야—마이클 Z. 2008-10-29 20:04 z

프로그램적으로 할 수 있지 않았을까?만약 그 기사가 자매에 존재한다면, 링크는 자동 생성된다.그렇지 않다면 그렇지 않다.편집자에 대한 행동 변화가 필요하지 않으며, 단지 See Anto & EL 섹션의 기존 자매 프로젝트 박스를 삭제하는 것만이 봇에게 사소한 것일 수 있다.[ rox ] [x] 20:24, 2008년 10월 29일 (UTC)[응답]

그럴지도 모르지, 하지만 스마트한 기술이 필요할 거야. 그리고 감독 없이 항목을 추가하면 안 될 거야.예를 들어 Wiktionary 항목은 일반적인 대문자화 규칙을 따르기 때문에 wikt:banana가 있지만 wikt:우크라이나의어떤 경우에는 링크가 레지나처럼 다른 이름을 가질 수 있으며, Saskatchewan은 wikt에 링크할 수 있다.레지나.

하지만 어쨌든, 봇을 추가하는 것은 우리가 사이드바 링크에 대해 결정하는 어떤 것이든 따르는 부차적인 고려사항이다.—마이클 Z. 2008-10-29 21:18 z

리투아니아어 위키백과에서도 이와 유사한 시스템이 사용된다.예를 들어 다음과 같다.Europa에는 그러한 링크가 있다(사이드바에 있는 관련 상자는 "키투오스 프로젝투오스"이다).lt:Shablonas와 같은 템플릿:비키카토스 또는 lt:샤블로나스:비키오디나스는 그러한 연계가 있어야 할 기사를 가리키는 데 사용된다. --마티나스 파타시우스 (토크) 23:45, 2008년 10월 31일 (UTC)[응답]

내부 vs 외부 vs 자매 사이트는 중요한 문제가 아니라고 생각한다.문제는 우리의 독자들에게 가장 유용한 것이어야 한다.사이드 바 링크가 얼마나 자주 사용되는지 알 수 있는 방법이 있을까?만약 그렇다면, 나는 6개월 동안 위키트리노 링크를 시도해보자고 제안할 것이다.-농업 (대화) 14:02, 2008년 11월 2일 (UTC)[응답]

사용 mw:확장:누케

WP:더미에 쓰기

위키피디아의 원래 목표는 사람들이 알고 싶어 할 모든 것에 대한 기사를 쓰는 것이었다.300만개의 기사가 영어 프로젝트를 진행하면서, 나는 그 목표가 어느 정도 달성되었다고 생각한다.우리의 관심은 이제 백과사전을 유용하게 만드는 데 집중해야 한다.

너무 많은 기사들, 심지어 기초적인 주제에 관한 기사들조차도 일반 독자들에게는 대체로 또는 완전히 이해할 수 없다.어떤 기사들은 아래쪽에 복잡한 것(또는 더 구체적인 기사)을 두는 대신 위에서 아래로 높은 수준의 게발국어를 뿌린다.어떤 사람들은 위키링크를 중요한 용어를 정의하지 않기 위한 핑계로 사용하며, 독자들이 첫 번째 기사를 이해하는 헛된 시도로 위키피디아를 가로지르는 기러기 추격에 나설 것을 강요한다.어떤 것들은 99%의 사람들에게 횡설수설하는 복잡한 수학 공식들을 포함한다.

예전에는 일반 청중이라고 불리는 위키백과 주제가 있었지만, 그것은 비활동적이다.나는 하나의 위키백과 주제가 해결하기에는 문제가 너무 컸다고 생각한다.

나는 우리가 해야 할 일은 사람들에게 모든 위키백과 기사에 이해력을 포함하도록 강요하는 것이라고 생각한다.(그렇다고 모든 기사가 일반 대중이 이해할 수 있어야 한다는 말은 아니다. 오히려 모든 기사는 읽을 가능성이 있는 사람들이 이해해야 한다.)

나는 이것을 하는 한 가지 방법이 어떤 기사가 좋은 기사가 되기 전에 내가 "더미 테스트"라고 부르는 것을 요구하는 것이라고 생각한다.더미 테스트는 안전 점검의 반대다.더미 테스트는 이 주제에 대해 전문가들로부터 의견을 구하는 대신에 이 주제에 대해 잘 알고 있는 잠재 독자들의 판단을 요구한다.예를 들어, 야구를 위한 더미 테스트는 야구의 규칙을 모르는 사람들이 그 기사를 이해할 수 있는지 알아보도록 요구할 것이다.어떤 복잡한 주제의 경우, 더미들은 다른 사람들보다 같은 분야의 학부생일 수도 있지만, 모든 경우에 더미들은 그 주제에 익숙하지 않은 사람들이어야 한다.

더미들은 독자들의 관점에서 피드백을 제공할 것이다.결국 사람들은 대개 백과사전에 눈을 돌린다.더미들이 그 글을 이해할 수 없다면 좋은 기사가 되지 못한다.

"덤미"라는 말은 말 그대로 멍청한 사람을 의미하는 것이 아니라 위키백과가 해야 할 것처럼 아주 기본적인 것부터 주제를 설명하는 "...덤미" 책들의 정신에서 "덤미"를 의미하는 것임을 분명히 해야 한다.

우리가 할 수 있는 다른 일들로는 "너무 기술적인" 태그를 대화 페이지보다 기사 자체에 붙이는 것을 허용하고 위키피디아를 개선하는 것 등이 있다.기술 문서를 액세스 가능한 페이지로 만드십시오.나는 또한 월드북에 포함될 만큼 주제가 기본인 모든 기사를 일반인이 이해할 수 있게 만드는 것을 우선으로 하여 일반 관객 프로젝트를 부활시키고 싶다.

개인적으로, 나는 "위키피디아 기사는 그 주제에 대해 아직 잘 알지 못하는 사람들을 위해 쓰여져야 한다"는 위키피디아 기둥의 중요한 부분으로 여겨져야 한다고 생각한다. "위키피디아는 백과사전이다." 따라서, "더미를 위해 쓰라"는 단순한 스타일 가이드라인이 아니라 중요한 정책이어야 한다. -- Mwalcoff (talk) 01:19, 3N2008년(UTC)보다 과대평가[응답]

나는 확실히 그렇게 주관적인 것이 정책이 되어서는 안 된다고 생각한다.그것은 문체상의 문제로서, (이미 MTAA에서) 양식적 지침으로서 적절하게 처리되고 있다.그것이 정책이 된다면 기술 기사 편집과 관련된 위험도 꽤 있을 겁니다. 위키백과 역사상 처음으로, 불필요한 과잉 살상처럼 보이는 양식적 목적으로 제재가 적용될 수 있기 때문이지요.

나는 MTAA가 통치하는 내용을 손상시키지 않고, 솔직히 개선될 여지가 별로 없다고 생각한다.수학 같은 분야에서는 기초가 되는 기본을 이해하기 전에는 이해할 수 없을 뿐인데, 예를 들어, 어떤 기본을 살펴보면 한계 지식을 가정하지 않고는 파생상품을 정확하게 표현할 수 없고, 파생상품을 이해하기 전에는 통합에 대해 제대로 이해할 수 없다.이런 종류의 체인은 다변량 미적분학의 과목에 있어서는 상당히 커지게 되고, 내용을 손상시키지 않고 수행할 수 있는 단순화만이 있을 뿐이며, 논리와 고등 수학에 관한 많은 기사들은 이미 그 선에서 잘못된 쪽에 놓여 있다고 생각하는데, 그리고 당신이 묘사하는 종류의 어떤 종류의 "개선"도 거의 항상 없는 것이다.적어도 내 경험상 그 기사는 손상되었다.셀러너 02:09, 2008년 11월 3일 (UTC)[응답]

나는 일반적인 정서가 좋다.아까 계량 이론에 대한 링크를 따라가 보니 양자 이론의 기본 요지를 잘 알고 있음에도 불구하고 대부분의 글이 고대 수메르어로 쓰여진 것처럼 보였다. 적어도 (나는 너무 멍청하지 않아, 맹세해! )하지만 GA 과정에 관료주의를 더 추가하는 것이 최선의 생각인지는 잘 모르겠다.내가 보기에 GA는 충분히 나쁘고, 기본적으로 "충분히 좋은" 기사를 표시하는 경량 공정이라는 본래의 의도를 충족시키기 위해 처음부터 다시 시작할 필요가 있다.위키프로젝트를 다시 가져오는 것은 좋은 생각일 수 있고, 우리는 항상 더 많은 전문 편집자들을 모집할 수 있다.나는 또한 유전학에 대한 소개와 같은 소개서를 쓰는 아이디어도 좋아한다.—슬로우킹맨 (대화) 03:36, 2008년 11월 3일 (UTC)[응답]

게이지 이론을 이해하려면 양자장학 이론, 동력학 시스템 이론, 양자 전기역학, 그리고 분명히 직렬과 통합까지의 미적분학을 이해해야 한다.

수학에서, 나는 많은 학부생들이 위키피디아가 교과서에 비해 그들에게 파생상품을 훨씬 더 잘 설명했다고 말하는 것을 들었다; 나는 또한 시리즈와 한계에 대해서도 같은 이야기를 들었다.한계가 무엇인지 전혀 알지 못하는 파생상품에 대해 읽으려는 사람들의 입맛을 맞추려고 하는 기사에 스스로 넘어가지 않기 때문에 그럴 수 있다고 생각한다.사전 지식 없이는 효과적으로 의사소통을 할 수 없는 아이디어들이 있다.물론, 게이지 이론을 이해하고 그것에 대한 약간의 어설픈 설명을 읽는 것이 아니라, 양자역학, QED, QFT, DST에 대해 쉽게 읽어낸 다음 논리적인 진행을 따라 할 수 있었다.셀라노르 12:56, 2008년 11월 3일 (UTC)[응답]

맞아, 확실히 어느 정도의 전제조건 지식을 전제로 해야 할 주제가 몇 가지 있어.그러나 여전히 상당히 불투명한 전제조건 지식을 전제로 해서는 안 될 많은 기사들이 있다.나는 대부분의 사람들이 일상 생활에서 마주치거나 신문에서 읽을 수 있는 어떤 것이라도 이해할 수 있는 위키백과 기사를 가지고 있어야 한다고 제안하고 싶다.네가 세계책에서 찾을 수 있는 어떤 주제도 마찬가지야.또한 위키피디아는 종이가 아니기 때문에, 상위 수준의 정보를 도입 기사에 주입하려고 할 필요가 없다는 것도 유념할 필요가 있다.상위 정보는 본조에서 연계된 보다 구체적인 기사에 넣을 수 있다.

문제들 중 하나는 일부 편집자들이 위키피디아가 접근할 수 있어야 한다는 것을 이해하지 못한다는 것일 수도 있다; 그들은 그것을 유용한 것으로 보기 보다는 단순히 그들의 지식의 요약으로 본다. (이것은 독자들을 위한 것보다 자신을 위한 편집자의 큰 문제의 일부분이다.)예를 들어, e(수학적 상수)에 관한 기사의 한 편집자는 기사의 이해할 수 없는 점에 대해 이의를 제기했을 때, 사람들이 이 주제에 관한 인기 있는 책을 읽으러 갔다가 다시 돌아와 위키백과 기사를 읽을 수 있다고 대답했다!그는 백과사전으로서 위키피디아가 가장 기본적인 정보를 얻기 위해 가장 먼저 가는 곳이 되어야 한다는 것을 이해하지 못했으며, 그런 다음 좀 더 깊이 있게 배우고 싶다면 책을 읽으러 갈 수 있다.

그렇기 때문에 위키피디아가 어떤 주제에 대해 아직 익숙하지 않은 사람들에게 정보를 제공하기 위한 것이라는 선에 따라 위키피디아의 첫 번째 기둥에 몇 개의 단어를 포함시킬 수 있다고 생각한다.당신은 이것이 명백하다고 생각하겠지만, 분명히 철자가 필요하다.

'소개' 기사라는 개념은 경계하지만, 내용은 잘 짜여진 것 같다.내 생각에, 주요 기사 유전학은 "소개" 기사가 되어야 하며, 부기 기사에는 더 복잡한 정보가 포함되어야 한다. -- Mwalcoff (talk) 13:48, 2008년 11월 3일 (UTC)[응답]

나는 실제로 e에 관한 기사에서 편집자와 동의한다.만약 당신이 이해할 수 없는 어떤 것이 있다면, 당신은 그것을 완전히 이해할 수 있도록 전제조건에 대해 숙지해야 할 것이다.그것을 하향 평준화 하는 것은 우리 독자들에게 해로울 것이다; 만약 우리가 당신이 원하는 대로 한다면, e에 관한 기사는 모든 수준의 독자들에게 맞추려고 할 때 우스꽝스러울 정도로 거대해지거나, 아니면 "e는 대략 2.71에 해당하는 수학 상수"처럼 완전히 쓸모없는 것이 될 것이다.e가 진정으로 당신에게 어떤 의미를 갖기 위해서는 그것이 어떻게 도달되었는지, 그리고 그것이 진정으로 무엇을 의미하는지 이해해야 한다(이는 한계를 이해할 필요가 있다는 것을 의미한다).셀라노르 17:23, 2008년 11월 3일 (UTC)[응답]

나는 편집자가 이 기사에 대해 말하는 것을 알 수 있다.어쩌면 우리는 다음과 같은 페이지 헤더를 가져야 할지도 모른다.

{{User:Gnevin/sandbox1 read=Limits and Pi}}

그네빈 (대화) 21:48, 2008년 11월 3일 (UTC)[응답]

그것도 좋지만 좀 작을 수도 있을 것 같아. 21:26, 2008년 11월 3일 (UTC)

당신의 다른 요점에 답하기 위해, 나는 위키피디아가 기본적인 정보를 얻기 위해 가장 먼저 가야 하는 장소가 되어야 한다는 것에 동의하지 않는다.만약 여러분이 모든 것을 단순화하기를 원한다면, 그것을 염두에 둔 또 다른 프로젝트가 있다; 그것은 "단순 위키백과"이다.

나는 당신이 위키피디아가 조직되는 방식에 대해 약간 혼란스러워 한다고 생각한다; 우리는 주제에 익숙하지 않은 사람들에게 정보를 제공한다.위키피디아를 읽으면 해독제가 무엇인지, 어떻게 작용하는지 쉽게 알 수 있다.여러분은 통합에 관한 기사를 읽는다고 해서 모든 것을 알아낼 수 없을 겁니다. 당연히, 미적분학에 대한 역사가 없는 사람에게는, 그것들을 도입하는 것은 파생상품, 접선선, 한계, 기능, 그리고 기본적인 대수학까지 모두 한 글에 쓰도록 요구할 겁니다.그건 말도 안 돼.우리는 주제에 대한 정보를 제공할 수 있고 제공할 수 있다; 당신은 접선, 한계, 기능 등에서 필요한 수학적 지식과 기술에 대한 모든 것을 읽을 수 있다.단지 그것을 위해 프로젝트 전체에 걸쳐 다른 기사에 주어진 정의를 확장할 필요는 없다.

물론 대안적인 해결책은 필요한 정보에 대해 누군가가 알 필요가 없는 방식으로 정보를 제시하는 것이다.물론, 우리는 정확성, 정확성, 정확성을 잃는다; 기술적인 용어로 설명하는 것이 그러한 것들을 성취하는 가장 좋은 방법이다.정확도, 정밀도, 정확도, 정확도, 정확도를 평가하는 경우(예를 들어, 파생상품이 무엇인지를 설명하는 경우, "한 지점에서 접선 선의 기울기" vs "x축의 변화로 나눈 y축의 변화 값"을 선의 한 부분에만 닿도록 다른 선에 대해 그린 선으로 나눈 값) 우리는 다시 그리기를 시도해야 한다.그들이 먼저 이해해야 할 자료로 RS하고, 그리고 나서, 좋아.나는 그것에 대해 아무런 문제가 없다; 그것이 어쨌든 사람들이 배우는 방법이다.

궁극적으로, 나는 이런 종류의 것들은 당신이 무언가를 이해하고자 하는 독자에게 맞추기를 원하는지, 아니면 사물의 빠른 요약을 원하는 독자에게 맞추기를 원하는지에 달려있다고 생각한다; 전 그룹의 일원으로서, 나는 단지 그것을 원하는 누군가에게 접근할 수 있게 하는 것만으로 쓸모없는 것 다음으로 요약되는 기사를 보는 것을 싫어한다.빠른 정의

나는 "x에 대한 소개" 기사가 좋은 타협이라고 생각한다; 그것들은 주요 기사를 하향 평준화하는 것과 관련된 피해를 야기하지 않으며, 그것들은 빠른 정의나 요약에만 관심이 있고 그 자료에 별로 관심이 없는 사람에게 필요한 자료가 요약되고 단순화될 수 있는 장소를 제공한다.그리고 그것은 말이 된다; 만약 여러분이 유전학에 대한 소개를 원하지만, 그것을 진정으로 이해하려고 하지 않는다면, 그것이 바로 가야 할 장소일 것이다.그 대답은 확실히 유전학에 관한 주요 기사를 그 정도로 하향 평준화하지는 않는다.셀라노르^{Talk to me} 21:31, 2008년 11월 3일 (UTC)[응답]

예를 들어

{{User:Gnevin/sandbox2 read=Limits and Pi}}

그네빈 (대화) 21:48, 2008년 11월 3일 (UTC)[응답]

예를 들어, 'e' 기사는 기술 수준이 낮은 청중에게 설명되는 추가 섹션을 추가함으로써 단순화되지 않을 것이다.6학년 수학의 모든 사람들은 뉴턴의 미적분학을 배움으로써 e의 기술적 의미에 대해 더 배우고 싶은지 결정하기 위해 e의 일반적인 개념과 그것의 중요성에 대해 알 수 있어야 한다.'e'는 기사의 접근법이 시사하는 것보다 훨씬 간단한 것이다.

이와 같은 가벼운 설명을 단념시키는 것은 헨리 8세의 전기의 기본을 읽기 전에 독자가 중세 캐논과 관습법을 완전히 이해하도록 요구하는 것만큼이나 이상한 일이다.

대안은 6학년 수학의 독자들이 'e'는 전혀 중요하지 않다; 수학, 공학, 사회과학, 그리고 인류 역사의 조각상의 중요한 부분이 아니라, 접선을 좋아하는 수학자들에게만 관심을 가지고 있다; 그리고 기초적인 것에 대해 더 많이 배우려는 동기를 얻지 못한다.원칙백과사전의 사명을 위한 비극적인 결과.

GA는 그 목적에 비해 너무 무겁기 때문에 GA 기준이 이를 지켜볼 만한 곳은 아니라고 생각한다.역사, 종교, 경제, 의학, 동물학, 또는 내가 탐구한 백과사전의 많은 다른 분야들에서 이러한 경향을 알아차리지 못했기 때문에 위키백과에서 수학 주제와 물리학 주제의 일부가 접근성에서 멀어지게 된 이유를 나는 잘 모르겠다.어쩌면 거기에 단서가 있을지도 모른다.

--Hroðulf (또는 Hrothulf) (토크) 23:54, 2008년 11월 3일 (UTC)[응답]

우리는 그네빈이 위에서 제안한 것과 정확히 같은 것을 하는 전제조건 상자라고 불리는 것을 가지고 있었다.어떤 이유에선지, 그들은 결코 알아채지 못했다.

나는 특히 우리가 종이가 아니라는 것을 고려할 때 완전하고 이해할 수 있는 것이 가능하다고 생각한다.월드북이나 아메리카나 같은 정원 다양성의 일반 백과사전(아직도 그렇게 만든다면)은 정확성을 훼손하지 않고 간단한 방법으로 사물을 설명하는 데 성공한다.그러면 여러분은 브리태니카를 갖게 되는데, 브리태니카는 좀 더 교육받은 청중들을 위해 쓰여지고 좀 더 깊이 들어가며, 마지막으로 여러분은 특정한 주제에 대한 백과사전을 가지게 되는데, 이것은 가장 전제적인 지식을 전제로 한다.위키피디아의 가장 좋은 점은 우리가 종이책이 아니기 때문에 세계책과 브리태니카 그리고 "미적분학의 백과사전"이 한 곳에서 모두 될 수 있다는 것이다!나는 얼마 전에 지식이 부족할 가능성이 가장 적은 청중들을 위해 기사를 써야 한다고 제안했다.많은 기사의 경우, 이것은 일반 독자일 것이다. 다른 기사의 경우, 특정 분야의 학부생일 수도 있고, 아마도 한 분야의 직업 전문가일 것이다. -- Mwalcoff (토크) 00:58, 2008년 11월 4일 (UTC)[응답]

Mwalcoff, 템플릿 말씀이세요?전제조건?그렇다면 복잡한 기사에 대한 전제조건을 나열하는 아이디어가 마음에 든다.위에서 언급했듯이, 표준 텍스트 링크보다 더 직접적이면서, 모든 것을 하나의 기사에 주입하려는 필요성을 줄인다.그것은 또한 사람들이 대학 과정을 수강하는 것에 익숙한 개념과도 유사하다.생각? --Ckatz^chat_spy 01:15, 2008년 11월 4일 (UTC)[응답]

네, 그런 뜻이었습니다. -- 음왈코프 (대화) 02:22, 2008년 11월 4일 (UTC)[응답하라]

이미 한 기사가 어떤 주제에 익숙하지 않은 사람들에게 문맥이 불충분할 수 있다는 것을 나타내는 태그가 있는데, 이는 초개인적인 경영학 기사에 주어졌다.아마도 전문용어가 너무 많이 포함된 기사들을 위해 또 다른 태그가 만들어질 수 있을까?어떤 면에서, 인쇄된 백과사전에는 매우 부적절한 저널리즘, 일화, 잡지 같은 스타일 또는 개인적인 스타일과 반대로 기술적인 스타일로 쓰여진 기사들에 감사하자.ACEOREVIVEED (토크) 22:20, 2008년 11월 4일 (UTC)[응답]

서론을 일반인이 접근할 수 있는 것으로 사용하는 것이 무슨 문제인가?이것은 현재 파이, 그리고 e에 해당된다.그런 종류의 기사의 대다수는 기초 수학 개념을 이해하지 못하는 사람에게 쓸모없는 것이기 때문에, 왜 그냥 그렇게 하지 않는가?셀라노르 23:04, 2008년 11월 4일 (UTC)[응답]

나는 우리가 어떤 행동이 기사를 더 이해하기 쉽게 만드는 데 도움이 될지를 결정하기 전에, 정확히 무엇이 위키피디아의 이해가능성에 대한 정책인지 결정해야 한다고 생각한다.이 논의를 빌리지펌프의 정책 부분으로 옮기겠다. -- 음왈코프 (대화) 05:42, 2008년 11월 7일 (UTC)[응답]

• 기사에 필요한 사전 지식이 요구되어서는 안 된다는 것이 이미 우리의 방침이다.이를 준수하지 않은 경우, 해당 기사는 GA/FA에 불합격해야 하며, 제안된 대로 명시적으로 테스트하는 것이 좋을 것이다.수학 기사는 최악의 범법자인데, 이것은 우아한 순수함과 정밀함의 부르바키 스타일에 익숙하고 선호하는 전문적인 수학자들이 소유하고 있기 때문이라고 나는 생각한다.의료기사에서도 전문가들이 들어와 심장마비보다는 심근경색 등 자신이 선호하는 전문용어를 사용하기 위해 기사를 변형하면서 비슷한 과정이 일어나는 것을 본다.우리의 역할은 누구나 편집할 수 있는 백과사전이 되는 것이기 때문에, 우리는 그러한 전문적인 엘리트주의를 밀어내야 하고 더미들을 위한 주제는 이것을 위한 좋은, 현존하는 슬로건이다.워든 대령 (대화) 2008년 11월 7일 (UTC) 13:21[응답]

• • 많은 주제들이 상당한 양의 배경 지식을 필요로 한다는 것을 우리가 완전히 잘 알고 있을 때, "어떤 기사도 사전 지식이 요구되어서는 안 된다"고 선언하는 것은 비현실적이다.이것은 수학뿐만 아니라 모든 과학, 음악, 그리고 많은 다른 분야에도 적용된다.우리는 키(음악)를 언급하는 모든 기사가 키가 무엇인지에 대한 정의를 포함하기를 기대하지도 않고, 수학 용어를 언급하는 모든 기사가 그 용어의 정의를 포함하기를 기대하지도 않는다.각각의 글은 가장 큰 독자층을 확보하기 위해 필수요건을 거의 이해하는 독자를 위해 작성되어야 한다.
    비록 글쓰기가 서툴거나 너무 기술적인 것에 대한 많은 불평이 타당하지만, 다른 것들은 단순히 독자들이 모든 글들이 독자의 입장에서 일하지 않고 즉시 접근할 수 있기를 기대하는 결과일 뿐이다.그것은 불가능한 기준이다.접근성에 대한 불만의 아이러니한 측면은 스펙트럼 시퀀스와 같은 많은 진정으로 복잡한 주제에서 WP가 실제로 주제를 토론하는 대학원 수준의 텍스트보다 학부생이 훨씬 더 쉽게 접근할 수 있다는 것이다.이 정도 수준의 자료는 다른 백과사전은 없다.— 칼 (CBM · talk) 2008년 11월 7일 (UTC) 13:31 [응답]

나는 "어떤 기사도 사전 지식이 요구되어서는 안 된다"고 선언하는 것이 비실용적이라는 것에 동의한다.우리는 가정된 사전 지식의 목표 수준을 정의할 필요가 있다.위키백과의 유사한 토론에서:마을_펌프_(정책)#Compensibility_of_articles 기본 목표 수준은 "평균적으로 12세"여야 하며, 보다 복잡하거나 기술적인 언어 또는 프레젠테이션이 필요하다는 것을 보여주기 위해 편집자와 재조명자에게 입증의 싹을 틔워야 한다고 제안했다.

e(수학적 상수)는 나쁜 접근법의 좋은 예다 - 나는 학교에서 e에 대해 배웠고, 우리 중 누구도(현재 수학 교수인 2명 포함) 15세에 e(수학적 상수)를 이해하지 못했을 것이다. --필차 (대화) 15:16, 2008년 11월 7일 (UTC)[응답]

기본적으로 인라인 시트의 표시 끄기

글루링크와 레드링크에 의한 WP 기사의 시각적 혼란은 인라인 시트로 인해 크게 악화된다.내가 이해한 바와 같이, 눈에 띄게 명백한 진술(지구가 태양을 공전한다)은 생략하고, 사실의 모든 주장은 반드시 인라인 인용문으로 참조되어야 하며, 인라인 인용문은 각주로 연결되는 진술 뒤에 위첨자 번호로 나타난다.

인라인 시트가 잔뜩 들어간 글을 읽는 것은 육체적으로 고통스럽다.종이 백과사전도 없고, 그 문제 때문에, 내가 본 어떤 책도 그런 수준의 발소리를 쓰지 않는다.

반면에 나는 인라인 시트의 필요성을 이해하는데, 그것들은 익명 또는 가명 편집자에 의한 잘못된 정보의 삽입에 대한 부분적인 안전장치이기 때문이다.

따라서 기본적으로 위키백과 기사의 인라인 시트의 표시를 해제하고, 독자들이 한 번의 마우스 클릭으로 디스플레이를 켤 수 있는 페이지 상단 근처에 "토글 스위치"를 배치하는 것으로 보완하자는 나의 제안.--굿모닝월드 (토크) 14:15, 2008년 11월 3일 (UTC)[응답]

인라인 인용문(특히 인쇄 등)을 비활성화할 수 있다는 생각은 좋지만, 디폴트로 비활성화해서는 안 된다고 생각한다.모든 사람이 그것을 켜고 끄는 방법을 깨닫지 못할 수도 있고, 경험이 부족한 사용자들이 내용을 검증할 수 있는 것과 그렇지 않은 것은 어려울 것이다.셀라노르 14:52, 2008년 11월 3일 (UTC)[응답]

나는 이 제안에 강력히 반대한다.만약 이것이 신체적으로 당신에게 상처를 준다면, 당신은 정신과적 문제로 정신과 치료를 받고 싶을 것이다.시트를 위해, 특히 인라인 시트를 위해 싸워야 하는 것을 고려하면, 이 제안은 매우 나쁜 생각이다. - 데님아데프트 (토크) 14:57, 2008년 11월 3일 (UTC)[응답]

동의한다. 인용문은 옵트인 시스템 뒤에 숨기에는 너무 중요하다. --Tango (대화) 15:07, 2008년 11월 3일 (UTC)[응답]

강력하게 반대한다, 선택사항으로서라도.도대체 왜 저자들은 각각의 의미 있는 진술에 주석을 달아야 하는가?쓸모없다고 생각할 수도 있지만 본문에 앵커가 없는 긴 참고문헌을 보는 것은 훨씬 더 큰 허튼소리다.이제 어떤 현명한 사람이 실수로 참조를 끄고 인용 부재를 위해 {{unreferenced}s 또는 심지어 {{prod}s를 삽입하기 시작한다고 생각해 보십시오.NVO (대화) 10:08, 2008년 11월 4일 (UTC)[응답]

사용자 스타일시트에 코드를 추가하면 시각적 영향을 줄일 수 있다(사용자:굿모닝월드/모노북.css.예를 들면

supp.reference a { display:reference }

그들을 완전히 숨겨야 한다.

최신 브라우저(예: MS Internet Explorer가 아님)를 사용하는 경우 다음을 추가할 수 있으며, 문단을 마우스로 누를 때까지 인용문 참조가 눈에 덜 띄도록 표시되므로 여전히 해당 참조를 찾아 클릭할 수 있다.완전히 숨기려면 "#CCC"를 "투명"으로 변경하십시오.)

/* 인라인 참조 인용문 숨기기 */ p supp.reference a { color: #CCC; } p:hover supp.reference a { color: #002BB8; } p:hover supp.reference a:active { color: #FA700; }

무슨 문제가 있으면 나에게 알려줘.—마이클 Z. 2008-11-03 15:19 z

고마워, 이따가 먹어보고 다시 보고할게.하지만, 그것이 효과가 있다 하더라도, 그것은 오직 나와 우연히 여기서 읽고 있는 사람에게만 도움이 될 것이기 때문에 "이기적인" 해결책이 될 것이다.그래서 나는 예전처럼 내 제안을 유지한다.(아직 충분히 생각해보지 못한 가능한 타협안은 당신의 코드를 "나의 선호"에서 "게젯" 탭에 옵션으로 추가하는 것일 수도 있다.)--굿모닝월드 (대화) 15:42, 2008년 11월 3일 (UTC)[응답]

기본적으로 WP:검증 가능성과 WP:신뢰할 수 있는 소스의 경직성을 고려할 때 거의 의미가 없다.끌 수 있는 장치로서, 스타일시트를 실제로 수정할 수 있다는 점을 고려할 때, 이 요청도 그렇게 필요하지 않다고 생각한다.javascript 버전이 css 버전보다 기사별 통제를 더 많이 할 수 있을지 궁금하다. --Izno (토크) 17:10, 2008년 11월 3일 (UTC)[응답]

나는 이미 인용된 이유에 따라 가능한 가장 강력한 용어로 이 제안에 반대한다.와우.. 이건 정말 안좋은 생각이야.미안해, 굿모닝월드. 하지만 모든 사용자를 위해 이것을 구현하는 것은 좋은 것이 없어.[ rox ] [x] 17:16, 2008년 11월 3일 (UTC)[응답]

각주는 존경할 만한 학문적 글의 일부분이며, 그럴만한 이유가 있다.나는 그들이 원하지 않는 독자들에게 그것들을 숨기는 선택권을 주는 것에 반대하지는 않지만, 메모는 절대적으로 'on'으로 디폴트되어야 한다.TenOfAllTraes(대화) 22:19, 2008년 11월 3일 (UTC)[응답]

나는 그 모든 것에 동의하지만, 각 주석을 네모난 괄호로 둘러싸인, 한 줄로 된 여러 개의 각주 참조는 어떤 학술적인 글이나 사실 어떤 인쇄물에서도 받아들여지지 않는다는 것을 명심하라.각주의 존재는 허용되지만, 현재의 시행은 훌륭한 타이포그래픽 기준에 미치지 못한다.—마이클 Z. 2008-11-03 22:45 z

난 사실 우리 형식이 완전히 틀렸다고 생각하지 않아.당연히 우리는 우리 자신을 온라인 학술지에 비교해야 한다.주요 저널의 HTML 버전을 보면 참조를 위한 많은 다른 스타일이 드러난다.과학 저널들 중 '빅 건'으로는 과학, 자연, 셀, PNAS가 있다.

• 과학과 PNAS는 둥근 괄호로 묶은 전체 높이 숫자를 사용한다: 로렘 입숨 (2) dolor sic amet (3,4)
• 자연은 위첨자 숫자(브래킷되지 않은 숫자)를 사용하지만 클릭성을 지원하기 위해 매우 넓은 글꼴을 가지고 있다: 로렘 입숨^{2 1} 돌로르 amet^{2 2, 2 3}.
• 셀은 작성자와 날짜를 원형 괄호로 묶고, 대괄호는 다중 참조를 구분한다.로렘 입숨 (Smith and Wesson, 2005) dolor sic amet ([Jones et al., 2006], [Simpson, 2007])

내가 본 바로는, 대부분의 온라인 저널은 그 세 가지 형식 중 하나를 따른다.우리의 스타일은 기존의 웹 표준에 비해 완전히 제정신이 아닌 것은 아니며 눈에 띄게 거슬리는 것도 아니다.대괄호 대신 네이처 스타일의 와이드 폰트를 보면 좋겠지만, 위첨자 숫자를 사용하는 한 링크를 쉽게 클릭할 수 있는 방법이 필요하다.TenOfAllTraes(대화) 23:24, 2008년 11월 3일 (UTC)[응답]

모두 인용 참조에 대한 링크를 사용하는가, 아니면 텍스트만 사용하는가?인문 저널이 무엇을 사용하는지도 궁금할 것 같아.—마이클 Z. 2008-11-04 16:12 z

예, 모든 노트는 페이지 하단의 참조 목록에 대한 하이퍼링크 앵커입니다.TenOfAllTraes(대화) 2008년 11월 4일(UTC) 17:00[응답]

가장 흥미롭군, 테노팔레이즈 그 정보 고마워나는 가서 이 네 개의 온라인 저널을 모두 살펴보았다.불행히도 과학과 자연은 온라인에서 무료 기사를 제공하지 않지만, Cell과 PNAS는 무료 기사를 제공한다.내 생각에는 후자 둘 다 훌륭하고 읽기 쉽다.그러나 그 안에 있는 인라인 시트의 밀도는 WP 기사에 요구되는 것보다 훨씬 적다.거기에는 다음과 같은 이유가 있다.과학저널에 게재하는 사람들은 일반적으로 박사학위자인데, 자기 이름(가명)으로 출판하고 있으며, 평판을 걸고 있으며, 기사들은 동료들의 평판을 받고 있다.또한, 그들의 독자층은 구체적으로 언급되지 않은 많은 정보를 이미 알고 있을 것으로 예상할 수 있다.

지금, 나는 WP 기사의 인라인 시트의 요건을 폐지해야 한다고 주장하는 것이 아니다.그것은 백과사전의 규칙 준수를 보장하기 위해 부분적인 (충분하지는 않지만 충분하지 않은) 안전장치로서 필수적이다.내가 전에 이런 말을 한 적이 있지만 그것은 반복할 가치가 있다.

그러나 내 글 베스만 가문을 보면 수많은 인라인 구절들이 그것을 어지럽히고 있는 것이 얼마나 추악한지 새삼스럽게 생각한다. 그리고 이것은 어떻게 하면 그것을 더 멋지게 보이게 할 수 있는지에 대한 조언을 받은 후에 나온 것이다.

책에서, 각주 시스템은 위첨자 번호가 페이지 하단의 각주를 가리키는 같은 페이지부터 책 끝 쪽지 "수집"까지 다양하다.그 다음엔 니올 퍼거슨과 같은 "거의 각주를 전혀 쓰지 않는" 작가들이 있는데, 그는 파란 달에 한 번 각주를 제공하고 나머지 정보에 대해서는 당신이 그의 말을 받아들이기를 기대한다.내가 가장 좋아하는 시스템은 본문에 시트가 전혀 없는 것이 아니라 책 뒷면에 이렇게 엔딩이 나타나는 것이다.

173쪽: "... 모차르트가 거절했을 때, 살리에리는 그의 튜비스트에게 작은 신생아가 죽는 것을 보고 싶다고 털어놓았다.요제프 폰 옴파의 회고록, 비엔나 1821페이지.175쪽: "..."

등등.좋아, 이제 이 실타래 안에 있는 사람들이 추천하는 소프트웨어 솔루션을 확인해 볼 시간이다.--굿모닝월드 (토크) 19:58, 2008년 11월 4일 (UTC)[응답]

정보를 알려줘서 고마워. (각 페이지의 각주와는 달리, 섹션이나 책의 끝부분에서 주석을 찾을 수 있다.퍼거슨 스타일은 매력적으로 보인다; 출판사는 누구인가?거의 사용되지 않지만 매우 매끄러운 또 다른 스타일은 사이드노트로, 각 노트가 마커가 있든 없든 본문 옆의 여백에 걸려 있다.Bringhurst(책)에서 볼 수 있음—아마존의 책 내 검색에서 예를 볼 수 있을 것이다.[1] 그리고 물론 하버드 스타일도 있는데, 원괄호 안에 텍스트 참조가 있다.

그래, 우리 요구 사항은 전문적이고 동료가 검토한 출판물보다 더 철저하게 각주를 하는 거야.하지만, 우리는 학업보다는 폭넓은 청중들을 목표로 하기 때문에, 각주는 평균적으로 덜 사용될 것이다.따라서 인쇄된 출판물 또는 온라인 학술 기사(아직도 접근이 용이함)에 있는 것보다 시각적으로 덜 두드러지게 만들어져야 한다.—마이클 Z. 2008-11-04 23:21 z

더 명확하게 말하면, 책의 본문을 깨끗하게 하고, 참고에 이어 책의 본문 한 조각(및 그 본문이 등장하는 페이지 번호)을 반복하는 형태로 책 뒷면에 있는 '내주'를 수집하면서 완전히 시트가 없는 체계는 퍼거슨 감독이 사용하는 것이 아니라 제임스 글리크의 '제니우스'와 같은 책에 사용된다.퍼거슨 감독은 그의 책 "세계의 전쟁"을 보면서, 아주 드물게 각주를 사용하는 사람이다.나는 지금 내가 그렇게 많은 시간을 할애한 기사가 의심하지 않는 독자에게 어떻게 보일 것인지에 대해 낙담하고 있을 뿐이다; 만약 내가 인라인 시트의 혼란으로 인해 그 기사를 읽고 싶지 않다면, 어떻게 다른 사람들이 읽기를 기대할 수 있을까?--굿모닝월드 (토크) 15:44, 2008년 11월 5일 (UTC)[응답]

참조 링크를 더 크게/전체 높이로 만드는 것을 볼 수 있어서 노인들이 신경쇠약에 걸린 상태에서 보고 클릭할 수 있다. - 데님아데프트 (토크) 23:52, 2008년 11월 3일 (UTC)[응답]

그것은 개인화된 CSS로 쉽게 할 수 있다.그래서 각주 링크를 완전히 숨길 수 있다.나는 그들을 혼란스럽게 하는 것 또한 가능할 것이라고 기대한다.아마도 이러한 옵션들 중 몇 가지를 위한 가젯이 있어야 할까?대수학자 10:38, 2008년 11월 4일 (UTC)[응답]

단지 시력 문제가 있는 많은 노인들이 CSS 코딩 방법을 모를 수 있다는 생각이 들었다. :-) - 데님아뎁트 (토크) 17:52, 2008년 11월 5일 (UTC)[응답]

그래서 내가 기구를 만들자고 제안한 거야.대수학자 11:41, 2008년 11월 6일 (UTC)[응답]

Comment I copy I've copy Michael's CSS for currents an expected for citesesese of Greasemonkey 사용자들이 실험할 수 있도록 이 userscript를 만들었다. (BTW I am a Script-beginner)en: 및 fr: 위키피디아의 모던 및 모노북 스킨에 대해 테스트됨.사용자는 Greasemonkey를 통해 "숨기기"를 전환하고 현재 위키백과 기사를 다시 로드할 수 있다.이것은 스냅샷 전후를 보여준다.나 자신은 항상 보이는 시트를 선호하지만, 외관을 개선하고 사용자에게 선택권을 제공할 수 있는 모든 기기에 관심이 있다. -84사용자(대화) 15:57, 2008년 11월 4일 (UTC)[응답]

매우 희미하거나 보이지 않는 구절의 문제는 특히 여러 구절들이 줄지어 있을 때 텍스트에 간극을 남기는 것이다.이것들은 거의 틀림없이 원래의 링크만큼 거슬린다.디스플레이:아무도 이 문제를 해결하지 못하지만, 만약 그것들이 켜지면 텍스트가 다시 래핑되므로, 그것 역시 좋은 해결책은 아니다.

아쉽게도 Cite.php[2]에서 만든 링크 텍스트는 괄호 숫자일 뿐이므로 간단한 CSS를 사용하여 괄호를 숨기거나 변경할 방법이 없다.중요한 기능 요청은 CSS로 브래킷을 생성하거나 스팬을 추가하여 골라내는 것이 될 수 있지만, 현재 진행 중인 개발이 있다는 증거는 없다.—마이클 Z. 2008-11-04 16:12 z

MediaWiki의 괄호 안에 클래스를 추가해 보았다.참조 링크를 인용하라; 그것은 실현가능하지 않았다. (어떤 경우에는 페이지 크기를 20% 증가시켰다!)해피멜론 17:22, 2008년 11월 4일 (UTC)[응답]

오, 이런 기능이 있는지 몰랐네이 일을 성사시킬 수 있는 어떤 가능성이 있어야 한다.

HTML을 다른 클래스로 혼동할 필요는 없다.스팬이나 다른 요소만 있으면 되고, 그러면 CSS는 다음과 같은 것을 사용하여 그것을 선택할 수 있다.sup.reference a span {}. —마이클 Z. 2008-11-04 19:52 z

알았다: 브래킷을 완전히 숨기려면 이제sup.reference a span { display: none; }(htt: 테스트 진행 중).—마이클 Z. 2008-11-04 19:59 z

귀찮게 할 건 아니지만, HTML이 많이 추가되는군...어때sup.reference {display:none;}그 뒤를 이어sup.reference a {display:inline !important;}대신에?내 생각엔 그렇게 할 것 같아. 그리고 너는 그 범위를 참고문헌에 추가할 필요가 없을 거야.테스트는 하지 않았지만, 작동하지 말아야 할 이유가 없다고 본다. --DJ (대화 • 기여) 12:04, 2008년 11월 6일 (UTC)[응답]

불행히도, 작동하지 않는다. 괄호는 링크 제목에 포함되어 있기 때문에 그렇게 분리될 수 없다.나는 또한 이 HTML의 추가에 반대한다; 렌더링된 출력을 그렇게 크게 부풀려서 얻을 수 있는 것은 너무 적다.해피멜론 12:47, 2008년 11월 6일 (UTC)[응답]

내가 분명히 말하겠다.

나는 이미 참고 인용문에 각 괄호를 둘러싼 평범한 범위를 추가했다.이것은 HTML을 많이 추가하지 않는다(Wikipedia의 HTML은 이미 상당히 무겁고, 나는 아마도 이것의 추가보다 훨씬 더 많은 코드를 제거할 수 있는 십여 가지 방법을 생각할 수 있을 것이다).기사 베스만 가문은 9만8239바이트에서 10만1229B(B2990B, 3.0%)로 증강된다.이것이 문제라면 콘텐츠 주변에 스팬을 배치하고, CSS를 약간 더 복잡하게 만들어 줌으로써 그 증가를 반으로 줄일 수 있다.

인용 표시를 숨기거나 수정하는 방법은 사용자 스타일 시트(예: 내 것은 User:Mzajac/monobook.css)에 있으므로 HTML을 추가하지 않는다.

1. sup.reference { display: none; }참조를 완전히 숨길 것이다.
2. sup.reference a span { display: none; }브래킷을 완전히 숨길 것이다.
3. 나만의 스타일시트에서 나는 참고문헌을 검정색으로 인쇄된 책 참조와 똑같이 보이게 하는 코드를 구현했다.다중 연속 참조는 쉼표(여전히 버기)로 구분된다.해당 항목을 찾으려면 마우스를 한 단락 위로 이동하면 참조에 밑줄이 표시됨(Safari, Firefox, Opera에서 테스트됨; MSIE에서 작동하지 않음)

—마이클 Z. 2008-11-06 16:39 z

추가 설명:Firefox에는 Styley 사용자를 위한 사용자 스타일 "Wikipedia - hide reference link"가 이미 존재한다는 것을 알았다.위 데님아데프트의 코멘트에서 영감을 받아 밸런스를 위해 "위키피디아-볼더 볼드 인라인 시트" 스타일을 만들었다.발견했으므로 스타일에는 Greasemonkey 대신 Styley를 사용하는 것을 추천한다. -84user (토크) 19:31, 2008년 11월 4일 (UTC)[응답]

이미 WikEd 편집기 가젯을 사용하여 인라인 인용을 페이드할 수 있다(Gadgets 아래의 Wikipedia Preferences에서 WikiWikEd를 선택하고 버튼을 클릭).Cacycle (talk) 00:17, 2008년 11월 5일 (UTC)[응답]

잘못된 문제를 해결한다고?

위에서 언급된 기사 중 하나인 베스만 가문을 교란적으로 거슬리는 각주를 가지고 있다고 보았다.나는 동의한다, 특히 학문적인 글쓰기에 익숙하지 않은 독자들에게, 글의 흐름과 외관은 위키링크와 각주에 의해 방해된다.단, 이것은 과대평가나 빈약한 각주형식의 문제는 아닐 수 있다.사람들은 아마도 각주 링크를 덜 보이게 하기 위한 기술적 도구를 개발하려고 노력함으로써 우리가 이상적이지 않은 편집과 스타일 선택을 단지 회피하고 있는 것이 아닌지 의아해 한다.베스만 가문의 이 단락을 인용하십시오.

콘라드는 아이슬레벤에서 견습생으로 고향을 떠났다.[16]그는 Münzwardein로 Dömitz에(Mecklenburg)[17] 다음 1683Münzmeister의 공주 Nassau-Holzappel의 Cramberg에 란 강 river,[18]1687년에 Münzmeister로 독일 주문의 기사의 Friedberg에 그의 약속, 1692년 Münzmeister은 Archbishopric고 선 제후국 Mainz[19]의 Asc에로에 임명되었다.haffenburg[2][7].

그것은 사실적인 정보로 가득 차 있지만, 확실히 우리는 그것을 더 잘 제시할 수 있어야 한다.그 단락은 콤마와 함께 나누어져 있다.거의 모든 제목과 위치가 위키로 연결되어 있다.모든 사실에는 각주 링크가 있다.

내가 보는 것은 본질적으로 줄 바꿈을 놓치고 있는 글머리표나 시간표다.비교:

• (Unded) 아이슬레벤에서 애프레티시프 시작
• (미제) ö미츠(메클렌부르크)^[17]에서 뮌즈워딘(Meklenburg)으로 활동했다.
• 1683: 뮌즈마이스터(Münzmeister)를 란 강^[18] 크렘베르크에 있는 나소홀자펠 공주에 임명
• 1687: 프리드베르크에서^[19] 독일 기사단 뮌즈마이스터 임명
• 1692: 아샤펜부르크의^[2][7][19] 마인츠 대주교 및 선거인단에 뮌즈마이스터 임명.

거의 동일한 단어로 이루어진 동일한 정보지만, 이제는 그것이 순서가 정해진 사건 목록과 이정표라는 것이 명백해졌다.각주 링크는 모두 줄 끝에 있고 길을 벗어나 있기 때문에(그러나 여전히 텍스트와 명확하게 연결되어 있음) 주의를 산만하게 하지 않는다.백스페이스, 총알, 볼드체인은 사건들과 그 질서의 시간적 분리를 분명히 한다.

나는 글머리표식 방법만이 이 정보를 제시하는 유일한 방법이라고 말하는 것도 아니고, 심지어 그것이 최선이라고 말하는 것도 아니다. (최상에 가깝다는 것에도 불구하고....) 나는 문제가 반드시 각주 링크와 함께 있는 것은 아니라고 말하고 있다.위의 구절에서 각주 링크는 시각적인 혼란을 더하지만, 분명히 그것들만이 유일한 문제는 아니다(그리고 아마도 주요한 문제는 아닐 것이다).

기사들을 대량으로 다시 쓰지 않고, 위키링크의 수수한 손질과 각주 링크의 통합과 같은 간단한 단계를 통해 흐름과 외모를 개선할 수 있다.각주가 문장 안에 나타나는 곳이라면 문장의 끝으로 옮기는 것이 해로운지 생각해 보라.그것을 단락의 끝까지 옮기는 것을 생각해 보아라.각주가 쉼표로 바로 나타나는 경우 런온 문장에 플래그가 표시되지 않는지 확인하십시오.만약 연결고리가 빠르고 맹렬하게 다가오고 있다면, 그것은 추가적인 산문이 필요하다는 신호를 보낼 수도 있다.문단 휴식을 취하는 것을 두려워하지 마라.

여기에 그 단락을 마지막으로 찌르는 것이 있다.나는 그 주제에 대해 아무것도 모르기 때문에, 감히 광범위하게 다시 쓰거나 확대하려고 하지 않는다.

콘라드는 아이슬레벤에서 견습생으로 고향을 떠났고, 이후 뒤미츠(메클렌부르크)에서 뮌즈워딘을 지냈다.^[16][17]1683년 뮌즈메이스터(Münzmeister)를^[18] 란 강 크렘베르크에 있는 나소홀자펠 공주로 임명하였다.그는 1687년 프리드베르크에서 독일 기사단과 함께 뮌즈마이스터가 되었다.마침내 1692년 그는 아샤펜부르크에^[2][7][19] 있는 마인츠 대주교와 선거인단을 위해 뮌즈마이스터로 승격되었다.

그것은 확실히 어느 정도 개선될 수 있지만, 현 시점에서 나는 각주 연결이 중요한 양식적 문제라고 생각하지 않는다.나는 각주 syle이 문제로 인식되는 많은 상황들이 현명한 편집으로 교정될 수 있을 것이라고 생각한다.이것은 기술적으로 사고방식이 있는 사람들이 독자들에게 우리의 자료를 다르게 볼 수 있는 선택권을 주지 말고, 오히려 우리가 잘 쓰고 신중하게 써야 한다는 우리의 편집자들에게 주의를 주어야 한다는 것이다.TenOfAllTraes(대화) 15:33, 2008년 11월 7일 (UTC)[응답]

모든 좋은 점.시각적 영향을 줄이기 위해 우리가 할 수 있는 또 다른 방법은 연속된 음의 문자열을 하나의 노트로 통합하는 것인데, 이것은 실행 중인 텍스트의 갭 토치 모양을 줄이고 노트 목록을 단축시키는 것이다.나는 어떤 인쇄물 출판물도 우리가 하는 것처럼 여러 개의 참조 번호를 함께 묶는다고 생각하지 않는다.—마이클 Z. 2008-11-07 16:19 z

생각할 거리야, 고마워.기사의 각주를 보면 이미 세 개의 별도 참조를 하나의 각주로 통합하고 있다.각주 링크를 문장 끝으로 이동:내가 잘못 알고 있을지도 모르지만, 나는 당신이 정보의 항목과 관련된 곳에 각주를 붙인다고 생각했다.따라서 나는 문장의 끝에는 없고, 아이슬레벤 바로 뒤에 각주를 달았다. 왜냐하면 그 각주는 문장 전체가 아니라 그 정보 항목만을 확증하기 때문이다.

글머리표와 시간표, 나는 그것들이 좋은 글이라고 여겨지는지 잘 모르겠다.

그러나 나는 몇몇 문제들이 현명한 편집과 개혁으로 개선될 수 있다는 것에 동의한다.-좋은 아침 세상 (토크) 17:04, 2008년 11월 7일 (UTC)[응답]

글머리표 리스트에 대한 나의 요점은 글머리표 리스트가 이 예에서 산문보다 더 낫다는 것이 아니라, 이 단락이 정말로 산문으로 가장한 글머리표 리스트에 불과하다는 것이었다.부풀려진 CV가 반드시 전기 기사에 원하는 형식은 아니라는 데 동의하지만, 총알을 제거하고 같은 텍스트를 문단에 넣는 것도 좋은 글이라고 가장해서는 안 된다.(상관님, 우리도 전자 매체에서 어느 정도 추가적인 유연성을 누리고 있다는 것을 알아야 하며, 우리는 그렇게 할 수 있다.소재가 보다 명확하고 효과적으로 표현될 수 있도록 도움을 준다면 비물질적 요소를 현명하게 사용할 수 있다.)

각주 배치는 판단의 문제로서, 나는 노트를 옮길 때 주의해야 한다는 것에 동의한다.그럼에도 불구하고, 나는 "1978년에 밥이 그린그로서로 일했던 뉴욕으로 이사했다"^[1][2]라는 문구를 따라 뭔가를 쓰는 것이 불합리하다고 생각하지 않는다. 여기서 노트 1은 밥이 뉴욕으로 이사한 날짜를 알려주고 노트 2는 그의 직업에 대한 정보를 제공한다.(문장의 끝에서 각주가 이치에 맞지 않으면, 때로는 문장이 너무 많은 것을 이루려고 한다는 것을 나타낼 수도 있다.)각주는 자신이 지지하는 문장에 근접한 것이어야 하지만 문장의 정확한 단어에 맞춰져야 하는지 여부는 문맥에 따라 달라진다.TenOfAllTraes(대화) 17:36, 2008년 11월 7일 (UTC)[응답]

(ec)다른 출판된 참조 작품들은 모두 이와 같은 작은 스타일 트윗으로 변함없이 절정을 이루는 진보적인 글쓰기 및 편집 과정을 따른다.그것은 위키피디아와 같은 역동적인 프로젝트에서는 불가능하며, 어떤 기사도 "완료"되지 않고 따라서 "최종적인 스타일의 트윗"도 가능하지 않다.특히 위키텍스트에서 참고문헌을 결합하는 것은 믿을 수 없을 정도로 멍청한 짓이다: 기사를 편집하고 재편성할 때, 문구를 따로 옮기고 내용과 출처를 모두 추가하거나 제거하면 어떻게 되는가.이러한 지속적인 개선 과정을 용이하게 하기 위해 사실들은 그들의 참고자료와 함께 보관되어야 하며, 참고자료들은 그들이 확증하는 사실들만큼 별개의 것으로 보관되어야 한다.우리는 결코 내용보다 스타일을 우선할 수 있는 위치에 있지 않을 것이다.결코 출력 참조가 지금과 같이 분리되고 명백한 방식으로 렌더링할 필요가 없다고 말하는 것은 아니다 - 나는 인용 시스템을 일부 수정하여 참조의 '블록'을 감지하고 하나의 통일된 참조 섹션에 렌더링하는 것에 강력히 찬성한다(따라서 모든 참조 링크는 하나의 괄호 안에 포함됨).. CSS3 및/또는 JS를 통해 가능할지 모르지만, 내 생각에는 기반 MediaWiki 확장의 변경이 필요할 것 같다.그러나 우리가 기초 코드에 예쁜 렌더링을 적용하기 위해 어떤 방법을 사용하든, 그 코드는 쉬운 수정, 재구성 및 변경을 용이하게 하면서 콘텐츠의 검증가능성을 쉽게 유지하는 데 주로 초점을 두어야 한다.해피멜론 17:48, 2008년 11월 7일 (UTC)[응답]

로블록스

게임 속 정보를 담고 있는 'IT와 관련된 다른 페이지'(게임 리뷰 사이트 제외)와 위키(ROBLOX Wiki)는 정보가 거의 없고 편집이 불가능하기 때문에 위키백과의 방대한 영상에서 로블록스라는 페이지가 만들어져야 한다고 진지하게 생각한다.그러니까 만들어줘.NHL09addict (대화) 03:54, 2008년 11월 8일 (UTC)[응답]

위키피디아 콘텐츠는 어떤 주제에 관심이 있는 사용자들이 해당 콘텐츠에 대한 기사를 쓸 수 있도록 만들어진다.당신은 주제에 관심이 있고 기사를 만들 수 있는 기술적 능력을 가진 그런 사용자일 뿐이다.위키백과를 참조하십시오.첫 번째 기사.또는 다음 웹 사이트를 방문하십시오.위키프로젝트 비디오 게임/요청서/누군가 그 일을 맡을 것이라는 보장은 없지만, 창작요청서를 제출한다.--Fuhgetaboutit (대화) 11:35, 2008년 11월 8일 (UTC)[응답]

위키백과 참조:삭제/Roblox용 문서.기사를 만들 만한 믿을 만한 출처가 없다는 것이 지난 5월 결정됐다.일부 문서를 찾을 수 있는 경우, 자신의 User Space에서 기사를 작성하고, 해당 기사가 황금 시간대에 준비되었다고 느끼면 WP에 기록하십시오.DRV. 리틀 레드 라이딩 후드토크 01:53, 2008년 11월 9일 (UTC)[응답]

실시간 대 턴 기반 게임 플레이 삭제

그래서 나는 실시간 대 턴 기반 게임 플레이는 하루빨리 삭제되어야 한다고 생각한다.기사 전체가 의견으로 가득 차 있다(턴 기반 게임은 숙달하기 어렵고, 턴 기반 게임은 앉아서 턴이 끝나기를 기다리는 것은 지루한 일 등).그렇다, 그것은 많은 출처를 가지고 있지만, 의견의 출처를 갖는 것은 의미가 없다.그리고 이 기사는 위키피디아에는 들어맞지 않고, 이미 실시간 게임과 턴 기반 게임 기사가 존재하는데, 왜 이 두 기사를 하나의 기사로 비교해야 하는가?--Megaman en m (토크) 00:11, 2008년 11월 9일 (UTC)[응답]

기사를 삭제해야 한다고 생각되면 WP:AfD에 기재해야 한다. -- 임페라이터3733 (토크) 00:16, 2008년 11월 9일 (UTC)[응답]

고마워, 길을 찾을 수가 없었어.-메가만 엥 엥 므 (토크) 00:16, 2008년 11월 9일 (UTC)[응답]

신규제안정책방향

많은 지역사회 구성원들이 현재의 정책에 강하게 반대한다.우리는 위키미디어 프로젝트의 주연을 커뮤니티 드래프트와 함께 하기 위해 언어 기준의 수정을 제안하고 있다.자유롭게 의견을 제시하십시오.

정말이지, 정말이야.— Crazymadlover—준비 미결 코멘트가 2008년 9월 25일 (UTC) 20:56에 추가되었다.[답답하다]

해상도 외에 이미지의 크기를 조정하십시오.

Freenode/#wikipedia <KordeX> 안녕하십니까, 이미지 핸들링에 대한 제안이 있는데, 16:9와 같은 크기에서 자동으로 척도를 계산하는 것이다.그것은 HeightxWidth 바로 옆에 페이지 페이지에 표시될 것이다. 이것은 기지에 매우 쉬운 패치다.(미코 코텔라이넨)—87.93.143.223 (대화) 22:38, 2008년 10월 2일 (UTC)[응답]에 의해 서명되지 않은 논평 준비

모금 배너에 댓글 달기여부

이곳 현지 엔위키가 이를 바꿀 수 있을지 모르겠지만 기부자들의 댓글이 포함돼 있어 지난해 모금 현수막이 정말 마음에 들었다.여기서 볼 수 있듯이, 누군가가 온라인으로 기부를 할 때, 그들은 위키백과/미디어에 대한 코멘트를 남길 수 있다.지난해 모금 배너에는 대본이 있어 페이지를 새로 고칠 때마다 임의의 댓글이 달렸었다.나는 이것이 기부자들을 끌어 모으는 데 도움이 되었다고 생각한다. 그리고 가능하다면 우리는 이것을 다시 포함하도록 배너를 바꿔야 한다.레이와스92^Talk 02:29, 2008년 11월 10일 (UTC)[응답]

그것은 분명히 우리가 지금 가지고 있는 터무니없이 거대한 것 보다 개선될 것이다.2008년 11월 10일(UTC) 18시 5분 셀라노르[응답]

작년 현수막도 더 마음에 들었다.올해의 배너를 왜 이렇게 터무니없이 크게 만들었는지 아는 사람 있어? -- 임페라이터3733 (토크) 23:08, 2008년 11월 10일 (UTC)[응답]

기본 정책 추가

위키피디아에 기능적으로 더 추가하는 것이 가능한가?아마도 많은 사람들이 행사에 동의하지 않고 위키피디아가 당론을 취하는 경우가 있을 것이다.이것의 한 예는 TWA 800 충돌이다.

분명히 나는 TWA 800 추락사고에 대한 정부의 입장을 수용하는 당신의 정책에 동의하지 않지만 나는 그 점을 주장하기 보다는 다른 의견을 불러일으키는 주제에 대한 논의가 이루어질 수 있는 과정을 설정하기 위해 논쟁하기로 선택했다.현재 당신은 대안 이론 페이지를 제공하지만 이것은 대안적 사고의 포스팅이 된다.우리가 필요한 것은 새로운 방향으로 이어질 수 있는 근거 문서와 함께 격리된 사실의 적극적인 나열이다.

아리드베르크 (대화) 21:23, 2008년 11월 5일 (UTC)[응답]

WP:NPOV가 답변이 될 것이며, 특히 WP:NPOV#Undu 중량."주당노선"을 취하는 것은 그것이 믿을 만한 소식통에 의해 가장 받아들여지고 가장 검증 가능한 것이기 때문이다.당신이 제안하는 것은 우리가 그 사실을 받아들이고 그것들을 우리 자신이 도달한 결론으로 속단하기 위해 사용하자는 것인데, 이것은 또 다른 정책인 WP: 독창적인 연구는 하지 않는다는 것이다.이러한 정책 중 하나를 구체적으로 언급하려면 해당 정책의 대화 페이지를 방문하여 토론을 시작하십시오.그러나 나는 당신에게 다음과 같이 경고한다.당신의 요청은 들어줄 것 같지 않다. --Izno (대화) 21:32, 2008년 11월 5일 (UTC)[응답하라]

그렇다. 또한, 위키피디아는 그러한 접근방식이 시사하는 것 중 적지 않은 것이다. 특히 비누 상자나 토론 포럼이 아니다.우리의 정책은 "정부의 입장을 수용하는 것"이 아니다.중립적인 관점을 반영하기 위해서다.소수의견이 그 주제에 유의하다면, 그것은 아마도 언급되어야 하고, 그렇게 식별되어야 한다.

아리드버그가 제안하는 것은 5대 기둥으로부터의 급진적인 이탈이며, 아마 별로 설득력을 얻지 못할 것이다.—마이클 Z. 2008-11-05 22:02 z

위키피디아는 프린지 이론을 허용했지만, 우리는 지금 립서비스만 한다. 하지만 이것은 정확히 당신이 생각하는 것과 같지 않다.당신이 제안하는 것은 백과사전의 목표의 일부가 아닌 독창적인 연구를 위한 포럼에 가깝고, 그런 점에서 우리가 할 수 있는 일은 아닐 것이다.셀라노르 22:06, 2008년 11월 5일 (UTC)[응답]

TWA Flight 800 대체 이론 관련 기사 읽어 보셨어요?여기에 각각에 대한 비판적 분석과 함께 8개의 이론이 나열되어 있다. ---- Gadget850 (Ed) - 16:09, 2008년 11월 12일 (UTC)[응답]

대화 페이지의 새 탭 제안

기사에 포함될 수 있는 잠재적 출처 리스트에 대한 기사에 대해서는 토크페이지에 새로운 탭(예: "프로젝트 페이지", "토론", "역사", "이 페이지 편집" 등)을 추가할 수 있을지 궁금했다.과거에는 내가 직접 기사에 담을 시간이 없었기 때문에 우연히 마주치는 뉴스들을 기사의 토크 페이지에 올린 적이 있다.종종, 그것은 보관되고 아무도 그것이 존재하는지 알지 못한다. 왜냐하면 그들은 기록 보관소에서 찾을 가능성이 낮기 때문이다.나는 또한 수많은 다른 편집자들이 (기록보관소와 별도 표제 아래) 토크 페이지의 다양한 부분에 있는 잠재적 출처를 나열하는 것을 보았다.그러나, 만약 우리가 "기사에 사용될 소스"(더 나은 이름은 의심의 여지 없이 찾을 수 있음)를 위해 토크 페이지 내에 별도의 탭을 가지고 있다면, 편집자들은 그들이 생각하기에 한 곳에 기사에 통합되어야 한다고 생각하는 믿을 만한 출처를 올릴 수 있다.이 페이지는 웹사이트, 책, 저널, 비디오 등의 잠재적인 출처 목록일 뿐이기 때문에 (일반적인 대화 페이지에서 재개될 수 있는) 토론이 필요 없을 것이다.그러면 편집자들은 재빨리 이 탭으로 가서 기사에 포함할 출처를 찾을 수 있을 것이다.출처가 기사에 통합됨에 따라, 다른 편집자들에게 그들의 포함을 경고하기 위해 체크아웃될 수 있다.게다가, 만약 누군가가 그 기사에 걸려서 그것을 개선하고자 한다면, 그것은 시작하기에 좋은 틀을 제공할 것이다.

코딩이 얼마나 걸릴지, 서버에 부담이 될지는 잘 모르겠지만 백과사전이 계속 성장함에 따라 선을 긋기보다는 지금 제안하고 싶었을 뿐이다.탭은 "이 페이지 기록"/"편집"처럼 독립적으로 서 있거나, 대화 페이지 내의 별도의 탭일 수 있다(Talk:Arctlename/Source).나는 이것이 페이지를 복잡하게 만들 것이라고 생각하지 않는다. 그리고 새로운 탭이 만들어질 수 없다고 해도, 누군가는 무작위로 분리된 표제보다는 모든 잠재적인 출처를 나열하는 다른 방법을 생각할 수 있을 것이다.신뢰할 수 있는 출처를 포함하여 계속 강조함에 따라, 많은 잠재적 출처를 나열하는 중심 영역이 현재 기사를 확장하고 소싱하는 데 도움이 될 것이다. --Nehrams2020 (토크) 23:50, 2008년 11월 10일 (UTC)[응답]

• 또는 추가 읽기 섹션을 만들 수도 있다.G 삼촌 (토크) 2008년 11월 11일 (UTC) 15:53[응답]

토크 페이지의 작업관리 목록에 포함시킬 수 있다. ---- Gadget850(Ed) - 15:57, 2008년 11월 12일(UTC)[응답]

내가 들은 것 중 최악의 생각은 아니지만, 나는 방울과 휘파람을 추가하는 것을 반대하기 때문에 반대한다.나는 정말 중요한 일들만 제도화되어야 한다고 생각한다."이 페이지 편집" 탭이 필요하며 "토론" 페이지와 "이력" 페이지에 대한 링크도 매우 중요하다.이 특징은 그 정도의 중요도는 아니다.새로운 편집자들은 이미 충분한 잡동사니에 직면해 있다.우리는 사람들을 끌어들이려고 하는 것이지 그들을 당황하게 하는 것이 아니다.2008년 11월, 라라오우.

오브트레이싱 배너

나는 숨기기 링크를 클릭한 후 문자 전용 메시지로 변경되도록 현재의 기금 모금 배너를 변경할 것을 제안한다.이 사이트를 개선하고 이곳을 계속 운영하기 위해 여가를 기부하는 사람들은 이미 그 눈에 띄지 않는 숨길 수 없는 현수막 때문에 점점 더 화가 나고 있다.많은 편집자들은 그것을 그들의 노고에 대한 무감각한 감상 부족이라고 본다.위키백과를 참조하십시오.좌절감을 느낄 수 있는 기기/제안!그러나 논의 없이 온라인에 기기를 숨기고 사용자 인터페이스 시스템 메시지를 추가하는 배너로 포인트를 만드는 대신 여기서 집중적이고 개방적인 토론을 보고 싶다.Cacycle (대화) 2008년 11월 7일 15시 30분 (UTC)[응답]

그것들을 바꾸는 것은 우리에게 달려 있지 않고, 기금 모금을 하는 사람들에 의해 변화가 풀릴 것 같다.이 토론을 원하신다면 메타(Meta)에서 진행하십시오.Talk:2008/설계 초안 작성, 여기에 기재하지 않음 - en.위키백과 커뮤니티에는 배너에 대한 직접적인 통제가 없다. - Rjd0060 (대화) 15:41, 2008년 11월 7일 (UTC)[응답]

고맙게도, 그 기기(IAR, 긴급 조치라고 부르든 뭐든 간에, 그것은 분명히 절실히 필요했다; 그것을 제거하는 것은 아마도 등록된 사용자들을 위해 좋은 생각이 아니었다)는 것은 그것을 없앨 수 있었다.나는 이 시점에서 무엇이 문제인지 잘 모르겠다.셀라노르^{Talk to me} 20:14, 2008년 11월 7일 (UTC)[응답]

그것은 그렇게 하는 각 사용자에 의해 활성화되어야 하며, 그렇게 함으로써 그들은 이미 그것을 봤다는 것을 표시했다 - 심지어 사무실의 관점에서도 나는 솔직히 그것의 해로운 점을 보지 못한다.오더인차오스 00:59, 2008년 11월 8일 (UTC)[응답]

나는 웹사이트들이 그들의 페이지에 큰 난해한 배너를 덧붙이는 것에 약간의 음모가 있다고 생각한다: last.fm은 IP의 국가를 탐지하기 위해 큰 광고, 유튜브를 추가했고, WP는 큰 공지를 했고, WP는 기금 모금을 했다.O_o -- Mentisock 10:08, 2008년 11월 8일 (UTC)[응답]

이와 관련, 선호도에서 '이미 기부했으니 이제 내 얼굴에서 나가라'는 박스를 체크하면 향후 모금 배너를 억누를 수 있을까.나는 그것만 두려워하며 극도로 꺼려 왔다.만약 다음 광고에 영향을 미치지 않는다면, 나는 분명히 광고의 거대한 괴물을 도끼로 칠 수 있기를 바란다.Mr^talk Zaius 09:44, 2008년 11월 13일 (UTC)[응답]

위키백과 문서 공유

많은 온라인 신문들이 페이스북, 마이스페이스 등에 관심 기사를 게재하는 것은 물론 친구에게 기사를 보낼 수 있도록 허용하고 있다.나는 이것이 위키피디아에도 도움이 될 것이라고 믿는다.감사합니다.

위키피디아 기사를 페이스북이나 마이스페이스에 올리는 것(모든 글을 직접 쓰지 않는 한)은 일반적으로 저작권 위반이 된다. - 2008년 11월 12일 (UTC)[응답]

어떻게? 위키피디아의 라이센스는 위키피디아가 인정받는다면 자유롭게 배포될 수 있도록 해준다.이것은 전에도 몇 번 여기에 올라온 적이 있는데, 나는 반대할 이유가 없다.다른 이들은 불필요하고 직접 기사를 공유하는 것이 어렵지 않다고 말했다.레이와스92^Talk 18:57, 2008년 11월 12일 (UTC)[응답]

나는 기사 링크를 공유하는 것이 전체 기사를 공유하는 것을 허용하는 것보다 훨씬 더 나을 것이라고 생각한다.이렇게 하면, 더 많은 사람들이 웹사이트에 온 후에 그 기사를 읽고 심지어 백과사전에 기고하도록 격려할 수 있다.현재 나는 FA에게만 이 기능이 있다고 생각한다. 각 기사의 링크가 그렇게 하는 것이 좋을 것이다. --GPPandetalk! 2008년 11월 12일 (UTC)[응답]

GPPANDE에게 그렇다.

Reywas92, 위키백과만 믿고 있는 것은 충분하지 않으며, 페이스북이나 마이스페이스에서는 일어나지 않을 GFDL 면허도 게시해야 한다. - JmabelTalk 20:27, 2008년 11월 12일 (UTC)[응답]

나는 마이스페이스에 대해 잘 모르지만, 페이스북에서는 기사에 대한 링크만 공유하고 있는데, 그건 문제가 되지 않을 거야.레이와스92^Talk 21:03, 2008년 11월 12일 (UTC)[응답]

나는 실제적으로 GFDL에 링크만 올리면 되는 것이지 전문을 올리면 되는 것은 아니라고 생각한다; 페이스북과 마이스페이스에서는 충분히 가능한 일이다. --Tagishsimon (대화) 01:34, 2008년 11월 13일 (UTC)[응답]

사용자:gppande는 기사에 연결만 해야 하는 몇 가지 중요한 이유를 지적하지만, 완벽하게 분리가 가능한 중간지대를 지적하고 싶다.인쇄 가능한 버전의 기사 전체를 GFDL 링크가 있는/Iframe에 포함시키려 하는 모든 사이트에 기사 전체를 넣으십시오.그렇게 하면 동적으로 업데이트되지만, 동적으로 업데이트되는 동일한 라이센스 링크가 있다.Mr^talk Zaius 09:37, 2008년 11월 13일 (UTC)[응답]

해당 사이트는 회원 게시 정보에 대한 사이트 소유자의 권리를 주장하는 최종 사용자 동의서를 가지고 있는가?만약 그렇다면, 위키피디아의 GFDL은 위키피디아의 텍스트를 게시하는 것을 허용하지 않을 수도 있다. 물론 기사에 대한 링크에는 문제가 없다.—마이클 Z. 2008-11-14 16:25 z

관리자가 자동 확인 상태를 부여할 수 있도록 허용

나는 이것의 기술적 타당성을 확신할 수 없지만, 관리자들이 계정을 자동 확증된 것으로 표시하도록 허용하는 것에 대해 사람들은 어떻게 생각하는가?내가 최근에 지독한 BLP 위반으로 인해 페이지를 반보호했기 때문에 물어본다.그럴 때, 나는 또한 선의의 IP 기고자를 차단했다.I.P.가 보호 페이지를 즉시 편집하도록 허용하고 싶다. 예를 들어, 내가 즉시 자동 확증이라고 플래그를 지정하는 계정을 만들도록 하는 등. 하지만, 나는 현재 이것을 할 수 없다.생각?비꼬는 자살주의자 (토크) 2008년 11월 12일 (UTC) 19:15, 응답

자동 확인된 지위를 부여하는 방식(주로 누구에 의해서도 취소할 수 없다는 것)이 사용자 권리로 변하기 어렵게 만드는 것이라고 생각한다.개발자는 아마 더 잘 알 것이다.MBisanz 19:18, 2008년 11월 12일 (UTC)[응답]

기술적으로, 오토콘 확증권이 있는 다른 그룹을 만들 수 있고, 관리자가 해당 그룹을 할당하거나, 오토콘 확증 그룹을 할당할 수도 있다. -Steve Sanbeg (대화) 20:52, 2008년 11월 12일 (UTC)[응답]

"수동 확인"과 같은 그룹을 만드는 것은 기술적으로 가능할 것이고 꽤 쉬울 것이다. 자동 확인과 같은 모든 권한을 가지고 있었다. 개발자들은 여기와 같은 곳에서 합의를 본 후에 그것을 추가할 것이다.그리고 그 아이디어 또한 지지한다. 비록 그것이 많이 쓰일지는 모르겠지만. --ais523 21:58, 2008년 11월 12일 (UTC)

이것은 좋은 생각이고, 나는 "수동적으로 확인된" 집단에 대한 ais523의 생각을 지지한다.{{Nihiltrestalk log}}} 23:16, 2008년 11월 12일 (UTC)[응답]

좋은 생각이지만, 나는 약간 더 짧은 이름인 DendodgeTalk^Contribs 23:21, 2008년 11월 12일 (UTC)[응답하라]을 제안한다.

"manconf"는 어때? ;-) 좋은 제안 btw :-)

한편, 계정이 자동 확인 상태에 도달하면 자동으로 그룹을 제거하도록 소프트웨어가 스크립트로 작성되어야 한다. 그렇지 않으면 필요 없는 모든 수동 확인 계정을 정리할 관리자(admin-bot)가 필요하다.SoWhy 23:29, 2008년 11월 12일 (UTC)[응답]

기술적으로 우리는 $wgImplicitGroups 어레이에서 자동 확증된 것을 얻을 수 있다고 생각한다.펑피카 23:31, 2008년 11월 12일 (UTC)[응답]

나는 어렴풋이 이것이 "어느 곳"에서 이미 논의 중이거나 논의되고 있었다는 것을 기억한다.

어쨌든, 만약 이것이 활성화된다면(나는 반대하지 않을 것이라고 생각한다) 우리는 오토콘 확증 제거의 역방향도 가능하다고 가정해야 하는가? - jc37 01:51, 2008년 11월 13일 (UTC)[응답]

예, $wgImplicitGroups에 더 이상 포함되어 있지 않으면 승인 가능하고 분리할 수리가 가능함.셀라노르 08:18, 2008년^{Talk to me} 11월 13일 (UTC)[응답]

당신은 그것을 없애고 싶지 않을 것이다.당신은 이것이 3중국이 되기를 원할 것이다.On/Off/금지 - 자동 인증을 해제한 다음 관리자의 검토 없이 자동으로 다시 수행되도록 허용할 이유가 거의 또는 전혀 없음."X 편집은 확증된 상태를 얻기에 충분하지만, X+1 편집에서 망쳤기 때문에 2*X는 이 사람에게 필요하다." MrZaius^talk 09:40, 2008년 11월 13일 (UTC)[응답]

탈부착이 나쁜가?블록에서 한 발짝 물러나 주제 금지를 시행하는 데 도움이 될 수 있다. --Nate1481 09:49, 2008년 11월 13일 (UTC)[응답]

그것이 어떻게 그러한 금지를 시행하는 데 도움이 될까?반보호 기사는 자동 확인 상태 없이 편집자를 잠그기 위한 것으로만 보호 정책에 위배된다.그리고 설사 그것이 어쨌든 반보호되어 있다 하더라도, 그렇다면 이런 식으로 금지를 강행할 이유가 없다.주제 금지는 사람들이 다른 모든 사용자들처럼 프로젝트의 다른 부분에서 일할 수 있도록 하는 것이다.주제 금지를 시행하기 위해 오토콘을 제거하면 관련이 없지만 반보호적이거나 이동할 필요가 있는 기사에서 작업할 수 있는 능력이 무력화되므로 주제 금지에 대한 어떠한 이유도 실질적으로 제거될 수 있다.

그렇긴 하지만, 나는 $wgImplicitGroup 변수에서 오토콘 확증을 제거하는 것은 좋은 생각이 아니라고 생각한다. 왜냐하면 그것은 또한 우리가 기준을 충족하는 수천 명의 새로운 편집자들에게 이 지위를 할당하는 새로운 수동 방법을 만들어야 한다는 것을 의미하기 때문이다.어떻게 될까?관리봇이 지속적으로 권한을 변경하시겠습니까?아니면 코드를 다시 작성해서 자동이지만 허가 가능한 코드를 만들까?소프트웨어가 계정을 자동 확인으로 업그레이드하면 자동으로 제거되는 새 사용자 그룹을 만드는 것이 더 쉽지 않을까?SoWhy 11:00 2008년 11월 13일 (UTC)[응답]

기술적 측면에 대해서는 잘 모르겠다. 단지 주제 금지에 대한 나의 생각을 명확히 하기 위해서, IP와 양말 역시 그것들 때문에 금지되는 주요 기사들은 이미 반비보호되어 있는 것이지, 그 사용자를 차단하기 위한 반보호 기사가 아니다. --Nate1481 11:23, 2008년 11월 13일 (UTC)[응답]

암묵적 그룹 목록에서 제거한다고 해서 분리할 수 있는 것은 아니다.자동 홍보 그룹은 그런 식으로 일하지 않는다.수동으로 허가된 사용자로부터 수동으로만 제거할 수 있으며, 사용자가 오토콘펌웨어 요구 사항을 충족하지 않는 경우에만 실제로 그룹에서 제거할 수 있다.스페셜에 나올 겁니다.사용자 권한, 그러나 사용자가 수동으로 권한을 부여하지 않는 한 실제 자동 확증 여부에 관계없이 선택 해제된다.하지만 누군가가 AusciFilter와 TorBlock이 작동하는 방식과 유사한 수동 오토콘펌프 제거를 위한 확장자를 쓸 수 있을 것이다.Mr.Z-man 23:16, 2008년 11월 13일 (UTC)[응답]

IP에 계정을 만들도록 요청하십시오.=Nichalp«Talk »=10:42, 2008년 11월 13일 (UTC)[응답]

요점은 계정을 생성한다고 해서 자동 확인 상태가 즉시 계정에 전송되지 않아 향후 며칠 동안 IP가 동일한 상태로 유지된다는 것이다.그래서 왜 2008년 11월 13일 (UTC)[응답]

4일, 10개 편집, 1개 확인 이메일 아이디.그리 길지 않은 IMO. =Nichalp «Talk »=11:39, 2008년 11월 13일 (UTC)[응답]

위키백과에서 새로 만든 사용자들의 토크페이지로 자동화된 메시지가 있어야 한다고 생각한다.현재 이 메시지는 훌륭한 위키피디아가 수동으로 게시하고 있다.그 메시지에는 위키백과의 일반적인 안내서와 편집 방법이 포함되어야 한다.메시지 하단에는 사용자가 자동 확인되지 않아 여전히 접근 불가능한 글에 대한 설명이 적어야 한다.사용자는 이 시간을 이용하여 기본적인 WP:정책들을 살펴보고 이해하여 일단 자동 확인되면 올바른 사고방식을 가질 수 있다.만약 사용자가 WP에 대해 진지하고 자신을 돕고 공동체에 더 잘 봉사하고 싶다면, 그는 분명히 그것을 좋아하고 따를 것이다.자동 확인은 모든 진지한 편집자가 멋지게 합격할 수 있는 작은 운전 시험이다.보관하는 데 해롭지 않지만 제거하면 많은 소중한 물건들이 사고를 당할 수 있다. --GPPande talk! 2008년 11월 13일 (UTC) 14:23, 답변

오토콘 확증은 그들이 편집한 것에 대해 최소한 약간의 검토를 할 수 있을 정도로 충분히 존재했다는 것을 보여주는 것으로 여겨진다; 당신이 이미 알고 있는 누군가가 오토콘 확증을 받기 위해 며칠 동안 그들이 하고 있는 일을 멈추게 하는 것은 그것의 정신에 반하는 것처럼 보인다; 누군가가 그들의 초기 시간/편집 수를 어떤 이유로 설정함으로써 그들을 보증할 수 있다면 좋을 것이다.개발 작업이 필요하지만 계속 진행할 수 있도록 가치를 부여한다. -Steve Sanbeg (대화) 21:08, 2008년 11월 13일 (UTC)[응답]

그럼 편집 카운트와 등록 시간이 영원히 틀릴 수 있다는 거야?Mr.Z-man 23:16, 2008년 11월 13일 (UTC)[응답]

그것은 네가 그들의 말을 무슨 뜻으로 하느냐에 따라 달라진다.만약 그것이 한 사람을 의미한다면, 그렇다, 만약 익명으로 편집하는 사람이 있다면, 적어도 이 변화는 그것을 조금 더 정확하게 만들겠지만, 아마도 영원히 틀렸을 것이다.만약 그들이 데이터베이스 항목이라면, 기술적으로 이것은 편집자들이 이름보다 그 사람과 더 많이 연관되도록 만들 것이고, 따라서 더 잘못될 것이다.그러나 나는 가장 심한 편집카운트염에 걸린 사람일지라도 등록 전에 편집한 몇 개(예: 10개)를 가진 사람이 작업 중인 것을 방해하지 않도록 하는 것에 대해 크게 걱정하지 않을 것이라고 예상한다.이 방법뿐이 아니라 수동으로 자동 확인 후 나중에 추가 확인을 제거해야 하는 것보다 사용자를 확인하는 정신으로 보인다. -Steve Sanbeg (대화) 00:13, 2008년 11월 14일 (UTC)[응답]

IP에서 편집하지 않았다면?그들은 다른 프로젝트에서 존경받는 사용자가 될 수 있다.아니면 만약 그들의 IP 편집이 같은 IP에 있는 다른 사람들의 IP 편집과 섞여 있다면?나는 단지 왜 우리가 다른 상황에서 데이터베이스 오류로 보일 수 있는 것을 의도적으로 소개해야 하는지 모르겠다.Mr.Z-man 17:36, 2008년 11월 14일 (UTC)[응답]

이 아이디어는 별로 좋아하지 않는다.반보호에 의해 망쳐지는 선의의 IP의 예시 시나리오는 이 제안의 영향을 전혀 받지 않는다; 우리는 익명의 사용자를 사용자 그룹에 할당할 수 없다. (좋은 편집자의 IP에 권한을 할당하는 재미는 반달로 동적으로 스왑할 수 있을 뿐, 좋은 시절!)자기확인을 위한 요구조건이 너무 낮아서 나는 우리가 왜 누구에게 권리를 부여해야 하는지 모르겠다.EVula // talk // talk // 21:19, 2008년 11월 13일 (UTC)[응답]

너무 늦게 브리온은 어젯밤 이 목적을 위해 "Uploader" 그룹을 만들었고, 그는 아직 어떤 박(관리인 또는 크래트)이 그것을 줄 수 있는지 할당하지 않았지만, Stewards는 그것을 허락할 수 있다.MBisanz^talk 21:21, 2008년 11월 13일 (UTC)[응답]

19:15 12 11월 12일부터 21:19 13 11월...토론할 시간이 너무 많아서 다행이다.:) EVULA/// talk // 21:23, 2008년 11월 13일 (UTC)[응답]

업로더는 파일 업로드를 위한 추가 권한을 부여하는데, 이 스레드는 수동으로 확인되는 경우 다른 사람이 반보호된 페이지를 편집할 수 있도록 허용하기 위한 것이다.이 토론과 저 그룹의 중첩은 보이지 않는다. -스티브 산베그 (대화) 00:16, 2008년 11월 14일 (UTC)[응답]

음, 이전에 비슷한 논의에 대해 언급했던 것 같은데, 특히 남용 필터의 자동 확증된 상태 취소 능력과 그에 따른 재확인의 필요성을 고려할 때, 이것이 바람직하고 실현 가능한 것일 수 있다.우리는 ''autopromote override시스템이 있을지도 모른다.— Werdna • talk 13:27, 2008년 11월 14일 (UTC)[응답]

며칠 전 새 봇 계정이 보관해야 할 반보호 페이지를 편집할 수 없을 때 이 기능이 필요했다.봇 깃발을 부여하면 이 문제가 제거되지만 시험 기간에 봇에는 깃발이 주어지지 않는다.나는 결국 반달리즘의 한 사건은 제쳐두고 지금까지 작동해 온 페이지의 보호를 없앴지만, 나는 계정을 자동 확인하는 방법이 필요하다고 생각한다.~ 사용자:아멜리오라테! 2008년 11월 15일 04:43 (UTC)[응답]

주석 미리 보기

MediaWiki는 "이것은 미리보기일 뿐이며, 당신의 변경사항은 아직 저장되지 않았다는 것을 기억하라!" 등을 넣을 수 있다.보통 페이지 밖에서?미리보기이기 때문에 통지가 항상 레이아웃을 약간 변경하기 때문에 사용자에게 페이지가 어떻게 보일 수 있는지 절대적으로 진실된 버전을 보여주지 않는다.수정된 페이지를 원본과 비교하기 위해 수정하지 않고 다시 페이지를 미리 보아야 한다. -- 2008년 11월 14일 (UTC)[응답]

미리보기에는 섹션 편집 링크도 생략되어 있어서 묶음인지 아닌지 구별할 수 없다.대수학자 12:11, 2008년 11월 14일 (UTC)[응답]

네, 그리고 방금 기억난 또 하나 있는데, (실제 미리보기된 페이지가 아니라 편집창에서) 대체품을 처리하지 않는다는 겁니다.그것은 페이지를 진정으로 구문 분석할 때만 다루기 때문일 수 있지만, 대체된 템플릿은 페이지를 먼저 저장하지 않고는 실험할 수 없기 때문이다. -- 멘티소크 13:35, 2008년 11월 14일 (UTC)[응답]

편집 알림에 대한 지침

Wikipedia_talk를 참조하십시오.Editnotice#Guidelines_for_editnotes. 여기서 편집자 사용에 대한 지침을 만들 것을 제안한다.세나리움 22:23, 2008년 11월 14일 (UTC)[응답]

사이드바 맨 위로 검색 상자 이동

추가 투입을 모색한다.다음 내용을 참조하십시오.

• 미디어위키 대화:사이드바#탐색 위로 검색 상자 이동 --타임시프터(대화) 04:32, 2008년 11월 15일(UTC)[응답]

다른 위키피디아 번역에 의존하는 편집 정책

합리적인 추측은 영어 위키백과의 편집사항들 중 많은 부분이 다른 웹사이트에 의존하고 있으며, 이것은 실제로 다른 언어의 위키백과들을 포함할 수 있다.하지만, 만약 어떤 항목이 단순히 다른 언어로 된 위키피디아의 직역이었다면, 확실히 이것은 표절이라고 불릴 수 있다.반면에, 만약 어떤 항목이 단순히 - 다른 출처를 사용하는 것 외에 - 다른 언어 위키피디아를 지침으로 사용한다면, 나는 그것을 받아들일 수 있다고 생각한다.하지만, 위키피디아는 이미 다른 위키피디아들의 번역 요청에 대한 정책을 가지고 있는가?영어 위키백과에서 할마르 선덴에 대한 기사가 나오기 전에 스웨덴어 위키백과에도 한 기사가 있었다.나는 후자를 편집의 지침으로 사용하고 싶지만, 나는 스웨덴어를 할 줄 모른다.Hjalmar Sunden에 대한 나의 작품은 다른 자원을 사용했고 스웨덴어 출품작에 없는 정보를 포함하고 있기 때문에 표절은 아니라는 것을 잘 기억하라.위키피디아 기사가 다른 언어 위키피디아에 영향을 받는 경우는 어떨까?ACEOREVIVEED (토크) 21:47, 2008년 10월 27일 (UTC)[응답]

위키백과에서 텍스트를 복사하는 것은 어떤 언어로든 위키백과 기사의 저자에게 적절한 귀속성이 주어지는 한 저작권 침해도 표절도 아니다.한 언어로 광범위한 기사를 취역하여 기사가 약하거나 존재하지 않는 다른 언어로 번역하는 인터위키 번역가의 공동체가 성행하고 있다.적절한 귀속성이 유지되는 한 이것은 전혀 문제가 되지 않는다.그러나, 어떤 위키백과도 WP에서 요구하는 바와 같이 신뢰할 수 있는 출처라고 생각할 수 없다.RS와 WP:V. 따라서 위키백과 기사는 어떤 언어로도 다른 위키백과 기사를 참고자료나 출처로 사용하는 것은 좋지 않다.당신은 꽤 합법적으로 외국어 기사와 동일한 원고를 사용할 수 있다(외국어로도 될 가능성이 높고, 가능하다면 영어 출처를 선호한다). 그러나 기사 자체를 출처로 인용하는 것은 받아들일 수 없다.나는 이것이 사물을 명확하게 해주길 바란다.해피멜론 22:05, 2008년 10월 27일 (UTC)[응답]

아니, 나는 외국어 위키백과 기사를 영어로 번역하는 것을 "표절주의"라고 생각하지 않을 것이다.해피멜론의 말처럼 인터위키 번역가의 커뮤니티가 번성하고 있다.위키피디아 보기:번역, 위키백과:영어로 번역해야 하는 페이지, 카테고리:번역 등이 필요한 위키백과 기사들당신은 위키피디아에서 스웨덴어에서 영어로 번역되는 페이지를 제안할 수 있다.번역/*/랑/sv. --픽셀페이스(대화) 23:15, 2008년 10월 27일 (UTC)[응답]

빠른 답변에 감사드리며, 제 질문에 매우 잘 답변하셨습니다.ASCOREVIVEED (토크) 23:59, 2008년 10월 27일 (UTC)[응답]

무언가를 정리하기 위해 위키피디아(언어에 관계 없음)의 모든 콘텐츠는 Gnu 무료 문서 사용권을 릴리스한 콘텐츠다.라이선스와 상위 5명의 기여자에 대한 액세스와 관련된 정보가 유지되는 한, 생각하고 있다는 의미에서 "플래그라이징"할 수 없다.무료 콘텐츠야.셀라노르 15:23, 2008년 10월 28일 (UTC)[응답]

나는 이 문제가 틀렸다고 생각한다; 우리는 WP:V에 따라 다른 위키에서 번역되어서는 안 된다. 왜냐하면 위키피디아는 신뢰할 수 있는 출처가 아니기 때문이다.위키에 대한 편집은 신뢰할 수 있는 출처를 기반으로 해야 한다. 텍스트를 추가하는 편집자는 원본에 액세스해야 하며, 원본 언어로 이러한 출처를 읽을 수 있어야 한다.원본 출처에 접근, 읽기, 이해되지 않는 한, 다른 위키에서 번역하는 것은 우리의 핵심 WP:V 정책을 위반한다.샌디조지아 (토크) 20:42, 2008년 10월 28일 (UTC)[응답]

편집자들이 다른 위키와 다른 외국어 기사의 구글 번역과 그 번역으로부터 새로운 기사를 시작하는 것에 문제가 있었다. 비록 그 기사들을 여기서 시작하는 기고자는 언어에 능숙하지 않지만 말이다.기계로 만든 번역은 신뢰할 수 없다.아마도 요점으로는, 본질적으로 출처를 인용하는 편집자는 출처와 상의했다고 보증한다.다른 위키도 신뢰할 수 있는 출처가 아니며(위키피디아 자체가 신뢰할 수 있는 출처가 아닌 것처럼), 어떤 기사도 편집자가 상담하지 않은 출처에 의존해서는 안 된다.이것은 표절이나 저작권의 문제가 아니라 신뢰할 수 있는 출처의 문제다.(그리고 저작권이 있는 출처로부터 직접 텍스트 번역은 파생적이므로 저작권을 침해한다.) 카블람모 (토크) 20:55, 2008년 10월 28일 (UTC)[응답]

나는 위의 두 가지 모두 사실이 아닌 몇 가지 가정을 한다고 생각한다; 다른 위키피디아들은 RS를 인용하지 않으며, 다른 언어의 출처는 본질적으로 증명할 수 없다; 이것들 중 어느 것도 사실이 아니다.당신은 또한 사람들이 기계보다는 번역을 할 수 있고, 기사의 내용을 번역할 수 있는 사람도 출처를 읽을 수 있다는 것을 무시하는 것 같다.다른 위키피디아들 중 어느 것도 출처의 신뢰성에 관한 정책을 가지고 있지 않다; 당연히, 그들은 다른 이름을 가지고 있지만 모두 존재한다.두번째로, 첫번째의 진원지로서, 그것은 사실이 아니다.그렇더라도 번역자는 RS가 아닌 출처가 존재한다면 생략할 수 있다.셋째, 검증가능성 정책에는 출처가 영어 이외의 언어의 존재만으로 검증할 수 없다고 하는 것은 없다.모국어로 출처가 가능하다고 가정하면, 그렇다, 그러한 출처를 사용해야 한다. 하지만 모국어를 사용할 수 없다면 모국어가 아닌 출처를 인용하는 것은 아무런 문제가 없다.셀라노르 12:37, 2008년 10월 29일 (UTC)[응답]

셀라노르, 내가 쓴 글을 잘못 읽고 있는 것 같아.예, 다른 위키(및 en)wiki 역시 신뢰할 수 있는 출처가 아니다; 그것은 WP:V를 이해하는 사람이 질문하지 않는다.신뢰할 수 없는 출처에서 번역하는 것은 본문의 기반이 되는 신뢰할 수 있는 출처를 참조하지 않고 WP:V를 위반하는 것이다.만약 이 번역 그룹들이 그렇게 하고 있다면, 그것은 중단되어야 한다.나는 다른 언어의 출처가 신뢰할 수 없다고 말하지 않았다: 사실, 나는 유창한 스페인어를 말하고 읽기 때문에 종종 그것들을 사용한다.나는 번역할 때 (위키 텍스트가 아닌) 원래의 신뢰할 수 있는 출처를 참조할 필요가 있다고 말했다.en에 추가된 모든 텍스트.위키는 어떤 언어든지 믿을 수 있는 출처에 기초해야 한다; 위키는 신뢰할 수 있는 출처가 아니다.위키에서 원본과 상의하지 않고 번역하는 것은 신뢰할 수 없는 출처를 기반으로 하는 텍스트를 추가하는 것과 같다.번역자가 원래의 출처를 상담했다면, 어떤 언어로든, 어떤 언어로든, 그러한 출처를 번역하고 그에 기초하여 텍스트를 추가한다.그러나 신뢰할 수 없는 출처(위키)에서 번역하지 말고, 원래의 출처가 신뢰할 수 없는 위키에서 올바르게 표현된다고 가정한다.SayWhereYouGotIt에 대해 생각해 보십시오. Wiki에서 얻은 정보라면 그 점을 인용해야 하며, 신뢰할 수 없는 정보원에게는 인용하지 마십시오.Wiki는 믿을 만한 출처가 아니다.다른 위키들이 사용했던 원본에서 상담하고 번역할 필요가 있다.샌디조지아 (토크) 2008년 10월 29일 18:45 (UTC)[응답]

관용적인 번역이 다른 언어로 존재한다는 사실만으로 그 기사가 다른 언어로 번역되는 것을 막을 수는 없다; 요점은 그것들이 신뢰할 수 있고 검증 가능한 출처에 기초해야 한다는 것이다.나머지는 중요하지 않다; 여기서의 의문은 그러한 번역이 GFDL이 허가한 프로젝트들 사이에 존재하지 않는 플라가리즘을 구성할지 여부였다.셀라노르 18:53, 2008년 11월 1일 (UTC)[응답]

기계에서 생성된 번역은 신뢰할 수 없다. 그 언어에 유창한 한 사람의 번역은 믿을 수 없으며, 받아들일 수 있다.언어에 유창한 한 사람에 의한 출처 상담은 허용된다; 중간 출처(즉, 다른 위키)에 대한 의존 또는 그러한 출처로부터의 기계 생성 번역은 허용되지 않는다.모든 수단을 동원해서 우리는 다른 위키에서 정확하고 관용적인 번역을 장려해야 하지만, 그러한 번역을 할 수 있는 능력이 있고, 사용된 모든 출처를 확인한 사람이 해야 한다.추가적인 관련 논의는 이 FAX에서 확인할 수 있다.Kablammo (대화) 2008년 10월 29일 19:29 (UTC)[응답]

당연히, 아무도 기계식 번역을 옹호하지 않기 때문에, 나는 네가 무슨 말을 하려는지 정확히 모르겠다.다만 GFDL 허가 프로젝트 사이에 '플agarism'이라는 느낌이 드는 사람이 없는지 확인하고 싶었다.RS/V 문제는 그것보다 부차적이지만, 번역자가 단순히 단어 번역과 참고문헌 복사를 하는 것이 아니라고 가정하면 존재하지 않는다.셀라노르 18:53, 2008년 11월 1일 (UTC)[응답]

동감이다

1. 기계 번역은 초안으로도 전혀 받아들일 수 없다.
2. 번역가들은 언어학적으로뿐만 아니라 주제에 대해서도 유능해야 한다.
3. 원본 언어로 제공된 출처는 반드시 확인해야 한다.
4. 어떠한 이유로든 출처를 확인할 수 없는 경우에는 인용해서는 안 된다.

아, 그리고 위에서 말한 바와 같이 타 위키에서 번역한 것은 적절한 귀속만 이루어진다면 표절은 아니다.--굿모닝월드 (토크) 14:58, 2008년 11월 7일 (UTC)[응답]

몇 년 동안 샌디조지에 대해 많은 존경을 받았음에도 불구하고, 나는 그가 "WP:V에 의하면, 위키피디아는 신뢰할 수 있는 출처가 아니기 때문에 우리는 결코 다른 위키에서 번역되어서는 안 된다"고 말하는 것이 완전히 틀렸다고 생각한다."이전 버전은 믿을 만한 출처가 아니었기 때문에 영어 위키백과의 어떤 기사도 편집하거나 리팩터링하지 말라"고 말하는 편이 나을 것이다.기사에 대한 사전 작업이 다른 언어로 이루어졌다는 사실이 영어로 이루어졌을 때보다 사실적으로 덜 신뢰할 수 있게 하지는 않는다.

역사에서 기사의 영문 버전에 편집된 내용을 기록하듯이, 번역 시 다른 위키백과의 버전에 부분적으로 기사가 기초하고 있음을 나타내는 참고문헌 섹션에는 명시적 통지(요약 또는—나의 선호)가 있어야 하며, 이는 이상적으로 특정 ve와 참조되어야 한다.사용된 리션(어법에서는 내가 잘 알고 있는 언어에서 번역과 함께 외국어 위키에서 청소를 하는 것을 가끔 발견했기 때문에)- Jmabel Talk 18:23, 2008년 11월 12일 (UTC)[응답]

여기서 구별되는 것은 앞의 글을 출처로 취급하는 것과 출발점으로 취급하는 것 그 자체로 소스가 되어야 하는 것이다.나는 우리가 정말로 후자를 의미한다고 생각한다.— Werdna • talk 09:33, 2008년 11월 16일 (UTC)[응답]

피처링된 기사의 일시적 리프팅 장기 반보호

안녕 - 나는 여기서 제기된 이슈에 대해 토론하고 싶다 - 특집 기사의 장기 반보호를 일시적으로 해제하는 것이다.내가 걱정하는 것은 많은 나라 FA들이 무려 1년 동안 반보호를 해왔다는 것이다.반보호를 하는 이유는 매우 실용적이지만, 그러한 장기적이고 검토되지 않은 보호가 익명의 IP와 새로운 사용자들이 위키백과에서 가장 눈에 잘 띄고 인기 있는 기사에 기고하는 것을 막고 있는 것이 아닌가 하는 걱정이 든다.나는 이것이 WP:PROTECT#Semi-protection의 편지와 정신을 침해하고 있다고 생각한다.-이 대책으로 보일 수 있는 것처럼, 나는 이 정책에 의해 용납되지 않는 한, 검토되지 않은 장기적 반보호는 새로운 사용자들을 가두어 두는 것으로 끝날 뿐이라는 것을 느낀다.FA의 품질을 보존하는 것도 중요하지만, 새로운 정보를 제공하는 자유를 방해하기도 하고, 여러 가지 면에서 WP의 정신을 침해하기 시작한다.소유 및 WP:BOLD는, 최선의 의도에도 불구하고, 보다 적은 수의 일반 사용자들이 새로운 종류의 편집이 의심스러울 정도로 컨텐츠에 대한 최고의 접근과 제어를 얻는다.신규 사용자가 쉽게 꺼질 수 있고, 정책에서 자동 확정이 허용 가능한 핑계라고 하지 않는다는 점을 감안할 때 오토콘 확정은 핑계가 아니다.반보호에 대한 주기적인 검토가 있어야 하며, 반보호의 원인이 된 조건이 계속 존재하는지 여부를 확인하기 위해 최소한 며칠간 해제해야 한다고 제안한다.시바 (비즈누) 09:27, 2008년 11월 12일 (UTC)[응답]

매년 보호가 검토될 수 있도록 하는 롤링 리뷰가 좋은 계획이 될 것 같다. --Nate1481 14:06, 2008년 11월 12일 (UTC)[응답]

문제는 인도와 같은 대중적인 국가 페이지에 있는데, 이 페이지를 열어두면 적극적인 편집자들이 일일이 편집하지 않으면 급격히 악화될 것이다.평균적으로 하루에 20번씩 수정하여 포함의 적합성을 판단하는 것은 인간적으로 불가능하다.인도와 같은 페이지에 포함된 텍스트는 요약 스타일과 목록 같은 내용의 제거에 초점을 맞추기로 선택하면서 메가바이트의 토론 끝에 왔다.애논 편집자는 이것을 모른다.뭔가 빠졌다고 느끼면 단순히 내용을 추가하고 카슈미르에 NPOV 관련 내용을 삭제하며 델리를 국가로 전환하는 등 무식한 편집을 할 것이다.그러한 편집은 끊임없는 주의를 요한다.자원 봉사자로서, 우리는 모든 편집을 확인하는 데 시간을 낭비해서는 안 된다.RC 순찰대는 공공 기물 파손 여부를 확인할 수 있을 뿐, 그들은 수개월 동안 그 페이지에 남아 있는 미묘한 기물 파괴 행위를 걸러낼 수 있는 위치에 있지 않다.인도 페이지의 미묘한 반달리즘에 대한 이 기사를 참조하십시오.위키피디아가 열려 있는 동안, 나는 또한 수개월 동안 노동 토론을 하고 내용 포함과 NPOV를 토론한 편집자들의 기여가 단 한 방에 지워져서는 안 된다고 느낀다.인도 페이지가 편집에 개방되어 있고, 소수의 사람들이 보고 있을 때, FARC로 두 번 끌려갔다.그러면 우리는 개인적인 삶의 약속을 떠나서 돌아와서 무엇이 잘못되었는지 보고 모든 근무 시간을 다시 하라고 기대할 수 없다.그렇게 하는 것은 나나 다른 사람의 의무가 아니다.그러나 그것은 낙담하고 있다.내 생각에는 보호가 긍정적으로 작용하고 있다.우리는 새로운 기사를 만들기 위해 등록을 요구하는데, 그것은 IMO가 더 미루는 것이다.=Nichalp talkTalk »=07:39, 2008년 11월 13일 (UTC)[응답]

당신의 주장은 실제적인 관점에서 만들어 졌다. 정책에 포함되지 않는 한, 그것에는 아무런 문제가 없다.즉, ⑴ 반보호적 사용의 정확한 정책 위반, 즉, 기사를 과감하게 개선하고 새로운 편집자를 몰아낼 수 있는 정규 편집자들 사이에서 일종의 소유권을 창출할 수 있는 권리, 그리고 ⑵ 인기 있는 기사를 처음 사용자가 접근할 수 없게 만드는 위험을 감수하고 있다는 것이다.

우리는 모두 자원봉사자인데, 어쨌든 보상은 받지 않는 것 같아.어떻게 FA 건물 업무의 악화에 대한 혐오가 위키피디아의 새로운 사람들에 대한 접근성을 보호하거나 기존 정책을 시행하는 것보다 더 중요한 것으로 증명되는가?그것은 WP와 약간 어긋난다.최상의 의도에도 불구하고, 우리는 새로운 사용자들의 기여를 본질적으로 부정적이라고 가정하고 있으며, 그들이 FA에 대해 아무것도 모를 것이라고 가정하는 것은 약간 거들떠보지도 않는다; 내 생각에 자동 확증된 사용자들은 같은 것에 취약하기 때문에, 그것은 안전장치가 될 수 없다.나는 모든 기사가 FA 지위에 상관없이 같은 위험에 노출되어 있다고 생각한다.문제는 새로운 사용자들이 먼저 얻으려고 하는 것이 인기 있는 기사라는 것이다.당신(니찰프)은 앞서 인도가 어떻게 가장 많이 읽혔는지 지적한 바 있으니, 위키백과를 처음 경험하려는 새로운 사람들의 반응을 상상해 보라.여기서 나는 불과 2~3주 전에 직접 경험을 가지고 이야기한다.

내가 하고 싶은 것은 인도와 같은 기사가 1년 동안 반보호를 받고 있는 것을 4~5일 동안 보호받지 못하고 지켜져야만 공공기물 파손과 임의적인 대형 데이터 추가의 위험성을 확인할 수 있다는 것이다.그게 다야 - 난 이것이 누구에게나 요구한다고 생각하지 않아. 그렇지 않으면 너의 건전한 주장을 위반하는 것도 아니라고 생각해.내가 묻고 있는 것은 당연한 것처럼 적절한 자유다.나는 만약 이것이 계속되려면 이 실무적인 관심사를 WP:PROTECT에 포함시킬 것을 제안할 수 있을 뿐이다.시바(비즈누) 2008년 11월 13일(UTC) 19:12[응답]

"당신의 주장은 실제적인 관점에서 이루어진 것이다. 정책에 포함되지 않는 한, 그것에는 아무런 문제가 없다. 이는 (a) 반보호 사용의 정확한 정책 위반을 감수하고 있다"는 의미 - 프로젝트를 돕기 위한 정책 정신(즉, 상식, 정책의 이면에 있는 실질적인 추리)에 따라 '정책은 그렇게 말한다'는 이유만으로 서한에 따르는 것이 더 중요하다.

"어떻게 하면 FA 건물 업무의 악화에 대한 혐오가 위키피디아의 새로운 사람들에 대한 접근성을 보호하거나 기존 정책을 시행하는 것보다 더 중요한 것으로 증명되는가? " - 99% 이상의 위키피디아 방문자들은 결코 편집하지 않을 것이다. 그들이 보는 페이지가 모두 보호되어 있기 때문이 아니라, 단지 편집하지 않을 뿐이다.수만 명의 사람들만이 편집할 수 있는 안정적이고 형편없는 기사는 공공 기물 파괴와 비협조적이고 부정확한 정보로 가득 찬 불안정한 기사보다 더 낫다. 특히 우리가 그것을 "피치있는"이라고 부르면서 돌아다니는다면 말이다(그러나 모든 변명의 반보호적인 기사가 FA나 심지어 GA, 예를 들어 개년아).

"내가 하고 싶은 것은 1년 동안 반보호를 받고 있는 인도와 같은 기사는 공공 기물 파손과 임의적인 대형 데이터 추가의 위험성을 확인하기 위해 4~5일 동안 보호받지 않고 지켜져야 한다는 것이다." - 페이지 역사를 살펴보라.만약 그것이 반보호적인 상태에서 여전히 꽤 빈번하게 공공 기물 파손이 일어난다면, 그것은 아마도 비보호라는 것이 좋지 않은 생각일지라도, 그렇지 않다면, 비보호라는 것이 효과가 있을지도 모른다는 징조일 것이다.Mr.Z-man 18:22, 2008년 11월 14일 (UTC)[응답]

Auld Lang Syne Flaged Revs, Flaged Revs, Flaged Revs, Flaged Revs의 곡에 맞추어.플래그 지정된 Revs, 플래그 지정된 Revs, 플래그 지정된 Revs.플래그 지정된 Revs, 플래그 지정된 Revs, 플래그 지정된 Revs.Flaged Revs, Flaged Revs, Flaged Revs. — Werdna • talk 13:34, 2008년 11월 14일 (UTC)[응답]

나는 이것이 표준 보호 정책에 따라 처리되어야 한다고 생각한다.FA라는 이유만으로 FA를 보호해서는 안 된다.만약 그들이 파손된다면, 아마도 평상시보다 조금 더 빨리 보호하겠지만, 단지 그것 때문에 보호되지는 않을 것이다.무슨 일이 일어나는지 인도도 지켜주지 않고 있어. 137.246.207.202 (대화) 17:51, 2008년 11월 14일 (UTC)[응답]

누가 사람들이 단지 이유 때문에 FA를 보호하고 있다고 하는가?보호 일지를 보세요, 인도는 보호되고 있었습니다, 왜냐하면 그 당시 거의 모든 애논 편집자들이 보호 정책에서 다루는 공공 기물 파손이나 스팸을 추가하고 있었기 때문이었습니다.FA라는 사실은 전혀 언급되지 않았다.그리고 나는 네가 "나는 무슨 일이 일어나는지 보기 위해 인도를 보호하지 않는다"는 말이 무슨 뜻인지 잘 모르겠다-애논은 페이지를 보호하지 못한다...Mr.Z-man 18:22, 2008년 11월 14일 (UTC)[응답]

어쩌면 로그아웃된 걸지도 모르지.나는 최근에 FA들이 반보호적인 반면, 그것이 최근의 공공 기물 파손은 미미하거나 전혀 없었거나, 또는 다른 유사한 FA들이 반보호적인 것이었기 때문에 본 적이 있다.이런 합리성을 경계해야 하지만 인도에서는 그렇지 않다.우리는 정말로 이런 종류의 기사에 국기가 달린 회전수를 사용할 수 있다.세나리움 22:52, 2008년 11월 14일 (UTC)[응답]

시바, 나는 어떤 것이 더 나쁜지 모르겠다, "예고된 반달리즘"이나 "기사는 요약문체로 쓰여져 있다, FA에 속하지 않는다"와 같은 이유로 아논이 텍스트를 덧붙이지 못하게 하거나, 아논을 되돌리지 못하게 하는 것. 그런 이유들은 더 미루는 것이 아닌가?내가 쓴 두 나라 FA:네팔과 부탄은 FA 자격을 잃었다.FA 기사를 공개 편집용으로 보관했다가 '인적 검토와 검증'이 없어 지위를 잃게 되는 그런 시나리오를 지지하십니까?일단 기사가 FA에 도달하면 이상적으로는 평지에 있어야 한다.현재, 반보호를 받고 있음에도 불구하고, 이 기사는 오늘날에도 사소한 반달리즘에 시달리고 있으며, 그들이 느끼는 어떤 것이라도 덧붙이기를 원하는 편집자들의 편집은 그것이 들어맞지 않다고 생각하는 것을 멈추지 않고 결석하고 있다.=Nichalp talkTalk »=15:35, 2008년 11월 16일 (UTC)[응답]

인도 이달 랭킹 74위 =니찰프 «토크 »=15:41, 2008년 11월 16일(UTC)[응답]

다시 말하지만, 위의 모든 주장은 타당하다.내가 묻고 싶은 것은 바다를 시험하고 심각한 공공 기물 파괴 위협이 여전히 존재하는지 보기 위해 그러한 장기적 보호가 잠시 해제되어야 한다는 것이다.반보호를 1년 넘게 검토하지 않는 것은 적절치 않다고 생각한다.FA 지위에 대해 말하자면, 나는 인도, 네팔, 부탄과 같은 기사들이 높은 관심의 나라 FA들이기 때문에, 다소 덜 두드러진 주제보다는 좀 더 경계할 필요가 있다고 생각한다.네가 말했듯이, 만약 인도가 74번째로 인기 있는 기사라면, 그것은 "누구나 편집할 수 있는 무료 백과사전"이라는 위키피디아의 주장에도 불구하고, 새로운 사람들을 편집하지 못하게 할지도 모른다 – 당연히 우리는 이것이 여전히 사실이라는 것을 알지만, 검토가 없는 장기적인 반보호는 나쁜 방식으로 더 또는 덜 제한적이다.시바(비즈누) 2008년 11월 16일(UTC) 18:12[응답]

응, 하지만 30개의 특집 기사를 지명하면 각 기사에 대해 30분씩의 차이점을 확인할 수 없어.그렇게 하면 연기되지 않을까?누구나 백과사전을 편집할 수 있는데, 우선 순위가 높은 페이지를 편집하기 위해서는 계정이 필요하다.새 페이지 만들려면 이미 계정이 필요하지 않아?요점으로 돌아와서, 보호가 제거되면 어떤 일이 일어나기를 바라는가?순 양극이냐 음극이냐?보호가 해제되면 IP 및 확인되지 않은 사용자에 의한 각 편집에 대한 설문 조사를 수행하시겠습니까?=Nichalp talkTalk »=19:24, 2008년 11월 16일 (UTC)[응답]

Z Man씨에게 - 문제는 이 검토되지 않은 장기적 반보호가 단순히 확장되거나 초과되는 것이 아니라 실제로 WP:PROTECT와 모순되는 결과를 초래한다는 것이다 - 이제 나는 이 정책이 만들어졌을 때 모든 이슈를 고려했고 모든 상황에서 FA와 관련이 있다고 생각한다.당신의 주장이 매우 현실적임을 감안할 때, 나는 FA에 대한 장기적 반보호를 용인할 수 있는 정책에 포함시키려 노력하는 것이 옳을 것이라고 제안한다 - 그것은 이것을 바라보는 또 다른 방법이다.시바(비즈누) 18:22, 2008년 11월 16일 (UTC)[응답]

아마도 우리는 그런 경우를 포함시키기 위해 정책을 다시 써야 할 것이다.=Nichalp talkTalk »=19:24, 2008년 11월 16일 (UTC)[응답]

조지 W 부시와 같은 기사는 차기 대통령이 취임하고 난 직후에 보호받지 못할 수도 있지만, 역사를 잠깐 들여다보면 "실험적인 보호 해제"가 헛수고가 될 것이라는 것을 암시해야 한다.검토가 안 됐다고 누가 그래?보호 검토를 위한 공식적인 프로세스는 WP를 제외하고는 없다.RFP, 아카이브되지 않은 RFP.나는 조지 W 부시 대통령의 역사를 살펴봤을 뿐인데, 보호해 주지 않는 것은 어리석은 짓이라고 판단했다. 내가 그것을 검토만 한 것이 아니었을까?내 생각에 너는 여러 가지 이슈들을 섞고 있는 것 같아.끈기 있게 포착된 기사가 모두 FA는 아니며, 모든 FA가 무한히 반감되는 것도 아니다.FA라고 해서 FA를 지킬 이유가 없다.만약 공공연한 FA가 빈번하게 공공 기물을 파손하고 있다면, 그것은 다른 유명 기사들이 빈번하게 공공 기물을 파손하는 것과 마찬가지로 보호될 것이다.FA라는 사실이 그것과 거의 관계가 없다.보호정책은 이미 심각한 이유로 장기 반제약을 적용하고 있고 인도를 보호하기 위해 주어진 이유가 여기에 들어맞는데 왜 정책이 바뀌어야 하는지 모르겠다.미스터 지맨 2008년 11월 16일 (UTC) 19:17[응답]

위키 아틀라스 프로젝트

안녕. 나는 지리 기사에 대해 많은 일을 하는데 우리 지도 자원이 매우 실망스럽다고 생각해.모든 좋은 백과사전들은 지도책을 가지고 있지만 나는 위키 미니 지도책의 표준이 낮고 종종 부정확하며, 높은 표준을 의도한 위키백과들의 하위 표준인 낮은 품질의 배경을 발견한다.나는 우리가 강화된 위성사진과 함께 더 발전된 지도책을 가져야 한다고 생각한다.위키아틀라스 자매 프로젝트나 위키백과의 새로운 영역을 지원하는 사람이 있는가? 위키아틀라스나 새로운 영역은 우리가 책 형식으로 보지만 좀 더 발전된 지도와 양질의 위성사진을 얻을 수 있는 범위 내에서 적절한 지도도를 작성하려고 시도하고 있는가?우리가 현재 웹상에서 공식 지도책과 가장 가까운 것은 MSN 엔카르타 지도책이지만 우리가 알고 있는 이것은 오래된 것이다.위키 프로젝트는 정보 서비스에 전념하고 있기 때문에, 우리가 프로젝트의 일부로서 참조 포인트로서 제대로 된 세계 지도책을 가지고 있지 않다는 것은 매우 이상해 보인다. 블로펠드 백작 11:58, 2008년 11월 13일 (UTC)[응답하라]

그 프로젝트는 OpenStreetMap의 노력을 복제하는 것이 아닐까?위키미니아틀라스는 정말로 OpenStreetMap의 지도 표시를 지원해야 한다. 왜 그렇게 하지 않는지 나에게 묻지 마라.헤밍센 12:26, 2008년 11월 13일 (UTC)[응답]

좋아, 우선 위키미니아틀라스는 현재 꽤 오랫동안 풀스크린 버튼을 가지고 있고, 두 번째로 높은 품질의 지오다타는 구하기 쉽지 않다.오픈스트리트맵 데이터의 투영은 WMA와는 다르다. 오픈스트리트맵 데이터[3]를 표시할 수 있는 기능을 가진 새로운 위키미니아틀라스[WikiMiniAtlas]를 연구해 왔지만, 내 부분에 대한 심각한 시간 제약 때문에 이것은 아직 끝나지 않았다.내가 OSM과 함께 가지고 있는 주요 쇠고기는 지도 상의 라벨링이다.나는 위키피디아에서 온 라벨을 원한다.THIS는 위키미니아틀라스에서 다국어 지도를 허용한다.OSM 레이블(잘못 해독할 수 없는 유형 집합 중 일부)이 지도를 어지럽힌다. --Dschwen 15:23, 2008년 11월 13일 (UTC)[응답]

그래, 블로펠드 백작 15:25, 2008년 11월 13일 (UTC)의 지도를 어지럽히는 라벨이 무슨 뜻인지 알아.

오픈스트리트맵은 플래시를 사용한다.그리고 속도와 자원에 굶주린 애플리케이션은, 나를 지연시키고 있었다.=Nichalp talkTalk »=12:55, 2008년 11월 13일 (UTC)[응답]

위키피디아의 지도책은 빠른 확인에 유용하지만, 이것은 높은 품질의 지도책과 위키피디아에서 기대하는 형식적인 지도책의 종류가 아니다.노트 OpenStreetMap은 예를 들어 베트남과 같은 동아시아 지역의 경우 "해외" 문자가 있고 영어로 인식되지 않는 방식으로 편집되었다. 블로펠드 백작 12:38, 2008년 11월 13일 (UTC)[응답하라]

이상적으로는 우리는 구글 어스/맵이 하는 것을 복제해야 한다.고해상도 SVG 맵(약 1:1000 스케일)을 만든 다음 함께 연결하십시오.=Nichalp talkTalk »=12:55, 2008년 11월 13일 (UTC)[응답]

그래, 난 구글의 설정 방식이 좋아.Wiki를 완전히 사용할 수 있는 유사한 데이터베이스를 만들 수 있는 방법이 있다면, 나는 전적으로 찬성할 것이다. --사용자:AlbertHerring 14:26, 2008년 11월 13일 (UTC)[응답]

그래, 나도 니콜프 말에 동의해.위키미디어 프로젝트는 정말로 웹에 대한 정보의 중심이 되어야 하며 이것은 외부에 의존하기 보다는 우리 프로젝트 내에서 우리 자신의 지도 정보 프로그램을 개발하는 것을 의미한다.이상적으로 우리는 위키백과를 향한 트래픽을 증가시킬 정도로 발전된 무언가를 원한다.나는 매일 구글 지도를 사용하는 사람들이 수백만 명에 달할 것이라고 생각하지만, 만약 우리가 웹에 가장 포괄적인 지도 제작 시설 중 하나와 그것이 프로젝트에 끌어들일 수 있는 인원의 양을 가지고 있다면 그 혜택을 상상해 보라.언젠가 도시 내에서 랜드마크 등을 찾아 가상 3D로 조망할 수 있는 기능과 함께 위키피디아에 3D로 된 상세한 위성지도를 상상한 후 라벨을 클릭해 각각의 기사를 보는 일이 있다.야심 차게 들리지만 미래에는 불가능하지 않지만 멋진 전망이 될 것이다.하지만 좀 더 현실적으로, 나는 위키 안에 있는 괜찮은 견고한 2D 지도책과 함께 행복할 것이다. 블로펠드 백작 15:12, 2008년 11월 13일 (UTC)[응답하라]

여가 시간에, 나는 높이 지도 데이터를 기반으로 지구 전체의 3D 지형 표현 작업을 해 왔다.소규모로 약간의 성공을 거두었지만, 다른 몇 명의 조력자들과 함께, 만약 이것이 당신이 염두에 둔 것이라면, 나는 이것의 프로그래밍 프로젝트를 만들 수 있었다.프리츠폴 (대화) 21:42, 2008년 11월 13일 (UTC)[응답]

가능한 경우 등고선과 지형을 3D로 보여주는 지도.나는 또한 구글이 3D 지도를 개발하는 방법과 미래에 어떻게 이것이 3D 관점에서 이해를 높이기 위해 이곳의 도시와 지형을 탐구하는 백과사전적 목적으로 사용될 수 있는지에 대해 생각하고 있었다.아마도 나는 인터넷의 미래가 점점 가상화된 3D가 될 것이라고 강조하는 다큐멘터리를 너무 많이 보고 있었을 것이다. 하지만 나는 왜 위키피디아가 돈과 전문지식을 기꺼이 투자한다면 이런 방식으로 구글 위성 지도와 같은 것을 개발하는 것이 불가능할지 모르겠다.사람들은, 만약 우리가 구글 지도를 가지고 있다면, 웹 상에 지도를 제공하는 다른 사이트들이 있다면, 왜 우리는 어떤 지도도 필요할까라고 말할지도 모른다. 하지만 그것은 위키 프로젝트 내에서 편리할 뿐만 아니라 잠재적으로 교통의 측면에서 우리는 위키피디아에 상당한 양의 새로운 사람들을 끌어 모을 수 있을 것이다. 블로펠드 22:04, 2008년 11월 13일 (UTC) 백작[응답]

글쎄, 내가 가상 지형을 자동으로 만들 수는 있지만, 반드시 인공 지형을 만들 수는 없어. 다른 출처가 필요하거나 손으로 만들 수도 있어.아마도 몇몇 관심 있는 사람들은 이런 종류의 프로젝트에 협력하는 것을 도울 수 있을 것이다.그런 거라면 새로운 포럼이 필요할지도 몰라...프리츠폴 (대화) 22:08, 2008년 11월 13일 (UTC)[응답]

정확히 말하자면, 진짜 세부사항들은 내가 현실적으로 미래까지 생각하지 않았지만, 그래, 나는 지형과 위성사진을 향상시키는 것에 대해 생각하고 있었어.첫 번째 단계는 우리의 위키 미니 아틀라스를 더 높은 표준으로 발전시키고, 필요하다면 그것을 계획하기 위한 더 넓은 프로젝트를 세우는 것이라고 생각한다.나는 MiniAtlas와 좌표 프로젝트를 셋업하는 워크그룹들이 이미 존재한다는 것을 안다.아마도 그것을 좀 더 광범위한 것으로 바꾸는 것도 나쁘지 않을 것이다.어느 쪽이든 우리는 견고한 지도가 필요하고 인터넷과 위키 프로젝트가 진화하는 방식은 웹 상의 다른 지도 시스템과 동등한 수준의 지도 시스템을 개발하는 것이 현명할 것이다.기본적으로 나는 위키백과에 맞게 변형된 Microsoft Virtual Earth 같은 것을 생각하고 있다. 블로펠트 카운트 22:13, 2008년 11월 13일 (UTC)[응답]

우리는 항상 구글 지도에서 WMA의 데이터를 추출할 수 있지 않을까?~ 편집자 휴이키 ~ 2008년 11월 13일 (UTC)[응답]

그것은 그들의 저작권을 약간 침해할 것이다.Geni 03:42, 2008년 11월 14일 (UTC)[응답]

Bloefed 백작님, 어떤 종류의 지도를 보고 계신 겁니까?지형도? 도로지도?http://www.ngdc.noaa.gov/mgg/topo/gltiles.html은 다음과 같은 이미지를 만드는 데 사용되는 GFDL이다.이미지:인도 topo big.jpg.그것은 탐험할 만한 가치가 있을지도 모르는 높은 규모를 가지고 있다.=Nichalp«Talk »=18:33, 2008년 11월 14일 (UTC)[응답]

SRTM 데이터가 있는 위치에 Globe 데이터를 사용하지 마십시오...SRTM은 분해능이 90m로 수평과 수직 모두 정확도가 훨씬 뛰어나다.차세대 블루마블의 해상도는 500m이다 – 해상도가 높은 시각 데이터가 자유롭게 이용 가능한지 잘 모르겠다.– 사달멜릭 ▷인터뷰 19:33, 2008년 11월 15일 (UTC)[응답]

지도와 백과사전을 더 잘 통합하는 한, 한 가지 방법은 지도 네임스케이프를 공동체에 만드는 것이다.그러면 우리는 여기서 [[맵:시칠리 오른쪽 300px 엄지손가락 시칠리아 지도]와 같은 것을 사용할 수 있을 것이다.그러나 Commons에서는 Map:Sicily-en이라는 업로드된 파일이 없을 것이다.대신 지도에 대한 설명이 있다...이와 비슷한 것:

배경 = 왼쪽 지형 = 오른쪽 = 20 아래쪽 = 18 위쪽 = 위쪽 = 20개 투영 = 20개 투영 = Mercator Layer1 = 주도로 Layer2 = Mountains_1000m Layer3 = City_50000-en

물론 그렇게 되면 글꼴 크기, 색상, 선 두께 등과 같은 것들을 지정할 수 있어야 한다.어쨌든, 지도가 포함된 페이지를 볼 때, 지도 서버는 지도의 면적과 픽셀 폭에 기초하여 지도에 가장 적합한 데이터의 척도(완전한 SRTM 또는 무엇인가의 공동작업자)를 결정한다.그것은 각 층을 차례로 추가하고 지형, 주요 도로, 1,000m 이상의 산과 더 큰 마을들을 포함하는 비트맵을 생성할 것이다.또한 해당 이미지 맵에 대한 HMTL 코드를 생성하여 Etna 레이블을 클릭하면 뷰어가 기사 Etna로 이동한다.비트맵과 이미지 맵 모두 향후 사용을 위해 캐시된다.물론 그것은 구글 어스와는 다르겠지만, 나는 그것이 우리가 가진 자원을 넘어선다고 생각한다.이마저도 일이 많을 것이다.– 사달멜릭 ▷인터뷰 19:33, 2008년 11월 15일 (UTC)[응답]

지도 생성 방법 대신 WMA를 사용하십시오.조금 전에 템플릿에서 예를 하나 드렸다.정보를 빈 칸에 저장하여 WMA를 초기화하는 GeoTemplate/sandbox.

우리가 미래를 예측하는 동안, 나는 거대한 호수가 전국적으로 얼어붙은 후 중서부의 황량한 사막을 보기 위해 여름으로 바뀌는 계절이 다른 것을 보고 싶다.나는 80년대 스타일의 벡터링 지구를 보고 싶다.나는 나의 카운티 선거 결과를 카토그램으로 확대할 수 있기를 바란다.공용 맵을 오버레이할 수 있는 기능.나는 애니메이션 날씨와 온도 지도를 보고 싶다.강우량을 보거나, 지도책이나 연감에서 찾을 수 있는 다른 것을 보십시오.— 디스펜서 06:17, 2008년 11월 16일 (UTC)[응답]

새 배너

프랑스어 « Portail de la Littérature » 여기[4]의 새로운 배너를 보십시오.그것은 무작위 사진 갤러리에 바탕을 두고 있다.사용자에게 묻기:스테프48은 그것에 대해 질문한다.PRA (대화) 09:57, 2008년 11월 16일 (UTC)[응답]

Portal과 같은 포털에 표시되는 랜덤 이미지/아티클과 어떻게 다른가?비디오 게임 및 포털:축구?자코플레인 • 2008-11-16 11:16

화랑이지, 그림 한 장이 아니다.PRA (대화) 2008년 11월 16일 11시 34분 (UTC)[응답]

그들은 한 번에 두 개 이상의 무작위 이미지를 사용한다.우리는 몇 년 동안 그것을 해오고 있다.DendodgeTalk^Contribs 14:13, 2008년 11월 16일 (UTC)[응답]

우리는 (영어와 다른 언어로 된) 포털을 많이 보았는데 그런 현수막은 본 적이 없다.너의 모델은 너무 잘 숨겨져 있다.길을 알려 주시오.PRA (토크) 2008년 11월 16일 (UTC) 15:40[응답]

우리는 보통 갤러리 배너를 그렇게 하지 않지만, 이것의 여러 배너와 같다.DendodgeTalk^Contribs 15:42, 2008년 11월 16일 (UTC)[응답]

드구스티버스 엣 컬러리버스 논설문 "취향과 색에 대해 논쟁할 필요 없어..."PRA (대화) 2008년 11월 16일 (UTC) 16:41, 응답하라

영상을 무작위화해서 비자유 영상이 배너에 담기지 않았으면 좋겠다.리틀 레드 라이딩 후드토크 22:17, 2008년 11월 16일 (UTC)[응답]

저것들은 선택되었고, 100개 이상의 저작권이 사라졌음이 분명하다.세나리움 00:45, 2008년 11월 17일 (UTC)[응답]

그래서 무작위로 고르는 과정은 그들의 나이를 체크하는 거야?리틀 레드 라이딩 후드토크 01:07, 2008년 11월 17일 (UTC)[응답]

여기 리스트에서 무작위로 고른 건데, 저작권 상태는 확인됐나 봐.그들 중 대부분은 늙어 보이고 나는 다른 사람들은 무료 면허증으로 풀려났다고 생각한다.세나리움 03:05, 2008년 11월 17일 (UTC)[응답]

위키백과:명명 규칙(Ancient 이집트어)

위키백과:명명 규칙(Ancient 이집트어)은 1년 이상 존재했지만, 현재 위키백과:이름 지정 규칙 또는 다른 정책 또는 명명 규칙과 연결되어 있지 않다.명명 규칙이라는 꼬리표가 붙었음에도 불구하고, 여기서 논의된 것처럼 보이지 않는다.다른 곳에서는 위키백과 강연에서 이 주제에 대해 언급하는 것이 고작이다.이름 지정 규칙/아카이브 11#복사 편집 태그, 이것은 약간만 관련이 있다.

그러나 위키피디아에 의해 채택되었다.위키프로젝트 이집트, 그리고 이집트를 지지하는 활동적인 구성원들 사이에 강한 공감대가 존재하는 것으로 보인다.

IMO 그것은 더 넓은 지역사회에서 채택되어야 하며 WP의 가이드라인 목록에 추가되어야 한다.NC, 또는 거부, {{Wikipedia 서브캣 가이드라인 이름 지정 협약 고대 이집트} 배너가 제거되었다.안드레와 (토크) 2008년 10월 18일 (UTC) 13:40[응답]

나는 위키피디아에서 이 토론에 연결했다.마을 펌프(정책)#위키백과:명명 규칙(Ancient 이집트어) 및 위키백과 대화:명명 규칙# 이집트어 이름, 위키백과 대화:위키프로젝트 이집트#위키백과:명명 규칙(Ancient 이집트어) 및 위키백과 대화:명명 규칙(Ancient 이집트어)#리슈밍... 그리고 토크:쿠푸#나밍 컨벤션은 이 토론의 최근 라운드가 시작된 곳이다.내가 잊은 사람?안드레와 (토크) 2008년 10월 18일 (UTC) 14:28[응답]

일반적으로 가이드라인은 정책을 무시할 수 없다.그것은 당신이 하고 있는 일에 치명적인 결함이 아니라, 단지 그 과정의 일부로서 당신이 언급했던 예외사항들을 WP에 기록하기를 원할 것이라는 것을 의미한다.이름. - Dan Dan Dank55 (보내기/수신) 2008년 10월 21일 (UTC) 20:53[응답]

그래, 맞아. 그래서 Pump(정책)와 Talk의 헤드업:NC. 만약 이 가이드라인을 채택하기로 합의했다면, 그것은 WP로부터 이 가이드라인을 연결해야 한다는 것을 의미한다는 점에서 기본적으로 정책 결정이 될 것이다.NAME(더 흔히 WP라고 함:내 경험상 NC)는 정책 페이지다.WP와 관련하여 정책과 지침 사이의 경계가 약간 모호하다.NC는 예외를 포함한 세부 규칙을 설명하는 페이지가 공식적으로 가이드라인으로 간주되지만, 어떤 의미에서 정책을 오버룰 수 있다.WP에서 이러한 오버라이드 명명 규칙을 나열할 때 이에 대한 (관리 통제라는 의미에서) 어느 정도 통제가 있다.NC, 그리고 이 제안은 근본적으로 그 통제권을 행사하는 것이다.안드레와 (대화) 2008년 10월 22일 (UTC) 12시 5분 (답변)

'지침은 정책을 초월할 수 없다'는 지적은 오해를 불러일으킨다.위키피디아는 관료주의가 아니며, 기존의 정책과 지침은 행동의 처방이 아니라 공동체 표준의 문서화 역할을 하는 경향이 있다.따라서, 만약 지역사회가 고대 이집트인들을 위한 명명규칙을 사용한다면, 계속 사용하라.— Werdna • talk 09:09, 2008년 10월 22일 (UTC)[응답]

바로 그거야그러나 나는 이 지침과 WP 간의 불일치를 해결할 때가 왔다고 생각한다.NC. 어떤 의미에서는 이미 이런 일이 일어났다.(제안된?) 가이드라인은 현재 가이드라인이 아닌 제안된 명명 규약으로 재접속되었다.안드레와 (대화) 2008년 10월 22일 (UTC) 12시 5분 (답변)

그것은 실제로 보이는 것만큼 정책에 반대되는 것은 아니다; 마네호를 통해 우리에게 내려오는 이집트인들을 위한 그리스식 이름들이 매우 많으며, 실제로 상형문자의 읽기가 시작된 이후로 거의 사용되지 않게 되었다.여러 가지 이유로 헬레네이티드 형식이 여전히 관습적인 경우(메네스, 라메스, 어플리스)에서 우리는 실제로 그것을 사용하고, 나는 그에 따라 가이드라인을 수정했다.내가 볼 때, 실제로 문제가 되고 있는 유일한 질문은 우리가 쳇을 이용해야 하는가 아니면 쿠푸를 이용해야 하는가 이다; 그리고 그것은 정책보다는 대체로 사실의 문제(현재의 표준 사용법이란 무엇인가?)이다.2008년 10월 22일(UTC) 16:14, Sentrionalis PMAnderson [응답]

IMO의 진짜 의문은, 정말로 우리가 이 가이드라인이 필요한가 하는 것이다; 그것이 우리가 WP보다 더 명확하게 말할 필요가 있는 것을 말하는가 하는 것이다.NAME 자체는 그렇다.나는 그것에 대해 결정하지 않았다.2008년 10월 22일(UTC) 16:16, Sentrionalis PMAnderson [응답]

동의해 하지만 토크에서의 논쟁은쿠푸#기사 이름은 아주 다른 견해를 취했다.안드레와 (토크) 02:49, 2008년 10월 23일 (UTC)[응답]

우리는 이미 동등한 지침을 가지고 있다. 이것은 상황을 정리할 것이다.더그 웰러 (토크) 2008년 10월 24일 (UTC) 20:08[응답]

하지만 그게 다야...뭔가 깔끔하게 정리되는 거 없어?현재 수정된 대로 WP를 따르십시오.NC. 그건 순전히 명령의 소름끼치는 소리야.이전의 콘텐츠는 예외, 매우 강력한 예외(그리스어를 절대 사용하지 않음), 그리고 나와 이름 없는 다른 사람들이 WP를 밴딩한다고 비난한 관련 위키피디아 대상 회원들에 의해 매우 중요한 것으로 여겨지는 예외를 설정하려고 했다.이전 논의에서 NC.

그리고 우리가 아직 다루지 않은 또 다른 문제가 있는데, 무덤의 일반적인 이름보다는 체계적 이름이다. 무덤은 매우 유사하고 똑같이 가열되어 있으며, 만약 이것이 채택된다면, 위키백과 강연에서 제기될 수 있고 꽤 가능성이 있다.정책 페이지 Ay WP에 대한 추가 참조 없이 명명 규칙(Ancient 이집트어):그런 다음 링크에 의해 그것을 승인할 NC.지저분하다. 안드레와(토크) 19:04, 2008년 10월 26일 (UTC)[응답하라]

나는 이전의 질문(파라오의 명명 규칙)의 어드레스는 각 규칙이 적용되어야 하는 상황을 구분할 수 있다고 생각한다.아직까지는 설명되지 않았지만, 가끔 그리스식 명명 규칙을 선호하는 이유의 일부는 그 이름이 주로 마네토와 같은 학자를 통해 우리를 통해 내려왔을 때다(PMANDerson의 예들 중 첫 번째 두 가지인 Menes와 Ramesses는 그 범주에 잘 들어맞는다.우리가 말기 파라오, 특히 헤로도토스와 같은 그리스 역사학자가 연대기를 쓸 수 있는 시대에 살았던 사람들에 대해 이야기할 때 상황은 복잡해진다.그래서 우리는 이집트 와히브르나 와히브르 하이브르 대신 압리와 같은 괴짜들을 얻는데, 이것은 불행하게도 26왕조의 다른 파라오에 사용되는 이집트식 명명 규칙과는 일치하지 않는다.이것은 또한 이따금 눈에 띄는 파라오에게 프센네스 1세까지 거슬러 올라가며, 그 정보가 거기에 있는 것 같지는 않지만, 나는 같은 시간 틀에 열거된 여러 오르소콘들이 이름으로는 이집트인보다 그리스인일 것이라고 의심한다.(내 출처를 다시 확인하고 보고를 할 것이다.)

그러나 요약하자면, 고대 이집트 명명 규칙은 일관성이 있으며, 제3중간기 시대까지, 후기 고대 이집트 역사의 많은 부분이 그리스 고학자들에 의해 거의 독점적으로 전달되어 상형문자가 해독될 때까지 영어로 진행되었던 시기까지이다.내부의 일관성을 위해 후대의 파라오들에게 주어진 이름들을 다시 찾아보는 것이 이치에 맞을지도 모른다.캡몬도 (대화) 2008년 10월 29일 19:14 (UTC)[응답]

내 귀에는 그리스어처럼 들리지만, 오르소콘은 합법적인 고대 이집트어 번역본이라는 것이 밝혀졌다.그리고 그리스 이름을 후대의 파라오(아프리스 등) 대 고대 이집트의 형태(동일한 파라오에 대한 와이브레)에 사용할 것인가에 대한 최근의 학자들의 의견이 분분하다.그러나 일관성의 명목상 그것이 전체적인 경향인 것 같기 때문에 고대 이집트 이름으로 가는 것이 더 타당하다고 생각한다(Khufu vs 목격자).주장을 굽히다.나는 대신 Apries 기사의 이름을 Waibre로 바꿀 것을 제안하고, 위키백과를 자주 하는 사람들의 의견을 부탁할 것이다.위키프로젝트 고대 이집트.그래서 결국, 나는 사물의 "그리스어 이름 없음" 측면을 주장할 것이다. 이것은 항상 WP와 일맥상통하는 것이다.NC. 캡몬도(토크) 18:37, 2008년 11월 6일 (UTC)[응답]

나는 이것이 어리석은 "일관성"이라고 믿는다; 우리는 호보블린을 제거하자.우리는 고대 이집트를 안와르 사다트보다 더 많이, 그리고 같은 이유로 아파트는 우리의 독자와 소통하지 않으며, 실제로 영어 사용자들과도 소통하지 않는다.나는 무조건적으로 이 페달 밟는 것에 반대한다.2008년 11월 6일(UTC) 18:46, Sentrionalis PMAnderson 18:46[응답]

내 요점은 충분히 타당성이 있으며, 적어도 최근에 출판된 인기 있는 책 몇 권을 Apries 대신 Waibre를 사용하는 주제에 대해 인용할 수 있다.피터 A.클레이튼의 "바로스의 연대기"는 도슨과 힐튼의 "고대 이집트의 완전한 왕족"처럼 이집트 제26왕조의 모든 파라오에게 고대 이집트 이름을 사용한다.둘 다 이 주제에 관한 일부 대학 강좌의 교과서/참고로 사용되고 있기 때문에, 요즘 이 파라오의 주제에 관심이 있는 사람은 누구나 그리스인이 아닌 이름에서 출발할 가능성이 높다.실제로 그 왕조의 다른 파라오마다 단 한 가지 예외(네카우/네초 역시 바뀌어야 한다고 주장할 것임)만 있다면 우리는 그리스어 대신 고대 이집트어 이름을 사용한다(즉, 아마시스 대신 아모세 2세).원래의 아모세 1세는 그리스 아마시스 1세에 의해 거의 언급되지 않기 때문에 후자는 특히 좋은 예다.

일관성이 반드시 유행을 따르는 것은 아니며, 나는 그것을 그렇게 특징짓지 않을 것이다.

당신의 안와르 사다트 예를 들자면, 나는 당신이 그 주장을 오해한 것이 아닌지 의심해야만 한다: 그것은 그렇게 하기 위해서 고대의 이집트 이름을 엄격하게 사용하는 것이 아니라, 일반적인 영어 사용이 우리에게 내려온 그리스어 명명 규칙보다 그 이름들을 선호하는 것처럼 보이기 때문이다.Khufu vs. 그리스 치프스의 좋은 예, 체프렌의 디토 카프라, 소리스의 스네페루.나는 이집트의 26번째 왕조에 사용된 이름들의 나중에 호지-포드가 후기 파라오들이 일반적으로 초기 시대의 파라오들 보다 덜 알려져 있고, 어떤 경우에는 그리스 이름이 여전히 널리 퍼져 있기 때문이라고 추측한다.고대 그리스 학자들의 영어 번역기 사용 경향에 따라, 나는 이러한 형태의 일관성이 페더레이션이 아니라 전반적인 경향에 부합한다고 주장한다.

그리고 또한 안와르 사다트는 사실 안와르 엘 사다트라는 제목이 붙어 있는데, 이것은 WP와 엄격히 부합되지 않는다.NC도 마찬가지야.그래서 사실 당신 자신의 주장에 대한 반례.

그래서 나는 너의 "홉고블린"이 잘못되었다는 것을 정중히 제출한다.;-) 캡틴몬도 (대화) 21:32, 2008년 11월 6일 (UTC)[응답]

핵심 질문들

자, 간단한 질문 하나 할게:WP:NC의 예외일 고대 이집트에 관한 기사 명칭에 대한 체계적인 명명 규약이 필요한 상황이 있는가? 그 문제를 1번 질문으로 부르겠다.

관련되고 좀 더 구체적인 질문이 있다.전통적인 이름이 여전히 일반적인 이름임에도 불구하고 고대 이집트 이름이 그리스에서 유래된 전통 이름보다 기사 이름으로 선호되어야 하는 상황이 있는가?2번 질문으로 할게.

나는 사실 그것들이 다른 용어로, 모든 실제적인 목적에서 같은 질문이라고 생각한다.그러나 그것은 어느 쪽이든 별로 중요하지 않다.문제는, 만약 어느 쪽이든 '예'라고 대답한다면, 고대 이집트에 관한 기사에 대한 구체적인 명명 규칙이 필요하다는 겁니다.WP의 새로운 단락:NC 또는 WP의 새로운 지침:NC가 연결돼 있다.

반면에 두 가지 모두에 대한 대답은 '아니오'라면, 내가 제안하고 싶은 것처럼, 여기서 의견이 모아지고 있다면, 새로운 가이드라인은 필요 없으며, 제안된 가이드라인은 거부되어야 한다.

Cheops/Khufu도 WP의 예외가 아니다.NC. 이 사건은 현재의 영어 사용으로 볼 때 쿠푸에 대해 {결국) 만들어진 것이었다.che스/쿠푸 논쟁의 유일한 관련성은 그것이 (제안된) 특정 명명규칙의 반관례적 지위를 다시 주목하게 했다는 점이다.안드레와 (대화) 2008년 11월 1일 12시 25분 (UTC)[응답]

음, 최근 논평은 없어.다 끝났으면 이제 제안된 명명 규칙을 거부된 것으로 플래그 지정하시겠습니까?안드레와 (대화) 2008년 11월 13일 (UTC) 17:00[응답]

NC는 없다. — Werdna • talk 09:34, 2008년 11월 16일 (UTC)[응답]

WP:NC는 고대 이집트의 군주들을 위한 명명 정책과 일치한다.파라오 아프리(그리스어 파생어)를 위해 고대 이집트 이름 와히브레를 사용하자는 최근 제안은 WP와 일치하는 이유로 사실상 반대되었다.NC, 즉 그리스어에서 유래된 이름이 영어에서 훨씬 더 흔하다는 것이다.

나는 원래의 제안이 위키피디아에 관한 고대 이집트 사물에 관심이 있는 사람들의 커뮤니티 내에서 비공식적인 지침으로 의도되었다고 말하는 것이 타당할 수 있다고 생각한다. 그리고 WP에 공식적인 변화는 필요하지 않다.이를 수용하기 위한 NC.캡몬도 (대화) 2008년 11월 17일 (UTC) 17:13[응답]

위키백과 정의 방법

위키피디아 목록을 보면, 모든 항목이 정말로 "위키페디아스"로 분류되어야 하는지 궁금하다 - 나는 볼라푸크 위키피디아에 있는 대부분의 항목이 봇에 의해 만들어졌고 단편적이라는 것을 읽은 적이 있다.쵸토 위키피디아는 단지 15개의 예술작품을 가지고 있다.우리는 위키피디아가 위키피디아의 자격을 갖추기 전에 최소한의 기사를 써야 하고 좋은 범위의 주제를 다루어야 한다고 말해야 할까?ACEOREVIVEED (토크) 21:16, 2008년 11월 6일 (UTC)[응답]

나는 너의 제안을 이해할 수 없다.일부 기준을 충족하지 못하는 위키백과에는 위키백과 이외의 다른 이름이 부여되도록 제안하는 겁니까?무슨 이름?몇 개의 기사?어떤 측정이 "좋은 범위의 주제 포함"을 정의하고 있는가?—마이클 Z. 2008-11-07 17:53 z

당신의 제안은 위키백과 목록에서의 표를 줄이거나 바꾸는 것 뿐인가?Talk에 게시하셨습니다.위키백과 목록프라임헌터(토크) 2008년 11월 7일(UTC) 18시 30분[응답]

응답에 감사드리며, 여기 복잡한 문제들이 있다고 본다. 예를 들어, 위키백과가 위키백과로 분류되기 위해서는 최소한 50개의 기사가 있어야 한다고 말한다면, 위키백과 언어판 한 판은 51개의 기사로 자격이 주어지고, 다른 판은 49개의 기사로 되어 있지 않다.나는 또한 위키피디아의 유용성은 기사 번호로만 측정되고, 다루는 기사 범위에서는 측정되지 않는다고 말하는 것은 오해의 소지가 있다고 생각한다(나는 여기 사람들에게 현재 위키피디아 목록 상위 20위 안에 드는 볼라푸크 위키피디아에 대한 기사를 읽으라고 충고하고 싶다 - 놀랍게도 에스페란토어로 위키피디아를 능가한다).웹 어딘가에서 "좋은 위키피디아가 가져야 할 모든 필수 기사 목록"을 읽을 수 있는 곳이 있다. - 구글 검색을 하고 "위키피디아 목록"을 입력하면, 당신은 내가 무슨 뜻인지 알게 될 것이다.Prime Hunter, 나는 당신에게 나의 제안이 위키피디아 목록과 관련이 있다는 것에 동의한다 - 나는 확실히 이 리스트가 구조조정이 필요하다고 생각한다.아마도 이 이슈는 그곳의 토크페이지에 가장 적합할 것이다.다시 한 번 댓글을 달아줘서 고마워.ACEOREVIVEED (토크) 21:26, 2008년 11월 7일 (UTC)[응답]

나는 위키백과 기사를 언급하고 있었던 것 같다: 위키백과에서 중요한 기사: 이제 기사_all_all_anguage_hould_have가 리디렉션될 것이다.이것은 그 자체로 논쟁의 여지가 있는 항목으로, 그것의 토크 페이지는 밝히고 있다. (그 목록은 사회과학과 철학에 너무 치우친다는 주장이 있다.) 그러나 적어도 1,050개의 기사를 가진 위키피디아가 800개의 기사를 가진 위키피디아가 더 나을 수 있다는 오해를 피하는 데 도움이 된다.ACEOREVIVEED (토크) 21:48, 2008년 11월 7일 (UTC)[응답]

WP:DEADLine을 참조하십시오.다른 언어로 된 위키피디아가 비활동적이라는 것은 현재 미래에 대한 어떤 의미도 갖고 있지 않다.그들은 해를 끼치지 않고 있으며, 우리가 위키피디아를 개선해야 하는 시간인 무한한 시간을 주어, 그들은 결국 돌아올 것이다. --Jayron32.talk.contracts 21:57, 2008년 11월 7일 (UTC)[응답]

위키피디아의 콘텐츠 부족을 이유로 재단이 위키피디아를 폐쇄하지 않는 한 말이다.DendodgeTalk^Contribs 22:01, 2008년 11월 7일 (UTC)[응답]

나는 재단이 콘텐츠 부족으로 인해 사업을 중단한 적이 없다고 믿으며, 공공 기물 파손이 정리되지 않아 프로젝트가 잠기지 않으면 완전히 난장판이 된다는 뜻의 기부자 부족으로 사업을 중단했다. --Tango (토크) 2008년 11월 14일 (UTC) 13:47, 2008년 11월 14일 (화) 응답

역사적으로 관심이 있는 문제로서, 누가 다른 언어들을 위한 별도의 위키피디아들이 있어야 한다고 결정했는지 아는 사람이 있는가?훨씬 더 분명한 것은, 확실히, 다른 어떤 작품에서도 그랬듯이, 언어 버전이 다른 하나의 위키백과가 있어야 한다는 것이다.바벨의 힘은 극복하기엔 벅찬 느낌이었을까?--코트니스키 (토크) 10:10, 2008년 11월 8일 (UTC)[응답]

그렇게 되면 어떤 언어가 기본이 되어야 하는지에 대한 논쟁으로 이어질 것이고, 토크 페이지는 모두 다른 언어로 되어 있어야 할 것이다.서버에서도 더 쉬울 겁니다.Dendodge Talk^Contribs 10:14, 2008년 11월 8일 (UTC)[응답]

코티스키:그것이 (명목상 제외) 현재 상황과 어떻게 다를까?대수학자 10:52, 2008년 11월 8일 (UTC)[응답]

글쎄요, 논란의 여지가 있는 문제를 결정하는 커뮤니티가 하나 있을 것이고, 감시 목록과 같은 것들이 다국어 편집자들에게 훨씬 더 효과적일 것이고, 기반 구조의 많은 부분(범주, 인포박스, 참고 자료 목록 등)이 공유될 수 있을 것이다.그 소프트웨어는 틀림없이 많은 표준 항목을 언어 간에 자동으로 번역하도록 진화했을 것이다.모든 것이 매우 다를 것이다(그리고 더 좋을 것이라고 생각하지만, 지금은 알아낼 방법이 없다).--코트니스키 (토크) 13:44, 2008년 11월 17일 (UTC)[응답하라]

음, 가장 중요한 것은 이러한 프로젝트들이 위키프로세서를 사용하여 활발하게 편집되고 있기 때문에 "위키피디아"라고 불리지 않고, 그것이 그들의 이름이기 때문이다.조스 베이커리라는 가게는 빵을 하나도 팔지 않더라도 여전히 조스 베이커리라고 불릴 것이다.장기적으로는 그들이 진정한 위키백과가 되기를 바란다.Dcoetzee 09:34, 2008년 11월 9일 (UTC)[응답]

나는 어떤 사람이 다른 위키피디아의 다른 언어판이 있어야 한다고 "결정"했다고 생각하지 않는다 - 나는 그것이 단지 일이 일어난 방법이라고 생각한다.새로운 언어로 위키피디아를 시작하는 것은 위키미디어 인큐베이터에 아이디어가 받아들여지는 복잡한 과정을 의미할 것이다. 예를 들어, 라코타 위키피디아를 시작하자는 제안이 그곳에서 만들어졌고, 나는 필리핀과 올드 노르드 위키피디아에 대해 비슷한 아이디어가 만들어졌다고 믿는다.나는 한 사람이 다른 언어로 된 동일한 형식의 단일판을 가지는 것이 다른 출처들, 예를 들어 다른 판본을 가진 성경이나 브루노 베텔하임이 지적한 대로 영어로 번역된 지그문트_프루드의 작품들과 같이 실제로 일어나는 일이라고 정확히 말할 수 있다고는 생각하지 않는다.원래 독일어에 충실하지 못했다.나는 또한 연극의 번역이 때로는 문자 그대로의 번역이 아니라는 것도 알고 있다.ACEOREVIVEED (토크) 2008년 11월 9일 (UTC) 20:25 [응답]

위키백과는 위키백과다.왜 많은 기사들이 관련되는가?— Werdna • talk 13:41, 2008년 11월 14일 (UTC)[응답]

고급 수표?

위키피디아는 현재 WP와 같은 새로운 사용자들에게 그것의 기본적인 특징과 마크업을 소개하는 많은 페이지를 가지고 있다.자습서 및 WP:체츠시트.그러나 좀 더 발전된 위키 마크업(트리플 브레이스 브래킷, IFREQ 등)에 대한 사용자 친화적인 가이드는 본 적이 없다.이러한 특징들(예: 가새 받침대 끈)은 현재 나에게 가장 진보된 템플릿을 의미 없게 만들고, 따라서 내가 어떻게 해야 하는지를 배우기를 열망하지만 그것들에 기여할 수 없게 한다.현재 작업에 정통한 사람이 작업 방법을 안내하고 그에 따라 자신만의 복잡한 템플릿을 만드는 것이 가능할까?It Is Me Here (토크) 2008년 11월 9일 (UTC)[응답]

• 대부분은 자신의 도움말인 네임스페이스 페이지가 있지만 가이드가 유용할 것이다.다른 사람이 가이드를 만들겠다고 제안하는 사람이 없다면 그렇게 하겠지만, 나는 여기서 가장 박식한 사람이 아니다.DendodgeTalk^Contribs 19:38, 2008년 11월 9일 (UTC)[응답]
  • 음, 적어도 하나를 시작하고 당신이 알고 있는 것을 추가할 수 있다면, 그것은 매우 감사할 것이다.It Is Me Here (토크) 17:50, 2008년 11월 10일 (UTC)[응답하라]
    • 아니면 당신은 2004년 이후로 우리가 이미 가지고 있는 것을 읽을 수 있을 것이다.☺ 삼촌 G (토크) 15:50, 2008년 11월 11일 (UTC)[응답하라]

위키백과:위키백과에 대한 편집자 색인(주요 도움말 메뉴에 링크됨:콘텐츠)는 앞선 도움을 찾는 두 곳이다.자조하다.누락된 것을 발견했을 때, 그것들을 쓰도록 도와줘. :) -- Quidity (대화) 08:26, 2008년 11월 15일 (UTC)[응답]

좋아, 링크 고마워, 얘들아.It Is Me Here (토크) 07:23, 2008년 11월 17일 (UTC)[응답하라]

크리켓

나는 호기심이 많아서 이리로 온다.하지만 무작위 기사를 보면, 그들 중 절반은 크리켓 선수들에 관한 것이다. 정말 크리켓에 관한 많은 통계를 필요로 하는 사람이 있는가?하나의 제목이나 주제나 그 어떤 것으로 그들을 "해결"할 수 있는 방법이 있는가?고마워요.

위키백과의 262만2933개 중 12078개는 '크리켓'의 주제와 관련이 있는 것으로 평가되는데, 이는 믿을 수 없을 정도로 적은 비율이다.무작위 기사 버튼은 그저 무작위일 뿐이므로 표본 크기가 작은 예상치 못한 결과를 얻는 것은 놀랄 일이 아닐 것이다.난 그냥 무작위로 10개의 기사를 골라서 축구선수 두 명, 종 한 명, 고대 전투 한 명, 앨범 두 장과 예술가 한 명, 의회 의원 한 명, 라디오 쇼와 우표 가격 리스트를 얻었어. 백과사전을 채우기 위해서는 온갖 것이 다 필요하단 말이야!해피멜론 17:27, 2008년 11월 14일 (UTC)[응답]

그것은 거의 반퍼센트다; 거의 믿을 수 없을 정도로 작다. (그러나 OP의 50%가 미친 무작위적인 우연이었을 것이다.)크리켓은 영어 위키피디아에 지나치게 많이 실려 있다.그 이유는 많은 매우 활동적인 기고자들이 이 주제에 집중하기 때문이다(Wikipedia:위키프로젝트 크리켓).이 "문제"에 대한 유일한 합리적인 "해결"은 다른 과목에 대한 기사를 쓰는 것이다.체계적 편견에 대항하는 정신에서 위키피디아의 문제는 우리가 잘 다루는 주제가 아니라, 그들이 분명해 보일지라도, 우리가 잘 다루지 못하는 주제들이다. -- 자오 (토크) 18:30, 2008년 11월 14일 (UTC)[응답]

좀 더 정확히 말하면 0.46%인데 WP에서는 다음과 같이 생각한다.CRIC는 특히 우리가 여전히 파란색보다 더 많은 빨간 링크를 가지고 있기 때문에 그것에 대해 매우 기뻐할 수 있다.예를 들어, 우리는 19세기에 거의 손을 대지 않았고 영국 밖에서 국내 크리켓에 대한 우리의 보도는 많은 작업을 필요로 한다.이것은 과대포장되기는커녕 크리켓은 여전히 과소포장되어 있지만 상대적으로만 그렇다는 것을 의미한다."문제"가 더 많은 모집과 더 많은 참여를 필요로 하는 다른 많은 프로젝트들과 함께 있다는 것은 자오가 옳다.나는 크리켓이 100개 이상의 국가에서 행해지고 있는 세계적인 스포츠로, 특히 아대륙에서 10억 명으로 추정되는 팬 층을 가지고 있는 것에 대해 모호한 점이 없다는 것을 지적하고 싶다.WP:CRIC는 다른 사람들이 따를 수 있는 표준을 정하고 있는 몇 안 되는 위키프로젝트 중 하나이다.기타 고급 프로젝트는 WP:MILHIST 및 WP:풋볼. 우리가 어떻게 돌아가는지 알고 싶은 사람이 있다면 WT:CRIC에서 토픽을 열어라. 참가하고 싶은 사람이 있다면 WP:CRICMEM – 가장 환영받을 것이다. ---BlackJack 07:09, 2008년 11월 15일 (UTC)[응답]

• 글쎄, 이 억만장자에도 불구하고, 크리켓은 많은 사람들에게 알려지지 않은 것처럼 보이지만, 분명히, 어떤 스포츠에 대해서도 언급될 수 있다.아니면 거의 어떤 주제에 대해서도 말할 수 있기 때문에 가볍게 받아들이자는 뜻이었는지도 모른다.--자오 (토크) 07:38, 2008년 11월 15일 (UTC)[응답]

• 10억 :-) 팬층이 뭔지는 모르겠지만 상당히 적은 것 같아. ---블랙잭 22:21 (UTC) 2008년 11월 15일 (답)

• 위키백과의 경우:위키프로젝트 삭제 정렬/크리켓은 어떤 것이든 사용할 수 있으며, 현재 레드링크도 받고 있다.☺ 삼촌 G (토크) 2008년 11월 15일 (UTC) 15:06[응답]

그렇긴 한데, 그 기사들은 프로젝트 멤버가 지명한 후에 삭제되었어.우리는 그것을 위해서만 물건을 보관하는 것이 아니다.---BlackJack 16:17, 2008년 11월 15일 (UTC)[응답하라]