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

파란색 및 빨간색 알림 다시 가져오기

나는 어제 바뀐 방식이 마음에 든다.이제 다시 한번 구식이다.

우리의 토크 페이지 메시지에는 파란색이요.

사용자 이름 ping을 위한 주황색이며, 모든 토론에서 언급된다.

우리가 만든 페이지를 순찰하고 편집한 것에 대한 감사를 받을 때 초록색.

경고나 다른 부정적인 것들을 받았을 때 빨간색.--액션 히어로 슈팅! 2015년 9월 15일 (UTC) 14:31, 15 (응답)

Hey Action Hero: 그 변화는 일시적인 것으로 보인다.HTH, --Eltre (WMF) (토크) 14:57, 2015년 9월 15일 (UTC)[응답하라]

패트롤러 사용자 시간 맞지?

오렌지무디 사건에서 보듯이, 우리의 새로운 페이지 순찰대는 양말퍼펫을 통한 우회술에 취약하다.그것은 또한 계속되는 패트롤러 역량 문제로 고통받고 있다.이러한 문제를 관리하는 데 도움이 되는 "patroller" 사용자 권한을 추가해야 할 때인가?VQuakr (대화) 04:17, 2015년 9월 8일 (UTC)[응답]

더 나은 솔루션:"자동 확인"과 유사하게 만드십시오(사용 빈도가 낮은 "patroller" 및 "no-patroller" 사용자 권한 사용)."straw"의 예로서, "자동" 권리를 가지려면 벨트 아래에 "10개 기사/1000개 편집/90일" 또는 "0개 기사/4000개 편집/1년"이 있어야 하며, 여기서 기사는 기사로서 최소 7일/7일(즉, 최근에 이동한 초안은 계산되지 않음), 특정 크기(예: 100바이트), 삭제는 상담에 포함되지 않아야 한다.t. davidwr/(talk)/(contracts) 04:38, 2015년 9월 8일(UTC)[응답]

새로운 계정으로 검토하는 데 어떤 장벽도 개선될 수 있지만, 양말마스터 위에 링크된 남용 사례에서는 게임 오토콘 확증을 위해 더미 편집을 했다.이와 유사한 "자동" 권한은 유사하게 게임할 수 있으며, 권한을 할당하는 경우 발생하는 정밀 검사를 초대하지 않는다.오토콘 확증과는 달리, 패트롤러 권리는 대부분의 편집자들이 필요하거나 사용하지 않을 권리다.VQuakr (대화) 04:44, 2015년 9월 8일 (UTC)[응답]

오렌지무디 케이스와 같은 정교한 양말장갑에 관해서 어떻게 "비자동화"를 만들 수 있는지 모르겠다.그런 양말로는 양말장수가 규칙을 배우고 양말장수가 관리자들을 속일 것이다.유일한 차이점은 그것이 관리자의 시간을 빨아들이거나 관리자가 1, 2분 이상을 소비하지 않을 것이고 그들의 "조사"는 실제로 "자동" 권리와 동등한 기계적일 것이라는 점이다.요컨대, 이 사용자 권리는 이와 같은 정교한 경우에 도움이 되지는 않겠지만, 아마도 덜 세련된 양말장갑에 대해서는 도움이 될 것이다.또한, "자동" 권리 대 "정규" 권리에는 한 가지 큰 이점이 있다: 만일 내가 노련한 편집자이고 오늘 내가 페이지를 순찰하고 싶은 변덕을 결정한다면, 나는 나에게 부여되는 권리가 주어지기를 기다릴 필요가 없다. 데이비드wr/(토크)/(기고)/(기고) 05:06, 2015년 9월 8일 (UTC)[응답]

새로운 페이지 순찰에 기부를 시작한 사람으로서, 아무도 새로운 페이지 순찰에 기부를 시작해서는 안 된다.페이지를 제대로 태그할 수 있는 문맥이 없고, 어떤 새로운 사용자도 그런 상황에서 훨씬 더 잘 할 것이라고 기대하지 않았기 때문에 관련 정책을 읽었음에도 불구하고 많은 실수를 했다.Orangemoody 사건, 그리고 요구조건이 다소 낮은 한 순찰하는 경험이 풍부한 편집자들의 만족도 때문에 페이지 순찰을 위한 사용자 권리는 분명히 적절하다.나는 45일, 최소 250일 또는 500회의 편집과 (오렌지무디에서처럼 문턱에 도달하기 위해 약간의 복사나 링크 추가의 사용에 대항하기 위해) 중요한 편집의 입증 가능한 이력을 제안하고 싶다.만약 우리가 그것보다 훨씬 더 높이 간다면, 우리는 새 페이지 순찰을 크게 증가시킬 위험을 무릅쓸 것이다.~ 롭^Talk 05:02, 2015년 9월 8일 (UTC)[응답]

좋은 지적이야.만약 밀린 일이 너무 길어진다면, 우리는 "patring"을 완전히 버려야 할 것이다. davidwr/(talk)/(contracties) 05:06, 2015년 9월 8일 (UTC)[reply]

오렌지무디가 누군지는 모르겠지만, 그의 주제는 확실히 주목을 받지 못한다.나는 많은, 많은 불공평한 신속한 안내의 대상이 되어왔다.나는 모든 사람들이 그들이 불공평하다는 것에 동의하지 않으며 약간의 차이점을 제공하는 것을 좋아할 것이라는 것을 안다.오타와히텍 (대화) 11시 38분, 2015년 9월 8일 (UTC)[응답]

오타와히테흐, 소식을 듣게 되어 반갑다!잘 지냈으면 좋겠다.나는 섹션 시작부분의 내 포스트에 오렌지무디에 대한 기사를 링크했다: 짧은 이야기, 그것은 무고한 희생자들로부터 돈을 갈취하려고 시도하는 위키피디아의 웹 존재와 열린 본성의 복잡한 착취였다.새로운 페이지 순찰 게임을 하는 것은 그 공격의 일부분이었다.하지만, 나는 이 시점에서 해결책이 필요한 문제에 대한 충분한 증거가 있기 때문에 디프가 필요하지 않다고 생각한다.VQuakr (대화) 21:27, 2015년 9월 8일 (UTC)[응답]

낯익은 얼굴 보니 반가워, VQuakr.몇 년 동안 나처럼 얼토당토않은 사람에게조차 명백하게 드러난 문제를 마침내 인정하는 데 왜 그런 스캔들이 필요했는지 궁금하다.이 특정 스레드에 참여하지 않는 편집자가 이 승인을 공유한다고 BTW가 확신하십니까?오타와히텍 (대화) 13:37, 2015년 9월 9일 (UTC)[응답]

• 나는 아이디어 랩에서 비슷한 것을 제안했었다: 대기 중인 변경 검토자 및 관리자로 순찰 제한하고, 추가적인 패트롤러 그룹을 만들 수도 있다.기본적으로 네 가지 옵션이 있다.

1. 고유한 사용자 그룹 검토자/패트롤러
2. 순찰할 수 있는 검토자가 있는 두 개의 별개의 그룹
3. 패트롤러가 검토할 수 있는 두 개의 뚜렷한 그룹
4. 두 개의 개별 사용자 그룹

NPP에서 활동 중인 많은 (전부는 아니지만) 사용자들은 애당초 리뷰어인 반면, #4는 관리자를 위한 중요한 작업을 수반하기 때문에 #1로 가는 것이 가장 간단한 선택이다.#2는 처음부터 NPP에 대한 중요한 사용자 기반을 보장하여, 백로그 증가의 우려를 완화시키고, #3보다 더 타당하다.

그래서 나는 #2를 지지한다: 오토콘 확증에서 'patrol'을 제거하고, 'patrol'로 새로운 patroller 사용자 그룹을 만들지만, 검토자는 'patrol'을 하게 한다.세나리움 (대화) 2015년 9월 8일 (UTC) 15:00[응답]

• • 또는 별도의 사용자 권한을 도입할 수 있지만 자동 확증에 "patrol"을 부착한 상태로 30일 동안 유지하여 자동 확증 사용자로부터 보호자가 권한을 빼앗기기 전에 요청할 수 있는 기회를 제공한다.이렇게 하면 4위로 전환하는 동안 밀린 일이 늘어나는 문제를 해결할 수 있을 것이다. ~ 2015년 9월 8일 (UTC) 롭^Talk 15:47, 롭(Rob)
• 여기서 논의가 진행 중이기 때문에 아이디어 랩에서 내가 말해야 했던 부분만 간단히 반복하겠다.

  우리가 어떤 정권에서 전용상업기업을 설립하든 그 길을 찾을 수 있다.어떤 "NPP 검토자"의 사용자 권리로든 계정을 만드는 데는 시간이 좀 걸리겠지만, 테이블 위에 돈이 있을 때는 사소한 일이다.그 때 우리의 최선의 선택은 'NPP 사용자 권리'를 가진 사람은 편집에 대한 보상을 받지 못할 수 있다고 말함으로써 사용자 권리를 이용 약관에 묶는 것이다(GLAM, WiR, 재단의 직원 등)오렌지무디(Orangemoody) 타입으로 멘토링이나 많은 경험을 필요로 하는 것들을 감지하는 것에 대해서는.AGF는 우리가 순진하지만 선의의 사람으로서 적절한 지침이 필요한 각각의 새로운 편집자를 다루기 위해 우리의 손을 묶고 있고 각 NPP는 그것을 어떻게 관리해야 하는지를 알아내야 하기 때문이다.나는 우리에게 나쁜 신념을 가진 유료 편집자 등을 찾아내고 다루는 법을 알려주는 것을 본 적이 없다.만약 우리가 그것을 알아내려고 노력한다면 우리는 '삭제주의자'와 '과욕주의자'라고 불리며, 이것은 조만간 사람들이 포기하거나 적은 숫자로 스스로 경영하는 방법을 알아내게 되는 것이다.물론 꼭두각시 팔뚝이 밀고 있는 기사를 인식하기 위한 지침을 주는 것은 거의 게시되자마자 무용지물이 될 것이다.WP만 있다면 훨씬 더 쉬울 것이다.CABAL 제어 NPP :)[1]

  우리가 정말로 할 수 있는 유일한 것은 우리의 권리 기준을 통과할 수 있는 계정을 만드는 데 필요한 시간/비용을 늘리는 것이다.나는 또한 문턱을 지날 때 자동으로 권리를 부여하고 지지하지 않을 것이다.한 가지 가능성은 사용자 권리와 함께 확인되는 것을 30일 정도 후에 권리 또는 다른 관리자에게 권리의 사용을 확실히 하기 위해 권리와 다른 관리자가 NPP를 검토하는 2단계 과정으로 만드는 것이다.나는 이것이 특히 새로운 사용자 권리를 롤아웃할 때, 과중한 업무에 시달리는 우리 관리단에게는 다소 시간이 걸릴 것이라는 것을 알고 있다. 그러나 2단계 검토를 하는 것은 심지어 신용이 좋지 않은 계정도 프로젝트에 긍정적인 기여를 해야 한다는 것을 의미한다.그리고 그렇게 하기 위해 시간을 들여서 우리의 시스템을 파괴하는 데 드는 비용을 증가시킨다.Jbh^Talk 15:24, 2015년 9월 8일 (UTC)[응답]

