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

할당된 휴대용 IP

누군가가 IP 상태 측면에서 "할당된 휴대용"의 의미를 명확히 할 수 있는가?이것은 이 속편 보고서의 몇 블록과 관련이 있다.Whois 데이터가 여기에 있다.고마워!--체이서 - t 08:48, 2007년 10월 15일 (UTC)

"할당된 휴대용"은 단순히 주소 블록이 국가 레지스트리 서비스(이 경우 APNIC)에 의해 직접 할당되었으며, 따라서 제공자에 독립적이라는 것을 의미한다.이는 IP 주소를 서비스 제공업체로부터 "빌려" 받고 그 제공업체와 함께만 사용할 수 있는 일반적인 모델과는 달리 IP 주소의 "소유자"가 그것을 한 제공업체에서 다른 제공업체로 이전할 수 있다는 것을 의미한다.휴대용 IP 주소를 취득하는 주된 이유는 제공자를 변경할 때 IP 주소의 확립된 평판을 유지하고, 이전 주소를 포기하지 않고도 제공자를 변경할 수 있는 유연성을 확보하기 위함이다.하지만, 이것이 두 명의 사용자가 다른 사용자의 양말 인형인지 아닌지를 결정하는 데 어떤 역할을 할지는 잘 모르겠지만, 요청하신 대로 그렇게 정의하십시오:) AmiDaniel (토크) 15:45, 2007년 10월 15일 (UTC)

할당된 휴대용 주소는 평균 정적 IP보다 정적인 경향이 있다.--추적자 - t 20:49, 2007년 10월 15일(UTC)

음.. 이런 의미에서 생각해 본 적은 없지만, 나는 분명히 그런 결론을 성급히 내리지는 않을 것이다.IP가 "정적"인지 "동적"인지 여부는 서비스 제공자가 IP 주소를 IANA에 의해 할당되는 방식이 아니라 가입자에게 주소를 할당하는 방식에 의해 결정된다."휴대용"이라는 것은 IP 주소나 블록이 한 제공자에서 다른 제공자로 이전될 수 있다는 것(있었거나 그렇지 않을 것이다!)이며, 특히 이러한 성질 때문에 제공자에 의해 주소를 확인할 수 없다는 것을 의미한다.일반적으로 (적어도 AFAIK) 휴대용 IP 주소의 경우는 전대기업이 필요할 경우 대체 제공자에게 전송 시 동일한 IP 주소를 유지할 수 있다는 조건으로 상위 제공자로부터 휴대 IP 주소를 전대하는 것이다.비용 때문에, 이는 일반적으로 ISP 시장이 매우 경쟁적인 지역(예: APNIC가 서비스를 제공하는 많은 지역의 경우)에서만 이루어진다.그런 다음 전대기업은 자신의 내부 할당 계획에 기초하여 이러한 IP 주소를 통해 고객에게 연결성을 제공할 것이다. 일부는 개인, 기업, 서버에 정적으로 제공될 수 있으며, 다른 일부는 고객 중 하나 또는 다수에게 동적으로 사용될 수 있다.대부분의 경우, 어떤 개인도 단일 휴대용 주소의 관리인이 될 수 없다.정적인 것과는 반대로 대부분의 휴대용 IP 주소는 여러 개인이나 실체가 공유하고 있을 가능성이 높다고 말하고 싶다. 비록 이것도 결코 강제적인 것은 아니다.간단히 말해, 당신은 스리랑카 텔레콤에 연락하여 이 IP 주소가 어떻게 사용되는지 정확히 알 수 있는 정확한 성격을 나에게 물어봄으로써 훨씬 더 많이 알 수 있다 :) 아미다니엘 (토크) 19:11, 2007년 10월 17일 (UTC)

아주 도움이 되고 유익한 답변 고마워, 아미다니엘.이번 교류에서 많은 것을 배웠다.--추적자 - t 20:56, 2007년 10월 17일 (UTC)

도와줘서 기뻐 :) 아미다니엘 (대화) 03:24, 2007년 10월 19일 (UTC)

밑줄이 그어진 링크

나는 내 기본 설정을 밑줄 연결로 설정했지만, 오늘까지 나는 왼쪽의 네비게이션과 상호 작용 링크가 밑줄로 되어 있다는 것을 알아차리지 못했다.뭔가 바뀐 거야, 아니면 내가 이걸 처음 알아차리는 거야?나는 IE7을 브라우저로 사용하고 있다.2007년 10월 18일(UTC) 15:53, Coemgenus 15:53,

그들은 당신이 그것들을 굽어볼 때 밑줄을 그어야 한다.그것은 Wikipeia의 CSS 스타일(브라우저 설정보다 우선함)에 의해 관리되고 있다. — Edokter • Talk • 2007년 10월 18일 (UTC)

그래, 하지만 난 그들 위를 맴돌지 않을 거야.그들은 지금 항상 밑줄을 그어 놓고 있다.2007년 10월 18일 쿰게누스 16:02 (UTC)

그래, 이상하다.내가 아는 한 변한 것은 아무것도 없다.캐쉬를 정리해보셨나요? — Edokter • Talk • 16:11, 2007년 10월 18일 (UTC)

우회해서, 아무 효과도 없이, 그리고 제거해버렸고, 또한 아무런 효과도 없었다.이거 좀 이상해.심지어 편집 화면의 기호와 문자 링크에도 밑줄이 그어져 있다.2007년 10월 18일 코엠게누스 17:56 (UTC)

나는 이 편집이 성공했다고 믿는다.아마도 부분적인 되돌리기가 필요할 것이다.--- RockMFR 18:11, 2007년 10월 18일 (UTC)

응, 그 편집(내가 요청한)이었어.기술적으로 "언더라인 링크:항상" 환경설정에서 모든 연결에 밑줄을 그으십시오.그러나 사용자들은 이미 "정상적인" 포틀렛과 스페셜 차들에 익숙해 있기 때문에 미디어위키에 다시 넣을 필요가 있다.Monobook.css c AlexSm 18:50, 2007년 10월 18일(UTC)

/* "언더라인 링크:항상" */ .포틀렛 a, #페이지별 특집 기사를 편집하다 a  { 문자로 된: 없는 } .포틀렛 a:맴돌다, #페이지별 특집 기사를 편집하다 a:맴돌다 { 문자로 된: 밑줄을 치다 } 

P.S. 이 설정은 2007년 10월 18일(UTC) http://en.wikipedia.org/w/index.php?title=-&action=raw&gen=css을 통해 발효된다.

이것은 고쳐져야 한다.WP:BYPASS 또는 WP:필요에 따라 숙청하십시오.죄송합니다만 --MZMcBride 03:33, 2007년 10월 19일(UTC)

Tnavbar-header 템플릿 문제

누군가가 이 문제를 보고 무엇이 잘못되었는지 알아낼 수 있는지 볼 수 있을까?fontcolor 매개 변수가 vde에 올바르게 적용되고 있지만 제목과 그 매개 변수가 {{Oklahoma University}}과 같은 많은 템플릿에 부정적인 영향을 미치지는 않는다.보호되었으니 문제가 보이지만 템플릿을 편집할 수 없으면 알려줘.고마워요.£N마jdan•talk 20:28, 2007년 10월 18일(UTC)

문제는 제목이 [[ ]]를 사용하여 연결된다는 점인데, 제목 자체는 [[ ]] 밖에 지정된 글꼴 색보다 우선한다는 점이다.이것을 쉽게 해결할 수 있는 방법은 없지만, 오클라호마 대학교의 템플릿에서 이것을 해결책으로 시도해 볼 수 있다.

제목=[오클라호마 대학 <스팬 스타일="색상:#fff"] 오클라호마 대학[/span]]

— Edokter • Talk • 22:20, 2007년 10월 18일 (UTC)

정보를 줘서 고마워.생성된 HTML을 보면서 그게 문제인 줄 알았는데 아쉽게도 그 해결책이 나한테는 안 먹힐 것 같아.{{오클라호마대학}}} 템플릿은 실제로 내가 만든 또 다른 템플릿인 {{접이 가능한 그룹}}}에서 생성된다.더 나은 해결책을 찾을 때까지 vde를 그만둘까 봐.고마워요.£N마jdan•talk 13:01, 2007년 10월 19일(UTC)

