위키백과:마을 펌프(제안)/아카이브 12
Wikipedia:이 페이지에는 빌리지 펌프(제안)에서 보관된 토론이 수록되어 있다.이 페이지의 내용을 편집하지 마십시오.이러한 토론 중 하나를 다시 시작하려면 새 스레드를 시작하거나 해당 주제와 관련된 대화 페이지를 사용하십시오.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125,126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188
조정 및 지도 정보 토론
위키백과에서 진행 중인 기사에 좌표 및 지도 정보를 포함시키는 것에 대한 논의:위키프로젝트 지리 좌표#Geolinks-cityscale. --SEILco (대화) 15:33, 2007년 12월 28일 (UTC)[
영구적인 물품 만들기
일단 완전히 정확하고, 최신이며, 품질이 매우 우수하다고 여겨지는 일부 기사는 해당 주제에 관한 새로운 정보가 발견될 때까지 해당 상태로 저장되어야 한다.이는 과학적인 기사에 가장 잘 적용되는데, 일반 대중은 그 기사에 오류가 있다고 잘못 믿기 때문에 완벽하게 정확한 과학 기사를 편집하는 경우가 많기 때문이다.기사를 반영구적으로 만드는 것은 우선 기사가 올바른 정보를 묘사하고 둘째로 공공 기물 파손으로부터 보호한다는 것을 보장할 것이다.—67.84.10.3 (대화) 20:58, 2007년 12월 28일 (UTC)[에 의해 서명되지 않은 논평 준비
- 물건은 절대로 안 된다.주제에 관한 새로운 정보가 나오지 않을 때에도, 그것에 관한 견해는 끊임없이 변화하고 있으며, 다른 어떤 조직과 흐름도 항상 개선될 수 없다.게다가, 기사의 "완성" 여부를 어떻게 결정하는지를 알아내는 것은 엉망일 것이다.Dcoetzee 23:36, 2007년 12월 28일 (UTC)[
- 위의 코멘트에 바로 동의하지 않고 베로피디아와 WP를 살펴보십시오.EIW#Stable. -- John Browton (차가운) 23:54, 2007년 12월 28일 (UTC)[하라
- 우리는 이미 "영구적인 기사"를 가지고 있다. 이것은 좋은 기사나 특집 기사로서 통과된 기사들의 버전이며, 토크 페이지의 {{기사역사}상자에 나열되어 있다.나는 위키에 정통하지 않은 독자가 그러한 승인된 버전의 기사를 좀 더 쉽게 접할 수 있도록 하는 조치를 지지한다.--파로스 (토크) 03:42, 2007년 12월 30일 (UTC)[
자동화된 웹 사이트 도구
위키피디아 페이지에서 링크된 페이지를 웹사이트를 사용하여 보관 요청을 한 다음 "활성" 페이지 대신 보관된 페이지로 연결하는 자동화된 웹사이트 도구를 개발하면 좋을 것이다.이것은 링크로트 문제를 예방하고, 기사에 인용된 모든 웹 참조를 보관한 후 보관된 페이지로 연결하려는 편집자들의 엄청난 노력을 덜어줄 것이다.이것이 가능한가?댓글?---필(대화) 00:17, 2007년 12월 29일 (UTC)[
- 인용되는 대부분의 페이지들은 저작권이 있으며, 특히 신문 소유주들은 페이지를 온라인 보관소에 복사하는 것에 강한 거부감을 가질 것이다.위키백과 편집자들이 그렇게 하는 것을 쉽게 만드는 것은 (내 생각에) 미국신문협회로부터 소송을 제기하는 것이다.나는 편집자들이 완전한 시트를 하도록 하는 것이 더 유익할 것이라고 생각한다; 그렇게 함으로써, 링크가 나빠지더라도, 그 출처는 여전히 오프라인으로 체크될 수 있다.또는 오프라인 소스가 없는 경우 archive.org을 통해. -- John Brown (바닷컴) 22:01, 2007년 12월 29일 (UTC)[
이메일
- 설명
- [사람들이 wikimail이나 e-메일을 가질 수 있도록 이메일 서버를 만든다. yourname@wikipedia.org 또는 yourname@wikimail.org과 같은.
- 관심 있는 위키백과 사용자(이름 추가)
- 이것은 큰 프로젝트일 것이지만 위키피디아에 더 많은 히트곡을 낼 수 있을 것이다.—Kintetsubuffalo가 추가한 서명되지 않은 코멘트 준비 (대화 • 기여) 00:17, 2007년 12월 29일
- 그게 무슨 소용이야?gmail과 경쟁하는 것이 서버 공간을 더 많이 차지하지 않고 어떻게 할 수 있을까?미스터 지만 04:22, 2007년 12월 29일 (UTC)[
- 무엇을 숨겨야 하는가?(나는 매일 너의 이메일을 읽는다.)2007년 12월 29일 07:38(UTC) 이하[
이미지 시스템 제안서
나는 상대적으로 처음이지만, 여기 공정하게 사용하는 임피지 업로드 및 관리 시스템에 대한 몇 가지 제안서를 작성했다. 사용자:Mbisanz/ImageSystemProposal 및 코딩 방법을 알고 있는 사용자나 코멘트가 있으면 코딩할 수 있는 사용자들을 찾고 있다.Mbisanz (대화) 06:52, 2007년 12월 29일 (UTC)[
중복 스텁이 너무 많음
약 30만 종의 식물과 100만 종 이상의 동물로 추정된다.어떤 사람들은 그들 한 사람 한 사람에 대한 기사를 갖고 싶어 하는 것 같다.다른 웹사이트에서 이런 기사를 만드는 일을 하는 여러 봇들이 있다.이 봇으로 만들어진 모든 기사들은 처음에는 아주 짧은 단조로운 것들이고, 그 너머 어디에서도 그것을 만드는 사람은 극히 드물다.알로에이데스속(Aloeides)을 예로 들어보자.11종의 기사 중에서 7월에 봇을 만들었을 뿐 편집된 것은 단 한 건도 없다.나는 무작위 호출과 새로운 기사가 순찰하는 동안 이 쓸모없는 무수히 많은 다른 찌꺼기들을 보아왔다.나는 그것들을 쓸모없다고 부른다. 왜냐하면 그것들은 쓸모없기 때문이다; 그들 중 어느 한 곳에도 독특한 정보의 단 한마디도 없다.
주범인 User의 또 다른 예:폴봇은 일본의 저명한 사진작가 중 한 명인 사에키 게이조부로인데, 이 중 328명의 웹사이트 목록에서 모두 생성되었다.나는 일편단심의 기사가 유용하다는 것을 믿기 어렵다.한 가지 리스트는 그들 모두와 함께 만들어져야 한다.
내 제안은 간단하다:어떤 것에 관한 기사는 그 자신의 페이지를 보증하기에 충분한 독특한 자료를 가지고 있어야만 만들어져야 한다. 만약 그렇지 않다면, 리스트는 완벽하게 받아들여질 수 있다.만약 스텁이 쉽게 모조 기사로 병합될 수 있다면, 그렇게 해야 한다.사실, 이 개인의 공신력 이론은 또한 사람, 장소, 그리고 다른 주제들에 기인할 수 있다.
식물/동물 예에 따라, 모든 종은 충분한 고유 정보가 발견될 때까지 속기사에 포함되어야 한다.사람과 장소는 그 사람/장소와 관련된 것이 더 많이 발견될 때까지 훌륭한 목록을 가질 수 있다.
분명히, 아마도 가장 좋고, 가장 흔하고, 가장 강력한 반박은, 이러한 모든 기사들은 합법적인 주제로서, 결국 특집 기사가 될 수도 있고 그렇지 않을 수도 있다는 궁극적인 반증일 것이다.나는 이것에 전적으로 동의한다.나비의 한 종은 생태계에 필수적이고 일본 사진작가는 그 자신의 권리로 중요하고 주목할 만하다.그러나 어떤 주제가 결국 한 걸음 더 나아가고 두 번째 문장이 작성될 때까지, 나는 개별 조항이 하나로 병합된 상태를 유지할 것을 주장한다.이러한 주제들은 주목할 만하지만, 좋은 출처를 가지고 있는 경우가 드물고 사용하기에는 너무 짧다.
모델로서 독일어 위키피디아는 비록 대통령에 관한 것이라 하더라도 그런 짧은 글은 허용하지 않을 것이다.그러나 나는 우리가 독일어 위키피디아가 아니라는 것을 인정하겠고, 가상의 등장인물들을 위한 것과 같은 그들의 합병의 일부는 너무 격렬하다는 것을 인정하겠다.
불필요한 이 기사들을 병합하기 위한 첫 번째 단계는 그것들을 자동으로 쓰는 봇들을 막는 것이다.이러한 봇의 지지자들은 이러한 즉시 스텁이 다른 사용자가 스텁에 추가할 수 있는 시작점이라고 주장한다.그러나, 나는 어쨌든 그 기사들은 몇 줄만 포함하고 있기 때문에, 리스트가 완벽하게 받아들여질 수 있는 출발점이 아니라는 것을 절대적으로 이유가 없다고 본다.게다가 아까도 말했지만 이 점은 7월 이후 위의 나비 종 페이지는 손도 대지 않아 무효가 되고, 노력하면 그보다 더 오래된 종들을 많이 발견할 수 있었다.결국?어쩌면지난 6개월 동안 독특하고 유용한 콘텐츠가 없었는가?절대 아니다.그리고 아니, 나는 가장 짧은 페이지를 위해 사이트를 뒤지지 않았다; 더 많은 재치 있게 짧은 기사들이 있다.
나는 네가 많은 불필요한 그루터기의 군더더기들을 볼 수 있기를 바란다.나는 많은 사람들이 이것에 반대할 것이라고 확신하지만, 나는 내가 내 주장을 분명히 밝혔기를 바라며, 많은 사람들이 중복되는 1라인 선수들은 여기서 원하지 않는다는 것에 동의할 것이다.감사합니다 레이와스92Talk 00:21, 2007년 12월 15일 (UTC)[
- 나는 너의 말에 동의하지만, 네가 제안하는 실천의 변화에 대한 충분한 지지가 어디에도 없다고 생각해.내가 더 걱정되는 것은 봇이 이런 기사를 만든다는 생각이다.나는 이것이 진행되는지 몰랐고, 걱정된다.어떻게 하면 봇들이 다른 웹사이트에서 정보를 수집하고 그들을 위한 기사를 위키피디아에 만들 수 있을까?확실히 이것은 노골적인 저작권 위반이다.또한, 봇은 자신이 기여하는 것에 대한 공신력(또는 정확성)을 전혀 평가할 수 없다.—gorgan_allyty (talk) 12:44, 2007년 12월 18일 (UTC)[
- 나는 폴봇을 운영한다.데이터 자체는 저작권을 가질 수 없기 때문에 정보를 복사하는 것은 결코 저작권 위반이 아니다.프레젠테이션(예: 전체 문장)만 저작권을 가질 수 있다.Feist Publishes 대 농촌 전화 서비스를 참조하십시오.– Quadell 17:58, 2007년 12월 18일 (UTC)[
- 나는 너의 말에 동의하지만, 네가 제안하는 실천의 변화에 대한 충분한 지지가 어디에도 없다고 생각해.내가 더 걱정되는 것은 봇이 이런 기사를 만든다는 생각이다.나는 이것이 진행되는지 몰랐고, 걱정된다.어떻게 하면 봇들이 다른 웹사이트에서 정보를 수집하고 그들을 위한 기사를 위키피디아에 만들 수 있을까?확실히 이것은 노골적인 저작권 위반이다.또한, 봇은 자신이 기여하는 것에 대한 공신력(또는 정확성)을 전혀 평가할 수 없다.—gorgan_allyty (talk) 12:44, 2007년 12월 18일 (UTC)[
- 나도 동의해.—gorgan_allyty (talk) 2007년 12월 19일 (UTC) 10:42[
쿼델은 폴봇을 기사 작성이 용이하도록 도구로 사용한다.봇이 스스로 하는 것이 아니다.만약 당신이 이 기사들을 좋아하지 않는다면, 관련 분류 프로젝트와 함께 그것을 가져보는 것은 어떨까?이것은 그런 직책에는 거의 어울리지 않는 것 같다.독일어 위키백과는 스터브 템플릿의 사용을 금지했지만, 이 이름으로 부르지 않더라도 스텁 기사의 점유율은 여전히 가지고 있다(예: de:에릭 에릭센, 드:칼 테오도르 자흘, 드:코넬리우스 알프레드 몰로니, 드:마구자와, 드:와펜 카메룬).de:Wikipedia:아티켈#음팡_(Stubs)는 너무 짧은 글의 예로서 "루드비히 2세는 바이에른의 왕이었다"고 이름지었으나, 유효(그러나 짧음) 기사로 "루드비히 2세 (1845년 8월 25일 ~ 1886년 6월 13일)는 바이에른의 왕이었다"고 한다.독일인들이 한 일은 그루터기 분류 프로젝트와 동등한 것을 제거하는 것뿐이었다.발렌티니아어 14:11, 2007년 12월 19일 (UTC)[
- 만약 이것이 완전히 자동화된 봇이 아닌 도우미 프로그램이라면 그것은 나쁘지 않다.나는 우리가 "봇"과 같은 프로그램을 언급하지 않았으면 좋겠어, 매우 혼란스러워.공교롭게도 봇을 이런 식으로 쓸 수 있느냐 없느냐가 정책의 문제인 만큼 여기서 토론하는 것이 옳다.—gorgan_allyty (talk) 2007년 12월 20일(UTC) 10시 15분[
한 문장 뭉침은 식물에 대해 많은 것을 말해줄 수 있다.기사가 전혀 없는 것보다는 한 가닥 단조로운 것이 낫다.어쨌든 식물의 모든 종에는 수십 가지의 자원이 존재하며, 지금 한 가지 내용인 것은 시간이 흐를수록 성장할 것이다(위키피디아는 결국 유기적인 것이며, 즉시가 아니라, 즉석에서 이루어지는 것이 아니다).유용한 내용을 삭제하는 것은 생산적이지 않고 위키백과에 도움이 되지 않는다. --Oldak Quill 05:33, 2007년 12월 22일 (UTC)[
- 한 문장의 스텁을 한 글에 십여 개의 섹션으로 합치면 두 가지 목표를 모두 달성할 수 있다. - 정보는 보관되고 그 가치를 높이는 다른 정보로 둘러싸여 있다. - 백과사전은 단 한 문장짜리 스텁 기사를 많이 가지고 있지 않기 때문에 더 좋아 보인다.물론 원래의 타이틀은 모두 합병된 최종 제품으로 리디렉션될 것이다.건배! bd2412T 00:06, 2007년 12월 23일 (UTC)[
- 합치는 데는 장단점이 있다.합병의 단점으로는 분류법 조항(종류가 많으나 일부는 합병하도록 강요되는 경우), 종을 차등 분류할 수 없음(합병된 조항은 분류할 수 있는 반면, 종마다 다른 범주는 추가할 수 없음) 및 조항 디벨로의 비우호성으로 합병을 들 수 있다.pment (나는 어떤 AfD 공정에서 유래한 호지포지 병합 기사보다 짧은 종족 기사에 덧붙일 가능성이 더 높다.)"백과사전은 많은 단조로운 기사들을 가지고 있지 않기 때문에 더 좋아 보인다." - 당신은 이 가정을 무엇에 근거하고 있는가?링크를 따라다니며 검색으로 기사를 찾는 독자로서, 나는 병합된 글의 앵커 포인트로 리디렉션되는 것보다 한 스텐트 스텁을 다루는 것을 더 좋아한다.이산 단위는 장점이 있다! --Oldak Quill 02:03, 2007년 12월 23일 (UTC)[
- 음.. 대부분의 경우 그렇듯이, 어떻게 외향적인 스텁이 존재 이외의 것을 말해주는가?한 문장의 병합된 목록으로 리디렉션하는 것이 더 낫다.내가 전에 말했듯이, 이론적으로 시간이 지나면서 이론적으로 성장할지 모르지만, 그들은 확실히 아직 성장하지 않았다.몇 개 더 추가될 수 있을 때 소위 유용한 단일 문장을 삭제하십시오.레이와스92Talk 00:38, 2007년 12월 23일 (UTC)[
- 단 하나의 문장은 다음과 같다: "[공통 식물명] (라틴 이항체)는 유럽 전역에서 찾아볼 수 있는 [식물의 종류]이며 항염증 성질로 잘 알려져 있다."그것은 한 문장에서 5가지 사실에 관한 것이며, 주제에 대해 조금이라도 알고 싶다면 확실히 읽어볼 가치가 있다.위키피디아의 마감시한은 없으며, 1회성 스텁을 넘어 발전하지 않은 기사는 12개월 안에 그것이 어디에 있을지에 대해 아무런 언급도 하지 않는다.누군가가 한번 더 쓰고 싶어하면 기사를 풀어버린다는 측면에서, 만약 스텁이 삭제되었다면 어떻게 기사를 개발할 수 있었는가(또는 개발하기 위해 영감을 받을 수 있었는가).기껏해야 처음부터 기사를 시작하고 다른 사람들의 노력을 복제한다. --Oldak Quill 02:03, 2007년 12월 23일 (UTC)[
.: 아마도 충동적인 스터브에 초점을 맞춘 그룹이 있을 수 있지 않을까?벌써 하나 있어?나는 각자가 그 기사에 대한 작은 연구를 통해 단지를 단락으로 업그레이드한다는 취지의 것을 의미한다.스텁 리스트가 있나?업그레이드된 스터브를 개선하는 그룹도 있을 수 있다.몰라.내가 미쳤나봐.하지만 합병하는 아이디어는 마음에 안 들어.물론 스텁을 삭제하지 않고도 스텁에서 따로 목록을 만들 수 있다.---Vapor One (토크) 01:20, 2007년 12월 25일 (UTC)[
위키피디아의 요점은 결국 모든 종에 대해 괜찮은 기사가 나올 것이라는 것이다.이건 어린 프로젝트야, 성장할 시간을 좀 줘.모든 종은 정의상 그 자체로 주목할 만하며, '스텁'이 '스텁'이기 때문에 삭제해야 한다는 정책은 없다.만약 당신이 그 기사들이 충분하지 않다고 걱정한다면, 다른 사람이 그것을 하기를 기다리지 말고 스스로 그것들을 개선하라.닉 말로리 (토크) 2007년 12월 29일 (UTC) 10:24 [
- 난 그걸 개선시킬거야, 닉. 하지만 사실은 내가 이 애매한 식물들에 대해 아무것도 모른다는거야. 심지어 신경도 안써.아무도 정말 신경 쓰지 않는 것 같다.결국 팽창할 수도 있지만, 얼마나 될까?누군가가 그 기사를 작업한다고 해도, 우리는 아마 그 식물에 대해 조금 더 긴 스터브 이상으로 그것을 확장시킬 만큼 충분히 알지 못할 것이다.이러한 식물 기사들 중 대다수는 반년 전에야 봇에 의해 창조된 인간에 의해 편집된 적이 없다.레이와스92Talk 17:29, 2007년 12월 29일 (UTC)[
- 그냥 Mzoli의 Meats라고 하자, 충분히 말했다.~user:orngjce223 어떻게 타이핑하지?2007년 12월 30일 19:18 (UTC)[하라
- 그래, 왜냐하면 그것은 짐보 웨일즈에 의해 만들어졌기 때문이야.그것이 많은 사용자들을 한꺼번에 끌어모으는 논란을 불러일으켰고, 실제로 그것에 대해 쓸 만한 것이 있다.레이와스92Talk 20:35, 2007년 12월 30일 (UTC)[
자동 편집 요약
요약이 공백인 상태에서 변경된 내용을 반영하는 자동 요약이 만들어지지 않는 이유는 무엇인가?링크를 위키로 만들거나 누군가의 철자나 대문자를 고칠 때마다 설명문을 쓰는데 귀찮을 수가 없고 나만 그런 것 같지는 않다.[요약]은 좋지만 P를 p로 변경하는 것은 설명 없이 드래그(편집 클릭, 로드 대기, P 찾기, 커서 배치, 삭제, p, 스크롤 페이지, 저장 클릭)만으로 충분하다.몇 달 동안 요약을 사용하기 위해 노력한 결과, 논쟁의 소지가 있는 편집에만 사용하던 이전의 형태로 되돌아갔다. --Seans Potter Business 18:32, 2007년 12월 21일 (UTC)[
- 원클릭-퀵-요약-삽입 기능을 추가하는 사용자 설명서가 귀하에게 적합한 솔루션인가?(미디어위키와 마찬가지로:에딧풀스, 그러나 요약분야의 경우) ∴ AlexSm 18:56, 2007년 12월 21일 (UTC)[
- 그러나 이것은 요약을 완료하지 않는 수천 명의 다른 사용자들에 대해서는 아무런 도움이 되지 않을 것이다. --SeansPotato Business 19:14, 2007년 12월 21일 (UTC)[
- 커뮤니티에서 가장 유용한 몇 가지 "요약 부품"(예: "위키화", "말하기", "+아이위키", "+카테고리", "+그림" 등)을 제안할 경우, 이것은 기기로 만들어지고 많은 사용자들이 선호도에서 간단히 사용할 수 있다.또한, 이런 식으로 봐줘: 너 혼자 편집을 하고, 그 다음에 보통 여러 사람이 그것을 보게 되므로, 도움이 되는 요약을 제공하고 시간을 조금 절약하는 것이 예의야 ∴ AlexSm 19:42, 2007년 12월 21일 (UTC)[
- 인용: 당신 혼자 편집을 하고, 그 다음엔 보통 여러 사람이 그것을 보게 된다. 그래서 편집 요약을 직접 지정하지 않을 때마다 모든 사람이 자동 편집 요약을 자동으로 만드는 것이 좋다.또한 편집 요약을 자동 요약(또는 좋지 않은 경우)이 없는 한 모든 사람이 편집 요약을 직접 지정해야 하는 이유도 여기에 있다.- 사실, 빈 편집 요약(또는 /* 섹션 제목 */)이 있는 "Save page"는 미리보기 및 자동 편집 요약이 있는 페이지를 주어야 변경사항을 적용하기 위해 "Save"를 한 번 더 누르도록 요청해야 한다고 생각한다.---Niels ø (noe) (talk) 21:31, 2007년 12월 21 (UTC)[
- 그 아이디어는 사람들이 편집하는 것을 단념시킬 것이기 때문에 영구적인 제안으로 거부되어 왔다.내가 요약을 입력하도록 강요되지 않는 한, 나는 하지 않을 것이다(해당되는 경우 저장을 클릭하기 전에 보통 마이너 편집 상자를 클릭한다). 그리고 만약 내가 강요당한다면, 사소한 실수들을 수정하는 것을 중지할 것이다.나는 컴퓨터 코드 조각이 왜 편집 요약을 아직 구성하지 않는지 모르겠다(각 편집에 대해 저장된 정보를 바탕으로 소급해서 할 수 있고 이런 "P > p 또는 Parsnip > parsnip" 같은 것을 원해.심지어 똑똑하고 대문자 변화라고 말할 수도 있다: Parsnip > parsnip. --Seans Potter Business 21:57, 2007년 12월 21일 (UTC)[
- 인용: 당신 혼자 편집을 하고, 그 다음엔 보통 여러 사람이 그것을 보게 된다. 그래서 편집 요약을 직접 지정하지 않을 때마다 모든 사람이 자동 편집 요약을 자동으로 만드는 것이 좋다.또한 편집 요약을 자동 요약(또는 좋지 않은 경우)이 없는 한 모든 사람이 편집 요약을 직접 지정해야 하는 이유도 여기에 있다.- 사실, 빈 편집 요약(또는 /* 섹션 제목 */)이 있는 "Save page"는 미리보기 및 자동 편집 요약이 있는 페이지를 주어야 변경사항을 적용하기 위해 "Save"를 한 번 더 누르도록 요청해야 한다고 생각한다.---Niels ø (noe) (talk) 21:31, 2007년 12월 21 (UTC)[
- 커뮤니티에서 가장 유용한 몇 가지 "요약 부품"(예: "위키화", "말하기", "+아이위키", "+카테고리", "+그림" 등)을 제안할 경우, 이것은 기기로 만들어지고 많은 사용자들이 선호도에서 간단히 사용할 수 있다.또한, 이런 식으로 봐줘: 너 혼자 편집을 하고, 그 다음에 보통 여러 사람이 그것을 보게 되므로, 도움이 되는 요약을 제공하고 시간을 조금 절약하는 것이 예의야 ∴ AlexSm 19:42, 2007년 12월 21일 (UTC)[
- 그러나 이것은 요약을 완료하지 않는 수천 명의 다른 사용자들에 대해서는 아무런 도움이 되지 않을 것이다. --SeansPotato Business 19:14, 2007년 12월 21일 (UTC)[
← 선호를 정해서 이런 일이 일어나도록 할 수 있지만, 꽤 귀찮다.나는 자동적인 무언가가 유용할 것이라는 점에서 장점이 있다고 생각하지만, 아마도 구현하기가 매우 어려울 것이다.그것은 AI의 한 종류로서 기능해야 할 필요가 있을 것이다. 그 차이를 보면서, 여러분이 한 일을 분류하는 방법을 "추적"하려고 노력한다.그것은 매우 버거울 것이다. 내 예상이다.하지만 일반적인 사소한 편집을 위한 바로 가기 버튼은 매우 좋은 해결책이라고 생각한다.Wikify, 철자법, -whitespace 등의 버튼은 엄청나게 도움이 될 것이고, 당신은 사람들이 그것을 사용할 것이라고 장담할 수 있다.
- 편집 내용을 분류하는 것이 너무 어렵다면(사례가 바뀌고 단어 주변에 []를 추가하는 것이 쉽게 인식될 수 있을 것이라고 생각했다) 2007년 12월 21일(UTC)의 역사 차이를 살펴볼 때 이전과 달라진 점을 보여주기만 하면 된다[
- 좋아, 그럼 해보자.
- 나만 그런 걸까, 아니면 뭔가를 하겠다는 공감대와 실제 이행 사이에 어떤 파탄이 있는 것 같은 걸까.내 말은, 제안이 실제로 결실을 맺게 된 게 언제가 마지막이지?모든 사람은 어느 쪽으로든 자신의 의견을 표현하기 위해 온몸에 넘어지지만, 그것이 끝나자마자 모든 것이 멈추는 것 같다.이 아이디어에는 무엇이 필요한가?개발자의 개입?이것은 단지 모노북.js 사용자 정의일까?이 일을 성사시키기 위해 누구에게 연락해야 하는가?자, 여러분.
★알려줘서 고마워.버질라에서 일이 어떻게 돌아가는지 잘 모르겠어...추가 작업에 대한 합의가 이루어지도록 하기 위해 다른 논의가 필요한가?다른 사람이 처리하게 해야 할 것 같은데...누구라도 그렇게 생각한다면 말이야
- 일단 버질라에서 요청이 접수되면, 주요 장애물은 개발자가 이를 위해 필요한 코드를 작성할 시간이 있는지 여부다.Bugzilla에서는 논의의 여지가 있지만 그것은 주로 코드 작성과 관련이 있을 것이다.지역 위키(즉, 여기서)에 대한 합의가 있는 한, 개발자들은 일단 암호화가 되면 그것을 실행해야 한다.Tra(Talk) 03:03, 2007년 12월 24일 (UTC)[
- 이번 토론에 참여한 인원수가 공감대를 추론하기에 충분하다는 것을 누군가가 확인해주면 개발자들에게 제안하겠다. --SensPotato Business 13:56, 2007년 12월 24일 (UTC)[
- 나는 적어도 다섯은 세어.나는 그것이 지역사회에서 충분히 중요한 부분이라고 생각한다.뒹굴게 하자.
- 60,000명 중 5명?Okey-dokey... --Seans Potter Business 14:14, 2007년 12월 24일 (UTC)[
- 나는 적어도 다섯은 세어.나는 그것이 지역사회에서 충분히 중요한 부분이라고 생각한다.뒹굴게 하자.
- 이번 토론에 참여한 인원수가 공감대를 추론하기에 충분하다는 것을 누군가가 확인해주면 개발자들에게 제안하겠다. --SensPotato Business 13:56, 2007년 12월 24일 (UTC)[
- 제안이 논의되었고 여기서 합의가 이루어졌다: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Automatic_edit_summary" --Seans Potter Business 15:29, 2007년 12월 24일 (UTC)[
- 내 말은 우리가 100만 명 이상의 등록된 사용자들을 가지고 있다는 거야.어쨌든 그래, 네 제안이 내게는 잘 어울리고 네가 기꺼이 주도권을 쥐는 것에 감사해.제안서가 마련되면 링크를 게시하여 I/W가 이를 준수하고 지원을 제공할 수 있도록 하십시오.다시 한번 고마워!
- 단지 회계 담당자일 뿐 - 등록된 사용자 수가 6백만 명 이상: 통계.
- 으으으악!내 6만 달러가 어디서 왔는지...어쨌든, 여기 "bug"/향상 항목이 있다.등록이 되어 있으면, 그 버그로 가서, 아래쪽으로 스크롤하여 투표할 수 있다. --Seans Potter Business 09:21, 2007년 12월 25일 (UTC)[
너는 좋은 생각을 가지고 있지만, 나는 네가 발전했다고 생각해!나는 봇이 "이전"에서 그리고 "이후"에서, 그리고 "이후"에서, 변경되는 부분을 잠깐 복사하는 것을 훨씬 더 선호한다.아니면 뭔가.기사를 위해 편집된 요약을 스캔할 때 훨씬 더 유용할 것 같은데, "위키파이"는 사실 많은 것을 말해주지는 않지만, 실제로 변화를 설명하는 무언가가 있을 수도 있다.마찬가지로, 이것은 RCP에 큰 도움이 될 것이며, 당신에게 변화가 무엇인지 볼 필요 없이 말해줄 것이다.그레스윅 (토크) 2007년 12월 28일 (UTC 16:41,
- 나는 개인적으로 위키, 수정 타이포, 카피편집, 사진 추가, 사물 이동 등과 같은 여러 개의 확인란으로 나누기를 원한다.그런 다음, 사용자 편집 요약에 요약의 종류를 추가하는 "최소 편집"으로 확장될 수 있다.~user:orngjce223 어떻게 타이핑하지?2007년 12월 30일 19:35 (UTC)[하라
<노트>라는 새 참조 태그 생성
때때로 참조 대신 노트(즉, 조금 더 많은 정보)에 <ref> 태그를 사용하기도 하는데, 나는 참조뿐만 아니라 메모의 별도 목록을 만들기 위해 이전 {{note} 템플릿을 사용하는 기사를 본 적이 있다.mw: 매우 쉬울 것이다.확장:<참고>와 <참고>와 <참고/>와 정확히 같은 방식으로 작용하는 두 개의 새로운 후크로서 <주>와 <주 />를 추가하기 위해 인용/Cite.php 확장을 들 수 있다.
이렇게 하면 기사가 하나의 목록으로 함께 묶이거나 오래된 템플리트 시스템을 사용해야 할 때 두 개의 목록(노트 중 하나와 참고문헌 중 하나)을 유지할 수 있을 것이다.예를 들면 다음과 같다.국제포경위원회는 참고 태그만 사용하지만 일부 태그는 노트용(예: 숫자 6)이므로 대신 두 개의 목록이 있을 수 있다.
또한, 각각의 리스트를 여러 개 가질 수 있는 것은 (아마도 조금 더 많은 작업으로) 불가능할까?예를 당신 < 수 있었다;ref1>,<>ref2>,<>ref3>. <에 해당합니다;references1 />,<>references2 />,<>references3>는 목록 거버너즈 섬:미국 앨라배마 주의 탁자 아래의 리스트를 가지고 다음 중 하나를 기사의 마지막 부분에 같은 기사들을 편리할 것, 또는 영국( 같은 국가 기사) 그렇게 가지고 있다.그 infobox에 나는 음표뿐 아니라.기사 끝의 참고문헌 섹션
(기술마을 펌프에서도 이 문제를 제기했다.)Chris_huhtalk 15:01, 2007년 12월 28일 (UTC)[
- 이는 WT:FOOT에서 자주 논의된다. 우연히 이 기능에 대한 Bugzilla 요청이 있을 경우 WP:FOOT의 관련 섹션에 나열되어야 한다. -- SEILCO (대화) 15:25, 2007년 12월 28일 (UTC)[
- 나는 그것들 모두 훌륭한 아이디어, 노트와 분리된 참조 목록(그리고 어쩌면 노트1과 같은 노트 목록도 분리되어 있을 수 있다.)이라고 생각한다.나는 그것이 시행되기를 바란다.Equazcion •properties/C • 2007년 12월 28일(UTC) 23:58[
섹션 속성을 갖는 것이 이것을 구현하는 좋은 방법이 될 것이다.사용 예:
<ref 섹션="notes" hello i는 노트(/ref)이고, <ref>는 그냥 정기(기본) ref(ref)일 뿐이다.
힌디어 편집기 문제
안녕, 나는 힌디 페이지의 철자가 대부분의 경우 꽤 형편없다는 것을 알아챘다.힌디어에 기반을 둔 편집자가 본질적인 실수를 가지고 있다는 것을 깨달았을 때 나는 실수를 바로잡기 위해 페이지 중 하나를 편집하려고 했다.
더 자세히 설명하기 힌디 편집기에서 "위키피디아"를 타이핑할 때 편집자는 "W" 소리 등의 뒤에 "e" 소리를 넣기로 결정하는데, 그것이 영어로 어떻게 될 것인가 하는 것이지만 힌디에서는 이것이 "위키피데이아"라는 단어로 귀결된다.
페이지에서 힌디 언어 링크를 클릭하면 힌디어로 된 위키백과 로고(올바르게 읽음)를 보고 페이지의 제목 표시줄을 보면 이 오류가 나타난다.
나는 이 문제가 대부분의 다른 인도어로 자동 확장된다는 것을 깨달았다. 왜냐하면 인도 언어들은 비슷한 방식을 따르고 있기 때문이다.
주구르 빈 (대화) 08:23, 2007년 12월 29일 (UTC)[
- 복잡한 스크립트 지원 기능을 설치하셨습니까?—2007년 12월 30일(UTC) 05:25 점 기억[
파이트송
위키백과를 참조하십시오.중앙집중식 토론/대학 기사에 수록된 노래, 특히 싸움 노래, 특히 전체 가사의 포함에 대한 토론을 위한 싸움 노래.바이올렛/리거 (t) 2007년 12월 30일 (UTC) 10:56[
- 이런 공지를 붙일 곳은 아닌 것 같다.대신 그 페이지에 RfC를 게시해야 한다.Equazcion •1987/C • 2007년 12월 30일(UTC)
대통령 선거에 출마한 위키백과 사람들
나는 이런 리스트를 꼭 보고 싶다.나를 포함해서, 조나톤 샤키 (그리고 그의 모든 양말), 레이 맥키니, 그리고 수많은 다른 사람들.얼마나 많은 사람들이 위키피디아를 편집하고 다른 나라에서 가장 높은 자리에 출마했는지도 모르지만, 분명 흥미로울 것이다.우리가 이렇게 해야 한다고 생각하는 사람 또 있어?--우가맨 (토크)UGA MAN FOR PRESS 2008 22:53, 2007년 12월 30일 (UTC)[하라
- 나는 그것을 여기에 가져와서 WP와 국경을 접하는 것은 좋지 않은 생각이라고 생각한다.SOAPBOX...물론 사용자 범주를 만들 수도 있겠지만, 나는 요점을 잘 모르겠다. --DJ (대화 • 기여) 23:53, 2007년 12월 30일 (UTC)[
위키백과:비관리자 롤백
우리는 이제 개발자들이 관리자가 비관리자에 대한 롤백 권한을 부여하고 제거할 수 있도록 만든 위치에 있다.지난 한 달 동안, 우리는 그것이 주어질 수 있는 방법에 대해 논의해왔고, 우리는 이제 그것의 실행에 대한 합의를 얻기 위해 노력해야 할 시점에 와 있다.최대한 많은 분들에게 제안서를 검토해보고 그 제안을 지지하거나 반대하는 결론을 내릴 수 있도록 부탁할 수 있다.Ryan Postlethwaite 23:06, 2007년 12월 30일 (UTC)[하라
진심이었어?
나는 위키피디아가 모든 결과와 함께 "그랬니?"라는 팁을 포함시킨다면 괜찮다고 생각한다.구글은 우리가 검색 상자에 잘못 입력했을 때 이미 그것을 가지고 있었다.내가 이것을 제안하는 이유는 Charles_Shobraj(역사를 보라)를 위해 기사를 시작했고 계속 열심히 일하고 있었다.기사를 작성하기 전에, 나는 그것에 대해 검색했고 그 기사가 존재하지 않는지 확실히 했다.모든 일이 끝난 후, 나는 구글에서 추가 자료를 얻으려고 애쓰고 있었다.이번에는 그 기사가 이미 찰스 소브라즈(쇼브라즈 & 소브라즈 참조)라는 제목으로 존재한다는 것을 이해했다.만약 WP가 "말씀하셨나요?"라는 옵션을 가지고 있다면.시간을 낭비하지 말았어야 했다. --Avinesh Jose (토크) 06:43, 2007년 12월 24일 (UTC)[
- 나는 위키피디아의 검색 알고리즘이 어떤 큰 개선을 사용할 수 있다는 것에 동의한다.이렇게 널리 사용되는 매체는 우리가 시대에 크게 뒤처져 있는 것 같다.IMDb에서 나는 영화 제목이나 배우 이름을 완전히 잘못 쓸 수 있고 그 사이트는 내가 정확히 무슨 뜻인지 알지 못하는 경우가 더 많다.위키피디아에서는 당신이 정확히 어떤 철자를 쓰지 않는 경우가 약 70%에 달하며, 당신은 완전히 잘못된 결과를 얻는 것 같다.
- 위키백과 참조:지속적인 제안#검색에서 철자 오류를 탐지해야 한다.향상된 검색을 위해 Google의 사이트:en.wikipedia.org을 사용하십시오.–Pomte 07:46, 2007년 12월 24일 (UTC)[
- "IMDb가 할 수 있다면 우리도 할 수 있어야 한다"고 말한 것을 용서하십시오.나는 그들이 우리보다 훨씬 더 많은 서버 자원을 가지고 있다고 상상할 수 없다.나는 그들이 직장에서 표준 미디어위키와 PHP 철자 수정 스크립트보다 더 효율적인 대본을 얻었다는 느낌이 든다. 왜냐하면 그들의 소프트웨어는 처음부터 쓰여졌기 때문이다.이것은 나의 보잘것없는 생각에서 우선시되는 것으로서 다시 한번, 우선시 되어야 한다.여기서 검색 기능은 매우 중요하다.
- IMDB는 우리 기사에 따르면 1998년부터 아마존닷컴이 소유하고 있기 때문에 나는 그들이 더 많은 자원을 가지고 있다고 추측한다.미스터 지맨 08:20, 2007년 12월 24일 (UTC)[하라
- "IMDb가 할 수 있다면 우리도 할 수 있어야 한다"고 말한 것을 용서하십시오.나는 그들이 우리보다 훨씬 더 많은 서버 자원을 가지고 있다고 상상할 수 없다.나는 그들이 직장에서 표준 미디어위키와 PHP 철자 수정 스크립트보다 더 효율적인 대본을 얻었다는 느낌이 든다. 왜냐하면 그들의 소프트웨어는 처음부터 쓰여졌기 때문이다.이것은 나의 보잘것없는 생각에서 우선시되는 것으로서 다시 한번, 우선시 되어야 한다.여기서 검색 기능은 매우 중요하다.
- 일부 관심사는 mw일 수 있다.확장:디드유미언.이것은 영어 위키트리거에 사용하기 위해 커뮤니티에 의해 승인되었지만 아직 개발자들의 승인을 받지 못했다. -- Visviva (토크) 17:03, 2007년 12월 31일 (UTC)[
'빨간색 링크' 통계 또는 카운터 만들기
동일한 빨간색 링크를 가진 페이지 수를 알려주는 '빨간색 링크' 카운터를 만든 다음 더 많은 페이지에 나타나는 '가장 빨간색' 링크를 순위 페이지에 나열해 보십시오.그러므로 기고자들은 가장 필요한 기사가 무엇인지 바로 찾을 수 있었다.'요청서' 페이지보다 낫다(또는 더 민주적이다).
메리 크리스마스!
LG트라프 (대화) 2007년 12월 25일 (UTC) 22:54 [
- 이것은 위키피디아에서 볼 수 있다.대부분 수배된 물건들.그러나 이러한 종류의 순위의 문제 중 하나는 빨간 링크를 포함하는 탐색 상자(여러 페이지에 표시)가 있다면, 빨간 링크들은 즉시 많은 백링크를 가지고 있고 그 페이지를 어지럽힐 것이다.Tra(Talk) 23:06, 2007년 12월 25일 (UTC)[
- 포르투갈어로 비슷한 리스트가 있는지 모르겠지만 그럴 것 같지는 않다.이 목록은 가장 최근에 Sapphic에 의해 만들어졌기 때문에 당신은 아마도 그녀에게 포르투갈어 위키백과에 대해서도 똑같이 할 수 있는지 물어 볼 수 있을 것이다.Wikimedia Wiki가 데이터베이스 덤프 등에 동일한 형식을 사용하기 때문에 이 목록을 생성하는 것은 매우 간단해야 한다.포르투갈어를 사용하는 한, 아마도 다룰 기사가 적을 것이기 때문에 프로세스의 수동 부분(주제로 정리하거나 탐색 상자 등의 원인을 찾는 것 등)을 수행하는 것이 더 쉬워야 한다.트라 (토크) 01:45, 2007년 12월 27일 (UTC)[
위키백과 인도판 지원
이것은 인도판 위키백과를 돕기 위해 개발된 프로젝트에 대해 알려주기 위함이다.프로젝트 시작 전부터 동일한 DD NEWS(인도 정부의 공식 뉴스 채널)가 프로젝트에 대한 이야기를 했고, 녹음된 버전은 다음 사이트에서 확인할 수 있다.
다음에서 몇 가지 도구를 사용해 보십시오.
http://mozhi.org/hindi http://mozhi.org/punjabi http://mozhi.org/tamil
우리는 인도 독자들이 각각의 언어로 검색할 수 있도록 위키백과 페이지에 대한 맞춤형 검색 상자를 제공할 수 있고, 그들은 각각의 인도어로 단어를 입력한다.사용자는 해당 언어로 직접 단어를 입력하여 검색할 수 있다.
구현에 필요한 설명이나 도움이 필요하면 알려주십시오.우리 사이트에서도 동일한 연락처 페이지를 찾을 수 있다.만약 관심이 있다면 우리는 그것을 광범위하게 시작하고 모든 페이지를 포함할 수 있다.
그린 버터플라이 : 생태학, 공정무역, 인권에 관한 상품과 기업의 등급을 매긴다.
안녕하십니까, 위키피디아인 여러분.
내 프로젝트를 간략하게 발표하게 하고, 당신의 제안을 자유롭게 게시할 수긍정적으로.나는 한 친구와 생태학에 대해 토론하고 있었고 그 주장을 지지했다: 소비자는 힘을 가지고 있다.그의 매일의 선택은 생태계를 향하든 아니든 산업을 지향한다.질적으로.공정무역을 지향한다.
나는 웹사이트가 각 사용자들이 회사와 제품을 평가할 수 있게 해준다면 좋지 않을까 생각했다.생태율, 공정무역률, 품질률, '근로자의 권리' 또는 인권률을 상상했다.각각의 인터넷 사용자 소비자들은 자신의 지식을 공유할 수 있고 어떻게 보면 세상을 변화시키는 나비가 될 수 있다. (희망스럽게도 허리케인보다 덜 폭력적인 수단을 부추긴다.)
나는 PHP, ASP에서 프로그래밍 기술을 가지고 있다.Net 및 현재 이 아이디어에 대한 조언(기술, GUI, ...)과 제안사항을 찾고 있다.어떤 콜라보레이션도 물론 환영할 것이다.왜 새로운 위키백과 지부가 아닌가?
또한, 이 프로젝트에 관심이 있는 사람을 알고 있다면, 이 메시지를 자유롭게 전달하십시오.
미리 고맙다
평화 ,
마이클.
(wikimedia Foundation 메일링 리스트 'http-l@lists'로 연락하면 된다.wikimedia.org)')
봇 파괴 - 적어도 저작권 문제를 다루는 봇 파괴
'공정한 사용 근거, 래킹 소스' 등을 이유로 '속한 삭제'를 위한 태그 지정에 전념하는 봇에 문제가 늘고 있다.
모든 경우에 그들은 틀렸다.
여러분은 분명히 봇과 토론할 수 없으며, 그들은 "기계"가 되어 지속적으로 활동한다는 불공평한 이점을 가지고 있다.
사례 1: 이미지:에우스카디 에스쿠도.png.베타카ommandBot은 분명히 바스크 자치체의 공식 슈테온을 자신의 기사에서 사용하는 자명한 공정 사용 근거를 볼 수 없었다.인간은 결코 이런 오류를 범하지 않았을 것이다(그렇지만 행정가는 다시 생각하지 않고 삭제했다).
사례 2: 이미지:바타수나 로고.jpg.오사마KBOT(이름이야!)는 "출처"가 부족해서 빨리 삭제해야 한다고 주장했다.수백만 번 재현한 흔한 로고인데 출처가 뭔지 전혀 모르겠어.다행히도 이 사건에서 나의 항의는 주의를 끌었고 이미지는 그대로 남아있다.
인간다운 분별력이 필요한 이런 문제들을 인간들이 잘 처리해 주길 바란다.그렇지 않으면 우리는 미쳐버릴 것이다.
봇은 다른 위키나 그와 같은 것에 링크를 추가해도 괜찮지만, 그렇지 않다면, 특히 그들이 그 근거를 식별하기 어려운 SD에 대한 지명을 담당할 때, 그들은 매우 파괴적이다.인간 위키백과를 위해 죽여버리자! --Sugaar (대화) 07:36, 2007년 12월 26일 (UTC)[하라
- 맞아, 나도 이 봇들과 부딪혔어. 그리고 그 때 우연히 그들의 실수를 발견했어.단지 공정한 사용 템플릿이 채택되지 않았다고 해서 근거가 없다는 것은 아니며, 템플릿이 이러한 봇들이 무엇을 볼 수 있는 유일한 방법인 것 같다.내가 보지 않을 때 그들의 오류로 인해 얼마나 많이 삭제되었는지 생각하면 소름이 끼친다.2007년 10시 15분, 12시 26분
- 봇은 템플리트를 "그냥" 찾으면 안 된다.적어도 BcB의 주요 초점은 에 사용된 기사가 이미지 요약에 정의되어 있는지 여부라는 것을 알고 있다.이제 그것의 폐쇄된 코드지만, 나는 BC가 단지 템플릿에서 조항=x 변수를 찾는 것이 아니라 어떤 방법을 택했다고 생각한다.
- 날 믿어, 난 좌절감을 이해해 그리고 그건 변명의 여지가 없어다만 삭제하기 전에 확인하는 것이 관리자의 '직무'이다.내가 관리자라면 확인해 볼 것이다.BCB는 삭제되어서는 안 되는 일부 이미지에 태그를 지정할 수 있으며(공정한 사용 근거를 누락한 경우), 나는 심지어 사용자 페이지에 BCB의 기여에 대한 링크까지 가지고 있으며, 나는 자주 검색하여 태그 지정되는 일부 이미지에 근거 자료를 추가한다.그러나 우리의 이미지 정책은 매우 분명하고 근거는 반드시 제공되어야 한다고 되어 있고, 어떤 사람들은 그것을 이해하지 못하는 것 같다.핵심 단어는 "꼭" - Rjd0060 (대화) 00:05, 2007년 12월 27일 (UTC)[하라
저작권 위반은 위키피디아의 근본적인 위협이다.저작권 소유자들은 위반에 대해 소송을 제기할 수 있다.이미지 저작권 위반은 대부분의 텍스트 위반과는 달리 개방적이고 폐쇄적인 상황이다. 또한 텍스트 위반이 있을 경우 일반적으로 저작권 소유자에게 유리한 사항이다(예: 웹사이트의 PRish 텍스트). 이미지 소유자는 이미지 판매로 돈을 버는 제3자일 경우가 많다.위키피디아 콘텐츠는 단지 온라인에 있는 것만이 아니다. 이 프로젝트의 목적은 정보를 종이, DVD, 거울 등으로 배포하는 것이다.이미지는 ⑴ 주제를 이해하는 데 특별히 중요하지 않은 경우가 많고 ⑵ 저작권 위반이 만연할 경우 소송이 발생할 가능성이 훨씬 높기 때문에 재단은 소싱과 면허가 불완전할 때 무엇을 허용하는지 상당히 제한적인 태도를 취하는 것이 타당하다.그리고 그렇다, 봇은 100% 정확하지는 않지만, 실수를 저지르고, 관리자가 이를 잡지 않는 곳에서는 여전히 문제를 해결할 수 있다. -- 존 브레본 (리바운딩) 02:55, 2007년 12월 27일 (UTC)[
- 나는 심각한 저작권 문제를 발견하는 봇을 문제 삼지 않는다.문제는 베타코만드봇이 저작권 침해 여부와는 무관한 명시적 사용 근거의 결여에 불과할 때에도 곳곳에서 저작권 위반을 보고 있다는 점이다.—2007년 12월 27일(UTC) 20:41, 점 기억[
- Rjd, 도트는 이미 이 답장을 쓴 것 같아.위키피디아에 대한 정책은 전반적인 확고한 규칙으로 시행되어서는 안 된다.WP의 포인트:IAR은 정책이 일반적으로 나아갈 길이지만 각각의 경우를 고유하게 고려해야 한다는 것이다.봇은 이것을 할 수 있는 능력이 없다. 그저 바보같이 특정한 패턴을 확인하고 어떤 식으로든 규칙을 세운다.정책 문제도 있을 수 있지만, 정책이 있는 그대로 견뎌야 한다고 해도, 로봇이 로봇을 시행하도록 하는 것은 위키피디아의 정책 정의에 부합하지 않는다.Equazcion •properties/C • 2007년 12월 28일 01:05, (UTC)[
- WP의 포인트:IAR은 특이/유일한 사례에 대해 탈출 해치를 제공하는 것이 아니라, 각 사례에 대해 편집자가 정책을 따를지 여부를 "특이하게 고려"하도록 강요하는 것이 아니다.정책을 따르는 것이 말이 되지 않는 한 정책을 따라야 한다.만약 당신이 이 봇의 편집 중 많은 부분이 잘못되었다거나(기존의 가이드라인이나 정책을 위반한다), 혹은 다른 규칙을 따라야 한다고 주장하기를 원한다면(아마 가이드라인에 포함되어야 할 것이다), 그것도 괜찮다.하지만 "봇은 어리석기 때문에, 봇은 사용되어서는 안 된다"고 주장하지 맙시다.그것은 비스타터(non-starter)이다. 봇은 (봇 승인 그룹의 관점에서) 재량권이 필요 없는 기능이 좁게 정의된 경우에만 승인된다.때때로 그들은 수정이 필요하다. 만약 그렇다면, 당신은 정말로 그것을 연구해야 한다. -- John Brown은 14:03, 2007년 12월 28일 (UTC)[
- 봇은 출처나 저작권 같은 사소한 문제들에 대한 치안 유지 업무를 담당해서는 안 된다.이미지가 저작권으로 보호되고 누군가 그것에 문제가 있다면, 그것은 결국 인간의 주도하에 의해 발생할 것이고 그 때 이미지가 삭제될 것이다.우리는 그것을 위해 봇이 필요하지 않다.
- 우리는 인터위키 링크와 같은 일상적 개선을 위해 봇이 필요할지도 모른다. 그러나 저작권 정책이나 다른 삭제에는?말도 안돼봇은 그러한 인간의 미묘함을 이해할 수 없고 업로드용 템플릿은 틀림없이 유용하지만, 그렇다고 해서 모든 오래된 이미지들이 그것의 요구 사항을 따라야 한다는 것은 아니다, 그렇지 않은가?이러한 사소한 불편에 대해 신속한 삭제 절차를 밟는 것은 훨씬 더 어렵다.
- Btw, 상대적으로 불평이 부족한 것은 봇들이 오류와 학대를 하는 것이 아니라 사람들이 그것에 대해 무력감을 느낀다는 것을 의미한다.로봇 페이지에서 불평만 하면 해결되고, 봇 소유주에게 불평만 하면 반드시 답장을 안 할 텐데...위키피디아의 편집자들은 이에 속수무책으로 당하며 문제를 제기한다:우리는 정말로 저작권 보호를 위해 봇이 필요한가? 아니면 이것이 급여에 대한 미친 저작권 이익의 발명인가?
- 인간에게 인간 문제를 다루게 하고, SD처럼 인간의 개입이 거의 필요 없는 삭제는 훨씬 덜하고, 삭제는 아닌 일상적 개선에만 봇을 사용하도록 하자 ---Sugaar (대화) 13:15, 2008년 1월 1일 (UTC)[
요약 자동 편집
편집 요약 없이 편집을 할 때 자동 편집 요약(AES라고 함)이 만들어지는 경우가 많다.새로운 기사의 경우 AES는 "ABC..."로 작성됨. 페이지를 리디렉션하고 요약으로 공명하지 않을 때 AES는 XYZ로 리디렉션됨.그러나 다른 두 가지 일반적인 AES도 있다: 페이지를 비워라.페이지를 "Abc def"로 바꾸었다.이 두 사람은 경험이 많은 편집자들이 매우, 매우 드물게 사용하지만, 감시 목록 등에 공공 기물 파손으로 나타난다.이 페이지를 사용할 때의 98%는 IP 또는 새로운 사용자가 페이지를 블랭킹하거나 내용을 반말로 대체하여 편집하는 것이다.나는 이러한 AES를 편집하는 것이 불가능해야 한다고 제안한다.소프트웨어는 이러한 유형의 파괴행위 편집이 언제 발생하는지 알고 있다.나는 그것을 반달들이 이런 식으로 파괴하는 것을 금지하고 그들을 되돌리는 시간을 절약하는 단순한 변화로 본다.나는 다소 말이 많았지만, 비반달은 거의 빈 페이지가 없기 때문에 이것이 실행되어서는 안 될 이유가 없다고 본다.레이와스92Talk 20:49, 2007년 12월 30일 (UTC)[
- 아마도 아직 자동확증되지 않은 익명의 편집자와 사용자로 제한되어야 할 것이다(계정연령 <4일>).그래야 합법적으로 페이지를 비우는 사용자와 관리자(개인 정보, 사용자 페이지 비우기 등)가 갑자기 그러한 편집을 금지하지 않을 수 있다.Tuvok[/]T@lkImprove 21:33, 2007년 12월 30일 (UTC)[
