위키문헌:사랑방

위키문헌 사랑방

새 글 쓰기

보존 문서

• 보존 문서 목록

"해석" 이름공간 도입 제안

현재 많은 문서에 케이스 바이 케이스식으로 수록되어 있는 "해석문"(번역이 아님)을 수록하기 위하여 "해석:" 이름공간을 새롭게 만들 것을 제안합니다.

생성 필요 이유에 관한 설명

1. 통일되지 않은 방식: 여러분이 이미 잘 아시는 것처럼, 현재 있는 문서들에는 해석이 중구난방으로 달려 있습니다. 방식도 통일되어 있지 않고 극단적으로 해석이 원문처럼 둔갑한 경우도 많습니다.
   • 현재 방식의 문제는 한문 해석문의 수록 지침 도입 토론에 자세히 정리해 둔 것이 있습니다.
   • 통일안으로 만들어진 한문 해석문 지침의 경우, 틀 사용 방식이 어렵기도 하고 "한문은 아닌데 해석문이긴 한 경우"를 전혀 커버하지 못한다는 문제가 있습니다.
2. 번역 이름공간으로 대체 불가: 번역:언간독과 같은 경우, 한문도 아니고 원문(언간독)은 분명 한국어이기 때문에 "번역"이라고 하기는 어렵지만 해석은 등재해주고 싶다는 의견이 있었습니다.

추가를 통해 기대되는 효과

1. 명확한 구분: 위키문헌은 근본적으로 원문을 수록하는 프로젝트이기 때문에 엄밀한 의미에서 마음대로 해석문을 만들면 안 됩니다. 이것이 너무 가혹한 정책이기 때문에 만들어진 것이 "번역" 이름공간이고요. 현재 "해석문"은 번역도 아니고 그렇다고 원문도 아닌 애매한 상태이나, "번역" 이름공간과 마찬가지로 독립적인 이름공간을 주는 것이 매 번 제기되는 "취지에 맞지 않는다"라는 의견을 수용하면서도 해석문의 작성을 가능하게끔 하는 방식이 될 수 있습니다.
   • 번역 이름공간과의 구분: 전 지침에서 지적한 것과 같이 "한문은 엄연한 의미에서는 한국어이다"라는 문제를 해소해 줄 수 있습니다.
2. 활동 장려: 해석문을 만드는 방식으로 위키문헌에 기여하고자 하는 분들께는 어떤 방식으로 활동하면 되는지 더 명확해지는 것인 만큼, 이를 매개로 해석 활동을 하고 싶은 사용자를 모을 수 있는 기회로 작용할 수도 있습니다.
3. 문서 간의 관계 정리: 해석이라기보다는 한자 독음만 적는 경우(대한민국헌법과 대한민국헌법 (한자혼용)의 관계 등)까지도 포함하면 문서 간의 관계를 더 구조적으로 정비할 수 있습니다. 이전에는 해석이 있다는 것도 모를 수도 있지만 아에 이름공간으로 정비해 버리면 서로 연관지어주기 더 쉬우리라고 생각합니다.
4. 정확한 원문 / 이해가 쉬운 텍스트의 동시 제공: 원문에 한자음이 표시되지 않은 경우 이해를 위해 편집자가 임의로 적어주는 경우가 있는데 이는 엄연한 의미에서 원문 훼손인 만큼, 이럴 때 해석 이름공간을 이용하면 확실히 원문은 원문대로, 해석은 해석대로 분리해줄 수 있을 것 같습니다.

이름공간 번호는 (큰 상관은 없으나) 112(해석)와 113(해석토론)을 생각하고 있습니다. 그냥 번역 이름공간이 114-115번이어서 임의로 생각해낸 번호입니다. 또한 일반-해석 사이의 연결은 밑에서 제안하는 것처럼 스크립트를 이용한 버튼 사용을 제가 제안하고는 있지만, 꼭 이래야 하는 것은 아니고 그냥 단순히 상단에 틀을 붙이는 정도로 해도 괜찮을 것 같습니다.

해석 이름공간을 실제로 도입한다면 지금까지의 편집 지침·경향·관행을 뜯어고쳐야 할 수도 있습니다. 그런 만큼 꼭 한 마디씩이라도 의견 남겨 주시면 감사하겠습니다. --Aspere (토론) 2025년 1월 23일 (목) 18:31 (KST)

