위키백과:마을 펌프(기술)/아카이브 68

템플리트 네비게이터

나는 몇 달 전에 사용적합성 위키에 위의 디자인을 올렸으며 그 이후로 별다른 일은 일어나지 않았다.나는 시스템이 계층 구조를 구성하기 위해 AJAX 범주를 사용한다고 생각한다.사용자가 템플릿을 선택할 때 매개변수를 입력하라는 메시지가 표시된다(위키아와 유사).이를 위해서는 기계 판독이 가능한 메타 데이터가 더 많이 있어야 한다. DBpedia 논의를 참조하십시오.— 디스펜서 05:38, 2009년 11월 27일 (UTC)

내 생각에 이것은 좀 더 구체적인 계획인 템플릿 형식과 함께 유용할 것 같다.내가 이 아이디어로 보는 세 가지 주요 난제가 있다: 설계의 문제(위계 자체를 사용할 수 있게 하는 방법), 유지보수의 문제(복잡하거나 논쟁의 여지가 있는 새로운 템플릿을 추가하는 것) 및 포괄성의 문제(모든 템플릿을 시스템에 넣는가, 아니면 일부 하위 집합에 넣는가)어떤 부분집합?어떤 서브셋을 사용할 수 있는가?).말하자면, 그것은 흥미로운 생각이고 나는 그것에 대해 더 많은 생각을 하고 싶다.{{Nihiltres talk edits}}} 03:24, 2009년 11월 29일 (UTC

파일:Vamana1.jpg

나는 이 이미지를 DYK(19-10-09에 나타난)를 위해 잘랐다.자른 버전은 위키피디아에서 볼 수 있다.최근 추가된 249개, 그러나 바마나, 오남 등의 기사에는 없다.무엇이 문제인가? --Redtigerxyz 06:39, 2009년 11월 28일 (UTC)

나는 이미지의 설명 페이지를 공유지에 제거했고 이제 새로운 버전이 어디에서나 볼 수 있다.때때로 새로운 버전의 이미지를 업로드할 때 미리 보기가 재생성되지 않고 수동으로 수행해야 하는 경우가 있다.Svick (대화) 13:21, 2009년 11월 28일 (UTC)

바마나, 푸타나 등에서는 보이지 않고, 발리프라티파다에서도 상영된다.어리둥절해?? --Redtigerxyz ^Talk 13:50, 2009년 11월 28일 (UTC)

그것은 나에게 좋다.캐시를 바이패스해 보십시오(대부분의 브라우저에서 Ctrl+F5 키를 누르십시오).Svick (대화) 14:06, 2009년 11월 28일 (UTC)

아카이브

나는 CleverBot의 실수 후에 /Archive 67을 고치려고 노력했다.누가 내가 실을 잊어버리지 않았는지 확인해 줄래?이게 유일하게 깨진 페이지였나?(이러한 실수는 실책봇의 '언아카이빙(unarchiving)'에 있었고, 최근 기고문에서도 다른 것을 발견하지 못했으니, 그랬기를 바란다.)나는 또한 MiszaBot의 VP 아카이빙을 켜고, LemberBot을 껐다. 왜냐하면 LemberBot은 현재 작동하고 있지 않기 때문이다.다른 페이지로 전환해야 하는 페이지가 있는가?Svick (대화) 22:07, 2009년 11월 28일 (UTC)

색인된 페이지 없음

카테고리:허용되는 네임스페이스에서 마법 단어 __NOINDEX__가 사용될 때, 노인덱스된 페이지는 템플릿에 의해 자동으로 추가된다.NOINDEX(카테고리 추가):노인덱싱된 페이지(자동 분류기가 존재하지 않았을 때의 복제)를 추가하기 때문에 중복이 추가되고 실제로 색인화되지 않은 페이지(예: 메인 스페이스의 페이지)를 나열하므로 분류가 잘못될 수 있다.그러므로 나는 우리가 카테고리를 감축할 것을 제안한다.색인되지 않은 페이지, 템플릿에서 제거하기 시작:NOINDEX.

또한 카테고리를 필터링할 수 있다.MediaWiki를 통해 네임스페이스별로 페이지를 색인화하지 않음:Noindex-category, 네임스페이스로 나누는 것에 관심이 있는지 모르겠는데, 어떻게 생각하는지 알려줘. 우리는 적어도 페이지와 카테고리를 구분할 수 있어.

{{#ifeq:{{{네임스페이스} {{ns:카테고리}}} 색인되지 않은 카테고리 Noinded page}}}

. 세나륨 (대화) 01:01, 2009년 11월 28일 (UTC)

나도 동의해.그러나 {{NOINDEX}}}은(는) 잘못된 페이지에 배치되었을 때(효과가 없는 네임스페이스에 사용되었을 때) 특별한 추적 카테고리를 추가할 수 있다.우리는 이미 "What links here"를 사용하고 우리가 보고 싶은 네임스페이스를 선택함으로써 그러한 사례를 찾아 고칠 수 있다.그러나 페이지 하단에 (긴 설명 이름을 가진) 가시적인 카테고리를 유발하고 카테고리 페이지에 수정해야 할 사항을 설명하면 다른 편집자들이 우리를 위해 수정 작업을 계속하게 된다.그것은 우리가 작업하는 것을 절약하고, 우리가 위키브레크를 해도 페이지가 고쳐지며, 그것은 더 많은 편집자들이 템플릿을 사용하는 방법과 시기를 배우고 사용하지 않는다는 것을 의미한다.이 방법을 사용하여 다른 여러 템플릿에서 좋은 효과를 얻는다(예: 범주:위키백과 메시지 상자 매개변수를 수정해야 한다.

그리고 나는 필터링에 동의한다.Commons가 MediaWiki에서 ParserFunctions를 사용하는 것으로 확인됨:Noindex-category 그래서 그것을 처리할 수 있을 것 같다.일반적으로 큰 범주를 하위 범주로 나누는 것이 매우 유용하다.그리고 다른 여러 네임스페이스에서도 {{NOINDEX}}이(가) 많이 사용되고 있는 것으로 알고 있기 때문에 더 많은 네임스페이스를 필터링해야 한다고 생각한다.그래서 마법의 단어는 아마도 많은 네임스페이스에서 직접적으로 많이 쓰일 것이다.

그리고 이 토론이 끝나면, {{NOINDEX}}의 토크 페이지에 복사하는 것이 좋겠으니, 나중에 참고할 수 있도록 그쪽에 보이는 것이 좋다.

--David Göthberg (대화) 05:19, 2009년 11월 28일 (UTC)

범주 제거:{{NOIND}}의 위키백과 노인덱스 페이지, 업데이트하는 데 시간이 좀 걸릴 겁니다.잘못된 사용에 대한 추적 범주는 템플릿이 어떻게 사용되는지에 따라 달라진다. 예를 들어 신속한 삭제 템플릿과 같은 여러 템플릿에서 변환된다. _NOINDEX__를 직접 사용해야 할 수도 있다.세나륨 (대화) 2009년 11월 29일 16:02, (UTC)

파이어폭스 추락 사고

내 집 컴퓨터의 위키피디아 페이지를 방문하려고 하면, 내 파이어폭스가 고장 난다.2009년 9월 말(나 부재중) 이후 새로운 현상이다.이 문제를 해결하기 위해 Firefox 설정을 수행할 수 있는 작업이 있는지 확인하십시오.내 현재 버전의 Firefox는 최신 버전보다 훨씬 더 빨리 실행되기 때문에 업데이트하러 가지 않을래.

(미안하지만 버전 번호는 모르지만 2004년 8월에 설치되었다)

David Fremlin, 2009년 11월 28일 —서명되지 않은 의견을 82.31.207.41 (대화) 18:26, 2009년 11월 28일 (UTC)

버전 번호는 도움말 > 정보에서 사용할 수 있으며, 아마도 도움이 될 것이다(개인적으로 나는 당황한다).다른 웹사이트에서 고장 난 거 있어?그냥 얼어버리는 거야, 아니면 어떤 종류의 오류 메시지가 오는 거야? - Jarry1250 18:31, 2009년 11월 28일(UTC)

이렇게 빨리 답장해줘서 고마워!"버전 1.0"이기 때문에, 내가 그것을 받았을 때 약간 골동품이었던 것을 알 수 있다. 그래, 다른 사이트들도 같은 문제를 주었고, 나는 단지 별로 신경쓰지 않았다. "분할 결함"을 보도하면서, 그것은 얼지 않고, 완전히 죽는다. (나는 일종의 레드햇을 가지고 있다.내가 지금 타이핑하고 있는 다른 컴퓨터는 위키피디아 페이지를 다룰 수 있지만 엄청나게 느리다는 것을 알아.

내 "버전 1.0" 기계에서는 기본 페이지인 http://wikipedia.org을 얻을 수 있지만 http://en.wikipedia.org과 http://fr.wikipedia.org 둘 다 파이어폭스 프로그램을 죽인다.또 어떤 가치가 있는지는: http://en.wikipedia.org을 내 웹사이트에 복사했고, 거기 버전 1.0은 문제없이 읽지만, 물론 장식을 꽤 많이 놓쳤기 때문에, 문제는 스타일시트 어딘가에 있는 것 같다.David —서명되지 않은 의견을 82.31.207.41 (대화) 18:43, 2009년 11월 28일(UTC)까지 추가한 준비

추신. 이 페이지도 내 파이어폭스를 망가뜨린다.왼쪽 칸에 트러블이 있는지 궁금하다.아마도 이것은 다른 프레임과 다른 프레임에 있을 것이다.David —서명되지 않은 의견을 82.31.207.41 (대화) 10:16, 2009년 11월 29일(UTC)까지 추가한 준비

Firefox를 업그레이드하십시오.—DJ (대화 • 기여) 13:32, 2009년 11월 29일 (UTC)

나도 동의해.3.5가 1.0보다 훨씬 느리면 잘못된 행동을 하는 것이다:P - Jarry1250 13:34, 2009년 11월 29일(UTC)

프로그래밍 언어 확장(프로그래밍 기능이 더 많은 프로그램)

나는 위키피디아에 대해 몇 가지 템플릿을 썼다.그것은 마치 손을 뒤로 수갑으로 채운 채 그림을 그리려고 하는 것과 같다.프로그래밍 언어로서 매우 제한적이다.템플릿과 변수/루핑 조작 방법에 대한 자세한 정보를 검색하려는 초기 시도에서 변수 확장이 설치되었는지에 대한 질문에 이어 마을 펌프[1]에서 이러한 과거 논의를 찾았다.아모니는 위키피디아 [2]에 프로그래밍 언어 확장에 관한 토론 링크를 게시했다.내가 최근에 아노미에게 이 토론에서 무슨 일이 나왔느냐고 물었을 때, 아노미 씨는 이렇게 말했다.

• 교체 언어는 안전하게 내장되어야 한다(예: 샌드박스에서 탈출할 수 있는 방법이 없음).
• 리소스 제한이 용이함(WP 서버에 대한 DoS 방법 없음)
• 배우기 쉬운 (기여자가 이미 알고 있을 가능성이 높은 경우 포인트 적립)
• PHP 확장을 설치할 수 없고 외부 실행 파일을 공개할 수 없는 제한적 호스팅 사이트는 위키백과의 템플릿을 여전히 재사용할 수 있도록 순수 PHP 구현을 한다.

이번이 마지막이 진짜 살인마야."

제 질문은, 위키백과 소프트웨어를 사용하는 사이트가 얼마나 많은지, 위키백과 템플릿을 재사용할 수 있도록 제한적인 호스팅에 대한 통계가 있는가?그들이 말하는 사용자 기반 비율은 몇 퍼센트인가?고마워 Stmrlbs talk 18:24, 2009년 11월 29일 (UTC)

나는 미디어위키 엔진에서 그 가치가 얼마인지 사이트를 운영하고 있다.나 또한 같은 소프트웨어로 개인 위키를 운영한다.나는 두 기계에 대한 모든 루트 액세스 권한을 가지고 있다.우리는 제어판으로 서버를 설치하여 내부 통제권이 없는 사람들을 수용할 수 있는 데까지 갈 수 있을 뿐이다.이러한 제한적인 호스팅에서 서버를 실행할 때 당신은 스스로를 절름거리고 있는 것이다.순수 PHP 구현이 "있기 좋은" 것은 아니지만, 결코 개발 요건이 아니다. 2009년 11월 29일 (UTC)

순수한 PHP는 브리온 외 연구진에 의해 설계 요구 사항으로 간주되었다. 마지막으로 이것이 위키텍-l에서 진행되었을 때.개인적으로, 나는 그것에 대체로 동의한다.만약 위키코드가 템플릿을 재사용하는 것이 어려워지면, 위키코드의 휴대성이 크게 저해될 것이다.작은 사이트와 제한된 호스팅으로 사람들을 놀리는 것은 쉽지만, 미디어위키를 채택한 작은 취미 활동 사이트들이 엄청나게 많은데, 나는 그것이 장려되어야 한다고 생각한다.드래곤즈 비행 (토크) 2009년 11월 29일 19:17 (UTC)

우리는 지원을 찾고 제한적인 호스팅 환경에 있는 소수의 *quite*를 얻었으며, 그들은 PHP 확장을 설치하거나 외부 스크립트로 확장할 수 없다.PHP가 하는 방식과 모든 것을 빨아들이는 것은 정말 풀기 어려운 문제다.^데몬^{[omg plz]} 18:44, 2009년 11월 29일 (UTC)

삭제 로그 검색을 사용자 친화적으로 설정

나는 삭제 로그 검색을 더욱 사용자 친화적이고 인터넷 검색 엔진 사용과 일치하도록 하기 위해 버그 보고서를 제출했다.현재 해당 기사에 대한 삭제 로그 정보를 찾으려면 기사의 정확한 구두점을 삭제한 상태에서 정확한 제목을 입력해야 한다.로그 검색은 다른 검색과 마찬가지로 작동해야 하며, 기사 제목에서 키워드를 기반으로 삭제된 기사에 대한 정보를 찾을 수 있어야 한다.이것은 사람들이 위키피디아에서 다른 모든 검색을 사용하는 것처럼 로그 검색을 사용하는 것에 의한 혼란을 줄여줄 것이고 기사에서 정보를 찾을 수 없을 것이다.이 향상/버그에 동의하는 경우 구두점을 포함하여 정확한 제목을 요구하지 말고 버그질라: 버그#211555: 키워드 검색에 대해 투표하십시오.고마워. stmrlbs talk 01:42, 2009년 11월 30일 (UTC)

도구 서버 IP 편집 로그아웃 다시 시도

툴서버 IP, 91.198.174.201(토크 · 기여 · WHOIS)이 로그아웃을 다시 편집하고 있다.그 IP는 왜 소프트 차단할 수 없는가?로그아웃을 편집할 이유가 없지 않은가?Wknight94 15:44, 2009년 11월 25일 (UTC)

사람들은 이전에 툴서버에서 실행되는 봇이 승인되어 로그아웃하더라도 해를 끼치지 않는다고 주장해왔다.나는 반대한다, 왜냐하면 IP에서 봇과 같은 편집은 항상 6명의 관리자들이 그들이 하고 있는 일을 중단하고 서둘러 확인하도록 만들기 때문이다.그래서 애논 봇 편집은 실제 쇼스토퍼는 아니더라도 확실히 시간 낭비다.⬅ ❝Redvers❞ 15:49, 2009년 11월 25일 (UTC)

툴서버 규칙이 익명으로 편집하는 것에 대해 명시적이라는 점을 지적할 것이다.IP를 자유롭게 소프트 블록하십시오. --MZMcBride (대화) 15:53, 2009년 11월 25일 (UTC)

디스펜서는 이에 대한 이전 논의에서 일부 읽기 전용(따라서 익명) 툴 서버 봇이 편집이 차단되면 작동을 중단한다고 말했다.그래서 그 봇들이 고쳐지지 않는 한 이 IP는 차단되어서는 안 된다고 생각한다.Svick (대화) 2009년 11월 25일 19:58, 25 (UTC)

이미 명확한 규칙과 편집에 대한 책임의 필요성을 감안할 때 IP는 즉시 소프트 차단되어야 하며 그 후에 고장난 봇을 고쳐야 한다.OrangeDog(오렌지독) 2009년 11월 25일 (UTC) 20:29,

나는 또한 합의를 향한 한 목소리가 더 필요하다면 이것을 지지할 것이다.읽기 전용 봇은 무의미한 "내가 차단되었는가?"를 제거하거나, 만약 어떤 이상한 이유 때문에 실행 불가능한 경우 계정을 만들어야 한다.Anomie 25 23:05, 2009년 11월 25일 (UTC)

그래 소프트 블록 이 범위가 적절하다.그렇지 않으면 사람들은 계속해서 피위키피디아 틀과 다른 것들을 고치지 않을 것이고 그것은 더 어려워질 것이다.현재의 편집은 속도가 느리고 문서화가 잘 되어 있기 때문에 문제가 되지 않지만(따라서 어떤 임의의 IP보다 덜 책임이 있는 것은 아니며, 사실 더 그렇다) 원칙은 여전히 유효하다.Rich Farmbrough, 12:58, 2009년 11월 27일 (UTC)

문제의 원인이라면 왜 도우미봇을 패치하면 안 되는가?또한 91.198.174.203이 차단될 경우 HTML 스크래핑을 수행하는 일부 웹 도구는 파손되거나 기능이 저하될 수 있다.— 디스펜서 03:08, 2009년 11월 28일 (UTC)

왜 둘 다 하면 안 되는가?Anomie⚔ 21:06, 2009년 11월 28일 (UTC)

그러면 그 도구들은 그들이 실제로 할 필요가 없는 일을 하는 것이 금지되었을 때 고장나지 않도록 고쳐져야 한다.Mr.Z-man 21:13, 2009년 11월 28일 (UTC)

좋아, 그 IP에 3시간 테스트 소프트 블록을 달았어.Rich Farmbrough, 16:09, 2009년 11월 30일 (UTC)

사용자 블록 및 관리 툴의 페이지별 세분화 크기 조정

코드에 익숙한 사람이라면 누구나 사용자 블록에 페이지당 세분성을 추가하려는 노력을 느낄 수 있다.예를 들어 관리자가 X페이지 또는 Y 카테고리의 모든 페이지에서 사용자를 차단하고 싶지만 나머지 Wiki를 편집하도록 허용하려는 경우.

이와 유사하게, 페이지 단위로 주어진 관리자에 대한 관리 도구의 코드 변경이 얼마나 필요한지:예를 들어, '크래트'가 새로운 관리자 W에게 카테고리 X의 페이지를 삭제할 수 있는 권한을 부여하거나, 사용자 페이지가 카테고리 Y 또는 목록 Y에 있는 사용자가 카테고리 Z의 기사를 편집하지 못하도록 차단하는 것을 허용한다.또는 더 간단히 범주 X의 페이지에 대한 보호를 관리하십시오.

나는 이것이 비경쟁적일 것이라고 예상하지만, 그것이 몇 주 안에, 몇 달 안에 작동하도록 만들어질 수 있는 것인가, 아니면 현재 개발자들의 규모와 작업량을 감안할 때 그것보다 더 큰 것인가?

문의하는 이유는 여기를 참조하십시오. davidwr/(대화)/(기여)/(이메일) 01:56, 2009년 11월 28일(UTC)

2005년에는 기사당 차단 제안이 있어 큰 지지를 얻고 있다.2004년 이전부터 T2674는 기사별, 네임스페이스별 차단을 개발하여 지금까지 성공을 거두지 못했다.그것을 배치하려는 모든 시도는 실패했고, 나는 다른 제안들도 똑같이 혹은 더 실행하기 어렵다고 생각한다.우리의 개발자 공급 부족을 고려하면, 우리는 몇 년 전에 이 버그를 고칠 수 없었다.세나륨 (토크) 02:37, 2009년 11월 28일 (UTC)

불행히도, 그것은 고치기 가장 쉬운 벌레가 아니다.세나리움이 말한 것처럼 지금까지의 모든 시도는 비참하게 실패하였다.지난번 시도는 정말 안 좋았고 꽤 빨리 탈락한 거 알아.FWIW, 차단 코드 전체가 엉망이라 다시 써야 해누군가 나에게 동기를 부여하려고 노력한다고 느낀다면, 그것은 매우 오랫동안 내 뒤쳐져 왔다 : ^demon^{[omg plz]} 03:34, 2009년 11월 28일 (UTC)

실제 구현이 어려운 것은 아니지만 차단 시스템에 더 끔찍한 슬러지를 도입하지 않고는 제대로 구현이 어렵다.— Werdna • talk 00:38, 2009년 11월 30일 (UTC)

WP:필터가 할 수 있어야 하는가?유지하기는 힘들겠지만, 사용자 목록과 금지 페이지를 유지하기 위해 특별히 추가할 수도 있을 것 같아.나는 또한 범주가 필터 기준에 추가될 수 있다고 가정한다.--Stefan 14:04, 2009년 11월 30일 (UTC)

"페이지 단위 밴"에 대한 최근 토론

최근에 행정관이 "페이지당 배출 금지"를 내리는 것에 대해 논의하지 않았는가?그리고 페이지 하단의 요약에 따르면, 그러한 것들에 대한 합의를 찾지 못했는가?–xeno^talk 15:53, 2009년 11월 30일(UTC)

관리자 봇 프록시로 이 작업 수행

나는 그것이 곧:en에 받아들여질지는 의문이지만, 몇몇 작은 위키들은 특정한 화이트리스트 사용자들을 대신하여 특정한 일을 한 봇으로부터 이익을 얻을 수 있을 것이다.예를 들어, 기성 사용자가 특정 사용자의 멘토인 경우, 관리자봇을 멘토에 의해 요청하여 프로테지를 차단할 수 있다.마찬가지로, 반달 격투 그룹의 구성원은 사전 결정된 시간까지 사용자를 차단하고 사전 결정된 최대 시간 동안 페이지를 보호하는 봇에 접근할 수 있다.

코딩-더-봇의 관점에서, 이것은 어려워 보이나?큰 위키에서 잘 작동하고 큰 혼란을 일으키지 않으려면 위키 코드에 '비인격화'를 추가해야 하기 때문에 봇의 행동이 봇이 아닌 편집자로 기록되었다.가장 코드 추가가 큰 작업인가?davidwr/(talk)/(contracts)/(e-mail) 05:53, 2009년 11월 28일(UTC)

봇 레벨 코딩은 훨씬 쉽고 꽤 할 수 있다.β^_command 23:18, 2009년 11월 28일 (UTC)

이것은 비관리자들이 어떻게 관리 기능을 수행하는지에 대한 아주 세밀한 통제를 우리에게 줄 것이다.나는 호출하는 사용자 이름의 가장이 항상 편집 요약의 앞에 붙고 자신의 상세 로그를 보관하는 것이 그렇게 중요하다고 생각하지 않는다.이는 기준이 명확하고 객관적인 페이지 금지를 시행하는 데 큰 도움이 될 수 있다. 2009년 11월 28일 (UTC)

으으으으으으으으으.— Werdna • talk 00:38, 2009년 11월 30일 (UTC)

이것에 대해 자세히 설명해 주시겠습니까? davidwr/(대화)/(기여)/(이메일) 15:38, 2009년 11월 30일 (UTC)

텍스트 시프트

어떤 이유에서인지, 한 단어로 이루어진 이 단 하나의 편집은 텍스트가 모두 바이오박스의 보튼으로 떨어지게 만들었는가?핸디캡퍼 (대화) 16:40, 2009년 11월 30일 (UTC)

나는 그 두 개정판들 사이에 어떤 형식적인 변화도 보이지 않는다.어떤 브라우저를 사용하십니까?창 크기를 변경해 보십시오. --왕 어미에 20:17, 2009년 11월 30일 (UTC)

"백과사전 광고에 대한 5가지 사실" 이미지

그 광고에 실린 이미지들은 잘 배치되어 있지 않은데, 다시 배치해 줘.Accdude92 (Talk to me!) (사인) 20:10, 2009년 11월 30일 (UTC)

Z-bot씨가 나가신다.

Wikipedia_talk:위키프로젝트_철학, 사용자:Mr.Z-bot이 지난 40분 동안 14번이나 같은 메시지를 올렸는데, 관리자가 친절하게 그만둘 수 있을까?Paradoctor (대화) 02:52, 2009년 12월 1일 (UTC)

봇 소유자를 죽여라, 내가 말한다. --MZMcBride (대화) 03:01, 2009년 12월 1일 (UTC)

메시지는 서로 다르다는 점에 유의하십시오.보고서를 요청한 태스크포스마다 하나씩 있다.그러나 모든 태스크포스 대화 페이지는 메인 프로젝트 토크 페이지로 리디렉션된다.요약메세지를 만들었으면 더 좋았을 텐데, 여러 프로젝트가 토크페이지를 공유할 상황은 예상하지 못했다.(참고: 봇이 실제로 약 2시간 전에 편집을 중지했다는 점에 유의하십시오.)Mr.Z-man 03:03, 2009년 12월 1일 (UTC)

내 가슴의 깊이를 전하는 말들이 아마 있을 테지만, 지금으로서는 가슴 아픈 '엉덩이'가 가장 잘 떠오를 것 같아 두렵다.그리고 공식적으로 다음과 같다.나는 MZMcBride씨의 제안에 격렬히 반대한다.반달족을 견제하기 위해서는 우리의 모든 "전문가들이 필요하다.Paradoctor (대화) 03:38, 2009년 12월 1일 (UTC)

"변환"은 숫자를 lat_deg, lat_min, lon_deg 및 lon_min으로 조정한다.

안녕! 템플릿 구문에 대해 물어보는 거야.위치 지도

Pag(타운)를 위한 위키백과 페이지는 다음과 같이 좌표를 제공한다.

• 좌표 44 26.61 N 15 03.27 E

템플릿:위치 지도는 다음과 같은 동일한 마을에 대한 구문을 제공한다.

• lat_lat_min=44 lat_min=26 lon_lon=15 lon_min=3

그러니 그 정도면 공평하다.그러나 내가 만든 페이지에는 다음과 같은 내용이 있다.

• 좌표 59.9108 10.5920

이것은 구글 지도, 야후 지도 또는 이와 유사한 - cf에서 올바른 위치를 제공한다.59°54′39″N 10°35′31″E / 59.9108°N 10.5920°E / 59.9108; 10.5920 - 그러나 다음과 같은 위치 지도 구문에 숫자를 삽입하려고 하면 lat_deg=59_min=91 lon_deg=10 lon_min=59.

스칼럼

스칼럼 (아커스후스)

여기는 위치가 정확하지어쨌든 몇 분 몇 도인지 정말 모르겠어.내가 뭘 잘못하고 있는 거지?게시히테 (토크) 21:22, 2009년 11월 28일 (UTC)

도수는 전체 원의 1/360이다.분수는 섭씨 1/60도, 초는 분당 1/60이다. 초는 분(分)의 1/60이다.따라서 분수 부분(예: 0.9108)을 분으로 변환하려면 60을 곱한다(예: 0.9108×60=54.648분).도(각도) 참조#자세한 내용은 하위 구분.Anomie⚔ 21:28, 2009년 11월 28일 (UTC)

(충돌 편집) 나는 너에게 정도와 분(분)이 어떻게 작용하는지 설명하기를 기대했지만(그것은 꽤 간단하다, 정말) 그럴 필요가 없다는 것을 알게 되었다.그러한 불인정. :-)

십진법으로 좌표를 가지고 있는 경우, 즉 도, 분 단위가 아닌 도만 가지고 있으면 직접 넣을 수 있다.{{Location map}}의lat_deg그리고lon_deg아래 예제를 참조하십시오.Svick (대화) 21:39, 2009년 11월 28일 (UTC)

최소값과 초값을 선택적으로 만드는 코드를 샌드박스에 추가했다.— 디스펜서 07:47, 2009년 12월 1일 (UTC)

스칼럼

스칼럼 (아커스후스)

스크립트 기부 링크를 중간 클릭으로 사용할 수 없음

나는 기부 링크를 사용하고 싶었다.나의 자연스러운 행동 방침은 파이어폭스의 버튼/링크를 중간으로 클릭하고 그 동안 계속 현재 페이지를 읽는 것이었다.그러나 버튼은 자바스크립트만 있기 때문에 이것은 아무런 쓸모가 없었다.기부버튼은 정말 자바스크립트가 필요한가?왜 주요 자금원을 방해하는 작은 짜증나는 장벽을 두었는가?—Aaron Lawrence가 추가한 서명되지 않은 논평 준비 (대화 • 기여) 05:19, 2009년 12월 1일 (UTC)

그것은 사람들이 어디에서 왔는지 더 잘 추적할 수 있게 해주며, 다른 사람들이 내가 생각하는 청중들에게 제시된 배너를 최적화 할 수 있게 해준다.어쨌든 배너에는 자바스크립트가 필요하다.하지만 나는 그것이 약간 짜증난다는 것에 동의한다.—DJ (대화 • 기여) 20:43, 2009년 12월 1일 (UTC)

WP의 이미지 주석

이미지 주석은 왜 위키백과가 아닌 공용에만 나타나는가?아마도 많은 사람들이 모르고 있을 것이다.수리하면 EV가 추가될 것 같아.브랜드[t] 06:58, 2009년 12월 1일 (UTC)

"EV"는 알지 못하는 사람들에게 "적극적 가치"를 의미한다.Graham87 09:56, 2009년 12월 1일 (UTC)

아무도 여기에 설치하지 않았다.그리고 그 책의 저자로서 나는 en-WP가 그렇게 하기 전에 2, 3개월을 더 연기할 수 있다면 정말 고맙겠다.하원에 있는 그 기계는 10월 말에 기사의 미리 보기에도 주석을 직접 표시하도록 업데이트되었다.내가 알기로는 그 버전의 가젯은 아직 다른 곳에서는 사용되지 않았다.가장 큰 WMF 프로젝트에 먼저 배치하는 것이 오히려 위험할 것이다.현재의 계획은 우선 더 작은 위키 다양성 프로젝트에 그것을 배치하고 그것이 어떻게 진행되는지 보는 것이다.만약 모든 것이 잘 된다면, 우리는 더 큰 프로젝트(de-WP, en-WP)에도 이것을 사용하는 것을 고려할 수 있다.하지만 지금은 안돼, 제발.어쨌든, 그것이 여기서 활성화되기 위해서는 지역사회의 합의가 있어야 할 것이다; 그리고 사람들은 그들이 그것을 어떻게 구성하기를 원하는지 또한 설명했어야 했다.Lupo 15:52, 2009년 12월 1일 (UTC)

죽은 인터위키 접두사

방금 우연히 기사를 발견했는데, 인터위키 아래 외부 링크가 있는 W(더블유)는 ThePN에 링크되어 있다. W. 내가 그 링크를 따라갔는데, http://wiki.theppn.org/W,이 정말로 링크된 사이트는 다른 도메인으로 이동했다.(더PN의 이전 도메인인 .org는 데님 회사의 소유인 것 같다!?)나중에 검색해보니 http://wiki.jpopstop.com/wiki/W으로 연결되는 링크가 맞는 것 같아.

Interwiki 링크를 사용하여 ThePN과 외부로 연결되는 많은 다른 일본 아티스트 페이지가 있는 것을 보고, 나는 몇 가지 조사를 하기로 결정했고 헬프 데스크 기록 보관소에서 이것을 발견했다.위키백과:도움말_desk/Archives/2007_6월_25#2007년 날짜의 "ThePN:" 링크는 어떻게 작동하나?

더 많은 연구가 이를 가능하게 했다: http://community.livejournal.com/theppnwiki

그렇다면, 현재 ThePN이 JPOP Stop!이므로, 데이터베이스 액세스 권한을 가진 누군가가 들어가서 인터위키 데이터베이스에서 ThePN을 JPOP Stop!과 함께 체계적으로 제거/교체할 수 있으며, (might도) 링크가 있는 모든 기사에서 동일하게 할 수 있는가? --Geopgup (토크) 11:32, 2009년 12월 1일 (UTC)

인터위키 데이터베이스는 메타에 있는 인터위키 맵에 의해 제어되며, 메타 관리자만이 편집할 수 있다.이 토크 페이지 아카이브, 특히 ThePN 접두사 제거 및 JPOP 중지 접두사 추가에 대한 섹션을 참조하십시오!Graham87 12:30, 2009년 12월 1일 (UTC)

고도의 기술적 질문: 윙크, 윙크, nod, nod

왜 하필 내 거야!@#$%^&* 다른 거의 모든 것이 파란색일 때 빨간색 서명?커피와 동정은 기쁜 마음으로 받아들였다.차를 마실 수 없다.

테이퍼(토크) 01:38, 2009년 12월 2일 (UTC)

사용자:에서 사용자 페이지를 만들지 않았으므로테이퍼형.사용자 이름의 빨간색 링크를 클릭하기만 하면 뭔가를 쓰고 저장할 수 있다.프라임헌터 (토크) 01:43, 2009년 12월 2일 (UTC)

새 페이지를 나열하는 Google의 속도

나의 동료 위키피디아인 여러분, 나는 구글이 검색 엔진에 새로운 기사들을 나열하는 속도에 약간 걱정된다.나는 꽤 새로운 페이지를 순찰하고 많은 페이지를 저작권 침해로 분류한다.의심스러운 위반의 출처를 찾기 위해 나는 몇 줄의 의심스러운 기사를 복사하여 구글에 붙여넣을 것이다.변함없이 가장 먼저 등장하는 것은 기사 그 자체다.나는 그저 그것을 무시하고 그 근원을 찾을 때까지 다음 단계로 간다.하지만, 나는 단지 구글이 다양한 이유로 곧 삭제될 많은 기사들을 빨아들이고 캐싱하고 있는 것이 약간 걱정된다.그럼, 이게 무슨 문제가 되는 겁니까?나는 구글 리스트에서 12시간에서 24시간 동안 기다리게 하는 것이, 단지 그 기사가 빠르게 삭제되거나 다른 중대한 수정을 받지 않도록 하는 것이 좋을 것이라고 생각한다.생각?강아지 바구니 2009년 11월 23일 (UTC)

우리는 구글에 사료를 공급한다.내 생각에 자동으로 작동하도록 기술적 조작을 설정하는 것이 이치에 맞을 것 같다.{{NOINDEX}} 등록되지 않은 페이지Jehchman^Talk 19:16, 2009년 11월 23일 (UTC)

제호크만, 좋은 생각인 것 같아!기사가 회람될 때까지 구글 피드를 연기하는 것은 좋은 생각처럼 들린다.스피디 삭제로 표시된 페이지로 확장하는 것도 고려해 볼게.2009년 11월 23일 강아지 바구니(UTC)

피드가 새 페이지나 모든 개정판을 다루고 있는가?후자의 경우, IP 및 새로운 사용자 편집(플래그 리비전 테마와 함께)을 연기하는 것도 고려할 수 있다.LeadSongDog come howl 19:44, 2009년 11월 23일 (UTC)

대부분의 IP 편집이 좋으니, 그것은 미끄러운 경사다.적어도 새로운 페이지를 위해, 그리고 CSD의 대상이 되는 페이지들을 위해.강아지 바구니 2009년 11월 23일 (UTC)

현재 CSD 태그가 지정된 페이지는 NOINDEXed(또는 NOINDEXed)로 되어 있지만, 때때로 이것을 업데이트하는 데 구글이 시간이 걸릴 수 있다.- 킹핀¹³ (토크) 20:09, 2009년 11월 23일 (UTC)

{{NOINDEX}}은(는) 메인 스페이스에서는 작동하지 않는데, 그것은 의도적인 결정이다.— 가비아 임머 (대화) 2009년 11월 23일 20:30 (UTC)

응, 메인 스페이스에서는 NOINDEX가 작동하지 않는 것 같아.그것을 가능하게 할 수 있는 방법이 있는가?아니면, 더 정확히 말하자면, 등록되지 않은 페이지와 CSD 후보자에게만 그것을 가능하게 하기 위해서인가?2009년 11월 23일 퍼피스의 바구니(UTC)

물론 있다.재단이 그 정책에 대해 잘못 알고 있다고 재단을 설득하고, 지역 사회에 당신이 옳다고 확신시키고, 기술 담당자들에게 그것을 바꾸도록 설득하십시오.그러나 물론 이런 일은 일어나지 않을 것 같다.— 가비아 임머 (대화) 23:28, 2009년 11월 23일 (UTC)

CSD 태그에 추가하는 주요 문제는 페이지가 색인화된 후 추가하면 페이지가 다시 검색될 때까지 아무런 효과가 없다는 것이며, 몇 시간 또는 며칠이 될 수 있다.그래서 당신은 창조 후에 매우 빠르게 태그를 추가해야 하는데, 이것은 일반적으로 눈살을 찌푸리게 한다.Mr.Z-man 23:44, 2009년 11월 23일 (UTC)

그런가?나는 어디선가 구글이 위키미디어 콘텐츠를 직접 효율적으로 캡처하기 위해 구글봇을 단순히 사용자 정의하기 위해 그 관계를 중단하기로 선택했다는 인상을 받았었다. (그것은 모르지만, 최근의 변화를 추적함으로써 추측할 수 있을 것이다.드래곤즈 비행 (토크) 2009년 11월 23일 22:31, 23 (UTC)

불행히도, 모든 페이지가 실제로 순찰되는 것은 아니다.필요한 것은 새로운 등록되지 않은 물품에 대한 봇의 허가를 몇 시간 지연시키는 것이다.그들이 아니라 우리가 해야 할 것이다.나는 기술적으로 타당하다면 그것에 대한 어떤 합의가 있을 수 있다고 생각한다.나는 재단이 정책과 무슨 관계가 있는지 모르겠다. 그것은 enWP 결정이다. DGG (토크 ) 22:48, 2009년 11월 24일 (UTC)

나는 DGG에 동의한다.구글에 새로운 기사를 공급하기 전에 약간의 지연은 필수적이다. 그렇지 않으면, 새로운 기사는 어떠한 편집 감독 없이 홍보 목적으로 사용될 수 있다(예: 새로운 제품/서비스/영화/앨범/정책/냉동 융합을 위한 방법.기간은 "몇 시간"보다 길어야 한다.그러나: 동일한 시간대에 있는 누군가가 기사를 보고 수정할 수 있을 만큼 충분히 길어야 한다. 18-24시간은 더 의미가 있을 것이다(예: 사용자 A는 현지 시간으로 1800에 지역 회사 B에 대한 퍼프 기사를 쓰고, 사용자 C는 다음날 1000으로 보고 1200년까지 xis 검사를 완료한다).또한, 등록되지 않은 기사들을 색인화하지 않고, 그것들이 회람될 때까지 구글에 공급하지 말아야 한다는 주장도 있다.... - 포인트리스트 (대화) 23:35, 2009년 11월 24일 (UTC)

구글이 어떤 페이지를 인덱싱할지 결정하게 하는 게 어때?나는 우리가 구글과 검색자들이 무엇을 원하는지 재평가하는 것은 좋은 생각이 아니라고 생각한다.때로는 최근에 만들어진 기사를 찾는 것이 유용하다. --Apoc2400 (토크) 16:33, 2009년 11월 25일 (UTC)

COI BOT는 새로운 페이지를 검색하여 복사 붙여넣기 페이지인 경우 태그를 지정하지 않는가?Tim1357 (대화) 2009년 11월 25일 17:00 (UTC)

새로운 페이지를 순찰하는 꽤 많은 일을 하는 사람으로서, 나는 COI BOT가 복사 붙여넣는 새로운 기사들을 많이 놓치고 있다고 말할 것이다.한 시간 안에 5-10에 카피 붙여넣기 저작권 위반 딱지를 붙인다.2009년 11월 26일 퍼피스의 바구니(UTC)

단지 FYI, 구글의 새로운 페이지 목록은 매우 빠른 것 같다.예를 들어, EuroVoice 유럽 음악 콘테스트는 오늘 UTC 2145에서 만들어졌으며, 만들어진 지 6분 이내에 구글에 등록되었다(검색 결과: EuroVoice 유럽 음악 콘테스트 사이트:wikipedia.org).나는 그것이 좀 무섭다고 생각한다.실제로 이 예에서는 NPP 시스템이 잘 작동했는데, 기사는 자동으로 "잠재적인 자서전이나 이해충돌 가능성"이라는 꼬리표가 붙었고, 편집자가 그것을 순찰하고 광고에 표시했고, 나는 그것을 템플리트로 만들었고, 슈민웹은 그것이 만들어진 지 1시간도 되지 않아 이미 그것을 삭제했으므로 괜찮다.그러나 그것은 살아있는 사람에 대한 고약한 공격이었을지도 모른다 – 그들은 여전히 NPP 밀접하게 일하면서 3주 이상 된 등록되지 않은 BLP 페이지들 – 또는 심지어 금융 시스템에 대한 신뢰를 떨어뜨리려는 비열한 시도일 수도 있다.어쨌든, 만약 나쁜 사람들이 즉시 순찰을 받지 않을 수 있는 새로운 기사를 만들어 구글의 최고 리스트를 얻을 수 있다는 생각을 갖게 된다면, 위키피디아에는 좋지 않을 것이다.IMO는 인간이 검토하기 전에 원시 콘텐츠를 구글에 공개하는 아이디어에 대해 더 폭넓은 논쟁이 있어야 한다. - 포인트리스트 (토크) 22:49, 2009년 11월 26일 (UTC)

얼마 전만 해도 이 문제를 따로 눈치채고 극도로 짜증이 났지만, 구글에 대한 개인적 혐오감 때문에 내 의견이 색깔에 불과하다는 생각에 말을 꺼내지 않았다.나는 다른 모든 사람들이 "오, 하지만 구글이야!그리고 그들은 너무 훌륭해서 그들이 하는 어떤 것도 잘못될 수 없어!"어쨌든, 그들이 지금 위키피디아 페이지에서 수정을 받는 속도는 우스꽝스럽다.단순히 새로운 페이지가 아니다.그들은 이미 당신의 위의 코멘트를 가지고 있다. [3]그들은 (때로는) 몇 분 안에 검색 스니펫에 변화를 주는 것처럼 보이는데, 이것은 BLP의 관점에서 위험하다. 인신공격은 페이지와 사람의 관련 키워드를 한 번에 색칠하기 시작해야 한다.구글의 일부 사람들은 위키피디아의 영향력에 대한 완전한 무지로 그들의 봇을 최근 창어 사료에 확실히 연결시켰다.• 아나킨 23:33, 2009년 11월 26일 (UTC)

옵션은 랜딩 페이지일 수 있고, 구글이 하나를 빨리 인덱싱하고 검색 페이지에 링크를 만들 수 있으며, 평균 시간 위키피디아(우린)에서 스팸이나 다른 이유로 삭제하기 때문에 랜딩 페이지로 링크한다. "당신의 검색 엔진이 최신 상태가 아니다"라는 정책상의 이유로 기사를 삭제했는데, 이는 "이 기사는 존재하지 않는다" Mio보다 훨씬 나은 것이다.n (토크) 2009년 11월 26일 23:47 (UTC)

제외나 토론의 이유가 이해를 위해 해당 페이지에 자동 포함되지만 소프트웨어 작업 Mion (토크) 23:57, 2009년 11월 26일 (UTC)

생각해보면, 실시간 인터넷, 이것이 무엇에 관한 것인지, 실시간 협업에 관한 것인지, 우리는 먼저 새로운 기사를 확인하거나 편집하는 데 필요한 회의록을 논의할 수 있다, 나는 새로운 기사를 견본화 할 필요가 있다고 생각한다, 새로운 기사들에 대한 찬성과 반대는 체크되지 않았다.미온(토크) 00:10, 2009년 11월 27일 (UTC)

그리고 템플릿은 탐색 템플릿을 선호하며, 뺑소니 템플릿을 싫어한다:)Mion (토크) 00:12, 2009년 11월 27일 (UTC)

위키백과 atm의 가장 강력한 기둥 중 하나는 현재 사건 보도인가? 모든 새로운 기사를 24시간 지수대에 놓는 것은 우리 자신을 크게 다치게 할 수도 있다는 것을 모두에게 상기시켜 줄 수 있을까?등록되지 않은 페이지에 대한 노인덱스는 내가 상상할 수 있는 것이지만, 24시간 블록이 더 잘 생각되지 않는다면, 약간 너무 많은 것 같다.—DJ (대화 • 기여) 00:36, 2009년 11월 27일 (UTC)

중요한 새 기사가 24시간 후에 등록이 취소된다면, 구글에 접속하는 것만이 유일한 해결책은 아니다.창조자는 항상 누군가에게 순찰을 부탁할 수 있다.NPP 백로그가 문제라면, 우리는 패트롤러들에게 더 많은 지원을 해야 할 수도 있고, 아니면 새로운 편집자들이 새로운 기사를 만들기 전에 기존 기사를 최소한으로 수정하도록 요구할 수도 있다. - 포인트리스트 (talk) 11:11, 2009년 11월 27일 (UTC)

삭제된 페이지 캐시를 Google에서 제거할 수 있음

1. 이 작업을 수행하려면 Google 계정이 있어야 함
2. 여기로 이동: https://www.google.com/webmasters/tools/removals
3. "새 제거 요청" 단추를 누르십시오.
4. 무엇을 제거하시겠습니까? --> 구글 검색 결과에 나타나는 정보 또는 이미지. --> 다음
5. 어떻게 제거되었는가? --> 사이트 소유자는 이 페이지를 수정하여 더 이상 나와 관련된 정보나 이미지를 포함하지 않도록 했다. --> 다음
6. 첫 번째 텍스트 상자에 wiki 페이지 URL을 입력하십시오. http://en.wikipedia.org/wiki/EuroVoice_European_Music_Contest
7. 삭제된 페이지에서 더 이상 URL에서 검색할 수 없는 단어를 입력하십시오.이 부분은 기사명을 예시로 입력할 수 없기 때문에 조금 까다롭다, 페이지 제목은 여전히 그 URL에 올라오지만, 지금은 "기사 foo는 존재하지 않는다"고 말하고 있다.대신 삭제 페이지 통지에 나타나지 않는 삭제된 문서에 WAS 단어를 포함시켜야 한다.삭제 통지 페이지 내, 사이드바 또는 페이지 상단의 재단 기부 배너에서 단어를 찾을 수 있는 경우 캐시된 페이지 삭제는 거부된다.
8. Google에 요청 제출
9. 구글이 제거 요청에 따라 행동할 때까지 최대 2~3일을 기다리세요.

성공하면 삭제된 글의 캐시된 페이지가 제거되고, 캐시 링크가 없는 검색 URL만 삭제 통지 페이지로 이동하는 일만 남게 된다.

구글에 대한 이러한 캐시 삭제 제출은 페이지 삭제 과정의 일부로 자동화될 수 있을 것이다.64.91.85.115 (대화) 20:12, 2009년 11월 29일 (UTC)

사실 이것은 좋은 정보인데, 왜냐하면 그것은 전체 페이지가 삭제될 때 거의 프로그램적으로 실행될 수 있기 때문이다.중요한 문제는 역사 병합과 오려내기 수리인데, 이 두 가지 모두 페이지를 일시적으로 삭제하게 된다.— 가비아 임머 (대화) 2009년 11월 29일 20:18, (UTC)

VPR

이상하게도, VPR: 위키백과: 위키백과:빌리지_펌프_(제안)#Mark_pages_less_for_24_hours_old_for_no-indexing.개인적으로 나는 페이지를 즉시 색인화해야 할 어떠한 정책적 이유도 없다고 본다(주제 기사의 경우는 드물지만, 나는 심지어 24시간을 기다리는 사람들과도 함께 살 수 있다 - WP:NOTNNEWS).Rd232 22:24, 2009년 12월 2일(UTC)

아티클의 번호가 잘못되었거나 연결된 노트

1988년 「저작권·디자인·특허법」에서 본문의 노트와 「참조·노트」 부분의 노트의 번호가 일치하지 않는다.예를 들어, infobox 링크에서 [2]번호는 19번으로 번호가 매겨졌다. 따라서 3번과 18번 사이의 모든 숫자가 잘못되었다.사소한 편집과 재구축을 시도해 봤지만 별 차이가 없다.그래서 나는 기술적 오류가 있을 것이라고 생각한다.누가 이걸 좀 봐줄래?피터 콕스헤드 (대화) 2009년 11월 27일 10:56, (UTC)

기사는 cite.php 대신 기존의 {{ref}, {{note} 시스템을 사용한다.그것은 아마 개종되어야 할 것이다.OrangeDog(오렌지독) 2009년 11월 27일 (UTC) 12:36,

개조를 하기에는 일이 많아 보이는데, 도구가 있는가?피터 콕스헤드 (대화) 19:20, 2009년 11월 30일 (UTC)

예, 사용자:Cyde/Ref 컨버터.변경 사항을 항상 다시 확인하십시오.Graham87 14:13, 2009년 12월 1일 (UTC)

컨버터 설명서를 보면, 오류의 원인이 {{Infobox}} 템플릿 내의 참조인 것처럼 보이는 것이 문제다.(이후 번호 매김이 잘못됨)사용자:Cyde/Ref_Converter#Converting_reference_been_템플릿은 "미디어위키 또는 참조/참조 확장 중 하나에 템플릿이 포함된 페이지에 문제를 일으킬 수 있는 버그가 있다"고 제안한다.나는 그 페이지에 문제의 근원이 될 것 같은 것은 구식 인용 시스템이 아니라 이 버그라고 생각한다.Peter coxhead (대화) 10:08, 2009년 12월 2일 (UTC)

MediaWiki 인터페이스 메시지

이제 MediaWiki 인터페이스 메시지에 대해 논의할 수 있는 새로운 중앙 페이지가 생겼다.위키백과:미디어위키 메시지.일종의 '빌리지 펌프(미디어위키 메시지)'이다.신사 숙녀 여러분, MediaWiki 인터페이스 메시지가 흥미롭다면, 이 페이지를 여러분의 감시 목록에 추가하는 것을 고려해 보십시오.

--David Göthberg (대화) 2009년 11월 29일 (UTC) 20:14

사용자가 로컬 MediaWiki 메시지를 삭제(또는 처리되지 않은 상태로 유지)하면 성능이 약간 향상된다는 이야기를 들었으므로 현재 기본 메시지와 동일한 모든 MediaWiki 메시지를 삭제하자고 제안했다.이것은 수백 개의 인터페이스 메시지와 관련이 있다.만약 이것에 대해 아는 사람이 있다면, 위키피디아에서 논평하고 싶으십니까?MediaWiki 메시지#미디어위키:1movedto2?

--David Göthberg (대화) 2009년 12월 2일 19:15 (UTC)

업로드 진행 중 대화 상자

이미지를 업로드할 때 가끔 이 대화 상자가 표시되기도 해.아마도 20명 중 1명일 것이다.항상 0%에 걸려서 파일을 업로드하기 위해 프로세스를 다시 시작해야 하는데, 그러면 이 대화 상자가 나타나지 않아.무엇이 이것을 촉발시키고 있는지에 대한 아이디어는? -- - Gadget850 (Ed) 21:14, 2009년 11월 30일 (UTC)

UI를 보면 사용적합성 팀이 꾸며낸 것처럼 보인다.내 추측으로는 이것은 베타 기능이고 a) 불안정하거나 b)는 일부 시간만 가능했다.{{Nihiltres talk 편집}}04:40, 2009년 12월 1일 (UTC)

아래 토론에 따라 Adblock Plus에 다음 규칙을 추가했다.

http://en.wikipedia.org/w/extensions/UsabilityInitiative/*

그 이후 업로드에 대한 모든 시도는 "업로드 진행 중"이라는 결과를 낳았다. ---— Gadget850 (Ed) 13:12, 2009년 12월 1일 (UTC)

Firefox 애드온 "Firefogg" - Preferences > Gadgets > Add mwMembed 지원...에 관련된 향상된 업로드 팩의 일부분 입니다.그 상자 체크 표시했어? - Jarry1250^{[Humorous? Discuss.]} 19:18, 2009년 12월 1일(UTC)

아- 그래.나는 그것을 무력화시켰고 무슨 일이 일어나는지 볼 것이다. ---- Gadget850 (Ed) 23:57, 2009년 12월 1일 (UTC)

이 대화 상자는 사용적합성 이니셔티브의 작업이 아니라 마이클 데일의 작업이다.Adblocking 사용성이니셔티브는 어떠한 방식으로도 이에 영향을 주어서는 안 된다(이론적으로). --Catrope 20:54, 2009년 12월 1일 (UTC) —Catrope가 추가한 서명되지 않은 코멘트 작성(토크 • 기여)

"Add mwEmbed support for..."를 사용하지 않도록 설정했는데도 여전히 대화 상자를 받았다.도구 모음에서 같은 스타일의 대화 상자를 표시하는 "미디어 추가 마법사" 아이콘이 표시됨.관련성이 있는 경우 모노북을 사용한다. -- - Gadget850 (Ed) 12:51, 2009년 12월 2일 (UTC)

상단 라인 배치가 여전히 손상됨

이전: 주 공간 오른쪽 정렬 제목 요소가 다시 끊어짐

지금 누군가가 고칠 만큼 기사공간에 심각한 문제인가?OrangeDog (1999 • ε) 13:14, 2009년 12월 1일 (UTC)

이것은 아마도 모금 현수막이 있는 무언가에 기인할 것이다.내가 임시변통할 수 있는지 알아볼게.이런 문제가 없는 베타 벡터 스킨도 사용할 수 있다.—DJ (대화 • 기여) 16:19, 2009년 12월 1일 (UTC)

너는 배너 btw를 숨기기 위해 그 가젯을 사용하고 있니?나는 이 문제를 계속 보고 있었지만, 저녁 식사 후에나 기다려야 할 것 같아.시험 시간을 잘 들이지 않고 제대로 풀기에는 너무 복잡해.—DJ (대화 • 기여) 16:59, 2009년 12월 1일 (UTC)

특히 기금 모금에 관한 중앙 통지의 믿을 수 없을 정도로 성가신 성격 때문에, 기금 모금에 대한 적절한 탐지 방법을 찾을 수 없었기 때문에, 현재로서는 해결 방법이 단순히 영구적으로 활성화되어 있다. diff —TheDJ (대화 • 기여) 2009년 12월 1일 (UTC)

이 문제는 사용자:84user/monobook.css를 편집하여 위키백과 로고 및 배경 이미지(나는 더 깨끗한 레이아웃을 선호함)를 삭제할 때 발생한다.좌표 템플릿 코드는 위의 OrangeDog와 같이 기사 상단에 오버레이된다.내 독일어 편집:Benutzer:84user/monobook.css는 이 문제를 일으키지 않는다 - 좌표는 기금 모금 배너 바로 위에 있는 탭 바 선 아래에 나타난다.두 CSS 파일에서 모두 내 편집 기록을 참조하십시오.나는 모금 배너를 숨기지 않지만, 내 영어 계정에서 사용할 수 있는 많은 장치들이 있다.나는 Como, Merate, Wellington, 그리고 그들의 독일 동급 제품 de:코모, 드:Merate and de:웰링턴: en: 페이지는 좌표가 겹치고, de: 페이지는 괜찮다. -84user (토크) 21:08, 2009년 12월 1일 (UTC)

CSS와 Javascript는 캐싱을 사용한다.따라서 수정하기 전에 브라우저 캐시를 바이패스해야 한다.브라우저를 다시 시작하면 캐시도 지워질 수 있다.—DJ (대화 • 기여) 21:19, 2009년 12월 1일 (UTC)

나는 매번 캐시를 우회한다.그 문제는 다른 브라우저에서도 로그인하거나 로그아웃한 나에게도 여전히 존재한다."좌표"라는 아이디가 있는 스팬에 사용되는 CSS로 범위를 좁혔을 수도 있다.여기서 제공된 html을 변경하여 좌표선을 해트노트 텍스트에서 "이동"할 수 있다.

<span id="coordinates">

이를 위해:

<span style="position:absolute; z-index:60; right:35px; top:-40px;">

35 px는 상단 "[ ]" 링크(내 기본 설정에서 사용 가능)에 공간을 허용하는 것이고 -40px는 좌표를 선 위(내가 원하는 위치)로 이동시킨다. -20px는 선 바로 아래에 두지만 해트노트 텍스트는 삭제한다.좌표는 보통 내 모노북.css가 삭제하는 "From Wikipedia, the free 백과사전"이라는 행과 같은 선에 위치한다.OrangeDog의 스크린샷에도 해당 라인이 빠져있다. -84user (토크) 22:18, 2009년 12월 1일 (UTC)

아, 그게 이유야.그럼 운이 없군, 내가 만든 해결책은 독자들의 대다수를 위한 것이지, 자신의 스타일을 해킹하는 사람들을 위한 것이 아니었다. :D 당신은 당신의 모노북.css 파일에 다음을 수동으로 추가해야 할 것이다.

#바디컨텐츠 { 포지션:상대적; }  토피콘 {   맨 위의:-3em !중요하다; } #좌표{   맨 위의:-1em !중요하다;   맞다: 0px를 붙이다; !중요하다; } 

bodyContent는 통지 중에 위치를 수정하기 위해 활성화되어 있는 것이다.이것은 벡터 아래에서도 영구적으로 적용된다.기본 위치를 모두 수정하고 "From Wikipedia the Free 백과사전" 태그라인에서 누락된 1em 높이를 설명하기 위해 토피콘 변경이 필요하다.—DJ (대화 • 기여) 23:58, 2009년 12월 1일 (UTC)

나도 동의해, 해커들보다 독자들이 먼저야.당신의 수정은 현재 크롬과 오래된 Netscape 브라우저에서도 로그아웃한 사용자들에게 효과가 있다.위의 CSS 코드 조각에 감사한다; 사용자 내부에는 아무런 영향도 없었다.Test84user/monobook.css, 그러나 사용자:Test84user/monobook.js(점 하나를 추가하고 세미콜론을 제거했다):

부록CSS('#Subsite {display:none !중요} \n#bodyContent { position:상대적, } \n.topicon {top:-3em !중요, } \n#choordinations{top:-1em!중요, 오른쪽: 0px!중요, }'); 

이 자바스크립트는 약간의 기이한 점을 가지고 있다: 칸투에서 좌표는 선을 가로지르지만 리디렉션에서는 OK이다. (사용자:Test84user는 내가 시험에 사용하는 계정이다) -84user (대화) 04:17, 2009년 12월 2일 (UTC)

"다시 리디렉션"이라는 통지는 "Whichinia로부터"와 같은 공간을 다시 추가한다."는 다음과 같이 덧붙인다: ( —DJ (대화 • 기여) 12:04, 2009년 12월 2일 (UTC)

검색 기법 개선 제안

나는 위키피디아가 훌륭한 프로젝트라고 생각한다.그러나 한 가지는 여전히 누락되어 있어 시스템 사용성을 크게 향상시킬 수 있다.키워드의 어떤 조합으로도 검색이 가능해야 한다.그런 다음 일치하는 모든 기사에 대한 링크를 포함하는 특수 페이지가 표시되어야 한다.이상적으로는 다음과 같은 (고급) 검색 가능성이 나란히 존재해야 한다.

1. (이것을 위한 텍스트 필드에) 모든 키워드를 포함하는 기사만 찾을 수 있다. 2.키워드를 포함하지 않은 기사(이러한 텍스트 필드)만 찾을 수 있다. 3.키워드(이러한 텍스트 필드) 중 ANE가 포함된 기사만 검색해야 한다.

하나의 검색 파일만 제공되는 경우 & for logical AND, logical OR, 그리고 ! (아마도 괄호 사용 포함) 논리적 NOT를 사용하는 구문

예:나는 카우보이, 인디언이라는 단어가 포함된 모든 기사를 찾고 싶지만 영화와 픽션이라는 단어는 찾지 못했다.그러면 다음 검색 문자열을 사용할 수 있다.

카우보이 & 인디안 & ! (영화 픽션)

할레킨96 (대화) 07:02, 2009년 12월 2일 (UTC)

음...물론 우리는 이미 이것을 가지고 있다. 사실 몇 년 동안 가지고 있었다.좀 더 자세히 보면..wp에서의 당신의 질문은 특별할 것이다:검색/카우보이 인디언 - (영화 OR 픽션).그러니까, AND는 암묵적이야 OR은..NOT는 다른 검색 엔진에서와 마찬가지로 마이너스 부호로 분류된다.다른 쪽 손에는 '말씀하셨나요'가 더 똑똑해져야 하는데..:) --레인맨 (대화) 2009년 12월 2일 (UTC)

위키피디아의 검색 엔진은 항상 좀 원시적이었다.최근에 개발자들이 많이 개선했는데, 작업량을 보면 금방 이런 작업을 하는 것을 볼 수 없다.그 동안 Google Advanced Search를 사용해 보십시오. — 이, 저, 그리고 다른 (대화) 10:07, 2009년 12월 2일(UTC)

새 페이지에 대한 기여 검색

새로운 페이지를 찾기 위해 내 자신의 기여(또는 사용자)를 검색하는 쉬운 방법이 있는가?나는 단지 내가 만든 기사들의 목록을 얻으려고 노력하는 중이다.—N마jdan•talk 19:31, 2009년 11월 30일(UTC)

툴 서버에는 이를 가능하게 하는 많은 도구들이 있다.하지만 내가 아는 한 미디어위키 자체에 내장된 것은 없다.Soxred93은 여기에 도구 모음집을 가지고 있다.네가 찾고 있는 것은 이것이다.베스트, - 킹핀¹³(토크) 19:40, 2009년 11월 30일(UTC)

완벽해고마워!-NMajdan•talk 21:02, 2009년 11월 30일(UTC)

모든 사람의 "사용자 기여" 페이지 하단에 있는 상자에 포함되어 있다 - "예술작성"이라는 레이블이 붙어 있다. -- Quidity (토크) 21:00, 2009년 12월 3일 (UTC)

사용적합성 이니셔티브 차단

사용적합성 이니셔티브가 초래한 문제를 어떻게 제거할 것인지 알아냈다.

지금쯤 많은 분들이 사용적합성 이니셔티브에 대해 들어보셨을 겁니다.그리고 실험 코드를 삽입하기 때문에 그것이 야기하는 문제를 알아챘다는 것을.예를 들어 클릭트래킹 JavaScript와 새로운 기능을 실행하는 사용자로 무작위로 선택되어 사용적합성 사람들은 우리가 어떻게 행동하고 그들의 새로운 기능이 어떻게 작동하는지 테스트하고 연구할 수 있다.그리고 각 사용자가 몇 시간 동안 이 기능을 실행한 다음, 전원이 꺼지고 다음 날 몇 시간 동안 다시 돌아올 수 있는 것처럼 보인다.지금까지는 좋았지만, 그건 상관없어.

하지만, 나는 오래된 컴퓨터를 가지고 있어서 그들의 코드를 모두 로드하고 실행하면 내 페이지 로드가 터무니없이 느려진다.그리고 때때로 그들의 암호는 매우 엉성해서 모든 종류의 문제를 일으킨다.나는 템플릿과 다른 생산적인 것들을 하기 위해 여기에 있어, 그래서 나는 그들의 실험 대상이 될 시간이 없다.그래서 나는 이 문제를 어떻게 제거해야 하는지 알아냈다.

나는 "애드블록 플러스"라는 훌륭한 애드온을 가진 파이어폭스를 가지고 있다.그래서 필터에 이 규칙을 추가했다.

http://en.wikipedia.org/w/extensions/UsabilityInitiative/*

이 규칙은 사용적합성 이니셔티브의 모든 자바스크립트 및 CSS 파일을 차단한다.와우!이제 나는 위키피디아를 다시 편집할 수 있어!그리고 페이지는 다시 허용 가능한 속도로 렌더링된다.

그리고 누가 말하기 전에: "그것은 아마 우연의 일치였을 것이다."글쎄, 나는 가끔 그 규칙을 끄려고 노력해왔고, 매번 규칙을 해제할 때마다(그리고 동시에 그들의 실험 코드를 실행하기 위해 선택된다), 그러면 상황은 다시 느리고 무뎌진다.그리고 나는 그들의 코드를 읽었는데, 그것은 반복적으로 우리가 여기 있는 자바스크립트 코더들에게 피하라고 말하는 기능들을 사용한다. 왜냐하면 우리는 그 기능들이 너무 느려진다는 것을 알고 있기 때문이다.아니, 우연이 아니야.

벡터 스킨은 사용적합성 코드에 따라 다르므로 벡터 스킨을 사용하는 경우 Adblock 필터링(또는 브라우저에 있는 모든 애드 블록 프로그램)에 이 규칙을 추가하지 마십시오.

--David Göthberg (대화) 05:28, 2009년 12월 1일 (UTC)

데이빗, 이렇게 말해줘서 고마워, 내 머리 위로 거대한 전구가 바로 번쩍거리거든.나는 최근에 내가 식별할 수 없는 간헐적인 추태를 보였는데, 이것이 그것을 고쳤다.우연히, 내 경우는 NoScript의 사용으로 인해 발생한 것이 아닌가 의심스럽다. 사용적합성 프로젝트가 하이퍼스페이스에서 임의 스크립트를 로드하고 있다면 화이트리스트에 화이트리스트를 추가했음에도 불구하고 해당 스크립트가 내 화이트리스트에 포함되지 않았을 가능성이 있다.wikipedia.org.만약 다른 누군가가 문제를 겪고 있다면, 이것이 범인일 수도 있다.— 가비아 임머 (대화) 06:20, 2009년 12월 1일 (UTC)

우리가 사용해서는 안 되는 악랄한 것에 대해 구체적으로 설명해 주시겠습니까? --Catrope 20:49, 2009년 12월 1일 (UTC) —Catrope가 추가한 서명되지 않은 코멘트 준비(토크 • 기여)

카트로프:물론이지. 특정한 악은getElementsByClassName()기능을 하다그것은 매우 무거운 기능이다.그래서 경험이 많은 자바스크립트 코디네이터들은 우리에게 그 기능을 피하라고 말했다.그리고 나는 경험이 많은 코더들 자신이 그 기능을 사용하지 않기 위해 그들 자신의 코드로 많은 노력을 기울인다는 것을 안다.하지만 난 그게 아주 작은 기능이라는 걸 알아, 난 그걸 직접 사용하고 싶어졌어...

나는 js 신참일 뿐이지만, 코드의 oldSizzle() 함수에 그 함수를 여러 번 사용하는 것을 볼 수 있고, 어떤 상황에서는 그 함수가 시즐() 함수에 할당되어 사방에서 사용되고 있다.그것은 js2.combined.min.js 파일에 있다.

하지만 어쨌든, 위에서 설명했듯이, 정확한 이유와 상관없이: 만약 내가 당신의 코드를 차단하지 않는다면, 위키피디아의 편집은 너무 느려지고, 때로는 버거워진다.(그러나 나는 그 정도로 버기 부분은 개의치 않는다, 결국 당신의 코드가 조만간 실시간 테스트 되어야 한다.)

나는 사용자들이 당신의 테스트를 거부할 수 있는 장치가 있어야 한다고 생각한다.우리 중 일부는 그것을 실행할 수 있는 하드웨어 및/또는 대역폭을 가지고 있지 않기 때문이다.불행히도 그것은 로그인하고 가젯을 알고 있는 소수의 사용자들에게만 도움이 될 것이다.따라서 사용자의 페이지 로드+렌더링 시간을 자동으로 측정하여 사용자가 하드웨어 속도가 너무 느린 경우 코드를 로드하지 않도록 하는 쿠키를 저장할 수 있다.그게 가능하겠어?

--David Göthberg (대화) 09:20, 2009년 12월 2일 (UTC)

그것은 다소 무거운 기능이다.브라우저에 기본 구현이 있다면 그렇게 나쁘지 않은 겁니다.가장 큰 문제는 그 기능을 시작하기 위해 어떤 진입점을 이용하느냐다.문서 전체에서, 그것은 실제로 다소 극적인 과속방지턱일 수 있다.—DJ (대화 • 기여) 2009년 12월 2일 (UTC) 15:31, 2

이 지글거리는 모든 것들은 우리가 사용하는 도서관인 jQuery의 일부분이다.오래된 브라우저에서는 속도가 느릴 수 있지만, 어떤 버기 동작이 일어날 수 있는지 모르겠다.이것을 묘사해 주시겠습니까? --Catrope 20:37, 2009년 12월 3일 (UTC) —Catrope가 추가한 서명되지 않은 코멘트 작성 (토크 • 기여)

키보드/문자 질문

토론 페이지에 rfc를 입력하려고 하는 중.내 오래된 키보드에는 없는 verticle 직선이 필요한 것 같아.다른 캐릭터는 대체 가능한가?—Tapred가 추가한 서명되지 않은 의견 준비 (대화 • 기여) 07:27, 2009년 12월 2일 (UTC)

정말 없는 거야?백슬래시와 같은 키에 있어야 한다.\Shift 키를 누른 상태에서만).다른 국가별 레이아웃을 사용하고 있다면 영어 자판 배열을 사용해 본 적이 있는가?최후의 수단으로, 당신은 항상 그것을 어디선가 복사할 수 있다(예: 여기: ) 또한 정확히 필요한 것이 무엇인가에 따라 끈으로 대체할 수도 있다.{{subst:!}}. Svick (대화) 09:06, 2009년 12월 2일 (UTC)

나의 비교적 새로운 HP 키보드에는 배관 기호도 부족하다(내 백슬래시 키 시프트 옵션은 '?'이다). 매번 잘라서 붙여넣어야 하고, 많이 사용한다.나를 미치게 한다. --Jezebel's Ponyo^shhh 15:41, 2009년 12월 2일 (UTC)

누구에게도 모욕을 주려는 것이 없이, "파이프" 문자는 보통 끊어진 수직선으로 표시되고, 여기에 표시되는 것처럼 단단한 선이 아니다.표준 키보드에서 "?" 문자는 SHIFT+/(백슬래시가 아닌 슬래시).백슬래시 문자는 "\"이다."파이프" 문자는 SHIFT+\이다.맛있는 카르분클 (토크) 2009년 12월 2일 16:11, 2 (UTC)

항상 그런 것은 아니다. 내 Dell kbd는 파이프에 대한 견고한 선을 가지고 있다.어쨌든, 아직도 못 찾겠으면 이렇게 해 봐.편집 창과 "페이지 저장" 버튼 아래에는 "삽입"으로 기본 설정되는 작은 풀다운 메뉴가 있다.다음 중 하나를 선택하십시오.

• 생산해야 할 "위키 마크업"{{}} {{{}}} [] [[]]그리고 더 많은 것.파이프 기호는 3-곡선형 대괄호와 1-제곱 대괄호 사이에 있다.
• 생산해야 할 "심볼스"~ ¡ ¿ † ‡그리고 더 많은 것.파이프 기호는 두 번째(틸드와 거꾸로 된 느낌표 사이)이다.

파이프 중 하나를 클릭하면 커서 위치에 파이프가 삽입된다. --Redrose64(토크) 16:17, 2009년 12월 2일(UTC)

'reftools' 가젯을 활성화하면 편집 상자 하단에 있는 내 삽입 메뉴가 비활성화되었다.아무튼 맛있는 카르분클은 내 키보드에 있는 파이프 캐릭터가 존재한다고 지적했지만, 그 캐릭터가 끊어진 선으로 나타나서 내가 그것을 간과하게 되었다.도움에 감사드리며, 어떤 광기로부터 이 편집자를 구해주셨습니다. --제즈벨의 포뇨^shhh 16:37, 2009년 12월 2일 (UTC)

(ec) 상기 메뉴에서 또 다른 것을 발견했다: "IPA"를 선택하면 다음 항목으로 마감되는 많은 항목이 생성된다.˩ ꜛ ꜜ ‖ ↗ ↘ k͈ s͎ {{IPA }}. 파이프 기호는 더블 바와 대각선 화살표 2개 바로 앞에 있다. --Redrose64 (토크) 16:41, 2009년 12월 2일 (UTC)

첫째, 모든 도움과 유익한 토론에 감사한다.그것은 키에 있는 기만적인 기호에도 불구하고 역슬래시를 넘어서는 캐릭터다.애플 제품도 같은가?나는 이것을 발견하기 전에 복사해서 붙여넣었다.다시 한번 위키피디아 사람들에게 고마워!테이퍼(토크) 22:19, 2009년 12월 3일 (UTC)

CIDR 범위에 대한 로그를 차단하시겠습니까?

IP별 IP와 달리 전체 CIDR 범위에 대한 블록 로그를 볼 수 있는 방법이 있는가?고마워요.—Zach425 /기여 18:19, 2009년 12월 2일 (UTC)

그럼, Special(특수)으로 이동하십시오.로그/차단하고 (결과)를 입력하십시오.이 범위에서 모든 개별 IP 블록을 검색하는 것에 대해 묻는 경우, 아니요.— AlexSm 19:18, 2009년 12월 2일 (UTC)

좋은 지적이야, 그건 좀 애매했어.특정 범위의 개별 IP 블록을 검색하는 것이 궁금했다.실망스러운 답변이지만 제공해줘서 고마워.—Zach425^talk/농가 02:26, 2009년 12월 3일 (UTC)

위키백과를 살펴보십시오.관리자_noticeboard#New_tools 두 가지 도구가 있다.모든 현재 블록에 대해 하나씩, 전체 블록 로그에 대해 하나씩.즐기다. β^_command 08:59, 2009년 12월 3일 (UTC)

그게 바로 내가 찾던 거야.정말 고마워!—Zach425 /기존 17:48, 2009년 12월 3일 (UTC)

범주의 임의 문서

어떤 범주에서 무작위로 기사를 고른 도구가 위키백과를 유지하는데 유용할 것이라고 생각한다.현재 몇 가지 하우스키핑 카테고리가 있다. 예: 카테고리:참조되지 않은 BLP. 항목 수가 많고 많은 페이지를 채우는 BLP.약간의 시간을 정리하는데 쓰고 싶은 편집자는, 시작하기 좋은 장소를 찾기 위해 일을 해야 한다.범주 내 임의 문서 위젯은 이러한 범주 페이지 또는 정리 작업을 나열하는 페이지에 추가될 수 있다.시행하는 것은 어렵지 않을 것이고 나는 그것이 청소 일을 더 즐겁게 할 것이고 따라서 절실히 필요한 일에 더 많은 노력을 기울일 것이라고 생각한다.--농업 (토크) 22:20, 2009년 12월 2일 (UTC)

툴서버에서 임의의 기사도구를 사용할 수 있다.Svick (대화) 22:37, 2009년 12월 2일 (UTC)

고마워, 그 도구는 내가 원하는 것을 많이 하는 것 같아. 정말 어려운 것 같아.하지만 위키피디아 페이지에 삽입되어 있을 때 외부 연결고리로 나타나기엔 좀 어색하다.이 링크를 사용하여 다음 범주에 링크를 추가했다.참조되지 않은 BLP.나는 카테고리에 나열된 모든 카테고리에 대해 그와 같은 임의의 기사 링크가 있어야 한다고 생각한다.위키백과 백로그 또는 WP:백로그 랜덤 페이지좀 더 쉬운 방법이 있으면 좋겠다.-농업 (대화) 18:02, 2009년 12월 3일 (UTC)

기사 알프레드 드 그라치아

아미데그 2009년 12월 1일, 나는 위에 언급된 기사에 대한 수정과 참조를 추가했다.모든 편집과 참고문헌은 ItsmeJudith라는 편집자가 30분도 채 지나지 않아 삭제했다.오늘, 12월 3일, 나는 12월 1일에 대한 나의 편집과 언급이 기사의 역사 페이지에 더 이상 나타나지 않고, Itsme Judith가 삭제한 흔적도 없다는 것을 알았다.이게 어떻게 가능하지?아미데그 (대화) 15:04, 2009년 12월 3일 (UTC)

기사의 이력서에 기재된 당신의 편집은 여전히 거기에 있는 것처럼 보이지만, 그것들은 되돌아갔다.또한 편집 요약에서 귀하를 되돌린 편집자가 귀하가 남긴 이유를 설명하고 귀하의 토크 페이지에서도 귀하에게 연락한 것을 볼 수 있을 것이다(자신의 토크 페이지는 사용자 토크:아직 찾지 못했다면 아미데그(Amideg).다른 사람이 제거한 자료를 계속 재첨부하지 않는 것이 최선이다.추가한 내용이 제거된 경우 삭제한 사람에게 물어보거나 기사 대화 페이지에서 물어보십시오(Talk:알프레드 드 그라치아) 정보 및 조언.행운을 빈다!⬅ ❝Redvers❞ 15:16, 2009년 12월 3일 (UTC)

Kingbotk 플러그인에 필요한 도움말

안녕. 여기 VB 아는 사람 있어? 킹보텍 플러그 인에 도움이 될 수 있어.위키피디아 토크당 AWB의 새로운 구축에 대한 스펙은 통하지 않는다.AutoWikiBrowser/Bugs#Kingbotk 플러그인이 SVN 버전에서 평가되지 않음고마워요.숨기기 T 17:28, 2009년 12월 3일 (UTC)

나는 플러그인과 함께 일할 재능 있는 프로그래머가 필요하다는 이 요청을 지지하고 싶다.–xeno^talk 17:38, 2009년 12월 3일(UTC)

RfC 질문

방금 내 첫 RfC를 올렸어.나는 두 가지 카테고리를 열거했다.1차 카테고리 목록에만 등장했다.기사는 이 범주에 속하지만, 문제의 문제에 대해서는 두 번째 범주가 아마도 더 목적적합하고 코멘트를 이끌어낼 가능성이 높다.

질문: 첫 번째 범주만 해당 목록을 자동으로 게시하는가?그렇다면 두 번째 리스트에 올릴 방법이 있을까?만약 그렇지 않다면, 보다 관련성이 높은 리스트에 게시하기 위해 리스트 순서를 뒤집는 것이 허용될 수 있는가?삭제하고 다시 시작해야 하는가?

테이퍼(토크) 22:33, 2009년 12월 3일 (UTC)

가이드 WP:RFC가 그러는데 한 번 써봐.{{rfctag}}RfC를 더 많은 범주에 나열할 수 있는 여러 매개변수Rfc에 있는 s를 이런 식으로 병합했으니까 RFC 봇이 알아낼 수 있길 바라네그렇지 않은 경우 RfC를 두 번째 범주에 수동으로 추가할 수 있지만, RfC가 종료된 후에는 반드시 제거하십시오.Svick (대화) 00:43, 2009년 12월 4일 (UTC)

고마워 이제 알겠어나의 성급한 독서와 그것이 삽화되어 있는 방식 때문에 나는 내가 올바른 방법으로 그것을 했다고 믿게 되었다.다시 한번 고마워. 69.226.245.37 (대화) 04:40, 2009년 12월 4일 (UTC)

고정되었지만 감시 목록에 나타나지 않는 편집 또는 기여 목록 또는 이력

또 눈치챈 사람 있어?YellowMonkey (Bananabucket) (Invincibles Features 주제 드라이브: 1개 왼쪽) 01:05, 2009년 12월 4일 (UTC)

예, 삭제도 마찬가지 - 현재 서버 지연 시간이 12분인 것 같음 - Peripitus(Talk) 01:22, 2009년 12월 4일(UTC)

나 역시 이것을 보았지만, 그것은 스스로 교정하고 있는 것처럼 보인다.데이터베이스와 웹 캐시가 지연된 것 같아?Sam Barsoom 01:26, 2009년 12월 4일 (UTC)

이것은 실제로 현재 나에게 일어나고 있다.애니메이트 03:30, 2009년 12월 4일 (UTC)

알려진 바로는, 똑똑한 사람들이 그것을 보고 있다는 것이다.복제가 다시 내려오면 좋아질 거야Q 03:37, 2009년 12월 4일 (UTC)

새 메시지 표시줄이 사라지지 않음

몇 분 전에 로그인했는데 화면에 "새로운 메시지" 오렌지색 바가 나타나는 것을 봤어.링크를 클릭하고 내 토크 페이지로 이동한 다음 내 워치리스트를 클릭했지만, 내 토크 페이지에서 클릭했을 때 오렌지 바가 사라지지 않았고, 바로 이 편집 화면에서 바는 여전히 남아 있는 메시지를 쓰고 있다.이 문제는 로그아웃, 브라우저 닫기 및 다시 열기, 다시 로그인한 후에도 계속된다.제거하는 방법 아는 사람 있어?캐시를 제거 및 바이패스했으며 Windows XP에서 Firefox 3을 사용하고 있다.고마워, Dabomb87 (토크) 01:06, 2009년 12월 4일 (UTC)

OK, 추가 조사 결과, 높은 서버 지연의 결과인 것 같다(이 의견 기준 12분 이상).Dabomb87 (대화) 01:13, 2009년 12월 4일 (UTC)

아마도 위의 스레드의 문제와 관련이 있을 것이다.Sam Barsoom 01:27, 2009년 12월 4일 (UTC)

새 문서가 나타나지 않음

11월 22일 나는 해리 H. 할셀에 대한 새로운 기사를 제출했지만, 오늘부로 그것은 검색에 나타나지 않으며, 이 주제에 대한 기존의 링크(예: 그레이스 할셀에 관한 기사에서 찾을 수 있는 것)도 그것이 존재한다는 것을 나타내지 않는다.그 기사는 내가 낸 기고 아래 나타나긴 하지만 일반 대중은 이용할 수 없을 것 같다.내가 알 수 있는 한, 나는 제출을 위한 지침을 따랐고, 그것이 왜 나타나지 않는지를 나타내는 것을 도움말 파일에서 아무것도 발견하지 못했다.무슨 일인가? —제논456호에 의해 추가된 서명되지 않은 논평 준비 (대화 • 기여) 04:09, 2009년 12월 4일 (UTC)

안녕 제논.이 기사는 사용자:Xenon456/Harry H. Halsell에서 사용자 공간의 하위 페이지로 작성되어 몇 분 전까지 존재했다.기사가 상주하는 메인스페이스에 갖기 위해서는 해리 H. 할셀로 옮겨야 했다.나는 너를 위해 그렇게 했다.건배.---Fuhgetaboutit (대화) 04:18, 2009년 12월 4일 (UTC)

범주:리디렉션

네, 그것은 존재한다...하지만 지속할 수 없는 일이니까 그걸 갖는다는 건 정말 의미가 없어...범주가 소프트웨어에 의해 자동으로 추가되는 경우는 제외한다.이는 예를 들어 카테고리:색인된 페이지 없음.그러나 이는 메인 스페이스의 리디렉션에만 해당되어야 한다. 또는 각 네임스페이스에 대한 리디렉션 범주가 있어야 한다.그럼 적어도 메인 스페이스는 버질라에서 요청해야 한다고 생각해?세나륨 (토크) 00:02, 2009년 11월 9일 (UTC)

새로운 특수 페이지(특별 페이지:Alredirects) 또는 Special:모든 페이지가 좋을 것이다.Mr.Z-man 03:51, 2009년 11월 9일 (UTC)

이게 왜 필요한 거지?분류하기 위한 분류인 것 같다(그리고 내가 볼 때 특수 페이지도 마찬가지로 무의미할 것이다).그러나 만약 사람들이 그것을 어느 정도 사용할 수 있다면, 그 특별한 페이지는 자동으로 생성된 카테고리보다 소프트웨어가 보통 하는 것과 더 일치하는 것처럼 보인다.-Kotniski (토크) 07:52, 2009년 11월 9일 (UTC)

나도 개인적으로 그런 범주의 요점을 잘 모르겠다; 비록 몇몇 사람들은 그것이 만들어졌기 때문에 유용하다고 생각할지도 모른다.특수:모든 페이지에는 리디렉션을 제외할 수 있는 방법이 분명히 있어야 하며, 또한 비리디렉션을 제외할 수 있어야 한다.세나륨 (토크) 18:55, 2009년 11월 9일 (UTC)

목적 중 하나는 카테고리를 포함하여 다양한 종류의 리디렉션을 추적하는 것이다.인쇄할 수 없는 리디렉션, 카테고리:보호된 리디렉션 및 범주:위키피디아 소프트 리디렉션, 모든 중요한 정보 보유.또한 내가 알 수 있는 한 잘 정비되어 있다.관리가 불가능하고 아무 소용이 없는 루트 카테고리를 자동으로 채우는 것이다.OrangeDog(오렌지독) 2009년 11월 9일 (UTC) 20:16, 9:16

카테고리 페이지에는 카테고리가 리디렉션에 대한 카테고리 및 페이지만 포함하며 리디렉션 자체를 포함해서는 안 된다고 명시되어 있다.그러나 현재 범주에 있는 1046페이지 중 953페이지가 리디렉션되어 있다.범주에서 봇을 쉽게 실행할 수 있어서 "[카테고리:모든 리디렉션에서 [Redirects]]"를 선택한 다음 정기적으로 반복하여 청결 상태를 유지하십시오.Anomie⚔ 22:08, 2009년 11월 9일 (UTC)

글쎄, 찬성할 수 있겠네.--코트니스키 (대화) 09:42, 2009년 11월 10일 (UTC)

자동 분류와 관계없이 제거해야 하며, 수동으로 제거할 수 없다.세나륨 (대화) 04:28, 2009년 11월 11일 (UTC)

놀라운 카테고리를 삭제하기 위해 후보자로 지명했다.범주화되지 않은 리디렉션.세나륨 (대화) 00:38, 2009년 11월 15일 (UTC)

리디렉션 자동 분류에서 몇 가지 이점을 발견했는데, 우리는 리디렉션에 대한 최근의 변경 사항을 볼 수 있고, 카테고리 페이지에서 자주 혼란스러워하는 신규/미취업자 사용자들을 위한 링크를 제공하며, T20596이 해결되면 인터페이스에서 페이지가 리디렉션인지 알 수 있을 것이다(따라서 리디렉션에 대한 편집, 유용한 fo).r 새로운 사용자).세나륨 (대화) 04:28, 2009년 11월 11일 (UTC)

따라서 이에 비추어, 우리는 이것을 요청해야 하지 않을까? 세나륨 (영구) 16:25, 2009년 11월 13일 (UTC)

좋아, 몇몇의 리디렉션 카테고리는 유용하다 - "가능성이 있는" 것이 생각나는 것이다.따라서 해당 범주에 있는지 확인하기 위해 모든 리디렉션을 선별하는 것도 유용하다."분류되지 않은 범주"의 사용은 "재연결" 범주와 마찬가지로 그렇게 하는 방법이다.Rich Farmbrough, 21:50, 2009년 11월 15일 (UTC)

BAG는 어떤 봇도 Category를 추가할 수 없다는 것을 잘 알고 있을 것이다.분류되지 않은 리디렉션은 수백만 개의 리디렉션으로 리디렉션되는데, 수천 개의 리디렉션만 있는 리디렉션을 갖는 이유가 무엇인가?봇은 카테고리를 추가할 때 데이터베이스를 직접 확인해야 하며, 리디렉션에 다른 카테고리가 있는지 여부는 중요하지 않다.'가능성이 있는 범주'(나는 그것이 유용할 수 있다는 것에 동의한다)와 같은 범주는 오직 사례별로 인간에 의해서만 추가될 수 있는데, 당신이 리디렉션을 건너뛸 때, 그들을 위해 범주를 선별하는 것은 힘든 작업이 될 것이다.

그러나, 내가 말했듯이, 나는 소프트웨어가 자동으로 카테고리:를 추가하도록 하는 것에 찬성할 것이다.메인 스페이스 리디렉션으로 리디렉션(리디렉션에 대한 범주는 'Wipedia의 리디렉션'으로 이름을 바꿀 수 있다.왜냐하면, 최근 리디렉션에 대한 변경사항을 볼 수 있고, 카테고리 링크가 T20596을 통해 혼란스러운 새 사용자를 돕기 위해 편리하기 때문에, 페이지가 리디렉션인지 여부를 (적어도 인터페이스에서) 알 수 있을 것이고, 봇과 자동화된 스크립트에 도움이 될 수 있을 것이다.세나륨 (대화) 22:10, 2009년 11월 15일 (UTC)

이 말은 아마 좀 늦었을 것이다. 하지만 우리는 특별한 것을 가지고 있다.ListRedirects.Intelligentsium 00:31, 2009년 11월 17일(UTC)

이것은 괜찮지만 카테고리가 가질 수 있는 이점을 제공하지 않는다.세나륨 (대화) 2009년 11월 20일 16:27, (UTC)

이 범주의 이름은 Category로 지정되어야 하지 않는가?위키백과 리디렉션(리디렉션에 대한 페이지, 분명히 프로젝트 관련 범주를 포함하므로) — 76.66.197.2 (토크) 04:25, 2009년 11월 21일 (UTC)에 의해 추가된 서명되지 않은 코멘트 준비

네, 그 이름은 바뀌어야죠.그러나 Category는 다음과 같은 경우가 거의 없다.리디렉션은 콘텐츠에 사용되며, 자동 분류되는 경우 리디렉션에 사용할 수 있다.세나륨 (대화) 00:48, 2009년 11월 28일 (UTC)

리디렉션 자동 범주화

원래의 시점으로 돌아가면 메인 스페이스의 모든 리디렉션은 자동으로 범주(예: 색인되지 않은 페이지)로 분류되도록 bugzilla에서 요청할 것인가?리디렉션 ?다음과 같은 몇 가지 이점을 제공할 수 있다.

1. 자동화된 프로세스에 대한 리디렉션을 탐지하고 선별하는 방법 제공
2. (관련 변경을 통해) 리디렉션에 대한 최근 변경 내용 보기 허용
3. 리디렉션으로 인해 때때로 혼동되는 새로운 사용자에게 링크를 제공하십시오.
4. T20596이 해결되면 모든 리디렉션에 대해 편집 알림을 사용할 수 있음(다시, 새로운 사용자에게 유용함)

세나륨 (대화) 22:27, 2009년 11월 28일 (UTC)

좋아, 15분 정도 시간을 낼 수 있으면 좋겠네리디렉션 플래그가 이미 데이터베이스에 부울 열로 저장되어 있음(page.page_is_redirect() 따라서 이것은 인치여야 한다. — 이, 저, 그리고 다른 (대화) 06:37, 2009년 11월 29일 (UTC)

그럴 경우, 좋은 것 같다(한 가지 이유로 편집 공지를 활성화하는 것이 좋다).WP에 버그 파일 및 목록 작성:데브메모.Rd232 06:43, 2009년 12월 5일(UTC)

CSD F3 업로드

여기가 이 토론을 시작하기에 적절한 장소인지는 모르겠지만...업로드할 때 태그가 즉시 지정된 파일을 업로드할 때 이 파일의 비상업적 또는 교육적 사용만이 허용되는 제한(& F3 템플릿 추가)이 가능한가? 즉, 동일한 경고 템플릿이 업로더의 토크 페이지에 배치되는 것이 가능한가?보통 파일들은 매우 빨리 삭제되기 때문에, 나는 이것이 봇 가치가 있다고 생각하지 않는다.그 이유는 업로더가 이 경고를 읽지 않는 경우가 많고, 이미지/파일이 삭제된 이유를 설명할 때 다른 사용자(관리자)가 경고 메시지를 반복할 수밖에 없기 때문이다.제안이요?스키어 듀 (토크) 04:08, 2009년 12월 2일 (UTC)

이렇게 하지 않는가? —DJ (대화 • 기여) 12:01, 2009년 12월 2일 (UTC)

당신이 "저작권 소유자가 나에게 WP에서만 [이것]을 사용할 수 있는 허가를 주었다"를 선택하면, 할당된 저작권 태그는 빠른 템플릿이다.(특별 참조:업로드 및 라이센스 미리보기 기능.) MER-C 03:58, 2009년 12월 3일(UTC)

정확히 - 이 옵션이 선택되었을 때, 이미지 설명 페이지에 있는 것과 동일한 메시지가 업로더의 대화 페이지에도 배치되는 것이 가능한가?스키어 듀 (토크) 08:03, 2009년 12월 4일 (UTC)

과거에 "새로운" 기사가 삭제되었는지 확인하는 방법

새로 만든 페이지가 이전에 삭제되었는지 확인할 수 있는 방법을 찾고 있어.그러한 특권은 단순한 인간(또는 롤백자나 자동 확인자 등)에게만 있는 것인가.대기 중인 것으로 보이는 페이지 뷰 삭제에 대한 논의가 있었구나.-RadioFan (토크) 21:06, 2009년 12월 3일 (UTC)

기사의 내역으로 가면 상단에 "이 페이지에 대한 모든 로그 보기"라는 링크가 나타난다.여기서 삭제를 포함하여 기록된 모든 작업을 볼 수 있다. — Edokter • Talk • 21:16, 2009년 12월 3일 (UTC)

그러나, 불행하게도, 기사를 처음 만든 사람의 사용자 이름은 아니다.그것은 매우 유용할 것이다. 99.166.95.142 (대화) 16:44, 2009년 12월 4일 (UTC)

당신은 존재하지도 않고 AFAIK에 요청하지도 않은 로그 이벤트 'create'가 필요할 것이다. 하지만 나는 그것이 이미 어딘가에서 논의되었다고 확신한다.나는 그것이 유용할 것이라는 것에 동의한다.그러나 로그는 여전히 네임스페이스로 필터링할 수 없다.세나륨 (토크) 23:15, 2009년 12월 4일 (UTC)

하위 페이지가 아닌 기본 페이지만 검색 중

예를 들어 접두사를 검색하고자 함:위키백과:중재/요청뿐 아니라 하위 페이지, "워크샵" "증거" 등이 아닌 메인 페이지(아브컴 결정이 내려진 곳)만 해당된다.

가능할까요?

예를 들어 Arbcom이 가장 좋아하는 "decorum"이라는 단어를 찾는다고 하자.

감사합니다.이킵 (토크) 21:38, 2009년 12월 3일 (UTC)

아니, 그 페이지는 완전히 착각된 (하위) 페이지들로 만들어졌고, 내부 검색엔진이 그것을 해결해주지 않기 때문이다.우리가 단일 페이지 검색을 지원하지 않았더라도, 당신은 브라우저에서 그것을 할 수 있고, 한 페이지를 가져온 다음 그 위에 grep을 하는 두 줄의 대본을 쓸 수 있다.반면 여러 하위 페이지를 함께 검색하려면 접두사:prefix1 접두사2 접두사3. --rainman(토크) 11:13, 2009년 12월 4일(UTC)과 같은 구문을 사용할 수 있다.

충분히 확실하지 않았어. 미안해.나는 최종 아르브콤 결정이 내려진 페이지에서만 검색하고 싶다.따라서 이 페이지와 다른 모든 최종 결정 페이지에 특정 용어가 있는지 검색하고자 한다.

위키백과:중재/요청/케이스/A_Man_In_Black

위키백과:중재/요청/사례/194x144x90x118

위키백과:중재/요청/사례/경과_Pacifist_2

그러나 다음과 같은 사례의 하위 페이지는 아니다.

위키백과:중재/요청/사례/유효_Pacifist_2/증거

위키백과:중재/요청/사례/경과_Pacifist_2/작업장

위키백과:중재/요청/사례/유효_Pacifist_2/제안_결정

어쩌면 그게 더 명확할 수도 있어, 그게 가능해?Ikip (토크) 17:09, 2009년 12월 4일 (UTC)

불행히도 그렇지 않다. --rainman (대화) 17:24, 2009년 12월 4일 (UTC)

AWB? 이상적이지는 않지만 할 수 있다(특히 일회용이라면). - Jarry1250^{[Humorous? Discuss.]} 20:52, 2009년 12월 4일(UTC)

여러분, 이렇게 도움을 주셔서 감사하다.나는 AWB를 조사할 것이다.이킵 (토크) 06:20, 2009년 12월 5일 (UTC)

위키백과 비용절감을 위한 전문가 포럼

위키백과의 비용을 줄이기 위한 새로운 아이디어나 기술적 해결책을 찾기 위한 전문가 포럼을 만드는 것은 어떨까?

이것을 하기 위해서는 먼저 위키백과의 비용을 어떻게 구성하는지 알아야 한다.
그리고 전문가들이 새로운 해결책을 찾기 위해 아이디어를 쓰고 다른 전문가들을 부러워해야 했다.

우리는 다음과 같은 일반적인 issi를 만들 수 있다.

- 에너지 소비 절감 방법
- CPU 사용량을 줄이는 방법
- 서버 CPU 대신 온라인 사용자의 CPU 사용 방법(가능한 경우)
- 밴드 사용 줄이기 방법
- 캐싱을 개선하는 방법
- 사용자가 다운로드한 총 바이트 수를 줄이는 방법
- 어떻게 등....

위키백과의 유지 비용에 대한 정보를 게시할 수 있는 사람이 있는가?—87.4.249.168 (대화) 11:15, 2009년 12월 4일 (UTC)에 의해 서명되지 않은 의견 추가 준비

비록 그 생각에 박수를 보내지만, 나는 몇 가지를 지적해야 한다.

1. 우리는 아이디어가 풍부하다.우리의 제한적인 요소인 ATM은 자원이다.존재하는 모든 아이디어는 http://strategy.wikimedia.org을 참조하십시오.
2. 기술적으로 현명한 일이지만, 우리는 이미 상위 10개 웹사이트의 다른 많은 웹사이트들보다 훨씬 더 효율적으로 운영되고 있을 것이다.이것은 한정된 자원을 가진 직접적인 결과물이다.그것 때문에 모든 것을 최대한으로 써야 해.
3. 내가 정확히 기억한다면 하드웨어와 atm으로 연간 300만 달러 정도의 예산이 든다.내년에 500만 달러 정도 될 것 같은 기부금 등에 따라.가장 큰 혜택은 아마도 소프트웨어를 더 최적화함으로써 만들어질 수 있지만, 그렇게 하려면 많은 인력과 직원이 필요하다.

—DJ (대화 • 기여) 11:35, 2009년 12월 4일 (UTC)

87.4.249.1987. 기존의 메일링 목록인 위키텍-l을 사용해 보십시오.{{Nihiltres talk edits}}}15:23, 2009년 12월 4일 (UTC)

DevMemo 응답 대기 중

WP:DevMemo for 2009년 11월 (Wikipedia:MediaWiki/DeveloperMemo/2009년 11월)는 현재 폐쇄되어 개발자들의 응답을 기다리고 있다. (다음은 위키백과:MediaWiki/DeveloperMemo/2009년 12월 현재 이전 이슈와 함께 시드되어 초안을 작성 중이다.)누군가 개발자에게 메모를 통지하고 11월 메모에 응답하도록 요청해 주시겠습니까?고마워요.Rd232 19:54, 2009년 12월 4일(UTC)

리디렉션 자동 범주화

리디렉션의 자동 범주화에 대해 더 많은 정보를 얻을 수 있는가? 사이트 요청에 더 많은 지원이 필요할 것이다.고마워, 세나리움 (토크) 23:19, 2009년 12월 4일 (UTC)

AWB에서 regex 참조는 어떻게 작동하는가?

(IRC에 대한 도움을 좀 찾으려고 했는데, 지금 당장 받을 수 있는 사람이 없는 것 같다.

나는 교체하려고 한다.

[http://www.sclegacy.com/encyclopedia/starcraft_story.php#(\S+) Transcript]

와 함께

[http://web.archive.org/web/20040810213217/http://www.sclegacy.com/encyclopedia/starcraft_story.php#$1 Transcript] (Archived from [http://www.sclegacy.com/encyclopedia/starcraft_story.php#$1 the original] on 2004-10-08)

기본적으로, web.archive.org 링크를 데드 링크의 전면에 고정하고, 원래의 후크에 있던 닻을 보존하기 위해 백레퍼런스를 사용한다. rʨanaɢ _contribs/ 23:29, 2009년 12월 4일 (UTC)

구체적으로 아무것도 묻지 않았으니, 이 regexp를 작동시키길 원하는 것 같군.네모난 괄호만 벗어나면 돼

\[http://www.sclegacy.com/encyclopedia/starcraft_story.php#(\S+] 성적증명서\

교체는 괜찮다.Svick (대화) 00:16, 2009년 12월 5일 (UTC)

고마워! 그거 고쳤어. (내가 전에 시험해봤을 때, 반복적으로 자기 자신을 교체했었어. 탈출하지 않은 괄호 때문에 그런 것 같아.)Best, rʨanaɢ _contribs/ 00:41, 2009년 12월 5일 (UTC)

보안 서버

보안 서버를 설명하는 페이지를 작성했다.위키백과:보안 서버.나는 영어를 모국어로 하는 사람과 기술적으로 고쳐야 할 것이 있는지 확인해 주었으면 한다. (나는 영어를 모국어로 하는 사람이 아니다.)그리고 나는 그것의 토크 페이지에 있는 초보자들의 질문을 좋아한다. 왜냐하면 우리는 그 페이지의 어떤 부분이 불분명한지 알 수 있기 때문이다.

보안 서버에 대한 문서가 어디에도 없는 것 같아서 페이지를 만들었어.나는 모든 위키미디어 프로젝트의 영어판을 검색했다.

페이지가 준비되었다고 생각되면 보안 서버 로그인 페이지에서 해당 페이지에 링크를 추가하려고 한다.MediaWiki talk:를 참조하십시오.Loginend#코드의 브러시업.

--David Göthberg (대화) 15:59, 2009년 12월 3일 (UTC)

로그인 페이지 변경 사항

우리는 또한 로그인 페이지에 대한 몇 가지 다른 변경도 하고 있다.MediaWiki talk:를 참조하십시오.Loginend#코드의 정리. (위 절에서 그 부분을 언급하는 것을 잊었다.)

--David Göthberg (대화) 09:11, 2009년 12월 5일 (UTC)

[새로운 간헐적 문제?]주석을 저장하면 다른 사람이 삭제됨(충돌 경고 편집 없음)

댓글을 저장하면 이전에 저장한 댓글이 삭제되는 경우를 두 번 봤다.저장 편집자 두 명 모두 "상충 편집" (또는 어떤 문제의 통지)을 받지 못했다고 표시한다.두 사람 모두 그들의 (의도하지 않은) 삭제 내용이 눈에 띄자 당황하고 사과했다.

내가 본 두 가지 차이점.

• 토크: 로만 폴란스키(아래에 있는 코멘트는 덧셈이었다.다른 편집자에 의한 국기 변경은 의도치 않게 취소되었으며, 이전의 논평도 마찬가지였습니다.

• AfD(다른 사람의 의견을 의도하지 않게 삭제한 경우 특히 불행한 장소)

새로운 문제?교정자77 (대화) 22:09, 2009년 12월 3일 (UTC)

이것은 내가 다른 미디어위키 위키에서도 경험한 아주 오래된 버그다.나는 그 벌레의 성질을 모르지만, 그것이 흔하지 않고 오랫동안 일어나고 있다는 것은 알고 있다.나는 의도하지 않은 경주 조건이 있다고 생각한다.Sam Barsoom 01:28, 2009년 12월 4일 (UTC)

감사합니다, 여러분.아마도 일시적인 기술적 결함이 있는 것이 좋을 것이다... 그래서 우리는 항상 동기(예를 들어 누군가가 우리의 메시지를 삭제함으로써 비열한 행동을 했다는 것)에 대한 결론에 도달하기 전에 잠시 멈춰있을 수 있다.프로그램은 결코 완벽하지 않다.그러나 우리는 그 소프트웨어가 결코 실패하지 않는다고 믿게 된다. (컴프 사이언스에 MS학위를 가진 학생들도)블러셔.)교정자77 (대화) 07:36, 2009년 12월 4일 (UTC)

이 편집자들은 우연히 위키피디아에 있는 오래된 버전의 페이지를 편집했을지도 모른다.증거를 보려면 예제를 두 번 클릭하여 이전 편집을 클릭하십시오.그들은 이전 버전의 페이지를 편집하는 것에 대한 경고를 받아야 한다.심지어 짐보 웨일즈조차도 이런 실수를 한 적이 있다 - 그것은 드문 일이 아니다.Graham87 14:36, 2009년 12월 5일 (UTC)

고마워, 그레이엄.나는 그런 가능성을 생각하지 못했었다.(옛 버전을 편집했을 때는 항상 의도적으로 반달리즘을 되돌리는 것이었는데...이제 어떻게 하면 우연히 그곳에 도달할 수 있을지 곰곰이 생각해 볼 것이다. 하지만 분명히 할 수 있다. :-) 건배.교정자77 (대화) 15:48, 2009년 12월 5일 (UTC)

템플릿 도움말 찾기

해결됨

– rʨanaɢ _contribs/ 15:45, 2009년 12월 5일 (UTC)

얼마 전 {{산지수 행}}}을 만들어 산악세트지수 기사를 위한 테이블을 만드는 데 도움을 주었다.그러나, 템플릿이 깨졌고, 간헐적으로 가짜 마차 반환을 방출한다.예를 들어, 곰 산이라는 이름을 가진 봉우리 목록을 참조하십시오.

템플릿 전문가가 이 템플릿을 수정하는 데 도움을 줄 수 있는가?나는 이것에 대해 오랫동안 어리둥절했다.템플릿 토크에서 응답하십시오.산악 인덱스 행(템플릿 기록 링크 감시 로그 편집).고마워!!—hike395 (대화) 04:33, 2009년 12월 5일 (UTC)

인용 스타일

WP:PUNC는 타이프라이터/직선 아포스트로피와 인용문(' 및 "")을 사용하고, 타이포그래픽/커리 아포스트로피와 인용문(" 및 "")을 사용하지 말 것을 말한다.그러나 편집 창과 "페이지 저장" 버튼 아래 삽입 메뉴는 다음과 같이 시작한다.

– — ‘’ “” ° ″ ′ ≈

내가 틀렸다면 고쳐줘, 하지만 여기 있는 세 번째와 네 번째 클릭 가능한 아이템은 곱슬 아포스트로피와 인용문처럼 끔찍하게 보인다. --Redrose64 (토크) 15:23, 2009년 12월 5일 (UTC)

WP:FUNC는 정상적인 글쓰기에 그것들을 사용하지 않는 것이 그것들이 절대 사용되어서는 안 된다는 것을 의미하지 않는다고 말한다.예를 들어, 구두점에 관한 기사를 쓰거나 방금 쓴 바로 그 메시지를 쓰려면 곱슬곱슬한 아포스트로피와 인용구가 필요할 것이다.rʨanaɢ _contribs/ 16:56, 2009년 12월 5일 (UTC)

미디어위키:Editdools.js 및 MediaWiki:에디툴스.MOS에서 사용되지 않는 글리프 포함에 대한 자세한 내용은 토크 페이지를 참조하십시오. ---— Gadget850 (Ed) 22:51, 2009년 12월 5일 (UTC)

최신으로 표시되는 오래된 블록 통지

IP 사용자에 대한 차단 해제 요청을 작업할 때 기여 로그를 확인했더니 페이지 상단에 블록 알림이 보였다.올해 1월 15일에 2주 동안 발행된 블록에서 블록 통보가 온 것을 제외하면 모두 양호하다.벌레인가? -제레미 20:25, 2009년 12월 5일 (UTC)

EDIT) Special도 마찬가지인 것 같다.기여금/207.69.137.22. -제레미 20:29, 2009년 12월 5일(UTC)

위 내용은 최근 다시 차단되었다.

01:16, November 30, 2009, Dominic (talk contribs block) blocked 207.69.136.0/22 (talk) (expires on December 14, 2009 at 01:16, anon. only, account creation blocked) ({{checkuserblock}}) (unblock change block)

상단의 블록 알림은 사용자가 차단되었을 때 여전히 표시되지만 '이전 블록'만 표시되고 현재 블록은 표시되지 않는 것 같다. -- œ^™ 23:04, 2009년 12월 5일(UTC)

문제는, 도미닉이 블록 로그나 기여목록 표제 중 어느 하나에 블록이 있는지 몰랐다는 거야, 레인지블록이었나봐.적어도 기여 페이지 로그에는 범위 블록을 메모하는 것이 좋지 않을까?-제레미 00:53, 2009년 12월 6일 (UTC)

파이어폭스 추락 사고

위키피디아 페이지에 액세스하려고 할 때마다 일반 Firefox 브라우저(버전 1.0, 2004)가 작동 중단된다.무슨 일인지 아는 사람 있어? 설정을 변경해서 고칠 수 있어?(이전에도 물어봤지만 실이 사라진 것 같다.)Fremdh (대화) 16:18, 2009년 12월 4일 (UTC)

Firefox(2004?!)를 업데이트하는 것은 거의 확실히 가치가 있다. 이것은 위키백과 문제뿐만 아니라 나머지 인터넷에도 도움이 될 것이기 때문이다! ╟-TreasuryTag►belonger-16:27, 2009년 12월 4일 (UTC)

나는 얼마 전에 그 실을 보았다 - 그 이후 위키피디아에 보관되었다.마을 펌프(기술)/아카이브 68#화재폭스 충돌(VPT는 주로 시작하는 새 스레드 수 때문에 매우 빠르게 아카이빙됨).그러나 사용자:Fremdh(위, Roop Nagar에게 4가지 기여만 있는 사람)는 IP 사용자 82.31.207.41 (토크) 18:26, 2009년 11월 28일.다른 사용자가 게시한 정보는 해당 스레드를 참조하십시오. 그러나 여기에 추가 의견을 제시하십시오. --Redrose64(대화) 17:45, 2009년 12월 4일(UTC)

모두들 고마워, 하지만 내 질문에 대한 대답을 듣고 싶었어...Fremdh (대화) 11:48, 2009년 12월 5일 (UTC)

우리는 비록...Firefox 1.0은 구식이므로 업그레이드하는 것이 가장 좋다.가장 최근의 것은 3.5.5로 어제 (내 생각에) 공개된 것 같다. --Redrose64 (토크) 14:18, 2009년 12월 5일 (UTC)

상당히 구식인 소프트웨어, 특히 무료 구식 소프트웨어에 대한 문제에 대해 질문할 때, 일반적인 대답은 최신 버전으로 업데이트한 후 다시 시도해 보는 것이다.Mozilla Firefox를 사용하면 현재 버전보다 이전 버전으로 업그레이드가 가능하지만 Windows 95 또는 최신 Firefox 버전 3.5.5(토크)에 문제가 있는 다른 이전 운영 체제에서 실행하지 않는 한(최소한) 이전 버전을 원하는 이유를 알 수 없다. --DThomsen8(토크) 14:25, 2009년 12월 5일(UTC))

봐: 위키피디아는 모든 사람들을 위한 것이어야 해. 단지 그들의 애완 쥐보다 어린 장비와 소프트웨어를 가진 사람들만이 아니야.분명히 아무도 무엇이 문제를 일으켰는지 모른다.나는 이것이 지난 3개월 사이에 스타일시트 변화에 있을 것이라고 생각한다; 나는 이렇게 말한다. 왜냐하면 내가 위키피디아 페이지를 내 사이트로 복사하면 물론 대부분의 장식이 없어도 완벽하게 로딩되기 때문이다.나는 그 변화가 어떤 엄격한 의미에서 필요하다고 생각하지 않는다(여러분 중 위키백과 페이지의 일반적인 서식이 바뀐 것을 눈치채지 못하셨습니까?) 그리고 위키백과는 가능한 한 그러한 땜질하는 것을 피하도록 노력해야 한다고 생각한다.Fremdh (대화) 10:39, 2009년 12월 6일 (UTC)

문제 해결: 차단 자바스크립트.이에 대한 단점도 있지만 나는 그것을 감수할 수 있다 —프레드(토크 • 기여)가 추가한 서명되지 않은 코멘트 준비 (20:24, 2009년 12월 6일 (UTC)

위키피디아는 모든 사람들을 위한 것이어야 하지만, 우리가 <사용자의^source 0.1%>를 위해 구기술을 무한정 지원한다면 소프트웨어 개발을 불필요하게 어렵고 느리게 만드는 것뿐만 아니라, 대다수의 사용자들을 해롭게 하고 있을 것이다.나는 또한 모질라조차도 3.0보다 오래된 파이어폭스의 어떤 버전도 공식적으로 지원하지 않는다는 것을 지적하고 싶다.개인적으로, 나는 사이트가 제대로 작동하지 않는 것보다 잘 알려지지 않은 보안 구멍이 더 걱정된다.Mr.Z-man 21:35, 2009년 12월 6일 (UTC)

사실, 내가 위키피디아를 갈 때 파이어폭스는 정기적으로 충돌한다 - 편집 사이클에 걸려있는 것 같다(미리보기나 저장하기).나는 버전 3.5.5를 가지고 있다.위키백과 편집 주기 외에는 다른 곳에서는 전혀 충격받지 않아.하지만, 나는 그것이 내 애드온 중 하나여야 한다고 결정했다.내가 안전모드로 파이어폭스를 꺼냈을 때 그런 일은 일어나지 않는 것 같다.그래서.. 어떤 부가물이 문제를 일으키는지 알아내면 여기에 올릴게.문제는 늘 있는 일이 아니라는 점이다.편집 사이클에서 반복해서 보는 것 같다.그래서 - 범위를 좁힐 때까지 계속 가지고 놀 것이다. stmrlbs는 22:29, 2009년 12월 6일 (UTC)

각주 마커

이 프로젝트의 일부 다른 언어 버전은 각주를 나타내기 위해 위첨자 숫자만 사용하지만 영어 버전은 대괄호 안의 숫자를 사용한다.왜 그런 것일까요?숫자만 사용하면 눈에 훨씬 더 즐겁고 가독성이 향상된다. -Rrius (대화) 09:15, 2009년 12월 5일 (UTC)

이것은 전에 (지난번에는 VPR에 대해 생각) 나왔지만, 긴 이야기를 짧게 하기 위해, 괄호를 AFAIK: 각주의 클릭 가능한 면적을 증가시키고, 두 개(또는 그 이상)를 서로 연계하여 사용할 때 서로 쉽게 구별하여 숫자()의 "편리업"을 피하도록 하는 두 가지 주요 목적의 AFAIK에 사용한다.^{1 7 12 27}나는 지난 번 이것이 토론을 위해 제기되었을 때 그 두 문제 중 어느 것도 명백한 해결책이 발견되었다고 생각하지 않는다. - Jarry1250 13:02, 2009년 12월 5일 (UTC)

예, 위키백과:Village_pump_(proposals)/Archive 38#인라인 시트의 디스플레이를 2008년 11월부터 기본적으로 해제하십시오.로그아웃할 때 시트가 희미해지거나, 꺼지거나, 대담해지는 것을 보고 싶다면 스타일리쉬(또는 원하는 경우 Greasemonkey)가 있다면, Salix alba의 위키백과 - 참조 링크 숨기기 또는 위키백과에서 사용자:Mzajak의 아이디어를 아마추어적으로 각색한 위키백과 - 볼더 볼드 인라인 시트를 참조하십시오.하지만 내가 이것들을 마지막으로 테스트한 것은 1년 전이었다.원하는 것처럼 보이도록 쉽게 수정할 수 있어야 한다. -84사용자(토크) 00:14, 2009년 12월 7일(UTC)

저작권 기호

나는 종종 symbol 기호를 찾는 내 자신을 발견했고, 다른 곳에서 그것을 복사/붙여넣어야 하는 것은 언제나 고통스러운 일이다.인서트 메뉴에 추가될 가능성은 없을까(내가 그냥 흐릿해서 이미 거기에 있는 게 아니라면)?PC78 (대화) 19:47, 2009년 12월 5일 (UTC)

그렇지 않은데, 무슨 소용이 있겠니?어떤 경우에도 . — Edokter • Talk • Talk • 20:04, 2009년 12월 5일(UTC)을 입력할 수 있다.

당연히 편리하지애초에 인서트 메뉴가 있는 것과 같은 이유야.PC78 (토크) 20:12, 2009년 12월 5일 (UTC)

나는 에독터가 의미하는 바는 '위키피디아에 무슨 소용이 있을까?'라는 선에 더 가깝다고 생각한다.이것은 편집자들이 기사에서 사용하고 있는 캐릭터인가, 만약 그렇다면, 어떤 목적으로 사용하는가?나는 여기서 뭔가 아주 명백한 것을 놓치고 있을지도 모르지만, 머리 위로는 우리가 그것을 사용하고 싶은 곳이 전혀 생각나지 않는다.TenOfAllTraes(대화) 22:11, 2009년 12월 5일(UTC)

나는 저작권자를 명명할 때 그것을 합리적으로 사용하는 경향이 있다.삽입 메뉴에는 이미 대부분의 편집자가 필요로 하지 않을 무명 기호가 잔뜩 실려 있다(그 중 몇 개가 있는지도 모른다).나는 많은 것을 요구하는 것이 아니다.PC78 (토크) 22:46, 2009년 12월 5일 (UTC)

삽입 메뉴는 MediaWiki:Editdools.js 및 MediaWiki:Editdools; 당신은 이것을 토크 페이지에서 논의할 수 있다. ---— Gadget850 (Ed) 22:52, 2009년 12월 5일 (UTC)

건배, 내 부탁은 거기로 옮길게.PC78 (토크) 15:02, 2009년 12월 6일 (UTC)

짜증나는 벌레

조언대로 헬프 데스크에서 스레드가 움직였다.

이것은 가능성이 희박할 수도 있지만, 그런 문제에 어떤 영향력을 가지고 있는 사람이라면 위키피디아의 '디프' 세대의 오랜 버그(그리고, 내게는 규칙적인 자극제)를 고쳐야 한다고 압박할 수 있을지 궁금하다.이것은 전형적인 예다.

http://en.wikipedia.org/w/index.php?title=Nonsuch_Palace&action=historysubmit&diff=328327302&oldid=283689391

내가 완전히 이해하지 못하는 어떤 이유로 소프트웨어가 혼동되기 때문에, 동일하거나 실질적으로 동일한 여러 단락이 완전히 다른 것으로 플래그 지정되어 있음을 알 수 있다.나는 이것이 알려진 이슈로 기록되어 있고, 한동안 존재해왔지만, 우선순위가 낮은 것으로 보여지고, 누군가의 도움 없이는 결코 고쳐질 것 같지 않다고 생각한다.만약 내가 이 요청을 게시하기에 더 적절한 장소가 있다면 알려줘.86.146.46.190 (토크) 21:58, 2009년 12월 5일 (UTC)

그래, 알려져 있다.마을 펌프 현장 중 하나, 아마도 기술적인 부분이 더 논의하기에 가장 좋은 장소일 것이다.--SPHILbrickT 22:15, 2009년 12월 5일 (UTC)

내가 아는 한, 이것은 해결하기 쉬운 문제가 아니며, 현재 우리가 가지고 있는 것보다 더 나은 성능을 제공하는 무료 디프 소프트웨어 패키지도 없다.OrangeDog (1998 • ε) 21:10, 2009년 12월 6일 (UTC)

편집 중 로그인

안녕하십니까, 여러분.위키백과 페이지에 로그인하는 동안 편집하는 옵션을 제공하는 것이 가능할까 하는 생각이 들었다.즉, 로그인하지 않았다고 가정하십시오.페이지를 편집하고 익명이 아닌 ID로 편집하려는 경우.현재 로그인 페이지로 안내하는 로그인을 먼저 클릭해야 한다.그런 다음 로그인 정보를 입력하고 로그인을 클릭하여 기사 페이지로 돌아가십시오.그런 다음 편집을 누르고 ID로 편집할 수 있다.내가 제안하는 것은, 당신이 먼저 로그인하고 나서 편집을 클릭할 필요가 없는 시스템을 제공할 수 있지 않을까 하는 것이다.대신 편집을 클릭하고 편집 페이지 자체에 로그인 정보를 제공하십시오(생방 저널과 블로거가 의견을 게시할 때와 같은 경우).두 페이지 로드(로그아웃 포함 시 세 페이지)를 절약한다.이는 빠른 편집을 원하지만 로그인 후 로그아웃하는 과정을 거치지 않기 때문에 편집하지 않는 사용자에게 매우 유용할 수 있다.단 한 번만 편집하면 돼이러한 사람들은 "로그인 상태 유지" 옵션을 사용하지 않거나 다른 컴퓨터를 사용하고 있을 수 있다.나는 이 계획을 사용하는 동안 쉽게 해결할 수 없는 보호된 페이지 등의 문제를 보지 않는다.어떻게 생각하십니까? --Relocant Philosopher (대화) 03:26, 2009년 12월 6일 (UTC)

사실, 너는 이미 비슷한 것을 할 수 있어.편집 창이 열려 있는 동안 로그인을 클릭하면 로그인이 완료된 후 다시 편집 창으로 돌아가게 된다.인텔리전트시움 03:28, 2009년 12월 6일 (UTC)

와우! 그래, 이제 됐다. 언제 이런 일이 일어났니?마지막으로 편집 창을 열면서 로그인을 클릭할 때까지 나는 항상 기사 페이지로 이동했다. 기사 페이지는 내가 비논리적이고 이 혼란에 대한 중요한 동기인 것이다.내 생각에 그것은 여전히 한 번의 클릭이 더 있지만 확실히 이전보다 더 견딜 수 있는 것 같다.그래도 편집 페이지에 바로 로그인 정보용 텍스트 상자를 두어 개 추가하는 것에 대해 어떻게 생각하십니까? --Relicant Philosopher (대화) 06:57, 2009년 12월 6일 (UTC)

너무 시각적으로 주의를 분산시키는 경우 새 창을 열고 로그인한 다음 편집 내용을 미리 보고 저장하십시오.엄밀히 말하면, 미리보기는 필요하지 않지만, 당신의 서명 라인이 의도한 대로 작동하는지 확인하는 한 가지 방법이다. davidwr/(대화)/(contracts)/(e-mail) 04:37, 2009년 12월 6일 (UTC)

고마워. 그래도 편집 페이지에 로그인 정보용 텍스트 상자 몇 개를 추가하면 모든 것이 간단해지는 단점이 보이니?마지못해 Philosopher (대화) 06:57, 2009년 12월 6일 (UTC)

그렇다, 한 페이지에 더 많은 요소들이 그것을 이해하기 어렵게 만든다.우리는 실제로 편집 페이지를 시각적으로 더 희박하게 만드는 과정에 있다.—DJ (대화 • 기여) 11:46, 2009년 12월 6일 (UTC)

WP에 로그인하기 위한 몇 가지 팁:LOGOUT. ---— Gadget850 (Ed) 16:29, 2009년 12월 6일 (UTC)

템플릿 및 페이지 로드 시간에 대한 질문

안녕, 나는 인용 템플릿과 페이지 로딩에 대해 쓰려고 해.기사에 인용 템플릿이 많이 포함되면 로딩 속도가 점점 느려지는 것 같다.그것이 직접 템플릿 때문인지, 아니면 단순히 더 긴 기사가 더 많은 템플릿을 가질 수 있고 길이 또한 로딩 속도를 늦출 수 있는 것인지 모르겠다.정답을 아는 사람?SlimVirgin 12:33, 2009년 12월 6일(UTC)

인용 템플릿은 많은 구문 분석 기능을 사용할 수 있다.그것은 페이지에 복잡성을 더하여 구문 분석과 렌더링에 시간이 더 오래 걸리는 원인이 된다.특히 당신이 로그인 했을 때, 당신은 종종 페이지의 캐시된 복사본과 함께 제공되지 않기 때문에 이것을 알게 될 것이다.페이지의 html 소스를 보면 페이지의 복잡성과 렌더링 시간을 알 수 있다.다음과 같은 의견이 있다.

<!--- NewPP 한계 보고서 Preprocessor node count: 3144/1000000 Post-expanded size: 64735/2048000바이트 템플릿 인수 크기: 32961/2048000바이트 값비싼 파서 함수 개수: 1/500 -->

이것은 얼마나 많은 파서 기능과 위키코드 요소가 사용되는지를 말해준다.줄의 첫 번째 번호는 사용이고, 마지막 번호는 허용되는 최대값이다.

<!!--- 키 enwiki:pcache:idhash:5554932-0!1!0!mdy!!en!3과 타임스탬프 20091206124419 -->와 함께 파서 캐시에 저장되었다.

페이지를 파싱한 후(그러나 HTML로 렌더링되기 전에) 파서캐시에 저장할 수 있다.이 줄에는 언제, 어떤 번호로 저장되었는지 나와 있다.이 캐시는 페이지가 변경될 때 업데이트된다(또는 템플릿, 카테고리 등).{{CURRENTIME}}과 같은 것들은 내가 추측하는 파서캐쉬에 좋지 않을 수도 있다...사실 확실하지 않다.

<!-- srv173이 0.912초에 서비스함 -->

이것은 페이지 소스에서 마지막 중요한 코멘트다.그것은 당신에게 HTML을 렌더링하여 당신에게 제공했던 서버를 알려준다.그러나 로그인하지 않은 경우 이는 오징어 서버 중 하나에 의해 캐시된 "이전" 결과일 가능성이 높다.그러면 훨씬 더 빨리 너에게 줄 수 있을 거야.

마이클 잭슨이 죽었을 때 서버가 다운될 뻔했다는 걸 기억하시겠죠.그 페이지는 매우 크고 계산하기에 매우 집약적이었다. (10초 이상)하지만 너무 자주 편집되어 파서카시와 오징어는 1분에 몇 번 업데이트해야 했다.그것은 서비스의 핵심에 엄청난 부담을 주고 있었고, 그들은 더 이상 그것을 다룰 수 없었다.우리는 이전에 한 페이지에 이렇게 많은 트래픽이 있었던 적이 없었다.—DJ (대화 • 기여) 12:55, 2009년 12월 6일 (UTC)

위키백과의 대화에서 적극적인 후속 조치의 실마리를 찾을 수 있다.출처 인용 #페이지 로드 속도 향상Eubulides (대화) 04:11, 2009년 12월 8일 (UTC)

이걸로 버그?

이 특정한 이슈에 버그가 있는지 아는 사람?

<div[foo][foo][foo]][[foo]][foo][foo]][foo][foo]][div]]]

다음 html을 출력하다

<>div>, <href="/wiki/Foo"title="푸"class="mw-redirect">, foo<, /a>,<>br />,<>p>, <href="/wiki/Foo"title="푸"class="mw-redirect">, foo<, /a>,<>br />, <href="/wiki/Foo"title="푸"class="mw-redirect">, foo<, /a>,<>br />, <href="/wiki/Foo"title="푸"class="mw-redirect">, foo<, /a>,<>br. />,<>/p>, <href="/wiki/Foo"title="푸"class="mw-redirect">, foo<, /a>,<>/div&gt을 말한다.

어떤 것이 보이는지

— RockMFR 18:37, 2009년 12월 6일 (UTC)

딱 맞는 벌레를 찾을 수가 없었다.그 행동은 다소 bugzilla:5718, bugzilla:4780과 비슷하지만 원인이 같은 것인지 다른 것인지 당장 알 수는 없다.드래곤즈 비행 (토크) 2009년 12월 6일 19:13 (UTC)

나는 이것을 HTML-Kit로 실행했고 HTML Nautify를 호출했다.휴식 시간은 확실히 디스켓에 의해 전환되고 있지만, 나는 그것이 더해지는 것을 보지 못한다.<p>...</p>태그. ---— Gadget850 (Ed) 12:57, 2009년 12월 7일 (UTC)

오디오 자동 재생

독자가 페이지를 클릭할 필요 없이 페이지가 로드되는 즉시 Greenleves 파일을 재생할 수 있는 방법은 없을까? --__A. di. M. 22:21, 2009년 12월 6일(UTC)

사용자 페이지는 MySpace 프로필이 아니다.자동 재생 오디오는 좋지 않다.EVULA// 통화 // ☯ // 22:26, 2009년 12월 6일 (UTC)

위에 디토.사용자가 듣고 싶을 때는 클릭할 수 있다.비주얼로 플레이 버튼이 어디에 있는지 지적하지만, 사용자를 위해 결정을 내리지 않으면 된다. - -ooo 22 22_¢:31, 2009년 12월 6일 (UTC)

이 옵션을 기본 설정에 추가할 수 있는 방법이 있는가?지금 거기 있다는 말은 아니지만, 곧 다가올 특집일 수 있을까?Woogee (토크) 00:05, 2009년 12월 7일 (UTC)

나는 이것에 어떤 백과사전적 사용도 예상할 수 없다.대부분의 사람들은 그 음악에 관한 기사를 방문했을 때 즉시 음악을 듣기를 바라지 않을 것이다; 어떤 음악은 연주될 수 없다(저작권상의 이유로) 또한 기사에 모순을 일으킨다.2009년 12월 7일 02:00(UTC)

나는 오토플레이 음악과 저작권 우려 사이에 갈등이 있다고 생각하지 않는다(Fair Use sounds는 단지 작은 스니펫일 뿐이고, 무작위로 곡을 고르는 것을 듣는 것은 이상할 것이다.
그렇긴 하지만 자동 재생/복사권 충돌은 없지만 자동 재생/좋은 맛의 충돌은...EVULA// 통화 // ☯ // 20:06, 2009년 12월 7일(UTC)

자바스크립트를 작성하면 자동 재생이 될 수 있고, 사람들이 개인용 .js에 포함시키도록 설득할 수 있다.음악 자동 재생은 지옥의 산물이기 때문에 왜 사람들이 그렇게 하길 원하는지는 잘 모르겠어.대수학자 17:58, 2009년 12월 7일 (UTC)

2009년 독감 대유행 기사에 대한 정교한 해커 파괴 행위 - 사용자가 이용할 수 없음

해결됨

– 신속하게 처리된 단순 파괴 행위. 별일 아니야. EVULA // talk // talk // 00:33, 2009년 12월 8일(UTC)

이 중요한 공중보건 페이지에 정교한 해커 기물 파손

2009년 독감 유행 http://en.wikipedia.org/wiki/2009_flu_pandemic

해커는 해킹 기술을 이용해 홍보용 하운드라는 자아를 뚫는 대신 이 페이지의 '백신' 부분을 추가해 파괴하는 방식을 택했다.

그는 "1976년 미국에서 대량 백신 접종으로 100만 건이 넘는 사람들의 머리가 벗겨진 것과 대조를 이룬다"고 말했다.[71]"

유머의 시도는 일반 사용자가 제거할 수 없게 만드는 코딩으로 버팀목이 되어, 반달리즘을 되돌리기 위해 '편집' 화면에 가면 거기서 '재미있는 농담'을 찾아볼 수 없게 된다.텍스트의 미리보기를 편집 화면에 인쇄하면 텍스트도 해당 화면에서 찾을 수 없다.백신 섹션의 편집 화면 또는 전체 기사에 대한 동일한 결과.

해커와 해커를 식별하고 사이트에서 둘 다 제거하는 조치를 취해야 한다.

주요 기사에는 반달리즘이 포함되어 있음

백신

주요 기사: 2009년 독감 유행 백신 2009년 11월 19일 현재, 16개국 이상에서 6500만 회 이상의 백신이 투여되었다; 백신은 안전하고 효과적이어서 감염으로부터 보호해야 할 강력한 면역 반응을 만들어낸다.[67] 현재의 3가 계절 인플루엔자 백신은 신종 유행성 변종이 이 백신에 사용되는 변종과 상당히 다르기 때문에 H1N1 감염 위험을 증가시키거나 감소시키지 않는다.[68][69] 신종 H1N1 백신의 안전도는 전반적으로 계절독감 백신의 안전도와 유사하며, 백신을 접종한 후 기레인-바레 증후군이 보고된 경우는 십여 건도 안 된다.[70] 이 중 실제로 H1N1 예방접종과 관련이 있는 것으로 의심되는 것은 극히 일부에 불과하며, 일시적인 병만 관찰되었다.[70] 이는 1976년 미국에서 대량 백신 접종으로 100만 건이 넘는 사람들의 머리가 벗겨진 것과 대조를 이룬다.[71]

계란 알레르기가 있는 사람들의 안전 우려는 백신을 위한 바이러스가 닭갈비를 기반으로 한 문화에서 자라기 때문이다.계란 알레르기가 있는 사람들은 주의 깊고 통제된 환경에서 의사와 상의한 후 등급이 매겨진 양으로 백신을 받을 수 있을 것이다.[72] 백스터가 제조한 백신은 난자를 사용하지 않고 만들어지지만 면역성을 생산하려면 3주 간격으로 2회 복용해야 한다.[73] 캐나다에서는 11월 말 현재 예방접종에 따른 과민성 쇼크가 확인된 사례가 24건이며, 사망자는 1명이었다.추정률은 백신 접종자 31만2000명당 1건의 과민반응이다.그러나 주어진 15만7000여 회분 중 6명이 아나필락시스(anaphylaxis)를 앓은 백신이 한 차례 있었다.이 배치의 비교적 적은 나머지 선량은 조사가 보류된 상태로 유지되고 있다.캐나다의 최고 공중 보건 담당자인 데이비드 버틀러 존스 박사는 비록 이것이 보조 백신이지만, 이 6명의 환자들에게 이런 심각한 알레르기 반응의 원인은 아닌 것으로 보인다고 말했다.[74][75]

편집 페이지에 반달리즘이 포함되어 있지 않음

백신

2009년^[update] 11월 19일 현재, 16개국 이상에서 6500만 회 이상의 백신이 투여되었다; 백신은 안전하고 효과적이어서 감염으로부터 보호해야 할 강력한 면역 반응을 만들어낸다.^[1]현재의 3가 계절 인플루엔자 백신은 신종 유행성 변종이 이 백신에 사용되는 변종과 상당히 다르기 때문에 H1N1 감염의 위험을 증가시키거나 감소시키지 않는다.^[2][3]신종 H1N1 백신의 안전 프로필은 전반적으로 계절독감 백신의 안전 프로필과 유사하며, 예방접종 후 기예인-바레 증후군이 보고된 사례는 십여 건도 안 된다.^[4]이 중 실제로 H1N1 예방접종과 관련이 있는 것으로 의심되는 것은 극히 일부에 불과하며, 일시적인 병만 관찰되고 있다.^[4]이는 1976년 미국에서 대량 백신 접종으로 기예인-바레 증후군이 500여 건에 달해 25명이 사망했던 것과 크게 대조적이다.^[5]

계란 알레르기가 있는 사람들의 안전 우려는 백신을 위한 바이러스가 닭갈비를 기반으로 한 문화에서 자라기 때문이다.계란 알레르기가 있는 사람들은 주의 깊고 통제된 환경에서 의사와 상의한 후 등급이 매겨진 양으로 백신을 받을 수 있을 것이다.^[6]백스터가 제조한 백신은 난자를 사용하지 않고 만들지만 면역력을 생산하려면 3주 간격으로 2회 복용해야 한다.^[7]

캐나다에서는 11월 말 현재 예방접종에 따른 과민성 쇼크가 확인된 사례가 24건으로 1명이 사망하는 등 피해가 속출하고 있다.추정률은 백신 접종자 31만2000명당 1건의 과민반응이다.그러나 주어진 15만7000여 회분 중 6명이 아나필락시스(anaphylaxis)를 앓은 백신이 한 차례 있었다.이 배치의 비교적 적은 나머지 선량은 조사가 보류된 상태로 유지되고 있다.캐나다의 최고 공중 보건 담당자인 데이비드 버틀러 존스 박사는 비록 이것이 보조 백신이지만, 이 6명의 환자들에게 이런 심각한 알레르기 반응의 원인은 아닌 것으로 보인다고 말했다.^[8][9]

편집 미리보기 페이지에도 반달리즘이 표시되지 않음

2009년 독감 대유행 편집 (섹션)

무료 백과사전인 위키피디아에서

항법:으로 이동, 검색.

미리보기

이것은 미리 보기일 뿐이므로 변경 사항이 아직 저장되지 않았음을 기억하십시오!

백신

주요 기사: 2009년 독감 유행 백신

2009년 11월 19일 현재, 16개국 이상에서 6500만 회 이상의 백신이 투여되었다; 백신은 안전하고 효과적이어서 감염으로부터 보호해야 할 강력한 면역 반응을 만들어낸다.[1] 현재의 3가 계절 인플루엔자 백신은 신종 유행성 변종이 이 백신에 사용되는 변종과 상당히 다르기 때문에 H1N1 감염의 위험을 증가시키거나 감소시키지 않는다.[2][3] 전반적으로 신종 H1N1 백신의 안전 프로필은 계절독감 백신의 안전 프로필과 유사하며, 예방접종 후 기예인-바레 증후군이 보고된 경우는 십여 건도 안 된다.[4] 이 중 실제로 H1N1 예방접종과 관련이 있는 것으로 의심되는 것은 극히 일부에 불과하며, 일시적인 병만 관찰되었다.[4] 이는 1976년 미국에서 대량 백신 접종으로 기예인-바레 증후군이 500건 이상 발생하여 25명이 사망했던 돼지독감 발생과는 큰 대조를 이룬다.[5]

계란 알레르기가 있는 사람들의 안전 우려는 백신을 위한 바이러스가 닭갈비를 기반으로 한 문화에서 자라기 때문이다.계란 알레르기가 있는 사람들은 주의 깊고 통제된 환경에서 의사와 상의한 후 등급이 매겨진 양으로 백신을 받을 수 있을 것이다.[6] 백스터가 제조한 백신은 난자를 사용하지 않고 만들지만 면역성을 생산하려면 3주 간격으로 2회 복용해야 한다.[7]

캐나다에서는 11월 말 현재 예방접종에 따른 과민성 쇼크가 확인된 사례가 24건으로 1명이 사망하는 등 피해가 속출하고 있다.추정률은 백신 접종자 31만2000명당 1건의 과민반응이다.그러나 주어진 15만7000여 회분 중 6명이 아나필락시스(anaphylaxis)를 앓은 백신이 한 차례 있었다.이 배치의 비교적 적은 나머지 선량은 조사가 보류된 상태로 유지되고 있다.캐나다의 최고 공중 보건 담당자인 데이비드 버틀러 존스 박사는 비록 이것이 보조 백신이지만, 이 6명의 환자들에게 이런 심각한 알레르기 반응의 원인은 아닌 것으로 보인다고 말했다.[8][9]

— 68.165.11.37 (대화) 00:10, 2009년 12월 8일 (UTC)에 의해 추가된 이전의 부호 없는 의견

응? 이제 고친 것 같아.브라우저 캐시를 새로 고쳐보십시오.Calvin 1998 00:14, 2009년 12월 8일 (UTC)

때로는 적을 과소평가하는 것보다 과대평가하는 것이 더 위험할 때도 있다."해커 반달리즘"은 없다.그것은 당신이 페이지를 로드하고 편집 버튼을 클릭하는 사이에 제거될 정도로 빠르게 되돌아온 단순한 반달리즘일 뿐이다.Intelligentsium 00:21, 2009년 12월 8일(UTC)

제안 - 보조 편집 상자 바꾸기

마이너 편집 박스가 많이 오용된다는 댓글들을 많이 보고 알게 되었다.많은 사람들, 심지어 일부 베테랑 편집자들조차 "미리" 편집이라고 여겨지는 것에 대해 단순히 지침을 모르거나 따르려고 애쓴다.그들은 그것을 좀 더 주요한 편집에 대해 설명하거나 논쟁적인 변화를 시도하지 않기 위해 사용한다.

내가 이 문제를 해결하기 위해 고안한 아이디어는 마이너 편집 박스를 "미니어 편집"이라고 불리는 상자 대신 체크할 수 있는 몇 개의 다른 상자로 교체하는 것이다.이러한 사소한 편집을 하는 사람은 해당 상자를 선택한다.다른 모든 사람들은 설명하지 않을 수 없을 것이다.

일부 가능한 상자는 다음과 같을 수 있다(단, 단순화하기 위해 숫자를 줄여야 함).

• 철자수정
• 캡스
• 구두점
• 경미한 단어 수정(필요한 경우 a와 같이 의미를 변경하지 않고 단어를 추가/제거/변경)
• 서식 수정(예: 기울임꼴, 머리글)
• 간격(예: 더 많거나 더 적은 공백)
• 이미지 크기 조정
• 페이지에 이미 있는 단어/문구를 다른 위키백과 페이지에 연결
• 템플릿 추가(예: 탐색 상자)
• 반달리즘 제거
• 스팸 제거
• 부적절한 외부 링크 제거

이 제안으로, 여러 개의 상자를 확인하는 옵션이 있을 것이다.

편집 요약을 공백으로 두면, 선택 상자에 있는 내용이 자동으로 편집 요약이 된다.

나는 이 모든 예들이 나열되어야 한다고 말하거나 다른 제안들이 추가될 수 없다고 말하는 것이 아니다.하지만 한 가지 확실한 것은 그것이 부편집 상자의 잘못된 사용을 멈출 것이라는 것이다.Sebwite (대화) 05:33, 2009년 12월 8일 (UTC)

이러한 옵션들이 기존 시스템을 남용하는 사용자들을 어떻게 방해할 것인가?만약 누군가가 "논란적인 변화"를 "실행"하고 싶다면, 그들은 여전히 그것을 "형식화"로 표시할 수 있다.EVULA // talk // talk // 06:22, 2009년 12월 8일(UTC)

명예의 정도가 있다.그러나 "소수"로 간주되는 목록들은 다른 사람들이 더 이상 클릭할 필요 없이 사소한 편집이 무엇인지 아는 심리적 효과를 가질 것이고, 다른 종류의 사소한 편집에 대해 박스를 분리할 것이다.또한 특정 유형의 사소한 편집이 무엇인지를 명시하고 사용하지 않을 경우 편집 요약을 자동으로 작성한다.그런 식으로, 예를 들어, 만약 한 사람이 새로운 탐색 상자를 수많은 페이지에 추가하는 것이라면, 그들은 그것을 더 효율적으로 할 수 있을 것이다.세브라이트 (대화) 2009년 12월 8일 (UTC) 14:43, 8

꼭 그렇지는 않다.그들은 매번 한 상자씩이 아니라, 한 상자를 몇 번 더 체크해야 할 것이다.(그리고 각 페이지에 대한 편집 요약을 복사하여 붙여넣을 수 있다. 대량 편집을 할 때 나는 그렇게 한다) EVula // talk // ☯ // 17:06, 2009년 12월 8일(UTC)

나로서는 사소한 편집의 오용에 대해서는 별로 눈치채지 못하지만, 그렇다면 처음부터 편집이 사소한 것으로 표시되었는지 아닌지는 잘 눈치채지 못할 것 같다.나 스스로 마이너 박스를 사용하지만, 다른 편집에 그렇게 많이 신경 쓰지 않아.그럼에도 불구하고, 만약 문제가 있다면, 소프트웨어 변경을 정당화할 만큼 중요한 것은 아니다; 나는 또한 편집 페이지를 지금보다 더 복잡하게 만드는 어떠한 소프트웨어 변경도 일어나지 않을 것이다.Equazcion (대화) 17:15, 2009년 12월 8일 (UTC)

위의 목록을 다음 네 개의 상자로 단순화하는 것은 어떨까?

• 맞춤법, 구두점, 대문자 또는 문법 수정
• 위키 형식 수정
• 새 템플릿 추가
• 공공 기물 파손, 스팸 또는 외부 링크 제거

Sebwite (대화) 17:44, 2009년 12월 8일 (UTC)

사용적합성 팀이 향후 "최소 편집" 부분을 "게시 대화상자"로 이동하는 것을 고려하고 있다는 점에 유의하십시오.여기서 실험을 참조하십시오(게시 단추 선택).—DJ (대화 • 기여) 2009년 12월 8일 20:00 (UTC)

중복되고 제거할 수 없는 제안을 병합하다.

찰스 컬런 기사를 보다가 중복으로 보이지만 편집 페이지에는 나타나지 않는 병합 템플릿이 눈에 띄었다.어떻게 제거해야 할지 잘 모르겠어 Matt (talk) 11:21, 2009년 12월 8일 (UTC)

이걸 찾아줘서 고마워문제는 템플릿에 추가된 병합 10mplate이었습니다.인포박스 연쇄살인범나는 그것을 "noinclude" 태그로 포장했다.페이지를 새로 고치면(예: Firefox의 Shift+F5) 메시지가 사라진다. - Pointillist(대화) 11:39, 2009년 12월 8일(UTC)

템플릿 병합은 문서 페이지에 있어야 한다고 생각한다. ---— Gadget850 (Ed) 17:48, 2009년 12월 8일 (UTC)

WP의 CSS 스타일시트

나만의 사이트를 위해 특수 문자 입력 도구(모든 편집 창 아래)와 비슷한 것을 만들 생각인데, 어떻게 작동하는지 알아내려고 페이지 출처를 기웃거리고 있다.특히 페이지 소스 코드의 이 부분을 보고 있다.

<>div id="editpage-specialchars"style="margin-top:15px, 국경:1px 고체 # aaaaaa은 2px 패딩."class="edittools-text edittools-version-019">,<>p>,<>b&gt을 말한다.복사와 붙여 넣기:<>/b>, – —‘’ “”° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · 제<>b>.이야기 페이지에:당신이 올린 글<>/b>, ~~~~<>/p>,<>시간 />,<>p>,<>small>,{{}}{{{}}}[][경우] 뻗는다[경우에는 종류:]]#REDIRECT[경우]]&nbs에 서명한다.P.<>s>,<>/s>,<>sup>,<>/sup>,<>sub>,<>/sub>,<>code>,>/code>,<>pre>,<>/pre>, 개체, blockquote>,<>/blockquote>, <, ref>,<>/ref>,{{Reflist}}<>references/>,<>includeonly>,<>/includeonly>,>noinclude>,<>/noinclude>,{{DEFAULTSORT:}}<>nowiki>&.그것은, /nowiki>,>!--><>로 확장 class="plainlinks">,<>/span>,<>/small>,<>/p>,<>시간 />,<>p>,<>small>,<>b&gt을 말한다.기호:<>/b>, ~ ¡ ¿ † ‡ ↔ ↑↓•#½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ ∞‘’ “”«» ¤ ₳ ฿ ₵ ¢ ₡ ₢달러 ₫ ₯ € ₠ ₣ ƒ ₴ ₭ ₤ ℳ ₥ ₦ № ₧ ₰ £ ៛ ₨ ₪ ৳ ₮ ₩ ¥ ♠ ♣ ♥ ♦ m² m³ ♭ ♯ ♮© ® ™<, br/>,<>b>.인물들:<>/b>, Á á Ć ć É é Í í Ĺ ĺ Ń ń Ó ó Ŕ ŕ Ś ś Ú ú Ý ý Ź ź 알 아 È è Ì ì Ò ò Ù ù  â Ĉ ĉ Ê ê Ĝ ĝ Ĥ ĥ Î î Ĵ ĵ Ô ô Ŝ ŝ Û û Ŵ ŵ Ŷ ŷ Ä ä Ë ë Ï ï Ö ö Ü ü Ÿ ÿ ß Ã ã Ẽ ẽ Ĩ ĩ Ñ ñ Õ õ Ũ ũ Ỹ ỹ Ç çĢ ģ Ķ ķ Ļ ļ Ņ ņ Ŗ ŗ Ş ş Ţ ţ Đ đ Ů ů Ǎ ǎ Č č Ď ď Ě ě Ǐ ǐ Ľ ľ Ň ň Ǒ ǒ Ř ř Š š Ť ť Ǔ ǔ Ž ž Ā ā Ē ē Ī ī Ō ō Ū ū Ȳ ȳ Ǣ ǣ ǖ ǘ ǚ ǜ Ă ă Ĕ ĕ Ğ ğ Ĭ ĭ Ŏ ŏ Ŭ ŭ Ċ ċ Ė ė Ġ ġ İ ı Ż ż Ą ą Ę ę Į į Ǫ ǫ Ų ų Ḍ ḍ Ḥ ḥ Ḷ ḷ Ḹ ḹ Ṃ ṃ Ṇ ṇ Ṛ ṛ Ṝ ṝ Ṣ ṣ Ṭ ṭ Ł ł Ő ő Ű ű Ŀ ŀ Ħ ħ Ð ð Þ þ Œ œ Æ æ Ø ø Å å Ə ə{{유니 코드}}<>br/>,<>b>.그리스:<>/b>, Ά ά Έέ Ή ή Ί ί Ό ό Ύ ύ Ώ ώ Α α Β β Γ γ Δ δ Ε ε Ζ ζ Η η Θ θ Ι ι Κ κ Λ λ Μ μ Ν ν Ξ ξ Ο ο Π π Ρ ρ Σ σ ς Τ τ Υ υ Φ φ Χ χ Ψ ψ Ω ω{{Polytonic}}<>br/>,<>b>, 키릴 문자:<>/b>, А а Б б В в Г г Ґ ґ Ѓ ѓ Д д Ђ ђ Е е Ё ё Є є Ж ж З з Ѕ ѕ И и І і Ї ї Й й Ј ј К к Ќ ќ Л л Љ љ М м Н н Њ њ О о П п Р р С с Т т Ћ ћ У у Ў ў Ф ф Х х Ц ц Ч ч Џ џ Ш шщ щ ъ ъ ы ь ь э < < < < < < < < < < < < < < < < < < < < < < <?IPA:</b> t̪ d̪ ʈ ɖ ɟ ɡ ɢ ʡ ʔ   ɸ ʃ ʒ ɕ ʑ ʂ ʐ ʝ ɣ ʁ ʕ ʜ ʢ ɦ   ɱ ɳ ɲ ŋ ɴ   ʋ ɹ ɻ ɰ   ʙ ʀ ɾ ɽ   ɫ ɬ ɮ ɺ ɭ ʎ ʟ   ɥ ʍ ɧ   ɓ ɗ ʄ ɠ ʛ   ʘ ǀ ǃ ǂ ǁ   ɨ ʉ ɯ   ɪ ʏ ʊ   ɘ ɵ ɤ   ə ɚ   ɛ ɜ ɝ ɞ ʌ ɔ   ɐ ɶ ɑ ɒ   ʰ ʷ ʲ ˠ ˤ ⁿ ˡ   ˈ ˌ ː ˑ ̪   {{IPA }} </small> </p> </div>

여기서 중요한 건class="edittools-text edittools-version-019". 소스 코드 상단에 연결된 6, 7개의 스타일시트를 둘러보았지만 이 물체는 어디에서도 찾을 수 없었다.어디 있는지 아는 사람 있어?

고마워, rʨanaɢ _contribs/ 20:24, 2009년 12월 8일 (UTC)

MediaWiki:기본 버전에 대한 에딧풀.en.wp 버전의 경우 MediaWiki:Editools.js 및 MediaWiki에 있는 "Edittools javascript loader" 코드:Common.js/edit.js(MediaWiki에 넣을 수 있는 기능:자신의 사이트에 대한 공통.js).—DJ (대화 • 기여) 2009년 12월 8일 (UTC) 20:32, 8

Edittools-version-* 클래스는 Javascript에 의해 확인되어 Javascript가 구식인지 여부를 확인한다.Javascript는 캐시되므로, 만약 Javascript가 자체 버전 18이고 클래스 이름에 19가 표시된다면, 오래된 것임을 알고 있고, 스스로를 다시 로드해야 한다) —DJ (대화 • 기여) 20:34, 2009년 12월 8일 (UTC)

