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

중첩된 템플릿

템플리트에 대한 나의 이해로 볼 때, 템플리트를 어떤 페이지에서 사용하든 데이터베이스로부터 해당 페이지를 수집하는 데 걸리는 시간이 증가한다.항법 템플릿은 지속적으로 다듬어지고 있으며, 종종 사람들은 반복적으로 사용된 템플릿의 일부를 별도의 템플릿으로 분리하기로 결정한다.이 포장은 세 개의 템플릿이 서로 안쪽으로 접혀 있는 극한에 달할 수 있다.이것이 장기적으로 위키피디아의 공연 문제를 야기할 것인가, 따라서 그것을 포기해야 하는가?이 문제를 해결하기 위한 지침이 작성되어야 하는가? - Samsara (talk • contracts) 23:12, 2006년 11월 28일(UTC)

5단계 깊이의 내포 템플릿이 어떤 기사의 편집과 관리가 보다 직선적이고 편집자의 목표를 더 쉽게 달성하는 데 도움이 된다면, 시스템이 어려움을 겪게 하라!나는 대부분 진지하다.더 좋은 기사를 장려하는 어떤 구조도 칭찬하고 베껴야 한다. 낙담해서는 안 된다.한 가지 좋은 예가 주기율표다.그 위키피디아는 미개척자들에게 어리둥절하다.하지만 일단 내면의 템플릿이 이해되면, 그것은 굉장해!무엇이 효율적이고 그렇지 않은지에 대한 걱정보다는, 어떤 기사를 더 효율적으로 사전 번역(예를 들어)하는 것이 더 낫다고 시스템을 재설계하는 것이 더 나을 것이다.— EncMstr 23:59, 2006년 11월 28일 (UTC)

(충돌 편집 * 2)

사전 반출은 변화가 늦어진다는 것을 의미할 뿐이다.현명한 선택은 아니다. - Samsara (talk • contracts) 00:17, 2006년 11월 29일(UTC)

그럴지도 모르지, 하지만 난 템플릿 편집이 사전 폐지를 촉발할 거라고 생각하고 있었어.만약 내가 그 직업의 취지를 이해하고 있다면, 그것은 지금 일어나는 일에 매우 가깝다.— EncMstr 00:47, 2006년 11월 29일 (UTC)

그래, 그럴 만도 하지. - 삼사라 (토크 • 출연) 02:34, 2006년 11월 29일 (UTC)

제발, 다신 이러지 마이것은 거의 전적으로 그것을 위해 두 번 금지되었던 한 집요하고 파괴적인 사용자에 의해 이미 죽도록 논의되어 왔다.

우리의 리드 개발자는 그것이 눈에 띄는 문제를 일으키지 않는다고 말했고, 그렇다고 하더라도 우리는 이런 기술적인 문제에 우리 자신을 신경 써서는 안 된다고 말했다.컨텐츠 및 사용 편의성에 집중하십시오.서버들이 막히기 시작하면 개발자들은 코드를 더 깨끗하게 만들거나 기술적인 면에서 사물을 제한하는 방식으로 문제를 처리하게 될 것이다.백과사전을 더 좋게 만들려면 내포된 템플릿을 사용하십시오.— 오메가트론 00:11, 2006년 11월 29일 (UTC)

실제로 위키피디아의 기본 정책 중 하나는 성과에 대해 걱정하지 말라는 것이다.La novemberka 10:54, 2006년 11월 29일 (UTC)

새로운 차이점 기능?(iii)

당신이 만든 오래된 편집의 차이에 있을 때, 새로운 선택사항이 있다: "undo".이게 무슨 소용이야?샌드박스에서 시험해봤는데 중간 편집 충돌 등으로 편집을 취소할 수 없다고 하더라.

또한 페이지 하단의 바닥글, Safari 2.0.4는 예전보다 훨씬 넓어졌다.모든 페이지에서 수평 화살표는 텍스트보다 더 멀리 뻗어 있으며, 이는 일반적이지 않다. --Fbv65edel / ☑t / ☛c 22:21, 2006년 11월 28일(UTC)

셀프 롤백인 것 같은데?지금은 제대로 작동하지 않을 수도 있지만?오래된 편집에 대해서만 나타나는 것처럼 보이지만, 물론 이 경우 "중간 편집이 충돌하여 편집을 취소할 수 없었다"는 메시지를 준다.누군가는 새로운 편집에 대해서만 실행 취소를 하도록 되어 있다고 생각할 것이다. --Interiot 22:37, 2006년 11월 28일 (UTC)

그게 다인 것 같은데, 어떻게 누군가가 막지 않고 망가진 상태로 살아날 수 있었는지 궁금하다.svn을 통해 알아보고 있지만, 아직 안 보여...프로데고 22:49, 2006년 11월 28일 (UTC)

Singpost 스토리를 참조하십시오.쿠스마 (討討) 22:59, 2006년 11월 28일 (UTC)

아! 아직도 어떻게 작동하는지 이해가 안 되는데, 왜 아직도 그 표지판이 나한테 안 왔는지 궁금해!프로데고 23:06, 2006년 11월 28일 (UTC)

고마워, 지금은 그 기능을 이해하지만, 여전히 내게는 효과가 없어. --Fbv65edel / tt / cc 23:30, 2006년 11월 28일 (UTC)

그것은 소프트웨어가 실수로 새로운 변화를 망치지 않고 오래된 것을 되돌리는 방법을 명료하게 알아낼 수 있을 때에만 효과가 있다.사용자 A가 한 섹션을 변경하고, 사용자 B가 다른 섹션을 변경하고, 사용자 A가 변경 사항을 되돌릴 수 있게 되었을 때, 나는 마침내 그것을 작동시켰다.(하지만 섹션은 반드시 사전에 존재해야 한다...) 이제 모든 사람들은 갈등을 해결하는 방법을 제대로 분별할 수 있는 더 나은 AI 능력을 갖출 것을 미디어위키에게 요구할 것이다. --Interiot 23:39, 2006년 11월 28일 (UTC)

나는 너처럼 두 개의 계정이 없기 때문에 User talk를 편집했다.인터리어트AWB. 다른 섹션을 편집한 다음 편집을 취소해 주시겠습니까?고마워! --Fbv65edel / ☑t / ☛c 23:44, 2006년 11월 28일 (UTC)

나는 이 특집을 썼다.당신이 어떤 계정을 사용하느냐는 실행 취소의 성공 여부와는 아무런 관계가 없다.소프트웨어에서 단일 비온탑 편집을 모호하게 되돌리는 방법을 알아낼 수 있다면 unos는 작동될 것이다.즉, 해당 특정 단락을 변경하기 위해 실행 취소할 편집이 마지막 비반전 편집이어야 함을 의미한다.가능하면 버튼만 (undo)하게 하는 것을 고려 중이야.— Werdna talk visit 07:07, 2006년 11월 29일 (UTC)

이에 대한 문서를 m:에 추가하려고 했다.도움말:반복하고, 이것이 어떤 기능을 하는지 더 잘 알고 있는 사람이 개선해 주면 고맙겠다(예를 들어, 문단에서만 효과가 있는지 몰랐다).--ais523 13:58, 2006년 11월 29일 (UTC)

내가 아는 한, "undo"는 단 한 번의 편집만 취소한다.만일 그렇다면, 사용자가 이러한 모든 변경사항을 취소하고 있다는 인상을 받을 수 있으므로, 두 개 이상의 편집을 다루는 디프에는 이 변경사항이 나타나지 않아야 한다.Tizio 16:25, 2006년 11월 29일 (UTC)

include bot는 nowiki 태그 내에서 변경해서는 안 된다.

사용자 대화 페이지에 있는 경우

<노위키>{{welcome}}</노위키>

WinBot Bot은 "welcome"을 "subst:welcome"으로 바꾸었다.그건 잘못된 것 같아.하지만 해결책은 내가 이 게시물에서 했던 것처럼 더 많이 하는 것 같아.즉, 템플릿 코드를 nowiki 섹션으로 구분하십시오.그것이 가까운 장래에 권고되는 행동 방침이 될 것인가, 아니면 봇이 노위키 문맥을 이해하도록 가르칠 것인가?나는 그 맥락을 인식하는 것이 매우 어려울 것이라는 것을 믿을 수 있었다.그리고 때로는 부적절할 수도 있다.--SportWagon 15:25, 2006년 11월 28일 (UTC)

시작 템플릿 자체가 다음을 포함하도록 확장됨

<code><nowiki>{{helpme}}</nowiki></code>

코드 태그로 테스트해 보겠지만 그게 차이를 만든다는 게 믿기지 않아.분명히 헬프미 템플릿은 변전소와 함께 사용하도록 설계되지 않았지만 나중에 변경되었다면, 아마도 확장된 환영을 소급해서 변경하는 것이 맞을까?--SportWagon 15:38, 2006년 11월 28일 (UTC)

봇 소유자의 대화 페이지에 메시지를 남겨라.그 봇은 &lt;nowiki>나 &lt;pre]토지 안쪽에 변위해서는 안 된다.그건 오류야. --Ligulem 15:42, 2006년 11월 28일 (UTC)

내 토크 페이지에는 실험으로 변전소가 없는 환영 템플릿도 있었다.윈봇이 이를 바로잡기 위해 왔을 때, 노위키 버전도 잘못 수정했다는 주장이다.즉, nowiki 버전만 만들어졌어도 문제가 발생하지 않았을 것이다.문제가 해결되었는지 아닌지는 확실하지 않지만, 이 정보는 그 문제를 더욱 적합하게 한다.--SportWagon 13:52, 2006년 11월 29일 (UTC)

더 많은 실험은 그 문제가 근본적으로 고쳐지지 않았다는 것을 암시한다.그러나 Bot를 활성화하는 프로세스가 동일한 사용자 토크 페이지에서 "subst"가 없는 진정한 "welcome" 템플릿을 먼저 찾지 않는 한 잘못된 대체는 일어나지 않을 것이다.즉, 환영 템플릿의 실험적인 "나쁜" 사용은 nowiki가 사용하지 않는 곳에 "하위"가 추가되도록 했다.내가 제안한 nowiki에 대한 난독화는 또한 사람들이 예상하는 것처럼 또 다른 예를 "보호"했다.따라서 이것은 일반적으로 템플릿을 잘못 사용한 사람들에게 사소한 문제가 될 것이고, 개정 로그는 무엇이 행해진지를 보여주므로, 이것은 대부분 현재 FYI에 불과하다.--SportWagon 17:25, 2006년 11월 30일 (UTC)

이름이 같은 잘못된 항목에 대한 링크

나는 한 페이지에서 (군내보다는) 전국 각지에 있는 다른 초등학교로 향하는 세 개의 초등학교 링크를 발견했다.어떻게 하면 그 링크를 죽일 수 있지만, 텍스트를 빨간색으로 유지할 수 있을까? 마치 죽은 링크인 것처럼?

레이맨스 피크에게 미안하다.

구체적으로 무슨 뜻인지 보려면, "루둔 카운티 공립 학교"로 가서 초등학교 아래에서 "호라이즌 초등학교"를 클릭하십시오.지금 캐나다 BC에 어떻게 살고 있는지 주목해라.

