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

핫링크 사용 안 함 제안

관심 있는 모든 사람들을 위해, 나는 모든 위키미디어 프로젝트에서 핫링크를 사용하지 않도록 하는 제안을 했다.메타에서 토론에 참여하십시오.~ JonnyMrNinja 20:46, 2008년 7월 27일 (UTC)[응답]

"핫링크링"이란 용어에 익숙하지 않은 사람들에게 Wikimedia 사이트를 이미지 저장 및 이미지 서버 사이트로 사용하여 일반 시청자가 할 수 있는 일(예: 위키백과 기사를 보는 일) 없이 (다른 곳에 전시하기 위해) 이미지를 끌어내는 것을 말한다.-- 존 브로턴 (리틀링) 2008년 7월 28일 (UTC) 12:36 [응답]

이 제안은 매우 잘 받아들여졌고, 잘게 찢겨져 시궁창에 피를 흘리고 울게 하기 전에 힘을 얻었다.내 요약을 인용하자면 - "대역폭과 관계없이, 특히 커먼즈에게는 현재 상태대로 프로젝트 핫링크를 비활성화하는 것은 좋지 않은 생각이다.나의 제안은 EN의 PD 범주에서 발견된 사진들을 토대로 하여 프로젝트 전체를 반영한다고 가정하였다.몇몇 아이들이 마이스페이스 페이지를 위해 여자친구에게 키스하는 사진을 올리는 것은 특별히 접근하기 위해 프로젝트에 있는 많은 이미지들에 접근하는 것을 허락하지 않을 이유가 없다.서버에서 사용하기 위해 이미지를 보관하면 다운로드 및 복사할 필요가 없어져 기록과 사용권이 깨진다.다른 사이트에서 우리의 이미지를 사용할 수 있도록 허용하면(우리가 인증되지 않은 경우에도) URL이 여기에 있는 것을 보는 사람일지라도 우리의 프로젝트에 대한 관심을 높일 수 있다.핫링크는 연간 최대 10k의 비용이 든다. 이는 다른 많은 형태의 글로벌 광고보다 저렴하다(그리고 더 유용하다.관련된 기술적 문제와 이미지 검색에서 독자를 잃을 가능성은 말할 것도 없다."내 제안은 철회되었고, 나는 관심 있는 사람들을 위해 그리고 언젠가 "핫링크"를 찾기 위해 기록보관소를 검색할 사람들을 위해 이 글을 올린다.~ 2008년 7월 29일 (UTC) 08:25 (JohnnyMr Ninja 08:25)[응답]

좋아, 다른 많은 사이트들이 하는 것처럼 다른 방법으로 가서 사진을 삽입하기 위한 HTML 조각과 증명서/라이센스를 지정하는 제목 텍스트, 그리고 관련 위키미디어 페이지로 바로 돌아가는 하이퍼링크를 제공하는 것은 어떨까?녹농균_(talk) 13:47, 2008년 7월 30일 (UTC)[응답]

삭제 대상 후보 지명에 대한 의견, 입장 및 응답

삭제 지정 페이지에 대한 의견과 입장에 응답하는 동안, 해당 문제에 대한 의견이나 입장 표명이 각 측면에 3중등 기호로 둘러싸인 하위섹션을 만들어 이를 하위섹션으로 만들고, 이후 콜론과 하위섹션을 사용하여 하위섹션을 만드는 대신 별표로 진행되어 과감하게 만드는 것이 생각난다.모든 토론 페이지에서와 같이 하위섹션에 포함.이렇게 하면 다시 돌아가서 닫힌 관리자가 읽을 수 있는 문구 등을 명확히 하는 것이 훨씬 쉬워질 것이다.현재 단일 편집 섹션으로 편집을 한다는 것은 몇 개의 세부적인 설명이나 응답만 있으면 아주 쉽게 분실될 수 있다는 것을 의미한다.줄리 댄서 (토크) 2008년 7월 28일 (UTC) 12:27[응답]

거의 모든 토론에서 나는 현재의 방식이 훨씬 더 명확하다는 것을 알게 될 것이다.그 어려움은 사람들이 서로에 대한 정교한 회답을 시작하고 주제에서 너무 많은 부분을 들여놓기 시작할 때에만 온다.DGG (대화) 08:26, 2008년 7월 29일 (UTC)[응답]

그게 바로 이 제안에 대한 내 요점이야...만약 그리고 초기 논평이나 입장이 만들어지고 그것이 모든 요점의 하위섹션으로 설정된다면, 역점 논의는 최소한 모든 들여쓰기이다. 그것들이 매우 정교하더라도, 다시 시작해야 할 필요가 적어도 같은 편집 블록 안에 포함된다.하위 섹션이 초기 불만 사항과 코멘트로 제한되어 있어, 포인트 대위점이 장황하고 정교해졌을 때 정리를 유지할 방법이 없다.줄리 댄서 (토크) 13:39, 2008년 7월 30일 (UTC)[응답]

"최근"(ly)와 같은 블랙리스트 단어(또는 경고 대화상자 팝업)

나는 작년에 이것에 대해 언제 한번 언급했었다.사람들이 사건들을 ...err...rer...recent적으로 묘사할 때 의도치 않게 "recent(recent)"라는 단어를 사용하는 많은 기사들이 있다.문제는 독자가 언제 "최근"을 언급해야 하는지 전혀 모른다는 것이다.이 단어가 백과사전에서 사용되어야 하는 상황(직접 인용문 제외)은 없다.우리는 항상 문장이 날짜에 따라 달라지도록 구해야 한다.

상기 용어에 대한 몇 가지 제안:

1. 스팸 블랙리스트에 "최근"을 추가하십시오(그리고 그것이 얼마나 많은 문제를 발생시키는지 직접 인용문을 재생산할 수 없는지 모니터링).어떤 소프트웨어도 변경할 필요가 없다.
2. "최근" 단어가 검색되면 "미리보기 표시" 및/또는 "페이지 저장"을 클릭할 때 경고 또는 대화상자를 표시하십시오.
3. 봇(어느 것?)의 감시 목록에 "최근"(ly) 및 기타 그러한 용어를 추가하고 편집자/기사 토크 페이지/특수 봇의 감시 목록 또는 그 중 일부에 통보한다.
4. 스팸 블랙리스트에 "최근"를 추가하고(또는 "단어 블랙리스트"를 새로 작성) 개별적으로 해당 단어를 사용할 수 있는 "기사별" 화이트리스트를 만드십시오.블랙리스트-화이트리스트 접근법은 연장될 수 있다는 장점이 있다.예를 들어, 필요한 기사를 제외하고 '젠장'과 같은 외설이나 '게이(게이) 게이(일반적으로 반달리즘으로 의도하는 것)'와 같은 구절을 차단할 수 있다.이미 봇들이 이런 것들을 찾아다니고 있으니 얼마나 유용할지 모르겠다.

봇 옵션을 3번으로 추가해 블랙리스트-화이트리스트 옵션을 4번으로 맞췄다. Zunaid©® "최근" 문제에 대한 지원을 좀 더 구체적으로 측정하고 싶다.옵션 4가 우리에게 제공하는 다른 용도는 만약 누군가가 그것을 더 가져가고 싶다면 별개의 제안으로 간주될 수도 있다.Zunaid©® 20:21, 2008년 7월 29일 (UTC)[응답]

내가 보기엔 소름끼치는군"최근"이라는 단어의 사용은 글로벌 접근방식이 그것을 공격하기 위해 실행되어야 하는 이슈를 터무니없이 사용하는가?나는 백과사전의 맥락에서 "최근"이라는 단어를 합법적으로 사용하는 것이 거의 없다는 것에 동의하지만, 나는 그것을 그렇게 큰 거래로 보지 않는다.나는 우리 봇들 중 몇몇의 블랙리스트에 그것을 추가하는 것은 해가 되지 않을 것이라고 생각한다. 왜냐하면 잘못된 긍정의 수는 낮을 가능성이 높기 때문이다. 하지만 나는 다시 한 번, "최근" 문제가 얼마나 나쁜지, 그리고 그것이 이 정도의 주의를 요하는지에 대해 의문을 제기한다.2008년 7월 29일 세레 21:10 (UTC)[응답]

미안하지만, 당신을 겁주려고 한 것은 아니다;) 이것은 단지 나의 일화적인 경험일 뿐이지만, 그것은 극도로 널리 퍼져있는 것처럼 보인다. 사람들은 항상 뉴스거리가 될 만한 일이 발생할 때마다 최신 뉴스를 기사에 싣기를 원한다.현재 어떤 주제적인 기사라도 훑어보면 당신은 필연적으로 "최근"이 잘려나가는 것을 발견할 것이다.)그 자체로 새로운 사건들이 항상 문제가 되는 것은 아니지만, 그러한 추가의 표현은 필연적으로 문제가 될 수밖에 없고, 많은 것들이 있다.필연적으로 이 사건들은 일단 "최근" 상태가 지나면 정리되지 않는다.만약 누군가가 도움이 될 "최근"을 위해 비기사 공간 결과를 걸러내는 구글 검색(I couldn't)을 할 수 있다면.나는 WP, Talk, Template 공간을 포함한 en.wikipedia.org/wiki,에서 190만개의 결과를 얻는다. 따라서 실제 기사 수는 훨씬 적을 것이다.하지만 나는 거짓 양성 비율이 매우 낮을 것이라고 생각한다.실제 제목에 최근 몇 개의 기사가 수록되어 있어 제외할 필요가 있지만, 이와 별도로 우리가 사용할 수 있는 도구의 성공률은 95%를 훨씬 초과해야 한다.Zunaid©® 22:45, 2008년 7월 29일 (UTC)[응답]

그렇다면 이 문제는 어떻게 다뤄질 것인가?우리의 스팸봇 등은 블랙리스트가 있는 단어로 편집만 취소하도록 프로그램되어 있는데, 전체 편집은 스팸일 가능성이 높기 때문이다.단순한 문법/문법적 변화도 쉽다.문제는 사용자가 정보를 가지고 기사를 업데이트하고 "최근"이라는 단어를 사용할 때 봇픽스를 갖는 것이 그렇게 간단하지 않다는 것이다.편집을 되돌리면 "최근"이라는 단어의 불운한 사용에 대해서만 유용한 정보가 수정될 가능성이 있다.또한 쉽게 대체할 수 있는 것도 없다 - 적절한 해결책은 문맥상이며 단어에 따라 달라질 수 있다.유일한 해결책은 어떤 식으로든 봇이 기사에 플래그를 다는 것이다.그렇다면 편집자 개선을 위해 "최근"이 포함된 기사를 게재하는 봇을 제안할 것인가?2008년 7월 29일 세레 22:50 (UTC)[응답]

"최근"이라는 용어는 분명히 문맥에 따라 다르지만, 그 용어의 사용은 날짜에 맞지 않는 사용(즉, 기준 시간이 현재가 아닌 장소)에서 완벽하게 허용된다.크리스토퍼 파럼(토크) 2008년 7월 29일 23시 50분 (UTC)[응답하라]

나는 우리가 동의한다고 생각한다.그러나 나는 예를 사용하는 것을 좋아한다.그래서 여기 있다: 예를 들어, 내가 누군가를 인용하는 동안, 나는 그 용어를 사용하는 것이 완벽하게 합법적이라고 생각한다.그러나, 내가 "새로운" 법이나 "최근 법률"을 언급하고 있고 그것을 묘사하는 데 실제로 최근의 용어가 이용된다면 그것은 POV이다. --CyclePat (대화) 23:56, 2008년 7월 29일 (UTC)[응답]

수천 개의 기사가 한 가지를 다른 것과 비교할 때 "더 최근에"라고 말한다.그리고 어떤 상황에서는, 예를 들어 지질학, 진화론, 우주론에서, "최근"은 아주 오랜 기간 동안 "최근"으로 남아있을 수 있다는 것을 의미할 수 있다.나는 그 단어에 대해 어떠한 자동 소프트웨어 반응도 있어서는 안 된다고 생각한다.그것은 가치 있는 것보다 더 많은 혼란과 짜증을 일으킬 것이다.프라임헌터 (토크) 00:13, 2008년 7월 30일 (UTC)[응답]

나는 Prime Hunter의 말에 동의한다.존 F의 이 문장들을 생각해 보아라. 케네디 암살 사건: 1) "안보에 대한 우려가 있었는데, 왜냐하면 1963년 10월 24일에야 유엔 주재 미국 대사인 애들라이 스티븐슨이 댈러스를 방문했을 때 야유당하고, 떠밀리고, 항의 표시에 맞고, 침을 뱉었기 때문이었습니다." 2) 11월 22일 저녁, 댈러스 경찰서는 파라핀을 실시하였다.오스왈드의 손과 오른쪽 뺨에 대한 테스트는 과학적인 테스트를 통해 오스왈드가 최근에 무기를 발사했는지 여부를 판단하기 위한 것이다."그 단어는 의미로서 즉각적으로 현재 진행 중인 의미를 더 많이 가지고 있기 때문에 블랙리스트 작성은 위키백과에 적합한 다른 방법으로 사용될 때 문제를 일으킬 수 있다.그루티니스...뭐라고? 2008년 7월 30일 00:51 (UTC)[응답하라]

생각해 보면, 최근(그리고 *ly)이라는 단어는 실제로 흔히 쓰이는 단어일 가능성은 매우 낮다고 말할 수밖에 없다.그럼에도 불구하고, 그것을 찾아낸다는 생각은 나를 혼란스럽게 한다.이것에 대한 나의 문제는 초점을 맞출 수 있는 많은 단어와 구절들이 있다는 사실이지만, 만약 여러분이 그것들에 대해 보호한다면 결국 위키피디아는 편집하기 귀찮아질 것이고 나는 그것이 사기를 해칠 것이라고 생각한다.위키피디아의 위대한 점은 모든 것이 단서가 만들어지는 순간부터 완벽하게 표현된다는 것이 아니라, 한 작가가 기사를 시작할 수 있고, 또 다른 작가는 그 기사를 개선할 수 있으며, 그럼에도 불구하고 또 다른 작가는 편집자가 저지른 실수나 그 이전에 저지른 실수를 고칠 수 있다는 것이다. (그리고 기타 등등) 당신이 알고 있는 바로는 모든 사람들이 놀랄 만큼 정보적인 기사를 가지고 있다는 것이다.전세계에서 읽고 배울 수 있다.나는 단어와 용어를 돌보는 것은 모든 과정을 너무 자동화하고 위키피디아의 인간적인 요소와 함께 어울리는 가치의 일부를 앗아간다고 생각한다.그래서 나는 그 단어가 거의 해당되지 않는다는 생각에 동의하지만, 나는 그것을 막기 위해 %-SYKKO-% (내게 말함) 01:53, 2008년 7월 30일 (UTC)[응답하라]는 어떠한 과정도 시행되어야 한다는 것에 동의하지 않는다.

AWB나 반짝이나 뭐 그런 걸로 더 잘한 것 같아 (이것들을 실제로 본 적이 없어서 잘 모르겠어.)단지 단어를 검색하고, 문맥을 읽고, 적절한 경우 변경하십시오.아니면 그런 면에서 구글을 이용할 수도 있다.~ JonnyMrNinja 02:04, 2008년 7월 30일 (UTC)[응답]

음...나는 JFK와 지질학적 예들이 내가 고려하지 않았던 좋은 반증이라고 생각한다.비록 내가 생각하기에 그 기사들에 플래그를 지정하는 자동적인 방법이 부적절한 용도를 찾고 수정하는 과정을 상당히 빠르게 할 것이다.이렇게 해서 편집자들이 확인할 수 있는 기사 목록을 제작할 수 있는 봇이 있을까?Zunaid©® 09:02, 2008년 7월 30일 (UTC)[응답]

자신의 사용자가 대화 페이지를 편집할 수 없도록 제안

사용자(예:사용자:예)는 사용자 및 사용자 대화를 편집할 수 없음:예시지만 다른 사람은 할 수 있기 때문에 향후 논의(ex)에 대해 경고를 받을 수 있다.양말 태깅) 나루톨로베히나타5 09:21, 2008년 7월 30일 (UTC)[응답]

사용자는 특정 페이지의 편집을 금지할 수 있지만, 이것은 기술적이거나 물리적인 메커니즘이 아니다.그러나 사용자가 무한정 차단되거나 {{unblock}} 템플릿을 남용하지 않는 한 사용자의 사용자 공간 편집이 금지되는 상황은 처음 알았다.우선, 위키피디아에서 의사소통이 필요하고, 그들의 사용자 공간은 그들이 자신의 토크 페이지나 다른 누군가의 것에 회신하는지에 관계없이, 그것을 위해 사용된다.x4206 Talk Mess 09:26, 2008년 7월 30일 (UTC)[응답]

음, 나는 그것에 대해 생각하고 있었어.그러시죠.렛이 이걸 잡아먹었어나루톨로베히나타5 09:28, 2008년 7월 30일 (UTC)[응답]

WP에서 가능한 문구 변경:FN

이 편집에 이어, 현재 WT에서 의견이 모아지고 있다.FN은 가이드라인이 편집실무에 대한 권고안을 제시하지 말고 각 접근방식의 장단점을 개략적으로 설명해야 한다고 규정했다.파파 리마 위스키 (토크;도) 2008년 7월 30일 17:14 (UTC)[응답하라]

암호로 보호된 저널 문서에 대한 액세스

이 문제는 아마도 제기되었을 것이다. 하지만 위키피디아가 모든 암호로 보호된 저널에 편집자들에게 온라인 액세스를 제공할 방법이 있을까?나는 하나의 사용자 이름과 비밀번호로 내가 원하는 거의 모든 저널 기사에 무료로 접근할 수 있는 제도적인 "Athens" 계정을 갖게 되어 다행이다.하지만 그런 게 없다면 너무 답답할 것이고, 그렇게 많은 사람들이 접근하지 못한다는 생각이 마음에 들지 않는다.위키백과의 정신이나 출처와 지식의 균등하게 접근하는 것 같지는 않다.

나는 위키피디아가 아테네와 같은 계획에 동참하는 사람들처럼 일정 기간 동안 자격과 신분증을 가진 직원과 학생들을 가진 대학이나 기관과 같지 않다는 것을 깨달았다.그래서 그것은 아마도 불가능하고 기존의 계획들이 그것을 관리할 수 없었거나 저널들이 그것을 원하지 않았을 것이라고 말하기는 쉬울 것이다...하지만 혹시 기회가 있을까?의심의 여지 없이, 자격을 갖춘 편집자들이 어떤 식으로든 제한을 받아야 할 것이다, 아마도 "정립된" 편집자들이든 뭐든 간에...그리고 나는 각 편집자가 1년간의 접속이나 그 무엇에 가입하기를 원하는 소액 결제가 있어야 하고, 아마도 그들의 IP주소와 연결된 비밀번호/사용자 이름 또는 비밀번호/사용자 이름이 너무 쉽게 획득되고 전달되는 것을 막기 위해 어떤 것이든 간에 필요할 것이라고 생각한다.

나는 아테네와 같은 계획이 어떻게 재정적인 측면에 작용하는지는 잘 모르지만, 확실히 더 많은 사용자와 자금이 그들을 위해 그리고 다시 저널을 위해 더 좋게 작용할 것이다.그리고 더 많은 사람들이 더 높은 품질의 원천에 접근할 수 있다면 위키피디아에 더 좋을 것이다(그것은 그러한 출처의 해석과 사용에 대한 증가된 지침을 필요로 한다 하더라도, 그것을 감당할 수 있는 사람들은 과학적인 자격증이나 학문적인 자격증과는 상관없이 이미 그 기사에 응대할 수 있다는 것에 주목한다).에버프루즈 (대화) 21:27, 2008년 7월 24일 (UTC)[응답]

그것은 사실 꽤 좋은 생각이다; 나는 너와 같은 처지에 있고 내가 필요로 하는 거의 모든 것에 제도적으로 접근할 수 있다. 하지만 나는 많은 편집자들이 누구와도 학문적으로 연관될 기회가 없고 도서관이 제공할 수 있는 제한된 자원에 의존해야 한다는 것을 알고 있다.셀라노르 21:32, 2008년 7월 24일 (UTC)[응답]

좋은 생각이지만 아마 결코 좋은 생각이 아닐 것이다.그렇지 않다면, 이 프로젝트는 전통적인 학문적 추구와 같은 관점에서 결코 간주되지 않을 것이며, 위키피디아와 같은 공개 프로젝트에서 어떤 구독 기반 단체가 그들의 자료에 대한 그룹 접근권을 갖는 것이 어떻게 괜찮을지 보지 못할 것이다.2008년 7월 24일 세레 21:35 (UTC)[응답]

출판사와 집계업자들은 보통 그들의 학생과 직원 FTE를 합친 것에 근거하여 대학에 요금을 부과한다.위키피디아는 "설립된" 편집자의 수를 상당히 신뢰할 수 있게 셀 수 있었지만, "설립된" 많은 버전은 위키미디어 재단의 자원을 훨씬 넘어 그 수와 수반되는 가격을 밀어낼 것 같다.나는 WMF가 엔에 대한 접근권조차 살 돈이 있는지 의심스럽다.위키 관리자.

나는 WMF가 학문적 명성을 갖지 못하는 것에 문제가 없을 것이라고 생각한다.출판사들은 그런 것에는 관심이 없다.출판사들은 익명의 접속을 다소 우려하지만, 이미 악용되는 접속을 차단할 수 있는 메커니즘을 갖추고 있다.많은 대학 도서관은 어떤 식으로든 대학과 연계될 것을 사용자들에게 요구하지 않는다; 어떤 것은 연방법에 의해 이루어질 수 없다.출판업자들은 이것을 다루는 법을 배웠다.잭슈미트 (talk) 2008년 7월 24일 (UTC) 21:41 (talk)[응답]

위키미디어 재단은 처음에는 최소한의 액세스만 구입할 수 있었고, 그 후에 편집자들이 등록하여 충분한 수수료를 지불할 때까지 기다렸다가 더 구입할 수 있을 것이다.사용자당 기관에 부과되는 요금이 편집자에 대한 합리적인 개별 가입비보다 훨씬 더 큰 것이 아니라면, 나는 모르겠다.에버프루즈 (대화) 22:43, 2008년 7월 24일 (UTC)[응답]

이것의 가장 큰 문제는 위키피디아 가입의 기준이 너무 낮아서 사람들이 이 기록들에 접근하기 위해서만 가입하는 것이 행복할 것이라는 점이다.승인되고 검증된 사용자 중 일부 계층이 이러한 리소스에 액세스하거나, 관리자(예: 관리자)를 할인 받는 것이 타당할 수 있다.문제는 여기에 쓰인 돈이 이런 식으로 가장 잘 쓰일 수 있을 것인가, 아니면 이러한 사용자들이 전형적으로 다른 방법으로 이러한 자원에 접근할 수 있을 것인가 하는 것이다.Dcoetzee 18:28, 2008년 7월 25일 (UTC)[응답]

이 제안은 좋을 것 같고 여기 아테네 http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2268217에 대한 기사가 있어. 비록 이 기사의 모든 내용을 이해하지는 못했지만, 위키백과의 경우 이런 시스템을 갖추는 것이 매우 어려울 것 같다는 생각이 들어. --Bob K31416 (토크) 20:02, 2008년 7월 25일 (UTC)[응답]

아래에 있는 내 스레드를 참조하십시오.나는 위키피디아에 텍스트가 독점적 데이터 형태로 되어 있지 않으면 타당하지 않다는 감정의 기류가 스며들고 있는 것이 상당히 우려된다.그런데, 나는 콘텐츠 과학 저널에 대한 하드 카피 지불의 효용이 급속히 줄어들고 있다고 의심한다.소프트웨어가 오픈소스여야 하듯이 과학적인 담론도 그래야 한다.메날라루스2

아래는 무슨 실인가?에버프루즈 (대화) 06:22, 2008년 7월 30일 (UTC)[응답]

어쨌든, 나는 원천이 그들 자신의 장점에 따라 판단되어야 하고 과학적인 담론이 열려 있어야 한다는 것에 매우 동의한다.이것은 그러한 방향으로의 움직임일 것이다. 각 개인이 개별 기사/저널을 구입하거나 오도할 수 있는 추상적인 것에 의존하기 보다는, 이 방대한 온라인 출처 저장소에 더 저렴하고 쉽게 접근할 수 있도록 기존의 위키백과 편집자 수를 합친 것이다.(대화) 13:03, 2008년 7월 31일 (UTC) p.s.는 위키피디아가 있다는 것을 깨달았다.위키프로젝트 리소스 교환은 이와 같은 소스를 나열하거나 요청하지만 얼마나 많은 사용량을 얻을 수 있는지 모른다.에버프루즈 (토크) 2008년 7월 31일 (UTC) 13:22 [응답]

대화 페이지를 아카이브로 이동할 때 기록 복사

이 제안은 위의 제안과 관련이 있지만, 나는 그것의 타당성에 대해 덜 확신한다.나는 토크 페이지의 아카이브를 만들 때 토크 페이지와 함께 토크 페이지의 이력을 움직이는 어떤 자동적인 방법이 있어야 한다고 생각한다.벌써 가능한 일인가?이런 예감이 든다.그렇다면, 나는 이 조치가 보관 도움말이나 보관 템플릿 문서에 더 두드러지게 금지되어야 한다고 생각한다.샤크D (대화) 03:04, 2008년 7월 30일 (UTC)[응답]

(섹션 제목에 따라) 히스토리를 복사하거나 (실제 게시물에 따라) 이동 히스토리를 복사하는 것을 말하는 겁니까?기사토크 페이지의 경우 일반적으로 역사를 메인토크 페이지의 한 부분에 보관하고 여러 개의 아카이브 페이지 사이에 분리하지 않는 것이 좋다.참고 항목: 도움말:요점을 인용하기 위한 대화 페이지 보관:

토크 페이지 이력을 한 곳에 보관하는 아래에 기술된 "컷 앤 페이스트" 방법을 사용하는 것이 널리 선호된다.해당 기사의 대화 페이지에 대해 상쇄적인 합의가 이루어지지 않는 한, 기사 대화 페이지에 대해 "페이지 이동" 보관을 사용하지 마십시오.

Dbiel^(Talk) 03:20, 2008년 7월 30일 (UTC)[응답]

좋아, 그건 내 질문에 대한 대답이야.샤크D (대화) 2008년 7월 30일 (UTC) 20:14, 응답

이를 달성하기 위한 한 가지 방법은 페이지를 보관하기 위해 (복사 및 붙여넣기 대신) 페이지를 이동하는 것이다.그런데 이게 왜 바람직한 아카이브 방법인지 잘 모르겠어. -- 다쿠(토크) 03:23, 2008년 7월 30일 (UTC)[응답]

