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

다른 곳으로 리디렉션되지만 별도의 페이지가 필요한 페이지에 Falseredirect라는 템플릿 추가 및 사용

이 글을 올리기에 가장 좋은 곳이 아니라면 미안하고, 만약 그렇다면, 어떤 페이지에 올리는 게 더 좋은지 말해줘.

기본적으로 러시아어 위키백과에는 다른 페이지가 리디렉션되는 페이지의 시작 부분에 사용되는 템플릿이 있지만, 해당 페이지가 다음과 같은 다른 주제 때문에 리디렉션하는 대신 별도의 기사가 필요한 경우:
"페이지"는 여기서 리디렉션된다.이 주제는 별도의 기사가 필요하다.
이것은 매우 유용한 템플릿이지만, 영어 위키백과에서는 본 적이 없고, 다른 언어는 러시아의 언어뿐이며, 같은 방식으로 행동하는 템플릿도 본 적이 없다.그렇다면 사람들에게 영어 위키피디아에 이 템플릿을 구현할 것을 요청하는 곳은 어디일까?물론 이 템플릿은 내가 직접 번역할 수 있지만, 사용하지 않고 아마 삭제될 거야.카피네이터 (대화) 10:49, 2020년 8월 3일 (UTC)[응답]

템플릿 {{R 가능}}을(를) 가지고 있지만, 대상 기사보다는 리디렉션에 들어간다.이것이 유용할 수 있는 예를 들 수 있는가?제목이 다른 기사로 리디렉션되지 않으면 적어도 짧은 스텁을 쓰거나 리디렉션을 완전히 삭제하여 제목을 빨간색 링크로 만드는 것이 더 낫다고 생각하십니까?필 브리저 (대화) 10:59, 2020년 8월 3일 (UTC)[응답]

예를 들어 내 템플릿은 자동으로 슈퍼 마리오 64 DS에서 슈퍼 마리오 64로 리디렉션되는 사람들에게 유용하다(이것이 현재 러시아 위키에서 사용되고 있는 방법이다).그들은 템플리트와 같이 다른 기사가 필요한 다른 주제라는 것을 알게 될 것이다.리디렉션은 사람들에게 리디렉션과 이름이 같은 다른 주제에 대한 설명 페이지가 있음을 보여준다.위키백과 편집자들을 위해, 이것은 그들이 어떤 페이지를 만들 수 있는지를 보여줄 것이다.너의 템플릿에 대해서는, 너의 템플릿이 명확하지 않게 리디렉션 대신 새 페이지를 만들 수 있다는 글이 어디에 쓰여 있는지 확실히 알 수 없었다.또한, 리디렉션 페이지에 표시되는데, 독자와 편집자 모두 별도의 페이지가 필요한 리디렉션이 있다는 것을 분명히 알 수 있는, 저와 달리 리디렉션 페이지로 이동하지 않는지는 볼 수 없을 겁니다.

카피네이터 (대화) 18:33, 2020년 8월 4일 (UTC)[응답]

나는 "위키피디아에는 [재직권-제목]에 대한 기사가 없다"와 같은 내용의 해트노트를 전시하는 것이 아이디어라고 생각한다. [편집자 쓰기에 대한 pipped link to write one]!"그러나 이 위키에서는 약간 문제가 있다. {{R} 가능성 있는}}} 초안 제목 확인과 이 템플릿이 동일한 작업을 하기를 원할 것 같다. 또한 영어 위키피디아는 메인 공간에서 기사를 작성하기 전에 편집자들이 자동 확증되어야 한다고 요구한다. (그러나 리디렉션을 덮어쓰지 않기 위해서가 아니라, 의견 일치가 이미 이에 반대되는 것이다.)그래도 재미있는 생각이야.이반벡터 (/)^Talk_Edits 15:12, 2020년 8월 3일 (UTC)[응답]

버전 간에 더 많은 패리티를 원해.기사 작성을 위해 확증할 필요가 있다는 차이점이 있다고 하셨죠?만약 당신이 확인된 사용자들만 기사를 만들기를 원하거나 사람들이 초안 제목을 가진 기사를 만들기를 원한다면, 당신은 여기서 다음을 링크할 수 있다: "위키피디아에는 [재연결된 제목]에 대한 기사가 없다. [인큐베이터 편집기에 연결된 pipped link to write one]!"또한 리디렉션과 별도의 페이지가 필요한 경우가 많은데, 메인 페이지는 리디렉션에 대한 섹션이 있을 수 있기 때문에 레드 링크를 만드는 것은 좋지 않을 수 있기 때문이다.

내가 왜 이 템플릿이 유용할 수 있는지 너에게 제대로 설명하지 못했다면 미안해, 하지만 나는 러시아 위키의 다른 사용자가 너에게 더 잘 설명할 수 있을 것 같아.당신이 이 템플릿을 사용하지 않는 위키에서 왔기 때문에, 당신은 그것이 쓸모없다고 생각하겠지만, 러시아 위키에서 온 사람이라면 그것이 얼마나 유용한지 말해줄 것이다.카피네이터 (대화) 18:49, 2020년 8월 4일 (UTC)[응답]

그래서, 만약 내가 당신을 정확히 이해한다면, 이 제안된 템플릿의 기본 아이디어는 여전히 존재하지 않는 기사를 위한 기반시설을 만드는 것을 돕는 것인데, 그러나, 분명히 가능성이 있다, 그렇지 않은가?

나는 이것에 동의한다.때때로, 새로운 기사를 만들기 위해 어떤 모멘텀이 필요하다.많은 사람들이 (잠재적인) 주제에 대해 잘 알고 있다 하더라도, 어떤 것이 누락되었거나 가장 가능한 방법으로 구조화되지 않았다고 느끼지만, 어떻게, 어디서부터 어떻게 시작해야 할지 모른다(또는 새로운 주제의 일부에 대해서만 알고 있기 때문에 처음부터 필요한 문턱을 넘지 못하고, 기사를 위험에 빠뜨리는 대신).삭제하기 위해, 그들은 그것에 대해 알고 있는 것에 전혀 기여하지 않는다.다른 사람들은 필요한 구조에 대해 좋은 개요를 가지고 있을 수 있지만, 주제에 대해 잘 알지 못한다(또는 그것에 대해 기사를 쓸 시간이 없다).정상적인 절차는 먼저 기사를 쓰고 나서 그 주위에 인프라를 구축하는 것이지만, 나는 때때로 기사를 반대로 하는 것이 도움이 된다는 경험을 했다.이름이 지정되었지만 누락된 주제에 대한 빨간색 링크가 여러 위치에서 하나의 미래 대상 이름에 집중되는 경우 이는 동일한 미래 주제와 관련하여 무작위로 배포되는 일부 빨간색 링크보다 더 많은 추진력을 발생시키지만 동일한 대상 페이지 이름으로 끝나지는 마십시오.빨간 링크에 초점을 맞추면, "여기 무슨 링크?"와 같은 도구를 사용하여 관련성과 맥락을 감지하고, 기사에 더 잠재적인 유용한 자료를 찾고, 미래 구조를 보는 것은 이미 새로운 주제와 기존의 주제를 더 잘 구분하기 시작할 수 있다.

기사 해트노트에 대한 다양한 템플리트 중 하나에 대한 매개변수로 빨간색 링크를 제공하면 이미 이 작업을 수행할 수 있다.그러나 현 상황에서는 불행히도 새로운 기사를 위한 인프라 구축에 대한 생각보다는 '정리'에 더 치중하는 다른 편집자들에 의해 이 문제가 없어질 것 같다.내가 당신을 정확히 이해한다면, 그래서 당신은 편집자들에게 빨간 링크를 그냥 두라고 말하는 그런 해트노트 링크를 위한 전용 템플릿이 유용할 거라고 생각하는 거지?{{거짓 간접}}}은(는) 그것에 대해 최선의 이름이 아닐 수도 있고, 아마도 {{가능성이 있는 해트노트}}이(가) 더 좋을 것이다.

이 생각을 조금 더 생각해 보면, 페이지 이동이나 삭제에서 빨간 링크를 남기기 보다는 가능성과 명확하게 연결될 경우 특별 템플릿의 기사에 일반적인 빨간 링크를 액자에 넣는 방법도 유용할 수 있다.이런 식으로 프레임을 짜면 편집자들이 그러한 빨간 링크를 제거하기 전에 다시 한번 생각하게 될 것이다.{{Link with possibility}}와 같은 것이 그 일을 할 수 있다(HTML 코멘트와 유사하지만, 보다 일관되고 기능적이다).

해당 기사가 작성되면 이들 템플릿은 이를 자동으로 감지해 표시된 해트를 "위키피디아에는 기사가 없다, 여기에 xyz"에서 "xyz와 혼동하지 말라"({Distuguish}처럼)로 바꾸거나 그냥 음소거하여 정상적인 링크처럼 보이게({{Ill}처럼) 기사를 넣을 수 있다.봇 또는 편집자에 의해 문서의 소스 코드에서 템플릿을 쉽게 찾고 제거할 수 있도록 숨겨진 유지관리 범주.

빨간색 링크는 이미 설명 페이지(적어도 독일어 위키백과 - IERC에서는, 영어 WP에는 없지만, 나는 그것을 찾아봐야 할 것이다)에서 만약 그들이 가능성이 있는 기사들을 가리킨다면(이미 "여기 무슨 링크?"에 따라 같은 장소를 가리키는 여러 링크로 표시됨)에서 허용된다.

내가 개인적으로 가끔 하는 일은 WP에게 다음과 같다.IAR 및 SeeAskes 섹션의 기사에 관련된 주제에 대한 빨간색 링크를 추가하십시오(영문 WP에 아직 기사가 없지만 다른 언어 실체에 이미 있는 경우).이건 {{ill}}}을(를) 사용한다.마찬가지로, 나는 가끔 모호한 페이지에서도 이것을 한다.비록 형식적으로, 우리의 MOS는 그곳에서의 빨간 링크를 허용하지 않지만, 나는 이것으로 꽤 좋은 경험을 했다.누군가가 영어 WP에서도 주제에 관한 기사를 작성하기 전까지는 그러한 연결고리는 거의 없어지지 않는다. 일반적으로 이러한 연결고리를 추가한 후 1년 내에 발생한다.

그렇다, 나는 그러한 템플릿과 우리의 가이드라인에 있는 가능성과의 빨간색 연결에 대한 몇 가지 언급이 도움이 될 수 있다고 생각한다.

--마티아스폴 (대화) 10:26, 2020년 8월 7일 (UTC)[응답]

