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

다시 모바일 - IP 편집기에 대한 정보

(편집자가 아닌 독자로서) 정보를 찾기 위해 기사를 읽으면 대개 '역사'를 클릭해 논란, 반달리즘 등의 주제가 되었는지(그리고 위키피디아의 신뢰성에 대해 논의할 때 다른 사람들에게도 그렇게 하라고 조언한다)를 본다.모바일에 관한 기사(안드로이드, 베타)를 읽으면 '편집자의 마지막 편집 x일 전'을 보게 되고, 그 줄의 전반을 클릭하면 굵은 글씨체는 아니지만 역사를 보게 된다는 것을 알고 있다.diff를 클릭하면 diff를 볼 수 있고, 그 아래 diff를 만든 편집자의 링크를 볼 수 있다.내가 그 링크를 따라가면, 그들이 이름이 붙은 편집자라면, 나는 다소 이상한 프로필 페이지를 보게 된다(몇 년 전만 해도 그들이 올린 최신 파일을 보여주는 것이 정말 적절한가?또는 마지막으로 그들에게 감사를 표한 편집자의 신원을 확인하는 것 - 감사하는 것은 대개 기밀이다."X년 전에 y 편집 및 z 업로드와 함께 참여"라고 명시된 편집 수를 클릭하면 이들의 기여 목록을 볼 수 있다.그들의 토크 페이지도 볼 수 있고, 코멘트를 할 수 있다.

하지만 IP 에디터라면 난 전혀 이해가 안 돼.나는 "편집자에게 리디렉션"이라는 메시지를 받고 이어 "이 페이지는 존재하지 않는데, 과감하게 만들어서 만드는 게 어때?"라는 플래시를 받은 다음, IP 편집기의 사용자 페이지를 만들기 위해 편집 모드로 설정된다.좋은 생각은 아니네, 물론이지.사실 벌레인 것 같다.또는 세 개의 버그:

(a) 모바일 편집자가 IP 편집자를 위한 사용자 페이지를 작성하도록 권장하는 것은 적절하지 않다.

(b) 모바일 판독기가 IP 편집기를 위한 사용자 기여도를 볼 수 있어야 한다(OK 이는 모바일 편집자에게 더 많을 수 있음:내가 방금 내 감시목록에서 발견한 반달리즘이 관련 쓰레기의 무차별적인 일부인지 알고 싶지만 IP 주소의 경우에도 기여목록은 편집자의 심각성을 나타낼 수 있다.)현재 이렇게 하는 유일한 방법은 기사로 돌아가서 데스크탑 모드로 들어가는 것이다. (각 페이지를 수동으로 스트레칭하여 그다지 읽을 수 없는 내 스마트 폰의 글꼴 크기로 만드는 것 포함), "history"를 클릭하고 편집자를 구하고, 기여자 목록을 얻는 것이다.보통은 유일한 편집인 걸 발견했을 뿐이지

(c) 모바일 독자가 IP 편집자의 사용자 토크 페이지를 보고 편집하는 것이 가능해야 한다.방금 확인했는데 위의 결과는 빨간 IP 주소 링크를 클릭하면 해당 IP 주소에 사용자 대화 페이지가 있는지 여부에 상관없이 해당 IP 주소의 사용자 페이지 생성 제안으로 이어진다는 것이었습니다.

IP 편집기를 클릭하면 "이 IP 주소를 사용하는 편집자가 위키백과 사용자 이름을 등록하지 않은 경우"와 같은 내용의 "프로필" 페이지가 나타날 수 있다.이 IP 주소에서 편집하는 사람이 둘 이상 있을 수 있다.이 IP 주소에서 가장 최근에 편집한 내용이 여기에 표시된다.이 IP 주소에 대한 '사용자 대화 페이지'를 참조/시작하십시오.(적절한 경우) PamD 20:09, 2014년 7월 25일(UTC)

이 중 대부분은 마리아나를 위한 것이지만, 감사는 기껏해야 반 기밀에 지나지 않는다는 것을 말할 수 있다.누가 누구에게 감사하고 있는지 당신은 공공 기록에서 볼 수 있다.당신은 그 사람이 어떤 것에 대해 감사받았는지 알 수 없다.하지만, 분쟁에 관련된 사람들의 경우, 여러분은 종종 매우 쉽게 추측할 수 있다.Whatamidoing (WMF) (토크) 22:55, 2014년 7월 25일 (UTC)

그러나 사용자:Maryana_(WMF)는 Mobile에 그녀가 참여한 것을 과거로 묘사하고 있으며, 현재 Flow에 대해 연구하고 있다고 말한다.@Maryana(WMF): 아직도 Mobile에 관여하고 있는가?감사(Thanks)에 대한 코멘트는 그냥 지나가는 것이었다(Mobile 인터페이스의 이상한 점들 중 하나, 일반적으로 표시되지 않는 것이 여기에 눈에 띄게 진열되어 있지만, 아무리 오래 전에 감사(Thanking)가 일어났을지도 모른다). 나의 주된 관심사는 위에 표시된 글머리 기호들이다.PamD 10:46, 2014년 7월 28일(UTC)

그들은 제품 매니저들을 재배열했다: 대니 혼은 플로우를, 마리아나는 모바일을, 그리고 데스캐나는 모바일을 가지고 있다. (그리고 내가 그것들을 정리했으니, 그들은 아마 다시 모든 사람들을 재배열할 것이다.) ;;-) Whatamidoing (WMF) (토크) 2014년 7월 28일 (UTC) 19:00 (UTC)

• PamD, 그 행동(사용 페이지로 안내하는 IP 링크)은 정말 버그다. 보고해줘서 고마워!링크는 IP 기여로 가야 한다.마리아나 (WMF) (토크) 22:55, 2014년 7월 28일 (UTC)

복원 기능 향상

삭제된 기사를 복원할 때 이유를 입력하고 '복원' 버튼을 클릭한다.버튼이 대본을 활성화하는 것 같아그 스크립 유저가 접근 가능한가 아니면 개발팀만 이용할 수 있는가?

나의 동기는 CSD나 Prod를 복원할 때 복원된 기사를 편집하고 CSD나 Prod 템플릿을 제거해야 한다는 것이다.수동으로 해야 할 때도 있겠지만 다른 방법이 있으면 좋을 것 같다.한 버튼은 여전히 "복원"이라고, 다음 버튼은 "CSD/PROD 통지 복원 및 제거"라고 말할 수 있다.

반자동으로 복원하고 고지를 제거할 수 있는 스크립트를 만들 수 있을까 고민하던 중 복원 단계에서 이 기능을 수행해야 한다는 생각이 든다.--S Philbrick(Talk) 14:31, 2014년 7월 26일(UTC)

버튼은 HTML 요청을 트리거한다.누군가가 이러한 동작 후에 이 HTML 요청을 무시하고 API를 사용하여 동일한 작업을 수행한 다음 삭제하지 않고 성공한 후 템플릿을 제거하기 위해 편집 작업을 수행함으로써 페이지를 정리하는 자바스크립트를 만들 수 있을 것 같다.불가능한 것은 아니다.한편, 이에 대한 예외가 있을 수 있으므로 템플릿을 제거해야 하는 경우 대화 상자를 사용하여 물어야 할 수 있다.—DJ (대화 • 기여) 09:10, 2014년 7월 28일 (UTC)

그래서 내가 자바스크립트를 쓸 수 없다는 것을 감안한다면 다음에 어떻게 해야 할까.Bugzilla를 통해 기능 요청을 할 수 있는 사람을 검색해야 하는가, 아니면 이 기능을 요청해야 하는가?--S Philbrick(Talk) 17:08, 2014년 7월 28일(UTC)

이것은 미디어위키 소프트웨어 문제가 아니라 자바스크립트 문제임이 분명하므로 자바스크립트 접근법을 취해야 한다.עודדווו Od Mishehu 06:52, 2014년 7월 29일 (UTC)

디스플레이타이틀 경고

한 글에 DisplayTITLE 마법 단어를 여러 번 사용하면 페이지 하단에 다음과 같은 경고가 발생한다.경고: 예를 들어 여기서 "Bambi Kino" 표시 제목은 이전의 표시 제목 "<i>Bambi Kino</i"보다 우선한다.앨범 인포박스가 타이틀을 이탤릭체화하지 않도록 설정함으로써 해결될 수 있는 일이지만, 이 경고가 유용하기엔 너무 잘못된 긍정주의적인 경고가 아닌가 하는 생각이 든다.생각?휴온(토크) 17:29, 2014년 7월 26일 (UTC)

이것은 mw:에서 새로운 것이다.MediaWiki 1.24/wmf14#Core 변경 사항:

• #af66fecb - 디스플레이TITLE을 두 번 이상 사용할 경우 경고(T52449)

DISPLAYTITLE이 인포박스에 의해 자주 사용되고 나중에 바뀌는 영어 위키백과에서는 서툴게 작동한다.추적 범주가 없으면 발생 항목을 찾기 어렵고 인포박스 파라미터를 DISPLAYTITLE을 사용하지 않도록 설정하는 것이 어려워 보인다.Prime헌터 (토크)20:52, 2014년 7월 26일 (UTC)

새 매개 변수를 참고하십시오.{{DISPLAYTITLE:... noerror}}경고를 억제하고{{DISPLAYTITLE:... noreplace}}DisplayTITLE을 대체하지 않는다. infobox 템플릿에 오류가 추가될 수 있다, 그렇지 않은가?레이먼드 (토크) 07:21, 2014년 7월 27일 (UTC)

나는 인포박스 템플릿을 조정하는 것이 큰 도움이 될 것이라고 생각하지 않는다. 왜냐하면 그것은 오버라이드되고 있는 인포박스일 가능성이 높기 때문이다.그것은 "noerror"를 추가해야 하는 두 번째 통화다.

오류 메시지는 MediaWiki:douplicate-displaytitle을 사용하여 조정할 수 있다.가장 좋은 방법은 우리가 이미 MediaWiki:douplicate-defaultsort에서 하고 있는 것과 같이 그 메시지에 추적 카테고리를 추가하는 것이다.만약 문제가 충분히 광범위하게 퍼진다면, 메시지들은 사람들이 물건들을 정리할 기회가 있을 때까지 눈에 보이는 오류 메시지 없이 추적 카테고리를 추가할 수 있다.Anomie⚔ 23:46, 2014년 7월 27일(UTC)

그냥 과감하게 추적 카테고리를 추가하기로 했다.페이지가 편집되거나 삭제될 때 채워져야 한다.이것은 만약 더 많은 논의가 그것이 좋은 아이디어라고 결정한다면 "메시지 없는 추적 범주"를 해서는 안 된다는 말은 아니지만, 우리는 확실히 추적 범주를 원하기 때문에 우리는 그 부분에서 기다리지 않는 편이 나을 것이다.Anomie⚔ 23:52, 2014년 7월 27일(UTC)

효과가 있는 것 같아, 그렇게 해서 찾은 거야. --Redrose64 (대화) 08:11, 2014년 7월 28일 (UTC)

{{nobbr}}이(가) 생성되지 않음 &nbsp;