이렇게 하는 목적은 대화 페이지의 차이를 더 쉽게 검색할 수 있는 것이다.즉, 코멘트에 대한 차이점을 찾으려고 할 때 코멘트가 있는 페이지가 아카이브 페이지인 경우, 내역이 다른 기사에 있기 때문에 코멘트에 대한 차이점을 찾기가 어렵다.이것에 반대하는 가장 좋은(그리고 아마도 최종적으로는) 주장은 되돌릴 수 없다는 것이다.예를 들어, 나중에 어떤 이유로 두 개의 보관된 대화 페이지를 병합하려고 한다면, 이력도 병합할 수 없을 것이다.샤크D (대화) 2008년 7월 30일 (UTC) 20:16, 응답

차이점을 찾는 가장 쉬운 방법은 일치하는 타임스탬프에 대한 사용자의 기여도를 검색하는 것이다.그러나 인터페이스의 타임스탬프는 사용자의 시간대 프리프(prefs)에 의해 조정되며 사용자 시그널의 타임스탬프는 일정하게 유지되므로 UTC +/- 0을 사용하는 경우에만 잘 작동한다.나는 아마도 이것을 자동으로 하는 자바스크립트를 만들 수 있을 것이다.며칠만 줘.— CharlotteWebb 22:18, 2008년 7월 30일 (UTC)[응답]

만약 토론 페이지가 이사가 가능할 만큼 충분히 넓다면, 아마도 사람들은 이 주제에 대해 자주 토론하고 있을 것이다.만약 사람들이 이 주제에 대해 자주 토론한다면, 토크 페이지를 옮기는 것은 아마도 진행 중인 토론에 지장을 줄 것이다.- Twas Now (토크 • 기여 • 이메일 ) 05:33, 2008년 7월 30일 (UTC)[응답]

무슨 말인지 잘 모르겠어.페이지를 이동하면 원래 페이지가 리디렉션으로 바뀔 뿐이다.이 경우 리디렉션은 자체적이고 새로운 내역이 포함된 새로운 대화 페이지로 변환될 것이다.샤크D (대화) 2008년 7월 30일 (UTC) 20:14, 응답

"새로운 역사"는 현재 진행 중인 논의를 생략할 것이라는 주장이다.— CharlotteWebb 22:18, 2008년 7월 30일 (UTC)[응답]

예, 하지만 토론은 이미 (일반적으로) 일정 기간 동안 주제가 사그라진 후에야 보관된다.나는 이렇게 함으로써 추가적인 위험이 사라지지 않는다고 생각한다.샤크D (대화) 01:41, 2008년 8월 1일 (UTC)[응답]

[1]처럼 토크 페이지의 역사를 한 번에 볼 수 있는 것이 도움이 된다.페이지 이동에 의해 보관되었다면 하나의 큰 페이지가 아니라 여러 페이지를 로드해야 했을 것이다.— CharlotteWebb 22:18, 2008년 7월 30일 (UTC)[응답]

흰색 배경에서 조광기 색조 옵션으로

위키백과 기사의 배경색을 바꿀 방법이 있다면 알려줘.그렇지 않으면 배경색을 흰색에서 회색으로, 또는 또 다른 덜 강렬한 색상으로 바꾸기 위해 버튼을 클릭할 수 있는 것이 좋은 선택일 것이다.하드 드라이브에 기사를 저장한 다음 바디 태그를 bgcolor="#CCCCCCC"로 바꾸려고 했지만, 예를 들어, <body bgcolor="#CCCCC"로 바꾸려고 했지만, 이 방법은 효과가 없고, *.css 파일을 찾아갔을 때, 시도해야 할 것이 너무 많았다.

ELApro (대화) 2008년 7월 31일 (UTC) 20:42, elapro@yahoo.com[응답]

사용자 지정 스타일시트 페이지로 이동하여 스타일시트를 수정하십시오.정확한 구문은 잘 모르겠지만, 거기서 할 수 있다.나는 누군가가 너에게 필요한 정확한 코드를 가지고 올 것이라고 확신한다.칠음 20:44, 2008년 7월 31일 (UTC)[응답]

내용 상자의 배경(페이지 탭 아래의 모든 항목 및 메뉴 오른쪽)을 변경하려면 사용자 정의 스타일시트 페이지에 다음 줄을 추가하십시오.

#내용 {배경: #CCC; }

다른 색상을 사용하려면 #CCC를 다른 육각색 코드로 교체하십시오.Meta를 통해 살펴보십시오.일부 아이디어에 대한 사용자 스타일 갤러리, 몇 가지 더 어두운 스타일이 있는데, 만약 당신이 원하는 것이 바로 그것이다.모든 베스트 – Ikara^{talk →} 01:36, 2008년 8월 1일 (UTC)[응답]

메인 스페이스가 흰색이기 때문에, 메인 스페이스에 영향을 미치지 않는 다른 모든 것은 밝은 파란색 CSS가 설치된다.대수학자 01:41, 2008년 8월 1일 (UTC)[응답]

메인 스페이스 페이지를 흰색으로 설정하는 CSS만 재정의하면 된다.

.ns-0 * #내용물, .ns-0 * #p-causes ri.선택된 a, .ns-0 * #p-causes ri a:맴돌다 {     배경:#ccc; } 

아노미에 02:12, 2008년 8월 1일 (UTC)[응답]

disabigation 리디렉션의 봇 생성

위키백과의 토론:Foo(해제)의 모든해제 페이지는 적어도 Foo(동음이의)에서 만들어진 것으로 리디렉션을 갖도록 제안되었지만, (해제)를 끝낼 VPP#ALL해제 페이지는 (해제) 페이지에 대한 명명 규칙의 측면에서 정책 변경의 시행 여부에 대해서는 합의에 이르지 않았다.ist. 이것이 봇에게 적합한 작업이 될 것이라는 지적도 나왔다.이후 위키피디아에서 다음과 같은 요청이 있었다.Bot_requests#Disambigation_redirects.그 요청의 기술적 측면을 검토한 후, 나는 더 넓은 청중이 몇 가지 우려를 해결할 수 있도록 이 문제를 제기하기로 결정했다.

이 제안의 근거를 간단히 요약하면 페이지 이동, 기존 기사 변경 또는 기존 정책 변경 없이, 아직 존재하지 않는 곳에 리디렉션을 만들 것을 제안할 뿐이다.이것은 일관성을 위해 그리고 검색 보조 수단으로 언급되어 왔다.특별히 해로운 것은 아니지만, 이러한 리디렉션을 만드는 것도 불필요할 수 있다는 지적도 나왔다.

{{disambig}} 템플릿(및 그 파생상품)을 사용하는 기사가 무엇인지 조사를 해보니 Foo(동음이의)가 아닌 Foo에 11만4402건의 해체 기사가 있다.이들 중 일부는 이미 기존 리디렉션을 가지고 있지만, 숫자를 간단히 살펴보면, 최소한 이 제안이 88,043개의 기사를 만들 것이라는 것을 알 수 있다.제안의 범위(88,000~115,000개의 리디렉션 생성)를 고려할 때, 나는 여기서 어느 정도의 정밀 조사가 필요하다고 생각한다.

다시 말하지만 기술적 관점에서 이것은 꽤 간단하다 - 그것은 단지 큰 범위일 뿐이다.그러므로 나는 공동체의 의견을 구하고 있다.나는 이 문제에 대한 대부분의 의견이 몇 가지 다른 유형 중 하나에 속할 것이라고 생각한다.

• 이 제안이 유익하고 반드시 실행되어야 한다는 것
• 이 제안이 유해하지 않고 실행될 수 있는지 여부
• 이 제안이 유해하지는 않지만 실행될 만한 가치가 없을 것
• 이 제안이 정당하지 않으며 실행되어서는 안 된다는 것

본 제안의 이행에 충분한 관심이 있다면 WP와 함께 제기하여 봇 요청을 후속 조치할 것이다.BOT의 기술적 구현에 따른 승인을 위한 BAG.실행 의지가 부족하거나 앞으로 나아가서는 안 된다는 상당한 의견이 있으면 원청들에게 이 문제를 더 이상 압박하지 말 것을 권고할 것이다.미리 감사드리며, 2008년 7월 28일 (UTC) 19:26 (응답)

나는 3번째나 4번째 그룹에 속할 것 같아."Foo"를 검색하는 경우 검색 상자에 "Foo"를 입력하십시오.'푸'라는 이름의 기사가 여러 개일 가능성이 높다는 것을 알고 있더라도, 내가 종영하는 '푸'가 제대로 된 '푸'가 아니라면 기사 위에 있는 해트노트의 링크를 클릭해야 할지도 모른다는 위험을 감수해야겠다.나는 여분의 시간을 "Foo (해체)"를 타이핑하는 데 쓰지 않을 거야.사람들이 실제로 이것들을 검색할 확률은 낮으며, 우리는 리디렉션하기 위해 의도적으로 연결되지 않도록 해야 하기 때문에, 나는 리디렉션에 대한 많은 링크가 이미 존재하지 않는 한 리디렉션을 만드는 것에 반대한다.링크가 몇 개만 있다면 업데이트만 하는 것이 좋을 것이다.Mr.Z-man 20:27, 2008년 7월 28일 (UTC) — (수정) 처음에 약 8만 8천 페이지 이상의 부분을 보지 못했는데, 그건 말도 안 되는 소리야.Mr.Z-man 23:30, 2008년 7월 29일 (UTC)[응답]

난 2그룹이나 3그룹에 속해있어 대부분 무감각해 하지만 그게 할 수 있는 해악은 없어그것은 위키피디아가 다음과 같은 경우에 해당된다.성능에 대해 걱정하지 마십시오. 이 많은 페이지를 작성할 때 사이트별로 어떤 단점이 있는지 알 수 있는가? -- Natalya 00:13, 2008년 7월 29일(UTC)[응답]

(내가 의심하는 것은) 있다고 해도, 그 봇은 그러한 부작용을 제거할 수 있을 만큼 충분히 천천히 작동하도록 프로그램될 수 있다.--에르바나스는 고아원에 03:54, 2008년 7월 29일 (UTC)[응답]

예를 들어, 성능이 중요한 "템플릿질라" 구성 등 문제가 될 수 있는 경우가 있지만 페이지를 만들고 편집하는 것은 위키의 가장 기본적인 두 가지 기능이며, 우리가 원하는 어떤 것이든 할 수 있을 정도로 최적화되어야 한다.나는 너의 상위 두 그룹 중 한 그룹에 속해 있어, 나는 그것이 우리가 그것을 하는 데 어떤 재앙을 일으킬 것이라고 생각하지 않아.9만 페이지(간접)도 아마도 지금까지 행해진 것 중 가장 큰 봇창작은 아닐 것이라는 느낌이 든다.{{citation need}} --_{tiny plastic} 그레이 나이트 grey 09:12, 2008년 7월 29일 (UTC)[응답]

안녕, 여러분, 나는 이 제안의 원래 선동자야. 그리고 나는 이 봇이 만들어지는 것에 찬성하는 내 주장을 반복하고 싶어.WP에서의 나의 원래 제안서:(해체)를 끝내기 위한 VPP#ALL 해체 페이지, 나는 Foo와 같은 {{해체}가 포함된 페이지를 모두 Foo(해체)로 리디렉션하자고 제안하면서 시작했지만, 알고 보니 그것은 현행 위키백과 정책에 어긋났고 사람들은 대체로 그 생각에 반대했다.이후 바(Disambiggation)와 같이 현재 존재하지 않는 페이지를 만들어 {{disambig} 템플릿이 들어 있는 바(Bar)로 리디렉션하도록 하는 아이디어가 되었다.이것은 만약 누군가가 금속 막대에 관한 기사가 무엇이라고 불릴지 확실하지 않아 "바(해체)"를 입력했다면, 그들은 항상 그들을 올바른 방향으로 가리키는 적절한 페이지로 이동하게 된다는 것을 의미할 것이다(바텐더-바(barenders-and-bar) 바 기사[또는 그 반대]로 옮겨지는 것과는 대조적이다).처음에 내가 준 예는 내가 처음 제안을 시작했을 때 레드링크였지만 나중에 리디렉션으로 만들어졌던 택시(해체)이다.그러나 6만여 장 정도의 그런 존재하지 않는 해프닝 페이지는 여전히 남아 있어 아직 할 수 있는 일이 많다.

누군가 (해산) 타이핑을 한다는 생각이 바보처럼 느껴진다면, 내가 위에서 설명한 정확한 이유 때문에 타이핑을 한다는 것을 장담할 수 있고, 아마도 다른 사람들도 그렇게 할 것이다.해트링크에 의존하는 경우, 사용할 템플릿과 정확히 무엇을 타이핑할 것인지에 대한 인간의 생각이 필요하므로 항상 수동으로 생성해야 한다. 그러나 리디렉션 및 디스케이블 페이지에서는 사용자가 찾고 있던 페이지의 링크가 거기에 있을 것이라고 확신할 수 있다(해트링크에 의존하는 경우).d) 그리고 내가 제안한 리디렉션은 해트링크보다 리디렉션과 디스어셈블리를 제공하는 봇에 의해 수행될 수 있다.

Foo (Disambigation) → Foo 리디렉션에 대한 나의 주된 주장은 그들이 아무런 해를 끼치지 않을 것이라는 것이다.제목에 (해체)가 있는 회사나 사람, 그 밖의 것은 없기 때문에 현재 존재하지 않는 페이지들은 앞으로 다른 어떤 것에도 반드시 필요하지 않을 것이다.게다가, 그러한 연결고리는 거기 앉아서 아무 것도 하지 않거나 혹은 필요한 기사를 찾는 누군가에게 도움이 될 것이고, 따라서 그들은 위키피디아에 의해서만 인공적으로 될 수 있다.

그리고, 다시 한 번 말하지만, 제안서는 현재 상태로는 정책 변경이나 페이지 이동이 없으며, 리디렉션 페이지만 작성한다는 사실을 다시 한번 강조하겠다.

일부 사람들은 그러한 리디렉션으로 토론의 범위가 있을 수 있다고 제안했다.예를 들어 특정 주제에 대해 두 개 이상의 설명 페이지가 있거나, 설명서에 {{disambig}} 이외의 다른 템플릿이 포함될 수 있다(전체 목록은 CAT:DRT에서 찾을 수 있음).이것들은 모두 공정한 지적이지만, 당분간 우리의 봇은 {{disambig}}} 이외의 템플릿이 있는 어떤 페이지도 무시하고, 또한 {{disambig} 템플릿과 제목에 (또는 ) 문자가 있는 페이지도 무시하도록 만들 것을 제안한다.내 계산에 의하면, 그것은 봇이 Foo (해체) → Foo (장소)와 비논리적 Foo (해체) → Foo (해체) 리디렉션을 만드는 것을 막을 것이다.그러면, 일단 봇이 쉽고 논란의 여지가 없는 편집들을 만들어내기 시작하면, 우리는 프로젝트를 확장하는 최선의 방법에 대해 이야기 할 수 있다.그러나 당분간 나는 "바레본" 봇에 대한 합의를 모색하고 있을 뿐이다.

It Is Me Here (대화) 09:23, 2008년 7월 29일 (UTC)[응답하라]

지지하다.나는 이것이 어떤 사용자들에게 유용하고, 아무도 해치지 않는 다는 것을 알 수 있다. 그리고 만약 당신이 봇 일을 기꺼이 할 누군가를 찾을 수 있다면, 나는 당신에게 더 많은 힘을 말한다.페이지 통계를 설명하기 위해 링크에 총계를 넣을 수 있지만 프로젝트 페이지에 왜 그런 일이 일어났는지 설명하는 코멘트가 추가될 수 있다.Mlaffs (대화) 15:28, 2008년 7월 30일 (UTC)[응답]

지원 고맙지만 페이지 해제에 대한 링크 문제에 대해서는, 그 규칙은 페이지를 리디렉션하는 것이 아니라 기사 네임스페이스에서 해제에 이르는 링크를 참조하지 않을까(기사 네임스페이스 → 위키백과 네임스페이스 링크는 금지됨과 마찬가지로)?It Is Me Here (talk) 2008년 7월 31일 (UTC) 19:42, 응답하라

잘 모르겠어. 그 논리가 어떻게 작용하는지 러스봇의 운영자에게 확인해 봐야 할 거야.리다이렉트 페이지는 카운트에 포함되는 것처럼 보이지만, 내가 틀릴 수도 있다.하지만 난 그게 정말 문제가 된다고 생각하지 않아.Mlaffs (대화) 2008년 8월 1일 15:16, (UTC)[응답]

그것은 개념적으로 설명 페이지들에 대한 총 링크의 수를 증가시키겠지만, 링크가 있는 위키피디아 제목 설명 페이지의 주요 업무는 그것들에 많은 수의 링크가 있는 설명 페이지를 다루는 것이다.만약 봇이 이 일을 하게 된다면, 각각의 모호한 페이지들은 하나의 링크만 더 얻게 될 것이고, 이것은 각각의 페이지들의 수를 크게 증가시키지 않을 것이다. (사실, 오직 한 장으로만). : )모든 불분명한 페이지에 대한 링크의 총수는 확실히 증가하겠지만, 나는 그것이 얼마나 큰 거래일지/만약 그것이 거래가 될 수 있을지 확신할 수 없다. -- Natalya 19:56, 2008년 8월 1일 (UTC)[응답]

현재 상태로는 이 제안에 대한 지지가 미지근해 보이지만 심각한 이견은 거의 없다.주말 동안 토론이 진행될 수 있도록 하겠다. 추가 반대 목소리가 나오지 않는 한 WP에서 논의하겠다.검토용 가방.2008년 8월 1일 셰어 23시 1분 (UTC)[응답]

여기서 사용되는 Commons 이미지의 분류(en).위키백과)

나는 최근에 사용자가 유용하다고 느낄 수 있는 이미지를 그룹화하기 위해 카테고리의 미디어 기능을 활용하는 작업을 수행하고 있다(예: 카테고리:나비와 나방의 이미지).나는 우리의 많은 자유(libre) 이미지들이 공유지에서 호스팅된다는 것을 알고 있었지만, 우리의 많은 이미지들이 여기에 상응하는 페이지가 없이 그곳에서 소싱된다는 것을 주목하지 못했다.예를 들어, 나비 카테고리를 합쳐서, 나는 현재 공유지에서 사용되고 있는 3000개 이상의 이미지 - 기사에 사용되고 있는 3000개 이상의 이미지를 발견했다.자, 분명히 나는 독자와 편집자를 위해 이것들을 분류하고 싶다. 우리 기사의 멋진 시각적 색인을 가질 뿐만 아니라, 이미지 관리에도 도움을 주고 싶다. (범주화는 불필요한 중복성을 확인할 수 있는 두 번째 기회를 더한다.)하지만 당신은 위키피디아의 한 페이지에 WP에서 꿈틀거리고 있다는 것을 알게 될 것이다.Commons#Categorization은 "아니오, 대신 Commons를 분류하십시오."라는 단문장이다.자, 나는 커먼즈 사상이 마음에 드는데, 그 근거를 확인해봐.그러나 이상적으로는 모든 자유 영상을 공유 영상으로 이동해야 하며, 기사 외부에 자유롭지 않은 이미지를 표시할 수 없다면,이미지를 표시할 이유가 무엇인가 있는 수?나는 영어 위키백과에서 사용되는 모든 무료 이미지를 시각적으로 색인화할 수 있는 방법이 없다고 말하는 것은 우리의 사용자들과 편집자들 모두에게 해롭다고 생각한다.이 가이드라인은 한 달에 몇 번 비봇/비반달 관련 편집을 받는 페이지에서 아무런 근거도 없이 제공되며, 질문한 지 3개월 후 마지막 답변이 나온 토크 페이지도 함께 제공된다.나는 이것에 대한 어떤 생각이나 논평에 대해서도 발언권을 갖고 싶다.-ζαπερραπρρ 00 00:43, 2008년 7월 31일 (UTC)[응답]

여기에 영어-위키피디아 특정 분류에 대한 빈 이미지 설명 페이지를 만들 수 있다.다만, 그렇게 한다면, 커먼즈도 분류해 주시오.Superm401 - Talk 05:26, 2008년 7월 31일 (UTC)[응답]

당신의 답변은 가이드라인에 어긋나는 것 같다.?) WP에서:커먼즈 - 그러나 개인적으로는 내가 화해를 할 수 있는 것이다. 누구나 지적할 수 있는 이전의 토론이 있는가? 또는 커뮤니티의 다른 어떤 것이 이것에 대해 어떻게 생각하는가?-ζαπερραπρρρρ 03:20, 2008년 8월 2일 (UTC)[응답]

위키백과:현지 대사관

이것은 솔직히 말해서 직원 수가 적고 거의 인원이 없는 것 같은데, 1년 넘게 응답이 없었고, 첫째로 국제 사용자들이 더 쉽게 이용할 수 있어야 하며, 둘째로 편집자들의 지원을 받아 주류 사용에 더 많이 통합되어야 한다.나는 이것을 상호작용 사이드바에 포함시키거나 커뮤니티 포털이나 마을 펌프에 통합하는 것을 제안하고 싶다.위키피디아에 3년 가까이 적극적으로 참여하고 있는데 전혀 들어보지 못한 유저에게 이런 얘기를 했다.Sedd^{Editor Review} 25n 21:06, 2008년 7월 25일 (UTC)[응답]

오! 진짜 대사관이 아니야우리가 위키피디아 국가에 갈 수 있다면 멋질 것이다.나는 "네!친애하는 위키피디아인 여러분" 우리는 우리의 신념을 지지해야 한다."위키피디아 여권에서는 이런 짜증나는 양말 퍼펫을 막기 위해 로그인 계정에 접속할 수 있었다. --CyclePat (대화) 21:35, 2008년 7월 25일 (UTC)[응답]

내 이해는 다른 위키에서 오는 사람들이 그들을 이해할 수 있는 누군가를 찾을 수 있도록, 그것이 본질적으로 특정 언어를 말할 수 있는 사용자들의 목록이어야 한다는 것이었다.개인적으로, 나는 그것을 사이드바에 넣는 것이 좋다고 말하겠지만, 나는 당신이 그것에 대한 합의를 얻기 위해 애쓸 것이라고 생각한다, GDonato (토크) 20:07, 2008년 7월 27일 (UTC)[응답]

Why not a name like "the Rosetta Stone of Wikipedia", "Wikisetta Stone", (see Rosetta Stone) or "WikiBabel Fish", "Babel Wikifish", (see Babel fish) or simply "the WikiTraductor", "Translitarater", or why not "Translingua" : Since "Trans" means "through" or "across, beyond, to go beyond" and Lingua means "speech, language"...만약 우리가 프로토-인도-유럽어로 돌아간다면, 인도-유럽 가족의 가상 재구성된 조상 언어인 우리는 아마도 트랜스-덴화(즉시 번역을 위해)아니면 "미들 언어를 통해서"라는 뜻의 "트랜스메디우스 링구아"가 더 나을 수도 있다. --CyclePat (talk) 05:41, 2008년 7월 29일 (UTC)[응답]

나는 이 아이템이 자동으로 옆구리에 붙을 필요는 없다고 생각해.그러나 사용자 설정에서 원하는 경우 사용자가 선택할 수 있는 옵션이 될 수 있다.그게 더 나을 것 같아. --CyclePat (토크) 05:45, 2008년 7월 29일 (UTC)[응답]

나는 원래의 제안에 강력히 동의한다.이것은 훌륭한 on=wiki 기능이 될 가능성이 있고 조정의 중심이다.그것은 커뮤니티 포털에 통합되어야 한다.미스터 IP 《열린 편집의 정의》 14:51, 2008년 8월 2일 (UTC)[응답]

위키미디어 구매력

위키미디어의 구매력이 무엇인지 알고 싶다.199달러짜리 낡은 비닐을 찾았다.만약 내가 물론 GFDL등에서 위키피디아에 내용을 재게재한다면 위키미디아가 이 오래된 비닐 구입의 일부를 지불할 수 있을까? b.tw. 문제의 비닐은 더 이상 저작권이 없기 때문에 우리는 그 내용을 재게재할 수 있다.또한 때로는 법정 녹취록을 요구하는 경우도 있었다.만약 이것이 주문되고 개별 저작권 상태에 의해 지불된 것이라면, (어쨌든 캐나다에서) 종업원이 지불인의 소유임을 나타낸다.그래서 이 물질은 GFDL로 자유롭게 방출될 수도 있고, 어쨌든, 내가 발견한 이 비닐은 1928년 경이고, 조지 5세에 관한 것이다.상태가 아주 좋다.그것은 또한 그의 희귀하고 첫 번째 오디오 녹음 중 하나이다.우리가 이 문제를 어떻게 해결할 수 있을 것 같아?그럴까?위키소스가 박물관의 일종과 같은 구매력이 되어 자료를 재게재할 수 있을까?그렇다면 위키피디아가 이 자료를 사용할 수 있을까? 이야기:영국이 현재의 예언자라면 조지 5세지만, 나는 이것이 더 큰 규모로 사용될 수 있다고 믿는다.--CyclePat (대화) 21:39, 2008년 7월 25일 (UTC)[응답]

나는 위키미디어 재단이 정보를 구입하기 위해 예산을 책정할 것인지에 대해 매우 의심스럽다; 나는 그들이 그것을 그들의 역할로 보고, 어떤 요청을 받아들이고, 어떤 자금을 조달할지 결정하고, 자금을 지출하고, 무엇이 실제로 전달되었는지 감시하는 시스템을 설치하여 운영하는 것은 행정상의 악몽이 될 것이다. (물론 이 모든 것은)영어 위키백과뿐만 아니라 200개 이상의 모든 언어 위키백과들에 대해서, 물론, 대부분의 위키백과가 아닌 많은 위키백과들이 여러 나라를 포함하기 때문에, 한 나라에서 특정 언어 위키백과의 과정을 접수하고, 또 특정 언어 위키백과를 취급하는 작은 파벌을 피하기 위한 조항이 만들어져야 할 것이다.그의 비슷한 공짜 돈 ... ) -- 존 브로튼 (리빙) 22:38, 2008년 7월 25일 (UTC)[응답]

이것을 다른 언어로 구현해 달라는 것이 아니다. --CyclePat (토크) 17:26, 2008년 7월 26일 (UTC)[응답]

위키미디아는 금전적인 문제가 없지만, 돈을 태울 돈도 없다- 나는 그것이 위키미디아의 자금을 쓰는 아주 좋은 방법이 될 것이라고 생각하지 않으며, 또한 그것이 어쨌든 우리가 목표로 하고 있는 것이라고는 전혀 생각하지 않는다.J 밀번 (대화) 2008년 7월 26일 18:10 (UTC)[응답]

위키미디아의 이사회 중 상당 부분(아마도 이런 프로그램을 승인해야 할)이 다른 언어로 된 "홈 위키"를 가지고 있다는 점을 고려하면, 이것은 결코 "영어 전용" 시스템이 되지 않을 것 같다.Mr.Z-man 20:55, 2008년 7월 26일 (UTC)[응답]

