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

Wikipedia:

크베타 페슈케가 잘못 발음했다.

현재 Kvta Peschke를 향해 있는 모든 링크를 Květa Peschke로 직접 연결하도록 하기 위해 봇을 사용하는 것이 가능한가?당연하지, 이미 리디렉션되어 있지만, 체코어의 정확한 철자는 ě가 있는 Květa Peschke이며, "ě"를 읽을 수 있는 지의 기사에서는 더 좋을 것 같아. --Vole (토크) 10:40, 2009년 1월 25일 (UTC)

  • 또한, 이것과 같은 비슷한 케이스가 수천 개 있는데, 이름에서 담배가 빠져 있다. 아마도 나는 많은 것을 재생시키는 봇을 사용할 수 있을 것이다.이 봇을 어떻게 시작해야 할까? --Vole(토크) 10:43, 2009년 1월 25일(UTC)
위키피디아로 이동하십시오.봇 요청.청발 변호사 11:03, 2009년 1월 25일 (UTC)

철자 교정기를 만드는 것의 문제는 어떤 링크에 달려있는지에 달려있다. 너무 많은 게으른 (점화되지 않은) 철자는 링크의 일부가 아니기 때문에 봇에 의해 완전히 무시될 것이다.CharlotteWebb 13:40, 2009년 1월 25일 (UTC)

검색 중

자주 사용하는 사용자로서 드롭다운 목록을 참조하고 싶을 때마다 주어를 입력해야 하는 것이 답답하다.주제를 다시 입력하기 위해 드롭다운 목록으로 돌아가기 위해 내가 사용할 수 있는 방법이 있는가?

고마워, 월리 in Iowa173.20.5.142 (토크) 13:45, 2009년 1월 25일 (UTC)

검색 상자에서 수행한 이전 검색 목록을 말하는 겁니까?보통 몇 글자만 입력하면 나타나는데, 그 뒤에 화살표 키를 사용하여 하나를 선택할 수 있다. - Mgm (토크) 14:34, 2009년 1월 25일 (UTC) Special:PrefixIndex가 관심사일 수 있음.프라임헌터 (토크) 2009년 1월 25일 (UTC) 14:52, 25


아니, 검색에 입력해서 드롭다운을 받고 선택해서 기사를 얻는다.그리고 나서 나는 가끔 그 주제에 대한 다른 기사를 위해 드롭 다운으로 돌아가고 싶지만, 드롭 다운을 다시 받기 위해 원래 검색어를 입력해야 한다.Wallace Fiala추가서명되지 않은 논평 준비 (대화 • 기여) 2009년 1월 25일 (UTC)

자동 결과 기능을 끄면 기본적으로 보어의 저장 목록이 표시되며, 이 경우 간단히 두 번 클릭하고 원하는 항목을 선택할 수 있다.♫ 멜로디아 샤콘네 ♫ (토크) 18:08, 2009년 1월 25일 (UTC)

AWB 타이포스

나는 최근에 오자를 교정하는 기능을 여기에 추가했다.이것은 내가 피해야 할 것이, 다른 것을 하기 위해서, 비원어적(오류의 여지가 있는 - 원주민들이 나보다 훨씬 더 섹시하게 철자를 쓰는 것)으로서 더 나은 것이 아닌가?또한, 내가 잘못하고 있는 것 같아. 그리고 내 모노북 피부는 나에게 아주 새롭고, 이 모노북 링크는 그렇게 완벽하지 않았던 것 같아.이해해 줬으면 좋겠는데, 모노북에 대해 이런 식으로 시간을 낭비하고 있는 것 같아.기사 쓰는 게 더 나을지도...이 웹사이트는 이해할 수 없는 미친 마음-바글러다!!--Voletyvole (토크) 21:57, 2009년 1월 25일 (UTC)

센터링 클래스="유익한 정렬 가능"

어떻게 수업의 중심을 잡으십니까?고마워 Ikip (토크) 02:01, 2009년 1월 26일 (UTC)

1 2
3 4
이렇게요?CharlotteWebb 02:38, 2009년 1월 26일 (UTC)
고마워!!!Ikip (대화) 03:00, 2009년 1월 26일 (UTC)

CfDs 이후의 메시지

CfD에 이어 카테고리가 이동되면 봇은 이전 카테고리의 작성자를 나열하는 메시지를 새 카테고리에 남긴다.예를 들어,

"로봇: 카테고리에서 이동:우주 거래 및 전투 시뮬레이션 게임.저자: 진통자, 마라스무신, 사이데봇, 에프², 샤크D"

내 질문은, 이름이 어떤 순서로 나열되어 있는가?편집한 순서대로 나열되어 있는가?연대순으로 "첫" 편집자는 누구인가?SharkD (대화) 2009년 1월 22일 10시 15분 (UTC)

봇이 어떻게 쓰느냐에 따라 달라진다; 그들 모두가 작가를 나열하는 것은 아니다.이 경우 사용자에게 다음과 같이 물어보겠다.사이드, 우주 거래 범주를 옮긴 것은 그의 봇이었기 때문에. --Kbdank71 16:25, 2009년 1월 22일 (UTC)
아, 그렇구나.고마워요.SharkD (대화) 03:15, 2009년 1월 23일 (UTC)

기침, 기침.우리가 범주를 이동시킬 수 있는 몇 가지 기본 방법을 가지고 있을 때가 되었다.이상적으로 리디렉션은 템플릿 리디렉션뿐만 아니라 작동될 것이다.즉, 이전 범주 이름을 사용하는 기사는 즉시 업데이트할 필요가 없는 기사의 위키텍스트를 제외한 모든 측면에서 새로운 범주 이름을 사용하는 것으로 나타날 것이다.이미지도 마찬가지일 텐데… — CharlotteWebb 03:19, 2009년 1월 25일 (UTC)

카테고리를 이동하면 편집 내역이 보존된다면 나는 만족한다.SharkD (대화) 06:03, 2009년 1월 27일 (UTC)

이 페이지 맨 위에 있는 검색 상자

이 사실을 눈치챈 사람이 있는지 모르겠지만, 이 글의 상단에 있는 검색 필드에 일부 텍스트를 입력하고 간단히 'Enter'(즉, 실제로 버튼을 클릭하지 않고)를 누르면 검색 결과 대신 입력한 텍스트와 동일한 이름의 기사로 자동 이동된다.(Internet Explorer 7) SharkD()k) 2009년 1월 23일 19:53, (UTC)

예, 기본 동작은 "검색"이 아닌 "Go"이기 때문에. - JmabelTalk 19:56, 2009년 1월 23일 (UTC)
혼란스러워서 미안한데, "마을 펌프스 검색" 박스를 말하는 거야.SharkD (토크) 21:04, 2009년 1월 23일 (UTC)
이것은 이전에 헬프데스크에서 보고되었다.나는 IE가 망가진 것을 후회하는 것 외에 다른 어떤 조치가 취해질 수 있을지 모르겠다.대수학자 00:16, 2009년 1월 24일 (UTC)
우리 시스템에서 이것을 bugzilla:17161 --briion (대화) 17:44, 2009년 1월 26일 (UTC)

수배자: 실업자 인섬니아

for: Montbard Arrondisse에서 홀수 번호 지정 및 간격 정리
보상:오른쪽에서 그 노래를 들을 수 있다.
죽거나 살았거나.에디 보안관 (Howdy Partners!) 02:04, 2009년 1월 25일 (UTC)

내가 물게.구체적으로 무엇을 해야 하는가? -- Tcncv (대화) 04:46, 2009년 1월 25일 (UTC)
WP는 그렇게 생각하지 않는다.NFCC는 마을 펌프에 오디오 샘플을 "표시"할 수 있도록 허용한다.CharlotteWebb 05:13, 2009년 1월 25일 (UTC)
어쨌든.아르론분산 테이블에서 표를 보면 대부분이 3열로 되어 있지만 일부는 4열로 되어 있고 다른 일부는 2열로 되어 있다는 것을 알 수 있다.작은 두 개의 공동체가 합병되면서 새로운 공동체가 추가되었기 때문에 번호 매기기도 엉망이다.~EDDY ~ 01:40, 2009년 1월 26일 (UTC)
사건을 해결한다.그 기사에 대해서는 나는 공동체에 수동으로 번호를 매기지 않고 그것을 세 개의 열로 나누는 어떤 보편적으로 받아들여지는 방법을 알지 못한다. 그것은 리스트가 변경될 수 있다면 상당히 궁색한 것이다.또한 리스트를 복사하여 붙여넣는 사람은 아마도 앞쪽에 있는 숫자를 포함하기를 원하지 않을 것이다.알파벳 리스트인 만큼 숫자가 필요하거나 의미가 없는 것은 아닌지 의심스럽다.아마도 84개의 하드 컬럼으로 나누어 별표를 붙이는 것이 가장 좋을 것이다.CharlotteWebb 16:37, 2009년 1월 26일 (UTC)

링크로서의 이미지

해결됨
ukexpat (대화) 02:10, 2009년 1월 26일 (UTC)

나는 기둥 헤더를 90도 회전시켜야 하는 표를 만들었다.내가 위키피디아에서 사용하는 것을 관찰한 크로스브라우저 방법은 셀 텍스트 대신 SVG 이미지를 사용하는 것이다.하지만 한 가지 문제가 있는데, 보통 이미지를 클릭하면 방문자들이 이미지를 보기 위해 페이지로 이동한다는 것이다.방문자가 다른 (즉, 임의) 페이지로 이동하도록 변경하려면 어떻게 변경해야 하는가?고마워요.SharkD (대화) 14:08, 2009년 1월 25일 (UTC)

ImageMap 확장 사용.Graham87 15:56, 2009년 1월 25일 (UTC)
고마워지금 문제는 이 기술이 어느 기사에 쓰였는지 기억이 안 난다는 것이다.수직 방향 텍스트(실제로 SVG 파일)가 맨 위에 있는 테이블을 본 사람이 있는가?이미지 자체의 크기/크기화에 대해 좀 더 자세히 살펴보고 싶다.SharkD (대화) 2009년 1월 25일 16:59, 25 (UTC)
신경 쓰지 마.나는 그 기사를 찾았다.SharkD (토크) 17:16, 2009년 1월 25일 (UTC)

향후 참조를 위해 표 도움말 페이지에 이 작업이 어떻게 수행되는지 설명하는 섹션을 추가했다.SharkD (토크) 01:47, 2009년 1월 27일 (UTC)

SVG 래스터라이저에서 사용하는 글꼴

SVG 래스터라이저에서 사용하는 글꼴은 어디에서 찾을 수 있는가?내 로컬 시스템에서 이미지를 만들 때 InkScape는 내 로컬 글꼴을 사용하는데, 이것은 위키백과에서 사용하는 글꼴과는 다르다.고마워요.SharkD (대화) 2009년 1월 25일 19:26, 25 (UTC)

m:SVG 글꼴을 참조하십시오. --dapete 21:01, 2009년 1월 25일(UTC)
알았어, 고마워.SharkD (토크) 23:31, 2009년 1월 26일 (UTC)

OGM 파일

나는 최근에 슈퍼를 이용하여 MP4 비디오를 OGM 포맷으로 변환했지만, 위키백과/위키메디아 커먼즈는 OGG와 OGV 파일만 받아들인다. (그리고 슈퍼는 OGG나 OGV 비디오로 변환할 수 없다.).ogm과 .ogv의 차이점은?위키피디아가 OGM(OGG 또는 OGV만큼 무료)을 받지 않는 이유가 있는가? -- -- 19:59, 2009년 1월 25일 (UTC)

VLC 미디어 플레이어에 내장된 트랜스코더 사용Geni 01:30, 2009년 1월 26일(UTC)
모두 하나의 동일한 형식이고 파일 확장명이 다를 뿐이지ogg는 오디오 보르비스의 원래 형식이다.ogm은 이 파일 형식에서 비디오/비디오 및 메타데이터를 처리하기 위한 일부 확장자를 포함한다.동일한 파일 형식이지만, 사양서의 "최소한" 버전이라고 말할 수 있을 것이다. .ogm은 공식적인 파일 확장자는 아니지만, 이러한 파일들을 순수한 ogvorbis 오디오 파일과 구별하기 위해 파일 확장자로 널리 사용되었다.ogv와 oga는 현재 순수 오디오(.oga .spx)와 오디오/비디오/비디오/비디오(.ogv) 파일을 구별하기 위해 제안된 "새로운" 파일 확장명이다.그러나 본질적으로, 그것은 모두 "다양한" 종류의 메다를 포함할 수 있는 하나의 파일 형식이다.참고 항목 [1] --DJ (대화 기여) 11:19, 2009년 1월 26일 (UTC)
또한 .ogm 파일에는 자주 비사용 코덱이 포함되어 있다는 점에 유의하십시오.실제로 비디오 코덱으로 Theora를 사용하고 오디오 코덱으로 Vorbis를 사용하고 있는지 확인하십시오. --briion (토크) 17:38, 2009년 1월 26일 (UTC)

알파벳 문자 템플릿

다음과 같은 템플릿이 있는가?

?
암호: {{?}}

알파벳의 각 글자에 대해?고마워 Ikip (토크) 02:03, 2009년 1월 26일 (UTC)

지금까지 나는 다음과 같은 것을 발견했다.
{{A-classicon}}
{{B-classicon}}
{{C-classicon}}
Class D fire icon.svg
이킵 (토크) 02:07, 2009년 1월 26일 (UTC)
첫 번째 세 가지는 파일 이름으로 판단하여 기사 분류 템플릿에 사용된다.ukexpat (대화) 02:12, 2009년 1월 26일 (UTC)
위키콤에서 이 사진들을 찾았는데, 그냥 템플릿만 만들면 돼.

Gross A.jpg Gross B.jpg Gross C.jpg Gross D.jpg Gross E.jpg Gross F.jpg Gross G.jpg Gross H.jpg Gross J.jpg Gross K.jpg Gross L.jpg Gross M.jpg Gross N.jpg Gross O.jpg Gross P.jpg Gross Q.jpg Gross R.jpg Gross S.jpg Gross T.jpg Gross U.jpg Gross V.jpg Gross W.jpg Gross X.jpg Gross Y.jpg Gross Z.jpg

고마워. Ikip (토크) 02:14, 2009년 1월 26일 (UTC)
템플릿 생성:템플릿:그로스_AIKIP (토크) 03:00, 2009년 1월 26일 (UTC)
참고 항목: 공통:범주:라틴 문자.프라임헌터 (토크) 2009년 1월 26일 (UTC)

사진이 수직이 아닌 수평인 템플릿 만들기

템플릿을 만드는 중:사용자:Ikip/n {{ARS-userpage}} 템플릿이 내장되어 있음.사용자:와 같은 모든 작은 사진들이 정렬되도록 시도하고 있다.피오투스/탑 또는 사용자:여기서 Peteforsyth의 상:

This user helped "Oregon State Capitol" become a featured article.This user helped "1984 Rajneeshee bioterror attack" become a featured article.This user helped "Johnson Creek (Willamette River)" become a featured article.This user helped "Hanford Site" become a featured article.This user helped "Portal:Oregon" become a featured article.This user wrote "Columbia River", which became a good article.This user wrote "Neil Goldschmidt", which became a good article.This user wrote "Barlow Road", which became a good article.This user wrote "Fern Hobbs", which became a good article.This user wrote "Celilo Falls", which became a good article.This user wrote "The Register-Guard", which became a good article.This user wrote "Portland City Hall (Oregon)", which became a good article.

현재 사진은 수직이며, {{사용자:이킵/n 오리건 무스 캐나다}}.

{{사용자의 코딩 수정 방법:이킵/n}}?

참고 항목: 수평으로 사진 허용 가능:

템플릿 사용 시작.이킵 (토크) 04:58, 2009년 1월 26일 (UTC)

일차적인 문제는 이것이 이미지 맵을 사용하고 있다는 것이다.imagemap은 결과를 div에 포함시키는 역겨운 habbit을 가지고 있다. 당신은 이러한 여러 개의 imagemap div를 {{User:이킵/n}}.그것이 문제를 일으키고 있다.구현이 사용자와 다름:Piotrus/Top 등 이러한 모든 사용이 각각의 단일 기호(이미지맵 div) 주위에 개별 "인라인" div를 가지고 있는 반면, 당신은 모든 기호에 "인라인" div를 한 번에 감싸고 있다. --DJ (토크기여) 11:37, 2009년 1월 26일 (UTC)
Face-smile.svg 고마워, 네가 말한 것을 토대로 지금 어떻게 고쳐야 할지 잘 모르겠지만, 내가 올바른 방향을 가리키고 있어.직접 고쳐줘서 고마워:) 이킵 (대화) 14:39, 2009년 1월 26일 (UTC)
사실, 해결된 게 아니라 태그를 제거했는데...더 이상의 도움은 감사할 것이다.Ikip (토크) 2009년 1월 26일 19:04 (UTC)
나는 잔돈을 다 썼다. (오늘 오후에 시간이 없었다.)하지만 기억해...이 모든게 아주 망가졌어그리고 그것은 페이지의 같은 영역을 사용하기 때문에 깃발들이 도착하면 더 깨질 것이다.플래그 지정된 개정판이 도착하면, 우리는 이 모든 아이콘으로 무엇을 하고 싶은지, 그리고 어떻게 그것들을 "적절하게" 사용할 것인지에 대해 정말로 생각해야 할 것이다.물론 지금은 다른 피부에서도 작동하지 않는다. --DJ (토크기여) 20:40, 2009년 1월 26일 (UTC)

신뢰할 수 있는 웹사이트 내에서만 검색하는 검색 엔진?

나는 틈새 주제에 대한 믿을 만한 출처를 찾기 위해 구글을 자주 이용한다.그리고 대부분의 경우 구글은 블로그와 포럼의 바다를 돌려주는데, 나는 "파이낸셜 타임스"나 "ieee.org"과 같은 신뢰할 수 있는 웹사이트를 찾기 전에 12페이지의 결과 페이지를 확인해야 한다.

신뢰할 수 있는 웹 사이트 내에서만 검색하는 검색 엔진이 있는가? 여기서 "신뢰할 수 있는" 검색은 실제로 편향되어 있지 않으며, 일부 웹 사이트는 신뢰할 수 있는 출처로 분명히 받아들여지고 있으며, 우리는 합의에 근거하여 목록을 작성할 수 있다.신뢰할 수 있는 모든 웹사이트의 목록을 쓰는 것은 불가능하지만, 100개의 신뢰할 수 있는 웹사이트는 일반적인 주제에 충분할 것이다.신뢰할 수 있는 웹사이트의 목록은 시간이 지남에 따라 위키피디아 사람들에 의해 개선될 수 있다.

그러한 검색엔진이 존재하는가?그렇지 않다면, 구글과 필터를 기반으로 한 빠른 매쉬업을 만들 의향이 있는가?힌트/아이디어/협조에 감사 :-) 니콜라스1981 (토크) 11:25, 2009년 1월 26일 (UTC)

구글 뉴스 a 구글 스콜라(Google Scraft)는 대부분 신뢰할 수 있는 결과를 주지만, 확실히 모든 신뢰할 수 있는 사이트를 다루지는 않는다. --Apoc2400 (대화) 12:26, 2009년 1월 26일 (UTC)
나는 그들에게 시도했고, 구글 뉴스가 단지 뉴스 웹사이트만 포함하고 다른 레퍼런스 웹사이트는 포함하지 않음에도 불구하고 어떤 경우에는 유용하다는 것을 알게 되었다.고마워! 니콜라스1981 (토크) 02:45, 2009년 1월 27일 (UTC)
Pubmed, JSTOR(접근 권한이 있는 유니에 있는 경우).Geni 17:54, 2009년 1월 26일 (UTC)
내 생각엔 의학적 연구 기사를 쓸 때 퍼블리싱이 유용할 것 같아.나는 JSTOR에 접근할 수 없지만 그것이 북미 도서관의 소장품들에 접근할 수 있다는 것을 상상할 수 있다.내가 설명한 검색엔진의 힘은 특정 컬렉션을 보지 않고, 대규모의 참조 웹사이트에서는 편집자들이 확인할 수 있는 것보다 훨씬 많은 웹사이트를 볼 수 있다는 것이다.이것은 당신의 질의와 일치하는 것을 찾을 확률을 크게 증가시킬 것이다.고마워 :-) 니콜라스1981 (대화) 02:45, 2009년 1월 27일 (UTC)

사진

기사에 사진을 추가하고 싶은데 방법이 없어 보인다.

그래, 내가 가서 새로운 아이디와 그 모든 헛소리들을 만들었어. 지금 나는 단지 [기사와 함께 그것을 넣고 싶어 — Koibetu추가서명되지 않은 코멘트 준비 (토크 기여) 2009년 1월 26일 (UTC)

WP에서 설명한 대로 이미지를 업로드했는가?업로드? – ukexpat(대화) 15:55, 2009년 1월 26일(UTC)

견적서 관련 문제

Taking Tiger Mountain (전략별)의 인용구에 어떤 문제가 있는지 설명해 주시겠습니까?앨범 템플릿과 겹치는 것 같아.(Firefox 3.0.4를 사용하고 있다.) 이 부분에 대해서는 어떤 방법이 없을까?Anness, —Mattisse (Talk) 20:54, 2009년 1월 26일 (UTC)

흰 공간을 더하는 것일 수도 있지만 문제가 해결된 것 같은 {{clear}}를 추가했다.Mattisse (Talk) 21:16, 2009년 1월 26일 (UTC)
{{quote box}} 템플릿 코드를 사용하여 박스를 50% 페이지 너비로 왼쪽 정렬해 보았지만 제대로 작동하지 않았다.ukexpat (대화) 21:36, 2009년 1월 26일 (UTC)
{{}}}}의 끝과 다음 줄 사이에는 줄 바꿈이 없었다.BTW: {{quote box2}}: 더 많은 기능이 있다. --— Gadget850 (Ed) - 21:48, 2009년 1월 26일 (UTC)
이제 상자의 맨 윗줄은 위의 텍스트의 마지막 줄(Firefox 2.0.0.20)과 약간 겹친다.ukexpat (대화) 22:38, 2009년 1월 26일 (UTC)
적어도 내 브라우저에서는 <블록케쿼트>를 사용하는 것이 그렇게 하는 것 같다.Mattisse (Talk) 22:45, 2009년 1월 26일 (UTC)
그건 나한테 효과가 있어.ukexpat (대화) 03:30, 2009년 1월 27일 (UTC)

"제안" 섹션의 두 제안의 기술적 타당성

기술적으로 얼마나 실현 가능한가?

  1. 편집하기 위해 다른 탭과 다른 색상으로 "편집" 탭을 더 크게 또는 강조 표시하시겠습니까?
  2. "랜덤 아티클"과 같은 역할을 하지만 지정된 범주 내에서 또는 지정된 포털 또는 위키피디아 제목의 영역 내에서 기능을 추가하시겠습니까?

고마워, » šῥъъτ ¢ 19:45, 2009년 1월 25일 (UTC)

2번은 잘 모르겠지만 1번은 아주 쉽다.모든 관리자는 MediaWiki로 이동하십시오.기능 표시 방법 편집 및 변경. -- 킹 오브 20:01, 2009년 1월 25일 (UTC)
사실, 미디어위키:편집은 편집 탭의 텍스트만 제어하며, 내가 아는 한 일반 텍스트 입력만 허용한다.MediaWiki를 사용해야 할 경우:모노북.css의 색상이나 크기를 변경할 것.{{Nihiltres talk log}}}20:23, 2009년 1월 25일 (UTC)

Nihiltres는 인터페이스 페이지에 대해 정확하다.만약 누군가가 그것을 만들고 싶다면, 범주 내에서 무작위 기사를 얻는 것은 재미있는 도구 서버 가젯이 될 것이다.http://toolserver.org/과 같은 링크를 포함하십시오. somebody/randompage.php?cat=Living_people(또는 현재 진행 중인 내용)에서 사이드바에 연결하십시오.이것은 적어도 BLP가 새로운 차원을 순찰할 수 있게 해줄 것이다.만약 이것이 잘 작동하고 인기 있는 것으로 입증된다면 아마도 메인 소프트웨어에 추가될 수 있을 것이다.CharlotteWebb 16:51, 2009년 1월 26일 (UTC)

이 도구 http://tools.wikimedia.de/~erwin85/php는 주어진 범주의 임의의 기사를 제공할 것이다.이 링크는 무작위 BLP를 제공한다. --픽셀페이스(토크) 23:44, 2009년 1월 26일 (UTC)
아, 태양 아래 새로운 것은 없다.CharlotteWebb 03:22, 2009년 1월 27일 (UTC)
위키북은 사이트 JS에서 좀 진부한 일을 한다.대상 범주 중 하나(38개) 내에서 페이지를 찾을 때까지 쿼리 계속을 통해 (클라이언트 측, API를 통해) 생성기=랜덤을 검색하여 "랜덤 북"을 제공하지만, 이는 모든 NS_MAIN 비간접 페이지 중 약 10%가 해당 범주 중 하나에 있기 때문에 작동한다.여기에는 Category와 같이 실현 가능한 몇 가지 카테고리가 있다.살아 있는 사람들. --Splarka (rant) 08:15, 2009년 1월 27일 (UTC)