아마도 우리는 [[도움말]이 필요할 것이다.Edittools] ---- - - Gadget850 (Ed) 21:09, 2009년 12월 8일 (UTC)

또는 MediaWiki talk의 맨 위에 제공된 정보에 대한 확장/추가 정보:Edittools. -- Quidity (토크) 22:24, 2009년 12월 8일 (UTC)

고마워, 얘들아! ranaana / _contribs/ 22:23, 2009년 12월 8일 (UTC)

도구 모음 인용문 편집 / 액세스 날짜 형식

편집 툴바의 "인용 삽입" 기능이 이제 이전처럼 "2009-12-08"이 아닌 "2009년 12월 8일"로 접속 날짜를 자동으로 삽입하는 것을 주목했다.이것은 왜 바뀌었을까?나는 위키피디아에서의 의견 일치를 다음과 같이 생각했다.YYYY-MM-DD 숫자 날짜에 대한 Mosnum/제안은 YYYY-MM-DD 날짜를 각주(특히 액세스 날짜)로 유지하는 것이었다.이러한 변경이 나쁜 또 다른 이유는 이전에 삽입된 접속 날짜가 여전히 대부분 YYY-MM-DD이고 새로운 접속 날짜는 그렇지 않기 때문에 불일치가 발생(중대한 문제)하기 때문이다.도구 모음 기능에 대한 이러한 변경 사항을 어떻게 되돌릴 수 있는가?오프라이너(토크) 03:08, 2009년 12월 9일 (UTC)