반면에, 전체 링크를 글꼴 태그 안에 감싸는 것도 효과가 있는 것 같다... — Edokter • Talk • 17:23, 2007년 10월 19일 (UTC)

<참조/> 태그 필요

횡단 편집

기사 섹션을 편집하여 새 <ref> 항목을 추가한다고 가정하십시오.미리보기 표시 시 미리보기에는 기사 텍스트는 표시되지만 참조는 표시되지 않으므로 실제로 변경한 내용은 표시되지 않는다.또는 텍스트와 참조를 추가하면 변경 내용 중 일부를 볼 수 있지만 모든 변경 내용은 볼 수 없다.

이 문제에 부딪치면 대개 섹션 끝에 <참조/>를 임시로 추가하는 식으로 일을 한다.그런 다음 미리 보기를 표시하고, 오류를 수정하고, <참조/>를 제거하고 페이지 저장을 한다.그러나 그것은 분명히 오류가 발생하기 쉬운 일인데, 왜냐하면 사람의 본능은 오류가 수정되는 즉시 페이지를 살리는 것이고, <참고/> 태그를 떼고 그 후에 다시 가서 해야 한다는 것을 잊어버리는 것은 너무나 쉬운 일이기 때문이다.

기술적인 해결책이 떠오른다.편집 중인 섹션에 <ref> 태그가 포함되어 있지만 <reference/>가 포함되어 있지 않다면 소프트웨어에 {{preview-reference}}와 같은 템플릿 참조를 추가해야 하며, 이는 이와 같은 것으로 확장될 것이다.

--"미리보기할 섹션에는 다음과 같은 참고문헌이 포함되어 있는데, ""전체 기사는 &lt;참고문헌/" 태그에 표시된다:" <참고문헌/>

물론 참고문헌이 아닌 단원의 텍스트만 편집하고 있다면 굳이 확대된 것을 볼 필요는 없고, 그저 귀찮을 뿐이다.다른 접근방식은 별도의 참조 미리보기 버튼이 될 수 있지만, 그것은 나에게 과잉 살상으로 보인다.

일관성 검사

이와 관련된 점에는 양쪽 한 구역 및 기사 편집을 위해 경우에 기사 하나 이상의<>를 포함하는 것은 사실 ref&gt을 가두고 싶습니다.<>없이 태그, references/&gt며, 또는 두개 이상의<>포함하는 그들을 확대할 것 태그, references/>, 태그. 바람직하지 않을 것이다(실험은 각각의<>references/>, 모든<>팽창합니다;ref>, 있을 것을 보여 준다.Gs에 함께에 출연하다.틱, 그러니까 모든 <ref> 태그 뒤에 정확히 한 개의 < </> 태그가 있어야 한다.)미리보기 쇼가 끝났을 때, 이 시점에서 페이지 저장을 한 경우, 그리고 이러한 잘못된 상황이 있을 경우 경고(미리보기 창이나 다른 곳에서는 놓칠 수 없을 정도로 두드러진 경우)를 발령해야 할 경우, 기사 전체에 대해 점검을 실시할 것을 제안한다.

누군가 기사에 첫 번째 참조를 추가했을 때 어떤 일이 일어나는지 고려해야 하기 때문에, 이것은 저장을 막는 오류 메시지가 아니라 미리보기 시간에 발령되는 경고가 되어야 한다고 생각한다.섹션 편집 중에 이 작업을 수행하면 먼저 참조 섹션을 추가하는 것을 잊어버렸기 때문에 저장을 차단하지 않으려는 것이다.마찬가지로, 정리 작업을 수행하는 사람이 문서를 위에서 아래로 순서대로 여러 개의 참조를 추가하여 한 번에 한 섹션씩 저장한 후에 마지막에 가서 참조를 추가할 수 있다.그러나 참고문헌 섹션을 추가하도록 상기시킬 필요가 있다.

아니면 더 크게 생각하는 것

더 크게 생각한다면, 더 나은 접근법이 있을 겁니다. 비록 내가 이것을 처음으로 생각하는 사람이 될 수는 없겠지만, 아마도 이 방법이 사용되지 않는 데는 그럴만한 이유가 있을 겁니다.그러나 지금 내게는 분명한 <참고/> 태그의 전체 생각을 잊어버리고, 위키피디아를 통해 봇을 보내서 그것들과 관련 부분을 없애도록 하는 것이 옳은 일처럼 보인다. 그리고 대신 단순히 전체 섹션을 갖는 것이 옳다.

==참조=<참조/>

Wikitext가 HTML로 렌더링될 때, <ref> 태그를 포함한 모든 글의 위키텍스트에 암시적으로 추가된다(또는 그와 동등한 동작).그리고 미리보기를 할 때 어느 섹션에서도 마찬가지다.

물론 이 변화는 나의 다른 두 가지 사항에서 다룬 두 가지 문제를 모두 다룰 것이다.

--207.176.159.90 23:09, 2007년 10월 18일(UTC)

마지막 한 가지 문제점은 참고문헌이 기사의 마지막 섹션이 아닌 경우가 매우 많으며, 실제로 그렇게 되어서는 안 된다는 것이다.태그를 사용하는 목적은 참조가 배치되는 정확한 위치와 형식 지정에 있어 어느 정도의 유연성을 허용하는 것이다.TCC (대화) 01:26, 2007년 10월 19일 (UTC)

단, (1) 하나 이상의 <ref> 태그가 부딪혔고 (2) 위키텍스트에서 <참조/> 태그가 마주치지 않았다면, "ERROR!! 같은 것을 추가하는 것이 좋을지도 모른다. <참조> 태그는 보이지 않았다. ERROR!! - 인용된 참조는 다음과 같다." 그리고 나서 암시적인 <참조> 태그를 추가한다. -- 보라카이 빌 03:00, 2007년 10월 19일 (UTC)

오류보다는 경고 메시지가 유용할 가능성이 높으며 구현하기 특별히 어렵지 않은 특징이 될 수 있다.그러나 참조 태그를 자동으로 추가한다는 개념은 많은 문제를 열어놓는데, 그 중 하나는 Csernia가 언급했던 것이다.참조 블록을 페이지에 추가하는 방법의 정확한 성질은 상당히 의도적으로 명시적으로 정의되지 않는다.기사에서 참조 블록이 발생하는 경우, 기사의 작성자에게 맡겨서 원하는 대로 형식을 지정할 수 있도록 해야 한다.참조 블록이 없는 것이 사실 올바른 경우가 많다 - 다양한 소스를 인용하는 템플릿 또는 infobox를 고려한다; 일반적으로 템플릿 자체보다 템플릿이 변환되는 페이지의 참조 블록에 이 템플릿에 인용된 소스를 포함하는 것이 더 낫다.사실, 나는 현재 Cite의 가장 큰 문제들 중 하나는 그것이 특정 페이지에서 참고문헌이 어떻게 사용되는지를 편집자들이 커스터마이징할 수 있는 충분한 능력을 허용하지 않는다는 것이라고 매우 믿는다. 이 제안은 아주 사소한 불편함을 완화하기 위해 그들의 사용을 훨씬 덜 커스터마이징 할 수 있게 하려고 한다.내가 가장 중요하게 생각하는 한 가지는, 예를 들어 "노트"와 "소스"가 서로 분리될 수 있도록 주어진 페이지 내에서 서로 다른 종류의 참조 유형을 정의하는 능력이다.나는 또한 현 시스템이 그렇지 않은 MLA와 같은 다른 형태의 텍스트 인용문, 즉 MLA를 사용할 수 있도록 하는 것이 중요하다고 생각한다.Cite의 개혁에 대한 많은 논의가 최근에 이루어졌고, 우리는 곧 그 시스템에 약간의 변화를 보게 될 것이다.읽을 가치가 있는 것은 위키피디아-l의 최근 실이다.아미다니엘 (토크) 03:21, 2007년 10월 19일 (UTC)

좋아, 문제가 많으면 그 제안은 잊어버려.그러나 나는 나의 처음 두 하위섹션이 그 경우에 다루어졌으면 한다. --207.176.159.905:07, 2007년 10월 19일 (UTC)