찬성 아무래도 지금 규칙을 만들어두는 편이 좋다고 생각합니다. 소 잃고 외양간 고치는 것보다는 유비무환이 더 좋다고 보는 입장이라서요. NZ 토끼들 (토론) 2025년 1월 23일 (목) 18:36 (KST)

번역 이름공간만을 사용하기에는 부족한 점이 있다고 생각하므로 새로운 이름 공간을 도입하자는 의견에 찬성합니다. Respice post te (토론) 2025년 1월 23일 (목) 19:12 (KST)

찬성 찬성합니다. -- Jjw (토론) 2025년 1월 23일 (목) 19:54 (KST)

찬성 개인적으로는 중국어 위키백과의 간체자-정체자 변환처럼 한자를 1:1 단순 대응하는 것이 있었으면 좋겠다고 생각하였는데, 이러한 방식도 나쁘지 않은 것 같습니다. 다만 여전히 의미가 조금 헷갈리는 부분이 있습니다. 저는 고대 또는 중세 한국어를 현대 한국어로 "번역"하는 것으로 이해가 되는데, 해석과 번역이 개념상 어떠한 차이가 있는지 잘 모르겠습니다. 고대 그리스어를 현대 그리스어로 옮겨도 여전히 "번역"의 개념에 들어가는 것이 아닐련지요? 번역 이름공간을 사용하면 안 되는 이유가 있는지요? 위키문헌:한문 해석문의 수록 생성 당시에 토론에 참여하지 않아서 잘 모르겠네요.--Namoroka (토론) 2025년 1월 25일 (토) 18:21 (KST)

또한 여전히 해석이나 번역을 사용하더라도 여전히 교정 기능을 사용하였으면 좋겠습니다. 예시 en:Page:รัฐธรรมนูญ (ฉบับชั่วคราว) ๒๕๕๗ (๒) ๒๕๕๙.pdf/1--Namoroka (토론) 2025년 1월 25일 (토) 18:22 (KST)

이 모든 문제는 근본적으로 "한문"과 "중국어"의 경계가 불명확해서 생깁니다. 한문이라고 하나로 이야기하긴 하지만 단어만 한자로 쓰는 경우("한국식 한문")부터 중국어로 번역한 것이나 다름없는 수준까지 넓게 분포하기 때문에 어디까지 한국어의 변형인지, 어디부터 중국어인지 선을 긋기가 어려우니까요. 실제로 과거 토론에서도 관련한 문제가 논의된 적도 있습니다. 이런 문제로 인해 한문은 "번역", "해석", "풀이" 등 온갖 용어가 섞여 사용되긴 하는데, 저번에 총의를 수렴할 때는 "그래도 한문은 한국어에 속하니까 "번역"은 아니지 않은가"라는 의견이 상당수 제기되어서 이를 반영한 제안입니다. --Aspere (토론) 2025년 1월 25일 (토) 20:08 (KST)

또한 한자를 음으로 자동으로 변환하는 것은 저도 정말 보고 싶은 기능인데, 한자와 한자음이 한국어에서 간체-정체 관계처럼 일대일로 대응되지 않기 때문에 그런 예외를 전부 처리해주려면 굉장히 어려울 것 같습니다. 예를 들면 "金"은 거의 항상 "금"으로 읽지만 사람 이름에 들어가는 순간 전부 "김"으로 읽는데 소프트웨어적으로 일반 단어와 인명을 구분해주기가... 만들 수만 있으면 국한문 혼용 문헌의 접근성이 엄청 좋아질 것 같습니다. --Aspere (토론) 2025년 1월 25일 (토) 20:08 (KST)

중국어 위키백과에서도 기본 변환 테이블은 있지만 그렇지 않은 것은 -{zh-tw:歐; zh-cn:奥; zh-hk:奧}--와 같이 지정하고 있고, 한국어 위키문헌에서 필요한 기능은 각 언어별로 양방향 전환이 필요한 중국어와 달리 한자 → 한글 단방향 변환만 필요하기에 더욱 쉬울 것이라고 생각했는데, 이제까지 이러한 논의가 없었나 보네요. 하여튼 이건 나중에 따로 해야하는 얘기입니다. / 원문이 아닌 모든 한국어는 번역 이름공간으로 가지 않는 것이군요. 그렇다면 해석 이름공간에는 "현대 한국어로 풀어서 설명한 것"만을 포함하고, 단순히 한자를 한글로 옮긴 것은 포함하지 않는 건가요? 아님 해석 문서에 가능하면 둘 다 기재하는 건가요?--Namoroka (토론) 2025년 1월 25일 (토) 22:58 (KST)