YYYY-MM-DD 숫자 날짜에 대한 제안은 실패했다. 합의된 내용이 없었다.따라서 우리가 각주에 YYYY-MM-DD 날짜를 "유지"해야 한다는 개념을 뒷받침하는 데 사용할 수 없다.각주에 YYYY-MM-DD 날짜를 사용하기로 합의한 적이 없기 때문에, 사용할 수 있는 개별 기사를 제외하고는 "유지"에 대해 말하는 것은 말이 되지 않는다. --Jc3s5h (대화) 03:32, 2009년 12월 9일 (UTC)

좋아, RFC 일은 잊어버려.하지만 이러한 변화의 이유는 무엇일까?그것은 큰 모순으로 이어지기 때문에 좋은 것이 되어야 한다.오프라이너(토크) 03:35, 2009년 12월 9일 (UTC)

기본 편집 도구 모음에는 참조를 입력할 수 있는 기능이 없다.당신은 당신의 선호도에서 어떤 선택사항을 선택했음에 틀림없다.참조 편집 기능을 추가하기 위해 어떤 선호 설정을 변경했는지 알아내고, 누가 변경했는지 안내해 줄 것을 제안한다. --Jc3s5h (대화) 03:43, 2009년 12월 9일 (UTC)

사용자:Mr.Z-man/refToolbar 도구.누군가 YYYY-MM-DD가 더 이상 허용되지 않는다고 생각했기 때문에 작가는 11월 19일에 바뀐 것 같다.User_talk:Mr.Z-man/refToolbar#Date_formats.오프라이너(토크) 03:49, 2009년 12월 9일 (UTC)