보안 서버가 다운되었나?

보안서버를 방문하면 503을 받지만, 일반 서버에서는 503을 받는다.wikipedia.org은 잘 작동한다.그게 무슨 일인지 아는 사람?(왜 내가 잘못된 섹션에 있다고 느끼는지...) Elm-39 - T/C 13:47, 2009년 1월 27일 (UTC)

지금 나한테는 잘 되고 있어.대수학자 14:23, 2009년 1월 27일 (UTC)
여기도 마찬가지야.과부하인가 봐Elm-39 - T/C 18:17, 2009년 1월 27일 (UTC)
편집: 워, 데이터베이스 서버 지연 시간이 1,986초입니다.그건... 30분 정도야무슨 일인지 궁금하군...Elm-39 - T/C 18:51, 2009년 1월 27일 (UTC)

기본 범주의 사용자 페이지

Bobbylow의 사용자 페이지에는 몇 가지 주요 범주가 있다(보안, 형식 과학 등).내 생각에:

  • 이제 우리는 범주를 제거해야 한다.
  • 봇은 사용자 페이지가 포함되지 않도록 범주를 감시해야 한다.
  • 더 나은 해결책:자동으로 이를 방지하는 확장 또는 패치.예: 카테고리 페이지에 (<includeuser pages/>와 같은) 특별한 태그가 없는 경우 반드시 포함하지 마십시오.
Eloy (대화) 2009년 1월 27일 16:06, (UTC)
내 생각에 그건 기사 초안인 것 같아.Elm-39 - T/C 18:20, 2009년 1월 27일 (UTC)
사용자:의 하위 페이지로 이동:바비로우/크립토그래피ukexpat (대화) 19:18, 2009년 1월 27일 (UTC)

"(마지막 변경) 새로운 메시지가 있으십니다."가 자꾸 돌아오다.

해결됨

새 메시지를 봤는데, 오렌지 바가 계속 무작위로 나온다. - 페레그린 피셔 (토크) (기적) 2009년 1월 27일 (UTC) 19:06

나도 알아. 일시적인 서버 문제인 것 같아. 걱정하지 않을 거야.ukexpat (대화) 19:19, 2009년 1월 27일 (UTC)
기여금이 지연되었다. 아마도 관련이 있을 것이다. --NE2 19:59, 2009년 1월 27일(UTC)

변경 내용이 즉시 표시되지 않음

해결됨

내가 새로운 페이지를 만들었을 때, 내가 그것을 저장한 후 위키피디아는 그 페이지가 존재하지 않는다고 말한다.이것은 보통 몇 분 안에 맑아진다.몇 주 전에 같은 걸 봤어. davidwr/(토크)/(기여)/(이메일) 20:30, 2009년 1월 27일 (UTC)

↑. – ukexpat(대화) 21:05, 2009년 1월 27일(UTC) 바로 위의 게시물을 참조하십시오.
다시 로드해 보십시오.일부 브라우저는 이전 페이지를 캐시한다. 199.125.109.64 (토크) 02:38, 2009년 1월 28일 (UTC)
일찍이 엄청난 지연이 있었다. 신경(talk) 02:48, 2009년 1월 28일 (UTC)

에이커에서 km2로의 자동 전환이 제대로 작동하지 않음

Green tickY - 해결됨

그레이트 스모키 산맥 국립공원 페이지에서 나는 244,442에이커의 전환이 990.44 km²를 주는 것을 보았는데, 이는 잘못된 것이다.오른쪽 수치는 99.044㎢이다.사용되는 위키 함수는 244,742에이커(990.44km2)이다.그 프로그램은 이번에는 10배의 오류 요인을 제공한다.나는 이것이 하나의 오류인지 아니면 체계적이었는지 모르겠다.누가 이 문제를 좀 봐줄래?감사합니다, --Gabodon (대화) 21:31, 2009년 1월 27일 (UTC)

1에이커 = 0.00404685642 평방 킬로미터. 244,442 에이커 = 989.120 평방 킬로미터.공식에 반올림 또는 사소한 오류까지 차이를 기록하십시오.그런데 640에이커=1평방마일, 약 2.56평방킬로미터=1평방마일이다.계산을 해보면, 250에이커 = 1평방킬로미터, 그래서 990.44 평방킬로미터가 오른쪽으로 보인다. davidwr/(토크)/(contracties)/(e-mail) 22:01, 2009년 1월 27일 (UTC)
맞아, 하지만 이탈리아에서는 쉼표를 사용하여 소수점을 분리해서 244.442에이커(2,400.44에이커)로 읽었어.다 설명되었어, 고마워. --가보돈 (대화) 22:08, 2009년 1월 27일 (UTC)

자동 변환 링크

WP 사이드바의 언어간 위키 링크 옆에 구글 머신 번역 링크가 제공될 것을 제안하고 싶다.SharkD (대화) 03:23, 2009년 1월 21일 (UTC)

왜 기계 번역이 바람직한가?{{Nihiltres talk log}}} 03:35, 2009년 1월 21일 (UTC)
그래, 이런 백과사전을 말할 때는 컴퓨터 번역을 사용하는 것이 더 좋지 않아.최소한으로 말하는 것은 부정확하며, 구글 번역은 수작업으로 더 나은 번역을 제안한다는 점에서 위키피디아만큼 개방적이지 않다.
그렇긴 하지만, 난 샤크D의 이유를 기다리고 있어.HHALDaяtatalktalk2mecontracts 20:44, 2009년 1월 21일 (UTC)
이것은 아마도 편집자들에게 더 유용할 것이다 - 당신은 기사를 프랑스어 버전과 비교할 수 있고 영어로 누락된 프랑스어 버전에 어떤 정보가 있는지 볼 수 있다.아마도 이 기능은 사용자 스크립트나 가젯으로 가장 잘 구현될 것이다.트라 (토크) 23:06, 2009년 1월 21일 (UTC)
그 이유는 신뢰할 수 있는 정보가 그곳에서 발견될지도 모른다는 의심이 들 때 다른 언어 위키에서 검색하는 간단한 방법을 원하기 때문이다.확장해야 할 일본 비디오 게임 스텁이 많다.SharkD (대화) 08:03, 2009년 1월 28일 (UTC)
구글 툴바에 이런 기능이 있는 줄 알았는데?청발 변호사 23:40, 2009년 1월 21일 (UTC)
나는 위키 페이지에 번역 링크를 추가하는 자바스크립트를 가지고 있다. (그래서 당연히 로그인해야 한다—Go-go SUL…)CharlotteWebb 04:02, 2009년 1월 25일 (UTC)
이 링크를 사용하려면 먼저 대상 페이지를 로드해야 하는가?SharkD (대화) 08:03, 2009년 1월 28일 (UTC)

수정본 다시 작성

이봐, 내가 궁금한건 왜 이 두개의 수정본들이 빨간색으로 표시되는가?나는 어떤 변화가 있었는지 정말 알기 어렵게 만든다.[2] LoveMonkey (talk) 05:23, 2009년 1월 26일 (UTC)

미디어위키는 웬일인지 오른쪽의 텍스트가 왼쪽의 텍스트로 대체되었다고 생각하지만, 실제로는 작은 덧셈밖에 없었다...캘빈 1998 05:54, 2009년 1월 26일 (UTC)
아마도 그 단락이 너무 길었기 때문일 것이다.그것은 미디어위키를 완전히 혼란스럽게 했을 것이다.이것, 저것, 그리고 나머지 06:42, 2009년 1월 26일 (UTC)
헷갈린다.어떻게 할 수 있을까?무례한 의도는 아니었어, 약속할게.또한, 왜 이 한 편집자의 편집이 모두 이렇게 계속 되었는가?이제 엘프 하나?같은 기사에 대한 나의 편집은 기사의 다른 편집자들뿐만 아니라 이런 식으로 나타나지 않는데, 왜 이 편집자만 있는 것일까?또한 이제 그것은 멈췄다.[3] 누구한테 갈까, 이거 고쳐줄까?선의로 나는 증거를 편집하지 않는 한 사람들이 시스템을 게임을 한다고 비난하는 것을 좋아하지 않는다.편집한 내용에서 편집자가 이 (이슈)에 대한 통제권을 갖는 것은 편집한 내용에서 나타난다. 왜냐하면 편집한 내용에서 유일하게 편집한 결과를 얻었기 때문이다. 그리고 이제 내가 불평한 후에 그들은 이 작업을 중단했다.LoveMonkey (토크) 2009년 1월 26일 (UTC)
긴 단락의 편집은 정확히 동일한 수정 효과를 가진다: 당신이 방금 [4]에서 한 모든 것을 보라.소이디 (토크) 2009년 1월 26일 16시 19분 (UTC)

아마도 디프 제너레이터에는 어떤 종류의 바이트 제한이 있을 것이고, 그 이후에는 각 "라인"의 유사성과 차이점을 확인하는 데 번거로움이 없을 것이다.CharlotteWebb 16:58, 2009년 1월 26일 (UTC)

:
보아하니 이 한계는 오래전 2005-08-31년에 팀 스타링에 의해 추가되었다.우리는 그에게 이것이 여전히 필요한지 물어볼 수 있다.당신이 편집하고 있던 단락은 약 15,000개 입니다.나눠서 하는 게 좋을 거야문단 분리를 원하지 않을 경우, 참조 태그 내부 또는 이와 같은 html 주석 내부에 줄 바꿈을 추가할 수 있다.이것은 페이지를 볼 때 무시되지만 적어도 분산 보기를 덜 부담스럽게 하기 위해 문단을 위키 텍스트의 여러 "줄"로 나눌 것이다.CharlotteWebb 17:14, 2009년 1월 26일 (UTC)

왜 댓글을 달아?한 줄만 끊어도 괜찮을 거야...Werdna대화 09:16, 2009년 1월 28일 (UTC)

MediaWiki 소프트웨어 오류

MediaWiki 소프트웨어에는 사용 중인 파일을 고아로 잘못 표시하는 버그가 있다.따라서 이와 같이 표시된 공정 사용 파일은 신속하게 삭제된다.누가 이걸 고칠 수 있을까?(짐보 웨일스가 내 첫 번째 추측이겠지만 확실하지는 않다.)제대로 업로드되고 사용 중인 파일의 전체 시리즈가 고아로 표시되었기 때문에 빠르게 삭제되었다.그러니 누구와 어디로 가야 할지 누가 가리켜줄 수 있다면 정말 좋을 것이다.고마워. -BlueCaper (대화) 02:59, 2009년 1월 28일 (UTC)

이것은 버그가 아니다. 단지 페이지를 제거하면 된다. 신경(talk) 03:06, 2009년 1월 28일 (UTC)

지미는 기술적인 문제에 전혀 관여하지 않는다.Werdnatalk 01:21, 2009년 1월 29일 (UTC)

정렬 가능한 Wikitable에 열 중앙 집중화

여자 테니스 선수 명단에서 우리는 큰 재포맷 작업을 하고 있고 분류 가능한 위키피디어를 사용하기로 결정했다.우리는 각 표의 표제를 중심으로 하되, 그 내용은 No, Birth, Death, Grand Slam 칼럼에 대해서만 중심이 맞춰져야 한다고 생각한다.우리는 이것을 어떻게 하는지, 가능한지 모른다.좋은 생각 있어?미리 고마워!매딘\talk08:20, 2009년 1월 27일 (UTC)

style="text-align:left" 또는 style="text-align: center"(단일 파이프 기호 참고)를 사용하여 셀 내용 앞에 나올 수 있다.간결성을 위해 arlign=left 또는 arlign=중앙을 사용할 수도 있지만, 일부 상황에서는 작동하지 않을 수 있다.-우드스톤 (토크) 08:53, 2009년 1월 27일 (UTC)
파이프( ) 대신 느낌표(!)를 사용하여 셀을 헤더로 정의하고 적절하게 포맷(와 함께)class="wikitable", 대담하고, 중심이 되고, 세포가 약간 어두워진다.)도움말 참조:자세한 내용은 . mattbr 18:53, 2009년 1월 27일(UTC)
정답.하지만 그가 칼럼 포맷에 대해 어떻게 물어봤는지 봐기본적으로 테이블의 일반 내용은 정렬된 상태로 유지된다.그러나 미디어위키에서는 현재 단일 열의 모든 셀에 CSS 스타일링을 적용하는 것은 불가능하다.한 행의 내용이 중심이 되려면 각각의 셀에 대해 이 스타일링을 써야 한다.이것은 COL/COLGROGroup HTML 구문이 필요하기 때문이다(내 생각엔..).그러나 이러한 HTML 요소는 Mediawiki에 의해 지원되지 않으며 브라우저에 의해 희박하게 지원된다(IE와 Opera i 믿음에 따름). --DJ (대화 • 기여) 21:05, 2009년 1월 27일 (UTC)
흠, 특정 세포에 적용되는 CSS 클래스(.wikable-central tr.wikable tr)를 만들어 적절하게 스타일링할 수 있을 것 같다.EVULA // talk // talk // 21:14, 2009년 1월 27일(UTC)
그건 별로 도움이 안 돼, 타이핑을 해야 하니까.class="wikitable=centered"그 열의 각 셀에 대해, 타이핑하는 것보다 그렇게 뛰어난 것은 아니다.style="text-align:left" . 이것이 도움이 되는 유일한 장소는 모든 칼럼이 중심이 되는 테이블인데, 나는 그것이 뚜렷한 소수라고 생각한다.그 DJ가 맞아. 이런 종류의 일을 좀 더 깨끗한 테이블 마크업을 위해 더 쉽게 만들려면 COLGroup 구문이 정말 필요해.또한 Mattbr에 참고하십시오. 느낌표는 테이블 헤더 바깥쪽에 잘못 표시되어 있다(더 어두운 음영과 굵은 글씨로 강조).표준 테이블 행에 사용되는 마크업을 보는 것은 내 애석한 일이다.Andrwsc (대화·출연) 21:33, 2009년 1월 27일 (UTC)
아니 .wikable 중심은 테이블 자체를 위한 클래스일 것이다(class="wikitable wikitable-centered" 나는 이 특정 클래스가 세포의 중심을 맞추기 위해 CSS만 포함할 것이라고 상상하고 있다. 그래서 그것은 표에 삽입된 다른 CSS 코드와 상호운용성이 있을 것이다.EVULA// 통화 // // 21:48, 2009년 1월 27일 (UTC)
좋아, 하지만 그것은 여전히 모든 이 중앙에 있는 테이블에만 도움이 되고, 그것이 없어도, 당신은 항상 사용할 수 있다.class="wikitable" style="text-align:center" 표 머리말에서 오늘처럼.내 요점은 대부분의 테이블이 컬럼 설정(왼쪽이든 오른쪽이든 가운데든)마다 다른 정렬을 요구하는데 우리는 그것에 대한 좋은 해결책을 가지고 있지 않다는 것이다.예를 들어, 매우 일반적인 스타일의 테이블에는 적어도 첫 번째 열(왼쪽 정렬)에 텍스트 문자열이 있고, 다른 여러 열(적절한 경우 오른쪽 정렬 또는 가운데 정렬)에 숫자 데이터가 있으며, 스타일 정렬 코드를 행별로 반복하지 않고는 그렇게 할 수 있는 쉬운 방법이 없다.Andrwsc (대화/연락처) 21:56, 2009년 1월 27일 (UTC)
아, 이건 사실이야...공평하게 말하자면, 그것은 미디어위키가 아니라 CSS의 한계다.내가 생각할 수 있는 유일한 것은 개별 행에 영향을 미치는 수많은 불필요한 클래스가 있을 것이다(즉, .wikable-center3는 영향을 줄 것이다)..wikitable-center3 tbody tr td+td+td, .vasible-center5가 영향을 줄 수 있음.wikitable-center5 tbody tr td+td+td+td+td () 그러나 그것은 결코 우아한 해결책이 아니다.EVULA// 통화 // // 22:28, 2009년 1월 27일 (UTC)
이렇게 나쁜 생각은 아닌 것 같아. 비록 난 그렇게 하겠지만..col3-center(두말할 것 없이).col3-left그리고.col3-right) 등등.그것을 위키 가능한 테이블과 디폴트로 제한할 이유가 없다.청발 변호사 23:18, 2009년 1월 27일 (UTC)
스케치된 요구사항은 매우 일반적이며 (CSS) 솔루션을 갖추면 많은 기사를 정리할 수 있고 편집이 쉬워질 것이다.의 선에 따라 무엇인가.col3-center tbody tr td+td+td {style="text-align: center"}가 실행 가능한 것일 수 있다.그러나 위의 "col3-center"는 3 이상의 모든 열에 영향을 미칠 것이다.그래서 정렬의 모든 스위치는 표시되어야 할 것이다.왼쪽 정렬 테이블의 3열만 중심화하면 된다.col3-center col4-left. -우드스톤 (토크) 10:46, 2009년 1월 28일 (UTC)
모두에게 미안하다, 내가 그 질문을 잘못 읽었다.느낌표는 헤더를 포맷하지만 나머지 내용은 포맷하지 않으며, 셀을 잘못 설명하고 접근성에 도움이 되지 않기 때문에 비헤더 셀에 사용해서는 안 된다.mattbr 07:15, 2009년 1월 28일 (UTC)
Q: 위키미디어가 콜그룹(그리고 그 애드, tbadies도)을 지원하는 것을 가로막고 있는 주요 장애물은 무엇인가?지금 당장 이들에 대한 지원이 더해지면 어떤 '파탄'이 날까.SharkD (토크) 07:57, 2009년 1월 28일 (UTC)
<col>과 <colgroup>의 다양한 일관성 없는 브라우저 구현이 주요 장애물이다.예: [5][6]을 참조하십시오.미디어위키의 구체적인 망설임에 대해서는 986#c25와 같은 버그 986의 다양한 코멘트를 참조하십시오.또한 [7]을 참조하십시오(사양에 따라 정렬이 반드시 열에서 지원되는 것은 아님).--Splarka (rant) 08:28, 2009년 1월 28일 (UTC)
반면에, tbody와 thead는 전체적 것의 일부였다.table 그러나 나는 그것이 큰 문제없이 가능할 것이라고 생각한다.EVULA// 토크 // // 17:33, 2009년 1월 28일 (UTC)

현재 일치하지 않는 템플릿 집합이 있음:

  • {{}}}style="text-align:left"
  • {{좌석2}}:style="text-align:left" {{{1 }}}
  • {{오른쪽}}<div align="right">{{{1}}}</div>
  • {{}}}<div align="center">{{{1}}}</div>

중간 솔루션으로서, CSS 접근방식을 완화하면서, 우리는 새로운 세트를 정의할 수 있다.

  • {{ta-l}}}style="text-align:left"
  • {{ta-r}}}style="text-align:right"
  • {{ta-c}}}style="text-align:center"

-우드스톤 (토크) 09:43, 2009년 1월 29일 (UTC)

Wikimedia 보안 게이트웨이

66.230.230.230(토크 · 기여)은 토르(Tor) 노드지만, 블록 형식에는 민감한 IP라고 되어 있다.확실히 66.230.192.0에서 66.230.239.255까지의 모든 IP가 보안 게이트웨이인 것은 아니다(MediaWiki:블록 팁 익스텐트).내가 아는 유일한 보안 서버 IP는 66.230.200.219208.80.152.134이다.스펠캐스트 (토크) 09:06, 2009년 1월 28일 (UTC)

66.230.200.0/24는 Tampa 서버의 이전 IP 범위였습니다. 66.230.200.1 ~ 66.230.255.255. 66.230.230은 IP 범위에 있지 않으며 전혀 포함되지 않았다.막든 뭐든 마음대로 막든지. :) --briion (대화) 19:11, 2009년 1월 28일 (UTC)
완료. 그러나 IP는 MediaWiki에서 업데이트되어야 함:시솝.js.스펠캐스트 (토크) 10:44, 2009년 1월 29일 (UTC)

위키백과의 상위 10개 참고 자료들은 무엇인가?

위키피디아의 상위 10개 출처가 무엇인지 찾기 위해 URL을 세어본 사람이 있는가?나는 CNN, 뉴욕타임스, 타임지, AP통신 등이 2차 매체를 통해 의심하고 있다.모두 온라인에 기록보관소가 있다. --리처드 아서 노턴(1958- ) (토크) 12:47, 2009년 1월 28일 (UTC)

안녕 리처드, 나는 그 질문에 대한 답을 가지고 있지 않지만, 나는 네가 흥미로워할만한 비니쉬 주제에 대한 참고자료로 여겨질 수 있는 웹사이트 목록을 만드는 프로젝트를 하고 있어.그리고 만약 당신이 당신의 질문에 대한 답을 얻는다면 나는 매우 흥미가 있을 것이다:-) 이 토론을 보라.건배 니콜라스1981 (토크) 05:59, 2009년 1월 30일 (UTC)

"자신의 변화를 순찰을 한 것으로 표시할 수 없다."

해결됨
실제로 올바르게 작동하는 동안기능이 비활성화됨

