영어 위키백과에서 봇을 운영하려면 먼저 승인을 받아야 한다.이렇게 하려면 아래 지침에 따라 요청을 추가하십시오.만약 여러분이 프로그래밍에 익숙하지 않다면, 다른 사람에게 여러분 자신을 위해 봇을 운영하도록 부탁하는 것이 좋은 생각일 것이다.

봇 연산자를 위한 지침

I

승인 신청 전

봇 정책을 읽었으며 봇이 정책을 준수하는지, 그리고 자주 거부되는 봇으로 나열되지 않았는지 확인하십시오.
작업이 논란이 될 수 있는 경우(예: 기사를 비유지관리 편집하는 대부분의 봇과 사용자 대화 페이지에 메시지를 게시하는 대부분의 봇) 해당 포럼에서 해당 작업에 대한 합의를 구하십시오.WP:빌리지 펌프(제안)와 관련 정책, 지침, 템플릿 및/또는 위키프로젝트의 토크 페이지 등이 공통적으로 출발한다.승인 요청에서 이 토론에 연결하십시오.
아직 봇 계정을 생성하지 않았다면 봇 계정을 만들어야 할 것이다.계정을 만들려면 로그인 시 여기를 클릭하십시오. (로그인 중에 봇 계정을 만들지 않으면 소유권을 확인할 때까지 가능한 sockpuppet 또는 인증되지 않은 봇으로 차단될 가능성이 있음)
사용자 페이지에 연결하고(일반적으로 {{bot} 템플릿을 사용하여 수행됨) 그 기능을 설명하는 봇의 사용자 페이지를 만드십시오.혹시라도 이상이 생길 경우를 대비해서 '비상 차단 버튼'도 넣을 수 있다.

II

애플리케이션 파일링

쉬운 brfa.js는 BRFA를 신속하게 접수하는 데 사용될 수 있다.그것은 자동적으로 많은 서류철 실수를 확인한다!경험이 풍부한 봇 운영자에게 추천하지만 대본은 누구나 사용할 수 있다.

아래 상자에 봇의 사용자 이름을 입력하고 버튼을 클릭하십시오.추가 작업에 대한 요청인 경우 작업 번호(예:BotName 2).
결과 페이지의 질문을 완료하고 저장하십시오.

이제 요청을 기본 승인 페이지의 올바른 섹션에 추가하십시오.여기를 클릭하여 설명선 바로 아래 목록의 맨 위에 {{BRFA}}을(를) 추가하십시오.
- 첫 번째 요청의 경우: 사용{{BRFA bot name Open}}
- 추가 작업 요청의 경우: 사용{{BRFA bot name task number Open}}

III

승인 프로세스 중

프로세스 중에 승인 그룹 구성원은 봇에 대한 평가판을 승인하고(일반적으로 커뮤니티 입력 시간을 허용한 후) 요청을 이 섹션으로 이동시킬 수 있다.
지정된 편집/시간 동안 봇을 실행한 다음 요청 페이지에 {{BotTrialComplete}}을(를) 추가하고 봇에 적용되는 {{BRFA} 템플릿(또한 봇의 기여도에 링크하고 발생 가능한 오류에 대해 코멘트)을 이동하여 요청을 'trial complete' 섹션으로 이동하십시오.
요청이 간과되고 있다고 생각될 경우(~1주일간 BAG 주의 없음) {{B를 추가할 수 있다.페이지에 AG 지원이 필요함.하지만, 모든 코멘트가 끝난 후에는 사용하지 마십시오!
승인 과정 중 언제든지 봇의 승인 페이지에 {{BotWithgrad}}을(를) 추가하여 요청을 철회할 수 있다.

IV

승인 프로세스 후

재판 편집이 검토되고 충분한 시간이 경과한 후, BAG 회원은 요청을 적절히 승인하거나 거부할 것이다.
- 승인된 요청의 경우:그 요청은 여기에 기재될 것이다.필요한 경우, 관료는 2, 3일 이내에 봇에 플래그를 지정하며, 당신은 그 작업을 완전히 실행할 수 있다(최근의 변경사항을 복잡하게 하지 않도록 깃발을 기다리는 것이 가장 좋다).봇에 이미 깃발이 있거나 깃발이 없는 상태로 실행하려는 경우, 준비되면 작업을 시작할 수 있다.
- 거부/만료/미사용 요청의 경우:요청은 관련 섹션의 BRFA 메인 페이지 하단에 나열된다.

봇 이름	상태	창조했다	마지막 편집기	날짜/시간	마지막 BAG 편집기	날짜/시간
드네오봇 (T C B F)	개방하다	2022-03-06, 12:53:05	네오 더 트윈	2022-03-06, 15:17:04	프라임팩	2022-03-06, 15:08:10
콰르프클 (봇) 8 (T C B F)	개방하다	2022-03-01, 18:15:04	콰르프클	2022-03-01, 19:21:35	BAG에서 편집하지 않음	n/a
비스카봇 (T C B F)	개방하다	2022-02-27, 05:11:36	비스카	2022-02-28, 02:19:29	프라임팩	2022-02-27, 13:51:06
가정봇 (T C B F)	대기 중	2022-02-16, 11:35:09	프라임팩	2022-02-27, 13:54:27	프라임팩	2022-02-27, 13:54:27
게일런 봇 2 (T C B F)	개방하다	2022-02-07, 12:07:35	아노미	2022-03-01, 12:50:31	아노미	2022-03-01, 12:50:31
자베스봇 (T C B F)	대기 중	2022-01-15, 22:43:07	프라임팩	2022-02-16, 12:39:30	프라임팩	2022-02-16, 12:39:30
엘리봇 (T C B F)	대기 중	2021-01-23, 14:46:12	헤노르	2022-02-08, 18:20:15	미루는 판독기	2021-11-08, 01:07:48
베어리프봇 (T C B F)	연장 평가판	2022-01-20, 21:37:46	브라운헤어드걸	2022-03-06, 06:14:28	프라임팩	2022-02-13, 14:35:48
IndentBot (T C B F)	평가판 완료	2021-10-15, 03:20:20	데이비드 엡스타인	2022-02-27, 20:26:29	프라임팩	2022-02-27, 14:18:35

현재 승인 요청

드네오봇

연산자: 네오 더 트윈 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 3월 6일 일요일 12시 52분(UTC)

기능 개요:봇은 국가 형식에 따라 날짜 형식과 국가 영어를 업데이트하는 데 사용될 것이다.

자동, 감독 또는 수동:감독됨

프로그래밍 언어: Java

사용 가능한 소스 코드:

관련 토론에 대한 링크(해당하는 경우):

기간 편집 계속:

영향을 받는 예상 페이지 수: 12000개

네임스페이스:기사 공간 & 드래프트 공간

제외 준수(예/아니오):아니요.

기능 세부 정보:봇은 자동으로 {{Use mdy date}, {{Dmy date}} 템플릿뿐만 아니라 국가 영어(예: {{남아공 영어 사용}, {{미국 영어 사용}})를 배치한다.봇은 {{Bot} 템플릿으로 태그가 지정된 사용자 페이지나 페이지가 아닌 기사에서만 작동된다.

토론

최근 나는 미국이 먼저 달을 사용하기 때문에 적절하지 않은 날짜 형식을 가진 {{dmy date}}라는 미국 기반 기사를 많이 접하게 되었다.국가별 특정 기사에 필요한 영어 유형({{남아공 영어 사용})을 명시하는 것도 적당할 것이다.

특정 기사에 적합한 태그를 어떻게 결정할 것인가?니키마리아 (대화) 13:51, 2022년 3월 6일 (UTC)

니키마리아(Nikkimaria), 봇은 태그가 필요한 기사를 감지하고, 특정 기사가 {{미국식 영어 사용}} 템플릿으로 태그가 지정되면 날짜 형식 {{미디 날짜 사용}}}}을 추가한다.국가별 영어의 종류는 "릴 웨인은 미국 래퍼, 고약한 C는 남아공 녹음 아티스트"와 같은 기사의 지하를 감지하게 되며, 따라서 봇은 어떤 기사에 어떤 태그를 붙여야 하는지 알게 될 것이다.네오 더 트윈 (대화) 14:55, 2022년 3월 6일 (UTC)

설명:이 작업에는 컨텍스트B가 있을 것 같다.OT 문제.FWIW, 이 제안된 봇 운영자는 총 1,500개의 편집본을 가지고 있다.– Jonsey95 (대화) 14:56, 2022년 3월 6일 (UTC)
동의해, 그리고 운영자가 바로 위에 언급한 내용은 그들이 그것을 극복할 수 있을 것이라는 확신을 주지 못해.프라임팩 (대화) 15:08, 2022년 3월 6일 (UTC)
좋은 아이디어가 제안된다면 편집이 정말 중요한가?나는 얼마 동안 있어왔고 이 봇이 적절할 것이라는 것을 깨달은 것은 내 위키 경험에 관한 어떤 것을 의미해야 한다.이쯤에서 재판을 해주면 고맙겠다.네오 더 트윈 (대화) 15:13, 2022년 3월 6일 (UTC)

콰르프클 (봇) 8

연산자: 콰르프클 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 3월 1일 화요일 18시 15분(UTC)

자동, 감독 또는 수동: 자동

프로그래밍 언어: JavaScript

사용 가능한 소스 코드: 사용자:Qwerfjkl (봇)/코드/8

기능 개요:미국 카운티 대통령 선거 결과 문서화

관련 토론에 대한 링크(해당하는 경우): 위키백과:봇의뢰 #미국군수선거 결과의 마무리 템플리트화

기간 편집: 한 번 실행

영향을 받는 예상 페이지 수: <3000개

제외 준수(예/아니오):아니요.

봇 플래그가 이미 있음(예/아니오):네

기능 세부 정보:모든 미국 카운티 대통령 선거 결과를 위키피디아 마크업(펜실베이니아주 엘크 카운티 등)에서 {{PresHead}, {{PresRow}}, {{PresFoot}}(일리노이주 쿡 카운티 등)을 사용하여 템플릿 형식으로 변환하십시오.regexps가 불완전하므로 코드는 테이블이 필요한 형식과 일치하는지 확인하고, 그렇다면 저장한다.

토론

비스카봇

연산자: 비스카 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 2월 27일 일요일 05:11 (UTC)

자동, 감독 또는 수동: 자동

프로그래밍 언어:AutoWikiBrowser

사용 가능한 소스 코드: AWB

기능 개요:PMC 서식으로 인한 CS1 오류 수정

관련 토론에 대한 링크(해당하는 경우):

기간 편집:가능한 한 연속적으로

영향을 받는 예상 페이지 수: 하루에 약 10-30페이지

제외 준수(예/아니오):네

봇 플래그가 이미 있음(예/아니오):아니요.

기능 세부 정보:이것으로 알 수 있다. pmc=PMC로 대체한다. pmc= 카테고리의 각 문서에 대해:CS1 maint: PMC 형식.또한 각 기사에 대한 일반적인 AWB 수정사항(오타가 아님)을 실행할 수도 있다.일부 예: [1][2][3]

토론

호기심에 코멘트만 해도 2022년 2월 27일(UTC) 13시 51분 현재 이 카테고리에 3페이지가 있다."라이브" 카운트는 3이다.프라임팩 (대화) 13:51, 2022년 2월 27일 (UTC)

카테고리는 User:인용 봇, 그러나 그 봇은 청소할 때마다 누군가가 수동으로 범주에 대해 트리거해야 한다.이 새로운 봇은 봇과 봇 자체를 수동으로 유발하는 사람들로부터 스트레스를 받을 수 있는데, 이것은 인용구에 다른 정보를 추가하기 위해 더 의도된 것이다.비소이카 (토크 · 기여) 14:23, 2022년 2월 27일 (UTC)

우리는 BRFA 동안 대부분의 독자들에게 이것은 일반적으로 숨겨져 있는 오류 메시지와 숨겨진 카테고리를 제거하기 때문에 외적인 변화가 될 것이라는 것을 인정해야 한다.나는 그 일을 지지하고, 봇은 BRFA 승인을 받아 외관 변경을 할 수 있지만, 편집자들은 렌더링된 페이지의 변화를 보지 못하기 때문에 승인된 BRFA 이후에도 봇 편집을 반대하기도 한다.– Jonsey95 (대화) 14:33, 2022년 2월 27일 (UTC)

물론, 나도 동의해.BRFA 과정을 거치면서 봇 계정의 깃발과 AWB 액세스 권한을 얻어서 이걸로 어떤 워치리스트도 범람시키지 않을 겁니다.비소이카 (토크 · 기여) 18:39, 2022년 2월 27일 (UTC)

현재 카테고리에는 한 페이지밖에 없기 때문에, 이것은 어느 누구도 알아채지 못할 대량의 작업이 아닐 수도 있다.모두 미리보기로 이 메시지를 보셨나요?

Script warning: One or more {{cite journal}} templates have maintenance messages; messages may be hidden (help).

나는 "코스메틱" 문제에 대한 그러한 미리보기 경고가 상당히 짜증나는 것이라고 생각하며, 그것들을 없애게 하는 봇들이 있다면 행복할 것이다.인간의 땅속은 늪에 빠져서 이런 편집 작업을 할 시간이 없다.봇이 카테고리를 정리할 수 있음:CS1 maint: url-status?wbm1058 (talk) 01:44, 2022년 2월 28일(UTC)

응, 이 카테고리는 수작업으로 꽤 규칙적으로 정리된 것 같아, 내 예상은 하루에 10-30페이지 정도야.다른 범주에 대해서는, 아마도 이런 단순한 발견/교체가 아닐 것이다. 하지만 나는 다른 사람이 하지 않는다면, 미래에 언젠가 그것을 위해 뭔가 일을 할 수 있을 것이다.비소이카 (토크 · 기여) 02:17, 2022년 2월 28일 (UTC)

가정봇

연산자: 이스케이드굿와이스 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 2월 16일 수요일 11시 34분(UTC)

기능 개요:초안에 AFC 미제출 템플릿 추가.

자동, 감독 또는 수동:자동

프로그래밍 언어:파이톤

사용 가능한 소스 코드: 이게 먹힐 것 같아?

관련 토론에 대한 링크(해당하는 경우): 위키백과:마을 펌프(제안) § Bot 제안서(AFC 제출 템플릿)

기간 편집:연속적인 것을 의미했다.

영향을 받는 예상 페이지 수: 새 페이지 피드(오늘 약 250개)로 판단하여 AFC 템플릿이 없는 초안이 많지 않은 것으로 가정하여 하루에 100장까지 작성

네임스페이스:초안

제외 준수(예/아니오):예(피위키봇)

기능 세부 정보:AFC 미제출 템플릿({afc 제출/초안})을 포함하지 않은 드래프트 공간, {{draft 아티클} 템플릿 또는 현재 이 2개로 리디렉션되는 모든 드래프트에 추가한다.위에 나열된 VPR 제안서의 예를 참조하십시오.

토론

피드백과 다른 의견만 허락한다면 나는 이것을 완전히 거절하지는 않을 것이다. 그러나 모든 초안이 AFC를 통과해야 하는 것은 아니다. 따라서 모든 초안에 봇을 배치하는 것은 매우 문제가 있다.프라임팩(대화) 12:22, 2022년 2월 16일(UTC)
대기 중.(내가 링크를 고친) RFC가 완료될 때까지.앞으로는 요청을 하기 전에 합의를 이끌어내라.프라임팩(대화) 12:22, 2022년 2월 16일(UTC)

@Primfac: 이것이 오해인지는 확실하지 않지만, 제출된 템플릿이 아니라 제출되지 않은 템플릿(템플릿:afc 제출/초안)이다.— ImpleGoodWraith (대화 • 기여) 12:28, 2022년 2월 16일(UTC)에 의해 추가된 이전의 서명되지 않은 논평

나도 알아, 그리고 내 요점은 여전히 남아있어 - 모든 초안이 AFC에서 검토를 위해 보내진 것은 아니니까, 그래서 모든 초안에 템플릿을 추가하는 것은 문제가 있어.프라임팩(대화) 12시 38분, 2022년 2월 16일(UTC)

@Primfac:나는 당신이 그 제안을 "검토를 위해 모든 새로운 초안을 자동으로 제출"하는 것으로 해석했다고 생각했다.

나는 RFC를 기다릴 것이다. – 가정 GoodWraith (대화 기여) 12:49, 2022년 2월 16일 (UTC)

참고: 이 BRFA가 제출된 이후 이 봇을 편집한 것으로 보인다.봇은 시험 승인을 받거나 승인되지 않는 한 자신의 사용자 공간이나 운영자의 사용자 공간 밖에서 편집할 수 없다.아노미비OTC 12:41, 2022년 2월 18일(UTC)
나는 BAG 회원은 아니지만, 여러 가지 이유로 당신의 코드가 당신이 기대하는 대로 작동하지 않을 것이라는 점을 지적하고 싶다.
먼저 파이톤이 해석할 것이다."{{afc submission".lower(),"{{articles for creation".lower(), 등(항상 별개의 것 True, 즉, 실제로 고려되는 유일한 조건은"{{draft article}}".lower() not in page.text.
또한, 당신의time.sleep 호출은 루프를 벗어나서 실행되지 않을 것이다.Bsoyka(대화 · 기여) 04:59, 2022년 2월 25일(UTC)
승인되면 알아내겠다.– AssemeGoodWraith(대화 기여) 05:09, 2022년 2월 25일(UTC)
…아니면 지금이라도.– AssemeGoodWraith(대화 기여) 05:09, 2022년 2월 25일(UTC)
네, 만약 코드에 오류가 있다면, 알려진 버그를 수정해야 하기 때문에 요청을 더 연기하는 것은 의미가 없기 때문에 빠른 시일 내에 해결하십시오.프라임팩 (대화) 13:54, 2022년 2월 27일 (UTC)

게일런 봇 2

연산자: 게일란 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 2월 7일 월요일 12시 7분(UTC)

자동, 감독 또는 수동: 자동

프로그래밍 언어: JS, 러스트

사용 가능한 소스 코드: 현재 약간 엉망이지만 요청에 따라 게시할 수 있음

기능 개요:파일 페이지에서 해당 파일을 더 이상 사용하지 않는 페이지에 대해 {{fair use regional} 및 친구를 제거하십시오.

관련 토론에 대한 링크(해당하는 경우):위키백과:Bot_requests#Remove_redundant_FURs_from_file_pages

기간 편집: 지금 한 번 실행

영향을 받는 예상 페이지 수: < 5,842개

제외 준수(예/아니오):아니요.

봇 플래그가 이미 있음(예/아니오):아니요.

기능 세부 정보:많은 파일 페이지에는 더 이상 필요하지 않은 공정한 사용 합리성이 포함되어 있다.예를 들어 파일:애플IGOS.png는 팔레트(컴퓨팅)용 FURE를 가지고 있지만, 그 기사는 실제로 그 이미지를 사용하지 않는다.이 봇은 그러한 경우를 다음과 같이 찾아낸다.

xml 덤프 및 parse_wiki_text를 사용하여 문서 매개변수가 있는 이러한 템플릿 중 하나를 포함하는 모든 파일: 페이지를 찾는다.
이 쿼리의 결과(및 xml 덤프에서 추출된 리디렉션 목록)와 교차 확인하여 사용되지 않는 FUR를 찾으십시오.

결과 데이터는 여기에 있다.이것들 몇 십 개를 직접 확인해 봤는데 괜찮아 보이더라.다음과 같은 경우가 있다.컨티넨탈 스퀘어.JPG는 실수로 잘못된 기사와 연결되는 FUR(FUR는 Continental Center로 연결되는 링크)를 가지고 있는데, 이 JPG는 이 봇에 의해 제거될 것이다.내 생각은 이것이 괜찮다는 것이다. - 이것은 PUR이 없는 것으로 플래그가 붙어야 하는데, 누군가가 그것을 역사에서 구할 수 있을까?확실하진 않다.

봇의 실제 편집 부분은 아직 구현되지 않았지만, 위에서 링크된 JSON을 루핑하기 위해 피위키봇이나 멍을 사용하는 것으로 구성되어야 하며, FUR가 여전히 존재하고 사용되지 않는지 다시 한 번 확인하여 제거해야 한다(이 시점에서 일주일이 지난 덤프로 작업 중이기 때문에).

일단, 이것은 일회성 실행일 뿐이다; 나는 그것을 계속 운영할 수 있는 효율적인 방법을 찾고 싶다. 하지만 우리가 그 점에 도달하면 새로운 BRFA를 신청하겠다.

토론

내 생각은 이것이 괜찮다는 것이다. - 이것은 PUR이 없는 것으로 플래그가 붙어야 하는데, 누군가가 그것을 역사에서 구할 수 있을까?하지만 누군가는 그럴까?아니면 어떤 다른 봇이나 봇 같은 인간이 와서 퍼가 부족하다고 꼬리표를 붙일까?공정 사용 봇은 역사적으로 매우 논란이 많았다는 것을 명심하라.그 대 그 일이 어느 정도까지 본질적인 것인가 하는 것은 내가 모르는 운영자의 태도 때문이었지만, 사람들은 여전히 전체 아이디어에 대해 예민한 반응을 보일지도 모른다.초기 버전을 봇의 편집 후에도 완전히 FURred 상태로 남아있을 이미지로 한정하는 것이 더 안전할 수 있고, 이미지에 태그를 붙이는 것 또한 인간의 주의를 위해 필요한 FUR이 부족할 수 있다(또는 현재로서는 무시한다).아노미에 12시 48분, 2022년 2월 7일(UTC)

추신: 만약 여러분이 그것을 계속 운영하기를 원한다면, 현재 버전은 인간이 기사에서 이미지를 제거했을지도 모르는 반달리즘을 되돌릴 수 있는 시간을 준다는 사실은 보존되어야 할 좋은 일이다.아노미에 12시 48분, 2022년 2월 7일(UTC)

나는 봇이 공정한 사용 합리성을 제거한다는 생각이 전혀 불편하지만, 적어도 그것은 공공 기물 파손과 페이지 이동, 합병, 분할을 설명해야 한다.페이지 이동 및 최소한 일부 합병의 경우, 봇은 대상 페이지에서 이미지가 사용되는 경우 리디렉션을 따르고 FUR를 업데이트해야 한다.RfD에서 리디렉션이 지명되었다면 봇은 여전히 리디렉션을 따라야 한다. 이동에서 리디렉션되는 대부분의 리디렉션은 유지되어야 하지만, 가끔 예외가 있고, 보통 자신이 유지되고 있는지 모르는 편집자와 FUR가 업데이트되어야 할 것임을 모르는 편집자 사이에 큰 중첩이 있을 것이다.어떻게 쪼개진 부분이 자동으로 감지될 수 있는지 모르겠다.사용하지 않는 PUR를 제거해야 한다는 공감대가 있다면, 봇이 다음과 같은 설명을 곁들여 토크 페이지로 옮기는 것이 훨씬 나을 것이다.

<날짜> 게일런봇은 이 이미지가 아래 템플릿에 열거된 글에 사용되지 않는 것을 발견했다.

이미지가 복원되었거나 다른 기사 또는 제목으로 이동되었으며 파일 페이지에 현재 위치에 대한 FUR(자유 사용 근거)가 없는 경우 아래 템플릿을 파일 페이지로 다시 이동하여 적절하게 업데이트하거나 새 FUR를 작성하십시오.
파일 페이지에 현재 모든 용도에 대한 PUR이 포함되어 있는 경우 수행할 작업이 없음.

봇이 뭔가 잘못됐다고 생각되면 <우선 접촉장소>에 자세한 내용이 적힌 메시지를 남겨주십시오."

Thryduulf (대화) 10:49, 2022년 2월 23일 (UTC)

이렇게 하면 잘못된 긍정을 너무 많이 만들지 않고도 BOTREQ에서 제시된 이슈를 효과적으로 처리할 수 있을 것이라는 의견과 이 제거 후 영상이 부적절하게 변경될 수 있는 상황을 충분히 볼 수 없다는 의견을 가진 사람들로부터 많은 신뢰를 받고 있지 않다.만약 이러한 문제들이 (봇 운영자가 위의 논평들 중 어떤 것에 대해서도 아직 응답하지 않았다는 것을 알음) 설명될 수 있다면, 논의는 더 진전될 수 있지만, 현재 나는 이것을 거절하는 쪽으로 기울고 있다.프라임팩 (대화) 13:58, 2022년 2월 27일 (UTC)

안녕. 미안해, 리얼라이프는 지난 몇 주 동안 많이 있었어.곧 이 문제로 다시 돌아오도록 노력하겠지만, 몇 가지 간단한 메모:

초기 버전을 봇의 편집 후에도 완전히 FURRED 상태로 유지되는 이미지로 제한하는 것이 더 안전할 수 있다.이것은 좋은 생각이다.만약 우리가 이것을 진행한다면, 적어도 하나의 다른 FUR가 있는 파일로 제한하고, 아마도 유효한 FUR가 없는 것처럼 보이는 페이지 목록을 별도로 유지 할 것이다.
페이지 이동 및 최소한 일부 합병의 경우, 봇은 대상 페이지에서 이미지가 사용되는 경우 리디렉션을 따르고 FUR를 업데이트해야 한다.이것은 부분적으로 수행된다: 만약 FUR가 리디렉션을 참조한다면, 그 리디렉션을 따르고, 대상 페이지를 고려한다.리디렉션 대상에 연결하도록 FUR을 업데이트할 생각은 없었지만, 어느 시점에서는 좋은 생각이 될 수도 있다.

한 가지 다른 가능성은, 그리고 나는 이것이 얼마나 많은 유용한 편집이 제외되는지를 알기 위해 데이터를 살펴본 적이 없는데, 이는 파일의 모든 현재 용도가 기존 FUR에 의해 가려질 때에만 FUR를 제거하는 것이다.(반반항체주의 지연과 함께) 유용한 PUR을 제거하는 것의 대부분의 문제를 제거해야 한다는 것. 모든 기존 용도에 적용된다면, 추가적인 PUR은 상당히 유용하지 않다고 생각한다.게일란 💬️ 23:30, 2022년 2월 28일 (UTC)

한 가지 다른 가능성은, 그리고 나는 이것이 얼마나 많은 유용한 편집이 제외되는지를 알기 위해 데이터를 살펴본 적이 없는데, 이는 파일의 모든 현재 용도가 기존 FUR에 의해 가려질 때에만 FUR를 제거하는 것이다.그것이 내가 "완전히 FURRED"라고 말하면서 제안했던 것이다.너무 크게 시작해서 뒤로 밀리는 것보다 작게 시작해서 확장하는 것이 더 쉽다.아노미에 12:50, 2022년 3월 1일(UTC)

자베스봇

연산자: 자베 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 1월 15일 토요일 22시 43분(UTC)

자동, 감독 또는 수동: 자동

프로그래밍 언어:파이톤

사용 가능한 소스 코드: pywikibot interwikidata.py 스크립트

기능 개요: 오래된 인터위클링크 정리

관련 토론에 대한 링크(해당하는 경우):

기간 편집: 1회 럼

영향을 받는 예상 페이지 수:계산하지 않았지, 아마 몇 번에서 몇 천번 사이일 거야.

제외 준수(예/아니오):네

봇 플래그가 이미 있음(예/아니오):아니요.

기능 세부 정보:옛 인터위킬링크를 담은 기사가 아직도 꽤 있다.나는 그것들을 치우고 싶다.봇은 기본적으로 모든 페이지를 거친 다음 해당 위키다타 객체에 기사가 링크되어 인터위키 링크와 충돌이 없는 경우 인터위키 링크를 제거한다.

토론

봇으로 어떤 편집을 할 것인지 예시나 세 가지 예를 들 수 있는가? (답장에 ping하지 마십시오) 프라임팩 (대화) 09:31, 2022년 1월 16일 (UTC)

참고: 이 BRFA가 제출된 이후 이 봇을 편집한 것으로 보인다.봇은 시험 승인을 받거나 승인되지 않는 한 자신의 사용자 공간이나 운영자의 사용자 공간 밖에서 편집할 수 없다.아노미비OTC 12:17, 2022년 1월 16일(UTC)

3번의 시험 편집을 했다([4 ], [5 ], [6]). --Zabe (토크) 12:18, 2022년 1월 16일 (UTC)

미안한데 내가 이걸 처음 물어봤어야 했어. 어떻게 이걸 찾고 있는지, 그리고 얼마나 많은 편집이 계획되고 있는지 좀 더 정확하게 알려줄 수 있니?프라임팩(대화) 19시 5분, 2022년 1월 16일(UTC)

나는 기사 네임스페이스의 모든 페이지를 훑어보고 있다.그게 안됐으면 xml 덤프가 필요할 것 같아. --Zabe (대화) 21:39, 2022년 1월 16일 (UTC)

편집 횟수는 조금 질의해야 하는데 --Zabe (토크) 21:41, 2022년 1월 16일 (UTC)

Zabe, 우리가 어떤 종류의 편집을 보고 있는지 알아낼 기회가 있었나?프라임팩 (대화) 14:01, 2022년 2월 13일 (UTC)

아니, 내가 시간을 낼 수 있을 때까지 이 요청을 주저하지 않는 것으로 표시해 줘. --Zabe (대화) 17:00, 2022년 2월 15일 (UTC)

대기 중.대기 중인 번호 크런치.프라임팩(대화) 12시 39분, 2022년 2월 16일 (UTC)

엘리봇

연산자: 엘리엇321 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2021년 1월 23일 토요일 14시 46분(UTC)

자동, 감독 또는 수동: 자동

프로그래밍 언어:

사용 가능한 소스 코드:

기능 개요:{{Redirect 카테고리 셸} 템플릿을 Wikidata로 리디렉션할 때 자동으로 적용하고, 중복 {{Wikidata 리디렉션} 템플릿을 제거한다.

관련 토론에 대한 링크(해당하는 경우):

기간 편집: 한 번 실행

영향을 받는 예상 페이지 수: 50,000-100,000

제외 준수(예/아니오):네

봇 플래그가 이미 있음(예/아니오):아니요.

기능 세부 정보:나는 최근에 {{Redirect 범주 셸}}을(를) 수정하여 Wikidata 링크를 자동으로 감지하고, 존재하는 경우 템플릿 {{Wikidata redirect}을(를) 적용했다.이것은 이미 보호수준으로 행해졌으며, {{Wikidata redirect}}도 적용해서는 안 될 이유가 없다.

카테고리에는 현재 100,000개의 리디렉션이 있음:소프트웨어에 의해 적용되는 Wikidata 항목에 연결된 리디렉션.카테고리에는 현재 30,000개의 리디렉션이 있다.위키다타는 리디렉션한다.이 중 거의 모든 것이 수동으로 {{Wikidata redirect}}을(를) 적용하여 해당 범주에 넣었는데, 이는 태그를 제거해야 함을 의미한다(중복될 것이므로).

나머지 7만 페이지 중 상당수는 {{rcat shell}이(가) 추가된 템플릿이 필요할 것이다.{{Redirect 카테고리 셸}}}으로의 변경이 최근이었기 때문에, {{Wikidata redirect}}은(는) 없지만 {{Redirect 카테고리 셸}이(가) 있는 Wikidata 항목에 연결된 많은 리디렉션이 카테고리에 추가되지 않았다.위키다타는 리디렉션한다.범주 간 카운트 차이:Wikidata 리디렉션 및 범주:Wikidata 항목에 연결된 리디렉션은 수정할 페이지 수입니다.

편집은 AWB가 자동화된 봇으로 실행되면서 진행된다.편집 횟수가 상당하지만 이 작업에는 중단의 위험이 매우 낮다.이 봇은 AWB를 사용하여 리디렉션하는 다른 일반적인 수정도 수행할 수 있지만, 이는 기능에서 중요한 부분은 아니다.

다소 비슷한 실패한 요청은 위키백과였다.Bots/Requests for Approval/TomBot. 그러나 그 요청은 전체적으로 혜택을 덜 받고 30~60배 더 많은 페이지를 편집하는 Bot에 대한 것이었다.이것은 훨씬 좁고 유용한 요청이다.

토론

이 작업에 대해 더 폭넓은 공감대를 형성할 수 있는 사전 토론이 있으십니까?
이 BRFA가 템플릿의 원인:Wikidata가 중복으로 리디렉션되는가?내가 제대로 이해한다면 이 일은 모든 전횡을 고아로 만들까?만약 그렇다면, 그리고 특히 사전 논의가 없다면, 나는 그 템플릿을 TfD에 보낼 것을 제안한다(그리고 나서 이 봇 작업은 기술적으로 TfD를 구현하는 것일 수 있다).그것은 또한 이 과제에 대한 더 넓은 합의를 시험하는 한 방법이 될 것이다.

RowlingReader (대화) 16:01, 2021년 1월 23일 (UTC)

이 특정한 과제에 대한 합의를 도출하는 것에 대해 내가 아는 논의는 없다.{{위키다타 리디렉션}}은(는) 두 가지 이유로 중복되지 않는다.{{redirect 카테고리 쉘}}}을(를) 복사한다.하지만, 물론, 이 용법은 변위될 수 있다.다른 용도는 위키와 범주 리디렉션, 즉 "소프트" 용도에 있다.그러나 "하드" 사용은 템플릿에서 더 이상 사용되지 않을 수 있다(자동 스위치로 약간 다르게 구현된다).엘리엇321 (토크컨트롤) 16:20, 2021년 1월 23일 (UTC)

우선, 스타일리시하게 이 발표는 열등하다고 말할 수 있다.예를 들어, 여기를 참조하십시오.맨 위에 있는 것(편집 때문에 생긴 것)은 매뉴얼처럼 보이지 않고 일반 텍스트와는 약간 어울리지 않게 보인다.

만약 rcat 셸을 봇에 의해 수동으로 추가해야 한다면, 정말 여기에 일리가 있는가?범주 내 페이지에 {{Wikidata 리디렉션}을(를) 추가하는 것이 어떨까?Wikidata 항목에 연결된 리디렉션?RowlingReader (대화) 00:39, 2021년 1월 24일 (UTC)

미안해 - 그건 내 변화가 오해받고 되돌아간 탓이었어.지금 확인해 보면 그들이 의도했던 모습 그대로를 알 수 있다.

{{wikidata redirect}에 {{redirect 카테고리 쉘}}을(를) {{wikidata redirect}에 추가하는 이유는 자동탐지를 위한 것이다.위키다타에 대한 링크가 제거되면 위키백과의 업데이트는 필요하지 않다(따라서, 셸을 사용하는 링크에 위키다타에 대한 링크가 추가되면 업데이트는 필요하지 않다.엘리엇321 (토크컨트롤) 07:52, 2021년 1월 24일 (UTC)

좋아, 말이 되네.두 템플릿의 템플릿 토크 페이지에서 이 BRFA에 대한 링크를 삭제하여 코멘트를 받을 수 있도록 하십시오.RowlingReader (대화) 09:37, 2021년 1월 24일 (UTC)

완료. 엘리엇321 (토크 기여) 10:08, 2021년 1월 24일 (UTC)

그래서 {{RCAT shell}}은(는) 연결된 항목을 확인하여 Wikidata 박스를 추가해야 한다는 생각이다.소프트웨어가 페이지가 Wikidata 항목에 연결되어 있는지 이미 감지할 수 있기 때문에 템플릿을 수동으로 추가할 필요는 없다.맞나? --PhiH (토크) 13:20, 2021년 1월 24일 (UTC)

@PhiH: 꽤 많이.이 껍질은 위키다타에 대한 링크를 자동으로 감지하고, 발견되면 템플릿을 초월한다.따라서 이 봇은 템플릿의 중복 수동 전이를 제거하고, 위키다타에 연결된 모든 리디렉션에서 자동으로 변환되도록 셸을 추가할 것이다.엘리엇321 (토크 기여) 15:36, 2021년 1월 24일 (UTC)

{{wikidata redirect}} 및 {{redirect 카테고리 셸}}}}을(를) 사용하여 변경된 내용을 정확히 이해하면, {{wikidata redirect}만 있는 리디렉션이 빈 {{redirect 카테고리 셸}}로 변경되어 오류가 발생하게 된다.이는 적용할 다른 리디렉션 범주를 결정하기 위해 수동 검사가 필요함을 의미하며, 이는 명백히 이 Bot 작업이 할 수 없는 일이다.—seav (대화) 01:02, 2021년 1월 25일 (UTC)

FYI, 빈 Rcat 셸은 기타 리디렉션 범주로 리디렉션을 정렬하게 되며, 편집자는 이 리디렉션을 적절한 범주로 태그 지정한다.P.I. 엘즈워트.^{put'r there}03:41, 2021년 1월 25일(UTC)

그럼 그게 문제야, 페인 엘즈워스?고양이에게 몇 만 페이지나 채운다고?RodelingReader (대화) 08:12, 2021년 1월 25일 (UTC)

Wikidata 항목이 있는 빈 RCAT 쉘은 카테고리로 분류할 필요가 없다.템플릿을 생성하기 때문에 기타 리디렉션 :위키다타 리디렉션.나는 아직 그것이 시행되는지 확인하지 않았다.그 템플릿이 있고 Wikidata 항목이 없는 페이지도 문제다.그들은 단지 하나의 추적 범주에서 다른 범주로 이동한다. --PhiH (대화) 08:44, 2021년 1월 25일 (UTC)

왜 오스크 리디렉션으로 분류할 필요가 없는가?Wikidata 항목을 연결/존재하는 것은 실제로 엔위키에 리디렉션이 있는 이유에 대한 설명이 아니다.확실히 리디렉션은 여전히 분류되어야 하는가?미루는 Reader (대화) 09:06, 2021년 1월 25일 (UTC)

@PhiH: @ProcrasingReader: {{redirect 카테고리 셸} 템플릿은 bot에 의해 카테고리 없이 Category로 적용되어서는 안 된다.기타 리디렉션은 수동으로 채워야 한다.결과적으로, 나는 이 봇을 가지고 그것을 할 계획이 없다.카테고리가 없는 리디렉션을 수동으로 분류할 수 있다.

(단, 봇이 적용할 수 있는 범주화되지 않은 리디렉션에 대한 추적 범주가 유용할 것이다.그러나 나는 그것에 대한 합의를 얻고 싶지 않다, 왜냐하면 그것이 이 제안보다 훨씬 더 논쟁거리가 될 것이기 때문이다) 엘리엇321 (토크 콘텐츠) 11:37, 2021년 1월 25일 (UTC)

내 요점은 예를 들어 설명하기 더 쉽다고 생각한다. 또는 내가 여기서 제안된 것에 대해 정확히 잘못 알고 있다.봇을 가지고 있거나 아직 봇을 코딩하지 않은 경우 손으로 5번 편집할 수 있는가?미루는 Reader (대화) 12:10, 2021년 1월 25일 (UTC)

여기에 몇 가지 다른 사례들이 있기 때문에, 어떤 변화가 더 유용할 지 보여주는 페이지가 있을까?엘리엇321 (토크 콘트롤) 03:46, 2021년 1월 26일 (UTC)

실제로 제안된 내용을 볼 때 가장 덜 혼란스러운 방법이므로 각 사례의 실제 편집이 더 바람직할 것이다.RowlingReader (대화) 09:57, 2021년 1월 26일 (UTC)

하지만 현재 {{Wikidata redirect}}만 사용하는 페이지에 빈 RCAT 셸을 추가하고 싶으시죠?카테고리에 추가할 경우:Wikidata 항목에 연결되어 있는 경우 기타 리디렉션? --PhiH(토크) 12:32, 2021년 1월 25일(UTC)

나는 그 상황에 처한 페이지를 수동으로 분류할 수 있다.엘리엇321 (토크 콘트롤) 03:46, 2021년 1월 26일 (UTC)

그것은 수동 분류에 관한 것이 아니다.리디렉션이 Wikidata 항목에 연결되었을 때 RCAT 쉘로 범주를 추가해야 하는지에 대해 논의하고 있다. --PhiH (토크) 14:19, 2021년 1월 26일(UTC)

Rcat 셸 내에 "Wikidata redirect" 템플릿과 같은 하나 이상의 rcat 템플릿이 있는 한, 리디렉션이 Category로 정렬되지 않음:기타 리디렉션.제안자가 제안했듯이, 그것은 문제가 되지 않을 것이다.제안자는 봇이 빈 Rcat 셸을 리디렉션에 추가해서는 안 된다는 것을 알고 있는 것으로 보인다. P.I. Elsworth ed. 15:35, 2021년 1월 25일(UTC)

우리가 논의해야 할 사례가 여러 건 있을 것 같은데, 아래는 얼마든지 언급해 줘.

RCAT 셸을 이미 사용하는 리디렉션
이는 논란의 여지가 없어야 한다.{{Wikidata redirect}}을(를) 사용할 경우 제거되고 템플릿은 RCAT 쉘에 의해 변환된다.
RCAT 쉘 없이 리디렉션...
1. …{Wikidata redirect}}를 사용하고 Wikidata 항목에 연결된 제품
  템플릿이 제거되고 RCAT 쉘이 추가된다.RCAT 셸이 이러한 페이지를 범주에 추가하도록 프로그래밍된 경우:기타 리디렉션?
2. …{Wikidata 리디렉션}을(를) 사용하지 않고 Wikidata 항목에 연결된 제품
  RCAT 쉘이 추가된다.위와 같은 문제가 발생한다.
3. …{Wikidata 리디렉션}을(를) 사용하며 Wikidata 항목에 연결되지 않은 경우
  템플릿이 제거됨.RCAT 셸을 추가하면 다음과 같은 범주에 추가된다.기타 리디렉션.
  현재 이 페이지는 카테고리에서 추적된다.연결되지 않은 Wikidata 리디렉션.이 봇 작업이 시작되기 전에 누군가는 이 목록을 검토하고 필요한 경우 위키다타에 페이지를 추가해야 한다.

--PhiH (대화) 14:46, 2021년 1월 26일 (UTC)

내가 정확히 이해한다면, 이 봇은 이미 위키다타에서 항목화된 리디렉션을 감지할 때 내부 {{Wikidata 리디렉션} 태그와 함께 Rcat 쉘을 추가할 것이다.그렇게 되면 리디렉션은 Misc. 리디렉션 범주로 정렬되지 않는다.{{NASTRO comment}} 템플릿이 적용된 곳에서도 가능한 도전이 느껴진다.많은 예들 중 하나는 3866 랭글리에 있다.이 봇이 저 많은 리디렉션에 무슨 짓을 할까?나는 사실 Rcat 조개껍데기들이 더 많이 섞여있다는 생각이 마음에 든다.봇이 위키다타 아이템에 연결되는 새로운 리디렉션을 계속 체크할지 궁금하다.P.I. 엘즈워스 에드 21:57, 2021년 1월 26일 (UTC)

봇이 {{NASTRO comment}} 리디렉션에 손을 대지 않는데, 그럴 필요가 없기 때문이다.

주 정리 작업 후에 이것을 실행할 수 있을 것이다(아마 매주 실행하면 충분할 것이다).엘리엇321 (토크 콘트롤) 05:25, 2021년 1월 27일 (UTC)

NASTRO 코멘트는 Rcat 셸을 적용하므로 Wikidata 리디렉션 템플릿을 자동으로 적용한다.그리고 나서 위키다타 리디렉션의 두 개의 렌즈가 있을 것이다.둘 중 하나를 제거해야 하지 않을까?P.I. Elsworth ed. 18:49, 2021년 1월 27일(UTC)

이 봇의 요점은 이런 편집이 더 이상 필요하지 않다는 것이라고 생각했다.여기서 Wikidata의 링크가 제거되면 위키백과에 대한 업데이트가 필요하지 않다고 하셨는데(따라서, 셸을 사용하여 위키다타에 대한 링크가 추가되면 업데이트가 필요하지 않다) --PhiH (토크) 19:00, 2021년 1월 27일(UTC)

매주 실행하면 새로 생성된 리디렉션을 처리할 수 있다.편집자들은 새로운 리디렉션을 만드는 것을 좋아하지만, 그들은 일반적으로 그들의 새로운 리디렉션을 분류하는 것을 봇과 위키홈즈에게 맡긴다.P.I. 엘즈워트.^{put'r there}17:11, 2021년 1월 28일(UTC)

그럴듯하게 들리네.완전히 새로운 페이지는 생각해 본 적이 없었다. --PhiH (토크) 17:29, 2021년 1월 28일 (UTC)

@PhiH: "이미 RCAT 쉘을 사용하고 있는 리디렉션:이것은 논란의 여지가 없어야 한다.": rcat 셸에 Wikidata rcat만 들어 있는 경우를 생각해 본 적이 있는가?𝟙𝟤𝟺𝟺𝑤𝓇𝟮𝟥 ( ( ( ( ( ( (( (𝗮𝘭𝙠 () 21:25, 2021년 2월 16일 (UTC)

AWB가 사용되는 이유에 대해서도 궁금하십니까?오해하지 마. 난 AWB를 좋아해.하지만 그것은 속도나 엉뚱함의 부족으로 알려져 있지 않다.매뉴얼에 따르면...봇의 토크를 편집하면 봇이 정지된다. 봇 운영자는 봇을 다시 시작하기 전에 반드시 봇 계정에 로그인하고 봇의 토크 페이지를 방문하여 "새로운 메시지" 통지가 취소되도록 해야 한다.그렇다면 왜 비 AWB 봇을 이 일을 하도록 만들지 않는가?P.I. 엘즈워스 에드 22:14, 2021년 1월 26일 (UTC)

주로 나는 위키피디아와 접하기 위한 다른 어떤 틀보다 AWB와 regex를 더 잘 알기 때문이다.만약 그것이 선호된다면, 나는 맞춤 코드를 쓸 수 있다.엘리엇321 (토크 콘트롤) 05:26, 2021년 1월 27일 (UTC)

그냥 궁금해서 그러는데, 당연히 너한테 달렸겠지.나는 가끔 내가 AWB에서 로그아웃하고, 위키피디아에 로그인해서 알림을 확인하고, 로그아웃하고, 다시 AWB에 로그인해야 할 때 그것이 나를 얼마나 미치게 하는지 알고 있다.로봇 이외의 작업에서도 그런 일이 일어날 수 있어. P.I. 엘즈워드.^{put'r there}18:53, 2021년 1월 27일(UTC)

카운터를 재설정하기 위해 AWB에서 로그아웃할 필요는 없어또한, 기술적으로 개인 모드로 봇 계정에 로그인하면 위키백과에서 로그아웃할 필요도 없다.프라임팩(대화) 13:44, 2021년 3월 8일(UTC)

그래서 내가 기다리고 있는 것을 명확히 하기 위해서: 각 사건마다 한두 건씩의 실제 편집을 하는 것이 더 바람직할 것이다. 그것이 실제로 제안된 것을 보는 가장 덜 혼란스러운 방법이기 때문이다.그 후에, 어떤 편집이 좋고 어떤 것이 더 많은 논의가 필요한지에 대한 논의를 하는 것이 더 명확해질 것이다.RodelingReader (대화) 15:32, 2021년 2월 13일 (UTC)

Re: 위의 메시지.프라임팩(대화) 13:44, 2021년 3월 8일(UTC)

@Primfac and DroadingReader: 핑해줘서 고마워.실제로 여기서 하고자 하는 일의 범위를 조금 넓혔다(사용자: 참조).엘리/rcat 표준화) - 그리고 이것을 진행하기 전에 먼저 다른 곳에서 변경사항에 대한 합의를 얻을 계획을 세우고 있으므로, 이 요청을 보류하거나 이상적일 수 있다면 (미안하지만, 이런 유형의 상황이 어떻게 작용하는지는 정확히 모르겠지만, 한 마리의 rcat을 제거해야 하는 좁은 과제에 대한 승인을 얻는 것은 현실적이지 않다.나는 그들 중 20명을 상대하는 것을 목표로 하고 있다.엘리(토크캐스터) 18:38, 2021년 3월 8일(UTC)

대기 중.갈 준비가 되면 템플릿에 대해 설명하십시오(잠시 여기에 앉아 있어도 문제가 없음).프라임팩(대화) 19:29, 2021년 3월 8일(UTC)

이 매우 생산적인 논의는 아마도 BRFA가 제출되기 전에 다른 곳에서 일어났어야 했다.아마도 이 BRFA는 다양한 시험 사례에 대한 완전한 토론과 수동 시연에 따라 철회된 후, 그 논의에 대한 링크와 과제에 대한 더 나은 설명을 다시 제출해야 한다.– Jonsey95 (대화) 02:25, 2021년 12월 7일 (UTC)

@Elli: 그냥 여기서 후속 조치를 취하면: 아직도 이 BRFA를 통과시킬 생각이세요?RowlingReader (대화) 01:07, 2021년 11월 8일 (UTC)

@ProcrashingReader: 그래, 그냥 다른 일들로 바빴을 뿐이고 아직 기술적인 세부 사항들을 완전히 확신할 수는 없다.나는 곧 그 일에 대해 후속 조치를 취하도록 노력하겠다.엘리 (토크 기여) 01:10, 2021년 11월 8일 (UTC)

또 다른 제안이 있어:위키백과:Bot 요청#T 위치 지정 또는 제거:위키다타 리디렉션.내 제안이 더 나은 이유:

Qids("Q" 번호)를 유지하므로 다른 wikidata 항목으로 리디렉션을 이동하는지 추적할 수 있다.
그것은 오직 범주만을 위한 RCAT를 망치지 않는다.헤노르 (대화) 18시 20분, 2022년 2월 8일 (UTC)

시험 기간 중의 봇

베어리프봇

연산자: 랑크2 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2022년 1월 20일 목요일 21시 35분(UTC)

기능 개요:이 봇의 기능은 베어 레퍼런스를 채우는 것이다.맨 참조란 시타이톤에 포함된 정보가 없는 참조로, 그 예로는 <ref>{{ref 웹url = https://encarta.microsoft.com 제목 = 마이크로소프트 Encarta}</ref>가 아닌 <ref>https://wikipedia.org</ref>가 있다.자세한 내용은 위키피디아에서 확인할 수 있다.베어_URL 및 사용자:BrownHairedGirl/Articles_with_bare_links.

자동, 감독 또는 수동:자동, 실수는 그대로 수정될 것이다.

프로그래밍 언어:복수다.

사용 가능한 소스 코드:아직은 아니에요.

관련 토론에 대한 링크(해당하는 경우):WP:Bare_URLs, 그러나 인용 봇은 이미 맨 ref를 채웠고, 그렇게 하도록 승인되었다.

기간 편집:계속.

영향을 받는 예상 페이지 수: 약 20만 페이지, 적게 또는 더 많이.

네임스페이스:메인 스페이스.

제외 준수(예/아니오): 예.

기능 세부 정보:그 봇의 목적은 맨 리프를 고치는 더 나은 방법을 제공하는 것이다.Enterprisey에서 설명한 바와 같이, 우리의 인용 도구는 더 잘 할 수 있을 것이다.인용 봇은 과부하가 걸리고, Reflinks는 지속적으로 웹페이지의 제목을 얻지 못한다.ReFill은 약간 더 낫지만 툴의 작성자가 지적한 소프트웨어의 설계상 오류로 인해 매우 느릿느릿느릿하다.

AWB 실행에서 증명되었듯이, 내 스크립트는 Reflinks, ReFill 또는 인용 Bot를 얻을 수 없는 많은 사이트의 제목을 얻을 수 있다.이 도구는 인용 봇과 같은 다른 도구에 대한 "부스터"와 같으며, 다른 도구들이 중단된 부분을 집어낸다.

봇이 제목을 채우지 않는 경우는 몇 가지 예외가 있다.예를 들어 제목이 5척보다 짧으면 제목에 유용한 정보가 있을 가능성이 매우 낮기 때문에 입력하지 않는다.샌드 닥터가 좀 더 완전한 충전을 할 수 있는 봇을 가지고 있기 때문에 트위터 링크는 그냥 내버려둘 것이다.

이들 참고자료 채우기 '불완전성'에 대한 논의가 있었다.예를 들어 화이트리스트 사이트(NYT, Youtube 등)가 아니면 "work="/"website=" 매개 변수를 채우지 않는다.이것은 인용봇이 IERC에서 하는 것과 비슷하다.이러한 다른 매개변수는 일반적으로 채워지지 않지만, "완벽한 것은 선의 적"이며, 어떤 종류의 채움도 인용의 개선을 나타낼 것이라는 데 의견이 일치한다.모든 충원된 시트는 편집자나 다른 봇에 의해 항상 훨씬 더 개선될 수 있다.

예:

특수:디프/1066367156

특수:디프/1066364250

특수:디프/1066364589

토론

{{BotOnHold}} 위키백과의 마감 보류 중:관리자_noticeboard/Incidents#Rlink2.미루는 Reader (대화) 23:25, 2022년 1월 20일 (UTC)

@ProcrasingReader:ANI 나사산이 닫혔다.링크2 (대화) 15:03, 2022년 1월 25일 (UTC)

초기 질문 및 생각(특별한 순서가 아님):

인용 봇이 왜 맨 URL로 기사를 대량 편집하도록 승인하지 않고 트리거 전용인지(즉, 인용 봇이 트리거되는 개별 기사만 편집하는지)에 대한 코멘트를 보내주면 고맙겠다.영향을 받는 페이지 수가 정확하다고 가정할 때, 이 작업에 대해 적극적이고 승인된 작업이 없는 것 같고, 이것이 봇 사용에 분명히 적합한 작업인 것 같아 왜 그렇지 않은지 궁금하다.
어떻게 20만 페이지의 영향을 받은 페이지 수를 얻게 되셨습니까?
인용 템플릿의 정확히 어떤 값을 이 봇이 채울 것인가?나는 그것이 채워질 것이라고 생각한다. title=- 또 다른 것은?

미루는 Reader (대화) 23:25, 2022년 1월 20일 (UTC)

@ProcrasisingReader: 인용 봇이 트리거된 개별 기사만 편집한다고 말하는 것은 사실 정확하지 않다.그래, 촉발시켜야 해. 하지만 일괄 처리 모드도 있어. 한 번에 최대 2,200개의 기사를 쓸 수 있어.지난 6개월 동안 이 시설을 이용하여 봇에게 70만 개에 이르는 기사를 URL이 없는 상태로 공급해 왔다.

인용봇이 표적이 필요한 이유는 단순히 범위 때문이다.인용봇은 위키피디아에 실린 640만개의 기사 중 어느 것도 잠재적으로 개선할 수 있지만, 하루에 몇 천개의 기사만 처리할 수 있기 때문에, 그것들을 모두 처리하는데 약 4년이 걸릴 것이다.그렇기 때문에 인용 봇은 우선순위가 높은 사례에서 봇을 표적으로 삼을 편집자가 필요하다.

이와는 대조적으로 베어리프봇의 기사 세트는 약 20만 개다.이는 전체의 3%에 불과하며, 각각의 경우 BareRefBot은 페이지의 대부분의 ref를 생략한다(여기서 인용 봇은 모든 ref를 처리하며, ref가 수백 개일 경우 페이지당 최대 10분이 소요됨).훨씬 간단하고 선택적인 BareRefBot은 인용 봇보다 훨씬 더 빨리 기사를 처리할 수 있기 때문에 BareRefBot은 14일(10 X 60 X 24 X 14 = 201,600) 만에 24시간 내내 10번의 편집/분 동안 꾸준히 로트를 처리할 수 있다.좀 더 느리게 실행하는 것이 바람직할 수도 있지만, 기본적으로 이 일은 2주 안에 밀린 일을 정리할 수 있을 것이다.따라서 추가 선택성이 필요하지 않다.

Rlink2의 데이터의 출처를 모르지만, 20만 개의 비PDF 베어 URL이 현재 나의 추정치다.나는 지난 몇 달 동안 모든 데이터베이스 덤프를 스캔했는데, 그 수치는 내가 마지막 데이터베이스 덤프(20220101)에서 찾은 숫자에서 그 이후의 진행률 추정치를 뺀 것이다.앞으로 며칠 안에 20220120 덤프에서 자료를 받아서 여기에 추가하겠다.

내 데이터베이스 검색에는 매일 300개의 빈 URL이 추가되는 새로운 기사가 표시된다는 점에 유의하십시오(아마도 일부는 즉시 채워지지만 월말에 남아 있을 것이다).그래서 매달 약 9k–10k 기사에 대한 작업이 진행될 것이다.그 중 일부는 인용봇에 의해 수행될 것이며, 인용봇은 보통 약 30%의 기사에 대한 모든 베어 URL 참조를 채울 수 있다.BareRefBot은 나머지 대부분을 처리할 수 있다.브라운헤어드걸(대화) • (출연) 01:40, 2022년 1월 21일 (UTC)

기사 수.@ProcrasingReader:이제 20220120 데이터베이스 덤프의 스캔을 완료했으며, 20220120의 다음과 같은 헤드라인 번호를 가지고 있다.

태그가 지정되지 않은 PDF 베어 URL 참조가 있는 기사: 221,824
20220101 덤프에는 없었던 20220120 덤프에서 태그가 지정되지 않은 베어 URL 참조가 있는 기사: 5,415(하루 평균 285개 추가)

내 추측으로는 20220101년 이후 진행 상황을 약간 과대평가했었다.그러나 태그가 지정되지 않은 PDF 베어 URL 참조가 있는 총 20220120개 기사는 총 25만2,226개보다 30,402개가 낮다.그래서 19일 만에 태그가 없는 맨 URL을 가진 총 기사가 12% 조금 넘게 줄어들어 큰 진척을 보였다.

이 숫자에는 {{Bare URL 인라인}}} 태그가 지정된 ref가 포함되지 않는다.이 집계는 20220101년 33,794명에서 20220120년 13,082명으로 감소했다.이는 20,712명(61%)의 하락으로 경이적인 진행률을 보이고 있으며, 인라인 태그가 붙은 베어 URL 참조를 @Rlink2가 매우 생산적인 목표로 삼았기 때문이다.

태그가 지정된 기본 URL과 태그가 지정되지 않은 기본 URL이 있는 기사 집합 간에 일부 중복이 있는데, 일부 기사에는 태그가 지정되지 않은 기본 URL 참조가 모두 있기 때문이다.인라인 태그가 지정된 베어 URL이 포함된 기사 중 일부는 PDF에만 해당되므로 툴이 채울 수 없다는 점도 솜털의 한 요소다.

두 목록을 합치면 일부 PDF를 포함해 태그가 지정되거나 태그가 지정되지 않은 URL 참조가 포함된 총 23만1,316개의 기사가 20220120개에 달한다.따라서 태그가 지정되거나 태그가 지정되지 않은 PDF 베어 URL 참조가 포함된 총 230,000개의 기사를 예상해 보십시오.

태그가 지정된 URL 참조와 태그가 지정되지 않은 URL 참조를 모두 포함하면 1월 첫 19일의 집계에서 약 4만 건이 감소했다.나는 그 중 약 2만 5천 명이 랑크2의 작업 때문이라고 추정하고 있는데, 그래서 랑크2의 작업이 계속되어야 한다는 생각이 간절하다.브라운헤어드걸(대화) • (출연) 18:06, 2022년 1월 22일 (UTC)

업데이트. 20220201 데이터베이스 덤프의 스캔 데이터를 확보했다.

태그가 지정되지 않은 PDF 베어 URL 참조가 있는 기사: 215,177개(221,824개에서 감소)
202201201 덤프에 없었던 20220101 덤프에서 태그가 지정되지 않은 베어 URL 참조가 있는 기사: 3,731(하루 평균 311건 추가)
인라인 태그가 지정된 베어 URL 참조가 있는 기사: 13,162개(20220120년 13,082개에서 소폭 상승)

따라서 이 12일 기간 동안 태그가 지정된+태그되지 않은 비PDF 베어 URL의 평균 감소량은 6,567명 감소했다.1월 말 하루 평균 547건의 순청산은 1월 1일의 하루 2000건 이상에서 크게 줄어든 것이다.

두 기간 동안, 나는 인용 봇을 24시간 내내 맨 URL 정리로 먹도록 하고 있었다. 차이점은 1월 초, Rlink2의 작업이 터보차지 방식으로 진행되었다는 것이다.이 봇이 승인되면 청소는 다시 터보차지된다.브라운헤어드걸(대화) • (출연) 20:44, 2022년 2월 5일(UTC)

업데이트해줘서 고마워.모든 일이 잘 풀리면, 우리는 생각보다 빨리 승리의 폴카를 부를 것이다. 즉, 우리는 관심을 맨 URL pdfs로 돌릴 수 있다(그렇다 - PDF를 다루는 방법에 대한 몇 가지 생각이 있지만, 지금 이 점에 초점을 맞추자).링크2 (대화) 04:10, 2022년 2월 7일 (UTC)

@Rlink2: 좋아.

나는 또한 맨 URL PDF ref에 대한 아이디어를 가지고 있다.이 봇토론이 끝나면 어떻게 진행해야 할지에 대한 우리의 생각을 곰곰이 생각해 보자.브라운헤어드걸 (대화) • (출연) 09:57, 2022년 2월 7일 (UTC)

범위. @Rlink2:PDF 베어 URL은 이 작업에서 제외할 것을 요청한다.{{Bare URL PDF}}은(는) 유용한 태그지만 PDF 베어 URL을 처리하는 더 좋은 방법이 있다고 생각한다.나는 다른 곳에서 어떻게 진행할 것인지에 대한 논의를 시작할 것이다.데이터베이스 검색에서 쉽게 제외되고 다른 목록에서 쉽게 필터링됨(AWB: 페이지가 regex와 일치하지 않을 경우 건너뛰기<ref><ref[^>]*?>\s*\[?\s*https?://[^>< \ \[\]]+(?<!\.pdf)\s*\]?\s*<\s*/\s*ref\b )) 봇이 쉽게 지나갈 수 있도록. --브라운헤어드걸(토크) • (기증) 02:20, 2022년 1월 21일 (UTC)

@BrownHairdGirl:좋아, 내가 제안서에서 빼냈어.그 제안은 ANI 때문에 보류된 상태고, BRFA 메인 페이지에서는 아직 전개가 되지 않았기 때문에, 어수선한 것을 정리해도 괜찮다는 생각이 들었다.Rlink2 (대화) 22:10, 2022년 1월 21일 (UTC)

@Rlink2:나는 PDF 맨 URL에 대해 다시 생각해 보았고, 내가 최고의 것을 선의 적이 되게 하는 함정에 빠졌음을 깨닫는다.

그렇다, 나는 아마도 그들을 다루는 더 좋은 방법들이 있을 것이라고 생각한다.그러나 첫 번째 단계로서 태그가 붙지 않도록 하는 것보다 태그가 붙도록 하는 것이 좋다... 그리고 일반 {{Bare URL 인라인}}보다 특정 {{Bare URL PDF}}} 태그가 붙도록 하는 것이 좋다.

그러니, 제 생각을 바꿔서 PDF 베어 URL의 태그를 복원해 달라고 부탁드려도 될까?귀찮게 해서 미안해.브라운헤어드걸(대화) • (출연) 09:36, 2022년 3월 1일 (UTC)

@BrownHairdGirl: 문제없어.내가 수정해서 소스 코드를 업데이트해서 반영하도록 할게.피드백 고마워.링크2 (대화) 14:36, 2022년 3월 1일 (UTC)

@Rlink2: 잘됐네, 그리고 내 변심에 대해 그렇게 친절하게 대해줘서 고마워.

그 동안에사용자를 업데이트한 경우:PDF에 {{Bare URL PDF}을(를) 사용할 수 있도록 BrownHairedGirl/BareURLinline.js.PDF용 {{Bare URL 인라인}}의 기존 용도에 대해서도 AWB를 실행해 {{Bare URL PDF}}(으)로 변환했다.브라운헤어드걸 (대화) • (출연) 16:15, 2022년 3월 1일 (UTC)

설명 열기:나는 이 유사한 이니셔티브에 삽입되는 것을 본 적이 있다.그게 여기서 유용한 일일까?이 봇이 삽입하도록 제안된 제목들은 장황하고 반복적일 수 있으며, 간결하거나 명백히 틀릴 수 있다는 것을 인정한다.많은 경우에 수동적인 개선이 필요할 것이다.이 작업을 하는 데 관심이 있는 편집자들을 어떻게 도울 것인가?

봇은 불량하고 부적합한 제목을 식별하는 방법이 있으며, 그런 경우 인용문을 작성하지 않는다.나는 인용 봇의 리스트와 AWB에서 우연히 발견한 다른 리스트를 사용하고 있다.Rlink2 (대화) 22:06, 2022년 1월 21일 (UTC)

RuspingReader처럼 나는 여기서 봇 허가 우선 순위를 이해하는 것에 관심이 있다.나는 이러한 편집이 보편적으로 생산적이라는 것을 확신하지 못한다.나는 과거에 봇 직업에 대해 행해진 제약이 있었다고 믿는다. 봇 직업에는 변화가 현저하게 개선되고 있다는 강한 공감대가 없다.나는 이것이 워치리스트에 추가될 모든 소음의 단점을 극복하기 위해 충분히 큰 개선이 필요하다고 생각한다.난 그 술집이 여기서 비었다는 것을 확신할 수 없다.User_talk:를 참조하십시오.Rlink2#A_little_mindless 배경.~Kvng (대화) 16:53, 2022년 1월 21일 (UTC)

@Kvng: 내 생각에 리프는 다음과 같다.{{cite web title = Wikipedia - Encarta, from Microsoft url=https://microsoft.com/encarta/shortcode/332d}} 단순한 연결보다 더 낫다.<ref>https://microsoft.com/encarta/shortcode/332d</ref>. "완전하게" 채워지지만 "완전하게"(웹 사이트 매개변수로 채워짐)되지는 않는 베어 레프(bear ref)는 새로운 레프(ref)를 더 유익하게 남겨두면 링크(link)가 100% 베어(bearning)보다 낫다는 것이 의견의 일치다.그것은 항상 정상에서 완벽한 개선까지 비실용적이다.

완벽함을 원하는 사람도 있을 수 있다는 것을 알고 있으며, 개선의 여지가 있다면 그것을 받아들여야 한다고 생각한다.웹 사이트 매개 변수를 가능한 한 빨리 채우는 작업을 더 잘 수행하는 스크립트(해당 편집에 대해 업그레이드가 활성화되지 않음)로 최근에 업그레이드를 했다.새로운 스크립트 업데이트와 함께, 당신이 내 페이지에서 이야기한 ref.http://encyclopedia2.thefreedictionary.com/leaky+bucket+counter)는 로 변환될 것이다.

{{cite web  url=http://encyclopedia2.thefreedictionary.com/leaky+bucket+counter  title = Leaky bucket counter   website = TheFreeDictionary.com}}

. 이것은 예전 충만함보다 낫다.

{{cite web  url=http://encyclopedia2.thefreedictionary.com/leaky+bucket+counter.  title = Leaky bucket counter. {{!}} Article about leaky bucket counter. by The Free Dictionary}}

모든 사이트에 적용되는 것은 아니지만 시작이다.Rlink2 (대화) 22:06, 2022년 1월 21일 (UTC)

Rlink2와 BrownHairdGirl은 이러한 대체품들이 훌륭하며 그들을 반대하는 사람들은 완벽을 추구하고 있다고 주장한다.대부분의 경우 이러한 개선은 명백한 증분적 개선이다(재화)이다.몇 가지 사례와 측면에서는 사물을 개선하거나 심지어 저하시키지도 않는다(좋지 않다).봇은 고도로 가변적인 품질과 포맷의 외부 메타데이터(HTML 타이틀)에 의존하기 때문에, 좋은 것과 나쁜 것을 분리할 수 있는 믿을 만한 방법이 없는 것 같다.한 가지 해결책은 인간 편집자들이 봇을 따라다니며 이것들을 고치도록 하는 것이지만, 우리는 그것을 하기 위해 줄 서 있는 자원봉사자들을 가지고 있지 않다.또 다른 해결책은 성취한 전체적인 성과를 높이는데 있어 좋지 않은 기여를 용인하는 것이지만 나는 우리가 그 가치 계산을 어떻게 하는지 모르겠다.~Kvng (대화) 16:14, 2022년 1월 22일 (UTC)

@Kvng: 나는 이미 HTML 제목보다 더 많은 정보를 사용하기 위해 스크립트를 업그레이드했다고 설명했다.위의 응답을 참조하십시오. 분리할 수 있는 신뢰할 수 있는 방법이 없는 것 같음. 나쁜 제목을 탐지하는 방법을 개발했음.그러한 경우, 그것은 ref를 채우지 않을 것이다.약간 추악한 제목(자유 사전처럼)과 일부 비정보적인 제목(예: "웹사이트", "트위터", "뉴스스토리")은 차이가 있다.전자는 독자에게 더 많은 정보를 제공하는 반면 후자는 더 적은 정보를 제공한다.그래서 제목이 너무 일반적이면 참고문헌을 채우지 않을 것이다.Rlink2 (대화) 16:18, 2022년 1월 22일 (UTC)

물론, 우리는 진행하면서 개선을 할 수 있지만, HTML 제목이 너무 다양하기 때문에, 그 과정에서 더 많은 것이 발견될 것이다.내가 오해하면 고쳐줘. 하지만 네가 찾고 있는 승인은 위키피디아 전체를 무제한으로 기어다니고 대체품을 적용하는 거야.그런 접근법으로, 우리는 모든 문제가 도입된 후에야 문제를 피하는 방법을 알게 될 것이다.~Kvng (대화) 16:55, 2022년 1월 22일 (UTC)

@Kvng: 아래 요청대로, 제기된 문제를 보여주는 디프트를 제공하십시오.브라운헤어드걸(대화) • (출연) 17:02, 2022년 1월 22일 (UTC)

@Kvng: 그런 접근법으로 우리는 모든 문제가 도입된 후에야 문제를 피하는 방법을 알게 될 것이다.꼭 그렇지는 않지만, 나는 모든 제목을 적용하기 전에 파일에 저장한다.나는 파일을 훑어보고 문제 제목이 있는지 살펴본다.만약 있다면, 나는 그것들을 제거하고, 대본을 수정해서 그 나쁜 제목을 붙이지 않도록 한다.그리고 봇이 활동을 하고 있을 때에도, 나는 가능한 실수를 잡기 위해 사실 이후의 몇 가지 차이점을 여전히 볼 것이다.Rlink2 (대화) 17:24, 2022년 1월 22일 (UTC)

@Kvng: Rlink2의 ref에 다음과 같은 내용이 포함되어 있다고 생각하는 경우를 식별하는 diff를 게시하십시오.

더 나아지지 않다.
권위를 떨어뜨리다

나는 이 사건들이 존재한다고 믿지 않는다.해당 유형이 존재한다고 주장하므로 각 유형의 여러 예를 제공하십시오.브라운헤어드걸(대화) • (출연) 16:29, 2022년 1월 22일 (UTC)

나의 이전 일화적인 불평은 내가 내 감시목록에서 검토했던 편집에 근거한 것이었다.나는 이제 Rlink2에 의해 가장 최근에 편집된 37개의 (스크린으로 가득 찬) 베어 레퍼런스 편집본을 검토하여 다음과 같은 문제점을 찾아냈다.37개 수정사항 중 10개는 개선사항이라고 생각하지 않는다.

[7] WP 소개:피코크 발행
[8] 끊어진 링크, 리디렉션 페이지 제목 사용
[9] 끊어진 링크, 리디렉션 페이지 제목 사용
[10] 끊어진 링크, 리디렉션 페이지 제목 사용
[11] 끊어진 링크, 리디렉션 페이지 제목 사용
[12] 끊어진 링크, 리디렉션 페이지 제목 사용
[13] 기사 제목이 아닌 웹 사이트 이름
[14] 잘못된 제목
[15] 새로운 제목이 기본 URL보다 적은 컨텍스트를 제공함
[16] 신규 타이틀은 베어 URL보다 컨텍스트를 적게 부여함 ~Kvng (토크) 17:44, 2022년 1월 22일(UTC)

@Kvng: 그럼 27개의 개선이 있었단 말씀이세요?물론 벌레도 있고 뭐 그런 것도 있지만, 우리는 항상 그것을 헤쳐나갈 수 있다.

[17] 유익하지만 WP:피코크 타이틀은 맨 레퍼런스 IMO보다 낫다.

다음 링크 세트(리디렉션 페이지 제목 사용)에 대해 내가 한 업그레이드에서 해당 링크를 수정할 것이다.서로 다른 두 개의 URL이 동일한 제목을 가진 경우, 일반 URL로 가정한다.이 URL 리디렉션의 대부분은 어차피 데드 링크여서, 그냥 내버려둘 것이다.

[18] 이것은 업그레이드 시 수정되었다.
[19] 이슈를 보지 마라.

[20] 쉽게 고치고, 저것을 잡지는 못했지만, 향후의 편집에 유의했다.

[21] 맨 URL은 거의 틀림없이 많은 정보를 가지고 있지 않았다("https://nytimes.com/what-you-should-do-2022"과 "NY times" 대 "redwater.ca/pebina-place"과 "Pembina Place"의 차이가 있다).그럼에도 불구하고, 업그레이드는 이러한 문제들 중 일부에 대해 다루었어야 했고, 따라서 희망컨대 점점 덜 일어나야 했다.

그래서 이제 내가 아직 다루지 않은 문제 편집이 한두 가지밖에 없다(WP와 같이:피코크 원.나쁘지 않은 Rlink2 (대화) 18:09, 2022년 1월 22일 (UTC)

계획은 봇이 20만 번의 편집을 하는 것이고, 37번의 편집 때마다 1-2번의 이슈에서 우리는 잠재적으로 5-10,000번의 비생산적인 편집들을 도입할 것이다.나는 그것이 받아들여질 수 있을지 확신할 수 없다.~Kvng (대화) 19:21, 2022년 1월 22일 (UTC)

@Kvng: 나는 당신의 기존 세트에서 1-2 이슈를 말했지, 37번의 편집 때마다 말 그대로 1-2 이슈를 가지는 것이 아니다.더 많은 이슈가 고쳐질수록, 나쁜 편집의 비율은 점점 줄어들 것이다.봇은 처음에는 천천히 달리다가 실수를 포착하고 속도를 높일 것이다.괜찮은 것 같아?Rlink2 (대화) 19:24, 2022년 1월 22일 (UTC)

나는 작은 표본으로 추론하고 있다.당신이 직면하고 있는 것을 더 정확하게 알기 위해서는 우리는 더 큰 검토가 필요하다.50개만 편집해 보면, 나는 이것이 잘못될 수 있는 많은 방법들을 보아왔다.그것은 내가 아직 밝혀지지 않은 많은 다른 것들이 있다고 가정하게 한다.이 문제를 해결하려면 당신의 제안에 일종의 QA 계획을 추가해야 한다.~Kvng (대화) 00:31, 2022년 1월 23일 (UTC)

@Kvng: 같은 문제의 많은 편집 사항을 확인하셨습니다.고친 것과 똑같은 문제들.10개의 서로 다른 오류를 발견하지 못하셨고, 5개의 문제를 발견하셨으며, 그 중 4개는 이미 수정되었거나 수정될 것이며, 1개는 WP라고 해도 문제가 되지 않을 것 같다.POCKEK, 그것은 여전히 원본 ref보다 더 유익하다. (하지만 나는 이것을 조사할 것이다.)기억하라, 이것은 점진적인 개선에 관한 것이다.기억하라, 이 시트라틴들은 그들에게 아무런 정보도 첨부되어 있지 않다.아무것도 없다.'뭔가'를 추가하는 것이 중요하며, 완벽하지는 않더라도, 없는 것보다 항상 더 유익할 것이다.만약 당신이 매우 목이 말라서 지금 당장 물을 마실 필요가 있다면, 당신은 후지 물을 더 좋아하기 때문에 그 가게의 브랜드 물을 거부할 것인가?그것은 또한 당신이 페라리나 람보르기니를 살 여유가 없다면 차라리 차를 가지고 싶지 않다고 말하는 것과 같다.

나는 이미 앞에서 설명한 QA 계획을 실행 중이다.Rlink2 (대화) 00:56, 2022년 1월 23일 (UTC)

내 생각엔 내가 모든 제목을 적용하기 전에 파일에 저장하는 것을 말하는 것 같아. 나는 파일을 훑어보고 문제 제목이 있는지 살펴본다. 만약 있다면, 나는 그것들을 제거하고, 대본을 수정해서 그 나쁜 제목을 붙이지 않도록 한다. 그리고 봇이 활동을 하고 있을 때에도, 나는 가능한 실수를 잡기 위해 사실 이후의 몇 가지 차이점을 여전히 볼 것이다.네가 이미 편집한 미트봇에는 잘 안 되는 것 같던데.대본이 개선되었음에도 불구하고, 나는 이것이 진짜 봇과 더 잘 어울릴 것이라고 확신하지 않는다.일종의 시범 운영과 독립된 자원봉사자들의 편집 품질에 대한 검토는 어떠세요?~Kvng (대화) 21:18, 2022년 1월 25일 (UTC)

지금 발견되는 30페이지에 대해 어떻게 좀 해줄래?insource:"title = Stocks - Bloomberg"?~~
사용자:1234qwer1234qwer4 (대화)20:56, 2022년 1월 27일 (UTC)

@1234qwer1234qwer4:여기서 만나서 반가워, 내 BRFA를 검토해줘서 고마워.너의 의견은 매우 고맙고 존중받았어, 너는 많은 것을 알고 있고 할 말이 많을 거야."블룸버그"에 관해서, 그 타이틀들 중 몇 개는 내가 맡긴 것이다.일반 제목이 붙어 있는 저 30개의 링크는 애당초 데드 링크인 것 같다.나는 그것들을 살펴보고 수동으로 교체할 수 있다.스크립트는 일반 제목 배치를 방지하도록 여러 URL에 걸쳐 공유된 제목을 찾고 배치하지 않는 업그레이드를 가지고 있다.Rlink2 (대화) 21:11, 2022년 1월 27일 (UTC)

시트가 많이 쓰이는 것 같아.{{!}}예를 들어 첫 번째 예에서 스팸 내용 포함 title = Blur {{!}} full Official Chart History {{!}} Official Charts Company. 스팸과 실제 제목("Blur") 중 어떤 하위 문자열이 스팸인지 모르기 때문에 이것은 어렵다.한 가지 방법: 파이프 경계를 따라 문자열을 세 개로 나누고 각 문자열을 매우 긴 텍스트 파일에 새 줄로 추가하십시오.그런 다음 각 문자열의 카운트를 사용하여 파일을 정렬하십시오."450\tOfficial Charts Company"는 파이프 경계선을 따라 해당 문자열이 포함된 450개의 제목을 발견했음을 나타낸다.안전하게 제거할 수 있는 것은 스팸이다.제목에서 탐지될 때마다 선행 파이프와 함께 제거되도록 이러한 문자열을 스켈치 파일에 추가하십시오.그 엉터리 데이터는 다른 봇 작가들에게도 매우 귀중할 것이다.일부 데이터를 축적하기 위해 먼저 기존 시트 온위키에서 실행할 수 있다.여러분은 아마도 잘못된 긍정에 대한 데이터를 수동으로 검토하기를 원할 것이다. 하지만 이 스팸 문자열들은 매우 명백하고 여러분은 이런 식으로 많은 것을 꽤 빨리 얻을 수 있다. -- GreenC 07:10, 2022년 1월 22일 (UTC)

만약 이것이 성사된다면, 나는 시험 주행에 순응할 수 있는 쪽으로 기울고 있다; 나는 이것이 단 한 번의 실행 후에만 승인될 것이라고 기대하지는 않지만, Kvng의 실 위에서 언급된 것처럼, 봇이 실제로 움직이기 시작할 때까지 몇 가지 우려/이슈가 터지지 않을 것이다.프라임팩 (대화) 16:19, 2022년 1월 25일 (UTC)

@Primfac: @GreenC:나는 이미 이것을 했다.모든 타이틀은 파일에 저장되며, 같은 타이틀 중 둘 이상의 타이틀이 '' 기호 다음에 공통적인 부분이 있으면 웹사이트 파라미터를 채울 수 있다면 제거할 수 있다.위에서 설명한 것처럼 "website=" 매개 변수를 감지하고 채우는 것도 이전보다 훨씬 좋아졌다.

봇이 실제로 움직이기 시작할 때까지 어떤 우려/불안들은 터지지 않을 것 같다.그래, 나도 동의해.처음에는 느리게 가고, 다음에는 속도를 낼 것이다.Rlink2 (토크)

당신이 그것을 놓쳤는지(혹은 내가 당신의 대답을 놓쳤는지) 잘 모르겠지만, 나의 세 번째 첫 번째 질문에 대한 당신의 대답을 확인해 줄 수 있는가?미루는 Reader (대화) 18:04, 2022년 1월 25일 (UTC)

@ProcrasingReader:내가 처음 대본을 만들었을 때, 그것은 "title=" 매개 변수만 채우곤 했다.일부 편집자들은 "website=" 매개변수를 보고 싶다고 불평했고, "title=" 매개변수만 채우는 것이 "없음"보다 낫다는 공감대가 있는 반면, 나는 가능하다면 그 파레미터를 스크립트에 추가할 수 있는 기능을 추가했다.일부 웹사이트에 "website="를 추가하는 것은 성공적이지만 모든 웹사이트는 아니다.
그러나 이 봇은 일단 죽은 고리를 벗어버릴 것이다.Rlink2 (대화) 18:29, 2022년 1월 25일 (UTC)

@Rlink2: {{dead link}}(날짜) 404 오류를 반환하는 베어 URL을 참조하면 태그를 봇할 수 있는가?

이는 리스트 작성 단계에서 그러한 ref가 제외되어 시간을 많이 절약할 수 있기 때문에 다른 베어-URL 고정 프로세스에 큰 도움이 될 것이다.

링크를 비활성 상태로 취급해야 하는 다른 상황도 있지만 여러 번 점검해야 할 수 있다는 점에 유의하십시오.404는 꽤 확정적이어서 첫 패스에 안전하게 태그가 붙을 수 있다.브라운헤어드걸(대화) • (출연) 19:07, 2022년 1월 25일 (UTC)

@BrownHairdGirl:그래, 난 분명히 할 수 있어.Rlink2 (대화) 20:03, 2022년 1월 25일 (UTC)

고마워! 브라운헤어드걸(토크) • (출연) 20:09, 2022년 1월 25일 (UTC)

PS @Rlink2: 베어 URL PDF를 사용한 나의 실험은 HTTP 상태 410("Gone")은 거의 사용되지 않지만 0이 아닌 사용량을 가지고 있음을 보여준다.

410은 완전히 데드 링크이므로, 봇이 이를 404처럼 취급할 수 있는가, 즉, {{데드 링크}}와 같은 URL을 태그할 수 있는가?

또한 @GreenC에 ping을 하는데, 만약 그들이 410개 정도를 추가할 수 있는 주의사항이 있다면.브라운헤어드걸(대화) • (출연) 01:52, 2022년 2월 8일(UTC)

@BrownHairdGirl: 좋은 생각이야.이거 하나 넣어야지.항상 그렇듯이 최고 수준의 예의와 예의를 갖춰 문제를 제기해줘서 고마워.

봇에서 변경사항이 제대로 작동하는지 확인하기 위해 410 코드가 반환되는 디프들 중 일부에 링크해 주시겠습니까?다시 한 번 감사드려요.Rlink2 (대화) 01:59, 2022년 2월 8일 (UTC)

감사합니다 @Rlink2.나는 실험용 코드에 410을 추가한 이후 한 시간쯤 지나서야 죽은 것으로 꼬리표를 붙이며 지금까지 그들을 추적하지 않고 있다.그것은 그 오류가 404인지 410인지의 흔적을 남기지 않는다.

이제 내 테스트의 일부로 기록하기 시작하고, 세트가 있을 때 다시 연락할 것이다. (페이지 이름, URL, HTTP 코드, HTTP 메시지만 있을 것이다.)브라운헤어드걸(대화) • (출연) 02:09, 2022년 2월 8일 (UTC)

@Rlink2:User talk에 [22]라는 글을 올렸다.Rlink2#HTTP_410은 이러한 URL 9개의 목록이다.그게 내가 몇 시간 전에 그것들을 기록하기 시작한 이후로 찾은 내 스크립트 전부야.

이게 도움이 되길 바래.브라운헤어드걸 (대화) • (출연) 11:25, 2022년 2월 8일 (UTC)

웹 페이지 상태를 정확하게 결정하는 것은 매우 쉽다.예를 들어, forbes.com은 봇 차단을 사용하며, 충분한 일시 중지 없이 연속해서 X번 이상 그들의 사이트를 확인하면, 그 페이지가 200이지만 404s(또는 403?)를 반환한다.내 생각에는 CloudFlare 서비스라서 많은 사이트에서 사용하고 있는 것 같아.강력한 범용 데드링크 체커는 상당히 어렵다.예를 들어 IABot은 네트워크 분산을 허용하기 위해 최소 3주 동안 3번 점검한다. -- GreenC 20:34, 2022년 1월 25일(UTC)

예를 들어, forbes.com은 봇 차단을 사용하며, 충분한 일시 중지 없이 연속해서 X번 이상 그들의 사이트를 확인하면, 그 페이지가 200이지만 404s(또는 403?)를 반환한다.정확히 말하면 404를 돌려주는 것이 아니라 다른 것을 돌려주는 것이다.BHG는 404개의 링크에 대해 이야기 하고 있었는데, 이것은 그들의 "죽었거나 살았거나" Rlink2 (대화) 20:40, 2022년 1월 25일 (UTC)

아마도 그것은 효과가 있을 것이다, 왜냐하면 웹사이트들은 머리말과 코드로 예상치 못한 비표준적이고 비논리적적인 일들을 하기 때문이다. -- GreenC 21:19, 2022년 1월 25일 (UTC)

이 프로젝트는 지금까지 일의 복잡성에 대한 과소평가로 특징지어져 왔다.범위를 촘촘히 하고 일차적인 업무 경험을 좀 더 쌓아야 한다.나는 죽은 링크 탐지와 봇의 기능에 태그를 추가하는 것을 지지하지 않는다.~Kvng (대화) 21:26, 2022년 1월 25일 (UTC)

@Kvng:이 프로젝트는 지금까지 업무의 복잡성에 대한 과소평가로 특징지어져 왔다.착각하지 마, 난 한동안 대본을 잘 조율해왔어.나는 구석진 곳을 알고 있다.데드 링크 감지를 추가하는 것은 논란의 여지가 없으며 툴을 더욱 범위 내에 유지한다.그러니 지지해 주지 그래?링크2 (대화) 21:39, 2022년 1월 25일 (UTC)

왜냐하면 우리가 쓸만한 타이틀을 얻도록 하는 것은 충분히 어렵기 때문이다.방해할 필요 없어봇은 동일한 편집에서 제목과 데드 링크 태그를 추가할 가능성이 별로 없으므로 나중에 별도의 작업으로 데드 링크 태그를 수행하면 추가 편집이 거의 없을 것이다.~Kvng (대화) 22:44, 2022년 1월 25일 (UTC)

왜냐하면 우리가 쓸만한 타이틀을 얻도록 하는 것은 충분히 어렵기 때문이다.그렇지 않다는 것만 빼면.당신은 우리가 이미 고친 5개의 버그를 식별했다.봇은 동일한 편집에 제목과 데드 링크 태그를 추가할 가능성이 별로 없다. 제목과 데드 링크 분리 기능은 유사하지만 동일하지는 않다.제목이 적절하지 않을 경우, 그것은 ref를 그냥 둘 것이다.링크가 비활성화된 경우 Dead 링크 템플릿을 배치한다.Rlink2 (대화) 22:58, 2022년 1월 25일 (UTC)

@Rlink2:소프트웨어 개발 경험이 얼마나 많은지는 모르겠지만, 내 경험에 따르면 남아 있는 버그 수는 이미 보고된 버그 수와 직결되어 있다.모든 프로그램이 비슷한 수의 버그를 가지고 있고, 더 많이 찾아서 고칠수록 소프트웨어가 더 좋다고 가정하는 것은 잘못된 것이다.현실은 소프트웨어의 질과 문제의 복잡성이 크게 다르고 어떤 소프트웨어는 다른 소프트웨어보다 훨씬 많은 문제를 가지고 있다.나는 너의 작업에서 몇 가지 문제점을 빨리 발견했으니 아직 더 많은 문제를 찾을 수 있을 거라고 생각해.~Kvng (대화) 14:12, 2022년 1월 26일 (UTC)

@Kvng: 주의가 산만해지지 않는다.URL을 입력하는 첫 번째 단계는 HTTP 요청을 하는 것이기 때문에 URL을 비활성 상태로 태그하는 데 필요한 정보는 항상 봇이 사용할 수 있다.만약 그 요청이 404 에러로 실패한다면, 우리는 죽은 링크를 가지고 있다.이것은 매우 간단한 이진법 결정이다.

당신의 낮은 우연의 일치에 대한 주장은 거의 맨 URL로만 작업한 나의 수개월의 경험과는 정반대다.실시간 및 비활성 상태의 맨 URL을 모두 사용하는 페이지의 발생률이 매우 높다.따라서 여기서 하지 않는 것은 많은 추가 편집을 의미할 것이고, 더 중요한 것은, 실제로 죽은 URL을 채우기 위해 반복적으로 노력하는 훨씬 더 많은 수의 낭비된 인간과 봇 직업들을 의미할 것이다.브라운헤어드걸(대화) • (출연) 23:01, 2022년 1월 25일 (UTC)

PS 단지 설명을 위해, 404 오류는 죽은 URL을 신뢰성 있게 나타낸다. GreenC는 URL이 확실히 죽었지만 404는 반환되지 않는 다른 결과들이 많으며, 그러한 결과들은 복수 패스할 수 있다고 지적한다.그러나 나는 어떤 거짓된 404s도 보지 못했다. (몇 가지는 있을지 모르지만 매우 희귀하다.)브라운헤어드걸(대화) • (출연) 04:59, 2022년 1월 26일 (UTC)

@BrownHailedGirl: 나는 이것에 대한 너의 경험을 존중해.나는 내가 검토한 50개의 수정사항에서 그 사건들 중 어떤 것도 찾지 못했다.아마도 그것은 주립 랭크2의 도구 때문일 것이다.

나는 주의를 산만하게 하는 것이 없다는 것에 동의하지 않는다.내가 들어오기 전에 우리는 이미 이것을 시행하는 것에 대한 세부사항에 대해 논의하느라 정신이 없었다. 그리고 우리는 계속 집중하자고 제안했다.~Kvng (대화) 14:12, 2022년 1월 26일 (UTC)

@Kvng: 산만하다는 그 이야기는 솔직하지 못하다.당신이 오해한 것에 대한 설명을 요구하는 토론으로 변질시키기 전에 이것에 대한 두 개의 짧은 게시물이 있었다.브라운헤어드걸(대화) • (출연) 14:22, 2022년 1월 26일 (UTC)

그 과정을 끌어내는 데 열을 받아서 기쁘다.내가 하려고 하는 것과는 정반대여서 분명히 나는 잘 하고 있지 않다.나는 여전히 우리가 스코프 크리프와 싸워서 누락된 타이틀을 채우는 것을 고수해야 한다고 생각한다.~Kvng (대화) 00:21, 2022년 1월 27일 (UTC)

이미 설명했듯이, 죽은 링크에 태그를 붙이는 것은 작업 목록에서 불용품을 제거하기 때문에 제목을 채우는 과정에서 중요한 부분이다.

그리고 내가 이미 설명했듯이, 그것은 봇이 이미 가지고 있는 정보를 이용하는 매우 간단한 작업이다.브라운헤어드걸(대화) • (출연) 00:45, 2022년 1월 27일(UTC)

그래, 네가 설명했고 내가 읽었는데 내 입장을 바꾸라고 설득하진 않았어.나는 이것에 대해 확고히 하는 것이 내가 원하는 바를 얻는 것을 의미하지 않는다는 것에 감사한다.~Kvng (대화) 00:56, 2022년 1월 27일 (UTC)

소스 코드

미세 조정 얘기가 나와서 말인데, 소스 코드를 게시할 생각이세요?코드 리뷰를 통해서 추가 곶감을 확인할 수 있을 것 같아.~Kvng (대화) 22:44, 2022년 1월 25일 (UTC)

바라건대, 하지만 지금은 아니야."코드 리뷰"는 당신이 생각하는 방식으로는 그다지 유용하지 않을 것이다.만약 벌레가 있다면 언제든지 신고할 수 있다.Rlink2 (대화) 22:54, 2022년 1월 25일 (UTC)

@Rlink2:나는 이것에 대해 너와 의견이 달라야 한다.일반적인 원칙으로서, 나는 오픈 소스 코드에 매우 찬성한다.그것은 위키피디아와 같은 협력적 환경에서 더욱 강하게 적용되기 때문에, 나는 예외를 둘 만한 충분한 이유가 없는 한 코드를 사용할 수 있어야 한다는 기본적인 가정으로 봇에게 접근한다.

코드를 게시하면 다음과 같은 몇 가지 이점을 얻을 수 있다.

그것은 다른 편집자들이 그 코드가 그것이 주장하는 대로 행동하는지 검증할 수 있게 한다.
그것은 다른 편집자들이 버그를 찾도록 도와준다.
그것은 관련 업무를 위한 도구를 개발하고자 하는 다른 사람들을 돕는다.

그래서 만약 봇 소유자가 소스 코드를 발행하지 않는다면, 나는 그것이 왜 보류되고 있는지에 대한 좋은 설명을 기대한다.브라운헤어드걸(대화) • (출연) 00:35, 2022년 1월 26일 (UTC)

@BrownHairdGirl:그래, 네 관점을 보니 좋구나.그럼 내가 확실히 오픈소스로 만들게언제 내가 그것을 눈감아 줄까?이번 주 후반에 링크를 제공할 수도 있고, 아니면 봇이 재판에 들어갈 때까지 기다려야 할까?내가 그 코드를 어디에다 붙이겠어?네 의견 고마워.Rlink2 (대화) 00:39, 2022년 1월 26일 (UTC)

@Rlink2:자네에게 달렸어, 하지만 내 관행은 내가 재판을 시작할 준비가 되면 언제든지 그걸 이용할 수 있게 하는 거야.그것은 보통 재판이 허가되기 전이다.

나는 보통 BRFA 페이지의 하위 페이지(또는 페이지)에 코드를 넣는다.브라운헤어드걸(대화) • (출연) 01:06, 2022년 1월 26일 (UTC)

@BrownHairdGirl: 좋아, 네 본보기를 따라 가능한 한 빨리 (이번 주에는 더 늦도록) 눈감아 줄께.하위 페이지는 훌륭하고, 좋은 생각이고, 모든 것을 위키에 보관한다.Rlink2 (대화) 01:11, 2022년 1월 26일 (UTC)

위키백과에 예비 코드가 있다.Bots/Requests_for_승인/BareRefBot/코드.스크립트에는 그것보다 더 많은 것이 있지만(예: 네트워킹 코드, 위키텍스트 코드 ) 이것이 그것의 핵심이다.시간이 지날수록 더 많이 출시될 것이고 나는 추가 부분에 대해 언급할 시간이 있다.Rlink2 (대화) 20:08, 2022년 1월 26일 (UTC)

위키백과 대화에서의 코드 검토 의견 및 토론:Bots/승인 요청/BareRefBot/코드

시험

평가판 승인(50개 편집) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.위에서 언급했듯이, 이것이 봇이 재판에 회부되는 유일한 시간은 아닐 가능성이 높고, 비록 이번 1차 시험에서 100% 성공하더라도 피드백에 따라 더 큰 시험으로 출하될 수도 있다.프라임팩 (대화) 14시 12분, 2022년 1월 26일 (UTC)

@Rlink2: 재판의 보고서에는 편집된 목록뿐만 아니라 봇이 건너뛴 페이지 목록도 포함될 수 있는지요.그 정보는 봇을 평가하는 데 매우 유용하다.브라운헤어드걸(대화) • (출연) 14:25, 2022년 1월 26일 (UTC)

@BrownHairdGirl: 알았어.Rlink2 (대화) 20:07, 2022년 1월 26일 (UTC)]]

@Primfac: 시험용 봇에 AWB를 활성화해 주시겠습니까?감사합니다.Rlink2 (대화) 21:43, 2022년 1월 26일 (UTC

@Rlink2:BRFA에 연결된 편집 요약과 함께 자신의 계정에서 평가판 편집을 수행하는 데 문제가 없다고 본다.

[[WP:BRFA/BareRefBot BareRefBot]] trial: fill 3 [[WP:Bare URLs]]</ref>

... 렌더링되는 항목: BareRefBot 평가판: 3개의 WP:Bare URL 채우기

그것이 내가 BRFA로 한 것이다.브라운헤어드걸(대화) • (출연) 18:06, 2022년 1월 27일 (UTC)

@BrownHairdGirl:알았어, 오늘 이따가 할게.조언해줘서 고마워.Rlink2 (대화) 18:11, 2022년 1월 27일 (UTC)

평가판 완료.편집 내용을 보려면 여기를 참조하십시오(페이지 비트가 로드되는 속도가 느림).내가 오래된 데이터베이스 덤프에서 일하고 있기 때문에, 봇이 건너뛴 것은 이미 Cite Bot이 맨 조회수를 채웠다.만약 스크립트의 버그 때문에 하나를 건너뛰거나 건너뛰었다면, 나는 그것을 나열하고 메모했을 것이다.링크2 (대화) 03:18, 2022년 1월 28일 (UTC)

다음은 기여자 목록의 기존 경로를 통한 편집 목록이다. ~~https://en.wikipedia.org/w/index.php?title=Special:Contributions/Rlink2&offset=202201280316&dir=next&target=Rlink2&limit=53~~

53개의 편집이 있었고, 오히려 승인된 50개가 있었다.브라운헤어드걸(대화) • (출연) 03:27, 2022년 1월 28일 (UTC)

우웩! AWB가 50이라고 해서 편집 카운터가 AWB로 약간 꺼진 것 같아.어쩌면 내가 실수로 세션을 중단해서 편집 카운터 같은 걸 리셋했는지도 몰라.정확히 어떻게 작동하는지 확실하지 않다.미안하다.그러나 3 2개 편집(실제 양은 53개가 아니라 52개인 것 같음)만 더 편집하면 되니까 큰 차이는 없을 것 같다.Rlink2 (대화) 03:38, 2022년 1월 28일 (UTC)

미안, 52점이야.위의 나의 기여목록에는 비기사 편집 1개가 포함되어 있었다.여기 고정된 기여 목록: https://en.wikipedia.org/w/index.php?target=Rlink2&namespace=0&tagfilter=&start=&end=&limit=52&title=Special%3AContributions

그 자체로는 별것 아닌 것 같다.그러나 봇이 정밀 조사를 받을 때는 미공개 개표 오류가 크게 보이지 않는다. --브라운헤어드걸(토크) • (출연) 13:50, 2022년 1월 28일(UTC)

뭐, 뭐, 그건 봇코드 문제가 아니라 과대계상 한 내 인간 실수였어.다음 번에는 정확히 50개 수정하도록 할게.미안하다.Rlink2 (대화) 14:03, 2022년 1월 28일 (UTC)

나는 이것에 대해 잘 모르지만, 나는 이 방법이 50번의 편집을 한 후에 봇이 멈추도록 프로그램을 짜는 것이라고 생각했다.레비비치 18:46, 2022년 1월 28일 (UTC)

나는 수동으로 AWB로 재판을 했는데, 유화스럽게도 AWB 카운터가 약간 도청되어 있다.만약 내가 봇 프레임워크를 사용했다면 정확히 50으로 만들 수 있었을 텐데.링크2 (대화) 21:28, 2022년 1월 28일 (UTC)

@Rlink2:나는 AWB 버그는 매우 가능성이 없다고 생각한다.나는 16년 동안 약 150만 건의 AWB 편집을 했고, 카운터에서 버그를 본 적이 없다.

나는 그 오류가 봇이 변경 없이 페이지를 저장한 데서 일어났을 가능성이 가장 높다고 생각한다.그러면 AWB의 편집 카운터가 증가하지만, 서버는 이를 WP로 볼 수 있다.Null 편집, 새 수정본 작성 안 함.

이를 피하기 위해 사용하는 한 가지 기술은 봇이 변수를 조항에 복사하도록 하는 것이다.텍스트에서 FixedArtitleText로.모든 변경사항은 FixedImpleText에 적용된다.그 후 모든 처리가 완료된 후 최종적인 건전성 확인으로서, 나는 기사 여부를 시험한다.텍스트 == 고정 문서텍스트...그리고 만약 그들이 같다면, 나는 페이지를 건너뛴다.브라운헤어드걸(대화) • (출연) 00:17, 2022년 1월 29일(UTC)

나는 그 오류가 봇이 변경 없이 페이지를 저장한 데서 일어났을 가능성이 가장 높다고 생각한다. 이것이 가장 유력한 설명이다.Rlink2 (대화) 01:13, 2022년 1월 29일 (UTC)

더 많은 편집이 이루어지기 보다는 덜 편집되는 것 같기 때문에 나는 이것을 이해할 수 없다.~~~
사용자:1234qwer1234qwer4 (대화) 17:53, 2022년 1월 29일(UTC)

뭐, 뭐, AWB로 대본을 수작업으로 사용했기 때문에 50을 넘은 것은 내 인간적인 실수였다.봇이나 대본에는 문제가 없다.Rlink2 (대화) 17:59, 2022년 1월 29일 (UTC)

몇 가지 생각:

있는 것 같다. title=xxx - yyy그리고 url=zzz.com, 그리고 zzz는 xxx 또는 yyy와 같으며, 제목에서 제거하고 다음에 추가하는 것이 안전해야 한다. website=. (혹은){{!}}또는 대시 대신 긴 대시).일반적인 것으로 나타남: A1, A2, A3, A4, A5
위와 유사하게 Zzz의 축약 버전을 확인할 수 있다: B1, B2, B3
FindArticles.com은 위키피디아에서 흔한 사이트다: C1 또한 많은 소프트-404s이다."죽은" 링크 때문에 제목이 틀리게 된 것 같아.
GoogleNews는 특별한 규칙을 가질 수 있는 일반적인 사이트: D1

-- GreenC 15:18, 2022년 1월 28일 (UTC)

그리고 zzz는 xxx 또는 yyy와 같으므로 제목에서 지우고 "website"에 추가하는 것이 안전해야 한다. 내가 말했듯이, 스크립트는 할 수 있을 때 이렇게 한다.많은 것들 중에서 이 차이를 하나의 예로 보아라.당신이 링크하는 몇몇 다른 것들도 이러한 행동을 보여준다."할 수 있을 때"에 대한 강조 - 의미 있는 제목 필드가 잘못된 형식의 웹사이트 필드보다 낫기 때문에 주의의 측면에 있다.또한 당신이 링크한 디프트의 일부는 웹사이트의 메인 페이지의 인용문들이기 때문에, 그 경우에는 "일반적인" 제목이 나올 것으로 예상된다.

당신이 연결한 몇몇의 것들에서도, 단지 하나의 스플라이스가 아니라 두 개의 스플라이스가 있기 때문에, "RPGGeek"와 "RPGGeek"의 차이를 구별할 수 있는 확실한 방법은 없다.

findarticles.com - "죽은" 링크 때문에 제목이 잘못되었다.그래, 잘 알겠다.이 스크립트는 여러 사이트에서 동일한 제목을 사용할 때 탐지할 수 있는 기능이 있다.

구글뉴스는 내가 그것을 본 특별한 규칙이 있을 수 있는 흔한 사이트다.제목이 원래 URL보다 더 많은 정보를 담고 있어서 괜찮다고 생각했는데, 전체 포인트인 거지?너는 무슨 특별한 규칙을 예언하고 있니?링크2 (대화) 15:36, 2022년 1월 28일 (UTC)

A1: 제목{{!}} RPGGeek== rpggeek의 url.따라서 제목이 다음과 같이 분할될 경우{{!}}이 성냥이 나타나다.그것은 문자 그대로의 일치(사례 이외에는)가 안전해야 한다.
A2: A1과 같다."-"를 따라 나누면 URL과 문자 그대로 일치한다. 공백과 대/소문자를 조정한다.
A3: 제목과 동일{{!}} Air Journal그리고 url은 공중파라..이 경우, 평탄한 케이스와 URL의 공간 또는 대시 테스트를 수행하십시오.
A4: 제목과 URL에서 iReadShakespeare와 동일.
A5: 또 다른 RPGGeek
D1: 예를 들어 제목에서 "Google 뉴스 아카이브 검색"을 제거하여 "Google 뉴스" 작업을 설정하는 경우 사이트별 규칙

-- GreenC 18:09, 2022년 1월 28일 (UTC)

A1, A2, A3: 반쪽은 제목에, 반쪽은 웹사이트 필드에 있는 상태에서 나는 스크립트 코드를 맹목적으로 모든 스플라이스를 만들지는 않았다.그것은 사이트들이 무엇이든 넣을 수 있기 때문에 버그 통을 열어준다.스크립트가 분할되려면 품질 보장이 필요하다.그러한 품질 보증을 갖게 되면 공항 기사 diff의 일부 URL에서 그랬던 것처럼 제목을 분할하고 웹사이트 매개변수를 배치하게 된다.

엔위키에 소스를 많이 사용하면 목록으로 인해 별 생각 없이 공통적인 부분을 제거하기 쉽다.그러나 제목의 공통적인 부분은 웹사이트 매개변수에 반드시 적합한 것은 아니다(예를 들어, 위의 웹사이트는 RPGgeek.com이지만, 제목의 공통적인 부분은 "제목 RPGgeek.com"이다.물론 "마지막 스플라이스를 가져라"라고 말할 수도 있겠지만, "RPGgeek.com 기사"를 하는 다른 사이트가 있다면 어떨까?많은 웹사이트 구성이 있기 때문에 우리는 포스텔의 법칙을 따르고 그것을 안전하게 재생해야 한다.

이를 웹 사이트 매개 변수에 적합한 IMDB와 비교하십시오.따라서 이 대본은 추가 정보가 어디로 가야 하는지 확실하지 않다면 제목에서 일반적인 부분을 삭제하지 않을 것이다.우리는 그 인용문을 더 적게는 아닌 더 유익한 것으로 만들고 싶다.

A4: 웹 사이트 이름은 말장난의 제목 중 일부야, 자세히 봐.우리가 무작정 물건을 제거하고 나누기만 하면 웹사이트 제목을 지우고 싶지 않은 경우가 바로 이것이 만들어지는 문제들 중 하나이다.그리고 그것은 또한 주요 웹페이지의 인용이다.

D1 - 그래, 괜찮겠다.좋은 제안이야.Rlink2 (대화) 18:49, 2022년 1월 28일 (UTC)

A에게는..A3 단순한 것이 아니라 문자 그대로의 일치다.리터럴 일치 여부를 검정하십시오.A1로 좀 더 명확하게 하려면:

제목 찾기 =whatever {{!} whatever {{!}} RPGGeek. 그리고 기존 url=rpggeek.com. 끈을 따라 나누십시오.{{!}}(또는 대시).이제 세 개의 현이 있다: "whatever," "whatever," "RPGeek".세 문자열 각각에 대해 기본 URL 문자열과 비교하십시오. 이 경우 "rpggeek".비교 1: "whatever" != "rpggeek".비교 2: "아무거나"!= "rpggeek".비교 3: "RPGGeek" == "rpggeek" - 일치하는 것을 찾았어!따라서 두 가지 작업을 안전하게 수행할 수 있다: 제거{{!}} RPGGeek제목에서, 그리고, 추가 website=RPGGeek이 규칙/시스템은 모든 예에 대해 적용되어야 한다.URL 문자열 비교를 수행할 때 제목 문자열에서 공백을 제거하거나 "-" 및/또는 소문자로 교체해야 할 수 있다.A4가 분할된 경계선을 따라 합법적으로 사용되었을 때 기존 타이틀을 망치고 싶지 않다는 당신의 말이 무슨 뜻인지 알겠다. 문제는 얼마나 흔한가 하는 것이다. -- GreenC 19:14, 2022년 1월 28일 (UTC)

BTW 만약 네가 그것을 하는 것이 불편하다면, 하지 마.95%가 정확하고 5%가 틀릴 수 있기 때문에 95%를 위해 아무것도 하지 않는 것에 비해 그 효용성을 따져봐야 한다 -- GreenC 19:51, 2022년 1월 28일 (UTC)

@GreenC:너의 통찰력에 감사하고, 나는 이것을 실행하려고 생각하겠다.이미 한 것 같은데, 내가 올린 업데이트 소스 코드를 봐.나는 당신이 요구하는 것을 실행할 수 있다. 그것은 스플라이스 다음에 오는 도메인이다.예를 들어 웹사이트가 "encarta.com"이고 제목이 "Wiki Encata.com"이라면 "encarta.com"은 분할할 수 있지만, "Wiki Enkarta Encylopedia - The Payed Encylopedia"라면, 웹사이트 이름 검색에 도움이 되는 다른 메타데이터가 없는 "Wiki Encylopedia - the Payed Encylopedia"라면, 그 일은 다루기 어려운 상황이므로 나는 전혀 분할하지 않는다.링크2 (대화) 21:28, 2022년 1월 28일 (UTC)

나는 이 모험에 대한 나의 기여가 ANI에서 스페인 종교재판을 재연하는 데 국한되지 않도록 52년을 다 겪었다.

특수:Diff/1068376250 - 맨 링크가 최소한 "Goodreads.com"이라고 되어 있는 반면, 인용 템플릿은 책의 제목인 제목만 주고 위키백과 기사 제목과 같기 때문에 맨 링크는 인용 템플릿보다 독자들에게 더 유익했다.따라서 이 경우, 봇은 유용한 정보를 추가하기보다는 유용한 정보를 제거(또는 인용 템플릿 뒤에 숨김)했다.나는 이 편집이 어떻게 개선되었는지 모르겠다.
특수:Diff/1068372499 - 마찬가지로, 여기서 봇은 "Pagina sin titulo"("제목 없는 페이지")라는 제목으로 맨 URL을 aviancargo.com으로 대체했다.이것은 도메인 이름의 유용한 정보를 숨기고 쓸모없는 페이지 제목으로 대체한다.이 편집의 이 부분은 개선이 아니다.
특수:Diff/1068369653 - 기본 URL의 영어 도메인 이름을 외국어 문자를 사용하여 인용 템플릿 제목으로 대체.개선사항이 아니다; 영어를 사용하는 독자는 인용 템플릿보다 기본 URL에서 더 많은 것을 배울 것이다.
특수:Diff/1068369064 - website=DR보다 적은 것을 말해주다www.dr.dk하지만 그게 화이트리스트에 문제가 있는 건 아닐까?
특수:Diff/1068369849 - 웹 사이트 제목을 통해 프로모션을 추가한 예: 이 경우 소스의 태그라인, "큰 소리로 커뮤니티에!"
- Special에 대해서도 비슷한 고민을 하고 있다.Diff/1068369121은 인용 템플릿에 "Google 뉴스 아카이브 검색"을 눈에 띄게 추가하기 때문이다.하지만 news.google.com은 이미 맨 URL에 들어가 있었고, 봇도 신문의 이름을 덧붙이고 있어 유용한 정보를 추가하고 있다.내 프로모션에 대한 우려는 이렇게 약하다.
특수:Diff/1068368882, 특수:Diff/1068375545, 특수:Diff/1068369433(첫 번째) - 비활성 URL로 태그가 지정되었지만 비활성 URL이 아닌, 모두 라이브 웹 사이트로 이동하며,
특수:Diff/1068375631 및 특수:Diff/1068369185 - 비활성 URL로 태그가 지정되었지만 404가 아닌 503으로 다시 표시됨.유사하게 특별함:Diff/1068372071은 404가 아닌 522이다.특수:Diff/1068376097은 404가 아닌 타임아웃으로 나에게 돌아온다.특수:Diff/1068376127은 404가 아닌 DNS 오류로 표시됨.'죽은 URL'이 503과 522s, 타임아웃, DNS 오류, 나머지 모든 것에도 적용된다면, 404s만이 아니라 내가 언급할 줄 알았는데 문제가 되지 않을 수도 있다.

#1-4의 우려는 단순히 덧셈으로 해결할 수 있을지 궁금하다. website=[domain name]인용문 템플릿에?그러면 적어도 기본 URL에서 유용한 도메인 이름을 보존할 수 있을 것이다. 5번은 이전 실행에서 나온 것처럼 나에게 중요한 것이다.비록 이 프로모션 문제가 2%의 시간만 발생한다고 해도, 만약 우리가 이것을 20만 페이지에 실행한다면, 그것은 우리가 백과사전에 추가할 4,000개의 프로모션 문장이 될 것이다.개인적으로, 나는 그것이 너무 높은 것인지, 그렇지 않은 것인지 아니면 맨 URL을 인용 템플릿으로 변환하는 혜택에 대해 지불해야 할 대가인지 모르겠다.(하지만, 개인적으로 인용 템플릿에는 별로 쓸모가 없다고 생각되기 때문에 나는 이 문제에 편향되어 있다.6번도 문제인데, 위에서 언급한 것처럼 하나의 핑을 기준으로 어떤 것을 죽은 것으로 꼬리표를 붙이면 충분한지 의문이다.#7은 전혀 문제가 되지 않을지도 모른다, 나는 알고 있다.이것이 도움이 되기를 바라며, 특히 Rlink에 대한 당신의 연구에 관련된 모든 사람들에게 감사한다.레비비치 18:19, 2022년 1월 28일 (UTC)

@Levivich: 나는 이 모험에 대한 나의 기여가 ANI에서 스페인 종교재판을 재연하는 데 국한되지 않도록 52년을 모두 거쳤다.시간을 내어 편집된 내용을 검토해주셔서 감사드리며, 이곳과 ANI에서 모두 정중함과 선의를 표해 주셔서 감사드린다.~~위키미디어 아카이브 전쟁 2는 피했으면 좋겠다. 위키미디어 아카이브 전쟁 1은 모든 전쟁을 끝내기 위한 전쟁이었고, 많은 사건들이 있었고, 우리~~는 또 ~~다른 것이 필요~~하지 않다. 아카이브 사이트에 대한 논쟁은 어리석다고 생각하는 만큼, 이 언급들은 갈등이 시작되기 전에, 지금 매우 실제적인 전쟁을 통해 고통 받고 있는 모든 사람들을 존중하자... 주제에서 벗어난 농담은 제쳐두고...

특수:Diff/1068369064 - DR과 DR.dk의 차이는 매우 미미하다.게다가, "DR"은 통신사/웹사이트의 이름이기 때문에, 그것이 더 정확한 IMO이다.

그리고 404대가 아닌 것에 대해서는 최근에 게이터를 404 링크만 잡도록 업그레이드했을 뿐 다른 것은 아무것도 잡지는 않았다고 이전에 설명한 적이 있다."404"가 아닌 당신이 연결한 디프들은 대부분 실제 여전히 비활성 링크인 반면, 여기서의 합의는 단지 404 상태 코드 반환을 "데드 링크"로 표시하는 것이었습니다. 그래서 나는 그 변화를 만들었다.이 세트에 사용된 '데드링크' 데이터는 그 변화가 404대만을 반영하기 전에 수집되었고, 나는 그 사실이 있은 후에야 깨달았다.'완전히' 살아서 죽은 것으로 표시되는 것에 대해서는, 시간 초과 오류일 뿐일지도 모른다(404는 아니지만 나에게 맞지 않는 것은 그냥 내버려 둘 것이기 때문에, 지금 문제가 되는 것은 아니다).

비록 이 프로모션 문제가 2%의 시간 동안만 발생하더라도.그것보다 적다.이것을 보여주는 것은 오직 한 가지 차이점이 있었던 것 같다.그리고 만약 큰 이슈가 된다면 나는 단어들을 블랙리스트에 올릴 수 있고 그것들을 채우지 않을 수 있다.

나는 개인적으로 인용 템플릿에 별로 쓸모가 없다고 본다.뭐, 보통은 상관없어하지만 우리는 인용문에 정보를 추가하고 있고 인용문 템플릿은 그렇게 하는 데 있어 자유롭다.

이것이 도움이 되기를 바라며, 특히 Rlink에 대한 당신의 연구에 관련된 모든 사람들에게 감사한다. 고마워, 그리고 위키피디아에서도 네가 열심히 해줘서 고마워.하지만 BHG가 없다면 이 중 어느 것도 불가능할 것이다.그녀는 이 모든 것의 기초를 닦았다.그녀가 개입하지 않았다면 이것은 불가능했을 것이다.맨주먹만 고치는 그녀의 역할은 나보다 훨씬 크다.나는 그저 내 작은 역할인 "도움"을 하고 있을 뿐이다.하지만 그녀는 모든 전문지식을 가지고 있다.링크2 (대화) 21:28, 2022년 1월 28일 (UTC)

나는 첫 25개 수정 사항을 검토하는 시간을 가졌다.내 연구 결과:

[23]은 인증서 발급(SSL_ERROR_BAD_CERT_DOME)이며, 위험을 감수하고 싶은 경우 아마도 액세스할 수 있을 것이다.이것을 데드 링크로 표시하는 것이 옳은가?

[24 ], [25], [26], [27] 왜 없는 건지 모르겠다. website=이 위에

[28] 첫 번째 링크는 죽은 것으로 보이지 않는다.
[29] 첫 번째 링크는 죽은 것으로 보이지 않는다.
[30] 먼저 죽은 고리로 보인다.
[31] https://www.vueling.com/en/book-your-flight/flight-timetables은 데드 링크가 아닌 것으로 보인다.
[32] https://thetriangle.org/news/apartment-complex-will-go-up-at-38th-and-chestnut/에서 Cloudflare 연결 시간 초과를 보고하고 있다.이것을 데드 링크로 표시하는 것이 옳은가?

맨 링크 제목에 대한 문제는 대부분 website=매개 변수이것을 분류하는 코드는 도서관에 있고 게시된 것이 아니고 나는 그것이 어떻게 작동하는지 알지 못하며 나는 그것이 우리가 원하는 것을 하고 있는지 확신할 수 없다.자세한 내용은 코드 검토 페이지를 참조하십시오.~Kvng (대화) 18:25, 2022년 1월 28일 (UTC)

이것을 데드 링크로 표시하는 것이 옳은가? (SSL_ERROR_BAD_CERT_DOME 관련) 나는 그것을 보았다.SSL 오류(Chrome 또는 Chromium 기반 브라우저에서 "Thisisunsafe"로 입력)를 클릭하면 다른 페이지로 리디렉션되는 것을 볼 수 있다.만약 당신이 더 자세히 본다면, URL에 임의의 문자를 추가하면, 같은 페이지로 리디렉션된다. 즉, 그 웹사이트에 포괄적으로 리디렉션이 있다는 것을 의미한다.그래서 그렇다, 나는 그것을 죽은 것으로 표시하는 것이 옳다고 생각한다.

그 발견에 관해서는, 그렇다, 그것은 이미 보고되었다.리디렉션 부분을 추가해야 할 것 같아, 여러 URL이 동일한 URL로 리디렉션되면 비활성 상태로 표시해.그래서 그거 보고해줘서 고마워.

왜 웹사이트가 없는지는 이해가 안가, 앞에서 설명한 것처럼 웹사이트 매개변수가 정확하고 유효한 것이 확실할 때만 웹사이트 매개변수를 추가하게 된다.", "-"와 같은 어떤 등장인물을 구분하는 것은 분명해 보이지만 그것만으로 발생할 수 있는 많은 버그들이 있다.

이것을 데드 링크로 표시하는 것이 옳은가?그 링크는 나에게 통하지 않는다.나는 여러 브라우저에서 테스트를 했다.Rlink2 (대화) 18:47, 2022년 1월 28일 (UTC)

@Kvng 및 Levivich:나는 항상 그 접근법이 website=매개변수는 다음과 같아야 한다.

웹 페이지 또는 룩업 테이블에서 신뢰할 수 있는 결정을 내릴 수 있는 경우 웹 사이트 이름 사용
또는
웹 사이트 이름을 사용할 수 없는 경우 URL의 도메인 이름을 사용하십시오.

예를 들어, https://www.irishtimes.com/news/world/europe/munich-prosecutors-sent-child-abuse-complaint-linked-to-pope-benedict-1.4788161의 기본 URL 참조를 참조하십시오.

만약 봇이 웹사이트 이름이 "아일랜드 타임즈"라고 믿을 수 있다면, 인용 템플릿은 다음을 포함해야 한다. website=The Irish Times

... 그러나 만약 봇이 웹사이트의 이름을 신뢰성 있게 결정할 수 없다면, 인용 템플릿은 다음을 포함해야 한다. website=www.irishtimes.com.

나는 그 견해를 가지고 있다. 왜냐하면 이름 없이, 우리는 인용문을 어떻게 형성할 것인가에 대해 두 가지 선택권을 가지고 있기 때문이다.

A {{cite web url=https://www.irishtimes.com/news/world/europe/munich-prosecutors-sent-child-abuse-complaint-linked-to-pope-benedict-1.4788161 title=Munich prosecutors sent child abuse complaint linked to Pope Benedict}}
B {{cite web url=https://www.irishtimes.com/news/world/europe/munich-prosecutors-sent-child-abuse-complaint-linked-to-pope-benedict-1.4788161 title=Munich prosecutors sent child abuse complaint linked to Pope Benedict website=www.irishtimes.com}}

이 두 가지 옵션은 다음과 같다.

A:"Munich prosecutors sent child abuse complaint linked to Pope Benedict".
B: "Munich prosecutors sent child abuse complaint linked to Pope Benedict". www.irishtimes.com.

옵션 A는 매우 성가신데, 그 이유는 일본이나 잠비아, 러시아나 볼리비아의 웹사이트에 그 기사가 뜨는지, ii) 출처가 평판 좋은 신문인지, 당파적인 정치 사이트인지, 블로그인지, 포르노 사이트인지, 풍자 사이트인지, 전자상거래 사이트인지에 대한 표시를 주지 않기 때문이다.그것은 출처의 신뢰성에 대한 예비 평가를 하는 데 필요한 중요한 정보를 독자에게 박탈한다.

내가 보기에 옵션 B는 출처에 대한 정확한 설명을 제공하기 때문에 훨씬 더 유용하다.이름만큼 명확하지는 않지만, 없는 것보다 훨씬 낫다. 많은 경우 도메인 이름에서 출처를 쉽게 식별할 수 있으며, 이것은 그 중 하나이다.

이것은 많은 편집자들이 뒤따르는 관행이다.불행하게도 소수의 청교도들은 어떤 가치도 선호하지 않는다. website=대신에 website=domain name. 그들의 완벽하거나 아무것도 아닌 접근방식은 최상의(전체 웹 사이트 이름)이 선의 적인(도메인 이름)이 되도록 함으로써 맨 URL 채우기의 효용성을 현저히 약화시킨다.

나는 @Rlink2가 완벽하거나 아무것도 아닌 그런 청교도들과 어느 정도 만남을 가졌다는 것을 알고 있으며, 우려를 수용하려는 Rlink2의 칭찬할 만한 의지가 그들이 이 변두리 광신자들의 요구를 받아들이게 만들었을까 두렵다.나는 Rlink2가 완벽주의를 무시하고 독자들에게 효용성을 우선시하기를 바란다... 봇을 재구성하여 도메인 이름을 추가함으로써.브라운헤어드걸(대화) • (출연) 19:45, 2022년 1월 28일 (UTC)

나도 동의해.당신의 예에서 B가 A보다 나을 뿐만 아니라, 맨 링크에는 제목과 웹사이트 이름이 모두 들어있기 때문에 맨 링크가 당신의 예에서 A보다 낫다고 말할 수 있을 것이다.나는 인용 템플릿의 빈 웹 사이트 매개변수가 웹사이트 매개변수에 도메인 이름을 갖는 것보다 낫다고 생각하는 사람이 있는지 솔직히 보려고 애쓴다.레비비치 19:50, 2022년 1월 28일 (UTC)

@Levivich: 청교도주의는 사람들로 하여금 매우 이상한 입장을 취하게 할 수 있다.나는 URL만 채우는 것에 대한 다른 토론에서 정말 이상한 것들을 본 적이 있다.

이 특정 링크에 대해서는, 그것의 URL이 기사 제목에 파생된 것으로 형성되어 있기 때문에, 베어 URL은 꽤 유용한 정보를 제공한다.그래서 제목만 채우는 것이 실제로 개선인지 아닌지는 조금 뒤척인다.

그러나 일부 주요 웹사이트는 숫자 공식(예: https://www.bbc.co.uk/news/uk-politics-60166997) 또는 영숫자 공식(예: https://www.ft.com/content/8f1ec868-7e60-11e6-bc52-0c7211ef3198))으로 URL을 구성한다.그 (알파)숫자적 예에서는 제목만으로도 더 유익하다.

그러나 제목+웹사이트는 제목이 일반적이지 않다면 맨 URL보다 항상 더 유용하다.브라운헤어드걸(대화) • (출연) 20:12, 2022년 1월 28일 (UTC)

을 주제로 website=올바른 웹 사이트 제목을 결정하는 한 가지 방법은 도메인 이름으로부터의 리디렉션에 의존하는 것이다.그것은 irishtimes.com이 아일랜드 타임즈로 리디렉션되기 때문에, 그 봇은 덧붙이는 것을 알 수 있다. website=The Irish Times 그것은 수작업으로 유지되는 어떤 데이터베이스보다 더 포괄적일 것 같다.* 페퍼리 _{it has begun...}* 20:42, 2022년 1월 28일 (UTC)

그것은 좋은 생각이다. 나에게 @Pupery:를 알려줘서 고마워.네 생각은 언제나 여기서 환영이야.나는 평소처럼 BHG에 동의해야 한다.어떤 공감대가 형성됐는지 몰랐을 뿐 BHG와 레비치는 웹사이트 매개변수에 대해 명확한 사례를 제시한다.이거 대본에 넣어야지.커뮤니티 위시리스트 항목 중 하나는 VE를 기사 이외의 공간으로 가져오는 것이었어야 했다.이 사슬에 답장하는 것은 나에게 어렵다.링크2 (대화) 21:28, 2022년 1월 28일 (UTC)

@Rlink2: 훨씬 쉽게 회신하려면 Special로 이동하십시오.Preferences#mw-prefection-betafeatures를 선택하면 "토론 도구"(위에서 4번째 항목)가 활성화된다.

그렇게 하면 모든 시그니처 이후에 "답답장" 링크가 나올 것이다.브라운헤어드걸(대화) • (출연) 22:05, 2022년 1월 28일 (UTC)

고마워, 이 길이 훨씬 편해.Rlink2 (대화) 22:07, 2022년 1월 28일 (UTC)

@Pppery: 그러한 접근방식의 문제는 예를 들어, 일부 도메인 이름이 둘 이상의 게시를 호스트한다는 것이다.

theguardian.com / guardian.co.uk = The Guardian and The Observer
independent.co.uk = 일요일의 독립과 독립
independent.ie = 아일랜드 독립 및 일요 독립(아일랜드)
heraldscotland.com/ = The Herald (Glasgow)와 Sunday Herald

출판물의 이름을 찾으려고 노력하면 이 봇의 작업을 지나치게 복잡하게 만들기가 쉬울 것이다.하지만 도메인 이름만 쓰면 KISS가 더 좋다.브라운헤어드걸(대화) • (출연) 22:01, 2022년 1월 28일 (UTC)

말이 된다.나는 도메인 이름만 사용하는 것에 반대하지 않는다.* 페퍼리 * 22:10, 2022년 1월 28일 (UTC)

내 관심의 대부분은 죽은 링크 감지와 관련이 있다.이것이 내가 예상한 주의를 산만하게 하는 것으로 밝혀지고 있다.맨 링크와 데드 링크 편집이 있는 기사는 [33], [34], [35] 3개뿐이었다.이것들을 별도의 작업으로 실행하려면 12%의 편집이 더 필요할 것이고 나는 그것이 큰 문제가 아니라고 생각한다.다시 한번 데드 링크 감지 및 표시를 해제하고 베어 링크를 채우는 데 집중하도록 요청한다.

네가 연결한 링크들 중 많은 것들이 실제로 죽었어.그리고 그렇지 않았던 것들에 대해서는, 나는 대본이 더 자유분방했을 때의 데이터를 데드 링크로 태그하는 것에 사용한다고 생각한다. (이제 코드는 훨씬 더 엄격해졌고, 404s에 한한다.)나는 우리가 완전한 코멘트와 함께 진행함에 따라 소스 코드를 더 추가할 것이라고 말했다.Rlink2 (대화) 18:47, 2022년 1월 28일 (UTC)

@Rlink2: 쓸모없는 단편보다는 봇의 코드를 모두 발표함으로써 많은 드라마를 피할 수 있었을 것이다.다른 유능한 편집자가 AWB를 사용하여 봇을 완전히 복제할 수 있을 정도로 충분히 완전하게 지체 없이 그렇게 할 것을 제안한다.

응, 이 질문들에 대한 답변이 끝나는 대로 할게.Rlink2 (대화) 19:17, 2022년 1월 28일 (UTC)

또한, 25일에 내가 특별히 [36]에게 404 오류를 반환하는 베어 URL 참조를 {{데드링크}(날짜)로 봇에게 요청했는데, 당신은 1시간도 안 되어 [37]이라고 대답하여 "Ok, I can't can ok, I can do that.

이제 당신의 시험 실행에서 데드 링크 태깅은 사실상 404개의 오류로 제한되지 않았던 것 같다.나는 당신이 링크를 죽은 것으로 태그하기 위해 다른 근거를 사용하겠다고 밝힌 이 토론에서 어떤 의미도 없다고 본다.보고되지 않은 범위 변경이 봇 운영자에 대한 신뢰를 어떻게 약화시키는지 알 수 있는가?브라운헤어드걸(대화) • (출연) 19:15, 2022년 1월 28일 (UTC)

응, 대본을 업데이트하기 전에 오래된 자료에서 나온 버그라고 했잖아.미안하다.나는 그 사실을 알고 나서야 깨달았다.Rlink2 (대화) 19:17, 2022년 1월 28일 (UTC)

게시된 코드는 무용지물이 아니었다.그것은 내가 프로젝트를 이해하는 데 도움을 주었고 나는 Rlink2가 작은 발전을 이루도록 도와준 몇 가지를 지적했다.

나는 이 재판에 대한 약속과 수행 사이의 간극에 대해 화가 나지 않는다. 왜냐하면 그것이 원래 나를 이 일에 끌어들인 관찰이기 때문이다.Rlink2는 확실히 성실하게 일하고 있다. 고마워!진전이 있었고 곧 도착할 겁니다.~Kvng (대화) 21:29, 2022년 1월 28일 (UTC)

친절한 말 고마워.BHG에 대한 응답으로 나는 당신이 링크를 죽은 것으로 태그하는 데 다른 근거를 사용할 것이라고 당신이 공개한 이 논의에서 어떤 요점도 보지 않는다.나는 내 메인 계정으로 스크립트를 실행할 때 링크가 죽은 것으로 태그하기 위해 더 넓은 기준을 사용한다고 말했다.그러나 BRFA를 시작했을 때 404명의 응답만으로 범위를 제한했다.내가 한 일은 BRFA에 나열된 데드링크 크레테리아와 함께 새로운 배치를 실행하고 데이터를 사용하는 것인데, 나는 그것을 잊어버리고 BRFA 이전으로부터 수집된 베어 레퍼런스 데이터를 사용했기 때문에 데드링크(404가 아님)라는 것을 의미하는 다른 것들이 데드링크로 표시되었다.너를 실망시켜서 정말 미안해.다음에는 더 잘해서 조심할게.이를 위한 해결책은 이전 데이터에 대해 "데드 링크" 템플릿을 배치하지 않고 향후의 새 데이터에 대해서만 해당 템플릿을 배치하여 범위가 정의되도록 하는 것이다.

보고되지 않은 범위 변경이 봇 운영자에 대한 신뢰를 어떻게 약화시키는지 알 수 있는가?교활하게 굴거나 범위를 우회하려는 의도는 아니었다.

가장 중요한 것은 kvng가 한 말이다.진전이 있었고 곧 도착할 겁니다. 그렇다, 항상 개선되어야 할 것들이 있다.Rlink2 (대화) 21:44, 2022년 1월 28일 (UTC)

@Rlink2: 협력적인 회답은 고맙지만, 이것은 아직 해결되지 않았다.

당신은 봇이 1) 특정 기사를 포함하지 않고 공급되는 기사 목록이나 2) 이전의 http 요청에서 해당 URL로 캐슁된 데이터에 의존한다고 말하는 것 같다.

어느 쪽 접근도 안전하지 않다.코드는 404 오류에 대해 각 URL을 새로 확인해야 하며, {{Dead link} 태그를 해당 URL에만 적용해야 한다.

봇이 처리하는 페이지 목록은 그 동작과 무관해야 한다.사전 선택은 할 일이 없는 수천 페이지를 건너뛰지 않도록 함으로써 봇을 보다 효율적으로 만드는 좋은 방법이다.그러나 사전 선택은 봇이 처리하는 페이지를 정확하게 처리할 수 있도록 보장하는 코드를 대체하지 않는다.
이 작업에 대한 http 요청을 캐시하는 것은 좋지 않은 생각이다.그것은 오류에 대한 추가적인 벡터를 추가하며, 이는 기준 변경 후 플러시되지 않은 캐쉬의 이 사례에 국한되지 않는다.브라운헤어드걸 (대화) • (출연) 22:19, 2022년 1월 28일 (UTC)

나는 최근 Rlink2가 게시한 추가 코드를 완전히 검토할 기회가 없었지만, 간단한 보기에서는 다른 프로세스에 의해 채워진 것으로 보이는 URL의 데이터베이스를 사용한다는 것을 보여준다.그 데이터베이스는 재판을 위해 재구성되었어야 했고 그렇지 않았지만, 이러한 종류의 문제에 대한 2단계 접근법에는 근본적으로 잘못된 것이 없다.이 접근법을 사용한다면 페이지 목록은 정말로 관련이 있다.~Kvng (대화) 23:03, 2022년 1월 28일 (UTC)

특정 품목을 포함하지 않고 공급되는 물품 목록. 음, 일괄적으로 또는 개별 품목으로 작동해야 한다.

이 작업에 대한 http 요청을 캐시하는 것은 좋지 않은 생각이다.내가 'cache'를 변수 이름과 데이터베이스로 사용함에도 불구하고, 스크립트가 작동해야 하는 방법은 제목을 리터링하고 저장한 다음 바로 리터링하는 것으로, 추가 분석을 위해 제목을 저장하면서"새롭게 체크"하는 것으로 구성된다.그래서 제목을 얻는 대본과 기사 안에 넣는 대본이 있다.나는 후자를 위한 코드를 이미 공개했고, 전자에 대한 코드를 곧 공개할 것이다.나는 그들 중 몇몇을 위해 미리 Getter를 운영하려고 노력했지만, 너의 피드백 덕분에 더 이상 이것을 하지 않을 거야.Rlink2 (대화) 23:11, 2022년 1월 28일 (UTC)

@Rlink2: 내 요점은 배치 대 개별적인 기사와는 관련이 없었다.그것은 무언가 다른 것에 관한 것이었다. 즉, 어떤 사전 선택 과정에 의존하지 않는 것이다.

나머지 부분에 대해서는, 나는 그 봇이 실제로 어떻게 작동하는지 여전히 불분명하다.모든 코드와 AWB 설정을 게시하면 해결될 수 있다.

@Kvng: 두 단계 접근법의 근본적인 문제는 앞에서 설명한 바와 같다: 시험 운행에서 발생한 것처럼 오류에 대한 추가적인 기회를 만든다는 것이다.브라운헤어드걸(대화) • (출연) 00:04, 2022년 1월 29일(UTC)

나는 위키피디아에 "게터" 코드를 게시했다.Bots/Requests_for_승인/BareRefBot/Code2.만약 내가 뭔가를 놓쳤거나 뭔가 설명이 필요하다면 나에게 알려줘.나는 지금 조금 피곤하고, 하루종일 일하고 있어서, 내가 설명하는 것을 잊어버린 것은 완전히 불가능해.

다시 말하지만, 코드 공개 지연은 코멘트와 정리가 되어 이를 이해하고 봇이 실제로 어떻게 작동하는지 명확히 알 수 있도록 하고 있다(UTC(Link2 (토크) 01:08, 2022년 1월 29일 (UTC)

@Rlink2:나는 이제 막 재판을 평가하기 시작했고 두 가지 사소한 것을 알아차렸다.

봇은 인용 템플릿에 각 매개변수에서 등호 부호의 양쪽에 공백을 채우고 있다(예: website = Cricbuzz.
이는 위키마크를 편집 창에 워드포킹할 때, 공백이 매개변수와 값을 다른 선에 놓이게 할 수 있기 때문에 템플릿을 읽기 어렵게 만든다.예를 들어, 그러한 공간은 생략할 수 있다. website=Cricbuzz
경우에 따라 매개변수 값이 두 개 이상의 공백 뒤에 따른다.여러 개의 연속 공백 문자를 하나의 공백으로 대체하여 각 템플릿을 처리하기 위해 코드를 추가함으로써 이 문제를 없앨 수 있는가?

고마워. --BrownHairedGirl (대화) • (출연) 01:18, 2022년 1월 29일 (UTC)

봇은 인용 템플릿에 각 매개변수 Fixed에서 등호 부호의 양쪽에 공백을 채워 게시된 소스 코드에 반영하고 있다.

매개변수 값에 이어 두 개 이상의 공백이 완료되고 게시된 소스 코드에 반영된다.Rlink2 (대화) 01:22, 2022년 1월 29일 (UTC)

고마워 @Rlink2.빨랐어!브라운헤어드걸 (대화) • (출연) 01:24, 2022년 1월 29일 (UTC)

Comment Cite 템플릿은 참조 스타일을 사용하는 기사에만 추가되어야 하며, 참조 스타일을 탐지하고 기사 스타일의 수정된 참조를 유지하기 위해 무엇을 하고 있는가?키스 D (토크) 21:43, 2022년 1월 30일 (UTC)
@Keith D: 그럼 당신은 만약 기사가 다음과 같은 참조를 사용하고 있다면[https://google.com google], 그리고 맨 ref.<ref>https://duckduckgo.com</ref>로 전환되어야 한다.<ref>[https://duckduckgo.com Duckduckgo]</ref>인용문 템플릿 대신에 스타일?암호로 입력하면 돼Rlink2 (대화) 21:50, 2022년 1월 30일 (UTC
그것은 내가 그 경우에 기대했던 것이다.키스 D (토크) 21:53, 2022년 1월 30일 (UTC)
@Keith D: 나는 이것을 추가했지만, 그것을 반영하기 위해 여기에 게시된 소스 코드를 업데이트해야 할 것이다.Rlink2 (대화) 15:54, 2022년 2월 1일 (UTC)
@Rlink2:기다려.@Keith D의 요청을 실행하지 마십시오.

인용봇은 항상 브라켓이 있는 베어 URL을 인용 템플릿으로 변환한다.나는 이 봇이 왜 다르게 작동해야 하는지 모르겠다.

일부러 고사리 같은 스타일을 사용하는 몇 가지 기사가 있다.[https://google.com google] 그러나 그것들은 매우 희귀하다.내가 아는 유일한 경우는 월간 시리즈별 사망자, 예를 들어 2020년 5월의 사망자 등인데, 인용 템플릿이 그들을 비하하는 리프가 너무 많기 때문에 고사양식을 사용한다.그 페이지들은 그냥 건너뛰거나, 정의된 집합에 브라켓 형식을 적용하는 것이 훨씬 더 나을 것이다.브라운헤어드걸(대화) • (출연) 17:21, 2022년 2월 1일 (UTC)
인용 봇이 예술작품에 사용된 인용 스타일이 아닌 경우, 인용 봇을 템플릿으로 변환하지 않아야 한다.그것은 기사의 확립된 스타일을 연마하는 것일 것이다.키스 D (토크) 17:37, 2022년 2월 1일 (UTC)
이래서다.{{article style}}6년 동안 54건의 전횡이 일어났어!우리에게 필요한 것은 스퀘어 링크 전용, 편집자들이 그것을 사용할 수 있는 새로운 옵션, 그리고 그것을 존중하는 봇들뿐이다.페이지의 스타일 설정을 결정하는 중심 메커니즘인 CSS와 같다. -- GreenC 18:06, 2022년 2월 1일(UTC)

인용 템플릿은 ref의 유지관리성을 획기적으로 개선하고 스타일의 일관성을 보장한다.수백 개의 ref가 서버 로딩되어 비실용적인 경우가 매우 드물지만, 그러한 페이지는 드물다.

대괄호 참조가 지배적인 대부분의 경우, 인용 템플릿을 사용하는 방법을 모르거나 관련된 추가 작업을 좋아하지 않는 편집자들에 의해 참조가 추가되었기 때문이다.우리는 봇의 일을 깎아내리는 것이 아니라, 다른 ref를 개선하기 위해 노력해야 한다.브라운헤어드걸(대화) • (출연) 19:20, 2022년 2월 1일 (UTC)
WP:CITEVAR을 참조한다. "편집자는 단지 개인적인 선호에 근거하여, 다른 기사와 일치하도록 하기 위해 또는 먼저 변경에 대한 합의를 구하지 않고 기사의 확립된 인용 방식을 변경하려 해서는 안 된다."키스 D (토크) 23:45, 2022년 2월 1일 (UTC)
신속하고도 비열한 참조 결과를 '스타일'로 낙인찍는 것은 어리석은 일일 것이다.브라운헤어드걸(대화) • (출연) 01:54, 2022년 2월 2일(UTC)
위와 같이, 나는 봇이 항상 인용 템플릿을 사용하는 것을 훨씬 더 선호한다.

그러나 그것이 확립된 스타일인 고사양 스타일을 따르려고 한다면 높은 임계값을 사용하여 확립된 스타일을 결정할 수 있다.한계점은 다음과 같아야 한다고 제안한다.
브라켓 스타일을 사용하여 최소 5개의 비베어 참조(즉, 비베어 참조.[http://example.com/foo Fubar]카운트는 분류되지만, 그러나[http://example.com/foo]하지 않는다)

브래킷이 없는 비베어 참조는 pge의 인라인 참조의 50% 이상이어야 한다.

나는 이 모든 것이 더 복잡하게 만드는 것에 대해 걱정한다. 하지만 만약 봇이 매번 인용 템플릿을 사용하지 않는다면, 그 고사리 형식을 과도하게 사용하지 않도록 주의할 필요가 있다.브라운헤어드걸(대화) • (출연) 20:27, 2022년 2월 2일 (UTC)
위와 같이, 나는 봇이 항상 인용 템플릿을 사용하는 것을 훨씬 더 선호한다.여느 때처럼 나는 버그와 복잡성을 줄이려면 여기 BHG에 동의해야 한다.어쨌든 대다수의 기사들은 인용 템플릿을 사용하고 있다.

기술적으로 BHG의 크레테리아를 구현하는 것은 가능하지만, 그것은 추가적인 복잡성을 야기할 것이다.그러기 위해서 나는 항상 템플릿을 사용하는 BHG의 조언을 따르는 것을 선호하지만, 나는 어떤 것에든 개방적이다.Rlink2 (대화) 20:44, 2022년 2월 2일 (UTC)
현재 어떤 스타일을 사용해야 하는지 자동화된 도구를 알려주는 메커니즘이 없다.요즘 CS1 2를 사용하지않는것은매우 드문 일이며,의식적인 선택으로서, 오류가 발생하기 쉽고 복잡한 추측 작업을 하기보다는 어떻게 행동해야 하는지에 대한 도구에 플래그를 지정하는 것이 페이지의 책임이다.나는 적응하기 위한 해결책을 강구하고 있다.{{article style}}하지만 이 BRFA가 끝나기 전에는 준비가 안 될 겁니다그 동안 CS1 2 홀드아웃으로 남아 있는 편집자와 마주친 경우(존재하는가?)그들이 되돌아올 것이고 우리는 봇에 깃발을 꽂는 간단하고 임시적인 해결책을 생각해 낼 수 있다.{{cbignore}}작동 - 아무것도 하지 않는 빈 템플릿, 봇은 페이지의 아무 곳이나 자신의 존재를 확인하고, 있다면 생략한다. -- GreenC 21:12, 2022년 2월 2일(UTC)
기사의 99%가 인용 템플릿을 사용하고 있다.나는 BHG에 동의한다. 우리는 대부분의 코드가 1%의 문제를 해결하는 "스코프 크리프"를 피하고 싶다.

나는 개인적으로 인용 게임에 피부는 없지만, 다시 말하지만, 기본적으로 모든 기사가 그것들을 사용하고 있다.

그 동안 홀드아웃으로 남아 있는 편집자와 마주치면 (존재하는가?) 그들이 돌아올 것이고 우리는 봇을 예스(Yes)로 플래그할 수 있는 간단하고 임시적인 해결책을 생각해 낼 수 있다.링크2 (대화) 15:40, 2022년 2월 4일 (UTC)
@Rlink2: 그것이 훨씬 더 좋은 해결책이다.나는 그러한 사건들이 매우 드물게, 페이지들의 1%보다 훨씬 적을 것이라고 추측한다.브라운헤어드걸(대화) • (출연) 02:32, 2022년 2월 5일 (UTC)
나는 최근 내 감시목록의 기사를 통해 브라운헤어드걸이 직접 404 리프들에게 꼬리표를 달았다는 것을 알아챘다.그녀와 다른 사람들이 죽은 참조들을 태그하는 것에 집중할 수 있다면, 우리는 죽은 링크 태그들을 봇에서 꺼낼 수 있다.여기 사람들은 어떻게 생각해?Rlink2 (대화) 14:20, 2022년 2월 5일 (UTC
나의 태깅은 매우 느린 작업이다.내가 실험적으로 몇 가지 일을 해왔지만, 그렇다고 해서 이 봇의 기능을 제거할 이유는 없다.이 봇이 페이지를 처리하고 있는데 이미 HTTP 오류 코드가 있으면 태그를 지정하는 데 사용하지 마십시오.브라운헤어드걸 (대화) • (출연) 18:34, 2022년 2월 5일 (UTC)

이제 재판이 편집된 지 7일이 지났다.@Rlink2: 제안된 변경 사항과 수락한 변경 사항의 목록을 작성했는가?

그 리스트를 검토하면 2심 재판에 더 가까워질 것 같다. --BrownHairdGirl (대화) • (출연) 20:47, 2022년 2월 5일 (UTC)

여기 큰 것들이 있다.

PDF 태그 지정은 재판 전에 제외되었으며 앞으로도 계속 그렇게 유지될 것이다.1심 재판 때는 PDF ref 태그가 없었다.
재판에 앞서, 채울 당시 링크가 "404" 상태 코드를 반환한 경우에만 봇이 "데드링크" 템플릿으로 ref를 표시하는 것이 합의 사항이었다.링크가 404가 아니지만 문제(서비스 불가, "클라우드플래어", 일반 리디렉션, 유효하지 않은 HTTPS 인증서 등)가 있는 경우 베어 ref는 그 순간에 그냥 내버려 두었을 것이다.재판 과정에서 반드시 살아있지는 않지만 404 상태 오류를 반환하지 않은 여러 링크에는 의도된 목표가 아닌 "데드링크" 템플릿이 표시되었다.첫 번째 변화는 404 탐지기가 제대로 작동하는지 확인하는 것이었고, 부정확한 데이터를 캐시하지 않았다.이러한 링크의 표시 외에, 봇은 "광범위하게 해석"된 참조나 보관의 데드 링크에 대해서는 아무것도 하지 않을 것이다.
주로 브라켓 리프를 사용하는 기사에서 브라켓 리프를 맨 상태에서 맨 것으로 전환할 때 브라켓 리프를 사용하자는 제안이 있었지만 이를 구현할 콘센서는 없었다.편집자들은 "브래킷 리프" 기사는 매우 드물고 보통 특별한 경우라고 지적했다.이런 경우, 기사의 편집자들은 인용 템플릿은 사용하지 말아야 한다는 것을 분명히 하고, 봇 외설물을 사용하므로 봇은 그런 기사들을 처리하지도 않았을 것이다.GreenC는 기사의 인용 스타일을 나타내는 템플릿이 존재했지만 54개 트랑클루온에 그쳤고, 다른 편집자들은 봇이 기사의 인용 스타일을 결정하기는 어려울 것이라고 설명하면서 확장했다고 지적했다.
브라운헤어드걸은 매개변수 간격과 관련해 사소한 두 개의 사소한 사소한 사소한 흠집내기를 지적했는데, 이것이 고정된 것이다.
WP의 가능성에 대해 몇 가지 논의가 있었다.피코크 타이틀은 드물지만, 그런 예는 드물다고 설명했고, '피코크' 타이틀이 무엇인지 봇에게 이해시키려고 애쓰는 것은 어려울 것이라고 말했다.이 말을 꺼낸 사람들은 내 대답에 만족하는 것 같았고, 그래서 이 일에 대해 어떤 것도 할 수 있는 공감대가 없었다.
웹 사이트 매개 변수에 대해 어떻게 해야 할지를 두고 약간의 논쟁이 있었다.봇은 적절한 웹 사이트 매개변수를 추출할 수 있으며 일부 웹 사이트와 제목 매개변수를 분할할 수 있다.웹사이트 매개변수에 대해 봇이 어디까지 갈 수 있는지에 대한 논란이 있었지만, 나는 구조화되지 않은 데이터를 다루고 있기 때문에 이 측면에 너무 연연하지 말고"안전하게 행동해야 한다"고라고.봇이 웹사이트 이름을 추출할 수 없다면 웹사이트 매개변수(등)에 도메인 이름만 사용해야 한다는 공감대가 형성됐다.{{cite web title = Search Results website=duckduckgo.com}}대신에{{cite web title = Search Results }}) 따라서 결과 참조는 인용되는 웹사이트에 대한 중요한 정보를 여전히 가지고 있다.이 변화는 이미 이루어졌다.Rlink2 (대화) 21:58, 2022년 2월 5일 (UTC

@Rlink2, 그 신속하고 상세한 회신에 감사한다.내가 보기엔 우리가 어디로 가야 하는지에 대한 좋은 요약인 것 같다.

내가 보기에는 그 바탕 위에서 봇은 2차 시험운행을 진행해야 하는데, 그 변화들이 1차 시험에서 제기되는 우려를 해소해 주는지 시험해 보아야 할 것 같다.@Primfac, 어떻게 생각해?그럴 준비가 됐나?브라운헤어드걸 (대화) • (출연) 23:13, 2022년 2월 5일 (UTC)

이에 대한 작은 업데이트: 위에서 설명한 바와 같이 봇은 이제 410개의 "고장" 상태 코드를 포착한다.410은 기본적으로 그 내용이 더 이상 통용되지 않는다는 것을 나타내는 덜 사용되는 방법이다.410 상태코드를 이용해 죽은 링크를 표시하는 사이트 수는 많지 않지만 일부 있어 봇에서 시행한 것이다.Rlink2 (대화) 21:09, 2022년 2월 8일 (UTC)

고마워 @Rlink2.오랜 시간 동안 점검한 결과, URL이 없는 페이지의 약 0.5%가 410개의 오류를 반환하는 베어 URL을 하나 이상 가지고 있는 것으로 추정한다.이는 {{dead link}}s로 태그가 붙는 그러한 베어 URL이 약 1,300개가 있음을 시사하므로 이 추가가 큰 도움이 될 것이다.브라운헤어드걸(대화) • (출연) 00:29, 2022년 2월 9일(UTC)

재판2길

평가판 연장 승인(50개 편집) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.늦어져서 미안해, 2심도 괜찮아 보여.프라임팩 (대화) 14:35, 2022년 2월 13일 (UTC)

@Primfac: @BrownHairdGirl:

디프는 https://en.wikipedia.org/w/index.php?target=Rlink2&namespace=all&tagfilter=&start=2022-02-16&end=2022-02-16&limit=50&title=Special%3AContributions에서 찾을 수 있다.

건너뛴 기사는 PDF URL 또는 비활성 URL이었지만 404 또는 410(예: 만료된 도메인, 연결 시간 제한)을 반환하지 않았다.한 사이트는 이상한 웹사이트 구성이 잘못되어 Chrome, Safari, Pale Moon, Seamonkey 또는 Firefox에서 작동하지 않았다. (어떤 모호한 브라우저에서만 볼 수 있었다.)콘센서스와 합의된 대로, 봇은 404나 410개의 데드 링크는 건드리지 않을 것이며, 2심 때는 그렇지 않았다.

내 생각에 또한 비 웨이백 Archive.org url(알다시피 archive.org에는 단순히 아카이브된 웹 페이지 이상의 책과 문서 스캔도 있다)이 있었고, 그 바로 옆에 "웹 아카이브" 템플릿이 있는 맨 참고 자료도 있었다고 생각한다."광범위하게 해석"의 일부로서 이것들은 채워지지 않았다.나는 보관 맨 리프의 양이 적다고 생각하므로 문제가 되지 않아야 한다고 생각한다.

건너뛴 나머지 사이트에는 정크 제목(예: "기다려주십시오......." 또는 "403 금지")이 있었다.

웹사이트의 "자연적인" 이름을 결정할 수 없고 웹사이트 이름이 제목에 없을 때 웹사이트 매개변수가 추가되었을 때 요청된 대로.이런 인용이 나오는 상황을 피하기 위해 각별한 주의를 기울였다.

{{Cite web title = Search results {{!}} duckduckgo.com website=www.duckduckgo.com }}

어떤 것 같을까?

"Search results duckduckgo.com". www.duckduckgo.com. 링크2 (대화) 04:18, 2022년 2월 16일 (UTC)

고마워 @Rlink2.

정확히 50개의 Trial2 편집 목록도 https://en.wikipedia.org/w/index.php?title=Special:Contributions&dir=prev&offset=20220214042814&target=Rlink2&namespace=0&tagfilter=AWB BrownHairdGirl (talk) • (1997년) 05:09, 2022년 2월 16일 (UTC)에서 확인할 수 있다.

응, 이번에는 정밀함을 위해서, 그리고 드라마를 피하려고 정확히 50으로 만들려고 노력했어.Rlink2 (대화) 15:26, 2022년 2월 16일 (UTC

큰 문제.방금 처음 6개의 디프트를 확인했어.그 중 하나는 정확하게 태그가 붙은 데드 링크(Dead link)이지만, 나머지 5건([38], [39], [40], [41], [42])에는 없다. website=매개 변수대신, 웹사이트 이름이 제목에 추가된다.
이것은 Trial1 이후 합의된 것이 아니므로(그리고 여기에서 @Rlink2에 의해 요약[43]) 웹사이트 필드를 추가하지 않고 참조를 채운 모든 평가판2 편집을 되돌리십시오.브라운헤어드걸(대화) • (출연) 05:22, 2022년 2월 16일 (UTC)
[44], [45] 등의 일부 편집에서 도메인 이름으로 웹 사이트 필드를 추가했다는 것을 알 수 있다.
봇이 웹사이트 이름을 알아낼 때, 그것을 정확한 단계에 넣기 보다는 제목에 잘못 붙이는 일이 벌어지고 있는 것으로 보인다. website= 매개 변수브라운헤어드걸(대화) • (출연) 05:41, 2022년 2월 16일 (UTC)
안녕 @BrownHairdGirl:

웹 사이트 매개 변수가 이러한 차이점에 추가되지 않은 이유는 웹 사이트 이름이 제목에 있기 때문이다(예: NYT 링크에는 제목에 "뉴욕 타임즈"가 있으며 브라우저에서 직접 확인할 수 있다).봇은 웹사이트 이름을 추가하기 위해 제목을 수정하거나 변경하지 않았다. 만약 그것이 웹사이트 이름을 추출할 수 있다면 그것은 우리가 동의한 대로 "웹사이트=" 매개변수에 추가되었을 것이다.
세 가지 가능성이 있다.
웹사이트 이름은 웹사이트에서 추출할 수 있으므로, 보다 정확한 이름을 사용할 수 있기 때문에 웹사이트 매개변수에 도메인 이름을 사용할 필요가 없다.이에 대한 예는 다음과 같다.

"Article Story". New York Times.

봇은 웹사이트 이름이 제목에 포함되어 있다는 것을 감지할 수 있었지만, 어떤 이유에서인지 그것을 추출할 수 없었다.앞에서 말한 바와 같이, 웹사이트 이름을 타이틀에서 추출하는 것은 때때로 어려울 수 있기 때문에, 웹사이트 이름을 검출할 수 있다고 해도, 「website=」 파라미터에 적합한 값을 얻을 수 없을 수도 있다.이 경우 웹 사이트 매개 변수를 추가하는 방법은 다음과 같다.

"The Battle of Tripoli-Versailles - The Green-Brown Times". www.thegreenbrowntimes.com.

웹 사이트 매개변수가 정보를 반복하는 경우 봇은 대신 다음과 같이 인용했다.
"The Battle of Tripoli-Versailles - The Green-Brown Times".

봇은 웹사이트 이름을 감지할 수 없어서 도메인 이름에 웹사이트 매개변수를 추가했다(그리고 이것은 당신이 위에서 제공한 추가 디프트로 증명되었다).인용문은 다음과 같이 보일 것이다.

"Search results". www.duckduckgo.com. 링크2 (대화) 15:25, 2022년 2월 16일 (UTC)

@Rlink2, 나는 당신이 꽤 간단한 것을 과소평가하고 있다고 생각하는데, 나는 분명히 동의했다고 생각했다. website= 매개 변수는 항상 존재해야 하며 파일링해야 한다.위의 점들이 그 가치가 무엇인지를 판단해야 하지만 절대 빠뜨려서는 안 된다.브라운헤어드걸(대화) • (출연) 16:04, 2022년 2월 16일 (UTC)
@BrownHairdGirl:

"website=" 매개변수를 추가한 이유는 인용문에 웹사이트 이름이 항상 포함되도록 하기 위함이었다.웹 사이트 매개 변수를 요청한 첫 번째 설명에서 예제 제목에는 웹 사이트 이름이 없으므로, 이 경우 웹 사이트 매개 변수를 추가해야 하는 것이 분명했다.게다가, 우리가 2심판을 시작하기 전에 내가 내 마지막 목록에서 준 "website=" 예제는 웹사이트 이름이 제목에 포함되지 않았다."website=" 매개변수를 추가하지 않은 인용문에는 웹사이트 이름이 그대로 있었다.

개인적으로, 나는 비록 웹사이트 이름이 제목에 있더라도, 당신의 충고를 따르고 웹사이트 매개변수를 항상 포함시키는 것에 동의한다.하지만, 나는 그것이 인용 게임의 일부 파벌들 사이에 분노를 야기시킬 수 있다고 우려했다. 그들은 그 봇이 아마도 중복된 정보로 ref를 "빌어먹을" 것이라고 주장할 것이다. 그래서 이것은 그들을 행복하게 하기 위해 행해졌다.Rlink2 (대화) 18:19, 2022년 2월 16일 (UTC)
@Rlink2: 기사가 수록된 작품의 이름은 어떤 참고문헌에서도 항상 핵심적인 사실이다.어떤 형태로든 사용할 수 있다면 별도 필드로 포함해야 하며, URL의 경우 도메인 이름으로만 사용하더라도 항상 어떤 형태로든 사용할 수 있다.인용 템플릿의 전체 목적은 양식의 비정형 텍스트보다는 일관성 있게 구조화된 데이터를 제공하는 것이기 때문에 "분리된 필드" 문제는 매우 중요하다.[http://exmple.com/foo More foo in Ballybeg next year -- Daily Example 39th of March 2031]

부풀어 오르는 것이 있다면, 그것은 사이트 이름이 속하지 않는 제목에 추가된 것이다.만약 당신이 제목에서 그런 중복성을 확실하게 제거할 수 있다면, 그렇다면 훌륭할 것이다... 하지만 나는 당신이 모든 데이터를 다 쏟아부어서 그 누구도 만족시킬 것이라고 생각하지 않는다. title=매개 변수

나는 이것이 약간 걱정된다. 왜냐하면 당신이 인용 템플릿이 무엇에 쓰이는지 충분히 이해한다는 확신을 주지 못하기 때문이다.그것들은 일관성 있게 구조화된 데이터에 관한 것이고, 중복성의 문제는 그 핵심 목적에 부수적이다.브라운헤어드걸(대화) • (출연) 18:37, 2022년 2월 16일 (UTC)
@BrownHairdGirl:

기사가 수록된 작품의 이름은 어떤 참고문헌에서도 항상 중요한 사실이다. 어떤 형태로든 사용할 수 있다면 별도 필드로 포함해야 하며, URL의 경우 도메인 이름으로만 사용하더라도 항상 어떤 형태로든 사용할 수 있다. 알았어

만약 당신이 제목에서 그러한 중복성을 믿을 수 있게 제거할 수 있다면, 나는 사실 이 아이디어를 첫 번째 답장에서 제안하려고 했었다. 왜냐하면 봇이 원한다면 웹사이트 제목을 안정적으로 제거할 수 있어야 하기 때문이다.그렇게 하면 우리는 이런 것을 가지고 있다.
{{Cite web title = Article Title website=nytimes.com}}

대신에
{{Cite web title = Article Title {{!}} The New York Times }}

또는
{{Cite web title = Article Title {{!}} The New York Times website=nytimes.com }}

나는 이것이 약간 걱정된다. 왜냐하면 당신이 인용 템플릿이 무엇에 쓰이는지 충분히 이해한다는 확신을 주지 못하기 때문이다. 그것들은 일관성 있게 구조화된 데이터에 관한 것이고, 중복성의 문제는 그 핵심 목적에 부수적이다.네 말이 맞아, 나는 인용 템플릿이 만들어지기 전부터 편집해 온 너 같은 사람들에 비해 인용 템플릿에 대해 비교적 잘 알지 못하지만, 나는 시간이 지날수록 배우고 있어.이 모든 것을 말해줘서 고마워, 정말 고마워.Rlink2 (대화) 18:57, 2022년 2월 16일 (UTC)
@Rlink2; 긴 답장은 고맙지만 우리는 아직 그곳에 없다.웹 사이트 이름을 완전히 제거하지 마십시오.

이상적인 출력은 웹사이트 필드에 웹사이트 이름을 갖는 것이다.불가능할 경우 도메인 이름을 사용하십시오.

웹 사이트 이름을 신뢰할 수 있는 정보로 결정할 수 있는 경우 title=매개 변수, 단순히 정보를 덤프하지 마십시오. 웹 사이트 필드에서 '도메인 이름보다 더 좋으므로' 사용하십시오.

그리고 만약 당신이 확실하지 않다면, 어떤 중복이 누락보다 낫다.

위의 예를 들어 보십시오.
{{Cite web title = Article Title website=nytimes.com}}
bad: 웹사이트 이름이 있었는데 버렸어.

{{Cite web title = Article Title {{!}} The New York Times }}
bad: 웹 사이트 필드 없음

{{Cite web title = Article Title {{!}} The New York Times website=nytimes.com }}
이상적이지는 않지만, 이 세가지 중에서 최악은 아니다.

이 경우 최고는 다음과 같다.{{Cite web title = Article Title website= The New York Times}}

내가 필요한 것을 가성으로 시작하면 도움이 될 것 같다.

VAR 이 항목URL = "http://exmple.com/fubar" VAR domainName = FunctionGetDomainNamefromURL(이URL) VAR 문서Title = FunctionGetTitleFromURL(thisURL) // start by setting default value for websiteParam  VAR websiteParam = domainName // e.g. "magicseaweed.com" // now see if we can get a website name VAR foundWebsiteName == FunctionToFindWebsiteNameAndDoAsanityCheck() IF foundWebsiteName  IS NOT BLANK // e.g. "Magic Seaweed" for https://magicseaweed.com/그런 다음 BEGIN 웹 사이트Param = foundWebsiteName IF 문서제목에 foundWebsiteName 다음 BEGIN VAR 다듬기기사제목 = 기사제목 - foundWebsiteName IF 절삭 문서제목이 공백이 아니거나 다음 글제목 = 다듬어진기사제목 ENDIF ENDIF 기능EndIF 함수MakeCiteTemplate(이URL, 기사)제목, 웹 사이트모수)

이것이 브라운헤어드걸(대화) • (출연) 20:25, 2022년 2월 16일 (UTC)
@BrownHairdGirl:그래, 이게 말이 돼.앞으로는 이 점을 명심하겠다.그래서 웹 사이트 파라미터는 앞으로 항상 있을 것이다.링크2 (대화) 23:28, 2022년 2월 16일 (UTC)
@Rlink2:이 점을 염두에 두기보다는 그 근거로 코드가 재구성됐고, 수정된 코드가 업로드됐다는 것을 알려줬으면 하는 바램이었습니다.브라운헤어드걸(대화) • (출연) 13:40, 2022년 2월 19일 (UTC)
@BrownHairdGirl : 그래, 정확한 언어는 나의 강한 슈트가 아니다;;)

완료, 그리고 소스 코드에 반영 (410 추가와 같이 다른 모든 버그 수정도 지금 업로드되어야 한다) 그래서 지금, 만약 웹사이트 매개변수를 추출할 수 없거나 존재하지 않는다면, 도메인 이름은 항상 대신 사용될 것이다.

그리고 만약 당신이 확실하지 않다면, 어떤 중복이 누락보다 낫다. 나도 동의해.Rlink2 (대화) 14:16, 2022년 2월 19일 (UTC)
그래, 시간이 좀 지났는데, 이 문제만 제기되어 (고정이 된) 유일한 문제야.한 번 더 재판을 해야 할까?Rlink2 (대화) 13:56, 2022년 2월 22일 (UTC)
@Rlink2: 개정된 코드는 어디에 있는가?브라운헤어드걸(대화) • (출연) 10:01, 2022년 2월 23일 (UTC)
@BrownHairdGirl: 코드는 같은 장소에서 찾을 수 있다, 위키백과:Bots/Requests_for_승인/BareRefBot/CodeRlink2 (대화) 12:48, 2022년 2월 23일 (UTC)
@Rlink2: // 2.0 - 2022년 2월 27일 코드.

시간여행?브라운헤어드걸(대화) • (출연) 13:39, 2022년 2월 23일 (UTC)
@BrownHailedGirl: ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ감사합니다;) 링크2 (대화) 13:44, 2022년 2월 23일 (UTC)
@Rlink2, 프로브 없음.Tiposhappon tu oll. Tiposhapon

나는 개정된 코드를 완전히 분석하지는 않았지만 검토했다.원칙적으로는 건전한 접근을 하는 것처럼 보인다.

나는 이 새로운 코드에 대한 재판이 좋은 생각이 될 것이고, 또한 이 재판은 더 다양한 사건들을 시험하기 위해 더 큰 세트 (250 또는 500 편집)가 되어야 한다고 생각한다.어떤 웹마스터들은 그들의 사이트에서 정말 이상한 일들을 한다.브라운헤어드걸 (대화) • (출연) 20:12, 2022년 2월 23일 (UTC)
문제2.태그가 지정된 링크가 비활성(예: [46], [47])인 편집에서 추가된 태그는{{Dead link bot=bareref date=February 2022}}.
이는 잘못되었다.이 봇의 이름은 BareRefBot이므로 태그는 다음과 같아야 한다.{{Dead link bot=BareRefBot date=February 2022}} . 브라운헤어드걸(대화) • (출연 ) 05:33, 2022년 2월 16일 (UTC)
내가 고쳤어.Rlink2 (대화) 15:26, 2022년 2월 16일 (UTC
나는 이 문제가 도착했는지 여부를 확인하기 위해 어느 재판도 확인하지 않았지만, 도메인 재판매 페이지와 유사한 페이지들은 채워져서는 안 되며 적절한 보관소나 새로운 장소를 찾기 위해 인간 검토가 필요하기 때문에 죽은 것으로 표시된 링크들은 채워져야 한다.AFAIK는 페이지가 도메인 리셀러인지 아닌지를 자동으로 판단할 수 있는 신뢰할 수 있는 방법은 없지만, 다음과 같은 문자열이 일반적인 예다.
- 이 웹사이트는 판매용이다.
- Deze 웹사이트는 te coop이다.
- HugeDomains.com
- Denna sida ér till salu
- DomainMarket.com에서 이용 가능
- 主婦が消費者金融に対して思う事
또한, 다음은 오류를 나타내며, 이와 같이 취급되어야 한다(맨 URL이 최선의 선택으로 가고 있는 것 같다).
- 페이지를 찾을 수 없음
- 실제 기사 제목은 여기에 속함
- 웹 사이트 사용 안 함
"판매용!" 문자열은 도메인 재판매 페이지와 다른 부적합한 링크의 제목에서 자주 발견되지만, 일부 잘못된 긍정이 있을 수 있는가?만약 누군가가 시간을 갖고 있고 (나는 atm을 사용하지 않는다) 그것을 더 적합하지 않을 가능성이 있는 것으로 생략하는 것이 더 나은지 아니면 우리가 더 많은 좋은 것들과 함께 몇몇 부적절한 링크를 얻는 것을 받아들이는 것이 더 나은지를 결정하는 것이 어떤 비율인지 보는 것이 유용할 것이다.모든 경우에 당신의 코드는 각 범주의 문자열이 감지될 때 문자열을 쉽게 추가하거나 제거할 수 있어야 한다.Thryduulf (대화) 11:44, 2022년 2월 23일 (UTC)
@Thryduulf:피드백 고마워.나는 이미 이것을 했다. (에서와 같이, 판매 타이틀을 위한 도메인을 탐지한다.)보통 그 안에 "판매용"인 어떤 것이든 보통 정크 타이틀을 붙이는데, 나쁜 타이틀로 채우는 것보다 더 늦게 ref를 생략하는 것이 낫다.Rlink2 (대화) 12:45, 2022년 2월 23일 (UTC)
이 접근법은 건전한 것 같지만, 항상 예상치 못한 에지 케이스가 있을 것이다.나는 체크가 용이하도록 무작위적인 견본의 기사에 대해 봇의 처음 몇 천 개의 편집을 느린 속도로 실행할 것을 제안한다.
하는 것도 좋을 것이다.
리디렉션된 URL을 따르지 않음.그 시설은 웹마스터들에게 널리 악용되어 매우 지저분한 결과를 초래할 수 있다.

위 필터를 회피하는 경우를 수용하기 위해 악용된 도메인의 블랙리스트를 유지한다.
그게 도움이 되길 바래.브라운헤어드걸(대화) • (출연) 20:18, 2022년 2월 23일 (UTC)
@BrownHairdGirl: 나는 체크가 용이하도록 무작위적인 기사 샘플에 대해 봇의 처음 몇천 편집 작업을 느린 속도로 진행할 것을 제안한다.그래, 좋은 생각이야.맨 참조를 수동으로 AWB로 작성하는 동안 나는 직접 많은 에지 케이스와 "Gotchas"를 보았기 때문에 더 많은 확인은 항상 좋은 일이다.

리디렉션된 URL을 따르지 않음. 이건 사실 좋은 생각일 수 있어.몇 개의 URL이 리디렉션되고 몇 개의 URL이 유효한지 알 수 없지만 404개를 던지는 대신 1면으로 리디렉션을 사용하는 데드 링크가 많다.HTTP에서 HTTPS로 그냥 넘어가는 리디렉션에 대해 예외가 있을 수 있다(일반적으로 콘텐츠의 변경이나 제거를 나타내지 않기 때문이다).다시 한번 데이터 수집을 좀 해서 이 접근법이 실현 가능한지 살펴봐야겠지만, 효과가 있을 것으로 보인다.

유출된 도메인의 블랙리스트를 유지하라. 이미 "블랙리스트된" 도메인 목록을 가지고 있다. 그래, 좋은 생각이다.Rlink2 (대화) 19:39, 2022년 2월 24일 (UTC)
소프트 404 스트링 검출에 있어서는 모두 에지 케이스다.거의 무한에 가까운 다양성이 있다.예를 들어 외국어에는 "archivo no encontrado pagina non trovata pargina nang encontrada erreur 404 något saknas"라는 제목이 있다. 계속된다.-- GreenC 21:40, 2022년 2월 24일 (UTC)
@GreenC: 음, 그 중 하나에 "404"라는 숫자가 들어가 있는데, 그건 걸러질 겁니다.물론 항상 무한의 다양성이 있겠지만 99.9%를 얻을 수 있다.실행 중에 내가 기억나는 유일한 소프트 "404"s는 이미 존재하는 필터가 동일한 페이지로 가짜 리디렉션(위에서 설명됨)된 후였다.Rlink2 (대화) 22:05, 2022년 2월 24일 (UTC)
글쎄, 나는 인터넷 아카이브의 후원 직원으로서 4년 이상 소프트 404 탐지기를 연구해왔고 기껏해야 85%를 얻을 수 있을 거야.몇 년 동안 걸러낼 끈을 찾으려고 노력한 끝에 그런 거야.그 시점에는 벽이 있다. 왜냐하면 마지막 15%는 대부분 독특한 경우들이기 때문이다. 한 번의 오프로, 그래서 여러분은 그것들을 실제로 예측할 수 없다.99%를 위해 노력하는 것은 고맙지만 아무도 그것을 이해하지 못한다.현존하는 최고의 부드러운 404 필터는 구글에 의해 만들어졌고 나는 그들이 99%를 얻는다고 생각하지 않는다.이 주제에 대한 학술 논문, AI 프로그램 등이 있다.행운이 있길 바라며, 부디 그 문제에 대해 감사해 주시기 바라며, 그것은 비교가 되지 않는다. -- GreenC 23:11, 2022년 2월 24일 (UTC)
@GreenC:

그렇다, 나는 부드러운 404 탐지가 매우 어려운 문제라는 것에 동의한다.그러나 이 경우 해결할 필요조차 없을지도 모른다.

그래서 99%의 85%가 될 겁니다.내 상대적인 경험 부족 때문에 내 대본은 75% 혹은 심지어 65%라고 하자.그래서 모든 "부드러운 404년대" 중에서 (이들 중에서는 위키백과의 베어 ref가 많지 않은데, 이것은 봇의 목적이다) 여전히 좋은 덩어리를 얻을 수 있다.

내가 본 부드러운 404의 모습은 같은 페이지로 리디렉션하는 것과 같은 것이다.이제 어떤 리디렉션은 합법적일 수도 있고, 어떤 리디렉션은 합법적일 수도 있고, 어떤 리디렉션은 그렇지 않을 수도 있다.그건 네가 말한 것처럼 알아내기가 어려운 문제야.그러나 우리는 리디렉션이 있을 경우 소프트 404가 있을 수도 있고 없을 수도 있다는 것을 알고 있으며, 따라서 그 순간 그것을 그냥 내버려두는 것으로 탐지 문제를 피한다.

또 다른 예는 여러 페이지의 제목이 같은 경우일 수 있다.부드러운 404의 그 순간에 가능성이 있다, 그렇지 않을 수도 있다.그러나 만약 우리가 이 불법적인 상황에서 어떤 것도 하지 않는다면, 우리는 부드러운 404를 "탐지"하는 것에 대해 걱정할 필요가 없다.

그것은 마치 "안타티카에서 살기에 가장 더운 곳이 어디냐"고 묻는 것과 같으며, "다 함께 그곳을 피하자, 아프리카나 남아메리카를 다루자"고 답하는 것과 같다.완벽한 비유는 아니지만 요점은 알 수 있다.

내가 어떻게 대처해야 할지 모르는 유일한 것은 외국어 404대지만, 다시 말하지만, 너무 많지 않다.

내가 사용한 "99%"는 문자 그대로가 아니라 과장된 것이었다.무한한 양의 구성과 사물을 가진 웹사이트가 있기 때문에 그 어떤 것도 100%에 근접하지 못할 것이다.모든 웹사이트를 계획하는 것은 불가능하지만, 동시에 그러한 종류의 웹사이트는 드물다.Rlink2 (대화) 05:20, 2022년 2월 26일 (UTC)
사용자:Rlink2: 어떤 도메인들은 거의 또는 전혀 가지고 있지 않으며, 다른 도메인들은 50%에 가까운 매우 높은 비율을 가지고 있다(자신을 ibm.com uh).소프트-404를 구성하는 것은 랜딩 페이지가 관련 내용을 가지고 있을 수 있지만 아카이브 URL과 비교하여 원본만 검출할 수 있는 것과 같지 않기 때문에 그 자체로 판단하기 어려울 수 있다. 한 가지 방법: URL이 위키 페이지에 추가된 날짜를 결정한다.날짜에 대한 보관 URL을 확인하고 해당 URL의 제목을 사용하십시오.타이틀 봇을 쓴다면 그렇게 할 것이다.모든 URL은 결국 404 또는 소프트-404로 복구되므로 wiki에 추가된 시간에 가까운 스냅샷을 얻는 것이 가장 신뢰할 수 있는 데이터가 될 것이다. -- GreenC 15:19, 2022년 3월 2일(UTC)
"Wiki 페이지에 URL이 추가된 날짜를 결정하십시오. 날짜에 대한 보관 URL을 확인하고, 거기서 나온 제목을 사용하십시오."이건 사실 좋은 생각이야, 한 번 생각해봤는데 잊어버린 것 같아, 말해줘서 고마워(또는 상기시켜줘서.

하지만 "광범위하게 해석"의 일환으로 나는 봇이 아카이브 사이트로 어떤 것도 하지 않기를 바라며, 그것은 맨 리프를 채우는 목표에서 벗어나는 불필요한 드라마를 만들 것이다.또한 그 웹사이트는 제목을 좀 더 설명적이게 바꾸거나, 혹은 아마도 내용이 이동되었을 수도 있다.그래서 그것은 보관된 타이틀이 항상 최고의 타이틀은 아닐지도 모른다.아마도 보관 제목과 현재 URL 제목 사이에 약간의 불일치가 있을 경우, 현재 ref를 그대로 두라는 신호가 되어야 할 것이다.

만약 어떤 사이트가 404개의 높은 비율을 가지고 있다면, 우리는 단순히 그것을 블랙리스트에 올릴 것이고 봇은 그 도메인들로부터 어떠한 ref도 채우지 않을 것이다.링크2 (대화) 16:18, 2022년 3월 2일 (UTC)

그리고 외국 타이틀에 관해서는, 내 런에서 아주 적은 양의 타이틀이 있다.기껏해야 5만 개 이상의 맨 편집이 실행되는 동안 10개를 보았다.Rlink2 (대화) 22:50, 2022년 2월 24일 (UTC)
외국어 웹사이트가 매 50,000개 중 10개 정도를 차지한다는 말씀이세요? -- GreenC 23:24, 2022년 2월 24일 (UTC)
사실 외국 기사가 실린 기사가 50개쯤 됐을지도 모르지만, 그 중 5~10개 정도만 기억난다.극저온 캐릭터 중 일부를 걸러냈는데, 대본의 수작업 방식 때문에 인용 오류를 만들었기 때문에 봇이 결정해야 할 실제 액수는 그것보다 적다.Rlink2 (대화) 05:22, 2022년 2월 26일 (UTC)

보조 도구로서의 BareRefBot

BareRefBot을 보조 도구로 실행하십시오. 즉, 좀 더 세련된 인용 봇이 시도했다가 실패한 참조에서 작업하는 것이 가능한 한 타겟이 되어야 함을 당부하고자 한다.

이것은 내가 처음에 제기했어야 할 큰 문제다.그 URL은 내가 BareRefBot을 작동시키기를 열망했던 이유야. 그리고 나는 이것을 미리 충분히 설명했어야 했어.이 BRFA에 대한 다른 기여자(@Rlink2, Primefac, GreenC, RusingReader, Kvng, Levivich, Pppery, 1234qwer4, Thryduulf)에 대한 ping을 실시하십시오.

인용 봇이 다룰 수 있는 링크에서는 매우 철저한 작업을 하기 때문에 나는 이것을 제안한다.조테로 서버를 활용해 베어레프봇이 얻을 수 없는 날짜와 작성자 등 메타데이터를 많이 추출하고, 해당 시 {{cite 뉴스}나 {{cite 저널}을 사용하는 등 개별 사이트의 문제를 해결하기 위해 크고 잘 개발된 룩업 세트를 보유하고 있다.또한 도메인 이름을 회사 제목으로 변환하기 위한 잘 개발된 룩업 테이블을 가지고 있다.

따라서 이상적으로는 모든 베어 URL이 잘 다듬어진 인용 봇에 의해 채워질 것이다.불행히도, 인용 봇은 데이터를 제공하지 않기 때문에 채울 수 없는 웹사이트가 많다.WP와 같은 기타 도구:REFLINKS와 WP:REFill은 종종 이러한 URL을 처리할 수 있지만, 그 중 어느 것도 배치 모드에서 작동하지 않으며 개별 편집자는 인용 봇의 누락에 뒤처지지 않을 만큼 빠르게 수동 작업을 수행할 수 없다.

BareRefBot의 USP는 Rlink2의 교활한 프로그래밍 덕분에 이 후속 작업을 일괄 처리 모드로 할 수 있으며, 그것이 바로 그 대상이라는 것이다.그렇게 해서 우리는 양쪽의 장점을 모두 얻을 수 있다: 인용 봇은 할 수 있으면 다듬은 일을 하고, 베어리프봇은 나머지와 함께 할 수 있는 최선을 다한다.

인용 봇에 URL이 없는 긴 기사 목록을 두 세트로 체계적으로 제공하고 있다.

사용자:BrownHairedGirl/Articles with new bare URL refses, 최신 데이터베이스 덤프에는 있지만 이전 덤프에는 없는 베어 URL ref(ABUR)가 포함된 조항으로 구성됨.20220 덤프에는 4,904개의 새로운 ABUR가 있었고, 그 중 4,518개의 ABUR가 여전히 베어 URL을 사용하고 있었다.
사용자:BrownHairedGirl/Articles(베어 링크 포함), 컷오프 날짜 이후 내 인용 봇 목록에 포함되지 않은 문서로 구성됨.이 봇은 현재 2021년 12월 1일 이후 인용봇이 처리하지 않은 3만3239건의 기사를 절반가량 진행 중이다.

인용 봇이 실행한 후 BareRefBot이 이러한 리스트를 대상으로 한다면, 우리는 양쪽의 장점을 모두 누릴 수 있다.현재, 이 목록들은 쉽게 접근할 수 있다: 내가 사용한 모든 인용 봇은 연결된 페이지에 공개적으로 기록된다. 그리고 그것이 더 편리하다면, 나는 기꺼이 전체 (논플릿 목록)의 Rlink2 사본을 이메일로 보낼 것이다.만약 내가 버스에 치이거나 다른 방법으로 인용 봇에게 먹이를 주는 것을 중단한다면, Rlink2나 다른 누군가에게 인용 봇을 처음 먹이는 일을 맡기는 것은 간단할 것이다.

다른 사람들은 어떻게 생각하는가? --BrownHairdGirl (대화) • (출연) 11:25, 2022년 3월 2일 (UTC)

여기 내가 제안하는 것의 예가 있다.

Matt Wieters는 내 목록의 #2178페이지 12월 1일 이후 처리되지 않음 - 11의 6부(2,847페이지)에 현재 인용봇에서 처리되고 있다.

인용봇은 2022년 3월 2일 11시 26분에 기사를 편집했지만, 아무런 URL 참조도 채우지 않았다.WP를 사용한 후속 조치:이 편집에서 기본 URL 참조 1개를 채우려면 REFLINKS를 사용하십시오.

그 후속 조치가 바로 BareRefBot이 해야 할 일이다.브라운헤어드걸(대화) • (출연) 11시 42분, 2022년 3월 2일(UTC)

나는 무엇보다도 네가 길을 건너기 전에 양쪽 길을 다 살펴서 버스에 치이지 않도록 해야 한다고 생각해. :-D. 제안된 대로 BRB가 CB를 따르도록 하는 것이 더 효율적이라는 생각이 들어.나는 어떤 단점도 보이지 않는다.레비비치 19:28, 2022년 3월 2일 (UTC)

@BrownHairdGirl

말이 되네, 인용 봇이 완전히 ref를 작성하는 데 더 낫다고 생각해.한 가지 흥미로운 점은 인용 봇이 이미 채워진 참고 자료를 개선할 수 있는지 여부다.예를 들어 인용 봇이 저자, 제목, 이름, 날짜를 얻을 수 있는 출처가 있다고 하자만, 베어리프봇은 제목만 얻을 수 있다.BareRefBot이 제목만 채우고 인용 봇이 그 뒤에 온다면 인용 봇이 나머지 부분을 채울 것인가?

그리고 그것은 적절할 때 인용 뉴스나 인용 저널을 사용하는 것과 같은 개별 사이트의 문제를 해결하기 위해 크고 잘 발달된 조회 세트를 가지고 있다. 나는 동의한다.

조테로 서버를 활용해 BareRefBot이 얻을 수 없는 날짜, 작성자 등 메타데이터를 많이 추출하고, 개별 사이트 Correct(수정)의 문제를 해결하기 위해 크고 잘 개발된 룩업 세트를 보유하고 있다.

또한 도메인 이름을 회사 제목으로 변환하기 위한 잘 개발된 룩업 테이블을 가지고 있다.예, 목록을 Bare Ref Bot에 포팅할 수 있음(목록은 여기에서 찾을 수 있음)

그렇게 해서 우리는 양쪽의 장점을 모두 얻을 수 있다: 인용 봇은 할 수 있으면 다듬은 일을 하고, 베어리프봇은 나머지와 함께 할 수 있는 최선을 다한다.동감이다다른 사람들이 말하는 Rlink2 (대화) 19:38, 2022년 3월 2일 (UTC)

@Rlink2 우리가 원칙적으로 동의해서 기쁘다.몇 가지 유용한 문제를 제기하는 경우:

한 가지 흥미로운 점은 인용 봇이 이미 채워진 참고 자료를 개선할 수 있는지 여부다.

그래, 할 수 있어.하지만 기존의 모든 자료를 덮어쓰지는 않는다고 생각하는데, 그래서 우선 합격권을 주는 게 낫다고 본다.

예를 들어 인용 봇이 저자, 제목, 이름, 날짜를 얻을 수 있는 출처가 있다고 하자만, 베어리프봇은 제목만 얻을 수 있다.BareRefBot이 제목만 채우고 인용 봇이 그 뒤에 온다면 인용 봇이 나머지 부분을 채울 것인가?

기존 인용문만 있는 경우 title=채운 인용 봇은 많은 다른 매개변수를 추가한다(예: [48] 참조).

하지만, 나는 우리가 BareRefBot이 항상 추가되고 채워지는 것에 동의했다고 생각했다. website=매개 변수?

내 관심사는 대부분 그쪽에 있다. title=. 인용봇은 맨 리프를 채울 때 제목에서 관련 없는 것들을 벗겨내는 일을 꽤 잘하지만, 나는 그것이 기존의 타이틀을 다시 가공한다고 생각하지 않는다.그래서 나는 제목을 채울 때 인용 봇에게 첫 번째 패스를 주는 것이 가장 좋다고 생각한다.

그게 도움이 되길 바래.아마도 CB의 관리자인 AManWithNoPlan은 나의 평가를 확인하고 내가 인용 봇이 부분적으로 채워진 참조를 처리하는 방법에 대해 오해한 것이 있다면 우리에게 알려 줄 수 있을 것이다.브라운헤어드걸(대화) • (출연) 20:27, 2022년 3월 2일 (UTC)

네 말이 맞는 것 같아.인용 봇은 대부분 위키백과 조테로에 의존한다 - 우리가 조테로를 넘어서는 몇 가지가 있다: IEEE만이 유일한 것일 수 있다.봇이 하는 일은 광범위한 오류 검사(나쁜 날짜, "rss 피드 확인" 등의 저자들)이다.또한 기존 데이터를 거의 덮어쓰지 않는다.AManWithNoPlan (대화) 20:35, 2022년 3월 2일 (UTC)

신속하고 유용한 설명에 @AMANWithNoPlan 고마워. --BrownHairedGirl (대화) • (출연) 20:51, 2022년 3월 2일 (UTC)

@BrownHairdGirl @AMANWithNoPlan

하지만 기존의 모든 자료를 덮어쓰지는 않는다고 생각하는데, 그래서 우선 합격권을 주는 게 낫다고 본다.그래, 내 생각에 존이 인용봇 토크 페이지에서 이 점을 제기한 것 같은데, AManWithNoPlan은 위에 새로운 정보를 추가할 수는 있지만 이전 정보를 덮어쓸 수는 없다고 말했다.

하지만, 나는 우리가 BareRefBot이 항상 예, 이것은 변하지 않았다.나는 "제목과 웹사이트"라고 말하는 것을 잊었다. 반면 인용봇은 작가, 제목, 웹사이트, 날짜 등을 얻을 수 있다.

그래서 나는 제목을 채울 때 인용 봇에게 첫 번째 패스를 주는 것이 가장 좋다고 생각한다.이게 말이 되네.

인용봇은 맨 리프를 채울 때 제목에서 관련 없는 것들을 제거하는 일을 꽤 잘 한다"고 나는 동의한다.AManWithNoPlan은 BareRefBot에 포팅될 수 있도록 사용된 기술을 공유할 수 있는가?아니면 조테로 서버에서 스트리핑을 했는가?그는 이것에 대해 더 많은 정보를 가지고 있을 것이다.

리스트 작성 과정의 전환에 대해서도 질문이 있어.인용 봇이 한 묶음의 기사를 완성하는 데 보통 얼마나 걸리는가?링크2 (대화) 20:43, 2022년 3월 2일 (UTC)

https://en.wikipedia.org/api/rest_v1/#/Citation/getCitation을 참조하고 NO_DATE_WEB 목록이 있는 https://github.com/ms609/citation-bot/blob/master/Zotero.php을 참조하십시오.ITES, 정리_날짜 기능 등AManWithNoPlan (대화) 20:45, 2022년 3월 2일 (UTC)

@Rlink2: 인용봇은 나의 ABUR 목록을 하루에 3,000개 정도의 비율로 처리한다.그것에는 꽤 많은 변화가 있지만(예: 큰 리스트는 슬루, 작은 스텁은 빠르다), 3k/day는 좋은 야구장이다.

20220301 데이터베이스 덤프에는 155K ABUR가 들어 있어 밀린 로그 처리까지 최대 50일을 내다보고 있다.브라운헤어드걸(대화) • (출연) 20:47, 2022년 3월 2일(UTC)

@BrownHairdGirl

그럼 50일마다 새로운 리스트가 생길거고, 아니면 목록을 조각조각 쪼개서 기사 인용 봇의 리스트를 줄거야?링크2 (대화) 21:01, 2022년 3월 2일 (UTC)

@Rlink2: 최대 2,850페이지의 묶음으로 되어 있는데, 이것이 인용봇 묶음의 한계에 해당한다.

내 작업 목록 페이지 보기:사용자:BrownHairedGirl/Articles with bare links and User:새로운 베어 URL ref를 포함한 BrownHairedGirl/Articles리스트가 완성되는 대로 이메일로 보낼 수 있어, 보통 하루에 한 개 정도.브라운헤어드걸 (대화) • (출연) 21:27, 2022년 3월 2일 (UTC)

듀 @me.

@Rlink2, 나는 인용봇을 따르기 위해 BareRefBot의 작업목록을 내 작업목록만으로 작성할 필요가 없다는 것을 방금 깨달았다.

인용봇은 4개의 채널이 있어서 나의 목록은 인용봇 작품의 약 4분의 1에 불과하다.다른 편집은 배치 작업 및 개별 요청으로 다른 편집자를 대신하여 수행된다.대부분의 편집자는 나처럼 작업 목록을 발표하지 않지만, 인용 봇의 기여 목록은 봇이 자신을 대신하여 편집한 페이지의 기록이기 때문에 부분적인 작업 목록(분명히 인용 봇을 처리했지만 편집하지 않은 페이지는 포함하지 않는다)이다.

https://en.wikiscan.org/user/Citation%20bot은 하루 평균 약 2,500건의 편집 내용을 보여준다.따라서 BareRefBot grab이 인용봇의 마지막 편집 1만 건을 말한다면, 이는 보통 CB의 약 4일 분량의 작업으로, 작업하기에 좋은 목록이 될 것이다.대부분의 편집자들은 맨 URL을 기준으로 인용 봇 작업을 선택하지 않기 때문에 해당 목록에서 맨 URL의 발생률은 낮지만 최근에 인용 봇에 의해 처리된 맨 URL은 모두 낮을 것이다.

또한, BareRefBot이 채우지 않는 실행을 하는 데 문제가 없다고 보지만, 적절한 경우 {{Bare URL PDF}}만 적용하면 된다.조잡한 검색에 따르면, 현재 태깅해야 할 3만 리프가 넘는 것으로 나타나, 며칠 동안 봇을 바쁘게 해야 한다. 즉, 채우기 기능을 해제하고 태그 모드로 실행되도록 하는 것이다.

이게 도움이 되길 바래.브라운헤어드걸(대화) • (출연) 21:20, 2022년 3월 4일(UTC)

@BrownHairdGirl:

BareRefBot의 작업 목록은 내 작업 목록으로만 작성될 필요는 없다.응, 나도 기부자 명단 까먹었어.

따라서 BareRefBot grab이 인용봇의 마지막 편집 1만 건을 말한다면, 이는 보통 CB의 약 4일 분량의 작업으로, 작업하기에 좋은 목록이 될 것이다. 나도 동의해.

대부분의 편집자들은 맨 URL을 기준으로 인용 봇 작업을 선택하지 않기 때문에 해당 목록에서 맨 URL의 발생률은 낮지만 최근에 인용 봇에 의해 처리된 맨 URL은 모두 낮을 것이다.맞아. 인용 봇에 봇을 묶는 것은 인용 봇이 가는 만큼만 빨리 갈 수 있다는 것을 의미한다는 것을 알아두렴. 그렇게 서두르는 것이 아니라 그냥 참고할 만한 것이니까 난 괜찮아.

또한, 나는 BareRefBot이 그 봇이 채우지 않는 런을 하는 것에 아무런 문제가 없다고 본다. 나도 그렇다.Rlink2 (대화) 01:44, 2022년 3월 5일 (UTC

고마워 @Rlink2.

나는 BareRefBot이 인가되면 24시간 내내 작동하기 시작할 수 있기를 바랐었다.1분에 7번 편집한다.하루에 약 1만 페이지까지 할 수 있고, 3주 이내에 밀린 일지를 정리할 수 있을 것이다.

인용봇을 따르도록 함으로써, 우리는 그것을 하루에 약 3,000페이지로 제한한다.최대 10주까지 걸릴 수 있다는 얘기인데 아쉽다.하지만 이런 식으로 더 좋은 결과를 얻을 수 있을 것 같아.브라운헤어드걸(대화) • (출연) 01:58, 2022년 3월 5일 (UTC)

@BrownHairedGirl: 예를 들어 하이브리드 모델은 인용 봇이 더 나은 데이터를 얻을 수 있는 웹사이트(예: nytime, 저널, barerefbot이 이해하지 못하는 메타데이터 태그가 있는 웹사이트 등)의 ref를 채우는 것을 피할 수 있을 것이다.그렇게 하면 우리는 두 가지 세계 중 최고를 얻을 수 있다 - 베어레프봇의 속도와 인용봇의 (높은) 품질이다.링크2 (대화) 02:02, 2022년 3월 5일 (UTC)

@Rlink2: 이론적으로는 가능하지만, 아무런 이득도 없이 복잡성을 더한다고 생각한다.

BareRefBot이 해결하기 위해 존재하는 문제는 그 세트인 viz. 인용봇이 채울 수 없는 URL이며, 우리는 그것들의 최종 목록을 얻을 수 없다.Reflinks를 위해 그러한 목록을 만들려고 했던 나의 경험은 위압적이었다: User의 하위 페이지:BrownHairedGirl/No-reflinks 웹사이트 목록 1400개가 넘는데, 아직 완성되지 않았다.브라운헤어드걸 (대화) • (출연) 02:16, 2022년 3월 5일 (UTC)

숫자 몇 개.@Rlink2:나는 AWB의 목록 비교자와 프리 파서를 사용하여 수치를 분석하였다.TL;DR은 인용 봇이 처리하는 다른 기사들에는 BareRefBot에 대한 매우 슬림한 피킹이 실제로 존재한다는 것이다.

나는 오늘 정오 UTC를 기준으로 CB의 최근 수정사항 1만 장을 가져갔다.그것은 2월 28일에 불과 2시간밖에 안 걸리는 5일이었다.그 10K 중 4041명만이 내 리스트에 없었다.이 중 13개만 여전히 {{Bare URL 인라인} 태그를 가지고 있으며 93개에는 태그가 지정되지 않은 비PDF 베어 URL 참조가 있다.중복 제거 후 104쪽이 남았지만 그중 25쪽이 초안이라 메인 스페이스 기사는 79개밖에 남지 않았다.

따라서 CB의 기여도 목록은 BareRefBot이 작업할 수 있도록 하루 평균 16개의 비 BHG 제안 기사만을 제공한다.

그 5일 동안 나는 CB에 1만4,168개의 기사를 먹였는데, 그 기사는 봇이 편집한 6,000개만 모자랐다.이 14,168개 기사 중 2,366개 기사에는 여전히 {{Bare URL 인라인} 태그가 있으며, 10,107개 기사에는 태그가 지정되지 않은 비PDF 베어 URL 참조가 있다.복제품을 제거한 후, BareRefBot이 작업할 10,143개의 기사를 남겼다.그것은 하루에 약 2,000개 입니다.

그래서 그 5일 동안 인용 봇은 내가 제공한 기사의 28.5%에 대한 모든 맨 URL을 채웠다. (또한 맨 참조가 아닌 일부 기사들이 더 많은 것이다.)베어리프봇이 나머지에 큰 흠집을 낼 수 있다면 좋을 것이다.

이것이 도움이 되기를 바란다. --BrownHairedGirl (대화) • (기여) 20:03, 2022년 3월 5일 (UTC)

평가판 사용 기간을 완료한 봇

IndentBot

연산자: 노츠니위스트 (토크 · 기여 · SUL · 카운트 편집 · 로그 페이지 이동 · 블록 로그 · 권한 로그 · ANI 검색)

접수시간 : 2021년 10월 15일 금요일 03:20 (UTC)

기능 개요:토론 페이지의 들여쓰기를 조정하십시오.

자동, 감독 또는 수동:자동

프로그래밍 언어:파이톤, 피위키봇

사용 가능한 소스 코드: 온기투브

관련 토론에 대한 링크(해당하는 경우): 위키백과:Bot_requests/Archive_83#Bot_to_fix_indents

기간 편집:연속(지연에 대한 최근 변경 내용 추적)

영향을 받는 예상 페이지 수:매개 변수에 따라 달라진다.10분이 지연되면 10분당 20~30페이지 정도를 확인한다(아래 기능 세부사항 참조).초기에는 내용이 실속 있는 페이지 대부분이 편집되지만, 봇이 페이지 전체를 처리하기 때문에 시간이 지날수록 접지를 더 많이 다루면서 줄어들게 된다.

네임스페이스:모든 대화 네임스페이스 및 프로젝트 네임스페이스.다른 네임스페이스에 토론 페이지가 있는지 확인하십시오.

제외 준수(예/아니오):예, 피위키봇의 저장 기능을 사용한다.

기능 세부 정보:첫째, wikitxt는 일반적인 방법으로 선으로 분할된다.\n구분 기호로서, (WikiTextParser에서 탐지한 바와 같이) 바로 앞의 표, 템플릿 또는 태그와 같은 특정 새로운 선은 선의 끝으로 간주되지 않는다.그리고 나서 우리는 신청한다.fix_gaps,fix_extra_indents그리고fix_indent_style줄의 순서에 따라

정의들

들여쓰기 문자는*,:그리고#.
주어진 선X, 우리는 라인의 들여쓰기 문자를 다음에 의해 나타낸다.indent_text(X), 그리고 우리는 다음을 기준으로 들여쓰기 수준을 나타낸다.lvl(X). 특히 다음과 같은 경우X그때는 들여쓰지 않는다.lvl(X) == 0.
빈 선은 공백으로만 구성된 선이다.
갭은 두 개의 움푹 들어간 선 사이에 끼어 있는 빈 선의 비어 있지 않은 연속적인 시퀀스로, 이것을 개선과 폐선이라고 한다.
간격의 길이는 빈 줄의 시퀀스 길이입니다.

고치다

fix_gaps: 이 수정은 많은 변형을 가지고 있다.내버려두다A그리고B각각 개폐선이다다음부터 시작하는 개구부 또는 닫기 선과의 간격 없음#제거됨그렇지 않으면 길이 1의 간격이 모두 제거되고, 긴 간격이 제거되는 경우에만 제거된다.lvl(B) > 1.
fix_extra_indents: 우리는 처음부터 끝까지 반복한다.만약 우리가 선을 마주친다면A줄에 이어B그런lvl(B) > lvl(A) + 1다음, 들여쓰기 수준이 다음보다 크거나 같은 선의 후속 청크lvl(B),부터 시작해서B에 의해 왼쪽으로 이동됨lvl(B) - lvl(A) - 1직급이 일은 옷을 벗어서 하는 것이다.indent_text[lvl(A):lvl(B)-1](Python 표기법) 이 선들에서.
fix_indent_style: 처음부터 끝까지 반복해서 선을 조정한다.indent_text동일하거나 작은 수준의 가장 가까운 이전 줄의 해당 문자를 사용하기 위해 각 줄의 각 줄에 대해, 단,#문자는 행에서 제거, 소개 또는 이동되지 않는다.

위의 설명은 몇 가지 세부사항(명칭 에지 사례에 대한 일부 예외 사항)을 생략한다.수정은 다른 라운드가 페이지를 변경하지 않을 때까지 위의 순서로 반복적으로 적용된다(한 라운드면 거의 항상 충분).

모든 에지 케이스를 다루는 것은 기본적으로 불가능하며, 특히 당신이 주문된 목록과 가능한 실수의 조합을 사용할 때, 그것들 중 몇 가지를 생각해 내는 것은 어렵지 않다.희망은 이것들이 받아들여질 만큼 희귀하다는 것이다.

이 봇은 다음과 같이 최근의 변화를 추적한다.delay의 사소한 지연.chunk분, 가장 최근에 대체되지 않은 편집이 포함된 사용자 서명이 포함된 비-봇 편집 확인delay회의록그 효과는 IndentBot은 서명 추가 편집만으로 활성화되며, 가장 최근 지연 시간 내에 서명 추가 편집이 있는 페이지는 편집하지 않는다는 것이다.나는 지연이 10분에서 30분으로 설정되어야 한다고 생각한다.너무 오랜 지연은 편집자가 활발한 토론에서 수동으로 들여쓰기를 수정하여 부분적으로 봇의 목적을 방해하게 된다.비토크 페이지는 편집해야 할 서명이 3개 이상 있어야 하며, 비토론 페이지에 대한 하나의 우발적인 서명이 봇을 트리거하지 않도록 한다.대부분의 샌드박스는 피한다.

토론

또한 누군가 IndentBot을 확인된 사용자로 만들어 CAPTCHA를 우회할 수 있는가?윈스턴 (대화) 04:01, 2021년 10월 15일 (UTC)
- 신경 쓰지 마, 이제 오토콘 확증이야.윈스턴 (대화) 22:54, 2021년 10월 15일 (UTC)
인간 편집용으로만 최근의 변화를 필터링할 때 내가 왜 아직도 봇을 보는지 아는 사람 있어?윈스턴 (대화) 08:25, 2021년 10월 17일 (UTC)
여기서 대답했다.윈스턴 (토크) 01:51, 2021년 10월 18일 (UTC)
참고: 이 BRFA가 제출된 이후 이 봇을 편집한 것으로 보인다.봇은 시험 승인을 받거나 승인되지 않는 한 자신의 사용자 공간이나 운영자의 사용자 공간 밖에서 편집할 수 없다.아노미비OTC 23:07, 2021년 10월 18일(UTC)
죄송합니다, 기능을 잘못 실행하셨습니다.윈스턴 (토크) 01:42, 2021년 10월 19일 (UTC)
이 일을 해줘서 고마워.다른 네임스페이스에 토론 페이지가 있는지 확실하지 않은 경우 등에 대한 응답으로 DYK noms는 항상 생각나는 이상한 예다.템플릿:후보들을 아십니까/라 폴리아 바로코체스터.하지만 우리가 일을 단순하게 하기 위해 이것들을 건너뛰어도 괜찮을 것이다.— 이어위그 (대화) 03:39, 2021년 10월 20일 (UTC)
DYK 유목민들처럼 몇 가지 사례만 있다면, 빠른 제목 접두사 확인으로 처리하기는 꽤 쉽다.윈스턴 (대화) 03:53, 2021년 10월 20일 (UTC)
코드는 상당히 안정되어 있고 주어진 예가 좋게 보이면 봇은 짧은 시험으로 준비한다.윈스턴 (대화) 04:07, 2021년 10월 20일 (UTC)

평가판 승인(편집 50일 또는 7일 중 먼저 발생하는 경우) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.프라임팩(토크) 07:35, 2021년 10월 20일 (UTC)

@Primfac 편집은 사소한 것이어야 하는가?윈스턴 (토크) 07:36, 2021년 10월 20일 (UTC)

재판에서는 좀 더 면밀한 조사를 받도록 '아니오'로 진행합시다.내 생각엔 이게 통과된다면 마이너라고 표시하는 것도 비슷한 봇과 일치할 것 같아.프라임팩(토크) 09:06, 2021년 10월 20일 (UTC)

평가판 완료.여기 차이점을 보십시오.

아직 자세히 보진 않았지만, 내가 본 가장 중요한 사건은 디프피디아에서 80번 라인이었다.{{Div col}}이(가) 포함된 중재 시행 로그/2021.{{Div col}}이(가) 코멘트와 같은 라인에서 시작했으면 좋겠다.윈스턴 (대화) 12:56, 2021년 10월 20일 (UTC)
이전 라인에 예외적인 뉴라인 문자가 포함되어 있는 경우 스타일을 조정하지 않는 것이 가능한 해결책이며, 이 경우 예외적인 뉴라인은 {{Div col}}} 바로 전의 뉴라인이 된다(템플릿 바로 앞의 뉴라인은 라인 분할 단계에서 구분자로 계산되지 않기 때문이다).윈스턴 (대화) 13:03, 2021년 10월 20일 (UTC)
참고: 나는 엣지 케이스가 등장할 때 봇이 모든 케이스를 올바르게 처리하려고 하기보다는 특정 라인을 수정하지 못하도록 하는 것이 가장 쉬운 방법이라고 생각한다.윈스턴 (대화) 13:07, 2021년 10월 20일 (UTC)
모든 코멘트에 열려 있는지 확실하지 않은 경우 언제든지 삭제하십시오.Talk:에서 편집한 것을 보고 왔다.아야톨라와 나는 관심이 있었다.편집한 것을 보면, 그럭저럭 제대로 못 맞추었다.시작은 잘되지만, 들여써야 할 "정답을 공부해줘"를 시작하는 서명 부분에서 실패한다.이것을 놓쳤기 때문에 이후에 편집한 내용이 모두 틀렸다.
또 바뀐 메시지는 10년이 넘었는데, 그렇게 오래된 메시지나 이 부분이 시험의 일부였던 메시지를 바꾸는 것이 과연 일반적인 관행일까?적극적(대화) 23:34, 2021년 10월 20일(UTC)
편집이 나한테 더 잘 포맷되어 보이고 다른 사람의 의견에 관심이 있지만 의도하지 않은 에지 케이스는 보이지 않는다.사용자:에서 링크를 확인하십시오.IndentBot#들여쓰기가 조정되는 이유와 방법을 이해하는 IndentBot.

오래된 메세지에 대해서는, 봇은 그것을 고려하지 않는다.그것은 한 번에 페이지 전체의 들여쓰기를 조절한다.더 활발한 대화 페이지를 위해 오래된 토론은 종종 기록 보관소에 저장된다.봇은 서명이 있는 최근 편집에 의해서만 활성화되기 때문에 보관된 페이지는 건드리지 말아야 한다.윈스턴 (대화) 00:07, 2021년 10월 21일 (UTC)
메시지의 들여쓰기된 부분이고, 마지막 부분(두 번째 회색 미편집 부분)을 들여놓는다.그건 분명히 옳지 않아.적극적 무관심(대화) 00:46, 2021년 10월 21일(UTC)
당신이 언급하고 있는 선들을 부분적으로 인용해줄 수 있니?봇이 들여쓰기를 완전히 고정하지는 않는다는 점에 유의하십시오. 특히, 추가 들여쓰기를 추가하지 않는다(따라서 들여쓰지 않은 줄은 들여쓰지 않은 상태로 유지됨).들여쓰기 문자만 변경하고, 빈 줄을 제거하며, 오버인딩을 줄인다.윈스턴 (대화) 00:56, 2021년 10월 21일 (UTC)
아! 무슨 일이 있었는지 알겠어.전체 발행 섹션은 다음과 같다.
다른 언어로 된 그의 토론 페이지에 있는 해답을 공부해라.아카데미카나다 (토크) 03:21, 2009년 11월 24일 (UTC)
이것이 완전히 시작된 메시지의 끝이다.
:간단한 검색을 통해 그를 마르하스와 그랜드 아야톨라 중 한 명으로 소개한 이슬람 단체, 독립 웹사이트, 학회 등의 출처를 찾을 수 있다. 다음은 다른 언어로 된 몇 가지 입니다.메시지가 들여쓰기로 시작됨을 주의하다.
메시지의 시작은 들여쓰기되었고, 봇은 메시지의 중간선을 정확하게 들여쓰게 되었지만, 끝부분은 원래 들여쓰기가 아니어서 봇은 무시했다.네가 말했듯이, 들여쓰지 않은 선은 들여쓰지 않은 채로 남아 있지만, 그것은 두 단계의 들여쓰기를 가진 하나의 메시지를 남긴다.액티브디시브(대화) 01:08, 2021년 10월 21일(UTC)
그래, 이 봇은 모든 오류를 고칠 만큼 똑똑하지 않아."메시지당" 수준의 세부적인 수준에서 문제를 다루려면 훨씬 더 발전해야 할 것이고, 심지어 너무 많은 에지 케이스가 있다.윈스턴 (토크) 01:14, 2021년 10월 21일 (UTC)
회선 파티셔닝을 약간 개선했다.또한fix_indent_style이제 목록을 깨는 새로운 라인 이후 "메모리"를 재설정한다.이런 행동은 더욱 일리가 있고 본래의 움푹 들어간 곳에 더욱 충실하다.앞에서 말한 {{Div col}}을(를) 포함해 꽤 많은 버그를 해결한다.윈스턴 (대화) 05:08, 2021년 10월 22일 (UTC)
@Primfac: 좀더 면밀한 조사를 이끌어내기 위해 다른 실험을 해도 될까?(또한 이번에는 툴포지에서 테스트하고 싶다.)윈스턴 (대화) 08:42, 2021년 10월 22일 (UTC)
[49]에 관하여: 이것은 봇의 잘못이 아니라, AFD에서는 투표에 총알을 사용하는 관습이지만, 델소트 통지는 콜론 인덴트를 사용한다.이 경우, 봇은 첫 번째 델소트 통보 후 모든 총알을 콜론으로 바꿨고, 말 그대로 모든 AFD에서 이런 일이 일어날 것이다.이 일에 대해 뭔가 조치를 취할 수 있을까?
평가판 연장 승인(50개 편집) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.편집 요약에서 정책/정보 페이지를 인용할 것을 제안한다.또한 평가판에서도 사용자 대화 페이지에 보조 편집 플래그를 사용하는 것을 고려하십시오. 그렇지 않으면 사용자에게 새 메시지가 경고될 수 있기 때문이다.– SD0001 (대화) 12:24, 2021년 10월 24일(UTC)
좋아, 사용자 대화 페이지의 편집은 사소한 편집이 될 거야.또한 <작은 클래스="delsort-notice"로 시작하는 코멘트에 대해서는 간단한 예외를 추가할 수 있다.MOS에 링크 추가:편집 요약에 INDENTMIX.윈스턴 (대화) 12:31, 2021년 10월 24일 (UTC)

@SD0001:사실, 이 델소트 공지는 어떻게 삽입되는 겁니까?수동으로 입력하거나 자동화가 필요한가?나는 그들 중 한 명이 단지 "클래스" 속성 없이 <작은 것>을 사용한다는 것을 알아차렸다.윈스턴 (대화) 12:48, 2021년 10월 24일 (UTC)

찾았다.{{Deletion sort}}} 입니다.하지만 가끔 누군가가 수동으로 추가하는 것 같아.작은 태그에 regex를 사용하고 그 뒤에 "Note:"를 붙일 겁니다.윈스턴 (대화) 12:57, 2021년 10월 24일 (UTC)
예, 이 템플릿은 몇 가지 툴로 인해 변위되어 있으며, MediaWiki:Gadget-twinklexfd.js 및 사용자:엔터프라이즈/delsort.js가 두 가지 공통점이다.– SD0001 (대화) 12:58, 2021년 10월 24일(UTC)
@Notsniwiast 사실, 나는 그 템플릿 대신 총알을 사용하기 위해 과감하게 편집했다.아무도 내 편집을 되돌리지 않는다면, 예외는 불필요할 것이다.– SD0001 (대화) 13:02, 2021년 10월 24일 (UTC)
@SD0001 여전히 재판에 이 예외를 추가하고, 나중에 제거해 줄까?윈스턴 (대화) 13:05, 2021년 10월 24일 (UTC)
그래, 그게 더 나을 거야. 왜냐하면 봇은 이미 대장내 소포 통지가 있는 많은 페이지들을 만지고 있을 테니까.– SD0001 (대화) 13:06, 2021년 10월 24일(UTC)

평가판 완료.여기에서 기여도를 보거나, 여기서 알파벳 순서로 차이점을 확인하십시오.윈스턴 (대화) 14:50, 2021년 10월 24일 (UTC)

위키백과처럼 보인다:토론 카테고리는 또한 봇을 유발하는 몇 가지 템플릿을 사용한다.윈스턴 (대화) 14:53, 2021년 10월 24일 (UTC)
템플릿 토크 참조:Cfd2#이 템플릿과 관련된 선행 콜론 제거– SD0001 (대화) 16:58, 2021년 10월 24일(UTC)
나는 이 편집을 하지 말았어야 했다고 생각한다.사용자:Salimfadhley가 3개의 총알 포인트에 대해 언급한 것은 그들이 파라브릭과 비슷한 효과를 만들려고 의도한 것처럼 보일 때였다.ಮಲನನಡ್್್್ ( ( ( ( ( ( ( ((토크 ) 15:53, 2021년 10월 24일 (UTC)
특수:Diff/1051601137은 나에게 걱정거리야.봇이 편집을 하지 말았어야 했기 때문이 아니라, 모든 항목이 기본 템플리트에 의해 만들어졌기 때문이다.템플릿을 변경하거나, 봇에서 PERM 페이지를 제외하거나, 누군가 권한을 요청할 때마다 봇이 뒤에서 따라와 수정한다는 사실을 받아들이거나.옵션 1(사전 설정된 레이아웃 변경)이 가장 좋지만, 특히 점원이 필요한 봇이 있기 때문에 더 많은 논의 및/또는 합의가 필요할 것 같다(그것이 어떤 영향을 미칠지 확실하지 않음).프라임팩(토크) 17:08, 2021년 10월 24일(UTC) 오늘 노쇼에 미안, 왠지 심한 두통을 겪는다.
- 그래, 주변에 이런 템플릿이 몇 개 있는 것 같아.지금 당장은 관련 페이지를 빼고, 템플릿이 변경되면 나중에 포함시킬 계획인 것 같아.하지만 여전히 모든 관련 항목이 템플릿을 사용하여 만들어지는지는 잘 모르겠어.나는 <작은 클래스="delsort-notice"와 같은 델소트 통보와 단지 <작은 것>의 차이점을 볼 수 있기 때문에, 템플릿이나 편집자가 수동으로 두 가지 이상의 버전을 하지 않는 한, 몇 가지 다른 도구들이 관련될 수 있다(보조 편집 도구에 대해서는 아무것도 모른다).또 다른 예는 위키백과:물품_for_deletion/Metropolitan_Gazette_(2차_nomentation)이 여전히 사용되는 경우:SD0001의 편집 후에 만들어졌음에도 불구하고.지금은 "위키피디아:요청_for_permissions/" 및 "Wikipedia:토론/" 카테고리<작은> 태그를 사용한 통지서는 이미 재판을 위해 처리되었다.윈스턴 (토크) 02:16, 2021년 10월 25일 (UTC)
나는 결국 편집자 한 명에게 왜 그들의 배달 통지에 클래스 속성이 없는지 물었고, 보아하니 그들은 단지 수동으로 그것을 하고 있었다.그래서 나는 수작업의 편집에 의한 변화일 가능성이 높다고 생각한다.윈스턴 (대화) 11:14, 2021년 10월 25일 (UTC)
참고: (이것은 ಮ್ನಡ್್್ comment comment comment comment의 코멘트에 대한 답신인데, 보다 일반적으로 관련성이 있어 여기에 게시하고 있다.)불행히도, 이런 피할 수 없는 경우에는 할 일이 별로 없다.SD0001에서도 비슷한 예를 들고 나왔다.문제의 본질은 봇이 전체 논의를 한 번에 운영하도록 요구한다.그 결과, 토론에서 단 하나의 사소한 "폭력" 이상의 어떤 것이라도 편집자의 들여쓰기를 시각적으로 변경하지 않고는 일관되고 접근 가능한 목록을 만들 수 없게 된다.예외를 만들면 목록/표시가 깨지고, 종종 이슈를 목록의 다른 부분으로 이동시킨다.변화는 보통 경미하고 핵심 내용을 바꾸지 않기 때문에, 나는 이것이 받아들여지길 바란다.또한 봇의 작업이 {{pb}}, {{pb} 등 템플릿에 대한 인식을 높여주길 바란다.HTML lists}은(는) 잘못된 마크업에 대한 가장 일반적인 이유를 설명한다.나는 이 템플릿들과 다른 가이드라인들에 대한 링크를 봇의 사용자 페이지에 가지고 있다.윈스턴 (토크) 02:26, 2021년 10월 25일 (UTC)
나는 그 봇이 불필요한 빈 줄을 삭제하는 쓸모없는 편집을 하는 것을 알아챘다.사실 이 봇이 하기 위해 열거된 모든 것은 쓸모없는 것이다.나는 의도적으로 더 들여쓰거나 들여쓰기의 스타일을 바꿀 것이다. 그래서 이것은 그것을 되돌리려고 하는 것처럼 보인다.이 봇이 문제가 아닌 것을 고치려고 하는 것 같아.확실히 이 근처에서 봇을 다루는 것이 더 유용하다.Graeme Bartlett (대화) 10:24, 2021년 10월 26일 (UTC)
@Graeme Bartlett 당신은 당신의 지나친 표현이나 변화무쌍한 들여쓰기 스타일의 예를 제공할 수 있는가? 어떤 일반적인 들여쓰기가 부적절하며 접근 가능한 해결책이 비실용적인가?내가 본 바로는, 이것은 상당히 드물지만, 피할 수 있는 가장자리 케이스일 수도 있다.윈스턴 (토크) 02:46, 2021년 10월 27일 (UTC)

사용자 대화에서 이동:IndentBot/Archive 1 § 쓸모없는 편집

– 윈스턴 (토크) 11:10, 2021년 10월 26일 (UTC) 처음 토론회를 옮기면서 내가 잘못했는지를 말해라.

이 봇은 여기서 쓸모없는 편집을 했다: https://en.wikipedia.org/w/index.php?title=Talk:Bicarbonate&curid=1450293&diff=1051599806&oldid=1051598562

우리가 보는 생산량에 영향을 주지 않는 것 같아나는 봇이 화장품만을 바꾸는 것은 허용되지 않는다고 생각했다.여분의 빈 라인이 중복되어 있어도 에테르를 제거할 필요는 없다!Graeme Bartlett (대화) 10:18, 2021년 10월 26일 (UTC)

이 편집은 시각적 출력(두 개의 탭을 열고 앞뒤로 전환하면 보다 쉽게 볼 수 있음)을 약간 변경하고, 더 중요한 것은 위키백과별로 HTML에 접근하기 쉽도록 변경하기 때문에 엄밀히 말하면 외관적인 편집은 아니다.스타일 /리스트 매뉴얼 § 목록 스타일 , MOS:INDENTMIX 및 도움말:§ 공통의 실수를 나열하십시오.더 큰 논의에서 시각적 향상은 중요할 수 있다.윈스턴 (대화) 11시 10분, 2021년 10월 26일 (UTC)
이 봇은 화면 판독기 사용자에게 유용한 MOS:Accessibility 문제를 수정한다.또한 새로운 WP와 같은 툴링을 위해 토크 페이지를 더 쉽게 접근할 수 있도록 한다.회신툴.그 변화는 시각적 개선에 관한 것이 아니다.– SD0001 (대화) 12:59, 2021년 10월 31일(UTC)

끊다

이 상황은 어떤가?여기서 어디로 가야 할지 잘 모르겠어.모바일에서는 글머리표, 글머리표, 글머리표 없는 댓글이 줄을 서지 않는다는 것을 알게 되었다(예를 들어 여기서 확인) 봇이 훨씬 더 효과적이다.윈스턴 (토크) 01:06, 2021년 10월 29일 (UTC)

{{BAG 지원 필요}}윈스턴(토크) 09:17, 2021년 10월 31일(UTC)

이번에는 좀 더 큰 재판이 필요할 것 같아.CfD 템플릿은 토크 페이지 노트별로 수정되었고, PUM 템플릿도 편집하셨군요.WP의 경우:RFUD @Graeme Bartlett의 출신이라고 추측하는 데, ~~문제는 {{}~~인 것 같다.~~UND}} 변위기가 글머리 자국을 만들 때, 그러나 대부분의 사용자는 이것을 알아차리지 못했고 어쨌든 자신의 들여쓰기 문자를 추가하고 있다.~~
또한 최종 들여쓰기 성격 변경 문제도 논의되어야 한다고 생각한다.나는 어떤 선호도 가지고 있지 않지만 가시적인 총알을 총알이 없는 것으로 바꾸는 것(또는 그 반대로 [50]의 몇 가지 경우를 보는 것)은 거슬리는 것으로 보일 수 있다고 생각한다.이것에 대한 다른 사람들의 생각을 듣고 싶다.– SD0001 (대화) 12:59, 2021년 10월 31일(UTC)

라디오 침묵에 대한 사과, 내 인생의 현시점에서는 비교적 낮은 우선순위지만, 나는 여기서 더 많은 재판이 아마도 좋을 것이라는 것에 동의한다.프라임팩(토크) 13:03, 2021년 10월 31일 (UTC)

마지막(그리고 따라서 시각적) 캐릭터를 바꾸는 것이 짜증날 수 있다는 것을 깨달았지만, 중요한 것은 애초에 등장인물을 섞으면 안 된다는 것이다.따라서 최종 들여쓰기 문자가 변경되지 않으면 수정 사항의 상당 부분을 중성화시킨다.다음과 같은 간단한 단일 레벨 목록도

* Comment 1. : Comment 2. * Comment 3. : Comment 4.

HTML과 스크린 리더의 네 개의 별도 목록으로 남겨질 것이다.최종 문자에 나타나는 들여쓰기 스타일 수정의 일부분을 계산해 볼 수 있는지 봅시다.윈스턴 (대화) 13:17, 2021년 10월 31일 (UTC)

범주에서:자동으로 서명되는 비토크 페이지(페이지의 빠른 모음을 얻기 위해 이것을 사용함), 2770줄의 들여쓰기 문자가 변경되고, 839줄의 마지막 문자가 변경된다.각각의 변경된 문자는 (대부분 항상) 있어서는 안 되는 곳에서 새로운 리스트가 시작되고 있음을 나타낸다.윈스턴 (대화) 13:31, 2021년 10월 31일 (UTC)

@SD0001 {{}}} 혼란스러워UND} 템플릿.샌드박스에 넣었을 때 총알점을 못 봤고 템플릿 문서에도 총알 포인트가 안 나왔어나는 Graeme Bartlett가 그들이 연관되어 있는 차이를 통해 그 봇을 알아챘다고 믿는다.윈스턴 (대화) 14:26, 2021년 10월 31일 (UTC)

정말 그렇지 않다.나는 그렇게 많은 RFUD 코멘트가 과의인([51])된 이유라고 추측했다.– SD0001 (대화) 14:36, 2021년 10월 31일(UTC)

@SD0001 나는 "마지막 캐릭터 문제"를 검토했는데, 예를 들어, 한 수준에서 첫 번째 코멘트가 불룩해졌을 때 어떻게 그것이 침해될 수 있는지 알 수 있다. 그러나 다음의 코멘트는 모두 또는 대부분 불룩해졌고, 그 후 봇에 의해 변경된다.두 가지 예는 "수미야-8974에 대한 언반 요청"과 "소요코아니스 언반 호소"에서 찾아볼 수 있다.아마도 나는 봇이 각 레벨에 대해 어떤 유형(방전 또는 비방전)이 더 일반적인지 먼저 계산한 다음, INDENTMIX 위반에 직면했을 때 더 일반적인 유형을 사용하는 절충안을 구현할 수 있을 것이다.윈스턴 (대화) 10:10, 2021년 11월 1일 (UTC)

이 전략으로 최종 캐릭터가 변경된 라인이 25% 줄어든 630개가 된다.윈스턴 (대화) 13:27, 2021년 11월 1일 (UTC)

나는 세 가지 수정 각각을 조금씩 개선해 왔고 봇은 세 번째 재판을 받을 준비가 되어 있다고 생각한다.나는 최종 캐릭터 인덴트믹스 위반을 단순히 무시하지 않고서는 더 이상 최종 캐릭터 문제를 완화할 수 없다고 생각한다.재판 중/후에 불평하는 사람이 있는지 알 수 있을 것 같다.재판을 위한 사용자 대화 페이지를 제외하고 최소가 아닌 편집 정책을 계속 진행하여 더 많은 정밀도를 끌어낼 것이다.윈스턴 (대화) 13:56, 2021년 11월 2일 (UTC)

@SD0001:나는 그 봇이 보수적이지 않다는 것을 깨달았고, 때로는 원 편집자의 들여쓰기 스타일을 보존하지 않음으로써 본문을 이해하기 어렵게 만들곤 했다.브레인스토밍과 시행착오를 거친 후, 나는 봇이 원래의 들여쓰기를 훨씬 더 존중하도록 만들 수 있었다. 접근성을 약간 희생시키면서 말이다. 즉, 그것은 특정 인디엔트믹스 위반에 대해 원문을 무시하는 것이다.변경된 최종 들여쓰기 문자의 수는 48% 더 줄어들었다.제3의 재판을 시작할 수 있을까?윈스턴 (대화) 11:04, 2021년 11월 4일 (UTC)

물론 그렇게 해.

평가판 연장 승인(200개 편집) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.– SD0001 (대화) 06:48, 2021년 11월 5일(UTC)

인덴트봇은 반드시 필요하다.일부 편집자들은 그들의 원고를 가지고 실수를 한다.몇몇은 단순히 어떻게 들여써야 할지 모른다.제일 답답해?어떤 사람들은 고의적으로 잘못 진술했다(보통 그들의 실수가 지적된 후) & 그들이 잘못 진술한 것을 고의적으로 '의도' 했을 때?그것은 기본적으로 비유적인 '중간 손가락'을 당신에게 주는 그들의 방식이다.굿데이 (토크) 17:47, 2021년 11월 5일 (UTC)

평가판 피드백

예

나는 이 거대한 리팩터링을 이 봇이 내 토론을 편집하는 것을 보고 되돌렸다. 나는 그 부분을 분리하기 위해 일부러 총알을 선택했다.— Xaosflux 13:53, 2021년 11월 5일(UTC)
여기 또 다른 예가 있다: diff - 이것은 말이 되지 않는다. 첫 번째 줄은 분명히 "토론"의 일부가 되기 위한 것이 아니었기 때문에 다르게 양식화되었다.— Xaosflux 14:01, 2021년 11월 5일(UTC)
더 많은 불량 편집(다른 편집기에서 이미 되돌림)— xaosflux 14:03, 2021년 11월 5일(UTC)
내가 추측할 수 있는 다른 봇의 예를 쫓지 말자. 이미 한 가지 방법을 편집하도록 특별히 프로그램되어 있었다.— Xaosflux 14:09, 2021년 11월 5일(UTC)
새로운 목록을 더 나쁘게 만든 또 다른 예는 이 로봇이 이중 총알을 도입한 "자폐적인 사람" 주위의 섹션을 참조하십시오.— Xaosflux 14:54, 2021년 11월 5일(UTC)

토론하다

나는 이 과제가 항상 모든 편집에 대해 발표되기 전에 훨씬 더 큰 논의가 필요할 것이라고 생각한다; 나는 그것을 뒷받침할 정책이 없는 논쟁적인 편집(즉, 특정 들여쓰기 또는 목록 스타일만 사용하도록 허용된 정책)을 계속 할 것으로 기대한다.— Xaosflux 13:58, 2021년 11월 5일(UTC)

이런 편집본을 보면 볼수록 이건 근본적으로 깨진 것 같다.특정 페이지의 OPT-IN-ONY로서 유용할 수 있는가?— Xaosflux^Talk 14:04, 2021년 11월 5일(UTC)
일단 마지막 들여쓰기 캐릭터를 완전히 바꿔야 할 것 같아.에지 케이스가 너무 많아미안하다.네가 게시한 내용을 검토해 보고, 이 행동을 무력화시킨 후에도 봇이 계속 수정했을지 확인해 볼게.이전에 마지막 인물 문제가 제기되었지만, 나는 그 문제를 과소평가했다.윈스턴 (대화) 14:09, 2021년 11월 5일 (UTC)
그렇다, 나는 마지막 인물의 들여쓰기를 전혀 변경하지 않는 것을 제안하고 싶다.내가 믿는 바로는 접근성 문제는 별로 없고, 그것을 고치는 것은 분명히 가치 있는 것보다 더 큰 문제처럼 보인다.– SD0001 (대화) 14:47, 2021년 11월 5일(UTC)
당신이 이것을 승인했을 때 당신들이 무슨 생각을 하고 있었는지 모르겠지만, 그것은 기존의 논의를 완전히 망치고 있다[52].그리고 BTW는, 실제로 스크린 리더를 사용하는 한 친구의 말에 따르면, 무늬를 들여쓰는 것이 이 큰 일이라는 생각 전체가 하나의 신화라고 한다.이는 문자 그대로 수십만 건의 토론과 게시물을 이해할 수 없게 만들 수 있는 잠재력을 가지고 있다.지금 당장 그만둬 EENG 14:10, 2021년 11월 5일(UTC)
EENG, 이것은 시험 운영인데, 특히 이런 종류의 문제가 발생하는지 확인하기 위해 시행된다.분명히, 큰 우려가 있고, 여기의 마지막 몇 가지 게시물에 근거하여, 나는 이 봇이 중요한 점검 없이는 승인되지 않을 것이라고 생각하기 시작했다.프라임팩(토크) 14:12, 2021년 11월 5일(UTC)
그렇게 생각해?어떻게 이게 날 수 있다고 생각하셨죠?내가 읽은 바로 위에서 나는 봇이 원래의 의미를 훨씬 더 존중하도록 만들었다. 아, 그는 토론자들이 사용하는 의미를 존중하고 있는데, 이것은 토론의 흐름을 따르는 데 훨씬 더 중요하다.너희들은 기꺼이 타협하고 토론은 불가능하게 만든다는 거야?EENG 14:19, 2021년 11월 5일(UTC)

관련 사용자의 사전 승인 없이 사용자 페이지에서 시험 실행을 하지 않는 것이 좋을까?나는 EENG의 토크 페이지에서 봇을 되돌렸다. 단지 EENG가 그 효과를 좋아한다는 것이 정말 믿기 어려워 보였기 때문이다.그의 연설 페이지는 우주에서 볼 수 있다는 것을 기억하라.비쇼넨탈크 14:23, 2021년 11월 5일(UTC)
맞아, 내가 네임스페이스를 없앴어.윈스턴 (대화) 14:25, 2021년 11월 5일 (UTC)
사용자 토크 네임스페이스를 제거했으니 기사 토크 페이지와 프로젝트 가이드라인 토크 페이지만 망치겠다는 겁니까?뭐, 이제 시작인 것 같군
넌 이해 못 해기존의 페이지를 망치지 않고서는 할 수 있는 방법이 없다. 왜냐하면 INDENT의 주장과 사람들이 그들의 토론을 실제로 포맷하는 방식 사이에 근본적인 갈등이 있기 때문이다.당신이 하고자 하는 것은 불가피하게 기존 토론의 형식을 바꾸어 편집자의 논평의 의미가 바뀌게 된다.너는 원을 네모나게 만들려고 하고 있고, 그것을 완전히 포기해야 한다.EENG 14:56, 2021년 11월 5일 (UTC) P.S. 나는 방금 위에서 이 계획이 프로젝트 페이지(예: 토크 페이지뿐만 아니라 실제 가이드라인과 정책)도 망치는 것이라는 것을 알아차렸다.정신병자들이 분명히 망명을 점령했다.

이미 2번의 재판(50+50 = 100 편집)이 진행되었는데, 기본적으로 부정적인 피드백이 전혀 없었으며, 이것이 200번의 편집에 대한 연장재판을 승인한 이유였다.문제를 야기하는 새로운 코드에서 뭔가 퇴보한 것 같다.@Notsniwiast가 이제 봇을 멈춘 것 같다.– SD0001 (대화) 14:25, 2021년 11월 5일(UTC)
동의해. 이건 토크 페이지의 포맷을 재킹하는 거야.때때로 형식은 의도적으로 거기에 있다.예를 들어, Talk:Stanley Kubrick의 봇을 풀었다.집 올랜도 (토크) 14:14, 2021년 11월 5일 (UTC)
@Jip Orlando 죄송합니다, 총탄에 의한 스와핑 문제였습니까/총탄 없음 문제였습니까?만약 문제가 격리되었다면, 어느 부분을 언급할 수 있는가?윈스턴 (대화) 14:27, 2021년 11월 5일 (UTC)
[53] 여기서는 토론 내용을 왼쪽으로 옮기고 콜론이 어디에 있는가에 총알을 추가하여 회신 내용을 수정하는 것처럼 보인다.나는 그것이 서식을 일관적으로 보이게 하는 것으로 이해하지만, 그것은 의도적으로 행해진 것으로 보이는 것을 취소하는 것이다.나는 그 총알이 요점을 만드는 데 사용되는 것으로 보고, 그 요점에 대한 회답으로 그 탄알을 본다.내가 트집잡는 건지도 모르지만 갑자기 총알의 바다가 터져도 일이 정리되는 것처럼 보이지는 않는다.집 올랜도 (토크) 14:38, 2021년 11월 5일 (UTC)
경고 팝업을 좋아하는 사람은 내 계정 토크 페이지를 짜는 것을 좋아하지 않는다. 단지 그것이 의미상 공허한 백색 공간이라는 것을 알아내기 위해서였다.만약 다른 사람이 같은 일을 했다면 나는 화가 났을 것이다.생각 없는 것일 때는 더욱 그렇다.〇 브리 (대화) 14:21, 2021년 11월 5일 (UTC)
미안해, 사용자들의 대화 공간을 좀 더 존중했어야 했는데.그것은 일단 봇에서 제거되었다.윈스턴 (대화) 14:29, 2021년 11월 5일 (UTC)
기록에 대해, 편집이 마이너 편집 + 봇 편집 + 계정에 봇 플래그가 있는 경우 사용자 토크 페이지 통지가 억제된다.나는 네가 이 근처에 bot=진실을 추가할 필요가 있다고 믿는다.또한 봇 깃발이 만료되었다.– SD0001 (대화) 14:39, 2021년 11월 5일(UTC)
봇 깃발이 만료된 걸 깜빡했어.봇 플래그가 켜져 있으면 편집한 내용이 봇 편집으로 자동 표시된다.윈스턴 (대화) 14:41, 2021년 11월 5일 (UTC)
사용자 토크 테스트는 봇 플래그가 없는 한 수행되지 않아야 한다.+bot 및 +minor 속성을 결합하면(nominornewtalk) 새 메시지 알림을 트리거하지 않는 기능.(이는 현재 시험해야 한다는 보증이 아니다.)— Xaosflux^Talk 14:39, 2021년 11월 5일(UTC)
@SD0001:나는 운영자 @Notsniwiast: 그들이 방금 편집한 모든 편집을 수동으로 검토하고 페이지를 더 악화시킬 수 있는 모든 것을 되돌릴 것을 제안한다.— Xaosflux^Talk 14:56, 2021년 11월 5일(UTC)
나는 그가 그렇게 하는 것을 믿을 수 없다고 생각한다.그가 해야 할 일은 즉시 모든 것을 되돌리는 것이고, 봇의 편집에 이어 페이지가 편집된 곳에는, 스스로 살펴보라고 메시지나 경고하는 어떤 것을 게시하라.이거 진짜 심각하다.이게 아무 데도 없다는 게 믿어지지 않아.EENG 14:59, 2021년 11월 5일(UTC)
응, 지금 돌아오고 있어.윈스턴 (대화) 15:00, 2021년 11월 5일 (UTC)
내 감시 목록에서:나는 더 이상 말하고 싶지 않지만, [54] 이것은 AlwaysInRed의 메시지의 배치(그리고 따라서 의미)를 바꾸었다.많은 디프들은 큰 변화를 가지고 있기 때문에 어떤 것이 문제가 되는지 알아내기 어렵다.Urve (대화) 15:51, 2021년 11월 5일 (UTC)
@Urve 메시지를 부분적으로 인용해서 내가 찾을 수 있게 해줄래?그것은 "나는 납분해자와 한 명"인가?윈스턴 (대화) 15:53, 2021년 11월 5일 (UTC)
그렇다. 비록 그것이 의도하지 않은 실수였다 하더라도, 사람들은 이런 식으로 의도적으로 댓글을 달며, 계속해서 우여곡절하지 않은 댓글에 답한다.사람들이 왜 이렇게 하는지는 나도 잘 모르겠어.하지만 문제는 이 모든 것들이 그들이 답하고 있는 것과 무관하게 퇴색되면 의미가 바뀐다는 것이다.Urve (대화) 15:57, 2021년 11월 5일 (UTC)
나는 이 봇이 실패할 운명이고, 지속적인 사용을 위해 승인되어서는 안 되며, 그것이 만든 제한된 시험 운영에도 결코 승인되어서는 안 된다고 생각한다.내가 여기서 처음 본 것은 완전히 잘못된 토크 페이지 리팩터링의 몇 가지 차이점이었고 디프포스터는 완전히 틀렸다는 것이 정확했다.토론 페이지에 있는 사람들은 다른 것을 의미하기 위해 들여쓰기를 사용하는데, 그것은 봇이 적절하게 추측할 수 없다. 왜냐하면 들여쓰기의 의미는 그들의 논평의 구문보다는 그들이 말하고 있는 것의 의미에 있기 때문이다.단지 쉬운 예를 선택하기 위해, 사람들은 응답하는 사람을 표시하기 위해 코멘트의 들여쓰기 수준(토론에서 정확히 같은 장소에 배치된 코멘트에 대한 여러 다른 들여쓰기 수준 중)을 선택할 것이다; 만약 봇이 앞뒤의 그 부분을 이해할 수 없다면(그리고 그럴 수 없는 경우) 들여쓰기 수준을 올바르게 조정할 수 없다.n. 사람들은 때때로 그들이 원하는 코멘트의 중요도에 따라 자신의 코멘트의 *표현 또는 :표현 중 하나를 의도적으로 선택하고 코멘트 내의 하위 요소뿐만 아니라 전체 코멘트에 *표현과 :표시를 모두 사용할 것이다.게다가, 편집자들은 심지어 그들의 논평에 대해 조심스러운 인간 리팩터링에도 상당한 화를 내는 경우가 많다.이는 존재하지도 않는 완전한 인간 수준의 AI 없이 해결할 수 있는 과제가 아니며, 그마저도 석연치 않은 가치가 있다.의미 있는 것을 바꾸는 봇 광란은 나쁜 일이고, 전혀 불필요하다.우리는 우리의 토크 페이지가 어떤 사양에 따라 잘 구성될 필요가 없다.우리는 그들이 서로 의사소통을 하기 위해 필요하다.—David Eppstein (대화) 16:16, 2021년 11월 5일 (UTC)
- @David Eppstein:시각적 차이가 없는 편집만 이루어진다면?즉, 종류의 편집
```
* 원 : : : : 2
```
  로
```
하나, 둘
```
  윈스턴 (대화) 16:25, 2021년 11월 5일 (UTC)
  - 위의 예를 보십시오.위키코드 좀 봐.만약 당신이 이 페이지에서 봇을 실행했다면, 그것은 당신의 첫 번째 예를 "수정"하여 당신의 메시지를 무의미하게 만들 것이다.그것이 바로 여기서 본질적인 문제인 것이다: "*" 다음에 "::"가 뒤따르는 이 특정 사례가 오류의 의도적인 예이기 때문에 남아야 한다는 것을 알 수 있는 논리를 쓸 수 없다.그러기 위해서는 인간의 두뇌가 필요하다.레비비치 16:33, 2021년 11월 5일(UTC)
    그 봇은 "syntax highlight" 태그 안에 있기 때문에 첫 번째 예를 고치지 않을 것이다.윈스턴 (대화) 16:34, 2021년 11월 5일 (UTC)
    나는 내가 출판물을 누르자마자:-) 그러나 대부분의 편집자들은 그런 태그를 사용하는 것을 알지 못할 것이라는 것을 깨달았다.어쨌든, 봇이 이것에 대해 무엇을 할 수 있을까:
    * 1 : 2
    "투"가 새로운 논평인지 아니면 "원"의 두 번째 단락인지 알 수 있는가?만약 하나가 서명되지 않았다면?등. 레비비치 16:40, 2021년 11월 5일 (UTC)
    최종 들여쓰기 캐릭터는 시각적 외관을 바꿀 것이기 때문에 더 이상 변경되지 않을 것이기 때문에 아무 소용이 없을 것이다.윈스턴 (대화) 16:43, 2021년 11월 5일 (UTC)
    좋아, 그럼 이건 어때?
    하나: 둘. 셋. 넷.* 다섯 개.
    2와 4는 총알이어야 하는가?또는 다음 중 하나:
    하나. 둘. 셋.* 4: 5
    이게 모두 두 개의 총탄 리스트가 들어 있는 하나의 댓글인가, 아니면 다섯 개의 다른 댓글인가?콜론으로 바꿀 건가? 총알로 바꿀 건가?레비비치 16:45, 2021년 11월 5일(UTC)
    아무것도 변하지 않을 것이다.미안해, 마지막 들여쓰기 문자로는 줄에 대한 마지막 들여쓰기 문자를 의미해.그러니깐*:그건 그럴 것이다.:. 윈스턴 (대화) 16:48, 2021년 11월 5일 (UTC)
    기본 목록 공백과 최종 문자가 아닌 문자만 변경할 수 있다.그래서 적출 수준과 최종 총알/무탄은 전혀 변하지 않을 것이다.윈스턴 (대화) 16:49, 2021년 11월 5일 (UTC)
    허허, 넌 내 다음 질문인 들여쓰기 수준에 대한 질문을 예상했었구나:-) 그럼 이 두 가지 변화( 들여쓰기 수준에 대한 변화, 최종 캐릭터에 대한 변화 없음)는 방금 실행된 마지막 시험 운영과는 다른 두 가지가 되겠지?레비비치 16:56, 2021년 11월 5일(UTC)
    정답.비주얼은 바뀌면 안 된다.윈스턴 (대화) 16:57, 2021년 11월 5일 (UTC)
    음, 엄밀히 말하면 시각적 변화가 있을 겁니다.:::그 뒤를 이어***봇이 후자를 로 바꿀 것이기 때문에.::*. 윈스턴 (대화) 17:01, 2021년 11월 5일 (UTC)
    
    그래, 하지만 그 특정한 예시(:::: 그 다음에 ***)는 단지 완전한 실수인 것 같으니까, 그 변화는 시력을 가진 독자와 시각 없는 독자들 모두에게 더 좋을 것이다.들여쓰기 수준을 바꾸지 않는 것, 최종 캐릭터를 바꾸지 않는 것이 시각적 변화를 일으키지 않는 비결이라는 게 맞는 것 같다.나는 BAG 회원은 아니지만, 당신이 제안한 수정(그리고 재판의 네임스페이스 제한 등)으로 다시 시험운행을 하는 것이 타당해 보인다.당신이 묘사하고 있는 것처럼 봇을 제한하는 것은 눈에 보이는 독자들에게 변화를 보이지 않게 만드는 것처럼 보인다.당신이 고치려고 하고 있는 문제를 완전히 해결하지는 못하겠지만(문자 파일을 편집하고 한 코멘트를 다른 코멘트와 분리하기 위해 들여쓰기를 하는 것은 완전히 석기 시대의 고풍스러운 것이기 때문에), 우리는 진공관을 사용하는 것이 낫다고 생각한다. :-D 레비비치 17:05, 2021년 11월 5일(UT)C)
    그래 나는 많은 사람들을 화나게/애너링한 것에 대해 기분이 나쁘다.나는 너무 열심이었다.윈스턴 (대화) 17:11, 2021년 11월 5일 (UTC)
    걱정마.우리 중 많은 이들이 단지 스포츠 때문에 EEng를 짜증나게 한다.레비비치 17:18, 2021년 11월 5일(UTC)
- (충돌 편집)이것은 WP와 상충될 것이다.코스메틱봇. 집 올랜도(토크) 16:35, 2021년 11월 5일(UTC)
  - 신경 쓰지 마, 이건 예외야.어느 쪽이든, 많은 미친 사용자들이 그들의 시계 목록을 어지럽힐 것이다.집 올랜도 (토크) 16:37, 2021년 11월 5일 (UTC)
    - 코스메틱BOT 논쟁은 나에게 설득력이 있지만 그것보다 더 많은 것이 있다.외모를 바꾸지 않고 들여쓰기 코딩을 정상화하기 위해 토크 페이지를 바꾸는 것이 의미론적으로 깨끗한 위키마크를 만드는 방법으로 도움이 된다고 생각한다면 착각에 빠지는 것이다.:-표시는 결코 의미론적으로 깨끗하지 않다. :-표시는 정의 목록 내에서만 적절하다. 여기서 실제 목적은 정의 본문을 구분하는 것이며 들여쓰기는 이러한 종류의 목록이 어떻게 포맷되는지에 대한 부작용일 뿐이다.그것은 대화 페이지에 삽입을 위해 사용하는 것은 해킹이다.이와 같이, 봇의 임무는 유용한 것을 성취하기보다는 해킹을 연마하면서 우리의 감시목록을 편집으로 채우는 것일 것이다.—David Eppstein (대화) 17:56, 2021년 11월 5일 (UTC)
      의미론에 관한 것이 아니다.그 변화는 독자들을 스크린에 띄우는 것을 돕기 위한 것이다.나는 그저 그 봇에게 지나치게 열성적이었고, 불행히도 이 재판이 명백해지기까지 시간이 걸렸다.레비비치와의 코멘트 사슬에서 위에서 설명한 한정판이 훨씬 나을 것이다.MacOS를 사용하는 경우 VoiceOver와 갭 및/또는 들여쓰기가 혼합된 목록을 읽어보고 화면 판독기에 어떤 영향을 미치는지 확인하십시오.윈스턴 (대화) 18:39, 2021년 11월 5일 (UTC)
이것은 봇보다는 대본으로서 더 나을 것이다.가급적 토크 페이지의 한 섹션에서만 작동하는 대본이 좋다.스크립트로, 편집자는 게시하기 전에 수동으로 오류를 검토/수정할 수 있다.레비비치 16:31, 2021년 11월 5일(UTC)
윈스턴, 네가 도와주려는 건 알지만 위키피디아를 편집한 건 1800개뿐이야 그리고 그 중 몇 개만 페이지 대화를 할 수 있어당신은 자신이 어떤 일에 관여하고 있는지 그 미묘한 점을 이해하기 시작할 경험조차 가지고 있지 않다.그것은 차를 운전해 본 적이 없는 사람이 고속도로를 다시 설계하는 것과 같다.EEng 16:44, 2021년 11월 5일(UTC)
우리는 확실히 인덴트 봇이 필요하다.어떤 편집자들은 조언을 받고 나서 어떻게 해야 할지 모르고, 인간의 실수를 하거나, 그저 거절할 수도 있다.굿데이 (토크) 17:49, 2021년 11월 5일 (UTC)
- 그것은 봇이 고칠 수 있는 것이 아니다.—David Eppstein (대화) 17:56, 2021년 11월 5일 (UTC)
  - 한 사람이 만들어졌으면 좋았을 텐데, 그렇게 할 수 있었겠지.오랫동안 끌어온 토론들을 읽을 때, 잘못된 뜻을 가진 사람들을 보면, 좌절감을 느낀다.누가 누구한테 반응하는지 말해줄래?굿데이 (토크) 18:15, 2021년 11월 5일 (UTC)
그것은 좋은 생각이고 나는 언젠가 승인될 수 있는 어떤 종류의 봇 작업이 있을 것이라고 확신한다.토론의 위키텍스트를 편집하는 것은 내가 올바르게 하기 위해 생각할 수 있는 가장 어려운 봇 작업일 뿐이다.LISTGAP 변경부터 시작하거나 다른 방법으로 봇이 하는 변경의 양을 제한하는 것이 좋을 것 같아.궁금한 점이 있으면 물어봐; 나(불행히도?ㅋㅋ)는 토론 위키텍스트를 조작한 경험이 몇 년 있다.엔터프라이즈y (토크!) 21:15, 2021년 11월 5일 (UTC)
기본적으로 나는 피처 크리프를 잡았다.나는 그 봇을 단순한 LISTGAP과 비-최종-표시-문자 INDENTMIX 변경사항으로 되돌려 놓았다.윈스턴 (대화) 21:37, 2021년 11월 5일 (UTC)

봇 변경

움푹 들어간 부분을 고치기 위해 봇을 요청한 원래 봇에서는 두 가지 예가 제시되었다.첫 번째 예는 추가 들여쓰기(일반적인 수정) 한 개를 제거하는 것이었고, 두 번째 예는 최종적인 들여쓰기(접근성 수정)가 아닌 들여쓰기 수정(접근성 수정)이었다.나는 이 요청을 처리하기로 결정했지만 피처 크리프를 잡아서 그 생각을 너무 멀리 했다.이것은 결국 지난 재판에서도 증명했듯이 아주 정반대의 "고문"을 만들어냈다.(사용자 대화 편집, 봇기 놓치기 등 절차적 문제 이외에는) 제기된 문제들이 당초 요청을 넘어 구현한 기능들 때문이라고 믿고 사과드린다.

나는 봇을 목록 갭과 비문자 인덴트믹스 수정으로만 제한했다.들여쓰기 수준과 최종 들여쓰기 문자는 변경되지 않는다(따라서 원래 봇 요청의 첫 번째 예는 실제로 그대로 둔다).여기 샌드박스 디프가 있다.이러한 것들은 접근성 변화로, 시각적인 독자들에게 유일한 눈에 띄는 변화는 마지막 들여쓰기 문자로 나타나지 않는 총알 포인트인 '떠다니는 총알'의 숨기기일 것이다.예를 들면

마크업	렌더링:
:1. : 2 ** 3	하나 두 개 셋

될 것이다

마크업	렌더링:
:1 : : : : 2 : :* 3	하나 두 개 셋

윈스턴 (대화) 10:56, 2021년 11월 7일 (UTC)

@Notsniwiast: 여기 샘플 혼합 리스트가 있다. 만약 당신이 그것에 대해 어떤 조치를 취한다면?

확장 콘텐츠
A A A A A A A A A A A A A A A A A A

— Xaosflux^Talk 13:05, 2021년 11월 7일(UTC)

나는 방금 이 리스트에서 그것을 테스트했다.아무 소용이 없다.윈스턴 (대화) 13:09, 2021년 11월 7일 (UTC)

@Xaosflux: 위 내용 참조. --Sand Doctor 07:39, 2021년 12월 29일(UTC)

평가판 완료.중단된 이전 평가판을 종료하는 중.윈스턴 (대화) 06:29, 2022년 1월 5일 (UTC)
{{BAGAssistanceNeedded}}} 위에서 설명한 대로 한정판을 사용해 보고 싶다.재점검을 위해 들여쓰기 수준에 변화가 없어야 하며 최종 들여쓰기 문자에 변화가 없어야 한다.눈에 띄는 유일한 시각적 차이점은 "떠다니는" 총알을 가리켜야 한다.다른 변화로는 목록 간격의 수와 들여쓰기 스타일의 혼합의 양이 감소하는데, 이것은 시각적으로 눈에 띄어서는 안 된다.여기 몇 가지 신선한 차이점 예들이 있다.우리가 살아있는 위키에 대한 재판을 여전히 경계한다면 나는 더 많은 샌드박스 런을 할 수 있다.윈스턴 (대화) 06:29, 2022년 1월 5일 (UTC)
Btw, 편집 요약에서 순서가 지정된 쌍은 (빈 행이 제거된 경우, 하나 이상의 들여쓰기 문자가 변경된 경우)을 나타낸다.윈스턴 (대화) 06:51, 2022년 1월 5일 (UTC)
...그럼.평가판 연장 승인(200개 편집) 평가판이 완료되면 관련 기여도 및/또는 차이점에 대한 링크를 제공하십시오.나는 어떤 형태로든 이 일을 승인하는 것을 전적으로 지지한다.그러나: 비록 나는 이런 말을 하고 싶지 않지만, 사람들이 정말로 토론이 엉망이 되는 것을 좋아하지 않는다는 것을 인식한다면, 나는 여러분에게 더 이상 토론의 의미를 바꾸는 편집이나 실수들이 (가장 보잘것없는 방법으로도) 그 요청에는 그다지 좋게 보이지는 않을 것이라고 경고해야겠다.나는 조심하는 편이 틀렸다.내가 회신 링크를 개발한 경험으로 보아, 위키피디아 토크 페이지에서는, 비록 무언가가 실수처럼 보일지라도, 의도적일 가능성이 충분히 있다.엔터프라이즈y (토크!) 07:02, 2022년 1월 5일 (UTC)
알았어만약 우리가 의미에 영향을 미치는 떠다니는 총알의 합법적인 사용을 발견한다면, 나는 단순히 봇이 변하는 것을 막을 수 있을 것이다.*로:그래서 탄환이 떠있든 안 떠있든 간에 사라지는 것을 막는다.나는 작은 덩어리로 이 실험을 할 것이다. 각 조각에 대한 차이점을 검토한 후 총탄이 제거된 차이점을 지적한다.윈스턴 (토크) 07:19, 2022년 1월 5일 (UTC)

@Enterprisey 시작하기 전에 봇에 (템프) 봇 플래그를 주어야 하는가?또한, 사소한 편집이나 사소한 편집이 아닌지요?윈스턴 (대화) 07:22, 2022년 1월 5일 (UTC)
만약 이전 재판들이 플래그가 붙지 않았다면, 나는 이것이 되어야 한다고 생각하지 않을 것이다; 나는 그것이 재판이고 나는 사람들이 약간 더 사소한 편집에 주의를 기울일 것이라고 생각하기 때문에 그들을 사소한 것이 아니라고 표시하겠다.엔터프라이즈y (토크!) 07:34, 2022년 1월 5일 (UTC)
@Notsniwiast, 나는 편집이 페이지의 시각적 외관을 바꾸지 않도록 각별히 주의할 것을 권고하고 싶다("이중 총알" 오류를 제거하는 것 외에); 우리는 항상 나중에 봇에 더 많은 작업을 추가할 수 있다.네가 벌써 그렇게 하고 있었는지 확실하지 않아(확인하지 않았다); 그냥 메모만 해.엔터프라이즈y (토크!) 08:12, 2022년 1월 5일 (UTC)
응, 마지막 들여쓰기 문자가 아닌 글머리 기호만 제거해.나는 20번 편집한 후에 탄환이 숨겨져 있는 부분을 지적하면서 그 차이를 보여줄 것이다.윈스턴 (대화) 08:16, 2022년 1월 5일 (UTC)

청크 1(20디프)

여기 봐.무슨 걱정거리가 생겼는지 보려고 잠깐 들르는 중이야.윈스턴 (대화) 08:54, 2022년 1월 5일 (UTC)
내가 확인한 몇 개는 괜찮아 보인다.만약 그 다음날이나 이틀 동안 아무도 반대하지 않는다면, 계속해도 괜찮다.100번 편집한 후에 다시 일시 중지하시겠습니까?엔터프라이즈y (토크!) 01:48, 2022년 1월 6일 (UTC)
@Notsniwiast, 나는 봇이 현재 너의 샌드박스를 편집하고 있다는 것을 알아차렸다.샌드박스 편집이 평가판에 포함되지 않은 경우 계속 진행하면서 이 메시지를 무시하십시오.하지만, 당신이 바로 위에 있는 그 중 하나와 연결되었기 때문에, 나는 당신이 샌드박스 편집본을 재판으로 세고 있다고 가정한다.봇 작업은 실제 토론 페이지를 편집하는 작업이기 때문에 가능한 한 그 사용법과 유사해야 한다.즉, 봇이 이번 재판을 위해 샌드박스가 아닌 실제 페이지를 편집해야 한다는 것이다.내가 보기에 재판의 일부는 사람들이 편집에 반대하지 않고 샌드박스에 편집이 이루어지면 반대할 기회를 갖지 못하게 하는 것이다.엔터프라이즈y (토크!) 08:10, 2022년 1월 6일 (UTC)
샌드박스 편집은 재판의 일부가 아니에요어떤 링크를 참조하는지는 모르겠지만 실제 평가판 디프트에 연결할 때는 이 페이지를 복잡하게 만들지 않도록 디프트를 넣은 내 샌드박스 수정본에 영구 URL을 사용한다.윈스턴 (대화) 08:21, 2022년 1월 6일 (UTC)
좋아.잘못 읽었어.엔터프라이즈y (토크!) 08:41, 2022년 1월 6일 (UTC)

청크 2(50디프)

여기 봐.윈스턴 (대화) 10시 7분, 2022년 1월 6일 (UTC)
내가 이 봇에 대해 알고 있는 것은 이번이 처음이며, 위에서 언급한 모든 텍스트를 읽어본 적이 없어서 이 문제가 이전에 해결되었더라면 그렇게 미안하게 생각하지는 않았지만, 요약 편집이 개선될 수 있을까: 예: "MOS:Access#Lists당 조정된 들여쓰기"평가판 편집. (1, 10)"은 세 부분으로 구성된다.
- "조정된 들여쓰기..."는 일종의 괜찮지만, 들여쓰기 수준을 변화시키고 있다는 것을 암시할 수 있다. " 들여쓰기 표시"를 수정하는 것이 더 나을 것이다.
- "트레일 편집"은 전혀 문제가 되지 않는다.
- "(1, 10)"은 암호화된 것이며 디버깅을 위해 운영자에게 잠재적으로 유용하지만, 봇에 친숙하지 않은 편집자들에게는 혼란스러울 뿐이다.
- 편집된 요약에는 리스트에서 여러 개의 빈 줄을 제거하였거나 그 이유는 언급되지 않는다.개인적으로 나는 이것이 MOS에 의한 것이라는 것을 안다.LISTGAP, 하지만 모두가 그러지는 않을 것이다.요약에 봇이 무엇을 했는지, 봇이 왜 그랬는지, 사람들이 봇을 되돌리려는 유혹을 받지 않도록, 애초에 왜 빈 줄을 남겨서는 안 되는지에 대해 알아보도록 그것을 봇이 한 일에 대해, 그리고 봇이 왜 그랬는지 그 이유를 적어두는 것을 추천한다.리스트를 약간 수정하고, Redros64는 더 많은 것을 하는데, 우리 둘 다 요약 편집에서 LISTGAP을 언급했고, 나는 그것에 대해 긍정적인 반응을 보았다.Thryduulf (대화) 13:02, 2022년 1월 6일 (UTC)
  - 좋은 지적이야.편집 요약을 "MOS당 들여쓰기 표시 조정:LISTGAP 및 MOS:INDENTMIX. 빈 줄 X개 제거.들여쓰기 표시의 Y 조정.평가판 편집."윈스턴 (대화) 15:18, 2022년 1월 6일 (UTC)

청크 3(60디프)

여기 봐.나는 이것의 오류를 알아내는데 막혔다: Diff for Talk:공산주의 정권하에서 대량 살상.그 봇은 분명히 "나는 그것이 공정하지 않다고 생각한다"로 시작하는 유동 총알을 라인에 도입했다.하지만 여기 내 샌드박스에 위키텍스트를 복사하면 괜찮아 보인다(누구나 이것을 확인할 수 있다).또한 Talk:의 편집 미리보기에서도 괜찮아 보인다.공산주의 정권하에서 대량 살상.사용자 대화와 대화에서 위키텍스트가 다르게 표시되는가?오류를 재현할 수 없다(실제 토크 페이지에서는 재현을 시도하지 않았고 샌드박스 토크 페이지는 없는 것 같지만).윈스턴 (대화) 20:22, 2022년 1월 7일 (UTC)
좋아, 섹션이 아니라 위키텍스트 전체를 베꼈는데, 실제로 떠다니는 총알이 나타났어.그래서 나는 최소한의 재현 가능한 예(원래 토크 페이지는 600k바이트 이상)를 만들어내려고 노력했고, 그것이 링크와 관련이 있다는 것을 발견했다.이 수정본을 고려하십시오(간단한 표현은 실례지만, 페이지 크기를 줄이기 위해 몇 가지 변환을 수행했다).우리가 관심 있는 대목은 "합의가 기각됐다"는 내용이 담긴 대목이다.떠다니는 총알을 주목해라.이제 페이지를 편집하고 wikitxt의 끝에 있는 wikilink를 물로 삭제하십시오(다른 wikilink를 삭제하는 것도 효과가 있을 수 있음).떠다니는 총알이 어떻게 사라졌는지 주목해라.위키링크를 삭제하는 대신 페이지의 첫 번째 템플릿을 삭제할 수 있고 떠다니는 글머리 기호도 사라진다...무슨 일이 일어나고 있는지 잘 모르겠어.윈스턴 (대화) 01:42, 2022년 1월 8일 (UTC)
- WP에서 논의한 내용:VPT, 이것은 아마도 위키링크 내부의 새로운 라인으로 인한 GIGO 문제일 것이다.나는 그러한 새로운 전화선이 잘 작동하는 것 같았기 때문에 허용된다고 생각했지만 분명히 그렇지 않았다.간단한 해결책과 보수적인 면을 유지하기 위해, 나는 봇이 그 페이지에 포함된 위키링크와 마주친다면, 그 어떤 인덴트믹스 수정책도 수행하기를 거부하도록 하고 있다.\n.
  나는 이 덩어리의 다른 편집에서 전혀 예상치 못한 것을 보지 못했다.윈스턴 (대화) 00:13, 2022년 1월 9일 (UTC)

청크 4(70디프)

여기 봐.여기에 총알자국이 도입된 오류는 단 한 가지였다.이것은 봇이 예상하지 못한 테이블을 만드는 템플릿 때문이었다.봇은 이제 테이블을 확인하기 위해 템플릿을 확장한다. 평가판 완료.윈스턴 (대화) 06:59, 2022년 1월 10일 (UTC)

좀 쉬어야겠다.코드는 아직 사용할 수 있다.이 요청을 취소하는 중.{{BotWithdraded}}}Notsniwiast (대화) 05:15, 2022년 1월 13일 (UTC)

자, 재판이 끝났으니 문제가 발견되지 않는다고 가정하면 지금으로서는 더 이상 어떤 것도 할 필요가 없다.만약 이것이 승인된다면, 당신은 당신이 돌아올 때마다 봇을 실행하기 시작할 수 있다.– SD0001 (대화) 09:51, 2022년 1월 13일 (UTC)

SD0001, 이 요청을 승인하시겠습니까, 아니면 그들의 철회를 수락하시겠습니까?프라임팩 (대화) 15:10, 2022년 1월 23일 (UTC)

@SD0001?솥(토크 • 기여) 10:10, 2022년 2월 13일(UTC)

그들의 토크 페이지에 메모를 남겼다.프라임팩 (대화) 14:18, 2022년 2월 27일 (UTC)

뒤로

안녕, 나 휴식 시간에서 돌아왔어.만약 사람들이 이 봇이 유용하다고 느낀다면 계속하자.단지 내가 걱정하는 것은 사람들이 그것이 도와주는 사람들의 수에 비해 그것이 귀찮다고 생각한다면이다.윈스턴 (대화) 20:01, 2022년 2월 27일 (UTC)

데이비드 엡스타인씨, 이런 말을 해서 미안하지만, 당신은 나보다 더 멀리 이 문제를 추구했소.귀하의 (우리의) 우려 사항이 모두 해결되었는가?EENG 20:21, 2022년 2월 27일(UTC)
- 내 걱정은 "나는 봇을 목록 공백과 비문자 인덴트믹스 수정으로만 제한했다. 들여쓰기 수준 및 최종 들여쓰기 문자는 변경되지 않는다."—David Eppstein (대화) 20:26, 2022년 2월 27일 (UTC)

승인된 요청

BRFA에 성공한 후 운영 승인을 받은 봇은 정보 제공 목적으로 여기에 나열될 것이다.이러한 봇에는 다른 승인 조치가 필요하지 않다.최근 승인된 요청은 여기서 찾을 수 있으며(편집) 이전 요청은 아카이브에서 찾을 수 있다.

Dushan Kreheľ (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) 승인 14:22, 2022년 3월 6일(UTC) (봇에는 플래그가 있음)
BattyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 65) 승인 14:17, 2022년 2월 27일 (UTC) (봇에는 플래그가 있음)
Qwerfjkl (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제:7) 승인 14:12, 2022년 2월 27일 (봇에는 깃발이 있음)
WOSlinkerBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 21) 승인 13:55, 2022년 2월 27일 (UTC) (봇에는 플래그가 있음)
WOSlinkerBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 20) 승인 15:00, 2022년 2월 13일 (UTC) (봇에는 플래그가 있음)
DoggoBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 4) 승인 15:00, 2022년 2월 13일 (UTC) (봇에는 플래그가 있음)
SdkbBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 3) 승인 15:48, 2022년 2월 10일 (UTC) (봇에는 플래그가 있음)
TolBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 13A) 승인 20:53, 2022년 1월 29일 (UTC) (봇에는 플래그가 있음)
Qwerfjkl (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제:6) 승인 20:47, 2022년 1월 29일 (UTC) (봇에는 깃발이 있다)
BattyBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 64) 승인 16:28, 2022년 1월 25일 (UTC) (봇에는 플래그가 있음)
TolBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 13) 승인 15:17, 2022년 1월 23일 (UTC) (봇에는 플래그가 있음)
WOSlinkerBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 19) 승인 17:18, 2022년 1월 18일 (UTC) (봇에는 플래그가 있음)
WOSlinkerBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 18) 승인 09:39, 2022년 1월 13일 (UTC) (봇에는 플래그가 있음)
TolBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 10) 승인 22:25, 2022년 1월 10일 (UTC) (봇에는 플래그가 있음)
FastilyBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 16) 승인 14:21, 2022년 1월 6일 (UTC) (봇에는 플래그가 있음)
NovemBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) 승인 18:38, 2022년 1월 3일(UTC) (봇에 플래그가 있음)
MalnadachBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 12) 승인 10:01, 2022년 1월 2일 (UTC) (봇에는 플래그가 있음)
TolBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 11) 승인 16:31, 2021년 12월 31일 (UTC) (봇에는 플래그가 있음)
PrimeBOT(BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 37) 승인 16:31, 2021년 12월 31일 (UTC) (봇에 플래그가 있음)
SdkbBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 승인 17:38, 2021년 12월 30일 (UTC) (봇에 플래그가 있음)
Qwerfjkl (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 4) 승인 17:32, 2021년 12월 30일 (UTC) (봇에는 깃발이 있음)
Rlink2 Bot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) 승인 07:27, 2021년 12월 29일 (UTC) (봇에는 플래그가 있음)
FastilyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 15) 승인 22:40, 2021년 12월 28일 (UTC) (봇에 플래그가 있음)
NovemBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 승인 09:43, 2021년 12월 16일 (UTC) (봇에 플래그가 있음)
CowBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) 승인 09:43, 2021년 12월 16일 (UTC) (봇에는 플래그가 있음)
BattyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 62) 승인 12:42, 2021년 12월 8일 (UTC) (봇에는 플래그가 있음)
TolBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 9) 승인 13:41, 2021년 12월 5일 (UTC) (봇에는 플래그가 있음)
FireflyBot II(BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 승인 18:12, 2021년 11월 21일 (UTC) (봇에는 플래그가 있음)
BattyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 63) 승인 14:20, 2021년 11월 17일 (UTC) (봇에는 플래그가 있음)
WOSlinkerBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 17) 승인 08:54, 2021년 11월 17일 (UTC) (봇에는 플래그가 있음)

거부된 요청

운영이 거부된 봇은 보관 전 최소 7일 동안 정보 제공 목적으로 여기에 나열된다.이러한 봇에는 다른 조치가 필요하지 않다.이전 요청은 보관소에서 찾을 수 있다.

DoggoBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 6) Bot 거부 08:30, 2022년 3월 6일 (UTC)

BHGbot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 9) Bot 거부 08:16, 2021년 12월 16일 (UTC)

Cewbot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 9) Bot는 14:19, 2021년 9월 19일 (UTC) 거부

Q28bot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 1) Bot 거부 10:28, 2021년 9월 14일 (UTC)

HooptyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) Bot는 2021년 8월 27일 10:31, 2021년 8월 27일(UTC) 거부

SWinxyTheBot(BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) Bot가 21:02, 2021년 8월 22일(UTC) 거부

ProcBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 9) Bot 거부 21:02, 2021년 8월 22일 (UTC)

AWMBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 2) Bot 거부 02:05, 2021년 8월 8일 (UTC)

BattyBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 58) Bot는 2021년 7월 20일 19:16, 2021년 7월 20일 (UTC) 거부

CountyBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) Bot는 23:10, 2021년 6월 29일(UTC) 거부

K.Kapil77 Bot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) Bot는 15:31, 2021년 6월 10일 (UTC) 거부

DoggoBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 2) Bot 거부 00:53, 2021년 6월 5일 (UTC)

LemonadeBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) Bot가 2021년 5월 20일 08:17, 2021년 5월 20일(UTC) 거부

DannyS712 bot IV (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (과제: 73) Bot 거부 09:51, 2021년 4월 21일 (UTC)

사용자 이름키란 BOT(BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 4) Bot 거부 14:17, 2021년 2월 14일 (UTC)

만료된 요청/끌어음

이러한 요청은 사업자가 요구하는 정보가 제공되지 않았거나 철회되었기 때문에 만료되었다.이러한 작업은 실행할 권한이 없지만, 그러한 인증 부족이 반드시 가치에 대한 발견에서 오는 것은 아니다.예를 들어, 시험 승인을 받은 봇은 편집자에 의해 시험되지 않았거나 시험 결과가 게시되지 않은 봇이 여기에 나타날 것이다.위에서 진행 중인 활발한 토론이 있는 경우 봇 요청을 여기에 배치해서는 안 된다.요청이 만료된 운영자는 언제든지 요청을 재활성화할 수 있다.다음 목록은 보관되기 최소 7일 전에 정보 제공을 위해 여기에 나열된 만료된 최근 요청(있는 경우)을 보여준다.이전 요청은 각 아카이브에서 찾을 수 있다.만료됨, 철회됨.

DoggoBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 5) 운영자 17:22, 2022년 2월 28일 (UTC)

DoggoBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 5) 운영자 17:21, 2022년 2월 28일 (UTC)

RichBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 2) 2022년 1월 23일 만료 (UTC)

Rlink2 Bot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 운영자 22:21, 2022년 1월 20일 (UTC)

Qwerfjkl (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 5) 운영자 18:22, 2022년 1월 3일 (UTC)

DoggoBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) 만료 17:43, 2021년 12월 30일(UTC)

Pi's Pixie Bot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) 만료 07:37, 2021년 12월 29일 (UTC)

Qwerfjkl (봇) (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (과제: 3) 운영자 13:38, 2021년 12월 20일 (UTC) 철회

DaxServerBot I (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 3) 만료 01:47, 2021년 11월 16일 (UTC)

DaxServerBot I (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 만료 01:42, 2021년 11월 16일 (UTC)

FASBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 7) 운영자 10:13, 2021년 10월 18일 (UTC)

TNTBot (BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 2) 운영자 18:40, 2021년 9월 21일 (UTC)

TolBot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 6) 운영자 16:21, 2021년 9월 20일 (UTC)

BHGbot (BRFA · 기여 · 조치 로그 · 차단 로그 · 플래그 로그 · 사용자 권한) (태스크 : 8) 운영자 20:21, 2021년 8월 18일 (UTC)

PearBOT II(BRFA · 기여 · 조치 로그 · 블록 로그 · 플래그 로그 · 사용자 권한) (태스크: 10) 운영자 14:02, 2021년 8월 9일 (UTC)

v t 위키백과 기술 도움말
찻집, 헬프 데스크, 빌리지 펌프(기술), 대화 페이지 또는 IRC에서 개인적인 기술 지원을 받으십시오.
일반 기술적 도움	브라우저 노트 캐시 바이패스 바로 가기 키 편집 CharInsert 충돌 편집 도구 모음 편집 되돌리는 중 페이지 작성 방법 IRC 자습서 모바일 액세스 다국어 지원 페이지 이력 페이지 정보 페이지명 도움 인쇄 소프트웨어 통지 편집통지 특수 문자 들어가는 사용자 액세스 수준 비주얼 에디터 사용자 안내서
특수 페이지 관련	특수 페이지 도움말 필터 편집 사용자에게 전자 메일 보내기 로그인 중 암호 재설정 로그 페이지 이동 잘라내기 및 붙여넣기 이동 수정 비관리자 및 관리자 전용 페이지 이동 알림/에코 FAQ 페이지 큐레이션 페이지 가져오기 변경 보류 중 임의 페이지 최근 변경 사항 관련변경 검색 중 링크 검색 태그 사용자 기여도 감시 목록 여기에 링크된 내용
위키텍스트	위키텍스트 치트시트 기둥 라인브레이크 목록 마법의 주문 초보자를 위한 조건식 스위치 파서 함수 시간함수 리디렉션 섹션 및 TOC 테이블 소개 기본 사항 고급 테이블 형식 지정 무너지는 중 조건부 표 정렬 색상 사용
링크 및 디프	링크 언어간 인터위키 영구적 디프스 가장 간단한 확산 가이드 간단한 디프 및 링크 가이드 전체 디프 및 링크 가이드 콜론 트릭 링크 색상 파이프 트릭 URL
미디어 파일: 이미지, 영상과 소리	미디어 도움말 파일 생성 및 사용 파일을 공용으로 이동 이미지들 이미지 소개 그림 자습서 업로드할 이미지 준비 이미지 업로드 중 이미지 숨기기 옵션 확장 이미지 구문 SVG 도움말 갤러리 태그 그래픽 자습서 기본 비트맵 이미지 편집 이미지 품질 향상 방법 그래픽 랩 리소스 사운드 파일 표시 비주얼 파일 마크업
기타 그래픽	가계도 그래프 및 차트 생성 방법 바르차르트 차트 축척 방법 수학 공식 수학 기호 악보 음악 기호 타임라인 EasyTimeline 구문 위키히에로 구문
템플릿 및 루아 모듈	템플릿 고급 템플릿 코딩 템플릿 설명서 템플릿 인덱스 템플릿 제한 템플릿 샌드박스 및 테스트 케이스 인용 템플릿 루아 도움말 루아 프로젝트 자원. 하기 위해서 대체 숙청 작업 대기열 전폐 레이블 단면 낙서 안내서
데이터 구조	네임스페이스 주/기사 카테고리 초안 파일 파일 설명 페이지 도움 포털 프로젝트/위키피디아 이야기하다 보관 간단하다. 템플릿 사용자 사용자 페이지 설계 미디어위키 버그 보고서 및 기능 요청 시스템 메시지 TimedMediaHandler 확장 모듈 특별한
HTML 및 CSS	계단식 스타일 시트 Wikitext의 HTML CSS 클래스 카탈로그 common.js와 common.css 단일 공간 코딩 글꼴에 대한 사용자 CSS 마이크로포맷의 클래스 마크업 유효성 검사 스팬 태그 유용한 스타일
맞춤화 도구 및 도구	우선권 가젯 스킨스 인용 도구 반달리즘 도구 정리 감시 목록 사용자 정의 페이지 숨기기 IRC 스크립트 사용자 스크립트 가이드 기술 사용자 스타일 도구들 대체 검색 브라우저 도구 편집 도구 탐색 바로 가기 최적 공구 세트 Wikimedia 클라우드 서비스 미디어위키의 베타 기능
자동 편집	AfC 도우미 스크립트 AutoWikiBrowser 봇스 작성 중 핫캣 허글 탐색 팝업 레드워른 트윙클 WPCleaner 비활성 이글루 스티키
참고 항목: 카테고리:위키백과 방법 범주:위키백과 정보 페이지 추가 탐색 위치: 도움말 페이지 관리자 접근성 계정 봇스 참조 인용 메타데이터 템플릿 사용자 스크립트

봇 관련 아카이브(v·t·e)
게시판 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16
봇(토크) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22 WP에서의 새로운 논의:2021년 4월 이후 BOTN
Bot 정책(토크) 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 29 Bots(대화)에 보관된 2007년 이전 버전
Bot 요청 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49, 50 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 61, 62, 63, 64, 65, 66, 67, 68, 69, 70 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 81, 82, 83
Bot 요청(대화) 1, 2 WP에서의 새로운 논의:2021년 4월 이후 BOTN
BRFA 이전 형식: 1, 2, 3, 4 새 형식:분류된 보관 파일(모든 하위 페이지)
BRFA(토크) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15 WP에서의 새로운 논의:2021년 4월 이후 BOTN
Bot 승인 그룹(토크) 1, 2, 3, 4, 5, 6, 7, 8, 9 BAG 후보작
위키백과 위키백과_토크

Search

위키백과:봇/승인요청

현재 승인 요청

토론

토론

토론

토론

토론

토론

토론

시험 기간 중의 봇

토론

소스 코드

시험

재판2길

보조 도구로서의 BareRefBot

평가판 사용 기간을 완료한 봇

토론

끊다

평가판 피드백

봇 변경

청크 1(20디프)

청크 2(50디프)

청크 3(60디프)

청크 4(70디프)

뒤로

승인된 요청

거부된 요청

만료된 요청/끌어음