둘 다 포함하는 것을 생각하고 있습니다. 제가 "정리가 필요하다"라고 하는 가장 큰 이유가, 원문도 원문에 따라 한자만 있는 경우, 한글 독음을 달아둔 경우, 원문 내에서 아에 풀이까지 해주는 경우가 모두 있는데 독음을 달아주는 것을 포함해 원문에 무엇인가를 보충하는 것을 편집자의 영역으로 넘겨버리면 독자 입장에서 원문에는 없는데 따로 달아준 것인지, 아니면 원문에 이미 있던 것인지를 구분할 수 없을 테니 확실히 구별해 표시할 필요가 있다고 하는 것이기 때문입니다. 덧붙여 "위키문헌은 원문을 그대로 넣는 곳"이라고 소개하면서 정작 저런 것 하나하나를 봐 주기 시작하면 결국은 "어디까지 괜찮은가"라는 문제가 생기고 결국은 다시 중구난방으로 돌아가는 셈일 것이고요. --Aspere (토론) 2025년 1월 25일 (토) 23:07 (KST)

자바스크립트를 통한 "해석" 버튼 표시

이름공간을 실제로 도입할 경우 원문과 해석문을 유기적으로 연결해 줄 방법이 필요하다고 생각합니다. 단순히 상단에 틀을 부착하는 방식도 나쁘지는 않으나, 타 사이트에서 영감을 얻어서 상단에 링크 버튼을 추가하는 스크립트를 제작해왔습니다.

스크립트 설명

일반 이름공간(ns:0)의 문서일 경우 "문서"와 "토론" 사이에 "해석"으로 가는 링크를, 해석 이름공간(가칭)의 경우 "해석"과 "토론" 사이에 "문서"로 가는 링크를 삽입해줍니다. 도입 시 아마도 미디어위키:common.js에 해당 내용을 삽입해서 모든 사용자에게 표시되게끔 해야 하지 않을까 싶습니다.

스크립트 실험판

크게 두 버전을 만들었는데, 둘 중 어떤 것이 더 나을지 아직 결정하지 못했습니다. 관련해서 여러분의 의견을 꼭 받고 싶습니다.

버전 1: 상대편 문서가 없을 경우 빨간 링크로 표시합니다.

• 장점: 문서를 만들어줄 수 있다는 것이 가시적으로 보이는 만큼, 활동 유도에 효과적입니다.
• 단점: 모든 문서가 해석문을 필요로 하는 것은 아니다 보니, 너무 과도한 표시가 될 우려가 있습니다.

버전 2: 상대편 문서가 없을 경우 아에 링크를 표시하지 않습니다.

• 장점: 깔끔하고 해석문이 필요 없을 경우에 편리합니다.
• 단점: 해석문으로 가는 링크가 없어지는 셈이다 보니 일반 사용자 입장에서 접근하기 어려워집니다.

토론 문서도 존재하지는 않지만 빨간 링크로 표시하고 있으며, 영어 위키낱말사전 등에서는 Citations 이름공간이 별도로 있는데 이 경우에도 문서가 없더라도 그대로 표시하고 있으므로 첫 번째가 맞다고 생각합니다. en:wikt:위키백과 필요 없는 문서에서는 별도 틀로 숨길 수 있으면 좋겠네요. 추가로 여기에서도 Gadget-DocTabs.js를 이미 사용 중입니다.--Namoroka (토론) 2025년 1월 25일 (토) 23:04 (KST)

옳으신 말씀입니다. 또 그걸 어떻게 구현해야 하는지 공부해와야겠네요... Aspere (토론) 2025년 1월 25일 (토) 23:13 (KST)

스크립트 사용해 보기

특수:내사용자문서/common.js에 다음 줄을 삽입해 주세요. 두 개를 동시에 넣지 마세요!

• 버전 1: importScript("User:Aspere/haeseoktest.js"); (사용자:Aspere/haeseoktest.js)
• 버전 2: importScript("User:Aspere/haeseoktest-withoutlink.js"); (사용자:Aspere/haeseoktest-withoutlink.js)