모든 것이 여기서 시작되었다.OrangeDog (1999 • ε) 20:24, 2009년 12월 9일 (UTC)

누락품

나는 내가 알고 있는 사실의 기사를 찾을 수 없어서 매우 어리둥절하다.내가 직접 기사를 읽은 적이 있는데 ORSAT 분석 기사를 인용하는 웹사이트를 찾기도 했다.

[redacted/possibio] --RAM (talk) 04:52, 2009년 12월 9일 (UTC) 의심 카피비오가 davidwr/(talk)/(contracts)/(e-mail) 05:19, 2009년 12월 9일 (UTC)

네가 찾고 있는 걸 찾은 것 같아, 오르사트 분석.저작권 침해가 의심되는 사항으로 삭제되었다.WP 참조:위키백과 저작권에 대한 정보를 위한 저작권.그 근거로 나는 너의 문자를 수정했다.그러나 이 웹사이트는 2006년에 있었던 그대로의 기사를 인용하는 것을 권장하고 있다.텍스트는 내부 날짜가 2000인 Excel 스프레드시트에서 가져온 것으로 보인다.이 날짜가 잘못되어 위키백과 페이지가 먼저 만들어졌을 가능성이 있다.동일한 텍스트를 포함하는 다른 웹 사이트는 2007년 이후 날짜가 있다. davidwr/(talk)/(contracts)/(e-mail) 05:19, 2009년 12월 9일(UTC)