이 템플릿과 같은 것이 유용할 수 있는 특별한 예는 유기체에 관한 기사와 함께 발생한다.어떤 종에 대한 기사가 없을 때, 잘못된 편집자들은 종종 종에서 그 종에 속하는 종으로 리디렉션을 만든다.("유도" 관련 위키백과들 사이에서 이에 반대하는 명확한 합의가 있기 때문에 잘못된 안내)이러한 관행은 마치 종들이 이미 기사를 가지고 있는 것처럼 보이게 하여 창조를 단념시킨다(종들에 대한 정보를 원하지만 그들이 시작한 곳으로 돌아가게 되는 속기사의 독자들에게 도움이 되지 않을 뿐만 아니라).피터 콕스헤드 (대화) 08:50, 2020년 8월 9일 (UTC)[응답하라]

영어 학습자 및 장애인을 위한 범용 오디오 기사

영어 학습자와 시각 및/또는 학습 장애가 있는 사람들을 위해 오디오 형식으로 콘텐츠를 제공할 수 있도록, 전담 자원봉사팀이 기사의 범용 내레이션을 시작할 수 있다면 놀라운 일이 될 것이라는 생각이 든다.화면 판독기 기술은 좋지만 변곡, 발음, 뉘앙스가 부족하다.이런 맥락에서 현재 진행 중인 프로젝트는 시작은 좋지만 사용자가 녹음을 요청해야 한다는 점에서 그리 멀리 가지 않는다.

프로체르원카 (대화) 01:59, 2020년 8월 7일 (UTC)[응답]