처음 두 개의 하위 섹션은 실행 가능하다.이의가 없는 한 이번 주말에 뭔가 시행하도록 노력하겠다.어쨌든, Cite는 해결해야 할 많은 문제들을 가지고 있다. - 당신은 빙산의 일각에 거의 부딪치지 않았다.) AmiDaniel (토크) 06:33, 2007년 10월 19일 (UTC)

아미다니엘, <ref> 태그가 마주쳤는데도 여전히 참조 블록이 없는 것이 맞는 경우가 있는가?그런 상황에서 경고 메시지를 통해 기사의 맨 끝에 참조를 확대하거나, 경고 메시지가 나타나지만 확장되지 않은 참조가 숨겨져 있거나, 확장되지 않은 참조가 경고(현재 행동) 없이 숨겨져 있는 것이 더 유용한가? -- 보라카이 빌 05:46, 2007년 10월 19일 (UTC)

물론 있었다.머리 위로는 엔위키에 대한 생각이 떠오르지 않지만, 내가 직접 이런 스타일의 템플릿을 구현했다는 것은 알고 있다.그러나, 문제는 참조 태그 없이 참조 태그를 갖는 것이 괜찮아야 하는지에 관한 것이 아니라, 그러한 태그를 배치할 장소나 여부를 소프트웨어 또는 편집자가 결정해야 하는지에 관한 것이다.IMO, 올바른 동작은 편집기를 저장한 후, 일치하는 참조 블록이 없는 참조 태그가 있음을 편집자에게 경고하는 것이다.아미다니엘 (토크) 06:30, 2007년 10월 19일 (UTC)

(다음 50)

모든 기사의 편집 내역 페이지에는 다음과 같은 링크가 있다.

(50)(다음 50)

불행히도 역사는 역순으로 나열되기 때문에, 목록 순서의 '다음 50'은 연대순으로 '이전의 50'이며, 일단 두 페이지의 항목을 지나치면, 나는 항상 잘못된 링크를 클릭하며 더 뒤로 가는 대신 제 시간에 전진하는 자신을 발견하게 된다.

다음과 같은 다른 문구를 찾을 수 있는가?

(50대 이상)(50대 이상)

또는

(다음 50 이후)(다음 50 이전)

아니면 뭐 그런 거?

--207.176.159.90 05:14, 2007년 10월 19일(UTC)

MediaWiki talk:를 참조하십시오.다음은 현재 소프트웨어로 변경하려고 할 때 무엇이 잘못되는지에 대한 설명.그 문제가 터무니없이 정리되기는 어려울 것 같지는 않지만, 개발자의 개입이 필요하고, 개발자는 바쁜 경향이 있다. --ais523 09:28, 2007년 10월 19일 (UTC)

내가 만든 기사

인터리엇은 사용자가 만든 모든 기사를 표시하는 도구를 가지고 있다고 들었는데, 대본은 실패한 것 같고 인터리엇은 AWOL이다.나는 기술적으로 전혀 생각이 없다. 그러나 만약 대안에 대해 알고 있고 내 Talk 페이지를 ping할 수 있다면 그것은 훌륭한 Dick G 05:13, 2007년 10월 11일 (UTC)

허허, 그냥 똑같은 질문을 하려고 온 거야.특수:기고문은 새 기사와 특별 기사로 표시되지 않는다.위키피디아의 새로운 페이지는 적어도 그리 오래 거슬러 올라가지 않는다.스페셜(Special)을 얻는 것은 얼마나 어려울까?Specia와 같은 새로운 기사를 표시하기 위한 기부금최근의 변화들이 그래?고마워^Talk. - 2007년 10월 11일, 18:07, Taxman 18:07

http://tools.wikimedia.de/에 또 다른 도구가 있었지만, 2007년 10월 11일(UTC) 알렉스 스모트로프 18:25, 둘 다 작동하지 않는 것 같다.

나는 사용자 통계를 제공할 수 있는 도구를 가지고 있다. 로그 목록은 [1]을 참조하라. 나는 그것을 원하는 모든 사람을 위해 기꺼이 실행한다.β^_command 20:36, 2007년 10월 13일 (UTC)

나도 이걸 어떻게 하는지 알고 싶어.내가 만든 기사로 돌아가고 싶을 때, 그리고 목록 등을 유지하려고 해도 기사 이름을 기억할 수 없을 때, 그것은 나를 미치게 한다. --Mattisse 16:39, 2007년 10월 20일 (UTC)

MediaWiki:시테노티스가 나타나지 않음

칸나다 위키백과에서 누군가 새로운 사이트 공지사항을 설정하려고 했지만, 그 메시지는 현재 어떤 것으로 설정되었든 전혀 나타나지 않는다.aon에도 메시지가 나타나지 않기 때문에 사이트 공지 ID가 아니다. -- Kassad 12:59, 2007년 10월 20일(UTC)

구식 시테노티스는 일단 이번 모금행사를 위해 중앙으로 교체되었다. --briion 18:57, 2007년 10월 20일 (UTC)

페이지 하단의 I/W 링크?