현재 스크립트는 "해석" 이름공간이 없는 만큼 "번역" 이름공간으로 작동하게끔 설계되어 있습니다. 그래서 표시되는 모습은 언간독 및 번역:언간독 문서를 보시는 것이 제일 좋습니다. --Aspere (토론) 2025년 1월 23일 (목) 18:31 (KST)

일단 첫 번째 버전부터 common.js 생성을 통해 테스트합니다. --Jeebeen (토론) 2025년 1월 24일 (금) 13:54 (KST)

• User:Aspere/haeseoktest.js

코드를 검토하기 위해 링크를 달아 놓습니다. --Jeebeen (토론) 2025년 1월 24일 (금) 13:56 (KST)

링크를 좀 눈에 잘 띄게 걸어둘 걸 그랬네요. 신경써 주셔서 감사드립니다. --Aspere (토론) 2025년 1월 24일 (금) 14:13 (KST)

가젯으로 Gadget-DocTabs.js라는 비슷한 기능이 있고, 이 기능은 하위 문서를 탭으로 보여주는 기능이라 1:1 비교는 어렵겠으나 API 사용을 더 선호하여 선택하신 까닭이 있으실까요? --Jeebeen (토론) 2025년 1월 24일 (금) 14:15 (KST)

사실 저도 JS를 완벽히 이해하고 있지도 않고 JS 실력이 안 좋기 때문에 상세하게 조언해 드리기는 좀 어렵습니다. --Jeebeen (토론) 2025년 1월 24일 (금) 14:16 (KST)

간단한 이유입니다. 제가 API밖에 몰라서... 저도 이것저것 조합하면서 만든 것이고 "하여튼 작동하니 좋았쓰" 마인드로 완성해서 아마 분명히 개선점이 많으리라 생각합니다. Aspere (토론) 2025년 1월 24일 (금) 14:16 (KST)

저도 왜 API를 썼는지 이유가 궁금해서 여쭤 본 거고, JS에서 API를 사용하는 게 구체적으로 어떤 영향이 있는지는 잘 모릅니다. 사실 자바스크립트는 사용자가 사용 중인 컴퓨터나 장치의 에셋을 사용하는 거고, 루아나 API는 서버 에셋을 사용하므로 사실 그 사실만 놓고 본다면 API 써도 문제는 없지 않나 싶습니다. --Jeebeen (토론) 2025년 1월 24일 (금) 15:27 (KST)

$.ready는 현재 depracted된 표현입니다.--Namoroka (토론) 2025년 1월 25일 (토) 23:08 (KST)

(대충 진짜 몰랐다는 답변) 혹시 어떻게 고치면 좋을지 조언을 받을 수 있을까요? --Aspere (토론) 2025년 1월 25일 (토) 23:11 (KST)

제가 다른 사항과 착각하였습니다. 그대로 사용하셔도 무방합니다.--Namoroka (토론) 2025년 1월 26일 (일) 18:12 (KST)

환경설정의 소도구 베타 단락에 해당 코드를 추가해두었습니다. / 버전 1은 해석을 쓰지 않는 문서가 절대 다수이므로 쓰지 않는 것이 맞다고 생각합니다. 버전 2의 경우 현 구조상에서는 원문은 없고 해석만 존재하여 원문에서 해석 이름공간으로 넘겨주기가 되어있으면 여전히 링크가 표시됩니다. 오즈의 마법사 → 번역:오즈의 마법사의 사례처럼요. 오즈의 마법사 문서가 존재하니 "문서" 탭이 표시가 되지만 눌러보면 넘겨주기입니다.--Namoroka (토론) 2025년 7월 4일 (금) 23:54 (KST)

감사합니다! (제안자로써 부끄럽습니다만) 제가 현실에서 바쁜지라 이 제안에 지금 신경을 못 쓰고 있기도 하고, 아에 다른 해석문까지 한 번에 싸잡아서 정리해버리는 편이 더 나은 것 같아서 일단은 잊어버린 척 보류 중입니다. 그래도 다른 분들께서 의견이 있으시다면 남겨 주시면 정말 감사할 것 같습니다. 덧붙여서 다시금 도와주셔서 정말 감사합니다! 기술 쪽은 정말 하나도 몰라서 손가락을 벌벌 떨면서 작업하는지라 다른 분이 도와주시면 정말 안심이 됩니다. Aspere (토론) 2025년 7월 6일 (일) 21:28 (KST)