당신이 그 의견을 가질 자유는 있지만, 아무도 이것이 영어 전용 시스템이 될 것이라고 말하지 않았다.만약 다른 위키백과 시스템들이 그 후에 따라 하기를 원한다면 그것은 그들에게 달려있다.하지만 지금 당장은 1928년 조지 왕의 타이네 다리 내관 연설의 비닐에 대한 자금을 요청하고 있다.캐나다에는 국립문서보관소에 복사본이 있지만 일반인들은 그것을 사용할 수 없다.199달러에 파는 것을 찾았어.위키미디아가 비용의 절반 또는 약 100달러를 지불할 경우에만 이 카피를 사서 디지털 카피를 만들고 사진을 찍어 위키미디어에 올릴 것이다.이 제안에서, 나는 누구나 열람할 수 있도록 빈민가를 주최할 것이며(요청 시) 필요하다면 다른 지역 위키피디아나 혹은 동료 캐나다 국립문서보관자로부터도 검증을 받을 수 있을 것이다.이것은 제안이고 나는 그것이 여기에 속한다고 믿는다.하지만 조언해줘서 고마워...이것도 이사회에 제기하겠다. --CyclePat (토크) 21:29, 2008년 7월 26일 (UTC)[응답]

나는 네가 다른 언어를 위한 것이 아니라고 말했다고 믿는다.나는 당신이 "다른 위키백과 시스템"이 무엇을 의미하는지 잘 모르겠다. - 위키백과는 그 자체로 돈이 없다.그냥 웹사이트일 뿐이야.재단의 자금을 조달하려면 위키미디어(모든 프로젝트, 모든 언어) 시스템이어야 하고, 메타나 커먼스와 같은 프로젝트에 대해서만 사용해야 하는데, 이 두 가지 모두 다국어 프로젝트다.만약 당신이 이 프로젝트를 위한 시스템만을 원한다면, 그 돈은 아마도 단지 이것만이 아니라 모든 프로젝트를 책임지고 있는 재단이 아니라 개인 기부자들로부터 나와야 할 것이다.Mr.Z-man 21:38, 2008년 7월 26일 (UTC)[응답]

재단이 이런 자료를 구입하면 어떻게 하는 겁니까?도서관을 시작하고 필요한 사람에게 물건을 배송해 주는가? ---- Gadget850 (Ed) - 01:28, 2008년 7월 29일 (UTC)[응답]

Wikimedia 재단이 정보를 수집하는 데 돈을 쓰는 것은 결과적으로 공짜로 기부금을 받기가 더 어려워질 것이기 때문에 나는 강력하게 반대할 것이다.왜 내 돈을 안 내려고 그래?Filceolaire (대화) 2008년 8월 2일 16:14 (UTC)[응답]

페이지 보호 설명

많은 사용자들에게, 기사가 보호되었다는 것을 발견하는 것은 좌절스럽거나 혼란스러울 수 있다.어떤 경우에는 누구나 알아낼 수 있지만, 어떤 경우에는 그 이유가 불가사의하여 어느 정도 파헤칠 수 있다.RFP 항목의 텍스트를 기사 토크 페이지에 자동으로 포함시키는 것이 좋을까?그리고 이러한 포함을 요구하기 위한 좋은 방침은?나는 보호와 긴밀하게 협력한 적이 없기 때문에, 그 아이디어의 어떤 정교함도 높이 평가된다. 오픈 편집의 Defender인 IP씨, 15:09, 2008년 7월 27일 (UTC)[응답]

봇에게는 흥미로운 가능성처럼 들린다; 아마도 누군가가 WP에서 요청을 할 수 있을 것이다.BOTREQ? RFP에 게시물이 아니라 보호 로그에 기재된 내용에 의해 촉발되어야 할 것이다. -- John Brown (리콜라이저) 19:46, 2008년 7월 27일 (UTC)[응답]

보호 로그를 직접 확인해보지 그래?그것은 왜 그것이 보호되었는지를 설명해 줄 것이다.J 밀번 (대화) 2008년 7월 29일 (UTC) 16:46[응답]

보호 로그에 액세스할 수 없는 경우나는 보호 로그를 기사에서 직접 쉽게 접근할 수 있도록 하는 조치를 지지할 것이다.또한, 나는 모든 보호 편집 요약이 이유를 명시하도록 되어 있다고 생각했다. --acrocuse알렉스: 2008년 7월 29일 16시 49분 (UTC)[응답하라]

페이지가 토크 페이지에서 보호되는 이유는 분명 있어야 한다.신규/미숙련 사용자는 보호 로그가 존재하는지조차 알지 못할 수 있으며, 보호 로그가 어디에 있는지 모를 수 있다.또한 토크 페이지 상단에 "이 페이지는 다음과 같은 이유로 보호되었다." 그리고 그 이유는.이것은 봇이 하기 위한 간단한 작업이어야 한다. -- 임페라이터3733 (대화) 17:03, 2008년 7월 29일 (UTC)[응답]

업데이트를 위해 BOTREQ에 참가했는데, 해피멜론(Happy-Melon)이 보호-템플릿 유지보수를 위해 개발 중인 봇으로 이 새로운 기능을 접을 것이다.응원해줘서 고마워.미스터 IP 《열린 편집의 정의》 14:45, 2008년 8월 2일 (UTC)[응답]

디지털 서명이 있는 위키백과 동료 검토

나는 위키피디아에 새로운 신뢰 모델을 만드는 것에 대한 기사를 썼다.기사가 꽤 길어서 그냥 여기서 링크하는 거야.

그 아이디어는 선택적인 동료 검토 체계가 위키피디아와 통합될 수 있다는 것이다.검토자가 기사에 오류나 잘못된 정보가 포함되어 있지 않거나 다른 방법으로 품질이 적절하다고 동의할 때, 검토자는 단지 디지털 서명으로 기사의 특정 개정에 서명할 수 있다.누구나 기사에 서명할 수 있으며, 평론가들이 충분히 평판이 좋아 보이는지 결정하는 것은 독자의 몫이다.그 아이디어는 독자들이 글을 인용하거나 다른 심각한 용도에 적합하다고 판단하도록 돕는 것이다.

Ipuustin (talk) 13:21, 2008년 7월 28일 (UTC)[응답하라]

우리는 다양한 사용자들의 (접을 수 있는) 개정 서명 목록을 가지고 있는 토크 페이지 템플릿을 쉽게 만들 수 있었다.기사 페이지에 정보를 넣는 것에 대해서는 확신이 없지만, "이 기사는 피처링 기사" 스타나 "이 기사는 보호되고 있다" 자물쇠와 같은 작은 코너-아이콘을 가질 수 있을 것 같은데, 이것은 정보를 가진 사용자에게 목록에 대한 대화 페이지를 확인하도록 유도하는 것이다.사용자들은 자신의 사용자 페이지에 공개 키 약속을 지킬 수 있고, 만약 서명을 인플레이스 생성하기를 원한다면 나는 누군가가 사용자 자바스크립트 솔루션 및/또는 파이어폭스 플러그인 등을 만들 수 있다고 확신한다.요컨대 미디어위키에 전혀 변화가 필요 없이 이것을 하기 위한 전적으로 선택적인 인프라를 만드는 것이 가능해 보인다! --:-)_{tiny plastic} 그레이 나이트 ⊖ 15:24, 2008년 7월 28일 (UTC)[응답]

피처링 기사들이 상위권에 작은 별을 가지고 있듯, 이 역시 같은 포맷으로 통합되지 않으면 어떻게든 비슷한 것을 따를 수 있다고 생각한다. --CyclePat (토크) 07:17, 2008년 7월 29일 (UTC)[응답]

나는 그것이 어떻게 작동하는지 이해할 수 없어.나는 그들이 말하는 것에 있어서 높은 질의 글과 그렇게 적은 말을 하는 것에 있어서 낮은 질의 글들 둘 다를 확신한다는 것을 꽤 많이 알고 있다.(그것들은 모두 내 것이기 때문에, 나와 나는 매우 꼼꼼하고 천천히 그것들을 만들었고, 이러한 이유로 금방 지루해지거나, 피곤해지거나, 아니면 둘 다 포기했기 때문이다.권위 있는 스터브라고 증명해도 될까?그러나 잘 개발된 기사에 대해서는 (잠재적 편향성 등의 의문점은 제쳐두고라도) 어떤 기사들이 좋은지 확실히 알 수 없다.나는 FA 길이에 대한 어떠한 기사도 거치지 않았고, 인용된 언급과 대조적으로 FA의 모든 주장을 점검하지 않았다.나는 어떤 기사들은 꼼꼼하고 이해가능해 보이는 사람들에 의해 매우 꼼꼼하게 정리된 것으로 보인다는 것을 알 수 있다. (내가 한때 많은 편집자들이 8월의 신학자 User에서 가졌던 것과 같은 정도의 자신감을 가지고 있는 편집자들:에스제이).이 기사들(현실적으로, 이 다른 편집자들의 평판)에 나 자신의 평판을 걸 것인가?어, 고맙지만 아니에요내가 여기서 간과하고 있는 것은 무엇인가? -- 호리 (대화) 09:46, 2008년 7월 29일 (UTC)[응답하라]

위키피디아의 다른 모든 것들과 마찬가지로, 이 제안은 지역사회 중심의 자발적인 노력을 위한 것이다.어떤 사람이 서명할 필요는 없지만, 예를 들어, 귀하 자신이 특정 기사를 꼼꼼하게 확인하여 인증했다면, 해당 개정판에 대해 "디지털 서명"을 함으로써 이 내용을 진술하고자 할 수 있다.그러면 여러분의 의견을 소중하게 여기는 다른 독자(또는 여러분 자신을 인증하는 다른 사람들의 의견을 소중하게 여기는 독자 - 신뢰의 거미줄 참조)들은 그 특정 개정에 대해 조금 더 자신감을 갖게 될 것이다.독자가 신뢰하는 몇몇 사람들이 수정안에 서명했다면, 그것은 훨씬 더 좋다.분명히 이런 식으로 완전한 신뢰감을 얻을 수는 없지만 - 모든 사람에 대해 틀릴 수도 있지만 - 어떤 경우에는 어느 정도 만족감을 준다._{tiny plastic} -- Grey Knight ⊖ 10:27, 2008년 7월 29일 (UTC)[응답]

여기 우리가 사용할 수 있는 대화 페이지 상자의 예가 있다(아마도 상당히 개선될 수 있을 것이다).나는 또한 기사 자체에 "토피콘"을 추가하는 실험적인 {{revisions}} 템플릿을 만들었다. 다시 말하지만, 아마도 더 나은 이미지를 찾을 수 있을 것이다.참고로 아래는 {{signed revision top} 및 {{signed revision bottom}}에서 구성되며, {{signed revision}}이(가) 각각 본체 요소를 구성하고 있다.

{{signed revision top}}}{signed revision 123456 예제user1 24CB016EA}} {{ 서명된 개정판 234567 예시user2 20A75E12D 서명자-사용자=예시사용자Other}}}} {{ 서명된 개정판 345678 예시user3 1C83BABCA 서명자-서명=http://example.org/keydatabase/exampleuser3}}{서명 개정판 하단}}}

그게 무슨 소용이 있어 보이나? --_{tiny plastic} 그레이 나이트 ⊖ 11:16, 2008년 7월 29일 (UTC)[응답하라]

이것은 개념으로서 꽤 흥미로워 보인다.만약 그것이 유용하다면, 독자가 서명자가 누구인지, 그들의 자격 증명이 무엇인지 알 수 있는 적절한 방법이 있어야 한다.또한, 편집자들이 그들 자신의 편집에 서명하면서 COI 잠재력을 볼 수 있다.마지막 서명된 버전을 보기만 해도 너무 많은 사람이 확보되지 않는 한(따라서 현재 라이브 버전을 개선하는 데 도움이 되지 않는 한) 참고 자료로 유용할 것이다.녹농균_(talk) 13:59, 2008년 7월 29일 (UTC)[응답]

게다가, 나는 가장 큰 문제는 기술적 문제가 아니라 사회적, 즉 전문분야의 하나라고 생각한다.기사를 읽고 그 정보가 괜찮은지 확인할 수 있는 (feew!) 분야가 있다.다른 대부분의 경우, 내가 할 수 있는 일은 그것이 잘 쓰여져 있는지, 그리고 참고인들이 인용되고 있는 것을 말하는지를 확인하는 것뿐입니다.녹농균_(talk) 14:22, 2008년 7월 29일 (UTC)[응답]

위키피디아의 다른 모든 것들과 마찬가지로, 이 제안은 지역사회 중심의 자발적인 노력을 위한 것이다.정말?나는 그것을 "호리"인 나 자신이 기사에 오류나 잘못된 정보가 포함되어 있지 않다는 것을 개인적으로 보증하는 방법으로 읽었다.내가 특정 버전의 기사에 "Hoary by Holidated"를 찍으면, 이것은 내가 승인하고 Total Plastic이 승인하지 않았다는 것을 의미한다.하지만 (상상해보자) 사용자:토탈 플라스틱은 나의 오래된 위키컴이다: 우리는 2006년 초 "톰 크루즈가 유명하기 때문에 심리치료에 대한 그의 관점이 주목할 만하고 정신의학 기사에 많이 인용되어야 한다" 와커; 토탈은 항상 내 기사에 대해 매우 축하한다. 그리고 나는 그가 내 기사에 대해 비밀리에 그렇게 생각하지 않지만, 나는 그의 기사에 대해 알고 있다.프로소시에 대한 단서와 그의 시 관련 기사 편집에 대한 간절한 노력이 종종 그들의 손해라는 것을 알게 된다.당황스럽지만 은밀한 기쁨에 토탈은 내가 와타나베 카넨도 GA로 완수한 추진에 승인 도장을 찍었을 뿐(사실 그는 원본 자료를 하나도 읽지 않았음에도 불구하고, 모두 일본어로 되어 있기 때문에), 후디브라에 대한 그의 거대한 수정안의 완성을 기쁜 마음으로 발표했을 뿐이다.프로소디에 대한 나 자신의 제한적인 이해는 토탈이 다시 망쳤다는 것을 암시한다. 하지만, 아직도 스트렁크와 화이트를 진지하게 받아들이는 "잉글리쉬 메이븐"의 놀랄 만큼 어리석은 반대들이 산더미처럼 쌓여 있는 가운데 토탈의 니카라과 영어에 대한 1급 기사의 FAS가 무너진 지 겨우 한 달밖에 되지 않았기 때문에, 나는 그렇지 않은 마음을 가지고 있지 않다.내 '승인'을 허디브라스에게 붙이려고 말이야Whereupon 사용자:페미닌(Marjori Morningstar를 위대한 문학이라고 생각하는 사람, 그리고 내가 내 시를 알고 있다는 망상에 시달리는 사람)은 이 "승인"을 보고, 따라서 서둘러 자신의 시를 덧붙인다. 만약 묻는다면, 그는 후디브라를 읽었다고 맹목적으로 맹세할 것이다. 물론 우리 중 누구도 그렇지 않다.어떤 사람이 서명할 필요는 없지만, 예를 들어, 귀하 자신이 특정 기사를 꼼꼼하게 확인하여 인증했다면, 해당 개정판에 대해 "디지털 서명"을 함으로써 이 내용을 진술하고자 할 수 있다.나는 어떤 기사든 꼼꼼하게 확인하는 것은 극히 드문 일이라고 생각한다.그들은 전체적으로 공격하고, 어떤 특정한 부분을 꼼꼼하게 점검할 것이다. 하지만 인용의 정확성 확인을 포함한 전체 기사(도서관 간 대출과 나머지는 포함)는?난 그렇게 생각 안 해.아니, 이건 좀 더 생각해봐야 할 것 같아.내가 읽고 있는 것이 잘못 이해될 수도 있다는 강한 의심이나, 그릇된 이론의 결실, 혹은 평범한 허구일 수도 있다는 것에 분개하고 있기 때문에, 차라리 그것을 실현시킬 수 있는 어떤 방법이 있기를 바란다. --호리 (대화) 2008년 7월 29일 (UTC) 14:30, 2008년 7월 29일 (화)[응답하라.

도서관 상호 대출을 몇 번 하고 몇 가지 사실을 확인해 보았다.절대 안된다고 하지마출처를 검증해 봤더니 사실 어느 순간 '나는 사이클팟인데 이 기사가 좋은 것 같다'(토크페이지)는 식의 템플릿을 활용했다.그럼에도 불구하고, 대부분의 사람들이 단지 몇 가지 사실만을 확인한다는 당신의 생각에 따라 행동합시다.현재 사용자 페이지에서 작업 중인 내 "내 참조" 섹션을 살펴보십시오."Robert Threwlay 참조(예: 여러 페이지에 대한 링크).화려한 버튼까지 추가했다.나는 검증된 인용문 끝에 있는 http://www.aperfectworld.org/clipart/symbols/check.png과 같은 작은 진부한 간판이 고려하는 것이 더 나을 것이라고 생각한다.기사의 사실들은 종종 다양한 출처에서 나오고 종종 나는 WP:CITE에 의한 적절한 참조가 부족하기 때문에 많은 기사에 동의하지 않는다. 형식화의 부족은 위키피디아의 지침과 정책에 따라 문제를 야기할 뿐만 아니라, 어쨌든 나는 기사에 좋은 것으로 투표하는 것이 문제가 될 것이라고 믿는다.따라서 부적절한 형식의 참조를 추가하기 위한 많은 편집자의 안일한 태도를 감안할 때, 이 도구는 "참조", 검증가능성 및 신뢰의 가치를 평가하는 데 구체화되어야 한다고 나는 말한다.그럼에도 불구하고, 어떤 사용자도 대화 페이지에 하위 페이지나 템플릿을 만들어 현재 이것을 하는 것을 막을 수는 없다.그럼 왜 우선 그것부터 시작해서 어떻게 되는지 보는 게 어때?구현 중, 보안을 위한 작업은 약간 극단적으로 보인다...그리고 겉으로 보기에는 '폴' 투표만 만들어 줄 뿐이니, 당신이나 누군가는 제안된 변경안보다 기사의 현상유지가 낫다는 다소 약한 주장을 할 수 있을 것이다.본질적으로, 나는 이것이 위키백과 기사 돼지의 현재 상태를 정당화하고 변화를 무시하기 위한 무기의 한 종류로 이용되고 있다고 본다.B.T.W.는 캐나다에 있는 우리의 현재 정치 체제처럼 느끼게 해줘서 고마워!즉, 정치인들처럼, 우리는 보통 다른 누군가가 우리를 위해 책을 읽고 결정을 내리도록 내버려둔다는 것이다... (시사적으로) 나는 좋게 들린다!아니. 그렇진 않아.네 입으로 직접 말해줘.좋은 생각인 것 같아. --CyclePat (토크) 2008년 7월 29일 (UTC) 19:39, [응답]

내 생각에 우리는 여기서 서로 다른 방식으로 이야기하고 있는 것 같아."신뢰할 수 있는 웹" 설정의 작동 방식에 대해 자세히 설명해 보십시오.무엇보다도, 어떤 물건에 서명하는 요점은 어떤 일에 서명이 필요 없이 서둘러서 서명하는 것이 아니라, 서명자가 실제로 그들의 수표에 상당히 신중하다는 것이다. 결국, 그들은 이 신뢰의 진술에 그들의 약속을 지키고 있다.이것은 다음 단계로 이어진다. 즉, 누군가가 그 규칙을 따르지 않고 그들이 좋아하는 것에 서명한다면?이것은 사용자간 신뢰가 이루어지는 부분이다; "웹" 부분.서명된 개정안의 존재 자체가 의미 있는 것은 아니다; 예를 들어 내가 그것을 분명히 하겠다.

• 이제, 주어진 사람은 명백하다 — User:NonesuchReader는 더 큰 갈림길이 있는 그래브바워빗에 대한 기사를 읽고 있다 — 사용자:논설크리더(Nonesch Reader)는 철학적으로 말하면, 실제로 100% 다른 사람의 동기와 행동에 대해 알 수 없다.대신에, 그녀가 그 의견을 신뢰하는 사람들이 있다.그녀가 User를 신뢰한다고 가정합시다.그녀가 위키프로젝트 그래바워빗에서 정기적으로 교류해온 노네수치 판잔드럼은 신중하고 사려 깊은 접근법으로 유명하다.또한 사용자:노네수치찰리(Nonesschchch Charlie)는 반달파이터에 경험이 많고 인격을 잘 판단한다.
• 그녀는 사용자에 의해 더 큰 갈림길이 있는 그랩바워빗의 서명된 개정판이 있다는 것을 발견한다.논설치 닥터, 그는 누구인가?이것에 대한 그의 의견은 가치가 있는가?User:NoneschuchPanjandrum은 "네, 그 개정판이 체크아웃되었으므로 논쟁을 위해 그리고 아마도 몇 명의 User:Noneschch Doctor의 그랩바워비트 관련 기사 검증은 사용자에게 "서명"하기로 결정한다.논설치 닥터가 그렇게 할 수 있는 능력은 그를 "신뢰의 거미줄"에 추가시켰다; 그는 그의 가치를 증명했다.사용자:Noneschchch Charlie 또한 그를 신뢰하기로 결정하지만, 그의 전문성보다는 그의 성격에 대한 인상을 바탕으로 한다.사용자에게 제공되는 기능 제공:그녀가 그에 대해 의지하기로 결정한 두 가지, 즉 그가 그랩바워빗 기사의 검증에 대해 믿을 만하다는 것과 그가 일반적으로 좋은 성격을 가지고 있다는 것이다.
• 이제, 사용자:NonesuchWanderer는 다음 사용자 중 어느 한 명을 알지 못한다.NoneschuchPanjandrum 또는 사용자:노네수치찰리.따라서, 그녀는 이 거래소에서 어떤 것도 얻지 못한다. 그녀가 이러한 사용자의 성격을 결정할 때까지, 사용자들에 대한 그들의 의견은 다음과 같다.논설치 박사는 그녀에게 그다지 신빙성이 없다.이후 그녀는 사용자를 신뢰하기로 결정했다.논설치 찰리의 성격 판단관은 그가 그들 자신의 생각이 아닌 큰 불꽃 전쟁에 휘말린 많은 편집자들을 변호했다.이에 근거하여, 그녀는 이제 사용자:논설치 박사는 적어도 좋은 성품을 지니고 있다.그러나, 그녀가 사용자의 의견을 형성할 때까지:Noneschch Panjandrum, 그의 그랩바버비토리의 지식과 노력에 관한 기존의 신뢰의 진술은 그녀에게 검증되지 않았다. 따라서 그녀는 더 큰 갈림길에 서명한 그랩바버비트에 대한 그의 수정안에 대해 판단을 유보한다.
• 서명된 개정판의 존재만으로는 의미가 없다는 점에 유의한다.그것은 당신이 그 수정안을 신뢰하는 사람을 결정할 수 있는 출발점이다. 그리고 당신은 당신이 이 문제에 대한 그들의 의견을 신뢰하는지를 결정하기 시작할 수 있다.

그 중 어느 것도 절대적인 것은 아니다. 그것은 조금도 의심의 여지가 없는 것을 증명하지 못한다.그러나 제대로 활용하면, 직접 신뢰하는 사람들의 '1급'을 넘어서 신뢰의 줄을 따라가는 데 유용한 도구가 될 수 있고, 결국 우리에게 더 안 좋은 상황을 남기지 않는다._{tiny plastic} -- 그레이 나이트 ⊖ 15:36, 2008년 7월 29일 (UTC)[응답]

텍스트의 거대한 장벽에 대해 사과한다.:-) 신뢰의 웹 기사에서는 이러한 약정의 일반성에 대해 더 많은 논의를 하고 있으며, 여기서 당신은 과정에 대한 일반적인 질문에 대한 답을 찾을 수 있다.본질적으로, 새로운 것은 아무것도 추가되지 않는다; 사람들은 다른 사람들의 신뢰도를 평가하는 능력을 신뢰하는 것을 포함하여, 여전히 특정한 일에 대해 서로를 신뢰한다.우리는 항상 그것을 한다.그런 시스템이 하는 모든 일은 그 신뢰를 검증 가능한 방식으로 계량화하여, 누가 무엇을 위해 누구를 신뢰하는지 알 수 있고, 그 근거로 그 신뢰도 또한 무엇에 대해 신뢰하는지 결정할 수 있다._{tiny plastic} -- 그레이 나이트 ⊖ 15:42, 2008년 7월 29일 (UTC)[응답]

이 제안과 개념은 편집이 덜 공개될 수 있다는 믿음 때문에 반대하지 않을 수 없다.시간이 지남에 따라, 그러한 시스템의 긴축은 권위자가 서명한 판본의 변경에 대해 상당한 압력을 발생시킬 수 있으며, 따라서 그러한 조항은 정체로 기울게 된다.기사들은 응집력, 스타일, 포괄성 보다는 사실에 입각한 정확성을 위해 주로 서명될 것이기 때문에, 서명하는 것은 단순한 정확성을 넘어 어떤 분야에서든 기사의 전체적인 성장과 개선을 지연시킬 수 있다.일반적으로, 서명 시스템은 우리를 "안정적인 버전"이라는 괴물 같은 것 또는 편집자 계층의 잘못된 창조에 대한 미끄러운 비탈 아래로 조금 더 내려갈 수 있다.미스터 IP 《열린 편집의 정의》 14:37, 2008년 8월 2일 (UTC)[응답]

MediaWiki:프로텍트파게텍스

안녕하십니까? 세미 및 전체 보호된 페이지 메시지(MediaWiki에서 모두):보호 대상 페이지) 비관리자가 보호된 페이지를 편집하려고 할 때 표시되는 섹션과 같은 섹션이 있는지, {{editprotected}} 템플릿을 사용하도록 통보한 다음 관리자를 플래그다운하여 반보호 메시지에 편집을 추가하도록 요청하면 유일한 차이점은 be {{edit protected}}이(가) 아닌 템플릿 {{Editsemiprotected}}을(를) 사용하여 편집하도록 자동 확인된 사용자를 플래그로 지정하도록 하려면 아래에서 사용할 수 있는 텍스트의 예를 작성했다.

일부 반보호 페이지 대화 페이지가 주의 깊게 관찰되지 않아 요청된 편집(템플릿을 사용하지 않고 {{Editesmiprotected})이 기존 사용자에게 인식되기까지 시간이 오래 걸릴 수 있으므로 이 템플릿을 사용하면 페이지가 카테고리에 추가됨:위키피디아의 반보호 편집 요청은 어논과 새로운 사용자를 대신하여 반보호된 페이지를 추적하고 편집하기 훨씬 쉽게 만든다.생각? --mifter (토크) 2008년 7월 30일 (UTC) 20:56 [응답]

Done은 매우 합리적인 생각처럼 보인다.해피멜론 15:21, 2008년 8월 2일 (UTC)[응답]

C68-FM-SV의 비상 조치 제안

설명할 수 없는 중재위원회의 실종으로 인해, 우리는 이제 진짜 중재 위원회가 우리에게 돌아올 수 있는 시간이 될 때까지 긴급 중재 위원회를 구성해야 할 절박한 상황에 직면해 있다.나는 이러한 노력에 앞장설 것이다.대행중재위원회는 좋은 서열을 가진 위키피디아가 배제되지 않고 자원봉사로 임명될 것이다.멤버십 요청은 즉시 받아들여지고, 대행 아르브컴은 8월 7일 취임한다.C68-FM-SV 문제에 대한 결정은 48시간 이내에 내린 후 중재 집행을 통해 추진된다.고마워 :D씨 IP <열린 편집의 정의> 18:48, 2008년 8월 2일 (UTC)[응답]

좋은 생각이지만, 당신만의 중재 위원회를 그냥 시작할 수는 없다 - 그것은 단지 조금 너무 대담하다.이 사건에는 심각한 문제들이 있지만, 이것은 올바른 방법이 아니며, 여러분이 내리는 어떤 결정도 완전히 구속력을 잃게 될 것이다.Ryan Postlethwaite^{See the mess I've created or let's have banter} 18:53, 2008년 8월 2일 (UTC)[응답]

헤헤, 난 그렇게 생각하지 않아.누가 첫 번째 자원봉사를 할까?해피멜론 19:01, 2008년 8월 2일 (UTC)[응답]

이것은 대체로 말문이 막히지만, 실제 ArbCom이 깨어나 뭔가를 하게 하거나, 적어도 그들이 계획하고 있다는 것을 우리에게 알리려는 시도다.그런 이유로, 나는 반드시 실제 자원 봉사자들을 원한다!미스터 IP 《열린 편집의 정의》 19:05, 2008년 8월 2일 (UTC)[응답]

"위키페디안" 모두 손을 들어 "좋다"라고 말하시오.그 ArbCom은 인질을 잡지 않는다.샌디조지아 (토크) 2008년 8월 2일 (UTC) 19:06[응답]

설명할 수 없는 실종은?ArbCom이 사라졌다는 증거를 제시할 수 있는가?Corvus cornix_talk 19:54, 2008년 8월 2일 (UTC)[응답]

C68-FM-SV 사건은 확실히 적극적인 중재자의 존재에 대한 증거가 아니다.쿠스마 (토크) 20:22, 2008년 8월 2일 (UTC)[응답]

게다가 오늘 아침 시리얼을 준비하던 중 우유팩 옆면에 있는 ArbCom을 발견했다.난 희망을 가지고 있어...하지만 최악의 상황도 두려워몸값도 없고, 비행접시 접촉도 없고, 절단된 손가락이나 발가락도 우편물에 도착하지 않은지 꽤 오래되었다.내가 무슨 말을 할 수 있겠니? 난 현실주의자야.그러나 지금 분명히 말씀드리자면, 중재 대행 위원회가 실제 중재 위원회를 찾기 위한 현재 진행 중인 노력을 지연시키거나 축소시킬 것이라는 우려에 대해서는, 두려워하지 마십시오.우리는 수색을 계속하고 있으며 다음 몇 주 동안 단서나 생존자를 찾기 위해 프로젝트 공간을 샅샅이 뒤질 것이다.미스터 IP 《열린 편집의 정의》 20:36, 2008년 8월 2일 (UTC)[응답]

수색에 필요한 인력과 장비를...가능한 한 빨리 중재 위원회를 찾는 것이 우리 모두의 최선책이다.

한여름, 우리는 모든 것에 대해 불평할 사람들이 절실히 필요하다. (특히 무언가가 실제로 그들에게 걱정될 때)2008년 8월 2일(UTC) 21:48의 공작 월섬[응답]

모든 국가에서 모든 위키백과 기사를 액세스할 수 있도록 설정

중국과 같은 일부 국가에서는 인터넷 검열을 믿기 때문에 달라이 라마 등과 같은 특정 위키백과 페이지를 차단한다.어느 나라든 모든 사람은 검열되지 않은 위키백과 페이지에 대한 권리를 가져야 한다.어쩌면 위키피디아는 새로운 기술을 개발하거나 인터넷을 관리하는 조직과 협력해서 모든 위키피디아 페이지가 그들이 좋아하지 않는 위키피디아 페이지를 차단하는 중국 등지에서 접속될 수 있을 것이다.다니엘스펜서2 (대화) 04:28, 2008년 8월 3일 (UTC)[응답하라]

안녕, 다니엘, 그리고 그 프로젝트에 온 것을 환영해.내가 그 주제에 대해 잘 모르지만, 위키피디아와 같은 자원이 부족한 프로젝트가 PRC와 같은 거대한 정부와 소프트웨어 "무기전쟁"에 돌입하는 것은 매우 어려울 것이며, 그 세부사항에 대한 친밀한 지식 없이는 그들의 검열 소프트웨어를 중심으로 설계하는 것이 사실상 불가능할 것이라는 것이 나의 이해다.미래는 아마도 우리가 할 수 있는 그 어떤 것보다도 최종 사용자들의 런어라운드에 달려 있을 것이다.미스터 IP 《열린 편집의 정의》 06:51, 2008년 8월 3일 (UTC)[응답]

위키백과에 기부하는 더 많은 방법

내가 아는 몇몇 사람들은 신용카드는 없지만 위키피디아에 기부하기를 원한다.그들 중 많은 사람들은 왜 위키피디아가 휴대폰으로 벨소리 등을 구매할 수 있기 때문에 사람들이 휴대폰으로 기부할 수 있는 선택권이 없는지, 그래서 위키피디아는 사용자들이 그들의 기부금을 문자 메시지로 보낼 수 있는 문자 기부 옵션을 쉽게 설정할 수 있어야 한다고 질문했다.

나는 또한 그들만의 웹사이트를 가지고 있고 구글 광고를 사용하는 사람들을 알고 있다. 그리고 그들은 그들이 그들의 구글 광고 수입에서 직접 위키피디아에 기금을 기부하는 것이 쉬울 것이라고 말한다.위키피디아는 구글과 협력해야 하며, 구글 광고 사용자들이 자신의 계정에 로그인하여 금액(최소 또는 최대 기부 한도 없음)을 입력하는 옵션을 가지고 있어야 하며, 이는 위키피디아에 전달될 것이다.다니엘스펜서2 (대화) 04:42, 2008년 8월 3일 (UTC)[응답]

위키피디아에 "그들의 기부문자"를 보낼 방법이 없다.전화기를 통해 벨소리를 구입하려면 선불 전화기를 사용하고 있는 A)나 계약 전화(이 경우 계좌의 자금에서 자금이 공제되는 경우)를 사용하고 있는 B) 중 하나를 사용해야 한다(이 경우 기금이 청구서에 추가됨).어느 경우든 휴대폰 통신사를 통해 구매한 것으로 취급된다.위키피디아가 이런 서비스를 통해 돈을 받기 위해서는 휴대전화를 통해 접속되는 서비스의 제공자가 되기 위해서는 많은 법적 후크를 거쳐야 할 것이다.그런 식으로 기부금을 받는 것은 그만한 가치가 없다.

