모듈 토크:해트노트

이 모듈은 2018년 7월 4일에 병합될 것으로 검토되었습니다.그 논의의 결과는 "합의 없음"이었다.

이 버전의 모듈에서 제공되는 텍스트 및/또는 기타 크리에이티브 콘텐츠:Hatnote가 복사되거나 인큐베이터로 이동되었습니다.모듈: 이 편집이 포함된 Wp/nod/Hatnote.이제 이전 페이지의 이력은 후자 페이지의 해당 내용에 대한 속성을 제공하는 역할을 하며, 후자 페이지가 존재하는 한 삭제해서는 안 됩니다.

테스트를 추가했습니다.inline" 매개 변수: div 대신 스팬으로 해트노트를 출력합니다.이것은 다양한 용도를 가지고 있을 것이다.이미 도입되어 있는 것은{{Ghat}}용어 정의 위에 의도되지 않은 해트노트의 경우(인라인 해트노트의 스팬을 내부로 감싼다).<p>...</p>; 다른 사용 사례에서는 인라인 해트노트를 테이블 셀 안에 랩하거나 필요에 따라 항목을 나열하거나 할 수 있습니다.)또 하나는{{Hatnote-inline}}inline "의 메타데이터도 참조해 주세요.「」, 「자세한 것은…」등입니다.

위의 콘텐츠에 대한 해트노트의 템플릿화된 일관성을 제공하기 위해 많은 노력을 기울였지만 콘텐츠에 포함된 해트노트의 사용은 완전히 "규제되지 않은" 혼란입니다.이번 주말에 다른 일을 하고 돌아왔을 때, 그것을 바탕으로 한 템플릿의 첫 번째 사용은 WP:Manual of Style과 그 서브 가이드라인 자체입니다.이러한 상호 참조를 자주 사용하고 있기 때문입니다만, 무작정 사용하고 있습니다.스타일 가이드를 정리하는 것은 자동으로 모범이 되기 때문에 시작하기에 가장 좋은 장소인 것 같습니다. - SMC Candelish ☺☏ ^ʌ_ᴥ2014년^ʌ 5월 23일 21:27 (UTC)응답[응답]

저는 이것이 광범위한 결과를 가져올 수 있기 때문에 되돌렸습니다.그리고 저는 우선 합의를 찾기 위한 논의가 필요하다고 생각합니다.제가 제대로 이해한 경우 정의 목록과 본문 텍스트 안에 해트노트를 넣어야 합니다.첫째, 이러한 인라인 사용을 "해트노트"라고 부르는 것이 말이 되는지 잘 모르겠습니다.둘째, 인라인 케이스에서는 아마도 "blah blah"(자세한 내용은 foo 참조)와 같은 텍스트를 "blah blah"(blah blah)로 변경하는 것을 의미합니다.{{see also inline Foo}} )." 인라인 Wikitext로도 충분할 때 템플릿을 추가하는 것은 피해야 한다고 생각합니다.- Stradivarius님^{♪ talk ♪} 2014년 5월 23일 (UTC)응답[응답]

세 가지 다른 문제:

1. dl목록의 정의(또는 정의 세트) 위에 있는 해트노트는 기사 등의 맨 위에 있는 섹션과 정확히 동일한 기능을 수행하지만, 이러한 상황에서는 제대로 작동하지 않는 div 안에 들어가지 않음으로써 환경에 더 잘 맞게 포맷할 수 있습니다.
2. 실제로 인라인 인바디 텍스트 노트에 대해서는 실제로는 해트노트는 아니지만, 해트노트로 불리는 것을 피하기 위해 이 코드를 모두 복제하는 것은 의미가 없어 보입니다.해트노트가 아닌 경우, 같은 메타템플레이트와 모듈을 해트노트로 부르지 않는 리다이렉트(redirect)를 통해 호출할 수 있으며, 더 이상의 문제는 없습니다.블록과 인라인의 유일한 차이점은 div vs. span(및 div에 적용되어 들여쓰기되는 위치)입니다.블록의 것을 표준화할 이유가 없고, 인라인으로 혼돈을 일으킬 수밖에 없다.후자의 경우 사용되는 스타일은 지도 전체에 퍼져 있으며, 종종 unencycclopic-tone의 aside와 direction의 형태를 취한다.이러한 종류의 랜덤 노이즈는 인라인 "unhat" 노트의 표준 세트가 있는 경우 최소화될 수 있습니다(티노트).아래 Wikicode를 사용할 수 있는 것처럼 커스텀인라인 작성은 금지되지 않습니다.{{Hatnote}}, 커스텀 블록의 작성에 사용합니다.좋아, 좋아, 좋아.
3. 블록 해트노트(단순한) 패밀리를 포함한 대부분의 템플릿(완전 마침표)에 반대할 수 있기 때문에 "템플릿 회피" 이유를 잘 모르겠습니다.:''Insert your [[cross references here]]''자유 형식의 크로스소싱을 원할 경우 시스템 상의 거의 모든 노트를 대체할 수 있습니다.또한 거의 모든 인라인 분쟁/정리 템플릿과 다양한 인라인 타이핑 보조 템플릿은 "inline wikitext [that]로 대체될 수 있습니다"로 대체될 수 있기 때문에 그 근거는 거의 모든 인라인 분쟁/정리 템플릿과 다양한 인라인 타이핑 보조 템플릿을 제거할 수 있습니다.반복적으로 사용할 경우 템플릿에 넣기 때문에 손으로 계속 입력하는 것보다 템플릿을 사용하는 것이 빠르고 일관성이 있습니다.매우 빈번하게 추가되는 (기사명 참조) 및 (자세한 내용은 기사명 참조) 상위 가상이 항상 기사에 추가되어 블록 해트노트와 정확히 동일한 기능을 제공하므로 좀 더 현지화된 상황에서 템플릿 제작이 절실히 요구됩니다.방금 생각난 아이디어가 아니라 8년 정도 생각하고 있는 것입니다. :-) - SMcCandlish ☺☏^ʌ 2014년 5월 24일 (UTC^ʌ)_ᴥ응답 [응답]

SMc Candlish가 제공한 배경을 고려할 때, 저는 해트노트를 인라인으로 허용하는 것이 좋은 일이라고 생각하지 않습니다.이것은 포맷의 문제가 아니라 기본적인 해트노트 의미(시멘틱스입니까?)에 의한 것입니다.

해트노트에 대한 지침은 WP:해트노트"해트노트는 독자들이 찾고 있는 다른 기사를 찾는 데 도움이 된다"고 쓰여 있는데, 이것은 (적어도 나에게) 언제 지원해야 하는지에 대한 매우 실용적이고 유용한 규칙이다.독자용: "제가 올바른 페이지/장소에 있나요?"또한 이 규칙은 해트노트가 백과사전/본문/내용 텍스트의 일부가 아님을 나타냅니다.항상 항법 보조 장치입니다.그래서 인라인으로 사용할 때는 본문에 비콘텐츠를 삽입하는 것입니다.

이 배경으로부터, 해트 노트에는,<span>이 아니고, 외부<div>태그만 붙어 있습니다.이와 같이 일반적으로 html 처리 및 포맷에 의해 본문/콘텐츠에서 벗어나게 됩니다.또한 SMcCandlish가 인라인 및 테이블 사용으로 표시하는 "caos"에 대해서도 설명합니다.이것은, 어떠한 이유로 그 장소를 대상으로 하고 있지 않습니다.도트에 의한 또 다른 의도된 동작은 일종의 "노프린트" 효과입니다.해트노트는 콘텐츠가 아니기 때문에 콘텐츠 내보내기에서는 생략됩니다(BBC와 같이 인쇄, wikibook 만들기, pdf 만들기, 웹사이트에 다시 게시).이것은 일부에 의해 달성된다.class=기술.인라인으로 사용하면 문장의 일부가 잘려나갈 수 있습니다.그리고 문서에 경고를 적는 것은 헛된 희망입니다: 우리는 그러한 실수가 언제 일어날지 조언하거나 확인하기 위해 그곳에 있는 것이 아닙니다.

일반적으로 우리가 해트에 대해 생각하게 하는 모든 인라인 이슈는 콘텐츠로서 다르게 풀 수 있습니다.우선 Wikilink를 사용하는 것이 어떨까요?두 번째: 선두에 쓸 때와 같이 쓰면 어떨까요?

SMcCandlish에서 제공하는 예 {{Ghat}}에 이 일반적인 문장을 적용하겠습니다.표시된 것처럼 인라인 해트노트는 "Am I on the right page"라는 독자의 질문에 정확히 답하지 않습니다.그것은 납 부품에 가깝다. 바로 이 단어는 다양한 방법으로 철자를 쓴다.템플릿이 필요할 수도 있지만, 아직까지는 해트노트가 필요 없습니다.이것은 해결해야 할 용어집 내부 질문인 것 같습니다(용어가 불분명한 경우 어떻게 해야 합니까).

re 1 추가: 제 주요 포인트에서 설명한 바와 같이, 해트노트는 동일한 "기능"(시각 효과, 형식, 레이아웃, css 효과 짝수)을 가질 수 있지만, 동일한 의미론(WP:내용이 아닌 HAT 가이드라인, noprint 효과).re 2. SMc Candlish에서는 이름 때문에 해트노트가 꼭 맨 위에 있을 필요는 없다는 데 동의합니다.예를 들어 아래에도 {{further}}가 사용됩니다.OTOH, 테이블 셀에 단독으로 있는 {main}의 사용이 잘못되었습니다. 컨텐츠 전용에 빈 셀이 표시되므로 Wikilink여야 합니다.

-DePiep (대화) 2014년 5월 26일 (UTC)응답[응답]

DePiep가 여기서 말하는 해트노트에 대한 엄밀한 의미에서의 중요한 내용은 인라인 바리안트(다시 쓰는 대신 템플릿으로 만드는 것)에 정확하게 적용됩니다.

• 독자들이 정말로 찾고 있는 다른 기사를 찾을 수 있도록 도와주는 내비게이션 보조 도구
• 백과사전 내용 텍스트의 일부가 아닙니다.
• 기사에 대한 비콘텐츠 주입(즉, WP의 다른 부분에 대한 참조 형식의 WP 자기 참조)
• 인쇄할 수 없습니다.

게다가 DePiep은, 다음과 같은 서포트 불가의 전제 조건을 내걸고 있습니다.

연속해서 다루면, DePiep의 요점은 실제로 의도하지 않게 제가 여기서 제안하는 것을 뒷받침합니다.즉, 인라인 상호 참조(즉, 해트노트의 동등한 것)를 허용해야 하는가?가 아니라 "이미 보유하고 있는 수천 개의 인라인 상호 참조에 일관성을 제공하기 위해 이 코드를 다시 사용해야 하는가, 아니면 다른 방법으로 대처해야 하는가?어떻게 해서든 그것에 대해 언급할 것이다. - SMC Candelish ☺☏ ^ʌ_ᴥ2014년^ʌ 5월 30일 11:47 (UTC)응답[응답]