최종 도입 제안

처음 도입 제안을 남긴 것에 비해 굉장히 늦어졌지만 최종적으로 이름공간 도입에 관해 총의를 모으고자 합니다. 당초 제안에서 몇 가지 사항을 구체화했습니다.

그림 1: 홍길동전 문서를 예시로 든 해석 문서 구조의 설명입니다. 홍길동전 문서에 대해 해석:홍길동전 문서는 만들지 못합니다. 이는 홍길동전 문서가 판본 문서로 문헌의 내용("본문")이 없기 때문입니다. 대신 각 판본에 해당하는 홍길동전 (30장 경판본), 홍길동전 (36장 완판본), 홍길동전 (김유정) 문서는 해석 문서로 만들 수 있습니다.

그림 2: 시편 문서를 예시로 든 구조 설명입니다. 시편 문서에 대해 해석:시편 문서는 위와 같은 이유로 만들지 못하며, 번역:시편 문서는 존재할 수 있지만 번역해석:시편 문서는 존재할 수 없습니다. 시편의 각 판본에 해당하는 시편촬요나 셩경 개역/시편 등에는 해석 문서를 만들 수 있습니다.

1. 해석 문서의 도입 구조: 동음이의어 문서, 판본 문서, 번역본 문서의 구분이 확실해진 것에 맞추어, 각 "문서"에만 만들 수 있게끔 하고자 합니다. 자세한 설명은 그림 1을 참조해 주세요.
   • 또한 번역 문서와 겹칠 경우, 번역 문서 자체도 어느 정도 해석의 기능을 하는 만큼, "번역에 대한 해석"은 하지 못하게끔 하고자 합니다. (여기서 "번역"은 위키문헌의 자체 번역을 말합니다) 자세한 설명은 그림 2를 참조해 주세요.
2. 문서 좌상단에 해석 링크를 표시해주는 소도구는, 문서가 없는 경우 링크를 표시하지 않는 버전(버전 2)으로 하고, 이 소도구를 기본적으로 활성화되게끔 설정하고자 합니다.
   • 위의 의견처럼 "기본적으로 표시하되 숨기는 방법"도 좋지만, 현재 시점에서는 현실적으로 부작용이 클 것 같습니다. 이 부분은 나중에 바꿀 수 있는 만큼 일단 도입하고 차후 변경하는 방향으로 하면 좋을 것 같습니다.
3. 국한문 혼용 문서에서 한자음만을 한글로 바꾼 문서는 일단 해석 문서로 옮기되, 위에 나온 의견처럼 도구 형식으로 처리가 가능해지면 그 때 삭제하는 방향으로 하고자 합니다.
   • 누가 안 만들어줄까요... (속마음)
4. 해석 이름공간의 머리말 틀은 일단은 현행처럼 기본 {{머리말}} 틀을 사용하고자 합니다.
   • {{번역 머리말}}은 약간 어울리지 않아서 새로운 틀을 만드는 것도 좋아 보이나, 이름공간 도입에 비해 틀은 상대적으로 금방 만들 수 있는 만큼 그리 급해 보이지는 않습니다. 그리고 어차피 지금도 틀 구분 안 하고 쓰는데 특별히 문제 없기도 하고요.
5. 이 지침 도입에 따라 위키문헌:해석 문서를 뜯어고칠 필요가 있으며, 위키문헌:한문 해석문의 수록 지침은 자동으로 폐기됩니다. 관련 내용이 있는 지침이나 도움말도 맞추어서 변경할 필요가 있습니다. 당연한 것이지만 그래도 언급을 남기는 것이 맞다고 생각했습니다.

위의 논의에서 도입 자체에 관한 총의는 어느 정도 모였다고 생각하지만, 처음 말을 꺼낸 뒤로 시간이 좀 지난 만큼 다시 한 번 확인하고 넘어가고자 합니다. Aspere (토론) 2025년 8월 25일 (월) 23:21 (KST)

phab:T406405, gerrit:1193521.

총의 재확인을 위해 기존 토론 참여자를 호출하오니 의견을 남겨 주시면 감사하겠습니다.