@Jbhunley: 재관리 작업부하, 허가의 실제 추가 및 제거만 관리 플래그가 필요할 것이다.패트롤러의 후속 "요청"은 관리자가 아닌 사람에 의한 동료 검토를 통해 수행될 수 있다.우리는 이미 비슷한 목적으로 WP:NPP/N을 보유하고 있다.VQuakr (대화) 2015년 9월 8일 19:32, (UTC)[응답]

@VQuakr:안전 점검은 좋은 NPP를 '성장'하기 위한 적절한 피드백을 제공하는 데 유용할 것이다. 그러나 내가 제안하고 있는 것은 아마도 분명하지 않을 것이다. 그 과정은 다음과 같은 것으로 진행된다는 것이다.

1. (정책으로 설정된 일부 최소 기준)을 가진 편집자는 NPP-사용자-권한에 대한 요청을 하고 새로운 페이지 순찰을 실시할 계획이라고 말한다.
2. 관리자는 요청을 검토하고 빨간색 플래그가 나타나지 않으면 권한을 부여한다.(일반적으로 여기서 끝나게 된다)
3. 30일 정도 후에 다른 관리자(또는 NPP 동료)는 편집자의 기여도를 검토하여 그들이 최소한의 순찰(최소 50개의 밝은 줄)을 수행했는지 확인하고, 그들이 정확하며, 위키피디아에 정책적으로 준수되지 않는 기사를 가져오기 위해 다른 편집자와 함께 일하는 것과 같은 나쁜 행동을 보이지 않는지 확인한다.
4. 편집자가 에 실패하면 30일 이내에 NPP-사용자-권리가 제거되므로 관리자는 롤백 또는 검토자에 대해 현재와 같이 워크로드 증가를 볼 수 있다.

이것은 몇 가지 일을 할 것이다.첫째로, 그것은 역량에 대한 보험을 들 것이다. 이것은 편집자가 NPP를 하기 전에 실제로 확인될 수 없다.그것은 권리를 가진 편집자들이 기꺼이 그 일을 할 것을 보장함으로써 모자 수집을 줄일 것이다.가장 중요한 것은 상업적 편집 링이 자신의 기사를 스스로 순찰하는 것을 막는 관점에서 그것은 올바른 기사를 얻는 데 드는 비용을 증가시킨다.최소 기준을 얻기 위해서는 시간이 소요되어야 하며, 그들은 초기 검토에 맞설 수 있도록 페이지 작성 정책을 실제로 배워야 한다.또 다른 이점은 검토 과정이 확립됨으로써 NPP 편집자의 현장 확인을 할 수 있는 편집자의 간부가 생겨나고 문제가 발생할 경우 이를 해결할 수 있는 장소가 마련된다는 것이다.

이 사용자 권리의 주요 목적 중 하나는 유료 편집 링이 리뷰 없이 위키피디아에 자료를 삽입하는 것을 방지하는 것이기 때문에 우리는 모든 고급 사용자 권리는 상업적 편집 링에 실제 현금 가치를 가지고 있다는 것을 기억해야 한다.우리의 프로세스가 전복되는 횟수를 제한하는 유일한 방법은 (회계연령과 '신뢰성' 구축에 힘쓰는 일 둘 다에서) 시간적 투자를 사용자 권리를 갖는 실제 현금 가치보다 또는 매우 근접하게 만드는 것이다.나는 그것이 일종의 관료적이고 많은 위키피디아 사람들과는 정반대라는 것을 알지만, 선의의 편집자들이 (역량을 증명할 수 없는) 진입 장벽을 세우는 것은 정말로 그 프로젝트로 돈을 벌려는 사람들을 상대로 한 유일한 방어 자원봉사자들이다.Jbh^Talk 20:36, 2015년 9월 8일 (UTC)[응답]

• 물론 우리는 이것이 필요하다.누가 그것을 얻는지에 대해서는, 정확하게 추가되거나 제거된 CSD 태그 몇 개가 이 사용자 권리를 위한 최고의 자격요건이 될 것이라고 말하고 싶다.향후 오렌지무디 유형의 사건과는 별도로, 이러한 이용자 권리의 큰 장점은 필요할 때 쉽게 빼앗길 수 있다는 것이다.나는 꽤 많은 속도를 줄였고, 많은 것들은 정확하게 하려고 하는 사람들에 의한 고립된 오류였고, 몇몇은 기사가 태그가 붙었을 때 정확했지만, 그 이후에 기사를 수정함으로써 부정확하게 되었다.그러나 우리는 빠른 삭제 기준에 대한 그들 자신의 해석을 고집하는 패트롤러들이 있다.2015년 9월 8일(UTC) 15:50, 에레슈피엘체커스[응답]

• 뉴 페이지 패트롤러에 대한 최소한의 자격요건들을 도입하는 것에 초점을 맞출 때인 것은 사실이다.내가 여러 해 동안 여러 번 말했듯이, NPP는 원치 않는 새로운 기사에 대한 우리의 유일한 방화벽이며 거의 관리자 수준의 단서를 필요로 하는 핵심 과정이다.역설적으로 훨씬 덜 중요한 AfC 프로젝트는 500개의 메인 스페이스 편집과 90일(내가 소개한 것)이 필요하다.

The Blade of the Northern Lights, WareSpielCequers, Scottyung과 내가 치열하게 싸운 훌륭한 페이지 큐레이션 도구 모음은 3만개가 넘는 백로그를 '미어' 3,000개의 기사로 크게 줄였지만, 물론 여전히 우리가 디자인했던 방식으로 지능적으로 사용할 수 있는 사람들과만 못하다.

페이지 큐레이션 시스템의 출시와 동시에, 그것은 원래 그것에 대한 사용자 권리를 도입하기 위한 것이었지만, 당시에는 이것이 이루어지지 않았다.따라서 NPP의 필수 운영은 반반자주의, 보류 중인 변경 등과 같은 모든 기능과 달리 훈련, 경험, 특별한 권리를 요구하지 않는다는 것은 이례적인 일로 남아 있다. 그리고 내가 NPP에 보내는 1시간 세션에서 내 운영의 대부분은 잘못된 태그를 수정하고 CSD(또는 기준 변경), 비파티컬을 수정하고 있다.태그가 적용되지 않은 위치의 링 및 태그 지정, 태그가 지정된 이슈를 처리할 수 있도록 작성자 알림 등.우리가 우리의 패트롤러들을 믿을 수 없다는 것은 매우 좌절스러운 일이다. 그리고 그들의 포탈을 통과하는 몇 페이지 동안 AfC에서 그것에 대해 어떤 것도 하고 싶어하지 않는 것은 훨씬 더 큰 걱정이다. 매드 해터의 다과회에서보다 더 많은 행동과 소음이 있고, 우리의 NPP 게시판과 대화 페이지는 종종 휴면상태로 남아 있다.r개월

나는 AfC 검토자, New Page Patroller 및 PC 검토자를 비교적 높은 임계값을 가진 하나의 사용자 권리에 묶을 것을 강력히 제안한다.이것은 관료주의를 줄이고, 검토의 질을 높이며, 모자 수집가들을 위한 코트 페그의 수를 줄일 것이다.게다가, 그것은 기술적으로 우리가 이미 합의점을 가지고 있는 AfC와 NPP의 합병을 위한 기반을 마련할 것이다.

