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

로그인하지 않은 것처럼

가끔 위키백과(영어 버전, 나는 다른 버전을 한동안 시도하지 않았다)를 로딩할 때 로그인하지 않은 것처럼 보인다.측면의 오른쪽 상단 모서리에 "로그인" 링크가 나타나고, 그 옆에 "베타" 링크가 나타난다.그러나 "Try 베타" 링크를 클릭하면 로그인할 때 표시되는 모든 링크가 나타난다.보아하니, 나는 결국 로그인했어.

나는 이 벌레가 벌써 몇 달째 눈에 띄었다.나는 윈도우 7을 실행하고 있다.그리고 항상 최신 버전으로 업데이트한 FireFox를 사용하고 있다. --Kri (토크) 12:56, 2010년 1월 15일 (UTC)

이상했어.몇 가지 테스트를 해봅시다.

1: 브라우저 캐시를 건너뛰면 어떻게 되는가? (아마 브라우저가 일부 손상된 항목을 캐싱하고 있을 것이다.)

2: 브라우저의 모든 쿠키도 지우십시오.이전 버전의 Firefox를 사용하고 있지만 쿠키를 지우려면 브라우저에서 "도구" 메뉴를 클릭한 다음 "옵션 - 개인 정보 - 쿠키 표시 - 모든 쿠키 제거"를 클릭하십시오.그런 다음 위키백과 세션 쿠키를 삭제했으므로 다시 로그인하십시오.

3: 위의 두 가지가 도움이 되지 않으면 보안 서버를 사용하여 로그인하십시오.로그인 페이지로 이동한 다음 로그인 상자 아래의 텍스트에서 "보안 서버"를 클릭한 다음 평소와 같이 로그인하십시오.

보안 서버에 로그인했을 때 정상 서버에 로그인했을 때 문제가 없다면 페이지 로드를 방해하는 캐싱 프록시 뒤에 있는 것이 아닌가 싶다.그런 다음 브라우저에서 "도구 메뉴 - 옵션 - 고급 - 네트워크 - 연결 설정"을 확인하십시오.

--David Göthberg (대화) 13:20, 2010년 1월 15일 (UTC)

나는 결코 로그아웃하지 않고, 위키피디아를 꽤 자주 방문하기 때문에, 나는 그것이 문제가 아니라고 생각한다.하지만 다음에 같은 벌레가 나오면 먹어볼 수 있어. --Kri (토크) 17:14, 2010년 1월 16일 (UTC)

보안 서버는 별도의 로그인을 사용한다.일반 서버에 로그인한 경우에도 보안 서버로 이동하면 로그인이 되지 않지만 로그인해야 한다.

그리고 이 경우에 "프록시"는 같은 인터넷 서비스 공급자의 다른 사용자들과 공유되는 프록시 서버를 통해 서핑하고 있을 수 있다는 것을 의미한다. (만약 당신이 학교나 직장에서 컴퓨터를 사용하고 있다면, 프록시는 훨씬 더 흔하다.)그런 다음, 맨 위에 개인 메뉴가 있는 페이지 버전 대신 다른 사용자가 로드한 페이지 버전을 보고 프록시에 캐시할 수 있다.그것은 당신이 묘사하고 있는 정확한 것을 야기할 수 있다.만약 그것이 문제라면, 당신은 인터넷 서비스 제공자의 다른 사용자들에 의해 최근에 방문되었을 수도 있기 때문에, 인기 있는 페이지에서 그것을 볼 수 있어야 한다.보안 서버를 사용하면 일반적으로 프록시의 캐싱이 바이패스되거나, 프록시가 함께 바이패스되기도 한다.그러므로 보안 서버를 시도하는 것은 그것이 문제가 될 수 있는지 진단하는 빠른 방법이다.그러나 더 빨리 브라우저 설정을 확인하는 것은 프록시 서버를 통해 연결되도록 설정될 수 있다.

또 다른 방법은 이동 중에 데이터를 손상시키는 버기 무선 연결을 사용하고 있다는 것이다.그런 다음 매번 페이지 로드 실패(페이지 없음 또는 손상된 페이지)를 얻으십시오.이러한 연결은 또한 당신이 위키피디아로 보내는 데이터를 손상시킬 수 있기 때문에, 당신의 브라우저가 보낸 쿠키가 전송 중에 손상되었기 때문에 위키피디아는 당신이 로그인되어 있다는 것을 인식하지 못할 수도 있다.

--David Göthberg (대화)20:30, 2010년 1월 16일 (UTC)

아카이브를 통한 자동 검색 완료

나는 종종 오래된 게시물들을 읽는다 그리고 나는 종종 이미 보관되어진 토론의 링크들을 발견한다.— 디스펜서 03:36, 2010년 1월 16일 (UTC)

세상에, 타이밍 감각이 없어? 우리 모두 공황에 사로잡히는 데 집중하고 있는데 넌 그런 질문을 해?LTSally (대화) 04:02, 2010년 1월 16일 (UTC)

휴, 위기 극복.미안. 계속해! LTSally (대화) 04:20, 2010년 1월 16일 (UTC)

브라우저는 위키피디아에서 어떤 부분을 열려고 하는지 알려주지 않기 때문에, 나는 이것이 자바스크립트에서만 이루어질 수 있다고 생각한다.이 문제를 비롯한 많은 문제를 해결하는 리퀴드스레드가 곧 배치되기를 바란다.Svick (대화) 11:42, 2010년 1월 16일 (UTC)

FYI, 나는 LevelBot이 페이지를 보관할 때 이러한 링크를 수정한다고 믿는다.- 킹핀¹³ (토크) 11:48, 2010년 1월 16일 (UTC)

document.getElementById(location.hash.substring(1))!=null알 수 있을 거야하지만 나는 검색창에 상관없이 그냥 복사해야 한다고 생각해 — 디스펜서 15:50, 2010년 1월 16일 (UTC)

사용자 기여 검색

우리는 우리 자신과 다른 사람들의 기부금 내에서 검색할 수 있어야 한다.이를 bugzilla.174.3.106.27(대화) 01:22, 2010년 1월 17일(UTC)에 게시

넌 이미 할 수 있어.위키백과 참조:도구#페이지_역사.페이지 기록을 검색하고 특정 편집 내용을 찾을 수 있거나 사용자가 편집한 페이지, 기본적으로 원하는 모든 페이지를 찾을 수 있는 몇 가지 타사 도구가 있다. --Jayron32 04:41, 2010년 1월 17일(UTC)

템플릿:iw-ref

{{iw-ref}}}}이(가) 마르틴 알론소 핀손에서 사용했던 기사 이름 대신 "동등 기사"라는 텍스트를 생성하는 이유를 알 수 있는 사람이 있는가?문서를 간단히 보면 내가 이 일을 제대로 했다고 되어 있고, 코드를 간단히 보면 기사 이름을 표시하려는 의도가 있음을 알 수 있다. - Jmabel Talk 06:17, 2010년 1월 15일 (UTC)

{{#if:}{{{#if:}}}의 '등가물' 바로 앞에 수직 파이프를 보고 있기 때문이라고 추측한다.{{{{2}}}} [{{{1}:{1 }}}:{{2}} }}} 등가 기사] on}}}}}에는 if 문에서 거짓 옵션으로 사용하기보다는 링크의 이름을 바꾸는 파이프로서 이름이 변경된다.{{#if:로 다시 쓰고 싶을 것이다.{{{{{2}}}} [{{{1}:{1}}}:{{2 }}}}}}}}}}}}}}}}}에 해당하는 글, 즉 '등가 기사' 부분은 연결되지 않음을 의미함. --Ludwigs2 06:34, 2010년 1월 15일 (UTC)

P.s. 다시 생각해 보니, (좋다고는 말할 수 없지만) 의도적인 것일 수도 있다고 생각한다.그들은 아마도 항상 템플릿이 정확한 링크를 명시하기 보다는 "이 기사는 ...에 대한 동등한 기사의 개정판으로부터 정보를 통합한다"고 말하길 원할 것이다.링크가 정확해, 그냥 링크 라벨이 일반적이야그런 의도가 있었는지 토크 페이지에서 질문해 보겠다. --Ludwigs2 06:39, 2010년 1월 15일 (UTC)

그 문제는 영어 기사가 특정 위키백과에서 둘 이상의 기사를 쓰거나, 더 넓거나 좁은 범위의 기사를 쓸 때 발생한다.즉, 다른 위키백과에서 인용한 자료가 항상 동등한 기사에서 나온 것은 아니다. - Jmabel Talk 21:37, 2010년 1월 17일 (UTC)

데이터베이스 지연 시간

1311초의 서버 지연이 있어서 해킹이 진행 중인가? 그리고 나서 내 사용자 이름을 클릭하려고 했을 때 "오 이런!우리의 JSON 질의가 물거품이 되었나?" --macbookair3140 (토크) 02:24, 2010년 1월 16일 (UTC)

그래, 무슨 일이 일어나고 있어.라그는 지금 거의 2,000초다.Equazcion 02:29, 2010년 1월 16일 (UTC)

내 기여 페이지가 2시간 이상 늦었어.우지 (토크) 02:38, 2010년 1월 16일 (UTC)

"데이터베이스 서버 지연이 높기 때문에 2,249초보다 최신의 변경사항이 이 목록에 나타나지 않을 수 있다.

1407초 정도의 데이터베이스 지연이 있다는 게 무슨 일인가?내가 원치 않는 잡동사니를 봇에서 정리하는 것에 대한 우려를 언급할 때마다, 사람들은 나에게 서버들이 튼튼하고 어떤 것도 서버 속도를 늦출 수 없다고 단언한다.그럼, 거기서 12분간의 데이터베이스 서버 지연으로 어떻게 갈까? --IP69.226.103.13 나에 대한 이야기. 02:26, 2010년 1월 16일 (UTC)

WP:VP/T. —DoRD(대화) 02:33, 2010년 1월 16일(UTC) 이쪽에 있는 AN/I에서 내 응답을 복사하지 마십시오.고마워요.—DoRD (대화) 02:59, 2010년 1월 16일 (UTC)

패닉 버튼

음, 여긴 WP:VP/T야. 그래서...왜 서버들이 자기 자신을 속이는 거야?내 마지막 워치리스트는 1시 58분인데, 몇 가지 기사 기록을 확인해 보면, 그 기사들은 거의 동시에 업데이트되는 것을 멈췄다.최근의 변경 페이지는 완전히 최신이지만...아이디어 있으십니까? --Jayron32 02:44, 2010년 1월 16일 (UTC)

이것은 AN/I에서 복사한 것이다.케빈 러더포드 (대화) 02:45, 2010년 1월 16일 (UTC)

흠... 당황할 수도 있지?그냥 여기서 브레인스토밍 하는 거야.Equazcion 02:46, 2010년 1월 16일 (UTC)

나는 우리가 공황상태에 빠졌다고 생각한다.분명히 우리 주변의 세계는 붕괴되어 있다.케빈 러더포드 (대화) 02:50, 2010년 1월 16일 (UTC)

나는 꽤 오랫동안 당황하지 않았다.난 조금 필요할 수 있다.그럼 패닉인가? --Jayron32 02:54, 2010년 1월 16일 (UTC)

지원 공황과 집단 히스테리. 모금 시기가 아니므로 위키피디아가 위키피디아 사용으로 논문을 베끼는 모든 사람이 더 많은 돈을 받고 버티는 것은 아니다.--테릴자 _talk 02:57, 2010년 1월 16일 (UTC)

패닉!이제 뭐.나는 그 공황상태의 제안으로 여기까지 온 적이 없다.다음에 무엇을 해야 할지 생각나는 거 있어?케빈 러더포드 (대화) 02:59, 2010년 1월 16일 (UTC)

지원공황. --macbookair3140 (대화) 03:04, 2010년 1월 16일 (UTC)

그럼 패닉이 해결책이겠군이제 3천 8백 초까지입니다.내가 본 것 중 최악이다.—DoRD (대화) 03:06, 2010년 1월 16일 (UTC)

난 더 나쁜 걸 봤어.전에도 이런 일이 있었다.누군가에게 알려야 할 것 같아, 난 그저 누가 누군지 잘 모르겠어.데브스?Equazcion 03:10, 2010년 1월 16일 (UTC)

서버 지연이 1시간 10분이 넘었으니, 분명 뭔가 일이 벌어진 것이다.공황상태다.케빈 러더포드 (대화) 03:11, 2010년 1월 16일 (UTC)

이제 4000초가 넘었다.2012년^{Talk to me} 12월 21일 03:12, 2010년 1월 16일 (UTC)

설명서만 읽으면 4000초도 넘게 걸려. 누가 애들 좀 생각해봐!화분마N·(t) 03:16, 2010년 1월 16일 (UTC)

베타 스킨이 베타 스킨이 떨어져서 그런지 지금 5,000개를 승인하고 있다.2012년^{Talk to me} 12월 21일 03:23, 2010년 1월 16일 (UTC)

5천 초가 넘었기 때문에 오늘이 아마도 위키피디아의 마지막일 것이다.2012년^{Talk to me} 12월 21일 03:26, 2010년 1월 16일 (UTC)

나는 몇 달 전에 데이터베이스 서버와 WWW 서버 사이에 라우팅 문제가 있었을 때 10,000초 이상의 지연을 보았다.Bidgee (대화) 03:38, 2010년 1월 16일 (UTC)

몇 분만 시간을 줘, 1만 명까지는 갈 수 있을 거야.벌써 6k를 두드리고 있어.--Mr RadioGuy P T C E 03:41, 2010년 1월 16일 (UTC)

이것이 무력하게 비명을 지르는 일종의 공황인가, 아니면 폭동을 일으키는 공황인가, 건물에 불을 지르고 자경단을 찾아가서 범죄자를 구타하는 자크1688^Talk 03:12, 2010년 1월 16일 (UTC)

첫 번째는 재미있을 것 같아.Equazcion 03:13, 2010년 1월 16일 (UTC)

동감이다소리 지르면서 돌아다녀야 할 것 같아.만약 우리가 폭동을 부추긴다면, 사람들과 위키피디아가 다칠지도 모른다.케빈 러더포드 (대화) 03:16, 2010년 1월 16일 (UTC)

이제 DB서버에게 세 손가락 경례를 해야 할 때라고 생각한다.—DoRD (대화) 03:26, 2010년 1월 16일 (UTC)

• 소리지르는 강한 지지 공황. --IP69.226.103.13 내 얘기. 03:29, 2010년 1월 16일 (UTC)
• 강력한 지원 활동은 이러한 부분에 대한 단어보다 더 크다.케빈 러더포드 (대화) 03:31, 2010년 1월 16일 (UTC)

지지하지만 소리치며 뛰어다니는 것은 사람들에게 운동을 시켜주고 있다. --MrRadioGuy P T C E 03:33, 2010년 1월 16일 (UTC)

공황상태는 어때?지금 6천에 가까워지고 있어, 뭐 5620 정도.아직도 생각이 안 나?하이로니모스 로위 (대화) 03:35, 2010년 1월 16일 (UTC)

음, 나는 장을 보러 갈 것이고 내가 돌아왔을 때 상황이 나아지기를 바랄 것이다:-) 의사 제임스 (대화 · 기여 · 이메일) 03:38, 2010년 1월 16일 (UTC)

구명 보트에 빨리 타!6,000초라는 지연을 맞췄다.Bidgee (대화) 03:43, 2010년 1월 16일 (UTC)

패닉 업데이트: 6000 :) 초이우우우우우우시히:2010년 1월 16일(UTC) Sub Az86556 03:43, 16(UTC)

일하는 감시원이 없어서 이상하다.눈이 멀고 알몸이 된 기분이다.Equazcion 03:44, 2010년 1월 16일 (UTC)

그러나 무력하지는 않다!;;) Bidgee (대화) 03:46, 2010년 1월 16일 (UTC)

그러게 말이야, 지금 어떤 무작위 광기가 일어나고 있는지 누가 알겠나?하이로니모스 로위 (대화) 03:49, 2010년 1월 16일 (UTC)

특별함:여전히 작동하는 최근 변화들.Bidgee (대화) 04:02, 2010년 1월 16일 (UTC)

동의해, 이제 내가 보고 있는 모든 페이지를 확인해서 재미있는 일이 있는지 봐야 해.케빈 러더포드 (대화) 03:50, 2010년 1월 16일 (UTC)

그것은 7천명을 승인하고 있다. 위키피디아에서 2001년이 될때까지 기다려라.2012년^{Talk to me} 12월 21일 03:53, 2010년 1월 16일 (UTC)

7,000초만 쳐봐!새로운 기록을 세운 것 같군, 응?Schiffty3 03:59, 2010년 1월 16일 (UTC)

