위키백과:봇/공지판

개요 사전 봇정책 Bot 승인 그룹 가이드 게시판 뉴스레터 Bot 요청 승인 요청 어드민 {{BAG 도구}} 봇 만들기 봇 목록 봇현황보고서 Bot 활동 모니터

봇을 만드는 것을 돕다

여보세요. 여기가 정확한 장소인지 잘 모르겠어.만약 이 문제가 여기서 해결이 안 된다면 어디로 가야 하는지 알려 줘.
현재 enwiki에 대한 AWB 봇을 가지고 있다, User:KiranBOT. 대화 페이지에 위키백과 제목 배너를 추가한다(가장 간단한 작업인 것 같다).요컨대, 나는 완전히 자동화된/툴포지 봇을 만들어야 한다.

전주곡:약 20일 전, 나는 Mrwiki (AWB)에 봇깃발을 꽂았다.20일 이내에(7~8회 주행 시) 10k 이상 편집(mr:special:contractions/KiranBOT)했다.마라티어의 구문, 단어규칙(문법규칙이 아님) 때문에 논란의 여지가 없는 발견과 대체 과제가 많다.그러나 현역/정규 편집자가 10명도 안 되기 때문에 그런 과제가 산적해 있다.

요점:mrwiki에서는 간단한 봇을 운영하고 싶지만 DumbB처럼 지속적인 편집이 가능한 봇을 운영하고 싶다.OT. 몇 시간 전에 위키/툴포지에 계정을 만들어 회원 가입을 신청했다.하지만 나는 여전히 어떻게, 어디서 봇의 코드를 업로드해야 할지 잘 모르겠어.나는 그것을 C#로 부호화하고 싶다.봇은 교체할 키워드와 함께 mrwiki에 대해 논의/베팅될 것이 분명하다(mr:사용자:Usernamekiran/typos).어떤 도움이나 지시는 감사할 것이다.—usernamekiran • 방명록에 서명 • (대화) 23:38, 2021년 12월 31일(UTC)

안녕.PHP 프로그래밍 언어에 대한 참고 사항:사용자:Novm Languageae/Essay/Toolforge bot 자습서.특히 FTP 클라이언트와 콘솔을 실행하는 데 사용할 수 있다.C#의 경우, 당신은 이것을 사용하고 싶을 것이다: 위키텍:도움말:툴포게/모노.그리고 또한 쿠베르네테스 대신 그리드.그게 도움이 되길 바래.–Novm Languageae(토크) 23:56, 2021년 12월 31일(UTC)

고마워. 조사해봐.—usernamekiran • 방명록에 서명 • (대화) 23:59, 2021년 12월 31일(UTC)

Novm Languageae 튜토리얼은 시작하기에 좋아 보이지만, 다음 두 가지 사항을 참고하십시오.
1. FTP 클라이언트를 사용하여 파일을 호스트로 전송하는 것을 언급한다.다른 방법이 있다 – Git.GitHub/Gitlab에 리포지토리를 설치하고 거기에 코드를 넣을 수 있다.툴포지 호스트에서는 끌 수 있다.웹 후크나 GitHub Actions를 사용하면 로컬로 누르면 TF에서 자동으로 당김을 트리거할 수 있는 방법이 있다.
2. 크론 작업에 쿠베르네트를 사용하는 것을 언급하고 있다.그리드를 사용하는 것이 훨씬 쉽다(crontab 파일에 라인을 추가하기만 하면 됨).– SD0001 (대화) 04:01, 2022년 1월 1일(UTC)

보관하지 않도록 더미 코멘트를 작성하십시오.—usernamekiran • 방명록에 서명 • (대화) 18:41, 2022년 1월 17일(UTC)

그래서 github로 파일을 전송할 수 있었고, mono on putty/CLI로 파일을 만들 수 있었다.하지만 나는 봇을 실행할 수 없었다.처음에는 C#, 그 다음에는 python으로 갔지만 둘 다 효과가 없었다.닷넷위키봇 프레임워크, AWB의 소스 코드, 그리고 미디어위키에서 언급된 다른 프로그램들과 같이 공부할/참조할 자료가 .net에 많이 있다.내가 필요한 것은 그것을 어떻게 컴파일하고 툴포지에서 운영하는가에 관한 약간의 지침이다.너의 도움은 정말 고마워할 거야.또한 @Mz7, JPxG, ST47: —usernamekiran • 방명록에 서명 • (토크) 15:44, 2022년 1월 18일 (UTC)

@Mz7, SD0001, Novm Languageae:안녕. 그래서 나는 phthon과 pywikibot을 내 컴퓨터에 다운받았고, 그것을 이용해서 몇 가지 수정을 했어.꽤 직설적이었습니다.나는 replace.py을 사용하여 한두 번 수정했다.나만의 kiran.py을 사용하여 몇 가지 수정도 했다.그러나 나는 발견과 교체 작업을 수행하는 방법을 알아내지 못했다.좀 도와주시겠습니까?10개 미만의 편집 내용은 mr:special:contractions/KiranBOT_II. —usernamekiran • 방명록에 서명 • (토크) 20:06, 2022년 2월 17일(UTC)

나는 파이톤을 잘 모르기 때문에 이 특정한 질문에는 어쩔 수 없다.하지만 Python은 가장 인기 있는 위키 봇 언어 중 하나여서 나는 누군가가 도울 수 있다고 확신한다.불화의 #기술 채널이 좋은 자원이 될 수 있다.행운을 빈다.–Novm Languageae(토크) 20:14, 2022년 2월 17일(UTC)

설명서의 내용은 mw:설명서:Pywikibot/replace.py.찾기&바꾸기 같은 것이 될 것이다.replace foo bar -search:"insource:\"foo\" "아니면 내가 뭘 놓친건가?- 콰르페즈클락토크 20:31, 2022년 2월 17일(UTC)

아니면 찾거나 대체하기 위해 당신만의 파이톤 코드를 쓸 수도 있다.Pywikibot은 단지 처음에 텍스트를 가져오고, 마지막에 저장하기 위해 사용되어야 한다.– SD0001 (대화) 04:07, 2022년 2월 18일(UTC)

콰르페즈클: 안녕.빠른 배경의 경우:마라티(mrwiki)에 자동화된 봇을 만들어 특정 단어나 단어의 집합을 찾아 대체하고 싶다.현재 리스트에는 메인 스페이스에서 교체해야 할 42개의 단어가 있으며, 약 200개 정도로 성장할 것으로 예상된다.@SD0001 나는 이미 나만의 대본을 이용하여 페이지를 성공적으로 편집했다.현재 내가 고수하고 있는 것은 피위키봇의 구문을 대체하는 작업과 ns:0의 페이지를 편집하라고 스크립트에게 지시하는 것뿐이다.내가 만든 대본, 나는 한 페이지를 편집하라고 말했었다.—usernamekiran • 방명록에 서명 • (대화) 08:18, 2022년 2월 18일(UTC)

파이톤용 regex 모듈을 사용해 보셨나요?- Qwerfjkltalk 08:39, 2022년 2월 18일(UTC)

@Qwerfjkl: 안녕.답장은 고맙지만 유감스럽게도 나는 너의 답장을 보기 전에 해결책을 찾았어.나는 찾기 및 바꾸기 문제를 해결했고, 이제 남은 것은 스크립트에게 어떻게 특정 네임스페이스의 페이지를 편집하라고 말하는가 하는 것이다.그것 좀 도와줄래?—usernamekiran • 방명록에 서명 • (대화) 18:34, 2022년 2월 18일(UTC)

편집할 페이지를 어떻게 공급하느냐에 따라 달라진다.- 콰르페즈클락토크 19:42, 2022년 2월 18일(UTC)

편집할 페이지 목록을 생성할 때 네임스페이스별로 필터링하는 방법이 한 가지 있다.자세한 내용은 편집할 페이지 목록을 생성하는 방법에 따라 달라진다.API query, pywikibot 함수 등을 사용하고 있는가?우리랑 코드를 공유하면 더 많은 답을 얻을 수 있을 거야–Novm Languageae(토크) 20:34, 2022년 2월 18일(UTC)

"코드를 공유"할 경우(그리고 최대 5~10줄 이상), 저장소에 대한 링크를 사용하거나 페이지를 압도하지 않도록 [1]을 사용하십시오.헤드폭탄 {t · c · p · b} 21:31, 2022년 2월 18일(UTC)

암호는 다음과 같다.

수입하다 피위키봇 로부터 피위키봇 수입하다 페이지 생성기, 텍스트로 된 수입하다 리  #페이지를 펴다 사이트 = 피위키봇.사이트() 페이지를 매기다 = 피위키봇.페이지(사이트, u"user:user:userkiran/typos") 문자 메시지를 보내다 = 페이지를 매기다.문자 메시지를 보내다  #페이지 편집 끈을 매다 = 페이지를 매기다.문자 메시지를 보내다 페이지를 매기다.문자 메시지를 보내다 = 끈을 매다.대체하다("abcusernamekiran", "xyz")  #페이지 저장 페이지를 매기다.절약하다(u"수정된 스크립트로 편집") 

감사합니다, —usernamekiran • 방명록에 서명 • (대화) 09:54, 2022년 2월 19일(UTC)

@Usernamekiran: 페이지 생성 시 이와 같은 것(테스트되지 않음):

수입하다 피위키봇 로부터 피위키봇 수입하다 페이지 생성기, 텍스트로 된 수입하다 리  #페이지를 펴다 사이트 = 피위키봇.사이트() 페이지 = 사이트.샅샅이 뒤지다( "직접:\"foo\"",  총계=5, 네임스페이스=0) 을 위해 페이지를 매기다 에 페이지:     문자 메시지를 보내다 = 페이지를 매기다.문자 메시지를 보내다      #페이지 편집      문자 메시지를 보내다 = 문자 메시지를 보내다.대체하다("abcusernamekiran", "xyz")     # 또는 리 모듈 사용:     # text = re.sub("usernamekiran", "xyz", text)      #페이지 저장     페이지를 매기다.절약하다(u"수정된 스크립트로 편집")문자 메시지를 보내다 

- 콰르페즈클락토크 10시 40분, 2022년 2월 19일(UTC)

사용자:레고봇 스팸 MFD 아카이브

여기를 보아라.봇은 {{bots}}}을(를) 존중하지 않는다.지금 당장은 다른 것을 입력할 수 없음 —GMX^{(on the go!)} 21:15, 2022년 1월 26일(UTC)

• 봇이 위키백과를 편집하는 것을 차단했다.삭제/아카이브 토론/한 달 동안 2022년 1월, 해결 보류 중해결된 경우 관리자(@Legoktm: 포함)는 차단 해제하십시오.— xaosflux^Talk 22:27, 2022년 1월 26일(UTC)
  • 교환원이 상담 시 통보함.— xaosflux 22:28, 2022년 1월 26일(UTC)