여보세요. {{nobr}} 템플릿은 HTML 렌더링에서 공간을 깨트리지 않도록 공간을 변환하지 않고 HTML <span> 태그를 사용하는 것을 알게 되었다.이전에는 두 가지 방법 모두 텍스트가 일치하도록 가정했지만, 지금은 서로 다른 행동을 할 것 같아 두렵다.예를 들어, 브라우저가 템플릿에서 생성된 텍스트를 ASCII 공간을 포함하는 것으로 복사할 수 있는 반면 &nbsp;를 사용하는 텍스트는 (U+00A0) 복사될 수 있다고 생각한다.나는 유니코드 위첨자 문제와 <섭>의 사용만으로 위키피디아는 하나의 스타일로 정착하여 그것의 스타일 매뉴얼로 표준화해야 한다고 생각한다.{{nobr}} 템플릿이 공간을 U+00A0으로 대체하도록 수정하는 것이 좋다.기사를 쓰고 편집할 때 어떤 것을 사용해야 할지 모르겠는데, 이 선택(현재 상황에 대한 설명)에 대한 피드백도 함께 줘(가장 구체적인 템플릿인 만큼 수량에 {{val}}을(를) 사용하는 편이다.QrTTf7fH (대화) 17:37, 2014년 7월 27일 (UTC)

The<span>...</span>요소는 속성의 범위를 정의하는 것 외에는 아무 것도 하지 않는다.그것은 이다class="nowrap"속성(에 사용됨){{nobr}}, 그것이 효과가 있다; 이 클래스는 규칙과 연관되어 있다.

.포장을 풀다, .속박하다. a, .속박하다. .셀프링크, up.참조 a {   화이트 스페이스: 포장을 풀다; } 

이것은 를 사용한다.white-space17년 전 CSS 1.0 이후 단어 포장을 완벽하게 제어하는 방법이 되어온 속성.CSS 2(3년)에 있으며, 최종적으로 W3C 권고 단계에 도달하면 CSS 3에 (사실상) 유지될 것이다. --Redros64 (토크) 18:59, 2014년 7월 27일 (UTC)

정보를 알려줘서 고맙지만, 내 질문에 답하지 않아.— QrTTF7fH(대화 • 기여) 14:13, 2014년 7월 28일(UTC)에 의해 추가된 사전 서명되지 않은 설명

깨지지 않는 공간은 현재적 공간이다. 그것들은 콘텐츠의 일부가 되어서는 안 된다.대부분의 브라우저는 복사될 때 보통 공간을 대신한다.여전히 이들과 마주친다면, 그것은 오래된 템플릿 때문이지만, CSS가 깨지지 않는 텍스트를 만드는 데 선호되는 방법이다. -- [[User:Edokter]] {{talk}}14:20, 2014년 7월 28일(UTC)

코드 이슈?

킬러(회사)라는 페이지에서 이상한 점을 발견했다.외부 링크와 참조 섹션은 서로 "믹스"된다.템플릿 코딩에 문제가 있나? --BiH (토크) 08:06, 2014년 7월 28일 (UTC)

태그가 닫히지 않은 상태로 남아 있었다.

===역사==1984년부터 킬러 가족의 회원들은 이스탄불 지역에 많은 슈퍼마켓을 열었는데, 1994년에는 킬러 슈퍼마켓 Gıda Sanayi ve Tic으로 편입되었다.A.T. 2004년까지 이 그룹은 이스탄불 지역에 33개의 매장을 가지고 터키의 다른 지역에 있는 슈퍼마켓 체인을 인수하기 위해 갔다.2010년까지 킬러는 26개 도시에 172개의 점포를 가지고 있었다.매장은 600~2500㎡ 규모지만 킬러 개념은 평균 900㎡ 규모의 슈퍼마켓을 기반으로 하고 있다.<ref name="Kiler 정보"{{cite web url=http://www.kilerkurumsal.com/content/about.aspx 제목=회사 프로파일 게시자=kilerkurumsal.com 액세스 날짜=2014-07-28}===레퍼런스=={Reference==}=외부 링크= * {{공식 웹사이트 http://www.kiler.com.tr}}}}{이스탄불 증권거래소 기업}}}}

a의 부족에 유의하십시오.</ref>{{cite 웹} 템플릿 끝에서. 23W 08:35, 2014년 7월 28일(UTC)

T17712 -- Gadget850 ^talk 15:07, 2014년 7월 28일 (UTC)

기술 뉴스: 2014-31

2014년 7월 28일 08:09(UTC)

보안 연결 실패

지난 며칠 동안, 나는 다양한 위키피디아 페이지를 보려고 할 때 파이어폭스에서 오류를 경험했다.

다른 사람이 이 문제를 겪었는가?- MrX 17:28, 2014년 7월 28일 (UTC)

https://support.mozilla.org/en-US/questions/982298 또는 https://support.mozilla.org/en-US/questions/991444 ? --AKlapper (WMF) (토크) 13:06, 2014년 7월 29일 (UTC)

감사합니다, 2014년 7월 29일(UTC) 7월 29일 (UTC)

하나의 목록에서 wiki 알림 교차

나는 하나의 리스트에 wiki 교차 알림 제안이 있다.즉, 현재 어느 wiki에서 일하든 하나의 알림 목록만 존재한다는 것을 의미한다.q:en:에서 작업하고 s:de:에서 게시물을 받으면 같은 초 안에 경보를 받고 즉시 응답할 수 있는 기회가 주어진다. --Janezdrilc (대화) 11:22, 2014년 7월 29일 (UTC)

이미 이에 대한 버그들이 있다. --글래셔 (대화) 11:35, 2014년 7월 29일 (UTC)

알림별 예기치 않은 동작

알림에 버그로 보이는 것과 같은 메시지를 억제하기 위한 해결 방법을 보고하는 중

• 페이지 없음에서 쿼리
• 메가파우나 리스트의 수마트란 문타작

이러한 원하지 않는 메시지가 일반적인 감사 또는 언급 알림이 아니므로 내 기본 설정, 통지, 감사 또는 언급 또는 사용자 권한, 저장을 제외한 모든 항목의 선택을 취소하십시오.

나는 새 메시지 표시기와 Talk 페이지 메시지 체크 표시를 유지했다.

이 변경 이후 4, 5일 전부터 등장하기 시작한 [페이지 없음]등의 질의 통지는 없었다. --Ancheta Wise (토크 기여) 14:38, 2014년 7월 25일 (UTC

이것은 알려진 버그로, 통지가 있던 페이지가 삭제될 때 발생한다.T52829를 참조하십시오.마트마 렉스토크 18:37, 2014년 7월 25일 (UTC)

내 알림 해결 방법이 감사 또는 언급 알림에 포함된 것을 보고하게 되어 기쁘다. --Ancheta Wise(대화 기여) 07:24, 2014년 7월 31일(UTC)

"여기 무슨 링크"에 문제가 있는 것 같은데...그럴까?

여러분 안녕하십니까!여기 "what links here" 기능에 문제가 있는 것처럼 보이는 것이 있거나, 아니면 내가 끔찍하게 무언가를 놓치고 있는 것 같은 것이 있다.한 마디로, 연어 해제 페이지에 대한 링크를 보려고 하면 50페이지가 넘게 되는데, 손으로 확인하면(적어도 10페이지 이상 확인했는데), 연어 페이지에 대한 링크가 없는 반면 {{리눅스 커널} 템플릿은 포함되어 있다.이 템플릿은 이전에는 kernfs에 대한 링크가 있었지만, kernfs(Linux)에 대한 링크로 대체되었다.

단서라도?내가 어디 틀렸나?— (대화 기여) 21:13, 2014년 7월 25일 (UTC)

약 1년 동안 다음과 같은 템플릿 내의 연결을 변경하는 작업 대기열에 문제가 있었다.{{Linux kernel}}여기 링크에서 자주 업데이트하지 못한 것(다른 입증 가능한 문제들도 있다).비주얼 에디터와 연결된 그 무렵의 작업 대기열 소프트웨어에 분명히 변화가 있었지만, 「문제가 없다, 그렇게 작동하도록 되어 있다」부터 「응, 문제지만, 우리는 어떻게 고쳐야 할지 정말 모른다」까지 다양한 설명이 제시되어 있다. --Redros64 (대화) 22:09, 2014년 7월 25일 (UTC)

설명해줘서 고마워!내가 보기엔 불행히도 거기서 할 일이 거의 없다.— Dsimic (talk contracties) 22:20, 2014년 7월 25일 (UTC)

가끔 며칠 놔두면 저절로 가려진다.아니면 몇 주가 걸릴지도 몰라.만약 당신이 기다림에 싫증이 나거나 혹은 한 달이나 세 달 후에 아무 일도 일어나지 않는다는 것이 명백하다면, 유일한 해결책은 WP:"여기에 링크할 내용"에 있는 모든 페이지에는 NULLEDIT가 표시되어야 한다.그것은 "여기 링크"에 있어야 할 페이지를 수정하지는 않지만, 그렇지 않다.이 페이지의 최근 게시물에서는 API 호출이 제안되었지만, 나는 그것을 작동시키는 데 성공한 적이 없다. --Redros64 (대화) 22:59, 2014년 7월 25일 (UTC)

흠, 그건 정말 미친 짓이야, 내 생각엔.어떻게 위키미디어 개발자들이 이 문제를 해결할 수 없을까, 오래되고 잘 알려진 버그라는 사실을 알고 더 놀라운 것은 무엇일까?또한 {{리눅스 커널}} 템플릿이 포함된 기사에 대해 "XYZ에서 Kernfs(리눅스)가 연결되었다"는 통보를 받고 있으며, 참조된 편집에서 Kernfs(리눅스)에 대한 링크는 결코 추가되지 않았다. 페이지 편집 시 내부 캐시에 대한 업데이트 설명과 인라인으로 보인다.— Dsimic (talk contracties) 00:25, 2014년 7월 26일 (UTC)

내가 들은 바로는 전반적으로 미디어위키의 성능을 향상시켜야 하는 HHVM 프로젝트도 작업 대기열의 작업 처리 속도를 높일 것이다.HHVM의 단계적 진입의 일부로서, 작업 대기열의 일부는 현재 HHVM에서 실행 중이지만, 불행히도 그 부분은 비율을 증가시키지 않는다.그 계획은 나머지 대기열은 이동하되 준비가 되어 있어야만 마이그레이션된다는 것이다.단, 나는 이 프로젝트에 접선적으로만 관여하고 있기 때문에 내가 들은 것만 전달하고 있다는 것을 명심하라. --Dan Garry, Wikimedia Foundation (토크) 01:00, 2014년 7월 26일 (UTC)

그럼 그건 버그가 아니라 너무 많은 데이터와 관련된 문제인 겁니까?— Dsimic (토크 콘트롤) 01:06, 2014년 7월 26일 (UTC)

@Dsimic:사실 어떻게 분류되는지 모르겠다.대기 행렬을 앞당길 엔지니어링 작업이 진행되고 있다는 사실에 대해 언급하고 있었다. --Dan Garry, Wikimedia Foundation (토크) 01:30, 2014년 7월 26일 (UTC)

좋은 생각인 것 같은데, 문제/버그/무엇이든 작업 중인 것 — Dsimic (대화 기여) 01:34, 2014년 7월 26일 (UTC)

"여기 링크된 것"은 이제 연어에게는 좋아보인다. 이 며칠 동안 몇몇 내부 캐시가 새로워진 것 같다.— Dsimic (대화 기여) 05:14, 2014년 7월 27일 (UTC)

어떤 페이지가 navbox에서만 연결되는 것이 아닌 다른 것에 링크하는지를 볼 수 있다면 더욱 좋을 것이다. --NE2 01:18, 2014년 7월 26일 (UTC)

전적으로 동의한다.— Dsimic (토크 콘트롤) 01:23, 2014년 7월 26일 (UTC)

우리는 적어도 2005년부터 그것을 요구해 왔다.이전 토론에서 읽은 내용을 보면, 우리가 가장 바랄 수 있는 것은 데이터베이스 복사본에서 작업하는 외부 도구(tools.wmflabs.org에서 실행)가 있는 것이다.실시간은 아니지만 대부분의 목적에 적합할 것이다.Whatamidoing (WMF) (토크) 22:24, 2014년 7월 27일 (UTC)

그래 - 이건 "좋겠지만 모든 것을 다시 만들지 않고는 할 수 없다"는 거야. 단지 페이지 링크가 데이터베이스에 기록되는 방식 때문이지.안타깝게도 모든 것을 재구축하는 것은 실용적인 해결책이 아니다:-) Andrew Gray (토크) 23:05, 2014년 7월 29일 (UTC)

그것은 겉으로는 단순해 보이는 것 중의 하나일 뿐 속으로는 전혀 이야기가 다르다.BTDT, 수없이 많이.:) — (대화 기여) 04:32, 2014년 7월 31일 (UTC)

"편집 내용이 저장됨"

글의 역사를 살펴본 후, 뒤로 버튼을 누르면, 예를 들어, 한 페이지도 저장하지 않은 경우에도 나는 이 메시지를 받는다.

그러나 다시 역사를 들여다보면 아무것도 구하지 못했다.

핸섬펠라 (대화) 2014년 7월 29일 12시 7분 (UTC)

항상 그런 상황인가?'뒤로 버튼'은 어디 있지?어떤 브라우저와 운영체제인가? --AKlapper (WMF) (토크) 13:07, 2014년 7월 29일 (UTC)

브라우저: IE 11, 운영 체제:윈도 7.뒤로 버튼은 왼쪽 상단 버튼이다.

이 글을 올렸을 때는 그럴 때마다 일어나는 것 같았는데 지금은 사라진 것 같다.

핸섬펠라 (대화) 2014년 7월 29일 14:50 (UTC)

핸섬펠라, 이런 단계를 순서대로 밟으면 이런 일이 생기는가?

1. 변경 후 저장
2. 기록 페이지로 바로 이동
3. 다시 돌아가기( 방금 저장한 페이지로 이동)

Whatamidoing (WMF) (토크) 15:55, 2014년 7월 29일 (UTC)

그 순서는 내가 했던 것과 비슷하게 보이지만, 노력한 결과 문제가 없어졌다.

핸섬펠라 (대화) 2014년 7월 29일 17시 59분 (UTC)

핸섬펠라 이럴 때 VisualEditor를 사용하는 거야, 위키텍스트?Steven Walling (WMF) • 토크 22:20, 2014년 7월 31일 (UTC)

난 그냥 똑바로 편집해.핸섬펠라 (대화) 06:10, 2014년 8월 1일 (UTC)

[[w:파일:예.jpg]]]

코드는 [[w:]인 것 같다.파일:예.jpg]]는 이미지를 최대 해상도로 표시한다.위키백과의 예:헬프 데스크/아카이브/2008년 6월 29일#이미 위키백과에 사용된 이미지 크기 조정 파일:YGW 커버 1.jpg 및 파일:ID eNTITYvol1cover.jpg.링크된 토론을 보면, 미디어위키는 아마도 enwiki에 인터위키 접두사를 사용할 때 파일을 표시하지 않고 링크하는 데 사용한 것으로 보인다.MediaWiki가 변경되었는가?어쨌든, 현재 많은 이미지들이 프로젝트 전체의 다양한 토크 페이지에 의도치 않게 표시되고 있을 가능성이 있다.이로 인해 토크 페이지를 읽기 어려워지고 경우에 따라 토크 페이지가 WP를 위반하게 된다.NFCC#9.

이 파일들은 어떻게 해야 하는가?WP별:NFCC#9, 적어도 비무료 파일을 어떻게 해야 한다.결장이 추가된 경우(즉, [[:w:파일:예.jpg])), 그러면 이미지가 다시 연결된다.봇이 부적절한 링크를 가진 모든 페이지를 바꿀 수 있을까?아니면 MediaWiki를 바꿔야 하는가?

이 프로젝트를 가리키는 두 개의 네임스페이스 이름("파일"과 "이미지")과 최소 두 개의 인터위키 접두사("w"와 "en")가 있다는 점에 유의하십시오.어떤 인터위키 접두사와 어떤 네임스페이스 이름을 사용하든 상관없이 동일한 행동을 하게 된다.또한 여러 인터위키 접두사를 한 줄로 묶으면 이미지가 표시된다는 점에 유의하십시오(예: [[w:w:en:en:파일:예.jpg]]]], 모든 접두사가 이 프로젝트를 가리키는 경우다른 프로젝트를 통해 라우팅된 경우 이미지가 표시되지 않음(예: m:w:파일:예.jpg).

이 문제는 다른 프로젝트에도 혼란을 줄 수 있다. --Stefan2 (대화) 13:35, 2014년 7월 29일 (UTC)

그건 정말 벌레처럼 보인다.그것은 또한 다른 프로젝트에서 이미지를 탈피할 수 있다는 것을 암시하지만, 그것은 그렇지 않다; (정확히) 링크를 생성한다는 것이다.그러나 로컬 파일 링크는 링크 대신 전용으로 해석된다.분명한 해결책은 접두사를 제거하는 것이다. 접두사는 어차피 중복되기 때문이다.그동안 나는 여기에 버그를 다시 게시했다. -- [[User:Edokter]] {{talk}}13:54, 2014년 7월 29일(UTC)

시작 시 콜론을 추가하십시오([[:w:File:Example.jpg]]→ w:파일:예.jpg) 또는 "w" 제거([[:File:Example.jpg]]→ 파일:예.jpg) - 위키피디아와 같은 문제:마을 펌프(기술)/아카이브 128#w:(lang) 링크. --Redros64 (토크) 14:32, 2014년 7월 29일 (UTC)

그 문제는 퇴보하는 것이다. 이런 식으로 행동할 때는 아니었다. -- [[User:Edokter]] {{talk}}2014년 7월 29일 16:00(UTC)

스테판2:이건 내 잘못이야.그것은 메타, 커먼스(새로운 "c:" 접두사만 해당)와 몇 개의 다른 작은 위키뿐만 아니라 영어권 위키에만 영향을 미칠 것이다.최대한 빨리 수리할 수 있도록 노력하겠다. — 이것, 저것, 그리고 다른 (대화) 10:42, 2014년 7월 30일 (UTC

카테고리 이동

언제부터 카테고리를 다른 제목으로 옮길 수 있게 되었는가?나는 이것이 기술적으로 최근까지 가능하지 않았던 것으로 기억한다.이 기능이 활성화된 정확한 날짜는? --Theurgist (talk) 12:14, 2014년 7월 30일(UTC)

5월 22일? 위키백과:관리자 알림판/아카이브262#카테고리 페이지는 곧 이동 가능. --Edgars2007 (대화/연락처) 12:22, 2014년 7월 30일 (UTC)

범주에 속하는 기사는 새 이름에 나타나지 않으며, 수동으로 이동(또는 봇과 함께 이동)할 때까지 이전 이름(리디렉션이 아닌)으로 표시된다는 점에 유의하십시오.이것은 정말로 매우 제한된 기능이다.마트마 렉스토크 14:02, 2014년 7월 30일 (UTC)

위키백과 대화를 참조하십시오.페이지 이동#카테고리 이동.현재로서는, WP:CFR 및 WP:Cydebot(토크 · 기여)이 고양이의 이름을 바꾸기 위해 여전히 오래된 컷앤페이스트 방법을 사용하고 있지만, CFDS 프로세스는 여전히 사용되어야 한다. --Redros64 (토크) 14:13, 2014년 7월 30일 (UTC)

Gadget-charinsert와 Extension charinsert의 차이점

나는 왜 WP가 charinsert라는 기기와 charinsert라는 확장자를 사용하는지 약간 혼란스럽다.다른 모든 WMF 프로젝트에는 charinsert 가젯이 포함되어 있지 않다.미디어위키:Edittools는 JS를 사용할 수 없고 MediaWiki:Edittools.js는 JS가 활성화되면 호출된다.이 스크립트는 MediaWiki:가젯-charinsert-core.js 그러나 그것은 이미 숨겨진 가젯에 의해 로드되었다.그래서 두 가지 질문이 있다.charinsert 가젯은 WP에 무엇을 하는가(확장판과 어떻게 다른가) 그리고 왜 Gaditdools.js와 숨겨진 가젯에 의해 로드되어야 했는가?고마워, -24^Talk 17:39, 2014년 7월 30일 (UTC)

에독터, 당신을 위한 하나. --Redrose64 (대화) 19:14, 2014년 7월 30일 (UTC)

홀더에게 패스.위키, 그는 이런 구조를 생각해냈다. -- [[User:Edokter]] {{talk}}2014년 7월 30일 20:30(UTC)

한번 본 결과 미디어위키는 다음과 같이 기억한다.Edittools.js는 이 파일을 가져오는 다른 프로젝트(기본 가젯으로 이동하기 전에 있었던 코드)를 쉽게 하기 위해 있을 뿐 자동으로 로드되지는 않는다.이제 이 가젯은 Charinsert-core가 로드되는지 여부를 제어하지만 적절한 사용자 기본 설정이 설정된 경우에만 제어한다. -- [[User:Edokter]] {{talk}}20:36, 2014년 7월 30일 (UTC)

네! "미디어위키:Edittools.js는 "redirection"으로 일하고 있다.영어 위키백과는 사용하지 않는다.

나는 미디어위키 토크에서 다음과 같이 제안했다.Editools/Archive 9#MediaWiki:Edittools.js를 추가해야 한다.mw.log이전 제목에서 코드를 가져오는 사용자가 콘솔에서 통지를 수신하도록 호출하십시오.하지만 우리는 결코 그렇게 하지 않은 것 같다.나는 경고를 덧붙였다.

가젯 구현에 대한 자세한 내용은 미디어위키 대화:Edittools/Archive 9# 독자들에게 왜 이것이 로드되는가?홀더 21:57, 2014년 7월 30일(UTC)

살인적인 서버 지연

무엇이 이 지체를 야기하는지 아는 사람 있어?그 변화는 약 10분 후에야 알 수 있다.더스틴 (토크) 04:28, 2014년 8월 1일 (UTC)

라그는 이제 정상으로 돌아왔다.높은 지연은 버그 때문에 워치리스트/기여 DB 서버(db1055)가 따라갈 수 없을 정도로 너무 빨리 실행되어 새로 추가된 일부 데이터베이스 필드(T62618)를 채우는 데 사용되는 스크립트에 의해 야기되었다.그 스크립트는 수정될 때까지 엔위키에서 중지되었다.(#wikimedia-operations IRC 로그 참조) JustStand (대화) 06:45, 2014년 8월 1일(UTC)

모바일 사용자는?

나는 등록된 사용자가 아니다.나는 위키피디아에 접속하기 위해 모바일(안드로이드)을 자주 사용하지만 난 문제에 직면해 있다.나는 모바일 버전 위키피디아에서 페이지를 편집할 수 없어.심지어 이 편집도 모바일에서 데스크톱 버전으로 전환하여 만들었다.나에겐 심각한 문제인데, 왜 모바일 버전에서 페이지를 편집할 수 없는 거지?개인 정보 보호 때문에 계정을 등록할 수 없어.나는 등록되지 않고 모바일로 페이지를 편집하고 싶다.가능할까?위키피디아의 슬로건이 말하듯이"누구나 편집할 수 있음" - 왜 내가 편집할 수 없는가?몇몇 나라들은 데스크탑, 노트북 등을 널리 이용할 수 없었다; 그들은 전화기를 사용한다.나 같은 사람과 한 페이지를 편집하는 것 사이에서 장벽 역할을 하고 있다고 생각한다.누군가 나를 도와줄 수 있으면 좋겠다. :) 101.221.128.88 (대화) 13:55, 2014년 7월 25일 (UTC)

당신은 계정을 통한 개인 정보 편집이 없는 것보다 더 잘 될 것이다.존보드 (대화) 13:57, 2014년 7월 25일 (UTC)

사생활에 대한 질문은 아직 안 했나 봐.모바일 버전을 통해 편집할 수 없는 이유를 알고 싶다. 101.221.128.88 (토크) 14:01, 2014년 7월 25일 (UTC)

특정 오류가 발생하는가, 아니면 편집 기능을 사용할 수 없는가?어떤 모바일 플랫폼을 사용하십니까?— xaosflux 15:02, 2014년 7월 25일(UTC)

등록되지 않은 사용자로 모바일을 통해 편집할 수 없다.버그 53076은 일부 작업이 진행 중임을 암시한다. --AKlapper (WMF) (토크) 15:26, 2014년 7월 25일 (UTC)

사용자:Maryana(WMF)는 모바일 편집의 제품 매니저로 현재 상황을 알려줄 수 있지만, 결국 로그아웃 편집이 허용되는 것이 전반적인 계획이라고 본다.Whatamidoing (WMF)(대화) 19:09, 2014년 7월 25일 (UTC)

명확히 하자면, Maryana는 모바일 웹의 제품 매니저인 반면, 나는 모바일 앱의 제품 매니저인 것이다.그리고, 또, 명확히 하기 위해서, 모바일 앱에서 익명으로 편집이 가능하다. :-) --Dan Garry, Wikimedia Foundation (토크) 01:09, 2014년 7월 26일 (UTC)

Whatamidoing (WMF), AKlapper (WMF) & Xaosflux의 답변에 감사한다.빨리 이 기능을 봤으면 좋겠다.나는 또 다른 문제를 발견했다.나는 나의 안드로이드 전화기를 뒤적거릴 때 이 특별한 페이지의 "go" 버튼과 드롭다운 메뉴를 볼 수 없다.둘 다, 핸드폰으로 보니 go버튼과 저 두개의 drop down메뉴가 사라졌다.누가 고칠 수 있어?고마워 -- 101.221.130.34 (대화) 19:30, 2014년 7월 25일 (UTC)

• 특정 브라우저(오페라 미니 등)를 사용하는 경우에는 모바일 버전을 사용하여 편집할 수 없다.이것이 고쳐졌으면 좋겠다. --Stefan2 (대화) 13:30, 2014년 7월 29일 (UTC)

아니, 안 그럴 거야.wp:open 프록시를 참조하십시오. --117.201.38.153 (대화) 03:30, 2014년 7월 31일(UTC)

오페라 Mini는 WP에서 차단되지 않음:프록시를 열고(X-Forwarded-For 헤더를 사용하기 때문에), 움직이지 않는 위키백과판을 사용하여 편집이 가능하다.문제는 다른 것이다. --Stefan2 (대화) 12:18, 2014년 8월 2일 (UTC)

참조 목록 변경 요청

최근의 소프트웨어 변경은 {{reflist}} 태그가 없어도 토크 페이지 하단에 참조 목록을 추가했다.목록 앞에 작은 가로줄이 나타날 수 있는가?한 페이지의 마지막 게시물이 목록으로 흘러들어가면 산만해질 수 있다. --NeilN 14:13, 2014년 7월 29일(UTC)

이는 #자동으로 생성된 참조 목록-추적 및 아카이브의 최근 스레드(Talk) 14:35, 2014년 7월 29일(UTC)

나는, 아마도 순진하게 질문할 것이다. 당신이 토크 페이지에 참고문헌을 추가하기를 원하며, 당신은 이 단원의 하단과 반대로 페이지 하단에 참고문헌을 추가하길 원하는 경우가 있는가?참고문헌은 항상 특정 섹션에 적용하기 위한 것으로, 해당 섹션의 하단에 나타난다면 더 좋을 것이라고 생각하고 있다.알고리즘을 다음과 같이 수정하는 것이 비교적 간단하지 않을까?

페이지에 참조 목록 표시가 없는 참조 태그가 포함되어 있고 페이지가 토크 페이지인 경우 참조 태그를 포함하는 섹션에 {{Reflist-talk}}을(를) 추가하십시오.

왜 맨 아래에 있어야 하는지 꿈을 꿀 수 있는 드문 경우라면, 그 다음에 원하는 편집자는 {{reflist}}을(를) 직접 추가할 수 있다.--S Philbrick(Talk) 12:56, 2014년 7월 30일 (UTC)

도움말 참조:ARGL. -- Gadget850 ^talk 19:44, 2014년 7월 30일 (UTC)

... 또는 도움말:AGRL -- John of Reading (대화) 19:58, 2014년 7월 30일 (UTC)

<도!> -- Gadget850 ^talk 20:00, 2014년 7월 30일 (UTC)

그럼 거절인가? :-) --닐N^{talk to me} 17:34, 2014년 7월 31일 (UTC)