루둔 카운티 공립학교 기사의 링크를 [Horizon 초등학교(버지니아 주 루둔 카운티)]로 변경할 수 있다.Horizon 초등학교]]]].그러나 나는 누군가가 학교에 대해 의미 있는 기사를 쓰는 그런 시간이 될 때까지 그 링크를 제거하기만 할 것이다. (그리고 그것은 결코 "호라이즌 초등학교"가 아니라 "호라이즌 초등학교"가 되어서는 안 된다.사용자:Zoe (대화) 19:53, 2006년 11월 28일 (UTC)

클래식한 피부에서는 볼 수 없는 피처링된 기사

안녕, 클래식 스킨을 사용하는 사람들에게는 오른쪽 상단 가장자리에 있는 작은 별이 보이지 않기 때문에 기사가 특집 기사라는 힌트가 없어.그것을 고칠 수 없을까? --Nina 10:14, 2006년 11월 28일 (UTC)

아니, 인터위키스가 고전적으로 행해지는 방식 때문에.모노북에서는, 페이지에는 몇몇 끔찍한 CSS 해킹을 사용하여 별을 구석에 놓을 수 있는 충분히 순서화된 구조가 있다. 고전적으로 인터위키스의 수는 페이지마다 다르지만, 페이지 위에 표시되기 때문에, 어떤 페이지에서는 별의 위치가 틀릴 수도 있다.(내가 틀렸으면 고쳐줘. 이 답은 기억에서 나오는 거야.) --ais523 10:19, 2006년 11월 28일 (UTC)

음, 좋아, 인터위키스네.하지만 나는 그것이 작은 스타든, 특집 기사를 나타내는 범주든 상관하지 않는다.예를 들어, de:에서 FA-템플릿은 다음과 같은 범주를 포함한다.특집 기사.아마도 이 범주가 클래식에서만 보일 수 있을까? --Nina 12:02, 2006년 11월 28일 (UTC)

템플릿 대화에서 다음과 같은 종류의 내용을 제안하십시오.주요 기사: --ais523 12:07, 2006년 11월 28일(UTC)

실제로, 당신은 당신의 standard.css 파일(사용자 페이지의 하위 페이지)에 약간의 css를 추가하여 스타가 고전적으로 나타나도록 할 수 있다.예를 들어 사용자:를 참조하십시오.Hidnjo/standard.css. -- Rick Block (토크) 14:30, 2006년 11월 28일 (UTC)

고마워, 내가 한번 해볼게.하지만 특집기사를 표기하는 것이 일반적인 관심사라고 생각했기 때문에 모든 클래식한 피부사용자를 위해 누군가가 그것을 고칠 수 있기를 바랐다. --Nina 13:16, 2006년 11월 29일 (UTC)

인터위키스가 없는 FA, 인터위키스가 2개인 FA, 인터위키스가 31개인 FA, 인터위키스가 59개인 FA(내가 정확히 계산한 경우)를 클래식 스킨(URL에 포함)을 사용하고 위에 링크된 CSS 픽스와 비교하라; 페이지와 관련된 별의 위치는 인터위키 카운트에 따라 다르다.이것은 인터위키 링크에 대한 브라우저에서 사용하는 글꼴 크기가 행 끝에 있는 언어의 이름과 겹치는 경우 (특히 마지막 링크에서) 문제를 일으킬 수 있다.이런 일이 일어나지 않도록 CSS도 인터위키스를 고칠 수 있을 것 같은데 잘 모르겠어. --ais523 13:41, 2006년 11월 29일(UTC)

MediaWiki가 끝난 후 우리는 그것을 사용할 수 없을까?태그라인?Titoxd^(?!?) 16:30, 2006년 11월 29일 (UTC)

그래, 문제가 보인다.스타 대신 카테고리로 하면 해결된다.Template talk에 대해 많은 논의가 있다.피처링 기사, 그리고 그들이 이미 카테고리에 대해 결정했는지 알아보기 위해 이 모든 것을 읽지는 않았다. --Nina 13:48, 2006년 11월 29일 (UTC)

사용자 페이지를 볼 수 없음

사용자 페이지를 보는 데 문제가 있음.내가 볼 수 있는 것은 페이지 상단에 아주 작은 글씨체로 되어 있다.

<script type="text/light" src="/w/index.php?title=-&action=raw&smaxage=0&gen=js

나는 이 페이지 편집 버튼 등을 포함한 다른 어떤 것도 볼 수 없다.어제는 완벽하게 보였다.어떤 도움이라도 정말 고마워!감사합니다, Jam01 06:51, 2006년 11월 28일 (UTC)

나는 지금 페이지를 볼 수 있다.불편을 드려 죄송합니다. 근데 왜 그런 일이 일어났는지 아는 사람 있어?감사합니다, Jam01 06:53, 2006년 11월 28일 (UTC)

간헐적인 서버 문제일 수 있음:위키피디아는 페이지를 정리하기 위한 상호운용 서버의 복잡한 배열이다.공은 수십 가지 방식으로 뒤범벅이 될 수 있었는데, 그것은 자주 일어나는 일이 아니지만, 우리 모두가 가끔 그런 이상한 것들을 볼 정도로 자주 발생한다.다음에 브라우저 캐시를 지우고 서버 캐시를 지울 수 있다.— EncMstr 06:59, 2006년 11월 28일 (UTC)

그래, 충고 고마워!다시 그런 일이 생긴다면 그렇게 해보겠다.고마워!Jam01 08:45, 2006년 11월 28일 (UTC)

외부 편집기, 마크업 언어, 파일 형식

편집에 외부 편집기(있는 여러 편집기 중 하나)를 사용하려고 한다.편집 상자 창에서 데이터를 가져와 편집기로 가져올 수 있지만 *.wiki가 아닌 텍스트 파일로 입력(예를 들어 vim에 대한 지침은 vim을 프로그래밍하여 *.wiki 유형의 파일을 자동 검색하여 마크업 언어가 사용되도록 함) 이 데이터를 *.wiki로 전달하는 특별한 방법이 있는가?SFinside 04:53, 2006년 11월 28일(UTC)

연결 끊김으로 인해 예기치 않은 편집

첫째, 위의 약 15%가 이해할 수 있다는 것을 알게 되었다.나는 이것이 기술적인 토론 페이지라는 것을 알지만, 어떤 답변이든 "dumbdown"해줘.내 배경은 오래된 8비트 BBS sysop으로, 웹은 학교 다닐 때 새것이었고, 직장에서 Windows와 Mac 컴퓨터(데스크톱 출판, GIS, 카토그래피, &c)를 사용해 보았지만 유지보수와 거의 관련이 없었고, 2년여 전 처음으로 "실제" 컴퓨터(Windows 98, 나는 아직도 인베이드 컴퓨터에서 사용하고 있다)를 얻었다.나는 위키피디아를 비교적 처음 접한다.

여기 문제가 있다(그리고 여기가 맞는 곳인지 잘 모르겠다):(전화 접속) 서버 연결이 끊겨 로그오프되었을 때 편집을 위해 큰 토크 페이지가 열려 있었다.(그 반대였을 수도 있다)하룻밤으로 하기로 하고 나중에 토크 페이지를 확인해보니 편집 중이던 섹션의 일부가 서버와 연결된 IP 주소로 삭제되었다.누락된 자료를 삭제하는 과정도 아니었고, 추가했던 것은 하나도 저장되지 않았다.

연결이 끊겨 진행 중인 작업을 그대로 저장한 것은 이해할 수 있지만, 왜 아무것도 삭제되었을까?

이 대화와 관련될 수 있는 문제는 상태 표시줄에 "완료"가 표시되지만 동일한 큰 대화 페이지가 내 브라우저(Firefox)에 완전히 로드되지 않는 경우가 있다는 것이다.몇 번의 시도(사이에 캐시를 지우는 것)로 문제가 해결되지만, 인터넷에 접속하려면 국제 요금(낙원에 사는 것)을 내야 한다.

내가 문제를 해결하기 위해 하는 일은 보통 오프라인에서 편집 내용을 작성하여 붙여넣는 것이다.하지만 인터페이스 사용법만 익히고 있어 포맷에 많은 시간을 할애하고 있다.나도 이제 방법을 알게 되었으니 문제의 페이지를 보관할 거야.

댓글로.

.s

X ile 11:52, 2006년 11월 27일(UTC)

우선 전화 접속 연결도 있고, 당신의 아픔도 느껴져.당신의 질문에 대해서는, 위키피디아가 편집 내용을 저장하는 방법 때문에 가능하다.페이지를 편집하면 페이지의 전체 내용이 새 수정본으로 저장된다.한 페이지를 비우는 것이 가능한 것은 그것 때문이다.연결이 끊겼을 때 페이지 내용이 조금 저장되었지만 모두 저장되지는 않았다.따라서 일부 내용을 삭제한 것으로 보인다.이를 위한 한 가지 방법은 섹션 편집을 사용하는 것일 수 있다.이 페이지 편집 탭을 클릭하는 대신 페이지에서 편집할 위치를 찾은 다음 위로 올라가 가장 가까운 헤드라인을 찾을 수 있다.오른쪽에서 "편집" 링크를 누르면 해당 섹션 내의 페이지 내용만 편집된다.그것은 미래에 이런 일이 일어나지 않도록 하는데 도움이 될 것이고, 심지어 편집 페이지를 로드하고 페이지를 저장할 때 시간을 절약할 수 있을 것이다.이것이 당신의 질문에 대한 답을 주길 바란다.&nbsp;Shardsofmetal&nbsp; 03:14, 2006년 11월 28일(UTC)

알았어. 생각해보니, 지역 전화 교환-레이디오텔레폰-사텔라이트 전화 접속-전화 접속 서버-&c 연결을 지나치게 기술적으로 다루지 않을 방법이 없어.혼돈자가 너무 많아.이런 일이 더 자주 일어나지 않는 것이 놀랍다.'반달리즘'이라는 경박한 불만이 나올까 봐 걱정했는데, 이게 알려진 문제인 것 같다.

섹션 편집은 좋은 팁이고, 나는 그것을 사용해 본 적이 있다(때로는 잊어버린다.내 경우는 편집하던 부분마저 다소 길어져 있었다.도와줘서 고맙습니다.

불행히도 나는 삭제된 섹션의 일부에 대한 코멘트를 요청하기 위해 다른 편집자의 토크 페이지로 갔었다.나는 코멘트를 하기 전에 누락된 부분을 되돌리지 않은 것(분명히--그리고 내가 어떻게 고쳐야 할지 모르는 문제가 있다는 것도 알려주었다)에 약간 실망했다.

나는 오려 붙이는 일을 했다.이건 무슨 에티켓이야?독자들이 알아야 할 불연속성이 있지만, 나는 그것을 토크 페이지에서 지적하는 적절한 방법을 알지 못한다.기사였다면 편집 요약으로 충분할 것 같았다.삭제로 인해 Talk 페이지의 토론에 차질이 생긴 것은 충분한가?다른 사람의 논평에 [브래킷된] 편집 노트를 삽입해야 할까?더 할까?덜? 편집 요약 말고는?

무슨 장난으로 비난받고 싶지는 않지만, 만약 내가 (새 사용자로서) 다른 쪽에 있다면 비슷한 비난을 하는 것을 볼 수 있었다.

.s

X ile 23:42, 2006년 11월 29일 (UTC)

Mac OS X에서 Wikipedia Bot 개발

Mac에서 봇을 개발할 수 있는 도서관이 있는가?파이썬 도서관을 알고 있지만 오토매이터나 애플스크립트 확장 같은 Mac 친화적인 도서관이라면 사파리 도우미...이용 가능한가?야오쯔위안 09:51, 2006년 11월 27일 (UTC)

완전 자율형 봇(Botton)을 사용하는 경우 Python - code를 사용할 수 있으며 OS X에서 완벽하게 작동한다. Zetawoof^(&zeta;) 20:23, 2006년 11월 28일(UTC)

지정된 범주의 임의 페이지

무작위 싱글, 배우, 정치인 등 주어진 범주에서 무작위 페이지를 잡을 수 있는가?크리스 치즈가 윙윙거리는 01:16, 2006년 11월 27일 (UTC)

No. Tra (Talk) 01:49, 2006년 11월 27일 (UTC)

카테고리를 나열하고 눈을 가리고 클릭하는 건 어때?— EncMstr 07:06, 2006년 11월 28일 (UTC)

랜덤 카테고리 옵션이 있으면 좋을 것 같아.사용자:Zoe(대화) 19:47, 2006년 11월 28일(UTC)

범주의 임의 페이지가 아닌 임의 범주는 특수:임의/범주. --ais523 17:25, 2006년 12월 5일(UTC)

Mediazilla:2170 —시뮬레이션(talk&nbsp;•&nbsp;controlls) 03:23, 2006년 11월 29일(UTC)

바이러스 가능성?

이것은 방금 아칼라마리에 의해 내 토크 페이지에 게재되었다.

친애하는 Chris Griswold씨(ChrisGriswold)에게,

당신은 내가 질문하거나 이야기할 것이 있으면 당신에게 연락할 수 있다고 말했다.음, 나는 최근에 "크리스티나 아길레라" 위키피디아 페이지에 그녀를 찾아보고 있었고, 그리고 나서 그녀의 싱글 앨범과 앨범에 관한 페이지에 올라갔어.

그녀의 메인 페이지, 싱글 앨범 또는 앨범 페이지에 있는 사진들 중 하나는 바이러스에 감염되었다.나는 그것이 다른 것 중 하나일 수도 있지만 "더티"나 "스트라이핑"이라고 믿는다.내 바이러스 검사기는 확실히 그 페이지들 중 하나에서 바이러스를 찾아냈다.

이것은 매우 중요하다.나는 이 일에 대해 당신에게 즉시 경고하는 것이 현명한 생각이라고 생각했다.위키피디아에서 바이러스는 반달만큼 환영받지 못한다.

위키리크에 있는 건 알지만, 토크 페이지에서 계속 대화하고 있잖아.내가 생각할 수 있는 첫 번째 행정관이자 내 토크 페이지에 코멘트를 남긴 유일한 행정가는 너야.이것은 긴급한 사안이다.나는 장난하는 것이 아니다: 내 바이러스 검사자는 크리스티나 아길레라 사이트(주요 사이트, 싱글 또는 앨범)에서 뭔가를 찾아냈다.

나는 다른 사람들이 바이러스에 감염되기 전에 이 문제가 빨리 해결되기를 바란다.2006년 11월 26일 아칼라마리 19:05 (UTC)

나는 이런 종류의 사업에 대해 전혀 알지 못하며, 지금 당장 나가야 하니까, 이걸 너에게 갖다 주겠다.누가 좀 알아봐 줄래?고마워. --Chris Griswold (인터뷰) 2006년 11월 26일 (UTC) 19시 8분

당신의 컴퓨터에 모든 업데이트가 제대로 되어 있는 한, 웹 페이지는 당신에게 아무런 해를 끼쳐서는 안 되기 때문에 나는 걱정할 것이 없다고 생각한다.트라(Talk) 2006년 11월 26일 19:21(UTC)

예, 하지만 업데이트가 없는 사용자는 어떤가?위키피디아가 바이러스를 퍼뜨려서는 안 된다. --크리스 그리즈월드 (인터뷰) 12:18, 2006년 11월 27일 (UTC)

문제를 일으키는 것은 어떤 이미지인가?이것을 모르고 토론하는 것은 좀 무의미하다. --TheParanoidOne 13:36, 2006년 11월 27일 (UTC)

나는 그것이 "Dirrty" 사진이나 "Stripped" 사진이라고 믿는다.사용자: Tra는 그들이 사진을 편집했다고 말했다.하지만, 만약 바이러스가 내 바이러스 검사기에 다시 나타난다면, 나는 그것이 어떤 파일이었는지 알아낼 것이다.아칼라마리 16:24, 2006년 11월 27일 (UTC)

이에 대한 자세한 내용은 내 토크 페이지의 이 섹션을 참조하십시오.Tra (Talk) 16:55, 2006년 11월 27일 (UTC)

다른 웹사이트나 다른 컴퓨터 프로그램 같은 다른 것에서 바이러스가 나올 가능성에 대해 생각해 본 적이 있는가?_JD^talk 2006년 11월 27일 16:26 (UTC)

그럴 필요가 없었다.나의 바이러스 체커는 그 바이러스가 위키피디아에 있는 "크리스티나 아길레라" 페이지 중 하나에서 나왔다는 것을 분명히 지적했다.바이러스가 출현했을 때 다른 웹사이트에 가본 적이 없었고 크리스티나 아길레라의 웹사이트에도 가본 적이 없었기 때문에 위키피디아에 있는 사진에서 바이러스가 나왔다는 사실을 알아내는 것은 어렵지 않았다.만약 그것이 다시 나타나면, 나는 그것을 다시 보고할 것이다. 그리고 바라건대, 나는 더 많은 증거를 가지고 있을 것이다.내가 알고 싶은 것은, 애초에 바이러스가 위키피디아에 어떻게 들어왔을까?아칼라마리 17:17, 2006년 11월 27일 (UTC)

어떤 안티바이러스 소프트웨어를 사용하십니까?_JD^talk 2006년 11월 27일 19:31(UTC)

관련성은 알 수 없지만, 나의 바이러스 체커는 AVG; 프로그램 버전: 7.5.431(2006년 11월 27일 현재)이다.왜 내 경고에 불신이 있는지 물어봐도 될까?바이러스를 분리하려고 하는데 왜 내 바이러스 검사기에 대해 의논하는 거지?내가 직접 (아직 위키피디아에 있다고 가정할 때) 바이러스를 격리시키고 그것이 정확히 어디에 있는지 곧 알아내도록 노력할 것이다.아칼라마리 22:09, 2006년 11월 27일 (UTC)

미안해, 내가 전에 했던 코멘트에 서명하는 걸 깜빡했네.어쨌든, 내가 바로잡았어.나는 바이러스를 찾기 위해 크리스티나 아길레라 페이지(메인 페이지, 앨범, 싱글)로 돌아왔다.사진이 모두 깨끗하다.사용자: 사진으로 "인쇄 화면" 트릭을 할 때 문제를 분명히 해결하십시오.지금으로서는 이 토론이 끝나야 하는데, 누군가 그것에 대해 다른 할 말이 없다면 말이다.아칼라마리 22:09, 2006년 11월 27일 (UTC)

불신의 문제가 아니다.사실의 문제나 확증이다. --TheParanoidOne 22:51, 2006년 11월 27일 (UTC)

당신은 또한 바이러스 검사자들이 끊임없이 가짜 히트작을 만들어 낸다는 것을 알아야 한다 - 바이러스가 없을 때 바이러스가 있다고 주장하는 것이다.이것은 일이 심각하게 받아들여지지 않는다는 것을 의미하지는 않지만, 여러 가지 다른 도구로 세심한 검사가 필요하다는 것을 의미한다.Notinasnaid 09:45, 2006년 11월 28일 (UTC)

바이러스가 있었는데 내 바이러스 검사원이 찾아냈어나는 이번 일이 내 바이러스 검사원이 거짓말을 할 수 있는 일이 될지 의심스럽다. 그리고 좋은 바이러스 검사자는 "허위 치기"를 등록해서는 안 된다.내가 말했듯이, 이것은 가볍게 취급될 대상이 아니며, 현재로선 크리스티나 아길레라 페이지에 있는 사진들과 다른 자료들은 모두 깨끗하다.아칼라마리 15:59, 2006년 11월 28일 (UTC)

어떤 종류의 이미지, JPEG?GIF, BMP 또는 PNG와 같은 JPEG는 실행되지 않으며 브라우저가 이 JPEG를 사용하여 수행하는 유일한 작업은 디스플레이다.그것은 어떤 종류의 해를 끼칠 수 없다.한편, 바이러스 검사자들이 바이러스를 발견하는 방법은, 적어도 알려진 바이러스에서 발견된 바이트의 패턴과 일치하는 바이트의 패턴을 찾아내는 것이다.가끔, 바이러스가 아닌 파일은 그런 패턴과 일치하는 바이트 세트를 갖게 될 것이다.즉, 거짓 양성이 가능하다. --Largo Plazo 15:49, 2006년 12월 1일 (UTC)

유감스럽게도, 브라우저가 반드시 버그가 없는 것은 아니며 다운로드한 데이터가 우발적인 실행으로부터 보호되지 않기 때문에 이것은 반드시 사실이 아니다.예: [1]을 참조하십시오.—Blotwell 18:31, 2006년 12월 1일(UTC)

그 파일은 JPEG일 가능성이 높았지만, 나는 Haw가 관련이 있다고 생각하지 않는다.바이러스가 없어졌다.나는 크리스티나 아길레라 사이트에 갔었고, 그들은 괜찮아.그 사이트들은 지금 아무 문제도 없다.나는 지금 바이러스에 대한 큰 문제가 무엇인지 모르겠다.바이러스는 제거되었고, 만약 바이러스가 다시 온다면 더 많은 증거를 가지고 다시 보고하겠다고 말했다.왜 다들 내 바이러스 검사기와 나 둘 다 믿지 않는지 모르겠어.나는 많은 사이트에 가봤지만 바이러스에 걸린 적은 한 번도 없었다.누군가 바이러스에 감염된 사진을 위키피디아에 올렸다.넌 내가 거짓말을 했다는 것을 암시하는 대신에 어떻게 바이러스가 위키피디아에 퍼졌는지 알아내야 한다.나는 거짓말을 하기 위해 위키피디아에 등록하지 않았다.아칼라마리 19:53, 2006년 12월 2일 (UTC)

바이러스가 위키피디아에 들어온 경위에 대해서는 DCEdwards1966(토크 · 기여)과 스트로코플럭(토크 · 기여)에 의해 두 개의 이미지가 업로드되었다.트라 (Talk) 2006년 12월 2일 20:13(UTC)

바이러스 스캐너가 감염된 파일을 찾아냈어.저서 문제해결, PC 유지·보수(제2판) (ISBN 0-07-913732-6)에 따르면, 섹션 영역 「바이러스 증상과 대책」 부분 「바이러스 신화」(#1329 페이지)와 내가 인용한다(아래로부터).

• 바이러스는 데이터 파일 안에 숨지 못한다. 데이터 파일(예: 이미지)은 컴퓨터에 바이러스를 퍼뜨릴 수 없다.실행 가능한 프로그램 파일(및 실행 가능한 매크로를 포함하는 파일)만이 바이러스를 퍼뜨릴 수 있다.컴퓨터 바이러스는 데이터 파일을 감염시킬 수 있지만, 그것은 쓸모없는 노력이 될 것이다. 왜냐하면 데이터 파일이 실행되지 않고, 로드만 되기 때문에, 바이러스는 스스로 실행하거나 복제할 수 없을 것이기 때문이다.
  

이미지는 데이터 파일이다.이미지에는 매크로를 사용할 수 없다.이미지가 로드될 뿐 실행되지 않는다.그 세 가지 진술은 위의 텍스트 단락을 요약한다.걱정할 것 없다.하지만...

• 업로드할 때 감염이 되었으면 컴퓨터를 스캔해야 한다.
• 업로드할 때 감염되지 않았다면 모든 WikiPedia 서버를 검사해야 하며, 모든 사용자에게 가능한 바이러스를 검사하도록 지시하는 바이러스 통지가 제공되어야 한다(WikiPedia에는 실행 가능한 응용 프로그램이 없지만 javascript로 구동되는 javascript는 하나의 큰 매크로와 같다).

다른 정보가 필요하면 연락해.잊지 말고 나를 도와줘(사용자 및 사용자 대화 페이지에 대한 세부 정보)
컴퓨터와 크리켓 마스터
--크리켓 보이 03:35, 2006년 12월 4일 (UTC)

너의 책은 아주 간단히 틀렸다.그것은 "대상 컴퓨터의 소프트웨어에 큰 결함이 없는 경우"라는 중요한 단서를 생략했다.버퍼 오버플로가 무엇인지, 데이터 파일을 통해 바이러스를 전파하는 데 어떻게 악용될 수 있는지 모른다면, "컴퓨터 마스터"라는 호칭을 삭제하는 것이 좋다.—시뮬레이션(talk&nbsp;•&nbsp;controlls) 07:30, 2006년 12월 5일(UTC)

나는 위키피디아에 바이러스가 오면 내가 그것을 보고하고 그것을 증명할 더 많은 증거를 가지고 있다고 약속했다.아칼라마리 17:16, 2006년 12월 5일 (UTC)

Wikipedia는 Firefox 또는 IE에서 로드되지 않으며 AOL에서만 로드됨

안녕 여러분, 나는 네가 내가 겪고 있는 이 작은 문제를 해결해 줄 수 있기를 바랐어.컴퓨터에서 Firefox나 IE를 사용할 때 위키피디아에 접근할 수 없다.이상한 점은 AOL 브라우저에서 잘 작동한다는 것이다.나는 실제로 항상 파이어폭스를 이용하기 때문에 위키피디아를 꽤 자주 방문하기 때문에 상당히 답답하다.나는 Firefox에서 모든 추가 기능을 제거해 보았지만 IE에서 동일한 문제가 발생하는 것을 보면 그것이 원인이 아니라는 것을 거의 확신한다.뭐가 잘못됐을지 짐작조차 할 수 있는 지식이 없다.내가 아는 거라곤, 내가 생각하기에 이것을 야기할 수 있는 브라우저 중 어느 것도 바꾸지 않았다는 것뿐이에요.나를 도와줄 수 있는 누구에게도 고마워!

씨리얼 킬러 07:45, 2006년 11월 26일 (UTC)

"접근 불가"의 의미는 무엇인가?뭐가 보이니?전에 그 컴퓨터에서 작동했던 적이 있었니?Firefox를 제거하고 다시 설치하는 것은 어떠세요?— EncMstr 08:00, 2006년 11월 26일(UTC)

아무것도 싣지 않는다.Firefox에서는 공백으로 유지되며 작은 "Loading...메세지.IE에서, 아무것도 하지 않고 1분 정도 있다가, 위키피디아로 연결되는 링크를 나열하는 "Weer you looking..." 페이지로 이동한다.

시리얼 킬러 08:42, 2006년 11월 26일 (UTC)

내가 문제를 알고 있는 것 같아.인터넷 옵션이 잘못 설정되었을 수 있다.Windows인 경우 IE에 패치를 적용할 수 있으므로 Windows Update를 사용해 보십시오.너 또한 파이어폭스를 패치해야 할지도 모르지만, 나는 그 회사가 무엇이라고 불리는지도 모르기 때문에 어떻게 해야 할지 모르겠다.나로서는, 내가 이 스레드를 편집하기 위해 Internet Explorer를 사용하고 있기 때문에, 그것은 꽤 이상하게 들린다.버전 #는 6.0.2900.2180이다.게다가 AOL을 통해서만 접속할 수 있기 때문에, AOL이 여러 개의 다른 IP를 사용하기 때문에 표준 IP주소에 위키피디아에 문제가 있을 수 있다.물론 나는 이 문제를 경험한 적이 없기 때문에 확신할 수 없다.아, 그리고 "접근 불가능"은 아마도 단지 브라우저가 인터넷에서 그 페이지를 찾을 수 없다는 것을 의미할 것이다.

크리켓과 컴퓨터 전문가로서 승인하면
--크리켓 보이 01:55, 2006년 12월 3일 (UTC)

왼쪽 정렬된 이미지 묶음

이것은 영원한 질문일지 모르지만, 나는 어디서도 답을 보지 못했다.더 넓은 화면에서는 때로는 좌로 정렬되고 때로는 우로 정렬된 이미지가 뭉쳐져 페이지 측면에서 멀어지며 텍스트가 없는 간격이 생긴다.오늘 밤 특집 기사에서 특히 나쁜 예를 우연히 들었다.네 개의 이미지가 쌓여서 1920px 와이드 브라우저의 절반 이상을 소비했다.때때로 작동하는 케이스 바이 케이스 픽스(case by case)를 본 적이 있지만 결코 단정적으로 보이지 않는다(예: 지금 기사를 수정하더라도 30" Dell/Apple 디스플레이로 업그레이드하면 또 고장날까?)가능한 모든 해결을 위해 이 문제를 확실하게 해결할 수 있는 좋은 방법이 있는가? --Interiot 09:13, 2006년 11월 25일(UTC)

&lt;br style='clear:bothy'&gt;가 해결책일 수 있다.텍스트 뒤에 놓으면 공백이 발생하지 않고 페이지 양쪽으로 확장되는 빈 줄이 만들어진다.

그 결과는 다음과 같다.

Lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lolem ipsum lorem ipsum은 너무 게을러서 lorem ipsum이 어떻게 지속되는지 볼 수 없다.

로렘 입숨.

더 많은 지식 입숨.

어쨌든, 그 기사는 이제 혼합 맞춤으로 포맷되었다.하지만 이것은 또한 유용할 수 있다.

—Nethac DIU, 항상 여기서 말함.
2006년 11월 25일 11시 44분(UTC)

아니면 이미지를 테이블에 넣을 수도 있지만, 기사에 별로 좋지 않을 수도 있다; 그것은 많은 이미지를 담고 있다. 11:49_JD^talk, 2006년 11월 25일 (UTC)

당신은 첫 번째 사진의 나쁜 예시가 당신의 요점을 정확하게 증명하기 때문에 당신은 확실히 좋은 예시를 의미한다는 것을 나타낸다.이것은 매우 통속적인 문법적 실수의 좋은 예다 :) 다이나모 14:01, 2006년 11월 25일 (UTC)

개인적으로는 {{clear}}템플릿을 사용하겠다.내가 위의 예시를 네가 무슨 뜻인지 알 수 있도록 조정했어.물론, 템플릿은 네가 나열한 br코드로 가는 지름길일 뿐이야HTML을 모르는 사람은 타이핑하기가 더 쉽다. --Brad Beattie 15:52, 2006년 11월 25일(UTC)

그리고 정말 게으른 사람에게는 {{-}}(그리고 기술적으로 둘은 다른 태그, {{clear})이 비어 있다.div반면 {{-}}은(는) a이다.br 태그. EVULA// talk // &#9775; // 16:20, 2006년 11월 25일(UTC)

WP를 읽어보십시오.번치. -- 릭 블록 (토크) 16:38, 2006년 11월 25일 (UTC)

사실, 이것은 단지 미디어위키 CSS: Bug 6016 on Bugzilla에서 잘못 부호화된 것이다.서커스 01:28, 2006년 11월 27일 (UTC)

트렁크에서 고쳤으니 더 이상 문제가 안 될 거야—시뮬레이션(talk&nbsp;•&nbsp;controlls) 02:45, 2006년 11월 29일(UTC)

라틴 문자가 아닌 문자의 상위 태그 지정

일반적으로 기사 제목의 첫 글자가 대문자로 자동 변환되는 이유를 이해한다.

1. WP 협약은 개 기사가 "개"라는 제목을 붙여야 한다는 것이다.
2. 우리는 개에 대한 링크를 올바른 기사로 보내길 원한다.
3. 우리는 확실히 "개"와 "개"가 뚜렷하게 사용되는 것을 원하지 않는다; 즉, 우리는 두 개의 다른 기사를 원하지 않는다.

그러나 첫 글자가 라틴 문자가 아닐 때는 이러한 고려사항 중 어느 것도 적용되지 않는다.WP의 수학과 과학 영역에서 우리가 소문자 그리스 문자로 시작하는 기사를 가질 수 없다는 것은 지속적인 골칫거리다; 이런 경우, 문제의 문자는 결코 상투적인 것이 아니다; 그것은 상당히 잘못된 것이다.게다가, 그 사건들은 심지어 뚜렷하게 사용될 수도 있다. 오랫동안 나는 W에 Real Soon Now 기사를 쓰려고 했었다. 휴 우딘의 Ω-로직 (자세한 설명은 참조)Woodin, W. Hugh (2001). "The Continuum Hypothesis, Part II" (PDF). Notices of the AMS. 48 (7): 681–690. 그러나 Ω-logic이라는 전혀 다른 개념이 있다(예: 참조)

그래서 내 의견으로는, en.적어도 위키에는 라틴 문자로 시작하는 글자는 대문자로 하고 라틴 문자가 아닌 문자로 시작하는 글자는 그렇지 않도록 규칙을 수정해야 한다.폴란드의 l-with-a-slash-through-it 또는 umlauted 모음과 같은 거의 라틴 문자에 대한 예외가 있을 수 있다(실제로 나는 그리스 문자만 uppercasing에서 제외된다면 기쁠 것이다).분명히 그리스 WP에서는 상황이 달라져야 할 것이지만, 확실히 소프트웨어는 그것을 허용하기에 충분히 민첩하거나 쉽게 그럴 수 있다. --Trovatore 07:25, 2006년 11월 25일 (UTC)

중기적으로는 소문자 제목으로 전시할 기사를 표기하는 것이 가능해진다.장기적으로는 결국 더 깨끗한 대소문자 구분 제목 체계로 옮겨가야 한다.(이것은 수백만 페이지와의 역호환성이 주어진 사소한 문제가 아니므로, 그 문제에 대해서는 숨죽이지 말라.) --briion 20:46, 2006년 11월 25일 (UTC)

그 해결책들 중 어느 것도 우리가 정말로 가질 수 있어야 할 Ω-logic이라는 하나의 기사를 가질 수 있도록 허락할 것 같지는 않다.첫 글자가 비라틴어일 때는 대소문자를 구분할 수 없는가? --트로바토어 05:28, 2006년 11월 26일 (UTC)

아니오. 차이점을 명확히 하기 위해 불분명한 마커를 사용하십시오. 그렇지 않을 경우 검색, 링크 등도 복잡해진다는 점을 기억하십시오. --briion 01:12, 2006년 11월 27일(UTC)

소프트웨어 엔지니어로서, 나는 정말로 이것이 극복할 수 없는 기술적 문제라는 것을 믿을 수 없다. (하지만 나는 당신이 그것을 정말 망치고 싶어하지 않는다는 것을 믿을 수 있지만) 그리고 나는 이점이 없다고 본다.위키, 그리스 문자의 자동 어퍼캐싱.영어 위키피디아를 독립적으로 가져가야 하는 이유를 말해줄 사람?그렇지 않다면 영어와 그리스 WP의 상호작용에서 특히 규칙의 차이에 의해 어떤 문제가 발생하게 될 것인가? --Trovatore 16:41, 2006년 11월 27일 (UTC)

주로, 내 생각엔, 너는 너만의 사례 확인 기능을 써야 할 것 같아.대/소문자 구분 스위치로 Regex 기능을 수행하시겠습니까?아니, 유니코드를 처리하고 동시에 C(++)의 일부 상위캐스팅만 확장자로 간주하려면 다시 작성해야 한다.마찬가지로 대소문자를 구분하는 모든 문자열 라이브러리 기능.할 수 있어?물론입니다.우리가 하고 싶은 거?그렇진 않아, 몇 가지 기사를 위해서가 아니라구.가장 좋은 방법은 하나와 약간 다른 이름을 찾는 것이고 연결고리를 혼란스럽게 하는 것이다.이름이 너무 비슷하니까 네가 원하는 거겠지—시뮬레이션(talk&nbsp;•&nbsp;controlls) 02:33, 2006년 11월 29일(UTC)

그 약간 다른 이름도 쉽게 할 수 있다.예를 들어, 그것을 오메가 정합성이 있는 이론에 보관해 두어라. 예를 들어, 제거된 "하위 케이스" 템플릿이 부적절하다고 정당화하는 유일한 목적으로 옮기지 말고.Gene Nygaard 19:19, 2006년 12월 3일 (UTC)

진의 사실에 대한 설명은 매우 부정확하다."하위 사례" 템플릿(있는 곳에서도 적절했다)을 정당화하려는 움직임은 아니었다.이삿짐의 목적은 그 편지에는 라틴어 이름보다는 그리스 문자를 사용하는 것이었다.

진이 "오메가 일관성 이론에 보관하라"고 제안한 것은 Ω-로직과 Ω-로직의 구별 문제에 대한 대응으로서 비시퀀텀으로, 둘 중 어느 것도 오메가 일관성 이론을 가리킬 수 없기 때문이다(Ω-로직은 Ω-consistency와 다소 관련이 있지만, 동일 논문에 들어갈 만큼 밀접하지는 않다). 특히 "옴-로직의 일관성이 있다"는 것이다."Ω 일관성"보다 상당히 강하다. --Trovatore 20:20, 2006년 12월 3일(UTC)

바꾸기는 어렵지 않겠지만, 개발자가 변화를 만들어야 하고, 그들은 다소 바쁘다.그러나 만약 당신이 MediaWiki가 쓰여진 언어로 프로그램하는 방법을 알고 있다면 당신은 당신의 코드와 그것을 bugzilla에서 그것을 실행시키기 위한 요청을 제출할 수 있다.위키 소프트웨어의 소스 코드는 여기에서 액세스할 수 있다.프로데고 16:53, 2006년 11월 27일 (UTC)

실수로 또는 너무 빨리 페이지 저장

최근 두 번 나는 편집 요약 상자에 있는 동안 실수로 "Enter"를 누르고 의도하기 전에 페이지를 저장했다.나는 최근 (그리고 매우 환영) 요약 상자가 바뀌기 전에는 이런 일이 나에게 일어난 적이 없다고 생각한다.내가 그저 좀 더 서투르게 되고 있는 것인가, 아니면 "저장 페이지"의 선에 따라 이전과는 다른 기본 옵션이 되는 변화가 생긴 것인가? --Blisca 10:40, 2006년 11월 18일 (UTC)

버터핑거.나는 그 이후로 조급하게 말하지 않도록 조심해야만 했던 것을 기억한다. 내가 그것을 다시 말할 수 있을까?Femto 11:01, 2006년 11월 18일 (UTC)

이 문제에 대해 얼마 전에 여기서 실마리가 잡혔다.웹 양식의 기본값은 텍스트 영역이 아닌 필드에서 Enter 키를 누르면 기본 단추(또는 선택한 단추(있는 경우)가 눌러지는 것이다.나는 또한 여기저기서 실수를 했다; 당신의 전체 편집 요약을 게시하기 위해 null 편집을 하라.Tizio 12:45, 2006년 11월 18일 (UTC)

사실 Enter 키를 누르는 것은 기본 버튼을 누르는 것과 같은 것이 아니다.많은 웹사이트(위키피디아 포함)가 둘 다 똑같이 취급하고 있지만, 입력 버튼을 누르거나 클릭하는지에 따라 다른 액션이 발생할 가능성도 있다.예를 들어 구글은 검색 버튼을 클릭하면 '팁' 메시지를 주지만 홈페이지에서 검색한 뒤 입력을 누르면(이에 이를 비교해보면) 안 된다.Tra (Talk) 18:07, 2006년 11월 18일 (UTC)

그러면 기본 작업/버튼을 "미리보기" 버튼으로 만들 수 없으십니까?Btw 요약 미리보기 편집의 구현을 담당한 모든 사람에게 :) Zunaid©^{Please rate me at Editor Review!} 14:47, 2006년 11월 24일 (UTC)

나는 개인적으로 Save(저장) 버튼을 선호한다. 왜냐하면 'Save page(페이지 저장)'까지 탭할 필요 없이 편집 요약 및 부 편집 필드를 입력한 후 Enter(입력)을 누를 수 있기 때문이다.그러나 이 설정을 환경설정에서 변경하는 것이 유용할 수 있다.Tra(Talk) 14:38, 2006년 11월 25일(UTC)

나는 그것을 위해 ctrl/alt/s를 사용한다.그렇지 않으면 '저장'을 클릭하는데, 경고 환경설정으로 인해 섣불리 게시할 수 없다.편집 요약을 마지막까지 남겨두는 것이 우발적인 저장을 피하는 가장 효율적인 방법이다.qp10qp 03:49, 2006년 11월 30일(UTC)

쇼디 SVG 버전

나는 래스터 그래픽의 형편없는 버전들이 업로드되고, 그리고 나서 기사에 밀어넣어지는 것에 대해 불평하기 위해 글을 쓰고 있다.때때로 SVG 버전은 괜찮다; 종종 그렇지 않다.나는 구체적인 예를 들지는 않을 것이다. 왜냐하면 이것은 단지 사례별로 사람들을 변호하고 그들의 일을 개인적으로 받아들이도록 만들 것이기 때문이다.이것은 일반적인 문제다.

PNG 이미지를 로컬 컴퓨터에 다운로드하지 말고, 어떤 종류의 자동차 와셔를 통해 실행하고, 불량 SVG를 업로드하십시오.당신은 실제로 아무것도 성취하지 못하고 있다; 엔진은 어쨌든 대부분의 브라우저에 PNG를 제공할 것이다.PNG가 남아 있기 때문에 저장소를 저장하지 않고, 삭제하는 것은 업로더를 화나게 하는 것 외에는 아무 것도 해결할 수 없다.우리는 현금이 그렇게 궁하지 않아서 100Kb를 삭제하면 우리가 그 돈을 쓰게 될 것이다.

SVG는 문제 형식이다.장점도 있고, 그래.그러나 글꼴을 제대로 처리하지 못한다.그것은 잘 쓰일 수 있지만 나는 내가 보는 몇몇 작품이 마음에 들지 않는다.벡터 에디터인 Macromedia FreeHand로 그래픽을 만들고, Adobe Photoshop에서 내보낸 EPS를 Rasterize한다.만약 당신이 EPS를 SVG로 바꾸고 싶다면, 나는 기꺼이 그것을 이용할 수 있도록 하겠다.하지만 래스터 이미지에서 벡터를 다시 그리려고 하면 불필요한 작업을 많이 해야 하거나 일을 망쳐버린다.

PNG는 이미지의 훌륭한 형식이다; GIF와 달리 완전히 자유로운 리브레이고 유니시스가 우리 공을 물어뜯으러 올 염려가 없다.시간과 데스크톱에 있는 놀라운 도구와 더 이상 관련이 없다면 기존 PNG에서 손실 없이 몇 바이트를 짜낼 수 있는지 확인하십시오.실제적인 이점과 해를 보이지 않는 한 SVG로 교체하지 마십시오.감사합니다.존&nbsp;리드&nbsp;° 09:27, 2006년 11월 10일(UTC)

SVG는 원칙적으로 PNG보다 유지보수와 업데이트가 훨씬 용이하며, 물론 규모가 훨씬 우수하다.언젠가는 SVG의 편집이나, 어쩌면 시맨틱 메타데이터 같은 것이 있어서 지도 색상 등을 자동 표준화할 수 있을 겁니다.만약 좋은 품질의 SVG가 PNG로 만들어져야 한다면, 그것은 단지 미래의 이익을 위해 만들어져야 한다.(물건 취급은 확실히 문제야, 인정)

다음과 같이 동작이 현재 결함이 있는 자동 생성된 SVG 미리 보기 대신 PNG 또는 GIF를 사용할 수 있다는 점에 유의하십시오.

(그러나 경계가 없는 것은 분명 아니다.) —시뮬레이션(talk&nbsp;•&nbsp;controlls) 02:54, 2006년 11월 12일(UTC)

SVG는 다른 벡터 형식보다 더 이상 "문제"가 아니다.그리고, 그것의 광범위한 기능(투명성, 필터)과 완전히 개방되고 문서화된 상태를 고려하면, 그것은 확실히 많은 경우에 있어서 다른 벡터 형식보다 낫다.둘 다 CSS를 사용하기 때문에 그것의 글꼴 취급은 HTML의 그것보다 낫지도 나쁘지도 않다.CSS를 통해 누락된 글꼴(예: "sans serif")에 대한 일반적인 대체물을 지정할 수 있는 능력은 SVG의 큰 장점이며, 웹의 경우 정확한 글꼴 충실도보다 더 중요한 장점이다(그래픽 전문가로서 귀하가 더 중요하게 여길 수 있다).나는 비트맵을 SVG로 자동 추적하는 것이 거의 항상 저하되며, 심지어 이미지를 수동으로 다시 그리는 것조차도 특정한 노력을 들이지 않고 관련 기술을 갖추지 않는 한 저하가 될 수 있다는 것에 동의하지만, SVG를 포맷으로 대하는 당신의 태도는 근거가 없어 보인다.Tapolator 22:37, 2006년 11월 19일 (UTC)

내가 강조할 것은:나는 두 가지 형식을 모두 만들 수 있는 도구를 가진 사람이 원작을 위해 선호하는 선택을 말하는 것이 아니다.어떤 경우에는 SVG가 더 나을지도 모른다. 말할 수 없지만, 나는 그런 도구가 없다.그것들은 흔하지 않다.

나는 기존의 PNG를 가져가고, 열등한 SVG 모방을 올리고, 더 좋은 품질의 PNG를 대체하도록 강요하는 사람들을 볼 때만 화가 난다.래스터 PNG를 진정한 벡터 SVG로 직접 변환할 수는 없다.어떤 경우에는, PNG의 창시자가 지역사회를 떠났을지도 모른다; 그것에 대해 당신이 할 수 있는 것은 아무것도 없다.만약 당신이 재창조에 충분한 시간과 노력을 들인다면, 당신은 받아들일 수 있는 SVG를 생각해 낼지도 모른다; 그것도 괜찮다.

하지만 제작자가 있을 때 PNG를 열등한 SVG에 도살하지 마십시오!만약 그것이 고려중인 나의 일이라면, 당신은 언제든지 나에게 연락할 수 있다.나는 이런 식으로 전적으로 만들어진 어떤 PNG에도 사용할 수 있는 벡터 포맷 작업 파일을 만들 수 있게 되어 기쁘다.당신은 SVG로 마음껏 전환할 수 있다.이거 괜찮아.나는 단지 내가 아름다운 그래픽을 만드는데 몇 시간을 소비하고 다른 누군가가 15분 후에 와서 형편없는 변환을 한 다음 내 일을 밀어내는 것이 얼마나 짜증나는 일인지 표현하고 싶다.나는 이것을 GFDL에 따라 일반 쓰레기통에 넣고, 누구나 편집할 수 있다, 그렇다.하지만 더 나빠지지 말고 더 나아지게 해 줘.알았지? 존&nbsp;리드&nbsp;° 07:45, 2006년 11월 15일 (UTC)

오, 난 그것에 전적으로 동의해.더 낮은 품질의 SVG에 더 높은 품질의 PNG를 사용해야 한다.그러나 모든 것이 평등하다는 것은 SVG가 우월하다는 것이다.당신이 직접 영상을 SVG로 변환하거나, 그렇게 할 수 있는 사람에게 제공한다면 의심할 여지 없이 감사할 것이다(PSD와 같은 것을 SVG로 변환하는 것은 매우 간단해야 한다, 비록 내가 틀릴 수 있지만 나는 상상할 것이다).—시뮬레이션(talk&nbsp;•&nbsp;controlls) 05:09, 2006년 11월 16일(UTC)

두 가지 형식을 모두 만들 수 있는 도구... 흔하지 않아?그렇지 않아.잉크케이프는 매우 흔하며, 특히 이 위키피디아에서는 수천 개의 이미지가 만들어진다.최신 버전의 Adobe Illustrator도 유효한 SVG를 내보낼 수 있다.물론 둘 다 PNG까지 래스터라이징할 수 있다.(아쉽게도 내가 아는 한 프리핸드는 SVG가 가능하지 않지만, 요즘은 규칙이라기보다는 오히려 예외다.)당신의 이미지에 대한 벡터 변환 노력을 조정해 달라는 당신의 요청에 대해서는 전적으로 공감하지만, 당신의 사용자 페이지와/또는 당신의 이미지 페이지는 그러한 요청을 하기에 더 좋은 장소가 될 수 있다고 생각한다.Tapolator 22:37, 2006년 11월 19일 (UTC)

모든 것이 거의 같지 않다.나는 벡터에서 래스터로의 직접적인 변환은 거의 하지 않는다; 나는 포토샵에서 빙빙 돌면서 트위크를 한다.때로는 포토샵 쪽이 큰 일이기도 하지만, 결과는 마치 프리핸드에서 바로 나온 것처럼 보일 수도 있다.SVG는 래스터들에게 악취가 난다.나는 벡터가 어쨌든 독자에게 실질적인 실용성을 가지고 있다는 것에 동의하지 않는다; 대부분의 브라우저들은 SVG(또는 다른 벡터 포맷)를 직접 표시할 수 없고, 어쨌든 MediaWiki는 PNG를 서비스한다.

어쨌든, 나는 SVG를 출력하는 틈새 도구를 가지고 있지 않다.다른 그래픽 전문가들처럼, 나는 산업 표준 EPS 포맷으로 일한다.우리는 그 형식을 좋아하지 않을 수도 있고 그것이 어떻게 "자유롭지 않은"지에 대해 하루종일 투덜거릴 수도 있지만 그것은 널리 지지를 받고 있다.나는 기꺼이 EPS를 업로드하고 누군가가 SVG로 전환하도록 할 것이다.그것은 허용되지 않는다.존&nbsp;리드&nbsp;° 21:46, 2006년 11월 19일(UTC)

정확히 어떻게 SVG는 래스터들에게 냄새가 나?천성적으로 더 빛나는 이미지에 적합하지 않다는 말인가?사실이지만, 다른 벡터 형식에도 동일하게 적용된다.그러나 SVG는 투명성과 필터(예: 흐릿)로 EPS보다 훨씬 더 광범위한 이미지를 효율적으로 근접시킬 수 있다.

대부분의 브라우저가 SVG를 표시할 수 없음: "most"라는 이상한 정의를 가지고 있음.마지막 집계까지, 오직 하나의 주요 브라우저만이 SVG를 지원하지 않았다.

제발.그 (IE)는 여전히 압도적으로 많은 사용자들이 사용하는 브라우저다(그리고 나는 가능할 때마다 그것을 회피하지만, 그것을 뒷받침할 명백한 필요성을 인식하는 사람으로서 이렇게 말한다).(Adobe 플러그인은 있지만 소중한 사람은 거의 없다.)위키백과 기사에 기여할 만한 이미지나 콘텐츠가 있다면 20% 이상의 사람들이 볼 수 있는 형태로 제공하라. --Largo Plazo 16:36, 2006년 11월 29일 (UTC)

SVG를 산출하는 틈새 도구: 나는 성전을 일으키고 싶지 않지만, 어도비 일러스트레이터, 코렐 드로, 심지어 잉크케이프도 실제로 "니체 도구"라고 불릴 수 없다.그들 모두는 SVG를 한다.특히 잉크케이프는 완전히 무료다. 한번 시도해 보면 좋아할 수도 있다.

마지막으로, 이미지의 EPS 원본이 SVG로 변환하고 싶다면 위키백과에서 도움을 받을 수 있을 것이다.위키프로젝트_삽화.Tapolator 22:37, 2006년 11월 19일 (UTC)

업데이트: 위키백과:위키프로젝트_영어 WP의 삽화는 다소 휴면해 보이지만 프랑스어 위키백과들이 그들의 아틀리에 그래피크에 얼마나 생생한 페이지를 담고 있는지 보라.그곳에서는 SVG 변환에 대한 많은 요청이 있고, 벡터화된 영상들이 보여지고 원본과 나란히 논의되고 있다.영어 위키백과에서도 그런 포럼을 시작해야 할 것 같다.Tapolator 22:54, 2006년 11월 19일(UTC)

나는 존에게 동정한다, 가장 좋은 버전의 이미지가 독자에게 제시되어야 한다.업로드된 PNG의 형편없는 SVG 버전을 만드는 것은 그 누구에게도 이득이 되지 않는다.실제로 SVG가 우수하다면 사용해야 하지만, 이는 업로드된 래스터 이미지에서 얻은 사실 이후에 만들어진 SVG의 경우는 거의 없는 것으로 보인다.낮은 품질의 SVG는 PNG 이미지 설명에서 연결될 수 있지만 단순히 "벡터 그래픽이 더 좋다"고 해서 PNG를 대체해서는 안 된다.우선 고려사항은 독자의 관점에서 어떤 버전이 더 나은가 하는 것이어야 한다.드래곤스 04:36, 2006년 11월 20일 (UTC)

제안해줘서 고마워.나는 SVG 지원 범위에 대해 정정했다.그래도 네가 새 장난감을 사주기 전까진 난 개인적으로 할 수 없어, 잉크케이프는 내 박스 위에서 뛰지 않아, 미안해.어떤 경우든, 나는 유통 기간 동안 합리적으로 고해상도 PNG를 선호한다.바이트가 부족하지 않아.벡터 그래픽 호스팅/서비스 측면에서 가치가 없다고 본다.이것은 철학적 이상을 극단적으로 운반하는 또 다른 사례다.누구나 PNG를 편집할 수 있고 리브레 형식도 있다.존&nbsp;리드&nbsp;° 11:16, 2006년 11월 21일 (UTC)

음, 원칙적으로는 누구나 기계 코드로 프로그래밍할 수 있어...그러나 높은 수준의 프로그래밍 언어는 존재한다:) SVG와 동일하다.물론 (현대식) 벡터적 형식에 단순히 들어맞지 않는 많은 종류의 그래픽이 있다.그러나 다른 많은 것들은 적합하며, 그것들을 벡터링하는 것은 많은 장점을 가지고 있다.예를 들어 도면을 번역하려면 텍스트 개체를 클릭하고 잉크케이프를 사용하여 다른 언어로 다시 입력하는 것이 비트맵 편집기에서 레이블을 지우고 대신 새 레이블을 만드는 것보다 훨씬 쉽다(특히 흰색 배경을 넘지 않는 경우).당신 자신의 예를 빌리자면, 이 SVG 이미지에서 너무 얇은 글자를 좀더 대담하고 멋진 것으로 교체하는 것은 몇 분 정도 걸린다; PNG 원본에서 같은 것을 하는 것은 체커로 인해 훨씬 더 많은 일을 하는 것이다.

따라서 이미지가 벡터 특성(기술 도면, 다이어그램, 지도 등)이라면, 이를 벡터 형식으로 변환할 때의 이점이 비트맵 버전이 가지고 있던 일부 광택과 광택의 손실 가능성을 능가하는 경향이 있다고 생각한다.물론 때때로 SVG는 너무 엉뚱해서 그렇지 않을 수도 있지만, 이런 상황에서도 나쁜 SVG 파일을 가져다가 그것을 개선하는 것은 큰 문제가 되지 않는다.사실 위키백과에서 SVG를 선호하는 주된 이유는 비트맵보다 위키 친화적이기 때문일 것이다(미디어위키에 대해 "외부 편집자"를 설정하는 것은 분명히 고통스러운 일이지만 SVG의 잘못은 아니다).

잉크스케이프에 관해서는, 정확히 어떤 것이 당신이 그것을 실행하지 못하게 하는지에 대해 좀 더 자세히 설명해 주시겠습니까?윈도, OSX, 리눅스에서도 잘 작동하며, 엄청나게 빠른 속도나 메모리를 요구하지 않는다(매우 복잡한 그래픽을 편집하지 않는 한).Tapolator 19:55, 2006년 11월 21일 (UTC)

업데이트: 10억 큐브 이미지의 SVG를 청소했었습니다. 여기를 참조하십시오.나는 더 굵은 글꼴, 고정 스트로크 너비, 그리고 연결 스루쉬의 모양을 개선하여 당신의 PNG보다 훨씬 더 멋져 보이도록 했다. 나는 또한 스루쉬의 4개 복사본에 클론을 사용했는데, 그것은 또 다른 벡터적 특성이다: 그들 중 하나를 편집하고, 모든 4개가 자동으로 업데이트된다.모두 합쳐서 내 시간의 10분 정도 걸렸다.PNG가 있으면, 나는 이 모든 것을 너무 많은 양의 지루한 노동 없이는 할 수 없을 것이다.SVG의 이점:)

그리고 이 특정한 이미지 때문에 SVG를 선호하는 또 다른 중요한 이유가 있다: 큰 정육면체의 모서리에 있는 체크무늬 정육면체의 아주 작은 복사본은 PNG에서 거의 보이지 않는다, 심지어 전체 크기에서도.하지만 그들은 그 개념을 이해하는데 중요하다.그래서 내가 이 이미지를 이용해서 아들에게 10억의 아이디어를 설명한다면, 나는 SVG를 자유롭게 확대/축소할 수 있는 잉크케이프에 싣는 것을 매우 선호할 것이다.Tapolator 20:37, 2006년 11월 21일 (UTC)

수고하셨습니다.그것을 적절한 기사에 넣으면 그 일은 끝난다.그러면 우리는 다른 형편없는 SVG 변환으로 넘어갈 수 있다.존&nbsp;리드&nbsp;° 21:01, 2006년 11월 21일(UTC)

편집 모드 도움말 노트에 체크 시트에 링크를 추가하시겠습니까?

위키백과에 링크를 추가하자고 제안할께:편집 모드 레이아웃에서 "편집 취소 도움말(새 창에서 열기)" 링크 옆에 있는 체크시트예:

편집 취소 도움말 및 체크 시트(새 창에서 열기)

매우 가끔만 편집하는 내 친구들은 기본 Wiki에 대한 주의사항을 쉽게 찾을 수 있는 것에 대해 좌절감을 표시했으며(예: 배관 링크), 도움말의 크기/복잡성에 위축되거나 무시된다.편집 페이지.

생각? --Quiddity 06:25, 2006년 10월 29일 (UTC)

위키백과에서 교차 게시:마을 펌프(제안)#편집 모드 도움말 노트에 cheatsheet 링크 추가?누가 나한테도 이 얘기를 꺼냈지?거기서 피드백을 해 주시죠.고마워 :)

생각? 강한 지지!아아, 알아야 할 것이 너무 많다. 아직 몇 개씩은 배워야 한다.위키백과 해봤어?스타터 툴세트 : 거대하지만 여전히 충분하지 않다. -- DLL 20:39, 2006년 10월 30일 (UTC)

그 시작 도구 세트 페이지는 나를 소름 끼치게 한다;) 나는 그것을 향한 새로운 사람이 불쌍하다.완전히 압도적이고 조직적이지 않다.

그러나 소개 및 자습서는 점점 더 좋아지고 있으며, 체이스 시트 및 도움말:콘텐츠 메뉴는 가장자리에 걸쳐 있다(단순함 대 심층).:) -Quiddity 04:48, 2006년 11월 1일 (UTC)