버팔로 리지 철도에서 우회로를 만들었어텍스트와 카테고리 사이에는 오른쪽에는 "[이 페이지를 순찰으로 표시]"라고 되어 있다.그러나 내가 그것을 클릭할 때(http://en.wikipedia.org/w/index.php?title=Buffalo_Ridge_Railroad&action=markpatrolled&rcid=274038115),을 클릭하면 "순찰로 표시할 수 없음"이라는 제목과 "자신의 변경사항을 순찰로 표시할 수 없다"라는 텍스트가 있는 페이지로 이동된다.특수로 돌아가기:새로운 페이지." --NE2 17:55, 2009년 1월 28일 (UTC)

그렇게 되면 순찰 시스템을 무너뜨릴 수 있을 거야 신경(talk) 17:58, 2009년 1월 28일 (UTC)
그런데 왜 이게 지금 막 나타나는 것일까? --NE2 18:12, 2009년 1월 28일 (UTC)
페이지 순찰을 위한 링크는 Special:에서 페이지를 이동할 때만 표시되어야 한다.페이지.그렇게 하지 않았다면, 재미있는 일이 벌어지고 있는 거야.대수학자 18:23, 2009년 1월 28일 (UTC)
사용자:이름이 바뀌기 전 DA01의 토크 페이지.는 WP로부터 ngone을 받았다.CHU가 설명해줄게-제스케 쿠리아노(v^_^v) 18:29, 2009년 1월 28일 (UTC)
같은 지역에서 혹시 바뀐 게 있나? 신경(talk) 18:49, 2009년 1월 28일 (UTC)
버질라:15936을 고친 것 같군대수학자 18:57, 2009년 1월 28일 (UTC)
의도적이었나?그런 것 같다. 신경(talk) 19:05, 2009년 1월 28일 (UTC)
문제는 페이지 URL에 rcid가 있을 때만 [patrupted로 표시] 링크가 표시되지만, 이는 Special:에 의해서만 추가된다는 것이었다.새 페이지.따라서 누군가가 정리 태그 등을 추가하기 위해 페이지를 편집했다면, 브라우저 기록으로 돌아가거나 NewPages로 다시 돌아가지 않는 한 저장 후 순찰 링크를 사용할 수 없을 것이다.Mr.Z-man 19:17, 2009년 1월 28일 (UTC)
그러나 자신의 편집 내용을 순찰을 한 것으로 표시할 수는 없는데, 왜 그것이 문제가 되었는가? --NE2 20:35, 2009년 1월 28일 (UTC)
작성한 페이지를 순열된 것으로 표시할 수 없다.당신이 그것을 만들지 않은 이상 편집한 후에도 당신은 그것을 순찰할 수 있다.Mr.Z-man 20:37, 2009년 1월 28일 (UTC)
순찰은 페이지 단위로 하는 거지 편집 단위로 하는 게 아니라고?그러면 오류 메시지가 "변경"에서 "새로운 페이지"로 변경되어야 하지 않을까? --NE2 20:47, 2009년 1월 28일 (UTC)
위키피디아에서, Patrolled 편집은 새로운 페이지에만 적용된다.MediaWiki 소프트웨어를 사용하는 다른 위키에는 모든 편집 내용을 순찰할 수 있는 옵션이 있다.이것은 내가 관여하고 있는 또 다른 위키에 관한 사례다.해당 Wiki에 대해 관리자가 편집한 내용은 기본적으로 순찰("autopatrol" 옵션)으로 표시된다.-=# Amos E Wolfetalk #=- 22:28, 2009년 1월 28일(UTC)
그것이 미디어위키 기본 메시지가 '변화'를 언급하는 이유지만 미디어위키:마르케as patripterrror-noautopatrol은 en에만 더 적합한 것으로.위키백과대수학자 22:35, 2009년 1월 28일 (UTC)
제안된 대로 "페이지"를 참조하도록 메시지 변경.해피멜론 13:56, 2009년 1월 29일 (UTC)

비기사 페이지에도 "순찰로 표시" 표시

해결됨
- 실제로 제대로 작동하는 동안기능을 비활성화해 왔다.

좋아, 그래서 나는 이제 기사들의 새 페이지 목록에서 클릭하지 않아도 페이지를 순열로 표시할 수 있다는 사실을 알게 됐어.그러나, 현재, 등록되지 않은 비 문서 페이지도 "순찰로 표시" 링크를 가지고 있다.이것이 정말 필요한가요?링크를 가지고 있는 토크 페이지를 몇 장 우연히 발견했는데, 그 페이지들은 필요 없을 것 같아.게리 (대화) 22:37, 2009년 1월 28일 (UTC)

여기도 마찬가지(위키피디아:주요 후보 목록/복숭이 컨벤션 목록).Dabomb87 (대화) 23:42, 2009년 1월 28일 (UTC)

CSS를 이용하면 메인 스페이스 밖에 숨길 수 있어

칸막이하다.패트로링크       { 전시하다: 없는;  } .ns-0 칸막이하다.패트로링크 { 전시하다: 막다; } 

이렇게 하면 모든 네임스페이스에 링크가 숨겨지고, 다시 메인 스페이스에 표시된다.CSS가 없는 브라우저의 Failsafe는 아무 것도 하지 않을 것이고 디스플레이가 없는 브라우저:block을 지원하지 않을 것이다.해피멜론 14:02, 2009년 1월 29일 (UTC)

범주화되지 않은 템플릿에 대한 질문

우리는 분류되지 않은 기사들을 위한 특별한 페이지를 가지고 있다, 스페셜:분류되지 않은 페이지.분류되지 않은 템플릿(예: 범주를 포함하지 않는 템플릿 네임스페이스의 페이지)의 유사한 목록을 가질 수 있는지 궁금했다.이것은 유지보수와 조직적인 목적에 매우 유용할 것이라고 생각한다. --Eastlaw · 20:24, 2009년 1월 26일 (UTC)

특수:범주화되지 않음템플릿. --Splarka (rant) 08:18, 2009년 1월 27일 (UTC)

신경쓰지마, 미안해. --Eastlaw ½ 10:53, 2009년 1월 30일 (UTC)

일별 편집

해결됨
ukexpat (대화) 15:55, 2009년 1월 30일 (UTC)

stats.grok.se은 기사 페이지 조회 수를 하루에 보고할 수 있는 것으로 알고 있는데, 기사 페이지 조회 횟수에 대해서도 비슷한 서비스가 있을까?고마워!SharkD (대화) 22:02, 2009년 1월 28일 (UTC)

역사를 포함하지 않기 때문에 당신이 요청한 것은 아니지만, http://www.wikirage.com/은 현재까지의 다양한 시간 범위에 대해 가장 적극적으로 편집된 기사를 제공한다.-118fium 01:46, 2009년 1월 29일 (UTC)
어쨌든 고마워.SharkD (대화) 04:04, 2009년 1월 29일 (UTC)

고집센 백링크

하루나 이틀 전에 나는 이탈리아 파스타 요리에 관한 기사인 아글리오 이올리오를 위한 공간을 마련하기 위해 비스티 보이즈의 앨범에 관한 Aglio e Olio라는 기사를 Aglio e Olio (앨범)로 옮겼다.템플릿도 편집했다.비스티 보이즈는 약 100개의 BB의 노래 기사에 나오는 템플릿인 새로운 기사 이름으로 링크한다.내가 알 수 있는 한, 시스템은 이전 템플릿 버전을 새 템플릿 버전으로 숙청해 놓았지만(템플릿의 10개 정도 발생을 확인했다) Aglio e Olio의 백링크는 이전 Beastie Boys 템플릿 버전으로 고착되어 있다.

나는 백링크가 즉시 업데이트되지 않고 작업 대기열을 통해 업데이트된다는 것을 알고 있지만, 나는 무언가가 작동하지 않는다는 생각이 들기 시작했어.백링크 업데이트를 트리거하는 데 필요한 작업이 있는가?2009년 1월 29일 02시 46분 (UTC)

100만 명이 넘는 작업 대기열은 현재 상당히 많은 밀린 작업량을 시사한다.아무것도 할 필요가 없어, 소프트웨어가 결국 그것을 없앨 거야.지금 당장 이 일이 마무리되는 게 정말 중요하다면 파서에게 한 페이지를 바로 처리하되 한 장씩 돌아가라고 강요해 본문을 열고 아무것도 바꾸지 않고 "저장"을 누를 수 있다.그렇게 하면 해당 페이지의 모든 링크를 즉시 업데이트하는 효과가 있을 것이다.하지만 네가 어떤 급박한 상황에 있지 않다면, 난 신경 쓰지 않을 거야.시간이 지나면 저절로 깨끗해질 것이다.드래곤즈 비행 (토크) 03:39, 2009년 1월 29일 (UTC)
그래, 그리고 링크 고마워, 며칠 더 줄게.2009년 1월 29일 03시 49분(UTC)
이번 달에는 몇 주가 지나도록 링크 업데이트가 이루어지지 않았다.한 보고서는 12월 20일부터 편집에 관한 것이었다.[8] 40일 후 특별:WhatLinksHere/WAAG(FM)는 여전히 템플릿을 초월하는 WBWN을 포함하고 있다.프라임헌터 (토크) 04:27, 2009년 1월 29일 (UTC)
특수:WhatLinksHere/WAG(FM)가 마침내 WBWN을 제거했다.위 내용을 읽은 후 누군가가 무효 편집을 했는지 궁금하다.프라임헌터 (토크) 2009년 1월 29일 (UTC) 13:03
다시 한 번, 나는 전에 이 문제를 제기한 적이 있다.밀린 업무는 받아들일 수 없다. 현재보다 훨씬 빨리 정리해야 한다.나는 혼란스러운 기사를 만들기 위해 페이지를 이동할 때마다 기사 메인 스페이스가 혼란스러운 페이지를 가리키지 않도록 한다.다른 사용자들도 똑같이 했으면 좋겠다.그러나 템플리트를 새로 고치는 데 40일 이상이 걸릴 수 있다면 아무도 확인하는데 신경 쓰지 않을 것이다.나는 크리스마스에 앞서 옮겨온 두 페이지를 계속 지켜봤고, 2주가 지난 후에도 템플릿 업데이트에도 불구하고 여전히 그들을 가리키는 수십 개의 기사가 있었다.짐보가 마지막으로 현금을 더 달라고 호소한 후, 새로운 서버에 돈을 뿌렸으면 좋겠어!러그넛 (토크) 08:19, 2009년 1월 30일 (UTC)
우리는 현재 작업 대기열에서 일어나는 일을 더 잘 감시하고 업데이트 문제를 해결하는 방법을 조사하고 있다. --briion (대화) 17:12, 2009년 1월 30일 (UTC)

Talk 페이지의 참조

토크를 방해하지 않고 참조가 그 안에 포함될 수 있는 토크 페이지의 템플릿이 있는가?한 기사의 토크 페이지에 있는 참고문헌에 보라색 상자를 두었는데, 이미 '트리핑'을 해서 토크 페이지를 한 번 망친 적이 있다.고마워!SharkD (대화) 04:18, 2009년 1월 29일 (UTC)

내가 너의 문제를 이해했는지 잘 모르겠어.레퍼런스에 대해 빨간색 메시지를 받으셨습니까? --— Gadget850(Ed) - 13:03, 2009년 1월 29일(13:03, 13:03)
문제는 {{reflist}}}을(를) 토크 페이지 소스 하단에 배치하면 그 아래에 많은 사용자들이 새로운 섹션을 만들어 하단에 표시하지 않는다는 점일 것이다.또는 다른 섹션이 보관 후에도 자체 참조를 표시할 수 있도록 해당 섹션에서 발생하는 참조만 표시하는 "섹션 참조" 템플릿을 원하십니까?프라임헌터 (대화) 2009년 1월 29일 15:32, (UTC)
첫 번째, 두 번째가 아니다.이상적으로는 편집자의 편집이 페이지 상단에 방해되지 않도록 템플릿을 추가할 수 있지만, 페이지 하단에 있는 텍스트를 정상적으로 자동으로 렌더링할 수 있다.또한 섹션이 편집되지 않아야 하고 편집할 수 없음을 나타내기 위해 색칠된 배경과 테두리가 좋을 것이다.SharkD (대화) 15:46, 2009년 1월 29일 (UTC)
이런 것도 곰곰이 생각하고 있었다.우리 어디엔가 바닥글 메시지 박스 템플릿 있지 않아?몇 시간 동안 실제 생활에 방해가 된다. --— Gadget850 (Ed) - 16:06, 2009년 1월 29일 (UTC)
나는 계속하여 이러한 요구사항의 대부분을 충족하는 템플릿을 생성했다. {{Reflist-talk}}}.SharkD (토크) 22:23, 2009년 1월 29일 (UTC)
나는 그것을 보고 재빨리 테스트를 했다.문제는 페이지 하단에 달려 있다는 점이다.누군가가 단순히 +를 클릭하면 그 아래에 새로운 섹션이 만들어진다.그것은 또한 봇에 의해 보관되기 쉽다.맨 위에 항상 맨 아래에 표시되는 템플릿이 필요하다. --— Gadget850 (Ed) - 01:23, 2009년 1월 30일 (UTC)
이것은 템플릿으로 할 수는 없지만, 일종의 마법의 말로 할 수 있을 것이다.템플릿 레벨이 아닌 미디어위키 레벨에서 할 필요가 있다.— 칼 (CBM · talk) 02:05, 2009년 1월 30일 (UTC)
이 변화들이 무엇인지 구체적으로 설명해 주시겠습니까?참조 섹션의 자동 생성 같은 것을 의미하는가, 아니면 포함하면 템플릿이 맨 아래로 떨어지는 플래그만 의미하는가?나는 자바스크립트가 이것을 성취하는데 사용될 수 있다고 생각한다.즉, 스크립트는 요소를 정상적인 흐름에서 벗어나 부모 div의 마지막 자식으로 삽입한다.SharkD (토크) 05:31, 2009년 1월 30일 (UTC)
응, 나도 몇 번이나 걸려 넘어졌어. 고치기는 쉽지만.SharkD (대화) 05:32, 2009년 1월 30일 (UTC)
아마도 후자일 것이다,_MOVEREFSLISTTOBottom_의 효과에 대한 것이다__ 우선은 reflist 후에 선언된 ref를 줍기 시작할 필요가 있을 것이다.이들도 두 번째 리스트를 채우는 것 같지 않고 그냥 무시한 것 같다."참조" 섹션, "외부 링크" 섹션에는 ref를 필요로 하는 "내용 진술"이 포함되어서는 안 되며, 그 내용은 어쨌든 기사의 상부에 의해 지지/감축되어야 하기 때문에 결코 기사에 영향을 미쳐서는 안 된다.CharlotteWebb 19:49, 2009년 1월 30일 (UTC)
<참조/> 태그가 누락되었을 때의 오류 메시지는 항상 마지막 섹션 뒤에 있다.에러가 실제로 참조 목록을 생성하도록 메시지에 <참조/> 태그를 넣을 수 있다.나는 이것을 좀 더 보고 싶다. --—— Gadget850 (Ed) - 21:37, 2009년 1월 30일 (UTC)

참조 강조 표시 복제

해결됨
ukexpat (대화) 15:54, 2009년 1월 30일 (UTC)

나는 현재 각주를 사용하는 웹사이트(인쇄 출판물의 웹 버전)에서 일하고 있다.닻을 클릭할 때(그리고 기사에 대한 ^ 백업을 클릭할 때 반대) 전체 리프 라인이 강조(배경색 변경)되는 것과 비슷하게 행동하도록 하고 싶다.나는 각주 코드가 자동으로 생성되거나 어떤 것이든 필요하지 않다. 그것은 단지 정적 사이트일 뿐이다.잠깐 숙독하고 난 후 코드를 찾을 수 없어서, 펌프에 대한 주제만 모호하니, 여기서 물어봐야겠다고 생각했다.;) EVULA // talk // talk // 21:15, 2009년 1월 29일 (UTC)

Cite.php 확장자를 원하는 경우.행운을 빌어. --—— Gadget850 (Ed) - 2009년 1월 29일 (UTC)
나는 그가 언급하고 있는 하이라이트가 우리의 지역 CSS 및/또는 Javascript 파일 어딘가에 있을 것이며 확장자 자체의 일부가 아닐 것이라고 확신한다.드래곤즈 비행 (토크) 2009년 1월 29일 22:26 (UTC)
꽤 쉽게 할 수 있다.점프는 쉬워, 그냥 닻이야.더 어려운 부분은 링크를 클릭했을 때 색칠하는 것이다. 그러나 MediaWiki를 보면:common.css, 그 부분은 네가 원하는 거야각주의 링크를 넣으면 가도 좋다.게리 (대화) 2009년 1월 29일 22시 30분 (UTC)
그래, 앵커들을 세워놨어(네 말대로...그들은 단지 앵커일 뿐)이지만 :target CSS 사이비 클래스에는 익숙하지 않았다.그렇기 때문에 내가 .js 파일을 검색한 결과 아무것도 나타나지 않았고, .css 파일에서 배경색을 찾아야 하는 이유를 알 수 있을 것이다.도.
나는 개별 각주를 주문목록으로 취급하고 있기 때문에 거기에 클래스를 적용하고 목록 항목의 배경을 설정하기만 하면 된다; 매력적으로 작용한다(그리고 그것을 매끄러운 스크롤 jQuery 스크립트와 결합할 것이기 때문에 꽤 나쁠 것이다).대단히 고맙습니다:) EVULA/// 토크 // 22:51, 2009년 1월 29일 (UTC)

인쇄 문제-일부 링크를 통해 페이지가 공백으로 인쇄됨

전에 이런 얘기를 꺼냈는지는 모르겠지만, 지난 몇 달 동안 나는 일부 기사에 일부 페이지를 인쇄하는 데 문제가 있다는 것을 알았다.대부분의 페이지는 인쇄가 잘되지만, 일부 페이지(같은 기사 내)는 공백으로 인쇄된다.나는 컴퓨터가 같고 아무것도 바꾸지 않았기 때문에 컴퓨터에 문제가 있다고 생각하지 않는다.몇 개의 기사에서 내가 만약 내가 어떤 링크를 제거하면(일시적으로 영구적으로가 아닌) 인쇄 문제가 해결된다는 것을 알아차렸듯이, 어떤 링크들이 이 문제를 야기하고 있다고 생각한다. --WordsExpert (토크) 21:39, 2009년 1월 29일 (UTC)

어떤 기사들이 이것을 야기시키고 있는 것처럼 보이는 지에 대한 어떤 링크들인가?대수학자 22:32, 2009년 1월 29일 (UTC)
콘스탄틴 브란쿠시에 관한 예 4페이지의 한 예시 4페이지에서 나는 그것을 적어도 몇 십개의 기사에서 알아차렸다. --WordsExpert (토크) 01:07, 2009년 1월 30일 (UTC)
그리고 어떤 브라우저와 운영체제는? --DJ (대화기여) 12:36, 2009년 1월 30일 (UTC)
Vista 및 탐색기의 최신 버전을 브라우저로 사용. --WordsExpert (talk) 21:29, 2009년 1월 30일 (UTC)

로그인한 사용자에게 보이지 않는 반달리즘?

해결됨
ukexpat (대화) 15:51, 2009년 1월 30일 (UTC)

는 뉴스 페이지에서 이상한 것을 발견했다.로그오프할 때 해시 링크와 도입부 사이에 'poo'가 적혀 있는 것 같다.그러나 로그인하면 그런 것은 나타나지 않는다.편집하려고 하면 전혀 페이지에 없는 것 같고, 페이지 이력을 보면 누가, 언제 추가했는지 알 수 없다.이거 정말 흥미진진한데, 무슨 일인지 누가 설명해줄 사람 있어?고마워. --Urzică (대화) 22:43, 2009년 1월 29일 (UTC)

아마 템플릿 파괴 행위일 거야.서버 캐시를 정리하는 것이 그것을 고친 것 같다.대수학자 22:45, 2009년 1월 29일 (UTC)
예, {{저널리즘}}}}에 대한 반달리즘이었다.로그인한 판독기와 로그인하지 않은 판독기를 위해 서로 다른 캐시가 보관되기 때문에 파괴 행위가 한 쪽에만 캐쉬에서 지속되는 것이 가능하다.현재의 긴 작업 대기열로 페이지는 스스로 업데이트하는 데 오랜 시간이 걸렸다.대수학자 22:47, 2009년 1월 29일 (UTC)
아, 맞다.(그리고) 설명해줘서 고마워. --Urzicic (토크) 22:53, 2009년 1월 29일 (UTC)

아난다브하드람:없나?

아난다브하드람의 ref 섹션에 많은 noinclude 코드가 나타나는가?디트(talkcontribs) 15:24, 2009년 1월 30일 (UTC)

난 그들을 보지 않는다.캐시를 지우고 서버 제거를 시도해보셨습니까?ukexpat (대화) 15:53, 2009년 1월 30일 (UTC)
아난다브하드람은 {{Cite web}}을(를) 사용하며, 2분 [9] 동안 편집되었으며, 이 템플릿이 비교할 수 없는 성능을 보였다.</noinclude>. 템플릿이 수정되고 기사가 업데이트됨(그러나 템플릿이 수정된 후 다른 관련 기사가 아직 업데이트되지 않았을 수 있음)프라임헌터 (토크) 23:13, 2009년 1월 30일 (UTC)

IE8 및 각주 문제

어젯밤에 IE8 (RC1)로 업그레이드했는데 각주에 문제가 있다.(1) 각주가 위첨자라기보다는 작은 첨자이고, (2) RefList에 있는 모든 각주는 0이다.Bubba73 (대화), 18:00, 2009년 1월 30일 (UTC)

나는 IE8 지원 문제처럼 들린다.ukexpat (대화) 18:59, 2009년 1월 30일 (UTC)

기본 요약이 "공백 편집 요약을 입력할 때 확인"과 함께 제대로 작동하지 않음

내 기본 설정에서 "공백 편집 요약을 입력할 때 확인" 선택사항이 사용 가능으로 설정됨.이전에 새 페이지를 만들고 편집 요약을 공백으로 두면 "새 텍스트가 있는 작성 페이지"와 같이 페이지 작성에 대한 페이지가 자동으로 생성된다.나는 여전히 이렇게 한다고 믿지만, 지금 내가 편집 요약을 공백으로 두면, 편집 요약을 입력하지 않았다고 경고한다.이것의 문제는 예전에는 소프트웨어가 나를 위해 편집 요약을 자동으로 생성한다는 것을 알고 있었는데, 이제는 이것을 더 이상 모르는 것처럼 보인다는 것이다.게리 (대화) 2009년 1월 30일 18:04 (UTC)

이 inane 기능을 사용하면 첫 번째 시도에서 빈 요약은 거부하지만 두 번째 시도에서 같은 기능이 거부되지 않도록 숨겨진 입력을 추가한다.javascript를 사용하여 특정 조건에서 첫 번째 시도에서 추가(재로드 건너뛰기)할 수 있다.

if(wgAction="편집" &&gt;wgCurRevisionId == false) ///빨간색 링크 문서를 편집하는 경우.GetElementById("편집 양식")innerHTML += ///이 매개 변수를 편집 요약 '<input name="wpIgnoreBlankSummary" 유형="숨겨진" 값="1" />]; //실제로 비어 있지 않음

CharlotteWebb 18:45, 2009년 1월 30일 (UTC)

괜찮아, 별거 아냐.나는 단지 나를 위해서만 그것을 바꾸고 싶지 않다; 나는 "만들기"의 편집 요약을 사용할 것이다.하지만 내가 이 이야기를 꺼내는 이유는 기능성이 최근 일주일 사이에 바뀌었기 때문이다.왜 바뀌었는지 궁금하다.게리 (대화) 2009년 1월 30일 18시 50분 (UTC)

감독권 변경에 대해 설명하시겠습니까?

는 Special을 본다.ListGroupRights와 I see, 두 개의 "숨기기" 및 "덮어쓰기" 권한 대신 다음과 같은 권한이 표시됨:

  • 페이지의 특정 수정사항 삭제 및 삭제 취소(삭제 수정)
  • 관리자(administrator)에 숨겨진 수정사항 검토 및 복원(숨기기)
  • 관리자에게 숨겨진 수정사항 검토 및 복원(압축)
  • 이전에 숨겨져 있던 수정기호 보기(오버헤이트)

이러한 권한은 무엇이며, 삭제 수정, 숨기기 수정 및 축소 수정 간의 차이점은 무엇인가?ownser가 있을 때는 제 토크페이지에 {{tb}}}을(를) 사용해 주십시요.--Ipatrol (talk) 22:56, 2009년 1월 30일(UTC)

[10]을 참조하십시오.해피멜론 23:49, 2009년 1월 30일 (UTC)

잘못된 이미지 목록에 있는 이미지가 텍스트의 다음 단락(또는 그 이상)을 사라지게 하는가?

Bad Image(불량 이미지) 목록에 이미지를 추가하려고 하면 이미지가 표시되지 않지만 텍스트의 다음 단락(또는 여러 단락)도 사라진다.

예를 들어 다음 코드를 입력하십시오.

:예:
: < br clear="all">
:이 텍스트는 페이지에 나타나야 하지만 나타나지 않는다!
:이 대사도 그래야지!
:*그리고 이 목록 항목!
:~~~~

생산:

예:

이 텍스트는 페이지에 나타나야 하지만 나타나지 않는다!
이 대사도 그래야지!
  • 그리고 이 목록 항목!
Bushytle (talk) 00:16, 2009년 1월 31일 (UTC)

("나쁜" 이미지가 아닌 이미지를 사용하여 표시되는 경우):

예:
Strapon01.jpg

이 텍스트는 페이지에 나타나야 하지만 나타나지 않는다!
이 대사도 그래야지!
  • 그리고 이 목록 항목!
Bushytle (talk) 00:16, 2009년 1월 31일 (UTC)

나쁜 이미지 리스트의 내재된 악행을 무시한 채, 이 보증된 버그는 꽤 성가시다...다음 중대한 변화(서명 추가는 그것을 멈추게 하고, 그래서 내가 예에서 그것을 사용한 이유)까지 모든 것이 그냥 사라진다.출력 html에는 그것의 흔적이 없다.그럼 벌레인가, 아니면 다른 건가?Bushytle (talk) 00:16, 2009년 1월 31일 (UTC)

이것은 또한 bugzilla:16039에서도 보고된다.프라임헌터 (토크) 02:24, 2009년 1월 31일 (UTC)

금주의 소프트웨어 업데이트

지금 사이트에서 MediaWiki가 업그레이드되고 있는 중...참고 항목: mw:자세한 내용은 금주 소프트웨어 업데이트. --briion (토크) 03:55, 2009년 1월 28일 (UTC)

페이지가 존재하지 않는다.=) ——Locke Coletc 04:06, 2009년 1월 28일 (UTC)
작은 새가 내게 이렇게 말했다.이번 주 업데이트는 좀 더 보기 좋은 곳일 수 있다.:) {{Nihiltrestalk log}} 04:12, 2009년 1월 28일 (UTC)
링크를 고쳐줘서 고마워. :) --briion (토크) 19:14, 2009년 1월 28일 (UTC)

의도적이었는지는 모르겠지만 [롤백] 링크가 이제 감시 목록에 나타난다.

--briion (대화) 2009년 1월 28일 19:14, (UTC)
그것을 끄는 옵션이 가능할까?좀 어수선하다.♫ 멜로디아 샤콘네 ♫ (토크) 20:23, 2009년 1월 28일 (UTC)
어수선할 뿐만 아니라, 나는 내가 무언가를 클릭하는 것을 보면 감시 목록의 [롤백] 링크가 아주 무시무시하다는 것을 알게 된다.나는 우연히 롤백을 하고 싶지 않다.워치리스트를 위해 그것을 끌 수 있는 옵션이 있는 것은 좋은 일일 것이다.모두 동일한 "mw-rollback-link" 스타일을 사용하기 때문에 특수: 페이지별 .js가 스타일을 보이지 않게 만드는 유일한 옵션이다.워치리스트?Framanax (대화) 22:12, 2009년 1월 28일 (UTC)
/* 최근 변경 사항에서 롤백 숨기기 */ .페이지-특수_RecentChanges .mw-mw-link 링크 {전시하다:없는;} /* 감시 목록에서 롤백 숨기기 */ .페이지-특수_감시 목록 .mw-mw-link 링크 {전시하다:없는;} 
CSS만 있으면 돼하지만, 그것은 JS를 통해 이루어질 도 있고, 심지어 JS('쇼 롤백' 링크)에 의해서도 풀릴 수도 있다.아마도 기기로. --Splarka (rant) 23:10, 2009년 1월 28일 (UTC)