맨살을 쓴다.<references />원소가 아니라 원소{{reflist}}템플리트(페이지의 HTML을 검사한 결과 다음 항목으로 포장되지 않았음을 나타내기 때문에 알 수 있음<div class="reflist" style="list-style-type: decimal;">...</div>)) 그리고 그것은 Cite.php 확장이기 때문에 그것은 MediaWiki 소프트웨어의 일부분이고 우리가 통제할 수 없는 것이 대부분이다. --Redros64 (토크) 20:28, 2014년 7월 31일 (UTC)

만약 사람들이 이것을 원한다면, 나(또는 다른 누군가)는 버질라에게 그것을 요청 할 수 있다.그것은 아마도 모든 위키(Wikipedia, 영어 위키백과뿐만 아니라)에 영향을 미칠 것이기 때문에, 그것을 요청하기 전에 신중히 숙고하는 것이 현명할 것이다.Whatamidoing (WMF) (토크) 22:22, 2014년 7월 31일 (UTC)

먹을 만할 것 같아.나는 그것이 사소한 거래가 아니므로 무엇이 잘못될 수 있는지 생각해 볼 가치가 있다는 것을 인정한다.나의 가장 큰 단점은 (상상이 어려운) 토크 페이지 하단의 ref를 정말로 원했다면, 항상 그렇게 하도록 강요할 수 있기 때문에, 문제를 상상하기 위해서는 누군가가 ref가 하단에 나타나기를 원하지만, ww를 하지 않는 상황을 꿈꿀 필요가 있다.하단의 적절한 참조 섹션을 삭제하십시오.왜 그럴까 하는 생각이 들지는 않지만 어쩌면 다른 누군가가 그런 상황을 상상할 수도 있을 것이다.

그것을 실행하는 것을 지지하는 또 다른 주장; 사람들은 실행 직후에 많은 예들이 있었다고 주장할 수 있는데, 이는 추가된 모든 토론 페이지의 모든 ref가 아래에 나타나기 시작했기 때문이다. 그리고 대부분은 이제 정리될 것이다. 그것은 옳지만 문제는 해결되지 않았다.우리가 새로운 편집자를 계속 추가함에 따라, 누군가, 어딘가에서 토크 페이지를 사용하여 편집을 논의할 것이고, 참조를 포함한 기사의 일부를 토크 페이지에 복사할 수 있으며, 처음에는 해당 참조가 속한 것으로 보이는 추가 섹션의 하단에 위치하게 될 것이다.그러나 그때 누군가가 새로운 구간을 추가하게 되고, ref가 떠내려와 혼란을 야기할 것이다.아니면 직접적으로 일어날 수도 있다.누군가가 페이지의 줄에 코멘트를 덧붙이며, 참조자가 아래쪽에 앉아 있는 것을 알아차리지 못한다.하단의 토론에 참여한 사람들은 왜 ref가 거기 있는지 깨닫지 못할 수도 있다.관련 참조 템플릿이 없는 대화 페이지에 참조가 표시되는 규칙이 참조가 포함된 섹션에 표시되면 해당 참조가 표시되도록 거의 확실히 표시되며, 드물지만 다른 곳에 속하는 경우에는 쉽게 수정할 수 있다.--S Philbrick(Talk) 12:02, 2014년 8월 1일(UTC)

1.24wmf12를 배치하기 전에 참조 목록이 누락되었다는 오류 메시지가 있었다.네임스페이스 탐지를 사용하여 사용자 및 대화 페이지에 오류를 표시하지 않았다.우리는 누락된 참조 리스트를 꽤 빨리 정리할 수 있었다.나는 AGRL이 시행된 방식이 유용한 방법보다 더 고통스럽다고 생각하기 시작했다. -- Gadget850 ^talk 12:21, 2014년 8월 1일 (UTC)

나도 동의해.배포 전에 편집자가 오류(필요한 코드 없이 ref)를 수행함에 따라 보기 흉한 빨간색 오류 메시지가 생성되었다.배포 후 보기 흉한 빨간색 오류 메시지는 사라졌는데, 이는 긍정적인 것처럼 들리지만, 도입 비용으로는 편집자가 거의 원하는 것이 아닌 "수정"을 도입하는 것이 거의 확실하다.더 안 좋은 것은 이제 문제를 암시하는 오류 메시지가 없어서 페이지가 잘못 만들어졌고, 그 이유가 분명하지 않다는 것이다.

난 버질라 신고한 적 없어, 총알을 물 때가 된 것 같아.--S 필브릭(토크) 14:31, 2014년 8월 1일 (UTC)

어떻게 처리하시겠습니까====부속=====?그것이 RFC나 기사의 많은 부분에 대한 주요 재서기를 제안하는 것이라고 상상해보라.각 하위 섹션에 대해 별도의 참조를 원하십니까? 아니면 모두 함께 참조하시겠습니까?

(Bugzilla 요청은 어렵지 않지만, 당신의 이메일 주소를 전 세계에 게시해야 한다.)Whatamidoing (WMF) (토크) 02:41, 2014년 8월 3일 (UTC)

도구 모음의 추가 단추

도구 모음에서 단추를 추가하는 방법한 자바스크립트 페이지에서 몇 가지를 복사했는데, 이게 안 되네

jQuery.getscript('//meta.wikimedia.org/w/index.php?title=User:Krinkle/Scripts/InsertWikiEditorButton.js&action=raw&ctype=text/javascript', 기능을 하다 () {           // 참조 목록         krInsertWikiEditor 버튼({                 "id": "mw-customedit 버튼-mypecial 버튼",                 "아이콘": "http://upload.wikimedia.org/wikipedia/commons/2/2b/Button_ref_inscription.png",                 "label": "참고 목록",                 "이전에 삽입": "==참조=\n{reflist}\n\n",         });   }); 

난 오래된 도구모음을 사용하고 있어, 그게 문제가 된다면.그런데 어떻게 하면 오래된 코드 에디터를 활성화할 수 있을까?비슷한 것$wgCodeEditorEnableCore = true; (이 라인은 작동하지 않음) --Edgars2007(대화/출연) 11:43, 2014년 7월 30일(UTC)

그 스크립트는 그 자체로 매우 오래된 것이며, 위키에디터를 위한 것이지, 오래된 도구모음을 위한 것이 아니다.

버튼 추가에 대한 설명서는 다음과 같다.MediaWiki의 예는 다음과 같다.Common.js/edit.js

CodeEditor는 Enhanced toolbar/WikiEditor 옵션이 활성화된 경우에만 작동하며, 이는 CodeEditor에 크게 의존하기 때문이다.디커플링 작업을 하고 있지만 몇 주 동안 시간이 없어서 작업할 수가 없었어. 버질라:45850은 이 정도야.바라건대 위키마니아 이후 나는 그것을 고쳐야 하지만 100% 확신하지는 않는다.—DJ (대화 • 기여) 11:56, 2014년 7월 30일 (UTC)

좋아, 내가 너무 많이/ 적게 베꼈나 봐.그리고 샘플은열려 있는 태그와 닫힌 태그 사이에 아무 것도 없으면 텍스트를 제거하시겠습니까?

기능을 하다 AddExtraButtons () {  mw.도구 모음.애드버튼스(  {   'imageId': '버튼-스위치',   '이미지 파일': '//upload.wikimedia.org/wikipedia/commons/2/2b/Button_ref_inscription.png',   '스피드팁': '참조',   '태그 열기': '===참조=\n',   '태그 클로즈': '{{reflist}}\n\n',   '샘플텍스트': '아무것도 아니다'  } ); } 

--Edgars2007 (대화/출연) 12:10, 2014년 7월 30일 (UTC)

@Edgars2007: 누락된 로더 코드를 추가하여 당신의 JS를 변경했다.나는 또한 샘플을 제거했다.같은 편집의 텍스트로,작동해야 한다 대로지금 원하는.확인해 주시겠습니까?홀더 22:09, 2014년 7월 30일(UTC)

@helder.위키:응, 효과가 있어.크나큰 감사! :) --에드가르2007 (대화/출연) 08:50, 2014년 8월 1일 (UTC)

"단어 포장" 매우 긴 단어

지정된 최대 길이를 초과하지 않는 긴 단어를 조각으로 나누는 템플릿(또는 다른 자동화된 방법)이 있는가?이상적으로는 하이픈이나 빈칸을 일정한 간격으로 끼워 넣음으로써 단어를 깨트릴 수 있을 것이다.나는 가끔 인포박스를 비정상적으로 넓게 만들지 않고 인포박스에 긴 단어를 표시해야 하기 때문에 물어보는 거야.어떤 아이디어나 조언이라도 감사할 것이다.람트론 (대화) 15:53, 2014년 7월 31일 (UTC)

{{shy}}}}}. /~휴사틀럼/16:16, 2014년 7월 31일 (UTC)

불행히도 그렇게 하려면 부드러운 하이픈을 수동으로 삽입해야 하는데, 그것은 내가 하드 하이픈을 삽입하는 것만큼 쉽게 할 수 있었다.나에게 정말 필요한 것은 이것과 비슷한 방식으로 하이픈을 삽입하는 자동 방법이다: {{하이페네이트 20 애버리베리롱워드}}}.람트론 (토크) 16:25, 2014년 7월 31일 (UTC)

음. 내 생각엔...<wbr />구성요소는 그 때 유용하지 않다(Wipedia: 참조):마을 펌프(기술)/아카이브 117#nowrap 대 please-wrap-here 옵션?). --Redros64 (대화) 16:35, 2014년 7월 31일 (UTC)

또 다른 가능한 해결책은 어떤 식으로든 자동적인 Infobox 확장을 금지하여 Infobox 자체가 단어를 포장하도록 하는 것이다.그렇게 할 수 있는 방법이 있을까?람트론 (토크) 16:45, 2014년 7월 31일 (UTC)

어떤 infobox 또는, 어떤 페이지에 문제가 표시되었는가? --Redrose64 (대화) 17:16, 2014년 7월 31일 (UTC)

그것은 당면한 문제가 아니라 이따금씩 올라오는 문제다.다음번에 해결책이 나올 때 찾고 싶다.문제가 명확하지 않은 경우, 긴 단어 또는 URL이 infobox에 나타날 때 발생할 수 있는 상황을 보여주는 간단한 예:

BTW, 동일한 문제가 사용자 상자와 다른 시각적 용기에 나타날 수 있다.URL의 경우 이상적인 해결책은 컨테이너 힘 시각적 래핑을 통해 URL 복사-붙여넣기에 가짜 하이픈이 포함되지 않도록 하는 것이다.람트론 (대화) 17:38, 2014년 7월 31일 (UTC)

나는 해결책을 찾았을지도 모른다: 단어-wrap:break-word로 분리된 스타일로 단어를 캡슐화한다.더 많은 탐사가 필요하지만, 여기 예를 들어보자.

http://www.example.com/Averyveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongurl.htm

람트론 (대화) 2014년 7월 31일 18:18, (UTC)

많은 infobox가 URL을 포장에 포함{{URL}}다른 사람들은 당신이 직접 그 템플릿을 제공하기를 기대한다.어느 쪽이든 이 문제를 거론할 장소는 지금에 와 있다고 생각한다.{{URL}}템플릿.이제 모듈에서 Lua-ised:URL. 그러나 템플릿 토크에서 토론이 계속 진행됨:URL. --Redros64 (대화) 18:38, 2014년 7월 31일 (UTC)

참고: {{}}URL}은 포맷이 아니라 메타데이터의 방출인 특정 목적을 가지고 있다.(왜 루아, BTW에 있어야 하는가?)Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 20:23, 2014년 8월 1일(UTC)

만료된 Toolserver 사용자 wiki_researcher에 대한 수정 사항이 있는가?

다음 사항을 사용자에게 게시했다.Smith609의 토크 페이지: "Edit history statists, 또는 오른쪽 여백의 Statistics 도구 상자 아래의 페이지 watchers를 클릭하면 다음 -403:사용자 계정이 만료됨 요청한 페이지는 계정이 만료된 Toolserver 사용자 wiki_resecher가 호스팅한다. 툴서버 사용자 계정은 사용자가 6개월 이상 비활성일 경우 자동으로 만료된다. 오래된 페이지에 액세스할 수 없도록 만료된 콘텐츠에 대한 요청을 자동으로 차단한다.참조: [13]??" 마틴이 대답했다..."글쎄, 툴 서버 자체는 지금 만료되었어.업데이트된 링크나 찾는 방법에 대한 제안이 있으십니까?"해결책이 있는지 아는 사람 있어?Atsme☯^Consult 18:32, 2014년 7월 31일 (UTC)

툴서버에 있는 모든 것들은, 당신이 찾고 있는 아이템이 활성인지 아니면 유지되는지 확신할 수 없는, 현재 랩에 있다.(oh 사이드바의 일부 링크가 끊어짐) "기록 통계 편집" 및 "페이지 감시자"는 위의 "도구 상자" 섹션에 있는 "페이지 정보" 링크를 통해 검색할 수 있다.건배, Mlpearc (오픈 채널) 18:49, 2014년 7월 31일 (UTC)

그것은 정말, 아주 긴 총에 의해 사실이 아니다.그리고 대부분의 히트 도구에 대해서는 "재단이 왜 그것들을 생산으로 옮기는 것을 거부하는가"라는 의문을 제기한다.어쨌든 게시할 장소는 mw:Tool Labs/Toolserver 종료 후 문제 수집, WM-DE가 한 달 만에 최대 8TB의 Toolserver 데이터를 완전히 삭제하므로 빠른 조치를 취하십시오.— 디스펜서 19:32, 2014년 7월 31일(UTC)

게다가, 실험실은 독점적인 것 같다. 도구를 소싱하는 "열림"에 따르지 않는 사람은 누구나 문을 닫는다.그것은 슬픈 일이다.최상의 선택:Rich Farmbrough, 22:36, 2014년 7월 31일 (UTC)

그것은 사용자들을 화나게 했던 버려진 프로젝트들에 대한 수년간의 경험에서 벗어난 것이다.그래서 사람들은 툴랩에서 비슷한 문제를 예방하고 싶다고 결정한 것이다.그리고 물론 그것은 편집자들에게 그들의 기여를 공유하도록 요구하는 것만큼이나 배타적이다. 우리가 생각하기에 우리의 움직임에서는 완전히 정상적이다.이것은 단지 tollabs btw를 위한 것이다.실험실 자체는 그러한 제한이 없으며 예외를 위해 사례별로 허가 및 사용이 가능하다.내가 의심하는 연구 목적의 토올랩에는 예외가 있을 수 있지만, 디폴트(디폴트)는 우리의 모든 지식 공유에서 우리가 하는 것과 실제로 일치한다.—DJ (대화 • 기여) 10:53, 2014년 8월 1일 (UTC)

IIRC 위키다시보드는 GPL'd였으므로 오픈 소싱 문제는 없다.툴서버를 구하지 못한 이유는 항상 제때에 짜내는 재단 직원들에게는 너무 많은 일이었기 때문이다.WM-DE는 Toolserver를 흰 코끼리로 보았고 빨리 그것을 이용하기를 원한다.

그건 단지 조직 정치일 뿐이야. 우리가 도구를 해체해야 하는 이유, 웹 서버 엿먹기, 네임스페이스 테이블 구현 거부, 데이터베이스 이름이 일치하지 않는 이유, 2등급 보안 관행, 인기 있는 유닉스 명령, 크론 금지, 또는 빌어먹을 멋진 개인 정보 보호 정책 같은 건 설명 안 돼..

하지만 그건 오픈소스니까 재단의 "성공적인 이주"에 대한 구글 독스 프레젠테이션에 넣어볼 수 있을 겁니다.— 디스펜서 13:45, 2014년 8월 1일(UTC)

코드 요소의 스타일링

언제 그리고 왜 우리가 스타일링을 시작했는가?<code>...</code>테두리가 있는 요소? --Redros64 (대화) 18:41, 2014년 7월 31일 (UTC)

그것은 게리트:148397로, 똑같이 보이게 하려는 의도를 가지고 있을 것이다.<pre>blocks. --Patrick87 (대화) 19:22, 2014년 7월 31일 (UTC)

거스름돈이 마음에 들지 않았는데, 코드가 너무 강조된 것 같아, 굵은 글씨처럼.나는 조금 더 좋아한다.like this, python 문서에 사용됨.Danilo.mac (대화) 01:15, 2014년 8월 1일 (UTC)

테두리의 경계선<code>...</code>바람직하지 않은 요소: MediaWiki talk:Common.css#더블 테두리 및 템플릿 대화:프리#더블 테두리. --Redros64 (대화) 09:19, 2014년 8월 1일 (UTC)

에덕터가 템플릿을 고친 것 같아, 고마워!마트마 렉스토크 11:27, 2014년 8월 1일 (UTC)

어떤 템플릿이 될 것인가? --Redrose64 (대화) 11:35, 2014년 8월 1일 (UTC)

당신이 연결한 {{pre}}?마트마 렉스토크 13:22, 2014년 8월 1일(UTC)

나도 그 변화가 마음에 들지 않았다. 나는 <코드> 형식은 그대로 괜찮다고 생각했다.이제 많은 인라인 코드 조각들은 그들 주위의 경계를 산만하게 한다.람트론 (토크) 15:12, 2014년 8월 1일 (UTC)

• code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text아직도 안 좋아 보여...좌우 경계가 없는 곳이라면 그래도 괜찮겠지만(그렇지 않을 다른 사람들도 있을 것 같은데)

code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text 

중첩은 더 나아 보이지 않는데, 이것은 일어나서는 안 된다. 그러나, 그것에 대해 여러 다른 토론이 있다는 사실에 근거하면, 그것은 분명히 그렇다.— {{U 기술 13}} 15:21, 2014년 8월 1일(UTC)

HTML은 전자가 블록 요소이고 후자는 인라인 요소인 만큼 <code> 안에 <pre>를 중첩하는 것을 허용하지 않는다.파싱된 페이지의 HTML 소스를 보면, HTML Flearch가 <pre> 안에 <code>를 둥지 틀면서 그것들을 "interweaved"한 것을 볼 수 있는데, 그것은 분명히 멍청해 보인다.그나저나 왜 그러려고 하는 거야?마트마 렉스톡스 18:07, 2014년 8월 1일 (UTC)

현재 Intel HEX 전체에서 볼 수 있는 성가신 유사 중첩 테두리의 예::0300300002337A1E. 람트론 (대화) 15:37, 2014년 8월 1일 (UTC)

저 기사는 왜 <코드> 태그를 사용하는가?이건 컴퓨터 코드가 아닌 것 같아.아마도 태그는 제거되어야 하고, 템플릿은 모노스페이스 폰트를 사용하도록 변경되어야 하는가?마트마 렉스토크 18:07, 2014년 8월 1일 (UTC)

그것은 실제로 "컴퓨터 코드"이다. (아마 당신은 그것이 높은 수준의 언어 소스 코드가 아니라는 것을 의미했을 것이다.)이와 같은 컴퓨터 코드는 많은 기사에서 인라인 스니펫과 더 큰 블록으로 나타난다.이곳이 올바른 질문 장소가 아닐 수도 있다는 것을 알지만, <코드>가 이와 같은 코드를 포맷하는 올바른 방법이 아니라면, 적절한 방법은 무엇일까?람트론 (토크) 18:46, 2014년 8월 1일 (UTC)