만약 사람들이 신용카드를 사용하지 않고 돈을 지불하고 싶다면, 나는 당좌예금 계좌로 페이팔(PayPal)을 이용하든지 아니면 선불 신용카드를 사서 기부금을 내는 데 이용하든지 권하고 싶다.— 당신을 먹여 살리는 손:^Bite 2008년 8월 3일 (UTC) 14:37[응답]

그냥 우체국에 가서 우편환과 우편요금을 사.그것은 단순히 레거시 기술을 활용하는 것에 대한 문제일 뿐이다.칠음 14:42, 2008년 8월 3일 (UTC)[응답]

메인 페이지는 기사인가?

메인 페이지의 왼쪽 상단 모서리에 해당 페이지가 기사로 표시된 탭이 있는데, 분명히 그렇지 않다.독일어 위키백과에서는 위키프로젝트측의 일부로, 스페인어에서는 표지로, 프랑스어에서는 리셉션으로, 이탈리아어에서는 감각적으로 메인페이지라고 부르고, 네덜란드어에서는 헤드페이지로, 일본어에서는 넥페이지(아마도 잘못 번역했을 것이고), 러시아어에서는 제목(제목의 짧은 버전)으로 표기하고 있다.야후는 폴란드어를 번역하지 않는다.모든 주요 위키피디아(포르투갈어 제외, 그들은 같은 실수를 한다)는 메인 페이지에 그것이 무엇인지 라벨을 붙인다.왜 우리는 똑같이 할 수 없을까?

미디어위키에서 논의된 바 있다.Nstab-main, 그리고 나는 왜 우리가 이 사소한 변경을 할 수 없는지 이해할 수 없다, 다른 위키피디아들이 문제없이 그렇게 해왔기 때문이다.불안첼로 (대화) 2008년 8월 3일 15:35 (UTC)[응답]

위키백과:빌리지_펌프_(기술)#제안:_Move_main_page_to_a_different_namespaceJuliancolton^{TropicalCyclone} 15:39, 2008년 8월 3일(UTC)[응답]

보아하니 서버 부하가 너무 많은 것 같군. --orcament알렉스: 2008년 8월 3일 19시 15분 (UTC)[응답하라]

새로운 제안:위키백과:가상 참조 자료

위키피디아에 위키리크스를 추가하는 걸 봤는데오늘날 다양한 기존 가이드라인의 허구적 언급.기존 가이드라인에 대해 "보기"가 될 정도로 유용하다면, 커뮤니티의 의견을 들을 준비가 되어 있어야 하지만, 관련자 모두가 어디에서나 언급하는 것을 소홀히 한 것으로 보인다.위키백과 토크에서 의견을 제시하십시오.허구적인 언급.아노미에 03:02, 2008년 8월 4일 (UTC)[응답]

WP nulify 또는 reverse WP 제안:N

내가 백과사전을 사용하는 이유는 간단하지만 깊이 있는 주제를 보기 위함이다.대부분의 경우 백과사전이 필요한 바로 그 이유는 주목할 수도 있고 그렇지 않을 수도 있는 주제에 대한 출처와 확장을 찾기 위함이다.그러나 현재의 생각은 백과사전은 적어도 한 사람이 편집하기에 충분할 정도로 주목할 만한 주제를 간단히 다루기보다는 주목할 만한 주제만을 다루어야 한다는 것이다.어떤 주제가 존재하는지 알아보기 위해 구글에 먼저 보내고, 위키피디아나 다른 온라인 출처를 통해 완전한 요약을 얻고, 온라인 요약 내의 링크와 인용구를 통해 출처와 확장된 작품 옆에 나를 보내는 것이 바로 이러한 근본적인 개념의 차이점이다.즉, 구글이 무언가를 검색하기 위해, 위키피디아는 완전한 요약을 찾고(만약 공신력 문제가 번복되거나 무효화되었다면), 더 심층적인 탐구를 위해 책과 다른 출처를 찾아낸다.그래야 독자나 연구자로서 필요한 모든 것을 얻는다.내가 연구하고 있는 주제에 전혀 관심이 없는 사용자들이 어떤 주제가 주목할 만한 것이 아니라고 생각한다면 현재의 방법은 위키피디아로부터 아무것도 얻지 못한다.줄리 댄서 (토크) 03:49, 2008년 7월 30일 (UTC)[응답]

나는 단순히 공신력 가이드라인을 무시하려는 어떤 제안도 그리 멀리 가지 않을 것이라고 생각한다.그러나 나는 당신이 WT:N을 보고 그것들에 대한 잠재적인 변화에 대해 현재 진행중인 논의를 볼 것을 제안한다.2008년 7월 30일 셰어 03:55 (UTC)[응답]

셰레스, 네가 나보다 먼저 이 일을 해줘서 정말 기뻐.너는 정말 친절하구나.S. Dean Jameson 04:21, 2008년 7월 30일 (UTC)[응답]

• 공식적으로, "공지력"은 "관심"에 관한 것이 아니다.예를 들어, 나는 바구니 짜는 것에 전혀 관심이 없지만, 그 고리는 여전히 파란색이다.눈에 띄는 것이 반드시 흥미롭다는 것과 같은 것은 아니다.흥미롭다는 것이 반드시 주목받는 것과 같은 것도 아니다.S. Dean Jameson 04:26, 2008년 7월 30일 (UTC)[응답]

나도 동의하지만, 삭제 토론에 참여하는 다른 사용자들은 자신이 흥미롭다고 느끼는 것에 전적으로 근거하여 DELETE 또는 KEEP에 대한 지지를 나타낼 수 있고, 토론에 게시된 DELETE의 대다수가 해당 기사를 얼마나 흥미롭게 느끼는지 때문에 기사를 삭제할 수도 있다.폭도들의 통치를 막을 방법을 찾으면 나는 전적으로 동의할 것이다.줄리 댄서 (대화) 05:56, 2008년 7월 30일 (UTC)[응답]

너는 실제로 많은 AfDs에 참여했니?당신이 묘사하는 시나리오에서는 ("삭제, 들어본 적이 없다"라고 논평하는 사람들) 그 기사는 보관될 것이다.어떤 불명확한 주제를 삭제한 것에 대한 당신의 입장이 이것을 촉발시켰다는 것이 명백해지고 있다.IDON'처럼.TLICKIT은 삭제에 대한 좋은 주장이 아니기 때문에 IREALLIVELYLICKIT은 포함에 대한 좋은 주장이 아니다.S. Dean Jameson 13:03, 2008년 7월 30일 (UTC)[응답]

그러나 그러한 논의를 검토하는 행정부는 정책이나 지침을 사용하여 이를 뒷받침하는 의견을 그 이상으로 본다.그래서 "삭제.나는 그것에 대해 들어본 적이 없다."라고 말하는 것은 "계속하라"로 더 중요할 것이다.이런 믿을 만한 출처는 공신력을 보여 준다."관리자들은 단순한 투표 카운터 그 이상이며 심지어 나와 같은 중국 공산당의 카발리스트로 의심되기도 한다.(줄리가 이메일에서 내가 한 명인지 물어봤어)케빈 (토크) 06:04, 2008년 7월 30일 (UTC)[응답]

당신의 정치적 제휴나 충성의 문제는 실제 세계에서 여기 있는 것처럼 가볍게 여기지 않을 수도 있기 때문에 위키백과 자체의 본체 내에서가 아니라 대외적으로 제기되었다.실제 세상이 몰래 들어오는 것을 막기 위해 여기서 이메일 주소를 삭제하는 것과 같은 이유다.그렇긴 하지만, 당신은 실제로 1차적인 참고문헌을 읽지 않고 그 참고문헌이 포함된 참고문헌을 찾아보지 않았거나, 매일 그 방법이 광범위하게 사용되는 러블레이스 센터를 방문했거나, 러블레이스 센터에 과학자들이 와서 그 방법을 개발하는 데 도움을 준 러시아 연구소를 방문했다.당신은 Rypka 박사의 저작물 출판자나 그 방법의 다른 사용자들과 어떻게 1971년에 개발된 방법인 그 방법이 오늘날에도 주요한 응용 프로그램을 가지고 있는지 알아보지 못했다.이제 문제는 위키피디아의 관리자들이 미래의 연구자들이 위키피디아를 인식하지 못하게 하는 그들 자신의 의견을 포함하여 어느 한 쪽의 위키피디아 사용자 의견에 기초하여 그러한 방법을 눈에 띄지 않게 생각한다면 누가 위키피디아를 신뢰할 수 있는가 하는 것이다.창피 한줄 아세요이런 방법이 다른 곳에서 출판될 수 있어서 다행이다.줄리 댄서 (토크) 06:21, 2008년 7월 30일 (UTC)[응답]

나는 이 제안이 실행될 것이라는 것을 믿을 수 없지만, 여전히 답변을 하고 싶다.내가 이해한 바와 같이(그리고 이것이 반드시 공식적이거나 그런 것은 아니다), 우리의 포함 기준인 "공지력"은 기본적으로 (i) 위키백과가 백과사전 (ii) 검증가능성 또는 귀속가능성(Wipedia:정의용 ATT).(i)는 창조의 원칙이며, 아마도 변화의 대상이 아닐 것이다.만약 (나) 바뀌려면 우선 우리의 슬로건이 바뀌어야 한다.위키백과, 무료 백과사전.하지만 우리가 크리에이티브 커먼즈 면허를 채택하는 것에 대해 생각하고 있기 때문에, 이것은 불가능하지 않을 수도 있다; 만약 충분한 위키피디아 사람들이 위키피디아가 백과사전 이상의 무언가가 되어야 한다고 생각한다면, 이것은 일어날 수 있다.그래서 (나) 상당히 강한 주장은 아닌 것 같다.이미 많은 사람들이 했듯이 포크를 시작할 수 있다는 것을 안다. (Knol은 이 노선을 따라 접근하는 것의 예로 볼 수 있다.)그러나 그것은 요점을 놓치고 있는 것이다.대부분의 많은 사람들이 '위키피디아'(다른 것은 아닌)가 백과사전을 넘어서는, 디지털 시대에 걸맞는 무언가가 되기를 원하고 있으며, 개화시대에 발명된 구시대적 관념에 제한을 받지 않는다. (개헌을 제안하는 절차가 무엇인지 궁금하다.이 페이지는 확실히 그런 것은 아니다.)

다음 단계로 넘어가자. (ii)는 아마도 더 심한 구속으로, 주의를 요한다.내가 보기에 이것이 바로 Citizendium이 "유지가능성"이라고 부르는 것이다 [2].나는 당신의 경험에 대해 잘 모르지만, 언급할 수 없는 주제에 대한 기사를 유지하는 것은 매우 어렵다. 왜냐하면 정의에 따르면, 어떤 주제가 농담이나 잡동사니가 아닌 기사를 쓰는데 신뢰성을 사용할 수 있는 출처를 가지고 있는 경우에만 주목할 수 있기 때문이다.지방신문이나 작은 무명 학술지에는 비감각이 가득 담겨 있어 안정적으로 사용할 수 없다.위키피디아 선량은 상당한 양의 농담도 포함하고 있기 때문에, 그것 역시 믿을 수 없다.(ii)를 안심시키려면, 다시 말해서, 우리는 일종의 품질 보증 메커니즘이 필요하다.아마도 위키백과:우리는 전문가의 아이디어나 실명확인 등을 거의 거부하기 때문에 국기로 수정한 것이 정답이다.'알림' 기준이 없을 때 위키백과에 기여하기 시작했기 때문에, 앞으로 위키백과에서 '알림' 기준을 떨어뜨려도 놀라지 않을 것이다. -- 다쿠 (토크) 04:35, 2008년 7월 30일 (UTC)[응답]

그렇다면, 이전 편집자들이 언급했던 훌륭한 제안들(예: 진행중인 토론의 가능한 변화들을 지적하는 것)과는 별도로, 당신은 WP:N을 바꿔야 한다고 생각하는가? 왜냐하면 그것이 현재 당신의 이상 "검색용 구글, 요약용 위키백과, 심층용 책"을 방해하기 때문이다.나는 그러한 결정을 내리는 기관들이 "이것이 내가 원하는 것이기 때문에"보다 더 설득력 있는 증거를 필요로 할 것이라고 생각한다.- Twas Now (토크 • 기여 • 이메일 ) 05:44, 2008년 7월 30일 (UTC)[응답]

비록 내 의견이 온라인상의 경험에 한정되어 있지만, 내 의견은 오직 나 자신만을 대변할 수 있다. 예전 전화 접속 메시지 게시판으로 돌아가는...1978년쯤이었는지 봅시다.줄리 댄서 (토크) 06:01, 2008년 7월 30일 (UTC)[응답]

흥미롭군, 예전에는 백과사전 프로젝트를 전혀 몰랐어.어떤 이름이라도 기억나니?출처를 좀 찾아보면 이 일에서 몇 가지 깔끔한 기사가 나올지도 모른다._{tiny plastic} -- 그레이 나이트 ⊖ 16:31, 2008년 7월 30일 (UTC)[응답]

줄리의 글은 위키피디아에서 최적의 분류:삭제/최적분류를 위한 조항.나는 그들이 그들의 동기에 대해 개방적이고 정직하다면 긍정적인 토론을 하는 데 더 효과적일 것이라고 믿는다.Dcoetzee 22:24, 2008년 7월 30일 (UTC)[응답]

기타 공증 요건이 없는 Wiki 호스트가 있는데, 그 호스트에 사용을 제안해도 될까? -93.96.212.203 (토크) 15:07, 2008년 8월 4일 (UTC)[응답]

WP 변경 제안:정책 방향