든든한 지지.차라리 치트시트가 "도움말 편집하기"를 고급도움말 편집에 대한 링크로 대체하는 것을 보고 싶지만, 이것도 역시 도움이 될 것이다;) --Wolf530 18:58, 2006년 11월 4일 (UTC)

강력한 지원(VP(제안) 아카이브)을 보유하고 있는 것으로 보이며, 이를 구현하기 위해 어디에서 또는 어떻게 요청해야 하는가, 또는 이의나 개선 사항이 있는가?그리고 고마워! --Quiddity 21:56, 2006년 11월 23일 (UTC)

MediaWiki 수정:Edithelpage 및 MediaWiki:의견이 일치한다고 느낄 때마다 편집 도움말을 사용하십시오.Titoxd^(?!?) 07:50, 2006년 11월 24일 (UTC)

어떻게?: 나는 관리자가 아니고, 그 2페이지에 대해 제안된 변경사항을 어떻게 코드화할지 모른다("도움말 편집"을 어떻게 연결하는지 알 수 있지만, 어떻게 연결되지 않은 "&"와 두 번째 링크를 추가할지 알 수 없다.)

나는 여기를 가리키는 그들의 토크 페이지에 메모를 올리겠지만, 추가 도움은 고맙다.:) --Quiddity 20:24, 2006년 11월 25일 (UTC)

미디어위키토크에 {{editprotected}}을(를) 추가했다.미디어위키 공간의 요청된 변화에 관심을 끌기 위한 통상적인 방법인 편집헬피지. --ais523 13:45, 2006년 11월 29일(UTC)

"도움말 편집" 링크만 교체할 수 있을 것 같은데 옆에 추가할 수는 없어.그 변화를 수행하기 위해서는 더 큰 합의가 필요할 것 같다. -- Renesis (대화) 00:24, 2006년 12월 1일 (UTC)

아, 소프트웨어 변경이 필요한데, 내 생각엔 의도된 것 같아.버그픽스 제출은 내 분야가 아니다. 나는 당분간 이 아이디어를 옹호하는 것을 그만 둘 것이다. 비록 다른 누군가가 그것을 받아들이고 실행할 수 있다면 말이다. (배움 미디어위키는 내 할 일 목록에 있지만 상위권에는 없다;) -Quiddity 02:18, 2006년 12월 1일 (UTC)

내 말은, 우리가 현재의 링크를 대체하기 위해서는 단지 그것만 더하는 것이 아니라 더 큰 합의가 필요하다는 뜻이었어.누가 그걸 원하는지도 모르겠고, 그냥 선택사항으로 언급하고 있었을 뿐이야. - 레네시스 (대화) 06:45, 2006년 12월 1일 (UTC)

글쎄, 찬성하겠지만, 나는 이미 VPP와 VPT를 통해 두 번이나 이 아이디어를 제안했는데, 단 6명만이 피드백을 제공했기 때문에, 더 큰 합의가 일어날 것으로 예상하지 않는다. (다른 경로가 개설/제안되지 않는 한?CBB를 통해 동시에 제안서를 홍보할 수 있을까?)흠, 그 변화를 지지해 주시겠습니까?;) -Quiddity 20:14, 2006년 12월 1일 (UTC)

솔직히, 나는 내가 이 토론을 보기 전까지는 그 연결고리를 눈치채지 못한 것 같아, 그래서 나는 그것에 대한 애착도, 어떻게 그것이 개선될 수 있는지에 대한 강한 의견도 가지고 있지 않다.하지만, Cheatsheet 링크는 당신이 페이지를 편집하는 도중에 찾고자 하는 것과 더 비슷해 보여, 그래서 나는 아마 지지할 것이다.우리가 고려할 수 있는 또 다른 것은 그것을 "당신의 변화는 즉시 텍스트가 보일 것이다" 아래의 목록에 넣는 것이다. -- Renesis (대화) 16:43, 2006년 12월 2일 (UTC)

위키백과에 제출된 변경 제안서:마을 펌프(제안)#"Chatsheet" 링크로 "도움말 편집" 바꾸기거기에 코멘트를 해달라 :) --Quiddity 22:00, 2006년 12월 2일 (UTC)

출처를 알 수 없는 공백

Satveer Chaudhary 기사의 윗부분에서 공백의 출처를 찾을 수 없을 것 같다.추가 줄 바꿈에서 오는 것도 아니고 템플릿에서 오는 것도 아닌 것 같다.더 조사해 볼 사람?서커스 01:33, 2006년 11월 27일 (UTC)

인포박스를 제거하면 깨끗해진다.흠, 뭐가 지저분한지 모르겠는데 다른 데서도 괜찮다면...심그레이 토크 01:38, 2006년 11월 27일 (UTC)

예, 템플릿에 문제가 있음:인포박스 정치인.리차드 헨리 리는 같은 인포박스를 사용하는 또 다른 기사로, 처음에 같은 공간을 가지고 있으며, 공간에 대한 뚜렷한 이유가 없다.템플릿 [2]에 Office2, term_start2 및 term_end2 매개 변수를 비워 두면 상단의 공간이 제거된다.Special(특수)을 통해 실행할 경우:ExpandTemplates, 당신은 </tr> 사이에 몇 개의 빈 줄이 생성되는 것을 볼 수 있다.<tr> 사무실2/term_start2/term_end2 주장 근처.만약 이 빈 라인이 생성되지 않도록 템플릿을 수정할 수 있다면, 문제를 해결할 것이다.하지만 템플릿은 꽤 복잡해서, 어떤 변화가 필요한지 내게는 분명하지 않다. --Interiot 03:59, 2006년 11월 27일 (UTC)

User:에 버전이 있는 경우릭 블록/샌드박스3가 더 나은 것 같다.나는 그 문제가 위키피디트 구문과 표준 HTML 테이블 구문을 혼합하는 것과 관련이 있다고 생각한다.에슈 난독화. -- 릭 블록 (토크) 04:57, 2006년 11월 27일 (UTC)

고정 [3] --Ligulem 13:22, 2006년 11월 27일 (UTC)

포함하지 않다

<노인클루먼트>와 </노인클루션>은 무엇을 하는가? --Shanedidona 19:17, 2006년 11월 26일 (UTC

이것들은 템플릿에 사용되는 태그들이다.이 태그 사이에 텍스트를 넣으면 템플릿 페이지가 표시되지만 템플릿이 다른 페이지로 변환될 때는 표시되지 않는다.트라 (Talk) 2006년 11월 26일 19:23 (UTC)

알았어. 고마워. :-) --샤네도나 19:48, 2006년 11월 26일 (UTC)

<포함만>은 무엇을 하는가?이 태그에 대해 이야기하는 페이지가 있는가? --Shanedona 19:52, 2006년 11월 26일 (UTC)

http://meta.wikimedia.org/wiki/Help:Templates#Noinclude_and_includeonly. --Ligulem 19:54, 2006년 11월 26일(UTC)

고장난 리디렉션

직경 1,205km의 채론-1은 단지 텍스트(한곤)-예, 괄호 안에 있다.그러나 편집 페이지로 이동하면 리디렉션이고 편집을 마치면 리디렉션 페이지가 표시되지만 가로 1,205km의 차론에서 입력하면 (어떤 이유로) 리디렉션되지 않고 (행온)만 보면...그 리디렉션을 완전히 삭제하고 깔끔하게 고칠 수 있겠지만 wtf?칸트라스 17:23, 2006년 11월 26일 (UTC)

나한테는 잘 되고 있어.브라우저의 캐시를 지우고 다시 시도하십시오.페이지가 바뀌었다고 생각하지 않을 수도 있고 당신은 최신 버전을 다운로드하도록 강제할 필요가 있다. -- JLaTondre 17:29, 2006년 11월 26일 (UTC)

효과가 있었어/시피쉬 칸트라스 17:36, 2006년 11월 26일 (UTC)

Firefox의 이미지 정렬 오류

Mozilla Firefox에서 이미지 정렬 불량으로 문제를 경험한 사람이 있는가?

파이어폭스에서 뉴캐슬 센트럴 스테이션 기사를 열면 두 개의 이미지(뉴캐슬_Central_Station.jpg, Newcastlistext.jpg)가 기사 텍스트의 일부와 겹친다.IE에서 열면 중복이 없다.2006년 11월 26일 (UTC)

내 파이어폭스는 그 페이지에는 문제가 없지만 "목록하는 방법...위키피디아의 " 섹션:삭제기사는 텍스트가 박스와 겹쳐져 있어, 텍스트 포장처럼 이미지와는 큰 관계가 없을 것이다. --Derlay 00:02, 2006년 11월 27일 (UTC)

염장 카테고리

이것이 가능한가?나는 다양한 사람들이 계속해서 Category:2010 영화를 재창조하고 있다는 것을 알아챘다.그것은 다소 혼란스러운 긴장감을 안고 있는 "원래 2010년에 개봉된 영화들"을 담고 있다. 거의 모든 기사들은 대부분 루머가 되어왔다. 또는 그들이 삭제되거나 재유포된 검증 가능한 정보에 대해 너무 부족하다."향후 개봉될 영화"를 포함시키는 것에 대한 의미론적 논쟁은 차치하고라도, 적어도 1년 정도 더 그 시기에 개봉될 영화에 대한 충분한 검증 가능한 정보가 없을 것이다. 그렇다면, 그러한 범주들이 재창조되고 재게재되는 것을 막을 수 있을까?크리스 치즈는 2006년 11월 25일 19:04(UTC)에서 칭얼거렸다.

범주:범주 페이지가 소금에 절인 경우 삭제된 범주를 보호한 다음 로봇이 해당 범주에 기사가 추가되지 않도록 하십시오.트라(Talk) 2006년 11월 25일 19:24(UTC)

염장술은 범주의 위키텍스트의 재생을 막을 수는 없지만, 누군가가 진정으로 원했다면 범주의 재포용을 막을 수는 없다고 믿는다... --Interiot 20:26, 2006년 11월 25일 (UTC)

그래, 하지만 로봇은 고아가 되고 포만감을 주는 사람들을 위해 누군가 뭔가를 넣으면 다시 그들을 비운다.Martinp23 20:54, 2006년 11월 25일 (UTC)

php를 통해 위키백과 데이터에 액세스하시겠습니까?

안녕, 모두들.php 스크립트를 통해 특정 페이지 섹션을 요청할 수 있는지 궁금하다.예를 들어, 위키피디아 크롬이나 나머지 기사 없이 페이지 내용 상자 또는 요약의 일반 텍스트를 어떻게 포함시킬 수 있는가?어쩌면, 내가 감히 말할 수 있을까, 기능적인 연결고리?나는 그러한 메커니즘이 존재한다고 생각한다. 트릴리언 채팅 클라이언트의 neet-o 위키백과 검색의 정확성 때문에, 그러나 나의 최선의 노력은 다른 페이지에 위키백과 내용을 포함시키기 위한 기술적인 세부사항들에 매우 복잡하게 나타났다.나는 누군가가 URL에서 '액션=raw'를 사용하는 것을 보았지만, 그것은 답의 일부인 것 같다.

어쨌든, 이 질문에 효과적으로 대답할 수 있는 곳에 대한 어떤 도움이나 방향도 매우 감사하다.

기록을 위해, 나는 거머리 위키백과의 내용뿐만 아니라 약간의 검색 발달로 위키백과 스킨/리더에 해당하는 것을 개발하려고 한다. 69.114.196.13 18:43, 2006년 11월 25일 (UTC)Mike Weber

-- 2006년 11월 25일 01시 42분 (UTC)

마지막에 &action=render로 페이지를 얻은 다음, 이 결과를 긁어 원하는 것을 얻을 수 있다.예를 들어, 요약의 경우 첫 번째 <h2> 태그까지 모든 것을 원하며, 내용의 경우 <테이블 ID="toc" 안에 있는 모든 것을 원하게 된다.그러나 많은 위키백과 페이지에 대해 이 작업을 수행할 생각이라면 데이터베이스 덤프가 유용하다는 것을 알 수 있을 것이다.트라 (Talk) 2006년 11월 25일 19:03, (UTC)

-- 나만의 위키백과 거울을 주최할 처지는 아니지만, 액션=렌더(render)는 정말 쓸모가 있을 것이다.하지만 위키백과 질의에 대한 정보를 위한 중앙 저장소가 있을까?어떤 유형의 매개 변수를 전달할 수 있는가?예를 들어, '섹션' 매개변수가 통과될 수 있다는 것을 알 수 있지만, 그것은 단지 편집에 효과가 있는 것 같다.내가 이런 것에 대해 좀 더 배울 수 있을까?('섹션' 매개변수 또는 그것과 같은 것을 어떻게 작동시키는지에 대한 설명을, "생선을 줘, 하지만 낚시는 안 돼" 같은 방법으로)감사합니다, 그리고 아름답게 지내세요, 여러분.

2006년 11월 25일 4시 41분(UTC) 마이크 베버

나는 그런 유형의 설명서는 잘 모르지만, 당신은 카테고리에서 기계로 읽을 수 있는 페이지 목록을 가져오는 데 유용한 query.php에 관심이 있을 것이다.트라 (Talk) 22:29, 2006년 11월 25일 (UTC)

기술 질문 리: 범주

알다시피, 카테고리 페이지에서 각 하위 카테고리는 옆에 더하기 기호가 있으며, 하위 카테고리의 다음 중첩 하위 카테고리 계층을 볼 수 있다.그러나 나는 적어도 한 사용자로부터 그것이 그에게 제대로 작동하지 않는다고 말한 것을 들었다; 대신에 그것은 "로드"를 계속하며 실제로 목록을 작성하지 않는다.그러나 그것은 내게는 제대로 작동한다.이것은 단지 그의 자바스크립트를 업그레이드해야 하는 문제인가, 아니면 기술팀이 조사할 것이 있는가?도와줘서 고마워.Bearcat 00:08, 2006년 11월 25일(UTC)

이 사용자는 어떤 브라우저를 사용하고 있는가?트라 (토크) 01:41, 2006년 11월 25일 (UTC)

사용자 상자