데이터 샘플이니 어떠세요?<samp>...</samp>? --Redros64 (대화) 18:59, 2014년 8월 1일 (UTC)

알려줘서 고마워, 레드로스 내가 알아볼게BTW, 이 형식 변경으로 인해 엉망이 된 것은 이것뿐만이 아니다.예를 들어, MOS:CODE. Lambtron (대화) 19:07, 2014년 8월 1일(UTC)의 예를 살펴보십시오.

한 가지각색의<samp>...</samp>이런 스타일을 선호하는 방법이라면 MOS에서 언급되어야 한다.아마도 이미 그곳에 있는 것 같지만 나는 그것을 보지 못했다.람트론(토크) 19:15, 2014년 8월 1일 (UTC)

@Lambtron:나는 MOS 페이지가 잘못되었거나(또는 적어도 오해의 소지가 있는); <</pre></code>(또는 <code>)(또는 <code>(space-indent code block))>가 위에서 설명한 것처럼 결코 정확하지 않으며, 사용되어서는 안 된다고 업데이트했다.<</사전>이나 공간 표시(이것은 동일한 HTML을 생산한다)로 완전히 만족한다.마트마 렉스토크 19:35, 2014년 8월 1일 (UTC)

사전 태그로 둘러싸면 다음과 같은 정보를 얻을 수 있다.

{{Intel HEX 03 0030 00 02337A 1E}}}

- 필요한 것은 아니다.그러나 Redrose의 제안된 샘프 태그로 나는 이것을 얻었다.어떤 것이 올바른가요?람트론 (토크) 19:50, 2014년 8월 1일 (UTC)

• 테두리 없이 스타일링 텍스트에 여전히 사용할 수 있는 사항. - Evad37[talk] 03:38, 2014년 8월 2일(UTC)

  사용하다<kbd>...</kbd>대신에, 로서<tt>...</tt>더 이상 사용되지 않는다. -- [[User:Edokter]] {{talk}}09:19, 2014년 8월 2일 (UTC)

  그래...더 이상 추가하지 말아줘.<tt>...</tt>s. 홀더 11:12, 2014년 8월 2일 (UTC)

  • 진짜.<tt>...</tt>일부 브라우저에서는 렌더링하지 않고 빈 섹션만 남긴다.미디어: 참조이 토론에서 나쁜 요소.png가 나온 후 이 제안을 예로 들어보자.— {{U 기술 13}} 15:47, 2014년 8월 2일(UTC)

나는 줄곧 사용해 왔다.<code>...</code>왜냐하면 그것은 MOS에 따르면 정확해 보였고 그것은 그것과 MOS에 대한 최근의 변화까지 완벽하게 작동했지만, 지금 그것은 깨졌다.사용 팁을 받았다.<pre>...</pre>, 그것은 작동하지 않는다;<samp>...</samp>다른 누구도 지지하지 않는 것처럼 보이는 것;<tt>...</tt>, 더 이상 사용되지 않는 , 그리고 지금.<kbd>...</kbd>문제가 있는 교체를 시작하기 전에<code>...</code>다른 것으로 태그를 달면, 나는 그 교체가 (1) 기능적, (2) 이러한 목적을 위해 허가된 것이며, (3) 앞으로도 이와 같이 바뀌지 않을 것임을 알아야 한다.<code>...</code>그랬어. 그래서 내 일이 무의미해졌어.어느 것이 맞으며, MOS에서 언급되어야 하지 않을까? Lambtron (대화) 15:52, 2014년 8월 2일 (UTC)

그것은 무엇이 태그로 표시되느냐에 따라 달라진다.사전, 코드, kbd, samp 및 var의 각 사양을 참조하십시오.또한 de:에 짧은 전환 테이블이 있다.위키백과:위키프로젝트 HTML5는 영어 위키백과에서도 유용할 것 같다.홀더 16:11, 2014년 8월 2일(UTC)

이것은 MOS에서 명시적으로 다뤄질 필요가 있다.w3.org 의 사양.<code>...</code>"컴퓨터 코드 조각이...또는 컴퓨터가 인식할 수 있는 기타 문자열".그것은 확실히 Intel HEX와 많은 다른 종류의 비-하이/로우 레벨 컴퓨터 코드에 적용할 수 있을 것 같다.편집자들이 이것을 위해 MOS 밖에서 검색해야 한다는 것은 불합리하다.또한, 내가 대체품으로 택한 태그는 앞으로 그 스타일이 바뀌지 않을 것이라는 것을 어떻게 알 수 있을까?람트론 (토크) 16:41, 2014년 8월 2일 (UTC)

넌 몰라.그러나 가장 중요한 것은 그것의 의미론이다.스타일은 항상 CSS를 통해 위키당, 피부당 또는 사용자별로 오버리디될 수 있다.홀더 16:47, 2014년 8월 2일(UTC)

• 홀더, 저 표를 영어로 여기 enwp에 있는 페이지로 번역해줄 수 있니?그렇다면 정말 좋겠다.내가 가장 잘 알 수 있는 것처럼(나는 단어를 읽을 수는 없지만 대부분의 단어에서 농담을 얻는다), 그것은 생방송을 위해 몇 번의 트윗만 있으면 된다.그것은 내가 제안서에서 말한 것과 같은 종류의 페이지로서, 편집자들이 더 이상 사용되지 않는 요소 대신에 무엇을 사용해야 하는지를 알 수 있도록 돕기 위한 것이다.고마워요.— {{U 기술 13} 16:54, 2014년 8월 2일(UTC)

  @기술 13: 됐다.검토 후 보다 적절한 제목으로 자유롭게 이동하십시오.홀더 18:34, 2014년 8월 2일(UTC)

해체 제안

나는 최근에 DPL 봇의 토크 페이지에 제안을 남겼고, 스틸1943은 나도 여기서 만들 것을 추천했다.DAB Solver의 안타까운 죽음으로 대체 솔루션에 대한 검색이 생겨났으며, 이를 제안하고자 한다.러시아어 위키피디아에서 디비게이션을 할 수 있는 링크를 만들면 분홍색으로 강조 표시되므로 바로 알 수 있다.이와 같은 것이 영어 위키백과에 실현 가능할까?WQUlrich (대화) 23:11, 2014년 7월 31일 (UTC)

@WQUlrich: Dab Solver는 여전히 한 번에 한 기사씩 잘 작동한다 - 오래된 링크는 디스펜서의 새 집으로 리디렉션된다.WPCleaner는 또 다른 옵션이다.GoingBatty (토크) 23:29, 2014년 7월 31일 (UTC)

링크 중 하나의 다른 색상을 발견하면 페이지 미리보기(또는 페이지 저장 후)에 바로 알 수 없다.하지만 그렇다고 해서 여러분이 혼란 페이지가 아닌 잘못된 기사에 연결한다면, 도움이 되지 않을 것이다. (즉, 은하수에 연결하려고 했을 때 은하수에 연결하려고 했던 것)그래서 그것은 단지 절반의 해결책일 뿐이다.내 스마트 링크 스크립트를 사용할 필요는 없고, 다른 방법은 네비게이션 팝업 가젯과의 링크를 확인하는 것이고, 편집하는 동안 좀 더 편리하게 사용할 수 있게 만들었을 뿐이다.그러나 내가 아는 한 정말 다른 방법은 없다. --V111P (대화) 07:16, 2014년 8월 1일 (UTC)

그런데 이것을 common.css에 넣으면 원하는 결과를 얻을 수 있다: --V111P (토크) 07:37, 2014년 8월 1일 (UTC)

@V111P: 그것은 redirs용이지, dab 페이지가 아니다.WQUlrich가 원하는 것은 링컨과 같은 링크의 스타일을 다르게 할 것이다.그 링크의 출처를 조사하면<a href="/wiki/Lincoln" title="Lincoln">Lincoln</a>없는class=또는id=다른 스타일을 유발하는 데 사용될 수 있다. --Redrose64 (대화) 12:17, 2014년 8월 1일 (UTC)

고마워, Redros64.러시아어 위키피디아에는 리디렉션에 사용할 수 있는 장치가 있어서 혼란스러웠어.그러나 dabs에 대한 가젯은 보이지 않고 dabs 링크에 대한 기본 색상은 다른 링크와 동일하다(그리고 클래스나 ID가 없다). --V111P (토크) 17:44, 2014년 8월 1일(UTC)

@Redros64: 알았어, 내가 틀렸어.링크 색상이 같은 페이지 미리보기의 링크만 보고 있었는데, 저장된 페이지에서는 해제 페이지의 링크가 분홍색 배경(ru:2D - 3D 링크)으로 되어 있다.나는 그것을 하는 대본을 찾았다: ru:MediaWiki:가젯-bkl-check.js.당장 여기서 작동하게 할 수는 없지만, 할 수 있다(그리고 지금 우리가 __DISAMB를 가지고 있으니 더 좋은 방법이 여기 있다.설명 템플릿의 IG__).--V111P (대화) 19:57, 2014년 8월 1일 (UTC)

@V111P: 가젯으로 설정되지 않았지만 사용자:아노미/링크 분류기는 링크 색상을 dab 페이지로 변경하는 방법을 알고 있다.자세한 내용은 해당 페이지를 참조하십시오.저장된 페이지와 미리보기에서 작동한다. -- John of Reading (토크) 20:02, 2014년 8월 1일 (UTC)

와, 응답해줘서 고마워.하지만 내 머릿속엔...WQUlrich (대화) 22:08, 2014년 8월 1일 (UTC)

나도 고마워, 레딩의 존. --V111P (토크) 06:21, 2014년 8월 3일 (UTC)

요약 편집 도구를 다시 가져올까?

기여 페이지 하단에 있는 요약 편집 링크를 클릭하면 [14]가 표시된다.나는 우리가 편집 요약을 많이 사용하는 사람들을 위해 이것을 되찾았으면 좋겠다. 만약 당신이 오래된 기여를 찾으려고 한다면 그것은 매우 유용할 수 있다.고마워요.더그웰러(대화) 12:52, 2014년 8월 1일(UTC)

@Dougweller:그것은 나에게 효과가 있다.어떤 오류 메시지를 보셨습니까?자오펑 리[말씀] 기여...] 2014년 8월 2일 07:33(UTC)

@Zhaofeng Li: 기억이 나지 않고 지금 내게 효과가 있는 것처럼...알려줘서 고마워.더그웰러(토크) 10:57, 2014년 8월 2일(UTC)

Overtype 모드

나는 Visual Editor를 사용하여 Google Chrome의 페이지를 편집하고 있었는데 어떤 이유로 인해 Overtype 모드가 켜졌다.Visual Editor에서 일반 편집 모드로 전환했는데, 그게 고쳐지지 않았어.누군가에게 이런 일이 일어난 적이 있는가(Visual Editor bug, 아마도?) 그리고 어떻게 Overtype 모드를 끄는가?알타멜 (토크) 22:40, 2014년 8월 1일 (UTC)

삽입 키를 눌렀는가? --NE2 22:42, 2014년 8월 1일(UTC)

내가 그랬을지도 몰라.방금 테스트해 봤는데 이상한 건 VE에서는 오버타입을 유발하지만 일반 편집기에는 그렇지 않다는 겁니다.또 그런 일이 생기면 그냥 인서트 키를 쳐서 오버타입을 끌게.고마워, 알타멜 (토크) 22:46, 2014년 8월 1일 (UTC)

하이퍼링크바이러스

구글 크롬을 사용할 때 하이퍼링크 바이러스에 의해 링크가 Planarian 기사에 주입되는 경우도 있다.그 바이러스에 의해 해킹된 문구들 중 일부는 '먹다', '백과사전', '가족', '음식', '놀이', '시스템'이다.위키피디아가 그 바이러스와 미래의 하이퍼링크 바이러스의 작용을 차단하기 위해 진화할 수 있는 방법이 있을 경우에 대비해서 나는 이것을 언급했다.나는 그들을 신경 쓰지 않지만 몇몇 사람들이 신경 쓸 경우를 대비해서 이것을 언급했고, 그 바이러스의 작용을 차단하기 위해 인터넷 설정을 사용하는 방법을 결코 배우지 않을 것이다.블랙밤추 (토크) 04:35, 2014년 8월 1일 (UTC)

@Blackbombu: Diffs? --NeilN^{talk to me} 05:03, 2014년 8월 1일 (UTC)

링크된 하이퍼링크 바이러스는 혼동되지만 나는 의심스러운 "하이퍼링크 바이러스" BestSaveFor를 검색했다.너랑 아케이드Yum.이것은 방문 웹사이트에 없는 링크를 삽입하는 나쁜 브라우저 확장 기능을 가진 독자들을 위한 것으로 보인다.페이지가 사용자에게 전송된 후 사용자 자신의 소프트웨어에 의해 링크가 삽입되면 위키피디아가 어떻게 할 수 있는지 모르겠다.프라임헌터 (대화) 2014년 8월 1일 12시 42분 (UTC)

내가 직접 하이퍼링크 바이러스를 만들었는데, 내가 사악한 신 가면처럼 해서 그런 것 같지는 않아.빠른 삭제 위키는 위키백과처럼 검증가능성에 대한 규칙을 가지고 있지 않다.나는 Chips Challenge Wiki에서 Blackbombuchu로 계정을 만들었지만, Blackbombuchu로 'Stay login'을 클릭하지 않고 Chips Challenge Wiki에 로그인한 후 다른 wikia.com 웹사이트로 가서 Chips Challenge Wiki가 많은 웹사이트의 일부라는 것을 깨닫지 못했다.나중에 나는 스피디 삭제 위키를 블랙밤추로 계정을 만들려고 했지만 이미 사용자 이름이 찍혔다고 해서 맹신 마스크로 등록했다.스피디한 삭제위키에서 계정을 만들지 않았기 때문에 칩스 챌린지위키에서 만든 나만의 계정인 줄 몰랐다.블랙밤추 (토크) 15:42, 2014년 8월 1일 (UTC)

여하튼 이것은 위키백과와는 아무 상관이 없다. --NeilN 16:04, 2014년 8월 1일 (UTC)

여러분이 사용하고 있는 문구에도 불구하고, 이것들은 바이러스가 아니며 위키피디아가 그것들을 "차단"하기 위해 할 수 있는 것은 아무것도 없다 - 그것은 전적으로 여러분 자신의 웹브라우저 내의 여러분 자신의 컴퓨터에서 일어나고 있다.Andrew Gray (대화) 17:38, 2014년 8월 1일 (UTC)

사실 CAMMAC 컴퓨터야.구글 크롬은 자바 업데이트 바이러스를 다운받아 오랫동안 사용하지 않아 구글 크롬이 작동 상태가 매우 좋지 않아 내 컴퓨터에 하이퍼링크를 주입하는 문제가 있는지 알 수 없었다.빠른 삭제 위키는 누구나 편집할 수 있어 하이퍼링크 바이러스를 자유롭게 편집해 잘못된 정보를 수정할 수 있다.블랙밤추 (토크) 23:13, 2014년 8월 1일 (UTC)

사실, 위키피디아는 이러한 행동을 차단할 수 있는 한 가지 도구를 가지고 있다 - 편집 필터.문제는 이 문제로 야기된 혼란이 그것을 정당화할 만큼 나쁜 것인가 하는 것이다.עודדוווו Od Mishehu 12:03, 2014년 8월 3일 (UTC)

나는 편집 필터가 여기에서는 어떤 영향도 미치지 않을 것이라고 생각한다 - 이것들은 실제로 편집을 통해 위키백과 기사에 추가되는 것이 아니라, 사용자 컴퓨터의 표시 시점에 브라우저에 추가되는 것이다.우리가 할 수 있는 건 아무것도 없어Andrew Gray (대화) 14:08, 2014년 8월 3일 (UTC)

편집기 상호 작용 분석기

• 나는 다른 편집자와 거의 같은 시기에 기사를 편집하는 사고를 찾기 위해 도구를 사용해 왔다.2014년 8월 1일 현재 http://toolserver.org/~snottyung/snotctr.html에서 동작하지 않았다.위키백과:도구에는 "편집기 상호작용 분석기"가 나열되어 있으며, 이 분석기를 클릭하면 toleabs:virma/editorinteract.py이 작동하지 않음으로 이어진다.아마도 이것은 내가 몇 달 전에 읽은 것으로 기억되는 툴 서버 업데이트 때문일 것이다.나는 어떤 방향이나 접근 가능한 설명 없이 중요한 기능성을 앗아가는 "개선"을 좋아한다.실제로 작동하는 대체 편집기 상호 작용 도구가 있는가?모든 "도구"가 현재 다른 웹 사이트에 있는 경우, 다른 사용자가 위키백과를 업데이트하십시오.도구? 에디슨 (토크) 15:36, 2014년 8월 1일 (UTC)

"그것은 2014년 8월 1일부로 작동하지 않았다." - 툴서버가 다운된 2014년 7월 1일 이후로 영구적으로 작동하지 말았어야 했다.이 페이지에는 많은 내용이 수록되어 있으며, 그 중 상당수는 현재 페이지 아카이브에서 찾을 수 있다. --Redros64 (대화) 15:54, 2014년 8월 1일 (UTC)

문제는 나머지 스코티툴과 함께 WMF 실험실의 버전도 다운된 것처럼 보인다는 점이다.(toollabs:scottytools/index.html)추가위트니스 이름여기 (토크) 22:52, 2014년 8월 1일 (UTC)

Labs 교차 결합에 대한 편집자 상호 작용 도구 사용— Maile (talk) 23:15, 2014년 8월 1일(UTC)

또한, 당신이 torollabs:virma/editorinteract.py 위에 링크한 도구는 나에게 잘 열린다.— 마일 (대화) 23:20, 2014년 8월 1일 (UTC)

톨라브:sigma/editorinteract.py 교체 도구는 절대 작동하지 않았으며, 내가 작동하지 않는다고 말할 때 오류 메시지만 제공했다.그러니까 그냥 "간헐적으로 작동한다"고만 해.그 페이지의 "위키스토크" 도구는 여전히 도구 서버 도구로, 단지 404 오류를 발생시킨다.당신이 말한 대로 "이 페이지에는 많은 정보가 있다"고 했으므로 위키 소프트웨어 마법사들이 7월 1일 툴 서버가 종료되었다는 것을 알았다면, 툴 서버 스크립트에 대한 툴 페이지에는 왜 여전히 링크가 있는가?고마워요.에디슨 (토크) 2014년 8월 2일 12시 34분 (UTC)

일부 공구 제공자들은 툴 서버가 다운되고 있다는 것을 완전히 잘 알고 있었고, 그것에 대해 아무것도 하지 않았다(무서운 일이든 그렇지 않든). 일부 공구 제공자들은 더 이상 우리와 함께 있지 않다.위키피디아에서 해당 도구에 대한 정보를 다음과 같이 보장하는 것은 일반적으로 도구 제공자의 책임이다.도구 - 일반 편집 가능한 페이지 - 최신 버전. --Redrose64 (대화) 16:58, 2014년 8월 2일(UTC)

지역사회는 도구 운영자와 함께 오랫동안 비활성화된 공구를 제거할 수 있어야 한다.עודדווו Od Mishehu 12:01, 2014년 8월 3일 (UTC)

리플링크

리플링크가 다시 작동하고 있는 것 같다.철회 결정이 번복되었는가? --P123ct1 (대화) 08:22, 2014년 8월 2일 (UTC)

"철회"?들어본 적이 없다.그냥 고장나서 지금 고친 것 같아.마트마 렉스토크 10:38, 2014년 8월 2일 (UTC)