WP:A는 지난 몇 달 동안 일부 논쟁의 대상이 되어 왔으며, 5월에 삭제 제안으로 정점을 찍었다.이 제안의 결과는 합의에 이르지 못했다. 의도된 대리인이었던 것이다.{{Update after}}일반적으로 "현재"를 대체하기에 충분하지 않다고 여겨졌다.그러나 [...의 경우] 링크는 좀 덜 난해한 것으로 대체해야 한다는 일부 동의가 있었다(원안 참조).이로 인해 새로운 프로젝트 페이지에 대한 제안서를 작성하게 되었다(Wikipedia talk:##신규 프로젝트 페이지 제안).나는 이미 페이지를 실행했지만, 다른 사용자의 제안에 따라 토론과 필요하다면 번복을 위해 변경사항을 게시했다.

제안된 정책은 크게 수정된 정책을 실행한다.{{As of}}CAT의 (숨겨진) 하위 범주로 문장을 분류하는 템플릿:[...의 경우] 페이지에 연결하지 않고 ASOF.디폴트 「as...」의 본문도, 「정확한 언어의 사용을 장려하고 있다」라고 하는 것이, 본문에서는, 「정확한 언어의 사용을 장려하고 있다」라고 하고 있어,{{Update after}} 템플릿.카테고리는 유지관리가 낮고 왓링크스여기/[...의 경우] 페이지보다 찾아보기 쉽고 접근이 용이하며, 가장 도움이 되는 것은 템플릿이 문장 자체에 가시적인 위키링크를 생성하지 않기 때문인데, 이것이 원래 삭제 제안의 이유였다.참고용으로 이전 프로젝트 페이지를 참조하십시오.고마워 – Ikara^{talk →} 16:00, 2008년 7월 31일 (UTC)[응답]

[[...의 경우] 링크 대신 {{As}을(를) 사용하는 정책을 지지하며, 정책의 As를 들어보지 못한 편집자들이 선의로 삭제 또는 변경되는 경우가 많다.

유지 보수 작업의 중복을 줄이기 위해, 현행 성명서의 상태가 변경될 경우 업데이트될 것으로 보이는 URL(예: 기업의 공식 사이트에 있는 관련 페이지)에 선택적 URL 매개 변수를 추가하거나, 현재 업데이트된 결과를 유지하고 계속 업데이트될 수 있는 페이지를 추가할 것을 제안한다.아마도 기본 설정에서 (기본적으로) 현재 문장의 URL에 대한 링크를 표시하는 옵션이 있을 수 있다.그런 링크가 전혀 나타나지 않았더라도 출처를 보는 편집자들은 URL을 복사할 수 있었다.

그리고 다음과 같은 사소한 제안이 있다.내버려두다{{As of}}parameter lc가 있을 때마다 lc=on을 입력하지 않고 "as"로 인쇄한다.프라임헌터 (토크) 2008년 7월 31일 (UTC) 16:52 [응답]

응원해줘서 고마워.lc 매개변수가 공백이 아닌 정의된 경우 실제로 낮은 대소문자를 제공한다(단순히 사용할 수 없음).{{As of ... lc}}하는 것처럼{{As of ... #=lc}}여기서 #는 매개 변수 이름이며 다른 정의된 매개 변수에 따라 달라진다).예를 들면,{{As of ... lc=1}}심지어 코드를 약간 수정하면{{As of ... lc=}} , 그러나 wikitxt를 더 읽기 쉽게 만들기 때문에 lc=on을 사용하자고 제안했다.df=이긴 하지만 df 파라미터도 실제로 마찬가지다.미국은 필요한 경우 나중에 새로운 날짜 형식을 추가할 수 있다.나는 이것을 명확하게 하기 위해 템플릿 문서를 수정할 것이다.url 매개 변수에 대해서는, 이것이 비기능적 매개 변수여야 한다고 생각하는 것이 맞는가?그렇다면 url=[]를 간단히 사용하라.템플릿의 URL]이면 충분하다.템플릿의 끝에 나타나는 다음과 같은 인라인 플래그를 만들 수 있지만 기본적으로 숨겨야 하며 Monobook.css 파일을 올바르게 수정하는 사용자만 볼 수 있다.CSS가 활성화되지 않은 사용자들은 기본적으로 깃발을 볼 것이기 때문에 나 또한 이것을 하는 것을 경계한다.이러한 문장은 일반적으로 참조되어야 하며, 이러한 URL을 사용할 수 있는 경우 참조로 사용해야 한다는 점에 유의하십시오.지금은 비기능적 용량에서만 url 매개 변수를 사용하는 것을 제안하도록 설명서를 수정하겠다(아마 전방 호환이 될 것이다).모든 베스트 – Ikara^{talk →} 00:42, 2008년 8월 1일 (UTC)[응답]

CSS 지원 없이 위키피디아를 보는 사람은 인터넷에서 가장 싱겁고 혼란스러운 사이트 중 하나를 보게 될 것이다.CSS가 없으면 인터페이스(측면봉 등)가 제대로 표시되지 않고, 실제 내용은 신경 쓰지 마십시오.앰박스 및 토크 스페이스 메시지는 많은 내비게이션 박스, 참조, 조정 템플릿 등과 마찬가지로 모두 일반 텍스트로 표시된다.위키피디아는 감각적인 검색 경험을 위해 CSS 지원을 가정하기 때문에 위에서 제안하는 아이디어는 유용하고 유용한 아이디어다.나는 이 제안이 아주 좋은 생각이라고 생각한다.해피멜론 14:04, 2008년 8월 2일 (UTC)[응답]

그럴 경우 이 제안이 받아들여진다고 가정해 국기를 추가하는 것을 검토하겠다(현재 반응을 보면 그렇게 될 것으로 예상한다).이제 설명서는 미래의 편집자를 지원하기 위해 url 매개변수의 사용을 권장한다.고마워 – Ikara 21:54, 2008년 8월 2일 (UTC)[응답]

나 또한 이 변화를 강력히 지지한다."현재"는 실제로 매우 유용하지만, 오랫동안 개혁이 필요했다.나는 이 눈에 띄지 않는 새로운 시스템의 모든 것을 좋아한다.한 가지 작은 점: 현재 템플릿은 Y/M/D가 모두 제공될 때 링크된 날짜를 렌더링한다는 것, 맞지?최종 제품도 그렇게 될까?나는 결과에서 날짜연동을 완전히 제거할 것이다.많은 사용자들이 그들의 현재 태그에 3자 날짜를 제공할지 의심스럽지만, 날짜 연동이 점차적으로 진행되고 있기 때문에, 이 일에서 완전히 배제하는 것이 좋을지도 모른다.어쨌든, 잘했어.미스터 IP 《열린 편집의 정의》 13:47, 2008년 8월 2일 (UTC)[응답]

실례지만, 이건 주제에서 벗어난 이야기지만, 데이트 연계가 끝나가는 중인가?데이트 링크가 접근성의 일부인 줄 알았는데?내가 내 정의와 헷갈리는가?프라나맥스 (대화) 2008년 8월 2일 (UTC) 14시 7분 (답변)

날짜 연결 및/또는 날짜 자동 형식 지정 환경설정을 완전히 싫어하는 편집자 그룹이 있다.그들은 간신히 WP를 손에 넣었다.MOSDATE는 데이트 링크 추천에서 어느 쪽이든 추천하지 않는 것으로 변경되었으며, 인용 템플릿의 날짜에 대한 Template talk:cite 웹에 대한 활동이 있었다.이 집단이 (조직화되지 않은?) 야당이나 관심 없는 집단에 비해 얼마나 큰지 모르겠다.IMO, 데이트 연계는 "떠나는 길" 밖에 없다. 다른 사람들이 그것 때문에 싸우는 것에 질려버리기 때문에 소모되는 것이다.아노미에 17:22, 2008년 8월 2일 (UTC)[응답]

사실이야."나가고 있는 중"은 "죽일 작정이다"라고 말하는 내 방식이었다.D 진지하게, 더 이상 그 관행이 권장되지 않기 때문에, 템플릿 등을 다시 만들 때 생략하는 것을 보고 싶다.나는 이전의 표현들이 가식적이었다는 것을 인정한다.미스터 IP <열린 편집의 정의> 17:49, 2008년 8월 2일 (UTC)[응답]

현재 템플릿은{{Start date}} 날짜를 자동으로 포맷하고 Wikilink를 추가하는 날짜를 표시하는 템플릿.alt 매개변수를 사용하여 링크 없이 수동으로 날짜를 추가하는 것 외에 링크를 추가하거나 현재 날짜가 연결되었는지 여부를 제어하지 않는다.– 이카라^{talk →} 21:54, 2008년 8월 2일 (UTC)[응답]

나는 이것을 강력한 제안 이상의 것으로 만드는 것에 반대한다.이것은 가장 좋은 정책이다.우리가 사람들에게 이것을 하도록 요구할 수 있는 실현 가능한 방법은 없으며, 이것을 하지 않는 것에 대한 제재는 완전히 어리석은 일일 것이다.이것이 표준 관행이 되고 더 널리 알려지면 WP:MoS형 가이드라인이 될 수 있지만 이것은 정책이 되기에는 너무 사소한 것이다.미스터 지맨 2008년 8월 2일 (UTC) 14:10 (응답)

여기서 "정책"을 사용하는 것은 단지 엉성한 표현으로 보인다.나는 아무도 이것이 공식적인 정책이 될 것을 제안하지 않는다고 생각하지 않는다 - 내가 내 응답자의 원래 글에서 그 단어를 베꼈지만 나는 그렇지 않다.프라임헌터 (토크) 2008년 8월 2일 (UTC) 14시 20분[응답]

동의해. 이것은 백과사전을 최신 상태로 유지하기 위한 유용한 도구의 개선만큼 정책이 아니야.미스터 IP 《열린 편집의 정의》 17:50, 2008년 8월 2일 (UTC)[응답]

미안, 그건 내 엉성한 표현이었어."현재"는 공식적인 정책이 아니며 결코 공식적인 정책이 아니었다.내 말은 위키백과 자체가 아니라 프로젝트 페이지의 정책(가이드라인)을 바꾸자는 것이었다.그것을 MoS형 가이드라인으로 포함시키는 것은 도움이 될 것이지만, 아직 멀었다.도움이 되었으면 좋겠다 – Ikara 21:54, 2008년 8월 2일 (UTC)[응답]

업데이트: 인라인 참조 지원을 추가했으며 이를 반영하기 위해 템플릿 문서와 WP:As를 업데이트했다.설명서에서 monobook.css 페이지에 코드 줄을 추가하는 데 필요한 문서에서 사용할 수 있는 정적 예를 볼 수 있다.변경 사항을 검토하여 수정할 사항이 있으면 언제든지 말해줘.고마워 – Ikara 02:40, 2008년 8월 5일 (UTC)[응답]

섹션의 감시 목록

이것은 약간 야심적일 수도 있지만, 나는 기사의 미립자 부분을 관찰할 수 있도록 부탁하고 싶다.내가 이것을 요청하는 유일한 이유는 여기 다양한 마을 펌프스에서와 같이 많은 양의 대화 페이지를 보기 위해서라는 것을 인정한다.샤크D (대화) 01:26, 2008년 8월 1일 (UTC)[응답]

위키백과:여러 해 동안 제안했고 이것이 목록에 없다는 것에 약간 놀랐다.문제들 중 하나는 위키피디아가 페이지 기반이라는 것이다. (저장, 데이터 추적 등의 측면에서) 섹션은 매우 수정 가능하고 일시적인 것이다.예를 들어, WP에 따라 "참고사항" 섹션 위에 있는 기사에서 "참고사항" 섹션을 이동했다.GTL: 사람이 이해하기 쉽지만, 컴퓨터 소프트웨어에 대해서는 잠재적으로 악몽을 꿀 수 있다. 만약 어떤 식으로든 감시목적을 위해 섹션을 추적하려고 한다면 말이다.그리고 훨씬 더 일시적인 하위 섹션은 어떨까? (AfD 토론 목록과 같은 페이지는 주로 개별 토론의 전가여서 편집자들이 개별 토론에 따를 수 있다.) -- 존 브레본(UTC) 01:54, 2008년 8월 1일 (UTC)[응답]

그래, 모두가 이것을 원해, 아무도 반대하지 않아.이제, 우리에게 필요한 것은 우리가 그렇게 하기 위해 실행한 오픈 소프트웨어를 개선할 수 있는 프로그램 기술을 가진 사람뿐입니다.존의 말에도 불구하고, 나는 프로그램을 짜는 것이 그렇게 복잡할 것이라고 생각하지 않는다.칠음 01:56, 2008년 8월 1일 (UTC)[응답]

답장 고마워.어쨌든 그럴 가능성은 없다고 생각했다.샤크D (대화) 02:08, 2008년 8월 1일 (UTC)[응답]

존이 언급하는 어려움을 고려할 때, 더 실용적인 (또한 꽤 혁명적인) 방법은 마을 펌프나 다른 특정한 다른 것들과 같은 다국적인 토론 페이지를 제거하는 것이다. (요청된 움직임도 이와 유사한 문제를 야기하는가?지금은 기억할 수 없다) AfD와 마찬가지로 중앙 위치에서 연결만 가능한 전용 토론 페이지로, 06:33, 2008년 8월 1일(UTC)[응답]

그건 좋은 생각이야.그것은 또한 토론에 연결되고 그것을 참고 자료로 유지하기를 원하면 링크는 결코 죽지 않는다는 것을 의미할 것이다.샤크D (토크) 07:05, 2008년 8월 1일 (UTC)[응답]

나는 이것을 강력히 지지할 것이다.하위 페이지는 현재 페이지와 동일한 모양을 제공하도록 변환될 수 있다.기본 페이지를 보면 하위 페이지가 추가 또는 제거되는 시점에 대한 알림이 제공된다.Phyomonas_(talk) 11:30, 2008년 8월 1일 (UTC)[응답]

Ditto. 그러나 내가 생각할 수 있는 두 가지 복잡한 문제: "새로운 섹션 편집"은 좀 더 복잡해질 것이다. 그리고, 다양한 보관 봇들이 활동을 위해 여러 페이지를 감시한 다음, "부모"(사실, 그 하나가 그렇게 딱딱하게 들리지 않는 것)를 수정해야 하지 않겠는가? Saintrain (대화) 22:31, 2008년 8월 1일 (UTC)[응답]

이 논의를 WP로 옮기기 위해 고려해야 할 사항이 있다.VPT, 그것은 꽤 기술적인 제안이다.2008년 8월 1일 셰어 22시 59분 (UTC)[응답]

음, 만약 이것이 매우 복잡하고 앞으로 오랜 시간이 걸릴 것이라고 가정한다면, 최소한 모든 XfD 논의를 AfD 형식으로 바꾸는 것이 좋을 것 같다. 갑자기 비고문자가 삭제되고 최종 관리자가 d에 관련 링크를 남길 필요가 없다고 결정했을 때, 기록 보관소를 통과해야 하는 것은 매우 좌절스럽다.해결 방법에 대한 전기 요약:

• 기본 설정으로 이동
• 감시 목록 클릭
• '해당되는 모든 변경 사항을 표시하도록 감시 목록 확장' 확인란

이것은 완벽한 해결책은 아니지만, 적어도 이 방법으로 페이지의 특정 섹션이 수정되었는지 여부를 알 수 있다. - -ααεεεααααα 03 03 03:45, 2008년 8월 2일 (UTC)[reply]

부분적인 해결은 어렵지 않겠지만, 이것은 구역 명칭의 변경과 보관에 직면했을 때 매우 취약할 것이다.우리는 장기적으로 보다 강력한 솔루션 완전한 포럼 솔루션이 필요하다.Dcoetzee 06:56, 2008년 8월 2일 (UTC)[응답]

조금 전에 다른 XfD 프로세스를 AfD와 같이 전환하자는 제안이 있었는데, 많은 지원을 받았으나 실행된 적이 없는 것 같다.보다 강력한 포럼 솔루션에 대해서는 mw와 같은 것.확장:리퀴드스레드?개발은 좀 느리지만 결국 위키미디어 프로젝트에 쓰이겠다는 게 목표라고 생각한다.그러나 그것은 여전히 토론 페이지에서만 작동될 수 있다. 그것은 나사형 토론에 사용되지 않는 섹션에서는 작동하지 않을 것이다.Mr.Z-man 13:40, 2008년 8월 2일 (UTC)[응답]

그 토론이 어디에 있었는지 아십니까?비교적 최근에 사람들을 지목할 만한 논의가 있었던 이상, 그것을 실행하는 것에 대해서는 과감히 마다하지 않을 것이다. -ζαππε 14 14 14 14 14 14:26, 2008년 8월 4일 (UTC)[응답]

위키백과:빌리지 펌프(제안)/아카이브 29#트랜스러디블 XfD 토론. -- 존 브레턴 (리콜라) 17:59, 2008년 8월 4일 (UTC)[응답]

정적 위키백과

최근 한 사용자는 위키백과 기사에 대한 사용자의 신뢰를 확보하기 위해, 자신의 주장대로, 자신의 잘못된 삭제를 거짓으로 변호했다. (삭제 이유인 BTW는 저자에 대한 원한이었다.)

그러나 이 주장의 문제는 위키백과 기사들이 지속적으로 열린 편집 소스로서 공공 기물 파손은 어떤 기사가 다운로드되기 전에 일어날 수도 있고 기사가 다운로드된 직후에 수정이나 업데이트가 일어날 수도 있기 때문에 본질적으로 신뢰할 수 없다는 것이다.

이를 시정(이론적으로)하고 문제를 드러내기 위해, 관리자가 선택한 시간 간격 동안 관찰하고 삭제하는 변경사항만 가지고 하루, 주 또는 월 1회 생성되는 정적 위키백과의 창설을 제안한다. --igy 10:14, 2008년 8월 2일(UTC)

나는 너의 제안을 이해할 수 없다.좀 더 자세히 설명해 주시겠습니까?— 건배, 잭리 12:28, 2008년 8월 2일 (UTC)[응답]

그것은 본질적으로 세부사항과 관계없이 진정으로 열린 편집을 영원히 끝내자는 제안이다.나는 그들의 의도가 어떻든 간에 그러한 모든 모험에 강력히 반대한다.미스터 IP 《열린 편집의 정의》 13:13, 2008년 8월 2일 (UTC)[응답]

종료하는 것이 아니라 정적 버전이 이전 시간 간격에 대해 검토되고 승인된 변경사항을 포함하는 방식으로 보충한다.사용자는 동적 버전을 계속 편집하지만, 시간 간격이 끝날 때 검토되고 승인된 변경사항만 더 이상 편집할 수 없고 정적인 버전에 포함된다.이 기능을 제공할 수 있는 현재 아카이브된 버전도 현재 열려 있는 편집이다.(...물론 나는 심각하지는 않지만, 이 아이디어는 단지 스푸핑일 뿐이다.) --igy 13:37, 2008년 8월 2일 (UTC)

위키백과 확인:플래그 지정된 수정사항.- Twas Now (토크 • 기여 • 이메일 ) 2008년 8월 2일 (UTC) 15:42, 응답 [응답]

그리고 베로피디아. -- 존 브로튼 (식용차) 17:53, 2008년 8월 4일 (UTC)[응답하라]

위키백과의 WikiTimeLine 확장 활성화에 대한 토론

이것은 "지구", "트릴로바이트" 및 "T-Rex" 이벤트가 추가된 WikiTimeLine 인터페이스 입니다.맨 위는 모든 이벤트가 있는 메인이고 맨 아래는 개요 영역( 훨씬 더 큰 스케일이 있는)이다.마우스 커서의 도움을 받아 시간 표시 막대를 이동하여 확대/축소하고 이벤트를 제거하며 이벤트에 대한 자세한 정보를 얻으려면 이벤트를 클릭하십시오(기사 페이지까지 이동).

위키피디아에서 위키타임라인 확장을 활성화하는 것이 좋을 것 같아.그것은 일종의 대화식이고 실시간 버전의 쉬운 시간 표시 입니다.대신 글의 독자에 의해 통제된다.글에 태그를 추가하면 독자가 해당 링크를 클릭하면 이벤트가 시간 표시 막대에 추가된다.원하는 이벤트를 추가하고(따라서 개별 시간 표시줄을 만들고), 확대/축소하고 이동할 수 있다.라이브 예제와 자세한 내용은 여기에서 확인(상단의 링크 몇 개 클릭) 및 해당 MediaWiki 페이지를 참조하십시오.그것은 위키타임스케일과 시밀레 타임라인의 혼합물이다.인터페이스는 자바스크립트에 있어서 거의 모든 것이 클라이언트측에서 실행되기 때문에 서버에 많은 부하가 걸리지 않는다.그러므로 그것은 무거운 트래픽 위키(위키미디어 파운데이션 위키와 같은)에서도 사용될 수 있다.bugzilla에 있는 사람들은 우리가 먼저 여기에 관심을 가져야 할 필요가 있고, 그 후에 위키백과 관리자들이 bugzilla/mediawiki 개발자들에게 가서 연장 활성화를 요청할 수 있다고 나에게 말했다.위키백과의 이 연장선에 관심 있어?만약 그렇다면 여기에 당신의 지지를 보내주십시오.ColdCase (대화) 2008년 8월 2일 12:25 (UTC)[응답]

아주 흥미로워 보이는군 그래.우리가 정확히 무엇을 위해 그것을 사용할 것인지 명확히 해줄 수 있니?스코모록 2008년 8월 2일 19:40 (UTC)[응답하라]

물론이지예를 들면 다음과 같다.공룡의 연대표, 로마 제국의 연대표, 진화의 연대표, 우주의 연대표, 우리의 솔라시스템 연대표 등등.여기서 타임라인에 대해 말하자면, 평행하게 볼 수 있는 수십 개의 사건들을 말하는 겁니다.최고의 기능:네가 원하는 대로 붙이면 돼!시청할 수 있는 기능:좋아, 지구의 기존과 비교했을 때 인간은 언제 생겨났을까?식당 종업원이 언제였죠?한 기사에서 다음 기사로 이동하여 거기에 나열된 이벤트를 추가할 수 있다.그래서 당신은 당신의 개별적인 연대표를 함께 할 수 있다.위의 그림에서 볼 수 있듯이:다음과 같은 비교를 할 수 있다.T-Rex가 언제 존재했고, 지구의 기존과 비교했을 때 트릴로비트가 언제 존재했는가.다음과 같다.좋아, 난 타임라인에서 서로 비교해서 그것과 저것을 보고 싶어.인간이 지구의 전체와 비교했을 때 연대표의 오른쪽 끝에 있는 매우 좁은 띠에 불과하다는 사실은 정말 흥미롭다.) 복잡한 생명체 그 자체도 지구 진화에서 매우 늦게 나타났었다...역사였던 것(또는 미래를 예견할 수 있는 것)은 어떤 주제든 간에 서로 보여주고 섞일 수 있다.마치 작은 타임라인 원더랜드 같다;;) 콜드케이스 (토크) 01:26, 2008년 8월 3일 (UTC)[응답하라]

정말 좋을 것 같아.역사의 한 주제에 관한 모든 기사들은 유익할 것이다.나는 너무 많은 자바스크립트를 좋아하지는 않지만, 이것은 그만한 가치가 있을 것이다.나의 유일한 걱정은 그것이 오래된 브라우저에서 작동하지 않는다는 것이다. ·:··윌 베백·:· 01:39, 2008년 8월 3일 (UTC)[응답]

이 테스트는 다음을 통해 성공적으로 완료되었다.Internet Explorer 6, 7, 8(IE 5.5 엔진과 함께)Firefox 2, 3, Opera mini; Opera 8, 9.5 (7 및 7.5로 부분적으로 기능함), Safari 3.1, 4, Mozilla 1, Netscape Navigator 8, 9 (부분적으로는 6 및 7로 기능함)브라우저가 javascript를 지원하지 않으면 아무것도 표시되지 않는다.브라우저가 AJAX를 지원하지 않는 경우, 기사/페이지를 변경하지 않는 한(따라서 적어도 하나의 기사의 타임라인을 추가할 수 있음) 여전히 작동한다.그래서 99%의 이용자에게 효과가 있어야 한다고 말하고 싶다;) ColdCase (토크) 12:09, 2008년 8월 3일 (UTC)[응답]

FWIW, 기존 마크업을 사용하는 위키백과에서 타임라인이 이미 사용되고 있음 - 예를 들어 매킨토시 모델의 타임라인을 참조하십시오. -93.96.212.203 (대화) 15:03, 2008년 8월 4일 (UTC)[응답]

편집자 지수에는 타임라인에 대한 정보가 많다. -- 존 브로우턴 (식용차) 17:51, 2008년 8월 4일 (UTC)[응답]

관심 있는 사용자들이 "이미 일정이 있다"고 말하기 전에 이 확장자의 내용을 읽어주면 고맙겠다.이 연장은 다른 레벨, 상호작용, 기타 등등...직접 읽고 사용해 보십시오(원래 게시물의 라이브 예시 참조)."이미 존재하는" 것으로만 표현하지 마십시오.이것은 쉬운 시간대가 아니다.역사에 관한 것이라면 위키리듬이 백만 배 더 낫다.반면에, 통계에 관한 것이라면, 당신은 쉬운 시간을 필요로 할 것이다.EasyTimeline은 서버 쪽이고 WikiTimeline은 클라이언트 쪽이며 (Javascript) EasyTimeline은 클라이언트 쪽이며 Easytimeeline만이 꿈꿀 수 있는 것을 할 수 있다.) 또한 쉬운 시간줄보다 사용하기 쉽다(Again, Easytimeline에 반하는 것은 없으며 Wikitimeline이 할 수 없는 것을 할 수 있다).그러니, 제발 조금만 시간을 내서 실제 사례를 들어봅시다.다시, 여기 라이브 예시에 대한 링크가 있습니다, 첫 번째 줄의 링크를 클릭하십시오;) 만약 여러분이 시간을 들여 이것이 무엇에 관한 것인지 알고도 여전히 그것에 반대한다면: 좋아, 문제 없어!ColdCase (대화) 21:56, 2008년 8월 4일 (UTC)[응답]

따라서 mw당:확장:위키타임라인, 연장은 2008년 7월 현재 버전 1.0이다.그것을 활성화하는 데 많은 시간이 걸리지 않을 것이다. - 정확히 무엇이 필요한지는 잘 모르겠지만. - 존 브로튼 (기침) 22:45, 2008년 8월 4일 (UTC)[응답]

이름 바꾸기

WP:편집자 리뷰의 이름을 위키백과_talk:로 바꾸자는 제안을 했다.편집기_review#이름 변경.논평과 아이디어는 환영한다.MBisanz 18:48, 2008년 8월 4일 (UTC)[응답]

기사 내 Ogg 비디오 처리 개선 필요

(이것은 아마도 BugZilla에 들어가야 할 소프트웨어 제안일 것이다, 비록 나는 현재 이것이 어디로 가야 하는지를 정확히 알 수 있을 만큼 소프트웨어의 레이어를 잘 이해한다고 주장하지는 않는다.)

현재 위키백과에서 비디오가 처리되는 방식에는 몇 가지 큰 문제가 있으며, 나는 이것이 다른 위키미디어 프로젝트에도 적용된다고 생각한다.

• 데이터 형식이 전혀 같지 않아도 동영상은 기사에서는 이미지로 취급된다.키 방향 "Image:"는 뚜렷한 이유 없이 비디오 파일을 표시하는 데 사용된다.
• 위키미디어 소프트웨어는 편집자가 글에 축소판 그림이나 크기 조정된 이미지를 게시하고자 할 때 이미지를 보다 작은 크기로 변환한다.이 트랜스코딩은 대역폭을 절약하기 위해 수행되며 이미지를 표시하는 데 필요한 데이터보다 더 많은 데이터를 전송하지 않는다.이것은 사용자들을 위해 투명하게 행해진다.
• Wikimedia 소프트웨어는 비디오를 능동적으로 변환하지 않으며, 사실 원본보다 작은 프레임 크기로 표시했을 때 비디오에 전혀 영향을 주지 않는다.만약 640x480 비디오가 하원에 업로드되었다가 128x96으로 기사에 표시된다면, 그것은 여전히 완전한 640x480 비트 전송률로 독자에게 스트리밍되며 불필요하게 엄청난 양의 대역폭을 소비한다.

이미지 자동 크기 조정을 위한 핸들링에 비해 이 소프트웨어를 설계하는 사람이 비디오 처리를 제대로 고려하지 않은 것 같다.

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

추가 기능이 필요하지 않은 변경 사항

일반적으로 나는 비디오 처리 방식에 대해 두 가지 변경을 제안하고 있는데, 이는 비디오가 현재 사용되는 방식을 처리하는 것이 더 나을 것이다.

• 1. "비디오:"를 사용하여 위키백과의 모든 비디오 콘텐츠를 지정하십시오.
• 2. 영상미네일 템플릿은 비디오가 표시되는 시기를 인식할 수 있도록 수정해야 하며, 아무것도 저장하지 않고 대역폭을 낭비하기 때문에 비디오 프레임을 원본보다 작게 크기를 조정하려 하지 않으며, 편집자의 프레임 크기가 원본 비디오보다 작은 비디오를 표시하려는 시도를 무시하도록 수정해야 한다.

이런 변화가 자리 잡으면서 현재와 같은 영상으로 작업하는 현실을 반영할 것이다.편집자가 더 작은 프레임 크기를 원할 경우 다음을 수행해야 한다.

• 현재 대용량 비디오 다운로드
• 지역 기계로 변환해
• 원본의 다시 터치된 버전으로 작은 비디오 업로드(원본을 대체하지 않음)
• 업로드한 작은 비디오에 링크하여 "100px" 크기 조정 방법을 사용하지 않고 전체 프레임 크기로 표시

나는 이 트랜스코딩된 대체 비디오 파일이 원본과 어떻게 연결될 수 있는지 예를 만들었다.향후 비디오 작업에 이와 같은 것을 사용할 것이다.이미지:Rhof-Histrchmaschine.ogv

이미지 템플릿이 깨지고 비디오 크기 조정을 시도하면 안 된다는 것을 알기 때문에 세탁기 기사에서 보듯이 비디오 크기를 조정하려고 시도하지 않는 나만의 자유형 위키 동영상 템플릿 스타일을 실험하고 있다.

(나는 위키피디아에서도 이 예를 보여주고 있다.미디어 파일 생성 및 사용)

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

자동 비디오 트랜스코딩

훨씬 더 광범위한 기능 변화는 Wikimedia 소프트웨어가 이미 이미지 사용자를 위해 크기를 조정하고 있는 것처럼 사용자로부터 추가 입력 없이 비디오를 더 작은 프레임 크기로 변환하고 비트 전송률을 자동으로 낮추는 기능을 추가해야 한다는 것이다.

이것을 하기 위한 정해진 방법이 없기 때문에 그것은 만들어져야만 할 것이다.이미지 템플릿은 이미 "100px"를 사용하여 너비를 지정할 수 있다.비디오에서도 유사한 것이 가능해야 하며, 아마도 추가적인 "kbit" 명칭이 있어야 한다.

[[비디오:예.gg 200px 200kbit 썸 비디오 너비 200픽셀 및 최대 스트리밍 속도 200kbit로 표시된 예시 비디오.]

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

트랜스코드에 필요한 시간을 어떻게 처리할 것인가?

잠재적인 문제는 비디오를 변환하는 데 필요한 시간과 처리 능력과 관련이 있다.1분짜리 동영상을 변환하는 데 2분 정도 걸린다.

위키미디아는 트랜스코딩할 데이터 볼륨이 작기 때문에 실시간으로 영상을 변환한다.특히 수천 명의 사람들이 기사에 비디오를 추가하고 편집함에 따라 비디오가 트랜스코딩하는 백로그가 될 수 있기 때문에, 플라이 비디오 트랜스코딩은 작동하지 않을 수 있다.

또한 비디오 파일을 변환하는 데 일정한 시간이 걸리기 때문에 트랜스코드 대기열이 남용될 가능성도 있어 보인다.반달은 수백 개의 트랜스코드를 대기열에 넣을 수 있는데, 각각은 매우 다양한 트랜스코드 파라미터를 가지고 있고, 다른 누군가를 위해 트랜스코드를 완전히 차단할 수 있다.

반달은 매일 일정한 숫자로 트랜스코드를 씌우는 것은 좋은 선택이 아닌 것 같다. 왜냐하면 반달은 매일 그 한계를 넘나들 수 있기 때문이다.나는 비디오 트랜스코딩 문제와 잠재적인 시스템 파괴 행위를 다루는 좋은 방법을 알지 못한다.

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

트랜스코드에 필요한 스토리지를 어떻게 처리하는가?

두 번째 문제는 저장과 관련이 있다.분명히 위키피디아는 크기가 조정된 이미지를 캐시에 투명하게 저장하기 때문에 기사에서 수천 명의 사람들이 다시 볼 때 다시 암호화될 필요가 없다.아마도 위키미디아가 비디오의 자체 트랜스코딩을 했다면 이것들 역시 캐시되어야 할 것이고, 이러한 트랜스코드가 사용하는 공간은 사소한 것이 아니다.

여기에서도 나는 공공 기물 파손에 대해 걱정한다. 왜냐하면 반달은 결국 수백 메가바이트의 위키미디어 저장소를 소비하게 되는 20메가 비디오의 많은 트랜스코드를 만들 수 있기 때문이다.

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

현상유지

만약 자동 트랜스코딩이 사용되지 않는다면, 우리는 현재의 시스템을 고수하게 되는데, 이 시스템에서는 각 사용자가 자신의 컴퓨터에서 로컬 트랜스코더를 사용하여 동일한 비디오의 각 크기 변형을 업로드할 수 있다.

트랜스코딩이나 프레임 크기 조정을 위해 어떤 대역폭 속도를 사용해야 하는지에 대한 지침이 없기 때문에, 각 사용자가 만든 트랜스코드의 결과는 이미 매우 불균일하고 하나의 비디오에서 다음 비디오로 일관성이 없다.

나는 여기서 일관된 방법을 찾으려고 노력하고 있다: 위키백과_토크:생성_and_usage_of_media_files#Offering_multiple_video_bit-rate

지역 트랜스코딩에 대한 짜증 요인은 반달족이 같은 비디오의 수백 개의 리코드를 업로드하고 그런 식으로 위키미디어 저장 공간을 낭비하는 것을 막는 어떤 것도 볼 수 없지만 반달리즘 남용의 한계인 것 같다.

전반적으로 나는 이것을 다루는 좋은 방법이 보이지 않을 뿐이지만, 기사에 비디오를 더 쉽게 사용할 수 있도록 뭔가 조치가 취해져야 한다.

DMahalko (대화) 2008년 7월 27일 (UTC) 14:09 [응답]

흥미롭군위키(미디어)가 비디오 포맷을 지원하는지 몰랐어.해결책은 좀 더 일반적인 4:3 가로 세로 비율에 맞는 크기를 제외하고 2단계(예: 128x128px, 256x256px, 512x512px 등)로 비디오 크기를 몇 개(표준화) 제공하는 것이라고 생각한다.편집자가 a)를 업로드하거나, b) 서버에 의해 자동으로 생성될 수 있다.실제로 전시된 비디오는 이러한 가능성들 중에서 선택되어 기사 자체에 명시된 크기에 상관없이 압축될 것이다.나는 가능한 크기의 수를 한정된 (낮은) 숫자로 줄일 것을 제안하고 싶다.이 값을 제한하고 두 개의 전원(또는 일부 다른 숫자의 전원)에 기반하여 구성하면 대용량 파일에서 로컬 디스크 공간을 최소로 낭비할 수 있다.SharkD (대화) 18:08, 2008년 7월 27일 (UTC)[응답]