@NZ 토끼들, Respice post te, Jjw, Namoroka, Jeebeen: — regards, Revi 2025년 10월 4일 (토) 17:52 (KST)

패치와 관련해서 한 가지 의견을 드리자면, 혹시 (굳이 필요하다면) 이름공간의 영어 명칭은 'Annotation'으로 해 주실 수 있을까요? 영문판 위키문헌에서 사용하는 용어이다 보니 그렇게 하는 편이 연결(연상)하기 쉬울 것 같습니다. Aspere (토론) 2025년 10월 4일 (토) 17:55 (KST)

 완료 — regards, Revi 2025년 10월 4일 (토) 17:58 (KST)

찬성 -- Jjw (토론) 2025년 10월 4일 (토) 22:09 (KST)

찬성합니다.--Namoroka (토론) 2025년 10월 5일 (일) 14:54 (KST)

찬성합니다. -- NZ 토끼들 (토론) 2025년 10월 13일 (월) 15:48 (KST)

17시 전후로 적용되었습니다. — regards, Revi 2025년 10월 13일 (월) 17:21 (KST)

저자 문서의 등재 기준 ("문헌이 1개 이상 등재되어 있을 것") 신설 제안

저자 문서 정리 중 저자 문서의 취지에 맞지 않게 "홍보성"으로 보이는 문서가 일부 보여 제안합니다. 원래 저자 문서의 취지는 그 사람이 작성한 문헌을 한 번에 볼 수 있게끔 하는 목록 문서의 역할을 하는 것인데, 정작 문헌은 없이 저자의 소개만 있거나, 수십 개가 나열되어 있기는 하지만 전부 저작권에 걸려 있어 단시일에 등재가 가능해질 가능성이 굉장히 희박한 경우가 있습니다. 이러한 문서는 위키문헌의 목록이기보다는 위키백과에 들어가야 할 "인물의 소개"에 더 가깝다고 생각하는 만큼, 지양해야 한다고 생각합니다.

이에 따라서, 저자 문서의 등재 기준으로서 "위키문헌 내 문서가 1개 이상 등재되어 있을 것"(색인 문서 포함)을 제안합니다. 단순히 저자 문서에 (링크 없는 단순 텍스트를) 나열하는 것이 아니라, 그 문서가 실제로 존재하는지를 따지고자 합니다. 인터위키 여부도 생각해 보았는데, 그러면 결국 "한국어 위키백과"로 링크 걸어두고 우기는 문제가 생길 수도 있다고 생각하여 제외하였습니다. Aspere (토론) 2025년 8월 15일 (금) 15:36 (KST)

구체적인 사례를 알 수 있을까요? 개인적으로는 문서 1개 이상을 정하는 것보다 건별로 검토하는 것이 더 나을 것 같습니다. 문서는 생성되지 않았지만 색인 문서만 먼저 정리되어 생성될 수도 있는 것이고요.--Namoroka (토론) 2025년 8월 22일 (금) 16:05 (KST)

제가 작업 중에 봤던 문서는 저자:성재기 (1933년)나 저자:강유원 정도가 있었습니다. 저자:빅토리아 빅터나 저자:어니스트 헤밍웨이 같이 있을 법 하지만 문서가 없는 경우도 있었고요. 아마 제대로 살펴보면 훨씬 많으리라 생각합니다. 이러한 문서들은 저자의 소개(광고)에 가깝지, "위키문헌 내 문서를 쉽게 찾을 수 있게끔 하는 목록"의 기능은 전혀 하고 있지 않습니다.

또한 덧붙여, 말씀하신 것처럼 "색인 문서가 먼저 생길 수도 있다"의 가능성도 고려해서 색인 문서도 포함해 산정하자고 제안에 적어두었던 것입니다. Aspere (토론) 2025년 8월 22일 (금) 16:46 (KST)

취지에는 동의합니다만 개인적인 의견으로는 결국 건별로 삭제 토론을 하는 것이 옳다고 생각됩니다. {{저작권 미소멸 저자}}에 해당하더라도, 해당 인물이 다른 자유 저작물에서 간접적으로 언급되는 경우에 색인 문서에 수록이 가능하기도 하고요..--Namoroka (토론) 2025년 8월 25일 (월) 16:26 (KST)