부사장 기록 보관소를 보면 올해 7월 1일 철수에 대한 엄청난 논의가 있을 것이다.그것에 대한 격렬한 항의가 있었다.그때 해보니 효과가 없었는데 지금은 정상으로 돌아왔다. --P123ct1 (토크) 18:50, 2014년 8월 2일 (UTC)

나는 그것을 알고 있고, 말했듯이, 내가 알고 있는 어떤 권력자들로부터도 어떠한 결정도 내리지 않았다.툴서버 마이그레이션이 완료되지 않아 툴이 얼마간 고장났다.마트마 렉스톡스 18:55, 2014년 8월 2일 (UTC)

@P123ct1:철회되지 않았다.이 도구의 작성자는 처음에 이 도구를 새로운 WMF 호스트 도구 서버로 마이그레이션하지 않기로 결정했다.몇 번 탄원한 뒤 마음을 바꿨다. --닐N^{talk to me} 18:56, 2014년 8월 2일 (UTC)

그렇구나, 그렇구나. --P123ct1 (토크) 19:05, 2014년 8월 2일 (UTC)

그것은 http://dispenser.homenet.org에 있는 것으로 보인다 - 토올랩이 아니다.GoingBatty (토크) 22:57, 2014년 8월 3일 (UTC)

로그 항목과 작업이 일치하지 않음

실패한 사용자 플래그를 변경했지만 로그 항목에는 완료된 것으로 표시됨.몇 주 전에 68133번 버그를 열었는데, 다른 방법이 없을까?— xaosflux 15:08, 2014년 8월 3일(UTC)

사용자:Mr.Z-man/closeAFD.js(2개 콘트)

... 제대로 작동하지 않는 것 같다(AFDs를 거치는 것은 꽤 오래간만이다, 3월에는 여전히 괜찮았다).나는 비슷한 문제가 2012년에 이미 논의되었다가 해결되었다는 것을 알았다.그러나 지금 또 다른 이유가 있을지도 모른다.도움 요청. --Tone 20:45, 2014년 7월 23일(UTC)

아직도 안 먹히나?방금 위키백과를 닫았다.조항_for_deletion/Dunmore_Candy_Kitchen 성공. --j⚛e 데커^talk 18:41, 2014년 7월 24일(UTC)

정확히 뭐가 문제야?지난 한 달 동안 몇 군데 문을 닫았는데, 잘 되는 것 같았어.안sh666 08:43, 2014년 7월 25일 (UTC)

여전히 작동하지 않는다.1부(폐쇄 AFD 숨기기)는 정상 작동하지만, 폐쇄 요소 자체는 정상 작동하지 않는다.닫기 옵션을 선택하는 드롭다운 메뉴가 표시되지 않는 경우미디어위키 변화의 부작용이 될 수 있을까.Firefox 사용, btw.그 사이에 이 이야기가 보관되어 JJE 데커와 Ansh를 핑킹했다.고마워. --Tone 16:33, 2014년 8월 3일 (UTC)

경주 조건일지도 몰라.예를 들어 사용자 대화:티모테우스 카넨스/displaymessage.js#Z-man씨의 근접성 때문에 의존성 누락 또는 다른 것AFD.js는 그 기능을 가정하는 것 같다.displayMessage사용자:Timotherus Canens/displaymessage.js는 라인만 있으면 바로 이용할 수 있다.importScript('User:Timotheus Canens/displaymessage.js')실행됨(비동기적이기 때문에 나는 그렇게 생각하지 않는다).그리고 여전히 사용되지 않는 것을 사용하고 있다는 사실 또한 있다. addOnloadHook. Holder 01:28, 2014년 8월 4일(UTC) 대신

@Tone:Javascript 콘솔에 무엇이 보이나?T. 캐넌스 (대화) 01:49, 2014년 8월 4일 (UTC)

@tone: 나는 이것을 당신의 벡터.js에서 재현할 수 있다.는 것으로 보인다.fixTab()...에 의해 부서지다.더 이상 조사하지 않은 뭔가가 있어내가 그 코드를 삭제하고 두 개만 남겼을 때importScript줄, 나한테 효과가 있어T. 캐넌스 (대화) 02:03, 2014년 8월 4일 (UTC)

@Timotherus Canens:잘됐네, 지금 효과가 있는 것 같아.나머지 암호는 어디서 왔는지 기억이 안 나.정말 고마워! --Tone 07:16, 2014년 8월 4일 (UTC)

텍스트 레이아웃

표제나 텍스트를 infobox에 중앙 집중화하려면 어떻게 해야 하는가? 즉, L이나 R에 대해 정당화되지 않는다.MoS -P123ct1 (토크) 17:23, 2014년 8월 3일 (UTC)

일반적으로 인포박스의 행은 세 가지 방법 중 하나로 주어질 수 있다.

• 그 headern=매개변수는 굵은 면과 중심인 전체 너비 행을 생성한다(솔직히 말해서, 그것은 하나의 행이다).<th>...</th>원소).
• 그 datan=파라미터는 단독으로 사용할 경우 전체 너비 행도 생성되는데, 이 행은 중심이지만, 정상 무게(이상적으로, 이 행은 a)가 된다.<td>...</td>원소).
• A labeln= datan=쌍은 두 개의 열을 산출하며, 두 열은 모두 왼쪽 정렬됨: 왼쪽 열은 굵게 표시됨(a<th>...</th>);; 오른쪽 열은 정상 무게(a)<td>...</td>).

각각의 경우, n은 양의 정수이고, 각 행은 n에 대한 고유한 값을 가져야 한다; 라벨/데이터 쌍의 경우 n은 일치해야 한다. --Redros64 (토크) 19:39, 2014년 8월 3일 (UTC)

그 대답 고마워. --P123ct1 (토크) 12:55, 2014년 8월 4일 (UTC)

IE11의 벡터에서 이상한 테이블 렌더링

누군가가 벡터와 IE11을 사용하여 암스 산업을 살펴보고 그들이 표에 무슨 일이 일어나고 있는지 알아낼 수 있는지 볼 수 있을까?폭 명령과 관련이 있을 것 같아.벡터, 모노북에서 볼 필요가 있으며 현대는 렌더링에 아무런 문제가 없다.Nthep (대화) 18:25, 2014년 8월 3일 (UTC)

그 페이지는 내게 괜찮아 보인다.적어도 당신이 보고 있는 것을 묘사할 수 있는가? 그리고 스크린샷을 제공하는 것이 바람직하다.마트마 렉스톡스 18:39, 2014년 8월 3일 (UTC)

(충돌 편집)캡션과 테이블 내용은 별도의 테이블로 코딩되었으며, 그 중 첫 번째 테이블이 제대로 닫히지 않았다(마감). }실종되었다), 실제로 나머지 기사를 테이블로 옮겨 놓았다.보아하니 IE가 이 테이블을 화면의 25%로 만드는 이유는width="25%"Firefox는 그렇지 않지만 캡션 셀에는 적용됨.데이터 테이블 안에 자막을 넣어 고정시킨 겁니다. +도움말에서 설명하는 구문:표. SiBr₄ (대화) 18:47, 2014년 8월 3일 (UTC)

서버 과부하?

서버에 과부하가 걸리는 이유는?AFD에서 오류 메시지가 표시된다: "Wikipedia:삭제/로그/2014년 8월 3일 위키백과 무료 백과사전 < 위키백과:삭제 관련 기사 Log Sorry, 현재 서버 과부하 상태임.너무 많은 사용자가 이 페이지를 보려고 한다.이 페이지에 다시 액세스하기 전에 잠시 기다리십시오.잠금 대기 시간 제한" Edison (토크) 18:29, 2014년 8월 3일(UTC)

WP:BUNDle 스크립트/툴

WP를 수행하는 데 사용할 수 있는 스크립트 또는 도구가 있는가?번들이 더 쉬우십니까?삭발한 사용자가 최근에 내가 지우고 싶은 기사들로 다소 넓은 벽의 정원을 만들었지만 반짝반짝 빛나는 것은 별개의 논의를 할 것이고, 지명 작업을 손으로 하는 것은 고통스러운 일이다.가이진42 (토크) 18:32, 2014년 8월 3일 (UTC)

트윙클을 사용하여 첫 번째 토론을 시작한 후, 후속 기사를 수작업으로 공천에 추가할 수 있다.— 이것, 저것 및 다른 (대화) 08:06, 2014년 8월 4일 (UTC)

AWB의 사전 텍스트 기능을 사용하여 후속 페이지에 AfD 알림을 추가하는 작업을 쉽게 수행할 수 있다.직접 도구를 신청하거나 WP에서 다른 사람에게 요청할 수 있다.AWB/태스크.SiBr₄ (대화) 10:08, 2014년 8월 4일 (UTC)

기술 뉴스: 2014-32

07:37, 2014년 8월 4일 (UTC)

지도상의 선

안녕! 템플릿에 대해 잘 알고 있음:지도에서 여러 위치를 강조 표시할 수 있는 위치 지도+.하지만 그런 장소들 사이에 선을 긋는 템플릿이 있을까?이것들은 도로/철도 노선 등의 지도를 그리는 데 유용할 수 있다.§§§§ {T/C} 08:21, 2014년 8월 4일(UTC)

템플릿 데이터

템플릿 데이터를 추가하는 자동화된 시스템이 있는 것 같다. (CamelCase를 다시 한번 사용했기 때문에 사용자가 불친절하다!제발 그만 좀 해!특히 사용자 친화적인 변화의 부속물로서!)

그러나 문제는 템플리트 데이터가 적절한 무절제 태그에 있는지 확인하지 않고 템플리트 데이터를 템플리트 태그에 추가한다는 것이다.

아마도 템플릿 문서 페이지에서만 작동하도록 되어 있지만, 템플릿 페이지에서도 작동한다.

이거 벌레야?

최상의 선택:Rich Farmbrough, 22:40, 2014년 7월 31일 (UTC)

나는 이것이 위키피디아에서 논의되었다고 생각한다.마을 펌프(기술)/아카이브 128#MW 확장 "템플릿 문서 관리" 이제 모든 템플릿에 영향을 미침. --Redros64 (토크) 23:13, 2014년 7월 31일 (UTC)

삭제 로그에 삭제 검토에 대한 참고 사항 포함

그래서 오빈 페이지는 빠르게 삭제되었다.나는 그 결정에 동의하지 않고 페이지를 복원했다.하지만 재창작 당시 삭제 검토 논의가 벌어지고 있는지 몰랐다.기사 삭제가 현재 논의되고 있다는 메모를 삭제 로그에 작성할 수 있는가?오이야르밥시 (대화) 04:48, 2014년 8월 3일 (UTC)

기사 내역과 삭제 로그로 판단했을 때 페이지를 복원하지 않고 삭제된 페이지와 동일한 이름을 사용하여 새 페이지를 작성하셨습니다.그러나 삭제 로그는 삭제 당시 알려진 것만을 기록하고 있으며, DRV가 7월 26일에 제출되었기 때문에 7월 23일에 삭제된 것은 미래의 사건이라는 것을 알 수 없었다.삭제되기 전에 DRV가 올라오는 경우는 드물다(알 수 없는 경우). --Redrose64(대화) 09:29, 2014년 8월 3일(UTC)

사실 삭제 검토가 진행 중이던 7월 31일에 다시 만들었다.하지만 나는 그것이 일어나고 있는지 전혀 몰랐다.재창작자가 통지를 받아야 한다.오이야르밥시 (토크) 02:24, 2014년 8월 4일 (UTC)

응, 7월 31일에 다시 만들었잖아. 그 날짜는 내가 링크한 페이지 기록에 나와 있고, 나는 다른 주장을 하지 않았어.페이지를 재생성하면 페이지에 대한 삭제 로그를 볼 수 있다.삭제 로그에는 삭제된 페이지의 복원이 포함되며, 이 로그의 항목에는 DRV 페이지에 대한 링크가 포함되어 있는 경우가 많지만, 종종 DRV에 이어 페이지가 복원될 때 이러한 링크는 복원이 수행되는 동시에 항상 페이지를 복원하는 사람에 의해 수동으로 추가된다.예를 들어, Formato에 대한 삭제 로그를 참조하십시오. Formato는 우연히 당신이 언급한 것과 동일한 DRV 페이지로 연결됩니다.때때로 DRV에 대한 링크가 삭제 항목에 포함되는데, 시퀀스는 (i) 페이지 삭제, (ii) 페이지 복원, (iii) 해당 복원을 위한 DRV 시작, (iv) DRV가 원래 삭제를 유지하므로 페이지가 다시 삭제되고 이번에는 DRV에 대한 링크가 로그에 포함된다.그러나 이러한 링크는 소급해서 추가할 수 없다: 로그 항목은 완전히 수정될 수는 있지만 수정할 수는 없다. --Redrose64 (토크) 07:11, 2014년 8월 4일 (UTC)

그래, 내가 이해한 대로야.소프트웨어 변경으로 편집자가 삭제 로그 위에 나타날 삭제된 페이지에 이 문제에 대한 해결책으로 공지할 수 있는지 궁금했다.오이야르밥시 (대화) 05:49, 2014년 8월 5일 (UTC)

자동으로 범주를 알파벳 순으로 정렬하고 구성하기 위한 BOT 만들기

수년 동안 수작업으로 이 작업을 해 온 사람으로서, 기술적으로 능숙하고 다음과 같은 봇을 만들고 운영하는 방법을 알고 있는 모든 분에게 간곡히 간청한다.

1. 각 문서 및 카테고리 페이지의 모든 카테고리를 알파벳 순으로 자동 정렬
2. 생년월월일, 세기, 숫자/숫자로 시작하는 모든 범주와 같이 숫자로 시작하는 각 기사 및 범주 페이지에 범주를 배치할 위치에 대한 통일된 시스템을 만드십시오.

위키백과의 중앙 집중식 토론을 참조하십시오.Bot requests/Archive 61#범주를 자동으로 알파벳순으로 작성하고 구성할 수 있는 BOT 만들기감사합니다, IZAK (대화) 09:10, 2014년 8월 4일 (UTC)

VPP에서 다시 토론 시작

위키백과를 참조하십시오.마을 펌프(정책)/아카이브 114#자동으로 범주를 알파벳화하고 구성할 수 있는 BOT 만들기감사합니다, IZAK (대화) 22:48, 2014년 8월 5일 (UTC)

Derek Jeter 모바일 버전의 이미지 압축 문제

데릭 지터에게 이상한 구린내 나는 방금 발견했는데 이게 알려진 문제인지 아닌지 찾을 수가 없어.en.m.에서 페이지의 모바일 버전을 보는 중.wikipedia.org, 이미지 중 한 개(및 한 개만)가 그 높이의 절반 정도로 수직으로 압축되어 표시되는 것을 알았다. 이 사진: 파일:데릭 지터 2004.jpg.이미지가 바탕 화면 보기에서는 압축되지 않으며, 모바일 보기에서는 이미지가 스퀴핑되는 코드를 볼 수도 없다.이 기사가 얼마나 교통량이 많은지 생각해 볼 때, 나는 그 기사를 여기서 꺼내야겠다고 생각했다.도움이 된다면 아이패드용 사파리(Safari)를 사용하고 있다. --넬리블리(대화) 16:16, 2014년 8월 4월 4일 (UTC)

Firefox 31에서도 (하단의 모바일 뷰 링크 사용) 정확히 같은 문제가 보인다.나는 아마도 당신이 당신의 기계에 오래된 이미지를 저장해 두었을 것이라고 생각했다; 하지만 나는 그 페이지를 방문한 적이 없고, 그래서 나는 그 이미지를 직접 캐시할 수 없기 때문에, 그것은 문제가 되지 않는다. --Redros64 (대화) 17:31, 2014년 8월 4일 (UTC)

저 이미지는 코드의 태그를 사용하고 있다. T65134와 관련이 있는가?Andrew Gray (대화) 2014년 8월 4일 18시 40분(UTC

이미지가 넓이보다 높기 때문에 upright유효하다. --Redros64 (대화) 18:50, 2014년 8월 4일 (UTC)

페이지에 대한 HTML은<img />요소, 특성 중 일부는 다음과 같다.src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Derek_Jeter_2004.jpg/170px-Derek_Jeter_2004.jpg" class="thumbimage" data-file-width="623" data-file-height="935" height="255" width="170"나는 그 일을 빠뜨렸다.alt=그리고srcset=속성은 영향을 미치지 않는다고 생각하니까특히 꼿꼿한 엄지손가락 이미지에 대해 지정된 폭과 높이가 맞는 것 같다. --Redrose64 (토크) 19:02, 2014년 8월 4일 (UTC)

그것은 확실히 태그의 유효한 사용이지만, 직립은 적어도 일부 이미지에서는 모바일에 이상한 영향을 미치는 것처럼 보인다.HTML 소스에서 파일 크기에 대해 주어진 비율은 양쪽 모두 동일하지만 로드되는 파일 자체가 손상됨.이상하다. 앤드류 그레이(토크) 19:37, 2014년 8월 4일 (UTC)

나는 Commons File 페이지의 캐시를 지웠는데 지금은 괜찮아진 것 같아.—DJ (대화 • 기여) 08:17, 2014년 8월 5일 (UTC)

나도 이제 괜찮아.감사합니다, 여러분. --넬리블리 (대화) 05:21, 2014년 8월 6일 (UTC)

로고의 배경색 질문

회사 담당자가 로고 파일:HG 로고-2012-spot Col-01.jpg

그 이미지는 분명히 흰색 바탕을 가지고 있다.

그러나 파일 히스토리에서는, 《수소학》이라는 글에서처럼, 배경은 검정색이다.

제가 무엇을 빠뜨리고 있나요?

(내 추측으로는 배경은 사실 흰색이 아니라 투명하지만 여전히 검은색으로 표시돼서는 안 되는 것 아닌가?)--S 필브릭(Talk) 13:05, 2014년 8월 5일 (UTC)

이미지는 JPEG이기 때문에 투명한 배경을 가질 수 없다.작업 대기열의 지연으로 인해 검은색 배경을 가진 구형 버전이 여전히 기사에 사용되고 있을 것이라고 장담한다.지금은 괜찮아 보이는데, 숙청이나 null 편집으로 고쳐야 한다. /~huesatlum/13:57, 2014년 8월 5일 (UTC)

고마워, 네 말이 맞는 것 같아.Purge를 시도했지만 null 편집을 할 생각은 없었다.--S Philbrick(Talk) 14:14, 2014년 8월 5일(UTC)

해결됨

(ec)아무것도 안했는데 지금은 괜찮아 보인다.--S 필브릭(Talk) 13:59, 2014년 8월 5일 (UTC)

Lua로 변환된 보호 템플릿

이는 이제 모든 보호 템플릿이 모듈 사용으로 전환되었음을 알리기 위한 것이다.보호 배너.스위치 뒤의 배경과 영향을 받는 템플릿 목록은 이 스레드를 참조하십시오.또한, 변환된 템플릿에서 이상한 점이 발견되면 거기에 메모를 남겨 두십시오.— 미스터 스트라디바리우스 2014년 8월 5일 (UTC)

정렬 가능한 테이블 글리치

안녕, List of long cantilever bridge span table sorting이 제대로 작동하지 않음(예: "Main span" 열을 정렬하려면 클릭, 다시 클릭해도 아무 일도 일어나지 않음).이는 '경간거리가 짧은 다수 교량' 행과 무관치 않아 보인다.이것을 고치는 가장 좋은 방법은 무엇인가?테이블에서 그 행만 빼는 것 말고도 고칠 방법이 없을까?86.128.1.157 (대화) 00:19, 2014년 8월 6일 (UTC)

열이 병합되면 정렬이 작동하지 않는다.나는 마지막 줄을 없애서 고쳤다.러슬릭_제로 09:05, 2014년 8월 6일 (UTC)

행을 헤더 셀로 만들거나(이 경우 실제로 바닥글로 만들 수 있음) 정렬 최하위 클래스를 사용하는 것도 이 경우 효과가 있었을 것이다.—DJ (대화 • 기여) 09:25, 2014년 8월 6일 (UTC)

필요한 정보 - GEO IP 조회 서비스

안녕, 우리는 다음 서비스 http://geoiplookup.wikimedia.org/,을 우연히 발견했는데 이 서비스와 관련된 몇 가지 사항을 알고 싶다.

1) 이 서비스에 대처할 수 있는 교통량2) 가용성과 결과 면에서 이 서비스가 얼마나 신뢰할 수 있는가.3) 본 서비스와 관련된 가격책정이 있는가? 또는 비용이 없는가?