안녕하세요, SMC씨, 당신의 인라인 스타일 통일 계획이 매우 흥미롭고 저는 당신의 모자 달린 뉴스레터를 구독하고 싶습니다.봇에 의한 회피책이라기보다는 코드에 이러한 스타일의 포인트를 실장하는 것이 타당하다고 생각합니다.– SJ + 2014년 6월 14일 01:25 (UTC)응답[응답]

OP에 의한 진지한 코멘트 접기(답변 대신)쓸모 없는.난 이것에 대해 언급조차 하지 않을 거야.이는 또한 이 토크에서 변경이 있을 수 없음을 의미합니다. -DePiep (토크) 22:23, 2014년 8월 13일 (UTC)응답[응답]

• @Stradivarius, @Sj, @DePiep:: 인라인 "모자" 노트(즉, 정의 가능한 방법으로 표시된 인라인 상호 참조)는 사고나 이의 없이 약 2년간, 그리고 여러 가지 방법으로 사용되고 있습니다.{{Crossreference}}주로 페이지 사이에 사용되다{{See above}}특정 기사 내에서 사용되는{{Ghat}}용어집 엔트리의 해트노트로 사용됩니다.모듈을 다시 통합해야 할 수도 있습니다.모듈:상호 참조(또는 모듈:하이픈을 사용하는 경우는, 상호 참조해 주세요)."해트노트"는 WP 초기부터의 약간 이상한 이름이고, 그다지 큰 의미는 없다.2년은 개념 실증 및 문제 파악에 충분한 기간입니다. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 3월 28일 21:58 (UTC)응답하세요

아니요. WP를 읽어주세요.해트노트 먼저그리고 더 이상 나에게 핑계를 대지 마세요. -DePiep (대화) 22:03, 2016년 3월 28일 (UTC)응답[응답]

입력은 WP뿐이므로:IDONT LIKEIT 필리버스터링, 안 할 거야. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 3월 28일 23:13 (UTC)응답하세요

아니요. 제 의견은 "Hatnote"라는 개념은 인라인 사용에 적합하지 않다는 것입니다.다른 사람들도 여기에 기술한 것처럼. -DePiep (대화) 21:04, 2016년 3월 30일 (UTC)응답[응답]

IDONTLIKEIT의 전형적인 경우죠.결국, 사물을 이름으로 분류하는 당신의 개인적인 현실 터널이 다음과 같이 부화하는 진정한 현실에 만족하지 못하는지는 중요하지 않다.<div>...</div>구조가 제대로 작동하지 않거나 모든 시나리오에서 전혀 작동하지 않습니다.그 진정한 현실은 당신이 찡그린다고 해서 마법처럼 변하지 않을 것이다.인지 부조화가 너무 심하다면 이름에 "모자"가 들어가지 않도록 이름을 바꿀 수 있습니다.심지어<div>- 기반은 종종 물건의 맨 위가 아닌 끝에 사용됩니다(예:{{More}}): SMc Candlish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 21일 22:34 (UTC)응답해주세요

@Stradivarius 씨: 이 모듈이 이 목록을 비워두지 않는 이유를 알고 계십니까?Frietjes (토크) 2014년 8월 13일 22:12 (UTC)응답[응답]

@Frietjes:네, 모듈입니다.모듈을 통해 이 리다이렉트 내용을 캡처한 해트노트 리다이렉트:카테고리를 채울 수 있도록 리다이렉트 합니다.잘못된 방향 수정입니다.'모듈 토크' 참조:기능의 초기 요구에 대한 해트노트를 리다이렉트 합니다.VPT에서도 논의되고 있습니다.- Stradivarius님 2014년 8월 14일 (UTC)응답[응답]