나는 이미 내가 크게 기여한 위키백과 기사를 뜯어내고, 내가 위키백과를 위해 만든 사진을 백금 케이블로 찍어 그들의 웹사이트에 PDF에 올린 다음, 이미지의 저작권을 주장하는 일을 해야 했다.만일 내가 이상한 방법으로 창조된 원고를 비 SVG 형식으로 보존한 것이 아니었다면, 그 기사가 내 작품의 바가지가 아니라는 것을 증명할 방법이 없을 것이고, 그것은 자유롭게 제안하고 자신의 것으로 주장하는 사람에 대한 기고 편집자의 말이 된다.

위키백과 기사가 원본이지만 누군가가 가져가고 PDF를 만들어 PDF의 생성/수정일을 기사가 존재하기 이전으로 역행한 다음, 콘텐츠 도둑이 저작권이 있는 자료가 들어 있다고 주장하는 카피비오 깃발을 위키백과 기사에 올리면 어떻게 위키백과에서 자료를 증명할 수 있겠는가?피비오? 그러한 남용에 의해 자유롭게 유통되는 콘텐츠에 대한 보호도 없고 방어도 없는 것 같다.

이런 경우 위키백과 관리자들은 도둑을 법정에 세우거나 저작권 주장을 중단시키려 하는 것과는 반대로 위키백과의 무료 배포 정책의 강간 문제를 다루는 쉬운 방법이기 때문에 원래 비폭력적인 위키백과 내용을 삭제하는 데만 급급할 가능성이 높다.