너의 끝에서 답장이 오기를 고대하고 있어.— Nmalh7(대화 • 기여) 03:24, 2014년 8월 6일(UTC)에 의해 추가된 사전 서명되지 않은 논평

@Nmalh7:이것은 상업적인 서비스가 아니며 유보적인 성격을 가지고 있다.그것을 우연히 사용하는 것보다 더 많이 사용하는 것은 감사하지 않다.—DJ (대화 • 기여) 09:18, 2014년 8월 6일 (UTC)

위키백과 앱/모바일 버전의 요약 통조림

위키백과 앱/모바일 버전에 대한 불만/오퍼 피드백을 어디서 해야 하는가(그것들이 같은 것인지는 확실하지 않지만 그렇다고 생각한다).그 장소가 여기라면 미리 로드된 편집 요약을 제거하거나 강조를 해제할 것을 제안하고 싶다.편집한 후 앱에 올라오는 화면을 말하는 건데, 저장하기 전에 "이 기사를 어떻게 개선하셨나요?"라고 묻는 화면은 네 가지 옵션으로,고정 타이포, 고정 문법, 추가 링크 및 기타.이 기능이 추가된 이후, "Fixed typeo" 편집 요약은 예상대로 매우 유명해졌다. - 이것은 첫 번째 옵션이고 가장 두드러진 옵션이며, 편집 요약을 건너뛰는 것은 분명하지 않지만 거의 정확하지 않다.패트롤러로서, 나는 허위 편집보다 편집 요약을 전혀 볼 수 없다; 최근까지 허위 편집 요약을 보면 대개 사용자가 의도적으로 탐지를 회피하려 한다는 것을 알 수 있었다. --봉와리어 (대화) 09:35, 2014년 8월 6일 (UTC)

이것은 모바일 앱에만 해당되는 것 같다.버그질라에 대한 버그 리포트도 제출했는데, 이런 것들이 가는 곳이었죠.그 제안은 bugzilla:69168로 알려져 있다.—DJ (대화 • 기여) 10:29, 2014년 8월 6일 (UTC)

고마워, 도청기에 응답했어토론을 한 곳에서 계속하려면 거기서 응답하라. --Dan Garry, Wikimedia Foundation (토크) 14:55, 2014년 8월 6일 (UTC)

두 분 덕분입니다. --봉와리오르 (대화) 17:18, 2014년 8월 6일 (UTC)

가노티체

Chrome + Windows 7에서 List_of_longest_cantilever_bridge_spans와 같은 많은 페이지를 편집할 때 콘솔에 다음 두 가지 오류가 표시됨:

1. JavaScript 구문 분석 오류: 구문 분석 오류:'MediaWiki:' 파일에 피연산자가 누락됨11호선 가젯-gonotice.js
2. XMLHtpRequest는 https://commons.wikimedia.org/w/api.php을 로드할 수 없음.요청된 리소스에 '액세스-제어-허용-오리진' 헤더가 없음따라서 오리진 'https://en.wikipedia.org'은 액세스가 허용되지 않는다.

러슬릭_제로 10:37, 2014년 8월 6일 (UTC)

첫째는 고쳐야 한다.나는 Genotice와 관련이 없는 두 번째 오류를 재현할 수 없다. -- [[User:Edokter]] {{talk}}2014년 8월 6일 10시 45분(UTC)

(갈등 편집) 위 기기로 Genotice를 마이그레이션한 것 같군.홀더.위키, 에독터: 뭐라고 대답하나? --Redrose64 (대화) 10:52, 2014년 8월 6일 (UTC)

Genotice를 가젯으로 마이그레이션

MediaWiki:Gonotice.js to MediaWiki:가젯-gonotice.js, 그래서

• 사용자는 자신의 기본 설정에서 해당 기능을 선택 해제하거나 비활성화할 수 있다(2010년 Peter에 의해 요청, MediaWiki talk:Gonotice.js#이걸 끌 수 있을까?와 위키백과의 다른 사용자들에 의해:가노티체#꺼??);
• CSS(표시)는 JS 코드(로직)와 분리된다.
• ResourceLoader가 코드를 축소함
• ResourceLoader가 다른 가젯에 사용되는 것과 동일한 HTTP 요청에 로드함

testwiki에 추가한 "<gadget-gonotice" 옵션을 활성화하는 경우:특수:기본 설정#mw-prefection-gadgets, testwiki:특수:워치리스트.영어 위키백과에서 이 기기는 현재 행동을 유지하기 위해 기본적으로 활성화될 것이다.홀더.위키 00:18, 2014년 7월 27일(UTC)

그것은 이미 선택불가였다. 나는 적어도 세 번은 그것을 하는 방법을 설명했었다.대부분은 이 페이지의 기록 보관소에 있어야 한다.

ri.건오티체 { 전시하다: 없는; } 

특수:MyPage/common.css. --Redrose64 (대화) 00:26, 2014년 7월 27일 (UTC)

그러면 JavaScript가 계속 로드되고(별도의 요청으로) CSS가 JavaScript 코드의 중간에 혼합된 상태로 유지된다.홀더.위키 00:29, 2014년 7월 27일(UTC)

제정신인 것 같지만, 일부 사용자에게는 왜 그런 종류의 알림을 가젯에서 찾는지 헷갈릴 수도 있다.아마도 단순히 기기에는 항상 숨겨져 있고, 이전과 같은 선택적 행동을 계속한다(Redrose가 설명한 대로).—DJ (대화 • 기여) 08:57, 2014년 7월 28일 (UTC)

@TheDJ: 이 스크립트를 (대부분의) 다른 로컬 스크립트가 있는 리스트에 두는 것이 혼란스럽다고 생각하지 않는다.

그리고 "숨겨진" 기본 가젯은 지원되지 않는다(mw:Gadgets 2.0은 아직 현실이 아니며, 우리는 "숨겨진" 가젯을 구현하기 위해 해킹을 사용하고 있다).그것이 지원되었다 하더라도, 그것은 사용자들이 나의 목표 중 하나인 스크립트 코드 로드를 거부할 수 없게 할 것이다.홀더 12:32, 2014년 7월 28일(UTC)

• 이 기기를 만드는 것은 합리적인 것처럼 보인다(확실히 선택되지 않는 조건에서는, 선택권은 스스로 상실할 것이다).그러나, 내가 생각하기에, 그것은 (Commons가 사용한다고 믿는 것처럼) 비지질 메시지를 포함한 모든 감시 목록 메시지를 하나의 옵트 아웃 기기로 바꾸는 것을 볼 수 있는 좋은 기회가 될 수 있다.Andrew Gray (대화) 11:47, 2014년 7월 28일 (UTC)

한 가지 다른 질문 - 이것이 우리가 새로운 건조를 추가하는 방법에 중요한 영향을 미칠까?정기적으로 관리하는 사람은 우리 둘, 셋뿐이고 나는 백엔드를 잘 이해하지 못한다 :-)Andrew Gray (대화) 11:59, 2014년 7월 28일 (UTC)

@Andrew Gray:그렇지 않아.유일한 변화는 그것에 사용된 페이지의 제목일 것이다.그리고 나는 당신이 기존 genoitice 스크립트/gadget을 비지오타겟 메시지에도 사용할 수 있다고 생각한다: 단지 큰 좌표(예:corners:[ [-1000,-1000], [1000, 1000] ], testwiki에서 했던 것처럼 , 그리고 그것은 모두를 위해 보여져야 한다 (대부분?)사용자. 홀더 12:19, 2014년 7월 28일 (UTC)

곰곰이 생각해 보면, 기존의 감시목록 고시를 있는 그대로 유지하는 것이 아마도 좋을 것이라고 생각한다. 그들은 "중요한 이슈의 적극적인 홍보"를 위한 꽤 핵심적인 도구로서, 우리는 아마도 지역 고시를 탈퇴한 사람들에게도 그것들이 가시적으로 유지되도록 해야 할 것이다.앤드루 그레이 (대화) 2014년 7월 28일 19:18, (UTC)

감시대상에서 수평줄 위에 나타나는 부분을 말하는 거지?홀더 19:58, 2014년 7월 28일(UTC)

예, 정말로 :-) Andrew Gray (대화) 20:28, 2014년 7월 28일 (UTC)

댓글 더 있어?테스트 버전에서 문제가 발견되었는가?지금 구현할 수 있는가?홀더 13:59, 2014년 8월 4일(UTC)

난 문제가 없다고 본다.그러나 직선적인 조치가 아닌 한 정확한 지침이 필요하다(이 경우 Common.js로 수행하고 가젯 정의를 만들기만 하면 된다). -- [[User:Edokter]] {{talk}}2014년 8월 5일(UTC) 18시 42분

@Edokter: 테스트 wiki에서 JS를 복사할 수 있다(지금 영어 위키백과에 있는 것과 일치하도록 알림 목록을 업데이트하기만 하면), CSS를 별도의 페이지로 이동하고, MediaWiki에서 로더 코드를 제거할 수 있다.Common.js/watchlist.js, MediaWiki에 줄 추가:가젯 정의 및 가젯 설명 작성.나는 지금 (글로벌) 편집인터페이스 권한을 가지고 있기 때문에 testwiki에서 편집한 내용을 다시 확인하고 관련 변경 사항을 enwiki에 복제할 수 있다.홀더 21:23, 2014년 8월 5일(UTC)

아, 그럼 내 도움은 별로 필요 없겠네 :) 계획은 건실해.여기에 가젯을 만들면 활성화하기 전에 코드를 다시 확인해볼게. -- [[User:Edokter]] {{talk}}21:53, 2014년 8월 5일(UTC)

@Edokter: 페이지를 이동할 때 가젯을 활성화하고 이전 로더 코드를 동시에 제거해야 하므로 코드를 검토할 수 있는 기회를 주기 위해 나는 대신 testwiki에서 버전을 업데이트했다.반면 MediaWiki 생성:Gadget-genotice.css 및 MediaWiki:가젯-gonotice는 가젯이 만들어지지 않는 동안 문제를 일으키지 않을 것이고, 따라서 이러한 것들은 이루어진다.홀더 23:16, 2014년 8월 5일(UTC)

testwiki에서 .js 가젯을 복사했다.코드가 수정되었으므로, 어쨌든 이동은 작동하지 않을 것이다. -- [[User:Edokter]] {{talk}}2014년 8월 6일 08:09(UTC)

내가 복사하고 이동할게.그것은 모든 관찰자들을 감동시킬 것이다.난 갈아탈 거야. -- [[User:Edokter]] {{talk}}2014년 8월 6일 08:36(UTC)

다 됐어. Genotice는 이제 (기본 사용 가능) 가젯이 되었다. -- [[User:Edokter]] {{talk}}2014년 8월 6일 08:56(UTC)

페이지 로딩마다 여전히 대량으로 로딩되어 있다.대량 데이터를 MediaWiki로 이동하는 방법:기계-gonotice-core.js? -- [[User:Edokter]] {{talk}}2014년 8월 6일 10시 46분(UTC)

@edokter: 좋은 생각이야.이렇게 나누면 어떨까?

1. 모듈 "ext.gadget.gonotice"
   • MediaWiki:Gadget-genotice.js: 로더 모듈만(사용자가 감시 목록에 있는지 테스트하고 필요한 경우 다른 모듈을 로드함)
2. 모듈 "ext.gadget.genotice-core"
   • MediaWiki:가젯-gonotice-core.css: 현재 미디어위키:가젯-gonotice.css
   • MediaWiki:Geo-Gonotice-core.js: geoWikiLinker, hideGonotice, displayGonotice 및 runGonotice(현재 MediaWiki의 하단에 있는 genotice:가젯-genotice.js)
   • MediaWiki:가젯-genotice-list.js: 통지 목록

공지사항 목록과 이를 사용하는 코드의 구분은 코어 코드의 우발적인 변경을 방지하고, 핵심 스크립트의 변경을 사람들이 별도로 지켜볼 수 있도록 하는 데 도움이 될 것이다.또한 다른 위키에서 코드를 사용하는 데 도움이 될 수 있다(자체적인 통지 목록이 있지만 공통적인 "핵심" JS를 사용할 수 있다).홀더 13:35, 2014년 8월 6일(UTC)

코어 부품을 게으르게 로드하는 것은 쉽지만 (가젯과 호출 mw.load.load로 정의하여) 동일한 방법으로 목록을 게으르게 로드할 수 있는가? -- [[User:Edokter]] {{talk}}14:56, 2014년 8월 7일(UTC)

@Edokter: test wiki: testwiki:특수:PrefixIndex/MediaWiki:기계-건조체.우리는 각각의 가젯에 두 개 이상의 js 페이지를 추가할 수 있고, 그것들은 하나의 모듈로 합쳐진다.홀더 01:43, 2014년 8월 8일(UTC)

그것이 내가 알아야 할 것이다.고마워요. -- [[User:Edokter]] {{talk}}07:46, 2014년 8월 8일 (UTC)

또한 완료.그렇게 하면 로드되는 코드 힙을 절약할 수 있다. -- [[User:Edokter]] {{talk}}2014년 8월 8일 08:41(UTC)

Sonia Sotomayor 페이지용 도구 리플링크

지난 주 동안 나는 소니아 소토마요르 페이지에 있는 리플링크 도구를 실행하여 최신 정보를 제공한다.처음 170여 건의 참고문헌에는 잘 되는 것 같았지만, 인용문 #180번과 #185번은 실제 기사 인용문과 일치하지 않는 것 같다.리프링크에서 인용문#180은 "징리치" 인용문을 위한 레드링크를 제공하지만, 기사 인용 번호는 징리치와 아무런 관련이 없다.이틀 동안 효과가 없었는데 누가 좀 봐줄래?이것은 링크 체크 체크 링크 보고서의 목록을 작성하기 위해 호출된 리플링크 입니다.로렌스프린시페 (토크) 00:14, 2014년 8월 5일 (UTC)

리프링크는 2~3일이 더 지나도 여전히 작동하지 않고 있으며, 현재 이 페이지의 13번지에 위의 리프링크 마을 펌프 섹션이 하나 더 있다는 것을 알게 되었다.누가 이것 좀 봐줄래?예를 들어 소니아 소토마요르 각주 #263에서는 에스콰이어 매거진에 성공적으로 연결되었지만, 레프링크스는 애리조나 주의 뉴스 언론에서 어딘가에 데드링크 공지를 한다.로렌스프린시페 (대화) 13:42, 2014년 8월 7일 (UTC)

@LawrencePrincipe:당신(그리고 다른 사람들)이 소니아 소토마요르 기사에 대해 많은 일을 한 것 같으니까, 현재 버전에 있는 Reflinks를 실행한다고 해서 그 문제를 재현할 수는 없는 것 같다.당신은 당신이 보고 있던 것과 같은 문제를 발생시키는 테스트 페이지를 당신의 사용자 공간에 만든 후, 사용자 토크에 대한 링크를 제공하기를 원할 수 있다.디스펜서/리프링크.행운을 빈다!GoingBatty (토크) 16:40, 2014년 8월 7일 (UTC)

@GoingBatty:, Hi Going Batty, 그래, 좋은 지적이야.누군가가 리플링크 오류를 확인할 수 있을 때까지 나는 앞으로 24-48시간 동안 모든 편집을 중지할 것이다.Cite No.263은 다음과 같은 데드링크 경고를 제공한다.

263 소토마이어는 불안한 졸업생들에게 미래를 포용할 것을 촉구한다(kold.com).

accessdate=2010년 5월 19일

날짜=2010년 5월 8일

출판사=KOLD-TV

410 2011-01-17년 이후 사망

그러나 기사의 각주 #263으로 바로 가면 263의 기사 각주는 리플링크로부터의 KOLD-TV 데드링크 통지와는 무관하지만 대신 에스콰이어 매거진을 이용한다.다른 사람이 확인할 때까지 모든 업데이트 편집을 연기하겠다.로렌스프린시페 (대화) 2014년 8월 7일 18:21, 7 (UTC)

@LawrencePrincipe:오, 너는 Reflinks가 아니라 Checklinks를 사용하고 있구나.기사에서 kold.com이 #259라고 나와 있음에도 불구하고 체크링크스가 #263을 kold.com으로 보여주고 있음을 확인시켜 준다.이 문제를 보고할 적절한 장소는 사용자 대화:디스펜서가 문제를 해결할 수 있도록 디스펜서/체크링크.행운을 빈다!GoingBatty (토크) 03:23, 2014년 8월 8일 (UTC)

기사 및 대화 페이지 탭

로그온하지 않고 나는 어떤 WP 기사도 보고 맨 위에 있는 처음 두 탭은 "기사"와 "대화"를 읽는다.

그런 다음 로그온하면 탭이 "페이지"와 "토론"으로 변경된다. 왜?이것은 새로운 사용자를 혼란스럽게 할 수 있다.

프로젝트 전체에서 기사 및 대화 페이지가 참조되는 방식에 동의하도록 탭을 "기사" 및 "대화"로 변경하도록 제안하십시오.

모노북 스킨, 파이어폭스 31: 노이스터(토크), 10:12, 2014년 8월 6일(UTC)

벡터에서는 그런 문제를 갖지 말아야 하고, 대부분의 '신입'자들이 그런 일을 하고 있기 때문에 나는 그것에 대해 너무 걱정하지 않을 것이다.—DJ (대화 • 기여) 10:21, 2014년 8월 6일 (UTC)

나는 번식할 수 없다.예시로 구체적인 페이지가 있으십니까? -- [[User:Edokter]] {{talk}}2014년 8월 6일 10시 23분(UTC)

이것은 영어 위키피디아의 맞춤형 미디어위키 메시지가 영어(엔)용으로만 설정되고 다른 언어로는 설정되지 않은 이슈로 보인다.(메시지: MediaWiki:Nstab-main 및 MediaWiki:말하라.) 노이스터, 설정에 어떤 언어를 설정했는가?만일 그것이 en-GB 또는 en-CA라면, 이러한 편집이 문제를 해결했어야 하지만, 만약 그것이 다른 것이라면 그것은 여전히 이전과 같을 것이다.꽤 많은 메시지들이 영국식 영어(en-GB)나 캐나다식 영어(en-CA)가 아닌 영어(en)만을 위해 커스터마이징되었기 때문에 많은 사용자들이 그들의 언어를 en으로 설정하기를 선택한다.— 미스터 스트라디바리우스^{♪ talk ♪} 2014년 8월 6일 (UTC)

네, 그것은 GB 단위였습니다.그 변화는 이미 효력을 발휘했다.빨리 일해!: 노이스터(토크), 2014년 8월 6일(UTC)

위키백과별:데이터베이스 보고서/사용자 기본 설정 스페인어, 프랑스어, 인도네시아어, 영국식 영어 및 아랍어가 상위 5개 언어임. -- Gadget850 ^talk 00:50, 2014년 8월 7일(UTC)

