위키백과:사랑방/2008년 제39주

링크 추가
위키백과, 우리 모두의 백과사전.
사랑방
◀ 2008년 제39주 ▶
2008년 9월
주 월 화 수 목 금 토 일
36 1 2 3 4 5 6 7
37 8 9 10 11 12 13 14
38 15 16 17 18 19 20 21
39 22 23 24 25 26 27 28
40 29 30 1 2 3 4 5
새로 고침 / 보존 문서


포털/들머리 선정 투표가 금주에 개시됩니다.[편집]

지난 주의 논의한 바대로 금주에 개시됩니다. 과거 많은 찬성을 얻었던 포털과 들머리는 자동적으로 후보에 등재되었으며 이틀 가량 제3, 4의 후보를 받도록 하겠습니다. 그리고 투표의 절차와 관련한 사항의 논의도 이틀 가량의 기간 동안 논의하고 특별한 반대나 여타의 사정이 없으면 절차를 확정짓고 수요일 무렵에 투표가 개시, 공시하는 것이 좋겠습니다.

현재 잠정적 절차는 다음과 같습니다

  1. 투표 기간은 투표 개시로부터 2주. 개시 후 지체없이 노티스창을 통해 대문에 공시
  2. 투표권자는 투표 개시를 기준으로 30일 이상 기간, 1회 이상의 기여를 한 등록 사용자
  3. 한 선택지가 15표 이상의 찬성을 얻고 2위의 선택지보다 5표 이상의 차이를 얻어야 선정
  4. 최종의사결정의 담보와 절차의 안정을 위해 복수 투표는 불허하며 타선택지에 대한 반대투표 금지
  5. 어느 선택지도 2주 내에 3번의 조건을 달성하지 못하면 투표는 무효로 종결
  6. 그 외의 사항은 위의 규정과 성질에 반하지 않는 한 관리자 선거 절차를 준용

그리고 숙려된 의사결정을 위해 아래 기존토론의 기록을 참고해주세요. --hun99 (토론) 2008년 9월 22일 (월) 01:19 (KST)[답변]

찬성합니다. 이 안대로 1주일 내에 투표를 시행했으면 합니다. 하지만, 다만 투표가 무효화되었을 경우에는 그에 대하여 대비책도 준비되어야 하지는 않을까요? BongGon (토론) 2008년 9월 22일 (월) 23:43 (KST)[답변]

의견[편집]

(훈님과 의견이 약간 다른 부분만 강조)

포털 투표를 이번 목요일 0시부터(월요일 토론이 적어서) 개시하였으면 합니다. 현재로서는 포털이냐 들머리냐 두가지 말고는 새로운 의견이 나온 것이 없습니다. 하지만 목요일까지 의견을 듣다보면 새로운 의견이 또 제시될 수도 있겠습니다.

투표권은 기존 관리자 선거의 "선거 개시를 기준으로 등록 후 30일이 경과하고 20회 이상의 편집을 한 사용자"에서 완화된 "선거 개시를 기준으로 등록 후 3주 경과, 5회 이상의 일반 문서 편집"으로 하였으면 합니다.

지난 투표는 참고로만 하였으면 좋겠고요, 개인적으로 제가 기존에 투표했던 분들 사용자토론방을 돌아다니며 투표 참가를 권유하는 글을 올릴 것입니다.(공정성을 위해 저는 마지막 날에만 의견을 발표하겠습니다)

승리요건(?)은 15표 이상 득표 + 차점자와 5표 이상 득표입니다. 만약 3가지 이상의 안이 나왔는데 1,2위가 5표 이내일 경우에는 5일간의 결선투표를 실시하며, 기존의 2가지 안이 5표 이내의 접전을 벌일 경우 재토론을 거친 후에 재투표를 할 것인지 말 것인지를 결정하였으면 합니다.

얼핏 보면 너무 오래 걸리고 지지부진할 것 같지만, 이름공간을 결정하는 것이니만큼 서두를 필요는 전혀 없다고 생각합니다. 관리자들께서 위에 공지를 달아주셨는데요, 포털 투표도 공지를 달고, 기존 투표 참가자들에게 투표 권유 글 하나씩만 더 쓰는 열의를 보였으면 합니다. adidas (토론) 2008년 9월 23일 (화) 01:50 (KST)[답변]

아디다스님의 안에 대체적으로 찬성하지만, '기존의 2가지 안이 5표 이내의 접전을 벌일 경우 재토론을 거친 후에 재투표를 할 것인지 말 것인지를 결정' 등은 이미 많이 소요된 시간과 과도한 토론이 이루어진 점을 고려할 때 다른 방법으로 대체해야된다고 생각합니다. 그리고 선거권 기준의 경우도 Hun99님안대로 하는게 나을 것 같습니다. BongGon (토론) 2008년 9월 23일 (화) 18:00 (KST)[답변]
투표권은 헌님 말씀대로 하는 것도 좋겠습니다. 다만 5표 이내의 경우에 성급하게 결정할 필요는 없다고 봅니다. 중요한 문제인만큼 급하게 정하지 않아도 됩니다. adidas (토론) 2008년 9월 24일 (수) 00:47 (KST)[답변]

지난 주 및 이번 주의 정해진 기간이 도과하였습니다. 위의 절차에 따라 투표를 개시하도록 하겠습니다. 위키백과토론:포털에서 투표가 개시될 예정입니다. --hun99 (토론) 2008년 9월 24일 (수) 00:50 (KST)[답변]

