편집토론기록

리브레 위키:위키방/보존문서8: 두 판 사이의 차이

< 리브레 위키:위키방
500번째 줄: 500번째 줄:
* [https://meta.wikimedia.org/wiki/Separatism 분리주의]로 갈까요? 아니면 [https://meta.wikimedia.org/wiki/Mergism 병합주의]로 갈까요? --[[특수:기여/118.235.13.180|118.235.13.180]] 2021년 7월 15일 (목) 19:39 (KST)
* [https://meta.wikimedia.org/wiki/Separatism 분리주의]로 갈까요? 아니면 [https://meta.wikimedia.org/wiki/Mergism 병합주의]로 갈까요? --[[특수:기여/118.235.13.180|118.235.13.180]] 2021년 7월 15일 (목) 19:39 (KST)
: '분리주의'가 각각의 주제들이 개별 문서로 분리되어야 하는 것을 말한다면, '병합주의'는 그 반대로 사소한 주제들이 관련 메인 문서로 병합되어야 한다는 걸 말한다고 합니다. --[[특수:기여/175.223.31.240|175.223.31.240]] 2021년 7월 16일 (금) 15:38 (KST)
: '분리주의'가 각각의 주제들이 개별 문서로 분리되어야 하는 것을 말한다면, '병합주의'는 그 반대로 사소한 주제들이 관련 메인 문서로 병합되어야 한다는 걸 말한다고 합니다. --[[특수:기여/175.223.31.240|175.223.31.240]] 2021년 7월 16일 (금) 15:38 (KST)
::딱히 정해진거 없습니다. 그냥 개별 문서나 주제별로 다를 수 있겠네요. 일단 지나치게 길어지면 분리하는걸 권장하고 너무 적으면 합쳐두는게 아무래도 낫겠죠 --[[사용자:Chirho|Chirho]] [[파일:Chirho.png|17px]] [[사용자토론:Chirho|토론]] 2021년 7월 16일 (금) 16:16 (KST)


== 특수:올리기 안내 변경 제안 ==
== 특수:올리기 안내 변경 제안 ==

2021년 7월 16일 (금) 16:17 판


보존문서 기간 특이사항
보존문서1 2015년 4월 17일 ~ 2015년 4월 20일 이름 결정, 초기 골격 형성
보존문서2 2015년 4월 19일 ~ 2015년 4월 19일 스킨 결정
보존문서3 2015년 4월 20일 ~ 2015년 4월 30일 임시 관리자 선임
보존문서4 2015년 4월 30일 ~ 2015년 5월 12일 공모전 시행
보존문서5 2015년 5월 7일 ~ 2015년 5월 20일 제로보드 위키방의 개설, 마지막 정규운용
보존문서6 2015년 6월 29일 ~ 2015년 7월 3일 리브레 위키 6·29 게시판 폭파 사태
보존문서7 2016년 1월 24일 게시판 서버 점검
보존문서8 2021년 5월 25일 ~ 2021년 8월 3일 위키방 운영 중단에 따른 임시 게시판 사용


임시 개장

로그인 문제가 지체되는 관계로 임시 위키방을 개소합니다. 편집시 상단의 안내 문구는 당분간 무시하셔도 됩니다. --Centrair(센트레아) APP·DEP 2021년 5월 12일 (수) 23:54 (KST)

위키방에서 임시 위키방으로 링크되는 문서는 리브레 위키:위키방이지만 토론에 참여하고자 한다면 이 문서로 넘어와주세요.--ASHNIZ (토론) 2021년 5월 16일 (일) 14:43 (KST)
특수:환경설정#mw-prefsection-gadgets에서 "[편집] 링크를 화면의 오른쪽에 표시합니다."를 설정하고 문단의 편집 버튼을 누르면 자동으로 넘어와집니다. --Centrair(센트레아) APP·DEP 2021년 5월 16일 (일) 14:53 (KST)
일반 사용자는 보호된 문서에서 문단 편집 버튼이 뜨지 않습니다. --Liebesfreud (기여∙토론) 2021년 5월 16일 (일) 15:00 (KST)

관리규정 대규모 개정 제안

관리규정이 슬슬 오래되어 전체적으로 개정할 필요가 있다고 생각하여 제안합니다. 내용: 사용자:Pika/관리규정 개정안

크게 보면 3가지 개정입니다.

  1. 운영진 개편: 관리관, 감독관, 검사관 체제에서 현재의 리브룬과 레브로 전환합니다. 인원감축체제는 임기 무제한, 겸임 가능으로 축소됩니다.
  2. 투표에 관한 규정 신설: 현재 별다른 규정이 없는 투표에 대한 규정을 신설합니다.
  3. 선거에 대한 규정 재통합: 둘로 쪼개진 규정을 다시 통합합니다.
  4. 윤문과 용어 통일

몇 개(정의나 뭐 기타 신설)는 그냥 재미삼아 넣은 거라 자세히 안 보셔도 됩니다. 저도 꼭 통과될 걸 바라고 쓴 건 아니라서요 ㅋ;; --Pika (토론) 2021년 5월 13일 (목) 09:24 (KST)

우선적으로 대체된 것은 맞지만 임시 위키방으로 운영되는 중이다 보니, 구체적인 일자는 불분명하지만 빠른 위키방 정상화를 추진코자 함은 언급된 상황에서 시간적 제약도가 낮은 규모 있는 결정은 차후 탐색 편의상 정상화된 위키방에서 하는 것이 좋지 않을까 하는 생각입니다.
우선 든 생각들입니다.
1.서문
  • '모든 사용자는 일반적인 상식의 범주 안에서의 자유로운 활동을 언제나 존중받으며,'
    어감상 '범주 안에서의'로 규정하여 제약적인 성격을 더하면 좋겠습니다.
2.정의
  • 우선 이용약관에서 정의가 이루어지고, 이용약관에서 관리규정을 이용자 의무 사항으로 정하도록 되어 있는 만큼 관리규정에서 다시 다룰 의미에 의문이 있습니다.
  • 만약 추가하는 방향으로 의견이 모인다면 '관리규정에서 사용하는 용어의 정의입니다.': '관리규정에서 사용하는 용어의 정의는 다음과 같습니다. '와 같이 바꾸면 좋겠습니다.
3.1 기본적 금지사항
  • '2.토론, 문서 서술 등에서 타인의 존엄성을 훼손하는 행위'는 1항으로 지정하는 것으로 우선할 것이 좋겠습니다. 법 이전에 인간의 존엄이 우선한다고 여깁니다.
  • '1.아래의 불법정보를 게재하는 행위'는 이전과 같은 순번으로 분리하는 것이 좋을 것 같습니다. 공공질서나 미풍양속에 반하는 것이 반드시 법적으로 규제되는 것만에 해당하지는 않기 때문입니다.
  • 1.2.'게재함으로써 범죄가 되거나~'는 이전과 같이 간결하고 보다 넓게 아우를 수 있는 '불법적 자료 게시'로 할 것이 좋겠습니다. 불법 행위를 조장한다는 내용은 공공질서나 미풍양속에 반하는 것을 금지한다는 것으로 대체 가능할 수 있어 보입니다.
  • 불법적 자료에 대한 예시는 부정적 요인의 연상을 줄이고, 사이트 특성상 저작권을 중시하는 성격에서 기존 규정을 참고해 다음과 같이 작성되면 좋겠습니다.
    '불법적 자료 게시(예: 출판되었거나 유료서비스를 이용해야 접할 수 있는 자료의 일부 또는 전부 등재, 기밀 유출, 불법행위에 대한 설명 등)'
3.2 사용자 이름, 문서와 서명
  • 안내의 '사용자 문서 그리고 서명' 및 각 조항의 '사용자 이름, 문서와 서명'은 이전과 같이 '사용자 이름과 문서, 서명'으로 하면 좋겠습니다. '사용자 이름'과 '사용자 문서'는 '사용자'를 공유하는 명칭이지만 서명은 일반적인 용례상 그와 같은 성격이 덜하기 때문입니다.
3.5 다중계정
  • '다중계정 규정에서 사용하는 용어의 정의입니다.': '다중계정 규정에서 사용하는 용어의 정의는 다음과 같습니다. '와 같이 바꾸면 좋겠습니다.
4.2 운영진의 역할
  • 관리규정 전체를 통틀어 관리관, 감독관, 검사관을 리브룬과 레브로 바꾸는 논의는 다른 순서로 나누었으면 합니다. 정기선거 체제로의 진행시 세 직책으로 나뉘도록 되어 있던 것을 정기선거 체제가 아닌 현황에서 통합하는 것은 보다 충분한 검토가 이루어져야겠습니다.
4.4.2 선거권과 피선거권
  • 존대 반영: '다중계정 사용자의 경우, 선거권과 피선거권은 다중계정 중 하나에만 부여합니다. 또한 다중계정의 활동은 합산하여 처리합니다.'
4.5 인원감축체제
  • 존대 반영: 1. '운영진 정원 모집이 어려울 경우 사용자 의결을 거쳐 인원감축체제로 전환합니다. 발동시 정기선거 및 비정기선거를 중단합니다.'
  • 존대 반영: 3. '인원감축체제 시행 중에는 입후보 자격이 있는 사용자는 항상 투표를 통하여 운영자 선출에 나설수 있습니다.'
    • 존대 반영: 3.2. '선거권과 피선거권은 선거에 대한 규정에서 정의하는 사용자가 가집니다.'
4.7 운영자의 해임
  • 존대 반영: 2.2. '투표권은 선거에 대한 규정에서 정의하는 사용자가 가집니다.'
6.3 규정 개정에 관한 규정
  • 존대 반영: 5.'레브는 개정안에 대해 한 번 거부할 수 있으며, 사유를 첨부해야 합니다.'
--Text-Justify (메시지) 2021년 5월 14일 (금) 22:09 (KST)
대부분 동의하여 반영했습니다. 반영하지 않는 것에 대한 저의 생각을 아래에 정리했습니다.
  1. 범주 안에서의'를 사용하는 것이 제약적인 느낌을 주는 지는 잘 모르겠네요. 그런데 제 글을 다시 읽어보니까 말이 좀 이상하여 다시 수정해야 겠습니다.
  2. 정의는 약관에는 없는 '게시판' 때문에 넣은 것입니다. 사실 별 필요가 없다는 느낌이 들기는 합니다.
  3. 불법적 자료 게시에서 '출판되었거나 유료서비스를 이용해야 접할 수 있는 자료의 일부 등재'는 공정이용과 대치된다고 생각하여 뺐습니다.
긴 글 읽어주셔서 감사합니다. --Pika (토론) 2021년 5월 14일 (금) 23:17 (KST)
이거 하는 김에 약관 개정(문체 관련) 요청이 이전에 들어온게 있었는데 같이 처리하면 어떨까 싶습니다 --Chirho Chirho.png 토론 2021년 5월 18일 (화) 09:12 (KST)
약관 개정을 일반 사용자가 할 수 있나요? --Pika (토론) 2021년 5월 18일 (화) 18:36 (KST)
운영진이 직접 논의를 해야 할 사안 같긴 한데.... 정확히는 운영진이라기 보다는 법적 권리능력을 가진 사람들이 하는 것이 맞을 듯 싶네요. --Chirho Chirho.png 토론 2021년 5월 18일 (화) 21:46 (KST)

위키짱 이전 문서 처리 방법 논의

이미 몇몇 문서는 수정되었거나 일반 문서로 이전되었지만, 좀 더 체계적인 관리를 위해 처리 방법을 논의하는 것이 좋다고 생각합니다.

제가 생각하는 방법은 마당:문화에 하위 문서를 생성하여 각 개별문서의 처리방법을 논하는 것입니다. 다른 의견이 있으시면 아래에 남겨주세요. --Pika (토론) 2021년 5월 14일 (금) 19:43 (KST)

지침과 같이 쓰일 것으로 예상되는 만큼 임시로나마 위키방이 생성된 이상 위키방에서 진행하는 것이 더 어울리지는 않을까 합니다. --Text-Justify (메시지) 2021년 5월 14일 (금) 22:16 (KST)
위키방의 하위문서를 파서 논의하거나 아예 새 마당을 만드는 게 나을 것 같습니다. --Zlzleking (대화|편집 이력) 2021년 5월 14일 (금) 23:13 (KST)
아니면 예전 IRC 때의 사례를 참고해서 디스코드 채팅방에서 논의한 다음 로그를 보존하는 방법도 있고요. --Zlzleking (대화|편집 이력) 2021년 5월 14일 (금) 23:13 (KST)
위키방 하위문서도 괜찮을 것 같네요. --Pika (토론) 2021년 5월 14일 (금) 23:24 (KST)
저는 새 마당이 좋을 것 같네요! 아무래도 내용이 꽤 길어질 성싶거든요! --Unter (토론) 2021년 5월 15일 (토) 00:58 (KST)
마당으로 하게되면 마당:문화 하위문서보다는 마당:위키쨩이 더 좋을 것 같습니다. CÆRULEUM 토론 2021년 5월 15일 (토) 01:23 (KST)
위키방으로 의견을 냈습니다만 위키방 하위로 되잡습니다. --Text-Justify (메시지) 2021년 5월 16일 (일) 17:49 (KST)
  • 마당:문화 하위
  • 위키방
  • 위키방 하위
  • 새 마당
  • 디스코드
  • 위키방 하위
  • 새 마당
  • 마당을 쓴다면 새 마당
이런 의견들이 나왔습니다... --Text-Justify (메시지) 2021년 5월 16일 (일) 17:45 (KST)
그럼 의견이 많은 위키방 하위와 마당:위키쨩 둘 중에서 정하죠. --Pika (토론) 2021년 5월 16일 (일) 17:51 (KST)
제가 보기에 마당과 위키방 이들의 성격 차이는 공식적인 안건이냐 사용자 자율 안건이냐의 차이로 보이는데 그래서 전 위키쨩 포크는 공식적인 안건으로 분류하는 방향 즉, 위키방 하위로 토론하는게 맞을거 같아 보입니다. --ASHNIZ (토론) 2021년 5월 16일 (일) 20:56 (KST)
저도 하위문서에 한표요 --Chirho Chirho.png 토론 2021년 5월 18일 (화) 09:13 (KST)
찬성 하위문서가 나은것 같습니다.CÆRULEUM 토론 2021년 5월 18일 (화) 09:39 (KST)

의견이 거의 일치하여 위키방 하위에 문서를 만들었습니다. --> 리브레 위키:위키방/위키쨩 문서 처리 --Pika (토론) 2021년 5월 18일 (화) 18:52 (KST)

현관에 위의 안건들 홍보

위에서 논의 중인 안건 둘 다 중요하고 큰 안건으로 생각되는데 현관에 공지가 필요할 것 같습니다.--A$HNIZ 2021년 5월 18일 (화) 21:30 (KST)

리:운영진 요청을 경유하여 요청해주시면 됩니다. --Centrair(센트레아) APP·DEP 2021년 5월 19일 (수) 10:58 (KST)

현재 대량 삭제에 대하여

현재 Pika 님이 미사용, 발전 가능성 없음, 불필요한 동음이의 같은 말도 안 되는 주관적인 이유로 문서를 삭제 신청하고 있습니다. 저는 이런 삭제를 반대하며, 빨리 문서를 원상 복구하기를 촉구합니다. --Alzip (토론) 2021년 5월 22일 (토) 09:28 (KST)

의견 철회 --Alzip (토론) 2021년 5월 26일 (수) 18:41 (KST)
말도 안 되어 보이지는 않습니다. 포크 자료는 다소 빠르게 처리되는 감도 있는 듯 하지만 기존 문서를 보자면 대개 존치 의미가 있어 보이지는 않습니다. --Text-Justify (메시지) 2021년 5월 22일 (토) 22:24 (KST)
발전 가능성이란 주제는 상당히 주관적으로 보이며, 그런 이유로 삭제하는 것은 상당히 무책임해 보입니다.--Alzip (토론) 2021년 5월 23일 (일) 01:59 (KST)
포크 자료는 제 이의 제기 대상이 아닙니다--Alzip (토론) 2021년 5월 23일 (일) 02:00 (KST)
주관적이라고 생각하시나 발전 가능성이 낮아 보입니다. --Text-Justify (메시지) 2021년 5월 23일 (일) 13:07 (KST)
그렇다고 삭제하는 건 더 말이 안 돼는 발상인 것 같습니다.--Alzip (토론) 2021년 5월 23일 (일) 13:09 (KST)
교대역사.jpg 같은 사진은 직접 촬영에 별로 문제도 없어 보여서 지울 필요가 있나 싶기는 합니다. --Text-Justify (메시지) 2021년 5월 22일 (토) 22:28 (KST)
저는 파일에 대해서는 이의 제기 안 하겠습니다. 진짜 깨진 파일도 있네요... --Alzip (토론) 2021년 5월 23일 (일) 01:58 (KST)
교대역 사진은 현재 공사가 완료되어 큰 의미가 없어서 삭제요청했습니다. -- Pika (토론). 다른 사용자가 추가한 서명입니다. 서명은 --~~~~를 입력하여 남깁니다.
공사가 있었다 정도로 서술을 수정하면 해결될 문제가 아닐까요?--Alzip (토론) 2021년 5월 23일 (일) 10:11 (KST)
위키미디어는 아니지만 해당하는 자료는 어느 정도 저장소 역할을 인정해도 되지 싶습니다. 저는 보류 의견을 남깁니다. --Text-Justify (메시지) 2021년 5월 23일 (일) 13:07 (KST)

동음이의 문서에는 이의가 있을 수 있다고 생각합니다만(딱히 동음이의어 기준이 없기 때문에), 딴짓이나 한 사용자가 대량 등록한 극히 짧은 유튜버 문서는 필요가 없다고 생각합니다. 특히 교실에서 딴짓하는 법은 내용마저 형편없습니다. --Pika (토론) 2021년 5월 23일 (일) 03:58 (KST)

그렇다고 원래 있던 내용까지 없앨 필요는 없지 않습니까? 삭제를 하는 이유가 무었이죠?

참고로 제가 삭제 요청한 동음이의 문서는 아래 조건을 만족하지 않는 문서입니다. --Pika (토론) 2021년 5월 23일 (일) 04:01 (KST)

  • XX (동음이의) 문서: 문서 3개 이상 존재
당신만의 기준이 아닐까요? 누군가에게는 그 동음이의도 필요할 수 있습니다.--Alzip (토론) 2021년 5월 23일 (일) 10:07 (KST)
2개만 있는 경우에는 {{다른 뜻}}으로 넘겨줄 수 있으니 충분할 것으로 봅니다 --Centrair(센트레아) APP·DEP 2021년 5월 23일 (일) 12:51 (KST)
그거 괜찮은 생각인 것 같네요. 무작정 삭제만 하지 말고 후속 작업도 해주었으면 좋겠습니다.--Alzip (토론) 2021년 5월 23일 (일) 12:54 (KST)
반대편 문서가 존재해야 작업하는 의미가 있겠죠 --Centrair(센트레아) APP·DEP 2021년 5월 23일 (일) 12:58 (KST)
그건 또 그렇네요.--Alzip (토론) 2021년 5월 23일 (일) 13:09 (KST)
여태껏 그렇게 하고 있었습니다. --Pika (토론) 2021년 5월 23일 (일) 16:44 (KST)

아, 그리고 지금은 토론 중에 있으니, 더 이상의 삭제 행위는 멈춰주시기 바랍니다. --Alzip (토론) 2021년 5월 23일 (일) 10:13 (KST)

다른 이야기다만 삭제 문서를 퍼와도 틀:문서 가져옴을 붙여야 되는건가요? 발전가능성 없다고 삭제된 문서 유용하게 쓰일거 같은거 퍼왔고 가공해서 다른 문서 생성할 예정인데.--A$HNIZ 2021년 5월 23일 (일) 14:20 (KST)

발전 가능성 없는 사유로 삭제된 경우 대개 사전적 의미 정도만 적혀있는 경우가 많아서 문서 가져옴 틀을 부착하지 않아도 될 것 같습니다 --Centrair(센트레아) APP·DEP 2021년 5월 23일 (일) 14:38 (KST)
단순 사전적 의미는 내용은 어떻게 하나요? (제 사용자 문서 5.1문단 내용입니다.)--A$HNIZ 2021년 5월 23일 (일) 14:50 (KST)
5.1 문단을 보니 필요없을 거 같네요 --Centrair(센트레아) APP·DEP 2021년 5월 23일 (일) 14:59 (KST)

틀:소프트웨어 정보에 대하여

현제 토론으로 인하여 버전 표시는 릴리즈 노트로 대체하고 버전 표시는 비표준으로 있는데요, 이제 버전이 표시된 틀을 쓰는 문서들을 릴리즈 노트를 쓰게 만들고 속성을 삭제하려고 합니다. 무슨 방법 없을까요? --Alzip (토론) 2021년 5월 23일 (일) 12:13 (KST)

틀에서 표시 이름이나 입력값 표시 위치 방식은 틀을 고쳐서 바꿀 수 있습니다. 이렇게 하면 기존 문서를 바꾸지 않고 해결이 가능합니다. 다만 기존 문서에서 입력된 값 자체는 인력이나 봇으로 해결해야 합니다. --Text-Justify (메시지) 2021년 5월 23일 (일) 15:48 (KST)
제가 설명을 잘못한 것 같네요. 그게 아니라 틀:소프트웨어 정보에는 {{{버전 정보}}}라는 표준 속성과 {{{최신 버전}}}과 {{{안정 버전}}}이라는 비표준 속성이 있습니다. 비표준 속성을 쓰는 문서들을 다 버전 정보를 쓰게 만들고 비표준 속성들을 제거하고 싶습니다. --Alzip (토론) 2021년 5월 24일 (월) 06:12 (KST)

숫자 문서들에 대해서

대부분 숫자 문서들이 소인수분해나 어떤 수(소수 등)인지에 대한 내용 밖에 없습니다. 따라서 대부분 문서로서 제대로 기능하지 못하므로 삭제해야 한다고 생각합니다.

제가 삭제를 제안하는 문서는 -1, 0 ~ 10, 42나 144000 같이 숫자 이외의 내용(역, 원자, 등 번호 모두 제외)이 있는 문서를 제외한 나머지 문서가 그 대상입니다.

일부 1XX 문서는 통신망 식별번호로 넘겨줄 수도 있어 보입니다. --Pika (토론) 2021년 5월 24일 (월) 03:43 (KST)

그쪽이 인지도가 있어서 그런거죠? --110.70.54.196 2021년 5월 27일 (목) 15:46 (KST)

이의가 없어 삭제 요청 시작하겠습니다. --Pika (토론) 2021년 5월 26일 (수) 14:39 (KST)

같은 부류의 다른 대상과 비교하면 별다른 특징이 보이지 않으니까 삭제하는 거죠? --110.70.59.222 2021년 5월 26일 (수) 16:38 (KST)

네 그렇습니다. --Pika (토론) 2021년 5월 26일 (수) 17:52 (KST)

-1, 0 ~ 10, 12, 42, 100, 666, 144000을 제외한 나머지 숫자 문서에 삭제 신청했습니다. --Pika (토론) 2021년 5월 26일 (수) 17:52 (KST)

동의 못하는 부분이 있어서 의견 남겼습니다. 토론:11 문서 참고해주세요.--✉빛의 편지 ❤(대화) · ✑(기여) 2021년 5월 27일 (목) 16:44 (KST)

연도/날짜 문서, 분류, 틀에 대한 제안

현재 리브레 위키에서 연도/날짜 문서, 틀, 분류는 기준 없이 생성되었습니다. 제가 생각하기에는 여러 중복되거나 불필요하게 정보를 제공하는 등 매우 큰 수술이 필요하다고 생각합니다.

연도와 날짜 문서

현재 연도 문서와 날짜 문서에 모두 사건과 발매 등이 적혀 있는 등 중복된 역할을 담당하고 있습니다. 그런데 특정 날짜를 검색하여 어떤 사건이 있었는지를 볼 것 같지는 않습니다. 따라서 아래와 같이 제안합니다.

  • 사건, 발매 등은 모두 연도 문서로 넣는다. 단, 특정 주제의 연표가 있으면 해당 문서를 사용하고, 연표 문서 생성 장려.
    이는 연도 분류를 대체하기 위한 목적도 있습니다. (아래에서 자세히 설명)
  • 생일은 좀 애매한데, 생일을 유지하지 않는다면 날짜 문서는 월 문서로 통합.

--Pika (토론) 2021년 5월 24일 (월) 04:07 (KST)

각 날짜 문서에는 그 날짜에 해당하는 기념일이라는 게 있을 수 있네요. 이런 점까지 고려해 주시면 감사하겠습니다. --175.223.3.164 2021년 5월 26일 (수) 13:51 (KST)
알겠습니다. 고려해보겠습니다. --Pika (토론) 2021년 5월 26일 (수) 14:39 (KST)

별로 의견이 없어서 좀 더 지켜보고, 사건만 먼저 연도 문서로 옮기려고 합니다. --Pika (토론) 2021년 6월 21일 (월) 00:10 (KST)

아직까지는 사건을 연도 문서로 옮겨도 되지 않아도 될 것 같습니다. --118.235.10.180 2021년 6월 21일 (월) 01:38 (KST)

동의 못하는 부분이 있어서 의견 남겼습니다. 토론:3월 31일 문서 참고해주세요. --110.70.52.247 2021년 6월 26일 (토) 15:07 (KST)

사건 등을 모두 연도 문서로 넣자는 건 약간 급진적이라는 생각이 드네요. 하지만 연표 문서 생성을 장려하는 건 개인적으로 괜찮다고 봅니다. --118.235.5.15 2021년 6월 28일 (월) 18:01 (KST)

연도 분류

리브레 위키의 연도 분류는 위키백과처럼 매우 상세합니다. 하지만 굳이 색인으로 사용하는 분류를 그렇게까지 자세히 만들 필요가 없다고 생각합니다.

  1. 분류는 구글 등에 검색되지 않습니다. (굳이 분류:XX로 검색하지 않는다면요)
  2. 분류는 문서를 가나다 순서로 보여줄 뿐 다른 정보를 제공하지 않습니다. 따라서 목록을 제공하는데 알맞지 않습니다.
    따라서 목록을 제공하려면 대한민국의 철도/노선처럼 일반 문서를 이용하는 것이 더 맞다고 생각합니다.
  3. 즉, 분류는 문서간의 상관관계를 보여주거나 위키 관리용이면 족하다고 생각합니다.

따라서 사건사고 연도 분류를 제외한 연도 분류의 삭제를 제안합니다. (X년 출생/사망/설립/폐지 등) --Pika (토론) 2021년 5월 24일 (월) 04:07 (KST)

뭔가 이상한 위백식 분류도 같이 읽어보시면 좋을 것 같네요. --175.223.31.234 2021년 5월 24일 (월) 08:58 (KST)
시점 기준 분류가 다 없어지는지라 선뜻 동의하기는 망설여집니다. 이점이 미미하다는 것이 요지겠으나 반대로 삭제할 경우의 이점이 얼마나 될지 잘 모르겠습니다. --Text-Justify (메시지) 2021년 5월 25일 (화) 00:09 (KST)
연도 문서나 관련 주제 연표에서 해결하자는 의미입니다. 분류로 해결하면 문서마다 연도 문서로 연결하는 것은 이점이 딱히 없습니다. --Pika (토론) 2021년 5월 25일 (화) 00:17 (KST)
즉, 연도 분류 삭제의 목적은 연도 문서의 접근과 효용을 향상시키는 것입니다. --Pika (토론) 2021년 5월 25일 (화) 00:19 (KST)
별도 문서상에서 처리할 경우에는 누락되는 문제와 함께 직접 같이 입력하는 수고를 들여야 한다는 점이 걸립니다. 위키방:218835('폐교된 학교를 한꺼번에 보려면 어떻게 하면 될까요?')처럼 연도 문서 내에서 분류 표기를 삽입하는 방식도 있을 것으로 보입니다. --Text-Justify (메시지) 2021년 5월 25일 (화) 00:29 (KST)
개인적으로는 굳이 연도별로 상세분류를 달아놓을 이유가 뭔지가 궁금하네요. 실효성 자체도 별로 없는데다가(해봐야 문서 한둘입니다) 어지간하면 공통된 항목으로 묶을 수 있는건데 그걸 쪼개놓은 경우는 말 그대로 사족이죠. 년도 관련은 분류 처리보다는 개별 표같은걸 만들어서 단일 문서에서 처리하는게 어떨까 싶네요 --Chirho Chirho.png 토론 2021년 5월 25일 (화) 08:34 (KST)
동감합니다. 제가 생각하는 것과 동일하네요. --Pika (토론) 2021년 5월 26일 (수) 05:07 (KST)
분류토론:연도별 데뷔도 한 번 참조해 보시면 감사하겠습니다. --118.235.4.32 2021년 5월 26일 (수) 01:29 (KST)
저는 굳이 이런 분류가 있어야 하나 싶더라고요 연관된 각각의 1개 분류당 여러 문서가 어느 정도 나오면 모르겠는데 이 구조는 분류를 만들기 위한 분류 수준이라 생각하거든요 --Chirho Chirho.png 토론 2021년 5월 26일 (수) 11:21 (KST)

저는 메타문서는 되도록 줄이고 분류로 대체하자는 쪽이네요! 양쪽을 비교해봤을 때 분류 쪽이 관리 부담이 적거든요! --Unter (토론) 2021년 5월 26일 (수) 10:16 (KST)

확실히 목록보다는 분류가 편하기는 합니다. 그런데 분류명이 일관되지 않거나 제멋대로인 경우는 정리를 좀 해야 할 듯 싶네요. 또한 분류명 중 일본식 조어법인 "ㅁㅁのㅇㅇ"와 같은 분류명은 가능하면 최소화하는게 어떨까 싶습니다. 분류가 난잡해지는 주 원인이 년도 조합 분류와 일본식 조어법으로 된 혼합형 분류거든요 --Chirho Chirho.png 토론 2021년 5월 26일 (수) 11:21 (KST)
저도 분류명은 정리를 해야겠다 생각하는데 귀찮아서 나중으로 미루고 싶네요! 다만 그건 또 별개의 문제인 것 같으니 지금은 더 이상의 의견을 삼가겠습니다! --Unter (토론) 2021년 5월 26일 (수) 11:37 (KST)
저는 출생/사망/작품 등의 연도별 분류를 삭제하는 것은 반대합니다! 열람이든 편집이든 연도별 분류를 자주 이용하는 저의 입장에서는 이게 삭제되면 위키 사용이 많이 불편해지거든요! 분류 기능이 없어서 메타문서로 문서 목록을 만들던 과거 엔하계 위키 시절의 사례를 생각하면, 좋은 결과가 나오진 않을 겁니다! 어느 위키나 그렇지만 메타문서는 장기적으로 관리하기가 너무 번거로워요! 시간이 지나도 갱신되지 않거나 갱신 횟수가 적은 분야에만 쓰는 게 낫지 자주 갱신되는 분야에는 적합하지 않습니다! --Unter (토론) 2021년 5월 26일 (수) 11:37 (KST)
일단 연도를 사용해서 분류명을 무한증식시키는 방식은 가능한 지양해야 할 듯 싶습니다. 해봐야 한두개 문서밖에 안되면 연표처리하는것이 더 효율적일거라 생각되는데 반대로 문서양이 많다면 확실히 분류가 편하겠죠. 그리고 또 하나 염두에 두어야 할 것은 해당 분류의 상위 분류를 어떤 방식으로 할 것인지 같이 생각을 해 봐야 할 것 같습니다. --Chirho Chirho.png 토론 2021년 5월 26일 (수) 13:22 (KST)

우선 분류가 편리하다는 점은 동의합니다만, 현재 연도 분류가 너무 난립한다고 생각합니다.

  • 나라별 연도‎(연도별 ‎나라)
  • 데뷔‎
  • 분쟁‎
  • 사망
  • 설립‎
    • 개교
  • 스포츠‎
  • 작품
    • 드라마
    • 만화‎
    • 비디오 게임‎
    • 소설‎
    • 소프트웨어‎
    • 애니메이션
    • 연극‎
    • 영화‎
    • 음악
  • 조약
  • 출생
  • 폐지‎
    • 서비스 종료‎
    • 폐간
    • 폐교‎
    • 해체‎

위는 저희 위키에 있는 연도 하위 분류 목록입니다. 해당 분류에 대한 생각은 아래와 같습니다.

  • 앞서 말씀드렸다시피 사건/사고 연도 분류는 삭제를 주장하지 않습니다. 따라서 나라별 연도‎(연도별 ‎나라)[1], 분쟁‎은 제외 대상입니다.
  • 데뷔‎, 사망, 설립, 출생, 폐지‎는 분류로서 가치가 없다고 생각합니다.
  • 스포츠와 조약은 좀 애매하네요. 조약은 역사이기도 하고요.
  • 작품은 앞서 언급한 대로 메타 문서를 만들어서 설명을 곁들이면 좋을 것 같네요. 시리즈와 연동할 수도 있고, 문서간 링크가 많아져 검색 순위 상승도 노려볼 수도 있어 보입니다.

--Pika (토론) 2021년 5월 27일 (목) 20:50 (KST)

연도별 작품 분류를 메타 문서로 대체한다는 것에는 방대한 대상을 다루는 메타 문서가 인력으로 편하게 관리되리라고 생각하지는 않습니다. 누락 가능성과 추가적인 확인/편집을 감수해야 합니다. --Text-Justify (메시지) 2021년 5월 28일 (금) 01:16 (KST)
동의합니다. 분류로 나누는 것이 확실히 편하고, 메타 문서는 유입효과가 불확실합니다. --✉빛의 편지 ❤(대화) · ✑(기여) 2021년 5월 28일 (금) 01:27 (KST)
메타 문서는 봇으로 자동화해두면 편하지 않을까 싶네요. 아니면 메타 최상위 분류에 카테고리 트리를 걸어두면 조금 나을거 같습니다. --Centrair(센트레아) APP·DEP 2021년 5월 29일 (토) 16:34 (KST)

분류와 별도로 메타문서를 만드는 것은 확실히 효과가 있다고 생각합니다.

  1. 분류는 각 문서에 대한 부가적인 정보를 넣을 수 없습니다. 오로지 색인 역할만 합니다.
  2. 연도별 작품 메타문서(X년 일본/한국 애니메이션 또는 비디오 게임)를 생성하면 작품에 대한 간략한 설명뿐만 아니라 연도별 평가, 수상 등에 대한 정보도 넣을 수 있습니다. 이는 다른 위키에는 없으므로 유입효과가는 분명히 있을겁니다.

그리고 편하게 관리되지 않는다는 점은 동의하지만, 연도가 바뀌면 그 이전 연도는 갱신할 일이 거의 없습니다. 즉, 2022년이 되면 2021년 메타를 관리할 일은 적어지죠. 그 해 연도 분류는 유지하지만, 메타 문서에 서술을 마치면 분류를 삭제하는 방법을 사용할 수도 있습니다. --Pika (토론) 2021년 6월 13일 (일) 02:27 (KST)

당해년도 분류만 유지되는 형태가 되겠네요 --Centrair(센트레아) APP·DEP 2021년 6월 13일 (일) 11:09 (KST)
기존 분류를 지우지 않고 병행하여 사용한다면 달리 찬반 의견이 있지는 않습니다. --Text-Justify (메시지) 2021년 6월 14일 (월) 23:56 (KST)
메타문서에 서술되면 분류를 지우자는 것의 제 의견입니다. --Pika (토론) 2021년 6월 15일 (화) 01:36 (KST)
고정적이고 평소 큰 변동이 없는거면 메타문서로 가도 무방한데 자주 바뀌는거면 메타문서로 가기 좀 난감한거죠? 그거 아니고 현행화 관련이면 할만할 듯 싶습니다.(해당 기간 서술) 메타문서로 고정되면 굳이 분류를 유지할 필요는 없겠죠. 이 부분에 대해서는 합의가능한 영역이 있을 것으로 보입니다. --Chirho Chirho.png 토론 2021년 6월 18일 (금) 10:11 (KST)
각주
  1. ↑ 명칭 통일 필요

날짜 관련 틀

  1. 틀:출시일: 출시한 지 몇 년 되었는지를 굳이 보여줄 필요가 있을까요?
  2. 틀:날짜/출력: 많은 분들께서 사용하는 것 같습니다만, 사실 왜 사용하시는지는 모르겠네요. 그냥 [[X년]] [[X월 X일]]로 입력하는 것이 더 편하지 않나요? 틀:날짜, 틀:날짜/숫자따로, 틀:날짜/연월일입력, 틀:날짜/연월일입력/월, 틀:날짜/연월일입력/일 또한 마찬가지입니다.

하던 일이 있어 문체가 중구난방인 것은 이해해주셨으면 감사드리겠습니다;; --Pika (토론) 2021년 5월 24일 (월) 04:07 (KST)

둘 다 별로 유용한 틀은 아니지만 굳이 편집 역량을 소모해서까지 지울 필요가 있을지는 의문이네요! 지운다면 딱히 반대는 하지 않겠지만, 후속 조치 없이 틀만 지우겠다면 반대합니다! --Unter (토론) 2021년 5월 26일 (수) 11:44 (KST)
삭제로 합의되면, 단순하게 [[X년]] [[X월 X일]]로 치환하려 합니다. --Pika (토론) 2021년 5월 27일 (목) 20:24 (KST)

날짜/출력의 경우 월 부분이 각 년도 월별 문단에 링크가 걸리는 걸로 압니다. 단순히 [[X년]] [[X월 X일]]로 치환해도 무방하긴 합니다. 혹시나 다른 틀에 의존성이 걸려 있을 수 있으니 확인해볼 필요도 있겠네요 --Centrair(센트레아) APP·DEP 2021년 5월 27일 (목) 21:43 (KST)

확인을 해보았는데, 틀:날짜는 인용 틀에 사용되지만 링크가 걸리는 것은 아니기 때문에, 단순 치환하면 될 것 같습니다. 나이 관련 틀은 새로운 틀을 만들어서 넘겨주기로 충분할 것 같네요. --Pika (토론) 2021년 5월 27일 (목) 23:55 (KST)

날짜 관련 틀은 딱히 반론이 없어서 봇으로 전환한 후 삭제 요청할 계획입니다. --Pika (토론) 2021년 6월 13일 (일) 02:20 (KST)

질적 성장

리브레 위키의 질적 성장에 대해 고민해 보았으면 좋겠네요. --175.223.20.41 2021년 5월 24일 (월) 10:04 (KST)

동의합니다. 양질 다 잡는 것이 최고겠지만 안 되니까 양이냐 질이냐 일텐데 저는 질이 더 우선이라 봅니다. 어차피 양은 대형 위키를 이길 수가 없습니다. 저는 질을 높여서 대형 위키들과의 차이점을 두는게 맞는 것 같은데 또 양이 많아야 클릭수가 늘어나니까 즉, 양은 위키 생존 문제라서--A$HNIZ 2021년 5월 25일 (화) 14:30 (KST)
그래서 제가 주로 기여하는 문서가 리브레 시리즈입니다.--A$HNIZ 2021년 5월 25일 (화) 14:30 (KST)

소도구 조정 안내

개발진에서 popups 확장기능을 기본값으로 조정하여, 각주 소도구와 충돌할 수 있으니 사용자분들은 특수:환경설정#mw-prefsection-gadgets에서 각주 소도구를 해제하시기 바랍니다. --Centrair(센트레아) APP·DEP 2021년 5월 24일 (월) 10:06 (KST)

서버 폰트

서버 폰트 같은건 개발진분들께 문의를 드려야하나요? 한자 정보 틀에서 파이어폭스는 출력이 되는데 크롬으로 안나오는 폰트가 있어서요. --사용자:Cerulean/서명하기/ 2021년 5월 24일 (월) 16:23 (KST)

네. 간단한 문의는 리브레 디스코드 채널에서 답변 받을 수 있습니다 --Centrair(센트레아) APP·DEP 2021년 5월 24일 (월) 19:49 (KST)
혹시 이메일로도 연락이 될까요? 사용자:Cerulean/서명하기/ 2021년 5월 24일 (월) 21:31 (KST)

디스코드 채널 주소를 모릅니다.

bbs:205232에 있습니다. --Centrair(센트레아) APP·DEP 2021년 5월 24일 (월) 21:45 (KST)
어 위키방에 있네요...사용자:Cerulean/서명하기/ 2021년 5월 24일 (월) 22:31 (KST)

팝업 확장기능

팝업 확장기능을 제대로 활용하려면 문서의 글이 팝업에 나오도록 해야하는데 팝업 작동방식을 보면 문서 앞부분 틀을 제외한 문자열들만 출력되는 방식이다 보니 '== 개요 ==' 로 시작하는 문서 팝업을 띄워보면 '...' 만 뜹니다. 팝업 확장기능을 활용하기 위한 편집 지침 마련이 필요한 것 같습니다. 사용자:Cerulean/서명하기/ 2021년 5월 25일 (화) 15:45 (KST)

타이젠 문서는 마우스 올리면 ... 만 뜨고 우분투 문서는 사진과 문장이 잘 나옵니다.

최상단에 요약문이 없는 경우 popups에 요약이 나타나지 않습니다. 별도 지침이 필요하다기 보다는 요약을 적당히 다시 쓰는 방향으로 가는 쪽이 좋겠습니다. 기존 엔하식으로 쓴 문서들은 개요 문단을 무작정 올린다고 적절한 요약문이 되지 않는 경우가 많으니... --Centrair(센트레아) APP·DEP 2021년 5월 25일 (화) 16:42 (KST)

리브레 위키/역사 편집

오랜만에 리브레 위키/역사 문서를 편집했습니다. 17년부터 21년까지는 샅샅히 살펴봤고, 15, 16년은 문서에 적힌 것만 손봤습니다. 뭔가 사관이 된 느낌이네요ㅋㅋ

그다지 길지 않은 여러 리브레 위키 사건 문서들도 여기에 통합했습니다. 혹시 제가 빼먹은 중요한 사건이나 문구가 있다면 추가해주셨으면 합니다. --Pika (토론) 2021년 5월 26일 (수) 05:09 (KST)

노 사람(...) 문제

발전 가능성이 없는 문서 말이죠. 개인적으로는 노 사람(...)이 원인으로 생각하고 있는데요. 그 문제를 어떻게 해결하죠? --118.235.5.195 2021년 5월 26일 (수) 16:02 (KST)

"마토메"류들의 부족(?)

“ (전략) 한눈에 보기 좋게 정리한 "마토메"류들의 부족이 좀 눈에 띄는 것 같습니다. 이런 주제들은 위키백과에서도 손대기 어려울 뿐만 아니라, 나무위키에서의 이용층을 어느 정도는 흡수할 수 있다는 이점이 있죠. “
— 위키방:170565

기존 위키방을 둘러보다가 저런 걸 우연히 발견하게 되었네요. --39.7.14.205 2021년 5월 31일 (월) 18:27 (KST)

나라자료 틀들 재포크

현재 한국어 위키백과의 나라자료 틀들은 1768개인데 반해 리브레 위키의 나라자료 틀들은 281개 밖에 되지 않습니다. 이에 더해서 리브레 위키의 나라자료 틀들은 국기 변수가 없는 경우도 허다합니다. 언젠간 위키백과에서 나라자료 틀들을 다시 포크해야할 거라고 생각합니다. --Axzrich93 (토론) 2021년 6월 2일 (수) 16:25 (KST)

필요할 때마다 조금씩 당겨오면 될거 같습니다. --Centrair(센트레아) APP·DEP 2021년 6월 2일 (수) 16:49 (KST)

뜬금없는 질문이지만, 리브레 위키는 '내용이 긴 문서' 순위를 볼 수 있나요?

얼마 전에 SCP-6000: 악마 헥토르와 공포의 티타니아 문서를 게시했습니다. CCL이 호환되는 SCP 재단 사이트의 영문 문서를 번역했지만요.

이 문서의 분량이 약 17만 바이트 가량입니다. 어쩌면 리브레 위키 문서 중 가장 긴 문서일지도 모르겠다는 생각이 들었습니다. 그래서 문득 생각났는데 리브레 위키는 나무위키가 제공하는 것과 유사한 '내용이 긴 문서들' 을 볼 수 있나요? Creative (토론) 2021년 6월 3일 (목) 11:17 (KST)

특수:긴문서 보시면 됩니다. 테러방지법 필리버스터였나 그게 52만바이트 정도 됩니다. --Chirho Chirho.png 토론 2021년 6월 3일 (목) 11:22 (KST)

한 가지 궁금한 게 있습니다.

위에서 언급된 대량 삭제와 관련하여 질문할 게 있는데, 혹시 저명성 부족 때문 아닐까요? --118.235.13.162 2021년 6월 18일 (금) 04:06 (KST)

리브레 위키에서의 저명성 기준은 저쪽 대비 그렇게 빡빡하게 잡고 있지는 않습니다. 다만 합의에 의해서 불필요한 유사 문서 난립같은것이나 아무리 해도 별 내용이 없는 경우는 삭제가 가능한 부분이고요. --Chirho Chirho.png 토론 2021년 6월 18일 (금) 10:14 (KST)
저것보다는 다음을 말하는 거 같습니다.
  • 같은 부류의 다른 대상과 비교하면 별 다른 특징이 보이지 않는 경우
  • 내용이 지나치게 짧으면서도 더 이상 작성되기 어려운 경우

--110.70.59.34 2021년 6월 18일 (금) 18:34 (KST)

철도역 분류 간소화 제안

현재 철도역에 사용하는 분류는 다음 4가지입니다. (폐지 포함하면 5개)

  1. 노선: 경부선, 서울 지하철 1호선 등
  2. 운행계통: 수도권 전철 1호선 등
  3. 소재지: 서울 용산구의 철도역 등
  4. 관할: 서울관리역 등

하지만 대형 철도역일수록 분류가 많아지며, 서울역 문서를 PC에서 볼 때, hotcat을 키면 4줄, 꺼도 2줄이나 나옵니다. (도쿄역의 경우 도호쿠 신칸센, 도카이도 본선, 도호쿠 본선, 츄오 본선, 소부 본선, 케이요선, 마루노우치선, 요코스카선·소부 쾌속선, 츄오 쾌속선, 케이힌 도호쿠선, 야마노테선...으로 길게 나올 게 뻔합니다.) 모바일에서는 말할 필요도 없다고 생각합니다.

따라서 아래와 같이 분류를 간소화하는 것을 제안합니다.

  1. 노선, 운행계통: 물리적 노선만 유지
    사실 KTX나 무궁화호도 운행계통에 들어가기 때문에 '분류:KTX 정차역' 등의 분류도 생성할 수 있습니다. 그런데 이런 운행계통은 분류보다 문서로 보내는 것이 더 적절하다고 생각합니다. 물리적 노선과 운행계통 중 인덱스로 써먹기에는 노선이 적당하기 때문입니다.
    추가로, 간선 및 어느 정도 규모가 있는 지선(수인선 등)으로 한정하려 합니다. --Pika (토론) 2021년 6월 25일 (금) 07:19 (KST)
  2. 소재지: 현행 유지
  3. 관할: 삭제
    불필요한 과잉분류라고 생각합니다. 특히 영약가 없는 동작서비스안전센터같은 거요.

--Pika (토론) 2021년 6월 25일 (금) 00:10 (KST)

저는 소재지 분류도 더 간소화했으면 좋겠어요. 광역자치단체 정도로 (예: 서울특별시의 철도역) --118.235.5.63 2021년 6월 25일 (금) 20:01 (KST)

반대 의견이 없어서 관할 삭제부터 진행하겠습니다. --Pika (토론) 2021년 6월 29일 (화) 21:04 (KST)

다크모드

리브레 위키 다크모드 기능이 부실한 것 같습니다. 스마트폰 UI 차원에서 다크모드로 바꾸면 스킨이 자동 감지해서 다크모드로 바꿔주는 기능같은건 있는거 같은데 잘 안되네요. '기기의 다크모드 설정 무시하지 않기' 이런 옵션이 기본 설정되어 있긴 한데..

저는 그냥 브라우저에 확장기능 깔아서 쓰고 있습니다. 개인적으로 확장기능을 설치하지 않은 기기에서도 다크모드가 잘 작동하면 좋겠네요. 나무위키는 다크모드 기능이 잘 작동하던데 리브레 위키는 스킨에서 다크모드를 켜면 현관 문서 일부 틀에서 흰 배경이 그대로 나옵니다.

사용자:Cerulean/서명하기/ 2021년 6월 26일 (토) 12:38 (KST)

나무위키에서는 다크 모드 추가 이후 라이트/다크 모드에 따라 색상이 바뀌는 문법이 따로 추가되었지만 미디어 위키에서는 이를 해결할 수 있는 간단한 방법은 없는 것으로 알고 있습니다. 저는 보통 배경색의 투명도를 조절하는 방식으로 해결하고 있습니다. --Liebesfreud (기여∙토론) 2021년 6월 26일 (토) 18:57 (KST)
이슈트래커:208897 MW에 의존성이 있기 때문에 현 시점에서는 보류입니다. --Zlzleking (대화|편집 이력) 2021년 6월 29일 (화) 13:56 (KST)

분류 정리 방안

난잡한 분류들을 적당하고 합리적인 선 내에서 정리하는 건 어떤가요? (위키방:128579, 위키방:133356 참조) --118.235.9.5 2021년 6월 30일 (수) 10:02 (KST)

'철도역 분류 간소화 제안' 문단과 같이 최소한의 방향을 제시해야 의미 있는 논의가 진행되지 않을까 합니다. --Liebesfreud (기여∙토론) 2021년 7월 3일 (토) 19:45 (KST)

위키 작성 새 시리즈를 만들어 볼까 합니다.

시리즈:체계적인 위키 문서 작성과 같은 제목으로 위키 문서를 체계적으로 작성하는 법을 알려주는 시리즈를 만들려고 합니다.--Alzip (토론) 2021년 7월 3일 (토) 18:56 (KST)

시리즈:위키 작성, 당신도 할 수 있다!가 있습니다 --Centrair(센트레아) APP·DEP 2021년 7월 3일 (토) 21:02 (KST)
그것은 기초 작성법을 다루고요, 저는 좀 더 체계적이게 작성하는 방법(문단 구조 등등)을 중점으로 써 볼려고 해요.--Jellanie (토론) 2021년 7월 4일 (일) 02:16 (KST)
그건 도움말:좋은 글 쓰기와 겹치는 것 같습니다 --Centrair(센트레아) APP·DEP 2021년 7월 4일 (일) 09:52 (KST)
그러면 거기에 보충해 보죠.--Jellanie (토론) 2021년 7월 5일 (월) 08:03 (KST)

정보상자 css 일괄적용

{| class="infobox {{#if:{{{테두리색|}}}|border-color-custom}}" style="width: 26em;{{#if: {{{테두리색|}}}|border: 2px solid {{{테두리색}}};}}"

제가 정보상자 틀에 테두리를 지정하면 테두리가 겉에 안에 두 개가 되어서 테두리가 틀에 떨어져버리는 일을 막기 위해 틀:정보상자/styles.css을 작성했었습니다. 이 css를 미디어위키:common.css에 제가 관리자분께 추가를 요청드려서 틀:정보상자 칸 틀:정보상자 그림칸을 사용하는 틀까지 일괄 적용시키려합니다. 그런데 [style*="solid"]를 사용한게 좀 안전하지 않은거 같아서 틀:정보상자/styles.css에 있는 .infobox[style*="solid"]을 .infobox.border-color-custom처럼 바꿀려고 합니다. 앞으로 편집을 하실때 추가를 하셨음합니다. 기존에 있던 틀은 봇으로 바꾸든지 하면 됩니다.

1. 위에 나온 css 문서를 미디어위키:common.css로 옮기면 어떤 문제가 생길지를 모르겠습니다. infobox 클래스를 쓰는 문서가 엄청나게 많아서 일괄 적용시킬때 문제가 발생할 것 같습니다.

2. border-color-custom 클래스 이름이 너무 길어서 단축이 필요합니다. 가능하면 bordered로 변경할려고 합니다.

사용자:Cerulean/서명하기/ 2021년 7월 3일 (토) 22:35 (KST)

그건 <templatestyles>를 사용하면 css가 문서 전체에 적용되기 때문입니다. --Pika (토론) 2021년 7월 4일 (일) 10:16 (KST)
아 제가 멍청했네요. 알고있던건데 사용자:Cerulean/서명하기/ 2021년 7월 4일 (일) 10:19 (KST)

Crystal button cancel.svg 틀스타일을 추가하거나 클래스를 추가하거나 이런 작업이 비슷하게 시간을 소모하는 것 같습니다.

시리즈:리브레 한자사전

6월 28일 쯤에 시리즈:리브레 한자사전을 만들었습니다. 관심있으신 분들은 참여해주시면 좋겠습니다. 사용자:Cerulean/서명하기/ 2021년 7월 4일 (일) 10:15 (KST)

위키백과 분기 문서

위키백과에서 분기하는건 CCL상 문제가 없는데 단순 분기는 삭제 사유가 되나요?

삭제를 피하려면 어떻게 하면 되나요 사용자:Cerulean/서명하기/ 2021년 7월 9일 (금) 12:53 (KST)

단순 분기만으로 바로 삭제하지는 않으나 내용상 의미가 없다면 삭제할 수도 있습니다. 내용 추가 좀 하시는게 제일 쉬울것 같습니다만 --Chirho Chirho.png 토론 2021년 7월 9일 (금) 12:58 (KST)
위키방:208144 한국어권 포크 제한에 대해
이런 바탕이 있습니다. --Text-Justify (메시지) 2021년 7월 9일 (금) 13:14 (KST)
"그대로 베껴오는 건 별 의미가 없다고 생각합니다." 그렇다면 그대로 배끼지 않는다면 제한적으로 허용이 된다는 건가요? 저도 다른 유저분들에 비하면 뉴비라..
정보 얻어갑니다.Caeruleum (토론) 2021년 7월 9일 (금) 13:28 (KST)

위키백과에서 내용 일부만 가져온 경우에도 해당되나요? Caeruleum (토론) 2021년 7월 9일 (금) 13:12 (KST)

일부만 가져온 내용이 상당수이거나, 구태여 그렇게 가져올 의미가 없으면 지우고 다시 쓰는 편이 낫지 않을까요. --Text-Justify (메시지) 2021년 7월 9일 (금) 13:19 (KST)
아 그렇군요 Caeruleum (토론) 2021년 7월 9일 (금) 13:23 (KST)
위키백과 포크를 한다면 내용 추가나 업데이트되지 않은 내용을 최신화하는 등의 편집을 더하는 게 좋다고 생각합니다. 위키백과 포크 문서의 좋은 사례라고 생각하는 문서를 꼽자면 대한민국의 애니메이션 의무 편성 제도 문서가 있습니다. 문단 구성을 다르게 하고 기존 내용의 최신화, 법 조항을 인용하는 부분을 각주에서 인용문 틀로 바꿔서 가독성 개선 등을 해서 분량을 위키백과 원본보다 많이 늘렸습니다.--Ho95kr (토론) 2021년 7월 9일 (금) 19:32 (KST)
위키백과를 보면 정보 갱신이 안된채로 1년이 지난 문서도 많던데요. 그런걸 갱신하거나 리브레 위키만의 내용을 더 추가하거나 하면 되겠네요. 감사합니다.Caeruleum (토론) 2021년 7월 9일 (금) 21:19 (KST)
그런데 엔간하면 처음부터 직접 작성하는 것이 더 좋긴 합니다. 그리고 출처가 같다고 저작권 위반은 되지 않을 거니까, 출처 같은 건 이용해먹어도 좋죠. --Pika (토론) 2021년 7월 15일 (목) 22:50 (KST)
감사합니다 :) 사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:06 (KST)

위키방:170565도 한번 읽어보세요. --118.235.13.48 2021년 7월 9일 (금) 23:12 (KST)

좋은 방법인지 모르겠습니다.

제 토론에 한자를 찾기 힘들어서 넘겨주기를 만들어야 된다는 말을 남기신 유저분이 있어서 한번 검색하기 쉽게에 있는 '가' 문서에 링크를 만들어봤습니다.

시리즈:리브레 한자사전 '가' 검색 결과 >

이런 식으로 링크를 만들어 보았는데 이걸 동음이의어 문서가 따로있는 '간' 같은 문서에도 한자사전 링크를 추가하는 것도 괜찮은지를 모르겠습니다. 간 (동음이의)에 한자사전 링크를 만드는 것은 접근성 차원에서 좋은 선택이 아닌 것 같아서 차라리 간 문서에다가 링크를 만들려고 합니다. 사용자:Cerulean/서명하기/ 2021년 7월 11일 (일) 14:49 (KST)

추가하면 배치가 이렇게 됩니다.

다른 뜻에 대해서는 간 (동음이의) 문서를 참조하세요.

'간' 음을 가진 한자

혹은

'간' 음을 가진 한자

다른 뜻에 대해서는 간 (동음이의) 문서를 참조하세요.

원래 이것부터 적을려 했는데 순서가 뒤집혔네요. 시리즈:리브레 한자사전 '가' 검색 결과 > 이렇게 만들면 좀 이질감이 듭니다. 사용자:Cerulean/서명하기/ 2021년 7월 11일 (일) 14:55 (KST)

글쎄요. 해당 기능은 포털 사이트의 한자사전을 이용하는 것이 더 좋아 보입니다. --Pika (토론) 2021년 7월 15일 (목) 22:07 (KST)
이 기능의 검색 범위는 리브레위키 내부입니다.사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 22:43 (KST)
리브레 위키가 담당할 역할이 아닌 것 같다는 의미입니다. --Pika (토론) 2021년 7월 15일 (목) 22:46 (KST)
사용자가 더 편리할 수 있기 때문에 리브레 위키가 담당해야하는 것이라고 생각합니다.사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 22:56 (KST)
신뢰성이나 접근성으로 봤을 때 포털 사이트 사전을 이용하는 것이 더 정확하고 빠릅니다. 그리고 PC에서는 한자 키를 이용할 수도 있고요. --Pika (토론) 2021년 7월 15일 (목) 23:05 (KST)
그리고 서명을 사용자 문서를 이용하실 때에는 subst 구문을 이용하셔야 합니다. templatestyles(CSS)를 이용하지 않는 것도 추천드립니다. --Pika (토론) 2021년 7월 15일 (목) 23:06 (KST)
그럼 시리즈:한자사전을 이용하는 것이 아닐텐데요. 사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:09 (KST)
제가 말씀드린 건 한글 검색만 해당합니다. --Pika (토론) 2021년 7월 15일 (목) 23:13 (KST)
아니면 시리즈:한자사전에 하위 문서로 만드는 것도 나쁘진 않은 것 같습니다. --Pika (토론) 2021년 7월 15일 (목) 23:13 (KST)
'한'으로 검색하고 시리즈 문서로 들어가는게 아니라 처음부터 시리즈:리브레 한자사전/한으로 검색하는 걸 말씀하시는 거죠?--사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:17 (KST)
네, 맞습니다. --Pika (토론) 2021년 7월 15일 (목) 23:18 (KST)
음 다행히 그것도 같이 만드는 중이네요.

'가' 음을 가진 한자 이런 식의 링크도 괜찮다고 보는데..--사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:20 (KST)

위처럼 해도 상관없기는 하죠?--사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:23 (KST)
위처럼이 어떤 거죠? --Pika (토론) 2021년 7월 15일 (목) 23:35 (KST)

가에다가

'가' 음을 가진 한자 이걸 추가하는 걸 말하는 겁니다.

기존에 있는 문서면 괜찮은데, 이걸 위해 문서를 별도로 만드는 것은 좀 그렇습니다. --Pika (토론) 2021년 7월 15일 (목) 23:42 (KST)
기존 문서 없으면 한자 링크 말고도 여러가지 내용 보충해서 만들려고 합니다. 역시 링크만 달랑 걸어놓으면 문제가 되겠죠? --사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:44 (KST)
아무래도 그렇죠. 그리고 최상단 보다는 별도 문단이나 아래처럼 목록에 넣는 게 일관성 있고 좀 더 좋은 것 같습니다. --Pika (토론) 2021년 7월 15일 (목) 23:49 (KST)
어 그렇게요? 작업량이 방대할거 같은데 한자도 없는데 링크부터 만드는건 순서가 틀리니까 우선 한자문서부터 늘려야겠군요. 일단 보류해야겠습니다.사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 23:53 (KST)
한자 링크가 튀어나온 못처럼 되는거네요. 일관성도 중요하죠

인물 사진 관련

  1. 유튜버나 아이돌 사진같은 건 저작권에 걸리지는 않죠?
  2. 선만 지키면 허용이 될거 같은데 그 선을 모르겠습니다.

사용자:Cerulean/서명하기/ 2021년 7월 14일 (수) 00:01 (KST)

검색해보니까 저작권이 아니라 초상권의 문제라네요.

저작권은 기본적으로 촬영자에 귀속됩니다. 유튜브 영상 캡쳐는 유튜버의 소관일 것이고, 신문에 나온 아이돌 사진은 사진 기자의 소유입니다. --Centrair(센트레아) APP·DEP 2021년 7월 15일 (목) 22:23 (KST)

허락받고 써야되는거군요. 사용자:Cerulean/서명하기/ 2021년 7월 15일 (목) 22:38 (KST)

분리주의? 병합주의?

'분리주의'가 각각의 주제들이 개별 문서로 분리되어야 하는 것을 말한다면, '병합주의'는 그 반대로 사소한 주제들이 관련 메인 문서로 병합되어야 한다는 걸 말한다고 합니다. --175.223.31.240 2021년 7월 16일 (금) 15:38 (KST)
딱히 정해진거 없습니다. 그냥 개별 문서나 주제별로 다를 수 있겠네요. 일단 지나치게 길어지면 분리하는걸 권장하고 너무 적으면 합쳐두는게 아무래도 낫겠죠 --Chirho Chirho.png 토론 2021년 7월 16일 (금) 16:16 (KST)

특수:올리기 안내 변경 제안

제가 예전에 위키방에서 같은 주제를 올린 적이 있는데 흐지부지되어 다시 제안합니다.

현재 안내문에는 파일 올리는 것에 대한 안내보다 문서에 어떻게 삽입하는지가 더 많은 것 같습니다. 간단한 업로드 안내와 저작권 관련 내용이 보충되어야 한다고 생각합니다.

따라서 적어도 아래 두 내용이 포함되어야 할 것 같습니다. --Pika (토론) 2021년 7월 15일 (목) 22:06 (KST)