탭 링크 색

헬프 데스크에서 복사한 내용은 다음과 같다.

위키백과 페이지의 맨 위에 있는 탭 버튼에서 존재하지 않는 페이지(예: 존재하지 않는 대화 페이지)로 연결되는 링크는 푸르스름한 보라색을 나타낸다.기존 페이지와 구분하기 어렵다.존재하지 않는 페이지에 대한 일반적인 링크처럼 빨간색으로 만드는 css 코드가 있는가?—teb728 t c 00:57, 2014년 8월 6일(UTC)

사실, 그들은 보통 빨간색이다.네가 왜 그런 색깔을 보고 있는지 모르겠어.벡터 css에서 탭 색상을 바꿀만한 것이 보이지 않지만, 기존 css를 일시적으로 제거하고 무엇을 얻을 수 있는지 확인해 보십시오.SpinningSpark 02:15, 2014년 8월 6일(UTC)

나는 다른 브라우저와 다른 PC에서 로그인하지 않은 세션을 시도했다; 그것들은 똑같아 보였다.

생성된 HTML을 보았다: 정상적인 적색 링크 클래스="new"가 앵커에 적용되기 때문이다.탭 버튼의 경우 앵커는 li 내부 스팬에 있고, class="new"는 li에 적용되며, 닻은 클래스가 없다.