나는 항상 우리가 그렇게 많은 비디오를 가지고 있지 않은 이유가 위키피디아의 이미 매우 큰 밴드를 줄이려는 "빅 브라더"의 어떤 음모 때문이라고 생각했다.그래서 나는 항상 우리가 이 사실을 비밀로 하려고 노력하는 어떤 불문율이 있었지만.아마도, 여기서 이 문제를 논의하는 대신, 더 좋은 장소를 고려해 볼 수 있을 것이다.미디어 파일(이미지) 업로드와 관련하여 어떤 유형의 문서가 이미 존재하는지 위키피디아를 살펴보셨습니까?오그 파일...등? (이것에 대한 많은 정보를 수집해 보려 한다) 나는 조사했던 기억이 나지만, "우량" 메카니즘으로부터 두어 블록의 프리마릴리를 얻어냈다.지금 우리가 동영상을 올릴 수 있다는 사실을 왜곡하려는 것처럼 보이는 것 대신에, 왜 단순히 동영상을 다루는 섹션이 없는가 하는 것이다.나는 이 제안이 유효한 문제를 제기한다고 생각한다.첫째, 1) OGG 파일을 포맷하는 것은 어렵다(또는 적어도 마지막으로 시도한 것은) 2) 우리가 사용해야 할 사양이 무엇인지 파악하기가 어렵다.그래서 다시 한 번, 문제를 무시하는 대신에 나는 우리가 이 문제를 조금 더 깊이 들여다봐야 한다고 생각한다.동영상을 다루는 계획을 자세히 설명하십시오.어떤 것을 보관해야 하는지, 어떤 것을 삭제했는지.최대 크기.WP를 시작할 때가 된 것 같다.WP와 유사한 지침을 따를 수 있는 비디오(및 정보를 수집하는 장소):이미지. --CyclePat (대화) 06:00, 2008년 7월 29일 (UTC)[응답]

"새로운" 사용자들이 동영상을 업로드하는 것을 막기 위해 메카니즘을 추가하는 것을 추천하고 싶다.그리고 임의의 문자처럼 보안 코드 기능을 추가하십시오.또는 IP 범위당 비디오가 3개(더 많이 업로드하려고 하는 Sockpuppet을 포함)인 비디오의 최대 업로드 비율 --CyclePat(토크) 06:05, 2008년 7월 29일(UTC)[응답]

우리는 현재 하드코어 자유 콘텐츠 애호가들 외에서는 아무도 코덱에 대해 알지 못하며 코덱으로 변환하는 방법을 통제하는 코덱을 사용하는 것을 발견한다.우리의 영상 핸드링이 이미지 핸들링에 비해 상당히 부족한 이유는 이미지의 경우 대부분 ImageMagick과 RSVG를 미디어위키로 구축하는 문제였기 때문이다.그러나 현재 테오라에 대한 지원은 다소 낮다(이 때문에 비디오를 업로드하는 우리들 중 많은 수가 여전히 그것을 하기 위해 명령행 기반의 ffmpeg2theora를 사용한다).코르타도(소프트웨어)는 없는 것보다는 낫지만 그래도 꽤 기본이다.그러나 이것을 개선시키기 위한 노력은 최소한 있을 것이다.여기 봐.Geni 15:43, 2008년 7월 29일 (UTC)[응답]

따라서 다중 비트 전송률을 생성하기 위한 암호 해독은 미디어위키에게는 장기적인 목표다.그러나 비디오 암호화는 CPU 비용이 너무 비싸기 때문에(단일 이미지 크기 조정과 비교), 아직 아무도 만들지 않은 특수 시스템/미디어위키 인프라가 많이 필요하다.그러나 그것은 결국 올 것이다.대역폭에 관한 한...오늘날 비디오는 정말로 문제가 되지 않는다. 사실 위키미디아가 비디오 트래픽을 훨씬 더 많이 가지고 있는 것이 매우 좋은 여러 가지 복잡한 이유들이 있다.

Ogg 파일을 만드는 한, 커먼스에 관한 좋은 자습서가 있다. 개선된 것을 환영한다.

현재로서는 미디어위키가 미리 보기 이미지를 지원하기 전에 했던 작업을 수행할 수 있다.우리는 사람들이 하이리스를 올리도록 장려할 수 있고 우리는 수동으로 낮은 품질의 미리 보기를 만들 수 있다.누군가가 이런 일을 하는 봇을 세우는 것은 어렵지 않을 것이다.이상적이지는 않지만, 세상의 종말도 아니다.수동으로 생성된 미리 보기에 대해 권장 비트 전송률과 해상도를 설정하는 것이 유용할 것이다...나는 아직 아무도 그것을 하지 않았다고 믿는다.

이 과목에 관심이 있는 사람들도 이 리스트 포스트에 관심이 있을 수 있다. --Gmaxwell (대화) 00:02, 2008년 7월 31일 (UTC)[응답]

그래서, 당신은 사용자들이 고레즈 버전의 동영상을 업로드하도록 장려되고 있다는 말씀이세요?어떤 이유에선지 나는 달리 기대했다.샤크D (대화) 01:33, 2008년 8월 1일 (UTC)[응답]

위키피디아와 커먼스에 모든 파일을 업로드할 경우 20메가바이트의 파일 크기 제한이 있으므로 업로더는 고해상도지만 몇 초 동안만 사용할 수 있는 고해상도 또는 몇 분 동안 실행되는 작은 저화질의 저화질 영화를 선택할 수 있다.그것만으로도 사용 제한은 충분할 것 같다.DMahalko (토크) 2008년 8월 5일 (UTC) 13:42, 답신

플래그 지정된 수정본 요청

현실을 직시하자, 영어 위키피디아에서는 합의 부족으로 인해 국기 개정안이 시행되지 않을 것이다. (적어도 그렇더라도 나는 매우 놀랄 것이다.)그리고 어쩌면 그것이 좋은 것인지도 모르고, 지금 말하기는 불가능하며, 양쪽의 설득력 있는 주장이 많이 있다.

내 제안은 특정 페이지에 플래그로 표시된 수정본을 사용할 수 있도록 하는 것이다.관리자는 WP:RFP와 유사한 프로세스로 수정사항 플래그 지정 페이지를 설정할 수 있다.이것은 반보호의 대안으로 사용될 수 있다.이것을 사용할 수 있는 한 페이지는 진화지만 다른 많은 페이지들도 있을 것이다. (반보호를 대신하는 것이 아니라 다른 대안이 될 것이다.)

이런 식으로, 위키피디아의 대다수는 변하지 않을 것이고, 단지 몇 개의 기사만 있을 것이다; 등록되지 않은 사용자들은 비록 그들의 변경사항이 나타나기까지는 시간이 걸리겠지만 이전에 그들이 할 수 없었던 일부 페이지를 편집할 수 있을 것이다.모든 페이지에는 수정 플래그 지정 여부에 대한 합의가 필요할 것이다.

단순하게 하기 위해서, 나는 새로운 사용자 그룹을 만드는 것을 반대하며 롤백자, 관리자 등에게 새로운 권한을 주겠지만, 나는 합의가 그렇게 된다면 새로운 사용자 그룹을 받아들일 수 있다.

나는 이 제안이 합의를 이끌어 낼 수 있는 훨씬 더 좋은 기회를 가지고 있고 또한 우리가 비침해적인 방법으로 행동의 국기적인 수정을 볼 수 있게 해줄 것이라고 믿는다.만약 그것이 정말 도움이 되고 많은 기사에 시행된다면, 사람들은 전면적인 개정안에 더 개방적일 것이다.만약 그렇지 않다면, 우리는 그냥 상태 쿼터로 돌아갈 수 있다.

네 생각을 말해줘.Jkasd 07:05, 2008년 7월 30일 (UTC)[응답]

흠, 나는 방금 아이디어를 생각해 냈다. 익명의 독자/편집자의 여론조사는 어떨까?현재 제안된 바와 같이 플래그로 표시된 수정사항은 로그인한 사용자에게 전혀 영향을 미치지 않으므로, 영향을 미칠 사용자로부터 의견을 구하는 것이 타당하다.미디어위키에 링크를 걸 수도 있어아논노티스.문제는, 우리가 단지 표준 프로젝트 페이지만 할 수 있다는 것인데, 그 페이지를 보고, 편집하고, 응답을 타이핑하는 기회 비용이 낮은 관심(그리고 샘플 편향)으로 이어질지는 잘 모르겠다.간단히 클릭해서 제출하는 것이 더 나을 수 있다; 어쩌면 개발자들이 Special을 해킹을 할 수도 있다.보드투표, 혹은 툴서버에 무언가를 올릴 수도 있다. --슬로우킹맨 (토크) 10:05, 2008년 7월 30일 (UTC)[응답]

나는 그것이 좋은 생각이라고 생각하지 않는다; 그러한 시스템은 아마도 게임할 수 있을 것이다.{{Nihiltrestalk log}}} 11:47, 2008년 7월 30일 (UTC)[응답하라]

anon 사용자들에게만 영향을 미치는 기능에 대해 토론한 다음 기본적으로 그것에 대해 말하지 않는 것은 아마도 훨씬 더 '게임하기 쉬운' 일일 것이다. --VectorPotential Talk 11:53, 2008년 7월 30일 (UTC)[응답]

로그인한 사용자에게 영향을 미침 - 변경사항을 즉시 볼 수 없음.Hut 8.5 20:14, 2008년 8월 1일 (UTC)[응답]

음, 개인적으로 나는 "플래그로 보호되는" 페이지에 대한 유일한 실제 효과(즉, 애논이 보는 것)로 국기 수정이 가능해야 한다고 생각하는데, 그래서 이것은 좋은 생각처럼 들린다.a) 추천 기사(마커처럼, 관리자로 설정할 수 있는 기능 제공)와 b) 공공 기물 파괴 행위 청소에 대한 기본 지원(마커처럼, 롤백자나 새로운 그룹에게 주는 기능, 관리자와 마찬가지로)을 추가하는 것은 애논이 보는 것에 큰 영향을 미치지는 않지만 지역사회에 유용할 수 있는 보너스가 될 것이다.{{Nihiltres talk log}}{{Nihiltres talk log}} 11:47, 2008년 7월 30일 (UTC)[응답]

응, 나는 이것을 지원할 준비가 되어 있어.아마도 우리는 모든 기사에 대해 그것을 가능하게 할 수 있지만, 관리자가 (이 제안과 유사한 방식으로) 페이지를 다르게 설정하지 않는 한, 등록되지 않은 사용자들에게 최신 버전을 보게 할 수 있을 것이다.Hut 8.5 20:14, 2008년 8월 1일 (UTC)[응답]

나는 보편적인 국기 개정에 대한 극단주의적인 반대자지만, 나는 거의 이 일의 배후에 있을 수 있었다.운이 좋으면, FR은 위키피디아의 가장 문제가 많은 페이지에 대해서만 선택사항으로 영구히 FR을 설정하게 되어, FR에 대한 음험한 생각이 프로젝트의 나머지 부분까지 스르르 흘러가는 것을 막을 수 있을 것이다.내가 보고 싶은 것은 관리자가 문제가 있는 페이지를 위해 사용할 수 있는 "비상 페이지 상태" 조치의 확립된 계층 구조로, FR이 옵션 중 하나가 될 수 있는 몇 가지 등급의 페이지 보호가 있는 통합 시스템이다.사실, 나는 완전한 보호가 완전히 폐지되어 FR로 대체되는 것을 보고 싶다.반 보호는 그대로 유지되지만, 완전 보호는 기본값이 가장 최근에 플래그가 지정된 편집으로 설정된 "플래그된 개정 상태"로 대체된다.미스터 IP 《열린 편집의 정의》 2008년 8월 2일 14:19 (UTC)[응답]

나도 꽤 회의론자지만 재판을 하는 것이 타당해 보인다는 데는 동의해.우리는 각자 그 효과가 무엇일지 무한정 추측할 수 있지만, 그것에 대해 현명해지지는 않을 것이다.나는 일반적으로 BLP로 시작하는 것이 다른 곳에서 제안되었을 수도 있다고 생각한다.그것은 넓어 보이지만, 나는 NPOV의 원리를 정말로 손상시킬 수 있는 BLP에 대한 보다 과감한 제한을 없애기 위해 그것을 지지한다.우리는 현재 공직에 출마한 정치인들과 같이 확실한 계층으로 시작할 수 있다.DGG (대화) 05:39, 2008년 8월 3일 (UTC)[응답]

여기서 뭘 하면 좋을까, 버질라에서 요청서를 올려야 할까?Jkasd 04:20, 2008년 8월 5일 (UTC)[응답하라]

그렇다, Bugzilla의 일반적인 요청은 좋은 생각이겠지만, 나는 개인적으로 이 논의가 실행 가능성을 향상시키기 위해 더 많은 관심을 갖기를 바란다.{{Nihiltres talk log}}{{Nihiltres talk log}} 13:45, 2008년 8월 5일 (UTC)[응답]

이것은 위키백과에서 오랫동안 논의되어 왔다.플래그가 지정된 수정사항: 기존 제안사항에 추가하거나, 또는 해당 제안이 정당하다고 생각될 경우 자신의 제안을 추가하는 것이 어떻겠는가?—B가 추가한 서명되지 않은 설명 준비. 월터딩 (토크 • 기여) 2008년 8월 5일 15:50

네, 이 아이디어의 시드는 WT:플래그가 붙은 수정안#분할 제안들, 희망적으로 보였지만 아무 것도 나오지 않는 것 같았다.생각을 가다듬었고, 대신 여기서 의논하는 것이 좋을 것 같았다.Jkasd 21:05, 2008년 8월 5일 (UTC)[응답하라]

Friendluy에 "Welcome-auto", "Welcomeusername" 및 "uw-coi" 추가

이것들이 '친절함'에 있으면 좋겠는데, 그래야 우리가 더 잘 배치할 수 있어.나루톨로베히나타5 09:32, 2008년 7월 30일 (UTC)[응답]

자, 만약 당신이 그 템플릿들을 Friendly에 추가하고 싶다면, 당신은 Ioeth에게 그렇게 하라고 말하면, 그는 Friendly의 창조자다. Dokna macy [토크] 21:36, 2008년 8월 2일 (UTC)[응답]

그에게 연락하려고 했지만, 운이 없었어...나루톨로베히나타5 11:39, 2008년 8월 5일 (UTC)[응답]

재제안:계층화된 삭제 및 "설정된" 사용자 그룹 제안

이것은 얼마 전에 제안되었지만, 다른 모든 제안에 묻혀 있는 것 같아 WP:VPR/PP에 베꼈다.거기서 나의 수정된 제안에 대해 코멘트를 해줘. -- 임페라토르3733 (토크) 16:22, 2008년 8월 6일 (UTC)[응답]

밥 딜런

밥 딜런의 진짜 생년월일은 5월 24일이 아니라 11일. 부틀레그 시리즈 1-3권의 책자에 나오는 그의 아이디에 이렇게 나타나는데, 가짜 아이디를 쓰는 것 같지는 않아. 직접 찾아봐.—Alexadamalex가 추가한 서명되지 않은 설명 준비(대화 • 기여)

구글 검색 [3]에 따르면 5월 24일이라는 많은 정보원을 찾을 수 있다.Talk: 밥 딜런이 기사의 변화를 제안하기에 더 좋은 장소가 될 것이다.프라임헌터 (토크) 22:44, 2008년 8월 6일 (UTC)[응답]

편집기 제출 전, 로그인하지 않은 경우, 편집기 요청

등록한 사용자가 편집 시 로그인을 잊어버리는 경우가 있다.그 결과 등록된 사용자의 IP 주소가 사용자 이름 대신 기록에 표시된다.로그인하지 않은 사용자가 편집본을 제출할 때 "편집본을 제출하기 전에 로그인하시겠습니까?"라는 메시지를 받을 것을 제안한다.가능한 선택은 "예" 또는 "감사합니다,"가 될 것이다. --Bob K31416 (대화) 17:34, 2008년 7월 17일 (UTC)[응답하라]

나는 이 제안에 동의하고 나에게 일어난 다음과 같은 문제를 덧붙이겠다.watch list(로그인됨을 의미함)를 검토 중이었는데 새 창에서 열기 위해 항목을 클릭했을 때 새 창이 로그인되지 않았다.이 작업은 자주 발생하는 것은 아니지만 실제로 로그인했다고 생각할 때 IP를 편집하게 된다.Dbiel 18:36, 2008년 7월 17일 (UTC)[응답하라]

• 설명:나는 이 아이디어가 정말 마음에 들어.이런 일이 거의 두어 번 있었는데, 위키미디어 소프트웨어에서 페이지 편집을 시작할 때 로그인을 원하는지 물어봤으면 좋겠다.당신이 로그인하지 않았을 때, 그것은 현재 편집 페이지 상단에 눈에 띄지 않는 명백한 통지를 표시한다.아마도 그 고지는 약간의 로그인 특정 그림이 있는 {{ambox}}에 표시되도록 변경될 수 있을 것이다.페이지 저장 중에 로그인 프롬프트보다 구현이 더 쉬울 것이다.— OranL (토크) 19:13, 2008년 7월 17일 (UTC)[응답]

• {{ambox}}}의 제안은 매우 좋은 생각처럼 들리며, 현재의 통지 표준화와 일관될 것이다.Dbiel 19:25, 2008년 7월 17일 (UTC)[응답하라]

나는 이 아이디어를 강력히 지지한다. 왜냐하면 주로 나에게도 그런 일이 일어났고, 사용자들에게 로그인하지 않았음을 알리는 눈에 띄는 시각적 지표가 없기 때문이다. --craphic알렉스:. 2008년 7월 17일 19:27 (UTC)[응답하라]

이것은 좋은 생각인 것 같다.그 동안 사용자는 로그인할 때 편집 페이지의 모양이 독특하도록 사용자 정의 .css 파일에 무언가를 삽입할 수 있다. 즉 밝은 보라색 배경 또는 기타.이렇게 하면 그 차이가 더욱 뚜렷해질 것이다.Phyomonas_(talk) 19:29, 2008년 7월 17일 (UTC)[응답]

질문:해당 기사/세션에 대해 처음 "감사하지 않음"을 한 번 클릭하면 즉시 중지할 수 있는가?나는 IP 편집자들이 그들이 편집을 할 때마다 그 프롬프트에 직면해야 한다면 상당히 좌절하게 될 것이라고 상상할 것이다.자인 에브라힘 (대화) 2008년 7월 17일 (UTC) 19:33[응답]

나는 이와 같은 세계적인 통고를 생각하고 있었지만, 다른 색상의 박스를 가지고 (어떻게 바꾸어야 할지 모르겠고, 그렇다 모든 사람이 자유롭게 바꿀 수 있다.) --acrocuse알렉스: 2008년 7월 17일 19시 34분 (UTC)[응답하라]

편집의 약 30%는 익명의 사용자로부터 온다.그들이 편집을 시도할 때마다 팝업 메시지로 때리고 싶은가? --카닐도 (대화) 19:40, 2008년 7월 17일 (UTC)[응답]

로그인 정보가 컴퓨터에 저장될 수 있기 때문에 IP 또는 상자에 자동으로 나타나는 것을 감지할 때 사용자가 등록되어 있는 것을 감지하여 해당 상자를 표시하도록 할 수 있는가? --arcuit알렉스:. 2008년 7월 17일 19:44[응답]

이것의 문제는 고정적인 IP주소를 가지고 있지 않은 사용자들이 많고, 위키백과에 접속할 때마다 IP주소가 바뀔 수 있다는 것이다.하지만 세션 쿠키는 가능성이 있을 수 있다.

여기 몇 가지 아이디어가 있다.

• 이건 경고처럼 보인다.

현재 로그인되어 있지 않은 경우.이렇게 편집하면 IP 주소가 이 페이지의 편집 기록에 공개적으로 기록된다.계정을 만들면 IP주소를 숨길 수 있고, 그 외에 많은 혜택이 제공된다.당신의 IP로 전송된 메시지는 당신의 토크 페이지에서 볼 수 있다.

• 이건 통지서처럼 보인다.

현재 로그인되어 있지 않은 경우.이렇게 편집하면 IP 주소가 이 페이지의 편집 기록에 공개적으로 기록된다.계정을 만들면 IP주소를 숨길 수 있고, 그 외에 많은 혜택이 제공된다.당신의 IP로 전송된 메시지는 당신의 토크 페이지에서 볼 수 있다.

• 두 가지 모두 다음보다 더 눈에 띈다.
  

현재 로그인되어 있지 않은 경우.이렇게 편집하면 IP 주소가 이 페이지의 편집 기록에 공개적으로 기록된다.계정을 만들면 IP주소를 숨길 수 있고, 그 외에 많은 혜택이 제공된다.당신의 IP로 전송된 메시지는 당신의 토크 페이지에서 볼 수 있다.

에 대한 소품:알렉스: 내가 그의 페이지에서 쓴 글에 대해서.— OranL (대화) 20:17, 2008년 7월 17일 (UTC)[응답]

아직 계정이 없다면 계정을 만드는 것에 대해 뭐라고 말해야 하지만...Mr.Z-man 22:57, 2008년 7월 17일 (UTC)[응답]

나는 이것이 보통 계정을 가지고 있는 편집자들만이 볼 수 있어야 한다는 것이 요점이라고 생각했다.

어쨌든, 나는 ambox를 사용하는 것이 매우 좋지 않은 생각이라는 것을 발견한다; 특정한 일련의 템플릿들은 기사의 문제와 연관되어 있고, 이러한 메시지들의 본질은 대부분 메인 스페이스의 페이지들에 관한 일시적인 문제들이다.일반적인 용도에 더 적합한 형식을 원한다면 {{ombox}}}을(를) 적극 제안한다.2008년 7월 17일 (UTC) 23:27의 공작 월섬[응답]

계정을 가지고 있지만 로그인하지 않은 사용자만 모든 aon 사용자에게 표시하지 않고는 표시할 수 없다고 생각한다.Mr.Z-man 23:59, 2008년 7월 17일 (UTC)[응답]

{{ombox}}}을(를) 사용하도록 템플릿을 변경했고 현재 로그아웃된 메시지의 텍스트도 변경했다.위에서 보고 의견을 제시하십시오.템플릿이나 텍스트를 자유롭게 편집하십시오.— OranL (대화) 03:01, 2008년 7월 18일 (UTC)[응답]

_________________________________________________________________
모두 답장에 감사드린다.나는 네가 나의 제안에 대해 배려해 준 것에 감사한다.몇 가지 정리를 하려면 좀 더 자세한 설명을 해야 할 것 같다.

제안된 프롬프트는 편집 내용을 제출할 때 로그인하지 않은 모든 사용자를 위한 것이다.여기에는 등록된 사용자와 등록되지 않은 사용자가 모두 포함된다.등록되지 않은 사용자와 쉽게 구분할 수 있는 방법이 보이지 않기 때문에 둘 다 포함된다.

그들이 편집을 시작할 때 프롬프트가 나타나지 않는다.편집본을 제출할 때만 나온다.이 선택은 누군가가 편집서를 제출하지 않고 편집 페이지만 보고 싶어 할 수 있고 이 경우 프롬프트가 불필요하기 때문에 제안되었다.

안내문을 볼 사용자들은 위키백과 편집에 등록되어 있지 않고 처음 접하는 사용자들이 포함되어 있기 때문에, 나는 그들이 편집을 주저하지 않도록 최대한 간단하고 친근하게 언어를 만들려고 노력했다.즉흥적으로,

편집 내용을 제출하기 전에 로그인하시겠습니까?

그리고 클릭할 수 있는 선택들은 가능한 한 단순하고 친근한 것이어야 했다.

<그렇다> <고맙다>

--Bob K31416 (대화) 03:16, 2008년 7월 18일 (UTC)
_______________________________________________________[응답]

사실 등록 사용자와 등록되지 않은 사용자를 구분하는 쉬운 방법이 있다.로그인하면 쿠키가 생성된다.로그아웃할 때 쿠키는 사용자 이름을 저장하므로 다음에 로그인할 때 암호만 입력하면 된다.따라서 사용자가 로그아웃할 때 쿠키를 탐지하고 로그인하라는 메시지가 표시되도록 소프트웨어를 프로그래밍할 수 있을 것이다.이것은 사용자가 동일한 컴퓨터를 사용하고 쿠키가 삭제되지 않는 한 효과가 있을 것이다.– FISDOF9 04:00, 2008년 7월 18일 (UTC)[응답]

말씀드렸듯이 스타일 면에서 이런 생각을 하고 있었다.일반적으로 페이지에서는 볼 수 없지만, 보는 모든 IP에 대해 충분히 사용할 수 없음.

--accentalEx:. 08:37, 2008년 7월 18일 (UTC)[응답]

이것은 좋아 보이지만, 나는 여전히 편집이 제출될 때마다 프롬프트에 반대한다.자인 에브라힘 (대화) 09:51, 2008년 7월 18일 (UTC)[응답]

나는 이 아이디어의 장점을 본다.그것은 어떤 행동도 요구하지 않고 따라서 눈에 띄지 않는다."페이지 저장" 버튼 바로 아래에 위치해야 한다.편집자가 로그인하지 않은 경우에만 나타날 것이다.이렇게 하면 등록한 사용자는 "여기는 뭔가 달라!"라고 깨닫게 될 것이다.그것은 등록되지 않은 사용자에게는 중요하지 않을 것이다.그래서 나는 그 생각에 동의하고, 그것을 더 단순하고 부드럽게 만들기 위해 상기시키는 문구의 변화를 제안할 것이다.