Profczerwonka, WP:위키프로젝트 구어 위키피디아는 어떤 것이고, 예전에는 더 많은 자원봉사자들이 있었다.이런 녹취록을 갖고 있는 기사가 여럿 있지만 대부분은 상당히 시대에 뒤떨어져 있다.정말로 우리는 그 프로젝트에 더 많은 사람들을 모으면 된다.선장Eek^{Edits Ho Cap'n!}⚓ 05:58, 2020년 8월 7일 (UTC)[응답]

@대장Eek and Profczerwonka:위키프로젝트 구어 위키백과가 좋은 것이라는 데는 동의하지만, 장기적으로는 더 큰 그림을 볼 필요가 있다고 생각한다.구어 버전의 기사를 만드는 것은 많은 일이며, 그것들은 시대에 뒤떨어지기 쉽다.이와는 대조적으로 기계 판독은 규모에 따라 할 수 있으며, 기술이 발전함에 따라 그 품질은 지속적으로 향상되고 있다.나는 구어 위키피디아 토크 페이지에서 현재 구어 버전이 없는 기사를 기계적으로 읽을 수 있는 시스템을 구축하는 것에 대해 실마리를 만들었고, 그것은 긍정적인 반응을 얻었지만, 나는 그 주도권을 진전시키기 위한 기술적 전문지식이 부족하다.{{u Sdkb}}^talk 06:42, 2020년 8월 7일(UTC)[응답]

Sdkb, ooh, 난 그걸 아주 좋아하겠어!나 또한 필요한 기술적 전문지식이 부족하지만, 그것이 어려울 것이라고 생각하지 마십시오.봇이 필요한 모든 것은 기사를 독자에게 먹이고, 출력을 기록하고, 기사에 첨부되는 파일로 만드는 것이다.선장Eek6^{Edits Ho Cap'n!} 06:53, 2020년 8월 7일 (UTC)[응답]

우리가 기술이 이용가능해지고 확장가능해지기를 기다리는 동안, 나는, 그리고 몇몇 다른 편집자들은, 매우 로봇적인 목소리로 읽을 수 있다는 것을 알고 있기 때문에, 이제 우리는 그것을 시작해야만 한다고 생각한다.그들은 그것이 자동으로 수행되지 않는다는 것을 알 필요가 없다; 그것은 단지 베타 버전처럼 보일 것이다.매트릭스글롯 (토크) 09:24, 2020년 8월 7일 (UTC)[응답]

날 생각해줘서 기뻐, 어슬링<빌어먹을!> <빌어먹을!>EENG 22:03, 2020년 8월 7일 (UTC)[응답]

@CaptainEek, Sdkb 및 Mathglot:확장성 문제에 대해서는 전적으로 듣고 있다.종유성 문제는 미처 생각하지 못한 것 같다(아티클은 빨리 구식이 된다.)나는 여기 새로 온 편집자지만, 위키미디어 재단이 확장 가능한 기계 읽기 이니셔티브를 지원하기 위해 자금을 지원하거나 지원할 수 있을 것이라는 생각이 든다.그렇지 않으면 우리는 임시방편으로 그것을 계속 할 수 있을 것이다.이 실에 관심을 끌 생각은 없나?

프로체르원카 (대화) 2020년 8월 7일 13:00 (UTC)[응답]

• 이거 다 좋은 것 같아.나는 작년에 프로젝트로서 구어 위키피디아에 가입했을 뿐인데(그 시점에서는 이미 꽤 조용했다), 내가 쓴 어떤 글도 구어 버전으로 만들기로 결심했다.분명히 다른 기사들도 작업하면 더 좋겠지만, 스케일링 문제가 있고, 긴 두 기사를 녹음하고 편집하는 데 각각 오랜 시간이 걸렸다.나는 WMF가 기계 취급에 대한 실행 가능한 제안이 있다면 보조금을 제공하는 데 매우 관심이 있을 것이라고 의심한다.관련 직원 한두 명(즉, 보조금을 지급하지 않고, 약혼이나 접근성을 취급한 사람) 노즈백베어(대화) 13:20, 2020년 8월 7일(UTC) 회신
• 접근성 담당자와 관련된 것을 고려해 보셨습니까?그들 중 몇몇은 스크린 리더 소프트웨어를 사용한다. 예를 들어 Graham87 (대화·연출)은 항상 그것을 사용하며, 여기서 도움을 줄 수 있어야 한다. --Redrose64 🌹 (대화) 18:43, 2020년 8월 7일 (UTC)[응답]
  • @Redros64: 내가 아는 가장 오디오 지향적인 시각장애인의 한 사람으로서, 나는 페디아폰에 대해 언급하는 것 외에는 이것에 대해 많은 것을 말할 자격이 정확히 없다.일반적으로 음성 합성기의 변곡과 뉘앙스는 더 넓은 모집단에 대한 화면 판독기 사용자만큼 중요하지 않다.Graham87 02:54, 2020년 8월 8일 (UTC)[응답]
• 절차 참고 사항:여기서 좋은 논의가 많이 일어나고 있기 때문에 우리는 이것을 아이디어 연구소로 옮기고 싶을지도 모르지만, 이것은 완성된 제안보다는 브레인스토밍 단계에 있다.{{u Sdkb}}20:27, 2020년 8월 8일 (UTC)[응답]
• 체크아웃 메타:텍스트 음성 변환 프로젝트용 Wikispeech 및 mw:확장:Wikispeech의 기술 문서화.이를 위해서는 다국어 체계화 된 다국어 데이터와 오디오 파일, 그리고 메타 데이터(meta가 많이 필요하다.Languagea Libre는 그것을 위한 프로젝트다.공용 참조:범주:프로젝트에서 오디오 파일에 대해 수행하는 작업에 대한 Languagea Libre 발음을 보려면 주요 웹 사이트 https://lingualibre.org/에서 Wikidata 프런트 엔드를 한 번에 확인하고, Wikidata를 녹음, 편집 및 Commons에 게시하십시오. d:위키다타:위키다타 렉시메 양식:이것이 어떻게 정렬되는지 보기 위해.관심 있는 사람이라면 해야 할 일이 많은데, 여기에는 개별 단어를 분류하기 위해 노는 것, 프로젝트가 무엇인지, 프로젝트가 왜 중요한지, 그리고 이 모든 다양한 파일럿 도구들이 무엇을 하는지 기록하기 등이 포함된다.구어 위키백과 프로젝트는 위키미디어 프로젝트에 대한 사용과 통합에 대한 데이터를 얻기 위해서도 중요하다. 블루래스베리 (토크) 2020년 8월 9일 (UTC) 14:35 [응답]

가이드라인이냐 아니냐.

PLS 위키백과 대화 보기:참조 데스크/가이드라인/의료 조언#가이드라인 페이지로 표시됨.--Moxy 🍁 18:38, 2020년 8월 9일(UTC)[응답]

러시아 동문 및 멘토를 위한 CentralNotice 배너 2020

동료 여러분, 러시아 동문 및 멘토들의 2020년 기사 공모전에 대한 CentralNotice 배너 제안에 대해 의견을 보내주십시오.(2020 2020년 8월 20일 → 11월 10일, 러시아로부터의 모든 IP, WP 전용, 2주당 1개 배너 인상)감사합니다.주코프 (대화) 17:15, 2020년 8월 10일 (UTC)[응답]

위키백과:이름 변경을 위해 제안된 검토 이동

나는 현재 위키백과의 제목을 변경하라는 이동 요청이 있다는 것을 이사회에 통지한다.리뷰 이동.토론은 여기서 찾을 수 있다.이 제안이 어떤 식으로든 이 페이지의 사용 범위에 영향을 미칠 수 있고(이 페이지는 월별 하위 페이지가 여러 개 있음), 1년 전에 페이지 범위를 변경하기 위해 발생한 RfC가 있었기 때문에 이 게시판에 공지하지만, 현재 제목은 범위 ch를 적절히 반영하거나 반영하지 않을 수 있다.천사. 스틸1943 (대화) 18:38, 2020년 8월 10일 (UTC)[응답]

사용자의 기여도를 보다 쉽게 볼 수 있는 방법 구현

사용자의 모든 기여를 보기 위해(반복 링크를 넣지 않은 경우).그들의 서명)에서, 당신은 Special로 가야 한다.기여/ 및 이름을 입력하십시오.내 제안은 사용자 페이지의 "Talk" 버튼 옆에 새로운 "Collections" 버튼을 놓는 것이다. -- ApChrKey 21^Talk:50, 2020년 8월 7일 (UTC)[응답]

WP를 활성화하는 경우:기본 설정에서 POPUPS, 서명 위에 마우스를 올려놓고 사용자 위에 마우스를 올린 다음 기여를 클릭하십시오. (팝업은 다양한 용도로 훌륭하다.)샤즈질드(대화) 21:53, 2020년 8월 7일 (UTC)[응답]

와우 그 팝업은 정말 유용하다.몇 층 아래로 내려갈 수 있다. -- ApChrKey 22^Talk:04, 2020년 8월 7일 (UTC)[응답]

감시목록을 사용하면 엄청난 시간 절약이 된다.기사를 볼 필요 없이 각 디프마다 맴돌기만 하면 어떤 변화가 일어났는지 알 수 있다.즐기세요! 샤즈질드 (대화) 22:09, 2020년 8월 7일 (UTC)[응답]

@ApChrKey:사이드바의 "도구" 아래에 이미 "사용자 기여" 링크가 있다.어차피 탭으로 하고 싶으면 사용자 스크립트가 그렇게 쉽게 할 수 있어. (그걸 원하지만 직접 쓰는 방법이 확실하지 않다면 알려줘, 내가 만들어 줄게.)잭mcbarn (대화) 21:55, 2020년 8월 7일 (UTC)[응답]

고마워그건 몰랐어. -- ApChrKey 21^Talk:58, 2020년 8월 7일 (UTC)[응답]

ApChrKey, 내가 만든 것 중 하나는 WP:SUPERLINKSEdtalk! 22:46, 2020년 8월 7일 (UTC)[응답]

많은 사용자들은 또한 그들의 서명에 기여 링크를 넣는다.내 위로는 아무도 그렇게 한 것 같지 않으니까, 단지 그것을 언급하는 것 만으로는, 그것은 여기서 그 문제를 실제로 다루지 않는다.이반벡터 (/)^Talk_Edits 14:21, 2020년 8월 10일 (UTC)[응답]

ApChrKey: AMC 이후, 모바일 인터페이스(및 일반적으로 미네르바 스킨)는 페이지 상단에 도구 모음을 얻었으며, 주 사용자 페이지에는 기여 아이콘(언어 아이콘은 숨겨져 있어 공간을 만든다)이 있다.Timeless 스킨에는 User: 또는 User talk: page 또는 하위 페이지에 대한 기여 아이콘(또는 페이지 너비에 따라 링크)이 있다.페이지 도구 드롭다운에서 분리하여 History 오른쪽에 있다.기본 벡터 스킨에 대한 데스크톱 개선 프로젝트는 페이지 도구(또는 "문서 도구")를 왼쪽 사이드바에서 별도의 메뉴로 옮기는 것을 고려하고 있지만, 사용자 기여도의 배치에 대한 그들의 생각이 무엇인지 잘 모르겠다.Pelagic (메시지 · Z ) – (05:55 Tue 11, ACCY) 19:55, 2020년 8월 10일 (UTC)[응답]

@ApChrKey, Jackmcbarn, Shazjmd, Ivanvector:미디어위키위키 DI프로젝트에 이 제안에 대한 주제를 올렸다.Pelagic (메시지 · Z ) – (07:24 Tue 11, ACCY) 21:24, 2020년 8월 10일 (UTC)[응답]

중국어 간체 VS 전통적

제안이란 무엇인가?

우리 결혼이나 뭐 그런 거야?여기 당신을 위한 제안이 있다: 이 페이지 상단에 이 페이지의 모든 내용을 간략히 설명하라! --Palosirka (토크) 09:38, 2020년 8월 13일 (UTC)[응답하라]

이 페이지 상단에 설명 상자가 있다.331닷 (대화) 09:48, 2020년 8월 13일 (UTC)[응답]

상자는 있지만 제안이 무엇인지에 대해서는 아무것도 적혀 있지 않다. --Palosirka (대화) 09:52, 2020년 8월 13일 (UTC)[응답]

확실히 그렇다, 첫 문장 바로 아래. 331닷 (대화) 09:54, 2020년 8월 13일 (UTC)[응답]

상자가 엉망진창이다."제출 전 : 제안된 정책 변경은 빌리지 펌프(정책)에 속한다."그건 논리적인 문장이 아니라 단어 샐러드야. --Palosirka (대화) 10:10, 2020년 8월 13일 (UTC)[응답]

Palosirkka, 이것은 이미 이루어졌고 마을 펌프 메인 페이지와 다른 장소들에 잘 기록되어 있다.우리가 여기서 할 일은 없어.에드토크! 09:48, 2020년 8월 13일 (UTC)[응답하라]

아니 에드 아니야.그리고 메인 페이지나 다른 페이지를 말하는 것이 아니라 바로 이 페이지를 말하는 것이다. --Palosirkka (대화) 09:52, 2020년 8월 13일 (UTC)[응답]

Palosirka, "새로운 제안은 여기서 논의된다." - 나는 그것이 충분히 요약된다고 생각한다.어느 쪽이든 이 페이지를 편집하여 직접 변경할 수 있는가?페이지 편집처럼 사소한 것에 대해 왜 여기서 청혼이 필요한지 모르겠고, 정말 그렇다면 이 스레드는 WT:VPREdtalk! 10:01, 2020년 8월 13일 (UTC)[응답하라]

그게 뭔지만 알면 내가 기꺼이 직접 하겠어. --Palosirkka (대화) 10:07, 2020년 8월 13일 (UTC)[응답]

나는 네가 사전을 사용할 수 있다고 거의 확신한다.에드톡! 2020년 8월 13일 10시 17분 (UTC)[응답하라]

Ed6767 67, 나는 코웃음을 칠 필요가 없다고 생각한다.그 상자는 실제로 어떤 종류의 제안이 여기에 속하는지 아무런 지침도 주지 않는다.여기에 속하지 않는 제안의 유형을 상세히 기술하고 있는데, 이 페이지는 다른 곳에 속하지 않는 제안들을 위한 것이라고 가정하는 것인가?특정 종류의 제안(내 추측: "Wipedia 프로젝트 전체에 적용되지만 정책, 프로젝트, 소프트웨어에는 포함되지 않는 변경에 대한 개념")을 위한 것인가?)등?나는 정보를 얻기 위해 이 페이지를 보지만, 그 목적에 대해서는 전혀 생각해 본 적이 없으며, 팔로시르카(Palosirkka)가 합리적인 질문(조금 경솔하다면)을 한 것 같다.샤즈질드 (대화) 16:30, 2020년 8월 13일 (UTC)[응답]

나는 여기서 사용되는 의미에서의 제안은 상당히 구체적이고 합리적으로 충분히 충분히 논의된 이 위키에 대한 변화를 위한 아이디어라고 믿는다.그 아이디어는 이미 아이디어 랩이나 아마도 다른 곳에서 대화 페이지에서 논의되었어야 했다.그 페이지에 대한 소개는 특정한 유형의 아이디어에 더 좋은 다른 장소들을 나열한다.— 고스트인TheMachine^{talk to me} 10:40, 2020년 8월 13일 (UTC)[응답]

'제안이 무엇인가'에 대한 가장 좋은 증거는 이 페이지에서 방송되는 '제안'을 읽고 토론에 이어 그 과정에 참여함으로써 찾을 수 있다.경험을 먼저 수집해야 할 때는 정의가 필요하지 않다.비유하다.다른 편집자들의 참여와 당신의 아이디어와 주장에 대한 그들의 반응을 평가하라.— 네오란지 (필) 23:20, 2020년 8월 14일 (UTC)[응답]

이것은 아무리 말해도 이상한 대화다.그럼에도 불구하고, OP는 어떤 종류의 제안이 여기에 속하는지 설명하지 않는 페이지 상단에 대해 좋은 지적을 하고 있다.아마도 상위에 있는 과거의 제안들의 몇몇 예들이 도움이 될 것이다.나 자신도 이 제안 페이지가 WT의 변경사항과 어떻게 다르거나 중복될 수 있는지에 대해 확신이 서지 않는다.MOS, 그것은 적어도 위에서 명확하게 밝혀져야 한다.독자들이 이 페이지가 무엇인지 이해하기 위해 제안을 통해 읽으라고 제안하는 것은, 단지 윗부분에 있는 것을 말하기 보다는 다방에서 질문을 통해 독자들에게 질문의 장소라는 것을 이해하도록 제안하는 것과 같다!Aza24 (대화) 00:46, 2020년 8월 15일 (UTC)[응답]

응, 어떤 종류의 제안이 여기서 제안되어야 하는지는 분명하지 않을 것 같아.주요 위키백과의 상단에 있는 간단한 설명:마을 펌프가 좀 더 도움이 되긴 하지만, 그 다음엔 넓은 획이 실제로 모두 제대로 지켜지지 않은 그림을 그린다.마을 펌프는 제안자가 너무 중요하다고 생각하는 애완동물 프로젝트(또는 오줌싸개)를 제기하는 장소라고 말하는 것이 더 정확할 것 같고, 페이지 선택(아이디어 랩, 제안 또는 정책)은 제안자가 스스로 얼마나 중요하다고 생각하는가에 크게 좌우된다고 생각한다.be. – 우안팔라 (대화) 17:36, 2020년 8월 15일 (UTC)[응답]

임의 브레이크

어이쿠, 여기 실밥이 엉망이니, 쉬면서 리셋을 해라.하지만 나는 GhostIn에 동의해.더머신.어떤 아주 설익은 생각들이 여기서 끝나게 되는 것은 분명 문제지만, 설익은 생각을 제안할 것 같은 편집자들의 유형도 지시를 읽지 않는 종류이기 때문에(편집통지에서도) 우리가 할 수 있는 일이 별로 없을 것 같다.기준과 관련하여 다음과 같은 몇 가지가 떠오른다.

1. 구체적이고 구체적:"문제 X를 해결할 방법을 찾자"는 말만 하지 말고 해결책을 염두에 둬야 한다.(아이론적으로 이 실이 자격이 없다는 뜻)
2. 개발됨:특히 주요 제안의 경우, 품질 프레임워크, 아이디어 랩 또는 다른 곳에서 선행 작업 등을 통해 입증되는 명확한 작업이 있어야 한다.예를 들어, "포털을 더 이상 사용하지 말자"와 함께 여기에 떨어졌을 때 다른 스레드는 더 이상 잘라서는 안 된다. (이 문제는 RfCs에도 영향을 미치며, RfC는 중립적이지 않은/필요하지 않은/부적절한/등) 일단 실행되면 종료하기가 매우 어렵다.나는 사람들이 투표 "abort"를 실제로 취소한 경우를 단 한 가지도 생각할 수 없다.)
3. 광범위한 시사점:대부분의 제안은 펌프가 아닌 특정 프로젝트 페이지 등에서 진행되어야 한다.여기서 {{보십시오}}}} 통지는 일반적으로 충분하며, 특히 더 사소한 문제에 대해서는 더욱 그러하다.