해결책으로 나는 덧붙였다.li.new a {color:Black; background:#ffc0c0;} 내 벡터 css에게.배경은 의도한 대로 옅은 붉은색이지만 본문은 여전히 보라색이다.—teb728tc 10:28, 2014년 8월 6일(UTC)

그래, 사실, 나는 전혀 색을 바꿀 수 없어.나는 이 css가

#p-cause a.new { color: #ba0000; } #p-cause a.new:new:new { color: #a55858; }

작업을 해야 하지만 유사한 css가 비적색 탭의 색상 변경에 성공하더라도 작업을 수행할 수 없다.WP에서 다음 사항을 물어 보십시오.VPT. SpindingSpark 10:44, 2014년 8월 6일(UTC)

@Spinningspark:문제는 그 문제가 아니라는 점이다.<a>을 가지고 있는 꼬리표를 붙이다.new수업은 하지만<li>그 둘레에 있는 요소내 생각에 CSS는

#p-causes ri.새로운 a {색을 칠하다:#ba0000} 

효과가 있을 거야벡터(Vector)에서 모노북(Monobook)을 사용했을 겁니다.#p-cactions모든 탭 링크보다는 "추가" 드롭다운 메뉴만 포함하는 div로 나타난다.

비록 나에게는 존재하지 않는 상위 메뉴 링크가 4대 스킨에서 모두 정상으로 빨간색을 띠고 있다.SiBr₄ (대화) 21:50, 2014년 8월 6일 (UTC)

@SiBr4: 그렇다면 왜 그럴까?li.new a {color:Black;} 나 안 변했어?나는 어떤 색을 지정해도 보라색이 보여. (Vector를 사용한다.)SpinnSpark는 헬프 데스크의 도우미다. 내가 문제를 가지고 있다.—teb728tc 23:10, 2014년 8월 6일(UTC)

CSS 규칙이 각 개별 탭 링크에 적용되는 사이트 전체의 CSS 규칙에 의해 덮어쓰여질 수 있다.추가하면 효과가 있는가?!important, 에서와 같이li.new a {color:black !important;}? SiBr₄ (대화) 23:17, 2014년 8월 6일 (UTC)

그것은 효과가 있다.고마워!—teb728 t c 00:12, 2014년 8월 7일(UTC)

이것은 원래 여기에 게시되었다가 이상한 이유로 헬프 데스크로 옮겨졌다. --Redrose64 (대화) 12:45, 2014년 8월 6일 (UTC)

그게 무슨 가치가 있든지 간에, 나는 그것이 비 버그 질문에 더 낫다고 생각했기 때문에 헬프 데스크를 옮겼다.Spinspark의 추천뿐만 아니라 생성된 코드와/또는 css 파일에 버그가 있는 것이 의심되기 때문에 나는 그것을 다시 이동시켰다.—teb728tc 20:20, 2014년 8월 6일(UTC)

벡터 스킨에 대한 사이트 CSS에 문제가 있는 것 같다.

칸막이하다.벡터탭 ri.새로운 a, 칸막이하다.벡터탭 ri.새로운 a:방문했다 {     색을 칠하다: #A55858; } 

이것은 벡터 스킨 탭의 레드링크 색상을 #A55858로 설정한다. - 방문 여부와 상관없이.저 검붉은색이 보라색으로 보일지도 모른다.그것을 모노북이 가지고 있는 것과 대조해 보라.

#p-causes .새로운 a {     색을 칠하다: #BA0000; } 

이것은 모노북 스킨 탭의 레드링크 색상을 #BA0000으로 설정한다 - 훨씬 밝은 색.벡터에서 이 밝은 색상을 사용하려면

칸막이하다.벡터탭 ri.새로운 a, 칸막이하다.벡터탭 ri.새로운 a:방문했다 {     색을 칠하다: #BA0000; } 

특수:MyPage/vctor.css --Redrose64 (대화) 23:31, 2014년 8월 6일 (UTC)

고마워!그 값은 사이트 CSS 벡터 파일에 사용되어야 하지 않을까?심지어 #BA0000도 나에게는 좀 지루해 보인다.보통의 빨간 고리는 #E00000에 더 가까워 보인다.—teb728tc 00:12, 2014년 8월 7일(UTC)

@TEB728: 일반적인 텍스트 내 레드링크(즉, 탭 등에 없는 링크)가 어떻게 스타일링되는지 확인하였다 - 벡터(Vector) 사이트 CSS

a.새로운, #p-personal a.새로운 {      색을 칠하다: #BA0000; } a.새로운:방문했다, #p-personal a.새로운:방문했다 {      색을 칠하다: #A55858; } 

MonoBook의 경우 사이트 CSS는

a.새로운, #p-personal a.새로운 {      색을 칠하다: #CC2200; } a.새로운:방문했다, #p-personal a.새로운:방문했다 {      색을 칠하다: #A55858; } 

따라서 일반 텍스트에서 방문되는 레드 링크는 벡터와 모노북, 즉 #A55858에서 모두 동일하지만 방문되지 않은 레드 링크는 다르다: 벡터에서는 #BA0000이고 모노북에서는 #CC2200 . --Redros64 (토크) 09:50, 2014년 8월 7일 (UTC)

표시제 템플릿 문제

{{DISPLAYTITLE} 템플릿에 문제가 있는 것 같다.앨범에 대한 기사에 사용되어 {{Infobox 앨범}} 템플릿에 포함된 기사 제목에 대한 일반적인 이탤릭체 형식을 재정의하면 기사 시작 부분에 보기 흉할 정도로 빨간 경고가 표시된다.예를 들어, "유럽 '72 (라이브)"의 최신 버전이 여기에 있다.Displaytitle override가 없으면 기사 제목은 "European '72 (Live)"로 표시되지만, 모국어 텍스트는 앨범 제목의 일부분이므로 이탤릭체로 표시해야 한다.이전에는 잘 작동했지만 -- 그리고 이탤릭체는 여전히 작동하고 있지만 -- 지금은 "경고: 표시 제목 "<i>European 72 (Live)"가 이전 표시 제목 "<i>Europe 72</i> (Live)"보다 우선한다"는 불쾌한 메시지가 표시되고 있다.이거 고칠 줄 아는 사람 있어?— 2014년 8월 6일(UTC) 19:53, Mudwater ^(Talk)

@무드워터:(템플릿이 아닌 동작 스위치)를 사용하려면 다음 항목도 사용하십시오. Italic title=no문서 상단에 있는 상자에 다음과 같이 설명되어 있다.{{infobox album}}템플릿 토크에서 설명한 것과 동일한 문제:Infobox 필름#경고. --Redros64 (대화) 21:51, 2014년 8월 6일 (UTC)

@Redrose64:좋아, 답을 줘서 고마워."이탈리아식 제목=아니오"는 예전에는 필요 없었고, 뭔가 바뀌었지만, 괜찮아, 이제 됐다.도와줘서 고마워.— 2014년 8월 6일(UTC) 22:16, 진흙탕 ^(Talk)

@무드워터:변경된 "뭔가"는 위키피디아에서 다룬다.마을 펌프(기술)/아카이브 128#Tech 뉴스: 2014-29 및 위키백과:마을 펌프(기술)/아카이브 129#디스플레이티틀 경고이제 MediaWiki는 한 페이지에 두 개 이상의 페이지가 있으면 불평한다.{{DISPLAYTITLE:}}그것들 중 하나가 템플릿 코드의 일부라고 해도, 예를 들어,{{infobox album}},{{infobox book}}또는{{infobox film}}. --Redrose64 (대화) 13:23, 2014년 8월 7일 (UTC)

@Redrose64:흥미롭군그게 다 설명이 되네.고마워요.— 2014년 ^(Talk) 8월 7일(UTC) 13시 27분

나는 사용한다고 생각했다. italic title=force여분의 {{DISPLAYTLE}이(가) 없으면 역시 효과가 있을 텐데, 내가 잘못 알고 있었다.GoingBatty (토크) 16:47, 2014년 8월 7일 (UTC)

웹 인용을 중단하시겠습니까?

webcitation.org에 접속하는 데 문제가 있는 사람?나는 8월 6일 대부분을, 몇몇 사이트를 보존하려고 노력해왔지만, 그렇게 할 수 없었다.웹사이트가 다운되었다고 한다.나는 또한 이미 보관되어 있는 링크에 접속하려고 했지만 역시 소용이 없었다.자금 부족으로 인해 잠시 폐쇄될 것이라는 얘기가 있었던 것으로 알고 있는데, 그렇지 않았으면 좋겠다.만약 그렇다면, 그것은 매우 당황스럽다. - Favre1fan93 (대화) 03:52, 2014년 8월 7일 (UTC)

그래, 나도 그걸 보고 있어.나는 아직 걱정하지 않을 것이다, 왜냐하면 이것은 보통 유지보수를 위해 가끔 일어나기 때문이다.흥미롭게도, 아마존닷컴은 또한 유지보수를 위해 다운되었다.— Huntster (t @c) 03:56, 2014년 8월 7일 (UTC)

호스트 해결에서 실패하는 것처럼 보이며, 인프라 문제를 암시할 수 있다. 결국 다운포어드바이저 보고가 있다.마지막으로 인용을 확인했는데, 그 문제는 사이트를 계속하는 것이 아니라 자금 지원이 없으면 신규 인용을 받지 않는 것이기 때문에, 영원히 다운되고 아웃이 되는 것은 아닌지 의심스럽다. --MASEM (t) 04:00, 2014년 8월 7일 (UTC)

모든 사용자가 볼 수 있는 삭제된 콘텐츠

로그 메시지 유형을 검색하여 로그 메시지를 볼 수 있다(예: 특수:로그/매스메시지 또는 특수:로그/가져오기.로그 작업으로 로그 항목을 검색하면 이 두 개의 로그 항목이 나타난다.예를 들어, 누군가가 매스 메시지를 보내도 로그 항목은 여전히 Special:에 나타난다.로그/매스메시지(log action remove)라고 되어 있는 경우에도 로그/매스메시지.실수로 삭제한 콘텐츠가 이런 식으로 사용자에게 노출되는 것 같다.정말 이렇게 해야 되는 거야?

'특수:메타와키에서 로그/일부 동작".불필요한 사적인 정보가 노출되는 것을 피하기 위해 어떤 로그 액션을 보고 있었는지 말하지 않겠다.

• 18:01, 2014년 6월 10일 바라스(대화 기여)(로그 액션 제거)(enwp arb 요청당)

Stefan2 (대화) 12:53, 2014년 8월 7일 (UTC)

IP 범위의 RSS 피드?

IP 범위에 걸쳐 등록되지 않은 사용자에 대해 병합된 피드를 얻을 수 있는 방법이 있는가?당신이 @pamentials (그것은 내가 아니다), 의회가 IPv6 시스템으로 업그레이드한다고 가정해 보자.표준 서브넷 어레이를 검색하는 유일한 방법은 2^64(다른 용어로 184467440737095516)의 서로 다른 사용자 이름을 검색하여 시스템을 포함하는 것인가?좀 더 작은 규모로, 나는 5시간 이상 걸리는 IPv6 '0/16' 네트워크를 탐색해 보았다.

IP 범위에 걸쳐 활성 사용자 이름을 쿼리하거나 개별적으로 액세스하지 않고 범위에 걸쳐 RSS 피드를 결합하는 보다 쉬운 방법이 있을 것으로 보인다.있어?제가 무엇을 빠뜨리고 있나요?— Joecover가 추가한 사전 서명되지 않은 의견(대화 • 기여) 19:55, 2014년 8월 7일(UTC)

IP 범위에 대한 기여도를 조회하는 기기가 있는데, 제목은 "허용 /16, /24 및 /27 – /32 CIDR 범위..."로 시작한다.자바스크립트 코드 입니다.Graham87 07:19, 2014년 8월 8일 (UTC)

VisualEditor 뉴스레터 -2014년 7월과 8월

VisualEditor 팀은 현재 버그 수정, 성능 향상, 기술 부채 감소 및 기타 인프라 요구를 해결하기 위해 주로 노력하고 있다.당신은 Mediawiki.org 주간 업데이트에서 최근 작업을 자세히 볼 수 있다.

VisualEditor의 대화 상자는 아이콘 대신 액션 단어를 사용하도록 다시 설계되었다.이를 통해 번역이 필요한 항목이 늘어났다.사용자 안내서도 업데이트되고 있다.

마지막 뉴스레터 이후 가장 눈에 띄는 변화는 대화 상자였다.각 대화 상자와 창의 디자인은 단순화되었다.가장 일반적으로 필요한 버튼이 지금 맨 위에 있다.사용자 피드백을 바탕으로 버튼에는 이제 아이콘("<" 또는 "X"와 같은)을 혼동할 가능성이 있는 대신 간단한 단어(예: "취소" 또는 "완료")가 라벨로 표시된다.링크, 이미지 및 기타 항목을 편집하기 위한 많은 버튼은 이제 링크된 페이지, 이미지 이름 또는 기타 유용한 정보를 클릭할 때 보여준다.

• 숨겨진 HTML 주석(편집자는 볼 수 있지만 독자는 볼 수 없는 노트)을 이제 읽고, 편집하고, 삽입하고, 제거할 수 있다.작은 아이콘(점 위에 흰색 느낌표)은 각 코멘트의 위치를 표시한다.아이콘을 클릭하면 댓글을 볼 수 있다.
• 이제 이미지뿐만 아니라 텍스트와 템플릿을 드래그 앤 드롭할 수 있다.새로운 배치 선으로 물건을 어디에 떨어뜨리는지 훨씬 쉽게 알 수 있다.이미지는 더 이상 단락의 중간에 놓을 수 없다.
• 모든 참조 및 각주(각주)<ref> 태그)는 이전에는 "삽입" 메뉴를 통해서만 액세스할 수 있었던 "수동화면-다이오드버튼-레퍼런스-툴팁" 각주(수동 형식)와 기존 인용문을 다시 사용할 수 있는 기능을 포함하여 이제 "삽입자" 메뉴를 통해 만들어진다."삽입" 메뉴를 통해 "시각화면-다이얼로그 버튼-레퍼런스리스트-툴팁"이 여전히 추가된다.
• 이미지 또는 다른 미디어 파일을 추가할 때 이미지 캡션을 즉시 추가하라는 메시지가 표시됨.원본 캡션 및 기타 설정을 유지하면서 이미지를 교체할 수도 있다.
• Wikipedia 모바일 웹 버전을 방문하는 모든 태블릿 사용자는 8월 14일부터 VisualEditor 버전을 선택할 수 있다.설정 메뉴에서 모바일 보기의 베타 버전을 선택하여 새 도구를 테스트할 수 있다.
• 링크 도구에는 다른 탭에서 링크된 페이지를 열 수 있는 새로운 "열기" 버튼이 있어 링크가 올바른지 확인할 수 있다.
• 사용자 테스트에 따라 도구 모음의 "취소" 버튼이 제거되었다.편집을 취소하려면 읽기 탭, 브라우저의 뒤로 단추를 클릭하거나 변경사항을 저장하지 않고 브라우저 창을 닫으면 페이지를 나갈 수 있다.

앞을 내다보며

팀은 계획된 작업에 대한 세부 정보를 VisualEditor 로드맵에 게시한다.VisualEditor 팀은 인용문을 위한 자동 채우기 기능을 곧 추가할 계획이다.빠르고 쉽게 참조할 수 있도록 하는 것에 대한 당신의 생각은 여전히 필요하다.직립 이미지 크기에 대한 지원이 개발되고 있다.디자이너들은 또한 테이블에 행과 열을 추가하는 것을 지원하는 일을 하고 있다.Internet Explorer(인터넷 익스플로러)를 지원하기 위한 작업이 진행 중이다.

피드백 기회

편집팀은 이번 주말에 런던의 위키마니아에서 두 가지 발표를 할 것이다.첫 번째는 토요일 16시 30분에 제품 매니저 제임스 포레스터와 개발자 트레버 파스칼과 함께 입니다.두 번째는 일요일 12시 30분에 개발자 Roan Kattouw와 Trevor Parscal과 함께 하는 것이다.

VisualEditor 피드백 페이지에 메모를 게시하거나 2014년 8월 14일 목요일 09:00 UTC(유럽, 중동 및 아시아의 경우 주간 시간) 또는 2014년 9월 18일 목요일 16:00 UTC(미국의 경우 주간 시간, 유럽의 경우 저녁)에 업무 시간 토론에 참여하여 질문, 제안 또는 문제를 공유하십시오.

이 뉴스레터를 직접 페이지(월 1회 정도)에 구독하려면 w:en:위키백과:VisualEditor/Newsletter for English Wikipedia only 또는 Meta에서 모든 프로젝트에 대해.고마워!Whatamidoing (WMF) (토크) 18:13, 2014년 8월 8일 (UTC)

WMFLabs 개방형 데이터 문제

마리아DB [enwiki_p]> 쇼 데이터베이스 맘에 들다 "p5%\_p"; +----------------------------+   데이터베이스 (p5%\_p)            +----------------------------+   p50380gg50592__interwikis_p     p50380g50921__ghel_p           p50380g50921__wma_p          +----------------------------+ 3 노를 젓다 에 세트 (0.05 초) 

실험실은 툴서버에 비해 데이터 공개가 훨씬 적다.우리가 할 수 있는 일이 있을까?덜 엉망이 된 이름 붙이는 시스템인가?(http://tools.wmflabs.org/50592에서 빈 페이지를 반환하는 중)?사용자보다 먼저 열려 있지 않은 데이터 프로젝트를 선택해야 하는 경우:Silke WMDE가 Toolserver 백업을 삭제하시겠습니까?— 디스펜서 21:13, 2014년 8월 8일(UTC)

복합 템플릿 구문 질문

최근에 템플릿 편집에 참여하게 된 경우:이라크 반군의 상세한 지도.템플릿의 시작 구문은
{{#invoke:위치 지도 상단 이라크 대안맵=이라크 위치 지도2.svg float=왼쪽 폭=1800 캡션=y}}}
내 질문은 어떻게 하면 이미지를 만들 수 있을까 하는 것이다. 파일:이라크의 위치 지도2.svg는 이라크의 다양한 지역을 대표하는 아이콘들을 클릭할 수 있는 유일한 조각으로 남겨두기 위해 클릭할 수 없는 상태로 만들어졌는가?지금과 같이, 이 지도는 클릭이 가능하며, 트윙클을 가진 사람들에게는 마우스가 그 위를 맴돌 때 중요한 정보 위에 인포박스를 싣게 된다.기본적으로, 그것은 쉬운 해결책이 있는 사소한 골칫거리다.보통 같으면 클릭할 수 없는 이미지를 만들기 위해 빈 alt= 명령을 추가했을 텐데, 이것이 효과가 없는 것 같고 {{#invoke:...의 의미를 알기 위해 이 고급 코딩을 이해할 수 없다.도움이 필요하십니까? -- 채소 (대화) 19:20, 2014년 8월 8일 (UTC)

두 사람<div>아무 상관도 없으니 위에서 제거해 버렸다.그#invoke:루아가 진행 중이라는 것을 알 수 있는데, 이것은 정상적인 템플릿 코드가 아니기 때문에 추적이 더 어려워진다.다음 두 단어는location map기본 코드가 모듈에 있다는 것을 알 수 있다.위치 지도.보아하니, link= 네가 원하는 것을 하기 위해 우리가 이용할 수 있어야 하는 매개 변수지만, 나는 이미지의 연결을 해제할 수 없다.Jackmcbarn(말·출고)은 방법을 알지도 모른다. --Redrose64(말) 20:51, 2014년 8월 8일(UTC)

그 이미지를 흠잡을 수 없게 만드는 것은 그것의 면허를 위반하는 것이다.Jackmcbarn (대화) 20:53, 2014년 8월 8일(UTC)

더 말해줄래?이미지는 CC-3.0이다. 클릭 가능성을 파일 페이지로 되돌리는 것이 의무적인가, 아니면 캡션에 있는 저자 이름만 클릭하는 것이 필요한가? -- 채식 (토크) 20:59, 2014년 8월 8일 (UTC)

법적인 관점에서 우리가 CC-BY-SA 이미지를 표시할 때, 우리는 두 가지를 해야 한다: 첫째, 저작권 소유자에게 귀속성을 제공하는 것, 둘째, 이미지가 CC-BY-SA 라이센스 하에 있다는 것을 분명히 하는 것.우리는 보통 이 두 가지 일을 파일 설명 페이지 링크를 통해 한다. 그래서 Jackmcbarn은 이미지를 수정할 수 없게 만드는 것이 라이선스를 위반하는 것이라고 말한다.기술적으로 만약 우리가 이미지 캡션에서와 같이 이 두 가지를 다른 방법으로 제공한다면, 우리는 그 이미지를 흠잡을 수 없게 만들 수 있지만, 그러나 바람직하지 않은 많은 페이지에서는, 그리고 단지 파일 페이지에 연결하는 것이 더 중요하다.— Stradivarius^{♪ talk ♪} 04:00, 2014년 8월 9일 (UTC)

구문을 사용하는 템플릿에서는 배경 이미지가 연결되지 않고 이미지 파일 페이지로 연결되는 캡션 오른쪽 상단에 아이콘이 있다.모듈에는 다음과 같은 옵션이 될 수 있음:위치 지도도.그것이 가능하지 않다면 (배경 파일)"과 같은 간단한 링크도 자막에 추가될 수 있다.SiBr₄ (대화) 09:30, 2014년 8월 9일 (UTC)

@베기:모듈에 확대 아이콘을 추가하고 새 매개 변수를 추가했다.maplink에 대한 통제를 허용하다link이미지의 매개 변수.Jackmcbarn (대화) 2014년 8월 9일 (UTC)

이런...이 아이콘을 클릭하면 미디어 뷰어가 활성화된다. -- [[User:Edokter]] {{talk}}2014년 8월 9일 17:22(UTC)

@Edokter:가짜 미리 보기에 대해 MediaViewer(미디어 보기)를 비활성화하여 일단 수정.나는 언젠가 MediaViewer 자체에 대한 적절한 수정 사항을 쓸 계획이다.bugzilla:69353을 참조하십시오.Jackmcbarn (대화) 2014년 8월 9일 (UTC)

잠재적으로 비파괴적인가?

로그아웃한 ip로서, 나는 오타/오타("후기"를 "후기"로 대체)를 아주 빨리 고치려고 하고 있었다. 나는 우연히 조셉 코스마#바이오그래피에서 발견하게 되었다.나는 이 편집을 할 수 없었다.보아하니, 자동화된 필터는 이 편집이 잠재적으로 비파괴적인 것으로 확인되었고, 그것은 허용되지 않았다.또한 내가 지시받은 페이지가 ip 기여로부터 보호되는 것처럼 보이기 때문에, 나 역시 요청대로 오류를 보고할 수 없었다.

이 경험에서 위키피디아의 정신으로 볼 때, 간단한 해결책은 달갑지 않은 것처럼 보인다.

(참고: 계정을 얻거나 로그인하라는 말은 하지 마십시오. 개별 사용자가 IP로서 적극적으로 기여하기를 선호하는 다양한 이유가 있습니다.)
86.157.144.73 (대화) 12:17, 2014년 8월 10일 (UTC)

그것은 당신이 보고서를 작성해야 하는 페이지가 아니기 때문에 보호된다.잘못된 긍정을 보고하려면 여기를 클릭하십시오 링크를 클릭하여 오른쪽 페이지(하위 페이지임)로 이동하거나, 기본 페이지의 원본을 보면 다른 페이지로 이동해야 한다는 큰 경고가 표시된다.내가 자네를 위해 보고서를 제출했고, 이것은 분명히 잘못된 긍정이라고 언급했으니까, 이번에는 그것을 하는 것에 대해 걱정하지 마. 나는 사물의 기술적 측면에 대해 이해할 수 없으니까.나이튼드 (대화) 13:28, 2014년 8월 10일 (UTC)

그 나이튼드를 해줘서 정말 고마워.나는 지금 하위 페이지로 연결되는 링크를 보고 있고, 아마 시간이 날 때쯤 호프 속을 헤쳐나갈 것이다.좀 더 넓은 관점에서, 나는 몇몇 새로운 기고자들이 그들의 첫 번째 편집 경험으로 이런 것들을 접하게 될 수도 있다는 것을 명심할 필요가 있다고 생각한다:-/ 86.157.144.73 (토크) 14:21, 2014년 8월 10일 (UTC)

800개 이상의 Wiki에서 위키 간 알림

이 문제에 대한 몇 가지 작업을 마친 후, 나는 XTools 가젯의 새로운 XAgent를 발표하고자 한다.현재 작업이 진행 중이지만 사용할 준비가 되어 있다.만약 당신이 버그에 걸려 비틀거리거나 더 많은 제안이 있다면, 자유롭게 보고하라.

• XTools 가젯
• 버그/피드백:Bugzilla (우선) GitHub.

즐겨라. --Hedonil (대화) 16:30, 2014년 8월 10일 (UTC)

고마워 헤도닐이 훌륭한 기계는 점점 더 좋아지고 있다! --NeilN 18:17, 2014년 8월 10일 (UTC)

부서진 페이지: "Option_symbol"

URL

http://en.wikipedia.org/wiki/Option_symbol

다음 텍스트만 표시...

<링크 rel="스타일시트" href="//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.gadget.DRN-wizard%2CReferenceTooltips%2Ccharinsert%2CrefToolbar%2Cteahouse%7Cext.rtlcite%2Cwikihiero%7Cext.uls.nojs%7Cext.visualEditor.viewPageTarget.noscript%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cskins.vector.styles%7Cwikibase.client.init%2Cnolanglinks&only=스타일&skin=벡터&*

위키백과 페이지가 나타나지 않는다.

버질라를 통해 제출하려고 했는데, 로딩하는 동안 걸려있었어.— 165.121.80.236 (대화) 22:18, 2014년 8월 5일 (UTC)이(가) 추가된 이전 미서명 의견

내가 그 페이지를 치웠어야 했는데, 그게 이걸 고쳤어야 했어.그래도 오류가 발생하면 브라우저 캐시를 바이패스해 보십시오.—DJ (대화 • 기여) 09:21, 2014년 8월 6일 (UTC)

당신의 코멘트에 있는 블록 "[link el=…)" 텍스트가 내 모니터의 레이아웃을 깨고 오른쪽으로 튀어나오고 있다.그것을 동봉해 주시겠습니까?<pre style="overflow:auto"> </pre>태그?벤츠밴드(토크) 14:22, 2014년 8월 10일(UTC)

아티클에 템플릿이 너무 많음

기사에서 템플릿이 너무 많아서 마지막 템플릿은 나타나지 않는다.좋아, 쉬운 해결책은 그것들 중 일부를 제거하는 거야.다른 해결책은 없을까?자리스333 (대화) 02:50, 2014년 8월 8일 (UTC)

@Xaris3333: 어떤 기사인지 알려주시겠습니까?고마워!GoingBatty (토크) 03:24, 2014년 8월 8일 (UTC)

그것은 그리스어 위키에 있다.el:Πορεία των κυπριακών ομάδων στα ευρωπαϊκά κύπελλα ποδοσφαίρου Xaris333 (talk) 04:08, 8 August 2014 (UTC)

이제 괜찮아 보인다.그러나 나중에 이 문제를 발견하게 되면, 당신이 할 수 있는 일 중 하나는 Subst(변위)이다. 파서 오류 이전부터의 간단한 템플릿들 중 몇 가지는 페이지의 확장 크기를 줄이기 위해 (변위기와 이후의 모든 것은 템플릿 결과의 변위기로 평가될 수 없다)이다.VanIsaac_WS^cont 04:37, 2014년 8월 8일(UTC)

괜찮지 않아.마지막을 봐.Template:cite web과 {{reference}}(παρο μπςςς)을 볼 수 있다.둘 다 효과가 없다.자리스333 (대화) 04:48, 2014년 8월 8일 (UTC)

자리스333, 템플릿이 너무 많지 않고 그것은 문제가 되지 않는다.너는 그 글의 절반을 지울 수 있지만 여전히 문제가 있다.이것은 그리스어 위키피디아에 있기 때문에, 이것은 아마도 그리스어를 말하는 사람이 가장 잘 다룰 것이다.매기올라디스를 부른다.Bgwhite (대화) 07:01, 2014년 8월 8일 (UTC)

그래, 나중에 참조할 수 있도록, 한 페이지에 템플릿이 너무 많을 때(아래로 스크롤) 이렇게 표시되는 경우.노드 수가 초과되었다는 빨간색 오류 메시지가 표시되지 않으면 문제가 다른 문제임.VanIsaac_WS^cont 07:53, 2014년 8월 8일(UTC)

• 페이지 소스 코드를 보십시오.그것은 나에게 다음과 같이 말해준다.

<>!--NewPP 제한 보고서 mw1057 CPU시간 사용에 의해 Parsed:40.799초 실시간 사용:41.401초를 추가하십시오:303126/1000000을 노드 수 생성된:150774/1500000 Post‐expand 크기:2048000/2048000 바이트Template 주장 크기:829659/2048000 바이트 높은 확장 깊이:17/40 비싼 파서 재미 등 노드 수를 방문했다.cti카운트 온: 0/500 -->

CPU 시간이 매우 높으며, 확장 후 최대 크기를 포함한다.후자가 문제의 원인일 것이다.내 추측으로는 너무 많은 "cite web"과 "harvnb" 템플릿이 원인인 것 같다.변전될 수 있다면 그렇게 해봐루포 10:43, 2014년 8월 8일 (UTC)

아, 훌륭해.따라서 템플릿이 너무 많은 것이 아니라(노드 수가 최대 1/3이다), 페이지 콘텐츠가 너무 큰 것으로 보인다.그 기사는 그냥 평범하게 나눠야 할 것 같아.VanIsaac_WS^cont 05:50, 2014년 8월 10일(UTC)

네$wgMaxArticleSizeWMF 위키에서 2000kB로 설정됨: [39]루포 10:38, 2014년 8월 11일 (UTC)

위키피디아를 개인 웹페이지의 호스팅 공간으로 사용하는 사람들을 식별할 수 있는 방법이 있는가?

위키백과를 웹호스트로 사용하는 편집자(수동적으로 대부분)를 쉽게 찾을 수 있도록 편집자만 자신의 사용자 공간에 있는 편집자 목록을 쉽게 만들 수 있는 방법이 있는가?스키틀 (토크) 09:39, 2014년 8월 8일 (UTC)

첫 번째 샌드박스 초안을 작성하는 편집자들의 잘못된 긍정의 수가 압도적 다수가 아닐 수도 있고, 따라서 오히려 비효율적인 남용 탐지 도구가 될 수도 있는지 궁금하다.로저 (Dodger67) (대화) 10:29, 2014년 8월 8일 (UTC)

나도 그 점이 궁금하긴 했지만, 비교적 쉬운 방법이 있었다면 아마 조사할 가치가 있다고 생각했을 것이다.내 말은, 이상적으로는 당신도 회계연령이나 그런 것들을 기준으로 필터링할 수 있기를 원하겠지만, 그것은 추가적인 노력 없이는 성취할 수 없을 것 같다.스키틀 (토크) 11:22, 2014년 8월 8일 (UTC)

재미있는 생각이야.나는 그와 같은 것을 프로토타입으로 만들어 그 결과가 어떻게 보이는지 볼 수도 있다.Chillum 20:54, 2014년 8월 11일 (UTC)

보 텍스트 전용 템플릿이 티베트 텍스트를 너무 크게 렌더링함(MS Windows 제외)

Bo-textonly 템플릿의 사이징은 매우 작은 크기로 티베트 텍스트를 렌더링하는 Microsoft Himalaya 글꼴(MS Windows의 기본 티베트 글꼴)과 함께 작동하도록 조정된 것으로 보인다.이 템플릿은 이를 수정하지만, 다른 운영 체제나 다른 티베트 글꼴에 표시되면 티베트 텍스트가 너무 크게 렌더링되어 라인 간격이 흐트러질 수 있다.티베트 글꼴에는 "표준" 크기가 없기 때문에 하나의 스케일링 크기가 모두 들어맞지 않는다. 사실 일부 티베트 글꼴은 확장이 전혀 필요하지 않다.클라이언트 시스템에서 사용되는 기본 티베트 글꼴에 기반하여 크기를 조정하는 방법이 있는가?

그동안 나는 이 템플릿의 스케일링 사이즈를 그레이트 브라이트스타가 늘리기 전의 130%로 되돌렸다.이것은 모든 시스템에 이상적인 것은 아니다 - 티베트어의 텍스트는 여전히 많은 시스템에서는 너무 크고 윈도우에서는 약간 작을 것이다 - 하지만 그것은 내가 시도해 본 다른 시스템들에 근거한 최상의 타협에 관한 것으로 보인다.

나는 이 문제가 티베트 문자용 다른 템플릿에서 발견되는지 아직 확인하지 못했다.

크리스 핀 (토크) 06:08, 2014년 8월 10일 (UTC)

나는 중국어 위키백과의 샌드박스에서 시험을 보았다.내 컴퓨터는 Windows 8.1을 사용하고, "Microsoft Himalaya"라는 이름의 글꼴이 내장되어 있다.이 글꼴에서 타임즈 뉴로마어와 같은 일부 라틴 문자.내 테스트에서 나는 150%로 크기를 조정하면 이 글꼴이 타임즈 뉴로맨과 정렬할 수 있다는 것을 발견했다.제 결과 입니다.--Great Brightstar (대화) 09:29, 2014년 8월 10일 (UTC)

@Great Brightstar:그게 바로 문제야.150%로 변경했을 때 다른 티베트 글꼴보다 훨씬 작은 크기로 렌더링되는 Microsoft Himalaya 글꼴로 Windows 시스템에서만 테스트한 것으로 보인다.맥 OSX(Kailash 또는 Kokonor)의 기본 티베트 글꼴은 스케일링이 필요하지 않으며, 150%를 만들면 크기가 커진다.마찬가지로 DDC Uchen, Linux 또는 Windows의 Jomolhari Font.모든 사람이 Microsoft Windows를 사용하는 것은 아니며 심지어 Windows에서도 그들은 다른 티베트 글꼴을 설치했을지도 모른다.따라서 이러한 것들을 다양한 공통 글꼴과 다양한 공통 브라우저에서 테스트할 필요가 있다.특정 글꼴과 특정 브라우저를 사용하여 Windows에서 작동하는 것이 다른 모든 곳에서 작동한다고 가정하지 마십시오.Microsoft Himalaya 글꼴이 보기 좋게 보이려면 150%가 필요한 반면, 이것은 다른 시스템에서는 너무 크고 줄 간격에 문제를 일으키지만 다른 시스템의 다른 글꼴은 스케일링이 전혀 되지 않고 보기 좋다(100%).따라서 고객이 사용하는 시스템과 글꼴에 따라 확장되도록 템플릿을 수정하지 않는 한, 130% 또는 125%와 같은 절충된 확장 기능을 사용해야 한다.이것은 윈도우 시스템에서는 약간 작을 것이고 맥 시스템에서는 약간 클 것이다 - 하지만 적어도 어느 쪽에서도 그리 나쁘지는 않다.안부 전해요크리스 핀 (토크) 10:22, 2014년 8월 10일 (UTC)

아~ 시험 볼 때 전혀 고려하지 않았어..--그레이트 브라이트스타 (토크) 08:16, 2014년 8월 11일 (UTC)

오래된 개정 경고

예를 들어 텍스트를 검정색 대신 빨간색으로 만들어 "이 페이지의 구식 수정본을 편집 중" 경고가 더욱 두드러지게 만드는 방법이 있는가?그 검은 글자는 내 주의를 끌지 못한다.나는 모노북 스킨과 IE11을 사용한다.고마워요.DH85868993 (대화) 10:37, 2014년 8월 10일 (UTC)

관련 메시지는 MediaWiki:이미 큰 분홍색 #FFDB 박스에 들어 있는 Editingold.대부분의 위키피디아들은 메시지를 표시하는 그들만의 방법을 가지고 있다: 예를 들어, 웨일스어, 독일어, 스페인어, 프랑스어, 또는 네덜란드어. 하지만 모든 경우에, 그것은 밝은 배경에 있는 컬러 텍스트이거나, 색 배경에 검정색 텍스트이거나, 심지어 불이 켜지면 검정색 텍스트가 된다.분홍색 텍스트는 대조비가 내 서명처럼 높지 않으면 아마도 WCAG에 실패할 것이다 - 빨간색 #a80000은 상당히 어둡고 분홍색 #fee는 상당히 약하다. --Redros64 (토크) 08:30, 2014년 8월 11일 (UTC)

@DH85868993: 위에서 나는 모든 독자들을 위해 일반적인 경우를 고려하고 있었다.개인적으로 바꾸고 싶으면 CSS로 하면 돼현재 설정은 기본적으로 다음과 같다.

테이블#편집상의 {   배경색: #FFDBDB;   테두리 색의: #BB7070;   색을 칠하다: #000000; } 

특수에 붙여넣기:MyPage/common.css, 원하는 대로 색상을 조정하여 저장. --Redrose64 (토크) 09:06, 2014년 8월 11일 (UTC)

답장 고마워 @Redrose64:하지만 오래된 버전을 편집할 때 큰 분홍색 상자가 보이지 않는다 - 나는 다음과 같은 것을 본다.

사용자 편집 중:DH85868993/샌드박스

무료 백과사전인 위키피디아에서

2014년 8월 1일 19시 10분 현재 DH85868993에 의한 개정(토크 기여)

(diff) ← 구형 최신 개정 (diff) 신개정 → (diff)

경고: 이 페이지의 오래된 수정사항을 편집하는 중.저장하면 이 수정기호 이후 변경된 내용이 손실된다.

창 편집