찬성입니다. 투표가 개시되면 제가 기존의 투표자들에게 공고 글을 올리겠습니다. adidas (토론) 2008년 9월 24일 (수) 00:59 (KST)[답변]

75000[편집]

오늘안에 될듯 Wikiduseo (토론) 2008년 9월 23일 (화) 12:51 (KST)[답변]

음...보통 하루 100여개 정도 문서가 올라오는데 오늘은 조금 힘들 것 같습니다. 예상 달성 시간은 내일 저녁 느지막할 때?--Ta183 (토론) 2008년 9월 23일 (화) 13:42 (KST)[답변]
현재 74,983개이니까, 곧 75000개를 달성할 수 있지 않을까 싶습니다. 201KEI (토론) 2008년 9월 24일 (수) 21:40 (KST)[답변]
7만 5천 개가 이전 영문 위키백과에서 하나의 이정표 구실을 하고 있었는데 최근에는 없어졌더군요. 한국어 위키백과에서도 77777에 더 의미를 둘 듯 하고요. 히브리어의 경우 75,000 로고를 달았었는데...그냥 생각나서 적어 보았습니다.--Ta183 (토론) 2008년 9월 24일 (수) 09:46 (KST)[답변]

위키백과에 알맞은 해상도[편집]

위키백과에 알맞은 해상도는 얼마인가요? 저는 주로 1152×864픽셀을 씁니다. 자주 쓰이는 해상도는, 와이드화면이 아니라면, 1024×768이나 1280×1024라고 여겨지는데요. 그런데 최근 그림에서 200px 또는 그 이하짜리 그림을 300px 등으로 고치는 사례가 가끔 눈에 띄네요. 문제는 위키백과의 화면 구성이 어떤 해상도에 맞추어 되어 있느냐인데, 요즘 잘 쓰이지 않는 800×600픽셀 또는 640×480픽셀이라면 300px짜리 그림은 너무 크다고 여겨집니다. (예: 라선특급시)

제가 제기하고자 하는 문제는 (1) 위키백과에서 묵시적 또는 명시적으로 맞추어진 해상도는 무엇인가, (2) 300px 이상의 그림은 너무 크지 않나? 특히 섬네일(thumb) 표시가 달린 그림에서는 너무 크다는 점입니다. 이것에 대해 어떻게 생각하십니까? -- 이 의견을 작성한 사용자는 Knight2000 (토론)이나, 서명을 남기지 않아 다른 사용자가 추가하였습니다.

저 역시 300px 이상은 파노라마와 같이 특별한 경우를 제외하고는 지나치다고 생각합니다. 위키백과 어디엔가 지침으로 기록해 두었으면 좋겠네요. 위키백과:사랑방/2008년 제15주#적절한 해상도에 같은 논의가 있었습니다. --정안영민 (토론) 2008년 9월 27일 (토) 09:49 (KST)[답변]
한 230px 정도가 적당하다고 생각합니다 Ø샐러맨더 (토론 / 기여) 2008년 9월 27일 (토) 09:51 (KST)[답변]
최근 들어 미라지폰이나 SPH-M4655 같은 윈도 모바일을 탑재한 폰이라던가 아이팟 터치, 또 넷북+와이브로로 인터넷을 하시는 분들이 늘었는데 그런 분들을 생각한다면 230px도 크지 않을런지요? 저는 150~200px 정도면 적당하다고 생각합니다. 문서에서 먼저 그림을 크게 보여주는 것보다는, 작게 보여줌으로써 사용자가 선택권을 가지게 해 주는 것이 좋지 않을런지요. :) --iTurtle (토론) 2008년 9월 27일 (토) 10:15 (KST)[답변]
저 역시 150~200px가 적당하다고 생각합니다. 특히 섬네일(thumb) 그림은 크게 키울 필요가 없다고 생각합니다. 크게 하려면 애초에 섬네일이라고 할 필요가 없죠. --Knight2000 (토론) 2008년 9월 27일 (토) 13:01 (KST)[답변]

타언어 위키백과 번역을 위한 파이어폭스/그리스멍키 스크립트[편집]

위키백과 번역할 때 일일이 한국어 페이지 확인하는 것이 귀찮아서 그리스멍키 스크립트를 한 번 만들어 봤습니다. 조잡하게 하드코딩된 부분이 있어서 템플릿 변경에 따라 이상 동작할 수 있습니다;;

참고로 설치 후 일반적인 사용시에는 꺼두시는 게 좋습니다. 오른쪽 하단 원숭이 아이콘 메뉴에서 스크립트를 쉽게 켜고 끌 수 있습니다.

기능 / 특징[편집]

  • 한국어외 언어판 백과사전의 내부 링크에 마우스를 올려 놓을 경우, 그에 해당하는 한국어 항목이 존재하면 링크를 한국어판으로 수정
  • 이벤트 발생부터 링크 수정까지 다소 지연 있음
  • 링크 수정 후에는 링크 배경색 회색으로 바뀜

다운로드[편집]

-- 최담담 (토론) 2008년 9월 24일 (수) 16:22 (KST)[답변]

75,000[편집]

75,000개 돌파했군요. 위키백과에 참여하신 모든 분께 축하 말씀 드립니다.^^ --생활의발견 (토론) 2008년 9월 25일 (목) 00:27 (KST)[답변]

문서 이동 중 발생한 오류[편집]

문서를 이동하려고 하는데 이런 오류가 발생했네요.

데이터베이스 오류