편집 내용을 제출하기 전에 로그인하려면 여기를 클릭하십시오.

추가 기능이 유용할 수 있다.사용자가 로그인한 후 사용자가 편집 페이지에 있는 위치로 돌아가기 위해 클릭하는 버튼이 있을 수 있지만, 이번에는 로그인한 사용자로.그러나, 이것은 이미 일상적인 로그인을 하는 동안 기능이 아니기 때문에, 구현하기 어려울 것 같다.

--Bob K31416 (대화) 14:48, 2008년 7월 18일 (UTC)[응답]

만약 당신이 보통 이것과 문제가 있고, 당신이 dev를 기다리는 것을 원하지 않는다면, 당신의 monobook.css (또는 다른 피부 css 파일)에 있는 것과 같은 것이 도움이 될 것이다.

/* 로그인한 경우 */ "Save page" 버튼을 녹색으로 돌리십시오. 입력#wpSave {     배경색:#88ff88번길; } 

계정에 로그인하면 "페이지 저장" 버튼이 녹색으로 바뀐다.버튼이 녹색으로 표시되지 않으면 로그인하지 않았음을 의미한다(버튼을 클릭하지 마십시오!).Anomie⚔ 11:25, 2008년 7월 18일 (UTC)[응답]

영리하고 간단한 솔루션!나는 그것을 좋아한다.색도 다르고 뭐 그런 것도 없지만 지금 내가 직접 쓰고 있어. --_{tiny plastic} 그레이 나이트⊖ 12:13, 2008년 7월 18일 (UTC)[응답]

좋은 생각이야, 나한테는 안 통한다는 것만 빼면 말이야.조금도내 모노북.css나 monobook.js나 그 어떤 것에도 절대 작동하지 않는 코드.그게 왜 그런거야? -- 아첨꾼알렉스: 2008년 7월 18일 13:04 (UTC)[응답하라]

모노북 스킨을 사용하십니까?그렇지 않다면 그 피부에 .js 또는 .css 페이지를 사용해야 할 것이다.가끔 내가 일을 자극할 필요가 있을 때 나는 모던 스킨을 사용할 것이다. 그래서 내가 모더니즘 스킨을 할 때는 modern.js가 다음을 포함한다.importScript('User:Nihiltres/monobook.js'); .{{Nihiltrestalk log}} 13:29, 2008년 7월 18일 (UTC)[응답]

오, 작동을 시작하기로 결정되었지만, 내가 로그인했을 때.왜 이러한가?흠... --coracripatic알렉스: 08:43, 2008년 7월 20일 (UTC)[응답하라]

어제 잔돈으로 바꾸고 나서 캐시 지우는 거 잊으셨어요?아노미에 13:51, 2008년 7월 20일 (UTC)[응답]

내가 캐시를 치웠는데도 아무런 효과가 없었다. --corratic알렉스: 2008년 7월 20일 16:30 (UTC)[응답하라]

monobook.css 수정은 개인 사용자 계정에만 영향을 미칠 수 있다.예를 들어, 로그인하지 않으면 버튼을 빨간색으로 만들 수 없다. — OranL (대화) 18:32, 2008년 7월 20일 (UTC)[응답]

그리고 OranL이 위에서 말했듯이, 그것이 모노북.css를 사용하는 포인트다.위에 제시된 예를 사용하여 로그인할 때는 저장 버튼이 녹색으로, 로그인하지 않으면 회색으로 된다.그것은 나의 첫 모노북 참가였다.녹색 버튼은 익숙해지는 데 시간이 조금 걸렸지만, 로그인하지 않은 것이 분명하므로, 회색 저장 버튼을 클릭하기 전에 로그인해야 한다는 것을 상기시켜준다.Dbiel^(Talk) 18:57, 2008년 7월 20일 (UTC)[응답하라]

아 그렇구나.잘못 읽었어.로그인하지 않으면 녹색이 나타날 줄 알았다(사용설명서에서도 그것이 어떻게 가능할지 모른다).내 잘못. --oracuit.알렉스: 2008년 7월 20일 20:59 (UTC)[응답하라]

나는 이 제안이 매우 마음에 든다.사용자들의 기여를 IP로 돌리는 대신, 우리 모두에게 noobs가 누구인지를 더 잘 알게 해줄 것이다. --Pwnage8 (토크) 18:46, 2008년 7월 20일 (UTC)[응답]

나는 이 초록색 버튼이 실제로 기계로 통합되어야 한다고 생각한다. --acrobat알렉스: 2008년 7월 22일 15:23 (UTC)[응답하라]

나는 이 제안에 강력히 반대한다.나는 그 이면에 숨은 좋은 의도를 이해하지만, 이 폴리디는 IP 편집이 의도라기보다는 일종의 실수라고 추측할 수도 있고, 위키피디아를 편집하는 대다수의 방식이라고 추측할 수도 있다.그것은 또한 IP 편집에 성가신 한 단계를 더 도입할 것이며, 우리는 이미 IP 편집자들에게 너무 많은 일을 했다.그것은 또한 IP 편집의 점진적인 제거를 위한 또 다른 조치로서 반달들에게 전달된 경고와 의심스러운 것처럼 보이는 IP 편집자들에게 "경고"를 전달할 가능성이 있다.나는 가능한 한 강력하게 반대해야 한다.Mr. IP (대화) 08:58, 2008년 7월 26일 (UTC)[응답]

• 코멘트 나는 피부가 로그인한 편집자와 IP 편집자의 색상이 달라지는 것밖에 없다고 생각한다.헥, 지금 입력하는 편집창을 둘러싼 줄이 다른 색이어도 로그인하지 않았다는 걸 알 수 있을 거야.가래닭 (토크) 09:19, 2008년 7월 26일 (UTC)[응답]
  • 잘 말했다, 닭.음, 사실 내 피부는 로그인하지 않았을 때와는 매우 다르며, 의도적으로 그렇게 한다.하지만, 충분히 다르지 않다.IP에 대한 편집 창은 녹색, 분홍색, 파란색, 또는 Mr IP가 이쁘게 생각할 수 있다. -- Hoary (토크) 09:26, 2008년 7월 26일 (UTC)[응답]
    • 나는 이 제안을 강력히 지지한다.IP 편집에 오명을 씌우거나 IP에서 편집하는 모든 사람에게 새로운 고통을 안겨주지 않고 문제를 해결한다.그것을 구현하는 것은 위키피디아의 삶의 질 향상이 될 수 있다. 오픈 편집의 Defender인 IP씨, 2008년 7월 27일(UTC) 15:17[응답]

    편집 창을 변경하려면 CSS를 다음에 적용하십시오.#wpTextbox1저장 버튼에 대해 위에서 제안했듯이.던질 수도 있다.#wpSummary편집 요약 상자에 대해 동일한 작업을 수행하십시오.이와 비슷한 것:

#wpTextbox1, #wp요약 {     테두리 색의:#0f0; /* 녹색 테두리 부여 */     배경색:#cfc; /* 연한 녹색 배경 */ } 

• • 물론, 로그인하지 않은 편집자를 위해 색상을 변경하도록 dev를 시도하십시오.아니면 지금 당장 이렇게 할 수도 있는데, "표준" 외모의 유일한 차이점은 당신이 로그인해야 한다는 것을 의미한다.이렇게 하면 당신이 원하는 대로 명백하거나 확실하지 않게 만들 수 있다. 나는 녹색의 Save 버튼만 고수할 것 같지만, 만약 당신이 그렇게 걱정한다면 당신은 매직핑크 페이지를 전부 넘길 수 있다.아노미야 20:45, 2008년 7월 26일 (UTC)[응답]

______________________

내 이전 논평에서 나는 제안과 논평, 특히 알렉스의 제안에 대응하여 원래의 제안을 수정했다는 것을 알아두길 바란다.

여기서 수정된 제안서를 좀 더 명확히 하도록 노력하겠다.사용자가 로그인하지 않은 경우에만 액션을 요구하는 프롬프트 대신 "페이지 저장" 버튼 행 바로 아래에 파란색 상자가 배치된다.어떠한 조치도 필요하지 않으며 정보 목적만을 위한 것이며, 로그인하기 위한 편리한 링크가 있을 것이다.

________________________________________________________________________________________

<페이지 저장> <미리보기 표시> <변경사항 표시>

편집 내용을 제출하기 전에 로그인하려면 여기를 클릭하십시오.

________________________________________________________________________________________

편집자가 로그인하지 않은 경우에만 나타날 것이다.이렇게 하면 등록한 사용자는 "여기는 뭔가 달라!"라고 깨닫게 될 것이다.그것은 등록되지 않은 사용자에게는 중요하지 않을 것이다.

사용자가 로그인하지 않은 경우에도 유사한 문이 이미 표시된다는 점에 유의하십시오.문제는 '페이지 저장' 버튼에서 벗어나 페이지 상단에 나타나 편집 내용을 저장하러 갈 때 눈에 띄지 않는다는 점이다.
-Bob K31416 (대화) 13:07, 2008년 7월 26일 (UTC)[응답]

그럼 예전 공지를 새 공지로 바꿔야겠네.누가 그 생각에 찬성하는가? --Pwnage8 (대화) 15:47, 2008년 8월 4일 (UTC)[응답하라]

조언해줘서 고마워.나는 오래된 통지가 괜찮다고 생각한다.이 보고서는 몇 가지 유용한 세부사항을 제공하며, 편집을 시작할 때 일부 편집자에게 편집을 시작하기 전에 로그인할 수 있도록 로그인할 수 있는 옵션이 있음을 알릴 수 있다.다른 편집자들은 현재 메시지조차 알아차리지 못하고 바로 편집상자로 가서 편집을 시작할 수도 있다.내가 필요한 것은 "페이지 저장" 버튼 근처에 있는, 이전에 언급했던 파란 상자 안에 있는 짧은 알림입니다.'페이지 저장' 버튼과 근접해 있어 편집자의 주목을 받을 가능성이 높으며 박스 안의 정보는 로그인 옵션을 편집자에게 상기시켜준다. --Bob K31416 (대화) 20:22, 2008년 8월 7일 (UTC)[응답]

로그아웃된 편집과 로그아웃된 편집의 시각적 차이를 강력히 지지한다.근본학(C) 13:15, 2008년 10월 8일(UTC)[응답]

위키백과:공신력(빨간 머리와 주근깨를 가진 9대 여성 배관공)

위키백과:공신력(빨간 머리와 주근깨를 가진 9월 여성 배관공)은 공신력 인프라의 추가적, 그러나 필요한 확장으로서 제안되었다.주제별 공신력 지침의 이러한 인프라가 성장함에 따라, 우리는 AfD에서 기대의 모든 순열을 정의하고 독립적 사고의 위험한 적용을 방지해야 할 필요성에 보조를 맞춰야 한다.당장 이 중대한 문제에 대한 합의를 결정해야 할 뿐만 아니라, AfD 마감자들의 선한 판단에 부담을 줄 수 있는 모든 가능한 상황을 서둘러 정의해야 한다. --Kevin Murray (talk) 2008년 8월 5일 (UTC) 14:58, 8월 5일 (답)

• 이것은 심각한 제안으로 보이지 않는다. ·:·····15:10, 2008년 8월 5일 (UTC)[응답하라]
  • 윌, 겉으로는 통찰력이 있지만 이 패러디의 더 깊은 메시지는 매우 심각하다.주제별 공신력 가이드라인에 대한 현재 제안은 대략 10개가 있으며 제안 비율은 처분 비율을 훨씬 초과한다.여기에는 두 가지 문제가 있다:(1) 사람들은 WP:N에 대한 신뢰를 잃었고 (2) 우리는 우리의 규칙 세트를 더 이상 바보로 만들 위험이 있다. --케빈 머레이 (대화) 15:16, 2008년 8월 5일 (UTC)[응답]
    • WP:POINT는 여기에 적용되는 것으로 보인다.WP:N과 관련된 제안이 너무 많다면, 내 생각에 다른 제안을 추가하는 것은 토론을 진전시키는 데 도움이 되지 않는다고 생각한다. -- John Brown은 2008년 15:36, 8월 5일 (UTC)[응답]
      • 사실이지만, 짧고 재미있는 읽을거리야.사실, 토크 페이지는 가장 좋은 부분이다. -αααρρα 14 14 14 14 14:21, 2008년 8월 6일 (UTC)[응답]

유머러스한 페이지에 대한 이 토론은 여기에 속하지 않는다. --Boring old (fart) 12:25, 2008년 8월 7일 (UTC)[응답]

형식만이 유머러스하다. 그 메시지는 더 이상 심각할 수 없다!우리는 좁게 정의되고, 모순되고, 중복된 규칙 집합에 압도당하고 있다.최선의 의도에서, 사람들은 매달 점점 더 많은 규칙을 제안하고, 그리고 잠시 후 몇 명의 편집자들 사이의 합의에 근거하여 수락에 대한 합의를 주장하고 있다.템플릿에 나열된 알림 가이드라인에 대한 제안서를 참조하십시오.InKGuide. --Kevin Murray (대화) 2008년 8월 7일 (UTC) 15:59 [응답]

이 모의 제안이 내가 지금까지 본 것 중 가장 설득력 있는 지적 중 하나라는 것을 인정해야 한다.--아버지 구스 (토크) 20:17, 2008년 8월 7일 (UTC)[응답]

우리는 이미 당신이 불평하는 것에 대해 하는 에세이를 가지고 있다: 그것은 WP:CREP이라고 불린다.우리는 다른 것이 필요하지 않고 확실히 WP가 필요하지 않다.요점. 정책이 너무 많다고 생각되면 그렇게 말하고 구체적인 정책을 제시하되, 요점을 말하지 말라.데몬138 (대화) 22:29, 2008년 8월 7일 (UTC)[응답]

프린터 친화성

위키피디아가 어디선가 '프린터 프렌들리 버전'이라는 좋은 버튼이 있을 것이라는 것은 전혀 생각지도 않는 것 같지만, 나는 그것을 찾을 수가 없었다.내게 필요 없는 것(헤더, 바닥글, [편집] 링크 등)을 모두 프린트해서 잉크와 나무를 낭비하는 것은 고통이다.

Toolbox > 인쇄 가능한 버전 아래 왼쪽 사이드바에 있다. --— Gadget850 (Ed) - 19:52, 2008년 8월 6일 (UTC)[응답]

어떤 반감기의 현대 브라우저도 어쨌든 프린터 친화적인 버전을 자동적으로 사용할 것이다.우리는 모든 페이지에 관련 없는 것들을 제외한 프린트 스타일시트를 가지고 있다.Internet Explorer 6 또는 7 또는 Firefox 버전을 사용하는 경우 탐색이나 편집 링크를 인쇄하지 마십시오.— Matt Eason 20:43, 2008년 8월 7일 (UTC)[응답]

새로운 CSD 기준 제안

빠른 삭제에 대한 새로운 기준을 만들기 위한 제안에 대한 의견을 여기에 초대하기 위한 간단한 메모.제안된 기준은 업로더가 저작권 태그를 공급했지만 제3자를 콘텐츠 소유자로 지정한 경우, 허가를 내준 증거가 없는 경우 업로더에게 통지한 후 7일 후에 해당 허가를 받지 않으면 미디어가 속도를 내는 것이다.이것은 Commons에서 사용되는 NPD 프로세스와 동일하며, NSD와 NLD와 평행하다.체중을 재십시오! --Landmann (talk) 21:01, 2008년 8월 7일 (UTC)[응답]

물품에 대한 GA 마커

전에도 이런 제안이 있었겠지만, GA 지위가 부여된 기사의 오른쪽 상단 구석에 앉을 수 있는 작은 마커를 구할 수 있을까?우리가 현재 FA들을 위해 가지고 있는 것처럼 말이다.독일어 위키피디아는 글자 L(레센스베르테 아르티켈을 위한, 읽을 가치가 있는 기사)이 들어 있는 약간 푸른 광장이 있는데, 꽤 잘 작동한다.예는 다음과 같다: de:노르데.영어 위키백과에 GA 기호를 사용할 수 있을까? - 불안첼로 (토크) 00:57, 2008년 8월 8일 (UTC)[응답]

음, 네 말이 맞아.이것은 몇 번이고 제안되었고, 항상 격추된다.미끄러운 비탈길이다.FA와 GA가 표시되어 있다면 A급은 왜 안 돼?우리의 더 좋은 기사만을 광고하는 것은 NPOV에 어긋나는 것인가?왜 B급이나 스타트와 스텁이 안 되지?또한, 좋은 기사가 되는 것은 한 명의 검토자에 의해 결정되는 반면, FA는 지역사회의 합의에 의해 결정된다.그것은 끔찍한 생각이 아니라, 그것에 대해 행동하기 위한 명확한 합의를 얻는 것은 불가능할 것이다.파라곤12321 (대화) 02:15, 2008년 8월 8일 (UTC)[응답]

당연하지, 내가 예상했던 답이야.수치스럽기는 하지만, 적어도 내게는 그것이 유용한 특징이 될 것 같다.이를 WP에 게시할 경우:PEREN이 그렇게 자주 제안된다면?불안첼로 (토크) 02:30, 2008년 8월 8일 (UTC)[응답]

그러나 이러한 기능은 사용자가 직접 사용할 수 있다.My Preferences → Gadgets로 이동하십시오."사용자 인터페이스 가젯" 아래에는 "각 기사에 대한 페이지 헤더의 일부로 기사 품질 평가 표시"를 체크하는 상자가 있다.그 끊임없는 제안에 대해서는, 여러분은 마지막 "녹색 점 토론"을 읽는 것에 관심이 있을 것이다.그윈바 (대화) 02:54, 2008년 8월 8일 (UTC)[응답]

예, WP에 추가해야 한다.PEREN; 나는 그것을 지난 번에 제안했고, 이 제안이 수억 번 실패했다는 기록이 거기에 포함되어야 한다.샌디조지아 (토크) 02:58, 2008년 8월 8일 (UTC)[응답하라]

나는 그것을 추가했다.적합하다고 생각되는 대로 조정하십시오.그랜드마스터카 06:30, 2008년 8월 8일 (UTC)[응답]

위키백과 기사 및 사용자 정책 준수 점수 카드(템플릿)

임의의 삭제나 임의의 사용자 차단에 의존하기 보다는, 위키백과 기사 및 사용자 정책 준수 점수 카드(템플릿)를 사용하여 정책이 점수 ca에 대한 긍정 및 부정 등급의 합으로 표시된 동적 준수 등급으로 나열되는 기사와 사용자 모두의 실행 상태를 제공할 것을 제안한다.사용자 및 관리자가 사용자 또는 기사에 대해 입력한 rd.삭제 및 차단 결정은 좀 더 쉽게 합의에 도달할 수 있는 여러 관리자에 의해 이루어질 수 있다. (아래 표의 숫자는 컴퓨터에 의해 생성된 임의의 숫자에 불과하다)

참고 항목: 위키백과:위키프로젝트 협의회/디렉토리/위키피디아

줄리 댄서 (대화) 05:46, 2008년 7월 30일 (UTC)[응답]

너의 의도는 좋았을 거라고 확신하지만, 나는 이것이 실제로 일을 더 자의적으로 만든다고 생각해.예를 들어, "시스템 게임을 하지 마십시오" 칼럼의 증분 여부를 결정하기 위해서는 여전히 "가치 판단"이 필요하다. 사용자가 실제로 그렇게 하고 있었는가?이것은 현재 설정과 동일하다.그러나 이것과 다른 점은 어떤 맥락도 제거한다는 것이다. 그 값이 언제 증가했는가?오래전 일인가?사용자가 후속적으로 사과했는가?증가하는 사용자의 관계는 무엇인가; 그들은 사건에 연루되었는가?사용자의 활동을 보다 공정하게 평가하기 위해 고려해야 할 모든 종류의 맥락이 있으며, 기사도 마찬가지다.이것은 위키백과의 개념과 유사하다.투표는 토론의 대안이 아니다.미안! --_{tiny plastic} 그레이 나이트 grey 10:27, 2008년 7월 30일 (UTC)[응답]

사용자나 관리자가 토론 후 음수 또는 양수 값을 입력할지 결정하는 데 도움을 주는 사전 토론에는 문제가 없다.유일한 차이점은 테이블이 어떤 토론을 대체하는 테이블이 아니라 토론 페이지의 각 토론에 따른 현황 요약을 제공한다는 것이다.야채사우루스라고 생각해, 렉스, 야채사우루스!줄리 댄서 (토크) 2008년 7월 30일 (UTC) 14:17[응답]

이건 확실히 소름끼치는 일이야.문제 기사/사용자는 이와 같은 것을 도입하기보다는 사례별로 다루어야 한다.그것은 불필요하게 복잡하고 "숫자별" 접근법에 지나치게 전념하는 것처럼 보인다.나는 그것을 좋아하지 않는다.2008년 7월 30일 15:27(UTC)[응답]

나는 무엇보다도 그것을 학교 성적처럼 생각한다.현 제도는 갑자기 맑은 푸른 하늘에서 원한을 품은 다른 사용자가 할 수 있는 일은 모두 삭제하기 위해 경계선을 긋는 것이다.그들은 원저자의 반응이 인신공격이라는 주장이나 원저자가 미개하다는 주장을 몇 가지 접어두는 것만이 그들이 그 해석을 본국으로 몰고 가면 기사가 삭제되고 저자가 차단된다는 것을 알고 있다는 것을 알고 있다.만약 준수 이력이 인신공격이나 불친절함이 반작용의 잘못된 해석이라는 것을 보여줄 수 있다면 그러한 지명은 더 어려울 수 있다.가장 중요한 것은 그것은 맑은 파란 하늘로부터 삭제된 기사들에 대한 지명을 멈추게 할 것이다.원저자는 이 글에 대해 어떤 것이 있을지도 모른다는 경고를 받아 마땅하며, 이는 결국 지위의 역사가 드러내는 경향이 있을 것이다.지침서는 그러한 점에서 매우 유용한 등급 시스템을 사용하며, 유일한 차이점은 여기서 기사 및 사용자 상태에 관한 모든 정책에 적용된다는 것이다.야채사우루스라고 생각해, 렉스, 야채사우루스!줄리 댄서 (토크) 2008년 7월 30일 16:15 (UTC)[응답]

(ec) 우리는 이미 그것을 할 수 있는 능력을 가지고 있다.토크 페이지는 매우 드물게 삭제되기 때문에 과거의 토론을 잘못 전하려 해도 의미가 없다; 토크 페이지와 고발자의 입장은 대화 자체의 주요 원천에 의해 즉시 훼손된다.넌 이걸 2차 소스로 대체하자고 제안하는 것 같구나 그리고 그 상황에서 어떤 종류의 문맥도 제거해 줄거야정책 준수 문제를 숫자로 줄일 수는 없어, 너무 주관적이야.그리고 그 문제에 대해서는 백과사전에 도움이 된다면 규칙을 어길 수 있다!--_{tiny plastic}그레이 나이트⊖ 16:29, 2008년 7월 30일 (UTC)[응답]

생각 요약 렉스.당신은 아마도 당신 자신의 토크 페이지에서 관리자로서 토론을 끝내고 기사 토론 페이지나 사용자 토론 페이지로 돌아가 당신의 생각을 더 이상 말하지 않고 나타내기를 원할 것이다.당신은 그들이 미개한 것이 아니라고 말하고, 부정적인 금액을 입력하고, 당신은 그곳에 있는 타다 (té dé′) (정보적으로 팡파르의 소리를 제안하는데 사용됨: 발표와 함께 하는 승리나 자부심의 탄성, 활 등)줄리 댄서 (토크) 2008년 7월 30일 (UTC) 16:35 [응답]

내 이름은 렉스가 아니야(적어도 여기엔 없어)나는 너의 제안이 무엇인지 이해한다. 나는 단지 "나는 이런 저런 논평이 미개하다고 생각하지 않는다"라고 말하는 것 보다 나아진 이유를 모르겠다. 그것은 당신의 표를 증가시키는 모든 정보를 전달하고, 누가 그것을 말했는지에 대한 귀속성을 더 편리하게 보여주고, 그리고 럼보다는 개별적인 문제에 대해 말할 수 있게 하는 것이다.사용자가 지금까지 한 모든 작업을 하나의 더미(거대한 논쟁의 레시피처럼 들림)로 ping.--_{tiny plastic} 그레이 나이트 knight 17:02, 2008년 7월 30일 (UTC)[응답]

나는 여전히 네가 그 문제를 과장하고 있다고 생각한다.만약 어떤 기사가 잠재적인 공신력 문제를 가지고 있다면, 그것은 그렇게 태그되어야 한다.잠재적 검증가능성 문제가 있는 경우 이와 같이 태그가 붙어야 한다.만약 이 문제들이 특히 터무니없다면, 그것은 대신에 AfD로 간다.시간 경과에 따른 점수표라는 개념은 너무 지나치다.기사와 편집자를 "점수"하는 일은 특히 우리가 대별로 작용하는 시스템을 가지고 있을 때 너무 부담이 된다.세레 16:27, 2008년 7월 30일 (UTC)[응답]

공신력이나 참조와 같은 기존 태그가 있는 어떤 이유로든 삭제 태그가 지정되면 해당 태그가 삭제 태그 지정보다 강제적 또는 의무적 우선 순위를 가졌을 것이다.내가 무슨 말을 하려는지 알겠어?줄리 댄서 (토크) 16:38, 2008년 7월 30일 (UTC)[응답]

다소 미로 같은 표현이지만, 나는 사람들이 곧바로 삭제 태그로 가지 말고 정리 태그를 붙여야 한다고 말하고 있다고 생각한다.이것은 비록 그것이 요구되지는 않지만, 이미 공손하게 여겨지고 있다.우리가 말하고자 하는 것은 정리 태그와 정리 태그의 개수를 명시한 "점수 카드" 표가 있는 것은 실질적인 이익을 얻기 위한 노력의 중복으로 보인다는 것이다.그 테이블은 청소 문제가 무엇인지를 표시하지 않는 것만큼 도움이 되지 않는다.(사실 청소 태그도 최소한 그 위치가 약간의 단서를 줄 수는 있지만 토크 페이지 설명이 동반되어야 한다.) --_{tiny plastic} 그레이 나이트 ⊖ 17:02, 2008년 7월 30일 (UTC)[응답]

정리 태그가 필요한 글과 삭제 논쟁이 필요한 글의 차이는 잘 설정되지 않고 해석의 여지가 있다.그것이 바로 논의의 전체 목적이다.- 어떤 기사를 삭제해야 하는지, 아니면 회수할 수 있는지 여부를 결정하는 것이다.2008년 7월 30일 17:31(UTC)[응답]