블리, 보고서랑 부분 차단해줘서 고마워, 지금 조사하고 있어.레고크™ (대화) 04:54, 2022년 1월 27일 (UTC)

• @Xaosflux: 봇이 다시 한번 오작동을 일으키기 시작했다 - 이번에는 위키백과에서:삭제/아카이브 토론/2022년 2월그 페이지에서 차단하고 블록을 2월까지 연장해줘.—GMX^{(on the go!)} 14:57, 2022년 2월 3일(UTC)

@Porkchop GMX(이동 중): 완료 — xaosflux 15:43, 2022년 2월 3일(UTC)

나는 MFD 보관기 스크립트의 자동 실행을 비활성화했다.새 코드를 몇 개 준비했는데 자동화하기 전에 며칠 동안 수동으로 실행하겠다.지금 당장 보관이 필요한 MFD가 없으니 내일 한 번 시도해보고 부분 블록을 들어올릴게.레고크™ (토크) 07:19, 2022년 2월 4일 (UTC)

위키백과 검토:Bots/승인요청/MalnadachBot 12

MalnadachBot 과제 12는 잠재적으로 수십만 페이지의 보풀 오류를 수정하기 위해 최근 빠르게 승인되었다.봇이 몇 가지 초기 편집을 시작하면서, 내 감시목록이 폭발하기 시작했다.내가 내 감시목록에서 보는 대부분의 편집은 10년 이상 전에 내가 만든 고대 AfD 후보작에서 한 특정 사용자의 서명에 더 이상 사용되지 않는 <퐁> 태그를 고치는 것이다.매우 작은 샘플링: [2][3][4][5] 이러한 편집은 페이지 렌더링 방식을 바꾸지 않고 HTML5를 준수하도록 기본 Wikitext만 수정한다. 이러한 편집에서 실질적인 변경이 이루어지지 않기 때문에, 이 봇 작업은 우리의 봇 정책에 따라 승인되어서는 안 된다고 생각한다. 특히 WP:코스메틱BOT. 이 작업(및 다른 유사한 작업)을 고려하여 검토하도록 요청하고 싶다.핑핑봇 소유자 및 봇 작업 승인자: @ಮಲನಾ್್್್್್::::: @Primfac: — ScottyWong — 15:59, 2022년 1월 28일(UTC)

Scottyung, 구식 HTML 태그를 현대 구문으로 변환해야 하는 시기는 언제인가?린트 오류는 2018년부터 미디어위키에 의해 플래그가 붙었기 때문에, 소수의 편집자들이 이미 3년 넘게 오류를 수정해왔고 여전히 수백만 개의 오류가 있다.손쉬운 오류를 많이 고쳤다는 점에서 나머지 수백만 개의 오류를 고치는 데는 수년이 걸릴 것이다. – Jonsey95 (대화) 16:13, 2022년 1월 28일 (UTC)

그것은 적절하게 편집에 "봇"과 "최소"라고 태그를 붙이는 것이므로 감시 목록 홍수는 봇 편집 내용을 숨김으로써 완화될 수 있어야 한다.— xaosflux^Talk 16:23, 2022년 1월 28일(UTC)

나는 봇이 왜 이런 편집을 하는지, 그리고 어떻게 하면 내 감시 목록에서 그것들을 숨길 수 있는지 이해한다.그러나 WP를 제안한다면:코스메틱BOT는 더 이상 봇 정책의 유효한 부분이 아니다. 아마도 우리는 WP에서 그 부분을 삭제해야 할 것이다.BOTPOL? 아니면 어떻게 이 봇이 페이지의 위키텍스트에 순전히 화장적인 편집을 하지 않는지 설명해줄 수 있니? — 스코티원 — 16:40, 2022년 1월 28일 (UTC)

아직 그 부분을 살펴본 적이 없어. 홍수를 일으키는 즉각적인 기술 문제가 있는지 알아보고 있었어.— Xaosflux 16:47, 2022년 1월 28일(UTC)

WP:코스메틱BOT에서 명시적으로 언급함[고정] 브라우저의 디스플레이에 영향을 미치지 않거나 RemexHtml에 의해 출력되기 전에 고정된 경우에도, 미닫힘 태그와 같이 엄청나게 무효한 HTML (예를 들어, <sup> 변경...)</sub>에서 ^까지...을 비(非)비(/sup)– SD0001 (대화) 16:47, 2022년 1월 28일(UTC)

스코티원, 나는 코스메틱B를 인용했다.오늘 한번은 OT인데, 아마 아직 그 게시물을 못 봤을 거야.여기 또 있다:봇이 특정한 외관을 변경하기 위한 합의는 승인된 승인 요청으로 공식화되어야 한다. 그런 일이 있었다.BRFA와 봇의 편집은 WP와 일치한다.코스메틱BOT. – Jonsey95 (대화) 16:49, 2022년 1월 28일(UTC)

BRFA는 3시간도 안 돼 빠르게 승인을 받았으며, 지역사회 논의의 기회도 없었다.이 논의는 이 봇이 WP를 위반하여 작동하도록 커뮤니티의 합의가 있는지 여부를 시험하는 역할을 할 수 있다.코스메틱봇.위에 제시된 예시는 페이지 렌더링 방식을 실제로 바꿀 수 있기 때문에 실질적인 것이다.<퐁> 태그를 <스팬> 태그로 바꾸어도, 현대의 모든 브라우저가 여전히 <퐁> 태그를 이해하고 지지하기 때문에, 전혀 변화가 없다. — 스코티원 — 16:54, 2022년 1월 28일 (UTC)

템플릿 공간에서 오래된 태그를 제거하기 위해 노력했던 것과는 달리, 대화 공간 페이지에 있는 수백만 개의 글꼴 태그를 손으로 고치지는 않을 겁니다. 자동화된 프로세스와 작동 중단이 확인될 때까지 글꼴 태그를 그대로 두는 두 가지 옵션을 남겨두십시오.당신이 원하는 것은 VPR의 RFC나 영어 위키백과의 글꼴 태그 사용을 공식적으로 금지해야 하는지 물어볼 수 있는 곳인 것 같다.더 이상 사용되지 않는 다른 태그에 대해 물어보는 것이 좋을 수 있다.<tt>...</tt>,<strike>...</strike>그리고<center>...</center>네가 하는 동안.– Jonsey95 (대화) 17:02, 2022년 1월 28일 (UTC)

'지금부터, 더 이상 글꼴 태그를 사용하지 말자'와 '휴면 AfD 페이지 수백만 장(대부분은 영원히 읽거나 편집되지 않을 것이다, 평생 동안)'으로 돌아가 수백만 장을 편집해 모든 글꼴 태그를 확장 태그로 바꾸자'는 차이가 있다.이 논의가 어떻게 진행되는지 먼저 보고, 그 다음에 더 넓은 RFC가 필요한지 판단해보자. — 스코티원 — 17:15, 2022년 1월 28일 (UTC)

나의 봇 편집은 WP를 위반하지 않는다.코스메틱봇, 린트 오류는 일반적인 화장품 편집 금지에서 면제된다.RemexHtml에 의해 Lint 오류가 발생하기 전에 고정된 지점 4를 참조하십시오.