위키백과 ― 우리 모두의 백과사전.

데이터베이스 쿼리 구문 오류가 발생했습니다. 소프트웨어의 버그가 있을 수 있습니다. 마지막으로 요청한 데이터베이스 쿼리는 "Title::moveOverExistingRedirect" 함수에서 쓰인

(SQL 쿼리 숨겨짐)

입니다. MySQL은 "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.0.101)" 오류를 냈습니다.

그냥 단순 오류인 건가요? --하높(Skyhigh05) 2008년 9월 25일 (목) 02:23 (KST)[답변]

MySQL이라면 DB서버 프로그램입니다. 오작동이 있었거나 쿼리(질의문)이 가다가 죽어버린 것 같습니다. 단순 오류가 아니라면 겁먹을 시간인데 말이죠... --Aljjam (토론) 2008년 10월 6일 (월) 19:42 (KST)[답변]

CU요청[편집]

Wikiduseo (토론 · 기여 · 편집 횟수)의 CU를 요청합니다.

  • [1]에서 개인정보의 폭로.(특정판 삭제요청을 했음)
  • [2]에서 특정의 민족을 모욕하는 발언.
  • [3]에서 특정의 용어를 사용한 차단요청.
  • [4]에서 두번에 걸쳐서 증거음폐행위. [5]도 마찬까지.

단순한 장난이다고 생각했지만 본인이 공개하지 않는 개인 정보의 폭로, 특정의 용어를 사용한 차단요청 등 차단된 어느 사용자와 매우 유사하는 것이 있는데 CU를 요청합니다.

조사대상

  1. Wikiduseo의 발신처에서 다른 계정이나 IP에서 접속한 흔적이 있는지 조사를 부탁합니다. ----hyolee2♪/H.L.LEE 2008년 9월 25일 (목) 11:14 (KST)[답변]
CheckUser 요청은 m:Steward requests/Checkuser에서 해 주세요.--Kwj2772 (d)//이전 계정 2008년 9월 25일 (목) 17:17 (KST)[답변]

정작 해당 사용자의 토론란에는 아무 말도 안 하셨군요. 뭘 어쩌라는 거죠? IP가 다르면 문제 대상이 아니라는 건가요? --Klutzy (토론) 2008년 9월 28일 (일) 00:24 (KST)[답변]

CU요청이전에 다른 사용자에 의해서 경고됐습니다. 대처에 대해서는 결과가 나온 후에 검토합니다. ----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 10:00 (KST)[답변]


드디어 75000개 돌파![편집]

드디어 한국어 위키의 문서 갯수가 75000개를 돌파했습니다. 현 시각 기준 75,007개네요. 뭐 요즘은 77,777개에 더 의미를 둔다고도 합니다만, 어찌되었든 75,000개 돌파를 축하해봅니다 ^^) 201KEI (토론) 2008년 9월 25일 (목) 15:33 (KST)[답변]

미디어위키:sidebar에서 검색창 맨 위로[편집]

예전에 대문에 검색창을 걸자는 제안이 있었는데, 대문 디자인 상 검색창을 걸기에는 힘들다는 판단이 있었던걸로 알고 있습니다. 그래서 차선책으로 사이드바의 검색창을 맨 위로 옮겨 백과사전에 정보를 찾으러 오는 사람에게 주목적을 쉽게 달성하게끔 해주는게 백과사전으로서의 의무를 다하는게 아닌가 생각됩니다. --알밤한대(토론) 2008년 9월 25일 (목) 22:27 (KST)[답변]

적극 동의합니다. 저 또한 처음 위키백과를 접했을 때 검색창을 찾아 헤맸던 기억이 있습니다. 새 대문이 나오기 전까지는 검색창을 최상단으로 올립시다. --KSiOM(Talk) 2008년 9월 26일 (금) 03:43 (KST)[답변]
저도 동의합니다. 검색창이 어디 있는지 몰라 헤맸던 기억이 저도 있습니다. 여담입니다만, 위키백과는 솔직히 말해서 사용자 중심의 인터페이스가 부족합니다. 이 것이 위키백과는 폐쇄적으로 만드는데에 일조하지 않을까... 생각합니다만... 아무튼 검색창을 위쪽으로 올리는 데에 동의합니다. --RedmosQ (토론) 2008년 9월 27일 (토) 20:36 (KST)[답변]
동의합니다. 언젠가는 대문에 검색창을 걸기를... --Nt (토론) (토론) 2008년 9월 27일 (토) 20:49 (KST)[답변]
동의합니다. 노르웨어어판에서는 검색창을 맨 위에 배치해두고 있어요. --iTurtle (토론) 2008년 9월 27일 (토) 21:51 (KST)[답변]
저도 적극 동의합니다. BongGon (토론) 2008년 9월 27일 (토) 22:31 (KST)[답변]
저도 동의합니다. 상단면에 걸지 못하면 일단 왼쪽상단에라도 걸어두었으면 좋겠습니다. --hun99 (토론) 2008년 9월 27일 (토) 22:40 (KST)[답변]
참고로 중국어 위키백과도 검색창을 맨 위에 두고 있습니다. --Nt (토론) (토론) 2008년 9월 28일 (일) 11:33 (KST)[답변]
본질적인 해결책은 대문에 검색창을 두는 거지만, 어쨌든 이용자 입장에서는 찾기창이 맨 위에 있는 게 훨씬 좋겠지요. - I110 桂陽 / IRTC1015(議) 2008년 9월 28일 (일) 15:19 (KST)[답변]
검색창의 크기를 좀 키우고, 모바일 등 저해상도 환경에 대응하는 대문을 따로 만드는 건 어떨까요? - I110 桂陽 / IRTC1015(議) 2008년 10월 3일 (금) 12:39 (KST)[답변]
IE6에서는 쿠도군님 대문 이상하게 보입니더.. -_-; --iTurtle (토론) 2008년 10월 3일 (금) 20:55 (KST)[답변]
검색창을 원래 것은 그대로 두고 위에 하나 더하는 방법도 있습니다. --Knight2000 (토론) 2008년 10월 6일 (월) 08:57 (KST)[답변]

