모듈 토크:보호 배너

Module talk

완전히 보호된 Wikipedia 템플릿의 분류 오류

확장된 확인 템플릿이 현재 범주로 잘못 분류되어 있습니다.Wikipedia는 완전히 보호된 템플릿입니다.해당 카테고리에는 "기술상의 이유로 이 카테고리에도 잘못 확인된 확장된 보호된 템플릿이 포함되어 있습니다."라는 주기가 있지만 해당 주석이나 편집 요약은 이 "기술적 설명"을 나타내지 않습니다.이 모듈이 그 카테고리를 채우는 역할을 하고 있다고 생각합니다.이 이유는 설명할 수 있습니까?(ping @Mr. Stradivarius, 혹시 모르시겠지만) DelaylayingReader (대화) 2020년 8월 28일 (UTC)응답[응답]

@ProcrastinationReader:모듈을 고쳐야 할 것 같은데, 아직 정확한 수리가 필요한지는 모르겠어요.잘못 분류된 페이지의 예가 있습니까?Stradivarius씨 00:56, 2020년 8월 29일 (UTC)응답[응답]
모듈은 카테고리를 채우는 역할을 합니다.특히 카테고리 리스트는 모듈에 있습니다.보호 배너/구성, 3분의 2 정도 내려갑니다.Stradivarius씨♪ talk ♪ 00:57, 2020년 8월 29일 (UTC)응답[응답]
스트라디바리우스 씨, 예:템플릿:저스티스 리그 캐릭터, 템플릿:1960년대 팔레스타인 무장 공격 템플릿:G/topics 지연 리더 (토크) 2020년 8월 29일 01:29 (UTC)응답[응답]
설정내의 코멘트를 30초간 읽어 보면, 다음의 카테고리가 없는 것이 문제일 가능성이 있습니다.Wikipedia에서 확장된 보호된 템플릿을 확인했기 때문에 완전히 보호된 템플릿으로 가는 사다리를 마련하고 있습니까?완전하고 완벽한 추측이지만, 아마 틀렸을지도 몰라지연독자 (대화) 2020년 8월 29일 01:32 (UTC)응답[응답]
음, Mdaniels가 몇 달 전에 비슷한 일을 하고 있었던 것 같아요.설정 샌드박스를 조금 조정했습니다만, 이 방법이 효과가 있을까요?하지만 어떻게 테스트해야 할지 잘 모르겠어요.템플릿에서 버전 변경을 시도했습니다.1960년대 팔레스타인 무장세력은 샌드박스 v에 공격을 가했지만 오버라이드하지 않았다(템플릿 네임스페이스는 잠금을 삽입하기 위해 일종의 자동검출을 하기 때문에 수동 네임스페이스보다 우선한다).그래서 궁금한데, {{Pp-extended}}이(가) 단순히 {Pp}을(를) 사용하는 것이 아니라 {Pp-extended}}이(가) 왜 존재하는지, 적어도 소스상으로는 전자와 같은 기능을 하는 것 같습니다.지연독자 (대화) 2020년 8월 29일 01:47 (UTC)응답[응답]
@ProcrastinationReader:편집이 제대로 된 것 같습니다.확장된 보호 템플릿이 기본 케이스로 넘어가지 않도록 테이블을 편집하는 것이 중요합니다.가장 좋은 테스트 방법은 모듈에 몇 가지 새로운 테스트를 추가하는 것입니다.보호 배너/구성/테스트 케이스안타깝게도 이전 에디터가 테스트 케이스를 업데이트하지 않고 설정을 편집했기 때문에 기존 테스트 케이스도 수정해야 합니다.라이브 테스트의 경우 사용자:Jackmcbarn/advanced templatesandbox.js: 메인 모듈을 업데이트하지 않고 라이브 페이지에서 샌드박스를 테스트하기 위해 사용할 수 있습니다.Stradivarius♪ talk ♪ 씨 2020년 8월 29일 01:57 (UTC)응답[응답]
그 대본은 편리해요, 사실 조금 전에 C&C에서 추천한 것 같은데 까먹었어요.업데이트를 동기화하여 카테고리를 채우고 있는 것 같습니다(너무 느리게, 소프트웨어가 분류를 갱신하는 타이밍을 어떻게 결정하는지 잘 알 수 없습니다).또한 대부분의 테스트 케이스도 수정했습니다.참, 아주 잘 문서화된 모듈입니다.내가 접한 대부분의 유료 코드는 훨씬 더 나쁜 문서를 가지고 있다.사실 당신이 전문적으로 개발자가 아니라는 게 좀 놀랍네요.지연독자 (대화) 2020년 8월 29일 (UTC)응답[응답]
@ProcrastinationReader:모듈 업데이트 및 테스트 케이스 수정 감사합니다!대단히 감사합니다.카테고리 이름에 두 번째 하이픈이 필요하다고 생각합니다.단, "Wikipedia extended-confirmed protected templates"는 "extended-confirmed p"로 변환됩니다.'로테이션'이 우리가 원하는 것이라고 생각합니다.- Stradivarius씨♪ talk ♪ 2020년 8월 30일 14:08 (UTC)응답[응답]
스트라디바리우스 씨, 거스름돈은 괜찮습니다.그런데 완전히 보호된 페이지를 찾다가 카테고리를 발견했습니다.Wikipedia는 완전히 보호된 페이지입니다.이 카테고리의 모든 기사는 완전히 보호되지 않아 약간 혼란스러웠습니다.그리고 그들이 리다이렉트라는 걸 깨달았어요.리다이렉트를 카테고리로 분류하는 경향이 있습니다.1,375명의 멤버가 있는 완전 보호된 리다이렉트왜 553명밖에 없는 이전 카테고리로 분류되지 않았는지 아십니까?이동 보호가 되어 있기 때문일 수도 있습니다(확인한 몇 가지 예도 카테고리에 있습니다).Wikipedia에서 무제한으로 보호된 페이지)를 참조할 수 있습니다.단, 이러한 페이지가 범용 카테고리로 분류되지 않도록 하기 위해서는 추가 설정 케이스가 필요합니다.내 추측이 맞다면 설정 케이스를 편집이 아닌 모두로 변경하시겠습니까?아니면 완전히 보호된 이동에 대해 별도의 카테고리를 작성하시겠습니까?
제 측면 질문은 모듈이 왜 여러 카테고리에 이러한 항목을 추가하느냐는 것입니다.그게 좋은 행동인 건 알지만, 그 뒤에 있는 코드 논리가 뭐죠?각 보호 유형에 대한 카테고리를 개별적으로 찾고 있습니까(예: 카테고리에 대한 편집/이동 계층을 통해 별도로 배치됨)?지연독자 (대화) 2020년 8월 30일 14:18 (UTC)응답[응답]
좀 더 자세히 살펴보니 엉망진창인 것 같습니다(이 모듈에서는 그렇지 않습니다).이 모듈은 {{R fully protected}와 같은 리다이렉트템플릿에 의해 추가된 리다이렉트카테고리를 담당하지 않는 것 같습니다.따라서 잠금 태그가 부착되지 않은 리다이렉트 및 잠금 태그만 부착되어 있는 기타 기사도 있으므로 완전히 보호되고 있습니다.템플릿과 자물쇠가 둘 다 있는 태그 부착.이렇게 하면 추적 카테고리가 일관되지 않게 엉망이 되고 결과적으로 조금 쓸모 없게 됩니다.이걸 치우는 최선의 방법이 뭔지 모르겠어?Lua를 사용하여 리다이렉트를 확인할 수 있기 때문에 언제든지 추가할 수 있지만 퍼포먼스에 미치는 영향은 알 수 없습니다.내가 링크한 페이지와 같은 페이지를 수정하려면 봇도 필요할 거야?지연독자 (대화) 2020년 8월 30일 14:30 (UTC)응답[응답]
@ProcrastinationReader:하이픈을 추가하도록 변경했으므로 페이지가 새 카테고리로 천천히 이동하기 시작할 것입니다.이전 질문에 답변하기 위해 작업 대기열에 의해 업데이트가 이루어지며, 템플릿 편집으로 인한 범주 변경에 대해 매우 느릴 수 있습니다.몇 달이나 걸리는 걸 본 적이 있어요여러 보호 카테고리의 경우 이 모듈에서는 #invoke마다 하나의 보호 카테고리만 추가합니다.단, 페이지에는 여러 보호 템플릿이 있을 수 있습니다.또한 보호 카테고리를 추가하는 템플릿도 있습니다.이 문제를 우아하게 해결하려면 관련된 모든 템플릿에서 호출할 수 있는 보호 범주를 생성하기 위한 별도의 모듈을 만들어야 합니다.- Stradivarius님♪ talk ♪, 2020년 8월 30일 (UTC)응답[응답]
스트라디바리우스 씨, 음, 이 경우 (읽기 모드로) 잠금을 추가하는 것은 무엇입니까?그리고 왜 저것은 여기에 자물쇠를 추가하지 않는거죠?이거 나랑 꽤 비슷해 보여?딜레이팅 리더 (대화)2020년 8월 30일 (UTC)응답[응답]
@ProcrastinationReader:템플릿:편집 보호 수준에 따라 Template:pp-protected를 호출하는 Rcat 쉘.- Stradivarius님♪ talk ♪ 2020년 8월 30일 (UTC)응답[응답]
스트라디바리우스 씨, 알겠습니다.이걸 치우는 가장 쉬운 방법은{{pp-protected small=yes}}{{Rcat shell}}부터요?그런 다음 적절한 카테고리를 추가하는 {{R fully protected}}만 호출합니다.유일한 문제는 잠금이 부족하다는 것입니다만, 다음과 같이 {{R fully protected}에 추가하여 해결할 수 있습니다.{{pp small=yes category=no}}. 미루는 독자 (대화)2020년 8월 30일 (UTC)응답[응답]
아니, 지우지 마.그러면 특정 프로토 레벨에만 적용되는 전용 템플릿을 사용하지 않기 위해 지난 몇 년 동안 저와 다른 사람들(Paine Elsworth 등)이 수행한 작업이 취소됩니다.그래서 한 페이지에{{rcat shell}}또한 다른 보호 템플릿도 사용할 수 없습니다.{{r protected}}또는 이와 유사합니다.에 관한 것{{pp-protected}}프로트 레벨을 자동 검출해, 페이지를 세미프로트에서 풀프로트로 올릴 때에 조정할 필요가 없습니다."잘못된" 보호 범주에서 페이지(리다이렉트 또는 기타)를 발견한 경우 먼저 WP를 적용합니다.특수한 절차로 해결되는지 확인합니다. --Redrose64 🌹 (대화) 09:28, 2020년 8월 31일 (UTC)응답[응답]
Redrose64, 템플릿에 내재된 버그로 인해 잘못된 카테고리에 속합니다.Null 편집으로는 문제가 해결되지 않습니다(또한 완전히 보호된 페이지를 Null로 편집할 수 없습니다).위의 설명을 참조하십시오.내가 제안한 변화가 너의 노력을 저버려서는 안 된다.{{r protected}}는 다른 보호 수준도 고려하기 때문에, 이 경우 {{pp}}을(를) 거기로 옮겨도 부정적인 영향은 없을 것으로 생각합니다.내가 보지 못한 게 보이면 자세히 설명해 주세요.확실히 하자면, 완전히 보호된 케이스({r protected}}를 호출해야 하므로 누락이 발생하지 않습니다)에 대해서만 이동을 제안합니다.어디가 잘못됐는지 알 수 있는 시나리오는 전혀 없어요?예를 들어 샌드박스를 참조하십시오.지연독자 (대화) 2020년 8월 31일 (UTC)응답[응답]
PR님, 저희가 몇 년 전부터 알아채고 고치려고 애쓰고 있는 오래된 문제에 휘말리신 것 같습니다.이 토크 페이지만 해도 적어도 2016년으로 거슬러 올라가면 {{Redirect category shell}}이(가) {{This is redirect}}템플릿이었던 시기입니다.이 문제는 Extended-Confirmed-Protected뿐만 아니라 템플릿으로 보호되는 {{-r} 리다이렉트 등에도 적용됩니다.이 문제에는 여러 층이 있는 것 같습니다.Lua 전문가뿐만 아니라 매우 유능한 관리자 및 템플릿 편집자들도 이 문제를 수정하려고 시도했다가 나중에 발생할 수 있는 더 심각한 문제에 대처하기 위해 미루고 있습니다.그것은 정말 어려운 문제이기 때문에 나는 곧 해결책을 찾을 수 있을 것이라고 기대하지 않을 것이다.하지만, 저 자신도 그것이 결국 잘 해결되기를 바랍니다.P.I. 엘스워트드.put'r there2020년 9월 1일 (UTC) 12:01 (응답)

페인 엘스워스, 내가 제안한 해결책에 결함이 있나요?2개의 템플릿 중 하나를 사용하여 완전히 보호되는 리다이렉트(다른 템플릿은 현재와 같이 파손되지 않음)의 틈새 케이스에만 영향을 줄 수 있습니다.그러나 이 경우 문제의 원인이 될 수 없기 때문에 솔루션이 없는 것보다는 낫다고 생각합니다.적어도 완전히 보호되는 카테고리는 도움이 되지 않습니다.또는 다른 목적.셸은 반드시 {{r protected}}을(를) 호출하기 때문에 쉽게 해결할 수 있다고 생각합니다.지연독자 (대화) 12:08, 2020년 9월 1일 (UTC)응답[응답]

셸에서 {{pp-protected} 템플릿을 삭제하려고 하는 것 같습니다.그 때문에, 다음의 변경이 필요하게 됩니다.
{{#switch:{PROTECTIONLEVEL:edit} sysop=sysop-protected small=yes}{R protected embedditor=small=yes}{R template protected embed =small=yes}{R 템플릿 보호 extended embed smbed smbed smbed smbed smbed =y }확정확정확정=small=y smbed smbed small=y}{{
대상:
{{#switch: {{PROTECTIONLEVEL:edit}} sysop=sysop-protected embed=yes} templateed editor=small=yes} {R template protected small=yes} extended confirmed=smbed =smbed } {R-prot} imbed =s} {R} {{= {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{ {{
그것이 맞습니까?그리고 잃어버린 잠금 아이콘을 되찾기 위해 {{pp-protected} 템플릿을 {{R fully protected} rcat 템플릿에 삽입할 것을 제안하십니까?정확히 어디에 삽입하시겠습니까? P.I. Elsworted.put'r there12:38, 2020년 9월 1일 (UTC)응답[응답]
페인 엘스워스 말이 맞아요자세한 내용은 템플릿을 참조하십시오.완전히 보호됨/샌드박스두 샌드박스 모두 제가 제안하는 변경 사항으로 업데이트되었습니다.
(두 번째 옵션은 두 템플릿을 그대로 유지하되 셸에 카테고리=no를 추가하는 것입니다.이는 분류 문제를 해결하는 데에도 동일하게 작동하지만, 현재 완전히 보호되는 방향 수정의 절반은 셸을 사용하지 않기 때문에 잠금이 없습니다.위의 접근방식이 더 좋다고 생각합니다.따라서, 모든 케이스의 록을 가지고 있으며, 카테고리 분류도 고정하고 있습니다).지연독자 (대화) 19:43, 2020년 9월 1일 (UTC)응답[응답]
PR님처럼 완전히 보호된 리디렉션에서 변경 사항을 테스트할 수 없습니다. 그러나 템플릿으로 보호된 리디렉션에서 변경 사항을 테스트할 수 있으며 범주에서 제거되었습니다.{{Redirect 카테고리/sandbox}} 사용 시 위키피디아 템플릿으로 보호되는 템플릿.이것은 당신의 변화가 당신이 원하는 것을 이룰 것이라고 생각하게 합니다.한 가지 문제는 변경으로 인해 템플릿으로 보호된 리다이렉트가 카테고리에서 삭제되지 않았다는 것입니다.위키피디아는 페이지를 완벽하게 보호하며, 그것이 우리의 주요 이슈 중 하나입니다.따라서 귀사의 솔루션은 적절한 부분 수정(관리자에 의한 확인 테스트 필요)일 수 있습니다.단, 이 토크 페이지에서 언급한 바와 같이 분류가 올바르지 않거나 부적절한 다른 중요한 문제는 해결하지 않습니다.P.I. 엘스워트드.put'r there2020년 9월 2일 (UTC) 10:18 (응답)
테스트해줘서 고마워, 페인 엘스워스TE 리다이렉트에 적용되는 것과 동일한 방법으로 수정이 이루어지지 않기 때문에 유감스럽게도 이 문제는 이러한 변경으로는 해결되지 않습니다.모듈 내의 새로운 규칙과 템플릿의 수정이 필요하다고 생각합니다만, TE 리다이렉트의 경우는 자세히 조사하지 않았기 때문에 완전히 보호된 리다이렉트 케이스에 대해서만 변경을 제안합니다.나중에 다른 사건도 조사할 수 있을 겁니다완전히 보호받고 있는 고양이가 말도 안 되는 소리들로 오염되지 않는다면 다른 사람들의 문제도 더 분명해져야 한다.
위에서 제시한 템플릿과 상자 스크립트를 사용하여 Alissa(완전 보호된 리다이렉트)에서 변경 내용을 테스트했는데 이 리다이렉트가 올바르게 분류됩니다.라이브 리다이렉트 상에서 샌드박스로 변경하여 테스트를 진행하려는 관리자가 있다면 좋습니다.그렇지 않으면 기술적인 세부 사항에 대한 이의가 없으면 며칠 안에 비교적 간단한 변경을 할 수 있는 충분한 증거가 있다고 생각합니다.지연독자(대화) 2020년 9월 2일 (UTC) 11:38 (응답]
천만에요, 미루는 독자님!네, 이 작업을 수행한 관리자가 샌드박스 코드를 사용하여 FP 리다이렉트를 테스트하면 매우 도움이 됩니다.또 하나 궁금한 게 있는데, 만약 이 문제를 해결하는 대신{{pp small=yes category=no}}{{R fully protected} rcat에서, 만약 우리가 단지 그 rcat을 추가하면 무엇이 달라집니까? category=no 파라미터는 기존 {{pp-protected} 템플릿(물론 템플릿 {{pp})으로 리다이렉트됩니다.그럼 같은 일을 할 수 있을까요?아니면 결과가 달라질 것 같습니까?P.I. Elsworted.put'r there12:14, 2020년 9월 2일 (UTC)응답[응답]
Paine Ellsworth는 분류 측면에서 정확히 같은 결과가 될 것이다.그러나 완전히 보호된 많은 리디렉션에서는 셸을 사용하지 않고 대신 {{R 완전 보호됨}만 사용합니다.따라서 오른쪽 상단에 잠금 아이콘이 없습니다.이러한 경우에도 잠금을 추가하는 것으로, 이 「오류」를 수정할 수 있다고 생각합니다.또, 그 록이 거기에 있을 필요가 있다고 생각하기 때문에, 당초는 이것이 좋은 어프로치라고 생각했습니다.저보다 오랜 기간 동안 귀하와 다른 분들이 이 문제를 다루어 왔기 때문에 이 문제에 대한 귀하의 의견을 듣고 싶습니다.지연독자 (대화) 12:33, 2020년 9월 2일 (UTC)응답[응답]
임시 솔루션으로서 pp 템플릿을 완전 보호 rcat에 추가하는 것을 서포트합니다.또, category=no셸 내의 모든 보호 템플릿에 대해 셸에 대한 매개 변수를 지정합니다.셸 없이 사용할 경우 리다이렉트 페이지 상단에 잠금을 추가하지 않기 때문에 pp 템플릿을 {{R template-protected}, {{R extended-protected} 및 {{R semi-protected}}에도 추가할 수 있습니다.
장기적으로는 봇이 모든 보호된 리다이렉트를 검색하여 보호 Rcat을 rcat 쉘로 대체하는 것이 더 나은 해결책이 될 수 있습니다.단, 셸 사용을 정당화하기 위해 다른 적절한 Rcat도 추가하지 않으면 일부 편집자가 불만을 제기할 수 있습니다.그리고 그것은 봇에 의해 촉진될 수 없었다.그것은 수동으로 행해져야 하며, 그것을 달성하려면 Wikignomes의 군대가 필요하다.< 한숨> P.I. 엘스위트.put'r there2020년 9월 2일 (UTC) 13:29 (응답)
저도 기회가 되면 그 템플릿에 대해 조사해 보고 악영향은 없는지 확인하겠습니다.이 문제의 모든 컴포넌트에 대처하기 위해서는 더 나은 솔루션이 필요하다는 데 동의합니다.나는 위에서 봇에 대한 아이디어를 제기했다.문제는 둘 다 봇을 조작할 수 없다는 것입니다(완전 보호된 리다이렉트를 편집하려면 adminbot이 필요합니다).이 분야에 대한 경험과 관심을 가지고 있는 현역 관리자는 많지 않기 때문에 RfA를 투입하여 운용하고 싶지 않은 한 봇 포인트는 의미가 없다고 생각합니다.WikiGnomes(논리적으로 가능하더라도)는 같은 이유로 도움이 되지 않습니다.완전 보호된 편집 요청을 처리하는 데 시간이 오래 걸립니다(또한 이러한 요청을 적극적으로 처리하는 관리자는 1~2명뿐입니다).그 중 1000개가 끝날 것 같지는 않다.가능하더라도 리다이렉트당 소요시간(제안자 시간+관리 검토자 시간)의 2배에 달합니다.딜레이팅 리더 (토크)2020년 9월 2일 (UTC)응답[응답]

이동 보호

스트라디바리우스 씨, 보호된 페이지를 비시스템 수준으로 옮기는 것에 대해 어떻게 해야 할지 생각해 보셨습니까?현재 체인은 Category(카테고리)로 기본 설정되어 있습니다.Wikipedia는 완전히 보호된 페이지입니다.불합격인 테스트 케이스를 보고 Special을 만들었습니다.Diff/976938143입니다만, 실제로는 잘못된 것 같습니다.이동 보호된 TE를 TE로 분류하는 것은 의미가 없습니다.sysop 이동 보호 카테고리가 있습니다.['all template all sysop move'] = 'Wikipedia move-protected templates'하지만 이동 보호가 덜 된 경우, "Wikipedia template-Editor 이동 보호 템플릿"을 사용하는 것은 다소 어리석은 것처럼 보입니다.따라서 여기서는 어떤 솔루션이 최선인지 잘 모르겠습니다.지연독자(대화) 2020년 9월 6일 19:11 (UTC)응답[응답]

이동 보호를 위해 별도의 카테고리 트리를 도입하는 것은 어떻습니까?Wikipedia에서:이동 보호가 명확하지 않습니다. 다음을 제외하고 이동 보호 레벨은 몇 개입니까?완전히 이동 보호된 페이지입니다.기타 관련 비트:
  • 완전 편집으로 보호된 페이지도 암묵적으로 이동 보호됩니다.
  • 모든 파일은 암묵적으로 이동 보호되며 파일 이동자와 관리자만 파일을 이동할 수 있습니다.
- Andrybak (대화) 21:38, 2020년 9월 6일 (UTC)응답[응답]
  • 이론적으로는 모든 레벨로 이동할 수 있지만 대부분의 경우 편집 보호와 일치하지 않는 비 Sysop 이동 보호는 매우 드문 시나리오입니다.일부 메인스페이스 페이지(보통 ECP 이동 시)에서는 다음과 같은 템플릿이 몇 개 있습니다(edit=move, move=).TE) 가이드라인이 아닌 IAR 조치라고 생각합니다만, 그래도 합리적인 보호입니다.이동 카테고리 트리는 하나의 아이디어이며, 적어도 모듈에서는 구현하기가 그리 어렵지 않습니다.두 번 확인해야 할 템플릿도 산재되어 있습니다.이렇게 하면 다음과 같은 카테고리에 주의해 주십시오.Wikipedia의 이동 보호 템플릿은 아마도 어린 고양이만을 포함하는 고양이여야 합니다. 따라서 우리는 그로 인해 문제가 되는 봇이 없도록 해야 합니다.지연독자 (대화) 22:02, 2020년 9월 6일 (UTC)응답[응답]
(편집 충돌)미루는 독자:또한 Redrose64, Martin, Anonie⚔, wbm1058, xaosflux 및 Jackmcbarn의 의견을 듣고 싶습니다."깨기 어려운 너트"로서 얻을 수 있는 모든 도움이 필요합니다.P.I. Elsworted.put'r there21:48, 2020년 9월 6일 (UTC)응답
@Andrybak:이동 보호는 편집, 업로드 및 생성 보호와 정확히 동일한 5가지 수준(없음, 반, EC, 템플릿 및 전체)이 있습니다.그러나 IP 및 확인되지 않은 편집기는 페이지를 이동할 수 없으므로 이동 보호가 없는 페이지는 이동에 대해 사실상 반보호됩니다.이동에 대해 명시적으로 반프로토이지만 편집 보호가 없는 페이지는 거의 없습니다.이러한 페이지는 보통 실수이며 발견 시 깔끔함을 위해 이동 보호가 없는 것으로 축소되는 경우가 많습니다.--Redrose64 🌹 (talk) 11:10, 2020 (UTC)

사용자 공간 스크립트

우리는 고양이 오염이 심해서 누군가가 사용자 공간 스크립트를 추가하고// {{pp-template}}또는 css/js 파일에 저장하여 골드 잠금 및 sysop 보호 분류(예: 사용자:GoldenRing/common.js, 사용자:BeywheelzLetItRip/common.css, 사용자:AHollender(WMF)/샌드박스/2019-20 코로나 바이러스 대유행 데이터/2019-20 코로나 바이러스 대유행 데이터/styles.css 등IAdmin이 이 항목을 지속적으로 삭제하지 않고 사용자 공간에 .js/.css 파일을 표시하거나 분류(기본적으로 건너뛰기)하지 않는 것이 좋습니다(모두 IAdmin으로 보호됩니다).딜레이팅 리더 (토크)2020년 9월 6일 (UTC)응답[응답]

보고 싶은 사람이 있으면 샌드박스에서 해.지연독자 (대화) 22:38, 2020년 9월 6일 (UTC)응답[응답]
코드를 살펴봤습니다.기본적으로 보기 좋습니다.기여해 주셔서 감사합니다.:) 몇 가지 변경 사항이 있습니다.
  • 코드를 삽입하는 대신Protected:isProtected()직접 넣겠습니다.Protection:makeCategoryLinks()또는 더 나은 방법으로 전용으로Protection:shouldBeCategorized()make Category Links에서 호출합니다.사용자의 .js 페이지나 .css 페이지가 효과적으로 보호되고 있지 않다고 하는 것은 조금 혼란스럽고, 코드를 이동하면 의도를 보다 명확하게 하고 향후 버그를 회피할 수 있다고 생각합니다.
  • 모듈의 몇 가지 테스트 케이스와 관련될 수 있습니다.보호 배너/테스트 케이스
베스트 — Stradivarius님♪ talk ♪ 2020년 9월 7일 (UTC)응답[응답]
스트라디바리우스 씨, 리뷰해 주셔서 감사합니다!Re Bullet 1: 나는 그것을 불쑥 집어넣었다.:isProtected()또한 잠금 표시를 중지하고 분류를 중지해야 합니다.왜냐하면 이러한 종류의 파일에 대해 금색 sysop 잠금을 표시하는 것은 약간 오해의 소지가 있어 바람직하지 않다고 생각했기 때문입니다.잘못된 카테고리에 넣어서 //{pp-template}을(를) 제거하는 것도 좋은 생각인 것 같았다.모든 포인트를 취득하는 가장 쉬운 방법은 :isProtected()를 편집하는 것입니다.물론, 이러한 수정 자체가 바람직하지 않은지에 대한 생각은 열려 있습니다.지연독자 (대화) 2020년 9월 7일 16:11 (UTC)응답 [응답]
@ProcrastinationReader:알겠습니다. 자물쇠 아이콘도 눌러야 한다면 다음 사항에 동의합니다.:isProtected() 코드를 추가하기에 매우 편리한 장소입니다.문제는 이름 짓기 중 하나일 뿐이고, 샌드박스에서 해결하려고 했습니다.그러나 "템플릿은 보호 카테고리와 배너/패드락 아이콘을 출력해야 한다"는 식의 좋은 이름이 떠오르지 않아 에일리어스를 만들어 속였습니다.아마 더 좋은 방법이 있을 거야또, 꽤 오랫동안 고장난 것 같은 테스트 케이스를 수리했습니다.Stradivarius♪ talk ♪ 씨 2020년 9월 8일 14:24 (UTC)응답[응답]
스트라디바리우스 씨, 잘 어울리는데요!지연독자 (대화) 2020년 9월 9일 19:27 (UTC)응답[응답]
스트라디바리우스 씨, 이게 생방송으로 합류하는 게 좋은 건가요?지연독자(대화) 2020년 9월 15일 19:08 (UTC)응답[응답]
@ProcrastinationReader:아직 - 몇 가지 테스트 케이스가 누락되어 있으며, 사용자 JS/CSS 코드가 커버해야 하는 에지 케이스가 있습니다(즉, 서브 페이지인 경우 사용자 페이지에는 JS/CSS 콘텐츠 유형만 있습니다).User:Foo.css Wikitext 페이지입니다).Stradivarius♪ talk ♪ 씨 00:20, 2020년 9월 16일 (UTC)응답[응답]
재밌는.기술적으로는 수동으로 변경했을 경우, 이러한 페이지도 CSS가 될 수 있습니다.모든 것을 체크하는 가장 좋은 방법은 content Model을 사용하는 것이라고 생각합니다만, 「아마도 비싼 기능」입니다.페이지 제목 체크는 케이스의 99.9%를 처리할 수 있습니다.지연독자 (대화) 09:54, 2020년 9월 16일 (UTC)응답[응답]
콘텐츠 모델을 사용하는 것은 문제가 되지 않을 것입니다. 고가의 함수 호출은 1회뿐이기 때문입니다.그리고 그 결과는 페이지당 캐시되기 때문에 한 페이지에 # 호출이 여러 개 있어도 고가의 함수 호출은 1개뿐일 것입니다.- Stradivarius♪ talk ♪ 씨 2020년 9월 19일 04:19 (UTC)응답[응답]
또, 문서를 확인해 보면, 현재의 페이지의 컨텐츠 모델을 취득하는 것은, 고액의 함수 수에 포함되지 않는 것 같기 때문에, 실제로는 효과가 없습니다.- Stradivarius님♪ talk ♪ 7:18, 2020년 9월 19일 (UTC)응답[응답]
방금 코드를 라이브로 올렸습니다.무슨 문제가 있으면 알려주세요.- Stradivarius님♪ talk ♪ 2020년 9월 19일 (UTC)응답[응답]
스트라디바리우스 씨, 지금 좋아 보이네요궁금한 게 하나 있어요.카테고리가 콘텐츠로 바로 업데이트되지 않는 것은 알지만 페이지의 force recursive link update를 사용하여 삭제하면 즉시 업데이트되는 것으로 알고 있습니다.몇 벌 입어봤지만 카테고리에서 사라지지 않는다:위키피디아는 어떤 이유로든 페이지를 완벽하게 보호한다.지연독자 (대화) 2020년 9월 19일 (UTC)응답[응답]
몇 달 동안, 아니 더 이상 작동하지 않을 수도 있습니다. Wikipedia를 참조하십시오.Village pump ( technical ) / Archive 181 # API에 POST를 전송하여 삭제. --Redrose64 🌹 ( talk ) 2020년 9월 19일 (UTC)응답[응답]

서브 카테고리를 리다이렉트

카테고리:완전 보호된 리다이렉트는 서브카테고리가 없는 1,500명의 멤버가 있기 때문에 유지 보수에는 다소 도움이 되지 않습니다.BLP 대체명의 리다이렉트, 공공 기물 파손으로 인한 리다이렉트, 프로젝트 리다이렉트 선제 보호 등 분할하는 것이 이상적입니다.위의 Module_talk에서 간략히 설명했습니다.Protection_banner#Categorization_of_protected_redirects는 Stradivarius가 3가지 옵션을 제시했는데, 이 옵션이 가장 좋다고 생각합니다.이 모듈로 쉽게 할 수 있을 것 같아요.패키지가 리다이렉트용(아마도 가장 쉬운 옵션)인 경우 isRedirect의 제목 체크를 추가하여 여러 개의 래퍼를 작성하고 지정된 경고를 회피할 수 있습니다.이것들은 이유 키를 사용합니다.또한 네임스페이스별 옵션을 열어두지만 일반 배너 데이터를 사용할 수 없습니다(cat의 이유로 -redirect 서픽스를 붙이지만 잠금을 위해 부모로부터 데이터를 가져와 이를 회피할 수 있습니다).알고리즘에는 리다이렉트 키를 만드는 옵션 3도 있습니다만, 그것은 조금의 작업일지도 모릅니다(S씨나 잭이 가장 잘 알고 있을 것입니다).지연독자 (대화) 2020년 9월 7일 (UTC)응답[응답]

갱신하다

보호 범주 '문제'의 세탁 목록을 만들고 자유롭게 추가/변경하십시오.거기서 해결책을 찾을 수 있을 것 같아요.페인 엘스워스가 관심 있나?Stradivarius 씨가 리다이렉트 검출을 보호 카테고리 알고리즘에 대한 완전한 키 또는 리다이렉트 처리를 위한 새로운 모듈로 제안했다는 것을 알고 있습니다.나는 또한 접미사를 붙일 생각을 가지고 있었다 - 그 이유로 리다이렉트.알고리즘에 추가하는 것이 최선이라고 생각합니다.이 문제는 리다이렉트 이외의 모듈로 중복되어 있기 때문에 거의 중복되는 모듈보다 쉽다고 생각합니다.다만, 손실을 줄이고, 주로 보호 수준과 기간(indef/temp)에 근거해 분류하는 것에 초점을 맞추고, 그것들로부터 유용한 것을 얻고 싶다면 Petscan을 제안하는 것도 좋다고 생각합니다.예를 들어 DS가 아닌 확장된 확인된 보호를 확인하려면 토크 페이지에서 "ArbCom 아랍-이스라엘 시행" + [...]의 "템플릿 없음"을 사용할 수 있습니다.딜레이팅 리더 (대화)2020년 9월 26일 (UTC)응답[응답]

두 경우 모두 몇 가지 문제가 있습니다.

  • 카테고리:Wikipedia 이동 보호 페이지는 관리자가 아닌 이동 보호 기능을 처리할 수 있어야 합니다(현재는 완전히 보호되는 페이지로 이동합니다).그러나 모듈을 실행할 때마다 분류가 한 번만 이루어지기 때문에 이를 원활하게 작동하려면 카테고리 트리 구조를 완전히 변경해야 합니다(표준 보호 기능 등).또는 모든 것을 보호 수준별로 하나의 이동 보호 카테고리로 정리하고(네임스페이스 항목을 삭제) 네임스페이스 분류를 위해 Petscan을 제안할 수 있습니다(가장 쉬운 옵션일까요?).
  • 카테고리:위키피디아에서 보호하는 살아있는 사람들의 전기들은 효과적이지 않고, 따라서 그것(및 그 하위 범주)은 거의 비어있다.관리자는 {{pp-blp}을(를) 거의 사용하지 않습니다. Twinkle은 {{pp-30-500}을(를) 추가합니다. 예를 들어, 보호 이유로는 보통 "생인 전기 정책 위반"을 포함하지만 항상 그렇지는 않습니다.여기에서는 봇이 할 수 있는 일이 몇 가지 있습니다만, Petscan도 같은 용도로 사용할 수 있기 때문에, {{pp-blp}}를 폐기하고 보호 레벨에 따라 분류하는 것만으로 끝냅니까?적어도 준보호용으로 사용되는 것 같습니다만, 카테고리등의 다른 고양이에는 몇개의 반미가 으깨져 있는지 궁금하네요.Wikipedia의 반보호 페이지(많은 페이지, 한 눈에 보기)카테고리에 관한 유사한 문제:Wikipedia 확장 확인 보호된 페이지입니다.
미루는 독자에게: 네, 저는 이 모든 것을 매우 흥미롭고 주의 깊게 보고 있습니다.많은 부분이 제 급여 수준과 켄을 넘는 것 같지만, 저는 이런 것들에 대해 저보다 더 잘 아는 사람들에 의해 이 일이 해결되기를 바라고 있습니다.P.I. Ellsworth ed. 15:57, 2020년 9월 27일 (UTC)응답[응답]

고양이 전용

@Stradivarius씨:"catonly"라는 파라미터를 추가한 샌드박스를 변경했습니다."예"일 경우 배너/패드록은 숨겨지고 카테고리만 표시됩니다.합격 테스트 케이스 2개 추가.이렇게 하면 이 TfD가 구현됩니다.포장해 드릴까요?지연독자 (대화) 2021년 7월 15일 (UTC)응답[응답]

@ProcrastinationReader:구현해 주셔서 감사합니다!누군가 테스트 케이스를 쓰는 데 시간을 할애해 주셔서 감사합니다. :) 메인 모듈의 최신 변경 사항을 동기화하지 않은 것 같으니 다시 동기화하여 유닛 테스트를 통과했는지 확인해야 합니다.다른 테스트 케이스를 사용하여 자물쇠 아이콘이 표시되는 것을 확인할 수 있습니다. catonly=no 자세한 내용을 알고 싶다면 카테고리에 대해서도 비슷한 것을 사용할 수 있습니다.그리고 UNIQ를 복제하는 것도 봤고...스트립 마커를 검출하기 위한 QINU 패턴 - 향후 변경이 필요할 경우에 대비하여 자체 변수를 만들어야 합니다.샌드박스 코드는 괜찮아 보이지만, 상황이 복잡해지면 읽기 쉽도록 자체 기능으로 분할하고 싶습니다.뭔가 명확하게 하고 싶은 것이 있으면 알려 주세요.상기의 문제를 해결한 후, 유닛 테스트에 모두 합격하면, 코드를 전개해 주세요.베스트 — Stradivarius♪ talk ♪ 씨 2021년 7월 16일 11:45 (UTC) 응답[응답]
리뷰해 주셔서 감사합니다!이러한 테스트를 추가하고 배너 테스트도 추가했습니다.또한 그 패턴을 변수로 분할합니다.모든 테스트가 통과해서 코드를 배포했습니다.딜레이팅 리더 (대화) 2021년 7월 16일 (UTC)응답[응답]

2022년 2월 3일 템플릿 보호 편집 요청

모듈에 다음 항목을 추가하십시오.회선 772에 가까운 보호 배너/구성:

['모든 모듈 확장 확인 편집'] = 'Wikipedia 확장 - 보호 모듈',

ECP 모듈은 현재 카테고리로 분류되어 있습니다.Wikipedia에서 완전히 보호된 모듈로 이동합니다.이것에 의해, 다음의 카테고리로 이동합니다.Wikipedia 확장 확인 보호 모듈.AntiCompositeNumber (토크) 23:27, 2022년 2월 3일 (UTC)응답[응답]

완료: 특수:Diff/1069763876. --andrybak (토크) 23:50, 2022년 2월 3일 (UTC)응답[응답]
@안드리박 고마워요!AntiCompositeNumber (talk) 00:02, 2022년 2월 4일 (UTC)응답[응답]

일반 보호와 함께 보류 중인 변경 사항 관련 문제

침팬지에게 이 페이지는 미결인 동시에 반보호 상태입니다.{{pp-pc}}은 렌더링하지 않고 {{pp-pcalism}만 렌더링합니다.이게 예상된 건가요?: CX 줌 [그/그 사람](let's talk • {C•X})9:51, 2022년 8월 5일 (UTC)응답[응답]

@CX 줌:예, 한 가지 종류의 보호만 보고됩니다. 바로 "강력한" 보호입니다.이 경우,{{pp-vandalism}}는 확인되지 않은 사용자에 의한 모든 편집을 막는 편집용 준보호 기능을 선택합니다.{{pp-pc}}는 보류 중인 변경 사항을 선택합니다.이러한 변경 내용은 확인되지 않은 사용자에 의한 편집은 허용되지만 승인되지 않는 한 표시되지 않습니다.따라서 이 경우 세미프로트가 더 강력합니다. --Redrose64 🌹 (대화) 20:46, 2022년 8월 5일(UTC)응답[응답]

보호 수준에 일반 영어 사용

최근 Repression에서 독자들이 보호 아이콘을 이해하지 못하는 경우가 많아 툴팁 텍스트를 검토하게 되어 아쉬운 점이 있는 것 같습니다.메시지는 현재 "이 문서는 2022년 4월 7일 1:47 UTC까지 준보호되어 있습니다"와 같은 형식으로 되어 있습니다.독자는 "반보호" 또는 "확장보호"의 의미를 모르며, 극소수만이 보호정책 페이지를 클릭하여 확인할 수 있습니다.알기 쉽도록 쉬운 영어로 표현을 바꾸는 것이 좋습니다.준보호에 대해서는 2022년 4월 7일 1:47 UTC까지 신규 사용자는 이 문서를 편집할 수 없습니다(또한 추가된 쉼표와 제거된 마침표라는 두 가지 문법 수정 사항도 참고하십시오).EC의 경우 경험이 풍부한 사용자만 이 문서를 편집할 수 있습니다.생각?{{u Sdkb}}talk 2022년 8월 28일 (UTC) 18:21 (응답)

이론상으로는 타당해 보이지만, 당신이 제안한 단어들은 반보호와 확장확인을 위해 사용되는 언어로 서로 동의어처럼 읽혀지지 않습니다.* it has begun...ppery * 2022년 8월 29일 (UTC)응답[응답]
어떤 유명한 사건?토크 페이지에는 아무것도 없는 것 같습니다.--Redrose64 🌹 (토크) 09:15, 2022년 8월 30일 (UTC)응답[응답]
@Pppery씨, 다른 방법이 있나요?유저는 동시에 양쪽의 통지를 볼 수 없기 때문에, 편집 범위가 10~500인 유저에게는 직관적인 단어가 생각나지 않기 때문에, 우리가 더 잘 할 수 있을지 모르겠습니다.EC의 경우, 신규 및 중급 수준의 편집자는 편집할 수 없습니다만, 조금 더 알기 쉽게 되어 있습니다.
@Redrose64, https://slate.com/technology/2022/08/wikipedia-recession-article.html.{{u Sdkb}} 2022년 8월 30일 (UTC) 14:29 (응답)

도구 설명/제목이 실제 보호 수준과 일치하지 않습니다.

{{pp-extended}}와 같은 템플릿으로 표시된 기호와 기호 뒤에 배치된 링크는 자동으로 실제 보호 수준과 일치하지만 도구 설명/제목이 일치하지 않습니다.구체적으로는 러시아가 현재 완전 보호되고 있으며 보호 정책의 #full 섹션을 가리키는 링크가 있는 황금색 "F" 잠금을 표시합니다.그러나 제목 속성은 "이 문서는 확장 확인 보호됨"입니다.

이것은 지시보카1이 토크에서 깨달은 것입니다.러시아 및 모듈로 수정해야 합니다.~ ToBe Free (토크) 2022년 10월 1일 (UTC)응답[응답]

메모: 모듈을 일부 수정하고 테스트를 실행한 후 문제가 무엇인지 알아냈습니다.모듈은 모듈로부터 가져온 배너텍스트를 사용하는 템플릿 자체에 전적으로 의존하고 있는 것 같습니다.보호 배너/구성.준보호 페이지에서 {{pp-template}을(를) 사용하려고 하면 템플릿배너의 텍스트가 표시됩니다만, 보호 레벨은 준보호입니다.이것은 툴팁메시지가 사용하는 것처럼 대부분의 경우 동작합니다.${PROTECTIONLEVEL}이는 메시지가 페이지의 보호 수준에 적합함을 의미합니다.단, ecp용 툴팁은 읽기 쉽게 하드코딩되어 있습니다.This ${PAGETYPE} is extended-confirmed protected그것이 문제의 원인입니다.이 문제를 해결하려면 툴팁 메시지를 다음과 같이 변경하기만 하면 됩니다.This ${PAGETYPE} is ${PROTECTIONLEVEL} 다른 옵션의 형식과 일치합니다.Aidan9382(talk) 2022년 10월 1일 13:09 (UTC)응답[응답]