시행과 관련하여, 여기서 아이디어 랩이나 다른 곳으로 실을 쉽게 이동할 수 있는 장치가 있는가?그게 도움이 될 거야.

또한, 새로운 스팸 외에도 다른 역학 관계가 있다: 아직 개발되지 않은 아이디어에 주의를 기울이고자 하는 경험 많은 편집자들이 이 페이지를 훨씬 더 세밀하게 감시하고 있다는 것을 알고 있다. 이 아이디어 랩은 감시자가 적고 더 많은 쓰레기들을 가지고 있다.아이디어 연구소에서 좋은 경험을 좀 해봤지만, (예를 들어 최근) 토론이 진행되길 기본적으로 간청해야 할 때도 있었고, 내가 여기 왔더라면 그럴 필요가 없었을 것이다.불행하게도, 내가 위에서 제안하는 기준의 엄격한 시행은 실제로 그 역동성을 더 악화시킬 것이다. 왜냐하면 아이디어 연구실에는 더 많은 쓰레기들이 쌓여 있을 것이기 때문이다.아마도 우리는 찻집으로 옮기기 위해 그곳에서 장비가 필요할 것이다.

핵심적인 문제는 우리가 시작할 적절한 토론과 그것들을 시작할 방법에 대해 가지고 있는 어떤 규칙/규범도 시행할 수 있는 좋은 방법이 없다는 것이다.RfCs에서 WP로:Cent to Talk:도널드 트럼프, 우리가 해결할 방법을 찾을 수 있다면 훨씬 더 나을 거야{{u Sdkb}}{{u Sdkb}} 21:24, 2020년 8월 15일 (UTC)[응답]

나는 사람들이 투표에서 "abort"를 실제로 취소한 경우를 단 한 가지도 생각할 수 없다. 여기 보라.다른 사례도 있었다. --Redrose64 🌹 (대화) 22:50, 2020년 8월 15일 (UTC)[응답]

레드 로즈64, 괜찮다.우리 시스템은 아주 명백한 사건들을 처리할 수 있지만, 그것 외에는 종종 고장이 나곤 한다.{{u Sdkb}}} 09:38, 2020년 8월 16일 (UTC)[응답]

사용자 서명 필드 변경에 대한 기본 HTML 구문 검사 추가

사용자 지정 사용자 서명을 저장할 때마다 HTML 구문 검사를 추가할 수 있는지요?(아마 시사회할 때 조차도; 그들에게 그것을 고칠 기회를 줘.)사용자 토크 페이지에 사용자 서명을 수정해 달라는 댓글을 달았는데, 이 주제에 대해 사용자에게 주소를 쓴 것은 이번이 처음이 아니다.

보다 명백한 HTML 실수, 전체 토크 페이지를 붉게 만드는 누락된 글꼴 끝 태그, 전체 페이지를 작고 위첨자로 남기는 누락된 </supp>은 누군가가 찾아내어 빨리 고칠 수 있을 정도로 명백하다.이 오류와 같이 명확하지 않은 오류는 미리 보기 페이지 구문 강조 표시를 끊은 상태로 두십시오.그리고 그것들은 더 섬세하고 렌더링된 토크 페이지를 장식하지 않고 위키코드 구문만을 강조하기 때문에, 그들은 훨씬 더 오래 머물게 된다.이 사용자의 서명이 2014년부터 토크 페이지 구문 강조 표시를 깨고 있지만, 지금까지 내가 편집한 워치리스트 토크 페이지가 없어서 전혀 눈치채지 못한 것 같아.확실히 하자면:나는 이것이 순진하고 선의의 실수라는 것을 의심하지 않지만, 처음부터 잡히지 않을 이유가 없다.

이전에 일어났을 법한 모든 페이지를 수정하는 것은 별로 신경 쓰지 않지만, 왜 사용자들이 서명란에 원하는 것을 넣도록 내버려두어야 하는지, 그리고 문제가 생길 경우를 대비해서 이 난장판을 깨끗이 치워야 하는지 모르겠다.HTML 구문 체커는 영원히 존재해 왔고, 길고 복잡한 웹 페이지에서도 강력하다.사용자 지정 사용자 서명에 잘못된 HTML 구문이 있기 때문에, 우리는 Talk 페이지가 실수로 엉망이 되는 것을 허용해서는 안 된다.서명 입력 필드가 저장되도록 허용하기 전에 동일한 수준의 유효성 검사를 통해 입력하도록 요청하는 것은 지나친 요구인가?고마워, Mathglot (토크) 01:39, 2020년 8월 19일 (UTC)[응답]

Mathglot, mw에 대해 알고 있는가?사용자 서명에 대한 새로운 요구사항? --AntiCompositeNumber (talk) 01:45, 2020년 8월 19일 (UTC)[응답]

@AntiCompositeNumber:, 나는 몰랐어.참고로, 이 이슈에 대한 관련 섹션은 #제안: 서명 검증 요건이며, T140606에서 추적되고 있다는 점을 추가하겠다.그들은 불균형한 <퐁> 태그 등을 포함한 특정한 유형의 오류에 대해 이야기하는데, 만약 내가 그것을 제대로 읽고 있다면, 그것은 또한 내가 위에서 잘못 테스트된 태그로 식별한 오류를 잡을 수 있을 것이므로, 그것은 좋은 소식이다.링크해줘서 고마워.나는 미디어위키(또는 다른 자매 프로젝트와 위키백과)에 낯선 사람은 아니지만, 나의 주된 존재는 엔위키에 있다; 그리고 미디어위키가 자매 프로젝트에 더 널리 자신을 광고해야 하는지, 아니면 그런 것들을 놓치지 않기 위해 어떻게든 내 영역을 넓혀야 하는지는 잘 모르겠다.어쨌든, 링크 고마워!매트릭글롯(토크) 03:18, 2020년 8월 19일 (UTC)[응답]

Mathglot, 그 페이지에서는 정확하게 알 수 없지만, 관련 변경사항은 현재 배치되어 있다(mw:새_요건_for_user_signatures#결과.유일한 예외는 서명에 시행되지 않는 "obsolete HTML 태그" 보풀 오류다.보푸라기 오류를 발생시키기 위해 서명을 편집하려고 하면, 당신은 할 수 없다는 것을 발견해야 한다.내 도구를 사용하여 다른 사람의 서명을 확인할 수도 있다. 이 경우 https://signatures.toolforge.org/check/en.wikipedia.org/Gourami%20Watcher. --AntiCompositeNumber (talk) 04:12, 2020년 8월 19일 (UTC)[응답]

AntiCompositeNumber, 정말 반가운 소식이야, 고마워!그리고 문제가 GW의 시그니처 안에 어디에 놓여있는지 당신의 툴에 의해 확인되어 그것을 못박은 나의 분석을 받는 것이 좋다. (대부분의 브라우저들이 그런 것들을 용서하고 있기 때문에 나는 쓸모없는 HTML 태그에 대해서는 신경쓰지 않는다.)Mathglot (대화) 05:05, 2020년 8월 19일 (UTC)/[응답]

와카미도잉(WMF)의 기술 마을 펌프에서 길러졌다.위키백과 참조:마을 펌프(기술)/아카이브 182 § 사용자 지정 서명 및 위키백과 변경:마을 펌프(기술)/아카이브 182 § 사용자 지정서명 변경 월요일, Hatamidoing이 유효하지 않은 서명이 있는 사용자들이 점차적으로 연락될 것이라고 말한 곳.아이작(토크) 10:35, 2020년 8월 19일 (UTC)[응답하라]

잠깐 시간을 좀 내야 할 것 같아.;-) 그래, 벌써 일어나고 있어.enwiki의 경우, 우리는 약간의 오류와 함께 1,20000개의 활성 편집자(=최근 30일 동안 편집)로 시작했다.그들 중 대부분은 "플레인-팬시-시그"라고 불리는 문제를 가지고 있는데, 이것은 단지 당신이 당신의 프리프들에 불필요하게 체크된 상자를 가지고 있다는 것을 의미한다.

나와 두어 명의 자원 봉사자들은 지금까지 이곳 편집자 100여 명과 개별적으로 연락을 취했고, 수백 명의 다른 사람들이 스스로 자신의 시그니처를 고쳤다(또는 이와 무관하게 편집을 중단했다).신규 편집자에 대한 우리의 소모율이 매우 높기 때문에, 6월에 시그니처를 만들다가 편집을 중단한 신입은 더 이상 리스트에 올라 있지 않으며, 7월 이후 신입도 같은 실수를 저지를 수 없다.)아마존닷컴은 아마도 내일 업데이트 될 것이고, 우리는 그것이 얼마나 많은 차이를 만들었는지 볼 것이다.만약 메세지가 효과가 있는 것 같다면, 나머지는 작은 단위로 연락하자.

질문을 돕거나 전달하는 데 관심이 있는 경우 mw:사용자 서명/도움말의 새로운 요구사항은 지침의 중심점이다.Wiki에서 우리는 사람들에게 WT에 그들의 질문을 가져갈 것을 요구하고 있다.SIG, 이게 도움이 되는 사람들이 볼 수 있는 페이지야.지금까지 아무런 질문도 받지 못했는데, 그 말은 우리의 지시가 명확하다는 뜻이었으면 좋겠는데.

'할아버지' 기간을 끝내는 일정은 공식적으로 '내가 그 일을 할 때'(나는 병목현상이고, devs는 나를 기다려주기로 했다)이다.아마 몇 달 후일 것이다. (몇 주가 아니라 몇 년이 아니다.)현재 126,740명의 현역 등록 편집자 중 900명 미만이 이런 생각을 할 필요가 있으며, 그 중 700명 가량은 프리프에서 한 박스를 선택 해제함으로써 해결되는 오류를 가지고 있다.Whatamidoing (WMF) (토크) 04:08, 2020년 8월 20일 (UTC)[응답]

정치인 무면허 사진 공정한 사용 허용

수동 태그: "요약 편집 오류"

xtools 아티클info에 '마지막 편집' 열 추가

사용자가 기사의 Talk 페이지에서 현재 토론에 ping할 수 있는 적합한 후보인지 판단하는 데 도움이 되는 xtools 유틸리티 "gliticalinfo" 및/또는 기타 방법에 '마지막 편집된' 열을 추가하십시오(즉, 1년 동안 편집하지 않은 편집자를 ping하는 것은 시간과 노력의 낭비임).