문서 카운터에 뭔가 이상이 생긴 것 같습니다.[편집]

문서 개수가 어제 점심 75,007개 이후 변하지를 않고 있습니다. 삭제 기록이나 기타 새 문서 작성 기록을 살펴 보아도, 그리고 신규 등록자 숫자를 보아도 수치가 변하지 않는다는 것은 뭔가 이상하네요. 위키 서버 측에 뭔가 애로 사항이 생긴 것입니까? 궁금해서 질문을 올려 봅니다.--Ta183 (토론) 2008년 9월 26일 (금) 09:30 (KST)[답변]

네 저도 그런것을 느끼고 있습니다. 그런말을 할 참이였는데...%%스톰대박 %·% 2008년 9월 26일 (금) 12:23 (KST)[답변]
다른 언어판 위키에도 가 봤는데, 비단 우리 뿐의 사정이 아니라 모든 위키백과 문서 개수 기능이 고장난 것으로 보입니다. 작은 차이지만 문서 생산 의욕을 상당히 떨어뜨리는군요. 이거 빨리 기능 보정이 되지 않으면 77777도 언제 했는지 모르게 넘어갈지도 모르겠습니다.--Ta183 (토론) 2008년 9월 26일 (금) 22:07 (KST)[답변]
75008로 나오는데요?SSHS (토론) 2008년 9월 27일 (토) 17:12 (KST)[답변]
덜덜덜덜 요즘 서버 너무 이상해요 오류 떴다가 문서 숫자 계산도 안되고... ㅠㅠ 의욕이 후덜덜 떨어지네요 ㅠ vozdepaz (토론) 2008년 9월 28일 (일) 04:23 (KST)[답변]

위키서버 측에 무슨 문제가 생긴 게 확실한 것 같네요. 문서는 매일 100개 정도씩 꾸준히 생기고 있고 가입자들도 비슷하게 늘어나고 있는데 문서 상승 갯수는 고작 1개.... 카운터 숫자 아주 큰 역할 합니다. 신속히 복구되어야 하는데 문제가 생각보다 큰 것 같네요. 3일이 지나도록 차도가 없으니 말입니다.--Ta183 (토론) 2008년 9월 28일 (일) 10:21 (KST)[답변]

이런 벌써 3일이나 이런 문제가 있었나요? 굉장히 오래 지속되는 듯 한데 정말 어떤 조치가 필요할 것 같습니다만 어떤 방법이 아예 없나요? ....vozdepaz (토론) 2008년 9월 28일 (일) 14:25 (KST)[답변]

위키백과 문서 숫자 시스템이 생각보다 좀 허술한 듯 합니다. 사흘 동안 멈춰 있다가 오늘 다시 카운터가 올라가기 시작하는데, 전체 숫자를 세서 집계하는 게 아니라 멈춘 시점에서 단순히 문서가 늘어나고 줄어드는 숫자를 반영하고 있네요. 지난 3일 동안 문서가 줄잡아 300개 이상은 추가가 되었는데 이제 50개가 늘어났다는 게 그걸 방증한다 봅니다. 실망스럽네요. 앞으로 매겨지는 이정표들(77777, 10만, 20만 등등...)의 신뢰도가 없어지니까요.--Ta183 (토론) 2008년 9월 28일 (일) 22:19 (KST)[답변]

의견 위키백과 서버에 연락을 해보는게 어떨까요?--A. W. ROLAND ː <RECENT> 2008년 9월 28일 (일) 22:26 (KST)[답변]

이젠 괜찮은 것 같군요. 75,090개로 나옵니다. --Nt (토론) (토론) 2008년 9월 29일 (월) 15:25 (KST)[답변]

Ta183ta님 말씀이 맞는 것 같아요.. 아무리 그래도 며칠이나 문서 개수 확인 작업이 불통이었는데 75000에서 지금 100개 늘어났으면 말이 안되는 것 아닌가요? 진짜 어떻게든 해결을 봐야할 문제인 것 같습니다만... vozdepaz (토론) 2008년 9월 29일 (월) 23:38 (KST)[답변]

저작권에서 자유로운 한일번역기를 만듭시다.[편집]

일본어판 그대로 번역해서 문서수 늘립시다. 인공어판들도 그런식으로 많은 문서수인게 많은것 같습니다.SSHS (토론) 2008년 9월 27일 (토) 17:14 (KST)[답변]

