위키백과:마을 펌프(제안)/아카이브 183

RFC: 오늘의 특별 기사 변경 보류 중 보호

다음의 논의는 의견요청을 기록한 기록이다. 수정하지 마십시오. 이 논의는 더 이상 수정해서는 안 된다. 토론의 하단에서 토론의 요약을 찾을 수 있다.

내가 회계만 한다면 자동 반미 보호가 그 결과일 것이다. 그러나 그것은 클로져가 할 일이 아니다. 그리고 WP:PROTECT의 정책 주장은 많은 비중을 차지한다. 그래서 그 점을 염두에 두고, 그리고 아래 논의에 근거해, TFA인 동안 기사에 자동 반미보호를 시도하고 싶다는 커뮤니티의 공감대가 아래에도 있지만, 정책 기반의 타당한 고민도 있다. 따라서 이 문제를 어떻게 처리해 왔는지, 앞으로 나아가면 PC의 초기 구현(이행이 준비될 때마다 시작하는 것)과 마찬가지로 30일간의 자동반미보호 재판으로 해결할 수 있다.

(나는 이것이 "앞으로의 통조림 줍기"로 보일 수도 있다는 것을 알고 있지만, WP:PROTECT 정책은 위키피디아의 근본적인 기둥에 크게 의존하고 있으며, 아래 논의에서 언급된 것처럼 국지적으로라도 그 적용을 수정하는 것은 가볍게 해서는 안 된다. 그리고 폐업 시 기존 정책/지침/오래된 공통 관행을 고려해야 한다.) - jc37 02:15, 2021년 8월 30일(UTC)[]


위키피디아에 이어 2021년 4월 한 달간의 재판이 허가됐다.Billage pump (proposal)/Archive 178#Pending-changes 보호 오늘의 특집 기사 이제 평가판이 종료된 것으로 알고 있다(사용자 대화:Primfac#TFA PC 보호 재판에 대한 후속 RfC; 의례적인 핑과 고지이와 프라임팩에 대한 주의에 감사함). 그래서 나는 그것이 어떻게 진행되었는지, 그리고 다음에 무엇을 할 것인지에 대한 의견을 듣기 위해 이 토론을 열 것이다.

나를 중립적인 존재로 생각하라. 가 말하고자 하는 것은 WP에서 TFA 보호 요청을 본 적이 없는 것 같다는 것이다.2021년 2월 이후 ANI.

원래 토론에 참여한 모든 편집자 ping: TheDragonFire300, Iridescent, Redrose64, Jéské Couriano, Izno, Thryduulf, Vaticidalprophet, Wugapodes, Buidhe, Nosebagbear, Mz7, Bilorv, Hawkeye7, Aza24, HAL333, RandomCanadian, Elli, Extraordinary Writ, firefly, Pinchme123, Yair rand, Espresso Addict, Levivich, Zoozaz1, Venicescapes, ToBeFree, Waddie96, ONUnicorn, Kusma, Dennis Brown, CaptainEek, 제이슨 퀸, Nsk92, 스노우 라이즈, 뮤지크 애니멀, 하트 킹, 브레츠컬, 늑장 Reader, 필 브리저, 아사르테아, (그리고 설명하기 어려운 누군가 "Notme" Ethers, 나르키 블러트 (대화) 12:06, 2021년 6월 26일 (UTC)[]

조사(TFA PC)

  • 보호된 페이지를 간단히 살펴보면 다음과 같다.
    1. TFA의 날에 상당한 활동 증가
    2. 이미 반보호가 되어 있지 않은 페이지의 많은 활동은 공공 기물 파손이나 다른 형태의 비파괴적 편집이었다(여기저기 좋은 편집이 몇 개 있었지만 규칙이 아닌 예외였다).
    3. 그 페이지들에 비 AC들에 의한 대부분의 편집은 VOA나, 어쨌든 다른 것을 파괴했을 것이다.
    4. 문제가 있는 편집 내용이 신속하게 복구됨
    5. LTA의 징후가 나타나지 않아
  • 나 역시 철저했고, 재판이 만료된 후 처음 몇 개의 TFA를 점검했다. 이러한 기사의 편집의 성격은 PC로 보호되는 TFA(서포트 포인트 3번)와 대체로 유사하며, 포인트 4번도 이와 유사하다. 요컨대 5번 포인트에 관한 한 재판은 성공적이었지만(이에 관한 조치가 얼마나 효과적이었는지는 판단하기 어렵지만) TFA에 대한 반달리즘을 방지하는 데는 다른 방법으로는 효과적이지 않았다고 생각한다-우리가 TFA에서 시간을 낭비하고 빨리 잡혀서 차단되기를 원하는지, 아니면 오히려 더 빨리 차단되기를 원하는지. 우리는 그들이 다른 곳(그들의 공공 기물 파손 행위가 덜 보이는 곳, 그리고 아무도 AIV를 확인하지 않을 경우 집행에 더 많은 시간이 걸릴 수 있는 곳)을 돌아다니는 것도 또 다른 의문이다. PC는 포인트 2부터 포인트 4까지 눈에 띄는 영향이 없었기 때문에, 개인적으로 가까운 장래에 TFA를 반보호하는 것을 지지할 것이다(이것은 레고크tm이 운영하는 기존의 TFA 프로텍터 봇과 결합될 수 있다). 랜덤캐나디언 (대화/기여) 13:29, 2021년 6월 26일 (UTC)[]
    참고로 나는 PC로만 보호되는 것에 근본적인 문제가 없으므로 PC도 지원하지만 세미(semi)가 더 효과적일 것이라고 생각한다. 랜덤캐나디언 (대화/기여) 23:38, 2021년 6월 26일 (UTC)[]
  • 나는 TFA의 영구적인 PC 보호를 전적으로 지지한다; 나는 여기서 내 시간 내내 그것을 클릭할 때 파손된 TFA 레드를 반복적으로 보아왔다. 나는 또한 대부분의 비자율적인 확증된 편집은 파괴적인 편집이거나 비파괴적인 편집이라고 보았다. 내가 TFA에서 되돌아오는 현상은 그들이 부수적인 피해를 더 많이 입기 쉽다는 것이다; 때때로 반달에 의해 한 번 이상 편집이 이루어졌고, 나는 사람들( 심지어 ConverseBot)이 우연히 편집 중 하나만 취소하여 수정을 강요하는 것을 본 적이 있다. 나는 어떤 사람들이 위키피디아를 편집할 수 있어야 하고 TFA에는 보호장치가 설치되지 않아야 한다고 말하는 것을 잘 이해하지 못한다. 만약 그렇다면, 왜 모든 페이지에서 모든 보호를 제거하지 않는가? 그들이 좋아하는 기사를 편집할 수 있어야 하지 않을까? 왜 TFA는 반달의 희생양이 되어야 하는가? 그들은 거의 눈에 띄지 않는 극소수의 수정만이 필요할 정도로 업그레이드되었다. Sidenote: RandomCanadian I는 반보호보다 PC 보호를 지지한다. 왜냐하면 빠르게 교정될 수 있는 실수를 발견하는 사람들이 있을 수 있기 때문이다. 또한, 그것이 PC로 보호되고 있다는 사실은 아마도 그들이 파괴할 수 있다는 착각으로 그들을 보호되지 않는 사이트로부터 멀어지게 할 것이다. Wretchskull (대화) 14:36, 2021년 6월 26일 (UTC)[]
    • FA는 특히 더 많은 기술적 과목에 대해 여전히 근본적인 실수를 할 수 있다. 그 과정은 몇몇 특정한 위키피디아에 대해 매우 철저하지만, FA의 대부분의 리뷰어들은 주제 전문가가 아니라는 것을 기억하라.Bilorv (대화) 17:34, 2021년 6월 26일 (UTC)[]
  • 자동 PC 보호 지원 재판을 허가한 토론에서 말했듯이, 보류 중인 변경의 효용성은 관리자와 편집자의 업무량을 줄이는 것이 아니라(효과적으로 더 많은 작업을 창출한다), 오히려 공공 기물 파손이 독자에게 보이지 않도록 하여 잠재적으로 프로젝트를 도입하는 것이 목표라는 점에서 반보호와는 다르다.오 평판이 나쁜 일반적으로, TFA는 메인 페이지에 있는 동안 상당한 시청률 상승을 받는 경우가 많다. 예를 들어, 어제의 무명 식물인 그레빌라 주니페리나에 관한 TFA는 1분당12개의 뷰를 기록한 18,112개의 뷰를 기록했다. 따라서, 반달리즘이 TFA에 남을 수 있는 매 60초마다, 위키피디아에서 우리의 가장 좋은 콘텐츠의 쇼케이스로 여겨지는 것에 대한 수정을 보는 잠재적으로 적어도 12명의 독자들은 반달리즘이 일관성 있게 즉시 되돌아가지 않고 있다는 것을 보여준다. 오늘 특집 기사인 쇼조 비트에서는 [1]이 7분 동안 되돌리지 않았다(경고: 포르노에 대한 링크를 포함하고 있다). 재판은 성공적으로 보류 중인 변경사항 보호 기능을 켜는 것이 PC 백로그(어쨌든 24시간 동안만 켜짐)에 견딜 수 없는 부담을 주지 않았으며, 이 작은 비용은 예비/불경험 편집자들이 변경사항을 제안할 수 있도록 허용하면서 당사의 특집 콘텐츠의 세련된 품질을 유지하는 이점이 있다. Mz7 (대화) 16:22, 2021년 6월 26일 (UTC)[]
    공식적으로, 나는 반보호에 반대한다. 나는 PC로 충분하다고 생각한다. 아래의 몇몇 편집자들은 TFA에 대해 보류 중인 변경 보호와 함께 모호하거나 가상적인 문제를 표현했지만, 아무도 시험 기간 동안 그러한 문제에 대한 구체적인 증거를 지적하지 않았다. 변경 보류 보호는 일반적으로 편집률이 높은 기사에 적합하지 않은 것이 사실인데, 그렇게 광범위하게 하는 것은 보류 중인 변경의 백로그를 부풀릴 수 있기 때문이다. 그러나 하루에 한 기사에만 게재되는 경우에는 상황을 완전히 관리할 수 있다. 위에서 말했듯이, TFA는 적어도 5초마다 한 번씩 보는 경우가 많은데, 이 기록은 TFA의 공공 기물 파손 행위가 종종 그것보다 훨씬 더 많은, 심지어 몇 분까지 더 자주 일어난다는 것을 보여준다. 미결된 변경의 효용성은 우리가 기물 파손을 "최종 작업"으로 제시하는 당혹감을 피할 수 있다는 것이다. 내가 이해할 수 있는 한 가지 반대는 현재 진행 중인 변경 도구에 영향을 미치는 기술적 문제와 관련이 있다. 즉, 재판을 승인한 원래의 RfC에서, 나도 그 근거로 이 전체 아이디어에 대해 회의감을 표시했지만, 현재 상태로는 그 도구는 우리가 조심스럽게 진행할 수 있을 만큼 충분히 잘 작동하고 있는 것 같다. Mz7 (대화) 17:13, 2021년 6월 27일 (UTC)[]
    다음에 또 언제 어떤 일이 일어날지 아무도 모른다. 지난 한 해 동안 6개의 무작위 임계 곤충이 있었고, 그 중 절반은 '운에 의해' IIRC로 고정되었다. 즉, 개발자들은 무엇이 잘못되었는지 알아내지 못하거나 때로는 상황이 다시 작동하기 시작하는 것처럼 보였다. 아무도 코드베이스에 손을 대려 하지 않고, 코드베이스에 대해 잘 아는 사람도 거의 없다. 만약 그것이 잘못되면, 우리는 대부분 혼자일 수 있다. 나는 개인적으로 우리가 버기 기술의 확산을 부추겨서는 안 된다고 생각한다; 우리는 대기 중인 변경사항의 적용을 취소하거나 사용을 제한할 필요가 있다. 그 반대는 아니다. RodelingReader (대화) 22:46, 2021년 6월 27일 (UTC)[]
  • 마지막 토의당 지원. ~ HAL333 16:28, 2021년 6월 26일(UTC)[]
  • 자동 PC 보호에 반대하며, 대안으로 메인 페이지에 있는 동안 자동 반제어를 지원하십시오. TFA의 편집률이 너무 높아서 보류 중인 변경 시스템이 유용하지 않다. 이반벡터 (/)TalkEdits 16:43, 2021년 6월 26일 (UTC)[]
  • RandomCanadian의 매우 철저한 평가당 강력한 지원. 나는 이 점에 특히 관심이 있다. 많은 TFA 반달들이 단지 엉망으로 만들 페이지를 찾고 있고 만약 TFA가 반쪽이었다면 그 대신에 다른 것을 할 것이다. 불행히도 이것이 사실인지 아닌지는 제대로 평가하기 매우 어렵지만, 나에게는 그럴듯하다. 나는 PCP를 좋아한다. 왜냐하면 TFA를 편집 가능한 상태로 유지하는 것은 사람들이 우리가 누구나 편집할 수 있는 백과사전이라는 것을 발견하도록 돕는 데 특히 도움이 되기 때문이다. 물론, 대부분의 편집이 상황을 악화시키겠지만, 그게 중요한 것은 아니에요. 많은 귀중한 편집자들의 첫 편집이 기사를 더 나쁘게 만들었다. 우리는 시험 편집과 도움이 되지 않는 선의 편집 (그리고 심지어 일부 파괴적인 편집도)을 이미 감소하고 있는 새로운 기고자들의 흐름을 끊는 것을 멈추기 위해 투자할 가치가 있는 비용으로 볼 필요가 있다. 나는 반보호에 반대할 것이다. TFA 페이지에서는 적어도 일부 편집자(그리고 일반적으로는 포괄적인 주제 지식을 가진 편집자)가 보고 있을 것이다.Bilorv (대화) 17:34, 2021년 6월 26일 (UTC)[]
    나는 TFA가 실제로 새로운 편집자를 모집하는지 모르겠다. 그들은 철저하고 까다로운 검토 과정을 거쳤다. 그들은 확실히 개선될 수 있지만, 신입 (또는 심지어 적극적인 편집자)은 다른 기사에 비해 개선될 가능성이 더 낮다. 대체로, 얼마나 많은 편집자들이 실제로 TFA를 편집하면서 편집 경력을 시작했는지 잘 모르겠다. RusingReader (대화) 20:10, 2021년 6월 26일 (UTC)[]
  • 마지막 토론에서 "내 첫 번째 관심사는 독자, 그 다음 편집자"라는 내 코멘트를 통해 일시적인 완전 보호(최대 2-7일)를 지원하라. PC는 여전히 좋지 않은 생각이다. 나는 또한 당신이 "어쨌든 누가 다른 것을 파괴했을지도 모른다"라고 말할 때 당신이 잘못 생각하고 있다는 것을 지적하고 싶다. 이와 같은 공공 기물 파괴 행위는 기회주의적인 절도 행위와 유사하며, 이는 목표물이 덜 눈에 띄었을 때, 즉 기회가 적을 때 감소한다. 제1면에는 방앗간 기물 파손의 운영과는 다른 것을 파괴하는 데 뚜렷한 매력이 있어, 다른 곳에서도, 절대적으로 같은 일을 했을 것이라고 말하는 것은 정확하지 않다. 어쨌든 어떤 것을 파괴하는 편집자의 경우, 대부분의 경우, 눈에 잘 띄지 않으면서도 손상이 빨리 복구된다. Dennis Brown - 2x17:40, 2021년 6월 26일 (UTC)[]
  • 강력한 지원 - 만약 그것이 특징이라면, 그것은 이미 힘든 과정을 거쳤으며 CE나 다른 어떤 것이 2주나 기다릴 수 없는 것이 필요할 가능성은 거의 없다. Atsme💬 17:50, 2021년 6월 26일 (UTC)[]
    수년 전에 TFA가 꽤 많이 홍보되었으므로, 「CE가 필요할 가능성이 매우 낮다」에 대해서는 {{cn}} —쿠스마(토크) 18:15, 2021년 6월 26일 (UTC)[]
    나는 메인페이지의 비GA DYKs처럼 확실히 더 낮은 곳에 있는 과일이 있다고 생각한다. 내가 할 일을 찾을 때, 나는 DYKs를 통해 일하며 TFA에 별로 신경 쓰지 않는다는 것을 알고 있다. 스드라카즈 (대화) 20:35, 2021년 6월 26일 (UTC)[]
  • 보류 중인 변경은 열렬히 싫어하지만, 자유롭게 편집할 수 있는 다른 장소는 충분하다. PC 대신 세미(semi)로 두 번째 재판을 보고 싶지만 TFA를 보호하기 위해 뭔가 해야 한다는 일반적인 생각은 지지하지만 편집은 조금 열어두고 있다.쿠스마 (대화) 18:15, 2021년 6월 26일 (UTC)[]
  • 든든한 지지. 오랜만이네. TFA는 보류 중인 변화 보호가 빛을 발하는 대표적인 사례다. 기사 가시성이 너무 높기 때문에 편집률이 높은 것은 문제가 되지 않는다. 그래도 오늘 특집기사를 몇 번이나 확인했는데 그게 어떤 깨지거나 파손된 상태였는지는 셀 수 없다. 등록한 사용자로서 나는 이것이 바뀌지 않을 것이라는 것을 알지만, 난센스가 대다수의 독자들로부터 숨겨져 있다는 것을 알게 되어 훨씬 기분이 좋아질 것이다. 한편 선의의 편집자들은 여전히 기여할 수 있고, 우리의 가장 눈에 띄는 기사는 여전히 "누구나 편집할 수 있다"는 철학을 따르고 있다. 누이 좋고 매부 좋은 거 아냐. 뮤지크애니멀 18:21, 2021년 6월 26일 (UTC)[]
  • 지원 우리의 첫 번째 관심사는 독자들이어야 한다는 것에 동의한다. 그 기간 동안 TFA에 대한 나의 경험은 보류 중인 변경 보호의 가치를 확인시켜 주었다. 미결된 변화들이 제안된 좋은 편집들을 멈추지는 않지만, 그것은 공공 기물 파손을 막았다. Hawkeye7(토론) 18:59, 2021년 6월 26일 (UTC)[]
    나는 사실 우리 독자들이 가끔 공공 기물 파손 행위를 보는 것이 건강에 좋다고 생각한다. 위키피디아에서 읽은 모든 것을 믿지 않는 것은 좋은 기억으로 작용한다.쿠스마 (대화) 19:02, 2021년 6월 26일 (UTC)[]
    롤! 나키 블러트 (토크) 20:57, 2021년 6월 26일 (UTC)[]
  • 이전 논의에 따른 지원, 그리고 랜덤캐나디안의 주장에 의해 강화. 와디96 (토크) 19:08, 2021년 6월 26일 (UTC)[]
  • MusicAmonal을 지지하십시오. 내가 선제적 보호에 의심을 품고 있지만, 이것은 우리 독자들에게 정당한 문제를 해결하기 위한 실행 가능한 타협이므로 나는 지지해도 좋다. 솔직히 이 재판이 진행되는지도 몰랐기 때문에 분명히 문제가 되지 않았다. 그런 이유로 나는 PC 보호에 내재된 무언가가 중대한 문제를 일으킬 것이라는 생각에 별로 신경을 쓰지 않는다. Wug·a·po·des 19:09, 2021년 6월 26일 (UTC)[]
나는 여전히 보호 정책에 따른 선제적인 반보호에 반대한다. 그 정책은 아주 명확하다. 페이지 보호를 선제적 조치로 적용하는 것은 위키피디아의 개방적 성격에 반하며, 이러한 이유로 적용하면 일반적으로 허용되지 않는다. 나는 특히 자동 보호와 같은 인간의 판단이 개입되지 않는 선제적 보호에 대한 강한 반대 입장을 견지한다. 나는 그것에 대해 타협하고 재판 결과와 보호 정책에 근거하여 보류 중인 변경 보호를 선제적으로 적용할 용의가 있다: 보호 수준은 생산적인 편집자가 여전히 변화를 할 수 있도록 허용하면서 혼란을 막기 위해 필요한 가장 낮은 제한으로 설정되어야 한다. 보류 중인 변경 보호와 비교할 때, 선제적 반제약은 우리의 기본적 가치에 어긋날 뿐만 아니라 예상되는 혼란을 막기 위해 필요 이상으로 극단적이다. 만약 우리가 NOPREEMET에 대한 예외를 만들려고 한다면, 그 정책은 우리가 효과적인 가장 낮은 보호 수준을 선택해야 한다고 말하고 있고, 재판에서는 그 수준이 변경 보류 중임을 보여주고 있다. 그러한 이유로 나는 선제적인 반방호뿐 아니라 반방제 시행에 반대한다. 반방제 시행은 새로운 반방제 및 IP 편집을 중지하는 것 외에 다른 어떤 것도 보여주지 않을 것이다. 반보호를 선호하는 사람들은 보류 중인 변경사항보다 그것을 선호하기 위한 정책이나 근거 있는 이유를 제시하지 않았다. 지금까지 선제적인 반신반의로 제시된 주장들은 일화, 두려움, 그리고 나쁜 신앙에 대한 가정에 근거하고 있는데, 이 모든 것들이 우리의 정책을 감안할 때 납득할 수 없는 것이다. Wug·a·po·des 23:56, 2021년 6월 29일 (UTC)[]
정중하게, 나는 우리가 시험 기간 동안 견실한 방식으로 리뷰어로서 적극적으로 일하지 않았다면 우리 중 어느 누구도 가장 가능성이 높은 PC 문제를 눈치채지 못했을 것이라고 확신하지 못하는데, 이것이 내가 최근 몇 달 동안 이 프로젝트에 그렇게 결석하지 않았더라면 좋았을 것과 그 영향이 무엇이었는지를 더 잘 파악할 수 있는 이유의 일부다. 한편, 아마도 당신은 당신이 그 지역에서 일해왔고 상당한 영향을 주지 않았다고 말할 작정이었는지도 모른다. 그러나 더 나아가서(그리고 또 존경심을 가지고) 나는 그러한 주장은 (경험적이거나 이성적인 조치로서) 이 변화의 전체적인 비용-효익 가치에 대해 아주 설득력 있는 것이 아니라는 것을 제출하고자 한다. 왜냐하면, 관찰은 양방향으로 줄어들기 때문이다: 재판이 실행되고 있다는 것을 깨닫지 못했다면, 동등한 척도에서 어떤 이익도 알아차리지 못했기 때문이다.o 어떤 문제에도 주목하지 않는 것. 결국, 증거의 부재는 우리가 추측할 수 있는 이익이나 결점에 대한 부재 증거가 되지 않는다. 이것이 내가 이 토론이 첫 번째 토론과 마찬가지로 빠른 결과를 향한 힘을 키우는 것에 대해 약간 우려하는 이유다. 나는 정말로 관련 지역에서 참호에 있었던 사람들로부터 더 많은 이야기를 듣고 싶다. 또는 우리가 이 변화를 목적에 맞는 것으로서 고무하기 전에, 혹은 다른 면에서는 아무리 미묘하더라도, 어떤 면에서는, 주목한 효과에 대해 더 많이 듣고 싶다./전체에서 부정적인 부작용보다 더 많은 가치를 반환한다. 01:16, 2021년 6월 27일 (UTC)[]
  • 지지가 합리적인 균형을 이루는 것 같다. XOR'easter (대화) 19:31, 2021년 6월 26일 (UTC)[]
    • 나는 일반적으로 보류 중인 변경사항보다는 반제어로 할 것이다. 후자는 항상 나를 "허? 이게 언제 이로운가?"라고 생각했다."특징의 일종이다. 그것의 작동도 더 복잡하고 설명하기도 어렵다. 나는 페이지 기록을 방해하지 않고 감독 두통으로 이어지지 않는 행동 과정을 선호한다. XOR'easter (대화) 02:18, 2021년 6월 27일 (UTC)[]
    • 나는 TFA가 실제로 새로운 편집자를 영입하는 역할을 한다는 것이 납득할 수 없을 것 같다. 만약 독자가 어떤 주제에 대해 관심을 가지고 그것에 대해 쓰고 싶은 열정을 가지고 있다면, 그들은 아마도 그것에 대한 위키피디아 기사를 이미 발견했을 것이다. TFA는 이미 기사의 주제를 전문으로 다루지 않은 사람들에게 지역사회의 일을 자랑한다. XOR'easter (대화) 20:28, 2021년 6월 27일 (UTC)[]
  • 우리가 수집한 30일 동안의 시험 데이터에 대한 더 깊은 분석을 보고 싶다. 확인되지 않은 사용자로부터 건설적인 편집이 있었는가? 만약 그렇다면, 몇 퍼센트인가? 나는 미해결된 변화를 별로 좋아하지 않는다. 기술적으로는 기능성이 거의 기능하지 못하고 있다(개발자가 버그를 찾지 못해 핫픽스로 작동하도록 말 그대로 봇을 승인해야 했다). 개발 측면에서는 사실상 포기된 것이다. 게다가, 그것이 하는 모든 것은 파괴 행위를 생방송으로 보여주는 것을 막는 것이다. 그것은 페이지 역사가 쓰레기로 꽉 막히는 것을 막지 못한다. 편집한 내용이 전부 또는 대부분 비파괴적이라면 반제(반제)로 가십시오(그러지 않는 유일한 이유는 이념적인 것일 뿐이며, 나는 실용주의를 선호한다). RowlingReader (대화) 20:04, 2021년 6월 26일 (UTC)[]
    반제어를 지원하고 보류 중인 변경에 반대한다. 전자는 그 증거가 거의 모든 그러한 편집이 비파괴적이어서 메인페이지의 기사에 공공기물 파손을 초래하지만, 더 중요한 것은 어느 기간 동안 사실적으로 정확한 정보를 이용자들을 도출한다는 것이다. a) 기능이 손상되었기 때문에 보류 중인 변경에 반대한다(Wipedia:Bots/Requests for Approval/FireflyBot II) 및 WMF에 의해 유지되지 않은 장기(페이지:T185664); b) 위의 이유(및 일부 다른 이유). WP:보호정책(WP:PCPP)에 따르면, 앞서 언급한 기준을 충족하더라도 편집률이 매우 높은 기사에는 보류 중인 변경 보호를 사용해서는 안 된다. 그 대신 반보호가 고려되어야 한다. (TFA가 어떤 것인가) -- 그럴만한 이유가 있는데, PC 사용자 인터페이스는 요청 편집보다 열등하고, 빠른 속도로 편집 속도가 엉망진창이 된다. RodelingReader (대화) 22:34, 2021년 6월 27일 (UTC)[]
    semi에 대한 두드러진 지지; 이제 그것에 대해 중립적인 입장을 취하고 있으며, 최근의 설득력 있는 논평에 따르면, 그 중 많은 수가 아래의 IP로부터 왔다. PC는 적합하지 않기 때문에 여전히 반대한다. RusingReader (대화) 23:52, 2021년 7월 24일 (UTC)[]
  • 메인 페이지 표시 기간 동안 PC 또는 세미프로텍트를 지원하십시오. 위에서 언급했듯이, 차단된 편집의 대부분은 건설적이지 않았고 우리는 백과사전의 명성을 손상시키기 때문에 높은 가시성 페이지가 훼손되는 것을 피해야 한다. (t · c) 20:27, 2021년 6월 26일 (UTC)[]
  • 보류 중인 변경사항의 사용에 대한 강한 반대는 이 역할에서 보호를 사용하지만, 대신 반보호 기능을 사용하는 데 대한 다소 미온적인 수준의 지원. 이 주제에 관한 원래의 RfC와 마찬가지로 나는 이미 어느 방향으로 바람이 불고 있는지 분명한 지점에 도달하고 있다고 생각하지만, 이것이 실체적인 것이 될 것이라는 인상을 흔들 수 없기 때문에 (그런 상황에서 늘 하는 것은 아니지만) 새롭게 떠오르는 합의점에 나의 의견차를 등록하는 데 시간을 할애할 생각이다.다단계에서 일리노이드가 잘못 움직인다. 나는 스스로 보류 중인 변경 검토자로 최근 몇 년 동안 이 프로세스에 대해 상당히 많은 시간을 기록했으며, 특히 여러 개의 변경사항이 있는 경우, 도구의 승인 측면과 함께 작업할 필요가 없는 대부분의 편집자들이 그러한 감시의 적용이 얼마나 복잡해지는지 완전히 이해하지 못한다고 어느 정도 자신 있게 말할 수 있을 것 같다.iple 보류 중인 편집이 서로 바로 위에 오며, 자동 변경 사용자/비수정 편집으로 대체된다. 그것이 바로 우리가 (약간/절대적인 문제로서) 여기에 대비할 수 있는 상황인 것이다. 이러한 추가 요구(상충되는 편집 문제를 해결하기 위한 권한/수동 편집의 복잡한 사용)는 검토자들에게 상당한 양의 불필요한 바쁜 작업을 야기할 것이며, 이미 작업으로 인해 밀린 작업으로 인해 상대적으로 적은 수의 자원봉사자들이 종종 허덕이는 분야인 것이다. 그리고 이것은 우리가 고려하기도 전에 말이다.e 자주 볼 수 없는 PC 기술 버그-그리고 모든 것은 의심스러운 이익을 위해, 특집 기사들은 이미 정기적인 편집자들에 의해 태양 아래에서 일상적으로 순찰되고, 대부분의 공공 기물 파괴 행위와 그 밖의 다른 문제적 편집이 신속하게 되돌아간다는 사실 때문에 기물 파괴 행위에 의해 상당히 효과적으로 보호되고 있다.
또한 편집자 모집과 보유에서 모두 길고 실질적인 하향 추세에 있는 시점에서, 전통적으로 신규 사용자들의 첫 번째 편집의 수단이 되어왔던 영역에서 접근을 방해하는 문제도 있다. 실제로, 이전 논의에서도 언급했듯이, 처음 사용자들이 커뮤니티의 초기 편집에 대한 풍부한 시각을 가진 문맥으로 흘러들어가는 상황을 가지는 것, 따라서 새로운 사용자들이 우리의 기본 정책과 절차에 필수적인 피드백, 참여, 그리고 교육 등을 받게 될 것이라는 확률을 향상시킨다(그리고 그들의 첫 번째, 거의 피할 수 없는 실수는 잡히고 장기간의 실책에서 빠르게 고정된 실수와 가르칠 수 있는 순간으로 변모) 대안이 주어진다면 나는 가능한 모든 세계 중에서 최고라고 생각한다.
그래서 이 제안에 대한 비용 편익 분석은, 내가 보기에, 완전히 틀렸다. 그렇기는 하지만, 보류 중인 변경에서 반보호로 접근 방식을 전환하면 최소한 개념의 복잡성이 약간 제거되고 PC 밀린 업무와 그것을 매일 조금씩 조금씩 훔쳐가는 자원봉사자들의 해로운 영향을 피할 수 있다. 그러나 나의 첫 번째 선택은 두 가지 모두를 피하고 대부분 자기 교정적인 전통적인 접근법에 의존하는 것이다. 그리고 최소한 나는 위와 같은 매우 적절한 주의에 있어서 DroadingReader에 동의한다. 적어도 나는 이 재판이 우리에게 제공한 어떤 통찰력(추상적이긴 하지만 인상적)에 대한 좀 더 완전한 탐색을 보고 싶었는데, 그 전에 나는 여기서의 현상으로부터의 변화를 지지하기 위해 움직일 수 있었다. 나는 여기서 특별히 누구의 코끝도 고치고 싶지도 않고, 그러나 두 토론에 대한 나의 인상은 여기서 행동하기 위해 서두르는 것이 오히려 있었고, 가능한 많고 실질적인 연쇄효과에 대한 고려가 너무 적었다는 것이다. 나는 아마도 이 제안이 전적으로 문제를 찾는 해결책은 아니라고 확신할 수 있지만, 나는 정말로 우리가 여기 있는 이슈들에 대해 좀 더 세밀한 구분이 필요하다고 생각한다. 대다수가 여기서 나를 설득할 필요는 없다. 공감대가 이것에 대한 나의 시각에서 확고히 벗어나고 있는 것 같다. 하지만 어쨌든, 그것은 나의 인상이다. 제설 00:42, 2021년 6월 27일 (UTC)[]
  • 반보호 지원 - 경험상 TFA가 일반적으로 그렇듯이 편집률이 높은 상황에서는 PC가 잘 작동하지 않는다. 그리고 내가 TFA로 작업한 기사의 두 가지 기사를 가지고 있는 FA 작가의 입장에서 보면, 일부 나쁜 편집은 잠시 서성거릴 수 있다. 이것은 4분 동안 지속되었고, 공공 기물 파손을 통해 인포박스를 제거한 편집은 12, 11 등이었다. 무보호 시스템은 때때로 괜찮은 시간 동안 가장 잘 보이는 페이지가 엉망이 되는 결과를 초래한다. PC가 실행 가능하다면 좋겠지만, 나는 TFA가 자주 받는 높은 편집률로 인해 자주 고장날까 봐 걱정이다. 호그팜 01:03, 2021년 6월 27일 (UTC)[]
  • 반보호지원하라, 이건 그냥 사람들한테만 하면 된다. 반 보호는 놀라운 일이다. 우리 모두 이것을 알고 있다. 내가 본 모든 TFA는 잔인하게 파괴되었다, 모든 TFA가. 그리고 어쨌든 그 기사가 반반으로 끝나게 되는 시간이 절반 이상인데, 왜 그들이 거의 하지도 않았는데 그 기사가 얼마나 오래 버틸 수 있는지에 대해 이렇게 어색한 경쟁이 된 것일까? TFA에 대한 IP/비등록 편집의 대부분은 파괴 행위다. 반, 최악은 최악이 되고, 그들은 큰 문제가 아니라 대화 페이지에 편집을 제안해야 한다. 그게 다라면 미결은 지지하겠지만, 우리 모두 그게 깨지고 지저분하다는 걸 알고 있어. 앞으로 나아가야 할 시간이야. Aza24 (토크) 01:28, 2021년 6월 27일 (UTC)[]
  • 나는 반독점을 강력히 지지하며 변경 보류에 중립적이다. 나는 대기 중인 변화를 모니터링하는 것이 엄청난 노동집약적 시간이라는 것을 알게 되었다. 캐스 리버 (토크 · 기여) 04:19, 2021년 6월 27일 (UTC)[]
  • 위의 모든 것에 대한 지원. 머리 안 세요. 러그넛 07:37, 2021년 6월 27일 (UTC)[]
  • 위의 항목에 따라 반보호, PC를 보조 선택으로 지원하십시오. MER-C 08:43, 2021년 6월 27일 (UTC)[]
  • 반보호 지원, 변경 보류 나는 초기 RfC에서 PC의 사용에 강하게 반대했는데, 이는 플래그 지정된 리브 확장의 기술적 문제 때문이다. 나는 여전히 그것을 '소유'하는 개발 팀이 없는 것처럼 보인다는 점에서, 높은 관심을 받는 페이지에 깃발을 꽂는 것을 사용하는 것이 여전히 불안하다. 내 "patch the holes" bot(사용자:FireflyBot II)는 최근에 많은 작업을 할 필요가 없었는데, 이것은 좋은 일이다. 그러나 나는 우리가 문제의 원인이 정확히 무엇인지를 아직 규명하지 못했다고 믿는다(자율적으로 확증된 편집자들의 편집이 그들이 필요할 때 자동으로 받아들여지지 않는다). 나는 우리가 가장 주목받는 기사들에 잠재적으로 버기 코드를 사용해서는 안 된다고 생각한다. 나는 우리가 여기서 이데올로기가 아니라 실용적이어야 한다는 DroadingReader의 의견에 동의한다. 반딧불 (t · c ) 09:04, 2021년 6월 27일 (UTC)[]
  • 지원 PC,2차 선택 PC가 가장 좋은 선택이지만, 없는 것보다 세미(semi)가 더 좋다. TFA의 모든 형태의 보호에 반대하십시오. 다시 생각해 보면, 우리는 사람들이 메인 페이지에 실린 기사를 편집할 수 있기를 원하며 공공 기물 파손은 관리 가능하다.Jackattack1597 (토크) 10:45, 2021년 6월 27일 (토크) Jackattack1597 (토크) 10:39, 2021년 7월 14일 (토크)[]
  • 보류 중인 변경에 강력히 반대한다. 내 위의 몇몇 논평자에 따르면, 그것이 TFA와 같이 눈에 잘 띄는 곳에서 순양성이라는 증거는 없으며, 실제로 순양성이라는 일부 증거는 없다. 어떤 이유로든 모든 종류의 자동보호를 반대한다. 우리는 사람들이 위키피디아를 편집하도록 장려하고 싶다. 그래서 우리는 가능한 한 참여의 장벽을 적게 세워야 한다. 그것은 위키피디아의 필요성이 입증된 곳에만 보호를 의미한다. Thryduulf (대화) 11:29, 2021년 6월 27일 (UTC)[]
  • 코멘트 나는 많은 사람들이 PC 보호가 교통량이 많은 기사에 "문제"를 일으킨다고 주장하는 것을 본다. 재판이 진행되던 5월에 이런 문제점을 눈치챈 사람이 있는가. 구체적인 예를 제시할 수 있는가? Anomie 11:55, 2021년 6월 27일 (UTC)[]
  • 반보호 기능이 있는 동안 지원, 보류 중인 변경사항 적용에 반대. 변경 보류는 복잡한 난장판이며 매우 활동적인 기사에서는 두 배로 복잡한 난장판이 될 것이다. TFA 기사에는 항상 여러 명의 보호자가 있으며, 반보호와 결합하면 충분하다. 북8000 (대화) 13:59, 2021년 6월 27일 (UTC)[]
나는 이것이 매우 좁은 경우라는 것을 강조하고 싶다. 한 번에 한두 기사에 대한 반보호가 1일 또는 1일 반밖에 되지 않는다. 북8000 (대화) 13:35, 2021년 6월 28일 (UTC)[]
  • 반보호 지원. IP/비자율 확증 편집자는 편집 요청을 사용할 수 있으며, TFA에 대한 미결 변경 보호(누구나 편집할 수 있음)라는 이상을 존경하지만, Firefly가 제기한 기술적 문제와 Hog Farmant에서 언급한 실질적인 문제 때문에 망설이고 있다. 클로버모스 (대화) 18:53, 2021년 6월 27일 (UTC)[]
  • 질문: TFA 보호가 발달리즘에 미치는 영향에 대한 연구를 본 페이지와 연계한 다른 페이지에서 한 사람이 있는가? 만약 기물 파손 행위가 TFA i 세미나를 했을 때 단순히 그곳으로 옮겨간다면, 그 이유는 PC를 선호하는 좋은 이유가 될 것이다. 93.172.254.2 (대화) 08:31, 2021년 6월 28일 (UTC)[]
    나는 어떤 연구도 보지 못했기 때문에 일반적인 일화적인 증거만을 제시할 수 있다: 상당히 빈번한 DYK 기고자로서 말하는 것은 지난 2년 동안 나의 DYK 기사에 대한 파괴 행위는 무시해도 될 정도였다.쿠스마 (대화) 08:39, 2021년 6월 28일 (UTC)[]
    그러나 Saskatchewan에서는 이 기사가 Template: 아래의 메인 페이지에 게재된 이후 파손되었을 뿐이다.뉴스에서, 그리고 사실 반보호를 받았다. 숭어템플 (대화) 13:21, 2021년 6월 28일 (UTC)[]
  • 나는 반보호(첫 번째 선택), 반보호(재판이 아닌 두 번째 선택), 보류 중인 변경(제3의 선택)에 대한번째 한 달 재판을 지지한다. 나는 그들 중 적어도 한 명에 대한 합의에 도달하기 위한 목적으로 세 사람 모두를 지지한다. KevinL (일명 L235 · t · c) 16:32, 2021년 6월 28일 (UTC)[]
  • PC를 1차로 선택함으로써 반제어를 지원하십시오. PC는 트래픽이 많은 기사에는 적합하지 않고 변경 사항을 검토하는 데 많은 시간을 소비한다. 나는 또한 대부분의 비자동 확증 사용자들이 FA를 그렇게 많이 편집할 수 있을지 의심스럽다. 오두막 8.5 17:25, 2021년 6월 28일 (UTC)[]
  • 어떤 종류의 보호를 지원하고, 어떤 종류의 특정한 선호도 없이. 진정한 개선의 반달리즘과 빈약한 편집의 비율은 내 생각에는 너무 낮으며, 개인적으로 나는 새로운 사람이 당신의 작품을 즉시 되돌릴 수 있도록 기사를 편집할 수 있는 것은 단순히 편집하는 것을 멈추는 것보다 사람들을 멀리 내몰 가능성이 훨씬 더 높다고 생각한다. 오늘의 특집기사를 살펴보면, 지금까지 발생한 10개의 IP 편집 중 1개는 즉시 되돌리고, 마지막 1개는 무의미하다(앞부분의 대체 이름을 위키링크로 바꾸었으므로, 같은 문장의 동일한 기사에 대한 2개의 링크가 있다). 192.76.8.91, 2021년 6월 29일(UTC)[]
  • PC 또는 반보호에 반대한다. 채용 도구로서의 TFA의 편집성의 유용성은 그것이 야기하는 평판 문제를 능가한다. --에어랜드 (토크) 22:15, 2021년 6월 29일 (UTC)[]
  • 미디어위키의 기술적 특징은 미디어위키에서 부서지고, 재단에 이를 지원하는 사람이 없으며, 자원봉사자들이 단순히 생생한 기사의 파괴 행위를 다루는 것보다 순찰하기가 더 어렵다는 점이다. 이 위키에 대한 기술적 특징으로 제거해야지, 자동으로 제거해서는 안 된다. 토니발리오니 (토크) 02:50, 2021년 6월 30일 (UTC)[]
  • 자동 보호(잠재적으로 이동할 수 없는 경우 제외)에 반대하십시오. 통계에 정통한 사람이 하루 TFA 페이지뷰와 그날 만들어진 계정 수를 이용해 TFA가 더 많은 계정을 만드는 경향이 있는지 가늠해 볼 수 있을지 궁금하다. 이것은 논리적이긴 하지만, 나는 자료가 없기 때문에 그것이 사실이라고 확실히 말할 수 없다. 그러나, 우리가 데이터를 가지고 있는 것은 TFA의 첫 번째(또는 그들의 첫 번째) 편집인 신규 계정의 수입니다. "오늘" 특집 기사(현재 총 3시간 정도만 올라갔으며, 오늘 UTC이기 때문에 인용 부호만 올라갔으며, 오늘 꼭 현지인이 아닌 것 같음)에는 이미 새로운 편집자가 한 명 있다. 즉, 시험 편집으로 보이는 편집한 후 사과하고, 즉시 특집 기사를 편집했다. 물론, 그들은 반드시 좋은 편집은 아니었지만, 그것은 지금 계정을 가지고 있고 그들이 관심을 가지고 있던 TFA가 없었다면 그러지 못했을 것이다. 이전 TFA는 선의의 앱에서 IP 편집을 하고, 계정을 만들었을 수 있는 합리적인 변화(알 수 없는 방법)와 첫 번째 편집을 하는 다른 하나의 새로운 계정을 가지고 있다. 평균적으로, TFA가 TFA에 포함된 첫 번째 편집자가 적어도 1-2개의 새로운 편집자가 되는 것을 보기 위해서는 다양한 주제만 살펴봐야 한다. 그것은 새로운 편집자들이 TFA를 편집할 수 있기 때문에 참여한다는 것을 증명하지는 않지만, 위키피디아에 가서 "X"를 찾아보고, 그들이 관심 있는 TFA "Y"를 메인 페이지에서 보고, 그것을 클릭하고, 그들이 만들고 싶은 변화를 알아차리고, 그리고 나서 그것을 만든다고 상상해 보라. 그것은 백과사전의 "누구나 편집할 수 있다"는 사고방식을 강화시켜주고, 그들이 계정을 만드는 가장 큰 원동력이 될 것이다. "야, 그래, 내가 실제로 이것을 편집할 수 있어!" 자동적으로 일을 하는 것은 훌륭하지만 무분별하게 하는 것은 좋지 않다. 나는 TFA가 보호되는 동안 파손될 가능성이 매우 높은 기사만을 대상으로 하는 표적 자동 보호(예: DS 또는 이와 유사한 주제에 근거할 수 있음)를 잠재적으로 지원할 수 있다. TFA는 일반적으로 파손되지 않는 TFA만 남겨두고 있다. 그리고 나는 그것이 "더 많은 일"이라는 것에 대한 논쟁은 믿지 않는다 - 내가 나의 의견을 준비하기 위해 TFA를 통해 진정한 반달리즘의 거의 모든 것(적어도 80%가 넘는 것)이 분 안에 ConverseBot이나 자동화된 도구를 사용하는 누군가에 의해, 그리고 보통 1분 내에, 거의 다시 되돌아간다는 것을 알아차렸다. 때로는 변화가 개선(또는 적어도 공공 기물 파손은 아니었지만), 그리고 그들은 여전히 사람들에 의해 뒤바뀌었다는 것은 말할 것도 없고 - 무슨 일이 일어나고 있는지 확실하지 않다. 그러므로, TFA의 문제는 반달리즘이 아니다. 즉, 0이 아닌 수의 새로운 편집자들이 TFA를 편집할 수 있기 때문에 시작한다는 명백한 사실을 이용하지 않고 있다는 것이다. 그리고 우리는 TFA를 편집하는 사람들이 유지될 수 있도록 그것을 개선하기 위해 노력해야 한다. 나는 약간 강조하지만, 새로운 사용자에 의한 TFA의 편집이 되돌릴 때 해결책은 더 효과적인 의사소통이다. 아마도 새롭고 부드러운 템플릿 메시지가 유용할 것이다. 또는 표준 템플릿 대신 사용자 정의 템플릿 메시지를 작성하는 것뿐이다. "솔루션"은 전혀 해결책이 아니다 - 그것은 편집자들이 시작하기도 전에 편집자들을 잃는 새로운 문제를 야기한다. 왜냐하면 그들에게 우리는 더 이상 "누구나 편집할 수 있는 백과사전"이 아니기 때문이다. 우리는 "몇몇 사람들이 편집할 수 있는 백과사전"이 될 것이다. 왜냐하면 그들은 보호가 어떻게 작동하는지 모를 것이고, 그들은 그것에 대해 읽을 것이기 때문이다. 그들은 단지 "나는 이것을 편집할 수 없다."를 볼 것이다. -bɜ:bk:nhɪmez (사용자/say hi!) 03:09, 2021년 6월 30일 (UTC)[]
    • 아, 하지만 문제는 IP가 나쁘다고 가정하고 그것에 근거해서 직설적인 판단을 하는 대신에 기사 이력을 실제로 보고 있다는 겁니다. TFA를 넘어서도, 내 사용자 페이지의 섹션에는 현재 내가 보호하지 않은 10년 이상 동안 반보호된 기사들과 그 결과들이 나열되어 있다. 거의 모든 경우에 있어서, 붕괴는 존재하지 않는 것으로는 미미했다. 플라워를 예로 들어보자. 하루에 약 2k의 뷰를 볼 수 있다. 마지막 보호가 만료된 후 27일 동안 신규 또는 미등록 사용자가 9번 수정했다. 그 중 두 가지는 IP가 시험 편집을 하는 것에 의한 즉각적인 자가검증이었다. 나머지 편집 5개 중 3개는 1분 안에 되돌렸다. 마지막 두 가지는 사실 흥미롭다. IP는 글의 시작 부분에 비파괴적인 텍스트를 추가하면, 몇 분 후에 두 편집이 모두 되돌아가기 전에 새로운 계정이 생성된다. 두 리비전은 IPs 편집 후 15분 후에 되돌렸다. 그래서 그 기사가 보호받지 못한 후 약 38,800분 동안, 비파괴적인 글은 독자들에게 거의 18분 또는 약 0.05% 동안 보여졌다. 단순성을 위해, 매일 2k씩 읽는 독자들이 38k 분에 걸쳐 대략적으로 균등하게 분포되어 있다고 가정해 봅시다. 이것은 우리가 지난 달 5만 4천 명의 독자들 중에서 약 25명의 독자들에게 반달리즘을 목격했다고 추정할 수 있다는 것을 의미한다. 한편, 우리는 네 명의 사람들이 편집에 도전하도록 했다!
      TFA와 더 비슷한 또 다른 예는 내가 5월 22일 보호하지 않은 파블로 피카소다. 그 당시 하루 평균 약 6.7k의 조회수를 기록했고 이틀 동안 매일 10k 이상의 조회수를 기록했다. 이 39일 동안 신규 사용자나 미등록 사용자의 편집은 10건이었다. 그 10개의 편집 중 8개는 되돌렸다. 하나는 선한 믿음이었지만 비협조적이었다.하나는 날짜 형식의 변경이었다. 세 번째는 IP가 ref 태그를 사용하는 방법을 모르기 때문에 되돌린 콘텐츠의 추가(소싱됨!)였다(진지하게, 되돌리기 편집 요약). 그것은 우리에게 분명히 선의에 있지 않은 5개의 번복된 편집본을 남겨준다. 이 5개 중 2개는 '룸브로드봇'에 의해 바로 되돌아갔고, 나머지 3개는 2분 만에 되돌아갔다. 파블로 피카소 기사가 무방비로 보도된 5만6000분 중 기껏해야 6분, 즉 약 0.01%의 시간 동안 반달리즘이 눈에 띄었다. 지난 번과 같은 가정, 즉 261,000명의 관객의 수단에 의한 반달리즘은 약 28명의 사람들에 의해 목격되었다.
      물론, 다른 예와 반대가 있지만, 눈에 보이는 페이지의 단백질이 없는 것은 위키피디아의 기본적인 가정을 뒷받침한다: 사람들은 파괴적이기보다는 건설적이다. 연간 수백만 개의 페이지뷰를 가진 기사도 혼란을 최소화할 뿐만 아니라 신규 편집자와 미등록 편집자에 의한 건설적이고 선의의 편집이 여러 번 이루어진다. 우리가 혼란을 겪고 있는 곳에서도 오랫동안 보이지 않고 그 영향도 미미하다. 이제 TFA로 돌아갑시다.
      All About That Bass(ft. 6월 30일)는 13시간 후에 보호되기 전에 9명의 고유한 신규 또는 미등록 사용자로부터 편집을 보았다. 9명의 편집자 중 3명은 건설적이고 변태적이지 않았다. 남은 6개 중 1개는 15분 8번의 편집 끝에 차단된 계정이었다. 나머지 5명 중 2명은 선의였지만, 불필요한 변화로 되돌아갔다. 마지막 세 가지는 공공 기물 파손이었다. 그 반달리즘 편집 중 2개는 2분 이내에 되돌아갔으며, 3번째는 반달리즘이 독자들에게 보이지 않는 이타적인 텍스트 반달리즘이었다. 보호받고 차단된 기물을 포함했음에도 불구하고, 보호받지 못한 794분 중 약 13분 동안 독자들에게 혼란이 보였다. 전염병이라고 주장하는 사람들은 거의 없다. 베를린에서 키치너로 이름 변경(ft. 6월 29일)은 결코 보호되지 않았고 6개의 서로 다른 미등록 편집자들로부터 편집된 것을 보았다. 그들 중 두 명은 결국 봉쇄되었다. 나머지 4명 중 1명은 너무 상세한 짧은 설명을 적어 되돌아갔다. 또 다른 (아직도 되돌리지 않은) 인용문으로 일부 외부 링크를 고정시켰다. 또 다른 (아직도 변덕스럽지 않은)은 베를린온타리오의 선두에 위키 링크를 추가했다. 마지막은 당시 비어 있던 인포박스의 "이미지" 파라미터에 이상한 기호를 추가했다. 누군가가 알아차리기 전까지 16분 동안 서있었는데, 다른 모든 반달리즘은 1분 안에 되돌아갔다. 필립 데이비(ft. 6월 28일)는 7시간, 6개의 구별되는 IP를 보호받았지만 모두 같은 서브넷에 있었다. 보호 대신 범위 블록으로 쉽게 처리할 수 있었다(188.162.254.128/25 참조). CM 펑크(ft. 6월 27일)는 이미 무기한 보호를 받고 있었다. 쇼조 비트 (ft. 26 ft. 6월 26일)는 결코 보호받지 못했고 신규 및 미등록 편집자들로부터 6개의 편집을 보았다. 하나는 공공 기물을 파괴하려는 선의의 시도였지만 편집상의 충돌로 인해 단락이 깨졌다. 또 다른 것은 실제로 공공 기물 파손 행위를 되돌렸다. 또 하나는 위키 링크를 추가하는 것이었다. 나머지 3개는 공공 기물 파손 행위였다. 하나는 이미지 파괴를 시도하는 것 같았는데(편집 필터가 있는 줄 알았는데) 수정본이 삭제되어 로드하는 데 어려움을 겪고 있다. 또 하나는 단서봇에 의해 바로 풀렸고, 마지막은 5분 후에 IP에 의해 풀렸다. 기사가 실린 1440분 가운데 기물 파손이 12분 동안 눈에 띄었다. 그레빌라 주니페리나(ft. 6월 25일)는 결코 보호받지 못했고 9명의 뚜렷한 신규 또는 미등록 편집자를 보았다. 그들 중 세 명은 건설적이고 정말 흥미로운 방법이었다. 두 명의 IP가 함께 협력하여 기사의 성능을 향상시켰다. 다른 편집자는 그날 막 등록했고, 리드에 링크를 추가함으로써 도움을 주었다. 여섯 명의 비파괴적 편집자 중 한 명은 선의로 보이지만 하이픈과 알트 텍스트를 오해한 것처럼 보인다.하나는 시험 편집인같지만 선의일 수도 있다(나는 식물에 대해 잘 모른다. 세번째는 파일명을 라틴어에서 영어로 바꾸었는데, 아마도 그것이 이미지를 깨뜨릴 것이라는 것을 깨닫지 못했을 것이다. 나머지는 꽤 전형적인 반달리즘으로 금방 되돌아갔다.
      나는 이미 몇 시간 동안 TFA 페이지 기록을 살펴봤고, 독자들이 보호되지 않은 페이지와 어떻게 상호작용하는지를 살펴보기 전에 더 많은 시간을 보냈다. 반보호가 불가피하다는 주장은 거짓이다. 많은 TFA들이 보호를 받지 못하는데, 한 경우에는 페이지를 보호하지 말았어야 했다고 주장할 수 있다(그러나 그것은 아마도 범위 블록을 이해하지 못한 새로운 관리자였기 때문에 마음대로 사용할 수 있는 도구에 대한 적절한 대응이었다). TFA가 독특하게 대량 파괴 행위를 당한다는 생각은 과장된 것이다. 그들이 일반적인 반달리즘보다 더 많은 것을 얻지만, 그것은 여전히 작고 사람들이 그것을 과장하는 것보다 훨씬 낮은 비율이다. 5개 이상의 TFA에서 나는 하나의 개정판을 보았다. TFA는 작업이 필요하지 않다는 생각은 거짓이며, 다수의 신규 및 미등록 사용자들이 이러한 TFA를 개선했으며, 일부 편집은 며칠이 지난 지금도 계속되고 있다. 보류 중인 변화가 엄청난 밀린 업무로 이어질 것이라는 생각은 지지할 수 없다. 대부분의 편집은 검토 없이 PC 보호를 바로 통과하게 될 사람들, 극소수일 뿐 아니라 PC 검토자가 개입할 필요 없이 리턴에 의해 자동으로 승인될 사람들에 의해 수행된다. 내가 자동 반보호를 지지하는 사람들이 증거가 아니라 직관에 의존하고 있다고 말했을 때, 이것이 내 말이다. 실제로 시간을 들여 '역전' 태그가 부착된 IP 주소인지 확인하는 대신 편집된 내용을 살펴본다면, 공공 기물 파손에 대한 이런 두려움이 과장된 것을 알 수 있을 것이다. 나는 당신에게 IP 편집이 형식상의 오류로 인해 정규에 의해 요약적으로 역전되는, 유용하지만 불완전한 IP 편집의 예를 보여 주기도 했다. 수많은 신규 및 미등록 편집자들이 도움이 되고 TFA에 귀중한 기여를 한다. TFA와 정규 기사의 수 백 가지 수정 사항을 살펴본 결과 나는 많은 직감보다 사악한 IP에 대한 증거가 더 많이 필요하며, 실제 사실과 재판 결과를 감정에 유리하게 무시하는 것은 피곤하다. Wug·a·po·des 01:03, 2021년 7월 1일 (UTC)[]
      딱딱한 데이터 분석보다는 직관과 일화에 대한 많은 결정이 내려진다. 나는 RfC에 영향을 미치는 통계적 증거를 마지막으로 본 기억이 없다. 내가 위키피디아에서 본 최고의(그리고 아마도 유일한 좋은) 분석은 사용자다.엔터프라이즈y/AIV 분석, 하지만 그 데이터가 얼마나 많은 사람들의 마음을 바꿨는지 난 아직도 잘 모르겠어. 위키피디아에 관한 데이터를 생성하고 분석하는 데 시간을 들이는 ROI는 내가 느끼는 낮은 수준이며, 데이터에 기반한 논쟁은 일화보다 설득력 있는 일은 거의 없을 것이다. 나는 개인적으로 이런 이유로 이런 종류의 분석을 하기 위한 노력을 기울이지 않을 것이다. RusingReader (대화) 01:22, 2021년 7월 1일 (UTC)[]
      반대로 사용자:우가포드의 분석은 매우 유용하며 우리가 TFA를 보호하지 않는다면 우리가 파산할 위험이 거의 없다는 것을 나에게 확신시키는데 도움을 주었다. ROI가 충분한지 여부는 이 경우 Wugapodes에 달려 있다. JohnFromPinckney (대화/편집) 07:10, 2021년 7월 2일 (UTC)[]
      우가포드의 분석은 시간이 걸리고 확실히 일화보다 낫다고 확신하지만, 내가 "통계적 증거"를 언급할 때 나는 User와 같은 큰 표본 크기를 사용한다는 것을 의미했다.엔터프라이즈y/A정맥 분석. 아마도 데이터 과학 도구를 사용하는 것 같아, 손으로 하는 것은 너무 지루할 테니까. 우리는 이전 RfC의 30일 동안의 시험 데이터를 가지고 있으며 (대부분의 경우) 분석되지 않은 상태로 남아 있으며, TFA에 있는 기사에 대한 많은 과거 데이터(개정 이력)를 가지고 있다. 우리가 묻는 질문에 대한 명확한 답을 원한다면, 데이터는 존재하고 그것은 공공 수정 역사에 있다. 하지만 그 많은 사람들만이 그것을 분석할 수 있고, 나는 그것이 얼마나 많은 차이를 만들지는 예측할 수 없어 보이기 때문에, 데이터가 문제를 제시한다면, 사람들은 '사전 보호/누구나 편집할 수 있다'는 철학을 버릴까? 마찬가지로, 그 데이터가 최소한의 이슈만 제시한다면, 편집자들은 그 사실을 잊게 될 것이다. 그들의 일화? RusingReader (대화) 13:37, 2021년 7월 2일 (UTC)[]
  • 위의 다른 모든 사람당 1차 선택, PC에서 먼 2차 선택 지원(아직도 편집기 시간이 너무 많이 소요되기 때문에) 레비비치 06:51, 2021년 6월 30일 (UTC)[]
  • 서포트 세미 PC는 대체적으로 쓸모가 없으니, 거의 적용해서는 안 된다. 그것은 편집자의 시간 낭비다. Semi'ing TFA는 몇 년 전에 일어났어야 했던 감각적이고 합리적인 행동이다. 그것은 거의 시기상조다: 우리는 TFA가 일상적으로 공공 기물 파손의 대상이라는 것을 안다. 우리는 페이지가 사전적으로 보호되지 않는다는 생각에 사로잡혀 있어서 그렇게 하면 백과사전에 도움이 된다면 우리의 규칙이 바뀔 수 있다는 사실을 잊고 있었다. TFA 보호는 편집자의 시간과 주의를 상당히 절약하기 때문에 우리의 정규 정책에 대한 합리적인 예외다. 선장Eek 06:01, 2021년 7월 1일 (UTC)[]
  • 위와 같은 우가포드의 선택적 분석에 근거한 선제적 보호부분적으로 반대한다. 어차피 (싫다고 하는 실례지만) PC는 신경도 안 쓰고, 듣던 것만큼 관리가 허술하면 피하게 되어 더욱 기쁘다. 반보호를 선제적으로 적용하는 것은 기껏해야 두어 개의 작은 땅딸막이를 위한 큰 망치인데, 위에서 여러 번 언급했듯이 우리 누구라도 편집 가능한 정신에 어긋난다. TFA는 이대로 내버려두자. 파손된 소수의 사람들은 청소를 할 수 있고, 하루 동안 보호가 필요할 때 청소를 할 수 있다. JohnFromPinckney (대화/편집) 07:20, 2021년 7월 2일 (UTC)[]
  • 강력한 지원 PC 보호는 지원하지만 자동 세미(확실히 완전하지는 않음) 보호는 지원하지 않음. TFA는 WP에서 가장 눈에 띄는 부분이며 따라서 종종 새로운 편집자가 편집하려고 시도할 수 있는 첫 번째 기사다. 그것은 누군가가 처음 편집을 시도했을 때 편집이 허용되지 않는다는 통지에 맞닥뜨리게 되면 매우 나쁜 메시지를 보낼 것이다. 그것은 WP의 공개 편집 철학과는 상반된다. 그러나 PC는 TFA에서 일어나는 모든 파괴 행위를 걸러내는 훌륭한 방법이다. 에르고 섬 14:05, 2021년 7월 3일 (UTC)[]
  • 원칙상의 포괄적 보호에 반대하라, 이것은 위키피디아의 철학을 거스르고, 그들이 실제로 필요한 경우에만 보호를 적용한다. 또한 데이터 수집 RfC를 갖는 것을 반대하지만, 여기서 일어난 것처럼 보이는 데이터 분석 전에 RfC를 갖는 것은 말이 되지 않는다. 고마워요. 마이크 필 (토크) 14:57, 2021년 7월 3일 (UTC)[]
  • PC가 혼란스럽기 때문에 semi s를 지원하라, pc를 반대한다. 하지만 그때, 나는 PC가 enWP에서 처음 언급되었을 때부터 혼란스러웠던 것처럼 항상 반대해 왔다고 생각한다. 이런 식으로 쓰면 세미는 별로 해를 끼치지 않는다고 생각한다. 그것이 메인 페이지에 있을 때는 초보자로부터 그것에 대한 편집을 장려할 때가 아니다. DGG (토크) 17:20, 2021년 7월 3일 (UTC)[] 더 나은 선택이 될 다른 쉽게 눈에 띄는 기사들도 많이 있다.
  • 지원 세미; 중립 기울기 매우 약한 지원 PC; Hut 8.5에 따라. 선제적 세미 보호는 본질적으로 해답이 되지 않지만, 이것은 프로젝트에 입증 가능한 이익이 있을 수 있는 극소수의 시나리오 중 하나이다. 스펜서T•C 23:42, 2021년 7월 3일 (UTC)[]
  • Semi, Antious PC 지원. 검토자만 마지막 검토 이후 편집한 모든 편집을 수락하거나 되돌릴 수 있기 때문에 변경 보류 보호는 편집률이 높은 모든 기사를 망친다. 어떤 사람이 편집하는 페이지에서는 괜찮다; 어떤 사람은 좋고, 어떤 사람은 일이 필요하고, 어떤 사람은 나쁘고, 엄청난 번거로움과 검토자 측에서 많은 일을 하는, 여러 사람의 기고를 쉽게 얻을 수 있는 기사에서는 괜찮다. -- 아사테아 15 Contribs:51, 2021년 7월 4일(UTC)[]
  • 반보호를 지지하고, 다른 사람들이 이미 상세하고 명료한 표현을 내가 반복하거나 새로운 표현을 반복하려고 할 필요가 없다는 이유로 PC를 반대한다. SMcCandlish lish 😼 03:44, 2021년 7월 5일(UTC)[]
  • 어느 쪽이든/둘 다, 순포지티브. 숨막힘(대화) 10:15, 2021년 7월 5일 (UTC)[]
  • 절차상의 문제로서 반(半)을 반대하라 우리가 그 문제에 대한 이전의 합의를 뒤엎고 싶다면, 모든 관심 있는 사람들을 확실히 끌어들이기 위해 그것을 특별히 목표로 하는 제안으로서 해야 한다. 반보호 TFA에 반대할 수도 있는 사람들은 PC가 편집을 방해하지 않고, 승인될 때까지 애논이 그들을 보지 못하게 할 뿐이기 때문에 이 토론을 무시했을지도 모른다. PC에 대해 중립적인 입장을 취하고 있지만, 여기서의 많은 논평들이 "PC는 어디에서도 사용되어서는 안 된다"는 제안 자체가 아니라면, 사전 믿음에 유리한 실제 재판을 무시하고 있는 것 같다는 점에 주목한다. Anomie 13:13, 2021년 7월 5일 (UTC)[]
    FYI, WP를 수정했다.CENT는 이 논의의 가능한 결과로서 반보호를 포함시킨다. -- 04:20, 2021년 7월 19일 (UTC)[]
    너무 늦었어, IMO. 그리고 누군가가 이미 너의 편집을 취소했어. 내 표를 바꾸지 않을 거야. Anomie 00:12, 2021년 7월 20일 (UTC)[]
  • Semi, 중립 PC Semi가 여기 잘 어울리는 것 같아. PC는 새로운 편집자들에게 더 온화하고 "환영"할 수도 있지만, 편집률이 높은 어떤 기사에도 도전적이다. ∘에픽푸퍼 03:32, 2021년 7월 7일 (UTC)[]
  • PC반대하며, 현상(보호 없음)반보호(semi-protection)약간 표준으로 선호한다. 나는 "변경 보류 중"은 일반적으로 어디에서나 좋지 않은 생각이고, 특히 메인 페이지 기사에서는 논의된 이유로 좋지 않은 생각이라고 생각한다. 만약 IP 파괴 행위가 충분히 문제가 된다면, 우리는 TFA를 반보호하지 않는 것에 대한 일반적인 입장을 버릴 수 있다. 비록 이전의 논의에 따르면, 나는 그것이 다소 최후의 수단이라고 생각한다. 그러나 PC는 반보호 IMO보다도 더 나쁘다 스노우파이어 (토크) 03:34, 2021년 7월 7일 (UTC)[]
  • 보류 중인 변경 사항에 대한 지원. 보류 중인 변경사항 보호는 어떤 항목의 기본 옵션으로 사용되어서는 안 된다. 그것은 본질적으로 혼란스러우며, 그것의 사용을 최소화해야 한다. 로버트 맥클레논 (대화) 04:35, 2021년 7월 5일 (UTC)[]

*:@Robert McClenon: 잘못된 섹션에 있는 것 같으십니까? -- Asartea 10 Contribs:10, 2021년 7월 7일 (UTC) 코멘트 감사합니다, Asartea. 로버트 맥클레논 (대화) 11:50, 2021년 7월 7일 (UTC)[]

  • semi를 지지하라(그러나 그곳이 일치된 곳이라면 PC를 반대하지 말라) 현시점에서는 모두가 "모든 사람이 위키피디아를 편집할 수 있다"는 것을 알고 있기 때문에, 하루 동안 우리의 소중한 기사를 보호하지 않는 이유가 더 이상 설득력을 갖지 못한다.John M Wolfson (대화기여) 14:29, 2021년 7월 7일 (UTC)[]
  • 어떤 형태의 보호에도 반대하십시오. 이것은 문제를 찾는 해결책이다. 응, TFA는 파괴되지만, 빠르게 고쳐지잖아. 우리는 누구나 편집할 수 있는 백과사전이고, 그 원칙은 우리가 눈에 띄는 위치에 기사를 고를 때 자랑스럽게 전시되어야 한다. 그리고, 앞에서 언급했듯이, 가끔 공공 기물 파손 행위를 보는 것은 (급속히 고쳐지는) 독자들에게 위키피디아가 믿을 만한 출처가 아니라는 것을 상기시켜주는 좋은 방법이다. 나는 또한 공공 기물 파손 행위가 TFA에서 오래 지속되지 않는다는 것을 위에서 상세하게 분석한 것에 대해 확신하고 있다. 가네샤811 (대화) 14:33, 2021년 7월 7일 (UTC)[]
  • 반보호 지원 과거에 최근 많은 변화를 한 후 나는 지금이 너무 이른 순간이 아니라고 말할 수 있다. PC에 대해서는 내가 더 중립적이다. 쉘우드(토크) 23:04, 2021년 7월 8일 (UTC)[]
  • 가네샤811 등의 보호반대한다. 우리는 새로운 편집자들을 끌어들일 필요가 있고 페이지 보호는 그것에 해롭다. 그래, 반달리즘도 있겠지만 그건 덜 중요한 것 같고 치료법 수준도 관리가 가능한 것 같아. --Ykraps (대화) 05:07, 2021년 7월 9일 (UTC)[]
  • 모든 보호반대한다. (즉, 상황이 통제할 수 없을 경우 반보호를 실시하고, 그렇지 않을 경우 다른 기사와 마찬가지로 최근의 변화에 대처하는 현상 유지). 새로운 편집자를 모집하는 데 있어 가장 큰 장애물 중 하나는 아무도 이것이 정말 누구나 편집할 수 있는 백과사전이라는 격언을 믿지 않는다는 점이다. 나도 알아, 왜냐하면 2006년에 처음으로 시험 편집을 했을 때, 나는 그것이 실제로 즉시 그 프로젝트에 실행되리라고는 예상하지 못했기 때문이야. 내가 거기에 흑백으로 덧입힌 것을 보니 여기에 내가 기여할 수 있다는 생각이 들었다. 프로젝트에서 가장 눈에 띄는 편집 가능한 페이지로서 TfA는 누군가가 그러한 시험 편집을 고려할 수 있는 최초의 호출항이며, 우리는 "네, 위키피디아를 편집했지만 오직 당신만이 편집할 수 있습니다,"라고 말하는 것과 같은 장애물을 그들의 방식에 놓아서는 안 된다. 심지어, 그들이 위키피디아를 단지 위키피디아가라고 느끼도록 기사를 반비보호해 버려서는 안 된다. 전문가용 실용적인 차원에서 나는 PC가 원칙적으로 잘 작동하지 않고, 결국 편집자들이 정리하는 데 더 많은 일을 하면서 혼란스럽게 된다는 토니발리오니의 의견에 동의한다.아마쿠루 (토크) 08:40, 2021년 7월 9일 (UTC)[]
  • PC와 Semi 지원 만약 그것이 FA 과정을 통과했다면 그것은 대개 할 수 있는 일이며 IP로부터의 많은 변화들은 종종 큰 이득이 되지 않을 것이다. IP 에디터들도 토크 페이지에서 편집을 요청할 수 있지만, 이는 반달들이 하루 동안 조회수가 높은 기사를 때리는 것을 막기 위한 좋은 시작이다. 스파이-시클icle 16Talk?:17, 2021년 7월 9일 (UTC)[]
  • 반보호 지원. 만약 FAS와 TFA가 그들이 원하는 대로 작동한다면, 기사가 주요 페이지를 장식할 때까지 산문을 많이 다루지 않아도 된다. 분류해야 할 더 큰 이슈가 있다면, 어떤 경우든, 그것들은 토크 페이지에서 더 잘 다뤄진다; 하루에 수천 건의 조회수를 받는 기사에서 일어나는 주요 개정은 독자들에게 좋지 않다. 편집 속도는 일반적으로 PC 보호가 유용하기엔 너무 높다(IMHO). Vanamonde (Talk) 20:09, 2021년 7월 9일(UTC)[]
  • 반보호 재판지지하라 나는 이런 일에는 보통 코멘트를 하지 않지만, 나는 여기서 그것을 만들고 싶다고 느낀다. TfAs가 피쳐링되는 동안 관찰할 때, 자동 응답되지 않은 사용자로부터 수정 사항이 되돌아오지 않는 것을 보지 못했다. 말하자면, 반대자들은 한 가지 경우가 있다. 영구적인 결정을 내리기 전에 조금 더 자료를 수집해야 한다고 생각한다. 링크20XX (토크) 01:39, 2021년 7월 10일 (UTC)[]
  • PC를 반대하다. 본질적으로, PC는 트래픽이 많은 페이지에는 효과적이지 않다. El_C 13:31, 2021년 7월 11일 (UTC)[]
  • Suppoer Semiprotection; 다른 것들의 변경 보류에 반대한다. 비록 이것이 유용할 것이라는 더 많은 증거와 과거 실험의 분석을 지원하고, 반제법만을 시험하는 새로운 실험을 설정하여 개선된 내용이 있는지 확인하고 싶다. 슈슈가(토크) 16:31, 2021년 7월 11일 (UTC)[]
  • 반보호 지원. FA는 정의상 즉각적인 편집이나 급진적인 정비가 필요하지 않으며 새로운 사용자들의 주장을 끌어들이기 위해 모든 페이지를 자동으로 편집할 필요가 없으며, 특히 공공 기물 파괴 행위가 더 흔하고 그것을 뒷받침하는 데이터가 없는 일반 기고자들의 시간과 에너지와 균형을 맞출 필요가 있다. 대기 중인 변경사항을 바쁜 작업으로 간주하여 반대하십시오. - ReconditeRodent « talk · 기여 » 01:41, 2021년 7월 12일(UTC)[]
  • 독자와 편집자의 이익 사이에서 최선의 타협으로서 선제적인 PC 보호지원한다. 선제적 보호가 없는 현상에 대한 두번째 선택이다. 반달리즘이 단지 몇 초만이라도 그날의 가장 큰 성취라고 여겨지는 것에 대해 보여지는 것은 그저 당혹스러운 일이다. 의미 없는 준재판에 반대하라; PC와 달리 우리는 이미 무슨 일이 일어날지 알고 있고, 재판을 진행하면 준의 사용 여부를 결정하는 데 도움이 될 어떤 것도 말해주지 않을 것이다.-- --의 왕 04 04 04:15, 2021년 7월 19일 (UTC)[]
  • 반체제 반달리즘은 일어나 TFA가 아니면 당분간 다른 곳에 있을 것이다. TFA는 잘 감시되고 반달리즘으로의 회귀가 빠르게 일어난다. PC는 별로 잘 작동하지 않는 쓰레기 같은 방법이며, 특히 트래픽이 많은 페이지에서는 그렇지 않다. "누구나 편집할 수 있는 백과사전"이라는 고매한 이상은 이제 한동안 두들겨 맞고 너덜너덜 해졌는데, 이것은 또 하나의 관에 못이 박혀 있는 것이다. - 편집자는 공식적으로 슈로캣(58 FAs, 상당수는 MP에 있다)으로 알려져 있으며, 2A00:23C7:2B86:9800:39로 편집되었다.CA:4E99:E03B:7228 (토크) 08:34, 2021년 7월 20일 (UTC)[]
  • 보류 중인 변경에 대한 중립, 반보호에 반대 – Per Bilorv는 다음과 같이 썼다.

    ... TFA를 편집 가능한 상태로 유지하는 것은 사람들이 누구나 편집할 수 있는 백과사전이라는 것을 발견하도록 돕는 데 특히 중요하다. 물론, 대부분의 편집이 상황을 악화시키겠지만, 그게 중요한 것은 아니에요. 많은 귀중한 편집자들의 첫 편집이 기사를 더 나쁘게 만들었다. 우리는 시험 편집과 도움이 되지 않는 선의 편집 (그리고 심지어 일부 파괴적인 편집도)을 이미 감소하고 있는 새로운 기고자들의 흐름을 끊는 것을 멈추기 위해 투자할 가치가 있는 비용으로 볼 필요가 있다.
    사용자:빌로프17:34, 2021년 6월 26일 (UTC)

    지난 20년 동안 TFA의 공공 기물 파손 수준은 관리가 가능하다는 것을 보여주었다. 그렇게 하는 데 드는 노력은 새로운 사용자들에게 이것이 "누구나 편집할 수 있는 무료 백과사전"이라는 것을 보여주는 것의 이점보다 더 크지 않다. 207.161.86.162 (대화) 00:15, 2021년 7월 23일 (UTC)[]

  • 반보호 공무원을 만드는 것을 매우 강력하게 지지 – 나의 오랜 경험은 뉴스 속보나 일상의 시청률이 매우 높은 기사가 페이지 보호가 없다면 광범위한 반달리즘에 시달린다는 것을 증명했다고 말할 수 있다. 본지에 실린 TFA 기사도 예외는 아니지만, 사실, 실험적인 반보호 정책을 시행하기 전에 그곳에 소개된 기사들 중 일부는 24시간 동안 내가 본 것 중 가장 큰 반달리즘 공격을 경험했다. 이것은 소수의 알려진 LTA와 드라이브 바이 밴드를 포함했다. 그 예로는 2018년 7월 중순 허리케인 다니엘(2006)이 있다. 물론 위키피디아는 누구나 편집할 수 있는 백과사전이어야 하지만(실제로 여기 있는, 파괴적인 의도를 가진 사람들이 아니라) 대량 파괴 행위가 불가피할 때 특집기사를 무방비로 방치함으로써 백과사전의 진실성과 정확성을 지켜야 할 책임을 포기할 수 있다는 뜻은 아니다. 공공 기물 파손을 허용하는 것은 단지 파괴적인 것이 아니라, 나쁜 평판을 불러오고 더 많은 기물 파손과 모방 범죄(이것은 종종 최초의 기물 파손보다 훨씬 더 파괴적이다. 이 정책은 간단하다. 실험적인 세미 프로텍션은 의미 있는 부작용 없이 TFA를 통해 메인 페이지에 소개된 기사들의 혼란을 심각하게 줄였다. 그런 만큼 이 정책이 영구적으로 만들어져야 한다고 본다. 이 정책은 몇 년 전에 시행되었어야 했다. 이제 우리는 마침내 이 사이트의 무결성을 지키기 위해 옳은 일을 해야 할 때다. LightandDark2000 🌀 (토크) 05:16, 2021년 7월 23일 (UTC)[]
    • 이 실에 거의 모든 사람(예외 한두 가지)보다 기사를 더 많이 가진 사람이 TFA로 나타나면서, 당신과 의견이 다른 사람들의 입장을 "두뇌가 없는" 악플러로 묘사한다. 나는 실제로 IP 반달보다 개선(또는 악화)할 필요가 없는 것들을 "개선"하려고 애쓰는 등록된 편집자들로부터 더 많은 혼란과 슬픔을 발견한다. 반달들은 되돌아가서 가버리면 지루해진다. 등록된 사용자들은 터무니없이 어리석은 점들에 대해 길게 논쟁할 것이다. 반달리즘은 빨리 주워지고 되돌아가며, 낮 동안 지속되는 반달리즘의 대상이 되는 기사는 보호받을 수 있다. 오늘 기사(아더 블랙번)를 보고 아주 적은 수의 반달리즘(빠르게 되돌림)을 보고 있지만, 등록되지 않은 사용자로부터 몇 가지 뛰어난 변화들을 보고 있다. 기사를 보호하면 그 변화는 이루어지지 않을 것이다. 모든 IP가 토크 페이지를 사용하는 것을 아는 것은 아니며, 예를 들어 소유욕이 강한 아포스트로피를 추가하라는 메모를 남기는 것도 귀찮을 것이다. 이 사이트의 "통합"은 좋은 변화를 만들고자 하는 사람들에게 개방되어 있다. 만약 당신이 WP 기사의 자료가 "통합성"을 가지고 있다고 생각한다면, 그것은 틀렸다. 그렇지 않다. FA들은 시대에 뒤떨어지고 오류가 있으며, IP들은 종종 많은 편집자들보다 더 잘 등록되어 있는 편집자들만큼 잘 고른다. - 공식적으로 SchroCat으로 알려진 편집자86.162.16.171 (대화) 10:09, 2021년 7월 23일 (UTC)[]에서 편집자로 편집된다.
  • 반보호 반대; 보류 중이면 OK. 우가포드와 함께 해야겠어 위와 같은 상세한 팩트 기반 연구는 매우 설득력이 있다. GenQuest 23:45, 2021년 7월 24일 (UTC)[]
  • Semi, PC 지원, 보호 반대 - TFA의 가시성이 높음 이것은 양방향으로 갈 수 있다. 새로운 사람들이 그것을 보고 약간의 "재미있는" 것을 갖기로 결정하며, 그들의 파괴적인 편집은 더 많은 사람들에게 보여진다. 허리케인 에밀리(1993)는 TFA가 보호받지 못할 때 어떤 일이 일어나는지 보여주는 예다. 세미(Semi)는 PCR. 코딩사이클로네에서 큰 밀림을 일으키지 않기 때문에 최선의 행동 방침이 될 것이라고 생각한다.damages / 06:13, 2021년 7월 25일 (UTC)[]
  • TFA에 대한 어떤 수준의 보호지원하되, 완전한 보호까지 포함하되, 확증된 보호가 가장 선호된다 - 오늘의 특집기사의 목적은 새로운 편집자들이 뛰어들어 편집을 시작하도록 장려하는 것이 아니라는 것이 문제의 현실이다. 위키백과 기사들이 충분한 작업으로 어떤 것이 될 수 있는지 보여주기 위해서입니다. 만약 기사가 오늘의 특집 기사로서 메인 페이지에 도달하는 지경에 이르렀다면, 새로운 어떤 기사도 그것을 개선하기 위해 할 수 있는 일은 거의 없을 것이고, 대신에 그것은 반달, POV 푸셔, 그리고 다른 파괴적인 편집자들에게 매력적인 표적이 될 것이다. In The News and Did You Know와 같은 메인 페이지의 다른 부분들은 이미 새로운 편집자들을 유혹하는 역할을 한다. 만약 편집자가 특정 날짜의 특집 기사의 내용에 대해 진정한 관심을 가지고 있다면, 그들은 토크 페이지에서 그것을 변경해 달라고 요청할 수 있다. TFA를 무방비 상태로 방치하는 것은 공공 기사의 파괴 행위를 유도하고 숙련된 편집자들이 그들이 작업한 페이지를 가장 두드러지게 전시할 때 엉망으로 만드는 것을 다루고 싶지 않기 때문에 특별 기사에 기사를 싣지 못하게 하는 것이다. HumanBodyPiloter5 (대화) 19:40, 2021년 7월 26일 (UTC)[]
    • TFA로서 여러 기사를 써온 편집자로서 "TFA를 무방비로 방치하는 것은 모두 공공 기사의 파괴 행위를 부추기고 경험이 풍부한 편집자들이 페이지를 어지럽히는 반달족을 상대하고 싶지 않기 때문에 특집 기사 후보자에게 기사를 가져오지 못하게 하는 것"이라는 주장은 완전히 허풍이다. HumanBodyPiloter5, 당신의 말은 FA를 썼거나 TFA에 가본 적이 있거나 심지어 FAS를 검토한 적이 있다면 더 많은 비중을 차지했을지도 모르지만, 만약 당신이 그들의 입장이 되어본 적이 없다면 FA 작가들을 대변하려고 하지 말아주십시오. 나는 TFA (그리고 다음 주에 또 다른)에서 내가 기억하고 싶은 것보다 더 많은 기사를 가지고 있었고, 반달은 진짜 문제가 아니다. 다수의 경험 많은 FA 검토자들보다 더 잘 안다고 생각하는 등록 편집자들은 매우 빨리 되돌리거나 차단된 IP 반달들을 통과하는 것보다 훨씬 더 크고 더 해로운 문제들이다. - 편집자는 공식적으로 SchroCat으로 알려져 있다. 2A00:23C7:2B86:9800:E5에서 편집자:2A00:23C7:9800:E5에서 편집자.FF:FC15:F2DE:FA0B (대화) 21:57, 2021년 7월 26일 (UTC)[]
  • 아마쿠루 등에 의한 어떠한 형태의 보호에도 반대한다. 채용 기회는 문제를 훨씬 능가하며 TFA는 이 프로젝트에서 가장 주목받는 기사 중 하나이며, 어떤 공공 기물 파손도 금방 되돌아갔다. TFA로 특집기사를 낸 적은 단 한 건(2020년 2월 9일 에델 스피티저)밖에 없었지만, 이날은 편집이 두어 건에 불과했고, 빠르게 되돌아온 반달리즘(역사 참조)은 네 건에 불과했다. TFA는 위키피디아의 특별한 부분이 아니라 위대한 작품을 위한 쇼케이스다. 기사는 거기에 나타난다고 해서 다르게 취급되어서는 안 되며, 보호 정책은 다른 기사를 하는 것처럼 그것에 적용되어야 한다. 만약 반달리즘이 너무 많아서 다룰 수 없지만 대부분의 기사(내 것과 같은)는 보호가 없어도 그렇게 많은 반달리즘을 끌어들이지 못할 것이기 때문에 그것을 보호하라. SoWhy 09:47, 2021년 7월 28일(UTC)[]
  • 스트롱은 TFA를 위한 어떤 종류의 선제적 보호에도 반대한다. 다른 시간 동안 우리는 이 토론을 했다. (내 말은, 정말로, 이것은 또?) 그리고 위의 아마쿠루 외 에 대한 잘 표현된 분석을. 최근에 TFA를 몇 개 보고 왔는데, 캐주얼 에디터만이 당황스러운 오타를 포착하고 있다(토크:치매_with_Lewy_badies#TFA) 및 돋보기 오류(Talk:Call_of_ 참조)의무:_Modern_Warpare_Remastered#Killstreaks_==_scorestreaks?) 그것은 겉만 긁는 것이다. 물론 공공 기물 파손이 있긴 하지만 되돌리기는 쉽지만 품질을 확인하는 것은 쉽지 않다. 롤백 버튼이 없어도 한 번의 ref(아마도 그 이상)를 검사하는 데 걸리는 시간에 십여 건의 반달리즘 사례를 되돌릴 수 있다. 때때로 이런 종류의 일을 포착하는 것은 일상적인 편집자들뿐인 것 같다. 만약 총체적인 LTA가 한 페이지를 공격하기 시작한다면, 그때는 그것을 보호해야 한다. 하지만 그렇지 않으면 이것은 사람들을 참여시키고 커뮤니티를 극복하는 꽤 좋은 방법이다.위키:FearOfEditing. 만약 좋은 편집을 위해 10비트의 반달리즘이 있다면, 그래서? 나쁜 편집은 되돌리고 좋은 편집은 유지하기가 쉬운데, 결국 기사는 여전히 개선되었다. 평판 훼손은 적나라한 청어인데, 최근 검토되지 않은 몇몇 진짜 수준 이하의 FA들(일부 FA들 중 일부는 애초에 승진하지 말았어야 했다)이나 보통은 그 과정에서 미끄러진 멍청한 실수들을 가지고 있는 것에 의해 우리의 평판에 훨씬 더 손상을 입힌다. 반면에 위키백과 반달리즘의 존재는 이미 대중문화적 삼투증을 통해 대중들의 의식 속에 잘 배어 있고, 그것을 TFA에 접근하지 못하게 하는 것은 (그리고 최근의 많은 TFA 반달들이 자동 확증된 것을 볼 때), 이 제안은 그것이 의도하는 바를 이루지도 못할 것이다(는 그것을 발견한다).그러나 일부 사람들이 미트볼을 할 수 없다는 것을 증명하는 훌륭한 기념비적인 사례로 볼 수 있다.Elusion을 피하십시오. 관리자들은 어쨌든 보호에 대한 방아쇠를 당기는 것이 상당히 빠른 것 같다(아마도 너무 빠른 아폴로 15호는 두 개의 반달에 의해 3개의 비파괴적인 편집에 의해 단지 타격을 받은 후에 보호되었을 것이다, 그것은 내게 RFP에서의 감소처럼 보이지만, 나는 몇 년 동안 표준이 어떻게 발전해 왔는지 약간은 이해가 되지 않는다. PC의 경우, 그것은 정말로 낮은 트래픽 페이지에서만 작동하며, 그들의 변화가 지나갔다는 것을 보지 못하는 모바일 편집자들을 혼란스럽게 하고 좌절시킬 수 있는 능력을 가지고 있다. 연장이 제대로 뒷받침되지 않는 점도 문제다. 그 소릴 해서 미안해. 81.177.3.8 (대화) 17:06, 2021년 7월 30일 (UTC)[]

사이드 코멘트

나는 항상 새로운 편집자들이 참여하도록 유도하는 것이 목표라면, 몇 년 동안 작업해 온, 그리고 (본질적으로) 완성된 기사를 다루는 것은 잘못된 방법이라고 생각해 왔다(그리고 그렇다, 나는 WP 기사는 결코 "완성되지 않는다"는 것을 알지만, 내 말의 의미를 알고 있다고 생각한다). 아마도 우리는 그 목표를 달성하기 위해 "개선 조항"을 강조해야 할 것이다. 블루보어 (토크) 13:45, 2021년 6월 28일 (UTC)[]

이것은 2013년에 시도되었지만, 성공하지 못했다* Pppery it has begun...* 13:58, 2021년 6월 28일 (UTC)[]
기사 개선의 주요 이슈(내 생각엔)는 주제의 광범위성이다. 예를 들어, 나는 무엇을 추가하거나 삭제해야 할지조차 모르기 때문에 아마도 철학과 관련된 기사를 많이 개선하지 못할 것이다. 오직 전문가만이 합의와 합당한 그리고 과도한 무게를 알 것이다. 위키피디아 보기:개선 조항/2013/21, 고대 음악, 이민과 같은 과목도 개선이 매우 어렵다. 무엇을 개선해야 하는가? 적당한 무게와 과도한 무게? 위키백과 정책과 지침은? 마이너 CE처럼 개선이 쉬운 페이지를 나열하는 게 더 나을 것 같아. 숭어템플 (대화) 17:14, 2021년 6월 28일 (UTC)[]
위키백과:Growth Team의 특징은 현재 영어 위키백과에서 시험되고 있다. 그 중 하나는 신입에게 제안하는 과제 리스트를 제공하는 것이다.이삭(토크) 23:19, 2021년 6월 30일 (UTC)[]
기본 페이지에는 다른 섹션이 있다. DYK와 ITN 기사는 더욱 낙후되어 있다. ITN 기사는 더욱 흥미진진하고 ITN 이벤트는 편집자 모집, 아마도 그러한 목적을 위한 최고의 메인 페이지 섹션에 해당된다. 나는 TFA라는 한 섹션이 기사를 '완전한' 형태로 만들기 위해 지속적인 발전을 과시하는 것은 좋은 일이라고 생각한다. 이는 기사를 그 단계에 이르게 하는 가능한 동기부여와 독자들에게 그러한 기사가 어떻게 생겼는지 볼 수 있도록 하는 것이다. RusingReader (대화) 14:08, 2021년 6월 28일 (UTC)[]
@WP:FAC 코디네이터: 위와 같은 토론에 대해 다들 알고 있으리라 생각하지만, FA 레귤러들과 함께 어떤 토크 페이지가 활성화되어 있든 간에 노트를 삭제해야 할지도 모르겠다(어느 쪽인지, 네가 너무 많아서인지 모르겠다. RowlingReader (대화) 20:05, 2021년 7월 7일 (UTC)[]
위의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

IP 편집자가 아티클 토크 페이지를 만들 수 없도록 방지

그래서 내가 알기로는 IP 에디터들과 새로운 계정들은 새로운 기사를 만들 수 없다. 하지만 그것이 그들이 노력하는 것을 막지는 못했다. 매일 밤 위키백과:데이터베이스 보고서/고아 대화 페이지 목록인 비고아 대화 페이지가 생성되는데, 주로 IP 계정으로 작성되며, 이에 수반되는 기사가 없다. 가끔 토크 페이지는 무작위 코멘트만 달기도 하지만 기사의 초안이 있는 경우가 많다. 이건 큰 문제가 아니야, 내가 확인해 봤더니 매일 5페이지에서 15페이지가 넘게 나열돼 있어. 하지만 매일 일어나는 일인데 IP 계정 페이지 생성 금지가 기사 토크 페이지까지 확대되어야 하는지, 특히 기존 글과 연관되어 있지 않기 때문에 더더욱 궁금하다. 때때로 이러한 고아 대화 페이지는 리디렉션, 카테고리 또는 초안 공간에 있지만 주로 기사 공간에 있다.

생각, 의견, 반대? 리즈 05:14, 2021년 7월 27일 (UTC)[]

나는 IP가 존재하지 않는 기존 페이지의 토크 페이지에 대해 합법적인 토크를 하는 것이 나을 수 있기 때문에 더 많은 정보가 있을 때까지 이것을 계속 반대한다. IP별 토탈 토크 페이지 생성에 대한 데이터를 가지고 있으며, 그 중 어느 부분이 우리가 해결하고자 하는 문제인지 알 수 있는가? 고아 대화 페이지는 대부분 IP 계정으로 만들어진다며 그들의 창조를 관리자로 한정해야 할까? DMACks (대화) 05:45, 2021년 7월 27일 (UTC)[]
확실히 하자면, IP가 기사 토크 페이지를 만드는 것을 금지할 것인가 아니면 관련 기사가 없는 페이지(예: Talk:이것처럼)? 만약 후자가 기술적으로 실현 가능하다면, 아마도 그렇게 하는 것이 스팸을 줄일 수 있을 것이다. 하지만 우리는 편집 과정에서 토크 페이지의 중요한 역할을 고려할 때, 이미 존재하는 기사에 대해 등록되지 않은 사용자들이 토크 페이지를 만드는 것을 막지는 말아야 한다. Mz7 (토크) 07:15, 2021년 7월 27일 (UTC)[]
@Mz7 동의한다. -Qwerfjkltalk 07:26, 2021년 7월 27일 (UTC)[]
나도 Mz7에 동의해. 또한 IP 편집자가 대화 페이지를 작성할 수 없는 경우, 이를 시도할 때 보이는 메시지는 그들이 의도할 수 있는 장소(예: 초안 공간, WP:찻집, 위키백과:샌드박스 Thryduulf (대화) 10:42, 2021년 7월 27일 (UTC)[]
나는 IP가 기존 기사에 대한 토크 페이지를 만드는 것을 막으면 안 된다는 것에 동의하지만, 메인 스페이스에 고아 토크 페이지를 만드는 것은 거의 적절하거나 유용하지 않다는 것에 동의한다. 그러나 다른 페이지의 존재를 확인하는 편집 필터(예: 확증된 사용자를 자동화하는 메인 스페이스의 고아 토크 페이지 작성을 제한하는 편집 필터를 만드는 등)는 만들 수 없다고 생각한다. 만약 그것이 사실 가능하다면 나는 그러한 움직임을 지지할 것이다. 그러한 장소에서 초안 기사를 작성하는 IP는 삭제될 때 혼란에 빠질 뿐이다. 즉, 초안 문서를 스페이스나 다른 곳으로 리디렉션하는 것이 그들 자신의 이익이다. 반딧불 (t · c ) 11:18, 2021년 7월 27일 (UTC)[]
질문: 관련 기사가 없는 토크 페이지를 갖는 것이 적절한가? 또 다른 방법으로, 모든 사람(IP만이 아닌)이 기존의 기사가 없는 토크 페이지를 만드는 것을 막아야 하는가? 루돌프레드 (대화) 17:36, 2021년 7월 27일 (UTC)[]
관련 기사가 없는 토크 페이지를 갖는 것이 적절한가? 예. 토크 페이지 아카이브(예: 토크: 쿠바/아카이브 1은 존재하지만, 쿠바/아카이브 1은 존재하지 않음) 및 GA 리뷰(예: 토크:잉크 워시 페인팅/GA1은 존재하지만 잉크 워시 페인팅/GA1은 내가 생각할 수 있는 가장 흔한 예시들("관련 기사"가 있는지 여부는 해석에 달려 있다)이지만, 다른 용도는 매우 가끔 있다(예: 위키백과 초기에는 삭제된 기사의 토크 페이지만이 종종 삭제 논의의 유일한 장소인 경우가 있다.ocuited) - 범주:위키피디아 고아가 된 대화 페이지는 빨리 삭제되어서는 안 된다. 나는 IP 편집자가 이것들 중 하나를 만들어야 하는 이유를 생각할 수 없다(그리고 그것들을 코드화하려는 어떠한 시도도 단지 할 수 있는 사람에게 물어보는 노력보다 훨씬 더 클 것이다) 그러나 확증된 사용자들은 최소한 할 수 있어야 한다. Thryduulf (대화) 18:58, 2021년 7월 27일 (UTC)[]
만약 실현 가능하다면, Mz7의 예에 따른 관련 기사 없이 IP가 TP를 만드는 것을 방지하는 것을 지지한다. 만약 우리가 그들이 그렇게 하는 것을 완전히 금지한다면 그것은 WP를 약화시킨다.BRD는, 일단 IP의 편집이 TP 없이 기사에서 되돌아가면, 그들의 유일한 선택은 전쟁을 편집하는 것(아마도 편집 요약을 통해 통신하는 것)이나, 혹은 멀리 떠나는 것이다. 기병(토크) 22:58, 2021년 7월 27일(UTC)[]
  • 당사는 현재 다음을 가능하게 하는 기술 도구를 보유하고 있지 않다.
IF(   (USER IS IP) AND  (ACTION=CREATE PAGE) AND  (NAMESPACE=TALK) AND  (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") AND  ("TALK:(BASEPAGENAME:NEWPAGETITLE)" EXISTS) AND   (PAGE (main):(NEWPAGETITLE 없음) 그 다음 생성 불허; 
  • (또는 pseducode와 비슷한 것). 만약 우리가 확인되지 않은 편집자들이 모든 새로운 대화 페이지를 만드는 것을 중단하기를 원한다면, 그것은 하찮을 것이다.xaosfluxTalk 23:13, 2021년 7월 28일(UTC)[]
    The (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") IP 편집자들이 새로운 토크 페이지 아카이브를 만들 필요가 없어야 하기 때문에 라인이 생략될 수 있으며, 내가 살펴보지 않은 한 그들이 GA 지명의 빈번한 개시자인 것은 의심스럽다. 너의 말투로 보아 제안서 이행 능력에 중요한 차이가 없을 것 같은데? Thryduulf (대화) 23:51, 2021년 7월 28일 (UTC)[]
  • 그렇다, 이것은 소프트웨어 AFAIK에서는 기술적으로 불가능하다. 하지만 당신은 CSD에 그러한 페이지를 자동적으로 요청할 수 있다. RusingReader (대화) 23:28, 2021년 7월 28일 (UTC)[]
    나는 이 페이지를 인간적인 검토 없이 삭제하는 것에 반대한다. 왜냐하면 그것들은 실행 가능한 초안, 도움 요청, 그리고 유일한 문제가 잘못된 장소에 있는 다른 것들을 포함할 수 있기 때문이다. Thryduulf (대화) 23:47, 2021년 7월 28일 (UTC)[]
  • Mz7. 소프트웨어가 G8 대상 토크 페이지가 비자동 확증 계정에 의해 생성되는 것을 막았다면 좋을 것이다. 만약 당신이 WMF가 그렇게 하도록 할 수 있다면(혹은 당신이 직접 할 수 있다면) 당신은 나의 축복이 있다. 그것 없이는 "그들이 그렇게 하도록 내버려두고 관리자가 하루나 이틀씩 청소하게 하는 현상"이 최선의 선택이다. 나는 우리가 그 삭제들을 하는 봇을 믿을 수 없다는 위의 제안에 동의한다. 사용자:전원(전원~엔위키, π, ν) 23:50, 2021년 7월 28일(UTC)[]
  • 가능하다면 지원하겠는데 현재 우리 기술로는 불가능할 것 같다. 나는 봇 삭제의 양이 얼마나 될지 관심이 있지만, 다른 사람들과 마찬가지로 나는 즉시 삭제하기 위해 실행 가능한 콘텐츠를 게시하는 IP를 물어뜯는 것을 경계한다. Wug·a·po·des 00:09, 2021년 7월 29일(UTC)[]
  • 다른 사람들이 이런 합법적 편집의 제한에 대해 우려를 표명했듯이, 내가 공유하는 이 생각은 어떠한가? 소프트웨어(비슷하게, 그러나 어쩌면 내가 이것을 가능하게 하는 어떤 기능이 있다는 것을 내가 알지 못하는 것일 수도 있음) 또는 관리자봇(소금/블랙리스트를 살펴보기 위해 관리자봇이 필요할 것임)은 페이지 작성 후 새로운 기사-공간 페이지에 대한 대화 페이지를 자동으로 생성하지만 비교적 짧은 시간(즉, 1시간) 후에 생성한다. 그것은 단지 빈 페이지일 수도 있다. 이렇게 하면 편집자가 (존재하는 기사의) 합법적인 기사 대화 페이지를 편집하는 동시에 고아가 된 대화 페이지가 만들어지는 것을 막을 수 있다. 자동 삭제에 대한 우려는 공유하지만, 관리자가 관련 페이지를 삭제할 때 토크 페이지는 삭제할 수 있기 때문에 봇을 통해 자동으로 만드는 것이 문제가 될 만한 이유를 찾을 수 없다. 이는 또한 일부에서 가질 수 있는 "새로운 페이지 작성" 두려움을 없앨 수 있는 이점이 있으며, 또한 토크 페이지 배너나 다른 메시지를 자동으로 적용하거나 심지어 편집자들이 "헤더" 자료를 정리하여 마무리하는 "미완성 토크 페이지" 또는 유사한 것으로 분류할 수도 있다. -bb:ʳkənhmez (사용자/say hi!) 15:43, 7월 31일[UTC]
    • 내가 명시적으로 말하는 것을 잊어버렸기 때문에, 만약 그러한 봇이 실행되었다면, 비자동 확인 계정(또는 더 높은 계정)에 의한 토크 페이지 생성은 실행 가능한 선택이 될 것이고, 합법적인 창작(내 봇 제안이나 다른 것)을 방해하지 않는 방법이 동시에 실행된다면 나는 그것을 지지할 것이다. -bb:ʳkənhɪmez (사용자/say hi!) 15:45, 31 J.uly 2021 (UTC)[]

제안: 새 계정에 대해 기본적으로 구문 강조 표시 설정

다음의 논의는 의견요청을 기록한 기록이다. 수정하지 마십시오. 이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.
지지자들은 학습 곡선을 낮추고 경험을 향상시키는 새로운 편집자에게 도움이 될 것이며, 켜는 옵션을 찾기 어렵다고 언급했다. 반대자들은 느림과 접근성, 그리고 그것을 끄는 데 어려움을 우려했다. 논쟁은 비교적 평등하며, 많은 편집자들이 이 변경사항의 실행을 지지했기 때문에, 나는 새로운 계정에 대해 기본적으로 구문 강조를 켜는 것에 대한 분명한 공감대가 있다고 생각한다.Novm Languageae (토크) 09:10, 2021년 8월 4일 (UTC)[]

구문 강조 표시는 2018년에 출시된 매우 유용한 기능으로 위키링크를 파란색, 템플릿 보라색, 참조 녹색 및 기타 색상 코딩으로 전환하여 Wikitext를 더 쉽게 읽을 수 있도록 도와준다. 형광펜 버튼을 클릭하여 언제든지 켜거나 끌 수 있다(Codemirror-icon.png편집 도구 모음에서 )를 사용하지만, 많은 신규(신규가 아님) 편집자들이 검색하는 데 상당한 시간이 걸리고, 따라서 편집 도구 모음의 이점을 놓치게 된다.

모든 새로운 계정과 IP 편집기에 대해 구문 강조 표시가 기본적으로 활성화될 것을 제안한다. 이 제안은 기존 사용자를 변경하는 것을 포함하지 않는다. 모든 편집자는 버튼을 클릭 한 번으로 구문 강조 표시를 켜거나 끌 수 있는 옵션을 계속 갖게 될 것이다. {{u Sdkb}} 19:09, 2021년 7월 5일(UTC)[]


설문 조사(동기세 강조 표시)

  • 제안자로서의 지원. 이것은 새로운 편집자의 편집 경험을 향상시켜, 보존을 강화하는데 도움을 줄 것이다. 구문 강조 표시는 완벽하지 않지만(가끔 사소한 버그를 접했지만), 2년 동안 널리 사용되어 온 우리 대부분은 그것이 분명한 긍정이라는 것을 알게 된 것 같다. {{u Sdkb}} 19:09, 2021년 7월 5일(UTC)[]
  • 지원 유지력 향상에 도움이 되고, 보기에도 좋아 보인다.dudhrContribs 02:31, 7월 6일(UTC)[]
  • 는 진심으로 이 일을 몰랐고, 내가 이곳에 처음 왔을 때 알았으면 하는 바램을 가지고 있었다. 구문 강조 표시가 없다면, 그것은 단지 하나의 큰 위협적인 혼란일 뿐이고, 게다가 이 아이콘은 실제로 그것이 하는 일을 전달하지 않는다. 네가 언급하고 그것이 물건이라는 것을 나에게 알려줘서 정말 고마워. // MailotVoxel (대화) 17:24, 2021년 7월 6일 (UTC)[]
  • Support Condition support 이 구문 강조 표시는 원시 Wikitext 구문의 사용성을 크게 향상시킨다. 또한 WMF가 새로운 사용자를 위해 사용 가능한 이 기능을 기반으로 편집자 보존 메트릭스를 평가할 수 있다면 좋을 것이다. 마리오곰 (토크) 18:15, 2021년 7월 6일 (UTC)[]
  • 중요한 접근성 문제의 부재를 조건으로 내 투표를 지지하도록 변경. 아래 토론을 참조하십시오. 마리오곰 (토크) 18:21, 2021년 7월 6일 (UTC)[]
  • Sdkb당 가장 강력한 지원. ∘에픽푸퍼 03:27, 2021년 7월 7일 (UTC)[]
  • 지원 여기에서의 학습 곡선은 매우 가파르고, 이것은 사용자를 도울 수 있는 좋은 직관적인 방법이다. BTW 처음 먹어보았는데 켜두게 될 것 같아, 너무 좋아. HighInBC 08:45, 2021년 7월 9일 (UTC)[]
  • 지금은 반대 - 그것은 대형 기사의 실적을 현저히 둔화시킨다. 디폴트로 만들기 전에 새로운 편집자가 원하는 데이터로 몇 가지를 살펴봅시다. 우리는 그것이 유산을 증가시킬지 아닐지 모른다. '좋아해'는 이런 변화를 만드는 최악의 이유와 같다. 색채 배합은 접근하기 어려운 것 같아. VE 소스에 대한 구문 형광펜이 기존 편집기와 동일한지 잘 모르겠어. 그리고 아래에는 실행 가능성에 대한 질문이 있다. 우리가 이것이 개선될 것인지 아닌지를 고려할 수 있기 전에 정말로 더 많은 정보와 준비가 필요하다. 레비비치 13:12, 2021년 7월 9일 (UTC)[]
    문제는 새로운 편집자들이 정확히 무엇을 원하는지 알아내기가 어렵다는 것이다. 왜냐하면 그들은 종종 이런 종류의 페이지에 대해 알지 못하기 때문이다. 그리고 우리가 새로운 편집자들에 대해 커뮤니티에서 운영하는 설문조사를 할 수 있는 방법이 없기 때문이다.피톤코더(토크 기여) 11:30, 2021년 7월 16일 (UTC)[]
  • 일반적으로 잠정적인 지지, 이것은 분명히 우리가 지향해야 할 것이라고 생각한다. html은 대부분의 새로운 편집자들을 위협하고 혼란스럽게 할 것이다. 그러나, 그러한 시스템을 채택하는 것은 신중하게 이루어져야 하며, 레비비히가 지적하는 바와 같이 타당성과 유용성 모두에 대한 시험이 이루어져야 한다. Aza24 (대화) 16:00, 2021년 7월 9일 (UTC)[]
  • 지지하다. 작업을 훨씬 더 쉽고, 덜 위협적이고, 탐색하기 쉽고, 발견하기 쉬운 실수 등 - ReconditeRodent talk talk · 기여 » 01:41, 2021년 7월 12일(UTC)[]
  • 강한 지지 지옥 그렇다. 나는 우연히 마주치는 모든 신입들에게 구문을 강조하여 복음화한다. 그럴 필요가 없었으면 좋았을 텐데. 내가 이 사이트에서 경험해 본 가장 큰 QOL 개선 사항 중 하나는 -- 그리고 가장 필요한 사람들은 그것을 가지고 있지 않다. Vaticidalpropet 01:59, 2021년 7월 15일 (UTC)[]
  • 지지하다. 나는 항상 구문 강조표시를 사용하며, 편집이 훨씬 쉬워진다고 생각한다. 약간의 둔화를 벗어나면, 확실히 새로운 편집자들의 편집 능력을 해치지 않을 것이다.피톤코더(토크 기여) 11:32, 2021년 7월 16일 (UTC)[]
  • 기술적으로 구현하기에 사소한 것과 같이 모든 사람에게 디폴트로서의 지원은 모든 경우에 좋다. 구문 강조 표시가 없는 원시 텍스트 상자는 읽을 수 없다. RusingReader (대화) 11:41, 2021년 7월 16일 (UTC)[]
  • 지원 구문 강조 없이 편집하는 내 자신을 상상할 수 없다. 성능이 영향을 받는 경우는 매우 드물다.SD0001 (대화) 16:06, 2021년 7월 16일 (UTC)[]
  • 지원 비록 내가 직접 사용하지 않는 경향이 있지만 — GhostIn기계 17:18, 2021년 7월 16일 (UTC)[]
  • 다른 사람들이 지지하는 것과 같은 이유로 반대한다 - 버튼을 찾기 어렵기 때문이다. 기본적으로 구문 형광펜을 켰다면 새로운 모든 사용자들에게 어떻게 끄는지 아주 명확하게 알려야 할 것이다.(내가 이것을 끄려고 하는 새로운 편집자였다면 아마도 내가 제일 먼저 할 일은 "기본 설정" 메뉴로 가서 이미 선택되어 있지 않은 "syntax 형광펜"이라고 표시된 확인란이 발견되었으므로 나는 그렇게 결론을 내리겠다.내가 할 수 있는 유일한 것은 색상표를 바꾸는 것이다.) 이 제안서는 아마도 사용자의 첫 번째 편집에서 팝업으로 주의를 끌어서 토글을 찾기 쉽게 만들 필요가 있을 것이다. 이 경우, 토글을 원하지 않을 수 있는 사용자도 기본적으로 켜지 않고도 토글을 찾을 수 있는 이유는 무엇인가? DanFromAnotherPlace (대화) 20:13, 2021년 7월 16일 (UTC)[]
  • 아래 개정된 투표로 인해 반대되는 결과가 발생함 - Qwerfjkl (talk) 19:49, 2021년 7월 27일 (UTC). 이것은 모바일 2017 WikiText Editor(최소한 나에게는 그랬음)에서 끔찍하게 작용했고, 소스 편집기(Source Editor)를 사용하는 것이 거의 불가능하게 만들었다(실제 텍스트 몇 줄 편집에서 커서를 상쇄하는 것 같았다). -Qwerfjkltalk 14:52, 2021년 7월 22일(UTC)[]
    나는 구문 강조 표시 및 표시 없이 iPad에서 커서 오프셋을 얻는다. 키보드가 표시될 때마다 오프셋됨 - GhostInThetalk to me Machine 18:39, 2021년 7월 22일 (UTC)[]
    @Qwerfjkl, 어느 mw:에디터를 쓰고 있었나? mw:2017 Wikitext 편집기는 모바일 사이트에서 작동하지 않는다. Whatamidoing (WMF) (토크) 21:39, 2021년 7월 22일 (UTC)[]
    @Whatamidoing (WMF) 그렇다면 그것이 기본 모바일 소스 편집기였을 것으로 추측한다. 사용한 지 몇 달이 되었다. -Qwerfjkltalk 06:35, 2021년 7월 23일 (UTC)[]
    나는 모바일 위키텍스트 편집기가 구문 강조표시를 전혀 지지한다고 생각하지 않는다. 만약 당신이 모바일 기기에서 데스크톱 사이트를 사용하고 있다면, 당신은 2017년을 사용할 수 있었을 것이다.WTE, 그리고 예, 성능은 아마도 형편없을 것이다(예: phab:T197502). Whatamidoing (WMF) (토크) 18:23, 2021년 7월 23일 (UTC)[]
  • 나는 레비비치와 아자24에 동의한다. 나는 소스 편집을 쉽게 한다는 생각은 좋지만, 그 결과는 너무 추측적이다. 우리의 대형 기사에 히트한 성능은 비독점적이며, 어떻게 끄는지 알아내는 것은 어려울 수 있다. 이 조합은 실제로 새로운 편집자가 소스를 사용하여 편집을 완료할 가능성을 낮출 수 있다. 보유에 유의미한 이익이 있을지 여부도 궁금하다. 내가 보거나 함께 일하는 대부분의 새로운 편집자들은 시각적 편집기나 모바일 편집기를 사용하며, 그 효과를 보더라도 거의 보지 않을 것이다. 그들이 볼 수 있는 곳은 토크 페이지와 커뮤니티 페이지에서, 일반적인 크기, 시그너처 포맷 및 템플릿이 제공될 가능성이 더 높다. 나는 이 질문들을 조사하는 더 많은 작업을 지지하지만, 이것을 디폴트로 추진하기에는 너무 이르다고 생각한다. Wug·a·po·des 19:41, 2021년 7월 22일 (UTC)[]
  • 무조건 지지하다. 비주얼 편집기를 사용하지 않는 경우 이 기능은 반드시 있어야 한다. AXONOV (대화) ⚑ 21:55, 2021년 7월 22일 (UTC)[]
  • 지지하다. 나는 빅 기사에 대한 느리게 진행되는 성능에 대해 약간의 의구심을 가지고 있지만, 다른 모든 항목에서 구문 강조는 사용성과 보존에 있어 절대적인 이점이다(미컬러 위키텍스트는 사실상 읽을 수 없다). 실적 문제는 더 조사할 수 있지만, 막대한 이익을 감안할 때 기업 전체에 순 음의 영향을 미칠지 의문이다.고세이 (토크) 01:54, 2021년 7월 23일 (UTC)[]
  • 지지하다. 색상 코딩은 사용성에 큰 차이를 만들며, 그 이득은 어떤 단점보다 훨씬 크다. 마이클 매그스 (대화) 10:19, 2021년 7월 23일 (UTC)[]
  • 지원: 이 제안은 나 자신의 경험을 정확히 반영한다; 이것은 내가 일찍이 발견했더라면 좋았을 훌륭한 편집 보조책이며, 다른 사람들이 편집의 용이성을 바로 갖기를 바란다. 알83티토 (대화) 03:13, 2021년 7월 24일 (UTC)[]
    • 그리고 나는 새로운 사용자들이 원한다면 기능을 끌 수 있도록 가능한 한 버튼이 보이는 것을 전제조건으로 하는 것도 지지할 것이다.알83티토 (대화) 03:13, 2021년 7월 24일 (UTC)[]
  • 지원 — 이 기능에 대해 읽는 것은 이번이 처음인데, 와우 게임체인저다. 새로 온 사람들(그리고 나처럼 다소 경험이 많지만 느리게 편집하는 사람들)이 이것을 디폴트 세팅으로 하는 것은 엄청나게 도움이 될 것이다. 가장 편안의자 13:39, 2021년 7월 27일(UTC)[]
  • 기여에 대한 장벽을 상당히 낮추고 일반적으로 위키텍스트 편집을 훨씬 쉽게 하기 때문에 지원이 필요하다. 아래에서 성능 문제를 다루었는데, 큰 장애물로 보지 않는다. --Trialpears (토크) 16:46, 2021년 7월 27일 (UTC)[]
  • 강한 반대: 나는 지금 시험해 보고 위의 표를 수정하고 있다. 실제 구문 강조 표시는 도움이 되었지만, 편집을 매우 까다롭게 만들었기 때문에 텍스트 삭제를 초당 1자 정도로 늦췄다. 하지만 문자 위치 파악은 괜찮았다. -Qwerfjkltalk 19:47, 2021년 7월 27일(UTC)[]
    템플릿 추가 시에만 적용되는 겁니까, 아니면 다른 경우에도 적용되는 겁니까? 긴 페이지에 대한 나의 테스트는 단지 닫히지 않은 것 같았을 뿐이며 {{}}큰 둔화를 야기하는 것 같았지만, 그 경우에는 정말 나빴다. --Trialpears (talk) 11:46, 2021년 7월 28일 (UTC)[]
  • 지지 - 와우, 내가 몰랐던 훌륭한 도구가 얼마나 있는지. 토론을 읽고 직접 테스트해 본 결과, 편집자 유지에 있어 실질적인 혹이 발생할 수 있는 방식으로 가독성이 높아진다고 생각한다. 할 만해. 가네샤811 (대화) 04:58, 2021년 7월 29일 (UTC)[]

토론(동기세 강조 표시)

  • 기술적 측면에 대해서는, 만약 이것이 합의를 이룬다면, 나는 우리가 스스로 할 수 없다고 생각하므로 변경을 요청하는 페이브릭커 티켓을 제출할 것이다. 어디선가 간단히 스위치를 돌릴 수 있을 것이다. {{u Sdkb}} 19:09, 2021년 7월 5일(UTC)[]
  • 와우. 이 구문 하이라이팅에 대해 전에는 몰랐어. 나는 그 제안이 구문 형광펜 기구에 관한 것이었다. 나는 접근성에 익숙한 누군가가 이러한 얇은 글꼴, 연한 파란색, 연한 녹색의 색상이 문제가 되지 않을지를 평가해야 한다고 생각한다. 마리오곰 (토크) 18:19, 2021년 7월 6일 (UTC)[]
    나도 소식이야. 나도 한번 먹어봐야겠어. 나는 올해 이 기기를 잠시 사용하고 있었지만, 견딜 수 없는 부하 시간이 그것을 순 음성으로 만들어 비활성화했다. 아마도 (부끄러울 정도로 눈치채지 못했던) 툴바 버전이 훨씬 좋아져 sdkb의 제안을 지지할 수 있을 것이다. JohnFromPinckney (대화/편집) 18:27, 2021년 7월 6일 (UTC)[]
    @MarioGom 접근성에 대한 AA 대비 지침을 충족하도록 색상을 수정하였다(사진:T271895) 그러나 이러한 변경사항은 아직 실제로 여기에 배치되지 않은 것으로 보인다(사진:T280024). 나는 그 틈새로 미끄러지지 않도록 후자의 일을 부탁했다. wub "?!" 21:40, 2021년 7월 6일 (UTC)[]
  • ?@Sdkb: 내가 뭔가를 빠뜨리지 않는 한, 그런 전환은 선호가 아니지 않은가? 내가 묻고 싶은 것은 만약 그것이 선호도가 아니라면, "계정에 설정"할 것이 없기 때문이다. 즉, 영어 위키피디아가 기본적으로 사람들을 새로운 가치로 선택하도록 하는 것이 아니라 개발자들이 이 기능을 발명하여 사용자 선호 데이터베이스에도 통합하기를 원한다는 것을 의미한다. 또한, MobileFrontEnd(FYI에만 해당) — XaosfluxTalk 22:16, 2021년 7월 6일(UTC)[]에서는 이 기능을 사용할 수 없다고 생각한다.
    너는 아마 나보다 기술적인 면을 알고 있을 것이다. 내가 이해한 바로는 형식적인 의미에서 선호로 나타나는 것이 아니다. 하지만 소프트웨어는 켜거나 끌 때 기억나는 것 같으니 어디선가 추적하는 것이 있을 것이다. {{u Sdkb}}}talk 22:32, 2021년 7월 6일(UTC)[]
    내 서명 코멘트 입력: JS 해킹으로 현지에서 할 수 있을 것 같아 참고 항목: 테스트: [2][3] pref: [4]를 참조하십시오. RusingReader (대화) 22:47, 2021년 7월 6일 (UTC)[]
    @ProcrasingReader: 그래서 당신의 제안은 모든 페이지에서 그 버튼을 클릭하기 위해 자바스크립트 해킹을 실행하는 것이다. 하지만 이 제안서에 맞으려면 무엇이 필요할 것이다: 당신이 그것을 가지고 있지 않아야 하는 사람일 경우에 당신의 옵션 선호도를 추적하는 저장된 로컬 스토리지 아이템?xaosfluxTalk 23:12, 2021년 7월 6일(UTC)[]
    IP도 편집할 수 있고, 여전히 원할 때 IP를 끄도록 허용해야 한다는 점을 명심하십시오. 동일한 세션/브라우저/etc에 있는 동안 각 새 편집에 강제로 다시 적용하시겠습니까? 기본적으로, 나는 이것이 IP 편집자들을 위해 처리되어야 할 클라이언트 쪽 해킹을 추진하는 좋은 아이디어로 들리지 않는다고 말하고 있다.xaosfluxTalk 23:22, 2021년 7월 6일(UTC)[]
    거의 그렇긴 하지만, 어쨌든 IP 사용자들을 위해 노트 프리프는 저장되지 않는다. 또는 이 문서가 mw.user.options로 보이며 $wgDefaultUserOptions와 상관관계가 있음을 시사한다. 의사한테 있는 게 아니라 여기를 봐. 문서 설명에 따르면, 기본적으로 이미 사용 가능해야 한다. RowlingReader (대화) 23:47, 2021년 7월 6일 (UTC)[]
    IP에 의한 것이 아니라는 것을 알게 된 것은 사소한 일이었고, 단지 이 링크를 개인 브라우저 창에서 열고 보는 것이었다.xaosfluxTalk 23:54, 2021년 7월 6일(UTC)[]
    맞아, 그렇지 않아. 하지만 암호에 따라 달라져야 하니까 뭔가 이상해 보여. 확장 문서를 사용하면 기본적으로 이 기능을 켜는 해결책이 제공되지만, 이는 확장 코드와 AFAICS의 구성에서 키가 지나치게 강조되지 않는다. RowlingReader (대화) 23:57, 2021년 7월 6일 (UTC)[]
    후속 조치를 위해 IRC에 대해 논의한 후 확장 기능이 기본 설정의 기본값을 제대로 설정하지 않아 디폴트 기능이 비활성화된다는 것을 알게 되었다. Legoktm (토크) 08:38, 2021년 7월 7일 (UTC)[]
    기술적으로 새로운 계정에 대한 차이 선호를 설정하는 것은 쉬우며, 미디어위키는 그것을 지원한다. 보통 그렇게 되지 않는 이유는 그것이 이상한 경험을 만들어내기 때문이다. 예: "기본값으로 재설정"이 수행하는 작업, *사용자* 기본값으로 재설정되는지 아니면 모든 사용자의 기본값으로 재설정되는지 여부 이것이 사람들이 모르는 좋은 기능이라면, 나는 모든 사람의 디폴트를 바꾸되, 그것을 원하지 않으면 끄도록 직설적으로/원클릭하는 것이 이치에 맞는다고 생각한다. Legoktm (토크) 00:02, 2021년 7월 7일 (UTC)[]
    • 나는 CodeMirror 디폴트가 반드시 좋거나 나쁘다고 주장하려는 것이 아니다. 단지 이 제안이 핵심인 것처럼 보인다는 이유만으로, 개발자들에게 이것을 프로그래밍하기 위해 기능을 추가하는 것을 들여다보라고 요구하는 것은 어떠한 지역 사회의 합의도 필요하지 않다.xaosfluxTalk 23:24, 2021년 7월 6일(UTC)[]
      논의 내용을 보면 RFC가 다소 시기상조일 수도 있고, 실행 불가능한 결정이나 미흡한 결정으로 이어질 수도 있다. 나는 이 아이디어에 대한 지역사회의 지지를 측정하는 것이 여전히 유용하다고 생각하지만, 최종 결정은 아마도 다음과 같은 경우에 이루어져야 할 것이다.
      • 새로운 접근성 조정 색상표가 배치된다(사진:T280024) 그리고 우리 모두는 그것을 시험할 시간이 있다. 나는 이 아이디어를 지지하지만, 나는 현재의 색 체계가 지치는 것을 발견하고 있다.
      • 우리는 구현 경로와 그 결과에 대해 대략적인 아이디어를 가지고 있다.
      --마리오곰 (토크) 08:33, 2021년 7월 7일 (UTC)[]
      모든 지지에 내재된 투표는 "기술적으로 타당하다고 가정할 때 지지"이다. 만약 이것이 합의점을 얻는다면, 우리는 가짜 표를 만들어서 어떤 반응을 얻는지 볼 것이다. 하지만 그것에 대한 불확실성이 합의점을 평가하는 데 장애물이 되어서는 안 된다. 마찬가지로, 롤아웃되는 컬러 업데이트에 대한 지원을 조건화하고자 하는 사람은 누구나 환영한다. {{u Sdkb}}talk 07:47, 2021년 7월 10일(UTC)[]
      WMDE가 개발한 접근성 업데이트를 우리가 해도 괜찮다고 가정해 볼 수 있을 겁니다. 엄밀히 말하면 간단한 구성 스위치지만 그들의 동의가 필요할 것 같다. RusingReader (대화) 11:42, 2021년 7월 16일 (UTC)[]
  • 이거 나온 이후로 계속 쓰고 있어. 익숙해지려면 시간이 좀 걸리긴 하지만 꽤 도움이 된다. 나는 항상 그것을 켜둔다. 즉, 편집 페이지를 생성하는 동안 시간 초과(몇 분의 1초)로 인해 로드할 수 없는 경우가 많으므로 기본적으로 강조 표시가 없다. 어느 쪽 연결로 이런 일이 생기는지 모르겠다. 현재 내가 있는 호텔인가, 아니면 그 당시 서버들이 사용자 부하로 인해 어려움을 겪고 있는 것인가. 모두가 이것을 사용하고 있다면 시스템 및/또는 대역폭에 대한 배출량은 얼마나 될까? GenQuest 23:15, 2021년 7월 24일 (UTC)[]
  • 특정 바이트(예: 20만바이트)를 초과하는 페이지나 섹션에 있거나(a) 특정 네임스페이스(예: 토크 페이지)에 있을 때 강조표시 구문이 비활성화되도록 할 수 있는가? 이는 신참의 소스코드 편집을 용이하게 하고자 하는 사람뿐만 아니라, 큰 페이지/섹션의 실적 벌칙에 대해 염려하는 사람 모두를 만족시킬 수 있다. 판다케콕9 (토크) 14:51, 2021년 7월 27일 (UTC)[]
    그것이 페이지 로드를 의미 있게 늦춘다는 실질적인 증거는 없다. 느린 장치에 대한 성능 시간을 증거로 제시한 사람이 있는가? 아니면 그 주장에 대한 다른 형태의 증거라도? 그리고 솔직히, 만약 어떤 사람이 느린 장치에 있는 20만 자 페이지를 편집하려고 하고 있고, 섹션 단위로 편집하는 것을 사용하지 않는다면, 그것은 어쨌든 견딜 수 없을 것이다. RowlingReader (대화) 15:24, 2021년 7월 27일 (UTC)[]
    가장 긴 기사인 LGBT 캐릭터가 나오는 드라마틱한 TV 시리즈 목록(List of Stramic Television 시리즈: 2010년대, 528kb)에서 이 문제에 대한 테스트를 해봤다. 오펜드는 없지만 닫지 않은 템플릿이 있다면 속도를 늦출 수 있는 것은 없을 것 같다. 그 경우에는 참을 수 없을 정도로 느렸다. 아이슬란드와 같이 크지만 미친 듯이 크지는 않은 페이지에서는 183kb가 느리지만 관리할 수 있었다. 새로 온 사람들이 할 것 같은 정상적인 편집은 영향을 받지 않고 매우 긴 페이지에서만 속도가 특히 나쁠 뿐이라는 점을 고려하면, 나는 디폴트로 하이라이트를 하는 것이 의심할 여지없이 더 낫다고 생각한다. 아마도 몇몇 사람들은 매우 심각한 성능 문제를 가지고 있는 기기에 대해 생각하고 있을 것이다. --Trialpears (토크) 15:58, 2021년 7월 27일 (UTC)[]
  • 나는 이 타입의 편집자를 커먼스에 사용하고, 그것은 큰 도움이 되었다(내가 아무것도 하지 않고 나타났다. 동시에, 나는 영어 위키백과에서 이 기능을 어떻게 사용하는지 여전히 발견할 없었다. 내가 편집이 1.5k가 넘는 비교적 경험이 많은 편집자가 되었음에도 불구하고, 각각 평균 600바이트에 가까운 편집자가 되었다. 내 경험으로 볼 때, 나는 새로운 편집자들이 확실히 "강조된 구문" 편집기를 사용하는 것이 더 쉽다는 것을 알게 될 것이라고 말할 수 있다. 그러나 나는 누군가가 처음으로 편집기를 열 때, 파일을 하원에 업로드할 때 사용되는 것과 같이, 메시지를 영원히 비활성화할 수 있는 체크 표시 옵션과 함께, 다른 종류의 편집자와 그 사이의 전환 위치를 알려주는 메시지가 나타나야 한다고 생각한다. (현재 나는 대부분 지원 수준에 있다, 내가 나의 편집자를 만들 때 위에 투표할 것이다.) 최종 결정) 고마워! ---CX (/)hehim let's talk( ) 17:52, 2021년 7월 27일 (UTC)[]
  • 일반적으로 기본적으로 구문 강조 표시를 지원하지만 페이지 로드 시간과 관련이 없는 성능 문제가 다소 우려된다. 나는 합리적으로 현대적인 기계에 있지만, 구문 강조 표시가 활성화된 매우 큰 페이지를 편집할 때 편집이 손실된 적이 있다. 편집자는 때때로 속도를 줄인 다음 흰색 로딩 화면으로 가서 nev를 조정한다.회복된 물론, 이것은 대부분 "나"의 문제일 수도 있지만, 15분간의 일이 사라지는 것을 보는 것은 매우 좌절스러운 경험이 될 수 있다. (그래서 나는 몇 달 전에 점의 구문 형광펜을 기억하기 위해 전환한 것이다.) 많은 편집자들이 위키피디아에 접속하기 위해 약하게 작동하는 장치를 사용하고 있을 수 있다는 점을 유념하여, 나는 이러한 문제가 여전히 발생할 수 있다는 것을 배제할 수 있는 경우에만 디폴트로 이것을 가능하게 하는 것을 지지할 것이다. --Blablubs (대화) 10:24, 2021년 7월 28일 (UTC)[]
    이것은 분명히 나에게도, 심지어 짧은 기사에도 여전히 일어난다. -Qwerfjkltalk 11:34, 2021년 7월 28일(UTC)[]
    @Blablubbs와 @Qwerfjkl (그리고 다른 누구라도) @CX Zoom의 문제를 자동 활성화하지 않고 해결하는 '중간 만남' 접근법이 있을지 궁금하다. 구문 강조 표시에 대한 메모와 함께 나타나는 상자? Whatamidoing (WMF) (토크) 20:36, 2021년 7월 28일 (UTC)[]
    @XaosfluxLegoktm: 아마도 소프트웨어에서 그것이 가능한지 알고 있을 것이다. RusingReader (대화) 22:06, 2021년 7월 28일 (UTC)[]
    기술적으로 가능해야 할 것 같은데, 코드 에디터(JS/CSS/Lua 페이지에 대한 syntax 강조 표시)와 비슷한 것이 있는데, 툴바에서 클릭 한 번으로 끄거나 켜는 버튼이 있다. 나는 "Lossing large edit" 문제가 일반 위키텍스트 편집기에서 VE의 초안 기능을 구현하는 것이 더 나을 것이라고 생각한다. 레고크tm (대화) 03:43, 2021년 7월 29일 (UTC)[]
    나는 팝업 박스 접근에 강력히 반대할 것이다. 우리가 새로운 편집자 경험을 생각할 때, 우리는 그들이 포기하기 전에 건설적인 편집을 한 지경에 이르기를 원하기 때문에, 우리가 제시하는 정보가 무엇인지에 대해 극도로 선택적일 필요가 있다. 우리는 이미 그들에게 많은 중요한 것(예: 저작권 고지, 참고문헌 추가 요청)을 읽고 VE와 출처 사이에서 결정하도록 요구하고 있다. 그들이 클릭해야 하는 다른 상자를 추가하면 더미가 쌓이고 잠재적인 혼란이 야기된다(일부 사람들은 구문 강조 표시 기능을 켜는 것이 VE를 활성화하는 것이라고 생각할 수 있다). 나는 이 특별한 특징에 대해 설명하기 보다는 참조와 같은 핵심 개념을 전달하기 위해 그 귀중한 사전 편집 순간을 사용하고 싶다. 우리는 사람들이 오타를 고치려고 포괄적인 프로필을 만들도록 강요해서는 안 된다. {{u Sdkb}}}talk 18:35, 2021년 7월 29일 (UTC)[]
    나는 맨 처음에 팝업 공지가 일부 편집자들을 겁먹게 할 수 있다는 감정에 동의한다. 그러면 도움말에서 도움말 기사를 만들 수 있다.위키백과를 편집하는 다른 방법. 시간이 지남에 따라 편집자들은 다양한 편집 방법에 대해 더 많이 배울 것이다. 새로운 편집자에 대해서는 강조된 구문 편집기로 인사할 수 있다. 이와 관련된 일부 성능 문제가 있다고 하더라도 새로운 편집자들이 대대적인 편집을 할 것으로 기대해서는 안 된다. 숙련된 편집자의 경우 원할 때마다 전환할 수 있다. ---CX(/)hehim ( let's talk) 08:59, 2021년 7월 30일 (UTC)[]
  • 이에 따라 속도와 부하 시간이 얼마나 영향을 받는지에 대한 실제 데이터가 있는가? --에어랜드(토크) 05:28, 2021년 7월 29일(UTC)[]
    난 우리가 할 수 있다고 생각하지 않는다. 하지만 개인적인 경험으로 보아 위키 마크업이나 오류가 많은 페이지가 아니라면 로딩 시간의 차이는 무시할 수 있거나 존재하지 않는다는 것을 느꼈다. 단어가 많은 페이지는 로딩 시간에 큰 차이를 보이지 않는 것 같고, 나는 평균 인터넷 속도 이하인 반년 된 노트북을 사용한다. 내 노트북에는 210,000바이트가 넘는 이 대화 페이지의 편집 창이 기본적으로 바로 강조표시되는 구문을 로드한다. 그러나 24만 바이트가 넘는 라파엘 나달의 편집 창은 편집 창이 열린 후 구문 강조를 로드하는 데 추가적으로 1~2초가 소요되는데, 이는 아마도 기사에서 위키 마크업 양이 많기 때문일 것이다. 그렇더라도 편집 창은 구문 강조 표시가 비활성화된 것처럼 빠르게 로드된다. 가장 편안의자 04:28, 2021년 7월 31일 (UTC)[]
    @가장 편안한 의자 (개인 경험으로 알고 있는 바와 같이) 모바일 기기에서는 부하 시간이 현저하게 더 나쁠 수 있다./ -Qwerfjkltalk 11:22, 2021년 7월 31일 (UTC)[]
    편집 창은 휴대폰에 로딩하는 속도가 극도로 느리고 구문 강조 표시가 켜지지 않고 자주 충돌한다. 나는 이것이 특징인 줄 알기 전에 휴대폰으로 편집하곤 했으므로 구문 강조 표시가 그것을 더 악화시키는지 아니면 일반적으로 휴대폰의 편집 윈도우가 헐렁거리는지 확신할 수 없을 것이다. 가장 편안의자 12:24, 2021년 7월 31일 (UTC)[]
위의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

sdkb, 페이브 티켓 처리하시겠습니까? --Trialpears (대화) 09:25, 2021년 8월 4일 (UTC)[]

물론, 서류철: 사진: 사진:T288161. 어떻게 될지 두고 보자. {{u Sdkb}} 19:36, 2021년 8월 4일 (UTC)[]
나는 이 모든 논의를 놓쳤지만 성과에 관해서는 우리가 CodeMirror 6를 출시하면 내년에 크게 개선될 것이다. 다음 단계를 따르십시오.업데이트용 T259059. 뮤지크애니멀 16:26, 2021년 8월 5일 (UTC)[]

CleverBot Edit 요약 수정 제안

특정 제안: "[사용자 이름]에 의한 가능한 공공 기물 파괴 행위 재발급" 요약 내용을 "[사용자 이름]에 의한 편집이 허용되지 않음"(또는 다른 간단한 편집 요약)으로 대체하십시오. 자세한 내용은 다음과 같다.


우리 모두는 CleverBot을 사랑한다. 이것은 이 놀라운 기계다. 이것은 본질적으로 편집이 나쁜 때에 대해 항상 정확하다. 그리고 그것은 우리의 기사를 순찰을 하고 헛소리로부터 멀리하는 데 매우 도움이 된다. 기고문을 삭제하면 기고자 토크페이지에 친절하고 비기록적인 공지사항을 남긴다. 그렇다고 해서 절대적으로 완벽한 것은 아니며, 편집 요약이 개선될 수 있다고 생각한다.

잘 모르겠지만, 편집된 LevelBots 깃발의 95%는 반달리즘이다. 나머지 5%는 편집이 잘못되어 삭제될 가치가 있고 필요한 것이지만, 실제로 고의적인 파괴 행위는 아니다. 이러한 기물 파손이나 가능한 기물 파손으로 태그가 지정되어서는 안 된다(ClueBot은 항상 "[사용자 이름]에 의해 가능한 기물 파괴 행위 재발급"의 편집 요약을 남긴다). 별거 아니야, 선의로 수정해도 꽤 나쁘지만 절대적으로 이상적인 편집은 아니니까, 쉽게 바꿀 수 있다고 생각해. "[username]에 의한 편집이 허용되지 않음" 또는 "Reverting edit per MemberBot 알고리즘에 의한 편집" 또는 "vandalism"이라고 말하지 않는 것.

그래서, 사상 처음으로, 나는 MemberBot이 새로운 유망한 사용자들에 의해 편집된 내용을 되돌리는 것을 보았다.Franco tradisionle은 사실 꽤 괜찮다고 유포했다. 오타가 여러 번 있었는데(논문자는 ESL), 출처도 없고, 그 밖에 무엇이든지, 그리고 실마리봇이 촉발되었지만, 정보 자체는 위키 표준이었고, 함께 작업할 수 있는 새로운 사용자 편집의 종류였고, 함께 작업할 수 있는 편집자의 종류였다. 나는 그것에 대해 불평하는 것이 아니다. 사람들이 놀라운 것을 만들어 낼 수 있었다는 사실에 나는 당황했다. 그리고 그것이 더 자주 일어난다고 해도 나는 여전히 MemberBot의 팬이 될 것이다. 편집 요약을 말하는 거야.

그래서 이 한 가지 경우에서 새 편집자는 반달이라고 잘못 불렸고, 이것은 만약 '배달'을 포함시키기 위해 '상해'를 취한다면 로보틱스 제1법칙에 위배된다. (혹은 인간 동료의 '너 아마 병신일 가능성이 있다'보다 더 이상 별로 낫지 않은 반달은 정말 중립적이지 않다.) 이용자는 이에 놀라기도 하고 혼란스럽기도 하거니와 그녀가 속상해한다면 이해할 수 있을 것이다. 그래, 내가 아는 한 사람일 뿐이라는 것은 알지만, 그래도.

따라서 편집 요약을 좀 더 싱겁고 판단력 있는 것으로 변경해 달라고 청원할 수는 없을까? (그리고 단순히 어떤 행동을 기술하는 것이기 때문에, 95%가 아닌 100%의 시간을 수정해 줄 것을 청원할 수는 없을까? 내가 여기서 뭔가를 놓치고 있는 것인가, 아니면 이것이 걱정될 만한 가치가 있는가, 아니면 너무 많은 단점이 있는가? 어떻게 생각해? 헤로스트라투스 (토크) 20:05, 2021년 7월 19일 (UTC)[]

나는 "[username]에 의한 편집 재검증"을 더 중립적으로 말한다. "Edit not recepted"는 새로운 사람들이 CleverBot이 완벽하다고 생각하게 만들지만, 그렇지 않다. 숭어템플 (대화) 20:39, 2021년 7월 19일 (UTC)[]
당신의 편집이 너무 문제가 되어 되돌아가고 있다는 것을 로봇으로부터 들을 수 있는 좋은 방법이 없다. 새로운 편집자들은 ConverseBot이 무엇을 하는지, 그리고 왜 그것을 되돌릴 수 있는지 알 수 없을 것이다. 중요한 것은 상황을 설명하고, 그 상황에 대해 어떻게 해야 할지를 설명하는 곳으로 향하는 것이다. "Edit driggered a problebot; 편집자, 당신의 토크 페이지를 보고 설명을 하시오." 또는 유사한 Elemimele (talk) 20:54, 2021년 7월 19일 (UTC)[]
나는 사용자들이 왜 편집이 받아들여지지 않았는지 의문을 제기할 수 있는 것만큼 특별히 유용한 것은 아니라고 본다: 공공 기물 파손 혐의. 그래서 그것은 단지 반전에 혼란을 가중시키고 있을 것이다. Terasail[✉️] 00:12, 2021년 7월 20일 (UTC)[]

다른 사용자가 적어도 이 문제에 대한 다소 긴 토론을 볼 수 있도록 이 문제에 대한 이전 대화로 연결하십시오.

이 특정 메시징에 대한 구체적인 제안의 경우, "반복" 또는 "반복"이라는 단어를 포함하지 않으므로 반전을 식별하기 위해 요약 편집에서 이러한 특정 단어 중 하나를 찾는 다른 자동화된 도구에 문제를 일으킬 가능성이 있으므로 반대한다. -- Cobi(t c b) 00:40, 2021년 7월 20일(UTC)[]

좋아. "반전"을 포함시키는 것은 괜찮지만, 다른 로봇이 이해할 수 있도록 한 로봇은 "반달리즘"이라는 단어를 사용해야 한다는 말씀이시죠? 심지어 그것은 공공 기물 파손이 아니다. 그것이 아니었기 때문에, 5%의 시간. 로봇의 필요성은 가능한 한 환영할 필요가 있다고 생각하는가? 헤로스트라투스 (토크) 00:55, 2021년 7월 20일 (UTC)[]
아, 그리고 사람을 잊지 마, CleverBot도 사용자 토크 페이지에 글을 남겨. IERC 이 메시지는 괜찮다, 공공 기물 파손에 대해서는 언급하지 않고, 그것이 잘못되었을 수도 있다는 메모 등등. 아마도 토크 페이지 메시지에서 당신은 짧은 문자열에만 국한되지 않기 때문일 것이다. 그러나 기고자의 이름은 편집 요약에 링크되어 있기 때문에(그것이 되어야 함), 그 사람도 편집 요약에 끌려간다. "Edit reverted, your talk page"는 어때? 헤로스트라투스 (토크) 01:05, 2021년 7월 20일 (UTC)[]
  • 어떤 "수락되지 않은" 논문에 반대하라. 1) 이것은 편집이 출판된 적이 없다는 것을 암시할 수 있다. 2) 이것은 편집이 보통 어떤 종류의 수락 검토를 거치고 있다는 것을 암시한다. 그들은 그렇지 않다.Xaosflux 02:06, 2021년 7월 20일 (UTC)[]
  • 반대한다. 제안 사항들에 직접적으로 반대한다. 나는 당신이 어떤 형태의 괴롭힘으로 건너갈 때까지 로봇공학 제1법칙에 "성행"을 추가할 수 있다고 믿지 않는다. 그것은 확실히 ClebeBot의 능력이나 현재의 표현에 속하지 않는다. 1RR과 친근한 표현("허위 긍정? 고마워, 'CleumBot NG'), 'ClebeBot'은 최대한 친근하게 지내면서 제 역할을 하고 있다. 더군다나, 앞서 Cobbot Commons에 대한 토론에서 코비가 언급했듯이, 당신에게 다가와서 "가능성이 있는 병신"이라고 부르는 또 다른 사람이 여기서 사과를 오렌지에 비교하고 있다. 그것은 또한 모든 사람에게 같은 말을 하는 로봇에게는 적용되지 않는 심각성의 주요한 증가다.
이제, 내가 생각하기에 어떤 합리적인 사람도 불쾌하게 여기지 않을 것이라고 생각하는 표현들을 ConverseBot이 사용하는 것이 내 의견이다. "가능성 있는" 한정자는, 사람이든 봇이 하든, 되돌리는 것이 오류일 수 있다는 것을 암시한다. 이것은 내가 다른 어떤 애매한 상황에서 사용했던 것과 똑같은 쓰레기다 - 내 메일 클라이언트의 "피싱 가능성", 내 전화기의 "스팸 가능성", 비디오 게임에서 "부정 행위 금지". 이는 오류의 여지가 있음을 의미하며, 도움을 요청하거나 또는 추가 조치에 주의를 기울여야 함을 의미한다.
이 모든 것은, 내가 그러한 변화에 반대하는 주된 이유는 엄밀히 말하면 기술적인 것이다. 사소한 것까지도 바꾸면 누군가의 작업흐름이 깨질 이다. 다른 도구들은 CleverBot의 이러한 표현을 기대한다. 여기서 변화를 창출한다고 해서 기존의 문제로 보지 않는 것에 대해 순이익이 생기는 것은 아니다. -- SnoFox(t c) 07:32, 2021년 7월 20일 (UTC)[]
나의 원래 반대로부터 잊혀진 점: 메시지가 무엇을 담고 있어야 하는지에 대해서는, 로봇이 인간에게 왜 행동을 취하는지 알려주는 것이 중요하다고 생각한다. 제시된 대로 단순히 그 이유를 제거하는 것은 훨씬 더 큰 혼란을 야기할 것이다. 만약 당신이 ConverseBot에 익숙하지 않다면, 당신이 무엇을 했다고 생각했는지 정확히 명시하는 것보다 더 분명한 것은 무엇인가? 위키피디아는 그것에 대한 단어가 있다 - 그것은 공공 기물 파손이다. 우리는 그 용어를 사용해야지, 사탕발림하려 하거나 숨기려 해서는 안 된다. 현재 텍스트는 요약 편집에 관한 기술적 제한 사항을 고려할 때 간결하고 가능한 친근하다. -- SnoFox(t c) 07:55, 2021년 7월 20일 (UTC)[]
  • 여기서 제안된 두 단어 모두 반대한다. "수락되지 않음"이라는 문구는 편집이 받아들여질 수 있는 일종의 승인 과정이 있음을 부정확하게 시사하기 때문에 매우 혼란스럽다. 나는 또한 "토크 페이지 확인" 타입의 문구를 좋아하지 않는다. 왜냐하면 그것은 되돌리기가 왜 수행되었는지 그 이유를 모호하게 하고, 나는 그것이 페이지 역사를 따라가기 어렵게 만들 것이라고 생각하기 때문이다 - 10년 후에 당신은 더 이상 존재하지 않을 것 같은 메시지를 사람들에게 전달할 것이다. 봇에 의해 수행되고 있다는 것을 좀 더 분명히 하기 위해 메시지를 수정하는 것에는 어느 정도의 이점이 있을 수 있다고 생각하지만(아마도 거짓 긍정 보고서를 제출하기 위해 링크 이전에 "이 조치는 자동 컴퓨터 프로그램에 의해 수행되었는가?"와 같은 것을 덧붙인다) 그러나 나는 현재의 문구가 특별히 문제가 있거나 불쾌하다고 생각하지는 않는다.nsive. 192.76.8.91 (토크) 16:00, 2021년 7월 20일 (UTC)[]
아니 - LevelBot은 공공 기물 파손의 가능성을 분명히 한다. 핵심 단어일 도 있어 공공 기물 파손일 수 없다는 뜻이지만, 실마리봇은 통계적 추측만 하고 있다. 아심(토크) 02:27, 2021년 7월 22일 (UTC)[]
"[사용자]에 의한 리버스 편집: 비건설적" -Qwerfjkltalk 16:02, 2021년 7월 22일 (UTC)[]

임의 중단(ClueBot 편집 요약)

자, 봅시다. 이 시점에서...

  • 원래 제안서(나에 의해)는 "[username]에 의한 편집은 수락되지 않음"이었습니다.
  • 다음 편집기에서 "[username]에 의한 편집 재검증"(IMO가 더 낫음)을 제안함
  • 다음 편집자는 "Edit triggered a failure bot에 의해 탐지된 문제, 편집자, 설명을 위해 당신의 대화 페이지를 보라"고 제안했다. (이것은 IMO가 더 낫지만 가능한 길이 문제가 있다.)
  • 다음 편집자는 명확한 이유를 제공하므로 최신 정보("기물 파손 가능성")를 유지해도 괜찮다.
  • 다음 편집자는 "반달리즘"이라는 단어가 다른 로봇들의 이익을 위해 유지되어야 하기 때문에 최신 정보를 계속 유지해도 괜찮다.
  • 다음 편집자는 "승인되지 않음" 언어만 반대함(현재 상태에서는 정상인지 확실하지 않음)
  • 다음 편집자는 다른 로봇을 교란시킬 수 있기 때문에 최신 상태를 유지해도 괜찮다(또한 합리적인 사람이라면 "기물 파손 가능성"이라고 불리는 그들의 편집 내용을 신경 쓰지 않는다)
  • 다음 편집자는 현재를 유지해도 괜찮고, "이 동작은 자동 컴퓨터 프로그램에 의해 수행되었다"라고 덧붙이면 좋을 것이다.
  • 다음 편집자는 기본적으로 전류를 유지해도 괜찮다.

보기에도 예쁘지만, 큰 걸림돌은 다른 프로그램(또는 "워크플로우"에 포함된 다른 프로그램)이 차질을 빚을 것이라는 두려움이다. 사실이라면 크지만, 이게 정말 얼마나 클까? 물어보는 거야. 이러한 다른 프로그램 또는 워크플로우는 무엇을 하는가? 중요한 물건인가, 종이 흔들기인가? 얼마나 많은 편집 요약이 "반달리즘" 같은 단어를 포함하고 있는지 세어보면? 이는 "4월에 요약 편집 2.1%가 더 많이 '반달리즘'이라는 단어를 사용한다"와 같은 보도에 좋은 것으로, 그것은 괜찮지만, 그것은 단지 콩 세기에 불과하다.

나 자신은 되돌리기 버튼이나 반달리즘이라는 단어를 거의 사용하지 않는다; 나는 종종 이전 버전을 복구하고 손으로 쓴 설명을 하거나 "반달 시험 편집"을 사용한다. (여기에는 0이 아닌 수의 유용한 편집자들이 있는데, 그 편집은 반달리즘처럼 보이지만 아마도 당신이 정말로 기사를 편집할 수 있는지 시험하고 있었을 것이다.)그렇게 하고, 선의라고 가정하는 것이 좋다.) 그래서 어쨌든, 나의 리턴 편집 요약본에는 세계가 "반달리즘"이라고 해도 거의 포함되어 있지 않기 때문에... 내가 다른 로봇들을 망가뜨리는건가? 내가 사람들의 작업 흐름을 망치고 있는 건가? 그러면 안 될까? 그런 취지의 지침이 어디 있는가? (FWIW 위키백과:편집 요약 범례는 반달리즘 회전을 위한 "rvv"의 사용을 지지하는 것처럼 보이므로, 그 사람들과도 대화를 해야 할지도 모른다.)

아니면 이 다른 로봇들은 우리가 쓰는 고기가 아니라 다른 로봇들이 하는 일에만 신경을 쓸까? 글쎄, 왜? 이것은 촌스럽게 들리는데, 어떻게 끝나는지 모르십니까? (BTW 우리는 로보틱스의 제1법칙이 로봇이 당신을 폭행하는 것을 막고, 또한 "내 먼지를 먹어라, 터치홀"이라고 말하는 것도 막지 않을까? 나는 과학경찰이 그렇게 말할 것이라고 생각한다. 정서적 상처는 상처다.)

User talk의 편집자 "Revert"는 괜찮다.ConverseBot Commons/Archives/2017/12월#표준어로의 변경 제안은 "regex '/^revert/i'의 많은 도구 키"를 피했다. 이 키를 "regex '/^revert/i"로 유지하면 발생한 일에 대해 인간이 읽을 수 있는 순수하게 기술된 특성화로서 어쨌든 타당하다.

하여튼 여기서의 실제적인 문제가 무엇인지 생각하려고 안간힘을 쓰고 있다. 여기 좀 도와 주시겠어요? 기능을 위해 모욕의 사용이 필요중요한 로봇을 보여줘. 그걸 다시 쓰거나 분산시킬 수 없어. 그러면 내 주의를 끌게 될 거야. 헤로스트라투스 (토크) 15:45, 2021년 7월 22일 (UTC)[]

CleumBot NG 읽기는 여기여기다른 사용자들의 요약 편집. 그것은 분명히 LembeBot NG 자체로 업데이트 될 수 있지만, 이것은 이것이 다른 툴링에 대해 특별한 일이 아니라는 것을 보여준다. 위키피디아의 빠른 검색은 이 사용자의 모노북.js여기 있는 또 다른 키로 요약 메시지를 편집하는 것을 보여준다. 그러나, 이 데이터로 무엇을 하고 있는지 알 수 없다. 더 많은 것이 있다: [5] [6] [7] [8] 그리고 계속 검색결과를 뒤적거려도 계속 예시들이 나온다. 그리고 그것은 심지어 오프위키도 아니다. 오프위키 소스코드가 있는 툴이 수 톤에 달해 있고, 이것들도 확인이 필요할 것이다. -- Cobi(t c b) 04:28, 2021년 7월 23일 (UTC)[]
문제는 원본 포스터를 당신이 제안하고 있는 편집 요약본이 매우 모호해 보인다는 점이다. 그것은 이유 없이, 다른 편집자들에게 무슨 일이 일어나고 있는지 설명하는 것은 훨씬 덜 도움이 되고, 왜 그들의 편집이 되돌아가게 되었는지 이해할 수 없기 때문에 편집자를 혼란스럽게 할 것이다.
나는 "기물 파손 가능성"을 "비파괴성 편집 가능성"으로 대체하는 것을 선호하지만, 대부분의 경우 편집 요약은 매우 명확하다.
"2달러에서 1달러까지 가능한 공공 기물 파손을 재발급한다. 잘못된 긍정을 보고하시겠습니까? 고마워요. 단서봇 NG(Bot)"
전달된 메시지 또한 봇이 가끔 실수를 한다는 것을 매우 분명히 한다. 그리고 위키 크기의 경우, 나는 어떤 잘못된 긍정을 잡는 비용으로 공공 기물 파손을 되돌리는 데 봇을 갖는 것은 이해할 수 있다고 생각한다. 아심(토크) 21:49, 2021년 7월 22일 (UTC)[]
  • 반대한다. 항상 틀리게 될 몇 퍼센트의 CleverBot 편집이 있을 것이다. 그래서 편집 요약에 "가능성"이 포함되어 있지만, 95% (또는 그것이 무엇이든) 성공률이 충분하다. 이는 봇이 선이라는 극단적인 가정보다 선한 일을 하는 것에 대해 명확하지 않고 직접적이게 만드는 데 더 많은 단점이 있다. 믿음. {{u Sdkb}}00:06, 2021년 7월 23일 (UTC)[]
  • 반대 나는 그들의 감정을 상하게 할 수 있는 5%에 대해 아무런 문제가 없다. 95%의 정확한 플래그 지정은 허용 가능한 임계값을 훨씬 넘어섰다. 이것은 많은 논의 시간을 할애할 만한 문제가 아니다. GenQuest 22:53, 2021년 7월 24일 (UTC)[]
  • 반대한다. 무효한 반전은 명료하고 정확한 묘사를 갖는 것이 중요하다. 단서봇이 틀렸을 때 우리는 사람들이 단서봇을 이해하고 자신 있게 되돌리기를 원한다. 다양한 대안들은 사람들이 나쁜 단서봇 편집을 보고, 편집이 어떤 식으로든 합법적이거나 권위적이라고 가정하고, 그것을 만지면 안 된다고 믿는 심각한 위험을 야기한다. 설상가상으로, 연구는 설명되지 않은 회전이 새로운 사용자들에게 진짜 살인적인 것이라는 것을 보여주었다. 이 제안은 새로운 사용자들이 이해할 수 있는 이유 없이 편집이 받아들여지지 않기 때문에 무력감을 느끼면서 무심코 포기하게 할 것이다. 알제 (대화) 08:41, 2021년 7월 31일 (UTC)[]
  • 단서봇 NG의 과제 요약은 매우 분명하다: 반반달리즘을 빠르고 자동으로 탐지하고 되돌리려 하는 반반달 봇이다. 봇이 만든 편집 요약을 바꾸는 것은 아무것도 이루지 못하며, 더 많은 혼란을 초래할 뿐이다, IMO. 모든 파괴 행위는 비파괴적인 것이지만, 모든 비파괴적인 편집이 파괴적인 것은 아니다. 그래서 아니, 「건설적이지 않은」 제안도 효과가 없다.판다케코크9 (토크) 05:11, 2021년 8월 4일 (UTC)[]
  • 반대, 현재의 메시지는 괜찮다("가능한" 파괴주의"). 숨막힘(대화) 16:34, 2021년 8월 9일 (UTC)[]

사람들은 이전처럼 영어 위키백과에 대한 기사를 만들 수 없다.

이것은 있는 그대로의 비스타다. 새로운 옵션을 워크샵하려면 Idea Lab에서 논의를 시작하십시오.Xaosflux 13:54, 2021년 8월 10일(UTC)

다음의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

안녕 위키백과 사용자들!

사람들은 예전처럼 영어 위키피디아에 대한 새로운 기사를 만들 수 없다. 예를 들어, 먼저 존재하지 않는 기사를 작성하려고 할 때, 검색 섹션에 단어를 입력할 때 검색 결과가 있든 없든 페이지 하단에 "이 기사 시작"이 더 이상 빨간색으로 나타나지 않는다. 그리고는 브라우저에 관한 기사를 만들기 위해 단어의 예를 들어 두번째 때에 들어가는 부품:https://en.m.wikipedia.org/w/index.php?title=Wikipedia:New_user_landing_page&page=Donkervoort+10(Donkervoort에 대한 기사를 만들기 위해)이 탭 우리가 어음은 기사를 만들지만 creat지 않는 초안으로 그것을 만들어 내는 것으로 보인다.ei직접적 이전과 같은 기사를 작성하는 것과 같이 나타나는 옵션은 다음과 같은 단어의 일부를 입력할 때만 나타난다: https://en.m.wikipedia.org/w/index.php?title=Draft:Donkervoort_D10/editor/all&redirect=no# 또는 본문으로 리디렉션된 것보다 이전에 기사를 작성한 경우에만 나타난다. 우리는 초안 옵션을 제거하고 검색 탭에 존재하지 않는 글의 단어를 입력할 때 기사를 만들 때 빨간색으로 표시할 수 있는 옵션을 반환하고 또한 다음과 같이 브라우저에서 단어의 일부를 입력할 때 기사를 만들 수 있는 옵션을 반환하고자 한다. https://en.m.wikipedia.org/w/index.php?title=Donkervoort_D10/editor/all&redirect=no#은 이 옵션을 사용하여 돈커보트에 대한 기사를 작성할 때 초안으로 작성되는 것으로 나타난다.

감사 — SIDITJAUPI(대화 기여) 19:08, 2021년 8월 9일(UTC)[]에 의해 추가된 선행 서명되지 않은 논평

@SIDITJAUPI: 계정이 아직 확인되지 않음(10개 편집, 4일 등록) WP의 결과:ACPERM, 확인되지 않은 사용자는 메인 스페이스에서 직접 기사를 작성할 수 없다. 당신은 확인되거나 WP를 사용해야 한다.AFC. 늑장 판독기 (대화) 19:10, 2021년 8월 9일 (UTC)[]
이런 일은 없을 겁니다. ACPRM은 지역사회와 재단의 지원을 받는 몇 안 되는 사례 중 하나로, 사실관계와 목표는 광고를 포함한 비정부적 내용을 배제하는 것이다. 나는 OP가 그 이후로 양말퍼펫으로 막혔다는 것을 주목해야 한다.조금 푸른 보리 v^_^v 05:51, 2021년 8월 10일 (UTC)[]
위의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

Vital 아티클 템플릿을 토크 헤더

해야한다 {{Vital article}} 에 통합되다 {{Article history}}? ~ HAL333 21:03, 2021년 7월 23일 (UTC)[]

  • 대화 페이지의 잡동사니를 제한하기 위해 지명자로서 지원한다. 현재 Vital 기사 템플릿은 "이 주제는 레벨# 바이탈 기사입니다." ~ HAL333 21:03, 2021년 7월 23일(UTC)[]
  • {{}}}}}}{{{토크 헤더가 아닌}}}}}}의 합병을 제안하시는 겁니까? 만약 그렇다면 나는 네가 혼란을 피하기 위해 헤더를 바꿔야 한다고 생각해. 어느 경우든 나는 약간의 문제가 있지만 완전한 비스타로 보지 않는다. --트리얼피어 (토크) 21:20, 2021년 7월 23일 (UTC)[]
  • 나는 대부분의 경우 위키프로젝트배너쉘이 붐비는 토크페이지에서 이런 정보를 얻기에 가장 좋은 장소라고 생각한다. 사용자:전원(전원~엔위키, π, ν) 23:01, 2021년 7월 23일(UTC)[]
  • 지원 WikiProjectBannerShell 또는 Talk 헤더보다 이 방법이 더 적절하다고 생각하십시오. Hawkeye7 (토론) 00:06, 2021년 7월 24일 (UTC)[]
  • 논평 나는 그저 누군가가 "바이탈 기사"가 훌륭하고 잘 따르는 기준과 함께 의미 있다는 것을 나에게 납득시킬 수 있기를 바란다. 더그 웰러 통화 09:22, 2021년 7월 27일 (UTC)[]
나는 더그 웰러에 100% 동의한다. 중요한 기사를 고르는 것은 매우 제멋대로인 것 같고, 게다가 나는 목록의 가치를 더 이상 보지 못한다. 기병(토크) 23:17, 2021년 7월 27일(UTC)[]
  • 나는 작년에 아이디어 연구소에서 이것을 제안했다; SandyGeorgia는 그 당시 내가 그것에 반대하도록 설득하는 몇 가지 생각을 가지고 있었고, 아마도 이 토론에 관심이 있을 것이다. RowlingReader (talk) 00:10, 2021년 7월 28일 (UTC)[]
  • 위키프로젝트 배너 셸에만 추가하면 대화 페이지를 어지럽혀서는 안 된다. 나의 의견은 핑에 감사한다; 약 15년 동안 이런 노력이 오고 가는 것을 지켜보면서 형성된다. 이전의 많은 위키피디아 주제들이 기사를 중요도에 따라 분류하려고 시도했던 것처럼, 이것은 ...이다. 현재 인기 있는 위키프로젝트에 지나지 않아 다른 편집자 그룹의 다음 번 계획 반복으로 몇 년 안에 대체될 것 같다. (내가 편집하는 대부분의 영역에서도 선택이 항상 논리적이지 않다는 것이 명백하다.) 이것은 위키프로젝트 배너 셸에만 추가되어야 하며, 단지 길 아래 어딘가에서 대체될 가능성이 있는 또 다른 위키피디아 제목일 뿐이다. 나는 더그 웰러와 기병대원의 선택에 동의한다. 그 선택은 완전히 제멋대로인 것 같고, 실제로 그 어떤 것도 반영하지 않는 것 같다. (동일한 과거 프로젝트도 마찬가지였습니다. 그것은 단지 또 하나의 위키프로젝트가 그 배너 껍데기에 굴러들어간 것이 아니라, 토크 헤더나 기사 역사에 추가되어서는 안 된다. SandyGeorgia (토크) 19:03, 2021년 7월 28일 (UTC)[]
    • 나는 WPBS가 올바른 위치라고 나와 동의하는 사람과 논쟁하는 것은 싫지만, WP에 전화하는 것은 공평하지 않다고 생각한다.일시적이고 임의적인 프로젝트 VA. 사람들이 위키백과의 일부분(다양한 키위스 프로젝트는 모든 위키백과 - 적어도 모든 텍스트에 맞을 수 있음)이 있는 CD가 필요 없다는 것을 깨달은 후, 이것은 이전의 "CD" 프로젝트의 유일한 계승자다. 또한 적어도 비임의 경우 더 높은 중요도 수준이 반복적으로 선택되었다. 사용자:전원(전원~엔위키, π, ν) 23:55, 2021년 7월 28일(UTC)[]
  • 위에 언급된 다른 것들의 위키프로젝트 배너 셸추가하면 나는 Vital 기사가 유용하다는 것에 대해 에 동의하고 나는 그것을 직접 이용한다. Huggums537 (대화) 19:30, 2021년 7월 30일 (UTC) 파업 및 전환...[]
  • Sdkb의 코멘트당 반대. 또한, 나는 나의 이전 투표가 붕괴를 수반할 것이라는 것을 깨닫지 못했다. Huggums537 (대화) 14:18, 2021년 8월 9일 (UTC)[]
  • Comment I는 {{Vital 기사}을(를) {{Wiki ProjectBannerShell/sandbox}}에 통합했으며, 편집자는 몇 가지 예를 볼 수 있다. 만약 그런 식으로 폐쇄된다면 나한테 알려주면 내가 살아날 수 있어. 그렇지 않으면 {{기사 이력}}. — Wug·a·po·des 23:33, 2021년 7월 30일(UTC)[]
    @Wugapodes: 붕괴 속으로 옮길 수 있을까? RusingReader (대화) 19:38, 2021년 8월 6일 (UTC)[]
나는 붕괴로의 이전을 지지할 것 같다. 기병(토크) 13:06, 2021년 8월 9일(UTC)[]
  • 코멘트 나는 이 제안이 옳은 방향으로 생각하고 있다고 생각하지만, 궁극적으로 나는 지지할 수 없다. 활력 있는 기사 배너는 단지 하나의 작은 정보를 전달하기 위해 전체 배너를 차지하는데, 이것은 필요하지 않다. 특히 많은 활력 있는 기사들이 다른 배너를 많이 가지고 있다는 것을 고려한다면 특히 그렇다. 그러나 기사 역사의 일부가 아니어서 거기에 맞지 않으며, 위키프로젝트 배너로 전락하는 프로젝트와 같은 방식으로 주제 기반의 위키프로젝트도 아니다. 그것은 궁극적으로 무언가로 통합되어야 하지만, 나는 그것이 무엇이든지 아직 준비가 되어 있는지 확신할 수 없다. {{u Sdkb}}talk 15:06, 2021년 8월 3일(UTC)[]
    Sdkb, 에 대한 통합을 지원하시겠습니까? {{talk page header}} ? Sibbole() think 13:32, 2021년 8월 13일 (UTC)[]
  • 중요한 기사 목록이 단일 위키프로젝트의 도메인임을 감안할 때, 중요한 기사 배너는 표준 위키프로젝트 배너로 간주되어 다른 모든 관련 위키프로젝트 배너와 함께 위키프로젝트 배너 쉘 안에 배치되어야 하지 않는가? 기병(토크) 03:41, 2021년 8월 4일 (UTC)[]
    난 그렇게 생각하지 않아. 배너에 나열된 위키프로젝트는 모두 콘텐츠 프로젝트로서, 사람들은 "이 기사가 어떤 콘텐츠 영역에 관련되느냐?" "이 주제에 대해 알고 있는 다른 편집자를 어디서 찾을 수 있는가?"와 같은 질문에 답하기 위해 배너를 찾는다. 중요한 기사 고지는 전혀 다른 이유로 토크 페이지에 포함되며, 완전히 다른 질문인 "이 주제가 얼마나 중요한가?"에 답한다. {{u Sdkb}}talk 19:47, 2021년 8월 4일(UTC)[]
    위키프로젝트는 위키백과의 발전을 위해 함께 일하기를 원하는 사람들의 모임이다. 위키백과에서 함께 일함으로써 위키백과를 향상시키고자 하는 집단 역시 하나의 주제 영역에 대한 모든 것이 아닌 넓은 주제 영역을 파악하는 데 노력의 영역이 있다고 해도 위키프로젝트다. 위키백과를 참조하십시오.위키프로젝트 창간문헌, 내용영역도 좁지 않은 위키백과:위키프로젝트 디스컴비게이션은 모든 기사에서 위키백과의 개선에 초점을 맞추고 있다. WhatamIdoing (대화) 19:20, 2021년 8월 6일 (UTC)[]
  • 주로 반대한다. 왜냐하면 내가 알 수 있는 한 중요한 기사 프로젝트는 단지 몇몇 사람들의 우선순위 목록일 뿐이지, "토크 페이지 배너"의 중요성에는 미치지 못하기 때문이다. OTOH, 기사 이력 템플릿에 추가해도 괜찮아. 조조 유메루스 (토크) 19:43, 2021년 8월 6일 (UTC)[]
  • 반대해. 그대로 둬. 중요한 기사에 대한 나의 개인적인 의견은 그것들이 우리의 가장 중요한 기사들이 무엇인지에 대한 아주 대략적인 아이디어를 얻기 위해 여러 곳에서 사용되는 다소 유용한 지표라는 것이다. 거기서 내린 결정은 지표로서가 아닌 기사 공간, 즉 실제로 메인 페이지에서 일어나는 일에 결코 영향을 미쳐서는 안 되지만, 나는 문제의 기사가 선정되었다는 것을 나타내는 작은 토크 페이지 배너를 갖는 것은 괜찮다고 생각한다.아마쿠루 (토크) 13:24, 2021년 8월 13일 (UTC)[]

탐색 템플릿의 WikiProject 링크

많은 네비게이션 템플리트에는 템플리트 하단의 비기사 내용에 대한 링크가 포함되어 있다. 여기에는 유용한 범주, 포털, 개요 등이 포함될 수 있으며, 제거해서는 안 된다. 이 코멘트 아래 {{캐나다군 항공사령부 부대}}의 대표적인 예.

나의 관심사는 위키프로젝트를 포함한 이러한 연결에 관한 것이다. 왜냐하면 이것들은 명백히 MOS와 모순되기 때문이다.문서를 나타내는 링크에서 문서 네임스페이스 외부의 페이지에 연결하지 마십시오. 이 페이지들은 독자가 마주보는 것이 아니므로 기사에는 들어가지 말아야 한다.

사용량이 많은 만큼 약 3만4000여 건이 영향을 받는 것으로 추산하는데, 스타일 매뉴얼에 명백히 반대하더라도 철거에 대한 공감대가 형성되도록 하는 것이 최선이라고 생각했다. WT:LINK, WT:CLN템플릿 대화:Navbox 통지 --Trialpears (대화) 16:01, 2021년 7월 8일 (UTC)[]

  • Wiki 프로젝트가 독자를 대면하지 않기 때문에 위키백과 대상 링크 제거 지원. -- Asartea 16 Contribs:08, 2021년 7월 8일(UTC)[]
  • @Trialpears:, 나는 당신의 추리에 동의하지 않는다. 이러한 링크가 MOS를 위반한다고 생각되는 경우:링크, 다음 MOS:링크는 명확히 할 필요가 있다(글에서 링크에 대해 이야기하고 있는 것이 분명하다고 생각하지만). 우리는 일상적으로 템플릿을 통해 비-아티클과 연결된다. 예를 들어, 우리의 정리 템플릿은 모두 그렇게 한다. 대부분의 탐색 상자에는 (템플릿 네임스페이스로 이동하는) 자체 링크가 있다.쿠스마 (대화) 16:13, 2021년 7월 8일 (UTC)[]
    도매 철거에 반대하다. 당신의 예에서, 나는 그 링크가 무의미하다고 생각하지만, 당신이 여기에 제시하지 않은 34,000개의 기사에서 그렇게 하는지 확신할 수 없다.쿠스마 (대화) 16:15, 2021년 7월 8일 (UTC)[]
    쿠스마 아마 인라인 링크에 대한 당신의 생각이 맞을 겁니다. 정책/기타 페이지를 찾을 때 설정되는 확인 편향을 추측하십시오. 내가 예상한 리스트는 특별했다.WhatLinksHere/File:일반적으로 메인 스페이스에 있는 링크 외에 배치된 아이콘을 사용하는 People_icon.svg. 그것은 전혀 완벽한 목록은 아니지만 토론하기에 충분할 것이다. 위키프로젝트 링크가 도움이 될 만한 사례를 제시해 주시겠습니까? 나는 이 토론을 시작하기 전에 몇 십 페이지의 페이지를 확인했는데, 그 모든 페이지들은 위에 나와 있는 것과 아주 적은 효용성으로 비슷했다. 본질적으로 모든 템플릿 편집과 마찬가지로, 이러한 변경도 완전히 자동으로 수행되지 않고, 적절한지 확인하기 위한 인적 검토가 있어야 한다. --Trialpears (토크) 16:28, 2021년 7월 8일 (UTC)[]
    나는 현재 링크가 존재하는 구체적인 예를 염두에 두고 있지 않다(Template에 있는 소규모 프로젝트에 대한 Wiki Project 링크를 원할 수 있다).닥터 후) 그러나 일반적으로 우리는 우리 프로젝트의 협력적 성격을 보여주는 것에 개방적이어야 하며, 독자를 무대 뒤 영역으로 초대할 수 있는 네비박스나 유사한 링크를 갖는 것을 고려해야 한다. 대부분의 포털(연결이 가능한 다른 독자들을 향한 우리의 다른 네임스페이스)이 요즘 쇼케이스로만 전시되고 있다는 점에서, 위키피디아 주제와 추가로 연결되는 것은 어느 정도 일리가 있다.(포털이 위키프로젝트와 훨씬 더 통합되고 우리의 가장 훌륭한 작품을 전시하는 것보다 훨씬 더 협업에 중점을 두는 것이 좋겠지만, 아마도 나는 소수자에 속할 것이다. 심지어 포털에 대해 여전히 관심을 갖고 있는 20명의 사람들 사이에서도 말이다.쿠스마 (대화) 16:37, 2021년 7월 8일 (UTC)[]
  • 한가지 우려는 우리의 위키피디아 주제들 중 많은 부분이 본질적으로 빈사상태라는 것이다. 우리는 정말로 독자들에게 빈사상태의 프로젝트 페이지를 지적하고 싶은가? 블루보어 (토크) 17:34, 2021년 7월 8일 (UTC)[]
    • 좋은 지적이야, 우린 정말 이러면 안 돼. Aza24 (토크) 16:04, 2021년 7월 9일 (UTC)[]
  • 마지못해 하는 지원. 특히 {{윌리엄 셰익스피어}}이나 {{리차드 바그너}} 같은 좀 더 구체적인 템플릿에 대해서는 위키프로젝트와 연계한다는 발상이 마음에 들지만, Wiki프로젝트의 시대는 정말 당분간 사라지고 있으며, 일반적으로 연계하는 것은 아마도 순 부정적일 것이다. Aza24 (토크) 16:04, 2021년 7월 9일 (UTC)[]
  • 카테고리 및 포털은 모두 독자를 대상으로 하므로, 나는 네비게이션 템플리트에서 카테고리와의 연결을 허용하지 않는 것에 반대한다. 나는 위키프로젝트와의 연결을 허용하지 않는 것을 지지한다; 그것은 단지 적절한 일이 아니다. {{u Sdkb}}} 07:53, 2021년 7월 10일(UTC)[]
  • 범주 및 포털에 대한 링크 제거에 강력히 반대하며, 이는 탐색 템플릿의 내용을 보완한다. 던컨힐 (대화) 08:07, 2021년 7월 10일 (UTC)[]
    @SdkbDuncanHill: 나는 카테고리, 포털, 그리고 다른 독자들이 페이지를 마주하는 것이 좋은 링크라는 것에 전적으로 동의하며, 단지 위키프로젝트 링크만 제거하기를 원하지 않는다. 이 점을 분명히 하기 위해 당초의 진술을 약간 수정했다. --Trialpears (대화) 08:18, 2021년 7월 10일 (UTC)[]
  • 쿠스마 당 강력한 반대. 일부 템플릿의 가치가 낮은 링크도 있을 수 있지만, 이를 논의하는 곳은 개별 템플릿 수준에서 도매로 법제화하려 하지 않는다. Thryduulf (대화) 11:52, 2021년 7월 10일 (UTC)[]
  • 내게 포털은 전반적으로 (독자와 유지보수의 편집자에게) 낮은 가치로 보이지만, 나는 그것이 또 다른 논의라고 생각한다. 위키프로젝트 링크는 아마 좋은 것 같아. RusingReader (대화) 12:14, 2021년 7월 10일 (UTC)[]
  • 아자24 슈리두울프 당 강력한 반대. 이것은 2021년에 만들어진 MOS의 또 다른 나쁜 편집이다. 우리는 항상 파일, 포털, 카테고리에 연결되어 있다. MOS:DraftNolink는 드래프트 공간과의 연계를 금지하기로 되어 있었다. 대신 MOS에서 제거하도록 제안하십시오. Hawkeye7(토론) 12:19, 2021년 7월 10일 (UTC)[]
    호크아이7 혹시 우리가 서로 오해하고 있는 건 아닐까? 우리는 파일, 포털, 카테고리에 항상 연결되어 있고, 나는 우리가 계속 그렇게 해야 한다고 생각하지만, 위키프로젝트 링크는 그렇게 하는 것이 적절하다고 생각하지 않는다. 또한 Aza24는 그들의 발언을 당신의 코멘트와는 상당히 동떨어진 "유감적인 지지"라고 표현했다. --Trialpears (대화) 12:24, 2021년 7월 10일 (UTC)[]
    웁스. 잘못된 사용자. 정답. 우리는 항상 그랬고, MOS에도 불구하고 계속 그렇게 해야 한다. 나는 당신의 제안이 기사의 이미지를 금지하는 MOS보다 더 제한적이라는 것을 이해하지만, 나는 이 접근법을 지지하지 않는다. Hawkeye7(토론) 12:35, 2021년 7월 10일 (UTC)[]
    나는 여전히 MOS에 강하게 반대한다.LINK, 그리고 따라서 그것에 기초한 어떤 행동도 나는 위키피디아 제목에 대한 링크가 독자가 대면하는 것이 아니라 편집자를 향한 것이라는 스필브릭과 블루보어의 주장을 수용한다. 그러나, 나는 모든 탐색 템플릿이 위키백과나 토크 페이지가 아닌 기사 페이지에 있다는 것을 확신하지 못한다. 호크예7(토론) 20:47, 2021년 7월 10일 (UTC)[]
    위키백과, 도움말 및 템플리트 네임스페이스에 사용할 수 있는 상당한 양의 탐색 상자가 있지만, 근거가 적용되지 않기 때문에 삭제해서는 안 된다. 만약 누군가가 토론에서 (예를 들어 위 또는 ER에서 했던 것처럼) 내비게이션 박스를 사용한다면, 나는 거기에 링크를 가지고 있어야 할 이유를 보지 못하지만 기사에서는 그렇지 않다. 기술적으로는 가능하지만 본질적으로는 아무런 이득이 없는 혼란의 원인이 될 것 같다. --Trialpears (대화) 21:50, 2021년 7월 10일 (UTC)[]
    이것을 포함하여 거의 모든 페이지에 적어도 한 장이 있다. 호크예7 (토론) 21:29, 2021년 7월 12일 (UTC)[]
  • 참고… 위키피디아 제목은 대개 TOKK 페이지에 링크되어 있다. 이것은 위키피디아 주제가 "독서자 지향"이 아니라 "편집자 지향"이기 때문에 적절하다. 블루보어 (토크) 13:10, 2021년 7월 10일 (UTC)[]
    따라서, 나는 위키백과 주제에 대한 링크를 기사 공간에서 삭제하는 것을 지지하지만, 그것이 제안된다면 대화 페이지에서 삭제하는 것에 반대할 것이다. 블루보어 (토크) 20:06, 2021년 7월 22일 (UTC)[]
  • 부분 반대 MOS를 한 번 보면:Layout, 당신은 우리가 기사의 요소를 4가지 그룹으로 정의한다는 것을 볼 수 있다: 기사 내용 이전의 1개, 기사 내용 2개, 부록 3개, 최종 4개. 기술적으로 네비게이션 템플리트는 네 번째 그룹의 일부여서 기사의 일부분이지만, 기사에서 기사 네임스페이스 외부 연결 금지를 읽을 때, 많은 사람들이 두 번째 그룹인 기사 내용에 중점을 둔다고 생각할 것이다. 만약 독자가 기사 내용을 읽는 도중에 링크된 항목을 우연히 발견한다면, 그 링크가 링크된 항목에 대해 더 자세한 내용을 담고 있는 다른 기사로 그들을 데려올 것이라고 기대하는 것이 타당하다. 하지만, 그들은 그 링크가 그들을 카테고리 목록이나 포털로 데려온다면 놀랄지도 모른다. 이와는 대조적으로, 기사의 하단에 있는 경우, "카테고리" 또는 "포털"이라는 링크가 있는 네비게이션 템플리트를 볼 경우, 카테고리 목록이나 포털로 가져오는 것에 놀라지 않을 것이다. 는 대부분의 독자들이 최소한의 놀라움이라는 원칙을 환기하면서, 기사 내용에 포함된 범주나 포털 목록에 대한 링크를 발견하면 놀라지 않을 것이라고 생각한다. 그러나 항해 템플릿에서 그것을 보는 것은 전혀 놀라지 않을 것이다.
    당초 내 생각은 단순히 이 제안에 반대하고 표시된 대로 내비게이션 템플릿을 받아들이는 것이었지만, 위키프로젝트를 다르게 처리해야 한다는 sdkb의 지적에 설득력이 있다. 일반적으로 포털에서는 나보다 위키백과 과목에서 더 많은 가치를 발견하지만, 포털은 독자를 마주하고 있는 반면, 위키백과 과목은 편집자를 지향하는 경향이 있기 때문에, 나는 우리가 기사 토크 페이지에서 위키백과 과목을 언급하는 것이 그러한 링크의 더 나은 위치라고 생각한다.--S Philbrick (Talk) 13:12, 2021년 7월 10일 (UTC)[]
  • 이것에 관한 오래된 RFC가 있다... 위키피디아 주제의 전부가 삭제되었다.목시-14Maple Leaf (Pantone).svg:24, 2021년 7월 10일 (UTC)[]
  • 모든 새로운 편집자들이 독자로 시작되었다고 상상하는 것을 보면, 독자들에게 특정 분야에 관심이 있는 사람들을 지원할 수 있는 인프라가 있다는 것을 알리고, 따라서 이들을 해당 위키백과 커뮤니티로 끌어들이는 데 가치가 있다고 생각한다. 말하자면, "위키프로젝트"라고 이름 붙여진 링크가 그렇게 하는데 좋은 방법인지 잘 모르겠다. 나는 많은 사람들이 그것이 무엇을 의미하는지 이해하지 못할 것이라고 의심한다. 사용자:성장 팀의 MMiller(WMF) (잘 모르는 사람들을 위해, 위키백과:Growth Team 기능에는 현재 개발 중인 기능에 대한 정보가 포함되어 있음) 새로운 편집자가 독자로 방문한 페이지를 토대로 관심 있는 커뮤니티를 찾기 위해 새로운 편집자를 안내하는 데 조사가 있었는지를 알 수 있다. 아이작 (토크) 21:26, 2021년 7월 10일 (UTC)[]
  • 반대론 우리는 항법 박스에 대한 전면적인 재사상이 필요하다; 그들은 1990년대 웹 분위기를 가지고 있는데, 그것은 반드시 정확하지는 않다. 비록 그들의 현재 사용에는 확실히 이점이 있다. 현상으로서, 만약 사람들이 "위키 프로젝트" 링크를 알아차릴 정도로 주의를 기울인다면, 나는 그것이 해로운 것으로 보지 않는다. 사용자:전원(전원~엔위키, π, ν) 21:30, 2021년 7월 10일(UTC)[]
  • 지지대 제거. 나는 위키프로젝트에 연결하는 것이 독자들에게 이로운 경우를 확실히 상상할 수 있지만, 그것이 템플릿의 토크 페이지가 특히 다수의 위키프로젝트에 유용할 수 있는 것이다. 위키프로젝트가 너무 모호하게 광범위하게 진행되는 프로젝트도 많이 있는데, 예를 들어, 캐나다 위키프로젝트가 이 예에 열거되어 있어 매우 유용하지 않거나, 비활용적이어서 부정적인 경험이다. 위키프로젝트/포털을 다시 생각해야 한다고 생각하지만 네비게이션 템플리트가 그것이라고 생각하지는 않는다. 슈슈가(토크) 16:16, 2021년 7월 11일 (UTC)[]
  • Navigate 템플릿(및 더 일반적으로 메인 스페이스 기사), nom 및 위의 기타 항목에서 위키백과 주제에 대한 링크를 제거할 수 있도록 지원하십시오. 레비비치 19:33, 2021년 7월 11일 (UTC)[]
  • 지지하다. 여전히 활성화되어 있고 원하는 특정 Wiki Projects가 기본값이 되지 않는 한 주요 페이지에 링크를 유지할 수 있지만 기사 공간에서 홍보할 가치가 없는 추가적인 혼란. - ReconditeRodent « talk · 기여 » 01:41, 2021년 7월 12일(UTC)[]
  • 지명당 Wiki Project 링크 제거 지원 위키프로젝트가 독자들에게 유용한 상황은 보이지 않는다. 위키프로젝트는 편집자를 위한 것이므로 편집자 중심의 페이지에 머물러야 한다. 톨톡 기여 04:20, 2021년 7월 12일 (UTC)[]
  • 반대 — 이것은 독자들을 편집자로 초대하는 방해가 되는 방법처럼 느껴진다. 네비박스에는 V T E: View Talk Edit가 있고, 페이지마다 편집 버튼이 있듯이, 콘텐츠 카테고리는 편집 커뮤니티에 가입할 수 있는 작은 방법이 있어야 한다. 이제 문제의 위키프로젝트에서 그들이 어떤 내용을 게재하는가에 대해서는, 개선해야 할 것이 많다.(무엇을 위해서인지, 나는 또한 우리가 비고문인 바닥글에 수많은 물체를 가지고 있기 때문에 정당성으로 인용된 MOS법률화에 대해 적극적으로 적대감을 느낀다.)---카르윌 (대화) 19:42, 2021년 7월 16일 (UTC)[]
  • 반대 - 이것에 대해 Carwil의 의견에 대체로 동의한다. 나는 위키프로젝트가 독자를 대면하지 않는다고 말하지 않을 것이다. 이들 중 다수는 신입들이 특정 영역에서 편집에 대한 생각을 갖도록 돕는 자원 제공은 물론 기사를 찾고, 기사를 쓰는 방법을 이해하는 데 유용한 도구를 제공한다. 이는 예를 들어 ANI나 스팸 블랙리스트 또는 새로운 사용자를 환영하지 않는 다른 페이지와 상당히 다른 것이다. 물론 위키프로젝트도 항상 포함되어야 한다는 말은 아니다. Wiki Project가 최소한 반능동인지 또는 유용한 랜딩 페이지가 있는지 여부에 기초해 보십시오. \\ 21:12, 2021년 7월 16일 (UTC)[]
  • 가 일반적으로 생각하기에 약한 사람들은 우리가 독자들을 더 많은 편집 과정을 보기 위해 초대해야 한다고 생각한다. 엘리 (토크 기여) 00:50, 2021년 7월 19일 (UTC)[]
  • 강한 반대 - 이 링크는 위키피디아의 이해와 편집에 관여하는 사람들을 초대하는 방법이다. Portal: 링크도 제거하시겠습니까? 아마도 MOS는 기사 텍스트의 비기사 링크를 더 이상 사용하지 않도록 수정되어야 할 것이다(현재 주제에 관한 유익한 기사를 작성하려는 의도를 방해하는 경우). 적절한 위키백과는 다음을 허용한다.위키백과 제목 및 포털: 기사 제목, 사이드바, 네브박스 및 기타 지원 인프라에 있는 링크, 사용자가 주제를 더 폭넓게 탐색하도록 권장하고, 아마도 직접 참여하도록 유도하는 링크.--Verbarson (대화) 09:06, 2021년 7월 19일(UTC)[]
  • 로도덴드라이트, 아이작, 그리고 Spilbrick의 MOS에 대한 논평의 첫 단락에 반대한다.레이아웃. — Wug·a·po·des 19:47, 2021년 7월 22일(UTC)[]
  • 강력한 지원 – 메인 스페이스 네비게이션 템플리트는 공개적이고 위키프로젝트는 그렇지 않다. 독자들이 편집 과정에 더 많이 참여하도록 장려하는 것이 유용할 수 있지만, 위키프로젝트 링크는 대부분의 위키프로젝트들이 사용되지 않고 있다는 점을 감안할 때 특별히 유용한 방법은 아니다. (Wiki Projects를 되살리는 것이 유리할 수 있지만, 그러한 노력은 적극적인 편집자로부터 시작되어야 할 것이다.) 그리고 사용자의 99.9%까지 이용이 불가능한 링크를 항법 템플릿에 포함시키는 것은 단지 형편없는 설계일 뿐이다. 207.161.86.162 (토크) 23:20, 2021년 7월 22일 (UTC)[]
  • 반대: 과장된 이유로: 이것은 독자들을 편집자로 초대하는 명백한 방법처럼 느껴진다. 어쨌든 가장 흥미롭고 세밀한 독자들만이 그들을 주목하게 될 것이다. 또한 대량 제거는 각 Navbox가 개별적으로 평가될 가능성을 부정한다. 간단히 말해서 제거의 부정적인 면이 비제거의 긍정적인 면을 능가한다. 만약 어떤 조치가 취해진다면, 스타일 매뉴얼을 다듬는 것이 될 것이다. 감사합니다. 알83티토 (토크) 03:06, 2021년 7월 24일 (UTC)[]
  • 강력하게 반대 – 위의 다른 사용자 및 WP에 대해서도:IAR. 나는 이러한 링크를 탐색 템플릿에 포함시키는 것이 독자들에게 관련 위키프로젝트를 소개하고 새로운 편집자를 모집하는 좋은 방법이라고 생각한다. 새로운 독자들이 이러한 링크들 밖에서 위키프로젝트를 배우거나 찾을 수 있는 다른 방법은 사실상 없다. 나는 이 링크들을 제거하면 그들이 그 프로젝트에 이득이 될 수 있는 것보다 장기적으로 더 많은 해를 끼칠 것이라고 생각한다. 많은 위키프로젝트들이 비활동과 사용자 유지 문제로 어려움을 겪고 있으며, 이는 위키프로젝트들에게 또 다른 장애물이 될 것이다. 그리고 WP의 문구가 다음과 같은 경우:MOS는 아마도 정책 페이지가 이것을 분명히 허용하도록 수정되어야 한다는 것 보다는 이슈다. 우리는 수년 동안 이 일을 사실상 전혀 문제없이 해왔고, 나는 WP를 엄격하게 읽었다고 해서 요령을 바꿀 이유가 없다고 본다.MOS. 또한 WP:IAR이 존재한다. 규칙이 우리가 사이트를 개선하는 것을 방해한다면, 우리는 그것을 무시해야 한다. 그리고 필요하다면 그것을 수정하라. LightandDark2000 🌀 (토크) 22:10, 2021년 7월 24일 (UTC)[]
  • Support Project 링크는 상기의 많은 사람들에 의해 강조된 바와 같이 다른 짐승이다. 위키피디아 주제 링크는 대화 페이지에 있는 일상적인 독자에게만 표시되어야 한다. GenQuest 14:12, 2021년 7월 25일(UTC)[]
  • 반대 Wiki프로젝트는 특정 주제에 대한 기사를 찾거나 해당 영역에서 새로운 사용자가 편집할 수 있도록 도와주거나 도움을 주는 데 모두 유용하다. 기존의 편집자들이 관심을 가질 만한 새로운 위키프로젝트를 찾는데 도움을 줄 수 있다고 나는 주장한다. 리마고서 09:04, 2021년 7월 28일 (UTC)[]
  • Wikipedia 제목 링크 제거 지원. 그것들은 독자를 대면하는 페이지가 아니므로 기사 페이지에 나타나서는 안 된다. 조금만이라도 Nav-템플릿-클러터를 줄이는 것도 바람직하다. 일부 반대론에 대해서는, 나는 사람들이 뒤죽박죽을 엿보고 우리와 함께하기를 바란다는 일반적인 생각에는 동의하지만, 나는 위키피디컬 링크가 방법이라고 생각하지 않는다. 알제 (대화) 07:54, 2021년 7월 31일 (UTC)[]
  • 가 위키프로젝트 케미컬을 처음 발견했을 때를 기억한다. 그 후, 나는 그것을 다시 찾을 수 없었다. 나는 토크 페이지(새로운 사용자를 위해 숨겨져 있다 - 보통은 코멘트가 기사 뒤에 있다), 또는 다른 이름 공간 등에 대해 몰랐다. Christian75 (대화) 15:32, 2021년 8월 1일 (UTC)[]
  • 이것은 WP의 좋은 예다.IAR 사용. 확실히, 이건 MOS의 문제야.네비게이션 템플리트가 아닌 링크. 기사 본문에서 그렇게 노골적으로 위키프로젝트와 연결되는 것도 아니다(MOS:링크는 정신적으로 예방하고 싶은 것 같다.) 만약 독자들이 그러한 링크를 찾는다면, 그들은 단지 독자로만 머물지 않고 편집자가 될 가능성을 이미 가지고 있을 가능성이 가장 높다. 우리는 그들이 잠재력을 발휘할 수 있도록 도와야 한다. 판다케콕9 (대화) 05:18, 2021년 8월 4일 (UTC)[]
  • 반대 나는 전적으로 지지할 것을 기대하면서 이것을 읽기 시작했다. 하지만 템플릿에 있는 그 링크는 너무 멋지고 눈에 띄지 않으며, 실제로 위키백과 주제가 되는 MILHIST 입니다. 나는 이것이 사례별로 결정되어야 한다고 생각한다. 그리고 그것이 MOS와 충돌하는 정도까지.링크, MOS:링크는 이 용도가 아니라 변경되어야 한다. 나는 비활동/마진적으로 활성화된 위키피디아 주제에 연결하는 것에 반대한다. 그것을 어떻게 정의하느냐에 대해서는 잘 모르겠지만 그것이 현지화된 토론의 목적이다. 칼리오페젠1 (대화) 22:13, 2021년 8월 10일 (UTC)[]
  • 비독자 대면 페이지로 Wiki Project 링크 제거 지원. Per Alsee, 그리고 다른 사람들. Mathglot (대화) 22:00, 2021년 8월 14일 (UTC)[]

MOS 가이드라인 개정 제안 방법

안녕 동지들. 나는 MOS 지침의 특정 단락에 대한 짧은 추가를 제안하고 싶다. 그 지침과 실천요강의 호환성에 대한 논의에 뒤이어. WP를 찾았다.제안, 그러나 그것은 정말 실질적인 정책/지침 제안을 다루는 것 같다. MOS Para에 소량 추가를 제안하는 올바른 절차는? 감사 DBD 12:38, 2021년 8월 17일 (UTC)[]

해당 MoS의 Talk 페이지에서 올려보셨나요? 도니아고 (토크) 13:49, 2021년 8월 17일 (UTC)[]
거기서 사전토론이 벌어지고 있었다. 그렇다면 새 섹션을 시작하는 절차가 올바른가? 템플릿이나 태그도 없고, 뭐라도 있어? DBD 16:21, 2021년 8월 17일 (UTC)[]
개정 내용의 규모와 다른 편집자들이 어느 정도 에스컬레이션이 필요하다고 느끼는지에 따라 달라질 수 있지만(즉, MoS를 편집하기 전에 당신의 개정에 대한 합의를 얻음), 나는 토크 페이지에서 제안된 MoS에 대한 변경사항을 제안하지 않았거나 쉽게 해결된 우려에 직면하고 편집한 적이 있다. 나중에 문제가 생길 경우를 대비하여 실제 편집하기 전에 적절한 시간(5-7일이 좋다)을 부여해야 한다는 의견이 일치하는지 확인하십시오. 이것이 도움이 되기를! 도니아고 (토크) 17:02, 2021년 8월 17일 (UTC)[]
그거 정말 도움이 되네. 감사 로드 DBD 18:26, 2021년 8월 17일(UTC)[]

표시하려면 누르십시오...

수학 및 물리학 기사에 방정식을 표시하는 탭은 극도로 짜증난다. 끊임없이 두드리지 않고는 기사를 읽는 것이 불가능하다. 그냥 방정식이나 보여줘 2600:1700:3f7a:66a0:ec58:294e:5e43:7f52 (토크) 14:54, 2021년 8월 16일 (UTC)[]이(가) 추가되지 않은 이전 의견

이것은 iOS에서 MediaWiki와 관련된 문제다. 지금은 데스크톱 사이트로 전환할 수 있다. 2600:100F:B125:3055:FDBC:91B8:8484:BD84 (대화) 18:49, 2021년 8월 17일 (UTC)[]

스팸 블랙리스트에 google.com/url 추가

아무 것도 없어요.

실제로 google.com/url은 이미 글로벌 블랙리스트에 의해 차단된 상태지만, 이는 URL이 보이는 URL로 구문 분석된 경우에만 트리거된다. image=템플릿 파라미터나 <노위키> 태그 내에 https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv=dQw4w9WgXcQ을 추가하는 것을 막지는 않는다. 이미 블랙리스트에 올라있기 때문에 마감.알렉시스 재즈 (이나 핑) 14:47, 2021년 8월 22일 (UTC)

다음의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

기술적으로 스팸메일은 아니지만 유튜는 스팸메일은 아니다.글로벌 m:스팸 블랙리스트에 있는 google.com/url은 나쁜 이미지 삽입에 주로 사용되며, [9][10][11][12][13][14][15][16], 때로는 잘못된 링크를 삽입하는 데 사용된다. [17][18][19]. 자세한 내용은 검색을 참조하십시오. 추가하기를 제안한다. google\.com\/url MediaWiki로:잘못된 편집을 방지하기 위한 스팸 블랙리스트.알렉시스 재즈 (Talk or ping me) 10:38, 2021년 8월 22일 (UTC)[]

다른 URL을 프록시 처리하고 블랙리스트의 regexes를 우회하는 데 사용할 수 있는 URL을 차단하는 것이 타당하다. 나는 이것을 사용할 어떠한 합법적인 필요성도 생각할 수 없다. 만약 정당한 필요가 있다면 누군가가 나를 깨우쳐 줄 것이다. HighInBC 10:42, 2021년 8월 22일 (UTC)[]
  • 제안자로서의 지원.알렉시스 재즈 (이나 핑) 11시 30분, 2021년 8월 22일 (UTC)[]
  • 이것은 구현되기 전에 기존 링크의 정리가 필요할 것이다, 그렇지 않은가? 조조 유메루스 (토크) 11:45, 2021년 8월 22일 (UTC)[]
    조조 유머러스, 그건 사실 문제가 아니라 스팸 블랙리스트의 영향을 받는 라인만 추가/변경된다. 그래서 이것을 블랙리스트에 추가한다고 해서 이미 그런 링크가 포함된 기사를 편집하는 것을 막을 수는 없다. 정리는 필요하지만 google.com/url을 블랙리스트에 추가하기 위한 전제조건은 없다.알렉시스 재즈 (Talk or ping me) 12:42, 2021년 8월 22일 (UTC)[]
그래서 많은 물건들은 실제로 정비 봇에 의해 처리되지 않는다. {{nobots}} 블랙리스트 차단 페이지 저장으로 인한 지시사항. IMO는 시간이 지남에 따라 더 많은 손상을 입히고 예방한다. 기존 사례가 제거됐다면 블랙리스트를 추가해 새로운 것을 막는 것이 최선일 것이다. -- GreenC 14:21, 2021년 8월 22일(UTC)[]
  • IMO에 반대하라, 블랙리스트를 없애야 한다, 확대해서 블랙리스트 문제를 더 악화시킬 것이 아니다. 북8000 (대화) 13:42, 2021년 8월 22일 (UTC)[]
위의 논의는 종결되었다. 수정하지 마십시오. 이후 코멘트는 해당 토론 페이지에서 작성해야 한다. 이 논의는 더 이상 수정해서는 안 된다.

외국어 인터페이스 메시지

모든 외국어 인터페이스 메시지(예: MediaWiki:남용 필터-허용되지 않음/해제)? 다음 중 하나를 선택하십시오.

  • 모든 외국어 메시지 보관 또는
  • 모든 외국어 메시지 삭제 또는
  • 일부는 보관하고 다른 일부는 삭제

MFD의 후속 조치다. MFD는 메시지는 유지하되 마을 펌프의 입력은 넓히기로 합의했다. 대학 때문에 계속 미루다가 이제야 토론을 해야 할 때가 된 것 같다. 아심(토크) 22:53, 2021년 7월 18일 (UTC)[]

MFD에서 논의된 페이지의 전체 목록(편리하게 제공)
MediaWiki:오용필터-허용되지 않음/삭제 (토크 내역 링크 감시 로그 편집)
MediaWiki:기사단원/그 (토크 내역 링크 감시 로그 편집)
MediaWiki:인용오류/es (토크 내역 링크 감시 로그 편집)
MediaWiki:인용오류/pt-br (토크 내역 링크 감시 로그 편집)
MediaWiki:빈 참조 정의/정의 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:빈 참조 정의/fr에 오류 인용 오류 (토크 내역 링크 감시 로그 편집)
MediaWiki:빈 참조 정의/pt-br의 인용 오류 (토크 내역 링크 감시 로그 편집)
MediaWiki:참조가 없는 오류 그룹 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:참조/fr이 없는 오류 그룹 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:참조/pt-br 없이 오류 그룹 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:인용 오류 포함 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:인용 오류 포함 ref/fr (토크 내역 링크 감시 로그 편집)
MediaWiki:인용 오류 포함 ref/pt-br (토크 내역 링크 감시 로그 편집)
MediaWiki:링크 레이블 그룹이 없는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:링크 레이블 그룹/fr이 없는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:링크 레이블 그룹/pt-br이 없는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:입력/입력 없음 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:입력/fr 없음 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:입력/pt-br 없음 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:키/이 없음 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:키/fr을 참조하지 않는 경우 (토크 내역 링크 감시 로그 편집)
MediaWiki:키/pt-br 없음 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:숫자 키/에 대한 참조 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:숫자 키/fr을 참조하는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:숫자 키/pt-br 참조 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:너무 많은 키/에 대한 참조 오류 발생 (토크 내역 링크 감시 로그 편집)
MediaWiki:너무 많은 키/fr을 인용 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:너무 많은 키/pt-br을 인용 오류 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:오류 참조 그룹 불일치/에 대한 인용 오류 (토크 내역 링크 감시 로그 편집)
MediaWiki:오류 참조 그룹 불일치/fr 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:오류 참조 인용 그룹 불일치/pt-br (토크 내역 링크 감시 로그 편집)
MediaWiki:잘못된 매개 변수/es를 참조 (토크 내역 링크 감시 로그 편집)
MediaWiki:잘못된 매개변수/fr을 참조하는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:잘못된 매개변수/pt-br 참조 인용 오류 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 그룹/에 대한 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 그룹/fr을 참조하는 오류 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 그룹/pt-br의 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 키/에 대한 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 키/fr에 대한 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:누락된 키/pt-br에 대한 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:백링크 레이블이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:백링크 레이블/fr이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:백링크 레이블/pt-br이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:오류 참조 인용 키/이 없음 (토크 내역 링크 감시 로그 편집)
MediaWiki:키/fr이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:키/pt-br 없음 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:텍스트가 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:텍스트/fr이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:텍스트/pt-br이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:참조/nl이 없는 오류 참조 인용 (토크 내역 링크 감시 로그 편집)
MediaWiki:연락처/코 (토크 내역 링크 감시 로그 편집)
MediaWiki:접점/접점 (토크 내역 링크 감시 로그 편집)
MediaWiki:연락처/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:접촉/욱 (토크 내역 링크 감시 로그 편집)
MediaWiki:내용/코 (토크 내역 링크 감시 로그 편집)
MediaWiki:내용/플 (토크 내역 링크 감시 로그 편집)
MediaWiki:내용/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권/코 (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/ar (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/삭제 (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/es (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/fr (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/it (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/자 (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/nl (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/플 (토크 내역 링크 감시 로그 편집)
MediaWiki:저작권 경고/루 (토크 내역 링크 감시 로그 편집)
MediaWiki:피처링 콘텐츠/디 (토크 내역 링크 감시 로그 편집)
MediaWiki:피처링 콘텐츠/fr (토크 내역 링크 감시 로그 편집)
MediaWiki:피처 콘텐츠/코 (토크 내역 링크 감시 로그 편집)
MediaWiki:피처링 콘텐츠/플 (토크 내역 링크 감시 로그 편집)
MediaWiki:피처링 콘텐츠/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:가젯-HotCat/de (토크 내역 링크 감시 로그 편집)
MediaWiki:가젯-팝업.js/de (토크 내역 링크 감시 로그 편집)
MediaWiki:히스테르젠드/fr (토크 내역 링크 감시 로그 편집)
MediaWiki:교호작용/de (토크 내역 링크 감시 로그 편집)
MediaWiki:상호 작용/코 (토크 내역 링크 감시 로그 편집)
MediaWiki:교호작용/플레 (토크 내역 링크 감시 로그 편집)
MediaWiki:상호작용/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:라이센스/ko (토크 내역 링크 감시 로그 편집)
MediaWiki:목록 파일-요약/de (토크 내역 링크 감시 로그 편집)
MediaWiki:노이미지/데 (토크 내역 링크 감시 로그 편집)
MediaWiki:Permalink/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:보호 텍스트/es (토크 내역 링크 감시 로그 편집)
MediaWiki:수정인포/de (토크 내역 링크 감시 로그 편집)
MediaWiki:Sharedupload-desc-여기/de (토크 내역 링크 감시 로그 편집)
MediaWiki:Sharedupload-desc-여기/nl (토크 내역 링크 감시 로그 편집)
MediaWiki:Sharedupload-desc-here/no (토크 내역 링크 감시 로그 편집)
MediaWiki:Sp-공헌-풋어-아논/nl (토크 내역 링크 감시 로그 편집)
MediaWiki:Sp-contractions-footer-anon/nl-informal (토크 내역 링크 감시 로그 편집)
MediaWiki:Sp-공헌-풋어/nl (토크 내역 링크 감시 로그 편집)
MediaWiki:Sp-공헌-발가락/nl-정보 (토크 내역 링크 감시 로그 편집)
MediaWiki:토크페이지링크텍스트/nl-정보 (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-n-정보 사이트/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-n-접촉/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-n-콘텐츠/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁 n-기능 콘텐츠/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-t-permalink/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-t-recentchangeslinked/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:툴팁-whatlinkshere/pt (토크 내역 링크 감시 로그 편집)
MediaWiki:uctop/nl-informal (토크 내역 링크 감시 로그 편집)
MediaWiki:업로드 텍스트/fi (토크 내역 링크 감시 로그 편집)
MediaWiki:업로드 텍스트/루 (토크 내역 링크 감시 로그 편집)
MediaWiki:Wikimedia-copyright/pt (토크 내역 링크 감시 로그 편집)
나 자신을 인용하는 것으로 시작할 것이다. 위키백과별:Miscellany_for_deletion/MediaWiki:노기사 텍스트/es영어 위키피디아로서 기여하는 사람들이 영어를 제대로 구사할 수 있을 것으로 예상되기 때문에 [외국어]개인화된 메시지를 갖는 것은 전적으로 무의미하다. 요약하면: 이 프로젝트에 기여하기 위해서는, 당신은 우리가 거기에 넣는 모든 영어 시스템 메시지와 정책을 이해할 수 있는 충분한 영어 구사력이 있어야 하며, 이 메시지들을 번역하는 것은 아마도 영어를 잘 하지 못하는 사람들이 그들의 일에 기여하기 보다는, 이 프로젝트에 기여하도록 격려할 것이다.n 언어 위키백과는 문제없이 유창하게 한다. 아심(토크) 22:56, 2021년 7월 18일 (UTC)[]
또한 MFD에 참여한 유저들을 예의 바르게 @Papery @Xaosflux @Zoozz1 @Godsy @Davey2010 @Kusma @Elli.
그리고 이전 MFD: @SmokeyJoe @Robert McClenon @Gioguch Aasim (토크) 23:14, 2021년 7월 18일 (UTC)[]

조사(외국어 인터페이스 메시지)

  • 위키백과에서 내 코멘트에 대한 사례별:삭제용 miscellany/MediaWiki:오용필터-허용되지 않음/삭제xaosfluxTalk 00:12, 2021년 7월 19일 (UTC)[]
    • 뛰어들기를 원하지 않는 사람을 위한 예는 다음과 같다. 페이지가 있어, 미디어위키:인터페이스 언어를 engb로 설정한 사용자에게 표시되는 blockedtext/engb. 이제 우리는 정말로 여기서 이 언어를 사용하는 것을 권장하지 않는다. 그러나 만약 이 페이지가 우리의 사용자 지정된 메시지를 보는 대신에 삭제되었다면 그들은 미디어위키 기본값을 얻게 될 것이다. 우리는 확실히 en=> engb의 모든 메시지에 대해 이것을 하는 것이 아니라, 우리가 하는 가장 중요한 메시지에 대해서 한다. 이 기능은 MediaWiki와 같이 매우 인기 있는 언어를 사용하는 편집자에게 표시되는 특정 기본 메시지에도 유용할 수 있다.오용필터-허용되지 않음/삭제xaosfluxTalk 10:10, 2021년 7월 19일(UTC)[]
      @Xaosflux 내가 묻는 것을 네가 오해한 것 같다. 나는 영어 방언 현지화가 아닌 외국어 인터페이스 메시지에 대해 묻고 있었다. 이는 미디어위키가 다음과 같은 의미일 것이다.blockedtext/engb는 이 논의의 범위에 포함되지 않는다. 아심(토크) 02:25, 2021년 7월 22일 (UTC)[]
      @Awesome Aasim: 그렇더라도, 여전히 케이스 바이 케이스. 이것들이 쓸모없을 수 있는 경우가 분명히 있지만, 그러나 당신이 이 토론을 열어본 주요 샘플은 확실히 유용할 수 있는 예다. 인터페이스 세트를 가진 우리의 편집자(예: 교차 프로젝트 편집자)가 없다면 우리의 지역화된 버전을 볼 수 없겠지만, 대신에 미디어위키는 디폴트(default)가 될 것이다.xaosflux 09:43, 2021년 7월 22일 (UTC)[]
  • 가장 많이 보관하십시오. 이러한 항목은 삭제하는 것보다 보관하는 것이 더 유용해 보인다. 엘리 (토크 기여) 00:41, 2021년 7월 19일 (UTC)[]
  • 케이스 바이 케이스. 그룹으로 판단하기에는 너무 다양한 품질과 유용성의 인터페이스 메시지가 너무 많은 경우. 예: 번역되지 않은 다양한 저작권 경고 메시지는 그 상황에서 영어 메시지는 아마도 기본 번역 메시지보다 더 나쁠 것이지만, 내용 메시지는 양호하고 미디어위키 디폴트가 없기 때문에 삭제되어야 할 것이다. 192.76.8.91 (대화) 03:38, 2021년 7월 19일 (UTC)[]
  • 사용자의 선택 언어로 지역화된 Wiki UI(페이지 헤더, 바닥글, 사이드바 등)에 시각적으로 통합된 항목을 대부분 보관하십시오. 사람들은 그들이 선택한 어떤 사용자 언어로도 위키 인터페이스를 사용할 수 있다. 영어를 유창하게 사용하지 못하는 것과 아무 상관이 없다 – 예를 들어, 나는 가끔 내 모국어 독일어를 포함한 수많은 다른 위키피디아에서 손님으로 편집해 왔지만, 대부분의 위키피디아에서는 순수한 습관 때문에 여전히 영어로 인터페이스를 유지하고 있다. 이 로컬로 가능한 UI에 통합될 enwp 전용 문자열을 가지고 있다면, 이러한 문자열을 지역화해야 한다. 물론 우리는 Mediawiki가 지원하는 모든 언어로 번역되는 것을 약속할 수는 없고, 그것을 이루기 위해 거꾸로 굴하지 말아야 한다. 하지만 만약 우리가 이미 그러한 번역들을 가지고 있다면, 그것들을 유지해서 일부 방문객들에게 더 나은 사용자 경험을 유지하는 것은 어떤 해로움이 될까? 나는 기사 내부의 메타데이터의 일부로서 표시되어야 하는 것, 예를 들어 그러한 모든 "cite error" 구성요소에 대해 덜 확신하고 있다. Fut.Perf. 10:40, 2021년 7월 19일 (UTC)[]
  • 모든 을 기본값으로 유지하라, 외국어로 하는 것은 일반적으로 그들을 지켜야 할 이유들이다. (여기서 영어를 잘 읽지 못하는 사람들이 참여해야 할 많은 이유들) MFD를 사용하여 외국어 인터페이스 메시지 이외의 이유로 인해 문제가 되는 개별 페이지를 토론하십시오.쿠스마 (대화) 10:49, 2021년 7월 19일 (UTC)[]
  • MfD의 개별 토론에 대한 편견 없이 다른 특정 이유로 인해 문제가 있는 경우 모든 을 기본적으로 유지하십시오. 단순히 외국어로 된 것 자체가 삭제의 이유가 아니다. Thryduulf (대화) 11:09, 2021년 7월 20일 (UTC)[]
  • 모두 보관 – 위키백과 또는 영어 위키백과는 다른 자매 프로젝트는 말할 것도 없고 300개 이상의 다른 위키백과가 포함된 위키미디어 우산 아래 더 큰 프로젝트 커뮤니티의 일부분이다. 위키백과:위키미디어 자매 프로젝트는 다음과 같이 말한다.
    위키피디아는 위키피디아 기사에서 자매 프로젝트에 관한 페이지까지의 연계를 장려하고, 그러한 연계가 가능할 때마다 위키피디아의 외국어 판에 관한 기사에 상호 연동한다.
게다가, 환영 위원회는 또한 그들의 영어가 여기 기고하는데 충분하지 않을 때 새로운 사용자들을 그들만의 언어로 다룰 수 있는 도구들을 가지고 있다; 여기 리스트가 있다. 이 두 경우 모두 이 경우와는 전혀 다르지만, 그럼에도 불구하고 영어 위키피디아가 다양한 상황에서 다른 언어의 스피커를 환영하려는 의도가 분명하며, 그런 정신에서 이 경우도 예외가 되어서는 안 된다. Mathglot (talk) 01:11, 2021년 7월 22일 (UTC)[]
  • 삭제해야 할 특별한 원인이 없는 한 모두 보관하십시오. 나는 가끔 외국어로 된 위키피디아에 방문할 이유가 있었다. 지역 언어에 대한 지식이 필요 없는 다양한 종류의 값진 편집이 있다. 가능한 많은 인터페이스를 읽을 수 있다면 도움이 된다. 알제 (대화) 08:02, 2021년 7월 31일 (UTC)[]
  • 그들에게 특별한 문제가 없다면 모두 보관해라. 아래 Whatamidoing에 의해 상세히 기술된 바와 같이, 만약 우리가 메시지를 삭제한다면, 그 인터페이스 언어를 가진 사용자들은 대개 영어 메시지를 볼 수 없을 것이고, 그들은 그들의 언어에 대한 MediaWiki를 기본값으로 볼 것이다. MediaWiki:위키백과에 대한 오용 필터 허용 안 됨/삭제 링크:사용자 정의된 영어 버전 MediaWiki와 같은 필터/거짓 긍정 편집:오용필터 금지. 만약 우리가 그것을 삭제한다면 독일어 인터페이스를 가진 사용자들은 translationwiki를 보게 될 것이다.MediaWiki:독일어로 번역된 번역wiki:MediaWiki:사용자에게 관리자에게 문의하도록 지시하는 남용 필터 사용 안 함. 우리는 사용자가 그렇게 하는 것을 원하지 않는다. 기본 MediaWiki 메시지는 모든 MediaWiki 설치에 대해 기록되므로 로컬 Wiki 페이지를 연결하지 않고 로컬 정책과 기능을 언급하지 않는다. 우리는 기존의 번역을 삭제하는 것이 아니라 우리의 중요한 맞춤화들을 공통 언어로 번역해야 한다. 프라임헌터 (대화) 22:27, 2021년 7월 31일 (UTC)[]

배경(외국어 인터페이스 메시지)

어떤 이야기가 회자되고 있는지 모르는 사람을 위해:

사용자 인터페이스에 있는 모든 작은 텍스트 조각(즉, 기사가 아니라 버튼에 있는 단어 같은 것)을 "시스템 메시지"라고 부른다. 그것들은 거의 항상 원래 영어로 쓰여져 있고, MediaWiki 소프트웨어 코드에 삽입되어 있고, 그리고 나서 별도의 웹사이트인 TranslateWiki.net에서 번역된다.

예를 들어, 당신이 편집을 할 때, 당신의 변경사항을 저장하는 큰 파란색 버튼이 있다. 당신은 아마도 "변경 게시"라고 쓰여 있는 단추를 보는 데 익숙할 것이다. 버튼의 텍스트는 MediaWiki:라는 MediaWiki 메시지에 저장된다.변경 사항을 게시하십시오. 언어 기본 설정을 영어로 특별으로 설정한 경우:환경설정을 선택하면 "변경사항 게시"가 나타난다. 만약 당신이 당신의 언어 선호도를 다른 것으로 설정한다면, 당신은 그 언어에 대한 번역 (TranslateWiki.net에서)을 보게 될 것이다. 재미있는 트릭: 계정의 경우 변경 내용 게시라고 표시됨. (그 속임수는 각 독자들에게 다른 버전을 보여준다. 우리 대부분에게 그 문장은 영어가 될 것이다. 다른 언어의 모양을 보려면 여기를 클릭하여 이 페이지를 러시아어로 표시하거나 이 페이지를 일본어로 보려면 여기를 클릭하십시오.)

그것이 정상적인 시스템이다. 이제 이 위키에서 모든 편집자를 위해 사용자 정의에 대해 이야기해 봅시다.

당신이 이 세계 역사상 가장 큰 위키라고 상상해보십시오. 그리고 어딘가의 일반적인 표현은 달라져야 한다고 생각하십시오. MediaWiki:Publish changes(게시 - 그들은 그 버튼에 대해 신경을 쓰고 있다)는 이유로 저작권 고지를 변경하고 싶지는 않지만 존재하지 않는 페이지를 방문할 때 표시되는 텍스트나 (당사의 문서가 평균보다 더 광범위하기 때문에) 일부 메시지를 변경하고 싶을 수 있다. 이 wiki에는 있지만 다른 곳에는 없는 도움말 페이지에 대한 링크 당신은 충분히 생각해 보셨고, 당신의 변화는 모든 사람들에게 도움이 되는 일반적인 개선은 아니므로, 여기 영어 위키백과에서는 이 위키백과의 모든 사용자들을 위해 그것을 변경하기를 원하십니다. 필요한 사용자 권한이 있으면 그렇게 할 수 있다. MediaWiki 시스템 메시지 페이지를 편집하여 새 텍스트(wikitext가 아닌 HTML)를 포함하십시오. 이 로컬 메시지 페이지는 일반 텍스트보다 우선한다.

여기에 문제가 있으며, 번역된 페이지가 존재하는 이유: 너는 영어로 메시지를 바꿨어. 하지만 거의 300개의 다른 언어가 있는데, 그 중 누구도 당신의 새로운 맞춤 메시지를 보지 못한다. 왜냐하면 당신은 영어만 썼기 때문이다. 예를 들어 MediaWiki:노기사 텍스트는 다양한 언어로 다음과 같이 보인다.

MediaWiki 비교:
MediaWiki 기본값 현재 이 페이지에는 텍스트가 없다.

다른 페이지에서 이 페이지 제목을 검색하거나, 관련 로그검색하거나, 이 페이지를 만들 수 있다.

영어
영국식 영어 현재 이 페이지에는 텍스트가 없다.

다른 페이지에서 이 페이지 제목을 검색하거나, 관련 로그검색하거나, 이 페이지를 만들 수 있다.

스페인어 에스테 파기나에 건초 문자 보내지 마

Puedes buscar el titulo de esta página en otras páginas, buscar en los registros elacionados, o crear esta página.

독일 Diese Seite enthelt momentan noch keinen text.

Du kannst sie erstellen, Ihren Titel auf andéren Seiten suchen oder die Zugehörigen Logbücher betrachten.

프랑스어 나는 부을 것이다. 즉시 aucun texte sur cette 페이지.

Vous Pouvez lancer un recherche sur ce titre dans le autres 페이지, rechercher dans le opéations lié o creerer cette 페이지.

당신은 우리가 영어 버전을 사용자 정의한 것을 볼 수 있지만, 다른 모든 것들은 그 언어로 번역된 MediaWiki 디폴트를 보여주고 있다. UI를 다른 언어로 설정한 사용자도 사용자 지정 버전을 표시하려면 MediaWiki를 다시 생성하십시오.노기사 텍스트/es, MediaWiki:문서 텍스트/de, MediaWiki:문서 텍스트/fr 등, 우리가 보길 원하는 텍스트. 이 RFC의 질문은 다음과 같다: 우리는 사용자 정의 페이지의 번역을 유지하기를 원하는가?

BTW, 둘 이상의 언어를 유창하게 구사하고, 번역을 돕고 싶다면, 나에게 연락해줘. 내가 도와줄게 Whatamidoing (WMF) (토크) 21:46, 2021년 7월 19일 (UTC)[]

@Whatamidoing (WMF): (많은 페이브 티켓을 찾아봐야 할 것임) 그러나 (나와 다른 사람들에 의해) 이 문제의 일부에 대해 고쳐져야 할 것은 변종적인 폴백 행동(즉, MediaWiki:Foo가 시작되었고 변형이 시작되지 않은 다음 기본 언어를 표시하십시오. 그래서 만약 Mediawiki가 다음과 같이 말한다.Foo가 존재하며 MediaWiki:Foo/enCA는 그렇지 않지만, 누군가 en-CA 세트를 가지고 있다. en 프로젝트의 기반을 그들에게 보여 준다. 미디어위키 디폴트로 돌아가는 대신. 다른 문제들에 대해서는 위의 메모에서 x-wiki 편집자가 가져올 수 있는 대중적인 언어로 된 메시지 거부와 같은 특정 페이지의 로컬 버전을 사용하는 것이 얼마나 유용한지 확인하십시오. 위의 질문은 이 좋은 것 중 어떤 것에 관한 것이 아니라, 지역사회가 더 이상 고려하지 않고 그들 모두를 핵무기로 만들기를 원하는지를 묻는 것인데, 나는 이것이 매우 나쁜 생각이라고 생각한다.xaosfluxTalk 21:55, 2021년 7월 19일 (UTC)[]
MediaWiki와 같이 누락된 내용의 실제 "번역"을 게시하는 동안:Publish changes는 확실히 좋은 생각이고 MediaWiki와 같은 페이지에 대한 해결책이 아니다.스타일링으로 디폴트(기본값)를 증가시키는 오용 필터가 허용되지 않음(변수와 클래스가 있는 오용 필터는 전혀 새로운 솔루션이 작동할 수 있지만, 이 논의의 범위를 훨씬 벗어난다).XaosfluxTalk 22:00, 2021년 7월 19일(UTC)[]
기존 페이지를 삭제해야 할지, 아니면 더 만들어야 할지 의견이 없다. 나의 주된 의견은 시스템 메시지가 실제로 무엇인지 알 수 없다면 다른 것에 대한 의견을 형성하기 어려울 것이라는 것이다.
1, 2년 전에 "원형" 폴백 언어에 대한 몇 가지 작업이 있었다. pt 대 pt-br이 주요 예다. 하지만 나는 이런 상황에서 그것이 적용되는지 확신할 수 없다. 그러나 enca/engb의 예에서는 사용자 정의 메시지 목록을 만들고 사용자 정의 버전을 "번역된" 페이지 이름으로 변환하는 것이 더 빠를 수 있다. Whatamidoing (WMF) (토크) 03:45, 2021년 7월 20일 (UTC)[]
미디어위키와 같은 보다 "중요한" 지역 메시지에서도 그렇게 했다.blockedtext/en-gb. 비록 그것은 엉성한 해킹이고 변수 전달에 어려움이 있다.xaosflux 09:53, 2021년 7월 20일 (UTC)[]
@Xaosflux: 우리 동네 봇으로 할 수 있지? 모든 MediaWiki: 사용자 정의, 봇에게 모든 en-* 페이지를 만들어 메인 페이지를 넘기는 것을 허용하십시오. RowlingReader (talk) 00:17, 2021년 7월 28일 (UTC)[]
@ProcrasisingReader: 음, 관리봇이 되어야 할 것이고, 어떤 것은 정상적인 전폐를 방지하는 특이한 방법으로 매개 변수를 처리하도록 요구한다. 언어 변형 폴백 트리를 업스트림(mediawiki를 사용하는 모든 사람에게도 고정)으로 고정하는 것이 훨씬 나을 것이다.xaosfluxTalk 00:29, 2021년 7월 28일(UTC)[]
@Xaosflux: 나는 어떤 관리자가 기꺼이 봇을 운영할 의향이 있다면 봇을 써넣을 수 있어 기쁘다. 물론 소프트웨어로 하는 것이 낫겠지만 도청하는 것보다 어떤 해결책을 가지고 있는 것이 더 나을 것이다. 만약 업스트림 픽스가 일어난다면, 우리는 항상 미래에 그것들을 삭제할 수 있다. 이게 BTW가 뭔지 알아? 미루는 Reader (대화) 10:11, 2021년 7월 28일 (UTC)[]
@ProcrastrasingReader: 모든 MediaWiki에 트랜스블루션을 추가하는 것만큼 간단하지는 않다.MediaWikiFoo/engb:Foo - 내가 언급했듯이 매개변수가 있는 모든 것은 다른 방식으로 처리되어야 할지도 모른다. phab:T229992, phab:T162008과 다른 것들도 문제의 개요를 설명한다. 이상적으로는 최소한 특정 언어(esp 언어 변형)의 미발행 메시지가 미디어위키 기본값 대신 지정된 언어(예: engb --> en)로 되돌아갈 수 있도록 로컬 대체 체계를 정의할 수 있는 옵션이 있어야 한다.Xaosflux 14:46, 2021년 7월 28일(UTC)[]
+1 @Whatamidoing(WMF). 내가 제안하는 것에 대해 명료하게 말해줘서 고마워. 아심(토크) 17:52, 2021년 7월 20일 (UTC)[]

미디어위키 정리

마크업 레이아웃 및 들여쓰기 스타일을 개선하기 위한 봇이나 툴인 HTML Flearch와 유사. .... 0mtwb9gd5wx (토크) 04:01, 2021년 8월 17일 (UTC)[]

@0mtwb9gd5wx: 여기서 무엇을 묻고 있는지 잘 모르겠는데, 당신이 제안하는 것에 대해 몇 가지 더 자세히 말해 줄 수 있겠니? 미디어위키는 이미 무효 마크업을 많이 고치는 HTML 클리너를 포함시켰고, 파서가 자동으로 고칠 수 없는 것은 wp:linter에 의해 태그가 붙여져 위키그램이 고친다. 페이지의 렌더링된 HTML을 변경하지 않고 Wikitext를 더 멋있게 보이게 하는 편집을 언급하는 경우, WP:Cosmetic 편집 및 이를 독점적으로 만드는 봇은 WP에 의해 분명히 금지된다.코스메틱봇. 192.76.8.74 (토크) 04:26, 2021년 8월 17일 (UTC)[]
@1907.76.8.74: 프로그래밍 언어에 대한 예쁜 인쇄와 마찬가지로, https://refill.toolforge.org/이나 https://refill.toolforge.org/ng/과 유사한 브라우저 기반 구문 강조표시에 대한 대안으로 편집자에게 서버측 도구로서 MediaWiki 마크업을 받아 포맷하는 도구가 있을 수 있다. ....0mtw9gd5wx (대화) 04:52, 2021년 8월 17일 (UTC)[]
대부분의 다른 프로그래밍 언어와 달리 위키코드에서는 공백이 매우 중요하기 때문에 불행히도 실제로 가능한 툴은 없다. 그러나 편집기에서 사용할 수 있는 구문 형광펜 도구가 있다. 일부 도구 모음에서 "고급"의 ,(오른쪽 맨 끝에 있는 연필 아이콘이 아님) Special에서 "New wikitxt 모드" 또는 "Automatically enable new 베타 기능"이 활성화된 경우:Preferences#mw-prefection-beta features는 메뉴 아이콘에서 사용 가능하다. —DJ (토크기여) 08:11, 2021년 8월 17일 (UTC)[]
@TheDJ:@192.76.8.74:사실 다음과 같은 예쁜 포맷이 가능하다.
<ref name="N">NEWLINE{{cite web last1=L first1=F title=T url=U website=W access-date=D}}NEWLINE</ref>
그리고 refbegin과 refend 사이에 시트를 넣은 후 refbegin과 refend 사이에 시트를 넣는다. .... 0mtwb9gd5wx (토크) 00:36, 2021년 8월 24일 (UTC)[]

TFD 제안 - 콘덴싱 정당 템플릿

WP에서는 다음과 같은 논의가 있다.1만6000여 개의 정당 템플릿이 하나의 메타 모듈로 병합되는 것과 관련한 TFD. 조언해주시면 감사하겠다. 프라임팩(토크) 11:38, 2021년 8월 26일 (UTC)[]

{{usstat 80 92}}

다음으로 이동:

및 언급:

또한 다음을 가리킬 필요가 있다.

또한, 의회 법안을 위한 템플릿이 있는가?

{{uscompany bill house 89 8030}}}
.... 0mtwb9gd5wx (대화) 04:45, 2021년 8월 27일 (UTC)[]
Template_talk:USSTAT가 이 요청에 적합한 장소일 수 있다. 템플릿:USBill은 당신이 찾는 템플릿일 수 있다. Mux (talk) 05:54, 2021년 8월 27일 (UTC)[]

영어 위키백과 페이지 하단에 알바니아어 위키백과 추가 - 섹션 50.000 이상 설명

제안: 주요 중요 문서에서 전기 분리

전기의 수준은 3단계다. 나는 현재 리스트보다는 5단계로 나눠서 리스트를 만드는 것이 유익할 것 같아. 이에 반대한다면 3.5등급이나 4.5등급과 같은 중간수준을 추가하는 것에 대한 당신의 생각을 알고 싶다. 나는 너의 코멘트를 고대한다. 인터스텔라리티 (대화) 14:56, 2021년 8월 27일 (UTC)[]

중요한 기사 대화 페이지에서 이전 토론을 참조하십시오. 한 편집자는 시야를 넓히기 위해 여기서 토론을 열자고 제안했다. 세포간(대화) 15:01, 2021년 8월 27일 (UTC)[]
  • 나와 다른 사람들이 이전 토론에서 반대했던 것과 같은 이유로 반대하라. 바이탈 기사 목록은 더 이상 확대하지 않고 현재 크기로 유지할 수 있을 만큼 충분히 어렵기 때문에, 나는 이것을 (즉,) 세트에서 더 많은 공간을 창출하기 위한 방법 이외에는 정당성이 없다고 보았다. {{u Sdkb}}} 16:36, 2021년 8월 27일(UTC)[]
  • 반대한다. 내가 보기에 WP의 주요 목적은 다음과 같다.VAWP와 같은 노력을 돕기 위해 가장 중요하다고 여겨지는 100, 1000, 10,000개의 기사를 확인하는 것이다.핵심 콘테스트, 우리의 가장 중요한 기사의 질을 분류하고, 또한 편집자들이 어떤 기사의 우선순위를 정할지를 결정하는 데 도움을 준다. 그 중 어떤 것도 리스트를 사람들과 비사람들로 나누는 것으로부터 이익을 얻지 못한다. 오히려, 그것은 편집자들이 두 가지 목록을 모두 확인해야 하는 것과 불일치하게 만들 뿐이며, 기사를 선택하는 편집자들의 참여는 더 낮을 것이다. 위키피디아는 다른 영역에서는 이러한 행을 따라 분할되지 않는다는 점에 유의하십시오. - 우리는 추천 기사/특집 기사 또는 삭제 기사/삭제 대상 문서를 가지고 있지 않다. 마지막으로, 몇 가지 특정 사항을 해결하려면:
    • 어느 것이 더 중요한지에 대해 전기와 비전기라는 것은 서로 비교하기 어렵다는 주장을 알 수 있는데, 다른 어떤 다양한 범주에서도 마찬가지다. 목성, 제2차 세계대전, 의류, 기독교 중 어느 것이 가장 '비탈'인지 평가하는 것은 거의 무의미하지만, VA 프로젝트는 여전히 이들을 하나로 묶고 있다.
    • 레벨 3에서 127개의 새로운 기사 슬롯을 자유롭게 하는 것이 장점이라고 말해왔지만, 그건 우리가 원하는 것이 아니라고 생각한다. Sdkb당 리스트는 의도적으로 특정 레벨로 유지되며, 1000 레벨 3이 충분하지 않을 경우 레벨 4를 보거나, 또는 레벨 4를 1200으로 확장하는 데 합의한다.
    • 사람들을 5단계로 분류해야 하는 것에 대해, 나는 다시 그것에 대한 필요성이나 근거를 보지 못한다. 위키피디아 보기:활력 있는 기사/레벨/5/사람/작가·기자, 나는 이미 그 대다수가 누구인지 알지 못하며, 그것들이 생명력의 하한선을 제대로 대변한다고 생각한다. 그렇다, 그들은 중요한 사람들이지만, 그 이하의 사람들은 그러한 IMHO로 분류되어서는 안 된다. 그리고 그 운동 역시 점점 더 다루기 힘들고 제멋대로 된다. 레벨 6을 추가하려는 욕구는 아마 다른 분야에도 있을 것이다. 하지만 비슷한 이유로 나는 그것에 반대한다.
    • 요약하자면, 나는 VA 과정이 지난 몇 년 동안 잘 작동했고, 이렇게 큰 규모의 중앙 분리 수술은 도움이 되지 않을 것이라고 생각한다. 건배 — 아마쿠루 (토크) 08:07, 2021년 8월 28일 (UTC)[]
  • 논평: 나는 이것에 대해 중립적이지만, 프로젝트 페이지는 위키백과 아래에 배치되어야 한다.위키프로젝트 바이탈 기사 불필요한 에세이 템플릿 제거에 필요한 경우. 그들은 의도치 않게 페이지를 훼손하고 있다. 그들은 정반대가 필요할 때 페이지를 편집하도록 권장하지 않는다. 인터스텔라리티의 프로젝트는 이미 유용했다. 현재 레벨 5는 더 많은 개발과 대체 목록이 필요하며, 예를 들어 가장 중요한 전기를 찾아 알파벳 순으로 나열하는 데 유용할 것이다. --Thi (토크) 15:42, 2021년 8월 28일 (UTC)[]

메시지에 사용된 성별이 선호도에 치우쳐 있음(마을 펌프(기술)에서 복사됨)

잘못된 장소에 게시되었기 때문에 Village Pump(Technical)에서 복사한 것이다. 파브리카토르에게 보낼 수 있도록 이 문제에 대한 지역 사회의 합의를 이끌어내고 싶다...

"사용자 프로파일"이라는 이름의 첫 번째 탭 아래의 환경설정에는 다음 섹션이 있다. 메시지에 사용된 성별, 여기서 사용자는 성별 중립, 여성 또는 남성 대명사로 주소를 지정할 수 있으며, 다른 사용자가 사용자 이름 위에 있을 때 선택한 대명사가 사용자의 사용자 권한 및 기타 사용자 그룹과 함께 사용자 권한 및 편집 횟수 및 기타 기본 정보와 함께 표시된다.사용자.

그러나 이 기능에는 사용자가 성별 중립을 유지하기를 원하는 경우 사용자 이름 위에 마우스를 올려 놓으면 아무것도 표시되지 않으며, 사용자 이름 위에 마우스를 놓으면 아무 것도 표시되지 않기 때문에 이 기능이 전혀 작동하지 않는 것처럼 보이는 기술적 문제가 있다. 사용자가 선택을 했고 기능이 작동 중임을 나타내는 것과 같은 것.

선호도가 성별 중립을 선택한 사람들에게 편향된 외관을 피하고, 모든 편집자가 해당 기능이 실제로 작동하는지 알 수 있는 방법을 갖도록 하기 위해 이 기능을 추가할 것을 제안한다. Huggums537 (대화) 19:03, 2021년 7월 30일 (UTC)[]

[나는 이 제안이 무엇에 관한 것인지에 대한 혼란을 피하기 위해 수정안을 만들어야 한다. '성별 불특정'을 선택하면 사용자의 선택권이 표시되지 않는 기술적으로 제대로 작동하지 않는 기능이 대부분이기 때문에 내가 먼저 빌리지펌프(기술)에 가져왔다. 이것은 그들/그들의 대명사에 대한 편견에 관한 것이 아니지만, 나는 그것이 우연히도 그렇게 보이는 것처럼 보이기 때문에 내가 그것을 저 안에 던질 수도 있다고 생각했다. 그러나 나의 주된 관심사는 간단한 텍스트 수정만으로 쉽게 해결할 수 있는 기능이다.

따라서, 나는 하트왕과 트라피스트 수도승이 제안한 대로, 팝업에서 "성별 불특정" 또는 "지정되지 않은 성"이라고 말할 수 있도록 글씨를 수정하자는 나의 제안을 수정한다.

그들/그들에 대해 말하자면, 너희들은 내가 신경쓰는 모든 것을 위해 소들이 집에 올 때까지 그것이 들어오는지 아닌지에 대해 토론할 수 있다. Huggums537 (대화) 21:36, 2021년 7월 30일 (UTC)[]

  • 동의한다, 네 번째 선택지가 있어야 한다. 단순히 선택을 하지 않은 사람에게 '그들/그들' 대명사를 강요해서는 안 되므로 능동중립과 수동중립을 구별할 필요가 있다.-- 제왕 19:27, 2021년 7월 30일 (UTC)[]
  • 다른 사용자가 사용자 이름 위에 있을선택한 대명사가 사용자의 사용자 권한 및 기타 사용자 그룹, 편집 횟수사용자에 대한 다른 기본 정보와 함께 표시되는 것으로 가정해 보십시오. 이는 미디어위키 인터페이스의 일부가 아닌 로컬로 유지되는 장비로, 따라서 변경사항이 Phabricator를 거치지 않고 대신, 관리자(intadministrator)가 MediaWiki에서 필수적으로 변경해야 할 것이다.Gadget-popups.js(특히, 그/그녀가 아닌 옵션을 추가해야 하는 라인 4185와 해당 l10n 문자열을 추가해야 하는 라인 7276). 물론 KoH가 제안한 "그들/그들"과 "지정되지 않은" 사이의 분명한 차이점은 다른 문제지만, 그것은 NavPopups에 대한 지원을 추가하는 데 충분하거나 필요하지 않을 것이다.; 그러한 Phab 티켓의 제출 여부와 상관없이 스크립트에 대한 변경은 여전히 필요할 것이다. 2021년 7월 30일(UTC) 19:35, Writ Keeper⚇[]
    키퍼, 이게 맞는 것 같군 따라서, 새로운 제안에 따른 변경사항은 단순히 네비게이션 팝업에 "성별 지정되지 않음"을 추가하여, 이미 환경설정에서 제공되고 있는 현재 선택사항과 일치하고 다른 두 선택사항과 동일하게 팝업에서 표시되도록 하는 것이다. Huggums537 (대화) 23:18, 2021년 7월 30일 (UTC)[]
  • (편집 충돌) 다른 사용자가 사용자 이름 위에 있을선택한 대명사가 사용자 권한기타 사용자 그룹뿐만 아니라 사용자의 편집 수 및 사용자에 대한 일부 기본 정보와 함께 사용자 이름 위에 표시된다는 것이 무슨 뜻인지 모르겠다. 그런 경험은 처음이야. 난 내가 원하는지 잘 모르겠어.

    그럼에도 불구하고, 나는 그들/그들/그들/그들과 함께 연설되고 싶지 않다. 왜냐하면 오직 한 사람만이 있기 때문이다. 아아, 기본 라디오 버튼 '지정되지 않음'은 실제로 '지정되지 않음'을 의미하는 것은 아니다. 그래서 나에게 있어서 해결책은 단수 복수 대명사를 선호하는 사람들이 그것을 선택하고 '지정되지 않음'을 정말로 '지정되지 않음'으로 만드는 것이다. 아니면, 모든 옵션을 다 폐기하고 우리 모두를 깔끔하고 작은 상자에 넣으려는 시도를 그만두는 것이 좋을 것이다.

    스승 (대화) 19:40, 2021년 7월 30일 (UTC)[]

    위키피디아처럼 들리는데:도구/내비게이션 팝업 확장. 너한테는 불특정이지 성별이 불특정/알 수 없는(?) RodelingReader(토크) 20:02, 2021년 7월 30일(UTC)[]에 사용할 더 좋은 대명사가 없는 한 많은 사람들이 기본적으로 당신을 "그들"이라고 부를 것이다.
    스님트라피스트, 나는 "작은 상자"에 누구를 집어넣고 싶지는 않지만, 나는 모든 사람들에게 그것들을 처분하는 것이 아니라 선택할 수 있는 선택권을 주고 싶다. 그래서 나는 하트왕이 적극적이거나 수동적으로 중립적인 것을 구별할 수 있는 네 번째 선택권을 추가하는 것을 지지하고 있으며, 이루어질 수 있는 방법은 그들, 그/그들, 그리고 그녀와 함께 바로 "미지정 성별" 선택권을 추가하는 당신의 생각을 통합하는 것이다. 이러한 방법으로 사용자는 그들이 어떻게 다루어지기를 원하는지에 대한 완전한 선택을 할 수 있다. Huggums537 (대화) 20:57, 2021년 7월 30일 (UTC)[]
    트라피스트는 그녀가 그들처럼 언급되는 것을 선호하지 않으며 또한 어떤 대명사도 명시하기를 원하지 않는다고 말한다; 그것은 멋지다. 나는 그녀를 그들이라고 부르지 않을 것이다.
    그 깔끔하고 작은 박스들이 없으면 우리는 결국 디폴트 세팅으로 끝나게 된다. 인터넷상의 기본 설정은 종종 그/그였다. 우리가 그 깔끔하고 작은 상자 안에 우리 자신을 넣을 수 있게 해준다는 것은 내가 그/그/그라고 불리지 않는다는 것을 의미하는데, 그것은 수십 년 동안 꽤 지겨워져 왔다. 그들이 단수로 나아가는 디폴트 세팅은 IMO가 꽤 생산적이긴 하지만, 그들을 거부하고 특정하기를 거부하는 사람들을 위해, 우리 각자는 그녀 자신의 디폴트 세팅에 대해 자유롭게 생각해내야 한다. :) —발레 (대화) 13:46, 2021년 8월 3일 (UTC)[]
  • MediaWiki talk:를 참조하십시오.당신의 성별 § 2021년 7월에 UTJW에서 후속으로 U.T.JW에서 후속으로 미디어위키 소프트웨어 아이디어에 대한 논의를 위해 사용자들이 대명사로 다루어지기를 원하지 않는다는 것을 명시할 수 있는 옵션을 가지고 있다. ("지정되지 않음"은 토론에 기초하여 사용자 선호 설정의 텍스트에 추가되었다.) 관련 Phabricator 티켓이 있다. 이삭 (토크) 20:26, 2021년 7월 30일 (UTC)[]
    Isaacl, 사용자 이름 위에 마우스를 올려 놓으면 "지정되지 않은 성별"이 나타나지 않는다는 점을 제외한다. 앞에서도 언급했듯이 공백일 뿐 이 옵션을 선택하기로 한 사용자에게는 효과가 없다는 외관을 주는 것은 아무것도 보이지 않는다. 적어도 본문은 '미지정 성별'이라고 쓰도록, '필터 키퍼'가 제시한 방식대로 수정해야 한다. 그렇게 하면 문제의 일부도 해결하면서 이전 논의에도 부합할 것이다. Huggums537 (대화) 21:03, 2021년 7월 30일 (UTC)[]
    네, 네비게이션 팝업 확장에 의해 표시될 수 있는 내용에 대한 당신의 원래 게시물을 읽었습니다(아마도 이것을 확인할 수 있을 겁니다). 아이작 (토크) 21:24, 2021년 7월 30일 (UTC)[]
    아이작, 물론, 내가 그/그/그녀를 선택하면 내 선택이 팝업에 나타나지만, 내가 "지정되지 않음"을 선택하면 아무것도 나타나지 않는다. Huggums537 (대화) 21:44, 2021년 7월 30일 (UTC)[]
    그러면 해당 팝업이 활성화한 탐색 팝업 가젯에 의해 표시되고 있음을 확인하는 겁니까? 아이작 (토크) 21:59, 2021년 7월 30일 (UTC)[]
    팝업이 모든 옵션을 표시하지 않음을 확인하는 것뿐입니다. 가능하다면 어떤 도구가 팝업을 생산하고 있는지 확인해보겠지만, 이 근처에 있는 숙련된 편집자들은 당신이 사용자 이름을 가리킬 때 어떤 도구가 정보를 생산하는지 이미 알고 있을 것이라고 생각했고, Writ Keeper는 내가 코드를 보고 그 정보를 가지고 있기 때문에 그것이 항법 확장이고 내게 맞는 소리라고 제안했다.t... Huggums537 (대화) 23:30, 2021년 7월 30일 (UTC)[]
    아이작, 좋아, 내 생각엔 이게 네비박스 장치인 것 같아. Huggums537 (대화) 08:40, 2021년 7월 31일 (UTC)[]
  • 그들은이 사용자는 그들이 표준으로 삼는 현대적이고 비공식적인 영어 사용을 생각하므로 위키피디아에서는 그것을 피한다.
    -Qwerfjkltalk 20:35, 2021년 7월 30일 (UTC)[]
  • 어떻게 이 같은 일이 계속 돌고 있을까? 이 값에 대한 리터럴 옵션은 이미 불특정, 남성, 여성이다. 이는 언어 설정이며, gendered 명사(예: Userio vs Useria for "User")만을 사용하는 언어를 포함하여 세계적으로 사용되는 소프트웨어의 일부다. 이 제안은 매우 모호하고 XY 문제인 것 같다. 당신은 정말로 미디어위키 소프트웨어를 바꾸려고 하는가, 아니면 당신은 정말로 누군가가 그 지역의 기기를 다시 녹음하기를 원하는가?xaosfluxTalk 22:51, 2021년 7월 30일 (UTC)[]
    Xaosflux, 이것은 사실 간단하고 논란의 여지가 없는 편집이다. 내가 제안하는 것은 미디어위키 소프트웨어의 기존 값에 대한 변경 없이. 내가 요구하는 것은 사용자가 성별 중립 선호에 대해 "지정되지 않음"을 선택할 때, 만약 누군가가 남성 또는 여성 선호도를 선택한 경우, 그/그녀 선호도를 선택한 것과 동일한 방식으로 선택했음을 나타내기 위해 팝업 화면에 나타날 것이다. 현재 "지정되지 않음" 팝업에는 아무것도 표시되지 않는다. 그러나 "성별 불특정"이라는 두 개의 작은 단어를 팝업창에 추가할 수 있고, 적어도 사용자가 그러한 선택을 했다는 것을 나타내는 것을 보여줄 수 있다. 별로 복잡하지 않다. Huggums537 (대화) 23:08, 2021년 7월 30일 (UTC)[]
Special:의 기본값인 Unified:선호도. 사용자가 자신의 기본 설정을 만지거나 살펴본 적이 없는 경우 "지정되지 않음"으로 표시된다. 현재 사용자가 의도적으로 '지정되지 않음'을 선택했는지, 아니면 아무것도 하지 않았는지 알 길이 없다. 이 팝업은 Special:에서 "내비게이션 팝업"을 활성화한 등록된 사용자만 볼 수 있다.Preferences#mw-prefection-gadgets, 편집자들이 영어 위키백과에서 만든 스크립트. 기본적으로 비활성화되어 있으며, 등록되지 않은 사용자가 사용할 수 없다. 팝업이 아무 말도 하지 않고 '성별 불특정'이라고 말하는 것은 가능하겠지만, 팝업은 사용자가 그것을 선택했는지, 아니면 아무것도 선택하지 않았는지 알 길이 없다. 그렇게 하려면 MediaWiki 소프트웨어를 변경해야 한다. 프라임헌터 (대화) 23:28, 2021년 7월 30일 (UTC)[]
PrimeHunter, 그러나 사용자가 옵션을 선택했는지 아니면 다른 옵션처럼 표시되도록 디폴트로 설정되었는지 아닌지가 왜 다른 사람에게 중요한가? Huggums537 (대화) 23:36, 2021년 7월 30일 (UTC)[]
왜 누군가가 남성 대명사나 여성 대명사를 선택했느냐가 중요한가? Wug·a·po·des 00:45, 2021년 7월 31일 (UTC)[]
Wugapods, 왜 그것이 중요한지 묻지 말고, 팝업 정보로 이 대명사들을 다른 모든 사람들에게 알리기로 결정한 사람이 누구인지를 물어봐라. 하지만 또한 어떤 대명사의 비사용에 대한 정보는 그것이 채무불이행으로 결정되었든 아니든 간에 보류하기로 결정했다... Huggums537 (대화) 02:42, 2021년 7월 31일 (UTC)[]
내 요점은 당신이 기본이 아닌 선택권을 선택하는 사람들의 선택을 존중하는 것은 괜찮지만, 중립적인 선택권을 선택한 사람들에 대해서는 신경 쓰지 않는 것 같다는 것이다. 신경 쓰지 않아도 되지만, 다른 사람들은 신경 쓰지 않는다. — Wug·a·po·des 02:56, 2021년 7월 31일(UTC)[]
Wugapodes, 내가 무엇을 하거나 신경 쓰지 않는 것에 대한 이러한 가정은 토론과 무관해야 하며, 내가 신경쓰는 것은 평범한 "미지정 성별" 텍스트의 단순한 삽입에 전혀 영향을 미치지 않으며, 텍스트 자체는 어느 쪽이든 상관하지 않으며, 또한 어떤 배려에 대해서도 함축하지 않기 때문이다. 또는 텍스트 자체가 두 가지 옵션 모두에 적용되기 때문에 내가 하는 일이나 상관하지 않는 일에 대한 너의 요점은 오히려 엉터리로 보인다. Huggums537 (대화) 03:48, 2021년 7월 31일 (UTC)[]
분명히 말해서, "중립적인" 것은 일부 사람들이 시스템이 자신들을 징더된 언어로 언급하는 것을 전혀 원하지 않는다는 것을 의미한다. 어떤 것이 불특정하다고 말하는 것이 그것을 특정하지 않는 것에 비해 어떻게 도움이 되는지 설명하지 않으셨습니다 — Wug·a·po·des 03:01, 2021년 7월 31일 (UTC)[]
우가포드, 나는 그 제안의 평범하고 단순한 이점이 다른 사람들이 볼 수 있도록 그것을 가시화시키고 있다는 것을 아주 상세하게 반복해서 설명해 왔다. 만약 그것이 불문율이나 무언의 규칙처럼 보이지 않게 내버려 두는 것의 도움이 명백하지 않다면, 나는 너에게 뭐라고 말해야 할지 모르겠다. Huggums537 (대화) 03:56, 2021년 7월 31일 (UTC)[]
여기서 더 나은 반응은 대명사가 어느 쪽으로든 표시되기 때문에 누군가가 남성 또는 여성으로 선택해도 상관없다는 것이고, 누군가가 그것을 선택하든 상관없는 "성별 불특정"과 같아야 한다는 것이다. 또는 선택된 동일한 옵션이 어느 쪽으로 표시되기 때문에 기본값이 선택되기 때문이다. Huggums537 (대화) 11:55, 2021년 8월 7일 (UTC)[]
사용자가 선택을 했는지 아니면 디폴트되었는지 알아야 한다는 이상주의를 무시한다면 미디어위키 소프트웨어를 변경할 필요가 없다. 네비게이션 팝업은 알 방법이 없을 거라고 하셨지만, 내 생각에 네비게이션 팝업은 그 사실을 알 필요가 전혀 없을 것 같아서 디스플레이에 "미지정 성별"만 추가해도 문제가 되지 않을 것이고 사용자가 선택하든, 아니면 디폴트 되든 간에 나타날 겁니다. 심플 진정. 허금537 (대화) 23:54, 2021년 7월 30일 (UTC)[]
  • 도구가 겹치더라도 다른 개인의 성별을 유추하기 위해 문법적 성별을 잘못 사용하기 때문에 계속 동그라미가 친다(문법적 성별#문법적 대 자연적 성별 참조). 소프트웨어 설정은 시스템 인터페이스 메시지를 국제화하는데 있어서 특정한 목적을 위해 고안되었지만, 우리는 그것을 엔위키에서 누군가가 수행하기로 선택한 특정 성별을 위한 스탠드로 사용한다. 이것은 개인의 성별에 대한 우리의 문화적 신념이 세계의 나머지 언어들이 명사 수업을 어떻게 사용하는지에 맞춰지지 않을 때 반복되는 갈등으로 이어진다. 미디어위키나 기기가 개인의 성별과 문법적 성별을 구분하지 않는 한, 나는 이러한 논의가 계속해서 순환하기를 기대한다. (분쟁 편집)—Wug·a·po·des 23:18, 2021년 7월 30일(UTC)[]
    Wugapods, 그 제안은 국제 소프트웨어의 어떤 변경에도 영향을 미치지 않기 때문에 이 중 어떤 것도 여기에서는 아무런 영향을 주지 않는다. 팝업이 이미 국제 소프트웨어가 말하는 것과 일치하고 다른 사용자가 볼 수 있도록 로컬 영어 위키백과 네비게이션 팝업에만 영향을 미친다. 이것은 사람들이 계속해서 문제를 보고 있고, 그들은 제대로 해결되지 않고 있기 때문에 계속 순환한다. Huggums537 (대화) 07:45, 2021년 7월 31일 (UTC)[]
    맞아, 이게 바로 사용법이 잘못되었으니 제거해야 하는 이유야. 사람들이 (성별이나 대명사)를 어떻게든 식별하고 싶다면, 그들의 토크 페이지에 그것을 쓸 수 있는데, 우리는 소프트웨어 언어의 문법적 성별에 사용하는 정보로부터 그것을 유추해서는 안 된다. —DJ (대화기여) 16:50, 2021년 7월 31일 (UTC)[]
    디제이, 모든 사람을 기쁘게 할 수 없다면 그냥 다 같이 없애버리는 건 새로운 해결책이지만, 그러면 모든 사람들에게서 그 특징을 빼앗긴다는 거야. 우리 사이에 있는 이 뛰어난 정신력으로, 확실히 우리는 모든 사람들이 받아들일 만한 을 보여줄 수 있을까? 이 시점에서 어떤 제안이라도 들어볼게. 확실히 여기 디스플레이 팝업을 위해 나보다 더 좋은 아이디어를 가진 사람이 있을 거야? Huggums537 (대화) 19:28, 2021년 7월 31일 (UTC)[]
    아니, 우리는 모두가 받아들일 수 있는 무언가를 생각해내지 않을 것이다. 이것은 인터넷이다. 그러므로 적은 것이 더 많다. —DJ (대화기여) 07:26, 2021년 8월 1일 (UTC)[]
  • 맹세해. 이 사이트에 있는 사람들은 성 문제에 대해 너무 겁을 먹고 있다. 단순히 성별이 특정되지 않았다는 것을 다른 사람들에게 알리는 것에 대해 큰 문제가 있어서는 안 된다... Huggums537 (대화) 00:06, 2021년 7월 31일 (UTC)[]
    • 어떤 사람들은 중성자를 선택하면서 성별을 특정한다. 그것을 설명하려는 사람들을 무시하는 것은 공감대를 형성하지 않을 것이다. 현학적으로 행동하고 싶다면 '그'나 '그녀'의 부족은 성별이 특정되지 않았기 때문에 특정되지 않았다는 것을 알려주는 방법이다. 그것은 모호하지 않고, 그것을 바꾸는 것은 단지 다른 그룹의 사람들을 짜증나게 할 것이다. 이게 간단한 척 한다고 해서 그렇게 되진 않을 거야. Wug·a·po·des 00:45, 2021년 7월 31일 (UTC)[]
      '성별 불특정'이라는 텍스트를 팝업에 추가하는 우가포드도 모호하지 않고, 아무것도 바꾸지 않고 있다. 그것은 다른 사람들에게 선택을 보이게 하는 것만큼 간단하다. 다른 사람들에게 선택을 보이지 않게 하는 것이 자신의 보이지 않는 신호라는 주장은 사람들이 보이지 않는 신호를 볼 수 있다면 그들이 선택을 했다는 당신의 보이지 않는 신호일 테지만, 사람들이 보이지 않는 신호를 볼 수 있는 척하는 것은 그렇게 하지 못할 것이다. Huggums537 (대화) 03:21, 2021년 7월 31일 (UTC)[]
  • 문맥상에서는 이전에 사용한 아이콘 대신 어떤 텍스트를 표시할 것인지에 대한 논의가 있었다.T284783, "NavPopups는 ♂♀ 아이콘을 사용하여 자신이 어떻게 대처하고 싶은지 설명해서는 안 된다." 이삭(토크) 04:40, 2021년 7월 31일(UTC)[]
    Isaacl, 나는 성별을 나타내는 그래픽 아이콘은 불특정 성별의 텍스트를 추가하는 것에 대한 논의와는 무관하다고 생각한다. 또한, "성별 불특정"을 추가하는 것은 그 논의에서조차 언급되지 않은 새로운 생각이었다. 나는 그 제안에서 그들을 추가하는 것에 대해 놀랐고, 그것이 내가 그 토론에서 볼 수 있는 유일한 관련성이기 때문에 나는 거기에 진정한 맥락이 없다고 본다. Huggums537 (대화) 07:09, 2021년 7월 31일 (UTC)[]
    게다가, 나는 내가 이러한 다른 토론에 참여할 수 있었으면 좋았을 텐데, 왜냐하면 나는 성별이 다른 언어에서 중요하다는 생각에 대한 이러한 지지자들에게 분명히 무언가를 언급했을 것이고, 우리는 우리의 소프트웨어/언어/성별 등의 결정을 고려할 때 그것을 고려해야 하기 때문이다. 그들에게 보내는 나의 메시지는 매우 간단할 것이다; "이것은 영어 위키백과지 X 언어 위키백과가 아니다." 아마도 이전의 토론에서 아무도 그 대답을 생각하지 않았을 것이다. 나는 그것들을 아주 자세히 살펴보지는 않았지만, 스페인어와 같은 다른 언어로 성별이 어떻게 접근하는지에 대해 사람들이 소란을 피우고 있다는 생각을 얻을 정도로 충분히 훑어보았다. 2021년 7월 31일(UTC)
    토론에서 사용자 환경설정에서 "지정되지 않은" 선택사항이 선택되었을 때 왜 아무것도 표시되지 않는지에 대해 언급했고, 따라서 상황에 관심이 있는 모든 사람에게 링크를 제공했다. 내비게이션 팝업 기기는 다른 언어 위키백과에도 배치되어 있으므로 이들의 요구 사항도 수용할 수 있어야 한다. 이삭 (토크) 14:26, 2021년 7월 31일 (UTC)[]
    좋아, 충분히 그럴만한 상황인 것 같아. 그러나, 다른 사용자들이 그것이 영어 위키백과의 국부적인 도구라는 것을 암시했기 때문에 나는 내비게이션 팝업 가젯에 대한 상충되는 정보를 얻는 것 같다. 그것은 이 기구의 사용이 국제적으로 사용되는 미디어위키 소프트웨어와는 다르다는 것을 암시한다. Huggums537 (대화) 16:58, 2021년 7월 31일 (UTC)[]
  • 위키피디아에 따르면:데이터베이스 보고서/사용자 선호도#성별(2세), 등록 사용자의 98%가 성별을 지정하지 않았다. 능동적인 사용자에게는 더 낮다고 생각하지만 불특정 다수는 현실의 성중립적인 사람들이 아니라 단지 선택지를 보지 못한 사용자들일 뿐이다(항상 존재하지는 않았다) 또는 자신의 성별을 특정해야 할 타당한 이유를 알지 못한다. 나는 팝업이 공간을 사용해서는 안 된다고 생각한다. 그리고 나는 많은 팝업 사용자들이 성별 정보가 표시되지 않는다면 그것은 사용자가 그것을 주지 않았기 때문이라는 것을 알고 있다고 생각한다. "성별 불특정"을 표시하는 것은 사용자들이 원하지 않을 때 자신의 성별을 명시해야 하는지에 대해 걱정하게 할 수 있다. 나는 아무것도 명시되지 않았을 때 아무 말도 하지 않는 것을 지지한다. 프라임헌터 (대화) 09:51, 2021년 7월 31일 (UTC)[]
    프라임헌터는 물론 일부 부정적인 사람들에게는 그것이 사용자들을 걱정하게 할 수도 있지만, 긍정적인 폴리는 디스플레이가 사용자들로 하여금 그들이 선택권을 가지고 있다는 것을 더 잘 인식하게 할 수 있는 좋은 기회가 있다는 것을 내게 말해주고, 그들은 그들이 지금 그들이 원한다면 선택할 수 있다는 것을 보여 준 것에 더 감사할 수도 있다. 또한 "성별 불특정"선택하면 아무것도 보이지 않으므로 가시성을 가능하게 하는 것은 가치가 충분히 있다는 것을 깨닫지 못하는 사용자도 충분히 있다고 생각한다. Huggums537 (대화) 11:17, 2021년 7월 31일 (UTC)[]
    @Huggums537:아니면 그들은 그것을 비워두어야 한다고 느끼겠지만 지금은 그럴 수 없을까? 이름 옆에 '그/그들'을 두는 것에 반대한다면, 그들이 할 수 있는 일은 '그/그'나 '그/그녀'로 바꾸는 것뿐이다. 사라짐은 그것을 비우는 선택이다. 그건 문제야. 개발자들에게 네 번째 성별 선호도를 더하도록 설득하고, 그러면 여기서 뭔가 할 수 있을 것이다. 있는 그대로, 이것은 실행할 수 없다. RusingReader (대화) 12:26, 2021년 7월 31일 (UTC)[]
    DragingReader, I think* 당신은 이미 퇴장 전이고 그것을 내 제안으로 돌리려고 하는 문제를 설명하고 있다. 왜냐하면 그들의 이름 옆에 그들/그들을 두는 것에 반대할 수 있는 사용자들은 이미 뭔가 다른 것을 원하면 그/그녀로 바꿀 수 밖에 없기 때문이다. 팝업 디스플레이에 "성별 지정되지 않음"을 추가해도 이에 영향을 미치지 않고, 현재 이미 존재하는 것만 표시한다. 아마도 실행 불가능한 것은 내 제안이 아니라, 내 제안이 실행 불가능한 것을 나타내는 근본적인 선호도일 것이다. Huggums537 (대화) 13:27, 2021년 7월 31일 (UTC)[]
    내 관점에서는 단순한 사용자 정보의 표시를 가능하게 하는 통상적인 업무를 수행하기 위해 왔을 뿐인데, 나보다 먼저 온 사람들이 그런 일이 일어나도록 허락하지 않는 것 같은 실행 불가능한 시스템을 이미 시행했기 때문에 나는 계속 그렇게 할 수 없었다. Huggums537 (대화) 20:02, 2021년 7월 31일 (UTC)[]
  • 코멘트 나는 이전의 관련 대화에서 나온 다른 사람들이 이 토론에 참여함으로써 이익을 얻을 것이라고 생각한다. 특히 사용자 짐보 웨일즈 토크 페이지에서 정확히 동일한 이슈를 제기하고, Cullen328, Indy Wales, Sdkb, TheDJ, Floquenbeam(노핑 세트), RGloecher, Valeee, Khajidha, Xaosflux 등 여러 사용자가 해당 주제에 대해 응답한 [20]과 같은 정확한 주제와 관련된 사용자들이 특히 그렇다. 다른 가장 적절한 대화는 다음과 같다: MediaWiki_talk:Yourgender#7월_2021_follow_up_from_UTJW는 진짜 새로운 기여자들 중 유일하게 Whatamidoing(WMF)SandyGeorgia가 있었다. 이 두 가지 대화 모두 거의 같은 문제에 초점을 맞추고 있으며, 나는 지금 이 문제를 해결하기에 좋은 장소라고 생각한다. 만약 팝업에 "성별 불특정"이라고 쓰여 있다면, 그것은 단순히 우리가 이미 결정한 것과 정확히 일치할 것이다. 유일한 차이점은 이제 그것이 다른 사람들에게 보여질 것이고, 나는 이 보다 투명한 접근법이 훨씬 더 낫다고 생각한다. 어쨌든 우린 뭘 숨기고 있는 거지? Huggums537 (대화) 11:09, 2021년 7월 31일 (UTC)[]
  • 내가 뭔가를 놓치고 있는 건지도 모르지만, 여기의 옵션은 1) 팝업에 "그들/그들"을 표시하고, 다른 사람들이 그/그들을 그들/그들라고 부르도록 격려하고, 2) 팝업에는 아무것도 표시하지 않고, 다른 사람들이 그/그들라고 부르도록 격려하는 것이다. 왜냐하면 그것은 대부분의 영어 사용자들에게 일반적인 일이기 때문이다. "이 페이지는 일부러 비워두었다"를 인쇄할지 아니면 그냥 비워둘지 묻는 느낌이다.Joe(토크) 11:33, 2021년 7월 31일 (UTC)[]
    로, 그건 어제의 오래된 피곤한 선택이야. 미래의 물결인 지금 새로운 훌륭한 선택지가 있다! 팝업 디스플레이에 "성별 지정되지 않음"을 추가하십시오. Huggums537 (대화) 11:59, 2021년 7월 31일 (UTC)[]
    아, 그때 뭔가 놓친 게 있었어. 그 경우, 그것은 팸플릿으로 만들어진 매우 좋은 요점과는 상충된다.T284783: 누군가의 성별은 그들이 언급되고 싶은 방식과 같지 않다. 그래서 팝업이 이제 개인의 성별을 나타내는 것이 아니라 대명사를 직접적으로 가지고 있는 것이다. 만약 누군가가 그들이 그들처럼 언급되기를 원한다고 말한다면, 그것은 그들의 성별이 불특정하다는 것을 의미하지 않는다. 여기서는 정말 침묵이 말보다 더 많은 것을 말하는 것 같다. 아니면 팝업에 포함된 것을 사람들이 맞춤화하도록 하는 다른 선택사항일 수도 있다.Joe(토크) 12:08, 2021년 7월 31일 (UTC)[]
    넌 아무것도 놓치지 않았어. 난 그냥 웃기려고 한거야. 여기서는 정말 침묵이 말보다 더 많은 것을 말하는 것 같다. "성별 불특정"을 추가하는 것은 현재 침묵보다 못한 것을 "말하지" 않는다. 사실, 그것은 이전에 많은 사람들이 몰랐던 정보를 다른 사용자들에게 알려주기 때문에 더 많이 말한다. 누군가가 자신으로 지칭되기를 원하는지 아닌지에 대한 요점은 이 경우에 있어 무뚝뚝하다. 왜냐하면 그것은 이미 디폴트로 우리에게 결정되었기 때문이다. 우리가 이 토론에서 결정하려고 하는 것은 우리가 그 결정을 보여줄 것인지 아닌지에 관한 것이다. 정말 그렇게 간단하다. 만약 우리가 우리의 결정을 고수한다면, 우리는 그 결정을 전시하는 데 문제가 없을 것이다. Huggums537 (대화) 13:01, 2021년 7월 31일 (UTC)[]
  • 어떤 사람이 소프트웨어가 그들을 gendered 대명사로 언급하기를 원하든 원하지 않든 간에, 그 선택은 '지정되지 않은 성별'이라는 문구로 소프트웨어가 그들을 공개적으로 언급하기를 원하지 않았거나, '지정되지 않은 성별'은 대명사가 아니며, '지정되지 않은 성별'은 아무리 모호하고 모호하더라도 그들이 요구하는 공개적인 진술이 아니다.즉, 통신에서 gendered public 대명사를 원하는지 묻는 것뿐입니다. -- 알란스코트워커(talk) 15:30, 2021년 7월 31일(UTC)[]
    Alanscottwalker는, 어떤 사람이 소프트웨어를 선택하든, 그들이 사용자 이름을 선택하라는 요청을 받았을 때, 그들을 "참조"하도록 선택할 수 없으며, 소프트웨어가 "사용자"라는 문구로 그들을 공개적으로 언급하기를 원하는 것을 의미하지 않는다. "사용자" 또한 그들이 요구하는 공개적인 진술이 아니다. 그러나 "사용자"는 정보를 전달하는 데 사용되는 간단한 설명 데이터이기 때문에 위키피디아 전역의 다른 많은 장소(사용자 페이지에서 매우 두드러지게 나타남)에 두 번 나타난다. 그래서 그것은 "성별 불특정"을 추가하는 것이다. 누구든 자신의 의사에 반하는 어떤 것을 '참고' 받고 있다는 이 생각은 그저 우스꽝스러울 뿐이다. 아무도 그들의 의지와는 반대로 "사용자"로 지칭되는 것에 대해 불평하지 않는다. 점점 통제 불능이 되어가고 있다. Huggums537 (대화) 17:50, 2021년 7월 31일 (UTC)[]
    그들은 사용자다. 그것은 웹사이트를 사용하는 모든 사람들을 위한 단어다. 이 제안은 정말 말도 안되고, 개소리할 필요도 없어. 알란스코트워커 (대화) 19:33, 2021년 7월 31일 (UTC)[]
    앨런스코트워커, 정말 이상하고 멀리 떨어진 괴짜들은 그들이 전혀 "사용자"가 아니라고 주장할지도 몰라. 그들은 아무도 "사용하지 않는다"고 말할 수 있고, 그것은 그들을 "사용자"로 지칭되는 것을 불쾌하게 할 수도 있다. 그것은 본질적으로 '성별 불특정'으로 불리고 싶지 않다는 것과 같은 이상한 주장이기 때문에 잠시 그것에 대해 생각해 보라. 그러나, "성별 불특정"은 "사용자"가 웹사이트를 사용하는 모든 사람을 설명하는 단어일 뿐이라는 것을 의미한다. 그러니, 바라건대 내가 그런 종류의 논쟁은 "어리석은 짓"이라고 말할 때 내가 무슨 말을 하는지 알 수 있길 바란다. Huggums537 (대화) 20:41, 2021년 7월 31일 (UTC)[]
    납득할 수 없는 일 - 한 사람은 고의적이거나 필연적으로 희망과 같은 어떤 것에도 도달하지 못할 것 같아 보이는데, 이는 트롤링이나 미끼로 시작하는 코멘트를 통해 시작되며, 그 다음으로는 무관한 다른 것들이 존재하며 대명사와 관련된 참조를 망치는 것이다. -- 알란스코트워커 (talk) 12:55, 2021년 8월 1일 (UTC)[]
    알란스코트워커, 나는 이 실에 아주 많이 참여했고, 적어도 95%의 참가자들과 상호작용을 해왔고, 아무도 자신을 제쳐놓고 트롤링이나 미끼에 대해 불평하거나 제안하지 않았다. 다른 편집자에 대한 근거 없는 비난은 인신공격으로 볼 수 있다. 그러나, 당신이 나를 완전히 고발한 것은 아니므로, 그런 제안을 하는 것은 고발 그 자체를 하는 것과 거의 똑같이 나쁘다는 것을 기꺼이 이해하고, 앞으로 다시 그런 일을 하는 것을 피한다면, 나는 기꺼이 이 무단침입을 용서할 용의가 있다. 고마워요. Huggums537 (대화) 14:50, 2021년 8월 1일 (UTC)[]
    유일한 근거 없는 것은 PA의 제안, 즉 내 논평은 이전 논평에서 기초된 사람이 아니라 기여에 관한 것이었다는 것이다. 당신의 다른 논평도 많은 것이 될 수 있다는 것은 안심할 수 없다. 당신의 주장은 분명히 다른 것들도 납득시키지 못하고 있다; 내 입장에서 설명하려고 노력했지만, 여기서, 우리는 유용한 더 많은 논의를 할 수 있을 것 같다. -- 알란스코트워커 (대화) 15:32, 8월 1일 (UTC)[]
    동의함. -Qwerfjkltalk 15:40, 2021년 8월 1일(UTC)[]
  • 반대: 이렇게 할 진짜 이유는 없다. -Qwerfjkltalk 15:56, 2021년 7월 31일(UTC)[]
  • 나는 전에 이것에 대해 하고 싶은 말을 한 적이 있다. 나는 또한 이 토론이 모든 사람들의 마음에 들도록 해결될 것이라는 환상을 가지고 있지 않다. —DJ (대화기여) 16:12, 2021년 7월 31일 (UTC)[]
  • 안녕! 나는 Phab 티켓 T284783에 따라 기호에서 현재 표시 중인 대명사로 바꾸는 내비게이션 팝업을 만들었어. 나는 이와 비슷하게 현재 논의의 결과를 이행할 수 있을 것이다. 어쨌든, 나는 당신이 왜 "성별 불특정"을 그 안에 넣고 싶어하는지 이해하지만, 내가 이 실과 이전의 연계된 토론에서 볼 수 있는 것으로 보아, 그러한 움직임에 대한 합의는 없다. 헉, 나는 "지정되지 않은" 선호 설정을 표현하는 꽤 괜찮은 방법은 단순히 인터페이스에 성별을 명시하지 않는 것이라고 생각한다; 나는 또한 우가포드가 위에서 말한 나머지 것에 동의한다. 간단히 말해서, 우리는 대명사에 대한 새로운 선호도를 도입할 수 있고, 그것은 몇몇 문제를 해결할 수 있지만, 사람들은 우리가 이미 그것에 대한 선호도를 가지고 있다는 것에 반대할 것이다. 또한, 그 작업(PHP, 데이터베이스 등)이 얼마나 걸릴지에 대한 나의 최악의 추정치는 이전 경험에 근거한 "영원한" 것이다. 그래서... 어떻게 해야 할지 모르겠지만 계속 논의에 따를게 다시 말하지만, 만약 어떤 것이 결정된다면 언제든지 나에게 ping해줘, 비록 나는 위에서 필요한 정확한 코드 변경이 이미 Writ Keeper에 의해 확인되었다고 보지만. 엔터프라이즈y (토크!) 08:00, 2021년 8월 1일 (UTC)[]
  • 위키피디아인으로서, 우리는 성별이 없다. 인간으로서(우리의 설명 뒤에) 우리는 남자든 여자든 둘 중 한 명이다. XY 또는 XX 크롬 조합을 어떤 것으로 식별하든 변경할 수 없다. 굿데이 (토크) 15:15, 2021년 8월 1일 (UTC)[]
  • User:King of Hearts(사용자:하트왕)별로 다음과 같은 네 번째 옵션을 선택할 수 있도록 지원하겠다.
    사용자 - 탐색 팝업에 표시
    Navigation 팝업 창에 표시
    그/그들 - 그/그들을 네비게이션 팝업에 보여준다.
    지정되지 않음 - 현재처럼 빈/빈/아무것도 탐색 팝업에 나타나지 않음
    그렇게 하면, "그들/테마"라는 대명사를 "적극적으로" 사용하기로 선택한 편집자들이 원한다면, 이제 사용자 이름에 대한 탐색 팝업에서 '그들/그들'을 볼 수 있는 옵션을 갖게 될 것이고, 위키피디아에 그들의 대명사를 충분히 신경 쓰지 않거나 나열하기를 원하지 않는 편집자들은 '지정되지 않은' 옵션을 사용할 수 있다. 두 경우 모두 시스템은 '그들/테마' 및 '지정되지 않음' 옵션에 단수 '그들'을 사용하지만, 탐색 팝업은 이전 옵션에 대해 단수 '그들'을 표시하고 후자의 옵션에 대해서는 공백/비움으로 표시한다. 나는 또한 Navigation 팝업에서 명시적인 "성별 불특정/비공개/보류 등" 문구에 반대한다. Navigation 팝업 대명사에는 불특정 옵션의 어떤 것도 나타나지 않아야 한다. Some1 (토크) 16:27, 2021년 8월 1일 (UTC)[]
    네 번째 옵션으로 이 제안지지하십시오. – 자신의 성 정체성을 공개하지 않고 선호하는 것과 그 대명사의 사용을 통해 비이성적 정체성을 적극적으로 표현하는 것에는 차이가 있다. 위키피디아에 공개되지 않은 자신의 성 정체성을 가지는 것을 선호하는 사람들에게 대명사가 부과되어서는 안 된다. RGlucester — 인터뷰 16:39, 2021년 8월 1일 (UTC)[]
  • 포괄적인 편집 환경을 추구하기 위해서는 편집자의 성 정체성을 존중해야 한다. 우리가 편집자들이 영어를 다시 쓰도록 내버려 둘 것을 요구하지 않는다. 그들은 그 사람의 성별에 대해 어떤 것도 암시하지 않는 단수 대명사로서 영어에 널리 사용되어왔다. 그리고 영어 웹사이트로서, 나는 정말로 우리가 그것을 그렇게 사용하는 것에 대한 어떤 문제도 보기 위해 애쓰고 있다. {{u Sdkb}}}talk 18:41, 2021년 8월 2일(UTC)[]
    Sdkb, 이 주장의 큰 아이러니한 점은, 위키백과 링크에서 증명된 바와 같이, 대다수의 "노래자" 영어 사용자들과 작가들을 배제하는 동시에, 성 정체성의 소수 집단을 위한 포괄적 편집의 기치를 자랑스럽게 흔든다는 것이다. 이는 '포용적 편집'이라는 명분을 더하는 데 아무런 도움이 되지 않으며 소수 집단을 위선적으로 보이게 만든다.Huggums537 (대화) 02:36, 2021년 8월 3일 (UTC)[]
    허금스, 이 토론이 열린 3일 동안 37번이나 코멘트를 하셨잖아요. 토론에 참여하는 것은 괜찮지만, WP에 들어가는 데는 한계가 있다.블러존 영역. 그 점에 유의하십시오. 네가 대답할 거면, 너의 주장에 대해 좀 더 명확하게 말해라. 나는 너의 요점을 이해하지 못한다. {{u Sdkb}}talk 02:45, 2021년 8월 3일 (UTC)[]
    방금 네 코멘트를 다시 읽었으니, 내가 "그들"을 사용하는 것에 반대하는 것으로 완전히 오해했을 수도 있을 것 같은데, 실제로 "그들"을 사용하는 것이 괜찮고, 완전히 잘못 반응한 것이다. 천 가지 사과. 그것은 오해였으므로 나는 그것을 기록에서 제외할 것이다. Huggums537 (대화) 03:10, 2021년 8월 3일 (UTC)[]
    그래, 내 코멘트는 단수형에 찬성해. 파업에 감사드리며, 좀 더 명확하게 해야 할 사람은 아마 나일 것이다. {{u Sdkb}} 14:58, 2021년 8월 3일(UTC)[]
  • 사용자의 희망에 따라 완전히 지정되지 않은 네 번째 옵션을 허용하는 제안을 지지한다. 우리는 우리가 일반적인 그를 강요하지 않는 것처럼 원하지 않는 사용자들에게 단수를 부과해서는 안 된다. 우리는 벼룩을 허용해야 한다. 위키피디아에서 내 성 대명사의 사용을 거부하는 사람으로서(여기서 내 성 대명사는 내 편집과 관련이 없기 때문에) 또한 "그들"을 거부하면서 억지로 하나로 만드는 것은 좌절감을 느끼게 하고, 단조로운 것을 허락하지 않는다. Spy-cicle💥 20Talk?:59, 2021년 8월 2일 (UTC)[]
  • 팝업 가젯에서 성별 출력을 제거하기만 하면 된다. 그럴 필요는 없다. 이것은 현재와 미래에 많은 양의 논쟁을 덜어줄 것이다.고스트인기계 09:09, 2021년 8월 3일 (UTC)[]
  • 특이점 - 이미 축소되었는가? [21]을(를) 검사할 때 팝업 디스플레이의 오른쪽 사용자가 'he'와 '그들'을 전달할 수 있다는 것을 알 수 있다. 이 팝업창은 다음과 같다: "개인 대명사: 그/그 사람, 단수들도 괜찮다." 그래서 "그들" 또는 다른 대명사 선택을 렌더링할 수 있는 유연성이 이미 있을 수도 있다. Enterprisey, Xaosflux 또는 팝업에 익숙한 다른 사람, 어디선가 설명되어 있는가? 알란스코트워커 (대화) 13:33, 2021년 8월 3일 (UTC)[]
    @Alanscottwalker: nav pops는 몇 가지 일을 한다. 사용자 예:레이크, 그들은 그들의 인터페이스를 male - 그리고 navpopus는 이것을 이용하여 팝업의 왼쪽 상단 모서리에 값을 채운다. 또한 Navpops는 페이지의 일부 미리보기 텍스트를 제공하며, 이 경우 사용자는 산문 Personal 대명사:he/...라는 문구를 삽입했다. 사용자 페이지로 이동하면, Navpopus가 그것을 가져와서 박스 하단의 미리보기 섹션에 배달했다. — xaosfluxTalk 14:00, 2021년 8월 3일 (UTC)[]
    아, 고마워! 그래서 팝업창에 '그들'이나 다른 것을 얻을 수 있는 방법이 있다. 팝업이 무엇을 가져오고 있는지 알 수 있는 방법이 있는가? - Alanscottwalker (대화) 14:14, 2021년 8월 3일 (UTC)[]
    @Alanscottwalker: 나는 기대하지 않는다 - NavPopups는 주로 기사를 위한 팝업을 가져오기 위한 보조 도구로 고안되었으며, 그것은 확실히 사용자 페이지의 위키텍스트에 키워드를 기반으로 무언가를 가져와 포함시킬 수 있다. 하지만, 그것은 대본을 부풀릴 것이고 그것을 사용하기를 원하는 사람들은 그들의 사용자 페이지에 마법의 닭을 흔들어 놓도록 요구한다. 스크립트는 다음과 같다: MediaWiki:기기 팝업.js. 그것은 일반적으로 어떤 페이지의 처음 몇 줄의 텍스트를 포함할 것이다.XaosfluxTalk 14:39, 2021년 8월 3일(UTC)[]
    그렇다면, 페이지에 첫 번째 "코딩되지 않은" 산문을 가져오는 것인가? -- 알란스코트워커 (토크) 15:05, 2021년 8월 3일 (UTC)[]
    @Alanscottwalker: (Wikilinks를 가져올 예정), 주변의 목표는 대부분 기사의 리드를 가져오는 것이므로 템플릿 등을 생략하려고 한다 — xaosfluxTalk 00:17, 2021년 8월 4일(UTC)[
    XaosfluxAlanscottwalker, 나는 또한 그것이 사용자 페이지에서도 첫 번째 이미지[및 Wikilink]를 캡처할 것이라는 것을 알아챘다. [예: 내 팝업을 참조하십시오.] 그래서 만약 LGBTQ 커뮤니티의 누군가가 무지개 깃발의 이미지를 날리고 싶다면, 만약 그들이 그런 식으로 사용자 페이지를 설정하는 데 어려움을 겪고 싶다면, 그들은 그렇게 할 수 있을 것이다. 또한, 앨런이 링크를 공유하고 이 이야기를 꺼낸 것에 대해 감사해. Huggums537 (대화) 08:40, 2021년 8월 4일 (UTC)[]
    그래서 생각났어... 사용자 페이지에 {{PrefersPronun(대명사 삽입)}}을(를) 쓸 수 있으며, 팝업이 현재 디스플레이를 그것으로 대체할 것이다. 생각? 엔터프라이즈y (토크!) 08:07, 2021년 8월 4일 (UTC)[]
    @Enterprisey: 통계적으로 대부분의 편집자들은 navpoppoppup을 사용하지 않으며, 훨씬 더 적은 수의 편집자들이 사용자 페이지에서 마법의 키워드를 검색하여 그것에 익숙해지도록 한다는 것을 명심하십시오(또한 쓰레기 값이 navpop을 엉망으로 만드는 것을 막기 위해 일종의 입력 검증이 필요할 수도 있음).xaosfluxTalk 09:56, 2021년 8월 4일 (UTC)[]
    위키피디아에 추가할 것을 제안한다.도구/내비게이션 팝업/FAQ(지독하게 쉽게 찾을 수 있는 것은 아님) 기술적인 문구/링크에 대한 도움이 필요하지만, 다음과 같은 것.
  • "Pronun 기본 설정 표시:
    사용자는 _______에서 gendered 대명사(그/그/그)를 선택할 수 있으며, 그렇지 않으면 시스템이 단수로 기본 설정된다. 사용자가 gendered 대명사를 선택할 때, 그들의 선택은 팝업에 표시된다. 중립 대명사를 포함한 팝업에 다양한 대명사 선택사항을 표시하는 또 다른 방법은 사용자 페이지를 구성하여 페이지의 첫 번째 설명되지 않은 산문이 '개인 대명사: (너의 대명사 선호, 여기)'와 같은 것을 명시하도록 하는 것이다.
    알란스코트워커 (대화) 15:11, 2021년 8월 4일 (UTC)[]
    엣지 케이스일 수도 있지만, 그것이 실제로 필요한 사람들에게 엄청나게 유용할 것이라는 점을 고려하면, 그것은 약한 주장이다. 내가 개인적으로 장담하는데, 팝업스 코드는 열차 파괴로 충분해서 몇 줄의 코드도 더 이상 "버림"하지 않을 것이다. 어쨌든, 방금 카테고리를 찾았어:대명사 사용자 템플릿, 그래서 그것들을 검토하고 팝업이 그것들을 읽도록 한다 (사용자 지정 대명사 허용에 더하여 - 하지만 그것은 팝업 메시지의 시작 부분에 나타나기 때문에, 사람들은 그것들을 일반적인 상태로 사용할 수 있다!) 엔터티(토크!) 18:14, 2021년 8월 4일 (UTC)[]
    나는 그것에 반대하지 않는다. 왜냐하면 그것은 결국 채택된 대본이기 때문이다.xaosfluxTalk 18:44, 2021년 8월 4일(UTC)[]
    아, 내가 오해했을 수도 있어. "지원할 가치가 너무 많은 에지 케이스"에서와 같이 "에지 케이스"를 의미한다고 생각했지만, "에지 케이스"를 "에지 케이스"에서 "에지 케이스"를 의미한다면, "우리는 틈새 기기에 영향을 미치는 틈새 템플릿"은 매우 발견하기 불가능하고 따라서 대부분의 사람들에게 쓸모없는 것이기 때문에 사용자에게 더 잘 보이게 해야 한다."에서, 그렇다, 전적으로 동의한다. 엔터프라이즈y (토크!) 22:00, 2021년 8월 4일 (UTC)[]
    Enterprisey, 내가 제대로 이해하면 사용자 페이지의 첫 번째 텍스트 줄 앞에 상태를 추가하기만 하면 팝업을 일반 상태로 이미 사용할 수 있는 거지요? Huggums537 (대화) 06:44, 2021년 8월 5일 (UTC)[]
  • 다른 사람들이 작성한 것과 마찬가지로 기존 메시지들은 사용자가 성별을 정의하지 않으면 성별이 아닌 사생활의 이유로 인해 작성된다고 가정한다. 만약 이 제안이 통과된다면, 그것은 성 마술 단어로 모든 메시지를 작성/편집할 필요가 있고, 그것들을 비밀리에 동의된 편집자들을 위한 단어로부터 그들 자신을 남성 또는 여성으로 정의하지 않는 편집자로 다시 쓰여질 필요가 있다. 만약 그것이 이루어지지 않는다면, 우리는 성 중립적인 사용자들이 부적절한 메시지로 인해 혼란에 빠지게 될 것이다. 이것은 대명사만의 문제가 아니라, 어떤 메시지들은 어떤 대명사를 사용해야 하는지에 근거하여 특정한 방식으로 쓰여진다.--Snævar (talk) 23:43, 2021년 8월 3일 (UTC)[]
    이 토론 내내 산재된 몇몇 논평은 성별 선호 설정의 목적이 무엇인지에 대한 주장을 해왔다. 몇 달째 이 일을 이리저리 살펴보다가 몇 가지 결론을 내렸다. 첫째는 다음과 같다. 이 설정은 영어 때문에 존재하지 않는다. 두 번째는 다음과 같다. 그건 네 정체성에 관한게 아니야.
    언어가 그대로라면, 모든 언어는 성별에 대한 글쓰기에 어떻게 대처해야 하는지에 대한 자신만의 생각을 가지고 있다. 영어를 포함한 몇몇 사람들은 다른 사람들에 비해 그것에 거의 관심을 두지 않는다. 일부에서는 화자 및/또는 주제의 성별에 대한 언어적 끄덕임이 만연해 있다. 러시아어가 대표적인 예다. '특집'에서 확인할 수 있을 수 없는 일:"WhatamIdoing이 Tyop을 Tyop을 Typo로 이동"과 같은 문장을 로그에 기록한다. 러시아어에서는 이 문장의 동사에 문법적인 성별을 할당해야 한다. 당신은 "WhatamIdoing she moved Tyop to Typo" 또는 "TyopTypo에 모이도록 한 그 남자"를 써야 한다. 러시아어로는 "중립적인" 옵션이 없다. 당신은 그 언어에 대해 알거나 불특정 성별 채무불이행을 사용해야 한다.
    성별을 알 수 없는 사람에 대해 글을 쓰는 경우 언어마다 접근 방식이 다르다. 영어에서, 우리는 종종 만약 개인 대명사가 필요하다면 단수로 디폴트하지만, 대부분의 대명사는 필요하지 않고, 성별은 그렇지 않으면 영어 문법에 영향을 주지 않는다. 러시아어로, 나는 그들이 알려지지 않은 주제에 대해 남성적인 것으로 디폴트(현재/여전히)한다고 이해한다. 독일어에서는, 비록 그 사람의 성별을 안다고 해도, 당신은 "Die Person이 그녀의 페이지를 옮겼으며, 더 Editor는 그의 페이지를 편집했고, Das Neue는 그 질문에 대한 도움이 필요하다"라는 사람보다는, 명사에 속하는 문법적인 성별을 사용한다.
    기본 메시지: 이 설정의 요점은 자동화된 메시지가 모든 언어에서 합리적인 문법적 선택을 할 수 있도록 하는 것이다. 이 설정이 기능적이기 위해서는 문법 요구에 부합해야 한다. 기존의 세 가지 옵션 중 하나로 문법적으로 올바른 문장을 영어로 구성할 수 있다. 그러므로 영어는 네 번째 문법 선택권이 필요하지 않다. (스웨디쉬의 힘; 그들의 네 개의 대명사는 대략 그/그/그/그 밖의 그것이다.) 만약 당신이 당신의 신상을 발표하기 위한 선택권을 원한다면, 그것은 정말로 번역에 초점을 맞춘 이 환경에서 혼동되어서는 안 된다. Whatamidoing (WMF) (토크) 20:06, 2021년 8월 6일 (UTC)[]
    • 들어봐, 들어봐! 내가 알기로는 이것은 100% 정확하다. 또한 이러한 번역 작업에 깊이 빠져 있던 사람들로부터 받은 인상은 기존의 세 가지 옵션이 기본적으로 모든 언어의 목적에 충분하다는 것이다.
      영어를 사용한다고 해도, 클링온이나 신다린, 시멜리쉬 등으로 인터페이스 언어를 설정한 사람들에게도 동일한 선호 가치를 사용할 필요가 있다는 점에 유의하십시오. 일부 언어는 애니메이션/무생물(예: "it"), 형식/정보, 성인/어린이 등의 차이를 가지고 있지만, 이러한 것들은 여러 언어에서 그다지 이해되지 않는 혼란스러울 정도로 복잡한 선호도를 갖지 않는다는 점에서 무시될 수 있다. 예를 들어, "그것"은 봇을 의인화하기를 원하지 않는 사람들에게만 실제로 관련될 것 같다.
      개인적으로, 나는 미디어위키 토크에서 설명한 선호 텍스트의 최근 변화를 본다.당신의 성별은 한 걸음 뒤로, 그들이 사람들을 혼란스럽게 해서 "지정되지 않은" 것과 "중립된 채무불이행" 사이에 의미 있는 구분이 있다고 생각하는 것 같다. 모든 선호도는 말 그대로 "미디어위키가 당신을 문법적으로 어떻게 묘사해야 하는가?"라는 것인데, 미디어위키는 당신이 특정하지 않았기 때문에 또는 "그들"을 특별히 선택했기 때문에 또는 "그들"을 선택했기 때문에 "그들"을 사용하든 "그들"을 선택하기 싫어서 "그들"을 선택했기 때문에 "그들"을 사용하든 상관없다. 그것이 바로 그 툴의 개발자들이 그것을 실현하고자 하는 어떤 구체적인 방법으로 팝업스가 그것을 대변해야 하는 방법이다. Anomie 03:25, 2021년 8월 7일 (UTC)[]
    • 만약 당신이 MediaWiki가 당신을 언급하거나 묘사하는 것을 전혀 원하지 않는다면? opt out? 블루보어 (토크) 12:04, 2021년 8월 7일 (UTC)[]
      • 그렇지 않아, 너는 다른 사람들에게 너의 행동을 숨길 수 없어. 유일한 해결책은 애당초 어떤 행동도 하지 않는 것이다. 계정을 만들더라도 "사용자 계정 X가 생성됨"의 줄을 따라 로그 항목이 생성되므로 계정을 만들지 않는 것부터 시작해야 한다는 점에 유의하십시오. Anomie 12:49, 2021년 8월 7일 (UTC)[]
        • 이 스레드가 닫히기 전에, 나는 그 제안이 성별 설정의 문법적 구조를 바꾸는 것을 목표로 한 것이 아니라는 것을 지적하고 싶다. 그리고 그 모든 것의 요점은 단지 현재 그들이 발음하는 기본 단수형을 제외한 팝업을 항해하는 데 있는 기존의 모든 설정을 보이는 것에 지나지 않았다.팅(ting)은 남성/여성 대명사 설정을 포함한다. 단, 설정의 문법적 기능성이 항법 팝업에 설정의 표시 여부에 관계없이 동일하면 설정의 가시성을 제외할 타당한 이유가 없다. Huggums537 (대화) 17:01, 2021년 8월 28일 (UTC)[]
    선택의 자유와 관련된 모든 것들과 관련하여, 나는 우리가 익명성을 다루고 있다는 단순한 이유로 우리가 그것을 토론하고 있다는 사실까지 포함한 이 모든 제안들에 반대한다. 우리는 피트를 위해 누구와 협력하고 있는지도 모른다. 이곳은 대학 캠퍼스가 아니라 익명의 자원봉사자들이 모여 있는 가상의 커뮤니티인데, 이들은 모두 백과사전을 만드는 것을 돕기 위해 이곳에 있어야 한다. 왜 우리가 여기 있는 일과 이유가 아닌 성별에 초점을 맞추고 있는 걸까? 만약 그 기사가 성별과 관련이 없다면, 계속 진행하십시오. 우리는 이 백과사전을 만드는 것과 직접적으로 관련된 중요한 논의의 중심에 있을 때 익명 편집자의 대명사 선호를 체크하러 갈 시간이 없다. 우리는 자원 봉사자들에게 초점을 맞추지 말아야 한다. 나는 인종, 피부색, 신조, 성별에 관계없이 서로를 존중하는 것이 기대된다고 믿는다. 익명성 때문에 우리가 아는 것은 하나도 없고, 나는 모르는 것이 행복하다. 여기 있는 모든 사람들의 시간은 소중하고 동등한 고려를 받을 가치가 있다. 무엇보다 TP토론에서 반대하는 익명편집자의 적절한 대명사를 잊어버린 편집자가 잘못된 대명사를 사용했다는 이유로 드라마 게시판에서 자신을 발견한다는 생각이 두렵다. 나는 이미 그런 일이 일어나는 것을 보았다. 변수가 너무 많고 WP에 위키와이저가 너무 많다. 내가 기분이 상했을 때 행정관으로부터 받은 충고를 공유하겠다: "두껍게 자라". Atsme💬📧 13:42, 2021년 8월 7일 (UTC)[]
    Atsme를 존경하지만, 그들은 고의적으로 그리고 의도적으로 장기간에 걸쳐 누군가를 잘못 속이는 사람들이었다. 나는 당신이 이미 알고 있다고 확신한다. 경각심을 가질 필요는 없다. 실수는 가끔 일어나는데, 네가 "무서운" 것으로까지 확대되는 건 본 이 없어. 만약 그렇게 된다면, 거의 즉시 해고될 것이다. Symmacus Auxinus (talk) 00:54, 2021년 8월 8일 (UTC)[]
    Atsme, 당신은 또한 위키피디아 구축과 관련이 없다는 근거로 전체 토론을 반대하는 입장을 정당화하기 위해 전체 대화를 익명의 지원자와 그들의 성별에 초점을 맞추는 것으로 지나치게 단순화했다. 그러나, 많은 사람들이 그들의 사생활에 관한 생각과 의견, 그리고 성별뿐만 아니라 선택할 권리까지 여기에 참여했다는 사실은 이 토론에서 위키피디아 사람들에게 중요한 문제들이 있다는 충분한 증거가 되며, 명백히 지역사회 토론에서 고려할 가치가 있고, 그렇지 않으면 우리는 전혀 참여하지 않을 것이다. 나는 당신이 위키피디아를 만드는 정신을 암시하는 동시에 그들이 토론에 참여했다는 이유로 전체 공동체를 무시하는 것에 대해 어떠한 정당한 이유도 없다고 본다 - 공동체 토론 자체가 "백과사전 구축"의 중요한 부분이라는 것을 명심하라. 토론 없이는 합의도 없고, 그것 없이는 위키피디아를 만들 필요도 없다. Huggums537 (대화) 07:31, 2021년 8월 8일 (UTC)[]
    Symmacus Auxinus, 나는 그 사건을 언급하고 있지 않았다. 허금537, 당신의 우려는 이해하고 공감하지만, 결론은 변하지 않았다. 우리는 편집자가 아니라 편집에 집중하기 위해 여기에 있다. 우리는 백과사전을 만드는 것을 돕는 것 외에 다른 어떤 목적에도 시간을 자원하지 않았다. 즉, 콘텐츠를 만들고, 기사를 복사하고, 공공 기물을 파손하는 것을 멈추게 하고, 새로운 기사의 기사를 편집하는 것을 돕는 것 등이다. 우리는 사회적 이슈를 옹호하는 사회적 플랫폼이 아니며 또한 WP도 있다.RGW. 그것들은 우리가 백과사전을 만드는 것을 돕기 위해 우리의 귀중한 시간을 자청한 편집자로서 WP에서가 아니라, 우리가 실생활에서 보내는 시간에 바치는 것이다. 우리는 익명성을 선택할 것인지 아니면 우리의 실제 삶의 정체성을 알릴 것인지 선택할 것이다. 어느 쪽인가? 그 너머로는 우리가 예의(대단한)를 넘어 도움이 될 만한 어떤 의무도 있어서는 안 된다. 상처받는 PA를 출범시키고 기사나 다른 WP 행사장에서 모호하지 않은 혼란을 야기하는 것과 같은 그 어떤 것이라도 조치를 취할 수 있을 것이다. 하지만 그것이 우리가 관리자들을 둔 이유다. '생각하는 경찰' 역할을 하는 것도 편집자의 책임이 아니다. 아마도 이 에세이는 내가 처음 그것을 읽었을 때 그랬듯이, 우리 모두에게 적용되었듯이, 사물을 관점에 두는 데 도움이 될 것이다. 나는 말에 막대기와 돌로 접근하는 방식을 채택했다. 그것은 현실 세계에서 사는 것이 더 현실적인 접근법이기 때문이다. Atsme💬 16:11, 2021년 8월 8일 (UTC)[]
    아츠메, 내가 보기엔 여기 다른 편집자들에게 초점을 맞추고, 사회적 이슈를 옹호하거나, 백과사전을 만들지 않는 큰 잘못을 바로잡는 것은 사실 당신 자신인 것 같다. 나는 개인적으로 위키피디아에 강하게 반대한다.위키피디아는 '너'가 없으면 위키피디아가 없다는 아주 간단한 사실 때문에 (내가 저자를 존중하지만) 당신이 필요하지 않다. 에세이의 유형이 제공하는 유일한 실제 목적은 다른 사람들을 경멸하는 것이다. 심지어 당신조차도 그것이 "충격적으로" 당신의 관점에 놓여졌다는 것을 인정하며, 나는 누군가가 그러한 관점을 받아들이도록 하는 충격 상태에 있어야 한다고 생각한다. 그러나 고려할 가치가 있는 다른 에세이는 다음과 같다: 위키백과:편집자 자료위키백과:위키피디아는 하나의 공동체다. Huggums537 (대화) 19:55, 2021년 8월 8일 (UTC)[]

측량(대체)

  • 여기서 기고하는 편집자들은 중립적 옵션이 선택되었음을 다른 사람들에게 알리기 위해 탐색 팝업 디스플레이에서 사용할 수 있는 제안서 이외의 다른 문구에 대해 어떻게 생각하는가? 생각나는 몇 가지 예는 다음과 같다.
    1. 성별 미공개
    2. 성별 보류
    3. 중성 대명사
    4. 선택한 대명사 없음

Huggums537 (대화) 01:04, 2021년 8월 1일 (UTC)[]

  • 지원 옵션 3 또는 4는 성 언어를 사용하지 않으며, 그와 그녀의 모델이 그렇게 하는 것처럼 대명사 사용만을 참조한다. 이것은 어떻게 이 모든 것이 언어에 관한 것인지, 그리고 어떻게 성보다는 대명사가 사용되는지에 대한 과거의 논의와 더 일치한다. Huggums537 (대화) 01:27, 2021년 8월 1일 (UTC)[]
  • 옵션 5, 위와 같은 것은 없다. 즉 그대로 두라는 것이다. 위와 같이 소통하려고 노력했으므로 대명사 디스플레이를 만지작거릴 이유가 없다. JohnFromPinckney (대화/편집) 09:59, 2021년 8월 1일 (UTC)[]
    존프롬피니, 난 네가 위에서 대화하려고 했던 곳을 본 적이 없어... Huggums537 (대화) 13:31, 2021년 8월 1일 (UTC)[]
    바로 그거야 나는 이 전에는 아무것도 쓰지 않았다. 당신은 그것이 의사소통을 할 것이라고 생각하는가? JohnFromPinckney (대화/편집) 05:36, 2021년 8월 3일 (UTC)[]
    존프롬피니, 알았어, 알았어. 그것은 낚시꾼에게 꽤 좋은 미끼였다. Huggums537 (대화) 06:22, 2021년 8월 5일 (UTC)[]
    이 응답으로 스드라카즈(토크) 00:03, 2021년 8월 6일 (UTC)[]라는 좋은 킥킥을 얻었다.
  • 옵션 5, 위와 같은 것은 없다. 이것은 성별을 명시하는 것이 아니라 대명사를 명시하는 것이다. 자연 영어에서 누군가를 위해 대명사를 사용하는 것을 쉽게 피할 수 있는 방법은 없다. 실행 가능한 유일한 옵션은 (a) 그/그/그/그들/그들/그들/그들/그들/그들/그들/b) (b) (예를 들어) 더 많은 선택권을 도입하거나, (c) 사람들이 연설의 각 부분에 대해 그들이 원하는 것을 쓰는 무료 텍스트 박스가 있거나, (d) a+c 또는 b+c의 조합이다.c의 조합이다. 모든 경우에 기본값(기본값) 또는 사용자가 편집이 허용되기 전에 명시적으로 선택해야 하는 요구사항이 있어야 한다(미등록 사용자의 편집 허용과 호환되지 않음). 내가 기꺼이 a, b, d(그리고 c)를 지지하겠지만, 이것은 여기서 제안되고 있는 것이 아니다. Thryduulf (대화) 11:15, 2021년 8월 1일 (UTC)[]
    이것에 대해 더 생각해 보면, 현재의 세 가지 선택권에 변화가 없는 한, 1, 2, 4의 모든 선택권은 그나 그녀만이 유효한 선택이므로 적극적으로 해로운 것으로 반대해야 한다는 것을 의미하며, 3은 본질적으로 다른 것을 적극적으로 선택하지 않은 한 성별 중립으로 디폴트되는 현상이다. Thryduulf (대화) 13:41, 2021년 8월 1일 (UTC)[]
  • Huggum537당 지원 옵션 3 또는 4개. 이상적으로 우리는 사람들이 덜 보편적인 선택사항들을 수용하기 위해 그들이 원하는 어떤 대명사든지 선택할 수 있는 무료 텍스트 옵션을 가지고 있을 것이다. 우리가 그것들을 모두 열거할 필요가 없고 아마도 몇몇 유효한 선택사항들을 놓칠 필요가 없을 것이다. 불행히도, 나는 "공격용 헬리콥터" 위니들이 그것에 "재미있는" 아이디어를 가지려고 할 것이라고 확신하기 때문에, 그것은 약간의 치안유지활동이 필요할 것이다. 어차피 우리가 알고 있는 것은 사용자가 세 가지 옵션 중 하나를 선택했다는 것뿐이기 때문에 이 옵션은 여기서는 선택사항이 아닌 것 같다. 사용자가 원하는 것에 대한 추가 정보 없이 3, 4가 최선이다. --다니엘 리갈 (대화) 13:15, 2021년 8월 1일 (UTC)[]
  • 의 것들 중 어느 것도 - 나는 네가 내 이름 위를 맴돌 때 내 성별이나 대명사에 대해 어떤 도 나타나기를 원하지 않는다. "이 사용자가 선택하지 않았다"거나 "지정되지 않았다"거나 하는 말은 하고 싶지 않다. 단추를 클릭하지 않으면 아무 것도 나타나지 않는다는 사실이 좋아. 블루보어 (토크) 14:29, 2021년 8월 1일 (UTC)[]
    블루보어, 버튼을 클릭해도 아무 것도 나타나지 않는다. Huggums537 (대화) 14:40, 2021년 8월 1일 (UTC)[]
아… 버튼을 클릭할 때 어떤 일이 일어나든, 일어나지 않을 때는 아무 것도 나타나지 않는 한 상관하지 마라. 블루보어 (토크) 15:01, 2021년 8월 1일 (UTC)[]
클릭을 원하는 사람(이러한 클릭 버튼을 원하는 사람)이 클릭할 수 있는 버튼이 3개 이상 필요한 것이 문제인가? 블루보어 (토크) 15:52, 2021년 8월 1일 (UTC)[]
블루보어, 나는 많은 사람들이 그것이 문제라고 말하고 있다고 생각한다, 그렇다. Huggums537 (대화) 06:17, 2021년 8월 5일 (UTC)[]
  • 주석 - 편집자가 Banjo로 식별하면 어떻게 하시겠습니까? 정말 중요한가요? 굿데이 (토크) 17:21, 2021년 8월 1일 (UTC)[]
나는 누군가가 그것의 사용자 이름 위에 있을 때 밴조가 선호하는 대명사로 "it/its"를 표시하기를 원한다고 가정한다(아마도 잘못되었을 것이다). 아니면 적어도 그걸 옵션으로 가지고 있어. 블루보어 (토크) 17:35, 2021년 8월 1일 (UTC)[]
특히 저자의 맥락을 고려할 때 이 논평은 비이성적이라고 밝힌 개인들을 조롱하는 것으로 보인다. 그건 절대 용납할 수 없어. {{u Sdkb}}}talk 18:31, 2021년 8월 2일(UTC)[]
그것은 내 견해의 논평에서 너무 많은 것을 추론하고 있을지도 모른다. 인터넷 상에서, 아무도 당신이 개(또는 "반조")라는 격언을 언급할 수 없다는 것을 알고 있었기 때문이다. 내가 알기로는 굿데이는 인디브듀얼을 조롱한 이력이 없다. Spy-cicle💥 16:12, 2021년 8월 6일 (UTC)[]
굿데이가 '개인 조롱의 역사'를 갖고 있는지, 없는지는 전혀 의미가 없다. 최악의 경우 그것은 다른 사용자를 조롱하는 논평을 요구하지 않으며, 기껏해야 대화에 전혀 도움이 되지 않는다. Aza24 (토크) 20:00, 2021년 8월 7일 (UTC)[]
이것은 알려진 트랜스 공포증 농담이다. 선의라고 가정한다면, 굿데이는 아마도 그들 자신의 충고에 귀를 기울이고 이 토론과 성 정체성과 관련된 다른 모든 토론에서 고개를 숙여야 할 것이다. 이사벨🔔 13:35, 2021년 8월 8일 (UTC)[]
사실, 나는 위키피디아의 정치적 올바름에 대한 팬이 아니다. 이 주제에 대해서. 그러므로 나는 그러한 논의에 참여하는 것을 전반적으로 꺼린다. 자, 여러분, 이제 더 이상 핑을 대지 마십시오.) 굿데이 (토크) 13:51, 8월 8일 (UTC)[]
  • 지원 옵션 4 사용자의 희망에 따라 완전히 지정되지 않은 사용. 우리는 우리가 일반적인 그를 강요하지 않는 것처럼 원하지 않는 사용자들에게 단수를 부과해서는 안 된다. 우리는 벼룩을 허용해야 한다. 위키피디아에서 내 성 대명사의 사용을 거부하는 사람으로서(여기서 내 성 대명사는 내 편집과 관련이 없기 때문에), 또한 "그들"을 거절하는 사람으로서, 강제로 하나로 만드는 것은 좌절감을 느끼게 한다. 그저 그 벼락부자가 아무 것도 갖지 못하게 내버려 두어라. Spy-cicle💥 20:59, 2021년 8월 2일 (UTC)[]
    의견을 중복하지 마십시오.-Qwerfjkltalk 21:21, 2021년 8월 2일 (UTC)[]
    스파이-시클, 안녕. 현재 두 가지 다른 옵션 4를 지원하고 있는 것으로 보인다. 앞의 절에서 언급한 '옵션 4'는 이것과 다르다. 알란스코트워커 (대화) 13:52, 2021년 8월 3일 (UTC)[]
    첫 번째 토론 질문이 명확하지 않았기 때문에 알란스코트워커를 명확히 한다. 나는 사용자들이 불특정 성/성 대명사를 가질 수 있도록 하는 동시에 불특정 성/성 대명사를 선택하는 사람들이 "그/그들"을 갖지 않을 수 있도록 하는 모든 옵션을 지지한다. 그게 도움이 되길 바래. Spy-cicle💥 15Talk?:55, 2021년 8월 6일 (UTC)[]
  • 질문: "기본" 설정을 사용하지 않을 수 있는 방법이 있는가? (전혀)? 블루보어 (토크) 14:20, 2021년 8월 3일 (UTC)[]
    @Blueboar: 아니, 이 데이터베이스 값에 대한 스키마가 값으로 "nul"을 허용하도록 확장되었더라도 - 무언가가 여전히 'default'일 것이다(그것도 "nul"이었다). 현재 기본값은 지정되지 않음.xaosflux 15:01, 2021년 8월 3일(UTC)[]
아... 그게 문제야. 블루보어 (토크) 16:36, 2021년 8월 3일 (UTC)[]
  • 옵션 5, 수년간 Nav Pops를 사용해 온 MediaWiki 설정을 수정하십시오. 어느 순간 나는 팝업창에 남자 또는 여자 기호가 있다는 것을 알아차렸다(최근에 그/그녀로 바뀌었다). 또한 일부 사용자(나처럼)는 자신의 성별(프로노운)을 선택하지 않았기 때문에 기호가 없다는 것도 알아챘다. 가젯을 사용하는 대부분의 사용자들은 결국 어떻게 작동하는지 이해할 것이기 때문에 추가적인 "성별 불특정" 텍스트로 이 작은 팝업을 복잡하게 만들 필요가 없다. 해당 사용자가 보이지 않으면 "그들"을 사용하거나 편집자의 사용자 페이지에서 해당 사용자의 선호도에 대한 추가 정보가 있는지 확인하십시오. 하지만, 나는 미디어위키 설정에 네 번째 옵션이 있어서, 실제로 남성/여성 대명사가 아닌 다른 것을 선택하고자 하는 사용자들을 위한 실제 옵션이 있다면 가장 좋을 것이라고 생각한다. 그러면 Nav Pops 기기는 정말로 그것을 선택한 사람들을 위해 "그것들"을 보여줄 수 있을 것이다. -kykaarme (대화) 19:41, 2021년 8월 3일 (UTC)[]
  • 지원 3 4: 성별을 지정하지 않은 사용자는 "지정되지 않음"으로 기본 설정되어야 하며 팝업에서 렌더링이 없어야 한다. 대명사가 자신인 사용자는 "그/그들"이 팝업 화면에 나타나도록 해당 설정을 선택할 수 있어야 한다. "공개되지 않음"과 "보류되지 않음"은 우리가 이것을 비누상자에 사용하기를 원하지 않는 한 "지정되지 않음"에 해당된다. 이상적으로는 사용자가 지정한 모든 것을 팝업에 렌더링하도록 하지만 소프트웨어가 성별 중립(템플릿과 그렇지 않은 것)과 동일하게 취급할 수 있는 다섯 번째 무료 텍스트 설정이 있지만 관리자가 이를 무시하지 않으면 이는 공공 기물 파손에 대한 개방적인 문이 될 것이다. 이반벡터의 다람쥐 (/)treesnuts 15:06, 2021년 8월 5일 (UTC)[]
  • 모든 것에 반대하라 - 내가 위에서 논의한 바로는. Atsme 💬 14:09, 2021년 8월 7일 (UTC)[]
  • 모두 반대 - 우리는 무작위 잡동사니를 하기 위해서가 아니라 백과사전을 만들기 위해 여기에 있어야 한다. 50.201.201.228.202 (대화) 15:16, 2021년 8월 7일 (UTC)[]
    50... 얼마만큼의 가치가 있는지는 모르지만, 이 논의의 어떤 부분도 계정이 없는 편집자의 영향을 미치지 않을 것이다.Xaosflux 17:24, 2021년 8월 7일(UTC)[]
  • 위와 같은 나의 논평에 모두 반대하라. 조사라는 꼬리표가 붙었음에도 불구하고, 이 섹션은 현상 옵션을 배제하는 어떤 조사도 본질적으로 주도적이기 때문에 실행 가능한 합의에 도달할 가능성이 없다. {{u Sdkb}}}talk 17:56, 2021년 8월 7일(UTC)[]
    SdkbSteffle, 나는 현상유지를 선정의 하나로 추가할 생각은 하지 않았고, 의도적으로 누구를 이끄는 것도 아니었다. 현재 상황도 선택이었다면 두 분 중 한 분이 선택권을 고려하시겠습니까? 또한, 내가 누구를 이끌지 않기 위해 소급해서 현 상태를 선발에 추가해도 모두가 괜찮을까? Huggums537 (대화) 22:41, 2021년 8월 9일 (UTC)[]
    13개 이상 응답한 후? 아니, 너무 늦었어. JohnFromPinckney (대화/편집) 22:54, 2021년 8월 9일 (UTC)[]
    좋아, 어차피 거기 있을 필요는 없으니까 괜찮아. 왜냐하면 나는 많은 다른 사람들이 그들이 선택할 수 있는 선택도 없이 그리고 그들이 그들을 이끄는 사람에 대해 아무런 암시도 하지 않고 현상유지를 선택할 수 있다는 것을 관찰해왔기 때문이야. 그러므로, 어쨌든 그 선택이 진정으로 필요하지 않다는 것이 어떤 선의를 가지고 있는지는 누구에게나 꽤 명백하게 보여져야 한다. Huggums537 (대화) 23:10, 2021년 8월 9일 (UTC)[]
  • Sdkb당 모두 반대한다. 숨막힘 (대화) 2021년 8월 9일 16:30 (UTC)[]
  • Some1에서 제안한 4가지 옵션을 지원하십시오. 클로버모스 (대화) 22:38, 2021년 8월 18일 (UTC)[]

토론: 선택적 사용자 생성 선택사항

Xaosflux, AlanscottwalkerEnterprisey 간에 사용자 생성 스크립트를 활성화하거나 사용자가 사용자 페이지를 변경할 경우 자신의 팝업을 생성할 수 있음을 알려주는 알림 메시지를 게시하는 것에 대해 위에서 몇 가지 대화가 있었다. 나는 또한 Valeree와 같은 사용자들이 그러한 아이디어에 찬성하는 반면 Kykaarme와 TheDJ는 사람들에게 이것이 그러한 사용자들에게 실행 가능한 옵션이 될 수 있다는 것을 나타내는 사용자 페이지를 확인하라고 제안했다. 나는 또한 이 옵션에 대한 지역사회의 의견을 듣고 싶다. 이 전체 스레드의 결과가 어떻든 간에, 내 사용자 이름 위에 마우스를 올려놓고 네비게이션 가젯을 기본 설정에서 사용 가능으로 설정했을 때 볼 수 있는 예로서 나는 이미 최근에 내 사용자 페이지에서 이 옵션을 활성화했다. Huggums537 (대화) 11:45, 2021년 8월 7일 (UTC)[]

@Huggums537: 나는 현재 내 프로필에 있는 {{User Thees 대명사} 인포박스를 사용해 다른 사람들에게 나의 선호도를 알리고 있다. 지금 당장은 그것이 최선의 선택이고, 단지 자신의 대명사가 그들의 서명에 있는 것(미적 이유로 나는 하지 않는 것이 더 좋다)에 부차적인 것이다. 나는 그 정보를 팝업 기기로 바꾸는 방법을 갖는 것이 모든 사람들을 더 쉽게 만들 것이라고 생각한다. 나는 개인적으로 이 팝업창을 사용하여 전에 이야기하지 않은 사람과 대화할 때 다른 사용자의 대명사를 확인한다. 이사벨🔔 13:40, 2021년 8월 8일 (UTC)[]
이사벨 벨라토, 그래, 나도 내 선택에 같은 사용자 박스를 사용하고 있어. 그러나 선택 항목은 탐색 팝업에도 나타나지 않는다. 나는 그것을 서명에 넣을 생각을 하지 않았었다. 그것은 참신한 아이디어지만, 나는 오히려 내가 현재 사용하고 있는 접근법을 사용하여 내 사용자 페이지에 텍스트 줄을 추가하고, 그것이 내 문제를 해결해주기 때문에 내비게이션 팝업이 그것을 가져올 수 있도록 허락하는 것을 좋아하는데, 내 제안에서 내가 제안한 것은 아무것도 통과하지 못할 것 같지만, 커뮤니티가 다른 사람들에게 그들이 같은 일을 할 수 있다는 것을 알리기 위해 어딘가에 기호를 붙이기를 희망한다. 그들이 선택했다면 내가 한 짓이야 Huggums537 (대화) 18:10, 2021년 8월 8일 (UTC)[]

2021 RfA 검토

나는 RfA에 어떤 문제가 있는지 확인하기 위해 2021년 RfA 검토를 시작하고 RfC에 동봉했다. 관심 있는 편집자들은 참여하도록 초대된다. Best, Barkeep49 (대화) 01:41, 2021년 8월 29일 (UTC)[]