그렇다면 이 삭제된 글이 위키백과에서 삭제된 것이 사실 저작권 위반이 아닌지 어떻게 판단할 수 있을까?누가 삭제했는지에 대한 판단을 받아들여야 할 것 같고 나 같은 '복사기 운동가'가 삭제를 검토할 수 있는 선택권이 없어 "자유롭게 주어진 콘텐츠에 대한 교묘한 소유권 주장"이 아니라는 것을 확실히 하기 위해서야.DMahalko (대화) 05:43, 2009년 12월 10일 (UTC)

이 경우 인터넷 아카이브 페이지인 http://web.archive.org/web/*/http://www.cheresources.com/excessair.xls은 삭제된 글의 텍스트가 2003년 8월 5일에 존재했음을 보여준다.관리자로서 나는 삭제된 Orsat 분석을 볼 수 있다.2005년 9월 17일 IP 203.19.51.148에 의해 만들어졌다.여기에는 Excel 스프레드시트에 있는 "설명" 탭의 단어 복사본에 대한 포맷되지 않은 단어가 포함되어 있다.삭제된 기사는 모든 편집자가 볼 수 있게 하지는 않을 것이다.위키백과 참조:영구적인 제안#삭제된 페이지를 볼 수 있어야 한다.프라임헌터 (토크) 06:26, 2009년 12월 10일 (UTC)