그런 번역기를 만들수 있으시다면야.. adidas (토론) 2008년 9월 27일 (토) 17:20 (KST)[답변]
네, 그런 번역기를 만들 능력이 있었다면 벌써 만들었었겠지요. 가장 쉬운 한일번역기도 만들려면 보통일이 아닐텐데 --WhiteNight7(Talk) 2008년 9월 27일 (토) 20:22 (KST)[답변]
번역기로 문서 양만 늘려봐야 아무 소용이 없겠지요.--아들해 (토론) 2008년 9월 27일 (토) 20:24 (KST)[답변]
결사 반대 인공어판들이 까이는 이유가 번역기를 통한 문서 양산입니다. 이런 식의 주제가 나올때마다 항상 하는 말이지만, 번역기가 없어도 번역을 할 수 있는 사람만 번역기를 써서 번역해도 됩니다. --Dus|Adrenalin (토론) 2008년 9월 28일 (일) 00:05 (KST)[답변]
일본어판의 문제는 출처가 전무한 경우가 많다는 것입니다.(우리도 그 면에서 비슷하기는 하지만, 굳이 안 좋은 것을 따라갈 필요는 없습니다) 그런 면에서 굳이 문서 수와 퀄리티를 맞바꿀 필요는 없다고 봅니다.--Ta183 (토론) 2008년 9월 28일 (일) 09:08 (KST)[답변]
단순한(?) 번역기가 아니라 번역 도구가 있었으면 좋겠어요. 저작권에서 자유로운 번역도구 어떨까요? 위에 최담담님이 올린 것이 좋은 예가 될것같아요...--59.17.141.200 (토론) 2008년 9월 28일 (일) 12:04 (KST)[답변]
번역을 위주로 하는 분들을 위해서 단순작업을 없애 주는 도구가 있었으면 합니다. 예를 들면