지금 나의 인상은 아무도 어떤 것도 편집하고 싶어하지 않고 만약 편집이 누군가가 삭제하기 위해 지명할 최소한의 업무만 필요로 한다면 참조 태그를 붙이는 것이 아니라 삭제하기 위해 지명할 것이라는 것이다.그 아이디어는 만약 참조 섹션이 없다면 그것을 잊으라는 것처럼 보인다.즉, 인라인 레퍼런스가 없다는 뜻이고(기사는 하이퍼링크로 가득 차 있을 수 있지만), 레퍼런스 섹션 중 하나를 본 적이 있는가, 내 말은 모든 세부 사항을 말하는 것이다.댕! 삭제 딱지를 붙여서 여기서 나가자.줄리 댄서 (토크) 2008년 7월 31일 (UTC) 13:24 [응답]

그런 제도가 프로그램적으로 이루어질 수 있지 않는 한 나는 그런 제도를 신뢰하지 않을 것이다, 그것은 실제에 가깝지도 않다.샤크D (대화) 01:29, 2008년 8월 1일 (UTC)[응답]

나도 동의해.만약 자동화가 되고 자동화의 결과가 정확하고 목적에 부합한다면 나는 그것을 따라갈 것이다.

이렇게 되면 위키피디아가 경찰국가가 될 것이다. --Pwnage8 (대화) 08:30, 2008년 8월 6일 (UTC)[응답]

다른 사람들이 지적했듯이, 이것은 유용하기엔 너무 자의적이다.우리는 이미 당신의 차트에 있는 모든 이슈들을 처리할 준비가 되어 있다.만약 어떤 것이 공신력에 잠재적인 문제를 가지고 있다면, 그것은 태그가 붙는다.검증 가능성과 관련하여 잠재적인 문제가 있을 경우 태그가 지정된다.누군가 생각하기에 정기적인 편집 과정을 통해 고칠 수 없다고 생각하는, 특히 터무니없는 문제가 있다면, 기사는 AfD로 가져갈 수 있다.토크 페이지는 멋진 것들이고, 여러분이 제시한 많은 문제들을 해결하는 데 사용될 수 있다.

나는 사용자 등급을 매긴다는 생각에 더욱 강하게 반대한다.이것은 학교가 아니다; 모든 것을 잘 하는 사용자를 만들려는 어떤 목표도 없다; 여기 있는 모든 사람들은 최선을 다한다. 그리고 그들의 최선이 우리의 기준에 충분하지 않을 때, 다른 누군가가 와서 느슨한 부분을 고른다.'사용자 A가 NPOV 스타일의 전기를 쓰는데 짜증난다'는 어떤 종류의 말을 해도 우리의 응집력과 사기에 미치는 피해에 비하면 그 이점은 미미하다.어떤 종류의 규모든 구현할 때마다 사람들은 그것을 경연대회로 보게 될 것이다. 위키피디아는 그렇지 않다.2008년 8월 8일(UTC) 12시 19분 셀라노르[응답]

대체 사용자 이름

대체 사용자 이름은 원래 광범위하게 공공 기물 파손자 및 명백한 추가 지원을 원하는 사용자에 의해 사용되었기 때문에 나쁜 평판을 받는다.하나의 위키백과 계정에서 합법적인 대체 사용자 이름에 대한 문제는 이미 사용자의 위키봇에 대한 추가 계정을 요구함으로써 해결되었다.나의 경우 다중 사용자 이름이 필요한 것은 위키봇이 아니라 별도의 컴퓨터에 있는 나만의 프로젝트를 추적하는 것이다.내가 제안하는 것은 각 계정에 동일한 사용자 이름과 시퀀스 번호를 부여한 사용자 봇을 위한 것과 마찬가지로 여러 개의 계정이 실제로 허용된다는 것이다.나의 경우, 그것은 세 개의 계좌에 해당될 것이다. 예를 들어 찰리-1, 찰리-2, 찰리-3.나는 이 계정들이 내가 작업하고 있는 각각의 프로젝트를 추적하고 분리할 필요가 있다.그러한 능력이 없다면 나는 사용자 이름을 전혀 갖지 못할 것이다.—서명되지 않은 의견 71.100.0.179 추가(대화 • 기여)

음, IP 주소를 세지 않는 한 사용자 이름이 전혀 없으시죠...대체 계정에는 나쁜 평판이 있을 수 있지만, 당신이 제안하는 것처럼 봇을 제외한 모든 경우에 허용되지 않는 것은 확실하다.나는 다중 계정 정책을 읽기를 제안한다.나는 네가 제안하는 것은 이미 허용되었다고 믿는다.Mr.Z-man 06:51, 2008년 8월 3일 (UTC)[응답]

User_talk:를 참조하십시오.줄리 댄서, 위키백과:Checkuser/Case/Julie Dancer 요청, WP:ANI#사용자:줄리 댄서, 여기서 완전한 배경을 위해 인신공격과 해악을 반복했다.케빈 (토크) 09:22, 2008년 8월 3일 (UTC)[응답]

인신공격은 없었고 오직 사실의 진술만이 있었다.불행히도 위키백과 정책은 공산주의자들 역시 행정관이 되도록 허용한다.자신을 괴롭혔다고 주장하는 케빈과 사용자를 확인하면, 당신은 당신의 블록과 삭제 대상 지명 그리고 그 이면에 있는 이유가 말보다는 실제로 행동의 인신공격이었다는 것을 알게 될 것이다. 2008년 8월 12:13, 5 — 서명되지 않은 논평 71.100.0.126 (대화 및 기여)

그렇다, 위키피디아 정책은 공산주의자와 사회주의자들, 무정부주의자, 무신론자들, 무신론자들, 이교도들, 그리고 정치적이거나 종교적이거나 다른 개인적 측면에 상관없이 거의 모든 사람들이 관리자가 될 수 있도록 허용한다.그래서 나는 당신에게 규칙이 더 마음에 드는 다른 웹사이트를 찾기를 강력히 제안한다. -- 존 브로우턴 (식별) 12:41, 2008년 8월 5일 (UTC)[응답]

그게 왜 불행하지?2008년 8월 8일(UTC) 12시 24분(응답)

Pake라는 단어의 추가 정의

제안추가

"사진"은 컴퓨터처럼 ph(오토그래픽 f)ake 이미지를 만들었다.

소프트웨어에서 생성된 사진 몽타주나 향상된 이미지를 찾는 것은 꽤 흔한 일이다.때때로 이것들은 명백하지만 때때로 그들이 모두 가짜가 아니다.

리얼 삼손 (토크) 08:46, 2008년 8월 7일 (UTC)[응답]

나는 그 용어가 그 자신의 기사를 쓸 만할 만큼, 심지어 사진 조작에서 언급할 만할 만큼 충분히 주목할 만하다고 생각하지 않는다.포토샵.죄송합니다. - Twas Now (대화 • 기여 • 이메일 ) 2008년 8월 7일 (UTC) 11:31, 7 (응답)

도시사전에 제출할 것을 제안한다. --슬래시메(토크) 12시 12분, 2008년 8월 7일 (UTC)[응답하라]

농담 사이트.페이크에 대한 정의는 이미 있지만 이 특정 정의는 아직 아니다.아주 좋은 추가가 될 거야.그리고 그것은 "도시 사전"이라고 일컬어지는데, 단지 FTR. --Pwnage8 (대화) 19:04, 2008년 8월 8일 (UTC)[응답]

회계 개선

안녕 내이름 Kari 나는 너희들의 계정을 가지고 있어.그리고 궁금한게 있는데, 혹시 계정 설정을 개선해 줄 수 있는지요?나중에 다시 돌아갈 수 있도록 몇 가지 기사를 저장할 수 있었으면 좋겠어...유투브 같은 것들이 그들의 동영상에 어떤 역할을 하는데, 거기서 당신은 그것을 가장 좋아하는 것으로 올리고 당신의 홈페이지에서 찾을 수 있다.

로그인한 경우 맨 위에 "Watch"라고 적힌 탭을 클릭하여 기사를 "보기"할 수 있다.그런 다음 계정 이름 옆에 있는 페이지 맨 위에 있는 "내 감시 목록"을 클릭하면 즐겨찾기 목록처럼 보고 있는 모든 기사를 볼 수 있다.2008년 8월 8일 셰어 15시 12분(UTC)[응답하라]

그리고 물론 웹 브라우저의 책갈피 메뉴 내에 "Wikipedia 기사" 폴더를 설정하는 것을 방해하는 것은 없으므로 책갈피를 지정할 수 있다.또는 하위 페이지에 문서를 추가하는 사용자 하위 페이지(계정을 만든 경우 - free!)를 설정할 수도 있다.(그러면 노트를 쉽게 추가하고, 원하는 대로 그룹화 할 수 있는 등) -- 존 브로우턴 (식별) 15:51, 2008년 8월 8일 (UTC)[응답]

기본 페이지 페이지 페이지 목록

rev:38730으로, 이제 기본 페이지의 페이지 목록을 변경할 수 있다.그것은 현재 "메인 페이지 - 위키백과, 무료 백과사전"이다.누가 그것이 바뀌어야 한다고 생각하는가, 만약 그렇다면, 무엇으로 바뀌어야 한다고 생각하는가?아마도 "메인 페이지 - "?" --MZMcBride (토크) 00:03, 2008년 8월 9일 (UTC)[응답]을 제거하십시오.

나는 그것을 간단히 "위키피디아, 무료 백과사전"으로 설정했다.이것은 책갈피가 기본적으로 "메인 페이지"가 아닌 "위키피디아"로 시작되기 때문에 위키피디아 책갈피를 더 쉽게 할 것이다.그것은 또한 새로 온 사람들에게 좀 더 직관적이어야 한다.이것에 대해 다른 생각은 없으십니까?—2008년 8월 9일 00:54(UTC) 점 기억[응답]

이것은 위키피디아에서 벌어지고 있는 일과 비슷한 논의인 것 같다.빌리지_펌프_(기술)#제안:_Move_main_page_to_a_different_namespace.데몬138 (대화) 01:04, 2008년 8월 9일 (UTC)[응답]

새로운 기능성은 그 제안서(버기질라 특집요청 참조)와 함께 만들어졌으며, 페이지 제목을 "위키피디아, 무료 백과사전"으로만 바꾸는 것을 지지한다.--- 아버지 구스 (토크) 02:16, 2008년 8월 9일 (UTC)[응답]

추가 읽기

위키피디아가 새로운 과목(편파, 식이요법 문제 등)의 진입점으로서 훌륭하다는 것을 알게 된 이상, 필자와 편집자가 다루는 주요 주제(문자 참조와는 별도로, 항목 내용에 대한 간략한 설명으로)와 관련된 짧은 독서목록도 추가하도록 권장할 이유가 있는지 궁금하다.그러면 모든 관심 있는 독자들이 최신 관련/권장 출판물에 접속하는 데 도움이 된다.09:07, 2008년 8월 6일 —WECIU에 의해 추가된 서명되지 않은 의견 작성(토크 • 기여)

"추가 판독" 섹션(WP:GTL)은 기사에 사용될 수 있는 출처를 위한 것으로 되어 있지만, 아직 사용되지 않았다.독자들이 주요 주제에 대한 최신 출판물을 보게 하는 경우, "외부 링크" 섹션의 링크가 이를 달성하지 못하는 범위까지 인용문은 각주나 "외부 링크" 섹션에 있는 다른 주제에 대한 별도의 위키백과 기사에 있어야 한다.그리고 독자들은 기사의 위키링크나 "See other" 섹션의 링크를 통해 그러한 주제에 접근할 수 있어야 한다. -- John Brown은 2008년 8월 6일 (UTC) 14:21, 8월 6일 (답)

그것은 단지 가이드라인 중 하나일 뿐이다(Wikipedia:GTL#Furter reading)을 권장한다.

그것은 명시적으로 "독자에게 더 많은 읽을거리, 유용한 배경, 또는 더 많은 정보의 출처로 추천하는 모든 책, 기사, 웹 페이지 등에 사용되어야 한다." (현재 ;) -- Quidity 03:06, 2008년 8월 7일 (UTC)[응답]

아, 아마도 나는 그 부분에서도, 당신이 언급하지 않은 다음과 같은 부분에서도 잘못 이해한 것 같다.이 섹션... 일반적으로 기사에 구체적으로 언급되지 않은 주제에 관한 자원에 대한 것이다. - 존 브로튼(식별자) 23:31, 2008년 8월 7일(UTC)[응답]

아, 이런.나는 그것이 모순될 때 그것을 사랑한다.불협화음/IAR이 작동 중! 일관성은...;) --Quiddity 05:55, 2008년 8월 10일 (UTC)[응답]

메타위키에서 플러드 플래그 제안

영어 위키피디아에 관심을 가지고 있는데, 핵심 프로그램에 대한 개정은 지역 프로젝트에 대한 합의에 의해 가능/불가능할 수 있기 때문이다.만조기논보컬스크림 (토크) 2008년 8월 9일 (UTC) 17:56 [응답]

아무도 적절한 시기에 이 설정을 켜고 끄는 것을 기억하지 못할 것이다.이 효과를 원하는 경우 기본적으로 활성화되어 있는 "관리 편집 숨기기" 설정을 추가하는 것이 더 쉽지 않을까?— 2008년 8월 9일 샬럿웹 18:18 (UTC)[응답]

물론이지. 이 위키에 대한 커뮤니티의 관심이 있을지도 모르니까 여기에 글을 올렸을 뿐이야.메타 활성화 전용인 경우 메타 제안서.재미있는 읽을거리, 그리고 내가 말했듯이, 우리가 엔위키를 위해 이것을 원한다면, 우리는 여기서 토론을 시작해야 한다.Best, NonvocalScream (토크) 03:50, 2008년 8월 10일 (UTC)[응답]

Utilisatur SUL

안녕, 난 fr:에서 온 프랑스인이고 fr:의 창시자 중 한 명이야.Modelle:utilisateur SUL(여기서 이 템플릿을 번역한다)은 사용자 페이지에 이 템플릿을 넣는 것에 대한 아이디어 입니다.독자들에게 당신의 주요 위키가 어디에 있는지 알리기 위해서입니다.당신은 우리가 이것을 바벨처럼 "메타/일반" 템플릿으로 만들 수 있다고 생각하는가?Otourly (talk) 2008년 8월 8일 (UTC) 질문 또한 메타에 대해 다음과 같이 물었다.메타퓨브#Utilisateur SUL[응답]

제안된 템플리트를 템플리트에 복사하지 않아야 할 이유를 알 수 없음:SUL Box, 하지만 난 템플릿 전문가가 아니야.에드존스턴 (토크) 2008년 8월 10일 (UTC) 18:55 [응답]

프라이빗뮤징스의 아르브컴 제한사항 뒤집기 제안

위키백과로 이동:관리자_noticeboard#Proposal_to_oberturn_Privatemusings.27_arbcom_restrictionsrestrictions.NonvocalScream (talk) 2008년 8월 10일 (UTC) 20:48[응답]

섹션 보기

특정 섹션, 즉 RD에 대한 특정 질문(또는 제안 마을 펌프에 대한 제안)--omnipotence407 (대화) 11:53, 2008년 8월 10일 (UTC)[응답]을 시청할 수 있는 방법이 있어야 한다.

불가능해.각 페이지의 내용이 극적으로 변할 수 있기 때문에 시계 시스템은 한 페이지 단위로 되어 있다.— 당신을 먹여 살리는 손:^Bite 2008년 8월 10일 (UTC) 13:54[응답]

위키백과 참조:다년제 제안#페이지의 개별 섹션 감시 목록 작성 허용.Mr.Z-man 14:13, 2008년 8월 10일 (UTC)[응답]

문서 섹션의 컨텐츠로 "LED 템플릿" 사용

나는 이것이 효과가 있을지 잘 모르겠고 이 제안에 대해 토론하고 싶다.기본적으로 다음이 필요함:

1. 편집을 능률화하다
2. 부정확한 중복을 제거하다.
3. 정보 업데이트의 지연을 없애다.
4. 서로 다른 장소에서 동일한 소재여야 하는 것 사이의 충돌을 제거한다.

많은 (대부분 큰) "주요" 기사에는 약간의 내용이 포함된 섹션과 합법적인 "바보" 기사인 다른 기사와의 링크가 있다.그러한 물품 포크의 목적은 대개 주요 물품의 공간을 절약하기 위한 것이다.이제 기본 기사의 관련 섹션에 템플릿(포크 기사에 있는 LED의 내용에 기초함)을 배치한다면, 우리는 많은 작업을 절약할 수 있을 것이며, 포크 기사의 추가 개정(현재와 같이)이 주요 기사의 관련 섹션에 반영되지 않을 때 가능한 편집 충돌(및 상충되는 정보)도 절약할 수 있을 것이다.이 제안은 자동으로 통일된 내용을 보장할 것이다.

예를 들어보자:

대하드론 충돌기 1차 기사에는 '입자 충돌의 안전'이라는 섹션이 있다.좋아, 좋아...

이 섹션에는 다음과 같은 "메인 아티클" 템플릿이 포함되어 있다.

그 다음에 해당 주제에 대한 정보 단락이 나타나며, 포크 기사의 리드선과 가급적 동일하다.포크 기사가 그 목적에 부합하는 경우, 그 리드 내용의 템플릿은 주요 기사의 관련 섹션에 충분한 내용이어야 한다.

그러한 섹션은 다음 두 가지 템플릿만 포함할 것이다.

1. "주문서" 템플릿
2. "LED" 템플릿

만약 이 제안이 채택된다면, 우리는 심지어 그 두 템플릿의 기능을 링크와 리드 콘텐츠를 모두 포함하는 하나의 템플릿으로 결합할 수 있을 것이다.

어떻게 생각해?이게 먹힐까?잠재적인 문제점은?그들이 이 제안을 수정하고 그냥 파기하는 것만으로 해결될 수 있을까? - 페이즐리 / 토크 08:32, 2008년 8월 10일 (UTC)[응답]

비록 주요 기사의 업데이트에 따라 그러한 부분을 업데이트할 필요가 있지만, 나는 그러한 조치를 정당화하는 것이 그렇게 중요한 문제는 아니라고 생각한다.우선, 기사의 리드는 주제를 소개하고 가장 중요한 정보만 포함하고 있다는 점에서 가장 바뀔 가능성이 낮은 부분이다.매일 일어나는 현상(즉, 리드(lead)이 다소 나쁘거나 현재 사건과 관련된 경우가 아니라면)이 아니며, 잘 쓰여진 리드(lead)의 수정을 정당화할 만큼 중요한 사건들은 어쨌든 모든 관련 기사 전반에 파급되어 전체적으로 변화를 야기해야 한다.그것과는 별도로, 범위에도 차이가 있다. 적절한 섹션은 기사에 잘 통합되어 있어야 하며, 반면 리드선은 기사에 대해 소개하고 소개와 관련된 특정 스타일 규칙을 따라야 한다(대담한 방법 및 참조 방법 포함).일부 섹션은 당신의 예처럼 주요 기사의 리드선과 거의 동일하지만, 대개 차이가 있을 것이고, 단순히 텍스트를 복제하는 것만으로 편집자들이 매우 다른 기사 부분에 동일한 텍스트를 사용하도록 강요할 것이다.그것은 문제를 일으킬 것이고, 나는 비용을 정당화하기에는 이득이 불충분하다고 생각한다(이것을 소수의 경우에만 적용한다고 해도, 그것의 사용은 불가피하게 확산될 것이고, 거기서부터는 미끄러운 경사지라고 할 수 있다.나는 이 생각에 반대한다.흥미롭지만 문제가 있어2008년 8월 10일 (UTC) 09:22의 공작 월섬 (Walthaltham, The Duke of 09:22

나는 그 생각에 감사한다."... 어쨌든 모든 관련 기사에 파급되어 모든 기사에 변화를 야기해야 한다."음, 그게 바로 이 제안이 자동화하는 것이고, 내가 제안하는 이유는 그것이 항상 일어나는 것은 아니라는 것을 관찰했기 때문이다.내가 편집하는 기사는 대개 매우 크고 논란이 많으며, 기사의 변경에 따라 LED가 수정된다.그러한 변화가 항상 "모든 관련 기사의 변화"를 야기하는 것은 아니다.그 후 같은 주제와 관련된 다른 기사들을 통제하는 편집자들 사이의 악랄한 편집 전쟁을 포함한 갈등이 발생한다.NPOV는 반대편 POV를 포함하도록 요구하기 때문에, 이것은 울타리 양쪽에 POV를 포함시키는 것을 자동화할 수 있다.한쪽이 이기면 NPOV가 진다.이런 상황에서 어느 쪽도 승리하지 못하면 모두가 승리한다.나의 제안은 위의 후기를 쓰기 전에 내가 처음 생각하고 제안했던 것처럼 논란의 여지가 없는 것을 포함한 모든 상황에 분명히 적용된다. -- Fyslee / talk 09:42, 2008년 8월 10일 (UTC)[응답]

이것은 새로운 제안이 아니다; 아마도 그것은 WP에 추가될 수 있다.PEREN? 기본적으로 제안되고 있는 것은 딸아이 기사의 리드 부분을 메인 기사로 옮겨서, 두 사람이 계속 동기화되도록, 그리고 편집이 한 곳에서만 이루어지도록 하는 것이다.

그 제안에는 적어도 두 가지 문제가 있다.더 작은 것은 이것이 편집에 더 많은 복잡성을 더한다는 것이다; 숙련된 편집자들은 무슨 일이 일어나고 있는지 알아낼 수 있지만 다른 편집자들은 그렇지 않을 수도 있다.그리고 복잡성과 함께 혼란뿐만 아니라 잘못해서 사물을 깨뜨릴 가능성도 생긴다.(mw:확장:라벨이 부착된 섹션 전폐가 구현되었다.)더 중요한 것은 사실 딸아이 기사의 리드 섹션과 본기사의 한 섹션의 내용이 같아서는 안 된다는 점이다.딸아이 기사의 리드 섹션은 독자가 주제에 대한 이해가 없는 것처럼 써야 하며, 메인 기사의 섹션은 독자가 위의 단원을 읽었다고 가정하고, 정보를 반복해서는 안 된다.그 차이점들은 단어들이 위키링크가 되어있는지 안되어있는지와 같이 사소한 것일 수도 있고, 독자의 방향을 잡기 위해 딸 기사에서는 전체 문장을 복제하는 것만큼 중요할 수도 있다.(위 공작의 논평대로)

마지막으로, 한 가지 옵션은 상황이 심각하게 잘못 정렬되는 것을 발견했을 때 {{Sync}}을(를) 추가하는 것이다. -- John Brown (식별) 15:51, 2008년 8월 11일 (UTC)[응답]

"메타" 위키백과 관련 뉴스 페이지

페이지 작성 제안(WP와 같은 일부 지역:메타뉴스 또는 WP:en의 뉴스를 나열하는 ENWIKINEWS).위키백과내가 몇 주 동안 자리를 비웠기 때문에, 내가 없는 동안 무슨 일이 일어났는지 알기 위해 29,000페이지의 AN/I 아카이브들을 읽지는 않을 것이다(그리고 나는 그것에서 혼자가 아니라고 확신한다).커뮤니티는 이 사이트에서 매우 중요한 부분이라 7월 초와 비교했을 때 내가 완전히 어둠에 빠진 것 같아 아쉽다 - 같은 페이지에 있는 최근의 ArbCom 판결이나 다작의 반달 사건을 정말 따라잡고 싶다.건배, 알렉스 뮬러 16:35, 2008년 8월 10일 (UTC)[응답]

나는 그 아이디어가 마음에 든다."중앙집권화된 디스큐션"은 좋은 출발점처럼 보이지만, 현재 진행 중인 토론, 중요한 실타래 등을 요약하면 정말 유용할 것이다.셀라노르 16:38, 2008년 8월 10일 (UTC)[응답]

위키백과의 주별 추가 섹션으로 추가될 수 있음:표지판.— CharlotteWebb 18:21, 2008년 8월 10일 (UTC)[응답]

ARBCOM 케이스에 대한 팻말 기사가 이미 발행되어 있다. - 아이스웨지 (토크) 01:18, 2008년 8월 11일 (UTC)[응답]

이것은 고양이 종을 치는 것에 대한 전설적인 논의를 생각나게 한다 - 모든 사람들이 그것이 이루어져야 한다는 것에 동의하지만...예를 들어 m:list Summary Service를 보면, 일부 메일링 리스트에 요약이 있었지만, (확실히) 지금은 요약이 없다는 것을 알 수 있을 것이다. (나는 추측하고 있지만, 나는 긴 확률을 줄 것이다) (a) 이것은 많은 작업이다. (b) 논란이 되는 주제에 대한 토론을 요약한다(그리고 AN/I에서 논의되는 대부분의 주제는 아마도 토론이다)al) 정확하고 공정한 방식으로, (그리고 사람들은 여전히 반대할 것이다), 그리고 (c) 관련된 일의 양과 공정성과 정확성의 문제를 고려하면, 위키피디아에게 대신 다른 일을 하는 것은 확실히 덜 스트레스고 꽤 유용하다. -- 존 브로턴 (UTC) 2008년 8월 11일 (UTC)[응답]

SVG 템플릿 제품군에서 새 리디렉션 만들기

최근에 템플릿을 살펴본 경우:WillBeSVG/doc, 나는 갑자기 내가 경우에 따라 잘못 이미지를 플래그업하고 있다는 것을 깨달았다.즉, 나는 그 코드를 사용해 왔다.{{SVG icon}}http://en.wikipedia.org과 http://commons.wikimedia.org에서 이미지에 플래그를 지정하는 경우.올바른 범주는 이전된 것이 아니다.icon그렇지만symbol추가 조사 결과, 위키피디아와 하원에서 상당히 많은 이미지들이 플래그로 작성되었고, 그래서 이제 자동으로 만들어진 두 페이지가 있다. 카테고리:SVG 형식 및 공통 형식이어야 하는 아이콘 이미지:범주:벡터 그래픽을 사용해야 하는 아이콘 이미지, 이러한 범주가 범주에 나타나지 않기 때문에 대부분 전혀 눈에 띄지 않게 될 이미지:SVG 형식 및 공통 이미지:범주:벡터 그래픽을 사용해야 하는 이미지.따라서 나의 잘못을 바로잡고 그러한 실수가 앞으로 문제가 되는 것을 막기 위해서는 그럴 수 있을 것이다.{{SVG icon}}로 자동 전환되도록 되어 있다{{SVG symbol}}그리고 그 이미지들은 로 플래그가 붙여졌다.{{SVG icon}}카테고리:SVG 형식 또는 공통 형식이어야 하는 기호 이미지:범주:{{ConvertoSVG}}자체가 {{ShouldBe로 리디렉션되는 것처럼 벡터 그래픽을 사용해야 하는 기호 이미지SVG}}?여기 나야 (토크) 18:45, 2008년 8월 10일 (UTC)[응답]

템플릿 변경에 도움이 필요하면 WP:RT는 WP가 아닌 올바른 장소다.VPP. -- John Brownon (식용차) 16:04, 2008년 8월 11일 (UTC)[응답]

감사합니다, 다시 게시(이 페이지는 WP라고 믿지만):VPR ;) )It Is Me Here (토크) 2008년 8월 11일 19:39 (UTC)[응답하라]