저는 반대로 그러한 경우를 예외로 허용해 주는 방향으로 가야 한다고 생각합니다. 현재의 문제는 근본적으로 "기준이 없다"에서 비롯되는 만큼, 기준을 마련해 놓고 "여기에는 안 맞지만 놔둘 만 하지 않을까"로 의론이 흘러간다면 전혀 문제 없겠지만, 말씀해 주신 대로라면 "뭐 특별히 하지 말라는 법은 없지만 지워야 할 거 같으니까 지우자"를 장려하자는 모순이 생깁니다. 그냥 아무런 사용 없이 저자 문서만 툭 던져두는 것은 애초에 저자 문서의 존재 이유가 아닌 만큼 막아야 한다는 의견입니다. Aspere (토론) 2025년 8월 25일 (월) 16:35 (KST)

(약간 다른 이야기이지만) 색인 문서의 란에 해당 저자를 입력할 수 있을 정도로 관련이 있다면 해당 저자 문서에 직접 목록 방식으로 언급할 수 있는 만큼, 제 제안과 모순되는 점은 없다고 생각합니다. Aspere (토론) 2025년 8월 25일 (월) 16:37 (KST)

en:Help:Author pages와 같은 문서를 생성하는 것이 우선 필요해 보입니다.--Namoroka (토론) 2025년 9월 11일 (목) 15:16 (KST)

그렇다면 해당 문서를 만들고 지침으로 만들 때 다시 논의하도록 하겠습니다. Aspere (토론) 2025년 9월 18일 (목) 11:09 (KST)

위키컨퍼런스 서울 2025 관련 안내

안녕하세요 여러분,

공지가 약간 늦었습니다만 10월 25일에 위키컨퍼런스 서울 2025가 열립니다. 위키미디어 프로젝트에 관심있는 사용자라면 누구나 참여하실 수 있습니다.

아울러 위키컨퍼런스 서울 2025에 대한 중앙공지(Centralnotice)를 준비중입니다. 중앙공지는 메타에서 설정한 프로젝트의 상단에 알리는 공지로 사이트노티스와 유사합니다. 10월10일부터 25일까지 위키컨퍼런스 서울 2025에 대한 중앙공지가 진행될 예정입니다. 이와 관련하여 사전에 공지하고자 합니다. 감사합니다.--Youngjin (WMKR) (토론) 2025년 9월 15일 (월) 10:38 (KST)

자세한 내용은 meta:CentralNotice/Request/WikiConference Seoul 2025를 참조하세요.--Youngjin (WMKR) (토론) 2025년 9월 16일 (화) 13:07 (KST)

Revibot I

이런저런 사유로 위키문헌에 오랜만에 들어온 김에 다른 한국어권+타 몇몇 위키에서도 돌리고 있는 Revibot I을 가지고 와 봤습니다.

{{사용자:Revibot/Archive
|archive = {{SUBST:FULLPAGENAME}}/보존/REPLACE_HERE
|algo = old(90d)
|maxarchivesize = 100K
|counter = 1
|archiveheader = {{보존}}
|minthreadstoarchive = 2 <!-- 기본값 -->
|minthreadsleft = 5 <!-- 기본값 -->
}}

• 보존/ 뒤 REPLACE_HERE 를 %(year)d(연간 보존 시) 또는 %(counter)d(카운터 기반 보존 시) 로 대체하여야 합니다.
  • 연간 보존 시 maxarchivesize와 counter는 지워도 됩니다.
• algo는 보존 봇이 동작하는 시점 (한국표준시 기준 00시, 12시 전후)에 이 기간 이상 오래된 게시글을 보존할 지 결정하는 데 사용됩니다. 이 값을 지정하지 않으면 봇은 기본적으로 24시간을 기준으로 잡습니다.
• minthreadstoarchive는 보존할 문단이 2개 이상이어야 보존하도록 하는 설정입니다. 기본적으로 문단 2개 이상이 보존 대상이어야 보존하며, 1로 변경하면 보존할 문단이 하나만 있어도 보존합니다.
• minthreadsleft는 보존한 후 남은 문단의 갯수를 지정하는 설정입니다. 기본적으로 문단이 5개 남도록 보존하며, 0으로 설정하면 문단이 하나도 남지 않도록 보존할 수 있습니다.
  • 기본값에 따르면 문단이 7개 이상일 때 문단 5개가 남도록 2개 문단을 보존하게 됩니다.