또한 이 개정은 js 스크립트 "최고 기여 표시/숨기기"를 깨는데, 이는 이상하다. 왜냐하면 스크립트가 하는 모든 것은 사용자가 가장 최근에 기여하는 사용자인 경우 사용자가 기여하는 기여를 숨기는 것이기 때문이다.-- penubag (talk) 04:23, 2009년 1월 28일 (UTC)

우선 이러한 링크를 숨길 수 있는 스크립트 또는 기본 설정 옵션을 갖고 싶다.나는 그들이 감시목록을 보호했기 때문에 그들을 더 무서워하는 몇몇 관리자들과 이야기를 나누었다.JakeWartenberg, 2009년 1월 29일 (UTC)
신경 쓰지 마.저 CSS는 잘 작동해!제이크 바텐버그 2009년 1월 29일 16:15 (UTC)

나는 이것이 무섭다고 생각하는 사용자들의 의견에 동의한다.사용자 기록을 확인할 때도 롤백을 숨길 수 있는가?그것이 내가 가장 무서워하는 것이다.PSWG1920 (대화) 16:37, 2009년 1월 29일 (UTC)

예:
.페이지-특수_공헌 .mw-mw-link 링크 {전시하다:없는;} 
TKD:토크 16:57, 2009년 1월 29일 (UTC)

무섭고 어수선할 뿐만 아니라, RC와 감시 목록에 추가 쿼리 뭉치를 추가한다.나는 지금 내가 롤백기를 가지고 있는 enwiki RC에 대한 370개의 질의를 보고 있다.어쩌면 이 변화는 되돌아가야 할지도 모른다.시뮬레이션 (대화기여) 02:12, 2009년 1월 30일 (UTC)

그것은 정말 훌륭하고 삶을 훨씬 더 편하게 해 준다.Ty 03:59, 2009년 1월 30일 (UTC)
잘됐네.네가 좋아해 줘서 기뻐.그러나 나는 그것이 정말로 선호되어야 하며, 아마도 채무불이행이 되지 않아야 한다고 생각한다.JakeWartenberg 03:46, 2009년 1월 31일 (UTC)
@시뮬레이션: 브리온이 그것을 샅샅이 뒤졌으므로 성능 영향이 허용된다.에르고, 그것의 성능 영향은 문제가 아니다.
@Jake: 만일 이러한 불일치가 항상 존재하지 않았고, 로그 편집이 항상 일관되게 롤백 링크를 표시했다면, 아무런 문제가 없었을 텐데, 왜 그 반대는 다를까?사용자 기여도에 대한 롤백 링크, RC 피드의 롤백 링크, 감시 목록의 롤백 링크에는 실제로 차이가 없다. 둘 다 편집의 정당성과 동일한 양의 정보를 제공한다.이것은 편집 로그의 외관을 표준화함으로써 인터페이스의 일관성을 향상시킨다; 만약 당신이 당신의 개인적인 선호에 맞게 그 불일치를 다시 소개하고 싶다면, 그것은 완벽하게 괜찮고, 당신은 CSS를 그렇게 쉽게 할 수 있다.해피멜론 16:31, 2009년 1월 31일 (UTC)

네임스페이스 찾기 템플릿

위키피디아를 보고 있었는데:삭제검토#새로운 삭제 검토를 나열하고 템플릿 확인 단계:newdelrev에서는 사용자가 네임스페이스 이름을 수동으로 입력해야 한다.템플릿 이름을 자동으로 감지할 수 있는 방법이 있으면 유용할 것 같아서이 용도의 네임스페이스.그러나 이제 템플릿:뉴델레브에겐 정말 필요해이 방법이 유용할 수 있는 다른 애플리케이션은 무엇인가?—2009년 1월 30일 03:42, 점 기억(UTC)

활. 엎드려.인. 예배.우리가 지금까지 원했던 것 중 가장 중요한 현악기 조작 기능, 그리고 규칙적인 표현 테스트를 거쳐서 가장 강력한 현악기 조작 기능을 발견했다는 사실을 알고 있는가?만약 여러분이 문자열의 마지막 X자를 얻을 수 있는 방법을 생각해 볼 수 있다면, 우리는 정말로 정해진 것이다: 이 두 가지 아이디어는 사소한 것으로 문자열 슬라이싱, 문자열 분할, 길이 함수, 그리고 문자열 비교로 확장될 수 있다.그 두 가지 아이디어로 StringFunctions 라이브러리 전체를 거의 다 만들 수 있다고 말하는 것은 농담이 아니다.쿠키 해피멜론 17:50, 2009년 1월 30일 (UTC)
음, 만약 우리가 이것을 하위 문자열 해킹으로 사용하려고 한다면, 실제로 미디어위키에 하위 문자열 기능에 대한 네이티브 지원을 포함하는 것이 더 타당할 것이다. ---- RockMFR 17:58, 2009년 1월 30일 (UTC)
내 안에 있는 프로그래머가 겁에 질려 반항하는 것은 전적으로 동의한다.T8455에 투표해봐. 코드는 내내 사용 가능했음에도 불구하고 2년 반 동안 열려있었어.어쩌면 우리가 기초에서 그것을 해킹할 수 있을 만큼 이 기능성이 필요하다는 것을 증명한다면, 개발은 우리에게 더 기본적인 기능을 제공하는 경향이 있을 것이다.해피멜론 19:36, 2009년 1월 30일 (UTC)

StringFunctions는 wikitext의 성격과 이것의 성능에 미치는 영향이 크기 때문에 부분적으로 활성화되지 않았다.기존의 파서함수에서 문자열 기능을 재구성하는 것이 반드시 이에 대한 합리적인 대응은 아니며, 사용성과 성능에 상당한 영향을 미친다.착취한 행동도 버그였는데, 이 버그는 수많은 경우에서 깨졌다.결과적으로, rev:46628에서, 나는 패드 파서 기능을 사용하여 문자열을 자를 수 있는 기능을 비활성화했다. 이 변경은 다음 주 중반에 시행될 것이다.스트링 기능이 필요한 것을 쓰려면 템플릿이 아닌 파서 기능으로 구현해야 한다는 것이 기술팀의 조언이다.Werdnatalk 00:49, 2009년 1월 31일 (UTC)

빠른 참고 – 이 원칙에 따라, 다음 며칠 안에 Mr.Z-man 또는 나 자신에 의해 {{namespace} 템플릿과 동일한 기능을 가진 파서 기능이 추가될 것이다.Werdnatalk 00:57, 2009년 1월 31일 (UTC)
코드 검토에서 내 의견을 참조하십시오. 패치가 패드의 사용 방법을 잘못 이해함.드래곤즈 비행 (토크) 01:15, 2009년 1월 31일 (UTC)
"열 기능이 필요한 것을 쓰려면 템플릿이 아닌 파서 함수로 구현해야 한다."그 벌레가 왜 30개월째 문을 열었다고 생각해?왜냐하면 우리는 끈 기능이 필요한 것들을 쓰고 싶었고, 당신에게 (왕실 당신, 내가 당신을 탓하는 것이 아니라) "파서 기능으로 구현해달라"고 부탁했기 때문에 우리는 그것을 템플릿으로 구현할 필요가 없었다.물론 네 원칙에는 동의하지만, 나는 이것이 비개발자들에 대한 "감각적인 대응"으로 해석될 수 있다고 생각하지 않는다: 우리는 기능성을 요구했고, 우리는 그것을 얻지 못했고, 음란한 시간을 기다렸으며, 여전히 얻지 못했기 때문에, 우리는 그것을 우리가 가진 것에서 스스로 해킹했고, 개발자들이 그것을 보고 있고, 꽤 옳은 것이다.겁에 질렸지만, 놀랍게도, 우리가 3년 전 보다 나은 부분을 요구했을 때 우리는 농담이 아니라는 것을 깨달았고, 그래서 우리는 마침내 그것을 본래의 것으로 얻는다.내가 보기엔 윈윈하는 상황인 것 같아.해피멜론 10시 30분, 2009년 1월 31일 (UTC)
좋아, 그 기능성을 제거함으로써 위키소스의 성(性)의 첫 글자를 결정하는 과정을 자동화하는 능력을 없앨 수 있을 것이다.이것은 위키소스에서 매우 인기 있는 기능이었다.템플릿:작성자(wikisource:Scriptorium#템플릿에서 last_initial 매개 변수 제거:작성자).padright를 사용하여 하위 문자열을 하는 것은 보통 하위 문자열을 하는 것만큼 집약적이다 - 제한 사항은 문자열 내의 임의적인 지점이 아니라 위치 0에서 하위 문자열을 시작해야 한다는 것이다.따라서, 이것으로부터 다른 문자열 기능을 재구성하는 것은 정말로 불가능하다.또, 「착취한 행동도, 수많은 경우에 깨진 벌레였다」라고 하는 것은 무엇을 의미했는가?몇 가지 예를 올려 주시겠습니까?—2009년 1월 31일 01:03, 점 기억(UTC)
방법은 설명하지 않겠지만, 이 트릭에 기존의 파서 기능을 더하면 슬라이싱을 할 수 있다.일단 그렇게 되면, 거의 모든 문자열 라이브러리를 복제할 수 있을 겁니다.말이 나와서 말인데, 나는 개인적으로 StringFunctions의 일부 버전을 가능하게 하는 것이 지역사회의 이익이라고 생각한다.드래곤즈 비행 (토크) 01:23, 2009년 1월 31일 (UTC)
나는 끈 슬라이싱을 하기 위해 파서 기능을 극도로 신뢰할 수 없고 비효율적인 방법으로 결합하는 것이 가능하다는 것을 알고 있다.문제는 그 방법이 사용할 수 있을 만큼 충분히 신뢰할 수 없을 것이라는 것이다.이메일 좀 보내줄래? 우리가 각자 무슨 생각을 하고 있었는지 의논해 볼 수 있을까?
어쨌든, 나는 "수많은" 사례에서 패드라이크를 깨트린 버그가 무엇이었는지 더 알고 싶다.—2009년 1월 31일 01:32, 점 기억(UTC)
rev:46630은 기본적으로 네임스페이스 템플릿과 동일한 방식으로 네임스페이스, 제목스페이스 및 TALKSpace에 대한 파서 함수를 추가하여 형편없는 해킹을 제외한다.Mr.Z-man 01:52, 2009년 1월 31일 (UTC)
고마워PAGENAME 함수의 정상화를 요구하는 것도 무리인가?그리고 위키소스가 문자열의 첫 문자를 추출할 수 있어야 한다는 문제가 여전히 있다.—2009년 1월 31일 02:04, 점 기억(UTC)

로그 필터링

로그에서 편집기를 필터링할 수 있는가, MZMcBride라고 하는 MZMcBride를 삭제 로그에서 제외할 수 있는가, 아니면 도움말에서 이미 설명한 모든 작업을 수행할 수 있는가?Special_page#Logs?--Tikiwont (대화) 13:44, 2009년 1월 30일 (UTC)

delete-bot은 매번 동일한 요약을 사용하기 때문에 당신은 그것을 당신의 끝에 숨기고 다른 선에 주의를 기울일 수 있다.

if(wgPageName="Special:로그") 문서.body.innerHTML = document.body.innerHTML .replace(/<li.*?이전 IP 토크 페이지*?<\/li>/gi, "";

물론 이렇게 하면 50개 미만의 이벤트를 볼 수 있고 제한사항이 설정된다.CharlotteWebb 19:29, 2009년 1월 30일 (UTC)

고마워, 유용하게 들리네; 그리고 이것은 monobook.js나 다른 곳으로 가니?--Tikiwont (토크) 19:56, 2009년 1월 30일 (UTC)
그래. 다른 일반적인 홍수 피스(이렇게 분리)를 추가할 수 있다.CharlotteWebb 20:12, 2009년 1월 30일 (UTC)
"이전 IP"가 포함된 항목만 추가하십시오.
가져오기스크립트('사용자:MZMcBride/hideentries.js') 
사용자 피부 하위 페이지(일반적으로 특수:myPage/monobook.js.건배. --MZMcBride (대화) 07:44, 2009년 1월 31일 (UTC)
둘 다 덕분이야.어떤 이유에선지 두 번째, 더 비밀스러운 것만이 나에게 효과가 있었지만, 그건 괜찮아.--Tikiwont (토크) 08:41, 2009년 1월 31일 (UTC)

사용자 스크립트?

Special을 통한 스크립트 사용 이유:mypage/skin.js는 더 이상 작동하지 않는다.만약 이게 내 문제라면 어떻게 고쳐야 하는지 말해줘. 하지만 이 시점에서 나는 소프트웨어 문제라고 생각해.좋은 생각 있어?알렉스푸스코5 01:18, 2009년 1월 31일 (UTC)

User(사용자)Alexfusco5/monobook.js는 아마도 오늘(또는 최근에) 당신이 편집한 것일 것이다.브라우저에서 오류 콘솔 로그를 확인하십시오.아니면 혹시 실수로 스킨을 바꾸거나 자바스크립트를 무력화시킨 것 아닐까? --Splarka (rant) 01:40, 2009년 1월 31일 (UTC)
자바스크립트가 켜져 있고 나는 스킨을 바꾸지 않았다고 확신한다.게다가, 나는 모노북.js의 모든 대본들이 12월 중에 막 멈추는 것을 기억하기 때문에 한동안 이 문제를 겪고 있었을 것이라고 확신한다.스크립트 장치만 잘 작동하고 소프트웨어 버그나 구성 변경일 수도 있다고 생각하고 우선 나만 문제를 겪고 있는 것이 아닌지 확인하고 싶다.Alexfusco5 14:54, 2009년 1월 31일 (UTC)
아무도 신고하지 않아서 브라우저 문제일 수도 있어.아마도 당신의 브라우저(또는 어떤 애드온이나 확장자)가 정확한 페이지에서 javascript를 차단하고 있는 것은 아닐까?대수학자 14:59, 2009년 1월 31일 (UTC)
내 브라우저로 FF3를 사용하고 있는데 이 작업을 수행하는 추가 기능이 없는 것 같아. 지금 확인하려는 것은 알렉스푸스코5 15:11, 2009년 1월 31일(UTC)
오류 로그를 확인했을 때 내 잘못 나는 당신의 도움에 감사하여 오류를 볼 수 있을 정도로 스크롤되지 않았다 :) 알렉스푸스코 15:21, 2009년 1월 15:21, Alexfusco5 15:21

정기적으로 둘 이상의 피부를 사용하는 사람은 없을 것 같지만, "사용자:so-so-so/common.js"는 모든 피부에 로드할 수 있는 것으로 인식되는가?CharlotteWebb 15:04, 2009년 1월 31일 (UTC)

사실 사용자들은 스킨을 자주 바꾸지 않는다.그러나 더 중요한 것은 사용자/common.css/js 편집 실패는 일부 사용자에게는 해결하기가 지나치게 어려울 수 있다는 점이다.우연히 당신의 모노북.css를 추가하는 것을 상상해 보라.이 일은 ...monobook.js&action=edit&usskin=my skin으로 쉽게 해결할 수 있지만, 만약 그것이 common.css라면 그렇지 않다.양쪽은 bugzilla:10183을 참조하십시오. --Splarka (rant) 22:21, 2009년 1월 31일 (UTC)

범주 포함에 대한 자습서

이 글을 쓰면서 WT:CWNB는 다음 범주에 포함된다.토론 통지 카테고리 - 그러나 토론 카테고리는 아니다.나는 이것이 (내가 글을 쓸 때, 나는 시험하고 되돌려서) 토크 페이지에 있는 첫 번째 스레드 때문에 제안된 CfD - 서프라이즈 - 서프라이즈에 대해 토론하기 때문이라는 것을 안다.

여기서 제 질문은 어떤 믿을 수 있는 방법이 이 페이지에서 정확히 범주가 어느 범주로 넘어갔는지 알아낼 수 있을까 하는 겁니다.내 지혜를 이용해서 알아낼 수 있는 유일한 방법인가?

여기서 [[Category:blah] 대 [:Category:blah], [:Category:blah], [:Category:blah], [[:category]], [:category:blah],], [:category:blah]의 오류에 대해 말하는 것이 아니라는 점에 유의하십시오.고마워!Framanax (대화) 10:39, 2009년 1월 31일 (UTC)

기사에서 인라인으로 분류되는지 템플릿 전폐에서 분류가 수행되는지 알아내겠다는 말씀이세요?고급 검색 기능은 도움이 될 수 있다. 즉, 이 경우 모든 템플리트에서 "토론 통지 카테고리" 문자열을 찾는 이 검색("카테고리:"를 앞에 두면 요청된 네임스페이스보다 우선하고 카테고리 네임스페이스로 검색을 제한함)이 유용할 수 있다.나는 각각의 전횡을 개별적으로 보는 것 외에 다른 방법은 모른다.그러나 이 경우 그것은 전폐가 아니다 - 그것은 바로 위키백과의 대화에 있다:템플릿의 변형에 의해 생성된 첫 번째 스레드에 있는 캐나다어 위키백과 게시판:Cfdnotice.이 공지사항들은 CfD토론이 종결되면 정리하도록 되어 있다고 생각한다.어떤 이유로든 이것은 놓친 것 같다. -- 릭 블록 (토크) 16:21, 2009년 1월 31일 (UTC)

Infobox가 표시되지 않음

안녕, 내가 로그인했을 때, 몇몇 인포박스가 나타나지 않아.문제가 있는 페이지의 예로는 핀마크, 버스커드, 트롬스 등이 있다.문제가 없는 페이지의 예로는 스웨덴, 노르보튼 등이 있다.나는 어떤 장치도 사용할 수 없고 내 모노북.js는 비어 있다.무엇이 이 문제를 야기하는가? --Gerrit 12:19, 2009년 1월 31일 (UTC)

로그아웃하여 Shift+Reload(Firefox 3.0.5)를 하면 같은 문제가 발생한다. --130.239.112.204 (토크) 12:21, 2009년 1월 31일 (UTC)
지금 고친 것 같아! --GerritCUTEDH 12:23, 2009년 1월 31일 (UTC)
누군가 인포박스를 부숴버렸어, 그건 고정되어 있었어.안녕, 우디 (토크) 12:25, 2009년 1월 31일 (UTC)


모든 Wikimedia 프로젝트에서 사용자 페이지 자동 생성

다른 위키미디어 프로젝트의 모든 사용자 페이지와 사용자 토크 페이지가 자동으로 내 en으로 소프트 리디렉션되도록 만들고 싶다.wiki 사용자: 및 사용자 대화: 페이지(Meta: 또는 commons:와 같이 약간만 활성화되어 있는 프로젝트의 사용자들은 en.wiki에 메시지를 남긴다.이것을 하기 위한 봇, 스크립트, 확장 또는 다른 방법이 있는가, 아니면 새로운 프로젝트에 착륙할 때마다 수동으로 해야 하는가?--에어바나트 (대화) 15:31, 2009년 1월 31일 (UTC)

템플릿의 스팬 요소

해결됨

<span id="를 어떻게 사용하는가?템플릿으로 A"[/span]?

{{tl 스판 A}}{{tl Endspan}}}}}이(가) 작동하지 않는다.

미리 고맙다.Ikip (토크) 00:36, 2009년 2월 1일 (UTC)

통상적인 <span></span> 코드에 실패하는 경우(일부 상황에서 작동될 경우), 스팬의 {{#tag:span 내용을 여기에서 id="를 사용하십시오.A"}}. 자세한 내용은 여기를 참조하십시오.대수학자 00:46, 2009년 2월 1일 (UTC)
Smiley.svg 감사합니다, alg (토크) 00:55, 2009년 2월 1일 (UTC)
찾았어: mw:도움말:매직_words#미기타 :(아이킵(토크) 01:01, 2009년 2월 1일 (UTC)

모든 blps에 대한 편집통지

카테고리별로 식별된 모든 blps에 대한 편집 공지 표시 가능 여부:살아있는 사람들(Webedia:마을 펌프(제안)#모든 blps에 대한 Editnotice), disabigation page에 대해 행해진 것과 유사한 것 (여기 참조) ? Cenarium (Talk) 23:13, 2009년 1월 31일 (UTC)

모든 BLP에 일관성 있게 포함되고 비 BLP 기사에는 포함되지 않는 템플릿이나 메타트메이트가 있는가?난해한 페이지들의 상황은 그렇다.{{dmbox}})) 그래서 편집인트로 자동 추가하기 위해 자바스크립트를 쉽게 구할 수 있다.이러한 템플릿이 있는 경우에만 BLP에 대해 동등하게 수행할 수 있다.해피멜론 23:34, 2009년 1월 31일 (UTC)
BLP에 대해 수행할 수 있는 작업이 있는지, 또는 BLP에 대해 어느 정도의 차이가 있을지는 확실하지 않지만, 각 페이지 상단에 있는 "이 페이지 편집" 탭을 클릭하여 현재(적어도 나)만 편집 통지가 표시되며, 편집 통지는 디프에서 편집을 클릭할 때 나타나지 않는다.현명한 2009년 1월 31일 (UTC)
실제로 이는 스크립트가 하는 모든 작업이 해피멜론 10:21, 2009년 2월 1일(UTC) 링크에 매개 변수를 추가하기 때문이다.
사용자:RockMFR/blpeditintro.js. --- RockMFR 23:41, 2009년 1월 31일(UTC)
내게 효과가 있다 :) 고마워, 세나리움 (토크) 00:11, 2009년 2월 1일 (UTC)

섹션 편집 시 편집 소개도 추가할 수 있는가? Cenarium (Talk) 18:38, 2009년 2월 1일 (UTC)

"기사의 품질에 대한 평가 표시"

"기사의 품질에 대한 평가 표시"는 내 계정에는 통하지 않는다.가젯 옵션(작동되지 않음)을 사용한 다음 monobook.js(작동되지 않음)의 스크립트를 사용해 보았다.로크의 고스트 13:03, 2009년 2월 1일 (UTC)

사용자 대화:보다 자세한 정보가 포함된 화로정신/메타데이터.게리 (대화) 17:33, 2009년 2월 1일 (UTC)

워치리스트로 이동

나만 이걸 눈치챈 거야?최근에 나는 내가 어디에 있든지 간에 감시 목록에 오르는데 시간이 오래 걸리는 것 같다는 것을 알아차렸다.나만 그런 거야, 아니면 로딩 프로브가 있는 거야?SS가 아닌 남부, 미안 14:03, 2009년 2월 1일 (UTC)

불일치 AES

이전 편집으로 인해 내용이 교체되었다고 해야 하는데 왜 여기에 페이지가 만들어졌다고 하는가? -- 멘티피스토 16:51, 2009년 2월 1일 (UTC)

왜냐하면 이전 편집은 당시에 삭제되었고, 나중에 삭제되지 않았기 때문이다.로그를 참조하십시오.대수학자 17:05, 2009년 2월 1일 (UTC)

관리자에 대한 억제 간접 사용 가능 제안

WP:VPR#제안: 영어 위키백과에서 sysops에 대한 간접 억제 권한을 사용 가능으로 설정하십시오.프로데고 01:35, 2009년 2월 2일 (UTC)

특수 방법:무작위 작업?

Special(특수) 알고리즘을 아는 사람:무작위 사용?그 알고리즘은 얼마나 오래 사용됐지?

사용자:와 같은 연구의 신뢰성에 영향을 미치기 때문에 묻는 것이다.Knulclunk/랜덤.

얼마 전, 나는 Random에 대한 비공식적인 테스트를 했고, 거기에는 매일 다른 주제들이 떠도는 것 같았다.클러스터링은 주제보다는 기사-창작자-이름, 기사-창작자-날짜와 같은 기초적인 것이었을 수 있지만, 어떤 경우에도 무작위로 보이지는 않았다. davidwr/(토크)/(기조)/(이메일) 03:36, 2009년 2월 2일(UTC)

토픽클러스터가 내장되어 있지 않다.SpecialRandom 페이지에서 관련 코드의 대부분을 볼 수 있다.php. 내가 알기로는 페이지가 만들어지면 0과 1 사이의 임의의 숫자가 주어진다.특수:랜덤은 임의의 숫자 x를 선택한 다음 가장 낮은 숫자가 x보다 크거나 같은 페이지를 선택한다.이 때문에 개별 페이지가 더 자주 등장할 수 있다.만약 당신이 매우 작은 wiki를 가지고 있다면, 당신은 이것을 알아차릴 것이다.--- RockMFR 04:33, 2009년 2월 2일 (UTC)

느린 페이지

위키피디아에는 다음과 같은 것이 있다.브라우저(IE7)를 느리게 만드는 삭제 검토.자바스크립트인 것 같은데, 고쳐야 할 것 같아.SharkD (토크) 01:12, 2009년 1월 31일 (UTC)

성능 문제(고 CPU 사용량)를 유발하는 한 가지 식별 가능한 것은 main.css의 다음과 같은 CSS 규칙이다.
.TablePager tr:호버 td { 배경색: #eeff }
특정 페이지에서는 사용하지 않지만, 여전히 문제를 일으킨다.이 규칙의 포함이 중요하지 않으면 제거해야 한다. --- RockMFR 22:48, 2009년 1월 31일(UTC)
bugzilla:17294. --- RockMFR 23:16, 2009년 1월 31일 (UTC)
Firefox를 사용해 보셨습니까?훨씬 빠르고 부팅할 수 있는 맞춤법 검사 기능이 내장되어 있다.—2009년 2월 1일 00(talk):10, 점 기억(UTC)
나는 Avant Browser를 사용한다.내가 필요한 모든 기능이 있어, 고마워.SharkD (대화) 03:14, 2009년 2월 3일 (UTC)

여기에 링크된 내용

나는 (지금의 오해를 불러일으키는) 로부터 몇 가지 리디렉션을 정리하고 있었다.제목 없는 사무실파크 레크리에이션으로의 분사 그리고 나는 기술적인 문제에 부딪혔다.페이지에 있는 링크에 따르면, 전자는 그것에 연결되는 많은 오피스 관련 페이지[11]를 가지고 있지만, 나는 아무리 생각해도 링크를 어떻게, 어디서 고칠 수 있는지 알 수 없다.그들은 템플릿에서 벗어난 것 같지 않다.누가 나에게 이것을 설명해 줄 수 있니?Rockpocket 06:25, 2009년 2월 2일 (UTC)

제목 없는 Office Spin-Off에 대한 링크가 템플릿에서 방금 제거된 것 같다.몇 시간 전에 오피서스.작업 대기열이 링크 제거를 따라잡는 데 몇 시간이 걸릴 수 있으므로 작업 대기열이 따라잡힐 때까지 해당 기사는 여전히 여기서 What link 아래에 나열된다.걱정하지 마, 몇 시간 안에 고쳐야 해.--에어바나트 (대화) 06:49, 2009년 2월 2일 (UTC)
아, 말이 되네.고마워!Rockpocket 07:00, 2009년 2월 2일 (UTC)
1월에 WhatLinks는 몇 주가 걸릴 수 있다.업데이트하기 위해 여깄습니다.#Stubborn 백링크를 참조하십시오.이게 바뀌었는지 모르겠다.프라임헌터 (토크) 2009년 2월 2일 (UTC) 14:09

사용자의 초기 기여에 도달할 수 없음

오케이 이건 이상한거야.사용자:작은 구루와 그의 사용자가 기여하는 것.그러나 이 리틀 구루의 사용자 페이지(최근의 역사를 통폐합한 것)를 확인해 보면, 2001년부터 적어도 2002년 3월까지 공헌한 것으로 보이는 「리틀_구루」(아래줄 참조)의 사용자 이름이 있다.문제는 사용자들이 기여하는 기여에 접근할 수 없다는 것이다 - 특별:기여/리틀_구루(Little_guru)는 간격 있는 사용자 이름으로 나를 안내하고, 특수:공헌/리틀%5fguru(URL 인코딩)도 마찬가지다.이것도 역시 통하지 않는 향수 위키백과에서 사용자의 기여도를 체크하는 것 외에 이 문제를 해결할 수 있는 방법이 없을까?Graham87 13:55, 2009년 2월 2일 (UTC)

사용자 이름을 포함한 기사 이름의 밑줄과 공백은 미디어위키 소프트웨어에서 동일한 문자(공간)로 처리된다.이것이 항상 사실이었는지는 확실하지 않다.나는 또한 데이터베이스 변경으로 인해 초기 기여 이력이 신뢰할 수 없다고 들었다.언제 이런 일이 일어났는지는 잘 모르겠지만, 2002년 3월은 적절한 시간처럼 들린다.아마도 그 때 주변에 있던 누군가가 의견을 말할 수 있을 것이다.GFDL의 목적을 위해서는 어딘가에 이것에 대한 설명이 있어야 할 것 같다.좀 봤는데 아무것도 못 찾았어. -- 릭 블록 (대화) 14:59, 2009년 2월 2일 (UTC)
나는 그 두 가지를 모두 알고 있다. 나는 소프트웨어 변환 중에 밑줄이 공간으로 변환되지 않은 것이 이상하다고 생각한다.아마도 우리는 언더라인으로 사용자 이름의 오래된 기여를 알아내기 위해 sysadmin이 필요할 것이다.MediaWiki가 설치되기 전의 기사 기록에 대한 자세한 내용은 위키백과:Usemod 아티클 히스토리.내가 이상한 사용자 이름과 함께 발견한 차이점은 미디어위키로의 전환 이후여서 상황을 더욱 곤혹스럽게 만든다.Graham87 15:08, 2009년 2월 2일 (UTC)
사용자 테이블에는 user_name = "Little_guru"와 1 = "Little guru" 두 개의 항목이 있을 수 있다.모든 텍스트 이름은 지금 입력 파서에 의해 정규화되므로, 당신은 그 이름을 사용하는 "Little_guru"에 대한 기여를 결코 얻을 수 없었다(그리고 관리자도 할 수 없었다).
툴 서버에서 DB 액세스 권한을 가진 사람에게 user_name이 Little<wild>guru와 일치하는 사용자 테이블에 user_id 항목을 나열하도록 요청할 수 있다.rev_id = 268029449에 대한 개정표와 리틀 구루에 대한 현대적 차이에서 rev_user와 비교해 보면 답이 나온다.
암호 인증이 계속 작동하도록 하기 위해 변환할 때 이름에 "_"가 포함된 모든 사용자 항목을 복제해야 했을 수 있다.어쨌든 그것밖에 생각이 나지 않는다...Framanax (대화) 17:41, 2009년 2월 2일 (UTC)
고마워, 툴서버에 요청했어.Graham87 02:59, 2009년 2월 3일 (UTC)

오류

여보세요. 조금 전에 시스템에 오류가 있었어.시스템 관리자에게 다음 내용을 보여주어야 함:

요청: 71.1987.53.254에서 sq21까지 POST http://en.wikipedia.org/w/index.php?title=Talk:Oda_Nobunaga&action=submit,.wikimedia.org (1998/2.6).SAVEL21) ~ 208.80.152.27(208.80.152.27) 오류: ERR_READ_타임아웃, 에러 없음 [오류 없음] 2009년 2월 15일 02:48:02 GMT

불행히도 나는 위키피디아의 시스템 관리자와 일반 관리자 사이를 구별할 수 없다.이런 일이 가끔 일어나기도 한다(물론 정확한 날짜와 시간을 제외한다).-BlueCaper (대화) 16:22, 2009년 2월 2일 (UTC)

위키피디아는 그 순간 정말, 정말로 느리다. (ERR_READ를 정의하라)타임아웃).나는 아직 성공적으로 내 감시 목록을 로드하지 못했다. TKD:토크 16:41, 2009년 2월 2일 (UTC)

템플릿 다운

모든 템플릿이 어떤 이유에서인지, 이름만 공개하고 적절한 페이지로 위키링크만 공개하는 등, 모든 템플릿이 파쇄된 것 같다.무슨 일이 일어나고 있는지 아는 사람? -제레미 19:28, 2009년 2월 2일 (UTC)

결코 모든 템플릿이 깨진 것은 아니다.어떤 페이지가 있는지 예를 들어 줄 수 있니?대수학자 19:31, 2009년 2월 2일 (UTC)
{{user}} 및 {{checkuser}}}을(를) 사용해 보십시오미안하다. Jarl 양말/잡버의 손상을 복구하는 이었는데 WP에서 본 것만 보았다.SPI. -제레미(v^_^v Dittobori) 19:41, 2009년 2월 2일 (UTC)
그 페이지는 너무 크고, 템플릿이 너무 많다.확장 후 포함 크기는 2047998바이트로 제한은 2048000이다.소프트웨어가 이러한 제한 중 하나에 도달하면 제한치 이상으로 템플릿을 확장하지 않는다.위키백과 참조:상세 내역에 대한 템플릿 제한.대수학자 19:50, 2009년 2월 2일 (UTC)
그래, 정보 고마워, 대수학자-제레미 20:00, 2009년 2월 2일 (UTC)