레이븐스 어프렌티스(The Raven's Affective)의 윈도우 시리즈처럼 어떻게 이미지를 사용자 상자에 넣지?나는 문자 입력만 할 줄 안다.내 토크 페이지에서 알려줘.고마워, Ard0 22:48, 2006년 11월 24일 (UTC)

WP:UBX는 일반적인 정보를 제공한다.이미지의 경우 다음 항목으로 시작하십시오.{{userbox orange yellow [[Image:Crystal kthememgr.png 40px]] A userbox is a small box that looks like this.}} 오른쪽에 표시된 사용자 상자를 제공하고 올바른 텍스트와 이미지를 표시하도록 수정하십시오.트라(Talk) 01:55, 2006년 11월 25일(UTC)

Monobook과 Classic 스킨이 인라인 이미지를 정렬하는 방법의 변화

나는 (오래전부터 사용했던) 클래식 스킨과 약간 더 흔한 모노북 스킨이 인라인 이미지를 수직으로 정렬하는 방법에 차이가 있다는 것을 발견했다.위키피디아를 통과하고 있었는데:위키프로젝트 스타게이트는 제목에 있는 글립자가 이 부분 스크린샷에서 알 수 있듯이 라인의 나머지 부분과 너무 어긋나는 것을 보았다. 나는 그것을 "고정"했지만, 모노북을 사용한 누군가 그에게 그 픽스가 반대 방향으로 이미지를 정렬에서 벗어났다고 말했다.나는 CSS를 잘 모르기 때문에 이 다른 행동의 근본 원인을 찾지 못했고 맹목적으로 내 길을 만지작거리지 못했다.이 문제를 어떻게 해결할 수 있을지 조언해 줄 사람?브라이언 06:37, 2006년 11월 24일 (UTC)

(그 후 페이지는 전체 이미지 배너로 업데이트되었으며, 참고로 이 문제가 처음 나타난 두 버전은 [4]와 [5] Bryan 08:00, 2006년 11월 24일(UTC)이다.

알려진 문제하나의 확실한 해결책이 여기 있다.Geni 15:58, 2006년 11월 24일 (UTC)

좌표 링크가 잘못됨

좌표 링크에 무슨 일이 생겼어대부분의 지리적 기사를 참조하십시오. 예를 들어, 밀워키는 [6]에 대한 링크를 가지고 있으며, 그 지역의 개요를 얻기 위해 다양한 온라인 매핑 도구를 찾았지만, 이제 모든 페이지가 {{deletedpage}}의 변형으로 대체되었다.무슨 일입니까?삭칼레 (체크!) 2006년 11월 23일 10:26 (UTC)

지금쯤이면 크림시티가 좋아보인다... 약간의 시공간적 구분이 생겼을지도 모른다. -- DLL 20 ^{.. T}:04, 2006년 11월 24일 (UTC)

야, 이거 늙어가는구나.

좋아, 그냥 좋아. 1. 왜냐하면 나는 지금 DrecWay에 있기 때문에(깊은 숲에 있기 때문에 서버에 대한 다른 선택권이 없기 때문에) 나는 *PERiod*에 로그인할 수 없어. 2. 이 전에 나는 마당에서 J. 삼백의 사진을 찍기 위해 골치 아픈 데까지 갔고, 빠른 부하를 위해 사이즈(바이트)를 편집했다.재스민 페이지에 (5개월 전) 추가했어. 3.이제 위키 경찰이 제거해 버렸어. 그리고 난 그걸 되돌리기 위해 계속 접속할 수 없어!위키피디아가 Direcway 사용자를 인식하지 못하는 결함이 있는 것은 내 잘못이 아니다. 그리고 그렇다. 나는 당신의 헬프 데스크에 가서 아무 소용이 없었다.누가 제 웹사이트에 가서 사진을 받아 보시겠습니까: http://www.MagiaLuna.net/jsambac1.jpg.사진 아래에 제거된 텍스트는 "J.sambac은 개봉되지 않은 꽃봉오리와 함께 꽃을 피웠다.꽃에서 차 냄새가 꼭 나네."나의 답답함을 용서해 주시오.고마워, 그리고 BTW 나는 지금 내 사용자 페이지를 찾을 수 없어?그리고 물론 이것을 올리기 위해 로그인했고 지금은 로그인하지 않았다...2006년 11월 22일 마지알루나 20:34(UTC)

Magialuna의 사용자 페이지는 User:마지알루나.지금 사용하고 있는 ip의 토크 페이지는 User talk:69.19.14.41에 있다.로그온 상태를 유지하려면 브라우저에서 쿠키가 활성화되어 있고 사용자를 기억하도록 옵션을 활성화했는지 확인하십시오.이 작업이 실패해도 여전히 로그인할 수 없는 경우 업로더가 이미지 페이지에 메모할 수 있도록 이미지의 원본과 라이센스를 제공하십시오.트라 (Talk) 02:05, 2006년 11월 23일 (UTC)

거기 가본 적 있어, 다시 해 봐. 쿠키를 만들었어.출처?내 진짜 이름 말하는 거야?어, 내가 사진을 찍었는데, 아무도 날 믿지 않는다면 내 웹사이트에 거대한 편집되지 않은 원본 디지털 사진을 올릴 수 있어.면허증? 응? 2006년 11월 22일, Magialuna 21:19 (UTC)

좋아, 경고 전화 걸어, lol.원본 사진: http://www.MagiaLuna.net/DSC_0001.JPG Magialuna 21:45, 2006년 11월 22일(UTC)

위성 ISP의 사용자들은 https 서버(추가적인 프라이버시는 주지 않지만 위성 연결이 작동될 가능성이 더 높아짐)를 사용할 때 개선점을 찾는 경우가 많다; 이 페이지 상단에 링크가 있고(WP:VPT), 내 사용자 페이지(사용자:ais523 09:27, 2006년 11월 23일(UTC)에도 있다.

면허증이라면 GFDL이나 다른 무료 면허증으로 출시할 의향이 있으신지요?네가 승낙해야만 올릴 수 있어.트라 (Talk) 2006년 11월 23일 18:01, (UTC)

네. 쓰세요.고마워!2006년 11월 23일 마기알루나 19:36 (UTC)

HughesNet을 사용하는 누군가가 Turbo Acceleration 프록시를 우회하는 방법을 발견했다. [7].이 *may*는 일부 다른 위성 제공업체에서 사용할 수 있다. --Splarka (rant) 21:13, 2006년 11월 23일(UTC)

고해상도 버전을 이미지:jsambac.jpg.MediaWiki 소프트웨어는 썸네일을 위한 정확한 해상도로 자동 변환할 것이다.Tra (Talk) 17:52, 2006년 11월 24일 (UTC)

마지알루나, 넌 두 배로 좌절했고 한 부분에 두 개의 질문을 올렸다고 생각해.너의 이미지는 내가 알기로는 괜찮지만, 따로 다루면 더 빨리 고쳐졌을 거야.결혼식에 대해서는, 행운을 빌어! -- DLL 20 ^{.. T}:08, 2006년 11월 24일 (UTC)

참고: 원래 큰 ©이 붙어 있어서 이미지를 제거했다.©이 큰 이미지가 그려져 있는 것은 우리의 이미지 정책에 완전히 어긋난다.바스티크제 15:06, 2006년 11월 25일 (UTC)

손상된 기록

(Help Desk에서 스레드 이동)

1년 반 동안 지내면서 관리 일을 하고 역사 병합을 했는데 아직도 무슨 일이 벌어지고 있는지 모르겠어.나는 역사에서 차이를 비교할 때 나타나지 않는 차이를 볼 수 있다.이 diff]를 보고 다음 링크를 누르십시오.결과적인 차이, 특히 그들 사이의 시간 차이를 보아라.그럼 기사의 내력을 보시오.다른 사용자가 편집한 내용을 30개까지 생략하고 나중에 편집한 내용을 30+1개까지 모두 편집자에게 귀속시킨다.편집된 내용이 모두 역사에 나타나기 때문에 디프를 디프로 비교한다면 크게 걱정할 일은 아닌 것 같은데 왜 이런 짓을 하는지 이해가 안 간다.30명 중 25명이 내 것이기 때문에 나 또한 개인적인 걱정을 하고 있다.WAvegetarian•(토크) 12:54, 2006년 11월 24일 (UTC)

• 이것을 보고 클릭해 보면 5월 25일부터 6월 22일까지의 편집은 점보 달팽이의 것으로 귀속되지만, 역사 속에도 점보 달팽이도, 5월 25일 편집한 사람도 찾을 수 없다.나는 그것이 정말로 부패했다고 생각한다. - Mgm 13:08, 2006년 11월 24일 (UTC)

동일한 diff에 대한 다른 URL: http://en.wikipedia.org/w/index.php?title=Garfield_High_School_%28Seattle%2C_Washington%29&oldid=15642652&diff=15643044나는 오래된 숫자와 확산된 숫자들이 보이도록 그것을 전부 쓰고 있다; 그것들은 단지 492만큼만 다르다는 것에 주목하라: 이 기간 동안 492개의 편집만 있을 것이라는 것은 믿기 어렵다.http://en.wikipedia.org/w/query.php?titles=Garfield_High_School_%28Seattle%2C_Washington%29&revids=15642652 15643044&what=what=what&rvcoments&rvcoments&rvstart&rvends로 데이터베이스를 조회하면 이러한 값이 그럼에도 불구하고 데이터베이스에 존재한다는 것을 알 수 있기 때문에 여기에 일종의 괴리가 있는 것 같다.이 실을 기술 마을 펌프에 베끼면 더 많은 입력을 얻을 수 있을 것이다. --ais523 13:17, 2006년 11월 24일 (UTC)

충돌 편집:사용자:점보 달팽이는 이전에 CAPS LOCK이었습니다.그의 첫 기사 편집은 6월 22일이었다.이것은 역사 페이지를 보면 나타난다.첫 번째 편집 전에 (5번째 편집본을 나타냄)기사 편집) 2월, 3월, 5월에 편집되었다.다음 diff 링크를 사용할 때도 5월의 두 편집 내용이 나타나지 않는다.모든 것을 삭제하고 수동으로 복원하는 것과 같은 이러한 문제를 해결할 수 있는 방법이 있는가?이 기사가 편집한 내용은 모두 역사에 나타나지만, 다음 번 반복에는 나타나지 않는다.이 기사는 지난 1년 반 동안 약 6개의 다른 제목에 실렸다.이것을 WP:VP/T로 가져가야 할까?—WAvegetarian•(토크) 13:21, 2006년 11월 24일 (UTC)

에쉬, 내가 생각했던 것보다 더 안 좋네.나는 이것을 WP:VP/T에 복사할 것이다.거기서도 실이 계속되었다.-WAvegetarian•(토크) 13:27, 2006년 11월 24일 (UTC)

혼란을 더하기 위해 타임스탬프별로 데이터베이스 쿼리를 실행했다. http://en.wikipedia.org/w/query.php?titles=Garfield_High_School_%28Seattle%2C_Washington%29&what=revisions&rvcomments&rvstart=20050525064236&rvend=20050622192200노인들은 의심스러운 연속적인 정수들을 가지고 있다. 그리고 첫 번째 편집은 이제 WABegetarian (또한 그 기간 동안 두 번의 반달리즘 회귀를 가지고 있는 사람)에게 귀속된다.--ais523 13:49, 2006년 11월 24일 (UTC)

이미지를 오른쪽으로 정렬

이거 어떻게 하는 거야?내 모든 사용자 박스가 바벨 박스처럼 내 사용자 페이지의 오른쪽에 있기를 바란다. --Kukoo275 23:41, 2006년 11월 23일 (UTC)

고마워. --Kukoo275 02:33, 2006년 11월 24일 (UTC)

캐시된 특수 페이지에 대한 제안

특수 페이지:데드엔드 페이지, 특수:분류되지 않은 페이지, 특수:범주화되지 않은 범주 및 특수:원하는 범주는 정기적으로 생성되며 간격마다 변경되지 않는다.이러한 목록을 동적으로 컴파일하는 데 너무 많은 시간이 소요된다는 것은 이해하지만, 일단 그것들이 존재하게 되면, 목록에 있는 페이지의 변경사항을 감시하고 더 이상 속하지 않는 것을 제거하는 것은 너무 많은 요구가 되어서는 안 된다.이것은 이 특별한 페이지들을 더 유용하게 만들 것이다. 왜냐하면 현재 그 안에서 아직 고쳐지지 않은 것을 찾는 것은 상당히 어려울 수 있기 때문이다. --Derlay 00:29, 2006년 11월 23일 (UTC)

할 수 있는 것은 위키피디아의 편집 가능한 정규 페이지인 네임스페이스에 특수 페이지의 내용을 붙여넣는 것이다. 여기서 고정된 항목은 수동으로 제거할 수 있다.이는 이미 WP와 같은 일부 페이지를 통해 수행되었다.MWA는 Special의 편집 가능한 버전:수배 페이지.이렇게 디자인된 다른 페이지들은 위키피디아 입니다.데드 엔드 페이지, 카테고리:필요한 범주 및 범주:고립된 범주 트라(Talk) 01:15, 2006년 11월 23일(UTC)

로그인할 수 없음

PC에서 로그인을 시도할 때마다 로그인을 클릭하면 파일을 다운로드하라는 메시지가 표시된다.사용자 기본 설정에서 외부 편집기 사용을 선택하지 않은 경우, 영향을 미치지 않아야 한다고 생각함.무엇이 잘못되었는지 아는 사람? 81.104.37.81 20:29, 2006년 11월 22일(UTC) (보통 사용자:Lcarsdata)

학교에서 WP로 로그인한 만큼 내 PC와 파이어폭스와의 관계가 있을 테니 걱정하지 마십시오.Lcarsdata (Talk) 10:05, 2006년 11월 23일 (UTC)

영어 텍스트는 힌디나 뭐 그런 걸로 표시되는데...

나는 애플 PC의 사용자 몇 명이 힌디나 인도 드라비디아어로 된 글에서 이 텍스트를 본 적이 있거나 현재 보고 있다.

내가 과거에 이 오류를 껐다는 것을 알지만 어떻게 했는지 기억이 안 나는 것 같아.

그들은 모두 타이거와 사파리를 사용하고 있다.다른 브라우저에서는 문제가 발생하지 않는다.또한 크레이그 리스트와 몇몇 다른 사이트에도 영향을 미치는 것 같다.

어떤 도움이라도 감사할 것이다!고마워요.

Merrel O'Rourke (개인 정보 보호를 위해 삭제된 이메일) 2006년 11월 22일 수요일

이것은 당신의 기본 브라우저 설정의 오류처럼 보인다.Safari 메뉴로 이동하고 Preferences(기본 설정)으로 이동...(⌘,그런 다음 상단에 있는 모양 탭을 클릭하십시오.화면표시 옵션 맨 아래에 "기본 인코딩"이 나타난다.이 설정을 유니코드(UTF-8)로 설정하고 모든 설정을 완료하십시오.-WAvegetarian•(토크) 13:40, 2006년 11월 24일 (UTC)

"편집하려면 비활성화??"토크:편집하려면 Michael Richards#사용 안 함

왜 그 페이지는 맨 위에 쓰여 있는 것을 말하고, 이 분명히 새로 등록된 사용자는 그 기사를 마음대로 쓸 수 있었을까?BabuBhatt 15:52, 2006년 11월 22일(UTC)

사용자:커티살렌 계정은 얼마 전에 등록되었지만 오늘까지 이용하지 않았다.그러한 계정들이 악의적인 목적을 위해 놓여져 있을 때 그들은 보통 위키피디아에서 잠자는 계정으로 알려져 있다.(→넷스코트) 16:01, 2006년 11월 22일 (UTC)

지금까지 아무런 편집도 하지 않은 사용자들이 마치 새것처럼 취급될 수 있도록 프로그램을 바꾸려면 무엇이 필요할까?와케나 16:07, 2006년 11월 22일 (UTC)

흠, 나쁘지 않은 생각이야.내가 추천하는 것은 그것을 위키피디아에 게시하는 것이다.마을 펌프(기술).(→넷스코트) 2006년 11월 22일 16:11 (UTC)

와케나 16:15, 2006년 11월 22일 (UTC)

나는 그 변화가 그렇게 도움이 될 것이라고 전적으로 확신하지는 않는다.잠꾸러기 계정을 사용하는 반달들은 이미 어느 정도 정교함을 보여주었다.그들이 계정을 잠시 정지시키기 전에 불필요한 편집 한 번을 해야 한다는 뜻일 겁니다.GeeJoint^(t)•_(c) 16:29, 2006년 11월 22일(UTC)

네 말이 맞을 거야.그들이 다른 방법을 알아내는 데는 오래 걸리지 않을 것이다.와케나 16:32, 2006년 11월 22일 (UTC)

한편, 반달들을 위해 일을 만드는 것은 본질적으로 좋은 것이다.GeJo _(c)½ • 16:54, 2006년 11월 22일(UTC)

100개 편집으로 설정하면? - 투트모시스 17:07, 2006년 11월 22일(UTC)

좋은 생각이야.아니면 적어도 시간과 노력을 들여야 할 50, 250...특히 필요한 편집 횟수가 어떻게든 비밀에 부쳐진다면(허용되는 생각은 아니지만, 공상할 가치가 있다).와케나 17:21, 2006년 11월 22일 (UTC)

• 편집 횟수가 데이터베이스의 어느 곳에도 기록되지 않기 때문에(즉, 사용자 데이터베이스 테이블에 편집 횟수 테이블 또는 편집 횟수 필드가 없다는 의미) MediaWiki 내에서 직접 편집 카운트를 가져올 수 있는 방법은 없다.툴서버에서 하듯이 별도의 고가의 질의를 통해 도출할 수 있지만, 사이트에 일정 횟수의 수정이 이루어질 때까지 동일한 질의를 하는 것은 IMO가 너무 비싸고, 사용자는 오토콘 확인 플래그를 받는다.Titoxd^(?!?) 23:59, 2006년 11월 23일 (UTC)
  • 간단히 말해서, 프로그램 변경뿐만 아니라 데이터베이스 변경도 필요할 것이다.따라서 프로젝트 매니저들이 이러한 종류의 업무를 우선시할 가능성은 다소 낮다.:\ 와케나 02:23, 2006년 11월 24일 (UTC)

두 개의 기호가 있는 파이프 형식, 명목상의 단수 엔딩을 가진 단어와 언어용

일반적인 파이프 형식은 예:잘 알려진 바와 같이 "[내 낡은 아쿠룽을 설정했다]."그 문제는 일그러짐과 함께 발생한다.영어에서 대부분의 변형된 단어 형태는 맨 줄기의 형태를 가지고 있기 때문에, "[cat]의 꼬리", "[patrol] 남자들은 그들의 소각로에 압류된 키트를 가지고 있었다."와 같은, 변형된 형태에서 연결하기가 쉽다.

문제는 맨 줄기가 유효한 단어가 아닌 단어와 함께 온다.그것은 라틴어와 리투아니아어의 명사와 아이슬란드어의 명사와 슬라보어의 여성적이고 중성적인 단어, 그리고 로망스어의 동사와 같이 다른 언어에서 더 많이 발생하는데, 여기서 일부 변형된 형태에서는 열거된 형태의 끝부분이 탈락한다.그 결과 링크에서 "[소각 소각장]", "[인플레이션]"과 같은 단어 전체를 반복해야 한다.일부 외국 위키피디아에서는 이러한 현상이 매우 흔하며, 최대 수 메가바이트의 추가 텍스트가 추가된다.예를 들어 글을 쓸 수 있다면 유용할 것이다.「[incinner ing or]」, 「별 ξ[Sagittari us i]」, 「[inflat e ing]]」, 그 대신 「[inflat e ing]]」.Anthony Appleyard 2006년 11월 22일 11시 11분(UTC)

범주 리디렉션

이 기능이 위키피디아에 들어간다면 유용할 것이다.예를 들어,:-

• 일부 사람들은 다음과 같은 카테고리에 기사를 싣는다.재호흡기 다이빙.
• 독립적으로 행동하는 일부 다른 사람들은 다음과 같이 기사를 분류한다.폐쇄 회로 다이빙.
• 이 두 가지 범주를 병합하기로 결정했다.

단지 카테고리 본문을 변경할 수 있다면 유용할 것이다.판독을 위한 폐쇄 회로 다이빙

#redirect [[:Category:재호흡기 다이빙]]]

하나의 행위가 자동으로 범주의 멤버가 된다.폐쇄 회로 다이빙은 다음 범주의 멤버로 간주된다.카테고리의 모든 구성원을 편집할 필요 없이 재호흡기 다이빙:폐쇄 회로 다이빙.Anthony Appleyard 2006년 11월 22일 11시 5분 (UTC)

이 작업은 "소프트 리디렉션"을 사용하여 수행할 수 있으며, 템플릿 대화를 참조하십시오.카테고리 리디렉션.템플릿을 추가한 후 봇(사용자가 운영하는)이 결국 기사를 편집해 범주를 변경한다. -- 릭 블록(토크) 16:20, 2006년 11월 22일(UTC)

범주는 원 안의 다른 범주의 구성원이다.

방금 그 카테고리를 찾았어:압하지아에서 그루지아인들의 민족 청소는 그 자체가 하나의 일원이었기 때문에 한 범주의 하위 범주의 나무가 영원히 계속될 수 있었다.위키피디아의 봇 중 하나는 원형 하위 카테고리 체인(#redirect circles)을 찾도록 프로그램되어야 한다.(이제는 범주에서 자체 멤버쉽 라인을 제거함:압하지아에서 그루지아인들의 민족 청소; 이 구본을 보라.)Anthony Appleyard 10:52, 2006년 11월 22일(UTC)

이것이 반드시 문제가 되는 것은 아니다. 위키백과를 참조하십시오.분류#주기는 피해야 한다.범주는 특정한 공식적 의미를 가지지 않고 오직 지시된 그래프만 공식적인 구조를 가지며, 특히 나무를 형성하지 않고 사이클을 포함할 수 있다. -- Rick Block (talk) 16:29, 2006년 11월 22일 (UTC)

새 페이지

Javascript 또는 이와 동등한 것으로 Special에 있는 항목을 필터링하는 데 사용할 수 있는 항목이 있는지 여부:특정 크기 임계값 미만의 새 페이지?나는 그곳에서 상당한 양의 DYK 입력을 하고 있으며, 3kb 미만의 기사 80%를 스크롤하지 않아도 되는 것이 매우 편리할 것이다.GeJo _(c)½ • 09:53, 2006년 11월 22일 (UTC)

사용자:이에 대응한 Ais523/filternewpage.js; 사전요건은 'LI 링크 추가'와 '추가 탭'이며, WP:US/S --ais523 11:50, 2006년 11월 22일(UTC)

정말 고마워!확실히 시간을 많이 절약할 수 있을 거야. 그리고 내가 만든 작은 글의 수를 정말 과소평가한 것 같아.이 툴의 가동률은 95%에 육박하는 것 같다.GeJo _(c)½ • 13:51, 2006년 11월 22일(UTC)

템플릿: 매개 변수 목록을 하나의 매개 변수로 전달

페이지 A가 템플릿 B를 호출한다고 가정하자. 템플릿 C는 A. X,Y,Z가 제공하는 파라미터에 따라 (X,Y,Z) 중 하나를 호출한다. 이 파라미터는 C가 공급하지만, 리테이너는 A가 공급해야 한다.

그래서, 유사문자로:

• 사례 1
  • A가 Param으로 B를 부른다(X,1,2,3,4,5)
    • B는 이것을 C에게 전한다.
      • C는 파라암으로 X를 부른다(p,q,1,2,3,4,5)
• 사례 2
  • A는 Params로 B를 부른다(Z,알파,베타,감마)
    • B는 이것을 C에게 전한다.
      • C는 파라(p,q,알파,베타,감마)로 Z를 부른다.

하나의 파라미터로 A에서 B에서 C로 다중값을 전달하여 B가 통과할 수 있는 최대값 수를 알 필요가 없도록 하는 방법이 있는가?즉, piped parameter 목록을 하나의 parameter에 배치한 다음 어떻게든 C가 X/Y/Z template call로 공급될 수 있는 단일 parameter를 다시 "확장"할 수 있는 방법이 있는가?아니면 내가 하나 둘씩 통과하는데 갇혀 있는 것일까? -- TeraBlight 07:25, 2006년 11월 22일 (UTC)

작업할 수 있는 실제 사례를 제시해 주시겠습니까?Circeus 22:28, 2006년 11월 23일 (UTC

잠깐만, 내 사용자 페이지에 예를 하나 넣을게...TeraBlight 22:39, 2006년 11월 23일(UTC)

자, 한번 보십시오.사용자:TeraBlight/TemplateLab

물론 이 경우 건축은 바보같다. 그건 신경 쓰지 마.요점은 이 경우 4개의 "booleans" 또는 2개의 숫자 중 하나의 값 집합이 전달되어야 한다는 것이다.발신자측(/TemplateLab)과 중간(/Month) 코드에서 (p1,p2,p3,p4)을 사용하는 것은 상당히 추한 반면, (아침,오후, 심지어 밤, 밤, 첫째, 마지막) 내내 사용하는 것은 덜 추하지만 꽤 서툴다.내가 원하는 것은 그와 같은 단일 파라미터를 사용할 수 있는 것이다(시소코드)

• timeType=1 timeParams=[yes yes no]
• timeType=2 timeParams=[12 16]

전화를 건 사람 곁으로.

• 타임파람스={{timeParams}}}

중간 암호로

문제는 내가 어떻게든 이것을 /데이 또는 /타임에 있는 callee-side의 구성 가치에 "포장"해야 한다는 것이다.TeraBlight 23:29, 2006년 11월 23일(UTC)

ParserFunctions는 아직 살펴 보셨습니까?서커스 23:36, 2006년 11월 23일 (UTC)

네, /Time 템플릿에서 #ifeq와 #ifexpr을 사용하고 있는데...TeraBlight 23:47, 2006년 11월 23일(UTC)

ParserFunctions를 사용하여 텍스트 문자열을 분할할 수 없다.너는 모든 파라메이터를 따로따로 건너가면 된다.일반적으로 기사만큼 자주 보고 편집하지 않기 때문에, 템플릿이 못생기게 보이게 만든다고 해도 큰 문제가 되지 않을 것이다.작업을 수행할 수 있지만 Wikimedia Wiki에서는 사용할 수 없는 m:StringFunctions를 살펴보십시오.Tra(Talk) 23:53, 2006년 11월 23일(UTC)

음, 그래, 직접 문자열 조작을 사용하면 문제가 해결되지만, 현재 사용할 수 없기 때문에...나는 내용물을 문자열(기본 목록이나 배열 기능의 일종)으로 바꾸지 않고 하나의 컨테이너를 사용할 수 있는 어떤 방법이 있을 수도 있고, 파이프나 동등한 것들이 nowiki 태그처럼 어느 시점부터 작동하도록 위키텍스트로 되돌릴 수 있는 어떤 방법이 있을지도 모른다고 생각했다. 어쨌든 고마워.TeraBlight 00:11, 2006년 11월 24일(UTC)

어떤 식으로든 문자열을 구문 분석하거나 단일 매개변수를 여러 개의 매개변수로 변환하는 것은 불가능하다.다음 중 하나를 원할 수 있다.

• 네가 하고 있는 일을 다시 생각해봐. 더 쉬운 방법이 있니?
• 템플리트가 그렇게 복잡하지 않은데, 정말 이 기능이 필요한가?
• 제시된 대로 매개 변수를 하나씩 전달하십시오.

세 번째 경우에는 통과될 가능성이 있는 최대 매개변수를 파악해야 하며, 그것만을 위한 코드도 작성해야 한다. --Alfakim-- talk 06:11, 2006년 11월 24일 (UTC)

봇 니드

7, 8, 265 같은 페이지를 편집해서 WP를 해결:BUCH 문제.그것은 다소 공식적이다.시간을 절약하기 위해 봇/스크립트/무엇을 쓸 수 있는지 궁금하다.그 문제는 1876년 이후까지 계속 되는 것 같다.지금까지 내가 한 일을 보려면 1, 2, 3, 4, 5, 6, 362를 보라.

또한 해체에 있어서 일관성이 거의 없고, 때로는 {{otheruss-number}}, 때로는 {{otherus-number}}, 때로는 둘 다인 경우도 있다.아마도 그것들은 모두 {{otheruss-number}}일 것이고, 5 (동음이의)와 같은 페이지는 5 (숫자)와 합쳐져야 한다.--User24 00:01, 2006년 11월 22일 (UTC)

사용자:Ligulem은 위키백과 버전을 실행한다.스크립트로 작성된 태스크 목록을 제공할 수 있는 AutoWikiBrowser.그는 기꺼이 너를 위해 이것을 할 것이다.위키백과도 있다:봇 요청. -- 릭 블록 (대화) 02:45, 2006년 11월 22일 (UTC)

이것은 위키피디아로 할 수 있다.AutoWikiBrowser. --Ligulem 10:27, 2006년 11월 22일(UTC)

네, 두 분 모두 답변해주셔서 감사드리며, 토크 페이지 리굴렘에 글을 남겼는데 --User24 14:51, 2006년 11월 22일 (UTC)

검색변경

미디어위키에 대해 몇 가지 변경사항을 적용했다.세 개의 연결된 엔진에 대한 사이트 검색 링크를 포함하기 위한 검색노럴트 - 지수가 너무 뒤처진 상태(그리고 미디어위키 검색 엔진은 너무 형편없어서 좋지 않다).이것이 언젠가는 대부분의 사람들에게 영향을 미칠 것 같기 때문에, 나는 여기에 토론을 초대하기 위해 글을 올린다. (WP에 크로스포스팅:VPN, 이 페이지(WP:VPT)에 대해 의견을 제시하십시오.고마워 -- Martinp23 22:53, 2006년 11월 21일 (UTC)

그 고리들은 잘 작동하는 것 같다.결과가 나왔지만 당신이 원하는 것이 아닌 상황을 커버하기 위해 결과 페이지의 바닥글에 링크도 넣을 수 있을까?Tra(Talk) 23:02, 2006년 11월 21일(UTC)

바닥글에 대한 시스템 메시지가 무엇인지(있는 경우)내가 찾을 수 있는 가장 가까운 것은 MediaWiki:검색결과 텍스트, 여기서 텍스트를 넣었지만 코멘트를 주었음.이것은 검색 결과의 맨 위에 있는 텍스트로, 관리자는 검색 결과의 맨 위에 있는 텍스트로, 해당 텍스트에 대한 동의가 있으면 얼마든지 언급할 수 있다(바닥글이 훨씬 낫겠지만, 메시지를 찾을 수 없다).마틴p23 23:22, 2006년 11월 21일 (UTC)

다중 언어 기사

한 언어의 기사를 다른 언어의 기사들과 동일하게 세는 방법은?194.80.178.1 21:26, 2006년 11월 21일(UTC)

"카운트"라니 무슨 뜻이야?다른 언어 위키피디아와 동등한 기사가 수록된 기사 왼쪽에 가끔 보이는 링크를 말하는 겁니까?Notinasnaid 21:27, 2006년 11월 21일 (UTC)

미안. 네, 네. 194.80.178.1 21:30, 2006년 11월 21일 (UTC)

어떻게 해야 하나?194.80.178.1 21:42, 2006년 11월 21일(UTC)

자세한 내용은 Wikipedia:인터위키미디아 링크.이 링크가 있는 기사를 선택하고 편집을 사용하십시오. 기사 맨 끝부분을 보십시오.(인터위키 링크는 반드시 끝에 있을 필요는 없지만, 강력하게 권장된다.)예를 들어 블루스의 끝에서 나는 [[wa:블러제]]]다른 위키피디아("이 예에서는 wa")에 대한 두 개의 문자 코드와 기사 이름("이 예에서는 Blouze")만 있으면 된다.Notinasnaid 21:51, 2006년 11월 21일 (UTC)

이를 위한 코드들이 있는데, 이것은 특정 위키백과 사이트에 처음 두 글자로 부식이 된다.예를 들어 웹어드레스(webadress)가 en이기 때문에 이것은 en이다.wikipedia.org.[[CODE:]를 입력하여 연결하십시오.문서 이름]]], 여기서 CODE는 언급된 두 글자, 문서 이름은 연결 중인 문서의 이름이다.프로데고 21:54, 2006년 11월 21일 (UTC)

