위키백과:사랑방 (기술)/2025년 1월
Tech News: 2025-03
편집Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
- The Single User Login system is being updated over the next few months. This is the system which allows users to fill out the login form on one Wikimedia site and get logged in on all others at the same time. It needs to be updated because of the ways that browsers are increasingly restricting cross-domain cookies. To accommodate these restrictions, login and account creation pages will move to a central domain, but it will still appear to the user as if they are on the originating wiki. The updated code will be enabled this week for users on test wikis. This change is planned to roll out to all users during February and March. See the SUL3 project page for more details and a timeline.
Updates for editors
- On wikis with PageAssessments installed, you can now filter search results to pages in a given WikiProject by using the
inproject:
keyword. (These wikis: Arabic Wikipedia, English Wikipedia, English Wikivoyage, French Wikipedia, Hungarian Wikipedia, Nepali Wikipedia, Turkish Wikipedia, Chinese Wikipedia) [1] - One new wiki has been created: a Wikipedia in Tigre (
w:tig:
) [2] - View all 35 community-submitted tasks that were resolved last week. For example, there was a bug with updating a user's edit-count after making a rollback edit, which is now fixed. [3]
Updates for technical contributors
- Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. Starting the week of January 13, we will begin rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints for all wiki projects. This change was previously available on testwiki and should not affect existing functionality, but active users of the impacted endpoints may raise issues directly to the MediaWiki Interfaces Team in Phabricator if they arise.
- Toolforge tool maintainers can now share their feedback on Toolforge UI, an initiative to provide a web platform that allows creating and managing Toolforge tools through a graphic interface, in addition to existing command-line workflows. This project aims to streamline active maintainers’ tasks, as well as make registration and deployment processes more accessible for new tool creators. The initiative is still at a very early stage, and the Cloud Services team is in the process of collecting feedback from the Toolforge community to help shape the solution to their needs. Read more and share your thoughts about Toolforge UI.
- For tool and library developers who use the OAuth system: The identity endpoint used for OAuth 1 and OAuth 2 returned a JSON object with an integer in its
sub
field, which was incorrect (the field must always be a string). This has been fixed; the fix will be deployed to Wikimedia wikis on the week of January 13. [4] - Many wikis currently use Cite CSS to render custom footnote markers in Parsoid output. Starting January 20 these rules will be disabled, but the developers ask you to not clean up your MediaWiki:Common.css until February 20 to avoid issues during the migration. Your wikis might experience some small changes to footnote markers in Visual Editor and when using experimental Parsoid read mode, but if there are changes these are expected to bring the rendering in line with the legacy parser output. [5]
Meetings and events
- The next meeting in the series of Wikimedia Foundation Community Conversations with the Wikimedia Commons community will take place on January 15 at 8:00 UTC and at 16:00 UTC. The topic of this call is defining the priorities in tool investment for Commons. Contributors from all wikis, especially users who are maintaining tools for Commons, are welcome to attend.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
생성 보호된 문서
편집생성이 보호된 문서는 일본어 위키백과처럼 오른쪽 위에 아이콘이 뜨게 할 수 없을까요?
- 참고: ja:青葉真司
--RhapsoDJ (토론) 2025년 1월 15일 (수) 22:05 (KST)
- 특수:내사용자문서/common.js에 일본어 위키백과의 아래 소도구를 호출하는 스크립트를 넣어주시면 됩니다.
mw.loader.load( '//ja.wikipedia.org/w/index.php?title=MediaWiki:Gadget-protectionLog.js&action=raw&ctype=text/javascript');
- 한국어 위키백과에는 현재 해당 소도구가 없습니다. --ted (토론) 2025년 1월 16일 (목) 22:20 (KST)
- 아... 그렇군요. --RhapsoDJ (토론) 2025년 1월 22일 (수) 15:21 (KST)
기술 소식: 2025년 04주
편집위키미디어 기술 커뮤니티의 최신 기술 소식. 이러한 변경 사항에 대해 다른 사용자에게 알려주십시오. 모든 변경 사항이 여러분에게 영향을 미치는 것은 아닙니다. 번역이 가능합니다.
편집자를 위한 업데이트
- 관리자는 확장:Nuke를 사용하여 사용자 또는 IP 주소가 만든 여러 페이지를 대량 삭제할 수 있습니다. 이전에는 지난 30일 동안 만든 페이지만 삭제할 수 있었습니다. 이제 특정 사용자 또는 IP 주소를 대상으로 하는 경우 지난 90일 동안의 페이지를 삭제할 수 있습니다. [6]
- 점검 편집 기능을 사용하는 위키에서 되돌리기 기능을 사용하여 점검되지 않은 페이지 개정판을 되돌릴 때 해당 개정판은 이제 "자동 점검" 대신 "수동 점검"으로 표시되며, 이는 더 정확합니다. 최근 변경 사항에 필터를 사용하는 일부 편집자는 필터 설정을 업데이트해야 할 수 있습니다. [7]
- 지난주에 해결된 31 커뮤니티 제출 작업을 모두 확인하세요. 예를 들어, 시각편집기의 "링크 삽입" 기능은 편집자가 입력을 시작할 때 기존 페이지를 제대로 제안하지 않는 경우가 있었는데, 현재는 수정되었습니다.
기술 기여자를 위한 업데이트
- 구조화된 토론 확장(플로라고도 함)이 위키에서 점진적으로 제거되고 있습니다. 이 확장은 유지 관리되지 않고 문제를 일으킵니다. 이 확장은 모든 일반 토론 페이지에서 사용되는 토론도구로 대체됩니다. 마지막 위키 그룹(카탈루냐어 위키인용집, 위키미디어 핀란드, 고아 콘칸어 위키백과, 카빌리어 위키백과, 포르투갈어 위키책, 위키미디어 스웨덴)에 곧 연락할 예정입니다. 이 프로세스에 대해 질문이 있으면 위키에서 Trizek (WMF)에게 핑을 보내주세요. [8]
- 최신 분기별 기술 커뮤니티 뉴스레터가 출시되었습니다. 이 에디션에는 다음이 포함됩니다. 데이터 플랫폼 엔지니어링 팀의 서비스에 대한 업데이트, 디자인 시스템 팀의 코덱스에 대한 정보 등.
기술 소식은 기술 소식 작성자가 준비하고 봇이 게시합니다. 기여하기 • 번역하기 • 도움 요청 • 피드백 • 구독 및 구독 취소
MediaWiki message delivery 봇의 오동작
편집일단 해당 봇의 작동에 관한 논의는 기술 사랑방에서 진행해야 하는 것으로 나와 있어서 이 곳에 오동작 보고를 올립니다.
사랑방은 분류:메시지 전달을 받지 않는 사용자 분류가 되어 있는 것으로 알고 있고, 낱말사전 자유게시판의 경우에도 같은 방법으로 대량 메시지 전달을 막아 놨는데 4주차 사랑방에 대량 발신 메시지가 게재된 것을 확인했습니다. --Jeebeen (토론) 2025년 1월 24일 (금) 11:54 (KST)
- 해당 분류를 통한 메세지 거부는 위키백과:사랑방에만 적용되며, 각 주 (위키백과:사랑방/202n년 제n주)에는 적용되지 않습니다. 사랑방 메인 페이지가 아닌 각 주 문서로 배달하라고 설정해 둔 것이므로 문제 없습니다.--*Youngjin (토론) 2025년 1월 24일 (금) 11:58 (KST)
- 일단 다른 자매 프로젝트에서도 일괄 발송된 것을 확인하고 롤백했습니다. 낱말사전이나 문헌같이 비교적 규모가 작은 자매 프로젝트에서는 이런 메시지 발송이 마음에 들지는 않아서 위키백과 사랑방에 보고 되돌린 것 같네요. 아예 관련 안내 자체를 막아 버리면 사용자들이 알 길이 없기 때문에 살리는 게 맞다고 보아 복구합니다. --Jeebeen (토론) 2025년 1월 24일 (금) 12:30 (KST)
- 그러던 중 사용자 토론에 Ted님의 의견이 올라 왔는데, 애초에 대량 메시지 전달을 받지 않는 사용자 분류는 최상단에 넣는 것 아닌가요? --Jeebeen (토론) 2025년 1월 24일 (금) 11:59 (KST)
최근 기술 문제 대응 이력
편집(누락된 토론이 있을 수 있음) 최근 이력만 남깁니다. --ted (토론) 2025년 1월 26일 (일) 09:58 (KST)
다크 모드 관련 작업
편집인터페이스 관리자분들 및 개발자 참고사항입니다.
다크 모드의 경우 총 2가지 기능을 통해 활성화할 수 있습니다.
- 벡터-2022 기본 제공 다크 모드: 자동, 켬/끔
- 다크 모드 소도구: 켬/끔
- 틀스타일(CSS) 작업 가이드 (예시 → 틀:공지/styles.css)
- 벡터-2022 기본 제공 다크 모드의 경우:
- html.skin-theme-clientpref-night 엘리먼트 추가 (다크 모드 켬)
- prefers-color-scheme: dark 및 html.skin-theme-clientpref-os 엘리먼트 추가 (자동)
- 다크 모드 소도구의 경우:
- html.client-dark-mode 엘리먼트 추가 (다크 모드 켬)
- 미디어위키 등 특수 이름공간에서 틀스타일 적용 안 되는 문제 해결 방법
- 틀스타일이 적용되지 않는 경우 mw-parser-output 클래스를 추가합니다. (예시 → 특수:차이/38585548)
고칠 게 너무 많네요. 최대한 다크 모드에 적용하도록 수정은 하겠지만, 도와주실 분은 도움을 주시면 감사하겠습니다. 기록을 위해 남깁니다. --ted (토론) 2025년 1월 26일 (일) 18:48 (KST)
- (추가) 벡터-2022 다크 모드와 비호환되는 Page tabs 항목 제거. 위키백과:사랑방/안내문/헤더 생성. --ted (토론) 2025년 1월 27일 (월) 09:31 (KST)
사랑방 답변 기능 작동 문제
편집- 레거시 스킨
- 다크 모드는 사용자 제작 CSS 문서 이용 중
5시에는 답변 기능이 작동했는데, 22시 이후 답변 기능이 전혀 작동하지 않아 원본 편집으로 입력하고 있습니다. 다크 모드의 경우에도 {{삭토보존}}과 사랑방 인터페이스에서 기존에는 흑백 반전으로 정상적으로 표시되던 것에서 문제가 발생하는 것이 확인되는데, 조언 부탁 드립니다. --Jeebeen (토론) 2025년 1월 27일 (월) 23:11 (KST)
- 불편을 드려 죄송합니다. 문제라고 생각했던 사항들은 모두 고쳤습니다. 아직 고쳐지지 않은 부분이 있거나 제가 잘못 이해하는 부분이 있다면 알려주세요. --ted (토론) 2025년 1월 28일 (화) 01:27 (KST)
- 현재는 지금 올린 답변처럼 기능이 정상적으로 작동합니다. 염려해 주셔서 감사합니다. 혹시 답변 기능이 안 되는 것이 어떤 문제 때문인지 아시나요? 일단 제 의견이 올라 간 이후 Ted님 기여 목록만 보고 확인했을 때는 답변 기능 관련해서 참고할 만한 정비 내용인지는 잘 모르겠습니다. 다크 모드의 경우에는 기존에 입력되어 있던 미디어위키 스킨에 색상값 때문인 것 같기도 하나, 저는 다크 모드의 경우 사용에만 관심이 있고 구현하는 어디서 그 방법을 참고하면 되는지만 알고 있고 구현하는 데에는 크게 관심 갖지 않아 알고 있는 내용이 없어서 달리 알고 있는 게 없습니다. 다크 모드의 경우에도 정상적으로 작동합니다. --Jeebeen (토론) 2025년 1월 28일 (화) 06:28 (KST)
- flow 기능을 구현하는 div 태그에 기존에 존재했던 린트 오류 때문인가 싶기도 하네요. --Jeebeen (토론) 2025년 1월 28일 (화) 06:31 (KST)
- 적층된 기술 문제를 명절에 몰아서 처리하다 보니(그래도 다 처리 못함) 실수가 있네요. 답변 기능과 관련하여서는 말씀하신 사항(div 짝 문제)이 맞습니다. 동일 CSS가 레거시 스킨의 다크 모드에서도 다르게 동작할 수 있음을 인지하지 못했습니다. (문자가 다크 모드에서도 검은색으로 나오는 경우 별도의 틀스타일을 사용하지 않고 'color: var(--color-base)'를 사용하면 해결됩니다. 관련 링크) --ted (토론) 2025년 1월 28일 (화) 09:13 (KST)
- 이후 제가 다크 모드 관련 정비에 의견을 제시하거나 직접 참여해야 할 계기가 생길 때 이 토론을 참고하겠습니다. 감사합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 02:21 (KST)
- 적층된 기술 문제를 명절에 몰아서 처리하다 보니(그래도 다 처리 못함) 실수가 있네요. 답변 기능과 관련하여서는 말씀하신 사항(div 짝 문제)이 맞습니다. 동일 CSS가 레거시 스킨의 다크 모드에서도 다르게 동작할 수 있음을 인지하지 못했습니다. (문자가 다크 모드에서도 검은색으로 나오는 경우 별도의 틀스타일을 사용하지 않고 'color: var(--color-base)'를 사용하면 해결됩니다. 관련 링크) --ted (토론) 2025년 1월 28일 (화) 09:13 (KST)
기술 소식: 2025년 05주
편집위키미디어 기술 커뮤니티의 최신 기술 소식. 이러한 변경 사항에 대해 다른 사용자에게 알려주십시오. 모든 변경 사항이 여러분에게 영향을 미치는 것은 아닙니다. 번역이 가능합니다.
주간 주요 내용
- 점검자 및 관리자 - 편집자 또는 사용자에 대한 어떤 정보나 컨텍스트가 점검자 또는 관리자 결정을 보다 빠르고 쉽게 내리는 데 도움이 될 수 있습니까? 위키미디어 재단은 다가오는 연간 계획을 안내하는 데 도움이 되는 여러분의 의견을 듣고 싶습니다. 내년의 기술 방향을 정하기 위해 이 질문과 기타 13가지 질문에 대한 귀하의 생각을 공유해 주시기 바랍니다.
편집자를 위한 업데이트
- 이제 전 세계 iOS 위키백과 앱 사용자는 위키백과에서 읽고 편집한 기록을 기반으로 통찰력을 제공하는 개인화된 올해 검토 기능에 액세스할 수 있습니다. 이 프로젝트는 새로운 독자가 백과사전적 콘텐츠를 발견하고 상호 작용할 때 이를 환영하도록 돕기 위한 광범위한 노력의 일환입니다.
- 이제 편집 점검자는 잠재적으로 문제가 있는 새 페이지를 강조 표시할 수 있는 새로운 기능을 사용할 수 있습니다. 이전에 삭제된 페이지와 동일한 제목으로 페이지가 생성되면 이제 태그('Recreated')가 추가되며, 사용자는 이를 특수:최근바뀜 및 특수:새문서으로 필터링할 수 있습니다. [9]
- 이번 주 후반에는 편집자가 다른 넘겨주기(이중 넘겨주기)으로 연결되는 넘겨주기를 생성하려고 시도할 경우 새로운 경고가 표시됩니다. 이 기능은 두 번째 남겨주기의 대상 페이지로 직접 링크하도록 권장합니다. 이 개선을 위해 SomeRandomDeveloper 사용자에게 감사드립니다. [10]
- 위키미디어 위키는 로그인 중에 WebAuthn 기반 2차 요소 검사(하드웨어 토큰 등)를 허용하지만, 이 기능은 취약하고 사용자가 매우 적습니다. 미디어위키 플랫폼 팀은 SUL3(단일 사용자 로그인 버전 3)의 출시를 방해하지 않기 위해 새로운 WebAuthn 키 추가를 일시적으로 비활성화합니다. 기존 키는 영향을 받지 않습니다. [11]
- 지난주에 해결된 30 커뮤니티 제출 작업을 모두 확인하세요.
기술 기여자를 위한 업데이트
- 미디어위키 기록 덤프를 사용하는 개발자의 경우: 데이터 플랫폼 엔지니어링 팀은 임시 계정 이니셔티브를 지원하기 위해 이러한 덤프에 몇 가지 새로운 필드를 추가했습니다. 이러한 덤프를 읽는 소프트웨어를 유지 관리하는 경우 행의 필드 순서가 변경되므로 코드와 업데이트된 설명서를 검토하세요. 또한 필드 이름이 하나 변경됩니다.
mediawiki_user_history
덤프에서anonymous
필드는is_anonymous
로 이름이 변경됩니다. 이러한 변경 사항은 2월에 덤프가 다음 릴리스될 때 적용됩니다. [12]
기술 소식은 기술 소식 작성자가 준비하고 봇이 게시합니다. 기여하기 • 번역하기 • 도움 요청 • 피드백 • 구독 및 구독 취소
위키백과 머리글 틀에 자주 들어 가는 구문
편집아래와 같은 구문이 여러 문서에 굉장히 일관적으로 들어 가는데
<div style="margin-bottom: 1.2em; margin-top: 1.2em;"> ---- </div>
{{머리클 틀 스타일 분할선}} 같은 제목으로 틀로 만들어서 '모듈화'(루아 모듈이 아니라는 의미에서)하는 게 좋지 않나 싶네요. 그리고 TemplateStyles 기능은 위키백과에서 쓰이는 걸 잘 보지 못했는데 태그에 style값으로 주지 말고 이 기능 사용해서 분리하는 게 낫지 않나 싶습니다. --Jeebeen (토론) 2025년 1월 28일 (화) 09:07 (KST)
- {{hr}} 틀이 이미 있는데 이런 틀을 의미하시나요? --ted (토론) 2025년 1월 28일 (화) 09:19 (KST)
- 해당 예시를 통해 의도하시는 바를 제가 정확히 파악하지 못했습니다. 같은 CSS 속성 자체가 반복되어 이후에 변경을 한다고 하더라도 일일히 수정해야 하는 불편함이 있다 보니 한 페이지에 한 번만 작성하고 참조하는 방식에 대해 의견을 구하는 것이 제가 의도하려는 바였는데, 혹시 {{hr}}에서 그 방식을 사용하자는 의견이실까요? --Jeebeen (토론) 2025년 1월 29일 (수) 02:19 (KST)
- "----"라는 글자를 넣으면 hr 태그가 생성되며 {{hr}} 틀이 해당 동작을 따르기에 이런 방식의 틀을 의미하시는 것인지를 여쭤봤습니다. 유지관리상 이 틀을 수정하거나 활용하기에는 적절치 않아 보이며, 말씀하신 제안사항(틀 생성)이 맞아 보입니다. (이 논의와는 별개로, 위키백과:사랑방/안내문처럼 줄이 과다 사용되고 있을뿐 아니라 반복되는 내용이 있는 경우도 있어서 전반적으로 정리를 고민해야 합니다.) --ted (토론) 2025년 1월 29일 (수) 09:08 (KST)
저 제목으로 연결이 되어야 하는 부분으로,실제로 사용할 때는 {{info-hr}} 같은 넘겨주기를 사용하긴 해야겠죠. --Jeebeen (토론) 2025년 1월 29일 (수) 20:04 (KST) 내용 개변이 커서 원본 편집을 통해 표현을 수정하지 않고 취소선 처리한 다음 부연 설명합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 20:27 (KST)- 위 표현에 취소선 친 다음에 대상을 명확히 하자면, {{info-hr}}을 {{머리글 틀 스타일 분할선}}로 넘겨주기 하자는 의견이었습니다. 다른 편집 방안으로 오해될 수 있어서 부연 설명합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 20:30 (KST)
- 해당 코드를 템플릿화해서 사용하면 코드 가독성을 개선할 수 있다고 생각됩니다. 또한 말씀하신 대로 한꺼번에 효과를 적용할 수 있는 장점에도 동의합니다. 그리고 hr 태그는 브라우저마다 다르게 렌더링될 수 있기 때문에, 직접 효과를 명시하거나 아니면 border로 효과를 조정하는 방법을 고려할 수 있을 듯 합니다. --ted (토론) 2025년 1월 29일 (수) 20:51 (KST)
- "----"라는 글자를 넣으면 hr 태그가 생성되며 {{hr}} 틀이 해당 동작을 따르기에 이런 방식의 틀을 의미하시는 것인지를 여쭤봤습니다. 유지관리상 이 틀을 수정하거나 활용하기에는 적절치 않아 보이며, 말씀하신 제안사항(틀 생성)이 맞아 보입니다. (이 논의와는 별개로, 위키백과:사랑방/안내문처럼 줄이 과다 사용되고 있을뿐 아니라 반복되는 내용이 있는 경우도 있어서 전반적으로 정리를 고민해야 합니다.) --ted (토론) 2025년 1월 29일 (수) 09:08 (KST)
- 해당 예시를 통해 의도하시는 바를 제가 정확히 파악하지 못했습니다. 같은 CSS 속성 자체가 반복되어 이후에 변경을 한다고 하더라도 일일히 수정해야 하는 불편함이 있다 보니 한 페이지에 한 번만 작성하고 참조하는 방식에 대해 의견을 구하는 것이 제가 의도하려는 바였는데, 혹시 {{hr}}에서 그 방식을 사용하자는 의견이실까요? --Jeebeen (토론) 2025년 1월 29일 (수) 02:19 (KST)
- 삭토나 현재 공간, 즉 기술 사랑방에서는 모아 보기를 위해 끼워넣기(Transclusion)된 문서에서도 답변 기능이 잘 작동하지만 다른 공간에서는 그렇지 않습니다. 그런 환경에서는 아무래도 답변을 통해 의견을 내기가 어렵다 보니 논의를 촉진하려는 목적이 달성되기 어렵습니다. 사실 답변 기능은 논의와 의사소통 촉진을 위한 목적입니다. 사용자 접근성 이론에서 언급되는 것처럼 기능을 쓰다가 갑자기 그 기능이 작동하지 않으면 그냥 그 행동을 포기하는 유형의 사용자들이 오히려 더 많고 보고되는 경우가 더 드뭅니다. 답변 기능 문제는 위의 주제에서도 알 수 있듯 린트 오류 때문에 그런 것으로 보입니다.
- 중요한 것은 같은 구문이 반복되어 사용되고 있음에도 한 곳에서 참조하는 것이 아닌 각각의 문서(Page의 개념)에 기술되어 있으면 한 곳에서 해결되도 다른 곳에서는 여전히 문제가 해결되지 않고 남겨질 가능성이 있다고 생각합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 20:23 (KST)
- 린트 오류 건은 이미 잘 이해하고 있으며 위 문단에서 해결되었기 때문에 더 답변드리지는 않겠습니다. 제가 언급드린 '반복되는 내용'은 기술적인 내용이 아닌데 명확히 말씀드리겠습니다. 제가 위키백과:사랑방/안내문을 예시로 든 이유가 있습니다. '사랑방'이라는 글자가 좌측(큰 글씨)과 오른쪽(커피 모양 아래)에 중복 나열, 과거 토론 목록 링크(본문 내용 및 보존 문서 링크)가 중복, "질문은 질문방에 남겨라, 사랑방 이용 전에 도움말을 읽어달라"라는 내용의 반복 등을 의미한 것이지, 기술적인 부분에서의 언급이 아니었습니다. 저는 말씀하신 hr에 대한 부분도 물론 중요하게 보지만 그보다 전반적으로 큰 틀에서 사랑방의 안내문 콘텐츠를 수정하는 것을 더 우선순위에 둬야 하지 않는가가 제 말의 핵심이었습니다. --ted (토론) 2025년 1월 29일 (수) 20:30 (KST)
- 내용에 더하여 지금처럼 hr의 목적에 맞지 않은 너무 많은 사용도 지양해야 할 것입니다. hr의 사용 목적이 "thematic break"인데 해당 안내문에 이것 또한 너무 많이 과도하게 사용되고 있고 본 목적을 따르고 있지 않기도 하고요. --ted (토론) 2025년 1월 29일 (수) 20:32 (KST)
- 사실 hr 태그가 너무 많이 사용되는 것 같습니다. 저는 해당 태그가 사용자 입장에서 텍스트상 의미를 시각적으로 분할하여 전달하고자 할 때 쉽게 사용하라고 만들었다고 생각하고, 개발자 측면에서 안내문을 디자인할 때 해당 태그를 사용하는 게 적절하지 못한 '신호'(개발 분야에서 사용되는 용어는 아니라 따옴표 처리)를 줄 수 있는 부분이라고 생각합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 20:48 (KST)
- 의견 감사합니다. 꼭 필요한 부분에 수직선을 사용하는 방법이 있을 것이고, 약간의 음영 처리가 있는 커스터마이즈된 새로운 수직선을 틀(틀:머리글 틀 스타일 분할선)로 만들어서 구분하는 방향으로 진행하면 좋겠습니다. (사랑방의 '중복' 관련 내용 부분은 이곳 문단과 직접 관련된 사항은 아니니 따로 고민하겠습니다) --ted (토론) 2025년 1월 29일 (수) 21:13 (KST)
- 나중에 hr 태그를 배제할 목적이거나 아예 hr 태그를 사용하지 않는다면 {{info-line}}이라고 이름 짓는 게 나을 듯 합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 21:18 (KST)
- 네, 제안해주신 이름(info-line)도 고려할 수 있습니다. 틀을 직접 만들어주셔도 좋으며, 이 경우 추가 작업을 도와드리겠습니다. 아니면 구체적으로 함께 논의, 검토하여 생성을 도와드릴 수 있습니다. --ted (토론) 2025년 1월 29일 (수) 21:33 (KST)
- 나중에 hr 태그를 배제할 목적이거나 아예 hr 태그를 사용하지 않는다면 {{info-line}}이라고 이름 짓는 게 나을 듯 합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 21:18 (KST)
- 의견 감사합니다. 꼭 필요한 부분에 수직선을 사용하는 방법이 있을 것이고, 약간의 음영 처리가 있는 커스터마이즈된 새로운 수직선을 틀(틀:머리글 틀 스타일 분할선)로 만들어서 구분하는 방향으로 진행하면 좋겠습니다. (사랑방의 '중복' 관련 내용 부분은 이곳 문단과 직접 관련된 사항은 아니니 따로 고민하겠습니다) --ted (토론) 2025년 1월 29일 (수) 21:13 (KST)
- 사실 hr 태그가 너무 많이 사용되는 것 같습니다. 저는 해당 태그가 사용자 입장에서 텍스트상 의미를 시각적으로 분할하여 전달하고자 할 때 쉽게 사용하라고 만들었다고 생각하고, 개발자 측면에서 안내문을 디자인할 때 해당 태그를 사용하는 게 적절하지 못한 '신호'(개발 분야에서 사용되는 용어는 아니라 따옴표 처리)를 줄 수 있는 부분이라고 생각합니다. --Jeebeen (토론) 2025년 1월 29일 (수) 20:48 (KST)
- 정보 언급한 틀은 생성했습니다. 물론 복잡한 기술이 들어 간 틀이 아니긴 하나, 정상적으로 작동하는 것 같습니다. 틀 자체의 내용은 틀 토론에서 의논해도 될 듯합니다. 생각해 볼 만한 사항들에 대해서도 언급합니다:
- 관리 측면에서 구체적으로 분류를 정해야 합니다.
- 머리글 틀 스타일 분할선/설명문서 관련 내용에 대해 좀 더 논의해 봐야 할 듯 합니다.
- 임시적 성격에서 만드는 틀인가.
- 한국어판에서 필요에 의해 생성된 틀이고 이전에 생성되었던 틀과는 목적이 조금 다르기 때문에 생각해 볼 필요는 있다고 봅니다. --Jeebeen (토론) 2025년 1월 30일 (목) 01:55 (KST)
- 틀:머리글 틀 스타일 분할선: 고민 중이신 분류의 경우 분류:위키백과 서식 틀이 적절해 보여 추가했습니다. 위에서 논의된 대로 브라우저마다 다르게 표시될 수 있는
hr
태그가 아닌 CSS 효과로 대체해 보았습니다. 설명문서의 경우 '코드 가독성을 높이는 틀'이라는 개발자 관점의 서술보다는 틀의 실제 목적을 기술하는 편이 나아 보여 내용을 보완해봤는데 다른 의견 있으시면 알려주세요. 한국어 위키백과의 쓰임에 맞는 틀이기에 계속 안내문 내에서 사용된다면 임시적인 틀이라고는 생각되지 않습니다. --ted (토론) 2025년 1월 30일 (목) 09:11 (KST)- 오늘 사랑방에 다른 새로운 주제를 작성을 끝마친 뒤에 이에 대해 답변드리려 했으나, 그 내용을 다 정리하지 못해서 내일 답변을 드리는 점 양해 바랍니다. --Jeebeen (토론) 2025년 1월 30일 (목) 22:12 (KST)
- 틀:머리글 틀 스타일 분할선: 고민 중이신 분류의 경우 분류:위키백과 서식 틀이 적절해 보여 추가했습니다. 위에서 논의된 대로 브라우저마다 다르게 표시될 수 있는