1. 주석 태그의 일괄 한글화(|main= >>> |제목=) 2. 자주 나오는 용어(나라 이름 등...)의 자동 한글 변환 이런 것들을 원클릭으로 해결하면 번역에 좀 더 시간이 단축되고 더 많은 문서 생산도 가능하지 않을까 보는데요. 저같은 경우 한글로 긁어붙인 뒤 찾기>바꾸기를 쓰고 있지만 이것이 공식적으로 가능했으면 하는 소망이 있습니다.(프로그래밍과는 관련이 없는지라 능력자께서 만들어 주시기만 바라고 있습니다ㅡ,.ㅡ --Ta183 (토론) 2008년 9월 28일 (일) 22:39 (KST)[답변]

번역만 생각했지, 그 내용의 역사적 문화적 맥락은 전혀 고려치 않은 넌센스입니다. 만약 그렇다면 그들이 일본의 전쟁 행위에 대해 미화해놓은 글을 한글로 그대로 보시렵니까? BongGon (토론) 2008년 9월 28일 (일) 22:43 (KST)[답변]
번역은 그 자체로 하나의 창조이며, 매우 전문 영역입니다. 처음에는 저도 단순히 번역만 했지만, 최근에는 가능한 한 다른 자료를 참조해서 덧붙이며 편역을 시도하고 있습니다. 번역을 너무 쉽게 생각하지 마세요. 고등학교 영어 교과서 해석하는 것이 번역의 전부가 아닙니다. --WaffenSS (토론) 2008년 9월 30일 (화) 01:58 (KST)[답변]
번역은 장난으로 할 일이 아닙니다. 언어판에 따른 특성과 편집자가 자료를 수집/조사하여 써가는 재밌는 과정도 없어지죠. 그렇게 하면 남의 숙제해주는거 밖에 안됩니다.--크렌베리 (토론) 2008년 10월 4일 (토) 14:05 (KST)[답변]

이민과 이민자[편집]

이민 문서는 있지만 이민자 문서는 없습니다 그런데 ... 영어판은 Immigration Immigrants 다 똑같이 연결되는데요 음 보니 어떻게 나눠야 할지도 난감하고 그런데 혹시 좋은 방법이 뭐가 있을지요ㅠㅠ vozdepaz (토론) 2008년 9월 27일 (토) 22:03 (KST)[6][답변]

이민 문서에 이민자 내용을 통합할 수 있지 않을까요? adidas (토론) 2008년 9월 27일 (토) 22:46 (KST)[답변]
비슷한 내용이니 굳이 분리할 필요가 없다고 생각합니다. BongGon (토론) 2008년 9월 27일 (토) 22:46 (KST)[답변]
네 그렇게 생각한다면 좋겠지만 음... 이민 문서를 조금 편집하면서 이민자와 같이 부르도록 유도하면 좋겠네요.. 이민자에 이민 연결고리를 달면 되나요? vozdepaz (토론) 2008년 9월 27일 (토) 23:09 (KST)[답변]
이민 문서의 한 항목으로 이민자를 넣고, 영어판 연결은 immigration으로 하면 될 것 같습니다. --싱글·하트 (토론) 2008년 9월 28일 (일) 11:50 (KST)[답변]

뷰로크랫 이름 변경에 관하여[편집]

세부 사항 : 위키백과토론:뷰로크랫

뷰로크랫 이름 변경에 관하여 아직 전체적인 동의가 있지 않은 듯 합니다. 일단 뷰로크랫의 대안으로 제시된 이름 뿐만 아니라 과연 뷰로크랫에 대한 이름에 대해 찬반이 어느 정도 있는지도 사실 파악이 잘 안되고 있는것 같기도 하고 그렇습니다.

일단 이 이름 변경에 있어서는 서두르면 안된다는 합의점이 형성되고는 있기 때문에(굳이 뷰로크랫 사안이 아니더라도 다른 이름 변경에서 충분히 보여줬죠), 하지만 서두르면 안된다는 것이 그냥 시간만 보내라는 뜻 또한 아니기 때문에 저는 뷰로크랫의 이름 변경 절차에 관하여 다음과 같이 제안하고자 합니다.

  1. 뷰로크랫이 이름에 대한 찬반 여부 가리기(간단한 토론 뒤에 투표를 들어가든지, 여러 방법이 있겠습니다)
  2. 뷰로크랫의 역할에 대한 개념 정립과 그에 맞는 대안들 추려나가기
  3. 최종 결정을 위한 토론이나 투표

일단 추상적으로 이 정도로만 제시해 보았습니다. 사실 지금도 뷰로크랫의 이름에 대한 대안은 많은데, 개인적인 생각을 밝히자면 뷰로크랫의 역할에 제일 부합하는 것은 '임명권자(위원), 사무관, 실무자(관)' 정도로 생각됩니다. BongGon (토론) 2008년 9월 27일 (토) 22:42 (KST)[답변]

일단은 뷰로크랫이라는 이름을 한글화 하여야 하느냐 마느냐에 대한 여러분의 의견을 듣고 싶습니다. adidas (토론) 2008년 9월 27일 (토) 22:46 (KST)[답변]
맞습니다. 거기에 관련한 토론 혹은 찬반투표가 이루어진 뒤, 2단계로 차선책을 찾는게 우선이라고 생각합니다. 제가 토론란에 제시한 것도 바로 그것입니다. BongGon (토론) 2008년 9월 27일 (토) 22:53 (KST)[답변]
찬성 평소에 뷰로크랫, 뷰로크랫 하는 것은 들어보았지만 무슨 뜻인지 짐작을 할수가 없네요. 한글화에 찬성입니다.--A. W. ROLAND ː <RECENT> 2008년 9월 28일 (일) 22:35 (KST)[답변]
뷰로크랫은 한국어 화자에게 익숙한 외래어도 아니며, 그 의미를 짐작하기도 어렵습니다. 또한 해당 영어 단어의 의미를 알고 있는 사람에게도, bureaucrat(관료)이라는 단어는 백:아님#관료주의라는 위키백과 정책과도 충돌하기 때문에 혼란스러울 뿐입니다. 적절한 말로 바꾸었으면 좋겠습니다. :) --정안영민 (토론) 2008년 9월 28일 (일) 23:09 (KST)[답변]
동의합니다. 다만 적절한 한국어 이름을 찾는 데에는 꽤 걸릴 것 같네요. - I110 桂陽 / IRTC1015(議) 2008년 9월 29일 (월) 00:08 (KST)[답변]
지금 의견으로 볼 때 뷰로크랫이라는 이름의 변경에 딱히 반대하시는 분은 없으신 것 같습니다. 그럼 1단계를 생략하고, 바로 대안 찾아가기로 가는게 좋겠습니다. BongGon (토론) 2008년 9월 29일 (월) 12:26 (KST)[답변]

토론란 삭제 관련[편집]

일반적으로 문서의 토론란에서는 다른 사람의 글을 편집할 수 없고, 본인의 글인 경우에는 삭제가 아닌 삭제 표시를 하게 되어 있습니다. (위키백과:토론에서 지켜야 할 점 참조) 문제는, 비정상적인 글들 - 욕설 등 인신공격성 글, 개인정보, 저작권 위반 글 - 인데, 현재로서는 이들을 삭제할 수 있는 규정이 마련되어 있지 않습니다. (위키백과:토론란에 대한 지침#다른 이들의 의견이 있긴 하지만, 아직 제안 상태입니다.) 토론:조갑제 건도 있고 하여 이에 대한 논의가 필요할 듯합니다. jtm71 (토론) 2008년 9월 28일 (일) 11:14 (KST)[답변]

그리고 다중계정에 의한 토론교란(한 사람이 복수를 가장하고 토론을 조작하는 것)및 차단되어 있는 계정의 다른 계정에 의한 글(사용이 금지되어 있음)에 의한 글도 말소처리할 수 있는 규정이 필요합니다.----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 11:20 (KST)[답변]
어느 특정 문서를 악의적으로 반복편집하는 것에 대해 다중계정이라는 의견이 나왔습니다.(위키백과:사용자 관리 요청/2008년 9월) 동일인 이거나 동일인으로 추정되는 IP주소 사용자들과 멀티 계정에 의한 악의적인 문서훼손은 옳지 못한 일입니다. 자동 삭제나 강제 삭제규정을 마련해야 한다고 생각합니다.-- 개독구 2008년 9월 28일 (일) 12:38 (KST)[답변]


일단 일반 문서의 토론란의 글을 삭제할 수 있게 할 것인지의 여부를 결정해야 할 듯합니다. 개인적으로는 법적인 문제가 관련되어 있는 한 위와 같은 글들의 삭제는 허용되어야 한다고 생각합니다. jtm71 (토론) 2008년 9월 28일 (일) 11:29 (KST)[답변]

개인정보, 저작권 위반 글 은 편집(으로 삭제가)이 아니고 특정판의 삭제가 필요합니다.----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 11:39 (KST)[답변]
정리하면
  • 편집으로 삭제:욕설 등 인신공격성 글,
  • 편집으로 삭제 또는 말소로 삭제:다중계정에 의한 토론교란의 글 및 차단되어 있는 계정의 다른 계정에 의한 글
  • 특정판 삭제:개인정보, 저작권 위반 글 입니다.----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 11:43 (KST)2008년 9월 28일 (일) 15:28 (KST)(밑출부 추가)[답변]

동의합니다. 일단 이러한 내용들이 위키백과:토론에서 지켜야 할 점과 위키백과:삭제 정책의 내용이 보충되어야 할 듯합니다. 그리고, 토론란에서 특정 글을 삭제하는 경우에는 원래의 글이 있던 자리에 '□□□한 이유로 □□의 글을 삭제하였습니다. - 시간 표시' 정도의 요약 정보를 남겨 두는 것이 좋을 듯합니다. (다만, 다중 계정에 의한 글을 '금지된 내용'으로 규정하여 삭제할 것인지는 별도의 논의가 필요할 듯합니다. 개인적으로는 다중 계정임을 표시하더라도 '증거'의 의미로서 남겨둘 필요가 있다고 생각됩니다.) jtm71 (토론) 2008년 9월 28일 (일) 12:26 (KST)[답변]

jtm71님의 견해에 동의합니다. 다중 계정에 의한 글까지 지울 필요가 있을까요? - I110 桂陽 / IRTC1015(議) 2008년 9월 28일 (일) 15:17 (KST)[답변]
Jtm71님 및 IRTC1015님에게 다중 계정을 사용한 토론교란은 다른 사용자에게 혼란을 미치는 행위이며,그리고 차단되어 있는 계정의 다른 계정에 의한 글은 편집이 할 수 없으니까 발언 자제가 있을 수 없습니다.편집으로 삭제처리해도 판을 삭제하지 않는 한 기록은 남깁니다.----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 15:28 (KST)[답변]
이렇게 처리합니다.
Jtm71님 및IRTC1015님에게 다중 계정을 사용한 토론교란은 다른 사용자에 혼란을 미치는 행위이며,그리고 차단되어 있는 계정의 다른 계정에 의한 글은 편집이 할 수 없으니까 발언 자제가 있을 수 없습니다.XXX 다중 계정을 사용한 토론교란 때문에 말소처리 합니다.----hyolee2♪/H.L.LEE 2008년 9월 28일 (일) 15:33 (KST)[답변]

논의할 내용이 여러가지여서 구분합니다.

  • '삭제'와 '삭제 표시'는 구분되어야 할 듯합니다. 그리고, 차단 회피를 위한 다중 계정의 글은 삭제 처리되는 것이 맞을 듯합니다. 다만, 이 경우는 해당 글이 차단된 사용자의 글인지 명백히 판별 가능해야 합니다.
  • 현재 토론:조갑제에서 비난성 글을 삭제 또는 대체한 것은 다른 사람의 글을 고친 것으로 위키백과의 규칙에 어긋납니다. '공격적인 글'에 대한 뚜렷한 기준도 없어서 이 토론에서 결론이 나지 않으면 원래대로 되돌리게 될 수도 있습니다. jtm71 (토론) 2008년 9월 28일 (일) 18:31 (KST)[답변]

1주 내로 더 이상 의견이 없으면 위키백과:토론에서 지켜야 할 점과 위키백과:삭제 정책의 토론란에 위의 의견을 정리하여 토론란에서의 글 삭제에 대한 내용 추가를 제안하겠습니다. jtm71 (토론) 2008년 9월 29일 (월) 11:41 (KST)[답변]

토론란에서의 문서 삭제의 유형은 1) 삭제 표시 2) 내용 삭제 3) 특정판 삭제가 되며, 삭제를 고려해야 할 경우는 1) 저작권 2) 명예 훼손 3) (당사자가 원하지 않는) 개인정보 공개 정도가 될 것입니다. 이 중 저작권과 개인정보는 특정판 삭제 - 삭제 후 특정판 삭제 요청 - 가 고려되며, 명예 훼손은 내용 삭제, 기타 타 사용자에 대한 (위키백과의 발전을 저해하는, 명백히 판단이 가능한) 비방의 글이나 (위키백과의 규칙을 회피하는, 명백히 판단이 가능한) 차단된 사용자의 글은 삭제 표시 정도로 처리하면 될 듯합니다. 그리고, 관리자 요청 등의 인용이 필요한 경우에는 내용 복사보다는 버전 비교로 제시하도록 하는 것이 좋을 듯합니다. 다른 의견이 있다면 제안 바랍니다. jtm71 (토론) 2008년 9월 30일 (화) 08:20 (KST)[답변]