guys.194.80.178.1 22:08, 2006년 11월 21일(UTC)

업로드하기 위해 이미지 이름을 지정하는 방법은 무엇인가?

내가 마침내 성공하기 전까지 약 99%의 시간 동안 이미지 이름에 오타가 있다는 오류 메시지를 받는다.나는 이미지 이름 짓기에 대한 일반적인 규칙을 알고 있다.여분의 트릭이 있을까?고마워!매티스(대화) 2006년 11월 21일 20:02 (UTC)

나에게 그런 일이 일어나는 것은 대부분 단어 사이에 밑줄(_ )이 아닌 공간을 사용했기 때문이다.밑줄은 URL 밖 어디에나 있는 공간으로 나타나지만, 소프트웨어는 업로드하기 전에 변경 사항이 당신에게 잘 맞는지 확인하는 것을 좋아한다.GeJo _(c)½ • 09:45, 2006년 11월 22일 (UTC)

이미지 업로드 문제

카와리가(노래) 기사에 싱글 커버 「kaw-lig_Hank_Williams.jpg」를 올리고 싶다.여러 가지 방법으로 이름을 변경했지만 업로드할 때 항상 다음과 같은 메시지가 표시된다.네가 올린 파일이 비어 있는 것 같아. 이는 파일 이름에 오타가 있기 때문일 수 있다. 이 파일을 업로드할 것인지 확인하십시오.어제 나는 더스트 마이 빗자루와 비슷한 파일을 성공적으로 업로드했어.내가 지금 뭘 잘못하고 있는지 모르겠어.업로드 방법의 방향을 읽어 보았다.좋은 생각 있어?고마워!매티스(대화) 2006년 11월 21일 16:26 (UTC)

이미지 이름을 "카우리가.jpg"로 바꿨어.기사 이름에서도 마찬가지다.무엇이 잘못되었는지 알 수 없다.나는 상상할 수 있는 모든 조합을 시도해 보았다.고마워!매티스(대화) 2006년 11월 21일 17시 30분(UTC)

특수:업로드는 당신에게 두 가지 이름을 묻는다. 첫 번째는 당신이 가지고 있는 파일의 이름(예: 하드 디스크에 있는 당신의 파일 이름)이고, 두 번째는 당신이 여기에 업로드되면 이미지에 주고 싶은 이름이다.오류 메시지는 당신이 아마도 당신의 로컬 파일의 이름인 이름의 오타를 만들었음을 의미한다.네가 가지고 있고 업로드하려고 하는 파일이 실제로 비어 있는지도 확인해 볼게.Tizio 19:49, 2006년 11월 22일 (UTC)

감시자 명단

당신의 감시목록을 위한 RSS 스트림이 있으면 좋지 않을까?가능하냐, 안 가능하냐?옌드만 10:19, 2006년 11월 21일 (UTC)

나는 이것이 가능하다고 확신하지만, 대역폭을 이유로 활성화/활성화되지 않았다고 생각한다.니힐트레스 15:13, 2006년 11월 21일 (UTC)

• Bug #471은 RSS/Watchlist 아이디어를 논한다.누군가도 패치를 가지고 있는 것 같아.가장 큰 문제는 워치리스트가 평소 비공개였기 때문에 비밀번호 보호가 필요하다는 점이다.해결책은 (이것들을 정확하게 요약하고 있음) ... 1) 브라우저에서 RSS를 읽는 사람들은 아마도 이미 로그인 쿠키를 가지고 있을 것이다. 그래서 그들은 그것을 그냥 사용할 수 있다. 2) 외부 RSS 리더를 사용하는 사람들에게는, 사용자가 그들의 감시 목록을 반공용으로 만드는 것에 동의하도록 한 다음, 반초짜리 URL을 제공하는 것이 유일한 선택이다.그들의 RSS 리더에게 줄 t 토큰. --Interiot 15:18, 2006년 11월 21일 (UTC)

흥미롭군쿠키는 좋은 생각처럼 보인다(그 계정이 얼마나 오랫동안 스트림을 가능하게 하는 "열린" 상태를 유지할지는 확실치 않지만).뒤에서 벌어지는 일을 보니 반갑다...옌드만 15:25, 2006년 11월 21일 (UTC)

쿠키는 위키피디아에 접속할 때마다 사용하는 쿠키와 동일하다.예: 로그아웃을 하지 않으면 두어 달에 한 번씩만 로그인하면 된다. --Interiot 21:40, 2006년 11월 21일(UTC)

<노캣> 태그?

나는 위키피디아, 특히 템플릿에 포함된 카테고리를 포함하는 상황들에 대해 시간이 지남에 따라 여러 가지 상황을 접하게 되었는데, 그 때문에 미디어위키 소프트웨어가 태그 내의 모든 카테고리를 무시하게 만들 수 있는 태그를 갖는 것이 매우 유용했을 것이다.

1. 현재 이것을 할 수 있는 방법이 있는가?
2. 그렇지 않다면, 이 기능이 요청된 기능이어야 한다고 생각하십니까?

고마워, 니힐트레스 03:41, 2006년 11월 21일 (UTC)

글쎄, <무포함>을 사용하면 된다.태그 안의 카테고리는 템플릿을 분류할 뿐, 그 아래에 분류할 기사는 만들지 않는다. -- ReyBrujo 04:53, 2006년 11월 21일 (UTC)

고마워, 하지만 그것은 전혀 다른 문제는 아니다. 페이지에 번거롭거나 부적절할 수 있지만 원하지 않는 범주를 포함하는 템플릿이 있다고 생각해 보십시오.nowiki 또는 include tag만으로 템플릿이 렌더링되지 않는 한, 페이지는 해당 범주로 분류될 것이며, 이는 내가 상상할 수 없는 해결책이다.니힐트레스 05:48, 2006년 11월 21일 (UTC)

Mediazilla:835 —시뮬레이션(대화 • 기여) 06:13, 2006년 11월 21일(UTC)

이 일반적인 문제의 특정 사례는 거의 항상 무첨부 또는 적절한 #if를 사용하여 해결할 수 있다.어떤 진짜 문제를 해결하려고 하십니까? -- Rick Block (대화) 14:20, 2006년 11월 21일 (UTC)

현재 수행된 작업은 템플릿에서 다음 양식의 범주를 참조하는 것이다: {{{category [Category:예]]]}}}. 템플릿은 여전히 정상적으로 작동한다.그런 다음 범주 없이 템플릿을 변환하려면 형식에서 다음을 참조하십시오. {{예: 카테고리=}}}Tra(Talk) 23:38, 2006년 11월 21일(UTC)

이미지 축소

이미지 크기를 어떻게 바꿀 수 있어?내 말은, 영원히가 아니라, 예를 들어, 사용자 박스를 말하는 거야.현재 이미지가 너무 커서, 사용자 박스의 크기가 적당했으면 좋겠다.--Kukoo275 01:27, 2006년 11월 21일(UTC)

위키백과 참조:확장 이미지 구문.당신은 그것을 얻을 수 있다.트라 (토크) 02:13, 2006년 11월 21일 (UTC)

가, 이제 기억이 난다.한번은 화산 사진을 찍으려고 그랬어.난 바보야. 바보야고마워. --Kukoo275 03:14, 2006년 11월 21일 (UTC)

그러나 사용자 페이지에서는 공정한 사용이 불가능하며, 사용자 상자에서도 공정한 사용이 가능하다는 것을 기억하십시오.놀랍게도, 이미지:Rightswordguy.gif는 공정한 사용이며 사용해서는 안 된다!2006년 11월 22일(UTC) 10:08, Notinasnaid 10:08

비문서 네임스페이스의 Google 인덱싱...

별 생각 없이, 위키피디아 기사들만 (로봇에 의해 강제적으로) 검색 엔진에 의해 색인화되도록 되어 있다는 것이 나의 이해였다.txt 또는 등가물).그러나 나는 방금 나의 강연과 사용자 페이지가 "오파비니아 레갈리스" - [8] - 구글 검색의 네 번째와 다섯 번째 히트를 기록한다는 것을 알게 되었다. - 오파비니아에 위치하고 오파비니아 레갈리스에서 리디렉션된 실제 화석에 관한 우리의 기사보다 훨씬 위급하다.거의 사용하지 않는 나의 하원의 사용자 페이지조차도 우리의 실제 기사보다 우선한다.내 사용자 페이지가 더 자주 연결되기 때문에 이것은 말이 될 수 있지만, 모든 링크는 또한 색인화되지 않은 대화 페이지에 있어야 하는 시그니처로부터 온 것이어야 한다.

나는 사용자 이름이 그럴듯한 검색어인 다른 사용자들의 머리 위에서 생각을 할 수 없지만, 그들은 분명히 그곳에 있을 것이다.구글이 위키피디아 기사에 이례적으로 높은 순위를 매기는 것은 놀라운 일이 아니지만(이 표지판 참조), 기사 공간을 벗어나서 같은 일을 하는 것은 나쁜 징조일 뿐이고, 스팸이나 광고가 인덱싱될 만큼 오랫동안 사용자 공간에 머무르지 못하게 하는 것에 대해 우리가 얼마나 엄격해야 하는지를 보여주는 것이다.Opabinia regalis 05:12, 2006년 11월 13일 (UTC)

Wells there me 사용자:Salix 알바 및 사용자:Quercusrobur --Salix alba (토크) 09:10, 2006년 11월 13일 (UTC)

http://en.wikipedia.org/robots.txt은 Special만 차단하는 것 같다.랜덤, 특수:검색, 위키백과:삭제 및 하위 페이지, 전체 /w/ 페이지(예: 화면 및 기록 페이지 편집)를 위한 문서로 사용자 페이지를 인덱싱하느라 바쁘다.http://www.google.co.uk/search?hl=en&q=wikipedia+help&meta=("실제 도움말")와 같은 구글 검색을 고려한다면 말이 된다. 도움말:내용 및 위키백과:한 페이지를 어떻게 편집하느냐가 여기서 가장 인기 있는 두 가지 방법이다.마찬가지로, "위키피디아 사용자:ais523"은 내 사용자 페이지를 최고 히트작으로 찾는다.--ais523 09:33, 2006년 11월 13일 (UTC)

맞아 - 예상대로 고유하지 않은 사용자 이름 - 합리적으로 검색할 수 있는 항목의 이름을 가진 사용자들을 생각하려고 했어.사용자 페이지를 인덱싱하여 구글 잡음을 더하는 것은 나쁜 일인 것 같다.Opabinia regalis 14:16, 2006년 11월 13일 (UTC)

로봇에서 사용자 페이지를 제외하는 것은 꽤 좋은 생각일 것이다.txt; OTOH, 나는 위키백과:, 도움말:, 카테고리:, 포털: 또는 이미지:를 제외하는 것에 반대한다.템플릿에 대해 확실하지 않음:, MediaWiki: 또는 다양한 토크 스페이스(기사 토크 스페이스에 대해 사람들이 구글로 검색하는 경우를 상상할 수 있지만, 기술 네임스페이스는 위키백과가 아닌 미디어위키에 대한 사이트에서 히트를 쳐야 한다.)--ais523 14:21, 2006년 11월 13일 (UTC)

그래, 나도 위키백과: (그리고 WP:), 도움말:, 포털: 및 이미지:는 색인화되어야 한다 - 카테고리를 검색하는 것이 얼마나 유용한지는 확실하지 않지만, 왜 그렇지 않은지 모르겠다(아마도 카테고리 아래에는 아무것도 없을 것이다:위키백과?)IMO 사용자:, 템플릿: 및 토크 공간과 같은 모든 '내부'가 색인화되지 않아야 한다.공평하게 말하면, 위키피디아 내부 검색 기능은 사람들이 실제로 구글을 사용하여 이러한 영역을 검색할 정도로 충분히 형편없다.Opabinia regalis 01:31, 2006년 11월 14일 (UTC)

문제는 토론/사용자 페이지 등을 검색하려는 사람이 있다면 어쩔 수 없이 위키피디아의 검색엔진을 사용할 수밖에 없고, 찾는 페이지가 로봇에 의해 제한돼 있어 구글(더 나은 것)을 사용할 수 없다는 점이다.txt. 기사 공간 바깥을 가리키는 내부 링크의 일부(전부는 아님)에 rel=nofollow를 붙임으로써 비기사 공간 페이지의 호출랭크를 의도적으로 낮추는 것이 가능할 수 있다.이게 먹힐지는 모르겠지만...트라 (토크) 02:04, 2006년 11월 14일 (UTC)

사용자 이름에 문제가 있는 것은 아닐까?내 이름도 기사의 이름이긴 하지만 여기서 멈춰야 할 것 같아! :-) 카차롯 02:08, 2006년 11월 14일 (UTC)

Opabinia, 나는 그 대답이 명백하다고 생각한다.구글은 단순히 당신이 화석보다 더 흥미롭다고 결정했다.오파비니아에 대한 검색이 화석 페이지를 제공하긴 하지만 기록상으로는 오파비니아에 대한 검색은 화석 페이지를 제공한다.그것은 당신에게 먼저 주는 보다 상세한 오파비니아 레갈리스(화석 페이지의 모든 제목이 끝난 후일 뿐 사이드 아이템만)를 탐색하는 것이다.나는 이것이 아마도 세상이 함께 사는 법을 배울 수 있는 것이라고 생각한다.2006년 11월 14일 05:41 드래곤즈편(UTC)

흠. 카차롯의 경우, 구글 검색에서 우리의 기사를 먼저 보고, 그리고 내 사용자 페이지를 본 결과에서 적절히 들여쓰게 되었다.그것은 타당해 보인다.하지만, 확실히 하기 위해서, 그리고 원칙의 문제로서, 나는 WP를 둘 다.HATNO: 내 사용자 페이지 또는 대화 페이지로 사용자를 이동할 경우 해당 기사로 리디렉션카차롯 12:16, 2006년 11월 21일 (UTC)

사용자 공간 인덱싱은 매우 좋은 한 가지 이유로 유용하다.나는 스팸이 없으면 같은 양의 스팸을 어떻게 찾을 수 있는지 정말 모르겠어.MER-C 12:26, 2006년 11월 21일 (UTC)

Wikipedia_talk에서 시작된 토론:사용자 이름#사용자 이름_해제.카차롯 13:31, 2006년 11월 21일 (UTC)

MER-C, 그게 네가 그 쓰레기들을 파헤치는 방법이야?여기 스팸레이더만 있는 줄 알았는데 :) 내부 검색이 너무 안 되네.Opabinia regalis 00:57, 2006년 11월 22일 (UTC)

네. MER-C 06:15, 2006년 11월 22일 (UTC)

활성 감시 목록 항목

페이지에서 변경할 때는 내 감시 목록에 추가하지만, 가끔 페이지가 다시 파손되지 않도록 며칠만 보고 싶을 때가 있다.임시 watchlisting 옵션을 만들 수 있을까?

내 말은, 어떤 항목을 3일 또는 7일 동안 당신의 감시 목록에 추가할 수 있고, 그 후에는 자동으로 제거된다.3일(또는 7일) 동안 항목을 편집하면 해당 시점부터 3일(또는 7일) 동안 항목이 실행되도록 감시 목록의 시간이 갱신된다.

편집자가 책임감을 느끼는 엄청난 워치리스트에 압도되지 않도록 단기 워치리스트 항목을 자동으로 제거해 편집자(특히 관리자)의 과부하를 방지하는 것이 장점이다.이것은 위키피디아에서 편집자의 팀의 절반 이상을 차지하는 기사의 단기 기물 파괴 행위를 퇴치하는 데 특히 유용할 것이다.--크리스 그리즈월드 (인터뷰) 00:28, 2006년 11월 9일 (UTC)

당신이 할 수 있는 일은 다음과 같은 페이지를 만드는 것이다.사용자:ChrisGriswold/watchlist.페이지를 편집할 때 해당 페이지에 링크를 추가하고 7일 이상 지난 페이지를 제거하십시오.관련 변경사항( -> Special:)을 클릭하여 페이지에서 링크의 최근 변경사항을 확인할 수 있다.최근 변경사항 링크/사용자:ChrisGriswold/watchlist.이제, 만약 우리가 개발자들에게 스페셜에 링크를 추가할 수 있다면:기여.... --Splarka (rant) 08:34, 2006년 11월 9일 (UTC)

난 그 생각이 마음에 들어.사용자 대화 페이지를 제거하러 갈 때마다 감시 목록에 여러 가지 공지사항을 남겼는데, 3개월 전만 해도 누구를 계속 보고 싶은지, 누구를 막 '이미지 출처 없음' 통보를 했는지 기억이 잘 나지 않는다.대안은 내가 추측하는 페이지를 보지 않는 것이겠지만, 때때로 사람들은 이런 것들에 답한다.또한 수동 정리 후 "감시 목록에서 선택한 항목 제거"를 클릭하면 브라우저가 약 5분 동안 일시 중지되고 "전용"에는 최대 8500개의 항목이 있다.그것도 너무 힘들지 않아야 한다.이 페이지 보기 확인란 옆에 "X일 동안 감시" 필드를 추가하기만 하면 된다. empy를 그대로 두면 영구적으로 추가되는 반면 숫자를 입력하면 "만료 날짜"가 감시 목록 데이터베이스의 새 필드에 추가된다.그런 다음 특수할 때마다 스크립트에서 사용자에 대한 "기일 경과" 항목을 모두 제거하도록 하십시오.Watchlist가 로드됨. --Sherol(토크) 08:41, 2006년 11월 9일(UTC)

사용자 토크 페이지에서 회신을 확인하는 것은 감시자보다는 내가 기여하는 것이 최선이라는 것을 알게 되었다. --ais523 09:03, 2006년 11월 9일(UTC)

나는 진심으로 동의한다."X일의 감시 목록" 옵션은 정말 놀라울 것이다.정해진 수량을 사용해도 60일 정도.가능할까? --Quiddity 09:52, 2006년 11월 9일 (UTC)

가능한 것 같지만 메타 데이터를 변경해야 할 것 같아:모든 기록에는 항목이 추가된 시간과 제거 시간이 포함되어야 하기 때문에 감시 목록 테이블.Tizio 10:57, 2006년 11월 9일 (UTC)

제거 시간이면 충분할 텐데, 시스템은 언제 항목을 추가했는지가 아니라 감시 목록에서 언제 제거해야 하는지 알면 된다.그리고 데이터베이스 변경은 필요하겠지만, 새로운 분야를 추가하는 것은 큰 문제가 되지 않는다. 우리는 단지 미디어질라에서 변경 요청을 하면 된다. 몇 명의 사람들이 그것에 투표할 수 있도록 하고 그것을 이행하는데 약간의 개발들이 방해받기를 바란다; --쉐롤 (토크) 2006년 11월 9일 (UTC)

좋은 기능.나도 그걸 사용할 거야. --Ligulem 09:33, 2006년 11월 10일 (UTC)

아니, 그런 식이 아니야.편집본을 제출할 때마다 필드를 채우거나 확인란을 눌러야 하는 것은 원치 않는다.또한, 편집하는 시간에, 얼마나 오랫동안 그 페이지를 내 감시 목록에 올려놓았으면 좋겠느냐고 말할 수 있을지 모르겠다.

내가 마지막으로 본 지 며칠이 지났는지 보는 게 낫겠어.내가 목록을 편집할 때도 이 내용이 표시되어야 한다.그러면 쉽게 리스트를 내려갈 수 있는데, "흠, 나는 6개월 동안 X와 아무 관계도 없었고 그것을 감시해야 할 이유를 생각할 수가 없다.안녕." 그렇게 했으면 좋겠다.수출 특집도 좋을 것 같아.존 리드 ° 04:24, 2006년 11월 11일 (UTC)

물론 그것은 선택사항일 것이다.당신은 아무것도 기입하거나 확인할 필요가 없을 것이다. 그것은 선택적인 추가사항이 될 것이다.

위에서 언급했듯이, 환영/경고를 사용자 대화 페이지에 남기는 것과 같은 특정한 경우가 유용할 수 있는 부분이다.하지만 당신의 방법도 좋고, 서로 연계해서 작동할 수도 있다. -Quiddity 22:18, 2006년 11월 11일 (UTC)

그럼 이걸로 여기서 어디로 갈까? --크리스 그리즈월드 (인터뷰) 06:15, 2006년 11월 13일 (UTC)

셰롤은 바로 위에서 완벽하게 요약했다.버질라는 나를 불안하게 한다. 그렇지 않으면 내가 그것을 할 것이다.그리고 오래 기다리기를 기대하며, 개선은 우선순위가 낮고 개발은 너무 적다. --Quiddity 08:07, 2006년 11월 13일 (UTC)

툴 서버가 다시 가동되면, 나는 이것을 정확히 구현할 계획이었다.기본적으로, 최근의 변화들은 마지막을 유지한다.7일? 편집 일수.기본적으로 최근 변경사항을 사용하여 대상 사용자가 편집한 모든 기사 중 아직 표에 있는 모든 기사 목록을 가져온 다음 해당 페이지에 대한 모든 변경사항에 대해 최근 변경사항을 다시 확인하십시오.툴서버에 대한 쿼리를 실행할 기회가 없어 얼마나 빠른지...워치리스트보다 조금 느리다고 생각하지만, 최근의 변화표는 빠르기로 되어 있다... --Interiot 06:33, 2006년 11월 16일 (UTC)

제발.나는 위키피디아에서 큰 휴식을 취할 뻔 했지만, 편집을 할 때 나에게 가장 큰 무게는 내 감시 목록을 통과하려고 하는 것이라는 것을 깨달았다.이렇게 하면 일이 훨씬 쉬워질 것이다. --크리스 그리즈월드 (인터뷰) 09:20, 2006년 11월 24일 (UTC)

기본 페이지에 링크 서게이터 사용 문제

링크 서게스터를 기본 페이지에 적용하려고 했지만, 서게스터는 기본 wikitext에 구문 오류가 있다고 언급했다. http://can-we-link-it.nickj.org/suggest-links/suggester.php?page=Main_Page

누가 좀 고쳐줄래?Tom 13:14, 2006년 11월 21일 (UTC)

기본 페이지에 링크 서게이터 사용 문제

링크 sugger를 기본 페이지에 적용하려고 시도했지만 기본 페이지 아래에 있는 wikitxt에 wiki 구문 오류가 표시됨.구문 오류는 http://can-we-link-it.nickj.org/suggest-links/suggester.php?page=Main_Page을 참조하십시오.

구문 오류가 해결된 경우에만 이 링크 suger를 사용할 수 있습니다, 다른 사용자가 도와주시겠습니까?Tom 13:11, 2006년 11월 21일 (UTC)

작은 이미지는 너무 작아서 읽을 수 없고 고해상도 다운로드는 큰 이미지보다는 텍스트를 보여준다.

여보세요:

위키피디아의 일부 이미지는 너무 작아서 사람의 눈으로만 읽을 수 없다.예를 들어, 링크:프랑스의 군주 가계도는 매우 작은 이미지를 가지고 있다.이미지:프랑스-2ndCapet.png.이 이미지는 읽기에는 너무 작다; 그리고 고해상도 다운로드는 더 큰 이미지보다는 텍스트를 보여준다.어떻게 이 작은 이미지들이 인간의 눈을 위해 더 크고 읽기 쉽게 만들어질 수 있을까?

72.88.150.208 05:43, 2006년 11월 21일(UTC)

그 페이지는 내게는 괜찮아 보인다.어떤 OS와 브라우저 버전을 사용하십니까?이미지:France-2ndCapet.png, 클릭해서 이미지를 본 후 일부 브라우저를 사용하여 브라우저 창의 높이에 맞게 로드되므로 읽기 어려운 텍스트가 생성되며, 한번 클릭하면 크기가 100%(적어도 Firefox 1.5.x)로 확대된다.물론 후자는 실제 사용적합성 문제는 아니다.온도실 06:18, 2006년 11월 21일 (UTC)

저장 중이지만 게시하지 않음...