어쩌면 위키피디아가 작동하고 있을지도 모르지만 '미국'은 시간적으로 거꾸로 움직이고 있다...(미안하지만 설명서에 7천명 이상이 스타 트렉에 대한 설명을 요구한다고 되어 있다.화분마N·(t) 04:10, 2010년 1월 16일 (UTC)

• 어떤 형태의 공황도 다른 공황보다 우월하다고 선택하려는 시도에 강력히 반대한다.WP별:NPOV, 모든 다른 형태의 공황은 신뢰할 수 있는 출처에서 그들의 중요성을 공정하게 반영하는 커버리지를 받아야 한다. --BrownHairedGirl (토크) • (contracts) 04:01, 2010년 1월 16일 (UTC)

패닉이라면, 수건을 잊지 마! ref.은하계 히치하이커 가이드!--220.101.28.25 (토크) 04:06, 2010년 1월 16일 (UTC)

누군가 실수로 샌드박스 전체를 다시 만든 거야?Droughaway85 (토크) 04:21, 2010년 1월 16일 (UTC)

이제 거의 9000년이 다 되어가는데, 분명히 종말이 왔다.우리 모두는 좌파 진보주의자들이라는 이유로 지옥에 보내지지 말고 천국에 갈 수 있도록 음악원에 가야 한다. Jac16888^Talk 04:32, 2010년 1월 16일 (UTC)

왜, 하느님은 죄인만 받아들이시는 겁니까? --브라운헤어드걸(토크) • (기증) 04:37, 2010년 1월 16일 (UTC)

나는 우리의 마지막 시간이 위키피디아 리뷰로 가는 것이 더 나을 것이라고 생각한다. 위키피디아 리뷰로 가는 것이 우리 각자가 그들의 특정한 카발리즘적 유대관계를 고백하고 용서를 빌 수 있는 것이다.Droughaway85 (토크) 04:38, 2010년 1월 16일 (UTC)

몇 시간만 주어진다면 내가 카발 대신 모든 활동을 나열할 수 있을 만큼 길지 않아 여전히 운명에 처할 것이다. --브라운헤어드걸(토크) • (출연) 05:10, 2010년 1월 16일 (UTC)

라그 = 0. 앞으로 나아가 다시 죄를 짓는다. --220.101.28.25 (토크) 05:14, 2010년 1월 16일 (UTC)

"어려울 때, 의심스러울 때,
빙글빙글 돌면서 소리 지르고 소리 지르고."
WP당:원 (WP에 추가할 수 있음:패닉...;) -- Quiddity (대화) 21:10, 2010년 1월 16일 (UTC)

투표는 사악하다.

• (뭐, 그런 일이 오는 걸 못 봤나?)---구스 신부 (토크) 04:03, 2010년 1월 16일 (UTC)

호주에 있는 우리는 국제적인 날짜 선에 더 가깝고 대부분의 다른 나라들보다 먼저 새해를 보기 때문에, 나는 우리가 또한 이 문제를 고치는 첫 번째 사람이 될 것이라고 생각한다.모든 것이 정상으로 돌아오면 알려줄게.LTSally (대화) 04:08, 2010년 1월 16일 (UTC)

빠르게 8,000!--220.101.28.25 (대화) 04:12, 2010년 1월 16일 (UTC)

8,000. 이제 10,000^{[Must be 21 or older/void where prohibited/restrictions apply]} choyoowʼįhi에 대한 내기를 받아들인다.2010년 1월 16일(UTC) 셉 Az86556 04:15:15

나는 분명한 것을 추구한다; 그것은 분명히 9,000이 넘을 것이다!!!(여러분은 지금 명백한 인터넷 밈을 빼내 준 것에 대해 감사해도 좋다.)네이트 • (대화) 04:24, 2010년 1월 16일 (UTC)

베팅은 악이다.

투표만큼 악하지 않다는 것을 인정한다. 물론 그것은 사탄의 탄생이다.Equazcion 04:17, 2010년 1월 16일(UTC)

음, 나한테는 지연 메시지는 사라졌지만, 감시 목록은 여전히 업데이트되지 않았어.Equazcion 04:20, 2010년 1월 16일(UTC)

악은 악이다.

아무도 눈치채지 못한 것 같다-Jac16888^Talk 04:18, 2010년 1월 16일 (UTC)

음. 서버 지연 통지는 서버 지연/고장 발생... :PChoyoowʼįhi:2010년 1월 16일(UTC) 셉 Az86556^{> haneʼ} 04:19:19

그러나 나의 기여와 감시목록은 아직 몇 시간 뒤쳐져 있다.2012년 12월 21일 04:21, 2010년 1월 16일 (UTC)

맙소사 ---. 몇 초인지 최종 집계할 수 있을까?케빈 러더포드 (대화) 04:22, 2010년 1월 16일 (UTC)

수동 스톱워치를 작동시켰다.내 책상 위에 있는 조이우우우히:Az86556 04:23, 2010년 1월 16일(UTC)

아니, 돌아왔어.케빈 러더포드 (대화) 04:24, 2010년 1월 16일 (UTC)

내려가다. 최고봉은 8,906초요우łhi였다.2010년 1월 16일(UTC) 셉 Az86556 04:33:33,

8,984-Jac16888^Talk 04:39, 2010년 1월 16일 (UTC)

알았어더 높은 봉우리들이 보이나?네이트에게 희망을 주자, 그의 내기는 9,000:P Choyoowʼhi:2010년 1월 16일(UTC) 9월 Az86556^{> haneʼ} 04:41, 16

IRC를 통한 오타바는 9001을 보고했다.ITS OULD OUP 9000!!!!!!!!!!! --Izno (토크) 06:44, 2010년 1월 16일 (UTC)

그래, 이제 피치포크랑 횃불을 내려놓는 게 좋을 것 같아.케빈 러더포드 (대화) 04:42, 2010년 1월 16일 (UTC)

음, 작은 문제야, 실수로 불타는 횃불을 세금 관련 기사 더미에 떨어뜨렸어.약 6개월 후에 누군가가 그들이 떠났다는 것을 알게 되면 난 곤경에 처할 거야. 그렇지?--Jac16888^Talk 04:45, 2010년 1월 16일 (UTC)

6,900˚ 운동을 사용했을 수도 있다.휴! 멜트다운은 피했다.그럼 이것도 필요 없을 겁니다. --220.101.28.25 (대화) 04:45, 2010년 1월 16일 (UTC)

그래, 다시 돌아가서 그 말도 안 되는 사소한 사건에 대해 걱정하자...또 뭐였지?맞아, 아이티...츄우우우히:Az86556 04:46, 2010년 1월 16일(UTC)

다시 시간이 따라가는 걸 보니 좋군지금으로부터 423초 후에 일어날 반달리즘을 되돌리려 한다.LTSally (대화) 04:48, 2010년 1월 16일 (UTC)

젠장, 이제 난 이 페이지에 앉아 있는 것 말고도 생산적인 일을 해야 해.케빈 러더포드 (대화) 04:49, 2010년 1월 16일 (UTC)

WP:Crystal Choyoowʼįhi:를 읽어보십시오.Az86556 04:49, 2010년 1월 16일(UTC)

재미는 다 놓친 것 같아!
— V = I * R (옴과 대화 법) 23:02, 2010년 1월 16일 (UTC)

편집자들이 그날의 어떤 상황이건 아무 것도 할 수 없을 때 생기는 유쾌하고 선량한 농담은, 내 사기를 북돋우는 것을 멈추지 않는다.불행히도 훨씬 더 흔한 불타는 드라마 축제에서 우리가 그 이상에서 한 발짝도 벗어나지 못하고 있다는 것을 보여준다.해피멜론 13:17, 2010년 1월 17일 (UTC)

CSS 파일

기사의 내용을 제대로 렌더링하기 위해 필요한 CSS는 무엇인가?"인쇄 전용"과 같은 클래스는 어디에 정의되어 있는가? --Apoc2400(토크) 08:32, 2010년 1월 17일(UTC)

이론적으로 모든 강좌는 위키백과에 분류되어 있다.CSS 클래스 카탈로그.실제로 인쇄 전용은 MediaWiki에서 정의된다.Common.css. ---— Gadget850 (Ed) 11:29, 2010년 1월 17일 (UTC)

고마워. 모노북/main.css의 "외부"에 의해 외부 링크가 만들어진 후의 작은 화살표로 보여.하지만 내가 그것을 포함한다면, 위키백과 배경 이미지를 넣고 기본 글꼴을 바꾼다.원하는 부품만 가지고 나만의 monobook/main.css를 굴려야 하는가? --Apoc2400 (토크) 12:33, 2010년 1월 17일 (UTC)

끝에 유니코드 문자가 인쇄되지 않은 페이지 제목?

WP 후속 조치:AWB 버그 리포트 화재 엠블럼의 등장인물 목록: 푸인노 쓰루기는 그 끝에 인쇄되지 않은 유니코드 문자를 가지고 있는데, C# 시스템이기 때문이다.HttpUtility.UrlEncode함수는 예기치 않게 "%e2%80%8e"가 추가된 이름 문자열을 반환한다(공백과 악센트 문자를 올바르게 변경함).기사 이름을 손으로 치면 "%e2%80%8e"가 예상대로 붙지 않는다.페이지의 원제목을 어떻게 체크해야 할지 모르겠는데, 누가 좀 도와줄 수 있어?고마워 Rjwilmsi 11:15, 2010년 1월 17일 (UTC)

달리기를 해서 이상한 인물은 찾지 못했다.javascript:alert(escape(wgTitle))이 페이지에서는 [1]을(를) 육각으로 검사하지 않는다.기사 제목은 괜찮은 것 같아.Svick (대화) 12:16, 2010년 1월 17일 (UTC)

툴서버의 페이지 테이블 항목도 괜찮아 보인다.해피멜론 12시 40분, 2010년 1월 17일 (UTC)

%e2%80%8e는 좌우 표시다.왜 나타나는지 모르겠다. --Apoc2400 (대화) 13:56, 2010년 1월 17일 (UTC)

답장 고마워.Javascript 코드를 즐겨찾기에 넣을게.그러면 페이지에 오류가 없다.AWB에서도 오류가 없는 것 같다.문제는 처음에 캐릭터가 어떻게 사용자의 설정 파일에 들어갔는지에 관한 것이다.Rjwilmsi 14:00, 2010년 1월 17일(UTC)

워치리스트가 더 이상 기사를 표시하지 않음

나는 도움말 페이지에서 이것을 물었지만 여기가 더 좋은 곳일 수도 있다는 것을 깨달았다.내가 본 사용자 페이지의 감시 목록을 정리하는 동안, 나는 내가 보고 있는 3000개의 기사를 어떻게든 삭제했다.기사 이름이 편집 페이지에 그대로 나타나면서 복사해서 붙여넣었는데, 지금은 내 워치리스트가 교육받지 못한 내 눈에는 괜찮아 보이지만 기사에는 아무런 변화가 보이지 않는다.왜 그런지 간단한 이유가 있는가?고마워요.더그웰러(대화) 12:35, 2010년 1월 17일(UTC)

더 자세히 살펴본 결과, 삭제된 페이지의 이름을 복사했을 때 각 이름 뒤에 {talk}이(가) 있는 이름을 복사했고, 그 이름을 붙여넣은 후 {talk} {talk}이(가) 있는 이름 뒤에 다시 붙여넣은 다음, 즉 감시목록이 모두 {talk}(으)로 끝나는 것처럼 기사 이름을 보고 있다는 것을 알게 되었다.삭제 및 새 복사본과 붙여넣기를 통해 {talk}이(가) 수정되지 않음.더그웰러 (대화) 15:52, 2010년 1월 17일 (UTC)

Y2.01K 버그?

안녕. 새해 첫날에 이상한 일이 생겼으니 헬프 데스크에서 토론을 보고 여기서 회신해줘.고마워 ~AH1^(TCU) 17:29, 2010년 1월 17일 (UTC)

솔직히 말하자면, 나는 실제적인 문제가 없다고 본다.00:01까지 기다렸다고 생각하셨는데, 지역 시스템과 원격 사이트 간의 시간 기록 차이 때문에 쉽게 설명되십니다.타이밍 차이 < 1분, 특히 기술적으로 정확한 시간 계측에 의존하지 않는 이것과 같은 시스템에서는 오류의 설계 여유도 내에서 매우 허용된다.불만 사항이 뭔지 놓치는 게 아니라면, 여기...
— V = I * R (Talk to 옴s law) 19:34, 2010년 1월 17일 (UTC)

내가 Save 페이지를 한 번만 눌렀지만 위키피디아는 자동으로 다섯 번 항목을 게시하는 것은 어떨까?내가 연결한 것뿐만 아니라 2010년 첫 번째 것부터 다시 살펴봐 줘.~AH1^(TCU) 22:33, 2010년 1월 17일(UTC)

무슨 일이 있었는지 내 짐작은."편집" 대신 "새 섹션 추가"를 누른 경우.그리고 당신은 편집문을 작성했고 손으로 제목을 추가했다.이로 인해 게시물에는 두 개의 제목이 작성되었다.그런 다음 저장을 두 번 눌러 해당 섹션을 현재 페이지에 추가하십시오(이러한 방법으로 "새 섹션 추가"와 "편집"이 다름).—DJ (대화 • 기여) 23:36, 2010년 1월 17일 (UTC)

녹색 화면 가젯/토크 페이지 문제

나는 내가 위키피디아를 사용하지 않을 경우 받는 눈의 피로를 막기 위해 그린스크린 기구를 사용한다.나는 몇 개의 설명 페이지(예: User talk:ed17은 검정 바탕에 검은색으로 나타나는데, 이상보다는 오히려 덜하다.무엇이 이것을 야기하는지, 그리고 어떻게 고치는지를 아는 사람이 있는가?고마워, 던컨힐 (토크) 00:02, 2010년 1월 18일 (UTC)

응, 사용자가 페이지의 CSS를 사용하여 텍스트의 색상을 명시적으로 설정할 때 생기는 거야.예를 들어, 맨 위쪽에 있는 그 페이지에는 테두리:2px 솔리드 라이트스틸 블루; 컬러:블랙;퐁-패밀리:길 산스 MT. 정확히 이런 이유로 그렇게 하는 것은 좋지 않은 관행이지만, 얼마나 많은 일을 할 수 있을지는 잘 모르겠어...Ale_Jrb^talk 00:07, 2010년 1월 18일(UTC)

음, 확실해?내가 색을 제거했을 때:검은색,아무것도 하지 않았다.[2] :/ —Ed (대화 • 장엄한 타이탄) 00:22, 2010년 1월 18일 (UTC)

잘못 짚은 것 같아.널 위해 고쳤는데 이제 기계와 제대로 작동해뭔가 잘못됐으면 얼마든지 되돌아가라, 분명히.Ale_Jrb^talk 00:29, 2010년 1월 18일(UTC)

나는 단지 Ale_jrb와 Ed 둘 다 그들의 도움에 감사하고 싶다.던컨힐 (대화) 00:31, 2010년 1월 18일 (UTC)

(충돌 편집)웁스, 네 말이 맞아.바보 같은 날.고마워!

던컨: 천만에요.—Ed (토크 • 장엄한 타이탄) 00:32, 2010년 1월 18일 (UTC)

통신 도구?

FAQ(실제 FAQ에 나와 있지 않음)인 경우 죄송합니다만, 데이터베이스를 검색하여 두 개의 (이명) 편집자가 공통적으로 편집한 기사/페이지를 확인할 수 있는 도구가 있는가?고마워, 04:07, 2010년 1월 18일 (UTC)

최근에 헬프 데스크에서 바로 이 주제에 대한 질문이 있었다.답은 위키스토크와 크로스 기여였다.Intelligentsium 04:13, 2010년 1월 18일(UTC)

정말 고맙다. 거기 한번 가볼까 생각했어야 했다.건배! 2010년 1월 18일 04:16 (UTC)

참조 태그: 가변 세부 정보가 포함된 길고 짧은 양식 및 편집 순서 유지

같은 책이지만 다른 페이지와 같이 사소한 차이점을 제외하고 하나의 출처를 참조한다면, 이후 편집자가 본문을 다시 인용하면 정상적인 해결책이 실패한다.보다 유연한 참조 태그 지정이 필요하다.

문제:예제(발신됨):

"뉴욕은 도시[1]이고 강이 있는 주[2]이다."

"1. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 4."

"2. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 7."

이것은 너무 많은 중복성을 가지고 있다.그것은 "뉴욕은 도시다"에서 비롯되었다.뉴욕지리학, 수잔 친, 트라팔가 드 누베스, 빌리 스미스, 크리스틴 엠버스 (N.Y: 포터하우스 셀러리 출판, 1523년 3차 개정), 페이지 4.</ref>, 주(州)뉴욕지리학, 수잔 친, 트라팔가 드 누베스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 제3판 1523호), 페이지 7. 강과 함께."

보다 컴팩트하게 하기 위해 이름 속성을 사용해 보십시오.

"뉴욕은 도시다.뉴욕지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일)의 뉴욕지리학.</ref>와 상태<ref name="뉴욕" /> 강과 함께."

"1. 수잰 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일)에 의한 b 뉴욕 지리학"

그러나 그것은 페이지 번호를 생략하고, 그래서 우리는 더 긴 양식으로 되돌아간다. 이제서야 우리는 첫 번째 참조 이후 더 짧은 참조를 위해 참조의 공유 부분을 편집하고 페이지 번호를 추가한다.

"뉴욕은 도시다.뉴욕지리학, 수잔 친, 트라팔가 드 누베스, 빌리 스미스, 크리스틴 엠버스 (N.Y: 포터하우스 셀러리 출판, 1523년 3차 개정), 페이지 4.</ref>, 주(州)뉴욕지리, 위, 7페이지 강과 함께."

이렇게 하면 좋은 결과를 얻을 수 있다.

"뉴욕은 도시[1]이고 강이 있는 주[2]이다."

"1. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 4."

"2. ^ 뉴욕 지리, 위, 페이지 7."

누군가가 참조자의 순서를 바꾸고 싶을 때까지, 즉.다른 누군가가 도시를 국가보다 우선시하는 것이 지역 우월주의적이며, 세계적인 관점에서 더 크고 포위된 정치 단위가 우선시되어야 한다고 결정한다고 상상해보라. (당신이 그것에 동의하든 상관하지 말고, 단지 편집자가 그것을 결정한다고 가정하자.따라서 다음과 같이 기본 텍스트를 편집한다.

"뉴욕은 주(州)이다.뉴욕 지리학, 위, 7페이지와 도시.뉴욕지리학, 수잔 친, 트라팔가 드 누베스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 제3판 1523호), 페이지 4. </ref> 강과 함께."

기사 페이지에 나타나는 내용은 다음과 같다.

"뉴욕은 주[1]이고 강이 있는 도시[2]이다."

"1. ^ 뉴욕 지리, 위, 페이지 4."

"2. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 7."

읽기 쉽거나 정확하지 않음: "위"가 잘못됨.그리고 편집자는 아마도 참고문헌의 일부를 옮겨다녔어야 했지만, 만약 본문에서 그들이 단지 단어뿐만 아니라 전체 단락이나 섹션으로 움직인다면, 참고문헌의 편집은 이루어질 것 같지 않으며, 봇은 아마도 그것을 일관성 있게 포착하도록 설계될 수 없을 것이다.

제안:나는 <ref>,<그룹="에 대한 새로운 속성과 <ref name="" group=""""에 두 개의 새로운 태그가 중첩될 것을 제안한다. . . .</ref.그들은 길다... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

에서 조사를 위해 무엇이든지<>long> 내에 있음을 명시할 수 있을 때마다 reflist 같은 group=""특성 같은 기준으로 referents에서.. 참조를 생성합니다.<, /long&gt고, 못하는 일이 아니라<>안에 있어;short>....<, /short>무엇이든<> 짧은 이내에 있는 모든 다른 참조에 같은 group=""값을 기반으로 것 상태.>.<, /short> 아니라 wh.는 (긴) 범위 내에 있고, ("ref group="") 내에 있는 것은 무엇이든지 간에 ("ref group=") . . (/ref") 두 개의 새로운 태그 중 어느 하나에도 속하지 않는 것은 아마도 한 번만 나타나는 독특한 것일 수 있다.

편집 필드에서는 두 개의 새 태그가 동시에 사용되며, 두 태그는 <ref group=""""... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ./ref.또한 받아들일 수 있는 것은 <ref group="""". "짧은 길이" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .또한 <ref group=""""..." long" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .."일반적으로 첫 번째 줄임표나 </긴> 또는 </짧은> 닫힘 태그와 후속 <짧은> 또는 <긴> 개구부 태그 사이에는 아무것도 나타나지 않지만, 모든 줄임표는 선택적 채우기를 나타낸다.한 그룹 값에 대해, 한 번 이상 <긴>. . . . . . . . . . . 긴 그룹의 모든 인스턴스가 무시된다.한 그룹 값에 대해 <짧은>. . . . . . . . . . . . . 그룹의 모든 인스턴스가 무시된다.

group="와 name="의 값은 독립적일 것이며, 우연은 필요하지 않을 것이다.

위의 예에서 다음과 같이 하십시오.

<ref name="NYG" 그룹="뉴욕시뉴욕지리학, 수잔 친, 트라팔가 드 누베스, 빌리 스미스, 크리스틴 엠버스 (N.Y: 포터하우스 셀러리 출판, 제3편 1523편) </긴 뉴욕지리학> 페이지 4.

<ref name="NYG" 그룹="뉴욕" 7페이지.

결과, 표시:

"뉴욕은 도시[1]이고 강이 있는 주[2]이다."

"1. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 4."

"2. ^ 뉴욕 지리학, 페이지 7."

편집자가 내용을 편집하지 않고 참조인을 반전시키는 경우:

"뉴욕은 주[1]이고 강이 있는 도시[2]이다."

"1. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 7."

"2. ^ 뉴욕 지리, 페이지 4."

<ref name="인 경우NYG" />는 본문에 있는데, 제3의 참고문헌이 추가된 경우, <ref name="에 근거한 짧은 형식이 함축되어 있을 것이다.NYG" group="" 어디선가, 예:

"뉴욕은 주(州)이다.NYG" 그룹="뉴욕시"<긴 길이> . . . . . . . . . . . . . . . . . . . .ref. 도시<ref 그룹="NYG"라 함은 강과 함께 </ref>라고 쓰여져 있으며, 또 다시 <ref name="라고 쓰여졌다.NYG" />>그리고 또.<ref name="NYG" />”

"뉴욕은 주[1]이고 강이 있는 도시[2]이며 계속해서 쓰여져 왔다.[3]"

"1. ^ 뉴욕 지리학, 수잔 친, 트라팔가 드 누에브스, 빌리 스미스, 크리스틴 엠버스 (N.Y.: 포터하우스 셀러리 출판, 1523년 3월 3일) 페이지 7."

"2. ^ 뉴욕 지리, 페이지 4."

"3. a New York Geography"

빈 태그의 경우 그룹 속성은 불필요하지만 이름 및 그룹 속성은 태그 세트가 연결될 수 있도록 적어도 하나의 참조 태그에서 발생해야 한다.

유일한 변칙적인 비트는 참고문헌 끝 문장이다: 작가가 무엇을 하느냐에 따라 최종 기간이 나타나는 경우도 있고 그렇지 않은 경우도 있다. 따라서 일관성을 위해 작가는 가능한 모든 경우에 최종 기간을 생략할 수 있다.

기술적 구현에서 태그가 ref group=" ref 밖에 나타나거나 그룹 속성이 없거나 해당 값이 null이면 의미가 없다.태그의 내용은 마치 의미 없는 태그가 없는 것처럼 취급될 것이다.

이름="는 다른 목적을 위해 사용되므로 선택 사항이다.

감사합니다.

닉 레빈슨 (대화) 03:04, 2010년 1월 17일 (UTC)

이럴 필요 없어참고 문헌이 각주로부터 분리되어 있으므로 참고문헌의 순서가 바뀌는 것에 대해 걱정할 필요가 없으며 페이지 번호와 함께 짧은 형식의 각주를 사용할 수 있는 플리머스 콜로니 같은 기사를 보라.참조 시스템을 더 복잡하게 만들 필요 없이, 지적한 문제에 대한 합리적인 해결책이 있다. --Jayron32 04:36, 2010년 1월 17일 (UTC)

그렇다, 제이론이 설명한 2부제 시스템은 특히 더 무거운 기사들에 대한 이 문제에 대한 해결책에 대한 나의 경험이다.또는 완전히 분리되어 있는 서지학이 적절하지 않은 경우에는 과거에 {{rp}}를 사용해 본 적이 있지만, 훨씬 희귀한 옵션인 것으로 알고 있다. - Jarry1250 10:38, 2010년 1월 17일(UTC)

플리머스 콜로니는 긴 각주와 짧은 각주를 혼합하여 사용한다.짧은 각주의 좋은 예는 차코 문화 국립 역사 공원을 참조하십시오.참고 항목: {{Sfn} 및 {{SfnRef}}. --- - Gadget850(Ed) 15:11, 2010년 1월 17일(UTC)

알았어. 그만둘게.나는 이별이 좋다.닉 레빈슨 (대화) 2010년 1월 18:23 (UTC)

인쇄 가능한 버전 제안사항

해결됨

이런 변화를 어디서 제시해야 할지 모르겠지만, 여기서 제안할게.페이지 하단에 "인쇄 가능한 버전"을 "연락처"로 기재할 필요가 있는가?스몰맨12q (대화) 17:23, 2010년 1월 18일 (UTC)

아니, 내가 알아서 할게.—DJ (대화 • 기여) 21:32, 2010년 1월 18일 (UTC)

기록 도구

역사 페이지 상단에 있는 외부 도구 링크를 누락한 사람이 있는가? 이상하게도 파이어폭스에서만 발생하는 외부 도구 링크가 여전히 IE--Jac16888^Talk 22:14, 2010년 1월 18일(UTC)에 있다.

너의 언어는 영국식 영어에 맞춰져 있지 않니?그렇게 되면 이런 일이 생길 것이다.그리고 두 브라우저에 모두 로그인하셨나요?Svick (대화) 22:36, 2010년 1월 18일 (UTC)

IE에 로그인하지 않고 어제 언어만 변경하고, 다시 변경하고, 지금 다시 돌아왔어.고마워요.내가 영국영어를 btw로 설정할 줄 어떻게 알았어?그리고 왜 그런 영향을 미치는가?--Jac16888^Talk 22:41, 2010년 1월 18일 (UTC)

언어를 바꾸면 위키백과 인터페이스가 번역된다.해당 섹션의 번역(MediaWiki:히스레젠드)는 영국 영어와 아마도 다른 모든 언어에서 비어있다.이번이 처음이 아니어서 언어 설정일 거라고 확신했어.Svick (대화) 23:14, 2010년 1월 18일 (UTC)

영국 영어의 "번역"은 이제 역사 도구를 포함하도록 바뀌었다.Svick (대화) 00:16, 2010년 1월 19일 (UTC)

좋았어, 고마워--Jac1688^Talk 02:10, 2010년 1월 19일 (UTC)

그 날의 사진이 해킹을 했다고?

{{POTD}}에는 "e-러닝 모바일 소프트웨어, 모바일 클립, 페스티벌 테마 등 모바일에서 신기술 소프트웨어를 제공하는 전문 소프트웨어"라는 문구와 http://www.microxsolutions.com/mobile-development.php --Ronz(토크) 05:56, 2010년 1월 19일(UTC) 링크가 포함되어 있다.

여기 문제의 편집이 있다.16분 후에 되돌렸다.게리 킹 (대화) 05:59, 2010년 1월 19일 (UTC)

그렇게 빨리 잡아서 잘했어.캐시된 템플릿을 본 것 같아. --Ronz (토크) 06:05, 2010년 1월 19일 (UTC)

PrefixIndex transloclations가 좀 우스운 것 같음

나는 위키피디아에서 다음과 같이 보았다.관리/Bwilkins 2에 대한 요청:{{Special:Prefixindex/Wikipedia:Requests for adminship/Bwilkins}}원형 링크를 굵게 볼드하지 않는 것 같다(즉, Bwilkins 2 RfA 내에 Bwilkins 2 RfA에 대한 링크가 있지만, 그만큼 볼드한 것이 아니라 일반 링크로 나타난다).이것은 통상적으로 일어나는 것과는 다르다(예:[[Wikipedia:Village pump (technical)]] 이 페이지에서 위키백과:위키백과 대신 마을 펌프(기술):마을 펌프(기술)왜 그런지 아는 사람? rʨanaɢ^talk/_contribs23:59, 2010년 1월 17일 (UTC)

AFAIK, 만약 당신이 이전 RfAs의 목록을 언급한다면, 이것은 일어날 수 있는 일이다 - 그것은 템플릿 때문이다.목록의 페이지에 대한 링크가 굵게 표시되지 않는 이전 RfA(2/3위)를 볼 수 있다.다른 링크를 의미했다면, 아마 알거야.Ale_Jrb^talk 00:04, 2010년 1월 18일(UTC)

잘 모르겠는데...나는 왜 Bwilkins 2에 대한 링크가 그 자신의 페이지에 대담하지 않은지 이해할 수 없다.rʨanaɢ^talk/_contribs00:09, 2010년 1월 18일(UTC)

특별한 페이지의 링크를 포함하고 있기 때문이다.변환된 경우 특수:접두사 색인은 해당 색인이 있는 페이지 목록(즉, 위키백과로 시작하는 모든 페이지:관리/Bwilkins) - 그러나 이것들은 일반적인 링크가 아니며, 그들이 있는 페이지에서 대담하게 행동하지 마십시오.Ale_Jrb^talk 00:13, 2010년 1월 18일(UTC)

아, 그래. 난 방금 특별하다고 생각했어.PrefixIndex는 변환된 템플릿(내브박스 등)처럼 작동했지만, 특별했나 봐.rʨanaɢ^talk/_contribs 00:18, 2010년 1월 18일(UTC)

비밀은 해피멜론 10:58, 2010년 1월 19일 (UTC)이라는 제목에 있다.

NY 타임즈 내용

뉴욕타임스가 무료 콘텐츠 제공을 중단하고 '메탈링(metered)' 결제 시스템을 설치할 예정이라고 뉴욕 매거진이 보도했다.위키백과를 참조하십시오.웹 사이트를 사용하여 NY Times 기사가 페이월 뒤로 사라지기 전에 위키피디아에 기사를 보관하는 방법에 대한 정보 제공.--Blargh29 (토크) 22:36, 2010년 1월 18일 (UTC)

물론 NYTimes 기사는 온라인에 있든 없든 여전히 유효한 언급이다.— 칼 (CBM · talk) 02:20, 2010년 1월 19일 (UTC)

실제로. 참고문헌이 다른 곳(NYT 스토리를 실은 다른 뉴스 사이트, 마이크로필름 아카이브 등)에서 참고문헌을 확인할 수 있는 충분한 정보를 포함하고 있는 한, 그것은 여전히 완벽하게 유효하다.또한, 이것이 역사적 기록 보관소에 적용될 것인지 아니면 아주 최근의 내용에만 적용될 것인지는 확실하지 않다.1900년 이전의 신문 기록 보관소가 인터넷에서 공개적으로 이용할 수 있는 것이 많지 않기 때문에, 나는 사실 현재의 보도보다 그 점에서 더 많은 활용을 얻었다.— 가비아 임머 (대화) 04:28, 2010년 1월 19일 (UTC)

참고문헌이 여전히 유효하다고 해서 우리가 그들에게 WP를 허용해야 한다는 뜻은 아니다.망각의 링크로트.또한, NY 타임즈 URL은 거의 쓸모없게 될 것이다.--Blargh29 (토크) 08:09, 2010년 1월 19일 (UTC)

링크로트에 대해 동의했어그러나 그들이 아카이브 기사에 사용하고 있는 것과 같은 시스템을 사용한다면, 당신은 여전히 페이월 뒤에 있는 기사의 URL에서 기사의 요약(및 제목)을 볼 수 있을 것이다.---신부 구스 (토크) 09:26, 2010년 1월 19일 (UTC)

페이지 렌더링 문제를 일으키는 이미지 맵 - 이 단순한 변경으로 인해 어떻게 이렇게 큰 문제가 발생하는가?

이전에 이미 다뤘다면 미리 사과드립니다만, 작은 변화로 인해 수백 개의 문자와 섹션에 다음과 같은 텍스트가 표시될 수 있다는 것을 알게 되었다."?uniq216fca307a11cbc6-nowiki-00000015-qinu?"보통 페이지에서는.문제는 IE와 파이어폭스 둘 다에서 발생하기 때문에 브라우저에 의존하지 않는다고 생각한다.

예를 들어, 도움말 페이지의 이전 버전을 보십시오.쉬운 템플릿 문제 아래의 모든 섹션은 제목이 소문자로 바뀌고 섹션 편집이 비활성화되며 일부 섹션의 데이터가 대량 삭제되는 등 영향을 받는 것으로 보인다.예를 들어, 편집 모드에서 긴 대화를 볼 수 있음에도 불구하고 이 섹션이 얼마나 짧은지(새 소문자 제목 포함)를 보십시오(참고 - 이 섹션의 변경 사항은 없지만, 이제 모든 것을 볼 수 있고 제목이 다시 적절한 경우).지난 6개월 동안 누군가 추가한 악성코드를 내 마지막 편집에서 볼 수 있는데 문제를 해결한 것 같다.(중요한 부분은 이 코드가 영향을 받는 대화가 이루어지기 훨씬 전에 추가된 섹션에 있다는 것이다.)

정말 무서운 것은 이 데이터가 완전히 삭제되어 다른 페이지의 "여기 어떤 링크" 섹션에 다른 WP 페이지에 대한 링크가 포함되어 있다면 도움말 문서의 숨겨진 텍스트에 링크가 있는지조차 알 수 없다는 것이다.아마도 그것은 분명하지 않을 것이다 - 그리고 나는 이것이 얼마나 이상하게 보이는지에 대해 계속 말할 수 있지만, 나는 만약 이것이 큰 문제가 아니라면 전문가들이 나를 진정시킬 수 있도록 먼저 주제를 시작하고 싶다. 7 04:11, 2010년 1월 19일(UTC)

"유니크"는...Quinu' 문자열은 스트립 마커로, 파서가 "더 복잡한 내용이 여기에 들어갈 것"이라고 말하기 위해 삽입하는 자리 표시자.여기서 일어나는 일인 스트립 마커 노출은 MediaWiki에서 잘못된 형식의 코드가 파서를 재설정하게 하고, 어떤 스트립 마커가 어떤 특수 콘텐츠와 일치하는지 기억을 잃을 때 발생한다.스트립 마커 노출에 대한 공개 버그가 있는데, 이 버그를 정확히 알고 있다면, 이 버그를 게시할 수 있다.해피멜론 10:27, 2010년 1월 19일 (UTC)

Happy-mellon 고마워 - 문제를 일으킨 것은 단지 이미지맵 코드(아마도 다른 태그들과 함께)였던 것 같다.적절한 버그리스트를 알려주면 거기서 내 연구 결과를 언급할께.다시한번 감사합니다. 7 23:41, 2010년 1월 19일 (UTC)

서버 시간

나는 이 질문을 어디서 해야 할지 몰라서 여기서 해봐야겠다고 생각했다.

서버 시간은 지리적 위치(즉 플로리다?)에서 시간으로 설정된다.이건 좀 지구중심적이지 않아?WP는 세계적이기 때문에 시간을 GMT로 설정하는 것, 즉 국제 날짜 라인의 시간을 더 좋게 설정하는 것은 말이 되지 않는다.여기 뉴질랜드에서 우리는 태양을 본 첫 번째 나라들 중 하나이다. 결과적으로 나는 MY date로 날짜 관련 페이지를 만들 수 없다.나는 가끔 이런 차이 때문에 봇에게 반칙을 했다. - 앨런 리프트 (토크) - 06:48, 2010년 1월 19일 (UTC)

시간대는 이미 Special(특수)으로 설정)으로 설정했을 겁니다.기본 설정 - 적어도 로그 및 토크 페이지 서명이 로컬 표준 시간대에 표시되도록 도와준다.하지만 나는 네가 날짜 관련 페이지를 만드는 데 방해가 되는 데 어려움을 겪고 있어.현재 당신이 하는 것이 차단되고 있는 것에 대한 예를 들 수 있는가?고마워. 7 07:16, 2010년 1월 19일 (UTC)

조금 전의 일이었고 내가 정확히 기억한다면 그것은 유지 범주였다.나는 그렇게 차단되지는 않았지만 내 편집이 수정된 것 같아.내 기본 설정은 +12.00hrs. -- Alan Lifting(대화) - 07:49, 2010년 1월 19일(UTC)

서버는 GMT와 비슷한 UTC로 설정되어 있다. 위키피디아는 전 세계에 서버를 두고 있기 때문에 모두 현지 시간으로 설정될 수는 없다.Graham87 10:51, 2010년 1월 19일 (UTC)

에디툴스: 라틴 문자 순서를 개선하자는 제안

편집자들은 다소 긴 라틴 문자 목록(현재 AA á á icch ich ich ich ich ich ich ich ich ich es ri Ⅱ ... ... ... ...로 시작하는 것)을 합리화하기 위해 이 제안에 대해 발언하고 싶어할 것이다.

-노에티카!_⊥^{¡ɐɔıʇǝoT}– 07:36, 2010년 1월 19일(UTC)

추천된 자바스크립트 디버거?

나는 Firebug를 사용하여 모노북 스크립트(JavaScript)를 디버깅하려고 한다 - 행운을 얻지 못한다.다른 Firefox용 자바스크립트 디버거는 없으십니까?

고마워, 해리 다크스타해리 (토크) 2010년 1월 19일 (UTC) 14:51, 19

불벌레는 최고 중의 하나이다.당신은 또한 벤크만을 시도해 볼 수도 있는데, 벤크만은 또한 좋고 모질라에서 바로 그것이다.게리 킹 (대화) 2010년 1월 19일 18시 32분 (UTC)

일부 템플릿 코드에 대한 도움말 필요

{{cite 논문}}}에 ref 매개변수(다른 인용 템플릿에서 사용되는 것과 같이)에 대한 지원을 추가하려고 시도했다.그러나 내 코드가 작동하지 않는 것 같다.
{{#if {{{ref }}} id="{{anchorencode:{{{{ref}}}}}}}}}}}
누가 한번 보고 가능하면 고쳐줄 수 있겠니?고마워요.칼다리 (토크) 2010년 1월 19일 (UTC)

그 뒤의 결장.#if도움이 될 거야대수학자 18:04, 2010년 1월 19일 (UTC)

야호! 고마워! Kaldari (토크) 18:05, 2010년 1월 19일 (UTC)

보관 수정 도움말

그래서 나는 최근에 WP로부터 많은 링크들의 목록을 보관했다.DERM:MA Wikipedia_talk 페이지:위키프로젝트_Medical_Medical_Dermatology_task_force/Missing_articles/Archive_1#Required_Redirects. 그러나 아카이브된 논의는 초기에 "내용" 지수를 가진다.어떻게 제거하지?미리 고마워! ---kilbad (대화) 18:24, 2010년 1월 19일 (UTC)

고정 게리 킹 (대화) 2010년 1월 19일 18시 30분 (UTC)

위키^베타.

Wiki^beta 테스트!강력한 템플릿 및 참조 숨기기 기능과 실제 Wikicode 파서를 통해 제공되는 새로운 이미지 미리 보기 기능 및 WYSIWYG 테이블 편집 기능이 곧 출시될 예정!Firefox 3.6 릴리즈 이후 다른 제품들이 메인 릴리즈를 기다리는 동안 지금 차세대 편집을 경험해 보십시오.*

기본 설정에서 Wiki를 가젯으로 사용하지 않도록 설정하고 "importScript('사용자:Cacycle/wikEd_dev.js';" 스킨.js 페이지로 이동하여 Shift-Reload를 누르고 즐기십시오.그리고 Wiki 토론 페이지에 당신의 의견을 남겨라.잊지 말고 버튼을 눌러봐...

(*Firefox 3.5 버그 519076은 길고 강조된 텍스트의 추가를 다소 느리게 한다. wiked는 Internet Explorer나 Opera에서는 작동하지 않는다.또한, '새로운 섹션' 편집에 버그가 있다는 것을 방금 알아챘는데...) 캐시클 (토크) 23:13, 2010년 1월 19일 (UTC)

문제를 확인해줘서 고마워, 그들은 하루종일 나를 미치게 했어! – ukexpat (대화) 02:34, 2010년 1월 21일 (UTC)

일부 URL을 자동으로 수정하시겠습니까?

지난 6개월 동안 한 홍콩 신문사가 리디렉션을 남기는 것을 귀찮게 하지 않고 컨텐츠 관리 시스템 URL을 약간 변경하여, 이들에 대한 오래된 링크가 모두 깨졌다.나는 이것이 봇에 의해 자동으로 고쳐질 수 있다고 생각하지만, 누가 이미 이 선들을 따라 무언가를 할 수 있는 봇을 가지고 있는지 모르겠다.

기본적으로 이전 형식의 링크

http://www.thestandard.com.hk/archive_news_detail.asp?pp_cat=&art_id=35072&sid=&con_type=1&archive_d_str=19970806

다음이 됨:

http://www.thestandard.com.hk/news_detail.asp?pp_cat=&art_id=35072&sid=&con_type=1&d_str=19970806&sear_year=1997

즉, archive_news_detail.asp는 news_detail.asp가 되고, archive_d_str은 d_str이 되며, d_st에서 처음 4자만 나오는 새로운 매개변수 sear_year가 필요하다.수동으로 작업하는 예를 보려면 여기를 참조하십시오.조언은?고마워, 택시 (대화) 06:48, 2010년 1월 20일 (UTC)

위키백과:봇 요청 페이지가 도움이 될 수 있다.조시 패리스 07:35, 2010년 1월 20일 (UTC)

만약 다른 사람들이 없다면 나는 이것을 할 수 있다.Rjwilmsi 11:55, 2010년 1월 20일 (UTC)

Alt Gr이 제대로 작동하지 않음

이것은 위키피디아에 문제가 있는 것이 아니라 내 쪽의 문제일 수도 있지만, 어떤 해결책은 여전히 환영할 만하다.수작업으로 사인을 하려고 하면 ~~~대신~~~~~~~~~~를 받는다.마찬가지로 {}이(가) 아닌 {~}을(를) 받는다 이것은 오늘에야 시작된 일인데, 이런 일은 처음이었다.나는 Azerty 자판, 벨기에어 레이아웃, Firefox 3.0을 사용하고 있으며, 모든 것이 예를 들어, 정상적으로 작동한다.마이크로스프트 워드.좋은 생각 있어?프람 (대화) 2010년 1월 20일 12시 30분 (UTC)

위키백과를 로그아웃하고 편집하면 어떻게 되는가?위키백과 외부의 Firefox에서는 어떤 일이 일어나는가?프라임헌터 (대화) 13:49, 2010년 1월 20일 (UTC)

Alt Gr을 통해 데드 키에 액세스할 수 있도록 키보드 레이아웃을 설정한 것 같군.예를 들어 "Belgian Extended"를 참조하십시오.Windows(윈도우)를 사용하는 경우 응용 프로그램별 설정이 될 수 있다.OrangeDog (1998 • •) 13:58, 2010년 1월 20일 (UTC)

답장 고마워.로그아웃된 편집은 도움이 되지 않는다.위키백과 밖에서 편집하는 파이어폭스(예:구글 검색)도 같은 결과를 주기 때문에 위키백과 문제가 아니다.키보드와 언어 설정으로 좀 더 실험해 볼게, 아마 무심코 바꾼 것 같아.Fram (토크) 14:09, 2010년 1월 20일 (UTC)

좋아, 기본 언어 변경, 다시 시작, 이제 문제 해결.고마워!프람 (대화) 2010년 1월 20일 14:29 (UTC)

누락된 페이지 크기 도구

해결됨

나보다 여기 사람들이 더 많이 알고 있는 것 같아서 내 토크 페이지에서 이것을 베끼고 있어.루어피쉬 °^° 13:35, 2010년 1월 20일(UTC)

설명할 수 없는 이유로 "페이지 크기" 도구가 내 왼쪽 도구 상자에서 사라졌다.지금처럼 편집 모드에 있을 때 데드링크로 다시 나타나지만, 그렇지 않으면 사라졌다.어떻게 돌려받을 수 있는지 조언해 주시겠습니까?나는 그것이 꽤 필수적인 도구라고 생각한다.귀찮게 해서 미안해.Brianboulton (대화) 10:55, 2010년 1월 20일 (UTC)

아직 거기 있고 날 위해 일하고 있어 그리고 그건 너의 모노북 js에 있어혹시 최근에 옛 모노북에서 벡터 스킨으로 바꾼 건 아닐까? - 킹핀¹³ (토크) 13:40, 2010년 1월 20일 (UTC)

고마워, 브라이언은 그 문제가 이제 해결되었다고 보고했어.Ruhrfisch °^° 18:39, 2010년 1월 20일(UTC)

사용자 기여도 분석 도구

안녕, 나는 내 사용자 페이지를 재설계하는 중이야.나는 사용자의 기여를 분석하는 도구가 있다는 것을 알고 있다.중기적으로는 올해 말 10K 편집에 성공하면 관리 도구 상자를 요청하고 싶어질지도 모른다.이미 존재하는 것 이상으로 내가 한 일에 대한 분석을 사용자 페이지에 올릴 수 있다면 좋을 것이다.내가 생각할 수 있는 중요한 분석적 차원은 다음과 같다.

• 어떤 글과 함께 제공되는 토크 페이지가 가장 많이 편집되거나 가장 실질적인 편집을 했는지,
• 메인스페이스, 기사토크 공간, 사용자토크 공간 등에서 내가 편집한 부분이 몇 퍼센트인가.
• 내가 편집한 것들 중 어떤 부분이 더 큰 비중을 차지하는지 말이야

사람들은 이러한 목적을 위해 어떤 도구를 추천할 것인가?내가 생각지도 못한 것에 대해 네가 추천할 만한 다른 것이 있니?고마워--피터 코언 (대화) 23:16, 2010년 1월 20일 (UTC)

• http://toolserver.org/%7Esoxred93/count/index.php?name=Peter_cohen&lang=en&wiki=wikipedia –2010년^talk 1월 20일(UTC)

• • 좋아 보이는 OO야, 고마워.더 많은 기사를 기록하는 ANY 도구?--Peter cohen (talk) 00:13, 2010년 1월 21일(UTC)

• • • 아, 이제 어떻게 하는지 알아냈어.고마워.---피터 코헨 (대화) 00:20, 2010년 1월 21일 (UTC)

TOC가 계속 무너지고 있음

이것은 아마도 간단한 해답이 있을 것이다. 그러나 최근에 나의 TOCs는 디폴트로 열리지 않고 디폴트로 접힌 것으로 계속 나타난다.이게 내가 한 짓이야?내가 여기저기 물어봤지만 다른 사람들은 대부분 그것을 보지 못하고 있다.Gigs (talk) 05:19, 2010년 1월 21일 (UTC)

만약 당신이 TOC를 붕괴시킨다면, 그 후에 그것들은 모두 붕괴된 것처럼 보일 것이다.한 번 더 확장하면 모두 한 번 더 확장된다.더 이상 확장 상태를 유지하지 않는 경우 브라우저의 캐시 및 쿠키를 지우십시오.게리 킹 (대화) 05:56, 2010년 1월 21일 (UTC)

이동-툴 Rdr 옵션

이동 도구 페이지에는 이동 페이지에 대한 Rdr 또는 이동 중인 두 페이지에 대한 Rdr 생성을 억제하는 옵션이 포함되어 있다.보통 옮길 만한 기사에는 토크 페이지가 있지만, 이동된 페이지의 제목을 대신할 메인 네임스페이스 페이지는 처음에 어떤 대화가 필요하지는 않을 것 같다.나는 이 상황에 다양한 방법으로 대응해 왔다.나에게 일어나는 모든 선택의 범위는 다음과 같다.

1. 세 개의 상자를 모두 선택한 후, 결과가 나오는 대화 페이지 Rdr을 삭제하십시오.
2. create-Rdr(빨간색 경고 msg에서 "삭제됨" 페이지를 다시 만든다는 표시)의 선택을 취소하고 새 Dab 페이지, 새 기본 주제 기사 또는 필요한 Rdr을 생성하여 새로운 기본 네임스페이스 페이지의 기록을 시작하십시오. *
3. 대화 페이지 이동 선택을 취소한 다음 대화 페이지를 별도로 이동, 동일한 "이동 이유"를 복사하고 만들기-Rdr 선택을 취소하십시오.
4. 세 개의 상자를 모두 선택한 후 즉시 토크-pg Rdr을 편집하여 소프트 Rdr로 변환
5. 세 개의 상자를 모두 체크한 후, 토크-pg에서 대화를 시작할 때, 부드러운 Rdr로 시작하도록 편집하기 위해 누군가에게 의지하십시오.

*^{Note re point 2 above -- the No-Move-tool-Rdr option}
BTW, 일단 새로운 메인 네임스페이스 페이지가 생성되면, 그것의 편집 내역은 삭제될 기미를 보이지 않지만, 그것의 공개 로그 페이지는 예를 들어 보여준다.

아웃그룹을 아웃그룹으로 이동(중복) [리디렉션되지 않음]

(옵션 2)에 따라) 토크 페이지가 처리되지 않은 채로 남겨진 경우, (저장된 경우) 세션의 첫 번째 편집 페이지에는 유사한 빨간색으로 표시된 경고 msg가 있다(비슷한 경우에만, bcz "Talk:"가 두 링크에 적절하게 표시됨).URL을 편집하거나 편집 페이지에서 팝업 도구를 사용하여 도달할 수 있는 동일한 msg(이 페이지에 대한 수정 내역이 없음)가 기록 페이지에 표시되며, 팝업 메뉴에서 "대화"를 누르고 "이력"을 클릭하여 팝업을 통해 메인 네임스페이스 페이지로 이동하는 세 번째 경로가 있다.토크 페이지의 메뉴가 뜨면.

마지막 2개만 다른 토크 페이지의 기존 링크를 끊지 않도록 주의하십시오. 이러한 링크는 수리를 위해 편집 이력에 대한 (간단하거나 광범위한) 협의가 필요할 수 있다.
곰곰이 생각해 보면, 즉각적인 소프트 Rdr이 올바른 접근법이라고 생각하는 경향이 있다(소프트-Rdr only-필요할 때에만, 특히 한 페이지의 토크를 자주 시작하는 많은 토론 시작 편집자들에게는 일어나지 않을 것이다; 토크 페이지 콘텐츠로서의 하드 Rdr은-- 잠시 Rdr에 불과했던 메인 네임스페이스 페이지의 경우-- lea의 원칙을 위반한다.놀라움, 그리고 사실 사용자 측에서 완전한 좌절감을 야기할 수 있다.기사에 대한 R'drn은 종종 놀랍지 않고 & "Rdr'd from..." 통지는 해를 끼치지 않고 눈에 띄지 않을 수 있다. 이와는 대조적으로 Rdr'd 메인 네임스페이스 페이지가 해당 비 Rdr'd 메인 네임스페이스 페이지와 밀접하게 연관되어 있는 대화 페이지는 "악과 마법의 구별"이 될 수 있으며 위키 편집자가 아닌 사람에게 매우 부적절할 수 있다.
나는 VPT에 와서 Rdrs가 서로 분리될 수 있도록 메인 네임스페이스와 토크 공간을 만드는 것을 제안하려고 한다.만약 다른 사람들이 소프트 Rdrs에 대한 나의 새로운 통찰력을 지지한다면, 나는 최소한 이동 도구는 주 네임스페이스/토크 페이지 통합 이동이 요청될 때마다 WP:소프트 리디렉션과 같은 것으로 주의를 끄는 빨간색 메시지를 가질 것을 제안한다.
이동 도구가 평범한 "하드"가 아닌 부드러운 RDR을 남겨두기 위해 Rdr(그리고 "하드" Rdr에 대한 명시적인 요청 없이)의 명시적인 억제 없이 토크 페이지가 이동될 때마다(그리고 "하드" Rdr에 대한 명시적인 억제 없이) 사실 좋은 생각이 될 수 있다.
--Jerzy•t 23:17, 2010년 1월 20일(UTC)

Tl;dr, 리디렉션은 그냥 놔둬.그것들은 싸다.–xeno^talk 23:19, 2010년 1월 20일(UTC)

• 색칠을 해라
  X 미해결 상태
  -- 이미 너무 많은 세부사항을 알려줬을 것이고, 단순히 다음과 같이 반복할 것이다.TK pgs는 유해하다고 여겨지는 다른 기사의 논의에 동반되는 기사와 Rr'g를 논의해야 한다.
  --Jerzy•t 18:14, 2010년 1월 21일(UTC)
  

어렵게 굴려는 것은 아니지만, 아직도 그 문제를 이해하지 못하고 있다.기사로 리디렉션하면 해당 기사의 토크 페이지로 리디렉션되는 리디렉션의 토크 페이지가 있다.그래서? –xeno^talk 18:20, 2010년 1월 21일(UTC)

PDF 파일 클릭 문제

파일 클릭:Apolo 11 Tapes Report.pdf와 "open PDF"는 Adobe Reader를 빈 페이지와 오류 메시지와 함께 불러온다."파일:"을 입력하는 경우Apolo 11 Tapes Report.pdf"가 작동하는 검색 상자에 입력된다.이거 벌레야?Bubba73 , 00:20, 2010년 1월 21일 (UTC)

응, 문서나 변환 과정에 뭔가 문제가 있어.다운받으면 글씨가 흐릿하다.파일을 "검색"한다는 게 무슨 뜻인지 이해가 안 가지만, 그 페이지로 다시 돌아오게 될 거야.게리 킹 (토크) 02:25, 2010년 1월 21일 (UTC)

"파일:"을 입력하는 경우검색/이동 상자에서 "시작"을 클릭하고 "시작"을 클릭하십시오.거기서 그것을 클릭하고 "PDF 열기"를 클릭하면 작동이 되고 텍스트가 선명해진다.오류는 파일 클릭 시:Apolo 11 Tapes Report.pdf 다음 "PDF 열기".Bubba73^{(Who's attacking me now?)}, 02:31, 2010년 1월 21일 (UTC)

네가 말한 대로 검색창을 통해 파일로 가서 파일을 다운받았는데 텍스트가 여전히 흐릿하게 보인다.어쨌든 왜 그 방법이 다른 결과를 반환하는지 이해가 안 가.게리 킹 (대화) 02:38, 2010년 1월 21일 (UTC)

파일에서 보기:아폴로 11 테이프 보고서.pdf, 텍스트는 흐릿해 보이지만 다운로드 했을 때는 그리 많지 않다.그러나 파일 클릭 시 (적어도) 클릭할 때 아무 것도 표시되지 않는 문제가 된다.Apolo 11 Tapes Report.pdf 다음 "PDF 열기" - 빈 페이지와 Adobe Reader 오류 메시지.오류 메시지가 표시되십니까?(나뿐일지도 몰라)Bubba73 , 02:44, 2010년 1월 21일 (UTC)

http://upload.wikimedia.org/wikipedia/commons/a/a4/Apollo_11_Tapes_Report.pdf을 클릭하셨나요?흐릿하지 않다.Anness, —mattisse (Talk) 02:46, 2010년 1월 21일 (UTC)

Bubba, 나는 오류 메시지를 받지 않았지만, 내가 너와는 다른 컴퓨터 설정을 사용하고 있기 때문에 그럴 가능성이 가장 크다(Mac에 있고 PDF 파일을 읽기 위해 Preview.app을 사용하고 있다).어쨌든 위의 링크에서 직접 PDF 파일을 열면 텍스트가 여전히 흐릿하다.그러나 오류 메시지는 없다.게리 킹 (대화) 02:48, 2010년 1월 21일 (UTC)

위의 링크를 클릭하면 된다.나는 Firefox에 문제가 있지만 IE에는 문제가 없다.WP의 베타 버전은 문제에 영향을 미치지 않는다.Bubba73^{(Who's attacking me now?)}, 02:51, 2010년 1월 21일 (UTC)

해당 링크를 클릭하면 PDF 파일을 읽을 수 있는 PDF 파일이 표시되면 설정에서 문제가 발생하는데, 이는 파일로부터 PDF를 다운로드하려고 할 때 브라우저와 동일한 링크이기 때문이다.아폴로 11 테이프 보고서.pdf.게리 킹 (대화) 02:53, 2010년 1월 21일 (UTC)

나는 Firefox에 문제가 있고 그 안에 PDF를 위한 애드온을 사용하고 있다.Bubba73 , 03:21, 2010년 1월 21일 (UTC)

흠, 파이어폭스를 사용하는데, 내가 보기엔 꽤 확실해 보이는데.우지 (토크) 22:19, 2010년 1월 21일 (UTC)

그렇다면 내가 가지고 있는 Firefox PDF 추가 기능에 문제가 있을 것이다.Bubba73^{(Who's attacking me now?)}, 22:34, 2010년 1월 21일 (UTC)

그럴 수도 있지, 나는 그런 추가 기능이 없어.우지(토크) 23:04, 2010년 1월 21일 (UTC)

테이블에 대한 도움 필요

내 샌드박스에서 잘 작동하는 테이블을 만들었는데, 의도한 기사에 올려놓으려고 하면 엉망이 돼.문제는 테이블의 배경색(부드러운 파스텔 그린)을 그대로 유지하고 싶고, 또한 어두운 초록색 테두리를 갖고 싶다는 것이다.그러나 기사에 저장해 놓으면 테이블 아래 모든 것을 짙은 녹색 테두리로 감싸고, 기사의 아랫부분을 연한 파스텔 녹색으로 채운다.나는 내가 생각할 수 있는 모든 것을 하려고 노력했고, 몇 시간 동안 그것에 대해 연구해왔는데, 모든 것이 유용하다는 것을 알고 있었다.테이블 디자인에 대해 아는 사람 중에 이것을 볼 시간이 있는 사람?정말 고마워!여기 내 샌드박스가 있다.사용자:Saukkomies/My Sandbox

그리고 여기 제대로 작동하지 않는 기사가 있다.쿠쿠텐리-트리필리아 문화의 집 태우기

거기 도착하면 테이블이 보일 거야, 놓치면 안 돼.제목:집 태우는 연습을 한 신석기 문화 시대표 고마워! --Saukkomies 06:24, 2010년 1월 21일 (UTC)

문제는 원래 코드에 있기 때문에 샌드박스와 기사 둘 다에서 사실상 '파쇄'된 겁니다.내가 고쳤다.게리 킹 (대화) 08:17, 2010년 1월 21일 (UTC)

게리 정말 고마워!당신의 도움에 깊이 감사한다. :) --Saukkomies 01:39, 2010년 1월 22일 (UTC)

곱슬 가새로 둘러싸인 선으로 시작하는 템플릿을 변환할 때 추가 선

어떤 이유에서인지 사용 중인 모든 곳에 {{NYinttop} 바로 앞에 추가 라인이 추가된다.마찬가지로 이 {{Jcttop} 개정도 오늘 아침 해결책이 떠오르기 전까지 똑같이 했다.이것은 아마도 미디어위키 버그일 것이다, 그러나 그 사이에 여분의 선을 없애는 데 사용될 수 있는 해결책에 대해 아는 사람이 있는가?(측면의 참고로, 추가 라인의 존재는 템플릿 앞에 템플릿과 단락을 구분하는 빈 라인이 있을 때만 눈에 띄지만, 해당 라인을 제거하는 것보다 더 나은 해결 방법을 제시해 주었으면 한다.) – TMF 12:06, 2010년 1월 21일(UTC)

잘 알려진 문제.템플릿이 있는 선으로 버그가 아니라, 뉴라인 캐릭터가 템플릿과 뉴라인 캐릭터를 가질 수 있을 겁니다.한 줄의 두 줄의 뉴라인 문자는 MediaWiki에 새로운 단락을 만든다.그래서 이것은 정말로 예상된 행동이다.이 문제를 "수정"하려면 새로운 라인 중 하나를 제거해야 할 것이다.만약 소프트웨어가 당신을 위해 이것을 고친다면, 텍스트를 "쓰레기"해야 할 것이다. 이것은 때때로 사람들은 새로운 선을 원하지만 그것을 만들 수 없기 때문에 원하지 않는 결과를 반환할 수 있다. 따라서 소프트웨어는 대신 지금과 같은 방식으로 행동한다.게리 킹 (대화) 2010년 1월 21일 17시 31분 (UTC)

그러나 템플릿에는 새로운 라인이 들어 있지 않은데, 이것이 여기서 이슈가 되고 있는 것이다.{{NYinttop}의 유일한 새로운 라인은 설명서가 있는 곳이며, "noinclude" 태그로 동봉되어 있으므로, 이 행은 절대 간과되어서는 안 된다.– TMF 17:39, 2010년 1월 21일(UTC)

편집으로 고친 것 같은데.게리 킹 (대화) 2010년 1월 21일 17시 53분 (UTC)

{{Jcttop}}}에 대해서는 예, {{NYinttop}에 대해서는 아니오.뉴욕 에리 카운티(225–256)의 카운티 노선 목록(225–256)을 참조하십시오. 뉴욕 주 에리 카운티 노선 목록(225–256)에서는 NYinttop을 모두 사용하기 전에 두 개의 새로운 노선이 존재하며, 기사에서는 템플릿 앞에 새 노선이 없음에도 불구하고 NYinttop을 모두 사용하기 전에 두 개의 새로운 노선이 존재한다.– TMF 18:03, 2010년 1월 21일(UTC)

여기 문서화된 버그나 특징을 언급하는 것 같아: 메타:도움말:뉴라인 및 스페이스#시작 시 자동 뉴라인: "다음으로 시작하는 템플릿*,#,:,;, 또는{ 시작 시 자동으로 새 줄 가져오기"(도움말:새로운 선 및 공간#시작 시 자동 뉴라인: "다음으로 시작하는 템플릿*,#, 또는:"시작할 때 자동으로 새 줄을 얻는다").이 경우, 더미 템플릿으로 출발 문자를 가리는 것이 도움이 될 수 있다.— 리차드국 (토크) 2010년 1월 21일 18시 20분 (UTC)

그래, 그럼 확실히 설명이 되겠지.이 사건에서 내가 어떻게 시작 인물을 가려낼 수 있을까?– TMF 18:36, 2010년 1월 21일(UTC)

버그/기능을 피하는 한 가지 방법은<table><tr><td>...</td></tr></table>위키 구문 대신 HTML 구문은 코드에서 줄 바꿈에 민감하지 않기 때문이다.

{{Jcttop}}}을(를) 좀 더 자세히 살펴보면, 문제는 일반 텍스트로 표 앞에 있는 선택 사항인 "전체 경로가 인..." 텍스트와 관련이 있을 수 있다고 생각한다.따라서 템플릿은 전송된 인수에 따라 텍스트(템플릿이 배치된 위치에 따라 인라인 또는 패러그라핑된 텍스트) 또는 블록 요소(테이블)로 시작할 수 있다.한 가지 단순화는 표 앞에 오는 것이 아니라 뒤에 오는 텍스트를 이동하는 것이다.그러나 당신이 테이블을 만들기 위해 다중 부품 템플릿을 사용하고 있다는 것을 고려하면 이것은 너무 복잡할 수 있다.또 다른 옵션은 텍스트가 테이블 제목 앞에 있는 선택적 행에 통합되어 템플릿이 표 형식 출력만 생성하도록 하는 것이다.

템플릿에는 현재 다음 코드가 포함됨:...<LINEBREAK>{ {}} class="wikitable"...이는 선택적 텍스트가 적용되는 경우, 위키피디트 시작의 시작 버팀대와 줄 바꿈으로 종료하고, 그렇지 않은 경우 위키피디트 시작 버팀대를 가진 다음, 개구부에서 버팀대 쌍을 닫은 다음, 파이프를 추가하여 테이블 버팀대(긴 #f의 참 또는 거짓 부분 중 하나)를 위키피디블 마크로 변환하는 것으로 보인다.up "{ "; 그리고 나서 'probable' 클래스를 적용....왜 그런지는 내게 분명하지 않다.{ 위키피디트 마크업은 초기 조건부 코드 이후에 전적으로 또는 (더 단순하게) 내지는 않고 닫는 교정기 쌍에 걸쳐 분할되었다.어쩌면 코드를 다음으로 바꿀 수도 있다.... }}<LINEBREAK>{ class="wikitable"...분명히 밝혀낼 거야

나는 여기서 일어나는 모든 일을 이해하는 척 하지는 않겠지만, 그것이 내가 고려할 선택사항이다.

— 리차드국 (토크) 2010년 1월 21일 19:37 (UTC)

음, {{jcttop}}}은 괜찮고, {{NYinttop}}}}}은(는) 후자의 템플릿이 모두 {{jcttop}에 대한 호출이기 때문에 현재 이슈가 되고 있는 것은 {{NYinttop}}} 입니다.NY가 명시했다.– TMF 21:36, 2010년 1월 21일(UTC)

Special을 이용한 실험:ExpandTemplates, 템플릿-a-템플릿이 버그/기능을 이끌고 테이블 앞에 한 줄 바꿈이 아닌 이중 줄 바꿈을 추가하는 것처럼 보인다.그런 점을 감안할 때, 내가 생각할 수 있는 다른 유일한 옵션은 관련 코드를 {{Jcttop}에서 {{Jcttop}까지 복사(또는 하위)하는 것이다.NYinttop}}을(를) 이중으로 변환하지 않고 거기서 수정한다.— 리차드국 (토크) 22:27, 2010년 1월 21일 (UTC)

T14974 입니다.해피멜론 00:08, 2010년 1월 22일(UTC)

좋아, 2년 동안 아무 해결책도 보이지 않고 열려있던 벌레야.*sigh* @Richardguan:대신 그냥 할 일은 {{jctint}라고 하는 것으로, 여분의 줄이 쟁점인 곳, 즉 산문을 따라 {{NYinttop}을 사용하는 곳, 즉 (여분의 라인의 존재는 중요하지 않은 곳)을 시작하는 곳이라고 생각한다.이것이 모든 면에서, 그리고 목적을 위한 해결 불가능한 문제라는 것은 유감스럽지만, 어쨌든 모두의 도움에 감사한다. – TMF 01:18, 2010년 1월 22일 (UTC)

사용자가 도구 상자에서 전자우편을 삭제하시겠습니까?

"전자우편 사용자"가 사용 가능한 사용자 페이지와 사용자 대화 페이지의 페이지 왼쪽에 있는 도구 상자(또는 다른 곳)에서 "전자우편 사용자"를 찾을 수 없는 것 같다.항상 Special을 사용할 수 있음:이메일을 보내는데 왜 항상 있던 툴박스에서 그것을 찾을 수 없는지 헷갈린다.나는 관리인이며 확실히 차단되지 않았고 개발자가 이메일 사용자 링크를 제거하기 위해 코딩을 변경했다는 얘기는 듣지 못했기 때문에 그것을 보지 말아야 할 이유가 없다.고마워, 밸리2시티^‽ 15:47, 2010년 1월 21일 (UTC)

아직도 보고 있어(적어도 네 페이지에서 봤어!) 파이어폭스에서...╟-TreasuryTag►directorate-16:28, 2010년 1월 21일 (UTC)

너의 사용자 페이지에 있는 "전자우편 사용자" 링크도 나에게 효과가 있어.먼저, 모노북.js 페이지를 비운 다음 해당 페이지에 설명된 대로 하드 리프레시를 수행하여 해결되는지 확인하십시오.게리 킹 (대화) 2010년 1월 21일 17시 34분 (UTC)

음, 아마도 구글 크롬의 물건일거야.Dell Tech가 현재 노트북에서 작업 중이기 때문에 다른 컴퓨터에서 작업 중이고 Firefox에서 한 번 업데이트/교체 작업을 수행했지만 사라졌고 IE에서는 작동하지 않았다.내 모노북에는 행정적인 것과 다른 도구들이 많이 있어서 뭔가 있을 수 있어.혹시 무슨 문제라도 있는지 한 번 살펴봐야겠다.고마워요.Valley2city 18:52, 2010년^‽ 1월 21일(UTC)

변환된 관련 변경 사항 피드 중단 섹션 헤더

위키백과에서:위키백과 간판포스트/뉴스룸, 관련 변경사항의 전달이 페이지의 모든 섹션에 대한 헤더를 파괴하기 시작했다. [3].이전에는 잘 작동했지만, 오늘날 페이지 헤더가 엉뚱하게 되었고, 그것들을 복원할 수 있었던 유일한 것은 그 초월된 피드를 제거하는 것이다.할프! —서명되지 않은 코멘트를 99.26.235.126 (대화) 19:52, 2010년 1월 21일 (UTC)

이것은 알고 있는 문제 bugzilla:16129 —TheDJ (대화 • 기여) 20:10, 2010년 1월 21일 (UTC)

CSS를 설정하지 않고 스타일 속성별로 링크 색상을 변경할 수 있는가?

나는 텍스트 색상을 조절할 수 있는 매개변수를 템플릿에 만들고 싶다.텍스트 항목은 기본적으로 연결되지 않는다.오히려 기본 배경은 상당히 깊어서 기본 연결 색 구성표를 읽기 어렵게 만들기 때문에 연결되지 않은 텍스트를 따라 링크 색상을 수정하는 것을 선택적으로 만들고 싶다.링크 색상을 스타일 속성이나 그런 것으로 변경할 수 있을까? -- 같은 보트 - 同舟(토크) 04:42, 2010년 1월 22일 (UTC)

모든 링크 안에 스타일 속성이 있는 스팬 태그를 붙이지 않고는 안돼, 내 머리 위에서. --Izno (토크) 06:15, 2010년 1월 22일 (UTC)

"pre" 문제 내부의 "nowiki"

이 코드를 사용하는 이유:

<스팬 스타일="흰색 공간:nowrap;"<nowiki][파일:{{{{PAGENAME} 엄지손가락 범례]</span></nowiki>

내부는 다음과 같은 결과를 초래한다.

<스팬 스타일="흰색-공간:노랩;"][파일:{{{PAGENAME} 엄지손가락 범례]</span>

편집 보기에서 예를 참조하십시오.

<스팬 스타일="흰색-공간:노랩;"][파일:{{{PAGENAME} 엄지손가락 범례]</span>

똑같지 않다.뭔가 잘못된 거 아니야?모스카 (토크) 23:37, 2010년 1월 21일 (UTC)

무엇을 달성하려고 하는지 확실하지 않지만, "사전" 대신 다음 중 하나를 사용하는 것은 어떨까? - 점묘사(토크) 23:51, 2010년 1월 21일(UTC)

<span style="white-space: pre; font-family: monospace; display: block;">[파일:{{{}PAGENAME} 썸 레전다]]</노위키>

결과=[[파일:{{]PAGENAME} 썸 레전다]]

아니면 그냥

<<nowiki>[파일:{{{{]PAGENAME} 썸 레전다]]</노위키>

결과=[[File:{{PAGENAME}} thumb Legenda]]

시도:

<스팬 스타일="흰색 공간:nowrap;"<nowiki][파일:{{{{PAGENAME} 썸 레전다]]</노위키>

즉, nowikis를 두 배로 증가시키는 것이다.편집창에서 보면 무슨 뜻인지 알 수 있어.해피멜론 23:57, 2010년 1월 21일 (UTC)

대답해줘서 고마워.난 해결책을 찾으려는 게 아니야내 말은 노위키는 정말로 "pre" 안에서 작동하는데, 다른 코드(<ref></ref>, </include only>, <blockquote></blockquote>, 테이블, wiki code...)는 보통 텍스트처럼 보여?Mosca (토크) 00:16, 2010년 1월 22일 (UTC)

옛날로 돌아가면 우리는 <프리> 태그 안에 있는 <노위키> 태그를 사용해야 했고, 그렇지 않으면 다른 모든 태그는 미디어위키에 의해 해석되었다.그래서 그런 이유로 <노위키> 태그는 보이지 않게 되어 있었기 때문에 보이지 않았다.나는 그 행동이 역호환성을 위해 유지되었다고 확신한다. 그렇지 않으면 많은 오래된 것.<pre><nowiki> ... </nowiki></pre>밖에 있는 사용법들은 갑자기 옛날 <노우키> 태그를 보여주었을 것이다.

실제로 <노위키> 태그를 보여주고 싶다면, 우리는 보통 이렇게 태그를 코드화한다: "<nowiki>". 예를 들어, 편집 창에서도 확인하십시오.

<노와키> 몇 통의 문자.</노위키>

물론 <프리> 태그도 <노위키> 태그의 기능성을 갖도록 업데이트한 지 몇 년이 되었으니, 그 안에 <노위키> 태그를 표시하도록 미디어위키를 업데이트해야 할 때가 아마 아닌가 싶다.

--David Göthberg (대화) 01:18, 2010년 1월 22일 (UTC)

설명해줘서 고마워.나는 안에 다른 <예비>가 없으면 잘 되었다.이 문제를 본 적이 없어서 이상하다.항상 배우다.모스카 (토크) 02:09, 2010년 1월 22일 (UTC)

<프리> 태그 안에 있는 <노와키> 태그를 보여줘야 할 정도로 희귀하기 때문에 아마 전에는 보지 못했을 것이고, 그런 예를 쓰는 편집자들은 대개 경험이 풍부하고 이미 그런 것을 다루는 방법을 알고 있다.

그런데, <프리> 태그 안에 있는 <프리> 태그를 보여주고 싶다면, 그 다음에도 같은 방법으로 <프리> 태그를 탈출한다.<pre>". The "<part는 단순히 "<"문자보다 낮은 문자에 대한 html 코드일 뿐이다.이에 대한 예가 있다.

<사전> 몇 가지 문자.</사전>

우리는 해시처럼 MediaWiki가 해석할 수 있는 모든 종류의 특수 문자를 삽입하기 위해 그러한 탈출을 사용한다.#" = "#", 공간 " " = " ", 파이프 " " = "|", 그리고 교정기 "{ }" = "{ } " 등등.우리는 이것을 템플릿 코드에 주로 사용한다.위키피디아는 물론 이것에 관한 몇 개의 글자가 있다.

--David Göthberg (대화) 10:54, 2010년 1월 22일 (UTC)

범주 교차점

카테고리에 포함되는 모든 기사 목록을 생성할 수 있는 방법이 있는가?

• 범주:참조되지 않은 모든 BLP 및
• 범주:인도(및 모든 하위 고양이)

그것은 인도어 위키피디아 주체가 자신의 관점에 해당하는 비소싱 BLP(최소한 인도 범주로 분류되는 BLP)를 검토하는 데 도움이 될 것이다.아베케다레 (대화) 2010년 1월 22일 15:07, (UTC)

위키백과:Category_intersection —DJ (대화 및 기여) 15:25, 2010년 1월 22일 (UTC)

안타깝다. 미디어위키 자체의 특징이 아니더라도 누군가가 요청하면 적어도 그런 리스트를 만들어 낼 수 있는 도구를 가지고 있기를 바라고 있었다.자원 봉사자 ? Abecedare (대화) 15:29, 2010년 1월 22일 (UTC)

WP처럼:범주 교차로 페이지에서 연결되는 CATSCAN은?나노닉 (토크) 15:42, 2010년 1월 22일 (UTC)

응. 방금 알았어.그것과 교차점 검색 도구를 시도하고 있다.아베케다레 (대화) 2010년 1월 22일 15시 59분 (UTC)

관심 있는 모든 사용자를 위한 업데이트:교차 검색 도구는 나에게 효과가 있었고 이 목록을 생성하는 데 사용되었는데, 현재 인도 위키백과 주제의 회원들에 의해 검토되고 있다.아베케다레 (대화) 23시 2분, 2010년 1월 22일 (UTC)

두 범주를 교차 참조

편집자가 카테고리처럼 두 개의 카테고리가 동일한 페이지를 볼 수 있는 도구를 알고 있는 사람:참조되지 않은 BLP 및 범주:2010년 1월 22일(UTC) 미국 작곡가 이키프 22:45(UTC)

WP를 살펴보셨습니까?CI 및 위키백과:캣스캔?– ukexpat (대화) 22:57, 2010년 1월 22일 (UTC)

이킵, 위쪽을 봐.아베케다레 (대화) 22:58, 2010년 1월 22일 (UTC)

너희들은 훌륭해, 신의 가호가 있기를.Ikip 23:06, 2010년 1월 22일 (UTC)

모든 템플릿 다운로드(해결 문제)

위키피디아 엔진이 설치된 내 사이트에 업로드할 위키피디아용 템플릿을 다운로드하는 방법을 알아내기 위해 3주 동안 많은 시간을 내 스스로 노력해왔고 나는 당황했다.나는 이미 위키피디아 토크에서 도움을 요청했다.위키프로젝트 템플리트 및 위키백과:위키프로젝트 템플리트 헬프 데스크가 나를 헬프 데스크로 보냈고, 헬프 데스크가 나를 여기로 보냈어...누가 나를 도와줄 수 있니?이거 할 줄 아는 사람 있어?Quando Omni Flunkis Moritati - (다른 모든 것이 실패하면 dead로 플레이) (토크) 19:19, 2010년 1월 22일 (UTC)

나는 네가 영어 위키백과에 있는 모든 템플릿을 너만의 위키로 원하는지 정말 의심스럽다.그러나 그럴 경우, 템플리트 네임스페이스에 페이지가 포함된 데이터베이스 덤프가 있다.특정 템플릿만 원하는 경우 특수:이 사이트에서 내보내고 "특별:자체 사이트에서 "수입". --MZMcBride (대화) 19:39, 2010년 1월 22일 (UTC)

말도 안 되는 소리인 거 알아...하지만 난 정말 그래.내가 그것들을 사용하든 사용하지 않든 나와는 무관하다.나는 지금 페이지들을 정리하고 있고, 그냥 참고자료들이 있는 페이지를 한 장 모아.그리고 Reflist 템플릿을 사용했다.그것은 효과가 없었다.내가 찾으려고 했던 다른 항목들은 분명히 위키백과의 템플리트에서 다루어졌었다.위키피디아의 일부인 것처럼 내 위키만 사용할 수 없다는 것은, 특히 템플릿에 의존하는 템플릿으로 답답하다.다른 템플리트가 필요한지 확인하기 위해 모든 템플리트를 조사하기 보다는, 템플리트만을 위해 내 서버에 최대 5~6GB의 공간을 두드려 그 번거로움을 해결하는 것이 낫겠다.그래, 나는 정말 모든 템플릿을 다운로드 받고 싶어.난 버리려고 노력했어나는 나에게 실제 파일을 줄 단 한 개의 덤프도 얻을 수 없다.회사, 집, 심지어 Mac 노트북에서도 PC를 구하려고 노력했다.아무 것도 없어요.좌절감을 넘어서는...확실히 누군가 쉽게 모든 위키백과 템플리트를 한 번에 잡을 수 있는 방향을 가지고 있다.내가 원하는 템플릿 하나하나를 연구해서 더 많은 템플릿이 필요하지 않도록 할 시간이 없어...이건 정말 쉬워.내가 반복했다는 걸 알아...답답해.도움말! Quando Omni Flunkis Moritati - (다른 모든 것이 실패하면 dead play) (토크) 20:12, 2010년 1월 22일 (UTC)

위키피디아를 기능하고, 보고, 느끼는 것을 설정하는 과정이 나쁘다는 것에 동의한다.위키미디아가 비교적 포괄적인 템플릿, 확장, 기타 여러 가지를 제공하는 미디어위키 버전을 출판하여 그것을 원하는 사람들에게 위키피디아와 비슷한 경험을 제공하는 것을 꼭 보고 싶다.하지만 그런 일이 일어나기를 바라는 것은 지금 너에게 도움이 되지 않을 거야.덤프 중에서 당신이 사용할 수 있는 가장 작은 것은 페이지-아티클인데, 여기에는 모든 템플릿이 포함되어 있지만, 모든 글과 이미지 설명도 포함되어 있다.bzip 압축이 적용된 5.4GB이며 압축되지 않은 100GB 이상으로 확장될 것이다.나는 방금 그 파일이 존재하는지 확인했고 너는 그것을 다운로드 할 수 있을 거야.브라우저들은 때때로 매우 큰 다운로드에 질식하지만, 만약 당신이 셸 액세스 권한을 가진 Linux 스타일 서버를 가지고 있다면, 나는 명령행에서 얻는 것이 항상 효과가 있는 것처럼 보인다는 것을 발견했다.즉, 파일을 얻었다고 가정할 때 불필요한 문서 내용을 많이 로드하거나(데이터베이스를 많은 RAM으로 백업하지 않는 한 권장하지 않음) 템플릿 페이지만 추출하기 위해 덤프를 필터링해야 한다.전반적으로 이러한 접근방식은 많은 작업이며, 쉬운 해결책과는 거리가 멀다.하지만 네가 정말 원한다면 그렇게 할 수 있어.

내가 사용한 대안(성공과 함께 거의)은 없지만 원하는 템플릿을 찾을 때마다 사용자 공간의 페이지에 유사한 Wikicode를 만드는 것이다(예: User:랜덤블링크/덤미.해당 템플리트 호출이 포함된 페이지를 저장한 후 특수:로 이동하십시오.내보내기. 추가 "사용자:다운로드해야 할 항목의 큰 상자에 임의로 "Randomblink/dummy"(또는 페이지 이름을 불러온 내용)를 입력한 다음 "템플릿 포함" 확인란을 선택하십시오.다운로드를 누르면 해당 페이지뿐만 아니라 해당 페이지를 렌더링하는 데 필요한 모든 템플릿(내보내기당 최대 1000개)이 포함된다.그런 다음 파일을 특수:사이트로 가져오면 해당 응용 프로그램에 필요한 템플릿이 로드된다.이렇게 하면 의존성을 직접 추적하지 않아도 된다.당신이 원하는 모든 템플리트를 복사하기 전에 그러한 다운로드가 여전히 많이 필요할 것 같지만, 그것은 여전히 덤프를 통해 모든 위키피디아의 템플리트를 복사하는 것보다 덜 어려울 것이다.드래곤즈 비행 (토크) 21:23, 2010년 1월 22일 (UTC)

글쎄, 몇 시간이 걸렸지만 나는 모든 위키백과 템플릿을 가져올 수 있는 XML 파일로 수집했어... 으악! 다시는 그렇게 하고 싶지 않아...음, 지금 수입중이야.어쨌든 하나, 둘 다 고마워.목사님 랜덤블링크 - 물어보면 믿게 될 것이다.(토크) 2010년 1월 22일 23:00 (UTC)

다른 사람들이 미래에 사용할 수 있도록 어딘가에 (어디에 있는지는 모르지만) 게시할 가치가 있을 것이다.OrangeDog (1998 • •) 15:16, 2010년 1월 23일 (UTC)

편집 상자 - 기호, IPA 등

기호, IPA, 그리스 문자 등을 선택할 수 있는 편집 상자 밑의 그 물건은 내게는 통하지 않는 것 같다.드롭다운 메뉴에서 관련 비트를 샅샅이 뒤지지만, 기호나 무엇이 올라오지 않는다.나는 윈XP에서 IE8을 사용하고 있다.던컨힐 (대화) 23:01, 2010년 1월 22일 (UTC)

빈 사용자:던컨힐/모노북.js, 그게 효과가 있는지 확인해봐.그런 다음 모든 가젯을 제거하십시오.그런 다음 다른 브라우저를 사용해 보십시오.게리 킹 (대화) 04:24, 2010년 1월 23일 (UTC)

그러나 우선 브라우저 캐시를 건너뛰어 "편집"을 추가하는 자바스크립트를 다시 로드하십시오.그리고 만약 당신이 당신의 개인 /monobook.js를 변경할 때, 당신은 보통 1분을 기다린 후, 당신의 브라우저 캐시를 우회하여 변경사항을 볼 필요가 있다.

--David Göthberg (대화) 2010년 1월 23일 (UTC) 10:54

캐시를 우회하는 것은 아무 소용이 없었다.던컨힐 (대화) 2010년 1월 23일 (UTC) 14:19

• 제대로 된 적이 없는 나의 모노북에는 '위키마르크'라는 것이 있었다.그것과 Ctrl+F5를 제거하면 기호를 선택할 수 있지만 이제 기호를 변경할 수 없다.던컨힐 (대화) 2010년 1월 23일 (UTC) 14:24

• • 그리고 나서 나는 나의 모노북을 블랭킹하려고 시도했다, 나는 어떤 기호/알파벳을 바꿀 수 있었지만, 나의 모노북을 위해 편집 화면에 있을 때, 그리고 내가 다른 페이지를 위해 그들의 막힘을 선택할 때에만 그것을 바꿀 수 있었다.그리고 위키파크와는 별개로 모든 것을 모노북에 복원했고, 이제 모든 것이 괜찮아진 것 같다.도와줘서 모두에게 고마워 :)★★★ 던컨힐 (대화) 14:38, 2010년 1월 23일 (UTC)

여기서 일어난 일은 아마도 던컨힐이 그의 /monobook.js를 편집하는 것과 브라우저 캐시를 바이패스하는 것 사이에서 1분을 기다리지 않았다는 것이었다.편집에서 새로운 버전의 자바스크립트와 CSS 페이지가 모든 위키백과 서버에서 이용될 때까지 종종 30-60초가 걸린다.그래서 그 전에 다시 로드하는 것은 보통 오래된 버전을 준다./monobook.js의 편집 미리보기에 있는 동안 현재 버전이 로드되므로 즉시 효과를 확인하십시오.

--David Göthberg (대화) 2010년 1월 23일 (UTC) 15:54

• 이제 다시 작동을 멈췄고, 작동한 이후로는 모노북이나 기계에 더 이상 아무 것도 하지 않았다. (DuncanHill (토크) 01:36, 2010년 1월 24일 (UTC)

검색할 때 이미지 없음

위키피디아의 어떤 이미지도 텍스트로 표시되지 않으며, 이 문제는 지난 몇 주 동안 발생했으며, 캐쉬를 삭제했지만 여전히 문제에 직면해 있다 —117.20.19.18 (대화) 04:42, 2010년 1월 23일(UTC)

웹 브라우저에는 이미지를 로드할지 여부를 선택할 수 있는 설정이 있다.그 설정을 해제했을 수도 있다.다른 웹사이트에 이미지가 보이십니까?

또 다른 가능성은 당신이 차단을 했을 수도 있다는 것이다.upload.wikimedia.org왜냐하면 그곳이 우리의 이미지들이 로딩되는 곳이기 때문이다.웹 브라우저에 "차단" 플러그인이 있으면 해당 플러그인을 확인하십시오.방화벽을 사용하는 경우 방화벽에서도 이러한 차단이 수행될 수 있으므로 거기서도 확인하십시오.

--David Göthberg (대화) 2010년 1월 23일 16:02, (UTC)

아니면 결과에 대한 이미지를 말하는 거니?그렇다면, 당신은 우리의 검색 기능 대신에 구글을 찾고 있을 것이다.또는 결과 페이지에서 다른 검색 모드 중 하나를 선택해야 한다. 기본적으로 모든 네임스페이스가 검색되는 것은 아니기 때문이다.위키백과를 참조하십시오.검색 중.—DJ (대화 • 기여) 17:04, 2010년 1월 23일 (UTC)

인터위키/인터언어 링크가 보안으로 변경되지 않음

기본적으로 {{sec 링크 자동} 동작이 아닌 이유는?보안 연결을 사용할 때는 믿을 수 없을 정도로 짜증 나, 인터위키/인터페이스 링크를 클릭할 때마다 보안되지 않은 연결에 빠지게 된다.예를 들면 다음과 같다.

• Wikinews(링크 자동 없음)
• 위키뉴스

현재 보안 연결을 사용하고 있는 경우 보안 링크로 디폴트하지 않는 것이 편리하다고 생각하지 않는다.스몰맨12q (대화) 2010년 1월 15일 19:25 (UTC)

왜냐하면 {{sec link auto}}는 실제로 이 문제를 해결하기 위한 bugzilla bugticket이 3년 이상 오래된 것이기 때문에 새로 도입된 템플릿이기 때문이다.이것의 대부분은 파서카체 btw와 관련이 있다.이 기능을 도입하려면 재단의 전체 페이지 세트가 캐시에 두 가지 모드로 저장되어야 함을 의미한다.일반 링크로 한 번, 보안 링크로 한 번.그것은 자원에 대한 투자를 필요로 한다.이것을 도와줄 수 있는 고객사이드 스크립트 btw가 있다.하나는 greasemonkey 대본이고, 다른 하나는 en.wp에 있는 대본인데 지금 찾을 수가 없어.—DJ (대화 • 기여) 20:15, 2010년 1월 15일 (UTC)

나는 얼마 전에 그리스에몬키 대본을 사용했다.그러나 Greasemonkey는 대부분의 윈도우 컴퓨터가 가지고 있는 IE가 아니라 파이어폭스에서만 작동한다.그 페이지들은 2개의 분리된 캐시에 저장되어야 한다는 것을 나는 알고 있다...위키미디어 재단은 왜 javascript를 사용하지 않는가?자바스크립트 솔루션을 만드는 것은 어렵지 않을 것이다... 또는 아마도 그것을 해결하기 위한 장치를 제공하는 것은 어렵지 않을 것이다.스몰맨12q (대화) 20:46, 2010년 1월 15일 (UTC)

(충돌 편집...헤헤, 스몰맨이 보이고 나도 같은 생각이야.)

내가 알고 있고 시험으로 알 수 있는 한:보안 서버의 사용자가 방문한 페이지만 추가 복사본으로 캐시된다.{{sec 링크 auto}}을(를) 사용할 때 이미 이러한 현상이 발생함.그리고 그 복사본은 아마도 보통 일주일 동안 보관되어 있을 것이다.보안 서버의 사용자 수가 적기 때문에, 그들이 캐시하는 페이지 수는 아마 그렇게 많지는 않을 것이다.

다른 스크립트를 테스트해 보았다.사용자:Anakin101/항상 securewikipedia.js.그것은 훌륭하게 작동한다. (그러나 몇몇 희귀한 종류의 링크에 대한 처리가 부족하다.)

"고객사이드"라고 하셨는데, 아이디어가 떠올랐었죠.보안 서버의 모든 사용자가 자동으로 스크립트를 로드하도록 만들 수 있어미디어위키 소프트웨어를 바꿀 필요 없이 완전히 고객사이드로 만들 수 있게 된 겁니다.그리고 그것은 여분의 캐싱을 유발하지 않을 것이다.물론 대본은 먼저 공식 위치에 복사되어야 하고, 여러분 중 몇몇은 자바스크립트 전문가들에 의해 업데이트/체크되어야 한다. (나는 그 대본을 이해할 수 있을 만큼 자바스크립트를 충분히 알지 못한다.)그리고 스크립트가 일종의 이스케이프 표시(일부 클래스가 있는 <스팬>)를 이해하여 스크립트가 일부 링크를 자동 변경하는 것을 막을 수 있다면 좋을 텐데, 때로는 보안 서버의 사용자에게 일부러 정상적인 링크를 보여주기를 원하기 때문이다.

--David Göthberg (대화) 20:52, 2010년 1월 15일 (UTC)

응 나도 비슷한 생각을 하고 있었어.우선 영어 위키백과에서 그것을 시험해 보는 것이 가장 좋을 것 같아.그라스몬키와 아나킨 대본이 둘 다 활동할 때 어떻게 되는지도 궁금하다...—DJ (대화 • 기여) 21:53, 2010년 1월 15일 (UTC)

그래서 무슨 일이 일어날까?스몰맨12q (대화) 20:00, 2010년 1월 17일 (UTC)

MediaWiki_talk:공통.js#Always_secure_위키백과 -DJ (대화 • 기여) 20:48, 2010년 1월 17일 (UTC)

링크해줘서 고마워.스몰맨12q (대화) 17:26, 2010년 1월 18일 (UTC)

MediaWiki:Common.js/secure.js는 이제 보안 서버에서 영어 위키백과를 사용할 때 자동으로 로드된다.—DJ (대화 • 기여) 20:54, 2010년 1월 21일 (UTC)

그렇다면 지금 {{sec 링크 오토}가 필요한가?그 템플릿은 쓸모없다고 표시해야 하는가?스몰맨12q (대화) 23:40, 2010년 1월 22일 (UTC)

우선 우리는 새로운 자바스크립트 수정이 얼마나 잘 작동하는지 좀 더 지켜봐야 한다.둘째로, 많은 학교, 직장, 도서관 등이 그들의 컴퓨터에서 자바스크립트를 비활성화하고 있고(브라우저를 해킹하는 많은 방법이 자바스크립트를 필요로 하기 때문에), 그리고 종종 보안 서버를 사용해야 하는 사용자들이 바로 그러한 사용자들이기 때문에, 모든 사용자들이 자바스크립트를 사용할 수 있는 것은 아니다.따라서 우리는 아마 메인 페이지("위키피디아 자매 프로젝트"와 "위키피디아 언어" 섹션)에 있는 {{sec 링크 오토}를 계속 사용해야 할 것이다.

그러나 다른 대부분의 장소에서는 앞으로 {{sec 링크 auto}}}을(를) 사용하는 것이 대부분 과잉 살상이다.문서와 위키피디아 업데이트:그들이 그것을 설명하도록 서버를 보호하라.

--David Göthberg (대화) 09:55, 2010년 1월 23일 (UTC)

또한 페이지에 변경해야 하는 모든 변경은 스크립트에 실행 시간을 추가한다(페이지의 URL을 단순히 "보기"하는 것 이상).sec 링크 오토로 고정된 모든 링크는 스크립트로 고정될 필요가 없으며 사이트를 보다 간편하게 사용할 수 있다.—DJ (대화 • 기여) 20:55, 2010년 1월 23일 (UTC)

그러나 {{sec 링크 오토}}을(를) 사용하는 것은 다른 비용뿐만 아니라 인적 시간 비용(매우 높음)이 있고, 위키백과 사용자가 일반적으로 효율적이지 않기 때문에 페이지 렌더링 시간이 증가한다.그리고 개발자가 버그를 수정하기 전까지(즉, 스크립트 서버측을 구현하기 전까지) 모든 것이 해결책임을 잊지 마십시오.— 디스펜서 21:38, 2010년 1월 23일 (UTC)

http://dumps.wikimedia.org/enwiki/20091128/ 링크에 덤프가 있는 버그가 있다.
그것은 https://secure.wikimedia.org/wikipedia/dumps/wiki/이 된다.
보안 서버에 있는 사용자는 http://dumps.wikimedia.org/enwiki/20091128/Smallman12q (대화) 23:48, 2010년 1월 24일(UTC)을 참조하십시오.

무시 목록에 추가됨그러나 브라우저 캐시를 제거해야 할 수 있다.—DJ (대화 • 기여) 01:54, 2010년 1월 25일 (UTC)

고마워, 다른 벌레가 나오면 알려줄게.스몰맨12q (대화) 02:03, 2010년 1월 25일 (UTC)

특수 페이지 문제

내가 알아챈 큰 문제가 있다.이 제품이 여기에 속하지 않는 경우 해당 위치로 옮기십시오.어쨌든 존재하지 않는 특수 페이지를 입력할 때마다 항상 "기본 페이지로 돌아가기"라고 쓰여 있다.자, 여기서 문제는 그전에 어떤 페이지에 있었든 간에 항상 그렇게 되어 있다는 것이다(그래서 만약 위키백과에 있다면, 예를 들어, 그것은 여전히 "메인 페이지로 돌아가라"고 말할 것이다).가능한 한 빨리 이것을 고쳐 주시오.고마워. --Hadger 04:03, 2010년 1월 21일 (UTC)

문제는 위키 소프트웨어가 방금 보고 있던 페이지를 추적하는지 여부다.일반적으로 이 작업은 URL에 추가 매개 변수를 추가함으로써 수행된다.자바스크립트 방식도 있지만, 일부 사람들이 자바스크립트를 사용하지 못하는 등 신뢰성이 항상 높은 것은 아니다.나는 이 기능이 소프트웨어에 존재하지 않고 곧 실행될 것이라고 생각하는데, 그래서 그것은 당신이 메인 페이지로 돌아가야 한다는 것을 암시한다.정말 원한다면 브라우저의 뒤로 버튼을 사용하여 원래 있던 위치로 돌아가면 된다.게리 킹 (대화) 05:01, 2010년 1월 21일 (UTC)

로그인 화면은 올바른 "Return to" 링크를 제공한다.OrangeDog(오렌지독) (1998년 1월 21일) 13:32, 2010년 1월 21일 (UTC)

그것은 로그인/등록 링크에 명시적으로 "returnto=" 옵션이 포함되어 있기 때문이다.당신은 그것을 각각의 특별한 페이지 링크에 추가해야 할 것이다.—DJ (대화 • 기여) 13:51, 2010년 1월 21일 (UTC)

소프트웨어에 이 기능이 이미 있는 경우, 그래, 특수 링크에서도 실행될 수 있다.물론 이러한 링크들을 어떻게 구성하느냐에 따라, 각각의 링크에 추가될 필요는 없다. 링크를 만드는 기능에 추가될 수 밖에 없다.그렇다면 미디어에 추가할 정당한 제안일 수도 있다.위키의 버질라.게리 킹 (대화) 2010년 1월 21일 17:36 (UTC)

(끝)HTTP referer를 사용하여 뷰어가 어디서 왔는지 결정하는 것은 어떨까?그게 목적이 아닌가? --Thinboy00 @076, 즉 00:49, 2010년 1월 25일 (UTC)

검색 막대가 너무 눈에 띄지 않음!!

내 이름은 크리스토퍼 켈리야.난 그저 위키백과 독서가일 뿐이야, 저 밖에 있는 수백만 명의 사람들처럼.그리고 한 가지 제안이 있다.검색창에 관한 겁니다.나는 위키피디아가 눈에 띄지 않게 왼쪽으로 내려가는 1/4의 길보다 더 과감하게 중앙 상단에 배치하는 것을 선호한다.나만 그런 거야, 아니면 남들도 동의해?

2010년 1월 24일 —Kellyc01이 추가한 서명되지 않은 의견 작성 (대화 • 기여) 07:03, 2010년 1월 24일 (UTC)

음, 개인적으로 나는 그것이 있는 곳을 좋아하지만, 검색 상자가 비어 있는 동안 검색 버튼을 클릭하면 훨씬 더 큰 검색 필드를 얻을 수 있을 것이다.다른 위키백과 스킨도 시도해 볼 수 있다. 페이지 내용에 대한 레이아웃이 다르다.wp:skin을 참고하여 그 방법을 배우십시오. --Ludwigs2 07:55, 2010년 1월 24일 (UTC)

베타 버전에서 바다표범 바가 맨 위에 나타나며, 새로운 사용자들은 다른 사이트들처럼 바다표범 바를 거기서 찾기를 기대한다.솔레솔 (토크) 08:38, 2010년 1월 24일 (UTC)

분명히 존재하는 스타일에 대해 불평하려고 하지 않는 것은 이 기간 동안 이유가 있지만, 이것은 정확히 주어진 이유 때문에 상식적인 종류의 변화처럼 보인다.왼쪽 상자는 기억도 안 나서 베타 제품이라는 걸 까맣게 잊고 있었어.한 가지 작은 위안이 있는데, 최근 버전의 파이어폭스는 이 (영어) 위키피디아를 오른쪽 상단에 사전 설정된 "검색 엔진 옵션" 중 하나로 가지고 있다.#다이센(토크) 09:07, 2010년 1월 24일 (UTC)

새 베타(창 위쪽의 링크 참조)에는 주로 이러한 이유로 오른쪽 상단에 검색란이 있다.하지만 대부분의 http://www.wikipedia.org은 당신이 검색장을 원하거나, 물론 구글을 사용한다.—DJ (대화 • 기여) 14:04, 2010년 1월 24일 (UTC)

템플릿 정리?HTML 정리정돈처럼?

혹시 템플릿용 HTML 정리 같은 건 없으세요?HTML 정리[4]에 익숙하지 않은 경우, HTML 정리 [4]를 위한 온라인 도구를 참조하십시오.템플릿 로직을 시각적으로 보다 직관적으로 만들고 이를 정리하여 교정기 누락 여부 등을 점검하는 데 도움이 되는 도구가 있는가?고마워. stmrlbs talk 22:35, 2010년 1월 24일 (UTC)

위키에는 템플릿을 편집할 때 도움이 되는 몇 가지 기능이 있다.

그리고 브래킷 매처 사용자 스크립트도 유용하다.위키백과에 대한 설명:WikiProject 사용자 스크립트/스크립트는 다음과 같이 말한다.

복잡한 중첩 식을 추적하는 데 도움이 되도록 일치하는 곱슬 브레이스가 강조 표시된 편집 상자의 복사본을 표시하는 '파스' 링크를 추가한다.

그것은 꽤 잘 작동한다.개인용 /monobook.js에 로드하는 코드:

/* 편집 상자의 복사본에 있는 색상 일치 괄호. [[사용자:ais523/bracketmatch.js] */ 가져오기스크립트("사용자:ais523/브래킷매치.js"); 

평소와 같이 /monobook.js를 편집한 후 브라우저 캐시를 바이패스하여 변경 사항을 확인하십시오.

--David Göthberg (대화) 01:05, 2010년 1월 25일 (UTC)

고마워! 이 템플릿들 중 몇 가지를 알아내려고 할 때와 나 자신의 변화를 확인할 때 큰 도움이 돼.stmrlbs talk 02:20, 2010년 1월 25일 (UTC)

누락된 참고 문헌

안녕! 최근에 린다 맥마흔 페이지를 작업하고 있는데, 그 페이지는 현재 약 70개의 레퍼런스까지 올라와 있어.이유는 모르겠지만, 기술적인 문제로 인해 31번까지 나오는 유일한 레퍼런스가 그것뿐이에요.다른 참고문헌은 그대로 있지만, 참고문헌을 클릭할 때 참고문헌의 어떤 것도 이끌어내지 못한다.<ref></ref> 태그를 사용하고, 참조 섹션에는 {{reflist 2}}이(가) 표시되어 있다.

네가 도와줘서 고마워.고마워! --스크루볼23톡 03:11, 2010년 1월 25일 (UTC)

문제 발견: ref 27에서 잘못된 템플릿이 다음 30개 정도의 참조를 망치고 있었다. --골베즈 (토크) 03:35, 2010년 1월 25일 (UTC)

나는 당신의 메시지의 일부 텍스트 주위에 노위키 태그를 두었으므로 실제 참조 목록 템플릿이나 참조 태그가 아닌 원시 텍스트가 표시된다.Graham87 04:41, 2010년 1월 25일 (UTC)

순서형 번호로 테이블 정렬

현행 FLC에서는 1, 2, 19, 24위 등 서열 순위가 이번처럼 표준표에서 제대로 정렬되지 않는 것이 드러났다.1위/2위/19위/24위로 내림차순으로 정렬하는 대신 다음과 같이 19위/1위/24위/2위로 정렬한다.

이것을 해결할 수 있는 우아한 방법이 있을까?고마운 도움, 스코모록 18:46, 2010년 1월 19일 (UTC)

{{ntsh}}}과 같은 분류 템플릿을 사용해야 한다.—N마jdan•talk 19:19, 2010년 1월 19일(UTC)

다음과 같은 경우:

{{nom}} 템플릿과 함께 작동하는 것처럼 보이지는 않지만, 그 세포들을 개별적으로 포맷해야 할 수도 있다.—N마jdan•talk 19:23, 2010년 1월 19일(UTC)

좋아, {{nom}} 템플릿 안에 다음과 같이 정렬 템플릿을 넣을 수 있을 것 같아.

그게 도움이 되길 바래.—N마jdan•talk 19:27, 2010년 1월 19일(UTC)

숫자가 중복되는 것을 피하기 위해, 당신은 다음과 같은 것을 사용할 수 있다.{{nts 19}}th. Svick (대화) 19:35, 2010년 1월 19일 (UTC)

하하. 네.생각지도 못했어그게 더 깨끗할 거야.—N마jdan•talk 19:37, 2010년 1월 19일(UTC)

그 해결책은 매우 고맙고, 매우 도움이 된다.그러나 차트가 더 일반화될 가능성을 고려할 때 "테이블 클래스:순서적" 또는 유사한 설정에서와 같이 순서형 정렬을 "이해"하는 테이블이나 템플릿이 있기 때문에 더 바람직해 보인다.마할로, 스코모록 23:26, 2010년 1월 21일 (UTC)

나는 위키백과 모임에서 이런 질문을 받았다.고민 끝에 왜 굳이 수적 종류를 강요할 수 없는 것일까.우리는 class="불복"이 있다. 이 템플릿 해킹을 사용하는 대신 숫자 분류에 힘을 가하는 또 다른 것을 추가하기만 하면 된다.— 디스펜서 03:04, 2010년 1월 26일 (UTC)

나는 위키피디아에 이미지 주석기 기구를 설치할 것을 제안한다.

나는 위키백과 사이트에 이미지 주석기 가젯을 설치할 것을 제안한다.이것은 사람들이 사진의 일부분에 대해 의견을 말할 수 있게 해주는 장치다.그 기계는 위키커먼즈에서 작동하고 있고 나는 그것이 유용하다는 것을 알았다.이 장치를 위키피디아에 설치하면, 위키피디아 독자들이 위키컴즈 사진에 첨부된 코멘트를 볼 수 있게 될 것이다.이 장치가 없다면 위키백과 독자들은 위키콤 사진에는 메모가 붙어 있다는 사실조차 깨닫지 못할 것이다.

여기에 노트가 첨부된 위키콤몬스 사진의 예가 있다.사진 위에 마우스 커서를 놓으면 노트를 읽을 수 있다.또한 가젯을 사용하기 위한 시작점인 "노트 추가" 버튼을 주목하십시오.http://commons.wikimedia.org/wiki/File:Magnus_890_electric_chord_organ.JPG

여기 위키코몬스의 위 사진을 보여주는 위키백과 페이지가 있지만, 위키백과에서는 이미지 주석기 가젯을 사용할 수 없기 때문에 노트가 보이지 않는다: http://en.wikipedia.org/wiki/Chord_organ

만약 독자가 그 사진이 흥미롭다고 생각하고 그것을 클릭하면 확대된 시야를 얻을 수 있을 것이다: http://en.wikipedia.org/wiki/File:Magnus_890_electric_chord_organ.JPG

위의 사진에 마우스를 올려 놓으면 노트가 표시되지 않는 것을 볼 수 있다.독자는 어떤 노트도 사용할 수 있다는 사실조차 모를 것이다.노트를 보려면, 독자는 정말로 끈질기고 운이 좋아 이 페이지의 몇 가지 링크 중 하나를 클릭하면 Wikimedia Commons 페이지의 소스 페이지로 이동할 수 있을 것이다. 거기서 마침내 노트를 볼 수 있을 것이다.그렇게 끈질긴 독자는 거의 없을 것이다.

이 가젯은 관리자만 설치할 수 있다.나는 행정관에게 이것을 설치하라고 요청했지만 세 개의 다른 행정관이 결근했고, 한 행정관은 일종의 투표/합의를 요구했다.그것은 내 토크 페이지에 설치되어 있다.

가젯 설치를 위한 도움말 파일은 다음과 같다: http://commons.wikimedia.org/wiki/Help:Gadget-ImageAnnotator/Installation

The LarryBrown (토크) 04:43, 2010년 1월 22일 (UTC)

그 관리자들은 옳다, 래리 - 당신은 관련된 페이지의 변경에 대해 동의할 필요가 있다. 왜냐하면 그것은 *모두*에 영향을 주기 때문이다.—제레미 04:45, 2010년 1월 22일 (UTC)

나는 이것을 빌드할 수 있는 무료 콘텐츠(예: 공유 라이센싱)에 적합한 것으로 볼 수 있지만, 무료 콘텐츠에는 적합하지 않다고 본다 - 만약 그것이 일반 텍스트 편집처럼 제어되지 않는다면, 나는 악의적인 사용자들이 이 태그로 이미지를 "반달링"하는 것을 볼 수 있고, 저작권 소유자들과 우리를 곤경에 빠뜨릴 수 있다. --MASEM (t) 04:49, 2010년 1월 22일 (UTC)

나는 또한 Larry Brown에게 하원에서 그것을 가능하게 하는 것에 대한 합의의 증명서가 필요하다고 말했다.그러나 Masem, 이것을 통해 편집된 것은 일반 텍스트 편집이다: 노트는 일반적인 편집을 사용하여 이미지 설명 페이지에 저장된다.게다가, 이것은 광범위하게 구성될 수 있다.현재 Commons에서는 확증된 사용자에게만 이미지 노트의 추가/편집/제거를 허용하고 있다.

또한, 이곳 영어 위키백과에서 설치를 시도하기 전에 팝업이나 트윙클과 같이 널리 사용되는 다른 스크립트와의 호환성 테스트가 있어야 한다.Lupo 22:40, 2010년 1월 24일 (UTC)

커먼즈에서의 나의 경험은 작은 이미지(주석을 보증하기에 충분한 디테일과 충분한 이력을 가진 이미지들)에 매우 유용하며, 모든 이미지에서 그것을 사용할 수 있게 되면 "하이맘!"의 적소성이 주석으로 추가되어 주위에 붙게 된다는 것이다.그것은 Commons에 있는 것인데, 사람들이 실제로 감시하는 이미지 페이지와는 반대로, 그들이 대부분 그렇지 않은 이곳과는 반대로.여기서 주석을 활성화하기 전에, 나는 우리가 그러한 문제를 피할 수 있다는 증거를 보고 싶다. 하지만 무료 이미지가 이미 이 기능을 가능하게 하기 위해 이미 Commons에 업로드될 수 있다는 점을 감안할 때, 애초에 가치가 있다는 증거를 보고 싶다.— 가비아 임머 (대화) 22:58, 2010년 1월 24일 (UTC)

주요 장점은 공용에서 작성된 주석이 기사에 사용된 이미지 축소판 그림에서 직접 보인다는 것이다.Lupo 08:07, 2010년 1월 25일 (UTC)

기관 사진의 주석을 살펴보았다.나는 위키피디아 편집자들이 거기에 표현된 비지원적인 PoV에 반대할 것이라고 생각한다.그러나 주석이 하원에 있다면 en.wp 표준을 시행하는 것 외에는 그것에 대해 할 수 있는 일이 없을 것이다.2010년 1월 25일 08:48, Beback talk (UTC)

또는 특정 이미지에 대한 주석 인라인 표시를 끄거나(파일이 포함된 위치에서 템플릿을 사용하여 수행할 수 있음) Commons에서 가져온 미리 보기에 대한 노트를 표시하지 않도록 확장명을 구성하거나(전혀 표시하지 않거나 노트 존재 여부를 나타내는 작은 아이콘만 표시하여 해당 확장명이 viii.로컬 이미지 설명 페이지에 표시) 또는 주석을 개선하십시오.그 특정 이미지에 대한 주석은 일반적이지 않다.그 특징의 사용에 대한 좋은 예가 하원에 많이 있다.나쁜 예도 많다.그러나 이러한 유형의 논의는 아마도 기술 VP의 범위를 벗어나서 그 특성이 전혀 바람직한지 여부에 대한 합의 구축(또는 비동의의 입증)의 영역으로 들어간다.Lupo 17:26, 2010년 1월 25일 (UTC)

비정상적인 실행 취소 결과?

조금 전 디스커버 카드에서 개정판 339578635를 되돌리기 위해 'undo' 버튼을 클릭했다.시어스 타워 링크(개정 339011701에서 윌리스 타워로 변경)를 복원하기 위해 수동으로 실행 취소도 편집했다.내가 이 편집을 저장했을 때, 바이트 수가 13,223에서 11,388로 이해할 수 없을 정도로 줄어든 것을 알았다. 그리고 나는 그 차이를 확인했고 나의 편집을 통해 다양한 인용문과 산문이 삭제되는 것을 보았다.그리고 나서 나는 내 첫 번째 편집에서 빠진 자료를 복구하지 못한 채 수작업으로 변경하지 않고 간단히 편집을 취소하려고 시도했다.여기서 무슨 일이 일어나고 있는지 알 수 없어.누구 없어?jæs (대화) 00:40, 2010년 1월 24일 (UTC)

FYI 나는 수동으로 Undos 앞으로 롤백했으므로 지금 기사는 괜찮아 보인다.물론, 왜 이런 이상한 일이 일어났는지에 대한 당신의 매우 타당한 질문은 다루지 않는다. -- Finlay McWalter • Talk 00:46, 2010년 1월 24일 (UTC)

고마워, 핀레이!나는 몇 가지 테스트를 했고, 그 범인을 좁혔다: 맥에서 구글 크롬을 위한 구글 보이스의 공식 확장.이유는 설명할 수 없지만, 그 연장이 활성화되면 참조 태그 사이에 있는 모든 것을 제거하는 끔찍한 부작용이 생긴다.내가 생각할 수 있는 확장자의 유일한 "기능"은 구글 보이스 확장명이 어떤 페이지의 10자리 전화 번호를 클릭 가능한 "다이얼" 링크로 변환하도록 설계되었다는 것이다.나는 이 기능에 대한 무언가가 참조 태그를 활용하거나 악용한다고 추측할 수 있을 뿐이다.정말 이 자리에서 어찌할 바를 모르겠으나, 말할 것도 없이 일단 내선 연장을 불능으로 유지할 생각이다.구글에 이 문제를 어떻게 전달할 수 있는지 잠시 확인해 볼게.엉망진창이 된 것에 대해 다시 한번 사과한다.jæs (대화) 01:17, 2010년 1월 24일 (UTC)

• 주소 표시줄에 디스커버리 카드에서 디프피라고 나와 있음에도 불구하고 위의 jaes가 준 첫번째 디프피는 알렉산드리아의 아주 오래된 히파티아 수정본으로 나를 데려간다.던컨힐 (대화) 01:34, 2010년 1월 24일 (UTC)

그것이 디프가 작동하는 방식이다 – 그것은 그것을 무시한다.title매개 변수 및 다음에서 수정본 표시oldid매개 변수올바른 링크는 아마도 이것일 것이다: [5].Svick (대화) 01:44, 2010년 1월 24일 (UTC)

내가 링크를 수정했어.나는 내가 깨진 기록처럼 들리기 시작했다는 것을 알지만, 링크 에러는 연장과 관련이 있다고 믿는다. 연장이 불능화되기 전에 내가 이 게시물에 앞서 만든 수정안에서 설명하기 힘들 정도로 변경되었기 때문이다.베타 소프트웨어를 사용하게 되면 이렇게 되는 것 같고, 그 사이에 "변경사항 표시"를 더 활용할 수도 있을 것 같다.jæs (대화) 02:08, 2010년 1월 24일 (UTC)

아직 그렇게 하지 않았다면 구글에 알려 줄 것을 권하고 싶다. --Thinboy00 @082, 즉 00:57, 2010년 1월 25일 (UTC)

사실, 그것은 내가 가장 먼저 한 일 중 하나였어!구글에서 온 누군가가 나에게 바로 돌아와서, 약간의 정보를 수집했고, 오늘 초 내가 확인할 수 있었던 2.0.1 버전도 디스커버 카드 기사에서 마주친 문제를 실제로 해결해주었다.jæs (대화) 01:39, 2010년 1월 26일 (UTC)

URL 코딩을 사용하여 페이지 이동

http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php에 URL을 입력하기만 하면 한 페이지를 다른 페이지로 이동할 수 있는 프리로드타이틀 코드가 있는가?

대안의 경우:

1. 페이지를 이동하려는 제목도 미리 로드할 수 있는가?

   http://en.wikipedia.org/w/index.php?title=Special:MovePage/ORIGINALARTICLE&preloadtitle=NEWARTICLE과 같은 것.

2. 새 페이지 제목 상자로 이동할 수 있는 바로 가기 키가 있는가?

   위키백과의 경우:편집 상자로 점프하는 키보드_shortcuts , (comma)는 작동하지 않는다.

Ikip 04:24, 2010년 1월 24일 (UTC)

http://en.wikipedia.org/w/index.php?title=Special:MovePage/ABC&wpNewTitle=Thispage과 같은 대상을 미리 로드할 수 있다. (이유와 모든 확인란을 미리 로드할 수 있다.) 실제로 페이지를 자동으로 이동하려면 api를 사용해야 한다.프로데고^talk 05:58, 2010년 1월 24일 (UTC)

오, 그 api가 뭔지 다시 한 번 상기시켜줘.고마워 :) 답장 고마워.Ikip 11:04, 2010년 1월 24일 (UTC)

API 및 API 설명서.—DJ (대화 • 기여) 13:59, 2010년 1월 24일 (UTC)

절대 URL을 만들지 않을 테니 URL을 따라하기만 하면 자동으로 무언가를 할 수 있어. 그렇게 허용한다면 sysop을 속여서 메인 페이지를 메인 페이지 ON WILEs로 이동시키는 링크를 클릭하는 것이 쉬워질 거야!!!!!!실제 단추를 클릭하거나 스크립트를 실행하지 않으면 페이지를 편집하거나 이동할 수 없다.—시뮬레이션(대화 • 기여) 16:15, 2010년 1월 24일 (UTC)

고마워, 정말 잘 먹혔어.Ikip 05:47, 2010년 1월 26일 (UTC)

인쇄 가능한 버전 제안사항

나는 인쇄 가능한 버전에 대해 두 가지 제안이 있다.

첫 번째는 참고문헌/주석을 첨부한 것이다.인쇄 가능한 버전에서 "^"와 a, b, c...etc를 제거할 수 있을까?인쇄 가능한 버전에서는 ^ 또는 a,b,c 등을 클릭할 수 없다.하지만, 나는 여전히 그 참조가 몇 번이나 사용되었는지 카운터가 있었으면 좋겠다... 아마도 작은 글씨로 (#) 같은 것이 사용되었으면 한다.

두 번째는 프린터 친화적인 페이지가 있다는 것을 더 많은 사람들이 알 수 있도록 프린트 가능한 버전 옆에 작은 아이콘을 추가해 줄 것을 요청하고 싶다.스몰맨12q (대화) 23:35, 2010년 1월 24일 (UTC)

또한 UTC, GMT, EST 등의 시간 유형을 인쇄 가능한 버전과 "이 페이지는 2010년 1월 24일 23시 25분에 마지막으로 수정한 페이지"라고 되어 있는 홈페이지 하단에 기재해 주시기를 부탁드린다.스몰맨12q (대화) 23:41, 2010년 1월 24일 (UTC)

인쇄된 각주에 있는 ^carre를 제거하자는 당신의 제안은, 나는, 좋다고 생각한다.캐럿은 화면 탐색 기능(두 번 이상 사용되는 ref에 대해서는 사용하지 않도록 설정하지만)이다.인쇄 코드는 다른 내비게이션을 제거하는 데 매우 유용하다. 이것은 내가 보기에 실수인 것 같다.그러나 Mediawiki는 캐럿만 감싸기 위한 HTML 개체를 생성하지 않기 때문에 인쇄 보기에 스타일시트를 사용할 수 없도록 설정할 필요가 없다.따라서 이를 위해서는 소프트웨어에 대한 변경 요청이 필요하다. -- Finlay McWalter • Talk 23:49, 2010년 1월 24일 (UTC)

"인쇄 가능한 버전"은 그다지 중요하지 않으며, 나는 우리가 그것을 강조할 필요가 없다고 생각한다.그것은 주로 CSS를 다룰 수 없는 형편없는 오래된 브라우저를 가진 사람들을 위한 것이다; 심지어 IE6도 인쇄 매체 스타일시트 일을 잘 처리한다. -- Finlay McWalter • Talk 23:55, 2010년 1월 24일 (UTC)

인쇄 가능한 버전은 기본적으로 일반 버전과 동일하지만, 인쇄 스타일시트를 볼 수 있도록 활성화되어 있다.Mr.Z-man 00:11, 2010년 1월 25일 (UTC)

나는 Finlay McWalter의 마지막 요점을 읽고 놀랐다. 이 요지는 Help에 의해 확인되었다.Firefox/Firebug에 대한 인쇄 가능 및 나만의 실험.나는 항상 "인쇄 가능한 버전" 링크가 모든 비트맵 이미지를 원래 해상도로 가진 페이지의 다른 버전을 가리키고 벡터 이미지가 1200*1200 이상에서 래스터화되었다고 생각했었다.나는 순진했던 것 같다: 고해상도 이미지를 업로드하고 테이블과 다이어그램에 벡터 그래픽을 사용하라는 모든 조언에도 불구하고, 이것은 인쇄에 아무런 차이가 없는 것처럼 보인다.따라서 아마도 여러분이 소유하고 있는 이미지를 위키피디아에 기부한다면, 화면 해상도보다 더 좋은 것을 업로드할 이유가 없다.맞나? - 포인트리스트(토크) 00:30, 2010년 1월 25일(UTC)

물론이지, 너는 이미지를 따로 다운받아서 너만의 레이아웃을 만들어.—DJ (대화 • 기여) 00:35, 2010년 1월 25일 (UTC)

물론 WP 콘텐츠로 돈을 벌고 싶다면 원본 SVG, JPG, PNG 등을 이용해 내 CMS로 수입하는 스크립트를 작성한 뒤 나만의 InDesign, Flash, Silverlight 등을 퍼낼 수 있다는 것을 알고 있다.나는 반대 질문을 했다: 만약 내가 위키피디아에 기고할 수 있는 이미지를 가지고 있다면, 왜 위키피디아가 사용하지 않을 고해상도 버전을 업로드해야 하는가? - 포인틸리스트 (토크) 00:42, 2010년 1월 25일 (UTC)

왜 사람들이 위키피디아 기사만 인쇄한다고 생각하는가?나는 항상 미리보기를 클릭해서 이미지를 다운받는다.—DJ (대화 • 기여) 00:50, 2010년 1월 25일 (UTC)

요점으로 돌아가기

1. ^와 abc를 제거한다.

   이것은 현재 참조의 내용에서 식별하기 어렵기 때문에 가능하지 않다.CSS 스타일로는 안 돼미디어위키를 바꿔야 할 것 같다.Cite_reference_link_multi 및 MediaWiki:이 요소들을 식별하기 위해(페이지를 더 크고 더 복잡하게 만들기 위해) Cite_reference_link_one을 인용한다.

2. 참조 수

   인쇄 가능한 버전은 일반 웹 페이지가 이미 하지 않은 작업을 할 수 없다.따라서 인쇄를 위해 a, b, c.를 다른 방법으로 세는 것은 불가능하다.

3. 아이콘 추가

   우리는 아이콘을 추가할 수 있지만, 그것은 필요하지 않다.사람들은 그저 메뉴에서 인쇄물을 선택해야 한다.오직 IE 5.5만이 인쇄 가능한 스타일시트가 정말로 필요하며 IE 5.5 지원은 더 이상 사용되지 않기 때문에 우리는 별로 신경쓰지 않는다.

   이 문제에 대해 bugzilla:22256을 열었다.

4. UTC 추가

   거기에 대한 버그리포트를 열게. 버그질라:22257

그게 네 질문에 답을 주길 바래.—DJ (대화 • 기여) 00:57, 2010년 1월 25일 (UTC)

그래, 그렇지.버그 리포트를 열어줘서 고마워.프린터 렌더링 솔루션을 요청하고 싶지만 서버/코딩 비용이 정당화되지 않을 겁니다.참고로, 새 보안 링커가 있는 버그를 찾았는데...위키백과 참조:VPT#인터위키.2Finteranguage_links_not_changing_to_secure.스몰맨12q (대화) 01:48, 2010년 1월 25일 (UTC)

"PDF로 다운로드" 옵션이 있는데, 기본적으로 바로 그것 입니다.그러나 그것은 단순히 "인쇄"를 사용하는 사람들에게는 도움이 되지 않는다. 그것은 오히려 흔한 것이다.그래서 나는 지금 이 시점에서 그 자원들이 단지 몇 가지 구석기 문제에 대해서 많은 사람들에게 기본적으로 별로 쓸모가 없는 어떤 것에 지향되어서는 안 된다고 생각한다.—DJ (대화 • 기여) 01:58, 2010년 1월 25일 (UTC)

요점으로 돌아가기(II)

인쇄 가능한 버전 링크가 CSS에 의해 제한되어야 한다고 생각하는 이유는?그것은 인용문을 처리하고 고해상도 이미지를 내장하기 위해 다른 논리를 사용하는 프린터 지향 페이지 렌더링 시스템을 가리킬 수 있다.결국, 우리는 이미 사용자가 선호하는 크기로 미리 보기를 제공했다.현재 인쇄 가능한 버전은 아무런 이점도 제공하지 않는다는 점을 고려할 때 (구 브라우저를 제외하고) 피쳐링된 사진 기준 #2("품질 인쇄 재현을 허용하기에 충분히 높은 해상도의")는 오해의 소지가 있다.기고자들은 화면 해상도 이미지가 위키피디아 목적에 전적으로 충분하며, IP의 GFDL/CC3 고해상도 버전이 필요하지 않다는 것을 알아야 한다. - 포인트리스트 (토크) 01:18, 2010년 1월 25일 (UTC)

나는 항상 그것을 이미지만 인쇄하고 싶어하는 사람들을 위한 것이라고 생각했다.잉크가 얼마나 비쌀 수 있는가를 고려하면, 나는 인쇄 가능한 버전의 더 큰 그림들에 다소 짜증이 날 것이다.인쇄 가능한 버전은 가능한 한 웹 레이아웃에 가깝게 붙어야 하며 가장자리 주변의 재료(사이드바, 탭, 시트노티스 등)를 빼야 한다.미스터 Z-man 01:26, 2010년 1월 25일 (UTC)

그리고 나는 실제로 피처링된 그림 기준을 읽은 비교적 적은 사람들, 거의 모든 사람들이 당신의 해석에 동의할 것이라고 생각한다.—DJ (대화 • 기여) 01:43, 2010년 1월 25일 (UTC)

인쇄된 해상도 비교 - 보려면 클릭하십시오.

아마도 나는 이것을 잘 설명하지 못하고 있는 것 같다.독자가 기사의 "인쇄 가능한 버전" 링크(예: Helix-turn-helix)를 누르면, 인쇄를 위해 HTML 페이지가 준비되고 브라우저로 다운로드된다.현재 페이지에는 화면 해상도 이미지(예:src="200px-Lambda_repressor_1LMB.png" class="thumbimage" height="294" width="200"대신 페이지에는 원본 이미지(예:src="http://upload.wikimedia.org/wikipedia/commons/8/8f/Lambda_repressor_1LMB.png" class="thumbimage" height="294" width="200"어느 쪽이든 이미지는 동일한 높이와 너비로 스케일링되며 레이아웃은 변경되지 않으며 잉크는 더 이상 사용되지 않는다.하지만... 원본 이미지를 사용하면 더 많은 데이터를 프린터로 렌더링할 때 더 자세한 정보를 볼 수 있다.이것은 단순한 변화다... 필요한 것은 스크린 스케일의 버전이 아닌 원본 비트맵(또는 가장 잘 재생된 SVG) 이미지의 파일명을 사용하는 것이다.우리가 이것을 할 준비가 되지 않았다면, 왜 기여자들이 인쇄 해상도 이미지를 업로드 해야 하는가? - 점묘사 (토크) 02:45, 2010년 1월 25일 (UTC)

음, 내가 찾고 있던 기능성은 이미 "PDF로 다운로드"의 일부분이기 때문에, 분명히 나는 이것을 잘 설명하지 못했다.나는 그에 따라 샘플 이미지를 업데이트했다."인쇄 가능한 버전" 링크가 왜 이 접근법을 사용하지 않는지 아직도 궁금한데.... - 점묘사 (토크) 03:07, 2010년 1월 25일 (UTC)

만약 인쇄 가능한 버전이 전체 원본 이미지를 사용했다면 DSL보다 느린 연결의 사용자들은 위키백과 페이지를 인쇄할 수 없을 것이다...

그러나 큰 이미지를 업로드하는 데는 다음과 같은 여러 가지 좋은 이유가 있다.

• 이미지는 최소한 기사에 사용되는 크기의 두 배 이상이어야 하므로 재샘플링 기능은 작업하기에 좋은 데이터를 가지고 있어야 한다.
• 우리는 장기적으로는 그 안에 있다.위키피디아, 또는 적어도 그 자료의 일부는 먼 미래까지 사용될 것이다.시간이 지나면서 사람들은 더 큰 화면과 더 높은 해상도의 컴퓨터를 사용한다.그래서 몇 년 후 우리는 지금보다 더 큰 이미지가 필요하다.내가 320x200px 컴퓨터를 사용하기 시작했을 때 일반적인 화면 해상도였는데, 지금은 1600x1200px가 일부 사용자들에 의해 사용되고 있다.
• 위에서 언급한 바와 같이:우리들 대부분은 이미지의 전체 화면 버전을 보기 위해 이미지를 클릭하거나 다운로드하기 위해 이미지 페이지로 이동한다.나는 현재 괴테보리(선박)의 이미지 중 하나를 바탕 화면 배경으로 사용하고 있다.그리고 위키피디아의 이미지는 다른 장소에서 다시 사용될 수 있다.예를 들어, 내가 만든 암호 도표 중 두 개가 미국의 가장 큰 은행 중 한 곳의 보안 시스템에 관한 인쇄 책자에 사용되었다.사본 보내주셨는데, 내 책꽂이가 아주 멋있어. :)

--David Göthberg (대화) 2010년 1월 25일 (UTC) 17:52, 25

데이빗, 고마워. 그 점들은 모두 아주 좋은 점들이야. 특히 샘플링 문제는 내가 고려하는 것을 잊었어.모든 베스트 - 포인트리스트 (토크) 18:21, 2010년 1월 25일 (UTC)

Userboxtop 템플릿으로 인해 사용자 페이지 포맷이 중단됨

내 사용자 페이지의 형식이 'userboxtop' 템플릿에 의해 해제되고 있다."흥미로운 위키백과 기사"라는 제목의 섹션의 큰 격차를 주목하라.이 문제를 해결하는 방법에 대한 제안이 있으십니까?Jrtayloriv (대화) 22:20, 2010년 1월 22일 (UTC)

누가 고친 것 같은데 네가 다시 고친 거잖아.그래서 {{FixBunching}} 템플릿을 추가했는데, 어떤 종류의 수정인지.게리 킹 (대화) 04:29, 2010년 1월 23일 (UTC)

그들의 편집이 나를 위해 고쳐주지 않아서(Firefox 3.5를 사용하고 있다), 내가 마지막 편집을 하기 전에 아직 망가졌다.그것을 고치려고 한 편집자는 IRC의 누군가였고, 그가 만든 변화는 그의 스크린을 위해 고쳤으나, 당시 나나 IRC의 다른 사람들을 위한 것은 아니었다.{{FixBunching}}} 역시 나를 위해 아무것도 하고 있지 않다.나는 아직 화면에 빈틈이 남아 있다.도와줘서 고마워.다른 제안은 없으세요?Jrtayloriv (대화) 22:11, 2010년 1월 23일 (UTC)

기둥을 만드는 템플릿인 {{top}등과 관계가 있는 것 같다.내 페이지와 사용자의 페이지 간에 볼 수 있는 유일한 차이점:삭스원. 이게 왜 서로 간섭하는지 알아?Jrtayloriv (대화) 22:13, 2010년 1월 23일 (UTC)

상자 흐름을 고정하십시오.{{top}} + {{middle} + {{bottom}}}이(가) 테이블을 만든다.하지만 그 테이블은 "width: 100%", 그래서 대부분의 브라우저에서는 100% 너비를 얻을 수 있도록 사용자 페이지의 오른쪽 부동 상자 아래로 흐른다.요령은 대신 "을 사용하는 것이다.margin: 0;" 테이블에서, 모든 가능한 너비를 사용하지만 오른쪽 떠 있는 상자 아래로 흐르지 않는 상자를 얻는다.그래서 내가 그 설정을 가지고 너에게 테이블을 손으로 코딩했어.

--David Göthberg (대화) 03:51, 2010년 1월 24일 (UTC)

데이비드 정말 고마워!Jrtayloriv (대화) 23:22, 2010년 1월 26일 (UTC)

여러 카테고리 보기

나는 여러 카테고리를 보는 것에 대해 두 가지 질문이 있다. (1) 두 개의 특정 카테고리에 있는 기사 목록을 얻는 가장 좋은 방법은 무엇인가?예를 들어, 카테고리에 있는 기사 목록을 얻는 방법:참조되지 않은 모든 BLP * 및* 범주:미국의 록 기타리스트? (2) 카테고리나 하위 카테고리에 있는 기사 목록을 얻는 가장 좋은 방법은?예를 들어, 카테고리에 있는 기사 목록을 얻는 방법:미국의 록 뮤지션 *또는*은 카테고리의 모든 하위 카테고리에 있다.미국의 록 음악가?— 2010년 1월 26일(UTC) 12:51, 진흙물 ^(Talk)

(1)의 경우, 참조 WP:CI, 교차 도구를 사용할 수 있다(Category: bit 없이 하단 상자에 두 범주 모두 입력). 또는 WP:캣스캔.나노닉 (토크) 13:08, 2010년 1월 26일 (UTC)

(2)의 경우 WP:CATSCAN도.Svick (대화) 14:11, 2010년 1월 26일 (UTC)

고마워, 나노닉과 스빅이게 바로 내가 찾던 거야. "P.S." 흥미롭게도, 교차로 검색과 캣 스캔은 둘 다 (1)이나 (2)에 사용될 수 있을 것 같다.— 진흙물 ^(Talk) 00:34, 2010년 1월 27일(UTC)

범주 교차점

위키백과 주체가 그 범위 내에서 어떤 종류의 유지보수가 필요한 기사를 나열하는 섹션을 갖는 것은 좋은 생각일 것이다.이를 위해, 기사가 그러한 범위에 있는 범주(예: "Category: Category:Foo", "카테고리:Foo의 이력 등) 및 특정 템플릿이 포함되거나 특정 유지보수 범주에 포함되는 템플릿.직접 그런 쿼리를 만들 수 있는 툴은 알고 있지만, 자동으로 만들고 결과를 특정 위키백과 제목 페이지에 배치/업데이트할 수 있는 툴이 있을까?그래서 어떤 사람은 목록을 보고, 그 목록에서 기사를 선택하고, 그 목록에는 유지보수가 필요한 새로운 기사가 추가되거나, 그렇지 않은 사람(즉, 템플릿이 추가/제거되었다는 뜻)을 제거하기 위해 인간의 개입 없이 그렇게 하는 것이다.MBelgrano (대화) 15:52, 2010년 1월 26일 (UTC)

위키백과:기사가 특정 업무에 들어갈 때 매일 보고하는 기사 경고(Webedia:WikiProject 축구/예: 출력에 대한 기사 경고) 및 사용자:WolterBot은 유사한 월별 서비스를 제공한다(Wipedia:위키프로젝트 풋볼/청소 목록(다른 예시 결과).비슷한 일을 하는 다른 사람들도 있을 것이다.나노닉 (토크) 18:03, 2010년 1월 26일 (UTC)

LTR 및 RTL 스크립트 혼합 문제

에 문제가 생겼어{{ug}}아랍어(오른쪽에서 왼쪽으로) 스크립트를 포함하는 .후에 템플릿 끝을 만약 당신이 및 대신 정규 공간 사용하는 템플릿에서 마구 뒤섞인 그런 위험과 같은 소수의 편집에서, 것들은 정말,;nbsp고, 보시다시피(및을 사용하여 nbsp.)실제 디스플레이, 잘못된 것이다 심지어 날씨가 좋을 때는 편집 창에서 보자면 이 날짜 전에 찾아오는 왼쪽에서 오른쪽으로 향하는 스크립트(날짜)를 망쳤어요.는 아르곤육체의

흥미롭게도, 이 템플릿은 라틴 문자도 포함하고 있는데, 아랍어 이후 모든 것이 갑자기 좋아졌다고 덧붙이자.템플릿 자체 안을 살펴봤지만 누락된 것은 없었다.</span> 태그 같은 것 때문에 원인이 뭔지 잘 모르겠어. rʨanaɢ^talk/_contribs17:45, 2010년 1월 26일 (UTC)

RTL 텍스트 후에 처음에 가졌던 문자는 백핸드에 '약한' 문자로 보여지는데, 그 중 방향을 예측하지 못한다.이 때문에 문자열의 방향성은 RTL로 다시 전환되지 않는다.양방향_텍스트를 참조하십시오.방향을 강제 적용하려면 왼쪽에서 오른쪽으로 표시하거나 오른쪽에서 왼쪽으로 표시 문자가 필요하다.(항상 템플릿에 의해 추가되는 실험을 할 수 있을 것 같은데...—DJ (대화 • 기여) 2010년 1월 26일 (UTC) 19:39, 19:39

사용자:DJ/SandboxTemplate5가 지금 가지고 있다.이렇게 보기 좋은가? —DJ (대화 • 기여) 19:58, 2010년 1월 26일 (UTC)

그것이 하는 일을 설명하기 위해서.표시에는 "여기는 ltr vs rtl의 경계선이며, 왼쪽 바로 왼쪽에 있는 문자를 lrm이면 '좌우'로, rlm의 경우 '좌우'로 처리한다"고 적혀 있다.그 템플릿은 약간의 문서 btw를 사용할 수 있다.—DJ (대화 • 기여) 20:02, 2010년 1월 26일 (UTC)

&lrm; 캐릭터가 마커인가?효과가 있을 것 같은데, 좀 더 만지작거릴게.나는 단지 <span> 태그가 그것을 이미 커버하지 않았다는 것에 놀랐다; 위키백과의 스타일시트 안 어딘가에 <rtl> 속성이 있어야 하는데, <span lang="ar>에는 분명히 포함되어 있고 <span lang="ug"도 포함되어 있지 않다면 놀랄 것이다.아랍어 템플릿에도 비슷한 문제가 생긴 적이 있는지 궁금하다.

(btw, 문서에 대한 네 말이 맞아; 템플릿에는 문서가 없었고 며칠 전에 업데이트했을 때 나는 성급하게 굴었고 그것을 전혀 이해하지 못했어!) rʨanaɢ^talk/_contribs 22:25, 2010년 1월 26일 (UTC)

출처를 보면 알 수 있듯이, 이것은 템플릿 랑아르가 하는 것과 정확히 같다.—DJ (대화 • 기여) 01:37, 2010년 1월 27일 (UTC)

짜증나고, 눈에 보이지 않는 칸을 끊임없이 나타냄.

Javascript를 통해 페이지에 짜증나고 항상 존재하는 div가 추가되어 사파리의 검사관과 함께 발견했듯이 내가 오른쪽 클릭을 제대로 하지 못하게 하는 것 같다.이 파일에는 빈 iframe이 포함되어 있으며, 이 이미지: .일반적으로 가시성:숨김을 사용하여 숨겨지지만, 실제로 숨기는 것이 아니라 디스플레이:누구도 대신 사용했어야 한다고 생각한다.

그나저나 그게 뭔데? --(ƒî) » 04:34, 2010년 1월 25일 (UTC)

위키미니아틀라스인데, 내가 최근에 보고한 사파리에서 버그를 경험하고 있구나.https://bugs.webkit.org/show_bug.cgi?id=34042 —DJ (대화 • 기여) 11:30, 2010년 1월 25일 (UTC)

나는 WMA의 저자에게 그 문제를 통지했다.—DJ (대화 • 기여) 11:39, 2010년 1월 25일 (UTC)

여기서 언급해줘서 고맙고, 추가 정보는 TheDJ에게 고마워!내가 화내지 않아서 다행이고, 나뿐만이 아니야.나는 회피성 자바스크립트 주사나 다른 악의적인 것에 대한 온갖 걱정스러운 생각을 하기 시작했는데, 그것이 어디서 오는 것인지 추적하기가 어렵다...고딕(토크) 13:14, 2010년 1월 25일 (UTC)

알려줘서 고마워.시야를 가리는 것도 나쁘지 않을 것 같다:숨김과 디스플레이:없음. --Dschwen 15:42, 2010년 1월 25일 (UTC)

좋아, 코드를 바꿨어.캐시를 지우고 다시 시도하십시오. --Dschwen 15:46, 2010년 1월 25일(UTC)

그게 고쳐준 것 같아, 고마워! - (ƒî) » 2010년 1월 27일 (UTC)

위키백과용 에테르패드

에테르패드의 에테르패드는 최근 구글에 의해 공개되었다.여러 사람 사이에서 텍스트 문서를 실시간/동시에 편집할 수 있다.나는 대부분의 위키백과 기사들이 텍스트일 뿐이라는 점을 고려할 때 위키백과 사회자와 에테르패드를 통합할 것을 제안하고 싶었다. 이것은 여러 편집자들 사이의 훨씬 더 나은 협업을 가능하게 할 것이다.

이것에 대해 어떤 생각이 있으십니까?스몰맨12q (대화) 21:35, 2010년 1월 25일 (UTC)

이것이 현재의 MediaWiki 편집 소프트웨어와 어떻게 통합될 것인가?기존 기사를 편집할 때 또는 초안을 작성할 때 별도의 시스템에 사용하시겠습니까?OrangeDog(오렌지독) (19:25, 2010년 1월 26일 (UTC)

글마다 따로따로 "패드"를 활성화 시키고 싶었어.그래서 사용자는 기본적으로 "에테르패드로 편집"을 클릭하면 기사 내용이 미리 로드된 패드로 이동하게 된다.거기서, 다른 사용자들도 "에테르패드로 편집"을 클릭할 수 있고, 그들도 첫 번째 사용자가 갔던 곳으로 옮겨질 것이다.초안/편집용으로 쓰일 것이다..모든 편집이 패드의 모든 사람에게 즉시 보여질 것이기 때문에 현재의 사후/후기/복구보다 훨씬 더 나은 기능을 할 수 있을 것이다.스몰맨12q (대화) 22:14, 2010년 1월 27일 (UTC)

미디어위키 북 페이지

책 생성기는 PDF를 렌더링할 때 "레이아웃"이라는 용어를 사용한다.그러나 "레이아웃"은 말이 아니다."레이닝"으로 변경하고 싶은데 관련 MediaWiki 페이지를 찾을 수 없어.뭐 생각나는 거 있어?스틱(토크) 14:52, 2010년 1월 27일(UTC)

FYI, 이걸 찾다가 찾았는데, '레이아웃'이 어디서 왔는지 모르겠네 - 킹핀¹³ (토크) 15:03, 2010년 1월 27일 (UTC)

게시

그냥 스팸메일로 보내는 거야.예시에서는 오랫동안 사전 태그가 사용되지 않았다.Locos epraix ~ Beastepraix 15:57, 2010년 1월 27일(UTC)

Mediawiki API 쿠키

해결됨

– Smallman12q (대화) 22:58, 2010년 1월 28일(UTC)

편집을 위해 mediawiki api를 사용하여 포스트 요청을 하는 경우, 우리도 쿠키를 보내야 하는가, 아니면 에디토큰이 충분한가?편집 토큰 같은 쿠키 일부만 보내도 될까?필요한 정보와 선택 사항...서류가 좀 부족하다.스몰맨12q (대화) 00:47, 2010년 1월 28일 (UTC)

편집을 위해서는 편집 토큰과 함께 로그인 쿠키를 보내야 한다.일반적으로 로그인할 때 받는 모든 쿠키를 보관하고 각 요청과 함께 반환해야 한다.그렇지 않으면 API는 어떤 사용자가 편집을 하고 있는지 알 방법이 없다...이미 편집을 포함한 대부분의 일반적인 프로그래밍 언어에 사용할 수 있는 라이브러리가 있다. WP:MKBOT를 참조하십시오. — Carl (CBM · Talk) 00:53, 2010년 1월 28일(UTC)

나는 현재 API를 위해 vb/c .net에 라이브러리를 쓰고 있다.현재의 닷넷위키봇 프레임워크는 API를 사용하지 않는다.API를 엄격히 준수하는 라이브러리에 추가 기능을 추가하고 싶다.그래서 나는 쿠키를 다시 보내야 한다고 생각해, 그렇지?스몰맨12q (대화) 01:22, 2010년 1월 28일 (UTC)

WP:MKBOT에서 논의한 바와 같이 여러 개의 로그인 쿠키가 있다.로그인 명령어가 설정한 쿠키를 모두 저장한 후 각 편집과 함께 반환하십시오.당신은 페이지를 편집하기 위해서 뿐만 아니라, 다른 API 쿼리에서 반환되는 결과의 수에 대한 증가된 제한을 얻기 위해서 쿠키가 필요하다.— 칼 (CBM · talk) 13:07, 2010년 1월 28일 (UTC)

고마워!Smallman12q (대화) 22:58, 2010년 1월 28일 (UTC)

실제로 사소한 병합 문제 편집

기술 쪽 사람이 불면증을 겪고 있을 경우를 대비해서, 여기 곰곰이 생각해 볼 퍼즐이 있다.나는 레퍼런스 데스크에서 위키피디아를 보았다.레퍼런스_데스크/인문#플래그_라티오스.흥미로운 것은 실의 하단에 있는 작은 인쇄 논평이다 - 위키미디어 소프트웨어가 두 개의 동시대의 편집본을 병합할 때, 왜 잘못된 시간 순서대로 그것들을 병합하는가?(진짜 곰일 수도 있는) 추적만 된다면 정말 쉽게 고칠 수 있을 것 같다. --Ludwigs2 07:17, 2010년 1월 28일 (UTC)

내 아이콘

아이콘 변경 방법 —Czimerman이 추가한 서명되지 않은 설명 준비(토크 • 기여) 18:37, 2010년 1월 28일(UTC)

"내 아이콘"이라니 무슨 뜻이야?사용자 이름 옆에 있는 아이콘?Svick (토크) 18:42, 2010년 1월 28일 (UTC)

필름의 비디오 샘플 범주

나는 필름의 비디오 샘플을 분류하는 것에 기술적인 문제가 있다.범주 대화를 참조하십시오.필름의 비디오 샘플.고마워, 에릭 (토크) 21:57, 2010년 1월 28일 (UTC)

고정. (_NO GARILLER__)이 필요한 것이다(이전에 비슷한 실수를 한 적이 있다) :D) Der Wohltrafte Fuchs^(talk) 22:24, 2010년 1월 28일 (UTC)

훌륭해!고마워!에릭 (토크) 22:26, 2010년 1월 28일 (UTC)

하위 페이지 이름에 대한 매직 워드

몇 가지 수준의 하위 페이지가 있는 페이지의 컨텍스트에서 어떤 하위 페이지를 얻을 수 있는지 제어할 수 있는 마법의 단어가 있는가?예를 들어, Wikipedia가 있는 FAS 하위 페이지:주요 기사 후보/Foo/아카이브1

• {{BASEPAGENAME}}수확하다Featured article candidates/Foo
• {{SUBPAGENAME}}수확하다archive1
• 단지 생산만 하는 것이 있는가?Foo?

rʨanaɢ _contribs/ 04:29, 2010년 1월 29일 (UTC)

오, 사실, 어쩌면 내가 가지고 있을지도 몰라.약간 해킹 같은 느낌이 들지만, 그런 느낌이다.{{SUBPAGENAME:{{NAMESPACE}}:{{BASEPAGENAME}}}} 작품, 덕분에. rʨanaɢ^talk/_contribs04:34, 2010년 1월 29일 (UTC)

{{#titleparts} 사용 가능 -{{#titleparts:Wikipedia:Featured article candidates/Foo/archive1 1 2}}Foo 반환 - 설명서가 여기에 있음.미스터 Z-man 06:14, 2010년 1월 29일 (UTC)

2010년 1월 23일 이후 페이지 통계 무효

23일 이후 기사에는 히트작이 집계되지 않았다는 사실을 다른 사람이 눈치채지 못하셨나요?나는 두 개의 다른 IP의 임의 페이지를 많이 방문했는데 페이지 통계는 조회수가 0을 나타내고 있다.이게 무슨 일인지 아는 사람?미리 고마워! :) --Neon Sky (토크) 19:43, 2010년 1월 25일 (UTC)

어느 페이지 통계?Stats.grok.se ? —DJ (대화 • 기여) 22:43, 2010년 1월 25일 (UTC)

항상 며칠씩 늦지 않아?2008년 3월 22일에 찍힌 2008년 3월 아시아 통계 스냅샷은 3월 20일부터 통계로 끝난다.Svick (대화) 22:51, 2010년 1월 25일 (UTC)

미해결

en.wikipedia.org 사이트.지금 작동하는 것 같아. :) --Neon Sky (토크) 01:37, 2010년 1월 26일 (UTC)

위키백과 강연에서도 같은 문제를 제기했다.너 #http://stats.grok.se/en/201001/Castle_Green,_London 알고 있었니?잃어버린 날들은 어떻게 설명되며 회복될 수 있는가?단순 남부 (대화) 2010년 1월 26일 (UTC)

https://bugzilla.wikimedia.org/에서 트러블티켓을 했는데 비교적 빨리(2시간 이내) 고쳐졌다.나는 거기서 시도해 볼 것을 제안한다.:) 행운을 빈다!--네온 스카이 (토크) 23:03, 2010년 1월 26일 (UTC)

2010년 1월 23,24는 실종된 것 같다.하지만 그 후에는...스몰맨12q (대화) 22:17, 2010년 1월 29일 (UTC)

eu 위키백과의 기능

안녕, 나는 바스크 위키피디아와 협력하고 있어. 그리고 우리는 새로운 기능들을 구현하는 것에 관심이 있어.네가 아직 가지고 있기 때문에 우리에게 새로운 것이다.해결책이 Common.css나 Common.js와 관련이 있을 거라고 거의 확신하지만, 노력한 만큼 도움이 필요하다.위키백과에서도 이 문제에 대해 이야기했지만 아무도 모른다.

• 참조 관련.동일한 참조가 사용되는 경우(<ref name=")A>>) 그러면 알파벳순으로 나열된다.이건 너의 경우지만, 바스크 위키피디아의 결과는 1,01,1 1,2...나는 어떻게 더 잘 설명해야 할지 모르니 다음 예를 참고하십시오.헬륨#참고 및 eu:헬리오#에로이테지악.자세한 내용이 필요하면 문의하십시오.
• 인쇄/내보내기 섹션에서 "PDF로 다운로드" 버튼을 구현하기 위해 따라야 할 단계는 무엇인가?"책 만들기"는 흥미롭지는 않지만 기사를 다운로드 하는 옵션은 정말 유용할 수 있다.

제발, 이 이야기를 좀 더 좋은 곳으로 옮겨 줘. 하지만 나는 그것을 찾을 수 없었어.네가 팁을 주면 고맙고 나의 부족한 영어에 대해 미안해.고마워. --이노르베즈 (대화) 09:30, 2010년 1월 28일 (UTC)

참고문헌 발행은 기이하다.버질라에서 '사이트 요청' 버그를 신청하는 것밖에 생각이 나지 않는다.만약 당신이 Bugzilla를 잘 모르면, 누군가에게 물어봐라.PDF로 다운로드 문제에는 다른 사이트 요청 버그가 필요할 수 있다. eu에서 "수집" 확장 기능을 사용할 수 있어야 한다.위키백과더 이상 도움이 되지 못해 미안해 — 이것, 저것, 그리고 다른 (대화) 07:02, 2010년 1월 29일 (UTC)

아무튼 고마워. --이노르베즈 (대화) 09:36, 2010년 1월 29일 (UTC)

어떻게 해야 할지 모르겠지만 나는 이 페이지에 도달했고, 시트가 있는 숫자가 없고 글자를 사용하기 위해서는 어떤 변화가 일어나야 하는지 설명되어 있다.PDF 다운로드와 관련된 정보를 알고 있거나 알려 줄 수 있다면 감사하겠다. --Inorbez (대화) 13:08, 2010년 1월 29일 (UTC)

비판적 인종을 거의 연습하지 않았는가?

나는 편집을 시작하고, 산만해지고(아마도 더 급한 일로, 편집이 내 주의를 끄는 것에 의해), 그것을 끝내는 나쁜 버릇이 있다, 하루 뒤에 말한다.때때로 이것은 나를 (몇 년이고 몇 년 동안 다루어 온, 그리고 내가 부드럽고 책임감 있게 다루는 것을 스스로 칭찬하는) 갈등 해결의 과정을 거치게 한다.
아마도 그렇게 중단된 편집은 18일에 시작했는데, 나중에 [잘못 알아들을 수 없을 정도로] 완성되지 않은 것으로 보인다.그 설명은 내가 두 번의 세이브 사이에 62초간의 창에서 편집을 시작했음을 암시하는 것으로 밝혀졌다. (아마도, 첫 번째 1분에 저장한 것은 단순한 우연일 것이다.)그것은 또한 내가 인정하기 싫은 것을 암시한다. 내가 시작한 이래로 크고 눈에 보이는 추가 사항들에 비추어, 내가 저장한 것, 즉 서버 이상 현상을 수반하는 버그가 일반적인 편집 충돌 처리를 방해하지 않는 한, 내가 결코 편집하지 않았던 편집 충돌 처리를 오버로딩하지 않는 한.내가 그렇게 하고 있다는 징후도 없이 봤지
나는 이것이 이전 혹은 이후의 보고서와 묘한 유사성을 가지지 않는 한 추구될 것이라고 기대하지 않는다는 것을 서둘러 언급한다: 나는 "만약 한 번 일어났다면, 그것은 실제로 일어나지 않았다"는 원칙을 확고히 지지한다.그러나 아마도 개발자들은 가상의 괴상한 사건들이 숨겨져 있고, 때때로 그들이 "Pfft!"나 "Hhmmph"를 불러올 때까지 내려와서 뒤집어서 일주일이나 1년 더 앉아있지만, 결국에는 "WTF"나 "잠깐만, 생각나는..."를 얻게 될지도 모른다.
모든 독자 여러분 덕분이다.
--Jerzy•t 23:18, 2010년 1월 28일(UTC)

• 물론 또 다른 워치 워드는 " 조종실에서 문제를 찾아봐"이며, 내가 조종사일 때는 거의 적용되지 않을 수 있다.운전하면서 곰곰이 생각해 보니, 내가 가끔 운동을 하는 것 중에 또 다른 두 가지 나쁜 습관이 있다는 생각이 들었다.
  1. 편집 중에 URL 복사
  2. 다른 편집 영역에서 복사한 자료로 편집 영역을 덮어쓰기.