정확히 말하면, 스프레드시트는 "Orsat 기구는 사용...", 위키백과 기사는 "Orsat Analysis는 사용..."을 시작하고, 이것과는 별도로, 더블 스페이스를 배치할 장소를 포함한 동일한 사본이었다.프라임헌터 (토크) 06:40, 2009년 12월 10일 (UTC)

위키백과에 관한 벵골어 기사를 읽을 수 없다.

안녕.

Windows XP 서비스 팩 3 v.5512를 사용하고 있다.구글 툴로킷은 조작할 수 있지만 위키피디아에 올라오는 벵골어 기사는 읽을 수 없다.어떻게 해야 할지 알려달라.—122.162.43.57 (대화) 06:27, 2009년 12월 9일 (UTC)에 의해 서명되지 않은 의견 추가 준비

Bangla 스크립트 표시 및 벵골어 위키백과, 특히 Windows XP와 관련된 지침 입력 도움말을 확인하십시오.Graham87 14:50, 2009년 12월 9일 (UTC)

도움말도 참조하십시오.영어 위키백과의 다국어 지원(인도어)Graham87 15:01, 2009년 12월 9일 (UTC)

배너가 있는 성가신 자바스크립트 버그

해결됨

1. 쿠키/캐쉬는 모금 현수막을 닫아두지 않고, 나는 그것이 다른 그런 시위자들의 행동에 기초해야 한다고 거의 확신한다...
2. [닫기]를 치면 짜증나는 이유로 모금 페이지가 열리기도 한다.

베타 스킨의 Vista에서 Firefox 3.5를 사용하십시오.이것들은 벌레로 되어 있는 것인가, 아니면 의도적인 것인가?:x --Izno (토크) 08:42, 2009년 12월 9일 (UTC)

CentralNotice 스크립트에 결함이 있는 것 같아.어쩐지 전체div.siteNoticeBig받았다onclick=goToDonationPage()그래서 자연스럽게 [숨기기]를 클릭하면 기부 페이지도 나온다.— AlexSm 16:01, 2009년 12월 9일 (UTC)

업데이트: 실제 기부 사례가 있는 배너만 영향을 받으므로(이 방법이 수정될 때까지) 배너를 숨기려면 해당 배너를 클릭하지 마십시오.P.S. 이 메타 페이지에서도 문제가 명백하다.— AlexSm 16:32, 2009년 12월 9일 (UTC)

Trevor와 Roan은 이것이 지금 고쳐져야 한다고 보고한다.—DJ (대화 • 기여) 21:31, 2009년 12월 9일 (UTC)

"여기 링크 내용" 문제

템플릿 A가 기사 B에 대한 링크를 포함하고 있으며 기사 C에서 "What links here"를 확인할 때, 목록에는 C가 있다고 가정합시다.내가 발견한 문제는 템플릿의 링크가 D를 가리키도록 변경되어도 C는 C에 B와의 링크가 없는데도 여전히 리스트에 나타난다는 것이다.알려진 문제인가, 업데이트하는 데 시간이 걸리는가, 아니면 내가 뭔가 잘못하고 있는 건가?Keyed In (talk) 2009년 12월 9일 (토크) 18:18, 9 (UTC)

업데이트하는 데 시간이 좀 걸릴 것 같다. - Jarry1250^{[Humorous? Discuss.]} 18:33, 2009년 12월 9일(UTC)

고마워. 그래도 재밌네. 왜냐하면 다른 페이지(템플릿이 아닌)는 바로 업데이트되기 때문에...나중에 다시 해볼게.Keyed In (대화) 2009년 12월 9일 (UTC) 20:54

그것은 반복되는 문제다.예를 들어, 이 토론을 참조하십시오. &rewHowse (토크) 2009년 12월 9일 20:59, (UTC)

그래, 그리고 더 확실해, 왜냐하면 최근에 일자리 줄이 좀 컸거든.특수:통계에 의하면 4800만개의 일자리가 창출되고 있다.그것을 다시 내리려면 몇 주가 걸릴 것이다.—DJ (대화 • 기여) 21:25, 2009년 12월 9일 (UTC)

성장 중인지 축소 중인지 알 수 있는가? - Jarry1250^{[Humorous? Discuss.]} 22:22, 2009년 12월 9일(UTC)

이번 주 초만 해도 5600만 건이었는데, 팀과 도마는 데이터베이스에 대한 질의를 수작업으로 적용하여 대기열에서 몇 개의 'noop' 작업을 가져간 것으로 알고 있다.그 외에는 잘 모르겠다(Haven은 지난 2일 동안 그렇게 많은 "Heavy Use Template" 변경사항이 없었으므로, 확실히 조금 도움이 될 것이다) —DJ (대화 • 기여) 23:33, 2009년 12월 9일 (UTC)

네가 도와줘서 모두 고마워.키 입력 (대화) 22:43, 2009년 12월 9일 (UTC)

IP 차단 정책

WT:에서 토론을 참조하십시오.차단 IP 주소#업데이트 필요?거기서 응답하라.OrangeDog (1999 • ε) 20:26, 2009년 12월 9일 (UTC)

SVG 리프레시