안녕, 나는 위키피디아가 "저장, 그러나 게시하지 말라" 버튼을 가지고 있지 않다는 것에 매우 화가 났다고 말하고 싶다.만약 그들이 실제로 그러한 특징을 가지고 있다면 그것은 더 두드러질 필요가 있다.나는 새 기사를 쓰며 술 한잔 마시려고 걸었을 때 매우 속상한 순간이 있었다.내가 돌아왔을 때, 위키피디아는 닫혀 있었고, 나의 모든 힘든 일은 사라졌다.변경 사항 저장 및 포스트 버튼 바로 옆에 배치될 수 있다.그 버튼을 누르면 그 기사가 당신의 기고문에 아낄 수 있을 것이다.만약 내가 틀렸다면 고쳐줘. 하지만 나는 그런 방법이 있다고 믿지 않아.--Gwakamoley 18:07, 2006년 11월 20일 (UTC)Gwakamoley

위키 페이지에 대한 모든 변경사항은 설계상 즉시 실행되므로, 초안을 저장할 수 없고 편집하는 동안 기사에 영향을 주지 않는다.문제를 해결하기 위해 초안 사본을 만들려면, 문서 공간이나 사용자 공간(개인 위키백과처럼:샌드박스).모든 텍스트를 사용자:곽아모리/드래프트 샌드박스 또는 토크:예를 들어 기사 이름/템플은 편집한 내용을 거기서 해결한 다음 다시 모두 선택한 후 다시 기사에 복사하여 그동안 편집한 내용을 다시 포함하도록 주의하십시오.도움이 되십니까? --내블리스 18:16, 2006년 11월 20일 (UTC)

그래, 하지만 난 여전히 그런 기능이 추가되어야 한다고 생각해...불가능하지 않는 한(만약 당신이 그렇게 말한다면).--Gwakamoley 18:20, 2006년 11월 20일 (UTC)

그렇게 할 방법이 없다는 건 거의 확실하다.만약 당신이 프로젝트의 대대적인 점검을 하고 있다면, 나는 당신의 컴퓨터에 있는 프로그램에서 당신의 글을 쓰라고 제안하고 싶다. 당신은 당신의 진보를 원하는 만큼 절약할 수 있다.그 외에는, 어디서든 작업할 수 있도록 사용자 공간의 하위 페이지를 사용하는 것이 좋다.EVula // talk // talk // 2006 // 20:36, 2006년 11월 20일(UTC)

몇 가지 더 좋은 이유: WP는 여러분 자신의 보관 장치가 아니다; 좋은 텍스트 프로세서는 게시하기 전에 권장되는 교정 기능을 사용한다; 당신은 다시 한번 (미리보기 버튼) 원시 게시하기 싫은 것들을 읽을 수 있다. -- DLL 21 ^{.. T}:37, 2006년 11월 20일 (UTC)

나도 호박을 맞았어.해결 방법은 모두 선택하고 ctrl-C를 눌러 클립보드에 복사하는 것이다.그런 다음 편집증이 심하면 메모장이나 워드(또는 기타)에 붙여 넣으세요.이것은 나를 두어 번 구해주었다.위키피디아 특집답게 박자가 낮은 소리로 들리는데, 어떤 경우든 '게시 없는 저장' 특집 내용이 헷갈리게 들린다고 생각한다.Tempshill 06:21, 2006년 11월 21일 (UTC

글을 많이 쓰면 나도 글을 올리기 전에 클립보드에 복사해.만약 뭔가 잘못되면, 나는 다시 시도할 수 있다.때때로 브라우저에서 '뒤로'를 클릭하는 것이 도움이 되지만, 브라우저가 죽거나, 컴퓨터가 죽는다면, 할 수 있는 일이 많지 않다.주요 재작성 시에는 '저장' 기능이 있는 외부 프로그램에서 일하는 것이 가장 좋다.그러나, 다른 사람들이 말했듯이, 텍스트를 다시 썼기 때문에 편집한 내용을 다시 추가해야 한다는 것을 기억하십시오. 그리고 편집 요약에 그것들을 기재하십시오('버전 xyz에서 처음 추가된 편집 다시 추가'와 같은 것을 말함).카차롯 11:43, 2006년 11월 21일 (UTC)

가로 스크롤 막대

오늘 아침부터 나는 Firefox 2.0의 위키백과 기사 페이지(사용자 및 토크 페이지 포함, 감시 목록 제외)에서 가로 스크롤 바를 보고 있다.수평 스크롤 막대는 IE에 나타나지 않는다.MediaWiki에서 CSS나 uputed HTML이 바뀌었는지 아는 사람? -- Jeff3000 23:48, 2006년 11월 19일 (UTC)

난 괜찮아 보인다.아마도 당신의 개인적인 js나 css와 무슨 관련이 있는 것 아닐까?—Mets501 (대화) 02:40, 2006년 11월 20일 (UTC)

텍스트에 "사전" 태그가 포함되어 있는지 여부에 따라 달라질 수 있다. 창 줄의 끝에서 선이 자동으로 절단되지 않고 파이어폭스가 스크롤 바를 제공한다. -- DLL 21 ^{.. T}:39, 2006년 11월 20일(UTC)

외부 링크가 외부 링크로 표시되지 않음

http://en.wikipedia.org/wiki/Speech_recognition#Hidden_Markov_model_.28HMM.29-based_speech_recognition

안녕, 위의 기사 섹션에는 누군가의 웹페이지에 있는 포스트스크립트 파일을 가리키는 링크가 있지만, 기사를 볼 때(Internet Explorer를 사용하여) 위키백과 항목이 아닌 URL임을 나타내는 일반적인 그래픽을 보여주지 않는다. --rebroad 10:42, 2006년 11월 19일 (UTC)

어떤 버전의 IE를 사용하십니까?그래픽은 IE6로 나에게 잘 어울린다.다른 외부 링크는 정상으로 표시되나? --TheParanoidOne 10:55, 2006년 11월 19일(UTC)

그렇기 때문에 일반적으로 그런 것에 대한 구체적인 통지가 없는 한 리치 미디어 콘텐츠에 연결해서는 안 된다(WP:EL. Patstuart^{(talk)(contribs)} 11:53, 2006년 11월 19일 (UTC)

IE7에서 나는 이러한 외부 링크가 한 줄에 있을 때 올바르게 표시된다는 것을 알게 되었지만, 다른 줄에 감으면 화살표가 표시되지 않는다.나는 이것이 css가 어떻게 렌더링되는지에 대한 AA의 문제 때문일 수 있다고 생각한다.Tra(Talk) 14:48, 2006년 11월 19일(UTC)

정말. 아마도 JS로 고칠 수 있을까? —단순 (대화 • 기여) 06:11, 2006년 11월 21일 (UTC)

참조문제

작업 중인 목록을 사용자:에 있는 테이블 형식으로 변환하는 중:VegaDark/Sandbox와 나는 모든 항목을 인라인으로 소싱해 왔다.같은 소스를 사용하는 축구 선수들이 너무 많아서 페이지 하단에 있는 참조 카운트에서 bz를 지나쳤는데 일종의 오류를 보여주고 있다.개발자만이 ca-cz 및 그 이상의 기능을 추가할 수 있다(내가 작업을 마칠 때까지 d 또는 e를 통해 필요할 수 있다).혹시 그런 일이 생길 수 있는 겁니까?고마워, 베가닥 01:49, 2006년 11월 19일 (UTC)

버그/특징 요청으로 간주될 수 있고 버그질라에 게시해야 한다는 걸 방금 깨달았는데, 거기에 계정이 없어...제출하고 싶은 사람?고마워요.베가닥 02:10, 2006년 11월 19일 (UTC)

변화를 만드는 것은 그리 어렵지 않다, 미디어위키:인용 참조 링크 많은 형식 백링크 레이블에 필요한 링크ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs ct cu cv cw cx cy cz 그 끝에 더해졌다.그러나 이 편집은 관리자만 할 수 있다.트라(Talk) 02:36, 2006년 11월 19일 (UTC)

고마워, 잘 됐어.이제 dz를 거친다.그러나 지금은 단어 포장 대신 페이지를 늘린다.개발자들이 프로그래밍을 바꾸지 않고도 워드랩을 할 수 있는 방법은 없을까?베가다크 07:58, 2006년 11월 19일 (UTC)

MediaWiki:cite_reference_link_multi_sep 및 MediaWiki:cite_reference_link_multi_and(관리자가 수행해야 함) 페이지 생성 및 puting  각자 이걸 고칠 수 있을 거야Tra(Talk) 16:59, 2006년 11월 19일(UTC)

페이지를 만드는 데 관리자 관심 있으십니까?베가다크 21:30, 2006년 11월 19일 (UTC)

완료, 작동하는지 알려줘(모두 너의 샌드박스 페이지에 한 줄에 있어)그러나 진지하게, 단일 소스에 대해 최대 dz가 필요한 경우 다른 참조 체계를 고려해 보십시오.2006년 11월 20일 02:51, Opabinia regalis (UTC)

내가 그 페이지를 치운 후에 효과가 있었어, 고마워.나는 원래 참조 체계가 달랐지만, 내가 동료 검토를 통해 페이지를 넣을 때 모든 항목을 인라인으로 인용하는 것을 추천했다. 그렇지 않으면 피처링 상태가 되지 않을 것이다.좀 더 좋은 생각이 떠오를 수 있는지 한번 봐봐.VegaDark 04:11, 2006년 11월 20일(UTC)

특집 리스트에 대해서는 특별히 아는 바가 없지만, 만약 우리가 각주에 dz까지 올라가고 있다면 최근에 인라인 인용 크리프가 통제 불능이 되었다고 말하고 싶다.과거에 사람들은 페이지/섹션/etc 번호와 저자의 이름이 적힌 개별 노트를 포함시키고, 작품에 대한 전체 인용문을 별도의 섹션에 나열함으로써 이 문제를 피했다(WP에서는 이것이 일반적이라는 것을 이해한다).MILHIST 지원 기사).간단한 옵션은 어떤 면에서는 더 탁하지만 작품이 인용될 때마다 개별 노트를 생산하지 않는 기존의 {{ref}/{note}} 시스템을 사용하거나, 단지 노트 대신 이 특정 작업으로 가는 링크된 별표를 포함하는 것이다.하지만 그것들 중 어떤 것이 당신의 특정한 목적에 맞는지 모른다.Opabinia regalis 05:40, 2006년 11월 20일 (UTC)

내가 생각하기에 많은 사람들이 알지 못하는 것은 참조 태그가 이미 동일한 출처에 대해 명명된 다중 참조 인용구를 허용하고 있다는 것이다. --내블리스 18:21, 2006년 11월 20일 (UTC)

사실, 그 특징은 바로 이 문제에 관한 것이었습니다.베가다크 20:30, 2006년 11월 20일 (UTC)

음. 음, 이제 알겠어. 하지만 난 다른 해결책이 있어야 한다는 것에 동의하고 싶어.토론 내용을 잘못 읽어서 미안해. --내블리스 20:48, 2006년 11월 20일 (UTC)

http://stats.wikimedia.org/

아마존닷컴은 며칠째 접속이 안 되고 있다.무슨 일이야? --Derlay 03:16, 2006년 11월 18일 (UTC)

그 도구는 비공개적인 것으로 간주되는 일부 정보를 생성했다.결과적으로, 이 정보가 제거되기 전까지는 통계를 사용할 수 없으며, 도구가 수정되어 다시는 이런 일이 일어나지 않게 된다.

의 실에서 유추해 보면, 툴의 개발자인 에릭 자크테와 우리의 CTO인 브리온 바이버는 이러한 효과와 소통하고 있으므로 가까운 장래에 통계가 복구될지도 모른다. 164.11.204.56 20:41, 2006년 11월 20일 (UTC)

자동 요약 기능 변경?

반달족이 페이지를 비울 때(예: '새로운 페이지 내용'으로 페이지 교체) 자동요약이 있다는 것을 알게 되었지만, 내가 정말 좋아했던 자동요약, 즉 리디렉션을 만들 때 제공된 자동요약이 사라진다.개발자들이 이것을 다시 가져올 수 있을까? :- ( Kimchi.sg 13:30, 2006년 11월 17일 (UTC)

내게 효과가 있다: [9] —단순 (대화 • 기여) 01:18, 2006년 11월 19일 (UTC)

나는 그것을 알아냈다.보아하니 새로운 리디렉션 자동 판매는 ""#REDIRECT과 . 05:35, 2006년 11월 21일 (UTC) 사이에 공간이 필요하지 않다.

자동 요약 생성 여부를 확인하고 리디렉션 여부를 확인하는 데 동일한 코드가 사용된다.요약이 생성되지 않았지만 결과 리디렉션이 작동하는 편집에 링크해 주시겠습니까?—시뮬레이션 (대화 • 기여) 06:08, 2006년 11월 21일 (UTC)

위키백과 기사 작성자의 위치는 어디인가?

내가 이 질문을 도움말 페이지 중 하나에 올렸는데, 누군가가 나에게 마을 펌프도 한번 써보라고 제안했어.나는 기술적으로 타당하다고 알고 있는 것에 대한 정보를 찾고 싶다. 우리가 실제로 그것을 하는지 확신이 서지 않을 뿐이다.나는 어떤 나라의 주민들이 위키피디아에 돌려주는지 관심이 있다.

예를 들어, 기여하는 사람들은 어디에 있는가?wikipedia.org 라이브?그들은 주로 영어가 모국어인 나라에 있는가?아니면 영어가 제2외국어일 뿐이지만 널리 사용되는 장소에는 네덜란드나 인도를 의미하든 수천 개가 있을까?기고자들이 정말 원어민인지 아닌지는 관심 없다(글쎄, 나는 그렇다, 그러나 우리는 일일이 물어보지 않고는 그 사실을 정말 알 수 없다).나는 단지 그들이 어디에 있는지 관심이 있다. 왜냐하면 우리는 그들의 IP 주소를 통해 그것을 추적할 수 있기 때문이다.그리고 물론 나는 그들이 누구인지는 관심도 없고, 이것은 개인의 사생활을 침해하는 것도 아니다.그렇다, (IP주소에 따라) 인도에서 유래된 기사들은, 말하자면, 그곳에 일시적으로(혹은 영구적으로) 거주하고 있는 영국인에 의해 쓰여질 수도 있었지만, 영어를 사용하지 않는 나라들에서 온 수십만 개의 기사가 있다면, 나는 그것들이 모두 국외자에 의해 쓰여진 것은 아니라고 생각해도 무방할 것이라고 생각한다!

es에 기여하는 사람들은 어디에 살고 있는가.wikipedia.org?스페인, 남미, 중앙아메리카, 미국?

zh에 기여하는 사람들은 어디에 있는가?wikipedia.org live 또는 ko.wikipedia.org 또는 ... 이 사람들은 각각의 디아스포라, 소위 "유명한" 중국인들, 대만인들, 또는 인민 공화국에 살고 있는 사람들인가?

추적하기 쉽지 않을까?그리고 그것은 왜 몇몇 위키피디아들이 다른 사람들보다 훨씬 빨리 성장하는지에 대한 통찰력을 주지 못할까?

고마워요.

프레리 아빠 2006년 11월 17일 01:12 (UTC)

당신은 그것을 사용하는 위키에서 국적 사용자 박스를 확인함으로써 알아낼 수 있다; 당신은 또한 어논의 '최근 변화들'을 확인하고 IP를 확인하여 그들이 어느 나라에서 왔는지 확인할 수 있다. --ais523 09:40, 2006년 11월 17일 (UTC)

카테고리를 살펴보는 것을 제안한다.위치별 위키백과 사용자.어느 정도 밝아진 것 같군개인적으로, 나는 테네시에 있어.EVULA // talk // talk // 2006년 11월 20일(UTC)

이에 대한 몇 가지 필기체 통계가 수행되었다. 메타:프로젝트 및 원산지별 편집예쁜 그래프 같은 건 없지만, 데이터가 거기 있어.아마도 가장 흥미롭게도, 중국인들에게:HK: 28.6%, TW: 25.9% ...CN: 6.1% (그 기간 상당 기간 중국 본토에서 차단되었을 것이라는 점을 명심하십시오.)심그레이 토크 20:54, 2006년 11월 20일 (UTC)

SVG 이미지 문제

나는 다음의 SVG 이미지에 문제가 있다.파일은 IE와 FireFox에서 잘 로딩된다.내가 고칠 수 있는 게 있을까? -SharkD 09:41, 2006년 11월 16일(UTC)

위키백과에서 사용되는 libcroco(libcroco, libcsvg에서 사용) 버그 버전에서 알려진 버그다.Libcroco의 업스트림에서 고정되어 있지만, Wikimedia의 서버에서는 여전히 오래된 버전이 사용되고 있다.해결 방법은 버그 보고서 참조… – Gustavb 16:26, 2006년 11월 16일(UTC)

고마워! 인라인 스타일시트를 사용해 볼게. -SharkD 23:36, 2006년 11월 16일(UTC)

벌레가 더 많다.이를 해결할 방법은? -SharkD 23:46, 2006년 11월 16일(UTC)

불행히도 Librsvg 선량은 텍스트 경로를 지원하지 않는다.[10] --Gary van der Merwe 16:18, 2006년 11월 18일 (UTC)

해결 방법: 텍스트를 경로로 변환(Path->Object에서 경로로 Inkscape).라인 엔딩은 사용하지 마, 이것들도 문제야.끝 선을 "없음"으로 설정하고 적절한 위치에 별도로 그려진 삼각형 또는 화살촉을 사용하십시오.

BTW, 이미지가 구형을 보여야 하기 때문에 이 그림과 비슷한 관점이 있지만 오른쪽으로 30° 더 회전하는 것이 좋을 것 같다.루포 12시 5분, 2006년 11월 21일 (UTC)

==doctitle.substr(0,1).toLowerCase()처음 편지의 경우를 제외하고 동일할 경우에만 사실이어야 한다.다시 보는 것만 빼면 그건 완전히 어리석고 잘못된 일이고, 그래야 한다.rtb.substr(0,1).toLowerCase() + rtb.substr(1) == doctitle.substr(0,1).toLowerCase() + doctitle.substr(1)생각합니다밑줄/공간과 같은 다른 변환도 할 수 있다. (처음 문자도 마지막 문자도 아닌 것 같은데?)

또한, 반죽성을 보존하는 지저분한 케이스에 대해 뭔가 해결이 될 수도 있을 것이다(아니, 나는 저 e가 거기에 속하는지 모르겠다).투명성과 z-인덱스로 펑키한 일을 하면 어떨까?실제 제목을 맨 위에 올려놓지만 보이지 않는 표시 제목을 아래에 표시하여 표시하십시오.문제는 실제 제목이 표시 제목(C Sharp)보다 길면 사람들이 제목보다 덜 선택하기 쉽다는 것이다.또한, 사용자에게는 분명히 예상 밖의 일일 것이다.나는 당분간만 표준과 동등한 이름을 고수할 것이다.—시뮬레이션(대화 • 기여) 00:22, 2006년 11월 17일(UTC)

시메트릭의 오른쪽 타이틀은 붙여넣을 수 있는 상태로 유지되어야 한다.사용적합성과 관련된 모든 문제는 보기 좋게 보이는 것, 짜증나는 것만큼 거부권을 행사한다.형식을 깨는 것은 위험하지만, 내가 개인적으로 제안하는 것은 이중 제목을 사용하는 것이 될 것이다. - 주제가 어떤 주제인지, 어디에 다른 주제와 함께 나열되어 있는지 주목하라.C sharp와 같은 기사의 경우, 우리는 어쨌든 직관적인 연결고리에 어려움을 겪을 것이다 - 주제에 대해 잘 알고 있지만 위키피디아는 아닌 사람들은 여전히 [C#]를 쓰고 올바른 페이지로 나아가기를 희망한다.Nihiltres 00:44, 2006년 11월 17일(UTC)

모든 기사에 대해 수정사항을 구현한 다음 마우스를 올리거나 제목 텍스트에 이벤트를 선택하여 붙여넣기 가능한 텍스트가 각각 표시되거나 복사되도록 할 수 있는가? --DavidHOzAu 03:03, 2006년 11월 17일(UTC)

스니키, 하지만 내가 찬성하는지는 잘 모르겠어.어떤 사람들은 제목에 대한 링크를 복사하기 보다는 타이핑하는 경향이 있을 것이고, 그것을 막기 위해 우리가 할 수 있는 것은 아무것도 없다.—시뮬레이션(대화 • 기여) 01:11, 2006년 11월 19일 (UTC)

그래, "붙일 수 있는 경우 실시간으로 체크하고, 붙일 수 있는 경우에만 "h1" 코드를 교체한다(User: 참조):Interiot/js/RealTitle.js).동시에, 그것은 내가 가지고 있던 또 다른 문제를 해결했는데, 대개 한 페이지의 네임스페이스는 "기술적 제약" 때문에 언급되지 않는다는 것이다.그래서 네임스페이스가 거기에 있는지 여부도 자동으로 감지하고, 없으면 추가(다시, 이름이 붙여넣을 수 있는지 확인하기 위해)한다.이 시점에서 대본에 뚜렷한 단점(복잡성 이외에는)이 보이지 않기 때문에 이의 없는 한 곧 모노 스페이스.js에 추가하려고 한다.(사소한 단점은 인쇄가 되지 않는다는 점이고, 라크 피연산자와 같은 몇 가지 이상한 경우는 작동하지 않지만, 97%의 사용을 위해 가능한 한 최선을 다한다고 생각한다) --Interiot 04:42, 2006년 11월 21일 (UTC)

그것은 나에게 좋게 들린다.—시뮬레이션(대화 • 기여) 06:05, 2006년 11월 21일 (UTC)

기술 제한 사항 해결 방법 설명

누군가가 위에서 fr:아이팟 기사는 여기서처럼 '아이팟'이 아니라 '아이팟'으로 제목을 표시한다.이것은 사용자가 "기술적 제약 때문에, blah blah..."라고 읽게 하는 것보다 훨씬 더 좋아 보인다.프랑스어 위키피디아는 {{lowercase}} 템플릿의 존재 여부를 확인하고 소문자 통지를 삭제하며 제목을 소문자 버전으로 바꾸는 사이트 전반의 자바스크립트 기능을 추가해 이를 실현한다.("RealTitleBanner" 검색) 사용자가 Javascript를 활성화하지 않은 경우, "기술적 제약"으로 인해 다시 표시되기만 한다.흐릿하게 하다.

게르브란트는 엔위키에서도 이 일을 해냈다.{{subst:}}{{subst:}}}를 추가하면 지금 이 작업을 할 수 있다사용자:Gerbrant/realTitle.js}을(를) 모노북.js에 연결하십시오.

이 기능이 MediaWiki에 추가되었으면 할 정도로 안전하고 유용해 보인다.모노북.js.이에 대한 우려는? --Interiot 01:24, 2006년 11월 16일 (UTC)

두 가지 사항: 첫째로, HTML 제목과 표시된 제목을 수정하는 것이 좋다.둘째, 혼란을 피하기 위해 위키링크에서 원하는 제목이 통하지 않는 C 샤프 같은 것에 주의할 것을 강력히 제안한다.만약 이것이 현장 전체에 걸쳐 이루어진다면 깔끔할 것이다. 그러나 초기 사례에 대해서만 그렇다.소문자를 표시할 수 없다는 것은 소프트웨어의 어리석은 결함이지만, 그 이름을 더럽히지 못하게 하는 것은 좋지 않은 생각이다.아마도 설명 메시지로는 괜찮겠지만, 별로 중요한 건 아니지, 그렇지?HTML 제목과 인쇄용 제목을 붙이는 데 도움이 되지 않는 곳에서도 수정할 수 있다.—시뮬레이션 (대화 • 기여) 05:22, 2006년 11월 16일 (UTC)

그래서 나는 이것을 제안할 것 같다. (시험되지 않은!)

addOnload Hook(기능) {var rtb = document.getElementById("RealTitleBanner"), if(!rtb )가 반환되는 경우, var docitle = document.getElementById("content).getElementsByTagName("H1").item(0.inner)HTML; if(rtb.substr(0,1) to LowerCase() == docitle.substr(0,1)toLowerCase() {rtb.style.display = "none"; document.getElementByid("content)".getElementsByTagName("H1").item(0.inner)HTML = document.GetElementById("RealTitle").innerHTML; } document.title.replace("/^"+doctitle+"/", rtb);

그 중 얼마나 많은 것이 끔찍하게 부서질지 알 수 없고, 인쇄를 위해 다른 출력물을 얻는 방법도 알 수 없으며, 기사를 직접 보는 것 외에 정확한 디스플레이를 얻는 방법(예: 페이지 편집)은 확실히 알 수 없다.—시뮬레이션 (대화 • 기여) 05:36, 2006년 11월 16일 (UTC)

좋아, 제목이 잘 맞네, 사용자:Interiot/js/RealTitle.js(프랑스 코드에 근거한 것으로, 약간의 오류 확인 기능이 있고 한동안 사용중이기 때문이다.)당신의 제안에 따라, 나는 새로운 div id "RealTitleBannerUnpastable"을 만들었는데, 이는 주어진 제목이 붙여질 수 없도록 의도된 것이다(이 경우, 나는 당신이 말한 대로 H1이 아닌 문서 제목만 바꾼다).(붙일 수 있는가, 붙일 수 있는가?)하지만, 그것이 붙여질 수 있을지를 예측하는 것이 항상 간단하지는 않다.{{underscore}}}}이(가) 태그된 대부분의 기사는 밑줄이 있을 만한 이름의 공백을 대신하지만, 소수의 기사들은 그렇지 않다(Shift-J).IS) 또는 (NSAKEY, "_NSAKEY"는 대부분 붙여넣을 수 있다.)더 직설적인 {{lowercase}}}로도 기사는 첫 번째 주장으로 전혀 다른 제목을 줄 수 있다...이것은 오캄(프로그래밍 언어)과 같은 (삭제된) 타이틀의 전형이다.그것들 중 일부는 어떻게 해야 할지 모르겠어.

인쇄 제목을 고치는 것은 아마도 CSS @media printing과 관련된 것으로 이루어지겠지만, 이 초에는 기계학을 어떻게 작동시키는지 명확하지 않다. --Interiot 07:37, 2006년 11월 16일 (UTC)

이름을 붙여넣을 수 있도록 하기 위해 할 수 있는 한 가지 방법은 자바스크립트가 한 이름이 다른 이름으로 매핑되는지 실제로 확인하는 것이다(예: RealTitle, 대문자, 모든 밑줄을 공백으로 변경하고, 현재 페이지 이름을 얻으면 RealTitle을 대신 표시해도 괜찮다).사소한 일상적인 문제들을 고치는 것 외에도, 그것은 또한 사람들을 혼란스럽게 하는 더 극단적인 시도를 예방할 것이다. --Interiot 17:09, 2006년 11월 16일 (UTC)

위 자바스크립트에서 그렇게 했거나, 아니면 적어도 그렇게 하기로 되어 있었다. rtb.substr(0,1).toLowerCase()

사진 없음!?!

사진은 안 보여!?!서버 문제라도 있나?사용자가 게시함:자혼 165.95.18.61 22:14, 2006년 11월 15일(UTC)

나는 이미지가 잘 나오고 있다. 아마도 너의 컴퓨터에 문제가 있는 것 같다.— Knowledge Seeker er 22:20, 2006년 11월 15일 (UTC)

나는 또한 이 문제를 겪고 있다. IE와 파이어폭스 둘 다 업로드에서 로드하기를 꺼려하는 것 같다.wikimedia.org.블록 설정을 변경해 보았지만 두 브라우저가 모두 불만족스럽다는 사실이 매우 이상해 보인다.좋은 생각 있어?그레이캡 23:09, 2006년 11월 20일 (UTC)

위키피디아의 철자가 틀렸다.