위키백과에서 적절한 RfC를 실행해야 한다.이미 요청된 통계 및 표에 대기하고 있으며 이미 NPP 기본 페이지를 재설계하고 있는 사용자 권한에 대한 새로운 페이지 순찰/RfC.VQuakr은 이미 전용 게시판을 설계했고 교육부가 만들어졌다.많은 일들이 있었고 아마도 DGG는 그가 흥미로운 아이디어들도 가지고 있다는 것을 알기 때문에 관여할 수 있을 것이다.쿠드풍 กุผึ ( ((토크) 16:28, 2015년 9월 8일 (UTC)[응답]

"신뢰할 수 있는 편집자" 깃발과 그러한 권리가 있는 것은 이치에 맞고 서류 작업을 줄인다.관리자가 권한을 부여했지만 정책 지침을 제공할 수 있는 임계값이 있는 경우데니스 브라운 - 2015년 9월 8일 16:38, 8일 (UTC)[응답]

FWIW, 나는 개인적으로 PC 리뷰어가 이 새로운 NPP 권리에 포함될 필요가 없고, 별개의 것으로 남아야 한다고 생각한다.PC 검토자는 실제로 자체 보호에 유용하다. --IJBall (contracts • talk) 20:26, 2015년 9월 8일 (UTC)[응답]

• 나는 전에는 그런 생각에 매우 적대적이었고, 지금도 그것에 대해 꽤 회의적이지만, 최근의 발전에 비추어 볼 때 나는 우리가 새로운 페이지를 순찰하기 위한 최소한의 막대가 필요하다는 것을 인정해야 한다.그러나 나는 "10개 기사/1000개 편집/90일"이나 "0개 기사/4000개 편집/1년"과 같은 높은 바는 결코 지지하지 않을 것이다.나는 우리의 NPP체계가 반반항원주의를 위한 현재의 방법에 기초할 것을 제안한다.우리는 패트롤러 사용자 권리를 설정했는데, 이는 반반달리즘에 대한 '롤백' 권리와 유사하다.그것이 실행되면, 우리는 CVUA와 비슷하게 NPP 아카데미를 더 널리 광고할 필요가 있을 것이다.프로그램이 완료되면 사용자는 WP에서 권리를 신청할 수 있다.RFPERM. 나는 또한 검토자 패키지에 자동으로 권한을 추가하는 것에 찬성할 것이다. 검토자를 신뢰하는 사람은 새로운 페이지를 검토할 수 있을 만큼 충분히 능력이 있을 것이다.또한 Special을 통해 롤백하지 않고 수동으로 되돌릴 수 있기 때문에 수동 페이지 순찰(예: 새 페이지 피드 없음)을 계속 허용할 수도 있다.최근 변화들. --Biblioworm 17:08, 2015년 9월 8일 (UTC)[응답하라]
• 나는 헌신적인 "patroller" 권리를 강력히 지지한다.품질을 순찰하는 위키피디아는 느리지만 확실히 영(0)에 가까워지고 있다.그러나 바는 높은 기준과 과장된 요구사항보다는 슈터 게임이 아니라 심각한 수준의 새로운 페이지를 순찰하는 것에 대한 신뢰와 치료에 더 중점을 두어야 한다.2015년 9월 12일 02시 52분 (UTC)[응답]
• 패트롤러 맞는 말이 좋은 생각처럼 들린다.물론, 일부 사람들이 위에서 말했듯이, 재정적으로 동기부여를 하는 나쁜 배우는 단지 권리를 획득할 수도 있다. 그렇게 해야 하는 것은 그들의 계획을 더 어렵고 노출하기 쉽게 만들 것이다. 만약 순찰자 권리를 얻기 위해 100개의 메인 스페이스 편집이 필요하다면, 그들은 각 순찰 계좌에 시간을 투자해야 할 것이다.빠른 자동 편집으로 속임수를 쓰거나 소수의 순찰 계정을 사용하고, 만약 누군가가 그들과 함께 순찰하는 페이지에서 특이한 패턴을 발견하면 발견 위험을 감수한다. --조금 (대화) 05:40, 2015년 9월 12일 (UTC)[응답]
• NPP 수행 문제는 RfCs 검토 문제와 동일하며, 동일한 사용자 권한이 필요하다.나는 그 권리가 하위 계층에도 할당될 수 있다는 이해와 함께, 그 권리의 자동 배정을 위한 높은 바를 지지할 것이다.NPP 부분은 여전히 새로운 페이지에 태그를 지정하는 것은 허용하지만, 그것들을 순열로 표시하지는 않는다.RfC 부분은 여전히 코멘트를 할 수 있다.막대가 충분히 높게 설정되어 있으면 자동 사용자 권한을 대체할 수 있으며, 이 경우 사용자는 자신의 물품을 확인할 필요가 없다.권리의 부여를 위해서, 나는 그것이 기사를 만들 필요가 없다고 생각한다. 아마도 대부분, 우리의 가장 효과적인 검토자와 패트롤러들 중 많은 사람들이 처음부터 거의 기사를 만들지 않았고, 그들 중 몇몇은 전혀 만들지 않았다.나는 자동적으로 권리를 부여받을 수 있는 가능성에 동의하지 않지만, 많은 문제들이 있다.자동허가는 물품의 생성을 요구해야 하지만 나는 이것이 자동화될 수 있는지 모르겠다.자동 배정을 위해서, 나는 그것으로 여러 개의 양말 퍼펫을 만드는 기술을 아주 철저하게 억제할 수 있는 수준으로 막대를 설정했을 것이고, 나는 적어도 90일, 500일 정도 편집했다고 생각한다.(물론, 그 전에 선의로 그것을 받을 자격이 있는 사람, 그리고 많은 사람들이 그것을 간단히 요구할 수 있을 것이다.)관리자들에 의해 제거되고 승인될 것이다; 나는 우리가 어떻게 자동 레벨에 도달함으로써 제거의 극복을 막을 수 있는지 모르겠다.나는 첫 번째 보조금 지급이 제한된 기간 동안 이루어져야 한다는 이전의 제안이 마음에 드는데, 이 점검 과정이 어떻게 자동화될 수 있는지 모르겠다.몇몇 유료 편집자들은 좋은 리뷰를 하고, 모래는 권리를 가질 만하지만, 절대로 자동적으로 자격이 주어지지 않아야 하고, 그 또한 자동화가 될 수 있을지는 잘 모르겠다. DGG (토크 ) 2015년 9월 13일 19:25 (UTC)[응답]

@DGG: 페이지를 "등록"으로 표시하는 기술적 조치가 제안된 권리가 통제해야 하는 것이라는 데는 동의하지만, 자동 등록 권리와 동의어가 되어야 한다는 데는 동의하지 않는다.질 좋은 기사를 만들고 순찰하는 것은 작가와 편집자의 기술만큼이나 다른 기술이다.물론 많은 숙련된 위키피디아 사람들이 둘 다 허가를 받을 가치가 있지만 둘 다 가질 가치가 있는 많은 위키피디아 사람들이 있다.VQuakr (대화) 05:03, 2015년 9월 16일 (UTC)[응답]

상당히 겹치는 부분이 있다.현재 우리는 매우 쉽게 자동출국할 수 있다.기본적인 기술 세트의 많은 부분이 똑같다. 대부분의 사람들은 다른 기술보다 한 기술을 더 잘한다.문법과 작문 원리에 대한 지식이 없으면 아무도 작가나 편집자가 될 수 없듯이 말이다. DGG (토크 ) 05:19, 2015년 9월 16일 (UTC)[응답]

임시 네임스페이스

나는 선의의 새 사용자들이 새로운 기사를 만들고 다른 방법으로 작업하는 것을 막는 것에 강력히 반대한다.내가 제안하는 것은 드래프트 네임스페이스를 더 잘 사용하는 것이다.아마도 '새로운' 사용자들은 그들의 새로운 기사가 기사 공간이 아닌 드래프트에 자동으로 나타나게 할 수 있을까?스튜어트예이츠 (대화) 2015년 9월 13일 20:17 (UTC)[응답]

@Stuartyeates: 패트롤러 사용자 권리는 어떤 부정적인 방법으로도 새로운 사람들에게 영향을 주지 않을 것이다.새로운 편집자들은 여전히 그들이 지금 할 수 있는 그대로의 기사를 만들 수 있지만, 새로운 페이지들은 더 균일한 능력 수준의 큐레이션 팀에 의해 순찰될 것이다.이것은 새로운 편집자들이 생각지도 못한 빠른 삭제 지명에 덜 물릴 뿐만 아니라, 패트롤러가 나머지 순찰 체크리스트에 더 익숙해질 것이라는 것을 의미한다.그 결과, 새 편집자는 그들의 기여에 대해 유능하고 시기적절하며 건설적인 피드백을 받을 가능성이 더 높아지게 된다.VQuakr (대화) 04:50, 2015년 9월 16일 (UTC)[응답]

Stuartyeates는 정확히 다음 주에 제안서를 볼 수 있을 것으로 기대한다: 새로운 사용자와 새로운 사용자가 자동으로 드래프트로 향한다. DGG (토크 ) 2015년 9월 16일 05:15 (UTC)[응답]

댓글 요청 : 봇 깃발과 관료

관리자에게 "모듈:" 네임스페이스의 페이지 이동 제한 제안

자동 보관

1. 기본적으로 대화 페이지에 보관 봇을 추가하면 안 되는가?여러 토크 페이지에 고대의 글이 많이 올라오는 것을 보면 정말 짜증난다.
2. 기본적으로 토크 헤더도 포함하지 않는 이유는? -- Pankaj Jain Capankajsmilyo (토크 · 기여 · 카운트) 05:37, 2015년 9월 19일 (UTC)[응답]

이전 IP 대화 페이지 삭제 중

WP에서 의견을 제시하십시오.BOTREQ#Bot to Undelete 40만 개의 오래된 IP talk 페이지 - 오래된 것으로 삭제된 약 40만 개의 IP talk 페이지를 Undelete하기 위해 Bott를 사용하자는 제안. 103.6.159.88 (talk) 05:59, 2015년 9월 19일 (UTC)[응답]

아흐메드 모하메드(학생)

아흐메드는 이미 세계에서 가장 큰 인터넷 거물들의 본사로 초대되었다.위키미디아가 비슷한 지지와 격려의 제스처를 취해야 한다고 생각하고 있었다.그래서 나는 아흐메드를 위한 위키미디어 회의 초대나 위키마니아 초청에 관해 말할 수 있는 가장 좋은 사람은 누구일까?나는 이메일보다는 위키피디아 사용자 페이지로 연결되는 링크를 선호한다.감사합니다.클라이네비제스 (대화) 2015년 9월 20일 (UTC) 10시 45분[응답]

명심해, 아흐메드는 그렇게 예외적인 일을 하지 않았어.6백만 명이 넘는 사람들이 사는 메트로 지역 출신이야그의 또래의 대도시에는 아마도 수백 명의 학생들이 매년 비슷한 지적 재능을 보이고 있을 것이다. 그들 중 대부분은 취미의 결과를 학교에 가져오지 않거나, 대부분의 학교처럼, 그의 학교가 저지르는 실수를 하지 않을 정도로 똑똑하다.달러 투 도넛스는 만약 그의 공학 선생님이 "만약 그가 지금쯤 학교를 바꾸었다면, 그는 아마도 그것을 가지고 있었을 것이다"라고 그의 학생들에게 말했다. "디지털 시계를 만들어서 내일 수업에 가져온다.어떻게 해야 할지 알 수 없다면, 한 시간을 들여서 당신이 가지고 있는 것을 가져오라." 그의 학생들 중 적어도 몇 명은 완성된 시계를 가져올 것이다.davidwr/(토크)/(기적) 20:23, 2015년 9월 20일 (UTC)[응답하라]

WP를 제거하는 Bot:이스트레그(인종주의자?)는 "이스라엘"이라는 단어 아래 "이스라엘 유대인"에게 위키링크를 한다.

아래 토론은 위키백과에서 이동됨:Bot requests — Cliftonian (talk) 18:45, 2015년 9월 15일 (UTC)[응답]

나는 위키피디아에서, 항상, 특히 (유대인) 이스라엘 사람들에 대한 기사의 첫 문장에서 이것을 본다.이 기사는 "X인(태생 Y 데이트)은 이스라엘인"이라고 시작할 것이다."—"이스라엘"이라는 단어가 이스라엘 유대인 기사와 연결된다.이러한 다소 보편적인 관행은 적어도 WP는 다음과 같다.이스트레그는 내 생각에 인종 차별주의자와 연관되어 있다.마치 미국 백인들이 "X person (Y born date)은 미국인이기 때문에..."라는 글을 연 것 같다. "American이라는 단어 아래 White American과 연결된다.나는 지난 한 달여 동안 우연히 이 사용법들을 접하게 되면서 이 사용법들 중 적어도 몇 십 개는 손으로 제거했지만, 그 수가 너무 많은 것 같기 때문에(그리고 어떤 의제를 가진 사람들은 가끔 이 링크를 다시 추가하는 것 같기 때문에, 나는 봇이 위키코드를 바꾸는 것이 바람직할 것이라고 생각한다.[[Israeli Jews Israeli]]바로는Israeli연결되지 않은.나는 이것들에 대한 경험이 없어서 여기에 나열할 거야.어떤 도움이라도 감사할 것이다.건배, — Cliftonian (대화) 09:49, 2015년 9월 14일 (UTC)[응답]

좀 더 폭넓은 논의가 필요하다.이 과제에 대한 합의를 증명할 수 있는가?왜냐하면 이것은 논쟁거리가 될 가능성이 높은 이슈에 관한 몇몇 기사에 영향을 미칠 것이기 때문이다.헤드폭탄 {토크 / 기여 / 물리학 / 책} 13:18, 2015년 9월 14일 (UTC)[응답]

빨리 대답해줘서 고마워. 헤드밤.나는 아래 RFC를 개설했다.잘 지내길 바라며, — 클리프토니안 (대화) 08:48, 2015년 9월 15일 (UTC)[응답]

의견요청

위와 같은 헤드밤의 요청으로 나는 더 많은 견해를 얻기 위해 이것을 열 것이다.나는 또한 WP에 글을 올렸다:이스라엘은 거기서 의견을 얻으려고 한다.나는 이미 나의 근거를 위에 게시했다.— 클리프토니안 (대화) 08:47, 2015년 9월 15일 (UTC)[응답]

• (이스라엘 사람들이 리디렉션하는) 이스라엘인을 가리키도록 링크를 변경하십시오.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디가 편집한 2015년 9월 15일 09:00 (UTC)[응답]

• 그것도 만족할 만한 해결책이 될 것이다.고마워 앤디.— 클리프토니아어 (대화) 09:22, 2015년 9월 15일 (UTC)[응답]

• 내가 이스라엘 아랍인들을 위해 확인한 모든 기사의 링크들은 눈에 띄게 이스라엘 아랍 또는 아랍 이스라엘과 연결되어 있다.이스라엘 시민을 위한 모든 연결고리가 이스라엘로 이어지거나 특정 국가의 기사로 이어져야 하며 링크 대상이 뚜렷하게 가시화되어야 한다고 생각한다."워코사인" 13:09, 2015년 9월 15일 (UTC)[응답]

• @WarKosign: 분명히 말하지만, 여기서 "특정 국가의 기사"라고 말할 때, 이 사건이 요구하는 대로 이스라엘의 유대인/아랍인/이스라엘의 드루즈 시민/등급을 말하는 것이 맞다고 생각하는가?아니면 모든 경우에 대한 이스라엘 기사를 말하는가?아랍 이스라엘인의 전기 기사를 어떻게 시작할 것인가 하는 것은 이것보다 훨씬 더 복잡하고 별도의 논의를 위해 남겨져야 한다고 나는 생각한다.— 클리프토니아어 (대화) 14:07, 2015년 9월 15일 (UTC)[응답]

@Cliftonian: 그래, 나는 국가가 아닌 민족성을 의미하는 Nation이라는 단어를 사용했다.아랍인과 유대인 이스라엘인을 같은 스타일로 묘사해야 한다고 생각하므로 별도의 논의가 아니다.유대인 이스라엘인이 다수지만 다른 민족을 가진 이스라엘 국민이 예외라고 해서 디폴트 사례로 간주해서는 안 된다."워코사인" 15:10, 2015년 9월 15일 (UTC)[응답]

나는 아프리카계 미국인 배우들에 대한 몇몇 기사를 그 나라에서 소수민족인 또 다른 민족적 사례로 보았다.내가 확인한 기사들은 어떤 부분에서는 관련이 없는 한 기사에서 그들의 민족성을 언급하지 않고, 위키링크가 없는 미국인으로 묘사하고 있다.민족성에 대한 유일한 언급은 범주별이다."워코사인" 15:29, 2015년 9월 15일 (UTC)[응답]

다른 곳에서 토론하십시오(WP:VPR).이것은 봇 운영자가 이미 논의되었거나 논란의 여지가 없는 요청이 있는 사람들과 작업할 수 있는 페이지라고 되어 있다.여기 RfC가 있으면 그 유용한 소음이 사라진다.레곡™ (대화) 15:55, 2015년 9월 15일 (UTC)[응답]

위의 토론이 위키백과에서 이동됨:Bot requests — Cliftonian (talk) 18:45, 2015년 9월 15일 (UTC)[응답]

@WarKosign: 대화의 실이 감동되어 살짝 헤어지는 것을 양해해 주십시요.이상적으로 모든 배경을 가진 이스라엘 사람들이 위키링크 없이 단순히 이스라엘인이라고 소개될 것이라는 당신의 의견에 동의하지만, 봇에 관한 한, 나는 봇의 저열한 과일에 집중하는 것이 더 낫다고 생각한다.[[Israeli Jews Israeli]]먼저 문제 삼다그 나머지는 또 다른 토론이고, 훨씬 더 길고, 훨씬 더 복잡한 토론이다.— 클리프토니아어 (대화) 2015년 9월 15일 (UTC)[응답]

@Jethro B: 대부분의 변경을 한 것 같은데, 그는 실제로 AutoWikiBrowser를 사용했다.https://en.wikipedia.org/w/index.php?title=Special:Contributions/Jethro_B&offset=20121031035859Naraht (토크) 21:36, 2015년 9월 15일 (UTC)[응답]을 참조하십시오.

나랏, 고마워— 클리프토니안 (대화) 08:05, 2015년 9월 16일 (UTC)[응답]

• 나는 이 링크들이 받아들일 수 없다는 것에 동의한다. 기껏해야 WP:이스트레그 링크.클리포니안의 연결고리를 완전히 제거하자는 제안과 이스라엘인과의 연결고리로 대체하자는 앤디의 제안은 둘 다 내게는 괜찮다.—Granger (대화 · 기여) 17:07, 2015년 9월 16일 (UTC)[응답]

• 사소한 점이지만 이스라엘 유대인들은 인종이 아니다.그러므로 그것은 인종차별이 아니다.그 주장된 행동은 아마도 차별이라고 특징지을 수 있을 것이다.칭찬(말)

• 나에게 이스라엘은 시민권을 언급하기 때문에 항상 이스라엘과 연결되어야 한다.이스라엘 유대인과의 연계는 항상 이스라엘 유대인이 해야 한다. filceolaire (대화) 22:37, 2015년 9월 22일 (UTC)[응답]

• 위키피디아에 따라 개별 기사의 편집자들이 내린 편집 결정이다.스타일/생물 및 위키백과 설명서:살아있는 사람들의 전기.이에 대한 공감대를 형성하려면 그 두 가지 정책과 수많은 사례를 면밀히 읽어내는 것이 바탕이 될 필요가 있다.스튜어트예이츠 (대화) 03:29, 2016년 9월 12일 (UTC)[응답]

중국어 버전의 해결책과 위키백과에서의 열전

문제 & 이유

1. 정치와 문화적 배경이 서로 다른 백 년 가까이 되는 지금, 홍콩(1842년), 중화민국(1911년), 중화인민공화국(1949년), 마카오, 말레이시아, 싱가포르 등 여러 곳의 중국어가 ...등등, 다른 어휘를 발달시켰고, 심지어 다른 문법, 글쓰기, 표현, 획수까지 발달했다...
2. 현재 소위 "전통/간편화된 중국어 텍스트 간 언어 인코딩의 단순한 전환은 많은 문제를 처리할 수 없고, 더 나쁜 것은 내용에 대한 열띤 논쟁과 공격, 방어적인 변화를 야기했다.
3. 아무 차이도 없는 척할 필요 없어.변화를 멈출 필요가 없다.중국어의 신세대 통일을 강요할 필요는 없다.
4. 지구상의 모든 인간의 문화를 위하여, 모든 나라의 문화를 위하여,
5. 논쟁을 줄이고 따라서 서로 다른 장소/국가의 사람들이 자신의 장소/국가의 미래 세대를 위해 지식과 문화를 전달하기 위해 시간과 에너지를 위키백과 컨텐츠에 사용할 수 있도록 한다.

해결책

위키피디아의 원래 개념은 전 세계 사람들에게 존경을 받아왔다.위키피디아는 다양한 중국어 버전을 독립된 세트로 분할하여 콘텐츠가 독립적으로 만들어지고 각 세트가 서비스하는 국가 또는 장소의 사람들을 위한 서비스를 가능한 한 빨리 제공할 수 있도록 배려하십시오.평화가 함께 하기를.모든 나라와 모든 문화가 대대로 번영하기를. --Xaaan5 (대화) 23:46, 2015년 9월 14일 (UTC)[응답]

• 영어 위키백과 관련?--Antigng (대화) 00:13, 2015년 9월 15일 (UTC)[응답]
• Antigng와 동의하면, 이것은 여기 말고 기존의 중국어 위키백과나 메타위키에서 해결되어야 할 이슈로 들린다. 데이비드wr/(토크)/(contracties) 03:02, 2015년 9월 15일 (UTC)[응답]

• 현지 언어가 광둥어인 만다린 이름을 붙이려다 다른 사람들이 없애고 싶어 하는 홍콩 기사에 문제가 생겼다.하지만 나는 이것을 여기서 프로젝트 수준의 문제로 생각했을 것이다.Graeme Bartlett (대화) 11:57, 2015년 9월 17일 (UTC)[응답]

• OP가 무엇을 요구하는지 이해한다면 이미 끝난 것이나 부분적으로 끝난 것 같다."중국어" 위키백과 외에도 이미 광동어, 하카, 민난, 그리고 다른 WP들이 있다.메타 참조:언어 그룹별 위키백과 목록, Sinicative 섹션.
  Graeme Bartlett가 언급하는 홍콩 기사처럼 영어 위키피디아에 관한 한, 만약 편집 전쟁이 진행된다면 그것은 일반적인 과정으로 해결되어야 한다.스탠닝 (대화) 2015년 9월 17일 14시 12분 (UTC)[응답]
• 사아안5: 이것은 전에 제기된 적이 있다.수년 전, 여기 영어 위키백과에서 논란이 되는 기사들을 나누자는 제안이 있었다. 그래서 우리는 하나의 NPOV 기사 대신에 다양한 관점에서 기사를 가지고 있다.미국 대 영어 철자를 둘러싼 편집 전쟁이 있었다.모든 경우에 있어서 우리의 결정은 머리를 맞대고 전쟁 중인 편집자들에게 NPOV 기사를 만들기 위해 함께 일하라고 말하는 것이었고 NPOV는 이제 우리의 다섯 가지 기둥 중 하나로 합사되었다.이것은 지금까지 효과가 있었고 나는 그것이 바뀔지 매우 의심스럽다.반대로 언어는 같지만 미래에는 도구가 자동번역용으로 개발되면서 서로 다른 대본이 통합되는 경우를 상상할 수 있다.그냥 내 의견이야.filceolaire (대화) 22:48, 2015년 9월 22일 (UTC)[응답]

RfC: 기존 Google 및 Internet Archive 링크를 HTTPS로 변환해야 하는가?

이 RfC는 프록시 서버를 사용하는 위치들이 보안 링크를 결국 프록시화하지만 인증서를 가지지 않기 때문에 보안 링크를 해제한다는 사실을 완전히 놓쳤다.나쁜 생각이야.월터 괴를리츠 (대화) 04:13, 2015년 10월 17일 (UTC)[응답]

• RfC의 장점을 의심하는 것은 아니지만, 제안을 한 동일한 사용자도 RfC를 "거의 동물에 가까운" 것으로 폐쇄한 것은 최적보다 못하다. 이것이 한 달 전에 제기되지 않은 것은 약간 놀랍다. 하지만, 나는 이것이 세상의 끝이라고 생각하지 않아, 그러니깐 라비야.안부. --64.85.217.45 (대화) 00:54, 2015년 10월 27일 (UTC)[응답]

(지금까지 알려진 것은 몇 주 전 무권 편집자에 의해 은둔되어 있어서, 매우 놀라운 논평이다.)Rgrds. --64.85.217.45 (대화) 07:16, 2015년 12월 7일 (UTC)[응답]

만약 이러한 변화가 억압적인 정권하에서 고통 받는 독자들에게 삶을 훨씬 더 어렵게 만들 것이고 압제를 피하기 위해 대리 서버를 사용할 필요가 있다는 것이 사실이라면, 이것은 그러한 변화를 만들지 않을 충분한 이유일 것이다 - 아무리 많은 서양인들이 그러한 변화에 대해 '투표'를 한다.BushelCandle (대화) 16:01, 2016년 2월 28일 (UTC)[응답]

@BushelCandle:장기적으로 보면, 억압적인 국가들의 위키백과 독자들조차도 이 결정의 혜택을 볼 것이다.왜냐하면 HTTPS를 감안할 때 억압적인 정권은 구글 뉴스나 인터넷 아카이브와 같은 웹사이트를 검열하는 것에 대해 전부 또는 전무한 결정에 직면해 있기 때문이다(예를 들어, 러시아가 2015년 7월에 archive.org을 검열하는 것을 참조). --벤더슈 (대화) 00:35, 2016년 5월 12일 (UTC)[응답]

나는 단지 기술적인 의견을 추가하고 싶다.http 버전을 검색한 다음 https 버전을 검색하여 동일한 버전인지 비교한 다음 (자동으로) URL 프로토콜을 변경할 수 있다.그리고 만약 페이지가 어떤 식으로든 로드된다면, 그 페이지에 있는 동안 그 페이지의 합계를 확인하고 참조에 포함할 기회가 있다.https 링크에 접속할 수 없는 사람은 누구나 프로토콜을 수동으로 변경할 수 있다.Bytsock (대화) 23:16, 2016년 5월 19일 (UTC)[응답]

휴면 상태이거나 경험이 없는 기존 계정에 대해 VisualEditor 사용

관련 Infobox 템플릿에 "Social Media" 또는 "Verified Social Media" 매개 변수 추가 제안

이러한 언급이 독자들에게 유용할 수 있다고 생각하는 나의 주된 이유는 허위 계정의 확산이다.이 추가는 독자들이 공식적이고 검증된 계정을 더 잘 찾을 수 있게 해줄 것이다.

이러한 파라미터의 빈 템플릿은 다음 라인에 무엇인가 표시될 수 있다.

소셜 미디어 = <!-- 주목받는 인물과 조직과 관련된 가짜 계정이 만연하고 있기 때문에 모든 출품작을 검증해야 한다.형식([https://플랫폼의 참조명 예시])을 사용하거나, 설비가 가능한 경우 -->를 사용하는 것을 선호한다.

편집자가 추가 템플리트 개발에 동의할 경우, {{facebook /예}}{{twitter /예}}}{youtube /channel/예}} 등 컨텐츠 사용에 대한 정보를 추가할 수도 있다.

나중에 플랫폼 이름을 플랫폼 로고/기호로 대체하기로 결정한 경우 이러한 이후 형식을 사용할 수 있다.

그레그케이 07:57, 2015년 9월 20일 (UTC)[응답]

위키다타에서 이러한 가치를 얻어 추가해야 다른 위키들이 이를 통해 이익을 얻을 수 있을 것이다.거기에는 이미 약간의 자료가 있다.Sjoerd de Bruin (대화) 09:27, 2015년 9월 20일 (UTC)[응답하라]

나는 여기서 그 추리를 이해할 수 있을지 모르겠다.하지만 이 제안이 위키백과 계정을 얻기 위해 소셜 미디어 계정을 필요로 한다면, 나는 동의한다!만약 사람들이 wp 계정을 얻기 어렵게 만든다면, 나는 그것에 반대한다. --Thnidu (대화) 02:32, 2015년 9월 24일 (UTC)[응답]

백과사전이 왜 이런 정보를 원하는지는 확실하지 않다.또한 기사 본문에 있는 내용을 요약하기 위해 Info 박스를 [사용해야 한다]로 한다.GenQuest 12:06, 2015년 9월 24일 (UTC)[응답]

소셜 미디어 소스가 WP인지 또는 어떤 것인지 확실하지 않음:RS. Wtmitchell (대화) (이전 보라카이 법안) 12:25, 2015년 9월 24일 (UTC)[응답하라]

WP:ELMIN공식 바즈 (대화) 13:00, 2015년 9월 24일 (UTC)[응답]

비디오 제안서 입력 요청

친애하는 위키미디어 동료들:

나는 (특히 GLAM과 교육 프로그램에서) 새로운 기여자들에게 위키미디아를 소개하고, 그들이 건설적인 방법으로 지역사회에 참여하도록 동기를 부여하기 위해 만들어진 비디오 시리즈에 대한 제안을 개발하고 있다.조언해 주면 고맙겠다.이 비디오는 다국어로 번역하기 위한 것이다; 이미 스페인어, 독일어, 그리스어 번역에 자원 봉사자들이 있다.

제안서의 주요 초안 페이지가 여기에 있다.

제안 토크 페이지는 여기 있다; 그것은 동영상이 다룰 수 있는 특정 주제에 대한 개요를 포함한다.

프로젝트의 범위와 예산은 아직 검토 중이라는 점에 유의하십시오.이 시점에서 동영상이 다루어야 할 주제와 어떻게 다루어야 하는지에 대한 의견을 입력하는 것이 특히 도움이 될 것이다.이 정보는 프로젝트 범위와 예산이 조정됨에 따라 도움이 될 것이다.

질문과 의견을 대화 페이지에 추가하십시오.

만약 당신이 당신의 승인을 얻어 프로젝트를 지원하고 싶다면, 여기서 그렇게 하십시오.

만약 당신이 영상 번역에 자원하고 싶다면, 나에게 이메일을 보내거나 토크 페이지에 댓글을 달아줘.

감사하고 안부 전합니다

--Pine^✉ 22:13, 2015년 9월 24일 (UTC)[응답]

WhatLinks에서 모든 수준의 리디렉션 허용여기

특수:WhatLinks여기서는 모든 리디렉션 수준에서 중지를 허용해야 하며, 기본값은 WhatLinks를 표시하는 것이다.이 페이지(의미됨)는 최대 이중 리디렉션만 수행함.제프리T2000 (토크) 01:02, 2015년 9월 17일 (UTC)[응답]

나는 이런 제안을 볼 때마다 제안자에게 왜 그들의 제안이 좋은 것인지 설명해 달라고 부탁하지 않을 수 없다.이중 리디렉션(트리플 또는 쿼드러플은 말할 것도 없고)은 나쁜 것이며, 대부분의 경우 두 번째 리디렉션을 우회하기 위해 삭제되거나 다시 대상으로 지정된다.난 네가 여기서 제안하는 게 뭔지 전혀 모르겠어.비블브록스 (대화) 04:32, 2015년 9월 18일 (UTC)[응답]

왓링크스에게는 더욱 중요한 일이라고 생각한다.이름, 첫 번째 편집, 마지막 편집, 편집 횟수, 바이트 크기, 트래픽 등을 기준으로 항목을 정렬하려면 여기를 누르십시오.카테고리나 임의 목록과 동일함. --NaBUru38 (토크) 22:54, 2015년 9월 24일 (UTC)[응답]

카톨릭 교회를 언급하는 데 있어서 일관된 문체 사용법

위키피디아가 가톨릭 교회를 어떻게 지칭하는지에 대한 세계적인 변화를 만들어 달라.

현재, 사회자들은 "로마 가톨릭 교회"라는 용어를 사용하고 있는데, 이것은 가톨릭 신자들이 압도적으로 자신을 지칭하는 방식이 아니다.

가톨릭 교회는 24개의 의식으로 구성되어 있기 때문에, 전체를 "로마 가톨릭 교회"라고 지칭하는 것은 로마 의례 중 단 하나만이 전적으로 부적절하고 다른 의례에 모욕적이다.그렇다, 교회는 로마에 있는 바티칸에 '본부를 두고 있다'고 하지만 그렇다고 해서 그것을 그렇게 분류하는 것은 정당화되지 않는다.아무도 LDS교회를 "후일성인의 소금 호수 도시교회"라고 지칭하지 않는다.

"로마"는 기껏해야 시대에 뒤떨어진 고어다.최악의 경우, 그것은 많은 (예: 성공회) 중에서 교회를 하나의 가톨릭 교회로 자격을 부여하기 위한 미묘한 정치적 꼬리표다.교회를 '로마'로 표기해야 한다는 주장은 위키백과 내에 깊은 반 가톨릭, 개신교적 편견이 있음을 시사하는 듯하다.수세기 동안 반 가톨릭 개신교 신자들은 가톨릭 교회를 단지 "로마"로 폄하할 것을 주장해 왔다.'로마교회'나 '로마니즘'과 같은 용어는 교회를 더럽히고 보편적이기보다는 이국적이고 특이하다고 캐스팅하는 데 사용되었다.사도 신조와 니케네 신조는 많은 사람들이 "하나, 거룩, 가톨릭, 사도 교회"를 믿는다고 공언했기 때문에, 많은 개신교인들은 가톨릭 교회를 단순히 로마 교회라고 지칭할 것을 주장했다.교회와 무관한 정치적 왕국이었던 신성로마제국과의 역사적 혼란도 있다.

교회의 "공식적인" 명칭이 없기 때문에(그것은 단순히 교회다!) 우리는 공통의 용법에 의존해야 한다.역사적으로나 전 세계적으로 가톨릭 신자들이 가장 많이 사용하는 것은 교회를 가톨릭 교회라고 부르는 것이다.위키피디아의 용어를 업데이트하여 사실 및 일반적인 사용법뿐만 아니라 자체 식별된 합의를 반영하십시오.

진심으로

회질의

나는 로마의 의식이 아니라 로마 교황을 인정하는 것을 가리키는 '로마인'을 항상 이해했다.현재도 있고 항상 사용 중인 다른 의식들이 있다.'카톨릭 교회'의 문제는 다른 많은 기독교 교파들이 스스로를 가톨릭 신자로 여긴다는 것이다. DGG (토크) 04:20, 2015년 9월 24일 (UTC)[응답]

Mnewous, Attack attack

• 구 가톨릭 교회, 앵글로-카톨릭주의, 그리고 기독교의 많은 다른 "카톨릭" 향기를 간과하는 당신의 편견
• 내가 본 모든 버전에서 교황 레오 3세가 800년에 로마의 샤를마뉴에 왕관을 씌우는 것으로 시작하는 신성 로마 제국에 관한 당신의 역사적 오류는 얼마나 더 많은 신성 로마를 얻을 수 있었는가? - 그렇다면?

중립을 요구하는 위키피디아의 기둥을 버리고 RC의 견해에 부합되게 행동하기를 원하십니까?그럼 모르몬스를 성인으로 지칭해 그들의 관용에 부합하도록 할까?아니면 어떤 신앙에 대한 모든 언급을 "교회"로 바꾸거나?

문맥이 모든 것이다.RC교회를 '교회'라고 할 수도 있겠지만, 개신교 신자와 대화하고 그 맥락이 잘못 해석될 수 있다면 그렇게 하겠는가?옛 가톨릭 신자와 대화하고 있다면 그것을 가톨릭 교회라고 할 것인가?여기 위키피디아에서는, 모든 사람들에게 말하고 있다.아무것도 아닌 것으로 가정하고, 구체적으로 말해라.안녕, 바즈 (대화) 2015년 9월 24일 (UTC) 14:26 [응답]

나는 일반적으로 '로마 가톨릭 교회'에 대한 언급이 가장 큰 가톨릭 교회에 대한 언급이라고 가정하고 싶다. 가장 좁은 의미에서 '마론 교회'와 같은 다른 특정한 가톨릭 교회를 포함하는지 여부는 상황에 따라 달라진다.유일하게 올바른 용법이라고 교회의 고유 용법을 고집하는 것은 지나치게 편향된 것처럼 보일 것이다. (하지만 그렇다면 나는 앵글로 카톨릭 신자라서 역시 편향된 것이다.)알렉스 티플링 (대화) 2015년 9월 24일 (UTC) 14시 31분 (답변)

친애하는 알렉스 티플링에게, 나는 원래의 포스터가 "우리가 중립성의 기둥을 버리면 좋겠다"는 것에 대해 심각하게 의심한다.'로마 가톨릭 교회' 이름을 '카톨릭 교회'로 개명하는 것이 중립적이지 않을 것으로 생각되면 정중하게 설명해 달라. -나부루38 (대화) 23:06, 2015년 9월 24일 (UTC)[응답]

NaBUru38, 네가 불평하는 코멘트는 내 것이지 알렉스의 코멘트가 아니다.그것을 전부 다시 읽고, 그리고 Mnewhous'의 편집 내역과 그의 토크 페이지의 주의사항의 맥락에서, 나는 그 메시지에 꽤 만족한다.바즈 (토크) 08:38, 2015년 9월 25일 (UTC)[응답]

기사 제목은 중립적으로 하기 정말 어려운 것일 수 있는데, 제목 자체에 논란을 설명할 가능성이 없기 때문이다.가톨릭 교회가 여러분이 원하는 대로 교회의 주요 기사임을 알게 될 것이고, 로마 가톨릭(용어)은 이름과 관련된 문제들을 설명한다.나(로미 비숍과 함께하는 가톨릭 교회는 아님)는 모호함이 없는 상태에서 '카톨릭'을 사용하여 로마 비숍과 함께 있는 교회를 지칭할 수 있다는 데 동의한다.그러나 애매모호함이 존재하는 경우도 있고, 거기에 '로마'라는 말 자체가 경멸적인 것은 아니다.('로마 교회' '로마 교회' '로마니즘' 모두 그렇긴 하지만)실제로, PCPCU는 "로맨"이라는 단어를 사용하지 않을 경우 위반/충돌을 유발할 수 있다.

마지막으로, "로마 카톨릭"과 "라틴 굿 카톨릭"은 완전히 다른 용어라는 점에 주목하라.다른 의례의 '로마 가톨릭'도 있고, '로마 가톨릭'이 아닌 (논의할 만한) 라틴 레티 카톨릭도 있다.

복잡하고 어렵지만, 그 주제에 대한 위키피디아의 기사들은 상당히 중립적인 역할을 한다고 생각한다.가차없이 (대화) 08:31, 2015년 9월 25일 (UTC)[응답]

모든 Infobox에 대해 "px"를 "upright="/"size percent"로 변경하시겠습니까?

이제 이미지 디스플레이를 위한 최신 "400px" 옵션을 포함한 크기 옵션을 갖게 되었으므로 WP별로 사람들의 이미지 선호도를 존중해야 한다.아이업. 어쩐지 인포박스에서 'px'를 사용하는 모델은 처음에 큰(또는 작은) 이미지를 보고 싶어하는 다른 사람들에게 불리하다.설정을 px에서 이미지 크기 백분율/위로 변경해야 할 것 같다.동의하십니까? --George Ho (대화) 06:46, 2015년 9월 23일 (UTC)[응답]

@George Ho: 앞으로 몇 개월/몇 년 안에 영상에 대한 "올바른" 옵션을 폐기하기로 합의했으니, 나는 그것에 반대할 것을 추천하고 싶다.Jdforrester (WMF) (토크) 08:41, 2015년 9월 23일 (UTC)[응답]

만약 그들이 "적절한" 옵션을 폐지하기로 결정한다면, 이것이 WP에 어떤 영향을 미칠 것인가?아이업(IUP)? 다시 모든 사용자를 위해 'px'를 사용하는가? --George Ho (토크) 08:45, 2015년 9월 23일 (UTC)[응답]

@George Ho: 나도 그 포부는 픽셀 지정도 무효화하고, 대신 의미론적 이미지 유형으로 옮겨가는 것이라고 믿지만, 그것은 아직 합의되지 않았다(그리고 내가 직접 작업하는 것은 아니다, 미안하다).내가 링크한 RfC에 더 자세한 내용이 있다.Jdforrester (WMF) (토크) 08:46, 2015년 9월 23일 (UTC)[응답]

나는 "px"를 폐기하는 것이 효과가 있다고 생각하지 않는다.그것은 깃발과 체크 표시와 같은 매우 작은 아이콘에 영향을 미칠 것이다.그 링크를 읽으면서, 그들이 무미건조한 이미지들을 토론하고 있었는지 궁금하다. frameless ) --George Ho (대화) 08:57, 2015년 9월 23일 (UTC)[응답]

@George Ho: 미디어의 전횡이 어떻게 작용하는지를 완전히 바꾸자는 것은 꽤 광범위한 제안이다.네 말대로 좀 진지한 고민이 필요해Jdforrester (WMF) (토크) 17:33, 2015년 9월 23일 (UTC)[응답]

• 미국
• 아일랜드
• 독일.
• 스위스
• 네팔

템플릿:깃발은 표준 높이를 선호한다는 이유만으로 깃발 너비가 다르다.

고정화소 파라미터를 제거하면 더욱 심해진다. --NaBUru38 (대화) 22:59, 2015년 9월 24일 (UTC)[응답]

국기 아이콘들이 "표준 높이를 가지고 있다"는 것은 사실이 아니다.폭과 높이가 모두 고정되어 있으므로(기본값은 23x15px), 어떤 크기(23px 너비 또는 15px 높이)가 작은 아이콘을 사용한다.동일한 목록이 고정 너비로 다음과 같이 표시됨:

• 미국
• 아일랜드
• 독일.
• 스위스
• 네팔

그리고 높이가 고정된 이렇게:

• 미국
• 아일랜드
• 독일.
• 스위스
• 네팔

WT:WPFT 또는 템플릿 대화:그러나 플래그 템플릿의 기본 크기를 논하기에 플래그가 더 나을 것이다.SiBr₄ (대화) 12:06, 2015년 9월 25일 (UTC)[응답]

생성자가 {{db-c1} 템플릿을 제거할 수 있도록 허용

{{db-c1}{db-c1}는 생성자가 제거할 수 있어야 하는가?아래에서 논의하십시오. --189.25.240.76 (대화) 16:11, 2015년 9월 24일 (UTC)[응답]

왜? --Jayron32 12:02, 2015년 9월 25일 (UTC)[응답]

내가 만든 템플릿 범주에서 빠른 템플릿을 여러 번 제거했는데, 여기서 페이지는 실제로 추가되었지만 아직 표시되지 않았다(예: 이 템플릿). (템플릿이 설명서 하위 페이지를 통해 분류되는 경우, 작업 대기열이 따라잡아야 하기 때문에 며칠 또는 심지어 몇 주가 지나야 해당 범주에 나타나지 않을 수 있다.)

보다 빈번한 시나리오는 사용자가 카테고리를 만들고, 페이지 추가 방법을 잊어버리고(또는 방법을 모르며), 며칠 후에 C1 태그를 보고, 그 다음에야 카테고리에 페이지를 추가하는 것일 수 있다.SiBr₄ (대화) 2015년 9월 25일 12:51, (UTC)[응답]

그런 다음 범주 페이지를 다시 만드십시오.별일 없어. --Jayron32 16:07, 2015년 9월 25일 (UTC)[응답]

삭제 확인을 위한 OOUI

최근 이동양식이 OOUI로 전환되고 있다.업로드 마법사는 다음 주에 OOUI로 전환될 것이다.삭제 확인서(관리자용)도 OOUI로 전환해야 한다.제프리T2000 (토크) 2015년 9월 25일 (UTC) 15:58 [응답]

@제프리T2000: 나는 이것을 위해 T113758을 만들었다; 상기시켜줘서 고마워.Jdforrester (WMF) (토크) 16:49, 2015년 9월 25일 (UTC)[응답]

@Jdforrester(WMF): OOUI가 필요한 것은?어떤 형태라도?복수의 최종 상태를 가진 형태는?나는 특별하게 생각하고 있다:로그와 특별:특별하긴 하지만 기고금은 여기나 저기에 버튼이 있다.특수:MIMESearch도?누군가 특집 기사를 쓸어야 할지도 몰라특수 페이지.그 모두를 위한 과제는 없어 보였다. --Izno (대화) 17:24, 2015년 9월 25일 (UTC)[응답]

@Izno: 결국 모든 UI 인터페이스 구성요소를 OUI로 교체하고, 예: jQuery를 삭제하는 것이 계획.UI 및 기타 사용되지 않는 시스템.T100161은 MediaWiki를 모두 변환하기 위한 전체 티켓이다.T107037은 모든 특수 페이지를 위한 것이지만, 아직 로그, 기여도 또는 사실 대부분의 페이지를 위한 하위 티켓은 없다.Jdforrester (WMF) (토크) 11:35, 2015년 9월 26일 (UTC)[응답]

이 논의가 WP에 더 적합한가?VPT. 당신의 마술적 어투는 우리 머글에게는 별로 이해가 되지 않으며, 저쪽에 있는 더 많은 박식한 사람들로부터 더 나은 참여를 받을 가능성이 높다. --Jayron32 17:35, 2015년 9월 25일 (UTC)[응답]

@Jayron32: VPT는 코드 작성을 위한 참여를 요청하는 장소도 아니다. Git 패치의 형태로 입력하는 것은 환영할 일이다.:-) Jdforrester (WMF) (토크) 11:35, 2015년 9월 26일 (UTC)[응답]

알았어. 내가 물게.OOUI란 도대체 무엇인가?그리고 저 게릿(gerritt) 같은 것; 저것이 페렛(perret)과 같은 가족인가?GenQuest^{"Talk to Me"} 11:48, 2015년 9월 26일 (UTC)[응답]

OOUI. "게리트"는 게리트 리트벨트의 주어진 이름이다. --83.255.51.226 (대화) 08:17, 2015년 9월 29일 (UTC)[응답]

누가 "OOUI"의 이점이 무엇인지 설명해 주시겠습니까?위에 링크된 기사를 읽어보았지만, 어떻게 새로운 움직임 형태가 구식보다 더 '객체 지향적'인지 알 수 없다.젠크스24 (대화) 2015년 9월 29일 14:23 (UTC)[응답]

MediaWiki의 맥락에서 OOUI는 OOjs UI(데모)를 가리킨다.미디어위키와 위키피디아의 목표를 염두에 두고 작성한 현대식 위젯 툴킷이다.PHP와 Javascript 모두에서 생성될 수 있으며, 접근성, 일관성, 스킨십, 모바일 최적화 등이 가능하다.또한 기사 제목 입력 필드 등 미디어위키 특정 위젯을 자동 완성하여 쉽게 만들 수 있다.첫 번째 사용자는 Visual Editor였고 장기적인 계획은 이것이 어느 시점에 모든 제어장치에 사용될 것이라는 것이다.모든 개발자가 바퀴를 다시 발명할 필요는 없다는 생각이다.이미 OOUI에 있는 것을 사용하거나, 이 플랫폼이 제공하는 기반 위에 새로운 것을 구축하지만 처음부터 시작하는 것은 아니다.—DJ (대화 • 기여) 2015년 9월 29일 (UTC) 15:54[응답]

응답해줘서 고마워.그럼 기본적으로 개발자들이 일을 쉽게 할 수 있게 해주는 겁니까?그리고 또한 일이 일관되는 것이 좋을까?둘 다 좋은 것 같으니 괜찮아.하지만 이동 인터페이스로의 변경으로 인해 이곳에서의 일이 더욱 어려워졌다.나는 이제 그것에 대해 두 개의 버그를 제기해야 했고, 두 개의 버그를 모두 고친 후에도, 오래된 인터페이스는 여전히 나와 대부분의 다른 인터페이스들이 사용하기에 더 빠를 것이다.삭제 인터페이스를 변경해도 동일한 문제가 없을 것이라는 보장이 있는가?아니면 내가 이것이 백엔드에서 얼마나 유용한지를 과소평가하고 있는 것인가? 그리고 편집자들을 위한 이 사소한 문제들이 가치가 있는 것인가? (나는 당신, TheDJ가 이 질문에 반드시 답을 가지고 있지 않을 수도 있다는 것을 깨닫는다. 그들은 이 주제에 대한 지식을 가진 누구에게나 더 일반적이다.)젠크스24 (대화) 2015년 9월 29일 16:46 (UTC)[응답]

이렇게 표현해 봅시다.독특하고 수공예품, 약간 불완전하지만 아름답고 효율적이고 매우 비싼 가구들로 가득 찬 당신의 집을 사랑한다고 확신하지만, 이케아에게는 많은 이점이 있다.현재 많은 지역사회의 요청은 상황을 더 '상호작용', 'smarter', 'n00b proof' 등으로 만들어 달라는 것이다.그러나 일부 기본 원리를 바꾸지 않고서는 그러한 요청들 중 많은 수가 실제로 여러 대상 청중과 여러 대상 장치(그리고 Javascript 없이 브라우저를 파괴하지 않음)의 위키의 여러 영역에서 일관성 있게 구현하기 어렵고 비용이 많이 든다.OOjs UI는 커뮤니티와 개발자 모두에게 이러한 변경사항의 일부를 제공하기 위해 새로운 핸들을 만들 것이다.—DJ (대화 • 기여) 2015년 9월 29일 (UTC) 17:36[응답]

접두사 제안:TP: 템플릿의 경우:

우리는 모든 영어 위키백과 기사를 위한 타임라인을 만들었다.

받는 사람: WhatamIdoing, Mdennis(WMF), 짐보 웨일스, 무지개빛, 사용자:코렌

우리는 모든 위키백과 기사의 시각적, 스크롤 타임라인을 만드는 임무를 완수했다.물론 모든 기사가 자연에서 역사적인 것은 아니다.5백만 개의 영어 위키백과 기사 중에서, 우리의 추정치는 25만 개 정도가 적절한 시각적, 동시대의 프레젠테이션을 사용할 수 있을 것이다.그것은 많은 시간표다.우리는 그것이 역사, 인터넷, 그리고 오랜 시간 안에 일어날 수 있는 가장 흥미로운 일들 중 하나가 될 것이라고 믿는다.

우리는 다음과 같은 데모를 함께 했다.

http://wikitimelines.net/

위키백과 기사에 시간표를 넣을 수 있는 것과 관련하여.위키피디아 기사당 작은 스크립트 태그 하나와 작은 DIV 태그 하나일 것이다.

지금 하는 것은 놀랄 만큼 간단하다.

내가 원하는 것은 이것을 설치할 위키피디아 서버뿐이다.물론 위키피디아는 이 서버에 대한 완전한 인증 권한을 가지고 있을 것이다.이 일은 하루도 걸리지 않을 것이다.

OR:

나는 "아마존 웹 서비스" 서버에 대한 Wikipedia.org 인증 권한을 줄 수 있고 위키피디아는 나에게 사용 허가를 줄 것이다. (나는 심지어 돈을 지불할 것이다.)

그럼 1 Wikipedia.org 기사에서 테스트해보고 어떻게 되는지 보자.

우리는 이것이 얼마나 잘 되었는지 믿을 수 없다.우리는 위키피디아 기사의 타이밍을 멈출 수 없다. 그것은 매우 설득력 있고 재미있다.

나는 언급하는 것을 잊었다.이 모든게 새로운거야오늘날까지 아무도 이것을 본 적이 없다. (백과사전 기사로 타임라인을 만드는 것)우리는 이 기술을 단지 3명의 다른 사람들을 좋아한다는 것을 보여주었다.

고마워 제프 롤

Jrohl (대화) 21:54, 2015년 9월 13일 (UTC)[응답]

위키백과 데이터베이스의 덤프 또는 위키백과의 다른 "로컬 카피"를 사용하여 이 도구를 사용할 것을 고려해 보셨습니까?davidwr/(대화)/(공모) 23:16, 2015년 9월 13일 (UTC)[응답]

Davidwr에게

무슨 뜻인지 모르겠다: "위키백과 데이터베이스의 덩어리"

좀 더 구체적일 수는 없나요?

고마워요.

제프 롤

Jrohl (대화) 23:46, 2015년 9월 13일 (UTC)[응답]

위키백과 참조:데이터베이스 다운로드. davidwr/(대화)/(기여) 00:30, 2015년 9월 14일(UTC)[응답]

David = Davidwr,

응, 위키피디아가 어디서 얻는지 자료를 받고 싶어.위키피디아의 핵심과 동일한 랙 공간에서 실행할 수 있다면.그건 정말 빠를 거야.그리고 그것은 TCP/IP 자원을 전혀 사용하지 않고 매우 저렴할 것이다.내가 HTML로 데이터를 얻을 수 있을까? 나는 너희들이 위키 언어를 가져다가 즉시 기사 편집/저장 위에 HTML을 구문 분석할 수 있을지 모르겠다.내 위젯은 꽤 직진적이다.그것은 어떤 페이지에 있는지 알고 있다.위젯을 다음 위치에 배치하는 경우:

https://en.wikipedia.org/wiki/Queen_Victoria

그리고 그 위젯은 위키피디아에서 LAN에 있었고, 이것은 다음과 같이 번역될 수 있었다.

c:\pxidata\px\퀸_빅토리아\index.htm

또는 어떤 것이 있는지 그리고 그것을 사용자에게 제공한다.나에게 중요한 것은 기사의 현재 버전을 구문 분석하는 것이다.그래서 타임라인은 매번 기사와 정확히 일치할 것이다.내가 해야 할 일은 그 기사를 (로컬하게) 뽑고 그 글에서 단락을 끄집어내는 것이다.만약 내가 그 기사를 몇 밀리초 안에 끌어낼 수 있다면, 그것은 엄청나게 빠를 것이다.가장 느린 부분은 사용자 페이지의 위젯에 자바스크립트를 제공하는 것이다.그래서 내게 필요한 것은 큰 외진 파이프뿐이다.

그리고 나는 디스크 공간이 정말 많이 필요하지 않아.하루에 수백만 개의 타임라인을 처리하는 가장 큰 고민은 임시 파일을 삭제하고 디스크 공간을 운영 체제에 다시 푸는 것이다.시간 표시 막대에 대한 각 요청은 5개 정도의 임시 파일(SQL 출력)을 생성한다.그러나 그것들은 처리된 후 밀리초 이내에 삭제될 것이다.우리는 그들이 삭제되고 있는지 확인하기만 하면 된다.임시 파일 위치의 위치를 정할 수 있으니까, 이걸 감시할 수 있어.

디스크 쓰기(모든 테이블을 메모리 어레이로 변환) 없이 작업할 수 있도록 시스템을 쓸 수 있을지는 모르지만, 많은 작업이 필요할 것이다.그건 확실히 몇 주나 걸릴 거야.그래서 지금 이대로 놔두고 잘 올라오는지 살펴봐야 한다.

내 전문적 평가만 해도 네 경험은 다를 수 있어.

고마워 Jeff Rohl Jrohl (대화) 16:01, 2015년 9월 14일 (UTC)[응답]

David = Davidwr,

한가지 더요.물론 우리는 역사 위키백과 기사에 접속될 때마다 연대표가 로딩되는 것을 원하지 않는다.우리가 정말 좋아하는 것은 "collapseButton" 스판 태그인데, 대개 실질적인 기사들의 하단에 있다.그들은 매우 품위 있다.빅토리아 여왕 페이지에 "clappressButton"을 추가하고 거기에 내 SCRIP 태그와 DIV 태그를 넣으면 돼.따라서 "clapseButton"을 열면 위젯 JavaScript가 실행되어 시간 표시 막대 HTML과 JavaScript로 이 영역에 채워지게 된다.

그리고 만약 우리가 나의 빛나는 http://184.72.231.130/load1.js를 그 시점에서 발사할 수 있다면, 그 이후의 모든 것이 "걱정 없음"이 될 것이다.

물론, 이것의 문제는 위키피디아 페이지의 맨 아래에 있는 "clapseButton" 컨트롤이 있다는 것이다.내 말은 아래쪽에 있는 WAY down on the bottom.인용문 아래.그리고 그것은 "우리 팀"에게 좋지 않다.한편, 위키피디아의 타임라인은 매우 설득력이 있어서 모든 사람들이 짧은 시간 안에 그들이 어디에 있는지, 입소문을 타고 알 수 있을 것이다.

고마워 Jeff Rohl Jrohl (대화) 17:07, 2015년 9월 14일 (UTC)[응답]

나는 타임라인 오브 여자 농구에서 그것을 시도해 보았는데, 그것은 독특하게 잘 어울릴 것 같다.그것은 흉상이었다.내가 뭐 잘못했나?--S 필브릭(토크) 19:20, 2015년 9월 15일 (UTC)[응답하라]

아니, Philbrick 넌 잘못한 게 없어.이 글에서, 속도와 서술적 내용을 위해서, 우리는 어떤 위키백과 기사의 단락의 일부인 연대표에 데이터를 배치하고 있을 뿐이다.그것은 문단 태그 안에 있는 모든 내용이다.우리는 결국 "위키피디아 타임라인"을 위한 별도의 파서를 써야 할 것이다.한가지 문제는 위키백과 시간표 리스트에 대한 표준 형식이 없기 때문에 그것들을 구문 분석하는 것은 속임수라는 것이다.모든 위키백과 일정을 하나의 표준 형식으로 다시 쓰는 프로그램을 작성하는 시점까지 우리는 기꺼이 이것을 할 것이다.내용이 포함된 일부 단락 태그가 있는 https://en.wikipedia.org/wiki/Women%27s_basketball을 사용해 보십시오.

고마워요.

제프 로울 로흘(대화) 18:06, 2015년 9월 18일 (UTC)[응답]

나 또한 몇 주 전에 오늘 새로 생겼다는 주장에도 불구하고 이것을 본 기억이 난다.토론의 연결고리를 저장하지 않았고 현재로선 쉽게 찾을 수 없을 것 같다.찾은 위키백과:빌리지_펌프_(제안)/아카이브_126#I__like_to_put_a_timeline_a_wikipedia_page 나는 재단을 참여시키는 것에 대한 논의가 있었다는 것을 알고 있어 그 전선에서 무슨 일이 일어나고 있는지 듣고 싶다.--S 필브릭(Talk) 19:24, 2015년 9월 15일 (UTC)[응답]

그래, 필브릭은 별로 일어나지 않았어.로마는 하루아침에 이루어지지 않은 거에요.우리가 요청하는 것은 1대의 컴퓨터가 1개의 위키백과 기사에 1개의 타임라인을 표시하는 것이다.그리고 이게 어디로 가는지 볼 수 있을 겁니다.우리는 지금 6개월의 기간을 이 문제에 집중할 수 있는 곳에 할당하고 있다.2015년 10월 15일부터 2015년 3월 15일까지, 하루 8시간 또는 1000시간(총 근무 시간은 아니지만, 우리의 헌신적인 관심과 전체 척도)일 수 있다.나는 이런 자원이 그 이후에 이용될 것이라고 장담할 수 없다.나는 우리가 10개의 위키피디아 페이지에 타임라인을 배치할 수 있다면 타임라인이 훨씬 더 잘 이해될 것이라고 생각한다.그리고 나서 우리는 이 내용에 대해 토론하고 아마도 포함에 대한 합의된 투표를 할 수 있을 것이다.어떤 기사들은 다른 기사들보다 더 좋은 기한을 만들고 합의는 어떤 기사에도 포함되도록 지시할 것이다.

우리가 필요한 것은 "재단"이 우리가 지불하는 서버인지 아닌지에 상관없이 관리자 권한/인증을 가지고 있는 서버 1대뿐이다.그것은 그리 큰 첫걸음이 아니다.

우리는 또한 이것과 관련된 노력에 대한 보조금 신청서를 작성할 것이다. (또한 위에 언급된 1000시간의 범위 내에 있다.)이것에 대한 어떤 도움도 대단히 감사할 것이다.그래서 "비교적 역사"나 일반적으로 역사에 대한 보조금을 발행하는 어떤 단체에 대해 아는 사람이라면, 그것에 대해 우리에게 미리 알려준다.

고마워 Jeff Rohl Jrohl (대화) 18:42, 2015년 9월 18일 (UTC)[응답]

위키피디아에서 1개의 기사에 1개의 연대표를 붙이는 결정을 누가 내릴 것인가?

고마워 Jeff Rohl 64.39.94.189 (대화) 17:11, 2015년 9월 23일 (UTC)[응답]

좋아, 한 걸음 뒤로 돌아갑시다.

누가 내 타임라이닝 위젯 소프트웨어 백엔드로 위키백과 서버를 설치하고 구성할 수 있도록 허용하겠는가?

Jrohl (대화) 2015년 9월 27일 15:20 (UTC)[응답]

그것은… 그렇게 작동하지 않는다.타임라인을 렌더링할 컨텐츠를 검색하려면 사용자의 서버에 소프트웨어의 복사본을 설치하고 API를 사용하는 것이 좋다.만약 그것이 잘 작동한다면, 당신의 다음 단계는 아마도 당신의 소프트웨어를 MediaWiki 확장자로 다시 쓰고 (그리고 그것이 아직 그렇지 않다면 그것을 무료 오픈 소스로 만들고), 그리고 나서 그것이 위키피디아에 제대로 추가되도록 캠페인을 하는 것일 것이다.{{Nihiltres talk edits}}}{{Nihiltres talk edits}

탄쿄우 니힐트레스.내 부하들에게 이걸 조사하게 할 거야이런 일을 하는 건, 누군가 어떻게 돌아가는지 알려주기 전까지는 절대 모를 거야.Jrohl (대화) 14:52, 2015년 9월 30일 (UTC)[응답]

그리고 우리는 일단 시위 현장을 철거했다.Jroehl (대화) 15:52, 2015년 9월 30일 (UTC)[응답]

동작: AUSIC 확장

중재위원회는 현재 여러 차례의 감사소위 개혁을 검토하고 있으며 향후 소위원회 기능을 어떻게 보고 싶은지에 대한 커뮤니티의 의견을 요청하고 있다.이 때문에 현행 감사소위원회(AUSIC) 위원의 임기는 2015년 9월 30일(UTC) 23시 59분까지 연장된다.

지원: AGK, 더그 웰러, 고릴라워레, 게릴레로, LFaraone, 네이티브 외국인, 살비오 줄리아노, 스트라이듀울프, 윤슈이

반대:쿠르셀레스

중재위원회의 경우 --Guerillero Parlez Moi 02:10, 2015년 9월 5일 (UTC)[응답]

AUSIC의 미래와 이 문제에 대해 논의하십시오: 위키백과 대화:중재위원회/공지판#모션: AUSIC 확장

Commons 편집 페이지로 직접 연결

여기에 Commons에 있는 이미지에 대한 설명 페이지를 만들려고 하면 MediaWiki:Sharedupload-descreate, 기본적으로 "이 이미지는 Commons에 있으므로 이 페이지를 만들지 마십시오"라는 약간의 경고와 함께 Commons URL에 대한 링크가 제공된다.사용 중인 이 메시지의 예는 [8]을 참조하십시오.나는 WP에 갔다.URL 변경 방법을 묻는 HD. 지금 바로 파일:1987.jpg 오하이오주 남동부에 무장한 클랜스맨이 페이지를 편집하려고 하는데, 내가 미디어위키 페이지를 편집하여 설명 페이지 대신 편집 페이지인 [10]으로 가도록 하려던 중에 메시지에 있는 URL은 [9]이다.프라임헌터는 나에게 코드를 주었지만, 그 역시 그 생각에 반대했으므로 나는 먼저 여기서 채팅을 하지 않고 변화를 주지는 않을 것이다.

Proposal MediaWiki 페이지의 URL을 변경하여 사용자를 페이지로 보내는 대신 Commons 설명 페이지를 편집하도록 하십시오.나의 근거는 "페이지를 편집하는 일반적인 사람이 커먼스 페이지를 편집하려는 의도가 타당해 보이므로 설명 페이지를 통해 우회하는 대신 편집 페이지로 직접 전송하면 한 걸음도 절약할 수 있다"는 것이었다.PrimeHunter는 "[로컬 파일]에 Commons 범주, 섹션 편집 링크, History 탭, 업로더 링크 및 그 기여와 같은 여러 기능이 [Commons 설명 페이지]에 누락되어 있다.나는 크로스위키 편집 링크의 아이디어가 마음에 들지 않는다.나는 사용자들이 위키를 편집하기 전에 최소한 그것을 보아야 한다고 생각한다.나는 커먼즈나 다른 위키들이 우리에게 직접 편집 링크를 제공하는 것을 원하지 않을 것이다."

그래서 어느 쪽일까?내가 원하는 대로 링크를 변경해야 할까, 아니면 변경하지 않고 그대로 둘까, 아니면 다른 방식으로 변경해야 할까?나이튼드 (대화) 00:33, 2015년 10월 2일 (UTC)[응답]

이동할 때 대화 페이지 및/또는 하위 페이지 삭제

관리자가 페이지를 이동할 때 "관련된 대화 페이지 이동" 상자를 선택하면 새 제목 아래의 기존 대화 페이지를 삭제해야 한다.또한 '하위 페이지 이동' 상자를 체크하면 새 제목의 기존 하위 페이지를 삭제해야 하며, '관련 토크 페이지 이동' 상자를 체크하면 해당 토크 페이지의 하위 페이지도 삭제해야 한다.제프리T2000 (대화) 14:33, 2015년 10월 1일 (UTC)[응답]

그다지 [편집: "모든 것에 완전히 동의하지는 않는다"]는 아니지만, 만약 기사에 "이 페이지 삭제"라는 표시가 있다면, 오래된 토크 페이지를 삭제하고 새로운 페이지를 옮겨야 한다.나는 종종 이런 종류의 것에 반대한다[편집: "나는 종종 이런 종류의 제안들에 반대한다, 왜냐하면 그들이 어리석거나 지식이 없는 편집자들이 바보 같은 일을 할 수 있게 해주기 때문이다] 그러나 여기서 관리자는 항상 대화 페이지를 삭제하고 수동으로 움직이면 된다: 당신의 제안은 어리석은 행정가를 방해하는 데 별로 도움이 되지 않지만, 그렇게 하면 훨씬 간단해질 것이다.경솔한 움직임그러나 나는 하위 페이지를 삭제하는 것에 반대한다: 주요 토크 페이지와 달리, 토크 페이지 하위 페이지는 간과하기 쉽고, 실수로 놓치기 쉽다. 왜냐하면 다른 어떤 것도 탭을 빨간색에서 파란색으로 바꾸게 하지 않기 때문이다.특히 삭제될 페이지는 내가 보거나 편집하지 못했을지도 모르는 페이지들이기 때문에 내가 전혀 몰랐던 하위 페이지들을 짓밟는 위험을 무릅쓰고 싶지 않다.나이튼드 (대화) 00:39, 2015년 10월 2일 (UTC)[응답]

니텐드와 완전히 일치했어토크 페이지의 '삭제 및 이동'을 위한 체크박스는 유용하지만, 특히 페이지와 해당 하위 페이지가 앞뒤로 이동하는 경우, 해당 페이지의 상단에 리디렉션을 이동하기 위해 실제 컨텐츠를 삭제하는 경우가 발생할 수 있다.젠크스24 (대화) 01:13, 2015년 10월 2일 (UTC)[응답]

방금 몇 가지를 보간했으니 젠크스의 논평이 반드시 그들에게 적용되는 것은 아니다.나이튼드 (대화) 2015년 10월 2일 12시 20분 (UTC)[응답]

자동 삭제를 활성화하기보다는 UI가 하위 페이지가 존재하며 이동 중인 사람이 하위 페이지를 어떻게 해야 하는지 평가해야 한다는 경고를 제공할 수 있다면 더 좋을 것이라고 생각한다.나이 든 ≠ 더 현명한 12:45, 2015년 10월 2일 (UTC)[응답

그래, 좋은 생각이야.현재와 이 제안에 따라 하위 페이지를 갖는 유일한 효과는 "해당되는 경우 하위 페이지(최대 100개) 이동"에 대한 추가 확인란이다.하위 페이지가 존재한다는 자동 통지가 있다면 상당히 도움이 될 것이다.나이튼드 (대화) 2015년 10월 2일 13시 15분 (UTC)[응답]

Talk:Main_Page#Proposal:_제거_WP:In_the_news_from_the_main_page.

여론조사에 대한 예의상 링크를 주는 것.애덤 쿠어든, 2015년 10월 3일 (UTC)[응답]

이름을 변경할 때 사용자 및 사용자 대화 페이지 올바르게 삭제

사용자 이름을 변경할 때 새 사용자 이름으로 기존 사용자 페이지, 사용자 대화 페이지 및 하위 페이지를 MediaWiki로 적절하게 삭제하십시오.이유를 삭제하고 (각 개인 위키에) 이동하십시오.현재 기존 페이지에는 삭제 로그가 없고 이동은 "over rodirect"로 되어 있다.제프리T2000 (대화) 03:49, 2015년 10월 7일 (UTC)[응답]