홀로도모어 대화 페이지 문제

나는 홀로도모어 토크 페이지에서 기술적인 문제를 경험한다.대화 페이지를 열려고 하면 내 컴퓨터(Red Hat Enterprise)가 즉시 다시 시작됨.내가 윈도우 컴퓨터를 사용할 때는 이런 일이 절대 일어나지 않으며, 리눅스 시스템에서 다른 WP 페이지(대화 페이지 포함)를 입력할 때는 절대 일어나지 않는다.동일한 결과를 가진 두 개의 다른 Red Hat 리눅스 시스템을 사용한다(즉시 재부팅).그게 무슨 뜻인지 누가 설명해줄래?
미리 고맙다.
안부 전합니다
--폴 시버트 (토크) 19:40, 2009년 2월 2일 (UTC)

내가 미쳐가는 거야?

이 사안은 적극적으로 조사되고 있다. --briion (대화)

해결됨
참조 태그를 캐싱하여 렌더링을 최적화하려는 시도가 인라인 데이터 스트리핑에서 분산을 고려하지 못했다. 그 변화는 이미 역전되었다. 영향을 받는 페이지는 삭제해야 할 수 있다.

나는 최근에 비스나 바이러스에 대한 참조를 추가했다.하지만 컴퓨터에 이상하게 계속 나타나 (캐시를 몇 번 지우더라도)...다음 내용:

[http://discovermagazine.com/1994/dec/ofmythsandmischi458 "신화와 장난" , "[Discover (Discover) Discover]]", 1994년 12월 1일.

다음과 같이 나타나야 한다.

1994년 12월 1일, 디스커버리

기사에서 계속 보고 있는데

1994년 12월 1일 뇌염, "신화와 장난"

그 페이지의 참고문헌 #13에서 내가 보고 있는 것을 다른 사람이 보는가?— 2009년 2월 2일 사이언티즐 20:47 (UTC)

나는 ref의 이름("Discover")이 다른 ref와 충돌하고 있었다고 생각한다."Discover-Dec94"로 바꿨는데 이제 효과가 있는 것 같아.EVULA// 통화 // // 20:55, 2009년 2월 2일 (UTC)
난 그 변화를 봤어..."Discover"를 원격으로 닫은 다른 참조 이름이 없어서 어떻게 작동하는지 잘 모르겠다.다시 한번 말하지만, 너의 변화에 따른 정확한 결과를 본 후, 그것은 다시 "뇌염"으로 되돌아갔다.PC를 다시 시작해야 할 것 같아... 커피도 좀 사와야겠어.— 사이언티즐 20:58, 2009년 2월 2일 (UTC)
그것은 아직도 나에게 깨져 있다. (아마도 내 편집이 어떻게 해서든 그것을 재조정할 수 있을까?)현재는 ref 이름을 변경하면 미리보기에서는 수정되지만 실제 기사에서는 수정되지 않는다.대수학자 20:59, 2009년 2월 2일 (UTC)
워, 그래.헷갈리네...숙청도 도움이 안 돼*머리 자르기* EVULA //말하기 // 21:03, 2009년 2월 2일 (UTC)
새로운 캐싱 시스템이 참조 태그를 위해 막 설치되었다.그것은 아직 몇 개의 곤충을 가지고 있을지도 모른다.드래곤즈 비행 (토크) 21:01, 2009년 2월 2일 (UTC)
아... 흥미롭군브라우저에서의 나의 스위치와 저장된 인터넷 데이터를 완전히 삭제하는 것은 도움이 되지 않았기 때문에, 새로운 ref caching 시스템이 범인으로 보인다.— 2009년 2월 2일 21:04(UTC)
그래, 나는 이것을 다른 기사(윌리엄 헨리 엘리스)에서 알게 되었는데, 이제 ref 시스템은 기사에서 접하는 첫 번째 wikilink를 ref의 wikilink의 목적지로 사용하는 것 같다.처음에는 인용 템플릿인 줄 알았는데 내가 몇 가지 연습 편집을 했는데 참고 태그에 뭐가 들어가든 그렇게 하는 것 같아.처음에는 내가 미쳐가고 있다고 생각했지만, 곧 정리되길 바란다 - 두멜로 (토크) 21:05, 2009년 2월 2일 (UTC)

WT에서도 이 내용을 확인하십시오.FOOTY. D.M.N (대화) 21:31, 2009년 2월 2일 (UTC)

참조 태그를 캐싱하여 렌더링을 최적화하려는 시도가 인라인 데이터 스트리핑에서 분산을 고려하지 못했다.그 변화는 이미 역전되었다.영향을 받는 페이지는 삭제해야 할 수 있다. --briion (토크) 21:37, 2009년 2월 2일 (UTC)

저널 렌더링 문제 인용

해결됨

이전 버전네메시스코에서 참조 9와 11은 왜 UNIQ174fb445295d998f-nowiki-000059-QINU와 같은 문자열을 표시하면서 이상하게 렌더링되는가? {{Cite journal} 및 {{cite study}}를 사용한다.빈 출판사=필드를 없앴으니 괜찮다.Template_talk에서 토론:Cite_journal#Rendering_problem. --Apoc2400 (대화) 21:39, 2009년 2월 2일 (UTC)

나는 이것이 바로 위의 실과 같은 문제였을지도 모른다고 생각한다.대수학자 21:42, 2009년 2월 2일 (UTC)
맞아. --Apoc2400 (대화) 21:58, 2009년 2월 2일 (UTC)

리디렉션이 작동하지 않음

여기서 지적한 바와 같이, 몇 개의 리디렉션이 작동하지 않는 경우가 있는데, 를 들어, 쉘 하우스 절벽, Zeuxis와 Parrhasius, 그리고 2007년 가자 해전이다.무슨 일이야?와레 (토크) 00:15, 2009년 2월 3일 (UTC)

업데이트. 좋아, 나한텐 부두 같은데, 리디렉션 후 공간을 제거해서 세 개 다 고쳤어.와레 (토크) 00:18, 2009년 2월 3일 (UTC)
공간을 없애지 않고 다시 작동하게 만든 리디렉션을 편집했다는 사실인 것 같아.Null 편집은 충분했을 것이다. Edokter Talk • 00:40, 2009년 2월 3일 (UTC)
Special:최대 29바이트의 단축 페이지를 첫 번으로 정리했다.어떤 도움이라도 고맙게 생각하겠는데, 이것은 가장 재미있는 일이 아니기 때문이다. :-) 카를로스수아레즈46 (토크) 01:10, 2009년 2월 3일 (UTC)
그러니 그만하고 누가 대신 벌레를 고칠 수 있는지 보는 게 어때?그리고 내가 무슨 일이냐고 물었을 때 큰 소동을 일으켜줘서 고마워.바보. 디클라이언 (대화) 05:09, 2009년 2월 3일 (UTC)

대화 페이지의 "Cite error" 메시지

오류 메시지가 표시됨Cite error: <ref> tags exist, but no <references/> tag was found최근 일부 토크 페이지 하단에 등장(예: 토크:버락 오바마 취임식대담:인구 과잉.나는 그것이 경고가 없다면 가장 좋을 것이라고 생각한다. 왜냐하면 꽤 많은 사람들이 위키텍스트를 기사에서 토크 페이지로 복사하지만, 토크 페이지는 기사와 다르게 배치되고 참조 섹션은 맞지 않는 것 같기 때문이다.토크 페이지에 대한 경고를 끌 수 있을까? -- 배리브 (대화) 09:57, 2009년 1월 28일 (UTC)

페이지를 리팩터링하고 Wiki에 <ref> 태그를 추가하면 어떨까?---— Gadget850(Ed) - 12:42, 2009년 1월 28일(UTC)
그래, 가능하긴 하지만, 단지 경고 메시지를 없애기 위해 대화 페이지에서는 꽤 비생산적인 지속적인 작업이 필요하다.인용 연장은 경고 대신 자동으로 토크 페이지 하단에 참조를 표시할 수 있는가? - 배리브 (토크) 13:23, 2009년 1월 28일 (UTC)
음... 이건 새로운 메시지처럼 보여. 지금 카테고리에는 많은 대화 페이지가 있어.해당 문제에 대한 참조 형식이 잘못된 페이지.그 인용문은 확실하다.php는 그러한 방식으로 업데이트될 수 있지만 몇 가지 문제가 있다. --— Gadget850 (Ed) - 14:19, 2009년 1월 28일 (UTC)
이것은 엔위키만의 문제가 아니다; 나는 중국 위키피디아와 메타에서 정확히 같은 오류를 발견했다.EVULA// 통화 // // 22:52, 2009년 1월 28일(UTC)
이 오류 메시지가 기사 페이지에만 나타나도록 하는 것이 가장 이치에 맞다.나는 단지 오류 메시지를 제거하기 위해 대화 페이지의 참조를 편집하는 것은 비생산적이며, 페이지가 명시적으로 참조 목록을 요청하지 않더라도 확장자가 자동으로 참조 목록을 생성하는 것도 그다지 타당하지 않다는 데 동의한다.게리 (대화) 22:59, 2009년 1월 28일 (UTC)

좋아, 그런 변화를 시행할 지 여부를 결정할 수 있는 개발자로부터 의견을 들을 수 있을까?배리브 (대화) 00:07, 2009년 1월 29일 (UTC)

MediaWiki:인용 오류는 아마 비워져야 할 것이다...큰 빨간색 오류 메시지보다는 숨겨진 카테고리에 찬성한다. --MZMcBride (대화) 03:48, 2009년 1월 29일 (UTC)

그래, "Cite error" 메시지를 완전히 숨기려면 "$1"로 줄여야 해.그런 다음, "Cite error: "를 다른 인용 오류 메시지에 다시 추가하고 싶을 것이다.그렇게 된다면 <참조/>오류 메시지를 네임스페이스에서 검출하는 ParserFunction으로 포장하여 기사 페이지에만 표시할 수 있을 것 같다.드래곤즈 비행 (토크) 05:50, 2009년 1월 29일 (UTC)
MZMcBride는 이제 테스트로 이 메시지를 만들었다.만약 작동한다면, 네임스페이스는 임의로 추가/제거할 수 있어야 한다.도마가 우리 모두를 죽일 때까지, 물론. --Splarka (rant) 08:46, 2009년 1월 29일 (UTC)
이 구현의 문제는 인용 오류가 메인 스페이스 밖에서 전혀 보이지 않는다는 것이다.단순히 누락된 <참조/>의 구체적인 사례와는 반대로 모든 경우에 묵묵히 실패하기를 인용하고 싶은 것은 명백하지 않다.드래곤즈 비행 (토크) 08:55, 2009년 1월 29일 (UTC)
누락된 <참조/>만 숨기려면 다음과 같이 하십시오.
{{#스위치:{{네임스페이스} =<span class="cite-error-shown" #default=<span class="cite-error-hidden" 스타일="display:none;speak:none;"}}}}Cite 오류: $1</span>
그리고 사이트 전체 CSS: . 비록 이것은 더러운 해킹과 접근성 회귀라고는 하지만. --Splarka (rant) 09:16, 2009년 1월 29일 (UTC)

그렇다면 현재 상태는 어떤가?기사 초안은 많은 네임스페이스(특히 Talk and User)에서 찾을 수 있고, 묵직한 실패(또는 똑같이 나쁜, 숨겨진 오류 메시지) 대신 의미 있는 오류 메시지가 있으면 좋을 것 같아, 나는 네임스페이스당 전환이 너무 좋아하는지 잘 모르겠다.쿠스마 (토크) 09:25, 2009년 1월 29일 (UTC)

어제 이걸 봤는데, 실생활에 방해되더라.인용문을 살펴보았다.php 코드, 메시지는 MediaWiki에 의해 제어된다.참조가 없는 오류 참조를 인용하십시오.네임스페이스 스위치도 생각해봤는데 문제가 있어.{{reflist}}}}을(를) 사용하지 않고 ref를 추가하는 것이 문제인 만큼 이에 대한 오류의 발상이 마음에 든다.아마도 우리는 대화 페이지에서만 그것을 무력화시킬 수 있을 것이다.메시지에서 누락된 {{reflist}}을(를) 삽입하는 것은 가능하겠지만, 그렇게 하는 것이 아마도 최선의 방법은 아닐 것이다.또 다른 방법은 다음과 같은 범주를 확인하는 봇을 두는 것이다.참조 형식이 잘못된 페이지 및 토크 페이지의 참조 태그를 변환하는 페이지. - - - Gadget850(Ed) - 14:32, 2009년 1월 29일(UTC)
오늘 이것을 보면, MediaWiki:Cite error는 이제 네임스페이스를 전환한다; 메시지는 더 이상 대화 페이지에 나타나지 않는다.MediaWiki:참조가 없는 인용 오류 참조가 공백으로 표시되었으므로, 이제 기사는 암호화된 "Cite Error:" 메시지를 표시하고 Category에 배치된다.참조가 깨진 위키백과 페이지
다음과 같은 경우 참조 없이 Cite 오류 refses 오류 참조가 생성된다.
  • 있다<ref>...</ref>태그는 있지만 <references/> 태그는 없음(보통 {{reflist}}으로 생성됨)
  • <참조/> 바로 앞의 참조에 닫힌 </ref>가 없다.
  • 있다<ref>...</ref><<references/> 뒤의 태그
---- Gadget850 (Ed) - 15:06, 2009년 1월 29일 (UTC)
나는 <참고/> 태그가 없는 페이지 하단에 자동으로 각주 부분을 추가하는 패치를 bugzilla에 제출했지만 개발자들은 그 아이디어를 좋아하지 않는 것 같다.청발 변호사 17:24, 2009년 1월 29일 (UTC)

인용오류

MediaWiki에서 생성된 메시지:참조가 없는 인용 오류 참조는 제거되었다.따라서 <참조/> 태그가 없는 기사는 이제 암호화된 Cite 오류: 메시지를 보여준다.예를 들어 "무료"를 참조하십시오.하고 청한다.

  • "의 이전 메시지 복원Cite error: <ref> tags exist, but no <references/> tag was found".
  • 위키백과 작성:현재의 오류와 해결 방법을 제시하기 위해 오류를 인용하십시오. 이 토크 페이지는 우리에게 인용 오류 시스템의 개선을 논의할 수 있는 중앙집중식 장소를 제공할 것이다.

---- Gadget850 (Ed) - 2009년 1월 30일 (UTC)

좋아, 나는 인용 오류 메시지에 대한 포괄적인 조사를 했다.첫째로, 나는 미디어위키를 다음과 같이 만들었다.오류를 투명하게 인용: 오류 메시지를 전달하고 추가만 하면 된다.{{broken ref}}기본 추적 범주인 페이지(Talk:, User: 및 MediaWiki: 네임스페이스)를 제외한 모든 페이지에 잘못된 참조 형식을 가진 페이지를 추가하는 템플릿.이는 각 오류 메시지를 별도로 처리할 수 있다는 것을 의미한다.따라서 "Cite error:" 부분을 각 메시지의 전면에 복사하고 MediaWiki에 추가된 네임스페이스 스위치 MZMcBride를 이동했다.MediaWiki대한 오류 인용:이 모든 것을 시작했던 참고자료 없는 오류 참조를 인용하라.이것은 이 메시지가 메인 스페이스 밖에 숨겨져 있다는 것을 의미한다.특정한 오류가 있는 모든 페이지는 또한 MZ가 만든 또 다른 추적 범주인 위키백과 페이지로 분류된다.나는 이 추가 범주가 유용하다고 생각하지만, 좀 더 구체적으로 이름을 바꿔야 할 것 같다.해피멜론 15:36, 2009년 1월 31일 (UTC)

도움말 작성:가끔 암호화된 메시지를 설명하기 위해 오류를 인용하라.토크 페이지를 사용하여 문제와 개선 사항에 대해 논의할 수 있다. - - Gadget850(Ed) - 14:48, 2009년 2월 3일(UTC)

기록 페이지에서 RSS 및 Atom 오렌지 아이콘 제거

최근 페이지의 내역을 볼 때 RSS 및 Atom 텍스트 옆에 웹 피드를 나타내는 주황색 아이콘이 있다.나는 개인적으로 그것들이 주의를 산만하게 한다고 생각한다; 만약 다른 사람도 산만하게 한다면, 당신은 당신의 monobook.css 페이지를 편집하고 새로운 줄에 다음과 같은 코드를 추가하면 간단히 그것들을 제거할 수 있다.

a.피드링크 { 배경: 없는; 패딩 왼쪽: 0px를 붙이다; } 

건배! 게리 (토크) 2009년 1월 29일 19:26 (UTC)

고마워, 잘했어.단지 궁금할 뿐인데, 최근에 추가된 아이콘은 어디에 있는가?가리온96(토크) 18:30, 2009년 1월 31일 (UTC)
그것들은 r46058년에 미디어위키 소프트웨어에 추가되었다.대수학자 18:38, 2009년 1월 31일 (UTC)
고마워! -- Lucasbfr 16:21, 2009년 2월 3일 (UTC)

편집자가 축소된 템플릿을 만들도록 허용

해결됨

동일한 템플리트를 사용하는 사람이 템플리트의 접힘 여부를 선택할 수 있는가?도움:협박을 하는 것은 도움이 되지 않는다.

예: {{WP:ARS/Tagged}}은(는) 기본적으로 접히지 않는다.

편집자가 템플릿을 축소하도록 선택할 수 있는 방법이 있는가?원래 템플릿을 변경하지 않고?이킵 (토크) 15:28, 2009년 2월 1일 (UTC)

그 때는 아니에요.그러나, 만약 여러분이 이미 알지 못한다면, 같은 페이지에 둘 이상의 접을 수 있는 상자가 있다면(그리고 클래스를 사용한다면), 그것들은 모두 기본적으로 자동적으로 붕괴된다.게리 (대화) 2009년 2월 1일 (UTC) 17시 31분
Face-smile.svg 게리 정말 고마워.이킵 (토크) 06:14, 2009년 2월 4일 (UTC)

접속일월발행?

해결됨

안녕!

{{cite 웹}}을(를) 많이 사용하고 그 안에 접속월 및 접속년 필드를 사용하는 Ref가 많은 기사(Kala(앨범)가 있다.그러나 현재 어떤 액세스 날짜 값도 표시되지 않고 있다.템플릿에 문제가 있는지....? -- Chris TheDude (토크) 09:57, 2009년 2월 3일 (UTC)

내 생각에 접속날짜는 그것을 대체한 것 같은데 나는 100%가 아니다.Bidgee (대화) 09:59, 2009년 2월 3일 (UTC)
접속 날짜로 바꿀 수도 있지만, 어떻게 날짜 형식을 미국 스타일(월일)이 아닌 영국 스타일(일월)으로 표시되도록 설정하십니까? -- Chris TheDude (토크) 10:53, 2009년 2월 3일 (UTC)
날짜 형식 매개 변수를 알아낸 것 같군. --— Gadget850(Ed) - 11:37, 2009년 2월 3일(UTC)
응, 마지막에 검색해봐. :-) -- Chris TheDude (토크) 11:50, 2009년 2월 3일 (UTC)

변환 템플릿의 " "kipz"?

어제 노트북 기사를 읽다가 본문에는 '그래서 내가 너를 떠다닌다'는 문구가 계속 나왔지만 편집 요약본에서는 찾을 수 없었다.결국 나는 그것이 Template:convert에서 온 것이라는 것을 알아내서 {{convert 0.7 - 15 in}}}}}}}은 다음과 같이 보였다: 0.7–15. 그래서 I Hand You Liek Mudkipz (18–380 mm).누군가가 고쳤고 템플릿은 지금 정상적으로 작동한다.