나는 자주 매우 편리한 xmflabs 도구인 "기사" (샘플)를 사용하여 "주관된 편집자"의 핑 리스트를 작성하여 기사 토크 페이지에서 토론에 대해 통지받도록 한다.그러나, 편집자 수가 최대 20~30명(편집, 바이트 수 또는 저작자별 상위 10명)이 될 수 있으므로, 나는 대개 최근 3개월(또는 어떤 임계값이든)에 기여하지 않은 사용자를 목록에서 삭제한다.그러나 그것은 결정하는데 40에서 60클릭이 필요하다.위키백과에 대한 편집자의 마지막 기고일자를 포함하는 Top Editors 섹션의 표에 있는 새로운 날짜 열은 이것을 훨씬 더 쉽게 만들 것이다. (더 좋은 것은: 지난 6개월의 기여 패턴을 보여주는 글꼴 높이 스파크라인과 마지막 날짜까지 포함)고마워, Mathglot (토크) 21:02, 2020년 8월 24일 (UTC)[응답]

@Mathglot: "xtools"는 사실 "영어 위키백과"가 아니다. - 이것은 사적인 도구이고 유지 관리자들은 그들이 원하는 대로 그것을 사용할 수 있다.여기에서 유지관리자 목록을 볼 수 있으며, 유지 관리자들이 피드백을 받을 수 있으며, 여기에 기능 요청을 넣을 수도 있다.— Xaosflux^Talk 15:36, 2020년 8월 25일 (UTC)[응답]

@Xaosflux:, 고마워!T261247.매트릭글롯(토크) 19:23, 2020년 8월 25일 (UTC)[응답]

위키 앱의 "역사의 오늘" 알고리즘을 다시 작동시킨다.

안녕, 나는 최근에 위키 앱을 얻었고 그것을 보는 것을 매우 즐겼어.나는 특히 "역사 속의 오늘"을 좋아한다.하지만, 나는 그것이 보여주는 대부분의 기사들은, 더 좋은 말이 없기 때문에, 나쁜 소식이라는 것을 발견한다.나는 대부분의 기사의 절반 이상이 테러 공격, 철도 사고 또는 자연 재해에 관한 것이라고 말하고 싶다.나는 개인적으로 이 기사들을 읽는 것이 그다지 즐겁지 않다고 생각한다.위키피디아의 내부 작업, 이 문제를 어떻게 해결해야 할지 전혀 모르겠다거나, 이것이 이 변화를 제안하기 위한 올바른 포럼이라면 나의 엄청난 무지를 용서해 달라.혹시 다른 사람이 이런 일로 골머리를 앓은 적이 있는지, '역사의 오늘' 코너에서 일반적으로 어떤 기사가 나오는지 바꿀 수 있는 방법이 없을지 궁금하다.사전에 That01Lama — That01Lama가 추가한 서명되지 않은 이전의 논평 (대화 • 기여) 13:54, 2020년 8월 21일 (UTC)[응답]

@Th01Lama:이것들은 알고리즘에 의해 생성되는 것이 아니라 여러분과 같은 위키백과 편집자들이 선택한다.홈 스크린에 있는 것은 메인 페이지의 같은 리스트에서 뽑은 것 같고, '이날 더보기'를 누르면 나오는 것은 8월 21일 같은 설날 기사에서 나온 것이다.주요 페이지 목록 기준은 위키백과:선택된 기념일, 일별 목록 기준은 위키백과에 설명되어 있다.연중무휴.나는 당신이 그러한 기준에 맞는 즐겁거나 즐거운 이벤트를 찾기를 권장한다.바후르즈푸 (대화) 17:34, 2020년 8월 21일 (UTC)[응답]

That01Lama, 이것은 뉴스의 개념으로 더 큰 이슈에 놓이게 되는데, 그것은 부정적인 발전이 갑자기 일어날 가능성이 더 높다는 것이다. 반면에 긍정적인 발전은 시간이 지남에 따라 일어난다.아마도 중요한 사람들의 생년월일을 더 추가하는 것이 이 문제에 조금이나마 대처하는데 도움이 될 수 있을 것이다.나는 WP에 익숙하지 않다.하지만 OTD는 거기에 게시하는 것 보다 더 도움이 되는 피드백을 받을 수 있을 것이다.{{u Sdkb}} 22:11, 2020년 8월 22일(UTC)[응답]

@Sdkb에 완벽히 도달한 당신은, 나는 스스로 더 많은 긍정적인 사건들을 기꺼이 덧붙이겠지만, 사실은, 내가 모든 시간을 편집하는데 소비하지 않는 한 나는 거의 실수를 하지 않을 것이다.만약 내가 틀렸다면, 내가 "오늘의 기사"로 태그될 수 있는 것에 대한 기준이 있는 것처럼 들린다.아마도 이 표준은 미래에 더 긍정적인 판을 장려하기 위해 약간 수정될 수 있을 것이다.다른 누군가가 나의 이 일을 방해하는지는 아직 확실하지 않다.만약 다른 사람이 없다면, 나는 "고장나지 않았다면 고치지 마!"라고 말한다 — That01Lama (대화 • 기여) 21:54, 2020년 8월 25일 (UTC)[응답]에 의해 추가된 서명되지 않은 코멘트.

$wgNamespaces에서 임시 네임스페이스 제거하위 페이지 포함

주 네임스페이스에는 하위 페이지가 없으므로 다른 어떤 것과 마찬가지로 기사 이름에 있는 문자일 뿐이다.드래프트 네임스페이스의 페이지는 일반적으로 일단 받아들여지면 메인 네임스페이스의 페이지와 이름이 같아야 하기 때문에 거기에 하위 페이지를 두는 것도 말이 되지 않는다.예를 들어, 초안:Andreas Hedlund (arranger/orcherstrator)는 초안의 하위 페이지로 간주되어서는 안 된다.Andreas Hedlund (arranger, 그리고 초안:9/11 검토 위원회)는 초안:9의 하위 페이지로 간주되어서는 안 된다.그리고 내가 알기로는, 드래프트 네임스페이스에서 사용 중인 합법적이고 의도적인 하위 페이지는 없다.따라서, 나는 우리가 초안 네임스페이스를 삭제하도록 제안한다. Jackmcbarn (대화) 04:12, 2020년 8월 10일 (UTC)[응답]

현재 검토 중인 페이지: 채석장:query/47324.의도적인 것들이 많으니까, 이건 당신이 "합법적인" 것으로 간주하는 것으로 귀결되는 것 같아.—크립틱 05:19, 2020년 8월 10일 (UTC)[응답]

거의 모든 것들이 (1) 하위 페이지가 아닌 방식으로 슬래시를 사용하고, (2) 움직이는 사람이 남긴 "사용자:Foo/Bar"에서 "Drafraft:"Draft:Bar" 또는 (3) 드래프트 네임스페이스를 드래프트 기사 이외의 용도로 사용한 결과 대신 Foo/Bar".그 중에 합법적인 그룹이 있다고 생각하나, 아니면 내가 그 수를 과소평가하고 있는 그룹이 있다고 생각하나?잭mcbarn (대화) 23:25, 2020년 8월 10일 (UTC)[응답하라]

한꺼번에 많은 초안 기사를 편집하고 있다면, 그 기사의 이름을 초안:RexxS/Foo, 초안:RexxS/Bar 등은 이들을 함께 보관하지만, 하위 페이지가 허용되지 않으면 거의 동일하게 작동할 것이다.물론 하위 페이지를 진정으로 원한다면 드래프트에 내 사용자 공간을 사용할 수 있으므로 $wgNamespaces에서 드래프트 네임스페이스를 제거하는 데 문제가 없음을 알 수 있다.하위 페이지 포함구성이 변경될 때 캐릭터가 포함된 현재 초안 페이지 세트는 어떻게 될지 확신할 수 있는가? --RexxS (토크) 17:41, 2020년 8월 11일 (UTC)[응답]

@RexxS: 현재 제목에 슬래시가 있는 초안에는 전혀 아무 일도 일어나지 않을 것이다.그들은 여전히 그들의 현재 이름으로 접근할 수 있을 것이다.또한 사용자들은 여전히 그러한 제목으로 초안을 작성할 수 있을 것이다.이 변화만으로 {{BASEPAGENAME}}, {{SUBPAGENAME}}의 출력을 변경하고, 부모 페이지로 자동 브레드크럼 링크를 제거하는 것 등이 가능하다.잭mcbarn (대화)20:53, 2020년 8월 11일 (UTC)[응답]

@Jackmcbarn: 그래, 네가 말한 것들을 알아냈어. 내가 걱정했던 것은 --RexS (대화) 21:01, 2020년 8월 11일 (UTC)[응답]

@RexxS: MediaWiki 설명서를 확인해 보니, 다른 두 가지 효과만 보인다: 상대적 링크가 끊기므로, "Draft:"에서 "[/bar]"Foo"는 이제 "Draft:" 대신 "/bar"로 연결된다.Foo/bar"와 이동 초안은 더 이상 하위 페이지를 이동하는 옵션을 표시하지 않는다.초안은 결국 기사가 되어야 하고, 그러한 종류의 링크는 메인 스페이스에서는 유효하지 않을 것이기 때문에, 나는 그렇게 많은 손실을 고려하지 않으며, 또한 우리가 그들의 서브 페이지를 가지고 초안을 자주 이동한다고 생각하지 않는다.잭mcbarn (대화) 21:19, 2020년 8월 11일 (UTC)[응답하라]

가능한 초안: 하위 페이지가 있는 페이지의 라운드 로빈 이동(예: /doc, /sandbox 및 /테스트케이스가 포함된 템플릿)에 공간을 사용하시겠습니까?Certes (talk) 21:28, 2020년 8월 11일 (UTC)[응답]

@Certes: 임시 페이지에 자신의 사용자 공간을 쉽게 사용할 수 있다. --RexxS (토크) 21:36, 2020년 8월 11일 (UTC)[응답]

@Certes 및 RexxS:WP:ROUNDROBIN은 현재 초안의 하위 페이지를 사용할 것을 권고하고 있다.인기 페이지와 랩 사용자 스크립트에 의해 미러링되는 동작인 해당 목적을 위해 이동하십시오.그 기능이 MediaWiki 측 "하위 페이지 이동" 옵션(내가 알 수 있는 한, 이 변경의 영향을 진정으로 받는 유일한 것임)에 대한 액세스를 필요로 하는지는 확실치 않지만, 이러한 변화가 라운드 로빈 이동에 대해 현재 받아들여지고 있는 흐름을 방해할 수 있다는 점은 분명히 주목할 필요가 있다.Nathan2055^{talk - contribs} 01:54, 2020년 8월 23일 (UTC)[응답]