이봐, 전에도 이런 문제가 있었는데 어떻게 해결했는지 정말 기억이 안 나는데, 어제 최신 버전으로 업데이트한 SVG 파일은 PNG 파일에 업데이트되는 걸 거부해.여기 파일도 있고, 어떻게 보여야 하는지도.주위를 둘러봤는데, 내 기계만은 아닌 것 같아.보통 스스로를 고치는 데 이렇게 오래 걸리지 않는데, 내가 할 수 있는 일이 있을까?-- 패트릭 _o{Ⅱ^∞} 19:52, 2009년 12월 8일 (UTC)

나는 그 페이지를 숙청했다.브라우저 캐시를 건너뛰면 이제 괜찮아 보일 겁니다.—DJ (대화 • 기여) 2009년 12월 8일 (UTC)

고마워, 또 이런 일이 생기면 기억하겠어.-- 패트릭 _o6:09^∞, 2009년 12월 10일 (UTC)

사용자 페이지에서 Hugel을 활성화하는 방법?

해결됨

– 구성 수정 7 07:16, 2009년 12월 10일(UTC)

어떻게 하면 허글을 활성화할 수 있을까?여기에 올바른 값을 설정했지만 Huggle로 로그온하려고 하면 "Huggle이 계정에서 활성화되지 않았으므로 사용자 구성 페이지를 확인하십시오."라고 쓰여 있다.내가 뭘 안 하는 거지?고마워. --Mike Allen 06:05, 2009년 12월 10일 (UTC)

위키백과별로 맨 위에 "enable:true"를 추가해 보십시오.허글/다운로드? 7 06:31, 2009년 12월 10일 (UTC)

내 생각엔 그게 문제인 것 같아. - "enable-all"이 어디서 왔는지는 잘 모르겠지만, 내 것을 보면 "enable:true"라고 되어 있고 내 것은 작동하고 있어. 7 06:33, 2009년 12월 10일 (UTC)

나는 여기서 그것을 얻었다.네가 제안한 대로 해 봤더니 효과가 있었어.고마워. --Mike Allen^{talk · contribs} 06:42, 2009년 12월 10일 (UTC)

프로브 없음 - Meta의 모든 사용자를 위해 허글을 켜고 끄기 위한 프로젝트 수준 구성(걱정하지 마십시오 - 사용자가 사용할 때는 아무 것도 수행하지 않음)잘됐다니 다행이다. 7 07:16, 2009년 12월 10일 (UTC)

트윙클

트윙클(사용자, TW)에 대해 질문이 있다.나는 CSD에 기사를 태그하고 있는데 CSD에 대한 탭이 작동하지 않아.트윙클의 다른 메뉴는 모두 먹히지만 CSD는 먹히지 않는다.트윙클을 사용하기 시작한 이후 처음 있는 일이었다.--JL 09 15:51, 2009년 12월 10일 (UTC)

"작동하지 않는다"는 좋은 버그 리포트는 아니다.무엇을 하고 있고, 그 일을 하면 어떻게 되는가?대수학자 15:54, 2009년 12월 10일 (UTC)

그래, 단어 선택에 대해 미안해.CSD 탭을 클릭할 때마다 아무 것도 튀어나오지 않는다.XFD 태그, prod 또는 rpp와 달리 태그거가 적용할 기준을 선택할 수 있도록 메뉴가 튀어나오는 경우-JL 09 15:57, 2009년 12월 10일(UTC)

대화 페이지가 올바르게 보관되지 않음

해결됨

– 고정. Peachey88 23:13, 2009년 12월 10일 (UTC)

KAL007의 토크 페이지는 보관되어 있다.문제는 두 가지다.

• 현재 토크 페이지에는 5개의 아카이브만이 나열되어 있다.하지만 실제로 6개가 있다.6번 아카이브로 가는 유일한 방법은 5번 링크를 클릭한 다음 5번이 표시된 후 URL 박스에서 "5"를 "6"으로 변경한 다음 다시 "입력"하는 것이다.

• 일반적인 방법으로 페이지를 읽는 경우 보관 6의 일부가 누락됨.그러나 편집 상자를 열고 html을 읽으면 빠진 부분이 있지만 옅은 주황색 배경색을 띤다.

나는 그 페이지(6번 아카이브)가 봇에 의해 자동으로 수행되었는지, 아니면 누군가가 수동으로 수행했는지 모르겠다.어느 쪽이든 KAL007의 전체 토크 이력이 완전하게 보존되고 접근하기 위해서는 상황이 정비될 필요가 있다고 생각한다.보관된 페이지를 편집해서는 안 된다는 훈계 때문에 직접 고치려 하지 않는다.

다음은 링크:

http://en.wikipedia.org/wiki/Talk:Korean_Air_Lines_Flight_007

http://en.wikipedia.org/wiki/Talk:Korean_Air_Lines_Flight_007/Archive_5

http://en.wikipedia.org/wiki/Talk:Korean_Air_Lines_Flight_007/Archive_6

누가 고칠 수 있어?Editor ASC (talk) 22:56, 2009년 12월 10일 (UTC)

• 이 페이지에서 수동으로 생성한 아카이브 박스인 경우{{Archive box}} 토크 페이지에 관련 정보를 추가하십시오.Peachey88^{(Talk Page · Contribs)} 23:13, 2009년 12월 10일 (UTC)

검색 페이지 도움말 링크

검색 페이지의 도움말 링크는 새 검색 인터페이스가 얼마 전에 배포되었을 때 (논의 없이) 제거되었다.그것들을 다시 추가하는 것에 대한 논의가 있다.MediaWiki talk:를 참조하십시오.서치메뉴-엑시스트#갱신 요청

그리고 상기시켜주는 것은이제 MediaWiki 인터페이스 메시지에 대해 논의할 수 있는 새로운 중앙 페이지가 생겼다.위키백과:미디어위키 메시지.일종의 '빌리지 펌프(미디어위키 메시지)'이다.따라서 MediaWiki 인터페이스 메시지가 관심 있는 경우 해당 페이지를 감시 목록에 추가하는 것을 고려하십시오.

--David Göthberg (대화) 03:12, 2009년 12월 11일 (UTC)

위키미디어 바이러스

해결됨

– 태그가 지정된 링크가 현재 안전으로 나열됨. davidwr/(대화)/(계속)/(전자 메일) 01:41, 2009년 12월 12일(UTC)

Symantec의 Norton Safe Web은 wikimedia에 바이러스를 가지고 있다고 꼬리표를 붙였다. 아마도 Norton은 오류를 통보 받아야 한다. 아니면 정말로 wikimedia에 바이러스가 있는 것일까?Smallman12q (대화) 00:56, 2009년 12월 9일 (UTC)

탐지된 위협은 "트로잔"이기 때문이다."악성코드가 포함된 HTML 파일의 일반적 탐지"인 Maliframe!html"은, 주소가 HTML 파일이 아닌 이미지 파일이고, 코드가 포함되어 있지 않기 때문에, 이것은 실수임에 틀림없다고 말하고 싶다.Equazcion(토크) 01:00, 2009년 12월 9일(UTC)

실제로 jpeg 파일 끝에 HTML iframe 태그가 있는 코멘트가 있었는데, 아마도 트로이 목마가 탐지했을 것이다; 나는 어떤 브라우저도 실제로 그것에 영향을 받았을지 모르겠다.관리자가 원할 경우 파일의 이전 버전을 삭제할 수 있다.Anomie 9 01:40, 2009년 12월 9일 (UTC)

나는 이것에 대해 ANI에 글을 올렸다.관리자가 파일의 이전 버전을 삭제하기를 바란다.어쨌든 재단은 Symantec에게 그들의 주장을 검토하도록 요청할 수 있는 권한을 가진 유일한 사람이지만, 그런 일은 이미지가 사라진 후에나 일어나서는 안 된다.davidwr/(talk)/(contracts)/(contracts)/(e-mail) 17:48, 2009년 12월 9일 (UTC)

왜 어떤 권위가 필요한가?물론, 실제로, 시만텍은 아마도 재단의 공식적인 요청에 더 많은 주의를 기울이겠지만, 나는 왜 관련 독자들이 이것을 보도하지 말아야 하는지 모르겠다. 그리고 나는 16명이 이미 그렇게 했다고 본다.필 브리저 (대화) 2009년 12월 9일 (UTC)

사이트 소유자를 클릭하려면?여기를 클릭하십시오" 버튼을 클릭하고 다시 확인 절차를 시작하십시오. 사이트를 소유해야 합니다.코멘트는 당신이 주목한 대로 모두에게 공개된다. davidwr/(대화)/(기여)/(이메일) 00:09, 2009년 12월 10일 (UTC)

다중 사용자 기여 페이지

이건 일종의 기술적인 제안이니 엉뚱한 곳에 있는 게 아닐까.최근에 나는 여러 명의 사용자를 추가할 수 있는 기여 페이지(예: [4])라는 가능한 도구에 대해 생각하고 있었다.아마도 편집은 시간적으로 분류될 것이다. 양말 인형술사의 모든 편집이 양말과 일직선으로 정렬되어 있는 것을 보기 위한 목적, 편집 스타일에 대한 보다 완벽한 개요, 3RR-by-proxy 등을 보기 위한 목적 등이 그것이다.

이것은 기술적으로 합치기가 어려울까?그리고 또, 여기가 잘못된 곳인가? --외미에 15:33, 2009년 12월 11일 (UTC)

너는 올바른 위치에 있다.기술적으로 잘 알고 있는 많은 위키피디아 사람들이 이 페이지를 읽고 있기 때문에 당신은 여기서 좋은 피드백을 받을 수 있다.그러므로 이 페이지는 시작하기에 좋은 장소다.

그리고 그래, 네 생각은 매우 유용해 보인다.툴 서버가 기여 데이터에 접근할 수 있다고 생각하기 때문에 툴 서버 상의 도구로 우선 구현될 수 있을 것 같다.툴 서버 코더가 여기에 있는지 확인하십시오.

--David Göthberg (대화) 16:29, 2009년 12월 11일 (UTC)

툴 서버가 작동하겠지만 User:Lupin/Monitor_my_watchlist, on-wiki something so popups et. al. al.가 제 기능을 할 수 있을 것이다. --Euomie 17:05, 2009년 12월 11일 (UTC)

나는 툴서버에서 비슷한 소리가 나는 비슷한 양말 관련 도구들을 많이 본 적이 있다.틀림없이 1분 안에 누군가 링크를 제공할 수 있을 것이다 :) - Jarry1250 17:53, 2009년 12월 11일 (UTC)

우미에 왕:맞아, 차라리 온위키로 하는 게 나을 것 같아.그러나 보통 툴서버에서 어떤 것을 구현하는 것이 더 빠르다.가능한 또 다른 옵션은 API에 대한 자바스크립트와 일부 아약스 호출을 사용하여 코딩하는 것이다.비록 그것이 내 자바스크립트 능력을 훨씬 넘어섰고, 어쨌든 팝업을 깨트릴 것이다.

Jarry1250:그래, 네가 맞았으면 좋겠어!

--David Göthberg (대화) 18:14, 2009년 12월 11일 (UTC)

이를 수행할 수 있는 도구: http://toolserver.org/~erwin85/1998s.php.네가 원하는 게 정확히 뭔지는 아냐. 온위키보다는 툴서버에 있으니까. 하지만 없는 것보다는 낫지.마랄리아 (토크) 2009년 12월 11일 19:30 (UTC)

고마워유망해 보인다.*sockpuppet closion 이론에 대한 포레스* --Euomie 21:35, 2009년 12월 11일 (UTC)

Wii 게임 목록의 지속적인 시간 초과 오류

나와 다른 사용자들은 Wii 게임 목록에서 이력을 비교하거나 변경사항을 미리 볼 때 지속적인 타임아웃 오류를 표시했다.이 문제는 이 기사에 특유한 것 같다어떤 도움이라도 감사했다.참조용 오류 메시지:

요청: GET http://en.wikipedia.org/w/index.php?title=List_of_Wii_games&action=historysubmit&diff=330867755&oldid=330850001, 68.14.224.1987부터 sq33까지.아마존닷컴(wikimedia.org/2.7.CAVEL6) ~ 208.80.152.29(208.80.152.29) 오류: ERR_READ_타임아웃, 에러 없음 [오류 없음] 2009년 12월 11일 금요일 18:47:57 GMT

에테르7 (대화) 2009년 12월 11일 19:14, (UTC)

그 페이지는 너무 크고 복잡해서 그런 것 같아.허용된 전처리기 노드 수의 거의 절반을 사용한다(Preprocessor node count: 493958/1000000…의 광범위한 사용으로 인해 발생할 수 있다.{{dts}}. 좀 더 간단한 템플릿이나 아예 템플릿이 없는 것으로 교체해 볼 만할 것 같아.Svick (대화) 2009년 12월 11일 19:28 (UTC)

고마워.우리는 현재 리스트에 있는 정보를 응축하는 방법을 찾고 있는데, dts 템플릿이 문제가 될 수 있다는 것을 아는 것이 좋다.날짜 정렬에 사용할 수 있는 더 간단한 템플리트를 알고 있는가?에테르7 (대화) 20:20, 2009년 12월 11일 (UTC)

있다{{dts vgr2}}기사를 이 템플릿으로 바꿨는데, 지금은 전처리기 노드를 훨씬 덜 사용하지만, "Q4 2009"와 같은 날짜와 사용하는 날짜를 "2009"로 바꿔야 했다.{{TBA}}분류를 제대로 하지 않다후자 문제는 그 템플릿을 사용하지 않음으로써 쉽게 해결될 수 있을 텐데, 전자를 어떻게 풀어야 할지 모르겠다.Svick (대화) 22:01, 2009년 12월 11일 (UTC)

훌륭해.시간 초과 오류가 더 이상 안 나와.에테르7 (대화) 22:39, 2009년 12월 11일 (UTC)

이상한 편집 기록

누군가가 Talk의 편집 이력을 볼 수 있을까?잭 사르파티(기사 기록 링크 감시 로그 편집)?98.234.144.82(토크 · 기여 · WHOIS)에 의해 이루어진 두 편집은 최근에 회색으로 지워졌고 로그는 무슨 일이 일어났는지 전혀 알 수 없다.__meco (대화) 08:41, 2009년 12월 12일 (UTC)

그 편집들은 지나치게 관대한 것이었다.∘참말^talk¤ 08:51, 2009년 12월 12일 (UTC)

그렇구나. 바로 그 설명을 듣기 위해 클릭할 수 있는 무언가가 있을 거야.__meco (대화) 09:46, 2009년 12월 12일 (UTC)

음.. 그래, 아마도 툴팁을 특징으로 하는 문자 비트(예: "O" ( ) 또는 편집 필터가 자동 태깅을 하는 것처럼 편집 요약 영역의 끝에 "(과시)"와 같은 것을 붙일 수 있을 것이다.Peachey88^{(Talk Page · Contribs)} 10:08, 2009년 12월 12일 (UTC)

또 다른 혼란스러운 점은 관리자(과시적 편집 내용을 볼 수 없는 관리자)에게만 국한될 수 있다.Special:에서 편집한 왼쪽에는 연결되지 않은 텍스트(del/undel)가 표시됨:기여/98.234.144.82(페이지 기록에는 없음).프라임헌터 (토크) 10:37, 2009년 12월 12일 (UTC)

변경 내용을 되돌리십시오.

http://en.wikipedia.org/wiki/Mary_Magdalene으로 이동

참고문헌을 고치려고 하다가 참고문헌의 거미줄에서 길을 잃었는데 오늘 밤 뇌가 풀림모드로 작동하지 않아.

고마워. —Levalley가 추가한 서명되지 않은 코멘트 준비 (대화 • 기여) 06:22, 2009년 12월 13일 (UTC)

내가 고친 것 같아.Equazcion (대화) 06:30, 2009년 12월 13일 (UTC)

PNG 이미지 표시 문제?

내가 이 페이지를 열었는데 괜찮아 보인다.하지만 같은 페이지로 리디렉션되는 로페즈를 열면 PNG 이미지가 스케일링되지 않고 모든 화면을 차지하게 된다.Firefox, IE, Chrome에서 시도했지만, 똑같이 행동한다.이상해, 이제 2분 후, 파이어폭스는 괜찮아 보이지만 IE와 크롬은 아니야.연결 방법에 따라 다르겠지? Ac25 (대화) 22:35, 2009년 12월 11일 (UTC)

괜찮아 보이는데, FF 3.5.5 ♫ 멜로디아 샤콘네 ♫ (토크) 23:07, 2009년 12월 11일 (UTC)

IE8과 사파리에서도 괜찮다.Intelligentsium 23:10, 2009년 12월 11일 (UTC)

일부 캐싱이 관련된 것처럼 들리는데 - 기사나 이미지가 최근에 수정된 것 같지 않기 때문에 - 원래 문제가 무엇이었는지는 확실하지 않지만 - 서버와 화면 사이의 다양한 캐시가 당신이 수정 사항을 보는 것을 지연시키기 위해 공모한 것 같다. (WP:캐시 통과 참조)

리디렉션은 다른 URL을 가지므로 별도의 브라우저 캐시 항목과 추가 내용("재연결된 위치..." line"), 즉 서버 캐시 엔트리를 분리할 수도 있음. - IMSoP (talk) 19:19, 2009년 12월 13일(UTC)

영어 위키백과에서 사용 가능한 원본 가져오기

이제 Meta와 Oristance Wikipedia에서 이 사이트]로 수정본을 가져올 수 있다.그 기능이 다른 언어 위키피디아로 확장될 수 있다면 좋겠지만, 이것은 매우 좋은 시작이다!Graham87 02:54, 2009년 12월 13일 (UTC)

좋은 소식이야!그러면, 우리는 어디에서 수정본 가져오기 요청을 접수할 것인가?:) –Whitehors1 03:01, 2009년 12월 13일 (UTC)

페이지를 커먼스, 파운데이션위키, 프르위키, 체코위키에서 메타로 가져올 수 있으므로, 그 중 하나에서 이곳으로 옮겨야 할 매우 중요한 것이 있다면(De-Wiki와 En-Wikibooks에서 커먼스로 수입하는 것도 가능하므로, 3-steper는 가능하나 귀찮을 것이다.)MBisanz 03:57, 2009년 12월 13일 (UTC)

또한 페이지 수입에 대한 요청도 만들 것을 제안한다.MBisanz 03:57, 2009년 12월 13일 (UTC)

나는 방금 위키피디아를 대충 편집했다.가져오기 요청.조금 전에 시작했지만 다른 우선순위가 있었다. :-) Graham87 04:10, 2009년 12월 13일 (UTC)

Wikibooks에서 가져오기에 대한 이 페이지에 따르면 가져온 페이지는 "Transwiki:페이지 이름"은 기본적으로.어떻게 하면 이 기능이 활성화될 수 있을까?아니면 내가 뭘 놓치고 있는 걸까?Graham87 05:56, 2009년 12월 13일 (UTC)

나는 그것이 미디어위키와 관련이 있다고 생각한다.구성 설정-wgImportTargetNamespace 또는 MediaWiki:interwiki-namespace 설정 가져오기.MBisanz 06:05, 2009년 12월 13일 (UTC)

향수 위키백과에서 편집본을 가져오는 것은 오래된 사용자 이름에 흥미로운 일을 하는 것처럼 보인다.사용자가 편집한 내용:Larry Sanger는 "Larry_Sanger"라는 사용자 이름으로 여기와 nost.wp에 모두 기록되며, 사용자 이름에 밑줄이 포함된 편집은 Special:기부금.그러나 편집을 가져오면 사용자 이름이 "래리_상어"에서 "래리상어"로 변경되고 정상적인 방법으로 편집에 액세스할 수 있다.특히 2002년 1월 이전 래리 생거의 초기 기부자 명단은 이제 꽤 흥미로워 보인다!모든 편집은 거기서 "래리_상어" 또는 "래리상어"라는 사용자 이름으로 기록되기 때문에 향수 위키백과에 "래리상어"라는 이름으로 녹음된 편집은 없다.버그 323을 참조하십시오.Graham87 14:11, 2009년 12월 13일 (UTC)

부록으로, 나는 밑줄 친 사용자 이름을 고치는 영혼의 목적으로 수입 기능을 사용하는 것을 강력히 권고하고 싶다.개발자들은 그 일을 훨씬 더 효율적으로 할 수 있고, 향수 위키피디아는 2001년 12월 21일 이후 어떤 편집도 하지 않는다.Graham87 14:19, 2009년 12월 13일 (UTC)

이제 독일어, 스페인어, 프랑스어, 이탈리아어, 폴란드어 위키백과에서 개정 이력을 수입할 수 있게 되었다.Graham87 01:14, 2009년 12월 14일 (UTC)

중재위 선거에서 투표할 마지막 기회

이것은 모든 관심 있는 편집자들에게 오늘이 2009년 12월 선거에서 중재 위원회에 새로운 구성원을 선출하는 마지막 날이라는 것을 상기시켜주는 것이다.올해 투표는 SecurePoll 연장을 사용한 비밀 투표로 이루어진다.2009년 11월 1일 이전에 150개 이상의 메인 스페이스 편집이 있었던 차단되지 않은 모든 편집자는 투표할 수 있다(계정 확인).예비 유권자들은 후보 성명서와 후보자들의 개별 질문 페이지를 검토하도록 초대된다.투표는 비밀투표로 진행되며, 이런 방식으로 제출된 투표만 집계되지만, 후보자들의 댓글에 간략한 댓글을 남기고, 첨부된 토크 페이지에 후보들을 길게 토론하는 것이 초청된다.투표 설정과 관련하여 질문이나 어려움이 있을 경우, 선거 토크 페이지에서 문의하십시오.라이브 토론은 프리노드에서 #위키피디아-엔에스에 참여한다.

업데이트: 투표 기간은 12월 1일에 시작되었으며 2009년 12월 14일에 종료된다.그러나 SecurePoll 연장의 구성으로 인해 투표 기간은 2009년 12월 14일 이전에 발표된 23:59 UTC까지 연장되지 않을 수 있다.소프트웨어 개발자들에게 연락이 왔고 우리는 투표 기간을 2주 전체로 연장하는 작업을 하고 있다.이 메시지는 그러한 변화를 반영하기 위해 업데이트되지만 개입을 제외하고 2009년 12월 14일(오늘밤 자정) 00:00 UTC 이후 투표는 소프트웨어에 의해 수락되지 않을 것이다.

다음 링크를 따라 투표에 참여하십시오.

코디네이터의 경우 2009년 12월 13일(UTC)

FF의 지도 표시 문제가 잘못됨

나는 헬프 데스크에서 이 문제에 대해 물어봤고 IRC를 통해 지원을 받았지만 이 문제를 해결하지는 못했다.파이어폭스(3.5.5) 사용 & 브롬튼 레지스 & 기타 기사의 빨간색 위치 도트에 로그인할 때 카운티의 경계 밖에 있다.나는 도로 지도에 있는 좌표를 확인했고 그것들은 정확했다.로그인하지 않았거나 IE8을 사용하여 로그인한 경우 이 문제는 발생하지 않는다.사용자를 제거했다는 조언에 따라:AndyZ/peerReviewer.js는 내 모노북 & 클리어 캐쉬에 아무런 변화 없이 저장된다.어떤 조언이라도 고맙게 생각했다.— 로드 15:40, 2009년 12월 13일 (UTC)

User(사용자)디스펜서/altextexplorer.js 모노북.js에 있는 디스펜서/altexplorr.js.제거하면 고쳐야 한다.Svick (대화) 15:52, 2009년 12월 13일 (UTC)

고맙게도 고쳐준 것 같다.해결됨— 로드 18:49, 2009년 12월 13일 (UTC)