변환 템플릿 자체를 보면 변경 사항이 없지만, 이것은 수천 개의 관련 페이지와 코드 비트를 대량으로 초월하는 것으로 보인다(카테고리:하위 플레이트_of_템플릿_변환) ... 학문적 이해를 위해서, 수천 개의 하위 플레이트 웹에서 변경된 것을 어떻게 볼 수 있을까? -- DMahalko (토크) 20:29, 2009년 2월 3일 (UTC)

0.7–15인치(18–381 mm)를 했을 때, 머드키프즈가 이 편집을 통해 들어왔다. --NE2 20:33, 2009년 2월 3일 (UTC)
다른 방법으로 찾았어:Template:convert에서 "Related changes"를 클릭하고 Template 네임스페이스를 선택하고 Template:Convert/-/AoffSoff가 유일한 최근 버전이다.프라임헌터 (토크) 2009년 2월 3일 (UTC) 20:40

데이터베이스 덤프, 다시

다시 생각해내서 미안해.10월부터 시작된 enwiki 데이터베이스 덤프는 현재 최종적으로 실패했거나 종료되었다[12].(누군가 플러그를 뽑은 덕분에)그러나 엔위키는 현재 덤프 대기열[13]의 끝에 있고 다음 덤프는 3주 정도 후에 시작될 것이다.

엔위키를 줄 맨 위로 옮길 수 있을까?

그 이유는 내가 데이터베이스 덤프에 따라 널리 사용되는 봇을 운영하고 있기 때문인데, 사용자들이 당연히 내 토크 페이지(약 2개월 이후)에서 데이터 업데이트를 계속 요청하기 때문이다.나는 페이지 콘텐츠에는 관심이 없고, 메타데이터 테이블에만 있고, 이것들은 덤핑하는데 며칠이면 된다.그래서 지금 덤프를 시작하면 며칠 안에 새로운 데이터를 제공할 수 있을 것이고, 이것은 상황을 개선시킬 것이다.

정말 고마워. --B. 월터딩 (토크) 2009년 1월 31일 18:46 (UTC)

브리온은 1월 29일에 그것을 죽였다.우선 순위를 매기려면 그를 찔러야 할 것이다.해피멜론 18:52, 2009년 1월 31일 (UTC)

기사 내용을 덤프하는 것이 기사 기록을 포함하는 덤프보다 더 빠를까?라이트마우스 (대화) 03:39, 2009년 2월 2일 (UTC)

응; 사실 현재 덤프 절차는 메타데이터를 먼저 덤프한 다음 내용, 이력 등을 덤프하기 때문에 내가 관심 있는 부분은 보통 며칠 안에 끝내는 것이 보통이다.-B 월터딩 (대화) 21:37, 2009년 2월 3일 (UTC)

콘텐츠로만 운영할 수 있는 과제가 많다고 확신한다.긴 덤프 프로세스를 내용물만 짧은 프로세스로 분할할 수 있는가?라이트마우스 (대화) 12:37, 2009년 2월 4일 (UTC)

범주 이름 변경 및 이전 캣에서 새 캣으로 다시 연결하기 위한 도움말

기사 구조대에는 다음과 같은 범주가 있다.삭제 제안되었지만 좋은 칵테일 대화를 위한 것이 아닌 백과사전적 주제와 관련된 기사들. 우리는 카테고리로 이름을 바꿀 생각이다.삭제구조를 위해 태그가 지정된 기사.고양이 안에 있는 기사들은 모두 우리의 {{rescue} 태그에서 뽑은 것이지만, 고양이 페이지를 보고 있는 것 또한 그곳의 다른 물건 링크들을 보고 있다.모든 것을 망치지 않기 위해 어떤 조치를 취해야 하는가? - 반제보이 09:43, 2009년 2월 2일 (UTC)

그럼 그냥 우리가 직접 할까? -- 반제보이가 13:08, 2009년 2월 4일 (UTC)
무슨 걱정이야?이 카테고리에 현재 17페이지가 있으며,{{rescue}}또한 17페이지에 걸쳐 있다.이름을 바꾸면 "모든 것을 스크루업"할 수 없으며, 기다리지 않으려면 범주 이름을 바꾸고 템플릿을 변경한 후 이전 범주에 남아 있는 모든 페이지에서 null 편집을 수행해야 한다.내부작업은 잘 모르겠지만 우선 템플릿을 변경한 다음 범주 이름을 바꾸는 것이 좋다.그렇게 하면 null 편집이 절약될 수 있다. --Amalthea 13:50, 2009년 2월 4일(UTC)
템플리트가 현재 기사를 채우지만 "카테고리:삭제 제안은 했지만 백과사전적 주제와 관련이 있을있는 기사"라고 말했다.우리는 또한 범주에서 끌어내는 봇도 가지고 있다. o 우리가 새로운 범주 페이지를 만들고, 템플릿을 조정하고, 오래된 고양이 페이지를 새로운 것으로 리디렉션한다면, 사물을 다루는 것이 될 것인가 아니면 그들의 다른 단계일 것인가? 아니면 우리는 단지 그것을 추구하고 발생되는 문제들을 해결할 것인가? -- Banjeboi 15:19, 2009년 2월 4일 (UTC)
나는 그 링크의 전부 또는 대부분이 ARS 프로젝트 배너와 사용자 박스에서 나온 것이라고 생각한다.이러한 템플릿의 링크를 변경하고 남아 있는 항목을 확인하십시오.대수학자 15:27, 2009년 2월 4일 (UTC)
대부분, 예, 일부 사용자:GlassCobra를 수동으로 연결한다.그러나 물론 벤지보이, 범주의 내용을 사용하는 봇이 있다면, 봇 소유자와 먼저 대화하여, 그가 새로운 범주를 사용하도록 적시에 재구성할 수 있도록 해야 한다.리디렉션은 아마도 영향을 미치지 않을 것이다. --Amalthea 16:05, 2009년 2월 4일 (UTC)
좋아, 쿨리오, 그들과 함께 가서 변화를 시작할 거야.도와줘서 고마워. -- Banjeboi 16:06, 2009년 2월 4일 (UTC)

조금은 너그러운 사람이지만 나는 이것을 알아야 한다.

나만의 사용자 페이지에서 각종 인포러스와 물건(그림, 인플루언스, 영향을 받는 타입 등)으로 박스를 만드는 방법을 배우려고 한다.바보인 건 알지만 적어도 진짜 페이지를 건드리는 건 아니지?어쨌든 템플릿이 없다고 쓰여 있고 답답해.제발 도와주세요.

--CrimsonKing2000 (대화) 04:01, 2009년 2월 3일 (UTC)

닫힌 템플릿을 찾아 해당 소스를 사용자 페이지에 복사하십시오.그러나 모든 카테고리는 반드시 제거하십시오. davidwr/(대화)/(계속)/(전자 메일) 04:30, 2009년 2월 3일(UTC)
도움말 참조:Infobox, 위키백과:위키프로젝트 전기/인포박스, 카테고리:사람 infobox 템플릿.기존 infobox 유형을 사용하려면 이미 있는 매개 변수로 제한하십시오.프라임헌터 (토크) 2009년 2월 3일 12시 25분 (UTC)
{{Infobox user}}}을(를) 찾고 있는 것 같다.위키백과에도 관심이 있을 수 있다.사용자 상자. --—— Gadget850(Ed) - 15:46, 2009년 2월 4일(UTC)

사라지는 화이트 스페이스

이 편집에서 나는 수동으로 경고를 표시했고 또한 2월 섹션에 복사/붙여넣기 방식의 피아노 논 트로포의 이전 경고를 복사/붙여넣었다.자세히 살펴보면, 적어도 하나의 공간이 이동 중에 사라지는 것을 알 수 있다("그렇게 하는 것은 위키백과의 [위키피디아:]를 위반한다.중립적인 관점 위키백과:중립적 관점 중립적 관점 정책]]" 그렇게 하는 것은 위키백과의 [[]에 위배된다"로 바뀐다.위키백과:중립적인 관점 위키백과:중립적 관점 중립적 관점 정책]]"무엇이 이런 유형의 오류를 일으킬 수 있는가?OS, 브라우저 또는 Wiki 서버 문제인가?NJGW (대화) 04:50, 2009년 2월 3일 (UTC)

아마도 OS일 것이다; 아마도 공간은 편집 상자의 줄 바꿈에 있어서 복사되지 않았을 것이다. Edokter Talk • 02:16, 2009년 2월 5일 (UTC)

잘못된 이미지 목록에서 크기 제한 및 사이트 성능

해결됨

2005년으로 거슬러 올라가면 사용자:Tim StarlingMediaWiki에 다음과 같은 메모를 추가했다.잘못된 이미지 목록: "성능상 이유로 이 페이지를 10KB 미만으로 짧게 유지하십시오."우리는 현재 12kb인데 성능 문제가 여전히 존재하는지 궁금하다.아이디어 있으신 분? - 반얀트리 11시 14분, 2009년 2월 4일(UTC)

그것은 여전히 존재하지만, 사람들은 그러한 이미지들을 보지 않기 위해 그것을 받아들일 수 있는 트레이드오프라고 결정한 것으로 보인다. (개인적으로 나는 리스트가 너무 길다고 생각한다. 그러나 나는 사용자가 만든 콘텐츠가 있는 웹사이트의 어떤 블랙리스트도 실패할 운명이라고 생각한다. 왜냐하면 당신이 아무리 크게 만들더라도, 심지어 적당히 결정한 사용자라도 목록에 없는 이미지를 찾을 수 있기 때문이다.)거흐 (토크) 2009년 2월 4일 12시 58분 (UTC)
는 도마스에게 이것에 대해 물었다.그는 성능 영향이 미미하다고 말했다. --MZMcBride (대화) 13:08, 2009년 2월 4일 (UTC)

열, 표, 알파 정렬에 도전하시겠습니까?

정답은 뻔한 답이 아니다!이건 좀 깊이 파고 영감이 필요해.그것은 가능하지 않을 수도 있지만, 확실히 그렇다!할 수 없다면 아무도 죽지 않겠지만, 그렇게 하는 것은 삶을 훨씬 편하게 해줄 것이다.

나는 아주 긴 리스트에서 현재 4개의 컬럼으로 그것을 이동시킴으로써 가독성을 위해 Jat 씨족 리스트를 포맷하는 작업을 해오고 있다.나는 엄청난 수의 이름들이 알파 순서가 아니라는 것을 알아챘고, 이것이 의도적인 것은 아니라고 의심하지만, 페이지를 많이 사용하는 편집자들과의 언어 문제일 수도 있고, 미국 알파벳의 정렬 순서에 익숙하지 않은 것일 수도 있다.

각 섹션에 대해 기고자와 독자들이 모두 쉽게 살 수 있도록 "무엇"을 만드는 간단한 방법이 있는가?

답하기 전에 그 기사를 보시오.그래, 나도 알아, 하지만 정답은 단순하게 분류할 수 있는 테이블이 아닌 것 같아.

내가 이루고 싶은 것은 분류가 가능하고 (예:) 자동으로 4개의 칼럼에 들어가 초보 편집자나 비숙련 편집자가 쉽게 새로운 멤버를 추가할 수 있는 목록이다.엑셀로 내보내고, 분류하고, 붙여넣는 것은 정답이 아니다. 특히 어떤 이름은 위키링크가 있고, 어떤 이름은 그렇지 않다.

내 토크 페이지에서 도움말을 사용하는 것이 나를 이곳으로 오게 했다.나를 도와주러 달려온 녀석들 역시 당황했다!그들의 생각을 알아보세요.Fiddle Faddle (talk) 19:47, 2009년 2월 4일 (UTC)

모든 사용자에게 적합하고 위키백과를 준수하는 솔루션을 찾을 것 같지 않음:접근성.해도 미숙련 편집자들이 쓰기란 쉽지 않을 것이다.페이지를 최대한 단순하게 유지하고 필요할 때 정리하는 것을 추천한다.--- RockMFR 21:55, 2009년 2월 4일 (UTC)
라이트 형제도 날아갈 것 같지 않았다.그러나 그들은 그랬다.추천하는 것을 봅시다.Fiddle Faddle (talk) 22:07, 2009년 2월 4일 (UTC)

분류 가능한 테이블은 정보가 둘 이상 있을 때만 유용할 것이다.여기서는 각 씨족의 이름만 가지고 있기 때문에 따로 분류할 것이 없어 자동으로 분류할 단추를 가지고 있던 취지를 꺾는다.페이지를 저장할 때 이전 순서로 항목을 추가할 수 있지만 페이지가 로드될 때(버튼을 누르지 않아도) 자동으로 정렬되도록 하려면, 그것은 별개의 문제다.그러나 정말로 페이지를 저장하기 전에 정렬을 클릭할 수 있는 것이 더 나을 것이다.CharlotteWebb 02:54, 2009년 2월 5일 (UTC)

바로 그거야문제는 분류하기를 꺼리는 것 같기도 하고, 혹은 이름을 추가할 때 페이지를 사용하는 편집자들이 분류 순서를 모르는 것 같기도 하다.나는 그것이 분류 가능한 테이블의 고전적인 용도가 아니라는 것을 알지만, 긴 단일 열만 있다면 그것은 효과가 있을 것이지만, 페이지를 분류하고 표시 가능한 것처럼 보이게 하는 것이 도전이다.Fiddle Faddle (talk) 07:21, 2009년 2월 5일 (UTC)
정렬-온-뷰는 자바스크립트가 무엇을 정렬하고 어떻게 정렬할 것인지 정확하게 추측할 수 있는 경우에만 작동한다.이것은 페이지에 따라 다를 것이다.여기 한 줄에 각각 4개의 셀이 하나씩 들어 있는데, 원하는 결과는 네 개의 리스트를 추출하여 하나로 결합한 다음 알파벳 순으로 정렬하고 다시 네 부분으로 나눈 다음 이 부분들을 다시 테이블 셀에 넣는 겁니다.기계는 행만 정렬해서는 안 된다는 것을 알 수 있는 어떤 방법이 필요하다. (한 행만 있는 것처럼 아무것도 하지 않음) 또는 열을 정렬(필요에 따라 수평으로 이동)하거나 각 목록(다른 목록과 독립적으로)에 있는 항목을 정렬해야 한다.
나는 우리가 각 페이지에 대해 별도의 자바스크립트 코드를 원하지 않을 것이라고 생각하지만, 다양한 스타일이 합리적으로 잘 정의되어 있고 숫자가 적다면 새로운 유형의 분류 가능한 테이블에 대한 지침이 위키비트에 추가될 수 있다.당신은 그것들의 이름을 지정하고 당신이 원하는 것을 위키텍스트에 명시해야 할 것이다.
그러나 이 경우(이를 분류하는 "올바른 방법"이 하나밖에 없는 경우), 잘못된 위치에 항목을 추가함으로써 알파벳 순서를 더 빠르게 하는 편집 후 정리하기 위해 봇을 실행하는 것이 최선의 선택일 것이다.
이상적으로는 모든 브라우저가 여러 열에 걸쳐 하나의 목록을 표시하는 것을 지원하므로(도구를 정렬하는 것이 더 쉽게 알 수 있음), 목록을 수동으로 잘라내고 각 하위 목록의 수직 높이를 추정할 필요가 없다.앞으로 나는 그것을 인식하지 못하는 것으로 알려진 사용자-에이전트의 컬럼-카운트 속성을 속이는 자동적인 방법을 보고 싶다.CharlotteWebb 15:45, 2009년 2월 5일 (UTC)
어쩌면 이 기사가 정말 간단한 리스트를 가지고 여러분의 "미래 방식"을 위한 인과관계가 될 수 있을까?
나는 내가 두려워하는 봇을 만들 기술이 없다.Fiddle Faddle (talk) 16:06, 2009년 2월 5일 (UTC)

문제 리디렉션

해결됨

내가 브린크러그로 페이지를 옮길 때 자동으로 만들어진 브린크러그는 제대로 방향을 바꾸고 있지 않은 것 같다.이중적인 방향 전환은 없지만, 아무리 생각해도 나는 그것에 어떤 문제가 있는 것을 볼 수 없다.나는 페이지와 브라우저를 성공적으로 제거했다.또 이런 문제가 있는 사람 있어?Tivedshambo (t/c) 07:40, 2009년 2월 5일 (UTC)

정확히 무엇이 잘못되었는가?전 괜찮은 것 같은데요.이것, 저것, 그리고[talk] 나머지 09:38, 2009년 2월 5일 (UTC)
사용자:해피멜론은 링크 전에 공간을 제거하여 "고정"하지만, 내가 알고 있는 한 미리 작동했어야 했다(특히 페이지가 자동으로 생성되었기 때문에).데이터베이스 지연에 대한 문제였을까?Tivedshambo (t/c) 09:55, 2009년 2월 5일 (UTC)

소프트웨어에 문제가 있다: 리디렉션 처리를 위한 새로운 코드(잠재적으로 이중 리디렉션을 기능할 수 있도록 허용하기 위한)가 한 개정판에 도입되었고, 그 안에 있는 버그는 약 30개 개정 후에 수정되었다.1월 28일 위키미디어 위키피디아는 이 두 버전 사이에 미디어위키 버전으로 업데이트되었다. 그래서 그것은 변경사항을 포함했지만 버그픽스는 포함하지 않았다.문제는 정확히 어떻게 (아마도 버그픽스가 '파손된' 버전을 실행 중이기 때문에 생몰입된 상태였을 것이다)는 확신이 없지만, 데이터베이스에는 아직도 꽤 많은 고장난 리디렉션들이 있는데, 이 리디렉션은 손으로 지워질 때까지 남아 있을 것이다.해피멜론 11시 38분, 2009년 2월 5일 (UTC)

파손된 리디렉션은 더미 편집으로 수정할 수 있지만, Null 편집으로는 수정할 수 없으므로 공간이 제거된다.대수학자 13:08, 2009년 2월 5일 (UTC)
멜론: "잠재적으로 이중 리디렉션을 허용한다"?야호, 하지만 "잠재적으로"라는 말은 나를 어리둥절하게 만든다. 그것에 대한 버그 넘버가 있니(찾을 수 없어)? --Amalthea 13:35, 2009년 2월 5일 (UTC)
T13644 - r45973에 추가된 코드는 리디렉션 체인의 최대 길이를 정의 가능한 구성 설정으로 만들어 0(하드 리디렉션을 허용하지 않음, 모든 리디렉션 페이지를 "로 액세스되는 것처럼 처리", 1(기본값, 현재 상황) 또는 1개 이상의 리디렉션 체인을 허용하도록 허용한다(몇 가지 정말 멋진UI가 추가됨).AFAIK는 현재 위키미디어 어디에서도 이것을 가능하게 하기 위해 열려있는 버그는 없다.해피멜론 14:07, 2009년 2월 5일 (UTC)
아, 고마워.여기서 2, 3개로 늘리면 싱글을 위해 만든 기사 중 남은 리다이렉트 관리에 도움이 될 것 같아.그 기능으로, 한 사람이 리디렉션할 수 있다.
철자가 틀린 노래 → 노래 → 앨범 → 아티스트
잘 될 거야현재는 모두 아티스트 기사를 직접 지목해야 할 것이며, 결국 만들어진 각 기사로 모두 리타겟팅해야 한다. --Amalthea 15:21, 2009년 2월 5일 (UTC)
단지 완성도를 위해서, 코드는 r45973년에 도입되었고, 수정은 r46502 (실제로 30!가 아닌 530 개정)에서 시행되었다. 그리고 나서 위키피디아는 r46424로 변경되었다.해피멜론 16:19, 2009년 2월 5일 (UTC)

Dyktalk 템플릿

{{Dyktalk}} 템플릿 변전소가 페이지에 올라온 기사가 꽤 있는데, 5000개가 넘는 긴 목록을 보려면 여기를 참조하십시오.템플릿 사용을 위해 이러한 요소를 수정해야 하는가? -- WOSlinker (talk) 08:16, 2009년 2월 5일 (UTC)

이러한 문제를 해결하는 데 어려움을 겪고 있는 경우 모두 {{ArmitrateHistory}}을(를) 사용하도록 변환하고 이후 모든 FAS, AFD 등을 잡는 것이 좋다 — CharlotteWebb 15:50, 2009년 2월 5일(UTC)

페이지/기사 출처만 요청하시겠습니까?

이것이 가능한가?내 말은, 페이지에 대한 완전한 html 코드를 얻는 대신에, 기사의 출처만 얻는 것이 가능한가?출처만 흥미진진하다면, 이렇게 하면 엄청난 양의 데이터 전송을 줄일 수 있을 것이다.예를 들어, 내가 위키백과 기사에만 초점을 맞춘 웹 크롤러를 만들고 싶다면, 출처를 제외한 모든 것은 꽤 흥미가 없다.이렇게 하면 위키백과 부분의 트래픽도 절약할 수 있다. --Kri (토크) 17:03, 2009년 2월 5일 (UTC)

Edit this page(이 페이지 편집) 버튼은 이러한 목적을 제공한다.Dendodge TalkContribs 17:05, 2009년 2월 5일 (UTC)
wiki-text를 스크래치하고 다른 어떤 것도 사용하지 않으려면 action=raw를 사용하십시오.여러 기사를 얻으려면 API를 사용할 수 있다(예: [14])예를 들어, 수천 개의 기사를 다운로드하려면 데이터베이스 덤프를 다운로드하십시오.CharlotteWebb 17:30, 2009년 2월 5일 (UTC)
고마워! --Kri (대화) 17:33, 2009년 2월 5일 (UTC)
만약 당신이 API를 사용한다면, 당신은 색상이나 자동 링크 URL과 같은 인간 친화적인 포맷을 없애기 위해 실제로 탐색할 때 "&format=xml"을 추가하기를 원할 것이다.위키 텍스트를 <rev> 태그에서 분리한 후 &quot;, &amp;&amp;, &lt;, &gt; 등의 항목을 피해야 한다.CharlotteWebb 17:40, 2009년 2월 5일 (UTC)
참고 항목: mw:더 자세한 내용은 API를 참조하십시오. --Amalthea 17:59, 2009년 2월 5일(UTC)

섹션 제목을 사용하여 리디렉션

그것은 효과가 있다.기사로의 전환만으로 사람들이 혼란스러워할 것이라는 것을 깨달았을 때 나는 그것을 시도해 보기로 결심했다.

이것은 위키피디아에서 정확하다.페이지 섹션으로 리디렉션 #리디렉션

오늘 아침 내가 어디에 있었는지 기억할 수 있다면, 그 밑은 정확하지 않아.Vchim 침팬지 · 대화 · 기여 · 19:08, 2009년 2월 5일 (UTC)

알았어, 찾았어.

도움말: 링크#섹션 링크가 있는 리디렉션Vchim 침팬지 · 대화 · 기여 · 19:21, 2009년 2월 5일(UTC)

기사의 내역은 어떻게 찾는가?

리디렉션 페이지를 읽다가 어제 우연히 마주친 문제를 발견했다.WSGA(동음이의)는 리디렉션에 대한 변경 사항을 처음 편집한다.그러나 그 이전에 역사가 없었다면 그것은 정확히 변화가 아니다.두 번째 편집은 기사의 "뒤로" 변경이었다.역사가 없으니 그 글에 누가 기고했는지 모르겠다

기사가 옮겨지거나 방향을 바꾸거나 뚜렷한 이력이 없는 것을 본 적이 있는데, 정말 어떻게 해야 할지 아는 사람이 무슨 일이 일어났는지 알 수 있었다.Vchim 침팬지 · 대화 · 기여 · 19:12, 2009년 2월 5일 (UTC)

첫 번째 리디렉션은 WSGA(동음이의)WSGA로 이동될 때 WSGA(동음이의)에서 자동으로 생성되었다.07년 11월에 기사로 삭제되었고, 08년 11월에 그 기사가 WSGA(필수)로 옮겨졌다.
WSGA는 사실상 손대지 않은 채 WSGA(동음이의)에서 몇 분 정도 살았을 뿐이다. --Amalthea 19:29, 2009년 2월 5일(UTC)

WSGA(동음이의)에는 이력이 없다.

나는 WSGAWSEG에 합병할 것이며, 누구의 기여가 인정되어야 하는지 알아야 한다.Vchim 침팬지 · 대화 · 기여 · 20:36, 2009년 2월 5일 (UTC)

잠깐, 나는 역사를 위해 WSGA-FM만 보았다.나는 WSGA를 보고 있는 줄 알았는데 지금은 디스패치 페이지지만 그때는 그렇지 않았다.Vchim 침팬지 · 대화 · 기여 · 20:39, 2009년 2월 5일 (UTC)

템플릿:콜베긴

{{Colbegin}}}}이(가) 깨진 것 같고, 지금 작동시킬 수가 없으며, Template을 사용하는 페이지들 중 상당수는 다음과 같다.콜베긴은 더 이상 열에 있지 않다.왜 그런지 아십니까?이킵 (토크) 20:08, 2009년 2월 5일 (UTC)

날 위해 일한다.어떤 브라우저를 사용하십니까? --- RockMFR 20:35, 2009년 2월 5일 (UTC)
인터넷 익스플로러 6.0.작동하고 있는 페이지의 예를 들어 주시겠습니까?
알파벳#에서는 작동하지 않는다.참조_also 또는 Wabiling#예를 들어_도 참조하십시오.Ikip (토크) 22:01, 2009년 2월 5일 (UTC)
IE는 다중 열을 지원하지 않는다.대수학자 22:10, 2009년 2월 5일 (UTC)
IE는 현대 웹 브라우저가 할 수 있는 많은 일들을 하지 않는다.브라우저를 Safari 또는 Firefox로 업그레이드하십시오(가능한 경우, 하지만 IE7이 더 좋음).그런 식으로 웹을 훨씬 더 즐길 수 있을 것이다. :) EVULA/// talk // // 22:17, 2009년 2월 5일 (UTC
이건 분명히 IE 문제야.IETab 플러그인으로 FF3와 IE7을 전환했는데, 그 동작이 IE 아래의 열에 들어가지 않도록 변경된다. (토크) 23:18, 2009년 2월 5일 (UTC)
{{Colbegin}}은(는) 모든 브라우저에서 지원되지 않는 CSS3 열을 사용한다.IE(IE8 포함)는 칼럼 선택기를 지원하지 않는다.오페라도 마찬가지야.따라서, 이 템플릿은 FireFox나 Safari를 사용하는 최대 30%에게 적용된다.브라우저 지원에 대한 세부 정보를 템플릿 문서에 추가했다. --— Gadget850(Ed) - 23:32, 2009년 2월 5일(UTC)