그런 사건을 자동으로 해결할 수 있는 방법이 있지 않을까요?예를 들어 템플릿 {{Distinguish}}에 다음과 같은 코드를 포함하도록 새 모듈을 만들거나 현재 모듈을 확장하면 다음과 같은 코드를 가질 수 있습니다.{{#invoke:Hatnote hatnote pre=Not to be confused with sep=or}} 참고로 --Edgars2007(talk/contribs) 2015년 4월 7일(UTC)응답[응답]

안녕하세요, Edgars2007.설명해주신 것처럼 정교한 수정에 의지하지 않고 선행 및 후행 화이트스페이스를 잘라내는 기능을 확실히 구현할 수 있습니다.괜찮으시겠어요?

안부 전합니다,

코드네임 리사 (토크) 2015년 4월 7일 (UTC)응답[응답]

물론이죠. --Edgars2007(talk/contribs) 2015년 4월 7일(UTC)응답[응답]

@Edgars2007: 트리머를 구현했습니다.마침내.모듈에서 코드를 찾느라 내내 바보처럼 굴었어요알고 보니 템플릿에 있었어요.코드네임 리사(대화) 00:03, 2015년 4월 15일(UTC)응답[응답]

템플릿에서 변경된 내용:Hatnote가 Lua를 사용하기 시작했나요?.sr Wiki에서는 올바르게 동작하지 않기 때문에 텍스트는 이탤릭체로 표시되지 않고 왼쪽에서 띄어쓰기가 되지 않습니다.예: --Obsuser (talk) 2015년 12월 16일 (UTC)응답[응답]

@Obsuser:스타일은 MediaWiki에 정의되어 있습니다.Common.css.따라서 sr에 정의되어 있는지 확인해야 합니다.MediaWiki:Common.css도 마찬가지입니다.사용할 클래스 이름은 "hatnote"입니다.(이전에는 "dablink"와 "rellink"도 사용되었지만 이후 삭제되었습니다.) - Stradivarius^{♪ talk ♪} 06:37, 2015년 12월 16일(UTC)응답[응답]

@Stradivarius: 네, 업데이트 하겠습니다.감사합니다! --Obsuser (토크) 2015년 12월 16일 (UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

p._formatLink()는 카테고리 및 파일 링크에 대해 특수하게 구분되어 있지만 언어 코드 접두사가 있는 인터위키 링크에도 이것이 필요하거나 언어 링크로 취급됩니다.실제로 모든 링크에 대장을 추가하면 해가 되나요?기본 페이지는 기본 페이지와 동일하게 작동합니다.Langent (토크) 2016년 1월 28일 (UTC) 20:38 (응답)

@클라이언트:다른 많은 템플릿이 이미 하고 있듯이 기본적으로 콜론을 추가하지 않을 이유가 없습니다.지금으로서는 'if' 스테이트먼트를 코멘트하고 있습니다.이것이 고장났는지 아닌지를 판단할 수 있습니다.- Ahecht ( TALKPAGE
)23:58, 2016년 1월 28일 (UTC)응답 [응답]

코드를 정리했습니다.단점은 생각할 수 없어요, 아니면_formatLink를 대체하고 있지만 템플릿:대체용으로 포맷링크가 설정되어 있지 않고, 그 외의 장소도 알 수 없습니다._formatLink Wikitext에 직접 노출됩니다.Stradivarius^{♪ talk ♪} 씨 2016년 1월 28일 23:30 (UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

(Template talk에서의 이전 설명도 참조).노트)

<aside> 태그를 사용하는 것은 아직 가능하지 않기 때문에 역할 속성을 사용하여 동등한 접근성 컨텍스트를 추가할 것을 권장합니다.모듈:Hatnote/sandbox에는 변경 사항(diff)이 있습니다.화면 리더로 결과를 확인하고 싶은 사람이 있다면 mw:의 해트노트 템플릿: mw:와 비슷한 편집을 했습니다.스페셜:What Links Here / 템플릿:모자 노트.Matt Fitzpatrick (대화) 22:24, 2016년 2월 5일 (UTC)응답[응답]

diff 갱신.Matt Fitzpatrick (대화) 07:09, 2016년 2월 11일 (UTC)응답[응답]

누구의 반대도 받지 않고 끝냈습니다.Stradivarius님^{♪ talk ♪} 2016년 2월 12일 01:36 (UTC)응답[응답]

Scribuntu 템플릿을 다른 평가판 Wiki에서 작업하려고 합니다.모듈을 시도했을 때:다른 위키로 넘어갔는데 가져오는데 실패했어요

MediaWiki.org에서 infobox 템플릿을 Import하는 절차에는 Scribunto 및 lua 요소가 있는 템플릿을 Import하는 솔루션이 없습니다.갓블레스You2 (대화) 2016년 3월 28일 16:00 (UTC)응답[응답]

@GodBlessYo2: Scribunto 확장을 설치해야 합니다.그럼 효과가 있을 거야단, 올바른 콘텐츠유형을 가지려면 모듈을 삭제하고 다시 작성해야 할 수도 있습니다.- Stradivarius님^{♪ talk ♪} 2016년 3월 28일 (UTC)응답[응답]

Scribunto를 설치한 후에는 모듈 위에 복사해야 합니다.인수 및 모듈:예스노 --아히트(TALKPAGE
) 2016년 3월 28일(UTC) 16:24 (응답)

감사합니다! Scribuntu를 설치했는데 테스트 중에 Local Settings 라인에 코멘트가 있었습니다.Sribuntu가 네임스페이스를 활성화하기 때문에 모듈을 가져오지 못했습니다.제가 필요로 하는 주요 모듈을 찾아주셔서 감사합니다.다른 사용자를 돕기 위해 매뉴얼에서 문서를 확장했습니다.Wikipedia 정보 상자 가져오기 튜토리얼 GodBlessYou2 (대화)2016년 3월 28일 (UTC)응답[응답]

난 계속 장난치고 있었어forSee모듈에 추가한 기능:모자/샌드박스기본적인 생각은 엄청난 양의 해트노트가 리스트에서 변화를 일으키기 때문이다.For X, see [[Y]]" 스테이트먼트의 형식은 모듈을 통해 입수할 수 있습니다.모자 노트.

주요 기능은 현재 다음 세 가지 기능을 가지고 있습니다.

• 빈 매개 변수와 공백 공간이 미리 트리밍된 인수 목록입니다(음,_forSee인수 리스트를 직접 취득합니다.forSee사용하다getArgs(frame))
• "from" 숫자로, 해당 숫자의 매개 변수에서 시작합니다(예: {redirect}에서 사용된 초기 매개 변수를 건너뛰기 위해 2로 설정됨).
• 옵션 테이블이죠, 그건 꽤 표준적이거든요.

이 기능은 꽤 잘 작동하는 것처럼 보이지만, 더 우아할 수도 있습니다.특히, 저는 변종들이 교묘하게 추가하기 쉽도록, 인수 리스트를 전처리하는 부분을 분할하는 것이 타당하다고 생각합니다.또는 기능이 자체 모듈이어야 합니다.아니면 수정해야 할 다른 곳이 있을 수도 있습니다.

모듈에서의 몇 가지 빠른 해킹에 의한 초기 결과:리다이렉트 해트노트/샌드박스는 일부 엣지 케이스가 오프인 경우도 있지만 대부분 동작하고 있음을 시사합니다.

{{redirect REDIRECT USE1 PAGE1 USE2}}→

{{redirect/sandbox REDIRECT USE1 PAGE1 USE2}}→

어쨌든, 이것은 널리 이용될 것이기 때문에, 저만 보고 있는 것이 아니었으면 합니다.생각?{{Nihiltres talk edits} 16:13, 2016년 4월 7일(UTC) 답장 [응답]

해트노트 템플릿의 핵심 분석이 아직 누락되어 있습니다.즉, 카테고리:Hatnote 템플릿에는 최대 60개의 해트노트가 있으며 하위 카테고리에 더 많은 해트노트가 있습니다.이 모든 것의 패턴은 무엇입니까?나의 첫 번째 시도:

프라이머리:class=hatnote다음으로 토픽('토픽 X'에 대하여')이 있습니다.목록에 있을 수 있는 타깃 페이지('Y페이지' 참조)와 그 의미(해트노팅 관련성 설명)가 있습니다.나머지는 필러와 포맷입니다.

세컨더리: 템플릿에서는 <PAGENAME> 라벨이 사용됩니다( 참조).[[page label]]수신 리다이렉트 및 줄여서 --(dab)의 자동 추가.[첫 번째로 죽이고 싶은 동작은 해트노트 템플릿에 '(dab)'을 자동으로 추가하는 것입니다.더 나쁜 것은 <PAGENAME>과 결합되어 좌절감을 배가시킨다는 것입니다.제발 이런 식으로 저를 '도움'주는 것을 그만두세요. 제가 해트노트를 쓸 때, 저는 제가 무슨 말을 하고 있는지 알아요.사실 요즘은 {{hatnote}}개밖에 사용하지 않고 직접 글을 쓰고 있습니다.

Tertionary: 목록 처리, 문법

쿼티리오리나리오 이하:

-- 텍스트 적용

-- style 옵션(페이지 스타일 적응 허용, ENGVAR)

-- 기타 사항: 오류, 분류, 옵션 '내부 위키백과', ...

이제 범용 모듈: hatnote는 이러한 모든 문제를 적절한 우선순위로 다루거나 명확하게 거부해야 합니다.(이 샌드박스 제안은 그렇지 않다고 생각합니다.)핵심 모듈에 문장이나 "용"과 같은 단어가 포함되어 있어야 하는 이유는 무엇입니까?이는 주 mod: hatnote가 아닌 "열림 텍스트, 접두사 목록 텍스트, 목록 구분자"를 사용하는 등 전문 모듈을 추가하기 위한 것입니다.

- DePiep (토크) 2016년 4월 7일 17:19 (UTC)응답 [응답]

@DePiep: 나는 해트의 근본적인 디자인 원리에 대해 생각하는 것을 매우 좋아하지만, 그것은 이 논의의 범위 밖이다.

Grand Hatnote Overval (또는 그 어떤 것이든)의 첫 번째 목표는 기존 템플릿 세트를 현대화하고, 기존 사용을 표준화하며, 불필요한 변형 템플릿을 제거하고, 나머지 변형 템플릿의 범위를 하나의 목적으로 제한하는 것입니다.

즉, 그랜드 해트노트 오버홀의 대략적인 계획은 다음과 같습니다.

1. 기존 데이터 정리, 중앙 집중화 및 현대화("경관 단순화")
2. 범위, 의도, 특징 등 해트노트의 필요성에 대해 토론합니다(설계 질문).
3. 필요한 대로 해트노트를 구현하기 위한 작업(개선된 설계의 구현)

기존 시스템을 정리하기 위해서는 많은 작업이 필요합니다.이것에 우선 순위를 매겨, 일단 질문을 개시하면, 보다 의미 있고 생산성이 높아집니다.정리 작업을 조정하기 위해 Wiki Project를 시작해야 할 것 같습니다.

한편, 패턴의 좋고 나쁨을 불문하고, 기존의 패턴을 보다 표준으로 하기 위해서, 이 기능은 좋은 실장인가?패턴의 변경을 스코프에서 제외하고 어떻게 개선할 수 있습니까?{{Nihiltres talk edits}} 2016년 4월 7일 19:20 (UTC)응답 [응답]

물론 나는 해설자이고 네가 책임을 지니까 그게 끝이야.

하지만 기존의 패턴을 말하는 것이 아니라 본질적인 패턴을 말하는 것입니다. 즉, 어떤 해트노트(내 주요 노트)의 핵심입니다.

상위 해트노트 모듈을 변경할 것을 제안하기 때문에 상위 해트노트 문제를 생략할 수 없습니다(응답 및 샌드박스: "모든 해트노트 전용 함수"에서).

코어(위의 리스트에서 #0으로 표시)를 건너뛰어도 아무것도 해결되지 않습니다.그것은 단지 일을 지연시킬 뿐이다.

예를 들어 아래 #New docstyle 섹션을 작성했을 때, "Topic2"라는 단어가 토픽과! pagename으로 모두 사용되고 있다는 것을 알고 깜짝 놀랐습니다(그리고 현재 샌드박스에서 또 이상한 일이 일어나고 있습니다).이러한 혼재/분리는 mod: hatnote에서 방지해야 합니다.

따라서 mod:hatnote는 토픽과 페이지를 구별하고 목록을 작성할 수 있어야 하며 문법에 따라 단어들을 정리해야 합니다(텍스트 추가와 서식을 허용하지만 그것들을 규정할 수는 없습니다).그렇지 않으면 청소가 아니라 먼지를 교체하는 것입니다. (분명히 말씀드리기 위해 열심히 쓰고 있습니다.) - DePiep (토크) 19:44, 2016년 4월 7일 (UTC)응답[응답]

임의의 먼지를 중앙 집중식 표준 재사용 가능한 먼지로 대체한다면 "먼지를 교체"할 수 있습니다.{{Nihiltres talk edits}} 2016년 4월 8일 19:15 (UTC)응답 [응답]

당신은 너무 오만해서 믿을 수 없습니다.-DePiep (대화) 21:03, 2016년 4월 8일 (UTC)응답[응답]

이에 대한 Stradivarius씨의 조언을 읽고 싶습니다(Strad가 이 모듈을 작성했습니다).- DePiep (토크) 2016년 4월 7일 20:00 (UTC)응답 [응답]

우리 예습 좀 바꿀 수 있을까요?"Pagename"과 "Topic"만 사용됩니다.물론 제목으로요.실제로 10년이 지난 지금도 예시문 'USE1'은 나에게 아무런 의미가 없다(정말 정신적으로 'Topic1'을 뜻하는 'Usage1'로 번역해야 이해할 수 있다).

이전 항목에서 개선한 예:

• {{redirect FromRedirectPage Topic1 Targetpage1 Topic2}}→
  「FromRedirect Page」는 여기서 리다이렉트 됩니다.Topic1에 대해서는 Targetpage1을 참조하십시오.Topic 2 에 대해서는, 「FromRedirect Page」(구분)를 참조해 주세요.
• {{redirect/sandbox FromRedirectPage Topic1 Targetpage1 Topic2}}→
  「FromRedirect Page」는 여기서 리다이렉트 됩니다.Topic1에 대해서는 Targetpage1을 참조하십시오.Topic 2 에 대해서는, 「FromRedirect Page」(구분)를 참조해 주세요.

니힐트레스, 마지막 링크 변경 의도인가요?(좋은 데모 기능 보기;-) -DePiep (대화) 19:55, 2016년 4월 7일 (UTC)응답[응답]

기존 스타일의 올캡 부분은 입력 텍스트가 통과하는 위치를 강조 표시하기 위해 시각적 대비가 추가되기 때문에 매우 유용합니다(다른 텍스트는 문장 대/소문자이기 때문에).이름 짓기에 그다지 집착하지는 않지만 패턴상으로는 다음과 같이 해야 할 것 같습니다.

1. 페이지 이름을 반영하기 위한 입력 예에 "PAGE" 문자열을 포함합니다.
2. 일반 텍스트로 전달되는 입력 예에 "TEXT" 문자열을 포함합니다.
3. 입력 예제를 실제 사용 중인 대체품을 반영하도록 합니다.

예를 들어 다음과 같습니다.

• {{redirect2 REDIRECTPAGE1 REDIRECTPAGE2 USAGE1 PAGE1}}→
  "REDIRECT PAGE1" 및 "REDIRECT PAGE2"는 여기서 리다이렉트 됩니다.USE1에 대해서는 PAGE1을 참조하십시오.
• {{about TOPICTEXT USAGE1 PAGE1 and PAGE2}}→
  이 모듈은 TOPICTEXT에 관한 것입니다.USE1에 대해서는 PAGE1 및 PAGE2를 참조하십시오.

{{Nihiltres talk edits}2016년 4월 7일(UTC) 20:11 (응답)

아뇨, 그 문서 방식이 도움이 되진 않아요이 모듈레벨에서는 토픽과 페이지가 계속 혼재하고 있습니다(지금까지 텍스트를 추가해도 상관없습니다). (그런데 주의해서 보여드렸듯이 샌드박스의 파라미터 사용방법이 변경되어 있는 것을 알 수 있습니까?)[모두 대문자로 쓰라는 초대를 받지 않습니다.지금으로서는.- DePiep (대화)

@DePiep: 좋습니다.그럼 제안하신 계획의 원칙은 무엇입니까?제 예에서 당신이 비판하는 것이 무엇인지 잘 모르겠습니다.또, 샌드박스화된 코드의 불일치도 알고 있습니다.상기 지적은 제가 했으니까요.단, 이 점을 고려하면:

• {{redirect REDIRECTPAGE1 TOPIC1 PAGE1 other uses}}→
  「REDIRECT PAGE1」은, 여기서 리다이렉트 됩니다.TOPIC1에 대해서는 PAGE1을 참조하십시오.그 외의 용도는, 「REDIRECTPAGE1」(명료화)를 참조해 주세요.
• {{about ABOUT-TEXT TOPIC1 PAGE1 other uses}}→
  이 모듈은 ABOUT-TEXT에 관한 것입니다.TOPIC1에 대해서는 PAGE1을 참조하십시오.다른 용도는 Hatnote(명료화)를 참조하십시오.
• {{redirect/sandbox REDIRECTPAGE1 TOPIC1 PAGE1 other uses}}→
  「REDIRECT PAGE1」은, 여기서 리다이렉트 됩니다.TOPIC1에 대해서는 PAGE1을 참조하십시오.그 외의 용도는, 「REDIRECTPAGE1」(명료화)를 참조해 주세요.

...샌드박스화된 코드의 동작이 실제로 더 바람직하다는 것을 알 수 있습니다.{{Nihiltres talk edits}} 2016년 4월 7일 23:04(UTC)응답 [응답]

대문자를 쓰는 것은 실제로 외치는 것입니다.그만해. -DePiep (대화) 00:23, 2016년 4월 8일 (UTC)답글[답글]

어? 이 스레드는 템플릿을 문서화, 데모, 설명하는 방법에 대한 것입니다.템플릿이 제대로 작동하는지 여부가 문제가 아닙니다(샌드박스 변경은 다른 곳에서 설명합니다).이제 내 제안에 대해 되돌아갈 수 있나요? -DePiep (대화) 23:10, 2016년 4월 7일 (UTC)응답[응답]

대문자를 계속 쓰네요.날 트롤하려는 거지?나를 속여서 욕설(대소문자)을 하게 하는 거지?이제 평화를 되찾기 위해 대문자 및 성공 사례를 실제로 사용하는 중요한 문서를 지적할 수 있습니까? -DePiep (토크) 23:14, 2016년 4월 7일 (UTC)응답[응답]

이런, 자네 사례는 더 심하군데모해서 (여기 데모에서) "기타 용도"를 사용하려고 했는데, 템플릿 코드 텍스트가 아니라 입력 텍스트라는 것을 알게 되었습니다.Etheretera 등: 항상 텍스트, 구조, 의미가 뒤섞여 있습니다.정말 형편없는 접근법이다.나는 더 이상 너를 도울 수 없다.마지막(& first) 조언: 대문자를 사용하지 마십시오. -DePiep(토크) 23:57, 2016년 4월 7일(UTC)응답[응답]

re OK, 그럼 제안 스킴의 원칙은 무엇입니까? : 1. 대소문자가 아닌 제목 대소문자를 사용합니다.절대. (혹은 다음 주에 당신은 당신의 문서를 이해하지 못할 것입니다.)2. 1번을 다시 읽어라. 11번."Topicn"과 "Targetpagen"을 처음부터 끝까지 사용합니다.어떤 대가를 치르든 12개. (나중에 더 많이)- DePiep (토크) 00:14, 2016년 4월 8일 (UTC)응답[응답]

대문자 현상에 찬성하고 제목 대문자 전환에 반대합니다.이미 가독성이 있다고 생각한다고 말씀드렸습니다만, (명확한 문서적 맥락으로 볼 때, 「고함」이라고 하는 주장과는 달리) 실질적인 반론을 제시하고 있지 않습니다.적어도 다른 사람들이 언급할 때까지, 나는 그것을 그대로 두겠다.{{Nihiltres talk edits}} 19:12, 2016년 4월 8일(UTC)응답 [응답]

WP:SHOUT는 그것을 멈추기에 충분한 이유입니다(#1).또, 대문자로 문서를 작성할 수 있는 예에 대해서도 질문했습니다만, 지금까지의 예로는 없습니다(#2).또, 판독 가능한 입력을 사용한 후에만, 1개의 입력이 2개의 의미론(토픽&파게네임 혼재)에 사용되고 있는 것을 알 수 있다고 지적했습니다(#3).이 세 가지 이후, 당신의 개인적인 의견과 선호는 그다지 중요하지 않죠? -DePiep (대화) 21:01, 2016년 4월 8일 (UTC)응답[응답]

Wikipedia 토크에서 토론을 시작했습니다.Hatnote #해트노트의 "X의 경우 Y 참조" 항목 목록을 생성하는 코드 표준화 및 중앙 집중화에 대한 참조 목록 표준화토론은 이 페이지에 영향을 줄 수 있지만 다른 페이지와 관련이 있기 때문에 이 페이지에 배치되어 있습니다.관심 있으시면 거기서 코멘트 부탁드립니다.{{Nihiltres talk edits}} 2016년 4월 27일 (UTC) 17:26 (응답)

루아피 해트노트 작업을 하면서 이 모듈이_hatnote()함수는 카테고리를 지원하지 않습니다.대부분의 시간 카테고리는 문자열로 부적절하게 연결되거나 콜 후에 에 추가됩니다._hatnote()또, 각자가 카테고리 처리를 재실장할 필요가 있어, 다양한 템플릿/모듈간에 불일치가 발생하고 있습니다.예를 들어 {{About}}에는 Lua로 이행할 때 생략한 카테고리 처리가 몇 가지 있었습니다(카테고리는 비어있기 때문에 긴급하지 않지만…)._nocatModule의 경우 표준:Hatnote 기반 템플릿은 다음과 같습니다.args.category.

제가 이 일을 더하는 것에 대해 이의를 제기하는 분?category에 대한 의론._hatnote()테이블을 받아들이도록 코드를 설정합니다(또는nil카테고리 이름 키(복제 키 포함) 및false또는 category-key(string) 값을 지정하여 해트노트 텍스트 뒤에 카테고리 목록을 출력합니다.도우미 기능도 추가하겠습니다.addCategory()각 해트노트 모듈에서 항목을 다시 구현할 필요가 없도록 카테고리 테이블에 항목을 추가합니다.제가 망설이고 있는 가장 큰 이유는_hatnote()템플릿 인수 자체는 취득하지 않습니다.템플릿은 각각 다음과 같은 것을 포함해야 합니다.yesno(args.category)출력을 전환합니다.자체 완비되어 있지 않습니다.

다른 카테고리를 처리하는 방법에 대한 접근법과 제안을 100% 확신할 수 없습니다.{{Nihiltres talk edits}} 2016년 5월 11일 14:44 (UTC)응답 [응답]

SMc Candlish는 Wikipedia 토크에서 다음과 같이 지적했다.Hatnote # 존재하는 모듈 설명(참조 목록 표준화):Hatnote inline 및 {{hatnote inline}}은(는) 이 모듈과 {{hatnote}의 기능을 대부분 복제합니다.따라서 인라인 해트노트에 대한 지원을 추가하는 이 모듈의 간단한 개선 사항을 프로토타입으로 만들었습니다.inline모듈이 송신하는 파라미터 또는 인수<span>가 아닌 요소<div>이로 인해 인라인 고유의 모듈 및 템플릿이 자연스럽게 사용되지 않게 되므로 이 모듈의 기능은 중복되지 않을 수 있습니다.의견, 의견 또는 반대 의견이 있으십니까?{{Nihiltres talk edits}20:26, 2016년 6월 21일(UTC)응답[응답]

인라인 해트노트는 저에게 모순처럼 들립니다.'해트노트'의 '모자'는 내용 위에 있다는 뜻이죠?동시에 인라인일 수 없습니다.모듈:Hatnote inline은 SMc Candlish가 링크된 토론 섹션에서 합의를 찾을 수 없었기 때문에 작성한 포크처럼 보이며, MFD로 전송되어야 합니다.그리고 만약 우리가 이런 것을 사용하기로 결정한다면, 우리는 적어도 이름을 바꿔야 합니다.- Stradivarius님^{♪ talk ♪}, 2016년 6월 21일 (UTC)응답[응답]

하지만 그들은 종종 그렇지 않다.여러 가지, 예를 들면{{further information}}그리고.{{detail}}아래 콘텐츠에서 자주 사용되고 있습니다.또한 100만 건이 넘는 사람들이 자신의 표현으로 인라인 상호 참조를 수동으로 삽입하고 있습니다(예를 들어 "이 내용은 ...에서 자세히 다루어집니다." 등).또한 템플릿을 추가함으로써 유지보수를 대폭 개선할 수 있습니다. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 22일 04:19 (UTC)응답[응답]

나는 일반적으로 해트노트 시스템을 간소화하는 것 외에 그 문제에 대해서는 중립적이다.모듈:Hatnote inline은 어느 쪽이든 폐지/머지/삭제해야 합니다.또한 "Inline hatnotes"는 완전히 삭제할 의향이 있지만 {{crossreference}, {{see above}}, {{see }} 등의 용도에 대응해야 합니다.Lua와 Wikitext는 모두 이들을 지원하는 혼란스러운 요소가 있지만 전체적으로는 약 300개의 트랜슬레이션에 불과합니다.사실 지금 자세히 보니 {{위 참조}와 {{아래 참조}}}은 불필요한 커스터마이즈가 가능한 무서운 몬스터입니다.{{Nihiltres talk edits}} 2016년 6월 21일 23:51, (UTC)응답 [응답]

스크랩 하려고 했는데{{see above}}그리고.{{see below}}그리고, 어쨌든 그것들을 단순한 것으로 대체한다.모듈의 경우:Hatnote 인라인에서는 대부분의 Lua는 모듈의 용장 코드일 뿐입니다.Hatnote: 앞서 설명한 바와 같이 유일한 실제 차이점은<div>...</div>대.<span>...</span>. — SMc Candlish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 22일 04:19 (UTC)응답]

원래 위에 올렸는데 여기로 옮기겠습니다.

이를 통해 얻을 수 있는 것은 적어도 다음 중 모든 것이 실용적이라는 것입니다.

• <span>(기존의 "모자" 위치 또는 기타 위치에 있는) 베이스의 해트노트는, 다음의 배치 시나리오에 사용할 수 있습니다.<div>...</div>문서 흐름이나 잘못된 마크업을 방해할 수 있습니다.예를 들어,{{ghat}}.
• 상호 참조는 주의가 산만해지는 톱시팅 해트노트로 할 필요는 없지만 필요에 따라 덜 눈에 띄는 인라인 방식으로 배치할 수 있습니다.(이미 수많은 곳에서 수십만 건의 기사에서 일관된 템플릿이 아닌 손으로 쓴 메모로 일관성이 없는 작업을 수행하고 있습니다.)
• 인라인 CSS와 블록 CSS 중 어느 쪽에서만 다른 템플릿과 모듈을 Marge(및 재포킹하지 않음)함으로써 템플릿의 폭주를 줄일 수 있습니다.

이러한 혜택과 관련된 비용은 없습니다.이러한 이점이 있어야 하는 기존 템플릿에서 파라미터를 지원할 수 있도록 하는 것 외에<span>대신<div>(기존의 모든 해트노트에 이것이 필요한 것은 아닙니다.예를 들어, 명확화를 목적으로 하는 해트노트는 항상 페이지 톱 해트노트로 해야 합니다만, 문맥상 상호 참조는 다음과 같습니다.{{further information}}그리고.{{details}}유연성이 있어야 합니다.)기본 메타 코드를 템플릿이라는 이름으로 계속 호출할지 여부:노트 및 모듈:Hatnote는 전혀 중요하지 않다(WP:상식, WP:관료주의 및 WP:IAR은 해트노트를 생성하는 코드의 용도 변경 방법에 대한 "규칙"이 실제로 존재하는 것이 아닙니다.)이 "모자" 버저가 가상의 의사 문제라는 사실은 2년 이상 전에 지적되었습니다(#Inline variant 참조). 이 기간 동안 포크형 인라인 해트노트 코드는 문제없이 작동했습니다.이 기능을 통합하면 이전 기능에 대해 누군가가 생각해낸 귀여운 이름과는 다른 새로운 기능을 사용하지 않도록 하는 것보다 더 생산적인 것으로 돌아갑니다.정말이에요. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 22일 04:19 (UTC)응답[응답]

모듈에 대한 최근 변경 사항:Hatnote inline은 적어도 {{Crossreference}}이(가) 손상된 것 같습니다. 인라인 콘텐츠를 만들려는 명시적 의도에도 불구하고 블록 콘텐츠로 표시됩니다.Wikipedia 참조:신뢰할 수 있는 소스 특정 #일부 예에 대한 예외입니다.털북숭이 남자 (대화) 2016년 7월 17일 14:47 (UTC)응답[응답]

@Hairy Dude: 여기서는 문제를 재현할 수 없다.모듈 개서를 재확인했습니다.Hatnote는 인라인으로 정상적으로 표시됩니다.이 예의 {{crossreference}} 인스턴스는 (인라인) 스판 요소로 올바르게 표시됩니다.또한 MediaWiki의 CSS는 다음과 같습니다.Common.css는 블록 수준의 스타일을 적용하지 않습니다..hatnote, 단,div.hatnote. {{Nihiltres talk edits} 16:40, 2016년 7월 17일 (UTC)응답[응답]

@니힐트:Wikipedia에서 블록 디스플레이를 보고 있습니다.신뢰할 수 있는 소스 특정 #예외 ('링크' 참조 비트).위반 요소를 검사하면 이 규칙이 다음에서load.php적용:.hatnote { display: block !important }. 털북숭이 (대화) 2016년 7월 17일 19:21 (UTC)응답[응답]

@요정남자:사용자까지 추적:털북숭이/공통.css.{{Nihiltres talk edits}} 19:59, 2016년 7월 17일(UTC)응답 [응답]

@니힐트:나는 바보다.감사합니다 :) 털북숭이 아저씨 (대화) 2016년 7월 18일 00:05 (UTC)응답하세요

"Hatnote"는 더 이상 이 모듈의 기능과 모듈을 사용하는 메타 템플릿 및 그 하위 템플릿을 설명하지 않습니다.가장 빈번한 사용 사례만 설명하고 있습니다.이로 인한 혼란은 코드 실전 배치의 현실을 부정하는 2년 이상의 비생산적인 순환 토론으로 이어졌다.

• 적어도 카테고리에 직접 분류된 템플릿:모듈을 사용하는 상호 참조 템플릿:해트노트는 종종 내용 위의 해트노트로 사용되지 않고 내용 아래의 "슈트노트"로 사용됩니다.
• 어떤 것들은, 예를 들면...{{More2}}이 방법밖에 사용할 수 없습니다.왜냐하면, 상단에서 의미가 없기 때문입니다.(일반적으로 이 명령어를 사용하도록 강제하는 것은 큰 의미가 없습니다).{{Hatnote}}님은 현재 필수입니다.<div>; 많은 경우 공간을 낭비하고 문서 흐름을 방해합니다.)
• 다른 사람, 예를 들면{{Qnote}}는 완전히 다른 것(이 경우 생략 가능 또는 각주)이며 상호 참조나 WP 자기 참조가 전혀 아닙니다.
• 인라인 바리안트(사용)<span>현재 모듈에 의해 생산됩니다.Hatnote inline)은 포크 코드베이스를 계속 가질 필요는 없습니다."모자" 위치에서는 잘 사용되지 않습니다.{{ghat}}예외입니다).

"모자" 시나리오 제한은 이 모듈의 실제 코드베이스와 종속 메타템플릿이 실제로 어떻게 사용되는지와는 무관합니다.

이 페이지의 이전 설명에서 적어도 두 명의 편집자가 "해트노트"라는 용어를 모자처럼 컨텐츠의 맨 위에 있는 메모로 문자 그대로 해석하려고 하므로, 명백한(아마도 유일한) 해결책은 이름만 바꾸는 것입니다.모듈:메타 노트 및 템플릿:메타노트는 잘 될 거야간단한 해결책, 드라마 제로.그러면 "해트노트"라는 용어가 카테고리에서 계속 사용될 것입니다.해트노트 템플릿 등 실제로 해트노트 위치에 사용되는 템플릿의 설명(이 모듈에서 생성되는지 여부)이 솔루션을 사용하면 이 모듈에 대한 명확성을 높이고 비생산적인 접근을 방지하는 방식으로 형태와 기능을 분리할 수 있습니다. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 22일 (UTC)응답

이름 변경 및/또는 범위 확장이 현재 해트노트에 의해 정해진 구조 규범을 되돌리지 않을까 우려됩니다.적어도 현시점에서는 해트노트가 항상 페이지나 섹션의 맨 위에 있고, 큰 주제 네비게이션 박스를 제외한 대부분의 네비게이션 메타 콘텐츠는 해트노트의 형태로 제공된다는 예상이 있다.예를 들어 {{main}}이(가) 요약 스타일에 얼마나 중요한지 생각해 보십시오.이러한 구조적 규범들은 사람들이 같은 역할에서 같은 장소에서 일어나는 것에 의존할 수 있기 때문에 해트를 가치 있게 만드는 것을 돕습니다; 특히 다른 사람의 경우를 고려하세요.hatnoteCSS 클래스: 일관성 있고 의미론적으로 사용되지 않으면 클래스는 값이 없습니다.

물론, 확대가 더 일관되게 만든다면 반드시 나쁜 것은 아니다."해트노트"는 원래 섹션이 아니라 페이지 맨 위쪽에 더 엄격했습니다.그리고 2009년에 {{rellink}(현재는 {{hatnote}로 통합)을 만들었을 때, 저는 그 표준을 넓히는데 직접 참여했습니다.메타 템플릿 아래에 "관련 링크"를 "해트링크"({dablink})와 같은 방법으로 묶었습니다.{{hatnote}})로 이름이 바뀌었기 때문입니다.

<div> 요소가 중단될 수 있는 몇 가지 경우 해트를 인라인으로 사용할 수 있도록 하는 것이 가치 있다고 생각합니다만, 범위를 넓히기 전에, 해트를 사용하는 특수한 방법(예를 들면, 「슈노트」의 예)으로 규율이나 정규화를 실시할 수 없는 것을 확인해 둘 필요가 있습니다.다양한 용도에 맞게 템플릿을 넓히는 것이 아니라또, 다음의 예에서는, 많은 예외가 있습니다.모듈:Hatnote inline은 최대 300개의 기사에만 사용되며 주요 규범 모듈은 다음과 같습니다.햇노트는 100만 명을 돌파했다.예 {{more2}}은 현재 1개의 메인스페이스 트랜슬레이션을 가지고 있으며 문서에는 "여기서 {{details}은 너무 상세}}"로 설명되어 있습니다.그것은 그 자체의 용장성을 인정하고 있습니다.

좋은 활용 사례가 있다는 것은 공감하지만, 기사 구조의 핵심 요소이기 때문에 가능한 한 심플하고 균일하게 할 수 있는 것은 큰 가치가 있습니다.내가 다른 방향으로 악마의 어드바이스 주장을 합리적으로 해 낼 수 있다고 생각하는 것은 당신의 경우 도움이 되지 않습니다.대신 범위를 좁혀서 {{hatnote inline}}과(와) 같은 것을 완전히 배제하는 것이 어떨까요?{{Nihiltres talk edits}} 2016년 6월 23일 00:46(UTC)응답[응답]

저는 그것을 제시된 정신으로 받아들이고 이 점들에 대한 반론을 제기할 것입니다."최고성"에 대한 이 광범위한 기대는 환상이다.이러한 종류의 다양한 템플릿은 이 모듈의 존재보다 훨씬 이전으로, 원본 템플릿이 사용되었습니다.{{Hatnote}}Meta-template는 Lua 이전에도 사용되었으며, Olden Tymes 이후 컨텐츠 위가 아닌 아래에서도 자주 사용되고 있습니다.예를 들어, {{Details}}은 2005년 중반까지이며, 이러한 방법으로 자주 사용되고 있습니다(이는 어떤 가이드라인이나 정책, 상식에 위배되지 않습니다). 그리고 상기의 내용은 전혀 의미가 없는 {{More2}}은 2009년으로 거슬러 올라갑니다.

물론 우리가 구조적인 규범을 가지고 있다는 것에 동의하지만, 이러한 규범들이 무명하게 설정된 것은 아닙니다.Module:네임스페이스 페이지, 대부분의 편집자와 독자는 존재조차 모르는 페이지입니다.MOS에 의해 쉬운 영어로 설정되어 있습니다.레이아웃, WP:해트노트, WP:요약 등은 갑자기 변경되지 않고 "인라인 노트와 혼동되는 레이아웃을 사용할 수 있습니다."라고 말하는 대신 대부분의 경우 기존 intended-div 해트노트를 계속 권장합니다(증거: 특정 기간 동안 인라인 해트노트가 사용 가능함에도 불구하고 현재도 사용 가능함).기타 사항)Meta-Template의 호출은 SUMARY가 {{Main}}을(를) 권장하는지 또는 템플릿의 이름에는 영향을 주지 않습니다.다른 용도로 더 많이 사용되는 도구의 새로운 용도로 재사용해도 원래 사용이 위험하거나 무효화되지는 않습니다(저는 정기적으로 빗을 백스크래치로, 전화기를 MP3 플레이어로 사용합니다).

스코프 확장은 없습니다.대부분의 용장 코드를 가진2개의 모듈간의 스코프 Marge만 가능합니다.이것은 새로운 템플릿 세트를 작성하기 위한 권한 요청이 아닙니다.효율성과 유지보수를 용이하게 하기 위해 중복되는 두 템플릿을 조합하는 것을 제안합니다.

마크업 상황에 따라서는 디브(div)를 삽입할 수 없는 경우도 있습니다.(또한 템플릿 에디터가 레이아웃 경찰 역할을 하는 것은 템플릿 에디터의 일이 아니며, 명확한 이유 없이 어떤 대가를 치르더라도 모든 기사를 제한적인 레이아웃 가능성에 따르도록 강요합니다.)거의 동일한 두 개의 모듈을 합친 것, 즉 하나의 개가 전체 품종을 흔드는 것과 같습니다.)다른 경우(예를 들어 {{Ghat}})에는 특정 상황에서 들여쓰기가 바람직하지 않다는 문제를 피할 방법이 없습니다(다른 커스텀 코드를 사용하면 같은 처지로 돌아갑니다).

인라인 기능은 주로 div 및 span 템플릿/모듈 분할, 문서 지원 부족, {{crossref}}을(를) 사용하도록 인라인 상호 참조를 변환하는 우선 순위가 낮기 때문에 널리 배포되지 않습니다(AWB 또는 봇의 종류에 가깝습니다).만약 저나 다른 누군가가 AWB와 함께 한 시간을 보내기로 결정한다면, 그것은 훨씬 더 많은 페이지 순서로 사용될 것입니다.모든 새로운 템플릿은 여러 페이지에서 사용될 때까지 몇 페이지에서 사용됩니다.적용 범위가 제한된 모든 템플릿은 적용 범위가 훨씬 넓은 템플릿보다 적은 페이지에서 사용됩니다.공식적으로 규정된 기능을 가진 사람들은 그렇지 않은 사람들보다 더 일관되게 발견될 것이다."100만 번 사용하지 않는 템플릿 삭제" 표준은 없습니다.TfD 기준에 따르면, 300개는 유지하기에 충분하고, 결국엔 훨씬 더 높아질 것입니다.

WP가 기능하는 데 꼭 필요하지 않은 시스템상의 모든 템플릿을 제거하기 위해 당신의 악마의 옹호 사례가 만들어질 수 있습니다.그러나 우리는 그렇게 하지 않습니다.편집자는 자유롭게 템플릿을 작성, 개선 및 통합할 수 있습니다.수백만 개의 인라인 상호 참조가 있습니다.수동으로 포맷되어 있고, 매우 일관성이 없는 방식으로 되어 있으며, 많은 경우 도움이 되지 않습니다.이를 정리하는 것에 대한 실질적인 반대는 없으며, 가장 확실한 방법은 이미 활성화되어 있는 방법입니다. 즉, div 대신 스팬을 사용하는 템플릿을 사용하여 해트노트 코드를 변경하는 것입니다.이러한 상호 참조를 몇 가지 예측 가능한 형식으로 정규화하기 시작합니다(위의 실험적인 see-to-do 목록에 이미 있는 템플릿은 완전히 수정하고 교체해야 합니다).수작업으로 작성된 랜덤하고 혼란스러울 정도로 일관성이 없는 프로토 해트노트가 곳곳에 있다는 사실 때문에 처음부터 해트노트 템플릿이 만들어진 것입니다. 케이스는 매우 유사합니다.그리고 표준화를 위한 노력 끝에 사용 지침과 규범이 개발되었습니다.

요점은: WP는 점진적인 개선에 의해 작동하며 관료주의에 얽매이지 않는다.코드는 이미 동작하고 있습니다.코드를 병합하는 것이 더 실용적일 뿐입니다.이 "해트노트도 아니고 div도 아니기 때문에 죽여야 한다"는 것은 기능보다 형태를 우선시하고 현재보다 과거가 우선이다. - SMC Candelish ☺☏ ^ʌ_ᴥ2016년^ʌ 6월 26일 16:53, UTC

• 제안된 이름 "메타 노트" OTOH가 너무 넓습니다.또한 ENGVAR 메시지 및 유지관리 태그(이것도 메타)와 같은 다른 참고 사항을 포함할 것을 권장합니다.또한 "형식과 기능을 분리"하기 위해 이름 대신 모듈/템플릿에 대한 설명적인 템플릿 제목을 만듭니다.이것은 편집자 공간(콘텐츠 공간이 아님)이기 때문에 이를 정확하게 할 필요는 없습니다.기억하기 쉬운 이름을 자유롭게 선택해 유지할 수 있고, 원하는 대로 의미를 입력할 수 있습니다.설명적인 마이너 포인트에서는 틀릴 수 있습니다.이름은 OK입니다.-DePiep (토크) 11:43, 2016년 6월 27일 (UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

T164781에 따라 이 모듈의 출력에 '내비게이션 검색 불가' 클래스를 추가해야 합니다.그러면 검색 스니펫에서 해트노트가 제거되고 해트노트의 내용이 검색 결과를 바이어스하지 못하게 됩니다.자세한 내용은 Fabricator 작업을 참조하십시오.Kaldari (토크) 2017년 5월 9일 03:17 (UTC)응답[응답]

완료 - JJMC89(T·C) 5:20, 2017년 5월 9일(UTC) 응답[응답]

만약 이 일이 일어난다면_formatLink함수는 자동으로 밑줄을 공백으로 바꿉니다.사용자가 항상 공백이 있는 링크를 삽입하는 것이 이상적이지만 항상 그런 것은 아닙니다. 슬로바키아어 역사 개정판의 이 섹션을 참조하십시오.페이지명과 섹션 모두 밑줄이 있어 보기 흉합니다.모듈이 항상 공간을 표시하면 이 문제는 피할 수 있습니다.Wiktionary에서 이와 거의 동등한 기능을 수행하도록 했습니다.section_link모듈:링크)에서 기능을 수행합니다.- Eru·tuon 2017년 7월 21일(UTC) 17:53 (응답)

• 입력으로 발생할 수 있는 모든 문제를 해결하는 것은 템플릿과 모듈의 책임이 아닙니다.제목에는 일반적으로 밑줄이 포함되어 있습니다.해트노트에 있는 제목을 링크하는 데 이 모듈의 기능을 사용할 필요는 없습니다.누군가가 링크에 부적절하게 밑줄을 남겼을 경우 해결책은 해당 링크를 편집하고 공백으로 바꾸는 것입니다.{{Nihiltres talk edits}} 2018년 6월 25일 19:39 (UTC)응답 [응답]

  난 이걸 반대편으로 기대겠어.여전히 의미 없는 밑줄이 있는 "크랩 링크"의 수는 기술적으로 밑줄이 있어야 하는 타이틀의 수보다 훨씬 많다(그리고 그것들은 어쨌든 그것 없이도 작동할 것이다).즉, 불필요한 밑줄을 제거하기 위해 수동으로 링크를 청소하는 데 낭비되는 편집 시간은 아마도 수백만 분의 1 정도의 이상한 제목에 수동으로 추가하는 시간을 줄일 수 있습니다.그리고 이것은 확실히 우리가 하는 가장 큰 폭의 링크 청소 중 1위입니다. - SMC Candelish ☏ ¢ 😼 2018년 6월 26일 03:27 (UTC)응답[응답]

  @Nihiltres 및 Erutuon:SMc Candlish에 동의.오픈 WP:ER이 승인되었습니다. 다른 ER을 만들겠습니다.Psiededelisto (토크 • 기고) 2020년 6월 13일 (UTC)응답[응답]

  아, 더 늦기 전에 분명히 해야겠어요.선택적인 파라미터로 추가할 수도 있어요._=r ("communicores equals replace"로 읽음) 또는 수동으로 확인해야 하는 언더스코어 인스턴스 수를 조사하여 모두 체크합니다.기본 동작을 변경하는 템플릿 보호 편집 요청을 열지 않습니다. 기본 동작에 대한 모든 영향과 계획을 가지고 있지 않습니다.그러니 그 니힐트레스 걱정은 하지 마Psiededelisto (토크 • 기여) 2020년 6월 14일 01:40 (UTC)응답[응답]

  • @Psiededelisto:옵션이라면 최악의 아이디어는 아니지만, 저는 여전히 밑줄을 다시 포맷하는 것을 좋아하지 않습니다. 왜냐하면 a) 예상하지 못한 경우와 b) 깨질 가능성이 있기 때문입니다(밑줄이 바람직한 경우).기존의 포맷 내용은 (a)와 일치할 수 있지만 (b)와 일치하지 않을 수 있습니다.단, regex 기반의 검색을 사용하여 퀵테스트를 실시했는데, 타임아웃(regex 검색은 비용이 많이 든다)은 언더스코어를 포함한 입력으로 호출 {{main}페이지 220히트를 생성해 약 28만페이지로 변환했습니다.처음 20회의 조회수 중 6회는 "labeln" 구문을 사용하여 링크를 덮어쓰고 언더스코어 없이 다른 항목을 표시합니다.이는 모듈레벨에서 필터링하는 것이 아니라 수동으로 인스턴스를 수정하는 것을 정당화할 수 있을 정도로 적습니다.수동으로 수정하여 추가 검색에서 더 많은 인스턴스가 표시되는지 확인합니다.{{Nihiltres talk edits} 2020년 6월 15일 (UTC) 20:44 (응답)
    • @니힐트:모듈 레벨이 아닌 {{format link}에서 {{replace}}까지 필터링하는 것에 대해 어떻게 생각하십니까?Psiededelisto (토크 • 기여) 2020년 6월 15일 (UTC)응답[응답]
      • @Psiededelisto:검색hastemplate:"format link" insource:/\{\{ *format link[^\}_]*?_[^\}_]*?\}\}/는 타임아웃되지 않고 결과도 없습니다.이는 동작에 의해 기존의 트랜슬레이션이 변경되지 않음을 나타냅니다.그것은 그 수준에서 변화를 일으킬 가치가 없다는 것을 암시한다.{{Nihiltres talk edits} 2020년 6월 15일 (UTC) 20:56 (응답)

그 selfref=true이 기능은 매뉴얼에 {{selfref}을(를) 복제한다고 나와 있습니다.단, 모듈에서는 클래스 "selfref"를 추가하고 {{selfref}}에서는 "plainlinks selfreference noprint"를 추가합니다.똑같아야 하지 않을까요? --Ahecht (TALKPAGE
) 18:53, 2018년 8월 23일 (UTC)응답[응답]

• @Ahecht:네, 아마도 우리는selfref그리고.selfreference일관성이 있습니다.문제는 단순히 어느 쪽을 선택할 것인가 하는 것입니다.예를 들어 몇 가지 검색을 기반으로 합니다.insource:selfreference -insource:/tl\ selfref/ -insource:/\{\{selfref/ -hastemplate:selfref미디어위키와 템플릿 네임스페이스에서는selfref더 많이 사용될 수 있습니다.하지만 나는 그것에 대해 까다롭지 않다.추가 클래스는 장황합니다.noprint해트노트는 이미 MediaWiki에서 제외되어 있습니다.Print.css 및plainlinks해트노트에 외부 링크가 포함되어서는 안 되기 때문입니다.{{Nihiltres talk edits} 2018년 12월 19일 (UTC) 20:07 (응답)

  저는 이 마지막 점에 의존하지 않습니다.우리는 이것이 미래에 어떤 용도로 사용될지 정확히 예측할 수 없습니다.또한 "해트노트에는 외부 링크가 포함되어서는 안 된다"는 생각은 실제로 메인스페이스 및 기타 독자용 콘텐츠에만 관련되어 있습니다.프로젝트 공간 및 사용자 공간에 대해서는 적용할 "규칙"이 없습니다. 이러한 링크의 잠재적 사용 사례가 있습니다(예: Wikia [Wikia [무슨 바보 같은 이름], 미트볼 또는 기타 Wiki). - SMC Candelish ☏ ¢¢ 😼 2020년 6월 16일 06:51, UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

안녕하세요. 법률 기사의 경우 종종 이탤릭체를 사용해야 합니다.예컨대, Quaranto, Ex Parte Quirin, Toth v. Quarles.그러나 현재 {{format link}}에서는 이 작업을 수행할 수 없습니다.따라서 WP에 반하는 것으로 보인다.MOS: {{hatnote}, {{see also}} 등에 사용되는 자동 이탤릭체로 표시되는 경우가 많지만, 이 템플릿을 단독으로 사용하는 경우가 많습니다.그래서 수정했습니다.

• {{format link Quo warranto#Philippines italicizearticle=y}}

여기서 얻을 수 있는 것은, 다음과 같습니다.§ 필리핀

• {{format link Cybercrime Prevention Act of 2012#Disini v. Secretary of Justice italicizesection=y}}

여기서 얻을 수 있는 것은, 다음과 같습니다.2012년 사이버범죄방지법 § 디시니 대 법무장관

도움이 될 만한 예가 생각나지 않지만, 둘 다 협력하고 있습니다.사용자:예를 들어 Psi-edelisto/샌드박스입니다.(주의: 버그가 아닌 이탤릭체로 된 페이지명은 해당 페이지에서 테스트된 대법원 템플릿에 의해 발생합니다.)

따라서 다음을 복사하십시오.

1. 모듈: Sandbox/Psi-secedelisto/Hatnote → 모듈:해트노트
2. 사용자: Psi440edelisto/Format 링크 → 템플릿:포맷 링크

감사합니다! Psiededelisto (토크 • 기고) 2020년 6월 13일 (UTC)응답[응답]

@Psiededelisto:편집 의뢰 감사합니다!모듈에서 귀하의 코드에 대한 몇 가지 새로운 테스트 케이스를 추가했습니다.해트노트/테스트케이스에서 몇 가지 문제가 발생했기 때문에 모듈에서 수정을 시도했습니다.모자/샌드박스수정하는 동안 코드를 이해하기 쉽다고 생각했기 때문에 _formatLink를 변경하여 명명된 인수를 사용했습니다.예를 들어 섹션의 이탤릭체를 사용하는 경우 명명된 인수를 사용하지 않으면 함수 호출은 다음과 같습니다._formatLink("Foo#Bar", nil, nil, true)명명된 인수에 의해 이것은_formatLink{link = "Foo#Bar", italicizeSection = true}즉, 모든 파라미터의 동작을 확인하기 위해 함수 정의를 확인할 필요가 없습니다.명명된 매개 변수를 사용하려면 종속 모듈을 변경해야 하지만, 내 검색 결과 종속 모듈은 모듈뿐입니다.Cat 메인 및 모듈:해트노트 리스트, 손상이 심하지 않습니다.저도 바꿨어요.italicizearticle에 대한 파라미터italicizepage 이 모듈은 아티클스페이스뿐만 아니라 모든 네임스페이스에서 사용할 수 있습니다.어떻게 생각하시는지, 그리고 제가 편집에서 놓친 것이 있으면 알려주세요.Stradivarius님^{♪ talk ♪} 2020년 6월 14일 08:03 (UTC)응답[응답]

@Stradivarius씨:당신의 변경은 대체로 긍정적인 것 같습니다만, 당신의 버전에서는 버그를 찾을 수 없었습니다.Psiededelisto (토크 • 기고)2020년 6월 14일 (UTC)응답[응답]

Done@Psiededelisto:모듈을 업데이트했습니다.새로운 변경사항 및 UDP 모듈 관련 참고:Cat 메인 및 모듈:새로운 _formatList 함수 구문을 가진 Hatnote 목록.모듈 매뉴얼도 업데이트했습니다.해트노트 및 템플릿:포맷 링크여러 가지 변경 사항에서 문제가 발견되면 알려주십시오.베스트 — Stradivarius님^{♪ talk ♪} 2020년 6월 16일 (UTC)응답[응답]

사용자 페이지는 카테고리의 대부분을 차지하고 있습니다.오류가 있는 해트노트 템플릿으로 카테고리를 사용할 수 없게 됩니다.지금은 토크 페이지만 자동으로 제외됩니다.사용자 페이지도 여기서 제외해야 합니까?- Andrybak (대화) 13:34, 2020년 7월 4일 (UTC)응답[응답]

@Andrybak:그것은 나에게 합리적인 제안인 것 같다.이 작업을 수행하기 위한 코드를 모듈에서 구현했습니다.해트노트/샌드박스(diff).다음 날쯤 아무도 반대하지 않으면 라이브로 올리겠습니다.- Stradivarius님^{♪ talk ♪} 2020년 7월 11일 (UTC)응답[응답]

@Andrybak:코드가 가동되었습니다.카테고리로부터 유저스페이스의 페이지를 천천히 필터링 하기 시작하는 것을 확인할 수 있습니다.- Stradivarius님 2020년 7월 14일 (UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

모듈의_formatLink함수는 섹션만 공급하면 불필요한 공간을 추가합니다.예:

입력	({{format linkr #Italicize}})
출력(예상)	( ital 이탤릭체)
출력(실제)	(§ 이탤릭체)

따라서 샌드박스를 메인 모듈에 복사해 주세요.먼저 동기화된 것을 확인했습니다.테스트 케이스도 추가되었습니다.이상한 이유로 이전 동작으로 되돌아가고 싶은 경우는, 다음과 같이 지정할 수 있습니다. italicizePage=true이것은 빈칸을 추가하는 부작용으로 사용됩니다.<i>...</i>. Psieledelisto (토크 • 기여) 2020년 7월 28일 23:36 (UTC)응답[응답]

@Psiededelisto: 완료* ppery*_{it has begun...} 2020년 7월 29일 00:47 (UTC)응답[응답]

@Psiededelisto:이걸 찾아주시고 고쳐주셔서 감사합니다.빈칸을 추가하는 섹션 전용 링크 있음<i>...</i> 저도 버그처럼 느껴져서 테스트 케이스를 하나 더 추가해서 샌드박스에 수정을 했어요.이것이 모듈에 추가되는 좋은 방법이라고 생각하십니까?베스트 — Stradivarius님^{♪ talk ♪} 2020년 7월 29일 13:29 (UTC)응답 [응답]

@Stradivarius씨:물론입니다. 아무리 고장이 나더라도 이전 동작을 복구할 수 있도록 직접 고친 것이 아닙니다. TP ER 구현자 중에는 그런 것에 신경을 많이 쓰는 사람도 있고, 요청을 할 때 누구를 만나게 될지 알 수 없습니다.Psiededelisto (토크 • 기고) 2020년 7월 29일 (UTC)응답[응답]

@Psiededelisto:섹션 전용 링크의 추가 초기 공간은 오랫동안 템플릿에 있었던 것 같기 때문에 그 동작에 의존하게 된 사람도 있을 수 있습니다.그러나 그러한 사람들이 실제로 존재한다면 아마도 소수일 것이라는 것은 충분히 예상 밖인 것 같다.가서 고쳐서 불평하는 사람이 있는지 보자고우리는 그 이후에 취할 다음 단계를 생각해 낼 수 있다.베스트 — Stradivarius님^{♪ talk ♪} 2020년 7월 30일 (UTC)응답[응답]

난 내 수정안을 생방송으로 올렸어.- Stradivarius님^{♪ talk ♪} 2020년 7월 30일 13:48 (UTC)응답 [응답]

일부 노트 템플릿에서 MB는 Redlink Detection을 추가하도록 요청했습니다. Redlink Detection은 추적 및 수정이 가능한 상당히 일반적인 오류이기 때문입니다.이 기능의 기본 구현을 샌드박스로 정리하여 카테고리를 추가했습니다.존재하지 않는 페이지를 대상으로 하는 해트노트 템플릿이 있는 문서입니다.이것이 괜찮아 보인다는 피드백을 받고 싶습니다.분명한 불안감은 페이지가 존재하는지 확인하는 것은 "비용이 많이 드는 작업"이기 때문에 사이트 전체에 수천 개의 "비용이 많이 드는" 작업이 발생할 수 있다는 것입니다.반면, 전체적으로는 그렇게 비싸지 않고, 대부분의 페이지에서 제한의 대부분을 차지하지 않습니다.또 다른 문제는 {{format link}}을(를) 사용하여 "false positive"를 생성할 수 있다는 것입니다.이러한 문제는 아마 몇 가지 방법으로 완화될 수 있습니다.{{Nihiltres talk edits} 21:17, 2021년 12월 11일 (UTC)응답 [응답]

솔루션이 모든 해트에 적용되는지 알 수 없으며 업데이트할 특정 템플릿 목록이 필요하지 않습니다.만약 후자라면, 최근에 제가 발견한 건{{main}}레드링크 타깃을 사용합니다.이 버전의 Riviére de la Tortue(델슨)는 레드링크 타깃을 가지고 있습니다.{{other uses}}그 템플릿은 "실장 불량" 체크가 되어 있지만, 효과가 없는 것 같습니다.구현 개발/테스트에 관심이 있거나 도움이 될 경우에 한해 언급합니다.MB 2:49, 2021년 12월 15일 (UTC)응답[응답]

이 솔루션은 기본적으로 자동 목록을 사용하는 모든 해트에 적용됩니다. 자동 목록이 사용하는 자동 형식에 체크를 추가합니다.템플릿별로 수동으로 기능을 추가해야 하는 Wikitext 기반 해트노트에는 적용되지 않습니다.이 기능은 간단합니다.Riviére de la Tortue(Delson)의 예에서는 디폴트 사용 시 Redlink만 체크하고 이 페이지는 dismarkation 페이지를 수동으로 지정하기 때문에 "잘 구현되지 않은" 체크가 실패했습니다.내 디자인은 모든 "타깃" 링크에서 레드링크를 확인합니다(텍스트 입력에서 링크를 잡을 수는 없지만 괜찮습니다).{{Nihiltres talk edits}} 2021년 12월 16일 18:15 (UTC)응답 [응답]

hatnote 템플릿에 redlink 검출을 추가하는 것은 좋은 방법이라고 생각합니다만, formatLink 함수와 결합하는 것이 좋은 방법인지 잘 모르겠습니다.{{Format link}}은(는) 해트노트와 관련이 없는 여러 템플릿에서 사용되고 있으며, 이러한 템플릿을 사용하여 해트노트 추적 카테고리를 출력하는 페이지는 혼란스러울 수 있습니다.모듈에서 별도의 기능을 만드는 것은 어떨까요?존재 여부를 확인한 후 format Link를 호출하는 Hat Note기존 해트노트모듈은 새로운 기능을 사용하기 위해 업데이트해야 하지만 각 모듈에 대해 한 줄의 수정만 해야 하며, 이로 인해 혼란을 피할 수 있습니다.- Stradivarius^{♪ talk ♪} 씨 2021년 12월 15일 05:30 (UTC)응답[응답]

문제를 다소 완화하기 위해 샌드박스 구현을 업데이트했습니다.프로토타입에서는 옵션을 전달해야 합니다.이 옵션을 전달하려면 카테고리를 카테고리 이름 문자열로 지정하거나(빈 문자열은 분류를 비활성화함), 기본값을 문자열 이외의 모든 truthy 값과 함께 사용해야 합니다.대부분의 네이티브 메서드에 대해 "true"를 지정하고(AFAICT만 hatnotes 외부에서 formatLink 사용), {{format link}}이(가) 사용하는 formatLink 메서드에 파라미터 패스스루를 추가했습니다.즉, 사용자가 redlink 시 사용할 카테고리 이름을 지정하여 명시적으로 요청하지 않는 한 현재 프로토타입이 {{format link}}에 영향을 미치지 않아야 합니다.그것은 아마도 좋은 "빠른" 솔루션일 것입니다.즉, 이 작업을 완료한 후 링크 포맷 기능을 자체 모듈(프로토타입으로 제작한 옵션인 레드링크 분류 포함)에 추출하여 모듈 내부로 호출하는 것이 가장 깔끔한 솔루션이 될 수 있습니다.Hatnote의 링크 포맷 함수는 해트노트 고유의 기능이라고 (더 안전하게) 가정할 수 있습니다.그런 일을 하고 싶지는 않지만, 그게 더 나은 장기적 해결책이 될 것 같아요.{{Nihiltres talk edits}} 2021년 12월 16일 18:15 (UTC)응답 [응답]

formatLink 추출 중

이 기능을 추출하기 위해 상당한 작업을 수행했습니다.formatLink그리고._formatLink모듈:링크 포맷은 {{format link}}이(가) 반드시 해트노트에 관계되는 것은 아니기 때문에 가장 합리적인 재구축이라고 생각됩니다.

이 모듈의 코드는 옵션을 허용하는 향상된 기능을 통합하고 있으며,formatLink또는 문자열 옵션_formatLink지정된 카테고리명으로 지정된 경우에만 Redlink 분류를 이노블로 합니다.마찬가지로 모듈:기본 formatLink 기능을 삭제하고 새 모듈을 호출하며 기본 hatnote redlink-target 카테고리 이름을 지정하도록 Hatnote/sandbox가 업데이트되었습니다.

일치시키려면 몇 개의 다른 모듈을 업데이트해야 합니다만… 이것이 설계대로 합리적인 것 같습니까?에러 검출(meh)에의 링크 포맷은 아직 결합하고 있습니다만, 실장되어 있는 경우는, 해트 노트 고유의 것이 아니고, 보다 일반적인 방법으로 행해집니다.테스트 케이스를 업데이트하기 위해 몇 가지 작업을 더 수행해야 합니다(해트노트 모듈에서 새 모듈로 마이그레이션하고 새로운 기능을 테스트하기 위해 몇 가지 추가) 문서 작성 작업도 필요하지만, 준비는 거의 완료되었으므로 추가 피드백(특히 Stradivarius 씨)을 부탁드립니다.감사합니다. {{Nihiltres talk edits}} 2021년 12월 20일(UTC) 18:50 (응답)

@니힐트:네, 저는 이것이 좋은 방향이라고 생각하며 _formatLink를 자체 모듈로 분할하는 것에 동의합니다.수고하셨습니다.모듈에서는 p.formatPages와 p.formatPageTables가 더 나을 수 있습니다.모듈보다 링크 포맷:Hatnote - 개념적으로는 Hatnote 자체보다는 링크 포맷에 가까운 것으로 보이며 Hatnote 모듈의 다른 곳에서는 사용되지 않습니다.그렇다고 해도, 옮기면 일이 늘어나기 때문에, 어느 쪽도 그다지 강하게 느껴지지 않습니다.Stradivarius^{♪ talk ♪} 씨 2021년 12월 21일 14:10 (UTC)응답[응답]

검토해주셔서 감사합니다.문서 작성과 테스트에 대한 재미없는 작업에 대한 저의 동기 부여에 큰 도움이 됩니다.해트노트 모듈에 폭넓게 통합되어 있다고 생각했던 두 가지 방법을 마침내 자세히 살펴보았습니다.첫 번째는formatPages에는 몇 가지 용도가 있기 때문에 모듈에 범용 아날로그(분류 옵션 사용 가능)를 추가했습니다.포맷 링크두 번째는formatPageTables샌드박스 이외에서는 사용되지 않기 때문에 간단하게 삭제할 수 있습니다.(대담한) 변경을 도입하는 것이 안전하다고 생각합니다만, 우선 문서나 테스트등을 입수합니다.{{Nihiltres talk edits}}19:32, 2021년 12월 21일(UTC)응답[응답]

(←)(ping MB) 완료 - 자동 서식을 사용하는 Redlink 대상이 있는 모든 해트노트가 카테고리를 가리킵니다.존재하지 않는 페이지를 대상으로 한 해트노트 템플릿이 포함된 문서는 다음과 같이 구분된 모듈을 통해 수행됩니다.포맷 링크{{Nihiltres talk edits}22:50, 2021년 12월 26일(UTC)응답[응답]

벌써 400페이지가 넘는 카테고리가 있는 것을 알 수 있기 때문에, 이것은 확실히 가치가 있습니다.검출을 아티클스페이스로만 제한할 수 있습니까?다른 네임스페이스에서는 이러한 점에 신경 쓸 필요가 없습니다.감사해요.MB 22:57, 2021년 12월 26일 (UTC)응답[응답]

실제로 이들 중 일부는 카테고리 헤더에도 표시되므로 정리할 필요가 있습니다.MB 23:04, 2021년 12월 26일 (UTC)응답[응답]

니힐트레스, 위 내용을 보셨는지 모르겠네요.많은 케이스가 USER 및 DRAFT 영역에 존재하며, 이에 대해 신경 쓸 이유가 거의 또는 전혀 없습니다.이것들은 추적 대상에서 제외될 수 있습니까?MB 04:39, 2021년 12월 31일 (UTC)응답[응답]

MB 아, 네, 두 번째 멘트는 첫 번째 멘트를 완전히 부정하는 줄 알았어요.네임스페이스 기반 필터의 초안을 작성하여 다음 업데이트 라운드에서 구현합니다.모듈 토크에서 몇 가지 기능 요청 사항이 있습니다.지금 보고 있는 링크 포맷.사용자 네임스페이스, 임시 네임스페이스 및 모든 토크 네임스페이스를 제외하려고 합니다.{{Nihiltres talk edits}} 2021년 12월 31일 05:05 (UTC)응답[응답]

니힐트레스, 처음에는 기사를 제외한 모든 것을 제외하려고 생각했어요.그런데 카테고리에는 해트노트가 사용되고 있는 것을 알 수 있었습니다.사용자, 초안, 모든 대화는 완전히 제외합니다.템플릿에서 몇 가지를 봤는데, 실제로 변환이 되어 있으면 기사에 기재되어 있습니다.문서와 카테고리 외에 추적할 "독자 대면" 네임스페이스가 있는지 확실하지 않으므로 포함 목록이 제외 목록보다 짧을 수 있습니다.물론 큰 문제는 아니지만, 할 수 있을 때 개선해야 할 부분일 뿐입니다.감사해요.MB 05:18, 2021년 12월 31일 (UTC)응답[응답]

MB 스페셜 완료:Diff/1063743122.{{Nihiltres talk edits}} 2022년 1월 4일 (UTC) 18:26 (응답)

{{format linkr}}

참고: @Nihiltres, MB 및 Mr. Stradivarius:위의 변경 사항이 {{format linkr}에서 해제되었습니다.사용자 토크 시 진단:TryKid {{ { format linkr} 。 (예, {{format linkr}}을 사용하여 {{format linkr}}에 대해 이야기하는 아이러니한 점은 알고 있습니다.)템플릿 에디터는 일반적인 템플릿/모듈 변경뿐만 아니라 노출된 API의 사용을 체계적으로 체크할 필요가 있다고 생각합니다.이것은 기사 공간을 포함한 많은 페이지를 깼다.실례가 되지 않습니다.분명히 자원봉사 프로젝트입니다.이 변경은 순조롭게 진행되지 않았고 파손은 며칠 후에 발견/수정되었습니다.Psiededelisto (토크 • 기여) 2021년 12월 27일 (UTC)응답[응답]

그건 내가 낼게.용도를 확인했지만, 검색 쿼리를 {{format linkr}}이(가) 표시되지 않게 된 Lua 고유의 것으로 변경했기 때문에 그것을 놓쳤습니다.죄송합니다.{{Nihiltres talk edits}} 2021년 12월 27일(UTC) 16:12 (응답)

@니힐트:괜찮아요, 다음 번엔 기억하시길 바라면서 알려드리는 거예요.저는 지금까지 많은 가동 중인 생산 시스템을 망가뜨렸습니다(웃음).또한 {{format linkr}}은 특별한 역할이 있다는 것을 상기시켜 주셨으면 합니다만, 기사 공간이 아닌 토크 페이지용으로 만들었습니다(Linkr 버전으로 URL 바의 섹션을 붙여넣는 것이 훨씬 편리합니다). 어느 순간 잊고 어디서나 사용하기 시작한 것 같습니다.제가 아니라 베트남어 위키피디아에 복사되었기 때문에 다른 사람들이 유용하다고 생각하는 것 같습니다만, 제가 쓰고 있는 링크가 도움이 되지 않으면 사용하지 않는 것이 좋습니다.Psiededelisto (토크 • 기고) 2021년 12월 28일 01:00 (UTC)응답[응답]

템플릿:카테고리 쌍은 두 개의 인수("선행"과 "승계")를 사용하여 해당 인수의 존재를 확인한 후 하나 또는 둘 다 존재하는 경우 해트노트를 생성하는 특수한 형태의 해트노트입니다.현재 템플릿 코드는 보기 흉하고 Lua에서 쉽게 구현할 수 있습니다.모듈로 구현했습니다.지질학적 시간이지만 좀 더 중심적인 모듈에 속해야 할 것 같아요

편집자는 템플릿에 이 모듈에 진입점을 추가하는 것에 대해 어떻게 생각하십니까?카테고리 쌍?- hike395 (대화) 07:42, 2021년 12월 16일 (UTC)응답[응답]

제안된 기능은 이 모듈에서 구현되는 것이 아니라 자체 모듈이어야 합니다.하지만 그렇지 않으면 Luafication에 적합한 타깃으로 생각되며 필요한 코드는 대부분 이미 작성되어 있습니다.디자인을 조금 수정하고 싶습니다(번역을 쉽게 할 수 있는 정적 형식 문자열이 많고 연결 기반 형식이 적음). 하지만 대부분 제 스타일입니다.{{Nihiltres talk edits}} 2021년 12월 16일 18:23 (UTC)응답 [응답]

세컨드 - 예를 들어 별도의 모듈을 사용합니다.모듈:Cat Main, 즉 모듈:범주 쌍은 이 패턴을 따릅니다.- Stradivarius씨^{♪ talk ♪} 00:33, 2021년 12월 17일 (UTC)응답[응답]

감사합니다! 자체 모듈로 구현하겠습니다.- hike395 (토크) 05:13, 2021년 12월 17일 (UTC)응답[응답]