빠른 승인의 경우, 그것의 맥락은 MalnadachBot의 이전 BRFA이다.그들은 시험과 토론을 거쳐 성공적으로 이루어진 매우 구체적인 유형의 린트 오류를 수정하여 470만개가 넘는 린트 오류를 수정해야 했다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ((대화) 17:18, 2022년 1월 28일 (UTC)

아마도 이것은 당신이 말하는 것의 핵심을 놓치는 현학적인 포인트일 것이다. 그러나 수백만 개의 AfDs가 아니라 수백만 개의 오류가 있다. (쿼리당 매일 로그를 제외한 484,194개의 AfD 하위 페이지만 있다.)jp×g 20:39, 2022년 1월 31일(UTC)

신속한 승인과 관련하여: 봇 운영자는 이러한 유형의 오류를 수정하는 데 10번의 유사한 실행을 성공시켰으며, 따라서 "토론할 기회가 없었다"고 말하는 것은 좀 어리석은 일이다. 첫 번째 과제는 2021년 5월에 승인되었기 때문에, 내 생각에는 그 과제가 논의될 수 있었던 9개월의 봇 편집 값이다.봇 운영자가 유사한 업무가 많이 발생하여 문제점이 0으로 실행되면, 나는 봇톱 시간을 절약할 뿐만 아니라 봇에 의해 수행되는 작업의 유형이 문제가 되지 않는다는 것을 증명했다.프라임팩 (대화) 17시 19분, 2022년 1월 28일 (UTC)

분명히 말해서, 나는 빠른 승인이 반드시 부적절했다고 말하는 것이 아니다.나는 BRFA가 이 과제에 대한 명백한 지역사회 합의를 나타낸다는 Jonsey95의 주장에 대응하고 있었다.나는 또한 봇이 기술적으로 잘못된 일을 하고 있거나 벌레가 있다고 말하는 것이 아니다.내가 제안하는 것은 만약 고대 AfD 페이지에 있는 순전히 화장품 위키백스트 구문 문제를 수정하는 것이 WP의 자격이 되지 않는다면:코스메틱봇, 그럼 어떻게 될지 모르겠어.만약 WP:COSmeticBOT는 더 이상 봇들이 WP에서 일하는 방식을 반영하지 않는다. 그렇다면 우리는 그것을 제거해야 할 것이다.하지만 그것이 제거되기 전까지는, 나는 여전히 이런 종류의 과제가 현재 쓰여진 것처럼 봇 정책의 잘못된 측면에 있다고 믿는다. — 스코티원 — 17:32, 2022년 1월 28일 (UTC)

나는 코스메틱B의 관련 부분을 인용했다.위의 OT.– Jonsey95 (대화) 17:48, 2022년 1월 28일 (UTC)

나 혼자만 얘기하면 승인을 취소하는 근거(또는 부인하는 근거)를 찾기가 힘들다.그 봇은 더 이상 사용되지 않는 구문으로 우리의 페이지를 미래에 증명하기 위해 레그 작업을 하고 있다.그것은 나에게 좋은 일이다.그러나 봇 운영/봇 페이지는 WP를 언급할 수 있다.HIDEBOTS는 그 일에 짜증이 난 사람들을 위한 감시자 잡음을 줄이기 위한 방법이지만, 그 일 자체는 합법적인 IMO이다.헤드폭탄 {t · c · p · b} 17:50, 2022년 1월 28일(UTC)

나는 여기서 프라임팩의 평가에 동의한다.코스메틱B를 찾을 수 있는 상태로 페이지가 떨어지는 것을 방지하기 위한 예방 조치인 12개의 BRFA상관없어, 코스메틱B의 대사에는 신경 쓰지 마.이러한 변경이 오늘 실행될 수 있음을 나타내는 OT?내게는 합리적인 것 같다.또한 WP와 같은 다른 곳에서 보내는 (성실한) 시간을 회피한다.VPT는 왜 누군가가 아카이브를 읽을 수 없는지에 대한 질문을 받을 때 입니다.이즈노(토크) 18:51, 2022년 1월 28일 (UTC)

이 (봇 소유주의 토크 페이지에 우려를 표한 다른 사용자와는 별도로) 이 부분에 대해서는 내가 유일한 목소리인 것 같은데 괜찮다만 괜찮다.괜찮으시다면 이 토론을 잠시 더 열어 두고 다른 사람에게 의견을 표명할 기회를 주고자 한다.만약, 합리적인 시간이 지난 후, 이러한 성형수술이 프로젝트에 좋은 것이라는 분명한 공감대가 형성된다면, 나는 그것을 존중하고 다시 내 구멍으로 기어들어갈 수 있어 기쁘다.나는 이 토론이 진행되는 동안 봇을 일시 중지시켰다. 나는 지금 봇을 일시 중지시킬 것이다. 왜냐하면 이 작업에 대한 승인이 취소될 가능성이 다소 낮아 보이기 때문이다. 그리고 봇이 이러한 편집을 계속하도록 허용하는 것은 이 토론에 더 많은 관심을 끌 수 있기 때문이다. — 스코티원 — 18:56, 2022년 1월 28일 (UTC)

내 핸드폰에서 잠깐 메모해두면 돼, re: COSTERBOT: 예를 들어, 승인을 얻지 못하는 화장품 편집의 자격을 얻는 것은 템플릿 호출에 '=' 기호를 맞추거나(인포박스에서 흔히 볼 수 있듯이) 줄 끝에서 공백을 제거하는 것이다.이러한 것들이 위키텍스트를 정리할 수는 있지만 HTML 출력을 변경하지는 않는다.AFAIK, 코스메틱B가 바로 그것이다.OT는 --rchard2scout (토크) 15:09, 2022년 1월 30일 (UTC)에 좋다.

나도 동의해, 화장품 봇은 딱딱한 레드라인이 아니라 상식적으로 사용해야 해.문제는 이 봇이 아주 많은 편집을 정당화 할 수 있을 만큼 좋은 아이디어라는 것이다. 게다가, 그 답은 IMO이다. 게다가, 기술적으로 변화가 오늘날에는 아마도 일부 브라우저들이 더 오래된 구문을 더 이상 지원하지 않을 경우 그들은 미래에 나타나지 않을 것이다.기본적으로 숨겨져 있는 이런 종류의 편집과 옵트인(opt-in)을 할 수 있는 방법이 있었으면 좋겠다. -- GreenC 15:24, 2022년 1월 30일 (UTC)

…기본적으로 이런 종류의 편집은...- 기본 전자 메일 감시 목록 설정은 사소한 편집 내용을 숨기는 것이기 때문에 이미 존재한다.젠장, 사소한 봇 편집이라면 네가 보고 싶어도 감시 목록에 없을 거야.프라임팩 (대화) 20:48, 2022년 1월 30일 (UTC)

정말이야?내 감시 목록의 맨 위에 숨길 수 있는 일련의 확인란이 있다.

나는 내 감시목록에 있는 기사의 사소한 부분과 편집된 부분을 모두 본다.만약 사소한 편집이나 봇 편집이 기본적으로 숨겨져 있다는 것이 사실이라면 몽크봇/태스크 18은 완성되기 위해 달려갔을지도 모른다.

—스승 (대화) 21:04, 2022년 1월 30일 (UTC)

미안, 이메일 알림에 대해 언급했었어야 했는데.나는 그에 따라 나의 코멘트를 업데이트했다.프라임팩 (대화) 21:09, 2022년 1월 30일 (UTC)

모든 사람들이 어디서 오는지는 잘 알고 있고, 내가 소수인 것이 분명할 때 그것에 대해 계속 논쟁할 생각은 없지만, 어쩌면 내가 좀 고리를 벗어난 것일지도 모른다.여기 제 질문이 있다: 현대의 주요 브라우저들이 <퐁> 태그와 다른 HTML4 요소들에 대한 지원을 완전히 부정할 계획을 가지고 있다는 실질적인 증거가 있는가?만약 브라우저가 페이지의 html 소스에서 글꼴 태그를 본다면 말 그대로 그 태그를 무시하거나 어떻게 해야 할지 모를 때가 올까?브라우저가 그 어떤 것에도 거의 영향을 미치지 않고 무한정 지원하는 것은 너무나 쉬운 일인 것 같다.나는 이 봇이 실제적인 문제를 해결하는지, 아니면 먼 미래의 어느 시점에 존재할지도 모른다고 생각하는 가상의 문제를 해결하려고 하는지 궁금하다고 생각한다. — 스코티원 — 21:28, 2022년 1월 30일 (UTC)

그것은 미디어에 제기할 수 있는 훌륭한 질문이다.일부러 표시를 해놓은 위키 개발자들.<font>...</font>그리고 이러한 태그를 포함하는 모든 페이지의 "페이지 정보" 페이지에 오류 카운트를 삽입하여 "오류 카운트"를 "오류"로 표시한다.소프트웨어 세계에서 특정 용도를 구식 또는 구식 또는 구식이라고 표시하는 것은 일반적으로 지원 제거를 위한 첫 번째 단계로서 MW 개발자들은 오랜 기간 동안 지원되는 많은 기능에 대한 지원을 제거해왔다.MediaWiki 개발자들은 쓸모없는 태그에 대한 유사한 계획을 가지고 있거나 다른 계획을 가지고 있을 수 있다.– Jonsey95 (대화) 23:30, 2022년 1월 30일 (UTC)

파싱/노트/에 좋은 노트가 몇 개 있다.HTML5 컴플라이언스.또한 게릿트:334990에 묻혀 있는 일부 토론도 있는데, 이 토론은 주로 나의 현재 생각을 대변하고 있다(확실히 나는 더 이상 파싱 팀을 대변하지 않는다), 이것은 아마도 브라우저가 지원을 중단할 것 같지 않다는 것이다.<font>,<big>가까운 장래에 , 등등.만약 그들이 그렇게 한다면, 우리는 wikitxt->> 에서 부서지지 않도록 그 태그를 우리 스스로 구현할 수 있을 것이다.HTML 계층 또는 단지 CSS.브라우저가 태그를 삭제하기 전에 Wikitext에서 이러한 사용되지 않는 태그를 제거할 계획이나 고려사항이 없다고 생각한다.나는 2020년의 메타위키에 대한 같은 토론에서 이렇게 말했다.

그렇긴 하지만, 나는 모든 서명에 대한 regexes를 만드는 대신에 폰트/etc. 태그를 올바른 스팬/etc. 교체로 적절하게 구문 분석할 수 있는 봇을 훨씬 더 보고 싶다.레고크tm (대화) 18:49, 2022년 2월 4일 (UTC)

이것은 가상의 문제가 아니며, 우리는 린터가 표시한 적어도 하나의 구식 html 태그가 모바일에서 작동하지 않는다는 것을 확실히 알고 있다. <tt>...</tt>모바일 위키백과의 일반 텍스트 렌더링.모바일 보기와 데스크톱 보기에서 비교하십시오.이를 근거로 우리는 합리적으로 다음과 같이 결론을 내릴 수 있다.<font>...</font>어느 순간에도 일을 멈추게 될 것이다.게다가 HTML5에서 쓸모없는 모든 것이 린터에 의해 쓸모없는 것으로 간주되는 것은 아니다.예를 들어 다음과 같은 태그<big>...</big>및 테이블 속성:align,valign그리고bgcolor글꼴 태그와 같이 HTML5에서도 사용되지 않음에도 불구하고 Linter에 의해 표시되지 않는다.그래서 개발자들은 폰트 태그가 아닌 이것들에 대한 지원을 계속할 계획을 가지고 있는 것 같다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ( ( ( ((토크) 06:00, 2022년 1월 31일 (UTC)

비록 기록상으로는<tt>...</tt>모바일 스킨에서 css를 재정의하는 특정 css 때문에 모바일에서는 작동하지 않음(2012년으로 되돌림)어떤 일반적인 모바일 브라우저가 그것을 지원하지 않았는지 혹은 지원하지 않았는지는 불분명하다.아노미에 13:57, 2022년 1월 31일(UTC)

그래서, 우리가 결국 진짜 문제가 될 것이라고 생각하는 가상의 문제들을 여전히 고치는 것처럼 들린다.나는 그것이 결국 어떤 식으로든 진짜 문제가 될 것이라는 것에 동의하지만, 솔직히 나는 12살짜리 AFD에 있는 누군가의 서명에 있는 문제를 수정하는 요점을 여전히 보지 못한다. — 스코티원 — 07:17, 2022년 2월 1일 (UTC)

봇 편집으로 가득 찬 내 워치리스트가 마음에 들지 않는 만큼, 그것은 코스메틱B가 아니다.변경 사항이 유지 관리 오류를 삭제하는 한 OT 위반.내가 말하고자 하는 것은 봇이 실제로 모든 문제를 한번에 해결하지는 않는다는 것이다.예를 들어, 이 편집은 괜찮은데, 이 글꼴 태그는 어때?정말 봇이 돌아와서 페이지를 다시 편집하는 거야?또는 이 편집과 같은 작업도 괜찮지만, 다른 두 가지 글꼴 태그가 사용된다는 점만 빼면 괜찮다.정말 봇이 각각의 서명을 한 번에 하나씩 대체하는 것일까?— HELLKOWNZ ∣ TALK 11:12, 2022년 1월 31일 (UTC)

솔직히 말해서, 내가 그 일에 대해 조금 더 직설적으로 승인한 이유 중 하나이다; "여기 또 다른 세 개의 서명이 있다" 대신에, 나는 그 보탑이 같은 페이지에 있을 것 같은 유사한 린터 오류들을 폭넓게 찾아내서 한꺼번에 그들을 때리기를 바라고 있었다.실행이 진행되어 새로운 오류가 발견됨에 따라 후속 BRFA 없이도 실행 논리에 추가될 수 있었다.만약 이것이 사실이 아니라면, 그것은 틀림없이 그럴 것이다.프라임팩(대화) 11시 34분, 2022년 1월 31일(UTC)

나는 단지 내가 그것들을 발견했을 때 교체 리스트에 구체적인 패턴을 추가하고 있을 뿐이다.완전히 자동화된 작업이기 때문에 대체에 범용 regex를 사용하고 싶지 않다.그들은 대부분 잘 작동하지만, 가장 어려운 경우는 귀찮다.내 경험에 의하면 사람들은...일반적인 목적을 위해 문제를 일으킬 수 있는 모든 종류의 것들을 사용하는 것에 창의적이다.이 과제의 크기를 고려할 때, 99.9%의 정확도로도, 수천 개의 잘못된 긍정을 남길 것이다.일이 순조롭게 진행되면 대부분의 사람들은 신경 쓰지 않겠지만, 몇 가지 오류가 있다면 많은 사람들이 불평을 하며 이야기를 할 것이다.오늘날 1660만 개가 아닌 10만 개 이하의 린트 오류로 줄어들면, 감독된 실행을 통해 한 페이지의 모든 오류를 한 번의 편집으로 지울 수 있을 것이다.특정 대체품만을 사용하는 나의 현재 접근방식은 한 번에 페이지의 모든 오류를 수정하지 않을 수 있지만, 가능한 한 오판율을 0에 가깝게 유지함으로써 그 일을 한다.이것은 나에게 가장 중요한 것이다.

그렇기는 하지만 한 번에 봇이 고려하는 패턴 찾기 및 교체 횟수를 늘려 한 페이지에 있으면 더 많은 패턴이 교체될 수 있도록 하겠다.봇은 페이지를 처리하는 데 더 많은 시간이 걸릴 것이고 일반적인 편집 요약을 사용해야 할 것이다. 하지만 그것은 좋은 절충일 것이다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ((대화) 18:07, 2022년 1월 31일 (UTC)

이 모든 변경 사항을 한 번의 편집으로 통합하지 않는 것은 좋은 이유가 아니다.만약 여러분이 코드의<수정할 수 있는 또 다른 작품 tt>, 태그는<>를 바로잡을 수 있도록 코드, font>, 태근다면, 당신 가기 위해 wikitext grab 있으면 글꼴을 태그 코드를 통해 이를 실행하고tt 태그 코드를 통해 이를 실행한 다음, 어떤 다른 블록을 통해 이를 실행한 결과 wikitext을 결과 수정 wikitext 가지고 있다. delintin의당신이 가지고 있는 g 코드, 그리고 마침내 기사에 변경 사항을 쓰세요.대신 Wikitext를 잡고 글꼴 태그 코드를 실행한 다음 해당 편집을 저장하십시오.그런 다음, 나중에 다시 Wikitext를 잡아서 ttag 코드를 통해 실행하면 편집 내용을 저장할 수 있다.네가 편집하는 횟수를 빼면 정말 차이가 없어. — 스코티원 — 07:14, 2022년 2월 1일 (UTC)

분명히 하자면, 내가 글꼴 태그를 수정해야 하는 코드(즉, 글꼴 태그를 수정하기 위한 범용 regexes)와 몇몇 다른 린트 오류는 대부분 잘 작동하지만, 일부 잘못된 긍정을 주어서 이와 같이 완전히 자동화된 작업에서 사용하기에는 적합하지 않다.당신은 첫번째 BRFA와 내가 왜 그런 코드를 내 봇과 함께 사용하지 않는지에 대한 이 토론을 읽을 수 있다.보통 이런 상황에서는 반자동 작업으로 실행하고 모든 편집을 승인한 후 잘못된 긍정이 폐기될 수 있도록 저장한다.그러나 그것은 엄청나게 많은 페이지들이 관련되어 있기 때문에 여기서는 불가능하다.그래서 나는 편집을 저장하기 전에 페이지에서 체크된 특정 사용자 서명 및 대체 템플릿과 같은 일련의 확실한 대체 작업을 해야 한다.나는 편집에서 더 많은 것을 얻기 위해 체크할 교체품의 수를 늘렸다.이는 봇이 점검한 교체품 중 하나 이상이 한 페이지에 존재하고 동일한 편집으로 고정된 경우를 보여주는 예일 것이다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ( ((대화) 15:58, 2022년 2월 1일 (UTC)

코스메틱B가 아니에요.변경사항이 유지 관리 오류를 삭제하는 한 OT 위반은 동의하지 않는다.코스메틱B의 기초우선 OT는 외관상 복잡한 페이지 기록, 감시 목록 및/또는 최근 변경 내용을 검토하는데 드는 시간을 투자할 가치가 없는 편집과 함께 편집하기 때문에, 그렇게 해야 할 중요한 이유가 없는 한 수행해서는 안 된다.그것은 정책의 본문에 나와 있지 않지만, 분명히 유용성과 스팸성 사이에서 균형을 이루어야 한다. 현재의 경우는 유용성이 상당히 낮다. (유지관리 오류를 삭제하는 것은 우선순위가 높지 않다.)

기본적으로 나는 스코티원에 동의한다.나는 코스메틱봇에 대한 강한 감정이나 반감은 없지만, 만약 그 봇 과제가 준수된다고 생각되면 정책이 무치라는 뜻이기 때문에 우리는 그것을 없애는 편이 낫다.(봇 과제가 코스메틱B에 대한 반대라는 주장이 나올 수도 있다.OT는 명시적인 예외로 허용되어야 하지만 나는 그런 주장을 하는 사람을 보지 않는다.)티그라안^{Click here for my talk page ("private" contact)} 13:08, 2022년 2월 3일 (UTC)

"그럴 이유가 없는 한" -- 예, 일반적인 예시 중 하나는 정책 텍스트 바로 아래에 있는 "엄청나게 잘못된 HTML [..]" 입니다.내 말은, 나는 그 정책이 스팸 발송을 제한하지 않는다는 것에 동의해. 하지만 그건 별개의 문제야.— HELLKOWNZ talk TALK 15:16, 2022년 2월 3일 (UTC)

그 정책은 미닫힘 태그와 같은 엄청나게 무효한 HTML을 말한다.닫히지 않은 태그는 여전히 지원되는 사용되지 않는 태그는 말할 것도 없고 사용되지 않는 태그보다 훨씬 심각한 문제다."지극히 유효하지 않은 HTML"은 닫히지 않은 태그만 포함하지 않고, IMO는 글꼴 태그를 포함하지 않는다.적어도 우리가 정책을 서면으로 시행하는 것에 대해 진지하게 진지하게 생각한다면, BRFA에서 어떤 논의를 할 것으로 예상할 수 있다.티그라안^{Click here for my talk page ("private" contact)} 13:13, 2022년 2월 4일 (UTC)

다시 묻겠다:지금은 아니더라도 이 사용되지 않는 태그는 언제부터 고쳐야 할까?더 이상 사용되지 않는 태그의 예는 수백만 개에 달한다.린터 오류를 수정하는 우리의 역사적 속도에 근거해 볼 때, 특히 서명의 글꼴 태그는 여전히, 이해할 수 없을 정도로, 미디어위키 소프트웨어에 의해 허용되기 때문에, 모든 오류를 수정하는 데는 수년이 걸릴 것이다.– Jonsey95 (대화) 14:30, 2022년 2월 4일 (UTC)

예방이 치료보다 낫다는 말이 있다.소프트웨어 업데이트는 모든 웹사이트에서 자연스러운 부분이다.저것<font>...</font>,<center>...</center>그리고 다른 구식 태그들이 여전히 지원되고 있다는 것은 그것이 미래에 계속 그렇게 될 것이라는 것을 의미하지 않으며, 따라서 개발자들이 왜 그것들을 오류로 표시하고 우리에게 그것들을 교체할 시간을 주는지를 의미한다.하루 만에 로그인하여 다른 것들 중에서 정렬과 색상이 표시되지 않는 페이지를 본다고 상상해 보십시오.이미 2018년 7월에 한 차례 일어난 일이다.그런 일이 있은 후에 그들이 끔찍하게 무효가 되지 않을까?이러한 편집은 소프트웨어가 변경될 때 페이지가 편집자의 의도대로 계속 표시되도록 함으로써 편집자와 독자에게 도움이 될 것이다.이것이 기본적으로 코스메틱비(COSTERNB)의 이유다.OT는 브라우저 디스플레이에 영향을 주지 않거나 RemexHtml로 출력하기 전에 html을 고정해도 수정 가능하다.나의 봇은 이전의 10개의 BRFA 린트 고정 작업을 실행하면서 이미 약 250만 개의 글꼴 태그를 교체했는데, 거의 아무런 논의도 없었다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ( ((대화) 14:36, 2022년 2월 4일 (UTC)

(충돌 편집) 닫히지 않은 태그 쌍과 대등하게 작업을 중지할 태그를 고려한다.잘못된 마크업이 잘못됨.비주얼 디스플레이, 구문 분석, 화면 판독기, 인쇄, 접근성, 정방향 호환성 등 — HELLKOWZ talk TOK 14:40, 2022년 2월 4일(UTC)

@Hellknowz:그러나 이러한 더 이상 사용되지 않는 HTML4 태그는 여전히 지원되고 있으며, 특정 날짜에 지원을 중단하는 계획은 그 누구에 의해서도 발표되지 않았다.물론, 결국 그들은 지지받지 못할 것이고, 아마도 내년에, 우주의 열사병과 일치할 수도 있고, 어쩌면 그 중간쯤에 있을 수도 있다.이 시점에서 우리는 미래에 일어날지도 모른다고 생각하는 어떤 것에 대해 반응하고 있지만, 언제 일어날지는 알 수 없고, 그 비난이 어떻게 처리될 것인지에 대한 구체적인 사항은 알 수 없다.아마도 우리에게 5년 간의 불체포 통지가 주어질 것이다.아마도 HTML4 태그가 완전히 지원되지 않을 때쯤에는 이미 HTML6 태그를 사용하고 있을 것이고, 한 번만 할 수 있었을 때 이 모든 과정을 두 번째로 거쳐야 할 것이다.요점은 우리가 반사적으로 행동하고 있지만 아직 아무것도 모른다는 것이다.그리고 우리의 대응은 수백만 년 된 폐쇄된 AfDs를 편집해서 누군가의 서명을 엉망으로 만드는 겁니다.나는 많은 사람들이 이것을 뒤로 미루고 있다는 것이 놀랍다.내 말은, 이런 문제들을 해결하기 위해 기사 공간을 통과하는 것은 이해할 수 있다는 거야.하지만 15살의 AfDs는?정말?그게 얼마나 가치있는 일이지?누군가가 우연히 15년 된 AfD를 열게 되고 편집자가 원래 의도했던 사용자 정의 글꼴이 아닌 기본 글꼴로 누군가의 서명이 표시된다면 최악의 시나리오는 무엇인가? — 스코티원 — 17:31, 2022년 2월 4일 (UTC)

당신은 "최악의 경우"라고 말하지만 당신은 가장 좋은 사례 중 하나를 묘사한다.최악의 경우는 페이지 전체가 5xx 서버 오류를 발생시키고 아무것도 렌더링하지 않는다는 것이다.나는 그것이 일어날 것이라고 말하는 것이 아니라, 우리가 더 이상 사용되지 않는 것으로 표시된 것을 고치는 대신에 미래를 추측하려고 노력하고 있다는 것이다.원래 우려했던 것은 코스메틱B.OT는 적용되지 않는다(또는 이 사용 사례를 명시적으로 언급하지 않음).나는 사람들이 좋아하지 않더라도 그것이 정책을 따른다고 주장할 뿐이다.그러나 우리가 실제로 이것을 고치기를 원하는지 아니면 휴식시간이 될 때까지 놔두고 싶은지는 감시자들이 밝혀질 때까지 반대하지 않았던 다른 문제다.이 게시판은 정책적인 이유로 승인을 검토할 수 있는데, 나는 문제가 없다고 생각한다.내가 말했듯이, 나는 감시자 스팸도 싫어하고 모든 교체를 동시에 하지 않는 것은 꽤 끔찍해.그리고 이것은 어떤 것이 고쳐져야 할 첫 번째도 아니고 마지막도 아닐 것이다.이것은 감시 목록(검색, 정렬, 필터) 기능 문제처럼 들린다.— HELLKOWNZ talk TALK 19:10, 2022년 2월 4일 (UTC)

일부 위키텍스트에서 5xx 오류를 발생시킨다면 이는 절대적으로 개발자/sysadmin 문제일 뿐, 온위키 편집자나 봇이 해결할 문제는 아니다.레고크™ (대화) 06:42, 2022년 2월 5일 (UTC)

• 어떤 사람들은 좋은 이유로 그들의 시계 목록에 있는 사소한/봇 편집이 있다.예를 들어, 활성 페이지의 부분 또는 봇 편집을 모니터링하는 경우.그들이 그들을 흥분시키지 않는 것은 수십 년의 가치의 보관/폐쇄된 AFD가 그 이름을 거의 받을 자격이 없는 오류에 대해 사소한 수정 작업을 하는 것을 되돌아보는 것이다.축하해, 방금 삭제된 기사들 중 몇 개를 삭제한 후 편집자 감시 목록의 맨 위에 올려 놓았잖아.잘 했어요5, 4, 3분 후 레크리에이션 카운트다운...오직 죽음에서만 의무종료 (대화) 15:14, 2022년 1월 31일 (UTC)

• 나는 여기에 관련된 문제를 가지고 올 거야.날짜별로 정렬된 ANI 기록 보관소에서 뭔가를 찾으려고 했어하지만 그건 불가능해. 왜냐하면 검색된 날짜가 마지막 수정 날짜니까. 이것은 봇이 아카이브가 만들어진 지 한참 후에 사소한 오류들을 고쳤기 때문에 왜곡된 거야.예를 들어, 위키백과:관리자 알림판/IncidentArchive969에는 "문서고를 편집하지 말아달라"는 내용이 2개 들어 있지만, 이 봇은 어쨌든 그렇게 했다.나는 그 봇들이 어떤 문제를 해결하려고 했는지는 상관없어. 그들은 위키피디아의 검색 메커니즘을 깨뜨려서 그것을 사용할 수 없게 만들었어.리치333^(talk)(cont) 12:16, 2022년 2월 3일(UTC)

  솔직히 위키피디아 검색은 망했다.@Ritchie3333:당신이 언급한 문제(봇 편집으로 '마지막 수정'이 업데이트되는 아카이브 검색) 나는 작성 날짜별로 필터링하여 돌아다녔는데, 이는 아카이브에 있는 항목의 실제 날짜와 대략 일치해야 한다.미루는 Reader (대화) 15:21, 2022년 2월 3일 (UTC)

  리치333이 기술한 문제는 영원히 존재해 왔고, 봇이 아카이브 페이지를 청소하든, 인간이 수동으로 정리하든, Xfd 프로세싱 편집자가 하든지 간에 발생한다.MW 코드가 변경될 때 페이지를 편집해야 한다; 그것은 단지 현실이다.검색 데이트가 깨졌어– Jonsey95 (대화) 15:32, 2022년 2월 3일 (UTC)

  우리가 그것을 현실로 만들지 않는다면 그것이 현실일 필요는 없다.우리는 우리의 현실을 (AN, ANI, XfD와 같이) 보관된 토론 페이지들이 봇이나 다른 사람들에 의해 편집되지 않는 것이 되도록 선택할 수 있다.그리고 20년 후, 편집자가 원래 의도했던 맞춤 글꼴 대신 편집자의 화려한 서명이 기본 글꼴로 나타난다면, 음...감정적으로 문제를 해결할 방법을 찾아야 해서명에 사용자 정의 글꼴을 사용하는 사람으로부터 온 나는 그 문제를 해결할 수 있는 방법을 찾을 수 있다고 확신한다.추가 치료가 필요할 수도 있지만, 할 수 있을 것 같아. — 스코티원 — 17:36, 2022년 2월 4일 (UTC)

• 중요한 것은 -- 이런 종류의 토론은 종종 비관적인 성향을 띠게 된다는 겁니다. 왜냐하면 문제를 보지 않는 사람들은 그것에 대해 언급하는 것을 충분히 신경 쓰지 않기 때문이죠 -- 전 문제가 있다고 보지 않습니다만.좋아, 어쩌면 그것은 검색을 어길지도 모른다. 이것은 잠재적인 진짜 문제처럼 보이지만, 더 깊은 문제는 검색이 이것 때문에 깨지면 형편없다는 것이다.10년 전만 해도 임시로 감시하는 기능이 없었다는 사실 말고는 왜 10년 동안 감시 목록에 한 페이지를 두었는지 모르겠다.10년 전에 만료된 AfD를 감시하는 것이 이득이 되는 것은 아니다. 그렇지 않다면?있어? jp×g 20:12, 2022년 2월 8일(UTC)

MediaWiki에서 이 문제를 해결하지 않을래?

몇 가지 사전 토론에서 본 기억이 나는 것 같다(WP:VPT IERC, 비록 내가 토론을 찾을 수 없었지만, 그것을 연결하지 않은 것에 대해 사과한다) 미디어위키는 기본적으로 wikitxt(나쁜 HTML과 모든 것)를 가져다가 출력에 맞게 수정할 수 있는 업데이트를 어느 시점에 갖게 될 것이라고 했다.렌더링 파이프라인에서 마사지를 하거나 고정할 수 있는 "수정" 마크업을 수정하기 위해 수만 개(또는 아마도 모든 것을 말하고 실행했을 때 수백만 개)의 수정으로 편집 이력을 방해하는 것은 엄청난 시간과 자원의 낭비인 것 같다.—Locke Cole • t • c 03:27, 2022년 2월 7일(UTC)

번역이 모든 개정판을 보는 모든 사람들에게 엄청난 시간과 자원의 낭비라는 것을 요구함으로써 렌더링 파이프라인을 막아버리는 것과는 반대로 :) 데이터베이스의 수정은 어쨌든 근본적으로 싸다.

특정 태그 한 개를 번역하는 짧은 시간이 있었지만 번역과 맞지 않는 곳에서 사용하다 보니 다른 이유 중에서도 빨리 풀렸다.이즈노 (대화) 04:40, 2022년 2월 7일 (UTC)

렌더링은 정기적으로 편집되는 페이지의 문제일 뿐이고 오류가 있는 대부분의 페이지가 오래된/스테이일 토론 페이지인 것처럼 보인다는 점을 고려하면 대량 봇 편집이 어떻게든 더 낫다는 확신이 들지 않는다.—Locke Cole • t • c 05:34, 2022년 2월 7일(UTC)

아니, 서버가 모든 수정본을 다시 렌더링해야 해.주석을 개정하기 위한 HTML은 HTML로 저장되지 않고 Wikitext로 저장된다.이즈노 (대화) 05:46, 2022년 2월 7일 (UTC)

로크 콜, 네가 제안하는 것과는 정반대의 일이 일어났어페이지를 렌더링하는 코드는 수년 동안 구문 오류를 묵묵히 수정해 왔으며, 새로운 렌더러가 배치되었을 때 이러한 해결책 중 일부는 이월되지 않았다.따라서 특별함:렌더링 오류를 발생시킬 수 있는 오류(대부분 2018년 이후 gnome과 봇에 의해 수정됨)와 함께 어느 시점에 해결 방법이 제거될 것으로 추정되는 조건을 플래그하는 라인 오류.자세한 내용은 mw:구문 분석/교체 정돈 – Jonsey95 (대화) 04:52, 2022년 2월 7일(UTC)

@Jonsey95:포인터 고마워.내가 이것에 관심을 끈 것은 이 편집이 대체된 것이다.<tt>와 함께<code>내가 생각하기에 질량 축척으로 행해지는 이상한 일(반자동화 여부)이라고 생각했던 태그들.—Locke Cole • t • c 05:45, 2022년 2월 7일(UTC)

재미있는 것은 미디어위키에서 이것을 고칠 필요가 없다는 것이다. 세계의 어떤 주요 브라우저도 HTML4 태그에 문제가 없기 때문이다.만약 이 봇이 그것을 고치지 않았고, MediaWiki 소프트웨어가 고치지 않았다면, 당신의 브라우저가 그것을 고쳤을 것이다.이 문제들은 기사 영역에서만 고쳐져야 한다.나는 아직도 12년 된 폐쇄된 AfDs에 글꼴 태그를 고치는 것이 가치 있다고 여겨지는 정당한 이유를 듣지 못했다 — 스코티원 — 05:54, 2022년 2월 7일 (UTC)

사실, 의 경우<tt>토끼가 나를 이 토론에 참여하게 한 MDN은 여전히 이 태그가 시장의 모든 주요 브라우저에서 완전히 지원되는 것으로 보여준다.스펙에서 탈락한다는 것은 존재하지 않는 이슈를 쫓는 것을 의미하지 않는다.—Locke Cole • t • c 06:11, 2022년 2월 7일(UTC)

나는 여전히 어떤 합법적인 이유도 기본적으로 오류라고 듣지 않았다. 왜냐하면 나는 똑같은 말을 할 수 있고 그것이 그대로 사실이라고 할 수 있기 때문이다.

브라우저에 관해서는, 오늘날에도 그렇다.같은 이유로 MediaWiki 개발자들은 임의의 태그를 종료할 수 있고, 브라우저 또한 그렇게 할 수 있다.그리고 그들은 전에 그것을 해 본 적이 있는데, 개발자들은 말할 수 없다.

오늘날의 모바일이 CSS 리셋을 이전 태그의 다발(<ttt>와 <small>)에 이미 적용하고 있는데, 이 두 태그 모두 정상적인 텍스트로 렌더링된다는 사실은 신경쓰지 마십시오.이즈노 (대화) 06:15, 2022년 2월 7일 (UTC)

이러한 모든 이유로 인해 기사 공간 내에서 사용되지 않는 태그를 수정해야 한다.그러나, 10년 전에 마감된 오래된 AfD 페이지에서 이러한 더 이상 사용되지 않는 태그를 수정하기 위해 수백만 번을 편집하는 것은 어떤 가치가 있는가?그게 가치 있는 이유 하나라도 제시해 줄 수 있는 사람이 있다면 기꺼이 입을 다물겠다.나는 "왜?"라고 묻고 설득력 있는 대답을 바라는 것은 잘못된 것이라고 생각하지 않는다. — 스코티원 — 17:12, 2022년 2월 7일 (UTC)

나는 여러 번 오래된 AFD 로그 페이지(일반적으로 누군가가 TFD 삭제 템플릿을 부적절하게 복사한 경우)를 확인해야 했고, 페이지에 린터 오류가 있는 경우, 내가 그것을 수정하기 위해 그들이 어디에서 오는지 정리하는 데 시간이 오래 걸리고, b) 내가 원래 찾던 것을 찾았다.나에게 있어, 그것은 오래된 것들을 고칠 충분한 이유야.

"감시원 스팸" 주제에서, 나는 일년에 한 번 정도 겪으며 다시는 볼 필요가 없을 것 같은 나의 감시 목록의 절반 가량을 정리하는데, 그 중 많은 것들이 삭제 토론 페이지들이다.프라임팩 (대화) 17:21, 2022년 2월 7일 (UTC)

Malnadachbot을 페이지당 하나의 편집으로 제한하도록 요청

보푸라기의 오류 수정은 계속되며, 12년 전의 모든 AfDs가 보푸라기를 읽고 있는 편집자들의 무리에게 잘 나타나기를 바란다.어쨌든, 진지하게, 나는 MalnadachBot이 보풀 오류를 수정하기 위해 페이지당 여러 번 편집을 하고 있다는 것을 알게 되었다.내 RfA 페이지는 주기적으로 내 감시 목록에 나타난다.그 페이지의 기록을 보면 말나닥봇은 보푸라기의 오류를 수정하기 위해 그 페이지를 8번 별도로 편집했다.과제 2에 따라 5개의 편집이 이루어졌고, 과제 12에 따라 3개의 편집이 이루어졌다.모든 편집은 서로 극도로 유사하며, 봇 소유자가 레그스와 AWB를 적절하게 사용하는 방법을 알고 있었다면 한 번의 편집으로 편집하지 못했을 이유가 없다.보푸라기가 없는 10년 된 이 아카이브된 페이지를 얼마나 더 편집해야 보푸라기가 없는가?나는 솔직히 이것이 사용자:ಮಲ್್್್ಣೊ는 이 업무를 제대로 수행할 수 있을 만큼 유능한 봇 편집자가 아니다.적어도 그의 봇 접근을 제거할 수 있는 지원이 없다면, 나는 그의 봇 작업 승인이 그가 보풀 오류를 해결하기 위해 페이지당 한 장 이상 편집해서는 안 된다는 것을 분명히 해 줄 것을 요청하고 싶다. — 스코티원 — 16:31, 2022년 3월 2일 (UTC)

@ಮಲನಾಡ್್್್್ :::::의 코멘트를 메모한다.
분명히 하자면, 내가 글꼴 태그를 수정해야 하는 코드(즉, 글꼴 태그를 수정하기 위한 범용 regexes)와 몇몇 다른 린트 오류는 대부분 잘 작동하지만, 일부 잘못된 긍정을 주어서 이와 같이 완전히 자동화된 작업에서 사용하기에는 적합하지 않다. 당신은 첫번째 BRFA와 내가 왜 그런 코드를 내 봇과 함께 사용하지 않는지에 대한 이 토론을 읽을 수 있다.- 콰르페크렐트 16:40, 2022년 3월 2일(UTC)

나는 이것이 문제라고 생각하지 않는다. 이것들은 물결로 처리되고 여전히 합리적인 편집인 것 같다.이 봇은 편집에 "봇" 깃발을 적절히 주장하는 것으로 보여서, 감시목록에서 봇 편집을 보고 싶지 않은 사람은 누구나 쉽게 걸러낼 수 있다.서명 수정에 대한 수동 정의가 필요한 것으로 보이므로 모든 사례가 식별될 것으로 기대하는 것은 합리적이지 않다.만약 이런 일이 하루 동안 8번 편집하는 것처럼 매우 빠르게 일어난다면, 더 잘 다루어야 할 것 같지만, 한 페이지당 여러 달에 걸쳐 퍼질 때는 그렇지 않다.— xaosflux^Talk 16:44, 2022년 3월 2일(UTC)

참고: 이것은 일반적으로 (위에서 논의되고 있는) 과제의 적합성에 대한 승인이나 비난이 아니다. 단지 나는 이 특정한 제약이 좋은 해결책이라고 보지 않는다.— xaosflux^Talk 16:46, 2022년 3월 2일(UTC)

나는 이러한 문제들을 여러 번 수정하거나 수동으로 개입하지 않고서는 자동화된 방법으로 해결할 수 없는 이유를 모르겠다.규칙적인 표현을 제대로 이해한 사람이라면 누구나 이렇게 할 수 있다.이것은 유능한 코더에게 풀어야 할 복잡한 문제가 아니다.만약 이 봇 운영자가 한 페이지의 모든 오류를 한 번의 편집으로 고칠 수 없다고 주장하거나, 그의 코드가 너무 비효율적이어서 "잘못된 긍정"을 만들어내고 모든 편집을 수동으로 감독하도록 요구한다면, 다른 봇 운영자를 찾아야 한다고 생각한다.다른 사람이 원하지 않으면 내가 자진해서 그 일을 맡겠다.FYI - 봇 운영자 자신이 (봇이 아닌) 내 이전 RfA 페이지를 수동으로 편집했으며 페이지의 보풀 오류를 모두 수정해야 한다고 주장했다. — 스코티원 — 17:00, 2022년 3월 2일 (UTC)

@Xaosflux: 이 봇이 "파도를 타고" 페이지를 넘나들며 매번 다른 이슈들을 고치고 있다면 그것은 하나의 문제일 것이다.그건 여기서 일어나는 일이 아니야.봇은 동일한 이슈의 다른 인스턴스를 수정하기 위해 여러 번 편집하기 위해 같은 페이지로 이동한다.이것은 불필요하게 워치리스트를 채우며, 편집 이력을 방해하고, 오래된 보관 페이지의 마지막 수정 날짜를 바꾸고, 다른 문제들 중 하나이다.페이지에 동일한 보풀 오류의 10개 인스턴스가 있는 경우, 10개 인스턴스를 모두 수정하려면 둘 이상의 편집이 필요하다는 기술적 이유(부실한 코드화 제외)가 없다.나는 이 봇 운영자와 그가 수행하는 일에 대해 계속 불평함으로써 아마 내가 짜증나게 하고 있다는 것을 알고 있지만, 그것은 정말로 나에게 매우 짜증나는 일이다. — 스코티원 — 19:57, 2022년 3월 2일 (UTC)

봇 파장은 "이 서명 일괄 수정"의 선을 따라 "보풀 오류:n"의 모든 인스턴스를 수정하거나 심지어 "알려진 모든 유형의 보풀 오류를 수정"하는 것이 아니다.당신이 이것을 좋아하지 않는다는 것은 이해하지만, 나는 서명 수정이 다루기 힘든 골칫거리가 될 수 있고 종종 여러 개의 파도가 애드호크 타입으로 그것들을 다루기 위한 가장 좋은 방법이라는 것을 알고 있다.당신이 파악한 문제들만큼, 감시 목록을 방해하는 것은 빠른 행정 조치를 받을 가능성이 가장 높지만, 봇 깃발이 주장되고 있기 때문에 그것은 꽤 사소한 것처럼 보인다.나는 마지막 터치 날짜나 한 페이지에 대한 몇 가지 추가 수정과 관련하여 심각한 문제가 있다고 보지 않는다.더 나은 봇을 만드는 것은 거의 항상 환영받지만, 그러한 것이 실현되기를 기다리는 동안 개선을 멈추는 것은 보통은 아니다.— xaosflux^Talk 22:58, 2022년 3월 2일(UTC)

바로 그거야우리는 완벽을 선의 적이 되게 해서는 안 된다.모든 위키 모델이 증분 개선의 원칙에 의해 작동된 후에.첫 번째 BRFA를 제출하기 전에, 나는 무엇이 실행 가능한지 보기 위해 이전의 모든 en.wp 린트 고정 봇 작업 시도에 대해 살펴보았다.성공적 과제에는 BRFA당 특정 패턴 일괄 처리, 실패한 과제에는 모든 것을 고치려는 봇 운영자와 문제 규모를 파악한 후 포기해야 하는 봇 운영자가 포함되었다.분열과 정복 접근법을 이용해 봇을 여러 파도로 운영하는 것은 밀린 일을 줄이는 현실적인 방법일 뿐이다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ( ((토크) 05:28, 2022년 3월 3일 (UTC)

@스코티원:나는 너의 RFA에서 95개 정도의 린트 오류를 수동으로 수정했다.대본 편집에 15분 걸렸어정말 봇이 그것들을 한 번에 다 편집해 줄 거라고 생각하니?만약 봇 소유자가 레그스와 AWB를 적절하게 사용하는 방법을 알고 있었다면, 한 번의 편집으로 그것들을 만들 수 없었을 이유가 없다는 것은 정말 사실이 아니다.나는 누구보다 린트 오류에 대한 봇 수정 경험이 있어, 잘못된 긍정을 남기지 않고 가능한 한 효율적으로 봇을 운영하고 있다.그렇더라도 이 실이 열린 이후 봇이 140만 린트 오류를 고쳤다는 점을 지적하고 싶다.RFA 페이지는 본질적으로 대부분의 위키 페이지보다 훨씬 더 많은 서명을 가지고 있기 때문에, 봇은 평소보다 더 많이 그것을 재방문한다.이 일은 보기보다 훨씬 복잡하다.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ((대화) 17:06, 2022년 3월 2일 (UTC)

네 말은 말이 안 된다.나는 regex를 꽤 잘 이해하고 있으며, 위키백과에서 유사한 이슈를 고치는 봇을 운영하곤 했다(아마도 수백만 개의 개별 이슈를 고쳤겠지만, 적절히 코딩되어 있었기 때문에 그렇게 하기 위해 수백만 개의 편집을 할 필요가 없었다).이것은 보이는 것보다 더 복잡하지 않다. 사실, 전혀 복잡하지 않다. 그것은 단순한 regex를 찾아 교체하는 것이다.적절하게 코드화된 봇이 인간의 개입이나 감독 없이 단 한 번의 편집으로 이러한 보푸라기 문제를 모두 해결할 수 없는 기술적 이유는 없다.만약 당신의 regex가 적절하게 설계되었다면, 잘못된 긍정의 위험은 매우 낮을 것이다.내 RfA 페이지의 경우, 당신의 봇은 정확히 같은 문제의 다른 인스턴스들을 수정하기 위해 여러 번 수정했다.이 편집에서 6개의 서로 다른 인스턴스(instance)를 수정하십시오.<font color="something">Text</font>그리고 몇 주 후에, 당신은 정확히 같은 이슈의 14개를 더 수정하기 위해 이것을 편집한다.첫 번째 패스(또는 더 구체적으로 첫 번째 8 패스)에서 코드가 왜 이러한 이슈를 놓쳤는가? — 스코티원 — 18:31, 2022년 3월 2일 (UTC)

그것은 당신의 RFA 페이지에서 정확히 같은 문제의 다른 인스턴스들을 고치지 않았다.작업 2에서 편집한 내용은 특수 수정:LintErrors/tidy-font-bug.링크 안에 있는 더 많은 글꼴 태그와 달리, 이 유형의 오류는 이미 페이지에서 시각적 차이를 만든다.이 작업에서 모든 편집이 수행된 경우, 109 및 134줄의 편집은 일반적인 패턴을 대상으로 하는 경우 동일한 작업에서 다른 작업자와 한 번의 편집으로 봇을 올바르게 적용하기 어려울 것이다.아무리 잘 설계된 regex라 할지라도, 그들은 한 번의 편집으로 이 모든 것을 잡을 수 없다.서명이 많은 RFA나 기타 페이지의 경우, 내가 이미 하고 있는 대체를 더 많이 사용해야만 봇 편집 횟수를 줄일 수 있다.문제를 이해하기 위해 린트 오류를 고치는데 시간을 좀 투자해야 해, 그렇다면 이 문제를 쉽게 해결할 수 있는 일이라고 무시하지는 않을 거야.모든 오류를 한 번의 편집으로 수정하는 것이 매우 간단하다고 생각되는 경우 자신의 BRFA를 제출하십시오.ಮಲನಾಡ್್್್ ( ( ( ( ( ( ( ( ((토크) 05:01, 2022년 3월 3일 (UTC)

스코티원:위키백과:Billage pump (기술)/Archive 70은 약 180 Linter 오류가 있는 샘플 페이지로서, 거의 모든 것이 글꼴 태그와 관련이 있다.각 페이지의 단일 편집으로 해당 페이지와 기타 VPT 아카이브 페이지의 모든 린터 글꼴 태그 오류를 수정할 수 있는 거짓 양성 없는 정규식 집합을 만들도록 하십시오.만약 그렇게 할 수 있다면, 혹은 한 번의 편집으로 수를 90% 줄일 수 있다고 해도, 당신은 영웅이 될 것이고, 당신은 위키피디아가 수백만 개의 린터 오류의 부담에서 훨씬 더 빨리 벗어날 수 있도록 도울 수 있을 것이다.다음은 여러분이 보고자 하는 것의 예시 입니다.

<폰트 페이스="세기 고딕"][사용자:Equazcion <span style="색상:#000080">'Equazcion''[/span] <작은>[사용자 대화:Equazcion ''<supp''(<span style="color:#007BA7">talk</span')]<//sm><02:29, 2010년 1월 16일 (UTC)</font>[사용자:IP69.226.103.13 <font color="녹색"<strong>IP69.226.103.13] [[사용자 대화:IP69.226.103.13 <font color="녹색"<strong>내 얘기 좀 해봐.</strong>[[사용자:테릴자 <퐁색="003300">테릴자[/font]][[사용자 대화:테릴자 <콘트색="검은색"] [[사용자:2012년 12월 21일 Freak <font color="#922724">"'12월 21일 Freak'</font>][사용자 대화:2012년 12월 21일 Freak <font color="#008080">"Talk to me"</font>]</sup><font face="monospace" color="#004080"][사용자:화분원 <스팬스타일="컬러:#004080; 글꼴변수:작은캡스">플라워팟마N[/span]]·[사용자 대화:화분공 t])</font><fontface="Myriad Web">][사용자:Mrschimpf <span style=" color:maroon">네이트</span>]''스팬스타일='색깔:다크푸른'•<</span> <작은>([User_talk:Mrschimpf <span style="color:dodgerblue"</span>]'</font></font></font> <fonte face="Baskerville Old face"][사용자:the_ed17 <font color="800000">Ed</font>] [사용자 대화:the_ed17 <font color="800,000"(talk</font>)] • [[WP:OMT <font color="800,000""majeatic titan)</font></font> <font style="font-family: 비발디"][사용자:인텔리전트시움 <스팬 스타일="컬러:#013220">인텔리전트</span]"[사용자_talk:Intelligentsium <span style="색상:검정색" sium[/span]"'</font> <font color=""""blue"][User_talk:노에티카 '''''''''''''큰'아니, 큰일났다![/작음][사용자] :[Noetica T]</sup] [[사용자:루어피쉬 루어피쉬] ''[사용자 대화:루어피쉬 <하위색></하위색></하위색></하위색></하위색></하위색>>''<하위색="#A20846">1998-[사용자:재무부 태그 재무부]][[사용자 대화:재무부 태그]]]►[특수]기여/TreasuryTag <span style="cursor:help;" directorate</span>]-delp[사용자:나사볼23 <퐁색="0000EEE">sc</font><font color="4169E1">r</font><font color="00B2EE"ew</font color="FF6600">ba</font><font color="FFFF00"><font color="9400D3">23</font>] [[사용자 대화:스크류볼23토크] [font color="32CD32"][사용자:제스키에 쿠리아노 제레미]'</font> <font color="4682B4"([사용자 대화:제스케 쿠리아노 v^_^v] [[특수:기부금/제스케 쿠리아노 보리보리보리보리보리보리보리보리!]</sup> [[사용자:M[font size="-3"] 매셈 M[font size="-3"]ASEM[/font] ([사용자 대화:마셈 t]]) <스팬 스타일="경계:2px 솔리드 블랙;백그라운드:흑색;-웹킷-경계 반지름:16px;-moz-경계 반지름:16px;색:흰색;폭:20px;높이:20px")[사용자 대화:플라잉디도트 <flingidiot <font color="white"</font>]</span 스타일="position:top:12px;왼쪽:-20px;"[user:flingidiot <font color="black"]</span][사용자:플로이드 <퐁색="#5A5"AC5">ʄɭoia>[/font]''<sup>[User_talk:플로이드 <퐁색="#3호AAA3A"[/font][sub][sub]기여/플로이드식 <퐁색="#3AAA3A"[/font]]

쉬운 것을 몇 개 빠뜨렸다페이지를 지금과 비교하여 페이지를 마쳤을 때 같은 모양(또는 더 나은 모양)으로 표시해야 한다는 점에 유의하십시오.그 페이지에는 더 많은 종류의 린터 오류가 있지만, 서명에 있는 글꼴 태그를 자동 또는 반자동 방식으로 한 번에 고칠 수 있다면, 그것은 탁월할 것이다.나는 위의 페이지를 세미랜덤으로 선택했다. VPT 페이지에는 흥미로운 서명이 많이 있는 경향이 있다는 것을 알고; 이 정도의 복잡성을 가진 수천 개의 토론 페이지가 있다.– Jonsey95 (대화) 05:56, 2022년 3월 3일 (UTC)

비활성 봇 - 2022년 2월

마자바 보고서에 따르면 우리는 정의상 비활성 봇(계정과 운영자 모두 2년 동안 편집하지 않은 것)이 몇 개 있는 것 같다. (마자바, 목록에 있는 운영자가 있다면 그 기여금 같은 것을 받아서 보고서에 추가해 주시겠습니까?어쩌면 상호 활동을 나타내는 칼럼도 있을 수 있다. 예를 들어, 둘 다 없는 곳에서는 {{cross}, 둘 다 있는 곳에서는 {{check}}.이것은 고통스러웠다.:)

보류 중인 제거

전진전망

그리고 한 달여 만에 몇 개 더:

• 디스펜서에서 실행되는 PDFbot
• Makecat이 운영하는 Makecat-bot
• TAP 앤티크 펜이 운영하는 TAP 봇
• Bgwhite가 운영하는 BG19봇
• Andrew Su 및 JulialTurner에서 운영하는 ProductionBoxBot(차단됨)
• TheMagikBTheMagikCow에서 운영하는 OT

장기 비실행이지만 정책 외부는 아님

우리는 활성 봇 운영자들에게 조금 전 이후로 편집하지 않은 나머지 봇 계정들(숫자 선택, 일반적으로 5년 정도 괜찮은 것 같음)이 여전히 봇 깃발이 필요한지 물어보는 것을 고려해야 한다.이것들은 특히 눈에 띄는...:

• SprinterBot은 RscprinterBot으로 리디렉션됨

  교환원이 좌회전해서 퇴역할 수 있는지 확인해봐— xaosflux 14:25, 2022년 2월 1일(UTC)

  특수: 운영자 요청별로 제거됨:Diff/1069313440. — xaosflux 18:02, 2022년 2월 1일(UTC)

• CeraBot은 Cerabot~enwiki로 리디렉션됨

  교환원이 좌회전해서 퇴역할 수 있는지 확인해봐— xaosflux 14:27, 2022년 2월 1일(UTC)

• 인용 봇 1, 인용 봇 2, 인용 봇 3, 인용 봇 4가 요약되어 있는가?인용봇별
• 유용한 픽시봇 및 펨토봇(현재 운영자가 차단됨)
• 레고봇 II(막힘)
  • 봇 깃발을 자유롭게 제거하십시오.레고크™ (대화) 17:58, 2022년 2월 4일 (UTC)
  • 제거됨 - Xaosflux 21:58, 2022년 2월 11일(UTC)
• TohaomgBot(차단)
• 카스파봇(차단)
• FRadical Bot(차단 및 운영자 CU차단)

  제거됨 - xaosflux 10:42, 2022년 2월 1일(UTC)

• 사이데봇(차단)

토론

이 과일들은 저열한 과일처럼 보이지만, 나머지는 역시 질의를 해야 한다고 생각한다.이즈노 (대화) 05:30, 2022년 2월 1일 (UTC)

이것은 사실 내가 만들려던 제안의 주제였습니다. 나는 봇 유지자들의 위키 활동을 감시하는 봇 작업에 유용할 수도 있다고 생각한다."마지막 편집 날짜" 또는 "최근 180일 동안의 편집" 또는 이러한 줄에 따라 중앙 상태 페이지나 봇 사용자 페이지의 infobox에 표시될 수 있다.종종, 봇의 작가들과 유지 관리자들은 오랫동안 활동을 하지 않을 것이다. 그래서 그들이 블랙홀에 빠질 가능성이 높기 때문에 버그를 보고하거나 새로운 기능을 제안하는 것은 약간 실망스럽다.Sjp×g 07:45, 2022년 2월 1일(UTC)

이것은 좋은 생각처럼 보이지만, 우리가 실제로 가지고 있지 않은 것, 즉 모든 봇:운영자 관계의 프로그램적 나열에 의존한다.나는 실제로 이것을 위한 페이지/테이블을 보고 싶다.(이것은 또한 주기적으로 마지막 편집/조치 날짜와 함께 봇-수정될 수 있다.) 그러나 부트스트래핑에는 약간의 노력이 필요하다.— xaosflux^Talk 10:53, 2022년 2월 1일(UTC)

최근에 승인받은 BRFA를 무작위로 몇 개 고르면, 2013년부터 현재까지 비교적 일관되게 포맷된 "운영자:"라는 이름을 가진 것으로 보인다. -- 이걸 대충 훑어보고 뭔가를 생각해 낼 수 있을 것 같다.수작업으로 검증해야 할 사안일 수도 있지만 뭔가 될 것 같아. jp×g 11:36, 2022년 2월 1일(UTC)

지옥, 2007년도의 이 것도 운영자가 같은 방식으로 메모해둔 것 같아. jp×g 11:38, 2022년 2월 1일(UTC)

좋은 생각이 있어. 그래도 네 생각이 더 나을지도 몰라.주인 페이지에 봇 사용자 박스가 게시되어 작동 중인 봇을 매개 변수 중 하나로 표기하는 것도 있다.예:{{Template:User bot owner Acebot}} . 아마 봇의 페이지에는 사용자 박스나 템플릿도 있을 겁니다.또한 이러한 템플릿은 다음과 같은 범주를 채운다.위키백과 봇 운영자.–Novm Languageae(토크) 11:43, 2022년 2월 1일(UTC)

그것은 다소 관련이 있을 뿐인데 나는 현재 승인된 봇 작업 목록을 보고 싶다.카테고리에는 많은 페이지가 있다.승인된 위키백과 봇 승인 요청. 그러나 여기에는 완료, 비활성화된 작업, 쓸모없어진 작업, 합의 변경, 봇 중단 등이 포함된다.

유용한 방법은 클로징 BAG가 작업 특성(예: 편집/조치 요약의 작업 번호)을 위키백과에 추가하는 것이다.봇 활동 모니터가 앞으로 나아가면, 그렇게 될 겁니다.그러면 아마도 오래된 업무들은 임시방편으로 추가될 수 있을 것이다.미루는 Reader (대화) 12시 40분, 2022년 2월 1일 (UTC)

현재로선 소급 분류가 가능한 "향후"가 될 가능성이 높지만, 우리는 항상 과제의 "편집 기간" 섹션에 근거할 수 있다. 만약 그것이 일회성 실행이라면, 그렇게 분류하고, 그렇지 않으면 그것을 일종의 "옹구잉" 하위 캣에 넣을 수 있다.프라임팩(대화) 20:53, 2022년 2월 1일(UTC)

• 첫 번째 배치로 작업자 공지사항을 남겼는데, 일주일 내에 응답이 없으면 삭제하여 {{returned bott=yes}}}로 표시하겠다.— xaosflux 10:47, 2022년 2월 1일(UTC)

• Xaosflux: 스프린터봇에 관해서, 나는 이 봇의 작업을 부활시킬 현실적인 가능성은 거의 없다고 믿으니, 자유롭게 계정을 폐기하십시오.Rcsprinter123 (토론) 17:32, 2022년 2월 1일 (UTC)

사용자:에 열을 추가했다.나열된 운영자에 대해 마지막으로 기록된 활동(편집 또는 공개적으로 기록된 조치)에 대한 MazavahBot/Bot 상태 보고서마자바 (토크!) 11시 5분, 2022년 2월 1일 (UTC)

반자동화를 위한 편집에 대한 질문

나는 최근에 헬프 데스크에 글을 올렸다(위키피디아:헬프 데스크#반자동 편집에 대한 봇 정책 혼동) 여기서 반자동 편집에 어떻게 접근/실행해야 하는지에 대한 나의 혼란에 대해 설명하였다.원한다면 내가 링크한 부분을 읽어도 된다.간단히 말해서, 나는 내가 실행 중인 스크립트에서 편집 내용을 반자동화하고 싶다.나는 봇 계정을 만들고 싶지 않으며 편집한 내용을 내 메인 계정에 올리고 싶다(API에 익숙해지면 스크립트를 확장하는 것을 고려하고 봇 생성을 검토할 수도 있다).

내 요구사항은 간단해 보인다.그러나 mw에 따르면:API:편집하려면 CSRF 토큰이 필요하지만, 쉽게 할 수 없는 것 같아.mw.user.tokens.get( 'csrfToken' )그리고 그것을 효과가 없는 날이라고 부른다.코드 샘플이 보여주듯이, 4단계 과정이 있다.좋아, 하지만 두 번째 단계(lgname+lgpassword+lgtoken이 있는 POST)는 Special:BotPasswords라고 명시된 BotPasswords 봇 암호를 만들기 전에 소유자의 계정이 아닌 봇의 계정에 로그인했는지 확인하십시오. , 그리고 WP:SEMIAUTOMATED, BRFA를 통해 작업이 수행되지 않는 한 봇 계정을 보조 편집에 사용하면 안 된다.그래서, 나는 봇 계정을 사용해서는 안 되지만, 그것이 내 것이 될 수 없다는 것을 암시하는 것처럼 보이는 계정의 '봇 암호'가 여전히 필요해?

사이드 노트:MediaWiki JS 샘플 코드는 정상 작동한다.하지만 내가 이것에 대해 좋아하지 않는 것은 그것이 위키에 있는 JS 콘솔에서 이루어져야 한다는 것이다.나는 터미널에서 스크립트를 실행하는 것이 훨씬 더 좋다.노드 사용JS/피톤).

사이드 노트: 내가 너희들을 여기에 둔 동안, 누군가가 나에게 ReFill이 달성한 기능들을 어떻게 달성하는지 설명해줄 수 있는 문서들을 가르쳐 줄 수 있을까? ReFill이 달성한 기능들을 변경하지 않고 몇 가지 변화를 보여주는 페이지로 너를 보내줄 수 있을까?내 스크립트는 통계를 업데이트하는데, 내가 반자동화 중이기 때문에 스크립트가 실행된 다음 차이점을 표시하여 스크립트가 수행한 작업을 시각적으로 확인한 다음 변경 사항을 게시할 수 있으면 좋겠다.새트리시어 (대화) 16:09, 2022년 2월 20일 (UTC)

나는 어렴풋이 비슷한 일을 왁스로 하는 것 같아.IANA는 정기적으로 언어 하위 태그 등록 파일을 업데이트한다.내 AWB 스크립트가 해당 파일을 읽고 모듈을 업데이트하는 경우:언어/데이터/iana 언어, 모듈:언어/데이터/iana 스크립트, 모듈:언어/데이터/iana 영역, 모듈:언어/데이터/iana 변형 모델, 모듈:언어/데이터/iana 억제 스크립트 및 모듈:하위 태그 레지스트리의 언어/데이터/ISO 639-1.완전히 자동화되지 않았기 때문에 각 모듈의 업데이트를 수동으로 저장하기 전에 변경 사항이 약간씩 변경되는 것을 볼 수 있다. 이 모든 것은 awb 내에 있다.그래서, 여러분은 그것을 옵션으로 고려하는 것이 좋을 것이다.

—스승 (대화) 16:44, 2022년 2월 20일 (UTC)

조언해줘서 고마워!나는 AWB가 그것을 할 수 있는지 몰랐고, 나는 그것을 탐구할 가치가 있는 옵션으로 보았다.그게 사실 내 문제에 대한 가장 좋은 해결책이 될 수도 있지만.나는 여전히 API를 사용하여 어떻게 이것을 달성할 수 있는지에 대해 다른 사람들로부터 듣고 싶다.단지 내가 이것을 내가 제한한다고 느끼는 도구를 사용하지 않고 내가 직접 하는 것을 선호하기 때문에.하지만 당신은 나에게 미래의 어느 시점에서 AWB를 시험해보라고 확실히 설득했다:p 새트리시우스 (토크) 17:25, 2022년 2월 20일 (UTC)

특수:BotPasswords는 편집하려는 계정에 로그인할 때 사용한다.그것은 보통 대규모 편집 작업을 위한 전용 봇 계정이지만, 당신의 경우("반자동화")는 당신 자신의 계정일 뿐이다.참고로 봇 프레임워크를 사용하고자 할 것이다(mw:로그인, 세션 유지, 토큰 처리 등을 위해 보일러플레이트 코드를 쓰지 않아도 되는 API:클라이언트 코드#JavaScript)– SD0001 (대화) 19:01, 2022년 2월 20일 (UTC)

설명해줘서 고마워!내 질문에 대한 답이 나온 것 같아.변경하기 전에 API가 어떤 API를 호출하여 diff를 표시하는지(reFill이 하는 대로) 알고 싶다.내가 이걸 어떻게 이룰 수 있을까?새트리시어 (대화) 05:08, 2022년 2월 21일 (UTC)

이와 같이(사용자로부터 수신:Novm Languageae/스크립트/DraftCleaner.js):

기능을 발휘하다 GoToShowChangesScreen(제목NamespaceAndUnderscores, 위키코드, 편집요약) {  하게 하다 제목인코딩됨 = 인코드URIComentor(제목NamespaceAndUnderscores);  하게 하다 wg서버 = mw.구성.얻다('wgServer');  하게 하다 wgScript 경로 = mw.구성.얻다('wgScriptPath');  하게 하다 베이스URL = wg서버 + wgScript 경로 + '/';  // https://stackoverflow.com/a/12464290/3480193  $(<<폼 액션=>${베이스URL}색인.php?title=${제목인코딩됨}&action=method=" method="POST"/>")   .덧셈을($('<input type="hidden" name="wpTextbox1" >).발랄하게 하다(위키코드))   .덧셈을($('<입력형="숨겨진" 이름="wpSummary" >).발랄하게 하다(편집요약))   .덧셈을($('<<proble type="proble" name="mode">).발랄하게 하다('preview'))   .덧셈을($('<입력형="숨겨진" 이름="wpDiff">).발랄하게 하다('변경사항 표시'))   .덧셈을($('<input type="hidden" name="wPultimateParam">').발랄하게 하다('1'))   .부록($(문서화하다.보디)) //그것은 <몸> 어딘가에 더해져야 한다.   .제출하다(); } 

- 콰르페즈클틀톡 07:15, 2022년 2월 21일 (UTC)

@Qwerfjkl:됐다!정말 고마워, 정말 고마워.새트리시어 (토크) 07:32, 2022년 2월 21일 (UTC)

이 문제는 이미 해결되었다.새트리시어 (토크) 07:32, 2022년 2월 21일 (UTC)