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

글리치

문제는 내가 로그인했을 때 위쪽 마라긴에 "My Talk My Prefences 등"이 있는 "Butter's sister"처럼 보인다.음, 마우스를 움직이면 "내 이야기"가 위키백과 메인 페이지 링크 아래에 있을 정도로 왼쪽으로 이동한다.그것은 문제를 일으킬 것이다.결함은 위키피디아에서 하원으로 갔다가 다시 돌아오면 시작된다.--칼빈수퍼게니우스 20:39, 2006년 2월 27일(UTC)

Ditto, 다른 위키백과에서 온 경우. (발음이 고정됨)--TJ 15:58, 2006년 3월 2일(UTC)

버그 5116

나는 http://bugzilla.wikimedia.org/show_bug.cgi?id=5116에서 특별한 종류의 카테고리 배관을 요청했다.자세한 내용은 여기에 넣지 않을 것이다. 자세한 설명을 원하신다면 버질라 페이지에 남겨두십시오. 개발자들이 내 설명을 확실히 알 수 있도록 하십시오.나의 제안은 주로 항공기 기사를 다루는 것이지만, 다른 주제들도 이 문제를 지적했다고 확신한다.인굴레모 08:05, 2006년 2월 27일 (UTC)

FYI, 내 생각에 491번 버그는 거의 같은 것 같아.—Steve Summit (대화) 18:40, 2006년 3월 2일 (UTC)

페이지가 리디렉션된 경우 수정기호 네비게이션이 나타나지 않음

이것은 일반 불평에서 베껴온 것이다. 나는 여기서 더 많은 식견을 얻을 수 있다고 생각했다.Ta. --Cherry blower tree 13:59, 2006년 2월 23일 (UTC)

페이지 기록을 검색할 때, 다른 페이지로 리디렉션되는 수정본을 선택하는 경우(예: 여기와 여기) 다음과 같이 수정기호 탐색 텍스트:

무료 백과사전인 위키피디아에서
2005년 10월 11일 08:48 기준 개정, 현재 개정 보기
〇 구 개정 신개정 →

...은 나타나지 않을 것이다.혹시 누가 이것을 고칠 수 있을까? -- RattleMan 01:36, 2006년 2월 23일 (UTC)

알려진 대로, 버그질라를 검색해봐롭 처치(토크) 22:42, 2006년 3월 2일 (UTC)

Special에 대한 인수로서 이메일 제목:이메일 사용자

Special에 대한 링크를 만드는 방법:전자 메일 양식의 제목 필드에 원하는 제목이 pr 기본값이 포함된 전자 메일 사용자?html의 메일 링크에 있는 제목 변수처럼.Shanes 20:38, 2006년 2월 15일 (UTC)

현재 모든 이메일은 위키백과 이메일(또는 이와 유사한 변형)이라는 제목으로 전송된다.그것을 바꿀 방법이 없어 보인다.버그가 없는 것 같으니, 버질라에서 특집 요청으로 파일링하는 것을 추천한다.— 매복^(Talk) 사령관 21:20, 2006년 2월 15일 (UTC)

위키피디아를 통해 전송된 이메일은 위키피디아에서처럼 읽을 수 있는 것으로 남아야 하지만 나는 주의를 기울일 것이다.따라서 사용자 지정 주체는 대체하지 않고 표준 주체에 추가되어야 한다.플러그워시 22:15, 2006년 2월 15일 (UTC)

음, 위키백과 이메일은 사실 이미 꽤 비밀스럽다. (내가 "아, 위키백과에서 온 거야!"라고 알아내려면 시간이 좀 걸린다.)이것은 아마도 위키피디아에서 온 것이어야 하며, 이메일을 보낸 사용자에게 회신할 수 있도록 설정되어 있어야 한다.게다가, 이메일 하단에 고지서가 첨부되어야 한다.— 매복^(Talk) 사령관 03:09, 2006년 2월 16일 (UTC)

이것을 원하는 나의 주된 동기는 미디어위키의 메일 링크에 차단된 사용자의 IP를 자동으로 포함시키기 위함이다.차단된 텍스트.페이지는 사용자가 어떤 메일에도 주어진 IP를 포함해야 한다는 것을 주지하지만, 나는 차단해제를 요청하지만 IP를 포함시키는 것을 잊어버리는 자동 차단된 사용자들로부터 꽤 많은 메일을 받는다.그래서 그냥 양식에 주제란에 삽입만 하면 약간의 좌절감을 덜 수 있을 거라고 생각했다.또한 제목 필드에는 관리자가 가질 수 있는 전자 메일 필터의 중요도 수준 설정을 높일 수 있는 문자열 "요청 차단 해제" 또는 그러한 문자열이 포함될 수 있다.Shanes 10:57, 2006년 2월 16일 (UTC)

이 시점에서 여러 가지 다른 문제/기능 요청을 처리하고 있는 경우.— 매복^(Talk) 사령관 23:51, 2006년 2월 17일 (UTC)

아니, 난 아니야.왜 날 그렇게 생각하는지 이해가 안 가.Shanes 07:20, 2006년 2월 23일 (UTC)

좋아... 아닐지도 몰라. (결국 시행되는 것 중 하나면 충분할 거야.)하지만, 우리가 다룬 내용은 다음과 같다.

• 사용자에게 사용자:와 같은 페이지를 편집할 수 있는 기능 제공Special에 표시되는 예/이메일:Emailuser/예: 사용자가 전자 메일을 보내는 사람들에게 "제거자"를 넣을 수 있도록 한다.
• 불평하는 블록에 대해 특정 유형의 전자 메일을 생성하여 자동으로 IP 주소를 제공(대부분의 사람들은 개인 정보 보호를 위해 다른 사람에게 전자 메일을 보낼 때 자신의 IP를 제공하지 않으려 함)하거나...
• 사용자가 특수처럼 액세스할 수 있는 여러 유형의 위키백과 전자 메일 양식을 설정할 수 있도록 허용:이메일 사용자/예제/사용자 지정 제목이 포함된 차단/자동으로 추가된 항목 등
• 제목 위키백과 이메일을 사용하는 대신 사용자가 제목을 지정하고 [Wikipedia Email]을 앞에 붙이도록 허용하십시오.

그런데, 우편물의 주제 변수는 표준이 아니며, 대부분의 우편 고객들이 그것을 존중하지만, 그것을 사용해서는 안 된다.— 매복^(Talk) 사령관 21:16, 2006년 3월 1일(UTC)

우린 아마 서로를 이해하겠지만, 분명히 말하는데:사용자가 메일 양식을 편집하고 제출하기 전에 제목(또는 본문) 필드에 문자열을 삽입할 수 있는 방법을 원했을 뿐이다.사용자는 임의의 필드에 삽입된 문자열(html mailto: equivalent)을 제출하기 전에 편집할 수 있으며, 이 문자열은 모든 개인 정보를 관리해야 한다.단지 차단된 사용자들이 자신에게 주어진 IP를 MediaWiki에 넣는 것을 잊어버린 곳에서 그러한 메일을 받는 것뿐입니다.실제 형식의 차단된 텍스트(3달러에서 해당 페이지까지)는 메일을 무의미하게 만든다.나는 그들을 다시 우편으로 보내야 하고, 어떤 응답이 오기를 기다려야 해. 그 모든 것은 양쪽 모두에 많은 시간과 좌절감을 주고 있어.그리고 나는 이 옵션에서 이 특별한 경우를 제외한 다른 용도를 볼 수 있다.

메일에 대한 주제의 논거가 얼마나 표준적인지에 대한 당신의 다른 의견: 나는 그것이 RFC 2368이 말하는 것만큼 표준이라고 생각한다.

메일토 URL의 작성자는 URL의 확인자가 "주체"와 "본문" 헤더 이상을 이해하기를 기대할 수 없다.메일투 URL을 메일 메시지로 해결하는 클라이언트는 "주체" 및 "본문" 헤더를 사용하여 RFC 822 준수 메일 메시지를 올바르게 작성할 수 있어야 한다.

MUST라고 쓰여 있지 않지만, RFC에서 말하는 것에 꽤 강해야 한다.그러나 이것은 어쨌든 요점을 벗어난 것이다. 왜냐하면 우편물이 있었든 없었든 간에 그것은 좋은 선택이 될 것이라고 생각하기 때문이다.어쨌든, 미디어위키에서 시행되지 않은 것을 이해했고 나는 버질라를 구걸하러 가야 한다.아마 그럴 거야, 다음 번에 그 IP lacking unblocking mails에 좌절할 때 말이야.셰인 23:22, 2006년 3월 1일(UTC)