@Nathan2055:우리는 현재 제안되고 있는 라운드 로빈 페이지 이동 경로가 유용한 제안을 실행하는 데 장애물이 되도록 허용하는 것은 어리석은 일일 것이다.상황이 바뀌었을 때 조언을 업데이트하는 것은 사소한 일이다.그럼에도 불구하고, 단일 페이지 이동의 경우, 현재 권고사항은 임시 위치로 초안 공간 또는 사용자 공간을 사용하는지 여부와 동일하게 작동할 것이다.페이지를 모든 하위 페이지와 함께 이동할 것을 고려하고 있는 관리자는 임시 페이지에 사용하던 네임스페이스의 한계를 이해할 필요가 있을 것이다.아마도 우리는 User:를 사용하는 것에 동의할 수 있을 것이다.예/그런 동작의 루트로 이동. --RexxS (토크) 17:30, 2020년 8월 23일 (UTC)[응답]

• 지원 하위 페이지를 사용하여 초안을 구성하려는 사용자들은 사용자 공간을 사용할 수 있고, 하위 페이지를 사용하여 라운드 로빈 페이지 이동을 원하는 사용자들은 사용자 공간이나 프로젝트 공간을 사용할 수 있으며, 나머지 사용 사례는 메인 스페이스에서 무효가 되어 손실을 보지 않는다.DYK는 네임스페이스에 메인 페이지가 없을 때 하위 페이지가 있기 때문에 슬래시 문제가 많다. 그래서 이것은 미래에 일부 개발자의 삶을 더 쉽게 만들 수 있을 것이다.— Wug·a·po·des 20:47, 2020년 8월 20일 (UTC)[응답]

• 지지: 내게는 완전히 이치에 맞는다.그것은 드래프트 스페이스에서 드래프트 작업을 할 때 물건이 깨지는 것을 막을 것이다.아심 02:12, 2020년 8월 26일 (UTC)[응답]

• 지원 이와 같은 유사한 목적을 위해 사용되는 공간도 같은 방식으로 작동하도록 하는 것이 타당하다.· · · · Peter Southwood : —날짜 없는 코멘트 작성 08:09, 2020년 8월 28일 (UTC)[응답]

만료된 편집 메모 지우기

Wikipedia Talk에서 토론 통지:여기서 빈칸으로 만료된 편집 메모의 유지 관리 정리를 제안하는 편집 공지사항.미루는 Reader (대화) 14:08, 2020년 8월 28일 (UTC)[응답]

제2의 위키백과 블랙아웃?

ESRB/CERO/PEGI 등급을 비디오 게임 목록에 추가하십시오.

이름에서 알 수 있듯이, 게임의 등급을 오른쪽 측면 정보 패널에 추가하는 것이 매우 유익할 것이다.

이것은 또한 평가 페이지로 다시 연결하는 추가적인 이점이 있을 수 있다. (CERO A, B, C 등은 의미/연령 범위를 보지 않으면 매우 혼란스럽기 때문이다.)

As there are many systems around the world, maybe either a regional setting based on site translation (like UK only seeing PEGI, Germany only seeing USK, etc), and having the .com article contain the main release areas (usually Japan, North America, and Europe). --2600:1702:260:9100:C184:A0D6:6368:8E56 (talk) 05:27, 29 August 2020 (UTC)[reply]

그들은 포함되었지만 수년 전 합의에 의해 삭제되었다. 템플릿 토크:Infobox 비디오 게임/Archive 11#등급 제거 섹션 제안.그것들을 다시 추가하기 위한 어떤 제안도 그 논의 이후 무엇이 바뀌었는지 설명할 필요가 있을 것이고 WP:VG에게 이 논의를 알려야 한다.--67.68.208.64 (대화) 13:40, 2020년 8월 29일 (UTC)[응답]

우리는 게임이 너무 많고, 모든 게임이 그것을 얻는 것은 아니며, 영화나 TV와 같은 시청률을 가진 다른 매체들도 그것들을 포함하지 않기 때문에 그것들을 제거한다.(한나라에서 금지된 것처럼) 등급이 중요하면 몸으로 가린다. --마샘 (t) 20:47, 2020년 8월 29일 (UTC)[응답]

세계적인 측면은 이것을 내게는 별 볼일 없는 사람으로 만들어 준다.세계적인 게임은 여러 다른 보드에서 평가된다.마셈이 말하는 것처럼, 어떤 게임이 등급에 대해 특별히 주목할 만한 것을 가지고 있다면, 그것은 프로화 될 수 있다.Best Wishes, Lee Vilenski 07:39, 2020년 8월 30일 (UTC)[응답]

강하게 반대하라 등급은 문맥상 거의 제공하지 않는다.그들이 가치를 제공하는 유일한 시간은 그것을 둘러싼 논란이 있을 때 그리고 그러한 게임의 기사들은 대개 그러한 세부사항들을 기술한다.– 그리드(대화) 14:20, 2020년 8월 31일 (UTC)[응답]

보호된 항목 이동

정말 필요한 거야?나는 항상 그것들이 꽤 쓸모없는 아이콘이라고 생각해왔고, 그것은 그저 부풀어 오르는 것을 더한다.거의 아무도 이 기사들을 옮기려 하지 않는다. 아이콘은 그저 어수선할 뿐이고 이미 제거되어야 한다.예를 들어, 프랭크 시나트라.필요한 분류라면 지금처럼 템플릿/봇을 보관하고 {{pp-move}}만 편집해 토피콘 부분을 제거하면 된다.늑장부리는 Reader (대화) 17:52, 2020년 8월 27일 (UTC)[응답]

동의. {{u Sdkb}}^talk08:51, 2020년 8월 31일 (UTC)[응답]

• 제거. 메뉴에는 이동 옵션(기사 이동 권한이 없는 경우)이 제공되지 않으며, 누군가가 기사를 이동하려고 할 경우 충분한 힌트가 있어야 한다.(아마도 이유가 기재된) 보호 상태를 토크 페이지 시작 부분에 있는 항목 중 하나로 하는 데에는 작은 논리가 있다.— 고스트인The^{talk to me} Machine 09:22, 2020년 8월 31일 (UTC)[응답]

  이동 메뉴는 페이지를 이동할 수 있는 옵션을 제공한다.페이지 이동은 예를 들어 확장된 확인 수준에서 보호될 수 있으며, 새로운 편집자가 아닌 사용자가 페이지를 이동할 수 있다.~ 아모리 (u • t • c) 10:13, 2020년 8월 31일 (UTC)[응답]

  그게 고스트의 말인 것 같아?이동 버튼은 이동 권한이 있어야만 볼 수 있다.늑장부리는 Reader (대화) 12:47, 2020년 8월 31일 (UTC)[응답]

  실제로 이동 단추는 페이지를 이동할 수 있는지 여부를 나타내는 신뢰할 수 있는 표시기이지만, 페이지가 이동 보호되어 있는지 여부에 대한 신뢰할 수 있는 표시기는 아니며, 이것이 아이콘이 나타내는 것이다.편집 보호를 위해 "보기 소스"와 "편집"에 유사함.~ 아모리 (u • t • c) 18:30, 2020년 8월 31일 (UTC)[응답]

  아, 이제 알겠다.하지만 그 사건이 중요한가?즉, 거의 모든 편집자(그리고 확실히 99.9 퍼센트의 독자들)는 페이지를 이동할 수 있는지 여부와 상관없이 이동 보호되는지에 대해 별로 신경 쓰지 않는다는 것이다.아마도 여기 또는 저기 편집자가 할 수 있고(그리고 그들은 "페이지 정보"를 클릭할 수 있다), 그리고 그러한 편집자들은 보통 페이지의 정기적인 편집자일 것이다, 그러나 이미 그것은 모든 편집자와 로그인하지 않은 독자들에게 그 쓸모없는 아이콘을 보여주는 것을 정당화하지 못한다.조금이라도 보여야 한다면, 모든 것을 디폴트하기 보다는 (가젯 등을 통해) 옵트인(opt-in)이어야 한다고 생각한다.늑장부리는 Reader (대화) 19:37, 2020년 8월 31일 (UTC)[응답]

  나는 의견을 표명한 적이 없다. 단지 두 사람은 같은 정보를 전달하지 않기 때문에 서로 교환할 수 없다. 그것이 중요한지는 당신에게 달려 있다.독자는 페이지를 절대 이동할 수 없으므로(독자:=로그인하지 않은 것으로 가정), 실제로 정보를 전달할 수 있는 유일한 방법은 아이콘이다.다시, 나는 편집 보호를 위해 "보기 소스"와 유사하다.~ 아모리 (u • t • c) 00:12, 2020년 9월 1일 (UTC)[응답]

  따라서 아이콘은 실제로 "페이지 정보"를 클릭하는 것, 예를 들어 [2] DroadingReader (토크) 11:00, 2020년 9월 1일 (UTC)[응답] 정보를 전달하는 유일한 방법이다.

전역적으로 잠긴 사용자는 자신의 사용자 이름을 스트라이크아웃 스타일로 표시해야 함