범주가 혼동된 경우

해결됨

사용자가 템플릿을 변환할 때 발생할 수 있는 문제를 추적한 경우:사용자 페이지에 대한 위키백과에 대한 소개카테고리:위키백과 기본 정보(예:사용자:Djreload, 템플릿에는 나를 혼란스럽게 하지만 범인일 수 있는 줄이 있다.

'{{{#ifeq}:{{{{}네임스페이스} {{ns:프로젝트} [[카테고리:위키백과 기본 정보 {{PAGENAME}}]}}</포함 전용''

좋은 의견이라도 있나?LeeVJ (대화) 23:22, 2009년 2월 5일 (UTC)

선은 올바르게 작동하지만 네임스페이스 테스트는 [15]에서 불과 일주일 전에 추가되었다.영향을 받는 페이지는 null 편집으로 카테고리에서 제거할 수 있다.숙청만으로는 부족하다.만약 작업 대기열이 의도한 대로 작동한다면, 결국 페이지는 자동으로 제거되어야 하지만, 그러한 종류의 작업은 최근에 몇 주가 걸렸다.프라임헌터 (토크) 01:17, 2009년 2월 6일 (UTC)
아, 설명이 되네, 정말 고마워!LeeVJ (대화) 01:47, 2009년 2월 6일 (UTC)

제안: 기울임꼴 텍스트를 왼쪽으로 약간 이동

MediaWiki talk:를 참조하십시오.Common.css#Proposal: 이탤릭체 텍스트를 왼쪽으로 약간 이동시킨다.Army1987(대화 • 기여) 20:55, 2009년 1월 25일(UTC)에 의해 추가된 서명되지 않은 논평 준비

{{보호레벨}} 사용 가능, 보호 템플릿 업데이트

마법의 단어 {{PROTECTLVE}}을(를) 이제 사용할 수 있다(T11947, r45587 참조).이제 보호 템플릿을 업데이트하여 다음과 같은 작업을 수행할 수 있다.

  • 페이지가 올바른 보호 수준에 도달하지 않은 경우, 아무 것도 반환하지 않고 잘못된 보호 템플리트로 위키백과 페이지에 분류하십시오.

그런 다음 봇은 이 범주를 순찰하여 잘못된 보호 템플릿을 제거하거나 적절한 보호 템플릿으로 교체할 수 있다.템플릿 및 다음 범주에서 만료 옵션을 사용하지 않는다.범주:만료된 보호된 페이지, 카테고리:위키피디아 만료 없이 보호되는 페이지.세미, 풀, 이동 타입에 대해서는 {{pp-meta}}에서 직접 업데이트한 후 각 템플릿을 개별적으로 업데이트 할 수 있다.이 작업이 완료되면 MediaWiki에서 관리자에게 다음과 같은 사실을 알릴 수 있다.보호 텍스트(필수적으로, expiries를 추가하는 데 필요 없음).세나륨 (Talk) 09:33, 2009년 1월 29일 (UTC)

더욱 유용하게, 모든 페이지에 포함된 시스템 메시지에 코드를 입력하면 원칙적으로 잠금 아이콘을 페이지에 자동으로 추가할 수 있다.이에 대한 지지가 있을까.해피멜론 14:03, 2009년 1월 29일 (UTC)
잘 모르겠는데, 보호 템플릿의 종류가 다르고, 아무것도 반환하지 않는 경우도 있기 때문이다({{pp-move-indef}).보호 로그에 원하는 템플릿 유형을 입력할 수 있는 경우를 제외하십시오.그러나 그것은 2009년 1월 29일 세나륨 (Talk) 14:42, 2009년 1월 29일 (UTC)도 추가될 것인가?
나는 잠금 아이콘과 같은 것으로 표시되지 않는 보호된 페이지를 갖는다는 원칙에 동의하지 않는다. 단지 보호 태그가 일관성 없이 적용되었기 때문에 우리는 이 원칙에서 벗어날 수 있다.이제 자동으로 페이지를 보호됨(잠금 아이콘으로)으로 표시하여 템플리트 중 어떤 것도 아이콘을 추가할 필요가 없도록 할 수 있는 기회를 갖게 되었다.우리는 여전히 템플릿이 필요하다. 왜냐하면 보편적으로 적용되는 메시지에는 세부적인 것이 있을 수 없기 때문이다.그러나 그것은 우리가 왜 페이지가 보호되었는지에 대한 설명자 역할을 하기 위해 템플릿을 추가하기만 하면 된다는 것을 의미하지, 단지 그렇다고 표시하기 위해서가 아니다.그래서 예를 들어, 우리는 더 이상 추가하지 않아도 될 것이다.{{pp-template}}카테고리에 삽입하는 카테고리로서 모든 보호된 템플리트:보호 수준 및 네임스페이스에 기반한 보호 템플릿이 가능하다.우리는 여전히 추가해야 할 필요가 있다.{{pp-semi-sock}}예를 들어, 보호 상태와 네임스페이스에서 해당 정보를 추론할 수 없기 때문이다.그러나 그 템플릿은 더 이상 잠금 아이콘을 추가할 필요가 없을 것이다.해피멜론 16:55, 2009년 1월 29일 (UTC)
보호된 페이지 편집의 경우 예, 그러나 이동 보호되는 페이지 많은 경우 아이콘을 추가할 필요가 없으며, 독자와 미숙한 사용자를 혼동시킨다.(앞서 제안했듯이, 이동 보호된 페이지의 이동 탭을 유지하되 환경설정에서 비활성화할 수 있도록 허용하면 미숙한 사용자가 이동 탭이 때때로 사라지는 이유를 알아내는 데 도움이 될 것이다.아이콘은 반보호 아이콘과 혼동되거나 누락되어 비효율적이다.)그리고 때로는 아이콘뿐만 아니라 큰 알림을 원하기 때문에 템플릿과 이미지 외에는 실현 가능성이 없어 보이기도 한다.관리자는 또한 가능한 경우 특정 템플릿을 사용하도록 권장해야 한다.세나륨 (Talk) 17:36, 2009년 1월 29일 (UTC)
나는 이 토론을 시작할까 생각중이었어.:) 몇 가지 요점은 다음과 같다.
  • 나는 추적기 범주로 통지를 자동 교체하는 아이디어가 마음에 든다: 우리는 봇을 시켜 청소를 하거나 수동으로 할 수도 있고, AWB를 가진 사람이 가끔 쓸 수도 있다.
  • 보호 템플릿을 사용하여 자동 추가를 수정, 제거 또는 교체할 수 없는 한 보호 아이콘의 자동 추가라는 생각이 마음에 들지 않는다.우리의 현재 템플릿 시스템은 대부분의 경우 작은 아이콘 버전에서도 보호의 이유를 합리적으로 명확히 할 수 있게 해준다. 툴팁은 해당되는 경우 만료 날짜를 제공하고 보호에 대한 설명을 제공한다.
  • 나는 무한정 움직이는 보호된 페이지의 문제에 중립을 유지한다: 나는 모든 보호가 눈에 보여야 한다고 생각하지만(보이지 않는 보호는 사람들을 혼란스럽게 한다), 그것이 반보호와 혼동되는 것도 사실이다.나는 우리가 이 논의의 일부로서 이것을 더 탐구할 필요가 있다고 생각한다.
  • 이 새로운 마법의 단어를 사용하여 여러 가지 일반적인 템플릿을 병합할 수 있다. 즉, 유형 자동 선택semi또는full템플릿 패밀리를 단순화하기 위해 쉽게 구현될 수 있다.단순화할 템플릿에 해당 기능을 구현하는지 아니면 {{pp-meta}}에 구현하는지는 논란의 여지가 있다.
  • 이 기능은 이동 보호 및 반보호 페이지에 대한 통지를 추가할 수 있으며, 현재 이동 보호에 대해서는 언급하지 않고 있다.
{{Nihiltres talk log}}} 2009년 1월 29일 18:04(UTC)

그래. 니힐트레스, 그런 생각은 안 해봤는데, 당연히 그래야지.우리는 여전히 템플릿을 사용하고 있고, 여전히 보호의 다른 이유로 다른 템플릿을 가지고 있지만, 우리는 eg를 통일한다.{{pp-vandalism}}그리고{{pp-semi-vandalism}}그리고{{pp-move-vandalism}}템플릿이 페이지에 있는 실제 보호에 기반하여 적합한 것을 해결하도록 하십시오.보호가 만료되면 자동으로 통지가 사라지게 할 수도 있고, 추적 카테고리를 남겨 봇으로 청소할 수도 있다.난 여전히 pp-templates의 일부를 삭제하라고 제안하고 싶지만,{{pp-template}}특히(또는 기본적으로 다음에서 호출할 수 있음){{documentation}}보호 장치가 마련되어 있지 않을 때는 조용히 하도록 하라.) 그러나 나는 이것이 이러한 새로운 기능을 즉시 사용하는 가장 좋은 방법이 될 수 있다고 생각한다.해피멜론 18:55, 2009년 1월 29일 (UTC)

네임스페이스와 보호 유형/수준 확인의 조합을 사용하여 템플릿에 나열된 템플릿:보호 템플릿(WP를 계산하지 않음:OFFICE 템플릿)을 다음과 같이 줄일 수 있을 것이다.
  • pp-flash
  • pp-dlabalism
  • pp-flash
  • pp-flash
  • pp로 보호되는