후, 내가 착각한 것 같아 (특정 헤더가 표준이 아니라는 걸 알고 있었네, 자 간다.내 RFCs를 다시 고쳐야 한다.

이것은 시행하는 것이 그리 어렵지 않을 것 같다.링크 또는 일부 사용자 프리f에서 이 문자열을 지정할 위치를 지정하십시오.— 매복^(Talk) 사령관 01:35, 2006년 3월 2일 (UTC)

AOL & autoblocker 설명

autoblocker 및/또는 그것이 AOL 사용자에게 미치는 영향을 명확하게 설명하는 프로젝트 페이지가 어디에 있는가?차단된 것에 대해 혼란스러운 AOL 사용자들로부터 받는 이메일의 양이 최근에 상당히 증가했고 나는 답변을 위해 그들에게 어떤 획일적인 장소를 보내기를 원한다. 안드로이드79 22:17, 2006년 3월 1일 (UTC)

내용 목록

나 자신뿐만 아니라 자동 ToC를 검색하는 다른 사용자를 위해 사용자 페이지에서 강제로 자동 ToC를 제거할 수 있는 방법은?셰루르시즈 09:43, 2006년 3월 1일(UTC)

페이지 어딘가에 __NOTOC__를 포함시키면 그것이 요령이 될 것 같다.--벚꽃나무 11:26, 2006년 3월 1일 (UTC)

링크 - 밑줄 표시 여부?

위키링크가 밑줄을 긋는 것에서 밑줄을 긋지 않는 것으로 계속 바뀌는 이유를 아는 사람이 있는가?스타일 포맷 부서에서 편집 전쟁이 벌어지고 있는 건가? - MPF 12:17, 2006년 2월 28일(UTC)

일반적으로 이러한 현상은 브라우저가 스타일시트 중 하나를 로드하지 못했기 때문에 발생한다(대부분 기본 설정에서 생성된 스타일시트일 가능성이 있음).수정하려면 브라우저에서 강제로 다시 로드하십시오(Firefox에서 Shift-Reload).--cesarb 13:58, 2006년 2월 28일 (UTC)

아니, 그건 아무런 차이가 없어. 그리고 내 취향에 따라 언더라이닝이 저절로 변경될 수 있는 곳은 아직 일어나지 않은 다른 훨씬 더 명백한 페이지 레이아웃 변경 없이 어디에도 없어. - MPF 14:43, 2006년 2월 28일 (UTC)

내 기본 설정에는 밑줄이 그어져 있거나 그렇지 않은 옵션이 있다.'Misc' 아래, 드롭 다운 박스에 기재되어 있다. --Cherry blower tree 11:25, 2006년 3월 1일 (UTC)

고마워! 내가 어떻게 그걸 놓쳤지?? - MPF 13:41, 2006년 3월 1일(UTC)

대화 페이지를 보관하는 방법?

토크 페이지를 보관할 수 있는 두세 가지 방법이 떠오르지만, 공식적인 방법이 무엇인지 알고 싶다.예를 들어, Move를 하면 모든 편집 내역이 보존된다...아마 리디렉션으로 새 페이지를 만들었을 겁니다그러나 나는 하위 페이지를 만들고 나서 원본 페이지의 대부분의 내용을 잘라 붙여 마지막 몇 가지 항목은 그대로 둘 수도 있었다.이것은 연속성을 보존할 것이다.

공식적으로 허가된 해결책은? --Kaz 19:08, 2006년 3월 3일 (UTC)

위키백과:토크 페이지 보관 방법 - Liberatore(T) 19:19, 2006년 3월 3일(UTC)

둘 다 보통 사용된다.어떤 사람들은 오려 붙여서 보관하고, 어떤 사람들은 이사해서 보관한다; 그것은 개인적인 선호에 더 가깝다.그러나 세 번째 방법(역사에 보관)은 피하십시오. 세 번째 방법에는 상당한 단점이 있다(가장 중요한 것은 오래된 의견을 검색하는 것을 훨씬 어렵게 한다).--cesarb 21:12, 2006년 3월 3일 (UTC)

제목줄에서 Enter 누르기

나는 위키피디아와 같이 새로운 것이 많은 포럼들이 왜 다음과 같은지 갑자기 이해한다.레퍼런스 데스크, 결국 많은 사람들이 동봉된 텍스트 없이 모호한 제목을 추가하게 된다!

주석 추가 편집 페이지에 제목을 입력한 후 Enter 키를 누르면 "페이지 저장"을 누른 것처럼 동작한다.나는 이런 일을 하는 대부분의 사람들이 둔하거나 도움이 되지 않거나, 상자가 검색 엔진이라고 생각하지 않을 것이라고 생각한다. 그들은 심지어 방향을 읽었을지도 모른다.그러나 대부분의 이메일 고객들에게 거의 확실히 옳은 일을 할 수 있는 입력 키를 누르면 위키피디아에 관련된 모든 사람들에게 전혀 도움이 되지 않는 일을 하게 된다.그리고 그 신참은 아마 포기하고 떠나버렸을 것이고 우리는 그 멍청하고 앞뒤가 맞지 않는 신참들에 대해 투덜거린다.

이것을 합리적인 것으로 바꿀 수 있을까?가장 좋은 것은 입력 키가 당신을 피사체에서 신체로 데려가는 것일 테지만, 그것은 형태의 한계로는 가능하지 않을 수도 있다.입력 키를 가지고 있다면 아무것도 하지 않는 것이 좋을 것이다.r스피어 / ɹəədsɹ 15:48, 2006년 3월 3일 (UTC)

나는 루핀이 72시간 전에 이것을 바로잡아야 할 패치를 범했다고 믿는다.롭 처치(토크) 18:50, 2006년 3월 3일 (UTC)

기둥 사이의 간격을 좀 줄여 주시겠습니까? - 내 능력 밖이야.

이거 좀 도와줘두 기둥 사이에는 가운데(또는 거의 가운데) 아래쪽에 하얀 공간의 열이 있다.어떻게 하면 같은 상자의 다른 가장자리에 있는 간격과 균일하게 간격을 줄일 수 있을까?네가 이렇게 할 수 있다면 나는 너를 마크업 GOD(Djinn의 GOD)로 숭배할 것이다.

오귀스트 로댕의 조각상인 사상가는 종종 철학을 나타내기 위해 사용된다. 철학(그리스어: φφιλσοα, 철학, '지혜의 사랑')은 존재, 이성, 지식, 가치관, 마음, 언어에 관한 것들과 같은 일반적이고 근본적인 질문들에 대한 학문이다.그러한 문제들은 종종 연구하거나 해결해야 할 문제로 제기된다.어떤 소식통은 이 용어가 피타고라스 (기원전 570년–기원전 495년)에 의해 만들어졌다고 주장하고 있으며, 다른 사람들은 피타고라스가 단지 현존하는 용어의 사용을 주장했을 뿐이라고 주장하며 이 이야기에 이의를 제기한다.철학적 방법으로는 질문, 비판적 토론, 이성적 주장, 체계적 제시 등이 있다. 역사적으로 철학은 지식의 모든 몸을 아우르며 실천가는 철학자로 알려져 있었다.고대 그리스 철학자 아리스토텔레스 시대부터 19세기까지 '자연철학'은 천문학, 의학, 물리학을 포괄했다.예를 들어 뉴턴의 1687년 자연철학의 수학적 원리는 후에 물리학의 책으로 분류되었다.19세기에는 현대 연구 대학의 성장이 학문 철학과 다른 학문들을 전문화하고 전문화하도록 이끌었다.이후 전통적으로 철학의 일부였던 다양한 조사 분야가 별도의 학문적 학문, 즉 심리학, 사회학, 언어학, 경제학과 같은 사회과학이 되었다. 오늘날 학문철학의 주요 하위 분야로는 존재와 현실의 근본적 본질에 관계되는 형이상학, 지식과 신념의 본질을 연구하는 인식론학, 도덕적 가치에 관계되는 윤리학, 진정한 전제로부터 결론을 도출할 수 있는 추론규칙을 연구하는 논리학 등이 있다.es. 다른 주목할 만한 하위 분야로는 과학철학, 정치철학, 미학, 언어철학, 정신철학 등이 있다. (더 읽기) 철학은 인간이 물어볼 수 있는 가장 근본적인 질문들을 고수한다.이것들은 점점 더 많아지고 시간이 지남에 따라 철학나무의 겹치는 가지들로 배열되었다. 미학:예술이 무엇인가요?아름다움이란 무엇인가?미각의 기준이 있는가?예술은 의미있는가?만약 그렇다면, 그것은 무슨 의미죠?좋은 예술이란 무엇인가?예술은 목적을 위한 것인가, 아니면 "예술을 위한 예술인가?"무엇이 우리를 예술과 연결시키는가?예술은 우리에게 어떤 영향을 미치는가?어떤 예술은 비윤리적인가?예술이 사회를 타락시키거나 고양시킬 수 있을까? 인식론:지식의 본질과 한계는 무엇인가?아는 것(종양학)과 있는 것(종양학) 중 인간 존재에 더 근본이 되는 것은 무엇인가?우리가 알고 있는 것을 어떻게 알게 되는가?지식의 한계와 범위는 무엇인가?(할 수 있다면) 다른 마음이 있다는 것을 어떻게 알 수 있을까?(할 수 있다면) 외부 세계가 있다는 것을 어떻게 알 수 있을까?어떻게 우리의 답을 증명할 수 있을까?진실한 진술이란 무엇인가? 윤리: 윤리적으로 옳고 그른 행동(또는 가치관 또는 제도)에 차이가 있는가?만약 그렇다면, 그 차이는 무엇인가?어떤 행동이 옳고, 어떤 행동이 그른가?신의 계명은 옳은 행동을 하는 것인가, 아니면 그들의 옳은 것이 다른 것에 근거하는 것인가?절대적으로 옳은 기준들이 있는가, 아니면 그러한 기준들이 모두 특정 문화와 관련된 것인가?나는 어떻게 살아야 할까?행복이란 무엇인가? 논리: 무엇이 좋은 주장을 만드는가?복잡한 논쟁에 대해 어떻게 비판적으로 생각할 수 있을까?무엇이 좋은 생각을 하게 만드는가?내가 언제 무슨 말을 해도 말이 안 된다고 말할 수 있을까?논리의 기원은 어디인가? 형이상학:어떤 종류의 것들이 존재하는가?저것들의 본성은 무엇인가?어떤 것들은 우리의 인식과 별개로 존재하는가?공간과 시간의 본질은 무엇인가?몸과 마음의 관계는 무엇인가?사람이 된다는 것은 무엇인가?의식하는 것은 무엇인가?신들은 존재하는가? 정치 철학: 정치 제도와 그들의 권력 행사가 정당화되었는가?정의란 무엇인가?정부의 '적절한' 역할과 범위가 있는가?민주주의가 최고의 통치 형태인가?거버넌스가 윤리적으로 정당한가?국가가 허용되어야 하는가?국가는 특정한 도덕적 또는 종교적 교리의 규범과 가치를 증진시킬 수 있어야 하는가?국가는 전쟁을 할 수 있는가?국가는 다른 주의 주민들에 대한 의무를 가지고 있는가? 철학(책) - 철학에 관한 주요 기사는 다른 많은 기사로 이어진다. 서양 철학 동양철학 철학의 역사 서양철학의 역사 철학(책) - 철학에 관한 주요 기사는 다른 많은 기사로 이어진다. 서양 철학 동양철학 철학의 역사 서양철학의 역사 관련 위키미디어 다음의 위키미디어 재단 자매 프로젝트는 이 주제에 대해 더 많은 것을 제공한다. 위키북스 책들 커먼스 미디어 위키뉴스 뉴스 위키코테 인용구 위키소스 텍스트 위키 다양성 학습 리소스 위키보이지 여행안내역 위키트리노리 정의들 위키다타 데이터베이스 위키피디아 종족.

나도 노력하고 노력했는데, 도저히 이해할 수가 없어.나는 그 페이지의 다른 박스들 사이에 있는 것과 같은 공간을 가진 두 개의 기둥을 함께 짜야 한다.국경은 양호하며, 예측한 대로 작동한다.하지만 그 중앙의 넓은 공간은 나를 NUTZ로 몰고 있다. (그리고 아니, 이것은 철학 포털을 위한 것이 아니다.div 기반 레이아웃보다 사용되는 차트 코드가 더 안정적이기 때문에 출발점으로 선택했다.그건 그렇고, 나는 이중 외곽 경계선이 있어야 머물 수 있어.고마워. --해봐! 2006년 3월 3일 12시 14분(UTC)

이것을 어디에 사용하고 싶은지 정확히 모르기 때문에, 어떻게 고쳐야 할지 정확히 알 수 없지만, 나는 어떤 일반적인 정리나 간소화를 권하고 싶다.하지만, 이 페이지를 어지럽히기 보다는, 나는 하위 페이지에 있는 몇 가지 버전을 가지고 놀 것이다.이 질문을 사용자:힘내!/테이블 테스트.로사미 (토크) 21:14, 2006년 3월 3일 (UTC)

그게 더 나을까?잠시 패딩과 여백을 가지고 놀다가 더 깊이 파고들었고, 그 테이블 안에 테이블이 중첩된 다섯 개의 기둥이 있는 이유를 알 수 없었다.나는 그것을 하나의 셀 테이블이 아닌 테이블 셀에 직접 테두리를 적용하는 두 개의 열로 단순화했다.내 생각엔 내가 할 수 있는 한 코드를 단순화해서 과도한 패딩과 여백을 모두 제거했고, 아마 너처럼 CSS를 이해하는 사람을 위해 과도하게 편집한 것 같아.그래도, 나는 그것이 앞으로 유지될 수 있는 누군가에게 도움이 되기를 바란다.이게 네가 원하는 걸 하는 거야?— 캐서린\ 22:^talk08, 2006년 3월 3일 (UTC)

미안, 로사미와의 충돌을 편집해!Go for it!/테이블 테스트에 메모 남겨놓을게.— 캐서린\ 22:^talk09, 2006년 3월 3일 (UTC)

이미지 문제

케임브리지 대학의 이미지에 이상한 일이 일어났다 - 흰색 바탕에 세로 회색 선이 있는 가운데 블루랩 17:09, 2006년 3월 2일(UTC)

이미지 폭을 121px(128px부터)로 축소해서 절반 정도 보기 좋게 박스를 되돌려 놓았다.어찌된 일인지 썸네더는 이미지의 폭이 122~170픽셀(다시 작동하는 171픽셀 이상 사용) 사이일 경우에만 회색선을 출력한다.이상한 일이 일어나고 있어...청소와 교대조 교대조정을 시도했지만 라인만 얻었다. -- grm_wnr Esc 20:57, 2006년 3월 2일 (UTC)

이미지 페이지에서 ?action=purge를 사용하여 해당 이미지에 사용 중인 미리 보기를 재생성하도록 하십시오. --Briion 04:13, 2006년 3월 3일(UTC)

범주:로고 카테고리 페이지를 사용할 수 없음

현재 모든 로고의 이미지가 카테고리 페이지에 나타나기 때문에 페이지로 이동하면 200개의 이미지를 로드하려고 시도한다.여기에 로고가 너무 많아 첫 페이지부터 9~11pdp까지 올라가며 글자마다 수십 페이지가 달려 있어 무엇이든 불가능한 것을 찾아내는 행태를 부린다.로고를 하위카타고에 넣어 문제를 해결하려 하지만 로고 템플릿이 메인 페이지에 로고를 붙이기 때문에 해결이 안 되는 사람들이 있다.이 문제를 해결하기 위해 어떤 조치를 취할 수 있는가? --JeffW 17:32, 2006년 2월 28일 (UTC)

로고 템플릿을 고쳐야 할 것 같아. -- 팀 스타링 02:52, 2006년 3월 1일 (UTC)

올바른 문서를 가리키면 그렇게 할 수 있을 것 같은데, 템플릿을 편집할 수 없으면 보호됨. --JeffW 14:22, 2006년 3월 1일(UTC)

나는 변화한다고 생각한다.

• • [[범주:로고 <noinclude> </noinclude> {{PAGENAME}}] to
  • [[범주:{{{{1 로고}}}}} </아니오 포함> {{PAGENAME}}]]

속임수를 쓰겠지누군가가 이것을 변경하거나 내가 변경할 수 있도록 내게 접근 권한을 줄 수 있는가? --JeffW 18:14, 2006년 3월 1일(UTC)

다른 종류의 로고를 위한 다른 템플릿을 만드는 것이 좋지 않을까? --cesarb 22:07, 2006년 3월 1일 (UTC)

그럼 로고 코드를 복사해서 새 템플릿에 붙여넣고 거기서 변경해야 해?일종의 명명 규칙이 있는 것인가, 아니면 그냥 로고2라고 불러야 하는가? --JeffW 04:13, 2006년 3월 3일(UTC)

CesarB, 실행되었지만, subcat 태그만 있는 몇 개의 로고가 resective subcat뿐만 아니라 "logos" 아래 여전히 나타난다.--Esprit15d 19:22, 2006년 3월 3일 (UTC)

어떤 거?방금 대학교 로고에 있는 로고 중 일부를 현장 확인했는데 로고에는 없는 것 같아. --JeffW 22:55, 2006년 3월 3일 (UTC)

부수적 손상 템플릿 제안

동적 IP 자동 잠금으로 인해 무고한 선의의 기여자에게 빈번한 부수적 손상이 발생하고 있는 문제를 고려할 때, 나는 관리자에게 부수적 손상 문제를 보다 쉽게 경고할 수 있는 가능한 템플릿을 조정해 왔다.기본적인 생각은 자동 잠금 장치에 걸린 무고한 구경꾼들이 관련 IP와 그들의 이름만 입력하면 문제를 해당 관리자에게 알릴 수 있다는 것이다.

제안된 템플릿 구문:

{{템플릿:부수적 피해 경고 IP=0.0.0 피해자=존 스미스}

템플릿은 다음과 같을 것이다.

친애하는 관리자님께:

IP 주소 0.0.0.0이 귀하의 서명으로 자동 잠금 설정됨.

이 주소는 다른 많은 기여자가 선의로 사용하는 동적 IP 주소이며, 이러한 사용자에게 자동 잠금 기능이 미치는 부수적 손상이 자동 잠금 동작의 보호 혜택을 능가할 수 있다는 점에 유의하십시오.

이 메시지는 위키백과에 유용한 정보를 제공할 수 있기를 원하는 존 스미스에 의해 당신에게 보내졌고 따라서 이 IP 주소의 블록을 제거하도록 요청한다.

도와줘서 고마워.존 스미스 06:36, 2006년 2월 28일 (UTC)

기본 구문 포함:

[[이미지:Stop_hand.png 왼쪽 30px] ''Dear Administrator''':IP 주소 ''{{{{IP(Sorry, 사용자가 IP를 입력하는 것을 잊었음)}}''은 귀하의 서명 하에 ''자동 잠금''으로 되어 있다.이 주소는 다른 많은 기여자가 선의로 사용하는 동적 IP 주소이며, 이러한 사용자에게 자동 잠금 기능이 미치는 부수적 손상이 자동 잠금 동작의 보호 혜택을 능가할 수 있다는 점에 유의하십시오.이 메시지는 위키피디아에 유용한 정보를 제공할 수 있기를 원하는 이 IP에서 '{{{protim a good-feith user}}'에 의해 당신에게 보내졌고, 따라서 이 IP 주소의 블록을 제거하도록 요청한다.'''''''{{{{서명 ~~}}}}

위의 예제에서 매개 변수를 IP = 0.0.0.0, 공격 대상자 = 존 스미스(John Smith)로 설정한 경우.

서명된 파라미터의 이면에 있는 아이디어는 해당 사용자가 피해분야에서 자신의 이름을 밝히지 않아도 해당 관리자에게 영향을 받는 사용자에 대한 충분한 정보를 제공하기 위해 기본적으로 ~~~로 설정된다는 것이다.템플리트 공간에 템플리트를 추가하기 전에 이 템플리트를 여기에 배치하려는 이유 중 하나는 4틸트 서명을 기본값으로 사용하는 것이 구문 위반인지 아닌지 완전히 확신할 수 없기 때문이다.샌드박스 테스트는 결론에 이르지 못했다.나는 프로그래머가 아니라 순전한 자기 방어에서 벗어나 내 기술적 자신감을 넘어 대담함에 내몰린 천박한 위키백과 기고자에 불과하다.

코멘트, 제안, 그리고 "잘못된 방법으로 하고 있다" 경고는 Vremya 07:28, 2006년 2월 28일 (UTC)에 매우 감사할 것이다.

나는 대부분의 기고자들이 이 템플릿을 사용하는 것을 아는 것을 볼 수 없다.해볼만 하겠지...Superm401 - Talk 00:44, 2006년 3월 1일(UTC)

이 아이디어는 자동 잠금 사용자가 편집을 시도할 때 리디렉션되는 페이지에 대한 간단한 방법 안내서와 함께 이 템플릿을 추가하는 것이다.현재 이 페이지에는 관련 관리자에게 연락하는 방법에 대한 비교적 모호한 지침이 수록되어 있는데, 그 주된 결과는 충돌로 피해를 입은 사용자가 "왜 나를 공공 기물 파손으로 고발하는 겁니까?"라고 행정관은 말했다.나는 이 템플릿이 (1) 무고한 자동 잠금 사용자들을 어떻게 해야 할지 모르는 상태로 방치하지 않는 것과 (2) 관리자가 이러한 사용자들의 닳은 템퍼의 공격을 받지 못하게 하는 이중적인 목적을 달성하기를 바란다.

그런 말을 했더라면, 나는 여전히 어떤 기술적인 입력, 특히 네 가지 테일의 지름길을 템플릿에 통합하는 지혜나 어리석음에 대한 조언(그리고 그것이 어리석다면 어떻게 그것을 올바르게 할 것인가)에 대해 감사할 것이다.내가 말했듯이, 샌드박스 테스트는 브레미야 09:43, 2006년 3월 1일 (UTC)을 제대로 해결하지 못했다.

기술적인 문제라면 도와줄 수 없고, 관리자로서 차단을 많이 하지는 않지만, 보다 명확한 지시와 닳아 빠진 성질을 재조정하는 방법은 아주 좋은 일인 것 같다.가라고 말하고 싶다.제시W, 저글링 관리인 00:43, 2006년 3월 3일 (UTC)

새로운 마법의 단어?

이것은 소프트웨어 기능 요청에 가깝지만, 버질라에서 제출하기 전에 먼저 여기에 의견을 묻고 싶었다.

나는 다음과 같은 새로운 마법 단어들이 유용하다는 것을 알게 될 것이다.

• 다음 달: 다음 달 번호를 표시하려면
• 다음 달 이름: 다음 달 이름을 표시하려면
• 다음 달: 다음 달 유효 연도를 표시하기 위해
• 다음 주: 다음 주 수
• 다음 주:다음주에 속하는 해
• 다음 날: 내일의 날짜를 표시하기 위해
• NEXTDAYNAME: 내일의 평일 이름을 표시하려면
• NEXTDAYWEK: 내일에 속하는 주 번호를 표시하기 위해
• 다음 날 월: 내일의 달을 표시하기 위해
• 다음 날 월 이름: 내일 월 이름
• 다음 날:내일 날짜에 속하는 연도

이 마법의 단어들은 시험에 도움이 될 수 있다.예를 들어, 메인 페이지처럼 매일 바뀌는 페이지에서는, 내일의 메인 페이지가 어떤 모습일지 자동적으로 보여주는 테스트 버전을 만드는 것이 가능할 것이다.마찬가지로, 월간으로 변경되는 페이지들은 이것을 사용하여 다음 달의 내용을 미리 볼 수 있다.이것은 변환된 페이지의 형식이 잘 보이는지 보기 위해 미래의 내용을 미리 보는 데 매우 유용할 수 있다.(내일 포털 버전을 항상 보여주는 테스트 페이지를 갖고 싶다.독일도 그래야 잘 보이게 할 수 있다.)나는 몇몇 다른 페이지들도 마법의 단어를 통해 만들어진 "내일" (또는 "어제") 링크로부터 이익을 얻을 수 있을 것이라고 확신한다.이것이 다른 누군가에게 유용하게 들리는가? 아니면 이런 새로운 마법의 단어를 갖지 않는 좋은 이유가 있는가?쿠스마 (討討) 04:21, 2006년 2월 27일 (UTC)

너는 이미 템플릿으로 할 수 있어.소스(및 템플릿 포함 체인 위로 상승)에서 fr:위키백과:Le Bistro 또는 범주 fr:Catégori의 내용:모델레 석회화 근친 데이트._R_ 18:33, 2006년 3월 2일 (UTC)

나는 그것이 여러 층의 템플릿을 사용하여 가능하다는 것을 알고 있었지만, 이것을 구현하기 위한 다소 진부한 방법인 것 같다.이제 이런 일에 메타메타템플릿을 사용할 수 있을까?쿠스마 (討論) 21:00, 2006년 3월 3일 (UTC)

이전 결과 가져오기 검색

이것이 알려진 문제인지 아닌지는 확실치 않아, 버질라에서 아무것도 볼 수 없었다.어쨌든 2005년 12월 10일에 나는 Zeland를 찾아다녔고 (뉴질랜드에서와 같은 뉴질랜드의 일반적인 오보) 그들 대부분을 고쳤다.그러나 내가 지금 이렇게 세상을 검색할 때 그것은 여전히 단어가 삭제된 페이지를 보여준다. 나는 검색 데이터베이스가 업데이트되지 않는 것에 약간의 문제가 있다고 추측할 수 있다.이것이 알려진 버그인가? - SimonLyall 10:27, 2006년 2월 23일(UTC)

검색 데이터베이스는 주기적으로 업데이트된다.아마 아직 업데이트되지 않았을 겁니다. --cesarb 13:56, 2006년 2월 23일 (UTC)

긴 시간인 것 같다. 또한 내가 1월초부터 사고광산을 검색하면 많은 결과가 나온다. - SimonLyall 01:05, 2006년 2월 25일 (UTC)

며칠 전에 데이터베이스를 다시 만든 것 같군나는 그것이 규칙적으로 일어나는 한(아마 매주?큰 문제는 아니야. - 사이먼리올 23:02, 2006년 3월 3일 (UTC)

감시 목록에서 이전 항목 보기

한 달 이상 된 내 워치리스트의 항목을 볼 수 있는 방법은 없을까?예전에는 다 볼 수 있었는데 지금은 어떤 옵션을 선택해도 한 달을 넘길 수 없다.나는 URL을 해킹해 보았지만 그것은 아무런 차이가 없다.CJrother 23:42, 2006년 3월 3일 (UTC)

그것은 현재 불가능하다; 감시 목록은 지난 30일 정도만이 포함된 최근 변경사항 데이터베이스에서 뽑았다. --Briion 00:38, 2006년 3월 4일 (UTC)

위키백과용 플러그인을 작성하려면

안녕, 모두들,

우리는 웹 매핑 애플리케이션을 개발했다. 그리고 그것을 위키피디아와 통합하기를 원한다.우리의 매핑 애플리케이션은 MapServer,Php/Mapscript 를 스크립팅 언어로, MySql을 데이터베이스로 사용한다.우리의 애플리케이션은 우리가 제공한 이미지에서 사용자 클릭을 허용한다.그리고 점들은 플롯되어 있다.우리는 이를 위해 Php 파일을 개발했다.위키백과를 위한 플러그인을 만드는 방법을 우리에게 말해줄 수 있는 사람이 있을까?

무니라 도와줘서 정말 고마워

위키피디아를 운영하는 소프트웨어인 미디어위키(Mediawiki)를 말하는 것인가, 아니면 위키피디아 웹사이트 자체를 말하는 것인가?Mediawiki인 경우 해당 문서에 대한 링크를 보려면 해당 문서를 참조하십시오.위키피디아 웹사이트라면 왜 우리가 당신의 소프트웨어를 실행해야 하는지에 대해 극단적인 논쟁을 제시해야 할 것이다. -- Finlay McWalter Talk 21:56, 2006년 3월 3일 (UTC)

안녕, 우리는 우리의 어플리케이션을 MediaWiki와 통합할 작정이야. 어떤 문서 링크를 말하는 거니?고마워 무니라

참고 항목 m:MediaWiki 확장 -- Finlay McWalter Talk 12:53, 2006년 3월 4일(UTC)

새 템플릿은 어때?

누군가 카피비오 제작을 시인하는 것은 분명히 훨씬 더 나쁜 일이다.그러므로 나는 왜 그것에 대한 새로운 템플릿을 가지고 있지 않을까 하는 생각을 했다.

여기 있다:템플릿:인정카피비오

지금 바로 보려면:

{{복사viocore}}

그래, 어떻게 생각해?BTW, 좀 더 조정해서 좀 더 독특하게 만들고 링크도 처리해 줄래?고마워. --Shultz III 09:27, 2006년 2월 26일 (UTC)

나는 이것이 반드시 완전히 새로운 템플릿을 가질 필요는 없다고 생각한다 - 카피비오라는 작가의 주장을 제외하고는 대부분의 것이 똑같다.그것은 과정이나 그 어떤 것에도 영향을 주지 않는다.카피비오 목록 페이지의 이유를 참고하면 될 것 같고, 그것만으로도 충분하다고 생각한다.2006년 2월 26일 데코 22:38(UTC)

불필요하게 복잡함.가장 나쁜 부분은 위키피디아와의 연결이다.인정_Copyvios, 나는 당신이 우리가 창조하기를 제안한다고 생각한다; 그것은 단지 저작권 문제를 나누고 그들을 추적하고 처리하는 것을 더 어렵게 만드는 역할을 할 것이다.저자가 카피비오라고 말할 때 빠른 기준을 만드는 것을 볼 수 있었지만, 카피비오 조사 과정을 통해 보내려면 우리는 기존의 시스템을 단순하게 사용하고 완전히 중복되는 두 번째 시스템을 만들지 말아야 한다. --조금 08:05, 2006년 3월 4일 (UTC)

새 바로 가기 키

나는 여기서 관리자[롤백] 버튼에 대한 새로운 바로 가기 키를 제안했는데, 어떤 생각이라도 고마워할 것이다.기술적으로 쇼컷을 만드는 것이 가능한지 알아보려고 여기에 글을 올렸을 뿐인데, 예를 들어 임의의 기사는 항상 정해진 링크(특별한:무작위) 그러나 롤백 버튼은 그렇지 않다 - 문자, 숫자, 토큰 등이 포함되어 있다.생각?— FireFox • T • 20:27, 2006년 3월 5일

카테고리 목록

Wikipedia_talk를 참조하십시오.위키프로젝트_The_Beatles/Item_Classification#Building_From_the_category_dump 형식은 없지만 알파 순서로 되어 있는 카테고리의 기사 목록을 생성하는 더 쉬운 방법이 있는가?범주에서 어떻게 하는지 알 수 있어.sql 덤프 하지만 그러기 전에, 물어봐야겠다고 생각했어...차라리 바퀴를 재발명하지 않고 게으름뱅이 등...더 큰 문제, 다른 위키백과 주체가 기사 분류를 하고 있으며 분류표를 작성할 수 있는 도구가 이미 있는가?(우리는 이미 손으로 커플을 만들었다)비틀즈는 많은 카테고리에 많은 기사를 가지고 있다.++Lar: t/c 19:04, 2006년 3월 5일(UTC)

이미지에서 이상한 배경

{{Sockpuppet}}}에 사용된 이미지는 이상한 흰색 배경을 가지고 있다.imagemagick-interface에 버그가 있는 것 같다. 2006년 3월 5일 (UTC)

"이상하다"는 말은 "투명하지 않다"는 뜻인가?포토샵으로 같은 이미지를 보면 투명한 이미지가 아닌 흰색 배경도 있다. --핀레이 맥왈터토크 13:33, 2006년 3월 5일 (UTC)

이미지를 보는 경우:Nuvola 앱 kdmconfig.png, 이미지가 투명 배경인 것을 알 수 있다. 14:13, 2006년 3월 5일(UTC)

공유지에 있는 페이지를 보면, 누군가가 (요약 무손실 압축 편집으로) 변경한 어제까지 투명한 배경을 가지고 있었다.지금은 탄탄한 흰색 바탕을 가지고 있다. -- Finlay McWalterTalk 14:22, 2006년 3월 5일 (UTC)

커먼즈에서 찾은 이미지를 보니 배경이 투명하다. 2006년 3월 5일 14시 32분(UTC)

파이어폭스는 오래된 이미지를 투명한 이미지로, 새 이미지는 흰색 이미지로 보여준다.포토샵도 마찬가지다.페인트 숍 프로도 마찬가지다.잉크스케이프도 마찬가지다.오페라도 마찬가지 입니다. -- Finlay McWalterTalk 15:05, 2006년 3월 5일 (UTC)

새로 업로드한 이미지를 되돌렸고 모든 게 잘됐다.그 이미지는 24비트 알파에서 8비트 팔레트로 변환된 것 같다.그곳에서 사용되는 하얀 배경 때문에 공유지에서는 투명하지 않다는 것을 알 수 없다(피부를 다른 것으로 바꾸면 아마 더 명백해질 것이다).업로더가 어떤 종류의 봇을 실행하거나 다수의 이미지를 대량으로 다운로드하여 압축한 후 다시 업로드하고 있었던 것 같다.또한 그는 Special을 보면 이 문제를 알고 있는 것 같다.Commons의 로그/업로드에 따르면 그가 업로드한 많은 것들을 되돌리고 있다는 것을 보여준다.(사용자 프랑스어 위키백과 대화 페이지에도 노트가 있다.)—Locke Cole • t • c 15:17, 2006년 3월 5일(UTC)

내가 생각한 것은 이미지를 다운받아 김프로 열어보니 배경이 투명하다는 것을 알 수 있었다. 2006년 3월 5일 15시 24분(UTC)

이상하네..Finlay처럼 포토샵에서 이미지를 열었는데 흰색 바탕이 있다고 적혀있어.그것은 또한 전혀 디더링되지 않았다.하지만 내가 되돌린 버전은 투명하다.김프에서 열어본 파일의 크기가 얼마나 되십니까?—Locke Cole • t • c 16:53, 2006년 3월 5일(UTC)

[0:0][azatoth@azabox img]$ file Nuvola_apps_kdmconfig.png Nuvola_apps_kdmconfig.png: PNG image data, 128 x 128, 8-bit/color RGBA, non-interlaced [0:0][azatoth@azabox img]$ ll Nuvola_apps_kdmconfig.png -rw-r--r-- 1 azatoth azatoth 20195 2005-09-08 18:47 Nuvola_apps_kdmconfig.png

_→AzaToth 2006년 3월 5일 17:05 (UTC)

이상하네, 24비트 알파블링 버전(20,195바이트)을 얻었군.공통점을 살펴보십시오.이미지:Nuvola apps kdmconfig.png, {{Sockpuppet}}에서 흰색 배경을 유발하고 있던 이미지가 내 반전 직전 이미지다.(파손된 파일에 대한 직접 링크 입니다.)화이트 백그라운드 이미지의 파일 크기는 5110바이트 입니다.—Locke Cole • t • c 17:32, 2006년 3월 5일(UTC)

기본 키

누가 위키 데이터베이스 구조에 대한 정보를 알려주시겠습니까?기사가 증분 1차 키와 연관되어 있는 것처럼 보이며, 대량 추가 및 편집으로 키의 인덱스 트리가 빠르게 균형을 잃고 점점 더 긴 조회 시간을 초래하게 되는 것이 염려된다(db 관리자가 인덱스를 재구성할 때까지).하지만 E/R 다이어그램과 주요 유형을 보지 않고는 확신할 수 없다.Rklawton 07:26, 2006년 3월 5일 (UTC)

메타에 있는 MediaWiki 아키텍처에 MediaWiki 데이터베이스 아키텍처에 대한 약간의 설명서가 있지만, 나는 당신이 찾고 있는 것은 데이터베이스 레이아웃 테이블, 그리고 더 중요한 것은 주석이 달린 테이블 데이터베이스라고 믿는다.Titoxd^{(?!? - help us)} 07:31, 2006년 3월 5일 (UTC)

데이터베이스의 주요 지수는 자동 균형 조정으로 되어 있지 않은가? --cesarb 20:18, 2006년 3월 5일 (UTC)

순차적 키로 자동 밸런싱하는 것은 무료가 아니다.I/O와 CPU 사이클이 많이 필요하다.충돌 회피 기능이 있는 무작위 키는 그 무작위성으로 인해 균형 잡힌 나무를 만들어 낸다.Rklawton 23:17, 2006년 3월 5일 (UTC)

CPU와 I/O를 많이 사용하지 않는다.어떤 삽입 오더에도 잘 작동하도록 설계됐다.반면에 임의 키는 훨씬 더 많은 CPU와 I/O를 사용할 것이다(키스페이스가 없어질 때까지 순차적 키로는 불가능한 충돌을 확인해야 하기 때문이다).--cesarb 23:32, 2006년 3월 5일 (UTC)

내가 편집한 것은 기사의 임의 부분을 엉망으로 만들고 있다.

내가 홀로코스트 기사를 편집하거나 되돌릴 때, 그것은 내가 하지 않은 많은 터무니없는 편집들을 남긴다.이것은 2월 26일 뿐만 아니라 몇 분 전에 [누군가가 그것을 고칠 수 없으니 제발 되돌려야 한다].또한 2월 14일자 Chabad.org 기사에 이와 같은 내용이 실렸다. (그 기사는 6일에 나 자신의 편집도 하지 않았다.)Shlomke 03:36, 2006년 3월 5일 (UTC)

컴퓨터의 일부 소프트웨어에서 "히틀러" 또는 "Nazi"와 같이 불쾌하게 여겨질 수 있는 단어를 삭제하는 것으로 나타날 수 있다(이러한 단어를 후속 편집에 의해 삭제하는 경우, 이 단어는 제2차 세계 대전 직전에 독일과 관련하여 일반적으로 사용되는 두 개의 단어임).일부 Net Boomin 유형 프로그램(Norton Internet Security 일부 버전에는 이러한 기능이 있음)을 실행 중인지 아니면 이러한 소프트웨어가 설치되어 있을 수 있는 학교 또는 도서관 컴퓨터에 있는지 확인하십시오.내 생각에 유일한 해결책은 그 소프트웨어로 하여금 Wikipedia.org 도메인의 검열을 해제하게 하거나 편집에 다른 컴퓨터를 사용하는 것이다.이 문제가 해결될 때까지 기사를 더 편집하지 말고 여기서 계속 편집하여 문제를 해결하십시오.-gadfium 03:54, 2006년 3월 5일(UTC)

응, 우리는 컴퓨터로 사이버시터를 운영하고 있어.이것이 홀로코스트 기사에 도움이 된다. 하지만 나는 그것이 왜 Chabad.org 기사를 망쳤는지 모르겠다.다른 사람이 있는 더블 편집도 가능했던가?어쨌든, 문제가 해결되고 있는지 알아보기 위해 The Holocost 기사의 시험 편집을 할 수 있는 방법이 있을까?Shlomke 04:16, 2006년 3월 5일(UTC)

Chabad.org에서 당신은 역사를 보다가 실수로 이전 버전의 기사를 편집했을지도 모른다.그것은 꽤 쉽게 일어날 수 있다.

홀로코스트를 실험하는 가장 쉬운 방법은 기사의 위키텍스트를 복사하여 사용자 공간의 하위 페이지에 붙여 넣는 것이다. 예: 사용자:셸롬크/샌드박스.그런 다음 원하는 만큼, 이성적으로 편집할 수 있다.

사이버시터는 잘 모르지만, 만약 당신이 컴퓨터의 소유자(예: 부모)이고 프로그램의 마스터 암호를 가지고 있다면, 당신은 그것을 무시하도록 구성할 수 있을 것이다.wikipedia.org, 또는 적어도 위키피디아를 편집하는 동안 당신은 그것을 끌 수 있어야 한다.만약 당신이 부모가 사이버시터를 설치한 아이라면, 당신은 그것을 재구성하도록 설득할 수 있을지도 모르지만, 그들은 또한 당신이 모든 위키피디아에 완전히 접근하는 것을 원하지 않을지도 모른다. 그리고 그것은 우리가 그들의 결정에 간섭할 수 있는 장소가 아니다.-가드피움 04:50, 2006년 3월 5일 (UTC)

고마워, Shlomke 05:07, 2006년 3월 5일 (UTC)

템플릿 문제

한국어 위키백과 템플릿을 편집하려고 한다(ko:세 개의 매개 변수를 사용하는 템플릿:llang)이며, 이 중 세 번째 매개 변수는 선택 사항이다.템플릿은 어떤 것의 이름이 다른 언어로 표시되는 것이다.매개변수 1은 언어를 지정하고, 매개변수 2는 해당 언어로 이름을 지정한다.선택적 매개 변수 3은 그 이름이 한글로 어떻게 쓰여지는지를 명시한다.현재 템플릿의 작동 부분은 다음과 같다.

<작다>{llang/lighore imor1}:{1}:</작다><스팬 랭="{{1}}" xml:lang="{1}}"{{{1}}}}}{{2}}}<{{{3}}}}

그래서 "({{llang En En En En English 잉리시}}}}})"를 입력하면, 나는 그 결과를 얻게 된다.

(영어: English잉글리시)

'영어'와 ' '글글시' 사이의 공백 없이그러나 템플릿에 공백을 삽입하려고 하면 다음과 같다.

<작음>{{llang/lighore imor1}:{1}: </작음><스팬 랭="{{1}}" xml: xml="{{1}}"{{1}}}}{{{3}}}}</작음)

그런 다음 파라미터가 2개밖에 없는 "({{llang En En English})"를 입력하면 문제가 생긴다.

(영문: 영어 )

내가 제거할 수 없는 공백 끝에 ('영어'와 '닫는 괄호 사이')를 두고.세 개의 매개변수를 입력할 때 공백이 존재하도록 수정하는 방법을 알고 있는 사람이 있는가? 그러나 처음 두 개의 매개변수만 입력했을 때 공백이 존재하도록 수정하는 방법을 아는 사람이 있는가?정말 감사할 겁니다. --빙하 01:16, 2006년 3월 5일 (UTC)

신경 쓰지 마, 이 문제는 한국 위키백과 사용자에 의해 고쳐졌어.해결책은 다음과 같은 것이었다.

<작음>{{llang/언ergoley {{1}}}:</작음><스팬 랭="{{1}:{1}}" xml:"="{{1}}"{{{1}}}}{{{{3}}}}}}{{3}}}}}}}{{{3}}}}}}}}}}}/작음}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

어쨌든 고마워! --빙하기 01:19, 2006년 3월 5일 (UTC)

사진 문제

실례지만, 프랑스어 위키백과 사용자 입니다.

로신에 관한 프랑스 기사에서는 사진을 찾고 있는데, 로진카케.jpg(보여, 바로 저기 :)가 PD 자격증 문제를 가지고 있는 것을 보았다.오류인가, 내가 어떻게 하면 되는가, 그것을 커먼스에 올릴 수 있을까...?

내 메시지를 읽어줘서 정말 고맙고, 가능하다면 내 토론 페이지에서 대답해줘, 더 실용적일 거야.

다시 한번 감사드리며, 82.125.185.57 21:12, 2006년 3월 4일(UTC) 일명 피에르 비구에(Pierre Vigué)로 불린다.

이 일은 이미 해결되었다.마케미 06:19, 2006년 3월 5일 (UTC)

이메일 확인이 작동하지 않음

Special(특수)을 클릭한 경우:확인 메일과 이메일을 받았는데, 이메일에 있는 링크를 클릭하면 위키 페이지가 "잘못된 확인 코드"로 나타난다.암호가 만료되었을지도 몰라."나는 어제와 오늘 이것을 몇 번 시도해 보았다.어떡하지? --Bruce1ee 08:04, 2006년 3월 3일(UTC)

다시 해보시겠습니까?방금 내 위키피디아와 커먼스 이메일 주소를 확인했는데, 잘 작동했어.~MDD4696 02:28, 2006년 3월 4일(UTC)

그것은 나에게 일어났다; 내가 다시 확인했을 때 나는 모든 코드가 메일에 나타나는 하이퍼링크에 포함되어 있지 않다는 것을 깨달았다.마지막 열 통 정도의 편지가 메시지에 나타났지만 링크의 일부가 아니어서 링크를 클릭하면 잘못된 주소로 보내졌다.메시지에서 전체 주소를 복사하여 브라우저의 주소 표시줄인 Palmiro Talk 20:05, 2006년 3월 4일(UTC)에 붙여넣으십시오.

어떤 메일 프로그램을 사용하시는지 알려주시겠습니까?그리고 가능하다면, 내가 확인할 수 있도록 brion에 우편물 사본을 brion으로 보내 주시겠습니까? (한번 사용한 코드는 다시 사용할 수 없다.) --Briion 00:31, 2006년 3월 5일 (UTC)

효과가 있었다.Palmiro가 조언해줘서 고마워 – 모든 코드가 하이퍼링크에 포함되지는 않았다.BTW 내가 여기서 사용하고 있는 메일 프로그램은 IE6이다(웹메일 계정이다). --Bruce1ee 12:46, 2006년 3월 5일 (UTC)

이미지:US 로케이터 공백.svg

''이미지:위키백과에 사용된 US Locator Blank.svg'' 지도 이미지:위키프로젝트 보호지역 기사는 비어 있다.아치스 국립공원 등의 기사를 클릭하면 로케이터 지도가 흰색이고 붉은 로케이터 점이 눈에 띈다.이거 벌레야?만약 그렇다면, 개발자들에게 어떻게 연락할 수 있는지 누군가 나에게 지시해 줄 수 있을까?--MONGO 10:48, 2006년 2월 28일 (UTC)

아마도 최근의 librsvg 업그레이드와 관련이 있을 것이다.이미지를 재저장하고 다시 업로드했는데, 이제 괜찮아진 것 같아.—Ilmari Karonen(토크) 11:28, 2006년 2월 28일 (UTC)

매우 신속한 응답에 감사한다...이제 다시 작동하고 있다...그 노력을 인정하라!--MONGO 11:31, 2006년 2월 28일 (UTC)

몇 시간 동안 Adobe Illustrator에서 내보낸 SVG는 펑키한 비호환성으로 인해 잘못 렌더링(공백)되고 있었다.고정되어 있으므로 전체 재생이 완료될 때까지 이미지 페이지에서 action=purge를 사용하여 수동으로 플러시할 수 있어야 한다.(새 버전을 실제로 보려면 이미지를 강제로 다시 로드해야 할 수 있음)만일 그것이 하원에서 주최된다면 당신은 하원에서 숙청을 해야 할지도 모른다. --Briion 01:55, 2006년 3월 1일 (UTC)

그냥 궁금해서 그러는데, 어도비 일러스트레이터의 문제였나?만약 그렇다면, 이것이 문서화된 곳이 있는가?고마워요.=) —Locke Cole • t • c 02:10, 2006년 3월 1일 (UTC)

아니, libxml2의 버그나 제한으로 보인다.일러스트레이터의 내보내기(적어도 일부 버전에서는)는 인라인 DTD 정의를 사용하여 SVG 및 XLINK 네임스페이스 URL에 대해 명명된 엔티티를 생성하는데, 이는 분명히 2.6.22 이전 libxml2에서는 제대로 작동하지 않는다.만약 그들이 바로 전에 렌더링했다면, 그것은 오래된 버전의 librsvg가 XML 네임스페이스에 별로 신경을 쓰지 않았기 때문일 것이다...또는 다른 것. :) --Briion 07:25, 2006년 3월 1일 (UTC)

불행히도 새로운 렌더링은 다르게 보인다 - 0px 테두리가 더 이상 이미지에서 나타나지 않는다:주간고속도로 제55호선이미지:Interstate 99.svg는 이전의 모습을 보여준다. --SPUI(talk - sorted stub template 사용 안 함!) 23:16, 2006년 3월 4일(UTC)

이것을 버질라로 철해 주시겠습니까?조금 있다가 쿡쿡 찌르겠다... --Briion 00:34, 2006년 3월 5일 (UTC)

[1] - 고마워. --SPUI (대화 - 정렬된 스텁 템플릿을 사용하지 마십시오!) 00:49, 2006년 3월 5일 (UTC)

나는 내 설명 페이지에 도움이 필요하다.

난 방금 이 페이지를 만들었어:

http://en.wikipedia.org/wiki/AICE_(disambiguation)

왜냐하면 나는 AICE라는 조직에 관련된 페이지를 만들고 있지만, 여기에 이미 다른 AICE라는 조직이 있다.AICE를 찾는 사람들이 난장판으로 바로 갈 수 있도록 하려면 어떻게 해야 할까.페이지?

만약 두 AACE의 중요도가 거의 같다면, "AICE (콘텍스트 A)"와 "AICE (콘텍스트 B)"를 모호하게 하는 기사가 있어야 한다.이것은 잘 계획된 일련의 기사 이동으로 이루어질 수 있다.

• 전류 "AICE" ->"AICE(콘텍스트 A)"(컨텍스트 a가 설명되는 경우)
• 새로운 기사를 쓰거나, "AICE (컨텍스트 B)"라는 이름을 붙이거나, 샌드박스에서 그곳으로 옮기거나, 짧은 시간 안에 이 모든 동작을 수행하는 것이 가장 좋으며, 그렇지 않을 경우 어떤 일이 일어나는지 몇 가지 문제를 확인하십시오.)
• 위의 두 가지를 모두 가리키도록 "AICE(해제)" 업데이트
• "AICE (해체) -> "AICE"를 이동

그러면 AICE에 입학하는 사람들은 디스컴비그 페이지를 받게 될 것이다.하지만 현재 AIC를 보면..실제로 WP가 아니라고 가정할 때:AFD 사료, 그것이 더 중요하거나 똑같이 중요한 조직이라고 상상하기는 어렵다.그 경우, NEW 기사, (더 중요한 조직) sholud는 현재의 AICE로 다시 돌아온다. ("AICE (경쟁력 있는 식사)"로 이름을 바꾼 후) ...그게 도움이 되길 바래.++Lar: t/c 22:47, 2006년 3월 6일(UTC)

희생양

나는 이것이 기술적인 문제임에 틀림없다고 생각한다.사람들은 내가 만지지 않은 것으로 알고 있는 페이지들에 "반달리즘"을 비난하는 메시지를 내 상자에 남겼다. (나는 불명예스러운 신참일 수도 있지만, 그것을 알고, 나는 정치적 논의에서 멀어지려고 노력한다!)아무도 내 컴퓨터를 사용하지 않고, 최근에는 집에 침입한 사람도 없다.

그러니까 기술적인 문제든 너희들이 다 사악한 거야.

-오늘 밤에만 메세지가 남길 수 있다는 것을 알게 된 믿을 수 없을 정도로 과대평가된 뉴비.아니면 (스팸 이외의) 흥미 있는 말을 할 수도 있을 것이다.

시스템이 언제 나에게 성가신 '새 비밀번호'를 이메일로 보낼지 안다면 나는 로그인했을 것이다.벌써 몇 분이나 지났어.— 207.200.116.203 (대화 • 기여) 12:30, 2006년 3월 6일 이전에 추가된 서명되지 않은 의견

내가 마지막으로 확인한 바로는, 우리가 모두 악한 것은 아니어서 아마도 기술적인 문제나 의사소통의 오류일 것이다.만약 그들이 당신의 IP의 토크 페이지(우편함이 아닌 여기서 우리는 그것을 그렇게 부른다)에 메시지를 남기고 있다면, 그것은 당신의 IP 주소가 다른 사용자와 공유되기 때문일 것이다.그게 도움이 되길...++Lar: t/c 14:30, 2006년 3월 6일(UTC)

당신의 IP 주소는 AOL을 가리킨다.이것은 AOL의 알려진 문제점이다: 사용자의 IP 주소는 모든 편집에 따라 변경될 수 있으며, 다른 사람에게 의미하는 반달리즘 경고를 받을 뿐만 아니라 다른 사람을 위한 블록에 의해 우발적으로 차단되는 경우도 꽤 흔하다.일부 사람들은 AOL의 자체 브라우저 대신 다른 브라우저(예: Mozilla Firefox)를 사용하는 것이 문제의 일부를 방지한다고 말하지만, 이것은 확인되지 않았다.올바른 기술 수정은 AOL의 서버 소프트웨어 변경에 따라 달라진다. --cesarb 14:29, 2006년 3월 6일(UTC)

표시된 온도 예제에 대한 범주 억제

사용자 대화를 방지하는 방법:Danieljackson이 Category와 같은 정리 카테고리에 나타나지 않음:정리해야 할 디스암호화 페이지 정리?멜초이르 21:34, 2006년 3월 6일 (UTC)

모든 템플릿을 "하위"한 다음 범주 앞에 있는 콜론을 사용할 수 있는지 확인하십시오.마케미 22:19, 2006년 3월 6일 (UTC)

할 수 있었지만 마법처럼 비침습적인 해결책을 기대했었죠'노인클루트' 같은 거?멜초이르 22:54, 2006년 3월 6일 (UTC)

글쎄, BL 라커테가 나보다 덜 게으른 것 같아.고마워!멜초이르 01:15, 2006년 3월 7일 (UTC)

이 문제에 대한 요청이 bugzilla에 게시되었다.(bugzilla:1967 참조).아마도 나의 서투른 영어실력이 잊혀지라는 요청을 했을 것이다. : (borgx 07:20, 2006년 3월 7일 (UTC)

헝가리 응용예술대학에 이상한 일이 일어났다.

위의 대학에 관한 기사가 있었다.5월 1일 대학의 명칭이 모홀리 나기 예술 디자인 대학으로 바뀌었다.사용자가 와서 편집하기 전에 원본 페이지를 옮기는 대신에 새 이름으로 페이지의 내용을 복사하고 몇 가지 편집을 했다("이동" 버튼을 사용했어야 했기 때문에 매우 나빴다).그가 만든 새로운 내용을 삽입할 수 있는 새 이름으로 이전 페이지를 옮겨 되돌리고 싶었지만 페이지를 옮기자 모든 역사가 사라져 버렸어![2] 원본 페이지의 역사를 살리기 위해 새로운 이름으로 적절한 이동을 강화하고 싶었는데, 그 대신 잃어버렸다.왜?좀 도와주시겠습니까?

내 말은:

1. 원본 페이지(헝가리 응용예술대학)의 역사는 지워지지 않고 복원해야 한다.
2. 모홀리-나기 예술 디자인 대학 페이지의 현재 업데이트된 내용은 이전 페이지로 복사해야 한다.
3. 헝가리의 응용 예술 대학(업데이트된 콘텐츠 포함) 페이지는 '모홀리-나기 예술 디자인 대학'이라는 이름으로 적절히 옮겨야 한다.

따라서 결과는 본 페이지의 현재(업데이트된) 내용과 헝가리 응용예술대학 페이지의 전체 이력이 구현된 변화를 반영하여 "Moholy-Nagy 예술 디자인 대학"이라는 이름의 페이지가 되어야 한다.그것은 아마도 후기 페이지와 관련된 다른 모든 페이지로부터의 리디렉션을 포함할 수 있다.나는 이 일을 하기 위해서는 관리자가 필요하다고 생각한다.

미리 정말 고마워!

아담78 21:13, 2006년 3월 6일 (UTC)

아마도 위키피디아에 대해 도움을 요청하고 싶을 것 같다.요청됨_moves.위에 쓴 글씨가 좋은 것 같아.요청된 이동은 매우 간결한 형식을 사용하므로, 기록 내용은 올바른 이력을 가진 기사의 토크 페이지에 배치하고 이동 요청에서 참조해야 할 것이다.내가 행정관이 아니어서 틀릴 수도 있지만 그게 내 생각이야.행운과 행복한 편집! ++Lar: t/c 22:41, 2006년 3월 6일(UTC)

고마워!네가 제안한 대로 했어.유일한 문제는 현재 올바른 역사를 가진 페이지가 없다는 것이다.그것이 내가 가장 놀랍게도 잃어버린 역사다.어쨌든 '요청된 움직임'에 있는 사람들이 도움을 줄 수 있기를 바란다.Adam78 00:26, 2006년 3월 7일(UTC)

내 제안은 누락된 내역에 대해 찾을 수 있는 모든 리디렉션을 확인해봐.이거야? http://en.wikipedia.org/w/index.php?title=Moholy-Nagy_University_of_Art_and_Design_%28Budapest%29&action=history?사용자(또는 관리 도구 대신 일반 이동 페이지를 사용하는 사용자)가 페이지를 이동할 때마다 ***모든 페이지****** 뒤에 남겨진 리디렉션에 기록...WP는 리디렉션을 남기지 않고 페이지를 이동할 수 없도록 한다.이전에 관리자가 조치를 취하지 않은 경우, 해당 내역을 찾을 수 있다면 SOMP 페이지에 기록되어 있을 것이다.행운을 빈다...나는 당신이 그것을 찾을 때까지 어떤 관리자도 당신을 위해 어떤 행동도 하지 않도록 하는 것을 지지한다.(하지만 그 모든 것을 알맹이로 받아들이면, 나는 혼란스러울지도 모른다!)도움이 되길 바라며, 행복한 편집! ++Lar: t/c 01:36, 2006년 3월 7일(UTC)

해명: 당신이 이사한 곳은 당신이 이사한 곳이 아니라 역사를 얻는다.왼쪽 리디렉션은 이동했음을 나타내는 단일 편집을 갖는다. -Splash^talk 01:41, 2006년 3월 7일(UTC)

브레인 체크, 고마워 스플래시!하지만 너, 내가 이리저리 찾아다녔는데 잘 엉켜 있어.나는 내가 말한 것을 고수한다. 행정관이 관여하지 않는 한, 어떤 기사는 역사를 가지고 있다.아마도 역사 병합이 필요할 것이다.모든 리디렉션과 좌표를 찾아서 링크들을 어디선가...++Lar: t/c 02:00, 2006년 3월 7일(UTC)

내가 무심코 한 것에 대해 고맙고 미안하다.아담78 02:35, 2006년 3월 7일 (UTC)

오늘 무슨 일이야?

나는 KSTW와 비슷한 문제를 가지고 있었기 때문에("이 기사는 존재하지 않는다, 정직한!"), 이것은 위의 것과 관련이 있다.IE 6을 사용하면서 오늘 "접속하려는 페이지에 문제가 있어 표시할 수 없다"는 내용의 "HTTP 500 내부 서버 오류"가 많이 접수되고 있다.나는 주로 페이지를 편집하려고 할 때 이것을 얻지만, 위키피디아 페이지를 잠깐 동안 방문하려고 할 때 이런 일이 일어나기도 했다.무슨 일이야?Morgan Wick 00:02, 2006년 3월 6일(UTC)

기술적 문제. --cesarb 00:17, 2006년 3월 6일(UTC)

내가 롤랑 프레이제 기사를 열려고 하면, 그것은 존재하지 않는 것처럼 보이지만, 역사는 그것이 여전히 존재한다는 것을 보여준다.이것이 위의 문제와 관련이 있는지 없는지 모르겠다.스페이스포타토 02:08, 2006년 3월 7일 (UTC)

?action=purge --Briion 08:11, 2006년 3월 7일(UTC)

유형 설명을 오른쪽에서 왼쪽으로 리디렉션

이 페이지: [3], 리디렉션 설명이 표시되지 않음.그러나 해당 디프에는 [4]가 표시된다.이게 버그야, 특징이야?쿠스마 (討論) 20:59, 2006년 3월 4일 (UTC)

"직접 설명"이란? --Briion 00:29, 2006년 3월 5일(UTC)

특정 템플릿의 특징으로, 이 경우 대체 언어에서 {{R}}.Titoxd^{(?!? - help us)} 00:32, 2006년 3월 5일(UTC)

좋아, 그럼 이건 오른쪽에서 왼쪽으로 하는 것과는 아무 상관 없어.리디렉션의 다른 템플릿에서도 동일한 현상이 발생한다([5] 및 [6] 참조).설명은 리디렉션 페이지에 포함되지 않지만 디프트에 표시된다.왜 그게 버그가 아니라 특징이지?쿠스마 (討討) 17:37, 2006년 3월 5일 (UTC)

설명은 "noinclude"에 있으므로 편집 시에만 표시된다.

--윌리엄 앨런 심슨 2006년 3월 6일 (UTC)

템플릿의 노이클:틀린 철자의 R은 설명이 아닌 범주에만 관련된다.또한 디프 디스플레이의 "디프 박스"를 의미하는 것은 아니다.다른 점은 전체 기사(이 경우 리디렉션)가 디프포함 아래에 어떻게 표시되는가이다.링크를 확인해봐. 내 말뜻을 알아봐.쿠스마(討討) 12:29, 2006년 3월 6일 (UTC)

어쨌든, 나는 버그리포트를 찾았다: 이것은 버그질라:927이다.쿠스마 (討討) 03:19, 2006년 3월 7일 (UTC)

쿠키 다시 사용(로그인 상태를 유지할 수 없음)

몇 주 전에 비슷한 일이 생겼어.갑자기 로그아웃되었다(메시지나 뭐 그런 건 없고, 워치리스트를 새로 고치러 갔을 때 더 이상 로그인하지 않았다).다시 로그인하려고 하면 "로그인 오류:위키피디아는 사용자 로그인을 위해 쿠키를 사용한다.쿠키를 사용할 수 없도록 설정하셨습니다.활성화한 후 다시 시도하십시오."하지만 쿠키가 활성화되어 있고(아주 오랜 시간 동안 거기서 바뀐 것은 아무것도 없다) 항상 "Remember me" 박스를 체크하고 로그인한다.나는 파이어폭스를 사용하고 있다.좋은 생각 있어?olderwiser 17:24, 2006년 3월 4일(UTC)

아까 여기서 본 바로는 쿠키를 삭제하고 다시 로그인해보는 것이 나의 제안이다.이것이 도움이 되기를 바라며, 샤르드소프메탈^{[ Talk Contribs ]} 19:25, 2006년 3월 4일(UTC)

이제 좀 나아졌어.캐시를 지우고, 쿠키를 지우고, 다시 부팅하고, 일반적인 Windows(윈도우)의 빠른 치료법들을 모두 삭제했다.그러나 3월 4일 몇 시간 동안 나는 로그인할 수 없었다. 더 나이든 02:17, 2006년 3월 7일 (UTC)

제안: 이름 변형

위키피디아 검색이 자동으로 지미->제임스, 밥->로버트 같은 이름의 변형을 시도할 수 있다면 좋을 것이다.이것을 위한 방향 전환이 있어야 하지만 항상 있는 것은 아니다 - 최근 내가 우연히 만난 예는 클리퍼드 스타인을 위한 클리프 스타인이었다.지원이 있다면 미디어위키 버질라에서 이걸 받아볼 수 있어2006년 2월 20일 데코 02:05 (UTC)

위키피디아의 검색이 많은 일을 할 수 있다면 좋겠지만 (내가 알기로는) 절대 안 할 것이기 때문에 구글 사이트 검색을 이용한다.Superm401 - Talk 04:04, 2006년 2월 20일(UTC)

그리고 이 구글 검색 상자는 WP에 특정되어 있는데 맞춤법 검사 제안과 같은 좋은 것들이 모두 포함되어 있다.2006년 2월 20일(UTC) 18:38, 하이드톡

그것은 깔끔한 인터페이스지만, 당신은 어떤 구글 검색 상자에서도 당신의 질의 앞에 "site:en.wikipedia.org"을 입력할 수 있다.Superm401 - Talk 06:11, 2006년 2월 26일(UTC)

검색 질의 전에 그런 문자열을 입력하는 것이 좋은 사용자 인터페이스의 예라고 생각하는 사람들이 있다는 것은 정말 놀랍다. --Myk 03:11, 2006년 3월 5일 (UTC)

나는 그것이 실제로 마음에 든다. 당신은 고급 검색 페이지를 한두 번 통해 무언가를 하고, 당신은 그것이 생성하는 검색 문자열의 형식을 알아차린다.왜 그렇게 많은 사람들이 명령 기반 인터페이스를 두려워하는가?플러그워시 22:13, 2006년 3월 7일(UTC)

확실히 이렇게 오래 지체할 수는 없겠지...

발렌사 기사는 다음과 같이 분류된다.페이지 기록에 따르면 포르투갈 지리는 4일 전에 만들어진 그루터기라고 한다.그러나 발렌사만 클릭하면 그 페이지는 존재하지 않는다는 것을 알 수 있다.데이터베이스가 따라잡기엔 4일이나 지연되는 것 같아...왜 그러고 있어?그루티니스...뭐라고? 2006년 3월 9일 11시 11분(UTC)

아마도 삭제된 페이지에 대한 질문 #절에서 위의 브리온 바이버가 언급하는 버그일 것이다.나는 그 기사의 캐시를 숙청했고, 지금은 괜찮아.유진 판 데르 피엘 21:43, 2006년 3월 9일 (UTC)

페이지 사이클린 종속 키나제의 이상한 .ogg 링크

사이클린 의존 키나제 페이지를 보십시오.익명의 IP 주소를 통해 Media:example.ogg라는 이상한 링크가 추가되었다.그것은 위키피디아를 가리키지만 읽을 수 없다.어떻게 해야 할지 모르겠어. --사용자:AAM Talk 08:40, 2006년 3월 9일 (UTC)

삽입을 되돌렸다.사용자가 편집 도구 모음에서 임의 단추를 클릭했을 겁니다.다음에 그러한 파일에 대한 링크는 신참들에 의한 무해한 실험으로 안전하게 제거될 수 있다.— Kimchi.sg Talk 09:49, 2006년 3월 9일 (UTC)

편집한 후 자신의 이름을 삭제하는 중...가능한가?

그 주제는 그것을 요약한다.나는 지금 내 이름을 바꾸고 싶은 이름을 만들었다.만약 내가 어떻게든 내 계정을 삭제할 수 있다면, 나는 그 요청을 사용하여 이름 페이지를 변경할 수 있을 것이다.계정 삭제와 관련된 문제는 GNU 무료 문서 사용권인가?만약 편집이 없다면, 누군가가 요청으로 그들의 유일한 편집본을 제출함으로써 어떻게 해서든지 자신의 계정을 삭제할 수 있을까?샤랑기토 08:23, 2006년 3월 9일 (UTC)

옛날 것은 그냥 놔둬라, 무슨 큰일이니? --Briion 21:35, 2006년 3월 9일 (UTC)

Wikilinking 접미사 텍스트

링크를 만들 때 시스템(WP:Editing에서 언급된 바와 같이)은 링크를 접미사 텍스트로 확장시킬 수 있을 정도로 충분히 스마트하다.예를 들어 [[Foo]s는 모든 Foos를 포함하도록 링크를 확장한다.foos. 이것이 작동하지 않는 접미사 텍스트의 한 범주, 즉 소유권 또는 아포스트로피로 시작하는 접미사가 있는 것으로 보인다.예를 들어 [Foo]는 모든 Foo를 포함하도록 확장되어야 하지만 대괄호 사이에 텍스트만 연결되어야 한다.푸스.

의미론적으로, 나는 이 행동에 대해 아무런 문제가 없다. 왜냐하면 링크는 "Foo"라는 기사만을 가리켜야 하기 때문이다.그러나 그래픽으로 볼 때 이것은 영어로 보면 멍청해 보인다.Foo's는 한 단어로, 그렇게 연결되어야 한다. ...적어도 내 의견으로는;) 왜 이것이 기본 행동이 아니거나 아니면 안 되는지에 대한 어떤 생각이라도 크게 감사할 것이다.Seqsea (대화) 03:37, 2006년 3월 9일 (UTC)

내 추측에 의하면 (그러나 이것은 정보에 입각한 추측이다) "suffix"의 정의는 매우 단순하게 "인접적인 알파벳 문자"이며, 의도적으로 구두점을 교차하지 않는다는 것이다. 왜냐하면 일반적으로, 당신이 아포스트로피를 건너기를 원하는 경우가 있지만, 그것은 옳지 않기 때문이다.분명히 알고 있을 테지만, 물론 [Foo Foo's]라는 링크를 파이프화함으로써 링크의 외관을 (입력을 조금 더 하는 데 드는 비용으로) 항상 완벽하게 제어할 수 있을 것이다. [Foo Foo's]는 Foo의 것과 Foo와의 링크를 닮았다.—Steve Summit (대화) 03:45, 2006년 3월 9일 (UTC)

제안:노란색 "라벨"에 더 잘 쓰세요!

내부 위키백과 링크에 커서를 놓으면 페이지 이름이 적힌 노란색의 작은 라벨이 나타난다.예를 들어, Escatology의 라벨에는 "Escatology"라고 쓰여 있다.직접 먹어봐!

이건 전혀 쓸모가 없어...다른 기사로 건너뛰고 기다려야 에스챗학이 뭔지 알 수 있어

하지만, 약간의 변화를 도입하는 것은 정말로 기적을 일으킬 수 있다: 만약 모든 편집 페이지들이 여러분이 짧은 설명을 쓸 수 있는 작은 분야를 가지고 있다면, 그래서 그 라벨이 "세상 종말의 신학 연구"가 될 것이고, 우리는 하루에 수천 번의 불필요한 클릭을 줄일 것이다!

컴퓨터처럼 새로운 기술을 사용하는 것의 핵심은 사물을 더 효율적으로 만드는 것이다.그 방향으로 다시 한 번 작은 발걸음을 내딛자! - 조나단 샤퍼, 2006년 3월 8일 (UTC)

재미있는 생각이야!그러나 좀 더 노련한 편집자들 중 일부는 팝업 도구를 사용하기 때문에 이 문제에 대해 별로 생각하고 있지 않을 수도 있다.팝업 도구를 모노북.js에 설치한 상태에서 링크 위에 마우스를 올리면 처음 몇 문장, 언제, 누가 편집했는지에 대한 정보 및 기타 여러 가지 유용한 정보를 포함한 유용한 정보가 담긴 큰 상자가 나온다.그 "크러치"로, 어쩌면 근본적인 문제를 해결하려는 동기가 그렇게 강하지 않을지도 모른다.하지만 여기 오는 임의의 사용자들은 그것을 실행하지 않을 것이다.생각할 수 있는 음식.++Lar: t/c 15:04, 2006년 3월 8일(UTC)

사실, 작은 노란색 상자는 링크의 밑바탕에 있는 페이지를 보여준다.내가 이 링크를 만들면 --> 아래에 있는 것은 링크의 이름이 아니라 링크된 페이지를 가리킬 것이다.사용자:Zoe 17:21, 2006년 3월 8일(UTC)

이 (정확한) 제안을 실현하기 위해, 우리는 중요한 기술 부분에서 부족하다.이상적으로 소프트웨어는 기사에서 한 두 줄 요약을 추출할 수 있을 것이다. 이 요약을 다양한 애플리케이션(툴팁 아이디어, 요약 목록 생성, 기타 애플리케이션, 웹 사이트 등)에 사용할 수 있다.제대로 쓰여진 소개 단락("Joe Smith 1909-1924는 영국의 중요한 영화 감독이었는데, 기차가 있는 영화를 많이 만들었다.")은 이러한 목적을 잘 수행할 수 있지만, 위키텍스트에서 자동적으로 추출하는 것은 소프트웨어로서는 실용적이지 않다(이미지, 인포박스, 다블라인, 분쟁 박스 등).그래서 우리는 데이터베이스에 분리된 가게가 필요하거나(그리고 기사 상단에 별도의 작은 편집 창) 요약의 시작과 끝을 나타내는 특별한 마크가 필요하다.그렇게 되면 우리는 인트로 파라스가 정말로 요약품인지 확인하기 위한 공동의 노력도 필요할 것이다(Joe Smith 1909-1924는 너무 흔한 것이 아니라) (Joe Smith 1909-1924는 앤트림 카운티의 돼지 농장에서 태어나서 개구리들에 대한 평생의 공포를 키웠다."." -- -- Finlay McWalter Talk 18:00, 2006년 3월 8일 (UTC)

이 제안은 좋은 제안으로, 비록 실행이 그다지 우아하지는 않지만 이미 가능한 것이다.나는 에스챗톨로지의 예를 만들었다.먹어봐.이것은 더미 리디렉션에 의해 이루어진다.

나도 얼마 전에 생소할 수 있는 용어를 설명하기 위해 비슷한 방법으로 사용할 수 있는 템플릿을 만들었어.여기 에스챠토리의 예가 있다. 만약 이 템플릿이 널리 사용된다면, 사람들은 파란 점이 낯선 용어를 빠르게 설명할 것이라는 것을 알게 될 것이다. -- Samuel Wantman 01:45, 2006년 3월 9일 (UTC)

어느 쪽인지는 기억이 안 나는데, 제3자 위키백과 거울 중 하나가 이미 이런 팝업 추상화를 제공하고 있다...thefreedictionary.com처럼 보인다. 예를 들어, 그들의 Escatology 버전 -- Solipsist 21:12, 2006년 3월 9일 (UTC)

여기 링크 및 템플릿

나는 스페셜에 있는 링크를 보고 있었다.올바른 기사로 그들을 혼란스럽게 하기 위해 무엇이 여기/V10을 연결하는지(거의 모든 것이 V10 엔진으로 간다).다만, {{Piston 엔진 구성}}을(를) 사용하는 모든 기사가 V10 엔진을 가리키도록 2월 18일에 템플릿이 변경되었음에도 불구하고 목록에 나타난다는 것이다.이것이 정확하지 않게 하는 어떤 종류의 캐시가 있는가? --rogerd 03:04, 2006년 3월 8일 (UTC)

해당 페이지는 템플릿을 새로 고치기 위해 null 편집(편집 후 저장)이 필요하다.많이 있으면 위키피디아에서 요청을 할 수 있다.Bot 요청.-gadfium 06:27, 2006년 3월 8일(UTC)

삭제 작업을 트리거하기 위해 [8]을(를) 작게 편집했는데 이제 특수:여기/V10은 최신 버전이다.이전 {{Piston 엔진 구성} 편집은 bugzilla:4857 fix 이전인 것 같아. borgx^(talk) 10:03, 2006년 3월 8일(UTC)

너희 둘 다 덕분이다.응, 지금 맞는 것 같아. --rogerd 13:18, 2006년 3월 8일 (UTC)

어디선가 읽었는데...

나는 어딘가에서 사용자들에게 외국 위키백과의 공공 기물 파괴 행위를 청소하는 것을 돕기 위해 일시적인 SYSOP 능력을 줄 수 있다는 것을 읽었다.분명히, 이것은 주요 공공 기물 파손 행위가 진행되는 동안, 대부분의 혹은 모든 관리자들이 그들 지역에서 잠을 자고 있을 때 도움이 된다.하지만, 어떻게 이런 일이 일어날까?외국인 사용자에게 관리 능력을 부여하기 위해서는 원어민 관리자가 있어야 하지 않는가?아니면 이게 어떻게 되는 겁니까?이렇게 될 줄 몰랐어! --Shultz III 00:47, 2006년 3월 8일 (UTC)

일반적으로 관리 메커니즘이 아직 존재하지 않는 매우 작은 위키백과 중 하나에서 발생한다(가장 작은 일부 위키백과에는 소수의 정규 사용자만 있다).그러한 경우 누군가가 스튜어드에게 접근하게 될 것이며(지금 이런 종류의 메타에 관한 페이지가 있을 수 있지만) 모든 것은 비공식적이고 다소 수동적인 방식으로 이루어진다. -- Finlay McWalter Talk 00:55, 2006년 3월 8일(UTC)

좋아, 좋아.그것에 대해 더 읽을 수 있는 페이지가 있니?알고 있으면 위키링크를 보여줘.고마워. --Shultz III 01:07, 2006년 3월 8일 (UTC)

m:Meta:Requests_for_adminship이 메타 페이지다.Xaosflux _CVU/ 04:12, 2006년 3월 8일(UTC)

그 페이지는 메타에 대한 관리자 액세스 요청용이다.아직 로컬 관료가 없는 다른 위키에서 관리 권한을 요청하는 내용은 m:권한 요청을 참조하십시오.안젤라2006년 3월 8일 12시 48분(UTC)

어디 있어?

위키피디아의 원시 CSS 파일은 어디에 있는가?미디어위키를 둘러봤는데Common.css 및 MediaWiki:모노북.css, 그러나 "usermessage" 클래스 등의 항목을 찾을 수 없었다.고마워. – WB 00:09, 2006년 3월 8일(UTC)

위키백과를 둘러보십시오.CSS 클래스 카탈로그.~MDD4696 04:13, 2006년 3월 8일(UTC)

방청객 제안

특별한 제안이 하나 있다:감시 목록02:14 3월 7일 현재 (즉, "{CURRENTIME}} {{CURRENTMENTNAME}} {{CURRENTDAY}})와 같은 것이 상부에 있다면 좋을 것이다.—Steve Summit (대화) 15:12, 2006년 3월 5일 (UTC)

와우! 빠르네.고마워. ("당신의 감시 목록에 %d 페이지가 있는 경우" 대신 "최근 %d일 동안의 마지막 %d 변경 사항" 문장에서 더 낫겠지, 그렇지 않다면 말이야.) —스티브 서밋(토크) 22:42, 2006년 3월 5일 (UTC)

이 텍스트를 제어하는 페이지는 MediaWiki:자세한 정보를 확인하십시오.덧셈은 되돌렸다.나는 그것을 다시 추가할 것이다. 왜냐하면 나는 또한 그것이 꽤 유용하다고 생각하기 때문이다.제시W, 저글링 관리인 2006년 3월 7일 (UTC)

사실 네가 말한 비트가 있는 페이지는 미디어위키:rcnote야.나는 이 토론의 포인터를 가지고 그 페이지를 편집했다.제시W, 저글링 관리인 2006년 3월 7일 (UTC)

그리고 MediaWiki:wl note도.제시W, 저글링 관리인 2006년 3월 7일 (UTC)

고마워! 해피캠퍼스는 며칠 전에 보셨듯이 그런 변화를 만들었지만, "이행을 향한 약간의 저항이 있었다"는 이유로 되돌렸다.왜 그랬는지 모르겠어.내 토크 페이지의 "아하!" 아래에 있는 그의 댓글을 봐.—Steve Summit (대화) 17:55, 2006년 3월 8일 (UTC)

스타일링

누군가가 바닥글을 위한 새로운 NavFrame/NavHead 형식에 현재 바닥글이 스타일링한 것과 동일한 공간을 제공하는 스타일을 가지고 있는지 확인할 수 있는가?class="toccolours"? 새로운 바닥글에는 몇 가지 장점이 있지만(최소한 최종 사용자에게는, 이 새로운 구문에 사용되지 않는 위키피디아를 위한 것이 아니라면), 그들은 오래된 바닥글과 똑같이 생겼어야 한다.Circeus 20:19, 2006년 3월 10일 (UTC

텍스트 상자

어떻게든 양귀비 아티스의 텍스트 상자를 엉망으로 만들 수 있었다.사진 솜씨가 지워졌다.고치는데 도움이 좀 필요해.이러한 텍스트 보우의 구문이 어떻게 좋을지에 대한 설명도 좋다.--BorisFromStockdale 06:48, 2006년 3월 10일 (UTC)

나는 그것을 고칠 수 있었다.이제 제 질문은, 애초에 어떻게 바뀌었을까?그 그림은 괜찮았고, 그리고 나서 사라졌다.예술 편집 역사에 기록된 변경 사항은 없으십니까?제안 사항 있으십니까? --BorisFromStockdale 06:51, 2006년 3월 10일(UTC)

신경 쓰지 마, 난 지금...잘못된 기사를 보고 있었는데...늦었어, 자러 가야겠어...

자바스크립트가 작동하지 않음

편집 모노북.js 페이지에 편집 모드일 때 도구 섹션에 추가 기능을 추가해야 하는 스크립트를 몇 개 추가했지만 아무 일도 일어나지 않는다.모든 것이 순서가 맞는 것 같다. 스크립트들은 위키백과 스크립트 리스트에서 나온 것이다. 캐쉬는 명확하다. 나는 파이어폭스와 ZoneAlarm에서 자바스크립트를 사용할 수 있다.좋은 의견이라도 있나?고마워!헤로스트라투스 22:20, 2006년 3월 9일 (UTC)

그 안에 HTML 태그가 들어있어, 한 가지 이유.Firefox의 Javascript 콘솔에서 오류를 제거해도 문제가 해결되지 않는지 확인하십시오. — Omegatron 22:33, UTC)

그래? 확인은 OOOps, 확인은 물론, Javascript 콘솔에 대해서도 몰랐고, 찾을 수 있을거야, 고마워!!!헤로스트라투스 13:38, 2006년 3월 10일 (UTC)

커먼스에 연결

만약 당신이 (미디어위키 1.5)위키를 설치한다면, 그것은 지금 위키백과가 하는 방식대로, 공동체의 사진을 얻도록 설정될 수 있는가?만약 그렇다면, 어떻게?제라드 폴리 15:32, 2006년 3월 9일 (UTC)

기능성은 있지만, 접근은 없다.MediaWiki 설치는 공유 업로드 기능이 작동하는 Commons의 MediaWiki 설치 데이터베이스에 액세스할 수 없음.이러한 종류의 기능을 사용할 수 있게 하는 InstantCommons 기능에 대한 논의가 진행 중이지만 구체적인 것은 없다.롭 처치 (토크) 07:41, 2006년 3월 10일 (UTC)

그렇구나. 특히 (거의) 모든 것이 무료 면허를 받고 있을 때 하는 것은 논리적인 일인 것 같아.제라드 폴리 2006년 3월 10일 12시 14분 (UTC)

삭제된 페이지에 대한 질문

삭제된 두 페이지, 인터내셔널 남성 & 토크:애플. 두 기사 모두 '위키피디아에는 이 정확한 이름의 기사가 없다'는 공지문을 띄고 있지만, 두 페이지의 기사 내역은 정당한 내용을 보여주며 페이지가 삭제된 이유를 알 수 없다.이 기사들 어떻게 된 건지 설명해줄 사람 있어?왜 제거되었는가? --Muchness 15:25, 2006년 3월 8일 (UTC)

둘 다 괜찮아 보여.사용자:Zoe 17:22, 2006년 3월 8일(UTC)

그들 역시 나를 위해 나타나지 않아서, 나는 그들 둘 다 무효로 편집했고 지금은 괜찮아 보인다.캐싱 문제인가? --Bob Mellish 18:40, 2006년 3월 8일 (UTC)

이상해. 서로 다른 OS를 실행하는 두 대의 다른 컴퓨터에서 테스트를 했는데 둘 다 같은 문제가 있었어.페이지 복원을 위해 더미 편집 몇 개를 추가했다. --Muchness 23:11, 2006년 3월 8일 (UTC)

삭제되지 않고, 며칠 전에 캐시 버그가 있었다.보이면 퍼지 링크를 눌러라. --Briion 21:36, 2006년 3월 9일(UTC)

설명 고마워. --Muchness 10:01, 2006년 3월 10일 (UTC)

페이지 이동 및 내 감시 목록

페이지 이동이 "나의 감시 목록"에 최근 변경사항으로 나타나는 이유는? -- Samuel Wantman 09:49, 2006년 3월 7일(UTC)

벌레가 없는 한, 그럴 수 있지가능하다면 구체적으로 말해라. --Briion 21:38, 2006년 3월 9일 (UTC)

이 편집은 내 감시 목록에 나타나지 않고 기사의 가장 최근 변경사항이다.나는 지난 7일 동안 변경된 내용을 보고 이전 이름과 새 이름을 사용하여 텍스트 검색을 했다.기사의 옛 이름과 새 이름이 모두 감시되고 있다.더 구체적인 질문을 하지 못해서 미안해. -- 새뮤얼 원맨 01:08, 2006년 3월 10일 (UTC)

이미지가 사라지는가?

모두 안녕. 최근에 내가 이미지를 업로드했어.액티마인 로고.gif, 잠시 동안 멀쩡한 모습을 보였지만 갑자기 사라졌다.그대로 이미지 페이지는 그대로 있었지만 이미지는 없었다.내가 그것을 다시 업로드했더니 이미지가 아주 잘 나타났다.불행히도, 이제 다시 사라졌다.이것은 단지 서버 전파 문제인가, 아니면 내 이미지에 문제가 있는 것인가?~MDD4696 04:27, 2006년 3월 6일(UTC)

흥미롭군...캐시를 치웠더니 다시 나타났다.그런데 왜 그런 일이 일어났는지 아직도 궁금하다.~MDD4696 04:31, 2006년 3월 6일(UTC)

actimagine0310226logo.gif 이런 식으로 이름을 붙여봐. 그렇게 하면 이미지가 독특한 날짜를 가지고 있고 누군가가 덮어쓸 가능성은 희박하다.Miskatonic 00:55, 2006년 3월 10일 (UTC)

위키백과:중재요청

RfAr 페이지는 사라진 것 같다.내가 내 감시목록에서 그것을 찾아가려 할 때, 그것은 존재하지 않으며, 그것을 만들거나 검색하거나 창조를 요청할 수 있다는 말을 듣는다.나는 그것을 만들고 싶지 않다. 왜냐하면 만약 정말로 결함이 있다면, 그것은 이상한 효과를 가져올 수 있기 때문이다.2006년 3월 5일(UTC) 로버트 매클론 23:13

이제 거기에 있는 것 같다.롭 처치 (토크) 07:46, 2006년 3월 10일 (UTC)

여기가 어디지?

클래스="MainPageBG"

미디어위키를 살펴봤는데Common.css, 그리고 그것은 거기에 없다.

이 수업의 정의를 어디서 찾을 수 있는지 아는 사람 있어?
-가라! 2006년 3월 2일 17시 34분(UTC)

모노북에서도 못 찾겠어위키피디아:CSS 클래스 카탈로그에는 모든 스킨이 사용하는 모든 스타일시트의 목록이 있다. --cesarb 20:34, 2006년 3월 2일(UTC)

CVS의 피부 디렉토리를 통해 빠른 grep으로는 찾을 수 없었다.이 클래스가 참조된 곳은 어디인가?롭 처치 (토크) 2006년 3월 3일 19:48 (UTC)

클래스는 메인 페이지와 메인 페이지 재설계 초안에서 사용된다.나는 그것들이 더 이상 존재하지 않는 클래스를 언급하는 코드 잔재물이라고 생각하기 시작했다. --시작하라! 05:04, 2006년 3월 9일 (UTC)

그런 것 같군.롭 처치 (토크) 07:51, 2006년 3월 10일 (UTC)

다국어론

한 개 이상의 언어로 기여하는 것이 가능하지 않을까?줄루에서 메인 페이지를 열었는데 갑자기 로그인이 안 되더니 로그인을 하려고 하면 존재하지 않는다고 적혀 있었어!영어 위키피디아는 다른 위키피디아와 완전히 분리되어 있는가?다른 언어 버전에 대한 계정을 새로 만들어야 하는가, 아니면 내가 잘못하고 있는 것인가?어떤 도움이라도 정말 고마워!고마워 :) 2006년 3월 2일 10:43

불행히도, 그래, 너는 새로운 계정을 만들어야 해.마틴 10:45, 2006년 3월 2일 (UTC)

바라건대, 이것은 곧 바뀔 것이다.그것은 이미 오래 전부터 거론되어 왔다.Rmhermen 14:41, 2006년 3월 2일 (UTC)

다른 언어에는 분명히 중복된 사용자 ID가 있기 때문에, 사람들은 그것이 어떻게 구현될 지 궁금해해야 한다.예를 들어, 그리스어 위키피디아에 있는 누군가가 User:Zoe 계정을 만들었다면, 이 제안된 변경으로 어떻게 그들이 내 영어 계정을 인수하지 않았는지, 아니면 내가 그들의 그리스어 계정을 인수하지 않았는지 알 수 있을까?사용자:Zoe^(talk) 17:41, 2006년 3월 3일(UTC)

축하합니다, 단일 로그온(음, 큰 비기술적 로그온);-)의 정확한 문제를 해결하셨습니다.IERC라는 두 가지 제안은 모든 사람들을 중복 계정에서 강제로 빼내거나(그래서 모든 다른 Zoes는 새로운 사용자 이름을 얻어야 한다) 또는 어떤 사용자가 그것을 얻는지를 결정하기 위한 알고리즘을 찾는 것이었습니다. 그것이 기여의 양이나 등록일, 또는 그 이름으로 보유하는 계정 수나...뭔가가 있어네가 추측할 수 있듯이, 이것들 중 어느 것도 모두를 기쁘게 하지 못할 것이다.심그레이 토크 21:23, 2006년 3월 3일 (UTC)

이 문제가 논의되는 곳은 모르겠지만, 가장 쉬운 디스플레이 솔루션은 "User:en:Zoe"와 "User:gr:Zoe"이며, 기본값은 로컬 언어인 것 같다.이 방향은 일단 만들어졌거나 전혀 기여되지 않은 사용자 이름(유지된 마스터 사용자 번호, 그러나 새 사용자 이름에 할당하여 이름을 재사용할 수 있음)을 제거하는 방향일 수 있다.

--윌리엄 앨런 심슨 2006년 3월 5일 (UTC)

여기에서 Single Sign-On에 대한 완전히 새로운 논의를 시작하지 마십시오. 참조된 메타 페이지를 참조하십시오.롭 처치 (토크) 07:52, 2006년 3월 10일 (UTC)

방해받지 않는 공간 마크업?

나는 적절한 타이포그래피를 좋아하지만 간단한 위키 마크업도 좋아한다.지금 우리가 &mdash 같은 것들을 마크업으로 대체할 수 있다는 것은 좋은 일이지만, 모든 것이 다 잘 되지는 않는다.그래서 나는 &nbsp를 위한 위키 마크업 아이디어를 생각해내려고 노력해왔다.세 칸을 연속해서 사용하여 비파괴적인 공간을 나타내는 것에 대해 어떻게 생각하십니까?내 스스로도 몇 가지 단점을 생각할 수 있지만, 나는 그것을 밖에 던져야겠다고 생각했다.— 오메가트론 06:52, 2006년 3월 11일 (UTC)

되돌린 이미지 저장

5분 동안 정보를 검색했지만 "이미지 되돌리기" 또는 "이미지 되돌리기"를 검색하거나 이미지 정책 페이지를 보거나 도움말 페이지를 되돌리는 방법으로 정보를 찾지 못했다.수오...

기존 포토네임 위에 새로운 사진을 올리는 사람들이 급증하는 것 같다.나는 예전 사진으로 되돌릴 수 있고, 그렇게 할 수 있고, 사용자에게 독특한 이름을 사용하여 다시 업로드할 수 있는 노트를 남길 수 있다.하지만 예전 사진과 새 사진을 모두 살릴 방법이 있을까?내 말은, 새로운 것의 복사본을 다운로드한 다음, 되돌린 다음, 새로운 것을 업로드하고 라벨을 붙이는 것 말고는? (그들이 항상 그렇게 보이지 않는 소스/저작권 정보를 제공했다고 하더라도)?엘프 토크 02:43, 2006년 3월 11일 (UTC)

내가 아는 한, 아니.이 사진들을 어떻게 알아냈니?기꺼이 돕겠다.~MDD4696 02:49, 2006년 3월 11일(UTC)

좋아, 내가 약간 과장했다는 것을 고백한다.나는 적어도 3, 4, 5주 정도는 지난 주나 지난 주나 두 주 사이에 알아차렸으며, 여기서 지난 2년 동안 한 번 본 기억이 나지 않는다.그래서 "대박"은 과대 광고일 수도 있지만, 그것은 나를 걱정하게 하고, 또 무슨 일이 일어나고 있는지 궁금하게 만든다.내가 그들을 발견한 것은 다음과 같다: (a) 하나는 덮어씌워진 나의 사진이었고, 내가 업로드한 사진의 색인 페이지를 보고 있을 때, 내가 인식하지 못한 것이 있었다. (b) 내 감시목록에 있는 기사에 있는 이미지 캡션이 완전히 다른 말을 하도록 바뀌었고, 그 기사에 익숙했기 때문에, 내가 그 기사를 볼 때, 나는 그 사진을 볼 때,나이, 나는 그 사진을 알아보지 못한다는 것을 알았다; (c) 다른 이유로 내 감시목록에서 기사를 훑어보고 있었는데, 그 사진이 기존의 자막과 일치하지 않는다는 것을 알아차렸고, 그 글에 익숙했기 때문에 사진이 바뀐 것을 깨달았다.모든 경우 아래(여기와 같이)에 업로드 기록이 있는 이미지의 설명 페이지를 보면 다른 사용자가 동일한 이름을 사용하여 이미지를 업로드한 것을 알 수 있다.

나는 또한 이것들을 잡을 수 있는 어떤 방법이 있는지 정말 알고 싶다--아마도 자신의 감시 목록에 있는 이미지는 언제 덮어쓰여졌는지는 밝히지 않는다(위의 경우 ⑴과 같다).엘프 토크 03:49, 2006년 3월 11일 (UTC)

그래도 흥미로운 점이야이게 버질라에서 언급할 가치가 있을까?~MDD4696 04:51, 2006년 3월 11일(UTC)

특정 편집 단추 끄기

페이지의 다른 편집 버튼은 모두 영향을 받지 않고 특정 제목에 대한 [편집] 버튼을 끄는 방법이 있는가? --시작! 14:45, 2006년 3월 3일(UTC)

한 가지 방법은 <h2>를 사용하는 것이다.이것은 ===이것 대신 제목이다.이것은 예전에 당신이 페이지의 뒷부분을 편집하려고 할 때 문제를 일으키곤 했는데, 섹션과 머리글 간의 서신이 깨졌기 때문에, 나는 이것이 꽤 오래 전에 고쳐졌다고 생각한다.먹어보지 않았으니 조심해서 사용해라.-가드피움 20:22, 2006년 3월 3일(UTC)

내 토크 페이지를 봐, 내 생각엔 고쳐지지 않은 것 같아.—Nightstallion(?) 20:16, 2006년 3월 10일(UTC)

분명히 내가 틀렸다.편집 버튼도 눌리지 않아 두 배로 틀렸다.-가드피움 00:30, 2006년 3월 11일(UTC)

IE 오류

지난 한 주 정도, 나는 위키피디아 페이지를 로드하는 데 약간의 문제가 있었다. 주로 디퓨즈와 특수 페이지.로드하면 페이지가 표시되고 "Internet Explorer는 인터넷 사이트 <페이지 주소>를 열 수 없다"는 시스템 창이 뜬다.작업이 중단됨" 및 확인 버튼.OK 버튼을 클릭하면 페이지가 "표시할 수 없음" 메시지로 대체된다.이상하게도 뒤로 버튼을 클릭하면 페이지가 완벽하게 표시된다.이것은 겉보기에는 불규칙하고 겉보기에는 무작위로 보이는 페이지에서는 드물게 일어나지만, 위키백과 밖에서는 결코 일어나지 않는다.만약 내가 그 일이 일어난 페이지에서 왔다 갔다 하면 오류가 다시 발생하는 경향이 있다.그것은 바로 1분 전에 이 사용자 기고 페이지에서 마지막으로 일어났다.Raven4x4x10:37, 2006년 2월 27일 (UTC)

나도. --Quadalpha 03:07, 2006년 3월 3일 (UTC)

몇 주째인 나 셋은 - 이건 IE인가 아니면 위키피디아인가?Stephenb(Talk) 2006년 3월 7일 20:59(UTC)

나 넷! 왜 그런지 아는 사람 있어?--Deglr6328 19:14, 2006년 3월 11일 (UTC)

나는 이 문제가 있어서 Mozilla Firefox로 바꿨다. --The1exile - Talk - 기여 - 19:50, 2006년 3월 11일 (UTC)

나는 둘 다 사용하지만 사용할 수 없을 때는 문제가 정말 짜증난다.--Deglr6328 21:54, 2006년 3월 11일 (UTC)

정렬 목록

나는 한 박스에 두 개의 리스트를 가지고 싶다.텍스트 항목의 목록 하나는 왼쪽에 정렬되어야 하고, 다른 텍스트 목록은 오른쪽에 정렬되어야 한다(상자의 오른쪽 끝까지).

이건 어떻게 된 거야?
-가라! 2006년 3월 12일 13시 56분(UTC)

다음 중 하나와 같은 건가?두 번째 형태에서 번호표를 오른쪽 기둥으로 옮기는 것은 어색하다.일반적으로 발표보다는 콘텐츠에 집중하는 것을 추천하고 싶기 때문에 정말 정당한 이유가 없는 한 이 두 가지를 모두 하지 않는 것이 좋을 것 같다. -- 릭 블록(토크) 15:28, 2006년 3월 12일 (UTC)

항목 1개 남음	항목 1권
2품목 남음	항목 2권
3번 항목 남음	항목 3권
항목 4	항목 4

항목 1개 남음 2품목 남음 3번 항목 남음 항목 4

항목 1권 항목 2권 항목 3권 항목 4

SpamCop에서 블랙리스트에 올린 메일 서버

감시 목록에 있는 메시지 또는 최근 변경 사항으로 인해 여기에 있는 경우, 자세한 내용은 아래를 참조하십시오.모든 사용자가 이 중요한 메시지를 전달하도록 메시지가 표시됨

• 다음 경우에만 이메일을 확인하십시오.

1. Wikipedia 지원 이메일 계정 및
2. 아직 이메일을 확인하지 않으셨습니다.

• 위키백과 이메일을 사용 가능으로 설정하거나 확인 상태를 확인하려면 Special(특별)으로 이동하십시오.선호
• Watchlist와 Recent Changes에 있는 메시지는 약 2주 후에 제거될 것이다.
• 자세한 내용은 도움말:전자 메일 확인

고마워 xaosflux _CVU/ 03:13, 2006년 3월 4일 (UTC)

---

우리의 새로운 메일 서버가 스팸트랩 주소로 메일을 보낸 것으로 알려진 SpamCop에 의해 블랙리스트에 올랐다.(물론 정책별로 세부사항을 제공하지 않기 때문에 검증할 방법이 없다.)

사용자 간 전자 메일 기능이 실제로 남용될 가능성이 거의 없기 때문에, 나는 전자 메일 기능을 사용하기 위한 전자 메일 확인 요구 사항을 활성화했다.위키마다 따로 해야 하니 당분간은 좀 귀찮다.

리스트에 대해 이의를 제기했으니까 빨리 삭제하면 좋겠는데, 이메일을 받지 못하는 사람들은, 어, 다시 받기 시작할 겁니다. --Briion 22:42, 2006년 3월 1일 (UTC)

대부분의 사용자에게 의미:Special:로 이동하십시오.확인 메일을 보내고 확인 코드를 이메일로 보내라고 하십시오.그렇지 않으면 위키백과 이메일을 받지 못할 것이다.1개 이상 있으면 모든 계좌로 해야 한다. --cesarb 04:11, 2006년 3월 2일 (UTC) (링크 변경) Superm401 - Talk 05:46, 2006년 3월 2일 (UTC)

음. 갑자기, 내 감시 목록 페이지 맨 위에 신비한 메시지가 뜬다.

위키백과 이메일 확인이 가능해졌다.Wikipedia 이메일을 받으려면 Special(특수)으로 이동하십시오.이메일 확인, 코드 요청, 이메일의 링크에 따르십시오.

어떠한 설명도 제공되지 않으며, WP: 정책 페이지 또는 토론 페이지로의 링크도 제공되지 않는다.이것에 대한 힌트는 커뮤니티 포털에 나타나지 않는다."특수:확인메일"은 또한 무엇이 바뀌었는지, 왜 이 과정이 추가되었는지에 대해서도 설명하지 못한다.이게 아주 교묘한 장난이 아니라는 걸 내가 어떻게 알아?만약 우리가 이 새로운 과정이 필요하다면, 우리는 정말로 그것에 대한 공지를 게시하고 어디에나 전시되는 메시지에 설명 링크를 포함시켜야 한다.~ Jeff Q (대화) 09:34, 2006년 3월 2일 (UTC)

1. 만약 그런 메시지가 나타났다면, 사람들이 그것을 볼 수 있기를 바라는 마음에서 누군가가 그것을 감시 목록 표시에 추가했기 때문이다(예를 들어, 그들은 그것에 대해 공지를 하고 설명 링크를 포함했다).
2. 당신은 당신의 주소를 확인할 필요가 없다; 당신이 위키를 통해 다른 사용자들로부터 이메일을 받고 싶을 때만.
3. 만약 그렇다면, 그것은 환경설정 페이지를 통해서입니다.당신의 상태를 보여주는 멋진 큰 상자가 있는데, 다른 사용자들로부터 메일을 받을 수 있도록 선택하기 위한 상자 옆에 있다.
4. WP: 정책 페이지나 토론 페이지는 없으며, 이것은 내가 사이트의 필요에 따라 내린 기술적 결정이기 때문이다.
5. 나는 그것의 이유를 여기와 위키피디아에 발표했다; 그러한 모든 발표와 마찬가지로, 그 정보는 각각의 위키에서 가장 잘 볼 수 있도록 이 중심적인 장소에서 복사되어야 한다.

--Briion 10:16, 2006년 3월 2일 (UTC)

단순히 이메일을 수신하는 것이 아니라, 다른 사용자에게 이메일을 보낼 수 없게 될 것이며, 이는 부적절한 사용으로부터 보호하는 데 더 관련이 있는 부분이다.적어도 우리는 사용자에게 이메일을 보낼 수 있는 모든 사람이 유효한 반송 주소를 직접 입력했다는 것을 알 수 있을 것이다.— 로라 스커더 ▷인터뷰 15:00, 2006년 3월 2일(UTC)

좋아, 그래서 이메일을 확인했어...어떻게 해야 내 감시 목록에서 그 짜증나는 메시지를 지울 수 있을까?Paul^C/_T+16:17, 2006년 3월 2일 (UTC

사용하다#confirmemail { display: none }. --cesarb 16:54, 2006년 3월 2일 (UTC)

음, 이걸 어디서 어떻게 쓰지?나는 "푸트"라고 생각한다.#confirmemail { display: none }X페이지에서"가 더 도움이 될 것이다. --Yar Kramer 18:28, 2006년 3월 2일 (UTC)

사용자의 개인 스타일 시트에서 다음 항목을 참조하십시오.Yar Kramer/monobook.css(기본 MonoBook 스킨을 사용하고 있다고 가정)—Ilmari Karonen(토크) 18:46, 2006년 3월 2일(UTC)

선두 파운드 표시에서 벗어나기 위해 선행 공간이나 기타 다른 것이 필요한가?내 모노북.css에 있는데 계속 내 감시 목록에 코드가 표시되고 css 페이지가 번호 목록으로 나타난다.—C.Fred (대화) 22:35, 2006년 3월 4일 (UTC)

선두 해시 부호를 탈출하기 위해 아무것도 필요하지 않다; 번호 목록으로 표시된 것은 버그이며, 문제를 일으키지 않는다.올바른 위치에서 편집 중인지 확인하십시오(Monobook.css는 모노북 전용이며, 다른 스킨은 페이지의 다른 이름을 사용함). --cesarb 16:34, 2006년 3월 5일(UTC)

Special에 대한 기본 링크 이후:Confirmemail은 사람들을 혼란스럽게 했다(기본 설정에 연결하는 것이 훨씬 더 좋았을 것이다), 나는 그것의 텍스트를 편집했다(MediaWiki:환경설정에 다시 링크를 추가하려면 이메일 확인 텍스트)를 사용하십시오.상황을 더 잘 설명하기 위해 그것을 바꾸는 것이 좋을 것이다; 나는 단지 문장을 추가했을 뿐이고, 나머지는 여전히 미디어위키 디폴트다. --cesarb 15:26, 2006년 3월 2일 (UTC)

• SpamCop 블록이 WikiEN-l 메일링 리스트 트래픽에도 영향을 미쳤을까?어제 그만 받았어. (하지만 오늘부터 다시 백업이 시작되었어. 그래서 어쩌면 스팸캅 블록이 해제된 걸까?)—Steve Summit (대화) 15:48, 2006년 3월 2일 (UTC)

나는 계정을 만들 때 위키백과 이메일 기능을 활성화했다.이 링크를 따라 확인 코드를 입력해야 하는가, 아니면 신규 사용자만 사용할 수 있는가?팔미로토크 16:50, 2006년 3월 2일 (UTC)

사용자 환경설정 페이지로 이동(특수:선호도).확인이 필요한지 아닌지를 알려준다.—Steve Summit (대화) 17:05, 2006년 3월 2일 (UTC)

{display:none} 줄을 삽입하는 위치그런 텍스트를 삽입하기 위해 감시 목록 페이지를 편집할 수 없어.고마워. --Mounties (Talk) 18:23, 2006년 3월 2일 (UTC)

User:MMounties/monobook.css(기본 MonoBook 스킨을 사용한다고 가정할 때)에 있는 개인 스타일 시트.—Ilmari Karonen (talk) 18:46, 2006년 3월 2일 (UTC)

다른 모든 언어 위키에서 같은 조언이 번역에 나타나야 하는가?ፈቃደ (ውይይት) 2006년 3월 2일 19:56 (UTC)

그래, 그래야지.서버 관리자 로그의 항목은 그것이 모든 공개 위키에 대해 활성화되었음을 분명히 나타낸다.만약 당신이 위키피디스의 관리자라면, 계속 그것을 하고, 그렇지 않다면, 그곳의 관리자에게 그것을 하라고 말해라.관리자도 연락을 받을 수 있는 방법 중 하나이기 때문에 가능한 한 빨리 계정 확인을 하는 것이 특히 중요하다. --cesarb 20:23, 2006년 3월 2일(UTC)

아무도 내가 왜 내 이메일 주소를 재확인해야 하는지 설명하려고 하지 않았기 때문에, 나는 일단 위키백과 이메일을 무력화시켰다. (난 너처럼 내 보안에 대해 편집증적이야. :-P ) 이것은 위키백과 이메일과 의사소통을 할 수 있기를 원하기 때문에, 나에게는 다소 귀찮다.왜 그러고 있어?킴 브루닝 20:18, 2006년 3월 2일 (UTC)

그럼 내가 설명해 줄게.위키피디아는 과거에 당신의 이메일 주소의 확인을 요청하지 않았다; 당신은 이메일 주소 필드에 임의의 이메일 주소를 넣을 수 있었고, 그것은 누군가가 위키피디아를 통해 당신에게 이메일을 보내려고 할 때 사용될 것이다.그러나 이제 확인 기능이 활성화되었으므로 전자 메일 기능을 사용하려면 전자 메일을 확인해야 한다.이 확인은 당신이 이메일 주소의 합법적인 소유자임을 증명하는 것에 지나지 않는다.당신이 확인 이메일을 보내라고 하면, 그것은 당신의 기본 설정에 등록된 이메일로 임의의 키로 링크를 포함하는 짧은 문자 메시지를 보낼 것이다.브라우저에서 링크를 열기만 하면 이메일이 유효한 것으로 확인됨.

메시지 표시 방법의 샘플(개인 정보를 제거하기 위해 내가 받은 메시지임)

아마도 IP 주소 127.0.0.1의 누군가가 "CesarB" 계정을 위키백과에 등록했을 것이다.이 계정이 실제로 사용자의 계정인지 확인하고 Wikipedia에서 전자 메일 기능을 활성화하려면 브라우저에서 이 링크를 여십시오. http://en.wikipedia.org/wiki/Special:Confirmemail/deadbeefdeadbeefdeadbeefdeadbeef 이 링크가 *not*인 경우 링크를 따르지 마십시오.이 확인 코드는 2006년 3월 9일 04:07에 만료된다. 

--cesarb 20:31, 2006년 3월 2일 (UTC)

[그것이 바로 "방법"이다;] 여기, 내 생각에, 진짜 이유는 [왜]인 것 같다.cesarb가 말했듯이, 과거에는 이론적으로 이메일 주소 필드에 임의의 이메일 주소를 넣을 수 있었다.그래서 무작위적인 사람이 당신을 위한 위키피디아 이메일을 받을 수 있었다.그래서 위키피디아가 그 사람을 스팸으로 보내고 있다고 할 수 있다.외부 관계자들(예: 스팸캅)에게 그것이 사람들을 스팸으로 보내지 않는다는 것을 증명하기 위해서, 위키피디아는 보내는 모든 주소가 유효하고 요청되었는지 확인하는 정책을 지적할 수 있어야 한다.

일반적으로 메일을 보내는 사이트(어느 사이트든, 어떤 이유에서든)는 이와 같은 "더블 옵트인(double opt-in)" 방식을 사용해야 한다.다른 어떤 계획도 결국 스팸 발송자들에게 납치된다.더블 옵트인이 모든 관계자들에게 귀찮은 일이라는 데는 동의하지만, 불행히도 그 성가신 스팸 발송자들에 대한 대응으로 우리 모두가 지불해야 하는 가격 중의 하나이다.(또한 나는 위키백과 이메일이 실제로 어떤 스팸 발송자들에게 납치되었다는 것을 암시하는 것은 아니지만, "모든 사이트는 어떤 일이 있어도 더블 옵트인을 사용할 필요가 있다"는 것은 분명하다고 생각한다.정책이 적용된다.)—Steve Summit (대화) 21:06, 2006년 3월 2일 (UTC)

그것의 정확한 이름은 "확인된 옵트인"이 아닌가?'더블 옵트인'은 두 번 하는 것처럼 들리는데, 그렇지 않다(한 번만 확인하면 된다).--cesarb 22:01, 2006년 3월 2일 (UTC)

"더블 옵트인"은 내 친구가 말하는 것이다; 나는 어떤 용어가 "올바른"으로 여겨지는지 모르겠다.명시적으로 두 가지 일을 해야 하기 때문에 "이중"이다. 즉, 이메일을 요청하는 것과 당신이 요청한 것을 확인하는 것이다.—Steve Summit (대화) 22:17, 2006년 3월 2일 (UTC)

"Double opt-in"은 우리가 일반적으로 소비자 이메일 사업에서 사용하는 용어다.의도적으로 두 가지 일을 해야 한다(링크 후 양식을 제출하거나 상자를 선택한 후 제출).확인됨은 귀하가 등록되었다는 내용의 이메일을 보냈으며 귀하가 응답하여 예, 귀하임을 인정했음을 나타내는 것이다. - PKM 19:26, 2006년 3월 4일(UTC)

RE:"내 감시 목록 알림에서 해제하는 방법" 코멘트는 위에 표시된 방법으로 상자를 건너뛸 수 있지만 감시 목록 페이지의 알림은 영구적이지 않을 것이다. 미디어위키를 통해 추가했다.위키백과 이메일을 사용하는 수천 명의 편집자에게 이 단어를 전달하기 위해 세부사항을 살펴보되 메일 목록이나 이 페이지를 자주 읽지는 마십시오.이 용도에 대한 코멘트는 MediaWiki Talk에서 할 수 있다.자세한 정보를 확인하십시오.미디어위키 공간에도 불구하고 나는 이 고시를 시행하는데 대담했지만, 2주 이상 이 고시를 실행할 생각은 하지 않았다.만약 확인이 가능한 상태로 남겨진다면, 우리는 모든 위키미디어 보유자들에게 마지막 확인되지 않은 이메일 하나를 보내서 그들에게 확인 요구 사항을 알려줄 수 있을까?Xaosflux _CVU/ 01:37, 2006년 3월 3일(UTC)

내 감시 목록의 맨 위에 메시지가 있다.나만 그런 건 아닌 것 같아.:) 여기 링크되어 있지만, 설명 페이지(무엇에 관한 것인지)에 대한 링크가 더 이치에 맞을 것이다.DirkvdM 06:32, 2006년 3월 3일 (UTC)

나는 이 "충돌" 메시지를 지금 4번 받았다.나는 이번 주에 그것을 세 번 확인했다.이메일에 언급된 IP 번호는 나의 것이 아니다.이게 중요한가?그리고 내가 이것을 몇 번이나 확인해야만 하는가?다니엘데마레트 17:00, 2006년 3월 3일(UTC)

확인 이메일의 사용자 이름이 올바르고 확인 이메일을 보내도록 요청하면 정상이며, IP는 아마도 사용 중인 투명한 프록시일 것이다(Special:로그인하지 않은 동안 Watchlist. 동일한 IP 주소를 표시해야 함Special:인 경우에만 확인하십시오.Preferences(기본 설정)에서는 필요하다고 하며, 확인되었을 때 볼 수 있으며, 확인이 필요한 경우. --cesarb 17:09, 2006년 3월 3일(UTC)

나는 확인 메일을 보내라고 요청하지 않았다.다니엘데마레 18:22, 2006년 3월 3일 (UTC)

방금 내 감시 목록 페이지에 위키백과 이메일을 확인해 달라는 배너 광고가 떴어.나는 (위키피디아) 이메일 주소가 없다.현수막 광고 어떻게 없애?내 (작은) 화면의 4분의 1 이상을 차지해!

고마워 -- 쿼터 21:34, 2006년 3월 3일 (UTC)

monobook.css에 "#confirmail { display: none }"을(를) 사용해야 한다.

글쎄, 나는 오늘 만든 계정에서조차 내 이메일을 확인하고 있어.만약 당신이 "다른 사용자로부터의 이메일 사용 가능"을 설정했다면, 모든 계정에 대해 확인서를 보내야 한다고 생각한다.게다가 등록 과정에서 이메일을 설정하면 이메일 확인이 자동으로 전송되어야 한다.Platonides 11:39, 2006년 3월 4일 (UTC)

신규계좌 등록시 자동으로 전송됨. --Briion 12:14, 2006년 3월 4일 (UTC)

이것은 장기간 비활성 사용자와의 접촉에 대한 완전한 고통이다.예: 누군가가 무언가를 업로드했고 우리는 저작권 상태를 확인하기를 원한다.이것을 무시하고 어쨌든 1년 이상 된 계정에 대해 메일을 보낼 수 있는 방법이 있을 수 있을까?모제라티 22:54, 2006년 3월 4일 (UTC)

내가 생각하기에 워치리스트 노트에 추가되어야 할 것은 이것은 일회성 거래일 뿐 이메일 영수증의 활성화는 아니라는 것이다.IMDb가 보내는 것과 같은 종류의 "이메일 영수증"에 대한 참조라고 생각했기 때문에 나는 그것을 하지 않았다.IMDb에 제출될 때마다 주의하지 않으면 받은 편지함을 빠르게 연결할 수 있는 이메일 영수증이 생성된다(예전만큼 IMDb에 기여하지 않는 이유 중 하나).그리고 IMDb sysop이 나에게 그것은 꺼질 수 없다고 말했다.내가 위키피디아를 위해 얼마나 많은 편집을 하는지 생각해 보면, 각각의 편집에 대한 영수증을 받는 것은 참담했을 것이다.23스키두 20:22, 2006년 3월 7일 (UTC)

어떻게 배너 광고를 없앨 수 있을까?

감시목록의 맨 위에 있는 배너 광고를 없애는 방법을 아는 사람?위키백과 이메일을 받기 위해 내가 어떻게 해야 하는지에 대해 계속 이야기하지만, 왜 내가 그것을 원했을까?User and Talk 페이지가 있으며, 이메일을 비공개로 하고 싶다.나는 링크를 따라 해 보았는데, '고맙다'고 할 말이 없다.할당량 21:00, 2006년 3월 4일(UTC)

네 대답은 여기 있을 거야.사용자가 위키피디아를 통해 전자우편을 보내도록 하는 것은 선택권을 가능케 한 사용자들만을 위한 것이다.안 그랬으면 아무것도 안 해도 돼 - 파일:Ottawa flag.pngnathanrdotcom 21:06, 2006년 3월 4일(UTC)

미안, 내가 내 말을 확실히 하지 못했어.나는 배너 광고가 핸드폰의 모든 감시 목록을 대체하기 때문에 없애버리고 싶다.어떻게 꺼?그게 왜 거기 있지?고마워! 할당량.

자세한 설명:만약 "사용자에게 위키피디아를 통해 전자우편을 보낼 수 있는 선택사항을 가능케 한 사용자들"만 해당된다면..왜 그것을 활성화하지 않은 사용자들을 위해 그것이 표시되는가?할당량 21:33, 2006년 3월 4일(UTC)

모든 사람들은 옵션이 활성화되었는지 여부에 상관없이 그 메시지를 본다.그러나 이 페이지의 아래쪽에 있는 지시사항을 사용하여 메시지를 제거할 수 있다. - 파일:Ottawa 플래그.png Nathanrdotcom 21:39, 2006년 3월 4일(UTC)

이메일 확인

이거 본 사람 또 있어?이것이 더 크고 아름다운 것을 향한 발걸음이 될 수 있을까?— 일리안엡 (토크) 02:52, 2006년 3월 3일 (UTC)

나는 그것을 보았지만 내가 해야 할 모든 것을 이해하고 그것에 대한 정보를 찾을 수 있는지 확실하지 않다.그렇다면 이 모든 것이 확인되는 것은 무엇인가?료코샤 03:30, 2006년 3월 3일 (UTC)

내 환경설정으로 이동하여 전자우편 주소를 입력했는지 확인하고 확인 전자우편을 받을 수 있는 옵션을 선택하십시오.Special(특수):내 기본 설정에 이미 전자 메일 주소가 설정되어 있는 경우 확인 전자 메일을 요청하려면 확인 전자 메일을 사용하십시오.이제 이메일 기능이 작동하려면 확인이 필요하다. -Kmf164 (토크 기여) 03:37, 2006년 3월 3일 (UTC)

확인했는데 왜 매번 페이지뷰마다 바보 같은 공지가 계속 뜨는지 모르겠어.없애버려!—마이클 Z. 2006-03-03 03:39 Z

사용자:Mzajac/monobook.css:

#이메일 { display:display; }

이렇게 하면 고시가 제거된다. -Kmf164 (토크 기여) 03:51, 2006년 3월 3일 (UTC)

하지만 도대체 내가 이메일 메시지를 확인하는 이유가 뭘까?감시된 페이지에 대한 회신, 사이트 업데이트 등에 대한 알림 표준만?료코샤 05:39, 2006년 3월 3일 (UTC)

아니, 실제로 누군가가 당신의 대화 페이지에서 이 사용자 링크를 클릭할 때.당신은 당신의 감시목록의 페이지 변경이나 사이트의 변경에 대해 통지 받지 않는다. 그것은 다른 사용자에 의해 발생한 통신만을 위한 것이다.Titoxd^{(?!? - help us)} 07:01, 2006년 3월 3일 (UTC)

이거 본 사람 또 있어?이것이 더 크고 아름다운 것을 향한 발걸음이 될 수 있을까?

메, 오랫동안 1.6의 특징이었어.:) 롭 처치 (토크) 18:51, 2006년 3월 3일 (UTC)

1단계에서 더 큰...Titoxd^{(?!? - help us)} 21:21, 2006년 3월 3일 (UTC)

내가 보고 있던 것은 :P — 일리야네프 (Talk) 19:33, 2006년 3월 4일 (UTC)

그래, 그런가?—야간(?) 16:25, 2006년 3월 10일 (UTC)

자세한 내용은 위의 "SpamCop에서 블랙리스트에 올린 메일 서버"를 참조하십시오.—스티브 서밋 (토크) 02:19, 2006년 3월 4일 (UTC)

질문이 하나 있다:우리가 가지고 있는 모든 이메일 주소에 대한 이메일 확인이야?내 계정(하아레츠에서 포드사 물건에 이르기까지)이 쇄도하는 스팸 때문에 s******를 주고 있는 핫메일 주소가 있는데, 한동안 G메일 계정을 확인하지 못했다.아니면 단지 위키백과 이메일 때문일까?나를 혼란스럽게 했구나. -다니엘 블랑쳇 17:21, 2006년 3월 11일 (UTC)

네, 여기서 말하는 것은 위키피디아에서 당신이 위키피디아 기본 설정에 입력한 이메일 주소를 확인하려고 시도하고 있는 겁니다.이는 사용자의 다른 전자 메일 주소 또는 다른 발송 사이트에서 사용자의 전자 메일 주소를 사용하는 것과 관련이 없다.—Steve Summit (대화) 12:59, 2006년 3월 12일 (UTC)

테이블 '블롭스'가 가득 차 있다.

이 편집이 이 페이지를 파괴하지 않기를 바라지만, 여기 거래가 있다.위키백과를 편집하고 있었는데:샌드박스/워드 협회(Sandbox/Word Association), 그리고 내 편집이 저장되었을 때, 나는 "이 페이지는 아직 존재하지 않는다"라는 메시지로 옮겨졌다.오류가 있다는 것을 알고 브라우저 캐시를 지우고 페이지를 다시 로드했다.그리고 나서, "Error in numRows():테이블 '블롭스'가 가득 차서 횡설수설하고 있다.나는 돌아가서 편집본을 다시 붙이려고 했지만 여전히 주사위는 없었다.그리고 나서 나는 이전 버전의 페이지로 되돌아가려고 했지만, 단지 "테이블 블럽" 메시지의 더 많은 변형들을 얻기 위해서였다.뭐가 좋은지 아는 사람?— BrianSmithson 14:16, 2006년 3월 13일 (UTC)

나는 간신히 14:01 UTC까지 그리고 14:02 UTC까지 갈 수 있었다.그 결과 편집 자체가 공백으로 나타나지 않았음에도 불구하고 여러 개의 빈 편집 상자가 나타났다.가끔, 디프가 작동하기도 하고, 때로는 "노 페이지" 메시지를 보여주기도 했어.이상하다. -스플래시^talk 14:36, 2006년 3월 13일 (UTC)

이 문제는 아직 해결되지 않았는가?그것은 여러 페이지에 영향을 미쳤다.++Lar: t/c 17:43, 2006년 3월 13일(UTC)

이것은 지금 이론적으로 정해져 있다.영향을 받은 서버는 다시 제형으로 복구되었다(대부분, srv33에 대한 일부 수정은 여전히 해야 하지만 자동 폴백과 함께 투명하게 작동해야 한다).그리고 나는 풀백 코드에 있는 버그를 고쳤는데, 그것은 신비한 백지 상태의 원인일 가능성이 있다.

여전히 '그런 페이지 없음' 메시지를 표시하는 캐시된 페이지가 있을 수 있다.필요한 경우 삭제 링크를 사용하여 삭제... --Briion 23:04, 2006년 3월 13일(UTC)

철자 수표

페이지 미리보기에 철자 검사 옵션을 포함시킬 수 있는가?자동 수정은 없지만, 위키피디아가 잘못 발음될 수 있는 단어들을 강조할 수 있다면 좋을 것이다.--God Ω War 16:56, 2006년 3월 12일 (UTC)

현실적으로 말해서, 거의 확실히 그렇지 않지만, 파이어폭스 2 (곧 알파 I believe)는 철자 검사기를 포함할 것이다.마틴 20:41, 2006년 3월 12일 (UTC)

위키백과 참조:마을 펌프(매년 제안)#페이지 편집 시 체커 말하기.식목 20:48, 2006년 3월 13일 (UTC)

감시 목록 기본 설정 - 기본 설정 3일로 설정

내 워치리스트는 약 1400페이지에 달하는데, 12시간이라는 시간대로 디폴트 상태가 유지되기 때문에 3일 동안 계속 클릭해야 하는데, 그게 짜증나.어쨌든, CSS 등에 나의 워치리스트의 길이에 상관없이 이것을 변경하고 나의 디폴트를 3일로 설정할 수 있는 것이 있는가?앞으로 이 모든 트윗을 하지 않고 이것을 실행할 계획이 있는가?엘르 ^{à jamais}(Be eudimonic!) 01:41, 2006년 3월 3일 (UTC)

흥미로운 특집 요청이 될 수 있을 것 같아.롭 처치(토크) 18:52, 2006년 3월 3일 (UTC)

나는 해결책이 3일 파라미터를 포함하도록 워치리스트 링크를 수정하는 자바스크립트일 것이라고 생각한다.— 매복 사령관 22:09^(Talk), 2006년 3월 3일(UTC)

제 해결책은 [9]에 직접 연결하여 브라우저의 작업 표시줄에 해당 링크를 연결하여 그 가치가 무엇인지를 확인하는 것이었습니다.'내 감시 목록'을 치는 것보다 더 빨리 사용하는 거야, 어쨌든...심그레이토크 12:25, 2006년 3월 4일 (UTC)

아, 그건 내 집 컴퓨터에는 효과가 있지만, 내가 정기적으로 사용하는 공용 컴퓨터에는 효과가 없어.엘르 ^{à jamais}(Be eudimonic!) 03:52, 2006년 3월 7일 (UTC)

테스트[{{fullurl:Special:Watchlist days=3&hideOwn=1}} My watchlist]
옴니플렉스 03:44, 2006년 3월 13일 (UTC)

위키백과에서 이것들을 사용할 수 있을까? 네임스페이스?

위키백과 네임스페이스에 있는 페이지의 메뉴에 다음 아이콘 중 일부를 사용하고 싶지만, 계속 진행하기 전에 그렇게 하는 것의 합법성에 대한 정보를 추적해야 한다.이러한 아이콘에 대한 라이센스, 저작권 및 상표권에 대해 무엇을 알고 있는가?

이미지:Crystal Clear 앱 mac.png - 이 페이지에는 저자의 허락을 대충 번역하는 링크가 포함되어 있다.비록 구별하기는 어렵지만, 번역이 꽤 거칠기 때문이다.

이미지:파인더 아이콘.png 이미지:페이지 아이콘.png 이미지:Apple Dictionary Icon.png 이미지:ICal 아이콘.png 이미지:IPhoto 아이콘.png 이미지: Apple iDisk 아이콘.png 이미지:ISync icon.png

비록 이 아이콘들은 상표 있는 프로그램에서 나온 것으로 보인다.그래서 나는 그것들이 페이지의 메뉴 항목으로 표시될 수 있는지 여전히 확신할 수 없다.이러한 아이콘을 법적으로 어떤 용도로 사용할 수 있는지 명확히 하는 정보를 추적하는 데 도움이 될 수 있다면 어떤 도움을 주더라도 감사하겠다. --시작하십시오! 2006년 3월 15일(UTC)

아니, 그건 공평하게 사용하는 이미지니까.해당 링크와 WP를 모두 참조하십시오.FUP#Policy, 특히 항목 9.그것들은 그들이 묘사하는 것에 관한 기사들(기사 공간을 의미함)에만 사용될 수 있다.여기에 포함, 그래서 디인라인을 그렸다. -스플래시^talk 16:34, 2006년 3월 15일 (UTC)

브라우저 글꼴 변경 오류

무슨 일이 있었는지 잘 모르겠어, 트랙볼로 이상한 짓을 한 것 같아.갑자기 등장한 위키피디아와 위키피디아는 모두 작은 글씨체(볼드체로 보이지 않고 읽기 어렵다)처럼 보이는 형태로 전시되고 있다.내가 무슨 짓을 했는지 아는 사람...어떻게 고칠까?RJFJR 01:00, 2006년 3월 15일(UTC)

이제 나아진 것 같아.나는 무슨 일이 일어났는지, 무엇을 고쳤는지 모른다.RJFJR 01:22, 2006년 3월 15일 (UTC)

대부분의 브라우저는 보기, 텍스트 크기, 옵션을 가지고 있으며 키보드와 마우스 바로가기도 하다.Xaosflux _CVU/ 03:32, 2006년 3월 15일 (UTC)

기사 개수에 리디렉션이 포함되어 있는가?

이에 대한 설명서에 대한 링크를 제공하십시오.감사합니다, --시작! 2006년 3월 14일 04:02 (UTC)

어떤 기사가 셀까?「한 위키링크 포함」, 「200바이트 이상 길다」, 「두 개의 신라인 포함」, 「한 개의 쉼표 포함」 등 「기사」를 구성하는 것을 결정하는 방법에는 여러 가지가 제시되어 있다. --Carnildo 05:03, 2006년 3월 14일(UTC)

1면에 있는 것은 불분명한 페이지가 포함되어 있지만 그렇지 않다.--채리꽃나무 11시 20분, 2006년 3월 14일 (UTC)

특별 참조:통계 및 위키백과:무엇이 물건인가.—Steve Summit (대화) 14:24, 2006년 3월 14일 (UTC)

아니오. "Articles"는 기본 네임스페이스에 있고 리디렉션되지 않는 페이지로 정의된다.또한 문자열 "]"도 포함해야 한다.최소 크기 임계값이 있다면 즉석에서 기억하지 못하지만, 나도 그렇게 생각하지 않는다. 86.134.49.239 22:10, 2006년 3월 14일 (UTC)

도움말 - 포털 코드

포털 템플릿 논리가 어떻게 작동하는지 이해하려는 이유는 나만의 미디어위키에 복사하고 싶기 때문이다.나는 미디어위키 1.5.0을 실행하고 있다.[10]의 논리를 이해하려고 노력하는데, 여기에는 {{fullurl}}이라는 템플릿을 초월하는 듯한 모습이 담겨 있다.그러나 그러한 템플릿은 존재하지 않는다.나는 "fullurl"이 어디에 정의되어 있는지 알 수 없다.제가 무엇을 빠뜨리고 있나요?고마워요.니콜스르 22:11, 2006년 3월 13일(UTC)

{{fullurl}}}은(는) 읽고 있는 페이지의 URL을 제공하는 MediaWiki 소프트웨어의 최신 버전에 내장된 변수다.1.5.0에 나오는지 확실하지는 않지만, 최신 안정 버전은 1.5.7로 보안 수정이 상당히 많이 들어 있다.Titoxd^{(?!? - help us)} 23:15, 2006년 3월 13일 (UTC)

{{fullurl}}}은(는) 2006년 3월 14일(UTC) 1.6 borgx 00:27에서만 사용 가능한 것으로 알고 있다.

즉시 MediaWiki 1.5.7로 업그레이드하십시오. 1.5.0에는 여러 보안 취약성 및 주요 버그 수정이 포함되어 있다.

그렇긴 하지만, 풀루럴 변수는 MediaWiki 1.6. 86.134.49.239 22:07, 2006년 3월 14일(UTC)에 있는 파서의 특징이다.

SUBPAGENAME 등...

암호에서 "새로운" 마법의 단어를 찾았어이번에는 SUBPAGENAME, 현재 하위 페이지의 이름을 반환한다.예를 들어 {{SUBPAGENAME}}은(는) 여기에서 "Archive O"를 제공한다(여기서는 페이지 이름과 동일).페이지가 대신 위키백과인 경우:Foo/Bar, {{SUBPAGENAME}}이(가) "Bar"를 반환한다.

또한 나는 문법과 복수 키워드가 무엇에 쓰이는지 알아냈다.

문법

영어 위키백과는 아무 것도 하지 않지만, 구문은 {{gmar:genic Foo}이며, 여기서 "Foo"로 표현될 것이다.

복수형

단순히 첫 번째 매개 변수를 여기서 반환하면 카운트는 1이다(다른 위키백과에도 세 번째 매개 변수가 있을 수 있음).예: {{plural:count wordform1 wordform2}}: "wordform2" 제공. 2006년 3월 12일 (UTC)

그것은 새로운 것이다, 나는 위키피디아-l 86.134.49.239 22:05, 2006년 3월 14일 (UTC)에 대한 요청에 대한 응답으로 지난주에 그것을 추가했다.

범주 정렬 빈 버그

범주 분류 공백 [[... ]]이 많은 항목이 있는 경우 다음 200은 나타나지 않는다.마찬가지로, 0-9로 점프한 다음 이전 200을 시도하면, 처음부터 다시 페이지를 넘기지 않는다.그래서 문제는 양쪽 방향이다.범주에서:가능성을 가지고 리디렉션하면 문제를 볼 수 있다.몇 달 동안 이런 식으로 존재했으니까, 개발자들이 볼 수 있을 때까지 이것을 고치지 말아줘!

예, 템플릿의 잘못된 범주인 것으로 알고 있음:R - 10년(토크 히스토리 링크 감시 로그 편집).그러나 다시 말하지만, 몇 달째 그런 식이었으니, 시험 삼아 내버려 두어라.범주에서 동일한 6,000개 이상의 진입 버그를 만든 4개의 템플릿에서 이미 문제를 해결했다.인쇄할 수 없는 리디렉션.그래서 나는 그것이 일회성인지 아닌지를 판단하기 위해 더 많은 예시를 찾고 있었다.

어쨌든, 조금만 더 조심해.관련 버그질라 항목을 찾을 수 없었고, 오늘 늦게 집에 도착하면 거기에 게시할 것이다. --윌리엄 앨런 심슨 17:46, 2006년 3월 12일 (UTC)

버그 5241에서 보고됨. --윌리엄 앨런 심슨 12:52, 2006년 3월 13일(UTC)

버그 #4912. 86.134.49.239 22:17, 2006년 3월 14일(UTC)의 중복으로 표시됨

기본 페이지 초안

안녕. 페이지 제목이 어떻게 생겼는지 궁금했어(위키피디아:위키프로젝트 사용성/메인 페이지)가 맨 위에 나타나지 않는다.고마워, 샤르드소프메탈 17:10, 2006년 3월 11일 (UTC)

그들은 내가 믿는 바로는 제목 위에 놓인 DIV 섹션을 사용했다.하지만 그것은 의문을 제기한다: 타이틀 영역을 억압하는 명령이 있다면 좋을 것이다.__NOTITLE__?또는 __NOBANNER___(이름은 중요하지 않은 것 같지만, DIV 트릭을 사용하여 물건을 옮기는 것을 피할 수 있도록 메인 페이지에는 기능성이 좋을 것이다.AFAIK는 어떠한 부정적인 방법으로도 착취할 수 없을 것이다(토론/편집/역사/등등의 버튼을 숨기지 않을 것이고, 파괴주의의 한 형태로서 나는 그것이 꽤 빨리 되돌아 올 것이라고 확신한다(봇들은 가능하면 _NOTITLE_;;;)—Locke Cole • t • c 01:22, 2006년 3월 12일 (UTC)

IIRC, 실은 미디어위키:모노북.js에 있다.æle 12 02:18, 2006년 3월 12일 (UTC)

꽤 쓸모없고 반정보적인 일을 하기 위해 꼬리표를 붙이는 것이 무슨 소용이 있겠는가?86.134.49.239 22:04, 2006년 3월 14일(UTC)

블록 로그 항목을 제거하는 중

나는 행정관이다.내가 사용자를 차단하러 갔을 때 실수로 개인 이메일 주소를 포함했어.항목은 다음과 같다.

1. 15:00, 2006년 3월 7일, 우후키티는 유효기간이 90분인 "헤들리다운(등록금)"을 차단했다(NLP. Katefan0 <(EMAIL DELETED)>의 시민성 규칙 위반으로 차단).

항목의 전자 메일 부분이 어떻게든 제거될 수 있을까?아니면 실수였기 때문에 전체 엔트리는? --Woohookity^{(cat scratches)} 17:34, 2006년 3월 10일 (UTC)

정말 여기에 주소를 포함했어야 했어?~MDD4696 22:59, 2006년 3월 10일(UTC)

이것보다 더 두드러진 곳에 물어볼 필요가 있다! 86.134.49.239 22:25, 2006년 3월 14일 (UTC)

개발자가 불쾌한 요약을 제거할 필요가 있다.

개발자가 마리안 레제프스키와 마리안 레제프스키의 삭제된 역사에서 기분 나쁜 요약을 제거해 줄 수 있을까?/정리반달은 개발자 접근 권한이 없는 사람들에 의해 제거될 수 없는 매우 불쾌한 편집 요약을 사용했었다.고마워. --Ixfd64 10:23, 2006년 3월 10일 (UTC)

여기보다 더 눈에 띄는 곳에 물어봐야 해.그것은 페이지의 맨 위와 가이드라인에 개발자들이 이것을 읽을 의무도 없고 보장도 없다고 명시하고 있다.86.134.49.239 22:00, 2006년 3월 14일(UTC)

검색엔진이 왜 이렇게 형편없어?

'비트토렌트'를 입력하면 한 가지 결과를 얻는다. Kratos Aurion. WTF? — 67.40.249.122(대화 • 기여)가 추가된 선행 미서명 코멘트

왜냐하면 토렌트는 r이 2개 있기 때문이다.드래곤스 05:00 2006년 3월 2일(UTC)

그리고 '크라토스 오리온'은 하나밖에 없어?그럼 비토렌트 대신 크라토스 오리온을 얻는 거야?다시 한번, WTF? — 67.40.249.122가 추가된 선행 부호 없는 의견(대화 • 기여)

왜냐하면 그 글에는 '비트'와 '토렌트'(게임의 장소인 토렌트 포레스트에 분명하게 거부)라는 단어가 모두 담겨 있기 때문이다.당신이 철자를 썼듯이, 그것은 분명히 두 단어를 사용한 유일한 글이었다.드래곤즈 항공 05:18, 2006년 3월 2일 (UTC)

그거 정말 짜증나지 않니?내 말은, 적어도 비트코렌트에 잘못된 철자를 입력하는 누군가가 전혀 관련이 없는 컴퓨터 게임 대신 그것을 원했을 가능성이 있다는 것을 말해줄 수 있는 방법이 없을까?— 67.40.249.122(대화 • 기여)가 추가된 선행 미서명 논평

개발자들이 DWIM(Do What I Mean) Technology(Do What I Mean)에서 24시간 일하고 있을 겁니다.Boinger 14:53, 2006년 3월 2일 (UTC)

또는 좀 더 기술적인 용어를 사용하기 위해 퍼지 문자열 검색.워저빌 15:14, 2006년 3월 2일 (UTC)

검색엔진 고치는 사람 있어?어떻게 하면 고칠 수 있을까?새로운 버전을 출시할 계획이 있는가?— 67.40.249.122(대화 • 기여)가 추가된 선행 미서명 논평

사실 그렇지 않아요.그렇게 하는 것은 엄청난 시간과 노력이 들 것이다.구글이나 야후와 달리 우리는 상근 개발자 몇 명밖에 없는데, 그들의 첫 번째 관심사는 검색 알고리즘이 아니다.우리가 가진 자원으로 몇 년이 걸릴 일을 말하는 거잖아좋겠지만 지금 우리가 할 수 있는 일이 별로 없어.랄315 (대화) 06:23, 2006년 3월 2일 (UTC)

오픈소스 프로젝트로 만드는 건 어때?확실히, wp만큼 인기가 있는 만큼, 그것을 코드화할 자원봉사자들이 있을 것인가?내 말은, 이미 그것보다 더 나은 os search alg가 있다는 거야.— 67.40.249.122(대화 • 기여)가 추가된 선행 미서명 논평

검색 엔진은 오픈 소스입니다; Luke, Source에 다이빙해서 사용. --Briion 06:34, 2006년 3월 2일(UTC)

개발 로드맵이 있는가?— 67.40.249.122(대화 • 기여)가 추가된 선행 미서명 논평

아헴, 구글은 이미 우리를 위해 그것을 고쳤으며, 구글 질의 상자에 "bit torent site:en.wikipedia.org"을 입력하기만 하면 원하는 것을 얻을 수 있을 것이다 [11].이거 훌륭하지 않아?문제 해결!다시 백과사전 쓰기. --Vsion 14:22, 2006년 3월 2일 (UTC)

빠른 해결책은 "구글을 사용하여 위키백과에서 이 용어를 검색할 수 있다"라는 검색 결과 페이지에 링크를 추가하는 것일 수 있으며, 그것은 사이트:en.wikipedia.org 검색이 될 것이다.그냥 아무렇게나 생각...와저빌 14:34, 2006년 3월 2일 (UTC)

또는 사용자가 맞춤법을 올바르게 입력하도록 권장할 수 있으며...어쨌든 미디어위키 검색을 사용할 수 없을 때마다 구글 검색 상자가 뜬다.(적어도 나에겐 그렇다) 2006년 3월 2일 15:39, 2

왜 켜지는 거지?미디어위키 검색에는 장점이 없고 단점도 많다.

퍼리너로서 나는 퍼지 검색을 특징으로 하는 사이트들을 고맙게 생각한다. 정확한 철자는 우리가 원어민이 아닌 사람들을 위한 추가적인 장애물을 가지고 있기 때문이다.퍼지 검색은 오랫동안 연구되고 출판된 주제다; 레디 코드와 거의 레디 사이코드를 이용할 수 있다.하지만 성능은 좀 문제가 있다.일반적으로 퍼지 알고리즘은 더 무거운 검색을 필요로 하지만(검색 공간을 제거하기 위해 경험적 접근법을 사용할 수 있다) 적절하게 색인화된 데이터베이스에서는 정확한 일치가 빠르다.워저빌 16:01, 2006년 3월 2일 (UTC)

이 경우 "비트토렌트"에서 "비트토렌트"로 리디렉션이 존재하지만 검색 결과에는 나타나지 않는다.그러나 "비트 토렌트"를 검색하면 처음 두 결과가 "비트토렌트"로 리디렉션된다.그건 말이 안 돼. --어떤 사람은 2006년 3월 2일 15:59, 2일(UTC)

검색 지수가 심하게 시대에 뒤떨어져 있다.비트토렌트가 포함되지 않은 이유일 것이다.네 말이 맞아, 하지만 더 나은 검색 도구가 필요해.—일마리 카로넨 (대화) 16:45, 2006년 3월 2일 (UTC)

고마워 - 구글 검색은 잘 돼!우리 그거로 완전히 바꿔보는 게 어때?무례하게 굴고 싶지는 않지만, 찾아다니는 것은 창피한 일이다.세상에는 더 좋은 것들이 많이 있지만, 구글이 가장 쉬운 것 같다.적어도 다른 구글이 어디에 있든지 구글을 사용할 수 있는 옵션을 두어라.내 경우는, 전화로 누군가가 나에게 조금 토렌트를 체크해 보라고 했다.그래서 나는 위키피디아에 그것을 타이핑하고, 그것을 잘못 발음하고, (그렇다, 나는 그렇다, 그러나, 많은 사람들도 그렇다) 그리고 다음에 무엇을 해야 할지 전혀 모르는 완전한 헛소리를 듣게 된다.물론 현실에서는 구글에 입력해서 내가 잘못 말하고 있다는 것을 깨닫고 소프트웨어의 메인 페이지를 얻지만, wp의 seach가 실제로 작동한다면 좋지 않을까?

내가 아는 한, 구글은 여전히 그들의 지수를 만들기 위해 웹 기어가기에 의존하고 있다.이것은 위키피디아에 관한 구글 검색은 항상 시대에 뒤떨어지고 모호하고 거의 연관되지 않은 주제들을 간과할 수 있는 잠재력을 가지고 있다는 것을 의미한다.따라서 우리는 구글에만 의존할 수 없다.또한, 일부 사람들은 한 상업적 검색 공급업체만을 후원하는 것에 문제가 있다.궁극적으로 검색 개선은 아마도 내부에서 이루어졌을 것이다.지능적인 퍼지 논리를 제공하는 것은 칭찬할 만한 목표지만, 검색의 계산적 복잡성을 극적으로 증가시킨다.그것이 불가능하게 만들지는 않지만, 아마도 검색이 사이트의 나머지 부분을 잠식하지 않고 멋있게 만들어지려면 검색 전용 하드웨어가 필요하다는 것을 의미할 것이다.드래곤스 18:37, 2006년 3월 2일 (UTC)

음, 바로 위에 쓰여 있는 것은 검색 색인이 아주 시대에 뒤떨어져 있기 때문에 위키피디아 검색은 확실히 실시간 데이터에서 작동하고 있지 않다는 것이다.구글로 바꾸는 것이 좋은 선택이라고 생각하지만, 다른 것을 선택할 수 있는 맞춤화가 있어야 할지도 모른다.--Myk 06:36, 2006년 3월 3일(UTC)

학교에 다시 가서 불평을 그만하면 되는 일이잖아.물론 개발 자금을 지원할 의사가 없다면?--MatthewFenton 16:25, 2006년 3월 2일(UTC)

흠, 그건 깨졌으니까, 나는 그런 무례함이 꼭 필요하다고 생각하지 않아.나는 라디오에서 그에 대한 이야기를 듣고 타리크 라마단을 찾고 있을 뿐 철자를 모르는 타리크 라마단을 타이핑했다.나는 오직 한 가지 결과를 얻었다 - 1998년 1월 4일 릴리즈네 대학살의 윌라야.어떻게 그게 효과가 있다고 말할 수 있어?위대한 정의를 위하여.2006년 3월 2일 16:37(UTC)

어쩐지 나는 연간 60억 달러의 매출과 엄청난 시가총액을 가진 구글이 10만 대의 서버를 가지고 그것을 실행할 수 있는 모든 퍼즐로직 소프트웨어를 제공할 수 있다는 것에 놀라지 않는다.어쩐지 사람들이 무료의 비영리 위키피디아가 그것을 관리할 수 있기를 기대하는 것이 놀랍다.한편, 억만장자들이 위키피디아에 자금을 대기 시작할 때까지, 우리는 정확한 철자에 의존하거나 오타가 원치 않는 결과를 만들어 낼 것이라는 사실에 대처해야 할 것이다.RGTraynor 17:03, 2006년 3월 2일(UTC)

그럼 왜 작동하지 않는 걸 끄지 않는 거야?위대한 정의를 위하여.2006년 3월 2일 17:34(UTC)

검색 엔진은 정말 쓰레기야. 그리고 나는 그것을 개선하는데 수반되는 어려움은 멀리, 훨씬 더 과장되어 있다고 생각해.그래, 완벽하게 하기 위해서는 몇 년이 걸릴 수도 있지만, "충분히 잘" 하려면 정규 표현을 수정하는 방법을 아는 사람에게 몇 주밖에 걸리지 않아야 해. (내가 어떻게 'feew weeks'의 수치에 도달하게 되었는지를 수치화하라고 요구하지 말고, 당신이 "년" 수치를 뽑은 바로 그 장소에서 뽑았지.나도 비슷한 검색어를 썼어.하지만, 여기서 불평하는 것이 답이 아니다...프로그래밍에 대해 아무것도 모르는 사람들이 요청을 거절하지 않고도 프로그램적 개선을 요청할 수 있는 곳이 있을 겁니다.크로우 17:00, 2006년 3월 2일 (UTC)

나는 장애물이 과장된 것 같다는 것에 동의한다.이 일에 대한 충분한 일을 하는 것에 대한 중압감은 이미 끝났다.그런 면에서 학생들에게 주어질 수도 있는 프로젝트다.사실, 그렇다, 사람들은 위키피디아가 세계 수준의 브라우저를 출시하고 오픈오피스가 기능할 것으로 예상하는 것과 같은 방식으로 위키피디아가 그것을 관리하기를 기대한다.그것은 무례하고 배은망덕한 것이 아니라 사실만을 말하는 것이다.원래의 포스터는 어떻게 도와야 할지 묻고 있는 것 같았고, 그것을 하기 위한 구체적인 내용은 어디에도 주어지지 않았다.위대한 정의를 위하여.2006년 3월 2일 17:34(UTC)

원래 포스터는 실제로 "어떻게 하면 고칠 수 있을까?"라는 말을 사용했다. - 그저 불평만 하는 것이 아니라, 도움을 주기 위해 꽤 모호하게 제공했다.나는 이 일을 할 수 있는 코딩 기술을 가지고 있지 않지만 퍼지 검색을 가능하게 하는 일에 대해 +1을 투표할 것이다.나는 또한 선의의 행동을 하고 그가 도울 수 있는 곳을 향해 원래의 포스터를 가리킨 사람들에게 +1표를 던지겠다. 단지 "학교로 돌아가서 불평을 그만둬야 하는 것이 효과가 있다."- 별로 도움이 되지 않는다.지적된 바와 같이, 당신은 대화나 라디오에서 어떤 단어를 들을지도 모르고 철자를 모를지도 모른다. 그리고 영어가 모국어인 사람들에게는 융통성이 때때로 도움이 될 것이라고 확신한다.Jamse 18:15, 2006년 3월 2일 (UTC)

사전이 아니라는 것은 그것이 작동하지 않는다는 것을 의미하지 않는다. 그것은 철자 검사도 아니고, 또한 그렇게 되어서는 안 된다.찾는 것의 철자를 쓸 수 없다면, MatthewFenton 17:58, 2006년 3월 2일 (UTC) 사전에서 확인하십시오.

오, 제발.벌레가 아니라 특징이라고?!물론 그것은 일반적인 오언을 포착하고 가능한 일치점을 제시할 수 있어야 한다.특히 아랍어 이름에서는 번역이 항상 표준이 되는 것은 아니다.1998년 1월 4일 타리크 라마단을 요청했을 때 나는 릴리잔의 윌라야를 원한다고 제안하는 것은 말도 안 된다.위대한 정의를 위하여. 2006년 3월 2일 18시 10분 (UTC)

철자가 어떻게 되어 있는지 모른다면 사전에서 어떤 것을 확인하기가 어려울 수 있다 :-) 학교에 가는 것은 세계 인구의 대부분에게 실용적인 선택이 아닐 수도 있다.특히 편견 없는 정보가 가장 절실하게 필요한 부분은 더욱 그렇다."영어 철자를 배우는 것, 게으른 뼈"는 그들을 돕는 가장 건설적인 접근법이 아니다.

사전에는 없는 개념이 많다(속성 있는 이름이 떠오른다).또한 영어에 대한 번역이 다른 많은 단어들이 있다 - 모음 번역과 같은 것들이 명확하지 않기 때문에 아랍어의 철자가 다르다는 것을 목격한다.

위키피디아는 콘텐츠에 대한 많은 자원봉사의 도움을 받을 수 있었다.이 실의 코멘트로부터 나는 자원봉사 프로그래머들이 거의 그 수준으로 동원되지 않았다는 것을 감지하고 있다.자원봉사 프로그래머는 확실히 존재한다. 자유로운 소프트웨어 움직임을 보라.워저빌 18:19, 2006년 3월 2일 (UTC)

검색 엔진을 수정하는 것은 문제지만, 빠르고 건강한 서버 그리드를 모니터링하고 유지 관리하는 것, 많이 요청된 문서 유효성 검사 및 단일 로그인 기능 등과 같은 다른 많은 것들이 있다는 것을 기억하십시오.하지만 요청은 많고 코딩은 거의 없다.그렇긴 하지만, 만약 여러분 중 누구라도 이것을 어떻게 고칠 지에 대한 단서를 가지고 있다면, 여러분은 Bugzilla에게 PHP 패치를 제출하는 것을 환영한다.Titoxd^{(?!? - help us)} 18:25, 2006년 3월 2일 (UTC)

메인 빌리지 펌프에서 복사: '빌리지 펌프'를 검색해보면 마을 펌프로 들어갈 수 없다는 사실을 아는 사람이 있는가?검색에 입력했더니 관련 경기도 없고 아무 것도 나오지 않았다.'the'가 있든 없든 사람들이 들어갈 수 있도록 바꿔야 한다고 생각한다.의사 익명 03:34, 2006년 2월 28일 (UTC)

사실, 나는 검색 상자가 위키피디아에서 어떤 것을 찾는데 정말 형편없다는 것을 발견했다.두 가지 요인은 이것을 악화시킬 수 있다: 거기서 결과를 얻기 위해 당신이 확인해야 할지도 모르는 체크박스와 "위키피디아:"로 제목을 시작한다면 그것은 위키피디아 네임스페이스에서 검색하기 위해 힌트를 얻는 대신에 콜론을 포함한 "위키피디아:"로 시작하는 단어를 찾을 것이다.r스피어 / ɹəədsɹ 18:33, 2006년 3월 2일 (UTC)

사실, 나는 검색 상자가 어떤 것을 찾는데 정말 형편없다는 것을 발견했다.위대한 정의를 위하여.2006년 3월 2일 18:49(UTC)

내 추측으로는 개발 인력이 없는 것도 아니고 서버도 없는 것 같아.지금은 문자 그대로의 전체 텍스트 검색 지수를 업데이트할 자원도 없는데, 어떻게 개선해야 하나?(내 생각에는 광고가 해답이지만, 그게 인기 없는 감정이라는 걸 깨달았어.) —시뮬레이션(대화 • 기여) 01:39, 2006년 3월 3일 (UTC)

나는 그것에 대해 모른다 - 나는 더 많이 검색할 수 있고 더 똑똑하게 검색할 수 있는 짐승 같은 힘에 대한 것이 아니라고 생각한다.예를 들어 지금 검색엔진은 글과 제목을 모두 텍스트로 검색해 정확한 일치점을 찾는 것 같다.나는 그것에 많은 가치가 있다는 것을 볼 수 없다.제목을 모호하게 검색하는 것이 더 빠르고, 서버 시간이 덜 소요되며, 더 유용한 결과를 반환할 수 있다.위대한 정의를 위하여.02:30, 2006년 3월 3일 (UTC)

사실, 서버가 걱정된다면 검색 엔진을 끄고 야후와 구글을 통해 무료 검색을 받자.그들의 검색은 더 좋고, 무료하며, 우리는 검색 엔진이 고장 났을 때 그것들을 사용한다.위대한 정의를 위하여.02:33, 2006년 3월 3일 (UTC)

광고에 대한 증오를 공유하라.'애드 미러'는 어때?사이트의 부하는 광고와 함께 미러링한다.광고 자금 미러(GFDL 하에서는 괜찮다)를 운영하고 수익금을 WP에 기부하는 것을 목적으로 하는 별도의 재단을 설립하는 것은 어떨까?위키피디아가 그렇게 하지 않을 것이기 때문에, 아무도 그렇게 하지 않을 것이다.그것을 싫어하는 사람들은 그것을 싫어할 수 있다.무슨 상관이야, 그건 합법일 거야.그리고... 3. 이윤!위대한 정의를 위하여.2006년 3월 2일 18:38(UTC)

위 Titoxd의 언급에 따르면 당신은 단지 bugzilla에 패치를 제출할 수 있다: 당신은 우리의 bugzilla에 패치를 제출하지 않을 것이다. 당신은 Lucene 이슈 Tracker에 패치를 제출할 것이다.검색 백엔드는 MySQL이나 PHP와 마찬가지로 외부 오픈 소스 프로젝트다.여기서 불평하는 것은 별로 의미가 없다.루센은 위키피디아가 존재했던 것보다 더 오랫동안 활발한 개발을 해왔으며, 나는 우리가 그 당시에 엄청나게 우수한 검색엔진을 스스로 썼다고 기대하는 것은 타당하다고 생각하지 않는다. -- 팀 스타링 02:50, 2006년 3월 3일 (UTC)

팀 고마워 - 이것에 대해 얼마나 잘 알려지지 않았는지 흥미롭다.하지만 진지하게 말하는데 - 지금 우리가 하고 있는 것 보다 더 적은 작업으로 지금 우리가 이용할 수 있는 훨씬 더 우수한 대안이 있다 - 왜 그냥 그것을 끄고 야후와 구글을 사용하지 않는가?위대한 정의를 위하여.03:28, 2006년 3월 3일 (UTC)

야후와 구글은 우리의 사이트 구조(네임스페이스 등)를 읽을 수 없기 때문에 "dumb" 단어 검색만 제공할 수 있다.위키의 구조(기사공간에 대한 공통 검색 제한 등)와 작용하는 보다 유능한 검색을 하기 위해, 우리만의 검색엔진이 있다.위에서 언급했듯이, 그것은 매우 유능하고 일반화된 오픈 소스 검색 백엔드 라이브러리인 Apache Lucene을 기반으로 한다.그냥 징징거릴 생각이라면, 글쎄, 아무도 관심을 기울이지 않아도 놀라지 마.:)

또한 외부 크롤러는 오랜 지연 후에만 업데이트되는 것으로 제한된다. 현재 이는 내부 검색에도 해당되지만 업데이트 데몬의 메모리 누출 문제가 해결될 수 있는 경우 해결할 수 있다.그것은 구글이나 야후가 제공할 수 없는 것이다.

"XYZ를 입력하려고 하셨나요?"라는 퍼지 제목 검색이 가능하고 코드 안에 있지만 전체 텍스트 검색보다 수행이 느려서 현재 비활성화되어 있다.

Kate는 위키피디아에 대한 루세네 기반의 검색에 대한 개선을 위해 노력하고 있다; 만약 우리가 그 작업을 공개하는 것에 동의한다면 우리는 위키피디아의 최신 코드로 넘어갈 수도 있다.그렇지 않으면 다른 사람이 팔꿈치 기름을 넣을 성향을 가질 때까지 계속 앉아 있을 것이다. --Briion 04:11, 2006년 3월 3일 (UTC)

궁금한데, 이 재단의 누군가가 구글 검색 어플라이언스를 탐험해 본 적이 있는지, 아니면 우리가 볼 수 있는 오픈 소스가 충분하지 않은지?우리가 가지고 있는 문서 수에는 엄청나게 비싸 보이지만, 만약 그것이 우리가 효율적이고 잘 하기 위해 필요한 일을 한다면 그것은 가치가 있을 것이다.Google의 페이지와 외부 리뷰를 참조하십시오.— 캐서린\^talk 04:43, 2006년 3월 3일 (UTC)

우리는 그것이 존재한다는 것을 알고 있지만, 그것은 완전히 독점적이기 때문에 우리가 고려하고 있는 것은 아니다.재단은 상당히 완전한 오픈소스 소프트웨어 스택에서 운영하는데 전념하고 있다; 우리가 하는 일의 일부는 우리가 가진 모든 것이 복제될 수 있도록 하는 것이다. --Briion 07:37, 2006년 3월 3일 (UTC)

WP에 자주 제안되는 머신 인터페이스가 존재한다면, 구글은 그것을 사용하여 당신을 검색할 수 있고, (그것이 적절히 효율적인 "밀어넣기"를 지원했다고 가정하면) 그들의 검색을 항상 최신 상태로 유지할 수 있다.하지만 항상 실행해야 할 것들이 아주 많고 너희들이 까다로운 제약을 받고 있다는 걸 알아.— 암호고트 20:54, 2006년 3월 5일 (UTC)

고마워 브리온 - 정말 도움이 되네.만약 내가 너를 제대로 이해한다면, WP가 서버 부하를 줄이기 위해 퍼지 검색 스위치를 껐기 때문에 검색 엔진이 실제보다 이론적으로 더 낫다는 너의 말은?제대로 된 코드가 꺼져 있어서 코드를 개선해도 도움이 안 되는 겁니까?만약 그렇다면, 그것은 단지 괜찮은 검색 기능이 켜질 수 있도록 더 많은 서버를 위한 더 많은 돈의 문제일 뿐인가?통찰력 있는 답변 고마워.사용자 관점에서의 코멘트, 나는 구글을 사용하여 구글을 검색하는 것으로 넘어갔다. 단지 구글이 퍼지 제목 검색을 가지고 있기 때문이다.메인 wp 검색에서 그것을 볼 수 있으면 좋을 것이고, 그것을 사용할 수 있게 할 것이다.다시 한 번 감사드리며, 위대한 정의를 위해.2006년 3월 3일 17:44 (UTC)

빈정거림 감사드리며, 또는 사용적합성과 기능성이 이항성이 아니라는 것을 정말 모르십니까? --Briion 00:41, 2006년 3월 4일(UTC)

이 사용자가 비꼬는 것이 확실한가?그것은 나에게 전혀 명백하지 않다.— 암호고트 20:54, 2006년 3월 5일 (UTC)

흠.. 서로 징징대는 소리가 너무 심해서 토론할 때 충분한 포인트가 없어.제발, WP:AGF, WP:NPA, WP:Civiletera 등.베르드나648^T/\_C^@ 05:48, 2006년 3월 6일(UTC)

?? 빈정거릴 의도는 전혀 없고, 나는 그저 상황을 이해하려고 노력했을 뿐이다. 위에서 너무나 많은 모순된 설명이 제시되어 있었다.사용성과 기능성에 대해 무슨 뜻인지 잘 모르겠다.만약 네가 내가 'whing'하고 있다고 생각했다면 미안해 - 나는 문제가 어디에 있는지 알아내려고 했어.만약 코드에 문제가 있다면 해결책은 더 나은 코드지만, 코드는 이미 괜찮지만, 우리가 그것을 실행할 서버가 충분하지 않다면, 그것은 다른 문제다.'좋은 검색엔진을 갖기를 기대하는 것은 불합리하고 모두가 열심히 하고 있으니 비판하지 말라'는 말이 많은 것 같다.나는 그들이 열심히 일하고 있다는 것을 안다. 그리고 나는 그들이 아니라고 제안하려는 것이 아니다. 단지 엔진이 왜 내가 그것을 위해 사용하는 것에 대해 그렇게 나쁜지, 그리고 내가 무엇을 기여하기 위해 할 수 있는지를 정확히 이해하려고 노력하는 것이다.암호라면 별거 아니지.새로운 서버를 위한 돈이라면 조금 더 쓰세요.위대한 정의를 위하여.06:16, 2006년 3월 6일 (UTC)

철자가 서투른 사람들을 위한 추가 기능 없이 전체 텍스트 검색이 "무용하다"고 주장하는 것은 꽤 어리석은 짓이다. :) 검색은 유용하다.그러나 훨씬 더 유용할 수 있다. --Briion 08:06, 2006년 3월 6일 (UTC)

나는 프로그래머가 아니기 때문에 이것에 대해 잘 알지 못할 것 같다; 하지만 내 자신을 당황하게 할 위험을 무릅쓰고 나는 일시적으로 그 문제에 도움이 될 수 있는 제안을 하고 싶다.내가 보기엔 검색의 가장 큰 문제는 철자를 확인하지 않는 것 같아.그렇다면 검색 상자 위 또는 아래에 맞춤법 검사를 적용하거나 검색 결과가 10개 미만일 경우에만 맞춤법 검사 상자가 표시되도록 프로그래밍할 수 있다.철자 검사를 위해 검색을 프로그래밍할 필요는 없고 철자 검사기만 있으면 돼.너무 많으면 검색 결과가 10개 미만일 때만 검색이 맞춤법 검사를 받도록 할 수 있을까?맞춤법 검사기에 물건을 타이핑하는 것이 짜증나는 것은 알지만, 그것이 일시적인 해결책이고 인터넷 속도가 느린 사람을 위해 구글에 가는 것이 더 좋은 이유다.나는 그것이 시간이 많이 걸릴 수도 있다는 것을 알지만 나는 그렇지 않길 바란다.뭔가 조치를 취해야 해!많은 사람들이 이 웹사이트를 사용하고 있는데, 적어도 수십만 명은 안전하다고 생각해. 100명 중 1명이 철자를 쓰지 못하고 인터넷 속도가 느려지면 수천 명이 불편을 겪을 거야!철자를 못 쓰는 수만 명을 짜증나게 하는 것은 말할 것도 없고!나는 또한 우리 중 5%만이 평생 틀린 철자를 쓴 적이 없다고 해도 무방하다고 생각한다. 따라서 철자법을 배워야 한다는 제안은 불합리하다.만약 첫 번째 타이머가 위키피디아에 와서 무언가를 검색하고 아무것도 얻지 못한다면, 우리는 두 번째 타이머로 그 사람을 갖지 못할 수도 있다.그렇다, 우리는 다른 일들을 해야 하지만, 좋은 검색 상자는 우리의 최우선 과제들 중 하나일 것이다; 구글이 당신의 철자를 확인하지 않고 단지 철자법을 배워야 한다고 말해준다고 상상해 보라! (만약 그렇게 했다면 우리는 구글에 대해 들었을 것이다.그 광고는 나쁜 제안이 아니다. 만약 그것이 위키피디아를 더 좋게 만든다면, 만약 당신이 편지에 몇 개의 광고를 가지고 있는지 누가 신경 쓰겠는가?욱키피디아나 메모리알파로 가봐 광고 나쁘지 않아.씨치박스가 쓸모없거나 형편없다고 말하지 마. 많은 사람들이 그것에 열심히 노력했어! :D Phasuanonymonymous 05:38, 2006년 3월 12일 (UTC

'더볼' 검색이 왜 더볼을 찾지 못하는지 누가 설명해줄래?3월 3일에 페이지가 생성되었기 때문인가?그건 10일 전 일이잖아감사 사용자:Amram99 4:33, 2006년 3월 14일 (UTC)

앞에서 말한 바와 같이 현재 검색엔진은 즉시 업데이트되지 않는다. --Briion 07:19, 2006년 3월 14일 (UTC)

템플릿 찾기

나는 며칠 전에 FA 자격을 받은 기사를 쓰고 있어.과거에, 비록 우리 대부분은 이 기사를 동시에 나는 이 형식으로, 사용자 새로운 시스템을 활용할 가지고 거부했다 부부가 아니라, 모든 방식에서 주어진 순간, desp 그들의 마음에 드는 각주들을 입력한 이전의 모든 소스 노트"번역"<>ref>,<>/ref>, 기준 시스템 채택하였다.numeroite우리는 다른 편집자들로부터 <ref>[/ref] 시스템을 사용하도록 요청한다.문제의 당사자들이 삽입한 사용되지 않는 소스 노트의 존재는 FAS 프로세스에 기록되었고 수정되어야 했다. 이는 기사를 지명했던 당사자가 수행한 시간 소모적인 작업이다.나의 현재 관심사는 FA 지위가 달성되었고 모든 소스 노트가 올바른 형식으로 되어 있기 때문에 앞으로 이 기사에 기여하기를 원하는 사람들에게 어떻게 하면 그들이 (</ref) 시스템을 이용하여 소스 노트를 입력해야 하는지를 명확히 할 수 있을까 하는 것이다.토크 페이지에 넣을 수 있는 <ref></ref> 시스템의 사용이 요구된다는 템플릿이 있는가?감사합니다 -- Polaris999 07:32, 2006년 3월 16일 (UTC)

Cite.php 시스템에 대한 수정되지 않은 주의사항이 여전히 존재하기 때문에 현재 요구되지 않으며, 또한 요구될 수도 없다.변환할 수 없는 기사의 예는 Krasny Bor 전투(템플릿의 ref)와 프랑스 군대의 격납고(그림 캡션의 Refs)를 참조하십시오.Circeus 11:45, 2006년 3월 16일 (UTC)

MS-Word에 Wiki 페이지를 붙여넣을 때 일부 문자가 표시되지 않음...

MS Word2000에 http://en.wikipedia.org/wiki/Russian_phonology을 붙여 넣으면 많은 음성 문자가 박스로 등장한다.Windows2000pro에 추가하는 데 필요한 글꼴SP4가 보존될 것인가?Thanks, MMCohen

단어 대신 메모장에 붙여 넣으십시오.메모장은 완전한 유니코드 편집기지만, 당신의 워드 사본은 그렇지 않을 수도 있다.≈ Josi t t • @ 02:43, 2006년 3월 16일 (UTC)

이미지 엄지손가락 레이아웃이 만족스럽지 않음

(2006-03-15 14:35:56 -0800, 2006-03-15 15:07:15 -0800으로 제출된 질문에 대한 재게시입니다.)

워싱턴 파크, 포틀랜드#어린이놀이터에서 나는 세 개의 섬네일 이미지를 페이지에 걸쳐, 가급적 왼쪽, 가운데, 오른쪽 정렬로 표시하고자 한다.현재 wikitxt는

[[이미지:Pdx_washpark_childrensplayground_Elephan househouse 왼쪽.jpg 엄지손가락 센터 Elephant house popic area] [이미지:Pdx_washpark_childrensplayground_entence.jpg 엄지손가락이 어린이 놀이터 입구를 떠났다] [[이미지:Pdx washpark 어린이 놀이장 백2front.jpg 엄지손가락 어린이 놀이터 놀이장소]{{clr}}

그러나 이것은 첫 번째 이미지를 선에 그 자체로 표시한다.나머지 두 이미지는 왼쪽/오른쪽 정렬이 양호하지만, 중심 이미지 아래에는 중앙 이미지를 위한 충분한 공간이 있다.Win2k와 XP에서 IE 6.0, Netscape 8.0, Firefox 1.0 및 1.5.0.1과 거의 동일한 외관을 가진 브라우저와는 관련이 없는 것 같다.엄지손가락의 크기도 효과가 없다.이미지 참조를 왼쪽, 가운데, 오른쪽 순서로 배치하면 더 이상한 결과가 나왔다. 왼쪽은 괜찮은 것처럼 보였지만 중앙은 중앙과 오른쪽 중간에 있고 오른쪽은 그 자체로 선을 그었다.

<갤러리>를 해보았다...</노글리시>는, 그러나 그것은 이미지 썸네일을 만족스럽게 크게 만들지는 않는다.어쩌면 그것을 통제할 수 있는 방법이 있을까? (적절한 방법인 것 같다.)EncMstr 22:35, 2006년 3월 15일 (UTC)

누군가가 갤러리를 사용하기 위해 페이지를 바꿨지만, 코멘트는 없었다.이것은 즉흥적으로 의도된 것인가?

나일 수도 있다고 생각하지만, 저장하려고 할 때 서버에 문제가 생겨 최종 결과조차 볼 수 없었다.서커스 02:12, 2006년 3월 16일 (UTC)

Copyvio를 위한 소프트웨어 솔루션

나는 과거에 표절 탐지 시스템이 사용하는 알고리즘에 대해 약간의 연구를 한 적이 있다.가장 단순하고 유망한 것 중 하나는 2003년 논문 Winnowing에 설명되어 있다. PHP+SQL의 프로토타입을 구현할 수 있는 문서 지문을 위한 로컬 알고리즘.우리가 해야 할 일은 후보자들로부터 많은 텍스트들을 수집하고, 지문 데이터를 추출하면, 우리는 제출된 페이지의 어느 곳에서든 저작권이 있는 정보의 양을 거의 즉각적으로 식별할 수 있을 것이다.이는 구글 웹 서비스에 기반한 솔루션보다 상당히 확장성이 높은데, 이는 웹 서비스가 쿼리 수와 쿼리 크기에 제한을 받기 때문이다.다들 어떻게 생각해?데코 21:29, 2006년 3월 15일 (UTC)

내가 위에서 다루지 않은 한 가지 요점은 잠재적인 카피비오가 발견되면 어떻게 해야 하는가이다; 문서를 즉시 거부하는 것은 자료를 적절하게 인용하고 있거나 우연히 그와 충돌하는 사용자들에게 좌절감을 줄 수 있다.대신 이러한 변경 사항은 최근 변경 사항과 의심스러운 카피비오 부분이 디프에서 빨간색으로 강조 표시되도록 제안한다.이것은 물론 훨씬 더 복잡하게 만든다.2006년 3월 15일 데코 22:26 (UTC)

이것의 문제는 카피비오 자료의 가능한 광범위한 출처들이다: 초등학교와 중학교에 관한 기사는 종종 학교 웹사이트의 "정보" 또는 "미션" 페이지에서 복사하여 붙여진 자료들을 포함하고 있는 반면, 소수 대중 문화 인물들의 전기들은 이 인물의 홍보 홈 페이지에서 나온다.브리타니카나 엔카르타 등 집중 출처의 카피비오는 좀처럼 발생하지 않는다. --카르닐도 23:27, 2006년 3월 15일(UTC)

난 카르닐도에 동의해...나는 "표준" 텍스트라고 할 수 있는 것에서 카피비오를 찾은 적이 없다; 그것은 항상 기사의 주제와 직접적으로 관련된 비교적 작은 웹사이트에서 나온 것이다.이것은 브리태니카의 카피오스가 몰래 돌아다니지 않는다는 것을 의미하지는 않지만, 내 경험상 그들은 훨씬 더 희귀하다.신문을 보지는 않았지만, '문자 수집'에 대해 이야기하셨으니, 특정 문장을 검색하기 전까지는 잘 나타나지 않는 소규모 웹사이트의 카피비오 문제를 어떻게 해결하실지 궁금하다.Seqsea (대화) 00:03, 2006년 3월 16일 (UTC)

나는 브리태니커에서 카피비오를 찾은 적이 있다. 비록 그것이 웹사이트에서 무료로 구할 수 있는 첫 단락에 불과했지만 말이다.나는 우리 카피비오들의 99.x%가 그 대상의 공식 웹사이트나 그 대상 전용 웹사이트에서 온 것이라고 생각한다.브리태니커 등의 카피리오가 가장 위험하다고 생각하지만, 우리가 직접 경쟁하고 있기 때문이다.--벚꽃나무 00:54, 2006년 3월 16일 (UTC)

나는 사실 다른 백과사전의 카피비오들을 고려하지 않았고, 그런 취지로 아무것도 제안하지 않은 것 같다.대부분의 카피비오는 웹에서 나온다.말뭉치는 웹 크롤러를 사용하여 생성될 수 있지만, 웹이 너무 크기 때문에 사람들이 복사하기 더 쉬운 사이트로 어떻게든 표적이 되어야 할 것이다.이를 위한 한 가지 방법은 카피비오 출처라고 알려진 웹사이트 목록을 유지하는 것이지만, Seqsea가 말했듯이, 그것들은 종종 작은 주제별 사이트들이다.그래서 이건 까다롭군2006년 3월 16일 데코 01:47(UTC)

NavHead css? - 템플릿:하프라이프 시리즈

최근에 (오늘과 같은) 템플릿:하프라이프 시리즈는 더 이상 전체가 표시되지 않는다.대신 제목과 쇼/숨기기 버튼만 있으면 된다.템플릿의 버전 이력을 확인했는데, 1월 중에 변경 사항이 발생했는데, 방금 눈치 챘을 뿐인데, 최근 css에 대한 변경인 것 같아.

이것은 템플릿에는 쓸모가 없다. 예, 하프 라이프 템플릿은 부피가 너무 컸을 수도 있지만, 이것은 새로운 사람들과 다른 일반 사용자들을 위해 쉽게 탐색할 수 있도록 만들어졌다.그러나 기사 사이를 빠르고 쉽게 뛰어넘을 수 있는 방법이 지금은 숨겨져 있다.평균적인 사용자는 "쇼" 버튼을 발견하지 못할 것이고, 심지어 네비헤드를 볼 수도 없을 것이다.누가 이걸 다시 바꿔줄 수 있어?위키백과_토크에서 이에 대한 언급이 있다.WikiProject_Computer_and_video_games#What.27s_with_the_Show.2FHide.3F 여러 개의 네비브레이크가 있는 페이지가 하나만 숨겨져 있을 경우.지금은 모두 숨겨져 있고, 쓰레기야. - 한첸 05:33, 2006년 3월 15일 (UTC)

템플릿 - 뭐야!

여러 템플릿(예: 템플릿:포켓몬고메스와 템플릿:이전에 전체를 전시했던 마리오 시리즈)는 이제 기본적으로 숨겨져(붕괴) 있으며, 그 내용을 보려면 「[Show]」를 클릭해야 한다.템플릿이 아직 편집되지 않았으니 소프트웨어에 변화가 있는 게 아닐까?어떻게 템플릿이 기본적으로 컨텐츠를 표시하도록 강제할 수 있는가? -- WikidSmaht (talk) 21:03, 2006년 3월 15일 (UTC)

소프트웨어 변경이 아니라 스타일시트 변경.미디어위키처럼 보인다.모노북.css는 NavFrame 클래스로 표시된 div가 표시되도록 변경되었으며, 이 클래스와 마찬가지로 show/hide 버튼을 사용하십시오.원하지 않으면 div를 다른 클래스로 변경할 수 있다. --TreyHarris 21:31, 2006년 3월 15일(UTC)

버튼은 항상 거기에 있었지만, 기본적으로 표시되곤 했는데, 지금은 기본적으로 숨겨져 있다.왜 이렇게 바뀌었을까, 누구한테 얘기해야 할까?저 스타일시트의 역사를 보면, 1월 이후로 편집이 안 된 것 같아.그것이 문제의 원인이라고 확신하십니까? -- WikidSmaht (대화) 22:29, 2006년 3월 15일 (UTC)

아마도 우리가 각 템플릿의 기본 상태를 결정할 수 있는 것이 더 나을 것이다.기본적으로 표시는 NavFrameShow, 기본적으로 숨기는 것은 NavFrameHide와 같은 구분된 div를 만드는 것. borgx 00:47, 2006년 3월 16일(UTC)

그럴지도 모르지, 하지만 난 아직도 누가 왜 무엇을 바꾸었는지 잘 모르겠어.그리고 그 사이에 (만약에) 할 수 있는 일이 있다면? -- WikidSmaht (대화) 02:13, 2006년 3월 16일 (UTC)

나는 미디어위키를 보았다.monobook.css는 내가 위에 원점을 올렸을 때쯤에.그러나 1월 이후 그 부분에 대해서는 변화가 없었기 때문에 그것이 원인이 아니었다.원인이 실제로 무엇인지 아직 알아내지 못했는데, 엄청나게 많은 템플릿들이 숨겨져 있어서 엄청나게 많은 일을 하지 못하고 있다.누가 이걸 되돌릴 수 있을까? - 한첸 02:30, 2006년 3월 16일 (UTC)

다음 클래스는 MediaWiki에서 제공됨:모노북.js, CSS 파일 중 어느 것도. --cesarb 02:41, 2006년 3월 16일(UTC)

그리고, 정말로, 이것이 여러분 모두가 찾고 있던 변화 입니다. --cesarb 02:42, 2006년 3월 16일 (UTC)

그래. 미안해, 내가 ".js" 생각을 할 때 손가락이 ".css"를 타이핑했어.혼란에 대해 사과드립니다 --TreyHarris 02:45, 2006년 3월 16일 (UTC)

파렴치한 플러그:이런 것들이 정의되고 사용되는 곳을 쉽게 찾을 수 있도록 CSS 수업 카탈로그를 만들고 있다. --cesarb 02:44, 2006년 3월 16일 (UTC)

텍스트 상자가 끊어짐

나는 Mozilla Firefox 1.5.0.1을 사용하고 있는데 이 흥미로운 문제가 있다.텍스트가 많은 텍스트 상자가 있으면 텍스트 아래 부분이 대부분 잘려져 텍스트 상자 위만 보인다.브라우저가 로드될 때 텍스트 상자의 절반이 삭제되고 텍스트 상자에 표시되지 않을 경우 위키 기사를 편집하려는 경우 이 문제가 발생한다.(특히 블로거 사이트를 위한 템플릿에 사람들이 입력하는 긴 HTML 코드를 복사하여 붙여넣는 것도 어렵다.)누가 나를 도와줄 수 있을까? (MSIE에서 같은 페이지를 열면 이런 문제가 없다.)

위키백과:문서 크기에 유용한 정보가 있을 수 있음...그 동안 섹션별로 편집해 보십시오. -- WikidSmaht (토크) 21:08, 2006년 3월 15일 (UTC)

나는 원시 브라우저를 사용하는 것이 아니라, 이런 문제가 있어서는 안 된다. --Rachack 21:47, 2006년 3월 15일 (UTC)

1) 이 문제가 발생하는 페이지 목록을 제공할 수 있는가?

2) 어떤 운영 체제와 버전을 실행 중인지 알려주시겠습니까?

3) 프록시 서버 종류는 없으십니까? (Ad-blockers, "sanitizer", JS-stripper 등)

4) Firefox 확장을 사용하십니까?비활성화하거나 제거해 보셨습니까?

--Briion 20:13, 2006년 3월 16일 (UTC)

사용자 기여도

현재 목록과 동일하지만 사용자가 있는 모든 페이지(상단)를 제외하도록 필터링된 사용자 기여 목록을 얻을 수 있는가?(이것은 모두 맨 위에 표시된 페이지의 편집이며, 가장 최근에 편집된 페이지만이 아니다.) -- SGBailey 00:07, 2006년 3월 18일 (UTC)

위키몰라시스

너네 서버 다운 받았어? 위키피디아는 전화 접속이 더 빠르고 난 DSL에 속해 있어.나는 WP로부터 여기 지시를 받았다.이 문제에 관한 A.계엄령 21:27, 2006년 3월 17일 (UTC) : (

120초를 시도해보자 "Operation has timed out"이라는 글이 등장했다.계엄령 21:43, 2006년 3월 17일 (UTC) :o

'편집' 위치 망쳐놨어

켈트족의 매듭에서 역사 섹션의 '편집' 링크의 위치는 엉망이 된다...오른쪽의 이미지 때문일지도 몰라 헤드라인이 밑줄 친 걸 억지로 낮췄어.나는 헤드라인과 같은 선에서, 이것을 정상적으로 앉게 하는 방법을 생각해 낼 수 없을 것 같다.도움말? --Kickstart70 16:45, 2006년 3월 17일(UTC)

내가 예상한 대로 페이지 렌더링한다. 섹션 편집 링크는 블록 콘텐츠를 수용하기 위해 이동할 것이다.원하는 효과를 얻을 수 있는 a를 추가할 수 있지만 큰 차이는 없다.롭 처치 2006년 3월 17일 19시 42분(UTC)

샘 코른이 와서 해결책을 제시했어 그래서 지금 너한테 보이는 거야그것은 실행 가능한 해결책이지만, 일종의 해킹이다.이에 앞서 '편집' 링크는 기록 섹션의 다른 텍스트 위에 렌더링되었다.이상적으로는 이것이 문제가 되지 않을 것이며, 아마도 포함된 두 이미지 둘레에 담긴 상자가 더 영구적으로 해결될 것이라고 생각한다. --Kickstart70 20:43, 2006년 3월 17일 (UTC)

결함 수리에 필요한 도움말

안녕, 나는 이 페이지에서 과거에 여러 테이블을 포맷하는 데 조금 애를 먹었어.혹시 이 3개의 테이블 주변의 불완전한 경계선 문제를 내부의 내용 배열을 변경하지 않고 해결할 수 있는 방법을 아는 사람이 있다면, 제발 나를 위해 고쳐줄 수 있겠니?고마워. mdmanser 14:08, 2006년 3월 17일 (UTC)

테두리에 대한 스타일 비트를 제거해 보십시오. --Briion 22:39, 2006년 3월 17일(UTC)

IE에서 WP 로고 흐릿

이 문제는 파이어폭스를 이용하면 쉽게 풀 수 있지만 이 문제를 해결할 수 있는 해결책이 있는지 묻고 싶다.Microsoft Internet Explorer만 사용할 때 위키백과 로고가 흐릿하게 표시됨(IE6도 확인됨).(이미지 참조) 그러나 이 문제는 일관성이 없어 보인다.IE6가 장착된 다른 PC는 정상 작동하지만 많은 PC가 이러한 상태로 인해 장애를 겪고 있다. 붕소 00:14, 2006년 3월 17일(UTC)

그 이유는 CSS(Monobook.css)에 의해 당신의 이미지를 포함하기 때문이다!아마도 IE의 일부 버전에서 올바르게 하는 데 문제가 있을 것이다;-) 당신은 정말로 m:Requests에 로고 요청(또는 더 나은:Bugzilla!), 왜냐하면 Wiki.png가 활성화되면 이 효과는 더 이상 존재하지 않을 것이기 때문이다.BTW: 내가 보기에 이것의 주요 원인은 "IE5.5를 위한 해킹이 있는 센터 이미지"에서 ../skins-1.5/common/IEFixes.js일 수 있다.어쩌면 이것이 그 복제(블러링된 로고)를 야기할지도 모른다!?JavaScript가 비활성화된 경우 로고가 올바르게 표시되는지 확인하십시오.만약 그렇다면, 모노북에 추가할 때 다음과 같은 것이 효과가 있을 수 있다.js:

if (ISMSIE55 &&!done)IEAlphaFix) { logospan.style.left = '50%', logospan.style.setExpression('marginLeft', '"+(이.offsetWidth / 0) + "px"; }

그렇지 않다면 (내가 생각하는 것; ->IE5.5) Monobook.css! ---- 그 중 어떤 것이 효과가 있기를 바라며, Melangolie 21:38, 2006년 3월 17일(UTC)에 이미지(->#p-logo)를 왼쪽으로 2p배 더 정렬해 볼 수 있다.

추신: 아, 이미 하나 있다: 미디어질라:5275 --멜란졸리 21:50, 2006년 3월 17일 (UTC)

관리자 필요!제발!

나는 바보 같은 짓을 해서 위키피디아 난센스 항목을 만들었다.미안해. 후회하고 엔트리 기록도 삭제했으면 좋겠어.그러나 나는 이것을 어떻게 해야 할지 모른다.나는 그것이 나보다 더 높은 위키백과 사용자 권한을 가진 사람을 필요로 한다고 생각한다.내 사용자 이름은 Marcusvox이고 너는 내가 http://en.wikipedia.org/wiki/Sympatico에서 만든 바보 같은 글들을 볼 수 있을 것이다.

내가 편집한 이력이 지워져서 이 난센스 페이지가 영원히 사라질 수 있을까?다시 한 번, 와이키피디아 커뮤니티에 이런 실수를 저지른 것에 대해 사과한다.나는 말도 안 되는 항목을 만드는 습관을 들이지 않는다.--Marcusvox 23:34, 2006년 3월 16일 (UTC)

아주 정직한 말씀이시지만, 이미 되돌렸으니 역사에서 지울 필요는 없다. -2006년 3월 17일^talk 00:28, 2006년 3월 17일 (UTC)

네, 삭제할 필요도 없고, 보관할 필요도 없는데, 왜 안 되는 겁니까?삭제됨. --cesarb 00:33, 2006년 3월 17일(UTC)

고마워 CesarB.나는 네가 행정가라고 생각한다.다시는 그렇게 어리석지 않을 것이다. --Marcusvox 00:55, 2006년 3월 17일 (UTC)

우선 첫째로, 그것들은 더 이상 사용자의 기여에 보이지 않는다.Superm401 - Talk 02:01, 2006년 3월 17일 (UTC)

하지만 그가 여기서 그들을 제거해 달라는 요청은. --cesarb 16:06, 2006년 3월 17일 (UTC)

잃어버린 자수정

피부 자수정은 분명히 삭제되었고, 나는 그것을 위키피디아에서 추천했다.CSS가 없는 레거시 브라우저에 대한 사용자 지정순수한 XHTML로 기존 방식대로 CSS 마법에 의존하지 않는 피부가 있어야 한다.HIDE 트릭, 가능하면 HTML 3.2 엔티티를 UTF-8로 불필요하게 번역하지 않고, <참조/>를 위한 적절한 이름=앵커

레거시 피부 테스트 및 유지 관리 지원:옴니플렉스 12:41, 2006년 3월 14일 (UTC)

기억력이 좋다면 피부에 이상이 생겼기 때문에 피부를 제거되었다.정확한 이유가 1.6 또는 커밋 로그에 대한 릴리스 노트에 자세히 나와 있을 것으로 예상한다.86.134.49.239 22:11, 2006년 3월 14일(UTC)

1) 끔찍해 보였고, 2) 내가 시도했던 브라우저마다 기념비적으로 망가져 있었다, 3) 작가는 그것을 고치거나 유지하는 데 아무런 관심이 없는 것 같았다.CSS 지원이 제대로 되지 않은 브라우저에서는 특히 추했을 것이다; 오래된 클래식이나 향수 스킨, 또는 완전히 빈칸으로 된 마이스킨을 사용해 보십시오. --Briion 00:43, 2006년 3월 15일 (UTC)

분명히 나는 Classic에 "움직였다"고 했는데, 문제없었다. "UTF-8 char 삽입" 없이도 할 수 있었다. 자바스크립트 동물원은 (일반적으로) JavaScript 1.1이 비활성화된 내 레거시 브라우저를 가지고 있지만, 레거시 브라우저가 있으면 시간 낭비가 될 것이다.그러나 숨겨진 리셋 버튼은 결과의 삽입을 가속화하는데 괜찮다, 가난한 사람의 변종인 외부 편집기.옴니플렉스 02:02, 2006년 3월 17일 (UTC)

감시 목록에서 로봇 편집 숨기기

부질라: 4895

이 기능에 대해 투표하십시오.이 기능이 활성화되기 전에는 내 감시 목록을 사용할 수 없다.내 워치리스트의 첫 페이지에 있는 120개 항목 중 80개 이상이 봇에서 온 것이다.$wgFilterRobots를 설정하는 것만큼 간단하다.WL = true;...우리는 이 변화를 실제로 만들기 위해 개발 과정을 기다려야 한다...— ₀₉₁₈^BRIAN • 2006-03-9 20:23

브리온 Vibber가 이 버그를 WONTFIX로 표시했다는 점에 유의하십시오.롭 처치 (토크) 07:40, 2006년 3월 10일 (UTC)

그리고 후속 조치를 위해, 브라이언이 인용한 특징에 대한 수정 작업이 있을 때까지 REPEN으로 재개봉되었다.롭 처치 07:44, 2006년 3월 17일 (UTC)

삭제된 문서

나는 그것이 거짓 기사를 만드는 데 있어서 반달들이 가장 좋아하는 활동이라는 것을 알아챘다.단, 이러한 기사가 삭제되면 사용자의 기여 목록에서 사라진다.삭제된 기사를 포함해 사용자가 어떤 기사를 작성했는지 알 수 있는 방법은 없는가?이러한 기사들은 단순한 공공 기물 파괴 행위보다 고치는 데 더 많은 에너지를 소모하기 때문에 유용할 것 같고, 만약 사용자가 조작 기사를 만드는 경향이 있다는 것이 알려지면, 그것이 진짜 조작인지 확인하는 데 세 배의 시간이 걸릴 수 있다.마케미 06:16, 2006년 3월 5일 (UTC)

지금은 안 돼. --Briion 06:57, 2006년 3월 5일 (UTC)

하지만 우리는 그들의 토크 페이지 esp에 그것을 메모할 수 있다.편집 요약을 참조하십시오.체크아웃하려면 추가 단계가 필요하겠지만, 편집 요약을 하면 이 문제가 빨리 주목을 받게 될 것이고, 사용자가 해결할 수 있는 것이 아니다.Rklawton 07:22, 2006년 3월 5일 (UTC)

삭제된 기사 목록을 다시 가져오려는 시도가 있는가? --Massiveego 03:40, 2006년 3월 10일(UTC)

브리온은 특정 데이터를 삭제된 것으로 표시하는 방법에 대한 변경 작업을 하고 있는데, 여기에는 다른 수준의 가시성이 포함되어 있는 것으로 보인다.오래된 수정본들이 반짝이는 새 포장으로 다시 태어날 것 같다.롭 처치 07:49, 2006년 3월 17일 (UTC)

여전히 감시자 명단에 있는 배너 광고를 없애려고 노력하고 있다; 도와줘!

나는 '이메일이 확정되어야 한다'는 내용의 워치리스트의 배너 광고를 없애기 위해 2주째 노력하고 있다(확인할 이메일이 없다).여러 사람이 건의를 했지만(모두 고마워!) 소용이 없었다.나는 마법 주문으로 사용자:quota/monobook.css를 만들었다.나는 모든 파일과 임시 파일을 지웠다.나는 끊임없이 재부팅했다.그러나 나는 여전히 페이지 하단에서 모든 유용한 정보를 대신하는 배너를 얻는다.

왜 '그래, 이거 봤어, 고마워'라고 말할 방법이 없을까?연계를 따르는 것은 가망이 없다.한 바퀴 돌다

이것 좀 도와주면 정말 고맙겠어!할당량 22:10, 2006년 3월 9일(UTC)

"배너 광고"는 없다; 누군가 시스템의 변화에 대해 도움을 주는 메시지가 있다.반복해서 읽고 싶지 않으면 읽지 말 것. --Briion 00:00, 2006년 3월 10일 (UTC)

글쎄, 위아래에 넓은 공간과 상자안에 3줄의 줄이 있는 내 스크린의 약 6줄이면 첫번째 화면에는 2~3개의 워치리스트 아이템밖에 없다는 것을 의미한다.그것이 어떻게 '도움이 되는' 것인지 알 수 없다 :-) 할당량 09:15, 2006년 3월 10일 (UTC)

이 작업을 수행하는 방법은 매우 간단하므로 필요한 경우 다음을 여러 번 읽어 보십시오.

• 파일을 편집하십시오.네, 공백이 될 겁니다.편집으로 이동하면 편집 화면이 뜬다.
• 추가:

#이메일 { display:display; }
그럼 파일을 저장해 두십시오.

• 그러면 브라우저를 새로 고침해야 한다.Internet Explorer를 사용하는 경우 Control-F5를 누르고, Opera를 사용하는 경우 Control-Shift-R을 누르고, Mozilla/Safari/Konkeror를 사용하는 경우 F5를 눌러야 한다.
• 감시 목록으로 가면 메시지가 사라진다.

- 파일:Ottawa 플래그.png Nathanrdotcom 00:15, 2006년 3월 10일(UTC)

자세한 지시사항을 알려줘서 정말 고마워!그것들은 내가 여기저기 흩어져 있는 다른 게시물들로부터 얻은 것들이다.

정확히 그 절차에 따라 다시 시도했는데, 전혀 효과가 없다.(IE에 대한 이번 일)그 상자가 언제 저절로 없어질지 알기나 해?할당량 09:15, 2006년 3월 10일(UTC)

아, 생각 하나.. 그게 안 되는 이유가 내가 '클래식' 스킨을 사용하고 있기 때문일까?만약 그렇다면, 그것을 없앨 다른 방법이 없을까? - 고마워.할당량 09:18, 2006년 3월 10일(UTC)

사용자 사용:대신 할당량/standard.css.css.샘 코른^(smoddy) 09:34, 2006년 3월 10일 (UTC)

그것은 효과가 있었던 것 같다.고마워! 2006년 3월 17일 05:19 (UTC)

아마도 이러한 배너 박스의 경우 '이것을 다시 보여주지 마십시오'라는 확인란이 많은 분들과 시간을 절약할 수 있을 것이다.나는 이런 종류의 일을 처리하려고 애쓰기보다는 편집하는데 시간을 할애할 것이다.할당량

infobox 도움말

테이블을 Infobox 개미에게 어떻게 테이블을 만들 수 있는지 말해줄 사람 있어?

빠르고 더러운 예는 템플릿 대화:-, 자세한 예는 템플릿:을 참조하십시오.Infobox Micronation(토크 링크 내역 편집)옴니플렉스 14:05, 2006년 3월 18일 (UTC)

감시 목록에서 항목 제거

지금 몇 달째 내 감시 목록에 올라 있는 물건이 있는데, 귀찮아지기 시작했어.여러 번 제거해 보았는데 브라우저 캐시를 지웠는데 매번 '위키피디아 항목을 제거할 수 없음:BJAODN/이것이 너의 마지막 경고야, 만약 또 다른 나쁜 농담을 시도한다면 넌센스 삭제될 거야'...완성이 될 거야."좋은 생각 있어?마케미 22:09, 2006년 3월 17일 (UTC)

그게 네 감시 목록에 있는 실제 페이지의 정확한 제목이야?이 링크를 클릭하는 것이 도움이 되십니까?아무도 실제로 당신의 감시 목록을 볼 수 없기 때문에 이것은 디버깅하기 좀 어렵다.아래 제거하려는 페이지가 포함된 전체 감시 목록의 일부를 잘라내어 붙여 주시겠습니까?아니면 페이지 전체를 디스크에 저장해서 이메일로 보내줄 수 있어?—일마리 카로넨 (대화) 22:32, 2006년 3월 17일 (UTC)

당신이 준 링크는 정확히 같은 오류를 초래했다(예, 정확한 이름이다).맥락상 그렇다.

• 화이트 플라이트
• 위키백과:BJAODN/이것이 너의 마지막 경고야, 만약 네가 또 다른 나쁜 농담을 한다면 넌센스 삭제될 거야.
• 윌리엄 헌트
• 윌리엄 조이스(작가)
• 윌리엄 셰익스피어
• 볼프강 아마데우스 모차르트
• 여성권
• 잭 에프론
• 자이레

사용자

• 사용자:-TheRaven-
• 사용자:129.252.89.201
• 사용자:151.198.82.3
• 사용자:167.206.142.194
• 사용자:167.206.174.28

나는 이것이 사실 반달 기사였기 때문에 이상하다고 생각한다. 그래서 위키백과 네임스페이스 기사보다는 일반 기사에 나타나는 것이다. (예를 들어, 페이지 제목은 위키백과:등, 그것은 네임스페이스의 일부가 아니었다.)그래서인지 소프트웨어가 헷갈린다.고마워, 마케미 23:38, 2006년 3월 17일 (UTC)

이상해!하지만 나는 해결 방법을 알아냈다고 생각한다: 이 링크를 사용해 보십시오.—일마리 카로넨 (대화) 23:49, 2006년 3월 17일 (UTC)

야! 네가 해냈어!그게 왜 효과가 있지?고마워, 마케미 00:02, 2006년 3월 18일 (UTC)

페이지를 보거나 볼 때, 토크 페이지도 보거나 볼 수 없으며, 그 반대의 경우도 볼 수 있다.위 링크에서 볼 수 없는 페이지 이름은 "Talk:위키백과:"는 "Wikipedia:"로 시작하는 이름을 가진 주요 네임스페이스 페이지의 토크 페이지로서, 이 페이지는 여러분이 어떻게든지 여러분의 감시 목록에 가지고 있었던 것이다.그래서 그것을 해제하는 것 또한 해당 기사 페이지를 해제했다.

사실, 나는 그것이 애초에 당신이 보고자 했던 이상한 이름의 토크 페이지라고 장담할 수 있다.불행히도 특별함:Watchlist/edit에는 대화하지 않는 이름만 나열되며, 이는 그렇게 이상한 이름의 대화 페이지를 그런 방식으로 볼 수 없다는 것을 의미한다.토크 페이지의 언워치 탭을 사용하는 것 또한 효과가 있었을 것이다.이것은 틀림없이 벌레다.—Ilmari Karonen(토크) 00:30, 2006년 3월 18일(UTC)

버그 5280으로 제출됨.—Ilmari Karonen (대화) 01:05, 2006년 3월 18일 (UTC)

고마워, 그런 건 말이 돼, 비록 일반적으로 내가 같은 상황을 가진 페이지를 내 감시 목록에서 삭제했을 때(나는 삭제된 토크 페이지를 편집했을 뿐이고, 기사와 토크 페이지 모두 삭제되었다) 나는 문제가 없지만, 아마도 그것들의 "위키피디아"가 버그를 일으킨 원인일 거야.고마워, 마케미 01:43, 2006년 3월 18일 (UTC)

기사의 이미지는 더 나쁜 구글 결과를 준다.

나는 기사에 이미지를 가지고 있는 것이 없는 것보다 구글 검색에서 더 나쁜 결과를 만든다는 것을 실망스럽게도 발견했다.이미지와 함께 위키피디아 기사에 대한 구글 히트는 기사의 첫 번째 필수 요약이 아닌, 이미지의 캡션을 캡션으로 보여준다.여기의 나노르탈릭(검색:[13]) 검색에서 독일어 위키백과 기사는 1위를 차지하며, 검색 결과 조각에 표시되고 싶은 필수 정보를 가지고 있다.처음에 이미지가 있는 영어 위키백과(#10)의 경우, 코드 조각은 관련 없는 코드 조각 텍스트 때문에 후속 클릭을 권장하지 않는다.페이지 상단에 이미지가 없는 것 외에 이를 방지하는 방법에 대한 제안이 있으십니까?옌스 닐슨 15:52, 2006년 3월 17일 (UTC)

위키피디아는 정말로 검색 엔진 최적화에 대해 걱정할 필요가 없다.알렉사에 따르면 우리는 인터넷에서 18번째로 인기 있는 사이트야.네가 지으면 그들이 올 거야.Superm401 - Talk 21:55, 2006년 3월 18일(UTC)

이미지 교체 및 이미지 위치 지정 이미지 교체하고 해당 이미지 지정

알버타 하이테라는 기사에서 나는 두 가지 문제가 있다.택오박스에 있는 지도를 그 위에 있는 지도로 바꾸고 싶은데, 코드에서 첫 번째 지도 이름이 어디 있는지 찾을 수가 없어.어딘가에 택스박스 코드 안에 있을 거야, 내가 그걸 제거하면 지도도 사라지거든.둘째, 택스박스 지도를 교체할 수 없게 되어 다른 지도가 똑바로 앉았으면 한다.코드[Image:dwalbertahythe.png 엄지손가락 250px right]를 사용하면 안 되겠지?그러나 그것은 별로인 것 같다.이것 좀 도와줄래?고마워!데니 ☯ 04:10, 2006년 3월 17일 (UTC)

이 상자는 {{Canadian Town}}에 의해 만들어지는데, 이 상자는 "{{PAGENAME} Location.png"라는 이미지를 하드코드로 사용하였다.이미지 이름을 재정의할 수 있도록 템플릿을 다시 쓰는 것이 아니라 이미지를 상자에 넣는 유일한 방법은 이미지 위에 지도를 다시 업로드하는 것이다.하이테, 알버타 로케이션.png.

나는 너의 대체 요구가 무엇인지 잘 모르겠다.dwalbertahythy.png는 나에게 딱 맞는다(그러나 나는 때때로 모노북과 다르게 이미지를 배치하는 고전적인 피부를 사용한다).나는 당신이 새로운 이미지를 그 옆에 놓기 보다는 아래에 놓기를 제안하고 싶다. 그것은 당신이 그것을 단지 몇 단락의 위키코드 아래로 옮겨 놓을 수 있다.-gadfium 05:24, 2006년 3월 17일 (UTC)

그것은 이미지의 기본 이름일 뿐이다.템플릿 매개 변수로 오버리덴할 수 있다. --cesarb 01:02, 2006년 3월 18일(UTC)

크기에 대한 많은 사용자 의견 필요

Template_talk:현재_U._의원#규모 여론조사, 현재 버전(D)이 제안된 버전(M)만큼 좋은지 아닌지를 논의 중이다.어느 버전이 더 작은지(그것이 현재 의문이다).많은 사람들이 버전(D)이라고 말하지만, 내 눈에는 확실히 그렇게 보이지 않는다.내 생각에 더 많은 쌍의 눈이 필요하다.고마워!맷 예거 ♫ (토크?) 01:11, 2006년 3월 17일 (UTC)

1. 정말인지 몰라도, 나는"D"에 작은-파이어 폭스, WindowsXP1024*768px.(저는 또한 그건 완전히 다른 문제는 색을 볼 수도 없어...)Shimgray 이야기 01:41, 3월 17일 2006년(CoordinatedUniversalTime)을 얻는다.

D많이(파이어 폭스, winXP) 작다.나는 간신히.--핀레이 McWalter 강연 01:49, 3월 17일 2006년(CoordinatedUniversalTime)은 색을 볼 수 있다.

D나에게 작은 뿐만 아니라 나타난다.또한 거의 빛의 색을 구별할 수 있다.고마워!Flcelloguy(한 쪽지 말인가요?)02:01, 3월 17일 2006년(CoordinatedUniversalTime).

D(모질라 시몽키 Suite)고, 다른 한명도 화면 해상도에서, 수평 스크롤 바 강요하는 것에 맞지 않아 작다.*Dan T.* 02:20, 3월 17일 2006년(CoordinatedUniversalTime).

D,지만 별로(오페라, 큰 글꼴)에 의해.Carnildo 02:52, 3월 17일 2006년(CoordinatedUniversalTime) 작다.

D, 스크롤 필요한 약간의 작은 형식 갖고 있다.M(IE6는 1024와 768화면에)그것 모두가 볼 수 있도록 스크롤의 것이 많다.둘 다 D와 M으로 그 스크롤-아드리안 Pingstone 16:26, 3월 17일 2006년(CoordinatedUniversalTime)짜증 나게 합니다.

반면 M이 넘치D 멋지게 화면에 수평 스크롤이 필요하게 맞아떨어진다.두 버전 완벽하게 읽을 수 있다.모질라 파이어 폭스 1.5데비안 마구간에, 1600x1200, 132DPI-cesarb 00:47, 3월 18일 2006년(CoordinatedUniversalTime).

나는:MD보다 Template_talk을 통해 더 큰 파라메타를 위한 이유 설명한 바 있습니다.Current_U.S._Senators)규모 여론 조사. cesarb 00:59, 3월 18일 2006년(CoordinatedUniversalTime).

User-specified 뉴 페이지

:방법, 특정한 사용자 만들어 낸 모든" 새로운 페이지"뭐 특별한 비슷한 보러 ther 있다.Newpages지만 사용자 지정된?--MoRsΞ 23:08, 3월 16일 2006년(CoordinatedUniversalTime).

필터링 된 특별에: 보는 것.내가 좀 더 청소 했던 Newpages 지금은 코드 베이스에를 저지를 것이다.:)롭 교회 20:21, 3월 17일 2006년(CoordinatedUniversalTime).

그것은 매우 유용할 것이다.우리는 이미 특별이 있습니다.Log/upload 그래선 사실을 우리가 가지고 있지 않아 이상하네요.그것에 대한 일에 감사 드립니다.Superm401 얘기해 21:50, 3월 18일 2006년(CoordinatedUniversalTime).

Cite.php의 이상함

바르샤바 봉기를 외부 지원 부족의 마지막 각주 unexplicably 대담한로써, 제임에도 불구하고 외짝인 돈호 법의 전체 단락 보였다 시작되습니다.누가 좀 더 자세히 볼 수 있을까?서커스 02:13, 2006년 3월 16일 (UTC)

그것은 "파일이 실수로 파괴되었다는 것을 판 것"의 마지막 단 하나의 인용구에 의해 야기된다.하지만 나는 그것을 어떻게 고치는 것이 가장 좋은지 잘 모르겠다. 너는 아마도 그곳의 이탤릭체를 완전히 없애고 싶을 것이다.—Kirill Lokshin 02:21, 2006년 3월 16일 (UTC)

(갈등을 편집) 내가 고쳤다.마지막 싱글 인용문은 이탤릭체를 끝내는 두 개의 프리마임과 함께 붙여졌다.— Knowledge Seeker দ 02:29, 2006년 3월 16일 (UTC)

m:Cite는 알려진 문제의 목록을 제공한다.옴니플렉스 00:06, 2006년 3월 18일 (UTC)

하지만 이것은 Cite.php의 문제는 전혀 아니었다.Superm401 - Talk 21:44, 2006년 3월 18일(UTC)

네임스페이스별 감시 목록?

아마 전에 언급된 적이 있을 겁니다만, Talk은 없다.감시목록이 있어서 여기로 가져올게.기여/최근 변경사항과 같이 네임스페이스별로 감시 목록을 필터링할 수 있는 가능성은?때때로 나는 정책/RfA/*fD 질문을 다루는데 방해받지 않을 수 있지만, 여전히 아무도 Pict를 파괴하지 않았는지 확인하고 싶다.

나는 내가 참여하는 비기사-공간 페이지를 분리하여 Related Changes를 사용하려고 했지만, 그것은 유지하기가 정말 어렵고 페이지 무브와 같은 것에 대해서는 자동으로 업데이트되지 않는다.그리고 내가 WP-space watchlist 목록 항목만을 보여주기 위한 특별한 구문을 알고 싶은 만큼, 내가 정말로 염려하는 것은 때때로 쇼-아티클 공간만 보여줄 수 있다는 것이다.고마워. --내블리스 16:47, 2006년 3월 14일 (UTC)

버그질라에서 이것에 대해 물어볼 수 있다: 개발자들은 아마도 그곳에서 더 빨리 그것을 볼 것이다.æle✆ 2006년 3월 14일 21:02 (UTC)

고마워. 내가 찾은 것을 아래를 봐. --내블리스 22:26, 2006년 3월 14일 (UTC)

뭔가 도움이 될 것 같군시간이 날 때 알게 되겠지만, 없으면 특집 요청서를 제출하는 것을 추천한다.

있다면 버그 번호를 알려주면 내가 언제 고쳤는지 알 수 있고 다른 코멘트를 고려할 수 있어.86.134.49.239 22:14, 2006년 3월 14일(UTC)

1862년은 Bugzilla를 정확하게 읽고 있다면 거의 같은 요구인 것 같다.--내블리스 22:26, 2006년 3월 14일 (UTC)

이 작업을 위해 사용자 스크립트를 작성했다: 위키백과:WikiProject 사용자 스크립트/스크립트/워치필터.—Ilmari Karonen (대화) 17:32, 2006년 3월 18일 (UTC)

빈 편집 필드

어제 14시 3분 UTC에서 14시 31분 사이에 위키피디아가 페이지를 편집할 때 빈 편집 상자를 반환하는 페이지를 편집할 때 문제가 발생했다.이것은 봇들에게 심각한 문제를 제시한다: 그들은 무턱대고 많은 페이지를 비워둘 수도 있다.이 문제가 일회성 문제였을까, 아니면 봇을 운영하는 사람들이 그 문제를 코딩해야 할까?

(걱정되는 모든 사람들에게, 이것이 내 봇에 미친 유일한 영향은 반복적으로 자신의 토크 페이지를 비운 것이었다.) --카닐도 05:01, 2006년 3월 14일 (UTC)

아직도 그런 일이 일어나고 있는 것일까?만일 그렇다면, 우리는 그것을 재생산, 진단, 고치기 위해 훨씬 더 많은 정보가 필요하다. 86.134.49.239 22:15, 2006년 3월 14일 (UTC)

그게 내가 묻고 싶은 거야:앞으로 일어날 것 같은 일인가(이 경우 코딩이 필요할 것 같은 경우), 아니면 일회성인가? --카르닐도 05:23, 2006년 3월 15일 (UTC)

고친 지 오래됐네. --Briion 20:23, 2006년 3월 16일 (UTC)

고마워. --Carnildo 21:18, 2006년 3월 16일 (UTC)

긁어봐 -- 벌레(또는 비슷한 벌레)가 아직 거기 있어.OrphaniBott는 방금 기사를 비웠으며 로그는 두 가지 가능성을 나타낸다.

1. 서버가 제공한 페이지에는 빈 편집 필드가 포함되어 있거나
2. 서버는 "wpEdittime" 필드 이후에서 "wpTextbox1" 텍스트 영역이 끝나기 전에 잘라낸 일부 페이지를 제공했다.

--Carnildo 21:45, 2006년 3월 18일 (UTC)

<논평>과 <논평만>

<무포함>이나 <포함만>과 비슷한 지시사항이 있는가?

큰 테이블 중간에 편집해야 할 섹션이 있어.(Wikipedia를 살펴보십시오.위키프로젝트 비틀즈/기사 분류...각 글자는 별도 섹션) 왜냐하면 중간에 있기 때문에 한 섹션을 편집할 때 텍스트가 미리보기 모드로 포맷되지 않고 뒤죽박죽이 되어 있어 저장 시 무엇을 얻는지 알 수 없다.포함된 하위 섹션 페이지(User:Lar/Sandbox 및 User:Lar/Sandbox/앨범 Q, 섹션 중 하나)를 편집하는 경우에만 사용할 수 있는 포함 기능을 사용하려고 했지만, 섹션 편집 태그를 클릭하면 포함 섹션의 일부만 편집되는 것처럼 내가 원하는 부분에는 적합하지 않다.

관련 질문: [편집] 태그의 글꼴 크기를 제어하는 방법아주 큰 글씨체로 되어 있는데, 섹션 제목보다 작았으면 좋겠어.아니면 편집하기 위해 섹션을 사용하는 잘못된 방법을 택하는 것인가?다른 걸 써야 하나?직접 편집을 강제하시겠습니까?++Lar: t/c 23:39, 2006년 3월 13일(UTC)

그런 지시는 그들이 할 필요가 없기 때문에 존재하지 않는다.말도 안 되는 소리야.섹션 편집 링크에 적용되는 스타일은 스킨의 CSS 파일에서 제공되며 사이트 전체 사용자 지정 또는 사용자별 사용자 지정으로 재정의할 수 있다.86.134.49.239 22:09, 2006년 3월 14일(UTC)

네가 "말도 안 되는 소리"라고 생각하는 것 같아 유감이다.솔직히, 나는 그 논평이 좀 불쾌했다.나는 네가 누군지 잘 몰라서 다시 물어봐야겠다.나는 이 태그들이 필요하다고 생각하는데 나는 그 이유를 예시해 왔다.내가 참조한 표는 보셨나요?그 이유를 이해하지 못한다면, 그것을 성취하기 위한 다른 방법을 제안하십시오.

내가 준 예에서 섹션 편집 링크(Angain, you looked?)는 일반 링크보다 훨씬 크다.나는 부서장이 테이블 셀에 파묻혀 크기가 달라지기 때문에 의심한다.섹션 헤드에 대한 사이트 전체 사용자 정의 변경은 문제를 해결하는 방법이 아닐 수 있다.++Lar: t/c 23:07, 2006년 3월 15일(UTC)

나는 그것이 내게는 그렇게 들리기 때문에 우스꽝스럽다고 말했다.미리보기에서 뭔가를 숨기거나 미리보기에서만 보여줄 필요는 없을 것 같은데, 그런 태그가 예상할 수 있는 일 아닌가?섹션의 링크 편집에 대해서는, 글쎄, 미래에 문맥을 제공하는 것이 그러한 오해에 도움이 되었을 것이다.아니, 사이트 전체 값을 변경해도 도움이 되지 않아.롭 처치 2006년 3월 17일 07:29 (UTC)

미리보기 동안만 문자나 표시를 숨기거나 표시하거나 숨길 필요가 없다고 생각한다면 아마도 당신은 내가 준 예를 아직 보지 않았을 것이다.여기 또 문제가 있다.그렇게 친절하다면 스나이더 해설을 쓰는 데 시간을 들이지 말고 시간을 들여 보라(조용히, 어떤 제안에 적용하면 '어리석은 것'이 스나이더나 미개한 것이 아닌 문맥은 없다, 설령 그것이 실제로 타당하게 우스꽝스럽다고 생각하더라도 의견을 표현하는 더 좋은 방법이 있다).나는 그것을 다시 좀 더 자세하게 썼다.

여기로 이동: 위키백과:위키프로젝트_The_Beatles/Architect_Classification(문서_분류) 및 테이블로 스크롤 다운...예: "Atticleft in Category:비틀즈 앨범.표 섹션에 있는 "편집" 링크가 얼마나 큰지 보셨습니까?그게 첫 번째 문제야.이제 하나를 클릭하십시오. 예를 들어 "B" 섹션: [14] 전체를 볼 때 잘 포맷된 테이블 섹션은 현재 미리보기에서 뒤죽박죽이 되어 있는데, 이것은 중간에 있는 테이블의 덩어리이기 때문이다.제대로 했는지 확신할 수 없고, 저장하지 않고는 알 길이 없기 때문에 편집이 어렵다(서버 부하 증가와 추적할 편집 횟수 증가).그러나 putative Preview only 태그가 존재한다면, 본문을 괄호로 묶은 미리 보기 전용 { 및 } 쌍은 이 모든 것을 읽기 쉽게 만들 것이다.

자... 왜 전체 테이블 대신 한 번에 한 섹션씩 편집할 수 있겠어?두 가지 이유.전체 테이블이 크고, 작업 내용을 확인하기 위해 많이 스크롤해야 하지만, 더 나쁜 것은 여러 프로젝트 구성원이 바쁘게 기사를 분류할 때 갈등을 편집하기 쉽다.그것이 왜 이것이 좋은지 설명해 주길 바란다.아니면, 어쩌면 그것을 하는 다른 방법이 있을까?우리가 생각한 한 가지 방법은 각 테이블 섹션을 별도로 포함된 하위 페이지(noinclude를 사용하면 동일한 효과를 얻을 수 있음)로 만드는 것인데, 그것은 관리해야 할 수백 개의 하위 페이지를 만드는 것으로, 엉뚱해 보인다.++Lar: t/c 11:48, 2006년 3월 17일(UTC)

그 페이지는 디자인만 봐도 머리가 아프다.두 가지 요점이 모두 오른 것 같군, 그래나는 여전히 우리가 사람들이 예고편에서 뭔가를 숨길 수 있도록 허용해야 한다는 것에 대해 논쟁한다. 우리의 다른 모든 페이지들에 대해 그 내용에는 큰 의미가 없다. 그렇지 않은가?롭 처치 2006년 3월 17일 20:27 (UTC)

날 믿어, 나도 머리가 아파!대칭적인 이유로 nopreview를 언급했지만, 수정만 허용하는 미리보기일 뿐 nopreview는 그다지 유용하지 않아 보인다.비교적 트래픽이 많은 것을 염두에 두고 페이지 개선에 대한 제안이 있으십니까?우리는 (위에서 언급된 별도 포함된 하위 페이지 외에) 섹션에서 표를 분할할 것을 생각했지만, 그것은 (헤더 행의 강제적인 백분율에도 불구하고) 셀 너비를 한 섹션에서 다음 섹션으로 변화시키는 원인이 된다.어떤 제안이라도 고맙다(또는 아이디어를 요구할 다른 곳에 대한 조언들).++Lar: t/c 05:25, 2006년 3월 18일(UTC)

카테고리 내역 이동

이런게 가능할까: 카테고리:노르마 엘리자베스 보이드는 개발인가 뭔가에 의해 (주 네임스페이스로 이동) 고정되어 있는가?아니면 그냥 자르고 붙여넣고 카테고리를 지워야 할까? --쉐롤 (대화) 18:36, 2006년 3월 19일 (UTC)

기본 페이지 변경

어쨌든 새로운 메인 페이지를 무시하고 오래된 메인 페이지를 보는 것 혹은 나는 절망적인 원인을 찾고 있는 것이다.새것은 솔직히 내 눈을 아프게 해!마이크 07:48, 2006년 3월 19일 (UTC)

메인 페이지 대체 (Classic 2006) (표제 기사, ITN, 선택된 고리, DYK는 여전히 적절하게 회전해야 함) Raul654 07:53, 2006년 3월 19일 (UTC)

역겨운 테이블이 없는 내용 열

나는 최근에 테이블 기반의 시각적 레이아웃을 없애기 위해 일해왔고, 몇몇 사람들이 선호하는 링크 등이 많은 섹션과 같은 칼럼의 내용을 다루려고 노력했다.나는 그들을 별로 좋아하지 않지만, 어쨌든, 나는 그들이 잘 작동하도록 하는 편이 낫겠다.게다가, CSS 기반 레이아웃으로, 칼럼이 정말 마음에 들지 않는 사람들은 모노북.css. ;-) 원본 템플릿은 {{col-begin}에 있고, 나의 새로운 템플릿은 Template talk에 있다.열.나는 피드백이 필요하고 그것은 수정해야 한다.예를 볼 수 없으면 캐시를 바이패스하십시오.— 오메가트론 06:14, 2006년 3월 19일 (UTC)

Javascript에서 사용자 이름을 가져오는 중?

(현재 로그인한 사용자의) 사용자 이름을 문자열 변수에 저장하려고 한다.지금까지 나는 노력했다.

var myUserName = document.GetElementById('contentSub').innerHTML.match(/'(.+')/[1];

그러나 document.GetElementById('contentSub')가 null을 반환하므로 실패함.나는 또한 MediaWiki를 사용해 보았다.성함은 맞지만 구문을 알 수 없다. --Tifego 03:00, 2006년 3월 19일 (UTC)

document.GetElementById('pt-userpage')를 제안한다.GetElementsByTagName('a')[0].href 및 "/wiki/User:" 접두사를 제거하십시오.—일마리 카로넨(토크) 03:19, 2006년 3월 19일 (UTC)

고마워. (하지만 문서.GetElementById('pt-userpage')GetElementByTagName('a')[0.text 대신?) --Tifego 04:03, 2006년 3월 19일(UTC)

다음 작업을 수행할 수 있음:

var myUserName = document.getElementById('pt-userpage').getElementsByTagName('a')[0].firstChild.nodeValue

"텍스트"는 유효한 객체가 아니다.단, 우아한 방법은 쿠키(이상적으로 쿠키 읽기 기능을 사용해야 한다)를 읽는 것이다.

var cke = document.cookie;

var pos = cke.indexOf("enwikiUserName");

var start = cke.indexOf("=", pos)+1;

var end = cke.indexOf(";", pos);

if (end == -1) end = cke.length;

var myUserName = cke.substring(start, end)

-Superm401 - Talk 05:29, 2006년 3월 19일(UTC)

아니, 나는 네가 그것이 필수품이라는 것에 대해 틀렸다고 생각해.주로 이미 ".text" 버전을 사용하고 있고 사용자 이름을 완벽하게 얻기 위해 작동하기 때문이다. --Tifego 05:33, 2006년 3월 19일 (UTC)

명확히 하자면: "텍스트"는 특별한 의미를 가지고 있어서 비록 그 이름을 가진 노드는 없지만 여기서 사용하는 것이 타당하다."텍스트(text)"는 노드 안에 있는 것으로, 즉, --Tifego 05:43, 2006년 3월 19일(UTC)

네 말이 맞아!그러나 textNode 를 사용하기 위해 DOM 표준에 유의하십시오.Superm401 - Talk 05:47, 2006년 3월 19일(UTC)

또한, 나는 여전히 쿠키를 사용하는 것이 멋지다고 생각해.Superm401 - Talk 05:48, 2006년 3월 19일(UTC)

정규식을 사용하여 쿠키를 추출하는 더 좋은 방법은 다음과 같다.

var userName = 디코딩URIComentor(/(^ ;)\s*enwikiUserName\s*=([^;]*) $)/.exec(문서.cookie)[3.replace(/\+/g, ");;;

이것은 또한 사용자 이름을 제대로 이스케이프하지 않게 하는 것을 처리한다.—Ilmari Karonen (대화) 16:08, 2006년 3월 19일 (UTC)

스팸 필터 문제

스팸 필터에 문제가 있는데, 이런 식으로 편집을 할 수 있는데, 되돌릴 수 없다.관리자가 그것을 되돌릴 수 있고 누군가가 그것을 조사해 줄 수 있는가?고마워. tv316 22:59, 2006년 3월 18일 (UTC)

누군가 이미 되돌린 거야왜 그렇게 할 수 없다고 생각하는지 모르겠는데, 논란이 되는 토크 페이지에서 서명되지 않은 스페인어 텍스트를 삭제하는 것은 IMHO의 기술적인 문제가 아니다.옴니플렉스 07:57, 2006년 3월 19일 (UTC)

내가 그것을 할 수 있다고 생각하지 않았던 것은 아니다.롤백하거나 수동으로 되돌릴 수 없다.내가 정말 디프트에 링크를 올려서 "알았어, 얘들아.즐겁게 보내세요더 이상 내 문제가 아니야!"스팸 필터로 인해 내 복구가 거부되는 순간 기술적 문제가 된다. tv316 22:53, 2006년 3월 19일(UTC)

"알카에다 전략" 섹션의 ON 링크는 스팸 필터를 트리거한다(하지만 행정 롤백은 효과가 있는 것으로 보인다).나는 링크를 수정하여 문제를 해결했다.라울654 07:58, 2006년 3월 19일 (UTC)