다음과 같이 정리해 봅니다. jtm71 (토론) 2008년 10월 26일 (일) 12:46 (KST)[답변]

추가될 내용
개인 사용자 토론란이 아닌 토론란의 글은 일반적으로 무삭제를 원칙으로 하지만, 다음과 같은 경우에는 유형별 삭제를 허용한다.

삭제 표시[편집]

<s> 태그와 </s> 태그를 취소하려는 글 양쪽에 놓아 취소하는 글에 줄취소하는 글을 그어 삭제된 글임을 표시한다.

  • 글쓴이가 다른 사용자의 답변이 붙은 자신의 의견을 취소하는 경우
  • 명백히 판단이 가능한 타 사용자에 대한 비방의 글이나 차단된 사용자의 글

내용 삭제[편집]

내용 전체를 삭제한다.

  • 댓글이 달리지 않은 자신의 글을 취소하는 경우
  • 저작권을 위반하는 글
  • 당사자가 원하지 않는 개인 정보가 공개된 경우
  • 명예훼손의 우려가 있는 글

삭제한 위치에는 작은 글씨로 다음과 같이 삭제 이유와 서명을 표시한다.

'□□□로 □□의 글을 취소합니다./삭제하였습니다. - ~~~~'

특정판 삭제[편집]

위키백과의 관리자에게 특정판 삭제를 요청한다.

  • 저작권 위반, 명예훼손 등이 우려되는 경우