• maxarchivesize는 보존 문서의 최대 크기를 결정합니다. 해당 사이즈가 넘어가면 counter를 변경하고 보존 문서를 변경합니다. 보존 설정이 counter 기반이 아니면 의미가 없습니다.
• 2단계 문단(== 문단 ==)과 ~~~~ 서명이 포함되지 않으면 봇은 문단을 보존하지 않습니다.

기본적으로 사용자토론을 보존하기 위해 여러 곳에 들여온 것이긴 했습니다만, 그 외에도 커뮤니티 공간에서도 사용할 수 있으니 쓰실 분들이 있다면 유용하게 쓰시기를 바랍니다. — regards, Revi 2025년 10월 20일 (월) 14:33 (KST)

번역 절차 문의드립니다.

안녕하세요, 영어 위키문헌의 Calculus Made Easy 문서를 번역해 보려고 합니다. 그런데 위키문헌 기여가 처음이라, 시작하기 전에 절차상 의문점을 몇 가지 여쭙고 싶습니다.

1. 영어 위키문헌 페이지는 각 페이지의 PDF 스캔문서를 한 데 모은 형식으로 되어 있는데, 번역할 때에는 이와 무관하게 문서에 직접 텍스트를 입력하는 식으로 작성하는 것이 적절할까요?

2. 위키백과에서는 번역 기능을 사용해 왔기 때문에 언어 간 링크를 조작해본 일이 없습니다. 원본 문서와의 연결은 추후에 요청드리는 식으로 진행하면 될까요?

3. 번역 완료까지 시일이 다소 소요되리라고 예상하는데, 문서와 하위 페이지들에 {{초안}} 틀을 달았다가 나중에 번역 이름공간으로 이동을 요청드리면 될까요? Ymed16 (토론) 2025년 11월 9일 (일) 16:19 (KST)

위키문헌 활동에 관심을 가져 주셔서 감사드립니다. 번역에 관해서는 방법이 딱히 통일된 적은 없기 때문에, 특별히 주의가 필요한 내용은 딱히 없으리라 생각합니다.

1. 일단 현재까지 한국어판에 있는 번역 문서들은 직접 텍스트를 입력하는 방식으로 작성되어오긴 했습니다. 하지만 스캔 파일 자체는 여기서도 사용할 수 있는 만큼 (색인:Calculus Made Easy.pdf 문서를 만들면 아마 보이실 겁니다), 여기에다 직접 번역 텍스트를 입력한 다음 영어판처럼 끼워넣기 형태로 문서를 만드셔도 됩니다.
   • 두 번째 방식을 표준으로 지정하자는 의견이 과거에 있긴 했는데, 일단 논의가 진행된 적은 없습니다.
2. 인터위키 연결 자체는 그냥 쉽게 할 수 있는 만큼 나중에 생각하셔도 괜찮습니다. 일단 방법으로는, 해당하는 위키데이터 항목(d:Q5018893)에 만든 문서의 링크를 추가해주시면 됩니다.
3. 초안 이름공간을 사용하신다는 말씀으로 이해하였는데, 전혀 문제 없습니다. 사실은 그냥 번역 이름공간에서 직접 번역하셔도 전혀 문제 없는 만큼, 이 부분은 정말 편하신 대로 해 주시면 될 것 같습니다.

Aspere (토론) 2025년 11월 12일 (수) 15:57 (KST)

사랑방 자동 보존 도입 (#Revibot I)

위 문단의 내용과 관련되어 있지만 가독성을 위해 별도의 문단에 적습니다. 위키문헌 사랑방(지금 이 문서)의 보존을 자동으로 하게끔 해당 틀을 상단에 추가하였습니다. 보존 문서의 이름은 현재까지와 마찬가지로 순서(숫자)를 사용하게끔 해 두었습니다. 그렇게 중요한 내용은 아니지만 일단 기록을 위해서 적어둡니다. Aspere (토론) 2025년 11월 12일 (수) 16:02 (KST)

유니코드에 없는 한자가 있는 경우 어찌하면 좋을까요?

참고로 이런 내용도 보존 봇이 동작하기 위해서는 서명이 필요합니다. 보존한 사람의 서명을 아래에 다는 정도로 처리하시면 될 것입니다. — regards, Revi 2025년 11월 14일 (금) 15:12 (KST)