가젯이 있다(특수:Preferences#mw-prefection-gadgets / 모양 / 차단된 사용자 이름 제외) 기본 설정#mw-prefection-gadgets / 차단된 사용자 이름 제외). 이 설정은 사용자 이름이 차단된 경우 해당 사용자 이름을 타격한다.내가 보기에 그것은 전세계적으로 잠긴 사용자들에게도 똑같이 해야 할 것 같다.전에도 이런 논의가 있었나?아직 시행되지 않은 것 말고도 그렇지 않은 이유가 있을까? -- 로이 스미스 (대화) 13:22, 2020년 9월 1일 (UTC)[응답하라]

로이 스미스, 미디어위키 토크에서 느린 토론/요청이 있다.Gadget-markblocked.js#Globally locked and blocked usersCabay(대화) 13:54, 2020년 9월 1일(UTC)[응답]

아, 멋지다.그 실에서 제시된 바와 같이 T261752를 개통했다. --로이스미스 (토크) 14:08, 2020년 9월 1일 (UTC)[응답]

검토를 위해 편집 플래그 지정

위키백과에서 약간 논의된 내용:마을 펌프(아이디어 랩)/아카이브 32#플래그 편집을 검토하시겠습니까?지역사회의 공감대가 형성될 수 있는지 알아보기 위해 내 아이디어를 여기로 가져오도록 격려받았지내 생각은 감사 기능과 비슷하게, 다른 편집자들의 검토를 위해 편집에 플래그를 붙일 수 있는 능력을 확립하는 것이다.이것은 편집자가 문제가 있는 편집을 보지만 문제를 제대로 다룰 시간이 없거나, 편집자가 잠재적으로 문제가 있다고 느끼는 편집을 보았을 때 유용할 수 있다. 그러나 편집자는 확실히 알 수 있는 경험이나 자신감이 없고 부적절한 되돌림으로 거기에 발을 들이고 싶지 않다.플래그가 표시된 편집은 감시 목록에서 강조 표시될 수 있으며, 다른 방식에서도 검토를 위해 캡처할 수 있다.또한 편집자들이 편안하게 문제없다고 믿었던 편집을 풀 수 있는 메커니즘이 있을 수 있다.

이 기능은 검토를 위해 다른 편집자의 편집에 태그를 지정하는 것 외에도, 편집자가 다른 사람에게 자신의 작업을 검토하도록 더 쉽게 요청할 수 있다.나는 이것이 실제로 그러한 용량에 얼마나 사용될 수 있을지는 확실치 않지만, 그것이 나쁜 생각처럼 보이지는 않는다.예를 들어, 나는 가끔 테이블을 편집하려고 했지만 내가 의도한 대로 테이블이 보이게 할 수 없었다.내 편집에 플래그를 지정하는 것은 다른 편집자들의 관심을 끌 수 있는 빠른 방법이 될 것이다.

링크드 토론에서 "changetags 권한을 더 많은 사용자(admins + rollballer?)에게 확장하고 "검토를 위해 플래그(flaged for review)"(?)라는 새로운 태그를 만드는 것"이라는 큰 어려움 없이 기술적으로 달성될 수 있다는 의견이 제시되었다.

여기서도 분명히 문제가 발생할 가능성이 몇 가지 있는데, 예를 들어, 아이디어 랩에서도 논의되었는데, 편집 내용을 플래그로 표시하여 다른 편집자를 괴롭히는 것이 충분히 쉬울 수 있으며, 이 기능을 활성화하면 편집자가 스스로 "버튼을 누르는" 가능성이 낮아질 수 있다.하지만 결국, 나는 이 강화가 그것을 가능하게 하지 않고 그것이 어떻게 진행되는지 보지 않고 걱정거리가 될 만큼 충분히 남용될 수 있는지 확인할 수 있는 좋은 방법이 있는지 확신할 수 없다.

나는 이것에 대한 다른 편집자들의 의견을 환영한다; 시간을 내줘서 고마워!도니아고 (대화) 2020년 8월 25일 14:31 (UTC)[응답]

• @도니아고:다른 자원 봉사자가 그 일을 맡기를 바라는 마음에서 꼬리표나 템플릿을 추가하는 생각이 마음에 들지 않는다.그 대신 문제가 될 가능성이 있는 편집을 되돌린 다음 WP에 이어 기사의 토크 페이지에서 토론을 시작하는 것이 좋을 것 같다.BRD. 아니면 되돌리지 말고 토크 페이지에 올려라.그 정도까지 할 시간이 없다면 나중에 WP가 될 수 있을 때 다시 이야기하십시오.볼드체로 틀린 것은 무엇이든 고쳐라.WP도 있다.RCP는 최근 문제가 있는 것들을 감시하고 있는 순찰대를 변경했다.루돌프레드 (대화) 2020년 8월 25일 16:45 (UTC)[응답]

• 도니아고, 이미 그런 특징이 있어.그것은 보류 중인 변경사항이라고 불린다.이 옵션을 선택하면 모든 편집이 승인되어야만 독자가 볼 수 있다.

나는 위키하우를 편집했는데, 그들은 그것을 한다.그러나 그들이 그렇게 할 수 있는 이유는 그들의 공동체가 충분히 작아서 반달족을 되돌리기 쉽기 때문이다.하지만 위키피디아에서는 초당 10-40개의 편집이 있다.만약 그 모든 편집이 손에 들기 전에 검토되어야 한다면, 그것은 편집자들에게 불필요한 부담을 줄 것이다.

우리는 반달리즘 봇이 잠재적으로 문제가 될 수 있는 편집들을 되돌리고, 검토가 필요할 것 같은 편집들을 보여주는 ORES가 있지만, 우리는 모든 편집들을 강제로 순찰을 돌게 하지는 않는다.그렇게 되면 편집자들이 밀린 업무들을 관리하는데 엄청난 부담이 될 것이다.이론적으로는 그렇게 할 수 있지만 실제로는 그렇지 않다.아심 18:25, 2020년 8월 25일 (UTC)[응답]

나는 네가 나를 오해했다고 생각한다; 나의 제안은 인간 편집자들이 편집에 문제가 있을 수 있는 것으로 태그를 붙일 수 있는 수동 기능에 대한 것이다.나는 자동적으로 편집에 태그를 붙이는 어떠한 종류의 백엔드 과정도 검토가 필요하다고 제안하는 것이 아니다.도니아고 (대화) 18:51, 2020년 8월 25일 (UTC)[응답]

내 생각에 그들은 당신이 편집을 취소할 수 있다면 그것의 요점이 무엇인지를 말하고 있는 것 같다.위키백과의 에미르 (대화) 21:20, 2020년 8월 25일 (UTC)[응답]

그리고 그의 반응은 누군가가 자신감 있게 되돌릴 수 없다고 느끼지만( 심지어 토론은 취소하고 시작할 수 있다) 다른 누군가가 더 나은 토론을 할 수 있다고 생각하는 명확하지 않은 편집이 있다는 것이다.나는 개인적으로 긍정적인 면이 명확한 행동의 수를 줄이는 부정적인 면보다 더 큰지 확신이 없다.코백베어 (토크) 21:23, 2020년 8월 25일 (UTC)[응답]

독일어 위키피디아는 또한 "변경 지연"/"플래그 수정"과 같은 것을 가능하게 했다.그것은 우리의 구성과 세부사항에서 다르다.어느 쪽이든, 이 제안은 일종의 다른 방편이며, 변경사항은 기본적으로 발표되지만, 누군가가 의심스럽다고 발견하면 (반복될 때까지 게시하지 않고) 검토 플래그를 표시할 수 있다.그래서 극단의 중간지대에 있다.맘에 들어. --Matthiaspaul (토크) 18:39, 2020년 8월 28일 (UTC)[응답]

• 나는 이 선들을 따라 무언가를 보고 싶다.나의 감시목록은 내가 거의 알지 못하는 주제에 대해 많은 변화를 표시한다.예를 들어, 오늘날 IP는 여러 춤의 민족적 기원을 바꾸었는데, 이는 의심스럽지만 명백히 틀린 것은 아니다.단서가 있는 사람이 확인해주길 바라는 마음으로 위키피디아에 메시지를 남겼지만, 내가 흔들 수 있는 깃발이 있다면 그 과정은 더 부드러워질지도 모른다.Certes (talk) 22:08, 2020년 8월 25일 (UTC)[응답]

Certes, 내가 정확히 기억한다면, 관리자는 특정 diff에 대한 태그를 편집할 수 있는 능력이 있다.나쁜 편집이 두 개 있으면 반달리즘으로 표시할 수 있다는 뜻이다.봇도 똑같이 할 수 있다.하지만 이 태그를 롤백자로 확장하여 편집에 적절한 태그를 적용할 수 있다면 좋을 것 같아.아심 22:34, 2020년 8월 25일 (UTC)[응답]

이 깃발은 비관리자들에게 가장 유용할 수 있다; 평범한 편집자가 "전문가가 이것을 볼 수 있을까?"라고 말할 때 사용할 수 있는 것이다.관리자만 해당된다면 여전히 유용할 수 있지만, 이미 다른 방법을 사용할 수 있는 소수의 청중을 위해 굳이 구현할 가치는 없을 것이다.Certes (talk) 23:31, 2020년 8월 25일 (UTC)[응답]

• 나는 이 아이디어에 대해 회의적이다. 왜냐하면 그러한 특징의 한계가 무엇인지 분명하지 않기 때문이다.모호한 '필수 검토' 태그를 언제 할당하는 것이 적절할지에 대한 명확한 지침이 없다면, {{cleanup}}과(와) 비슷한 상황을 초래하지 않을까 걱정되는데, 이는 간단히 "이 글은 위키백과의 품질 기준에 부합하는 정리가 필요할 수도 있다"고 쓰여 있는 기사 정비 태그다.수년 동안 일부 편집자들은 이 극도로 모호한 태그를 붙였는데, 기사들은 어떻게 정리가 필요한지에 대한 자세한 설명을 하지 않았다.이것은 분명히 바람직하지 않았고, 2012년에 마침내 코멘트 요청이 있었다. reason=필수 태그 매개 변수.이와 비슷한 맥락에서, 이 제안은 {{creamup}}의 인라인 버전 생성과 다르지 않아 보이는데, {{citation needed}, {{dubious}, 또는 {{POV satement}} 등 콘텐츠에 관심이 필요한 이유를 더 잘 알려 주는 태그가 있다면 바람직하지 않다.참고 항목: 템플릿:이러한 대안에 대한 인라인 정리 태그.Mz7 (대화) 01:25, 2020년 8월 26일 (UTC)[응답]

나는 설명을 요구하지 않고 정화 템플릿을 구현하는 것이 잘못된 조치였다는 것에 동의한다.그렇긴 하지만, 나는 사람들이 이 태그를 사용하기를 원하는 이유를 기존 또는 아마도 새로운 템플릿에 쉽게 속일 수 있다고 생각하지 않는다. 만약 그럴 수 있다면, 나는 지금 당장 새로운 템플릿의 창조를 지지할 것이다.:)

임의의 예로서 - 내 감시 목록을 검토하고 있는데, 거기에 영화 기사가 나열되어 있는 것을 본다.그 차이점은 한 편집자가 영화의 리셉션을 다루는 기존의 일부 텍스트를 재구성했다는 것을 보여준다. 그리고 몇몇 유명한 영화 감독들이 이 영화를 얼마나 훌륭하다고 생각했는지에 관한 정보를 추가했다.이 정보가 기사 추가에 적합한가?맞아, 그들은 유명한 영화감독이고 그들의 의견이 중요하거든.아니, 왜냐하면 그들은 영화 비평가로 알려져 있지 않고 그들의 의견이 다른 사람들보다 더 비중 있게 다뤄질 자격이 없기 때문이다.아마도, 그것은 고전 영화에 무게를 두고 있는 여러 영화 감독들이기 때문이다.나는 이것을 파헤치고 싶지만, 그러한 삶의 상황들 중 하나가 내가 알 수 없는 기간 동안 떨어져 있어야 하는 것이다.내가 설득력 있는 Talk 페이지 토론을 시작할 시간도 없고, 당장 떠오르는 적절한 템플릿도 없다.내가 편집에 플래그를 달 수 있다면, 다른 사람이 곧 편집에 도착하지 않더라도, 그것은 여전히 훌륭할 것이고, 아마도 나 자신도 그것을 볼 것이다.

이게 도움이 되었으면 좋겠어!나는 이것이 얼마나 대단한 아이디어인지 또는 잠재적인 의견 차이가 프로보다 더 큰지 잘 모른다는 점에서 다른 편집자들의 의견에 동의하지만, 적어도 청문회는 받을 만해 보였다.건배!도니아고 (대화) 17:24, 2020년 8월 26일 (UTC)[응답]

• 나는 허글이 비슷한 기능을 가지고 있다고 믿지만, 그것은 사실 노골적인 반달리즘(기본적으로 허글의 목적)에만 나타날 것이다.이 기능성에 관한 한, 개발 노력이 필요할 것이고, 모두가 알고 있듯이, 커뮤니티 위시리스트에서 3~4년 연속 1위를 한 후에 자원 배분을 위해 3-5년을 더 기다려야 비경쟁적 기능을 구현할 수 있는 개발 시간을 얻게 될 것이다.그때도 어쩌면 그럴지도 모른다.그래서 현실적으로, 아마도 일어나지 않을 것이다.이에 가장 근접하게 접근할 수 있는 것은 WP:CCI와 같은 중앙 저장소로 편집본을 보낼 수 있는 버튼이나 특정 위키피디아의 대화 페이지로 편집본을 보낼 수 있는 더 쉬운 방법을 제공하는 사용자 설명이다.하지만 솔직히 기능성은 금방 압도될 것 같아.늑장부리는 Reader (대화) 20:41, 2020년 8월 26일 (UTC)[응답]

  @ProcrasingReader:인프라가 이미 존재하기 때문에 개발 시간이 필요하지 않다.필요한 유일한 변경 사항은 관리자 이외의 사용자 그룹(사소한)으로 변경태그를 확장하고 새 태그(관리자가 로컬로 수행할 수 있음)를 만드는 것이다.여기서 정말 필요한 것은 지역사회의 합의뿐이다.– SD0001 (대화) 10:18, 2020년 8월 31일 (UTC)[응답]

  SD0001, 내가 정확히 이해한다면, 그 교환권들을 주는 것은 또한 사람들이 태그를 제거할 수 있도록 허용한다?url 예제, 권한 보기:개별 리비전 및 로그 항목(변경 태그)에 임의 태그를 추가 및 제거하십시오.나는 그 기능을 분리하는 것이 불가능하다고 생각한다. 그리고 우리는 분명히 사람들이 태그를 제거할 수 있도록 허용하고 싶지 않다.우리가 그것을 회피할 수 있지만(예: 이 태그가 아닌 태그의 제거를 되돌리는 봇, 또는 태그 변경을 위해 로그를 보는 패트롤러) 나는 여전히 그것에 대해 무관심하다.더 좋은 방법은 수정본이 있는 기사에 숨겨진 템플릿을 매개변수로 추가하는 스크립트(트윙클에 추가)를 사용하여 수정본을 '태그'하는 것일 수 있다.봇은 그러한 개정사항의 목록(즉, 지정된 개정사항이 있는 템플릿의 전용)을 컴파일한다.늑장부리는 Reader (대화) 11:27, 2020년 8월 31일 (UTC)[응답]

  메, 만약 누군가 태그를 추가할 권리가 있다면, 그들도 태그를 제거하도록 하는 것은 당연하다.나는 그것에 대해 무엇이 논란이 되는지 모르겠다.스크립트를 사용하여 "태깅" 수정본을 작성하면 페이지 기록에 새로운 항목이 작성되고 태그도 제거해야 하므로 이력이 복잡해진다.OTOH는 네이티브 태깅 기능을 사용하여 아무도 보지 않는 태그 로그만 잡는다. – SD0001 (대화) 11:48, 2020년 8월 31일 (UTC)[응답]

  SD0001, 제 말은: 문제는 그들이 (사용된 편집기, 모바일 등) 기존의 태그를 제거할 수 있다는 겁니다.그들이 추가한 태그는 제거해도 괜찮지만 다른 태그는 제거하지 않는다.늑장부리는 Reader (대화) 12:16, 2020년 8월 31일 (UTC)[응답]

• 나는 특히 이 제안이 마음에 든다. 만약 플래거가 가능한 이유의 미리 정의된 리스트에서 이유를 명시할 수 있다면, 혹은 눈에 보이는 코멘트를 남길 수 있다면, 그래서 다른 편집자들이 그들이 찾아야 할 것을 더 쉽게 알 수 있을 것이다.

남용될 가능성이 있기 때문에, 우리는 일부 임계값을 초과하는 로그인한 사용자들에게만 이것을 허용해야 하지만, 많은 사용자들이 그것을 사용할 수 있도록 문턱이 상당히 낮아야 한다.또한 검토 태그가 공개적으로 표시되어야 하는지 또는 개인적인 용도로만 표시되어야 하는지를 선택하는 것이 유용할 수 있으며, 이후 검토를 위해 특별 내부 목록에 열거되어 있다(시간이 허락할 때).

오늘날 대안은 편집(이상적이지만 시간이 부족하여 가능하지 않은 경우가 많음)을 개선하거나, 되돌리거나, 토크 페이지 스레드를 여는 것이지만, 이후 두 가지 옵션은 편집 내용을 볼 충분한 시간과 인력으로 주어진 훨씬 더 미묘하고, 느긋하고, 우호적인 방법으로 해결될 수 있는 문제들에 대해 불필요한 스트레스와 드라마를 만들어 내는 경우가 많다.

--Matthiaspaul (대화) 18:39, 2020년 8월 28일 (UTC)[응답]

나는 미리 정의된 목록을 추가하면 기술적으로 더 복잡해질 것이라고 상상하지만, 그것이 훨씬 더 복잡해질지는 잘 모르겠다.나는 눈에 보이는 코멘트에 대해서는 잘 모르겠다. 그 시점에서 당신은 더미 편집을 할 수 있을 것이기 때문이다.로그인한 사용자로 제한하는데 동의함.새로운 편집자들이 이용할 수 있다면 아마도 이 기능에 더 의존할 가능성이 높기 때문에, 나는 낮은 임계값도 좋을 것이라고 동의한다.

내 느낌은 리뷰 태그가 공개적으로 보여서 다른 편집자들도 검토해서 이 문제를 해결할 수 있도록 해야 한다는 것이다... 또는 문제가 없다고 생각될 경우 편집의 태그를 해제하십시오.

생각해줘서 고마워!도니아고 (대화)19:18, 2020년 8월 28일 (UTC)[응답]

이유를 지정하는 기능도 이미 존재한다. Special:log/tag를 참조하십시오.– SD0001 (대화) 10:22, 2020년 8월 31일 (UTC)[응답]

나는 이것이 "롤의 헌장"이 될 수 있을지 걱정된다.사용자가 하는 모든 것을 플래그로 표시하거나, 정치적 또는 다른 입장에 동의하지 않아 편집에 플래그로 표시하거나, 하원의원이나 이와 유사한 사용자가 편집에 플래그로 표시하여 불편하게 만드는 것은 사실일 수 있다.편집 태그가 조작되는 것을 막기 위해 어떤 안전장치가 있는가? 독토럽_words^deeds 10:02, 2020년 9월 2일 (UTC)[응답하라]

그게 괴롭힘과 차단 가능한 범죄라는 사실 말고도?도니아고 (대화) 13:51, 2020년 9월 2일 (UTC)[응답]

대화 페이지

기사의 토크 페이지에서는 "토크 페이지는 위키피디아 기사에 대한 토론을 위한 것이지, 주제에 대한 일반적인 토론을 위한 것이 아니다"라고 말하는 경우가 많다.하지만, 만약 누군가가 대화 페이지에 언급된 것을 읽는다면, 꽤 자주 그 이야기가 기사보다 더 주제에 더 많이 다뤄지게 된다.상당히 급진적인 제안이 될 토크 페이지를 전면 폐지하는 것 외에, 우리는 그 주제에 대한 토론을 허용해야 하는가?보르비 (대화) 06:05, 2020년 9월 4일 (UTC)[응답]

• 처음에는 싫다고 말하곤 했다.그 지침은 대화 페이지의 파괴적인 토론에 개입하기 위한 실행 가능한 도구다.만약 그렇다면, 그것은 폐기되지 않고 인용 가능한 정책으로 업그레이드되어야 할 것이다.VanIsaac_WS^cont 06:17, 2020년 9월 4일 (UTC)[응답]
• 이것은 항상 나를 어리둥절하게 했다.만약 내가 기사에 무언가를 추가해야 하는지에 대한 의견을 구하고 싶다면, 이것은 기사에 대한 것보다 주제에 대한 토론으로 귀결되어야 한다.만약 내가 필수 과목 지식을 가진 누군가가 기사에 무언가를 덧붙일 수 있다고 제안하고 싶다면, 그 다음에 디토.등. 다운사이즈43 (대화) 06:59, 2020년 9월 4일 (UTC)[응답]

• 특정 콘텐츠 관련 스레드가 더 일반적인 토론으로 확대되는 것에 비해, 일부 사용자들이 기사 토크 페이지에 도착하여 주제에 대한 토론을 시작할 수 있는 정도(의견 유출, 페이지를 포럼으로 취급)라고 생각한다.나는 주제에 대한 폭넓은 논의가 종종 불가피하며, 가장 중요한 것은, 문맥이 종종 고립된 한 점에 집중하기 보다는 종종 필요하기 때문에, 진정한 콘텐츠 관련 토론에 유익할 수 있다는 데 동의한다.나는 편집자들이 WP를 인용하면서 더 노골적인 채팅 버라이어티를 닫는 것을 보았다.NOTFORUM (#4) 그것은 매우 분별 있는 것이다.긴급한 사례가 없는 한 가이드라인이 잘 작동하고 잘 적용된다고 할 수 있다.JG66 (대화) 07:19, 2020년 9월 4일 (UTC)[응답]

친절하고 도움이 되는 코멘트에 감사드린다.이 문제는 위키백과에서 이미 논의되고 있는 것으로 알고 있다. 3.4조에 따른 지속적인 제안.보르비 (토크) 07:48, 2020년 9월 4일 (UTC)[응답]

짧은 설명과 Wikidata 설명 동기화