새로운 철자 체커는 훌륭하다; 하지만 당신이 어디에 대문자를 두었든지 간에 위키백과, 위키백과, 위키백과 A가 빨간 선으로 밑줄을 그었는지를 아는 사람이 있는가?나는 그것이 좀 이상하고 별로 중요하지 않다고 생각하지만, 나는 여전히 고쳐져야 한다고 생각해.의사익명 21:50, 2006년 11월 13일 (UTC)

새로운 철자 검사기는 위키백과가 아니라 당신의 브라우저의 일부분이다;) 모든 종류의 것들이 내장 사전에서 누락되어 있다(오픈오피스에서 가져온 것). 단지 마우스 오른쪽 버튼을 클릭하고 "사전에 추가". --Quiddity 22:02, 2006년 11월 13일 (UTC)

이번 기회에 파이어폭스는 그들이 말하는 " 빌어먹을 승리를 위한 것"이라고 선언하고 싶다.:) 164.11.204.56 20:49, 2006년 11월 20일 (UTC)

이미지:AD.jpg의 특성

예를 들어 이 사진에서 나는 픽셀화 된, 진홍색의 반지를 배경에 본다.하지만 노트북으로 영상을 봤을 때 이런 모습은 보이지 않았다.이미지인가 모니터 결함인가? --브랜드 сп코바: 15:32, 2006년 12월 15일 (UTC)

사진은 내가 보기엔 괜찮아 보인다; 당신의 화면 설정의 색 깊이가 아마도 너무 낮게 설정되어 있을 것이다. --ais523 15:34, 2006년 12월 15일 (UTC)

내 사용자 하위 페이지

로그인한 상태에서 기본 사용자 페이지와 함께 두 개의 하위 페이지에 대한 링크를 표시할 수 있는 방법이 있는가?따라서 다음과 같은 대신:

나는 실제로 그것을 읽기를 원한다:

내 Javascript 또는 CSS 페이지를 편집하여 이 페이지를 페이지 맨 위에 추가하는 복잡하지 않은 방법이 있는가? 그리고 그 후에 캐시를 지우고 페이지를 새로 고치는 데만 하면 되는가?나는 두 매체 모두 경험이 없지만 빠른 접근을 위해 항상 이것을 하기를 원했다.이상적으로는 바는 여전히 우측 상단에 있어야 한다.감사합니다.보보. 07:56, 2006년 12월 15일 (UTC)

이 파일을 monobook.js 파일에 저장해 보십시오.