저작권 위반, 명예훼손으로 피해가 우려되는 경우, 먼저 해당 내용을 삭제하고 관리자에 특정판 삭제를 요청한다.

분류:위키백과 관리, 분류:위키백과 정비[편집]

양자의 차이에 대해 아시는 분 있으면 설명 부탁드립니다. 하나로 합칠까 고민중. adidas (토론) 2008년 9월 28일 (일) 13:35 (KST)[답변]

개인적인 생각으론 관리는 물리적인 통제가 떠오르고, 정비 하면 부족한걸 보충한다 이렇게 생각 되네요. 개독구 (토론) 2008년 9월 28일 (일) 13:38 (KST)[답변]
위키백과 관리 쪽에는 주로 삭제나 이동 등 관리자 권한이 필요한 내용이 들어있고, 위키백과 정비 쪽에는 POV, 정리 필요, 토막글 등 관리자 권한 필요 없이 토론과 편집으로 충분한 것들이 들어있네요. --더위먹은민츠(발자취) 2008년 9월 28일 (일) 13:40 (KST)[답변]
문제는 그게 명확히 분리되어 있는 게 아니라는 겁니다. -_- - I110 桂陽 / IRTC1015(議) 2008년 9월 28일 (일) 14:52 (KST)[답변]

원래는 둘 다 '위키백과 관리'였는데 딱딱하다는 느낌이 들어서 둘로 나눈 것입니다. 제목은 영어판의 maintenance를 번역해서 '정비'라고 했고요. 지금은 인터위키가 꼬여 있지만 영어판에는 en:Category:Wikipedia administration이 따로 있긴 합니다. --Puzzlet Chung (토론) 2008년 9월 29일 (월) 08:40 (KST)[답변]

small 태그 사용에 대한 의견 청취[편집]

그림에 긴 설명을 달 경우 습관적으로 small 태그를 달고 있습니다. 그림의 설명이 큰 글씨로 길게 이어지면 문서가 산만해 지기 때문인데요. 사용자:Bart0278님이 불여우를 써서 small 태그를 붙인 글이 아주 작게 표시된다고 하는 군요. 여러분 의견을 구합니다.

1. 파이어폭스 쓰시는 분들은 small 태그가 불편하신가요?
이 글이 쓰인 부분이 small 태그가 붙은 부분입니다. 비교해 주시기 바랍니다.

2. 글자의 크기를 약간 줄여야 할 경우 small 태그 이외의 좋은 방법은 없을 까요?

좋은 의견 구합니다. Jjw (토론) 2008년 9월 28일 (일) 22:04 (KST)[답변]

사용자 환경에 따라 다르지만, 제 경우는 small 태그가 9pt 정도로 표시됩니다. 8pt로 표시되는 분도 더러 있는 모양이네요. 글자 크기는 {{resize}} 등으로 때울 수는 있겠지요. - I110 桂陽 / IRTC1015(議) 2008년 9월 28일 (일) 22:39 (KST)[답변]
영어판 위키의 경우 섬네일에 달리는 글씨 크기가 알아서 작아지던데, 그곳에서 사용하는 방식을 적용하면 되지 않습니까? 번거롭게 태그를 쓸 필요도 없고 말이죠. --닭살튀김 (토론) 2008년 9월 29일 (월) 00:24 (KST)[답변]
문제는 그렇게 할 경우 지금 사용한 small 태그들을 다 떼어내야 할 것 같네요. 뭐 어려운 일은 아니겠지만. :) --iTurtle (토론) 2008년 9월 29일 (월) 12:55 (KST)[답변]
틀에서의 small 태그는 이런 글자를 보여줍니다. 漢字는 識別이 어렵습니다.
일반 문서에는 11pt/s:9pt, 틀에서는 10pt/s:7pt로 표시되는 듯합니다. 한글이나 한자에서 7pt는 알아보기 어려워 개인적으로는 틀에서 small 태그를 사용하지 않고 있습니다. jtm71 (토론) 2008년 9월 29일 (월) 11:24 (KST)[답변]
  • LERK님이 제시한 방법과 small 태그의 비교
    • span 태그: SPAN
    • small 태그: SMALL

제가 쓰고 있는 인터넷익스플로러 6.x 버전에서는 span을 사용한 글이 더 작아 보입니다. Jjw (토론) 2008년 10월 2일 (목) 19:04 (KST)[답변]

  • 의견 앞의 내용에도 밝혔듯이 일어판 위키나 영어판 위키처럼 자동으로 글씨가 작아지게 하는 방법이 어떨까 싶은데요. 태그를 사용하여 글씨를 작게 표기한 경우가 아직 많지 않으니 크게 번거롭지도 않을듯 하구요. 새로운 태그로 대체하면 이에 대한 정보를 숙지하지 못할 경우 그대로 small 태그를 쓸 수도 있고, 번거로워서 쓰지 않는 경우도 생길 수 있습니다. 모든 섬네일 설명을 일괄처리하면 태그를 쓸 필요도 없이 편하게 설명을 적을 수 있지 않을까요. 그런데 이걸 수정할 수 있는 미디어위키 설정이 무엇인지 아는 분 없는지; --닭살튀김 (토론) 2008년 10월 3일 (금) 22:46 (KST)[답변]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=위키백과:사랑방/2008년_제39주&oldid=20785927"