네임스페이스 체크를 사용하는 것은 템플릿과 사용자 대화(블록 해제 없이 블록을 변경할 수 있는 기능을 가진 템플릿은 현재 대부분 사용되지 않아야 함) 템플릿이 일반 pp-p-p-template 템플릿에 통합되거나, Happ-melon이 제안한 대로 문서 템플릿에 통합될 수 있다는 것을 의미한다.이동/반미/완전한 보호를 위해 별도의 버전이 필요하지 않아야 한다.Mr.Z-man 20:03, 2009년 1월 29일 (UTC)
몇 가지 더 많은 요점, 다른 요점:
  • {{pp-usertalk}}(및 그 반 등가물)을 일반 보호 템플릿에 병합하는 것은 아마도 좋은 생각이 아닐 것이다. 일반 템플릿에 대한 구체적인 근거가 되기 때문이다.우리가 그 네임스페이스의 모든 보호가 그 근거에 해당한다고 주장할 수 없다면, 나는 그것이 통합되어서는 안 된다고 생각한다.반면에 그것을 공식적으로 비난하는 것은 좋은 생각처럼 들린다.
  • {{pp-180}}}}은(는) 자동으로 호출({put-messages})하지만 템플릿뿐만 아니라 고위험 파일에도 사용되기 때문에 어떤 점에서는 혼자 남아야 할 것이다.{{#if:{{PROTECTIONLEVEL:edit}} {{pp-template small=yes}}}}(혹은) 개선이 될 것이다.
  • 보호 템플릿의 부적절한 사용, 즉 일반적으로 허용되는 범위 밖에서 사용할 경우 오류 메시지를 사용하시겠습니까?예를 들어, 반보호된 페이지에는 {{pp-disput}}을(를), 완전보호된 페이지에는 {{pp-indef}}을(를) 사용하지 않아야 한다.
  • 변경사항을 중앙 집중화할 것인지 아니면 개별 템플릿을 병합하는 것이 가장 좋은 방법이라고 생각하십니까?현재 우리는 보호 이유와 보호 유형이라는 두 개의 "축"을 따라 보호 템플릿을 가지고 있다.{{pp-180}}}은(는) 현재 유형 중심의 아키텍처를 가지고 있다.우리가 그 건축물을 좀 더 일반화해야 할까? (나는 약간 반대하지만, 여기 뭔가 재미있는 것이 있을지도 몰라.)
그것 말고도 우리에겐 계획이 있는 것 같아.{{Nihiltrestalk log}}} 23:20, 2009년 1월 29일 (UTC)
편집과 이동 보호의 이유가 종종 다르기 때문에(예: 반보호적인 기물을 반보호적으로 일시적으로 반보호적으로 이동하는 경우) 우리가 보호 템플릿을 병합할 수 있을지는 잘 모르겠다.그리고 예를 들어 공공 기물 파손으로 인해 기사가 반보호되었다가 분쟁으로 인해 완전한 보호를 받게 되면, 잘못된 이유를 제시할 것이다(어쨌든 그것은 갱신되어야 할 것이다).나는 세미와 풀(full)이 합쳐질 수 있는 유일한 경우는 pp-보호, pp-usertalk, pp-template일 것이라고 생각한다.일부 프로젝트 페이지는 무한정 완전하게 보호된다(예: 위키백과:저작권, WP:ITAAW)는 위키백과 네임스페이스에 대해서만 pp-indef를 만들 수 있고, 기사도 삭푸펫으로 인해 완벽하게 보호되어 pp-sock도 만들어질 수 있다.사실 우리는 edit=와 move= 매개 변수(예: edit=vandalism, move=indef)를 가진 하나의 템플릿만 사용할 수 있었지만, 오래된 템플릿은 깨뜨리지 않고는 리디렉션할 수 없었다.보호된 제목의 경우 MediaWiki를 업데이트했다.{{PROTECTL:create}}}의 제목 보호 경고, {{pp-create}}로도 동일한 작업을 수행할 수 있을 것 같다.세나륨 (Talk) 04:17, 2009년 1월 31일 (UTC)
잘못 배치된 보호 템플릿을 제거하는 간단한 방법은{{#ifeq:{{PROTECTIONLEVEL:edit}} sysop <template code here> [[Category:Wikipedia pages with incorrect protection templates {{PAGENAME}}]]}}전체 보호 템플릿의 경우,{{#ifeq:{{PROTECTIONLEVEL:edit}} autoconfirmed <template code here> [[Category:Wikipedia pages with incorrect protection templates {{PAGENAME}}]]}}반보호 템플릿의 경우{{#ifeq:{{PROTECTIONLEVEL:move}} sysop <template code here> [[Category:Wikipedia pages with incorrect protection templates {{PAGENAME}}]]}}이동 보호 템플릿용.지금 이 일을 해야 하는가?우리는 이것을 가지고 그 문제를 계속 논의할 수 있다.지금 생각해 보면 마법의 단어 {{PROTECTEXPIRY}}이(가) 꽤 유용할 텐데...세나륨 (Talk) 19:20, 2009년 1월 31일 (UTC)
템플릿을 카테고리(Category)로 업데이트하는 데 이의가 있는가?위의 설명에 설명된 대로 잘못된 보호 템플릿이 있는 위키백과 페이지?다른 변화에 대한 논의는 여전히 계속될 수 있다.세나륨 (Talk) 18:59, 2009년 2월 2일 (UTC)
어서 가봐.해당될 경우 편집 보호 템플릿을 병합하는 작업을 하고 있으며, {{pp-semi-protected}}을(를) {{pp-protected}}에 이미 라이브 테스트로 병합했다.일단 우리가 그들 모두를 합병하고 Die-on-No-protection 비트와 함께 한다면, 나는 모든 보호 템플릿 코드를 검토해서 그것을 최적화할 계획이다.지금 가야 해, 나중에 돌아와.{{Nihiltrestalk log}} 16:29, 2009년 2월 3일(UTC)
하나의 템플릿으로 병합될 수 있는 pp-템플릿과 pp-usertalk(및 사무실)를 제외하고 수행되며, 그 두 가지 또한 편견 없는 이동을 포함할 수 있다고 생각한다(ppp-protected와 대조됨).나는 또한 pp-protected를 수정하여 비보호 페이지의 전용을 처리했다.그러나, 그것이 수행된 방법은 직접 볼 때 템플릿을 숨기는 결과를 가져온다.이제 필요하지 않은 카테고리도 제거했다.만료된 위키백과 보호 페이지(아직 비어 있지 않음)가 만료되었지만 카테고리:위키피디아는 만료되지 않고 페이지를 보호하는데, 나는 그 용도를 알지 못한다.세나륨 (Talk) 18:53, 2009년 2월 3일 (UTC)
나는 우리가 pp-vandalism과 pp-semi-vandalism을 병합해야 한다고 확신하지 않는다.만약 기사가 공공 기물 파손에 대해 반보호를 받고, 예를 들어 분쟁으로 인해 보호를 받는다면, 그것은 정확한 이유를 표시하지 않을 것이다.보호할 때 보호 태그를 업데이트하지 않는 관리자가 있다.pp-p-protected의 경우에도 pp-p-p-semi-protected를 갖는 것이 템플릿의 의미에 대해 더 모호하지 않은 반면, 나는 장점을 볼 수 없다.특히 네임스페이스로 필터링된 템플릿의 사용을 확인하기 위해 what linkshere를 사용할 수도 있다.세나륨 (Talk) 15:13, 2009년 2월 4일 (UTC)
왓링크스여기서 문제들은 내가 연구하고 싶은 범주 분류로 해결할 수 있다. 범주 시스템을 바로 잡는 것이 내가 최근의 개선사항을 통합하고 모든 보편적으로 적용되는 범주를 포함한 특정 요소를 세계화하기 위해 {{pp-meta}을(를) 정비하기 전에 특히 좋을 것이다.보호 템플릿을 업데이트하지 않은 관리자에 대해 나는 이 문제를 어느 쪽이든 문제로 본다. 반보호 페이지가 분쟁으로 인해 반보호되어 있고 관리자가 페이지에 태그를 지정하지 않은 경우, 유형 자동 선택이 없는 경우, 사람들은 기사가 반보호되어 있음을 보거나 템플릿이 자동으로 사라지는 경우 알림을 받지 못한다.유형 자동 선택이 있다면, 사람들은 그 기사가 완전히 보호되고 있다고 보지만, 잘못된 이유를 얻는다.나는 후자의 상황이 아마도 더 바람직하다고 생각한다. 첫째, 템플릿의 효용이 완전히 파괴되는 반면(이유는 표시되지 않고/또는 부정확하며, 수준은 표시되지 않음), 둘째, 일부 효용은 남아 있다(이유는 부정확하고, 표시된 수준은 표시됨).{{Nihiltrestalk log}} 16:39, 2009년 2월 4일 (UTC)
나는 뚜렷한 이익이 없을 때 이런 종류의 기능들을 합병하는 것에 대해 신중하다.나는 다양한 프로젝트/대화/사용자/를 만들었다.하위 카테고리를 더 유용하게 만들기 위해 하위 카테고리(작업 대기열이 길고 위키백과 접두사를 사용하기 위해 이름을 바꾸는 것을 방해했음에도 불구하고, 정말로 분리할 수 없는 난장판이었다), 그러나 여기서 링크하는 것은 여전히 보호 템플리트(및 더 엄격한 네임스페이스 필터)가 포함된 모든 페이지의 목록과 기술 이름을 제공한다.mplate는 더 사용하기 편리하고 실용적이다.페이지에 잘못 적용된 보호 템플릿이 있는 경우, 해당 페이지에 카테고리:잘못된 보호 템플릿이 있는 위키백과 페이지도 수정하고 올바른 템플릿을 제공할 수 있다.하지만 페이지에 잘못된 이유가 있는 템플릿이 표시되면 우리는 그것을 확인할 수 없을 것이다.다용도 템플릿은 보호 상태가 자주 변경되는 페이지에 유용할 수 있지만, 이 템플릿이 없는 경우(그리고 특정 템플릿을 사용할 수도 있음)완전보호 사례가 드물고, 반보호도 만연해 이용자 오해를 유발할 수 있다.편집 창에 표시된 보호 수준이 적절한 경우(wysiwyg).합병의 진정한 이점은 무엇인가?세나륨 (대화) 00:35, 2009년 2월 7일 (UTC)

모든 페이지에 적용

이것이 어떤 미디어위키 페이지에 적용될지 확실하지 않다면, 나는 다음과 같은 것을 넣어야 한다고 생각한다.

{{#switch:{PROTEVEL:edit}} 오토콘확증={pp-semi 보호 소=yes}}} 꽉 찬={pp 보호 소=yes}}}}}}}}

편집 가능한 웹 사이트의 모든 페이지에 적용되는 Mediawiki 통지이렇게 하면 아이콘 템플릿이 필요하지 않고 더 큰 템플릿만 있으면 된다.{{pp-protected}}그리고{{pp-semi-protected}} 필요하면 대화 페이지에.이것은 또한 그러한 템플릿의 배치와 관련된 오류를 없애고 템플릿이 실제로 페이지에 있지 않기 때문에 (템플릿인 경우) 템플릿이 배치되는 페이지를 실수로 방해하는 것을 방지할 수 있다.Foxy LoxyPounce! 04:31, 2009년 1월 31일 (UTC)

나는 그것이 그 페이지를 어떤 카테고리에 포함하지 않을 것이라고 거의 확신한다.우리는 이미 동일한/그림자 커먼즈 이미지와 동일한 문제를 가지고 있다. -- 루카스bfrtalk 16:20, 2009년 2월 3일 (UTC)
FWIW, 그건 좋지 않은 생각이고 아마도 되돌릴 것이다.페이지 보기마다 자주 사용되는 고사용 메시지에 파서 함수를 넣으면 전체 파서 시간이 상당히 많이 추가된다.nstab-main이 메인 페이지 해킹에 파서 기능이 없는 것도 이런 이유 때문이다.^데몬[omg plz] 15:22, 2009년 2월 5일 (UTC)

검색어 인기 비교 도구

검색창에 특정 검색어가 사용된 횟수를 알 수 있는 도구가 있는가?고마워요.SharkD (대화) 03:12, 2009년 2월 3일 (UTC)

http://wikistics.falsikon.de/latest/wikipedia/en/searchTerms.htm을 참조하십시오(위쪽의 메모를 읽어 보십시오). - 안녕하십니까, 멜랑콜리(대화) 09:38, 2009년 2월 3일(UTC)
Ack! 내가 필요한 것은 프로젝트 전체에서 상위 1000여 개 정도가 아니라 검색어를 지정할 수 있는 것이다.또한, 2009년 11월 19일의 기간은 의미 있는 결과를 제공하기에 아마도 불충분할 것이다.SharkD (토크) 07:15, 2009년 2월 6일 (UTC)

{{reflist}}을(를) 깨끗하게 확장할 수 있는가?

위키 마크업 기사에서 편리한 참조 리스트를 만들 수 있기를 바란다.일부 템플리트에서는 "하위"를 적용할 수 있지만, 이 템플리트에 대해 "못된" 마크를 생성한다(css, 모든 컬럼 코드와 함께 여전히 사용).충족하고자 하는 요구사항은 다음과 같다.

  • reflist는 wiki markup을 사용하여 깨끗한 wiki markup을 생성하지 않아야 한다.
  • 포맷을 위해, 내가 정말 필요한 것은 위키 마크업에서 링크와 굵은/이탈릭이 있는 기사의 한 칸짜리 글머리표 목록이다.
  • 나는 그 페이지에 저장하지 않고 기존 기사에서 참조 목록을 얻을 수 있어야 한다.

조언을 해줄 수 있는 사람?Spidern 19:29, 2009년 2월 4일 (UTC)

예: 대체되지 않아야 하는 템플릿을 대체하지 마십시오.그것 말고는, 나는 당신이 무엇을 하려고 하는지 완전히 이해하지 못한다: 당신은 본질적으로 임의의 기사에서 '참고' 섹션과 같은 방식으로 렌더링할 위키미크업 블록을 만들려고 하는가?참조 목록의 정적 사본?해피멜론 20:36, 2009년 2월 4일 (UTC)
응, 해피멜론, 나는 위키 마크업에서 참조 리스트의 정적 사본을 얻으려고 하고 있어, 내가 토크 페이지에서 특정 상황의 ref 분석을 통해 ref를 할 수 있도록 말이야.나는 가장 쉬운 방법이 수작업으로 ref를 샅샅이 뒤져 잡는 것이라는 것을 알지만, 나는 단지 그것을 하는 데 덜 관여된 방법이 있기를 바라고 있었다.스파인02:51, 2009년 2월 5일 (UTC)
나는 그가 참조 리스트의 출처 HTML을 복사하기를 원한다고 생각한다.위키백과에서 내 대답을 참조하십시오.헬프 데스크. --—— Gadget850(Ed) - 21:08, 2009년 2월 4일(UTC)
궁극적인 목적이 물건을 다른 MW 동력 위키에 복사하는 것이라면, 참조를 켜고 reflist 템플릿(옵션)을 복사하는 것은 어떨까?마지막 경기를 아는 것은 많은 도움이 될 것이다.Fiddle Faddle (talk) 21:28, 2009년 2월 4일 (UTC)
이 글을 다시 읽으니 또 다른 각도가 보인다.페이지에서 참조를 수집하여 데이터베이스에 유지하는 것이 목적이라면, 참조 관리 소프트웨어가 꼭 필요하다.나는 FireFox에 조테로를 사용한다. ---- Gadget850 (Ed) - 23:04, 2009년 2월 4일 (UTC)
추천은 고맙지만, 내가 위에서 설명한 것과는 너무 멀리뛰는군(나는 이미 정기간행물 관리에 조테로를 사용하고 있다.나는 ref를 관리할 필요도 없고, 다른 wiki로 수출하고 싶지도 않다.나는 단지 대화 페이지에서 개별적으로 기사의 참고문헌에 대한 해설을 할 수 있기를 원한다.스파인02:51, 2009년 2월 5일 (UTC)
아마도 당신은 별도의 편집 상자에 참조를 넣는 마누스 맨스케의 자바스크립트 인터페이스 변경을 사용할 수 있을 것이다. -- 존 브레튼 (리스크립트) 20:32, 2009년 2월 6일 (UTC)

픽셀화된 영상

글의 상단에 있는 항공기와 조이스틱의 이미지는 항공기 가장자리 둘레에 약간 "재깅"(즉, 픽셀화)되어 있다.고칠 줄 아는 사람?고마워요.SharkD (토크) 07:16, 2009년 2월 6일 (UTC)

나는 Irfanview나 Photoshop을 사용하여 위키피디아에 그 이미지가 나타나기를 원하는 해상도로 정확하게 크기가 매겨진 .jpg나 .png 버전을 만들고, .svg 대신에 그 이미지를 사용할 것이다.온도실 (토크) 00:07, 2009년 2월 7일 (UTC)

카테고리에서 리디렉션 색상 지정

해결됨

(관련검색).범주에서 다른 색으로 리디렉션을 표시하도록 시도(실패)하고 있음*:

.redirect-in-category, .allpagesredirect {

   font-style: italic;    color:#308050;    } 

*: 메타에서 본 적이 있다.MediaWiki:Common.css, 그곳에서도 작동하지 않는 것 같지만.

이것을 바로 잡는 데 도움을 주었으면 좋겠다.

안부 전해요

G.A.Stalk 08:55, 2009년 2월 6일 (UTC)

A을
스판하다.리디렉션 인 a {    글꼴 스타일의: 이탤릭체의;    색을 칠하다:#308050 !중요하다; } 
범주 리디렉션에 사용할 수 있음.스팬 태그의 태그는 링크를 파란색으로 염색하고 있으며, 더 구체적으로 표현하지 않는 한 우선 순위를 차지하고 있다. --Amalthea 09:58, 2009년 2월 6일 (UTC)

Tournesol.png고마워!
G.A.Stalk 10:07, 2009년 2월 6일 (UTC)

언제든지. --Amalthea 10:15, 2009년 2월 6일 (UTC)

이미지 수정본 누락

어디선가 누락된 이미지에 대한 버그질라 보고서가 있다는 것을 알고 있는데, 이 문제가 동일한지 궁금할 뿐이다. 파일:혼다 C70.JPG, 누군가가 3008×2,000개의 공공 도메인 사진을 업로드하고 나서 누군가가 많이 축소했는데(아마도 이미지 구문 사용법을 몰랐기 때문에), 원본 이미지가 사라진 것 같은데, 원본 수정본을 클릭하면 "Firbidden" 메시지가 뜬다.원본이 영구히 분실된 것인가, 아니면 웹서버로부터 읽기 권한을 놓친 것인가? --Sherol (토크) 10:21, 2009년 2월 6일 (UTC)

Archive.org이나 구글에서 찾을 수 없는 원본이 없으면 영원히 잃어버린 것 같아. :(Bidgee (토크) 10:35, 2009년 2월 6일 (UTC)
원래 업로더인 사용자:Go81은 더 이상 활성화되지 않고 이메일을 활성화했다.그들에게 연락해서 그들이 그것을 다시 업로드할 의향이 있는지 물어 볼 수 있다. — Tivedshambo (t/c) 10:46, 2009년 2월 6일 (UTC)
재조명기는 더 짧은 시간 전에 활성화되었으며(그러나 전자 메일이 활성화되지 않음) 원본의 오프라인 복사본을 보관했을 수 있다.프라임헌터 (대화) 2009년 2월 6일 (UTC) 12:29
나는 그것을 평가한 사람의 토크 페이지에 글을 올렸다.플러그워시 (토크) 13:18, 2009년 2월 6일 (UTC)

리디렉션이 작동하지 않는가?

해결됨

리디렉션된 이 페이지는 실제로 리디렉션되지 않으며 대상 페이지에 대한 링크만 제공함으로써 부드러운 리디렉션 역할을 한다.도호쿠 다이가쿠 카레이 카레이 이가쿠 겐큐조 가와시마 류타 료타 쿄주 간슈 쵸토 노오 기타루 오토나 DSi 트레이닝

왜 안 되지?이산화질소 사용 때문일까.게리 (대화) 2009년 2월 6일 18시 13분 (UTC)

SmackBot의 빈칸 편집

smackBot이 빈 줄을 없애는 유일한 목적으로 편집 작업을 하는 것이 그렇게 좋은 생각인가?이력은 실제 편집으로 충분히 무겁다. 62.147.36.76 (토크) 18:31, 2009년 2월 6일 (UTC)

정말 좋은 생각이야, 내가 불필요한 빈 줄을 제거해야 하는 것을 멈추는 것은 무엇이든 좋은 거야.ukexpat (대화) 19:05, 2009년 2월 6일 (UTC)
편집 기록에서 "bot minor whitespace"를 위한 "bmw" 깃발을 얻을 수 있을까?사용자는 해당 플래그로 편집한 내용을 숨기거나 즐거운 시간을 보내기 위해 편집한 내용을 숨길 수 있는 옵션이 있어야 한다. davidwr/(대화)/(논문)/(이메일) 20:00, 2009년 2월 6일(UTC)
나는 그것이 그렇게 "핫 아이디어"인지 잘 모르겠다.특별히 기발한 이유 없이 편집이 많으면 자원의 유출이 발생한다.고장난 리디렉션을 수리하지 말라는 그들의 조언과 함께 한다.청발 변호사 21:05, 2009년 2월 6일 (UTC)
고장리디렉션은 수리해야 한다.리디렉션 링크? --NE2 22:17, 2009년 2월 6일(UTC)
그랬어. — 블루헤어 변호사 22:52, 2009년 2월 6일 (UTC)

렌더링 문제

섹션의 본문 텍스트의 첫 번째 줄은 그림 경계선과 "[편집]" 텍스트가 겹친다.

Firefox 3.0.6과의 프랑스-베트남 관계에서 가져온 오른쪽 스크린샷을 참조하십시오.단면 내 본문의 첫 번째 줄은 맨 왼쪽 사진을 중심으로 원픽셀, 회색 선 테두리를 겹쳐서 그린다.또한 '[편집]'이라는 글자가 오른쪽으로 겹쳐져 있다.이전 섹션에서 흘러내리는 사진의 결함인가?이거 고칠 수 있어?온도실 (토크) 00:03, 2009년 2월 7일 (UTC)

이것은 알려진 문제인데 (2005년 3월부터!) 개발자들은 신경 쓰지 않는 것 같다. - 에릭 바아스 (토크) 01:39, 2009년 2월 7일 (UTC)
버그는 편집 링크가 제자리에 있지 않은 것에 대한 것이라는 점에 유의하십시오. 주석 #16은 무슨 일이 일어나고 있는지에 대한 좋은 설명입니다.추가 논의를 읽어보면, 아례 그레고르는 버그를 고치기 위해 꽤 의지가 있었던 것 같지만, 광범위한 공감대가 없이는 누구도 다른 것을 깨뜨리거나 페이지 레이아웃을 바꾸지 않는 수정안을 생각해 낼 수 없었다.
텍스트가 겹치는 부분은 사실 파이어폭스 버그다.Anomie 04:16, 2009년 2월 7일 (UTC)
이미지 위에 마우스를 올려 놓으면 수정되고, {{fixbunching}} 템플릿이 링크 편집 작업을 수정한다.Dendodge TalkContribs 19:46, 2009년 2월 7일 (UTC)
너무 많은 부유물들이 서로 근접하게 떠다니며(MediaWiki가 아닌 CSS 문제), 사파리 3/Mac에서는 더 나빠 보인다. EVULA/// 토크 // 22:30, 2009년 2월 7일(UTC)
한 가지 메모: 불필요한 이미지를 자르는 것은 문제를 해결하는 데 큰 도움이 된다.EVULA // talk // talk // 22:32, 2009년 2월 7일(UTC)

나는 기꺼이 순찰을 돌았다고 표시한다.

나는 새로운 페이지를 순찰하지만 RSS 피드를 사용하여 "이 페이지를 순찰으로 표시" 링크가 보이지 않도록 한다.며칠 전에 나는 그 링크를 보기 시작했다. 아마도 시험중인 것 같다.

만약 이 링크가 특별한 새로운 페이지를 사용하지 않는 사람들에게 제공된다면 나는 기꺼이 이 링크를 사용할 것이다.RHaworth (Talk 기여) 19:42, 2009년 2월 7일 (UTC)

짧은 기간 동안 Special:에서 도착하는 시간뿐만 아니라 모든 상황에서 페이지를 순찰하는 것이 가능했다. 페이지.구현에 몇 가지 문제가 발생하여 기능이 다시 비활성화되었다.대수학자 22:04, 2009년 2월 7일 (UTC)

글머리 기호, 숫자 및 탭을 모두 같은 양으로 들여쓰기

VPR에서 이동됨

나는 총알, 숫자, 탭이 같은 양만큼 들여쓰이지 않는다는 것을 알아챘다.단정함을 위해서 나는 그들이 해야 한다고 생각한다.

  • 총알을 발사하다
  1. 번호를 붙이다

만약 이것에 대한 의견이 일치한다면 나는 그것이 시행하는 것이 꽤 간단할 것이라고 확신한다.IMO는 모두 탭(:)과 동일한 금액을 들여 보내야 한다.--Pattont/c 13:24, 2009년 2월 7일(UTC)

동의하지만, 전통적으로 들여쓰기는 일반적으로 1em이다(이 단락과 같다).-우드스톤 (토크) 15:03, 2009년 2월 7일 (UTC)
나는 "t", "b" 그리고 "n"의 왼쪽이 일렬로 서 있다. --Carnildo (토크) 21:52, 2009년 2월 7일 (UTC)
그들은 나를 위해 그렇게 하지 않아...나에게 있어 "불렛"은 왼쪽에서 가장 멀리 떨어져 있는 것이다."숫자"의 "n"은 "bullet"의 "e" 바로 밑에 있고, "tab"의 "t"는 "u"를 넘는다.Equazcion •1999/C 21:56, 2009년 2월 7일(UTC)
(ec)정말?그것들은 우리 대부분에게 끔찍하게 보인다.어떤 브라우저를 사용하십니까?해피멜론 21:57, 2009년 2월 7일 (UTC)
구글 크롬과 파이어폭스(NOT release 3)는 끔찍해 보인다.IE에는 관심이 없다.Fiddle Faddle (토크) 2009년 2월 7일 (UTC)
FF 3.0.6과 IE6은 상태가 좋지 않다.Equazcion •1999/C 2009년 2월 7일(UTC)

이것은 이전에 논의된 적이 있다; 일반적으로 그것이 좋은 아이디어라고 결론 내렸지만, 그 해결 시도는 어떤 상황에서 깨졌기 때문에 되돌렸다. 그리고 아무도 그 문제를 제대로 해결할 관심을 가지고 있지 않았다.

상황이 이렇다.<dd>"definition list"(presignal up is colon)를 생산하는 에 명시적인 2em 왼쪽 여백이 주어진다; 우리는 dd 태그를 '둥지'하여 2em의 배수를 추가함으로써 친숙한 코멘트 들여쓰기 시스템을 달성한다."순서 목록"과 "순서되지 않은 목록"(각각 번호와 글머리 기호, # 및 * 문자)은 명시적인 스타일링이 없으므로 브라우저 디폴트를 사용한다.그래서 그들은 잘못 정렬되었다.

  • 바즈
  1. 취옥

그 제안은 명시적으로 다음 사항을 정하는 것이었다.<ul>그리고<ol>태그도 2em 왼쪽 여백으로 표시되므로 다른 태그와 함께 정렬할 수 있다.

  • 바즈
  1. 취옥

그러나, 주문된 목록에는 문제가 있다.

  • 바즈
  1. 취옥

나의 의도는 그것을 주는 것이다.<ul>(iii)와 동일한 2em 고정 들여쓰기<dd>(iii), 그리고 주문된 리스트에 4개의 em indentation을 부여한다.그런 다음 총알이나 단일 인자로 줄을 서지는 않겠지만 최소한 이중으로 들여쓴 선으로 줄을 서야 했다.

  • 바즈
  1. 취옥
    • 바즈

생각?해피멜론 22:32, 2009년 2월 7일 (UTC)

통제된 기간 동안 시도해보고 의견을 구해보지 않겠는가?만약 그것이 css라면 그것은 쉽게 Fiddle Faddle (talk) 23:02, 2009년 2월 7일 (UTC)
첫 번째 수정의 문제는 목록이 4자리 숫자에 도달하는 드문 경우에만 발생하므로, 해당 인스턴스에 대해 예외를 프로그래밍하여 마진을 줄일 수 있지 않을까?그러면 그들은 소화가 덜 된 품목들과 완벽하게 일치하지는 않겠지만, 대부분의 경우 잘 맞춰진다는 것은 절충할 가치가 있지 않은가?Equazcion •1999/C 2009년 2월 7일 (UTC)
CSS를 어떻게 하겠어?대수학자 00:08, 2009년 2월 8일 (UTC)
나는 모르겠다:) 나의 제안은 부분적으로는, 이것이 실현 가능할 것인가 하는 질문이었다.만약 그렇다면 그것이 최선의 선택인 것 같다.Equazcion1999/C 00:13, 2009년 2월 8일 (UTC)
AFAIK는 CSS로 이 작업을 수행할 수 없다. 단, 특정 번호로 항목을 나열하기 위해 (일부 브라우저의 경우 전부가 아닌) 스타일을 적용할 수 있는 반면, 이것은 3자리 숫자 이하의 경우 999개의 개별 스타일 규칙을 필요로 한다.또한 아이폰과 PDA와 같은 매우 작은 화면에서는 두 자리 숫자로도 문제가 지적되었다.해피멜론 00:36, 2009년 2월 8일 (UTC)
나는 숫자에 대해서는 4em, 그 밖의 모든 것에 대해서는 2em에 동의한다. 훨씬 좋아 보인다.--- Pattont/c 23:14, 2009년 2월 7일 (UTC)
나는 총알에 대해 2개의 의견에 동의한다; 적어도 결장(<dd>) 항목과의 불일치는 고쳐야 한다.번호 목록은 가변 폭이고, 나머지 두 종류와 거의 섞이지 않기 때문에 번호 목록은 당분간 그대로 둘 수 있을 것 같다. Edokter Talk • 23:32, 2009년 2월 7일 (UTC)
너의 마지막 예시에 있는 것들이 어떻게 줄 서야 하는 거니?나로서는 첫 번째 '바즈'의 '바'와 'B'가 나란히 서고, 첫 번째 '바즈'의 '1000'과 두 번째 '푸'가 나란히 서고, 두 번째 '바즈'의 'k'가 나란히 서 있다.전체적인 인상은 성스럽지 못한 엉망진창이다. --카닐도 (토크) 00:04, 2009년 2월 8일 (UTC)

브라우저에서 외부 사이트로 스크린샷을 게시하여 링크하는 것은 어떠세요?나에게 줄 서 있는 것은 거의 없다. ubuntu/ff 212.240.232 (토크) 00:09, 2009년 2월 8일 (UTC)

FF3/비스타

아니면 그냥 여기에 올리면 FF3/Vista에 대한 내 경험은 오른쪽에 있어.무슨 브라우저를 사용하는 거야, 카닐도?해피멜론 00:36, 2009년 2월 8일 (UTC)

Linux에서 Opera를 사용하는 경우: 파일:Indent-example-opera-linux.png. --Carnildo(대화) 02:00, 2009년 2월 8일(UTC)
와우. 아마 브라우저에 문제가 있는 것 같아.누군가가 대신 버그를 모질라에게 제출하고, 그들의 끝에 이것을 고치면 된다:) Equazcion •auth/C 02:03, 2009년 2월 8일 (UTC)
마지막 예에서 작은 실수를 고쳤는데, 첫 번째 "바"가 잘못 배정된 경우였습니다. Edokter Talk • 02:15, 2009년 2월 8일 (UTC)

트윙클과 허글 문제

트윙클과 허글은 때때로 새로운 경고를 할 때 경고 템플릿을 덮어쓴다.[16][17][18][19] 트윙클/벅스 사람들이 이렇게 제안했다.이것은 알려진 문제인가? 내가 알아야 할 해결책이나 게시판이 있는가?PS: 구글 크롬을 사용하고 있는데...경고가 <1분>이면 확인 질문을 받을 수 있는 파이어폭스와의 (내가 알고 있는) 이런 일은 결코 일어나지 않았다.NJGW (대화) 22:08, 2009년 1월 21일 (UTC)

좋은 생각 있어?NJGW (대화) 06:42, 2009년 1월 23일 (UTC)
누가 제안을 할 것인가에 대한 제안은 어떨까?NJGW (대화) 01:07, 2009년 1월 26일 (UTC)
제안이 있는 게시판의 제안?NJGW (토크) 07:26, 2009년 1월 28일 (UTC)
이거 또 본 사람 있어?NJGW (대화) 2009년 1월 29일 19:26 (UTC)
다른 사람 이 실 보는 사람 있어?이런 일이 일어나는지 아직도 모르겠어?누가 알 수 있는 단서라도?NJGW (대화) 17:11, 2009년 2월 2일 (UTC)
트윙클을 운영하는 남자와 허글을 운영하는 남자는 어때?Fiddle Faddle (talk) 19:39, 2009년 2월 4일 (UTC)
후자는 존재하지 않는다 -- 구르흐 (토크) 19:41, 2009년 2월 4일 (UTC)
내가 위에서 지적했듯이, 트윙클/벅스의 사람들은 그것이 위키미디어 서버의 캐싱 문제일 수도 있다고 주장한다.[20] 이런 경우라면 그 다음은?너희들이 그렇게 생각하지 않는다면, 나는 무엇으로 그들에게 돌아갈까?NJGW (대화) 06:49, 2009년 2월 5일 (UTC)
아직도 그 다음 단계나 문제를 피하는 방법에 대한 단서를 찾고 있다.NJGW (대화) 03:41, 2009년 2월 9일 (UTC)

제안:숨겨진 "All Wikipedia Metateplate" 범주 만들기

설명 페이지에 연결되는 템플릿을 식별하는 도구를 작성 중이며 메타템플릿을 제외하고자 한다.처음에 나는 카테고리라고 생각했다.위키피디아 메타테마플레이트가 나의 해결책이었지만, 그 후 모든 하위 카테고리를 보았다.범주 행을 따라:모든 설명 페이지범주:무료가 아닌 모든 미디어, 카테고리 내의 내용을 포함하는 숨겨진 "모든 위키백과 메타플레이트" 카테고리를 보고 싶다.위키피디아는 메타템플릿과 그 하위캣을 포함한다.그걸 어떻게 설정해? --JaGatalk 17:47, 2009년 2월 6일 (UTC)

이러한 변경에 대한 합의가 있다면 AutoWikiBrowser에서는 쉽게 만들 수 있지만, 도구가 하위 캐트를 인식하도록 할 수 있을 만큼 충분히 쉬워야 한다.DendodgeTalkContribs 18:21, 2009년 2월 6일 (UTC)
그래, 내 도구는 확실히 할 수 있어. 하지만 불필요하게 복잡해 보여.이는 처리 시간을 단축하는 것은 말할 것도 없고 봇과 도구 작성자를 도처에 도울 수 있다. --JaGatalk 18:30, 2009년 2월 6일 (UTC)

더 좋은 질문은, 범주의 모든 멤버와 하위 캐럿을 숨겨진 "All blah blah" 범주에 추가하고 싶다면, 가장 좋은 방법은 무엇인가? --Jagatalk 19:54, 2009년 2월 6일 (UTC)

오토위키브라우저(AutoWikiBrowser)를 추천하고 싶다.DendodgeTalkContribs 19:47, 2009년 2월 7일 (UTC)
네가 직접 하고 싶다면.대부분의 코더들이 봇을 함께 던지는 것은, 당신이 그 루트를 가고 싶다면, 요청한다면 그렇게 어렵지 않을 것이라고 생각한다. --Izno (토크) 00:22, 2009년 2월 9일 (UTC)