기능 getUserSpaceWikiLink(페이지, 이름){반환 getWikiLink('User:'+wgUserName+'/'+page,(이름?이름:페이지).}기능{반환 '<href="'+wgArticlePath.replace(/\$ 1/, 페이지)+'">, '+(이름?이름:페이지)+'<, /a&gt다;;}기능 insertUserLink(이드, 페이지, 이름)getWikiLink(페이지, 이름){초본 talklink)document.getElementById('pt-mytalk의), var 완벽한.wuserlink)document.createElement()'LI'; newuserlink.id = 'pt-' + id; newuserlink.propertiesHTML = getUserSpaceWikiLink(페이지, (이름?이름:페이지), talklink.parentBefore(뉴유저링크, talklink), } addOnloadHook(기능) {inserLink('sandbox'); inserLink('map', 'MAP');;

그것이 너에게 효과가 있기를!"InsertUserLink" 라인을 복제하여 링크를 추가할 수 있다. -- Renesis (talk) 08:45, 2006년 12월 15일 (UTC)

충돌을 편집하지만 붙여넣기:

이 방법을 사용해 보십시오(삽입하는 대신 추가됨).

ppersonal() {var tb = document.GetElementById('p-personal') getElementByTagName('ul')[0]; addilink(tb, '/wiki/User:Bobo192/MAP', 'MAP', 'p-map', '사용자:Bobo192/MAP', '1'; addlink(tb, '/wiki/사용자:보보192/샌드박스', '샌드박스', 'p-샌드박스', '사용자:Bobo192/MAP', '2'); } addOnloadHook(ppersonal);  function addlilink(tabs, url, name, id, title, key) {     var na = document.createElement('a');     na.href = url;     na.appendChild(document.createTextNode(name));     var li = document.createElement('li');     if(id) li.id = id;     li.appendChild(na);     tabs.appendChild(li);     if(id)     {if(키 > 제목) { ta[id] = [키, 제목], }이(가) { ta[id] = [key, '']인 경우, }이(가) 아니면 }(가) wikibits.js akeytt(; return li; }).js akeytt; }

--Splarka (rant) 08:49, 2006년 12월 15일 (UTC)

고마워, 스플라카그게 바로 내가 원했던 거야.다른 버전을 시도했는데 내가 원하는 대로 되지 않아 버렸으니 나중에 어떻게 하는지 볼 거야.보보. 2006년 12월 15일 18:11 (UTC)

변환된 페이지 편집 내용을 감시 목록에 추가하는 중?

이곳이 미디어위키에 대한 기능을 제안하기에 적절한 장소인지...하지만 이것이 소프트웨어를 가장 많이 사용하는 것이기 때문에(그리고 내가 계정을 가지고 있는 유일한 장소) 나는 여기서 토론을 시작하도록 노력할 것이다.나는 페이지가 편집될 때, MediaWiki 소프트웨어가 그 페이지를 초월하는 모든 페이지를 null로 편집한다는 것을 안다.제 질문은...이러한 null 편집뿐만 아니라 정기 편집도 볼 수 있고, 기본적으로 특정 페이지의 어떤 것이 편집될 때 경고를 받을 수 있도록 "가능한가"라는 문구가 얼마나 짜증스러운지 알 수 있는 개발자인가?예를 들어, 내가 위키피디아를 보고 있다면:관리 요청, 하위 페이지 중 하나를 편집할 때 변경되었다는 통지를 볼 수 있다.난 개인적으로 매우 유용하다고 생각했어...소프트웨어에 추가될 수 있는지 아는 사람? -- Renesis (토크) 07:43, 2006년 12월 15일 (UTC)

여기 강화 요청에 대해 논의할 수 있는 한 곳이 있지만, 개발자의 의견을 원한다면 Bugzilla에서 강화 요청을 여는 것이 가장 좋을 것이다. --ais523 12:05, 2006년 12월 15일(UTC)

최근의 변화

나는 퀴즈를 냈다.이 뉴스 기사에서 그들은 반달리즘을 제거하기 위해 얼마나 많은 캐릭터가 추가되고 제거되었는지 볼 수 있도록 최근의 변화를 수정했다고 말했다.하지만 이 기능이 보이지 않는 이유는 컴퓨터를 잘못 사용하고 있기 때문인가, 아니면 최근 변경사항에서 아직 이 기능이 업로드되지 않았기 때문인가?--PrestonH 05:26, 2006년 12월 15일(UTC)

위키미디어 서버에는 아직 변경사항이 업로드되지 않았다.당신이 링크한 Signpost 기사는 개정판 18237과 18238에 변경 사항이 도입되었다고 나와 있지만, 작성 당시 특수:버전은 r18226이었다.그러나 하위 버전 리포지토리에서 Wikimedia 서버로 변경사항이 복사되는 데는 보통 이렇게 오래 걸리지 않는다.Graham87 10:55, 2006년 12월 15일 (UTC)

아직 r18226이다.위키-l에서 읽었던 것을 기억하는데, 현재 수정사항이 서버에 빨리 업로드되고 있지 않지만, 그 이유는 기억이 나지 않는다. --ais523 12:03, 2006년 12월 15일 (UTC)

최근의 몇 가지 코드 변경은 데이터베이스 레이아웃 변경을 포함한다.이러한 것들은 비교적 사소한 것이어야 하지만, 우리는 여전히 업데이트를 하는 동안 서버를 주의 깊게 배치해야 한다. (데이터베이스를 전환하는 동안 잠깐의 다운타임이 있을 것이다.)오늘이나 내일, 매주 하중이 거의 낮은 상태로 끝낼 것이다. --briion 20:34, 2006년 12월 15일(UTC)

그래서 변화가 일어날 때까지 며칠이 걸릴까?--PrestonH 06:41, 2006년 12월 16일 (UTC)

위키 페이지는 참조란이나 그 이후의 내용을 표시하지 못한다.

나는 레나트 액셀슨을 편집하고 있었다.페이지에는 내가 추가한 참조 섹션과 그 뒤에 있는 두 개의 템플릿(나도 추가)이 생략되어 있다.왜? -피튼거 03:49, 2006년 12월 15일 (UTC)

기사의 마지막 참조에 있는 닫기 태그의 슬래시를 잊어버리기 전의 편집자.고정. --*스파크* 04:01, 2006년 12월 15일 (UTC)

나는 방금 그 기사가 내 워치리스트에 이 페이지 앞에 나열되어 있어서 그 변화를 알아차렸다.내가 그걸 알아차렸어야 했는데.번거롭게 해서 죄송 합니다유언 (Talk - 기여) 05:44, 2006년 12월 15일 (UTC)

검색 문제

최근 며칠 동안 위키피디아에서 존재하지 않는 페이지를 검색할 때마다 구글과 야후 링크를 통해 매번 "검색에 문제가 있었다"는 글이 올라온다.–더 그레이트 라마^moo? 02:50, 2006년 12월 15일 (UTC)

WP:AN3RR 자동 보고 시스템?

WP에서 소개:AN3RR, 위반 보고서는 작성하는데 시간이 많이 걸린다.페이지 기록과 게시판을 왔다 갔다 하면서, 타임스탬프뿐만 아니라 모든 디프 URL을 복사한다(최소 디프 5개와 타임스탬프 5개, 앞뒤로 최소 20페이지의 스위치가 된다).사용자가 보고서를 작성하는 데 도움이 되는 자동화된 시스템을 갖추는 것은 멋진 일이 아닐 수 없다.내 고통을 느끼는 사람?— 코엘라칸 대화 — 2006년 12월 15일 (UTC)

나는 3RR 보고서를 작성하기 위한 자동화된 도구를 본 적이 있다고 생각했지만, 어디에 있는지 기억이 나지 않는다.경박한 보도를 막는 것은 일부러 지루하게 만드는 것이라고 생각한다. --*스파크* 22:06, 2006년 12월 15일 (UTC)

피부변수 문제

JS 문제가 더 많아졌어위키피디아 페이지의 출처를 보면 알 수 있듯이, 위쪽에 다음과 같은 여러 변수를 정의하는 Javascript가 있다.skin="monobook";또는skin="standard";고전용으로나는 몇 가지 대본에서 이것을 이용하려고 노력했다.

함수 myFunction() { //Function code } if(skin="standard") { addOnloadHook(myFunction()); }

조건부 진술이 안 될 이유가 없다고 본다. 조건부 진술은 일단 코멘트를 받으면 잘 통하기 때문이다.사용자:Karl Dickman/standard.js 및 사용자:Userscripts/Editcount link/source.js.카를 딕만 23:22, 2006년 12월 14일 (UTC)

저기 괄호 닫는 거 잊어버린 사람 있어?2세트를 열고 1세트를 닫았다. --Deskanatalk 23:26, 2006년 12월 14일(UTC)

즉,addOnloadHook(myFunction()할 필요가 있다addOnloadHook(myFunction());(아마도 JS는 세미콜론을 생략할 수 있게 해 주었을 것이다, 나는 기억나지 않는다.)—시뮬레이션(대화 • 기여) 2006년 12월 15일 20:57(UTC)

코멘트 역시 정확하지 않다. 그들은 백슬래시가 아니라 전진 슬래시여야 한다.루핀 토크 팝업 23:28, 2006년 12월 14일 (UTC)

단지 비판적인 시류에 편승하기 위해서: js는 표준 피부에만 적재되므로 표준 피부인지 확인하는 것은 좀 어리석은 일이다. --Splarka (rant) 08:22, 2006년 12월 15일 (UTC)

분명히 하자면, 위의 나의 나쁜 JS (폐쇄되지 않은 괄호와 잘못 형성된 논평)는 나의 원래 코드에 문제가 되지 않는다.내 파트와 Firefox의 JS 콘솔에서 철저한 구문 분석으로 양쪽 모두에게 증명할 수 있듯이, 나의 원래 코드는 작동한다.
또한 "the js"가 할당하는 스크립트를 참조하는 경우var skin="skin name" 표준 피부용으로만 적재되는 것이 아니라 어떤 피부에도 적재된다.모노북으로 페이지의 출처를 확인한다.카를 딕만^talk 04:39, 2006년 12월 16일 (UTC)

JS는 User:Karl Dickman/standard.js와 같은 사용자 피부에서 위의 예 코드를 사용하는 것을 언급하였다.모든 사용자 js는 동일한 이름의 스킨을 사용할 때만 로드된다(문서로 common.js를 설정하지 않은 경우).쓰기. --Splarka (rant) 08:12, 2006년 12월 16일 (UTC)

사용자 소개:Userscripts/Editcount link/source.js.이 스크립트는 피부 전용이 아니며, 다른 사용자의 스크립트에 복사되도록 되어 있다.document.write하지만 피부 테스트의 추가는 대본을 망가뜨렸다. 왜?

복사된 이미지 태그

나는 몇몇 이미지에 맞는 태그를 찾으려고 노력 중이다.그것들은 내 지역 신문사에서 복사한 것이지만, 나는 미디어 코디네이터로부터 사용 허가를 받았다.삭제되지 않도록 어떤 이미지 태그를 사용해야 하는가?카브만

독점적으로 "허락을 받고" 사용하는 저작권이 있는 이미지는 위키백과에서 허용되지 않는다.유감스럽게도 공정한 사용 주장이 위키피디아에서 저작권이 있는 이미지를 사용할 수 있는 유일한 방법이다. --Deskana talk 22:56, 2006년 12월 14일 (UTC)

대화 페이지의 부모에게 전화할 수 있는 방법이 있는가?

내가 대화 페이지에 배치하는 템플릿에서 나는 카타고리를 할당한다.현재 {{PAGENAME}}(으)로 설정되어 있다.불행하게도 이것은 내가 카타고리의 토크 페이지의 부모에게 보여주기를 원하는 카스타고리로 토크 페이지를 설정한다.이런 방법을 아는 사람 있어?Markco1 23:29, 2006년 12월 13일 (UTC)

원하는 작업을 수행하려면 상위 페이지에 템플릿 또는 카테고리 링크를 추가하십시오.템플릿이 토크 페이지에만 추가되도록 설계된 경우, 일반적으로 토크 페이지를 카테고리에 추가하는 것이 허용 가능한 대안으로 간주된다.트라 (토크) 00:07, 2006년 12월 14일

(UTC)

사실 내가 조사를 좀 했는데 {{BASEPAGENAME}}이(가) 토크 페이지의 Parent를 반환하는 것으로 보인다.페이지에 바로 배치하여 작업하지만, 왜 템플릿에서 이 작업이 작동하지 않는지 모르겠어.Markco1 17:37, 2006년 12월 14일 (UTC)

나는 당신이 [[카테고리:내 카테고리 {{BASEPAGENAME}}] ?
카테고리 링크를 배치할 때, 당신이 가진 유일한 매개변수는 카테고리 페이지에 나타나는 방법에 영향을 미치는 정렬 라벨일 뿐 링크 자체는 아니다. --*스파크* 17:51, 2006년 12월 14일 (UTC)

그래, 네가 옳아. 그게 내가 시도하고 있던 거였어. 그리고 내가 하고 있는 건 분류하는 것뿐이야.카타고리는 내가 하고 싶은 일을 하는 것을 허락하지 않는 것 같다.내가 뭔가 함께 해킹할 수 있을지도 모르니까 좀 더 조사해 볼게.나는 단지 내 템플리트로 상위 페이지를 혼란스럽게 하고 싶지 않지만 템플리트를 통해 편집하고 싶다. 방법이 있을 것이다.Markco1 18:01, 2006년 12월 14일 (UTC)

나는 페이지를 다른 페이지에서 분류할 수 있도록 허용함으로써 공공 기물 파손의 가능성을 의심한다 - 페이지를 보고 있으면 편집 내용을 볼 수 없고 추적하기가 어려울 수 있다 -*Spark* 18:12, 2006년 12월 14일 (UTC)

위키백과 검색

나는 그 사이트를 좋아하지만 더 좋은 검색엔진이 있을까?나는 구글을 사용하여 위키피디아에서 정보를 검색하는 것보다 위키피디아에서 정보를 검색하는 것을 더 쉽게 찾을 수 있다.예를 들어, 나는 위키피디아에서 GDDI를 검색했는데, 위키피디아에서는 GDDI에 대한 정보가 없이 돌아왔지만, 구글 검색을 하면 찾을 수 있는 위키피디아 페이지를 참조한다.그래서 이것은 훌륭한 개념이지만, 만약 당신이 그것을 검색할 수 없다면, 그것은 그것의 목적을 위한 것이 아니다.

고마워, 칼

잘 했어요해결책을 찾으셨군요.Samsara (대화 • 기여) 16:01, 2006년 12월 12일 (UTC)

구글은 대부분의 사이트에서 가장 좋은 검색 엔진이다."사이트:.."를 추가하기만 하면 되는데 왜 로컬 사이트를 사용하려고 하십니까?구글 검색엔진?Notinasnaid 00:23, 2006년 12월 14일(UTC)

비슷한 문제에 부딪혔는데 버그 리포트가 필요한지, 내가 놓친 게 있는지 잘 모르겠어.내가 '고르첼'을 검색해보니 위키피디아가 검색결과를 0개나 돌려줬지만 '고르첼 알고리즘'이라는 제목의 기사가 분명히 있다.기사 제목에 포함된 단어 검색이 해당 기사에 대한 결과를 반환하지 않는 이유는? --MatWatt 01:58, 2006년 12월 14일(UTC)

현재 그것은 많은 결과를 반환하는데, 그 중 당신이 언급한 기사는 두 번째로 열거된 것이다.일시적 오류가 발생했는지 확인할 수 있는가?그렇다면 시스템이 검색 서버에 연결할 수 없음을 나타내는 메시지를 표시했어야 한다. --briion 10:44, 2006년 12월 14일(UTC)

그래, 그래서 아마 내가 일시적으로 뇌를 잃었을지도 몰라.페이지 왼쪽에 있는 검색 상자를 사용할 때마다 결과가 나타나지 않는다."그 제목을 가진 페이지는 존재하지 않는다."라고 쓰여있지만, 그 접두사가 있는 페이지를 검색할 수 있는 선택권을 주고 많은 결과를 반환한다.나는 방금 검색이 그 검색 키워드를 포함한 모든 기사를 돌려줄 것이라고 짐작했었다.나는 그것이 정확히 일치하는 것을 찾고 있는지 몰랐다.검색 기능이 이런 식으로 작동한다는 것이 매우 이상하다. --MatWatt 22:20, 2006년 12월 14일(UTC)

옆면에 있는 검색 양식에 굵은 이동 단추가 있는 것을 볼 수 있는데, 이것은 입력란을 누르면 기본 동작이다.대신 검색하려면 Search. --Splarka (rant) 08:17, 2006년 12월 15일(UTC)을 클릭하십시오.

뉴봇 아이디어

나는 봇을 어떻게 만드는지 모르지만, 빨간 고리를 제거하기 위한 봇이 좋을 것 같아.

그 단어를 제거하지 않으면(예: 콜트 왓슨 경은 단지 콜트 왓슨 경일 뿐이며, [[]]은 다시 실현될 것이다.생각나는 거 있어?벌써 하나 있어?

빵 02:25, 2006년 12월 14일 (UTC)

위키백과:Wiki프로젝트 적색 링크 복구를 통해 적색 링크의 체계적인 제거그러나 레드 링크는 무분별하게 제거되어서는 안 된다. 그들은 새로운 기사들의 창조를 유도한다.Graham87 03:40, 2006년 12월 14일 (UTC)

잠재적인 기사가 있는 백과사전 주제에 대한 빨간색 연결고리는 그대로 유지되어야 한다. 따라서 모든 빨간색 연결고리를 제거하기 위한 봇은 거의 가능성이 없다.그러나 향후 참조를 위해 위키백과에 봇을 프로그래밍할 것을 요청할 수 있다.봇 요청.고마워!Flcelloguy (A 노트?) 03:52, 2006년 12월 14일 (UTC)

데드 링크에 대한 봇?

누군가가 페이지의 외부 링크를 보고 그들이 죽었는지 아닌지를 결정할 수 있는 봇을 만드는 것이 가능한가? 위약 효과 01:29, 2006년 12월 14일 (UTC)

• 음, 위키피디아를 사용해봐:Bot 요청. --Ixfd64 01:35, 2006년 12월 14일(UTC)

Internet Explorer 7(인터넷 익스플로러 7)을 사용하여 자동 새로 고침을 비활성화하시겠습니까?

IE7로 업그레이드하기 전에, 나는 보통 변경사항을 입력하고, 다른 페이지를 방문하고, 변경사항을 잃지 않고 돌아올 수 있었다.그러나 IE7은 내가 "뒤로" 버튼을 사용할 때마다 자동으로 새로 고쳐지는 것 같고, 저장하지 않은 변경사항은 손실될 것이다.자동 리프레시를 비활성화하는 방법을 아는 사람?고마워. --Ixfd64 01:19, 2006년 12월 14일 (UTC)

하이퍼링크를 클릭하기 전에 바로 미리보기 표시를 클릭하십시오. 미리보기 표시 화면으로 이동하려면 뒤로 버튼을 클릭해도 변경사항을 사용할 수 있다.그러나 미리 보기 표시 화면에서 추가 변경을 수행하면 하이퍼링크를 수행하기 전에 미리 보기 표시를 다시 클릭해야 한다.트라 (토크) 01:38, 2006년 12월 14일 (UTC)

변경하려는 설정은 설정의 "임시 인터넷 파일" 영역에 있는 "저장된 페이지의 새 버전 확인"입니다.[11] --Splarka (rant) 09:36, 2006년 12월 14일 (UTC)

차단 페이지

여보세요

나는 편집의 새로운 사용자다.나는 방금 우리 학교의 페이지를 편집했는데, 학교 수업 시간에 대부분 우리 학교 사람들에 의해 그것이 무더기로 파손되고 있다는 것을 알아차렸다.우리 학교의 등록되지 않은 사용자들이 그 페이지를 편집하는 것을 막을 방법이 있을까?— Cabman이 추가한 사전 서명되지 않은 의견(대화 • 기여)

그들의 편집을 막기 위해 당신이 할 수 있는 것은 아무것도 없지만, 관리자는 페이지를 반비례하거나, 등록되지 않은 모든 사용자가 그 페이지를 편집하지 못하도록 하거나, 학교 IP를 차단하고, 등록되지 않은 사용자가 어떤 것도 편집하지 못하도록 할 수 있다.그러나, 이 경우에는 필요 없어 보인다. 단지 당신이 보는 공공 기물 파손 행위를 되돌리십시오.행복한 편집!프로데고 00:23, 2006년 12월 14일 (UTC)

우리의 로봇 오버로드들

나는 꽤 숙련된 편집자지만 자동화된 로봇을 사용할 기회가 없었다.지금 당장은 로봇에게 딱 맞는 일이 하나 있어.하지만, 나는 그것들을 어떻게 사용하거나 창조할 지 전혀 모른다. (무역에 의한 프로그래머이기 때문에, 나는 기술적으로 상당히 능숙하다.)나는 어콜레이드(회사)에서 어콜레이드(회사)로 연결되는 모든 링크를 업데이트해야 한다.이것을 하기 위해 위키 로보트를 만드는 방법을 아는 사람?TIA! — Jumblefoot Talk 16:23, 2006년 12월 13일(UTC)

그것은 WP에서 보통 하는 일처럼 들린다.AWB; 요청된 봇 페이지를 사용해 보십시오. --ais523 16:40, 2006년 12월 13일(UTC)

SVG 렌더링 문제

위키백과 참조:Graphic_Lab/Images_to_to_to_to_trainnment_bm.어떤 문자는 다른 문자와 맞지 않고 첨자가 나타나지 않는다.잉크스케이프에서는 괜찮게 렌더링되는데, 본문을 경로나 다른 해결책으로 변환하는 대신 SVG를 우리 사이트에서 작동하도록 수정하고 싶다.앞으로 꾸준히 전시를 할 수 있었으면 좋겠다.— 오메가트론 15:38, 2006년 12월 13일 (UTC)

WMF는 Rsvg를 사용하는데, 이것은 아마도 버그로 추정된다.이건 아마도 상류에서 고쳐야 할 필요가 있을 거야. 왜냐하면 우리가 정확히 찾아갈 수 있는 건 아니니까.현재 버전에서 사용할 수 있는 경로로 변환된 텍스트가 있는 버전을 업로드해 보십시오. 따라서 작업을 수정하려는 모든 사용자가 액세스할 수 있으며 지원이 개선될 때 다시 액세스할 수 있습니다.—시뮬레이션 (대화 • 기여) 17:22, 2006년 12월 13일 (UTC)

전폐 편집

변환된 템플릿을 통해 페이지를 변환하는 경우, 변환된 페이지의 제목 옆에 있는 작은 [편집] 상자를 변환된 템플릿 대신 편집하지 않도록 만들 방법이 있는가, 아니면 최소한 이들을 억제하는 방법이 있는가?내가 하고 있는 일의 예를 들어, Talk에서 초월된 동료 리뷰를 확인해 보십시오.찰스 다윈.Adam Cuerden 04:22, 2006년 12월 13일 (UTC) 나는 거기서 그것을 제거했다. 왜냐하면 그것은 또한 편집 기능도 깨뜨리기 때문이다. 그러나 그것은 대부분 다른 페이지에서 작동하기 때문이다. (자동 설정 헤더 제외)

{{{{proview translocation link=위키백과:위키프로젝트_바이오그래피/피어_리뷰/찰스 다윈}}

모든 사람이 한번 볼 기회가 있으면 그것을 없애는 것이 좋다.

• 내가 생각할 수 있는 유일한 방법은 기사에 <노인클루브>와 관련 태그를 사용하여 머리글을 변환하여 정상적으로 표시할 때 큰 볼드체로 대체하는 것이다.페이지를 직접 보는 사람은 누구나 지금과 다른 모습을 발견해서는 안 된다. --*스파크* 15:25, 2006년 12월 13일(UTC)

• 위 상자 및 관련 페이지 참조. --*스파크* 15:29, 2006년 12월 13일(UTC)

IPA 혼란

나는 오페라 9.02를 사용하고 있는데 IPA 성적증명서가 나와 appear과 appear이 똑같이 나타나서 나에게 상당한 어려움을 주고 있다.eszett^talk 02:25, 2006년 12월 12일(UTC)

그 순간까지, 내가 본 모든 전형적인 글꼴은 다르다.

• Arial: ɪ ː
• Arial Unicode MS: ɪ ː
• 비올리눔: ɪ ː
• 비트스트림 사이버비트: ɪ ː
• 캄브리아: ɪ ː
• 교정: ɪ ː
• Charis SIL: ɪ ː
• 크리산티: ɪ ː
• 코드2000: ɪ ː
• 데자부 산스: ɪ ː
• Doulos SIL: ɪ ː
• 에버슨 모노: ɪ ː
• 겐티움: ɪ ː
• 겐티움알트: ɪ ː
• 겐티움 플러스: ɪ ː
• 헬베티카: ɪ ː
• 헬베티카 누에: ɪ ː
• 히라기노카쿠고딕: ɪ
• Linux Libertine: ɪ
• 루치다 그란데: ɪ ː
• 루치다 산스: ɪ
• 매트릭스: ɪ ː
• 키비라: ɪ ː
• STIX: ɪ ː
• 세괴 UI: ɪ ː
• 타임즈 뉴로마어: ɪ
• TITUS 사이버비트 베이직: ɪ ː
• 유니폰트: ɪ ː

(기억: 일부 글꼴이 설치되지 않은 경우 해당 문자가 다른 글꼴로 전환됨)

—Nethac DIU, 항상 여기서 말함.
2006년 12월 13일 20:23 (UTC)

Wikipedia 기본 편집 도구 모음에서 단추 이미지를 표시하지 않음

마침내 이 오랜 벌레의 원인을 찾았다.Firefox 1.0에서 1.5 이상으로 업그레이드한 사용자가 가장 많이 볼 수 있는 Firefox 업그레이드 버그다.1.0에서는 초기 광고 차단 방법이었던 Javascript에서 이미지 변경을 끄기 위한 구성 확인란이 있었다.1.5에서는 이 확인란이 제거되었다.그러나 1.0에서 1.5로의 업그레이드자는 관련 구성 파라미터를 재설정하지 않았다.그래서 이제 사용자는 꼼짝할 수 없게 되었다.

그 후 몇 달 전 위키미디어 개발자들은 화려해졌고 도구모음을 완전히 자바스크립트로 만들기 시작했다.그렇게 삽입된 이미지는 이렇게 차단되었다.

이 문제가 있다면 해결책은 여기 있다.

Firefox에서 about:config를 여십시오.일반 URL 창에 입력하십시오.

dom.disable_image_src_set을 찾으십시오.

마우스 오른쪽 버튼으로 누르고 "재설정"을 선택하여 기본값("거짓")으로 재설정하십시오.

단추가 다시 나타나야 한다.

자세한 내용은 위키미디어 버그 #5747을 참조하십시오. --John Nagle 06:33, 2006년 12월 13일(UTC)

글꼴

불필요한 글꼴을 삭제한 결과, 나는 지금 보기 흉한 대문자 유형의 위키백과 페이지를 받고 있다.제목과 기사를 표시할 때 어떤 글꼴을 사용해야 하는가?로리

위키피디아의 기본 글꼴은 없다.웹 브라우저에서 기본적으로 산세리프 글꼴로 표시해야 하므로, 해당 글꼴 중 하나(가장 일반적인 Arial 포함)를 설치하면 문제가 해결된다.—Mets501 (대화) 04:10, 2006년 12월 13일 (UTC)

이 {{sprotected2}}분은 어디서 오는 겁니까?

{{Computer Magazine}}}은(는) 직접 포함되지는 않지만 어딘가에서 {{sprotected2}}개를 혼용하기 때문에 위에 있는 페이지의 레이아웃이 깨지고 깨진다.나는 {{tnavbar}}과 {{navbar-header}} 둘 다 살펴보았는데 어떻게 다른 템플릿에 들어가는지 알 수 없는 것 같다.이게 어디서 왔는지 아는 사람?흠, 이제 고쳤군.범인을 찾아내다[12].Night Gyr (토크/Oy) 23:16, 2006년 12월 12일 (UTC)

큰 참조 단면

위키백과의 대화 내용:소식통을 인용해.일부 조항은 당연히 큰 참조 단면을 가지고 있다.이제 나는 이것에 전적으로 찬성하지만 몇몇 사람들은 그것이 심지어 두 줄의 형식과 작은 텍스트로도 기사를 다소 다루기 힘들고 밑바닥을 헤프게 만든다는 것을 관찰했다.이 문제를 바로잡기 위해 참조를 자르지는 않겠다.콘텐츠 섹션을 표시/숨길 수 있는 것과 동일한 방식으로 참조에 대한 "숨기기" 기능을 구현할 수 있는가?Sockatume 21:29, 2006년 12월 12일 (UTC)

내가 지울 수 없는 기물 파손의 미묘한 형태.

이 토론을 보십시오.JoshuaZ 18:19, 2006년 12월 12일 (UTC)

IE6 및 미리보기 편집

IE6가 편집을 미리 볼 때 이상한 행동을 한다는 것이 나의 관심에 떠올랐다.페이지를 편집하고 미리 보기를 클릭한 다음 편집 요약이 일반적으로 어디로 이동해야 하는지 아래로 스크롤하십시오.문제의 정확한 본질은 내 머리 위에 있지만, 무언가가 제대로 구문 분석되지 않고 있는 것은 분명하다.아이디어? 루나 산틴 10:03, 2006년 12월 12일 (UTC)

{{PMSA}}}이(가) 포함된 기사를 복사할 때 이 사실을 알게 되었다:여기에 가서 "미리보기 표시" 버튼을 클릭하면 효과를 볼 수 있다.파이어폭스 1.5.0.8은 분명히 그런 문제가 없는 것 같기 때문에 아마도 IE6를 그렇게 재미있게 다루는 CSS 중 하나일 것이다.—PhilTalk 10:11, 2006년 12월 12일 (UTC)

물리학(편집)과 사용자 대화(편집)에서도 같은 문제가 있었다.더 조사해 보면, 그것은 어디에서나 일어나는 일이 아니다.링크가 무엇인지 확실하지 않다. 그 템플릿인 {{PMSA}}이(가) 관련되어 있을 수 있지만, 그것만이 유일한 원인은 아니다.

우리 두 사람 사이에 좀 더 조사해 본 결과, 우리는 그것을 "Align=중앙"을 포함한 위키피디아로 추적한 것 같다. 적절한 경우:

{ -   }

잘 됐다.

{ align=중앙 -   }

위에서 설명한 바와 같이 보르크드.루나 산틴 10:36, 2006년 12월 12일 (UTC)

IE 버전 6.0.2900.2180에서는 잘 작동한다.정확히 어떤 버전의 IE를 사용하십니까? --ais523 16:11, 2006년 12월 12일(UTC)

스크린샷을 게시하십시오.—시뮬레이션(대화 • 기여) 01:55, 2006년 12월 13일 (UTC)

내 워치리스트에서 아이템이 사라지고 있다.

나는 가끔 내 워치리스트에 있는 항목을 보다가 페이지 새로 고침을 하면 항목이 사라진다는 것을 알아챘다.왜 그런 것일까요?변화를 계속 알려주기 위해 감시목록에 의존할 수 없다는 생각이 든다.고마워!타나츠 05:09, 2006년 12월 11일 (UTC)

기사가 삭제, 이동 또는 보호된 경우, 적어도 페이지에 다른 편집이 발생할 때까지 해당 기사가 감시 목록에 나열되지 않는다.흔히 보도되는 사안이다.Titoxd^(?!?) 05:11, 2006년 12월 11일 (UTC)

나는 그 기사가 삭제되거나, 이동되거나, 보호되어 있지 않았을까 하는 의구심이 든다.최근에 나는 어떤 항목에 "diff"를 치고, 기사 토크 페이지로 넘어가서 무엇인가에 반응한 다음, 다시 워치리스트로 돌아와 그 물건이 지금 없어진 것을 알게 되었다.당신이 설명한 문제 때문에 그것이 설명되었는가?타나츠 05:16, 2006년 12월 11일 (UTC)

사실, 내 감시 목록에서 네 답변이 사라졌어!타나츠 05:56, 2006년 12월 11일 (UTC)

기본 설정을 확인하십시오.워치리스트 탭에는 편집한 내용을 워치리스트에 숨기는 설정이 있는데, 이 경우 문제가 될 수 있는 것처럼 들린다.Titoxd^(?!?) 07:55, 2006년 12월 11일 (UTC)

사실 내 워치리스트에서 사라진 건 네 편집이었어.타나츠 01:47, 2006년 12월 12일 (UTC)

예, 이 페이지를 편집한 후 이 페이지(다음으로는 내 편집)가 감시 목록에서 사라집니다...너는 너의 선호도를 확인했니?Titoxd^(?!?) 02:04, 2006년 12월 13일 (UTC)

아, 이제야 설명이 되네.원하는 항목을 선택하십시오.Watchlist 탭에는 "일 수"=3이 표시되고 모든 확인란이 해제된다.타나잇츠 04:06, 2006년 12월 13일 (UTC)

관리자가 아닌 책임

관리자가 아닌 경우 IP 주소에 추가된 헛소리를 어떻게 되돌릴 수 있는가?카스파제스 13:50, 2006년 12월 12일 (UTC)

기록으로 이동하여 가장 최근에 배포되지 않은 버전을 찾고 날짜: "X 시간 기준 수정, Y 날짜", 아무 것도 변경하지 않고 해당 페이지를 "편집"하고 "rvv"를 입력하여 편집 요약에 저장하십시오.이 문서는 선택한 이전 버전으로 되돌아간다.대신, 디프는 이제 단일 수준의 반달리즘을 되돌리기 위한 편집 링크를 가지고 있다.반달리즘 이전 버전의 diff에서 "편집"을 클릭할 수 있으며, 마찬가지로 이전 버전을 변경하지 않고 제출할 수 있다.만약 반달리즘이 합법적인 편집에 의해 묻혔다면, 오래된 디프에는 실험적인 "undo" 기능이 있다 - 시도해 보라.도움이 되기를 바라며, Nihiltres 14:08, 2006년 12월 12일 (UTC)

추가 도움말을 참조하십시오.되돌아가고 있다.Femto 14:40, 2006년 12월 12일 (UTC)

반 보호 실행 취소

사용자 페이지의 반보호 기능이 해제된 경우...내 사용자 페이지가 최근에 IP에 의해 파괴되었기 때문에 나는 이것을 알고 있다. (내 사용자 페이지의 가장 최근의 기록 참조)왜 그러고 있어?이게 정상이야?제거되는 로그 항목이 없음.그랜드마스터카 03:13, 2006년 12월 12일 (UTC)

삭제된 페이지는 보호할 수 없음(그러면 WP:SOLT)를 삭제했을 때 보호되지 않았었죠.—시뮬레이션 (대화 • 기여) 06:07, 2006년 12월 12일 (UTC)

아 맞다.좋은 생각이야.그랜드마스터카 08:57, 2006년 12월 12일 (UTC)

온도 감시 목록

특정한 기간, 예를 들어, 이틀 동안 당신의 감시 목록에 한 페이지를 추가할 수 있다면 정말 좋지 않을까?971(그리고 세고...) 페이지 감시 목록으로 끝나지 않고 게시한 토크 페이지나 반달리즘을 되돌아본 기사를 볼 수 있다.해결책?옌드만 18:50, 2006년 12월 11일 (UTC)

예. 지난 n일 동안 편집한 모든 페이지를 찾아서 해당 페이지에 대한 최근 변경 사항을 보여주는 대체 보기(미디어위키에서 또는 툴 서버가 다시 나타나는 경우)를 가질 수 있어야 한다.당신이 기술하는 것보다 더 무차별하지만, 그럼에도 불구하고 유용할 것이고 비교적 쉽게 구현할 수 있을 것이다(그것은 단지 그 자체와 최근의 변화표의 SQL 조인일 뿐이다). --Interiot 19:58, 2006년 12월 11일 (UTC)

정보 상자 옆에 맞도록 열 수정

노크티나에가 제대로 못 맞추는데, 이걸 어떻게 고칠지 누가 제안해 줄 수 있을까? -- 사서함 02:02, 2006년 12월 12일 (UTC)

당신이 원하는 것을 반영하기 위해 템플릿을 세 번째 열에 붙여서 고친 것 같아.--Coro 02:26, 2006년 12월 12일 (UTC)

• 감사합니다, 바로 그 점이 바로 제가 고치고 싶었던 것입니다 =) -- 사서함 04:50, 2006년 12월 12일 (UTC)

대신 이렇게 해보아라: infobox를 기둥에 끼우는 것 대신에, 그것은 당신 뒤에 기사를 편집하려는 모든 사람들을 완전히 혼란스럽게 할 것이다. 그리고 그 세 번째 기둥을 없애고, 텍스트가 infobox 옆에 올라갈 수 있도록 기둥의 폭을 제한하라.브라우저 창의 크기를 충분히 줄이면 여전히 감소하지만, 만약 당신이 그렇게 빈둥거리고 있다면, 이것은 놀랄 일이 아니다. 더 나아가 기사의 내용은 이제 더 쉽게 편집할 수 있을 것이다.HTH 핸드 — Phil Talk 10:22, 2006년 12월 12일(UTC)

디프 및 히스토리 링크

이것은 사물의 구도에 있어서는 상당히 사소한 문제지만, 워치리스트나 관련 변경 페이지에는 링크를 순서(diff)(역사)로 나열하고, 기여목록에는 순서(역사) (diff)로 기재하는 특별한 이유가 있는가?놀랍게도, 나는 오늘까지 이것을 알아차리지 못했다.Opabinia regalis 05:18, 2006년 12월 11일 (UTC)

아니, 없는 것 같아.아마 원래 암호화된 방식일 겁니다고치기에는 사소한 것이어야 하지만, 사소한 노력이라도 할 만한 가치가 있는지는 모르겠지만.—Ilmari Karonen (대화) 16:09, 2006년 12월 11일 (UTC)

"Diff"에 따른 변경사항을 검토할 때 라인 번호에 따라 변경사항을 찾는 라인 번호가 나열되어 있으므로, 이 링크를 당신의 머리글 아래에 입력한다.아트리스에서 라인 번호를 찾으려면 어떻게 해야 할까?나는 그 어떤 도움 기사에서도 답을 찾을 수 없었다.고마워!리치어 17:20, 2006년 12월 11일 (UTC)

Unix를 생각해 보십시오. 예: vi(vi 편집기)는 줄 번호를 시각화할 수 있도록 허용하고 :set nu를 입력하십시오.그래서 그냥 본문을 복사해서(편집 버전) 써보면 된다.Windows에 갇혀 있으면 vim(vi향상된 ?)이 할 수 있을 겁니다. -- DLL 18 ^{.. T}:10, 2006년 12월 11일(UTC)

기사 내 인용 & 링크

<ref name="</ref>는 본문 단락 내의 링크와 참고문헌 목록에 모두 표시되도록 어떤 식으로든 수정할 수 있는가?

다케시마의 섬 기사에는 항공 및 2링크, 이 섬의 지리적 특징의 수위 견해 있었다.나는 이 두 링크가 예시로서 그리고 참고자료로도 기사에 나타나기를 원한다.(Wikimachine 20:58, 2006년 12월 10일 (UTC)

글의 한 곳에 링크만 나와도 큰 문제가 있어서는 안 된다고 생각한다.그러나 그것이 절대적으로 필수적이면, 예를 들어 <ref> 태그와 함께 정상적인 인라인 링크를 따라갈 수 있다.A search engine [http://www.google.com]<ref>[http://www.google.com Google.com]</ref> . Tra(Talk) 21:52, 2006년 12월 10일 (UTC)

1) 꽤 비표준적인 행동이지만, 그래서 독자들은 혼동될 가능성이 높으며 2) 이것에 대해 정말로 자동 번호의 외부 링크를 사용해서는 안 되며, 대신 단어를 연결해야 한다.그렇지 않으면 "[1][14]"와 같은 것으로 끝날 것이다.위키백과:각주는 자동 번호의 외부 링크를 독자를 혼동시킬 수 있으므로 자동 번호의 각주 링크와 함께 포함하는 것은 좋지 않다고 지적한다. --Interiot 19:52, 2006년 12월 11일 (UTC)

rss 피드

내가 rss를 통해 나의 watchlist를 읽을 수 있는지 궁금하다. 나는 rc가 가능한 것을 안다.헬프데스크에서 물어본 결과, 바로 여기였습니다. 감사합니다, …A:talk 07:56, 2006년 12월 10일(UTC)

지금은 아니지만, 앞으로 시행될지도 모른다.가장 큰 문제는 감시목록을 비밀로 할 필요가 있다는 것이다.이렇게 하는 한 가지 방법은 로그온되어 있다고 하는 쿠키를 시스템에서 확인하는 것이지만 웹 기반 피드 판독기에는 작동하지 않을 것이다.또 다른 옵션은 사용자만 알고 있는 피드의 URL에 긴 숫자를 포함시키는 것이지만 이것은 상당히 안전하지 않다.당신이 할 수 있는 것은 당신이 관심 있는 모든 페이지의 RSS 피드를 당신의 피드 판독기에 추가하는 것이다.Tra(Talk) 14:33, 2006년 12월 10일(UTC)

Tra의 답변은 최신 버전이 아니다. (개인 정보 보호 문제를 해결하기 위해) 로그인한 경우 http://en.wikipedia.org/w/api.php?action=feedwatchlist에서 감시 목록 피드를 받을 수 있다(m: 참조).자세한 내용은 API를 참조하십시오.--ais523 10:58, 2006년 12월 11일 (UTC)

좋아! 하지만 외부 피드 판독기로 어떻게 할 것인가? --TheParanoidOne 11:55, 2006년 12월 11일 (UTC)

안녕! 그거 알게 돼서 반가운데, 어디서 처음 발표되었니?세이지 파이어폭스 확장기를 사용하고 있다.해 보고 어떻게 작동하는지 설명하겠다. -- DLL 18 ^{.. T}:17, 2006년 12월 11일 (UTC)

완료. 시도: sage 다운로드 후 위의 feedwatchlist 링크를 열고 Ctrl+D를 열어 sage 디렉토리에 즐겨찾기를 하십시오. -- DLL 18 ^{.. T}:52, 2006년 12월 11일(UTC)

대량 파괴 행위

이미지와 함께 많은 페이지가 손상됨:고환 클로즈업.jpg.그 이미지는 편집 상자 안에 없고 페이지 수 톤에 있다.:/ – Zntrip 06:29, 2006년 12월 8일(UTC)

미디어에 추가됨위키의 나쁜 이미지 목록; 그것은 몇 페이지를 제외하고는 모두 이미지 양식에 포함될 수 없다.칼 딕맨 2006년 12월 12일 11시 10분(UTC)

리디렉션 이름으로 페이지 이동

혼란을 피하기 위해 잼샌드위치라는 기사는 리디렉션 이름 잼샌드위치(슬랭)로 기본 이름을 바꾸어야 하고, 그 다음 잼샌드위치를 잼샌드위치(슬랑)와 샌드위치를 가리키며 dab 페이지로 만들고 싶은데, 나는 그 동작을 할 수 없다. --ArmadilloFromHellGateBridge 20:26, 2006년 12월 10일 (UTC)

잼 샌드위치(슬랑)는 관리자가 먼저 삭제해야 한다.요청된 이동 시 요청.트라 (Talk) 21:44, 2006년 12월 10일 (UTC)

어? 버그야? 아니면 내가 놓친 게 있어?

안녕. Uotsuri Jima(1차 편집)로 리디렉션하여 DiaoyuDao(토크 히스토리 보호 링크 삭제 로그 보기 편집)를 만들었다.다른 새 편집자가 페이지를 비웠다(2차 편집).나는 그것을 다시 굴렸다.이 페이지는 이제 다시 Uotsuri Jima로 리디렉션되지만, 나의 마지막 롤백은 편집 히스토리에 있지 않다.'정확히 무슨 일이 일어났는지는 확실하지 않다.다만 궁금할 뿐인데, 어차피 내가 만든 리디렉션이 (다이오위다오) 오타가어서 삭제될 수도 있다.나는 단지 무슨 일이 일어났는지 미리 알고 싶었다.감사합니다 Chris 73 Talk 10:39, 2006년 12월 10일 (UTC)

기고문을 읽어보니 댜오위다오, 우오쓰리지마 등을 되짚은 것 같지만,댜오위다오는아닌 것 같다.실제로 리디렉션된 페이지를 되돌릴 때 리디렉션을 되돌리고 있다고 생각했을 수 있다.그러나 예수가 댜오위다오로 옮긴 후(이중 리디렉션 생성)댜오위다오 원본을(효과적으로)복원했다.

이러한 모든 리디렉션, 페이지 이동, 잘라내기 및 붙여넣기 등은 이 글의 역사를 정말 따라가기 어렵게 만든다.역사를 더 엉망으로 만들지 않으려면 극도의 주의를 기울여야 하지만, 여기서 자르고 붙이는 이삿짐 수리에 대한 요구가 있을 것이다.우연히도, 나는 댜오위다오 역사에서 현재 우오쓰리 지마에서는 찾아볼 수 없는 중국의 주장에 대해 타당해 보이는 내용이 있다는 것을 주목한다, 당신은싶을지도 모른다 병합하고 그것을.—Ilmari Karonen(대화) 11:00, 2006년 12월 10일(UTC)

이 청구(그리고 다른 중국)모든 센카쿠 열도에 상세히 설명되어 있다.새로운 사용자는 단지 중국인들의 주장만을 보여주고 다른 것들은 무시하는 것을 선택할 뿐이다.편집에 대해서는, 이 페이지의 「반전」을 확실히 클릭했다.페이지는 되돌렸지만, 리턴은 역사에 결코 나타나지 않았다. -- Chris 73Talk 17:26, 2006년 12월 10일 (UTC)

어쩌면 이게 네가 말하는 역귀신인가?트라 (토크) 17:39, 2006년 12월 10일 (UTC)

커먼스 도구

이 도구는 정말 없어졌는가? --브랜드 сп코바т 23:33, 2006년 12월 9일(UTC)

Wikimedia 데이터베이스가 도구 서버의 MySQL에 복원되는 동안, 예.하지만 다시 돌아올 것이다.Titoxd^(?!?) 21:25, 2006년 12월 10일 (UTC)

기타 사용자 템플릿

만약 이것이 잘못된 부분이라면 사과한다."다른 사람" 템플릿에는 다음과 같이 적혀 있다: "다른 사람 이름..."이것은 문법적으로 틀렸고, "사람"의 복수형은 "사람"이다.템플릿에는 다음과 같은 문구가 표시되어야 한다: "이름있는 다른 사람들을 위해..." -살사맨 22:11, 2006년 12월 9일 (UTC)

나는 이것이 위키피디아 토크에서 가장 잘 진행되는 토론이라고 생각한다.템플릿 토크에서 논의한 내용에 대한 상호 참조를 통한 모호성:다른 사람들. --사용자:Ceyockey (Talk to me) 22:22, 2006년 12월 9일 (UTC)

거울, 거울?

나는 방금 이 사이트가 우리 콘텐츠의 거울처럼 보이지만, 상업적인 장소라는 것을 알았다.나는 이것이 적절한 사용인지 아닌지 궁금하다."수용할 수 없다"고 여겨졌던 비슷한 상황(아마도 이 사이트와 함께)을 떠올리지만, 기술적 측면은 생소하다.만약 이곳이 이 문제를 언급하기에 적절한 장소가 아니라면, 좀 더 경험이 많은 사람이 나에게 정확한 페이지로 가는 포인터를 줄 수 있을까?고마워요.Doc Tropics 21:11, 2006년 12월 9일(UTC)

상업적 사용은 문제가 되지 않는다.{비사업적}} 참조. 그러나 다른 GFDL 준수 문제가 있을 수 있다. --Interiot 21:21, 2006년 12월 9일 (UTC)

이미지 개선을 위한 그래픽 랩

엄지손가락 및 기타 다양한 이미지

안녕 음...미디어위키 로고가 있어야 할 곳에 거대한 엄지손가락을 본 사람?기본적으로 이것은 내가 파이어폭스를 사용할 때만 나타나며 그것은 인터넷 익스플로러의 정상이다.아까 로고 대신 해적 깃발과 교도소 간판이 있었는데...하지만 지금은 거대한 엄지손가락이 있다.무슨 일이야?— Seadog 01:33, 2006년 12월 9일 (UTC)

'What Links Here' 보기

페이지의 '여기 어떤 링크'를 볼 수 있는지, 즉 해당 페이지에 새로운 링크가 만들어지면 내 감시 목록에 표시되도록 할 수 있는 방법이 없을까?내가 묻고 싶은 것은 내가 계속 보고 싶을 때 두드리고 싶은 몇 개의 혼란스러운 페이지가 있기 때문이다. 그리고 그것은 내가 주기적으로 그 페이지에 가서 확인해야 하는 것을 기억해야 할 필요가 없기 때문이다(그 페이지들은 주기적으로 많은 새로운 잘못된 링크를 받는 페이지들이다).던컨힐 16:43, 2006년 12월 8일(UTC)

나는 그렇게 생각하지 않는다. 그러나 그것은 아마도 사용자 스크립트로 이루어질 것이다. --ais523 17:05, 2006년 12월 8일 (UTC)

나는 'What links here' 감시 목록을 만드는 자바스크립트 도구를 만들었다(User:Tra#여기에 링크된 항목).요점은 당신의 감시목록에 있는 모든 페이지의 50개 이상의 백링크가 없는 경우에만 제대로 작동하기 때문에 백링크가 있으면 안 되는 디스패치 페이지 같은 것에만 사용되어야 한다는 것이다.트라 (토크) 2006년 12월 8일 17:30 (UTC)

고마워 트라!내가 필요로 하는 것과 정확히 같아 보인다 :) 사용자 스크립트 문제에 대해 크게 자신하지 않고, 제대로 해냈기를 바랄 뿐이다(즉, 나는 그것에 대해 전혀 아는 것이 없다).던컨힐 17:47, 2006년 12월 8일 (UTC)

응, 제대로 넣었네.무슨 문제가 생기면 말해.트라(토크) 17:59, 2006년 12월 8일(UTC)

상자 크기 편집

"내 기본 설정"에서 편집 상자를 80자씩 25행으로 표시하였다.나는 Win2000의 MSIE6에서 클래식한 스킨을 사용하고 있는데, 최근 (몇 주) 편집 박스가 더 이상 80 * 25가 아니라 역동적으로 사이즈를 맞춘다는 것을 알게 되었다.동적으로 크기를 조정하지 않았다면 훨씬 더 선호한다는 점 외에도, 크기 조정은 잘못되었고 편집 상자의 오른쪽 가장자리가 창 오른쪽에서 벗어났다.창 크기를 조정하면 즉시 크기가 너무 커졌을 때 다시 입력하기 시작할 때까지 상자가 창에 맞게 조정된다.스크롤 막대는 이미 완전히 오른쪽이기 때문에 상자의 이 영역에 접근할 수 없다.어떻게 하면 고칠 수 있을까? -- SGBailey 09:20, 2006년 12월 8일 (UTC)

내 기본 설정 > 편집으로 이동하여 '편집 상자에 전체 너비가 있는지'를 선택하지 않았는지 확인하십시오.트라 (토크) 17:37, 2006년 12월 8일 (UTC)

하나의 문단으로 표현되는 두 단락

원본 텍스트의 두 단락이 페이지에 있는 한 단락으로 렌더링되는 이유와 수정 방법을 아는 사람이 있는가?이것은 Banksia epica에서 일어나고 있다.설명 섹션은 위키 소스가 두 단락 사이에 빈 줄이 있는 두 단락으로 분명히 쓰여 있음에도 불구하고 하나의 긴 단락으로 렌더링되고 있다.문단 사이의 빈 행 하나가 무시되고, 빈 행이 너무 많은 공백만큼 올바르게 렌더링된다.헤스페리안 04:43, 2006년 12월 8일 (UTC)

문제는.''B. epica''<div/>'s. The<div/>3중 아포스트로피가 대담하게 표현되는 것을 막기 위한 것이었지만, 그런 식의 자기중심적인 스타일은 많은 브라우저에서 인식되지 않고 결과적으로 파서가 인식하지 못하기 때문에, 그것은 div를 여는 것으로 해석되었고 그것이 모든 종류의 기이한 현상을 초래했다.효과가 있었다면 결국 B. 에피카처럼 보일 것이다.

가 줄 바꿈을 하고 있다(이상하게도 뭔가가 그것을 완전히 벗겨내고 있다는 것을 제외한다면, feh).

어쨌든 평소의 <노위키>로 바꿔보았더니, 지금은 잘 진열되어 있다.—시뮬레이션 (대화 • 기여) 05:13, 2006년 12월 8일 (UTC)

정말 고마워!Hesperian 10:46, 2006년 12월 8일 (UTC)

의 예도 더 있었다.<div/>기사에, 그리고 구분 기호가 전혀 없는 적어도 하나의 사례에 더하기.나는 그것들을 사용하도록 고쳤다.<span/> 는 한 문자만 길지만 문제를 일으킬 가능성은 적다(div와 같은 블록 수준의 요소가 아니라 텍스트 수준의 요소가 됨).물론 시메탈릭터의 <노위키> 트릭도 그대로 통한다.—Ilmari Karonen(토크) 12:38, 2006년 12월 10일(UTC)