내 monobook.css를 사용자 지정하여 페이지 하단에 모든 인터위키 링크를 왼쪽의 상자 대신 표시할 수 있는가?다음은 미디어위키 사이트의 무작위 사례. -(쿠빅[*]스타(토크(이메일)) 13:55, 2007년 10월 20일(UTC)

리디렉션에 연결된 페이지

안녕!

방금 MV Liemba를 편집해서 Liemba를 연결 해제했는데, 이 링크는 물론 MV Liemba로 리디렉션된다.더블 리디렉트처럼 이런 일을 하는 봇이 있지 않은가?아니면 그들은 트윗이 필요한가?생레인 18:24, 2007년 10월 20일 (UTC)

중첩 테이블 클래스="접을 수 없음"

만약 누군가가 이 문제에 대한 해결 방법을 알고 있다면, 나도 그것이 무엇인지 알고 싶다.버질라에서도 그것에 대한 어떤 것도 찾을 수가 없었다.

내포된 접이식 테이블 몇 개를 대략 다음과 같이 코드화했다.

{ class="collapsible collapsed" !Outer table header row  -   interesting information  -   { class="collapsible collapsed" !Inner table header row  -   more detailed interesting information  -   { class="collapsible collapsed" ! Inner inner table header row  -   Even more detailed information that's not particularly interesting  }  }  }

다음과 같은 내용이 있다.

모두 부전승으로 무너져야 한다.하지만 바깥쪽 테이블을 확장하면 모든 안쪽 테이블도 확장되지만, 그들의 "쇼" 링크에는 "쇼"라고 쓰여 있다.Javascript는 확대한 걸 모르는 것 같아."표시"를 클릭하면 "숨기기"로 바뀌지만 다른 작업은 하지 않는다.이후 링크가 정상적으로 작동한다.

생각나는 거 있어?TCC (대화) 09:58, 2007년 7월 1일 (UTC)

의도한 대로 사용하지 않는 것 같군.보금자리를 지지하지 않는 것 같군.내가 주변을 둘러보고 답안과 정확한 코드를 조금 후에 가져다 줄게.—Andrew Hampe 23:17, 2007년 7월 1일 (UTC)

당신이 알 수 있도록, 한 가지 요건은 초기 상태를 지정할 수 있어야 하는데, 그래서 내가 NavFrame 등 대신에 테이블을 사용하는 겁니다.TCC (대화) 01:33, 2007년 7월 2일 (UTC)

접을 수 있는 하나의 테이블(예: {{Miculus footer}) 안에 3개의 NavFrames를 넣어 중첩된 테이블을 숨길 수 있다.2개 이하로만 둥지를 틀어도 빈 NavFrame div를 추가하여 숨길 수 있다.내포된 NavFrames를 기본적으로 확장하는 방법은 모르겠지만, 2개 이하로 내포하지 않는 한.–Pomte 18:55, 2007년 7월 24일 (UTC)

그것은 NavFrames를 사용하는 것의 약간의 문제야, 그래.in fit and starts. 스크립팅의 변경 사항을 적용하여 스크립팅 작업을 수행할 수 있는지 확인하고 있다.그래도 좀 느리긴 한데, 자바스크립트나 DOM은 처음이라서.TCC (대화) 02:07, 2007년 8월 10일 (UTC)

정리했다.나는 대본이 페이지 로드로 실행되는 순서에 대해 바보 같은 실수를 한 적이 있다.아마 굉장히 엉뚱할 텐데 JS와 DOM에서 경험이 있는 사람이 한번 보고 내가 뼈빠지게 한 일이 있는지 말해줄 수 있을까?사용자: 참조:Csernica/monobook.js.이걸 Common.js에 넣을 확률은?TCC (토크) 07:26, 2007년 8월 15일 (UTC)

재정의 클래스="해당 항목"

위키백과 수업을 무시해야겠어.특히 매력적인 #f2f2f2 테이블 헤더를 다른 색으로 교체해야 해.머리글 행에 머리글을 추가하려고 했는데, 위키피디아 클래스가 내 맞춤 스타일보다 우선인 것 같아.그렇다면 어떻게 위키피디아 클래스를 재정의할 수 있을까? -- --иро 05:14, 2007년 8월 21일 (UTC)

"style"보다 "class"를 먼저 배치하여 올바르게 재정의하십시오.더 이상, 그리고 나는 당신이 하고자 하는 일의 예를 보여야 한다(예를 들어, 당신은 당신의 사용자 공간에 페이지를 설정할 수 있다.EVULA// 토크 // 05:17, 2007년 8월 21일 (UTC)

요소의 클래스 및 스타일 속성 순서는 문제가 되지 않아야 한다.아노미 14:02, 2007년 8월 21일 (UTC)

응, 그래야지; "CSS"의 "C"는 계단식이야.먼저 만들어진 선언은 이후 선언에 의해 재정의된다(즉, 시트 X가 h2 태그는 녹색이어야 한다고 말하고 시트 Z가 h2 태그는 빨간색이어야 한다고 말하는 경우, 모든 시트가 마지막으로 포함되는 것은 표시 방법을 결정하지만, 특정 h2 태그는 파란색이어야 한다는 인라인 스타일로 덮어쓸 수 있다).EVULA// 토크 // 2007년 8월 21일 (UTC)

하지만 시트 W가 SPAN 태그는 파란색이어야 하고 인라인 스타일은 주황색이어야 한다고 말한다면,<span class="SheetW" style="color:orange">그리고<span style="color:orange" class="SheetW">등가(즉, 주황색)이다.비슷한 것이 예에 해당 예는 다음과 같다.<h2 class="SheetX SheetZ">그리고<h2 class="SheetZ SheetX">등가물이다.아노미 21:34, 2007년 8월 21일 (UTC)

예를 들어, --MZMcBride 06:43, 2007년 8월 21일(UTC)

MediaWiki를 보면:Common.css, 배경색이 TH 요소에 적용되고 있음을 알 수 있다.따라서 행이 아닌 각 셀에서 스타일 오버라이드를 지정해야 한다.클래스를 오버라이드할 수 있는 충분한 이유("이 컬러가 더 좋다"는 것만이 아니라)가 없다면, 사용자 선호나 스킨이 컬러를 오버라이드하는 것을 막을 수 있기 때문에, 나는 이것을 하지 말라고 충고하고 싶다.아노미 14:02, 2007년 8월 21일 (UTC)

미친 짓이라고 하지만..

..샌드박스 역사 페이지 중간에 (udnu) 버튼을 보는 사람은 나뿐인가?확인해 봤는데, 편집 요약에 없는 건데, 소프트웨어가 이 특정 수정판에 대해 어떻게 해서든 거꾸로 실행 취소 버튼을 만들고 있는 거야!AES 뒤로 또는 샌드박스에서 이상한 자바스크립트, css 또는 다른 것을 테스트하는 사람이 있는가?--VectorPotentials^Talk 13:15, 2007년 10월 19일(UTC)

아, 편집자가 방금 편집 요약에 '역방향' 유니코드 문자를 넣은 것 같은데, 아랍어 등으로 쓰인다. — Edokter • Talk • 2007년 10월 19일 (UTC)

그때는 신경쓰지 마십시오. --VectorPotential^Talk 13:37, 2007년 10월 19일 (UTC)

파일을 공용에 업로드할 수 없음

누가 좀 도와줄래?왠지 wp:commons에 이미지 파일을 업로드할 수 없다.내가 "목적지 파일 이름" 가젯을 입력하면, 이 이상한 빨간불 아이콘이 그 가젯 옆에 깜박이고, 내가 "업로드" 버튼을 눌렀을 때, 아무 일도 일어나지 않는다.외부 사이트와 내 PC에서 파일을 업로드해 봤지만 별 차이가 없다.이미지 저작권 선택 상자는 "미국 연방 정부"로 설정되어 있으므로 문제가 되지 않는다.wp:이미지 및 wp:commons 마을 펌프에 메시지를 남겼으나 응답이 없었다.고마워요.가토클라스 04:41, 2007년 10월 20일 (UTC)

내가 답을 찾은 것 같아, 그의 토크 페이지에 어메세지를 남겼어.그가 내게 돌아오면 확실히 알게 될 거야.TomStar81 (토크) 05:28, 2007년 10월 20일 (UTC)

사실 톰의 해결책은 효과가 없었지만 나는 그 문제의 일부를 알아냈다.웬일인지 내가 나브소스 온라인에서 직접 jpegs를 업로드하려고 하거나, 내 PC에 저장해 놓고 거기서 업로드하려고 해도 커먼스가 이를 인식하지 못한다.하지만 내가 같은 jpeg 파일을 가져다가 MS Paint에 jpeg로 저장하면 갑자기 Commons가 그 파일을 인식해서 업로드 할 수 있다.

문제는 MS Paint는 일정 크기를 넘어서는 사진을 다룰 수 없을 것 같은 다소 한정된 프로그램이고 나는 다른 페인트 프로그램을 가지고 있지 않기 때문에, 이런 일이 왜 벌어지는지 누군가 알아낼 수 있다면 그래도 고맙겠다.가토클라스 11:31, 2007년 10월 20일 (UTC)

다른 웹 사이트에서 직접 이미지를 업로드할 수 없다.먼저 컴퓨터에 저장해야 한다.이미지 편집자에 한해서는, 나는 KIMP를 추천한다.Windows용 KIMP는 http://gimp-win.sourceforge.net/에서 다운로드할 수 있다.

웹 브라우저에 문제가 있을 수 있음어떤 웹 브라우저를 사용하십니까?—2007년 10월 20일 점 기억(UTC)

제보를 해줘서 고마워:김프, 내가 한번 볼게 :)

현재 IE 7. 가토클라스 04:32, 2007년 10월 21일 (UTC)

Javascript 질문(생각해)

나는 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 및 Windows Vista를 사용하고 있다.최근에 나는 본문에서 커서를 움직이게 하는 것과 같은 간단한 일들을 하는 위키피디아에 어려움을 겪고 있다.기사 텍스트 내에서 편집하면서 탐색하는 것은 점점 더 어렵고 신뢰할 수 없다.쉽게(그리고 겉보기에 이유 없이) 텍스트의 전부 또는 일부를 선택하게 되고(파란색 또는 회색으로 바뀜) 보통 나는 이 문제를 완화하기 위해 페이지를 나왔다가 돌아와야 한다.나는 위키백과 이외의 다른 문제는 가지고 있지 않기 때문에 이것이 위키백과 문제인지 궁금하다.(또한, 텍스트가 이리저리 뛰어다니거나 통제 불능으로 스크롤되는 등) 마치 자바스크립트(또는 그 밖의 것)가 너무 빨리 작동하는 것처럼 제어력을 잃기가 매우 쉽다.내가 이 문제에 대해 말이 되는가?고마워, --Mattisse 15:59, 2007년 10월 20일 (UTC)

긴 페이지(즉, 소스 텍스트가 32kb 이상인 페이지)를 편집하시겠습니까?그것은 일부 브라우저에 문제를 일으키는 것으로 알려져 있다.니힐트레스^(t.l) 16:41, 2007년 10월 20일 (UTC)

문제를 일으키는 스크립트인지 쉽게 알아낼 수 있는 방법은 Firefox에서 Javascript를 비활성화한 다음 문제가 여전히 존재하는지 확인하는 것이다. — Edokter • Talk • 2007년 10월 20일 (UTC)

네, 아마 긴 페이지일 겁니다.오늘 여기에 게시해도 문제없어.또한, 종종 무언가가 나타나기 전에 오랜 지연이 있다.어제 나는 처음 아무 일도 일어나지 않는 것 같았기 때문에 여러 번 서명을 한 것을 알았다.하지만 내가 Preview를 보았을 때 나는 두 개의 서명을 보았다.또한 한 사용자 페이지에 같은 글을 세 번이나 올렸는데, 그 이유는 "위키피디아에 문제가 있다"는 메시지가 계속 올라오고 있고, 게시되는 줄도 몰랐기 때문인데, 그 사용자들은 내가 일부러 그런 줄 알고 '아이답다'라고 불렀기 때문이다.답장 고마워! --Mattisse 17:40, 2007년 10월 20일 (UTC)

일반적인 응답인 것은 알지만, 제어판의 Windows Update로 이동하여 어떤 이유로 인해 컴퓨터에 아직 업데이트되지 않은 안정성 업데이트가 있는지 확인해보셨습니까?—2007년 10월 21일 01:15, 점 기억(UTC)

특정 기사에 대한 IP 블록/범위 블록의 기술적 타당성

그래서 여기 내가 방금 생각해낸 것이 있는데 아마도 (a)는 반복적으로 질문을 받았고 (b)는 불가능하다.특정 IP(또는 더 유용하게 일부 IP의 범위를 차단하여 특정 기사를 편집하지 못하도록 Mediawiki를 언젠가 기술적으로 수정할 수 있을까?

IP를 사용하는 사람이 41.242.xxx 범위에 있어서 그런 생각을 했다.xxx는 이것이 그들이 지금까지 본 것 중 가장 우스꽝스러운 것이라고 생각하여, 지난 주에 자유주의(Libertarianism)에 6개의 다른 IP를 사용하여 약 9번 추가했다.만약 이것이 계속된다면, 어떤 해결책도 정말로 만족스럽지 않다: 레인지 차단도 남아공의 큰 척을 차단할 것이기 때문에 과민반응을 보일 것 같다; 페이지 보호도 좋지 않다, 이 특정 기사는 IP 주소로부터 많은 좋은 편집을 얻고 있다; 그리고 매번 감시하고 계속 되돌아가기만 할 뿐이고 계속 (what 지금 하고 있다)는 것이 귀찮아진다.

자, 만약 여러분이 한 기사에 대한 범위 블록을 할 수 있다면, 혹은 다른 방법으로, IP 주소의 범위에서만 페이지를 보호할 수 있다면, 남아프리카 공화국의 많은 부분이 한 기사에 대해 잠시 동안 편집하는 것을 막을 수 있을 겁니다. 완벽하지는 않지만, 아주 가까운 곳이지요.분명히 이 해결책은 현재 존재하지 않지만, 제 질문은 이 기능을 추가하는 것이 기술적으로 실현 가능한가 입니다.바보 같은 생각이라면 꼬리를 다리 사이에 끼우고 집으로 가고, 그렇지 않으면 처음으로 버질라를 탐험한다. --바네카(토크) 00:59, 2007년 10월 21일 (UTC)

글 한 개에 대한 범위 차단을 하고 있다면 페이지를 보호해보는 게 어때?범위가 좀 넓겠지만, 정말 누가 신경 쓰겠어, 한 기사인데, 임시로 반보호를 하는 거야.프로데고 02:57, 2007년 10월 21일 (UTC)

안녕 프로데고.다른 IP 편집자들이 기사를 편집하는 것을 막고 싶지 않기 때문이다.지금, 우리가 기사를 반보호할 때, 우리는 아기를 목욕물과 함께 내팽개친다.이 특정 기사에서는 합법적인 IP 편집자의 참여도가 평균보다 약간 높은 것으로 보이며, 공공 기물 파손은 아마도 WP:RFPP에서 보호에 필요한 수준으로 올라가지 않을 것이다.그러나 합법적인 IP 참여가 많지 않을 때에도, 그리고 공공 기물 파손이 기사를 휩쓸고 있을 때에도, 언제나 수치스럽게 여겨져 왔다.동적 IP에 대한 한 바보 때문에 모든 합법적인 IP 편집자가 기사를 편집하지 못하도록 차단하기 위해. --barneca (대화) 03:22, 2007년 10월 21일 (UTC)

그러나 또 다른 명백한 브라우저별 css 문제

더글라스_맥아더#Dates_of_rank에 있는 테이블은 Firefox 2.0.0.8을 사용하는 나에게 괜찮아 보인다.Internet Explorer 7.0.5730.11이 그것을 망쳐 놓는다. 세로선은 두 번째 열의 텍스트를 통과한다.CSS는 대단하지 않은가? -- 보라카이 빌 01:59, 2007년 10월 21일 (UTC)

부분적으로 IE 탓이기는 하지만, 실제 원인은 테이블의 이미지 태그에 왼쪽/중앙/오른쪽을 사용하는 것이었는데, 이것은 문제를 일으키는 것으로 알려져 있다(테이블의 dives는 섞이지 않는다).쉽게 고친다. — Edokter • Talk • 2007년 10월 21일 (UTC)

범주가 너무 높게 표시됨

나는 페이지 하단의 일부 텍스트를 덮는 범주가 너무 높게 나타나는 것에 문제가 있다.그것은 모질라에서가 아니라 IE6에서만 일어난다.또한 IE6의 다른 계정을 사용하면 모든 것이 정상인 이 계정에서만 발생한다.내 모노북에 뭐가 들었는지 확인했지만 찾을 수가 없었다.누구 아이디어 있는 사람?가리온96 (대화) 2007년 10월 21일 14:30 (UTC)

나는 가끔 그것을 가지고 있다.창의 크기를 조정하면 자동으로 지워진다. — Edokter • Talk • 2007년 10월 21일 (UTC)

그래, 그건 그냥 좀 이상해.됐다!고마워요.원인이 뭔지 알아?IE6 버그만?가리온96(토크) 2007년 10월 21일 14:48(UTC)

내 추측으로는...어쨌든 범주 상자를 제어하는 CSS를 살펴보겠다. — Edokter • Talk • 2007년 10월 21일 (UTC)

고마워, 네가 뭔가를 찾길 바라.이상하긴 한데, 지난 며칠 이후로만 그런 일이 있어.그래서 그 기간 동안 뭔가 바뀌었을 것이다.가리온96 (토크) 17:01, 2007년 10월 21일 (UTC)

불행히도 catlinks는 main.css로 정의되어 있어, 나는 그것을 만질 수 없다(거기도 아무 이상이 없다)내가 찾은 유일한 것은 IE60fixes.css:

/* /skins-1.5/monobook/의 규칙 18번IE60Fixes.css?100 */ #catlinks {POSITE: relative}

이유는 모르겠지만, 이것이 아마 카테고리 박스가 가끔 뛰어오르는 이유일 것이다. — Edokter • Talk • 2007년 10월 21일 (UTC)

인터넷 탐험가들의 CSS 기발한 목록들은 정말 어마어마하다.아마 들어보셨을 겁니다만, 사파리나 파이어폭스 같은 더 좋은 브라우저로 전환하십시오.적어도 IE7은 IE6의 많은 문제를 해결한다. 업그레이드는 나쁘지 않을 것이다.EVULA // talk // talk // 03:22, 2007년 10월 22일(UTC)

향수 위키백과에서 역사를 여기로 가져올 수 있도록 만들기

퍼스는 늦은 밤이라서 이건 그냥 뇌파일 뿐이야... 향수 위키피디아에서 이 웹사이트로 페이지 기록을 가져올 수 있게 하는 것이 가능할까?몇몇 배경: 향수의 위키백과는 2001년 12월 11일 데이터베이스 덤프에서 나온 읽기 전용 위키백과 사본이다.하지만 향수에는 약간의 역사가 있는 것 같다.위키피디아는 영어 위키피디아 데이터베이스에 저장되어 있지 않고, 저장되어 있지 않다.이 발상의 세균은 내가 영어 위키백과에서 성인을 위한 가장 초기 역사를 찾아내어 향수 위키백과에서 역사와 비교했을 때 생겨났고, 향수 위키백과에는 저장되어 있지만 영어 위키백과는 저장되어 있지 않은 11개의 편집본을 발견했을 때 생겨났다.향수 위키피디아에는 95,321개의 편집본이 저장되어 있을 뿐이며, 대부분은 아마도 여기서 수입할 필요가 없을 것이다.내가 볼 수 있는 유일한 문제는 그것이 개정 ID의 (매우 높은 숫자가 매우 오래된 편집에 할당될 것이다)를 망칠 수도 있고, 우리는 127.0.0.xxx과 같은 IP 주소를 저장하는 예전 UseModWiki 형태에 문제가 있을 수 있다는 것이다(마지막 옥텟을 발견함).또한 수입할 가치가 있을 수도 있고 없을 수도 있는 CamelCase 타이틀도 있을 것이다.그럴만한 가치가 있을까... 서버에 큰 영향을 줄까?그리고 예, 스페셜:수출이 향수 위키피디아에서 통할 것이다.Graham87 15:25, 2007년 10월 21일 (UTC)

하지만 향수에는 약간의 역사가 있는 것 같다.위키피디아는 영어 위키피디아 데이터베이스에 저장되어 있지 않고, 저장되어 있지 않다.아, 하지만 위키피디아에 저장되어 있었지만, 2002년 The Big Database Crash에서 모든 역사가 사라졌다(? 그럴 수 없어!FAQ 필요). — Edokter • Talk • 2007년 10월 21일 (UTC)

좀 더 이국적인 언어를 보여주는 것...

큰 블록으로만 표시되는 여러 언어가 있다(어떤 종류의 문자가 완전히 반복되어 있거나, 그저 빈 "이 문자는 존재하지 않는다" 블록으로 표시된다).적어도 한 개의 위키에는 텍스트를 제대로 표시하는 방법에 대한 지침이 시테노티스에 있었다는 것을 알고 있지만, 그런 지침이 없는 슬루(slew)가 있는데, 언어를 제대로 볼 수 있도록 어떤 글꼴을 설치해야 하는지 알아보고 싶다.

호기심이 많은 사람들을 위해, 내가 말하는 것은 다음과 같다.

• 벵골어
• 비슈누프리야마니푸리
• 조지아 주
• 다이브히
• 칸나다
• 말라얄람
• 아시리아 네오아람어
• 고딕어
• 크메르
• 아사메세어

그리고 내가 찾고 있는 것은 바로 내 것이다.위키백과:글꼴(언어로 쉽게 편집할 수 있도록 30달러는 지불하지 않는 것이 좋겠지만) 또는 다음과 같은 기능:위키백과:폰트가 안 보이니? 아니면 lo의 링크가 안 보이니?위키백과와 ti.위키백과EVULA // talk // talk // 16:40, 2007년 10월 21일(UTC)

이들 대부분은 실제로 사이트 공지사항을 가지고 있지만, 현재 모든 위키백과에서 사이트 통지는 비활성화되어 있다.Kannada 위키백과는 다음과 같은 내용을 담고 있다.위키백과:Kannada 지원, Malayalam Wikipedia는 ml:സഹാam:To Read in Malayalam, Gothic은 다음과 같은 것을 얻었다.위키백과:고딕 유니코드 글꼴.Bengali는 bn:উইকপেড::::방라스크립트 디스플레이 및 입력 도움말(아사메세지도, 아마도 Bishnupriya Maniffuriurie도 수정한다.Dhivehi는 dv:Tana_Support (하지만 그다지 유용하지는 않다.Khmer의 km:Khmer Unicode 글꼴을 설치하십시오.다른 모든 사람들에게는 글꼴 도움말이 존재하지 않는 것처럼 보이지만, 구글을 사용하여 직접 글꼴을 찾을 수 있다. -- Kassad 05:09, 2007년 10월 22일(UTC) 프린스 카사드 05:09

나는 이것이 형편없는 대답이라는 것을 알지만, 새로운 운영체제는 개봉 즉시 점점 더 많은 유니코드를 지원하고 있다.예를 들어, Windows Vista에는 많은 언어에 대한 많은 국제 글꼴이 제공된다. [2].그래서 사람들이 새로운 소프트웨어로 전환함에 따라 그 문제는 서서히 해결될 것이다.

그렇긴 하지만, 유니코드 문자 집합과 자유 글꼴을 표시할 수 있는 링크를 나열한 페이지는 좋을 것이다.—2007년 10월 22일 05:37 점 기억(UTC)

@Kassad 왕자:나는 사이트 안내문이 장애인인지 전혀 몰랐다.왜?그럼 내가 전에 본 적이 있다고 맹세했던 것에 대한 내 혼동이 설명이 되겠군링크도 고마워지금은 좀 바빠서 확인할 수 없지만, 집에 가서 확인해 볼게.

@점 기억하기:어, 나는 그것이 형편없는 대답이라고 생각하지 않아.나는 유니코드 지원이 뛰어난 Mac OSX를 사용한다. (목록을 컴파일할 때에도, 나는 글꼴을 찾아서 기본적으로 두 번 클릭하기만 하면 위키 몇 개를 제거할 수 있었다. 캐릭터들을 보기 위해 브라우저를 다시 시작하지 않아도 된 것은 꽤 좋은 일이다.)즉, 컴퓨터를 처음 설치할 때 옵션 언어인 *모두*를 설치하면 놀랄 것이고, 시스템 DVD가 어디에 있는지 전혀 알 수 없다. :D 나는 메타 주변을 샅샅이 뒤져서 유니코드 세트 목록이 있는지 알아볼 것이다. 만약 그렇지 않다면, 그러한 목록이 가기 가장 좋은 장소인 것 같다.EVula // talk // talk // 05:53, 2007년 10월 22일(UTC)

위키피디아는 왜 모호한 파일 형식을 사용하는가?

나는 왜 위키피디아가 SVG와 OGG와 같은 모호한 파일 형식을 사용하도록 권장하는지 궁금하다.난 이런 것들을 다룰 줄 알 만큼 기술에 정통하지만, 우리 가족은 그렇지 않다.내장된 자동 렌더링을 통해 이러한 포맷의 접근성을 향상시키는데 집중하는 것이 증가했다는 것을 알고 있지만, 그것들은 여전히 보편적으로 접근하기 쉬운 JPG, PNG, WAV, MP3만큼 사용하기에는 그리 간단하지 않다.위키피디아는 정보의 접근성을 강조해야 하지 않을까?—Cromanity가 추가한 서명되지 않은 코멘트 준비 (대화 • 기여) 2007년 10월 21일 (UTC) 19:48, 21

음, SVG는 JPG 포맷의 완전한 대체물이 될 수 없을 것이다.이것의 목적은 벡터 기반 이미지인데 반해, JPG는 사진을 찍기에 더 좋다. 이미지 같은 것은 있을 수 없다.존 토마스 그리피스 포즈.jpg는 SVG 버전으로 대체될 수 있다.PNG에 대한 유사한 주장.

OGG 대 다른 오디오 포맷에 대해서는 MP3가 독점 포맷이고(OGG는 그렇지 않은 반면) OGG가 WAV보다 더 잘 압축되기 때문이라고 생각한다(그리고 내가 틀릴 수도 있다.EVULA // talk // talk // 2007년 10월 21일(UTC)

내가 이해한 바와 같이 위키피디아는 정식으로 문서화되어 있고 특허에 의해 구속되지 않는 형식을 선호한다.따라서 PNG는 목적에 맞게 완벽하게 허용되어야 한다(즉, 로고나 만화 같은 픽셀 그래픽).SVG는 허용 가능한 벡터 형식이고, OGG는 허용 가능한 압축 음악 오디오로, 둘 다 번호가 없고 공개적으로 문서화된다.그러므로 그것들은 숫자형식보다 선호된다. 예를 들어, 오디오용 MP3 또는 수십 개의 전용 벡터형식들 중 하나.벡터 형식은 기본 데이터가 벡터 형식일 때 픽셀 형식보다 선호되는데, 벡터 파일은 손실 없이 확장할 수 있기 때문이다.이는 사진에 사용되는 압축 화소 형식인 JPG를 남긴다.우리는 번호 없는 좋은 대안이 없기 때문에 그것을 감수하고 살아간다.위키피디아가 번호 없는 포맷을 선호하는 이유는 이론적으로 특허권 보유자가 특허 번호 포맷을 사용하면 당신을 정지시킬 수 있기 때문이다.이것은 실제로 1990년대 후반 당시 우연한 GIF 포맷으로 일어났다.오픈소스 커뮤니티는 며칠 안에 PNG 포맷을 만들어 대응했지만, 변환 헤즐은 끔찍했다.우리 중 원한을 품은 자는 다시는 유니시스로부터 사지 않을 것이다. -아공 04:17, 2007년 10월 22일 (UTC)

파랑

나만 그런가, 아니면 메인 스페이스가 아닌 모든 페이지가 약간 파란색으로 바뀌었나? - BANG! 04:09, 2007년 10월 14일(UTC)

그들은 항상 약간 푸른색이었다.—2007년 10월 14일 04:12, 점 기억(UTC)

난 그렇게 생각하지 않아...전에는 백인이 아니었어? - BANG! 04:16, 2007년 10월 14일 (UTC)

아니오. 이전에 컴퓨터의 색 깊이를 너무 낮게 설정하여 페이지가 흰색으로 표시되었는지 확인하십시오.—2007년 10월 14일 04:17 점 기억(UTC)

오, 그렇군고마워! - BANG! 04:19, 2007년 10월 14일 (UTC)

그것들은 약간 파란색이다!와, 난 사실 그걸 전혀 몰랐어.이상하다. 화로정신 (대화 · 기여) 04:04, 2007년 10월 15일 (UTC)

또한, 내가 사용한 몇몇 화면들은 흰색처럼 매우 밝은 색상을 보여준다; 나는 그 화면들에서 파란 배경(또는 심지어 악명높은 ambox 'pastel-shaded box' 배경도 볼 수 없었다.--ais523 08:08, 2007년 10월 15일 (UTC)

응, 하지만 그건 보통 모니터 설정을 빙빙 돌려서 고칠 수 있어.BTW, 비기사 스페이스 페이지가 항상 파란색인 것은 아니다.2004년 7월 3일 이후로 모노북에서는 아주 옅은 푸른 색조였습니다.[3] Lupo 08:43, 2007년 10월 15일 (UTC)

몇 분 동안 모두 흰색으로 변했는데, 위쪽의 위키백과 스팸이 막 시작되었을 때, 그들이 연관되어 있는지 알 수 없었다.하지만 이제 다시 파란색으로 돌아왔어.진 나이거드 23:18, 2007년 10월 22일 (UTC)

Pic 코드가 작동하지 않음

나는 오늘 나의 첫 이미지를 기사에 넣으려고 했다 - USS Card의 사진을 시애틀-타코마 조선 페이지에.불행히도 그 암호는 원래대로 되지 않을 것이다.두 가지 명령만 따를 뿐 세 가지는 복종하지 않을 것으로 보인다.예를 들어, 내가 원하는 곳과 내가 원하는 크기를 가진 순간, 자막은 표시되지 않는다.캡션을 표시하도록 설정하면 크기나 위치 매개 변수가 손실된다.

나는 IE 7을 사용하고 있는데, 그게 무슨 차이가 있는지 모르겠어.하지만 다른 모든 페이지에 있는 사진들은 잘 보이는데, 이건 왜 안 돼?가토클라스 16:03, 2007년 10월 21일 (UTC)

'썸' 파라미터를 찾고 있었던 것 같은데?도움말 참조:이미지 표시 방법의 이미지. — Edokter • Talk • 17:50, 2007년 10월 21일 (17:50 (UTC)

아니, 난 엄지손가락을 찾는게 아니야.엄지손가락이 너무 작다.나는 오른쪽에 자막과 경계를 이루는 350px의 이미지를 갖고 싶다.다른 사람들은 모두 문제없이 이것을 관리하는 것 같지만, 왠지 그 코드가 나에게는 통하지 않을 것 같다.내가 다른 사람과 다른 일을 하고 있다는 것을 알 수 없어서, 정말 짜증나.가토클라스 17:54, 2007년 10월 21일 (UTC)

좋아, 편집했구나.그래, 그게 내가 원했던 거야, 고마워!하지만, 코드가 여전히 도움말 페이지에 설명된 대로 작동하지 않는데, 오른쪽이 아닌 왼쪽에 이런 이미지를 두려면 어떻게 해야 할까?가토클라스 17:59, 2007년 10월 21일 (UTC)

그런 다음 '왼쪽' 매개 변수(350px 왼쪽 엄지손가락 )를 추가하십시오.썸 이미지는 기본적으로 오른쪽에 있다. — Edokter • Talk • 18:01, 2007년 10월 21일 (UTC)

방법을 알면 쉬어!에독터에게 정말 고마워, 나는 이 문제에 대해 매우 짜증을 내고 있었어.도움말 페이지에서는 "썸"과 픽셀 크기를 명시해야 한다는 것이 전혀 명확하지 않다. 나는 당신이 그것만 있으면 된다고 생각했고 그것이 나를 당황하게 했다.가토클라스 18:14, 2007년 10월 21일 (UTC)

음, "썸" 기능은 크기와 마찬가지로 완전히 선택 사항이야.그러나 도움말 페이지가 좀 더 명확할 수 있다.EVULA // talk // talk // 2007년 10월 21일(UTC)

"썸" 파라미터가 포함되기 전까지는 사진이 제대로 표시되지 않았다.그래서 나는 그것이 전혀 "선택적"이라고 생각하지 않는다.이미지의 크기를 줄이려면 필드가 필수인 것 같다.가토클라스 04:01, 2007년 10월 22일 (UTC)

전혀 아니다.크기를 항상 지정할 수 있다.'썸' 옵션은 캡션을 표시하는 테두리만 만든다.그러나 주어진 크기가 없으면 엄지손가락은 기본적으로 150px로 되어 있다. — Edokter • Talk • 14:09, 2007년 10월 22일 (UTC)

오, 좋아, 테두리와 캡션을 얻기 위해서는 엄지손가락이 필요해.그것은 내가 이전에 축소된 이미지를 얻을 수 있었지만 캡션과 함께 그것을 이해할 수 없었기 때문에 말이 된다.

해명해줘서 다시 한 번 고맙네, 에덕터. 나는 이제야 세부사항들을 다 알게 된 것 같아.) 하지만 나는 가서 이미지 페이지를 다시 읽어야 할 것 같아. 왜냐하면 나는 이 세부사항들 중 어떤 것도 읽은 기억이 나지 않고 만약 그것이 없다면, 누군가가 그것들을 추가해야 할 때야.가토클라스 15:37, 2007년 10월 22일 (UTC)

"thumb"를 사용하지 않으면 캡션 텍스트가 Alt 텍스트가 되는데, 이 텍스트는 마우스 포인터를 이미지 위에 올려 놓았을 때(이미지를 클릭하지 않고)만 볼 수 있다.(SEWilco 15:58, 2007년 10월 22일 (UTC)

그래, 네 말이 맞는 것 같아.가토클라스 18:06, 2007년 10월 22일 (UTC)

일부 스킨에 링크 누락

스킨스 클래식, 쾰른 블루, 향수에는 "Cite this writory"와 "영구적인 링크"가 없다.고의야?도움말:기본 설정#Skin은 "일부 링크는 모든 피부에 존재하지 않는다"고 말하지만 이러한 링크는 언급하지 않는다.일관된 연계가 없는 것은 비현실적으로 보인다.위키백과:위키피디아의 말을 인용하면 "이 기사에게 귀기울여라"고 가정하고 위키피디아에서 인용 도움을 요청하는 사람들은 다음과 같이 말한다.헬프 데스크는 종종 "이 기사를 초대하라"는 말을 듣는다.2007년 10월 22일 프라임헌터 00:25 (UTC)

그것은 적어도 고전과 향수의 가죽을 위해 의도적이다 - 그것들은 모노북 가죽이 발명되기 전에 위키피디아가 어떻게 보였는지 되돌아보는 것이다 - 위키피디아: 참조:미디어위키 1.3 및 위키백과:Old Wikipedia 반환을 위한 아카이브/페티션. 다른 무엇보다도 당시 새로운 모노북 피부에 대한 몇 가지 논의를 위한 것이다.영구적인 링크 특성은 2005년 6월에 추가되었고 이 기사 링크를 인용한 것은 2005년 11월에 추가되었기 때문에 그러한 링크를 향수와 고전적인 스킨에 추가하는 것은 전적으로 시대착오적인 일일 것이다.쾰른 블루 스킨의 디자인은 잘 모르겠지만, 미디어위키의 첫 번째 버전에 포함되었다.미디어위키처럼 피부마다 다른 JavaScript 파일로 보고 어떻게 링크를 추가할지 모르겠다.모노북.js는 더 이상 사용되지 않는다.사실 네가 말한 세 가지 스킨은 자바스크립트를 지원하지도 않아.Graham87 09:37, 2007년 10월 22일 (UTC)

특수:Whatlinkshere

Special에 얼마나 걸리는 시간:업데이트할 링크여기는?루이지30 (Taλk) 13:02, 2007년 10월 22일 (UTC)

이는 작업 대기열의 길이에 따라 달라진다. 템플릿이 변경될 때, whatlinkshere 테이블을 업데이트하는 것은 해당 대기열에 추가된 사항 중 하나이다.그러나 작업 대기열 항목의 수와 소요 시간을 비교할 메트릭은 모른다.Graham87 13:53, 2007년 10월 22일 (UTC)

Refdesk 로드 문제

나는 마지막 날까지 리프데스크를 적재하는 데 문제가 있음을 알아차렸다.나는 그들이 로드되기 전에 내 감시 목록에서 링크를 몇 번 클릭해야 한다.나는 이 문제를 다른 페이지에서는 전혀 눈치채지 못했다.Refdesk 단골로 말하자면, 이것은 다소 아오잉이다!무슨 일이 일어나고 있는지 혹은 어떻게 그것을 고칠 것인지에 대한 어떤 생각이 있는가?던컨힐 15:15, 2007년 10월 22일 (UTC)

혹시나 해서 WinXP에서 사파리를 사용하고 있어.던컨힐 15:28, 2007년 10월 22일 (UTC)

나도 바로 가기를 입력해도 같은 문제가 있어(예:검색창에 WP:RDE).던컨힐 16:08, 2007년 10월 22일 (UTC)

{{PAGENAME}} 미사용: 어떻게?

주석: CB3의 제목을 수정한다.&#123;&#123; ...을 사용하여 가새 보호&#125;&#125; <노위키>보다는...</노위키>Pldx1 (대화) 13:38, 2016년 1월 27일 (UTC)
페이지의 페이지 이름을 가져올 수 있는 방법이 있는가? 그러나 작은 경우에서 시작하는가?만약 그렇다면, 방법을 말해줘.

고마워

트랜스휴머니스트 22:37, 2007년 10월 22일 (UTC)

도움말:마법의 단어.아마 {{lcfirst}{{{{PAGENAMEE}} - 보라카이 빌 02:14, 2007년 10월 23일(UTC)

보안 로그인

하단으로 향하는 로그인 페이지에서 보안에 대해 논의하고 로그인 보안을 위한 SSL 옵션을 제공한다.wikimedia.org.그러나 이 URL은 작동하지 않고 "위키는 존재하지 않는다"고 명시한다.한동안 이런 식이었다.한 달 전쯤 사용해 봤더니 다른 컴퓨터에서 똑같은 오류가 났다(과거 사용했던 것과 같은 일시적 글리치라고 생각했다).그리고 이게 고쳐지면 내 폰으로 검색하는 게 훨씬 쉬워지니까 로그인 페이지의 URL을 링크해줘.Morph 18:58, 2007년 10월 22일 (UTC)

그것은 연결고리가 아니다; 그것은 도메인이 안전해야 한다고 말한다.wikimedia.org하지만 링크는 좋을 것이다. — Edokter • Talk • 2007년 10월 22일 (UTC)

링크는 https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special:Userlogin ({User:ais523/Secure에서 템플리트 해 본 적이 있음) 입니다.URL}}은(는) 충분히 자주 출제되기 때문에 한동안은 주식 응답에 유용하다.)하지만 마지막으로 UI에서 연결되었을 때는 다시 변경되었다(MediaWiki talk:로그인 성공); 연결 속도가 그리 빠르지 않고 문제가 있음(인코딩으로 하드 코딩된 링크를 클릭하십시오).wikipedia.org보다{{fullurl}}'d.는 보안 연결을 그대로 두고 로그아웃할 것이며, 파일 업로드 링크의 대상에 문제가 있었다. --ais523 07:57, 2007년 10월 23일(UTC)

글쎄, 그것은 매우 혼란스럽고 그것을 연결고리로 바꾸는 것이 도움이 될 것이다.일반 사용자가 해당 도메인 이름을 사용자 로그인 페이지의 현재 도메인 경로에 붙여넣을 수 있는 방법을 어떻게 알고 있는가?대부분은 "secure"에 제공된 URL을 복사할 것이다.wikimedia.org"이라고 말하고 주소창에 붙여넣고 "위키는 존재하지 않는다"라고 생각해낸다.일반 사용자가 쉽게 혼동할 수 있으므로 다른 사용자에게 연결하십시오.나는 컴퓨터 괴짜인데 그걸 못 알아들었어. 그냥 실망한 거야.거기에 놓으려면 쉽게 접근할 수 있도록 해야 한다.보안 연결을 남길 정도로, 나는 사실 그것을 선호한다.스타벅스 무선 네트워크나 그런 식으로 패스워드를 보낼 때만 암호화하면 돼.내 인증을 암호화하고 en으로 다시 보내줘.wikipedia.org - 나는 그게 좋을 것 같아.Morph15^(talk):01, 2007년 10월 23일 (UTC)

그것은 말하기는 쉬워도 행하기는 어렵다.현재 보안 세션은 http 세션과 교환할 수 없다. 즉, 보안 서버에 로그인할 경우 보안 서버에만 로그인하게 된다는 것을 의미한다.게다가 보안을 전담하는 서버 자원이 매우 거의 없다.wikimedia.org, 즉 위키피디아에 하루 만에 로그인하는 모든 사용자가 보안 서버에서 그렇게 하면 다운된다는 것을 의미한다.이는 물론 로그인 텍스트에서 보안 서버에 대한 직접 링크가 제거된 주요 이유와 URL을 의도적으로 찾기가 상당히 어려운 이유다.모든 사람들은 https를 사용하는 것을 선호할 것이다; 불행하게도 지금은 그것이 가능하지 않다.그 점에 대해서는, 많은 사람들이 분명히 헷갈리기 때문에, 로그인엔드에서 보안 서버에 대한 언급을 모두 삭제하는 것이 좋을 것 같다.보안 서버를 찾을 만큼 충분히 아는 사람들은 피싱 당하지 않을 만큼 충분히 알고 있을 것이다.아미다니엘 (토크) 2007년 10월 23일 19:14 (UTC)

서버가 별도로 있는 이유인증서를 en에 추가하지 마십시오.wikipedia.org에서 443개의 인증에 대해 동일한 액세스 권한을 제공하시겠습니까?이렇게 하면 80세로 전환하면서 세션을 유지할 수 있지 않을까?비슷한 맥락에서, 왜 우리는 OpenID를 지원하지 않는가?Morph19^(talk):38, 2007년 10월 23일 (UTC)

OpenID는 단일 사용자 로그인(.k.a)의 구현에 따라 달라진다.57번 버그, 지금과 우주의 열사병 사이에 이루어질 것이다.일반 en에서 보안 로그인.wikipedia.org 서버는 위키미디아가 사용하는 가상 호스트 설정에 다소 까다로우며, 버그 225에서 설명한 것처럼 계산적으로 다소 비싸다.Titoxd^{(?!? - cool stuff)} 20:25, 2007년 10월 23일 (UTC)

버그 225의 마지막 포스터가 맞았던 것 같아.전체를 암호화할 필요도 없고 디폴트로 제공할 필요도 없다.가상 서버가 물리적 서버와 어떻게 다른지 잘 모르겠어.호스트 이름은 인증서에서 별칭 이름(en)을 사용하므로 그다지 중요하지 않아야 한다.wikipedia.org).내 말은...인터넷 상위 10위권인데 인증 암호화도 못 해?서버의 CPU 사이클을 감당할 수 없는 경우 SSL 게이트웨이 같은 것을 얻으십시오.이것은 정말로 다루어져야 한다.Morph 21:10, 2007년 10월 23일 (UTC)