위키백과:마을 펌프(제안)/아카이브 16
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
실시간(실시간) 메시징 시스템
궁금해서, 위키미디아는 왜 "실시간" 메시징 시스템을 만들지 않았을까?즉, 위키백과 페이지를 새로 고칠 필요가 없는 사람의 메시지를 실시간으로 주고받는 것을 의미한다.이것은 확실히 위키피디아를 훨씬 더 원활하게 운영할 수 있게 만들 것이며, 최소한 위키피디아 소프트웨어, 기간을 수정하는 것 이상 어렵지 않게 할 것이다.두 편집자가 같은 페이지에서 대담한 편집을 할 때는 특히 짜증난다.첫 번째가 편집을 한다.두 번째 사람은 "분쟁 편집"을 보고 나서 그들이 한 몇 분간의 타이핑이 헛수고였다는 것을 깨닫는다.실시간 메시징 시스템은 편집자들이 실시간으로 서로 관여할 수 있기 때문에 이 문제를 다룰 것이다.
IRC를 이용하면 된다는 건 알지만, 우리가 편집하는 모든 다른 기사들에 대한 모든 편집자들을 IRC에 올리게 하는 것은 어려울 수 있고, 그들 중 일부는 그것 때문에 혼란스러울 수도 있다.위의 제안은 상관없이 더 강한 공동체를 촉진할 것이다.게다가, 위키피디아와 IRC에 로그인해야 하는 것은 지루하다.위키미디아가 운영하는 모든 위키에 대해 별도의 계정이 필요하다는 것은 이미 충분히 나쁜 일이다.젠왓 (토크) 04:15, 2008년 1월 7일 (UTC)[
- 이것을 시행하는 것은 그리 어렵지 않을 것이다.그렇다면 어려운 것은 그런 것들을 제대로 로그에 기록하는 것이다.내 말은, 이런 대화들을 어떤 페이지에 올릴지 어떻게 결정하지? -아마코브무! 05:57, 2008년 1월 7일 (UTC)[하라
- 편집자들이 전체 기사가 아닌 기사들의 별도 섹션을 편집하는 경우, 편집 충돌은 훨씬 드물다.매우 활동적인 기사의 경우, 편집을 위해 몇 분 정도 걸리는 것은 일반적으로 실수다.그리고 편집 충돌이 있을 때, 편집이 "실수로 끝났다"는 것은 전혀 사실이 아니다; "뒤로" 화살표를 누르면 편집 상자로 돌아간다; 만약 텍스트를 추가하고 있다면, 새 창을 열고, 기사로 돌아가, 그 텍스트를 추가하면 된다(두 편집자가 같은 기사에 정확히 같은 일을 하고 있을 가능성은 거의 없다).시간, 그리고 만약 그렇다면, 둘 중 하나는 허무하게 실시간 통신을 편집하고 있는 것이다.
등각:코드의 작동 방식(서버 쪽 대 클라이언트 쪽)을 오해하는 것 같아, 그런 프로그램이 실시간 알림을 제공하기 위해 위키백과 같은 "자동으로 수정"하는 것과 같은 것을 수반할 것이라고 생각함으로써 시스템에 대한 부담을 과장하는 것이다.그런 시스템은 필요 없다.작동 방법에 대한 구체적인 예: 플래시 모듈은 클라이언트 측에서 지속적으로 실행될 수 있으며, 메시지가 전송될 때마다 서버는 해당 모듈 알림을 전송하여 서버에 대한 추가 부담 없이 실시간으로 사용자에게 통지한다.
John Brown: 라이브 알림은 위키피디아를 소셜 네트워킹 사이트로 만들기 위한 것이 아니다. 단지 사용자들이 편집하는 동안 메시지를 더 빨리 알림으로써 의사소통을 용이하게 하기 위한 것이다.지메일은 '소셜네트워크 사이트'는 아니지만 효율적인 업무처리 방법이라는 이유만으로 여전히 메시지를 생중계하고 있다.
존 나글:IRC의 한계도 지적돼 왔다.젠왓(토크) 23:50, 2008년 1월 7일 (UTC)[
- 나는 전혀 오해하지 않는다.나는 서버 쪽 코드와 클라이언트 쪽 코드에 대해 모두 알고 있고 자동 새로 고침을 제안하지 않았다.나는 새로운 토크 페이지 포스팅을 받았을 때 서버가 모든 사람에게 보내야 할 메시지를 언급하고 있었다.그것들은 서버에 부담을 줄 것이고, 그것이 제공하는 작은 이익의 가치가 없는 것을 야기할 것이다.또한 플래시 의존은 접근성 문제가 될 것이다.Equazcion •properties/C • 06:01, 2008년 1월 8일(UTC)
- 왜 더 큰 부담이 될까?내가 너를 정확히 이해했는지 보자.현재 상태로는, 누군가의 브라우저가 위키백과 기사를 요청할 때마다, 서버는 "새로운 메시지를 확인"한다.만약 있다면, 당신은 기사 내용을 받았을 때 화면에 "새로운 메시지"라는 메시지를 받게 된다.이것은 당신이 얼마나 많은 메시지를 가지고 있는지에 상관없이 사실이다: 만약 당신이 AFK에 있는 동안 누군가가 당신에게 연속해서 10개의 메시지를 보낸다면, 당신이 위키피디아로 돌아오면, 서버는 오직 한 번만 알고리즘을 실행한다. 왜냐하면 그것은 페이지 요청이 있을 때 실행되기 때문이다. 그리고 당신이 한 번만 새로 고쳤기 때문이다.실시간 메시징 시스템 하에서, 서버는 메시지가 발행될 때마다 클라이언트에 메시지를 발송할 것이다.그래?
- 나는 그것이 그렇게 많은 자원을 차지할 것이라고 생각하지 않는다.위키피디아가 그렇게 걱정했다면, 우리는 봇들이 입력하고 포용론자들 이외에는 아무도 신경 쓰지 않는 어리석고 모호한 지리적, 음악적 디렉토리 항목을 일괄 삭제함으로써 재정 문제를 도울 수 있을 것이다.내가 들은 바로는 위키미디아는 재정적으로 어려움을 겪지 않는다(적어도 웹사이트를 지원하지 않기 위해서).어떤 추가 비용도 이득보다 더 큰 것 같다.
- 현재 시스템에서는, 당신이 당신의 토크 페이지에 새로운 포스팅을 받을 때, 데이터베이스 플래그가 설정된다.사용자가 위키백과 페이지를 로드하면 해당 플래그가 확인된다.그것은 완전히 수동적인 시스템이다.당신이 제안하는 시스템은 서버가 새로운 포스팅이 있을 때마다 실시간 메시지를 보내도록 요구하는데, 이것은 서버에 대한 능동적인(수동적이지 않은) 행동이다.서버 측에서 수동적으로 유지하기 위해 클라이언트는 일정한 간격으로 기존 플래그를 계속 확인할 수 있었지만, 그것 역시 서버에 추가적인 부담을 줄 것이다.플래시 외에 다른 가능성은 아약스인데, 그것은 자바스크립트를 광범위하게 활용하기 때문에 여전히 접근성이 문제가 되고 있고 자바도 마찬가지일 것이다.Equazcion •1999/C • 2008년 1월 8일(UTC)
- 에카즈시온, 한 가지를 더 고려해야 하지만, 내 제안은 또한 편집 충돌의 양을 줄여 자원도 절약할 수 있다.그렇다, 그것은 클라이언트가 페이지 요청을 할 때만 체크되는 수동 기록을 유지하는 것보다 메시지를 능동적으로 발송하기 위해 더 많은 자원을 사용한다.그러나, 만약 편집자들이 실시간으로 의사소통을 할 수 있다면, 그들은 더 효과적으로 실시간 협업을 할 수 있다.이것이 IRC의 정당성이지만, 언급된 것처럼 IRC에는 한계가 있다.그리고 다시 한번, 나는 짐보가 위키피디아의 최소한의 비용이기 때문에 위키피디아가 웹사이트를 지원하기 위해 애쓰는 것이 아니라는 것을 과거에 분명히 했다고 생각했다. 그래서 "우리는 자원을 절약해야 한다"는 것이 유효한 주장처럼 보이지 않는다.젠왓 (토크) 22:35, 2008년 1월 8일 (UTC)[
- 나는 합리적인 지식을 가진 웹 개발자다.플래시는 추하고 독점적인 자바 애플릿도 마찬가지로 나쁘다. 둘 다 좋은 구현을 만들어내지 못할 것이다.당신이 제안하는 것은 JavaScript로 만들어질 수 있다(프로그램화 참조). 또는 Comet (프로그래밍화)는 일부 서버측 코드와 결합될 수 있다. 그러나 그것은 기술적으로 매우 복잡하다. 많은 JavaScript가 작성되어야 할 필요가 있을 것이다(대부분 상당히 불쾌하다), 그것은 서버에 엄청난 히트가 될 것이다.웹 서버에 추가 연결의 ousands)을 참조하십시오. 일반적으로 추하다.그러한 것의 단점과 복잡성은 어떤 장점보다 훨씬 더 클 것이다. 이것이 마이스페이스나 페이스북과 같은 사이트들도 그것을 하지 않는 중요한 이유다.
- 나는 그것이 일어나는 것을 볼 수 없지만 네가 원한다면 미디어위키에 그것을 구현해봐라.또한, 나는 충돌 편집이 자원에 많은 영향을 미치는지, 자주 사용되지 않는 페이지도 아닌지에 대해 의심한다. 대역폭과 처리 시간이 비싸기 때문이다.게다가, IRC에 대한 "명분화"는 없다 - 위키미디어의 서버에서 호스팅되지 않고 위키백과와는 독립적으로 운영된다. -할로 (토크) 18:21, 2008년 1월 12일 (UTC)[
위키피디아의 정확성을 평가하려면 통계를 수집하고 발표하십시오.
위키피디아의 정확성을 평가하기 위해, 특히 위키피디아를 돕기 위해:Wiki Project 시스템 편향 방지:위키백과 편집에 대한 통계는 공개되어야 한다.외부의 비판은 환영받기 때문에(사실, 유익한) 이러한 통계를 발표하면 연구자들이 위키백과가 어떻게 작동하는지 더 잘 이해할 수 있게 될 것이다.비록 그들이 직접 그것들을 모을 수는 있지만, 그들은 먼저 그들의 계정을 봇으로 확립할 필요가 있을 것이다.그러한 요청은 이루어지지 않았으며, 위키피디아의 편집에 대한 심층적인 검토가 이루어진 적이 없다는 확신으로 이어졌다.게다가, 이러한 통계를 발표하면 통계 분석을 이용하여 위키백과를 연구할 동기가 될 것이다.
몇 가지 기본적인 예:
- 편집-경쟁이 아닌 협업 정도를 대략적으로 측정하여 평균 사용자 수에 비례한 기사 편집 평균 횟수 측정
- 특정 과목의 평균 편집량 측정
- WP에 나열된 사항:다른 모든 것에 대한 체계적 편견
- 프린지 이론은 WP에 열거된 것 외에 전반적으로 다음과 같다.다른 모든 것에 비해 시스템 편향
- 일반 과목 전체
- 고급 주제와 관련된 기본 주제
- 대부분의 사용자가 광범위한 기사에 초점을 맞추는지 아니면 소수의 기사에 초점을 맞추는지 여부
- 정책 위반으로 인해 사용자가 금지되는 데 걸리는 평균 시간 및 블록 양
추세를 측정하는 것은 개인적인 의견에 기초하여 "글쎄, 나는 정책이 있어야 한다고 생각해..."라는 일반적인 것이 아니라, 특정 위키백과 정책의 효과에 대한 경험적 지표를 줄 수 있다.
위키피디아를 위해 일하는 훌륭한 봇 프로그래머라면 누구나 이것을 할 수 있고, 수학 참조 데스크에 있는 사람들은 상관관계를 끌어낼 수 있다.통계학 101을 본 나 자신도 상관관계를 제공할 수 있는 원시 데이터를 가지고 있었다.젠왓 (토크) 01:47, 2008년 1월 12일 (UTC)[
- 위키마니아에서 종종 제시되는 위키백과 통계 작업이 어느 정도 있었는데, 그 논문과 프리젠테이션을 검색해 볼 수 있는지 알아보세요. :-)
- 나는 내가 말하는 것을 가능한 한 확실한 통계적 근거에 기초하려고 노력하지만, 항상 모든 것에 대한 통계를 가지고 있는 것은 아니며, 대신 추론, 추론, 또는 직관에 의존해야 한다.(그러나 몇몇 사람들이 추측하는 것처럼 전형적으로 내 개인적인 견해에 의존하는 것은 아니다.
- 이 일에 봇을 사용하는 것은 어리석은 일일 것이다.대신, 위키백과 데이터베이스 덤프를 다운로드하고, SQL을 사용하여 무거운 리프팅 작업을 하십시오.그 이후에는 통계자료 101을 숫자에 적용하기만 하면 된다.이 방법을 사용하면 표본 크기가 전체 모집단 크기(= N 가 된다.이것은 여러분이 더 간단한 공식을 사용할 수 있고 매우 정확한 결과를 얻을 수 있다는 것을 의미하지만, 많은 통계 공식들이 여러분이 단지 더 큰 모집단에서 부분적인 표본을 추출하고 있다고 가정하기 때문에 주의할 필요가 있다.
- 일부 사람들이 사용하는 다른 접근법은 대표 샘플을 손으로 골라 그 샘플에 대한 통계를 사용하는 것이다.일반적인 표본 크기는 50-100페이지가 될 수 있다.이것은 훨씬 덜 정확하고 편향될 가능성이 있다.하지만 그것이 통계가 발명된 이유지요?
- 결과를 잘 읽어주길 바란다! --김브루닝 (토크) 02:57, 2008년 1월 12일 (UTC)[
- 위키피디아는 몇 기가바이트를 차지하며 이러한 데이터 덤프에 대한 서버의 대역폭 제한은 무엇인가?또한, 나는 프로그래머가 아니기 때문에 그것을 분석하기 위한 프로그램을 쓸 수 없을 것이다.데이터가 스프레드시트에 있어야 하는데젠왓(토크) 05:41, 2008년 1월 12일 (UTC)[
- 사용자 페이지와 토크 페이지를 포함하는 "모든 페이지, 현재 버전만"의 가장 최근의 덤프는 5.9GB로, bzip2 형식으로 압축된다."전체 페이지 편집 내역이 있는 모든 페이지" 덤프는 현재 2008-02-26의 ETA로 실행 중이다.http://download.wikimedia.org/enwiki/20080103/에서 다운로드 할 수 있다.Mr.Z-man 05:55, 2008년 1월 12일 (UTC)[
- MySQL 데이터베이스에 가져올 때 약 35-40GB까지 작동한다. --Carnildo (talk) 06:30, 2008년 1월 12일 (UTC)[
- 사용자 페이지와 토크 페이지를 포함하는 "모든 페이지, 현재 버전만"의 가장 최근의 덤프는 5.9GB로, bzip2 형식으로 압축된다."전체 페이지 편집 내역이 있는 모든 페이지" 덤프는 현재 2008-02-26의 ETA로 실행 중이다.http://download.wikimedia.org/enwiki/20080103/에서 다운로드 할 수 있다.Mr.Z-man 05:55, 2008년 1월 12일 (UTC)[
- 위키피디아는 몇 기가바이트를 차지하며 이러한 데이터 덤프에 대한 서버의 대역폭 제한은 무엇인가?또한, 나는 프로그래머가 아니기 때문에 그것을 분석하기 위한 프로그램을 쓸 수 없을 것이다.데이터가 스프레드시트에 있어야 하는데젠왓(토크) 05:41, 2008년 1월 12일 (UTC)[
사실, 여러분이 순하게 총명하고 논리가 그리 끔찍하지 않다면, 여러분은 아마도 책과 기계를 가지고 앉아서 비 오는 주말에 여러분의 스프레드시트를 위한 좋은 번호를 이미 얻을 수 있을 만큼 충분한 SQL을 배울 수 있을 것이다. --Kim Browning (토크) 07:27, 2008년 1월 12일 (UTC) 비교를 위해: 나무 밑에 앉아 그늘을 즐기다가 화창한 여름 오후에 배웠어. :-)[
누가 통계가 계산되고 공개되는 것에 문제가 있을지는 의문이지만, 나는 당신이 기대해서는 안 된다고 생각하지만, 나는 당신이 다른 사람들이 당신을 위해 기술적인 일을 하도록 할 수 있을 것이라고 생각하지 않는다.나는 단지 "다른 사람이 나를 위해 기술적인 일을 해주었으면 좋겠다"는 것이 여기서 일을 성사시키는 일이라고 생각하지 않는다. 특히 기술적인 일은 대개 가장 지루하고 복잡한 부분이기 때문이다.예를 들어, 2005년 이후 소수민족이 구축하려고 오랫동안 제안해 온 사용자 조사를 보십시오.그들의 성공 부족은 기술 일을 스스로 하고 싶어하지 않는 것, 개발자들을 공짜로 일하게 하는 것, 주제에 충분한 관심을 가질 수 있는 사람들을 얻을 수 없는 것, 그리고 내 생각에, 그들이 어떤 특정한 사람들에게 호의도 베풀지 않는 것에 대한 오만과 태도 등이 복합적으로 작용했기 때문이다.앞에서 제시한 바와 같이 데이터베이스 덤프를 다운로드하여 MySQL에 넣고 직접 SQL을 하는 것이 최선책이다. -할로 (토크) 16:08, 2008년 1월 12일 (UTC)[
- 위키백과 커뮤니티가 도움이 되어줘서 고마워."만약 당신이 순하게 총명하고 논리에 너무 소름끼치지 않는다면" - 내가 거기서 빈정거림의 존재를 감지할 수 있을까?나는 프로그래머는 아니지만, 위키백과 프로젝트에 관심이 있고 내가 좋아하지 않는 편집자들의 관점을 억압하는 것만이 아니라, 이 프로젝트를 나의 주요 목표 중 하나로 만들 작정이다.위키피디아의 봇 수를 보고 WP:전문가의 반란, 위키피디아가 일을 하겠다고 나선 전문직 종사자들의 가뭄을 겪고 있다는 것이 내게는 그렇게 확실한 것은 아니다.그들이 떠난 것은 네가 지금 나를 대하는 방식대로 적의를 가지고 대했기 때문이다.젠왓(토크) 00:31, 2008년 1월 13일 (UTC)[
새로운 보관 제안서
여기에 페이지를 보관하는 새로운 방법에 대한 아이디어가 있다. 사용자:Mbisanz/ArchiveSpace 및 다른 사용자의 생각을 테스트한 후 버그질라 또는 프로젝트-스페이스 페이지를 작성하십시오.MBisanz 02:35, 2008년 1월 12일 (UTC)[
- 나는 이 제안이 마음에 들지 않는다 - 나는 중요한 이점이 거의 없고, 중요한 기술적 작업이 필요하며, 제안된 링크 레이아웃이 상당히 보기 흉하며, 나는 이 문제를 수정해야 할 정도로 크게 생각하지 않는다.또한 새로운 네임스페이스(즉, 테이블 네임스페이스)를 만드는 것에 대해 상당한 반대가 있을 것이다.더 좋은 방법은 형편없는 검색 엔진을 개선하는 것이다.
- 혹시 모를 경우, 현 단계에서 여론조사를 만드는 것은 나쁜 형태라고 여겨지고, 이와 같은 정책이 일반적으로 이행되는 방식도 아니다. -할로(토크) 16:21, 2008년 1월 12일 (UTC)[
- 미안, 내가 다른 제안서들에서 봤던 것들로부터 벗어나고 있었어.그래, 나도 알아, 테이블 네임스페이스를 보았고 테이블 네임스페이스를 마주한 반대파에 실망했어.또 다른 아이디어는 일반적인 검색에서 제외를 위해 보관 페이지에 태그를 지정하는 방법이다(즉, "보관된 페이지 포함"이라고 쓰여 있는 검색 버튼).MBisanz 04:01, 2008년 1월 13일 (UTC)[
반달 처리
나는 오히려 사용자 206.82.17.190이 걱정된다.내가 2007년 12월에 알게 된 이 사용자는 이 글에서 많은 사람들이 했던 좋은 일을 "노화는 늙었을 때 얻는 것이다"라는 단 하나의 문장으로 대체함으로써 노화에 관한 페이지를 파손시켰고, 이 사용자가 하는 다른 기여들을 보면 이 사용자는 위키피디아를 파괴하기를 열망하고 있는 것 같다.이런 편집과 같은 사용자들을 막을 방법이 있을까? - 미안, 반달리즘 - 위키백과?ACEOREVIVEED (토크) 22:05, 2008년 1월 12일 (UTC)[
- 사용자:206.82.17.190은 현재 14일까지 차단되어 있다.WP 참조:일반 반달리즘 정책에 대한 반달. 131.111.8.96 (대화) 23:24, 2008년 1월 12일 (UTC)[
모든 아티클에 대한 조회수
안녕, 유튜브처럼 기사마다 조회 수를 보여줄 계획이야?고마워, Adrian Comollo (talk) 20:49, 2008년 1월 13일 (UTC)[
- 성능상의 이유로 개별 페이지 통계가 해제된다.위키피디아가 있었다.인기 페이지지만 비활성 페이지.그리고 이달 중 가장 많이 방문한 위키피디아 페이지를 나열하는 외부 페이지가 있지만, 정확히 당신이 찾고 있는 것은 아니다. -- 레이브루조 (토크) 21:17, 2008년 1월 13일 (UTC)[
새로운 CSD 제안
커뮤니티에 새로운 제안을 알리기 위한 교차 게시.위키백과에서 진행되는 토론:신속한 삭제 기준#새로운 기준 제안. - Rjd0060 (대화) 02:55, 2008년 1월 14일 (UTC)[
현재 이벤트 하위 포트
대부분의 Current 이벤트 하위 포트에 대한 토론이 Miscellany에서 삭제하기 위해 열렸다.당신은 이 하위 포탈의 운명에 대해 토론하는 데 참여하도록 초대받았다.나는 현재 알고 있는 것보다 더 많은 사람들에게 이것에 대해 알려야 한다고 생각했고, 따라서 부사장에게 알려야 한다고 생각했다. --DJ (대화 • 기여) 17:38, 2008년 1월 13일 (UTC)[
달러 대 유로
(영어) 유로 기사의 인용:
그것은 3억 2천만 명이 넘는 유럽인들을 위한 단일 통화다.유로화에 고정된 통화를 사용하는 지역을 포함하면, 유로화는 전 세계 4억 8천만 명 이상의 사람들에게 직접적으로 영향을 미친다.2006년 12월 현재 6,100억 유로(당시 환율로 환산하면 8,020억 달러에 상당함)가 유통되고 있는 유로화는 미국 달러를 넘어서는 등 유통 중인 현금가치가 세계에서 가장 높은 통화다.
통화 가치(예: GDP 기사)를 말할 때 달러를 사용하는 기사가 많은데, 심지어 지역 페이지(비영문)도 달러를 사용한다.
위의 인용구를 고려하면, 유로화가 유통되는 가장 큰 통화인 만큼 유로화가 아니어야 하는가?
그렇지 않다면, 유로화를 사용하는 나라들은 어떨까; 그들의 지역 페이지는 유로화를 사용해서는 안 되는가?NitroX Infinity (talk) 10:11, 2007년 12월 27일 (UTC)[하라
- 유로를 사용하는 IMO 국가들은 예를 들어 유로화와 달러로 GDP의 가치를 가져야 한다.사실은 그러한 수치를 위해 달러를 사용하는 것이 세계적인 표준 관행이며, 또한 유로존의 국가들에도 해당한다는 것이다.대부분의 생필품은 여전히 달러화로 거래되고 있기 때문이라고 생각하지만, 어떤 이유에서든, 나는 우리가 쓰레기 처리와 미디어에서 가장 흔히 사용되는 것을 지켜야 한다고 생각한다.마르틴 회크스트라 (대화) 2007년 12월 27일 (UTC) 10:16[
고마워, 푸그제트. 날 여기 지목해줘서 고마워. 그리고 테라토르니스, 통화에 대한 네 노트를 읽었어.나는 자국 통화를 사용하는 곳이 아닌 한 오늘날 가장 강력한 통화로서의 위치를 감안할 때 표준으로서의 유로로의 이동을 지지한다는 점을 덧붙이고 싶다.사람들이 달러로 사물을 보는 것에 익숙해졌거나 그렇게 하는 것이 현재 진행 중인 관행이라는 사실은 중요하지 않다 - 미터법이 제안되었을 때와 오늘날 몇 가지 예외를 제외하고, 그것은 선택의 시스템이다.또한 1달러는 미국, 호주, 캐나다에서 짐바브웨에 이르는 모든 것에 비해 유로화는 유로다.마지막으로 유로는 27개 정도의 국가를 대표하고, USD는 1개국을 대표한다.
안녕, --Rui "Gabriel" Coreia (토크) 07:51, 2008년 1월 3일 (UTC)[
- 위키피디아의 목표는 세상을 묘사하는 것이지, 세상을 바꾸는 것이 아니다.유로화가 가격을 기술하는 주요 통화가 될 때 유로화로 바꾸겠다. --카닐도 (토크) 08:32, 2008년 1월 3일 (UTC)[
- 아마도 숫자의 출처에 의존하게 하는 것이 최선일 것이다.만약 그 출처가 달러라면 (미국) 달러를 사용하고, 유로화를 말하고, 남아프리카 랜드에 대해 말한다면 (그리고 사람들이 얼마의 가치가 있는지를 추정할 수 있도록) 남아프리카 랜드(남아프리카 랜드)를 사용한다.유로화나 달러를 계산하는 것은 위험하다. 이러한 요금은 요즘 빠르게 변하는 경향이 있기 때문이다.effeetsanders 10:10, 2008년 1월 3일 (UTC)[
- 지금까지 액수가 미국 달러로 디폴트 된 데는 이유가 있다.위키피디아는 근본적으로 미국의 제도다.그것은 미국에서 한 미국인에 의해 시작되었고 현재 미국 단체에 의해 운영되고 있다.우리는 미국 법에 의해 지배되고, 우리의 문서는 미국어와 철자를 사용한다.기사들이 출처에 인용된 화폐단위를 사용해야 한다는 데는 동의했지만, 의심스러울 때, 나는 그 당시 가장 강력한 화폐단위를 사용한다는 논리가 없다고 본다.물론, EN 위키피디아가 미국인과 마찬가지로 영국인으로 간주되어야 한다는 주장이 제기될 수 있지만, 결국 나는 그렇게 생각하지 않는다.Equazcion •1999/C • 2008년 1월 3일(UTC)
- 위키백과의 대부분의 버전이 미국인들이 사용하지 않는 언어로 되어 있다는 것은 단지 운이 좋지 않은 일이다. :P 그리고 현재 위키미디어 재단 이사회의 대다수는 유럽출신이다.위키미디어 재단이 미국에 위치한 역사적(그리고 아마도 다른) 이유들을 위한 것이기는 하지만, 그것은 세계적으로 넓은 재단이다.모든 편집자는 자신의 법에 복종해야 하기 때문에 위키피디아가 적용되는 법은 단 한 가지도 없다.(참고: 위키백과와 영어 위키백과의 차이점)나는 생각한다.wikipedia.org은 영국, 미국, 캐나다, 호주, 중국, 네덜란드 또는 남극대륙이 아닌 중립적인 것으로 간주되어야 한다.특히 내용에 관해서는 중립적이어야 한다.우리 모두 위키피디아와 그것에 동의했다고 생각한다.중립적인 관점?하지만, 우리의 위치가 위키피디아를 보는 방법에 영향을 미친다는 것을 명심하십시오.당신같은 미국인은 위키피디아를 미국프로젝트로 더 쉽게 볼 수도 있고 나같은 네덜란드인은 2008년 1월 3일 12:41, 3일 (UTC)[
- 오, 나는 그것이 가능한 모든 곳에서 중립이 되어야 한다는 것에 전적으로 동의하지만, 중립은 이 경우 선택사항이 아니다.우리가 새로운 화폐단위를 발명하지 않는 한, 선택이 필요하다.위키피디아의 데이터베이스 서버는 (내가 아는 바로는) 미국에 위치해 있고 미국 법률의 적용을 받는다. 게다가, EN 버전은 문서화, 인터페이스, 초기, 그리고 기사가 지금까지 디폴트된 방식과 같은 다른 증거에 의해 미국 법인이다.. 만일 위키피디아가 원래 유럽인이었다면 우리는 지금 우리가 보고 있는 것과 매우 다른 것을 보게 될 것이고(예, EN 버전에서), 나는 처음부터 그랬을 것처럼 유로를 기본 단위로 유지하는 것에 반대하지 않을 것이다.그러나 현재 상태로는 유로화로 바꾸는 것에 대해 어떤 주장이 나올 수 있을지는 확실치 않지만(디폴트로서) 현재 보다 강력한 통화 단위라는 사실만이 이유라면, 나는 그것이 좋은 이유는 아니라고 말한다.Equazcion •2011/C • 2008년 1월 3일(UTC)
- 그런데 왜 통화가 아예 디폴트 되는 겁니까?환율만 안정된다면...물론, 우리가 미국 달러에 대한 비율이 고정된 남미 국가들에 대해 말할 때, 미국 달러를 언급하는 것은 나에게 문제가 되지 않는다.또는 미국 달러에 대해 통화가 매우 안정되어 있다면(예: 캐나다 달러에 대해 나는 이것을 예상한다.그러나 슬로바키아, 체코, 라트비아 등과 같은 특정 유럽 국가들에 갈 때도 비슷한 상황이 떠오른다.나는 유로화에 대해 그들의 통화가 매우 안정되어 있다고 상상할 수 있어, 유로화를 언급하는 것은 논리적인 접근일 것이다.그러나 유로화나 미국 달러화에 대해 어느 쪽도 안정적이지 않은 통화에 관한 것이라면 그냥 놔두고, 어느 쪽도 언급하지 마라.지금 당장 가치를 언급한다면, 다음 주에는 그 비율이 많이 바뀌었기 때문에 가치가 없다.현재 가치를 달러와 유로화로 자동 계산하는 도구는 여기에서도 유용할 것이다.그러나 그것은 요점을 벗어난다.나는 개인적으로 쉽기 전에 정확성을 선호하기 때문에 의심스럽다면 당신이 제안하는 대로 달러를 사용하지 말고 둘 다 사용하지 마십시오.
- 만약 당신이 다른 나라들의 가치들을 서로 비교하고 있다면, 그래 나는 공통 통화의 필요성이 있다는 것에 동의한다.중립적인 것이 더 좋겠지만, 네 말이 맞아. 아무것도 없어.나는 그 경우에 유로화와 미국 달러 둘 다 사용할 것을 제안할 것이다.대부분의 경우 이것은 어차피 테이블에 있을 것이기 때문에 테이블에 다른 열만 추가해도 그리 큰 문제가 되지 않을 것이다.effeetsanders 13:10, 2008년 1월 3일 (UTC)[
- "기본값"은 출처에서 하나의 명확한 통화가 사용되는 통화를 변경하는 것을 의미하지는 않는다.그것은 단지 여러 통화 중에서 선택할 수 있는 경우를 위한 것일 뿐이다.이것은 영어 위키백과이기 때문에, 나는 그 디폴트(채무불이행)가 무엇이어야 하는지에 대한 어떠한 의문도 보이지 않는다.다른 언어 버전은 자국 통화를 디폴트로 사용할 수 있으며, 영어 기사는 우리의 (국어-영어-스피커) 자국 통화를 사용할 것이다.사실 나는 유로화보다 GBP를 사용하는 것이 더 나은 주장이 될 수 있다고 생각한다.Equazcion •1999/C • 2008년 1월 3일(UTC)
미국 달러와 유로화를 모두 기사에 넣는 것은 어리석은 일일 것이다. 계속해서 변동하는 환율로 인해 둘 중 하나 또는 다른 하나가 며칠 안에 끔찍하게 부정확해질 것이기 때문이다.소스 소재에 사용되는 동일한 단위를 사용하는 것이 가장 좋으며, 소스 소재가 여러 통화를 나열하는 경우, 해당 통화를 소스에 나열한 순서와 동일하게 모두 나열하십시오.Rdfox 76 (대화) 15:11, 2008년 1월 3일 (UTC)[
- 일반적으로, 나는 출처가 계산을 하기 위해 하나의 기본 통화를 사용한다고 생각한다.내 생각에는 여러 옵션이 있는 경우 하나를 사용해야 한다(예: 200개 옵션, 예, 하나 또는 두 개를 선택해야 한다).내가 상상할 수 있는 또 다른 기회는 만약 어떤 나라가 통화에 대해 고정된 환율을 가지고 있다면, 그 환율을 언급하는 것도 이치에 맞을 수 있다는 것이다.(즉, 미국 달러에 대해 고정된 금리를 가지는 남미 국가들 또는 유로존에 대해 고정된 금리를 가지는 유럽 국가들).내가 상상할 수 있는 또 다른 기회는 한 나라가 어느 시점에 통화를 바꿀 것인가 하는 것이다.그래, 그럼 2002년 전에 프랑스에도 유로라는 말을 했구나...(비교하면)여러 나라를 비교할 때 원천으로 사용되는 연구의 기초가 된 화폐를 사용해야 한다.나는 역사적 이유로 이 유언장이 대부분 미국 달러일 것으로 예상한다.그러나 예를 들어 2002년 이전의 스페인 연구소에서 파생된 것이라면, 그렇다, 그것은 페소 단위로 모두 비교될 수 있다! (그리고 물론 현재의 환율도 아닌 그 당시의 환율과 비교될 것이다) 2008년 1월 3일 (UTC) 20:18, 3일 (
- 예를 들어, {{dollars 33}}을(를) 추가하면 33달러(~€22)가 되고 환율이 변하면 반자동으로 업데이트되는 템플릿을 사용하는 것이 어떨까?교묘한 구문을 이용해 인플레이션까지 가려낼 수 있었다. -할로(토크) 00:35, 2008년 1월 11일 (UTC)[
우리는 한 가지 간단한 이유로 USD를 사용한다.그것은 세계가 경제적 비교를 위해 사용하는 것이다.통화의 장단점을 비교할 때 일반적으로 미국 달러와 비교된다.이는 <개념된 거시경제 추리 삽입>, 따라서 달러가 그 과제에 가장 적합한 후보이기 때문이다(경제학 수업에서 한 번 들은 기억이 나지만, 기억이 나지 않고, 세상이 그것을 사용하는 한 여기서는 중요하지 않다).또한, 스타일 매뉴얼에서 WP:$(달러 편중 바로 가기, 킥킥에 주목, 킥킥에 좋다)에 주목해야 한다.
따라서, 나는 이것이 해결되었다고 믿는다.--Vox Rappis (Talk 기여) 23:43, 2008년 1월 7일 (UTC)[
- 예를 들어, 달러를 다른 통화에 묶는 대부분의 나라들, 즉 달러를 다른 통화에 묶는 데프락토 세계 기준 통화인 USD는 일단 그것을 고수하라.그러나, 모든 것을 정정당당하게 유지하기 위해서, 몇몇 다른 주요 통화들의 환율을 포함하거나, 그것들을 쉽게 이용할 수 있게 하는 것은 어떨까?위키미디아는 합리적인 과거에 매 분기 또는 매월 환율의 페이지를 설정하고 향후 주간 또는 일별 가치를 유지할 수 있다.각 날짜 항목을 앵커 조각으로 표시하면 기사가 환율 페이지의 해당 날짜로 연결될 수 있다.2008년 1월 15일 / 2008/01/15 —서명되지 않은 의견을 210.8.170.141 (대화) 21:57, 2008년 1월 14일 (UTC)[
제안: 아티클 이름 지정 마법사
위키피디아에 마법사를 추가하여 새로운 기사 및 이동 기사(재명)에 대한 명명 규칙을 따르는 편집자에게 안내할 수 있는가? 또한 병합된 기사 및 분할 기사에 따른 기사도 가능한가?나는 다음과 같은 옵션으로 시작하는 일련의 메뉴를 염두에 두고 있다.
- 이 기사는 다음에 관한 것인가?
- 사람?
- 인간이 아닌 생물체?
- 추상적인 생각?
- 인간이 만든 기구?
- 연구 분야
- 인간의 일부분?
- 인간이 아닌 유기체의 일부분인가?
- 이벤트?
- 절차?
후속 메뉴는 기사의 유형을 더욱 미세하게 조정하고 편집자에게 다음과 같은 고려해야 할 사항의 체크리스트를 제시한다.
- 대문자, 하이픈, 미국 및 영국 영어 철자 차이, 분음부, 숫자 등.특정 유형의 기사에 어떤 구체적인 지침을 적용해야 하는지를 누군가는 결정할 수 있다.
이때 우리는 다음과 같은 기사명을 가지고 있다.
대문자화의 차이점에 유의하십시오.최근에 발리 코뮈니케를 발리 코뮈니케로 옮겼는데, 10만 년의 문제를 10만 년의 문제로 삼았다.(이역학, 하이픈#하이픈 콤팩트한 수식어, 제5항: "하이픈은 형용사 구를 형성하는 데 숫자와 단어를 연결하는 데 사용된다."위키백과도 있다:Style#Hypens 설명서, 섹션 3, 포인트 7)
이것은 그러한 프로그램이 무엇을 할 수 있는지에 대한 사전 계획에 불과하다.계획을 더 다듬는 데는 내가 쓴 것보다 더 많은 시간과 성찰이 필요할 것이다. -- 파장 (토크) 07:48, 2008년 1월 14일 (UTC)[
합의로서의 침묵
위키백과에서 새로운 에세이를 만들었다.합의서로서의 침묵 2008년 1월 14일 (UTC)[
- 좋은 지침이 될 거야많은 경우, 페이지 이동에 있어서, 어떤 사람도 언급할 수 없다.MBisanztalk 19:24, 2008년 1월 14일 (UTC)[
- 페이지 이동 중에 이 작업을 수행하십시오.댓글을 달면 일주일 동안 아무도 응답하지 않고, 어쨌든 움직인다.꽤 잘 된다.투복[/]T@lkImprove 2008년 1월 14일 (UTC) :29 [응답
- 이 방침은 이미 있는 거 아니에요?정족수가 생길 때까지 영원히 기다리라는 역이 어떻게 사실일 수 있을까?긴 스탠딩 정책은 과감하게 하는 것이다.페이지 이동도 논란이 되지 않는 한 기다릴 필요가 없다.귀청이 터질 듯한 침묵은 논쟁의 여지가 없는 것으로 해석되어야 한다.건배!Wassupwestcoast (토크) 21:06, 2008년 1월 14일 (UTC)[
- 페이지 이동 중에 이 작업을 수행하십시오.댓글을 달면 일주일 동안 아무도 응답하지 않고, 어쨌든 움직인다.꽤 잘 된다.투복[/]T@lkImprove 2008년 1월 14일 (UTC) :29 [응답
- 이것은 WP:CON을 넘어서기 위한 것인가?("본질적으로 침묵은 공동체에 대한 적절한 노출이 있는 경우 동의를 의미한다.정책 페이지의 경우 보다 높은 참여와 공감대가 예상된다.) 그리고 이 제안은 자기주장적인가? --보슨 (대화) 21:10, 2008년 1월 14일 (UTC)[
- 거기서 그 인용구를 받아 들였니?찾을 수 없듯이. 2008년 1월 14일 22시 4분 (UTC)[
- 두 번째 단락, 세 번째/네 번째 문장.대수학자 22:15, 2008년 1월 14일 (UTC)[
- 아, 있었구나, 찾는데 어려움이 있었어. 2008년 1월 14일(UTC) 22:21[
- 두 번째 단락, 세 번째/네 번째 문장.대수학자 22:15, 2008년 1월 14일 (UTC)[
- 거기서 그 인용구를 받아 들였니?찾을 수 없듯이. 2008년 1월 14일 22시 4분 (UTC)[
제안: 들어오는 링크 수와 아티클 크기의 상관 관계 조사
⑴ 일반적인 글의 줄 수와 ⑵ "여기에 있는 링크"를 클릭하면 나열된 링크 수 사이에 높은 상관관계가 있는 것으로 보이는 것을 알게 되었다."a"가 "b"에 영향을 미치거나 "b"가 "a" 또는 "c"(다른 변수)가 "a" 및/또는 "b"에 어느 정도 영향을 미치는지 모르겠다.또한, 기사의 행 유형(예: 본문, 발신 내부 링크, 외부 링크)뿐만 아니라, "여기에 나열된 링크 유형(예: 기사 페이지, 기사 토크 페이지, 사용자 토크 페이지)에도 어느 정도 의미가 있을 수 있다.(이 상관관계에 대한 나의 관심은 단편 기사의 확장을 돕기 위해 들어오는 내부 링크를 추가하는 나의 관심에서 시작되었다.)이러한 상관관계를 연구함으로써 얻는 이점이 비용을 능가하는가?또한 위키백과 통계에서 다른 변수 쌍의 구성원 간의 상관관계를 고려해 보십시오. -- 파장 (대화) 21:49, 2008년 1월 14일 (UTC) -- 파장 (대화) 19:06, 2008년 1월 18일 (UTC)[
대중문화 참고문헌을 숨기고 백과사전을 개선하자는 제안
각 기사의 '대중문화' 부분(특히 고전 주제, 문학, 의학, &c 등을 다루는 기사)은 독자의 청사진에서 숨겨야 한다는 것이 나의 제안이다.그 이유에 대해 많은 시간을 낭비할 수는 없지만, 그럼에도 불구하고, 나는 독자들의 호기심을 자극하기 위해 몇 가지 예를 보여줄 것이다.
- 1. 고대 로마 시인 카툴루스를 다룬 기사에서 나는 대중문화란 내에서 다음과 같은 대사를 읽을 수밖에 없었다:'웹툰 어치우드에 따르면 카툴루스는 뼈만 남은 최초의 시인이다.'-아아, 내 마음은 이제 돌이킬 수 없이 쓸모없고 바람직하지 않은 지식으로 가득 차 있다.
- 2. '물갈퀴 발가락'에 관한 기사에서, 나는 스탈린이 물갈퀴 발가락을 가졌을지도 모른다는 의심스러운 사실을 알고 있다. 실제로, Marge Simpson은 물갈퀴를 가졌을지도 모른다! — 정말 기쁘구나!진짜!
- 3. 죄와 벌에 관한 기사 : 나는 지금 '소프라노스 에피소드 또 다른 것'이라는 쓸데없는 지식으로 괴로워하고 있다.테렌스 윈터의 이쑤시개는 줄거리와 성격의 측면을 공유한다.'
리스트는 끝이 없어!제발, 날 위해서!대중문화를 사랑하는 당신들끼리의 합의에 도달하자!다음의 디자인은 완벽한 해결책이 될 것이다: 이 프랑스어 위키백과에 실린 이 글에는 페이지 하단에 'dérouler'라고 쓰여 있는 탭이 있다(풀고, unroll 한다).각 기사의 대중문화 부문(최소한 고전적, 문학적 주제)으로 이렇게 할 수 있다면, 위키피디아는 사실상 준존중 백과사전일 것이다. -- 그라마티쿠스 7세 (토크) 18:42, 2008년 1월 11일 (UTC)[
- 이 섹션에 대한 실제 정책에 대한 자세한 내용은 WP:TRIVIA를 참조하십시오.내가 선호하는 구현은 이 섹션이 자신이 속한 주제 또는 그들이 참조하는 자료에 대한 이해에 중요한 참조만을 다루고 적절히 참조될 수 있는 부분이다.물갈퀴 발가락에 대한 마지 심슨의 언급은 물갈퀴 발가락을 가진 인물의 매체에서 주요 등장인물이기 때문에 유용하게 들린다.반면 카툴루스가 언급하는 것은 두 가지 주제에 대해 거의 깊이를 추가하지 못하며, 범죄와 처벌 관계는 독창적인 연구로서 전혀 존재해서는 안 되는 것처럼 들린다.리나미시마 (토크) 2008년 1월 11일 (UTC) 19:08 [
- 위와 같이.어떤 경우에는 당신은 파라다이스 로스트->그의 암흑 물질과 같은 완전한 이해를 위해 대중문화 참조가 필요하다.2008년 1월 11일 (UTC) 20(talk):21 (
- 리나미시마, 문제의 사실은: 나는 마지 심슨에 대해 읽고 싶지 않다. 이런 성격의 인물은 당신의 표준 백과사전에 전시되지 않을 것이다.AD 2200년 (만사가 잘되면) 당신은 마지 심슨이 알려질 것이라고 믿는가?그것은 대단히 의심스럽다.카툴루스일까 도스토예프스키일까?그것은 확실히 더 가능성이 있다.
- 나는 시대를 초월한 주제가 50-60년 안에 이론의 여지 없이 사라질 밀도 높은 호이 폴로이 주제보다 더 많은 관심을 보장하고 더 많은 장점을 자랑한다고 믿는다.안타깝게도, 눈이 '마지 심슨', '대니 글로버', &c.라고 쓰여 있는 텍스트를 피하는 것은 불가능하며, 따라서, 나는 이 결점에 대한 해결책으로 이 가장 멋진 타협안을 제시했답니다!
- 나는 삼투가 삭제되어야 한다고 말하는 것이 아니다!아니, 아니! - 그냥 숨겨져 있을 뿐이야. (이것은 또한 행상들과 전문가들에게도 깊은 인상을 줄 것이기 때문에, 내가 장담하건대.
- 불행히도, 유명한 위키피디아는 대중문화로 인해 골머리를 앓고 있다.고전적인 주제에 집착하는 사람은 왜 이 역병의 공포를 겪어야 하는가?
- 문화적 언급은 백과사전적일 수 있다.I.E. "쇠고기 어딨어?"어떤 것이 관련성이 있는지 여부를 규정하는 정책을 정의하는 것은 매우 어렵다.실제로 대중문화에 관한 기사는 WP의 느슨한 시행으로 인해 통제할 수 없게 되었다.RS와 WP:V는 다른 방식으로 작용했지만 위키리티와 같은 관련 대중문화는 제거되었다.젠왓 (토크) 01:51, 2008년 1월 12일 (UTC)[
- 내 최초 제안서를 못 읽었니?당신은 프랑스어 위키피디아 링크를 관찰하고 그 후에 나의 간절한 의도를 표시하지 않았는가? (그것은 언급된 정보를 드롭다운 메뉴에 넣는 것이었다.)그럼에도 불구하고, 나는 더 이상 부주의한 게으름뱅이들을 설득하려고 노력하지 않을 것이다.네, 네...이것은 논쟁의 여지가 있다.—Grammaticus VII가 추가한 서명되지 않은 논평 준비 (토크 • 기여) 03:10, 2008년 1월 12일 (UTC)[
우리에게 정말로 필요한 것은 새로운 위키미디어 프로젝트, 즉 "위키 알루션"으로 옥스퍼드 얼루션 사전이나 메리암-웹스터 얼루션 사전과 견줄 만하지만 모든 문화적 주제를 다룰 수 있도록 범위가 확장된 것이다.물론 가장 관련성이 높은 암시는 기사에 남겠지만, 완전한 수집은 새 프로젝트에 있을 것이다.이는 위키피디아 기사에 모든 사람에게 과할 만한 인용구를 많이 수집하는 위키키코테의 발전과 비슷하다.--파로스 (토크) 03:46, 2008년 1월 12일 (UTC)[
- 오! 나는 그 아이디어가 마음에 들어.어디서 투표할 수 있을까? -- 풀스톱(토크) 15:59, 2008년 1월 12일 (UTC)[
- http://meta.wikimedia.org/wiki/Proposals_for_new_projects.—Random832 15:21, 2008년 1월 15일 (UTC)[
- 오! 나는 그 아이디어가 마음에 들어.어디서 투표할 수 있을까? -- 풀스톱(토크) 15:59, 2008년 1월 12일 (UTC)[
내용물 실험
필자는 논란의 소지가 있는 기사를 주로 다루는 편집자와 관리자와, 논란이 되는 기사에 대한 POV 밀기, 고기 인형과 양말 인형 등을 어떻게 다루어야 하는지에 대해 의견이 크게 엇갈리는 것으로 보인다.의학, 창조론 등 과학적 요소가 있는 주제에서는 특히 그렇다.
나는 우리가 6개월 혹은 그 이상과 같이 장기간에 걸쳐서, 거의 동일한 품질의 동일한 논란의 영역에 있는 두 개의 기사가 다르게 관리되는 일종의 시험을 고안해 볼 것을 제안한다.한 기사에는 다양한 종류의 '정규' 편집자와 NPOV 옹호자들이 편집에 나서지 않을 것이고, 특정 의제를 가진 이들이 마음대로 편집한 기사도 나온다.논쟁의 여지가 있는 NPOV 편집은 이 기사에서 되돌릴 수 없다.정규 편집자들은 대화 페이지의 내용에 대한 질의에 응답하는 것을 꺼릴 것이다.기본적으로 자유방임 정책이 채택될 것이다.
다른 기사는 NPOV가 복귀하는 등, 일반 편집자와 관리자가 순찰하는 등 정상적인 방식으로 관리될 것이다.
6개월이 지나면 두 기사와 6개월 동안의 이력이 외부 중립단체에 제출돼 심사를 받게 된다.6개월 동안의 기사의 질을 평가할 수 있었다.
이런 종류의 테스트는 우리가 우리의 시간을 낭비하고 있는지 아닌지를 단념시키는데 유용한 자료가 될 수 있고, 실제로 POV 편집을 방해하여 위키피디아에 나쁜 평판을 주었고, 그 과정에서 위키피디아의 평판을 해치고 있다.
댓글?---필(대화) 00:26, 2008년 1월 13일 (UTC)[
- 여러 가지 방법으로 여러 번에 걸쳐서 해봤다.보지도 않은 채 논쟁도 하지 않는 기사는 결국 0의 내용으로 끝나게 된다.DGG (대화) 00:56, 2008년 1월 13일 (UTC)[
사실이지만, 그것들은 실제로 통제된 실험이 아니었고 세심하게 평가되지 않았다.그리고 NPOV를 보호하는 것은 나쁜 일이고, 위키피디아에 나쁜 이름을 주고 나쁜 의지를 만들어 낸다는 것을 여러 편집자들로부터 몇 번이고 반복해서 들었다.나는 이것이 가능하다는 것을 너에게 인정하겠다.그리고 나는 기꺼이 그 가능성을 즐길 것이다.
최소한 수백 개의 트롤, 양말 인형, 고기 인형, POV 푸셔, 프린지 요소 등 수십 개의 트롤이 정기적으로 공격하는 기사라도 논란이 되는 기사에 대한 NPOV 편집을 다룰 때는 편집자들이 극도로 온화해야 한다는 주장이다.글쎄, 우리의 "스톰 트루퍼" 전술이 가치 있는 것보다 더 문제가 있다는 것을 인정할 것이다; 그것들은 숙련된 편집자와 관리자의 시간을 낭비하고, 갈등을 일으키고, 위키피디아 리뷰나 등록부를 방문함으로써 쉽게 알 수 있듯이, 이러한 행동은 나쁜 의지를 일으키고 위키피디아를 나쁘게 만든다.
그러므로 적어도 작은 방법으로 이러한 가정들을 시험해 보자.NPOV 기사를 가지려고 하는 것은 나쁜 일이고, 과학적인 POV를 믿는 사람들은 나쁜 일이고 위키백과가 얼마나 편향적이고 추악한 곳인지 보여주는 증거라는 말을 듣는 것에 싫증이 난다.그래서 이것을 조금 시험해 봅시다.왜? --필렐 (대화) 01:14, 2008년 1월 13일 (UTC)[
- 만약 가능하다면 나는 이 실험이 실행되는 것을 보고 가장 흥미로울 것이다.편집자들이 논쟁적인 기사들에 소비하는 시간과 에너지의 양은 엄청나야 한다.다른 접근방식은 이러한 노력의 많은 부분을 보다 생산적으로 사용할 수 있게 할 수 있다.Wanderer57 (대화) 17:03, 2008년 1월 15일 (UTC)[
나는 논쟁적인 기사로 어디서부터 시작해야 할지 모르겠다. 왜냐하면 나는 당분간 다른 모든 기사들이 계속 일하도록 노력해왔고, 그것들을 보기 시작할 시간도 없었기 때문이다.몇 가지 실험을 시작하는 것이 좋을 것이다. :-) --김브루닝 (대화) 22:32, 2008년 1월 15일 (UTC)[하라
WikiGlobe: 대체 인터페이스 제안
다음은 정보 통합, 조직, 그리고 가장 중요한 접근에 대한 내가 생각하는 고유한 접근법에 대한 개요다.위키백과와는 독립적으로 존재하지 않을 것이다.나는 대체적이고 직관적인 검색 엔진으로 가장 잘 생각되는 위키피디아의 기존 구조와 함께 작동하는 시나리오를 설명하기 위해 최선을 다했다.
지구본 구글 어스와 유사한 어떤 것의 협력(또는 적어도 라이선스)을 가진 이 "검색 엔진"의 핵심 요소는 우리 행성의 상호작용 모델일 것이다.사용자는 우리가 익숙해진 모든 공간적 측면에서 이러한 표현과 상호 접속할 수 있을 뿐만 아니라 추가적인 동적 요소가 있을 것이다.
시간 척도 이 지구본을 온라인 연구 또는 탐색에 일반적으로 사용하는 것과 구별하여, 슬라이더 형태의 조정 가능한 시간 척도로 사용자는 선택된 특정 기간처럼 지구본을 "보기"할 수 있다.
이 두 요소의 결합을 통해 사용자는 역사, 지리 및 이전에는 불가능했던 직관적인 방법으로 풍부한 다른 정보와 접속할 수 있을 것이다.주어진 시간 간격에서 지구상의 주어진 위치는 위키피디아에 관한 관련 카테고리 및 기사와 하이퍼링크될 것이다.이러한 방식으로 사용자는 적절한 지리적 및 관계적 맥락에서 역사의 사건을 볼 수 있을 것이다.주어진 시간 간격에 따라 세계 각지의 상태를 한눈에 비교할 수 있어 여러 연구 영역에 대해 전례 없는 관점을 제공할 수 있다.
이 모든 것은 단순히 위키피디아의 점점 더 복잡해지는 상호 참조 네트워크를 직관적으로 탐색하는 수단일 것이다.물품은 이미 날짜와 위치 등의 요인에 따라 세분화하여 분류할 수 있다.이 두 개의 분리된 정보를 포함하는 개인, 주 또는 사건은 이 "meta"-search에 쉽게 통합될 수 있다(즉, 게티스버그 전투는 1863년 7월 1일부터 3일까지 시간 규모로 펜실베이니아 게티스버그 지역을 통해 접근할 수 있을 것이다).
추가 고려 사항
너무 면밀한 점검이 없다면 이런 사업이 시행되기 전에 해결해야 할 문제들이 분명히 많다.예를 들면 다음과 같다.
시간 간격 다양한 시대를 통해 지구를 운반하는 "시간 슬라이더"는 반드시 별개의 간격으로 나누어진다.지난 몇 세기 동안 거의 모든 기간 동안, 그것은 개별적인 날(또는 더 나아가 그러한 정보를 이용할 수 있는 곳)까지 분해될 수 있었다.그러나 우리가 역사를 거슬러 올라갈수록 모호함이 더 많이 생기고, 우리의 시간 간격은 더 멀어져야 할 것이다.다행히, 이것은 기사 자체에서 이용 가능한 정보의 양에 전적으로 의존할 것이며, 아마도 관리 가능한 "시간 슬라이더"의 설계에서만 가장 골치 아픈 것으로 판명될 것이다.
경계 국가 경계뿐만 아니라 다른 메타 정보(모든 사용자가 계층으로 켜거나 끌 수 있음)도 특히 과거에 더 희미해졌을 때(또는 존재하지 않을 때) 논쟁거리가 될 수 있다.이것은 사실 이 프로젝트에서 가장 어려운 측면으로 증명될 수 있는데, 부분적으로는 우리가 기존 기사로부터 이 정보를 독점적으로 얻을 수 없기 때문이다(즉, 기사는 국경 지대와 함께 암호화되지 않는다).그러나, 사실상 해당 국가, 지역 또는 도시의 경계가 해당 기사에 대한 하이퍼링크의 경계가 될 것이기 때문에, 그러한 국경의 확립은 이 대표에 결정적일 것이다.
지질학적 과정 대륙의 표류나 그 밖의 다른 것들을 나타내야 할 정도로 그 프로젝트가 역사 속으로 충분히 멀리 돌아가도록 확대된다면, 우리 인류 역사의 대부분에 작용했던 모델은 고장날 것이다.그러나 현대사에 사용되는 것보다 기하급수적으로 큰 시간 간격에도 불구하고 인터페이스가 이러한 먼 시기로 확장되지 못할 이유는 없다.
통합 위키피디아의 기존 시간별 분류 방법은 그런 측면에서 주요 역사 기사의 통합을 비교적 단순하게 만들어야 한다.위치 데이터에 한하여, 글로벌 인터페이스의 적절한 영역에 관련 기사를 연결하는 추가 정보 하나를 첨부할 것을 제안한다.이것은 새로운 기사 작성의 표준 부분이 될 수 있고, 기존 기사들은 매일, 무수한 다른 목적(검토 등이 필요한 경우)으로 태그가 붙을 수 있다.
질 표현 어떤 시간 간격과 어떤 위치에 부정확한 정보를 배치해야 하는가(전혀 그렇지 않은 경우)
전반적으로 나는 이것이 유토피아적이거나 비실용적인 것으로 치부될 것이라고 확신하지만, 나는 그러한 인터페이스가 본질적으로 비교적 간단할 수 있고, 플래시나 요즘 아이들이 사용하는 어떤 소프트웨어 개발자들의 손아귀 안에 있을 수 있다고 믿는다.분명히 상호 참조와 태그 지정은 결코 끝나지 않는 정교함의 작업이 될 것이다.그러나 불과 몇 년 사이에 위키미디어가 놀라운 성장을 이룬 것을 보면 이와 같은 조직도구는 불가피하다고 생각한다.유일한 질문은, 언제 시작할까?이다. (내가 하고 있는 일을 조금이라도 알고 있다면, 나는 모든 것을 끝장낼 것이다.)
프스탠리 (대화) 04:56, 2008년 1월 13일 (UTC)[
- 재미있는 아이디어지만, 적어도 위키미디아의 무료 콘텐츠 정책(예: 플래시 및 구글 어스)과 충돌하는 자유 콘텐츠 문제 때문에 제안된 대로 기술적으로나 기능적으로 구현하기가 어려울 것이다.만약 당신이 그것을 개발하는 것에 관심이 있다면, 작은 것을 시작하고 Visible Earth와 같은 무료 콘텐츠를 사용하여 사물을 단순하게 유지하기 위한 기본적인 2D 인터페이스를 만드는 것이 좋을 것이고 거기서부터 계속 발전시키는 것이 좋을 것이다 -Halo (토크) 05:23, 2008년 1월 13일 (UTC)[
- 우리에겐 m:위키미니아아틀라스(WikiMiniAtlas)는 위키피디아 기사를 지도에 표시하기 위한 2D 인터페이스를 제공한다.당신의 제안을 실행하기 위해, 해당 기간까지 기사를 제한하기 위해 필터가 추가될 수 있다.문제는 기사에 날짜를 기록하는 방법, 즉 infobox 매개변수, 카테고리, 인라인으로 작성된 날짜 등이 매우 다양하다는 점이다.따라서 기사에서 관련 날짜를 추출하는 데 사용되는 도구는 날짜를 지정하는 여러 가지 방법을 프로그래밍해야 하며, 이는 어려울 수 있다.트라 (토크) 15:11, 2008년 1월 13일 (UTC)[
- http://www.mediawiki.org/wiki/Manual:Hooks과 http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png)을 잠깐 둘러보면 http://www.mediawiki.org/wiki/Manual:Hooks/ArticleSave이나 http://www.mediawiki.org/wiki/Manual:Hooks/ArticleSaveComplete에 기사의 내용을 분석하기 위해 훅을 추가할 수 있을 것이라고 생각한다.저장한 날짜에 대해.발견된 날짜는 새로운 인터페이스를 지원하기 위해 사용되는 모든 데이터 세트의 문서에 링크를 추가하는 데 사용될 수 있다.모든 날짜를 잡으려면 날짜에 맞는 정규식 집합(PHP에서 쉽게)과 사용자가 잡히지 않는 날짜 형식을 보고할 수 있는 방법이 필요하다.정규 표현은 돕겠지만, 디자인을 제대로 하려면 미디어위키의 내막을 잘 아는 사람의 입력이 필요하다.Willll —2008년 1월 14일 (UTC) 22:31에 사전 코멘트가 추가됨[
위키피디아는 무료 콘텐츠다.데이터베이스 다운로드 및 제안서 이행! :-) --김브루닝 (대화) 22:33, 2008년 1월 15일 (UTC)[
WP:센트
정책 논의가 적절한 관심을 받을 수 있도록 템플릿:감시 목록 및 최근 변경사항의 Cent(또는 보안에 대한 우려가 있는 경우, 업데이트될 때마다 해당 Cent)—Random832 16:08, 2008년 1월 15일 (UTC)[
- 업데이트는 자주 업데이트되지 않으며 업데이트는 시간적으로 중요하지 않으며, 이를 완전히 보호하는 것이 더 쉬우며 관리자가 아닌 사용자가 WP에 추가 요청을 하도록 할 수 있다.변경이 이루어질 때마다 재제출 요청을 할 필요 없이 신규 추가에 대한 RFP({edit protected}보다 빠른 응답을 얻을 것임)Mr.Z-man 03:00, 2008년 1월 16일 (UTC)[
- 여기서도 비슷한 제안에 강력히 반대했다. --MZMcBride (대화) 03:04, 2008년 1월 16일 (UTC)[
그것은 변전될 필요가 있다. 시험 결과, 어떤 포함과 포함만이 그것이 없으면 감시목록에서 정상적으로 작동하지 않는 것으로 나타났다.—Random832 04:16, 2008년 1월 16일 (UTC)[
제안: 특정 기사에 대한 특정 편집자의 기여 검색
나는 특정 기사에 대한 특정 편집자의 기고문 검색을 용이하게 하는 프로그램이 있는 것에 흥미가 있다.많은 기사들은 기고 이력이 길고, 또한 많은 편집자들은 기고 이력이 길기 때문에, 현재 그러한 정보를 찾는 것은 때때로 많은 페이지에서 많은 기고를 시각적으로 스캔해야 할 수 있다.
이 프로그램은 그러한 검색을 수행하기 위해 두 가지 방법 중 하나를 선택할 수 있는 가능성을 가지고 설계될 수 있다. (편집자는 등록된 사용자 또는 IP 주소일 수 있다.)
한 가지 방법으로, 검색자는 먼저 기사를 선택한 다음 버튼("편집자")을 클릭하면 해당 기사에 기여한 모든 편집자의 수와 목록(및 각 편집자의 해당 기사에 대한 기고 횟수가 표시된다.해당 번호를 클릭하면 해당 기사에 대한 편집자의 모든 기여 목록이 표시된다.각 기여를 클릭하면 해당 기여 전후의 다른 버전 비교를 보여주는 페이지가 표시된다.
다른 방법으로 검색자는 먼저 편집자를 선택한 다음 버튼("Articles")을 클릭하면 해당 편집자가 편집한 기사 수와 모든 기사 목록(및 각 기사에 대한 편집자의 기여 횟수)이 표시된다.해당 번호를 클릭하면 해당 편집자가 해당 기사에 기고한 모든 기고 목록이 표시된다.각 기여를 클릭하면 해당 기여 전후의 다른 버전 비교를 보여주는 페이지가 표시된다.
2차원 검색을 위한 이 프로그램은 기사 네임스페이스 외에 다른 네임스페이스로 확장될 수 있다. -- 파장 (토크) 16:51, 2008년 1월 15일 (UTC)[
- 위키백과 페이지 기록 통계는 당신의 첫 번째 방법을 부분적으로 만족시킨다.조잔 (토크) 2008년 1월 15일 (UTC) 17:19[
http://en.wikipedia.org/w/api.php ?action=proprop=proprop=prop=prop=prop=prop=prop=prop위키백과:Village%20pump%20(proposals) &rvlimit=50 &rvprop=timestamp 사용자 의견 &rvuser=파장→AzaToth 20:15, 2008년 1월 15일(UTC)[
